From patrick at ianai.net Sat Aug 1 02:10:50 2009 From: patrick at ianai.net (Patrick W. Gilmore) Date: Sat, 1 Aug 2009 03:10:50 -0400 Subject: XO - a Tier 1 or not? In-Reply-To: References: <607f1e0a0907280811j6257ed1w21fcb331e271daf5@mail.gmail.com> Message-ID: <9D303F9F-5902-4F74-BEB4-A60B20B458F4@ianai.net> On Jul 28, 2009, at 11:36 AM, John van Oppen wrote: > XO has been offering a product lately that is all routes except level3 > and sprint which leads me to believe that they pay both of those > peers... Or there is a settlement in place, which is kinda-sortta the same thing, only not necessarily. Or they are worried about their ratios to those two networks. Which may be because of settlements. Or they might have capacity issues to those networks _because_ they do not pay those networks. Or .... Or you could be right. :) -- TTFN, patrick > -----Original Message----- > From: Justin M. Streiner [mailto:streiner at cluebyfour.org] > Sent: Tuesday, July 28, 2009 8:31 AM > To: nanog at nanog.org > Subject: Re: XO - a Tier 1 or not? > > On Tue, 28 Jul 2009, Charles Mills wrote: > >> Trying to sort through the marketecture and salesman speak and get a >> definitive answer. >> >> I figure the NANOGers would be able to give me some input. >> >> Is XO Communications a Tier 1 ISP? > > Do the best of my knowledge, no. The definition of 'Tier 1' is > something > of a moving target based on who you ask, but the most commonly stated > criteria I've seen over the years are: > 1. The provider does not buy IP transit from anyone - all traffic is > moved > on settlement-free public or private interconnects. That's not to > say > that the provider doesn't buy non-IP services (IRUs, lambdas, > easements, > etc) from other providers on occasion. > 2. The provider lives in the default-free zone, which is pretty much a > re-statement of point 1. > > I'll leave discussions about geographical coverage out of it for now. > > That said, I don't think XO meets the criteria above. I'm not 100% > certain, but I don't think they're totally settlement-free. Other > providers like Cogent would fall into this bucket as well. > > However, I also wouldn't get too hung up on tiers. Many very > reliable, > competent, and responsive providers providers but transit to handle at > least some portion of their traffic. It also depends on what sort of > service you need. For example, if you need a big MPLS pipe to another > country, there are a limited number of providers who can do that, so > they > would tend to be the big guys. However, if you just need general IP > transit, your options open up quite a bit. > > jms > > From ip at ioshints.info Sat Aug 1 03:11:10 2009 From: ip at ioshints.info (Ivan Pepelnjak) Date: Sat, 1 Aug 2009 10:11:10 +0200 Subject: Data Center QoS equipment breaking http 1.1? In-Reply-To: References: Message-ID: <000301ca127f$a2867db0$0a00000a@nil.si> Facts first: name-based virtual hosts depend on the HOST header in the HTTP/1.1 request to select the virtual web server. > I poured over my configs (I've done this config countless > times), and saw this in the apache docs: > > http://httpd.apache.org/docs/2.2/vhosts/name-based.html > > " Some operating systems and network equipment implement > bandwidth management techniques that cannot differentiate > between hosts unless they are on separate IP addresses." Thanslated into networking engineerese: since the QoS equipment (including routers unless you use HTTB NBAR) cannot peer into contents of the TCP session, it cannot find the HOST header and thus cannot decide which virtual host the traffic belongs to, making it impossible to enforce per-virtual-host QoS policies. > So, I installed lynx on the server, and sure enough, it > worked perfectly fine there, just not from anywhere outside > eSecuredata's network that I could see. > > Can anyone shed any light on this particular practice, of > this company in particular? What you're experiencing usually means only one thing: they're using a box that messes with HTTP headers. It could be a misconfigured DPI box, a transparent (broken) HTTP proxy or a custom-developed "wizardry". Configure the Apache logs (http://httpd.apache.org/docs/2.2/logs.html) to log the virtual host name in the HTTP request (the %{host}i directive) or use Wireshark on your client and the server to inspect it. If you find out they're messing with the HOST header (as suspected) switch the provider immediately. Ivan http://www.ioshints.info/about http://blog.ioshints.info/ From rol at witbe.net Sat Aug 1 03:44:36 2009 From: rol at witbe.net (Paul Rolland (=?UTF-8?B?44Od44O844Or44O744Ot44Op44Oz?=)) Date: Sat, 1 Aug 2009 10:44:36 +0200 Subject: The Cidr Report In-Reply-To: <73CBA376-77FB-4E13-A062-3C6FE31EF8DE@ianai.net> References: <200907312200.n6VM00px043598@wattle.apnic.net> <73CBA376-77FB-4E13-A062-3C6FE31EF8DE@ianai.net> Message-ID: <20090801104436.28cc8dd9@tux.DEF.witbe.net> Hi Patrick, On Fri, 31 Jul 2009 18:22:37 -0400 "Patrick W. Gilmore" wrote: > On Jul 31, 2009, at 6:00 PM, cidr-report at potaroo.net wrote: > > > Recent Table History > > Date Prefixes CIDR Agg > > 24-07-09 298785 182835 > > 25-07-09 299168 182751 > > 26-07-09 298909 182973 > > 27-07-09 299265 183099 > > 28-07-09 299345 183207 > > 29-07-09 299380 182987 > > 30-07-09 299354 183395 > > 31-07-09 299904 183680 > > Only 94 prefixes short! You mean 96, or is 299998 important to you ? ;) > Any bets on whether next tomorrow is THREE HUNDRED (thousand) day? > Careful what you say, we actually dropped prefixes Wed -> Thurs this > week. Don't invite people to "leak", you can be sure one of them will try to be the one who "helped" reach the 300K range :( Paul -- Paul Rolland E-Mail : rol(at)witbe.net CTO - Witbe.net SA Tel. +33 (0)1 47 67 77 77 Les Collines de l'Arche Fax. +33 (0)1 47 67 77 99 F-92057 Paris La Defense RIPE : PR12-RIPE This is dedicated to all the ones who want to control Internet, its content or its usage : "I worry about my child and the Internet all the time, even though she's too young to have logged on yet. Here's what I worry about. I worry that 10 or 15 years from now, she will come to me and say 'Daddy, where were you when they took freedom of the press away from the Internet?'" --Mike Godwin, Electronic Frontier Foundation From gih at apnic.net Sat Aug 1 04:27:06 2009 From: gih at apnic.net (Geoff Huston) Date: Sat, 1 Aug 2009 19:27:06 +1000 Subject: The Cidr Report In-Reply-To: <20090801104436.28cc8dd9@tux.DEF.witbe.net> References: <200907312200.n6VM00px043598@wattle.apnic.net> <73CBA376-77FB-4E13-A062-3C6FE31EF8DE@ianai.net> <20090801104436.28cc8dd9@tux.DEF.witbe.net> Message-ID: <3F67C678-69BD-40A2-83BF-F09D5E6F0B5A@apnic.net> On 01/08/2009, at 6:44 PM, Paul Rolland (???????) wrote: > Hi Patrick, > > On Fri, 31 Jul 2009 18:22:37 -0400 > "Patrick W. Gilmore" wrote: > >> On Jul 31, 2009, at 6:00 PM, cidr-report at potaroo.net wrote: >> >>> Recent Table History >>> Date Prefixes CIDR Agg >>> 24-07-09 298785 182835 >>> 25-07-09 299168 182751 >>> 26-07-09 298909 182973 >>> 27-07-09 299265 183099 >>> 28-07-09 299345 183207 >>> 29-07-09 299380 182987 >>> 30-07-09 299354 183395 >>> 31-07-09 299904 183680 >> >> Only 94 prefixes short! > You mean 96, or is 299998 important to you ? ;) > >> Any bets on whether next tomorrow is THREE HUNDRED (thousand) day? >> Careful what you say, we actually dropped prefixes Wed -> Thurs this >> week. > Don't invite people to "leak", you can be sure one of them will try > to be > the one who "helped" reach the 300K range :( done! Right now its 300002 entries from this vantage point. In amidst the teeming morass of updates of existing announced prefixes, sorting out the exact announcement of a new prefix that took the table over 300000 entries will take a little time to work out. Geoff From marcus at grmpf.org Sat Aug 1 07:45:24 2009 From: marcus at grmpf.org (Marcus Stoegbauer) Date: Sat, 01 Aug 2009 14:45:24 +0200 Subject: DENOG 1 - Call for Participation and Papers Message-ID: <4A7438E4.6090404@grmpf.org> DENOG 1 - Call for Participation and Papers The first meeting of the German Network Operators Group (DENOG) will be held in Frankfurt, Germany on the 5th of November 2009. We are pleased to hereby invite applications for presentations or short lightning talks to be held at this inaugural event. General Information =================== DENOG is a community for professionals within Germany who are operating, designing or researching the Internet. It provides a technical forum where those working on, with and for the Internet can come together to solve problems with every aspect of their (net)work. The inaugural meeting is designed to provide an opportunity for the exchange of information among network operators, engineers, researchers and other professionals close to the network community. More information about DENOG (in German) can be found at http://www.denog.de/ Information about the meeting will be published at http://www.denog.de/meeting/. Meeting Countdown ================= What When ------------------------------------------------------ Publication of Call for Papers July 27th, 2009 Deadline for all submissions September 28th, 2009 Publication of final programme October 11th, 2009 Deadline for receipt of final slides October 29th, 2009 Meeting Day November 5th, 2009 Topics for Presentations/Talks ============================== The day will be divided into four sessions as described below. The number and length of presentations per session is not fixed, although due to time constraints we would prefer the length of the presentations to be between 10 to 30 minutes. However proposals for longer/shorter presentations or presentations whose subject falls outside of the topics below are also welcome; please do not hesitate to submit them. Topic #1: Internet, politics and regulations -------------------------------------------- Duration: 90 minutes Topics can include (but are not limited to): Legal interception, government-driven DNS blacklists, DNSSEC (and problems arising from DNS blacklists). Topic #2: Peering ------------------ Duration: 60 minutes All around your peering experience. Why are you doing it? How are you doing it? Have you written any useful tools which others might find interesting? Topic #3: ISP BOF ----------------- Duration: 90 minutes "All things ISP". From Network/SLA Management (for or against it), abuse handling and log systems to data centre layout and planning (including power and cooling), everything that is interesting to you as an ISP can be presented or discussed within this topic. Topic #4: DENOG Organisational Matters -------------------------------------- Duration: 60 minutes, no papers necessary In this session we will discuss how to proceed with DENOG and potential future meetings. We will present our ideas and eagerly await your own ideas, feedback and comments. Submission Guidelines ===================== All submissions must have a strong technical bias and must not be solely promotional for your employer. To appeal to an international audience we ask you to produce your slides in English, but the presentation itself can be in either German or English. Please remember that your presentations should be suitable for a target audience of technicians from varied backgrounds, working for companies whose sizes vary considerably. To submit a proposal for a presentation, we request that you provide the following information as plain text or PDF format to : * the name of the presenter (and if applicable your affiliation) * a working email address * the name and number of the topic which will contain the presentation * the title of the presentation * its expected length (in minutes) * the preferred spoken language for the presentation * a short abstract of the presentation (not more than 200 words) We also welcome suggestions for specific presentations which you feel would be valuable to the DENOG community. Please be aware that your presentation will be publish on the DENOG website after the event. From leothelion.murtaza at gmail.com Sat Aug 1 10:06:41 2009 From: leothelion.murtaza at gmail.com (Murtaza) Date: Sat, 1 Aug 2009 21:06:41 +0600 Subject: caches for peer-to-peer trafic In-Reply-To: References: <949b74980907300216j5300dd26rd13ffba1bb48bb48@mail.gmail.com> Message-ID: <949b74980908010806s62c78ccbq349e90d09db14694@mail.gmail.com> Guys! Thank you very much for your responses. Anymore responses will also be very much appreciated. On Fri, Jul 31, 2009 at 6:00 PM, Charles Gucker wrote: > Sandvine Thanks and Regards, Ghulam Murtaza PhD Student, Lahore University of Management Sciences From andrew.wallace at rocketmail.com Sat Aug 1 10:10:38 2009 From: andrew.wallace at rocketmail.com (andrew.wallace) Date: Sat, 1 Aug 2009 16:10:38 +0100 Subject: Dan Kaminsky In-Reply-To: <7C332C86-7E7C-4C4E-8ADD-61310CA0758C@kyx.net> References: <4b6ee9310907291453y6da24d19l21cc5345bd8f08a2@mail.gmail.com> <4A711E00.7030602@trelane.net> <7C332C86-7E7C-4C4E-8ADD-61310CA0758C@kyx.net> Message-ID: <4b6ee9310908010810w50796caenac7471b94fac1792@mail.gmail.com> On Thu, Jul 30, 2009 at 11:48 PM, Dragos Ruiu wrote: > at the risk of adding to the metadiscussion. what does any of this have to > do with nanog? > (sorry I'm kinda irritable about character slander being spammed out > unnecessarily to unrelated public lists lately ;-P ) > What does this have to do with Nanog, the guy found a critical security bug on DNS last year. There is no slander here, I put his name in the subject header so to draw attention to the relevance of posting it to Nanog. I copy & pasted a news article caption, which also doesn't slander Dan Kaminsky but reports on the actions of other people true to the facts. Any further slander allegations, please point them at Wired's legal team. Andrew From cordmacleod at gmail.com Sat Aug 1 15:11:17 2009 From: cordmacleod at gmail.com (Cord MacLeod) Date: Sat, 1 Aug 2009 13:11:17 -0700 Subject: Dan Kaminsky In-Reply-To: <4b6ee9310908010810w50796caenac7471b94fac1792@mail.gmail.com> References: <4b6ee9310907291453y6da24d19l21cc5345bd8f08a2@mail.gmail.com> <4A711E00.7030602@trelane.net> <7C332C86-7E7C-4C4E-8ADD-61310CA0758C@kyx.net> <4b6ee9310908010810w50796caenac7471b94fac1792@mail.gmail.com> Message-ID: I don't see a video attached or an audio recording. Thus no slander. Libel on the other hand is a different matter. On Aug 1, 2009, at 8:10 AM, andrew.wallace wrote: > On Thu, Jul 30, 2009 at 11:48 PM, Dragos Ruiu wrote: >> at the risk of adding to the metadiscussion. what does any of this >> have to >> do with nanog? >> (sorry I'm kinda irritable about character slander being spammed out >> unnecessarily to unrelated public lists lately ;-P ) >> > > What does this have to do with Nanog, the guy found a critical > security bug on DNS last year. > > There is no slander here, I put his name in the subject header so to > draw attention to the relevance of posting it to Nanog. > > I copy & pasted a news article caption, which also doesn't slander Dan > Kaminsky but reports on the actions of other people true to the facts. > > Any further slander allegations, please point them at Wired's legal > team. > > Andrew > From jingshao at teekoo.com Sun Aug 2 10:19:43 2009 From: jingshao at teekoo.com (jingshao at teekoo.com) Date: Sun, 2 Aug 2009 11:19:43 -0400 Subject: bgp 4 asdot Message-ID: <20090802151942.GA7161@teekoo.com> Hi, I would like to know if there is still people using asdot format in real world? If do, would you please send me that line of output from a cisco router's show ip bgp? Also the show version of the cisco router please. We are writing a script to parse the output of cisco show ip bgp, would like to cover the corner case. Is asdot a corner case, anyway? Thanks, Jingshao Chen From jingshao at teekoo.com Sun Aug 2 15:15:40 2009 From: jingshao at teekoo.com (jingshao at teekoo.com) Date: Sun, 2 Aug 2009 16:15:40 -0400 Subject: What else shall we test? In-Reply-To: <1248307553.6564.767.camel@mike-desktop> References: <1248307553.6564.767.camel@mike-desktop> Message-ID: <20090802201539.GA13182@teekoo.com> Mike, Not familiar with JDSU product. But if you are serious about IP routing and packet forwarding test, you need to take a look at test tools. Do you hear of IXIA? They have a full set of test tools that test routers. I would suggest you try IxNetwork for control plane and forwarding plan. Their web site is http://www.ixiacom.com/ Thanks, Jingshao On 07/22/09, Michael J McCafferty wrote: > All, > We are putting together a test plan to test a pair of Cisco 7206 VXR's, > each with with NPE-G2. The purpose of the test is just to make sure we > know where their realistic limits are with a real configuration, full > route tables from two providers, etc. We have one JDSU T-Berd 8000 test > system with interfaces and software to test a single stream through > multi-mode fiber interfaces. We plan to test through the interfaces on > the NPE and through PA-GE cards with a variety of packet sizes > (especially 64 Byte). > I'd be interested in any thoughts on additional testing or testing > methodologies we might want to do, to help us set our expectations for > this setup and to plan when we need to go bigger as we grow traffic, > hosts, etc. > We plan to get 1 to 3 additional full tables and peer with Any2 Easy on > this network within the next year. We want to determine how this > platform will behave under moderate DoS attacks, BGP updates, etc. Is > there anything else we need to be mindful of? Can we get a realistic > test of the routers with the T-Berd? What else should we test while we > have the maintenance window and the test system on hand? > > Your thoughts and experience are appreciated! > > Thanks ! > Mike > > -- > ************************************************************ > Michael J. McCafferty > Principal, Security Engineer > M5 Hosting > http://www.m5hosting.com > > You can have your own custom Dedicated Server up and running today ! > RedHat Enterprise, CentOS, Ubuntu, Debian, OpenBSD, FreeBSD, and more > ************************************************************ > > From jingshao at teekoo.com Sun Aug 2 15:41:51 2009 From: jingshao at teekoo.com (jingshao at teekoo.com) Date: Sun, 2 Aug 2009 16:41:51 -0400 Subject: Triple play in Tier 1 carriers Message-ID: <20090802204151.GB13182@teekoo.com> Hi, My friend is constructing an ISP that provide data, video and voice services. He wanted to know a little bit information on how do the big ones such as ATT, Verizon, Sprint, Comcast design their infrastructures to support Voice and Video. Any pointer will be very appreciated. Thanks, Jingshao From trelane at trelane.net Sun Aug 2 15:51:41 2009 From: trelane at trelane.net (Andrew D Kirch) Date: Sun, 02 Aug 2009 16:51:41 -0400 Subject: Triple play in Tier 1 carriers In-Reply-To: <20090802204151.GB13182@teekoo.com> References: <20090802204151.GB13182@teekoo.com> Message-ID: <4A75FC5D.3080805@trelane.net> Right now we're using Asterisk, Bluetop/Blonder Tongue, and cable modems with a sip interface to provide triple play in large apartment complexes 300+ units). not really core infrastructure but the phones have to ring. Andrew jingshao at teekoo.com wrote: > Hi, > > My friend is constructing an ISP that provide data, video > and voice services. He wanted to know a little bit > information on how do the big ones such as ATT, Verizon, > Sprint, Comcast design their infrastructures to support > Voice and Video. > > Any pointer will be very appreciated. > > Thanks, > Jingshao > > From zartash at gmail.com Sun Aug 2 18:29:28 2009 From: zartash at gmail.com (Zartash Uzmi) Date: Mon, 3 Aug 2009 04:29:28 +0500 Subject: Weekly Routing Table Report In-Reply-To: <200907311812.n6VICtpS019420@thyme.apnic.net> References: <200907311812.n6VICtpS019420@thyme.apnic.net> Message-ID: <4fff97de0908021629r6884c40erbd97f423ea9d6472@mail.gmail.com> Apologies if this is too naive to ask but is there some detail available about the items listed in the summary? 1) In particular, what exactly is the difference between the "BGP routing table entries examined (292961)" and "Unique aggregates announced to Internet (145391)"? 2) I believe 292961 is the worst case routing table size for any router. If the unique aggregates announced to the Internet is 145391, how does the routing table size anywhere may exceeds this number? Is the word "Internet" the key here? 3) Is aggregation done at a particular router for (i) reducing the table size in that router, or (ii) reducing the number of announced prefixes by that router, or (iii) both? Zartash On Fri, Jul 31, 2009 at 11:12 PM, Routing Analysis Role Account < cscora at apnic.net> wrote: > This is an automated weekly mailing describing the state of the Internet > Routing Table as seen from APNIC's router in Japan. > Daily listings are sent to bgp-stats at lists.apnic.net > > For historical data, please see http://thyme.apnic.net. > > If you have any comments please contact Philip Smith . > > Routing Table Report 04:00 +10GMT Sat 01 Aug, 2009 > > Report Website: http://thyme.apnic.net > Detailed Analysis: http://thyme.apnic.net/current/ > > Analysis Summary > ---------------- > > BGP routing table entries examined: 292961 > Prefixes after maximum aggregation: 138493 > Deaggregation factor: 2.12 > Unique aggregates announced to Internet: 145391 > Total ASes present in the Internet Routing Table: 31852 > Prefixes per ASN: 9.20 > Origin-only ASes present in the Internet Routing Table: 27681 > Origin ASes announcing only one prefix: 13518 > Transit ASes present in the Internet Routing Table: 4171 > Transit-only ASes present in the Internet Routing Table: 105 > Average AS path length visible in the Internet Routing Table: 3.6 > Max AS path length visible: 24 > Max AS path prepend of ASN (12026) 22 > Prefixes from unregistered ASNs in the Routing Table: 456 > Unregistered ASNs in the Routing Table: 130 > Number of 32-bit ASNs allocated by the RIRs: 220 > Prefixes from 32-bit ASNs in the Routing Table: 81 > Special use prefixes present in the Routing Table: 0 > Prefixes being announced from unallocated address space: 340 > Number of addresses announced to Internet: 2082757696 > Equivalent to 124 /8s, 36 /16s and 92 /24s > Percentage of available address space announced: 56.2 > Percentage of allocated address space announced: 65.0 > Percentage of available address space allocated: 86.4 > Percentage of address space in use by end-sites: 78.5 > Total number of prefixes smaller than registry allocations: 140414 > > APNIC Region Analysis Summary > ----------------------------- > > Prefixes being announced by APNIC Region ASes: 70058 > Total APNIC prefixes after maximum aggregation: 24829 > APNIC Deaggregation factor: 2.82 > Prefixes being announced from the APNIC address blocks: 69476 > Unique aggregates announced from the APNIC address blocks: 31605 > APNIC Region origin ASes present in the Internet Routing Table: 3717 > APNIC Prefixes per ASN: 18.69 > APNIC Region origin ASes announcing only one prefix: 1012 > APNIC Region transit ASes present in the Internet Routing Table: 579 > Average APNIC Region AS path length visible: 3.5 > Max APNIC Region AS path length visible: 16 > Number of APNIC addresses announced to Internet: 475903680 > Equivalent to 28 /8s, 93 /16s and 182 /24s > Percentage of available APNIC address space announced: 88.6 > > APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 > (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079 > APNIC Address Blocks 58/8, 59/8, 60/8, 61/8, 110/8, 111/8, 112/8, > 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, > 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, > 180/8, 183/8, 202/8, 203/8, 210/8, 211/8, 218/8, > 219/8, 220/8, 221/8, 222/8, > > ARIN Region Analysis Summary > ---------------------------- > > Prefixes being announced by ARIN Region ASes: 124431 > Total ARIN prefixes after maximum aggregation: 66173 > ARIN Deaggregation factor: 1.88 > Prefixes being announced from the ARIN address blocks: 125090 > Unique aggregates announced from the ARIN address blocks: 52293 > ARIN Region origin ASes present in the Internet Routing Table: 13139 > ARIN Prefixes per ASN: 9.52 > ARIN Region origin ASes announcing only one prefix: 5077 > ARIN Region transit ASes present in the Internet Routing Table: 1287 > Average ARIN Region AS path length visible: 3.3 > Max ARIN Region AS path length visible: 24 > Number of ARIN addresses announced to Internet: 1012769216 > Equivalent to 60 /8s, 93 /16s and 161 /24s > Percentage of available ARIN address space announced: 88.8 > > ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 > (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 > 3354-4607, 4865-5119, 5632-6655, 6912-7466 > 7723-8191, 10240-12287, 13312-15359, 16384-17407 > 18432-20479, 21504-23551, 25600-26591, > 26624-27647, 29696-30719, 31744-33791 > 35840-36863, 39936-40959, 46080-47103 > 53248-55295 > ARIN Address Blocks 3/8, 4/8, 6/8, 7/8, 8/8, 9/8, 11/8, > 12/8, 13/8, 15/8, 16/8, 17/8, 18/8, 19/8, > 20/8, 21/8, 22/8, 24/8, 26/8, 28/8, 29/8, > 30/8, 32/8, 33/8, 34/8, 35/8, 38/8, 40/8, > 44/8, 45/8, 47/8, 48/8, 52/8, 54/8, 55/8, > 56/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, > 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, > 76/8, 96/8, 97/8, 98/8, 99/8, 108/8, 173/8, > 174/8, 184/8, 199/8, 204/8, 205/8, 206/8, 207/8, > 208/8, 209/8, 214/8, 215/8, 216/8, > > RIPE Region Analysis Summary > ---------------------------- > > Prefixes being announced by RIPE Region ASes: 67087 > Total RIPE prefixes after maximum aggregation: 39643 > RIPE Deaggregation factor: 1.69 > Prefixes being announced from the RIPE address blocks: 66684 > Unique aggregates announced from the RIPE address blocks: 44964 > RIPE Region origin ASes present in the Internet Routing Table: 13340 > RIPE Prefixes per ASN: 5.00 > RIPE Region origin ASes announcing only one prefix: 6980 > RIPE Region transit ASes present in the Internet Routing Table: 1995 > Average RIPE Region AS path length visible: 4.0 > Max RIPE Region AS path length visible: 21 > Number of RIPE addresses announced to Internet: 498967744 > Equivalent to 29 /8s, 189 /16s and 164 /24s > Percentage of available RIPE address space announced: 99.1 > > RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 > (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 > 6656-6911, 8192-9215, 12288-13311, 15360-16383 > 20480-21503, 24576-25599, 28672-29695 > 30720-31743, 33792-35839, 38912-39935 > 40960-45055, 47104-52223 > RIPE Address Blocks 25/8, 51/8, 62/8, 77/8, 78/8, 79/8, 80/8, > 81/8, 82/8, 83/8, 84/8, 85/8, 86/8, 87/8, > 88/8, 89/8, 90/8, 91/8, 92/8, 93/8, 94/8, > 95/8, 109/8, 178/8, 193/8, 194/8, 195/8, 212/8, > 213/8, 217/8, > > LACNIC Region Analysis Summary > ------------------------------ > > Prefixes being announced by LACNIC Region ASes: 24832 > Total LACNIC prefixes after maximum aggregation: 6078 > LACNIC Deaggregation factor: 4.09 > Prefixes being announced from the LACNIC address blocks: 24789 > Unique aggregates announced from the LACNIC address blocks: 13736 > LACNIC Region origin ASes present in the Internet Routing Table: 1147 > LACNIC Prefixes per ASN: 21.61 > LACNIC Region origin ASes announcing only one prefix: 367 > LACNIC Region transit ASes present in the Internet Routing Table: 192 > Average LACNIC Region AS path length visible: 4.0 > Max LACNIC Region AS path length visible: 23 > Number of LACNIC addresses announced to Internet: 72874176 > Equivalent to 4 /8s, 87 /16s and 248 /24s > Percentage of available LACNIC address space announced: 72.4 > > LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247 > plus ERX transfers > LACNIC Address Blocks 186/8, 187/8, 189/8, 190/8, 200/8, 201/8, > > AfriNIC Region Analysis Summary > ------------------------------- > > Prefixes being announced by AfriNIC Region ASes: 6163 > Total AfriNIC prefixes after maximum aggregation: 1482 > AfriNIC Deaggregation factor: 4.16 > Prefixes being announced from the AfriNIC address blocks: 6569 > Unique aggregates announced from the AfriNIC address blocks: 2514 > AfriNIC Region origin ASes present in the Internet Routing Table: 299 > AfriNIC Prefixes per ASN: 21.97 > AfriNIC Region origin ASes announcing only one prefix: 82 > AfriNIC Region transit ASes present in the Internet Routing Table: 61 > Average AfriNIC Region AS path length visible: 3.8 > Max AfriNIC Region AS path length visible: 16 > Number of AfriNIC addresses announced to Internet: 20273152 > Equivalent to 1 /8s, 53 /16s and 88 /24s > Percentage of available AfriNIC address space announced: 60.4 > > AfriNIC AS Blocks 36864-37887 & ERX transfers > AfriNIC Address Blocks 41/8, 197/8, > > APNIC Region per AS prefix count summary > ---------------------------------------- > > ASN No of nets /20 equiv MaxAgg Description > 4766 1714 6976 419 Korea Telecom (KIX) > 17488 1543 137 103 Hathway IP Over Cable Interne > 4755 1227 292 145 TATA Communications formerly > 9583 1114 87 548 Sify Limited > 4134 980 17389 381 CHINANET-BACKBONE > 7545 807 198 101 TPG Internet Pty Ltd > 9829 807 619 15 BSNL National Internet Backbo > 23577 785 34 666 Korea Telecom (ATM-MPLS) > 4808 754 1515 172 CNCGROUP IP network: China169 > 18101 750 201 32 Reliance Infocom Ltd Internet > > Complete listing at http://thyme.apnic.net/current/data-ASnet-APNIC > > ARIN Region per AS prefix count summary > --------------------------------------- > > ASN No of nets /20 equiv MaxAgg Description > 6389 4224 3643 323 bellsouth.net, inc. > 4323 1912 1048 386 Time Warner Telecom > 1785 1719 714 138 PaeTec Communications, Inc. > 7018 1511 5907 1047 AT&T WorldNet Services > 20115 1428 1464 679 Charter Communications > 2386 1265 669 921 AT&T Data Communications Serv > 6478 1249 274 302 AT&T Worldnet Services > 3356 1201 10963 443 Level 3 Communications, LLC > 11492 1129 208 12 Cable One > 22773 1079 2604 66 Cox Communications, Inc. > > Complete listing at http://thyme.apnic.net/current/data-ASnet-ARIN > > RIPE Region per AS prefix count summary > --------------------------------------- > > ASN No of nets /20 equiv MaxAgg Description > 30890 483 92 195 Evolva Telecom > 12479 470 578 6 Uni2 Autonomous System > 3292 460 1905 395 TDC Tele Danmark > 702 430 1861 346 UUNET - Commercial IP service > 9198 367 138 12 Kazakhtelecom Data Network Ad > 3320 353 7083 306 Deutsche Telekom AG > 3301 347 1684 310 TeliaNet Sweden > 3215 344 3081 109 France Telecom Transpac > 8866 335 109 20 Bulgarian Telecommunication C > 8551 310 290 38 Bezeq International > > Complete listing at http://thyme.apnic.net/current/data-ASnet-RIPE > > LACNIC Region per AS prefix count summary > ----------------------------------------- > > ASN No of nets /20 equiv MaxAgg Description > 8151 1504 2898 245 UniNet S.A. de C.V. > 10620 964 220 107 TVCABLE BOGOTA > 28573 637 579 41 NET Servicos de Comunicao S.A > 7303 601 320 94 Telecom Argentina Stet-France > 22047 539 302 14 VTR PUNTO NET S.A. > 11830 489 310 54 Instituto Costarricense de El > 11172 443 99 69 Servicios Alestra S.A de C.V > 6471 421 96 31 ENTEL CHILE S.A. > 7738 410 858 29 Telecomunicacoes da Bahia S.A > 3816 386 189 80 Empresa Nacional de Telecomun > > Complete listing at http://thyme.apnic.net/current/data-ASnet-LACNIC > > AfriNIC Region per AS prefix count summary > ------------------------------------------ > > ASN No of nets /20 equiv MaxAgg Description > 8452 1025 188 7 TEDATA > 24863 908 90 48 LINKdotNET AS number > 20858 324 34 5 EgyNet > 3741 277 856 237 The Internet Solution > 2018 245 215 143 Tertiary Education Network > 6713 176 166 16 Itissalat Al-MAGHRIB > 33783 152 10 8 EEPAD TISP TELECOM & INTERNET > 24835 138 46 9 RAYA Telecom - Egypt > 29571 138 14 6 Ci Telecom Autonomous system > 5536 123 8 9 Internet Egypt Network > > Complete listing at http://thyme.apnic.net/current/data-ASnet-AFRINIC > > Global Per AS prefix count summary > ---------------------------------- > > ASN No of nets /20 equiv MaxAgg Description > 6389 4224 3643 323 bellsouth.net, inc. > 4323 1912 1048 386 Time Warner Telecom > 1785 1719 714 138 PaeTec Communications, Inc. > 4766 1714 6976 419 Korea Telecom (KIX) > 17488 1543 137 103 Hathway IP Over Cable Interne > 7018 1511 5907 1047 AT&T WorldNet Services > 8151 1504 2898 245 UniNet S.A. de C.V. > 20115 1428 1464 679 Charter Communications > 2386 1265 669 921 AT&T Data Communications Serv > 6478 1249 274 302 AT&T Worldnet Services > > Complete listing at http://thyme.apnic.net/current/data-ASnet > > Global Per AS Maximum Aggr summary > ---------------------------------- > > ASN No of nets Net Savings Description > 1785 1719 1581 PaeTec Communications, Inc. > 4323 1912 1526 Time Warner Telecom > 17488 1543 1440 Hathway IP Over Cable Interne > 4766 1714 1295 Korea Telecom (KIX) > 8151 1504 1259 UniNet S.A. de C.V. > 11492 1129 1117 Cable One > 4755 1227 1082 TATA Communications formerly > 18566 1062 1052 Covad Communications > 8452 1025 1018 TEDATA > 22773 1079 1013 Cox Communications, Inc. > > Complete listing at http://thyme.apnic.net/current/data-CIDRnet > > List of Unregistered Origin ASNs (Global) > ----------------------------------------- > > Bad AS Designation Network Transit AS Description > 16927 UNALLOCATED 12.0.252.0/23 7018 AT&T WorldNet > Servic > 15132 UNALLOCATED 12.9.150.0/24 7018 AT&T WorldNet > Servic > 32567 UNALLOCATED 12.14.170.0/24 7018 AT&T WorldNet > Servic > 13746 UNALLOCATED 12.24.56.0/24 7018 AT&T WorldNet > Servic > 32567 UNALLOCATED 12.25.107.0/24 7018 AT&T WorldNet > Servic > 26973 UNALLOCATED 12.39.152.0/24 7018 AT&T WorldNet > Servic > 26973 UNALLOCATED 12.39.154.0/23 7018 AT&T WorldNet > Servic > 26973 UNALLOCATED 12.39.159.0/24 7018 AT&T WorldNet > Servic > 32326 UNALLOCATED 12.40.49.0/24 7018 AT&T WorldNet > Servic > 25639 UNALLOCATED 12.41.169.0/24 7018 AT&T WorldNet > Servic > > Complete listing at http://thyme.apnic.net/current/data-badAS > > Advertised Unallocated Addresses > -------------------------------- > > Network Origin AS Description > 41.223.92.0/22 36936 >>UNKNOWN<< > 41.223.112.0/22 5713 Telkom SA Ltd > 41.223.176.0/22 36981 >>UNKNOWN<< > 41.223.188.0/24 22351 Intelsat > 41.223.189.0/24 26452 Local Communications Networks > 62.61.220.0/24 24974 Tachyon Europe BV - Wireless > 62.61.221.0/24 24974 Tachyon Europe BV - Wireless > 63.140.213.0/24 22555 Universal Talkware Corporatio > 63.143.251.0/24 22555 Universal Talkware Corporatio > 64.31.32.0/19 11955 ServiceCo LLC - Road Runner > > Complete listing at http://thyme.apnic.net/current/data-add-IANA > > Number of prefixes announced per prefix length (Global) > ------------------------------------------------------- > > /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 > /7:0 /8:19 /9:10 /10:24 /11:58 /12:169 > /13:350 /14:619 /15:1171 /16:10574 /17:4763 /18:8324 > /19:17206 /20:20600 /21:20446 /22:26358 /23:26224 /24:153360 > /25:904 /26:1027 /27:574 /28:157 /29:8 /30:7 > /31:1 /32:8 > > Advertised prefixes smaller than registry allocations > ----------------------------------------------------- > > ASN No of nets Total ann. Description > 6389 2740 4224 bellsouth.net, inc. > 4766 1400 1714 Korea Telecom (KIX) > 17488 1290 1543 Hathway IP Over Cable Interne > 1785 1189 1719 PaeTec Communications, Inc. > 11492 1055 1129 Cable One > 18566 1043 1062 Covad Communications > 4323 967 1912 Time Warner Telecom > 9583 967 1114 Sify Limited > 8452 947 1025 TEDATA > 10620 872 964 TVCABLE BOGOTA > > Complete listing at http://thyme.apnic.net/current/data-sXXas-nos > > Number of /24s announced per /8 block (Global) > ---------------------------------------------- > > 4:14 8:210 12:2134 13:7 15:19 16:3 > 17:5 20:35 24:1111 32:52 34:2 38:583 > 40:98 41:1721 43:1 44:2 47:22 52:6 > 53:2 55:2 56:2 57:24 58:597 59:649 > 60:462 61:1081 62:1111 63:2004 64:3704 65:2407 > 66:3583 67:1680 68:860 69:2731 70:550 71:152 > 72:1652 73:2 74:1644 75:175 76:340 77:849 > 78:586 79:355 80:955 81:852 82:591 83:453 > 84:634 85:1063 86:372 87:670 88:373 89:1479 > 90:50 91:2425 92:384 93:1090 94:1107 95:1194 > 96:157 97:240 98:256 99:28 110:168 111:365 > 112:117 113:147 114:241 115:350 116:1119 117:555 > 118:338 119:757 120:147 121:782 122:1056 123:685 > 124:980 125:1377 128:225 129:222 130:128 131:414 > 132:74 133:10 134:186 135:43 136:224 137:165 > 138:167 139:82 140:446 141:123 142:384 143:377 > 144:361 145:48 146:390 147:152 148:529 149:221 > 150:206 151:193 152:145 153:148 154:2 155:275 > 156:167 157:301 158:118 159:343 160:289 161:156 > 162:272 163:165 164:474 165:515 166:466 167:361 > 168:709 169:176 170:481 171:41 172:10 173:324 > 174:269 178:1 180:4 186:109 187:145 188:350 > 189:573 190:2941 192:5790 193:4259 194:3298 195:2692 > 196:1127 198:3641 199:3363 200:5133 201:1285 202:7740 > 203:8287 204:3892 205:2135 206:2443 207:2737 208:3893 > 209:3449 210:2534 211:1106 212:1662 213:1618 214:80 > 215:29 216:4550 217:1365 218:405 219:450 220:1104 > 221:479 222:328 > > End of report > > From zartash at gmail.com Sun Aug 2 19:04:30 2009 From: zartash at gmail.com (Zartash Uzmi) Date: Mon, 3 Aug 2009 05:04:30 +0500 Subject: What is the most standard subnet length on internet In-Reply-To: <3F0B70F6-A8B2-4599-8441-2EB4A661E852@ianai.net> References: <200812191548.mBJFmoFP029058@aurora.sol.net> <3F0B70F6-A8B2-4599-8441-2EB4A661E852@ianai.net> Message-ID: <4fff97de0908021704n148676d4m6551b6f36be9f819@mail.gmail.com> Since this old thread recently became alive (momentarily), and I read through the posts, (perhaps, again!) ... Patrick, I would like to understand why you said that routers handling 10G traffic in DFZ are not bothered (much) by a few extra prefixes? Isn't this counter-intuitive? For example, for the worst case packet size of 40 bytes, a router has only 32ns to completely process a packet (including lookup!) in order to support 10Gb/s line rates. The higher rates leave with even smaller time, which makes me think that it's the "slow running" routers that should not be bothered *much* by a small increase in the number of prefixes. Or, were you referring to 10G routers "slow running" by comparing them with 100G routers? I do not except anyone to have such a long memory, so you may want to skim through the following :) Zartash On Sat, Dec 20, 2008 at 9:37 AM, Patrick W. Gilmore wrote: > On Dec 19, 2008, at 10:48 AM, Joe Greco wrote: > > As for routing table size, no router which can handle 10s of Gbps is >>> at all bothered by the size of the global table, >>> >> >> ... as long as it isn't something like a Cisco Catalyst 6509 with SUP720 >> and doesn't have a PFC3BXL helping out ... >> >> ... or if we conveniently don't classify a Catalyst 65xx as a router >> because it was primarily intended as a switch, despite how ISP's commonly >> use them ... >> >> so only edge devices >>> or stub networks are in danger of needing to filter /24s. And both of >>> those can (should?) have something called a "default route", making it >>> completely irrelevant whether they hear the /24s anyway. >>> >> >> A more accurate statement is probably that "any router that can handle >> 10s of Gbps is likely to be available in a configuration that is not at >> all bothered by the current size of the global table, most likely at some >> substantial additional cost." >> > > Good point! I should have said "10s of Gbps and tables associated with > default-free networks". > > Or are there lots of people using 6500s without 3BXLs in the DFZ? I admit > I have not audited every router in the DFZ, so perhaps someone with factual > info can help out here. > > If not, then we're back to where we started. The DFZ isn't worried about > table size this cycle, and the edges can (should?) have default. I'm sure > that will change in a couple years, but everything always does. > > Oh, and before anyone jumps all over me, I am NOT implying you should > deaggregate and blow up the table. Just that 300K prefixes is the DFZ is > not a reason to start filtering /24s. Today. :) > > -- > TTFN, > patrick > > > From vixie at isc.org Mon Aug 3 10:30:34 2009 From: vixie at isc.org (Paul Vixie) Date: Mon, 03 Aug 2009 15:30:34 +0000 Subject: Fwd: Dan Kaminsky In-Reply-To: <4A722FFA.9080905@gmail.com> (William Allen Simpson's message of "Thu\, 30 Jul 2009 19\:42\:50 -0400") References: <4b6ee9310907291453y6da24d19l21cc5345bd8f08a2@mail.gmail.com> <21537.1248973777@turing-police.cc.vt.edu> <4A722FFA.9080905@gmail.com> Message-ID: William Allen Simpson writes: > Are we paying enough attention to securing our systems? almost certainly not. skimming RFC 2196 again just now i find three things. 1. it's out of date and needs a refresh -- yo barb! 2. i'm not doing about half of what it recommends 3. my users complain bitterly about the other half in terms of cost:benefit, it's more and more the case that outsourcing looks cheaper than doing the job correctly in-house. not because outsourcing *is* more secure but because it gives the user somebody to sue rather than fire, where a lawsuit could recover some losses and firing someone usually won't. digital security is getting a lot of investor attention right now. i wonder if this will ever consolidate or if pandora's box is just broken for all time. -- Paul Vixie KI6YSY From davei at otd.com Mon Aug 3 10:45:41 2009 From: davei at otd.com (Dave Israel) Date: Mon, 03 Aug 2009 11:45:41 -0400 Subject: Fwd: Dan Kaminsky In-Reply-To: References: <4b6ee9310907291453y6da24d19l21cc5345bd8f08a2@mail.gmail.com> <21537.1248973777@turing-police.cc.vt.edu> <4A722FFA.9080905@gmail.com> Message-ID: <4A770625.2030404@otd.com> Paul Vixie wrote: > digital security is getting a lot of investor attention right now. i wonder > if this will ever consolidate or if pandora's box is just broken for all time. > It'll consolidate to the point where probabilities and probably costs can be accurately assessed, at which point it can be insured, and that's where it'll level off. From chandler.bassett at gmail.com Mon Aug 3 12:50:03 2009 From: chandler.bassett at gmail.com (Chandler Bassett) Date: Mon, 3 Aug 2009 13:50:03 -0400 Subject: Verizon Wireless Engineer Message-ID: Greetings, Can a Verizon Engineer contact me off list in regards to their 3G Air Cards? Thanks much. - Chandler From zartash at gmail.com Mon Aug 3 15:38:37 2009 From: zartash at gmail.com (Zartash Uzmi) Date: Tue, 4 Aug 2009 01:38:37 +0500 Subject: Fwd: Weekly Routing Table Report In-Reply-To: <200908031056.18246.mtinka@globaltransit.net> References: <200907311812.n6VICtpS019420@thyme.apnic.net> <4fff97de0908021629r6884c40erbd97f423ea9d6472@mail.gmail.com> <200908031056.18246.mtinka@globaltransit.net> Message-ID: <4fff97de0908031338s6f87144dq58ae188a1a2e7f9@mail.gmail.com> A response I received from Mark Tinka on afnog mailing list. Reposting for the nanog community: ---------- Forwarded message ---------- From: Mark Tinka Date: Mon, Aug 3, 2009 at 7:55 AM Subject: Re: Weekly Routing Table Report To: Zartash Uzmi Cc: pfs at cisco.com, afnog at afnog.org On Monday 03 August 2009 07:29:28 am Zartash Uzmi wrote: > Apologies if this is too naive to ask... Any question is a good question. > but is there some > detail available about the items listed in the summary? This is probably the link you seek: http://thyme.apnic.net/about.html > 1) In particular, what exactly is the difference between > the "BGP routing table entries examined (292961)" and > "Unique aggregates announced to Internet (145391)"? What this tells us is, assuming all routing entries "currently" present in the routing table (as seen by the infrastructure that enables this weekly CIDR report) were aggregated, the maximum number of routing entries, as at the point this report was generated, would be 145,391; just a little shy of half what we're seeing today. > 2) I believe 292961 is the worst case routing table size > for any router. Well, different networks will see slightly different views (more or less), but yes, the average number each DFZ (default-free zone) is seeing would be just about there. But if you mean the number of routing entries each router can support, then that's a different issue. This depends on a number of factors, particularly, the router's architecture. Software-based routers will, generally, hold as many routing entries as the amount of RAM they have can support. A number of software-based routers today support 2GB of RAM, e.g., Cisco's 7201 or 7206-VXR/NPE-G2, or Juniper's J4350 and J6350 routers. The limitation, obviously, is because packet forwarding occurs in the CPU path (a software Interrupt process, hence the name, "software-based routers"), there is a finite amount of traffic software-based platforms can forward, especially with other features enabled, before they run out of ideas, so to speak :-). Hardware-based routers, on the other hand, segment the process of handling routing entries and forwarding traffic, in a somewhat distributed fashion. Hardware-based routers typically have what are known as control planes and data planes. Control planes handle management and such house- keeping functions, which includes BGP. This function is generally similar to what you see in software-based routers, in that RAM is abundant (up to 4GB in today's largest systems) to hold as many routing entries from as many paths as possible. Where hardware-based routers differ from their software- based cousins is how routing entries are used to forward traffic. Once BGP has chosen the best path to all destinations in the control plane, those best paths are then "downloaded", if you will, to the router's data plane, which is normally a special chip that has a single function - forward traffic as quickly as possible. Dumb, but very efficient. The vendors call these ASIC's (Application Specific Integrated Circuits) or Programmable Chips. These ASIC's or Programmable Chips usually hold only one routing entry at a time, even though the control plane can have several copies of the same routing entry, as seen from multiple BGP paths. These ASIC's/Programmable Chips use expensive, specialized memory to hold these entries; it could be TCAM (Ternary Content Addressable Memory), SSRAM (Synchronous Static RAM), RLDRAM (Reduced Latency DRAM), e.t.c. These are high-speed types of memory that are built, in most cases, for networking applications, e.g., routers, switches, e.t.c., and work at very high bandwidths, supporting high-speed route entry look-ups, which allows hardware-based routers to forward traffic at the speeds they do, e.g, 1Gbps, 10Gbps, 40Gbps, e.t.c. The reason I brought this up is because the explosion of the IPv4 Internet routing table is putting pressure on routers, more specifically, hardware-based routers. This is because TCAM, SSRAM, RLDRAM, e.t.c., is very expensive, and as such, has a finite number of entries they can hold (I say entries because on some platforms, entries includes IPv4 routes, IPv6 routes, MPLS LSP's, ACL's, NetFlow data, e.t.c.). Upgrading these means swapping out expensive data plane infrastructure, which many service providers would like to avoid, if at all possible. > If the unique aggregates announced to the > Internet is 145391, how does the routing table size > anywhere may exceeds this number? For the very reasons we receive this report on a regular basis, to remind us of what we could do to reduce the pollution of the routing table, and hence, increase the lifetime of the (powerful?) routers we have in the network that can no longer serve us because they can't hold anymore routing entries without falling over. I wouldn't do Philip Smith's live presentation of the state of the Internet routing table any justice by trying to explain it here :-), but basically, we see about 50% more routing entries than we should mainly due to de-aggregation. This happens for a number of reasons, but one of the main ones is traffic engineering, where networks announce longer versions of their prefixes in order to balance inbound traffic to their network. This is usually a noble, commercially-driven decision, but with the side effects explained above. Cake, eat, both... :-). > 3) Is aggregation done at a particular router for (i) > reducing the table size in that router, or (ii) reducing > the number of announced prefixes by that router, or (iii) > both? Border and peering routers are generally the ones that face the world. They connect to the Internet either by purchasing transit from upstream providers, or peering with other networks privately or at public exchange points. Aggregation is typically done inside your network, but whatever the case, the prefixes that these routers announce to the outside should, ideally, be aggregates of the allocations a network receives from its RIR. Different networks implement this differently, e.g., some networks configure and announce aggregates on their border and peering routers, while others, like us, do the same on the route reflectors, which I think scales better if you have multiple border and peering routers spread across the network. But as you can tell, this is an internal design issue - the end goal is to announce to the world only what you need to announce to the world, and hopefully, keep the Internet routing table lean & mean. Hope this helps. Cheers, Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 835 bytes Desc: not available URL: From ras at e-gerbil.net Mon Aug 3 20:02:35 2009 From: ras at e-gerbil.net (Richard A Steenbergen) Date: Mon, 3 Aug 2009 20:02:35 -0500 Subject: Dan Kaminsky In-Reply-To: References: <4b6ee9310907291453y6da24d19l21cc5345bd8f08a2@mail.gmail.com> <4A711E00.7030602@trelane.net> <7C332C86-7E7C-4C4E-8ADD-61310CA0758C@kyx.net> <4b6ee9310908010810w50796caenac7471b94fac1792@mail.gmail.com> Message-ID: <20090804010235.GT51443@gerbil.cluepon.net> On Sat, Aug 01, 2009 at 01:11:17PM -0700, Cord MacLeod wrote: > I don't see a video attached or an audio recording. Thus no slander. > > Libel on the other hand is a different matter. You have those backwards. Slander is transitory (i.e. spoken) defamation, libel is written/recorded/etc non-transitory defamation. This seems like a group that could benefit from knowing those two words. :) -- Richard A Steenbergen http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) From cordmacleod at gmail.com Mon Aug 3 21:07:03 2009 From: cordmacleod at gmail.com (Cord MacLeod) Date: Mon, 3 Aug 2009 19:07:03 -0700 Subject: Dan Kaminsky In-Reply-To: <20090804010235.GT51443@gerbil.cluepon.net> References: <4b6ee9310907291453y6da24d19l21cc5345bd8f08a2@mail.gmail.com> <4A711E00.7030602@trelane.net> <7C332C86-7E7C-4C4E-8ADD-61310CA0758C@kyx.net> <4b6ee9310908010810w50796caenac7471b94fac1792@mail.gmail.com> <20090804010235.GT51443@gerbil.cluepon.net> Message-ID: <07528455-5BC2-4FD1-9A96-3F712A573B36@gmail.com> Read my post one more time... The standards you described are what I described. No video, no audio = no speech = no slander. The article was written, hence libel. On Aug 3, 2009, at 6:02 PM, Richard A Steenbergen wrote: > On Sat, Aug 01, 2009 at 01:11:17PM -0700, Cord MacLeod wrote: >> I don't see a video attached or an audio recording. Thus no slander. >> >> Libel on the other hand is a different matter. > > You have those backwards. Slander is transitory (i.e. spoken) > defamation, libel is written/recorded/etc non-transitory defamation. > This seems like a group that could benefit from knowing those two > words. > :) > > -- > Richard A Steenbergen http://www.e-gerbil.net/ras > GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 > 2CBC) From simon.allard at team.orcon.net.nz Mon Aug 3 21:54:56 2009 From: simon.allard at team.orcon.net.nz (Simon Allard) Date: Tue, 4 Aug 2009 14:54:56 +1200 Subject: caches for peer-to-peer trafic In-Reply-To: <949b74980908010806s62c78ccbq349e90d09db14694@mail.gmail.com> References: <949b74980907300216j5300dd26rd13ffba1bb48bb48@mail.gmail.com> <949b74980908010806s62c78ccbq349e90d09db14694@mail.gmail.com> Message-ID: PeerApp are very good Also caches video (youtube/FLV etc). -----Original Message----- From: Murtaza [mailto:leothelion.murtaza at gmail.com] Sent: Sunday, 2 August 2009 3:07 a.m. To: Charles Gucker Cc: nanog at nanog.org Subject: Re: caches for peer-to-peer trafic Guys! Thank you very much for your responses. Anymore responses will also be very much appreciated. On Fri, Jul 31, 2009 at 6:00 PM, Charles Gucker wrote: > Sandvine Thanks and Regards, Ghulam Murtaza PhD Student, Lahore University of Management Sciences From andrew.wallace at rocketmail.com Mon Aug 3 23:43:18 2009 From: andrew.wallace at rocketmail.com (andrew.wallace) Date: Tue, 4 Aug 2009 05:43:18 +0100 Subject: Dan Kaminsky In-Reply-To: <20090804010235.GT51443@gerbil.cluepon.net> References: <4b6ee9310907291453y6da24d19l21cc5345bd8f08a2@mail.gmail.com> <4A711E00.7030602@trelane.net> <7C332C86-7E7C-4C4E-8ADD-61310CA0758C@kyx.net> <4b6ee9310908010810w50796caenac7471b94fac1792@mail.gmail.com> <20090804010235.GT51443@gerbil.cluepon.net> Message-ID: <4b6ee9310908032143t1737ab53lf0883929f6c118df@mail.gmail.com> Hi, Read my post one more time and think though: Only "zf0" are legally in the shit. The guy "Dragos Ruiu" has absolutely no case against me. Copy & paste doesn't count as defamation, speak to Wired's legal team if you have an issue. Cheers, Andrew On Tue, Aug 4, 2009 at 2:02 AM, Richard A Steenbergen wrote: > On Sat, Aug 01, 2009 at 01:11:17PM -0700, Cord MacLeod wrote: >> I don't see a video attached or an audio recording. ?Thus no slander. >> >> Libel on the other hand is a different matter. > > You have those backwards. Slander is transitory (i.e. spoken) > defamation, libel is written/recorded/etc non-transitory defamation. > This seems like a group that could benefit from knowing those two words. > :) > > -- > Richard A Steenbergen ? ? ? http://www.e-gerbil.net/ras > GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) > > From rbk at mnsginc.com Tue Aug 4 08:34:46 2009 From: rbk at mnsginc.com (R. Benjamin Kessler) Date: Tue, 4 Aug 2009 09:34:46 -0400 Subject: cisco.com Message-ID: <0B608FCDCF43BF4C9194C896C53202435D8D2A@mnsg-svr2.mnsg.net> Hey Gang - I'm unable to get to cisco.com from multiple places on the 'net (including downforeveryoneorjustme.com); any ideas on the cause and ETR? Thanks, Ben From nderitualex at gmail.com Tue Aug 4 08:42:16 2009 From: nderitualex at gmail.com (Alex Nderitu) Date: Tue, 04 Aug 2009 16:42:16 +0300 Subject: cisco.com In-Reply-To: <0B608FCDCF43BF4C9194C896C53202435D8D2A@mnsg-svr2.mnsg.net> References: <0B608FCDCF43BF4C9194C896C53202435D8D2A@mnsg-svr2.mnsg.net> Message-ID: <1249393336.4204.0.camel@sys-engineer> Facebook seems to also be affected. -----Original Message----- From: R. Benjamin Kessler To: nanog at nanog.org Subject: cisco.com Date: Tue, 4 Aug 2009 09:34:46 -0400 Hey Gang - I'm unable to get to cisco.com from multiple places on the 'net (including downforeveryoneorjustme.com); any ideas on the cause and ETR? Thanks, Ben -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From sauron at the-infinite.org Tue Aug 4 08:45:04 2009 From: sauron at the-infinite.org (Dominic J. Eidson) Date: Tue, 4 Aug 2009 08:45:04 -0500 (CDT) Subject: cisco.com In-Reply-To: <1249393336.4204.0.camel@sys-engineer> References: <0B608FCDCF43BF4C9194C896C53202435D8D2A@mnsg-svr2.mnsg.net> <1249393336.4204.0.camel@sys-engineer> Message-ID: Both work from Austin, TX. - d. On Tue, 4 Aug 2009, Alex Nderitu wrote: > Facebook seems to also be affected. > > > -----Original Message----- > From: R. Benjamin Kessler > To: nanog at nanog.org > Subject: cisco.com > Date: Tue, 4 Aug 2009 09:34:46 -0400 > > > Hey Gang - > > I'm unable to get to cisco.com from multiple places on the 'net > (including downforeveryoneorjustme.com); any ideas on the cause and ETR? > > Thanks, > > Ben > > > > -- Dominic J. Eidson "Baruk Khazad! Khazad ai-menu!" - Gimli ---------------------------------------------------------------------------- http://www.dominiceidson.com/ From aaron.millisor at bright.net Tue Aug 4 08:45:51 2009 From: aaron.millisor at bright.net (Aaron Millisor) Date: Tue, 04 Aug 2009 09:45:51 -0400 Subject: cisco.com In-Reply-To: <0B608FCDCF43BF4C9194C896C53202435D8D2A@mnsg-svr2.mnsg.net> References: <0B608FCDCF43BF4C9194C896C53202435D8D2A@mnsg-svr2.mnsg.net> Message-ID: <4A783B8F.1070206@bright.net> Not sure the ETA but the network that the address for cisco.com resolves to (198.133.219.0/24) is no longer in BGP. -- ----------------------------------------------------- Aaron Millisor R. Benjamin Kessler wrote: > Hey Gang - > > I'm unable to get to cisco.com from multiple places on the 'net > (including downforeveryoneorjustme.com); any ideas on the cause and ETR? > > Thanks, > > Ben > > From lists at kneipi.de Tue Aug 4 08:46:10 2009 From: lists at kneipi.de (Armin) Date: Tue, 04 Aug 2009 15:46:10 +0200 Subject: cisco.com In-Reply-To: <0B608FCDCF43BF4C9194C896C53202435D8D2A@mnsg-svr2.mnsg.net> References: <0B608FCDCF43BF4C9194C896C53202435D8D2A@mnsg-svr2.mnsg.net> Message-ID: <4A783BA2.8080106@kneipi.de> > I'm unable to get to cisco.com from multiple places on the 'net > (including downforeveryoneorjustme.com); any ideas on the cause and ETR? Here too ------ snip ------ core-01.fra1#sh ip bgp 198.133.219.25 BGP4 : None of the BGP4 routes match the display condition ------ snap ------ From deleskie at gmail.com Tue Aug 4 08:46:10 2009 From: deleskie at gmail.com (deleskie at gmail.com) Date: Tue, 4 Aug 2009 13:46:10 +0000 Subject: cisco.com Message-ID: <994263966-1249393584-cardhu_decombobulator_blackberry.rim.net-987275097-@bxe1156.bisx.prod.on.blackberry> Facebook up. Cisco down. From eastern canada ------Original Message------ From: Alex Nderitu To: R. Benjamin Kessler Cc: nanog at nanog.org Subject: Re: cisco.com Sent: Aug 4, 2009 10:42 AM Facebook seems to also be affected. -----Original Message----- From: R. Benjamin Kessler To: nanog at nanog.org Subject: cisco.com Date: Tue, 4 Aug 2009 09:34:46 -0400 Hey Gang - I'm unable to get to cisco.com from multiple places on the 'net (including downforeveryoneorjustme.com); any ideas on the cause and ETR? Thanks, Ben -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. Sent from my BlackBerry device on the Rogers Wireless Network From jda at tapodi.net Tue Aug 4 08:47:51 2009 From: jda at tapodi.net (Jon Auer) Date: Tue, 4 Aug 2009 08:47:51 -0500 Subject: cisco.com In-Reply-To: <0B608FCDCF43BF4C9194C896C53202435D8D2A@mnsg-svr2.mnsg.net> References: <0B608FCDCF43BF4C9194C896C53202435D8D2A@mnsg-svr2.mnsg.net> Message-ID: See: https://puck.nether.net/pipermail/outages/2009-August/001386.html I do not have a route to that IP (198.133.219.25) in BGP either.. On Tue, Aug 4, 2009 at 8:34 AM, R. Benjamin Kessler wrote: > Hey Gang - > > I'm unable to get to cisco.com from multiple places on the 'net > (including downforeveryoneorjustme.com); any ideas on the cause and ETR? > > Thanks, > > Ben > > > From chris at uplogon.com Tue Aug 4 08:48:08 2009 From: chris at uplogon.com (Chris Gotstein) Date: Tue, 4 Aug 2009 08:48:08 -0500 (CDT) Subject: cisco.com In-Reply-To: References: <0B608FCDCF43BF4C9194C896C53202435D8D2A@mnsg-svr2.mnsg.net> <1249393336.4204.0.camel@sys-engineer> Message-ID: <7ab4d938bcf536ec9b6c7eef8192a5b1.squirrel@mail.uplogon.com> Seeing same issue from Chicago via Qwest and HE. > > Both work from Austin, TX. > > > > - d. > > On Tue, 4 Aug 2009, Alex Nderitu wrote: > >> Facebook seems to also be affected. >> >> >> -----Original Message----- >> From: R. Benjamin Kessler >> To: nanog at nanog.org >> Subject: cisco.com >> Date: Tue, 4 Aug 2009 09:34:46 -0400 >> >> >> Hey Gang - >> >> I'm unable to get to cisco.com from multiple places on the 'net >> (including downforeveryoneorjustme.com); any ideas on the cause and ETR? >> >> Thanks, >> >> Ben >> >> >> >> > > -- > Dominic J. Eidson > "Baruk Khazad! Khazad ai-menu!" - > Gimli > ---------------------------------------------------------------------------- > http://www.dominiceidson.com/ > > -- Chris Gotstein Sr Network Engineer UP Logon/Computer Connection UP 500 N Stephenson Ave Iron Mountain, MI 49801 Phone: 906-774-4847 Fax: 906-774-0335 chris at uplogon.com From sjk at sleepycatz.com Tue Aug 4 08:48:39 2009 From: sjk at sleepycatz.com (sjk) Date: Tue, 04 Aug 2009 08:48:39 -0500 Subject: cisco.com In-Reply-To: References: <0B608FCDCF43BF4C9194C896C53202435D8D2A@mnsg-svr2.mnsg.net> <1249393336.4204.0.camel@sys-engineer> Message-ID: <4A783C37.9060002@sleepycatz.com> We have seen the route for cisco withdrawn from 208 and 2828. Facebook seems fine Dominic J. Eidson wrote: > > Both work from Austin, TX. > > > > - d. > > On Tue, 4 Aug 2009, Alex Nderitu wrote: > >> Facebook seems to also be affected. >> >> >> -----Original Message----- >> From: R. Benjamin Kessler >> To: nanog at nanog.org >> Subject: cisco.com >> Date: Tue, 4 Aug 2009 09:34:46 -0400 >> >> >> Hey Gang - >> >> I'm unable to get to cisco.com from multiple places on the 'net >> (including downforeveryoneorjustme.com); any ideas on the cause and ETR? >> >> Thanks, >> >> Ben >> >> >> >> > From marc at let.de Tue Aug 4 08:50:27 2009 From: marc at let.de (Marc Manthey) Date: Tue, 4 Aug 2009 15:50:27 +0200 Subject: cisco.com In-Reply-To: <1249393336.4204.0.camel@sys-engineer> References: <0B608FCDCF43BF4C9194C896C53202435D8D2A@mnsg-svr2.mnsg.net> <1249393336.4204.0.camel@sys-engineer> Message-ID: <25782A27-7EFF-4655-8EFD-CFFF769C8096@let.de> Am 04.08.2009 um 15:42 schrieb Alex Nderitu: > Facebook seems to also be affected. facebook works fine from germany > > I'm unable to get to cisco.com from multiple places on the 'net > (including downforeveryoneorjustme.com); any ideas on the cause and > ETR? An error occurred while processing your request. Reference #97.520dd58.1249393745.3bb006 is #down Marc From deleskie at gmail.com Tue Aug 4 08:51:08 2009 From: deleskie at gmail.com (deleskie at gmail.com) Date: Tue, 4 Aug 2009 13:51:08 +0000 Subject: cisco.com Message-ID: <261698448-1249393881-cardhu_decombobulator_blackberry.rim.net-105432216-@bxe1156.bisx.prod.on.blackberry> So cisco has no BGP is that what I'm hearing... Oh the irony :) ------Original Message------ From: Aaron Millisor To: R. Benjamin Kessler Cc: nanog at nanog.org Subject: Re: cisco.com Sent: Aug 4, 2009 10:45 AM Not sure the ETA but the network that the address for cisco.com resolves to (198.133.219.0/24) is no longer in BGP. -- ----------------------------------------------------- Aaron Millisor R. Benjamin Kessler wrote: > Hey Gang - > > I'm unable to get to cisco.com from multiple places on the 'net > (including downforeveryoneorjustme.com); any ideas on the cause and ETR? > > Thanks, > > Ben > > Sent from my BlackBerry device on the Rogers Wireless Network From shon at unwiredbb.com Tue Aug 4 08:56:35 2009 From: shon at unwiredbb.com (Shon Elliott) Date: Tue, 04 Aug 2009 06:56:35 -0700 Subject: cisco.com In-Reply-To: <0B608FCDCF43BF4C9194C896C53202435D8D2A@mnsg-svr2.mnsg.net> References: <0B608FCDCF43BF4C9194C896C53202435D8D2A@mnsg-svr2.mnsg.net> Message-ID: <4A783E13.4020805@unwiredbb.com> can't get to cisco.com from here atm either, but can get to facebook. looks like facebook is now coming from ashburn, va. cisco dies within level3 for us, and for route-views.oregon-ix.net: 5 eugn-core1-gw.nero.net (207.98.64.161) [AS 3701] !H * !H don't see that address (198.133.219.25) in the global routing table either. show ip bgp 198.133.219.0 % Network not in table R. Benjamin Kessler wrote: > Hey Gang - > > I'm unable to get to cisco.com from multiple places on the 'net > (including downforeveryoneorjustme.com); any ideas on the cause and ETR? > > Thanks, > > Ben > > > From gmartine at ajax.opentransit.net Tue Aug 4 08:52:42 2009 From: gmartine at ajax.opentransit.net (German Martinez) Date: Tue, 4 Aug 2009 09:52:42 -0400 Subject: cisco.com In-Reply-To: References: <0B608FCDCF43BF4C9194C896C53202435D8D2A@mnsg-svr2.mnsg.net> Message-ID: <20090804135242.GA11802@ajax.opentransit.net> On Tue Aug 04, 2009, Jon Auer wrote: > See: https://puck.nether.net/pipermail/outages/2009-August/001386.html > I do not have a route to that IP (198.133.219.25) in BGP either.. Route is not longer in the routing table since (CET) 08/04 13:55:57 Withdraw 198.133.219.0/24> German -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From michal at krsek.cz Tue Aug 4 08:59:16 2009 From: michal at krsek.cz (Michal Krsek) Date: Tue, 04 Aug 2009 15:59:16 +0200 Subject: cisco.com In-Reply-To: References: <0B608FCDCF43BF4C9194C896C53202435D8D2A@mnsg-svr2.mnsg.net> Message-ID: <4A783EB4.7050009@krsek.cz> Same here in Prague (various upstreams in Central Europe) MK Jon Auer napsal(a): > See: https://puck.nether.net/pipermail/outages/2009-August/001386.html > I do not have a route to that IP (198.133.219.25) in BGP either.. > > On Tue, Aug 4, 2009 at 8:34 AM, R. Benjamin Kessler wrote: > >> Hey Gang - >> >> I'm unable to get to cisco.com from multiple places on the 'net >> (including downforeveryoneorjustme.com); any ideas on the cause and ETR? >> >> Thanks, >> >> Ben >> >> >> >> From jvanick at oaknet.com Tue Aug 4 08:59:41 2009 From: jvanick at oaknet.com (Jason Vanick) Date: Tue, 4 Aug 2009 08:59:41 -0500 Subject: cisco.com In-Reply-To: <7ab4d938bcf536ec9b6c7eef8192a5b1.squirrel@mail.uplogon.com> References: <0B608FCDCF43BF4C9194C896C53202435D8D2A@mnsg-svr2.mnsg.net><1249393336.4204.0.camel@sys-engineer> <7ab4d938bcf536ec9b6c7eef8192a5b1.squirrel@mail.uplogon.com> Message-ID: Same here via Verizon, Level3 and Comcast. Btw... all 3 resolve to the same 198.133.219.25 addr. -----Original Message----- From: Chris Gotstein [mailto:chris at uplogon.com] Sent: Tuesday, August 04, 2009 8:48 AM To: nanog at nanog.org Subject: Re: cisco.com Seeing same issue from Chicago via Qwest and HE. > > Both work from Austin, TX. > > > > - d. > > On Tue, 4 Aug 2009, Alex Nderitu wrote: > >> Facebook seems to also be affected. >> >> >> -----Original Message----- >> From: R. Benjamin Kessler >> To: nanog at nanog.org >> Subject: cisco.com >> Date: Tue, 4 Aug 2009 09:34:46 -0400 >> >> >> Hey Gang - >> >> I'm unable to get to cisco.com from multiple places on the 'net >> (including downforeveryoneorjustme.com); any ideas on the cause and ETR? >> >> Thanks, >> >> Ben >> >> >> >> > > -- > Dominic J. Eidson > "Baruk Khazad! Khazad ai-menu!" - > Gimli > ---------------------------------------------------------------------------- > http://www.dominiceidson.com/ > > -- Chris Gotstein Sr Network Engineer UP Logon/Computer Connection UP 500 N Stephenson Ave Iron Mountain, MI 49801 Phone: 906-774-4847 Fax: 906-774-0335 chris at uplogon.com From elmi at 4ever.de Tue Aug 4 09:01:52 2009 From: elmi at 4ever.de (Elmar K. Bins) Date: Tue, 4 Aug 2009 16:01:52 +0200 Subject: Smart hands in NYC area Message-ID: <20090804140152.GN43104@ronin.4ever.de> Hello friendly NANOGers, we'll have to move out of a colo in the NYC area (Verizon DC Elmsford) soon and I need two guys to disassemble half a rack full of equipment, pack the stuff securely and send it away in two batches (one within the US, one to Germany). Packing material needs to be brought, I suppose. The setup has been there for a while - unlikely Verizon kept the material. Can anyone refer me to a company that can help me there, or offer their own services? Thanks for your help, Elmar. From steve.rossen at gmail.com Tue Aug 4 09:03:27 2009 From: steve.rossen at gmail.com (Steve Rossen) Date: Tue, 4 Aug 2009 09:03:27 -0500 Subject: cisco.com In-Reply-To: <4A783C37.9060002@sleepycatz.com> References: <0B608FCDCF43BF4C9194C896C53202435D8D2A@mnsg-svr2.mnsg.net> <1249393336.4204.0.camel@sys-engineer> <4A783C37.9060002@sleepycatz.com> Message-ID: <1fffe9f20908040703m2d6a0bdbpd6986b4ebf447f8c@mail.gmail.com> Missing route on Internap also. Netraft shows cisco.com went down right at 12:00GMT. http://uptime.netcraft.com/perf/graph?site=www.cisco.com On Tue, Aug 4, 2009 at 8:48 AM, sjk wrote: > We have seen the route for cisco withdrawn from 208 and 2828. Facebook > seems fine > > Dominic J. Eidson wrote: >> >> Both work from Austin, TX. >> >> >> >> ?- d. >> >> On Tue, 4 Aug 2009, Alex Nderitu wrote: >> >>> Facebook seems to also be affected. >>> >>> >>> -----Original Message----- >>> From: R. Benjamin Kessler >>> To: nanog at nanog.org >>> Subject: cisco.com >>> Date: Tue, 4 Aug 2009 09:34:46 -0400 >>> >>> >>> Hey Gang - >>> >>> I'm unable to get to cisco.com from multiple places on the 'net >>> (including downforeveryoneorjustme.com); any ideas on the cause and ETR? >>> >>> Thanks, >>> >>> Ben >>> >>> >>> >>> >> > > From scott.wolfe at cybera.net Tue Aug 4 09:03:55 2009 From: scott.wolfe at cybera.net (Scott Wolfe) Date: Tue, 4 Aug 2009 09:03:55 -0500 Subject: cisco.com In-Reply-To: <4A783C37.9060002@sleepycatz.com> References: <0B608FCDCF43BF4C9194C896C53202435D8D2A@mnsg-svr2.mnsg.net> <1249393336.4204.0.camel@sys-engineer> <4A783C37.9060002@sleepycatz.com> Message-ID: <48FAC036AD7B7642BB2944FB9AE674A305651690@EXCHANGE.nashville.cybera.net> No route for 198.133.219.0/24 in 22820 from our upstream (3356 and 174). -Scott W -----Original Message----- From: sjk [mailto:sjk at sleepycatz.com] Sent: Tuesday, August 04, 2009 8:49 AM To: Dominic J. Eidson Cc: nanog at nanog.org Subject: Re: cisco.com We have seen the route for cisco withdrawn from 208 and 2828. Facebook seems fine Dominic J. Eidson wrote: > > Both work from Austin, TX. > > > > - d. > > On Tue, 4 Aug 2009, Alex Nderitu wrote: > >> Facebook seems to also be affected. >> >> >> -----Original Message----- >> From: R. Benjamin Kessler >> To: nanog at nanog.org >> Subject: cisco.com >> Date: Tue, 4 Aug 2009 09:34:46 -0400 >> >> >> Hey Gang - >> >> I'm unable to get to cisco.com from multiple places on the 'net >> (including downforeveryoneorjustme.com); any ideas on the cause and ETR? >> >> Thanks, >> >> Ben >> >> >> >> > -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 475 bytes Desc: not available URL: From giuseppe.spano at vpsat.it Tue Aug 4 09:04:38 2009 From: giuseppe.spano at vpsat.it (=?ISO-8859-15?Q?Giuseppe_Span=F2_-_Videopi=F9_Srl?=) Date: Tue, 04 Aug 2009 16:04:38 +0200 Subject: cisco.com In-Reply-To: <994263966-1249393584-cardhu_decombobulator_blackberry.rim.net-987275097-@bxe1156.bisx.prod.on.blackberry> References: <994263966-1249393584-cardhu_decombobulator_blackberry.rim.net-987275097-@bxe1156.bisx.prod.on.blackberry> Message-ID: <4A783FF6.2080901@vpsat.it> Hi everyone, same issue from Italy, via Fastweb and Retelit. deleskie at gmail.com ha scritto: > Facebook up. Cisco down. From eastern canada > > From jmamodio at gmail.com Tue Aug 4 09:06:54 2009 From: jmamodio at gmail.com (Jorge Amodio) Date: Tue, 4 Aug 2009 09:06:54 -0500 Subject: cisco.com In-Reply-To: <261698448-1249393881-cardhu_decombobulator_blackberry.rim.net-105432216-@bxe1156.bisx.prod.on.blackberry> References: <261698448-1249393881-cardhu_decombobulator_blackberry.rim.net-105432216-@bxe1156.bisx.prod.on.blackberry> Message-ID: <202705b0908040706x58e1f4a6tf791d3826066c51a@mail.gmail.com> FB up, Cisco down, from SATX (Time Warner Road Runner) J From jbayles at readytechs.com Tue Aug 4 09:08:45 2009 From: jbayles at readytechs.com (Jonathan Bayles) Date: Tue, 4 Aug 2009 10:08:45 -0400 Subject: cisco.com In-Reply-To: <25782A27-7EFF-4655-8EFD-CFFF769C8096@let.de> References: <0B608FCDCF43BF4C9194C896C53202435D8D2A@mnsg-svr2.mnsg.net> <1249393336.4204.0.camel@sys-engineer> <25782A27-7EFF-4655-8EFD-CFFF769C8096@let.de> Message-ID: <386FCF83D8086E4A89655E41CD3B53D317F42C78C9@rtexch01> Just watched the rviews via bgplay for the aforementioned /24, shows them converging from AT&T internet, to AT&T Worldnet, to Sprint + Globix, to AAAaaaaaaaaaah! -----Original Message----- From: Marc Manthey [mailto:marc at let.de] Sent: Tuesday, August 04, 2009 9:50 AM To: nanog at nanog.org Subject: Re: cisco.com Am 04.08.2009 um 15:42 schrieb Alex Nderitu: > Facebook seems to also be affected. facebook works fine from germany > > I'm unable to get to cisco.com from multiple places on the 'net > (including downforeveryoneorjustme.com); any ideas on the cause and > ETR? An error occurred while processing your request. Reference #97.520dd58.1249393745.3bb006 is #down Marc From nanog-post at rsuc.gweep.net Tue Aug 4 09:09:57 2009 From: nanog-post at rsuc.gweep.net (Joe Provo) Date: Tue, 4 Aug 2009 10:09:57 -0400 Subject: cisco.com In-Reply-To: <0B608FCDCF43BF4C9194C896C53202435D8D2A@mnsg-svr2.mnsg.net> References: <0B608FCDCF43BF4C9194C896C53202435D8D2A@mnsg-svr2.mnsg.net> Message-ID: <20090804140957.GA27300@gweep.net> On Tue, Aug 04, 2009 at 09:34:46AM -0400, R. Benjamin Kessler wrote: > Hey Gang - > > I'm unable to get to cisco.com from multiple places on the 'net > (including downforeveryoneorjustme.com); any ideas on the cause and ETR? Instead of the hoot-n-holler line, maybe check bgp? route-views.oregon-ix.net>sho ip bgp 198.133.219.25 BGP routing table entry for 198.133.219.0/24, version 8654975 Paths: (1 available, best #1, table Default-IP-Routing-Table) Not advertised to any peer 4826 7018 109 114.31.199.1 from 114.31.199.1 (114.31.199.1) Origin IGP, localpref 100, valid, external, best route-views.oregon-ix.net> route-server>sho ip bgp 198.133.219.0/24 BGP routing table entry for 198.133.219.0/24, version 11641505 Paths: (15 available, best #2, table Default-IP-Routing-Table) Flag: 0x24A0 Not advertised to any peer 7018 109, (received & used) 12.123.134.124 from 12.123.134.124 (12.123.134.124) Origin IGP, localpref 100, valid, external Community: 7018:2000 7018:32112 7018 109, (received & used) 12.123.1.236 from 12.123.1.236 (12.123.1.236) Origin IGP, localpref 100, valid, external, best Community: 7018:2000 7018:32112 7018 109, (received & used) 12.123.21.243 from 12.123.21.243 (12.123.21.243) Origin IGP, localpref 100, valid, external Community: 7018:2000 7018:32112 7018 109, (received & used) 12.123.13.241 from 12.123.13.241 (12.123.13.241) Origin IGP, localpref 100, valid, external Community: 7018:2000 7018:32112 7018 109, (received & used) 12.123.9.241 from 12.123.9.241 (12.123.9.241) Origin IGP, localpref 100, valid, external Community: 7018:2000 7018:32112 7018 109, (received & used) 12.123.145.124 from 12.123.145.124 (12.123.145.124) Origin IGP, localpref 100, valid, external Community: 7018:2000 7018:32112 7018 109, (received & used) 12.123.139.124 from 12.123.139.124 (12.123.139.124) Origin IGP, localpref 100, valid, external Community: 7018:2000 7018:32112 7018 109, (received & used) 12.123.142.124 from 12.123.142.124 (12.123.142.124) Origin IGP, localpref 100, valid, external Community: 7018:2000 7018:32112 7018 109, (received & used) 12.123.17.244 from 12.123.17.244 (12.123.17.244) Origin IGP, localpref 100, valid, external Community: 7018:2000 7018:32112 7018 109, (received & used) 12.123.5.240 from 12.123.5.240 (12.123.5.240) Origin IGP, localpref 100, valid, external Community: 7018:2000 7018:32112 7018 109, (received & used) 12.123.137.124 from 12.123.137.124 (12.123.137.124) Origin IGP, localpref 100, valid, external Community: 7018:2000 7018:32112 7018 109, (received & used) 12.123.33.249 from 12.123.33.249 (12.123.33.249) Origin IGP, localpref 100, valid, external Community: 7018:2000 7018:32112 7018 109, (received & used) 12.123.25.245 from 12.123.25.245 (12.123.25.245) Origin IGP, localpref 100, valid, external Community: 7018:2000 7018:32112 7018 109, (received & used) 12.123.45.252 from 12.123.45.252 (12.123.45.252) Origin IGP, localpref 100, valid, external Community: 7018:2000 7018:32112 7018 109, (received & used) 12.122.125.4 from 12.122.125.4 (12.122.125.4) Origin IGP, metric 411, localpref 100, valid, external route-server> http://onestepconsulting.org/communities/as7018/ doesn't indicate anything meaningful for those communities, so presumably they are internal. 109 appears to be properly originating, so ... -- RSUC / GweepNet / Spunk / FnB / Usenix / SAGE From jkrejci at usinternet.com Tue Aug 4 09:10:57 2009 From: jkrejci at usinternet.com (Justin Krejci) Date: Tue, 4 Aug 2009 09:10:57 -0500 Subject: cisco.com In-Reply-To: <25782A27-7EFF-4655-8EFD-CFFF769C8096@let.de> References: <0B608FCDCF43BF4C9194C896C53202435D8D2A@mnsg-svr2.mnsg.net><1249393336.4204.0.camel@sys-engineer> <25782A27-7EFF-4655-8EFD-CFFF769C8096@let.de> Message-ID: <413C993F95214DE883CC67D58A1683CF@usicorp.usinternet.com> The IP is back in BGP and the website is working for me now. From braaen at zcorum.com Tue Aug 4 09:13:13 2009 From: braaen at zcorum.com (Brian Raaen) Date: Tue, 04 Aug 2009 10:13:13 -0400 Subject: cisco.com In-Reply-To: <261698448-1249393881-cardhu_decombobulator_blackberry.rim.net-105432216-@bxe1156.bisx.prod.on.blackberry> References: <261698448-1249393881-cardhu_decombobulator_blackberry.rim.net-105432216-@bxe1156.bisx.prod.on.blackberry> Message-ID: <4A7841F9.1010607@zcorum.com> Maybe that has to do with the end of life notice they put for BGP. You can find the thread at https://puck.nether.net/pipermail/cisco-nsp/2009-August/062865.html deleskie at gmail.com wrote: > So cisco has no BGP is that what I'm hearing... Oh the irony :) > ------Original Message------ > From: Aaron Millisor > To: R. Benjamin Kessler > Cc: nanog at nanog.org > Subject: Re: cisco.com > Sent: Aug 4, 2009 10:45 AM > > Not sure the ETA but the network that the address for cisco.com resolves > to (198.133.219.0/24) is no longer in BGP. > > -- > ----------------------------------------------------- > Aaron Millisor > > > > > R. Benjamin Kessler wrote: > >> Hey Gang - >> >> I'm unable to get to cisco.com from multiple places on the 'net >> (including downforeveryoneorjustme.com); any ideas on the cause and ETR? >> >> Thanks, >> >> Ben >> >> >> > > > > Sent from my BlackBerry device on the Rogers Wireless Network > > -- ----------------- Brian Raaen Network Engineer email: /braaen at zcorum.com/ Telephone /678-507-5000x5574/ -------------- next part -------------- A non-text attachment was scrubbed... Name: braaen.vcf Type: text/x-vcard Size: 206 bytes Desc: not available URL: From cmaurand at xyonet.com Tue Aug 4 09:16:32 2009 From: cmaurand at xyonet.com (Curtis Maurand) Date: Tue, 04 Aug 2009 10:16:32 -0400 Subject: cisco.com In-Reply-To: <4A783E13.4020805@unwiredbb.com> References: <0B608FCDCF43BF4C9194C896C53202435D8D2A@mnsg-svr2.mnsg.net> <4A783E13.4020805@unwiredbb.com> Message-ID: <4A7842C0.7080801@xyonet.com> I'm reaching them from Time-Warner in Portland, Maine. 1 <1 ms <1 ms <1 ms 10.0.1.10 2 1 ms <1 ms <1 ms rrcs-24-39-42-66.nys.biz.rr.com [24.39.42.66] 3 3 ms 1 ms 1 ms rrcs-24-39-42-65.nys.biz.rr.com [24.39.42.65] 4 5 ms 3 ms 4 ms ten1-1-1.ptldmecny-pe01.nyroc.rr.com [24.24.21.145] 5 10 ms 9 ms 8 ms ten2-1-1.albynyqby-pe01.nyroc.rr.com [24.24.21.133] 6 11 ms 10 ms 10 ms ten1-2-1.albynywav-pe01.nyroc.rr.com [24.24.21.46] 7 11 ms 13 ms 10 ms ge-7-2-0.albynywav-rtr03.nyroc.rr.com [24.24.21.158] 8 15 ms 14 ms 14 ms ae-5-0.cr0.nyc30.tbone.rr.com [66.109.6.74] 9 15 ms 14 ms 14 ms ae-1-0.pr0.nyc30.tbone.rr.com [66.109.6.161] 10 15 ms 14 ms 14 ms ex1-tg2-0.eqnwnj.sbcglobal.net [151.164.250.245] 11 90 ms 89 ms 89 ms ded4-g1-3-0.sntc01.pbi.net [151.164.41.161] 12 90 ms 89 ms 89 ms Cisco-Systems-1152786.cust-rtr.pacbell.net [64.161.0.62] 13 89 ms 89 ms 89 ms sjc5-dmzbb-gw1-gig1-47.cisco.com [128.107.224.105] 14 319 ms 305 ms 298 ms sjce-dmzbb-gw1.cisco.com [128.107.224.2] 15 90 ms 89 ms 90 ms sjck-dmzdc-gw1-gig5-2.cisco.com [128.107.224.69] 16 * ^C H:\> Shon Elliott wrote: > can't get to cisco.com from here atm either, but can get to facebook. looks like > facebook is now coming from ashburn, va. > > cisco dies within level3 for us, and for route-views.oregon-ix.net: > > 5 eugn-core1-gw.nero.net (207.98.64.161) [AS 3701] !H * !H > > don't see that address (198.133.219.25) in the global routing table either. > > show ip bgp 198.133.219.0 > % Network not in table > > > > R. Benjamin Kessler wrote: > >> Hey Gang - >> >> I'm unable to get to cisco.com from multiple places on the 'net >> (including downforeveryoneorjustme.com); any ideas on the cause and ETR? >> >> Thanks, >> >> Ben >> >> >> >> > > From mhuff at ox.com Tue Aug 4 09:14:35 2009 From: mhuff at ox.com (Matthew Huff) Date: Tue, 4 Aug 2009 10:14:35 -0400 Subject: cisco.com In-Reply-To: <4A783EB4.7050009@krsek.cz> References: <0B608FCDCF43BF4C9194C896C53202435D8D2A@mnsg-svr2.mnsg.net> <4A783EB4.7050009@krsek.cz> Message-ID: <483E6B0272B0284BA86D7596C40D29F9D1221281AC@PUR-EXCH07.ox.com> Looks like it's back. rtr-inet1#show ip bgp 198.133.219.0/24 BGP routing table entry for 198.133.219.0/24, version 4296794 Paths: (1 available, best #1, table Default-IP-Routing-Table) Advertised to update-groups: 1 6128 7132 109, (received & used) 69.74.151.237 from 69.74.151.237 (65.19.127.20) Origin IGP, localpref 100, valid, external, best rtr-inet2#show ip bgp 198.133.219.0/24 BGP routing table entry for 198.133.219.0/24, version 11588586 Paths: (2 available, best #1, table Default-IP-Routing-Table) Not advertised to any peer 6128 7132 109, (received & used) 129.77.19.1 from 129.77.19.1 (129.77.9.252) Origin IGP, metric 0, localpref 100, valid, internal, best 6395 3356 7018 109, (received & used) 67.96.160.189 from 67.96.160.189 (216.140.10.58) Origin IGP, metric 6, localpref 100, valid, external Community: 6395:1 6395:1006 ---- Matthew Huff | One Manhattanville Rd OTA Management LLC | Purchase, NY 10577 http://www.ox.com | Phone: 914-460-4039 aim: matthewbhuff | Fax: 914-460-4139 > -----Original Message----- > From: Michal Krsek [mailto:michal at krsek.cz] > Sent: Tuesday, August 04, 2009 9:59 AM > To: Jon Auer > Cc: nanog at nanog.org > Subject: Re: cisco.com > > Same here in Prague (various upstreams in Central Europe) > > MK > > Jon Auer napsal(a): > > See: https://puck.nether.net/pipermail/outages/2009- > August/001386.html > > I do not have a route to that IP (198.133.219.25) in BGP either.. > > > > On Tue, Aug 4, 2009 at 8:34 AM, R. Benjamin Kessler > wrote: > > > >> Hey Gang - > >> > >> I'm unable to get to cisco.com from multiple places on the 'net > >> (including downforeveryoneorjustme.com); any ideas on the cause and > ETR? > >> > >> Thanks, > >> > >> Ben > >> > >> > >> > >> -------------- next part -------------- A non-text attachment was scrubbed... Name: Matthew Huff.vcf Type: application/octet-stream Size: 1595 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 4229 bytes Desc: not available URL: From gaurav.taparia at gmail.com Tue Aug 4 09:15:39 2009 From: gaurav.taparia at gmail.com (Gaurav Taparia) Date: Tue, 4 Aug 2009 08:15:39 -0600 Subject: cisco.com In-Reply-To: <25782A27-7EFF-4655-8EFD-CFFF769C8096@let.de> References: <0B608FCDCF43BF4C9194C896C53202435D8D2A@mnsg-svr2.mnsg.net> <1249393336.4204.0.camel@sys-engineer> <25782A27-7EFF-4655-8EFD-CFFF769C8096@let.de> Message-ID: Can get to facebook but not to cisco from Denver (level 3). Traces reach SJC and die in ATT net. Possibly a local data center outage / black-holing event. - Gaurav On Tue, Aug 4, 2009 at 7:50 AM, Marc Manthey wrote: > > Am 04.08.2009 um 15:42 schrieb Alex Nderitu: > > Facebook seems to also be affected. >> > > > facebook works fine from germany > > >> I'm unable to get to cisco.com from multiple places on the 'net >> (including downforeveryoneorjustme.com); any ideas on the cause and ETR? >> > > > An error occurred while processing your request. > Reference #97.520dd58.1249393745.3bb006 > > is #down > > Marc > From sam.oduor at gmail.com Tue Aug 4 09:21:00 2009 From: sam.oduor at gmail.com (Sam Oduor) Date: Tue, 4 Aug 2009 17:21:00 +0300 Subject: cisco.com In-Reply-To: <261698448-1249393881-cardhu_decombobulator_blackberry.rim.net-105432216-@bxe1156.bisx.prod.on.blackberry> References: <261698448-1249393881-cardhu_decombobulator_blackberry.rim.net-105432216-@bxe1156.bisx.prod.on.blackberry> Message-ID: <4f16c5450908040721x3251b442ub15cc5f674067bc0@mail.gmail.com> http://blogs.cisco.com/news/comments/final_update_ciscocom_outage/ On Tue, Aug 4, 2009 at 4:51 PM, wrote: > So cisco has no BGP is that what I'm hearing... Oh the irony :) > ------Original Message------ > From: Aaron Millisor > To: R. Benjamin Kessler > Cc: nanog at nanog.org > Subject: Re: cisco.com > Sent: Aug 4, 2009 10:45 AM > > Not sure the ETA but the network that the address for cisco.com resolves > to (198.133.219.0/24) is no longer in BGP. > > -- > ----------------------------------------------------- > Aaron Millisor > > > > > R. Benjamin Kessler wrote: > > Hey Gang - > > > > I'm unable to get to cisco.com from multiple places on the 'net > > (including downforeveryoneorjustme.com); any ideas on the cause and ETR? > > > > Thanks, > > > > Ben > > > > > > > > Sent from my BlackBerry device on the Rogers Wireless Network > > -- Samson Oduor From sjk at sleepycatz.com Tue Aug 4 09:21:20 2009 From: sjk at sleepycatz.com (sjk) Date: Tue, 04 Aug 2009 09:21:20 -0500 Subject: cisco.com In-Reply-To: <4A783C37.9060002@sleepycatz.com> References: <0B608FCDCF43BF4C9194C896C53202435D8D2A@mnsg-svr2.mnsg.net> <1249393336.4204.0.camel@sys-engineer> <4A783C37.9060002@sleepycatz.com> Message-ID: <4A7843E0.6000405@sleepycatz.com> Seeing them off of Sprint now. . . weird sjk wrote: > We have seen the route for cisco withdrawn from 208 and 2828. Facebook > seems fine > > From tme at americafree.tv Tue Aug 4 09:21:57 2009 From: tme at americafree.tv (Marshall Eubanks) Date: Tue, 4 Aug 2009 10:21:57 -0400 Subject: cisco.com In-Reply-To: References: <0B608FCDCF43BF4C9194C896C53202435D8D2A@mnsg-svr2.mnsg.net><1249393336.4204.0.camel@sys-engineer> <7ab4d938bcf536ec9b6c7eef8192a5b1.squirrel@mail.uplogon.com> Message-ID: <608D1E3A-9B12-4F66-93C8-2AE287268789@americafree.tv> On Aug 4, 2009, at 9:59 AM, Jason Vanick wrote: > Same here via Verizon, Level3 and Comcast. > No trouble in Virginia with either Cox Cable or Cogent. > Btw... all 3 resolve to the same 198.133.219.25 addr. > That's what I get ;; ANSWER SECTION: cisco.com. 86400 IN A 198.133.219.25 so, that sounds like routing to me. BTW, 198.133.219.26 is ping-able from here. Marshall > -----Original Message----- > From: Chris Gotstein [mailto:chris at uplogon.com] > Sent: Tuesday, August 04, 2009 8:48 AM > To: nanog at nanog.org > Subject: Re: cisco.com > > Seeing same issue from Chicago via Qwest and HE. > > >> >> Both work from Austin, TX. >> >> >> >> - d. >> >> On Tue, 4 Aug 2009, Alex Nderitu wrote: >> >>> Facebook seems to also be affected. >>> >>> >>> -----Original Message----- >>> From: R. Benjamin Kessler >>> To: nanog at nanog.org >>> Subject: cisco.com >>> Date: Tue, 4 Aug 2009 09:34:46 -0400 >>> >>> >>> Hey Gang - >>> >>> I'm unable to get to cisco.com from multiple places on the 'net >>> (including downforeveryoneorjustme.com); any ideas on the cause >>> and ETR? >>> >>> Thanks, >>> >>> Ben >>> >>> >>> >>> >> >> -- >> Dominic J. Eidson >> "Baruk Khazad! Khazad ai- >> menu!" - >> Gimli >> > ---------------------------------------------------------------------------- >> > http://www.dominiceidson.com/ >> >> > > > -- > Chris Gotstein > Sr Network Engineer > UP Logon/Computer Connection UP > 500 N Stephenson Ave > Iron Mountain, MI 49801 > Phone: 906-774-4847 > Fax: 906-774-0335 > chris at uplogon.com > > > > From gmartine at ajax.opentransit.net Tue Aug 4 09:18:39 2009 From: gmartine at ajax.opentransit.net (German Martinez) Date: Tue, 4 Aug 2009 10:18:39 -0400 Subject: cisco.com In-Reply-To: <1fffe9f20908040703m2d6a0bdbpd6986b4ebf447f8c@mail.gmail.com> References: <0B608FCDCF43BF4C9194C896C53202435D8D2A@mnsg-svr2.mnsg.net> <1249393336.4204.0.camel@sys-engineer> <4A783C37.9060002@sleepycatz.com> <1fffe9f20908040703m2d6a0bdbpd6986b4ebf447f8c@mail.gmail.com> Message-ID: <20090804141839.GB11802@ajax.opentransit.net> On Tue Aug 04, 2009, Steve Rossen wrote: Route is back 08/04 13:55:57 Withdraw 198.133.219.0/24 08/04 16:04:53 Update 198.133.219.0/24 Times are CET. German > Missing route on Internap also. > > Netraft shows cisco.com went down right at 12:00GMT. > > http://uptime.netcraft.com/perf/graph?site=www.cisco.com > > On Tue, Aug 4, 2009 at 8:48 AM, sjk wrote: > > We have seen the route for cisco withdrawn from 208 and 2828. Facebook > > seems fine > > > > Dominic J. Eidson wrote: > >> > >> Both work from Austin, TX. > >> > >> > >> > >> ?- d. > >> > >> On Tue, 4 Aug 2009, Alex Nderitu wrote: > >> > >>> Facebook seems to also be affected. > >>> > >>> > >>> -----Original Message----- > >>> From: R. Benjamin Kessler > >>> To: nanog at nanog.org > >>> Subject: cisco.com > >>> Date: Tue, 4 Aug 2009 09:34:46 -0400 > >>> > >>> > >>> Hey Gang - > >>> > >>> I'm unable to get to cisco.com from multiple places on the 'net > >>> (including downforeveryoneorjustme.com); any ideas on the cause and ETR? > >>> > >>> Thanks, > >>> > >>> Ben > >>> > >>> > >>> > >>> > >> > > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From tme at americafree.tv Tue Aug 4 09:24:33 2009 From: tme at americafree.tv (Marshall Eubanks) Date: Tue, 4 Aug 2009 10:24:33 -0400 Subject: cisco.com In-Reply-To: <48FAC036AD7B7642BB2944FB9AE674A305651690@EXCHANGE.nashville.cybera.net> References: <0B608FCDCF43BF4C9194C896C53202435D8D2A@mnsg-svr2.mnsg.net> <1249393336.4204.0.camel@sys-engineer> <4A783C37.9060002@sleepycatz.com> <48FAC036AD7B7642BB2944FB9AE674A305651690@EXCHANGE.nashville.cybera.net> Message-ID: <935C2261-A70F-413D-AC4A-299B499CCEB5@americafree.tv> On Aug 4, 2009, at 10:03 AM, Scott Wolfe wrote: > No route for 198.133.219.0/24 in 22820 from our upstream (3356 and > 174). > > -Scott W Through Cogent tme$ traceroute 198.133.219.26 traceroute to 198.133.219.26 (198.133.219.26), 64 hops max, 40 byte packets 1 dmz-mct2.americafree.tv (63.105.122.1) 0.673 ms 0.394 ms 0.243 ms 2 gi0-7.na21.b002176-1.dca01.atlas.cogentco.com (38.99.206.153) 0.690 ms 0.721 ms 0.970 ms 3 te9-2.3687.mpd01.dca01.atlas.cogentco.com (38.20.43.49) 0.984 ms 0.965 ms 0.732 ms 4 vl3491.ccr02.dca01.atlas.cogentco.com (154.54.7.234) 0.976 ms 0.923 ms 0.726 ms 5 te8-3.ccr02.iad01.atlas.cogentco.com (154.54.26.134) 54.971 ms te4-3.ccr02.iad01.atlas.cogentco.com (154.54.26.138) 3.705 ms 13.960 ms 6 sl-st30-ash-0-11-3-0.sprintlink.net (144.232.8.205) 1.973 ms 2.089 ms 1.975 ms 7 sl-crs1-dc-0-13-0-0.sprintlink.net (144.232.25.12) 3.495 ms 3.043 ms 2.734 ms 8 sl-bb20-dc-3-0-0.sprintlink.net (144.232.15.10) 2.989 ms sl-crs1- rly-0-13-5-0.sprintlink.net (144.232.19.212) 5.824 ms sl-crs1- rly-0-2-0-0.sprintlink.net (144.232.19.222) 5.860 ms 9 sl-crs1-rly-0-9-0-0.sprintlink.net (144.232.20.13) 5.613 ms 5.134 ms 4.477 ms 10 sl-gw18-sj-13-0-0.sprintlink.net (144.232.3.6) 71.695 ms 71.306 ms 72.170 ms 11 144.228.44.14 (144.228.44.14) 72.156 ms 72.895 ms 71.916 ms 12 sjce-dmzbb-gw1.cisco.com (128.107.239.89) 72.154 ms 144.228.44.14 (144.228.44.14) 72.301 ms sjce-dmzbb-gw1.cisco.com (128.107.239.89) 72.329 ms 13 sjck-dmzdc-gw2-gig5-2.cisco.com (128.107.224.73) 72.422 ms sjce- dmzbb-gw1.cisco.com (128.107.239.89) 71.853 ms sjck-dmzdc-gw2- gig5-2.cisco.com (128.107.224.73) 72.173 ms 14 sjck-dmzdc-gw2-gig5-2.cisco.com (128.107.224.73) 72.393 ms * 71.648 ms 15 * * * 16 * * * 17 * * * 18 * * * Could other Sprint routes be affected ? Regards Marshall > > > > -----Original Message----- > From: sjk [mailto:sjk at sleepycatz.com] > Sent: Tuesday, August 04, 2009 8:49 AM > To: Dominic J. Eidson > Cc: nanog at nanog.org > Subject: Re: cisco.com > > We have seen the route for cisco withdrawn from 208 and 2828. Facebook > seems fine > > Dominic J. Eidson wrote: >> >> Both work from Austin, TX. >> >> >> >> - d. >> >> On Tue, 4 Aug 2009, Alex Nderitu wrote: >> >>> Facebook seems to also be affected. >>> >>> >>> -----Original Message----- >>> From: R. Benjamin Kessler >>> To: nanog at nanog.org >>> Subject: cisco.com >>> Date: Tue, 4 Aug 2009 09:34:46 -0400 >>> >>> >>> Hey Gang - >>> >>> I'm unable to get to cisco.com from multiple places on the 'net >>> (including downforeveryoneorjustme.com); any ideas on the cause >>> and ETR? >>> >>> Thanks, >>> >>> Ben >>> >>> >>> >>> >> > From mmoriniaux at prosodie.com Tue Aug 4 09:24:37 2009 From: mmoriniaux at prosodie.com (Moriniaux Michel) Date: Tue, 4 Aug 2009 16:24:37 +0200 Subject: cisco.com References: <0B608FCDCF43BF4C9194C896C53202435D8D2A@mnsg-svr2.mnsg.net> <1249393336.4204.0.camel@sys-engineer> <4A783C37.9060002@sleepycatz.com> <1fffe9f20908040703m2d6a0bdbpd6986b4ebf447f8c@mail.gmail.com> Message-ID: All Ok from France through Sprintlink and Telia sh ip bgp 198.133.219.25 Number of BGP Routes matching display condition : 2 Status codes: s suppressed, d damped, h history, * valid, > best, i internal Origin codes: i - IGP, e - EGP, ? - incomplete Network Next Hop Metric LocPrf Weight Path *> 198.133.219.0/24 217.118.238.45 1370 120 0 1239 109 i * 198.133.219.0/24 213.248.77.181 120 0 1299 7018 109 i Cisco and facebook available -----Message d'origine----- De : Steve Rossen [mailto:steve.rossen at gmail.com] Envoy? : mardi 4 ao?t 2009 16:03 ? : nanog at nanog.org Objet : Re: cisco.com Missing route on Internap also. Netraft shows cisco.com went down right at 12:00GMT. http://uptime.netcraft.com/perf/graph?site=www.cisco.com On Tue, Aug 4, 2009 at 8:48 AM, sjk wrote: > We have seen the route for cisco withdrawn from 208 and 2828. Facebook > seems fine > > Dominic J. Eidson wrote: >> >> Both work from Austin, TX. >> >> >> >> ?- d. >> >> On Tue, 4 Aug 2009, Alex Nderitu wrote: >> >>> Facebook seems to also be affected. >>> >>> >>> -----Original Message----- >>> From: R. Benjamin Kessler >>> To: nanog at nanog.org >>> Subject: cisco.com >>> Date: Tue, 4 Aug 2009 09:34:46 -0400 >>> >>> >>> Hey Gang - >>> >>> I'm unable to get to cisco.com from multiple places on the 'net >>> (including downforeveryoneorjustme.com); any ideas on the cause and ETR? >>> >>> Thanks, >>> >>> Ben >>> >>> >>> >>> >> > > From bruce.horth at gmail.com Tue Aug 4 09:24:58 2009 From: bruce.horth at gmail.com (Bruce Horth) Date: Tue, 4 Aug 2009 10:24:58 -0400 Subject: cisco.com In-Reply-To: <48FAC036AD7B7642BB2944FB9AE674A305651690@EXCHANGE.nashville.cybera.net> References: <0B608FCDCF43BF4C9194C896C53202435D8D2A@mnsg-svr2.mnsg.net> <1249393336.4204.0.camel@sys-engineer> <4A783C37.9060002@sleepycatz.com> <48FAC036AD7B7642BB2944FB9AE674A305651690@EXCHANGE.nashville.cybera.net> Message-ID: I now have a route to 198.133.219.0/24 Cisco.com is back up. On Tue, Aug 4, 2009 at 10:03, Scott Wolfe wrote: > No route for 198.133.219.0/24 in 22820 from our upstream (3356 and 174). > > -Scott W > > > -----Original Message----- > From: sjk [mailto:sjk at sleepycatz.com] > Sent: Tuesday, August 04, 2009 8:49 AM > To: Dominic J. Eidson > Cc: nanog at nanog.org > Subject: Re: cisco.com > > We have seen the route for cisco withdrawn from 208 and 2828. Facebook > seems fine > > Dominic J. Eidson wrote: > > > > Both work from Austin, TX. > > > > > > > > - d. > > > > On Tue, 4 Aug 2009, Alex Nderitu wrote: > > > >> Facebook seems to also be affected. > >> > >> > >> -----Original Message----- > >> From: R. Benjamin Kessler > >> To: nanog at nanog.org > >> Subject: cisco.com > >> Date: Tue, 4 Aug 2009 09:34:46 -0400 > >> > >> > >> Hey Gang - > >> > >> I'm unable to get to cisco.com from multiple places on the 'net > >> (including downforeveryoneorjustme.com); any ideas on the cause and > ETR? > >> > >> Thanks, > >> > >> Ben > >> > >> > >> > >> > > > > -- BH From mike at sentex.net Tue Aug 4 09:25:18 2009 From: mike at sentex.net (Mike Tancsa) Date: Tue, 04 Aug 2009 10:25:18 -0400 Subject: cisco.com (back now) In-Reply-To: <4A783FF6.2080901@vpsat.it> References: <994263966-1249393584-cardhu_decombobulator_blackberry.rim.net-987275097-@bxe1156.bisx.prod.on.blackberry> <4A783FF6.2080901@vpsat.it> Message-ID: <200908041422.n74EMEq8084663@lava.sentex.ca> I see it now via 6453 7132 109 174 1239 109 ---Mike -------------------------------------------------------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike at sentex.net Providing Internet since 1994 www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike From David_Hiers at adp.com Tue Aug 4 09:24:47 2009 From: David_Hiers at adp.com (Hiers, David) Date: Tue, 4 Aug 2009 09:24:47 -0500 Subject: cisco.com In-Reply-To: <48FAC036AD7B7642BB2944FB9AE674A305651690@EXCHANGE.nashville.cybera.net> References: <0B608FCDCF43BF4C9194C896C53202435D8D2A@mnsg-svr2.mnsg.net> <1249393336.4204.0.camel@sys-engineer> <4A783C37.9060002@sleepycatz.com> <48FAC036AD7B7642BB2944FB9AE674A305651690@EXCHANGE.nashville.cybera.net> Message-ID: <81CDFC77FB2DC54DB875D4F8FFC36CE00A924A98D7@DSMAIL2HE.ds.ad.adp.com> FACEBOOK: UP CISCO: UP LOCATION: PORTLAND, OR David Hiers CCIE (R/S, V), CISSP ADP Dealer Services 2525 SW 1st Ave. Suite 300W Portland, OR 97201 o: 503-205-4467 f: 503-402-3277 -----Original Message----- From: Scott Wolfe [mailto:scott.wolfe at cybera.net] Sent: Tuesday, August 04, 2009 7:04 AM To: nanog at nanog.org Subject: RE: cisco.com No route for 198.133.219.0/24 in 22820 from our upstream (3356 and 174). -Scott W -----Original Message----- From: sjk [mailto:sjk at sleepycatz.com] Sent: Tuesday, August 04, 2009 8:49 AM To: Dominic J. Eidson Cc: nanog at nanog.org Subject: Re: cisco.com We have seen the route for cisco withdrawn from 208 and 2828. Facebook seems fine Dominic J. Eidson wrote: > > Both work from Austin, TX. > > > > - d. > > On Tue, 4 Aug 2009, Alex Nderitu wrote: > >> Facebook seems to also be affected. >> >> >> -----Original Message----- >> From: R. Benjamin Kessler >> To: nanog at nanog.org >> Subject: cisco.com >> Date: Tue, 4 Aug 2009 09:34:46 -0400 >> >> >> Hey Gang - >> >> I'm unable to get to cisco.com from multiple places on the 'net >> (including downforeveryoneorjustme.com); any ideas on the cause and ETR? >> >> Thanks, >> >> Ben >> >> >> >> > This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. From jason at lixfeld.ca Tue Aug 4 09:27:42 2009 From: jason at lixfeld.ca (Jason Lixfeld) Date: Tue, 4 Aug 2009 10:27:42 -0400 Subject: cisco.com In-Reply-To: <4A783B8F.1070206@bright.net> References: <0B608FCDCF43BF4C9194C896C53202435D8D2A@mnsg-svr2.mnsg.net> <4A783B8F.1070206@bright.net> Message-ID: Well, Cisco *did* EoS/EoL BGP last week. I guess there really wasn't all that much industry traction on whatever protocol they decided to replace it with. https://puck.nether.net/pipermail/cisco-nsp/2009-July/062646.html ;p On 4-Aug-09, at 9:45 AM, Aaron Millisor wrote: > Not sure the ETA but the network that the address for cisco.com > resolves to (198.133.219.0/24) is no longer in BGP. > > -- > ----------------------------------------------------- > Aaron Millisor > > > > > R. Benjamin Kessler wrote: >> Hey Gang - I'm unable to get to cisco.com from multiple places on >> the 'net >> (including downforeveryoneorjustme.com); any ideas on the cause and >> ETR? >> Thanks, >> Ben > > From giuseppe.spano at vpsat.it Tue Aug 4 09:29:34 2009 From: giuseppe.spano at vpsat.it (=?ISO-8859-15?Q?Giuseppe_Span=F2_-_Videopi=F9_Srl?=) Date: Tue, 04 Aug 2009 16:29:34 +0200 Subject: cisco.com In-Reply-To: <20090804135242.GA11802@ajax.opentransit.net> References: <0B608FCDCF43BF4C9194C896C53202435D8D2A@mnsg-svr2.mnsg.net> <20090804135242.GA11802@ajax.opentransit.net> Message-ID: <4A7845CE.6070503@vpsat.it> Cisco.com up again in Italy. Regards, German Martinez ha scritto: > On Tue Aug 04, 2009, Jon Auer wrote: > > >> See: https://puck.nether.net/pipermail/outages/2009-August/001386.html >> I do not have a route to that IP (198.133.219.25) in BGP either.. >> > > Route is not longer in the routing table since (CET) > > 08/04 13:55:57 Withdraw 198.133.219.0/24> > > German > From jhorstman at adknowledge.com Tue Aug 4 09:30:42 2009 From: jhorstman at adknowledge.com (Justin Horstman) Date: Tue, 4 Aug 2009 09:30:42 -0500 Subject: cisco.com In-Reply-To: <202705b0908040706x58e1f4a6tf791d3826066c51a@mail.gmail.com> References: <261698448-1249393881-cardhu_decombobulator_blackberry.rim.net-105432216-@bxe1156.bisx.prod.on.blackberry> <202705b0908040706x58e1f4a6tf791d3826066c51a@mail.gmail.com> Message-ID: See Cisco as Up Qwest, Cogent, Att, and L3 Midwest-US ~J -----Original Message----- From: Jorge Amodio [mailto:jmamodio at gmail.com] Sent: Tuesday, August 04, 2009 9:07 AM To: nanog at nanog.org Subject: Re: cisco.com FB up, Cisco down, from SATX (Time Warner Road Runner) J From jay at miscreant.org Tue Aug 4 09:31:26 2009 From: jay at miscreant.org (Jay Mitchell) Date: Wed, 5 Aug 2009 00:31:26 +1000 Subject: cisco.com In-Reply-To: <0B608FCDCF43BF4C9194C896C53202435D8D2A@mnsg-svr2.mnsg.net> References: <0B608FCDCF43BF4C9194C896C53202435D8D2A@mnsg-svr2.mnsg.net> Message-ID: <001b01ca1510$433669e0$c9a33da0$@org> Cisco.com (198.133.219.25) is alive from .au (from ASN7474) Traceroute shows: 9 448 ms 419 ms 389 ms sjck-dmzbb-gw1.cisco.com [128.107.224.6] 10 427 ms 268 ms 279 ms sjck-dmzdc-gw2-gig5-1.cisco.com [128.107.224.77] Did a quick check on a few .au looking glass sites and getting entries for 198.133.219.0/24. --jay -----Original Message----- From: R. Benjamin Kessler [mailto:rbk at mnsginc.com] Sent: Tuesday, 4 August 2009 11:35 PM To: nanog at nanog.org Subject: cisco.com Hey Gang - I'm unable to get to cisco.com from multiple places on the 'net (including downforeveryoneorjustme.com); any ideas on the cause and ETR? Thanks, Ben From a.harrowell at gmail.com Tue Aug 4 09:32:37 2009 From: a.harrowell at gmail.com (Alexander Harrowell) Date: Tue, 4 Aug 2009 15:32:37 +0100 Subject: cisco.com In-Reply-To: <4A783EB4.7050009@krsek.cz> References: <0B608FCDCF43BF4C9194C896C53202435D8D2A@mnsg-svr2.mnsg.net> <4A783EB4.7050009@krsek.cz> Message-ID: <200908041532.50510.a.harrowell@gmail.com> Up via Sprintlink in London... -------------- 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 Myke.Lyons at cmtww.com Tue Aug 4 09:47:27 2009 From: Myke.Lyons at cmtww.com (Myke Lyons) Date: Tue, 4 Aug 2009 10:47:27 -0400 Subject: cisco.com In-Reply-To: <483E6B0272B0284BA86D7596C40D29F9D1221281AC@PUR-EXCH07.ox.com> References: <0B608FCDCF43BF4C9194C896C53202435D8D2A@mnsg-svr2.mnsg.net> <4A783EB4.7050009@krsek.cz> <483E6B0272B0284BA86D7596C40D29F9D1221281AC@PUR-EXCH07.ox.com> Message-ID: <0D3E6F36-B3A5-4D1F-86EB-8D93426DF95F@cmtww.com> On Aug 4, 2009, at 10:14 AM, Matthew Huff wrote: > Looks like it's back. > > rtr-inet1#show ip bgp 198.133.219.0/24 > BGP routing table entry for 198.133.219.0/24, version 4296794 > Paths: (1 available, best #1, table Default-IP-Routing-Table) > Advertised to update-groups: > 1 > 6128 7132 109, (received & used) > 69.74.151.237 from 69.74.151.237 (65.19.127.20) > Origin IGP, localpref 100, valid, external, best > > rtr-inet2#show ip bgp 198.133.219.0/24 > BGP routing table entry for 198.133.219.0/24, version 11588586 > Paths: (2 available, best #1, table Default-IP-Routing-Table) > Not advertised to any peer > 6128 7132 109, (received & used) > 129.77.19.1 from 129.77.19.1 (129.77.9.252) > Origin IGP, metric 0, localpref 100, valid, internal, best > 6395 3356 7018 109, (received & used) > 67.96.160.189 from 67.96.160.189 (216.140.10.58) > Origin IGP, metric 6, localpref 100, valid, external > Community: 6395:1 6395:1006 Work from here as well sl-gw39-nyc-12-0-0-si28.sprintlink.net (144.228.178.109) AS/21986 From petelists at templin.org Tue Aug 4 09:48:34 2009 From: petelists at templin.org (Pete Templin) Date: Tue, 04 Aug 2009 09:48:34 -0500 Subject: cisco.com In-Reply-To: <4f16c5450908040721x3251b442ub15cc5f674067bc0@mail.gmail.com> References: <261698448-1249393881-cardhu_decombobulator_blackberry.rim.net-105432216-@bxe1156.bisx.prod.on.blackberry> <4f16c5450908040721x3251b442ub15cc5f674067bc0@mail.gmail.com> Message-ID: <4A784A42.9080406@templin.org> Sam Oduor wrote: > http://blogs.cisco.com/news/comments/final_update_ciscocom_outage/ I don't think the Kool-Aid powder is blending with the water...that's from (almost) two years ago. pt From David_Hiers at adp.com Tue Aug 4 09:49:01 2009 From: David_Hiers at adp.com (Hiers, David) Date: Tue, 4 Aug 2009 09:49:01 -0500 Subject: cisco.com In-Reply-To: <0B608FCDCF43BF4C9194C896C53202435D8D2A@mnsg-svr2.mnsg.net> References: <0B608FCDCF43BF4C9194C896C53202435D8D2A@mnsg-svr2.mnsg.net> Message-ID: <81CDFC77FB2DC54DB875D4F8FFC36CE00A924A99F8@DSMAIL2HE.ds.ad.adp.com> Cisco is aware of the issue and they are working on it. David Hiers CCIE (R/S, V), CISSP ADP Dealer Services 2525 SW 1st Ave. Suite 300W Portland, OR 97201 o: 503-205-4467 f: 503-402-3277 -----Original Message----- From: R. Benjamin Kessler [mailto:rbk at mnsginc.com] Sent: Tuesday, August 04, 2009 6:35 AM To: nanog at nanog.org Subject: cisco.com Hey Gang - I'm unable to get to cisco.com from multiple places on the 'net (including downforeveryoneorjustme.com); any ideas on the cause and ETR? Thanks, Ben This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. From rkulagow at gmail.com Tue Aug 4 09:54:24 2009 From: rkulagow at gmail.com (Robert Kulagowski) Date: Tue, 4 Aug 2009 09:54:24 -0500 Subject: cisco.com In-Reply-To: <4f16c5450908040721x3251b442ub15cc5f674067bc0@mail.gmail.com> References: <261698448-1249393881-cardhu_decombobulator_blackberry.rim.net-105432216-@bxe1156.bisx.prod.on.blackberry> <4f16c5450908040721x3251b442ub15cc5f674067bc0@mail.gmail.com> Message-ID: <117f338f0908040754md3db06ehe7d4013d0d61a673@mail.gmail.com> On Tue, Aug 4, 2009 at 9:21 AM, Sam Oduor wrote: > http://blogs.cisco.com/news/comments/final_update_ciscocom_outage/ Nice, except that the blog entry is from two years ago. What happened _today_? From Myke.Lyons at cmtww.com Tue Aug 4 09:58:45 2009 From: Myke.Lyons at cmtww.com (Myke Lyons) Date: Tue, 4 Aug 2009 10:58:45 -0400 Subject: cisco.com In-Reply-To: <4f16c5450908040721x3251b442ub15cc5f674067bc0@mail.gmail.com> References: <261698448-1249393881-cardhu_decombobulator_blackberry.rim.net-105432216-@bxe1156.bisx.prod.on.blackberry> <4f16c5450908040721x3251b442ub15cc5f674067bc0@mail.gmail.com> Message-ID: <3832C643-97B4-4D8B-B3A8-6ABA57BC5C4F@cmtww.com> On Aug 4, 2009, at 10:21 AM, Sam Oduor wrote: > http://blogs.cisco.com/news/comments/final_update_ciscocom_outage/ > That blog post is from 2007 so I'm assuming this was sent as a joke. From justin at justinshore.com Tue Aug 4 10:08:32 2009 From: justin at justinshore.com (Justin Shore) Date: Tue, 04 Aug 2009 10:08:32 -0500 Subject: cisco.com In-Reply-To: <261698448-1249393881-cardhu_decombobulator_blackberry.rim.net-105432216-@bxe1156.bisx.prod.on.blackberry> References: <261698448-1249393881-cardhu_decombobulator_blackberry.rim.net-105432216-@bxe1156.bisx.prod.on.blackberry> Message-ID: <4A784EF0.30202@justinshore.com> Didn't you hear? Cisco EoLed BGP this time last week. I guess they really meant it! Justin deleskie at gmail.com wrote: > So cisco has no BGP is that what I'm hearing... Oh the irony :) > ------Original Message------ > From: Aaron Millisor > To: R. Benjamin Kessler > Cc: nanog at nanog.org > Subject: Re: cisco.com > Sent: Aug 4, 2009 10:45 AM > > Not sure the ETA but the network that the address for cisco.com resolves > to (198.133.219.0/24) is no longer in BGP. From mhuff at ox.com Tue Aug 4 10:18:43 2009 From: mhuff at ox.com (Matthew Huff) Date: Tue, 4 Aug 2009 11:18:43 -0400 Subject: cisco.com In-Reply-To: <0D3E6F36-B3A5-4D1F-86EB-8D93426DF95F@cmtww.com> References: <0B608FCDCF43BF4C9194C896C53202435D8D2A@mnsg-svr2.mnsg.net> <4A783EB4.7050009@krsek.cz> <483E6B0272B0284BA86D7596C40D29F9D1221281AC@PUR-EXCH07.ox.com> <0D3E6F36-B3A5-4D1F-86EB-8D93426DF95F@cmtww.com> Message-ID: <483E6B0272B0284BA86D7596C40D29F9D1221281B4@PUR-EXCH07.ox.com> http://blogs.cisco.com/news/comments/final_update_ciscocom_outage/ FINAL UPDATE: Cisco.com Outage Service to Cisco.com has been restored and all applications are now fully operational. The issue occurred during preventative maintenance of one of our data centers when a human error caused an electrical overload on the systems. This caused Cisco.com and other applications to go down. Because of the severity of the overload, the redundancy measures in some of the applications and power systems were impacted as well, though the system did shut down as designed to protect the people and the equipment. As a result, no data were lost and no one was injured. Cisco has plans already in process to add additional redundancies to increase the resilience of these systems. Again, we thank our customers and our partners for their patience during the resolution of this issue. Posted by Cisco PR at 12:00AM PST ---- Matthew Huff | One Manhattanville Rd OTA Management LLC | Purchase, NY 10577 http:// www.ox.com | Phone: 914-460-4039 aim: matthewbhuff | Fax: 914-460-4139 From: Myke Lyons [mailto:Myke.Lyons at cmtww.com] Sent: Tuesday, August 04, 2009 10:47 AM To: Matthew Huff Cc: 'nanog at nanog.org' Subject: Re: cisco.com On Aug 4, 2009, at 10:14 AM, Matthew Huff wrote: Looks like it's back. rtr-inet1#show ip bgp 198.133.219.0/24 BGP routing table entry for 198.133.219.0/24, version 4296794 Paths: (1 available, best #1, table Default-IP-Routing-Table) Advertised to update-groups: 1 6128 7132 109, (received & used) 69.74.151.237 from 69.74.151.237 (65.19.127.20) Origin IGP, localpref 100, valid, external, best rtr-inet2#show ip bgp 198.133.219.0/24 BGP routing table entry for 198.133.219.0/24, version 11588586 Paths: (2 available, best #1, table Default-IP-Routing-Table) Not advertised to any peer 6128 7132 109, (received & used) 129.77.19.1 from 129.77.19.1 (129.77.9.252) Origin IGP, metric 0, localpref 100, valid, internal, best 6395 3356 7018 109, (received & used) 67.96.160.189 from 67.96.160.189 (216.140.10.58) Origin IGP, metric 6, localpref 100, valid, external Community: 6395:1 6395:1006 Work from here as well sl-gw39-nyc-12-0-0-si28.sprintlink.net (144.228.178.109) AS/21986 -------------- next part -------------- [1]http://blogs.cisco.com/news/comments/final_update_ciscocom_outage/ FINAL UPDATE: Cisco.com Outage Service to [2]Cisco.com has been restored and all applications are now fully operational. The issue occurred during preventative maintenance of one of our data centers when a human error caused an electrical overload on the systems. This caused [3]Cisco.com and other applications to go down. Because of the severity of the overload, the redundancy measures in some of the applications and power systems were impacted as well, though the system did shut down as designed to protect the people and the equipment. As a result, no data were lost and no one was injured. Cisco has plans already in process to add additional redundancies to increase the resilience of these systems. Again, we thank our customers and our partners for their patience during the resolution of this issue. Posted by [4]Cisco PR at 12:00AM PST ---- Matthew Huff | One Manhattanville Rd OTA Management LLC | Purchase, NY 10577 http://[5]www.ox.com | Phone: 914-460-4039 aim: matthewbhuff | Fax: 914-460-4139 [cid:image001.jpg at 01CA14F5.53540A00] From: Myke Lyons [mailto:Myke.Lyons at cmtww.com] Sent: Tuesday, August 04, 2009 10:47 AM To: Matthew Huff Cc: 'nanog at nanog.org' Subject: Re: cisco.com On Aug 4, 2009, at 10:14 AM, Matthew Huff wrote: Looks like it's back. rtr-inet1#show ip bgp 198.133.219.0/24 BGP routing table entry for 198.133.219.0/24, version 4296794 Paths: (1 available, best #1, table Default-IP-Routing-Table) Advertised to update-groups: 1 6128 7132 109, (received & used) 69.74.151.237 from 69.74.151.237 (65.19.127.20) Origin IGP, localpref 100, valid, external, best rtr-inet2#show ip bgp 198.133.219.0/24 BGP routing table entry for 198.133.219.0/24, version 11588586 Paths: (2 available, best #1, table Default-IP-Routing-Table) Not advertised to any peer 6128 7132 109, (received & used) 129.77.19.1 from 129.77.19.1 (129.77.9.252) Origin IGP, metric 0, localpref 100, valid, internal, best 6395 3356 7018 109, (received & used) 67.96.160.189 from 67.96.160.189 (216.140.10.58) Origin IGP, metric 6, localpref 100, valid, external Community: 6395:1 6395:1006 Work from here as well sl-gw39-nyc-12-0-0-si28.sprintlink.net (144.228.178.109) AS/21986 References 1. http://blogs.cisco.com/news/comments/final_update_ciscocom_outage/ 2. http://www.cisco.com/ 3. http://www.cisco.com/ 4. http://blogs.cisco.com/authors/bio/46 5. http://www.otaotr.com/ -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 2223 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Matthew Huff.vcf Type: application/octet-stream Size: 1595 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 4229 bytes Desc: not available URL: From mhuff at ox.com Tue Aug 4 10:20:58 2009 From: mhuff at ox.com (Matthew Huff) Date: Tue, 4 Aug 2009 11:20:58 -0400 Subject: cisco.com In-Reply-To: <483E6B0272B0284BA86D7596C40D29F9D12216B63F@PUR-EXCH07.ox.com> References: <0B608FCDCF43BF4C9194C896C53202435D8D2A@mnsg-svr2.mnsg.net> <4A783EB4.7050009@krsek.cz> <483E6B0272B0284BA86D7596C40D29F9D1221281AC@PUR-EXCH07.ox.com> <0D3E6F36-B3A5-4D1F-86EB-8D93426DF95F@cmtww.com> <483E6B0272B0284BA86D7596C40D29F9D12216B63F@PUR-EXCH07.ox.com> Message-ID: <483E6B0272B0284BA86D7596C40D29F9D1221281B5@PUR-EXCH07.ox.com> Disregard. This was from 2 years ago. Copied the link and verbage without verifying it. My bad. ---- Matthew Huff | One Manhattanville Rd OTA Management LLC | Purchase, NY 10577 http:// www.ox.com | Phone: 914-460-4039 aim: matthewbhuff | Fax: 914-460-4139 From: Matthew Huff Sent: Tuesday, August 04, 2009 11:19 AM To: 'Myke Lyons' Cc: 'nanog at nanog.org' Subject: RE: cisco.com http://blogs.cisco.com/news/comments/final_update_ciscocom_outage/ FINAL UPDATE: Cisco.com Outage Service to Cisco.com has been restored and all applications are now fully operational. The issue occurred during preventative maintenance of one of our data centers when a human error caused an electrical overload on the systems. This caused Cisco.com and other applications to go down. Because of the severity of the overload, the redundancy measures in some of the applications and power systems were impacted as well, though the system did shut down as designed to protect the people and the equipment. As a result, no data were lost and no one was injured. Cisco has plans already in process to add additional redundancies to increase the resilience of these systems. Again, we thank our customers and our partners for their patience during the resolution of this issue. Posted by Cisco PR at 12:00AM PST ---- Matthew Huff | One Manhattanville Rd OTA Management LLC | Purchase, NY 10577 http:// www.ox.com | Phone: 914-460-4039 aim: matthewbhuff | Fax: 914-460-4139 From: Myke Lyons [mailto:Myke.Lyons at cmtww.com] Sent: Tuesday, August 04, 2009 10:47 AM To: Matthew Huff Cc: 'nanog at nanog.org' Subject: Re: cisco.com On Aug 4, 2009, at 10:14 AM, Matthew Huff wrote: Looks like it's back. rtr-inet1#show ip bgp 198.133.219.0/24 BGP routing table entry for 198.133.219.0/24, version 4296794 Paths: (1 available, best #1, table Default-IP-Routing-Table) Advertised to update-groups: 1 6128 7132 109, (received & used) 69.74.151.237 from 69.74.151.237 (65.19.127.20) Origin IGP, localpref 100, valid, external, best rtr-inet2#show ip bgp 198.133.219.0/24 BGP routing table entry for 198.133.219.0/24, version 11588586 Paths: (2 available, best #1, table Default-IP-Routing-Table) Not advertised to any peer 6128 7132 109, (received & used) 129.77.19.1 from 129.77.19.1 (129.77.9.252) Origin IGP, metric 0, localpref 100, valid, internal, best 6395 3356 7018 109, (received & used) 67.96.160.189 from 67.96.160.189 (216.140.10.58) Origin IGP, metric 6, localpref 100, valid, external Community: 6395:1 6395:1006 Work from here as well sl-gw39-nyc-12-0-0-si28.sprintlink.net (144.228.178.109) AS/21986 -------------- next part -------------- Disregard. This was from 2 years ago. Copied the link and verbage without verifying it. My bad. ---- Matthew Huff | One Manhattanville Rd OTA Management LLC | Purchase, NY 10577 http://[1]www.ox.com | Phone: 914-460-4039 aim: matthewbhuff | Fax: 914-460-4139 [cid:image001.jpg at 01CA14F5.A289E6D0] From: Matthew Huff Sent: Tuesday, August 04, 2009 11:19 AM To: 'Myke Lyons' Cc: 'nanog at nanog.org' Subject: RE: cisco.com [2]http://blogs.cisco.com/news/comments/final_update_ciscocom_outage/ FINAL UPDATE: Cisco.com Outage Service to [3]Cisco.com has been restored and all applications are now fully operational. The issue occurred during preventative maintenance of one of our data centers when a human error caused an electrical overload on the systems. This caused [4]Cisco.com and other applications to go down. Because of the severity of the overload, the redundancy measures in some of the applications and power systems were impacted as well, though the system did shut down as designed to protect the people and the equipment. As a result, no data were lost and no one was injured. Cisco has plans already in process to add additional redundancies to increase the resilience of these systems. Again, we thank our customers and our partners for their patience during the resolution of this issue. Posted by [5]Cisco PR at 12:00AM PST ---- Matthew Huff | One Manhattanville Rd OTA Management LLC | Purchase, NY 10577 http://[6]www.ox.com | Phone: 914-460-4039 aim: matthewbhuff | Fax: 914-460-4139 [cid:image001.jpg at 01CA14F5.A289E6D0] From: Myke Lyons [mailto:Myke.Lyons at cmtww.com] Sent: Tuesday, August 04, 2009 10:47 AM To: Matthew Huff Cc: 'nanog at nanog.org' Subject: Re: cisco.com On Aug 4, 2009, at 10:14 AM, Matthew Huff wrote: Looks like it's back. rtr-inet1#show ip bgp 198.133.219.0/24 BGP routing table entry for 198.133.219.0/24, version 4296794 Paths: (1 available, best #1, table Default-IP-Routing-Table) Advertised to update-groups: 1 6128 7132 109, (received & used) 69.74.151.237 from 69.74.151.237 (65.19.127.20) Origin IGP, localpref 100, valid, external, best rtr-inet2#show ip bgp 198.133.219.0/24 BGP routing table entry for 198.133.219.0/24, version 11588586 Paths: (2 available, best #1, table Default-IP-Routing-Table) Not advertised to any peer 6128 7132 109, (received & used) 129.77.19.1 from 129.77.19.1 (129.77.9.252) Origin IGP, metric 0, localpref 100, valid, internal, best 6395 3356 7018 109, (received & used) 67.96.160.189 from 67.96.160.189 (216.140.10.58) Origin IGP, metric 6, localpref 100, valid, external Community: 6395:1 6395:1006 Work from here as well sl-gw39-nyc-12-0-0-si28.sprintlink.net (144.228.178.109) AS/21986 References 1. http://www.otaotr.com/ 2. http://blogs.cisco.com/news/comments/final_update_ciscocom_outage/ 3. http://www.cisco.com/ 4. http://www.cisco.com/ 5. http://blogs.cisco.com/authors/bio/46 6. http://www.otaotr.com/ -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 2223 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Matthew Huff2.vcf Type: application/octet-stream Size: 1595 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 4229 bytes Desc: not available URL: From hank at efes.iucc.ac.il Tue Aug 4 11:01:34 2009 From: hank at efes.iucc.ac.il (hank at efes.iucc.ac.il) Date: Tue, 4 Aug 2009 19:01:34 +0300 (IDT) Subject: cisco.com In-Reply-To: References: <0B608FCDCF43BF4C9194C896C53202435D8D2A@mnsg-svr2.mnsg.net> <4A783B8F.1070206@bright.net> Message-ID: <3610.217.132.99.105.1249401694.squirrel@email.iucc.ac.il> > Well, Cisco *did* EoS/EoL BGP last week. I guess there really wasn't > all that much industry traction on whatever protocol they decided to > replace it with. > > https://puck.nether.net/pipermail/cisco-nsp/2009-July/062646.html What happened could be: a) they were smoking something and indeed decided to use EIGRP rather than BGP. b) they were testing out 4 byte ASNs and had a software issue in their IOS c) someone in Cisco wanted to download a new IOS and got frustrated with their new site so he/she pulled the plug. Kudos to that brave Cisco employee. :-) -Hank From streiner at cluebyfour.org Tue Aug 4 11:23:51 2009 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Tue, 4 Aug 2009 12:23:51 -0400 (EDT) Subject: cisco.com In-Reply-To: <3610.217.132.99.105.1249401694.squirrel@email.iucc.ac.il> References: <0B608FCDCF43BF4C9194C896C53202435D8D2A@mnsg-svr2.mnsg.net> <4A783B8F.1070206@bright.net> <3610.217.132.99.105.1249401694.squirrel@email.iucc.ac.il> Message-ID: On Tue, 4 Aug 2009, hank at efes.iucc.ac.il wrote: > a) they were smoking something and indeed decided to use EIGRP rather than > BGP. > > b) they were testing out 4 byte ASNs and had a software issue in their IOS > > c) someone in Cisco wanted to download a new IOS and got frustrated with > their new site so he/she pulled the plug. Kudos to that brave Cisco > employee. I'm assuming that the outage this morning was catastrophic enough that whoever in their IT/Neteng group was working on this couldn't open a TAC case, or there were problems opening the case and then calling back into the TAC to get it escalated to priority 1. I might be half-kidding :) jms From cmaurand at xyonet.com Tue Aug 4 12:32:42 2009 From: cmaurand at xyonet.com (Curtis Maurand) Date: Tue, 04 Aug 2009 13:32:42 -0400 Subject: Dan Kaminsky In-Reply-To: <4b6ee9310908010810w50796caenac7471b94fac1792@mail.gmail.com> References: <4b6ee9310907291453y6da24d19l21cc5345bd8f08a2@mail.gmail.com> <4A711E00.7030602@trelane.net> <7C332C86-7E7C-4C4E-8ADD-61310CA0758C@kyx.net> <4b6ee9310908010810w50796caenac7471b94fac1792@mail.gmail.com> Message-ID: <4A7870BA.4020704@xyonet.com> andrew.wallace wrote: > On Thu, Jul 30, 2009 at 11:48 PM, Dragos Ruiu wrote: > >> at the risk of adding to the metadiscussion. what does any of this have to >> do with nanog? >> (sorry I'm kinda irritable about character slander being spammed out >> unnecessarily to unrelated public lists lately ;-P ) >> >> > > What does this have to do with Nanog, the guy found a critical > security bug on DNS last year. > He didn't find it. He only publicized it. the guy who wrote djbdns fount it years ago. Powerdns was patched for the flaw a year and a half before Kaminsky published his article. http://blog.netherlabs.nl/articles/2008/07/09/some-thoughts-on-the-recent-dns-vulnerability "However - the parties involved aren't to be lauded for their current fix. Far from it. It has been known since 1999 that all nameserver implementations were vulnerable for issues like the one we are facing now. In 1999, Dan J. Bernstein released his nameserver (djbdns ), which already contained the countermeasures being rushed into service now. Let me repeat this. Wise people already saw this one coming 9 years ago, and had a fix in place." --Curtis From Valdis.Kletnieks at vt.edu Tue Aug 4 13:19:08 2009 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Tue, 04 Aug 2009 14:19:08 -0400 Subject: Dan Kaminsky In-Reply-To: Your message of "Tue, 04 Aug 2009 13:32:42 EDT." <4A7870BA.4020704@xyonet.com> References: <4b6ee9310907291453y6da24d19l21cc5345bd8f08a2@mail.gmail.com> <4A711E00.7030602@trelane.net> <7C332C86-7E7C-4C4E-8ADD-61310CA0758C@kyx.net> <4b6ee9310908010810w50796caenac7471b94fac1792@mail.gmail.com> <4A7870BA.4020704@xyonet.com> Message-ID: <21558.1249409948@turing-police.cc.vt.edu> On Tue, 04 Aug 2009 13:32:42 EDT, Curtis Maurand said: > > What does this have to do with Nanog, the guy found a critical > > security bug on DNS last year. > > > He didn't find it. He only publicized it. the guy who wrote djbdns > fount it years ago. Powerdns was patched for the flaw a year and a half > before Kaminsky published his article. Yeah, and Robert Morris Sr wrote about a mostly-theoretical issue with TCP sequence numbers back in 1985. Then a decade later, some dude named Mitnick whacked the workstation of this whitehat Shimomura, and the industry collectively went "Oh ****, it isn't just theoretical" and Steve Bellovin got to write RFC1948. (Mitnick was the first *well known* attack using it that I know of - anybody got a citation for an earlier usage, either well-known or 0-day?) > "Wise people already saw this one coming 9 years ago, and had a fix in place." Yes, but a wise man without a PR agent doesn't do the *rest* of the community much good. A Morris or Bernstein may *see* the problem a decade before, but it may take a Mitnick or Kaminsky to make the *rest* of us able to see it... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 226 bytes Desc: not available URL: From swmike at swm.pp.se Tue Aug 4 13:25:28 2009 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Tue, 4 Aug 2009 20:25:28 +0200 (CEST) Subject: Dan Kaminsky In-Reply-To: <21558.1249409948@turing-police.cc.vt.edu> References: <4b6ee9310907291453y6da24d19l21cc5345bd8f08a2@mail.gmail.com> <4A711E00.7030602@trelane.net> <7C332C86-7E7C-4C4E-8ADD-61310CA0758C@kyx.net> <4b6ee9310908010810w50796caenac7471b94fac1792@mail.gmail.com> <4A7870BA.4020704@xyonet.com> <21558.1249409948@turing-police.cc.vt.edu> Message-ID: On Tue, 4 Aug 2009, Valdis.Kletnieks at vt.edu wrote: > Yes, but a wise man without a PR agent doesn't do the *rest* of the > community much good. A Morris or Bernstein may *see* the problem a > decade before, but it may take a Mitnick or Kaminsky to make the *rest* > of us able to see it... Same thing to get the industry to scramble to get rid of MD5 in SSL-certs, known for a long time, when it was shown to be practical it didn't take that long to get rid of. People want proof, not theory. -- Mikael Abrahamsson email: swmike at swm.pp.se From oberman at es.net Tue Aug 4 13:32:46 2009 From: oberman at es.net (Kevin Oberman) Date: Tue, 04 Aug 2009 11:32:46 -0700 Subject: Dan Kaminsky In-Reply-To: Your message of "Tue, 04 Aug 2009 13:32:42 EDT." <4A7870BA.4020704@xyonet.com> Message-ID: <20090804183246.B69B41CC34@ptavv.es.net> > Date: Tue, 04 Aug 2009 13:32:42 -0400 > From: Curtis Maurand > > andrew.wallace wrote: > > On Thu, Jul 30, 2009 at 11:48 PM, Dragos Ruiu wrote: > > > >> at the risk of adding to the metadiscussion. what does any of this have to > >> do with nanog? > >> (sorry I'm kinda irritable about character slander being spammed out > >> unnecessarily to unrelated public lists lately ;-P ) > >> > >> > > > > What does this have to do with Nanog, the guy found a critical > > security bug on DNS last year. > > > He didn't find it. He only publicized it. the guy who wrote djbdns > fount it years ago. Powerdns was patched for the flaw a year and a half > before Kaminsky published his article. > > http://blog.netherlabs.nl/articles/2008/07/09/some-thoughts-on-the-recent-dns-vulnerability > > "However - the parties involved aren't to be lauded for their current > fix. Far from it. It has been known since 1999 that all nameserver > implementations were vulnerable for issues like the one we are facing > now. In 1999, Dan J. Bernstein released his > nameserver (djbdns ), which already > contained the countermeasures being rushed into service now. Let me > repeat this. Wise people already saw this one coming 9 years ago, and > had a fix in place." Dan K. has never claimed to have "discovered' the vulnerability. As the article says, it's been know for years and djb did suggest a means to MINIMIZE this vulnerability. There is NO fix. There never will be as the problem is architectural to the most fundamental operation of DNS. Other than replacing DNS (not feasible), the only way to prevent this form of attack is DNSSEC. The "fix" only makes it much harder to exploit. What Dan K. did was to discover a very clever way to exploit the design flaw in DNS that allowed the attack. What had been a known problem that was not believed to be generally exploitable became a real threat to the Internet. Suddenly people realized that an attack of this sort was not only possible, but quick and easy (relatively). Dan K. did what a security professional should do...he talked to the folks who were responsible for most DNS implementations that did caching and a work-around was developed before the attack mechanism was made public. He was given credit for finding the attack method, but the press seemed to get it wrong (as they often do) and lots of stories credited him with finding the vulnerability. By the way, I know that Paul Vixie noted this vulnerability quite some years ago, but I don't know if his report was before or after djb's. Now, rather then argue about the history of this problem (non-operational), can we stick to operational issues like implementing DNSSEC to really fix it (operational)? Is your DNS data signed? (No, mine is not and probably won't be for another week or two.) -- 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 patrick at ianai.net Tue Aug 4 13:40:34 2009 From: patrick at ianai.net (Patrick W. Gilmore) Date: Tue, 4 Aug 2009 14:40:34 -0400 Subject: Dan Kaminsky In-Reply-To: <20090804183246.B69B41CC34@ptavv.es.net> References: <20090804183246.B69B41CC34@ptavv.es.net> Message-ID: <6F003C90-4108-4B7B-8970-F8E8B40F0A0D@ianai.net> > There is NO fix. There never will be as the problem is architectural > to the most fundamental operation of DNS. Other than replacing DNS > (not > feasible), the only way to prevent this form of attack is DNSSEC. The > "fix" only makes it much harder to exploit. Randomizing source ports and QIDs simply increases entropy, making it harder to spoof an answer. If this is not a "fix", then DNSSEC is not a fix either, as it only increases entropy as well. Admitted, DNSSEC increases it a great deal more, but by your definition, it is not a "fix". -- TTFN, patrick On Aug 4, 2009, at 2:32 PM, Kevin Oberman wrote: >> Date: Tue, 04 Aug 2009 13:32:42 -0400 >> From: Curtis Maurand >> >> andrew.wallace wrote: >>> On Thu, Jul 30, 2009 at 11:48 PM, Dragos Ruiu wrote: >>> >>>> at the risk of adding to the metadiscussion. what does any of >>>> this have to >>>> do with nanog? >>>> (sorry I'm kinda irritable about character slander being spammed >>>> out >>>> unnecessarily to unrelated public lists lately ;-P ) >>>> >>>> >>> >>> What does this have to do with Nanog, the guy found a critical >>> security bug on DNS last year. >>> >> He didn't find it. He only publicized it. the guy who wrote djbdns >> fount it years ago. Powerdns was patched for the flaw a year and a >> half >> before Kaminsky published his article. >> >> http://blog.netherlabs.nl/articles/2008/07/09/some-thoughts-on-the-recent-dns-vulnerability >> >> "However - the parties involved aren't to be lauded for their current >> fix. Far from it. It has been known since 1999 that all nameserver >> implementations were vulnerable for issues like the one we are facing >> now. In 1999, Dan J. Bernstein released >> his >> nameserver (djbdns ), which already >> contained the countermeasures being rushed into service now. Let me >> repeat this. Wise people already saw this one coming 9 years ago, and >> had a fix in place." > > Dan K. has never claimed to have "discovered' the vulnerability. As > the > article says, it's been know for years and djb did suggest a means to > MINIMIZE this vulnerability. > > There is NO fix. There never will be as the problem is architectural > to the most fundamental operation of DNS. Other than replacing DNS > (not > feasible), the only way to prevent this form of attack is DNSSEC. The > "fix" only makes it much harder to exploit. > > What Dan K. did was to discover a very clever way to exploit the > design > flaw in DNS that allowed the attack. What had been a known problem > that > was not believed to be generally exploitable became a real threat to > the > Internet. Suddenly people realized that an attack of this sort was not > only possible, but quick and easy (relatively). Dan K. did what a > security professional should do...he talked to the folks who were > responsible for most DNS implementations that did caching and a > work-around was developed before the attack mechanism was made public. > > He was given credit for finding the attack method, but the press > seemed > to get it wrong (as they often do) and lots of stories credited him > with > finding the vulnerability. > > By the way, I know that Paul Vixie noted this vulnerability quite some > years ago, but I don't know if his report was before or after djb's. > > Now, rather then argue about the history of this problem > (non-operational), can we stick to operational issues like > implementing > DNSSEC to really fix it (operational)? Is your DNS data signed? (No, > mine is not and probably won't be for another week or two.) > -- > 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 vixie at isc.org Tue Aug 4 14:25:54 2009 From: vixie at isc.org (Paul Vixie) Date: Tue, 04 Aug 2009 19:25:54 +0000 Subject: Dan Kaminsky In-Reply-To: <4A7870BA.4020704@xyonet.com> (Curtis Maurand's message of "Tue\, 04 Aug 2009 13\:32\:42 -0400") References: <4b6ee9310907291453y6da24d19l21cc5345bd8f08a2@mail.gmail.com> <4A711E00.7030602@trelane.net> <7C332C86-7E7C-4C4E-8ADD-61310CA0758C@kyx.net> <4b6ee9310908010810w50796caenac7471b94fac1792@mail.gmail.com> <4A7870BA.4020704@xyonet.com> Message-ID: Curtis Maurand writes: >> What does this have to do with Nanog, the guy found a critical >> security bug on DNS last year. > > He didn't find it. He only publicized it. the guy who wrote djbdns fount > it years ago. first blood on both the DNS TXID attack, and on what we now call the Kashpureff attack, goes to chris schuba who published in 1993: http://ftp.cerias.purdue.edu/pub/papers/christoph-schuba/schuba-DNS-msthesis.pdf i didn't pay any special heed to it since there was no way to get enough bites at the apple due to negative caching. when i saw djb's announcement (i think in 1999 or 2000, so, seven years after schuba's paper came out) i said, geez, that's a lot of code complexity and kernel overhead for a problem that can occur at most once per DNS TTL. and sure enough when we did finally put source port randomization into BIND it crashed a bunch of kernels and firewalls and NATs, and is still paying painful dividends for large ISP's who are now forced to implement it. why forced? what was it about kaminsky's announcement that changed this from a once-per-TTL problem that didn't deserve this complex/costly solution into a once-per-packet problem that made the world sit up and care? if you don't know the answer off the top of your head, then maybe do some reading or ask somebody privately, rather than continuing to announce in public that bernstein's problem statement was the same as kaminsky's problem statement. and, always give credit to chris schuba, who got there first. > Powerdns was patched for the flaw a year and a half before > Kaminsky published his article. nevertheless bert was told about the problem and was given a lengthy window in which to test or improve his solutions for it. and i think openbsd may have had source port randomization first, since they do it in their kernel when you try to bind(2) to port 0. most kernels are still very predictable when they're assigning a UDP port to an outbound socket. -- Paul Vixie KI6YSY From dr at kyx.net Tue Aug 4 16:31:13 2009 From: dr at kyx.net (Dragos Ruiu) Date: Tue, 4 Aug 2009 14:31:13 -0700 Subject: Dan Kaminsky In-Reply-To: <4b6ee9310908032143t1737ab53lf0883929f6c118df@mail.gmail.com> References: <4b6ee9310907291453y6da24d19l21cc5345bd8f08a2@mail.gmail.com> <4A711E00.7030602@trelane.net> <7C332C86-7E7C-4C4E-8ADD-61310CA0758C@kyx.net> <4b6ee9310908010810w50796caenac7471b94fac1792@mail.gmail.com> <20090804010235.GT51443@gerbil.cluepon.net> <4b6ee9310908032143t1737ab53lf0883929f6c118df@mail.gmail.com> Message-ID: On 3-Aug-09, at 9:43 PM, andrew.wallace wrote: > Hi, > > Read my post one more time and think though: Only "zf0" are legally > in the shit. > > The guy "Dragos Ruiu" has absolutely no case against me. > > Copy & paste doesn't count as defamation, speak to Wired's legal team > if you have an issue. > > Cheers, > > Andrew > Whoa. Feeling a tad defensive? ;-P I used slander specifically. Any defamation from referenced emails is short-lived. ;-) cheers, --dr > On Tue, Aug 4, 2009 at 2:02 AM, Richard A Steenbergen gerbil.net> wrote: >> On Sat, Aug 01, 2009 at 01:11:17PM -0700, Cord MacLeod wrote: >>> I don't see a video attached or an audio recording. Thus no >>> slander. >>> >>> Libel on the other hand is a different matter. >> >> You have those backwards. Slander is transitory (i.e. spoken) >> defamation, libel is written/recorded/etc non-transitory defamation. >> This seems like a group that could benefit from knowing those two >> words. >> :) >> >> -- >> Richard A Steenbergen http://www.e-gerbil.net/ras >> GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA >> F8B1 2CBC) >> >> > From nanog at daork.net Tue Aug 4 19:58:00 2009 From: nanog at daork.net (Nathan Ward) Date: Wed, 5 Aug 2009 12:58:00 +1200 Subject: cisco.com In-Reply-To: <0B608FCDCF43BF4C9194C896C53202435D8D2A@mnsg-svr2.mnsg.net> References: <0B608FCDCF43BF4C9194C896C53202435D8D2A@mnsg-svr2.mnsg.net> Message-ID: On 5/08/2009, at 1:34 AM, R. Benjamin Kessler wrote: > Hey Gang - > > I'm unable to get to cisco.com from multiple places on the 'net > (including downforeveryoneorjustme.com); any ideas on the cause and > ETR? CCNAs everywhere panic as their monitoring tools tell them that the 'Internet' is down. -- Nathan Ward From mkarir at merit.edu Tue Aug 4 21:06:17 2009 From: mkarir at merit.edu (mkarir) Date: Tue, 4 Aug 2009 22:06:17 -0400 Subject: IM based BGP route-server interface Message-ID: <25376C1E-AD6F-4F27-BD21-824873775FBE@merit.edu> All, We have been experimenting with Instant Messaging as an interface for providing easier access to a route-server. (no longer need to telnet xyz or use annoying web forms). We have essentially created a BGP chat bot. You can reach it by adding AIM: bgpbotz ( or Jabber: bgpbotz at jabber.merit.edu) to your buddy list. Just type 'help' or '?' to get started or 'examples'. Most normal route-server queries are supported. You should be able to view routes from Merit's perspective by querying bgpbotz. We would really appreciate any feedback on this project. The website is at: http://software.merit.edu/bgpbotz As bgpbotz is essentially just a query interface to an underlying route-server we would be happpy to add your BGP feeds to our installation and make them available as "views" for other people to query. Please feel free to contact us if you are interested in setting this up. Alternately you can download the chat bot code from the website and run it yourself. In that case please let us know so that we can add your bot to the project website. All comments are welcome. Thanks Eric Wustrow Manish Karir (Merit Network Inc.) From clenton at gmail.com Tue Aug 4 21:36:28 2009 From: clenton at gmail.com (Christopher Lenton) Date: Wed, 5 Aug 2009 12:36:28 +1000 Subject: cisco.com In-Reply-To: References: <0B608FCDCF43BF4C9194C896C53202435D8D2A@mnsg-svr2.mnsg.net> Message-ID: 2009/8/5 Nathan Ward > On 5/08/2009, at 1:34 AM, R. Benjamin Kessler wrote: > > Hey Gang - >> >> I'm unable to get to cisco.com from multiple places on the 'net >> (including downforeveryoneorjustme.com); any ideas on the cause and ETR? >> > > > CCNAs everywhere panic as their monitoring tools tell them that the > 'Internet' is down. > > -- > Nathan Ward > > > Oh the hilarity From bert.hubert at netherlabs.nl Wed Aug 5 01:24:16 2009 From: bert.hubert at netherlabs.nl (bert hubert) Date: Wed, 5 Aug 2009 08:24:16 +0200 Subject: Dan Kaminsky In-Reply-To: References: <4b6ee9310907291453y6da24d19l21cc5345bd8f08a2@mail.gmail.com> <4A711E00.7030602@trelane.net> <7C332C86-7E7C-4C4E-8ADD-61310CA0758C@kyx.net> <4b6ee9310908010810w50796caenac7471b94fac1792@mail.gmail.com> <4A7870BA.4020704@xyonet.com> Message-ID: <3efd34cc0908042324g31c3c8fdrf442cc03fba8fd72@mail.gmail.com> On Tue, Aug 4, 2009 at 9:25 PM, Paul Vixie wrote: > i didn't pay any special heed to it since there was no way to get enough > bites at the apple due to negative caching. when i saw djb's announcement > (i think in 1999 or 2000, so, seven years after schuba's paper came out) i > said, geez, that's a lot of code complexity and kernel overhead for a > problem that can occur at most once per DNS TTL. and sure enough when we Even then it was worth it, and it was silly that the DNS community ignored him. Note that work on RFC 5452 started two years before Kaminksy's announcement. >> Powerdns was patched for the flaw a year and a half before >> Kaminsky published his article. > > nevertheless bert was told about the problem and was given a lengthy window > in which to test or improve his solutions for it. and i think openbsd may You told me about the problem so I would not accidentally reveal it in process of working on and discussing my draft. You also told me you'd block progress of the draft until after the Kaminsky announcement. And given the tactics you employ on the IETF DNSEXT mailinglist, I knew you'd succeed. Recall that the draft contained 'MUST' wording that would've made it embarrassing for BIND *not* to implement source port randomization. I didn't have to make any changes to PowerDNS as I was aware of the danger of using a single source port already. In addition, remember the one famous succeeded attempt to spoof a source port randomizing nameserver, which took 10 hours and gigabit speeds? The same guy attempted this attack against PowerDNS, and failed for a simple (and accidental) reason. It turns out that PowerDNS query throttling and PowerDNS timeout caching makes it very hard to find the sweet spot between generating enough queries to spoof a domain in a timely manner, but not overloading the server or the network to the point that timeouts will be generated, which leads to PowerDNS to no longer sending out queries. That does not mean that I think the DNS is 'safe' now. My other attempt to increase DNS security in a simple way ('EDNS PING') was blocked as effectively as the RFC 5452 drafts were, and I've given up on that route. See http://www.ops.ietf.org/lists/namedroppers/namedroppers.2009/msg00760.html I'll be at HAR2009 next week, and I understand both Kaminksy and EDNS-PING co-author David Ulevitch will be there, which should be fun. I'll also be presenting on DNS security risks, which will cover the subjects above as well. Bert From rmacharia at gmail.com Wed Aug 5 05:13:46 2009 From: rmacharia at gmail.com (Raymond Macharia) Date: Wed, 5 Aug 2009 13:13:46 +0300 Subject: East Africa Fibre Connectivity- Heads up Message-ID: Hello all,in the last two weeks or so providers in East Africa, particularly in Kenya where I am, have been moving from Satellite to Fibre for the internet Back bone connectivity. From where I am I have seen an upsurge of about 100Mbps in the last two days from my users. It would be interesting to know if anyone out there has seen an increase in traffic from this region and by how much. There is more to come as providers are cutting prices and adding bandwidth to their networks. Best Regards Raymond Macharia From fred at cisco.com Wed Aug 5 08:52:50 2009 From: fred at cisco.com (Fred Baker) Date: Wed, 5 Aug 2009 09:52:50 -0400 Subject: East Africa Fibre Connectivity- Heads up In-Reply-To: References: Message-ID: That is very much to be expected, if nothing else due to pent-up demand. The existing vsat infrastructure tends to be pretty saturated, meaning that users experience a lot of loss as well as delay. What if they stop losing traffic? War story: in 1995 I found myself sharing a podium with Phill Gross, who was then a VP with MCI. He was more or less apologizing for the behavior of his network. They had recently upgraded to a then-new-and- gee-whiz OC-3 infrastructure, in many places using parallel bandwidth, and were dropping a lot - he reported one link to be dropping 20%. So they then upgraded the whole thing to OC-12 - and fiber that was OC-3 was replaced with an OC-12. They presumed that this would give them 75% overprovisioning at worst. What they actually saw was that those links that had been dropping 20% were now dropping 4%. TCP observed that it was not getting crunched into the ground, and started opening its windows. The other big issue with satcom is of course delay, and with conversion to fiber the delay plummets. That means that where you might have had connections running at average speed due to RTT, the average connection speed for the same session is instantly multiplied by /. That gives the user time and incentive to click again during that same time window - new load. Price is very important, of course, but I suspect your 100 MBPS is explainable by simple network dynamics. On Aug 5, 2009, at 6:13 AM, Raymond Macharia wrote: > Hello all,in the last two weeks or so providers in East Africa, > particularly > in Kenya where I am, have been moving from Satellite to Fibre for the > internet Back bone connectivity. From where I am I have seen an > upsurge of > about 100Mbps in the last two days from my users. It would be > interesting to > know if anyone out there has seen an increase in traffic from this > region > and by how much. There is more to come as providers are cutting > prices and > adding bandwidth to their networks. > > Best Regards > > Raymond Macharia From bicknell at ufp.org Wed Aug 5 09:18:11 2009 From: bicknell at ufp.org (Leo Bicknell) Date: Wed, 5 Aug 2009 10:18:11 -0400 Subject: Dan Kaminsky In-Reply-To: <20090804183246.B69B41CC34@ptavv.es.net> References: <4A7870BA.4020704@xyonet.com> <20090804183246.B69B41CC34@ptavv.es.net> Message-ID: <20090805141810.GA24211@ussenterprise.ufp.org> In a message written on Tue, Aug 04, 2009 at 11:32:46AM -0700, Kevin Oberman wrote: > There is NO fix. There never will be as the problem is architectural > to the most fundamental operation of DNS. Other than replacing DNS (not > feasible), the only way to prevent this form of attack is DNSSEC. The > "fix" only makes it much harder to exploit. I don't understand why replacing DNS is "not feasible". -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 825 bytes Desc: not available URL: From fweimer at bfk.de Wed Aug 5 09:32:27 2009 From: fweimer at bfk.de (Florian Weimer) Date: Wed, 05 Aug 2009 14:32:27 +0000 Subject: Dan Kaminsky In-Reply-To: <20090805141810.GA24211@ussenterprise.ufp.org> (Leo Bicknell's message of "Wed\, 5 Aug 2009 10\:18\:11 -0400") References: <4A7870BA.4020704@xyonet.com> <20090804183246.B69B41CC34@ptavv.es.net> <20090805141810.GA24211@ussenterprise.ufp.org> Message-ID: <823a86cow4.fsf@mid.bfk.de> * Leo Bicknell: > In a message written on Tue, Aug 04, 2009 at 11:32:46AM -0700, Kevin Oberman wrote: >> There is NO fix. There never will be as the problem is architectural >> to the most fundamental operation of DNS. Other than replacing DNS (not >> feasible), the only way to prevent this form of attack is DNSSEC. The >> "fix" only makes it much harder to exploit. > > I don't understand why replacing DNS is "not feasible". Replacing the namespace is not feasible because any newcomer will lack the liability shield ICANN, root operators, TLD registries, and registrars have established for the Internet DNS root, so it will never get beyond the stage of hashing out the legal issues. We might have an alternative one day, but it's going to happen by accident, through generalization of an internal naming service employed by a widely-used application. There are several successful application-specific naming services which are independent of DNS, but all the attempts at replacing DNS as a general-purpose naming service have failed. The transport protocol is a separate issue. It is feasible to change it, but the IETF has a special working group which is currently tasked to prevent any such changes. -- Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra?e 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From nick at foobar.org Wed Aug 5 09:37:57 2009 From: nick at foobar.org (Nick Hilliard) Date: Wed, 05 Aug 2009 15:37:57 +0100 Subject: Dan Kaminsky In-Reply-To: <20090805141810.GA24211@ussenterprise.ufp.org> References: <4A7870BA.4020704@xyonet.com> <20090804183246.B69B41CC34@ptavv.es.net> <20090805141810.GA24211@ussenterprise.ufp.org> Message-ID: <4A799945.8030806@foobar.org> On 05/08/2009 15:18, Leo Bicknell wrote: > I don't understand why replacing DNS is "not feasible". I'd be happy to think about replacing the DNS as soon as we've finished off migrating to an ipv6-only internet in a year or two. Shall we set up a committee to try to make it happen faster? Nick From rdobbins at arbor.net Wed Aug 5 09:43:31 2009 From: rdobbins at arbor.net (Roland Dobbins) Date: Wed, 5 Aug 2009 21:43:31 +0700 Subject: DNS alternatives (was Re: Dan Kaminsky) In-Reply-To: <823a86cow4.fsf@mid.bfk.de> References: <4A7870BA.4020704@xyonet.com> <20090804183246.B69B41CC34@ptavv.es.net> <20090805141810.GA24211@ussenterprise.ufp.org> <823a86cow4.fsf@mid.bfk.de> Message-ID: <825C8AC7-C01E-4934-92FD-E7B9E8091A3A@arbor.net> On Aug 5, 2009, at 9:32 PM, Florian Weimer wrote: > We might have an alternative one day, but it's going to happen by > accident, through generalization of an internal naming service > employed by a widely-used application. Or even more likely, IMHO, that more and more applications will have their own naming services which will gradually reduce the perceived need for a general-purpose system - i.e., the centrality of DNS won't be subsumed into any single system (remember X.500?), but, rather, by a multiplicity of systems. [Note that I'm not advocating this particular approach; I just think it's the most likely scenario.] Compression/conflation of the transport stack will likely be both a driver and an effect of this trend, over time. ----------------------------------------------------------------------- Roland Dobbins // Unfortunately, inefficiency scales really well. -- Kevin Lawton From marka at isc.org Wed Aug 5 10:11:22 2009 From: marka at isc.org (Mark Andrews) Date: Thu, 06 Aug 2009 01:11:22 +1000 Subject: DNS alternatives (was Re: Dan Kaminsky) In-Reply-To: Your message of "Wed, 05 Aug 2009 21:43:31 +0700." <825C8AC7-C01E-4934-92FD-E7B9E8091A3A@arbor.net> References: <4A7870BA.4020704@xyonet.com> <20090804183246.B69B41CC34@ptavv.es.net> <20090805141810.GA24211@ussenterprise.ufp.org> <823a86cow4.fsf@mid.bfk.de> <825C8AC7-C01E-4934-92FD-E7B9E8091A3A@arbor.net> Message-ID: <200908051511.n75FBMO4095809@drugs.dv.isc.org> In message <825C8AC7-C01E-4934-92FD-E7B9E8091A3A at arbor.net>, Roland Dobbins wri tes: > > On Aug 5, 2009, at 9:32 PM, Florian Weimer wrote: > > > We might have an alternative one day, but it's going to happen by > > accident, through generalization of an internal naming service > > employed by a widely-used application. > > Or even more likely, IMHO, that more and more applications will have > their own naming services which will gradually reduce the perceived > need for a general-purpose system - i.e., the centrality of DNS won't > be subsumed into any single system (remember X.500?), but, rather, by > a multiplicity of systems. Been there, done that, doesn't work well. For all it's short comings the DNS and the single namespace it brings is much better than having a multitude of namespaces. Yes I've had to work with a multitude of namespaces and had to map between them. Ugly. > [Note that I'm not advocating this particular approach; I just think > it's the most likely scenario.] > > Compression/conflation of the transport stack will likely be both a > driver and an effect of this trend, over time. > > ----------------------------------------------------------------------- > Roland Dobbins // > > Unfortunately, inefficiency scales really well. > > -- Kevin Lawton > > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From eriks at nationalfastfreight.com Wed Aug 5 10:20:21 2009 From: eriks at nationalfastfreight.com (Erik Soosalu) Date: Wed, 5 Aug 2009 11:20:21 -0400 Subject: DNS alternatives (was Re: Dan Kaminsky) In-Reply-To: <825C8AC7-C01E-4934-92FD-E7B9E8091A3A@arbor.net> References: <4A7870BA.4020704@xyonet.com><20090804183246.B69B41CC34@ptavv.es.net><20090805141810.GA24211@ussenterprise.ufp.org><823a86cow4.fsf@mid.bfk.de> <825C8AC7-C01E-4934-92FD-E7B9E8091A3A@arbor.net> Message-ID: <0B224A2FE01CC54C860290D42474BF6003DFA4A6@exchange.nff.local> Multiple systems end up with problems. Even standard DNS blows up when some company (Apple) decides that an extension (.local) should not be forwarded to the DNS servers on some device (iPhone) because their service (Bonjour) uses it. Thanks, Erik -----Original Message----- From: Roland Dobbins [mailto:rdobbins at arbor.net] Sent: Wednesday, August 05, 2009 10:44 AM To: NANOG list Subject: DNS alternatives (was Re: Dan Kaminsky) On Aug 5, 2009, at 9:32 PM, Florian Weimer wrote: > We might have an alternative one day, but it's going to happen by > accident, through generalization of an internal naming service > employed by a widely-used application. Or even more likely, IMHO, that more and more applications will have their own naming services which will gradually reduce the perceived need for a general-purpose system - i.e., the centrality of DNS won't be subsumed into any single system (remember X.500?), but, rather, by a multiplicity of systems. [Note that I'm not advocating this particular approach; I just think it's the most likely scenario.] Compression/conflation of the transport stack will likely be both a driver and an effect of this trend, over time. ----------------------------------------------------------------------- Roland Dobbins // Unfortunately, inefficiency scales really well. -- Kevin Lawton From rdobbins at arbor.net Wed Aug 5 10:24:56 2009 From: rdobbins at arbor.net (Roland Dobbins) Date: Wed, 5 Aug 2009 22:24:56 +0700 Subject: DNS alternatives (was Re: Dan Kaminsky) In-Reply-To: <200908051511.n75FBMO4095809@drugs.dv.isc.org> References: <4A7870BA.4020704@xyonet.com> <20090804183246.B69B41CC34@ptavv.es.net> <20090805141810.GA24211@ussenterprise.ufp.org> <823a86cow4.fsf@mid.bfk.de> <825C8AC7-C01E-4934-92FD-E7B9E8091A3A@arbor.net> <200908051511.n75FBMO4095809@drugs.dv.isc.org> Message-ID: <028622E2-8409-4DDB-AED3-0CFAEB422E80@arbor.net> On Aug 5, 2009, at 10:11 PM, Mark Andrews wrote: > For all it's short comings the DNS and the single namespace it > brings is much better than > having a multitude of namespaces. I agree with you, but I don't think this approach is going to persist as the standard model. Increasingly, transport and what we now call layer-7 are going to become conflated (we already see all these Rube Goldberg-type mechanisms to try and accomplish this OOB now, with predictable results), and that's going to lead to APIs/data types embedding this information, IMHO. ----------------------------------------------------------------------- Roland Dobbins // Unfortunately, inefficiency scales really well. -- Kevin Lawton From rdobbins at arbor.net Wed Aug 5 10:25:55 2009 From: rdobbins at arbor.net (Roland Dobbins) Date: Wed, 5 Aug 2009 22:25:55 +0700 Subject: DNS alternatives (was Re: Dan Kaminsky) In-Reply-To: <0B224A2FE01CC54C860290D42474BF6003DFA4A6@exchange.nff.local> References: <4A7870BA.4020704@xyonet.com><20090804183246.B69B41CC34@ptavv.es.net><20090805141810.GA24211@ussenterprise.ufp.org><823a86cow4.fsf@mid.bfk.de> <825C8AC7-C01E-4934-92FD-E7B9E8091A3A@arbor.net> <0B224A2FE01CC54C860290D42474BF6003DFA4A6@exchange.nff.local> Message-ID: <72C2F8C1-D188-41EB-BEC3-7020DD603F3F@arbor.net> On Aug 5, 2009, at 10:20 PM, Erik Soosalu wrote: > Multiple systems end up with problems. Yes, and again, I'm not advocating this approach. I just think it's most likely where we're going to end up, long-term. ----------------------------------------------------------------------- Roland Dobbins // Unfortunately, inefficiency scales really well. -- Kevin Lawton From rmacharia at gmail.com Wed Aug 5 10:24:07 2009 From: rmacharia at gmail.com (Raymond Macharia) Date: Wed, 5 Aug 2009 18:24:07 +0300 Subject: East Africa Fibre Connectivity- Heads up In-Reply-To: References: Message-ID: You are right the 100Mbps is pure network dynamics. right now we are adapting a wait and see but your added war story means we have to do more watching as well Raymond Macharia On Wed, Aug 5, 2009 at 4:52 PM, Fred Baker wrote: > That is very much to be expected, if nothing else due to pent-up demand. > The existing vsat infrastructure tends to be pretty saturated, meaning that > users experience a lot of loss as well as delay. What if they stop losing > traffic? > > War story: in 1995 I found myself sharing a podium with Phill Gross, who > was then a VP with MCI. He was more or less apologizing for the behavior of > his network. They had recently upgraded to a then-new-and-gee-whiz OC-3 > infrastructure, in many places using parallel bandwidth, and were dropping a > lot - he reported one link to be dropping 20%. So they then upgraded the > whole thing to OC-12 - and fiber that was OC-3 was replaced with an OC-12. > They presumed that this would give them 75% overprovisioning at worst. What > they actually saw was that those links that had been dropping 20% were now > dropping 4%. TCP observed that it was not getting crunched into the ground, > and started opening its windows. > > The other big issue with satcom is of course delay, and with conversion to > fiber the delay plummets. That means that where you might have had > connections running at average speed due to RTT, the average > connection speed for the same session is instantly multiplied by > /. That gives the user time and incentive to click again > during that same time window - new load. > > Price is very important, of course, but I suspect your 100 MBPS is > explainable by simple network dynamics. > > > On Aug 5, 2009, at 6:13 AM, Raymond Macharia wrote: > > Hello all,in the last two weeks or so providers in East Africa, >> particularly >> in Kenya where I am, have been moving from Satellite to Fibre for the >> internet Back bone connectivity. From where I am I have seen an upsurge of >> about 100Mbps in the last two days from my users. It would be interesting >> to >> know if anyone out there has seen an increase in traffic from this region >> and by how much. There is more to come as providers are cutting prices and >> adding bandwidth to their networks. >> >> Best Regards >> >> Raymond Macharia >> > > From ebroo at setuidzero.org Wed Aug 5 10:35:52 2009 From: ebroo at setuidzero.org (Edward Brookhouse) Date: Wed, 5 Aug 2009 11:35:52 -0400 Subject: Sprint/Verizon BGP Message-ID: <000601ca15e2$6a940c40$3fbc24c0$@org> Hi all, Any Sprint BGP admins on this list can offer any thoughts on why Sprint connected networks are preferring my Sprint connection when they should be preferring my Verizon? I (Healthy Directions) am AS16387, two blocks 63.73.158.0/24 and 63.78.31.0/24, being announced by sprint and Verizon, preferred to Verizon(DS3) over Sprint 3MB. Verizon BGP admins think everything is ok, have not heard back from BGP4 at sprint. Any thoughts appreciated, off-list contact welcome. Edward ebroo at healthydirections.com From robert at ufl.edu Wed Aug 5 10:39:54 2009 From: robert at ufl.edu (Robert D. Scott) Date: Wed, 5 Aug 2009 11:39:54 -0400 Subject: Sprint/Verizon BGP In-Reply-To: <000601ca15e2$6a940c40$3fbc24c0$@org> References: <000601ca15e2$6a940c40$3fbc24c0$@org> Message-ID: <056c01ca15e2$fa7abb60$ef703220$@edu> They will almost always prefer their IBGP to any learned routes. Why send traffic to a transit network and skew their I/O peering numbers when you can handle it yourself. I doubt you will change their mind. Robert D. Scott Robert at ufl.edu Senior Network Engineer 352-273-0113 Phone CNS - Network Services 352-392-2061 CNS Phone Tree University of Florida 352-392-9440 FAX Florida Lambda Rail 352-294-3571 FLR NOC Gainesville, FL 32611 321-663-0421 Cell -----Original Message----- From: Edward Brookhouse [mailto:ebroo at setuidzero.org] Sent: Wednesday, August 05, 2009 11:36 AM To: nanog at nanog.org Subject: Sprint/Verizon BGP Hi all, Any Sprint BGP admins on this list can offer any thoughts on why Sprint connected networks are preferring my Sprint connection when they should be preferring my Verizon? I (Healthy Directions) am AS16387, two blocks 63.73.158.0/24 and 63.78.31.0/24, being announced by sprint and Verizon, preferred to Verizon(DS3) over Sprint 3MB. Verizon BGP admins think everything is ok, have not heard back from BGP4 at sprint. Any thoughts appreciated, off-list contact welcome. Edward ebroo at healthydirections.com From morrowc.lists at gmail.com Wed Aug 5 10:48:09 2009 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Wed, 5 Aug 2009 11:48:09 -0400 Subject: Sprint/Verizon BGP In-Reply-To: <056c01ca15e2$fa7abb60$ef703220$@edu> References: <000601ca15e2$6a940c40$3fbc24c0$@org> <056c01ca15e2$fa7abb60$ef703220$@edu> Message-ID: <75cb24520908050848l1726e352vd2fffd8aa7fbacd3@mail.gmail.com> On Wed, Aug 5, 2009 at 11:39 AM, Robert D. Scott wrote: > They will almost always prefer their IBGP to any learned routes. ?Why send > traffic to a transit network and skew their I/O peering numbers when you can > handle it yourself. I doubt you will change their mind. http://onesc.net/communities/as1239/ uhm, prepend and/or localpref fiddling... -chris > Robert D. Scott ? ? ? ? ? ? ? ? Robert at ufl.edu > Senior Network Engineer ? ? ? ? 352-273-0113 Phone > CNS - Network Services ? ? ? ? ?352-392-2061 CNS Phone Tree > University of Florida ? ? ? ? ? 352-392-9440 FAX > Florida Lambda Rail ? ? ? ? ? ? 352-294-3571 FLR NOC > Gainesville, FL ?32611 ? ? ? ? ?321-663-0421 Cell > > > -----Original Message----- > From: Edward Brookhouse [mailto:ebroo at setuidzero.org] > Sent: Wednesday, August 05, 2009 11:36 AM > To: nanog at nanog.org > Subject: Sprint/Verizon BGP > > Hi all, > > > > Any Sprint BGP admins on this list can offer any thoughts on why Sprint > connected networks are preferring my Sprint connection when they should be > preferring my Verizon? > > > > I (Healthy Directions) am AS16387, two blocks 63.73.158.0/24 and > 63.78.31.0/24, being announced by sprint and Verizon, preferred to > Verizon(DS3) over Sprint 3MB. > > > > Verizon BGP admins think everything is ok, have not heard back from BGP4 at > sprint. > > > > Any thoughts appreciated, off-list contact welcome. > > > > Edward > > ebroo at healthydirections.com > > > > > > > > > From jlewis at lewis.org Wed Aug 5 10:48:47 2009 From: jlewis at lewis.org (Jon Lewis) Date: Wed, 5 Aug 2009 11:48:47 -0400 (EDT) Subject: Sprint/Verizon BGP In-Reply-To: <000601ca15e2$6a940c40$3fbc24c0$@org> References: <000601ca15e2$6a940c40$3fbc24c0$@org> Message-ID: On Wed, 5 Aug 2009, Edward Brookhouse wrote: > Any Sprint BGP admins on this list can offer any thoughts on why Sprint > connected networks are preferring my Sprint connection when they should be > preferring my Verizon? > > I (Healthy Directions) am AS16387, two blocks 63.73.158.0/24 and > 63.78.31.0/24, being announced by sprint and Verizon, preferred to > Verizon(DS3) over Sprint 3MB. I see you're prepending the heck out of your announcement to Sprint...but Sprint is apparently still prefering to use their internal/customer route to you rather than send your traffic across the internet. If you really want Sprint to not use your 3MB circuit unless the Verizon one is down, have a look at https://www.sprint.net/index.php?p=policy_bgp You probably want to lower their localpref for your routes. ---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From bicknell at ufp.org Wed Aug 5 11:07:03 2009 From: bicknell at ufp.org (Leo Bicknell) Date: Wed, 5 Aug 2009 12:07:03 -0400 Subject: Dan Kaminsky In-Reply-To: <823a86cow4.fsf@mid.bfk.de> References: <4A7870BA.4020704@xyonet.com> <20090804183246.B69B41CC34@ptavv.es.net> <20090805141810.GA24211@ussenterprise.ufp.org> <823a86cow4.fsf@mid.bfk.de> Message-ID: <20090805160703.GA35668@ussenterprise.ufp.org> In a message written on Wed, Aug 05, 2009 at 02:32:27PM +0000, Florian Weimer wrote: > The transport protocol is a separate issue. It is feasible to change > it, but the IETF has a special working group which is currently tasked > to prevent any such changes. My interest was in replacing the protocol. I've grown fond of the name space, for all of its warts. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 825 bytes Desc: not available URL: From johnl at iecc.com Wed Aug 5 11:48:23 2009 From: johnl at iecc.com (John Levine) Date: 5 Aug 2009 16:48:23 -0000 Subject: DNS hardening, was Re: Dan Kaminsky In-Reply-To: <4A7870BA.4020704@xyonet.com> Message-ID: <20090805164823.43774.qmail@simone.iecc.com> Other than DNSSEC, I'm aware of these relatively simple hacks to add entropy to DNS queries. 1) Random query ID 2) Random source port 3) Random case in queries, e.g. GooGLe.CoM 4) Ask twice (with different values for the first three hacks) and compare the answers I presume everyone is doing the first two. Any experience with the other two to report? R's, John From jmamodio at gmail.com Wed Aug 5 11:49:01 2009 From: jmamodio at gmail.com (Jorge Amodio) Date: Wed, 5 Aug 2009 11:49:01 -0500 Subject: Dan Kaminsky In-Reply-To: <20090805160703.GA35668@ussenterprise.ufp.org> References: <4A7870BA.4020704@xyonet.com> <20090804183246.B69B41CC34@ptavv.es.net> <20090805141810.GA24211@ussenterprise.ufp.org> <823a86cow4.fsf@mid.bfk.de> <20090805160703.GA35668@ussenterprise.ufp.org> Message-ID: <202705b0908050949p2285aef0qae1c78aa5f17f71a@mail.gmail.com> > My interest was in replacing the protocol. ?I've grown fond of the > name space, for all of its warts. As we evolved from circuit switching to packet switching, which many at the time said it would never work, and from the HOSTS.TXT to DNS, sooner or later the ?naming scheme? for resources on the net will imho in the future evolve to something better and different from DNS. No doubt for more than 25 years DNS has provided a great service, and it had many challenges and will continue for some time to do so. But DNS from being a simple way to provide name resolution evolved to something more complex, and also degenerated into a protocol/service that created a new industry when a monetary value was stuck to particular sequences of characters that require to be globally unique and the base to construct a URL. At some time in the future and when a new paradigm for the user interface is conceived, we may not longer have the end user ?typing? a URL, the DNS or something similar will still be in the background providing name to address mapping but there will be no more monetary value associated with it or that value will be transferred to something else. It may sound too futuristic and inspired from science fiction, but I never saw Captain Piccard typing a URL on the Enterprise. Sooner or later, we or the new generation of ietfers and nanogers, will need to start thinking about a new naming paradigm and design the services and protocols associated with it. The key question is, when we start? Meanwhile we have to live with what we have and try to improve it as much as we can. My .02 From bert.hubert at netherlabs.nl Wed Aug 5 12:12:38 2009 From: bert.hubert at netherlabs.nl (bert hubert) Date: Wed, 5 Aug 2009 19:12:38 +0200 Subject: DNS hardening, was Re: Dan Kaminsky In-Reply-To: <20090805164823.43774.qmail@simone.iecc.com> References: <4A7870BA.4020704@xyonet.com> <20090805164823.43774.qmail@simone.iecc.com> Message-ID: <3efd34cc0908051012q74fadfdej620cd0dcb20c1ea8@mail.gmail.com> On Wed, Aug 5, 2009 at 6:48 PM, John Levine wrote: > 3) Random case in queries, e.g. GooGLe.CoM > 4) Ask twice (with different values for the first three hacks) and > compare the answers > > I presume everyone is doing the first two. ?Any experience with the > other two to report? 3 works, but offers zero protection against 'kaminsky spoofing the root' since you can't fold the case of "123456789.". And the root is the goal. 4 breaks on Akamai and many other CDNs. Even 'ask thrice, and take the majority answer' doesn't work there. 5 is 'edns ping', but it was effectively blocked because people thought DNSSEC would be easier to do, or demanded that EDNS PING (http://edns-ping.org) would offer everything that DNSSEC offered. Bert From regnauld at catpipe.net Wed Aug 5 12:20:35 2009 From: regnauld at catpipe.net (Phil Regnauld) Date: Wed, 5 Aug 2009 19:20:35 +0200 Subject: Dan Kaminsky In-Reply-To: <202705b0908050949p2285aef0qae1c78aa5f17f71a@mail.gmail.com> References: <4A7870BA.4020704@xyonet.com> <20090804183246.B69B41CC34@ptavv.es.net> <20090805141810.GA24211@ussenterprise.ufp.org> <823a86cow4.fsf@mid.bfk.de> <20090805160703.GA35668@ussenterprise.ufp.org> <202705b0908050949p2285aef0qae1c78aa5f17f71a@mail.gmail.com> Message-ID: <20090805172035.GA80396@bluepipe.dk> Jorge Amodio (jmamodio) writes: > > It may sound too futuristic and inspired from science fiction, but I never saw > Captain Piccard typing a URL on the Enterprise. That's ok, I've never seen the Enterprise at the airport. > Sooner or later, we or the new generation of ietfers and nanogers, will need to > start thinking about a new naming paradigm and design the services and protocols > associated with it. > > The key question is, when we start? Let's see how far the SMTP replacement has come, and get some inspiration. Heck, it's an application that only _uses_ the DNS, should be easy. -- "Hey kid, go scan a /48" From cmadams at hiwaay.net Wed Aug 5 12:28:39 2009 From: cmadams at hiwaay.net (Chris Adams) Date: Wed, 5 Aug 2009 12:28:39 -0500 Subject: Dan Kaminsky In-Reply-To: <20090805172035.GA80396@bluepipe.dk> References: <4A7870BA.4020704@xyonet.com> <20090804183246.B69B41CC34@ptavv.es.net> <20090805141810.GA24211@ussenterprise.ufp.org> <823a86cow4.fsf@mid.bfk.de> <20090805160703.GA35668@ussenterprise.ufp.org> <202705b0908050949p2285aef0qae1c78aa5f17f71a@mail.gmail.com> <20090805172035.GA80396@bluepipe.dk> Message-ID: <20090805172839.GA745701@hiwaay.net> Once upon a time, Phil Regnauld said: > Jorge Amodio (jmamodio) writes: > > It may sound too futuristic and inspired from science fiction, but I never saw > > Captain Piccard typing a URL on the Enterprise. > > That's ok, I've never seen the Enterprise at the airport. I have, but not that Enterprise (I saw the space shuttle orbiter Enterprise on a 747 land here). > Let's see how far the SMTP replacement has come, and get some inspiration. > Heck, it's an application that only _uses_ the DNS, should be easy. There's always somebody looking to re-invent the wheel, but usually they are startups looking to make a quick buck by patenting and licensing their technology that "will be the savior of the Internet" (and so they don't get far). -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From jmamodio at gmail.com Wed Aug 5 12:30:39 2009 From: jmamodio at gmail.com (Jorge Amodio) Date: Wed, 5 Aug 2009 12:30:39 -0500 Subject: Dan Kaminsky In-Reply-To: <20090805172035.GA80396@bluepipe.dk> References: <4A7870BA.4020704@xyonet.com> <20090804183246.B69B41CC34@ptavv.es.net> <20090805141810.GA24211@ussenterprise.ufp.org> <823a86cow4.fsf@mid.bfk.de> <20090805160703.GA35668@ussenterprise.ufp.org> <202705b0908050949p2285aef0qae1c78aa5f17f71a@mail.gmail.com> <20090805172035.GA80396@bluepipe.dk> Message-ID: <202705b0908051030j230bd06ameaf57360464e525b@mail.gmail.com> >> It may sound too futuristic and inspired from science fiction, but I never saw >> Captain Piccard typing a URL on the Enterprise. > > ? ? ? ?That's ok, I've never seen the Enterprise at the airport. Don't confuse sight with vision. >> Sooner or later, we or the new generation of ietfers and nanogers, will need to >> start thinking about a new naming paradigm and design the services and protocols >> associated with it. >> >> The key question is, when we start? > > ? ? ? ?Let's see how far the SMTP replacement has come, and get some inspiration. > ? ? ? ?Heck, it's an application that only _uses_ the DNS, should be easy. It won't be quick, it won't be easy, and you will have to deal with the establishment that at all cost will keep trying to squeeze money out of the current system. Cheers From jay at west.net Wed Aug 5 12:32:38 2009 From: jay at west.net (Jay Hennigan) Date: Wed, 05 Aug 2009 10:32:38 -0700 Subject: Sprint/Verizon BGP In-Reply-To: <000601ca15e2$6a940c40$3fbc24c0$@org> References: <000601ca15e2$6a940c40$3fbc24c0$@org> Message-ID: <4A79C236.7060701@west.net> Edward Brookhouse wrote: > Hi all, > > > > Any Sprint BGP admins on this list can offer any thoughts on why Sprint > connected networks are preferring my Sprint connection when they should be > preferring my Verizon? > > I (Healthy Directions) am AS16387, two blocks 63.73.158.0/24 and > 63.78.31.0/24, being announced by sprint and Verizon, preferred to > Verizon(DS3) over Sprint 3MB. They will prefer to send you traffic over their direct connection over that of a peer. You can influence this by sending them a community to lower your local preference within their network. Export community 1239:80 to Sprint and clear your outbound BGP session with them. See if that does the trick. However, you might get better performance by keeping Sprint direct customers on the Sprint link under normal circumstances, but have the rest of the Internet come over your Verizon link. If the Sprint customer traffic (only) doesn't fill your pipe from them, then you'll likely get shorter paths and lower latency by taking it direct. To do this, don't export 1239:80 but instead export 65004:0 which will cause Sprint to prepend to the rest of the Internet but route their customer traffic to you directly. -- 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 jmamodio at gmail.com Wed Aug 5 12:34:31 2009 From: jmamodio at gmail.com (Jorge Amodio) Date: Wed, 5 Aug 2009 12:34:31 -0500 Subject: Dan Kaminsky In-Reply-To: <20090805172839.GA745701@hiwaay.net> References: <4A7870BA.4020704@xyonet.com> <20090804183246.B69B41CC34@ptavv.es.net> <20090805141810.GA24211@ussenterprise.ufp.org> <823a86cow4.fsf@mid.bfk.de> <20090805160703.GA35668@ussenterprise.ufp.org> <202705b0908050949p2285aef0qae1c78aa5f17f71a@mail.gmail.com> <20090805172035.GA80396@bluepipe.dk> <20090805172839.GA745701@hiwaay.net> Message-ID: <202705b0908051034p7301e3bei8302d22b38d36609@mail.gmail.com> >> ? ? ? That's ok, I've never seen the Enterprise at the airport. > > I have, but not that Enterprise (I saw the space shuttle orbiter > Enterprise on a 747 land here). There is one docked at Pier 26 in New York City :-) From regnauld at catpipe.net Wed Aug 5 13:06:08 2009 From: regnauld at catpipe.net (Phil Regnauld) Date: Wed, 5 Aug 2009 20:06:08 +0200 Subject: DNS hardening, was Re: Dan Kaminsky In-Reply-To: <3efd34cc0908051012q74fadfdej620cd0dcb20c1ea8@mail.gmail.com> References: <4A7870BA.4020704@xyonet.com> <20090805164823.43774.qmail@simone.iecc.com> <3efd34cc0908051012q74fadfdej620cd0dcb20c1ea8@mail.gmail.com> Message-ID: <20090805180608.GA81225@bluepipe.dk> bert hubert (bert.hubert) writes: > > 5 is 'edns ping', but it was effectively blocked because people > thought DNSSEC would be easier to do, or demanded that EDNS PING > (http://edns-ping.org) would offer everything that DNSSEC offered. I'm surprised you failed to mention http://dnscurve.org/crypto.html, which is always brought up, but never seems to solve the problems mentioned. From dotis at mail-abuse.org Wed Aug 5 13:12:32 2009 From: dotis at mail-abuse.org (Douglas Otis) Date: Wed, 05 Aug 2009 11:12:32 -0700 Subject: DNS hardening, was Re: Dan Kaminsky In-Reply-To: <20090805164823.43774.qmail@simone.iecc.com> References: <20090805164823.43774.qmail@simone.iecc.com> Message-ID: <4A79CB90.708@mail-abuse.org> On 8/5/09 9:48 AM, John Levine wrote: > Other than DNSSEC, I'm aware of these relatively simple hacks to add > entropy to DNS queries. > > 1) Random query ID > > 2) Random source port > > 3) Random case in queries, e.g. GooGLe.CoM > > 4) Ask twice (with different values for the first three hacks) and > compare the answers DNSSEC introduces vulnerabilities, such as reflected attacks and fragmentation related exploits that might poison glue, where perhaps asking twice might still be needed. Modern implementations use random 16 bit transaction IDs. Interposed NATs may impair effectiveness of random source ports. Use of random query cases may not offer an entropy increase in some instances. Asking twice, although doubling resource consumption and latency, offers an increase in entropy that works best when queried serially. Establishing SCTP as a preferred DNS transport offers a safe harbor for major ISPs. SCTP protects against both spoofed and reflected attack. Use of persistent SCTP associations can provide lower latency than that found using TCP fallback, TCP only, or repeated queries. SCTP also better deals with attack related congestion. Once UDP is impaired by EDNS0 response sizes that exceed reassembly resources, or are preemptively dropped as a result, TCP must then dramatically scale up to offer the resilience achieved by UDP anycast. In this scenario, SCTP offers several benefits. SCTP retains initialization state within cryptographically secured cookies, which provides significant protection against spoofed source resource exhaustion. By first exchanging cookies, the network extends server state storage. SCTP also better ensures against cache poisoning whether DNSSEC is used or not. Having major providers support the SCTP option will mitigate disruptions caused by DNS DDoS attacks using less resources. SCTP will also encourage use of IPv6, and improve proper SOHO router support. When SCTP becomes used by HTTP, this further enhances DDoS resistance for even critical web related services as well. -Doug From tme at americafree.tv Wed Aug 5 13:13:30 2009 From: tme at americafree.tv (Marshall Eubanks) Date: Wed, 5 Aug 2009 14:13:30 -0400 Subject: Dan Kaminsky In-Reply-To: <202705b0908051030j230bd06ameaf57360464e525b@mail.gmail.com> References: <4A7870BA.4020704@xyonet.com> <20090804183246.B69B41CC34@ptavv.es.net> <20090805141810.GA24211@ussenterprise.ufp.org> <823a86cow4.fsf@mid.bfk.de> <20090805160703.GA35668@ussenterprise.ufp.org> <202705b0908050949p2285aef0qae1c78aa5f17f71a@mail.gmail.com> <20090805172035.GA80396@bluepipe.dk> <202705b0908051030j230bd06ameaf57360464e525b@mail.gmail.com> Message-ID: On Aug 5, 2009, at 1:30 PM, Jorge Amodio wrote: >>> It may sound too futuristic and inspired from science fiction, but >>> I never saw >>> Captain Piccard typing a URL on the Enterprise. >> >> That's ok, I've never seen the Enterprise at the airport. Go to Dulles Airport. She used to be on the runway a long time; now she is at the Udvar-Hazy Center there. Don't know what this has to do with URIs, though. Marshall >> > > Don't confuse sight with vision. > >>> Sooner or later, we or the new generation of ietfers and nanogers, >>> will need to >>> start thinking about a new naming paradigm and design the services >>> and protocols >>> associated with it. >>> >>> The key question is, when we start? >> >> Let's see how far the SMTP replacement has come, and get >> some inspiration. >> Heck, it's an application that only _uses_ the DNS, should >> be easy. > > It won't be quick, it won't be easy, and you will have to deal with > the establishment > that at all cost will keep trying to squeeze money out of the > current system. > > Cheers > > From rdobbins at arbor.net Wed Aug 5 13:31:55 2009 From: rdobbins at arbor.net (Roland Dobbins) Date: Thu, 6 Aug 2009 01:31:55 +0700 Subject: DNS hardening, was Re: Dan Kaminsky In-Reply-To: <4A79CB90.708@mail-abuse.org> References: <20090805164823.43774.qmail@simone.iecc.com> <4A79CB90.708@mail-abuse.org> Message-ID: <90CEC867-A870-4E45-AFC2-898AD655699E@arbor.net> On Aug 6, 2009, at 1:12 AM, Douglas Otis wrote: > Having major providers support the SCTP option will mitigate > disruptions caused by DNS DDoS attacks using less resources. Can you elaborate on this (or are you referring to removing the spoofing vector?)? ----------------------------------------------------------------------- Roland Dobbins // Unfortunately, inefficiency scales really well. -- Kevin Lawton From Skywing at valhallalegends.com Wed Aug 5 13:38:33 2009 From: Skywing at valhallalegends.com (Skywing) Date: Wed, 5 Aug 2009 13:38:33 -0500 Subject: DNS hardening, was Re: Dan Kaminsky Message-ID: <982D8D05B6407A49AD506E6C3AC8E7D60173636AFB4A@caralain.haven.nynaeve.net> That is, of course, assuming that SCTP implementations someday clean up their act a bit. I'm not so sure I'd suggest that they're really ready for "prime time" at this point. - S -----Original Message----- From: Douglas Otis Sent: Wednesday, August 05, 2009 11:13 To: John Levine Cc: nanog at nanog.org Subject: Re: DNS hardening, was Re: Dan Kaminsky On 8/5/09 9:48 AM, John Levine wrote: > Other than DNSSEC, I'm aware of these relatively simple hacks to add > entropy to DNS queries. > > 1) Random query ID > > 2) Random source port > > 3) Random case in queries, e.g. GooGLe.CoM > > 4) Ask twice (with different values for the first three hacks) and > compare the answers DNSSEC introduces vulnerabilities, such as reflected attacks and fragmentation related exploits that might poison glue, where perhaps asking twice might still be needed. Modern implementations use random 16 bit transaction IDs. Interposed NATs may impair effectiveness of random source ports. Use of random query cases may not offer an entropy increase in some instances. Asking twice, although doubling resource consumption and latency, offers an increase in entropy that works best when queried serially. Establishing SCTP as a preferred DNS transport offers a safe harbor for major ISPs. SCTP protects against both spoofed and reflected attack. Use of persistent SCTP associations can provide lower latency than that found using TCP fallback, TCP only, or repeated queries. SCTP also better deals with attack related congestion. Once UDP is impaired by EDNS0 response sizes that exceed reassembly resources, or are preemptively dropped as a result, TCP must then dramatically scale up to offer the resilience achieved by UDP anycast. In this scenario, SCTP offers several benefits. SCTP retains initialization state within cryptographically secured cookies, which provides significant protection against spoofed source resource exhaustion. By first exchanging cookies, the network extends server state storage. SCTP also better ensures against cache poisoning whether DNSSEC is used or not. Having major providers support the SCTP option will mitigate disruptions caused by DNS DDoS attacks using less resources. SCTP will also encourage use of IPv6, and improve proper SOHO router support. When SCTP becomes used by HTTP, this further enhances DDoS resistance for even critical web related services as well. -Doug From johnl at iecc.com Wed Aug 5 14:07:30 2009 From: johnl at iecc.com (John R. Levine) Date: Wed, 5 Aug 2009 15:07:30 -0400 (EDT) Subject: DNS hardening, was Re: Dan Kaminsky In-Reply-To: <20090805180608.GA81225@bluepipe.dk> References: <4A7870BA.4020704@xyonet.com> <20090805164823.43774.qmail@simone.iecc.com> <3efd34cc0908051012q74fadfdej620cd0dcb20c1ea8@mail.gmail.com> <20090805180608.GA81225@bluepipe.dk> Message-ID: >> 5 is 'edns ping', but it was effectively blocked because people >> thought DNSSEC would be easier to do, or demanded that EDNS PING >> (http://edns-ping.org) would offer everything that DNSSEC offered. > > I'm surprised you failed to mention http://dnscurve.org/crypto.html, > which is always brought up, but never seems to solve the problems > mentioned. dnscurve looks like a swell idea, but I wouldn't put it in the category of a hack as straightforward as the ones I listed. Also, at this point there appears to be neither code nor an implementable spec available since Dan is still fiddling with it. Regards, John Levine, johnl at iecc.com, Primary Perpetrator of "The Internet for Dummies", Information Superhighwayman wanna-be, http://www.johnlevine.com, ex-Mayor "More Wiener schnitzel, please", said Tom, revealingly. From johnl at iecc.com Wed Aug 5 14:23:00 2009 From: johnl at iecc.com (John R. Levine) Date: Wed, 5 Aug 2009 15:23:00 -0400 (EDT) Subject: DNS hardening, was Re: Dan Kaminsky In-Reply-To: <3efd34cc0908051012q74fadfdej620cd0dcb20c1ea8@mail.gmail.com> References: <4A7870BA.4020704@xyonet.com> <20090805164823.43774.qmail@simone.iecc.com> <3efd34cc0908051012q74fadfdej620cd0dcb20c1ea8@mail.gmail.com> Message-ID: > 3 works, but offers zero protection against 'kaminsky spoofing the > root' since you can't fold the case of "123456789.". And the root is > the goal. Good point. 5) Download your own copy of the root zone every few days from http://www.internic.net/domain/, check the signature if you can find the signing key for 289FE7AD, and use that rather than the public roots. 6) EDNS0 PING, if you think anyone else will implement it R's, John From surfer at mauigateway.com Wed Aug 5 15:35:11 2009 From: surfer at mauigateway.com (Scott Weeks) Date: Wed, 5 Aug 2009 13:35:11 -0700 Subject: Dan Kaminsky Message-ID: <20090805133511.CD922966@resin13.mta.everyone.net> --- jmamodio at gmail.com wrote: From: Jorge Amodio Sooner or later, we or the new generation of ietfers and nanogers, will need to start thinking about a new naming paradigm and design the services and protocols associated with it. The key question is, when we start? ------------------------------------------------ Read "Patterns in Network Architecture" by John Day. scott From ebroo at setuidzero.org Wed Aug 5 15:47:48 2009 From: ebroo at setuidzero.org (Edward Brookhouse) Date: Wed, 5 Aug 2009 16:47:48 -0400 Subject: Sprint/Verizon BGP In-Reply-To: <4efae7750908051200h58d82572k2944580ad72142b1@mail.gmail.com> References: <000601ca15e2$6a940c40$3fbc24c0$@org> <4efae7750908051200h58d82572k2944580ad72142b1@mail.gmail.com> Message-ID: <000301ca160d$fe317340$fa9459c0$@org> Thanks All - problem resolved. From: Bhavini Mehta [mailto:bhavinim at gmail.com] Sent: Wednesday, August 05, 2009 3:01 PM To: ebroo at setuidzero.org Subject: Re: Sprint/Verizon BGP Hello, Are you still seeing the problem?? I see the route changed in our routing table 30 mins back and now we are seeing the best route via Verizon. I just wanted to reach out and see if you still needed someone from Sprint to look at it. Thanks On Wed, Aug 5, 2009 at 11:35 AM, Edward Brookhouse wrote: Hi all, Any Sprint BGP admins on this list can offer any thoughts on why Sprint connected networks are preferring my Sprint connection when they should be preferring my Verizon? I (Healthy Directions) am AS16387, two blocks 63.73.158.0/24 and 63.78.31.0/24, being announced by sprint and Verizon, preferred to Verizon(DS3) over Sprint 3MB. Verizon BGP admins think everything is ok, have not heard back from BGP4 at sprint. Any thoughts appreciated, off-list contact welcome. Edward ebroo at healthydirections.com From dotis at mail-abuse.org Wed Aug 5 16:00:59 2009 From: dotis at mail-abuse.org (Douglas Otis) Date: Wed, 05 Aug 2009 14:00:59 -0700 Subject: DNS hardening, was Re: Dan Kaminsky In-Reply-To: <982D8D05B6407A49AD506E6C3AC8E7D60173636AFB4A@caralain.haven.nynaeve.net> References: <982D8D05B6407A49AD506E6C3AC8E7D60173636AFB4A@caralain.haven.nynaeve.net> Message-ID: <4A79F30B.6090503@mail-abuse.org> On 8/5/09 11:38 AM, Skywing wrote: > That is, of course, assuming that SCTP implementations someday clean up their act a bit. I'm not so sure I'd suggest that they're really ready for "prime time" at this point. SCTP DNS would be intended for ISPs validating DNS where there would be fewer issues regarding SOHO routers. It seems likely DNS will require some kernel adjustments to support persistent SCTP. SCTP has been providing critical SS7 and H.248.1 services for many years now, where TCP would not be suitable. FreeBSD 7 represents a solid SCTP reference implementation. SCTP has far fewer issues going to homes connected via IPv6. -Doug From jmamodio at gmail.com Wed Aug 5 16:05:39 2009 From: jmamodio at gmail.com (Jorge Amodio) Date: Wed, 5 Aug 2009 16:05:39 -0500 Subject: Dan Kaminsky In-Reply-To: <20090805133511.CD922966@resin13.mta.everyone.net> References: <20090805133511.CD922966@resin13.mta.everyone.net> Message-ID: <202705b0908051405w49b8d7f9peee45ab2b743b1a6@mail.gmail.com> > Read "Patterns in Network Architecture" by John Day. "A Return to Fundamentals", great book. "the Internet today is more like DOS, but what we need should be more like Unix" Great thing he didn't say Windows :-) Cheers From surfer at mauigateway.com Wed Aug 5 16:21:31 2009 From: surfer at mauigateway.com (Scott Weeks) Date: Wed, 5 Aug 2009 14:21:31 -0700 Subject: Networking is IPC Message-ID: <20090805142131.CD923B2E@resin13.mta.everyone.net> Changed the subject line... --- jmamodio at gmail.com wrote: > Read "Patterns in Network Architecture" by John Day. "A Return to Fundamentals", great book. "the Internet today is more like DOS, but what we need should be more like Unix" Great thing he didn't say Windows :-) ----------------------------------------- I like these: "networking is interprocess communication". (quoted from Metcalfe - 1972) "Q: So, how long should an address be? A: Processing the address should halt" Chapters 5-8 are the meat of naming and addressing and he has a LOT to say on the subjects... :-) scott From dotis at mail-abuse.org Wed Aug 5 16:24:51 2009 From: dotis at mail-abuse.org (Douglas Otis) Date: Wed, 05 Aug 2009 14:24:51 -0700 Subject: DNS hardening, was Re: Dan Kaminsky In-Reply-To: <90CEC867-A870-4E45-AFC2-898AD655699E@arbor.net> References: <20090805164823.43774.qmail@simone.iecc.com> <4A79CB90.708@mail-abuse.org> <90CEC867-A870-4E45-AFC2-898AD655699E@arbor.net> Message-ID: <4A79F8A3.9040302@mail-abuse.org> On 8/5/09 11:31 AM, Roland Dobbins wrote: > > On Aug 6, 2009, at 1:12 AM, Douglas Otis wrote: > >> Having major providers support the SCTP option will mitigate disruptions caused by DNS DDoS attacks using less resources. > > Can you elaborate on this (or are you referring to removing the spoofing vector?)? SCTP is able to simultaneously exchange chunks (DNS messages) over an association. Initialization of associations can offer alternative servers for immediate fail-over, which might be seen as means to arrange anycast style redundancy. Unlike TCP, resource commitments are only retained within the cookies exchanged. This avoids consumption of resources for tracking transaction commitments for what might be spoofed sources. Confirmation of the small cookie also offers protection against reflected attacks by spoofed sources. In addition to source validation, the 32 bit verification tag and TSN would add a significant amount of entropy to the DNS transaction ID. The SCTP stack is able to perform the housekeeping needed to allow associations to persist beyond single transaction, nor would there be a need to push partial packets, as is needed with TCP. -Doug From jmamodio at gmail.com Wed Aug 5 16:30:19 2009 From: jmamodio at gmail.com (Jorge Amodio) Date: Wed, 5 Aug 2009 16:30:19 -0500 Subject: Networking is IPC In-Reply-To: <20090805142131.CD923B2E@resin13.mta.everyone.net> References: <20090805142131.CD923B2E@resin13.mta.everyone.net> Message-ID: <202705b0908051430x7e27c9ebk69d1640e2495e1cd@mail.gmail.com> > Chapters 5-8 are the meat of naming and addressing and he has a LOT to say on the subjects... ?:-) Yup. "Did I ever tell you that Mrs. McCave had twenty three sons and she named them all Dave? well, she did. And that wasn't a smart thing to do. You see, when she wants one and calls out 'yoo-hoo! come into the house, dave!' She doesn't get ONE. All twenty three Daves of hers come on the run! This makes things quite difficult at the McCaves' as you can imagine, with so many Daves. ..." by Dr. Seuss From morrowc.lists at gmail.com Wed Aug 5 16:49:28 2009 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Wed, 5 Aug 2009 17:49:28 -0400 Subject: DNS hardening, was Re: Dan Kaminsky In-Reply-To: <4A79F8A3.9040302@mail-abuse.org> References: <20090805164823.43774.qmail@simone.iecc.com> <4A79CB90.708@mail-abuse.org> <90CEC867-A870-4E45-AFC2-898AD655699E@arbor.net> <4A79F8A3.9040302@mail-abuse.org> Message-ID: <75cb24520908051449n29c53491m90fd021022d9816f@mail.gmail.com> On Wed, Aug 5, 2009 at 5:24 PM, Douglas Otis wrote: > On 8/5/09 11:31 AM, Roland Dobbins wrote: >> >> On Aug 6, 2009, at 1:12 AM, Douglas Otis wrote: >> >>> Having major providers support the SCTP option will mitigate disruptions >>> caused by DNS DDoS attacks using less resources. >> >> Can you elaborate on this (or are you referring to removing the spoofing >> vector?)? > > SCTP is able to simultaneously exchange chunks (DNS messages) over an > association. ?Initialization of associations can offer alternative servers > for immediate fail-over, which might be seen as means to arrange anycast > style redundancy. ?Unlike TCP, resource commitments are only retained within > the cookies exchanged. ?This avoids consumption of resources for tracking > transaction commitments for what might be spoofed sources. ?Confirmation of > the small cookie also offers protection against reflected attacks by spoofed > sources. ?In addition to source validation, the 32 bit verification tag and > TSN would add a significant amount of entropy to the DNS transaction ID. > > The SCTP stack is able to perform the housekeeping needed to allow > associations to persist beyond single transaction, nor would there be a need > to push partial packets, as is needed with TCP. and state-management seems like it won't be too much of a problem on that dns server... wait, yes it will. From smb at cs.columbia.edu Wed Aug 5 16:58:55 2009 From: smb at cs.columbia.edu (Steven M. Bellovin) Date: Wed, 5 Aug 2009 17:58:55 -0400 Subject: DNS hardening, was Re: Dan Kaminsky In-Reply-To: References: <4A7870BA.4020704@xyonet.com> <20090805164823.43774.qmail@simone.iecc.com> <3efd34cc0908051012q74fadfdej620cd0dcb20c1ea8@mail.gmail.com> <20090805180608.GA81225@bluepipe.dk> Message-ID: <20090805175855.2f68b9d9@cs.columbia.edu> On Wed, 5 Aug 2009 15:07:30 -0400 (EDT) "John R. Levine" wrote: > >> 5 is 'edns ping', but it was effectively blocked because people > >> thought DNSSEC would be easier to do, or demanded that EDNS PING > >> (http://edns-ping.org) would offer everything that DNSSEC offered. > > > > I'm surprised you failed to mention > > http://dnscurve.org/crypto.html, which is always brought up, but > > never seems to solve the problems mentioned. > > dnscurve looks like a swell idea, but I wouldn't put it in the > category of a hack as straightforward as the ones I listed. Also, at > this point there appears to be neither code nor an implementable spec > available since Dan is still fiddling with it. > As I understand it, dnscurve protects transmissions, not objects. That's not the way DNS operates today, what with N levels of cache. It may or may not be better, but it's a much bigger delta to today's systems and practices than DNSSEC is. --Steve Bellovin, http://www.cs.columbia.edu/~smb From mailvortex at gmail.com Wed Aug 5 17:26:45 2009 From: mailvortex at gmail.com (Ben Scott) Date: Wed, 5 Aug 2009 18:26:45 -0400 Subject: Dan Kaminsky In-Reply-To: <202705b0908050949p2285aef0qae1c78aa5f17f71a@mail.gmail.com> References: <4A7870BA.4020704@xyonet.com> <20090804183246.B69B41CC34@ptavv.es.net> <20090805141810.GA24211@ussenterprise.ufp.org> <823a86cow4.fsf@mid.bfk.de> <20090805160703.GA35668@ussenterprise.ufp.org> <202705b0908050949p2285aef0qae1c78aa5f17f71a@mail.gmail.com> Message-ID: <59f980d60908051526n7ab973ebi5285439e4a35285a@mail.gmail.com> On Wed, Aug 5, 2009 at 12:49 PM, Jorge Amodio wrote: > At some time in the future and when a new paradigm for the user interface is > conceived, we may not longer have the end user ?typing? a URL, the DNS or > something similar will still be in the background providing name to address > mapping but there will be no more monetary value associated with it or that > value will be transferred to something else. We're already there. It's called "Google". In the the vast majority of cases I have seen, people don't type domain names, they search the web. When they do type a domain name, they usually type it into the Google search box. (Alternatively, they type everything into the browser's "address bar", which is really a "search-the-web bar" in most browsers.) (Replace "Google" with search engine of your choice.) -- Ben From tme at americafree.tv Wed Aug 5 17:37:27 2009 From: tme at americafree.tv (Marshall Eubanks) Date: Wed, 5 Aug 2009 18:37:27 -0400 Subject: Dan Kaminsky In-Reply-To: <59f980d60908051526n7ab973ebi5285439e4a35285a@mail.gmail.com> References: <4A7870BA.4020704@xyonet.com> <20090804183246.B69B41CC34@ptavv.es.net> <20090805141810.GA24211@ussenterprise.ufp.org> <823a86cow4.fsf@mid.bfk.de> <20090805160703.GA35668@ussenterprise.ufp.org> <202705b0908050949p2285aef0qae1c78aa5f17f71a@mail.gmail.com> <59f980d60908051526n7ab973ebi5285439e4a35285a@mail.gmail.com> Message-ID: <313E753F-6920-4598-9ADE-A504E283B857@americafree.tv> On Aug 5, 2009, at 6:26 PM, Ben Scott wrote: > On Wed, Aug 5, 2009 at 12:49 PM, Jorge Amodio > wrote: >> At some time in the future and when a new paradigm for the user >> interface is >> conceived, we may not longer have the end user ?typing? a URL, the >> DNS or >> something similar will still be in the background providing name to >> address >> mapping but there will be no more monetary value associated with it >> or that >> value will be transferred to something else. > > We're already there. It's called "Google". > > In the the vast majority of cases I have seen, people don't type > domain names, they search the web. When they do type a domain name, > they usually type it into the Google search box. Partially true for web access, very rarely true for email. I type in email domains much more often than I do web domains. And now email addresses are becoming URIs for log ins, SIP calling, video conferencing, etc. It's also interesting how in some ways twitter and its relatives have been sending URLs backwards. If you type in http://www.americafree.tv you may have some idea what you are getting, but if you type in http://bit.ly/w5aM4 you have none. (These two URLs go, or at least they should go, to the same place. Who knows if that will be true in a year, or 5, or 10.) Here is a place IMO where a better UI and URI philosophy would really help. Regards Marshall > > > (Alternatively, they type everything into the browser's "address > bar", which is really a > "search-the-web bar" in most browsers.) > > (Replace "Google" with search engine of your choice.) > > -- Ben > > From cmadams at hiwaay.net Wed Aug 5 17:37:32 2009 From: cmadams at hiwaay.net (Chris Adams) Date: Wed, 5 Aug 2009 17:37:32 -0500 Subject: Dan Kaminsky In-Reply-To: <59f980d60908051526n7ab973ebi5285439e4a35285a@mail.gmail.com> References: <4A7870BA.4020704@xyonet.com> <20090804183246.B69B41CC34@ptavv.es.net> <20090805141810.GA24211@ussenterprise.ufp.org> <823a86cow4.fsf@mid.bfk.de> <20090805160703.GA35668@ussenterprise.ufp.org> <202705b0908050949p2285aef0qae1c78aa5f17f71a@mail.gmail.com> <59f980d60908051526n7ab973ebi5285439e4a35285a@mail.gmail.com> Message-ID: <20090805223732.GC1408048@hiwaay.net> Once upon a time, Ben Scott said: > In the the vast majority of cases I have seen, people don't type > domain names, they search the web. When they do type a domain name, > they usually type it into the Google search box. Web != Internet. DNS is used for much more than web sites, and many of those things are not in a public index. For example, most people type in their friends' email addresses (at least into an address book). -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From dotis at mail-abuse.org Wed Aug 5 17:53:32 2009 From: dotis at mail-abuse.org (Douglas Otis) Date: Wed, 05 Aug 2009 15:53:32 -0700 Subject: DNS hardening, was Re: Dan Kaminsky In-Reply-To: <75cb24520908051449n29c53491m90fd021022d9816f@mail.gmail.com> References: <20090805164823.43774.qmail@simone.iecc.com> <4A79CB90.708@mail-abuse.org> <90CEC867-A870-4E45-AFC2-898AD655699E@arbor.net> <4A79F8A3.9040302@mail-abuse.org> <75cb24520908051449n29c53491m90fd021022d9816f@mail.gmail.com> Message-ID: <4A7A0D6C.90808@mail-abuse.org> On 8/5/09 2:49 PM, Christopher Morrow wrote: > and state-management seems like it won't be too much of a problem on > that dns server... wait, yes it will. DNSSEC UDP will likely become problematic. This might be due to reflected attacks, fragmentation related congestion, or packet loss. When it does, TCP fallback will tried. TCP must retain state for every attempt to connect, and will require significantly greater resources for comparable levels of resilience. SCTP instead uses cryptographic cookies and the client to retain this state information. SCTP can bundle several transactions into a common association, which reduces overhead and latency compared against TCP. SCTP ensures against source spoofed reflected attacks or related resource exhaustion. TCP or UDP does not. Under load, SCTP can redirect services without using anycast. TCP can not. -Doug From mailvortex at gmail.com Wed Aug 5 18:02:50 2009 From: mailvortex at gmail.com (Ben Scott) Date: Wed, 5 Aug 2009 19:02:50 -0400 Subject: Dan Kaminsky In-Reply-To: <20090805223732.GC1408048@hiwaay.net> References: <4A7870BA.4020704@xyonet.com> <20090804183246.B69B41CC34@ptavv.es.net> <20090805141810.GA24211@ussenterprise.ufp.org> <823a86cow4.fsf@mid.bfk.de> <20090805160703.GA35668@ussenterprise.ufp.org> <202705b0908050949p2285aef0qae1c78aa5f17f71a@mail.gmail.com> <59f980d60908051526n7ab973ebi5285439e4a35285a@mail.gmail.com> <20090805223732.GC1408048@hiwaay.net> Message-ID: <59f980d60908051602y1fe364devfb5f590a8c7959dc@mail.gmail.com> On Wed, Aug 5, 2009 at 6:37 PM, Chris Adams wrote: >>> ... we may not longer have the end user ?typing? a URL, the DNS or >>> something similar will still be in the background providing name to address >>> mapping ... >> >> ? In the the vast majority of cases I have seen, people don't type >> domain names, they search the web. ?When they do type a domain name, >> they usually type it into the Google search box. > > Web != Internet. (Web != Internet) != the_point Most people don't type email addresses, either. They pick from from their address book. Their address book knows the address because it auto-learned it from a previously received email. If their email program doesn't do that, they find an old email and hit "Reply". (You laugh, but even in my small experience, I've seen plenty of clusers who rarely originate an email. They reply to *everything*. You have to email them once for them to email you. It's always neat to get a message in my inbox that's a reply to a message from three years ago. But I digress.) User IDs on Facebook, Twitter, et. al., aren't email addresses, they're user IDs. They just happen to look just like email addresses, because nobody's come up with a better system yet. The main reason those services ask for the user's email address for an ID is it makes the "I forgot my user ID" support cases easier. (Note that it doesn't eliminate them. Some people still don't know their Facebook user ID until you tell them it's their email address. Then they ask what their email address is...) Web browsers already automatically fill-in one's email address if you let them. One of these days Microsoft or Mozilla or whoever will come up with a method to make the automation more seamless, and people will probabbly stop knowing their own email address. To do the initial exchange for a new person, they'll use Facebook. Or whatever. Paper advertisements: What's easier? (1) Publishing a URL in a print ad, and expecting people to remember it and type it correctly. (2) Saying "type our name into $SERVICE", where $SERVICE is some popular website that most people trust (like Facebook or whatever), and has come up with a workable system for disambiguation. You get the picture. Follow the trend. The systems aren't done evolving into being yet, but the avalanche has definitely started. It's too late for the pebbles to vote. As the person I was replying to said, DNS is unlikely to go away, but I'll lay good money that some day most people won't even know domain names exist, any more than they know IP addresses do. -- Ben From jmamodio at gmail.com Wed Aug 5 18:06:04 2009 From: jmamodio at gmail.com (Jorge Amodio) Date: Wed, 5 Aug 2009 18:06:04 -0500 Subject: Dan Kaminsky In-Reply-To: <20090805223732.GC1408048@hiwaay.net> References: <4A7870BA.4020704@xyonet.com> <20090804183246.B69B41CC34@ptavv.es.net> <20090805141810.GA24211@ussenterprise.ufp.org> <823a86cow4.fsf@mid.bfk.de> <20090805160703.GA35668@ussenterprise.ufp.org> <202705b0908050949p2285aef0qae1c78aa5f17f71a@mail.gmail.com> <59f980d60908051526n7ab973ebi5285439e4a35285a@mail.gmail.com> <20090805223732.GC1408048@hiwaay.net> Message-ID: <202705b0908051606x46611462u5a61b574b8f0f914@mail.gmail.com> >> At some time in the future and when a new paradigm for the user interface is >> conceived, we may not longer have the end user ?typing? a URL, the DNS or >> something similar will still be in the background providing name to address >> mapping but there will be no more monetary value associated with it or that >> value will be transferred to something else. > > We're already there. It's called "Google". Almost there. No wonder why Microsoft does not want to brand "bing" as yet another "search engine" and are sucking Yahoo's brain power and employees, and Google that is "waving" into something. Talking about the subject with a friend during the past few days, most of the conversation ended being around the User Interface. When grandma wants to do on-line banking she does not care about a cryptic URL, or if it has a .bank gTLD or if by the magic of IDN she is able to write it in polish, she just wants to get to her bank account, so a UI that is application/context/content/user aware will help her when she just says "get me to my bank", grandma will spit on the spit pad for DNA authentication and the UI will magically get her there. And if Mr. Dan wonders about hacking the system, I already have several vials of grandma spit in frozen storage :-) But, you get the point. Cheers From mailvortex at gmail.com Wed Aug 5 18:17:02 2009 From: mailvortex at gmail.com (Ben Scott) Date: Wed, 5 Aug 2009 19:17:02 -0400 Subject: Dan Kaminsky In-Reply-To: <202705b0908051606x46611462u5a61b574b8f0f914@mail.gmail.com> References: <4A7870BA.4020704@xyonet.com> <20090804183246.B69B41CC34@ptavv.es.net> <20090805141810.GA24211@ussenterprise.ufp.org> <823a86cow4.fsf@mid.bfk.de> <20090805160703.GA35668@ussenterprise.ufp.org> <202705b0908050949p2285aef0qae1c78aa5f17f71a@mail.gmail.com> <59f980d60908051526n7ab973ebi5285439e4a35285a@mail.gmail.com> <20090805223732.GC1408048@hiwaay.net> <202705b0908051606x46611462u5a61b574b8f0f914@mail.gmail.com> Message-ID: <59f980d60908051617t1dc05917pbdc47e1cc7ef6f26@mail.gmail.com> On Wed, Aug 5, 2009 at 7:06 PM, Jorge Amodio wrote: > Talking about the subject with a friend during the past few days, most of > the conversation ended being around the User Interface. A popular idiom is "where the rubber meets the road". It comes from cars, of course. The contact patch between tire and surface. If those 100 square inches or so don't provide what's needed, nobody cares how elegant the rest of the car is. In information systems, the UI is where the rubber meets the road. > When grandma wants to do on-line banking she does not care about > a cryptic URL, or if it has a .bank gTLD or if by the magic of IDN she > is able to write it in polish, she just wants to get to her bank account ... Exactly. I think it would be nice if we had some nicely designed, elegant, centralized protocol to do all this, but I suspect that won't happen. Instead I think we'll have a bunch of ad hoc solutions, and then ad hoc solutions that attempt to meta the ad hoc soltions. Someone's already suggested this in another thread. So someone will log into GMyLinkedBook or whatever, which then makes use of Facebook to find a friend, which then talks to AIM to contact them on their iPhone via some other damn thing. Yes, it'll be a mess. So's most of the rest of the world. Keeps us IT guys in work, I guess. -- Ben From jmamodio at gmail.com Wed Aug 5 18:23:13 2009 From: jmamodio at gmail.com (Jorge Amodio) Date: Wed, 5 Aug 2009 18:23:13 -0500 Subject: Dan Kaminsky In-Reply-To: <59f980d60908051617t1dc05917pbdc47e1cc7ef6f26@mail.gmail.com> References: <4A7870BA.4020704@xyonet.com> <20090804183246.B69B41CC34@ptavv.es.net> <20090805141810.GA24211@ussenterprise.ufp.org> <823a86cow4.fsf@mid.bfk.de> <20090805160703.GA35668@ussenterprise.ufp.org> <202705b0908050949p2285aef0qae1c78aa5f17f71a@mail.gmail.com> <59f980d60908051526n7ab973ebi5285439e4a35285a@mail.gmail.com> <20090805223732.GC1408048@hiwaay.net> <202705b0908051606x46611462u5a61b574b8f0f914@mail.gmail.com> <59f980d60908051617t1dc05917pbdc47e1cc7ef6f26@mail.gmail.com> Message-ID: <202705b0908051623o6bf13228vfcaf9a0a8ef7ea8a@mail.gmail.com> > ?I think it would be nice if we had some nicely designed, elegant, > centralized protocol to do all this, but I suspect that won't happen. s/centralized/distributed/ > them on their iPhone via some other damn thing. ?Yes, it'll be a mess. Have you seen the iphone decoding bar code into urls ? > ?Keeps us IT guys in work, I guess. and the domainers/registr*s making money. Cheers From jgreco at ns.sol.net Wed Aug 5 18:23:57 2009 From: jgreco at ns.sol.net (Joe Greco) Date: Wed, 5 Aug 2009 18:23:57 -0500 (CDT) Subject: Dan Kaminsky In-Reply-To: <59f980d60908051602y1fe364devfb5f590a8c7959dc@mail.gmail.com> from "Ben Scott" at Aug 05, 2009 07:02:50 PM Message-ID: <200908052323.n75NNvuD042590@aurora.sol.net> > (2) Saying "type our name into $SERVICE", where $SERVICE is some > popular website that most people trust (like Facebook or whatever), > and has come up with a workable system for disambiguation. You might want to talk to AOL about 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 marka at isc.org Wed Aug 5 18:30:23 2009 From: marka at isc.org (Mark Andrews) Date: Thu, 06 Aug 2009 09:30:23 +1000 Subject: Dan Kaminsky In-Reply-To: Your message of "Wed, 05 Aug 2009 19:02:50 -0400." <59f980d60908051602y1fe364devfb5f590a8c7959dc@mail.gmail.com> References: <4A7870BA.4020704@xyonet.com> <20090804183246.B69B41CC34@ptavv.es.net> <20090805141810.GA24211@ussenterprise.ufp.org> <823a86cow4.fsf@mid.bfk.de> <20090805160703.GA35668@ussenterprise.ufp.org> <202705b0908050949p2285aef0qae1c78aa5f17f71a@mail.gmail.com> <59f980d60908051526n7ab973ebi5285439e4a35285a@mail.gmail.com> <20090805223732.GC1408048@hiwaay.net> <59f980d60908051602y1fe364devfb5f590a8c7959dc@mail.gmail.com> Message-ID: <200908052330.n75NUNlV001012@drugs.dv.isc.org> In message <59f980d60908051602y1fe364devfb5f590a8c7959dc at mail.gmail.com>, Ben S cott writes: > On Wed, Aug 5, 2009 at 6:37 PM, Chris Adams wrote: > >>> ... we may not longer have the end user =93typing=94 a URL, the DNS or > >>> something similar will still be in the background providing name to add= > ress > >>> mapping ... > >> > >> =A0 In the the vast majority of cases I have seen, people don't type > >> domain names, they search the web. =A0When they do type a domain name, > >> they usually type it into the Google search box. > > > > Web !=3D Internet. > > (Web !=3D Internet) !=3D the_point > > Most people don't type email addresses, either. They pick from from > their address book. Their address book knows the address because it > auto-learned it from a previously received email. If their email > program doesn't do that, they find an old email and hit "Reply". (You > laugh, but even in my small experience, I've seen plenty of clusers > who rarely originate an email. They reply to *everything*. You have > to email them once for them to email you. It's always neat to get a > message in my inbox that's a reply to a message from three years ago. > But I digress.) Which requires that people type addresses in in the first place. It's like these anti spam proceedures which require that you respond to a message that says you sent the email to let it through. I doesn't work if everyone or even if most do it. > User IDs on Facebook, Twitter, et. al., aren't email addresses, > they're user IDs. They just happen to look just like email addresses, > because nobody's come up with a better system yet. The main reason > those services ask for the user's email address for an ID is it makes > the "I forgot my user ID" support cases easier. (Note that it doesn't > eliminate them. Some people still don't know their Facebook user ID > until you tell them it's their email address. Then they ask what > their email address is...) No they make finding a unique id easy by leveraging a existing globally unique system. > Web browsers already automatically fill-in one's email address if > you let them. Which you have typed into the web browser in the first place. > One of these days Microsoft or Mozilla or whoever > will come up with a method to make the automation more seamless, and > people will probabbly stop knowing their own email address. To do the > initial exchange for a new person, they'll use Facebook. Or whatever. > > Paper advertisements: What's easier? (1) Publishing a URL in a > print ad, and expecting people to remember it and type it correctly. > (2) Saying "type our name into $SERVICE", where $SERVICE is some > popular website that most people trust (like Facebook or whatever), > and has come up with a workable system for disambiguation. 1 if you actually want people to get to you and not your competitor. There is a reason people put phone numbers in advertisments rather than say "look us up in the yellow/white pages". > You get the picture. Follow the trend. The systems aren't done > evolving into being yet, but the avalanche has definitely started. > It's too late for the pebbles to vote. There is a difference between looking for a service and looking for a specific vendor of a service. > As the person I was replying to said, DNS is unlikely to go away, > but I'll lay good money that some day most people won't even know > domain names exist, any more than they know IP addresses do. People may not know what a domain name is but they will use them all the time even if they are not aware of it. Google Twitter, Facebook etc. all depend on a working DNS whether they make it use visible to user or not. Mark > -- Ben -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From mailvortex at gmail.com Wed Aug 5 19:05:54 2009 From: mailvortex at gmail.com (Ben Scott) Date: Wed, 5 Aug 2009 20:05:54 -0400 Subject: Dan Kaminsky In-Reply-To: <200908052330.n75NUNlV001012@drugs.dv.isc.org> References: <4A7870BA.4020704@xyonet.com> <20090804183246.B69B41CC34@ptavv.es.net> <20090805141810.GA24211@ussenterprise.ufp.org> <823a86cow4.fsf@mid.bfk.de> <20090805160703.GA35668@ussenterprise.ufp.org> <202705b0908050949p2285aef0qae1c78aa5f17f71a@mail.gmail.com> <59f980d60908051526n7ab973ebi5285439e4a35285a@mail.gmail.com> <20090805223732.GC1408048@hiwaay.net> <59f980d60908051602y1fe364devfb5f590a8c7959dc@mail.gmail.com> <200908052330.n75NUNlV001012@drugs.dv.isc.org> Message-ID: <59f980d60908051705rd8bbb49vceafda9e78abe4a5@mail.gmail.com> On Wed, Aug 5, 2009 at 7:30 PM, Mark Andrews wrote: > ? ? ? ?Which requires that people type addresses in in the first > ? ? ? ?place. As I wrote, we're already part of the way towards people not having to do even that. > ? ? ? ?No they make finding a unique id easy by leveraging a > ? ? ? ?existing globally unique system. That too. But if Facebook *becomes* the globally unique system... >> ? Web browsers already automatically fill-in one's email address if >> you let them. > > ? ? ? ?Which you have typed into the web browser in the first place. Web browsers can get the user's email address from the OS/email program in many cases. The cases where that isn't working yet (e.g., Yahoo) are problems easily solved by technology. Sites and browsers already have a protocol for changing one's home page. "Would you like your email to be at 'Google'? [Yes] [No]" > ? ? ? ?1 if you actually want people to get to you and not your > ? ? ? ?competitor. And when people can't remember or mis-type the URL, you think they get the "right" site all the time? > There is a reason people put phone numbers in advertisments > rather than say "look us up in the yellow/white pages". If there was a better system, would they still print their phone numbers in advertisements? Of your associates, how many of their phone numbers do you know? How many does your phone dial for you? How often do you find yourself glad someone called you first, saving you the trouble from entering their phone number into your contacts manually? Now get the phone talking to PhoneFaceBook or whatever, so the "first call" problem is solved. Do you get to Google by typing "google.com" or "64.233.161.104"? If only the later mechanism existed, would you be adverse to adopting a better one? > There is a difference between looking for a service and looking > for a specific vendor of a service. Sure. There's a difference between looking for me and looking for all the other people named "Ben Scott", too. Yet Facebook has resulted in people I haven't talked to in 15 years finding me. Facebook solved the personal-name ambiguity problem for them. It seems reasonable to suppose that other ambiguity problems are solvable as well. People used to copy HOSTS.TXT around until someone came up with a better scheme. /etc/hosts still exists and still comes in handy for some things. People used to put great effort into maintaining giant bookmark files in web browsers. Sharing bookmark entries was a great way to improve one's web experience. These days, bookmark files are still used and still useful, but their necessity is very much diminished by improved web search engines and browser history. Look for the trend in all the things I'm writing about. It's not about getting *rid* of domain names, or URLs, or email addresses, or IP addresses, or phone numbers. It's about people finding ways of *using* all those things without *knowing* them. Extrapolate from that trend. >> ? As the person I was replying to said, DNS is unlikely to go away, >> but I'll lay good money that some day most people won't even know >> domain names exist, any more than they know IP addresses do. > > People may not know what a domain name is but they will use > them all the time even if they are not aware of it. Isn't that what I *just* *wrote*? :-) Please try to understand my point, rather than setting out to defend the usefulness of DNS. I still run ISC BIND on all my servers if that makes you feel less defensive. ;-) -- Ben @ 209.85.221.52 From james.cutler at consultant.com Wed Aug 5 19:40:09 2009 From: james.cutler at consultant.com (James R. Cutler) Date: Wed, 5 Aug 2009 20:40:09 -0400 Subject: Dan Kaminsky In-Reply-To: <200908052323.n75NNvuD042590@aurora.sol.net> References: <200908052323.n75NNvuD042590@aurora.sol.net> Message-ID: >> (2) Saying "type our name into $SERVICE", where $SERVICE is some >> popular website that most people trust (like Facebook or whatever), >> and has come up with a workable system for disambiguation. I can only hope that those who believe in "disambiguation" of mailing addresses, electronic or otherwise, will be sorely disappointed. Return to sender is the only safe course. [No, I am not an architect, regardless of what Google says.] And, I really want whitehouse.gov, not whitehouse.com, even though you could only guess my reason. The design intent of the DNS namespace and structure is to provide unambiguous location of domain name related data. The implementation of that structure and lookup mechanisms may be flawed, but we should fix the flaws, not discard the namespace. This discussion has wandered widely. Perhaps we should revert to discussing how to operate our networks to provide secure connectivity, including secure determination of connection targets. James R. Cutler james.cutler at consultant.com From zartash at gmail.com Wed Aug 5 19:51:59 2009 From: zartash at gmail.com (Zartash Uzmi) Date: Thu, 6 Aug 2009 05:51:59 +0500 Subject: Do you aggregate? Message-ID: <4fff97de0908051751q242860fdp624f66cc072ad0f8@mail.gmail.com> Hi all, I hope most people on the list look at the routing table analysis reports. Excerpt from last week show about 292961 prefixes which after maximum aggregation can be reduced to 138493. I wonder how many of you do actually aggregate? If so, do you aggregate manually or using some algorithm? In either case (manual or automatic aggregation), how frequently do you aggregate? more frequent than the BGP updates frequency? If you aggregate, do you announce the aggregated prefixes or the original un-aggregated prefixes? how big is your network? (Tier-1, 2, 3, campus, etc.) I am hoping to get a few answers :) Regards, Zartash From johnl at iecc.com Wed Aug 5 20:17:01 2009 From: johnl at iecc.com (John R. Levine) Date: Wed, 5 Aug 2009 21:17:01 -0400 (EDT) Subject: dnscurve and DNS hardening, was Re: Dan Kaminsky In-Reply-To: <20090805175855.2f68b9d9@cs.columbia.edu> References: <4A7870BA.4020704@xyonet.com> <20090805164823.43774.qmail@simone.iecc.com> <3efd34cc0908051012q74fadfdej620cd0dcb20c1ea8@mail.gmail.com> <20090805180608.GA81225@bluepipe.dk> <20090805175855.2f68b9d9@cs.columbia.edu> Message-ID: >>> http://dnscurve.org/crypto.html, which is always brought up, but >>> never seems to solve the problems mentioned. > As I understand it, dnscurve protects transmissions, not objects. > That's not the way DNS operates today, what with N levels of cache. It > may or may not be better, but it's a much bigger delta to today's > systems and practices than DNSSEC is. I took a closer look, and I have to say he did a really good job of integrating dnscurve into the way DNS works. Each request and response is protected by PKI, sort of like per message TLS. The public key for a server is encoded into the server's name, and the one for a client is passed in the packet. The name server name trick gives much of the zone chaining you get from DNSSEC. He doesn't say anything explicit about chained caches, but it seems pretty clear that you's have to tell the client cache about the server cache's key at the same time you tell it the server cache's IP address. It seems to me that the situation is no worse than DNSSEC, since in both cases the software at each hop needs to be aware of the security stuff, or you fall back to plain unsigned DNS. R's, John From mailvortex at gmail.com Wed Aug 5 20:36:47 2009 From: mailvortex at gmail.com (Ben Scott) Date: Wed, 5 Aug 2009 21:36:47 -0400 Subject: Dan Kaminsky In-Reply-To: References: <200908052323.n75NNvuD042590@aurora.sol.net> Message-ID: <59f980d60908051836x2be5394bwe75218e532b730d8@mail.gmail.com> On Wed, Aug 5, 2009 at 8:40 PM, James R. Cutler wrote: >>> (2) Saying "type our name into $SERVICE", where $SERVICE is some >>> popular website that most people trust (like Facebook or whatever), >>> and has come up with a workable system for disambiguation. > > I can only hope that those who believe in "disambiguation" of mailing > addresses, electronic or otherwise, will be sorely disappointed. I'm not suggesting the elimination of email addresses any more than I'm suggesting the elimination of DNS. I'm asserting that people find it easier to use methods other than transcription to share email addresses, and that society gravitates towards such methods. > ...?And, I really want whitehouse.gov, not whitehouse.com, > even though you could only guess my reason. Thanks for proving my point for me. :) Why do you think exists and is what it is? Why is it such a well-known example? I'm guessing it's because people frequently end up at the wrong website. Computers like using domain names, and are good at it. People don't, and aren't. It seems reasonable that computers will continue using domain names, while people continue to migrate to layered front-ends. I'm honestly stumped why people are having such a hard time speaking to this. Instead I keep getting told that DNS is more precise than Google. (Or email addresses are more precise than human names. Whatever.) Have I ever said otherwise? Indeed, my whole premise *depends* on the fact that DNS is absolutely precise while people are generally rather imprecise in their communications. The one counter-argument that actually speaks to my point -- that I can think of -- would be that computers are really lousy at deciphering human ambiguity. Which is true enough. But I think Google, Facebook, et. al., have demonstrated that it's not impossible to program a computer to deal with human ambiguity, provided you have enough computrons and limit the scope. Okay, one more counter-argument: To be useful, such services generally have to be popular. To become and remain popular, such services generally have to be widely available. Widely available services tend to get abused by spammers. Restricting service to block spammers is generally antithetical to making it widely available. Effective technological solutions are hard to find; political/economic solutions are expensive. -- Ben From marka at isc.org Wed Aug 5 20:43:12 2009 From: marka at isc.org (Mark Andrews) Date: Thu, 06 Aug 2009 11:43:12 +1000 Subject: dnscurve and DNS hardening, was Re: Dan Kaminsky In-Reply-To: Your message of "Wed, 05 Aug 2009 21:17:01 -0400." References: <4A7870BA.4020704@xyonet.com> <20090805164823.43774.qmail@simone.iecc.com> <3efd34cc0908051012q74fadfdej620cd0dcb20c1ea8@mail.gmail.com> <20090805180608.GA81225@bluepipe.dk> <20090805175855.2f68b9d9@cs.columbia.edu> Message-ID: <200908060143.n761hC1L001916@drugs.dv.isc.org> In message , "John R. Levine" writes: > >>> http://dnscurve.org/crypto.html, which is always brought up, but > >>> never seems to solve the problems mentioned. > > > As I understand it, dnscurve protects transmissions, not objects. > > That's not the way DNS operates today, what with N levels of cache. It > > may or may not be better, but it's a much bigger delta to today's > > systems and practices than DNSSEC is. > > I took a closer look, and I have to say he did a really good job of > integrating dnscurve into the way DNS works. Each request and response is > protected by PKI, sort of like per message TLS. The public key for a > server is encoded into the server's name, and the one for a client is > passed in the packet. The name server name trick gives much of the zone > chaining you get from DNSSEC. > > He doesn't say anything explicit about chained caches, but it seems pretty > clear that you's have to tell the client cache about the server cache's > key at the same time you tell it the server cache's IP address. > > It seems to me that the situation is no worse than DNSSEC, since in both > cases the software at each hop needs to be aware of the security stuff, or > you fall back to plain unsigned DNS. > > R's, > John The DNSCurve concept is fine the implementation however is really poorly done. It also only works well for iterative resolvers. It doesn't work well for stub resolvers, nameservers that forward etc. as one now has a key distribution problem. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From morrowc.lists at gmail.com Wed Aug 5 20:53:44 2009 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Wed, 5 Aug 2009 21:53:44 -0400 Subject: DNS hardening, was Re: Dan Kaminsky In-Reply-To: <4A7A0D6C.90808@mail-abuse.org> References: <20090805164823.43774.qmail@simone.iecc.com> <4A79CB90.708@mail-abuse.org> <90CEC867-A870-4E45-AFC2-898AD655699E@arbor.net> <4A79F8A3.9040302@mail-abuse.org> <75cb24520908051449n29c53491m90fd021022d9816f@mail.gmail.com> <4A7A0D6C.90808@mail-abuse.org> Message-ID: <75cb24520908051853t6c0f05d3l94c404d3227d191c@mail.gmail.com> On Wed, Aug 5, 2009 at 6:53 PM, Douglas Otis wrote: > On 8/5/09 2:49 PM, Christopher Morrow wrote: >> >> and state-management seems like it won't be too much of a problem on >> that dns server... wait, yes it will. > > DNSSEC UDP will likely become problematic. ?This might be due to reflected > attacks, fragmentation related congestion, or packet loss. When it does, TCP because all of these problems aren't already problems today? how is dnssec adding to this? or is your premise that dnssec adds to it because it requires edns0 and larger responses? > fallback will tried. ?TCP must retain state for every attempt to connect, ask worldnic how well that works... edns0 exists (for at least) the sidestep of truncate and use tcp. > and will require significantly greater resources for comparable levels of > resilience. Do you really think that dns in the future is going to move to mostly TCP based transport? do you know what added latency that will be for all clients which switch? What about handling more stateful requests on what today are stateless systems? (f-root-style anycasted pods of authoritative resolvers) > SCTP instead uses cryptographic cookies and the client to retain this state > information. ?SCTP can bundle several transactions into a common > association, which reduces overhead and latency compared against TCP. SCTP great... which internet scale applications use SCTP today? Which loadbalancers are prepared to deal with this 'new' requirement? > ensures against source spoofed reflected attacks or related resource > exhaustion. ?TCP or UDP does not. ?Under load, SCTP can redirect services how does SCTP ensure against spoofed or reflected attacks? > without using anycast. ?TCP can not. explain your assertions please... these seem like overly broad marketing slides which may be truthful in a corner-case but under wide deployment aren't going to work in this manner. -Chris From naveen at calpop.com Wed Aug 5 21:05:24 2009 From: naveen at calpop.com (Naveen Nathan) Date: Wed, 5 Aug 2009 19:05:24 -0700 Subject: dnscurve and DNS hardening, was Re: Dan Kaminsky In-Reply-To: References: <4A7870BA.4020704@xyonet.com> <20090805164823.43774.qmail@simone.iecc.com> <3efd34cc0908051012q74fadfdej620cd0dcb20c1ea8@mail.gmail.com> <20090805180608.GA81225@bluepipe.dk> <20090805175855.2f68b9d9@cs.columbia.edu> Message-ID: <20090806020524.GK30683@armakuni.lastninja.net> On Wed, Aug 05, 2009 at 09:17:01PM -0400, John R. Levine wrote: > ... > > It seems to me that the situation is no worse than DNSSEC, since in both > cases the software at each hop needs to be aware of the security stuff, or > you fall back to plain unsigned DNS. I might misunderstand how dnscurve works, but it appears that dnscurve is far easier to deploy and get running. The issue is merely coverage. How much of DNS do you want to protect. This is analagous to SMTP security, the more MTAs that support TLS the proportional increase of security in the system as a whole. Dnscurve appears to be another form of opportunistic encryption, the more servers that employ dnscurve means an accretion in security of DNS as a whole. From marka at isc.org Wed Aug 5 21:27:21 2009 From: marka at isc.org (Mark Andrews) Date: Thu, 06 Aug 2009 12:27:21 +1000 Subject: Dan Kaminsky In-Reply-To: Your message of "Wed, 05 Aug 2009 20:05:54 -0400." <59f980d60908051705rd8bbb49vceafda9e78abe4a5@mail.gmail.com> References: <4A7870BA.4020704@xyonet.com> <20090804183246.B69B41CC34@ptavv.es.net> <20090805141810.GA24211@ussenterprise.ufp.org> <823a86cow4.fsf@mid.bfk.de> <20090805160703.GA35668@ussenterprise.ufp.org> <202705b0908050949p2285aef0qae1c78aa5f17f71a@mail.gmail.com> <59f980d60908051526n7ab973ebi5285439e4a35285a@mail.gmail.com> <20090805223732.GC1408048@hiwaay.net> <59f980d60908051602y1fe364devfb5f590a8c7959dc@mail.gmail.com> <200908052330.n75NUNlV001012@drugs.dv.isc.org> <59f980d60908051705rd8bbb49vceafda9e78abe4a5@mail.gmail.com> Message-ID: <200908060227.n762RLWu002293@drugs.dv.isc.org> > -- Ben @ 209.85.221.52 Really? farside.isc.org:marka {2} % telnet 209.85.221.52 25 Trying 209.85.221.52... Connected to mail-qy0-f52.google.com. Escape character is '^]'. 220 mx.google.com ESMTP 26si8920387qyk.119 helo farside.isc.org 250 mx.google.com at your service mail from: 250 2.1.0 OK 26si8920387qyk.119 rcpt to: 550-5.1.1 The email account that you tried to reach does not exist. Please try 550-5.1.1 double-checking the recipient's email address for typos or 550-5.1.1 unnecessary spaces. Learn more at 550 5.1.1 http://mail.google.com/support/bin/answer.py?answer=6596 26si8920387qyk.119 quit 221 2.0.0 closing connection 26si8920387qyk.119 Connection closed by foreign host. farside.isc.org:marka {3} % -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From Skywing at valhallalegends.com Wed Aug 5 21:43:38 2009 From: Skywing at valhallalegends.com (Skywing) Date: Wed, 5 Aug 2009 21:43:38 -0500 Subject: dnscurve and DNS hardening, was Re: Dan Kaminsky In-Reply-To: <20090806020524.GK30683@armakuni.lastninja.net> References: <4A7870BA.4020704@xyonet.com> <20090805164823.43774.qmail@simone.iecc.com> <3efd34cc0908051012q74fadfdej620cd0dcb20c1ea8@mail.gmail.com> <20090805180608.GA81225@bluepipe.dk> <20090805175855.2f68b9d9@cs.columbia.edu> <20090806020524.GK30683@armakuni.lastninja.net> Message-ID: <982D8D05B6407A49AD506E6C3AC8E7D60173636A7519@caralain.haven.nynaeve.net> Of course, as long as an adversary in your packet path can force a seamless downgrade (e.g. to plain DNS or plain non-TLS SMTP), the hard security benefit is nowhere near as great as it's sometimes purported to be. And this is a problem that we'll be stuck living with for a very long time as far as I can tell. - S -----Original Message----- From: Naveen Nathan [mailto:naveen at calpop.com] Sent: Wednesday, August 05, 2009 7:05 PM To: John R. Levine Cc: nanog at nanog.org Subject: Re: dnscurve and DNS hardening, was Re: Dan Kaminsky On Wed, Aug 05, 2009 at 09:17:01PM -0400, John R. Levine wrote: > ... > > It seems to me that the situation is no worse than DNSSEC, since in both > cases the software at each hop needs to be aware of the security stuff, or > you fall back to plain unsigned DNS. I might misunderstand how dnscurve works, but it appears that dnscurve is far easier to deploy and get running. The issue is merely coverage. How much of DNS do you want to protect. This is analagous to SMTP security, the more MTAs that support TLS the proportional increase of security in the system as a whole. Dnscurve appears to be another form of opportunistic encryption, the more servers that employ dnscurve means an accretion in security of DNS as a whole. From mailvortex at gmail.com Wed Aug 5 22:01:15 2009 From: mailvortex at gmail.com (Ben Scott) Date: Wed, 5 Aug 2009 23:01:15 -0400 Subject: dnscurve and DNS hardening, was Re: Dan Kaminsky In-Reply-To: <20090806020524.GK30683@armakuni.lastninja.net> References: <4A7870BA.4020704@xyonet.com> <20090805164823.43774.qmail@simone.iecc.com> <3efd34cc0908051012q74fadfdej620cd0dcb20c1ea8@mail.gmail.com> <20090805180608.GA81225@bluepipe.dk> <20090805175855.2f68b9d9@cs.columbia.edu> <20090806020524.GK30683@armakuni.lastninja.net> Message-ID: <59f980d60908052001r6d53eed9m3d31a3d8b6d318c6@mail.gmail.com> On Wed, Aug 5, 2009 at 10:05 PM, Naveen Nathan wrote: > I might misunderstand how dnscurve works, but it appears that dnscurve > is far easier to deploy and get running. My understanding: They really do different things. They also have different behaviors. DNSCurve aims to secure the transaction between resolver (client) and the nameserver it queries. It encrypts both question and answer. It authenticates that the answer came from the nameserver queried. DNSSEC authenticates resource records as coming from the "official" delegated zone. Both allow the client to detect a forged answer, and allow the implementation to keep waiting for a non-forged answer. (DJB keeps saying that DNSSEC doesn't allow that, but I don't see why. An implementation of either could respond by giving up on the first invalid packet. Don't do that, then. Keep waiting, like DJB's DNSCurve implementation does.) DNSCurve keeps a sniffer from monitoring DNS queries. DNSSEC leaves those open to any sniffer. DNSSEC authenticates answers to the "zone owner". DNSCurve only protects the "local loop". If a cache is compromised and forged data inserted, a DNSSEC client can detect that; a DNSCurve client cannot. With DNSCurve, to protect against upstream attacks, every upstream cache must implement DNSCurve *and* be trusted by the end-user person. DNSSEC will work even if intermediate caches do not support DNSSEC. Neither is an "easy" implementation; both require changes to DNS infrastructure at both client and server ends to be effective. DNSCurve requires more CPU power on nameservers (for the more extensive crypto); DNSSEC requires more memory (for the additional DNSSEC payload). DNSCurve requires nameservers to have a particular name. DNSSEC does not. I'm told DNSCurve doesn't need any new record types, while DNSSEC does, and that can be a problem for firewalls and intermediate caches which assumed no new record types would ever be defined. There's lots of crappy implementations deployed in the world, so I have no idea how big a problem that might be. I think that's most of it. From a security perspective, I see DNSSEC as having the advantage if you're more worried about someone forging responses (since it authenticates the zone, and not the transaction), and DNSCurve as having the advantage if you're more worried about someone sniffing your DNS traffic. From my chair: I really don't care if someone knows what DNS records I'm looking up. Almost certainly I'll only be looking up records to connect to the associated server. The sniffer can then just look at the IP address. I do care quite a bit if an Internet provider running the local cache starts lying to me about what domain names are what. Say, to redirect things to their "sponsored" sites instead. YMMV. I reserve the right to be wrong. -- Ben From naveen at calpop.com Wed Aug 5 23:45:34 2009 From: naveen at calpop.com (Naveen Nathan) Date: Wed, 5 Aug 2009 21:45:34 -0700 Subject: dnscurve and DNS hardening, was Re: Dan Kaminsky In-Reply-To: <59f980d60908052001r6d53eed9m3d31a3d8b6d318c6@mail.gmail.com> References: <4A7870BA.4020704@xyonet.com> <20090805164823.43774.qmail@simone.iecc.com> <3efd34cc0908051012q74fadfdej620cd0dcb20c1ea8@mail.gmail.com> <20090805180608.GA81225@bluepipe.dk> <20090805175855.2f68b9d9@cs.columbia.edu> <20090806020524.GK30683@armakuni.lastninja.net> <59f980d60908052001r6d53eed9m3d31a3d8b6d318c6@mail.gmail.com> Message-ID: <20090806044533.GN30683@armakuni.lastninja.net> Ben, Thanks for the cogent comparison between the two security systems for DNS. > DNSCurve requires more CPU power on nameservers (for the more > extensive crypto); DNSSEC requires more memory (for the additional > DNSSEC payload). This is only true for the initial (Elliptic Curve) Diffie-Hellman exchange An long-term secret key is computed, but I assume the lifetime is dependant on configuration or implementation. It seems DJB is not only advocating his elliptic curve crypto system, but also his own home-rolled symmetric crypto Salsa20, which is meant to be computationally cheaper than AES in conjunction w/ poly1035whatever for integrity/MAC. I'll assume the cipher used for the lasting secret keys is interchangeable. So after initial communication between two servers that can speak DNSCurve, future communication should be computationally cheaper by using long-term keys. - Naveen From beckman at angryox.com Thu Aug 6 00:20:00 2009 From: beckman at angryox.com (Peter Beckman) Date: Thu, 6 Aug 2009 01:20:00 -0400 Subject: Level3 Routing Problems in Atlanta? Message-ID: I'm having a few troubles with L3 on this fine, dreadfully humid evening. HOST: max Loss% Snt Last Avg Best Wrst StDev 1. mph 0.0% 10 0.7 0.6 0.5 0.8 0.1 2. 10.1.41.89 0.0% 10 1.7 1.9 1.7 2.3 0.2 3. G2-0-3-891.WASHDC-LCR-08.ver 0.0% 10 1.8 1.8 1.7 1.9 0.1 4. so-1-1-0-0.RES-BB-RTR2.veriz 0.0% 10 2.3 2.4 2.2 2.6 0.1 5. 0.so-1-2-0.XL4.IAD8.ALTER.NE 0.0% 10 2.8 2.8 2.6 3.0 0.1 6. 0.xe-8-1-0.BR1.IAD8.ALTER.NE 0.0% 10 4.8 4.6 2.9 4.9 0.6 7. te-11-3-0.edge1.Washington4. 0.0% 10 5.1 3.4 2.8 5.1 0.9 8. vlan69.csw1.Washington1.Leve 0.0% 10 3.6 6.7 3.5 14.6 4.1 9. ae-61-61.ebr1.Washington1.Le 0.0% 10 12.8 9.2 5.7 16.0 3.6 10. ae-2.ebr3.Atlanta2.Level3.ne 10.0% 10 19.9 23.9 19.9 31.8 4.1 11. ge-5-0-0-52.gar2.Atlanta1.Le 0.0% 10 21.4 21.3 21.0 21.8 0.2 12. COX-COMMUNI.gar2.Atlanta1.Le 0.0% 10 209.8 201.7 197.4 209.8 4.0 <-- ew 13. mrfddsrj01-ge710.rd.dc.cox.n 10.0% 10 230.3 230.5 223.9 234.1 3.4 14. 70.164.18.1 10.0% 10 233.3 231.7 225.1 236.7 4.0 Return trip: HOST: 70.164.19.xx Loss% Snt Last Avg Best Wrst StDev 1. 70.164.19.3 0.0% 20 0.2 0.2 0.2 0.4 0.0 2. wsip-70-168-111-17.dc.dc.cox 5.0% 20 11.2 17.7 1.6 97.1 28.5 3. mrfddsrj01-ge706.rd.dc.cox.n 10.0% 20 36.9 42.0 1.4 282.6 79.5 4. 68.1.1.121 0.0% 20 31.4 39.1 24.0 157.9 28.6 5. ae-2-52.edge2.Atlanta2.Level 5.0% 20 211.9 212.2 208.0 215.7 2.1 <-- ew 6. 0.so-1-1-0.BR2.ATL4.ALTER.NE 0.0% 20 214.4 213.7 209.0 224.7 3.8 7. 0.so-2-1-0.XT1.ATL4.ALTER.NE 0.0% 20 51.7 55.6 50.6 62.5 3.3 8. 0.so-6-2-0.ATL01-BB-RTR1.VER 0.0% 20 56.7 60.0 51.0 123.1 15.1 9. so-7-1-0-0.LCC1-RES-BB-RTR1- 0.0% 20 229.6 231.6 228.6 239.7 2.8 10. P14-0.WASHDC-LCR-01.verizon- 0.0% 20 51.5 50.3 46.5 59.0 2.5 11. P13-0.WASHDC-LCR-03.verizon- 0.0% 20 226.9 245.0 226.9 363.4 33.0 12. P12-0.WASHDC-LCR-05.verizon- 0.0% 20 229.3 231.7 225.6 236.5 3.1 13. P15-0.WASHDC-LCR-07.verizon- 5.0% 20 320.0 243.6 226.6 324.9 29.3 14. ??? 100.0 20 0.0 0.0 0.0 0.0 0.0 15. mph (verizon vios in DC) 5.0% 20 231.3 232.1 227.2 235.2 2.3 Anyone else see this? Know what's going on? My route is kind of silly... I'm in Northern VA on Verizon FIOS, about 2 physical miles from the IP on Cox. Thank goodness for the speed of light. --------------------------------------------------------------------------- Peter Beckman Internet Guy beckman at angryox.com http://www.angryox.com/ --------------------------------------------------------------------------- From scott at doc.net.au Thu Aug 6 01:02:16 2009 From: scott at doc.net.au (Scott Howard) Date: Wed, 5 Aug 2009 23:02:16 -0700 Subject: Level3 Routing Problems in Atlanta? In-Reply-To: References: Message-ID: Starting a little closer and I'm seeing : traceroute to 70.164.18.1 (70.164.18.1), 64 hops max, 52 byte packets 1 ge-7-21.car1.Atlanta1.Level3.net (4.71.24.129) 0.393 ms 1.590 ms 1.492 ms 2 ge-6-0-0-51.gar2.Atlanta1.Level3.net (4.68.103.7) 3.484 ms 3.981 ms 5.614 ms 3 COX-COMMUNI.gar2.Atlanta1.Level3.net (65.59.222.6) 14.860 ms 124.165 ms 120.303 ms <--- 4 mrfddsrj01-ge710.rd.dc.cox.net (68.1.1.5) 28.224 ms 28.221 ms 23.729 ms 5 nova-gw.nova.org (70.164.18.1) 26.850 ms 34.466 ms 24.355 ms Hop 4 seems a bit variable - sometimes it's there, sometimes it's not : 3 COX-COMMUNI.gar2.Atlanta1.Level3.net (65.59.222.6) 10.614 ms 5.734 ms 15.114 ms 4 * * * 5 nova-gw.nova.org (70.164.18.1) 33.154 ms 27.222 ms 30.242 ms Overall ping times to the host are jumping between 30ms and 130ms : $ ping 70.164.18.1 PING 70.164.18.1 (70.164.18.1): 56 data bytes 64 bytes from 70.164.18.1: icmp_seq=0 ttl=251 time=122.090 ms 64 bytes from 70.164.18.1: icmp_seq=1 ttl=251 time=141.325 ms 64 bytes from 70.164.18.1: icmp_seq=2 ttl=251 time=137.261 ms 64 bytes from 70.164.18.1: icmp_seq=3 ttl=251 time=39.210 ms 64 bytes from 70.164.18.1: icmp_seq=4 ttl=251 time=33.649 ms 64 bytes from 70.164.18.1: icmp_seq=5 ttl=251 time=24.591 ms 64 bytes from 70.164.18.1: icmp_seq=6 ttl=251 time=128.027 ms 64 bytes from 70.164.18.1: icmp_seq=7 ttl=251 time=33.224 ms Scott. On Wed, Aug 5, 2009 at 10:20 PM, Peter Beckman wrote: > I'm having a few troubles with L3 on this fine, dreadfully humid evening. > > HOST: max Loss% Snt Last Avg Best Wrst > StDev > 1. mph 0.0% 10 0.7 0.6 0.5 0.8 0.1 > 2. 10.1.41.89 0.0% 10 1.7 1.9 1.7 2.3 0.2 > 3. G2-0-3-891.WASHDC-LCR-08.ver 0.0% 10 1.8 1.8 1.7 1.9 0.1 > 4. so-1-1-0-0.RES-BB-RTR2.veriz 0.0% 10 2.3 2.4 2.2 2.6 0.1 > 5. 0.so-1-2-0.XL4.IAD8.ALTER.NE 0.0% 10 2.8 2.8 2.6 3.0 > 0.1 > 6. 0.xe-8-1-0.BR1.IAD8.ALTER.NE 0.0% 10 4.8 4.6 2.9 4.9 > 0.6 > 7. te-11-3-0.edge1.Washington4. 0.0% 10 5.1 3.4 2.8 5.1 0.9 > 8. vlan69.csw1.Washington1.Leve 0.0% 10 3.6 6.7 3.5 14.6 4.1 > 9. ae-61-61.ebr1.Washington1.Le 0.0% 10 12.8 9.2 5.7 16.0 3.6 > 10. ae-2.ebr3.Atlanta2.Level3.ne 10.0% 10 19.9 23.9 19.9 31.8 > 4.1 > 11. ge-5-0-0-52.gar2.Atlanta1.Le 0.0% 10 21.4 21.3 21.0 21.8 > 0.2 > 12. COX-COMMUNI.gar2.Atlanta1.Le 0.0% 10 209.8 201.7 197.4 209.8 > 4.0 <-- ew > 13. mrfddsrj01-ge710.rd.dc.cox.n 10.0% 10 230.3 230.5 223.9 234.1 > 3.4 > 14. 70.164.18.1 10.0% 10 233.3 231.7 225.1 236.7 > 4.0 > > Return trip: > HOST: 70.164.19.xx Loss% Snt Last Avg Best Wrst > StDev > 1. 70.164.19.3 0.0% 20 0.2 0.2 0.2 0.4 0.0 > 2. wsip-70-168-111-17.dc.dc.cox 5.0% 20 11.2 17.7 1.6 97.1 28.5 > 3. mrfddsrj01-ge706.rd.dc.cox.n 10.0% 20 36.9 42.0 1.4 282.6 79.5 > 4. 68.1.1.121 0.0% 20 31.4 39.1 24.0 157.9 28.6 > 5. ae-2-52.edge2.Atlanta2.Level 5.0% 20 211.9 212.2 208.0 215.7 2.1 > <-- ew > 6. 0.so-1-1-0.BR2.ATL4.ALTER.NE 0.0% 20 214.4 213.7 209.0 224.7 > 3.8 > 7. 0.so-2-1-0.XT1.ATL4.ALTER.NE 0.0% 20 51.7 55.6 50.6 62.5 > 3.3 > 8. 0.so-6-2-0.ATL01-BB-RTR1.VER 0.0% 20 56.7 60.0 51.0 123.1 15.1 > 9. so-7-1-0-0.LCC1-RES-BB-RTR1- 0.0% 20 229.6 231.6 228.6 239.7 2.8 > 10. P14-0.WASHDC-LCR-01.verizon- 0.0% 20 51.5 50.3 46.5 59.0 > 2.5 > 11. P13-0.WASHDC-LCR-03.verizon- 0.0% 20 226.9 245.0 226.9 363.4 > 33.0 > 12. P12-0.WASHDC-LCR-05.verizon- 0.0% 20 229.3 231.7 225.6 236.5 > 3.1 > 13. P15-0.WASHDC-LCR-07.verizon- 5.0% 20 320.0 243.6 226.6 324.9 > 29.3 > 14. ??? 100.0 20 0.0 0.0 0.0 0.0 > 0.0 > 15. mph (verizon vios in DC) 5.0% 20 231.3 232.1 227.2 235.2 > 2.3 > > Anyone else see this? Know what's going on? > > My route is kind of silly... I'm in Northern VA on Verizon FIOS, about 2 > physical miles from the IP on Cox. Thank goodness for the speed of light. > > --------------------------------------------------------------------------- > Peter Beckman Internet Guy > beckman at angryox.com > http://www.angryox.com/ > --------------------------------------------------------------------------- > > From vixie at isc.org Thu Aug 6 01:51:24 2009 From: vixie at isc.org (Paul Vixie) Date: Thu, 06 Aug 2009 06:51:24 +0000 Subject: DNS hardening, was Re: Dan Kaminsky In-Reply-To: <75cb24520908051853t6c0f05d3l94c404d3227d191c@mail.gmail.com> (Christopher Morrow's message of "Wed\, 5 Aug 2009 21\:53\:44 -0400") References: <20090805164823.43774.qmail@simone.iecc.com> <4A79CB90.708@mail-abuse.org> <90CEC867-A870-4E45-AFC2-898AD655699E@arbor.net> <4A79F8A3.9040302@mail-abuse.org> <75cb24520908051449n29c53491m90fd021022d9816f@mail.gmail.com> <4A7A0D6C.90808@mail-abuse.org> <75cb24520908051853t6c0f05d3l94c404d3227d191c@mail.gmail.com> Message-ID: Christopher Morrow writes: > how does SCTP ensure against spoofed or reflected attacks? there is no server side protocol control block required in SCTP. someone sends you a "create association" request, you send back a "ok, here's your cookie" and you're done until/unless they come back and say "ok, here's my cookie, and here's my DNS request." so a spoofer doesn't get a cookie and a reflector doesn't burden a server any more than a ddos would do. because of the extra round trips nec'y to create an SCTP "association" (for which you can think, lightweight TCP-like session-like), it's going to be nec'y to leave associations in place between iterative caches and authority servers, and in place between stubs and iterative caches. however, because the state is mostly on the client side, a server with associations open to millions of clients at the same time is actually no big deal. -- Paul Vixie KI6YSY From fweimer at bfk.de Thu Aug 6 02:07:32 2009 From: fweimer at bfk.de (Florian Weimer) Date: Thu, 06 Aug 2009 07:07:32 +0000 Subject: DNS hardening, was Re: Dan Kaminsky In-Reply-To: <4A79CB90.708@mail-abuse.org> (Douglas Otis's message of "Wed\, 05 Aug 2009 11\:12\:32 -0700") References: <20090805164823.43774.qmail@simone.iecc.com> <4A79CB90.708@mail-abuse.org> Message-ID: <82my6d8lor.fsf@mid.bfk.de> * Douglas Otis: > Establishing SCTP as a preferred DNS transport offers a safe harbor > for major ISPs. SCTP is not a suitable transport for DNS, for several reasons: Existing SCTP stacks are not particularly robust (far less than TCP). The number of bugs still found in them is rather large. Only very few stacks (if any) implement operation without kernel buffers. The remaining ones are subject to the same state exhaustion attacks as TCP stacks are. At least some parts of SCTP and the SCTP API were designed for a cooperative environment. The SCTP API specification is very ambiguous, which is quite strange for such a young protocol. For instance, it is not clear if a single socket is used to communicate with multiple peers, head-of-line blocking can occur. The protocol has insufficient signalling to ensure that implementations turn off features which are harmful on a global scale. For instance, persistant authoritative <-> resolver connections only work if you switch off heartbeat, but the protocol cannot do this, and it is likely that many peers won't do it. SCTP proposers generally counter these observations by referring to extensions and protocols which are not yet standardized, not implemented, or both, constantly moving the goalposts. -- Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra?e 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From fweimer at bfk.de Thu Aug 6 02:11:35 2009 From: fweimer at bfk.de (Florian Weimer) Date: Thu, 06 Aug 2009 07:11:35 +0000 Subject: DNS hardening, was Re: Dan Kaminsky In-Reply-To: <4A7A0D6C.90808@mail-abuse.org> (Douglas Otis's message of "Wed\, 05 Aug 2009 15\:53\:32 -0700") References: <20090805164823.43774.qmail@simone.iecc.com> <4A79CB90.708@mail-abuse.org> <90CEC867-A870-4E45-AFC2-898AD655699E@arbor.net> <4A79F8A3.9040302@mail-abuse.org> <75cb24520908051449n29c53491m90fd021022d9816f@mail.gmail.com> <4A7A0D6C.90808@mail-abuse.org> Message-ID: <82iqh18li0.fsf@mid.bfk.de> * Douglas Otis: > DNSSEC UDP will likely become problematic. This might be due to > reflected attacks, SCTP does not stop reflective attacks at the DNS level. To deal with this issue, you need DNSSEC's denial of existence. The DNSSEC specs currently doesn't allow you to stop these attacks dead in your resolver, but the data is already there. -- Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra?e 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From fweimer at bfk.de Thu Aug 6 02:22:14 2009 From: fweimer at bfk.de (Florian Weimer) Date: Thu, 06 Aug 2009 07:22:14 +0000 Subject: DNS hardening, was Re: Dan Kaminsky In-Reply-To: (Paul Vixie's message of "Thu\, 06 Aug 2009 06\:51\:24 +0000") References: <20090805164823.43774.qmail@simone.iecc.com> <4A79CB90.708@mail-abuse.org> <90CEC867-A870-4E45-AFC2-898AD655699E@arbor.net> <4A79F8A3.9040302@mail-abuse.org> <75cb24520908051449n29c53491m90fd021022d9816f@mail.gmail.com> <4A7A0D6C.90808@mail-abuse.org> <75cb24520908051853t6c0f05d3l94c404d3227d191c@mail.gmail.com> Message-ID: <82eirp8l09.fsf@mid.bfk.de> * Paul Vixie: > there is no server side protocol control block required in SCTP. SCTP needs per-peer state for congestion control and retransmission. > someone sends you a "create association" request, you send back a > "ok, here's your cookie" and you're done until/unless they come back > and say "ok, here's my cookie, and here's my DNS request." so a > spoofer doesn't get a cookie and a reflector doesn't burden a server > any more than a ddos would do. This is a red herring. The TCP state issues are deeper and haven't got much to do with source address validation. The issues are mostly caused by how the BSD sockets API is designed. SCTP uses the same API model, and suffers from similar problems. > because of the extra round trips nec'y to create an SCTP "association" (for > which you can think, lightweight TCP-like session-like), it's going to be > nec'y to leave associations in place between iterative caches and authority > servers, and in place between stubs and iterative caches. This doesn't seem possible with current SCTP because the heartbeat rate quickly adds up and overloads servers further upstream. It also does not work on UNIX-like system where processes are short-lived and get a fresh stub resolver each time they are restarted. -- Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra?e 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From fweimer at bfk.de Thu Aug 6 02:32:50 2009 From: fweimer at bfk.de (Florian Weimer) Date: Thu, 06 Aug 2009 07:32:50 +0000 Subject: DNS hardening, was Re: Dan Kaminsky In-Reply-To: <20090805164823.43774.qmail@simone.iecc.com> (John Levine's message of "5 Aug 2009 16\:48\:23 -0000") References: <20090805164823.43774.qmail@simone.iecc.com> Message-ID: <82ab2d8kil.fsf@mid.bfk.de> * John Levine: > 3) Random case in queries, e.g. GooGLe.CoM This does not work well without additional changes because google.com can be spoofed with responses to 123352123.com (or even 123352123.). Unbound strives to implement the necessary changes, some of which are also required if you want to use DNSSEC to compensate for lack of channel security. As far as I know (and Paul will certainly correct me), the necessary changes are not present in current BIND releases. > 4) Ask twice (with different values for the first three hacks) and > compare the answers There is a protocol proposal to cope with fluctuating data, but I'm not aware that anyone has expressed interest in implementing it. Basically, the idea is to reduce caching for such data, so that successful spoofing attacks have less amplification effect. > I presume everyone is doing the first two. Any experience with the > other two to report? 0x20 has alleged interoperability issues. It's also not such a simple upgrade as it was initially thought, so the trade-off is rather poor for existing resolver code bases. -- Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra?e 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From fweimer at bfk.de Thu Aug 6 02:37:01 2009 From: fweimer at bfk.de (Florian Weimer) Date: Thu, 06 Aug 2009 07:37:01 +0000 Subject: dnscurve and DNS hardening, was Re: Dan Kaminsky In-Reply-To: <20090806044533.GN30683@armakuni.lastninja.net> (Naveen Nathan's message of "Wed\, 5 Aug 2009 21\:45\:34 -0700") References: <4A7870BA.4020704@xyonet.com> <20090805164823.43774.qmail@simone.iecc.com> <3efd34cc0908051012q74fadfdej620cd0dcb20c1ea8@mail.gmail.com> <20090805180608.GA81225@bluepipe.dk> <20090805175855.2f68b9d9@cs.columbia.edu> <20090806020524.GK30683@armakuni.lastninja.net> <59f980d60908052001r6d53eed9m3d31a3d8b6d318c6@mail.gmail.com> <20090806044533.GN30683@armakuni.lastninja.net> Message-ID: <82k51h75r6.fsf@mid.bfk.de> * Naveen Nathan: > I'll assume the cipher used for the lasting secret keys is interchangeable. Last time I checked, even the current cryptographic algorithms weren't specified. It's unlikely that there is an upgrade path (other than stuffing yet another magic label into your name server names). -- Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra?e 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From paul at jakma.org Thu Aug 6 04:04:32 2009 From: paul at jakma.org (Paul Jakma) Date: Thu, 6 Aug 2009 10:04:32 +0100 (BST) Subject: DNS hardening, was Re: Dan Kaminsky In-Reply-To: <82eirp8l09.fsf@mid.bfk.de> References: <20090805164823.43774.qmail@simone.iecc.com> <4A79CB90.708@mail-abuse.org> <90CEC867-A870-4E45-AFC2-898AD655699E@arbor.net> <4A79F8A3.9040302@mail-abuse.org> <75cb24520908051449n29c53491m90fd021022d9816f@mail.gmail.com> <4A7A0D6C.90808@mail-abuse.org> <75cb24520908051853t6c0f05d3l94c404d3227d191c@mail.gmail.com> <82eirp8l09.fsf@mid.bfk.de> Message-ID: On Thu, 6 Aug 2009, Florian Weimer wrote: > This doesn't seem possible with current SCTP because the heartbeat > rate quickly adds up and overloads servers further upstream. It > also does not work on UNIX-like system where processes are > short-lived and get a fresh stub resolver each time they are > restarted. Stubs on Unix systems can have long-lived processes that handle the actual lookups, the stub component in the process that calls into the resolver then accesses it via IPC. I.e. the NSCD style approach. regards, -- Paul Jakma paul at jakma.org Key ID: 64A2FF6A Fortune: As Zeus said to Narcissus, "Watch yourself." From a.harrowell at gmail.com Thu Aug 6 05:06:49 2009 From: a.harrowell at gmail.com (Alexander Harrowell) Date: Thu, 6 Aug 2009 11:06:49 +0100 Subject: dnscurve and DNS hardening, was Re: Dan Kaminsky In-Reply-To: <82k51h75r6.fsf@mid.bfk.de> References: <4A7870BA.4020704@xyonet.com> <20090806044533.GN30683@armakuni.lastninja.net> <82k51h75r6.fsf@mid.bfk.de> Message-ID: <200908061106.57699.a.harrowell@gmail.com> There are really two security problems here, which implies that two different methods might be necessary: 1) Authenticate the nameserver to the client (and so on up the chain to the root) in order to defeat the Kaminsky attack, man in the middle, IP-layer interference. (Are you who you say you are?) 2) Validate the information in the nameserver. (OK, so you're the nameserver; but who says www.google.com is 1.2.3.4?) 1) is the transport layer problem; 2) is the dnssec/zone signing problem. -------------- 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 elmi at 4ever.de Thu Aug 6 05:07:53 2009 From: elmi at 4ever.de (Elmar K. Bins) Date: Thu, 6 Aug 2009 12:07:53 +0200 Subject: Conclusion: Smart hands in NYC area and new: Tokyo Message-ID: <20090806100752.GL43104@ronin.4ever.de> Hello altogether, I got a couple of freelancers and a few tips which companies to use. I thought I'd at least share the company recommendations, of which I'll have the bosses pick. One other thing - I'll be needing the same thing in Tokyo by the end of the year. If anyone has recommendations, please don't hesitate. I'm not shy of travelling, but I'd rather save time and money there... Yours, Elmar. Recommended companies: Team Silverback (www.teamsilverback.com) OnForce (www.onforce.com) Endeavor Xeta Blackbox Ledcor (www.ltscompany.com) From dot at dotat.at Thu Aug 6 07:48:56 2009 From: dot at dotat.at (Tony Finch) Date: Thu, 6 Aug 2009 13:48:56 +0100 Subject: dnscurve and DNS hardening, was Re: Dan Kaminsky In-Reply-To: <20090806020524.GK30683@armakuni.lastninja.net> References: <4A7870BA.4020704@xyonet.com> <20090805164823.43774.qmail@simone.iecc.com> <3efd34cc0908051012q74fadfdej620cd0dcb20c1ea8@mail.gmail.com> <20090805180608.GA81225@bluepipe.dk> <20090805175855.2f68b9d9@cs.columbia.edu> <20090806020524.GK30683@armakuni.lastninja.net> Message-ID: On Wed, 5 Aug 2009, Naveen Nathan wrote: > > I might misunderstand how dnscurve works, but it appears that dnscurve > is far easier to deploy and get running. Not really. There are multiple competing mature implementations of DNSSEC and you won't be in a network of 1 if you deploy it. Tony. -- f.anthony.n.finch http://dotat.at/ GERMAN BIGHT HUMBER: SOUTHWEST 5 TO 7. MODERATE OR ROUGH. SQUALLY SHOWERS. MODERATE OR GOOD. From Ed.Lewis at neustar.biz Thu Aug 6 09:19:18 2009 From: Ed.Lewis at neustar.biz (Edward Lewis) Date: Thu, 6 Aug 2009 10:19:18 -0400 Subject: A DNSSEC irony In-Reply-To: <4A7A0D6C.90808@mail-abuse.org> References: <20090805164823.43774.qmail@simone.iecc.com> <4A79CB90.708@mail-abuse.org> <90CEC867-A870-4E45-AFC2-898AD655699E@arbor.net> <4A79F8A3.9040302@mail-abuse.org> <75cb24520908051449n29c53491m90fd021022d9816f@mail.gmail.com> <4A7A0D6C.90808@mail-abuse.org> Message-ID: At 15:53 -0700 8/5/09, Douglas Otis wrote: >DNSSEC UDP will likely become problematic. dotORG (.org) is DNSSEC signed now. nanog.org is DNSSEC signed now. Still getting mail on the list saying "DNSSEC UDP will be a problem"... (from some commercial's punch line) ...priceless Continuing, >This might be due to reflected attacks, fragmentation related >congestion, or packet loss. The same issues (related to the size of DNSSEC answers) are also true for the size of IPv6 answers (AAAA RR) and the size of ENUM (NAPTR RR) answers. I.e., the perceived issues related to stuffing data into larger (than 512B) datagrams aren't unique to DNSSEC. So, if you are paranoid about DNSSEC now, don't worry, there's more to be paranoid about around the corner. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 As with IPv6, the problem with the deployment of frictionless surfaces is that they're not getting traction. From morrowc.lists at gmail.com Thu Aug 6 09:18:11 2009 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Thu, 6 Aug 2009 10:18:11 -0400 Subject: DNS hardening, was Re: Dan Kaminsky In-Reply-To: References: <20090805164823.43774.qmail@simone.iecc.com> <4A79CB90.708@mail-abuse.org> <90CEC867-A870-4E45-AFC2-898AD655699E@arbor.net> <4A79F8A3.9040302@mail-abuse.org> <75cb24520908051449n29c53491m90fd021022d9816f@mail.gmail.com> <4A7A0D6C.90808@mail-abuse.org> <75cb24520908051853t6c0f05d3l94c404d3227d191c@mail.gmail.com> Message-ID: <75cb24520908060718t4a126852mda34fe2de0f92626@mail.gmail.com> On Thu, Aug 6, 2009 at 2:51 AM, Paul Vixie wrote: > Christopher Morrow writes: > >> how does SCTP ensure against spoofed or reflected attacks? > > there is no server side protocol control block required in SCTP. ?someone > sends you a "create association" request, you send back a "ok, here's your > cookie" and you're done until/unless they come back and say "ok, here's my > cookie, and here's my DNS request." ?so a spoofer doesn't get a cookie and > a reflector doesn't burden a server any more than a ddos would do. awesome, how does that work with devices in the f-root-anycast design? (both local hosts in the rack and if I flip from rack to rack) If I send along a request to a host which I do not have an association created do I get a failure and then re-setup? (inducing further latency) > because of the extra round trips nec'y to create an SCTP "association" (for > which you can think, lightweight TCP-like session-like), it's going to be > nec'y to leave associations in place between iterative caches and authority > servers, and in place between stubs and iterative caches. ?however, because > the state is mostly on the client side, a server with associations open to > millions of clients at the same time is actually no big deal. See question above, as well as: "Do loadbalancers, or loadbalanced deployments, deal with this properly?" (loadbalancers like F5, citrix, radware, cisco, etc...) -Chris From dotis at mail-abuse.org Thu Aug 6 10:07:16 2009 From: dotis at mail-abuse.org (Douglas Otis) Date: Thu, 06 Aug 2009 08:07:16 -0700 Subject: dnscurve and DNS hardening, was Re: Dan Kaminsky In-Reply-To: <20090806020524.GK30683@armakuni.lastninja.net> References: <4A7870BA.4020704@xyonet.com> <20090805164823.43774.qmail@simone.iecc.com> <3efd34cc0908051012q74fadfdej620cd0dcb20c1ea8@mail.gmail.com> <20090805180608.GA81225@bluepipe.dk> <20090805175855.2f68b9d9@cs.columbia.edu> <20090806020524.GK30683@armakuni.lastninja.net> Message-ID: <4A7AF1A4.2040402@mail-abuse.org> On 8/5/09 7:05 PM, Naveen Nathan wrote: > On Wed, Aug 05, 2009 at 09:17:01PM -0400, John R. Levine wrote: >> ... >> >> It seems to me that the situation is no worse than DNSSEC, since in both >> cases the software at each hop needs to be aware of the security stuff, or >> you fall back to plain unsigned DNS. > > I might misunderstand how dnscurve works, but it appears that dnscurve > is far easier to deploy and get running. The issue is merely coverage. There might be issues related to intellectual property use. :^( -Doug From vixie at isc.org Thu Aug 6 10:16:25 2009 From: vixie at isc.org (Paul Vixie) Date: Thu, 06 Aug 2009 15:16:25 +0000 Subject: DNS hardening, was Re: Dan Kaminsky In-Reply-To: Your message of "Thu, 06 Aug 2009 10:18:11 -0400." <75cb24520908060718t4a126852mda34fe2de0f92626@mail.gmail.com> References: <20090805164823.43774.qmail@simone.iecc.com> <4A79CB90.708@mail-abuse.org> <90CEC867-A870-4E45-AFC2-898AD655699E@arbor.net> <4A79F8A3.9040302@mail-abuse.org> <75cb24520908051449n29c53491m90fd021022d9816f@mail.gmail.com> <4A7A0D6C.90808@mail-abuse.org> <75cb24520908051853t6c0f05d3l94c404d3227d191c@mail.gmail.com> <75cb24520908060718t4a126852mda34fe2de0f92626@mail.gmail.com> Message-ID: <18285.1249571785@nsa.vix.com> note, i went off-topic in my previous note, and i'll be answering florian on namedroppers@ since it's not operational. chris's note was operational: > Date: Thu, 6 Aug 2009 10:18:11 -0400 > From: Christopher Morrow > > awesome, how does that work with devices in the f-root-anycast design? > (both local hosts in the rack and if I flip from rack to rack) If I send > along a request to a host which I do not have an association created do I > get a failure and then re-setup? (inducing further latency) yes. so, association setup cost will occur once per route-change event. note that the f-root-anycast design already hashes by flow within a rack to keep TCP from failing, so the only route-change events of interest to this point are in wide area BGP. > ...: "Do loadbalancers, or loadbalanced deployments, deal with this > properly?" (loadbalancers like F5, citrix, radware, cisco, etc...) as far as i know, no loadbalancer understands SCTP today. if they can be made to pass SCTP through unmodified and only do their enhanced L4 on UDP and TCP as they do now, all will be well. if not then a loadbalancer upgrade or removal will be nec'y for anyone who wants to deploy SCTP. it's interesting to me that existing deployments of L4-aware packet level devices can form a barrier to new kinds of L4. it's as if the internet is really just the web, and our networks are TCP/UDP networks not IP networks. From jmamodio at gmail.com Thu Aug 6 10:25:19 2009 From: jmamodio at gmail.com (Jorge Amodio) Date: Thu, 6 Aug 2009 10:25:19 -0500 Subject: DOS in progress ? Message-ID: <202705b0908060825y55b775aew9a3601fae77f9207@mail.gmail.com> Are folks seeing any major DOS in progress ? Twitter seems to be under one and FB is flaky. From ross at kallisti.us Thu Aug 6 10:26:05 2009 From: ross at kallisti.us (Ross Vandegrift) Date: Thu, 6 Aug 2009 11:26:05 -0400 Subject: DNS hardening, was Re: Dan Kaminsky In-Reply-To: <18285.1249571785@nsa.vix.com> References: <20090805164823.43774.qmail@simone.iecc.com> <4A79CB90.708@mail-abuse.org> <90CEC867-A870-4E45-AFC2-898AD655699E@arbor.net> <4A79F8A3.9040302@mail-abuse.org> <75cb24520908051449n29c53491m90fd021022d9816f@mail.gmail.com> <4A7A0D6C.90808@mail-abuse.org> <75cb24520908051853t6c0f05d3l94c404d3227d191c@mail.gmail.com> <75cb24520908060718t4a126852mda34fe2de0f92626@mail.gmail.com> <18285.1249571785@nsa.vix.com> Message-ID: <20090806152605.GA24420@kallisti.us> On Thu, Aug 06, 2009 at 03:16:25PM +0000, Paul Vixie wrote: > > ...: "Do loadbalancers, or loadbalanced deployments, deal with this > > properly?" (loadbalancers like F5, citrix, radware, cisco, etc...) > > as far as i know, no loadbalancer understands SCTP today. if they can be > made to pass SCTP through unmodified and only do their enhanced L4 on UDP > and TCP as they do now, all will be well. if not then a loadbalancer > upgrade or removal will be nec'y for anyone who wants to deploy SCTP. F5 BIG-IP 10.0 has support for load balancing SCTP. I have not tested or implemented it. I do not know what feature parity exists with other protocols. But at least it's documented and supported. -- Ross Vandegrift ross at kallisti.us "If the fight gets hot, the songs get hotter. If the going gets tough, the songs get tougher." --Woody Guthrie From sjk at sleepycatz.com Thu Aug 6 10:29:35 2009 From: sjk at sleepycatz.com (sjk) Date: Thu, 06 Aug 2009 10:29:35 -0500 Subject: DOS in progress ? In-Reply-To: <202705b0908060825y55b775aew9a3601fae77f9207@mail.gmail.com> References: <202705b0908060825y55b775aew9a3601fae77f9207@mail.gmail.com> Message-ID: <4A7AF6DF.6020806@sleepycatz.com> We are presently seeing some weird FB behavior -- timeouts and retry issues. We've had several reports from our users and just began investigating. Any info you have would be appreciated. --sjk Jorge Amodio wrote: > Are folks seeing any major DOS in progress ? > > Twitter seems to be under one and FB is flaky. > From chris at uplogon.com Thu Aug 6 10:31:05 2009 From: chris at uplogon.com (Chris Gotstein) Date: Thu, 06 Aug 2009 10:31:05 -0500 Subject: DOS in progress ? In-Reply-To: <202705b0908060825y55b775aew9a3601fae77f9207@mail.gmail.com> References: <202705b0908060825y55b775aew9a3601fae77f9207@mail.gmail.com> Message-ID: <4A7AF739.5040908@uplogon.com> Seeing the same thing. Can't bring up either sites. Jorge Amodio wrote: > Are folks seeing any major DOS in progress ? > > Twitter seems to be under one and FB is flaky. > From ge at linuxbox.org Thu Aug 6 10:30:00 2009 From: ge at linuxbox.org (Gadi Evron) Date: Thu, 06 Aug 2009 18:30:00 +0300 Subject: DOS in progress ? In-Reply-To: <202705b0908060825y55b775aew9a3601fae77f9207@mail.gmail.com> References: <202705b0908060825y55b775aew9a3601fae77f9207@mail.gmail.com> Message-ID: <4A7AF6F8.1010202@linuxbox.org> Jorge Amodio wrote: > Are folks seeing any major DOS in progress ? > > Twitter seems to be under one and FB is flaky. > DDoS happens hundreds of times a day. Twitter and the Internet operations security community will likely take care of it, especially as it's twitter and we all have a warm fuzzy feeling inside. Off topic, I found it hilarious how all the tweets came back to facebook and set statuses about twitter. :o) Gadi. -- Gadi Evron, ge at linuxbox.org. Blog: http://gevron.livejournal.com/ From andyring at inebraska.com Thu Aug 6 10:36:53 2009 From: andyring at inebraska.com (Andy Ringsmuth) Date: Thu, 6 Aug 2009 10:36:53 -0500 Subject: DOS in progress ? In-Reply-To: <4A7AF6DF.6020806@sleepycatz.com> References: <202705b0908060825y55b775aew9a3601fae77f9207@mail.gmail.com> <4A7AF6DF.6020806@sleepycatz.com> Message-ID: <479A72AC-7408-4FD9-A838-9AC884DFF9C3@inebraska.com> Same thing for me here in Lincoln, Neb. I was having issues like this starting Thursday evening about 8 p.m. or so, and it has continued all morning. And of course with Facebook being so vital to my job.... :) I can't pin down specifics, just that it feels "flaky" I guess. Timeouts, retries, photo tagging working intermittently, and so on. -Andy Ringsmuth On Aug 6, 2009, at 10:29 AM, sjk wrote: > We are presently seeing some weird FB behavior -- timeouts and retry > issues. We've had several reports from our users and just began > investigating. Any info you have would be appreciated. > > --sjk > > Jorge Amodio wrote: >> Are folks seeing any major DOS in progress ? >> >> Twitter seems to be under one and FB is flaky. >> > From kizmet at kizmet.id.au Thu Aug 6 10:41:37 2009 From: kizmet at kizmet.id.au (Cody Appleby) Date: Fri, 7 Aug 2009 01:41:37 +1000 Subject: DOS in progress ? In-Reply-To: <479A72AC-7408-4FD9-A838-9AC884DFF9C3@inebraska.com> References: <202705b0908060825y55b775aew9a3601fae77f9207@mail.gmail.com> <4A7AF6DF.6020806@sleepycatz.com> <479A72AC-7408-4FD9-A838-9AC884DFF9C3@inebraska.com> Message-ID: Ditto from Canberra, Australia FB very flakey, same as Andy I guess. Thanks, Cody Appleby On 07/08/2009, at 1:36 AM, Andy Ringsmuth wrote: > Same thing for me here in Lincoln, Neb. I was having issues like > this starting Thursday evening about 8 p.m. or so, and it has > continued all morning. > > And of course with Facebook being so vital to my job.... :) > > I can't pin down specifics, just that it feels "flaky" I guess. > Timeouts, retries, photo tagging working intermittently, and so on. > > > -Andy Ringsmuth > > On Aug 6, 2009, at 10:29 AM, sjk wrote: > >> We are presently seeing some weird FB behavior -- timeouts and retry >> issues. We've had several reports from our users and just began >> investigating. Any info you have would be appreciated. >> >> --sjk >> >> Jorge Amodio wrote: >>> Are folks seeing any major DOS in progress ? >>> >>> Twitter seems to be under one and FB is flaky. >>> >> > > From morrowc.lists at gmail.com Thu Aug 6 10:44:43 2009 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Thu, 6 Aug 2009 11:44:43 -0400 Subject: DNS hardening, was Re: Dan Kaminsky In-Reply-To: <18285.1249571785@nsa.vix.com> References: <20090805164823.43774.qmail@simone.iecc.com> <4A79CB90.708@mail-abuse.org> <90CEC867-A870-4E45-AFC2-898AD655699E@arbor.net> <4A79F8A3.9040302@mail-abuse.org> <75cb24520908051449n29c53491m90fd021022d9816f@mail.gmail.com> <4A7A0D6C.90808@mail-abuse.org> <75cb24520908051853t6c0f05d3l94c404d3227d191c@mail.gmail.com> <75cb24520908060718t4a126852mda34fe2de0f92626@mail.gmail.com> <18285.1249571785@nsa.vix.com> Message-ID: <75cb24520908060844m1d87d34fr7075d9d25cb4c55f@mail.gmail.com> On Thu, Aug 6, 2009 at 11:16 AM, Paul Vixie wrote: > note, i went off-topic in my previous note, and i'll be answering florian > on namedroppers@ since it's not operational. ?chris's note was operational: > >> Date: Thu, 6 Aug 2009 10:18:11 -0400 >> From: Christopher Morrow >> >> awesome, how does that work with devices in the f-root-anycast design? >> (both local hosts in the rack and if I flip from rack to rack) If I send >> along a request to a host which I do not have an association created do I >> get a failure and then re-setup? (inducing further latency) > > yes. ?so, association setup cost will occur once per route-change event. > note that the f-root-anycast design already hashes by flow within a rack pulling something I didn't previously understand from an ongoing discussion on the LISP/v6ops mailing lists... most routers today only hash on tcp/udp so.. sctp isn't going to hash in the same 'deterministic' manner, or someone should probably test that that is the case. > to keep TCP from failing, so the only route-change events of interest to > this point are in wide area BGP. right, and the (I think K-root) K-root folks had a study showing <1% of sessions seemed to be failing in this manner? (nanog in Toronto I think?) >> ...: "Do loadbalancers, or loadbalanced deployments, deal with this >> properly?" (loadbalancers like F5, citrix, radware, cisco, etc...) > > as far as i know, no loadbalancer understands SCTP today. ?if they can be > made to pass SCTP through unmodified and only do their enhanced L4 on UDP > and TCP as they do now, all will be well. ?if not then a loadbalancer > upgrade or removal will be nec'y for anyone who wants to deploy SCTP. > > it's interesting to me that existing deployments of L4-aware packet level > devices can form a barrier to new kinds of L4. ?it's as if the internet is > really just the web, and our networks are TCP/UDP networks not IP networks. sadly, people have (and continue) to make simplifying assumptions while designing/deploying equipment. -Chris From rachael.holt at gmail.com Thu Aug 6 10:46:27 2009 From: rachael.holt at gmail.com (Rachael Holt) Date: Thu, 6 Aug 2009 16:46:27 +0100 Subject: DOS in progress ? In-Reply-To: References: <202705b0908060825y55b775aew9a3601fae77f9207@mail.gmail.com> <4A7AF6DF.6020806@sleepycatz.com> <479A72AC-7408-4FD9-A838-9AC884DFF9C3@inebraska.com> Message-ID: <844dfba0908060846k5e4c7a3dic68ecad06a92ad53@mail.gmail.com> Facebook is being really flaky here in Ireland too. http://www.irishtimes.com/newspaper/breaking/2009/0806/breaking53.htm (about Twitter) 2009/8/6 Cody Appleby > Ditto from Canberra, Australia > FB very flakey, same as Andy I guess. > > Thanks, > Cody Appleby > > > On 07/08/2009, at 1:36 AM, Andy Ringsmuth wrote: > > Same thing for me here in Lincoln, Neb. I was having issues like this >> starting Thursday evening about 8 p.m. or so, and it has continued all >> morning. >> >> And of course with Facebook being so vital to my job.... :) >> >> I can't pin down specifics, just that it feels "flaky" I guess. Timeouts, >> retries, photo tagging working intermittently, and so on. >> >> >> -Andy Ringsmuth >> >> On Aug 6, 2009, at 10:29 AM, sjk wrote: >> >> We are presently seeing some weird FB behavior -- timeouts and retry >>> issues. We've had several reports from our users and just began >>> investigating. Any info you have would be appreciated. >>> >>> --sjk >>> >>> Jorge Amodio wrote: >>> >>>> Are folks seeing any major DOS in progress ? >>>> >>>> Twitter seems to be under one and FB is flaky. >>>> >>>> >>> >> >> > > From ken.gilmour at gmail.com Thu Aug 6 10:56:50 2009 From: ken.gilmour at gmail.com (Ken Gilmour) Date: Thu, 6 Aug 2009 09:56:50 -0600 Subject: DOS in progress ? In-Reply-To: <202705b0908060825y55b775aew9a3601fae77f9207@mail.gmail.com> References: <202705b0908060825y55b775aew9a3601fae77f9207@mail.gmail.com> Message-ID: <5b6f80200908060856w55470177t3a7acbdbb4c4218b@mail.gmail.com> Down from Costa Rica and Ireland too... Interesting that they are starting to go for Social Networking sites now. Have they given up on online gambling sites now? It appears as though they haven't been actively attacking gambling sites for several days... 2009/8/6 Jorge Amodio : > Are folks seeing any major DOS in progress ? > > Twitter seems to be under one and FB is flaky. > > From tme at americafree.tv Thu Aug 6 10:57:16 2009 From: tme at americafree.tv (Marshall Eubanks) Date: Thu, 6 Aug 2009 11:57:16 -0400 Subject: DOS in progress ? In-Reply-To: <202705b0908060825y55b775aew9a3601fae77f9207@mail.gmail.com> References: <202705b0908060825y55b775aew9a3601fae77f9207@mail.gmail.com> Message-ID: On Aug 6, 2009, at 11:25 AM, Jorge Amodio wrote: > Are folks seeing any major DOS in progress ? > > Twitter seems to be under one and FB is flaky. > > Twitter is very flaky & slow to load today, but that is hardly unusual. Do you have any other evidence ? Regards Marshall From chris at uplogon.com Thu Aug 6 10:59:35 2009 From: chris at uplogon.com (Chris Gotstein) Date: Thu, 06 Aug 2009 10:59:35 -0500 Subject: DOS in progress ? In-Reply-To: <5b6f80200908060856w55470177t3a7acbdbb4c4218b@mail.gmail.com> References: <202705b0908060825y55b775aew9a3601fae77f9207@mail.gmail.com> <5b6f80200908060856w55470177t3a7acbdbb4c4218b@mail.gmail.com> Message-ID: <4A7AFDE7.4060908@uplogon.com> check out: http://status.twitter.com/ Tells the story. Chris Gotstein Sr Network Engineer UP Logon/Computer Connection UP 500 N Stephenson Ave Iron Mountain, MI 49801 Phone: 906-774-4847 Fax: 906-774-0335 chris at uplogon.com Ken Gilmour wrote: > Down from Costa Rica and Ireland too... Interesting that they are > starting to go for Social Networking sites now. Have they given up on > online gambling sites now? It appears as though they haven't been > actively attacking gambling sites for several days... > > 2009/8/6 Jorge Amodio : >> Are folks seeing any major DOS in progress ? >> >> Twitter seems to be under one and FB is flaky. >> >> > From dhubbard at dino.hostasaurus.com Thu Aug 6 11:02:06 2009 From: dhubbard at dino.hostasaurus.com (David Hubbard) Date: Thu, 6 Aug 2009 12:02:06 -0400 Subject: DOS in progress ? Message-ID: From: Marshall Eubanks [mailto:tme at americafree.tv] > > Twitter is very flaky & slow to load today, but that is > hardly unusual. > > Do you have any other evidence ? > http://www.cnn.com/2009/TECH/08/06/twitter.attack/index.html From bradley.freeman at csirt.ja.net Thu Aug 6 11:02:01 2009 From: bradley.freeman at csirt.ja.net (Bradley Freeman) Date: Thu, 6 Aug 2009 17:02:01 +0100 Subject: DOS in progress ? In-Reply-To: References: <202705b0908060825y55b775aew9a3601fae77f9207@mail.gmail.com> Message-ID: <010701ca16af$3c508c00$b4f1a400$@freeman@csirt.ja.net> http://status.twitter.com/ "We are defending against a denial-of-service attack, and will update status again shortly." -----Original Message----- From: Marshall Eubanks [mailto:tme at americafree.tv] Sent: 06 August 2009 16:57 To: Jorge Amodio Cc: NANOG Subject: Re: DOS in progress ? On Aug 6, 2009, at 11:25 AM, Jorge Amodio wrote: > Are folks seeing any major DOS in progress ? > > Twitter seems to be under one and FB is flaky. > > Twitter is very flaky & slow to load today, but that is hardly unusual. Do you have any other evidence ? Regards Marshall From jmamodio at gmail.com Thu Aug 6 11:05:09 2009 From: jmamodio at gmail.com (Jorge Amodio) Date: Thu, 6 Aug 2009 11:05:09 -0500 Subject: DOS in progress ? In-Reply-To: <2415784765506713458@unknownmsgid> References: <202705b0908060825y55b775aew9a3601fae77f9207@mail.gmail.com> <2415784765506713458@unknownmsgid> Message-ID: <202705b0908060905lba66934uc87f1b092750fa62@mail.gmail.com> > http://status.twitter.com/ > > "We are defending against a denial-of-service attack, and will update status > again shortly." Perhaps the "puddy tat" finally got the bird :-) From darren.t.thurston at gmail.com Thu Aug 6 11:02:58 2009 From: darren.t.thurston at gmail.com (Darren) Date: Thu, 6 Aug 2009 09:02:58 -0700 Subject: DOS in progress ? In-Reply-To: References: <202705b0908060825y55b775aew9a3601fae77f9207@mail.gmail.com> Message-ID: http://status.twitter.com/ Ongoing denial-of-service attack 1 hour ago We are defending against a denial-of-service attack, and will update status again shortly. *Update*: the site is back up, but we are continuing to defend against and recover from this attack. On Thu, Aug 6, 2009 at 8:57 AM, Marshall Eubanks wrote: > > On Aug 6, 2009, at 11:25 AM, Jorge Amodio wrote: > > Are folks seeing any major DOS in progress ? >> >> Twitter seems to be under one and FB is flaky. >> >> >> > Twitter is very flaky & slow to load today, but that is hardly unusual. > > Do you have any other evidence ? > > Regards > Marshall > From jmamodio at gmail.com Thu Aug 6 11:12:23 2009 From: jmamodio at gmail.com (Jorge Amodio) Date: Thu, 6 Aug 2009 11:12:23 -0500 Subject: DOS in progress ? In-Reply-To: <2415784765506713458@unknownmsgid> References: <202705b0908060825y55b775aew9a3601fae77f9207@mail.gmail.com> <2415784765506713458@unknownmsgid> Message-ID: <202705b0908060912p69d2749uee81e255333a0256@mail.gmail.com> > "We are defending against a denial-of-service attack, and will update status > again shortly." Could be interesting if folks @Twitter take pictures or better video about how are they defending against the attack. Do they wear special helmets and cyber pitchforks ? From Valdis.Kletnieks at vt.edu Thu Aug 6 11:44:05 2009 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Thu, 06 Aug 2009 12:44:05 -0400 Subject: DOS in progress ? In-Reply-To: Your message of "Thu, 06 Aug 2009 11:12:23 CDT." <202705b0908060912p69d2749uee81e255333a0256@mail.gmail.com> References: <202705b0908060825y55b775aew9a3601fae77f9207@mail.gmail.com> <2415784765506713458@unknownmsgid> <202705b0908060912p69d2749uee81e255333a0256@mail.gmail.com> Message-ID: <75203.1249577045@turing-police.cc.vt.edu> On Thu, 06 Aug 2009 11:12:23 CDT, Jorge Amodio said: > > "We are defending against a denial-of-service attack, and will update status > > again shortly." > > Could be interesting if folks @Twitter take pictures or better video about how > are they defending against the attack. > > Do they wear special helmets and cyber pitchforks ? Blow up a fail-whale and let the falling chunks of blubber do the work. There's even good instructional videos on the net on how to deploy this. ;) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 226 bytes Desc: not available URL: From jmamodio at gmail.com Thu Aug 6 11:51:43 2009 From: jmamodio at gmail.com (Jorge Amodio) Date: Thu, 6 Aug 2009 11:51:43 -0500 Subject: DOS in progress ? In-Reply-To: <75203.1249577045@turing-police.cc.vt.edu> References: <202705b0908060825y55b775aew9a3601fae77f9207@mail.gmail.com> <2415784765506713458@unknownmsgid> <202705b0908060912p69d2749uee81e255333a0256@mail.gmail.com> <75203.1249577045@turing-police.cc.vt.edu> Message-ID: <202705b0908060951l696ee403of7bb700473f61ca7@mail.gmail.com> FB flakyness could be related to timeout with Twitter APIs Just reported by the birdhouse: "As we recover, users will experience some longer load times and slowness. This includes timeouts to API clients. We?re working to get back to 100% as quickly as we can." From bobbyjim at gmail.com Thu Aug 6 13:34:38 2009 From: bobbyjim at gmail.com (Bobby Mac) Date: Thu, 6 Aug 2009 13:34:38 -0500 Subject: Conclusion: Smart hands in NYC area and new: Tokyo In-Reply-To: <20090806100752.GL43104@ronin.4ever.de> References: <20090806100752.GL43104@ronin.4ever.de> Message-ID: Semi-on topic: In 2005 I was working with NTTcom on creating a new webhosting offering. NTT was going to move 16 FULL racks of net and server gear from the lab, to the next floor which was the actual datacenter. This required (due to weight and space issues) that every server/net device had to be unracked and uncabled. The crew doing physical move also did the break down of everything. I inquired about the down time to the lab and how long the move would take. I was told that it would take about 8 hours. I was extremely pessimistic that this would happen and voiced my concern. The lead server admin reassured me that everything would be perfect and that there would be no issues. To prove the point, he place a screw on top of one of the servers and stated "This will be in the same place tomorrow but in the data center". The move was 99.99% successful. The exception was that some one plugged fiber into the wrong port on a DB server but the aformentioned screw was in the same place on the server. Absolutely AMAZING! I'll track down which company provided the service. -Robert On Thu, Aug 6, 2009 at 5:07 AM, Elmar K. Bins wrote: > Hello altogether, > > I got a couple of freelancers and a few tips which companies > to use. I thought I'd at least share the company recommendations, > of which I'll have the bosses pick. > > One other thing - I'll be needing the same thing in Tokyo by the > end of the year. If anyone has recommendations, please don't hesitate. > I'm not shy of travelling, but I'd rather save time and money there... > > Yours, > Elmar. > > > Recommended companies: > > Team Silverback (www.teamsilverback.com) > OnForce (www.onforce.com) > Endeavor > Xeta > Blackbox > Ledcor (www.ltscompany.com) > > > > From cblecker at peer1.com Thu Aug 6 16:29:24 2009 From: cblecker at peer1.com (Christoph Blecker) Date: Thu, 06 Aug 2009 14:29:24 -0700 Subject: DOS in progress ? In-Reply-To: <202705b0908060951l696ee403of7bb700473f61ca7@mail.gmail.com> References: <202705b0908060825y55b775aew9a3601fae77f9207@mail.gmail.com> <2415784765506713458@unknownmsgid> <202705b0908060912p69d2749uee81e255333a0256@mail.gmail.com> <75203.1249577045@turing-police.cc.vt.edu> <202705b0908060951l696ee403of7bb700473f61ca7@mail.gmail.com> Message-ID: <4A7B4B34.9030808@peer1.com> It looks like there is something more widespread today. I've noticed a couple other sites having issues. LiveJournal has confirmed they are under attack as well: http://community.livejournal.com/lj_maintenance/125027.html Cheers, -Christoph Jorge Amodio wrote: > FB flakyness could be related to timeout with Twitter APIs > > Just reported by the birdhouse: > > "As we recover, users will experience some longer load times and > slowness. This includes timeouts to API clients. We?re working to get > back to 100% as quickly as we can." > From tme at americafree.tv Thu Aug 6 19:20:21 2009 From: tme at americafree.tv (Marshall Eubanks) Date: Thu, 6 Aug 2009 20:20:21 -0400 Subject: DOS in progress ? In-Reply-To: <4A7B4B34.9030808@peer1.com> References: <202705b0908060825y55b775aew9a3601fae77f9207@mail.gmail.com> <2415784765506713458@unknownmsgid> <202705b0908060912p69d2749uee81e255333a0256@mail.gmail.com> <75203.1249577045@turing-police.cc.vt.edu> <202705b0908060951l696ee403of7bb700473f61ca7@mail.gmail.com> <4A7B4B34.9030808@peer1.com> Message-ID: On Aug 6, 2009, at 5:29 PM, Christoph Blecker wrote: > It looks like there is something more widespread today. I've noticed a > couple other sites having issues. LiveJournal has confirmed they are > under attack as well: > http://community.livejournal.com/lj_maintenance/125027.html > This is interesting. http://www.nytimes.com/2009/08/07/technology/internet/07twitter.html Most computer security analysts did not cite a specific source of the attack Thursday. But Bill Woodcock, a research director of the Packet Clearing House, a nonprofit technical organization that tracks Internet traffic, said Thursday?s attack was an extension of the conflict between Russia and Georgia. It was not clear who initiated the attack, he said, but likely ?one side put up propaganda, the other side figured this out and is attacking them.? Instead of using a botnet, or a network of thousands of malware- infected personal computers to flood a site with traffic, Mr. Woodcock said this particular attack consisted of a wave of spam e-mail messages, which began infiltrating Twitter and other sites at 10:25 a.m. Eastern time. ?It?s a vast increase in traffic that creates the denial-of-service,? he said. YouTube and LiveJournal were also affected, Mr. Woodcock said, although ?Twitter was definitely hit the hardest.? YouTube said it had not noticed any problems with its service. ----------------- While I certainly trust PCH, I would be curious as to the evidence for this. Regards Marshall > Cheers, > -Christoph > > Jorge Amodio wrote: >> FB flakyness could be related to timeout with Twitter APIs >> >> Just reported by the birdhouse: >> >> "As we recover, users will experience some longer load times and >> slowness. This includes timeouts to API clients. We?re working to get >> back to 100% as quickly as we can." >> > > From woody at pch.net Thu Aug 6 21:26:06 2009 From: woody at pch.net (Bill Woodcock) Date: Thu, 6 Aug 2009 19:26:06 -0700 (PDT) Subject: DOS in progress ? In-Reply-To: References: <202705b0908060825y55b775aew9a3601fae77f9207@mail.gmail.com> <2415784765506713458@unknownmsgid> <202705b0908060912p69d2749uee81e255333a0256@mail.gmail.com> <75203.1249577045@turing-police.cc.vt.edu> <202705b0908060951l696ee403of7bb700473f61ca7@mail.gmail.com> <4A7B4B34.9030808@peer1.com> Message-ID: On Thu, 6 Aug 2009, Marshall Eubanks wrote: > http://www.nytimes.com/2009/08/07/technology/internet/07twitter.html > Mr. Woodcock said this > particular attack consisted of a wave of spam e-mail messages, which began > infiltrating Twitter Uh... Yes, well, the gist of my explanation of how joe-jobs work may have eluded the reporter, but the point I was trying to get across was that I was aware of a joe-job, but not aware of a botnet. > While I certainly trust PCH, I would be curious as to the evidence for > this. Google "cyxymu" and you should begin to see copies of the joe-job spam, as well as the earlier and archived postings this guy has made in the past. These URLs may be of interest, if you're really curious about the politics behind the attack: http://www.alertnet.org/db/blogs/29542/b5f1ff2ebdb92dabafda4b44e960db4c.htm http://en.wikipedia.org/wiki/Abkhazia Note that this is a deeply-layered conflict, with both sides trying to pass off actions as those of the other, and I don't know of anyone who's asserted that they have any means of determining whether this was a Georgian attack on an Abkhazian blogger, or a Russian or Abkhazian faux-martyring of an Abkhazian blogger that few people cared about yesterday, but who will have his seven minutes of fame in tomorrow's press. I don't have an opinion on the matter, and I don't think many in our community will probably take any interest in the underlying politics. What matters is that smart people in our community at Google and SixApart and Twitter communicated and coordinated quickly and effectively, and established a lot of connections that will serve them well in responding to things of this sort again in the future. INOC-DBA and NSP-Sec and the Anti-Spam list all got a workout today, and they all functioned exactly as they were intended to. -Bill From jmcmasters at atlanticbb.net Thu Aug 6 21:33:34 2009 From: jmcmasters at atlanticbb.net (jmcmasters at atlanticbb.net) Date: Thu, 06 Aug 2009 22:33:34 -0400 Subject: Huawei optical transport Message-ID: Everyone, I was curious if anyone has used Huawei Optical transport. We are looking at OptiX OSN 6800A to upgrade our backbone to 10G. Pro's and Con's would be great if anyone has used the platform. Thanks, Jeremy From tme at americafree.tv Thu Aug 6 23:06:16 2009 From: tme at americafree.tv (Marshall Eubanks) Date: Fri, 7 Aug 2009 00:06:16 -0400 Subject: DOS in progress ? In-Reply-To: References: <202705b0908060825y55b775aew9a3601fae77f9207@mail.gmail.com> <2415784765506713458@unknownmsgid> <202705b0908060912p69d2749uee81e255333a0256@mail.gmail.com> <75203.1249577045@turing-police.cc.vt.edu> <202705b0908060951l696ee403of7bb700473f61ca7@mail.gmail.com> <4A7B4B34.9030808@peer1.com> Message-ID: <4414DA77-DAEA-4AEE-92F8-D04282CFBE75@americafree.tv> On Aug 6, 2009, at 10:26 PM, Bill Woodcock wrote: > On Thu, 6 Aug 2009, Marshall Eubanks wrote: >> http://www.nytimes.com/2009/08/07/technology/internet/07twitter.html > >> Mr. Woodcock said this >> particular attack consisted of a wave of spam e-mail messages, >> which began >> infiltrating Twitter > > Uh... Yes, well, the gist of my explanation of how joe-jobs work > may have > eluded the reporter, but the point I was trying to get across was > that I > was aware of a joe-job, but not aware of a botnet. > Pity he just couldn't have used the phrase. It would have cleared it up some for me at least. >> While I certainly trust PCH, I would be curious as to the evidence >> for >> this. > > Google "cyxymu" and you should begin to see copies of the joe-job > spam, as > well as the earlier and archived postings this guy has made in the > past. > > These URLs may be of interest, if you're really curious about the > politics > behind the attack: > > http://www.alertnet.org/db/blogs/29542/b5f1ff2ebdb92dabafda4b44e960db4c.htm > > http://en.wikipedia.org/wiki/Abkhazia > > > Note that this is a deeply-layered conflict, with both sides trying to > pass off actions as those of the other, and I don't know of anyone > who's > asserted that they have any means of determining whether this was a > Georgian attack on an Abkhazian blogger, or a Russian or Abkhazian > faux-martyring of an Abkhazian blogger that few people cared about > yesterday, but who will have his seven minutes of fame in tomorrow's > press. > Given that the start of major hostilities there was 1 year ago today (the Georgian bombing and attack on Tskhinvali) and the war continued for 6 more days (until August 12th) I would not be surprised if there was more mischief in store. Let's hope this doesn't become a tradition. Thank you for the information. Regards Marshall > I don't have an opinion on the matter, and I don't think many in our > community will probably take any interest in the underlying politics. > What matters is that smart people in our community at Google and > SixApart > and Twitter communicated and coordinated quickly and effectively, and > established a lot of connections that will serve them well in > responding > to things of this sort again in the future. INOC-DBA and NSP-Sec > and the > Anti-Spam list all got a workout today, and they all functioned > exactly as > they were intended to. > > -Bill > > From woody at pch.net Thu Aug 6 23:21:44 2009 From: woody at pch.net (Bill Woodcock) Date: Thu, 6 Aug 2009 21:21:44 -0700 (PDT) Subject: DOS in progress ? In-Reply-To: References: <202705b0908060825y55b775aew9a3601fae77f9207@mail.gmail.com> <2415784765506713458@unknownmsgid> <202705b0908060912p69d2749uee81e255333a0256@mail.gmail.com> <75203.1249577045@turing-police.cc.vt.edu> <202705b0908060951l696ee403of7bb700473f61ca7@mail.gmail.com> <4A7B4B34.9030808@peer1.com> Message-ID: On Thu, 6 Aug 2009, Bill Woodcock wrote: > Note that this is a deeply-layered conflict, with both sides trying to > pass off actions as those of the other, and I don't know of anyone who's > asserted that they have any means of determining whether this was a > Georgian attack on an Abkhazian blogger... Sorry, meant to say _Abkhazian_ attack on a _Georgian_ blogger... See what I mean? I can't tell the players without a scorecard. And I always seem to reply too quickly, when I reply to NANOG. Nonetheless: > What matters is that smart people in our community at Google and SixApart > and Twitter communicated and coordinated quickly and effectively... etc. -Bill From jacques at siberia.co.za Fri Aug 7 02:35:28 2009 From: jacques at siberia.co.za (Jacques Marneweck) Date: Fri, 7 Aug 2009 09:35:28 +0200 Subject: Bebo contact Message-ID: Good morning, I'm looking for a person who works at Bebo to talk to about and abuse issue that Bebo support is clearly incapable of resolving without me registering for an account on their site. Can someone please contact me off list to get this abuse issue resolved? Regards --jm From morrowc.lists at gmail.com Fri Aug 7 08:53:58 2009 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Fri, 7 Aug 2009 09:53:58 -0400 Subject: 60 hudson and snorkels Message-ID: <75cb24520908070653t3507f3fetecf41aef01a103b7@mail.gmail.com> Going to be a long weekend: break out the scuba gear... From andrewy at webair.com Fri Aug 7 08:57:11 2009 From: andrewy at webair.com (andrew young) Date: Fri, 07 Aug 2009 09:57:11 -0400 Subject: 60 hudson and snorkels In-Reply-To: <75cb24520908070653t3507f3fetecf41aef01a103b7@mail.gmail.com> References: <75cb24520908070653t3507f3fetecf41aef01a103b7@mail.gmail.com> Message-ID: <4A7C32B7.9000208@webair.com> I just walked by 60H this morning and the roads are blocked off but the water is all gone. Cant speak for the basement, that place must be a mess right now. Christopher Morrow wrote: > Going to be a long weekend: > > > > break out the scuba gear... -- ---------------------------------------- Andrew Young Webair Internet Development, Inc. Phone: 1 866 WEBAIR 1 x143 http://www.webair.com Shift hours: Tues-Friday 12PM-8PM, Sat 9AM-5PM From andrewy at webair.com Fri Aug 7 09:54:07 2009 From: andrewy at webair.com (andrew young) Date: Fri, 07 Aug 2009 10:54:07 -0400 Subject: 60 hudson and snorkels In-Reply-To: <75cb24520908070653t3507f3fetecf41aef01a103b7@mail.gmail.com> References: <75cb24520908070653t3507f3fetecf41aef01a103b7@mail.gmail.com> Message-ID: <4A7C400F.4060800@webair.com> some video of it: http://abclocal.go.com/wabc/story?section=news/local&id=6953138 Christopher Morrow wrote: > Going to be a long weekend: > > > > break out the scuba gear... -- ---------------------------------------- Andrew Young Webair Internet Development, Inc. Phone: 1 866 WEBAIR 1 x143 http://www.webair.com Shift hours: Tues-Friday 12PM-8PM, Sat 9AM-5PM From bananas21ca at gmail.com Fri Aug 7 11:58:54 2009 From: bananas21ca at gmail.com (Brandon Bezaire) Date: Fri, 7 Aug 2009 12:58:54 -0400 Subject: Bebo contact In-Reply-To: References: Message-ID: Have you tried any of the contacts from the sites whois info? They may be able to pass it onto support. On Fri, Aug 7, 2009 at 3:35 AM, Jacques Marneweck wrote: > Good morning, > > I'm looking for a person who works at Bebo to talk to about and abuse issue > that Bebo support is clearly incapable of resolving without me registering > for an account on their site. Can someone please contact me off list to get > this abuse issue resolved? > > Regards > --jm > > From mike-nanog at tiedyenetworks.com Fri Aug 7 12:16:06 2009 From: mike-nanog at tiedyenetworks.com (mike) Date: Fri, 07 Aug 2009 10:16:06 -0700 Subject: pseudowire over ip/mpls Message-ID: <4A7C6156.5030609@tiedyenetworks.com> Does anyone here have good operational experience with pseudowire (t1 and ds3) carried over ip/mpls? I'm just interested in real world experiences and deployment scenarios that have went live. Mike- From cscora at apnic.net Fri Aug 7 13:13:01 2009 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 8 Aug 2009 04:13:01 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <200908071813.n77ID1bX007948@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 08 Aug, 2009 Report Website: http://thyme.apnic.net Detailed Analysis: http://thyme.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 293130 Prefixes after maximum aggregation: 138725 Deaggregation factor: 2.11 Unique aggregates announced to Internet: 145858 Total ASes present in the Internet Routing Table: 31891 Prefixes per ASN: 9.19 Origin-only ASes present in the Internet Routing Table: 27728 Origin ASes announcing only one prefix: 13529 Transit ASes present in the Internet Routing Table: 4163 Transit-only ASes present in the Internet Routing Table: 99 Average AS path length visible in the Internet Routing Table: 3.6 Max AS path length visible: 24 Max AS path prepend of ASN (12026) 22 Prefixes from unregistered ASNs in the Routing Table: 465 Unregistered ASNs in the Routing Table: 127 Number of 32-bit ASNs allocated by the RIRs: 231 Prefixes from 32-bit ASNs in the Routing Table: 84 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 337 Number of addresses announced to Internet: 2103732416 Equivalent to 125 /8s, 100 /16s and 104 /24s Percentage of available address space announced: 56.8 Percentage of allocated address space announced: 65.0 Percentage of available address space allocated: 87.3 Percentage of address space in use by end-sites: 78.5 Total number of prefixes smaller than registry allocations: 140470 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 69643 Total APNIC prefixes after maximum aggregation: 24862 APNIC Deaggregation factor: 2.80 Prefixes being announced from the APNIC address blocks: 69053 Unique aggregates announced from the APNIC address blocks: 31672 APNIC Region origin ASes present in the Internet Routing Table: 3729 APNIC Prefixes per ASN: 18.52 APNIC Region origin ASes announcing only one prefix: 1025 APNIC Region transit ASes present in the Internet Routing Table: 580 Average APNIC Region AS path length visible: 3.6 Max APNIC Region AS path length visible: 16 Number of APNIC addresses announced to Internet: 479781312 Equivalent to 28 /8s, 152 /16s and 225 /24s Percentage of available APNIC address space announced: 84.1 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, 175/8, 180/8, 182/8, 183/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 124787 Total ARIN prefixes after maximum aggregation: 66281 ARIN Deaggregation factor: 1.88 Prefixes being announced from the ARIN address blocks: 125453 Unique aggregates announced from the ARIN address blocks: 52489 ARIN Region origin ASes present in the Internet Routing Table: 13145 ARIN Prefixes per ASN: 9.54 ARIN Region origin ASes announcing only one prefix: 5068 ARIN Region transit ASes present in the Internet Routing Table: 1284 Average ARIN Region AS path length visible: 3.3 Max ARIN Region AS path length visible: 24 Number of ARIN addresses announced to Internet: 1029397568 Equivalent to 61 /8s, 91 /16s and 92 /24s Percentage of available ARIN address space announced: 90.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 3/8, 4/8, 6/8, 7/8, 8/8, 9/8, 11/8, 12/8, 13/8, 15/8, 16/8, 17/8, 18/8, 19/8, 20/8, 21/8, 22/8, 24/8, 26/8, 28/8, 29/8, 30/8, 32/8, 33/8, 34/8, 35/8, 38/8, 40/8, 44/8, 45/8, 47/8, 48/8, 52/8, 54/8, 55/8, 56/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8, 98/8, 99/8, 108/8, 173/8, 174/8, 184/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 214/8, 215/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 67221 Total RIPE prefixes after maximum aggregation: 39687 RIPE Deaggregation factor: 1.69 Prefixes being announced from the RIPE address blocks: 66828 Unique aggregates announced from the RIPE address blocks: 45092 RIPE Region origin ASes present in the Internet Routing Table: 13361 RIPE Prefixes per ASN: 5.00 RIPE Region origin ASes announcing only one prefix: 6984 RIPE Region transit ASes present in the Internet Routing Table: 1988 Average RIPE Region AS path length visible: 4.0 Max RIPE Region AS path length visible: 21 Number of RIPE addresses announced to Internet: 499404992 Equivalent to 29 /8s, 196 /16s and 80 /24s Percentage of available RIPE address space announced: 99.2 RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-52223 RIPE Address Blocks 25/8, 51/8, 62/8, 77/8, 78/8, 79/8, 80/8, 81/8, 82/8, 83/8, 84/8, 85/8, 86/8, 87/8, 88/8, 89/8, 90/8, 91/8, 92/8, 93/8, 94/8, 95/8, 109/8, 178/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 24888 Total LACNIC prefixes after maximum aggregation: 6115 LACNIC Deaggregation factor: 4.07 Prefixes being announced from the LACNIC address blocks: 24849 Unique aggregates announced from the LACNIC address blocks: 13809 LACNIC Region origin ASes present in the Internet Routing Table: 1153 LACNIC Prefixes per ASN: 21.55 LACNIC Region origin ASes announcing only one prefix: 369 LACNIC Region transit ASes present in the Internet Routing Table: 195 Average LACNIC Region AS path length visible: 4.1 Max LACNIC Region AS path length visible: 22 Number of LACNIC addresses announced to Internet: 72975040 Equivalent to 4 /8s, 89 /16s and 130 /24s Percentage of available LACNIC address space announced: 72.5 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: 6194 Total AfriNIC prefixes after maximum aggregation: 1493 AfriNIC Deaggregation factor: 4.15 Prefixes being announced from the AfriNIC address blocks: 6597 Unique aggregates announced from the AfriNIC address blocks: 2519 AfriNIC Region origin ASes present in the Internet Routing Table: 301 AfriNIC Prefixes per ASN: 21.92 AfriNIC Region origin ASes announcing only one prefix: 83 AfriNIC Region transit ASes present in the Internet Routing Table: 62 Average AfriNIC Region AS path length visible: 3.8 Max AfriNIC Region AS path length visible: 16 Number of AfriNIC addresses announced to Internet: 20195584 Equivalent to 1 /8s, 52 /16s and 41 /24s Percentage of available AfriNIC address space announced: 60.2 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 1719 6979 423 Korea Telecom (KIX) 17488 1550 139 102 Hathway IP Over Cable Interne 4755 1231 292 143 TATA Communications formerly 9583 1119 88 550 Sify Limited 4134 983 17997 384 CHINANET-BACKBONE 7545 815 198 103 TPG Internet Pty Ltd 9829 807 619 15 BSNL National Internet Backbo 23577 779 34 661 Korea Telecom (ATM-MPLS) 4808 754 1515 172 CNCGROUP IP network: China169 18101 748 201 31 Reliance Infocom Ltd Internet Complete listing at http://thyme.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 4209 3643 323 bellsouth.net, inc. 4323 1912 1048 384 Time Warner Telecom 1785 1725 714 139 PaeTec Communications, Inc. 7018 1498 5908 1051 AT&T WorldNet Services 20115 1464 1472 672 Charter Communications 6478 1329 274 284 AT&T Worldnet Services 2386 1289 673 939 AT&T Data Communications Serv 3356 1206 10979 439 Level 3 Communications, LLC 11492 1134 208 12 Cable One 22773 1082 2604 66 Cox Communications, Inc. Complete listing at http://thyme.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 30890 482 92 195 Evolva Telecom 12479 472 578 6 Uni2 Autonomous System 3292 461 1905 395 TDC Tele Danmark 702 430 1861 346 UUNET - Commercial IP service 35805 372 40 5 United Telecom of Georgia 9198 366 138 12 Kazakhtelecom Data Network Ad 3320 348 7067 301 Deutsche Telekom AG 3301 347 1684 310 TeliaNet Sweden 3215 344 3081 109 France Telecom Transpac 8866 339 109 20 Bulgarian Telecommunication C 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 1515 2898 245 UniNet S.A. de C.V. 10620 973 220 97 TVCABLE BOGOTA 28573 636 579 40 NET Servicos de Comunicao S.A 7303 617 328 93 Telecom Argentina Stet-France 22047 540 302 14 VTR PUNTO NET S.A. 11830 487 310 65 Instituto Costarricense de El 11172 443 99 69 Servicios Alestra S.A de C.V 6471 421 96 31 ENTEL CHILE S.A. 7738 410 858 29 Telecomunicacoes da Bahia S.A 3816 390 191 80 Empresa Nacional de Telecomun Complete listing at http://thyme.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 8452 1025 188 7 TEDATA 24863 909 90 48 LINKdotNET AS number 20858 324 34 5 EgyNet 3741 277 856 237 The Internet Solution 2018 246 215 143 Tertiary Education Network 6713 175 166 16 Itissalat Al-MAGHRIB 33783 152 10 8 EEPAD TISP TELECOM & INTERNET 29571 144 15 7 Ci Telecom Autonomous system 24835 131 46 9 RAYA Telecom - Egypt 5536 123 8 9 Internet Egypt Network Complete listing at http://thyme.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 4209 3643 323 bellsouth.net, inc. 4323 1912 1048 384 Time Warner Telecom 1785 1725 714 139 PaeTec Communications, Inc. 4766 1719 6979 423 Korea Telecom (KIX) 17488 1550 139 102 Hathway IP Over Cable Interne 8151 1515 2898 245 UniNet S.A. de C.V. 7018 1498 5908 1051 AT&T WorldNet Services 20115 1464 1472 672 Charter Communications 6478 1329 274 284 AT&T Worldnet Services 2386 1289 673 939 AT&T Data Communications Serv Complete listing at http://thyme.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 1785 1725 1586 PaeTec Communications, Inc. 4323 1912 1528 Time Warner Telecom 17488 1550 1448 Hathway IP Over Cable Interne 4766 1719 1296 Korea Telecom (KIX) 8151 1515 1270 UniNet S.A. de C.V. 11492 1134 1122 Cable One 4755 1231 1088 TATA Communications formerly 18566 1062 1052 Covad Communications 6478 1329 1045 AT&T Worldnet Services 8452 1025 1018 TEDATA Complete listing at http://thyme.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 16927 UNALLOCATED 12.0.252.0/23 7018 AT&T WorldNet Servic 15132 UNALLOCATED 12.9.150.0/24 7018 AT&T WorldNet Servic 32567 UNALLOCATED 12.14.170.0/24 7018 AT&T WorldNet Servic 13746 UNALLOCATED 12.24.56.0/24 7018 AT&T WorldNet Servic 32567 UNALLOCATED 12.25.107.0/24 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.152.0/24 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.154.0/23 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.159.0/24 7018 AT&T WorldNet Servic 32326 UNALLOCATED 12.40.49.0/24 7018 AT&T WorldNet Servic 25639 UNALLOCATED 12.41.169.0/24 7018 AT&T WorldNet Servic Complete listing at http://thyme.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 24.38.192.0/18 36377 PATRIOT MEDIA AND COMMUNICATI 24.225.128.0/17 36377 PATRIOT MEDIA AND COMMUNICATI 41.223.92.0/22 36936 >>UNKNOWN<< 41.223.112.0/22 5713 Telkom SA Ltd 41.223.176.0/22 36981 >>UNKNOWN<< 41.223.188.0/24 22351 Intelsat 41.223.189.0/24 26452 Local Communications Networks 62.61.220.0/24 24974 Tachyon Europe BV - Wireless 62.61.221.0/24 24974 Tachyon Europe BV - Wireless 63.131.240.0/20 40414 Optivon, Inc. Complete listing at http://thyme.apnic.net/current/data-add-IANA Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:20 /9:10 /10:24 /11:59 /12:170 /13:350 /14:622 /15:1176 /16:10603 /17:4765 /18:8353 /19:17223 /20:20578 /21:20493 /22:26414 /23:26134 /24:153445 /25:909 /26:1022 /27:577 /28:159 /29:8 /30:7 /31:1 /32:8 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 6389 2733 4209 bellsouth.net, inc. 4766 1404 1719 Korea Telecom (KIX) 17488 1296 1550 Hathway IP Over Cable Interne 1785 1194 1725 PaeTec Communications, Inc. 11492 1060 1134 Cable One 18566 1043 1062 Covad Communications 9583 972 1119 Sify Limited 4323 968 1912 Time Warner Telecom 8452 947 1025 TEDATA 10620 881 973 TVCABLE BOGOTA Complete listing at http://thyme.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 4:14 8:212 12:2135 13:7 15:19 16:3 17:5 20:35 24:1123 32:52 34:2 38:585 40:96 41:1748 43:1 44:2 47:22 52:6 53:2 55:2 56:2 57:24 58:602 59:607 60:463 61:951 62:1110 63:2027 64:3699 65:2403 66:3591 67:1696 68:859 69:2722 70:552 71:152 72:1650 73:2 74:1670 75:176 76:350 77:825 78:568 79:359 80:931 81:849 82:588 83:453 84:642 85:1064 86:372 87:677 88:376 89:1478 90:49 91:2452 92:390 93:1103 94:1180 95:1133 96:166 97:257 98:272 99:28 110:174 111:374 112:124 113:151 114:238 115:286 116:1128 117:559 118:337 119:757 120:148 121:638 122:1233 123:680 124:982 125:1379 128:225 129:223 130:129 131:414 132:74 133:13 134:185 135:43 136:226 137:164 138:167 139:82 140:441 141:123 142:384 143:357 144:359 145:48 146:388 147:153 148:530 149:225 150:206 151:193 152:139 153:148 154:2 155:275 156:167 157:301 158:114 159:343 160:290 161:162 162:272 163:162 164:465 165:520 166:466 167:363 168:700 169:176 170:481 171:41 172:10 173:351 174:274 178:1 180:4 186:115 187:163 188:395 189:576 190:2963 192:5790 193:4257 194:3290 195:2690 196:1120 198:3649 199:3367 200:5099 201:1296 202:7750 203:8263 204:3886 205:2159 206:2446 207:2742 208:3903 209:3519 210:2531 211:1106 212:1655 213:1621 214:82 215:29 216:4530 217:1366 218:405 219:410 220:1107 221:479 222:328 End of report From cidr-report at potaroo.net Fri Aug 7 17:00:03 2009 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 7 Aug 2009 22:00:03 GMT Subject: BGP Update Report Message-ID: <200908072200.n77M03mP004659@wattle.apnic.net> BGP Update Report Interval: 30-Jul-09 -to- 06-Aug-09 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS9198 95250 6.4% 251.3 -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration 2 - AS11 38501 2.6% 2566.7 -- HARVARD - Harvard University 3 - AS8151 36215 2.4% 7.4 -- Uninet S.A. de C.V. 4 - AS33783 25605 1.7% 168.5 -- EEPAD 5 - AS47408 13428 0.9% 610.4 -- MANDARIN-AS Mandarin WIMAX Sicilia SpA 6 - AS8877 10655 0.7% 43.0 -- BOLBG-AS PowerNet Ltd, Sofia, Bulgaria 7 - AS8452 10481 0.7% 10.2 -- TEDATA TEDATA 8 - AS9829 10365 0.7% 12.8 -- BSNL-NIB National Internet Backbone 9 - AS35805 9586 0.6% 22.7 -- UTG-AS United Telecom AS 10 - AS6389 9116 0.6% 2.2 -- BELLSOUTH-NET-BLK - BellSouth.net Inc. 11 - AS4249 8879 0.6% 48.8 -- LILLY-AS - Eli Lilly and Company 12 - AS7018 8028 0.5% 5.2 -- ATT-INTERNET4 - AT&T WorldNet Services 13 - AS17974 7547 0.5% 10.7 -- TELKOMNET-AS2-AP PT Telekomunikasi Indonesia 14 - AS7738 7380 0.5% 18.0 -- Telecomunicacoes da Bahia S.A. 15 - AS24863 7156 0.5% 7.9 -- LINKdotNET-AS 16 - AS12479 6863 0.5% 14.5 -- UNI2-AS Uni2 Autonomous System 17 - AS4323 6839 0.5% 1.6 -- TWTC - tw telecom holdings, inc. 18 - AS20115 6331 0.4% 4.3 -- CHARTER-NET-HKY-NC - Charter Communications 19 - AS6478 6217 0.4% 4.6 -- ATT-INTERNET3 - AT&T WorldNet Services 20 - AS10620 6102 0.4% 6.1 -- TV Cable S.A. TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS11 38501 2.6% 2566.7 -- HARVARD - Harvard University 2 - AS48297 766 0.1% 766.0 -- DOORHAN "Vse dlya vorot" Ltd 3 - AS45703 1908 0.1% 636.0 -- BKPM-AS-ID Badan Koordinasi Penanaman Modal (BKPM) 4 - AS4796 615 0.0% 615.0 -- BANDUNG-NET-AS-AP Institute of Technology Bandung 5 - AS47408 13428 0.9% 610.4 -- MANDARIN-AS Mandarin WIMAX Sicilia SpA 6 - AS21684 536 0.0% 536.0 -- CYBERINETBGP - Cyberonics, Inc. 7 - AS25546 4774 0.3% 477.4 -- BROOKLANDCOMP-AS Brookland Computer Services 8 - AS45024 462 0.0% 462.0 -- INTERBALT-AS INTERBALT Ltd. 9 - AS1564 1215 0.1% 405.0 -- DNIC-ASBLK-01550-01601 - DoD Network Information Center 10 - AS8668 2741 0.2% 391.6 -- TELONE-AS TelOne Zimbabwe P/L 11 - AS47640 1174 0.1% 391.3 -- TRICOMPAS Tricomp Sp. z. o. o. 12 - AS5050 5866 0.4% 366.6 -- PSC-EXT - Pittsburgh Supercomputing Center 13 - AS24994 675 0.1% 337.5 -- GENESYS-AS GENESYS Informatica AS for announcing own prefixes 14 - AS43912 2141 0.1% 305.9 -- NEWCOM-AS ZAO "NEWCOM" 15 - AS36896 1421 0.1% 284.2 -- MVCOMM 16 - AS40060 2274 0.1% 252.7 -- AAAWI - AAA Wireless, Inc. 17 - AS9198 95250 6.4% 251.3 -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration 18 - AS35400 1425 0.1% 237.5 -- MFIST Interregoinal Organization Network Technologies 19 - AS41492 205 0.0% 205.0 -- EXIMBANK-AS SC Eximbank SA 20 - AS5691 2660 0.2% 204.6 -- MITRE-AS-5 - The MITRE Corporation TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 88.204.221.0/24 10286 0.7% AS9198 -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration 2 - 95.59.1.0/24 10251 0.7% AS9198 -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration 3 - 95.59.8.0/23 10173 0.6% AS9198 -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration 4 - 95.59.4.0/22 10173 0.6% AS9198 -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration 5 - 95.59.3.0/24 10169 0.6% AS9198 -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration 6 - 95.59.2.0/23 10169 0.6% AS9198 -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration 7 - 89.218.220.0/23 10152 0.6% AS9198 -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration 8 - 89.218.218.0/23 10152 0.6% AS9198 -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration 9 - 92.46.244.0/23 10149 0.6% AS9198 -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration 10 - 72.23.246.0/24 5820 0.4% AS5050 -- PSC-EXT - Pittsburgh Supercomputing Center 11 - 193.201.184.0/21 4765 0.3% AS25546 -- BROOKLANDCOMP-AS Brookland Computer Services 12 - 19.0.0.0/8 4366 0.3% AS11 -- HARVARD - Harvard University 13 - 130.175.0.0/16 4365 0.3% AS11 -- HARVARD - Harvard University 14 - 130.170.0.0/16 4365 0.3% AS11 -- HARVARD - Harvard University 15 - 85.60.208.0/21 2840 0.2% AS12479 -- UNI2-AS Uni2 Autonomous System 16 - 129.9.236.0/23 2746 0.2% AS11 -- HARVARD - Harvard University 17 - 205.203.160.0/23 2744 0.2% AS11 -- HARVARD - Harvard University 18 - 85.60.208.0/22 2648 0.2% AS12479 -- UNI2-AS Uni2 Autonomous System 19 - 192.12.120.0/24 2625 0.2% AS5691 -- MITRE-AS-5 - The MITRE Corporation 20 - 192.147.21.0/24 2495 0.2% AS11 -- HARVARD - Harvard University 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 Aug 7 17:00:00 2009 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 7 Aug 2009 22:00:00 GMT Subject: The Cidr Report Message-ID: <200908072200.n77M00hf004646@wattle.apnic.net> This report has been generated at Fri Aug 7 21:11:28 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 31-07-09 299904 183798 01-08-09 299999 183923 02-08-09 299995 184260 03-08-09 300160 184468 04-08-09 300138 182809 05-08-09 299330 183479 06-08-09 299916 183808 07-08-09 300092 183909 AS Summary 32000 Number of ASes in routing system 13604 Number of ASes announcing only one prefix 4307 Largest number of prefixes announced by an AS AS4323 : TWTC - tw telecom holdings, inc. 89680896 Largest address span announced by an AS (/32s) AS27064: DNIC-ASBLK-27032-27159 - DoD Network Information Center Aggregation Summary The algorithm used in this report proposes aggregation only when there is a precise match using the AS path, so as to preserve traffic transit policies. Aggregation is also proposed across non-advertised address space ('holes'). --- 07Aug09 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 300158 183909 116249 38.7% All ASes AS6389 4209 336 3873 92.0% BELLSOUTH-NET-BLK - BellSouth.net Inc. AS4323 4307 1674 2633 61.1% TWTC - tw telecom holdings, inc. AS4766 1825 540 1285 70.4% KIXS-AS-KR Korea Telecom AS17488 1551 289 1262 81.4% HATHWAY-NET-AP Hathway IP Over Cable Internet AS4755 1231 191 1040 84.5% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP AS22773 1082 70 1012 93.5% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. AS8151 1513 583 930 61.5% Uninet S.A. de C.V. AS18566 1062 277 785 73.9% COVAD - Covad Communications Co. AS19262 1022 237 785 76.8% VZGNI-TRANSIT - Verizon Internet Services Inc. AS6478 1329 587 742 55.8% ATT-INTERNET3 - AT&T WorldNet Services AS8452 1025 289 736 71.8% TEDATA TEDATA AS18101 748 42 706 94.4% RIL-IDC Reliance Infocom Ltd Internet Data Centre, AS10620 973 314 659 67.7% TV Cable S.A. AS1785 1725 1095 630 36.5% AS-PAETEC-NET - PaeTec Communications, Inc. AS4804 686 91 595 86.7% MPX-AS Microplex PTY LTD AS4808 754 194 560 74.3% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network AS9498 638 99 539 84.5% BBIL-AP BHARTI Airtel Ltd. AS22047 541 14 527 97.4% VTR BANDA ANCHA S.A. AS7303 617 94 523 84.8% Telecom Argentina S.A. AS855 615 123 492 80.0% CANET-ASN-4 - Bell Aliant Regional Communications, Inc. AS11492 1134 657 477 42.1% CABLEONE - CABLE ONE, INC. AS24560 731 255 476 65.1% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services AS9443 533 84 449 84.2% INTERNETPRIMUS-AS-AP Primus Telecommunications AS7018 1498 1052 446 29.8% ATT-INTERNET4 - AT&T WorldNet Services AS5668 778 341 437 56.2% AS-5668 - CenturyTel Internet Holdings, Inc. AS17676 564 129 435 77.1% GIGAINFRA Softbank BB Corp. AS4134 983 553 430 43.7% CHINANET-BACKBONE No.31,Jin-rong Street AS3356 1207 782 425 35.2% LEVEL3 Level 3 Communications AS4780 562 137 425 75.6% SEEDNET Digital United Inc. AS7011 986 568 418 42.4% FRONTIER-AND-CITIZENS - Frontier Communications of America, Inc. Total 36429 11697 24732 67.9% Top 30 total Possible Bogus Routes 24.38.192.0/18 AS36377 PATRIOT-MEDIA-NJ - Comcast Telecommunications, Inc. 24.225.128.0/17 AS36377 PATRIOT-MEDIA-NJ - Comcast Telecommunications, Inc. 24.245.128.0/17 AS11492 CABLEONE - CABLE ONE, INC. 41.223.92.0/22 AS36936 CELTEL-GABON Celtel Gabon Internet Service 41.223.112.0/22 AS5713 SAIX-NET 41.223.176.0/22 AS36981 41.223.188.0/24 AS22351 INTELSAT Intelsat Global BGP Routing Policy 41.223.189.0/24 AS26452 BRING-AS - BringCom, Inc. 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV - Wireless Broadband via Satellite 62.61.221.0/24 AS24974 TACHYON-EU Tachyon Europe BV - Wireless Broadband via Satellite 63.140.213.0/24 AS22555 UTC - Universal Talkware Corporation 63.143.251.0/24 AS22555 UTC - Universal Talkware Corporation 64.31.32.0/19 AS11955 SCRR-11955 - Road Runner HoldCo LLC 64.31.59.0/24 AS7017 SCRR-7015 - Road Runner HoldCo LLC 64.31.60.0/24 AS7017 SCRR-7015 - Road Runner HoldCo LLC 64.79.88.0/24 AS26096 LODDEN - Lodden Services 64.79.89.0/24 AS26096 LODDEN - Lodden Services 66.128.38.0/24 AS15246 Telecomunicaciones Satelitales TelesatS.A. 66.180.239.0/24 AS35888 VIGNETTE - VIGNETTE CORPORATION 66.206.32.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.33.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.34.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.35.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.40.0/22 AS174 COGENT Cogent/PSI 66.206.44.0/23 AS174 COGENT Cogent/PSI 66.206.47.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 66.207.32.0/20 AS23011 66.241.112.0/20 AS21547 REVNETS - Revolution Networks 66.245.176.0/20 AS19318 NJIIX-AS-1 - NEW JERSEY INTERNATIONAL INTERNET EXCHANGE LLC 69.6.80.0/24 AS13442 69.6.81.0/24 AS13442 69.71.192.0/20 AS13818 PHX-INTL-TELEPORT - Phoenix International Teleport 74.116.112.0/21 AS12182 INTERNAP-2BLK - Internap Network Services Corporation 80.88.10.0/24 AS33774 DJAWEB 80.88.12.0/24 AS33779 wataniya-telecom-as 100.100.100.0/30 AS38676 AS33005-AS-KR wizsolution co.,Ltd 116.50.0.0/24 AS17754 EXCELL-AS Excellmedia 117.120.56.0/21 AS4755 TATACOMM-AS TATA Communications formerly VSNL is Leading ISP 121.46.0.0/16 AS4134 CHINANET-BACKBONE No.31,Jin-rong Street 121.50.10.0/24 AS38236 121.50.13.0/24 AS38236 121.50.15.0/24 AS17625 BLAZENET-IN-AP BlazeNet's Network 121.50.168.0/21 AS9931 CAT-AP The Communication Authoity of Thailand, CAT 122.128.120.0/22 AS38456 PACTEL-AS-AP Pacific Teleports. 158.222.5.0/24 AS21580 SIERRA-ADVANTAGE - Sierra Advantage, Inc. 158.222.70.0/23 AS6137 SISNA - SISNA, Inc. 158.222.72.0/23 AS6137 SISNA - SISNA, Inc. 158.222.224.0/20 AS19864 O1COMM - O1 COMMUNICATIONS 158.222.224.0/22 AS19864 O1COMM - O1 COMMUNICATIONS 158.222.229.0/24 AS19864 O1COMM - O1 COMMUNICATIONS 163.142.0.0/16 AS2500 WIDE-BB WIDE Project 172.7.0.0/24 AS28175 172.10.1.0/30 AS18305 POSNET POSDATA Co.,Ltd 178.0.0.0/16 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 178.1.0.0/21 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 178.1.24.0/24 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 192.9.0.0/16 AS11479 BRM-SUN-AS - Sun Microsystems, Inc 192.9.200.0/24 AS3602 AS3602-RTI - Rogers Telecom Inc. 192.64.85.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.69.107.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.69.108.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.69.177.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.70.164.0/24 AS25689 NRCNET-AS - National Research Council of Canada 192.96.37.0/24 AS10474 NETACTIVE 192.96.135.0/24 AS2018 TENET-1 192.96.136.0/23 AS2018 TENET-1 192.96.141.0/24 AS2018 TENET-1 192.96.143.0/24 AS2018 TENET-1 192.96.145.0/24 AS2018 TENET-1 192.96.177.0/24 AS6083 POSIX-AFRICA 192.101.45.0/24 AS2905 TICSA-ASN 192.101.46.0/24 AS6503 Avantel, S.A. 192.101.64.0/21 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 192.101.70.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 192.101.71.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 192.101.72.0/24 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 192.101.74.0/24 AS1239 SPRINTLINK - Sprint 192.124.248.0/23 AS680 DFN-IP service X-WiN 192.124.252.0/22 AS680 DFN-IP service X-WiN 192.131.233.0/24 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 192.132.58.0/24 AS20141 QUALITYTECH-SUW-300 - Quality Technology Services, LLC. 192.133.6.0/24 AS10282 ORANGE-BUSINESS-SERVICES-CEEUR Orange Business Services (formerly Equant) AS for CEEUR 192.139.3.0/24 AS23184 PERSONA - PERSONA COMMUNICATIONS INC. 192.153.144.0/21 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 192.154.32.0/19 AS81 NCREN - MCNC 192.188.208.0/20 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 193.33.148.0/23 AS30890 EVOLVA Evolva Telecom / iLink Telecom 193.104.229.0/26 AS34444 EUTELSAT-BACKBONE-AS EUTELSAT S.A. 196.6.108.0/24 AS5713 SAIX-NET 196.10.119.0/24 AS2018 TENET-1 196.10.122.0/23 AS2018 TENET-1 196.10.251.0/24 AS2018 TENET-1 196.10.252.0/23 AS2018 TENET-1 196.10.254.0/24 AS2018 TENET-1 196.13.101.0/24 AS2018 TENET-1 196.13.102.0/23 AS2018 TENET-1 196.13.104.0/24 AS2018 TENET-1 196.13.121.0/24 AS2018 TENET-1 196.13.125.0/24 AS2018 TENET-1 196.13.126.0/24 AS2018 TENET-1 196.13.169.0/24 AS2018 TENET-1 196.13.174.0/23 AS2018 TENET-1 196.13.176.0/21 AS2018 TENET-1 196.13.192.0/22 AS2018 TENET-1 196.13.196.0/24 AS2018 TENET-1 196.202.224.0/21 AS8818 TELE Greenland Autonomous System 198.1.2.0/24 AS4761 INDOSAT-INP-AP INDOSAT Internet Network Provider 198.23.26.0/24 AS4390 BELLATLANTIC-COM - Bell Atlantic, Inc. 198.54.82.0/24 AS2018 TENET-1 198.54.92.0/24 AS2018 TENET-1 198.54.222.0/24 AS2018 TENET-1 198.73.210.0/24 AS21570 ACI-1 - Accelerated Connections Inc. 198.97.72.0/21 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 198.97.96.0/19 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 198.97.240.0/20 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 198.135.236.0/24 AS4358 XNET - XNet Information Systems, Inc. 198.161.87.0/24 AS6539 GT-BELL - Bell Canada 198.161.92.0/24 AS6539 GT-BELL - Bell Canada 198.167.0.0/16 AS7456 INTERHOP - Interhop Network SERVICES Inc. 198.168.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 198.169.0.0/16 AS803 SASKTEL - Saskatchewan Telecommunications 198.180.198.0/24 AS23715 SEOUL-INTGW-GXS-AP Global Exchange Services 199.5.242.0/24 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 199.10.0.0/16 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.16.32.0/19 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 199.114.0.0/21 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.114.128.0/18 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.114.130.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.131.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.132.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.134.0/24 AS3541 ITSDN-U4 - DoD Network Information Center 199.114.136.0/24 AS27044 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.114.138.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.140.0/24 AS3544 ITSDN-U7 - DoD Network Information Center 199.114.142.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.144.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.148.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.150.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.152.0/24 AS27033 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.114.153.0/24 AS27034 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.114.154.0/24 AS1733 CENTAF-SWA - 754th Electronic Systems Group 199.114.156.0/24 AS1733 CENTAF-SWA - 754th Electronic Systems Group 199.114.160.0/24 AS1733 CENTAF-SWA - 754th Electronic Systems Group 199.121.0.0/16 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.123.0.0/18 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.123.16.0/20 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.123.80.0/21 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.189.32.0/19 AS7332 IQUEST-AS - IQuest Internet 199.202.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 199.202.216.0/21 AS577 BACOM - Bell Canada 199.233.92.0/24 AS26896 ITCOMM - IT Communications 199.246.116.0/24 AS813 UUNET-CANADA - MCI Communications Services, Inc. d/b/a Verizon Business 200.9.115.0/24 AS10292 CWJ-1 - Cable & Wireless Jamaica 200.108.176.0/20 AS14551 UUNET-SA - MCI Communications Services, Inc. d/b/a Verizon Business 202.6.176.0/20 AS24316 202.58.113.0/24 AS19161 202.73.144.0/20 AS4788 TMNET-AS-AP TM Net, Internet Service Provider 202.80.192.0/20 AS2706 PI-HK Pacnet Internet (Hong Kong) Limited 202.84.10.0/23 AS9308 CHINA-ABITCOOL Abitcool(China) Inc. 202.86.252.0/22 AS4748 RESOLINK-AS-AP Resources Link Network Limited 202.86.252.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.253.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.254.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.255.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.94.70.0/24 AS2764 AAPT AAPT Limited 202.124.195.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.125.113.0/24 AS9541 CYBERNET-AP Cyber Internet Services (Pvt) Ltd. 202.125.114.0/24 AS9541 CYBERNET-AP Cyber Internet Services (Pvt) Ltd. 202.125.115.0/24 AS9541 CYBERNET-AP Cyber Internet Services (Pvt) Ltd. 202.133.37.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.133.47.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.133.70.0/24 AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited 202.133.73.0/24 AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited 202.136.254.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.136.255.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.140.160.0/24 AS4841 202.140.161.0/24 AS4841 202.140.162.0/24 AS4841 202.140.163.0/24 AS4841 202.140.164.0/24 AS4841 202.140.165.0/24 AS4841 202.140.166.0/24 AS4841 202.140.167.0/24 AS4841 202.140.168.0/24 AS4841 202.140.169.0/24 AS4841 202.140.170.0/24 AS4841 202.140.171.0/24 AS4841 202.140.172.0/24 AS4841 202.140.173.0/24 AS4841 202.140.174.0/24 AS4841 202.140.175.0/24 AS4841 202.140.180.0/24 AS7540 HKCIX-AS-AP HongKong Commercial Internet Exchange 202.140.181.0/24 AS7540 HKCIX-AS-AP HongKong Commercial Internet Exchange 202.140.182.0/24 AS7540 HKCIX-AS-AP HongKong Commercial Internet Exchange 202.150.227.0/24 AS17727 NAPINFO-AS-AP PT. NAP Info Lintas Nusa 202.181.32.0/24 AS4645 ASN-HKNET-AP HKNet Co. Ltd 203.12.45.0/24 AS4854 NETSPACE-AS-AP Netspace Online Systems 203.62.0.0/17 AS7575 AARNET-AS-AP Australian Academic and Reasearch Network (AARNet) 203.78.48.0/20 AS9299 IPG-AS-AP Philippine Long Distance Telephone Company 203.80.136.0/21 AS4759 EVOSERVE-AS-AP EvoServe is a content and online access Internet provider company 203.86.96.0/19 AS4755 TATACOMM-AS TATA Communications formerly VSNL is Leading ISP 203.89.139.0/24 AS17911 BRAINPK-AS-AP Brain Telecommunication Ltd. 203.112.111.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.113.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.114.0/24 AS4802 ASN-IINET iiNet Limited 203.112.116.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.117.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.118.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.119.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.120.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.121.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.127.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.128.128.0/19 AS4134 CHINANET-BACKBONE No.31,Jin-rong Street 203.128.128.0/24 AS23849 CNNIC-NET263-AP Beijing Capital-online science development Co.,Ltd. 203.142.219.0/24 AS45149 203.189.96.0/20 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 204.9.216.0/23 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 204.9.218.0/23 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 204.19.14.0/23 AS577 BACOM - Bell Canada 204.89.214.0/24 AS4323 TWTC - tw telecom holdings, inc. 204.138.167.0/24 AS18990 AIRBAND-DALLAS - Airband Communications, Inc 204.197.0.0/16 AS3356 LEVEL3 Level 3 Communications 205.150.0.0/15 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 205.185.0.0/20 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 205.189.134.0/24 AS11814 CYBERSURF - Cybersurf Inc. 205.210.145.0/24 AS11814 CYBERSURF - Cybersurf Inc. 206.180.240.0/20 AS12083 KNOLOGY-NET - Knology Holdings 207.174.0.0/16 AS13790 INTERNAP-BLK3 - Internap Network Services Corporation 207.174.131.0/24 AS30715 NETRACK - Netrack, Inc. 207.174.132.0/23 AS30715 NETRACK - Netrack, Inc. 207.174.151.0/24 AS11500 PEAKPEAK - Peak to Peak Internet 207.174.152.0/22 AS30715 NETRACK - Netrack, Inc. 207.174.177.0/24 AS11500 PEAKPEAK - Peak to Peak Internet 207.174.178.0/24 AS11500 PEAKPEAK - Peak to Peak Internet 207.174.182.0/24 AS29831 FONENET - FONE NET, LLC 207.174.188.0/22 AS30715 NETRACK - Netrack, Inc. 207.174.192.0/24 AS29831 FONENET - FONE NET, LLC 207.174.200.0/24 AS22658 EARTHNET - Earthnet, Inc. 207.174.248.0/21 AS6653 PRIVATEI - privateI, LLC 207.231.96.0/19 AS11194 NUNETPA - NuNet Inc. 208.73.88.0/21 AS36835 208.77.224.0/24 AS36835 208.77.225.0/24 AS36835 208.77.226.0/24 AS36835 208.77.227.0/24 AS36835 208.77.228.0/24 AS36835 208.77.229.0/24 AS36835 208.77.230.0/24 AS36835 208.77.231.0/24 AS36835 209.54.123.0/24 AS6062 NETPLEX - NETPLEX 209.54.240.0/21 AS10887 BPSI-AS - BPSI Internet Services 209.74.96.0/19 AS10912 INTERNAP-BLK - Internap Network Services Corporation 209.140.90.0/24 AS14461 NTSL - NET SOLUTIONS 209.141.48.0/22 AS14461 NTSL - NET SOLUTIONS 209.217.224.0/19 AS6130 AIS-WEST - American Internet Services, LLC. 209.222.5.0/24 AS26699 PSI-CT - Printing For Systems Inc 209.222.6.0/24 AS26699 PSI-CT - Printing For Systems Inc 210.5.128.0/20 AS4837 CHINA169-BACKBONE CNCGROUP China169 Backbone 210.247.224.0/19 AS7496 WEBCENTRAL-AS WebCentral 213.181.70.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.80.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.81.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.82.0/23 AS17175 NSS-UK New Skies Satellites UK AS 213.181.82.0/24 AS17175 NSS-UK New Skies Satellites UK AS 213.181.83.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.84.0/22 AS17175 NSS-UK New Skies Satellites UK AS 213.181.84.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.85.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.86.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.87.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.88.0/21 AS17175 NSS-UK New Skies Satellites UK AS 213.181.88.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.89.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.90.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.91.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.92.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.93.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.94.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.95.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 216.99.20.0/24 AS3356 LEVEL3 Level 3 Communications 216.163.144.0/20 AS35985 ONERINGNET-ATL-1 - One Ring Networks, Inc. 216.172.198.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 216.172.199.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 216.251.207.0/24 AS1239 SPRINTLINK - Sprint 217.78.71.0/24 AS12491 IPPLANET-AS Gilat Satcom 217.78.72.0/24 AS12491 IPPLANET-AS Gilat Satcom 217.78.73.0/24 AS12491 IPPLANET-AS Gilat Satcom Please see http://www.cidr-report.org for the full report ------------------------------------ Copies of this report are mailed to: nanog at merit.edu eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From mailvortex at gmail.com Fri Aug 7 17:23:22 2009 From: mailvortex at gmail.com (Ben Scott) Date: Fri, 7 Aug 2009 18:23:22 -0400 Subject: dnscurve and DNS hardening, was Re: Dan Kaminsky In-Reply-To: <200908061106.57699.a.harrowell@gmail.com> References: <4A7870BA.4020704@xyonet.com> <20090806044533.GN30683@armakuni.lastninja.net> <82k51h75r6.fsf@mid.bfk.de> <200908061106.57699.a.harrowell@gmail.com> Message-ID: <59f980d60908071523w3fcfd168ge2fad84d7e2660ab@mail.gmail.com> On Thu, Aug 6, 2009 at 6:06 AM, Alexander Harrowell wrote: > 1) Authenticate the nameserver to the client (and so on up the chain to the > root) in order to defeat the Kaminsky attack, man in the middle, IP-layer > interference. (Are you who you say you are?) DNSSEC fans will be quick to point out that if everyone used DNSSEC, there would be no need to worry about Kaminsky attacks, etc. Nobody would bother with them since nobody would be vulnerable to them. Of course, expecting universal deployment of *anything* is a bit silly, so I think worrying about the transport might have been a good idea, too. But then, the standard was written 15 or so years ago, when CPU power was more expensive. Plus there's generally not a lot of trust between DNS client and server anyway, so I'm not really sure it matters. (It's not like most ISPs issue PKI certificates to their customers.) Something DNSSEC *can't* defend against is a simple DoS flood of bogus questions/answers. Of course, I don't really think DNSCurve can, either. Sure, it discards bogus packets, but it burns up a lot of CPU time doing so, so you're that much more vulnerable to a DoS flood. But then, given sufficient resources on the part of the attacker, there's really nothing anyone can do *locally* do defend against a DoS flood. Stuff enough data into *any* tube and it will clog. -- Ben From patrick at ianai.net Fri Aug 7 17:30:01 2009 From: patrick at ianai.net (Patrick W. Gilmore) Date: Fri, 7 Aug 2009 18:30:01 -0400 Subject: Weekly Routing Table Report In-Reply-To: <200908071813.n77ID1bX007948@thyme.apnic.net> References: <200908071813.n77ID1bX007948@thyme.apnic.net> Message-ID: On Aug 7, 2009, at 2:13 PM, Routing Analysis Role Account wrote: > BGP routing table entries examined: > 293130 By at least one count, we are still below 300K. -- TTFN, patrick From randy at psg.com Fri Aug 7 21:45:24 2009 From: randy at psg.com (Randy Bush) Date: Sat, 08 Aug 2009 11:45:24 +0900 Subject: sat-3 cut? In-Reply-To: <4A721DF7.1070101@gmail.com> References: <4A721DF7.1070101@gmail.com> Message-ID: >> http://english.aljazeera.net/news/africa/2009/07/2009730775992910.html > Surely, for a major investment like this, both ends have peers with others? never actually looked at the problems of african networking, have you? randy From randy at psg.com Fri Aug 7 22:01:29 2009 From: randy at psg.com (Randy Bush) Date: Sat, 08 Aug 2009 12:01:29 +0900 Subject: Dan Kaminsky In-Reply-To: <202705b0908051623o6bf13228vfcaf9a0a8ef7ea8a@mail.gmail.com> References: <4A7870BA.4020704@xyonet.com> <20090804183246.B69B41CC34@ptavv.es.net> <20090805141810.GA24211@ussenterprise.ufp.org> <823a86cow4.fsf@mid.bfk.de> <20090805160703.GA35668@ussenterprise.ufp.org> <202705b0908050949p2285aef0qae1c78aa5f17f71a@mail.gmail.com> <59f980d60908051526n7ab973ebi5285439e4a35285a@mail.gmail.com> <20090805223732.GC1408048@hiwaay.net> <202705b0908051606x46611462u5a61b574b8f0f914@mail.gmail.com> <59f980d60908051617t1dc05917pbdc47e1cc7ef6f26@mail.gmail.com> <202705b0908051623o6bf13228vfcaf9a0a8ef7ea8a@mail.gmail.com> Message-ID: > Have you seen the iphone decoding bar code into urls ? doesn't the iphone has an app to decode qr-codes similar to the one built into almost all keitai here in japan. http://en.wikipedia.org/wiki/QR_Code randy From gtb at slac.stanford.edu Fri Aug 7 22:30:20 2009 From: gtb at slac.stanford.edu (Buhrmaster, Gary) Date: Fri, 7 Aug 2009 20:30:20 -0700 Subject: Dan Kaminsky In-Reply-To: References: <4A7870BA.4020704@xyonet.com><20090804183246.B69B41CC34@ptavv.es.net><20090805141810.GA24211@ussenterprise.ufp.org><823a86cow4.fsf@mid.bfk.de><20090805160703.GA35668@ussenterprise.ufp.org><202705b0908050949p2285aef0qae1c78aa5f17f71a@mail.gmail.com><59f980d60908051526n7ab973ebi5285439e4a35285a@mail.gmail.com><20090805223732.GC1408048@hiwaay.net><202705b0908051606x46611462u5a61b574b8f0f914@mail.gmail.com><59f980d60908051617t1dc05917pbdc47e1cc7ef6f26@mail.gmail.com><202705b0908051623o6bf13228vfcaf9a0a8ef7ea8a@mail.gmail.com> Message-ID: > doesn't the iphone has an app to decode qr-codes similar to the one > built into almost all keitai here in japan. > > http://en.wikipedia.org/wiki/QR_Code Yep. Called iMatrix. (There are probably others too) From dr at kyx.net Fri Aug 7 22:41:59 2009 From: dr at kyx.net (Dragos Ruiu) Date: Fri, 7 Aug 2009 20:41:59 -0700 Subject: QR-Codes... was: Re: Dan Kaminsky In-Reply-To: References: <4A7870BA.4020704@xyonet.com> <20090804183246.B69B41CC34@ptavv.es.net> <20090805141810.GA24211@ussenterprise.ufp.org> <823a86cow4.fsf@mid.bfk.de> <20090805160703.GA35668@ussenterprise.ufp.org> <202705b0908050949p2285aef0qae1c78aa5f17f71a@mail.gmail.com> <59f980d60908051526n7ab973ebi5285439e4a35285a@mail.gmail.com> <20090805223732.GC1408048@hiwaay.net> <202705b0908051606x46611462u5a61b574b8f0f914@mail.gmail.com> <59f980d60908051617t1dc05917pbdc47e1cc7ef6f26@mail.gmail.com> <202705b0908051623o6bf13228vfcaf9a0a8ef7ea8a@mail.gmail.com> Message-ID: On 7-Aug-09, at 8:01 PM, Randy Bush wrote: >> Have you seen the iphone decoding bar code into urls ? > > doesn't the iphone has an app to decode qr-codes similar to the one > built into almost all keitai here in japan. > > http://en.wikipedia.org/wiki/QR_Code There are multiple (5+ at last count) iPhone apps for QR codes, incl. NTT and KDDI/au variants. There are also similar apps for Android, and Symbian ships with one (though not field aware like NTT and KDDI/au variants) cheers, --dr -- World Security Pros. Cutting Edge Training, Tools, and Techniques Tokyo, Japan November 4/5 2009 http://pacsec.jp Vancouver, Canada March 22-26 http://cansecwest.com pgpkey http://dragos.com/ kyxpgp From jmamodio at gmail.com Fri Aug 7 22:47:06 2009 From: jmamodio at gmail.com (Jorge Amodio) Date: Fri, 7 Aug 2009 22:47:06 -0500 Subject: Dan Kaminsky In-Reply-To: References: <4A7870BA.4020704@xyonet.com> <823a86cow4.fsf@mid.bfk.de> <20090805160703.GA35668@ussenterprise.ufp.org> <202705b0908050949p2285aef0qae1c78aa5f17f71a@mail.gmail.com> <59f980d60908051526n7ab973ebi5285439e4a35285a@mail.gmail.com> <20090805223732.GC1408048@hiwaay.net> <202705b0908051606x46611462u5a61b574b8f0f914@mail.gmail.com> <59f980d60908051617t1dc05917pbdc47e1cc7ef6f26@mail.gmail.com> <202705b0908051623o6bf13228vfcaf9a0a8ef7ea8a@mail.gmail.com> Message-ID: <202705b0908072047n8f96204hfc37845931c7353a@mail.gmail.com> >> Have you seen the iphone decoding bar code into urls ? > > doesn't the iphone has an app to decode qr-codes similar to the one > built into almost all keitai here in japan. Yes, is not really new but it can decode QR, DataMatrix (same as used for postage), ShotCode and bar code. With the new camera some applications got much better. Regards Jorge From jmamodio at gmail.com Fri Aug 7 23:32:44 2009 From: jmamodio at gmail.com (Jorge Amodio) Date: Fri, 7 Aug 2009 23:32:44 -0500 Subject: Dan Kaminsky In-Reply-To: References: <4A7870BA.4020704@xyonet.com> <20090805160703.GA35668@ussenterprise.ufp.org> <202705b0908050949p2285aef0qae1c78aa5f17f71a@mail.gmail.com> <59f980d60908051526n7ab973ebi5285439e4a35285a@mail.gmail.com> <20090805223732.GC1408048@hiwaay.net> <202705b0908051606x46611462u5a61b574b8f0f914@mail.gmail.com> <59f980d60908051617t1dc05917pbdc47e1cc7ef6f26@mail.gmail.com> <202705b0908051623o6bf13228vfcaf9a0a8ef7ea8a@mail.gmail.com> Message-ID: <202705b0908072132n703bce0cv7e4a58b9207f82a4@mail.gmail.com> >> doesn't the iphone has an app to decode qr-codes similar to the one >> built into almost all keitai here in japan. >> >> ? ? http://en.wikipedia.org/wiki/QR_Code > > Yep. ?Called iMatrix. ?(There are probably others too) Yes, that's one of the apps. Anyway, as you can see this is just one example that a URL may not look prima facie like a construct based on a FQDN. One issue on the UI side is that even with all the progress in graphics and visual representation for many things, to enter a URL we are still using a TTY interface. There are folks (MSFT is investing a bunch of money on it) doing R&D for touch sensitive data entry devices/UI that are context aware. You have now a little taste of that technology with the iphone and all the new smartphones and other gadgets that implemented the same idea. How many URLs you type to get to YouTube on the iphone/itouch ? ... none. The DNS (or whatever name we call it in the future) is not going away, it will go back to be what it was intented, and not just a giant global billboard where folks are fighting for space on it and where some other folks -even if they don't need it- buy space hoping that someday somebody will want their space at any cost making her/him rich. Cheers Jorge From smb at cs.columbia.edu Fri Aug 7 21:41:05 2009 From: smb at cs.columbia.edu (Steven M. Bellovin) Date: Fri, 7 Aug 2009 22:41:05 -0400 Subject: DNS hardening, was Re: Dan Kaminsky In-Reply-To: References: <20090805164823.43774.qmail@simone.iecc.com> <4A79CB90.708@mail-abuse.org> <90CEC867-A870-4E45-AFC2-898AD655699E@arbor.net> <4A79F8A3.9040302@mail-abuse.org> <75cb24520908051449n29c53491m90fd021022d9816f@mail.gmail.com> <4A7A0D6C.90808@mail-abuse.org> <75cb24520908051853t6c0f05d3l94c404d3227d191c@mail.gmail.com> Message-ID: <20090807224105.62dfb659@cs.columbia.edu> On Thu, 06 Aug 2009 06:51:24 +0000 Paul Vixie wrote: > Christopher Morrow writes: > > > how does SCTP ensure against spoofed or reflected attacks? > > there is no server side protocol control block required in SCTP. > someone sends you a "create association" request, you send back a > "ok, here's your cookie" and you're done until/unless they come back > and say "ok, here's my cookie, and here's my DNS request." so a > spoofer doesn't get a cookie and a reflector doesn't burden a server > any more than a ddos would do. > > because of the extra round trips nec'y to create an SCTP > "association" (for which you can think, lightweight TCP-like > session-like), it's going to be nec'y to leave associations in place > between iterative caches and authority servers, and in place between > stubs and iterative caches. however, because the state is mostly on > the client side, a server with associations open to millions of > clients at the same time is actually no big deal. Am I missing something? The SCTP cookie guards against the equivalent of SYN-flooding attacks. The problem with SCTP is normal operations. A UDP DNS query today takes a message and a reply, with no (kernel) state created on the server end. For SCTP, it takes two round trips to set up the connection -- which includes kernel state -- followed by the query and reply, and tear-down. I confess that I don't remember the SCTP state diagram; in TCP, the side that closes first can end up in FIN-WAIT2 state, which is stable. That is, suppose the server -- the loaded party -- tries to shed kernel state by closing its DNS socket first. If the client goes away or is otherwise uncooperative, the server will then end up in FIN-WAIT2, in which case kernel memory is consumed "forever" by conforming server TCPs. Does SCTP have that problem? --Steve Bellovin, http://www.cs.columbia.edu/~smb From lsc at prgmr.com Fri Aug 7 23:57:19 2009 From: lsc at prgmr.com (Luke S Crawford) Date: 08 Aug 2009 00:57:19 -0400 Subject: Botnet hunting resources (was: Re: DOS in progress ?) In-Reply-To: <202705b0908060825y55b775aew9a3601fae77f9207@mail.gmail.com> References: <202705b0908060825y55b775aew9a3601fae77f9207@mail.gmail.com> Message-ID: Jorge Amodio writes: > Are folks seeing any major DOS in progress ? > > Twitter seems to be under one and FB is flaky. >From what I understand, it's quite common. I got hammered last week. It took out some routers at my upstream (it was a tcp syn flood attack, a whole lot of really small packets. 20Kpps was the peak I saw before the upstream took me out.) Now, I've cleaned up the mess; (and for now, dropped the inexpensive upstream with the weak routers) I'm building out my monitoring infrastructure and generally preparing for next time. as far as stopping the attacks by 'finishing the job' - which is to say, blackholing the target, the way forward is pretty clear. I mean, I need to do more research and implement stuff, but I don't really need NANOG help for that. The thing is, I like my customers. I don't want to shut off people who are paying me just because they get attacked. I mean, if that's what I've got to do to keep my other paying customers up, I'll do it, but I'd really rather not. what is the 'best practice' here? I mean, most of this is scripted, so conceivably, I could get source addresses fast enough to block them upstream. (right now my provider is only allowing me to blackhole my own space, not blackhole source addresses, which while it keeps me in business, is not really what I want.) My provider does seem to be pretty responsive, so if I can bring them a tool, they might set it up for me. But yeah, I'm getting sidetracked. I guess there are two things I want to know: 1. are there people who apply pressure to ISPs to get them to shut down botnets, like maps did for spam? I've got 50 gigs of packet captures, and have been going through with perl to detect IPs who send me lots of tcp packets with 0 payloads, then manually sending abuse reports. Half the abuse reports bounce, and the other half are ignored. (most of the hosts in question are in china.) 2. is there a standard way to push a null-route on the attackers source IP upstream? I know the problem is difficult due to trust issues, but if I could null route the source, it's just a matter of detecting abusive traffic, and with this attack, that part was pretty easy. -- Luke S. Crawford http://prgmr.com/xen/ - Hosting for the technically adept http://nostarch.com/xen.htm - We don't assume you are stupid. From rdobbins at arbor.net Sat Aug 8 00:45:29 2009 From: rdobbins at arbor.net (Roland Dobbins) Date: Sat, 8 Aug 2009 12:45:29 +0700 Subject: Botnet hunting resources (was: Re: DOS in progress ?) In-Reply-To: References: <202705b0908060825y55b775aew9a3601fae77f9207@mail.gmail.com> Message-ID: On Aug 8, 2009, at 11:57 AM, Luke S Crawford wrote: > 2. is there a standard way to push a null-route on the attackers > source IP upstream? Sure - if you apply loose-check uRPF (and/or strict-check, when you can do so) on Cisco or Juniper routers, you can combine that with the blackhole to give you a source-based remotely-triggered blackhole, or S/RTBH. You can do this at your edges, and you *may* be able to arrange it with other networks with whom you connect (i.e., scope limited to your link with them). Combine that with the other standard architectural and hardening BCPs, along with the DNS BCPs, and you'll be much better prepared to detect, classify, traceback, and mitigate attacks. The key is to ensure you're making use of hardware-based routers which can handle high pps. ----------------------------------------------------------------------- Roland Dobbins // Unfortunately, inefficiency scales really well. -- Kevin Lawton From lsc at prgmr.com Sat Aug 8 03:15:04 2009 From: lsc at prgmr.com (Luke S Crawford) Date: 08 Aug 2009 04:15:04 -0400 Subject: Botnet hunting resources (was: Re: DOS in progress ?) In-Reply-To: References: <202705b0908060825y55b775aew9a3601fae77f9207@mail.gmail.com> Message-ID: Roland Dobbins writes: > On Aug 8, 2009, at 11:57 AM, Luke S Crawford wrote: > > > 2. is there a standard way to push a null-route on the attackers > > source IP upstream? > > Sure - if you apply loose-check uRPF (and/or strict-check, when you > can do so) on Cisco or Juniper routers, you can combine that with the > blackhole to give you a source-based remotely-triggered blackhole, or > S/RTBH. You can do this at your edges, and you *may* be able to > arrange it with other networks with whom you connect (i.e., scope > limited to your link with them). Ah, nice. thank you, that is exactly what I was looking for. I'll read up on it this weekend and see if I can talk my provider into letting me push that upstream. -- Luke S. Crawford http://prgmr.com/xen/ - Hosting for the technically adept http://nostarch.com/xen.htm - We don't assume you are stupid. From Jon.Kibler at aset.com Sat Aug 8 09:24:31 2009 From: Jon.Kibler at aset.com (Jon Kibler) Date: Sat, 08 Aug 2009 10:24:31 -0400 Subject: ServerBeach Name Server Outage? Message-ID: <4A7D8A9F.2060604@aset.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Is anyone else that uses ServerBeach hosting having issues with their name servers (ns[12].geodns.net) failing to resolve their hostnames? Jon K - -- Jon R. Kibler Chief Technical Officer Advanced Systems Engineering Technology, Inc. Charleston, SC USA o: 843-849-8214 c: 843-813-2924 (NEW!) s: 843-564-4224 http://www.linkedin.com/in/jonrkibler My PGP Fingerprint is: BAA2 1F2C 5543 5D25 4636 A392 515C 5045 CF39 4253 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkp9ip8ACgkQUVxQRc85QlPsXQCeNOy9iBjcqOoEkWnQzzfswLuJ eVsAnRADCXW0MbehW7yI907CABcTQmih =clMu -----END PGP SIGNATURE----- ================================================== Filtered by: TRUSTEM.COM's Email Filtering Service http://www.trustem.com/ No Spam. No Viruses. Just Good Clean Email. From joelja at bogus.com Sat Aug 8 09:37:24 2009 From: joelja at bogus.com (Joel Jaeggli) Date: Sat, 08 Aug 2009 07:37:24 -0700 Subject: Botnet hunting resources In-Reply-To: References: <202705b0908060825y55b775aew9a3601fae77f9207@mail.gmail.com> Message-ID: <4A7D8DA4.7070205@bogus.com> Roland Dobbins wrote: > > On Aug 8, 2009, at 11:57 AM, Luke S Crawford wrote: > >> 2. is there a standard way to push a null-route on the attackers >> source IP upstream? > > Sure - if you apply loose-check uRPF (and/or strict-check, when you can > do so) on Cisco or Juniper routers, you can combine that with the > blackhole to give you a source-based remotely-triggered blackhole, or > S/RTBH. You can do this at your edges, and you *may* be able to arrange > it with other networks with whom you connect (i.e., scope limited to > your link with them). Warren Kumari and other collaborated on a document to describe how this is normally done: http://tools.ietf.org/html/draft-ietf-opsec-blackhole-urpf-04 Coordination with your upstreams before you need this is important. > Combine that with the other standard architectural and hardening BCPs, > along with the DNS BCPs, and you'll be much better prepared to detect, > classify, traceback, and mitigate attacks. The key is to ensure you're > making use of hardware-based routers which can handle high pps. > > ----------------------------------------------------------------------- > Roland Dobbins // > > Unfortunately, inefficiency scales really well. > > -- Kevin Lawton > > From frnkblk at iname.com Sat Aug 8 11:35:42 2009 From: frnkblk at iname.com (Frank Bulk) Date: Sat, 8 Aug 2009 11:35:42 -0500 Subject: Botnet hunting resources (was: Re: DOS in progress ?) In-Reply-To: References: <202705b0908060825y55b775aew9a3601fae77f9207@mail.gmail.com> Message-ID: Some hardcore stuff on S/RTBH here: http://www.arbornetworks.com/index.php?option=com_docman&task=doc_download&g id=112 http://www.cisco.com/web/about/security/intelligence/blackhole.pdf (which appears to have replaced http://www.cisco.com/warp/public/732/Tech/security/docs/blackhole.pdf) http://www.nanog.org/meetings/nanog30/presentations/morrow.pdf http://pierky.wordpress.com/2009/05/31/gns3-lab-remote-triggered-black-holin g/ http://packetlife.net/blog/2009/jul/06/remotely-triggered-black-hole-rtbh-ro uting/ Frank -----Original Message----- From: Luke S Crawford [mailto:lsc at prgmr.com] Sent: Saturday, August 08, 2009 3:15 AM To: Roland Dobbins Cc: NANOG list Subject: Re: Botnet hunting resources (was: Re: DOS in progress ?) Roland Dobbins writes: > On Aug 8, 2009, at 11:57 AM, Luke S Crawford wrote: > > > 2. is there a standard way to push a null-route on the attackers > > source IP upstream? > > Sure - if you apply loose-check uRPF (and/or strict-check, when you > can do so) on Cisco or Juniper routers, you can combine that with the > blackhole to give you a source-based remotely-triggered blackhole, or > S/RTBH. You can do this at your edges, and you *may* be able to > arrange it with other networks with whom you connect (i.e., scope > limited to your link with them). Ah, nice. thank you, that is exactly what I was looking for. I'll read up on it this weekend and see if I can talk my provider into letting me push that upstream. -- Luke S. Crawford http://prgmr.com/xen/ - Hosting for the technically adept http://nostarch.com/xen.htm - We don't assume you are stupid. From william.allen.simpson at gmail.com Sat Aug 8 12:09:38 2009 From: william.allen.simpson at gmail.com (William Allen Simpson) Date: Sat, 08 Aug 2009 13:09:38 -0400 Subject: sat-3 cut? In-Reply-To: References: <4A721DF7.1070101@gmail.com> Message-ID: <4A7DB152.4030906@gmail.com> On a somewhat old thread, Randy Bush wrote: >>> http://english.aljazeera.net/news/africa/2009/07/2009730775992910.html >> Surely, for a major investment like this, both ends have peers with others? > > never actually looked at the problems of african networking, have you? > Not in a long time. My memory is that SAT-3 was supposed to be a nice cooperative effort funded by the nations themselves, rather than an outside investor. With cooperation, I'd have expected good peering. But my query isn't about politics, it's operational. By the map in the article, the termini are Spain and Portugal on one end, and South Africa on the other. Surely, a single break wouldn't affect both ends.... And the landings to Benin and Nigeria seem to be different (at least they have different numbers), so that's probably the break (between them). With peering on each end, traffic should just run each direction to the world.... -------------- next part -------------- A non-text attachment was scrubbed... Name: 200973082131872734_5.jpg Type: image/jpeg Size: 42607 bytes Desc: not available URL: From william.allen.simpson at gmail.com Sat Aug 8 12:27:40 2009 From: william.allen.simpson at gmail.com (William Allen Simpson) Date: Sat, 08 Aug 2009 13:27:40 -0400 Subject: sat-3 cut? In-Reply-To: <4A7DB152.4030906@gmail.com> References: <4A721DF7.1070101@gmail.com> <4A7DB152.4030906@gmail.com> Message-ID: <4A7DB58C.4080600@gmail.com> William Allen Simpson wrote: > By the map in the article, the termini are Spain and Portugal on one end, > and South Africa on the other. Surely, a single break wouldn't affect > both ends.... > A week later article by the BBC says it didn't. Rather, the Benin branch has the break. http://news.bbc.co.uk/2/hi/technology/8176014.stm "The rest of the system is unaffected by this fault," a Telkom South Africa representative said. > And the landings to Benin and Nigeria seem to be different (at least they > have different numbers), so that's probably the break (between them). > The Nigerian telco Nitel hasn't paid its dues, so its branch has been shut off, and most of Nigeria runs through Benin. Apparently, there is peering, and Benin is currently running "through neighbouring countries...." Sounds like this happenstance will provide motivation for more peering and cooperation. From george.barwood at blueyonder.co.uk Sat Aug 8 15:44:15 2009 From: george.barwood at blueyonder.co.uk (George Barwood) Date: Sat, 8 Aug 2009 21:44:15 +0100 Subject: DNS query repetition ( was DNS Hardening ) Message-ID: <806AE1E0D80B4FF59D47FC544FEEDE7A@localhost> In an earlier thread, Jon Levine asked > Other than DNSSEC, I'm aware of these relatively simple hacks to add > entropy to DNS queries. > 1) Random query ID > 2) Random source port > 3) Random case in queries, e.g. GooGLe.CoM > 4) Ask twice (with different values for the first three hacks) and compare > the answers > I presume everyone is doing the first two. Any experience with the other > two to report? I have implemented a (public domain) DNS cache "GbDns" that implements both 3 and 4 ( and also DnsCurve ). For non-deterministic authorities, such as Akamai, more that 2 queries are needed, and some relatively complex code. It turns out to be completely practical, albeit leading to an increase in the number of packets. Source code and a link to an IETF draft that describes the method is at http://www.george-barwood.pwp.blueyonder.co.uk/DnsServer/ Regards, George Barwood ( New subscriber, hence the new thread ) From goemon at anime.net Sat Aug 8 23:39:02 2009 From: goemon at anime.net (goemon at anime.net) Date: Sat, 8 Aug 2009 21:39:02 -0700 (PDT) Subject: Botnet hunting resources (was: Re: DOS in progress ?) In-Reply-To: References: <202705b0908060825y55b775aew9a3601fae77f9207@mail.gmail.com> Message-ID: On Fri, 8 Aug 2009, Luke S Crawford wrote: > 1. are there people who apply pressure to ISPs to get them to shut down > botnets, like maps did for spam? sadly no. > I've got 50 gigs of packet captures, and have been going through with > perl to detect IPs who send me lots of tcp packets with 0 payloads, then > manually sending abuse reports. > > Half the abuse reports bounce, and the other half are ignored. > (most of the hosts in question are in china.) it's a big problem, especially with rogue networks like france and china. there is currently zero incentive for anyone clean up, as there are no consequences for not doing so. this will not change until there are real consequences for operating IP cesspools. -Dan From nick at foobar.org Sun Aug 9 14:20:04 2009 From: nick at foobar.org (Nick Hilliard) Date: Sun, 09 Aug 2009 20:20:04 +0100 Subject: sat-3 cut? In-Reply-To: <4A7DB152.4030906@gmail.com> References: <4A721DF7.1070101@gmail.com> <4A7DB152.4030906@gmail.com> Message-ID: <4A7F2164.3080700@foobar.org> On 08/08/2009 18:09, William Allen Simpson wrote: > Not in a long time. My memory is that SAT-3 was supposed to be a nice > cooperative effort funded by the nations themselves, rather than an > outside investor. With cooperation, I'd have expected good peering. Indeed, it is a co-operative affair owned by several of the incumbent telcos along the route, and one suspects that they engage in all of the sort of benevolent, community-focussed behaviour that you'd expect from incumbents. On a more serious note, and peering / interconnection arrangements aside, the cable fault indicates a critical lack of resilience on the west coast of africa. Nick From astrodog at gmail.com Sun Aug 9 17:41:10 2009 From: astrodog at gmail.com (Astrodog) Date: Sun, 9 Aug 2009 17:41:10 -0500 Subject: ServerBeach Name Server Outage? In-Reply-To: <4A7D8A9F.2060604@aset.com> References: <4A7D8A9F.2060604@aset.com> Message-ID: <2fd864e0908091541y5915fe6fva02d54d4973e6aa@mail.gmail.com> On Sat, Aug 8, 2009 at 9:24 AM, Jon Kibler wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi, > > Is anyone else that uses ServerBeach hosting having issues with their name > servers (ns[12].geodns.net) failing to resolve their hostnames? > > Jon K I was just thinking about the irony in some asking if their DNS provider is down, via e-mail. That being said, they seem down for me, too. --- Harrison From Jon.Kibler at aset.com Sun Aug 9 18:43:00 2009 From: Jon.Kibler at aset.com (Jon Kibler) Date: Sun, 09 Aug 2009 19:43:00 -0400 Subject: ServerBeach Name Server Outage? In-Reply-To: <2fd864e0908091541y5915fe6fva02d54d4973e6aa@mail.gmail.com> References: <4A7D8A9F.2060604@aset.com> <2fd864e0908091541y5915fe6fva02d54d4973e6aa@mail.gmail.com> Message-ID: <4A7F5F04.4070200@aset.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Astrodog wrote: > On Sat, Aug 8, 2009 at 9:24 AM, Jon Kibler wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Hi, >> >> Is anyone else that uses ServerBeach hosting having issues with their name >> servers (ns[12].geodns.net) failing to resolve their hostnames? >> >> Jon K > > I was just thinking about the irony in some asking if their DNS > provider is down, via e-mail. > > That being said, they seem down for me, too. > > > --- Harrison That would normally make sense. However, Server Beach uses different name servers for its customers than it uses for itself. Jon K -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkp/XwQACgkQUVxQRc85QlObrwCgj2RkFrOwT1ok+q8xNXcrrI7K xdgAn3PDE8TWB+kNuabugwaAGCe3f/P6 =Lbja -----END PGP SIGNATURE----- ================================================== Filtered by: TRUSTEM.COM's Email Filtering Service http://www.trustem.com/ No Spam. No Viruses. Just Good Clean Email. From william.allen.simpson at gmail.com Sun Aug 9 21:09:49 2009 From: william.allen.simpson at gmail.com (William Allen Simpson) Date: Sun, 09 Aug 2009 22:09:49 -0400 Subject: sat-3 cut? In-Reply-To: <4A7F2164.3080700@foobar.org> References: <4A721DF7.1070101@gmail.com> <4A7DB152.4030906@gmail.com> <4A7F2164.3080700@foobar.org> Message-ID: <4A7F816D.4060406@gmail.com> Nick Hilliard wrote: > On 08/08/2009 18:09, William Allen Simpson wrote: >> Not in a long time. My memory is that SAT-3 was supposed to be a nice >> cooperative effort funded by the nations themselves, rather than an >> outside investor. With cooperation, I'd have expected good peering. > > Indeed, it is a co-operative affair owned by several of the incumbent > telcos along the route, and one suspects that they engage in all of the > sort of benevolent, community-focussed behaviour that you'd expect from > incumbents. > Oh, neither of us are talking about benevolence. If you and I have a joint venture, then I'd expect we'd have no problem with interconnection. > On a more serious note, and peering / interconnection arrangements > aside, the cable fault indicates a critical lack of resilience on the > west coast of africa. > True. Does NANOG have an outreach and construction program? If not, it's probably not on-topic.... From randy at psg.com Sun Aug 9 21:34:00 2009 From: randy at psg.com (Randy Bush) Date: Mon, 10 Aug 2009 11:34:00 +0900 Subject: sat-3 cut? In-Reply-To: <4A7F816D.4060406@gmail.com> References: <4A721DF7.1070101@gmail.com> <4A7DB152.4030906@gmail.com> <4A7F2164.3080700@foobar.org> <4A7F816D.4060406@gmail.com> Message-ID: > Does NANOG have an outreach and construction program? yes. informally, a fair number of nanogians have spent the last few decades doing tech transfer to the developing economies, including helping start sister groups such as afnog. nanog participates with arin in a bursary to bring engineers from developing economies to nanog and arin meetings. etc. sorry this so poorly publicized that you did not know. randy From brunner at nic-naa.net Sun Aug 9 21:50:47 2009 From: brunner at nic-naa.net (Eric Brunner-Williams) Date: Sun, 09 Aug 2009 22:50:47 -0400 Subject: sat-3 cut? In-Reply-To: References: <4A721DF7.1070101@gmail.com> <4A7DB152.4030906@gmail.com> <4A7F2164.3080700@foobar.org> <4A7F816D.4060406@gmail.com> Message-ID: <4A7F8B07.9020800@nic-naa.net> above link, and routing, at transport, there is a tld effort as well. Randy Bush wrote: >> Does NANOG have an outreach and construction program? >> > > yes. informally, a fair number of nanogians have spent the last few > decades doing tech transfer to the developing economies, including > helping start sister groups such as afnog. nanog participates with arin > in a bursary to bring engineers from developing economies to nanog and > arin meetings. etc. > > sorry this so poorly publicized that you did not know. > > randy > > > > From lsc at prgmr.com Mon Aug 10 02:49:47 2009 From: lsc at prgmr.com (Luke S Crawford) Date: 10 Aug 2009 03:49:47 -0400 Subject: Botnet hunting resources (was: Re: DOS in progress ?) In-Reply-To: References: <202705b0908060825y55b775aew9a3601fae77f9207@mail.gmail.com> Message-ID: goemon at anime.net writes: > On Fri, 8 Aug 2009, Luke S Crawford wrote: > > 1. are there people who apply pressure to ISPs to get them to shut down > > botnets, like maps did for spam? > > sadly no. ... Why do you think this might be? Fear of (extralegal) retaliation by botnet owners? or fear of getting sued by listed network owners? or is the idea (shunning packets from ISPs that host botnets) fundamentally unsound? If someone sufficiently trustworthy produced a BGP feed of networks that were unresponsive to abuse complaints, do you think other networks would use it to block traffic? I mean, ultimately I think that having several providers of such feeds with differing levels of aggression would be the best case, but someone has got to go first. -- Luke S. Crawford http://prgmr.com/xen/ - Hosting for the technically adept http://nostarch.com/xen.htm - We don't assume you are stupid. From goemon at anime.net Mon Aug 10 03:11:34 2009 From: goemon at anime.net (goemon at anime.net) Date: Mon, 10 Aug 2009 01:11:34 -0700 (PDT) Subject: Botnet hunting resources (was: Re: DOS in progress ?) In-Reply-To: References: <202705b0908060825y55b775aew9a3601fae77f9207@mail.gmail.com> Message-ID: On Mon, 10 Aug 2009, Luke S Crawford wrote: > goemon at anime.net writes: >> On Fri, 8 Aug 2009, Luke S Crawford wrote: >>> 1. are there people who apply pressure to ISPs to get them to shut down >>> botnets, like maps did for spam? >> sadly no. > ... > > Why do you think this might be? Fear of (extralegal) retaliation by > botnet owners? or fear of getting sued by listed network owners? or is > the idea (shunning packets from ISPs that host botnets) fundamentally unsound? such a list would include all of chinanet and france telecom. it would likely not last long. what do you do when rogue networks are state owned? > If someone sufficiently trustworthy produced a BGP feed of networks that > were unresponsive to abuse complaints, do you think other networks would use > it to block traffic? no. > I mean, ultimately I think that having several providers of such feeds > with differing levels of aggression would be the best case, but someone > has got to go first. consider how much time and effort it took to get intercage shut down and you'd realize it's pretty much a lost cause. -Dan From tim at pelican.org Mon Aug 10 03:16:46 2009 From: tim at pelican.org (Tim Franklin) Date: Mon, 10 Aug 2009 08:16:46 +0000 (GMT) Subject: ServerBeach Name Server Outage? In-Reply-To: <4A7D8A9F.2060604@aset.com> Message-ID: <19143268.611249892206754.JavaMail.root@jennyfur.pelican.org> > Is anyone else that uses ServerBeach hosting having issues with their name > servers (ns[12].geodns.net) failing to resolve their hostnames? I haven't seen any recent problems, although I have the geodns servers slaving from my server. Are you doing the same, or generating DNS directly on their NS (through the web front end)? Regards, Tim. From nanog at daork.net Mon Aug 10 04:34:57 2009 From: nanog at daork.net (Nathan Ward) Date: Mon, 10 Aug 2009 21:34:57 +1200 Subject: Botnet hunting resources (was: Re: DOS in progress ?) In-Reply-To: References: <202705b0908060825y55b775aew9a3601fae77f9207@mail.gmail.com> Message-ID: On 10/08/2009, at 8:11 PM, goemon at anime.net wrote: > such a list would include all of chinanet and france telecom. it > would likely not last long. You've mentioned France twice now. Is there a big botnet problem there? I've never heard of anything like that. I'll admit I don't follow this area of the network closely, but I'm sure there are other places higher up the list than FTE.. -- Nathan Ward From Jon.Kibler at aset.com Mon Aug 10 06:06:17 2009 From: Jon.Kibler at aset.com (Jon Kibler) Date: Mon, 10 Aug 2009 07:06:17 -0400 Subject: ServerBeach Name Server Outage? In-Reply-To: <19143268.611249892206754.JavaMail.root@jennyfur.pelican.org> References: <19143268.611249892206754.JavaMail.root@jennyfur.pelican.org> Message-ID: <4A7FFF29.2090208@aset.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Tim Franklin wrote: >> Is anyone else that uses ServerBeach hosting having issues with their name >> servers (ns[12].geodns.net) failing to resolve their hostnames? > > I haven't seen any recent problems, although I have the geodns servers slaving > from my server. Are you doing the same, or generating DNS directly on their NS > (through the web front end)? > > Regards, > Tim. > I am being lazy and using their servers directly. The problem has gone away. SB got back to me about 30 minutes after I opened a trouble ticket through my.sb and said, "At around 0930 this morning our DNS servers, ns1.geodns.com and ns2.geodns.com experienced an issue where name resolution was not completing. We have not as of yet identified the root cause of the issue, but services were restored shortly thereafter at around 0940. At this time, we would like to ask that you please check your services again to ensure that all is in order. If they are not, please do let us know and we will investigate further." I strongly disagree with their time frame estimates, as I saw an outage that lasted at least 55 to 60 minutes, not 10 minutes. I first observed the outage about 09:50 EDT, spent about 20 minutes investigating it and trying to verify it was not a routing issue (I checked from 9 different locations that I could not get name resolution), and another 10 minutes tracking down my password and reporting it -- at 10:20. Name services were still failing at 10:45, but were working correctly at 10:50 when I received the above message from SB. To me, it looks like that SB has a *CRITICAL* infrastructure design problem if they have a situation were both name servers can fail simultaneously. I hope this does not mean that they have a single dual-homed box that is really both name servers!! I would really want/expect them to have two physically different servers in two vastly diverse physical locations (or even better, multiple boxes hidden by anycast), but the type of failure observed tends to argue against such diversity. I hope this is a situation that SB will correct, as it is simply unacceptable to have all of one's name servers simultaneously fail. Jon K - -- Jon R. Kibler Chief Technical Officer Advanced Systems Engineering Technology, Inc. Charleston, SC USA o: 843-849-8214 c: 843-813-2924 (NEW!) s: 843-564-4224 http://www.linkedin.com/in/jonrkibler My PGP Fingerprint is: BAA2 1F2C 5543 5D25 4636 A392 515C 5045 CF39 4253 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkp//ykACgkQUVxQRc85QlNB9ACeKqHeeHTMLOE8STHffSvYLBto Yk0An2FNGMYiIReL7TgfP6ZGCyOEspBO =YyJH -----END PGP SIGNATURE----- ================================================== Filtered by: TRUSTEM.COM's Email Filtering Service http://www.trustem.com/ No Spam. No Viruses. Just Good Clean Email. From william.allen.simpson at gmail.com Mon Aug 10 07:13:55 2009 From: william.allen.simpson at gmail.com (William Allen Simpson) Date: Mon, 10 Aug 2009 08:13:55 -0400 Subject: sat-3 cut? In-Reply-To: <4A7F8B07.9020800@nic-naa.net> References: <4A721DF7.1070101@gmail.com> <4A7DB152.4030906@gmail.com> <4A7F2164.3080700@foobar.org> <4A7F816D.4060406@gmail.com> <4A7F8B07.9020800@nic-naa.net> Message-ID: <4A800F03.5000009@gmail.com> Eric Brunner-Williams wrote: > above link, and routing, at transport, there is a tld effort as well. > > Randy Bush wrote: >> yes. informally, a fair number of nanogians have spent the last few >> decades doing tech transfer to the developing economies, including >> helping start sister groups such as afnog. nanog participates with arin >> in a bursary to bring engineers from developing economies to nanog and >> arin meetings. etc. >> >> sorry this so poorly publicized that you did not know. >> It's not, and I cannot find it on our NANOG website. As you may remember, I'd helped with more formal outreach and instruction via ISoc (mid-'90s), but had not heard of the same by NANOG. OTOH, I've rarely attended any NANOG meeting outside Michigan, and we've not had one here for many years. There's one coming up in October that I'm looking forward to attending (time and finances allowing). What exactly is NANOG doing do help interconnect West Africa? Moreover, what NANOG member financing assistance to Nitel paying its fees, so that its link would be restored? From smb at cs.columbia.edu Mon Aug 10 07:21:43 2009 From: smb at cs.columbia.edu (Steven M. Bellovin) Date: Mon, 10 Aug 2009 08:21:43 -0400 Subject: sat-3 cut? In-Reply-To: <4A800F03.5000009@gmail.com> References: <4A721DF7.1070101@gmail.com> <4A7DB152.4030906@gmail.com> <4A7F2164.3080700@foobar.org> <4A7F816D.4060406@gmail.com> <4A7F8B07.9020800@nic-naa.net> <4A800F03.5000009@gmail.com> Message-ID: <20090810082143.39f641ce@cs.columbia.edu> On that note, folks might want to see http://www.nytimes.com/2009/08/10/business/global/10cable.html From jared at puck.nether.net Mon Aug 10 07:24:19 2009 From: jared at puck.nether.net (Jared Mauch) Date: Mon, 10 Aug 2009 08:24:19 -0400 Subject: Botnet hunting resources (was: Re: DOS in progress ?) In-Reply-To: References: <202705b0908060825y55b775aew9a3601fae77f9207@mail.gmail.com> Message-ID: <52CB08C8-4382-4FEB-965C-64C7BB6EDBD1@puck.nether.net> On Aug 10, 2009, at 5:34 AM, Nathan Ward wrote: > On 10/08/2009, at 8:11 PM, goemon at anime.net wrote: >> such a list would include all of chinanet and france telecom. it >> would likely not last long. > > You've mentioned France twice now. Is there a big botnet problem > there? I've never heard of anything like that. > I'll admit I don't follow this area of the network closely, but I'm > sure there are other places higher up the list than FTE.. I would say the problem plagues many diverse networks. The background radiation goes undetected by most people for cost reasons. It's cheaper to pass the bits then have a human convince someone their machine is compromised. The problem will continue to be acute as transit costs get even lower. - Jared From randy at psg.com Mon Aug 10 07:49:51 2009 From: randy at psg.com (Randy Bush) Date: Mon, 10 Aug 2009 21:49:51 +0900 Subject: sat-3 cut? In-Reply-To: <20090810082143.39f641ce@cs.columbia.edu> References: <4A721DF7.1070101@gmail.com> <4A7DB152.4030906@gmail.com> <4A7F2164.3080700@foobar.org> <4A7F816D.4060406@gmail.com> <4A7F8B07.9020800@nic-naa.net> <4A800F03.5000009@gmail.com> <20090810082143.39f641ce@cs.columbia.edu> Message-ID: > http://www.nytimes.com/2009/08/10/business/global/10cable.html if seacom completes, and it is looking likely (yay!), this will be great. but Alan Mauldin, research director at TeleGeography, a telecommunications market research company, said Africa was the last major area where broadband access was not widespread. try much of the pacific islands, central asia (the stans), myanmar, much of india, laos, cambodia, and large swaths of northern china and the middle of russia. and i am sticking to places with non-sparse population. americans are a bit naive about the rest of the world. randy From bmanning at vacation.karoshi.com Mon Aug 10 07:57:21 2009 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Mon, 10 Aug 2009 12:57:21 +0000 Subject: sat-3 cut? In-Reply-To: References: <4A721DF7.1070101@gmail.com> <4A7DB152.4030906@gmail.com> <4A7F2164.3080700@foobar.org> <4A7F816D.4060406@gmail.com> <4A7F8B07.9020800@nic-naa.net> <4A800F03.5000009@gmail.com> <20090810082143.39f641ce@cs.columbia.edu> Message-ID: <20090810125721.GB27939@vacation.karoshi.com.> On Mon, Aug 10, 2009 at 09:49:51PM +0900, Randy Bush wrote: > > http://www.nytimes.com/2009/08/10/business/global/10cable.html > > if seacom completes, and it is looking likely (yay!), this will be great. > but > > Alan Mauldin, research director at TeleGeography, a telecommunications > market research company, said Africa was the last major area where > broadband access was not widespread. > > try much of the pacific islands, central asia (the stans), myanmar, much of > india, laos, cambodia, and large swaths of northern china and the middle of > russia. and i am sticking to places with non-sparse population. > > americans are a bit naive about the rest of the world. > > randy clearly Alan's whole point rests on the interpretation of the two words -major- and -area-... and no, we will not stoop to using the US definition of broadband. --bill From nanog-post at rsuc.gweep.net Mon Aug 10 09:49:47 2009 From: nanog-post at rsuc.gweep.net (Joe Provo) Date: Mon, 10 Aug 2009 10:49:47 -0400 Subject: sat-3 cut? In-Reply-To: <4A800F03.5000009@gmail.com> References: <4A721DF7.1070101@gmail.com> <4A7DB152.4030906@gmail.com> <4A7F2164.3080700@foobar.org> <4A7F816D.4060406@gmail.com> <4A7F8B07.9020800@nic-naa.net> <4A800F03.5000009@gmail.com> Message-ID: <20090810144947.GA10446@gweep.net> [Followups set to futures as organization discussion.] On Mon, Aug 10, 2009 at 08:13:55AM -0400, William Allen Simpson wrote: > Eric Brunner-Williams wrote: > >above link, and routing, at transport, there is a tld effort as well. > > > >Randy Bush wrote: > >>yes. informally, a fair number of nanogians have spent the last few > >>decades doing tech transfer to the developing economies, including > >>helping start sister groups such as afnog. nanog participates with arin > >>in a bursary to bring engineers from developing economies to nanog and > >>arin meetings. etc. > >> > >>sorry this so poorly publicized that you did not know. > >> > It's not, and I cannot find it on our NANOG website. As you may remember, > I'd helped with more formal outreach and instruction via ISoc (mid-'90s), > but had not heard of the same by NANOG. It currently goes by the somewhat confusing moniker of a scholarship, right there on the pull-downs on every page of the site. The Postel Network Operator's Scholarship does get promoted widely and applicants are sought from other ops communities across the globe. Unfortunately for those not plugged into the physical meetings, it hasn't actually been promoted on nanog-announce, etc in the past. That will definitely get rectified. Cheers, Joe -- RSUC / GweepNet / Spunk / FnB / Usenix / SAGE From tomb at byrneit.net Mon Aug 10 10:49:55 2009 From: tomb at byrneit.net (Tomas L. Byrnes) Date: Mon, 10 Aug 2009 08:49:55 -0700 Subject: Botnet hunting resources (was: Re: DOS in progress ?) In-Reply-To: References: <202705b0908060825y55b775aew9a3601fae77f9207@mail.gmail.com> Message-ID: <70D072392E56884193E3D2DE09C097A91F449B@pascal.zaphodb.org> >Why do you think this might be? Fear of (extralegal) retaliation by >botnet owners? or fear of getting sued by listed network owners? [TLB:] No more than any anti-spam RBL or >is >the idea (shunning packets from ISPs that host botnets) fundamentally >unsound? > [TLB:] That's an ongoing raging debate. Some say, since enumerating badness cant' protect you against all threats, that you shouldn't' do it at all. My take is, if you can filter the worst actors early and fast, based on IP address, that gives you deeper packet devices more capacity, and saves you network bandwidth. It's been my experience that IP level blocking is a best practice as the second step (the first being selective availability of any service to only those it NEEDS to be, which in the case of many network operators is everywhere and everyone, and therefore a useless filter for a network operator) in a layered defense. >If someone sufficiently trustworthy produced a BGP feed of networks that >were unresponsive to abuse complaints, do you think other networks would >use >it to block traffic? I mean, ultimately I think that having several >providers of such feeds with differing levels of aggression would be the >best >case, but someone has got to go first. > > [TLB:] That's what ThreatSTOP is for. We use DNS, not BGP, because there are far more traffic management devices (think Subscriber firewalls) that can use it, and because AT&T has a patent on using BGP for block lists. From dotis at mail-abuse.org Mon Aug 10 12:57:36 2009 From: dotis at mail-abuse.org (Douglas Otis) Date: Mon, 10 Aug 2009 10:57:36 -0700 Subject: DNS hardening, was Re: Dan Kaminsky In-Reply-To: <20090807224105.62dfb659@cs.columbia.edu> References: <20090805164823.43774.qmail@simone.iecc.com> <4A79CB90.708@mail-abuse.org> <90CEC867-A870-4E45-AFC2-898AD655699E@arbor.net> <4A79F8A3.9040302@mail-abuse.org> <75cb24520908051449n29c53491m90fd021022d9816f@mail.gmail.com> <4A7A0D6C.90808@mail-abuse.org> <75cb24520908051853t6c0f05d3l94c404d3227d191c@mail.gmail.com> <20090807224105.62dfb659@cs.columbia.edu> Message-ID: <4A805F90.90107@mail-abuse.org> This was responded to on the DNSEXT mailing list. Sorry, but your question was accidentally attributed to Paul who forwarded the message. DNSEXT Archive: http://ops.ietf.org/lists/namedroppers/ -Doug From alexb at ripe.net Mon Aug 10 13:48:30 2009 From: alexb at ripe.net (Alex Band) Date: Mon, 10 Aug 2009 20:48:30 +0200 Subject: IPv6 Interview: Martin J. Levy of Hurricane Electric Message-ID: http://www.youtube.com/watch?v=p47m5XVt4WQ Time for another interview. Martin Levy talks about his experiences, what kind of customers they cater to, what worked and what didn't work during deployment, and what internal strategy they had. We recorded an interview with the Swedish government this week, which we'll be editing shortly. If you want specific topics to be covered, or there are specific people or industry players we should talk to in future interviews, please let me know and we'll try to get them in front of a camera. Enjoy, Alex From martin at theicelandguy.com Mon Aug 10 18:24:17 2009 From: martin at theicelandguy.com (Martin Hannigan) Date: Mon, 10 Aug 2009 19:24:17 -0400 Subject: sat-3 cut? In-Reply-To: References: <4A7DB152.4030906@gmail.com> <4A7F2164.3080700@foobar.org> <4A7F816D.4060406@gmail.com> <4A7F8B07.9020800@nic-naa.net> <4A800F03.5000009@gmail.com> <20090810082143.39f641ce@cs.columbia.edu> Message-ID: On Mon, Aug 10, 2009 at 8:49 AM, Randy Bush wrote: > americans are a bit naive about the rest of the world Not the Americans who provided a large chunk of capital and are managing SEACOM. Short summary: The operator is anticipating that South Africa and Kenya alone are going to utilize 85% of the capacity. The design capacity of the cable (The maximum saleable amount of bandwidth) is 1.28 Tb/s. The rest of the capacity is within reach of oil and some Francophone countries. Tata is buying capacity on the Mumbai to Djibouti leg which will interconnect them to both EASSY and SEACOM. EASSY and SEACOM are sharing landing stations in a few high value locations. All very commercial and not so uncommon. The only question I have is a context switch. Why Mogadishu? Do the (sea) pirates need more capacity to manage their ship hijacking business? Best Regards, Martin -- Martin Hannigan martin at theicelandguy.com p: +16178216079 Power, Network, and Costs Consulting for Iceland Datacenters and Occupants From jdfalk-lists at cybernothing.org Mon Aug 10 18:24:11 2009 From: jdfalk-lists at cybernothing.org (J.D. Falk) Date: Mon, 10 Aug 2009 17:24:11 -0600 Subject: Botnet hunting resources In-Reply-To: References: <202705b0908060825y55b775aew9a3601fae77f9207@mail.gmail.com> Message-ID: <4A80AC1B.6050602@cybernothing.org> Luke S Crawford wrote: > 1. are there people who apply pressure to ISPs to get them to shut down > botnets, like maps did for spam? Hi, Luke! MAAWG recently published a document to help ISPs deal with infected machines in their networks. It's not the same kind of pressure, but (as we learned with open relays at MAPS) pressure isn't very effective unless there are tools available to deal with the problem. http://www.maawg.org/about/publishedDocuments/MAAWG_Bot_Mitigation_BP_2007-07.pdf -- J.D. Falk Return Path Inc http://www.returnpath.net/ From nick at foobar.org Mon Aug 10 18:39:35 2009 From: nick at foobar.org (Nick Hilliard) Date: Tue, 11 Aug 2009 00:39:35 +0100 Subject: sat-3 cut? In-Reply-To: References: <4A7DB152.4030906@gmail.com> <4A7F2164.3080700@foobar.org> <4A7F816D.4060406@gmail.com> <4A7F8B07.9020800@nic-naa.net> <4A800F03.5000009@gmail.com> <20090810082143.39f641ce@cs.columbia.edu> Message-ID: <4A80AFB7.9080404@foobar.org> On 11/08/2009 00:24, Martin Hannigan wrote: > The only question I have is a context switch. Why Mogadishu? Do the (sea) > pirates need more capacity to manage their ship hijacking business? The indications are that Somalia has been improving over the past year or two. If this continues, then it may have a reconstructive capacity to grow which other countries don't. Nick From joelja at bogus.com Mon Aug 10 18:47:00 2009 From: joelja at bogus.com (Joel Jaeggli) Date: Mon, 10 Aug 2009 16:47:00 -0700 Subject: sat-3 cut? In-Reply-To: References: <4A7DB152.4030906@gmail.com> <4A7F2164.3080700@foobar.org> <4A7F816D.4060406@gmail.com> <4A7F8B07.9020800@nic-naa.net> <4A800F03.5000009@gmail.com> <20090810082143.39f641ce@cs.columbia.edu> Message-ID: <4A80B174.8010908@bogus.com> Martin Hannigan wrote: > The only question I have is a context switch. Why Mogadishu? Do the (sea) > pirates need more capacity to manage their ship hijacking business? Because ethiopia is the effectively land-locked economic power in the neighborhood and it needs diverse landing sites. Also I think Mogadishu is off the table for the moment. > > Best Regards, > > Martin > From jbates at brightok.net Tue Aug 11 08:11:26 2009 From: jbates at brightok.net (Jack Bates) Date: Tue, 11 Aug 2009 08:11:26 -0500 Subject: Botnet hunting resources In-Reply-To: <4A80AC1B.6050602@cybernothing.org> References: <202705b0908060825y55b775aew9a3601fae77f9207@mail.gmail.com> <4A80AC1B.6050602@cybernothing.org> Message-ID: <4A816DFE.7000703@brightok.net> J.D. Falk wrote: > Hi, Luke! MAAWG recently published a document to help ISPs deal with > infected machines in their networks. It's not the same kind of > pressure, but (as we learned with open relays at MAPS) pressure isn't > very effective unless there are tools available to deal with the problem. It could also use a lot more resources? Watching traffic flows for traffic destined to known C&C addresses is nice, but including a pointer to a resource that actually gives those addresses is much more useful. For those who don't deal with it every day, the document just says they need to spend even more time with google. Jack From bradley.freeman at csirt.ja.net Tue Aug 11 08:36:51 2009 From: bradley.freeman at csirt.ja.net (Bradley Freeman) Date: Tue, 11 Aug 2009 14:36:51 +0100 Subject: Botnet hunting resources In-Reply-To: <4A816DFE.7000703@brightok.net> References: <202705b0908060825y55b775aew9a3601fae77f9207@mail.gmail.com> <4A80AC1B.6050602@cybernothing.org> <4A816DFE.7000703@brightok.net> Message-ID: <00c901ca1a88$c8a59650$59f0c2f0$@freeman@csirt.ja.net> I surprised that nobody has mentioned the work of shadowserver.org, they are able to send reports of malware infections on your networks (see http://www.shadowserver.org/wiki/pmwiki.php/Services/Reports). The service has proved to a brilliant tool in mitigating various forms of malware such as Conficker with almost 0% false positives. Cheers Bradley -----Original Message----- From: Jack Bates [mailto:jbates at brightok.net] Sent: 11 August 2009 14:11 To: J.D. Falk Cc: NANOG Subject: Re: Botnet hunting resources J.D. Falk wrote: > Hi, Luke! MAAWG recently published a document to help ISPs deal with > infected machines in their networks. It's not the same kind of > pressure, but (as we learned with open relays at MAPS) pressure isn't > very effective unless there are tools available to deal with the problem. It could also use a lot more resources? Watching traffic flows for traffic destined to known C&C addresses is nice, but including a pointer to a resource that actually gives those addresses is much more useful. For those who don't deal with it every day, the document just says they need to spend even more time with google. Jack From braaen at zcorum.com Tue Aug 11 08:46:47 2009 From: braaen at zcorum.com (Brian Raaen) Date: Tue, 11 Aug 2009 09:46:47 -0400 Subject: Setting Up SNMP on a C9 C2000 CMTS Message-ID: <4A817647.7080600@zcorum.com> I am pulling my hair out trying to do this. According to the spec sheets on c9networks website, the device is capable of SNMP management, only I can not find anywhere in the interface to set up the community strings. Does anyone have any resources on how this would be done. Thanks -- ----------------- Brian Raaen Network Engineer email: /braaen at zcorum.com/ -------------- next part -------------- A non-text attachment was scrubbed... Name: braaen.vcf Type: text/x-vcard Size: 206 bytes Desc: not available URL: From setient at gmail.com Tue Aug 11 10:25:52 2009 From: setient at gmail.com (Ronald Cotoni) Date: Tue, 11 Aug 2009 10:25:52 -0500 Subject: Can someone from earthlink contact me offlist Message-ID: <2f1d68350908110825y35c75d73x101464dbbf905566@mail.gmail.com> I need to talk to someone at earthlink who is a mail administrator? From ken.gilmour at gmail.com Tue Aug 11 11:17:44 2009 From: ken.gilmour at gmail.com (Ken Gilmour) Date: Tue, 11 Aug 2009 10:17:44 -0600 Subject: Level 3 Contact Message-ID: <5b6f80200908110917l3b68f022wfc06114f26c03330@mail.gmail.com> Good morning, Could someone from Level3 who manages IPv6 Peering please contact me offlist? I am have tried to call Customer services numerous times and every time they attempt to transfer me to the appropriate person, the call is dropped. Thanks! Ken From dwhite at olp.net Tue Aug 11 11:27:27 2009 From: dwhite at olp.net (Dan White) Date: Tue, 11 Aug 2009 11:27:27 -0500 Subject: Level 3 Contact In-Reply-To: <5b6f80200908110917l3b68f022wfc06114f26c03330@mail.gmail.com> References: <5b6f80200908110917l3b68f022wfc06114f26c03330@mail.gmail.com> Message-ID: <20090811162727.GD9247@dan.olp.net> You can reach their IPv6 group via email at DL-IPV6-Support at Level3.com. On 11/08/09?10:17?-0600, Ken Gilmour wrote: >Good morning, > >Could someone from Level3 who manages IPv6 Peering please contact me >offlist? I am have tried to call Customer services numerous times and >every time they attempt to transfer me to the appropriate person, the >call is dropped. > >Thanks! > >Ken > -- Dan White BTC Broadband Ph 918.366.0248 (direct) main: (918)366-8000 Fax 918.366.6610 email: dwhite at olp.net http://www.btcbroadband.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Digital signature URL: From jdfalk-lists at cybernothing.org Tue Aug 11 12:52:46 2009 From: jdfalk-lists at cybernothing.org (J.D. Falk) Date: Tue, 11 Aug 2009 11:52:46 -0600 Subject: Botnet hunting resources In-Reply-To: <4A816DFE.7000703@brightok.net> References: <202705b0908060825y55b775aew9a3601fae77f9207@mail.gmail.com> <4A80AC1B.6050602@cybernothing.org> <4A816DFE.7000703@brightok.net> Message-ID: <4A81AFEE.2040405@cybernothing.org> Jack Bates wrote: > J.D. Falk wrote: >> Hi, Luke! MAAWG recently published a document to help ISPs deal with >> infected machines in their networks. It's not the same kind of >> pressure, but (as we learned with open relays at MAPS) pressure isn't >> very effective unless there are tools available to deal with the problem. > > It could also use a lot more resources? Watching traffic flows for > traffic destined to known C&C addresses is nice, but including a pointer > to a resource that actually gives those addresses is much more useful. > For those who don't deal with it every day, the document just says they > need to spend even more time with google. I'll share your comments with the document authors. They're treating it as a living document, with updates expected regularly. -- J.D. Falk Return Path Inc http://www.returnpath.net/ From tomb at byrneit.net Tue Aug 11 12:56:35 2009 From: tomb at byrneit.net (Tomas L. Byrnes) Date: Tue, 11 Aug 2009 10:56:35 -0700 Subject: Botnet hunting resources In-Reply-To: <00c901ca1a88$c8a59650$59f0c2f0$@freeman@csirt.ja.net> References: <202705b0908060825y55b775aew9a3601fae77f9207@mail.gmail.com> <4A80AC1B.6050602@cybernothing.org><4A816DFE.7000703@brightok.net> <00c901ca1a88$c8a59650$59f0c2f0$@freeman@csirt.ja.net> Message-ID: <70D072392E56884193E3D2DE09C097A91F44A0@pascal.zaphodb.org> >-----Original Message----- >From: Bradley Freeman [mailto:bradley.freeman at csirt.ja.net] >Sent: Tuesday, August 11, 2009 6:37 AM >To: 'NANOG' >Subject: RE: Botnet hunting resources > >I surprised that nobody has mentioned the work of shadowserver.org, they >are >able to send reports of malware infections on your networks (see >http://www.shadowserver.org/wiki/pmwiki.php/Services/Reports). The >service >has proved to a brilliant tool in mitigating various forms of malware >such >as Conficker with almost 0% false positives. > >Cheers > [TLB:] ThreatSTOP are a Shadowserver partner, and they, along with the Cyber_TA project @ SRI, are the source of our botnet C&C block list. From sjk at sleepycatz.com Tue Aug 11 19:10:49 2009 From: sjk at sleepycatz.com (sjk) Date: Tue, 11 Aug 2009 19:10:49 -0500 Subject: Residential BW Planning Message-ID: <4A820889.6080906@sleepycatz.com> I am trying to perform some capacity planning for some of our residential pops, but the old calcs I used to use seem useless -- as they were adapted from the dialup days and relied upon a percentage of users online (~50%) and a percentage of concurrent transmission (~19%). My present scenario involves a micro-pop terminating 250 residences where users are expecting 4 mb/s. So I am looking for some baseline to begin at, so I am wondering what others are doing. Any thoughts are appreciated. Thanks --steve From frnkblk at iname.com Tue Aug 11 22:06:04 2009 From: frnkblk at iname.com (Frank Bulk) Date: Tue, 11 Aug 2009 22:06:04 -0500 Subject: Residential BW Planning In-Reply-To: <4A820889.6080906@sleepycatz.com> References: <4A820889.6080906@sleepycatz.com> Message-ID: We have calculated our customers peak b/w usage between 20 and 60 kbps/user, spread across a wide variety of users and wide range of speeds (128/128 up to 15000/1000 kbps). You only need a few heavy users to skew things. But 400 at 4 Mbps would make me think that 20 to 30 Mbps would be sufficient. Frank -----Original Message----- From: sjk [mailto:sjk at sleepycatz.com] Sent: Tuesday, August 11, 2009 7:11 PM To: nanog at nanog.org Subject: Residential BW Planning I am trying to perform some capacity planning for some of our residential pops, but the old calcs I used to use seem useless -- as they were adapted from the dialup days and relied upon a percentage of users online (~50%) and a percentage of concurrent transmission (~19%). My present scenario involves a micro-pop terminating 250 residences where users are expecting 4 mb/s. So I am looking for some baseline to begin at, so I am wondering what others are doing. Any thoughts are appreciated. Thanks --steve From hectorherrera at gmail.com Tue Aug 11 23:25:10 2009 From: hectorherrera at gmail.com (Hector Herrera) Date: Tue, 11 Aug 2009 21:25:10 -0700 Subject: Residential BW Planning In-Reply-To: References: <4A820889.6080906@sleepycatz.com> Message-ID: I had a very educational experience with an ISP that provides two choices to their customers: a) pay as you go (per GB charge with a token monthly fee for keeping the port active) and b) 150GB per month "unlimited" package Both packages were priced with the intent to have the same cost for customers with similar usage. After 1 year and about 2000 customers in each package, we found that the average consumption was 0.2 Mbps per customer in a) and 0.35 Mbps per customer in b) Hope that helps. Hector From gaurab at lahai.com Wed Aug 12 01:00:41 2009 From: gaurab at lahai.com (Gaurab Raj Upadhaya) Date: Wed, 12 Aug 2009 07:00:41 +0100 Subject: Another fiber cut near Taiwan ? due to Typhoon Morakot ? Message-ID: <4A825A89.9080501@lahai.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Anyone in the know ? I can't find any published reports, but multiple internal reports of massive congestions from South Asian region to the US, and failure alarms. Given that Typhoon Morakot made landfall near Taiwan yesterday, this could impact APCN2, C2C, EAC, SMW3 amongst others. any updates are appreciated. - -gaurab -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkqCWokACgkQSo7fU26F3X1lcQCeIC1V9cuiFTvBW1NPire1DMlh CP0AoMJaXrKVllZnsSX3vHfCP6nN1oAl =1xDM -----END PGP SIGNATURE----- From ethern at ascc.net Wed Aug 12 01:08:37 2009 From: ethern at ascc.net (Ethern M., Lin) Date: Wed, 12 Aug 2009 14:08:37 +0800 Subject: Another fiber cut near Taiwan ? due to Typhoon Morakot ? In-Reply-To: <4A825A89.9080501@lahai.com> References: <4A825A89.9080501@lahai.com> Message-ID: <8582c31a0908112308v37c1ef82n9a214cceab4f5f4@mail.gmail.com> Hi Gaurab, How are you? Thank you for your help to install I-root. Actually I don't hear any damage info about submarine cable in Taiwan, and it seems fine from Taiwan to Internet now. cheers, Ethern ============================= Ethern Lin Network Division Computing Center, ACADEMIA SINICA Phone: +886-2-2789-9953 Fax : +886-2-2783-6444 ============================= On Wed, Aug 12, 2009 at 2:00 PM, Gaurab Raj Upadhaya wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Anyone in the know ? > > I can't find any published reports, but multiple internal reports of > massive congestions from South Asian region to the US, and failure alarms. > > Given that Typhoon Morakot made landfall near Taiwan yesterday, this > could impact APCN2, C2C, EAC, SMW3 amongst others. > > any updates are appreciated. > > - -gaurab > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.8 (Darwin) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEYEARECAAYFAkqCWokACgkQSo7fU26F3X1lcQCeIC1V9cuiFTvBW1NPire1DMlh > CP0AoMJaXrKVllZnsSX3vHfCP6nN1oAl > =1xDM > -----END PGP SIGNATURE----- > > From scott at doc.net.au Wed Aug 12 01:16:10 2009 From: scott at doc.net.au (Scott Howard) Date: Tue, 11 Aug 2009 23:16:10 -0700 Subject: Another fiber cut near Taiwan ? due to Typhoon Morakot ? In-Reply-To: <4A825A89.9080501@lahai.com> References: <4A825A89.9080501@lahai.com> Message-ID: I'm seeing high latency and some packet loss via multiple providers from the US to Singapore, matching what we saw a few days ago although not as bad (ie, packet loss is only about 5%, down from the 40% we were seeing a few days ago). At that time the cause was a cable fault somewhere in/near Japan, but at this stage I'm not sure if this is the same problem or not. Scott. On Tue, Aug 11, 2009 at 11:00 PM, Gaurab Raj Upadhaya wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Anyone in the know ? > > I can't find any published reports, but multiple internal reports of > massive congestions from South Asian region to the US, and failure alarms. > > Given that Typhoon Morakot made landfall near Taiwan yesterday, this > could impact APCN2, C2C, EAC, SMW3 amongst others. > > any updates are appreciated. > > - -gaurab > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.8 (Darwin) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEYEARECAAYFAkqCWokACgkQSo7fU26F3X1lcQCeIC1V9cuiFTvBW1NPire1DMlh > CP0AoMJaXrKVllZnsSX3vHfCP6nN1oAl > =1xDM > -----END PGP SIGNATURE----- > > From gaurab at lahai.com Wed Aug 12 02:00:58 2009 From: gaurab at lahai.com (Gaurab Raj Upadhaya) Date: Wed, 12 Aug 2009 08:00:58 +0100 Subject: Another fiber cut near Taiwan ? due to Typhoon Morakot ? In-Reply-To: References: <4A825A89.9080501@lahai.com> Message-ID: <4A8268AA.2000708@lahai.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Scott Howard wrote: > At that time the cause was a cable fault somewhere in/near Japan, but at > this stage I'm not sure if this is the same problem or not. > Now confirmed that APCN2, C2C and EAC are cut. also unconfirmed reports of SMW2 and SWM3 are out. FLAG and TGN seems to be not had any issues so far. It seems at this point, the fault is more on the South China Sea and the alarms I got seem to confirm that. For the geography, see http://en.wikipedia.org/wiki/File:South_China_Sea.jpg Circuits from Japan to SG, TH, PH are down, but not to HK. My perspective, yours may vary. - -gaurab -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkqCaKoACgkQSo7fU26F3X2u5ACg7Hpy9jVwHNzdDTWI6wSu4Qyh TiMAn21dcEPKOqkdlQN9rQLFz+NypgID =DKT6 -----END PGP SIGNATURE----- From pstewart at nexicomgroup.net Wed Aug 12 07:54:13 2009 From: pstewart at nexicomgroup.net (Paul Stewart) Date: Wed, 12 Aug 2009 08:54:13 -0400 Subject: Residential BW Planning In-Reply-To: References: <4A820889.6080906@sleepycatz.com> Message-ID: This may have changed a bit - but we used to use 2000 high speed = 100 meg of capacity. Based on 5000/800 ADSL or 8000/1000 cable modem profiles mainly... Paul -----Original Message----- From: Frank Bulk [mailto:frnkblk at iname.com] Sent: Tuesday, August 11, 2009 11:06 PM To: 'sjk'; nanog at nanog.org Subject: RE: Residential BW Planning We have calculated our customers peak b/w usage between 20 and 60 kbps/user, spread across a wide variety of users and wide range of speeds (128/128 up to 15000/1000 kbps). You only need a few heavy users to skew things. But 400 at 4 Mbps would make me think that 20 to 30 Mbps would be sufficient. Frank -----Original Message----- From: sjk [mailto:sjk at sleepycatz.com] Sent: Tuesday, August 11, 2009 7:11 PM To: nanog at nanog.org Subject: Residential BW Planning I am trying to perform some capacity planning for some of our residential pops, but the old calcs I used to use seem useless -- as they were adapted from the dialup days and relied upon a percentage of users online (~50%) and a percentage of concurrent transmission (~19%). My present scenario involves a micro-pop terminating 250 residences where users are expecting 4 mb/s. So I am looking for some baseline to begin at, so I am wondering what others are doing. Any thoughts are appreciated. Thanks --steve ---------------------------------------------------------------------------- "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 jbates at brightok.net Wed Aug 12 07:56:31 2009 From: jbates at brightok.net (Jack Bates) Date: Wed, 12 Aug 2009 07:56:31 -0500 Subject: Residential BW Planning In-Reply-To: References: <4A820889.6080906@sleepycatz.com> Message-ID: <4A82BBFF.9040408@brightok.net> Hector Herrera wrote: > After 1 year and about 2000 customers in each package, we found that > the average consumption was 0.2 Mbps per customer in a) and 0.35 Mbps > per customer in b) Although it's wise to plan for peak average, and depending on your service levels, keep enough cover room (though redundancy may provide that cover room for you) for the massive events. Jack From drew.weaver at thenap.com Wed Aug 12 08:51:39 2009 From: drew.weaver at thenap.com (Drew Weaver) Date: Wed, 12 Aug 2009 09:51:39 -0400 Subject: Anyone have a highly available SAAVIS network contact? Message-ID: Off-list, please. Thanks, -Drew From drew.weaver at thenap.com Wed Aug 12 08:57:48 2009 From: drew.weaver at thenap.com (Drew Weaver) Date: Wed, 12 Aug 2009 09:57:48 -0400 Subject: Follow up to previous post regarding SAAVIS Message-ID: Anyone know why SAAVIS would be allowing PEER1 (AS 13768) to advertise routes for whatever IP addresses they want? route-views.oregon-ix.net>sh ip bgp 173.45.110.0 | i 13768 2905 701 3561 13768 1221 4637 3561 13768 3549 3561 13768 3277 3267 174 3561 13768 6539 3561 13768 16150 3549 3561 13768 701 3561 13768 3267 174 3561 13768 6453 3561 13768 3582 3701 3356 3561 13768 This is probably a fairly major problem... -Drew From morrowc.lists at gmail.com Wed Aug 12 09:09:08 2009 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Wed, 12 Aug 2009 10:09:08 -0400 Subject: Follow up to previous post regarding SAAVIS In-Reply-To: References: Message-ID: <75cb24520908120709u26dddeacs6dd0d4241d40f8e1@mail.gmail.com> On Wed, Aug 12, 2009 at 9:57 AM, Drew Weaver wrote: > Anyone know why SAAVIS would be allowing PEER1 (AS 13768) to advertise routes for whatever IP addresses they want? sadly savvis didn't learn the pccw lesson, which is also the turk-telecom lesson which is also the as7007 lesson which is... fairly sad really in 2009. for the sake of $diety put a prefix-filter on your customer bgp sessions, it ain't hard! -chris > route-views.oregon-ix.net>sh ip bgp 173.45.110.0 | i 13768 > ?2905 701 3561 13768 > ?1221 4637 3561 13768 > ?3549 3561 13768 > ?3277 3267 174 3561 13768 > ?6539 3561 13768 > ?16150 3549 3561 13768 > ?701 3561 13768 > ?3267 174 3561 13768 > ?6453 3561 13768 > ?3582 3701 3356 3561 13768 > > This is probably a fairly major problem... > > -Drew > > From ken.gilmour at gmail.com Wed Aug 12 09:14:57 2009 From: ken.gilmour at gmail.com (Ken Gilmour) Date: Wed, 12 Aug 2009 08:14:57 -0600 Subject: Another fiber cut near Taiwan ? due to Typhoon Morakot ? In-Reply-To: <4A8268AA.2000708@lahai.com> References: <4A825A89.9080501@lahai.com> <4A8268AA.2000708@lahai.com> Message-ID: <5b6f80200908120714l686392b4w8a4de4f2fb41cc42@mail.gmail.com> I just chatted to my contact in SG (over Instant Messenger) who said they barely even noticed a problem. The provider is Star Hub. 2009/8/12 Gaurab Raj Upadhaya : > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Scott Howard wrote: > >> At that time the cause was a cable fault somewhere in/near Japan, but at >> this stage I'm not sure if this is the same problem or not. >> > > Now confirmed that APCN2, C2C and EAC are cut. also unconfirmed reports > of SMW2 and SWM3 are out. ?FLAG and TGN seems to be not had any issues > so far. > > It seems at this point, the fault is more on the South China Sea and the > alarms I got seem to confirm that. For the geography, see > http://en.wikipedia.org/wiki/File:South_China_Sea.jpg > > Circuits from Japan to SG, TH, PH are down, but not to HK. My > perspective, yours may vary. > > - -gaurab > > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.8 (Darwin) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEYEARECAAYFAkqCaKoACgkQSo7fU26F3X2u5ACg7Hpy9jVwHNzdDTWI6wSu4Qyh > TiMAn21dcEPKOqkdlQN9rQLFz+NypgID > =DKT6 > -----END PGP SIGNATURE----- > > From jmaimon at ttec.com Wed Aug 12 09:30:10 2009 From: jmaimon at ttec.com (Joe Maimon) Date: Wed, 12 Aug 2009 10:30:10 -0400 Subject: Residential BW Planning In-Reply-To: References: <4A820889.6080906@sleepycatz.com> Message-ID: <4A82D1F2.1010101@ttec.com> Hector Herrera wrote: > > After 1 year and about 2000 customers in each package, we found that > the average consumption was 0.2 Mbps per customer in a) and 0.35 Mbps > per customer in b) 4000 residential customers at an average of 1.1Gbps? Wonder what the 95th looked like. Seems a bit high. > > Hope that helps. > > Hector > > From ethern at ascc.net Wed Aug 12 09:54:12 2009 From: ethern at ascc.net (Ethern M., Lin) Date: Wed, 12 Aug 2009 22:54:12 +0800 Subject: Another fiber cut near Taiwan ? due to Typhoon Morakot ? In-Reply-To: <5b6f80200908120714l686392b4w8a4de4f2fb41cc42@mail.gmail.com> References: <4A825A89.9080501@lahai.com> <4A8268AA.2000708@lahai.com> <5b6f80200908120714l686392b4w8a4de4f2fb41cc42@mail.gmail.com> Message-ID: <8582c31a0908120754u45b6918rc1a8f0bbfed8ecbb@mail.gmail.com> Update: The submarine cable down first is EAC since 8/9. FNAL down today(8/12). The cause might be typhone Morakot. Hongkong seems the most critical impact by these cable down. cheers, Ethern ============================= Ethern Lin Network Division Computing Center, ACADEMIA SINICA Phone: +886-2-2789-9953 Fax : +886-2-2783-6444 ============================= On Wed, Aug 12, 2009 at 10:14 PM, Ken Gilmour wrote: > I just chatted to my contact in SG (over Instant Messenger) who said > they barely even noticed a problem. The provider is Star Hub. > > 2009/8/12 Gaurab Raj Upadhaya : >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Scott Howard wrote: >> >>> At that time the cause was a cable fault somewhere in/near Japan, but at >>> this stage I'm not sure if this is the same problem or not. >>> >> >> Now confirmed that APCN2, C2C and EAC are cut. also unconfirmed reports >> of SMW2 and SWM3 are out. ?FLAG and TGN seems to be not had any issues >> so far. >> >> It seems at this point, the fault is more on the South China Sea and the >> alarms I got seem to confirm that. For the geography, see >> http://en.wikipedia.org/wiki/File:South_China_Sea.jpg >> >> Circuits from Japan to SG, TH, PH are down, but not to HK. My >> perspective, yours may vary. >> >> - -gaurab >> >> >> >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG v1.4.8 (Darwin) >> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ >> >> iEYEARECAAYFAkqCaKoACgkQSo7fU26F3X2u5ACg7Hpy9jVwHNzdDTWI6wSu4Qyh >> TiMAn21dcEPKOqkdlQN9rQLFz+NypgID >> =DKT6 >> -----END PGP SIGNATURE----- >> >> > > From dhetzel at gmail.com Wed Aug 12 09:59:43 2009 From: dhetzel at gmail.com (Dorn Hetzel) Date: Wed, 12 Aug 2009 10:59:43 -0400 Subject: Another fiber cut near Taiwan ? due to Typhoon Morakot ? In-Reply-To: <8582c31a0908120754u45b6918rc1a8f0bbfed8ecbb@mail.gmail.com> References: <4A825A89.9080501@lahai.com> <4A8268AA.2000708@lahai.com> <5b6f80200908120714l686392b4w8a4de4f2fb41cc42@mail.gmail.com> <8582c31a0908120754u45b6918rc1a8f0bbfed8ecbb@mail.gmail.com> Message-ID: <7db2dcf90908120759m176238f4s365c11da23c4077c@mail.gmail.com> Do typhoons/hurricanes tend to damage cables in shallow water near the landing sites, tear up the landing sites themselves, or do damage in deeper water somehow? On Wed, Aug 12, 2009 at 10:54 AM, Ethern M., Lin wrote: > Update: > > The submarine cable down first is EAC since 8/9. FNAL down > today(8/12). The cause might be typhone Morakot. Hongkong seems the > most critical impact by these cable down. > > cheers, > Ethern > > ============================= > Ethern Lin > Network Division > Computing Center, ACADEMIA SINICA > Phone: +886-2-2789-9953 > Fax : +886-2-2783-6444 > ============================= > > > > On Wed, Aug 12, 2009 at 10:14 PM, Ken Gilmour > wrote: > > I just chatted to my contact in SG (over Instant Messenger) who said > > they barely even noticed a problem. The provider is Star Hub. > > > > 2009/8/12 Gaurab Raj Upadhaya : > >> -----BEGIN PGP SIGNED MESSAGE----- > >> Hash: SHA1 > >> > >> Scott Howard wrote: > >> > >>> At that time the cause was a cable fault somewhere in/near Japan, but > at > >>> this stage I'm not sure if this is the same problem or not. > >>> > >> > >> Now confirmed that APCN2, C2C and EAC are cut. also unconfirmed reports > >> of SMW2 and SWM3 are out. FLAG and TGN seems to be not had any issues > >> so far. > >> > >> It seems at this point, the fault is more on the South China Sea and the > >> alarms I got seem to confirm that. For the geography, see > >> http://en.wikipedia.org/wiki/File:South_China_Sea.jpg > >> > >> Circuits from Japan to SG, TH, PH are down, but not to HK. My > >> perspective, yours may vary. > >> > >> - -gaurab > >> > >> > >> > >> -----BEGIN PGP SIGNATURE----- > >> Version: GnuPG v1.4.8 (Darwin) > >> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > >> > >> iEYEARECAAYFAkqCaKoACgkQSo7fU26F3X2u5ACg7Hpy9jVwHNzdDTWI6wSu4Qyh > >> TiMAn21dcEPKOqkdlQN9rQLFz+NypgID > >> =DKT6 > >> -----END PGP SIGNATURE----- > >> > >> > > > > > > From dmm at 1-4-5.net Wed Aug 12 10:09:09 2009 From: dmm at 1-4-5.net (David Meyer) Date: Wed, 12 Aug 2009 08:09:09 -0700 Subject: NANOG Program Committee Nominations open September 08 2009 Message-ID: <20090812150909.GA20122@1-4-5.net> Folks, Following up on Joe's message, I wanted to remind folks that we are approaching the annual NANOG election and appointment time, and to ask you to consider nominating qualified folks for the NANOG Program Committee. The Program Committee is a group of sixteen individuals from the NANOG community who together are responsible for the solicitation and selection of material for NANOG meeting Programs. A new Program Committee will be selected by the Steering Committee after the election in October. Eight positions are to be filled. The currently-serving Program Committee members whose terms are expiring are Joel Jaeggli, Rodney Joffe, Sylvie LaPerriere, Kevin Oberman, Lane Patterson, Ren Provo, Josh Snowhorn and Todd Underwood. Furthermore, Joel, Ren, Josh and Todd have all served two consecutive terms so per the charter, they cannot be considered for another Program Committee appointment until October 2010. Important Dates: PC Nominations begin: Sep 08 2009 PC Candidate Information posted/nominations close: Oct 19 2009 New PC appointed: Oct 22 2009 Please consider nominating those people who meet the criteria set forth in the charter [0] and who will are interested in helping to continue (and improve) the overall quality of the NANOG program. Thanks, Dave (for the NANOG Program Committee) [0] Please see http://nanog.org/governance/charter, Section 6.2.1. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Digital signature URL: From dylan.ebner at crlmed.com Wed Aug 12 10:38:47 2009 From: dylan.ebner at crlmed.com (Dylan Ebner) Date: Wed, 12 Aug 2009 09:38:47 -0600 Subject: Visualizing BGP paths Message-ID: <6286FF05EBE33C4596F6C6C23762686702561805@VS11.EXCHPROD.USA.NET> I have been working on a project to better illustrate for our manages the provider path data takes when it flows from one of our customers to our datacenter. I have tried to use trace routes to illustrate the number of hops data takes, but when I try to show many sources on one page, it gets fairly messy quickly. I am also less concerned with the number of hops, and more concerned with the number of providers. Does anyone know of a toolset that will take a list of source IP's and a destination IP and show graphically which as numbers the packets need to traverse to reach our datacenter? I am thinking of something like this: http://www.robtex.com/as/as19629.html#graph, but instead of all the upstreams it would show something like AS16150 -> AS1239 -> AS209 -> AS19629. Dylan Ebner From steve at ibctech.ca Wed Aug 12 10:42:30 2009 From: steve at ibctech.ca (Steve Bertrand) Date: Wed, 12 Aug 2009 11:42:30 -0400 Subject: Visualizing BGP paths In-Reply-To: <6286FF05EBE33C4596F6C6C23762686702561805@VS11.EXCHPROD.USA.NET> References: <6286FF05EBE33C4596F6C6C23762686702561805@VS11.EXCHPROD.USA.NET> Message-ID: <4A82E2E6.3040705@ibctech.ca> Dylan Ebner wrote: > I have been working on a project to better illustrate for our manages > the provider path data takes when it flows from one of our customers to > our datacenter. I have tried to use trace routes to illustrate the > number of hops data takes, but when I try to show many sources on one > page, it gets fairly messy quickly. I am also less concerned with the > number of hops, and more concerned with the number of providers. > Does anyone know of a toolset that will take a list of source IP's and a > destination IP and show graphically which as numbers the packets need to > traverse to reach our datacenter? I am thinking of something like this: > http://www.robtex.com/as/as19629.html#graph, but instead of all the > upstreams it would show something like AS16150 -> AS1239 -> AS209 -> > AS19629. I like BGPlay: http://bgplay.routeviews.org/bgplay/ Steve -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3233 bytes Desc: S/MIME Cryptographic Signature URL: From ethern at ascc.net Wed Aug 12 10:44:41 2009 From: ethern at ascc.net (Ethern M., Lin) Date: Wed, 12 Aug 2009 23:44:41 +0800 Subject: Another fiber cut near Taiwan ? due to Typhoon Morakot ? In-Reply-To: <7db2dcf90908120759m176238f4s365c11da23c4077c@mail.gmail.com> References: <4A825A89.9080501@lahai.com> <4A8268AA.2000708@lahai.com> <5b6f80200908120714l686392b4w8a4de4f2fb41cc42@mail.gmail.com> <8582c31a0908120754u45b6918rc1a8f0bbfed8ecbb@mail.gmail.com> <7db2dcf90908120759m176238f4s365c11da23c4077c@mail.gmail.com> Message-ID: <8582c31a0908120844y46d45819jb3fc43aa69c63991@mail.gmail.com> Actually I can't tell you more about this. I am just have this info from my IPLC provider, and its just a gossip, not formal one as I mention. Its just happened that one cable system down on 8/9, the exact day of typhoon attacked Taiwan quite badly. Maybe someone can share more detailed info and we can wait for more info later. cheers, Ethern > Do typhoons/hurricanes tend to damage cables in shallow water near the > landing sites, tear up the landing sites themselves, or do damage in deeper > water somehow? > > On Wed, Aug 12, 2009 at 10:54 AM, Ethern M., Lin wrote: >> >> Update: >> >> The submarine cable down first is EAC since 8/9. FNAL down >> today(8/12). The cause might be typhone Morakot. Hongkong seems the >> most critical impact by these cable down. >> >> cheers, >> Ethern >> >> ============================= >> Ethern Lin >> Network Division >> Computing Center, ACADEMIA SINICA >> Phone: +886-2-2789-9953 >> Fax ?: +886-2-2783-6444 >> ============================= >> >> From dylan.ebner at crlmed.com Wed Aug 12 10:46:02 2009 From: dylan.ebner at crlmed.com (Dylan Ebner) Date: Wed, 12 Aug 2009 09:46:02 -0600 Subject: Visualizing BGP paths In-Reply-To: <4A82E328.2030805@imate.fi> References: <6286FF05EBE33C4596F6C6C23762686702561805@VS11.EXCHPROD.USA.NET> <4A82E328.2030805@imate.fi> Message-ID: <6286FF05EBE33C4596F6C6C23762686702561823@VS11.EXCHPROD.USA.NET> I use BGPLay for showing our connected status, but it doesn't let me put in a source IP/AS and a destination IP/AS. BGPlay is very helpful though. Dylan Ebner -----Original Message----- From: Jarno L?hteenm?ki [mailto:jarno.lahteenmaki at imate.fi] Sent: Wednesday, August 12, 2009 10:44 AM To: Dylan Ebner Subject: Re: Visualizing BGP paths http://bgplay.routeviews.org/bgplay/ Dylan Ebner wrote: > I have been working on a project to better illustrate for our manages > the provider path data takes when it flows from one of our customers > to our datacenter. I have tried to use trace routes to illustrate the > number of hops data takes, but when I try to show many sources on one > page, it gets fairly messy quickly. I am also less concerned with the > number of hops, and more concerned with the number of providers. > Does anyone know of a toolset that will take a list of source IP's and > a destination IP and show graphically which as numbers the packets > need to traverse to reach our datacenter? I am thinking of something like this: > http://www.robtex.com/as/as19629.html#graph, but instead of all the > upstreams it would show something like AS16150 -> AS1239 -> AS209 -> > AS19629. > > > > > Dylan Ebner > > From leo.vegoda at icann.org Wed Aug 12 11:02:10 2009 From: leo.vegoda at icann.org (Leo Vegoda) Date: Wed, 12 Aug 2009 09:02:10 -0700 Subject: 175/8 and 182/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 August 2009: 175/8 and 182/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 wj8DBQFKguZyvBLymJnAzRwRAmDCAKCCnxLNmk32v+sm786x5RyVLnLBDACcCu5I zCs7FdAdkIZRnfNtuVyVB0s= =6huK -----END PGP SIGNATURE----- From ethern at ascc.net Wed Aug 12 11:05:59 2009 From: ethern at ascc.net (Ethern M., Lin) Date: Thu, 13 Aug 2009 00:05:59 +0800 Subject: Another fiber cut near Taiwan ? due to Typhoon Morakot ? In-Reply-To: <8582c31a0908120844y46d45819jb3fc43aa69c63991@mail.gmail.com> References: <4A825A89.9080501@lahai.com> <4A8268AA.2000708@lahai.com> <5b6f80200908120714l686392b4w8a4de4f2fb41cc42@mail.gmail.com> <8582c31a0908120754u45b6918rc1a8f0bbfed8ecbb@mail.gmail.com> <7db2dcf90908120759m176238f4s365c11da23c4077c@mail.gmail.com> <8582c31a0908120844y46d45819jb3fc43aa69c63991@mail.gmail.com> Message-ID: <8582c31a0908120905w6491df93l5731f10be7e423a7@mail.gmail.com> Latest news: The typhoon Morakot cause rare debris flow under sea and damage many cable systems at southern Taiwan more than earthquake at 2005/12/25. Announced by CHT, Chunghwa telecom: http://english.cna.com.tw/ReadNews/Detail.aspx?pSearchDate=&pNewsID=200908120038&pType1=ED&pType0=xEMST&pTypeSel=0 cheers, Ethern ============================= Ethern Lin Network Division Computing Center, ACADEMIA SINICA Phone: +886-2-2789-9953 Fax : +886-2-2783-6444 ============================= On Wed, Aug 12, 2009 at 11:44 PM, Ethern M., Lin wrote: > Actually I can't tell you more about this. I am just have this info > from my IPLC provider, and its just a gossip, not formal one as I > mention. > > Its just happened that one cable system down on 8/9, the exact day of > typhoon attacked Taiwan quite badly. > > Maybe someone can share more detailed info and we can wait for more info later. > > cheers, > Ethern > >> Do typhoons/hurricanes tend to damage cables in shallow water near the >> landing sites, tear up the landing sites themselves, or do damage in deeper >> water somehow? >> >> On Wed, Aug 12, 2009 at 10:54 AM, Ethern M., Lin wrote: >>> >>> Update: >>> >>> The submarine cable down first is EAC since 8/9. FNAL down >>> today(8/12). The cause might be typhone Morakot. Hongkong seems the >>> most critical impact by these cable down. >>> >>> cheers, >>> Ethern >>> >>> ============================= >>> Ethern Lin >>> Network Division >>> Computing Center, ACADEMIA SINICA >>> Phone: +886-2-2789-9953 >>> Fax ?: +886-2-2783-6444 >>> ============================= >>> >>> > From ethern at ascc.net Wed Aug 12 11:10:34 2009 From: ethern at ascc.net (Ethern M., Lin) Date: Thu, 13 Aug 2009 00:10:34 +0800 Subject: Another fiber cut near Taiwan ? due to Typhoon Morakot ? In-Reply-To: <8582c31a0908120905w6491df93l5731f10be7e423a7@mail.gmail.com> References: <4A825A89.9080501@lahai.com> <4A8268AA.2000708@lahai.com> <5b6f80200908120714l686392b4w8a4de4f2fb41cc42@mail.gmail.com> <8582c31a0908120754u45b6918rc1a8f0bbfed8ecbb@mail.gmail.com> <7db2dcf90908120759m176238f4s365c11da23c4077c@mail.gmail.com> <8582c31a0908120844y46d45819jb3fc43aa69c63991@mail.gmail.com> <8582c31a0908120905w6491df93l5731f10be7e423a7@mail.gmail.com> Message-ID: <8582c31a0908120910kfce2e54k8861dc770721efe0@mail.gmail.com> > Latest news: > > The typhoon Morakot cause rare debris flow under sea and damage many > cable systems at southern Taiwan more than earthquake at 2005/12/25. Its 2006/12/26, not 2005. cheers, Ethern > > Announced by CHT, Chunghwa telecom: > > http://english.cna.com.tw/ReadNews/Detail.aspx?pSearchDate=&pNewsID=200908120038&pType1=ED&pType0=xEMST&pTypeSel=0 > > cheers, > Ethern > > ============================= > Ethern Lin > Network Division > Computing Center, ACADEMIA SINICA > Phone: +886-2-2789-9953 > Fax ?: +886-2-2783-6444 > ============================= > > > > On Wed, Aug 12, 2009 at 11:44 PM, Ethern M., Lin wrote: >> Actually I can't tell you more about this. I am just have this info >> from my IPLC provider, and its just a gossip, not formal one as I >> mention. >> >> Its just happened that one cable system down on 8/9, the exact day of >> typhoon attacked Taiwan quite badly. >> >> Maybe someone can share more detailed info and we can wait for more info later. >> >> cheers, >> Ethern >> >>> Do typhoons/hurricanes tend to damage cables in shallow water near the >>> landing sites, tear up the landing sites themselves, or do damage in deeper >>> water somehow? >>> >>> On Wed, Aug 12, 2009 at 10:54 AM, Ethern M., Lin wrote: >>>> >>>> Update: >>>> >>>> The submarine cable down first is EAC since 8/9. FNAL down >>>> today(8/12). The cause might be typhone Morakot. Hongkong seems the >>>> most critical impact by these cable down. >>>> >>>> cheers, >>>> Ethern >>>> >>>> ============================= >>>> Ethern Lin >>>> Network Division >>>> Computing Center, ACADEMIA SINICA >>>> Phone: +886-2-2789-9953 >>>> Fax ?: +886-2-2783-6444 >>>> ============================= >>>> >>>> >> > From mkarir at merit.edu Wed Aug 12 11:26:22 2009 From: mkarir at merit.edu (mkarir) Date: Wed, 12 Aug 2009 12:26:22 -0400 Subject: IM based BGP route-server interface In-Reply-To: <299ee3ad0908120858r6c8123f7ja29650d7d76d475c@mail.gmail.com> References: <25376C1E-AD6F-4F27-BD21-824873775FBE@merit.edu> <299ee3ad0908120858r6c8123f7ja29650d7d76d475c@mail.gmail.com> Message-ID: <0AD9032D-EF3C-4532-87EA-FFD6558CC8D5@merit.edu> All, Thanks to all who responded and provided useful feedback. We had an overwhelmingly positive response. We have incorporated a bunch of comments into the new version of the bot that is currently live. Some of the most visible changes are: - added minimal support for ping and traceroute from the bot interface - added a new aslookup command to provide a quick conversion of AS numbers to names and names to as numbers - added a show ip bgp view command to list possible views that can be queried - added support for cisco shortcuts - IPv6 bgp views should be available soon as well. - the jabber version of the bot was moved to a new server. The new versions of the bots are currently live at: AIM: bgpbotz Jabber: bgpbotz at jabber.research.merit.edu We would be happy to add more BGP views to the bot if anyone is willing to provide us with a BGP feed. So far we have only received 1 BGP feed offer. The new version of the bot code has been updated on the website as well if folks want to give that a shot. http://software.merit.edu/bgpbotz Comments and feedback are welcome and appreciated. Thanks. Eric Wustrow and Manish Karir (Merit Network Inc.) > Date: Tue, Aug 4, 2009 at 10:06 PM > Subject: IM based BGP route-server interface > To: nanog at nanog.org > > > > All, > > We have been experimenting with Instant Messaging as > an interface for providing easier access to a route-server. > (no longer need to telnet xyz or use annoying web forms). > > We have essentially created a BGP chat bot. You can > reach it by adding AIM: bgpbotz ( or Jabber: bgpbotz at jabber.merit.edu) > to your buddy list. > Just type 'help' or '?' to get started or 'examples'. Most normal > route-server > queries are supported. You should be able to view routes > from Merit's perspective by querying bgpbotz. > > We would really appreciate any feedback on this project. > The website is at: http://software.merit.edu/bgpbotz > > As bgpbotz is essentially just a query interface to an underlying > route-server we would be happpy to add your BGP feeds to our > installation and make them available as "views" for other people > to query. Please feel free to contact us if you are interested in > setting this up. Alternately you can download the chat bot > code from the website and run it yourself. In that case please > let us know so that we can add your bot to the project website. > > All comments are welcome. > > Thanks > Eric Wustrow > Manish Karir > (Merit Network Inc.) > From braaen at zcorum.com Wed Aug 12 12:02:00 2009 From: braaen at zcorum.com (Brian Raaen) Date: Wed, 12 Aug 2009 13:02:00 -0400 Subject: Visualizing BGP paths In-Reply-To: <6286FF05EBE33C4596F6C6C23762686702561823@VS11.EXCHPROD.USA.NET> References: <6286FF05EBE33C4596F6C6C23762686702561805@VS11.EXCHPROD.USA.NET> <4A82E328.2030805@imate.fi> <6286FF05EBE33C4596F6C6C23762686702561823@VS11.EXCHPROD.USA.NET> Message-ID: <4A82F588.7090308@zcorum.com> At least in Debian and Ubuntu Linux there is a traceroute utility that gives path ASN's. It is ironically called traceroute-nanog. If I do a `traceroute-nanog -AO $destination` I get all the ASN info. -- ----------------- Brian Raaen Network Engineer email: /braaen at zcorum.com/ Dylan Ebner wrote: > I use BGPLay for showing our connected status, but it doesn't let me put in a source IP/AS and a destination IP/AS. BGPlay is very helpful though. > > > > > Dylan Ebner > > > -----Original Message----- > From: Jarno L?hteenm?ki [mailto:jarno.lahteenmaki at imate.fi] > Sent: Wednesday, August 12, 2009 10:44 AM > To: Dylan Ebner > Subject: Re: Visualizing BGP paths > > > http://bgplay.routeviews.org/bgplay/ > > > Dylan Ebner wrote: > >> I have been working on a project to better illustrate for our manages >> the provider path data takes when it flows from one of our customers >> to our datacenter. I have tried to use trace routes to illustrate the >> number of hops data takes, but when I try to show many sources on one >> page, it gets fairly messy quickly. I am also less concerned with the >> number of hops, and more concerned with the number of providers. >> Does anyone know of a toolset that will take a list of source IP's and >> a destination IP and show graphically which as numbers the packets >> need to traverse to reach our datacenter? I am thinking of something like this: >> http://www.robtex.com/as/as19629.html#graph, but instead of all the >> upstreams it would show something like AS16150 -> AS1239 -> AS209 -> >> AS19629. >> >> >> >> >> Dylan Ebner >> >> >> > > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: braaen.vcf Type: text/x-vcard Size: 206 bytes Desc: not available URL: From scott at doc.net.au Wed Aug 12 12:37:48 2009 From: scott at doc.net.au (Scott Howard) Date: Wed, 12 Aug 2009 10:37:48 -0700 Subject: Another fiber cut near Taiwan ? due to Typhoon Morakot ? In-Reply-To: <8582c31a0908120905w6491df93l5731f10be7e423a7@mail.gmail.com> References: <4A825A89.9080501@lahai.com> <4A8268AA.2000708@lahai.com> <5b6f80200908120714l686392b4w8a4de4f2fb41cc42@mail.gmail.com> <8582c31a0908120754u45b6918rc1a8f0bbfed8ecbb@mail.gmail.com> <7db2dcf90908120759m176238f4s365c11da23c4077c@mail.gmail.com> <8582c31a0908120844y46d45819jb3fc43aa69c63991@mail.gmail.com> <8582c31a0908120905w6491df93l5731f10be7e423a7@mail.gmail.com> Message-ID: Some further press on it : http://www.computerworld.com/s/article/9136558/Update_Asian_undersea_cable_disruption_slows_Internet_access http://www.zdnetasia.com/news/communications/0,39044192,62056838,00.htm In the past hour we've seen latency and packet loss return to almost normal (we were seeing ~40% loss for a few hours) across multiple providers, so I'm guessing something has been done to re-route traffic. Scott. On Wed, Aug 12, 2009 at 9:05 AM, Ethern M., Lin wrote: > Latest news: > > The typhoon Morakot cause rare debris flow under sea and damage many > cable systems at southern Taiwan more than earthquake at 2005/12/25. > > Announced by CHT, Chunghwa telecom: > > > http://english.cna.com.tw/ReadNews/Detail.aspx?pSearchDate=&pNewsID=200908120038&pType1=ED&pType0=xEMST&pTypeSel=0 > > cheers, > Ethern > > ============================= > Ethern Lin > Network Division > Computing Center, ACADEMIA SINICA > Phone: +886-2-2789-9953 > Fax : +886-2-2783-6444 > ============================= > > > > On Wed, Aug 12, 2009 at 11:44 PM, Ethern M., Lin wrote: > > Actually I can't tell you more about this. I am just have this info > > from my IPLC provider, and its just a gossip, not formal one as I > > mention. > > > > Its just happened that one cable system down on 8/9, the exact day of > > typhoon attacked Taiwan quite badly. > > > > Maybe someone can share more detailed info and we can wait for more info > later. > > > > cheers, > > Ethern > > > >> Do typhoons/hurricanes tend to damage cables in shallow water near the > >> landing sites, tear up the landing sites themselves, or do damage in > deeper > >> water somehow? > >> > >> On Wed, Aug 12, 2009 at 10:54 AM, Ethern M., Lin > wrote: > >>> > >>> Update: > >>> > >>> The submarine cable down first is EAC since 8/9. FNAL down > >>> today(8/12). The cause might be typhone Morakot. Hongkong seems the > >>> most critical impact by these cable down. > >>> > >>> cheers, > >>> Ethern > >>> > >>> ============================= > >>> Ethern Lin > >>> Network Division > >>> Computing Center, ACADEMIA SINICA > >>> Phone: +886-2-2789-9953 > >>> Fax : +886-2-2783-6444 > >>> ============================= > >>> > >>> > > > > From goemon at anime.net Wed Aug 12 13:20:28 2009 From: goemon at anime.net (goemon at anime.net) Date: Wed, 12 Aug 2009 11:20:28 -0700 (PDT) Subject: Follow up to previous post regarding SAAVIS In-Reply-To: <75cb24520908120709u26dddeacs6dd0d4241d40f8e1@mail.gmail.com> References: <75cb24520908120709u26dddeacs6dd0d4241d40f8e1@mail.gmail.com> Message-ID: On Wed, 12 Aug 2009, Christopher Morrow wrote: > On Wed, Aug 12, 2009 at 9:57 AM, Drew Weaver wrote: >> Anyone know why SAAVIS would be allowing PEER1 (AS 13768) to advertise routes for whatever IP addresses they want? > sadly savvis didn't learn the pccw lesson, which is also the > turk-telecom lesson which is also the as7007 lesson which is... fairly > sad really in 2009. > for the sake of $diety put a prefix-filter on your customer bgp > sessions, it ain't hard! sounds too much like "work" to me. not interested. -Dan From morrowc.lists at gmail.com Wed Aug 12 13:43:01 2009 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Wed, 12 Aug 2009 14:43:01 -0400 Subject: Follow up to previous post regarding SAAVIS In-Reply-To: References: <75cb24520908120709u26dddeacs6dd0d4241d40f8e1@mail.gmail.com> Message-ID: <75cb24520908121143k4296aa9bo8f2a344cd05c02a5@mail.gmail.com> On Wed, Aug 12, 2009 at 2:20 PM, wrote: > On Wed, 12 Aug 2009, Christopher Morrow wrote: >> >> On Wed, Aug 12, 2009 at 9:57 AM, Drew Weaver >> wrote: >>> >>> Anyone know why SAAVIS would be allowing PEER1 (AS 13768) to advertise >>> routes for whatever IP addresses they want? >> >> sadly savvis didn't learn the pccw lesson, which is also the >> turk-telecom lesson which is also the as7007 lesson which is... fairly >> sad really in 2009. >> for the sake of $diety put a prefix-filter on your customer bgp >> sessions, it ain't hard! > > sounds too much like "work" to me. not interested. From nanog-post at rsuc.gweep.net Wed Aug 12 15:37:53 2009 From: nanog-post at rsuc.gweep.net (Joe Provo) Date: Wed, 12 Aug 2009 16:37:53 -0400 Subject: Follow up to previous post regarding SAAVIS In-Reply-To: References: <75cb24520908120709u26dddeacs6dd0d4241d40f8e1@mail.gmail.com> Message-ID: <20090812203753.GA49057@gweep.net> On Wed, Aug 12, 2009 at 11:20:28AM -0700, goemon at anime.net wrote: > On Wed, 12 Aug 2009, Christopher Morrow wrote: > >On Wed, Aug 12, 2009 at 9:57 AM, Drew Weaver wrote: > >>Anyone know why SAAVIS would be allowing PEER1 (AS 13768) to advertise > >>routes for whatever IP addresses they want? > >sadly savvis didn't learn the pccw lesson, which is also the > >turk-telecom lesson which is also the as7007 lesson which is... fairly > >sad really in 2009. > >for the sake of $diety put a prefix-filter on your customer bgp > >sessions, it ain't hard! > > sounds too much like "work" to me. not interested. The irony is that MCI had (and C&W maintained for quite some time) a functional, highly automated IRR-based customer filtering system [props to the Cary team]. Somewhere along the M&A highway, the work to maintain it was substituted with the work to dismantle it. Sad to see crap emitted with 3561 in the path. -- RSUC / GweepNet / Spunk / FnB / Usenix / SAGE From jared at puck.nether.net Wed Aug 12 15:57:07 2009 From: jared at puck.nether.net (Jared Mauch) Date: Wed, 12 Aug 2009 16:57:07 -0400 Subject: Follow up to previous post regarding SAAVIS In-Reply-To: <20090812203753.GA49057@gweep.net> References: <75cb24520908120709u26dddeacs6dd0d4241d40f8e1@mail.gmail.com> <20090812203753.GA49057@gweep.net> Message-ID: On Aug 12, 2009, at 4:37 PM, Joe Provo wrote: > On Wed, Aug 12, 2009 at 11:20:28AM -0700, goemon at anime.net wrote: >> On Wed, 12 Aug 2009, Christopher Morrow wrote: >>> On Wed, Aug 12, 2009 at 9:57 AM, Drew >>> Weaver wrote: >>>> Anyone know why SAAVIS would be allowing PEER1 (AS 13768) to >>>> advertise >>>> routes for whatever IP addresses they want? >>> sadly savvis didn't learn the pccw lesson, which is also the >>> turk-telecom lesson which is also the as7007 lesson which is... >>> fairly >>> sad really in 2009. >>> for the sake of $diety put a prefix-filter on your customer bgp >>> sessions, it ain't hard! >> >> sounds too much like "work" to me. not interested. > > The irony is that MCI had (and C&W maintained for quite some time) > a functional, highly automated IRR-based customer filtering system > [props to the Cary team]. Somewhere along the M&A highway, the > work to maintain it was substituted with the work to dismantle it. > Sad to see crap emitted with 3561 in the path. I've come to the conclusion that if someone put a nice web2.0+ interface on creating and managing these objects it would be a lot easier. If there were a customer portal where you could visit to say "update my prefix-list/acl to include the following new prefix(es), and push the change /now/" I presume that would drive customer utilization of these services and allow people to manage things "better". There are lots of leaks all the time, as can be evidenced by the leak detection stuff I set up here: http://puck.nether.net/bgp/leakinfo.cgi - Jared From justin at justinshore.com Wed Aug 12 16:12:39 2009 From: justin at justinshore.com (Justin Shore) Date: Wed, 12 Aug 2009 16:12:39 -0500 Subject: Follow up to previous post regarding SAAVIS In-Reply-To: References: <75cb24520908120709u26dddeacs6dd0d4241d40f8e1@mail.gmail.com> <20090812203753.GA49057@gweep.net> Message-ID: <4A833047.3000003@justinshore.com> Jared Mauch wrote: > I've come to the conclusion that if someone put a nice web2.0+ interface > on creating and managing these objects it would be a lot easier. I've looked into IRR several times, usually after events like PCCW. Each time the amount of work to 1) figure out how to implement IRR and 2) actually implementing it far outweighed the benefit of doing it for my network. I would love to implement it and looking towards the future I will someday have to. Until it becomes much easier to do so, I don't foresee smaller SPs like myself allocating the necessary resources to an IRR project until we're forced to because of our individual growth or an idiot PCCW-type event that generates lots of bad PR. > There are lots of leaks all the time, as can be evidenced by the leak > detection stuff I set up here: > > http://puck.nether.net/bgp/leakinfo.cgi Crossing fingers hoping I'm not in that list... Justin From mike at mikej.net.nz Wed Aug 12 16:16:18 2009 From: mike at mikej.net.nz (Michael Jager) Date: Thu, 13 Aug 2009 09:16:18 +1200 Subject: Visualizing BGP paths In-Reply-To: <6286FF05EBE33C4596F6C6C23762686702561805@VS11.EXCHPROD.USA.NET> References: <6286FF05EBE33C4596F6C6C23762686702561805@VS11.EXCHPROD.USA.NET> Message-ID: <4A833122.4030600@mikej.net.nz> On 13/08/09 03:38, Dylan Ebner wrote: > I have been working on a project to better illustrate for our manages > the provider path data takes when it flows from one of our customers to > our datacenter. I have tried to use trace routes to illustrate the > number of hops data takes, but when I try to show many sources on one > page, it gets fairly messy quickly. I am also less concerned with the > number of hops, and more concerned with the number of providers. > Does anyone know of a toolset that will take a list of source IP's and a > destination IP and show graphically which as numbers the packets need to > traverse to reach our datacenter? I am thinking of something like this: > http://www.robtex.com/as/as19629.html#graph, but instead of all the > upstreams it would show something like AS16150 -> AS1239 -> AS209 -> > AS19629. I find Perry Lorier's traceroute mesh server (http://tr.meta.net.nz) in "Grouped by AS" mode (do a "Full Traceroute" first to find the Grouped by AS option) pretty useful as a general "how do other people reach us?" tool. I don't think it's exactly what you want, but could possibly be something to start with? -Mike From ras at e-gerbil.net Wed Aug 12 16:23:05 2009 From: ras at e-gerbil.net (Richard A Steenbergen) Date: Wed, 12 Aug 2009 16:23:05 -0500 Subject: Follow up to previous post regarding SAAVIS In-Reply-To: References: <75cb24520908120709u26dddeacs6dd0d4241d40f8e1@mail.gmail.com> <20090812203753.GA49057@gweep.net> Message-ID: <20090812212305.GN51443@gerbil.cluepon.net> On Wed, Aug 12, 2009 at 04:57:07PM -0400, Jared Mauch wrote: > > I've come to the conclusion that if someone put a nice web2.0+ > interface on creating and managing these objects it would be a lot > easier. Agreed, this is one of the projects I've been working on just haven't had the time to finish it. But please allow me to put in a shameless plug for IRR PowerTools, which many networks (including a couple tier 1s) use to do their IRR: http://sourceforge.net/projects/irrpt/ The highlights are: * Automated retrieval of prefixes registered behind an IRR Object. * Automatic exclusion of bogon or other configured undesirable routes. * Tracking and long-term recording of prefix changes over time. * Automatic aggregation to optimize data and reduce unnecessary changes. * E-mail updates, letting users know that their change was processed. * E-mail alerts to the ISP, letting them know of new routing changes. * E-mail alerts to non-IRR using networks, with plain text changes. * Router config generation, for easy automated config deployment. I'm also in the process of beta testing a new 2.0 version which will be significantly rewritten for easier more scalable use, have a lot fewer dependencies, integrate better with db backend systems to customer prefix-list management, and fully support IPv6. Oh and there might just be a web gui for managing and using it too, if I can find a decent web developer who will do it for free. :) I'm hoping to have this out in the next couple of months. -- Richard A Steenbergen http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) From oberman at es.net Wed Aug 12 16:30:38 2009 From: oberman at es.net (Kevin Oberman) Date: Wed, 12 Aug 2009 14:30:38 -0700 Subject: Follow up to previous post regarding SAAVIS In-Reply-To: Your message of "Wed, 12 Aug 2009 16:12:39 CDT." <4A833047.3000003@justinshore.com> Message-ID: <20090812213038.B23661CC31@ptavv.es.net> > Date: Wed, 12 Aug 2009 16:12:39 -0500 > From: Justin Shore > > Jared Mauch wrote: > > I've come to the conclusion that if someone put a nice web2.0+ interface > > on creating and managing these objects it would be a lot easier. > > I've looked into IRR several times, usually after events like PCCW. > Each time the amount of work to 1) figure out how to implement IRR and > 2) actually implementing it far outweighed the benefit of doing it for > my network. I would love to implement it and looking towards the future > I will someday have to. Until it becomes much easier to do so, I don't > foresee smaller SPs like myself allocating the necessary resources to an > IRR project until we're forced to because of our individual growth or an > idiot PCCW-type event that generates lots of bad PR. While a web 2.0 app would be very nice, it's really not that hard to do now. You do need the IRRToolSet or something similar. the IRRToolSet has languished for a long time and was getting harder and harder to keep running, but the move to sourceforge and the massive number of updates and clean ups should soon result in a 5.0 release that builds cleanly on most Unix/Linux platforms with a modern C++ compiler. Once that happens, it's really pretty simple to use the IRR for this sort of thing and, while the IRR data quality is pretty poor, it's a vast improvement over crossing your fingers and sticking your head in the sand. Except for the ugliness of the Perl I wrote well over a decade ago (when I was just learning Perl), I'd try to talk the powers that be into allowing me to release it as an example, but the relevant code is really, really trivial. (Not that government would let me without vast quantities of paperwork.) -- 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 nanog-post at rsuc.gweep.net Wed Aug 12 16:41:03 2009 From: nanog-post at rsuc.gweep.net (Joe Provo) Date: Wed, 12 Aug 2009 17:41:03 -0400 Subject: Follow up to previous post regarding SAAVIS In-Reply-To: <20090812213038.B23661CC31@ptavv.es.net> References: <4A833047.3000003@justinshore.com> <20090812213038.B23661CC31@ptavv.es.net> Message-ID: <20090812214103.GA42448@gweep.net> On Wed, Aug 12, 2009 at 02:30:38PM -0700, Kevin Oberman wrote: [snip] > While a web 2.0 app would be very nice, it's really not that hard to do > now. You do need the IRRToolSet or something similar. the IRRToolSet has > languished for a long time and was getting harder and harder to keep > running, but the move to sourceforge and the massive number of updates > and clean ups should soon result in a 5.0 release that builds cleanly on [insert plug for the revitalization going on at irrtoolset at lists.isc.org] The internal piece (ras's code, etc) is the easy part. The customer- facing piece isn't particularly difficult either. Getting it past the inexplicably-powerful branding people in marketing and having a management team with the iron will to dictate that the pointy-clicky form is not just the standard vector but the ONLY vector for non-IRR clued users. That was the support the cary team had at old 3561. Most ISPs don't have that level of management clue & willpower, as the same "but they will go to $competator who doesn't require it!" which has screwed up everything from domain registration to responsible BGP announcements fouls the customer interface as well. Account reps wanting an exception 'just this once' are the norm. Cheers, Joe -- RSUC / GweepNet / Spunk / FnB / Usenix / SAGE From jfbeam at gmail.com Wed Aug 12 16:45:28 2009 From: jfbeam at gmail.com (Ricky Beam) Date: Wed, 12 Aug 2009 17:45:28 -0400 Subject: Follow up to previous post regarding SAAVIS In-Reply-To: References: <75cb24520908120709u26dddeacs6dd0d4241d40f8e1@mail.gmail.com> <20090812203753.GA49057@gweep.net> Message-ID: On Wed, 12 Aug 2009 16:57:07 -0400, Jared Mauch wrote: > I've come to the conclusion that if someone put a nice web2.0+ interface > on creating and managing these objects it would be a lot easier. > > If there were a customer portal where you could visit to say "update my > prefix-list/acl to include the following new prefix(es), and push the > change /now/" I presume that would drive customer utilization of these > services and allow people to manage things "better". That's fine... until you learn the hard way 9 times out of 10, the person heading to such a thing is a clueless moron. As much as it is a pain in the rear, having *people* proofing and editing the BGP configuration is far less work than creating the AI needed to keep idiots from doing idiotic things. I've never worked for any of the tier-1 beasts, but I have had to manage dozens of customer BGP sessions. Over a decade, I never dealt with a clueful customer... we cannot announce address space that doesn't belong to you; you cannot announce *our* address space to other ISPs; you have one f'ing link, why do you need BGP? (note: never actually ask that question or mute your phone immediately after asking.) How often do your prefixes change? In my experience adding new netblocks and/or customers, taking a few weeks to get things setup wasn't a problem; it'd take that long to get their connection turned up. (and if they were talking about BGP, sales would be talking to us before the contract was signed.) --Ricky From ras at e-gerbil.net Wed Aug 12 17:55:10 2009 From: ras at e-gerbil.net (Richard A Steenbergen) Date: Wed, 12 Aug 2009 17:55:10 -0500 Subject: Follow up to previous post regarding SAAVIS In-Reply-To: <20090812214103.GA42448@gweep.net> References: <4A833047.3000003@justinshore.com> <20090812213038.B23661CC31@ptavv.es.net> <20090812214103.GA42448@gweep.net> Message-ID: <20090812225510.GP51443@gerbil.cluepon.net> On Wed, Aug 12, 2009 at 05:41:03PM -0400, Joe Provo wrote: > Most ISPs don't have that level of management clue & willpower, as the > same "but they will go to $competator who doesn't require it!" which > has screwed up everything from domain registration to responsible BGP > announcements fouls the customer interface as well. Account reps wanting > an exception 'just this once' are the norm. I would make the opposite argument, my business would NEVER go to any network which didn't support IRR (and a bunch of other simple but important things, like a full set of non-secret BGP communities). It's amazing the number of networks that excludes in this day and age. And not even because "omg IRR is good because someone told me so and we should support it", but because I've seen FAR too much grief caused by humans typoing prefix-lists, or taking days to process them. It is the height of absurdity that this would ever be considered an acceptable solution to the problem. But most of all I'm amazed that we as network operators have managed to take such a simple concept as a protocol for storing and recursively retrieving a list of prefixes in a database and turned it into such a sloppy mess. We really shot ourselves in the foot with the complexity of RPSL, which tries to be everything to everyone rather than actually provide a simple effective way to maintain prefix-lists. -- Richard A Steenbergen http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) From frnkblk at iname.com Wed Aug 12 19:37:00 2009 From: frnkblk at iname.com (Frank Bulk) Date: Wed, 12 Aug 2009 19:37:00 -0500 Subject: Follow up to previous post regarding SAAVIS In-Reply-To: <20090812225510.GP51443@gerbil.cluepon.net> References: <4A833047.3000003@justinshore.com> <20090812213038.B23661CC31@ptavv.es.net> <20090812214103.GA42448@gweep.net> <20090812225510.GP51443@gerbil.cluepon.net> Message-ID: Perhaps this is a stupid question, but does each SP need to run their own physical RR? Isn't this something that could be hosted? Frank -----Original Message----- From: Richard A Steenbergen [mailto:ras at e-gerbil.net] Sent: Wednesday, August 12, 2009 5:55 PM To: Joe Provo Cc: nanog at nanog.org Subject: Re: Follow up to previous post regarding SAAVIS On Wed, Aug 12, 2009 at 05:41:03PM -0400, Joe Provo wrote: > Most ISPs don't have that level of management clue & willpower, as the > same "but they will go to $competator who doesn't require it!" which > has screwed up everything from domain registration to responsible BGP > announcements fouls the customer interface as well. Account reps wanting > an exception 'just this once' are the norm. I would make the opposite argument, my business would NEVER go to any network which didn't support IRR (and a bunch of other simple but important things, like a full set of non-secret BGP communities). It's amazing the number of networks that excludes in this day and age. And not even because "omg IRR is good because someone told me so and we should support it", but because I've seen FAR too much grief caused by humans typoing prefix-lists, or taking days to process them. It is the height of absurdity that this would ever be considered an acceptable solution to the problem. But most of all I'm amazed that we as network operators have managed to take such a simple concept as a protocol for storing and recursively retrieving a list of prefixes in a database and turned it into such a sloppy mess. We really shot ourselves in the foot with the complexity of RPSL, which tries to be everything to everyone rather than actually provide a simple effective way to maintain prefix-lists. -- Richard A Steenbergen http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) From scg at gibbard.org Wed Aug 12 19:43:00 2009 From: scg at gibbard.org (Steve Gibbard) Date: Wed, 12 Aug 2009 17:43:00 -0700 (PDT) Subject: Follow up to previous post regarding SAAVIS In-Reply-To: <20090812225510.GP51443@gerbil.cluepon.net> References: <4A833047.3000003@justinshore.com> <20090812213038.B23661CC31@ptavv.es.net> <20090812214103.GA42448@gweep.net> <20090812225510.GP51443@gerbil.cluepon.net> Message-ID: On Wed, 12 Aug 2009, Richard A Steenbergen wrote: > I would make the opposite argument, my business would NEVER go to any > network which didn't support IRR (and a bunch of other simple but > important things, like a full set of non-secret BGP communities). It's > amazing the number of networks that excludes in this day and age. And > not even because "omg IRR is good because someone told me so and we > should support it", but because I've seen FAR too much grief caused by > humans typoing prefix-lists, or taking days to process them. It is the > height of absurdity that this would ever be considered an acceptable > solution to the problem. I'd be very hesitant to use an upstream that didn't use any filtering method. But, as convenient as I find the IRR system to be (from the customer perspective, at least), I'm quite happy that a couple of our upstreams use other mechanisms instead. I've had prefixes fall out of the IRR a couple of times, leading to outages of IRR-using transit providers. I've had transit providers screw up manually maintained prefix-lists, or had mis-communications resulting in the wrong thing getting removed. With multiple transit providers and multiple systems, they tend not to all have the same filtering problem at the same time. That's a very good thing. I hope the recommendation that comes out of this discussion is to filter somehow, rather than to use any particular filter-generation mechanism. Diversity and redundancy are good things, in processes as well as hardware. -Steve From mkarir at merit.edu Wed Aug 12 19:44:48 2009 From: mkarir at merit.edu (mkarir) Date: Wed, 12 Aug 2009 20:44:48 -0400 Subject: Follow up to previous post regarding SAAVIS In-Reply-To: References: Message-ID: <86481589-3D72-4AD0-B52C-27209C560AC3@merit.edu> Hi Jared, You should give the new RADB portal a try. We were trying to do pretty much what you describe. Dont know what web2.0 is but the new portal is a web based object management system complete with "recommended" changes and inconsistency lists. We just added prefix allocation check with backend information from PCH (prefix checker tool). Prefix/acl generation is coming soon too stay tuned. Alert/ notification has been tested and we are figuring out how to roll it out on a larger scale. We are also starting to study whether the data itself has actually gotten any better since we put this web gui in place. -manish On Aug 12, 2009, at 6:55 PM, nanog-request at nanog.org wrote: > Date: Wed, 12 Aug 2009 16:57:07 -0400 > From: Jared Mauch > Subject: Re: Follow up to previous post regarding SAAVIS > To: nanog-post at rsuc.gweep.net > Cc: "nanog at nanog.org" > Message-ID: > Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes > > > I've come to the conclusion that if someone put a nice web2.0+ > interface on creating and managing these objects it would be a lot > easier. > > If there were a customer portal where you could visit to say "update > my prefix-list/acl to include the following new prefix(es), and push > the change /now/" I presume that would drive customer utilization of > these services and allow people to manage things "better". > > There are lots of leaks all the time, as can be evidenced by the leak > detection stuff I set up here: > > http://puck.nether.net/bgp/leakinfo.cgi > > - Jared From esavage at digitalrage.org Wed Aug 12 20:06:08 2009 From: esavage at digitalrage.org (Elijah Savage) Date: Wed, 12 Aug 2009 21:06:08 -0400 Subject: "OT" EVDO Technologies Message-ID: I would appreciate if anyone would be gracious enough to contact me offline in reference to extending EVDO connectivity. I am looking for a reputable kit for extending antenna's connecting to HWIC's. Thank you From ras at e-gerbil.net Wed Aug 12 20:16:38 2009 From: ras at e-gerbil.net (Richard A Steenbergen) Date: Wed, 12 Aug 2009 20:16:38 -0500 Subject: Follow up to previous post regarding SAAVIS In-Reply-To: References: <4A833047.3000003@justinshore.com> <20090812213038.B23661CC31@ptavv.es.net> <20090812214103.GA42448@gweep.net> <20090812225510.GP51443@gerbil.cluepon.net> Message-ID: <20090813011638.GR51443@gerbil.cluepon.net> On Wed, Aug 12, 2009 at 07:37:00PM -0500, Frank Bulk wrote: > Perhaps this is a stupid question, but does each SP need to run their own > physical RR? Isn't this something that could be hosted? The data itself is stored on a distributed network of databases, so there is technically no reason any SP needs to run their own. However, they often do, because when a customer can't figure something out it gives them access to go in and tweak the customers' records for them. Unfortunately the distributed nature of the databases is one of the biggest problems with the IRR system. Anyone can run an irrd, there is no inherient authentication of the data. In order to get your irrd "recognized" all you have to do is get mirrored by a database that other people query and boom you're in the system. What tends to happen is someone puts a route into a database and then completely forgets about it, so there are a huge number of completely bogus routes out there which are never going to get cleaned up. The other problem is that when a SP has a customer who "can't figure it out", a typical course of action is to just "register the route for them" rather than try to explain it to them. Unfortunately, the same thing as above happens here, you end up with a big pile of people who register a big pile of routes in a big pile of random databases, often times completely unnecessarily, and they'll never be removed either. The biggest problem with the entire system is the way that data gets into it, and the lack of incentive for people to ever remove data from it. But as a mechanism to allow the routes which need to be allowed, and mostly prevent accidental leaks, it works. For more information, take a look at: http://www.nanog.org/meetings/nanog44/presentations/Tuesday/RAS_irrdata_N44.pdf -- 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 Wed Aug 12 21:04:51 2009 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Wed, 12 Aug 2009 22:04:51 -0400 Subject: Follow up to previous post regarding SAAVIS In-Reply-To: <20090813011638.GR51443@gerbil.cluepon.net> References: <4A833047.3000003@justinshore.com> <20090812213038.B23661CC31@ptavv.es.net> <20090812214103.GA42448@gweep.net> <20090812225510.GP51443@gerbil.cluepon.net> <20090813011638.GR51443@gerbil.cluepon.net> Message-ID: <75cb24520908121904p365ca394vc6c0015884fa32a4@mail.gmail.com> On Wed, Aug 12, 2009 at 9:16 PM, Richard A Steenbergen wrote: > On Wed, Aug 12, 2009 at 07:37:00PM -0500, Frank Bulk wrote: >> Perhaps this is a stupid question, but does each SP need to run their own >> physical RR? ?Isn't this something that could be hosted? > > The data itself is stored on a distributed network of databases, so > there is technically no reason any SP needs to run their own. However, > they often do, because when a customer can't figure something out it > gives them access to go in and tweak the customers' records for them. Another reason one might choose to run their own is you never want to answer a customer with: "Well, we query the remote systems when we need to build prefix lists and apparently the remote system blacklisted us because we queried too many times this hour/minute/day/week.. sorry 'bout that!" It gives you control over the data format, availability, freshness (sorta) and 'security' of the data you'd update your network with. Not everyone has that set of requirements, but if you ask L3 or other folks that do IRR based 'auto filtering' I bet they have an answer along these lines. > Unfortunately the distributed nature of the databases is one of the > biggest problems with the IRR system. Anyone can run an irrd, there is > no inherient authentication of the data. In order to get your irrd > "recognized" all you have to do is get mirrored by a database that other > people query and boom you're in the system. What tends to happen is > someone puts a route into a database and then completely forgets about > it, so there are a huge number of completely bogus routes out there > which are never going to get cleaned up. drum, drum, drum.. rpki! (and hopefully having that tied back to a bill you pay... see sidr at ietf.org or wherever that list emanates from these days) > The other problem is that when a SP has a customer who "can't figure it > out", a typical course of action is to just "register the route for > them" rather than try to explain it to them. Unfortunately, the same > thing as above happens here, you end up with a big pile of people who > register a big pile of routes in a big pile of random databases, often > times completely unnecessarily, and they'll never be removed either. > > The biggest problem with the entire system is the way that data gets > into it, and the lack of incentive for people to ever remove data from > it. But as a mechanism to allow the routes which need to be allowed, and > mostly prevent accidental leaks, it works. The above 2 paragraphs I think encapsulate what happened to ConEd in ~2005? (or someone-or-other-edison in newyork) Old/stale data which cropped up in an unusual manner :( > For more information, take a look at: > > http://www.nanog.org/meetings/nanog44/presentations/Tuesday/RAS_irrdata_N44.pdf btw, +1 on irrtoolset.. good stuff. -Chris From nanog-post at rsuc.gweep.net Wed Aug 12 21:06:43 2009 From: nanog-post at rsuc.gweep.net (Joe Provo) Date: Wed, 12 Aug 2009 22:06:43 -0400 Subject: Follow up to previous post regarding SAAVIS In-Reply-To: <20090812225510.GP51443@gerbil.cluepon.net> References: <4A833047.3000003@justinshore.com> <20090812213038.B23661CC31@ptavv.es.net> <20090812214103.GA42448@gweep.net> <20090812225510.GP51443@gerbil.cluepon.net> Message-ID: <20090813020643.GA70070@gweep.net> On Wed, Aug 12, 2009 at 05:55:10PM -0500, Richard A Steenbergen wrote: > On Wed, Aug 12, 2009 at 05:41:03PM -0400, Joe Provo wrote: > > Most ISPs don't have that level of management clue & willpower, as the > > same "but they will go to $competator who doesn't require it!" which > > has screwed up everything from domain registration to responsible BGP > > announcements fouls the customer interface as well. Account reps wanting > > an exception 'just this once' are the norm. > > I would make the opposite argument, my business would NEVER go to any > network which didn't support IRR (and a bunch of other simple but > important things, like a full set of non-secret BGP communities). You and I would agree, but there are far more edge ASNs than mine, and last I checked you weren't running an edge. Just as with any commoditization, the large number of buyers tends to win out. If the world we wished existied, 3561 wouldn't have lost their good provider-hosted-IRR based filters. Cheers, Joe -- RSUC / GweepNet / Spunk / FnB / Usenix / SAGE From nanog-post at rsuc.gweep.net Wed Aug 12 21:06:49 2009 From: nanog-post at rsuc.gweep.net (Joe Provo) Date: Wed, 12 Aug 2009 22:06:49 -0400 Subject: Follow up to previous post regarding SAAVIS In-Reply-To: <20090813011638.GR51443@gerbil.cluepon.net> References: <4A833047.3000003@justinshore.com> <20090812213038.B23661CC31@ptavv.es.net> <20090812214103.GA42448@gweep.net> <20090812225510.GP51443@gerbil.cluepon.net> <20090813011638.GR51443@gerbil.cluepon.net> Message-ID: <20090813020649.GB70070@gweep.net> On Wed, Aug 12, 2009 at 08:16:38PM -0500, Richard A Steenbergen wrote: [snip] > Unfortunately the distributed nature of the databases is one of the > biggest problems with the IRR system. Anyone can run an irrd, there is You misspelled "largest strength". FOlks get to choose which registries to believe in what order, not required to have a single [politicized] entity. If folks mistakenly believe there is a 1:1 correspendence between IRR data and BGP tables, they will lose. The IRR data is more of a "flight plan", a set of what-is-possible per the originator of the data. [snip] > people query and boom you're in the system. What tends to happen is > someone puts a route into a database and then completely forgets about > it, so there are a huge number of completely bogus routes out there > which are never going to get cleaned up. Lots of folks set up systems for provisioning without deprovisioning. This is not an IRR problem, but a sloppy-human problem. Folks that get stuck with provisioning generally aren't incented to remove billable resources. CF good processes and management with backbone. Cheers, Joe -- RSUC / GweepNet / Spunk / FnB / Usenix / SAGE From ras at e-gerbil.net Wed Aug 12 22:03:23 2009 From: ras at e-gerbil.net (Richard A Steenbergen) Date: Wed, 12 Aug 2009 22:03:23 -0500 Subject: Follow up to previous post regarding SAAVIS In-Reply-To: <20090813020649.GB70070@gweep.net> References: <4A833047.3000003@justinshore.com> <20090812213038.B23661CC31@ptavv.es.net> <20090812214103.GA42448@gweep.net> <20090812225510.GP51443@gerbil.cluepon.net> <20090813011638.GR51443@gerbil.cluepon.net> <20090813020649.GB70070@gweep.net> Message-ID: <20090813030323.GT51443@gerbil.cluepon.net> On Wed, Aug 12, 2009 at 10:06:49PM -0400, Joe Provo wrote: > On Wed, Aug 12, 2009 at 08:16:38PM -0500, Richard A Steenbergen wrote: > [snip] > > Unfortunately the distributed nature of the databases is one of the > > biggest problems with the IRR system. Anyone can run an irrd, there is > > You misspelled "largest strength". FOlks get to choose which registries > to believe in what order, not required to have a single [politicized] > entity. Well, actually, no. I'm not aware of any mechanism under which you can effectively choose who to believe and in what order, nor do I think that it would make any real difference in the long run even if you could. IRR database mirroring is like being a tier 1, you have to peer with every other database out there in order to obtain a full view. That means there are two ways you can get access to all the data you need, you can either query someone else who maintains all those mirrors, or you can run your own irr db and do all the mirroring yourself. RADB is the de facto "main db" in the IRR system, it not only originates the vast majority of the routes but it maintains the most comprehensive mirroring of every other active IRR db. RADB currently tracks a total of 32 databases: http://www.radb.net/mirrorlist.html At the end of the day the results are the same, whether the data is in your local irrd or someone else's db (like RADB). You query them via the same mechanism, which has extremely limited source selection control. Basically the only thing you have control over are the list of IRR databases which are searched, but the results which are returned are a superset of all databases which you selected to search. You don't get to say "only listen to results from LEVEL3's db for this object unless they don't have results there, in which case you listen to SAVVIS" or anything like that. You could query the complete data for every individual route yourself, but this would be a massively difficult undertaking compared to the normal query operation. The normal query operation is by no stretch of the imagination easy either, querying a large ISP can take hours or more depending on the transaction latency between yourself and the server you're querying. In fact this is one of the reasons why querying data from RIPE is such a pain, their query language lacks a recursive service side expansion mechanism so the transaction latency turns querying a large AS-SET into a multi-hour or day long operation. Their whois daemon also has an obnoxious "feature" of forcefully closing the socket after 3 minutes, even if it's in the middle of returning an answer. This is the only real advantage of running your own local irrd, reducing the transaction latency, but it's still a lot of work to maintain the mirror, verify that all the data from all the sources is always importing correctly, etc. And even after you do all this, what does being able to pick a data source order buy you anyways? Do you think you win something by preferring say RADB over LEVEL3 over SAVVIS over ARIN over RIPE over...? You have no real idea where your customer's are keeping their records, or their customers, etc. Where do you draw the line on who's data you look at, and why do we need yet another system where people are left to make a judgement call over who's data they should trust? Personally I'm of the belief that every ISP running their own IRR db is a very bad idea, which is why I have chosen not to run one myself. To quote Vijay, it doesn't scale. The last thing the already very broken IRR system needs is more crap data by more random people spread out over more databases, and the majority of the current db's probably need to be shut down too. There is no reason that this process needs to be politicized, or cost anyone any money to use. Again, we've made a horrible system here. One reasonable solution is to have the server side run the complete query off its local database, and pass the complete results for a prefix-list back to the querier in a single transaction. This is how filtergen.level3.com works, though I personally find their system is be excessively slow. In IRRPT 2.0 development I'm writing a similar type of remote filter generator, which I hope will be useful to some people. > If folks mistakenly believe there is a 1:1 correspendence between IRR > data and BGP tables, they will lose. The IRR data is more of a > "flight plan", a set of what-is-possible per the originator of the > data. > > [snip] > > people query and boom you're in the system. What tends to happen is > > someone puts a route into a database and then completely forgets about > > it, so there are a huge number of completely bogus routes out there > > which are never going to get cleaned up. > > Lots of folks set up systems for provisioning without deprovisioning. > This is not an IRR problem, but a sloppy-human problem. Folks that > get stuck with provisioning generally aren't incented to remove billable > resources. CF good processes and management with backbone. There is plenty of motivation to add data to IRR to make your announcements work, but no motivation at all to remove data when it is no longer needed. Nobody sees a problem with this until you step back and realize that a lot of networks have IRR records so sloppy that they list nearly every route on the Internet. Why bother filtering at all then? I think if it was as simple as seeing a list of your routes (or customers in your as-set, etc) and having a checkbox to delete old data, people would be more reasonable about maintaining it. RPSL is scary and confusing to a lot of people (and it should probably be scary to everyone at any rate :P), there is no reason it needs to be like this. -- Richard A Steenbergen http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) From swmike at swm.pp.se Wed Aug 12 22:47:43 2009 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Thu, 13 Aug 2009 05:47:43 +0200 (CEST) Subject: Residential BW Planning In-Reply-To: <4A820889.6080906@sleepycatz.com> References: <4A820889.6080906@sleepycatz.com> Message-ID: On Tue, 11 Aug 2009, sjk wrote: > I am trying to perform some capacity planning for some of our > residential pops, but the old calcs I used to use seem useless -- as > they were adapted from the dialup days and relied upon a percentage of > users online (~50%) and a percentage of concurrent transmission (~19%). > My present scenario involves a micro-pop terminating 250 residences > where users are expecting 4 mb/s. So I am looking for some baseline to > begin at, so I am wondering what others are doing. > > Any thoughts are appreciated. I've seen everything from ~20 kilobit/s/user at peak, to over 400 (measured at 5 minute average with mrtg with ~500 users). It differs a lot if you get the "mom and pop"-userbase or if you have bunch of students who are downloading/streaming stuff all the time. Generally, comparing ADSL 8/1 to ETTH 10/10 or 100/100, download doesn't differ much, but symmetric speed users put out factor 4 more traffic (8/1 users upload half as much as what they download, ETTH users upload double what they download). -- Mikael Abrahamsson email: swmike at swm.pp.se From zbynek at dialtelecom.cz Thu Aug 13 04:29:17 2009 From: zbynek at dialtelecom.cz (Zbynek Pospichal) Date: Thu, 13 Aug 2009 11:29:17 +0200 Subject: Tinet Message-ID: <4A83DCED.8070306@dialtelecom.cz> Hi, anyone else who see routing problems (some sites unreachable, lags in traceroutes etc.) through Tinet (former Tiscali/AS3257)? BR, Zbynek From daniel at net2ez.com Thu Aug 13 04:53:50 2009 From: daniel at net2ez.com (Daniel Faubel) Date: Thu, 13 Aug 2009 02:53:50 -0700 Subject: Tinet References: <4A83DCED.8070306@dialtelecom.cz> Message-ID: <702C3A3F3EDC0C4DAE40374D274240CC067934@lax4-m4.ezdom.net2ez.com> We have been getting reports of issue. Daniel Faubel Net2EZ - Managed Data Centers Network Manager 310-426-9933 x1 NOC 310-426-9933 x110 Direct daniel at net2ez.com ________________________________ From: Zbynek Pospichal [mailto:zbynek at dialtelecom.cz] Sent: Thu 8/13/2009 2:29 AM To: nanog at nanog.org Subject: Tinet Hi, anyone else who see routing problems (some sites unreachable, lags in traceroutes etc.) through Tinet (former Tiscali/AS3257)? BR, Zbynek From nick at foobar.org Thu Aug 13 06:09:10 2009 From: nick at foobar.org (Nick Hilliard) Date: Thu, 13 Aug 2009 12:09:10 +0100 Subject: Follow up to previous post regarding SAAVIS In-Reply-To: <20090813030323.GT51443@gerbil.cluepon.net> References: <4A833047.3000003@justinshore.com> <20090812213038.B23661CC31@ptavv.es.net> <20090812214103.GA42448@gweep.net> <20090812225510.GP51443@gerbil.cluepon.net> <20090813011638.GR51443@gerbil.cluepon.net> <20090813020649.GB70070@gweep.net> <20090813030323.GT51443@gerbil.cluepon.net> Message-ID: <4A83F456.1010604@foobar.org> On 13/08/2009 04:03, Richard A Steenbergen wrote: > In fact this is one of > the reasons why querying data from RIPE is such a pain, their query > language lacks a recursive service side expansion mechanism so the > transaction latency turns querying a large AS-SET into a multi-hour or > day long operation. I've brought this to RIPE's attention before, but the suggestion was met with a sharp inhalation of breath and a discussion about exactly how difficult that might be. The ripe whoisd code-base is too complicated. [Server side UTF8 support would be nice too, but for entirely different reasons - apparently there are some people in the world who need character sets outside ascii7. Who knew?] > Do you think you win something by preferring say RADB over > LEVEL3 over SAVVIS over ARIN over RIPE over...? You have no real idea > where your customer's are keeping their records, or their customers, > etc. Where do you draw the line on who's data you look at, and why do we > need yet another system where people are left to make a judgement call > over who's data they should trust? Yes, this is a bit of a mess alright. > There is plenty of motivation to add data to IRR to make your > announcements work, but no motivation at all to remove data when it is > no longer needed. Nobody sees a problem with this until you step back > and realize that a lot of networks have IRR records so sloppy that they > list nearly every route on the Internet. Why bother filtering at all > then? Data with "source: RIPE" is quite good from this point of view, as the mnt-lower: and mnt-routes: fields are delegated by the RIR function in RIPE. There's no doubt that you can get all sorts of crap from non-RIR irrdbs, though. > I think if it was as simple as seeing a list of your routes (or > customers in your as-set, etc) and having a checkbox to delete old data, > people would be more reasonable about maintaining it. RPSL is scary and > confusing to a lot of people (and it should probably be scary to > everyone at any rate :P), there is no reason it needs to be like this. RPSL is scary both from an end-user and a developer point of view. From the developer point of view, if the requirement to support AS path regular expressions were removed, that would remove lots of scary code from irrtoolset. The grammar is also very rich, which is just another word for complicated. From the user point of view, as a means of maintaining full policy routing configuration information (which seemed to be its original goal), it fails quite badly: too complicated to be understood easily; to limited to fulfil its objective. Like lots of technologies which didn't take off as intended (x.500, multicast, etc), it's found a stable niche, although there is no doubt that its prefix filtering capability is very undervalued. Nick From jmaimon at ttec.com Thu Aug 13 09:07:29 2009 From: jmaimon at ttec.com (Joe Maimon) Date: Thu, 13 Aug 2009 10:07:29 -0400 Subject: Follow up to previous post regarding SAAVIS In-Reply-To: <20090812212305.GN51443@gerbil.cluepon.net> References: <75cb24520908120709u26dddeacs6dd0d4241d40f8e1@mail.gmail.com> <20090812203753.GA49057@gweep.net> <20090812212305.GN51443@gerbil.cluepon.net> Message-ID: <4A841E21.1070207@ttec.com> Richard A Steenbergen wrote: > On Wed, Aug 12, 2009 at 04:57:07PM -0400, Jared Mauch wrote: >> I've come to the conclusion that if someone put a nice web2.0+ >> interface on creating and managing these objects it would be a lot >> easier. > > Agreed, this is one of the projects I've been working on just haven't > had the time to finish it. But please allow me to put in a shameless > plug for IRR PowerTools, which many networks (including a couple tier > 1s) use to do their IRR: > > http://sourceforge.net/projects/irrpt/ > > The highlights are: > > * Automated retrieval of prefixes registered behind an IRR Object. > * Automatic exclusion of bogon or other configured undesirable routes. > * Tracking and long-term recording of prefix changes over time. > * Automatic aggregation to optimize data and reduce unnecessary changes. > * E-mail updates, letting users know that their change was processed. > * E-mail alerts to the ISP, letting them know of new routing changes. > * E-mail alerts to non-IRR using networks, with plain text changes. > * Router config generation, for easy automated config deployment. > > I'm also in the process of beta testing a new 2.0 version which will be > significantly rewritten for easier more scalable use, have a lot fewer > dependencies, integrate better with db backend systems to customer > prefix-list management, and fully support IPv6. Oh and there might just > be a web gui for managing and using it too, if I can find a decent web > developer who will do it for free. :) I'm hoping to have this out in the > next couple of months. > The longer a network develops without using or maintaining IRR data, the more difficult the transition becomes. A truly awesome capability would be to have some way to slurp in current configuration and output IRR objects that can then generate a functionally identical configuration. Even without that, I would happily settle for any improvements to irr tools, powertools or toolsets. I am sort of disappointed that there seemed to be far less then deserved support from those with a stake in this, the registries and vendors. Joe From nanog-post at rsuc.gweep.net Thu Aug 13 11:03:24 2009 From: nanog-post at rsuc.gweep.net (Joe Provo) Date: Thu, 13 Aug 2009 12:03:24 -0400 Subject: Follow up to previous post regarding SAAVIS In-Reply-To: <20090813030323.GT51443@gerbil.cluepon.net> References: <4A833047.3000003@justinshore.com> <20090812213038.B23661CC31@ptavv.es.net> <20090812214103.GA42448@gweep.net> <20090812225510.GP51443@gerbil.cluepon.net> <20090813011638.GR51443@gerbil.cluepon.net> <20090813020649.GB70070@gweep.net> <20090813030323.GT51443@gerbil.cluepon.net> Message-ID: <20090813160324.GA31413@gweep.net> On Wed, Aug 12, 2009 at 10:03:23PM -0500, Richard A Steenbergen wrote: > On Wed, Aug 12, 2009 at 10:06:49PM -0400, Joe Provo wrote: > > On Wed, Aug 12, 2009 at 08:16:38PM -0500, Richard A Steenbergen wrote: > > [snip] > > > Unfortunately the distributed nature of the databases is one of the > > > biggest problems with the IRR system. Anyone can run an irrd, there is > > > > You misspelled "largest strength". FOlks get to choose which registries > > to believe in what order, not required to have a single [politicized] > > entity. > > Well, actually, no. I'm not aware of any mechanism under which you can > effectively choose who to believe and in what order, nor do I think that > it would make any real difference in the long run even if you could. Experience proves otherwise. L3's filtergen is a great counter-example, where the customer-specific import policy dictates sources to believe regardless of what other stuff is in their local mirror. It happily drops prefixes not matching, so it does "make a real difference" WRT customer filtering. I'm not familiar with DTAG's tools, but would be shocked if they were less featureful. For querying other databases, see IRRd's !s syntax, which specifies sources in order. Also see Net:IRR's $whois->sources() method. For tools based on these, I would presume it be up to your implementation or policy expression as to how you decide the handling on multiple matches. When mentioned, usually the first which matches is specified as 'the one', which is why search order matters. What other purpose does specifying a search order serve? > IRR database mirroring is like being a tier 1, you have to peer with > every other database out there in order to obtain a full view. That Funny, subject of the thread is filtering customers. I don't need to take the same point of view of the RADB ("RADB's mission is to mirror all component databases so as to provide the most complete view possible of the entire IRR.") to do that, just a set of databases in which my customers can be/must be registered. Once upon a time, 3561 had a highly automated and effective way of doing this based in part upon running their own DB and that being the default/requirement for "non-advanced" customers. [snip] > Basically the only thing you have control over are the list of IRR > databases which are searched, but the results which are returned are a > superset of all databases which you selected to search. You don't get to > say "only listen to results from LEVEL3's db for this object unless they > don't have results there, in which case you listen to SAVVIS" or > anything like that. If I am running a tool to generate filter lists for my customers, I want to believe my RR, the local RIR, some other RIR that is well run, and then maybe my upstream. Specify that search order and believe the first match. Job done. If you have highly clued downstreams, go the filtergen route and tune source-believability based on customer, or cook up another avenue. There is nothing inherent in the system to prevent this. [snip] > from all the sources is always importing correctly, etc. And even after > you do all this, what does being able to pick a data source order buy > you anyways? Do you think you win something by preferring say RADB over > LEVEL3 over SAVVIS over ARIN over RIPE over...? Yes, reduced queries and the ability to ignore Bob's Bait and Tackle DB if I know it is part of the "piles of junk databases" you posit will exist. See above. > Where do you draw the line on who's data you look at, and why do we > need yet another system where people are left to make a judgement call > over who's data they should trust? I'm not sure who has a better viewpoint on what my customers can/should emit cross my network than me, so yeah I should make the call regarding what databases my customers need to be in for my business. Obviously for multihomed or well-meshed customers you have to approach that sanely or you'll get serious pushback from folks registered elsewhere. In the earlier 3561 days, I had to get them to eat non-MCI sources for us so I wouldn't be doubly & trebly registered. Assuming a perfect global datastore will fail. It doesn't exist now, and migrating there to such a mythical beast is impossible. Run your corner as cleanly as you can and apply as much error correction as possible to the outside world. Since this topic is about running one's corner cleanly, taking the input from known-garbage is a bad plan. > Personally I'm of the belief that every ISP running their own IRR db is > a very bad idea, which is why I have chosen not to run one myself. > To quote Vijay, it doesn't scale. The last thing the already very broken > IRR system needs is more crap data by more random people spread out over > more databases, and the majority of the current db's probably need to be > shut down too. Centralized scales better than distributed? Quick, call the 80s - we need HOSTS.TXT back. Of course it isn't applicable for every 10-prefix shop that happens to run BGP because they have multiple 0/0s, but that is merely due to the effort not being worth the return for those people, not anything to do with scaling of the IRR system. If small fries did run their own nodes, they would need to get their providers to slurp the data, or be an LIR or.... I don't see a massive clamor for small fries though. The existing open-door IRR policy has only grown slowly over the years, not exploded. Heck, some older ones [cf this thread's subject, BELL, et al] seem to no longer be used by their owners and just might not be worth querying. So yeah, I think a level of reasonable discrimination based on existing data quality encourages increased data quality. > There is no reason that this process needs to be > politicized, or cost anyone any money to use. Anytime you go down the road of advocating authority centralization, you'll start getting people politicizing the process [cf icann, alternate roots, all the random frothing-at-the-mouth-until-they-fall-over types]. I rather think that can be avoided by properly embracing the distributed databases that do indeed function. Some can be side-stepped with RIR- based IRRs, and decently distributed down to LIRs, but we all know ARIN is still playing catchup here so it doesn't help our sphere in the near term. Money? Assuming a registry-based or provider-customer based DBs then it would be part of the existing relationship, no? Fees were being used at RADB in part as an incentive to get folks to clean up dead records. In Oct of 2002 Larry Blunk reported that they trimmed from 3150 maintainers down to 1972, though I'm not finding any numbers on non-maintainer objects purged ... I'm sure some were just M&A detritus that moved from one maintainer to another. > Again, we've made a horrible system here. I think you've misspelled 'front end'. The system certainly seems to function, and the entire intent was that SPs would build their own customer-facing tools as well as internal tools. Seems we've fallen down in that regard, but irrpt [even if in php :-P] and the revival of IRRtoolset are indications that folks are still interested in building the internal widgets. In general I think you'd agree that the 'back end' of most all service providers did not keep pace with the growth of commoditization of service. > One reasonable solution is to have the server side run the complete > query off its local database, and pass the complete results for a > prefix-list back to the querier in a single transaction. [snip] Again, your complaint isn't against "the IRR", but regarding an implementation specific ... which aligns with what 3561 used to do. We are straying dangerously close back to the thread topic. [snip] > > Lots of folks set up systems for provisioning without deprovisioning. > > This is not an IRR problem, but a sloppy-human problem. Folks that > > get stuck with provisioning generally aren't incented to remove billable > > resources. CF good processes and management with backbone. > > There is plenty of motivation to add data to IRR to make your > announcements work, but no motivation at all to remove data when it is > no longer needed. Nobody sees a problem with this until you step back > and realize that a lot of networks have IRR records so sloppy that they > list nearly every route on the Internet. See what I wrote above; that is a provisioning/deprovisioning problem, not an IRR problem, and you know that. I know plenty of ISPs that don't perceive their lousy half-hearted attempts at deprovisioning *any* part of service to be a big deal, since improvements there doesn't make them money. As long as physical ports and circuits go back into inventory to sell to someone else, they could care less what data is left dangling. Sad but true. -- RSUC / GweepNet / Spunk / FnB / Usenix / SAGE From Rod.Beck at hiberniaatlantic.com Thu Aug 13 12:33:52 2009 From: Rod.Beck at hiberniaatlantic.com (Rod Beck) Date: Thu, 13 Aug 2009 18:33:52 +0100 Subject: TransAtlantic 40 Gig Waves References: Message-ID: <1E8B940C5E21014AB8BE70B975D40EDB0162857C@bert.HiberniaAtlantic.local> http://www.hiberniaatlantic.com/documents/Hibernia40GAcrossAtlanticPR-JSA2-FINAL.pdf Roderick S. Beck Director of European Sales Hibernia Atlantic Budapest, New York, and Paris From RWerber at epiknetworks.com Thu Aug 13 12:35:53 2009 From: RWerber at epiknetworks.com (Ryan Werber) Date: Thu, 13 Aug 2009 13:35:53 -0400 Subject: Tinet References: <4A83DCED.8070306@dialtelecom.cz> Message-ID: <4AF1A8AD5357984C95657E3F512AD692C68286@2BWEXCH01.Epik.local> We have transport and transit with them all through North America and currently we do not see any issues. Latency all across their network is within normal parameters. Perhaps clarify where you are having issues? Ryan Werber Epik Networks AS21513 -----Original Message----- From: Zbynek Pospichal [mailto:zbynek at dialtelecom.cz] Sent: Thursday, August 13, 2009 5:29 AM To: nanog at nanog.org Subject: Tinet Hi, anyone else who see routing problems (some sites unreachable, lags in traceroutes etc.) through Tinet (former Tiscali/AS3257)? BR, Zbynek From regnauld at catpipe.net Thu Aug 13 12:43:35 2009 From: regnauld at catpipe.net (Phil Regnauld) Date: Thu, 13 Aug 2009 19:43:35 +0200 Subject: Tinet In-Reply-To: <4AF1A8AD5357984C95657E3F512AD692C68286@2BWEXCH01.Epik.local> References: <4A83DCED.8070306@dialtelecom.cz> <4AF1A8AD5357984C95657E3F512AD692C68286@2BWEXCH01.Epik.local> Message-ID: <20090813174335.GA12270@bluepipe.dk> Some hosting we have in Paris was hit by an outage between 0100 GMT and 0800 GMT which seemed to be related to a software upgrade at Tinet. The affected path was between Copenhagen (TDC) and Galacsys/AS28855, via former Tiscali. P. Ryan Werber (RWerber) writes: > We have transport and transit with them all through North America and > currently we do not see any issues. Latency all across their network is > within normal parameters. > > Perhaps clarify where you are having issues? > > Ryan Werber > Epik Networks > AS21513 > > -----Original Message----- > From: Zbynek Pospichal [mailto:zbynek at dialtelecom.cz] > Sent: Thursday, August 13, 2009 5:29 AM > To: nanog at nanog.org > Subject: Tinet > > Hi, > > anyone else who see routing problems (some sites unreachable, lags in > traceroutes etc.) through Tinet (former Tiscali/AS3257)? > > BR, > Zbynek From mcallahan at bullseyetelecom.com Thu Aug 13 12:44:21 2009 From: mcallahan at bullseyetelecom.com (Mike Callahan) Date: Thu, 13 Aug 2009 13:44:21 -0400 Subject: TransAtlantic 40 Gig Waves In-Reply-To: <1E8B940C5E21014AB8BE70B975D40EDB0162857C@bert.HiberniaAtlantic.local> Message-ID: <90DF793301873F469B0B7878B4CFD4F40140E2E8C500@EXMAIL.bullseyetelecom.com> Just out of curriousity, what type of equipment is used to terminate circuits of this capacity? My experience stops at the 10GB mark. Thanks, Mike -----Original Message----- From: Rod Beck [mailto:Rod.Beck at hiberniaatlantic.com] Sent: Thursday, August 13, 2009 1:34 PM To: nanog at nanog.org Subject: TransAtlantic 40 Gig Waves http://www.hiberniaatlantic.com/documents/Hibernia40GAcrossAtlanticPR-JSA2-FINAL.pdf Roderick S. Beck Director of European Sales Hibernia Atlantic Budapest, New York, and Paris From joelja at bogus.com Thu Aug 13 13:44:51 2009 From: joelja at bogus.com (Joel Jaeggli) Date: Thu, 13 Aug 2009 11:44:51 -0700 Subject: TransAtlantic 40 Gig Waves In-Reply-To: <90DF793301873F469B0B7878B4CFD4F40140E2E8C500@EXMAIL.bullseyetelecom.com> References: <90DF793301873F469B0B7878B4CFD4F40140E2E8C500@EXMAIL.bullseyetelecom.com> Message-ID: <4A845F23.8070208@bogus.com> pos oc-768 pre standard 40G lr4 4 in 1 40 gig mux 100gig 10 in 1 mux with some very tight engineering tolerances probably others Mike Callahan wrote: > Just out of curriousity, what type of equipment is used to terminate circuits of this capacity? My experience stops at the 10GB mark. > > Thanks, > > Mike > > > -----Original Message----- > From: Rod Beck [mailto:Rod.Beck at hiberniaatlantic.com] > Sent: Thursday, August 13, 2009 1:34 PM > To: nanog at nanog.org > Subject: TransAtlantic 40 Gig Waves > > > http://www.hiberniaatlantic.com/documents/Hibernia40GAcrossAtlanticPR-JSA2-FINAL.pdf > > Roderick S. Beck > Director of European Sales > Hibernia Atlantic > Budapest, New York, and Paris > From mmc at internode.com.au Thu Aug 13 18:09:38 2009 From: mmc at internode.com.au (Matthew Moyle-Croft) Date: Fri, 14 Aug 2009 08:39:38 +0930 Subject: TransAtlantic 40 Gig Waves In-Reply-To: <1E8B940C5E21014AB8BE70B975D40EDB0162857C@bert.HiberniaAtlantic.local> References: <1E8B940C5E21014AB8BE70B975D40EDB0162857C@bert.HiberniaAtlantic.local> Message-ID: <4A849D32.3040604@internode.com.au> Congrats Rod. Southern Cross and Nortel have been trialing 40Gbps waves on the 8000km segment from Hawaii to New Zealand. http://www.itnews.com.au/News/152866,southern-cross-trials-40gbps-nortel-kit.aspx The 8000km segment is a LONG way - a very long way but it should mean stability for any cable system (I'm not sure there are segments that are much longer on any other system) - the bandwidth limit hasn't been hit yet! MMC Rod Beck wrote: > http://www.hiberniaatlantic.com/documents/Hibernia40GAcrossAtlanticPR-JSA2-FINAL.pdf > > Roderick S. Beck > Director of European Sales > Hibernia Atlantic > Budapest, New York, and Paris > > From andyzweb at gmail.com Thu Aug 13 22:27:27 2009 From: andyzweb at gmail.com (Andrew Euell) Date: Thu, 13 Aug 2009 23:27:27 -0400 Subject: Follow up to previous post regarding SAAVIS In-Reply-To: <75cb24520908120709u26dddeacs6dd0d4241d40f8e1@mail.gmail.com> References: <75cb24520908120709u26dddeacs6dd0d4241d40f8e1@mail.gmail.com> Message-ID: "the pccw lesson, which is also the turk-telecom lesson" tangent here: what was the pccw and turk-telecom thing? is the turk telco thing the Youtube fiasco? On Wed, Aug 12, 2009 at 10:09 AM, Christopher Morrow < morrowc.lists at gmail.com> wrote: > On Wed, Aug 12, 2009 at 9:57 AM, Drew Weaver > wrote: > > Anyone know why SAAVIS would be allowing PEER1 (AS 13768) to advertise > routes for whatever IP addresses they want? > > sadly savvis didn't learn the pccw lesson, which is also the > turk-telecom lesson which is also the as7007 lesson which is... fairly > sad really in 2009. > > for the sake of $diety put a prefix-filter on your customer bgp > sessions, it ain't hard! > > -chris > > > route-views.oregon-ix.net>sh ip bgp 173.45.110.0 | i 13768 > > 2905 701 3561 13768 > > 1221 4637 3561 13768 > > 3549 3561 13768 > > 3277 3267 174 3561 13768 > > 6539 3561 13768 > > 16150 3549 3561 13768 > > 701 3561 13768 > > 3267 174 3561 13768 > > 6453 3561 13768 > > 3582 3701 3356 3561 13768 > > > > This is probably a fairly major problem... > > > > -Drew > > > > > > -- Andrew Euell andyzweb [at] gmail [dot] com From morrowc.lists at gmail.com Thu Aug 13 22:31:59 2009 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Thu, 13 Aug 2009 23:31:59 -0400 Subject: Follow up to previous post regarding SAAVIS In-Reply-To: References: <75cb24520908120709u26dddeacs6dd0d4241d40f8e1@mail.gmail.com> Message-ID: <75cb24520908132031g18ed0a74sff5ea907b43f00f1@mail.gmail.com> On Thu, Aug 13, 2009 at 11:27 PM, Andrew Euell wrote: > "the pccw lesson, which is also the > turk-telecom lesson" > > tangent here: what was the pccw and turk-telecom thing? > is the turk telco thing the Youtube fiasco? pccw + pktelecom == youtube incident turk-telecom leaked covad + a bunch of other things ... 4 years back at either the time of NANOG or a US Holiday (Christmas??) Both incidents were: "Providers who didn't filter their customer(s)" -chris > On Wed, Aug 12, 2009 at 10:09 AM, Christopher Morrow > wrote: >> >> On Wed, Aug 12, 2009 at 9:57 AM, Drew Weaver >> wrote: >> > Anyone know why SAAVIS would be allowing PEER1 (AS 13768) to advertise >> > routes for whatever IP addresses they want? >> >> sadly savvis didn't learn the pccw lesson, which is also the >> turk-telecom lesson which is also the as7007 lesson which is... fairly >> sad really in 2009. >> >> for the sake of $diety put a prefix-filter on your customer bgp >> sessions, it ain't hard! >> >> -chris >> >> > route-views.oregon-ix.net>sh ip bgp 173.45.110.0 | i 13768 >> > ?2905 701 3561 13768 >> > ?1221 4637 3561 13768 >> > ?3549 3561 13768 >> > ?3277 3267 174 3561 13768 >> > ?6539 3561 13768 >> > ?16150 3549 3561 13768 >> > ?701 3561 13768 >> > ?3267 174 3561 13768 >> > ?6453 3561 13768 >> > ?3582 3701 3356 3561 13768 >> > >> > This is probably a fairly major problem... >> > >> > -Drew >> > >> > >> > > > > -- > Andrew Euell > andyzweb [at] gmail [dot] com > From kanagaraj at globaltransit.net Fri Aug 14 02:24:47 2009 From: kanagaraj at globaltransit.net (Kanagaraj) Date: Fri, 14 Aug 2009 15:24:47 +0800 Subject: Follow up to previous post regarding SAAVIS In-Reply-To: <20090813011638.GR51443@gerbil.cluepon.net> References: <4A833047.3000003@justinshore.com> <20090812213038.B23661CC31@ptavv.es.net> <20090812214103.GA42448@gweep.net> <20090812225510.GP51443@gerbil.cluepon.net> <20090813011638.GR51443@gerbil.cluepon.net> Message-ID: <4A85113F.3050700@globaltransit.net> > The other problem is that when a SP has a customer who "can't figure it > out", a typical course of action is to just "register the route for > them" rather than try to explain it to them. Unfortunately, the same > thing as above happens here, you end up with a big pile of people who > register a big pile of routes in a big pile of random databases, often > times completely unnecessarily, and they'll never be removed either. > > The biggest problem with the entire system is the way that data gets > into it, and the lack of incentive for people to ever remove data from > it. But as a mechanism to allow the routes which need to be allowed, and > mostly prevent accidental leaks, it works. > Agreed. Wish most providers take the extra mile effort to advise and facilitate customers on the process. The redundant entries are annoying :-) From Rod.Beck at hiberniaatlantic.com Fri Aug 14 04:14:59 2009 From: Rod.Beck at hiberniaatlantic.com (Rod Beck) Date: Fri, 14 Aug 2009 10:14:59 +0100 Subject: TransAtlantic 40 Gig Waves References: <1E8B940C5E21014AB8BE70B975D40EDB0162857C@bert.HiberniaAtlantic.local> <4A849D32.3040604@internode.com.au> Message-ID: <1E8B940C5E21014AB8BE70B975D40EDB0162859C@bert.HiberniaAtlantic.local> Obviously using 40 gig waves as the foundation blocks of one's network provides some economies of scale and per unit capex cost savings. I would be curious if anyone knows how to convert this SONET/SDH 40 gig waves into a 40 gig Ethernet handoff? Afterall, OC768 route cards are a tad expensive ... Roderick S. Beck Director of European Sales Hibernia Atlantic Budapest, New York, and Paris http://www.hiberniaatlantic.com Wireless: 33+6+8692+5357. AOL Messenger: GlobalBandwidth rod.beck at hiberniaatlantic.com info at globalwholesalebandwidht.com ``Unthinking respect for authority is the greatest enemy of truth.'' Albert Einstein. -----Original Message----- From: Matthew Moyle-Croft [mailto:mmc at internode.com.au] Sent: Fri 8/14/2009 12:09 AM To: Rod Beck Cc: nanog at nanog.org Subject: Re: TransAtlantic 40 Gig Waves Congrats Rod. Southern Cross and Nortel have been trialing 40Gbps waves on the 8000km segment from Hawaii to New Zealand. http://www.itnews.com.au/News/152866,southern-cross-trials-40gbps-nortel-kit.aspx The 8000km segment is a LONG way - a very long way but it should mean stability for any cable system (I'm not sure there are segments that are much longer on any other system) - the bandwidth limit hasn't been hit yet! MMC Rod Beck wrote: > http://www.hiberniaatlantic.com/documents/Hibernia40GAcrossAtlanticPR-JSA2-FINAL.pdf > > Roderick S. Beck > Director of European Sales > Hibernia Atlantic > Budapest, New York, and Paris > > From ras at e-gerbil.net Fri Aug 14 08:17:45 2009 From: ras at e-gerbil.net (Richard A Steenbergen) Date: Fri, 14 Aug 2009 08:17:45 -0500 Subject: TransAtlantic 40 Gig Waves In-Reply-To: <1E8B940C5E21014AB8BE70B975D40EDB0162859C@bert.HiberniaAtlantic.local> References: <1E8B940C5E21014AB8BE70B975D40EDB0162857C@bert.HiberniaAtlantic.local> <4A849D32.3040604@internode.com.au> <1E8B940C5E21014AB8BE70B975D40EDB0162859C@bert.HiberniaAtlantic.local> Message-ID: <20090814131745.GB51443@gerbil.cluepon.net> On Fri, Aug 14, 2009 at 10:14:59AM +0100, Rod Beck wrote: > Obviously using 40 gig waves as the foundation blocks of one's network > provides some economies of scale and per unit capex cost savings. > > I would be curious if anyone knows how to convert this SONET/SDH 40 > gig waves into a 40 gig Ethernet handoff? > > Afterall, OC768 route cards are a tad expensive ... I'm not aware of any solution that isn't going to be a lot more expensive than just using the native OC768 card (which isn't "that" expensive in crazy bankrupt carrier dollars, it's just not in the same ballpark as 10GE solutions). This in turn is going to be a lot more expensive than just running 4x10GE, for the moment. Of course native 40GE is in the works, so eventually this will make technical and financial sense, just not yet. But this is one of the major reasons I've been a proponent of 40GE standardization instead of focusing solely on 100GE, 40 maps directly to the next-generation optical technology and allows you to efficiently and affordably transport ethernet over long distances, whereas 100 is largely just a fancy cable management solution for hiding multiple parallel links (i.e. 10x10G) within a datacenter. Rod, do you know if the 40G waves increased the spectrum efficiency of your fiber? On land systems they pretty much break even, i.e. you can have a 100GHz 40G channels or 4x25GHz 10G channels but at the end of the day you still get the same amount of signal out of the fiber. I don't know whats being done on undersea cables though. Eventually this will get better too, and 40G will become the "native" wavelength standard with 10G being muxed onto them, similar to what we saw with the transition from 2.5G->10G 10 years ago. -- Richard A Steenbergen http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) From alexb at ripe.net Fri Aug 14 09:02:05 2009 From: alexb at ripe.net (Alex Band) Date: Fri, 14 Aug 2009 16:02:05 +0200 Subject: IPv6 Interview: XS4ALL rolls out native v6 to DSL customers Message-ID: <2197264B-1F7C-44EB-9607-DBE647AC8695@ripe.net> http://www.youtube.com/watch?v=f3WcWBIQ11A Marco Hogewoning of Dutch ISP XS4ALL talks about the roll out of IPv6 in their 300,000 customer network. German modem vendor AVM supplies them with a CPE that supports native IPv6, although it does have some limitations that need to be ironed out. Marco talks about how they got in touch with them, how they handle the spec and the issues, and how the project gained traction when the Sales department got interested. Enjoy, -Alex From jlewis at lewis.org Fri Aug 14 09:24:31 2009 From: jlewis at lewis.org (Jon Lewis) Date: Fri, 14 Aug 2009 10:24:31 -0400 (EDT) Subject: Any Qwest routing engineers? Message-ID: I hate doing this, but I'd appreciate it if someone who can look at routing issues inside AS209 would contact me. We're not a customer, but one of our customers noticed they (actually, our whole network) couldn't reach one of your multihomed customers. Traces stop at chi-edge-25.inet.qwest.net. Rerouting the traffic to avoid AS209 "solved" the problem...but perhaps we can get the real problem found & fixed? ---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From Rod.Beck at hiberniaatlantic.com Fri Aug 14 09:30:34 2009 From: Rod.Beck at hiberniaatlantic.com (Rod Beck) Date: Fri, 14 Aug 2009 15:30:34 +0100 Subject: TransAtlantic 40 Gig Waves References: <1E8B940C5E21014AB8BE70B975D40EDB0162857C@bert.HiberniaAtlantic.local> <4A849D32.3040604@internode.com.au> <1E8B940C5E21014AB8BE70B975D40EDB0162859C@bert.HiberniaAtlantic.local> <20090814131745.GB51443@gerbil.cluepon.net> Message-ID: <1E8B940C5E21014AB8BE70B975D40EDB016285A9@bert.HiberniaAtlantic.local> -----Original Message----- From: Richard A Steenbergen [mailto:ras at e-gerbil.net] Sent: Fri 8/14/2009 2:17 PM To: Rod Beck Cc: Matthew Moyle-Croft; nanog at nanog.org Subject: Re: TransAtlantic 40 Gig Waves On Fri, Aug 14, 2009 at 10:14:59AM +0100, Rod Beck wrote: > Obviously using 40 gig waves as the foundation blocks of one's network > provides some economies of scale and per unit capex cost savings. > > I would be curious if anyone knows how to convert this SONET/SDH 40 > gig waves into a 40 gig Ethernet handoff? > > Afterall, OC768 route cards are a tad expensive ... I'm not aware of any solution that isn't going to be a lot more expensive than just using the native OC768 card (which isn't "that" expensive in crazy bankrupt carrier dollars, it's just not in the same ballpark as 10GE solutions). This in turn is going to be a lot more expensive than just running 4x10GE, for the moment. Of course native 40GE is in the works, so eventually this will make technical and financial sense, just not yet. But this is one of the major reasons I've been a proponent of 40GE standardization instead of focusing solely on 100GE, 40 maps directly to the next-generation optical technology and allows you to efficiently and affordably transport ethernet over long distances, whereas 100 is largely just a fancy cable management solution for hiding multiple parallel links (i.e. 10x10G) within a datacenter. Rod, do you know if the 40G waves increased the spectrum efficiency of your fiber? On land systems they pretty much break even, i.e. you can have a 100GHz 40G channels or 4x25GHz 10G channels but at the end of the day you still get the same amount of signal out of the fiber. I don't know whats being done on undersea cables though. Eventually this will get better too, and 40G will become the "native" wavelength standard with 10G being muxed onto them, similar to what we saw with the transition from 2.5G->10G 10 years ago. -- Richard A Steenbergen http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) Agreed. I think it was a mistake to put all the effort into 100 GigE when it is not even clear a lot of fibre can support 100 Gig waves. As I understand the bit rate depends on the geometrical properties of the fibre. And yes, IP engineers are telling me is that there are no economically viable 40 gig SONET/Ethernet conversion boxes. My understanding is that we are getting a big spectrum efficiency gain. The press release states the system's potential is 10.16 terabits. Before the upgrade, it was 6.4 terabits or 80 10 gig waves per fibre pair (two cables, four fiber pairs each). I will check that figure. From chris at uplogon.com Fri Aug 14 10:03:15 2009 From: chris at uplogon.com (Chris Gotstein) Date: Fri, 14 Aug 2009 10:03:15 -0500 Subject: IPv6 Addressing Help Message-ID: <4A857CB3.10600@uplogon.com> We are a small ISP that is in the process of setting up IPv6 on our network. We already have the ARIN allocation and i have a couple routers and servers running dual stack. Wondering if someone out there would be willing to give me a few pointers on setting up my addressing scheme? I've been mulling over how to do it, and i think i'm making it more complicated than it needs to be. You can hit me offlist if you wish to help. Thanks. -- Chris Gotstein Sr Network Engineer UP Logon/Computer Connection UP 500 N Stephenson Ave Iron Mountain, MI 49801 Phone: 906-774-4847 Fax: 906-774-0335 chris at uplogon.com From jeroen at unfix.org Fri Aug 14 10:17:30 2009 From: jeroen at unfix.org (Jeroen Massar) Date: Fri, 14 Aug 2009 17:17:30 +0200 Subject: IPv6 Addressing Help In-Reply-To: <4A857CB3.10600@uplogon.com> References: <4A857CB3.10600@uplogon.com> Message-ID: <4A85800A.6020703@spaghetti.zurich.ibm.com> Chris Gotstein wrote: > We are a small ISP that is in the process of setting up IPv6 on our > network. We already have the ARIN allocation and i have a couple > routers and servers running dual stack. Wondering if someone out there > would be willing to give me a few pointers on setting up my addressing > scheme? Strange, I recall that you had to submit one when requesting address space from ARIN. Why don't you use that one? > I've been mulling over how to do it, and i think i'm making it > more complicated than it needs to be. You can hit me offlist if you > wish to help. Thanks. It all depends on your network and how you want to set it up, but for the sake of internal aggregation: * Determine the expected amount of IPv6 customers at a certain location for the next X years, making X > 2 (though 10 is probably a better idea, just in case, if don't want to do it again ;) ) * Take that number round it up to a power of 2 * Every customer gets a /48, you know the number, which is a power of 2, thus root it, and you know how many bits you need at that site eg expect 200 customers, round to power of 2 thus 256, which is 2^8, thus you will need a /48 + 8 bits = /40 at that location. You now know how much address space you need at that location for the next X years. Repeat that for all your locations / routing areas, basically the PoPs or termination points of your customers; or if you are really big do that per city/town/suburb. Keep enough space (the rounding helps there quite a bit, especially with numbers like 50k customers ;) Now you have an overview of what you expect to be allocating at each and every site. To add a little growth/future proof and to make live easy, you could either opt at this stage to round everything off to 'nice' numbers, eg only use /40's or /36's per PoP. Thus making everything the same, or doing things like grouping smaller PoPs together. Then when you have done that, take those blocks, and try to squeeze them a bit together. You should now have arrived to the address plan that you originally submitted to ARIN. Fill those blocks into a nice database, roll a PHP/shell/perl/whatever script to spit out your router configuration and presto: you are done. Enjoy the weekend ;) 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 thomas.mangin at exa-networks.co.uk Fri Aug 14 10:28:26 2009 From: thomas.mangin at exa-networks.co.uk (Thomas Mangin) Date: Fri, 14 Aug 2009 16:28:26 +0100 Subject: IPv6 Addressing Help In-Reply-To: <4A85800A.6020703@spaghetti.zurich.ibm.com> References: <4A857CB3.10600@uplogon.com> <4A85800A.6020703@spaghetti.zurich.ibm.com> Message-ID: I do not know about arin but ripe changed it's policy so you only have to say "pretty please" to receive your allocation. It better that way anyway. Thomas Mangin On 14 Aug 2009, at 16:17, Jeroen Massar wrote: > Chris Gotstein wrote: >> We are a small ISP that is in the process of setting up IPv6 on our >> network. We already have the ARIN allocation and i have a couple >> routers and servers running dual stack. Wondering if someone out >> there >> would be willing to give me a few pointers on setting up my >> addressing >> scheme? > > Strange, I recall that you had to submit one when requesting address > space from ARIN. Why don't you use that one? > >> I've been mulling over how to do it, and i think i'm making it >> more complicated than it needs to be. You can hit me offlist if you >> wish to help. Thanks. > > It all depends on your network and how you want to set it up, but for > the sake of internal aggregation: > * Determine the expected amount of IPv6 customers at a certain > location for the next X years, making X > 2 (though 10 is probably a > better idea, just in case, if don't want to do it again ;) ) > * Take that number round it up to a power of 2 > * Every customer gets a /48, you know the number, which is a power of > 2, thus root it, and you know how many bits you need at that site > > eg expect 200 customers, round to power of 2 thus 256, which is 2^8, > thus you will need a /48 + 8 bits = /40 at that location. > > You now know how much address space you need at that location for the > next X years. > > Repeat that for all your locations / routing areas, basically the PoPs > or termination points of your customers; or if you are really big do > that per city/town/suburb. Keep enough space (the rounding helps there > quite a bit, especially with numbers like 50k customers ;) > > Now you have an overview of what you expect to be allocating at each > and > every site. To add a little growth/future proof and to make live easy, > you could either opt at this stage to round everything off to 'nice' > numbers, eg only use /40's or /36's per PoP. Thus making everything > the > same, or doing things like grouping smaller PoPs together. > > Then when you have done that, take those blocks, and try to squeeze > them > a bit together. You should now have arrived to the address plan that > you > originally submitted to ARIN. > > Fill those blocks into a nice database, roll a PHP/shell/perl/whatever > script to spit out your router configuration and presto: you are done. > > Enjoy the weekend ;) > > Greets, > Jeroen > > From ras at e-gerbil.net Fri Aug 14 10:31:21 2009 From: ras at e-gerbil.net (Richard A Steenbergen) Date: Fri, 14 Aug 2009 10:31:21 -0500 Subject: Follow up to previous post regarding SAAVIS In-Reply-To: <20090813160324.GA31413@gweep.net> References: <4A833047.3000003@justinshore.com> <20090812213038.B23661CC31@ptavv.es.net> <20090812214103.GA42448@gweep.net> <20090812225510.GP51443@gerbil.cluepon.net> <20090813011638.GR51443@gerbil.cluepon.net> <20090813020649.GB70070@gweep.net> <20090813030323.GT51443@gerbil.cluepon.net> <20090813160324.GA31413@gweep.net> Message-ID: <20090814153121.GC51443@gerbil.cluepon.net> On Thu, Aug 13, 2009 at 12:03:24PM -0400, Joe Provo wrote: > > Experience proves otherwise. L3's filtergen is a great counter-example, > where the customer-specific import policy dictates sources to believe > regardless of what other stuff is in their local mirror. It happily > drops prefixes not matching, so it does "make a real difference" WRT No, level3's filtergen follows the exact "search path" rules I described previously, which has no real impact for any reasonably sized isp. For example, say I describe my as-set and aut-num and routes in altdb, you can have level3 restrict the scope of the initial query to ALTDB::myasset, and you can have level3 restrict the search path to altdb, but what happens when I have a customer in my as-set who registered their prefixes in radb? Now you have to open up the scope there, and ripe, and arin, and level3, and ntt, and savvis, etc. Now say someone comes along and slips an unauthorized route with my origin: aut-num into one of these databases. You have no way to prevent that from happening, when you run the query on my as-set/aut-num you're going to get back the superset of my legit routes + any bogus ones. And this is a good thing, because it's a lot less destructive to have bogus routes in the system than it is to give someone the ability to override legitimate routes with a bogus entry on a "more trusted" db. > customer filtering. I'm not familiar with DTAG's tools, but would be > shocked if they were less featureful. For querying other databases, see > IRRd's !s syntax, which specifies sources in order. Also see Net:IRR's > $whois->sources() method. For tools based on these, I would presume > it be up to your implementation or policy expression as to how you > decide the handling on multiple matches. When mentioned, usually the > first which matches is specified as 'the one', which is why search > order matters. What other purpose does specifying a search order serve? This is the server side search path I talked about, it has nothing to do with any specific client implementation nor is a client implementation practical. See page 34 of: http://www.irrd.net/irrd-user.pdf Again you can restrict a global query, but this provides very little practical benefit. You could dynamically restrict sources per query when you go to do the !i or !g expansion, but there is no information on what you should restrict it to, so again no practical benefit. The only thing Level3 adds that isn't part of the stock query syntax is the top level scope I mentioned above, ALTDB::AS-MYASSET. To support this recursively you would have to run multiple full queries for the full records without server side expansion, which is not practical for anyone with more than a few hundred routes. > If I am running a tool to generate filter lists for my customers, I > want to believe my RR, the local RIR, some other RIR that is well run, > and then maybe my upstream. Specify that search order and believe > the first match. Job done. If you have highly clued downstreams, go > the filtergen route and tune source-believability based on customer, > or cook up another avenue. There is nothing inherent in the system to > prevent this. ... > > Yes, reduced queries and the ability to ignore Bob's Bait and Tackle DB > if I know it is part of the "piles of junk databases" you posit will > exist. See above. This doesn't work if your customers have customers. I'm also not aware of anyone running any "bad" databases, or for that matter any databases which are of lesser security/quality than the "big boys". Short of what ripe implements because they are the RIR, there is no real security on registrations here, so it doesn't much matter if the database is level3 or bob's bait and tackle. And even given what I consider to be an excessively large list of irr databases today, from the standpoint of keeping good records, I'd be hard pressed to name one on the list who's data I should trust any less than say level3's. > Centralized scales better than distributed? Quick, call the 80s - we > need HOSTS.TXT back. A silly argument. In this case, hosts.txt is equivalent to an ISP having a human manually process an e-mail from a customer, add it to a prefix-list on a router, and then manually e-mail their upstream or peer ISPs to have them update the prefix-list, etc. In many cases centralized (or at least, restricted to some reasonably sized set, obviously nobody is proposing running the entire Internet on a single server run by a single entity) has much better security properties. As far as scale goes, you're talking about a pretty simple database of pretty simple objects here. There is probably more overhead that goes into maintaining the distributed nature of the db than there is actual work generating prefix-lists. :) > > There is no reason that this process needs to be > > politicized, or cost anyone any money to use. > > Anytime you go down the road of advocating authority centralization, > you'll start getting people politicizing the process [cf icann, alternate > roots, all the random frothing-at-the-mouth-until-they-fall-over types]. > I rather think that can be avoided by properly embracing the distributed > databases that do indeed function. Some can be side-stepped with RIR- > based IRRs, and decently distributed down to LIRs, but we all know ARIN > is still playing catchup here so it doesn't help our sphere in the > near term. A reasonable amount of authority centralization in this case is at the RIR level, particularly if it adds security mechanisms that provide some level of authorization over who is registering what prefixes. There is no reason that I should need to run my own database, if the system was designed properly. > > Again, we've made a horrible system here. > > I think you've misspelled 'front end'. The system certainly seems to > function, and the entire intent was that SPs would build their own > customer-facing tools as well as internal tools. Seems we've fallen > down in that regard, but irrpt [even if in php :-P] and the revival of > IRRtoolset are indications that folks are still interested in building > the internal widgets. In general I think you'd agree that the 'back > end' of most all service providers did not keep pace with the growth > of commoditization of service. The databases are full of garbage data, a large portion of the networks who do use it have as-set objects which expand to be completely worthless (either blocking all their customers, or allowing the entire internet), and there is a significant percentage of the bgp speaking Internet who can't figure it out at all (including a lot of otherwise theoretically competent tier 1's). Even of the people who use it, a LOT of it only works because of wide-spread and often unauthorized proxy registration, which IMHO is even more evil than not having it at all. I'm by no means advocating the hosts.txt approach, clearly we NEED a scalable automated system for managing authorized prefixes, but by every measurable standard I can come up with the end result is a festering pile of crap. I really don't think you can completely dismiss the back end (both implementation and design) as part of those problems. -- Richard A Steenbergen http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) From chris at uplogon.com Fri Aug 14 10:31:52 2009 From: chris at uplogon.com (Chris Gotstein) Date: Fri, 14 Aug 2009 10:31:52 -0500 Subject: IPv6 Addressing Help In-Reply-To: References: <4A857CB3.10600@uplogon.com> <4A85800A.6020703@spaghetti.zurich.ibm.com> Message-ID: <4A858368.1030200@uplogon.com> I think we had to let ARIN know the time frame of deploying IPv6 and how many customers we expected to put on in the first couple years. They did not ask for an addressing scheme. Reading over the RFC's and other IPv6 resources, we have decided to hand out /56's to small/home/SOHO customers and /48's to larger customers. I'm just not able to wrap my brain around the subnetting that needs to be done on the router. Like i said before, i think i'm just over complicating it in my mind. Chris Gotstein Sr Network Engineer UP Logon/Computer Connection UP 500 N Stephenson Ave Iron Mountain, MI 49801 Phone: 906-774-4847 Fax: 906-774-0335 chris at uplogon.com Thomas Mangin wrote: > I do not know about arin but ripe changed it's policy so you only have > to say "pretty please" to receive your allocation. It better that way > anyway. > > Thomas Mangin > > On 14 Aug 2009, at 16:17, Jeroen Massar wrote: > >> Chris Gotstein wrote: >>> We are a small ISP that is in the process of setting up IPv6 on our >>> network. We already have the ARIN allocation and i have a couple >>> routers and servers running dual stack. Wondering if someone out there >>> would be willing to give me a few pointers on setting up my addressing >>> scheme? >> >> Strange, I recall that you had to submit one when requesting address >> space from ARIN. Why don't you use that one? >> >>> I've been mulling over how to do it, and i think i'm making it >>> more complicated than it needs to be. You can hit me offlist if you >>> wish to help. Thanks. >> >> It all depends on your network and how you want to set it up, but for >> the sake of internal aggregation: >> * Determine the expected amount of IPv6 customers at a certain >> location for the next X years, making X > 2 (though 10 is probably a >> better idea, just in case, if don't want to do it again ;) ) >> * Take that number round it up to a power of 2 >> * Every customer gets a /48, you know the number, which is a power of >> 2, thus root it, and you know how many bits you need at that site >> >> eg expect 200 customers, round to power of 2 thus 256, which is 2^8, >> thus you will need a /48 + 8 bits = /40 at that location. >> >> You now know how much address space you need at that location for the >> next X years. >> >> Repeat that for all your locations / routing areas, basically the PoPs >> or termination points of your customers; or if you are really big do >> that per city/town/suburb. Keep enough space (the rounding helps there >> quite a bit, especially with numbers like 50k customers ;) >> >> Now you have an overview of what you expect to be allocating at each and >> every site. To add a little growth/future proof and to make live easy, >> you could either opt at this stage to round everything off to 'nice' >> numbers, eg only use /40's or /36's per PoP. Thus making everything the >> same, or doing things like grouping smaller PoPs together. >> >> Then when you have done that, take those blocks, and try to squeeze them >> a bit together. You should now have arrived to the address plan that you >> originally submitted to ARIN. >> >> Fill those blocks into a nice database, roll a PHP/shell/perl/whatever >> script to spit out your router configuration and presto: you are done. >> >> Enjoy the weekend ;) >> >> Greets, >> Jeroen >> >> From rdobbins at arbor.net Fri Aug 14 10:43:27 2009 From: rdobbins at arbor.net (Roland Dobbins) Date: Fri, 14 Aug 2009 22:43:27 +0700 Subject: IPv6 Addressing Help In-Reply-To: <4A858368.1030200@uplogon.com> References: <4A857CB3.10600@uplogon.com> <4A85800A.6020703@spaghetti.zurich.ibm.com> <4A858368.1030200@uplogon.com> Message-ID: On Aug 14, 2009, at 10:31 PM, Chris Gotstein wrote: > I'm just not able to wrap my brain around the subnetting that needs > to be done on the router. One of the things which has struck me as being fairly insane about current recommended 'best practices' for IPv6 addressing is the practice of wasting huge blocks of addresses on p2p links; even given the gigantic address space, in a world in which every soda-can, every window-blind, and swarms of medical nanobots injected into one's bloodstream will potentially become spimes, this just seems grossly short-sighted. The other, more immediately worrisome aspect of this practice is that it seems that we're essentially turning routers into sinkholes by doing this, with all the negative consequences this implies. Comments/clue greatly appreciated on this and related aspects . . . ----------------------------------------------------------------------- Roland Dobbins // Unfortunately, inefficiency scales really well. -- Kevin Lawton From david.freedman at uk.clara.net Fri Aug 14 10:49:30 2009 From: david.freedman at uk.clara.net (David Freedman) Date: Fri, 14 Aug 2009 16:49:30 +0100 Subject: IPv6 Addressing Help In-Reply-To: <4A858368.1030200@uplogon.com> References: <4A857CB3.10600@uplogon.com> <4A85800A.6020703@spaghetti.zurich.ibm.com> <4A858368.1030200@uplogon.com> Message-ID: <4A85878A.2000208@uk.clara.net> Chris Gotstein wrote: > I think we had to let ARIN know the time frame of deploying IPv6 and how > many customers we expected to put on in the first couple years. They > did not ask for an addressing scheme. > > Reading over the RFC's and other IPv6 resources, we have decided to hand > out /56's to small/home/SOHO customers and /48's to larger customers. > > I'm just not able to wrap my brain around the subnetting that needs to > be done on the router. Like i said before, i think i'm just over > complicating it in my mind. Will keep it simple, this is what I (and I suspect many others) do /128 - Loopback (what else?) /126 - Router p2p /112 - Router LAN shared segments (p2mp) /64 - Single customer LAN segments (customers asking for basic IPv6) /56 - Customer wants multiple LANs, doesn't want to fill out justification form /48 - Customer wants multiple LANs, thinks /56 is too small (for some reason), needs for routing, wants rDNS delegation etc.etc.etc.. This question gets asked so many times now, whilst people argue about the implications of using networks smaller than /64 for anything such deployments continue to exist and are successful. Perhaps we should document people's addressing plans somewhere, I see ratemyaddressingplan.com hasn't been taken yet? :) Dave. From david.freedman at uk.clara.net Fri Aug 14 10:49:30 2009 From: david.freedman at uk.clara.net (David Freedman) Date: Fri, 14 Aug 2009 16:49:30 +0100 Subject: IPv6 Addressing Help In-Reply-To: <4A858368.1030200@uplogon.com> References: <4A857CB3.10600@uplogon.com> <4A85800A.6020703@spaghetti.zurich.ibm.com> <4A858368.1030200@uplogon.com> Message-ID: <4A85878A.2000208@uk.clara.net> Chris Gotstein wrote: > I think we had to let ARIN know the time frame of deploying IPv6 and how > many customers we expected to put on in the first couple years. They > did not ask for an addressing scheme. > > Reading over the RFC's and other IPv6 resources, we have decided to hand > out /56's to small/home/SOHO customers and /48's to larger customers. > > I'm just not able to wrap my brain around the subnetting that needs to > be done on the router. Like i said before, i think i'm just over > complicating it in my mind. Will keep it simple, this is what I (and I suspect many others) do /128 - Loopback (what else?) /126 - Router p2p /112 - Router LAN shared segments (p2mp) /64 - Single customer LAN segments (customers asking for basic IPv6) /56 - Customer wants multiple LANs, doesn't want to fill out justification form /48 - Customer wants multiple LANs, thinks /56 is too small (for some reason), needs for routing, wants rDNS delegation etc.etc.etc.. This question gets asked so many times now, whilst people argue about the implications of using networks smaller than /64 for anything such deployments continue to exist and are successful. Perhaps we should document people's addressing plans somewhere, I see ratemyaddressingplan.com hasn't been taken yet? :) Dave. From celestea at usc.edu Fri Aug 14 10:59:41 2009 From: celestea at usc.edu (Celeste Anderson) Date: Fri, 14 Aug 2009 08:59:41 -0700 Subject: IPv6 Addressing Help In-Reply-To: <4A857CB3.10600@uplogon.com> References: <4A857CB3.10600@uplogon.com> Message-ID: Sounds like an excellent topic for a tutorial/talk/panel at the next NANOG. --celeste. ----- Original Message ----- From: Chris Gotstein Date: Friday, August 14, 2009 8:04 am Subject: IPv6 Addressing Help To: Nanog > We are a small ISP that is in the process of setting up IPv6 on our > network. We already have the ARIN allocation and i have a couple > routers and servers running dual stack. Wondering if someone out > there > would be willing to give me a few pointers on setting up my > addressing > scheme? I've been mulling over how to do it, and i think i'm > making it > more complicated than it needs to be. You can hit me offlist if > you > wish to help. Thanks. > > -- > Chris Gotstein > Sr Network Engineer > UP Logon/Computer Connection UP > 500 N Stephenson Ave > Iron Mountain, MI 49801 > Phone: 906-774-4847 > Fax: 906-774-0335 > chris at uplogon.com > > From owen at delong.com Fri Aug 14 11:09:53 2009 From: owen at delong.com (Owen DeLong) Date: Fri, 14 Aug 2009 09:09:53 -0700 Subject: IPv6 Addressing Help In-Reply-To: <4A85878A.2000208@uk.clara.net> References: <4A857CB3.10600@uplogon.com> <4A85800A.6020703@spaghetti.zurich.ibm.com> <4A858368.1030200@uplogon.com> <4A85878A.2000208@uk.clara.net> Message-ID: <3E67ED8A-C325-4DD9-AA63-6930AB9C4562@delong.com> On Aug 14, 2009, at 8:49 AM, David Freedman wrote: > > Chris Gotstein wrote: >> I think we had to let ARIN know the time frame of deploying IPv6 >> and how >> many customers we expected to put on in the first couple years. They >> did not ask for an addressing scheme. >> >> Reading over the RFC's and other IPv6 resources, we have decided to >> hand >> out /56's to small/home/SOHO customers and /48's to larger customers. >> >> I'm just not able to wrap my brain around the subnetting that needs >> to >> be done on the router. Like i said before, i think i'm just over >> complicating it in my mind. > > Will keep it simple, this is what I (and I suspect many others) do > > /128 - Loopback (what else?) > /126 - Router p2p > /112 - Router LAN shared segments (p2mp) > /64 - Single customer LAN segments (customers asking for basic IPv6) > /56 - Customer wants multiple LANs, doesn't want to fill out > justification form > /48 - Customer wants multiple LANs, thinks /56 is too small (for some > reason), needs for routing, wants rDNS delegation etc.etc.etc.. > I'll point out that you can do rDNS delegation down to the /64 (or even the /124) level. As to documenting, I think that the ARIN IPv6 wiki (http:// getipv6.info) might be an excellent place to add such data. Owen From sulrich at botwerks.org Fri Aug 14 11:18:00 2009 From: sulrich at botwerks.org (steve ulrich) Date: Fri, 14 Aug 2009 11:18:00 -0500 Subject: IPv6 Addressing Help In-Reply-To: References: <4A857CB3.10600@uplogon.com> Message-ID: i believe this is recently trod NANOG ground. i've seen a number of folks exploring techniques very similar to this from an addressing plan perspective. it's simple, intuitive and if you don't like it, well, you are free to craft your own. in either event it's a practical discussion of some of the considerations. http://nanog.org/meetings/nanog46/abstracts.php?pt=MTM3MyZuYW5vZzQ2&nm=nanog46 On Fri, Aug 14, 2009 at 10:59 AM, Celeste Anderson wrote: > Sounds like an excellent topic for a tutorial/talk/panel at the next NANOG. > > --celeste. > > ----- Original Message ----- > From: Chris Gotstein > Date: Friday, August 14, 2009 8:04 am > Subject: IPv6 Addressing Help > To: Nanog > >> We are a small ISP that is in the process of setting up IPv6 on our >> network. ?We already have the ARIN allocation and i have a couple >> routers and servers running dual stack. ?Wondering if someone out >> there >> would be willing to give me a few pointers on setting up my >> addressing >> scheme? ?I've been mulling over how to do it, and i think i'm >> making it >> more complicated than it needs to be. ?You can hit me offlist if >> you >> wish to help. ?Thanks. -- steve ulrich (sulrich at botwerks.*) From randy at psg.com Fri Aug 14 11:39:22 2009 From: randy at psg.com (Randy Bush) Date: Sat, 15 Aug 2009 01:39:22 +0900 Subject: IPv6 Addressing Help In-Reply-To: <4A85878A.2000208@uk.clara.net> References: <4A857CB3.10600@uplogon.com> <4A85800A.6020703@spaghetti.zurich.ibm.com> <4A858368.1030200@uplogon.com> <4A85878A.2000208@uk.clara.net> Message-ID: > /126 - Router p2p /127, see MATSUZAKI Yoshinobu gave a talk describing the ping pong attack on /127 at a ripe or apricot or both. both web sites are absolutely horrid at letting one find talks (see nanog for an example of good). randy From randy at psg.com Fri Aug 14 11:39:26 2009 From: randy at psg.com (Randy Bush) Date: Sat, 15 Aug 2009 01:39:26 +0900 Subject: IPv6 Addressing Help In-Reply-To: <4A85878A.2000208@uk.clara.net> References: <4A857CB3.10600@uplogon.com> <4A85800A.6020703@spaghetti.zurich.ibm.com> <4A858368.1030200@uplogon.com> <4A85878A.2000208@uk.clara.net> Message-ID: > /126 - Router p2p /127, see MATSUZAKI Yoshinobu gave a talk describing the ping pong attack on /127 at a ripe or apricot or both. both web sites are absolutely horrid at letting one find talks (see nanog for an example of good). randy From jlewis at lewis.org Fri Aug 14 11:40:34 2009 From: jlewis at lewis.org (Jon Lewis) Date: Fri, 14 Aug 2009 12:40:34 -0400 (EDT) Subject: IPv6 Addressing Help In-Reply-To: <4A85878A.2000208@uk.clara.net> References: <4A857CB3.10600@uplogon.com> <4A85800A.6020703@spaghetti.zurich.ibm.com> <4A858368.1030200@uplogon.com> <4A85878A.2000208@uk.clara.net> Message-ID: On Fri, 14 Aug 2009, David Freedman wrote: > Will keep it simple, this is what I (and I suspect many others) do > > /128 - Loopback (what else?) > /126 - Router p2p > /112 - Router LAN shared segments (p2mp) Why even go that big on LAN segments? i.e. If you have a LAN/VLAN where you have say 20 devices (routers, switches, etc.) and know you'll never have more than say 50-100 devices, why not go as far as using a /120? ---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From ljb at merit.edu Fri Aug 14 11:42:19 2009 From: ljb at merit.edu (Larry Blunk) Date: Fri, 14 Aug 2009 12:42:19 -0400 Subject: IPv6 Addressing Help In-Reply-To: References: <4A857CB3.10600@uplogon.com> <4A85800A.6020703@spaghetti.zurich.ibm.com> <4A858368.1030200@uplogon.com> <4A85878A.2000208@uk.clara.net> Message-ID: <4A8593EB.7020205@merit.edu> Randy Bush wrote: >> /126 - Router p2p >> > > /127, see > > MATSUZAKI Yoshinobu gave a talk describing the ping pong attack on /127 > at a ripe or apricot or both. both web sites are absolutely horrid at > letting one find talks (see nanog for an example of good). > > randy > > Here's a link to the talk -- http://archive.apnic.net/meetings/26/program/apops/matsuzaki-ipv6-p2p.pdf -Larry From david.freedman at uk.clara.net Fri Aug 14 11:45:29 2009 From: david.freedman at uk.clara.net (David Freedman) Date: Fri, 14 Aug 2009 17:45:29 +0100 Subject: IPv6 Addressing Help In-Reply-To: References: <4A857CB3.10600@uplogon.com> <4A85800A.6020703@spaghetti.zurich.ibm.com> <4A858368.1030200@uplogon.com> <4A85878A.2000208@uk.clara.net> Message-ID: <4A8594A9.3020402@uk.clara.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jon Lewis wrote: > On Fri, 14 Aug 2009, David Freedman wrote: > >> Will keep it simple, this is what I (and I suspect many others) do >> >> /128 - Loopback (what else?) >> /126 - Router p2p >> /112 - Router LAN shared segments (p2mp) > > Why even go that big on LAN segments? i.e. If you have a LAN/VLAN where > you have say 20 devices (routers, switches, etc.) and know you'll never > have more than say 50-100 devices, why not go as far as using a /120? Actually, this is where I start to move from "conserve addressing the good old way (tm)" to "Make it look readable" $ sipcalc 2001:dbb::/64 --v6split=112 | grep \: | head -n9 - -[ipv6 : 2001:dbb::/64] - 0 Network - 2001:0dbb:0000:0000:0000:0000:0000:0000 - 2001:0dbb:0000:0000:0000:0000:0000:ffff Network - 2001:0dbb:0000:0000:0000:0000:0001:0000 - 2001:0dbb:0000:0000:0000:0000:0001:ffff Network - 2001:0dbb:0000:0000:0000:0000:0002:0000 - 2001:0dbb:0000:0000:0000:0000:0002:ffff Network - 2001:0dbb:0000:0000:0000:0000:0003:0000 - 2001:0dbb:0000:0000:0000:0000:0003:ffff -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkqFlKgACgkQtFWeqpgEZrJsGwCdEUcD99wpMhKvWVmxv3rogMk+ 9V8An3uXswYKdE6B5Ab3AdYPTrK6otfy =xVBB -----END PGP SIGNATURE----- From trejrco at gmail.com Fri Aug 14 12:06:06 2009 From: trejrco at gmail.com (TJ) Date: Fri, 14 Aug 2009 13:06:06 -0400 Subject: IPv6 Addressing Help In-Reply-To: References: <4A857CB3.10600@uplogon.com> <4A85800A.6020703@spaghetti.zurich.ibm.com> <4A858368.1030200@uplogon.com> Message-ID: <00c801ca1d01$838e8a10$8aab9e30$@com> >-----Original Message----- >From: Roland Dobbins [mailto:rdobbins at arbor.net] >On Aug 14, 2009, at 10:31 PM, Chris Gotstein wrote: >> I'm just not able to wrap my brain around the subnetting that needs to >> be done on the router. >One of the things which has struck me as being fairly insane about current >recommended 'best practices' for IPv6 addressing is the practice of wasting >huge blocks of addresses on p2p links; even given the gigantic address space, >in a world in which every soda-can, every window-blind, and swarms of medical >nanobots injected into one's bloodstream will potentially become spimes, this >just seems grossly short-sighted. It is all a matter of perspective. If you want to use /126s (or whatever longer-than-64bit-prefix-you-like) that is ~OK - it certainly works! - but you may be complicating your life in the future. It is "your network" - build it however you wish, just be sure of the benefits and drawbacks associated with those choices. (Purely an off-the-top-of-my-head hypothetical: What if PtP links become drastically less common, and you need to re-address your network from ~/126s to /64s because of that? You are causing yourself pain, and for what gain? To conserve a resource that is not (and according to some, will effectively never be) in short supply?) A great counter-point to this is that if you do use /64s (or for that matter - anything shorter than the currently-not-recommended /127s, AFAIK), you should apply ACLs to them to prevent ping-pong. ((FWIW - counting the number of individual address being used is a non-starter ... ~18,000,000,000,000,000,000 addresses on each segment is more than enough for any solution I expect in the relevant future. I am not saying the goal of conservation is bad (e.g. - I like /56s to homes instead of /48s), just trying to keep things in perspective.)) Pick your flavor of answer, and drink heavily. I prefer coffee ... or Vodka. /TJ From cscora at apnic.net Fri Aug 14 13:12:39 2009 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 15 Aug 2009 04:12:39 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <200908141812.n7EICdj8012647@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 15 Aug, 2009 Report Website: http://thyme.apnic.net Detailed Analysis: http://thyme.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 293045 Prefixes after maximum aggregation: 138797 Deaggregation factor: 2.11 Unique aggregates announced to Internet: 145789 Total ASes present in the Internet Routing Table: 31941 Prefixes per ASN: 9.17 Origin-only ASes present in the Internet Routing Table: 27758 Origin ASes announcing only one prefix: 13556 Transit ASes present in the Internet Routing Table: 4183 Transit-only ASes present in the Internet Routing Table: 99 Average AS path length visible in the Internet Routing Table: 3.6 Max AS path length visible: 24 Max AS path prepend of ASN (12026) 22 Prefixes from unregistered ASNs in the Routing Table: 464 Unregistered ASNs in the Routing Table: 128 Number of 32-bit ASNs allocated by the RIRs: 236 Prefixes from 32-bit ASNs in the Routing Table: 87 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 305 Number of addresses announced to Internet: 2088201152 Equivalent to 124 /8s, 119 /16s and 107 /24s Percentage of available address space announced: 56.3 Percentage of allocated address space announced: 64.5 Percentage of available address space allocated: 87.3 Percentage of address space in use by end-sites: 78.6 Total number of prefixes smaller than registry allocations: 140112 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 70029 Total APNIC prefixes after maximum aggregation: 24871 APNIC Deaggregation factor: 2.82 Prefixes being announced from the APNIC address blocks: 69452 Unique aggregates announced from the APNIC address blocks: 31678 APNIC Region origin ASes present in the Internet Routing Table: 3730 APNIC Prefixes per ASN: 18.62 APNIC Region origin ASes announcing only one prefix: 1022 APNIC Region transit ASes present in the Internet Routing Table: 579 Average APNIC Region AS path length visible: 3.6 Max APNIC Region AS path length visible: 16 Number of APNIC addresses announced to Internet: 480080320 Equivalent to 28 /8s, 157 /16s and 113 /24s Percentage of available APNIC address space announced: 84.2 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, 175/8, 180/8, 182/8, 183/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 124187 Total ARIN prefixes after maximum aggregation: 66255 ARIN Deaggregation factor: 1.87 Prefixes being announced from the ARIN address blocks: 124834 Unique aggregates announced from the ARIN address blocks: 52347 ARIN Region origin ASes present in the Internet Routing Table: 13166 ARIN Prefixes per ASN: 9.48 ARIN Region origin ASes announcing only one prefix: 5084 ARIN Region transit ASes present in the Internet Routing Table: 1297 Average ARIN Region AS path length visible: 3.3 Max ARIN Region AS path length visible: 24 Number of ARIN addresses announced to Internet: 1012753984 Equivalent to 60 /8s, 93 /16s and 102 /24s Percentage of available ARIN address space announced: 88.8 ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 53248-55295 ARIN Address Blocks 3/8, 4/8, 6/8, 7/8, 8/8, 9/8, 11/8, 12/8, 13/8, 15/8, 16/8, 17/8, 18/8, 19/8, 20/8, 21/8, 22/8, 24/8, 26/8, 28/8, 29/8, 30/8, 32/8, 33/8, 34/8, 35/8, 38/8, 40/8, 44/8, 45/8, 47/8, 48/8, 52/8, 54/8, 55/8, 56/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8, 98/8, 99/8, 108/8, 173/8, 174/8, 184/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 214/8, 215/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 67351 Total RIPE prefixes after maximum aggregation: 39758 RIPE Deaggregation factor: 1.69 Prefixes being announced from the RIPE address blocks: 66989 Unique aggregates announced from the RIPE address blocks: 45267 RIPE Region origin ASes present in the Internet Routing Table: 13386 RIPE Prefixes per ASN: 5.00 RIPE Region origin ASes announcing only one prefix: 6995 RIPE Region transit ASes present in the Internet Routing Table: 1999 Average RIPE Region AS path length visible: 4.0 Max RIPE Region AS path length visible: 21 Number of RIPE addresses announced to Internet: 499938496 Equivalent to 29 /8s, 204 /16s and 116 /24s Percentage of available RIPE address space announced: 99.3 RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-52223 RIPE Address Blocks 25/8, 51/8, 62/8, 77/8, 78/8, 79/8, 80/8, 81/8, 82/8, 83/8, 84/8, 85/8, 86/8, 87/8, 88/8, 89/8, 90/8, 91/8, 92/8, 93/8, 94/8, 95/8, 109/8, 178/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 24891 Total LACNIC prefixes after maximum aggregation: 6126 LACNIC Deaggregation factor: 4.06 Prefixes being announced from the LACNIC address blocks: 24847 Unique aggregates announced from the LACNIC address blocks: 13861 LACNIC Region origin ASes present in the Internet Routing Table: 1150 LACNIC Prefixes per ASN: 21.61 LACNIC Region origin ASes announcing only one prefix: 368 LACNIC Region transit ASes present in the Internet Routing Table: 193 Average LACNIC Region AS path length visible: 4.1 Max LACNIC Region AS path length visible: 22 Number of LACNIC addresses announced to Internet: 73116096 Equivalent to 4 /8s, 91 /16s and 169 /24s Percentage of available LACNIC address space announced: 72.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: 6184 Total AfriNIC prefixes after maximum aggregation: 1496 AfriNIC Deaggregation factor: 4.13 Prefixes being announced from the AfriNIC address blocks: 6605 Unique aggregates announced from the AfriNIC address blocks: 2388 AfriNIC Region origin ASes present in the Internet Routing Table: 307 AfriNIC Prefixes per ASN: 21.51 AfriNIC Region origin ASes announcing only one prefix: 87 AfriNIC Region transit ASes present in the Internet Routing Table: 65 Average AfriNIC Region AS path length visible: 3.8 Max AfriNIC Region AS path length visible: 17 Number of AfriNIC addresses announced to Internet: 20439552 Equivalent to 1 /8s, 55 /16s and 226 /24s Percentage of available AfriNIC address space announced: 60.9 AfriNIC AS Blocks 36864-37887 & ERX transfers AfriNIC Address Blocks 41/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4766 1723 6980 424 Korea Telecom (KIX) 17488 1549 139 102 Hathway IP Over Cable Interne 4755 1229 292 141 TATA Communications formerly 9583 1099 87 543 Sify Limited 4134 995 18007 387 CHINANET-BACKBONE 18101 964 202 32 Reliance Infocom Ltd Internet 7545 816 198 103 TPG Internet Pty Ltd 9829 807 620 16 BSNL National Internet Backbo 23577 785 34 665 Korea Telecom (ATM-MPLS) 4808 761 1517 175 CNCGROUP IP network: China169 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 4205 3642 322 bellsouth.net, inc. 4323 1918 1048 386 Time Warner Telecom 1785 1727 714 138 PaeTec Communications, Inc. 7018 1489 5906 1049 AT&T WorldNet Services 20115 1466 1472 672 Charter Communications 6478 1363 279 256 AT&T Worldnet Services 2386 1287 673 937 AT&T Data Communications Serv 3356 1204 10979 435 Level 3 Communications, LLC 11492 1132 208 12 Cable One 22773 1086 2604 66 Cox Communications, Inc. Complete listing at http://thyme.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 30890 483 92 196 Evolva Telecom 12479 472 578 6 Uni2 Autonomous System 3292 463 1905 397 TDC Tele Danmark 702 430 1861 346 UUNET - Commercial IP service 35805 379 40 5 United Telecom of Georgia 9198 370 138 12 Kazakhtelecom Data Network Ad 3301 348 1684 311 TeliaNet Sweden 3320 345 7067 299 Deutsche Telekom AG 3215 344 3081 109 France Telecom Transpac 8866 339 109 20 Bulgarian Telecommunication C 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 1518 2898 244 UniNet S.A. de C.V. 10620 990 220 93 TVCABLE BOGOTA 7303 624 331 95 Telecom Argentina Stet-France 28573 614 579 34 NET Servicos de Comunicao S.A 22047 541 302 14 VTR PUNTO NET S.A. 11830 487 310 65 Instituto Costarricense de El 11172 442 99 70 Servicios Alestra S.A de C.V 6471 421 96 31 ENTEL CHILE S.A. 7738 414 858 29 Telecomunicacoes da Bahia S.A 3816 398 191 78 Empresa Nacional de Telecomun Complete listing at http://thyme.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 8452 1027 188 7 TEDATA 24863 922 144 29 LINKdotNET AS number 20858 325 34 6 EgyNet 3741 276 856 236 The Internet Solution 2018 200 180 142 Tertiary Education Network 6713 175 166 16 Itissalat Al-MAGHRIB 33783 152 10 8 EEPAD TISP TELECOM & INTERNET 29571 144 15 7 Ci Telecom Autonomous system 24835 130 46 9 RAYA Telecom - Egypt 5536 122 8 13 Internet Egypt Network Complete listing at http://thyme.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 4205 3642 322 bellsouth.net, inc. 4323 1918 1048 386 Time Warner Telecom 1785 1727 714 138 PaeTec Communications, Inc. 4766 1723 6980 424 Korea Telecom (KIX) 17488 1549 139 102 Hathway IP Over Cable Interne 8151 1518 2898 244 UniNet S.A. de C.V. 7018 1489 5906 1049 AT&T WorldNet Services 20115 1466 1472 672 Charter Communications 6478 1363 279 256 AT&T Worldnet Services 2386 1287 673 937 AT&T Data Communications Serv Complete listing at http://thyme.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 1785 1727 1589 PaeTec Communications, Inc. 4323 1918 1532 Time Warner Telecom 17488 1549 1447 Hathway IP Over Cable Interne 4766 1723 1299 Korea Telecom (KIX) 8151 1518 1274 UniNet S.A. de C.V. 11492 1132 1120 Cable One 6478 1363 1107 AT&T Worldnet Services 4755 1229 1088 TATA Communications formerly 18566 1062 1052 Covad Communications 22773 1086 1020 Cox Communications, Inc. Complete listing at http://thyme.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 16927 UNALLOCATED 12.0.252.0/23 7018 AT&T WorldNet Servic 15132 UNALLOCATED 12.9.150.0/24 7018 AT&T WorldNet Servic 32567 UNALLOCATED 12.14.170.0/24 7018 AT&T WorldNet Servic 13746 UNALLOCATED 12.24.56.0/24 7018 AT&T WorldNet Servic 32567 UNALLOCATED 12.25.107.0/24 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.152.0/24 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.154.0/23 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.159.0/24 7018 AT&T WorldNet Servic 32326 UNALLOCATED 12.40.49.0/24 7018 AT&T WorldNet Servic 25639 UNALLOCATED 12.41.169.0/24 7018 AT&T WorldNet Servic Complete listing at http://thyme.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 24.225.128.0/17 36377 PATRIOT MEDIA AND COMMUNICATI 41.223.92.0/22 36936 >>UNKNOWN<< 41.223.112.0/22 5713 Telkom SA Ltd 41.223.176.0/22 36981 >>UNKNOWN<< 41.223.188.0/24 22351 Intelsat 41.223.189.0/24 26452 Local Communications Networks 62.61.220.0/24 24974 Tachyon Europe BV - Wireless 62.61.221.0/24 24974 Tachyon Europe BV - Wireless 63.140.213.0/24 22555 Universal Talkware Corporatio 63.143.251.0/24 22555 Universal Talkware Corporatio Complete listing at http://thyme.apnic.net/current/data-add-IANA Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:19 /9:10 /10:24 /11:59 /12:170 /13:350 /14:624 /15:1174 /16:10618 /17:4792 /18:8358 /19:17269 /20:20635 /21:20542 /22:26526 /23:26231 /24:152910 /25:921 /26:1032 /27:597 /28:160 /29:8 /30:7 /31:1 /32:8 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 6389 2728 4205 bellsouth.net, inc. 4766 1410 1723 Korea Telecom (KIX) 17488 1295 1549 Hathway IP Over Cable Interne 1785 1197 1727 PaeTec Communications, Inc. 11492 1058 1132 Cable One 18566 1043 1062 Covad Communications 4323 970 1918 Time Warner Telecom 9583 952 1099 Sify Limited 8452 948 1027 TEDATA 10620 896 990 TVCABLE BOGOTA Complete listing at http://thyme.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 4:14 8:213 12:2136 13:7 15:20 16:3 17:5 20:35 24:1124 32:51 34:2 38:589 40:97 41:1768 43:1 44:2 47:13 52:6 55:2 56:2 57:24 58:620 59:608 60:462 61:974 62:1105 63:2011 64:3544 65:2405 66:3413 67:1704 68:865 69:2748 70:557 71:152 72:1656 73:2 74:1683 75:178 76:338 77:843 78:566 79:375 80:936 81:853 82:589 83:451 84:638 85:1070 86:376 87:676 88:370 89:1478 90:48 91:2467 92:389 93:1100 94:1183 95:1133 96:166 97:260 98:268 99:28 110:177 111:371 112:127 113:150 114:230 115:290 116:1133 117:558 118:337 119:768 120:151 121:648 122:1243 123:751 124:1032 125:1343 128:225 129:221 130:128 131:414 132:75 133:9 134:185 135:43 136:225 137:160 138:167 139:80 140:443 141:124 142:384 143:371 144:375 145:49 146:389 147:153 148:527 149:224 150:207 151:192 152:209 153:148 154:2 155:274 156:167 157:301 158:115 159:343 160:290 161:164 162:273 163:163 164:275 165:521 166:465 167:363 168:699 169:178 170:476 171:41 172:10 173:363 174:280 178:1 180:5 186:120 187:159 188:409 189:584 190:2913 192:5781 193:4257 194:3290 195:2699 196:1105 198:3646 199:3370 200:5103 201:1316 202:7728 203:8288 204:3887 205:2164 206:2446 207:2738 208:3910 209:3421 210:2521 211:1100 212:1627 213:1619 214:92 215:29 216:4319 217:1363 218:407 219:411 220:1092 221:462 222:327 End of report From herrin-nanog at dirtside.com Fri Aug 14 13:33:10 2009 From: herrin-nanog at dirtside.com (William Herrin) Date: Fri, 14 Aug 2009 14:33:10 -0400 Subject: IPv6 Addressing Help In-Reply-To: <4A857CB3.10600@uplogon.com> References: <4A857CB3.10600@uplogon.com> Message-ID: <3c3e3fca0908141133j73b26fd8o1066c93c846205e8@mail.gmail.com> On Fri, Aug 14, 2009 at 11:03 AM, Chris Gotstein wrote: > We are a small ISP that is in the process of setting up IPv6 on our network. > ?We already have the ARIN allocation and i have a couple routers and servers > running dual stack. ?Wondering if someone out there would be willing to give > me a few pointers on setting up my addressing scheme? ?I've been mulling > over how to do it, and i think i'm making it more complicated than it needs > to be. ?You can hit me offlist if you wish to help. ?Thanks. Hi Chris, Suggested scheme: Router loopback: /128 Router serial link: /126 Router/server ethernet link: /64 Dynamic IP customer: /128 from a /64 pool Dynamic IP always-on customer: Not sure there are any well conceived and solidly implemented answers here. Your customer's "DSL router" isn't going to work and you shouldn't expect a production-grade IPv6 NAT CPE any time soon. You can go DHCP or autoconfiguration and let him chew as many /128's as he wants but then you'll run into the broadcast traffic problem same as when you used DHCP for IPv4. On the flip side, you can convert your always-on folks to static IP customers with the risk of a routing explosion as these customers move around and as you merge and split service POPs. I'm not aware of any way of dynamically assigning an IPv6 subnet to a customer that's as well automated as IPv4 /32 dynamic assignment to a DSL router with an RFC1918 NATed interior, but that may just be my ignorance since I haven't needed to research it. Static IP customer: /60 Any static-IP customer who bothers to ask: /48 In all other respects follow whatever strategy works for you for IPv4 wrt routing areas and aggregation. Several notes: The RDNS delegation boundary for IPv6 is 4 bits (as opposed to IPv4's 8 bits). This makes boundaries like /48, /52, /56, /60 and /64 very convenient. You should probably avoid customer assignments that don't fall on one of those boundaries. Ethernet in IPv6 is intended to work on a /64 subnet. You can make it work on any other size but why create extra hassle for yourself for no good reason? I recommend /60 as the customer default where most folks suggest /56 or /48. The IPv6 use profile looks a heck of a lot like the IPv4 use profile and /60 is 16 subnets. How many of your customers find a reason to use more than 3 IPv4 subnets, including their RFC1918 ones? Relatively few. Giving every customer enough subnets by default to meet 90% of the typical usage profiles is not the worst idea in the world... IMHO it's a pretty bright idea. But there's no need to be damnfool wasteful about it. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From jeroen at unfix.org Fri Aug 14 13:35:38 2009 From: jeroen at unfix.org (Jeroen Massar) Date: Fri, 14 Aug 2009 20:35:38 +0200 Subject: IPv6 Addressing Help In-Reply-To: <00c801ca1d01$838e8a10$8aab9e30$@com> References: <4A857CB3.10600@uplogon.com> <4A85800A.6020703@spaghetti.zurich.ibm.com> <4A858368.1030200@uplogon.com> <00c801ca1d01$838e8a10$8aab9e30$@com> Message-ID: <4A85AE7A.7020605@spaghetti.zurich.ibm.com> TJ wrote: [..] > A great counter-point to this is that if you do use /64s (or for that matter > - anything shorter than the currently-not-recommended /127s, AFAIK), you > should apply ACLs to them to prevent ping-pong. One should be doing uRPF at minimum on all links anyway. BCP84 ;) If the user (or whatever you call the place where you send packets to) has a default route back and is not properly routing those packets can come back quite quickly. eg, route a /48 to the user. The user only uses the first /64, and doesn't care about the rest and doesn't route them to lo0 to avoid the default to match, the packets will nicely ping pong back to you. Easy solution: source address check, then the source will not be matching and you can drop the packet, or ICMP !A them so that the user might once figure out what goes on. Of course if user is sending packets with their source and their destination you will need another kind of filter, but they will only hurt themselves with it. 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 jeroen at unfix.org Fri Aug 14 13:40:06 2009 From: jeroen at unfix.org (Jeroen Massar) Date: Fri, 14 Aug 2009 20:40:06 +0200 Subject: IPv6 Addressing Help In-Reply-To: <3c3e3fca0908141133j73b26fd8o1066c93c846205e8@mail.gmail.com> References: <4A857CB3.10600@uplogon.com> <3c3e3fca0908141133j73b26fd8o1066c93c846205e8@mail.gmail.com> Message-ID: <4A85AF86.5000603@spaghetti.zurich.ibm.com> William Herrin wrote: [..] > I'm not aware of any way of dynamically assigning an IPv6 subnet to a > customer that's as well automated as IPv4 /32 dynamic assignment to a > DSL router with an RFC1918 NATed interior, but that may just be my > ignorance since I haven't needed to research it. DHCP-PD (prefix delegation) > Static IP customer: /60 ARIN defines a /56 minimum. That is the reason that ISPs get a /32. RIPE defines a /48 at the moment. [..] > I recommend /60 as the customer default where most folks suggest /56 > or /48. The IPv6 use profile looks a heck of a lot like the IPv4 use > profile and /60 is 16 subnets. How many of your customers find a > reason to use more than 3 IPv4 subnets, including their RFC1918 ones? > Relatively few. Think Future. And why bother with that anyway. If you as an ISP needs more address space just ring RIPE/ARIN/APNIC and ask for more, they will happily give it to you. > Giving every customer enough subnets by default to meet 90% of the > typical usage profiles is not the worst idea in the world... IMHO it's > a pretty bright idea. But there's no need to be damnfool wasteful > about it. I guess you ran the numbers on how to run out of IPv6 address space? You can always ask the US DoD for a few /32s, they have enough of them... Routing will become a problem before IPv6 address space will run out. Oh, and we are only allocating from 2000::/3 at the moment, can retry on the other 7 /8s.... 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 Rod.Beck at hiberniaatlantic.com Fri Aug 14 13:55:36 2009 From: Rod.Beck at hiberniaatlantic.com (Rod Beck) Date: Fri, 14 Aug 2009 19:55:36 +0100 Subject: TransAtlantic 40 Gig Waves References: <1E8B940C5E21014AB8BE70B975D40EDB0162857C@bert.HiberniaAtlantic.local> <4A849D32.3040604@internode.com.au> Message-ID: <1E8B940C5E21014AB8BE70B975D40EDB016285B5@bert.HiberniaAtlantic.local> -----Original Message----- From: Matthew Moyle-Croft [mailto:mmc at internode.com.au] Sent: Fri 8/14/2009 12:09 AM To: Rod Beck Cc: nanog at nanog.org Subject: Re: TransAtlantic 40 Gig Waves Congrats Rod. Southern Cross and Nortel have been trialing 40Gbps waves on the 8000km segment from Hawaii to New Zealand. http://www.itnews.com.au/News/152866,southern-cross-trials-40gbps-nortel-kit.aspx The 8000km segment is a LONG way - a very long way but it should mean stability for any cable system (I'm not sure there are segments that are much longer on any other system) - the bandwidth limit hasn't been hit yet! MMC Rod Beck wrote: > http://www.hiberniaatlantic.com/documents/Hibernia40GAcrossAtlanticPR-JSA2-FINAL.pdf > > Roderick S. Beck > Director of European Sales > Hibernia Atlantic > Budapest, New York, and Paris > > Well, the funny thing is that when I approached bandwidth buyers at some well known publicly traded carriers, they told me that 40 gig waves across the Atlantic were impossible. Quite common response. Indeed, when we decided to launch LAN PHY 10 GigE, the builder of our cable system told us it wasn't possible. From Valdis.Kletnieks at vt.edu Fri Aug 14 14:12:53 2009 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Fri, 14 Aug 2009 15:12:53 -0400 Subject: TransAtlantic 40 Gig Waves In-Reply-To: Your message of "Fri, 14 Aug 2009 19:55:36 BST." <1E8B940C5E21014AB8BE70B975D40EDB016285B5@bert.HiberniaAtlantic.local> References: <1E8B940C5E21014AB8BE70B975D40EDB0162857C@bert.HiberniaAtlantic.local> <4A849D32.3040604@internode.com.au> <1E8B940C5E21014AB8BE70B975D40EDB016285B5@bert.HiberniaAtlantic.local> Message-ID: <28620.1250277173@turing-police.cc.vt.edu> On Fri, 14 Aug 2009 19:55:36 BST, Rod Beck said: > Well, the funny thing is that when I approached bandwidth buyers at some > well known publicly traded carriers, they told me that 40 gig waves > across the Atlantic were impossible. Theoretically impossible, or just "impossible on the fiber that's already underwater"? Big difference there. > Indeed, when we decided to launch LAN PHY 10 GigE, the builder of our cable > system told us it wasn't possible. Again, was this "impossible on a cable the builder was about to build", or "impossible on the cable that the builder put under the water already"? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 226 bytes Desc: not available URL: From Rod.Beck at hiberniaatlantic.com Fri Aug 14 14:13:25 2009 From: Rod.Beck at hiberniaatlantic.com (Rod Beck) Date: Fri, 14 Aug 2009 20:13:25 +0100 Subject: TransAtlantic 40 Gig Waves References: <1E8B940C5E21014AB8BE70B975D40EDB0162857C@bert.HiberniaAtlantic.local> <4A849D32.3040604@internode.com.au> <1E8B940C5E21014AB8BE70B975D40EDB016285B5@bert.HiberniaAtlantic.local> <28620.1250277173@turing-police.cc.vt.edu> Message-ID: <1E8B940C5E21014AB8BE70B975D40EDB016285B8@bert.HiberniaAtlantic.local> -----Original Message----- From: Valdis.Kletnieks at vt.edu [mailto:Valdis.Kletnieks at vt.edu] Sent: Fri 8/14/2009 8:12 PM To: Rod Beck Cc: Matthew Moyle-Croft; nanog at nanog.org Subject: Re: TransAtlantic 40 Gig Waves On Fri, 14 Aug 2009 19:55:36 BST, Rod Beck said: > Well, the funny thing is that when I approached bandwidth buyers at some > well known publicly traded carriers, they told me that 40 gig waves > across the Atlantic were impossible. Theoretically impossible, or just "impossible on the fiber that's already underwater"? Big difference there. Impossilbe on the existing undersea cables. > Indeed, when we decided to launch LAN PHY 10 GigE, the builder of our cable > system told us it wasn't possible. Again, was this "impossible on a cable the builder was about to build", or "impossible on the cable that the builder put under the water already"? Impossible on our cable. The one they built. From herrin-nanog at dirtside.com Fri Aug 14 15:52:42 2009 From: herrin-nanog at dirtside.com (William Herrin) Date: Fri, 14 Aug 2009 16:52:42 -0400 Subject: IPv6 Addressing Help In-Reply-To: <4A85AF86.5000603@spaghetti.zurich.ibm.com> References: <4A857CB3.10600@uplogon.com> <3c3e3fca0908141133j73b26fd8o1066c93c846205e8@mail.gmail.com> <4A85AF86.5000603@spaghetti.zurich.ibm.com> Message-ID: <3c3e3fca0908141352me6d8b65ue7288b0b44172548@mail.gmail.com> On Fri, Aug 14, 2009 at 2:40 PM, Jeroen Massar wrote: > William Herrin wrote: > [..] >> I'm not aware of any way of dynamically assigning an IPv6 subnet to a >> customer that's as well automated as IPv4 /32 dynamic assignment to a >> DSL router with an RFC1918 NATed interior, but that may just be my >> ignorance since I haven't needed to research it. > > DHCP-PD (prefix delegation) Hi Jeroen, Cool. So we'll have $100 CPE which uses it in a relatively idiot-proof manner sometime between now and eternity. >> Static IP customer: /60 > > ARIN defines a /56 minimum. That is the reason that ISPs get a /32. > RIPE defines a /48 at the moment. ARIN "defines" a /64 minimum customer assignment and suggests /56. They go on to say that, "RIRs/NIRs are not concerned about which address size an LIR/ISP actually assigns." See ARIN NRPM 6.5.4.1. https://www.arin.net/policy/nrpm.html#six54 >> I recommend /60 as the customer default where most folks suggest /56 >> or /48. The IPv6 use profile looks a heck of a lot like the IPv4 use >> profile and /60 is 16 subnets. How many of your customers find a >> reason to use more than 3 IPv4 subnets, including their RFC1918 ones? >> Relatively few. > > Think Future. And why bother with that anyway. If you as an ISP needs > more address space just ring RIPE/ARIN/APNIC and ask for more, they will > happily give it to you. The future looks a lot like the past but with more blinking lights. Seriously, I'm pretty nuts when it comes to networking. My basement is AS11875, multihomed with about 35mbps of bandwidth. If I can't imagine how *I* would use more than 16 subnets then it's a safe bet that many years will pass before Joe random DSL customer wants to. The world won't end, even if you assign every customer a /48. But why be so grossly wasteful *before* anyone has demonstrated a practical use for doing so? > I guess you ran the numbers on how to run out of IPv6 address space? IIRC, RIPE allocated a /19 to France Telecom. Doesn't take more than a few hundred thousand allocations like that one to wipe out the IPv6 address space. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From deepak at ai.net Fri Aug 14 16:11:09 2009 From: deepak at ai.net (Deepak Jain) Date: Fri, 14 Aug 2009 17:11:09 -0400 Subject: TransAtlantic 40 Gig Waves In-Reply-To: <28620.1250277173@turing-police.cc.vt.edu> References: <1E8B940C5E21014AB8BE70B975D40EDB0162857C@bert.HiberniaAtlantic.local> <4A849D32.3040604@internode.com.au> <1E8B940C5E21014AB8BE70B975D40EDB016285B5@bert.HiberniaAtlantic.local> <28620.1250277173@turing-police.cc.vt.edu> Message-ID: > > > Well, the funny thing is that when I approached bandwidth buyers at > > some well known publicly traded carriers, they told me that 40 gig > > waves across the Atlantic were impossible. > > Theoretically impossible, or just "impossible on the fiber that's > already underwater"? Big difference there. > > > Indeed, when we decided to launch LAN PHY 10 GigE, the builder of our > > cable system told us it wasn't possible. > > Again, was this "impossible on a cable the builder was about to build", > or "impossible on the cable that the builder put under the water > already"? 1) 40G across large bodies of water is a nice achievement, kudos to everyone involved everywhere. 2) Even on cables that are already deployed where impossible things couldn't happen, have. It just takes a little longer for the technology involved. Case in point, I point to DSL over legacy (old) copper plants. Even super old fiber in the ground can do things that were originally considered impossible. For existing undersea systems (whomever owns them) inline amplifiers as well as cable issues need to be ironed out. Now that folks know the cost of rolling out a new cable vs the cost of engineering specialized solutions for those sorts of spans, they have decisions to make... but I have (and it has been proven) faith in technology to the impossible works... it just takes some time. :) 25Ghz spacing wasn't possible 5 years ago either. And there is hfDWDM spacing in labs somewhere too. So other than for the folks that are provisioning 40G or who are considering deploying their own systems... what's the big deal? Deepak From trejrco at gmail.com Fri Aug 14 16:26:35 2009 From: trejrco at gmail.com (trejrco at gmail.com) Date: Fri, 14 Aug 2009 21:26:35 +0000 Subject: IPv6 Addressing Help In-Reply-To: <3c3e3fca0908141352me6d8b65ue7288b0b44172548@mail.gmail.com> References: <4A857CB3.10600@uplogon.com><3c3e3fca0908141133j73b26fd8o1066c93c846205e8@mail.gmail.com><4A85AF86.5000603@spaghetti.zurich.ibm.com><3c3e3fca0908141352me6d8b65ue7288b0b44172548@mail.gmail.com> Message-ID: <869154084-1250285130-cardhu_decombobulator_blackberry.rim.net-1846477473-@bxe1082.bisx.prod.on.blackberry> "IIRC, RIPE allocated a /19 to France Telecom. Doesn't take more than a few hundred thousand allocations like that one to wipe out the IPv6 address space." Do we expect a few hundred thousand places that need 2^29 (500M, give or take(OTTOMH)) /48s? Didn't we _just_ get to seeing ~64k ASNs as a limiting factor? /TJ Sent from my Verizon Wireless BlackBerry -----Original Message----- From: William Herrin Date: Fri, 14 Aug 2009 16:52:42 To: Jeroen Massar Cc: Nanog Subject: Re: IPv6 Addressing Help On Fri, Aug 14, 2009 at 2:40 PM, Jeroen Massar wrote: > William Herrin wrote: > [..] >> I'm not aware of any way of dynamically assigning an IPv6 subnet to a >> customer that's as well automated as IPv4 /32 dynamic assignment to a >> DSL router with an RFC1918 NATed interior, but that may just be my >> ignorance since I haven't needed to research it. > > DHCP-PD (prefix delegation) Hi Jeroen, Cool. So we'll have $100 CPE which uses it in a relatively idiot-proof manner sometime between now and eternity. >> Static IP customer: /60 > > ARIN defines a /56 minimum. That is the reason that ISPs get a /32. > RIPE defines a /48 at the moment. ARIN "defines" a /64 minimum customer assignment and suggests /56. They go on to say that, "RIRs/NIRs are not concerned about which address size an LIR/ISP actually assigns." See ARIN NRPM 6.5.4.1. https://www.arin.net/policy/nrpm.html#six54 >> I recommend /60 as the customer default where most folks suggest /56 >> or /48. The IPv6 use profile looks a heck of a lot like the IPv4 use >> profile and /60 is 16 subnets. How many of your customers find a >> reason to use more than 3 IPv4 subnets, including their RFC1918 ones? >> Relatively few. > > Think Future. And why bother with that anyway. If you as an ISP needs > more address space just ring RIPE/ARIN/APNIC and ask for more, they will > happily give it to you. The future looks a lot like the past but with more blinking lights. Seriously, I'm pretty nuts when it comes to networking. My basement is AS11875, multihomed with about 35mbps of bandwidth. If I can't imagine how *I* would use more than 16 subnets then it's a safe bet that many years will pass before Joe random DSL customer wants to. The world won't end, even if you assign every customer a /48. But why be so grossly wasteful *before* anyone has demonstrated a practical use for doing so? > I guess you ran the numbers on how to run out of IPv6 address space? IIRC, RIPE allocated a /19 to France Telecom. Doesn't take more than a few hundred thousand allocations like that one to wipe out the IPv6 address space. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From herrin-nanog at dirtside.com Fri Aug 14 16:38:15 2009 From: herrin-nanog at dirtside.com (William Herrin) Date: Fri, 14 Aug 2009 17:38:15 -0400 Subject: IPv6 Addressing Help In-Reply-To: <869154084-1250285130-cardhu_decombobulator_blackberry.rim.net-1846477473-@bxe1082.bisx.prod.on.blackberry> References: <4A857CB3.10600@uplogon.com> <3c3e3fca0908141133j73b26fd8o1066c93c846205e8@mail.gmail.com> <4A85AF86.5000603@spaghetti.zurich.ibm.com> <3c3e3fca0908141352me6d8b65ue7288b0b44172548@mail.gmail.com> <869154084-1250285130-cardhu_decombobulator_blackberry.rim.net-1846477473-@bxe1082.bisx.prod.on.blackberry> Message-ID: <3c3e3fca0908141438s298e949w859114ab5127f0c@mail.gmail.com> On Fri, Aug 14, 2009 at 5:26 PM, wrote: >> "IIRC, RIPE allocated a /19 to France Telecom. Doesn't take >>more than a few hundred thousand allocations like that one >>to wipe out the IPv6 address space." > > Do we expect a few hundred thousand places that need 2^29 >(500M, give or take(OTTOMH)) /48s? ?Didn't we _just_ get to >seeing ~64k ASNs as a limiting factor? No we don't. Including France's phone company. But that insanity is at least within the scope of my imagination... unlike more than a small percentage of cable modem users using more than 16 /64 subnets. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From kmedcalf at dessus.com Fri Aug 14 16:41:56 2009 From: kmedcalf at dessus.com (Keith Medcalf) Date: Fri, 14 Aug 2009 17:41:56 -0400 Subject: Follow up to previous post regarding SAAVIS In-Reply-To: <86481589-3D72-4AD0-B52C-27209C560AC3@merit.edu> Message-ID: <444206150fb2354fb7cb74ae4e1d1443@mail.dessus.com> > ... Dont know what web 2.0 is but the new portal is a web based > object management system complete > with "recommended" changes and inconsistency lists. > We just added prefix allocation check with backend information > from PCH (prefix checker tool). Web 2.0 is marketroid drivel-speak for a method of continuing to ensure that Web Applications are uninspectable and unsecurable. It is based on doing partial document refreshes using code executing within the browser, usually in such a fashion that it modifies the document tree directly through foreign (ie, from the net) code execution in the context of the current user (or, because of the zillions of holes in those browsers supporting code execution, with the priviledges of the OS itself). It is highly insecure and cannot be secured by any products currently available. It is best to stay as far as possible from anything claiming that it is Web 2.0. Hallmarks of Web 2.0 are gratuitous javascript and java applications which cannot be disabled. Enabling any type of even minimal security on any web site that is "Web 2.0" buzzword compliant results in the display of completely blank pages. Web 2.0 pages will indirect all hyperlinks and navigation through javascript. Not because it provides anything useful but rather in order to force people to enable dangerous crap in their browsers (javascript, java, Flash Virus, &c) -- () ascii ribbon campaign against html e-mail /\ www.asciiribbon.org From jmaimon at ttec.com Fri Aug 14 16:43:09 2009 From: jmaimon at ttec.com (Joe Maimon) Date: Fri, 14 Aug 2009 17:43:09 -0400 Subject: IPv6 Addressing Help In-Reply-To: <869154084-1250285130-cardhu_decombobulator_blackberry.rim.net-1846477473-@bxe1082.bisx.prod.on.blackberry> References: <4A857CB3.10600@uplogon.com><3c3e3fca0908141133j73b26fd8o1066c93c846205e8@mail.gmail.com><4A85AF86.5000603@spaghetti.zurich.ibm.com><3c3e3fca0908141352me6d8b65ue7288b0b44172548@mail.gmail.com> <869154084-1250285130-cardhu_decombobulator_blackberry.rim.net-1846477473-@bxe1082.bisx.prod.on.blackberry> Message-ID: <4A85DA6D.3090000@ttec.com> While I think the address planning problem is serious and hinges directly on this issue, I believe all these opinions and stances have been repeated so often here and elsewhere that I for one would like to hear something new. To my mind the question is simple. Decades or Centuries? trejrco at gmail.com wrote: > "IIRC, RIPE allocated a /19 to France Telecom. Doesn't take more than a few hundred thousand allocations like that one to wipe out the IPv6 address space." > > Do we expect a few hundred thousand places that need 2^29 (500M, give or take(OTTOMH)) /48s? Didn't we _just_ get to seeing ~64k ASNs as a limiting factor? > > > /TJ > Sent from my Verizon Wireless BlackBerry > > -----Original Message----- > From: William Herrin > > Date: Fri, 14 Aug 2009 16:52:42 > To: Jeroen Massar > Cc: Nanog > Subject: Re: IPv6 Addressing Help > > > On Fri, Aug 14, 2009 at 2:40 PM, Jeroen Massar wrote: >> William Herrin wrote: >> [..] >>> I'm not aware of any way of dynamically assigning an IPv6 subnet to a >>> customer that's as well automated as IPv4 /32 dynamic assignment to a >>> DSL router with an RFC1918 NATed interior, but that may just be my >>> ignorance since I haven't needed to research it. >> DHCP-PD (prefix delegation) > > Hi Jeroen, > > Cool. So we'll have $100 CPE which uses it in a relatively idiot-proof > manner sometime between now and eternity. > > >>> Static IP customer: /60 >> ARIN defines a /56 minimum. That is the reason that ISPs get a /32. >> RIPE defines a /48 at the moment. > > ARIN "defines" a /64 minimum customer assignment and suggests /56. > They go on to say that, "RIRs/NIRs are not concerned about which > address size an LIR/ISP actually assigns." > > See ARIN NRPM 6.5.4.1. https://www.arin.net/policy/nrpm.html#six54 > > >>> I recommend /60 as the customer default where most folks suggest /56 >>> or /48. The IPv6 use profile looks a heck of a lot like the IPv4 use >>> profile and /60 is 16 subnets. How many of your customers find a >>> reason to use more than 3 IPv4 subnets, including their RFC1918 ones? >>> Relatively few. >> Think Future. And why bother with that anyway. If you as an ISP needs >> more address space just ring RIPE/ARIN/APNIC and ask for more, they will >> happily give it to you. > > The future looks a lot like the past but with more blinking lights. > Seriously, I'm pretty nuts when it comes to networking. My basement is > AS11875, multihomed with about 35mbps of bandwidth. If I can't imagine > how *I* would use more than 16 subnets then it's a safe bet that many > years will pass before Joe random DSL customer wants to. > > The world won't end, even if you assign every customer a /48. But why > be so grossly wasteful *before* anyone has demonstrated a practical > use for doing so? > > >> I guess you ran the numbers on how to run out of IPv6 address space? > > IIRC, RIPE allocated a /19 to France Telecom. Doesn't take more than a > few hundred thousand allocations like that one to wipe out the IPv6 > address space. > > Regards, > Bill Herrin > > From kuenzler at init7.net Fri Aug 14 16:59:02 2009 From: kuenzler at init7.net (Fredy Kuenzler) Date: Fri, 14 Aug 2009 23:59:02 +0200 Subject: IPv6 Addressing Help In-Reply-To: <4A857CB3.10600@uplogon.com> References: <4A857CB3.10600@uplogon.com> Message-ID: <4A85DE26.3030405@init7.net> Hi, Chris Gotstein schrieb: > We are a small ISP that is in the process of setting up IPv6 on our > network. We already have the ARIN allocation and i have a couple routers > and servers running dual stack. Wondering if someone out there would be > willing to give me a few pointers on setting up my addressing scheme? > I've been mulling over how to do it, and i think i'm making it more > complicated than it needs to be. You can hit me offlist if you wish to > help. Thanks. I did some presentations in the past ~12 to 18 months about v6 for v4-cluefuls ... the slides have been evolved over time, still way from being perfect, but it contains some examples which have been proven useful for some, at least. http://www.blogg.ch/uploads/IPv6-best-practice.pdf HTH, Fredy K?nzler, Init7 From cidr-report at potaroo.net Fri Aug 14 17:00:01 2009 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 14 Aug 2009 22:00:01 GMT Subject: BGP Update Report Message-ID: <200908142200.n7EM01nf092955@wattle.apnic.net> BGP Update Report Interval: 06-Aug-09 -to- 13-Aug-09 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS4961 129280 4.6% 2191.2 -- DISC-AS-KR Daewoo Information System 2 - AS9198 84498 3.0% 244.2 -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration 3 - AS9767 79188 2.8% 2140.2 -- DONGBUIT-AS-KR Dongbulife Insurance co.,LTD 4 - AS23716 60670 2.2% 2166.8 -- CHANGWON23716-AS-KR Changwon College 5 - AS18157 53746 1.9% 2149.8 -- CHUNGJU-AS-KR chungju university 6 - AS9956 50700 1.8% 2204.3 -- KONGJU-AS kongju national university 7 - AS9459 50451 1.8% 2193.5 -- ASKONKUK Konkuk University 8 - AS9686 47780 1.7% 2171.8 -- SKKUNET-AS SungKyunKwan University (SKKU) 9 - AS10159 36626 1.3% 2154.5 -- HAUNET-AS-KR HANKUK Aviation University 10 - AS11 34449 1.2% 2649.9 -- HARVARD - Harvard University 11 - AS9530 33061 1.2% 1944.8 -- SHINSEGAE-AS SHINSEGAE I&C Co., Ltd. 12 - AS9628 30914 1.1% 1627.1 -- SSEM-AS-KR Seoul Education Science Research Institute 13 - AS33783 26953 1.0% 191.2 -- EEPAD 14 - AS9868 26490 0.9% 2207.5 -- CUTH-AS Catholic University of DAEGU 15 - AS10088 23806 0.8% 2164.2 -- KWANGWOON-UNIV-AS-AP KWANGWOON University in Seoul, Korea 16 - AS18023 21948 0.8% 2194.8 -- KMU-AS-KR Korea Maritime University 17 - AS18027 21940 0.8% 2194.0 -- NSU-AS-KR namseoul university 18 - AS18026 21516 0.8% 2151.6 -- CHEJU-AS-KR Cheju University 19 - AS17865 21220 0.8% 2122.0 -- SCOURT-AS-KR Supreme Court of Korea 20 - AS10045 20074 0.7% 2230.4 -- TNUTNET-AS HANBAT NATIONAL UNIVERSITY TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS23525 6124 0.2% 3062.0 -- CNC-CNB - Canandaigua National Corporation 2 - AS11 34449 1.2% 2649.9 -- HARVARD - Harvard University 3 - AS11191 4726 0.2% 2363.0 -- ELITE-NET - Elite.Net 4 - AS9852 9056 0.3% 2264.0 -- SAMIL-AS SAMIL ACCOUNTING CORPORATION 5 - AS17840 2244 0.1% 2244.0 -- KOREACERT-AS-KR KECA, Inc. 6 - AS3784 8976 0.3% 2244.0 -- ERX-POSTECHNET Pohang University of Science and Technology 7 - AS10058 6720 0.2% 2240.0 -- CU-AS-KR NACUFOK 8 - AS9969 2232 0.1% 2232.0 -- WMS-NET-AS-KR KOREA RESOURCES RECOVERY AND REUTILIZATION CORPORATION 9 - AS10045 20074 0.7% 2230.4 -- TNUTNET-AS HANBAT NATIONAL UNIVERSITY 10 - AS9322 4460 0.2% 2230.0 -- EWHANET1-AS Institute of Information and Computing, EWHA WOMANS UNIV. 11 - AS17600 2226 0.1% 2226.0 -- ENVICO-AS-KR Korea Environment & Resources Corporation 12 - AS18303 2220 0.1% 2220.0 -- SMARTRO-AS-KR SMARTRO 13 - AS17603 4438 0.2% 2219.0 -- KUMOH-AS-KR Kumoh National University Technology 14 - AS18343 15506 0.6% 2215.1 -- TAEGUTECH-AS-KR Daegu Technical College 15 - AS18320 4429 0.2% 2214.5 -- GNUE-AS-KR Gwangju National University of Education 16 - AS18315 6642 0.2% 2214.0 -- SORABOLNET-AS-KR Sorabol College 17 - AS10042 4424 0.2% 2212.0 -- DPC-AS-KR DAEGU POLYTECHNIC COLLEGE 18 - AS9868 26490 0.9% 2207.5 -- CUTH-AS Catholic University of DAEGU 19 - AS17567 6622 0.2% 2207.3 -- IREX-AS-KR Airport Railroad Co ltd 20 - AS18163 8824 0.3% 2206.0 -- JINJU18163-AS-KR jinju national university TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 88.204.221.0/24 9289 0.3% AS9198 -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration 2 - 95.59.1.0/24 9229 0.3% AS9198 -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration 3 - 95.59.8.0/23 9108 0.3% AS9198 -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration 4 - 95.59.4.0/22 9108 0.3% AS9198 -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration 5 - 95.59.3.0/24 9106 0.3% AS9198 -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration 6 - 95.59.2.0/23 9104 0.3% AS9198 -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration 7 - 92.46.244.0/23 9077 0.3% AS9198 -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration 8 - 89.218.218.0/23 9077 0.3% AS9198 -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration 9 - 89.218.220.0/23 9077 0.3% AS9198 -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration 10 - 66.152.126.0/24 6090 0.2% AS23525 -- CNC-CNB - Canandaigua National Corporation 11 - 72.23.246.0/24 5963 0.2% AS5050 -- PSC-EXT - Pittsburgh Supercomputing Center 12 - 193.201.184.0/21 5256 0.2% AS25546 -- BROOKLANDCOMP-AS Brookland Computer Services 13 - 67.118.199.0/24 4724 0.2% AS11191 -- ELITE-NET - Elite.Net 14 - 79.141.74.0/23 4080 0.1% AS43912 -- NEWCOM-AS ZAO "NEWCOM" 15 - 130.175.0.0/16 3940 0.1% AS11 -- HARVARD - Harvard University 16 - 19.0.0.0/8 3940 0.1% AS11 -- HARVARD - Harvard University 17 - 130.170.0.0/16 3939 0.1% AS11 -- HARVARD - Harvard University 18 - 192.12.120.0/24 2709 0.1% AS5691 -- MITRE-AS-5 - The MITRE Corporation 19 - 85.60.208.0/21 2503 0.1% AS12479 -- UNI2-AS Uni2 Autonomous System 20 - 129.9.236.0/23 2463 0.1% AS11 -- HARVARD - Harvard University 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 Aug 14 17:00:00 2009 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 14 Aug 2009 22:00:00 GMT Subject: The Cidr Report Message-ID: <200908142200.n7EM003o092948@wattle.apnic.net> This report has been generated at Fri Aug 14 21:11:44 2009 AEST. The report analyses the BGP Routing Table of AS2.0 router and generates a report on aggregation potential within the table. Check http://www.cidr-report.org for a current version of this report. Recent Table History Date Prefixes CIDR Agg 07-08-09 300092 183961 08-08-09 300177 184040 09-08-09 300115 184584 10-08-09 300358 185154 11-08-09 300492 185446 12-08-09 300591 185710 13-08-09 300384 185157 14-08-09 299670 185421 AS Summary 32073 Number of ASes in routing system 13648 Number of ASes announcing only one prefix 4311 Largest number of prefixes announced by an AS AS4323 : TWTC - tw telecom holdings, inc. 89683968 Largest address span announced by an AS (/32s) AS27064: DNIC-ASBLK-27032-27159 - DoD Network Information Center Aggregation Summary The algorithm used in this report proposes aggregation only when there is a precise match using the AS path, so as to preserve traffic transit policies. Aggregation is also proposed across non-advertised address space ('holes'). --- 14Aug09 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 300270 185401 114869 38.3% All ASes AS6389 4203 333 3870 92.1% BELLSOUTH-NET-BLK - BellSouth.net Inc. AS4323 4311 1701 2610 60.5% TWTC - tw telecom holdings, inc. AS4766 1829 541 1288 70.4% KIXS-AS-KR Korea Telecom AS17488 1550 306 1244 80.3% HATHWAY-NET-AP Hathway IP Over Cable Internet AS4755 1229 169 1060 86.2% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP AS22773 1086 71 1015 93.5% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. AS8151 1489 568 921 61.9% Uninet S.A. de C.V. AS18101 964 44 920 95.4% RIL-IDC Reliance Infocom Ltd Internet Data Centre, AS19262 1024 235 789 77.1% VZGNI-TRANSIT - Verizon Internet Services Inc. AS18566 1062 277 785 73.9% COVAD - Covad Communications Co. AS6478 1363 611 752 55.2% ATT-INTERNET3 - AT&T WorldNet Services AS8452 1027 298 729 71.0% TEDATA TEDATA AS1785 1727 1124 603 34.9% AS-PAETEC-NET - PaeTec Communications, Inc. AS4804 686 91 595 86.7% MPX-AS Microplex PTY LTD AS9498 634 60 574 90.5% BBIL-AP BHARTI Airtel Ltd. AS4808 761 200 561 73.7% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network AS24560 736 191 545 74.0% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services AS7303 626 95 531 84.8% Telecom Argentina S.A. AS22047 541 14 527 97.4% VTR BANDA ANCHA S.A. AS10620 990 475 515 52.0% TV Cable S.A. AS11492 1132 637 495 43.7% CABLEONE - CABLE ONE, INC. AS855 617 126 491 79.6% CANET-ASN-4 - Bell Aliant Regional Communications, Inc. AS4134 995 532 463 46.5% CHINANET-BACKBONE No.31,Jin-rong Street AS3356 1205 748 457 37.9% LEVEL3 Level 3 Communications AS7018 1492 1051 441 29.6% ATT-INTERNET4 - AT&T WorldNet Services AS5668 779 340 439 56.4% AS-5668 - CenturyTel Internet Holdings, Inc. AS17676 564 127 437 77.5% GIGAINFRA Softbank BB Corp. AS4780 565 138 427 75.6% SEEDNET Digital United Inc. AS9443 515 94 421 81.7% INTERNETPRIMUS-AS-AP Primus Telecommunications AS7011 988 568 420 42.5% FRONTIER-AND-CITIZENS - Frontier Communications of America, Inc. Total 36690 11765 24925 67.9% Top 30 total Possible Bogus Routes 24.225.128.0/17 AS36377 PATRIOT-MEDIA-NJ - Comcast Telecommunications, Inc. 24.245.128.0/17 AS11492 CABLEONE - CABLE ONE, INC. 41.223.92.0/22 AS36936 CELTEL-GABON Celtel Gabon Internet Service 41.223.112.0/22 AS5713 SAIX-NET 41.223.176.0/22 AS36981 41.223.188.0/24 AS22351 INTELSAT Intelsat Global BGP Routing Policy 41.223.189.0/24 AS26452 BRING-AS - BringCom, Inc. 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV - Wireless Broadband via Satellite 62.61.221.0/24 AS24974 TACHYON-EU Tachyon Europe BV - Wireless Broadband via Satellite 63.140.213.0/24 AS22555 UTC - Universal Talkware Corporation 63.143.251.0/24 AS22555 UTC - Universal Talkware Corporation 64.31.32.0/19 AS11955 SCRR-11955 - Road Runner HoldCo LLC 64.79.88.0/24 AS26096 LODDEN - Lodden Services 64.79.89.0/24 AS26096 LODDEN - Lodden Services 66.128.38.0/24 AS15246 Telecomunicaciones Satelitales TelesatS.A. 66.180.239.0/24 AS35888 VIGNETTE - VIGNETTE CORPORATION 66.206.32.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.33.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.34.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.35.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.40.0/22 AS174 COGENT Cogent/PSI 66.206.44.0/23 AS174 COGENT Cogent/PSI 66.206.47.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 66.207.32.0/20 AS23011 66.241.112.0/20 AS21547 REVNETS - Revolution Networks 66.245.176.0/20 AS19318 NJIIX-AS-1 - NEW JERSEY INTERNATIONAL INTERNET EXCHANGE LLC 69.6.80.0/24 AS13442 69.6.81.0/24 AS13442 69.71.192.0/20 AS13818 PHX-INTL-TELEPORT - Phoenix International Teleport 80.88.10.0/24 AS33774 DJAWEB 80.88.12.0/24 AS33779 wataniya-telecom-as 100.100.100.0/30 AS38676 AS33005-AS-KR wizsolution co.,Ltd 116.50.0.0/24 AS17754 EXCELL-AS Excellmedia 117.120.56.0/21 AS4755 TATACOMM-AS TATA Communications formerly VSNL is Leading ISP 121.46.0.0/16 AS4134 CHINANET-BACKBONE No.31,Jin-rong Street 121.50.10.0/24 AS38236 121.50.13.0/24 AS38236 121.50.15.0/24 AS17625 BLAZENET-IN-AP BlazeNet's Network 121.50.168.0/21 AS9931 CAT-AP The Communication Authoity of Thailand, CAT 122.128.120.0/22 AS38456 PACTEL-AS-AP Pacific Teleports. 158.222.5.0/24 AS21580 SIERRA-ADVANTAGE - Sierra Advantage, Inc. 158.222.70.0/23 AS6137 SISNA - SISNA, Inc. 158.222.72.0/23 AS6137 SISNA - SISNA, Inc. 158.222.224.0/20 AS19864 O1COMM - O1 COMMUNICATIONS 158.222.224.0/22 AS19864 O1COMM - O1 COMMUNICATIONS 158.222.229.0/24 AS19864 O1COMM - O1 COMMUNICATIONS 163.142.0.0/16 AS2500 WIDE-BB WIDE Project 172.7.0.0/24 AS28175 172.10.1.0/30 AS18305 POSNET POSDATA Co.,Ltd 178.0.0.0/16 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 178.1.0.0/21 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 178.1.24.0/24 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 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.141.0/24 AS2018 TENET-1 192.96.177.0/24 AS6083 POSIX-AFRICA 192.101.45.0/24 AS2905 TICSA-ASN 192.101.46.0/24 AS6503 Avantel, S.A. 192.101.64.0/21 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 192.101.70.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 192.101.71.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 192.101.72.0/24 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 192.101.74.0/24 AS1239 SPRINTLINK - Sprint 192.124.248.0/23 AS680 DFN-IP service X-WiN 192.124.252.0/22 AS680 DFN-IP service X-WiN 192.131.233.0/24 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 192.132.58.0/24 AS20141 QUALITYTECH-SUW-300 - Quality Technology Services, LLC. 192.133.6.0/24 AS10282 ORANGE-BUSINESS-SERVICES-CEEUR Orange Business Services (formerly Equant) AS for CEEUR 192.139.3.0/24 AS23184 PERSONA - PERSONA COMMUNICATIONS INC. 192.153.144.0/21 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 192.154.32.0/19 AS81 NCREN - MCNC 192.188.208.0/20 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 193.33.148.0/23 AS30890 EVOLVA Evolva Telecom / iLink Telecom 193.104.229.0/26 AS34444 EUTELSAT-BACKBONE-AS EUTELSAT S.A. 196.6.108.0/24 AS5713 SAIX-NET 196.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.73.210.0/24 AS21570 ACI-1 - Accelerated Connections Inc. 198.97.72.0/21 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 198.97.96.0/19 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 198.97.240.0/20 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 198.135.236.0/24 AS4358 XNET - XNet Information Systems, Inc. 198.161.87.0/24 AS6539 GT-BELL - Bell Canada 198.161.92.0/24 AS6539 GT-BELL - Bell Canada 198.167.0.0/16 AS7456 INTERHOP - Interhop Network SERVICES Inc. 198.168.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 198.169.0.0/16 AS803 SASKTEL - Saskatchewan Telecommunications 198.180.198.0/24 AS23715 SEOUL-INTGW-GXS-AP Global Exchange Services 199.5.242.0/24 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 199.10.0.0/16 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.16.32.0/19 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 199.114.0.0/21 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.114.128.0/18 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.114.130.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.131.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.132.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.134.0/24 AS3541 ITSDN-U4 - DoD Network Information Center 199.114.136.0/24 AS27044 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.114.138.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.140.0/24 AS3544 ITSDN-U7 - DoD Network Information Center 199.114.142.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.144.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.148.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.150.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.152.0/24 AS27033 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.114.153.0/24 AS27034 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.114.154.0/24 AS1733 CENTAF-SWA - 754th Electronic Systems Group 199.114.156.0/24 AS1733 CENTAF-SWA - 754th Electronic Systems Group 199.114.160.0/24 AS1733 CENTAF-SWA - 754th Electronic Systems Group 199.121.0.0/16 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.123.0.0/18 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.123.16.0/20 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.123.80.0/21 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.189.32.0/19 AS7332 IQUEST-AS - IQuest Internet 199.202.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 199.202.216.0/21 AS577 BACOM - Bell Canada 199.233.92.0/24 AS26896 ITCOMM - IT Communications 199.246.116.0/24 AS813 UUNET-CANADA - MCI Communications Services, Inc. d/b/a Verizon Business 200.9.115.0/24 AS10292 CWJ-1 - Cable & Wireless Jamaica 200.108.176.0/20 AS14551 UUNET-SA - MCI Communications Services, Inc. d/b/a Verizon Business 202.6.176.0/20 AS24316 202.58.113.0/24 AS19161 202.73.144.0/20 AS4788 TMNET-AS-AP TM Net, Internet Service Provider 202.80.192.0/20 AS2706 PI-HK Pacnet Internet (Hong Kong) Limited 202.84.10.0/23 AS9308 CHINA-ABITCOOL Abitcool(China) Inc. 202.86.252.0/22 AS4748 RESOLINK-AS-AP Resources Link Network Limited 202.86.252.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.253.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.254.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.255.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.94.70.0/24 AS2764 AAPT AAPT Limited 202.124.195.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.125.113.0/24 AS9541 CYBERNET-AP Cyber Internet Services (Pvt) Ltd. 202.125.114.0/24 AS9541 CYBERNET-AP Cyber Internet Services (Pvt) Ltd. 202.125.115.0/24 AS9541 CYBERNET-AP Cyber Internet Services (Pvt) Ltd. 202.133.37.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.133.47.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.133.70.0/24 AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited 202.133.73.0/24 AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited 202.136.254.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.136.255.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.140.160.0/24 AS4841 202.140.161.0/24 AS4841 202.140.162.0/24 AS4841 202.140.163.0/24 AS4841 202.140.164.0/24 AS4841 202.140.165.0/24 AS4841 202.140.166.0/24 AS4841 202.140.167.0/24 AS4841 202.140.168.0/24 AS4841 202.140.169.0/24 AS4841 202.140.170.0/24 AS4841 202.140.171.0/24 AS4841 202.140.172.0/24 AS4841 202.140.173.0/24 AS4841 202.140.174.0/24 AS4841 202.140.175.0/24 AS4841 202.140.180.0/24 AS7540 HKCIX-AS-AP HongKong Commercial Internet Exchange 202.140.181.0/24 AS7540 HKCIX-AS-AP HongKong Commercial Internet Exchange 202.140.182.0/24 AS7540 HKCIX-AS-AP HongKong Commercial Internet Exchange 202.150.227.0/24 AS17727 NAPINFO-AS-AP PT. NAP Info Lintas Nusa 202.181.32.0/24 AS4645 ASN-HKNET-AP HKNet Co. Ltd 203.12.45.0/24 AS4854 NETSPACE-AS-AP Netspace Online Systems 203.62.0.0/17 AS7575 AARNET-AS-AP Australian Academic and Reasearch Network (AARNet) 203.78.48.0/20 AS9299 IPG-AS-AP Philippine Long Distance Telephone Company 203.80.136.0/21 AS4759 EVOSERVE-AS-AP EvoServe is a content and online access Internet provider company 203.86.96.0/19 AS4755 TATACOMM-AS TATA Communications formerly VSNL is Leading ISP 203.89.139.0/24 AS17911 BRAINPK-AS-AP Brain Telecommunication Ltd. 203.112.111.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.113.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.114.0/24 AS4802 ASN-IINET iiNet Limited 203.112.116.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.117.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.118.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.119.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.120.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.121.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.127.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.128.128.0/24 AS23849 CNNIC-NET263-AP Beijing Capital-online science development Co.,Ltd. 203.142.219.0/24 AS45149 203.189.96.0/20 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 204.9.216.0/23 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 204.9.218.0/23 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 204.19.14.0/23 AS577 BACOM - Bell Canada 204.89.214.0/24 AS4323 TWTC - tw telecom holdings, inc. 204.138.167.0/24 AS18990 AIRBAND-DALLAS - Airband Communications, Inc 204.197.0.0/16 AS3356 LEVEL3 Level 3 Communications 205.150.0.0/15 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 205.189.134.0/24 AS11814 CYBERSURF - Cybersurf Inc. 205.210.145.0/24 AS11814 CYBERSURF - Cybersurf Inc. 206.180.240.0/20 AS12083 KNOLOGY-NET - Knology Holdings 207.174.0.0/16 AS13790 INTERNAP-BLK3 - Internap Network Services Corporation 207.174.131.0/24 AS30715 NETRACK - Netrack, Inc. 207.174.132.0/23 AS30715 NETRACK - Netrack, Inc. 207.174.151.0/24 AS11500 PEAKPEAK - Peak to Peak Internet 207.174.152.0/22 AS30715 NETRACK - Netrack, Inc. 207.174.177.0/24 AS11500 PEAKPEAK - Peak to Peak Internet 207.174.178.0/24 AS11500 PEAKPEAK - Peak to Peak Internet 207.174.182.0/24 AS29831 FONENET - FONE NET, LLC 207.174.188.0/22 AS30715 NETRACK - Netrack, Inc. 207.174.192.0/24 AS29831 FONENET - FONE NET, LLC 207.174.200.0/24 AS22658 EARTHNET - Earthnet, Inc. 207.174.248.0/21 AS6653 PRIVATEI - privateI, LLC 207.231.96.0/19 AS11194 NUNETPA - NuNet Inc. 208.73.88.0/21 AS36835 208.77.224.0/24 AS36835 208.77.225.0/24 AS36835 208.77.226.0/24 AS36835 208.77.227.0/24 AS36835 208.77.228.0/24 AS36835 208.77.229.0/24 AS36835 208.77.230.0/24 AS36835 208.77.231.0/24 AS36835 209.54.123.0/24 AS6062 NETPLEX - NETPLEX 209.54.240.0/21 AS10887 BPSI-AS - BPSI Internet Services 209.74.96.0/19 AS10912 INTERNAP-BLK - Internap Network Services Corporation 209.140.90.0/24 AS14461 NTSL - NET SOLUTIONS 209.141.48.0/22 AS14461 NTSL - NET SOLUTIONS 209.217.224.0/19 AS6130 AIS-WEST - American Internet Services, LLC. 209.222.5.0/24 AS26699 PSI-CT - Printing For Systems Inc 209.222.6.0/24 AS26699 PSI-CT - Printing For Systems Inc 210.5.128.0/20 AS4837 CHINA169-BACKBONE CNCGROUP China169 Backbone 210.247.224.0/19 AS7496 WEBCENTRAL-AS WebCentral 213.181.70.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.80.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.81.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.82.0/23 AS17175 NSS-UK New Skies Satellites UK AS 213.181.82.0/24 AS17175 NSS-UK New Skies Satellites UK AS 213.181.83.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.84.0/22 AS17175 NSS-UK New Skies Satellites UK AS 213.181.84.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.85.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.86.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.87.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.88.0/21 AS17175 NSS-UK New Skies Satellites UK AS 213.181.88.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.89.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.90.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.91.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.92.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.93.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.94.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.95.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 216.99.20.0/24 AS3356 LEVEL3 Level 3 Communications 216.163.144.0/20 AS35985 ONERINGNET-ATL-1 - One Ring Networks, Inc. 216.172.198.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 216.172.199.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 216.251.207.0/24 AS1239 SPRINTLINK - Sprint 217.78.71.0/24 AS12491 IPPLANET-AS Gilat Satcom 217.78.72.0/24 AS12491 IPPLANET-AS Gilat Satcom 217.78.73.0/24 AS12491 IPPLANET-AS Gilat Satcom Please see http://www.cidr-report.org for the full report ------------------------------------ Copies of this report are mailed to: nanog at merit.edu eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From marka at isc.org Fri Aug 14 17:05:49 2009 From: marka at isc.org (Mark Andrews) Date: Sat, 15 Aug 2009 08:05:49 +1000 Subject: IPv6 Addressing Help In-Reply-To: Your message of "Fri, 14 Aug 2009 16:49:30 +0100." <4A85878A.2000208@uk.clara.net> References: <4A857CB3.10600@uplogon.com> <4A85800A.6020703@spaghetti.zurich.ibm.com> <4A858368.1030200@uplogon.com> <4A85878A.2000208@uk.clara.net> Message-ID: <200908142205.n7EM5nrS082260@drugs.dv.isc.org> In message <4A85878A.2000208 at uk.clara.net>, David Freedman writes: > > Chris Gotstein wrote: > > I think we had to let ARIN know the time frame of deploying IPv6 and how > > many customers we expected to put on in the first couple years. They > > did not ask for an addressing scheme. > > > > Reading over the RFC's and other IPv6 resources, we have decided to hand > > out /56's to small/home/SOHO customers and /48's to larger customers. > > > > I'm just not able to wrap my brain around the subnetting that needs to > > be done on the router. Like i said before, i think i'm just over > > complicating it in my mind. > > Will keep it simple, this is what I (and I suspect many others) do > > /128 - Loopback (what else?) > /126 - Router p2p > /112 - Router LAN shared segments (p2mp) > /64 - Single customer LAN segments (customers asking for basic IPv6) > /56 - Customer wants multiple LANs, doesn't want to fill out > justification form > /48 - Customer wants multiple LANs, thinks /56 is too small (for some > reason), needs for routing, wants rDNS delegation etc.etc.etc.. Why do you think only /48 customers will want reverse DNS? Every customer will want reverse DNS. The question is who supplies the nameservers. With the home market potentially getting routable address to all machines there will also be a need to supply forward DNS services as well. > This question gets asked so many times now, whilst people argue about > the implications of using networks smaller than /64 for anything > such deployments continue to exist and are successful. > > Perhaps we should document people's addressing plans somewhere, I > see ratemyaddressingplan.com hasn't been taken yet? :) > > Dave. > > > > > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From brandon at rd.bbc.co.uk Fri Aug 14 17:35:40 2009 From: brandon at rd.bbc.co.uk (Brandon Butterworth) Date: Fri, 14 Aug 2009 23:35:40 +0100 (BST) Subject: IPv6 Addressing Help Message-ID: <200908142235.XAA01474@sunf10.rd.bbc.co.uk> > Cool. So we'll have $100 CPE which uses it in a relatively idiot-proof > manner sometime between now and eternity. More now than eternity - To: UKNOF Date: Fri, 14 Aug 2009 16:26:44 +0100 "Marco Hogewoning of Dutch ISP XS4ALL talks about the roll out of IPv6 in their 300,000 customer network. German modem vendor AVM supplies them with a CPE that supports native IPv6, although it does have some limitations that need to be ironed out. Marco talks about how they got in touch with them, how they handle the spec and the issues, and how the project gained traction when the Sales department got interested. http://www.youtube.com/watch?v=f3WcWBIQ11A brandon From david.freedman at uk.clara.net Fri Aug 14 17:51:18 2009 From: david.freedman at uk.clara.net (David Freedman) Date: Fri, 14 Aug 2009 23:51:18 +0100 Subject: IPv6 Addressing Help References: <4A857CB3.10600@uplogon.com> <4A85800A.6020703@spaghetti.zurich.ibm.com> <4A858368.1030200@uplogon.com> <4A85878A.2000208@uk.clara.net> <200908142205.n7EM5nrS082260@drugs.dv.isc.org> Message-ID: <7B8B0D6F623C3A40A0D0A80A66756E2B0D7F06@EXVS01.claranet.local> Sorry, to clear this up, after now two replies, I was talking about delegation of the reverse zone to customer nameservers, and yes, I'm aware you can do this at smaller than /48, we just happen not to at present, we decided to draw the line somewhere (and what was relevant here was our own, internal policy) ------------------------------------------------ David Freedman Group Network Engineering Claranet Limited http://www.clara.net -----Original Message----- From: Mark Andrews [mailto:marka at isc.org] Sent: Fri 8/14/2009 23:05 To: David Freedman Cc: Chris Gotstein; Nanog Subject: Re: IPv6 Addressing Help In message <4A85878A.2000208 at uk.clara.net>, David Freedman writes: > > Chris Gotstein wrote: > > I think we had to let ARIN know the time frame of deploying IPv6 and how > > many customers we expected to put on in the first couple years. They > > did not ask for an addressing scheme. > > > > Reading over the RFC's and other IPv6 resources, we have decided to hand > > out /56's to small/home/SOHO customers and /48's to larger customers. > > > > I'm just not able to wrap my brain around the subnetting that needs to > > be done on the router. Like i said before, i think i'm just over > > complicating it in my mind. > > Will keep it simple, this is what I (and I suspect many others) do > > /128 - Loopback (what else?) > /126 - Router p2p > /112 - Router LAN shared segments (p2mp) > /64 - Single customer LAN segments (customers asking for basic IPv6) > /56 - Customer wants multiple LANs, doesn't want to fill out > justification form > /48 - Customer wants multiple LANs, thinks /56 is too small (for some > reason), needs for routing, wants rDNS delegation etc.etc.etc.. Why do you think only /48 customers will want reverse DNS? Every customer will want reverse DNS. The question is who supplies the nameservers. With the home market potentially getting routable address to all machines there will also be a need to supply forward DNS services as well. > This question gets asked so many times now, whilst people argue about > the implications of using networks smaller than /64 for anything > such deployments continue to exist and are successful. > > Perhaps we should document people's addressing plans somewhere, I > see ratemyaddressingplan.com hasn't been taken yet? :) > > Dave. > > > > > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From nanog at daork.net Fri Aug 14 19:15:16 2009 From: nanog at daork.net (Nathan Ward) Date: Sat, 15 Aug 2009 10:15:16 +1000 Subject: IPv6 Addressing Help In-Reply-To: <4A857CB3.10600@uplogon.com> References: <4A857CB3.10600@uplogon.com> Message-ID: <1000BA91-F4CE-4FB2-8997-7C52B4B43739@daork.net> On 15/08/2009, at 1:03 AM, Chris Gotstein wrote: > We are a small ISP that is in the process of setting up IPv6 on our > network. We already have the ARIN allocation and i have a couple > routers and servers running dual stack. Wondering if someone out > there would be willing to give me a few pointers on setting up my > addressing scheme? I've been mulling over how to do it, and i think > i'm making it more complicated than it needs to be. You can hit me > offlist if you wish to help. Thanks. I have some things to say on this. I've padded some of the following with zeros to make it easier to read/understand. Let's say your allocation is 2001:db8::/32 (doc prefix) 2001:db8::/32 2001:db8::/48 - ISP use 2001:db8::/64 - ISP internal routers 2001:db8::/112 - 65K loopbacks for your routers 2001:db8::0001:0/112 .. through .. 2001:db8::ffff:ffff:ffff:0/112 - 281 trillion link nets between your routers 2001:db8:0000:0001::/64 .. through .. 2001:db8:0000:ffff::/64 - 65K-1 /64s for ISP servers, offices, etc. etc. 2001:db8:0001::/48 .. through .. 2001:db8:000f::/48 - 9M Customer link nets 2001:db8:0010::/48 .. through .. 2001:db8:ffff::/48 - Assigned to customers Some notes: 1) The "Customer link nets" block should be long enough for you to get one link net per customer tail. You should do /64s for link nets to customers, unless you are *certain* that *all* customer devices will support whatever else you choose to use. The 15 I have suggested here gives you ~9M. 2) The "Assigned to customers" block can be chopped up in to /48s or / 56s or /60s or whatever your want. I recommend chopping customer prefixes on 4-bit boundaries (4 bits per hex digit). Less IP math in your head = easier life. Especially for helpdesk staff, and customers themselves. 3) Filter the "ISP internal routers" prefix at your border. This is equivalent to your /30s, /31s and /32s in IPv4 land. 4) The reason we have the loopbacks in the very first /112, is you will have to type them a lot, and fudging them can make your network melt down. 5) The reason we have the ISP internal /64s in the first /64s, is for the same reason as (4). 6) The reason we have ISP servers etc. in the following /64s, is these are also short to type, which means customers and first line support can type your DNS server addresses easily, read them over the phone, etc. 7) Allow the first /48 through all your filters that normally impact customers - and rate shaping, etc. etc. This first /48 is for ISP stuff, no customers should ever be on it. This is the only place where ISP stuff should ever live. You will have a temptation to chop your customer address space up in to "City", "POP", etc. I recommend resisting that - you are reinventing classful addressing, and when one POP or city grows too large, you have to make exceptions to your rules. Instead, when you need new addresses in an area (ie. you need more than zero IPv6 addresses at a POP) assign it a /48. Then when you need more, assign it another /48. You can do this intelligently, using the binary chop/sparse allocation method that Geoff Huston has written about. This lets you grow your / 48s in to /47s, or /46s as need arises. By doing your assignment this way, you don't get tied in to silly rules, nor do you get IGP bloat. I have an extensible IP management tool that I've been hacking on heaps in the last week that does this stuff for you. It should be ready for people to tinker with in the next few weeks. -- Nathan Ward -- Nathan Ward From patrick at ianai.net Fri Aug 14 23:10:29 2009 From: patrick at ianai.net (Patrick W. Gilmore) Date: Sat, 15 Aug 2009 00:10:29 -0400 Subject: The Cidr Report In-Reply-To: <200908142200.n7EM003o092948@wattle.apnic.net> References: <200908142200.n7EM003o092948@wattle.apnic.net> Message-ID: On Aug 14, 2009, at 6:00 PM, cidr-report at potaroo.net wrote: > This report has been generated at Fri Aug 14 21:11:44 2009 AEST. > The report analyses the BGP Routing Table of AS2.0 router > and generates a report on aggregation potential within the table. > > Check http://www.cidr-report.org for a current version of this report. > > Recent Table History > Date Prefixes CIDR Agg > 07-08-09 300092 183961 > 08-08-09 300177 184040 > 09-08-09 300115 184584 > 10-08-09 300358 185154 > 11-08-09 300492 185446 > 12-08-09 300591 185710 > 13-08-09 300384 185157 > 14-08-09 299670 185421 WHOA! Looks like we have another bet to make. :) More seriously, this is excellent news. Hopefully everyone out there is aggregating like crazy. I know we pulled 4x/24 into /22 recently (when someone notified us - oops). Can everyone else check their announcements? Maybe we can stay under 300K for a long time! -- TTFN, patrick From herrin-nanog at dirtside.com Fri Aug 14 23:38:12 2009 From: herrin-nanog at dirtside.com (William Herrin) Date: Sat, 15 Aug 2009 00:38:12 -0400 Subject: IPv6 Addressing Help In-Reply-To: <1000BA91-F4CE-4FB2-8997-7C52B4B43739@daork.net> References: <4A857CB3.10600@uplogon.com> <1000BA91-F4CE-4FB2-8997-7C52B4B43739@daork.net> Message-ID: <3c3e3fca0908142138u26d44deby932b874eb3f1aec2@mail.gmail.com> On Fri, Aug 14, 2009 at 8:15 PM, Nathan Ward wrote: > you are reinventing > classful addressing, and when one POP or city grows too large, you have to > make exceptions to your rules. Nathan, I'm going to contradict you there. Classful addressing had a lot to recommend it. The basic problem we ran in to was that there weren't enough B's for everyone who needed more than a C and there weren't enough A's period. So we started handing out groups of disaggregate C's and that path led to the swamp. CIDR too is the architect of its own demise. With address assignments all mixed together, we lack clean boundaries by which we can identify the multihomed orgs amidst the disaggregation for traffic engineering. Thus Bell South announces 4200 routes and we carry them all with an annual systemic cost in the neighborhood of $30M. The route table continues to grow beyond our control. With IPv6 we have more than enough addresses to give a /56 to everybody who needs more than a /60 and a /48 to everybody who needs more than a /56. A rapidly escalating assignment series like this would place a strong upper bound on the number of routes needed for any one entity regardless of how they grow. Allocating from pools reserved solely for specific prefix sizes should enable the compression of distant TE disaggregation. Maybe it's worth considering the benefits of a classful-like addressing before casually discarding it as yesterday's news. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From randy at psg.com Sat Aug 15 01:34:10 2009 From: randy at psg.com (Randy Bush) Date: Sat, 15 Aug 2009 15:34:10 +0900 Subject: IPv6 Addressing Help In-Reply-To: <3c3e3fca0908142138u26d44deby932b874eb3f1aec2@mail.gmail.com> References: <4A857CB3.10600@uplogon.com> <1000BA91-F4CE-4FB2-8997-7C52B4B43739@daork.net> <3c3e3fca0908142138u26d44deby932b874eb3f1aec2@mail.gmail.com> Message-ID: > I'm going to contradict you there. Classful addressing had a lot to > recommend it. The basic problem we ran in to was that there weren't > enough B's for everyone who needed more than a C and there weren't > enough A's period. So we started handing out groups of disaggregate > C's and that path led to the swamp. the swamp preceeded cidr and, if you had a bit of simple arithmetic clue, you would realize that, unless you are prescient, you will always run out of some classes before others. as we are very poor at predicting the future, there was no win to be had in classful. randy From nanog at daork.net Sat Aug 15 02:03:05 2009 From: nanog at daork.net (Nathan Ward) Date: Sat, 15 Aug 2009 17:03:05 +1000 Subject: IPv6 Addressing Help In-Reply-To: References: <4A857CB3.10600@uplogon.com> <1000BA91-F4CE-4FB2-8997-7C52B4B43739@daork.net> <3c3e3fca0908142138u26d44deby932b874eb3f1aec2@mail.gmail.com> Message-ID: On 15/08/2009, at 4:34 PM, Randy Bush wrote: >> I'm going to contradict you there. Classful addressing had a lot to >> recommend it. The basic problem we ran in to was that there weren't >> enough B's for everyone who needed more than a C and there weren't >> enough A's period. So we started handing out groups of disaggregate >> C's and that path led to the swamp. > > the swamp preceeded cidr > > and, if you had a bit of simple arithmetic clue, you would realize > that, > unless you are prescient, you will always run out of some classes > before > others. as we are very poor at predicting the future, there was no > win > to be had in classful. This is really this basis of my reply, so, I'll just say +1 Read about how sparse allocation/binary chop stuff works. You get the same amount of routes in your IGP table (or less) but it's much more flexible. -- Nathan Ward From nenolod at systeminplace.net Sat Aug 15 09:29:06 2009 From: nenolod at systeminplace.net (William Pitcock) Date: Sat, 15 Aug 2009 09:29:06 -0500 Subject: IPv6 Addressing Help In-Reply-To: <3c3e3fca0908142138u26d44deby932b874eb3f1aec2@mail.gmail.com> References: <4A857CB3.10600@uplogon.com> <1000BA91-F4CE-4FB2-8997-7C52B4B43739@daork.net> <3c3e3fca0908142138u26d44deby932b874eb3f1aec2@mail.gmail.com> Message-ID: <1250346546.1482.9.camel@petrie> Hi, On Sat, 2009-08-15 at 00:38 -0400, William Herrin wrote: > With IPv6 we have more than enough addresses to give a /56 to > everybody who needs more than a /60 and a /48 to everybody who needs > more than a /56. I don't think this is a good assumption to make. Just because the namespace keylength (where the IP address is the keyvalue) is 96 bits longer than with IPv4, one needs to keep in mind that there will be eventually a shortage of addresses, if only theoretical. > A rapidly escalating assignment series like this would place a strong > upper bound on the number of routes needed for any one entity > regardless of how they grow. Allocating from pools reserved solely for > specific prefix sizes should enable the compression of distant TE > disaggregation. I think pooling a /32 or /48 or whatever the allocation is like you described is however a good idea. Many of our IPv6 customers however, only want one specific IP address (so they can IPv6-enable their website). We assign those customers /96 subnets, and that seems to be going pretty well. The nice benefit of that is that we can aggregate those as say, a single /64 in our core router without polluting the IGP routes on our border routers (and IPv6 route entries typically use about twice as much memory as IPv4 route entries, so that is important to keep in mind.) I wish the RFCs had something useful to say about how to handle those single IP addressing situations. So far the discussion there is /80 vs /96, but both of those subnets seem wasteful to me. One of our upstream providers hands our border router off a /125 (which is just weird), for these single-ip-needed situations. William -- William Pitcock SystemInPlace - Simple Hosting Solutions 1-866-519-6149 http://www.systeminplace.net/ Follow us on Twitter: http://www.twitter.com/systeminplace From herrin-nanog at dirtside.com Sat Aug 15 10:29:46 2009 From: herrin-nanog at dirtside.com (William Herrin) Date: Sat, 15 Aug 2009 11:29:46 -0400 Subject: IPv6 Addressing Help In-Reply-To: References: <4A857CB3.10600@uplogon.com> <1000BA91-F4CE-4FB2-8997-7C52B4B43739@daork.net> <3c3e3fca0908142138u26d44deby932b874eb3f1aec2@mail.gmail.com> Message-ID: <3c3e3fca0908150829x40a0a1f4t8f77d14aca91f3fa@mail.gmail.com> On Sat, Aug 15, 2009 at 2:34 AM, Randy Bush wrote: >> I'm going to contradict you there. Classful addressing had a lot to >> recommend it. The basic problem we ran in to was that there weren't >> enough B's for everyone who needed more than a C and there weren't >> enough A's period. So we started handing out groups of disaggregate >> C's and that path led to the swamp. > > the swamp preceeded cidr Randy, Correct. Disaggregate classful blocks overwhelming the routers was part of the problem. CIDR was part of the solution. That's what I said. > and, if you had a bit of simple arithmetic clue, you would realize that, > unless you are prescient, you will always run out of some classes before > others. Of course. That's what reserves are for: a resource you move into place after you discover where it's needed. Whether its a reserve force in a military action, the reserve slack in your unix disk partition or the emergency fund in your bank account, this is a long solved problem in human endeavor. On Sat, Aug 15, 2009 at 3:03 AM, Nathan Ward wrote: > Read about how sparse allocation/binary chop stuff works. You get the same > amount of routes in your IGP table (or less) but it's much more flexible. Sparse allocation says that you maximize the potential expansion of an allocation by simply changing its netmask. That means your first two allocations go at 0% and 50% (allowing either to expand to half your space), your next two go at 25% and 75% (allowing any to expand to 1/4th of your space) and so on. Let's try some of Randy's simple arithmetic on sparse allocation. Start with: /32 Sparsely allocate 200 /56's Total remaining space: in excess of /33. In fact, you haven't consumed a single /48. Expandability by altering the netmask: to /40 Largest allocation still possible: only /40 See the problem? You've eaten 8 bits of capability long before you've consumed even half of your space. In fact, when you do consume close to half your space, the largest remaining block is a meager /47 and your expandability of all those /56's is only to /47. Software developers very rarely fragment a resource pool on purpose because of precisely this problem. On the other hand, consider an escalating pools (aka classful) scenario: /32 broken into four pools: /34 for the /60 pool /34 for the /56 pool /34 for the /48 and larger pool /34 for the reserve pool Assume that: 90% of allocations are /60 9.9% are /56 0.1% are /48 or larger 100,000 allocations into this strategy you haven't tapped the reserve pool and it's probably still possible for you to allocate a /35 from the /48+ pool. And the price for this structure is that a small number of the registrants will have more than 1 but less than 4 routes (one each of /60, /56 and /48+) as opposed to sparse allocation improves the probability that they'll have only 1 route. On the other hand, 100,000 allocations in to the fore-mentioned sparse allocation, while there's a higher probability of each user having only 1 route, the largest users will need many more than 1. You've used a total of /42, maybe a little more of your space but your largest remaining free space is only /48. So if you need to accomodate a /44 customer, you'll have to give him 16 discontiguous /48's. Sparse is a farce. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From lists at netrogenic.com Sat Aug 15 10:38:18 2009 From: lists at netrogenic.com (Jay Ess) Date: Sat, 15 Aug 2009 17:38:18 +0200 Subject: TransAtlantic 40 Gig Waves In-Reply-To: References: <1E8B940C5E21014AB8BE70B975D40EDB0162857C@bert.HiberniaAtlantic.local> <4A849D32.3040604@internode.com.au> <1E8B940C5E21014AB8BE70B975D40EDB016285B5@bert.HiberniaAtlantic.local> <28620.1250277173@turing-police.cc.vt.edu> Message-ID: <4A86D66A.4010509@netrogenic.com> In November 24th 2008 Sunet together with Telia and Sprint reached 40Gb on one wavelength using TAT-14. The total length for the project was 9600 kilometers (the length of Sweden plus TAT-14). The Swedish article can be found here http://techworld.idg.se/2.2524/1.215856/sunet-forst-med-40-gigabit-per-sekund-under-atlanten From leen at consolejunkie.net Sat Aug 15 18:46:33 2009 From: leen at consolejunkie.net (Leen Besselink) Date: Sun, 16 Aug 2009 01:46:33 +0200 Subject: Follow up to previous post regarding SAAVIS In-Reply-To: <444206150fb2354fb7cb74ae4e1d1443@mail.dessus.com> References: <444206150fb2354fb7cb74ae4e1d1443@mail.dessus.com> Message-ID: <4A8748D9.70808@consolejunkie.net> Keith Medcalf wrote: >> ... Dont know what web 2.0 is but the new portal is a web based >> object management system complete >> with "recommended" changes and inconsistency lists. >> We just added prefix allocation check with backend information >> from PCH (prefix checker tool). > > Web 2.0 is marketroid drivel-speak for a method of continuing to ensure that Web Applications > are uninspectable and unsecurable. It is based on doing partial document refreshes using code > executing within the browser, usually in such a fashion that it modifies the document tree > directly through foreign (ie, from the net) code execution in the context of the current > user (or, because of the zillions of holes in those browsers supporting code execution, > with the priviledges of the OS itself). > > It is highly insecure and cannot be secured by any products currently available. It is best > to stay as far as possible from anything claiming that it is Web 2.0. Hallmarks of Web 2.0 > are gratuitous javascript and java applications which cannot be disabled. Enabling any type > of even minimal security on any web site that is "Web 2.0" buzzword compliant results in the > display of completely blank pages. Web 2.0 pages will indirect all hyperlinks and navigation > through javascript. Not because it provides anything useful but rather in order to force > people to enable dangerous crap in their browsers (javascript, java, Flash Virus, &c) > > Their are people who do understand how to do these things right. It's called progressive enhancement. [0] [1] Which means you don't need any fancy stuff to be able to use it or read the content, but if you have support for it, it will add extra convenience-features like search suggestions. Also in certain ways things are starting to improve for example the HTML5 spec has a video-tag [2] that's the only kinda of useful thing Flash is used for these days. Their is SVG and Canvas- tag in the HTML5-spec as well, which means even less reason to use plugins. The Chrome browser uses seperate processes with less priviledges to render the pages and run scripts and plugins. I'm just saying it's not all bad. [0] http://en.wikipedia.org/wiki/Progressive_enhancement [1] http://www.alistapart.com/articles/understandingprogressiveenhancement/ [2] Some may say, but their are no codecs specified, but the same is true for images, etc. and I think images did pretty well [3] http://en.wikipedia.org/wiki/Google_Chrome#Security From simon at darkmere.gen.nz Sat Aug 15 21:14:01 2009 From: simon at darkmere.gen.nz (NANOG Mail List Committee) Date: Sun, 16 Aug 2009 14:14:01 +1200 Subject: ADMIN: List FAQ/Monthly Post. Message-ID: This 100-line document contains 62% of what you need to know to avoid annoying 10,000 people in your email to the NANOG list. It also contains pointers to another 23%. Please take 5 minutes to read it before you post [again]. General Information =================== About NANOG: http://www.nanog.org/about/ NANOG News: http://www.nanog.org/ NANOG lists and AUP: http://www.nanog.org/mailinglist/ NANOG List FAQ: http://www.nanog.org/mailinglist/listfaqs/ To Subscribe or Unsubscribe from the list: http://mailman.nanog.org/mailman/listinfo/nanog To contact the list's admins: admins at nanog.org Posting Policy ============== The NANOG list has over 10,000 subscribers so it is very easy for a thread to have scores of posts while being off-topic and only of interest to only a small proportion of subscribers. Please consider before each post if your email will be of interest to the majority of members or might alternatively be emailed directly the people of interest or posted to another forum. Please read the FAQ and AUP policy before posting for more details. Especially the following are discouraged: * Is a certain site down? Other Outages not affecting half the Internet. Please use http://downforeveryoneorjustme.com/ or a similar site. Please post to the Outages mailing list: http://wiki.outages.org * Spam Please use SPAM-L - http://spam-l.com/mailman/listinfo * Contacting People * http://puck.nether.net/netops/ * http://www.peeringdb.com * Please try other methods of contacting sites before you post to NANOG. Saying something like "I tried calling 213-555-3333 but no answer" shows you _have_ tried alternative methods first. * Political Issues * Topics such as ICANN policy, Government Policy or Law changes that do not have short term Operational impact should be avoided. * Operation topics with more specific lists * DNS - http://lists.oarci.net/mailman/listinfo/dns-operations * Email - http://www.mailop.org/ * NANOG Mailing list policy Please use the nanog-futures list or contact admins at nanog.org Please also avoid ================= * Sending posts to the list relevant to only one or two people on this list, such as tests or traceroutes in response to another post for comparison to those originally posted. * Jokes, Puns, amusing observations, spelling corrections. Other NANOG related lists ========================= * NANOG-futures - for discussion of the evolution of NANOG, including organizational structure, policies and procedures, and agendas for NANOG meetings. Such topics aren't appropriate for the main NANOG mailing list. http://mailman.nanog.org/mailman/listinfo/nanog-futures * nanog-attendee - For discussion of venue-specific issues relevant to attendees of the current NANOG physical meeting. http://mailman.nanog.org/mailman/listinfo/nanog-attendee * nanog-announce - For announcements of NANOG meetings an other Important NANOG related announcements. Low traffic and all posts are also sent to main list. http://mailman.nanog.org/mailman/listinfo/nanog-announce Other Mailing Lists =================== Information about related lists: http://www.nanog.org/mailinglist/listfaqs/otherlists.php From nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org Sun Aug 16 01:03:33 2009 From: nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org (Mark Smith) Date: Sun, 16 Aug 2009 15:33:33 +0930 Subject: IPv6 Addressing Help In-Reply-To: References: <4A857CB3.10600@uplogon.com> <4A85800A.6020703@spaghetti.zurich.ibm.com> <4A858368.1030200@uplogon.com> <4A85878A.2000208@uk.clara.net> Message-ID: <20090816153333.2d5ac5e2.nanog@85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org> On Fri, 14 Aug 2009 12:40:34 -0400 (EDT) Jon Lewis wrote: > On Fri, 14 Aug 2009, David Freedman wrote: > > > Will keep it simple, this is what I (and I suspect many others) do > > > > /128 - Loopback (what else?) > > /126 - Router p2p > > /112 - Router LAN shared segments (p2mp) > > Why even go that big on LAN segments? Why not? Do you enjoy dealing with variable length subnets (calculating start and finish addresses and subnet masks, working out if an address falls within a subnet or not, running two subnets in parallel and hair pinning traffic via a router, just to increase the number of devices etc. etc.)? There's better things we could be doing with our time, but with IPv4 we can't, because it's address space isn't big enough ... Isn't it great that we never have to worry about IPv4 style addressing issues (e.g. sizing the subnet, manually configuring the addresses, or having an "address configuration server" attached to the segment to manage addresses) when dealing with Ethernet in the last 27 years or so? Why is that, and what can we learn from that? > i.e. If you have a LAN/VLAN where > you have say 20 devices (routers, switches, etc.) and know you'll never > have more than say 50-100 devices, why not go as far as using a /120? > > ---------------------------------------------------------------------- > Jon Lewis | I route > Senior Network Engineer | therefore you are > Atlantic Net | > _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ > From randy at psg.com Sun Aug 16 01:09:00 2009 From: randy at psg.com (Randy Bush) Date: Sun, 16 Aug 2009 15:09:00 +0900 Subject: IPv6 Addressing Help In-Reply-To: <20090816153333.2d5ac5e2.nanog@85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org> References: <4A857CB3.10600@uplogon.com> <4A85800A.6020703@spaghetti.zurich.ibm.com> <4A858368.1030200@uplogon.com> <4A85878A.2000208@uk.clara.net> <20090816153333.2d5ac5e2.nanog@85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org> Message-ID: > Isn't it great that we never have to worry about IPv4 style addressing > issues (e.g. sizing the subnet, manually configuring the addresses, or > having an "address configuration server" attached to the segment to > manage addresses) when dealing with Ethernet in the last 27 years or > so? Why is that, and what can we learn from that? among many other things, that autoconf sucks in significant instances randy From nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org Sun Aug 16 01:54:43 2009 From: nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org (Mark Smith) Date: Sun, 16 Aug 2009 16:24:43 +0930 Subject: IPv6 Addressing Help In-Reply-To: References: <4A857CB3.10600@uplogon.com> <4A85800A.6020703@spaghetti.zurich.ibm.com> <4A858368.1030200@uplogon.com> <4A85878A.2000208@uk.clara.net> <20090816153333.2d5ac5e2.nanog@85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org> Message-ID: <20090816162443.8d97197e.nanog@85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org> On Sun, 16 Aug 2009 15:09:00 +0900 Randy Bush wrote: > > Isn't it great that we never have to worry about IPv4 style addressing > > issues (e.g. sizing the subnet, manually configuring the addresses, or > > having an "address configuration server" attached to the segment to > > manage addresses) when dealing with Ethernet in the last 27 years or > > so? Why is that, and what can we learn from that? > > among many other things, that autoconf sucks in significant instances > Presumably you're talking about duplicate addresses? If that was enough of a problem then I think there'd be an IEEE protocol to perform duplicate address detection and possibly recovery. From Skeeve at eintellego.net Sun Aug 16 02:56:59 2009 From: Skeeve at eintellego.net (Skeeve Stevens) Date: Sun, 16 Aug 2009 17:56:59 +1000 Subject: IPv6 Addressing Help In-Reply-To: <4A85800A.6020703@spaghetti.zurich.ibm.com> References: <4A857CB3.10600@uplogon.com> <4A85800A.6020703@spaghetti.zurich.ibm.com> Message-ID: <292AF25E62B8894C921B893B53A19D97395767FA08@BUSINESSEX.business.ad> Really? You just say 'Gimme v6 please' to APNIC and they do. -- Skeeve Stevens, CEO/Technical Director eintellego Pty Ltd - The Networking Specialists skeeve at eintellego.net / www.eintellego.net Phone: 1300 753 383, Fax: (+612) 8572 9954 Cell +61 (0)414 753 383 / skype://skeeve www.linkedin.com/in/skeeve ; facebook.com/eintellego -- NOC, NOC, who's there? > -----Original Message----- > From: Jeroen Massar [mailto:jeroen at unfix.org] > Sent: Saturday, 15 August 2009 1:18 AM > To: Chris Gotstein > Cc: Nanog > Subject: Re: IPv6 Addressing Help > > Chris Gotstein wrote: > > We are a small ISP that is in the process of setting up IPv6 on our > > network. We already have the ARIN allocation and i have a couple > > routers and servers running dual stack. Wondering if someone out > > there would be willing to give me a few pointers on setting up my > > addressing scheme? > > Strange, I recall that you had to submit one when requesting address > space from ARIN. Why don't you use that one? > > > I've been mulling over how to do it, and i think i'm making it more > > complicated than it needs to be. You can hit me offlist if you wish > > to help. Thanks. > > It all depends on your network and how you want to set it up, but for > the sake of internal aggregation: > * Determine the expected amount of IPv6 customers at a certain > location for the next X years, making X > 2 (though 10 is probably a > better idea, just in case, if don't want to do it again ;) ) > * Take that number round it up to a power of 2 > * Every customer gets a /48, you know the number, which is a power of > 2, thus root it, and you know how many bits you need at that site > > eg expect 200 customers, round to power of 2 thus 256, which is 2^8, > thus you will need a /48 + 8 bits = /40 at that location. > > You now know how much address space you need at that location for the > next X years. > > Repeat that for all your locations / routing areas, basically the PoPs > or termination points of your customers; or if you are really big do > that per city/town/suburb. Keep enough space (the rounding helps there > quite a bit, especially with numbers like 50k customers ;) > > Now you have an overview of what you expect to be allocating at each > and every site. To add a little growth/future proof and to make live > easy, you could either opt at this stage to round everything off to > 'nice' > numbers, eg only use /40's or /36's per PoP. Thus making everything the > same, or doing things like grouping smaller PoPs together. > > Then when you have done that, take those blocks, and try to squeeze > them a bit together. You should now have arrived to the address plan > that you originally submitted to ARIN. > > Fill those blocks into a nice database, roll a PHP/shell/perl/whatever > script to spit out your router configuration and presto: you are done. > > Enjoy the weekend ;) > > Greets, > Jeroen > From andy at nosignal.org Sun Aug 16 04:06:36 2009 From: andy at nosignal.org (Andy Davidson) Date: Sun, 16 Aug 2009 10:06:36 +0100 Subject: East Africa Fibre Connectivity- Heads up In-Reply-To: References: Message-ID: <6A1B9139-6D6B-48B6-A866-4A25146FB88D@nosignal.org> On 5 Aug 2009, at 11:13, Raymond Macharia wrote: > Hello all,in the last two weeks or so providers in East Africa, > particularly > in Kenya where I am, have been moving from Satellite to Fibre for the > internet Back bone connectivity. From where I am I have seen an > upsurge of > about 100Mbps in the last two days from my users. Hi, Raymond -- We see similar changes to traffic in the internet exchange world when someone changes their connection from 1GE to 10GE. Before they turn up additional sessions, they often peer more traffic, which I attribute to sliding window doing its thing, and eventually user behaviour altering. It's encouraging that your customers' internet performance experiences are improving - do share your upgrade stories with other providers in your region ! Best wishes, Andy From munfai at bubblenut.org Mon Aug 17 03:25:57 2009 From: munfai at bubblenut.org (Mun Fai Lee) Date: Mon, 17 Aug 2009 16:25:57 +0800 (SGT) Subject: APAC to US crawling In-Reply-To: <32274870.561250497420903.JavaMail.root@soursop.bubblenut.org> Message-ID: <19387808.581250497557523.JavaMail.root@soursop.bubblenut.org> Is anyone seeing a huge latency jump from Asia Pac to US again? Sample traceroute: 4 2 ms 1 ms 1 ms 210.13.64.14 5 2 ms 1 ms 4 ms 210.13.64.13 6 2 ms 2 ms 2 ms 218.105.0.69 7 41 ms 35 ms 35 ms 218.105.6.102 8 36 ms 36 ms 36 ms 218.105.5.82 9 36 ms 36 ms 37 ms 210.52.132.230 10 38 ms 39 ms 38 ms 210.53.126.2 11 38 ms 38 ms 39 ms 217.6.49.181 12 * 296 ms 295 ms lax-sa1-i.LAX.US.NET.DTAG.DE [62.154.5.170] 13 1033 ms 1029 ms 1028 ms 192.205.33.101 14 1087 ms 1090 ms 1094 ms cr2.la2ca.ip.att.net [12.122.129.98] 15 1086 ms 1084 ms 1085 ms cr1.slkut.ip.att.net [12.122.30.29] The above was taken from a user in China tracing to New York about 30 mins ago From ethern at ascc.net Mon Aug 17 03:55:30 2009 From: ethern at ascc.net (Ethern M., Lin) Date: Mon, 17 Aug 2009 16:55:30 +0800 Subject: APAC to US crawling In-Reply-To: <19387808.581250497557523.JavaMail.root@soursop.bubblenut.org> References: <32274870.561250497420903.JavaMail.root@soursop.bubblenut.org> <19387808.581250497557523.JavaMail.root@soursop.bubblenut.org> Message-ID: <8582c31a0908170155o1daf6bl628d787d7c197cf@mail.gmail.com> It seems that the FNAL system outage at 14:15 GMT+8. Not sure it is related or not. cheers, Ethern On Mon, Aug 17, 2009 at 4:25 PM, Mun Fai Lee wrote: > Is anyone seeing a huge latency jump from Asia Pac to US again? > > Sample traceroute: > > 4 2 ms 1 ms 1 ms 210.13.64.14 > 5 2 ms 1 ms 4 ms 210.13.64.13 > 6 2 ms 2 ms 2 ms 218.105.0.69 > 7 41 ms 35 ms 35 ms 218.105.6.102 > 8 36 ms 36 ms 36 ms 218.105.5.82 > 9 36 ms 36 ms 37 ms 210.52.132.230 > 10 38 ms 39 ms 38 ms 210.53.126.2 > 11 38 ms 38 ms 39 ms 217.6.49.181 > 12 * 296 ms 295 ms lax-sa1-i.LAX.US.NET.DTAG.DE [62.154.5.170] > 13 1033 ms 1029 ms 1028 ms 192.205.33.101 > 14 1087 ms 1090 ms 1094 ms cr2.la2ca.ip.att.net [12.122.129.98] > 15 1086 ms 1084 ms 1085 ms cr1.slkut.ip.att.net [12.122.30.29] > > > The above was taken from a user in China tracing to New York about 30 mins ago > > From munfai at bubblenut.org Mon Aug 17 04:08:45 2009 From: munfai at bubblenut.org (Mun Fai Lee) Date: Mon, 17 Aug 2009 17:08:45 +0800 (SGT) Subject: APAC to US crawling In-Reply-To: <8582c31a0908170155o1daf6bl628d787d7c197cf@mail.gmail.com> Message-ID: <17532344.641250500124276.JavaMail.root@soursop.bubblenut.org> Do you have any more details of the outage? Another cut in the region? ----- Original Message ----- From: "Ethern M., Lin" To: "Mun Fai Lee" Cc: nanog at nanog.org Sent: Monday, August 17, 2009 4:55:30 PM GMT +08:00 Beijing / Chongqing / Hong Kong / Urumqi Subject: Re: APAC to US crawling It seems that the FNAL system outage at 14:15 GMT+8. Not sure it is related or not. cheers, Ethern On Mon, Aug 17, 2009 at 4:25 PM, Mun Fai Lee wrote: > Is anyone seeing a huge latency jump from Asia Pac to US again? > > Sample traceroute: > > 4 2 ms 1 ms 1 ms 210.13.64.14 > 5 2 ms 1 ms 4 ms 210.13.64.13 > 6 2 ms 2 ms 2 ms 218.105.0.69 > 7 41 ms 35 ms 35 ms 218.105.6.102 > 8 36 ms 36 ms 36 ms 218.105.5.82 > 9 36 ms 36 ms 37 ms 210.52.132.230 > 10 38 ms 39 ms 38 ms 210.53.126.2 > 11 38 ms 38 ms 39 ms 217.6.49.181 > 12 * 296 ms 295 ms lax-sa1-i.LAX.US.NET.DTAG.DE [62.154.5.170] > 13 1033 ms 1029 ms 1028 ms 192.205.33.101 > 14 1087 ms 1090 ms 1094 ms cr2.la2ca.ip.att.net [12.122.129.98] > 15 1086 ms 1084 ms 1085 ms cr1.slkut.ip.att.net [12.122.30.29] > > > The above was taken from a user in China tracing to New York about 30 mins ago > > From ethern at ascc.net Mon Aug 17 04:51:46 2009 From: ethern at ascc.net (Ethern M., Lin) Date: Mon, 17 Aug 2009 17:51:46 +0800 Subject: APAC to US crawling In-Reply-To: <17532344.641250500124276.JavaMail.root@soursop.bubblenut.org> References: <8582c31a0908170155o1daf6bl628d787d7c197cf@mail.gmail.com> <17532344.641250500124276.JavaMail.root@soursop.bubblenut.org> Message-ID: <8582c31a0908170251t27f51e75o5ddae695fe7c51e2@mail.gmail.com> As I know, the FNAL system is down and from Taiwan to Hongkong and from Japan to Hongkong. But I don't have further info about this outage now. cheers, Ethern ============================= Ethern Lin Network Division Computing Center, ACADEMIA SINICA Phone: +886-2-2789-9953 Fax : +886-2-2783-6444 ============================= On Mon, Aug 17, 2009 at 5:08 PM, Mun Fai Lee wrote: > Do you have any more details of the outage? Another cut in the region? > > > ----- Original Message ----- > From: "Ethern M., Lin" > To: "Mun Fai Lee" > Cc: nanog at nanog.org > Sent: Monday, August 17, 2009 4:55:30 PM GMT +08:00 Beijing / Chongqing / Hong Kong / Urumqi > Subject: Re: APAC to US crawling > > It seems that the FNAL system outage at 14:15 GMT+8. > Not sure it is related or not. > > cheers, > Ethern > > On Mon, Aug 17, 2009 at 4:25 PM, Mun Fai Lee wrote: >> Is anyone seeing a huge latency jump from Asia Pac to US again? >> >> Sample traceroute: >> >> 4 2 ms 1 ms 1 ms 210.13.64.14 >> 5 2 ms 1 ms 4 ms 210.13.64.13 >> 6 2 ms 2 ms 2 ms 218.105.0.69 >> 7 41 ms 35 ms 35 ms 218.105.6.102 >> 8 36 ms 36 ms 36 ms 218.105.5.82 >> 9 36 ms 36 ms 37 ms 210.52.132.230 >> 10 38 ms 39 ms 38 ms 210.53.126.2 >> 11 38 ms 38 ms 39 ms 217.6.49.181 >> 12 * 296 ms 295 ms lax-sa1-i.LAX.US.NET.DTAG.DE [62.154.5.170] >> 13 1033 ms 1029 ms 1028 ms 192.205.33.101 >> 14 1087 ms 1090 ms 1094 ms cr2.la2ca.ip.att.net [12.122.129.98] >> 15 1086 ms 1084 ms 1085 ms cr1.slkut.ip.att.net [12.122.30.29] >> >> >> The above was taken from a user in China tracing to New York about 30 mins ago >> >> > From repstein at chello.at Mon Aug 17 05:44:30 2009 From: repstein at chello.at (Randy Epstein) Date: Mon, 17 Aug 2009 06:44:30 -0400 Subject: APAC to US crawling In-Reply-To: <19387808.581250497557523.JavaMail.root@soursop.bubblenut.org> References: <32274870.561250497420903.JavaMail.root@soursop.bubblenut.org> <19387808.581250497557523.JavaMail.root@soursop.bubblenut.org> Message-ID: <044201ca1f27$b5054ed0$1f0fec70$@at> >Is anyone seeing a huge latency jump from Asia Pac to US again? >The above was taken from a user in China tracing to New York about 30 mins ago There was another earthquake today in Asia, this one between Japan and Taiwan. Is this possibly related? Randy From Skeeve at eintellego.net Mon Aug 17 06:26:42 2009 From: Skeeve at eintellego.net (Skeeve Stevens) Date: Mon, 17 Aug 2009 21:26:42 +1000 Subject: FW: BoF for APNIC 28 in Beijing - IPv6 Promotion Message-ID: <292AF25E62B8894C921B893B53A19D97395767FA3D@BUSINESSEX.business.ad> FYI for those that might be attending APNIC 28 in Beijing next week. -- Skeeve Stevens, CEO/Technical Director eintellego Pty Ltd - The Networking Specialists skeeve at eintellego.net / www.eintellego.net Phone: 1300 753 383, Fax: (+612) 8572 9954 Cell +61 (0)414 753 383 / skype://skeeve www.linkedin.com/in/skeeve ; facebook.com/eintellego -- NOC, NOC, who's there? From: Skeeve Stevens Sent: Monday, 17 August 2009 9:05 PM To: 'apnic-talk at apnic.net' Cc: ausnog at ausnog.net; nznog Subject: BoF for APNIC 28 in Beijing - IPv6 Promotion Greeting all that will be attending APNIC 28 in Beijing, While we are in China at APNIC 28, and as per the spirit of 1.3 of http://www.apnic.net/__data/assets/pdf_file/0012/3117/sig-guidelines.pdf I am proposing that we hold a BoF for the purpose of seeing if there are enough interested parties to get together to discuss the issue of IPv6 promotion in the APNIC region with the 'maybe' end of it becoming a SIG. I am asking for some leeway in this request as this region is a complex one with a very broad range of cultural differences and language barriers that that don't always translate across the entire membership. For example, the way we might want to accomplish something in Australia could be very different to the way it would be done in say Japan, China or India. IPv6 promotion is something that APNIC has been doing for quite a while now, with some degree of success. But given the timeframes in which we have till things get very painful for many organisations, I do not believe that APNIC has sufficient resources (whether that be man-power, financial, etc) to effectively promote it across all the economic communities that it represents. I would like the hold a BoF to gauge the interest on how members themselves can be more involved in their region, what they would/could be prepared to do, and to discuss the challenges that we are having, developing new ideas and focusing on specific ways to promote IPv6 - without all the technical mumbo-jumbo. I am suggesting a much less technical perspective needs to take shape. I realise that a very large percentage of us are technical people, but there are many business minded people who I am sure have many great ideas... and if there isn't that many... let's get them involved somehow. Many members in the APNIC region have their own NIR (JPNIC, CNNIC, etc) to assist in these kinds of matters (I assume), but in Australia and NZ specifically speaking for my area of focus, we deal directly with APNIC... so I don't know how appropriate having people who deal with their NIR directly on these matters, but the more the merrier. There is no suggestion in this proposal that the many people who talk at conferences about IPv6, or APNIC themselves have not done a good job... My suggestion is that we can do more, and time is of the essence. I am inspired to bring this about by my own passion regarding IPv6 adoption, and I am willing to put (and already have put) the resources and passion of me and my company behind efforts to help finding new ways to foster IPv6 adoption in this region. There seems to be an issue of room availability at APNIC28, but if I have to put up some $$ myself and we go take over the local McDonalds, I am willing to do so to try and help make this BoF happen. I think timing is important... and I think now is the time we need to start discussing these things. Big machines like APNIC move rather slowly, and I am willing to try to do what it takes to try and push things along. So, if you're going to be in Beijing, and you really are passionate about IPv6 adoption, please come and see me - the big bald aussie-guy - and let's get something happening. I will be looking at the schedule to see where we can fit a couple of hours to chat. Also, you might be approached by myself or others who are also interested in making this happen. All I can ask is to please be involved, and DO - rather than talk about it. -- Skeeve Stevens, CEO/Technical Director eintellego Pty Ltd - The Networking Specialists skeeve at eintellego.net / www.eintellego.net Phone: 1300 753 383, Fax: (+612) 8572 9954 Cell +61 (0)414 753 383 / skype://skeeve www.linkedin.com/in/skeeve ; facebook.com/eintellego -- NOC, NOC, who's there? Disclaimer: Limits of Liability and Disclaimer: This message is for the named person's use only. It may contain sensitive and private proprietary or legally privileged information. You must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient. eintellego Pty Ltd and each legal entity in the Tefilah Pty Ltd group of companies reserve the right to monitor all e-mail communications through its networks. Any views expressed in this message are those of the individual sender, except where the message states otherwise and the sender is authorised to state them to be the views of any such entity. Any reference to costs, fee quotations, contractual transactions and variations to contract terms is subject to separate confirmation in writing signed by an authorised representative of eintellego. Whilst all efforts are made to safeguard inbound and outbound e-mails, we cannot guarantee that attachments are virus-free or compatible with your systems and do not accept any liability in respect of viruses or computer problems experienced. From jay at prolexic.com Mon Aug 17 07:23:01 2009 From: jay at prolexic.com (Jay Coley) Date: Mon, 17 Aug 2009 13:23:01 +0100 Subject: APAC to US crawling In-Reply-To: <044201ca1f27$b5054ed0$1f0fec70$@at> References: <32274870.561250497420903.JavaMail.root@soursop.bubblenut.org> <19387808.581250497557523.JavaMail.root@soursop.bubblenut.org> <044201ca1f27$b5054ed0$1f0fec70$@at> Message-ID: <4A894BA5.3070308@jcoley.net> Randy Epstein wrote: >> Is anyone seeing a huge latency jump from Asia Pac to US again? > > > >> The above was taken from a user in China tracing to New York about 30 mins ago > > There was another earthquake today in Asia, this one between Japan and Taiwan. Is this possibly related? > > Randy Just got word that TGN-1 near Taiwan has been cut off the coast of Taiwan. --J From jbates at brightok.net Mon Aug 17 09:15:23 2009 From: jbates at brightok.net (Jack Bates) Date: Mon, 17 Aug 2009 09:15:23 -0500 Subject: IPv6 Addressing Help In-Reply-To: References: <4A857CB3.10600@uplogon.com> <4A85800A.6020703@spaghetti.zurich.ibm.com> <4A858368.1030200@uplogon.com> <4A85878A.2000208@uk.clara.net> Message-ID: <4A8965FB.2000603@brightok.net> Jon Lewis wrote: > On Fri, 14 Aug 2009, David Freedman wrote: > >> Will keep it simple, this is what I (and I suspect many others) do >> >> /128 - Loopback (what else?) >> /126 - Router p2p >> /112 - Router LAN shared segments (p2mp) > > Why even go that big on LAN segments? i.e. If you have a LAN/VLAN where > you have say 20 devices (routers, switches, etc.) and know you'll never > have more than say 50-100 devices, why not go as far as using a /120? As long as it makes the nibble, I don't think it really matters much. I wouldn't assign anything to a router p2p unless it's on the nibble, just for administrative ease. That being said, presentation in routers is much cleaner using /64's, with perhaps 1 /64 broken into loopbacks, which will still stay relatively short in display. It may be wasteful, but minimal in waste compared to the /48's we hand out to customers. My first /48 was assigned for internal use, and as an ISP, I doubt I'll ever use it all even with an extreme amount of waste. My favorite shortcut was 2607:f780::1 which is assigned to the reachability server, as easy as I could make it for customers to ping by number when troubleshooting with the helpdesk. -Jack From sergevautour at yahoo.ca Mon Aug 17 09:36:24 2009 From: sergevautour at yahoo.ca (Serge Vautour) Date: Mon, 17 Aug 2009 07:36:24 -0700 (PDT) Subject: atac.fr DNS problem Message-ID: <742836.93094.qm@web53606.mail.re2.yahoo.com> Hello, Our AS855 can't seem to contact the DNS servers for atac.fr domains (dns.atac.fr [62.160.25.65] & dns2.atac.fr [195.68.125.36]). From our network, dig dies for both IPs: ------------------------------------------------------------------------------ ;; Received 401 bytes from 192.33.4.12#53(c.root-servers.net) in 17 ms atac.fr. 172800 IN NS dns2.atac.fr. atac.fr. 172800 IN NS dns.atac.fr. ;; Received 94 bytes from 194.57.253.1#53(E.NIC.fr) in 316 ms dig: couldn't get address for 'dns2.atac.fr': not found ------------------------------------------------------------------------------ If I use dig from public web sites it works: ------------------------------------------------------------------------------ ;; Received 401 bytes from 192.203.230.10#53(e.root-servers.net) in 94 ms atac.fr. 172800 IN NS dns2.atac.fr. atac.fr. 172800 IN NS dns.atac.fr. ;; Received 94 bytes from 194.57.253.1#53(E.NIC.fr) in 313 ms atac.fr. 300 IN A 194.145.56.21 atac.fr. 300 IN NS dns.atac.fr. atac.fr. 300 IN NS dns2.atac.fr. ;; Received 110 bytes from 195.68.125.36#53(dns2.atac.fr) in 113 ms ------------------------------------------------------------------------------ A traceroutes die as well: traceroute 195.68.125.36 .... 9 ae-2-79.edge1.NewYork1.Level3.net (4.68.16.78) [AS 3356] 25.278 ms ae-1-69.edge1.NewYork1.Level3.net (4.68.16.14) [AS 3356] 25.284 ms ae-4-99.edge1.NewYork1.Level3.net (4.68.16.206) [AS 3356] 27.476 ms 10 COLT-TELECO.edge1.NewYork1.Level3.net (4.78.132.22) [AS 3356] 25.871 ms 26.014 ms 25.589 ms 11 * * * 12 90.168-14-84.ripe.coltfrance.com (84.14.168.90) [AS 8220] 114.992 ms 114.912 ms 115.243 ms 13 * * * traceroute 62.160.25.65 ... 9 ae-2-79.edge2.NewYork1.Level3.net (4.68.16.80) [AS 3356] 25.573 ms 25.429 ms ae-3-89.edge2.NewYork1.Level3.net (4.68.16.144) [AS 3356] 25.591 ms 10 francetelecom-level3-te.NewYork1.Level3.net (4.68.111.86) [AS 3356] 39.905 ms francetelecom-level3-te.NewYork1.Level3.net (4.68.111.82) [AS 3356] 33.916 ms 33.762 ms 11 * * * It appears as though packets aren't making their way back. Is there anyone from francetelecom or AS8220 that could assist? Thanks, Serge __________________________________________________________________ The new Internet Explorer? 8 - Faster, safer, easier. Optimized for Yahoo! Get it Now for Free! at http://downloads.yahoo.com/ca/internetexplorer/ From fweimer at bfk.de Mon Aug 17 09:43:46 2009 From: fweimer at bfk.de (Florian Weimer) Date: Mon, 17 Aug 2009 14:43:46 +0000 Subject: atac.fr DNS problem In-Reply-To: <742836.93094.qm@web53606.mail.re2.yahoo.com> (Serge Vautour's message of "Mon\, 17 Aug 2009 07\:36\:24 -0700 \(PDT\)") References: <742836.93094.qm@web53606.mail.re2.yahoo.com> Message-ID: <82ljli7b6l.fsf@mid.bfk.de> * Serge Vautour: > Hello, > > Our AS855 can't seem to contact the DNS servers for atac.fr domains (dns.atac.fr [62.160.25.65] & dns2.atac.fr [195.68.125.36]). From our network, dig dies for both IPs: Please post full trace output, e.g. the result of "dig www.atac.fr +trace +all +norecurse" if you still can reproduce the issue. (Perhaps this topic is more suitable for the dns-operations mailing list, BTW.) -- Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra?e 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From ethern at ascc.net Mon Aug 17 10:44:06 2009 From: ethern at ascc.net (Ethern M., Lin) Date: Mon, 17 Aug 2009 23:44:06 +0800 Subject: APAC to US crawling In-Reply-To: <4A894BA5.3070308@jcoley.net> References: <32274870.561250497420903.JavaMail.root@soursop.bubblenut.org> <19387808.581250497557523.JavaMail.root@soursop.bubblenut.org> <044201ca1f27$b5054ed0$1f0fec70$@at> <4A894BA5.3070308@jcoley.net> Message-ID: <8582c31a0908170844h1b0f6552gad384d931dbc630c@mail.gmail.com> All I know the un-damaged cable systems are: TPE and C2C. The outage cause f FNAL is debris flow as the same as 8/7. Please have more info supplmented if you have. cheers, Ethern On Mon, Aug 17, 2009 at 8:23 PM, Jay Coley wrote: > Randy Epstein wrote: >>> Is anyone seeing a huge latency jump from Asia Pac to US again? >> >> >> >>> The above was taken from a user in China tracing to New York about 30 mins ago >> >> There was another earthquake today in Asia, this one between Japan and Taiwan. ?Is this possibly related? >> >> Randy > > Just got word that TGN-1 near Taiwan has been cut off the coast of Taiwan. > > --J > > From Rod.Beck at hiberniaatlantic.com Mon Aug 17 11:14:22 2009 From: Rod.Beck at hiberniaatlantic.com (Rod Beck) Date: Mon, 17 Aug 2009 17:14:22 +0100 Subject: TransAtlantic 40 Gig Waves References: <1E8B940C5E21014AB8BE70B975D40EDB0162857C@bert.HiberniaAtlantic.local> <4A849D32.3040604@internode.com.au> <1E8B940C5E21014AB8BE70B975D40EDB0162859C@bert.HiberniaAtlantic.local> <20090814131745.GB51443@gerbil.cluepon.net> <1E8B940C5E21014AB8BE70B975D40EDB016285A9@bert.HiberniaAtlantic.local> Message-ID: <1E8B940C5E21014AB8BE70B975D40EDB01628626@bert.HiberniaAtlantic.local> Rod, do you know if the 40G waves increased the spectrum efficiency of your fiber? On land systems they pretty much break even, i.e. you can have a 100GHz 40G channels or 4x25GHz 10G channels but at the end of the day you still get the same amount of signal out of the fiber. I don't know whats being done on undersea cables though. Eventually this will get better too, and 40G will become the "native" wavelength standard with 10G being muxed onto them, similar to what we saw with the transition from 2.5G->10G 10 years ago. -- Richard A Steenbergen http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) "Rod. This is direct from engineering: The number of wavelengths or channels Hibernia have on their DWDM infrastructure remains the same, however now each wave can be at a rate of 40Gb/s instead of only 10Gb/s. In the extreme case, we get 4 times the capacity, but in reality, because of the existing installed 10G's, we would not necessarily swap out all existing cards. We could say the overall increase in capacity is "up-to" 4 times. The enabling technology is based on advanced encoding techniques allowing a greater rate of symbol transfer." From sergevautour at yahoo.ca Mon Aug 17 12:38:38 2009 From: sergevautour at yahoo.ca (Serge Vautour) Date: Mon, 17 Aug 2009 10:38:38 -0700 (PDT) Subject: atac.fr DNS problem In-Reply-To: <82ljli7b6l.fsf@mid.bfk.de> References: <742836.93094.qm@web53606.mail.re2.yahoo.com> <82ljli7b6l.fsf@mid.bfk.de> Message-ID: <268183.75391.qm@web53607.mail.re2.yahoo.com> Hello, Here are the full outputs. I will also try the DNS mailing list. Thanks for any help. Serge ------------------------------------------------------------------------------------------------ dig www.atac.fr +trace +all +norecurse ; <<>> DiG 9.3.2 <<>> www.atac.fr +trace +all +norecurse ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 48292 ;; flags: qr ra; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 9 ;; QUESTION SECTION: ;. IN NS ;; ANSWER SECTION: . 42476 IN NS I.ROOT-SERVERS.NET. . 42476 IN NS E.ROOT-SERVERS.NET. . 42476 IN NS F.ROOT-SERVERS.NET. . 42476 IN NS A.ROOT-SERVERS.NET. . 42476 IN NS C.ROOT-SERVERS.NET. . 42476 IN NS M.ROOT-SERVERS.NET. . 42476 IN NS G.ROOT-SERVERS.NET. . 42476 IN NS K.ROOT-SERVERS.NET. . 42476 IN NS J.ROOT-SERVERS.NET. . 42476 IN NS D.ROOT-SERVERS.NET. . 42476 IN NS B.ROOT-SERVERS.NET. . 42476 IN NS L.ROOT-SERVERS.NET. . 42476 IN NS H.ROOT-SERVERS.NET. ;; ADDITIONAL SECTION: C.ROOT-SERVERS.NET. 591558 IN A 192.33.4.12 L.ROOT-SERVERS.NET. 591185 IN A 199.7.83.42 H.ROOT-SERVERS.NET. 590936 IN A 128.63.2.53 B.ROOT-SERVERS.NET. 591097 IN A 192.228.79.201 J.ROOT-SERVERS.NET. 128876 IN A 192.58.128.30 J.ROOT-SERVERS.NET. 128876 IN AAAA 2001:503:c27::2:30 F.ROOT-SERVERS.NET. 158903 IN A 192.5.5.241 M.ROOT-SERVERS.NET. 591132 IN A 202.12.27.33 A.ROOT-SERVERS.NET. 590997 IN A 198.41.0.4 ;; Query time: 1 msec ;; SERVER: 142.134.124.5#53(142.134.124.5) ;; WHEN: Mon Aug 17 14:31:40 2009 ;; MSG SIZE rcvd: 384 ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 61829 ;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 8, ADDITIONAL: 12 ;; QUESTION SECTION: ;www.atac.fr. IN A ;; AUTHORITY SECTION: fr. 172800 IN NS C.NIC.fr. fr. 172800 IN NS D.EXT.NIC.fr. fr. 172800 IN NS E.EXT.NIC.fr. fr. 172800 IN NS E.NIC.fr. fr. 172800 IN NS F.EXT.NIC.fr. fr. 172800 IN NS G.EXT.NIC.fr. fr. 172800 IN NS A.NIC.fr. fr. 172800 IN NS B.EXT.NIC.fr. ;; ADDITIONAL SECTION: A.NIC.fr. 172800 IN A 192.93.0.129 A.NIC.fr. 172800 IN AAAA 2001:660:3005:3::1:1 B.EXT.NIC.fr. 172800 IN A 192.228.90.21 C.NIC.fr. 172800 IN A 192.134.0.129 C.NIC.fr. 172800 IN AAAA 2001:660:3006:4::1:1 D.EXT.NIC.fr. 172800 IN A 204.152.184.85 D.EXT.NIC.fr. 172800 IN AAAA 2001:4f8:0:2::8 E.EXT.NIC.fr. 172800 IN A 193.176.144.6 E.NIC.fr. 172800 IN A 194.57.253.1 F.EXT.NIC.fr. 172800 IN A 194.146.106.46 G.EXT.NIC.fr. 172800 IN A 204.61.216.39 G.EXT.NIC.fr. 172800 IN AAAA 2001:500:14:6039:ad::1 ;; Query time: 132 msec ;; SERVER: 192.36.148.17#53(I.ROOT-SERVERS.NET) ;; WHEN: Mon Aug 17 14:31:40 2009 ;; MSG SIZE rcvd: 405 ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 42308 ;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 2 ;; QUESTION SECTION: ;www.atac.fr. IN A ;; AUTHORITY SECTION: atac.fr. 172800 IN NS dns2.atac.fr. atac.fr. 172800 IN NS dns.atac.fr. ;; ADDITIONAL SECTION: dns.atac.fr. 172800 IN A 62.160.25.65 dns2.atac.fr. 172800 IN A 195.68.125.36 ;; Query time: 108 msec ;; SERVER: 192.134.0.129#53(C.NIC.fr) ;; WHEN: Mon Aug 17 14:31:41 2009 ;; MSG SIZE rcvd: 98 dig: couldn't get address for 'dns2.atac.fr': not found ------------------------------------------------------------------------------------------------ traceroute 195.68.125.36 traceroute to 195.68.125.36 (195.68.125.36), 30 hops max, 40 byte packets 1 x.x.x.x (x.x.x.x) 0.211 ms 0.201 ms 0.199 ms 2 x.x.x.x (x.x.x.x) 1.103 ms 1.117 ms 0.872 ms 3 xe-3-0-0.bx01.asbn.va.aliant.net (207.231.227.6) 21.330 ms 21.179 ms 21.186 ms 4 xe-9-2-0.edge2.Washington4.Level3.net (4.53.114.13) 21.203 ms 21.192 ms 21.267 ms 5 vlan89.csw3.Washington1.Level3.net (4.68.17.190) 32.834 ms vlan79.csw2.Washington1.Level3.net (4.68.17.126) 34.681 ms 30.700 ms 6 ae-64-64.ebr4.Washington1.Level3.net (4.69.134.177) 35.436 ms 32.659 ms 25.709 ms 7 ae-3-3.ebr1.NewYork1.Level3.net (4.69.132.94) 26.966 ms 26.866 ms 26.734 ms 8 ae-81-81.csw3.NewYork1.Level3.net (4.69.134.74) 27.338 ms 27.391 ms ae-71-71.csw2.NewYork1.Level3.net (4.69.134.70) 34.384 ms 9 ae-1-69.edge1.NewYork1.Level3.net (4.68.16.14) 27.319 ms ae-3-89.edge1.NewYork1.Level3.net (4.68.16.142) 27.641 ms ae-2-79.edge1.NewYork1.Level3.net (4.68.16.78) 27.816 ms 10 COLT-TELECO.edge1.NewYork1.Level3.net (4.78.132.22) 88.956 ms 89.076 ms 89.154 ms 11 212.74.85.1 (212.74.85.1) 104.463 ms 104.253 ms 104.851 ms 12 90.168-14-84.ripe.coltfrance.com (84.14.168.90) 106.559 ms 107.168 ms 106.853 ms 13 * * * ---No further responses traceroute 62.160.25.65 traceroute to 62.160.25.65 (62.160.25.65), 30 hops max, 40 byte packets 1 x.x.x.x. (x.x.x.x) 0.213 ms 0.202 ms 0.198 ms 2 x.x.x.x (x.x.x.x) 1.601 ms 1.439 ms 0.743 ms 3 xe-3-0-0.bx01.asbn.va.aliant.net (207.231.227.6) 21.251 ms 21.258 ms 21.173 ms 4 xe-9-2-0.edge2.Washington4.Level3.net (4.53.114.13) 21.251 ms 21.417 ms 21.375 ms 5 vlan89.csw3.Washington1.Level3.net (4.68.17.190) 22.518 ms vlan69.csw1.Washington1.Level3.net (4.68.17.62) 24.455 ms vlan89.csw3.Washington1.Level3.net (4.68.17.190) 22.144 ms 6 ae-64-64.ebr4.Washington1.Level3.net (4.69.134.177) 30.684 ms ae-74-74.ebr4.Washington1.Level3.net (4.69.134.181) 29.177 ms 27.076 ms 7 ae-3-3.ebr1.NewYork1.Level3.net (4.69.132.94) 26.891 ms 26.730 ms 26.770 ms 8 ae-61-61.csw1.NewYork1.Level3.net (4.69.134.66) 35.472 ms ae-91-91.csw4.NewYork1.Level3.net (4.69.134.78) 38.017 ms ae-71-71.csw2.NewYork1.Level3.net (4.69.134.70) 38.655 ms 9 ae-4-99.edge2.NewYork1.Level3.net (4.68.16.208) 27.428 ms 27.855 ms ae-1-69.edge2.NewYork1.Level3.net (4.68.16.16) 27.529 ms 10 francetelecom-level3-te.NewYork1.Level3.net (4.68.111.86) 28.286 ms francetelecom-level3-te.NewYork1.Level3.net (4.68.111.82) 27.442 ms 27.764 ms 11 * * * 12 * * * ---No further responses ----- Original Message ---- From: Florian Weimer To: Serge Vautour Cc: nanog at nanog.org Sent: Monday, August 17, 2009 11:43:46 AM Subject: Re: atac.fr DNS problem * Serge Vautour: > Hello, > > Our AS855 can't seem to contact the DNS servers for atac.fr domains (dns.atac.fr [62.160.25.65] & dns2.atac.fr [195.68.125.36]). From our network, dig dies for both IPs: Please post full trace output, e.g. the result of "dig www.atac.fr +trace +all +norecurse" if you still can reproduce the issue. (Perhaps this topic is more suitable for the dns-operations mailing list, BTW.) -- Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra?e 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 __________________________________________________________________ Be smarter than spam. See how smart SpamGuard is at giving junk email the boot with the All-new Yahoo! Mail. Click on Options in Mail and switch to New Mail today or register for free at http://mail.yahoo.ca From bburke at merit.edu Mon Aug 17 14:15:27 2009 From: bburke at merit.edu (Betty Burke) Date: Mon, 17 Aug 2009 15:15:27 -0400 (EDT) Subject: [NANOG-announce] NANOG Updates In-Reply-To: <1052529662.638501250536265270.JavaMail.root@crono> Message-ID: <2140614295.639361250536527591.JavaMail.root@crono> NANOG Community: As the summer months begin to draw to a close, I hope many of you are making your plans to attend NANOG47. ?It is sure to be a great program and great meeting venue for all to network. ?If you have not yet sent your presentation abstract, please submit your materials to http://pc.nanog.org, as the NANOG Program Committee is accepting a few more presentations for consideration. Of additional note, the registration fee will increase on September 14, and the hotel NANOG group rate will expire on September 30, 2009. ?So don't wait, visit nanog.org for all the latest information and links to registration, the hotel, and local points of interest. In addition to the NANOG47 agenda, we encourage you to take part in the the 5th Annual NANOG Election process. ?The election information can be found at http://nanog.org/governance/elections/2009elections/ . ?Please take a moment to review the Eligible Voters list to confirm we have not missed you, and do consider sending a nomination for the Steering, Program, and Mail List committees. ?The process works well when the community, you, become engaged. As reported at NANOG46 and in NANOG-Futures, the NANOG Marketing Working Group is active and has a new list of sponsorship opportunities for consideration, http://nanog.org/meetings/nanog47/sponsorships.php . ?We can not emphasize enough how important NANOG Sponsorship is to our efforts in keeping the cost of registration in check. ?A balance of both allows Merit to provide the level of support the community has come to expect. ?Please do consider recommending a sponsorship opportunity to your marketing representatives and or send a note to marketing at nanog.org with any new ideas you may have. The community will be, and is, very appreciative and in return it is a great opportunity for Sponsors to have access to a diverse group which represent the spirit of NANOG. Lastly, in keeping with Merit's commitment to community transparency, the community will find a set of Financial updates at http://nanog.org/about/financial/ And the most recent NANOG46 survey information can be found at http://nanog.org/about/surveys As always, on behalf of the NANOG support staff, we look forward to seeing many of you in person at our next meeting, NANOG47 in Dearborn, Michigan. ?In addition to contacting me directly, always feel free to send any comments, questions or concerns directly to nanog-support at nanog.org Sincerely, Betty Burke NANOG Community Project Manager and NANOG SC Member _______________________________________________ NANOG-announce mailing list NANOG-announce at nanog.org http://mailman.nanog.org/mailman/listinfo/nanog-announce From a2thah at gmail.com Mon Aug 17 15:11:11 2009 From: a2thah at gmail.com (Adam Hebert) Date: Mon, 17 Aug 2009 16:11:11 -0400 Subject: Anyone else seeing "(invalid or corrupt AS path) 3 bytes E01100" ? Message-ID: <6348c7fd0908171311h2936e6bfifcfd684205befbaf@mail.gmail.com> Multiple providers are seeing this right now. I assume someone is advertising an extremely long AS_PATH again? anyone else seeing this? Adam From Eric.Ballard at suddenlink.com Mon Aug 17 15:27:19 2009 From: Eric.Ballard at suddenlink.com (Ballard, Eric) Date: Mon, 17 Aug 2009 15:27:19 -0500 Subject: Anyone else seeing "(invalid or corrupt AS path) 3 bytes E01100" ? In-Reply-To: <6348c7fd0908171311h2936e6bfifcfd684205befbaf@mail.gmail.com> References: <6348c7fd0908171311h2936e6bfifcfd684205befbaf@mail.gmail.com> Message-ID: We are seeing the same thing, has anyone found the offending AS yet? Thanks ERIC -----Original Message----- From: Adam Hebert [mailto:a2thah at gmail.com] Sent: Monday, August 17, 2009 3:11 PM To: nanog at nanog.org Subject: Anyone else seeing "(invalid or corrupt AS path) 3 bytes E01100" ? Multiple providers are seeing this right now. I assume someone is advertising an extremely long AS_PATH again? anyone else seeing this? Adam From jwbensley at gmail.com Mon Aug 17 15:47:31 2009 From: jwbensley at gmail.com (James Bensley) Date: Mon, 17 Aug 2009 21:47:31 +0100 Subject: Anyone else seeing "(invalid or corrupt AS path) 3 bytes E01100" ? In-Reply-To: References: <6348c7fd0908171311h2936e6bfifcfd684205befbaf@mail.gmail.com> Message-ID: <3c857e1c0908171347n12e23a25ud9f4ef8c96ffe246@mail.gmail.com> Throw your coffee at them! Just my two pence ;) ...James -----BEGIN GEEK CODE BLOCK----- Version: 3.1 GIT/MU/U dpu s: a--> C++>$ U+> L++> B-> P+> E?> W+++>$ N K W++ O M++>$ V- PS+++ PE++ Y+ PGP t 5 X+ R- tv+ b+> DI D+++ G+ e(+++++) h--(++) r++ z++ ------END GEEK CODE BLOCK------ From darren at bolding.org Mon Aug 17 16:19:34 2009 From: darren at bolding.org (Darren Bolding) Date: Mon, 17 Aug 2009 14:19:34 -0700 Subject: Request for a pointer - Linux modifying DSCP on replies? Message-ID: <5a318d410908171419n560075aar6e589145cf223efe@mail.gmail.com> I believe this is operational content, but may well be better asked somewhere else. I would love to have a pointer to another list/website. I am looking to do some policy routing based on DSCP marking, and I have this all working inside the networking equipment. I DSCP mark some packets at ingress and I policy-route others based on ACL's matching those DSCP markings. This should allow me to solve some problems in a rather elegant manner, if I do say so myself. And this works fine for some things- I have verified that Ping's to a host work as expected- the Ping shows up at the destination host DSCP marked, and the ICMP reply leaves with the same DSCP marking. However, when I do this with apache and mysql connections (TCP 80/3306), the incoming packets are marked, but the replies are not. My research into the subject doesn't seem to suggest there is a standard for whether replies to a TCP connection are required to have the same DSCP marking, but it seems to make a lot of sense that they would. I've disabled iptables on the server host to no avail. I've looked around for an apache or Linux kernel setting and found nothing. At this point I'm looking for pointers- to a way to solve this issue, or to a better place to ask. I've started investigating writing iptables rules to match incoming connections that have DSCP marking and explicitly mark response traffic, but that seems, I don't know... wrong. Linux kernel we are using is 2.6.9-67.ELsmp. Any help or pointers would be appreciated! --D -- -- Darren Bolding -- -- darren at bolding.org -- From nanog at data102.com Mon Aug 17 16:37:07 2009 From: nanog at data102.com (randal k) Date: Mon, 17 Aug 2009 15:37:07 -0600 Subject: Anyone else seeing "(invalid or corrupt AS path) 3 bytes E01100" ? In-Reply-To: <6348c7fd0908171311h2936e6bfifcfd684205befbaf@mail.gmail.com> References: <6348c7fd0908171311h2936e6bfifcfd684205befbaf@mail.gmail.com> Message-ID: Yep, we started seeing this right around 12:20pm MST. We saw it from a customer's rapidly-flapping BGP peer. We told them to configure bgp maxas-limit, but apparently CRS1s don't have that command. Anybody have a handy route-map that will deny anything with a as-path longer than say 15-20? ;-) Cheers, Randal On Mon, Aug 17, 2009 at 2:11 PM, Adam Hebert wrote: > Multiple providers are seeing this right now. ?I assume someone is > advertising an extremely long AS_PATH again? > > anyone else seeing this? > > Adam > From stmille at gmail.com Mon Aug 17 16:44:11 2009 From: stmille at gmail.com (Steve Miller) Date: Mon, 17 Aug 2009 14:44:11 -0700 Subject: Request for a pointer - Linux modifying DSCP on replies? In-Reply-To: <5a318d410908171419n560075aar6e589145cf223efe@mail.gmail.com> References: <5a318d410908171419n560075aar6e589145cf223efe@mail.gmail.com> Message-ID: Would not the end station be considered to be outside of the DS domain? It does not necessarily make sense (to me) for reply packets to be marked unless they are appropriate classified and marked on the return path at the point they re-enter the DS domain. I would imagine that iptables and the DSCP target would do what you wanted, yes. I'd consider classifying and marking traffic at whatever switch you would consider to be at the edge of the DS domain (connected to this server.) -Steve 2009/8/17 Darren Bolding : > I believe this is operational content, but may well be better asked > somewhere else. ?I would love to have a pointer to another list/website. > I am looking to do some policy routing based on DSCP marking, and I have > this all working inside the networking equipment. ?I DSCP mark some packets > at ingress and I policy-route others based on ACL's matching those DSCP > markings. ?This should allow me to solve some problems in a rather elegant > manner, if I do say so myself. > > And this works fine for some things- I have verified that Ping's to a host > work as expected- the Ping shows up at the destination host DSCP marked, and > the ICMP reply leaves with the same DSCP marking. > > However, when I do this with apache and mysql connections (TCP 80/3306), the > incoming packets are marked, but the replies are not. > > My research into the subject doesn't seem to suggest there is a standard for > whether replies to a TCP connection are required to have the same DSCP > marking, but it seems to make a lot of sense that they would. > > I've disabled iptables on the server host to no avail. ?I've looked around > for an apache or Linux kernel setting and found nothing. > > At this point I'm looking for pointers- to a way to solve this issue, or to > a better place to ask. > > I've started investigating writing iptables rules to match incoming > connections that have DSCP marking and explicitly mark response traffic, but > that seems, I don't know... wrong. > > Linux kernel we are using is 2.6.9-67.ELsmp. > > Any help or pointers would be appreciated! > > --D > > -- > -- ?Darren Bolding ? ? ? ? ? ? ? ? ?-- > -- ?darren at bolding.org ? ? ? ? ? -- > -- Steve Miller, CCIE #23977 (R&S), RHCE Key fingerprint = 5CE3 A789 4CF5 666F 5CD6 2A8E 3132 77C7 483F 5F9D From nanog-post at rsuc.gweep.net Mon Aug 17 16:48:40 2009 From: nanog-post at rsuc.gweep.net (Joe Provo) Date: Mon, 17 Aug 2009 17:48:40 -0400 Subject: Anyone else seeing "(invalid or corrupt AS path) 3 bytes E01100" ? In-Reply-To: References: <6348c7fd0908171311h2936e6bfifcfd684205befbaf@mail.gmail.com> Message-ID: <20090817214840.GA76062@gweep.net> On Mon, Aug 17, 2009 at 03:37:07PM -0600, randal k wrote: > Yep, we started seeing this right around 12:20pm MST. We saw it from a > customer's rapidly-flapping BGP peer. We told them to configure bgp > maxas-limit, but apparently CRS1s don't have that command. > > Anybody have a handy route-map that will deny anything with a as-path > longer than say 15-20? ;-) Been a while since I had to throw this on cisco, but I since it lacks sane repeat constraint, you have to either choose to iterate over your acceptable space or deny on the longer-than-acceptable. For the latter, ^[0-9]+_[0-9]+_[0-9]+_[0-9]+_[0-9]+_[0-9]+_[0-9]+_[0-9]+_[0-9]+_[0-9]+_[0-9]+_[0-9]+_[0-9]+_[0-9]+_([0-9]+_)+ clobbers 15 ASNs and longer. -- RSUC / GweepNet / Spunk / FnB / Usenix / SAGE From tkapela at gmail.com Mon Aug 17 16:58:12 2009 From: tkapela at gmail.com (Anton Kapela) Date: Mon, 17 Aug 2009 17:58:12 -0400 Subject: bits/hz/second: we're barely more efficient than the telegraph (Re: TransAtlantic 40 Gig Waves Message-ID: <2e9d8ae50908171458h4c5b96b0mf644c30468580ffe@mail.gmail.com> I'll comment on both: On Mon, Aug 17, 2009 at 12:14 PM, Rod Beck wrote: > Rod, do you know if the 40G waves increased the spectrum efficiency of > your fiber? On land systems they pretty much break even, i.e. you can [rod beck replies] > The enabling technology is based on advanced encoding techniques allowing a greater rate of symbol transfer." Looking back in Google and other IEEE papers, the previous 20 years of interfacing our abstract "bits" to the real world via photons hasn't been met with terribly high efficiencies, though we certainly have seen both great progress in the transmitter (who could have imagined a VCSEL in 1985?) and receiver technology, and of course a significant improvement in usable bits/sec. I can only wonder what the curve of optical spectral efficiency we achieve over the next decades will resemble. Perhaps we'll have to wait for a "Shannon of Optics" to stand up (or quit their day job at whatever modern-day version of $bell_labs they're stuck working for) and point out something obvious we're missing. A bit of sobering reality I often consider is we waited roughly a century to progress from where Marconi began to the present day, where we have cheap radios doing 12 bits/hz/sec costing about $20k (a pair). Clearly a key difference is that people are paying (allot, propotionately) to communicate $stuff and folks value networks more than they did previously - so we're not in the same position folks were pre-1900's, struggling to find a market for their crazy wires across the sea. For the experts out there: how long are we going to wait for something more efficient than morse code over twisted pairs? -Tk From dwhite at olp.net Mon Aug 17 17:12:19 2009 From: dwhite at olp.net (Dan White) Date: Mon, 17 Aug 2009 17:12:19 -0500 Subject: Request for a pointer - Linux modifying DSCP on replies? In-Reply-To: <5a318d410908171419n560075aar6e589145cf223efe@mail.gmail.com> References: <5a318d410908171419n560075aar6e589145cf223efe@mail.gmail.com> Message-ID: <20090817221219.GE25707@dan.olp.net> On 17/08/09?14:19?-0700, Darren Bolding wrote: >I believe this is operational content, but may well be better asked >somewhere else. I would love to have a pointer to another list/website. See the linux-net mailing list: http://www.kernel.org/pub/linux/docs/lkml/ -- Dan White -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Digital signature URL: From Eric.Ballard at suddenlink.com Mon Aug 17 17:21:08 2009 From: Eric.Ballard at suddenlink.com (Ballard, Eric) Date: Mon, 17 Aug 2009 17:21:08 -0500 Subject: Anyone else seeing "(invalid or corrupt AS path) 3 bytes E01100" ? In-Reply-To: <20090817214840.GA76062@gweep.net> References: <6348c7fd0908171311h2936e6bfifcfd684205befbaf@mail.gmail.com> <20090817214840.GA76062@gweep.net> Message-ID: With the help from our transit providers and Cisco TAC the issues looks to be that AS9354 is sending AS0 and causing the corruption when processed in our Cisco CRS routers. AS9354 shows to be Community Network Center Inc. (CNCI) or TDNC and directly connected to KDDI AS2516. If anyone from AS9354 is on this list please contact me or stop this advertisement or someone from KDDI please assist. Thanks ERIC -----Original Message----- From: Joe Provo [mailto:nanog-post at rsuc.gweep.net] Sent: Monday, August 17, 2009 4:49 PM To: randal k Cc: nanog at nanog.org Subject: Re: Anyone else seeing "(invalid or corrupt AS path) 3 bytes E01100" ? On Mon, Aug 17, 2009 at 03:37:07PM -0600, randal k wrote: > Yep, we started seeing this right around 12:20pm MST. We saw it from a > customer's rapidly-flapping BGP peer. We told them to configure bgp > maxas-limit, but apparently CRS1s don't have that command. > > Anybody have a handy route-map that will deny anything with a as-path > longer than say 15-20? ;-) Been a while since I had to throw this on cisco, but I since it lacks sane repeat constraint, you have to either choose to iterate over your acceptable space or deny on the longer-than-acceptable. For the latter, ^[0-9]+_[0-9]+_[0-9]+_[0-9]+_[0-9]+_[0-9]+_[0-9]+_[0-9]+_[0-9]+_[0-9]+_[0-9]+_[0-9]+_[0-9]+_[0-9]+_([0-9]+_)+ clobbers 15 ASNs and longer. -- RSUC / GweepNet / Spunk / FnB / Usenix / SAGE From dholmes at mwdh2o.com Mon Aug 17 17:23:22 2009 From: dholmes at mwdh2o.com (Holmes,David A) Date: Mon, 17 Aug 2009 15:23:22 -0700 Subject: TransAtlantic 40 Gig Waves In-Reply-To: <1E8B940C5E21014AB8BE70B975D40EDB01628626@bert.HiberniaAtlantic.local> References: <1E8B940C5E21014AB8BE70B975D40EDB0162857C@bert.HiberniaAtlantic.local><4A849D32.3040604@internode.com.au><1E8B940C5E21014AB8BE70B975D40EDB0162859C@bert.HiberniaAtlantic.local><20090814131745.GB51443@gerbil.cluepon.net><1E8B940C5E21014AB8BE70B975D40EDB016285A9@bert.HiberniaAtlantic.local> <1E8B940C5E21014AB8BE70B975D40EDB01628626@bert.HiberniaAtlantic.local> Message-ID: <485ED9BA02629E4BBBA53AC892EDA50E097F8E1C@usmsxt104.mwd.h2o> It seems intuitive, but according to basic queuing theory splitting up a single channel into N fixed smaller channels makes the response time (T), N times worse, where T= (queuing + transmission time). -----Original Message----- From: Rod Beck [mailto:Rod.Beck at hiberniaatlantic.com] Sent: Monday, August 17, 2009 9:14 AM To: Richard A Steenbergen Cc: nanog at nanog.org Subject: RE: TransAtlantic 40 Gig Waves Rod, do you know if the 40G waves increased the spectrum efficiency of your fiber? On land systems they pretty much break even, i.e. you can have a 100GHz 40G channels or 4x25GHz 10G channels but at the end of the day you still get the same amount of signal out of the fiber. I don't know whats being done on undersea cables though. Eventually this will get better too, and 40G will become the "native" wavelength standard with 10G being muxed onto them, similar to what we saw with the transition from 2.5G->10G 10 years ago. -- Richard A Steenbergen http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) "Rod. This is direct from engineering: The number of wavelengths or channels Hibernia have on their DWDM infrastructure remains the same, however now each wave can be at a rate of 40Gb/s instead of only 10Gb/s. In the extreme case, we get 4 times the capacity, but in reality, because of the existing installed 10G's, we would not necessarily swap out all existing cards. We could say the overall increase in capacity is "up-to" 4 times. The enabling technology is based on advanced encoding techniques allowing a greater rate of symbol transfer." From jared at puck.nether.net Mon Aug 17 17:40:39 2009 From: jared at puck.nether.net (Jared Mauch) Date: Mon, 17 Aug 2009 18:40:39 -0400 Subject: Anyone else seeing "(invalid or corrupt AS path) 3 bytes E01100" ? In-Reply-To: References: <6348c7fd0908171311h2936e6bfifcfd684205befbaf@mail.gmail.com> Message-ID: <54BE1E6C-EF51-49A5-930D-29B0B6C17C30@puck.nether.net> On Aug 17, 2009, at 5:37 PM, randal k wrote: > Yep, we started seeing this right around 12:20pm MST. We saw it from a > customer's rapidly-flapping BGP peer. We told them to configure bgp > maxas-limit, but apparently CRS1s don't have that command. > > Anybody have a handy route-map that will deny anything with a as-path > longer than say 15-20? ;-) Is there some significant barrier to people getting recent code on the devices that is not impacted by this and the other fun bgp 'attacks' that can happen? We usually see customers drop bgp sessions all over, making me wonder ... if you're not able to upgrade, what is the issue? Just that most people don't see these as an attack against their infrastructure? That people are unwilling to upgrade code unless it has a long-term impact to their operations? An outage once every few months is OK? - Jared From deleskie at gmail.com Mon Aug 17 17:45:28 2009 From: deleskie at gmail.com (deleskie at gmail.com) Date: Mon, 17 Aug 2009 22:45:28 +0000 Subject: Anyone else seeing "(invalid or corrupt AS path) 3 bytes E01100" ? Message-ID: <1325188421-1250549138-cardhu_decombobulator_blackberry.rim.net-2114119667-@bxe1156.bisx.prod.on.blackberry> I'd have to _assume_ that a lot of those impacted don't have a maint contract with their router vendor of choice and therefore don't have an easy path to upgrade. -jim ------Original Message------ From: Jared Mauch To: randal k Cc: nanog at nanog.org Subject: Re: Anyone else seeing "(invalid or corrupt AS path) 3 bytes E01100" ? Sent: Aug 17, 2009 7:40 PM On Aug 17, 2009, at 5:37 PM, randal k wrote: > Yep, we started seeing this right around 12:20pm MST. We saw it from a > customer's rapidly-flapping BGP peer. We told them to configure bgp > maxas-limit, but apparently CRS1s don't have that command. > > Anybody have a handy route-map that will deny anything with a as-path > longer than say 15-20? ;-) Is there some significant barrier to people getting recent code on the devices that is not impacted by this and the other fun bgp 'attacks' that can happen? We usually see customers drop bgp sessions all over, making me wonder ... if you're not able to upgrade, what is the issue? Just that most people don't see these as an attack against their infrastructure? That people are unwilling to upgrade code unless it has a long-term impact to their operations? An outage once every few months is OK? - Jared Sent from my BlackBerry device on the Rogers Wireless Network From jared at puck.nether.net Mon Aug 17 17:50:33 2009 From: jared at puck.nether.net (Jared Mauch) Date: Mon, 17 Aug 2009 18:50:33 -0400 Subject: Anyone else seeing "(invalid or corrupt AS path) 3 bytes E01100" ? In-Reply-To: <1325188421-1250549138-cardhu_decombobulator_blackberry.rim.net-2114119667-@bxe1156.bisx.prod.on.blackberry> References: <1325188421-1250549138-cardhu_decombobulator_blackberry.rim.net-2114119667-@bxe1156.bisx.prod.on.blackberry> Message-ID: <654840C7-D014-4CC8-BABF-EEB24B6A63B5@puck.nether.net> On Aug 17, 2009, at 6:45 PM, deleskie at gmail.com wrote: > I'd have to _assume_ that a lot of those impacted don't have a maint > contract with their router vendor of choice and therefore don't have > an easy path to upgrade. > -jim Cisco gives out free software upgrades for any security(PSIRT) issue. Take the recent 4-byte asn crash advisory: -- snip -- http://www.cisco.com/en/US/products/products_security_advisory09186a0080aea4c9.shtml Customers should have their product serial number available and be prepared to give the URL of this notice as evidence of entitlement to a free upgrade. Free upgrades for non-contract customers must be requested through the TAC. -- snip -- I would view this as an active attack against the internet infrastructure and be working with the PSIRT team if it impacted my network ... - Jared From darren at bolding.org Mon Aug 17 18:08:26 2009 From: darren at bolding.org (Darren Bolding) Date: Mon, 17 Aug 2009 16:08:26 -0700 Subject: Request for a pointer - Linux modifying DSCP on replies? In-Reply-To: References: <5a318d410908171419n560075aar6e589145cf223efe@mail.gmail.com> Message-ID: <5a318d410908171608n70f20e08te3bd609a4f4951c1@mail.gmail.com> Steve, Perhaps it is outside the DS domain, and that is the issue. It seems odd that the behavior with ICMP/Ping is different than that with TCP however. Not sure which is technically correct, but I am going to follow up on some of the pointers I've gotten to try and learn that. It just seems natural to me that connection oriented traffic would have the same markings on both sides of the conversation unless explicitly told otherwise. I would love to be able to mark the traffic at the edge of the DS domain- I do this at ingress from one location. The challenge I am trying to solve is that the DS edge switch will not reliably know how to policy-route traffic unless it has been previously marked. To clarify, as in many other environments, we have stateful devices such as firewalls and load balancers. I want to be able to route traffic that ingressed through one of these devices to egress through it as well. This is entirely solvable by splitting equipment functionally (a cluster of servers and associated network equipment, real or virtual associated with a service) or by employing SNAT solutions. However, for various reasons these solutions are not preferred in our environment, and I dare say I am not alone in that viewpoint. What I am trying to deploy now is a system where the stateful equipment (in this case a load balancer) has its traffic to the rest of the network tagged on ingress. Since I am using Cisco 6500's with sup720's, I can classify and mark the traffic with a DSCP setting via PFC/DFC hardware. I then inspect traffic at the layer-3 edge for the various pools of servers. Depending on the DSCP marking of the packet, I change the next-hop. Since this is implemented through an extended ACL for a route-map it is handled in hardware (a good thing). Research shows that I can implement similar functionality in hardware on L3 switching gear from Juniper, Foundry, etc. so I am not boxing myself into a vendor. I don't believe Cisco supports using reflexive-acl's to apply policy routing, and even if they did, that would likely swamp our sup's CPU's, so I don't believe maintaining a stateful filter on the switch is viable. This all works as expected for Ping's and the ICMP replies. It breaks down for TCP http/mysql connections. It sounds like the correct (per-spec) solution may be to have the Linux servers track the incoming connections DSCP setting and mark the outgoing packets related to those connections. I am not at all certain this will not hit the servers CPU's more than desired or require additional connection-tracking resources than the ones we currently implement via iptables. Is there some other design option I am not considering? Thanks to those of you who have replied so far, it is at least a start down some additional paths of research for me! It's been since the days of BSDI that I have been involved in system networking internals, so I have been at a loss who to even ask! --D On Mon, Aug 17, 2009 at 2:44 PM, Steve Miller wrote: > Would not the end station be considered to be outside of the DS > domain? It does not necessarily make sense (to me) for reply packets > to be marked unless they are appropriate classified and marked on the > return path at the point they re-enter the DS domain. > > I would imagine that iptables and the DSCP target would do what you > wanted, yes. I'd consider classifying and marking traffic at whatever > switch you would consider to be at the edge of the DS domain > (connected to this server.) > > -Steve > > 2009/8/17 Darren Bolding : > > I believe this is operational content, but may well be better asked > > somewhere else. I would love to have a pointer to another list/website. > > I am looking to do some policy routing based on DSCP marking, and I have > > this all working inside the networking equipment. I DSCP mark some > packets > > at ingress and I policy-route others based on ACL's matching those DSCP > > markings. This should allow me to solve some problems in a rather > elegant > > manner, if I do say so myself. > > > > And this works fine for some things- I have verified that Ping's to a > host > > work as expected- the Ping shows up at the destination host DSCP marked, > and > > the ICMP reply leaves with the same DSCP marking. > > > > However, when I do this with apache and mysql connections (TCP 80/3306), > the > > incoming packets are marked, but the replies are not. > > > > My research into the subject doesn't seem to suggest there is a standard > for > > whether replies to a TCP connection are required to have the same DSCP > > marking, but it seems to make a lot of sense that they would. > > > > I've disabled iptables on the server host to no avail. I've looked > around > > for an apache or Linux kernel setting and found nothing. > > > > At this point I'm looking for pointers- to a way to solve this issue, or > to > > a better place to ask. > > > > I've started investigating writing iptables rules to match incoming > > connections that have DSCP marking and explicitly mark response traffic, > but > > that seems, I don't know... wrong. > > > > Linux kernel we are using is 2.6.9-67.ELsmp. > > > > Any help or pointers would be appreciated! > > > > --D > > > > -- > > -- Darren Bolding -- > > -- darren at bolding.org -- > > > > > > -- > Steve Miller, CCIE #23977 (R&S), RHCE > Key fingerprint = 5CE3 A789 4CF5 666F 5CD6 2A8E 3132 77C7 483F 5F9D > -- -- Darren Bolding -- -- darren at bolding.org -- From jfbeam at gmail.com Mon Aug 17 18:26:59 2009 From: jfbeam at gmail.com (Ricky Beam) Date: Mon, 17 Aug 2009 19:26:59 -0400 Subject: Anyone else seeing "(invalid or corrupt AS path) 3 bytes E01100" ? In-Reply-To: <54BE1E6C-EF51-49A5-930D-29B0B6C17C30@puck.nether.net> References: <6348c7fd0908171311h2936e6bfifcfd684205befbaf@mail.gmail.com> <54BE1E6C-EF51-49A5-930D-29B0B6C17C30@puck.nether.net> Message-ID: On Mon, 17 Aug 2009 18:40:39 -0400, Jared Mauch wrote: > Is there some significant barrier to people getting recent code on the > devices that is not impacted by this and the other fun bgp 'attacks' > that can happen? In a word: YES. Any respectable ISP will not load code that has not been extensively tested. Failure to do so can, and WILL, lead to even greater impact outages. (we've all made that mistake. Once.) Unless you do millions with Cisco and can therefore get custom IOS builds, you won't get a newer version with *just* the intended bug fixed. Their maint "rebuilds" end up with multiple "fixes" and all too often, previous fixes reverted. (I stopped counting the number of times I had to bitch at them to refix the SNMP DLCI interface counters on the 7401... "we don't test frame relay on the 7401" -- sure, that's eons ago, but nothing has changed over there.) And then there's the question of support... again, any respectable ISP maintains maint contracts with their vendors. But, things tend to fall through the cracks... contracts expire, people forget to list all the equipment, vendors drop support for various hardware and software, etc. You've obviously not gone to Cisco for any "non-contract" software updates. It's faster to bribe someone with an active service contract or use google. Also... Never underestimate the power of Lazy! --Ricky From jay at west.net Mon Aug 17 18:31:23 2009 From: jay at west.net (Jay Hennigan) Date: Mon, 17 Aug 2009 16:31:23 -0700 Subject: bits/hz/second: we're barely more efficient than the telegraph In-Reply-To: <2e9d8ae50908171458h4c5b96b0mf644c30468580ffe@mail.gmail.com> References: <2e9d8ae50908171458h4c5b96b0mf644c30468580ffe@mail.gmail.com> Message-ID: <4A89E84B.6090109@west.net> Anton Kapela wrote: > For the experts out there: how long are we going to wait for something > more efficient than morse code over twisted pairs? For text messages, Morse code can be more efficient than modern encoding techniques. Morse is a variable-length code weighted to favor the more common symbols in plain text messages. The letter "e" is a single bit. In terms of message throughput/hz/second/, Morse is actually pretty decent. -- 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 fergdawgster at gmail.com Mon Aug 17 19:17:51 2009 From: fergdawgster at gmail.com (Paul Ferguson) Date: Mon, 17 Aug 2009 17:17:51 -0700 Subject: Anyone else seeing "(invalid or corrupt AS path) 3 bytes E01100" ? In-Reply-To: References: <6348c7fd0908171311h2936e6bfifcfd684205befbaf@mail.gmail.com> <54BE1E6C-EF51-49A5-930D-29B0B6C17C30@puck.nether.net> Message-ID: <6cd462c00908171717n2da4cb55l7dd1d106d8664d68@mail.gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Mon, Aug 17, 2009 at 4:26 PM, Ricky Beam wrote: > > Any respectable ISP will not load code that has not been extensively > tested. [...] Just an observation on how things have changed in ~15 years: I recall Cisco code bugs that were fixed in semi- real-time, and quotes from tli: "Code still warm from compiler. Confidence level: Boots in lab." :-) - - ferg -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.5.3 (Build 5003) wj8DBQFKifMaq1pz9mNUZTMRAkIVAKD/G3MTDXLx9QydkEQq4azQZW4VGwCgrI+t y30sajrGH98vhOhcyyW0wm0= =CzXf -----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 joelja at bogus.com Mon Aug 17 19:22:50 2009 From: joelja at bogus.com (Joel Jaeggli) Date: Mon, 17 Aug 2009 17:22:50 -0700 Subject: IPv6 Addressing Help In-Reply-To: <3c3e3fca0908141352me6d8b65ue7288b0b44172548@mail.gmail.com> References: <4A857CB3.10600@uplogon.com> <3c3e3fca0908141133j73b26fd8o1066c93c846205e8@mail.gmail.com> <4A85AF86.5000603@spaghetti.zurich.ibm.com> <3c3e3fca0908141352me6d8b65ue7288b0b44172548@mail.gmail.com> Message-ID: <4A89F45A.40700@bogus.com> William Herrin wrote: > The future looks a lot like the past but with more blinking lights. > Seriously, I'm pretty nuts when it comes to networking. My basement is > AS11875, multihomed with about 35mbps of bandwidth. If I can't imagine > how *I* would use more than 16 subnets then it's a safe bet that many > years will pass before Joe random DSL customer wants to. The the Dell sitting on my desk has something like 15 VMs spread across 6 or so discrete subnets, the host has a public v4 address as does one of vm's along with about two dozen private addresses, they're interconnected with some boxes in the closet, via two ethernets and several vlans. The box is using a /61 on the v6 side... > The world won't end, even if you assign every customer a /48. But why > be so grossly wasteful *before* anyone has demonstrated a practical > use for doing so? Why is is necessary insist that using bits in a fashion that doesn't require that growth be predicated on requests for additional resources be considered wasteful? > >> I guess you ran the numbers on how to run out of IPv6 address space? > > IIRC, RIPE allocated a /19 to France Telecom. Doesn't take more than a > few hundred thousand allocations like that one to wipe out the IPv6 > address space. > > Regards, > Bill Herrin > > From markom at markom.info Mon Aug 17 19:24:02 2009 From: markom at markom.info (Marko Milivojevic) Date: Tue, 18 Aug 2009 00:24:02 +0000 Subject: Anyone else seeing "(invalid or corrupt AS path) 3 bytes E01100" ? In-Reply-To: <6cd462c00908171717n2da4cb55l7dd1d106d8664d68@mail.gmail.com> References: <6348c7fd0908171311h2936e6bfifcfd684205befbaf@mail.gmail.com> <54BE1E6C-EF51-49A5-930D-29B0B6C17C30@puck.nether.net> <6cd462c00908171717n2da4cb55l7dd1d106d8664d68@mail.gmail.com> Message-ID: > Confidence level: Boots in lab." One could argue that certain things haven't actually changed that much ;-). Marko. -- Marko CCIE #18427 (SP) My network blog: http://cisco.markom.info/ From mysidia at gmail.com Mon Aug 17 19:33:45 2009 From: mysidia at gmail.com (James Hess) Date: Mon, 17 Aug 2009 19:33:45 -0500 Subject: Request for a pointer - Linux modifying DSCP on replies? In-Reply-To: <5a318d410908171419n560075aar6e589145cf223efe@mail.gmail.com> References: <5a318d410908171419n560075aar6e589145cf223efe@mail.gmail.com> Message-ID: <6eb799ab0908171733i532c95bet73ffc11a626efa35@mail.gmail.com> On Mon, Aug 17, 2009 at 4:19 PM, Darren Bolding wrote: > the ICMP reply leaves with the same DSCP marking. ICMPs may have special treatment. This is the kernel replying, not a user application. > However, when I do this with apache and mysql connections (TCP 80/3306), the > incoming packets are marked, but the replies are not. I haven't known Linux to automatically apply DSCP markings. Believe this operation may be by design. Not everyone is likely to want response traffic to have the same markings for all TCP protocols. HTTP requests are often small request, big response. People might sometimes want low delay for the request but higher throughput for HTTP responses (though higher delay compared to other applications sharing that bandwidth). If an application developer wants a Linux computer to apply DSCP or TOS bits, either, the application needs to elect to set ToS bits using setsockopt(), SO_PRIORITY, and SO_TOS on the socket descriptor itself... the app must be running as superuser to do this Or you may also be able to set the bits using iptables and the mangle table. e.g. # iptables -t mangle -I OUTPUT -p tcp --sport 80 -j DSCP --set-dscp 0x1a You may also be able to use a CONNMARK iptables target to mark a connection , and then use the mangle table to set the DSCP field of OUTPUT packets that match the connection mark. -- -J From ray at oneunified.net Mon Aug 17 19:46:45 2009 From: ray at oneunified.net (Ray Burkholder) Date: Mon, 17 Aug 2009 21:46:45 -0300 Subject: IPv6 Addressing Help In-Reply-To: <4A89F45A.40700@bogus.com> References: <4A857CB3.10600@uplogon.com> <3c3e3fca0908141133j73b26fd8o1066c93c846205e8@mail.gmail.com> <4A85AF86.5000603@spaghetti.zurich.ibm.com> <3c3e3fca0908141352me6d8b65ue7288b0b44172548@mail.gmail.com> <4A89F45A.40700@bogus.com> Message-ID: <077301ca1f9d$5d6d9670$1848c350$@net> > > Why is is necessary insist that using bits in a fashion that doesn't > require that growth be predicated on requests for additional resources > be considered wasteful? > Don't we still need to subnet in a reasonably small fashion in order to contain broadcasts, ill-behaved machines, and other regular discovery crap that exists on any given segment? And if we have to segment in such a fashion, the request and allocation of additional resources is a natural consequence of such containment. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From brett at the-watsons.org Mon Aug 17 21:11:06 2009 From: brett at the-watsons.org (Brett Watson) Date: Mon, 17 Aug 2009 19:11:06 -0700 Subject: Anyone else seeing "(invalid or corrupt AS path) 3 bytes E01100" ? In-Reply-To: <6cd462c00908171717n2da4cb55l7dd1d106d8664d68@mail.gmail.com> References: <6348c7fd0908171311h2936e6bfifcfd684205befbaf@mail.gmail.com> <54BE1E6C-EF51-49A5-930D-29B0B6C17C30@puck.nether.net> <6cd462c00908171717n2da4cb55l7dd1d106d8664d68@mail.gmail.com> Message-ID: On Aug 17, 2009, at 5:17 PM, Paul Ferguson wrote: > I recall Cisco code bugs that were fixed in semi- real-time, and > quotes > from tli: "Code still warm from compiler. Confidence level: Boots in > lab." IETF Dallas, 1995 I think. MCI Reston engg and Cisco (Ravi and others) in the terminal room cutting a new image of IS-IS for us because we'd tripped on the 24-day timer bug wherein all adjacencies would drop. Loaded on production routers that evening to fix the problem... good times :) -b From marka at isc.org Mon Aug 17 21:38:25 2009 From: marka at isc.org (Mark Andrews) Date: Tue, 18 Aug 2009 12:38:25 +1000 Subject: IPv6 Addressing Help In-Reply-To: Your message of "Mon, 17 Aug 2009 21:46:45 -0300." <077301ca1f9d$5d6d9670$1848c350$@net> References: <4A857CB3.10600@uplogon.com> <3c3e3fca0908141133j73b26fd8o1066c93c846205e8@mail.gmail.com> <4A85AF86.5000603@spaghetti.zurich.ibm.com> <3c3e3fca0908141352me6d8b65ue7288b0b44172548@mail.gmail.com> <4A89F45A.40700@bogus.com> <077301ca1f9d$5d6d9670$1848c350$@net> Message-ID: <200908180238.n7I2cP7i070270@drugs.dv.isc.org> In message <077301ca1f9d$5d6d9670$1848c350$@net>, "Ray Burkholder" writes: > > > > Why is is necessary insist that using bits in a fashion that doesn't > > require that growth be predicated on requests for additional resources > > be considered wasteful? > > > > Don't we still need to subnet in a reasonably small fashion in order to > contain broadcasts, ill-behaved machines, and other regular discovery > crap that exists on any given segment? That is the constrained by the number of machines on the segment. It has nothing to do with the number of bits allocated to the local portion other than that number of bits has to be big enough to contain the number of machines. With IPv4 the address space is so tight that one drives the other. With IPv6 these are independent of each other. > And if we have to segment in such a fashion, the request and allocation > of additional resources is a natural consequence of such containment. But we don't. This is one of the difference between IPv4 think and IPv6 think. I can remember the discussions about whether IPv6 addressed should be 64 bits or not. One of the reasons for going to 128 bits was so that we wouldn't have to worry about being overly conservative with address at the network level. The original thinking was /80 which later changed to /64. Pack networks not hosts. Mark > -- > This message has been scanned for viruses and > dangerous content by MailScanner, and is > believed to be clean. > > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From steve at ibctech.ca Mon Aug 17 21:43:53 2009 From: steve at ibctech.ca (Steve Bertrand) Date: Mon, 17 Aug 2009 22:43:53 -0400 Subject: IPv6 Addressing Help In-Reply-To: <077301ca1f9d$5d6d9670$1848c350$@net> References: <4A857CB3.10600@uplogon.com> <3c3e3fca0908141133j73b26fd8o1066c93c846205e8@mail.gmail.com> <4A85AF86.5000603@spaghetti.zurich.ibm.com> <3c3e3fca0908141352me6d8b65ue7288b0b44172548@mail.gmail.com> <4A89F45A.40700@bogus.com> <077301ca1f9d$5d6d9670$1848c350$@net> Message-ID: <4A8A1569.90208@ibctech.ca> Ray Burkholder wrote: >> Why is is necessary insist that using bits in a fashion that doesn't >> require that growth be predicated on requests for additional resources >> be considered wasteful? >> > > Don't we still need to subnet in a reasonably small fashion in order to contain broadcasts, ill-behaved machines, and other regular discovery crap that exists on any given segment? And if we have to segment in such a fashion, the request and allocation of additional resources is a natural consequence of such containment. > There are other ways around such problems. You've got larger issues if you need to worry about this. fwiw, I'm (in the ARIN region) assigning the value of a /56 for each CP(E). Along side of that, I'm ensuring that the encompassing /48 is reserved in the event that things go that way. This ensures that each client receives a /56 minimum, but also ensures that I can assign the rest of the /48 if ARIN enforces it, or divvy it up appropriately from the PE to the CE in the event From tony at lava.net Mon Aug 17 22:08:07 2009 From: tony at lava.net (Antonio Querubin) Date: Mon, 17 Aug 2009 17:08:07 -1000 (HST) Subject: IPv6 Addressing Help In-Reply-To: <077301ca1f9d$5d6d9670$1848c350$@net> References: <4A857CB3.10600@uplogon.com> <3c3e3fca0908141133j73b26fd8o1066c93c846205e8@mail.gmail.com> <4A85AF86.5000603@spaghetti.zurich.ibm.com> <3c3e3fca0908141352me6d8b65ue7288b0b44172548@mail.gmail.com> <4A89F45A.40700@bogus.com> <077301ca1f9d$5d6d9670$1848c350$@net> Message-ID: On Mon, 17 Aug 2009, Ray Burkholder wrote: > Don't we still need to subnet in a reasonably small fashion in order to > contain broadcasts, ill-behaved machines, and other regular discovery > crap that exists on any given segment? And if we have to segment in > such a fashion, the request and allocation of additional resources is a > natural consequence of such containment. Don't confuse the reasons for creating subnets with the rationale for determining their size. In IPv6 we really do NOT want to be overly concerned about how many hosts a subnet can contain. Antonio Querubin 808-545-5282 x3003 e-mail/xmpp: tony at lava.net From oberman at es.net Mon Aug 17 23:47:28 2009 From: oberman at es.net (Kevin Oberman) Date: Mon, 17 Aug 2009 21:47:28 -0700 Subject: Anyone else seeing "(invalid or corrupt AS path) 3 bytes E01100" ? In-Reply-To: Your message of "Mon, 17 Aug 2009 19:11:06 PDT." Message-ID: <20090818044728.546281CC0E@ptavv.es.net> > From: Brett Watson > Date: Mon, 17 Aug 2009 19:11:06 -0700 > > On Aug 17, 2009, at 5:17 PM, Paul Ferguson wrote: > > > I recall Cisco code bugs that were fixed in semi- real-time, and > > quotes > > from tli: "Code still warm from compiler. Confidence level: Boots in > > lab." > > IETF Dallas, 1995 I think. MCI Reston engg and Cisco (Ravi and others) > in the terminal room cutting a new image of IS-IS for us because we'd > tripped on the 24-day timer bug wherein all adjacencies would drop. > Loaded on production routers that evening to fix the problem... good > times :) I remember back in 1993 or 1994 getting a note from Tony Li chastising us for running BGP4 code that was over a WEEK old. How could we possibly expect things to work with code that far out of date? The amazing part is that BGP4 not only worked, but was very stable less then a month later when NSFnet shut down an se had to go to BGP4 to peer with everyone (like MCI, Sprint, NASA, and UUnet). Yep, it booted in the lab, all right. -- 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 swmike at swm.pp.se Tue Aug 18 00:28:16 2009 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Tue, 18 Aug 2009 07:28:16 +0200 (CEST) Subject: TransAtlantic 40 Gig Waves In-Reply-To: <1E8B940C5E21014AB8BE70B975D40EDB01628626@bert.HiberniaAtlantic.local> References: <1E8B940C5E21014AB8BE70B975D40EDB0162857C@bert.HiberniaAtlantic.local> <4A849D32.3040604@internode.com.au> <1E8B940C5E21014AB8BE70B975D40EDB0162859C@bert.HiberniaAtlantic.local> <20090814131745.GB51443@gerbil.cluepon.net> <1E8B940C5E21014AB8BE70B975D40EDB016285A9@bert.HiberniaAtlantic.local> <1E8B940C5E21014AB8BE70B975D40EDB01628626@bert.HiberniaAtlantic.local> Message-ID: On Mon, 17 Aug 2009, Rod Beck wrote: > Rod, do you know if the 40G waves increased the spectrum efficiency of > your fiber? On land systems they pretty much break even, i.e. you can > have a 100GHz 40G channels or 4x25GHz 10G channels but at the end of the > day you still get the same amount of signal out of the fiber. I don't > know whats being done on undersea cables though. Eventually this will > get better too, and 40G will become the "native" wavelength standard > with 10G being muxed onto them, similar to what we saw with the > transition from 2.5G->10G 10 years ago. Think of this as the natural progression equivalent to the evolution of speed over phone lines, from 300bps to 56k, ie use of DSPs to get more out of the available spectral capacity. 10G is generally pretty simple NRZ, 40/100G is much more complex using multiple bit per "baud" and/or polarization. (around page 34 is where the stuff you're asking about comes in) My guess is that 100G will be available and being rolled out before 40G is widely used, thus we'll wont see much 40G in DWDM systems, at least not with the current encoding standards (because they don't fit directly into 10G systems as they have higher requirements). -- Mikael Abrahamsson email: swmike at swm.pp.se From ip at ioshints.info Tue Aug 18 02:37:22 2009 From: ip at ioshints.info (Ivan Pepelnjak) Date: Tue, 18 Aug 2009 09:37:22 +0200 Subject: Anyone else seeing "(invalid or corrupt AS path) 3 bytes E01100" ? In-Reply-To: References: <6348c7fd0908171311h2936e6bfifcfd684205befbaf@mail.gmail.com> Message-ID: <000901ca1fd6$ba47a3c0$0a00000a@nil.si> > Anybody have a handy route-map that will deny anything with a > as-path longer than say 15-20? ;-) http://wiki.nil.com/Filter_excessively_prepended_BGP_paths Ivan http://www.ioshints.info/about http://blog.ioshints.info/ From rmacharia at gmail.com Tue Aug 18 04:43:43 2009 From: rmacharia at gmail.com (Raymond Macharia) Date: Tue, 18 Aug 2009 12:43:43 +0300 Subject: East Africa Fibre Connectivity- Heads up In-Reply-To: <6A1B9139-6D6B-48B6-A866-4A25146FB88D@nosignal.org> References: <6A1B9139-6D6B-48B6-A866-4A25146FB88D@nosignal.org> Message-ID: Thanks Andy for sharing that bit as well. Yes the excitement in region needs to be tempered with sober network analysis to make sure we do not fall short of what right now is being seen as "massive" amounts of capacity by many. Regards Raymond Macharia On Sun, Aug 16, 2009 at 12:06 PM, Andy Davidson wrote: > > On 5 Aug 2009, at 11:13, Raymond Macharia wrote: > > Hello all,in the last two weeks or so providers in East Africa, >> particularly >> in Kenya where I am, have been moving from Satellite to Fibre for the >> internet Back bone connectivity. From where I am I have seen an upsurge of >> about 100Mbps in the last two days from my users. >> > > Hi, Raymond -- > > We see similar changes to traffic in the internet exchange world when > someone changes their connection from 1GE to 10GE. Before they turn up > additional sessions, they often peer more traffic, which I attribute to > sliding window doing its thing, and eventually user behaviour altering. > > It's encouraging that your customers' internet performance experiences are > improving - do share your upgrade stories with other providers in your > region ! > > Best wishes, > Andy > From psirt at cisco.com Tue Aug 18 11:35:37 2009 From: psirt at cisco.com (Cisco Systems Product Security Incident Response Team) Date: Tue, 18 Aug 2009 16:35:37 -0000 Subject: Cisco Security Advisory: Cisco Security Advisory: Cisco IOS XR Software Border Gateway Protocol Vulnerability Message-ID: <20090818.bgp@psirt.cisco.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Cisco Security Advisory: Cisco Security Advisory: Cisco IOS XR Software Border Gateway Protocol Vulnerability Advisory ID: cisco-sa-20090818-bgp http://www.cisco.com/warp/public/707/cisco-sa-20090818-bgp.shtml Revision 1.0 For Public Release 2009 August 18 1500 UTC (GMT) - --------------------------------------------------------------------- Summary ======= Cisco IOS XR will reset a Border Gateway Protocol (BGP) peering session when receiving a specific invalid BGP update. The vulnerability manifests when a BGP peer announces a prefix with a specific invalid attribute. On receipt of this prefix, the Cisco IOS XR device will restart the peering session by sending a notification. The peering session will flap until the sender stops sending the invalid/corrupt update. This is a different vulnerability to what was disclosed in the Cisco Security Advisory "Cisco IOS Software Border Gateway Protocol 4-Byte Autonomous System Number Vulnerabilities" disclosed on the 2009 July 29 1600 UTC at the following link: http://www.cisco.com/warp/public/707/cisco-sa-20090729-bgp.shtml Cisco is preparing to release free software maintenance upgrade (SMU) that address this vulnerability. This advisory will be updated once the SMU is available. A workaround that mitigates this vulnerability is available. This advisory is posted at http://www.cisco.com/warp/public/707/cisco-sa-20090818-bgp.shtml Affected Products ================= This vulnerability affects all Cisco IOS XR software devices after and including software release 3.4.0 configured with BGP routing. Vulnerable Products +------------------ To determine the Cisco IOS XR Software release that is running on a Cisco product, administrators can log in to the device and issue the show version command to display the system banner. The system banner confirms that the device is running Cisco IOS XR Software by displaying text similar to "Cisco IOS XR Software". The software version is displayed after the text "Cisco IOS XR Software". The following example identifies a Cisco CRS-1 that is running Cisco IOS XR Software Release 3.6.2: RP/0/RP0/CPU0:CRS#show version Tue Aug 18 14:25:17.407 AEST Cisco IOS XR Software, Version 3.6.2[00] Copyright (c) 2008 by Cisco Systems, Inc. ROM: System Bootstrap, Version 1.49(20080319:195807) [CRS-1 ROMMON], CRS uptime is 4 weeks, 4 days, 1 minute System image file is "disk0:hfr-os-mbi-3.6.2/mbihfr-rp.vm" cisco CRS-8/S (7457) processor with 4194304K bytes of memory. 7457 processor at 1197Mhz, Revision 1.2 17 Packet over SONET/SDH network interface(s) 1 DWDM controller(s) 17 SONET/SDH Port controller(s) 8 TenGigabitEthernet/IEEE 802.3 interface(s) 2 Ethernet/IEEE 802.3 interface(s) 1019k bytes of non-volatile configuration memory. 38079M bytes of hard disk. 981440k bytes of ATA PCMCIA card at disk 0 (Sector size 512 bytes). Configuration register on node 0/0/CPU0 is 0x102 Boot device on node 0/0/CPU0 is mem: !--- output truncated The following example identifies a Cisco 12404 router that is running Cisco IOS XR Software Release 3.7.1: RP/0/0/CPU0:GSR#show version Cisco IOS XR Software, Version 3.7.1[00] Copyright (c) 2008 by Cisco Systems, Inc. ROM: System Bootstrap, Version 12.0(20051020:160303) SOFTWARE Copyright (c) 1994-2005 by cisco Systems, Inc. GSR uptime is 3 weeks, 6 days, 3 hours, 20 minutes System image file is "disk0:c12k-os-mbi-3.7.1/mbiprp-rp.vm" cisco 12404/PRP (7457) processor with 2097152K bytes of memory. 7457 processor at 1266Mhz, Revision 1.2 1 Cisco 12000 Series Performance Route Processor 1 Cisco 12000 Series - Multi-Service Blade Controller 1 1 Port ISE Packet Over SONET OC-48c/STM-16 Controller (1 POS) 1 Cisco 12000 Series SPA Interface Processor-601/501/401 3 Ethernet/IEEE 802.3 interface(s) 1 SONET/SDH Port controller(s) 1 Packet over SONET/SDH network interface(s) 4 PLIM QoS controller(s) 8 FastEthernet/IEEE 802.3 interface(s) 1016k bytes of non-volatile configuration memory. 1000496k bytes of disk0: (Sector size 512 bytes). 65536k bytes of Flash internal SIMM (Sector size 256k). Configuration register on node 0/0/CPU0 is 0x2102 Boot device on node 0/0/CPU0 is disk0: !--- output truncated Additional information about Cisco IOS XR software release naming conventions is available in the "White Paper: Cisco IOS Reference Guide" at the following link: http://www.cisco.com/warp/public/620/1.html#t6 Additional information about Cisco IOS XR software time-based release model is available in the "White Paper: Guidelines for Cisco IOS XR Software" at the following link: http://www.cisco.com/en/US/prod/collateral/iosswrel/ps8803/ps5845/product_bulletin_c25-478699.html BGP is configured in Cisco IOS XR software with the configuration command router bgp [AS Number] or router bgp [X.Y]. The device is vulnerable if it is running affected Cisco IOS XR version and has BGP configured. The following example shows a Cisco IOS XR software device configured with BGP: RP/0/0/CPU0:GSR#show running-config | begin router bgp Building configuration... router bgp 65535 bgp router-id 192.168.0.1 address-family ipv4 unicast network 192.168.1.1/32 ! address-family vpnv4 unicast ! neighbor 192.168.2.1 remote-as 65534 update-source Loopback0 address-family ipv4 unicast ! !--- output truncated Products Confirmed Not Vulnerable +-------------------------------- The following Cisco products are confirmed not vulnerable: * Cisco IOS Software * Cisco IOS XR Software prior to release 3.4.0 * Cisco IOS XR Software not configured for BGP routing No other Cisco products are currently known to be affected by this vulnerability. Details ======= On August 17th, 2009, a widely-distributed Border Gateway Protocol (BGP) route update contained an BGP Update message with a specific invalid attribute. When the invalid BGP Update message was processed by Cisco IOS XR software, it began resetting BGP peering sessions over which the update was received. When receiving the invalid update the receiving Cisco IOS XR software device will display a log message like the following example: RP/0/RP0/CPU0:Aug 17 13:47:05.896 GMT: bgp[122]: %ROUTING-BGP-5-ADJCHANGE : neighbor 192.168.0.1 Down - BGP Notification sent: invalid or corrupt AS path The peering session will flap until the sender stops sending the invalid/corrupt prefix. This vulnerability is documented in Cisco Bug ID CSCtb42995 ( registered customers only) and has been assigned Common Vulnerabilities and Exposures (CVE) ID CVE-2009-2055. Vulnerability Scoring Details ============================= Cisco has provided scores for the vulnerability in this advisory based on the Common Vulnerability Scoring System (CVSS). The CVSS scoring in this Security Advisory is done in accordance with CVSS version 2.0. CVSS is a standards-based scoring method that conveys vulnerability severity and helps determine urgency and priority of response. Cisco has provided a base and temporal score. Customers can then compute environmental scores to assist in determining the impact of the vulnerability in individual networks. Cisco has provided an FAQ to answer additional questions regarding CVSS at http://www.cisco.com/web/about/security/intelligence/cvss-qandas.html Cisco has also provided a CVSS calculator to help compute the environmental impact for individual networks at http://intellishield.cisco.com/security/alertmanager/cvss CSCtb42995 - Cisco IOS XR Software Border Gateway Protocol Vulnerability +----------------------------------------------------- CVSS Base Score - 4.3 Access Vector - Network Access Complexity - Medium Authentication - None Confidentiality Impact - None Integrity Impact - None Availability Impact - Partial CVSS Temporal Score - 3.9 Exploitability - Functional Remediation Level - Unavailable Report Confidence - Confirmed Impact ====== Successful exploitation of the vulnerability may result in BGP peering sessions continuously being reset. This may lead to routing inconsistencies and a denial of service for those affected networks. Software Versions and Fixes =========================== When considering software upgrades, also consult http://www.cisco.com/go/psirt and any subsequent advisories to determine exposure and a complete upgrade solution. In all cases, customers should exercise caution to be certain the devices to be upgraded contain sufficient memory and that current hardware and software configurations will continue to be supported properly by the new release. If the information is not clear, contact the Cisco Technical Assistance Center (TAC) or your contracted maintenance provider for assistance. +---------------------------------------+ | Cisco IOS XR Version | SMU ID | |----------------------+----------------| | 3.2.X | Not Vulnerable | |----------------------+----------------| | 3.3.X | Not vulnerable | |----------------------+----------------| | 3.4.0 | Pending | |----------------------+----------------| | 3.4.1 | Pending | |----------------------+----------------| | 3.4.2 | Pending | |----------------------+----------------| | 3.4.3 | Pending | |----------------------+----------------| | 3.5.2 | Pending | |----------------------+----------------| | 3.5.3 | Pending | |----------------------+----------------| | 3.5.4 | Pending | |----------------------+----------------| | 3.6.0 | Pending | |----------------------+----------------| | 3.6.1 | Pending | |----------------------+----------------| | 3.6.2 | Pending | |----------------------+----------------| | 3.6.3 | Pending | |----------------------+----------------| | 3.7.0 | Pending | |----------------------+----------------| | 3.7.1 | Pending | |----------------------+----------------| | 3.7.2 | Pending | |----------------------+----------------| | 3.7.3 | Pending | |----------------------+----------------| | 3.8.0 | Pending | |----------------------+----------------| | 3.8.1 | Pending | +---------------------------------------+ Workarounds =========== There are no workarounds on the affected device itself. Co-ordination is required with the peering neighbor support staff to filter the invalid update on their outbound path. The following procedure explains how to help mitigate this vulnerability: Using the peer IP address in the log message that was generated when the Cisco IOS XR software device received the invalid update; capture the notification message hex dump from the CLI command show bgp neighbor and contact the Cisco TAC whom can assist with a decode. Details on how to contact Cisco TAC are contained within the section "Obtaining Fixed Software" of this advisory. The following example show an example generated log message when receiving the invalid update, and the details to be captured to be sent to the Cisco TAC for decoding: Log message generated when receiving invalid update: RP/0/RP0/CPU0:Aug 17 13:47:05.896 GMT: bgp[122]: %ROUTING-BGP-5-ADJCHANGE : neighbor 192.168.0.1 Down - BGP Notification sent: invalid or corrupt AS path Information to capture for decoding by the Cisco TAC, is the output from show bgp neighbors [ip address of neighbor from above log message]. RP/0/RP0/CPU0:CRS#show bgp neighbors 192.168.0.1 Working with Cisco TAC, the decode of the above will display the AS path in a manner illustrated below. ATTRIBUTE NAME: AS_PATH AS_PATH: Type 2 is AS_SEQUENCE AS_PATH: Segment Length is 4 (0x04) segments long AS_PATH: 65533 65532 65531 65531 Working cooperatively with your peering partner, request that they filter outbound prefix advertisements from the identified source AS (in this example 65531) for your peering session. The filters configuration methods will vary depending on the routing device operating system used. For Cisco IOS XR the filters will be applied using Routing Policy Language (RPL) policies or with Cisco IOS software via applying route-maps that deny advertisements matching that AS in their AS-PATH. Once these policies are applied, the peering session will be re-established. For further information on Cisco IOS XR RPL consult the document "Implementing Routing Policy on Cisco IOS XR Software" at the following link: http://www.cisco.com/en/US/docs/ios_xr_sw/iosxr_r3.0/routing/configuration/guide/rc3rpl.html#wp1118699 For further information on Cisco IOS route maps with BGP, consult the document "Cisco IOS BGP Configuration Guide, Release 12.4T" at the following link: http://www.cisco.com/en/US/docs/ios/12_2sr/12_2srb/feature/guide/tbgp_c.html Obtaining Fixed Software ======================== Cisco will be releasing free software updates that address this vulnerability. Prior to deploying software, customers should consult their maintenance provider or check the software for feature set compatibility and known issues specific to their environment. Customers may only install and expect support for the feature sets they have purchased. By installing, downloading, accessing or otherwise using such software upgrades, customers agree to be bound by the terms of Cisco's software license terms found at http://www.cisco.com/en/US/docs/general/warranty/English/EU1KEN_.html or as otherwise set forth at Cisco.com Downloads at http://www.cisco.com/public/sw-center/sw-usingswc.shtml Do not contact psirt at cisco.com or security-alert at cisco.com for software upgrades. Customers with Service Contracts +------------------------------- Customers with contracts should obtain upgraded software through their regular update channels. For most customers, this means that upgrades should be obtained through the Software Center on Cisco's worldwide website at http://www.cisco.com. Customers using Third Party Support Organizations +------------------------------------------------ Customers whose Cisco products are provided or maintained through prior or existing agreements with third-party support organizations, such as Cisco Partners, authorized resellers, or service providers should contact that support organization for guidance and assistance with the appropriate course of action in regards to this advisory. The effectiveness of any workaround or fix is dependent on specific customer situations, such as product mix, network topology, traffic behavior, and organizational mission. Due to the variety of affected products and releases, customers should consult with their service provider or support organization to ensure any applied workaround or fix is the most appropriate for use in the intended network before it is deployed. Customers without Service Contracts +---------------------------------- Customers who purchase direct from Cisco but do not hold a Cisco service contract, and customers who purchase through third-party vendors but are unsuccessful in obtaining fixed software through their point of sale should acquire upgrades by contacting the Cisco Technical Assistance Center (TAC). TAC contacts are as follows. * +1 800 553 2447 (toll free from within North America) * +1 408 526 7209 (toll call from anywhere in the world) * e-mail: tac at cisco.com Customers should have their product serial number available and be prepared to give the URL of this notice as evidence of entitlement to a free upgrade. Free upgrades for non-contract customers must be requested through the TAC. Refer to http://www.cisco.com/en/US/support/tsd_cisco_worldwide_contacts.html for additional TAC contact information, including localized telephone numbers, and instructions and e-mail addresses for use in various languages. Exploitation and Public Announcements ===================================== On August 17, 2009 around 16:30-17:00 UTC several ISP's began experiencing connectivity issues as BGP sessions were being repeatedly reset. Cisco TAC was engaged with a number of customers all seeing similar issues. Stability came a few hours afterward as workarounds were applied. At this time, it is not believed that the connectivity issues were the result of malicious activity. Status of this Notice: INTERIM ============================== THIS DOCUMENT IS PROVIDED ON AN "AS IS" BASIS AND DOES NOT IMPLY ANY KIND OF GUARANTEE OR WARRANTY, INCLUDING THE WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR USE. YOUR USE OF THE INFORMATION ON THE DOCUMENT OR MATERIALS LINKED FROM THE DOCUMENT IS AT YOUR OWN RISK. CISCO RESERVES THE RIGHT TO CHANGE OR UPDATE THIS DOCUMENT AT ANY TIME. CISCO EXPECTS TO UPDATE THIS DOCUMENT AS NEW INFORMATION BECOMES AVAILABLE. A stand-alone copy or Paraphrase of the text of this document that omits the distribution URL in the following section is an uncontrolled copy, and may lack important information or contain factual errors. Distribution ============ This advisory is posted on Cisco's worldwide website at : http://www.cisco.com/warp/public/707/cisco-sa-20090818-bgp.shtml In addition to worldwide web posting, a text version of this notice is clear-signed with the Cisco PSIRT PGP key and is posted to the following e-mail and Usenet news recipients. * cust-security-announce at cisco.com * first-bulletins at lists.first.org * bugtraq at securityfocus.com * vulnwatch at vulnwatch.org * cisco at spot.colorado.edu * cisco-nsp at puck.nether.net * full-disclosure at lists.grok.org.uk * comp.dcom.sys.cisco at newsgate.cisco.com Future updates of this advisory, if any, will be placed on Cisco's worldwide website, but may or may not be actively announced on mailing lists or newsgroups. Users concerned about this problem are encouraged to check the above URL for any updates. Revision History ================ +---------------------------------------+ | Revision | | Initial | | 1.0 | 2009-August-18 | public | | | | release. | +---------------------------------------+ Cisco Security Procedures ========================= Complete information on reporting security vulnerabilities in Cisco products, obtaining assistance with security incidents, and registering to receive security information from Cisco, is available on Cisco's worldwide website at http://www.cisco.com/en/US/products/products_security_vulnerability_policy.html This includes instructions for press inquiries regarding Cisco security notices. All Cisco security advisories are available at http://www.cisco.com/go/psirt - --------------------------------------------------------------------- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iD8DBQFKitOJ86n/Gc8U/uARAlpUAJ95EA/XmiFntl4XuXpKTpqeIt5q8gCfdOPV /OmnNTdlD9lueFh99gS6NDM= =dejJ -----END PGP SIGNATURE----- From dylan.ebner at crlmed.com Tue Aug 18 12:54:10 2009 From: dylan.ebner at crlmed.com (Dylan Ebner) Date: Tue, 18 Aug 2009 17:54:10 +0000 Subject: Anyone else seeing "(invalid or corrupt AS path) 3 bytes E01100" ? In-Reply-To: <000901ca1fd6$ba47a3c0$0a00000a@nil.si> References: <6348c7fd0908171311h2936e6bfifcfd684205befbaf@mail.gmail.com> <000901ca1fd6$ba47a3c0$0a00000a@nil.si> Message-ID: <017265BF3B9640499754DD48777C3D2066129B978A@MBX9.EXCHPROD.USA.NET> Ivan- Thanks for posting this how-to on excessive as prepends. I have a couple of questions that some of the less BGP savvy out their may find helpfull 1. In my enviornment, we are not doing full routes. We have partial routes from AS209 and then fail to AS7263. Is their any advantage for someone like me to do this, as we are not providing any IP transit so we are not passing the route table to anyone else? 2. When I run the "sh ip bgp quote-regexp "_([0-9]+)_\1_\1_\1_\1_ \1_" | begin Network" I am seeing many many ASes that would be filtered by this access-list. What happens to those networks, are they unreachable from my AS, or do I just route those networks to my upstream provider and let them deal with it? 3. This last question is a little OT, but relates to your access list In the event of some kind if DOS attack coming from one of a few AS numbers (in this case we will use 14793), what is the feesability of using ip as-path access-list 100 deny _([0-9]+)_\1_\1_\1_\1_ ip as-path access-list 100 deny 14793 ip as-path access-list 100 permit .* Would this have any affect at all, or would my pipe from my upstream still be congested with garbage traffic ? Thanks Dylan Ebner -----Original Message----- From: Ivan Pepelnjak [mailto:ip at ioshints.info] Sent: Tuesday, August 18, 2009 2:37 AM To: 'randal k'; 'Adam Hebert' Cc: nanog at nanog.org Subject: RE: Anyone else seeing "(invalid or corrupt AS path) 3 bytes E01100" ? > Anybody have a handy route-map that will deny anything with a as-path > longer than say 15-20? ;-) http://wiki.nil.com/Filter_excessively_prepended_BGP_paths Ivan http://www.ioshints.info/about http://blog.ioshints.info/ From ip at ioshints.info Tue Aug 18 13:58:00 2009 From: ip at ioshints.info (Ivan Pepelnjak) Date: Tue, 18 Aug 2009 20:58:00 +0200 Subject: Anyone else seeing "(invalid or corrupt AS path) 3 bytes E01100" ? In-Reply-To: <017265BF3B9640499754DD48777C3D2066129B978A@MBX9.EXCHPROD.USA.NET> References: <6348c7fd0908171311h2936e6bfifcfd684205befbaf@mail.gmail.com> <000901ca1fd6$ba47a3c0$0a00000a@nil.si> <017265BF3B9640499754DD48777C3D2066129B978A@MBX9.EXCHPROD.USA.NET> Message-ID: <000901ca2035$cfcc03d0$0a00000a@nil.si> > Ivan- > Thanks for posting this how-to on excessive as prepends. I > have a couple of questions that some of the less BGP savvy > out their may find helpfull > > 1. In my enviornment, we are not doing full routes. We have > partial routes from AS209 and then fail to AS7263. Is their > any advantage for someone like me to do this, as we are not > providing any IP transit so we are not passing the route > table to anyone else? You could do it to protect your BGP table, but as you're not a transit AS, it does not make much sense. > 2. When I run the "sh ip bgp quote-regexp > "_([0-9]+)_\1_\1_\1_\1_ \1_" | begin Network" I am seeing > many many ASes that would be filtered by this access-list. Obviously a lot of people are prepend-happy. > What happens to those networks, are they unreachable from my > AS, or do I just route those networks to my upstream provider > and let them deal with it? If I understood correctly, you're using a default route toward AS7263, which means that anything that is not in your BGP table (and consequently your IP routing table) will be sent out of your AS via the default route. If you're getting the paths you're filtering from AS209 that means that more traffic will go to AS7263. > 3. This last question is a little OT, but relates to your access list > In the event of some kind if DOS attack coming from one of > a few AS numbers (in this case we will use 14793), what is > the feesability of using > ip as-path access-list 100 deny _([0-9]+)_\1_\1_\1_\1_ > ip as-path access-list 100 deny 14793 > ip as-path access-list 100 permit .* > > Would this have any affect at all, or would my pipe from my > upstream still be congested with garbage traffic ? No. You cannot influence the inbound traffic apart from not advertising some of your prefixes to some of your neighbors or giving them hints with BGP communities or AS-path prepending. Whatever you do with BGP on your routers influences only the paths the outbound traffic is taking. What you'd actually need is remote-triggered black hole. Search the Nanog archives for RTBH, you'll find a number of links in a message from Frank Bulk sent a few days ago. Hope this helps Ivan http://www.ioshints.info/about http://blog.ioshints.info/ From dylan.ebner at crlmed.com Tue Aug 18 14:23:47 2009 From: dylan.ebner at crlmed.com (Dylan Ebner) Date: Tue, 18 Aug 2009 19:23:47 +0000 Subject: Anyone else seeing "(invalid or corrupt AS path) 3 bytes E01100" ? In-Reply-To: <000901ca2035$cfcc03d0$0a00000a@nil.si> References: <6348c7fd0908171311h2936e6bfifcfd684205befbaf@mail.gmail.com> <000901ca1fd6$ba47a3c0$0a00000a@nil.si> <017265BF3B9640499754DD48777C3D2066129B978A@MBX9.EXCHPROD.USA.NET> <000901ca2035$cfcc03d0$0a00000a@nil.si> Message-ID: <017265BF3B9640499754DD48777C3D2066129B9877@MBX9.EXCHPROD.USA.NET> Ivan- This helps vey much. Thanks Dylan Ebner -----Original Message----- From: Ivan Pepelnjak [mailto:ip at ioshints.info] Sent: Tuesday, August 18, 2009 1:58 PM To: Dylan Ebner; 'randal k'; 'Adam Hebert' Cc: nanog at nanog.org Subject: RE: Anyone else seeing "(invalid or corrupt AS path) 3 bytes E01100" ? > Ivan- > Thanks for posting this how-to on excessive as prepends. I have a > couple of questions that some of the less BGP savvy out their may find > helpfull > > 1. In my enviornment, we are not doing full routes. We have partial > routes from AS209 and then fail to AS7263. Is their any advantage for > someone like me to do this, as we are not providing any IP transit so > we are not passing the route table to anyone else? You could do it to protect your BGP table, but as you're not a transit AS, it does not make much sense. > 2. When I run the "sh ip bgp quote-regexp "_([0-9]+)_\1_\1_\1_\1_ \1_" > | begin Network" I am seeing many many ASes that would be filtered by > this access-list. Obviously a lot of people are prepend-happy. > What happens to those networks, are they unreachable from my AS, or do > I just route those networks to my upstream provider and let them deal > with it? If I understood correctly, you're using a default route toward AS7263, which means that anything that is not in your BGP table (and consequently your IP routing table) will be sent out of your AS via the default route. If you're getting the paths you're filtering from AS209 that means that more traffic will go to AS7263. > 3. This last question is a little OT, but relates to your access list > In the event of some kind if DOS attack coming from one of a few AS > numbers (in this case we will use 14793), what is the feesability of > using ip as-path access-list 100 deny _([0-9]+)_\1_\1_\1_\1_ ip > as-path access-list 100 deny 14793 ip as-path access-list 100 permit > .* > > Would this have any affect at all, or would my pipe from my upstream > still be congested with garbage traffic ? No. You cannot influence the inbound traffic apart from not advertising some of your prefixes to some of your neighbors or giving them hints with BGP communities or AS-path prepending. Whatever you do with BGP on your routers influences only the paths the outbound traffic is taking. What you'd actually need is remote-triggered black hole. Search the Nanog archives for RTBH, you'll find a number of links in a message from Frank Bulk sent a few days ago. Hope this helps Ivan http://www.ioshints.info/about http://blog.ioshints.info/ From cluestore at gmail.com Wed Aug 19 10:12:51 2009 From: cluestore at gmail.com (Clue Store) Date: Wed, 19 Aug 2009 10:12:51 -0500 Subject: OSPF vs IS-IS vs PrivateAS eBGP Message-ID: <580af3b90908190812q72a55910w910b9e07327a9e2@mail.gmail.com> Hi All, I know this has been discussed probably many times on this list, but I was looking for some specifics about what others are doing in the following situations. I would like to run an IGP (currently OSPF) to our customers that are multi-homed in a non-mpls environment. They are multi-homed with small prefixes that are swipped from my ARIN allocations. OSPF has been flaky at best under certain conditions and I am thinking of making the move to IS-IS. I have also seen others going to private AS and running eBGP. This seems a bit much, but if it works, i'd make the move to it as I like bgp the most (all of the BGP knobs give me the warm and fuzzies :). I'd also like to see what folks are using in a MPLS network?? OSPFv3 or IS-IS or right to MP-BGP and redist static from the CE to PE??? On and off list are welcome. I'll make a summary after I gather the info. Thanks, Clue From cluestore at gmail.com Wed Aug 19 10:21:45 2009 From: cluestore at gmail.com (Clue Store) Date: Wed, 19 Aug 2009 10:21:45 -0500 Subject: OSPF vs IS-IS vs PrivateAS eBGP In-Reply-To: <580af3b90908190812q72a55910w910b9e07327a9e2@mail.gmail.com> References: <580af3b90908190812q72a55910w910b9e07327a9e2@mail.gmail.com> Message-ID: <580af3b90908190821r52c0af3ehe073c529571c57e1@mail.gmail.com> Sorry, not OSPFv3. IPv6 thoughts dancing in my head. OSPF-VRF as most of you probably interpret. On Wed, Aug 19, 2009 at 10:12 AM, Clue Store wrote: > Hi All, > > I know this has been discussed probably many times on this list, but I was > looking for some specifics about what others are doing in the following > situations. > > I would like to run an IGP (currently OSPF) to our customers that are > multi-homed in a non-mpls environment. They are multi-homed with small > prefixes that are swipped from my ARIN allocations. OSPF has been flaky at > best under certain conditions and I am thinking of making the move to IS-IS. > I have also seen others going to private AS and running eBGP. This seems a > bit much, but if it works, i'd make the move to it as I like bgp the most > (all of the BGP knobs give me the warm and fuzzies :). > > I'd also like to see what folks are using in a MPLS network?? OSPFv3 or > IS-IS or right to MP-BGP and redist static from the CE to PE??? > > On and off list are welcome. I'll make a summary after I gather the info. > > Thanks, > Clue > From jbates at brightok.net Wed Aug 19 11:45:02 2009 From: jbates at brightok.net (Jack Bates) Date: Wed, 19 Aug 2009 11:45:02 -0500 Subject: OSPF vs IS-IS vs PrivateAS eBGP In-Reply-To: <580af3b90908190812q72a55910w910b9e07327a9e2@mail.gmail.com> References: <580af3b90908190812q72a55910w910b9e07327a9e2@mail.gmail.com> Message-ID: <4A8C2C0E.5090206@brightok.net> Clue Store wrote: > I have also seen others going to private AS and running eBGP. This seems a > bit much, but if it works, i'd make the move to it as I like bgp the most > (all of the BGP knobs give me the warm and fuzzies :). > Upon previous advice I've received from large ISPs, I shifted to ISIS to strictly handle internal links and loopbacks which are stable in a single area and use iBGP/eBGP for everything else. While not currently using MPLS (size, topology, and customer demand don't warrant it), it's nice to have the foundations already in place. Shifting IGPs is annoying, especially given we previously had everything in the IGP. The only perk I saw with OSPF was future development of supporting MPLS across multiple areas. ISIS just seemed to suit my needs better. Jack From nick at foobar.org Wed Aug 19 12:01:02 2009 From: nick at foobar.org (Nick Hilliard) Date: Wed, 19 Aug 2009 18:01:02 +0100 Subject: OSPF vs IS-IS vs PrivateAS eBGP In-Reply-To: <580af3b90908190812q72a55910w910b9e07327a9e2@mail.gmail.com> References: <580af3b90908190812q72a55910w910b9e07327a9e2@mail.gmail.com> Message-ID: <4A8C2FCE.3070200@foobar.org> On 19/08/2009 16:12, Clue Store wrote: > I would like to run an IGP (currently OSPF) to our customers that are > multi-homed in a non-mpls environment. Unless you want your customers to have very substantial control over your internal network, don't use an SPF IGP like ospf or is-is. You really want to use BGP for this and private ASNs are fine - that's what they are there for. Nick From scott at dwc-computer.com Wed Aug 19 12:12:40 2009 From: scott at dwc-computer.com (Scott Spencer) Date: Wed, 19 Aug 2009 11:12:40 -0600 Subject: F5/Cisco catalyst configuration question Message-ID: Trying to link an F5 Local Traffic Manager with a Cisco Catalyst 6500 , have matched ports (speed,duplex ect..) but no link light at all on the F5. Does link with a Cisco 2950 switch in between but I need a direct connection with the 6500. Any suggestions what to try? Best regards, Scott Spencer Data Center Asset Recovery/Remarketing Manager Duane Whitlow & Co. Inc. Nationwide Toll Free: 800.977.7473. Direct: 972.865.1395 Fax: 972.931.3340 scott at dwc-computer.com www.dwc-it.com Cisco/Juniper/F5/Foundry/Brocade/Sun/IBM/Dell/Liebert and more ~ From Christopher.Greves at mindspark.com Wed Aug 19 12:41:11 2009 From: Christopher.Greves at mindspark.com (Christopher Greves) Date: Wed, 19 Aug 2009 13:41:11 -0400 Subject: F5/Cisco catalyst configuration question In-Reply-To: References: Message-ID: <7CC9F803BE7E0644A6219521B951AE380478D4F186@s003mb01.staff.iaccap.com> Scott, We've had issues in the past with IOS 6500's auto-negotiating uplink ports with an LTM into ISL Trunk mode. This only occurred when we had the port on the LTM configured as a tagged interface. It was easily solved by forcing the port on the 6500 into dot1q encapsulation. I'm not sure this necessarily explains why you aren't seeing a link light on the LTM though. I can't remember what the interface status was on both sides. This does correlate to why it's working on the 2950's as they don't support ISL and would likely negotiate into dot1q. Chris Christopher Greves? |??Senior Systems Engineer One North Lexington Ave, 9th Floor - White Plains, NY 10601 T?914-826-2067? |? C?914.420.8340? |? E christopher.greves at mindspark.com ? Mindspark Interactive Network, Inc. is an IAC company. -----Original Message----- From: Scott Spencer [mailto:scott at dwc-computer.com] Sent: Wednesday, August 19, 2009 1:13 PM To: nanog at nanog.org Subject: F5/Cisco catalyst configuration question Trying to link an F5 Local Traffic Manager with a Cisco Catalyst 6500 , have matched ports (speed,duplex ect..) but no link light at all on the F5. Does link with a Cisco 2950 switch in between but I need a direct connection with the 6500. Any suggestions what to try? Best regards, Scott Spencer Data Center Asset Recovery/Remarketing Manager Duane Whitlow & Co. Inc. Nationwide Toll Free: 800.977.7473. Direct: 972.865.1395 Fax: 972.931.3340 scott at dwc-computer.com www.dwc-it.com Cisco/Juniper/F5/Foundry/Brocade/Sun/IBM/Dell/Liebert and more ~ From cluestore at gmail.com Wed Aug 19 12:58:01 2009 From: cluestore at gmail.com (Clue Store) Date: Wed, 19 Aug 2009 12:58:01 -0500 Subject: OSPF vs IS-IS vs PrivateAS eBGP In-Reply-To: <4A8C2FCE.3070200@foobar.org> References: <580af3b90908190812q72a55910w910b9e07327a9e2@mail.gmail.com> <4A8C2FCE.3070200@foobar.org> Message-ID: <580af3b90908191058n2a0f867en6691c2381c8ec0f3@mail.gmail.com> Thanks for all the replies so far. Just to clarify, I am in the small ISP/Hosted services business. I was fortunate to inherit the current setup of OSPF to the multi-homed customers. As i stated earlier, I would like to run an IGP, what I really meant was I would like to run a routing protocol that gives me most control as well as the customer and that scales. I am not dead set on running and IGP as IGP in my mind refers to MY internal gateways. and not my customers gateways. eBGP with Private AS is what I would like to go with , but I have had some in the industry say this is not as good as running an IGP with the customer. However, I disagree, but from the looks, this really might just come down to whatever protocol im comfortable with and making sure that it is configured in the correct manor for my situation. As far as my internal connections, I think I will be migrating to IS-IS, but this is not the point of my message to the list, as I am more concerned about customer connections. Keep the opinions coming guys. Clue On Wed, Aug 19, 2009 at 12:01 PM, Nick Hilliard wrote: > On 19/08/2009 16:12, Clue Store wrote: > >> I would like to run an IGP (currently OSPF) to our customers that are >> multi-homed in a non-mpls environment. >> > > Unless you want your customers to have very substantial control over your > internal network, don't use an SPF IGP like ospf or is-is. You really want > to use BGP for this and private ASNs are fine - that's what they are there > for. > > Nick > > From markom at markom.info Wed Aug 19 13:13:17 2009 From: markom at markom.info (Marko Milivojevic) Date: Wed, 19 Aug 2009 18:13:17 +0000 Subject: OSPF vs IS-IS vs PrivateAS eBGP In-Reply-To: <580af3b90908191058n2a0f867en6691c2381c8ec0f3@mail.gmail.com> References: <580af3b90908190812q72a55910w910b9e07327a9e2@mail.gmail.com> <4A8C2FCE.3070200@foobar.org> <580af3b90908191058n2a0f867en6691c2381c8ec0f3@mail.gmail.com> Message-ID: > Keep the opinions coming guys. there are certainly many opinions on this subject. However, the most important factor is - how flexible you wish to be? As you correctly point out, this is not an issue of what protocol are you going to be running inside your network. So, "IGP" is not an issue. The issue at hand is what routing protocol are you going to be running with your customers. The question you should ask yourself is - in what situations are you going to be running routing protocol with customers? In those situations, how are you going to implement things like loop prevention, path selection, load sharing and most importantly - how are you going to be carrying those routes in your network? Now, if you are clear how to do those things and you are comfortable with them in any given scenario - why would you limit yourself to on one thing? You could decide to be very flexible and do "whatever customer prefers", or you could limit yourself to one routing protocol. There are pros and cons in both cases. Personally, I prefer being able to be flexible with customers, but I perfectly understand larger operators wanting to have "standard package" that can be copy/pasted without much risk... -- Marko CCIE #18427 (SP) My network blog: http://cisco.markom.info/ From giesen at snickers.org Wed Aug 19 13:40:49 2009 From: giesen at snickers.org (Gary T. Giesen) Date: Wed, 19 Aug 2009 14:40:49 -0400 Subject: ALTER.NET Issues in Seattle Message-ID: <9a9d0c6a0908191140x14feb04en4de2f1513e9a6df@mail.gmail.com> Seeing issues with Alter.net in Seattle to a Qwest DSL customer in Portland (and looks like a possible routing loop as well) from Calgary: traceroute 63.227.218.201 Type escape sequence to abort. Tracing the route to 63.227.218.201 1 gw-V4051.bb101-2420-1.cgy.akn.ca (209.90.250.33) 0 msec 0 msec 0 msec 2 maxtnt01-sdf-463.fast.net (204.92.61.209) 0 msec 0 msec 0 msec 3 125.at-6-0-0.XT2.CAL1.ALTER.NET (152.63.138.122) 0 msec 0 msec 0 msec 4 POS5-0.BR1.SEA1.ALTER.NET (152.63.105.85) 224 msec 212 msec 200 msec 5 POS5-0.BR1.SEA1.ALTER.NET (152.63.105.85) 188 msec 184 msec 192 msec 6 204.255.169.30 (204.255.169.30) 192 msec 192 msec 196 msec 7 sea-core-02.inet.qwest.net (205.171.26.85) 200 msec 204 msec 204 msec 8 por-core-01.inet.qwest.net (67.14.1.237) 208 msec 212 msec 224 msec 9 ptld-agw1.inet.qwest.net (205.171.130.26) 240 msec 232 msec 236 msec 10 ptld-dsl-gw34-10.ptld.qwest.net (207.225.86.10) 236 msec 244 msec 236 msec 11 x.x.x.x (x.x.x.x) 296 msec * 252 msec Seeing pings jump from 0 ms to 200+ ms at hop 4 (which also appears as hop 5), and is definitely *not* explained by geographical distance. Traceroute from my Toronto POP are fine: traceroute 63.227.218.201 traceroute to 63.227.218.201 (63.227.218.201), 30 hops max, 60 byte packets 1 ge0-1.cyan.akn.ca (66.135.102.132) 1.506 ms 1.498 ms 1.482 ms 2 ge-0-0-3.V4022.smalt.akn.ca (66.135.108.85) 2.198 ms 2.193 ms 2.180 ms 3 te3-5.1244.ccr02.yyz02.atlas.cogentco.com (38.112.93.49) 1.640 ms 1.634 ms 1.624 ms 4 te3-2.ccr01.ord01.atlas.cogentco.com (66.28.4.213) 16.861 ms 16.884 ms te9-8.ccr01.ord01.atlas.cogentco.com (154.54.27.241) 16.890 ms 5 154.54.29.18 (154.54.29.18) 17.594 ms 17.594 ms 17.582 ms 6 qwest.ord03.atlas.cogentco.com (154.54.10.186) 17.001 ms 16.384 ms qwest.ord03.atlas.cogentco.com (154.54.12.106) 16.435 ms 7 cer-core-01.inet.qwest.net (205.171.139.113) 16.480 ms 16.795 ms 16.802 ms 8 por-core-01.inet.qwest.net (67.14.1.237) 72.435 ms 72.472 ms 72.448 ms 9 ptld-agw1.inet.qwest.net (205.171.130.26) 72.502 ms 72.473 ms 72.473 ms 10 ptld-dsl-gw34-10.ptld.qwest.net (207.225.86.10) 72.985 ms 72.958 ms 72.626 ms 11 x.x.x.x (x.x.x.x) 134.030 ms * * Anyone else seeing the same thing? GG From giesen at snickers.org Wed Aug 19 13:50:51 2009 From: giesen at snickers.org (Gary T. Giesen) Date: Wed, 19 Aug 2009 14:50:51 -0400 Subject: ALTER.NET Issues in Seattle In-Reply-To: <9a9d0c6a0908191140x14feb04en4de2f1513e9a6df@mail.gmail.com> References: <9a9d0c6a0908191140x14feb04en4de2f1513e9a6df@mail.gmail.com> Message-ID: <9a9d0c6a0908191150y31be365dw63870b6ac1a6b98@mail.gmail.com> Another note: Seeing > 50% packet loss with 605 byte packets or larger. Anything 604 or under and there's zero packet loss. With or without df-bit set. GG On Wed, Aug 19, 2009 at 2:40 PM, Gary T. Giesen wrote: > Seeing issues with Alter.net in Seattle to a Qwest DSL customer in > Portland (and looks like a possible routing loop as well) from > Calgary: > > traceroute 63.227.218.201 > > Type escape sequence to abort. > Tracing the route to 63.227.218.201 > > ?1 gw-V4051.bb101-2420-1.cgy.akn.ca (209.90.250.33) 0 msec 0 msec 0 msec > ?2 maxtnt01-sdf-463.fast.net (204.92.61.209) 0 msec 0 msec 0 msec > ?3 125.at-6-0-0.XT2.CAL1.ALTER.NET (152.63.138.122) 0 msec 0 msec 0 msec > ?4 POS5-0.BR1.SEA1.ALTER.NET (152.63.105.85) 224 msec 212 msec 200 msec > ?5 POS5-0.BR1.SEA1.ALTER.NET (152.63.105.85) 188 msec 184 msec 192 msec > ?6 204.255.169.30 (204.255.169.30) 192 msec 192 msec 196 msec > ?7 sea-core-02.inet.qwest.net (205.171.26.85) 200 msec 204 msec 204 msec > ?8 por-core-01.inet.qwest.net (67.14.1.237) 208 msec 212 msec 224 msec > ?9 ptld-agw1.inet.qwest.net (205.171.130.26) 240 msec 232 msec 236 msec > ?10 ptld-dsl-gw34-10.ptld.qwest.net (207.225.86.10) 236 msec 244 msec 236 msec > ?11 x.x.x.x (x.x.x.x) 296 msec * ?252 msec > > Seeing pings jump from 0 ms to 200+ ms at hop 4 (which also appears as > hop 5), and is definitely *not* explained by geographical distance. > > > > Traceroute from my Toronto POP are fine: > > traceroute 63.227.218.201 > traceroute to 63.227.218.201 (63.227.218.201), 30 hops max, 60 byte packets > ?1 ?ge0-1.cyan.akn.ca (66.135.102.132) ?1.506 ms ?1.498 ms ?1.482 ms > ?2 ?ge-0-0-3.V4022.smalt.akn.ca (66.135.108.85) ?2.198 ms ?2.193 ms ?2.180 ms > ?3 ?te3-5.1244.ccr02.yyz02.atlas.cogentco.com (38.112.93.49) ?1.640 ms > ?1.634 ms ?1.624 ms > ?4 ?te3-2.ccr01.ord01.atlas.cogentco.com (66.28.4.213) ?16.861 ms > 16.884 ms te9-8.ccr01.ord01.atlas.cogentco.com (154.54.27.241) ?16.890 > ms > ?5 ?154.54.29.18 (154.54.29.18) ?17.594 ms ?17.594 ms ?17.582 ms > ?6 ?qwest.ord03.atlas.cogentco.com (154.54.10.186) ?17.001 ms ?16.384 > ms qwest.ord03.atlas.cogentco.com (154.54.12.106) ?16.435 ms > ?7 ?cer-core-01.inet.qwest.net (205.171.139.113) ?16.480 ms ?16.795 ms > ?16.802 ms > ?8 ?por-core-01.inet.qwest.net (67.14.1.237) ?72.435 ms ?72.472 ms ?72.448 ms > ?9 ?ptld-agw1.inet.qwest.net (205.171.130.26) ?72.502 ms ?72.473 ms ?72.473 ms > 10 ?ptld-dsl-gw34-10.ptld.qwest.net (207.225.86.10) ?72.985 ms ?72.958 > ms ?72.626 ms > 11 ?x.x.x.x (x.x.x.x) ?134.030 ms * * > > > Anyone else seeing the same thing? > > GG > From jlk at thrashyour.com Wed Aug 19 15:02:32 2009 From: jlk at thrashyour.com (John Kinsella) Date: Wed, 19 Aug 2009 13:02:32 -0700 Subject: Fwd: [Full-disclosure] Cisco Security Advisory: Firewall Services Module Crafted ICMP Message Vulnerability References: <200908191315.fwsm@psirt.cisco.com> Message-ID: <4CF2717B-3DE7-445A-9600-7D8F27E0A9A6@thrashyour.com> FYI...I thought PSIRT sent security notices to nanog? Begin forwarded message: > From: Cisco Systems Product Security Incident Response Team > > Date: August 19, 2009 10:12:26 AM PDT > To: full-disclosure at lists.grok.org.uk > Cc: psirt at cisco.com > Subject: [Full-disclosure] Cisco Security Advisory: Firewall > Services Module Crafted ICMP Message Vulnerability > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Cisco Security Advisory: Firewall Services Module Crafted ICMP Message > Vulnerability > > Advisory ID: cisco-sa-20090819-fwsm > > http://www.cisco.com/warp/public/707/cisco-sa-20090819-fwsm.shtml > > Revision 1.0 > > For Public Release 2009 August 19 1600 UTC (GMT) > > Summary > ======= > > A vulnerability exists in the Cisco Firewall Services Module (FWSM) > for > the Catalyst 6500 Series Switches and Cisco 7600 Series Routers. The > vulnerability may cause the FWSM to stop forwarding traffic and may be > triggered while processing multiple, crafted ICMP messages. > > There are no known instances of intentional exploitation of this > vulnerability. However, Cisco has observed data streams that appear to > trigger this vulnerability unintentionally. > > Cisco has released free software updates that address this > vulnerability. > > This advisory is posted at > http://www.cisco.com/warp/public/707/cisco-sa-20090819-fwsm.shtml. > > Affected Products > ================= > > Vulnerable Products > - ------------------- > > All non-fixed 2.x, 3.x and 4.x versions of the FWSM software are > affected by this vulnerability. > > To determine the version of the FWSM software that is running, issue > the "show module" command-line interface (CLI) command from Cisco IOS > Software or Cisco Catalyst Operating System Software to identify what > modules and sub-modules are installed in the system. > > The following example shows a system with an FWSM (WS-SVC-FWM-1) > installed in slot 4. > > switch#show module > Mod Ports Card Type Model > Serial No. > --- ----- -------------------------------------- ----------------- > ----------- > 1 48 SFM-capable 48 port 10/100/1000mb RJ45 WS-X6548-GE-TX > SAxxxxxxxxx > 4 6 Firewall Module WS-SVC-FWM-1 > SAxxxxxxxxx > 5 2 Supervisor Engine 720 (Active) WS-SUP720-BASE > SAxxxxxxxxx > 6 2 Supervisor Engine 720 (Hot) WS-SUP720-BASE > SAxxxxxxxxx > > After locating the correct slot, issue the "show module " > command to identify the software version that is running. > > switch#show module 4 > Mod Ports Card Type Model > Serial No. > --- ----- -------------------------------------- ----------------- > ----------- > 4 6 Firewall Module WS-SVC-FWM-1 > SAxxxxxxxxx > > Mod MAC addresses Hw Fw > Sw Status > --- --------------------------------- ------ ------------ > ------------ ------- > 4 0003.e4xx.xxxx to 0003.e4xx.xxxx 3.0 7.2(1) > 3.2(3) Ok > > The preceding example shows that the FWSM is running software version > 3.2(3) as indicated by the column under "Sw". > > Note: Recent versions of Cisco IOS Software will show the software > version of each module in the output from the "show module" command; > therefore, executing the "show module " command is not > necessary. > > If a Virtual Switching System (VSS) is used to allow two physical > Cisco > Catalyst 6500 Series Switches to operate as a single logical virtual > switch, the "show module switch all" command can display the software > version of all FWSMs that belong to switch 1 and switch 2. The output > from this command will be similar to the output from the "show module > " but will include module information for the modules in > each switch in the VSS. > > Alternatively, version information can be obtained directly from the > FWSM through the "show version" command, as shown in the following > example. > > FWSM#show version > FWSM Firewall Version 3.2(3) > > Customers who use the Cisco Adaptive Security Device Manager (ASDM) to > manage their devices can find the version of the software displayed in > the table in the login window or in the upper left corner of the ASDM > window. The version notation is similar to the following example. > > FWSM Version: 3.2(3) > > Products Confirmed Not Vulnerable > - --------------------------------- > > Other Cisco products that offer firewall services, including Cisco IOS > Software, Cisco ASA 5500 Series Adaptive Security Appliances, and > Cisco > PIX Security Appliances, are not affected by this vulnerability. > > No other Cisco products are currently known to be affected by this > vulnerability. > > Details > ======= > > The Cisco FWSM is a high-speed, integrated firewall module for > Catalyst > 6500 Series Switches and Cisco 7600 Series Routers. The FWSM offers > firewall services with stateful packet filtering and deep packet > inspection. > > A vulnerability exists in the Cisco FWSM Software that may cause > the FWSM to stop forwarding traffic between interfaces, or stop > processing traffic that is directed at the FWSM (management traffic) > after multiple, crafted ICMP messages are processed by the FWSM. Any > traffic that transits or is directed towards the FWSM is affected, > regardless of whether ICMP inspection ("inspect icmp" command under > Class configuration mode) is enabled. > > The FWSM stops processing traffic because one of the Network > Processors > (NPs) that is used by the FWSM to handle traffic may use all available > execution threads while handling a specific type of crafted ICMP > messages. This behavior limits the execution threads that are > available > to handle additional traffic. > > Administrators may be able to determine if the FWSM has been affected > by this vulnerability by issuing the "show np 2 stats" command. If > this > command produces output showing various counters and their values, as > shown in the example CLI output that follows, the FWSM has not been > affected by the vulnerability. If the command returns a single line > that > reads "ERROR: np_logger_query request for FP Stats failed", the FWSM > may > have been affected by the vulnerability. > > FWSM#show np 2 stats > - > ------------------------------------------------------------------------------- > Fast Path 64 bit Global Statistics Counters (NP-2) > > - > ------------------------------------------------------------------------------- > PKT_MNG: total packets (dot1q) rcvd : 10565937 > PKT_MNG: total packets (dot1q) sent : 4969517 > PKT_MNG: total packets (dot1q) dropped : 65502 > PKT_MNG: TCP packets received : 0 > PKT_MNG: UDP packets received : 4963509 > PKT_MNG: ICMP packets received : 0 > PKT_MNG: ARP packets received : 2 > PKT_MNG: other protocol pkts received : 0 > PKT_MNG: default (no IP/ARP) dropped : 0 > SESS_MNG: sessions created : 18 > SESS_MNG: sessions embryonic to active : 0 > [...] > > An FWSM that stops processing traffic as a result of this > vulnerability > will need to be reloaded. Administrators can reload the FWSM from the > supervisor of the Catalyst 6500 Series Switch or the Cisco 7600 Series > Router by issuing the command "hw-module module > reset" > (Cisco IOS Software), or "set module power up| down " (Cisco > CatOS Software). Note that unless the FWSM software is updated to a > non-vulnerable version, or crafted ICMP messages are blocked (see the > Workarounds section for details), the FWSM can still be subject to > exploitation (intentional or otherwise) after a reload. > > If an FWSM that is configured for failover operation encounters this > issue, the active FWSM may not properly fail over to the standby FWSM. > > IPv6 (in particular ICMPv6) cannot trigger this vulnerability. > > This issue is documented in Cisco Bug ID CSCsz97207 and has been > assigned Common Vulnerabilities and Exposures (CVE) ID CVE-2009-0638. > > Vulnerability Scoring Details > +---------------------------- > > Cisco has provided scores for the vulnerability in this advisory based > on the Common Vulnerability Scoring System (CVSS). The CVSS scoring in > this Security Advisory is done in accordance with CVSS version 2.0. > > CVSS is a standards-based scoring method that conveys vulnerability > severity and helps determine urgency and priority of response. > > Cisco has provided a base and temporal score. Customers can then > compute environmental scores to assist in determining the impact of > the > vulnerability in individual networks. > > Cisco has provided a FAQ to answer additional questions regarding CVSS > at: > > http://www.cisco.com/web/about/security/intelligence/cvss-qandas.html > > Cisco has also provided a CVSS calculator to help compute the > environmental impact for individual networks at: > > http://intellishield.cisco.com/security/alertmanager/cvss > > > * NP 2 threads lock due to processing crafted ICMP message > (CSCsz97207) > > CVSS Base Score - 7.8 > Access Vector - Network > Access Complexity - Low > Authentication - None > Confidentiality Impact - None > Integrity Impact - None > Availability Impact - Complete > > CVSS Temporal Score - 6.4 > Exploitability - Functional > Remediation Level - Official-Fix > Report Confidence - Confirmed > > > Impact > ====== > > Successful exploitation of the vulnerability may cause the FWSM to > stop forwarding traffic between interfaces (transit traffic), and stop > processing traffic directed at the FWSM (management traffic). If the > FWSM is configured for failover operation, the active FWSM may not > fail > over to the standby FWSM. > > Software Versions and Fixes > =========================== > > When considering software upgrades, also consult > http://www.cisco.com/go/psirt and any subsequent advisories to > determine > exposure and a complete upgrade solution. > > In all cases, customers should exercise caution to be certain the > devices to be upgraded contain sufficient memory and that current > hardware and software configurations will continue to be supported > properly by the new release. If the information is not clear, contact > the Cisco Technical Assistance Center (TAC) or your contracted > maintenance provider for assistance. > > Each row of the FWSM software table below describes a major FWSM > software train and the earliest possible release within that train > that > contains the fix (the "First Fixed Release") and the anticipated > date of > availability (if not currently available) in the "First Fixed Release" > column. A device running a release that is earlier than the release in > a specific column (less than the First Fixed Release) is known to be > vulnerable. The release should be upgraded at least to the indicated > release or a later version (greater than or equal to the First Fixed > Release label). > > +---------------------------------------+ > | Major | First Fixed Release | > | Release | | > |------------+--------------------------| > | 2.x | Vulnerable; migrate to | > | | 3.x or 4.x | > |------------+--------------------------| > | 3.1 | 3.1(16) | > |------------+--------------------------| > | 3.2 | 3.2(13) | > |------------+--------------------------| > | 4.0 | 4.0(6) | > +---------------------------------------+ > > Fixed FWSM software can be downloaded from the Software Center on > cisco.com by visiting http://www.cisco.com/public/sw-center/ > index.shtml > and navigating to "Security" > "Cisco Catalyst 6500 Series Firewall > Services Module" > "Firewall Services Module (FWSM) Software". > > Workarounds > =========== > > There are no workarounds for this vulnerability. Access control lists > (ACLs) that are deployed on the FWSM itself to block through-the- > device > or to-the-device ICMP messages are not effective to prevent this > vulnerability. However, blocking unnecessary ICMP messages on > screening > devices or on devices in the path to the FWSM will prevent the FWSM > from triggering the vulnerability. For example, the following ACL, > when deployed on a Cisco IOS device in front of the FWSM, will prevent > crafted ICMP messages from reaching the FWSM, and thus protect the > FWSM > from triggering the vulnerability: > > access-list 101 permit icmp any any echo > access-list 101 permit icmp any any echo-reply > access-list 101 permit icmp any any traceroute > access-list 101 permit icmp any any packet-too-big > access-list 101 permit icmp any any time-exceeded > access-list 101 permit icmp any any host-unreachable > access-list 101 permit icmp any any unreachable > access-list 101 deny icmp any any > access-list 101 permit ip any any > > This sample ACL is allowing certain ICMP messages that are vital for > network troubleshooting and for proper operation of the network. It is > safe to allow any other ICMP messages for which the Cisco IOS Software > "access-list" command has named ICMP type keywords. ACLs like the one > in the preceding example may also be deployed on non-Cisco IOS > devices, > such as the Cisco PIX and ASA security appliances, although the ACL > syntax on non-Cisco IOS devices may not support all the named ICMP > type > keywords that the Cisco IOS ACL syntax supports. However, on non-Cisco > IOS devices, it is safe to permit all ICMP messages for which there > are > named ICMP type keywords in the ACL syntax. > > As mentioned in the Details section, if the FWSM has stopped > processing > traffic due to this vulnerability, the FWSM will require a reload. > Administrators can reload the FWSM by logging in to the supervisor > of the Catalyst 6500 Series Switch or the Cisco 7600 Series router > and issuing the "hw-module module reset" (Cisco > IOS Software), or "set module power up|down " (Cisco CatOS > Software) commands. > > Additional mitigations that can be deployed on Cisco devices within > the > network are available in the Cisco Applied Mitigation Bulletin > companion > document for this advisory, which is available at the following link: > > http://www.cisco.com/warp/public/707/cisco-amb-20090819-fwsm.shtml. > > Obtaining Fixed Software > ======================== > > Cisco has released free software updates that address this > vulnerability. Prior to deploying software, customers should consult > their maintenance provider or check the software for feature set > compatibility and known issues specific to their environment. > > Customers may only install and expect support for the feature > sets they have purchased. By installing, downloading, accessing > or otherwise using such software upgrades, customers agree to be > bound by the terms of Cisco's software license terms found at > http://www.cisco.com/en/US/docs/general/warranty/English/EU1KEN_.html, > or as otherwise set forth at Cisco.com Downloads at > http://www.cisco.com/public/sw-center/sw-usingswc.shtml. > > Do not contact psirt at cisco.com or security-alert at cisco.com for > software > upgrades. > > Customers with Service Contracts > - -------------------------------- > > Customers with contracts should obtain upgraded software through their > regular update channels. For most customers, this means that upgrades > should be obtained through the Software Center on Cisco's worldwide > website at http://www.cisco.com. > > Customers using Third Party Support Organizations > - ------------------------------------------------- > > Customers whose Cisco products are provided or maintained through > prior > or existing agreements with third-party support organizations, such > as Cisco Partners, authorized resellers, or service providers should > contact that support organization for guidance and assistance with the > appropriate course of action in regards to this advisory. > > The effectiveness of any workaround or fix is dependent on specific > customer situations, such as product mix, network topology, traffic > behavior, and organizational mission. Due to the variety of affected > products and releases, customers should consult with their service > provider or support organization to ensure any applied workaround or > fix > is the most appropriate for use in the intended network before it is > deployed. > > Customers without Service Contracts > - ----------------------------------- > > Customers who purchase direct from Cisco but do not hold a Cisco > service > contract, and customers who purchase through third-party vendors but > are > unsuccessful in obtaining fixed software through their point of sale > should acquire upgrades by contacting the Cisco Technical Assistance > Center (TAC). TAC contacts are as follows. > > * +1 800 553 2447 (toll free from within North America) > * +1 408 526 7209 (toll call from anywhere in the world) > * e-mail: tac at cisco.com > > Customers should have their product serial number available and be > prepared to give the URL of this notice as evidence of entitlement > to a > free upgrade. Free upgrades for non-contract customers must be > requested > through the TAC. > > Refer to > http://www.cisco.com/en/US/support/tsd_cisco_worldwide_contacts.html > for additional TAC contact information, including localized telephone > numbers, and instructions and e-mail addresses for use in various > languages. > > Exploitation and Public Announcements > ===================================== > > The Cisco PSIRT is not aware of any public announcements or malicious > use of the vulnerability described in this advisory, but Cisco is > aware > of customers that have encountered this vulnerability during normal > network operation. > > This vulnerability was discovered during the handling of customer > support cases. > > Status of this Notice: FINAL > ============================ > > THIS DOCUMENT IS PROVIDED ON AN "AS IS" BASIS AND DOES NOT IMPLY > ANY KIND OF GUARANTEE OR WARRANTY, INCLUDING THE WARRANTIES OF > MERCHANTABILITY OR FITNESS FOR A PARTICULAR USE. YOUR USE OF THE > INFORMATION ON THE DOCUMENT OR MATERIALS LINKED FROM THE DOCUMENT IS > AT YOUR OWN RISK. CISCO RESERVES THE RIGHT TO CHANGE OR UPDATE THIS > DOCUMENT AT ANY TIME. > > A stand-alone copy or Paraphrase of the text of this document that > omits > the distribution URL in the following section is an uncontrolled copy, > and may lack important information or contain factual errors. > > Distribution > ============ > > This advisory is posted on Cisco's worldwide website at: > > http://www.cisco.com/warp/public/707/cisco-sa-20090819-fwsm.shtml > > In addition to worldwide web posting, a text version of this notice is > clear-signed with the Cisco PSIRT PGP key and is posted to the > following > e-mail and Usenet news recipients. > > * cust-security-announce at cisco.com > * first-bulletins at lists.first.org > * bugtraq at securityfocus.com > * vulnwatch at vulnwatch.org > * cisco at spot.colorado.edu > * cisco-nsp at puck.nether.net > * full-disclosure at lists.grok.org.uk > * comp.dcom.sys.cisco at newsgate.cisco.com > > Future updates of this advisory, if any, will be placed on Cisco's > worldwide website, but may or may not be actively announced on mailing > lists or newsgroups. Users concerned about this problem are encouraged > to check the above URL for any updates. > > Revision History > ================ > > +------------------------------------------------------------+ > | Revision 1.0 | 2009-August-19 | Initial public release | > +------------------------------------------------------------+ > > Cisco Security Procedures > ========================= > > Complete information on reporting security vulnerabilities > in Cisco products, obtaining assistance with security > incidents, and registering to receive security information > from Cisco, is available on Cisco's worldwide website at > http://www.cisco.com/en/US/products/products_security_vulnerability_policy.html > . > This includes instructions for press inquiries regarding > Cisco security notices. All Cisco security advisories are available at > http://www.cisco.com/go/psirt. > > +-------------------------------------------------------------------- > Copyright 2008-2009 Cisco Systems, Inc. All rights reserved. > +-------------------------------------------------------------------- > > Updated: Aug 19, 2009 Document ID: 110460 > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (GNU/Linux) > > iEYEARECAAYFAkqMMFYACgkQ86n/Gc8U/uA2jACeLVA38jWbQv4AGpSCvOPVJjgR > NqUAniMoiEUkV/JIDlo1xA0ztaO6jCFR > =2Tm1 > -----END PGP SIGNATURE----- > > _______________________________________________ > Full-Disclosure - We believe in it. > Charter: http://lists.grok.org.uk/full-disclosure-charter.html > Hosted and sponsored by Secunia - http://secunia.com/ From nanog at daork.net Wed Aug 19 16:36:12 2009 From: nanog at daork.net (Nathan Ward) Date: Thu, 20 Aug 2009 09:36:12 +1200 Subject: IPv6 Addressing Help In-Reply-To: <3c3e3fca0908150829x40a0a1f4t8f77d14aca91f3fa@mail.gmail.com> References: <4A857CB3.10600@uplogon.com> <1000BA91-F4CE-4FB2-8997-7C52B4B43739@daork.net> <3c3e3fca0908142138u26d44deby932b874eb3f1aec2@mail.gmail.com> <3c3e3fca0908150829x40a0a1f4t8f77d14aca91f3fa@mail.gmail.com> Message-ID: <9BB3CF9F-3E38-4C4C-850B-44129F073C23@daork.net> On 16/08/2009, at 1:29 AM, William Herrin wrote: > Start with: /32 > Sparsely allocate 200 /56's > > Total remaining space: in excess of /33. In fact, you haven't consumed > a single /48. > Expandability by altering the netmask: to /40 > Largest allocation still possible: only /40 My suggestion was to sparsely allocate /48s to push addresses to POPs (or something topologically relevant to your network, maybe even NASes) as required. So, 200 /56s, sparsely allocated, would still be one /48 (or however many /48s you want to have around your network, as above). Sparse allocation within each of those /48s is also potentially a good idea - case by case. Doesn't make sense on an ADSL pool where everyone has the same length. Makes sense where you're assigning address space to customers who are likely to have different prefix lengths. Sparse allocation of /48s within a /32 has the advantage of letting you grow each area of your address space in each area independently. You can put one /48 in one POP or NAS or something, and 10 in another, without having to break any of your addressing architecture rules. /48s seem flexible enough to me, but perhaps you want to use this technique with /44s or /40s, or something. -- Nathan Ward From darren at bolding.org Wed Aug 19 19:58:04 2009 From: darren at bolding.org (Darren Bolding) Date: Wed, 19 Aug 2009 17:58:04 -0700 Subject: F5/Cisco catalyst configuration question In-Reply-To: <7CC9F803BE7E0644A6219521B951AE380478D4F186@s003mb01.staff.iaccap.com> References: <7CC9F803BE7E0644A6219521B951AE380478D4F186@s003mb01.staff.iaccap.com> Message-ID: <5a318d410908191758p5d76177bq5b2a3d8e89b1d89a@mail.gmail.com> What model BIG-IP? On some models I have had to set the BIG-IP's or the 6500 (can't remember which) to specified speed/duplex and the other side to auto. I believe it was auto on the BIG-IP and fixed on the 6500. Setting both sides the same did not work. On Wed, Aug 19, 2009 at 10:41 AM, Christopher Greves < Christopher.Greves at mindspark.com> wrote: > Scott, > > We've had issues in the past with IOS 6500's auto-negotiating uplink ports > with an LTM into ISL Trunk mode. This only occurred when we had the port on > the LTM configured as a tagged interface. It was easily solved by forcing > the port on the 6500 into dot1q encapsulation. I'm not sure this necessarily > explains why you aren't seeing a link light on the LTM though. I can't > remember what the interface status was on both sides. This does correlate to > why it's working on the 2950's as they don't support ISL and would likely > negotiate into dot1q. > > Chris > > > Christopher Greves | Senior Systems Engineer > One North Lexington Ave, 9th Floor - White Plains, NY 10601 > T 914-826-2067 | C 914.420.8340 | E christopher.greves at mindspark.com > > Mindspark Interactive Network, Inc. is an IAC company. > > > > -----Original Message----- > From: Scott Spencer [mailto:scott at dwc-computer.com] > Sent: Wednesday, August 19, 2009 1:13 PM > To: nanog at nanog.org > Subject: F5/Cisco catalyst configuration question > > Trying to link an F5 Local Traffic Manager with a Cisco Catalyst 6500 , > have > matched ports (speed,duplex ect..) but no link light at all on the F5. Does > link with a Cisco 2950 switch in between but I need a direct connection > with > the 6500. > > Any suggestions what to try? > > Best regards, > > Scott Spencer > Data Center Asset Recovery/Remarketing Manager > Duane Whitlow & Co. Inc. > Nationwide Toll Free: 800.977.7473. Direct: 972.865.1395 Fax: > 972.931.3340 > scott at dwc-computer.com > www.dwc-it.com > Cisco/Juniper/F5/Foundry/Brocade/Sun/IBM/Dell/Liebert and more ~ > > > -- -- Darren Bolding -- -- darren at bolding.org -- From jbates at brightok.net Thu Aug 20 00:04:33 2009 From: jbates at brightok.net (Jack Bates) Date: Thu, 20 Aug 2009 00:04:33 -0500 Subject: IPv6 Addressing Help In-Reply-To: <9BB3CF9F-3E38-4C4C-850B-44129F073C23@daork.net> References: <4A857CB3.10600@uplogon.com> <1000BA91-F4CE-4FB2-8997-7C52B4B43739@daork.net> <3c3e3fca0908142138u26d44deby932b874eb3f1aec2@mail.gmail.com> <3c3e3fca0908150829x40a0a1f4t8f77d14aca91f3fa@mail.gmail.com> <9BB3CF9F-3E38-4C4C-850B-44129F073C23@daork.net> Message-ID: <4A8CD961.4010405@brightok.net> Nathan Ward wrote: > /48s seem flexible enough to me, but perhaps you want to use this > technique with /44s or /40s, or something. Given my unusual network consisting of a dozen different telco's, I actually assign each a /40 at a time, then /44-48 in each of their pops depending on expected growth. I probably could have possibly gone with /36, but then I limit my own allocations to them and I'd like to hope I get more telco's in the future. I do sparse allocation on the /40's to allow smaller routing tables if desired, though. Even for things that don't need nibble boundaries for technical reasons, I usually maintain them for ease of management and scripting. Jack From andy at nosignal.org Thu Aug 20 02:23:59 2009 From: andy at nosignal.org (Andy Davidson) Date: Thu, 20 Aug 2009 08:23:59 +0100 Subject: OSPF vs IS-IS vs PrivateAS eBGP In-Reply-To: <580af3b90908190812q72a55910w910b9e07327a9e2@mail.gmail.com> References: <580af3b90908190812q72a55910w910b9e07327a9e2@mail.gmail.com> Message-ID: <114465A0-4CAD-44D7-94CA-89DE610B0714@nosignal.org> On 19 Aug 2009, at 16:12, Clue Store wrote: > I would like to run an IGP (currently OSPF) to our customers that > are multi-homed in a non-mpls environment. They are multi-homed with > small prefixes that are swipped from my ARIN allocations. [...] Customers do, err, interesting and creative things, in unexpected ways. Develop a standard filtering/protection layer from them and deploy it however they connect to you - ergo use one routing protocol. Using bgp means you can transit people who aren't pinching your own arin space with the same filtering techniques. The filtering methods and techniques for customer/provider edges are well understood and documented for bgp so if you need help, then help is out there. With bgp you'd also leave less of a time bomb for whoever succeed you in the future. This is before we even look at the technical reasons why bgp is more suitable than a flooding RP for this deployment. Use BGP ;-) A From nanog-post at rsuc.gweep.net Thu Aug 20 05:02:11 2009 From: nanog-post at rsuc.gweep.net (Joe Provo) Date: Thu, 20 Aug 2009 06:02:11 -0400 Subject: Anyone else seeing "(invalid or corrupt AS path) 3 bytes E01100" ? In-Reply-To: <000901ca1fd6$ba47a3c0$0a00000a@nil.si> References: <6348c7fd0908171311h2936e6bfifcfd684205befbaf@mail.gmail.com> <000901ca1fd6$ba47a3c0$0a00000a@nil.si> Message-ID: <20090820100211.GA96092@gweep.net> On Tue, Aug 18, 2009 at 09:37:22AM +0200, Ivan Pepelnjak wrote: > > Anybody have a handy route-map that will deny anything with a > > as-path longer than say 15-20? ;-) > > http://wiki.nil.com/Filter_excessively_prepended_BGP_paths It will still be a while before we see unbroken 4byte AS behavior (that whole 'fix the teardown on a anyone sneezing' problem). But like with stale bogon filters, I expect folks inclined to use this to drop it in and forget about it. So it would be wise to adjust the recommended filter to anticipate a 2byteAS view allowing multiple instances of AS-TRANS; there's likely a more elegant approach, but the quick step of explicitly allowing _(23465_)+ before you deny _([0-9]+)_\1_\1_\1_\1_ Cheers, Joe -- RSUC / GweepNet / Spunk / FnB / Usenix / SAGE From randy at psg.com Thu Aug 20 05:06:55 2009 From: randy at psg.com (Randy Bush) Date: Thu, 20 Aug 2009 19:06:55 +0900 Subject: OSPF vs IS-IS vs PrivateAS eBGP In-Reply-To: <4A8C2FCE.3070200@foobar.org> References: <580af3b90908190812q72a55910w910b9e07327a9e2@mail.gmail.com> <4A8C2FCE.3070200@foobar.org> Message-ID: > Unless you want your customers to have very substantial control over > your internal network, don't use an SPF IGP like ospf or is-is. with your customer ^ i know that's what you meant, but i thought it worth making it very explicit. practice safe routing, do not share blood with customer. is-is in core with ibgp, and well-filtered ebgp (and packet filters a la bcp 38) to customers. randy From nanog at daork.net Thu Aug 20 06:52:21 2009 From: nanog at daork.net (Nathan Ward) Date: Thu, 20 Aug 2009 23:52:21 +1200 Subject: Anyone else seeing "(invalid or corrupt AS path) 3 bytes E01100" ? In-Reply-To: <000901ca2035$cfcc03d0$0a00000a@nil.si> References: <6348c7fd0908171311h2936e6bfifcfd684205befbaf@mail.gmail.com> <000901ca1fd6$ba47a3c0$0a00000a@nil.si> <017265BF3B9640499754DD48777C3D2066129B978A@MBX9.EXCHPROD.USA.NET> <000901ca2035$cfcc03d0$0a00000a@nil.si> Message-ID: <1C34AABD-9CE0-4687-81AA-0795176BD47E@daork.net> On 19/08/2009, at 6:58 AM, Ivan Pepelnjak wrote: > No. You cannot influence the inbound traffic apart from not > advertising some > of your prefixes to some of your neighbors or giving them hints with > BGP > communities or AS-path prepending. Whatever you do with BGP on your > routers > influences only the paths the outbound traffic is taking. What you'd > actually need is remote-triggered black hole. Search the Nanog > archives for > RTBH, you'll find a number of links in a message from Frank Bulk > sent a few > days ago. Or, you can prepend your advertisement with the troublesome ASN. Works for one or two troublesome ASNs as a quick hack at 3am - don't do it unless you understand why it works and why you shouldn't do it. -- Nathan Ward From ip at ioshints.info Thu Aug 20 07:13:31 2009 From: ip at ioshints.info (Ivan Pepelnjak) Date: Thu, 20 Aug 2009 14:13:31 +0200 Subject: OSPF vs IS-IS vs PrivateAS eBGP In-Reply-To: <580af3b90908190812q72a55910w910b9e07327a9e2@mail.gmail.com> References: <580af3b90908190812q72a55910w910b9e07327a9e2@mail.gmail.com> Message-ID: <003701ca218f$a2b5bde0$0a00000a@nil.si> Do not EVER run an SPF routing protocol with your customer. They can insert anything they want into it (due to configuration mistake, malicious intent or third-party hijacking) and your whole network (or at least the other customers) will be affected. Just to give you a few examples: * They could hijack the host route to your DNS server and spoof every other customer of yours that uses your DNS * They could hijack the host route to your POP3 server and collect the usernames and passwords of your residential users * Company A could hijack the host route to the web server of company B. * They could insert a better default route than you do and at least some of your routers will listen to them. * If they ever make a total mess and start flapping their LSAs, your whole network will be affected and all your routers will burn CPU running SPF algorithm. If you absolutely insist on not using BGP (but then BGP is the only currently available routing protocol designed to handle routing in scenarios where the two parties don't necessarily trust each other), use RIP. It's safer than OSPF, at least you can filter the incoming updates. Ivan http://www.ioshints.info/about http://blog.ioshints.info/ > -----Original Message----- > From: Clue Store [mailto:cluestore at gmail.com] > Sent: Wednesday, August 19, 2009 5:13 PM > To: nanog at nanog.org > Subject: OSPF vs IS-IS vs PrivateAS eBGP > > Hi All, > > I know this has been discussed probably many times on this > list, but I was looking for some specifics about what others > are doing in the following situations. > > I would like to run an IGP (currently OSPF) to our customers > that are multi-homed in a non-mpls environment. They are > multi-homed with small prefixes that are swipped from my ARIN > allocations. OSPF has been flaky at best under certain > conditions and I am thinking of making the move to IS-IS. > I have also seen others going to private AS and running eBGP. > This seems a bit much, but if it works, i'd make the move to > it as I like bgp the most (all of the BGP knobs give me the > warm and fuzzies :). > > I'd also like to see what folks are using in a MPLS network?? > OSPFv3 or IS-IS or right to MP-BGP and redist static from the > CE to PE??? > > On and off list are welcome. I'll make a summary after I > gather the info. > > Thanks, > Clue > > From rdobbins at arbor.net Thu Aug 20 07:20:02 2009 From: rdobbins at arbor.net (Roland Dobbins) Date: Thu, 20 Aug 2009 19:20:02 +0700 Subject: OSPF vs IS-IS vs PrivateAS eBGP In-Reply-To: <003701ca218f$a2b5bde0$0a00000a@nil.si> References: <580af3b90908190812q72a55910w910b9e07327a9e2@mail.gmail.com> <003701ca218f$a2b5bde0$0a00000a@nil.si> Message-ID: <95A2618D-B09E-4385-B609-F136AE243B8A@arbor.net> On Aug 20, 2009, at 7:13 PM, Ivan Pepelnjak wrote: > Do not EVER run an SPF routing protocol with your customer. I don't generally like 'me, too', posts, but Ivan's advice here cannot be overstated; this way lies madness. ----------------------------------------------------------------------- Roland Dobbins // Unfortunately, inefficiency scales really well. -- Kevin Lawton From nanog-post at rsuc.gweep.net Thu Aug 20 07:21:10 2009 From: nanog-post at rsuc.gweep.net (Joe Provo) Date: Thu, 20 Aug 2009 08:21:10 -0400 Subject: OSPF vs IS-IS vs PrivateAS eBGP In-Reply-To: <580af3b90908191058n2a0f867en6691c2381c8ec0f3@mail.gmail.com> References: <580af3b90908190812q72a55910w910b9e07327a9e2@mail.gmail.com> <4A8C2FCE.3070200@foobar.org> <580af3b90908191058n2a0f867en6691c2381c8ec0f3@mail.gmail.com> Message-ID: <20090820122110.GA64554@gweep.net> On Wed, Aug 19, 2009 at 12:58:01PM -0500, Clue Store wrote: [snip] > would like to go with , but I have had some in the industry say this is not > as good as running an IGP with the customer. Name and shame. TTBOMK, no-one who thought walking that road was a Good Idea did so for long after starting down the path. As far as 'customer choice' goes, the customer is indeed always right when it comes to their *desired goal* in the abstract (multihoming, etc), but rarely if ever in its implementation. Cheers, Joe -- RSUC / GweepNet / Spunk / FnB / Usenix / SAGE From pfs at cisco.com Thu Aug 20 08:26:50 2009 From: pfs at cisco.com (Philip Smith) Date: Thu, 20 Aug 2009 23:26:50 +1000 Subject: OSPF vs IS-IS vs PrivateAS eBGP In-Reply-To: <580af3b90908190812q72a55910w910b9e07327a9e2@mail.gmail.com> References: <580af3b90908190812q72a55910w910b9e07327a9e2@mail.gmail.com> Message-ID: <4A8D4F1A.2000309@cisco.com> Clue Store said the following on 20/8/09 01:12 : > > I know this has been discussed probably many times on this list, but I was > looking for some specifics about what others are doing in the following > situations. Discussed on list, presented in tutorials, how much more advice is actually required? ;-) > I would like to run an IGP (currently OSPF) to our customers that are > multi-homed Several have replied saying "don't ever do this". The I in IGP stands for "interior" - which means "inside" your network, which does not mean "outside" your network. For the latter, we have BGP - if BGP for some reason seems too hard, check out the NANOG tutorials on the subject. Good luck! philip -- From cluestore at gmail.com Thu Aug 20 08:47:14 2009 From: cluestore at gmail.com (Clue Store) Date: Thu, 20 Aug 2009 08:47:14 -0500 Subject: OSPF vs IS-IS vs PrivateAS eBGP In-Reply-To: <4A8D4F1A.2000309@cisco.com> References: <580af3b90908190812q72a55910w910b9e07327a9e2@mail.gmail.com> <4A8D4F1A.2000309@cisco.com> Message-ID: <580af3b90908200647q1d1b5b14ja95e92273f7e71b6@mail.gmail.com> Thanks again for all of the replies on and off list. As I stated earlier, I didn't not think IGP was the protocol of choice for running to customers, i've just been to many different houses that do actually do this. 99% of all of our customer CPE is not managed by the customer, so that leaves it up to me to decide what to run to them. The only issue with using ebgp is getting enough of my staff that actually understand bgp to the point where they can deploy it themselves without having to get me involved on every install. I think I can make this pretty cookie-cutter config to start off and then work from there. We are moving to a new NOC so this network will get a fresh start (new 7513-sup720, few m10i's, and a dozen or so 7200vxr's). So my deployment strategy will be ebgp with multihmed customers. I just had to poke the fire so I had some ammo for upper management when they ask why I decide to go ebgp. And yes Philip, I actually have many of those presentations saved on my drive as they were all for not ;) Once again, thanks all for the replies. Clue On Thu, Aug 20, 2009 at 8:26 AM, Philip Smith wrote: > Clue Store said the following on 20/8/09 01:12 : > > > > I know this has been discussed probably many times on this list, but I > was > > looking for some specifics about what others are doing in the following > > situations. > > Discussed on list, presented in tutorials, how much more advice is > actually required? ;-) > > > I would like to run an IGP (currently OSPF) to our customers that are > > multi-homed > > Several have replied saying "don't ever do this". The I in IGP stands > for "interior" - which means "inside" your network, which does not mean > "outside" your network. For the latter, we have BGP - if BGP for some > reason seems too hard, check out the NANOG tutorials on the subject. > > Good luck! > > philip > -- > From jeff-kell at utc.edu Thu Aug 20 10:50:45 2009 From: jeff-kell at utc.edu (Jeff Kell) Date: Thu, 20 Aug 2009 11:50:45 -0400 Subject: F5/Cisco catalyst configuration question In-Reply-To: <5a318d410908191758p5d76177bq5b2a3d8e89b1d89a@mail.gmail.com> References: <7CC9F803BE7E0644A6219521B951AE380478D4F186@s003mb01.staff.iaccap.com> <5a318d410908191758p5d76177bq5b2a3d8e89b1d89a@mail.gmail.com> Message-ID: <4A8D70D5.10200@utc.edu> Darren Bolding wrote: > What model BIG-IP? > On some models I have had to set the BIG-IP's or the 6500 (can't remember > which) to specified speed/duplex and the other side to auto. > > I believe it was auto on the BIG-IP and fixed on the 6500. > > Setting both sides the same did not work. We have some F5 3400s. No issues with getting link up, but have had issues with etherchannels. Our F5 admin wanted to run LACP, but we have had some issues. 3400 to Cat3750 seems to work okay, doesn't always like both ends 'active' as per Cisco recommended lacp settings. 3400 to Cat3750E we couldn't initially get LACP up in any case, but it maybe have been a flaky switch (had stack port issues), haven't tried again since the replacement. Seems to be fine with raw etherchannel (channel-group xx mode on). Anyone have "smarter" etherchannels running F5-to-Catalysts ? Jeff From scott at dwc-computer.com Thu Aug 20 11:24:15 2009 From: scott at dwc-computer.com (Scott Spencer) Date: Thu, 20 Aug 2009 10:24:15 -0600 Subject: F5/Cisco catalyst configuration question In-Reply-To: <5a318d410908191758p5d76177bq5b2a3d8e89b1d89a@mail.gmail.com> References: <7CC9F803BE7E0644A6219521B951AE380478D4F186@s003mb01.staff.iaccap.com> <5a318d410908191758p5d76177bq5b2a3d8e89b1d89a@mail.gmail.com> Message-ID: Darren, It's the F5-BIG-LTM-6400, pair of them. Thanks for your info. Got alot of good, helpful responses. Best regards, Scott Spencer Data Center Asset Recovery/Remarketing Manager Duane Whitlow & Co. Inc. Nationwide Toll Free: 800.977.7473. Direct: 972.865.1395 Fax: 972.931.3340 scott at dwc-computer.com www.dwc-it.com Cisco/Juniper/F5/Foundry/Brocade/Sun/IBM/Dell/Liebert and more ~ _____ From: packetmonger at gmail.com [mailto:packetmonger at gmail.com] On Behalf Of Darren Bolding Sent: Wednesday, August 19, 2009 6:58 PM To: Christopher Greves Cc: Scott Spencer; nanog at nanog.org Subject: Re: F5/Cisco catalyst configuration question What model BIG-IP? On some models I have had to set the BIG-IP's or the 6500 (can't remember which) to specified speed/duplex and the other side to auto. I believe it was auto on the BIG-IP and fixed on the 6500. Setting both sides the same did not work. On Wed, Aug 19, 2009 at 10:41 AM, Christopher Greves wrote: Scott, We've had issues in the past with IOS 6500's auto-negotiating uplink ports with an LTM into ISL Trunk mode. This only occurred when we had the port on the LTM configured as a tagged interface. It was easily solved by forcing the port on the 6500 into dot1q encapsulation. I'm not sure this necessarily explains why you aren't seeing a link light on the LTM though. I can't remember what the interface status was on both sides. This does correlate to why it's working on the 2950's as they don't support ISL and would likely negotiate into dot1q. Chris Christopher Greves | Senior Systems Engineer One North Lexington Ave, 9th Floor - White Plains, NY 10601 T 914-826-2067 | C 914.420.8340 | E christopher.greves at mindspark.com Mindspark Interactive Network, Inc. is an IAC company. -----Original Message----- From: Scott Spencer [mailto:scott at dwc-computer.com] Sent: Wednesday, August 19, 2009 1:13 PM To: nanog at nanog.org Subject: F5/Cisco catalyst configuration question Trying to link an F5 Local Traffic Manager with a Cisco Catalyst 6500 , have matched ports (speed,duplex ect..) but no link light at all on the F5. Does link with a Cisco 2950 switch in between but I need a direct connection with the 6500. Any suggestions what to try? Best regards, Scott Spencer Data Center Asset Recovery/Remarketing Manager Duane Whitlow & Co. Inc. Nationwide Toll Free: 800.977.7473. Direct: 972.865.1395 Fax: 972.931.3340 scott at dwc-computer.com www.dwc-it.com Cisco/Juniper/F5/Foundry/Brocade/Sun/IBM/Dell/Liebert and more ~ -- -- Darren Bolding -- -- darren at bolding.org -- From dylan.ebner at crlmed.com Thu Aug 20 12:36:19 2009 From: dylan.ebner at crlmed.com (Dylan Ebner) Date: Thu, 20 Aug 2009 17:36:19 +0000 Subject: F5/Cisco catalyst configuration question In-Reply-To: References: <7CC9F803BE7E0644A6219521B951AE380478D4F186@s003mb01.staff.iaccap.com> <5a318d410908191758p5d76177bq5b2a3d8e89b1d89a@mail.gmail.com> Message-ID: <017265BF3B9640499754DD48777C3D206612B7B5E2@MBX9.EXCHPROD.USA.NET> This couldn't be something as simple as a crossover cable, could it? -----Original Message----- From: Scott Spencer [mailto:scott at dwc-computer.com] Sent: Thursday, August 20, 2009 11:24 AM To: 'Darren Bolding'; 'Christopher Greves' Cc: nanog at nanog.org Subject: RE: F5/Cisco catalyst configuration question Darren, It's the F5-BIG-LTM-6400, pair of them. Thanks for your info. Got alot of good, helpful responses. Best regards, Scott Spencer Data Center Asset Recovery/Remarketing Manager Duane Whitlow & Co. Inc. Nationwide Toll Free: 800.977.7473. Direct: 972.865.1395 Fax: 972.931.3340 scott at dwc-computer.com www.dwc-it.com Cisco/Juniper/F5/Foundry/Brocade/Sun/IBM/Dell/Liebert and more ~ _____ From: packetmonger at gmail.com [mailto:packetmonger at gmail.com] On Behalf Of Darren Bolding Sent: Wednesday, August 19, 2009 6:58 PM To: Christopher Greves Cc: Scott Spencer; nanog at nanog.org Subject: Re: F5/Cisco catalyst configuration question What model BIG-IP? On some models I have had to set the BIG-IP's or the 6500 (can't remember which) to specified speed/duplex and the other side to auto. I believe it was auto on the BIG-IP and fixed on the 6500. Setting both sides the same did not work. On Wed, Aug 19, 2009 at 10:41 AM, Christopher Greves wrote: Scott, We've had issues in the past with IOS 6500's auto-negotiating uplink ports with an LTM into ISL Trunk mode. This only occurred when we had the port on the LTM configured as a tagged interface. It was easily solved by forcing the port on the 6500 into dot1q encapsulation. I'm not sure this necessarily explains why you aren't seeing a link light on the LTM though. I can't remember what the interface status was on both sides. This does correlate to why it's working on the 2950's as they don't support ISL and would likely negotiate into dot1q. Chris Christopher Greves | Senior Systems Engineer One North Lexington Ave, 9th Floor - White Plains, NY 10601 T 914-826-2067 | C 914.420.8340 | E christopher.greves at mindspark.com Mindspark Interactive Network, Inc. is an IAC company. -----Original Message----- From: Scott Spencer [mailto:scott at dwc-computer.com] Sent: Wednesday, August 19, 2009 1:13 PM To: nanog at nanog.org Subject: F5/Cisco catalyst configuration question Trying to link an F5 Local Traffic Manager with a Cisco Catalyst 6500 , have matched ports (speed,duplex ect..) but no link light at all on the F5. Does link with a Cisco 2950 switch in between but I need a direct connection with the 6500. Any suggestions what to try? Best regards, Scott Spencer Data Center Asset Recovery/Remarketing Manager Duane Whitlow & Co. Inc. Nationwide Toll Free: 800.977.7473. Direct: 972.865.1395 Fax: 972.931.3340 scott at dwc-computer.com www.dwc-it.com Cisco/Juniper/F5/Foundry/Brocade/Sun/IBM/Dell/Liebert and more ~ -- -- Darren Bolding -- -- darren at bolding.org -- From clowe at intelius.com Thu Aug 20 12:38:18 2009 From: clowe at intelius.com (Chris Lowe) Date: Thu, 20 Aug 2009 10:38:18 -0700 Subject: F5/Cisco catalyst configuration question In-Reply-To: <017265BF3B9640499754DD48777C3D206612B7B5E2@MBX9.EXCHPROD.USA.NET> References: <7CC9F803BE7E0644A6219521B951AE380478D4F186@s003mb01.staff.iaccap.com><5a318d410908191758p5d76177bq5b2a3d8e89b1d89a@mail.gmail.com> <017265BF3B9640499754DD48777C3D206612B7B5E2@MBX9.EXCHPROD.USA.NET> Message-ID: <8E80582D6651CB47BE5B9CE81D63D048020A379D@exchange2.intelius1.intelius.com> That is what I was thinking when I first read your email. I would agree with Darren. CL -----Original Message----- From: Dylan Ebner [mailto:dylan.ebner at crlmed.com] Sent: Thursday, August 20, 2009 10:36 AM To: Scott Spencer; 'Darren Bolding'; 'Christopher Greves' Cc: nanog at nanog.org Subject: RE: F5/Cisco catalyst configuration question This couldn't be something as simple as a crossover cable, could it? -----Original Message----- From: Scott Spencer [mailto:scott at dwc-computer.com] Sent: Thursday, August 20, 2009 11:24 AM To: 'Darren Bolding'; 'Christopher Greves' Cc: nanog at nanog.org Subject: RE: F5/Cisco catalyst configuration question Darren, It's the F5-BIG-LTM-6400, pair of them. Thanks for your info. Got alot of good, helpful responses. Best regards, Scott Spencer Data Center Asset Recovery/Remarketing Manager Duane Whitlow & Co. Inc. Nationwide Toll Free: 800.977.7473. Direct: 972.865.1395 Fax: 972.931.3340 scott at dwc-computer.com www.dwc-it.com Cisco/Juniper/F5/Foundry/Brocade/Sun/IBM/Dell/Liebert and more ~ _____ From: packetmonger at gmail.com [mailto:packetmonger at gmail.com] On Behalf Of Darren Bolding Sent: Wednesday, August 19, 2009 6:58 PM To: Christopher Greves Cc: Scott Spencer; nanog at nanog.org Subject: Re: F5/Cisco catalyst configuration question What model BIG-IP? On some models I have had to set the BIG-IP's or the 6500 (can't remember which) to specified speed/duplex and the other side to auto. I believe it was auto on the BIG-IP and fixed on the 6500. Setting both sides the same did not work. On Wed, Aug 19, 2009 at 10:41 AM, Christopher Greves wrote: Scott, We've had issues in the past with IOS 6500's auto-negotiating uplink ports with an LTM into ISL Trunk mode. This only occurred when we had the port on the LTM configured as a tagged interface. It was easily solved by forcing the port on the 6500 into dot1q encapsulation. I'm not sure this necessarily explains why you aren't seeing a link light on the LTM though. I can't remember what the interface status was on both sides. This does correlate to why it's working on the 2950's as they don't support ISL and would likely negotiate into dot1q. Chris Christopher Greves | Senior Systems Engineer One North Lexington Ave, 9th Floor - White Plains, NY 10601 T 914-826-2067 | C 914.420.8340 | E christopher.greves at mindspark.com Mindspark Interactive Network, Inc. is an IAC company. -----Original Message----- From: Scott Spencer [mailto:scott at dwc-computer.com] Sent: Wednesday, August 19, 2009 1:13 PM To: nanog at nanog.org Subject: F5/Cisco catalyst configuration question Trying to link an F5 Local Traffic Manager with a Cisco Catalyst 6500 , have matched ports (speed,duplex ect..) but no link light at all on the F5. Does link with a Cisco 2950 switch in between but I need a direct connection with the 6500. Any suggestions what to try? Best regards, Scott Spencer Data Center Asset Recovery/Remarketing Manager Duane Whitlow & Co. Inc. Nationwide Toll Free: 800.977.7473. Direct: 972.865.1395 Fax: 972.931.3340 scott at dwc-computer.com www.dwc-it.com Cisco/Juniper/F5/Foundry/Brocade/Sun/IBM/Dell/Liebert and more ~ -- -- Darren Bolding -- -- darren at bolding.org -- From ip at ioshints.info Thu Aug 20 14:30:07 2009 From: ip at ioshints.info (Ivan Pepelnjak) Date: Thu, 20 Aug 2009 21:30:07 +0200 Subject: OSPF vs IS-IS vs PrivateAS eBGP In-Reply-To: <580af3b90908200647q1d1b5b14ja95e92273f7e71b6@mail.gmail.com> References: <580af3b90908190812q72a55910w910b9e07327a9e2@mail.gmail.com><4A8D4F1A.2000309@cisco.com> <580af3b90908200647q1d1b5b14ja95e92273f7e71b6@mail.gmail.com> Message-ID: <006b01ca21cc$a46fb630$0a00000a@nil.si> > The only issue with using ebgp is getting enough of my > staff that actually understand bgp to the point where they > can deploy it themselves without having to get me involved on > every install. I think I can make this pretty cookie-cutter > config to start off and then work from there. For those of them that prefer eye candy to real study :), I've made a few video clips when the weather was really bad last winter and I couldn't go rock climbing ... http://wiki.nil.com/BGP (the "Videos" section") They are targeted at using BGP in MPLS VPN networks, but are useful in other similar scenarios as well. > So my deployment strategy will be ebgp with > multihmed customers. I just had to poke the fire so I had > some ammo for upper management when they ask why I decide to go ebgp. Ah, that was the reason ... You could have told us in advance and my previous reply would have been even more explicit :)) Good luck! Ivan http://www.ioshints.info/about http://blog.ioshints.info/ From ross at kallisti.us Thu Aug 20 15:25:20 2009 From: ross at kallisti.us (Ross Vandegrift) Date: Thu, 20 Aug 2009 16:25:20 -0400 Subject: F5/Cisco catalyst configuration question In-Reply-To: <4A8D70D5.10200@utc.edu> References: <7CC9F803BE7E0644A6219521B951AE380478D4F186@s003mb01.staff.iaccap.com> <5a318d410908191758p5d76177bq5b2a3d8e89b1d89a@mail.gmail.com> <4A8D70D5.10200@utc.edu> Message-ID: <20090820202520.GC8616@kallisti.us> On Thu, Aug 20, 2009 at 11:50:45AM -0400, Jeff Kell wrote: > Anyone have "smarter" etherchannels running F5-to-Catalysts ? Yes, I'm running LACP between SUP-720 6500s and BIG-IP 6900 boxes on the SFP interfaces. The key was to disable ethernet flow control on the BIG-IP side. They enable it by default and it really confuses the Cisco side. After disabling flow control on the BIG-IP's physical interfaces, LACP came up just fine. -- Ross Vandegrift ross at kallisti.us "If the fight gets hot, the songs get hotter. If the going gets tough, the songs get tougher." --Woody Guthrie From giesen at snickers.org Thu Aug 20 15:34:41 2009 From: giesen at snickers.org (Gary T. Giesen) Date: Thu, 20 Aug 2009 16:34:41 -0400 Subject: OSPF vs IS-IS vs PrivateAS eBGP In-Reply-To: <006b01ca21cc$a46fb630$0a00000a@nil.si> References: <580af3b90908190812q72a55910w910b9e07327a9e2@mail.gmail.com> <4A8D4F1A.2000309@cisco.com> <580af3b90908200647q1d1b5b14ja95e92273f7e71b6@mail.gmail.com> <006b01ca21cc$a46fb630$0a00000a@nil.si> Message-ID: <9a9d0c6a0908201334w21ef7f17ka22d6bd2e0b92ac0@mail.gmail.com> FWIW, we use BGP to our multihomed customers (even when we manage the CPE), using a private AS. OSPF doesn't have the right toolset to provide protection for inter-network route propogation, and the risk of some customer's CPE screwing up you routing is just too high to go naked. A basic CPE BGP config is not too difficult to template, and you don't necessarily have to use prefix filters on it (although you definitely need them on YOUR) side. And once you've got it deployed, you'll find the knobs you can turn to do things like TE (ie. data down one pipe, voice down the other, and failover for both) will have both you and your customers loving it. (What? I can actually use that spare circuit that normally does nothing?!?). GG On 8/20/09, Ivan Pepelnjak wrote: >> The only issue with using ebgp is getting enough of my >> staff that actually understand bgp to the point where they >> can deploy it themselves without having to get me involved on >> every install. I think I can make this pretty cookie-cutter >> config to start off and then work from there. > > For those of them that prefer eye candy to real study :), I've made a few > video clips when the weather was really bad last winter and I couldn't go > rock climbing ... > > http://wiki.nil.com/BGP (the "Videos" section") > > They are targeted at using BGP in MPLS VPN networks, but are useful in other > similar scenarios as well. > >> So my deployment strategy will be ebgp with >> multihmed customers. I just had to poke the fire so I had >> some ammo for upper management when they ask why I decide to go ebgp. > > Ah, that was the reason ... You could have told us in advance and my > previous reply would have been even more explicit :)) > > Good luck! > Ivan > > http://www.ioshints.info/about > http://blog.ioshints.info/ > > > From dr at cluenet.de Thu Aug 20 18:26:13 2009 From: dr at cluenet.de (Daniel Roesen) Date: Fri, 21 Aug 2009 01:26:13 +0200 Subject: OSPF vs IS-IS vs PrivateAS eBGP In-Reply-To: <580af3b90908200647q1d1b5b14ja95e92273f7e71b6@mail.gmail.com> References: <580af3b90908190812q72a55910w910b9e07327a9e2@mail.gmail.com> <4A8D4F1A.2000309@cisco.com> <580af3b90908200647q1d1b5b14ja95e92273f7e71b6@mail.gmail.com> Message-ID: <20090820232613.GA8710@srv03.cluenet.de> On Thu, Aug 20, 2009 at 08:47:14AM -0500, Clue Store wrote: > 99% of all of our customer CPE is not managed by the customer, so that > leaves it up to me to decide what to run to them. And then you run into the customer who thinks it's better to use a CPE of his own, breaks into the CPE to read your config and hooks up his own device with his own config... and suddenly you have Problems[tm]. I've seen it happening, more than once. > The only issue with using > ebgp is getting enough of my staff that actually understand bgp to the > point where they can deploy it themselves without having to get me involved > on every install. Am I alone in my view that BGP is _far_ more simple and straight-forward than OSPF (except in salary negotiations of course *G*)? Especially if you leave "plain simple area 0". Or if you have to protect from external parties. With BGP prefix-filtering, things are easy and obvious. > We are moving to a new NOC so this network will get a fresh start (new > 7513-sup720, few m10i's, and a dozen or so 7200vxr's). So my deployment > strategy will be ebgp with multihmed customers. I just had to poke the fire > so I had some ammo for upper management when they ask why I decide to go > ebgp. :-) Best regards, Daniel -- CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0 From giesen at snickers.org Thu Aug 20 18:44:18 2009 From: giesen at snickers.org (Gary T. Giesen) Date: Thu, 20 Aug 2009 19:44:18 -0400 Subject: OSPF vs IS-IS vs PrivateAS eBGP In-Reply-To: <20090820232613.GA8710@srv03.cluenet.de> References: <580af3b90908190812q72a55910w910b9e07327a9e2@mail.gmail.com> <4A8D4F1A.2000309@cisco.com> <580af3b90908200647q1d1b5b14ja95e92273f7e71b6@mail.gmail.com> <20090820232613.GA8710@srv03.cluenet.de> Message-ID: <9a9d0c6a0908201644u54d606d2ia963c402c705022c@mail.gmail.com> I think you misunderstood me. You definitely need prefix filters on the *provider* side, but the CPE doesn't necessarily need them as the impact is hopefully limited to that particular customer. They're always better of course. GG On 8/20/09, Daniel Roesen wrote: > On Thu, Aug 20, 2009 at 08:47:14AM -0500, Clue Store wrote: >> 99% of all of our customer CPE is not managed by the customer, so that >> leaves it up to me to decide what to run to them. > > And then you run into the customer who thinks it's better to use a CPE > of his own, breaks into the CPE to read your config and hooks up his own > device with his own config... and suddenly you have Problems[tm]. > > I've seen it happening, more than once. > >> The only issue with using >> ebgp is getting enough of my staff that actually understand bgp to the >> point where they can deploy it themselves without having to get me >> involved >> on every install. > > Am I alone in my view that BGP is _far_ more simple and straight-forward > than OSPF (except in salary negotiations of course *G*)? Especially if > you leave "plain simple area 0". Or if you have to protect from external > parties. With BGP prefix-filtering, things are easy and obvious. > >> We are moving to a new NOC so this network will get a fresh start (new >> 7513-sup720, few m10i's, and a dozen or so 7200vxr's). So my deployment >> strategy will be ebgp with multihmed customers. I just had to poke the >> fire >> so I had some ammo for upper management when they ask why I decide to go >> ebgp. > > :-) > > > Best regards, > Daniel > > -- > CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0 > > From randy at psg.com Thu Aug 20 18:52:18 2009 From: randy at psg.com (Randy Bush) Date: Fri, 21 Aug 2009 08:52:18 +0900 Subject: OSPF vs IS-IS vs PrivateAS eBGP In-Reply-To: <20090820232613.GA8710@srv03.cluenet.de> References: <580af3b90908190812q72a55910w910b9e07327a9e2@mail.gmail.com> <4A8D4F1A.2000309@cisco.com> <580af3b90908200647q1d1b5b14ja95e92273f7e71b6@mail.gmail.com> <20090820232613.GA8710@srv03.cluenet.de> Message-ID: > Am I alone in my view that BGP is _far_ more simple and > straight-forward than OSPF this is a very telling statement in a number of ways. that ospf has become exceedingly complex, and all that results thereof. that both are known for their complexity. randy From cluestore at gmail.com Thu Aug 20 19:56:14 2009 From: cluestore at gmail.com (Clue Store) Date: Thu, 20 Aug 2009 19:56:14 -0500 Subject: OSPF vs IS-IS vs PrivateAS eBGP In-Reply-To: References: <580af3b90908190812q72a55910w910b9e07327a9e2@mail.gmail.com> <4A8D4F1A.2000309@cisco.com> <580af3b90908200647q1d1b5b14ja95e92273f7e71b6@mail.gmail.com> <20090820232613.GA8710@srv03.cluenet.de> Message-ID: <580af3b90908201756t7baa03d1ua361c53cc384ede2@mail.gmail.com> > Am I alone in my view that BGP is _far_ more simple and > straight-forward than OSPF >that ospf has become exceedingly complex, and all that results thereof. I couldn't agree more. Most of my staff are still under the impression in Cisco land that the "network 10.0.0.0 255.255.255.0" statement injects that network into OSPF, when it simply turns on OSPF for the interfaces that are in that network. I'm really glad to see Cisco that made this change in OSPFv3 for v6. Clue On Thu, Aug 20, 2009 at 6:52 PM, Randy Bush wrote: > > Am I alone in my view that BGP is _far_ more simple and > > straight-forward than OSPF > > this is a very telling statement in a number of ways. > > that ospf has become exceedingly complex, and all that results thereof. > > that both are known for their complexity. > > randy > > From steve at ibctech.ca Thu Aug 20 20:22:48 2009 From: steve at ibctech.ca (Steve Bertrand) Date: Thu, 20 Aug 2009 21:22:48 -0400 Subject: OSPF vs IS-IS vs PrivateAS eBGP In-Reply-To: <9a9d0c6a0908201334w21ef7f17ka22d6bd2e0b92ac0@mail.gmail.com> References: <580af3b90908190812q72a55910w910b9e07327a9e2@mail.gmail.com> <4A8D4F1A.2000309@cisco.com> <580af3b90908200647q1d1b5b14ja95e92273f7e71b6@mail.gmail.com> <006b01ca21cc$a46fb630$0a00000a@nil.si> <9a9d0c6a0908201334w21ef7f17ka22d6bd2e0b92ac0@mail.gmail.com> Message-ID: <4A8DF6E8.1030502@ibctech.ca> Gary T. Giesen wrote: > FWIW, we use BGP to our multihomed customers (even when we manage the > CPE), using a private AS. OSPF doesn't have the right toolset to > provide protection for inter-network route propogation, and the risk > of some customer's CPE screwing up you routing is just too high to go > naked. A basic CPE BGP config is not too difficult to template, and > you don't necessarily have to use prefix filters on it (although you > definitely need them on YOUR) side. And once you've got it deployed, > you'll find the knobs you can turn to do things like TE (ie. data down > one pipe, voice down the other, and failover for both) will have both > you and your customers loving it. (What? I can actually use that spare > circuit that normally does nothing?!?). This is pretty much how I do it for our 100Mb fibre clients. Most of them are upgrading from a <2Mbps SDSL circuit (which has been hugely profitable) to 100Mb Ethernet over fibre. Instead of erasing the revenue of the SDSL, I had this bold approach (mgmt speak) whereas I'd make both circuits worthwhile, by making them redundant. Configure eBGP from your edge to the client edge using private-AS. Since I already have copy/paste templates (thanks to RANCID), I make it a habit to ensure filters are at both ends. Goes without saying that BCP-38 is followed, and strict is deployed everywhere possible. peer-group and regexes are handy. Even for clients who have a single connection (particularly where we control the CPE), I implement eBGP on it so that if I so have the need, I can move their connection about my network with relative ease, even if I know they will never be multi-homed into us. Since my upstream doesn't allow me to BGP peer with them (v4) (they statically route my own ARIN block to me), my v4 experience ends within my own network. *sigh* Either way, even though I'm small and perhaps irrelevant, if in the same sentence you read "my network" and "customer network", use BGP. Steve -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3233 bytes Desc: S/MIME Cryptographic Signature URL: From jbates at brightok.net Thu Aug 20 21:29:26 2009 From: jbates at brightok.net (Jack Bates) Date: Thu, 20 Aug 2009 21:29:26 -0500 Subject: OSPF vs IS-IS vs PrivateAS eBGP In-Reply-To: <580af3b90908201756t7baa03d1ua361c53cc384ede2@mail.gmail.com> References: <580af3b90908190812q72a55910w910b9e07327a9e2@mail.gmail.com> <4A8D4F1A.2000309@cisco.com> <580af3b90908200647q1d1b5b14ja95e92273f7e71b6@mail.gmail.com> <20090820232613.GA8710@srv03.cluenet.de> <580af3b90908201756t7baa03d1ua361c53cc384ede2@mail.gmail.com> Message-ID: <4A8E0686.7020902@brightok.net> Clue Store wrote: > I couldn't agree more. Most of my staff are still under the impression in > Cisco land that the "network 10.0.0.0 255.255.255.0" statement injects that > network into OSPF, when it simply turns on OSPF for the interfaces that are > in that network. I'm really glad to see Cisco that made this change in > OSPFv3 for v6. Cisco legacy commands make it hard on those learning fresh. I still get annoyed when I can't use CIDR notation in a config statement. I think, if nothing else, v6 is giving Cisco a fresh start at reimplementing some things. After dealing with Juniper awhile, I shifted some policies to mirror Juniper's method of doing things. At least that sorted out some confusion for others in the routers. Sadly, Cisco specific shortcuts still look cleaner and easier to manage in the config, but they also require more thought and understanding of what is going on. Jack From ip at ioshints.info Fri Aug 21 01:07:17 2009 From: ip at ioshints.info (Ivan Pepelnjak) Date: Fri, 21 Aug 2009 08:07:17 +0200 Subject: OSPF vs IS-IS vs PrivateAS eBGP In-Reply-To: <4A8DF6E8.1030502@ibctech.ca> References: <580af3b90908190812q72a55910w910b9e07327a9e2@mail.gmail.com> <4A8D4F1A.2000309@cisco.com> <580af3b90908200647q1d1b5b14ja95e92273f7e71b6@mail.gmail.com> <006b01ca21cc$a46fb630$0a00000a@nil.si> <9a9d0c6a0908201334w21ef7f17ka22d6bd2e0b92ac0@mail.gmail.com> <4A8DF6E8.1030502@ibctech.ca> Message-ID: <00a801ca2225$a4312920$0a00000a@nil.si> > Configure eBGP from your edge to the client edge using > private-AS. Since I already have copy/paste templates (thanks > to RANCID), I make it a habit to ensure filters are at both > ends. Goes without saying that > BCP-38 is followed, and strict is deployed everywhere possible. > > peer-group and regexes are handy. If you're starting from scratch, use peer templates, they are slightly more versatile than the peer groups and allow (limited) inheritance. Ivan http://www.ioshints.info/about http://blog.ioshints.info/ From Peter.George at lumison.net Fri Aug 21 05:39:34 2009 From: Peter.George at lumison.net (Peter George) Date: Fri, 21 Aug 2009 11:39:34 +0100 Subject: Alternatives to storm-control on Cat 6509. Message-ID: Hello, I have several Catalyst 6500 (Supervisor 32) aggregation switches with WS-X6148A-GE-TX and WS-X6148-GE-TX line cards. These line cards do not support storm-control/broadcast suppression. This impacted us badly during a recent spanning tree event. As it stands, we are at risk of overwhelming control planes with excess broadcast or multicast traffic, and I need to find alternative ways to protect these switches. I have been researching STP enhancements, and control-plane policing in the following documents, and would appreciate advice from engineers who may have had to implement similar workarounds for storm-control in a service provider setting. * Configuring Denial of Service Protection http://www.cisco.com/en/US/docs/switches/lan/catalyst6500/ios/12.2SX/configuration/guide/dos.pdf * Configuring Control Plane Policing http://www.cisco.com/en/US/docs/switches/lan/catalyst4500/12.2/31sga/configuration/guide/cntl_pln.pdf * Configuring Optional STP Features http://www.cisco.com/en/US/docs/switches/lan/catalyst4500/12.2/31sga/configuration/guide/stp_enha.pdf So, if we can't mitigate against STP events using storm-control or broadcast suppression, what might be the best combination of STP enhancements and control-plane policing? For example, is it possible to rate-limit broadcast/multicast, STP and ARP on a per VLAN basis? If so, how? Many thanks, P -- Peter George Lumison t: 0845 1199 900 d: 0131 514 4022 P.S. Lumison have changed the way businesses communicate forever http://www.unified-communications.net/ ________________________________ -- 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 sender. Any offers or quotation of service are subject to formal specification. Errors and omissions excepted. Please note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Lumison. Finally, the recipient should check this email and any attachments for the presence of viruses. Lumison accept no liability for any damage caused by any virus transmitted by this email. From dschuemann at gmail.com Fri Aug 21 09:07:44 2009 From: dschuemann at gmail.com (Dustin Schuemann) Date: Fri, 21 Aug 2009 10:07:44 -0400 Subject: Packet Loss on Level3 Message-ID: <548B9975-CC03-414D-B010-6A3356E5CDB9@gmail.com> Is anyone else seeing packet loss on Level3. 6. ge-6-11-137.car2.Detroit1.Level3.net 2.9% 35 372.1 148.6 19.4 704.8 127.4 7. ae-11-11.car1.Detroit1.Level3.net 8.6% 35 268.1 161.5 21.3 691.8 156.0 8. ae-8-8.ebr2.Chicago1.Level3.net 0.0% 35 173.6 142.8 34.5 532.4 117.1 9. ae-21-52.car1.Chicago1.Level3.net 5.7% 35 78.1 210.3 35.7 631.2 157.9 From nick at foobar.org Fri Aug 21 10:23:11 2009 From: nick at foobar.org (Nick Hilliard) Date: Fri, 21 Aug 2009 16:23:11 +0100 Subject: Alternatives to storm-control on Cat 6509. In-Reply-To: References: Message-ID: <4A8EBBDF.40909@foobar.org> Peter, This question would be better directed at cisco-nsp, but... On 21/08/2009 11:39, Peter George wrote: > I have several Catalyst 6500 (Supervisor 32) aggregation switches with > WS-X6148A-GE-TX and WS-X6148-GE-TX line cards. > > These line cards do not support storm-control/broadcast suppression. > This impacted us badly during a recent spanning tree event. Not surprised. The 61xx cards are not service provider suitable line cards and they have proved this very clearly. Sorry to hear about these storms - they really are devastating, aren't they? But if you're running L2 customer facing services, particularly shared L2 domain access, there are two things you care about: storm control and port security (mac address counting). The 61xx cards don't do storm control. > For example, is it possible to rate-limit broadcast/multicast, STP and > ARP on a per VLAN basis? If so, how? Yes, you replace your 61xx cards with 67xx cards. You can't do this sort of thing with qos or copp. Nick From rdobbins at arbor.net Fri Aug 21 10:39:50 2009 From: rdobbins at arbor.net (Roland Dobbins) Date: Fri, 21 Aug 2009 22:39:50 +0700 Subject: Alternatives to storm-control on Cat 6509. In-Reply-To: <4A8EBBDF.40909@foobar.org> References: <4A8EBBDF.40909@foobar.org> Message-ID: On Aug 21, 2009, at 10:23 PM, Nick Hilliard wrote: > there are two things you care about: storm control and port security > (mac address counting). Chopping up the layer-2 broadcast domain for a given VLAN into smaller pieces via pVLANs can't hurt, either, as long as the hosts have no need to talk to one another - and it has other benefits, as well. ----------------------------------------------------------------------- Roland Dobbins // Sorry, sometimes I mistake your existential crises for technical insights. -- xkcd #625 From jbates at brightok.net Fri Aug 21 10:49:13 2009 From: jbates at brightok.net (Jack Bates) Date: Fri, 21 Aug 2009 10:49:13 -0500 Subject: Alternatives to storm-control on Cat 6509. In-Reply-To: References: <4A8EBBDF.40909@foobar.org> Message-ID: <4A8EC1F9.7040600@brightok.net> Roland Dobbins wrote: > Chopping up the layer-2 broadcast domain for a given VLAN into smaller > pieces via pVLANs can't hurt, either, as long as the hosts have no need > to talk to one another - and it has other benefits, as well. Or you hit the extreme DSL concentrator end where you crank out q-in-q with roughly 1 vlan per customer (some equipment perhaps handling 1 to many with other built in security features) and let the router proxyarp between them. Unnumbered vlans and RBE saved parts of my network from pending doom. Even fixed issues with dslams that overran the arp caches causing unicast broadcast storms, but the arp cache was irrelevant when it was 1 vlan per port. I'm still waiting for other vendors to tell me how they can match that particular Cisco functionality. Jack From nick at foobar.org Fri Aug 21 10:57:26 2009 From: nick at foobar.org (Nick Hilliard) Date: Fri, 21 Aug 2009 16:57:26 +0100 Subject: Alternatives to storm-control on Cat 6509. In-Reply-To: References: <4A8EBBDF.40909@foobar.org> Message-ID: <4A8EC3E6.1000503@foobar.org> On 21/08/2009 16:39, Roland Dobbins wrote: > Chopping up the layer-2 broadcast domain for a given VLAN into smaller > pieces via pVLANs can't hurt, either, as long as the hosts have no need > to talk to one another - and it has other benefits, as well. Unless your broadcast storm happens on an untagged vlan. Or unless you're running VTP and also have ipv6 hosts connected to the switch on .1q tagged ports, and consequently have to disable VTP pruning in order to get said ipv6 .1q hosts to be able to talk to each other, and then if you have a broadcast storm on any vlan, it could hose your entire l2 network, because you've disabled vtp pruning. Anyway, the point is: storm control on customer facing equipment is a basic requirement. Nick From Jonathan.Gaynor at fccc.edu Fri Aug 21 10:57:49 2009 From: Jonathan.Gaynor at fccc.edu (Gaynor, Jonathan) Date: Fri, 21 Aug 2009 11:57:49 -0400 Subject: Redundancy & Summarization Message-ID: <437B9D1DC8417B428C3C5E0FCBB7E55A059AA2A6@rex1.ritf.fccc.edu> My institution has a single /16 spread across 2 sites: the lower /17 is used at site A, the upper /17 at site B. Sites A & B are connected internally. Currently both sites have their own ISPs and only advertise their own /17's. For redundancy we proposed that each site advertise both their own /17 and the whole /16, so that an ISP failure at either site would trigger traffic from both /17s to reconverge towards the unaffected location. My worry/question: will carriers down the line auto-summarize my advertisements into a single /16, resulting in a 'load sharing' while both sites are active? If you're a backbone carrier and you saw x.x/16 and x.x/17 (or x.x/16 and x.x.128/17) being advertised from the same peer would you drop the longer match? Regards and thanks, Jon Gaynor, Senior Network Engineer Fox Chase Cancer Center (215) 214-4267, jonathan.gaynor at fccc.edu From rdobbins at arbor.net Fri Aug 21 11:04:37 2009 From: rdobbins at arbor.net (Roland Dobbins) Date: Fri, 21 Aug 2009 23:04:37 +0700 Subject: Alternatives to storm-control on Cat 6509. In-Reply-To: <4A8EC3E6.1000503@foobar.org> References: <4A8EBBDF.40909@foobar.org> <4A8EC3E6.1000503@foobar.org> Message-ID: <1115299F-B8BA-4300-AD98-32915343F7C0@arbor.net> On Aug 21, 2009, at 10:57 PM, Nick Hilliard wrote: > Or unless you're running VTP Yes, but this is evil and dangerous in a customer-facing environment; transparent mode is the preferred option, in most circumstances. ----------------------------------------------------------------------- Roland Dobbins // Sorry, sometimes I mistake your existential crises for technical insights. -- xkcd #625 From nick at foobar.org Fri Aug 21 11:05:27 2009 From: nick at foobar.org (Nick Hilliard) Date: Fri, 21 Aug 2009 17:05:27 +0100 Subject: Alternatives to storm-control on Cat 6509. In-Reply-To: <1115299F-B8BA-4300-AD98-32915343F7C0@arbor.net> References: <4A8EBBDF.40909@foobar.org> <4A8EC3E6.1000503@foobar.org> <1115299F-B8BA-4300-AD98-32915343F7C0@arbor.net> Message-ID: <4A8EC5C7.2070809@foobar.org> On 21/08/2009 17:04, Roland Dobbins wrote: > Yes, but this is evil and dangerous in a customer-facing environment; > transparent mode is the preferred option, in most circumstances. It is very evil, yes. SXH and later support VTPv3 which allows you to disable VTP on a per port basis. But as you say, not suitable for customer facing networks. Nick From Jeff.Harper at Suddenlink.com Fri Aug 21 11:28:32 2009 From: Jeff.Harper at Suddenlink.com (Harper, Jeff) Date: Fri, 21 Aug 2009 11:28:32 -0500 Subject: Redundancy & Summarization In-Reply-To: <437B9D1DC8417B428C3C5E0FCBB7E55A059AA2A6@rex1.ritf.fccc.edu> References: <437B9D1DC8417B428C3C5E0FCBB7E55A059AA2A6@rex1.ritf.fccc.edu> Message-ID: <6E0BAD85087B0740A44800CF59B79FA1011BF1A2E5@SDLCORPWMBX01.suddenlink.cequel3.com> Hi Jon, If I personally saw it, I wouldn't bother since I would assume there would be a method to your madness. ;-) Jeff -----Original Message----- From: Gaynor, Jonathan [mailto:Jonathan.Gaynor at fccc.edu] Sent: Friday, August 21, 2009 10:58 AM To: nanog at nanog.org Subject: Redundancy & Summarization My institution has a single /16 spread across 2 sites: the lower /17 is used at site A, the upper /17 at site B. Sites A & B are connected internally. Currently both sites have their own ISPs and only advertise their own /17's. For redundancy we proposed that each site advertise both their own /17 and the whole /16, so that an ISP failure at either site would trigger traffic from both /17s to reconverge towards the unaffected location. My worry/question: will carriers down the line auto-summarize my advertisements into a single /16, resulting in a 'load sharing' while both sites are active? If you're a backbone carrier and you saw x.x/16 and x.x/17 (or x.x/16 and x.x.128/17) being advertised from the same peer would you drop the longer match? Regards and thanks, Jon Gaynor, Senior Network Engineer Fox Chase Cancer Center (215) 214-4267, jonathan.gaynor at fccc.edu From Grzegorz at Janoszka.pl Fri Aug 21 11:31:33 2009 From: Grzegorz at Janoszka.pl (Grzegorz Janoszka) Date: Fri, 21 Aug 2009 18:31:33 +0200 Subject: Redundancy & Summarization In-Reply-To: <437B9D1DC8417B428C3C5E0FCBB7E55A059AA2A6@rex1.ritf.fccc.edu> References: <437B9D1DC8417B428C3C5E0FCBB7E55A059AA2A6@rex1.ritf.fccc.edu> Message-ID: <4A8ECBE5.5090709@Janoszka.pl> Gaynor, Jonathan wrote: > My institution has a single /16 spread across 2 sites: the lower /17 is > used at site A, the upper /17 at site B. Sites A & B are connected > internally. Currently both sites have their own ISPs and only advertise > their own /17's. For redundancy we proposed that each site advertise > both their own /17 and the whole /16, so that an ISP failure at either > site would trigger traffic from both /17s to reconverge towards the > unaffected location. > > My worry/question: will carriers down the line auto-summarize my > advertisements into a single /16, resulting in a 'load sharing' while > both sites are active? If you're a backbone carrier and you saw x.x/16 > and x.x/17 (or x.x/16 and x.x.128/17) being advertised from the same > peer would you drop the longer match? No, BGP does not work this way. But you may force some carriers to have only /16. First, you may try to announce the /17's with the community no-export, so they will be seen only by your direct ISP, not by the rest of the world. Or you may try to use some other communities to limit announcements of your shorter prefixes, only to some part of the world. -- Grzegorz Janoszka From jbates at brightok.net Fri Aug 21 12:32:18 2009 From: jbates at brightok.net (Jack Bates) Date: Fri, 21 Aug 2009 12:32:18 -0500 Subject: Redundancy & Summarization In-Reply-To: <4A8ECBE5.5090709@Janoszka.pl> References: <437B9D1DC8417B428C3C5E0FCBB7E55A059AA2A6@rex1.ritf.fccc.edu> <4A8ECBE5.5090709@Janoszka.pl> Message-ID: <4A8EDA22.8030205@brightok.net> Grzegorz Janoszka wrote: > > No, BGP does not work this way. But you may force some carriers to have > only /16. First, you may try to announce the /17's with the community > no-export, so they will be seen only by your direct ISP, not by the rest > of the world. Or you may try to use some other communities to limit > announcements of your shorter prefixes, only to some part of the world. > Actually, BGP does work that way. The goal is for both /17's to normally make the route decisions, but if one of them disappears, there is a covering /16 route. While this normally wouldn't be a problem, there are places that have issues with their routing table size and do strange modifications to which prefixes they accept. I'd be more concerning if it was a bunch of /24's in a /16 cover, but given the extent of only having 3 prefixes, MOST policies would accept all 3 just fine. That being said, there is still the possibility of some traffic coming the wrong way, but it should be very small (less than if you sent both /17's out both providers and prepended). Jack From ras at e-gerbil.net Fri Aug 21 13:07:19 2009 From: ras at e-gerbil.net (Richard A Steenbergen) Date: Fri, 21 Aug 2009 13:07:19 -0500 Subject: Packet Loss on Level3 In-Reply-To: <548B9975-CC03-414D-B010-6A3356E5CDB9@gmail.com> References: <548B9975-CC03-414D-B010-6A3356E5CDB9@gmail.com> Message-ID: <20090821180719.GQ51443@gerbil.cluepon.net> On Fri, Aug 21, 2009 at 10:07:44AM -0400, Dustin Schuemann wrote: > Is anyone else seeing packet loss on Level3. > > 6. ge-6-11-137.car2.Detroit1.Level3.net 2.9% 35 > 372.1 148.6 19.4 704.8 127.4 > 7. ae-11-11.car1.Detroit1.Level3.net 8.6% 35 > 268.1 161.5 21.3 691.8 156.0 > 8. ae-8-8.ebr2.Chicago1.Level3.net 0.0% 35 > 173.6 142.8 34.5 532.4 117.1 > 9. ae-21-52.car1.Chicago1.Level3.net 5.7% > 35 78.1 210.3 35.7 631.2 157.9 If the loss doesn't continue for every hop along the path, it isn't real loss. For example, if there was actually a problem at hop 6, it would also affect the packets that are traveling to hop 8, so hop 8 wouldn't come up loss-free. Of course it's always possible that there is loss on a particular circuit that is part of a link-aggregate bundle, which causes only certain packets hashed certain ways to go down the "bad" channel, but typically you wouldn't see any loss at all since it's so hard to target that one bad channel channel. The far more likely scenario is that you're seeing routers with overloaded control-plane or exception processor rate-limits, due to excessive icmp generation demands. Running mtr is actually a leading cause of this type of overload, so you might actually be helping contribute to the problem. Unfortunately many routers have hard-coded rate-limits for icmp generation which can't be bumped, despite the fact that we routinely hit them due to "ordinary" things like excessive mtr use. I don't have a single router which hasn't bumped the rate limits by pretty significant amounts, and most are dropping through the day under normal traffic loads: ras at arandomrouter> show pfe statistics ip icmp | match throttled 5195868898 throttled icmps Take a look at a presentation I did at NANOG 45 for more details. http://www.nanog.org/meetings/nanog45/presentations/Sunday/RAS_traceroute_N45.pdf -- Richard A Steenbergen http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) From dr at cluenet.de Fri Aug 21 14:24:20 2009 From: dr at cluenet.de (Daniel Roesen) Date: Fri, 21 Aug 2009 21:24:20 +0200 Subject: OSPF vs IS-IS vs PrivateAS eBGP In-Reply-To: <580af3b90908201756t7baa03d1ua361c53cc384ede2@mail.gmail.com> References: <580af3b90908190812q72a55910w910b9e07327a9e2@mail.gmail.com> <4A8D4F1A.2000309@cisco.com> <580af3b90908200647q1d1b5b14ja95e92273f7e71b6@mail.gmail.com> <20090820232613.GA8710@srv03.cluenet.de> <580af3b90908201756t7baa03d1ua361c53cc384ede2@mail.gmail.com> Message-ID: <20090821192420.GA28365@srv03.cluenet.de> On Thu, Aug 20, 2009 at 07:56:14PM -0500, Clue Store wrote: > Most of my staff are still under the impression in Cisco land that the > "network 10.0.0.0 255.255.255.0" statement injects than network into OSPF, > when it simply turns on OSPF for the interfaces that are in that network. So most of your staff is FAR away from understanding OSPF. Don't you think it's easier to teach them BGP? Where you have a straight-forward config of explicit neighborship, with explicit in/out prefix-lists to control route propagation from/to customers? Where signalling channel (BGP TCP session) is totally separated from what routing information is being exchanged (BGP NLRI)? OSPF just _looks_ simple when used in fully-trusted, most simple almost all defaults config, and even then it's misleading (see your reference to IOS' "network" statement for OSPFv2). When traffic engineering is needed with multiple redundant uplinks for customers, things become very interesting very quickly. Troubleshooting OSPF LSA flooding and database replication is really HARD compared to BGP's simple UPDATE/WITHDRAW messaging. And then you got the whole lot of different LSA types, flooding rules, extension hacks, area types, yadda yadda. IS-IS more straight-forward than OSPF, but still complex. All this is referring to your concern about being able to teach the Ops folks BGP, compared to teaching them OSPF. In my experience, it was never a problem to teach Ops folks BGP to CPEs (even with traffic engineering mods via route-maps), but very hard to get them up to speed on IGPs - and I'm by no means an expert in those either. BGP gives you more control, and with far higher chance of Ops folks being able to troubleshoot issues to success. To me, a clear winner, if your CPE hardware supports it. My 0.02EUR ;) Best regards, Daniel -- CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0 From Brian.Dickson at concertia.com Fri Aug 21 14:47:14 2009 From: Brian.Dickson at concertia.com (Brian Dickson) Date: Fri, 21 Aug 2009 16:47:14 -0300 Subject: Redundancy & Summarization Message-ID: <21D41A38B8859B4A97B1AE2313922B8A810142723D@concertiabl02.concertia.com> > My institution has a single /16 spread across 2 sites: the lower /17 is > used at site A, the upper /17 at site B. Sites A & B are connected > internally. Currently both sites have their own ISPs and only advertise > their own /17's. For redundancy we proposed that each site advertise > both their own /17 and the whole /16, so that an ISP failure at either > site would trigger traffic from both /17s to reconverge towards the > unaffected location. There are two different ways to achieve almost-identical results. However, one is a 50% more "green" than the other, i.e. friendly to other network operators. These two choices are functionally equivalent, and possible, only because things currently work for both your /17's. Here are the two ways to do this: One is: - announce /17 "A" and /16 from uplink ISP-A - announce /17 "B" and /16 from uplink ISP-B - This results in 3 prefixes globally: A, B, and /16. The other is: - announce /17 "A" and /17 "B", with different policies (i.e. prepend your AS once or twice), at *both* ISPs. - This results in 2 prefixes globally: A and B. In all cases, as long as one ISP link is up, there is a path to both A and B. In most cases, the best path to A or B, is *mostly*, but not completely, under your influence. So, the main difference to everyone else is, the presence or absence of a routing slot (/16), and/or extra copies of A and/or B. The routing slot occupies a slot in data-forwarding-plane hardware that is very limited. The extra copies of A and B (and extra copies of your AS in the AS-path) only eat cheap control-plane memory. If everyone did things nicely, we would not have as much of a crisis on the hardware side as we (collectively) do. Please consider being part of the solution (announcing only /17's, but in both places) rather than part of the problem (adding a new redundant /16 to everyone's routers, including in the hardware slots.) Brian From patrick at ianai.net Fri Aug 21 15:08:42 2009 From: patrick at ianai.net (Patrick W. Gilmore) Date: Fri, 21 Aug 2009 16:08:42 -0400 Subject: Redundancy & Summarization In-Reply-To: <21D41A38B8859B4A97B1AE2313922B8A810142723D@concertiabl02.concertia.com> References: <21D41A38B8859B4A97B1AE2313922B8A810142723D@concertiabl02.concertia.com> Message-ID: <19DA1AC1-312D-4590-B25B-53A62DC3E67F@ianai.net> On Aug 21, 2009, at 3:47 PM, Brian Dickson wrote: >> My institution has a single /16 spread across 2 sites: the lower / >> 17 is >> used at site A, the upper /17 at site B. Sites A & B are connected >> internally. Currently both sites have their own ISPs and only >> advertise >> their own /17's. For redundancy we proposed that each site advertise >> both their own /17 and the whole /16, so that an ISP failure at >> either >> site would trigger traffic from both /17s to reconverge towards the >> unaffected location. > > There are two different ways to achieve almost-identical results. As much as I like Brian, I am going to have to respectfully disagree. > However, one is a 50% more "green" than the other, i.e. friendly to > other network operators. > > These two choices are functionally equivalent, and possible, only > because things currently work for both your /17's. > > Here are the two ways to do this: > > One is: > - announce /17 "A" and /16 from uplink ISP-A > - announce /17 "B" and /16 from uplink ISP-B > - This results in 3 prefixes globally: A, B, and /16. > > The other is: > - announce /17 "A" and /17 "B", with different policies (i.e. > prepend your AS once or twice), at *both* ISPs. > - This results in 2 prefixes globally: A and B. > > In all cases, as long as one ISP link is up, there is a path to both > A and B. > In most cases, the best path to A or B, is *mostly*, but not > completely, under your influence. This is highly dependent on variables not in evidence. If your upstreams are, for instance, Sprint & Level 3, then a large percentage of the Internet will be traveling through one or the other. And once it hits your upstream, prepends are irrelevant. Every upstream (for values of "every" == "100%" to at least one decimal place) localprefs their downstreams' prefixes. In this case, anyone downstream of either L3 or Sprint will send _all_ traffic through that upstream's link. While not the whole Internet, it's still quite a bit. Moreover, many people do things like localpref Sprint _down_ because they are more expensive. So even someone multi-homed to both may send all traffic through L3. Etc., etc. A slight twist on Brian's idea would be to use communities and tell Upstream A to localpref Prefix B below that of peer routes. Then you only need two prefixes, and each site only receives its own traffic except when the other site fails. If Upstream B goes down, Upstream A will accept Prefix B and propagate it. Again, dependent upon your upstreams having communities able to do this. Or if they are "nimble", maybe a call to their operations department? -- TTFN, patrick > So, the main difference to everyone else is, the presence or absence > of a routing slot (/16), and/or extra copies of A and/or B. > > The routing slot occupies a slot in data-forwarding-plane hardware > that is very limited. > > The extra copies of A and B (and extra copies of your AS in the AS- > path) only eat cheap control-plane memory. > > If everyone did things nicely, we would not have as much of a crisis > on the hardware side as we (collectively) do. > > Please consider being part of the solution (announcing only /17's, > but in both places) rather than part of the problem (adding a new > redundant /16 to everyone's routers, including in the hardware slots.) > > Brian > From cidr-report at potaroo.net Fri Aug 21 17:00:03 2009 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 21 Aug 2009 22:00:03 GMT Subject: BGP Update Report Message-ID: <200908212200.n7LM03mS047704@wattle.apnic.net> BGP Update Report Interval: 13-Aug-09 -to- 20-Aug-09 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS4961 516762 6.6% 6379.8 -- DISC-AS-KR Daewoo Information System 2 - AS9767 323141 4.1% 8733.5 -- DONGBUIT-AS-KR Dongbulife Insurance co.,LTD 3 - AS18157 219917 2.8% 8796.7 -- CHUNGJU-AS-KR chungju university 4 - AS9459 204123 2.6% 8874.9 -- ASKONKUK Konkuk University 5 - AS9956 201087 2.6% 8742.9 -- KONGJU-AS kongju national university 6 - AS9686 194396 2.5% 8836.2 -- SKKUNET-AS SungKyunKwan University (SKKU) 7 - AS23716 154216 2.0% 5507.7 -- CHANGWON23716-AS-KR Changwon College 8 - AS10159 149403 1.9% 5976.1 -- HAUNET-AS-KR HANKUK Aviation University 9 - AS9530 135249 1.7% 7118.4 -- SHINSEGAE-AS SHINSEGAE I&C Co., Ltd. 10 - AS9628 122729 1.6% 6459.4 -- SSEM-AS-KR Seoul Education Science Research Institute 11 - AS9868 99583 1.3% 7113.1 -- CUTH-AS Catholic University of DAEGU 12 - AS10088 96758 1.2% 8063.2 -- KWANGWOON-UNIV-AS-AP KWANGWOON University in Seoul, Korea 13 - AS18027 88348 1.1% 8834.8 -- NSU-AS-KR namseoul university 14 - AS18023 87965 1.1% 3518.6 -- KMU-AS-KR Korea Maritime University 15 - AS18026 87648 1.1% 8764.8 -- CHEJU-AS-KR Cheju University 16 - AS17865 87569 1.1% 7960.8 -- SCOURT-AS-KR Supreme Court of Korea 17 - AS10045 80256 1.0% 8917.3 -- TNUTNET-AS HANBAT NATIONAL UNIVERSITY 18 - AS9970 79372 1.0% 8819.1 -- KUT-AS Korea University of Technology and Education 19 - AS10176 79196 1.0% 8799.6 -- TENET-AS Taejon Institute of Education Science 20 - AS7557 79010 1.0% 8778.9 -- KTNET-AS Korea Trade Network TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS9456 8920 0.1% 8920.0 -- POSCO-AS POSCO 2 - AS10045 80256 1.0% 8917.3 -- TNUTNET-AS HANBAT NATIONAL UNIVERSITY 3 - AS9846 8908 0.1% 8908.0 -- FIRSTDATA-AS-KR FDIK 4 - AS17840 8890 0.1% 8890.0 -- KOREACERT-AS-KR KECA, Inc. 5 - AS9571 17776 0.2% 8888.0 -- INICIS-AS INICIS Co., Ltd 6 - AS17600 8883 0.1% 8883.0 -- ENVICO-AS-KR Korea Environment & Resources Corporation 7 - AS10042 17764 0.2% 8882.0 -- DPC-AS-KR DAEGU POLYTECHNIC COLLEGE 8 - AS9459 204123 2.6% 8874.9 -- ASKONKUK Konkuk University 9 - AS10055 35488 0.5% 8872.0 -- KORAIL-AS-KR Korean National Railroad Administration 10 - AS10058 26615 0.3% 8871.7 -- CU-AS-KR NACUFOK 11 - AS23983 26613 0.3% 8871.0 -- DJU-AS-KR Daejeon University 12 - AS23557 8848 0.1% 8848.0 -- YUHWA-AS-KR Yuhwa Securities Co., LTD 13 - AS23573 26532 0.3% 8844.0 -- OCIC-AS-KR OCI Information Communication 14 - AS18324 53042 0.7% 8840.3 -- MASANC-AS-KR Masan College 15 - AS23562 17674 0.2% 8837.0 -- BCRC-AS-KR Busan Cycle Racing Corporation 16 - AS9686 194396 2.5% 8836.2 -- SKKUNET-AS SungKyunKwan University (SKKU) 17 - AS18027 88348 1.1% 8834.8 -- NSU-AS-KR namseoul university 18 - AS17601 17664 0.2% 8832.0 -- KCGF-AS-KR KOREA CREDIT GUARANTEE FUND 19 - AS18319 61824 0.8% 8832.0 -- YJNET-AS-KR Yeungnam College of Science & Technology 20 - AS9452 8829 0.1% 8829.0 -- KUNET-AS Korea University TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 210.90.28.0/24 8941 0.1% AS23568 -- CRA-AS-KR Cycle Racing Association 2 - 163.239.192.0/20 8925 0.1% AS3813 -- SOGANG-AS-KR sogang university 3 - 163.239.208.0/21 8923 0.1% AS3813 -- SOGANG-AS-KR sogang university 4 - 163.239.128.0/18 8923 0.1% AS3813 -- SOGANG-AS-KR sogang university 5 - 163.239.0.0/17 8923 0.1% AS3813 -- SOGANG-AS-KR sogang university 6 - 210.110.248.0/22 8922 0.1% AS10045 -- TNUTNET-AS HANBAT NATIONAL UNIVERSITY 7 - 210.98.40.0/22 8920 0.1% AS10045 -- TNUTNET-AS HANBAT NATIONAL UNIVERSITY 8 - 203.246.186.0/24 8920 0.1% AS9456 -- POSCO-AS POSCO 9 - 210.119.112.0/24 8920 0.1% AS10045 -- TNUTNET-AS HANBAT NATIONAL UNIVERSITY 10 - 203.230.104.0/22 8920 0.1% AS10045 -- TNUTNET-AS HANBAT NATIONAL UNIVERSITY 11 - 203.230.96.0/21 8918 0.1% AS10045 -- TNUTNET-AS HANBAT NATIONAL UNIVERSITY 12 - 202.30.46.0/23 8916 0.1% AS10045 -- TNUTNET-AS HANBAT NATIONAL UNIVERSITY 13 - 220.66.143.0/24 8916 0.1% AS10045 -- TNUTNET-AS HANBAT NATIONAL UNIVERSITY 14 - 220.66.144.0/22 8912 0.1% AS10045 -- TNUTNET-AS HANBAT NATIONAL UNIVERSITY 15 - 220.66.148.0/23 8912 0.1% AS10045 -- TNUTNET-AS HANBAT NATIONAL UNIVERSITY 16 - 210.182.8.0/24 8908 0.1% AS9846 -- FIRSTDATA-AS-KR FDIK 17 - 203.252.168.0/24 8899 0.1% AS9459 -- ASKONKUK Konkuk University 18 - 210.119.217.0/24 8899 0.1% AS9459 -- ASKONKUK Konkuk University 19 - 203.252.166.0/24 8897 0.1% AS9459 -- ASKONKUK Konkuk University 20 - 210.119.219.0/24 8897 0.1% AS9459 -- ASKONKUK Konkuk University 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 Aug 21 17:00:00 2009 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 21 Aug 2009 22:00:00 GMT Subject: The Cidr Report Message-ID: <200908212200.n7LM00Hh047684@wattle.apnic.net> This report has been generated at Fri Aug 21 21:11:35 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 14-08-09 299670 185428 15-08-09 300270 185630 16-08-09 300435 185798 17-08-09 300545 186310 18-08-09 300921 186382 19-08-09 300907 186378 20-08-09 301052 186537 21-08-09 300840 186721 AS Summary 32108 Number of ASes in routing system 13642 Number of ASes announcing only one prefix 4303 Largest number of prefixes announced by an AS AS4323 : TWTC - tw telecom holdings, inc. 89681920 Largest address span announced by an AS (/32s) AS27064: DNIC-ASBLK-27032-27159 - DoD Network Information Center Aggregation Summary The algorithm used in this report proposes aggregation only when there is a precise match using the AS path, so as to preserve traffic transit policies. Aggregation is also proposed across non-advertised address space ('holes'). --- 21Aug09 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 300851 186486 114365 38.0% All ASes AS6389 4181 325 3856 92.2% BELLSOUTH-NET-BLK - BellSouth.net Inc. AS4323 4303 1731 2572 59.8% TWTC - tw telecom holdings, inc. AS4766 1830 540 1290 70.5% KIXS-AS-KR Korea Telecom AS17488 1555 303 1252 80.5% HATHWAY-NET-AP Hathway IP Over Cable Internet AS22773 1086 71 1015 93.5% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. AS18101 958 37 921 96.1% RIL-IDC Reliance Infocom Ltd Internet Data Centre, AS8151 1482 569 913 61.6% Uninet S.A. de C.V. AS19262 1039 236 803 77.3% VZGNI-TRANSIT - Verizon Internet Services Inc. AS4755 1227 432 795 64.8% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP AS18566 1062 277 785 73.9% COVAD - Covad Communications Co. AS6478 1383 629 754 54.5% ATT-INTERNET3 - AT&T WorldNet Services AS8452 1002 287 715 71.4% TEDATA TEDATA AS10620 983 348 635 64.6% TV Cable S.A. AS1785 1729 1118 611 35.3% AS-PAETEC-NET - PaeTec Communications, Inc. AS4804 686 91 595 86.7% MPX-AS Microplex PTY LTD AS9498 635 64 571 89.9% BBIL-AP BHARTI Airtel Ltd. AS4808 762 211 551 72.3% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network AS7303 627 98 529 84.4% Telecom Argentina S.A. AS22047 541 14 527 97.4% VTR BANDA ANCHA S.A. AS855 618 131 487 78.8% CANET-ASN-4 - Bell Aliant Regional Communications, Inc. AS11492 1110 629 481 43.3% CABLEONE - CABLE ONE, INC. AS4134 998 534 464 46.5% CHINANET-BACKBONE No.31,Jin-rong Street AS3356 1211 754 457 37.7% LEVEL3 Level 3 Communications AS7018 1492 1053 439 29.4% ATT-INTERNET4 - AT&T WorldNet Services AS17676 564 127 437 77.5% GIGAINFRA Softbank BB Corp. AS4780 571 142 429 75.1% SEEDNET Digital United Inc. AS7545 839 413 426 50.8% TPG-INTERNET-AP TPG Internet Pty Ltd AS9443 515 94 421 81.7% INTERNETPRIMUS-AS-AP Primus Telecommunications AS7011 993 573 420 42.3% FRONTIER-AND-CITIZENS - Frontier Communications of America, Inc. AS5668 777 363 414 53.3% AS-5668 - CenturyTel Internet Holdings, Inc. Total 36759 12194 24565 66.8% Top 30 total Possible Bogus Routes 24.225.128.0/17 AS36377 PATRIOT-MEDIA-NJ - Comcast Telecommunications, Inc. 24.245.128.0/17 AS11492 CABLEONE - CABLE ONE, INC. 41.223.92.0/22 AS36936 CELTEL-GABON Celtel Gabon Internet Service 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. 43.245.0.0/16 AS7502 IP-KYOTO Internetwork Kyoto 43.245.96.0/20 AS7502 IP-KYOTO Internetwork Kyoto 43.245.112.0/20 AS7502 IP-KYOTO Internetwork Kyoto 43.245.192.0/20 AS7502 IP-KYOTO Internetwork Kyoto 43.245.208.0/20 AS7502 IP-KYOTO Internetwork Kyoto 43.245.224.0/20 AS7502 IP-KYOTO Internetwork Kyoto 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.72.112.0/20 AS19166 64.79.88.0/24 AS26096 LODDEN - Lodden Services 64.79.89.0/24 AS26096 LODDEN - Lodden Services 64.247.160.0/20 AS10937 IIS - Island Internet Services 66.128.38.0/24 AS15246 Telecomunicaciones Satelitales TelesatS.A. 66.180.239.0/24 AS35888 VIGNETTE - VIGNETTE CORPORATION 66.206.32.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.33.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.34.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.35.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.40.0/22 AS174 COGENT Cogent/PSI 66.206.44.0/23 AS174 COGENT Cogent/PSI 66.206.47.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 66.207.32.0/20 AS23011 66.241.112.0/20 AS21547 REVNETS - Revolution Networks 66.245.176.0/20 AS19318 NJIIX-AS-1 - NEW JERSEY INTERNATIONAL INTERNET EXCHANGE LLC 69.6.80.0/24 AS13442 69.6.81.0/24 AS13442 69.71.192.0/20 AS13818 PHX-INTL-TELEPORT - Phoenix International Teleport 69.80.224.0/19 AS19166 74.120.160.0/24 AS19262 VZGNI-TRANSIT - Verizon Internet Services Inc. 74.120.161.0/24 AS19262 VZGNI-TRANSIT - Verizon Internet Services Inc. 74.120.162.0/24 AS19262 VZGNI-TRANSIT - Verizon Internet Services Inc. 74.120.163.0/24 AS19262 VZGNI-TRANSIT - Verizon Internet Services Inc. 74.120.164.0/24 AS19262 VZGNI-TRANSIT - Verizon Internet Services Inc. 74.120.165.0/24 AS19262 VZGNI-TRANSIT - Verizon Internet Services Inc. 74.120.166.0/24 AS19262 VZGNI-TRANSIT - Verizon Internet Services Inc. 74.120.167.0/24 AS19262 VZGNI-TRANSIT - Verizon Internet Services Inc. 74.120.168.0/24 AS19262 VZGNI-TRANSIT - Verizon Internet Services Inc. 74.120.169.0/24 AS19262 VZGNI-TRANSIT - Verizon Internet Services Inc. 74.120.170.0/24 AS19262 VZGNI-TRANSIT - Verizon Internet Services Inc. 74.120.171.0/24 AS19262 VZGNI-TRANSIT - Verizon Internet Services Inc. 74.120.172.0/24 AS19262 VZGNI-TRANSIT - Verizon Internet Services Inc. 74.120.173.0/24 AS19262 VZGNI-TRANSIT - Verizon Internet Services Inc. 74.120.174.0/24 AS19262 VZGNI-TRANSIT - Verizon Internet Services Inc. 74.120.175.0/24 AS19262 VZGNI-TRANSIT - Verizon Internet Services Inc. 80.88.10.0/24 AS33774 DJAWEB 80.88.12.0/24 AS33779 wataniya-telecom-as 95.143.64.0/20 AS30781 JAGUAR-AS AS for Jaguar Network 96.8.64.0/18 AS19166 96.8.127.0/24 AS19166 100.100.100.0/30 AS38676 AS33005-AS-KR wizsolution co.,Ltd 116.50.0.0/24 AS17754 EXCELL-AS Excellmedia 117.120.56.0/21 AS4755 TATACOMM-AS TATA Communications formerly VSNL is Leading ISP 121.46.0.0/16 AS4134 CHINANET-BACKBONE No.31,Jin-rong Street 121.50.10.0/24 AS38236 121.50.13.0/24 AS38236 121.50.15.0/24 AS17625 BLAZENET-IN-AP BlazeNet's Network 121.50.168.0/21 AS9931 CAT-AP The Communication Authoity of Thailand, CAT 122.128.120.0/22 AS38456 PACTEL-AS-AP Pacific Teleports. 158.222.5.0/24 AS21580 SIERRA-ADVANTAGE - Sierra Advantage, Inc. 158.222.70.0/23 AS6137 SISNA - SISNA, Inc. 158.222.72.0/23 AS6137 SISNA - SISNA, Inc. 158.222.224.0/20 AS19864 O1COMM - O1 COMMUNICATIONS 158.222.224.0/22 AS19864 O1COMM - O1 COMMUNICATIONS 158.222.229.0/24 AS19864 O1COMM - O1 COMMUNICATIONS 163.142.0.0/16 AS2500 WIDE-BB WIDE Project 172.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.141.0/24 AS2018 TENET-1 192.96.177.0/24 AS6083 POSIX-AFRICA 192.101.45.0/24 AS2905 TICSA-ASN 192.101.46.0/24 AS6503 Avantel, S.A. 192.101.64.0/21 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 192.101.70.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 192.101.71.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 192.101.72.0/24 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 192.101.74.0/24 AS1239 SPRINTLINK - Sprint 192.124.248.0/23 AS680 DFN-IP service X-WiN 192.124.252.0/22 AS680 DFN-IP service X-WiN 192.131.233.0/24 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 192.132.58.0/24 AS20141 QUALITYTECH-SUW-300 - Quality Technology Services, LLC. 192.133.6.0/24 AS10282 ORANGE-BUSINESS-SERVICES-CEEUR Orange Business Services (formerly Equant) AS for CEEUR 192.139.3.0/24 AS23184 PERSONA - PERSONA COMMUNICATIONS INC. 192.153.144.0/21 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 192.154.32.0/19 AS81 NCREN - MCNC 192.188.208.0/20 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 193.24.196.0/22 AS6714 ATOMNET ATOM SA 193.33.148.0/23 AS30890 EVOLVA Evolva Telecom / iLink Telecom 195.16.90.0/24 AS34377 BROKER-AS Przedsiebiorstwo Broker Service Sp. Z o.o. 195.225.58.0/24 AS6714 ATOMNET ATOM SA 196.6.108.0/24 AS5713 SAIX-NET 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.73.210.0/24 AS21570 ACI-1 - Accelerated Connections Inc. 198.97.72.0/21 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 198.97.96.0/19 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 198.97.240.0/20 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 198.135.236.0/24 AS4358 XNET - XNet Information Systems, Inc. 198.161.87.0/24 AS6539 GT-BELL - Bell Canada 198.161.92.0/24 AS6539 GT-BELL - Bell Canada 198.167.0.0/16 AS7456 INTERHOP - Interhop Network SERVICES Inc. 198.168.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 198.169.0.0/16 AS803 SASKTEL - Saskatchewan Telecommunications 198.180.198.0/24 AS23715 SEOUL-INTGW-GXS-AP Global Exchange Services 199.5.242.0/24 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 199.10.0.0/16 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.16.32.0/19 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 199.114.0.0/21 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.114.128.0/18 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.114.130.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.131.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.132.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.134.0/24 AS3541 ITSDN-U4 - DoD Network Information Center 199.114.136.0/24 AS27044 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.114.138.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.140.0/24 AS3544 ITSDN-U7 - DoD Network Information Center 199.114.142.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.144.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.148.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.150.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.152.0/24 AS27033 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.114.153.0/24 AS27034 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.114.154.0/24 AS1733 CENTAF-SWA - 754th Electronic Systems Group 199.114.156.0/24 AS1733 CENTAF-SWA - 754th Electronic Systems Group 199.114.160.0/24 AS1733 CENTAF-SWA - 754th Electronic Systems Group 199.121.0.0/16 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.123.0.0/18 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.123.16.0/20 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.123.80.0/21 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.189.32.0/19 AS7332 IQUEST-AS - IQuest Internet 199.202.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 199.202.216.0/21 AS577 BACOM - Bell Canada 199.233.92.0/24 AS26896 ITCOMM - IT Communications 199.246.116.0/24 AS813 UUNET-CANADA - MCI Communications Services, Inc. d/b/a Verizon Business 200.9.115.0/24 AS10292 CWJ-1 - Cable & Wireless Jamaica 200.108.176.0/20 AS14551 UUNET-SA - MCI Communications Services, Inc. d/b/a Verizon Business 202.6.176.0/20 AS24316 202.58.113.0/24 AS19161 202.73.144.0/20 AS4788 TMNET-AS-AP TM Net, Internet Service Provider 202.80.192.0/20 AS2706 PI-HK Pacnet Internet (Hong Kong) Limited 202.84.10.0/23 AS9308 CHINA-ABITCOOL Abitcool(China) Inc. 202.86.252.0/22 AS4748 RESOLINK-AS-AP Resources Link Network Limited 202.86.252.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.253.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.254.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.255.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.94.70.0/24 AS2764 AAPT AAPT Limited 202.124.195.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.125.113.0/24 AS9541 CYBERNET-AP Cyber Internet Services (Pvt) Ltd. 202.125.114.0/24 AS9541 CYBERNET-AP Cyber Internet Services (Pvt) Ltd. 202.125.115.0/24 AS9541 CYBERNET-AP Cyber Internet Services (Pvt) Ltd. 202.133.37.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.133.47.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.133.70.0/24 AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited 202.133.73.0/24 AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited 202.136.254.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.136.255.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.140.160.0/24 AS4841 202.140.161.0/24 AS4841 202.140.162.0/24 AS4841 202.140.163.0/24 AS4841 202.140.164.0/24 AS4841 202.140.165.0/24 AS4841 202.140.166.0/24 AS4841 202.140.167.0/24 AS4841 202.140.168.0/24 AS4841 202.140.169.0/24 AS4841 202.140.170.0/24 AS4841 202.140.171.0/24 AS4841 202.140.172.0/24 AS4841 202.140.173.0/24 AS4841 202.140.174.0/24 AS4841 202.140.175.0/24 AS4841 202.140.180.0/24 AS7540 HKCIX-AS-AP HongKong Commercial Internet Exchange 202.140.181.0/24 AS7540 HKCIX-AS-AP HongKong Commercial Internet Exchange 202.140.182.0/24 AS7540 HKCIX-AS-AP HongKong Commercial Internet Exchange 202.150.227.0/24 AS17727 NAPINFO-AS-AP PT. NAP Info Lintas Nusa 202.174.70.0/24 AS21175 M-LINK M-Link Teleport s.a. 202.181.32.0/24 AS4645 ASN-HKNET-AP HKNet Co. Ltd 203.12.45.0/24 AS4854 NETSPACE-AS-AP Netspace Online Systems 203.62.0.0/17 AS7575 AARNET-AS-AP Australian Academic and Reasearch Network (AARNet) 203.78.48.0/20 AS9299 IPG-AS-AP Philippine Long Distance Telephone Company 203.80.136.0/21 AS4759 EVOSERVE-AS-AP EvoServe is a content and online access Internet provider company 203.86.96.0/19 AS4755 TATACOMM-AS TATA Communications formerly VSNL is Leading ISP 203.89.139.0/24 AS17911 BRAINPK-AS-AP Brain Telecommunication Ltd. 203.112.111.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.113.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.114.0/24 AS4802 ASN-IINET iiNet Limited 203.112.116.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.117.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.118.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.119.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.120.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.121.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.127.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.128.128.0/24 AS23849 CNNIC-NET263-AP Beijing Capital-online science development Co.,Ltd. 203.142.219.0/24 AS45149 203.189.96.0/20 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 204.9.216.0/23 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 204.9.218.0/23 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 204.19.14.0/23 AS577 BACOM - Bell Canada 204.89.214.0/24 AS4323 TWTC - tw telecom holdings, inc. 204.138.167.0/24 AS18990 AIRBAND-DALLAS - Airband Communications, Inc 204.197.0.0/16 AS3356 LEVEL3 Level 3 Communications 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.166.112.0/20 AS10937 IIS - Island Internet Services 207.174.0.0/16 AS13790 INTERNAP-BLK3 - Internap Network Services Corporation 207.174.131.0/24 AS30715 NETRACK - Netrack, Inc. 207.174.132.0/23 AS30715 NETRACK - Netrack, Inc. 207.174.151.0/24 AS11500 PEAKPEAK - Peak to Peak Internet 207.174.152.0/22 AS30715 NETRACK - Netrack, Inc. 207.174.177.0/24 AS11500 PEAKPEAK - Peak to Peak Internet 207.174.178.0/24 AS11500 PEAKPEAK - Peak to Peak Internet 207.174.182.0/24 AS29831 FONENET - FONE NET, LLC 207.174.188.0/22 AS30715 NETRACK - Netrack, Inc. 207.174.192.0/24 AS29831 FONENET - FONE NET, LLC 207.174.200.0/24 AS22658 EARTHNET - Earthnet, Inc. 207.174.248.0/21 AS6653 PRIVATEI - privateI, LLC 207.231.96.0/19 AS11194 NUNETPA - NuNet Inc. 208.73.88.0/21 AS36835 208.77.224.0/24 AS36835 208.77.225.0/24 AS36835 208.77.226.0/24 AS36835 208.77.227.0/24 AS36835 208.77.228.0/24 AS36835 208.77.229.0/24 AS36835 208.77.230.0/24 AS36835 208.77.231.0/24 AS36835 208.87.152.0/21 AS25973 MZIMA - Mzima Networks, 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.217.224.0/19 AS6130 AIS-WEST - American Internet Services, LLC. 209.222.5.0/24 AS26699 PSI-CT - Printing For Systems Inc 210.5.128.0/20 AS4837 CHINA169-BACKBONE CNCGROUP China169 Backbone 210.247.224.0/19 AS7496 WEBCENTRAL-AS WebCentral 213.181.70.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.80.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.81.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.82.0/23 AS17175 NSS-UK New Skies Satellites UK AS 213.181.82.0/24 AS17175 NSS-UK New Skies Satellites UK AS 213.181.83.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.84.0/22 AS17175 NSS-UK New Skies Satellites UK AS 213.181.84.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.85.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.86.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.87.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.88.0/21 AS17175 NSS-UK New Skies Satellites UK AS 213.181.88.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.89.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.90.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.91.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.92.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.93.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.94.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.95.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 216.99.20.0/24 AS3356 LEVEL3 Level 3 Communications 216.163.144.0/20 AS35985 ONERINGNET-ATL-1 - One Ring Networks, Inc. 216.172.198.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 216.172.199.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 216.251.207.0/24 AS1239 SPRINTLINK - Sprint 217.78.71.0/24 AS12491 IPPLANET-AS Gilat Satcom 217.78.72.0/24 AS12491 IPPLANET-AS Gilat Satcom 217.78.73.0/24 AS12491 IPPLANET-AS Gilat Satcom Please see http://www.cidr-report.org for the full report ------------------------------------ Copies of this report are mailed to: nanog at merit.edu eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From mmc at internode.com.au Fri Aug 21 23:56:01 2009 From: mmc at internode.com.au (Matthew Moyle-Croft) Date: Sat, 22 Aug 2009 14:26:01 +0930 Subject: BGP Update Report In-Reply-To: <200908212200.n7LM03mS047704@wattle.apnic.net> References: <200908212200.n7LM03mS047704@wattle.apnic.net> Message-ID: <4A8F7A61.5090600@internode.com.au> I'm guessing that the top 20 unstable ASes are Korean or Asian is related to the cable cuts in Asia? cidr-report at potaroo.net wrote: > BGP Update Report > Interval: 13-Aug-09 -to- 20-Aug-09 (7 days) > Observation Point: BGP Peering with AS131072 > > TOP 20 Unstable Origin AS > Rank ASN Upds % Upds/Pfx AS-Name > 1 - AS4961 516762 6.6% 6379.8 -- DISC-AS-KR Daewoo Information System > 2 - AS9767 323141 4.1% 8733.5 -- DONGBUIT-AS-KR Dongbulife Insurance co.,LTD > 3 - AS18157 219917 2.8% 8796.7 -- CHUNGJU-AS-KR chungju university > 4 - AS9459 204123 2.6% 8874.9 -- ASKONKUK Konkuk University > 5 - AS9956 201087 2.6% 8742.9 -- KONGJU-AS kongju national university > 6 - AS9686 194396 2.5% 8836.2 -- SKKUNET-AS SungKyunKwan University (SKKU) > 7 - AS23716 154216 2.0% 5507.7 -- CHANGWON23716-AS-KR Changwon College > 8 - AS10159 149403 1.9% 5976.1 -- HAUNET-AS-KR HANKUK Aviation University > 9 - AS9530 135249 1.7% 7118.4 -- SHINSEGAE-AS SHINSEGAE I&C Co., Ltd. > 10 - AS9628 122729 1.6% 6459.4 -- SSEM-AS-KR Seoul Education Science Research Institute > 11 - AS9868 99583 1.3% 7113.1 -- CUTH-AS Catholic University of DAEGU > 12 - AS10088 96758 1.2% 8063.2 -- KWANGWOON-UNIV-AS-AP KWANGWOON University in Seoul, Korea > 13 - AS18027 88348 1.1% 8834.8 -- NSU-AS-KR namseoul university > 14 - AS18023 87965 1.1% 3518.6 -- KMU-AS-KR Korea Maritime University > 15 - AS18026 87648 1.1% 8764.8 -- CHEJU-AS-KR Cheju University > 16 - AS17865 87569 1.1% 7960.8 -- SCOURT-AS-KR Supreme Court of Korea > 17 - AS10045 80256 1.0% 8917.3 -- TNUTNET-AS HANBAT NATIONAL UNIVERSITY > 18 - AS9970 79372 1.0% 8819.1 -- KUT-AS Korea University of Technology and Education > 19 - AS10176 79196 1.0% 8799.6 -- TENET-AS Taejon Institute of Education Science > 20 - AS7557 79010 1.0% 8778.9 -- KTNET-AS Korea Trade Network > > > TOP 20 Unstable Origin AS (Updates per announced prefix) > Rank ASN Upds % Upds/Pfx AS-Name > 1 - AS9456 8920 0.1% 8920.0 -- POSCO-AS POSCO > 2 - AS10045 80256 1.0% 8917.3 -- TNUTNET-AS HANBAT NATIONAL UNIVERSITY > 3 - AS9846 8908 0.1% 8908.0 -- FIRSTDATA-AS-KR FDIK > 4 - AS17840 8890 0.1% 8890.0 -- KOREACERT-AS-KR KECA, Inc. > 5 - AS9571 17776 0.2% 8888.0 -- INICIS-AS INICIS Co., Ltd > 6 - AS17600 8883 0.1% 8883.0 -- ENVICO-AS-KR Korea Environment & Resources Corporation > 7 - AS10042 17764 0.2% 8882.0 -- DPC-AS-KR DAEGU POLYTECHNIC COLLEGE > 8 - AS9459 204123 2.6% 8874.9 -- ASKONKUK Konkuk University > 9 - AS10055 35488 0.5% 8872.0 -- KORAIL-AS-KR Korean National Railroad Administration > 10 - AS10058 26615 0.3% 8871.7 -- CU-AS-KR NACUFOK > 11 - AS23983 26613 0.3% 8871.0 -- DJU-AS-KR Daejeon University > 12 - AS23557 8848 0.1% 8848.0 -- YUHWA-AS-KR Yuhwa Securities Co., LTD > 13 - AS23573 26532 0.3% 8844.0 -- OCIC-AS-KR OCI Information Communication > 14 - AS18324 53042 0.7% 8840.3 -- MASANC-AS-KR Masan College > 15 - AS23562 17674 0.2% 8837.0 -- BCRC-AS-KR Busan Cycle Racing Corporation > 16 - AS9686 194396 2.5% 8836.2 -- SKKUNET-AS SungKyunKwan University (SKKU) > 17 - AS18027 88348 1.1% 8834.8 -- NSU-AS-KR namseoul university > 18 - AS17601 17664 0.2% 8832.0 -- KCGF-AS-KR KOREA CREDIT GUARANTEE FUND > 19 - AS18319 61824 0.8% 8832.0 -- YJNET-AS-KR Yeungnam College of Science & Technology > 20 - AS9452 8829 0.1% 8829.0 -- KUNET-AS Korea University > > > TOP 20 Unstable Prefixes > Rank Prefix Upds % Origin AS -- AS Name > 1 - 210.90.28.0/24 8941 0.1% AS23568 -- CRA-AS-KR Cycle Racing Association > 2 - 163.239.192.0/20 8925 0.1% AS3813 -- SOGANG-AS-KR sogang university > 3 - 163.239.208.0/21 8923 0.1% AS3813 -- SOGANG-AS-KR sogang university > 4 - 163.239.128.0/18 8923 0.1% AS3813 -- SOGANG-AS-KR sogang university > 5 - 163.239.0.0/17 8923 0.1% AS3813 -- SOGANG-AS-KR sogang university > 6 - 210.110.248.0/22 8922 0.1% AS10045 -- TNUTNET-AS HANBAT NATIONAL UNIVERSITY > 7 - 210.98.40.0/22 8920 0.1% AS10045 -- TNUTNET-AS HANBAT NATIONAL UNIVERSITY > 8 - 203.246.186.0/24 8920 0.1% AS9456 -- POSCO-AS POSCO > 9 - 210.119.112.0/24 8920 0.1% AS10045 -- TNUTNET-AS HANBAT NATIONAL UNIVERSITY > 10 - 203.230.104.0/22 8920 0.1% AS10045 -- TNUTNET-AS HANBAT NATIONAL UNIVERSITY > 11 - 203.230.96.0/21 8918 0.1% AS10045 -- TNUTNET-AS HANBAT NATIONAL UNIVERSITY > 12 - 202.30.46.0/23 8916 0.1% AS10045 -- TNUTNET-AS HANBAT NATIONAL UNIVERSITY > 13 - 220.66.143.0/24 8916 0.1% AS10045 -- TNUTNET-AS HANBAT NATIONAL UNIVERSITY > 14 - 220.66.144.0/22 8912 0.1% AS10045 -- TNUTNET-AS HANBAT NATIONAL UNIVERSITY > 15 - 220.66.148.0/23 8912 0.1% AS10045 -- TNUTNET-AS HANBAT NATIONAL UNIVERSITY > 16 - 210.182.8.0/24 8908 0.1% AS9846 -- FIRSTDATA-AS-KR FDIK > 17 - 203.252.168.0/24 8899 0.1% AS9459 -- ASKONKUK Konkuk University > 18 - 210.119.217.0/24 8899 0.1% AS9459 -- ASKONKUK Konkuk University > 19 - 203.252.166.0/24 8897 0.1% AS9459 -- ASKONKUK Konkuk University > 20 - 210.119.219.0/24 8897 0.1% AS9459 -- ASKONKUK Konkuk University > > 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 andrew at parnell.ca Sat Aug 22 00:21:45 2009 From: andrew at parnell.ca (Andrew Parnell) Date: Sat, 22 Aug 2009 01:21:45 -0400 Subject: BGP Update Report In-Reply-To: <4A8F7A61.5090600@internode.com.au> References: <200908212200.n7LM03mS047704@wattle.apnic.net> <4A8F7A61.5090600@internode.com.au> Message-ID: <2d54a02d0908212221q46110fe4h5cc5f3364ffb42d4@mail.gmail.com> It's nice to give Kazakhstan a break for a week or so. :p On Sat, Aug 22, 2009 at 12:56 AM, Matthew Moyle-Croft wrote: > I'm guessing that the top 20 unstable ASes are Korean or Asian is related > to the cable cuts in Asia? > > > cidr-report at potaroo.net wrote: > >> BGP Update Report >> Interval: 13-Aug-09 -to- 20-Aug-09 (7 days) >> Observation Point: BGP Peering with AS131072 >> >> TOP 20 Unstable Origin AS >> Rank ASN Upds % Upds/Pfx AS-Name >> 1 - AS4961 516762 6.6% 6379.8 -- DISC-AS-KR Daewoo >> Information System >> 2 - AS9767 323141 4.1% 8733.5 -- DONGBUIT-AS-KR Dongbulife >> Insurance co.,LTD >> 3 - AS18157 219917 2.8% 8796.7 -- CHUNGJU-AS-KR chungju >> university >> 4 - AS9459 204123 2.6% 8874.9 -- ASKONKUK Konkuk University >> 5 - AS9956 201087 2.6% 8742.9 -- KONGJU-AS kongju national >> university >> 6 - AS9686 194396 2.5% 8836.2 -- SKKUNET-AS SungKyunKwan >> University (SKKU) >> 7 - AS23716 154216 2.0% 5507.7 -- CHANGWON23716-AS-KR >> Changwon College >> 8 - AS10159 149403 1.9% 5976.1 -- HAUNET-AS-KR HANKUK >> Aviation University >> 9 - AS9530 135249 1.7% 7118.4 -- SHINSEGAE-AS SHINSEGAE I&C >> Co., Ltd. >> 10 - AS9628 122729 1.6% 6459.4 -- SSEM-AS-KR Seoul Education >> Science Research Institute >> 11 - AS9868 99583 1.3% 7113.1 -- CUTH-AS Catholic >> University of DAEGU >> 12 - AS10088 96758 1.2% 8063.2 -- KWANGWOON-UNIV-AS-AP >> KWANGWOON University in Seoul, Korea >> 13 - AS18027 88348 1.1% 8834.8 -- NSU-AS-KR namseoul >> university >> 14 - AS18023 87965 1.1% 3518.6 -- KMU-AS-KR Korea Maritime >> University >> 15 - AS18026 87648 1.1% 8764.8 -- CHEJU-AS-KR Cheju >> University >> 16 - AS17865 87569 1.1% 7960.8 -- SCOURT-AS-KR Supreme Court >> of Korea >> 17 - AS10045 80256 1.0% 8917.3 -- TNUTNET-AS HANBAT NATIONAL >> UNIVERSITY >> 18 - AS9970 79372 1.0% 8819.1 -- KUT-AS Korea University of >> Technology and Education >> 19 - AS10176 79196 1.0% 8799.6 -- TENET-AS Taejon Institute >> of Education Science >> 20 - AS7557 79010 1.0% 8778.9 -- KTNET-AS Korea Trade >> Network >> >> >> TOP 20 Unstable Origin AS (Updates per announced prefix) >> Rank ASN Upds % Upds/Pfx AS-Name >> 1 - AS9456 8920 0.1% 8920.0 -- POSCO-AS POSCO >> 2 - AS10045 80256 1.0% 8917.3 -- TNUTNET-AS HANBAT NATIONAL >> UNIVERSITY >> 3 - AS9846 8908 0.1% 8908.0 -- FIRSTDATA-AS-KR FDIK >> 4 - AS17840 8890 0.1% 8890.0 -- KOREACERT-AS-KR KECA, Inc. >> 5 - AS9571 17776 0.2% 8888.0 -- INICIS-AS INICIS Co., Ltd >> 6 - AS17600 8883 0.1% 8883.0 -- ENVICO-AS-KR Korea >> Environment & Resources Corporation >> 7 - AS10042 17764 0.2% 8882.0 -- DPC-AS-KR DAEGU >> POLYTECHNIC COLLEGE >> 8 - AS9459 204123 2.6% 8874.9 -- ASKONKUK Konkuk University >> 9 - AS10055 35488 0.5% 8872.0 -- KORAIL-AS-KR Korean >> National Railroad Administration >> 10 - AS10058 26615 0.3% 8871.7 -- CU-AS-KR NACUFOK >> 11 - AS23983 26613 0.3% 8871.0 -- DJU-AS-KR Daejeon >> University >> 12 - AS23557 8848 0.1% 8848.0 -- YUHWA-AS-KR Yuhwa >> Securities Co., LTD >> 13 - AS23573 26532 0.3% 8844.0 -- OCIC-AS-KR OCI Information >> Communication >> 14 - AS18324 53042 0.7% 8840.3 -- MASANC-AS-KR Masan College >> 15 - AS23562 17674 0.2% 8837.0 -- BCRC-AS-KR Busan Cycle >> Racing Corporation >> 16 - AS9686 194396 2.5% 8836.2 -- SKKUNET-AS SungKyunKwan >> University (SKKU) >> 17 - AS18027 88348 1.1% 8834.8 -- NSU-AS-KR namseoul >> university >> 18 - AS17601 17664 0.2% 8832.0 -- KCGF-AS-KR KOREA CREDIT >> GUARANTEE FUND >> 19 - AS18319 61824 0.8% 8832.0 -- YJNET-AS-KR Yeungnam >> College of Science & Technology >> 20 - AS9452 8829 0.1% 8829.0 -- KUNET-AS Korea University >> >> >> TOP 20 Unstable Prefixes >> Rank Prefix Upds % Origin AS -- AS Name >> 1 - 210.90.28.0/24 8941 0.1% AS23568 -- CRA-AS-KR Cycle Racing >> Association >> 2 - 163.239.192.0/20 8925 0.1% AS3813 -- SOGANG-AS-KR sogang >> university >> 3 - 163.239.208.0/21 8923 0.1% AS3813 -- SOGANG-AS-KR sogang >> university >> 4 - 163.239.128.0/18 8923 0.1% AS3813 -- SOGANG-AS-KR sogang >> university >> 5 - 163.239.0.0/17 8923 0.1% AS3813 -- SOGANG-AS-KR sogang >> university >> 6 - 210.110.248.0/22 8922 0.1% AS10045 -- TNUTNET-AS HANBAT >> NATIONAL UNIVERSITY >> 7 - 210.98.40.0/22 8920 0.1% AS10045 -- TNUTNET-AS HANBAT >> NATIONAL UNIVERSITY >> 8 - 203.246.186.0/24 8920 0.1% AS9456 -- POSCO-AS POSCO >> 9 - 210.119.112.0/24 8920 0.1% AS10045 -- TNUTNET-AS HANBAT >> NATIONAL UNIVERSITY >> 10 - 203.230.104.0/22 8920 0.1% AS10045 -- TNUTNET-AS HANBAT >> NATIONAL UNIVERSITY >> 11 - 203.230.96.0/21 8918 0.1% AS10045 -- TNUTNET-AS HANBAT >> NATIONAL UNIVERSITY >> 12 - 202.30.46.0/23 8916 0.1% AS10045 -- TNUTNET-AS HANBAT >> NATIONAL UNIVERSITY >> 13 - 220.66.143.0/24 8916 0.1% AS10045 -- TNUTNET-AS HANBAT >> NATIONAL UNIVERSITY >> 14 - 220.66.144.0/22 8912 0.1% AS10045 -- TNUTNET-AS HANBAT >> NATIONAL UNIVERSITY >> 15 - 220.66.148.0/23 8912 0.1% AS10045 -- TNUTNET-AS HANBAT >> NATIONAL UNIVERSITY >> 16 - 210.182.8.0/24 8908 0.1% AS9846 -- FIRSTDATA-AS-KR FDIK >> 17 - 203.252.168.0/24 8899 0.1% AS9459 -- ASKONKUK Konkuk >> University >> 18 - 210.119.217.0/24 8899 0.1% AS9459 -- ASKONKUK Konkuk >> University >> 19 - 203.252.166.0/24 8897 0.1% AS9459 -- ASKONKUK Konkuk >> University >> 20 - 210.119.219.0/24 8897 0.1% AS9459 -- ASKONKUK Konkuk >> University >> >> 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 >> >> >> > > > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit http://www.messagelabs.com/email______________________________________________________________________ > From andrew at parnell.ca Sat Aug 22 00:26:16 2009 From: andrew at parnell.ca (Andrew Parnell) Date: Sat, 22 Aug 2009 01:26:16 -0400 Subject: Alternatives to storm-control on Cat 6509. In-Reply-To: <4A8EBBDF.40909@foobar.org> References: <4A8EBBDF.40909@foobar.org> Message-ID: <2d54a02d0908212226n43a8d875sa19cd0a754d1c071@mail.gmail.com> > > Yes, you replace your 61xx cards with 67xx cards. You can't do this sort > of thing with qos or copp. The 67xx series cards aren't supported by the sup32, though. Would 65xx line cards do the trick? Andrew From cscora at apnic.net Sat Aug 22 02:04:35 2009 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 22 Aug 2009 17:04:35 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <200908220704.n7M74ZCu028065@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 22 Aug, 2009 Report Website: http://thyme.apnic.net Detailed Analysis: http://thyme.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 293735 Prefixes after maximum aggregation: 139010 Deaggregation factor: 2.11 Unique aggregates announced to Internet: 146284 Total ASes present in the Internet Routing Table: 31976 Prefixes per ASN: 9.19 Origin-only ASes present in the Internet Routing Table: 27800 Origin ASes announcing only one prefix: 13547 Transit ASes present in the Internet Routing Table: 4176 Transit-only ASes present in the Internet Routing Table: 100 Average AS path length visible in the Internet Routing Table: 3.6 Max AS path length visible: 24 Max AS path prepend of ASN (12026) 22 Prefixes from unregistered ASNs in the Routing Table: 629 Unregistered ASNs in the Routing Table: 167 Number of 32-bit ASNs allocated by the RIRs: 241 Prefixes from 32-bit ASNs in the Routing Table: 92 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 328 Number of addresses announced to Internet: 2089063616 Equivalent to 124 /8s, 132 /16s and 148 /24s Percentage of available address space announced: 56.4 Percentage of allocated address space announced: 64.5 Percentage of available address space allocated: 87.3 Percentage of address space in use by end-sites: 78.7 Total number of prefixes smaller than registry allocations: 140471 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 70153 Total APNIC prefixes after maximum aggregation: 24877 APNIC Deaggregation factor: 2.82 Prefixes being announced from the APNIC address blocks: 69601 Unique aggregates announced from the APNIC address blocks: 31611 APNIC Region origin ASes present in the Internet Routing Table: 3747 APNIC Prefixes per ASN: 18.58 APNIC Region origin ASes announcing only one prefix: 1023 APNIC Region transit ASes present in the Internet Routing Table: 579 Average APNIC Region AS path length visible: 3.6 Max APNIC Region AS path length visible: 18 Number of APNIC addresses announced to Internet: 481521344 Equivalent to 28 /8s, 179 /16s and 110 /24s Percentage of available APNIC address space announced: 82.0 APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079 APNIC Address Blocks 43/8, 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, 175/8, 180/8, 182/8, 183/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 124497 Total ARIN prefixes after maximum aggregation: 66423 ARIN Deaggregation factor: 1.87 Prefixes being announced from the ARIN address blocks: 125109 Unique aggregates announced from the ARIN address blocks: 52466 ARIN Region origin ASes present in the Internet Routing Table: 13183 ARIN Prefixes per ASN: 9.49 ARIN Region origin ASes announcing only one prefix: 5077 ARIN Region transit ASes present in the Internet Routing Table: 1290 Average ARIN Region AS path length visible: 3.3 Max ARIN Region AS path length visible: 24 Number of ARIN addresses announced to Internet: 1012944512 Equivalent to 60 /8s, 96 /16s and 78 /24s Percentage of available ARIN address space announced: 88.8 ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 53248-55295 ARIN Address Blocks 3/8, 4/8, 6/8, 7/8, 8/8, 9/8, 11/8, 12/8, 13/8, 15/8, 16/8, 17/8, 18/8, 19/8, 20/8, 21/8, 22/8, 24/8, 26/8, 28/8, 29/8, 30/8, 32/8, 33/8, 34/8, 35/8, 38/8, 40/8, 44/8, 45/8, 47/8, 48/8, 52/8, 54/8, 55/8, 56/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8, 98/8, 99/8, 108/8, 173/8, 174/8, 184/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 214/8, 215/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 67501 Total RIPE prefixes after maximum aggregation: 39779 RIPE Deaggregation factor: 1.70 Prefixes being announced from the RIPE address blocks: 67114 Unique aggregates announced from the RIPE address blocks: 45359 RIPE Region origin ASes present in the Internet Routing Table: 13379 RIPE Prefixes per ASN: 5.02 RIPE Region origin ASes announcing only one prefix: 6987 RIPE Region transit ASes present in the Internet Routing Table: 2000 Average RIPE Region AS path length visible: 4.0 Max RIPE Region AS path length visible: 21 Number of RIPE addresses announced to Internet: 499549376 Equivalent to 29 /8s, 198 /16s and 132 /24s Percentage of available RIPE address space announced: 99.3 RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-52223 RIPE Address Blocks 25/8, 51/8, 62/8, 77/8, 78/8, 79/8, 80/8, 81/8, 82/8, 83/8, 84/8, 85/8, 86/8, 87/8, 88/8, 89/8, 90/8, 91/8, 92/8, 93/8, 94/8, 95/8, 109/8, 178/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 24997 Total LACNIC prefixes after maximum aggregation: 6135 LACNIC Deaggregation factor: 4.07 Prefixes being announced from the LACNIC address blocks: 24966 Unique aggregates announced from the LACNIC address blocks: 13957 LACNIC Region origin ASes present in the Internet Routing Table: 1160 LACNIC Prefixes per ASN: 21.52 LACNIC Region origin ASes announcing only one prefix: 375 LACNIC Region transit ASes present in the Internet Routing Table: 188 Average LACNIC Region AS path length visible: 4.1 Max LACNIC Region AS path length visible: 22 Number of LACNIC addresses announced to Internet: 73280448 Equivalent to 4 /8s, 94 /16s and 43 /24s Percentage of available LACNIC address space announced: 72.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: 6210 Total AfriNIC prefixes after maximum aggregation: 1526 AfriNIC Deaggregation factor: 4.07 Prefixes being announced from the AfriNIC address blocks: 6617 Unique aggregates announced from the AfriNIC address blocks: 2630 AfriNIC Region origin ASes present in the Internet Routing Table: 307 AfriNIC Prefixes per ASN: 21.55 AfriNIC Region origin ASes announcing only one prefix: 85 AfriNIC Region transit ASes present in the Internet Routing Table: 69 Average AfriNIC Region AS path length visible: 3.8 Max AfriNIC Region AS path length visible: 15 Number of AfriNIC addresses announced to Internet: 20242944 Equivalent to 1 /8s, 52 /16s and 226 /24s Percentage of available AfriNIC address space announced: 60.3 AfriNIC AS Blocks 36864-37887 & ERX transfers AfriNIC Address Blocks 41/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4766 1724 6979 424 Korea Telecom (KIX) 17488 1554 140 103 Hathway IP Over Cable Interne 4755 1227 292 140 TATA Communications formerly 9583 1088 86 530 Sify Limited 4134 998 18167 389 CHINANET-BACKBONE 18101 959 202 32 Reliance Infocom Ltd Internet 7545 819 198 103 TPG Internet Pty Ltd 9829 807 620 16 BSNL National Internet Backbo 23577 787 34 667 Korea Telecom (ATM-MPLS) 4808 762 1533 176 CNCGROUP IP network: China169 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 4177 3607 314 bellsouth.net, inc. 4323 1908 1049 390 Time Warner Telecom 1785 1728 714 138 PaeTec Communications, Inc. 7018 1492 5875 1052 AT&T WorldNet Services 20115 1471 1474 674 Charter Communications 6478 1381 282 271 AT&T Worldnet Services 2386 1289 657 937 AT&T Data Communications Serv 3356 1210 10979 438 Level 3 Communications, LLC 11492 1110 208 12 Cable One 22773 1086 2604 66 Cox Communications, Inc. Complete listing at http://thyme.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 30890 484 92 197 Evolva Telecom 12479 475 578 6 Uni2 Autonomous System 3292 462 1905 397 TDC Tele Danmark 702 430 1861 346 UUNET - Commercial IP service 35805 380 40 5 United Telecom of Georgia 9198 366 138 12 Kazakhtelecom Data Network Ad 3320 348 7067 301 Deutsche Telekom AG 3215 344 3081 109 France Telecom Transpac 3301 344 1412 308 TeliaNet Sweden 8866 340 109 20 Bulgarian Telecommunication C 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 1475 2882 246 UniNet S.A. de C.V. 10620 990 220 93 TVCABLE BOGOTA 7303 625 332 96 Telecom Argentina Stet-France 28573 619 582 37 NET Servicos de Comunicao S.A 22047 541 302 14 VTR PUNTO NET S.A. 11830 485 308 67 Instituto Costarricense de El 11172 442 99 70 Servicios Alestra S.A de C.V 6471 421 96 31 ENTEL CHILE S.A. 7738 415 858 29 Telecomunicacoes da Bahia S.A 3816 396 191 79 Empresa Nacional de Telecomun Complete listing at http://thyme.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 8452 1002 188 7 TEDATA 24863 917 91 50 LINKdotNET AS number 20858 324 34 6 EgyNet 3741 277 857 237 The Internet Solution 2018 200 180 141 Tertiary Education Network 6713 175 166 16 Itissalat Al-MAGHRIB 33783 152 10 8 EEPAD TISP TELECOM & INTERNET 29571 143 14 6 Ci Telecom Autonomous system 24835 130 46 9 RAYA Telecom - Egypt 5536 122 8 13 Internet Egypt Network Complete listing at http://thyme.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 4177 3607 314 bellsouth.net, inc. 4323 1908 1049 390 Time Warner Telecom 1785 1728 714 138 PaeTec Communications, Inc. 4766 1724 6979 424 Korea Telecom (KIX) 17488 1554 140 103 Hathway IP Over Cable Interne 7018 1492 5875 1052 AT&T WorldNet Services 8151 1475 2882 246 UniNet S.A. de C.V. 20115 1471 1474 674 Charter Communications 6478 1381 282 271 AT&T Worldnet Services 2386 1289 657 937 AT&T Data Communications Serv Complete listing at http://thyme.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 1785 1728 1590 PaeTec Communications, Inc. 4323 1908 1518 Time Warner Telecom 17488 1554 1451 Hathway IP Over Cable Interne 4766 1724 1300 Korea Telecom (KIX) 8151 1475 1229 UniNet S.A. de C.V. 6478 1381 1110 AT&T Worldnet Services 11492 1110 1098 Cable One 4755 1227 1087 TATA Communications formerly 18566 1062 1052 Covad Communications 22773 1086 1020 Cox Communications, Inc. Complete listing at http://thyme.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 16927 UNALLOCATED 12.0.252.0/23 7018 AT&T WorldNet Servic 15132 UNALLOCATED 12.9.150.0/24 7018 AT&T WorldNet Servic 32567 UNALLOCATED 12.14.170.0/24 7018 AT&T WorldNet Servic 13746 UNALLOCATED 12.24.56.0/24 7018 AT&T WorldNet Servic 32567 UNALLOCATED 12.25.107.0/24 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.152.0/24 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.154.0/23 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.159.0/24 7018 AT&T WorldNet Servic 32326 UNALLOCATED 12.40.49.0/24 7018 AT&T WorldNet Servic 25639 UNALLOCATED 12.41.169.0/24 7018 AT&T WorldNet Servic Complete listing at http://thyme.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 24.225.128.0/17 36377 PATRIOT MEDIA AND COMMUNICATI 41.223.92.0/22 36936 >>UNKNOWN<< 41.223.176.0/22 36981 >>UNKNOWN<< 41.223.188.0/24 22351 Intelsat 41.223.189.0/24 26452 Local Communications Networks 43.245.0.0/16 7502 Internetwork Kyoto 43.245.96.0/20 7502 Internetwork Kyoto 43.245.112.0/20 7502 Internetwork Kyoto 43.245.192.0/20 7502 Internetwork Kyoto 43.245.208.0/20 7502 Internetwork Kyoto Complete listing at http://thyme.apnic.net/current/data-add-IANA Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:19 /9:10 /10:24 /11:59 /12:168 /13:351 /14:623 /15:1176 /16:10626 /17:4809 /18:8355 /19:17303 /20:20678 /21:20624 /22:26600 /23:26336 /24:153249 /25:924 /26:1039 /27:585 /28:153 /29:8 /30:7 /31:1 /32:8 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 6389 2707 4177 bellsouth.net, inc. 4766 1412 1724 Korea Telecom (KIX) 17488 1300 1554 Hathway IP Over Cable Interne 1785 1199 1728 PaeTec Communications, Inc. 18566 1043 1062 Covad Communications 11492 1037 1110 Cable One 4323 960 1908 Time Warner Telecom 9583 941 1088 Sify Limited 8452 926 1002 TEDATA 10620 896 990 TVCABLE BOGOTA Complete listing at http://thyme.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 4:14 8:213 12:2138 13:7 15:21 16:3 17:5 20:35 24:1129 32:52 34:2 38:598 40:97 41:1760 43:1 44:2 47:10 52:6 55:2 56:2 57:25 58:621 59:608 60:461 61:973 62:1105 63:2013 64:3624 65:2404 66:3416 67:1740 68:870 69:2729 70:556 71:162 72:1654 73:2 74:1707 75:179 76:314 77:851 78:569 79:372 80:933 81:850 82:598 83:453 84:633 85:1070 86:375 87:674 88:372 89:1462 90:48 91:2499 92:398 93:1114 94:1195 95:1160 96:166 97:264 98:283 99:28 110:185 111:382 112:118 113:152 114:238 115:287 116:1141 117:551 118:330 119:770 120:120 121:651 122:1238 123:755 124:1026 125:1338 128:224 129:219 130:128 131:416 132:75 133:9 134:182 135:43 136:225 137:160 138:170 139:83 140:444 141:123 142:384 143:353 144:388 145:49 146:390 147:156 148:530 149:222 150:208 151:192 152:210 153:148 154:2 155:272 156:167 157:301 158:112 159:344 160:290 161:164 162:269 163:164 164:275 165:529 166:465 167:360 168:701 169:161 170:475 171:41 172:2 173:381 174:316 175:1 178:1 180:7 182:1 186:129 187:164 188:416 189:583 190:2922 192:5784 193:4257 194:3294 195:2689 196:1115 198:3650 199:3364 200:5111 201:1304 202:7744 203:8275 204:3882 205:2166 206:2451 207:2738 208:3929 209:3408 210:2529 211:1103 212:1604 213:1655 214:132 215:30 216:4303 217:1349 218:405 219:415 220:1118 221:461 222:329 End of report From nick at foobar.org Sat Aug 22 04:13:47 2009 From: nick at foobar.org (Nick Hilliard) Date: Sat, 22 Aug 2009 10:13:47 +0100 Subject: Alternatives to storm-control on Cat 6509. In-Reply-To: <2d54a02d0908212226n43a8d875sa19cd0a754d1c071@mail.gmail.com> References: <4A8EBBDF.40909@foobar.org> <2d54a02d0908212226n43a8d875sa19cd0a754d1c071@mail.gmail.com> Message-ID: <4A8FB6CB.9000702@foobar.org> On 22/08/2009 06:26, Andrew Parnell wrote: > The 67xx series cards aren't supported by the sup32, though. Would 65xx > line cards do the trick? unfortunately not: > http://www.cisco.com/en/US/docs/switches/lan/catalyst6500/ios/12.2SXF/native/configuration/guide/storm.html > ? The following LAN switching modules do not support traffic storm control: > ? WS-X6148A-GE-45AF > ? WS-X6148A-GE-TX > ? WS-X6148-GE-45AF > ? WS-X6148-GE-TX > ? WS-X6148V-GE-TX > ? WS-X6548-GE-45AF > ? WS-X6548-GE-TX > ? WS-X6548V-GE-TX Hmmm, expensive proposition to upgrade then - even though sup720 + ws-x67xx cards make a nice l2 platform for gig ethernet. Nick From maillist at webjogger.net Sat Aug 22 08:52:13 2009 From: maillist at webjogger.net (Adam Greene) Date: Sat, 22 Aug 2009 09:52:13 -0400 Subject: Redundancy & Summarization In-Reply-To: <19DA1AC1-312D-4590-B25B-53A62DC3E67F@ianai.net> References: <21D41A38B8859B4A97B1AE2313922B8A810142723D@concertiabl02.concertia.com> <19DA1AC1-312D-4590-B25B-53A62DC3E67F@ianai.net> Message-ID: <4A8FF80D.4020103@webjogger.net> Another option could be to announce one /17 to each upstream provider and use conditional BGP to announce the other /17 to the provider that's still active in the event that one provider goes down. On 8/21/2009 4:08 PM, Patrick W. Gilmore wrote: > On Aug 21, 2009, at 3:47 PM, Brian Dickson wrote: > >>> My institution has a single /16 spread across 2 sites: the lower /17 is >>> used at site A, the upper /17 at site B. Sites A & B are connected >>> internally. Currently both sites have their own ISPs and only >>> advertise >>> their own /17's. For redundancy we proposed that each site advertise >>> both their own /17 and the whole /16, so that an ISP failure at either >>> site would trigger traffic from both /17s to reconverge towards the >>> unaffected location. >> >> There are two different ways to achieve almost-identical results. > > As much as I like Brian, I am going to have to respectfully disagree. > > >> However, one is a 50% more "green" than the other, i.e. friendly to >> other network operators. >> >> These two choices are functionally equivalent, and possible, only >> because things currently work for both your /17's. >> >> Here are the two ways to do this: >> >> One is: >> - announce /17 "A" and /16 from uplink ISP-A >> - announce /17 "B" and /16 from uplink ISP-B >> - This results in 3 prefixes globally: A, B, and /16. >> >> The other is: >> - announce /17 "A" and /17 "B", with different policies (i.e. prepend >> your AS once or twice), at *both* ISPs. >> - This results in 2 prefixes globally: A and B. >> >> In all cases, as long as one ISP link is up, there is a path to both >> A and B. >> In most cases, the best path to A or B, is *mostly*, but not >> completely, under your influence. > > This is highly dependent on variables not in evidence. If your > upstreams are, for instance, Sprint & Level 3, then a large percentage > of the Internet will be traveling through one or the other. And once > it hits your upstream, prepends are irrelevant. Every upstream (for > values of "every" == "100%" to at least one decimal place) localprefs > their downstreams' prefixes. > > In this case, anyone downstream of either L3 or Sprint will send _all_ > traffic through that upstream's link. While not the whole Internet, > it's still quite a bit. Moreover, many people do things like > localpref Sprint _down_ because they are more expensive. So even > someone multi-homed to both may send all traffic through L3. Etc., etc. > > A slight twist on Brian's idea would be to use communities and tell > Upstream A to localpref Prefix B below that of peer routes. Then you > only need two prefixes, and each site only receives its own traffic > except when the other site fails. If Upstream B goes down, Upstream A > will accept Prefix B and propagate it. > > Again, dependent upon your upstreams having communities able to do > this. Or if they are "nimble", maybe a call to their operations > department? > From patrick at ianai.net Sat Aug 22 12:52:32 2009 From: patrick at ianai.net (Patrick W. Gilmore) Date: Sat, 22 Aug 2009 13:52:32 -0400 Subject: Redundancy & Summarization In-Reply-To: <4A8FF80D.4020103@webjogger.net> References: <21D41A38B8859B4A97B1AE2313922B8A810142723D@concertiabl02.concertia.com> <19DA1AC1-312D-4590-B25B-53A62DC3E67F@ianai.net> <4A8FF80D.4020103@webjogger.net> Message-ID: <967B8A05-56F1-4BB4-8B6B-79C14E00DC75@ianai.net> Sent from my iPhone, please excuse any errors. On Aug 22, 2009, at 9:52, Adam Greene wrote: > Another option could be to announce one /17 to each upstream > provider and use conditional BGP to announce the other /17 to the > provider that's still active in the event that one provider goes down. Good idea. Still uses just two prefixes and allows for backup connectivity. Just be careful that the internal routing table does not stop the conditional announcement. -- TTFN, patrick > On 8/21/2009 4:08 PM, Patrick W. Gilmore wrote: >> On Aug 21, 2009, at 3:47 PM, Brian Dickson wrote: >> >>>> My institution has a single /16 spread across 2 sites: the lower / >>>> 17 is >>>> used at site A, the upper /17 at site B. Sites A & B are connected >>>> internally. Currently both sites have their own ISPs and only >>>> advertise >>>> their own /17's. For redundancy we proposed that each site >>>> advertise >>>> both their own /17 and the whole /16, so that an ISP failure at >>>> either >>>> site would trigger traffic from both /17s to reconverge towards the >>>> unaffected location. >>> >>> There are two different ways to achieve almost-identical results. >> >> As much as I like Brian, I am going to have to respectfully disagree. >> >> >>> However, one is a 50% more "green" than the other, i.e. friendly >>> to other network operators. >>> >>> These two choices are functionally equivalent, and possible, only >>> because things currently work for both your /17's. >>> >>> Here are the two ways to do this: >>> >>> One is: >>> - announce /17 "A" and /16 from uplink ISP-A >>> - announce /17 "B" and /16 from uplink ISP-B >>> - This results in 3 prefixes globally: A, B, and /16. >>> >>> The other is: >>> - announce /17 "A" and /17 "B", with different policies (i.e. >>> prepend your AS once or twice), at *both* ISPs. >>> - This results in 2 prefixes globally: A and B. >>> >>> In all cases, as long as one ISP link is up, there is a path to >>> both A and B. >>> In most cases, the best path to A or B, is *mostly*, but not >>> completely, under your influence. >> >> This is highly dependent on variables not in evidence. If your >> upstreams are, for instance, Sprint & Level 3, then a large >> percentage of the Internet will be traveling through one or the >> other. And once it hits your upstream, prepends are irrelevant. >> Every upstream (for values of "every" == "100%" to at least one >> decimal place) localprefs their downstreams' prefixes. >> >> In this case, anyone downstream of either L3 or Sprint will send >> _all_ traffic through that upstream's link. While not the whole >> Internet, it's still quite a bit. Moreover, many people do things >> like localpref Sprint _down_ because they are more expensive. So >> even someone multi-homed to both may send all traffic through L3. >> Etc., etc. >> >> A slight twist on Brian's idea would be to use communities and tell >> Upstream A to localpref Prefix B below that of peer routes. Then >> you only need two prefixes, and each site only receives its own >> traffic except when the other site fails. If Upstream B goes down, >> Upstream A will accept Prefix B and propagate it. >> >> Again, dependent upon your upstreams having communities able to do >> this. Or if they are "nimble", maybe a call to their operations >> department? >> > > > From hectorherrera at gmail.com Sat Aug 22 14:08:52 2009 From: hectorherrera at gmail.com (Hector Herrera) Date: Sat, 22 Aug 2009 12:08:52 -0700 Subject: Redundancy & Summarization In-Reply-To: <4A8FF80D.4020103@webjogger.net> References: <21D41A38B8859B4A97B1AE2313922B8A810142723D@concertiabl02.concertia.com> <19DA1AC1-312D-4590-B25B-53A62DC3E67F@ianai.net> <4A8FF80D.4020103@webjogger.net> Message-ID: On Sat, Aug 22, 2009 at 6:52 AM, Adam Greene wrote: > Another option could be to announce one /17 to each upstream provider and > use conditional BGP to announce the other /17 to the provider that's still > active in the event that one provider goes down. > Maybe I'm wrong, but I think this method will only work when handling local failures. If there is a failure in a remote network which causes ISP A to be unreachable from a third party, your routers will not adjust the announcements since ISP A and B are still reachable to you, but the third party will not be able to reach the network nearer to ISP A through the ISP B connection because ISP B doesn't have an announcement to that network. (This is assuming that ISP A and ISP B are not peers). Hector From sean at donelan.com Sat Aug 22 21:06:23 2009 From: sean at donelan.com (Sean Donelan) Date: Sat, 22 Aug 2009 22:06:23 -0400 (EDT) Subject: Alternatives to storm-control on Cat 6509. In-Reply-To: References: <4A8EBBDF.40909@foobar.org> Message-ID: <200908222143090.32BF5B92.16410@clifden.donelan.com> On Fri, 21 Aug 2009, Roland Dobbins wrote: >> there are two things you care about: storm control and port security (mac >> address counting). > > Chopping up the layer-2 broadcast domain for a given VLAN into smaller pieces > via pVLANs can't hurt, either, as long as the hosts have no need to talk to > one another - and it has other benefits, as well. I understand why hosts need to send broadcasts. In a close/single customer environment, broadcasts could be useful. I hope most future protocol designers now think of using multicast or other discovery mechanisms besides broadcast. But in a service provider network (or any managed network), is there any reason why a customer needs to hear other customer's broadcasts? In practice, are there any useful broadcast messages in a multi-customer environment that can't/shouldn't be proxied by the network operator or handled other ways. From swmike at swm.pp.se Sun Aug 23 01:30:30 2009 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Sun, 23 Aug 2009 08:30:30 +0200 (CEST) Subject: Alternatives to storm-control on Cat 6509. In-Reply-To: <200908222143090.32BF5B92.16410@clifden.donelan.com> References: <4A8EBBDF.40909@foobar.org> <200908222143090.32BF5B92.16410@clifden.donelan.com> Message-ID: On Sat, 22 Aug 2009, Sean Donelan wrote: > But in a service provider network (or any managed network), is there any > reason why a customer needs to hear other customer's broadcasts? In > practice, are there any useful broadcast messages in a multi-customer > environment that can't/shouldn't be proxied by the network operator or > handled other ways. Not that I know of, ISPs have successfully done L2 isolation of customers for 10 years and I haven't heard of any problems with it. Only bad part really is that if the customer is allowed several IPs and you use local-proxy-arp then traffic between customer computers will go via the ISP, which is one of the reasons I advocate the use of a home CPE router for IPv6, it's just a cleaner handoff. -- Mikael Abrahamsson email: swmike at swm.pp.se From sliplever at gmail.com Mon Aug 24 08:00:44 2009 From: sliplever at gmail.com (Dan Snyder) Date: Mon, 24 Aug 2009 09:00:44 -0400 Subject: Data Center testing Message-ID: <1c2d53bb0908240600u1d9bbd48t38023b9900fc4f43@mail.gmail.com> Does any one know of any data centers that do failure testing of their networking equipment regularly? I mean to verify that everything fails over properly after changes have been made over time. Is there any best practice guides for doing this? Thanks, Dan From Rod.Beck at hiberniaatlantic.com Mon Aug 24 08:20:34 2009 From: Rod.Beck at hiberniaatlantic.com (Rod Beck) Date: Mon, 24 Aug 2009 14:20:34 +0100 Subject: [SPAM-HEADER] - Data Center testing - Email has different SMTP TO: and MIME TO: fields in the email addresses References: <1c2d53bb0908240600u1d9bbd48t38023b9900fc4f43@mail.gmail.com> Message-ID: <1E8B940C5E21014AB8BE70B975D40EDB0162870B@bert.HiberniaAtlantic.local> "-----Original Message----- From: Dan Snyder [mailto:sliplever at gmail.com] Sent: Mon 8/24/2009 2:00 PM To: NANOG list Subject: [SPAM-HEADER] - Data Center testing - Email has different SMTP TO: and MIME TO: fields in the email addresses Does any one know of any data centers that do failure testing of their networking equipment regularly? I mean to verify that everything fails over properly after changes have been made over time. Is there any best practice guides for doing this? Thanks, Dan Dan" It is quite surprising how often data centres lose both primary and backup power. From ken.gilmour at gmail.com Mon Aug 24 08:31:13 2009 From: ken.gilmour at gmail.com (Ken Gilmour) Date: Mon, 24 Aug 2009 07:31:13 -0600 Subject: Data Center testing In-Reply-To: <1c2d53bb0908240600u1d9bbd48t38023b9900fc4f43@mail.gmail.com> References: <1c2d53bb0908240600u1d9bbd48t38023b9900fc4f43@mail.gmail.com> Message-ID: <5b6f80200908240631q7f711db5m26a4f195c647aaeb@mail.gmail.com> I know Peer1 in vancouver reguarly send out notifications of "non-impacting" generator load testing, like monthly. Also InterXion in Dublin, Ireland have occasionally sent me notification that there was a power outage of less than a minute however their backup successfully took the load. I only remember one complete outage in Peer1 a few years ago... Never seen any outage in InterXion Dublin. Also I don't ever remember any power failure at AiNet (Deepak will probably elaborate) 2009/8/24 Dan Snyder : > Does any one know of any data centers that do failure testing of their > networking equipment > regularly? I mean to verify that everything fails over properly after > changes have been made over > time. ?Is there any best practice guides for doing this? > > Thanks, > Dan > From sliplever at gmail.com Mon Aug 24 08:38:38 2009 From: sliplever at gmail.com (Dan Snyder) Date: Mon, 24 Aug 2009 09:38:38 -0400 Subject: Data Center testing In-Reply-To: <5b6f80200908240631q7f711db5m26a4f195c647aaeb@mail.gmail.com> References: <1c2d53bb0908240600u1d9bbd48t38023b9900fc4f43@mail.gmail.com> <5b6f80200908240631q7f711db5m26a4f195c647aaeb@mail.gmail.com> Message-ID: <1c2d53bb0908240638t446b0d18tfc711960b84350fc@mail.gmail.com> We have done power tests before and had no problem. I guess I am looking for someone who does testing of the network equipment outside of just power tests. We had an outage due to a configuration mistake that became apparent when a switch failed. It didn't cause a problem however when we did a power test for the whole data center. -Dan On Mon, Aug 24, 2009 at 9:31 AM, Ken Gilmour wrote: > I know Peer1 in vancouver reguarly send out notifications of > "non-impacting" generator load testing, like monthly. Also InterXion > in Dublin, Ireland have occasionally sent me notification that there > was a power outage of less than a minute however their backup > successfully took the load. > > I only remember one complete outage in Peer1 a few years ago... Never > seen any outage in InterXion Dublin. > > Also I don't ever remember any power failure at AiNet (Deepak will > probably elaborate) > > 2009/8/24 Dan Snyder : > > Does any one know of any data centers that do failure testing of their > > networking equipment > > regularly? I mean to verify that everything fails over properly after > > changes have been made over > > time. Is there any best practice guides for doing this? > > > > Thanks, > > Dan > > > From bdfleming at kanren.net Mon Aug 24 10:36:56 2009 From: bdfleming at kanren.net (Brad Fleming) Date: Mon, 24 Aug 2009 10:36:56 -0500 Subject: Best Effort QoS Drop Profile Input Message-ID: <98A5301B-0957-4646-877E-9C48A4710388@kanren.net> Hello all, We are working on fine tuning drop profiles for customer edge routers (Juniper J-2320 in almost all cases) and I was hoping for some input from those who are smarter and have done this before. Basics: - Sites each have a single T1 into a service provider L3 VPN - Queue depth is 500ms - Sites typically will use 90%+ of their line rate while school is in session (education network) - Services offered include: real-time video (in a different queue) and best effort (serviced by the queue in question) - Nearly all BE traffic will be TCP (typical web, email, etc traffic) We were never able to find a good best practice for configuring drop profiles on edge devices. We've been using the following with OK results but I was hoping to have some external, more experienced eyes take a look... drop-profiles { be_any { fill-level 50 drop-probability 5; fill-level 70 drop-probability 20; fill-level 90 drop-probability 50; } Has anyone ever run across a publicly documented best practice for drop profile configuration? Does anyone have suggestions on ways to improve the configuration above? Any input is much appreciated, thanks in advance! -brad fleming From luke.marrott at gmail.com Mon Aug 24 11:17:02 2009 From: luke.marrott at gmail.com (Luke Marrott) Date: Mon, 24 Aug 2009 10:17:02 -0600 Subject: FCCs RFC for the Definition of Broadband Message-ID: <4a9edb810908240917r15739868i93ae029165962e9c@mail.gmail.com> I read an article on DSL Reports the other day ( http://www.dslreports.com/shownews/FCC-Please-Define-Broadband-104056), in which the FCC has a document requesting feedback on the definition of Broadband. What are your thoughts on what the definition of Broadband should be going forward? I would assume this will be the standard definition for a number of years to come. Thanks. -- :Luke Marrott From jbates at brightok.net Mon Aug 24 12:45:41 2009 From: jbates at brightok.net (Jack Bates) Date: Mon, 24 Aug 2009 12:45:41 -0500 Subject: Data Center testing In-Reply-To: <1c2d53bb0908240638t446b0d18tfc711960b84350fc@mail.gmail.com> References: <1c2d53bb0908240600u1d9bbd48t38023b9900fc4f43@mail.gmail.com> <5b6f80200908240631q7f711db5m26a4f195c647aaeb@mail.gmail.com> <1c2d53bb0908240638t446b0d18tfc711960b84350fc@mail.gmail.com> Message-ID: <4A92D1C5.6030802@brightok.net> Dan Snyder wrote: > We have done power tests before and had no problem. I guess I am looking > for someone who does testing of the network equipment outside of just power > tests. We had an outage due to a configuration mistake that became apparent > when a switch failed. It didn't cause a problem however when we did a power > test for the whole data center. > The plus side of failure testing is that it can be controlled. The downside to failure testing is that you can induce a failure. Maintenance windows are cool, but some people really dislike failures of any type which limits how often you can test. I personally try for once a year. However, a lot can go wrong in a year. Jack From dholmes at mwdh2o.com Mon Aug 24 13:03:47 2009 From: dholmes at mwdh2o.com (Holmes,David A) Date: Mon, 24 Aug 2009 11:03:47 -0700 Subject: Alternatives to storm-control on Cat 6509. In-Reply-To: References: Message-ID: <485ED9BA02629E4BBBA53AC892EDA50E097F98B2@usmsxt104.mwd.h2o> In my opinion the Sup32 platform has some limitations when the technology is considered for high data rate, deterministic carrier customer-facing scenarios. Cisco sells the Sup32 as a wiring closet aggregation switch the main purpose of which is to connect desktop users to central core switches. In addition to the lack of storm-control/broadcast suppression mentioned below, the 61XX line cards also have a limit of, I believe, 2 ports in an Etherchannel. Additionally, and perhaps most significantly for deterministic network design, the copper cards share input hardware buffers for every 8 ports. Running one port of the 8 at wire speed will cause input drops on the other 7 ports. Also, the cards connect to the older 32 Gbps shared bus. In my view, with high data rates, it is difficult, if not impossible, to build a deterministic network with Sup32s. Cisco's solution for designing a deterministic network is the sup720 which has a 720 Gbps crossbar bus. The 67XX 48 port copper line cards have 2 20 Gbps connectors to the 720 Gbps bus, the 24 port fiber sfp line cards have a single 20 Gbps connector to the crossbar bus, and the 10 GiG 67XX line cards have 2 20 Gbps bus connectors. The crossbar bus connects line card connectors to each other in a point-to-point fashion. 67XX line cards are adequately provisioned with input and output buffers. There is still 40/48 (1 GiGE copper), 20/24 (1 GiGE sfp), and 40/160 (10 GiGE X2) oversubscription of ports to switch fabric connectors, however. Sup720 routing table lookups via Ternary Content Addressable Memory (TCAM) still use the 32 Gbps bus to access the TCAM to search for next hop for destination IP network. -----Original Message----- From: Peter George [mailto:Peter.George at lumison.net] Sent: Friday, August 21, 2009 3:40 AM To: nanog at nanog.org Subject: Alternatives to storm-control on Cat 6509. Hello, I have several Catalyst 6500 (Supervisor 32) aggregation switches with WS-X6148A-GE-TX and WS-X6148-GE-TX line cards. These line cards do not support storm-control/broadcast suppression. This impacted us badly during a recent spanning tree event. As it stands, we are at risk of overwhelming control planes with excess broadcast or multicast traffic, and I need to find alternative ways to protect these switches. I have been researching STP enhancements, and control-plane policing in the following documents, and would appreciate advice from engineers who may have had to implement similar workarounds for storm-control in a service provider setting. * Configuring Denial of Service Protection http://www.cisco.com/en/US/docs/switches/lan/catalyst6500/ios/12.2SX/con figuration/guide/dos.pdf * Configuring Control Plane Policing http://www.cisco.com/en/US/docs/switches/lan/catalyst4500/12.2/31sga/con figuration/guide/cntl_pln.pdf * Configuring Optional STP Features http://www.cisco.com/en/US/docs/switches/lan/catalyst4500/12.2/31sga/con figuration/guide/stp_enha.pdf So, if we can't mitigate against STP events using storm-control or broadcast suppression, what might be the best combination of STP enhancements and control-plane policing? For example, is it possible to rate-limit broadcast/multicast, STP and ARP on a per VLAN basis? If so, how? Many thanks, P -- Peter George Lumison t: 0845 1199 900 d: 0131 514 4022 P.S. Lumison have changed the way businesses communicate forever http://www.unified-communications.net/ ________________________________ -- 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 sender. Any offers or quotation of service are subject to formal specification. Errors and omissions excepted. Please note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Lumison. Finally, the recipient should check this email and any attachments for the presence of viruses. Lumison accept no liability for any damage caused by any virus transmitted by this email. From rdobbins at arbor.net Mon Aug 24 13:16:22 2009 From: rdobbins at arbor.net (Roland Dobbins) Date: Tue, 25 Aug 2009 01:16:22 +0700 Subject: Alternatives to storm-control on Cat 6509. In-Reply-To: <485ED9BA02629E4BBBA53AC892EDA50E097F98B2@usmsxt104.mwd.h2o> References: <485ED9BA02629E4BBBA53AC892EDA50E097F98B2@usmsxt104.mwd.h2o> Message-ID: <9C80A4B0-ECCC-4303-8EC7-83759B6D4EF2@arbor.net> On Aug 25, 2009, at 1:03 AM, Holmes,David A wrote: > In my opinion the Sup32 platform has some limitations when the > technology is considered for high data rate, deterministic carrier > customer-facing scenarios The hardware-based FPM is interesting. ----------------------------------------------------------------------- Roland Dobbins // Sorry, sometimes I mistake your existential crises for technical insights. -- xkcd #625 From swmike at swm.pp.se Mon Aug 24 14:07:00 2009 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Mon, 24 Aug 2009 21:07:00 +0200 (CEST) Subject: Best Effort QoS Drop Profile Input In-Reply-To: <98A5301B-0957-4646-877E-9C48A4710388@kanren.net> References: <98A5301B-0957-4646-877E-9C48A4710388@kanren.net> Message-ID: On Mon, 24 Aug 2009, Brad Fleming wrote: > We were never able to find a good best practice for configuring drop > profiles on edge devices. We've been using the following with OK results > but I was hoping to have some external, more experienced eyes take a > look... > > drop-profiles { > be_any { > fill-level 50 drop-probability 5; > fill-level 70 drop-probability 20; > fill-level 90 drop-probability 50; > } > > Has anyone ever run across a publicly documented best practice for drop > profile configuration? Does anyone have suggestions on ways to improve > the configuration above? > > Any input is much appreciated, thanks in advance! I think it's fine, personally I've been known to configure core network WRED with 0% drop at 40ms and 100% drop at 60ms (reasoning is that basically no application will be well suited by having its packets delayed much more than 40ms), though at the lower speeds you have, your values are probably better. Hm, just realised your "fill level" is in percent, right? Then I'd stop dropping packets earler if I were you, having 0% drop up until 250ms is not really helping interactive applications, you probably want to induce drop earlier (at 40ms or so), so file transfers don't fill up the buffer but hopefully the fewer packets/s of an ssh session still has low probability of being dropped (and fast-retransmit can do it's job fairly unnoticable to the user). So in your case, I'd have the first drop-probability much sooner, at 10% if you have 500ms buffering. Perhaps starting with a 1% at 10% and 3% at 20% buffer fill rate. -- Mikael Abrahamsson email: swmike at swm.pp.se From tmaufer at gmail.com Mon Aug 24 14:21:33 2009 From: tmaufer at gmail.com (Thomas Maufer) Date: Mon, 24 Aug 2009 12:21:33 -0700 Subject: new collaborative network forensics tool for massive pcap libraries Message-ID: I wanted to share with the NANOG community this likely interesting bit of pcap wrangling technology that Mu announced yesterday. Here is the announcement on the new network forensics application within pcapr : Collaborative Network Forensics Mu Dynamics ( http://www.mudynamics.com/ ) took the recently published dataset by the *U.S. Army Information Technology & Operations Center* ( ITOC ) from the ?2009 Inter-Service Academy Cyber Defense Competition? as well as the *Schmoo Group?s* ?Capture the Capture the Flag? ( CCTF ) dataset (for a grand total of *15.0 GBytes?26.3 million packets*), and indexed them all to enable contextual search and instant access to packets, not to mention Hacker-News/Twitter-style one-liners attached to packets and searches for a community-oriented collaborative forensics application. Check it out (read the blog, linked below, first): - http://bit.ly/12I62D for the blog and - http://www.pcapr.net/forensics for the online app Enjoy! A brief background on pcapr: It?s a web-based pcap repository (hence, pcapr) that has some powerful pcap manipulation capabilities. The pcaps on pcapr are fully decoded and editable and you can manipulate them in novel ways: You can identify and isolate or decode streams, remove garbage from the pcap (i.e., extraneous packets from protocols that you aren?t interested in), reorder packets, save subset or modified pcaps without destroying the original, etc. All this happens at http://www.pcapr.net/, which is open to the public. If you can access the web, you can access the pcapr database and upload your own local pcaps for analysis. All registered users can upload up to 5 pcaps into a scratch space that is private to them. There are currently *250*protocols represented on pcapr across over 1500 pcaps, in addition to the forensics application with its 26.3 million packets. Finally, a free denial-of-service traffic generator is available on pcapr; you can turn any packet you find on pcapr into a DoS template. All the best, ~tom -- Thomas Maufer Mu Dynamics, Inc. Mu Line Blog: http://bit.ly/mu-line-blog * Dir., Tech. Mktg. Mu Labs Blog: http://bit.ly/mu-labs-blog * Solutions Architect Mu on twitter: http://bit.ly/mu-twitter Mu on YouTube: http://bit.ly/mu-youtube Mu on Facebook: http://bit.ly/mu-on-facebook Mu Community sign-up: http://bit.ly/mu-community-signup Got packets? Use pcapr: http://bit.ly/pcapr Email to Thomas Maufer: mailto: tmaufer at mudynamics.com From warren at kumari.net Mon Aug 24 15:02:44 2009 From: warren at kumari.net (Warren Kumari) Date: Mon, 24 Aug 2009 16:02:44 -0400 Subject: ISP Security BOF -- NAOG 47 Message-ID: <8CFF8797-EF8F-401B-A4E2-898CEE0B7C87@kumari.net> "The time has come," the Walrus said, "To talk of many things", like how NANOG 47 is fast approaching and how I am *sure* that you would like to participate... This is *your* chance to talk about interesting security related topics and provide some feedback on what you would (and would not) like to hear about... Some security thing been buggin' you all year? Some topic that you feel strongly about and would like a change to inform others about? Step right up and give a talk -- this BOF is traditionally fairly laid back and easy going, so its a low stress introduction to presenting... Slides are welcome, but not required... W From deepak at ai.net Mon Aug 24 15:03:51 2009 From: deepak at ai.net (Deepak Jain) Date: Mon, 24 Aug 2009 16:03:51 -0400 Subject: Data Center testing In-Reply-To: <5b6f80200908240631q7f711db5m26a4f195c647aaeb@mail.gmail.com> References: <1c2d53bb0908240600u1d9bbd48t38023b9900fc4f43@mail.gmail.com> <5b6f80200908240631q7f711db5m26a4f195c647aaeb@mail.gmail.com> Message-ID: Thanks for the kind words Ken. Power failure testing and network testing are very different disciplines. We operate from the point of view that if a failure occurs because we have scheduled testing, it is far better since we have the resources on-site to address it (as opposed to an unplanned event during a hurricane). Not everyone has this philosophy. This is one of the reasons we do monthly or bimonthly, full live load transfer tests on power at every facility we own and control during the morning hours (~10:00am local time on a weekday, run on gensets for up to two hours). Of course there is sufficient staff and contingency planning on-site to handle almost anything that comes up. The goal is to have a measurable "good" outcome at our highest reasonable load levels [temperature, data load, etc]. We don't hesitate to show our customers and auditors our testing and maintenance logs, go over our procedures, etc. They can even watch events if they want (we provide the ear protection). I don't think any facility of any significant size can operate differently and do it well. This is NOT advisable to folks who do not do proper preventative maintenance on their transfer bus ways, PDUs, switches, batteries, transformers and of course generators. The goal is to identify questionable relays, switches, breakers and other items that may fail in an actual emergency. On the network side, during scheduled maintenance we do live failovers -- sometimes as dramatic as pulling the cable without preemptively removing traffic. Part of *our* procedures is to make sure it reroutes and heals the way it is supposed to before the work actually starts. Often network and topology changes happen over time and no one has had a chance to actually test all the "glue" works right. Regular planned maintenance (if you have a fast reroute capability in your network) is a very good way to handle it. For sensitive trunk links and non-invasive maintenance, it is nice to softly remove traffic via local pref or whatever in advance of the maintenance to minimize jitter during a major event. As part of your plan, be prepared for things like connectors (or cables) breaking and have a plan for what you do if that occurs. Have a plan or a rain-date if a connector takes a long time to get out or the blade it sits in gets damaged. This stuff looks pretty while its running and you don't want something that has been friction-frozen to ruin your window. All of this works swimmingly until you find a vendor (X) bug. :) Not for the faint-of-heart. Anyone who has more specific questions, I'll be glad to answer off-line. Deepak Jain AiNET > I know Peer1 in vancouver reguarly send out notifications of > "non-impacting" generator load testing, like monthly. Also InterXion > in Dublin, Ireland have occasionally sent me notification that there > was a power outage of less than a minute however their backup > successfully took the load. > > I only remember one complete outage in Peer1 a few years ago... Never > seen any outage in InterXion Dublin. > > Also I don't ever remember any power failure at AiNet (Deepak will > probably elaborate) > > 2009/8/24 Dan Snyder : > > Does any one know of any data centers that do failure testing of > their > > networking equipment > > regularly? I mean to verify that everything fails over properly after > > changes have been made over > > time. ?Is there any best practice guides for doing this? > > > > Thanks, > > Dan > > From nick at foobar.org Mon Aug 24 15:59:59 2009 From: nick at foobar.org (Nick Hilliard) Date: Mon, 24 Aug 2009 21:59:59 +0100 Subject: Alternatives to storm-control on Cat 6509. In-Reply-To: <485ED9BA02629E4BBBA53AC892EDA50E097F98B2@usmsxt104.mwd.h2o> References: <485ED9BA02629E4BBBA53AC892EDA50E097F98B2@usmsxt104.mwd.h2o> Message-ID: <4A92FF4F.9000109@foobar.org> On 24/08/2009 19:03, Holmes,David A wrote: > Additionally, and perhaps most significantly for deterministic network > design, the copper cards share input hardware buffers for every 8 ports. > Running one port of the 8 at wire speed will cause input drops on the > other 7 ports. Also, the cards connect to the older 32 Gbps shared bus. IMO, a more serious problem with the 6148tx and 6548tx cards is the internal architecture, which is effectively six internal managed gigabit ethernet hubs (i.e. shared bus) with a 1M buffer per hub, and each hub connected with a single 1G uplink to a 32 gig backplane. Ref: > http://www.cisco.com/en/US/products/hw/switches/ps700/products_tech_note09186a00801751d7.shtml#ASIC In Cisco's own words: "These line cards are oversubscription cards that are designed to extend gigabit to the desktop and might not be ideal for server farm connectivity". In other words, these cards are fine in their place, but they are not designed or suitable for data centre usage. I don't want to sound like I'm damning this card beyond redemption - it has a useful place in this world - but at the expense of reliability, manageability and configuration control, you will get useful features (including broadcast/unicast flood control) and in many situations very significantly better performance from a recent SRW 48-port linksys gig switch than from one of these cards. Nick From tom at dyn.com Mon Aug 24 16:23:30 2009 From: tom at dyn.com (Tom Daly) Date: Mon, 24 Aug 2009 17:23:30 -0400 (EDT) Subject: [NANOG-announce] Reminder - NANOG 47 is coming quickly! In-Reply-To: <31675904.38721251148903636.JavaMail.root@mail.corp> Message-ID: <17888119.38741251149010116.JavaMail.root@mail.corp> Hello Everyone, NANOG 47 is only 7 weeks away! The PC has been busily reviewing talks in preparation for the meeting. If you're interested in submitting a talk, please see: - http://nanog.org/meetings/nanog47/callforpresent.php. Also, registration is open and the hotel is ready for booking, please see: - https://nanog.merit.edu/registration. - http://nanog.org/meetings/nanog47/hotel.php Finally, NANOG is always looking for great sponsors, and we always have room for more: - http://nanog.org/sponsors Looking forward to seeing everyone in Dearborn. Thanks, Tom Daly (for the PC) _______________________________________________ NANOG-announce mailing list NANOG-announce at nanog.org http://mailman.nanog.org/mailman/listinfo/nanog-announce From jb at langports.com Mon Aug 24 17:30:16 2009 From: jb at langports.com (Juraj Benak) Date: Tue, 25 Aug 2009 08:30:16 +1000 Subject: email address and SMTP server Message-ID: Good morning, I'm having a problem with my SMTP server installed on W2k3 server. Before we used SMTP of our ISP but because messages were delayed by few hours on regular basis I decided to install SMTP server (Exchange server installation is busted and will have to reinstall the server to get it work). For now I have a problem with one address which is working from my ISP's SMTP server but not from my server. I have setup my ISP's DNS servers and there isn't problem with other recipients, only this one. I tried to check the domain record for that email and it was OK. I checked via MX record database what servers they are using and the servers were fine as well. I got this response: Final-Recipient: rfc822; Action: failed Status: 4.4.7 Is there any way how to check it or can you tell me what could be the problem? The domain is boomerangaustralia.com. Thanks Juraj From sethm at rollernet.us Mon Aug 24 17:40:42 2009 From: sethm at rollernet.us (Seth Mattinen) Date: Mon, 24 Aug 2009 15:40:42 -0700 Subject: Data Center testing In-Reply-To: References: <1c2d53bb0908240600u1d9bbd48t38023b9900fc4f43@mail.gmail.com> <5b6f80200908240631q7f711db5m26a4f195c647aaeb@mail.gmail.com> Message-ID: <4A9316EA.3050409@rollernet.us> Deepak Jain wrote: > Thanks for the kind words Ken. > > Power failure testing and network testing are very different disciplines. > > We operate from the point of view that if a failure occurs because we have scheduled testing, it is far better since we have the resources on-site to address it (as opposed to an unplanned event during a hurricane). Not everyone has this philosophy. > > This is one of the reasons we do monthly or bimonthly, full live load transfer tests on power at every facility we own and control during the morning hours (~10:00am local time on a weekday, run on gensets for up to two hours). Of course there is sufficient staff and contingency planning on-site to handle almost anything that comes up. The goal is to have a measurable "good" outcome at our highest reasonable load levels [temperature, data load, etc]. > At least once a year I like to go out and kick the service entrance breaker to give the whole enchilada an honest to $diety plugs out test. As you said, not recommenced if you don't maintain stuff, but that's how confident I feel that my system works. ~Seth From deepak at ai.net Mon Aug 24 17:50:13 2009 From: deepak at ai.net (Deepak Jain) Date: Mon, 24 Aug 2009 18:50:13 -0400 Subject: Data Center testing In-Reply-To: <4A9316EA.3050409@rollernet.us> References: <1c2d53bb0908240600u1d9bbd48t38023b9900fc4f43@mail.gmail.com> <5b6f80200908240631q7f711db5m26a4f195c647aaeb@mail.gmail.com> <4A9316EA.3050409@rollernet.us> Message-ID: > At least once a year I like to go out and kick the service entrance > breaker to give the whole enchilada an honest to $diety plugs out test. > As you said, not recommenced if you don't maintain stuff, but that's > how > confident I feel that my system works. Nature has a way of testing it, even if you don't. :) For those who haven't seen this occur, make sure you have a plan in case your breaker doesn't flip back to the normal position, or your transfer switch stops switching (in either direction -- for example, it fuses itself into the "generator/emergency" position). For small supplies (say <1MW) it's not as big a deal, but when the breakers in a bigger facility can weigh hundreds of pounds each and can take months to replace, these are real issues and will test your sparing, consistency and other disciplines. Deepak Jain AiNET From jaitken at aitken.com Tue Aug 25 07:53:10 2009 From: jaitken at aitken.com (Jeff Aitken) Date: Tue, 25 Aug 2009 12:53:10 +0000 Subject: Data Center testing In-Reply-To: <1c2d53bb0908240638t446b0d18tfc711960b84350fc@mail.gmail.com> References: <1c2d53bb0908240600u1d9bbd48t38023b9900fc4f43@mail.gmail.com> <5b6f80200908240631q7f711db5m26a4f195c647aaeb@mail.gmail.com> <1c2d53bb0908240638t446b0d18tfc711960b84350fc@mail.gmail.com> Message-ID: <20090825125310.GA67051@eagle.aitken.com> On Mon, Aug 24, 2009 at 09:38:38AM -0400, Dan Snyder wrote: > We have done power tests before and had no problem. I guess I am looking > for someone who does testing of the network equipment outside of just power > tests. We had an outage due to a configuration mistake that became apparent > when a switch failed. It didn't cause a problem however when we did a power > test for the whole data center. Dan, With all due respect, if there are config changes being made to your devices that aren't authorized or in accordance with your standards (you *do* have config standards, right?) then you don't have a testing problem, you have a data integrity problem. Periodically inducing failures to catch them is sorta like using your smoke detector as an oven timer. There are several tools that can help in this area; a good free one is rancid [1], which logs in to your routers and collects copies of configs and other info, all of which gets stored in a central repository. By default, you will be notified via email of any changes. An even better approach than scanning the hourly config diff emails is to develop scripts that compare the *actual* state of the network with the *desired* state and alert you if the two are not in sync. Obviously this is more work because you have to have some way of describing the desired state of the network in machine-parsable format, but the benefit is that you know in pseudo-realtime when something is wrong, as opposed to finding out the next time a device fails. Rancid diffs + tacacs logs will tell you who made the changes, and with that info you can get at the root of the problem. Having said that, every planned maintenance activity is an opportunity to run through at least some failure cases. If one of your providers is going to take down a longhaul circuit, you can observe how traffic re-routes and verify that your metrics and/or TE are doing what you expect. Any time you need to load new code on a device you can test that things fail over appropriately. Of course, you have to willing to just shut the device down without draining it first, but that's between you and your customers. Link and/or device failures will generate routing events that could be used to test convergence times across your network, etc. The key is to be prepared. The more instrumentation you have in place prior to the test, the better you will be able to analyze the impact of the failure. An experienced operator can often tell right away when looking at a bunch of MRTG graphs that "something doesn't look right", but that doesn't tell you *what* is wrong. There are tools (free and commercial) that can help here, too. Have a central syslog server and some kind of log reduction tool in place. Have beacons/probes deployed, in both the control and data planes. If you want to record, analyze, and even replay routing system events, you might want to take a look at the Route Explorer product from Packet Design [2]. You said "switch failure" above, so I'm guessing that this doesn't apply to you, but there are also good network simulation packages out there. Cariden [3] and WANDL [4] can build models of your network based on actual router configs and let you simulate the impact of various scenarios, including device/link failures. However, these tools are more appropriate for design and planning than for catching configuration mistakes, so they may not be what you're looking for in this case. --Jeff [1] http://www.shrubbery.net/rancid/ [2] http://www.packetdesign.com/products/rex.htm [3] http://www.cariden.com/ [4] http://www.wandl.com/html/index.php From trainier at kalsec.com Tue Aug 25 08:40:53 2009 From: trainier at kalsec.com (trainier at kalsec.com) Date: Tue, 25 Aug 2009 09:40:53 -0400 Subject: SORBS? Message-ID: I need a SORBS maintainer to contact me. The SORBS site reports the site and databases are in maintenance mode for the second day in a row. One of my domains was legitimately listed, but now that I've resolved the problem, I'm unable to request removal. Regards, Tim R. Rainier Systems Administrator II Kalsec Inc. www.kalsec.com From jlewis at lewis.org Tue Aug 25 09:12:38 2009 From: jlewis at lewis.org (Jon Lewis) Date: Tue, 25 Aug 2009 10:12:38 -0400 (EDT) Subject: SORBS? In-Reply-To: References: Message-ID: On Tue, 25 Aug 2009 trainier at kalsec.com wrote: > I need a SORBS maintainer to contact me. > > The SORBS site reports the site and databases are in maintenance mode for > the second day in a row. One of my domains was legitimately listed, but > now that I've resolved the problem, I'm unable to request removal. Based on info previously posted to the SORBS web site, I suspect SORBS may be in the middle of relocating their servers (changing hosting providers). If that's the case, I don't think you're going to have any luck getting changes made to the SORBS database until the move has been completed. ---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From marc at ena.com Tue Aug 25 09:35:43 2009 From: marc at ena.com (Marc Powell) Date: Tue, 25 Aug 2009 09:35:43 -0500 Subject: SORBS? In-Reply-To: References: Message-ID: <31A09AB8-B567-49E4-8420-8E0F4D1B1FD8@ena.com> On Aug 25, 2009, at 8:40 AM, trainier at kalsec.com wrote: > I need a SORBS maintainer to contact me. I don't think they watch here; at least I've never seen Michelle post here. Try dnsbl-users, the SORBS mailling list. From the google cache of the Mailling Lists page -- "This list is an open list where the SORBS DNSbl may be discussed. If it is about the SORBS DNSbl it is on topic (including questions on how to configure mailers to use SORBS). Currently this list is quiet, un- moderated, and anyone is free to join. Non-members of the list are not permitted to send mail to the list. For people who don't know the meaning of "confirmed opt-in" ("double opt-in" as most spammers call it), subscribe to this list and you will see how it works. Subscription is performed by sending a message to: majordomo at dnsbl.sorbs.net with a message body of: subscribe dnsbl-users end " From trainier at kalsec.com Tue Aug 25 09:45:32 2009 From: trainier at kalsec.com (trainier at kalsec.com) Date: Tue, 25 Aug 2009 10:45:32 -0400 Subject: SORBS? In-Reply-To: <31A09AB8-B567-49E4-8420-8E0F4D1B1FD8@ena.com> References: <31A09AB8-B567-49E4-8420-8E0F4D1B1FD8@ena.com> Message-ID: Thanks for the replies. I will use the mailing list if my issue doesn't get resolved. Regards, Tim R. Rainier Systems Administrator II Kalsec Inc. www.kalsec.com Marc Powell wrote on 08/25/2009 10:35:43 AM: > From: > > Marc Powell > > To: > > NANOG list > > Date: > > 08/25/2009 10:36 AM > > Subject: > > Re: SORBS? > > > On Aug 25, 2009, at 8:40 AM, trainier at kalsec.com wrote: > > > I need a SORBS maintainer to contact me. > > I don't think they watch here; at least I've never seen Michelle post > here. Try dnsbl-users, the SORBS mailling list. From the google cache > of the Mailling Lists page -- > > "This list is an open list where the SORBS DNSbl may be discussed. If > it is about the SORBS DNSbl it is on topic (including questions on how > to configure mailers to use SORBS). Currently this list is quiet, un- > moderated, and anyone is free to join. Non-members of the list are not > permitted to send mail to the list. > > For people who don't know the meaning of "confirmed opt-in" ("double > opt-in" as most spammers call it), subscribe to this list and you will > see how it works. > > Subscription is performed by sending a message to: majordomo at dnsbl.sorbs.net > with a message body of: > subscribe dnsbl-users > end > " > > > From graeme at graemef.net Tue Aug 25 09:48:52 2009 From: graeme at graemef.net (Graeme Fowler) Date: Tue, 25 Aug 2009 15:48:52 +0100 Subject: SORBS? In-Reply-To: <31A09AB8-B567-49E4-8420-8E0F4D1B1FD8@ena.com> References: <31A09AB8-B567-49E4-8420-8E0F4D1B1FD8@ena.com> Message-ID: <1251211733.24760.12.camel@squonk.lboro.ac.uk> On Tue, 2009-08-25 at 09:35 -0500, Marc Powell wrote: > I don't think they watch here; at least I've never seen Michelle post > here. I've had confirmation from Michelle personally this morning (following a similar question elsewhere) that the SORBS systems are indeed relocating. From a previous message to SPAM-L (reproduced with permission): Michelle Sullivan wrote: > SORBS is not closing. SORBS has received 3 credible offers for the > purchase of SORBS, one of which was not interested in continuing SORBS > but obtaining the IP and spamtraps. SORBS will not be accepting the > latter offer. > > Currently the two offers being considered are with anti-spam vendors > and one of the two have indicated that they will not commercialise > SORBS, but keep it as a community project. The other anti-spam vendor > have indicated they would pursue a split commercial model, where there > would be a free service as well as a 'premium' service (how this would > work I do not know). > > An announcement about which company is successful will be forthcoming > when necessary paperwork has been signed. > > Small outages will occur in the central database when the servers are > moved, this will NOT affect SORBS services globally, only updates > (listing and delisting) and local (Au) services during the outages. As inconvenient as this outage may be, the background to it is one with which a large proportion of this list is probably bearing scars - physical relocation. On a related note, no I don't have any information as to who it is that has taken SORBS on. Regards, Graeme From mob at bartzfamily.net Tue Aug 25 15:21:42 2009 From: mob at bartzfamily.net (Mike Bartz) Date: Tue, 25 Aug 2009 16:21:42 -0400 Subject: Alternatives to storm-control on Cat 6509. In-Reply-To: <4A92FF4F.9000109@foobar.org> References: <485ED9BA02629E4BBBA53AC892EDA50E097F98B2@usmsxt104.mwd.h2o> <4A92FF4F.9000109@foobar.org> Message-ID: <82a67ea80908251321u2217d3en30bff225bd7ccf8a@mail.gmail.com> On Mon, Aug 24, 2009 at 4:59 PM, Nick Hilliard wrote: > On 24/08/2009 19:03, Holmes,David A wrote: > >> Additionally, and perhaps most significantly for deterministic network >> design, the copper cards share input hardware buffers for every 8 ports. >> Running one port of the 8 at wire speed will cause input drops on the >> other 7 ports. Also, the cards connect to the older 32 Gbps shared bus. >> > > IMO, a more serious problem with the 6148tx and 6548tx cards is the > internal architecture, which is effectively six internal managed gigabit > ethernet hubs (i.e. shared bus) with a 1M buffer per hub, and each hub > connected with a single 1G uplink to a 32 gig backplane. Ref: > > >> http://www.cisco.com/en/US/products/hw/switches/ps700/products_tech_note09186a00801751d7.shtml#ASIC >> > > In Cisco's own words: "These line cards are oversubscription cards that are > designed to extend gigabit to the desktop and might not be ideal for server > farm connectivity". In other words, these cards are fine in their place, > but they are not designed or suitable for data centre usage. > > I don't want to sound like I'm damning this card beyond redemption - it has > a useful place in this world - but at the expense of reliability, > manageability and configuration control, you will get useful features > (including broadcast/unicast flood control) and in many situations very > significantly better performance from a recent SRW 48-port linksys gig > switch than from one of these cards. > > Nick > > We experienced the joy of using the X6148 cards with a SAN/ESX cluster. Lots of performance issues! A fairly inexpensive solution was to switch to the X6148A card instead, which does not suffer the the 8:1 oversubscription. It also supports MTU's larger than 1500, which was another shortcoming of the older card. Mike -- Mike Bartz mob at bartzfamily.net From nonobvious at gmail.com Tue Aug 25 16:41:02 2009 From: nonobvious at gmail.com (Bill Stewart) Date: Tue, 25 Aug 2009 14:41:02 -0700 Subject: FCCs RFC for the Definition of Broadband In-Reply-To: <4a9edb810908240917r15739868i93ae029165962e9c@mail.gmail.com> References: <4a9edb810908240917r15739868i93ae029165962e9c@mail.gmail.com> Message-ID: <18a5e7cb0908251441g42ebf014u80e76c89cf651bfe@mail.gmail.com> It's not a technical question, it's a political one, so feel free to squelch this for off-topicness if you want. Technically, broadband is "faster than narrowband", and beyond that it's "fast enough for what you're trying to sell"; tell me what you're trying to sell and I'll tell you how fast a connection you need.
  • If you're trying to sell email, VOIP, and lightly-graphical web browsing, 64kbps is enough, and 128 is better.
  • If you're trying to sell wireless data excluding laptop tethering, that's also fast enough for anything except maybe uploading hi-res camera video.
  • If you're trying to sell talking-heads video conferencing, 128's enough but 384's better.
  • If you're trying to sell internet radio, somewhere around 300 is probably enough.
  • If you're trying to sell online gaming, you'll need to find a WoW addict; I gather latency's a bit more of an issue than bandwidth for most people.
  • If you're trying to sell home web servers - oh wait, they're not! - 100-300k's usually enough, unless you get slashdotted, in which case you need 50-100Mbps for a couple of hours.
  • If you're trying to sell Youtube-quality video, 1 Mbps is enough, 3 Mbps is better.
  • If you're trying to sell television replacement, 10M's about enough for one HD channel, 20's better, but the real question is what kind of multicast upstream infrastructure you're using to manage the number of channels you're selling, and whether you're price-competitive with cable, satellite, or radio broadcast, and how well you get along with your city and state regulators who'd like a piece of the action.
  • If what you're trying to sell is "the relevance of the FCC to the Democratic political machines", the answer is measured in TV-hours, newspaper-inches, and letters to Congresscritters, which isn't my problem.
From fred at cisco.com Tue Aug 25 18:30:32 2009 From: fred at cisco.com (Fred Baker) Date: Tue, 25 Aug 2009 16:30:32 -0700 Subject: FCCs RFC for the Definition of Broadband In-Reply-To: <4a9edb810908240917r15739868i93ae029165962e9c@mail.gmail.com> References: <4a9edb810908240917r15739868i93ae029165962e9c@mail.gmail.com> Message-ID: <41A99CED-7857-4E24-B536-31493DE2EB99@cisco.com> On Aug 24, 2009, at 9:17 AM, Luke Marrott wrote: > What are your thoughts on what the definition of Broadband should be > going > forward? I would assume this will be the standard definition for a > number of > years to come. Historically, narrowband was circuit switched (ISDN etc) and broadband was packet switched. Narrowband was therefore tied to the digital signaling hierarchy and was in some way a multiple of 64 KBPS. As the term was used then, broadband delivery options of course included virtual circuits bearing packets, like Frame Relay and ATM. The new services I am hearing about include streamed video to multiple HD TVs in the home. I think I would encourage the FCC to discuss "broadband" to step away from the technology and look at the bandwidth usably delivered (as in "I don't care what the bit rate of the connection at the curb is if the back end is clogged; how much can a commodity TCP session move through the network"). http://tinyurl.com/pgxqzb suggests that the average broadband service worldwide delivers a download rate of 1.5 MBPS; having the FCC assert that the new definition of broadband is that it delivers a usable data rate in excess of 1 MBPS while narrowband delivers less seems reasonable. That said, the US is ~15th worldwide in broadband speed; Belgium, Ireland, South Korea, Taiwan, and the UK seem to think that FTTH that can serve multiple HDTVs simultaneously is normal. From frnkblk at iname.com Tue Aug 25 22:45:07 2009 From: frnkblk at iname.com (Frank Bulk - iName.com) Date: Tue, 25 Aug 2009 22:45:07 -0500 Subject: Data Center testing In-Reply-To: <20090825125310.GA67051@eagle.aitken.com> References: <1c2d53bb0908240600u1d9bbd48t38023b9900fc4f43@mail.gmail.com> <5b6f80200908240631q7f711db5m26a4f195c647aaeb@mail.gmail.com> <1c2d53bb0908240638t446b0d18tfc711960b84350fc@mail.gmail.com> <20090825125310.GA67051@eagle.aitken.com> Message-ID: There's more to data integrity in a data center (well, anything powered, that is) than network configurations. There's the loading of individual power outlets, UPS loading, UPS battery replacement cycles, loading of circuits, backup lighting, etc. And the only way to know if something is really working like it's designed is to test it. That's why we have financial auditors, military exercises, fire drills, etc. So while your analogy emphasizes the importance of having good processes in place to catch the problems up front, it doesn't eliminate throwing the switch. Frank -----Original Message----- From: Jeff Aitken [mailto:jaitken at aitken.com] Sent: Tuesday, August 25, 2009 7:53 AM To: Dan Snyder Cc: NANOG list Subject: Re: Data Center testing On Mon, Aug 24, 2009 at 09:38:38AM -0400, Dan Snyder wrote: > We have done power tests before and had no problem. I guess I am looking > for someone who does testing of the network equipment outside of just power > tests. We had an outage due to a configuration mistake that became apparent > when a switch failed. It didn't cause a problem however when we did a power > test for the whole data center. Dan, With all due respect, if there are config changes being made to your devices that aren't authorized or in accordance with your standards (you *do* have config standards, right?) then you don't have a testing problem, you have a data integrity problem. Periodically inducing failures to catch them is sorta like using your smoke detector as an oven timer. There are several tools that can help in this area; a good free one is rancid [1], which logs in to your routers and collects copies of configs and other info, all of which gets stored in a central repository. By default, you will be notified via email of any changes. An even better approach than scanning the hourly config diff emails is to develop scripts that compare the *actual* state of the network with the *desired* state and alert you if the two are not in sync. Obviously this is more work because you have to have some way of describing the desired state of the network in machine-parsable format, but the benefit is that you know in pseudo-realtime when something is wrong, as opposed to finding out the next time a device fails. Rancid diffs + tacacs logs will tell you who made the changes, and with that info you can get at the root of the problem. Having said that, every planned maintenance activity is an opportunity to run through at least some failure cases. If one of your providers is going to take down a longhaul circuit, you can observe how traffic re-routes and verify that your metrics and/or TE are doing what you expect. Any time you need to load new code on a device you can test that things fail over appropriately. Of course, you have to willing to just shut the device down without draining it first, but that's between you and your customers. Link and/or device failures will generate routing events that could be used to test convergence times across your network, etc. The key is to be prepared. The more instrumentation you have in place prior to the test, the better you will be able to analyze the impact of the failure. An experienced operator can often tell right away when looking at a bunch of MRTG graphs that "something doesn't look right", but that doesn't tell you *what* is wrong. There are tools (free and commercial) that can help here, too. Have a central syslog server and some kind of log reduction tool in place. Have beacons/probes deployed, in both the control and data planes. If you want to record, analyze, and even replay routing system events, you might want to take a look at the Route Explorer product from Packet Design [2]. You said "switch failure" above, so I'm guessing that this doesn't apply to you, but there are also good network simulation packages out there. Cariden [3] and WANDL [4] can build models of your network based on actual router configs and let you simulate the impact of various scenarios, including device/link failures. However, these tools are more appropriate for design and planning than for catching configuration mistakes, so they may not be what you're looking for in this case. --Jeff [1] http://www.shrubbery.net/rancid/ [2] http://www.packetdesign.com/products/rex.htm [3] http://www.cariden.com/ [4] http://www.wandl.com/html/index.php From mysidia at gmail.com Tue Aug 25 23:46:42 2009 From: mysidia at gmail.com (James Hess) Date: Tue, 25 Aug 2009 23:46:42 -0500 Subject: Data Center testing In-Reply-To: <20090825125310.GA67051@eagle.aitken.com> References: <1c2d53bb0908240600u1d9bbd48t38023b9900fc4f43@mail.gmail.com> <5b6f80200908240631q7f711db5m26a4f195c647aaeb@mail.gmail.com> <1c2d53bb0908240638t446b0d18tfc711960b84350fc@mail.gmail.com> <20090825125310.GA67051@eagle.aitken.com> Message-ID: <6eb799ab0908252146i273449c9o2850740456b2b63e@mail.gmail.com> On Tue, Aug 25, 2009 at 7:53 AM, Jeff Aitken wrote: >[..] Periodically inducing failures to catch [...] them is sorta like using your smoke detector as an oven timer. >[..] > machine-parsable format, but the benefit is that you know in pseudo-realtime > when something is wrong, as opposed to finding out the next time a device > fails. Config checking can't say much about silent hardware failures. Unanticipated problems are likely to arise in failover systems, especially complicated ones. A failover system that has not been periodically verified may not work as designed. Simulations, config review, and change controls are not substitutes for testing, they address overlapping but different problems. Testing detects unanticipated error; config review is a preventive measure that helps avoid and correct apparent configuration issues. Config checking (both software and hardware choices) also help to keep out unnecessary complexity. A human still has to write the script and review its output -- an operator error would eventually occur that is an accidental omission from both the current state and from the "desired" state; there is a chance that an erroneous entry escapes detection. There can be other types of errors: Possibly there is a damaged patch cable, dying port, failing power supply, or other hardware on the warm spare that has silently degraded and its poor condition won't be detected (until it actually tries to take a heavy workload, blows a fuse, eats a transceiver, and everything just falls apart). Perhaps you upgraded a hardware module or software image X months ago, to fix bug Y on the secondary unit, and the upgrade caused completely unanticipated side effect Z. Config checking can't say much about silent hardware problems. -- -Mysid From cabenth at gmail.com Wed Aug 26 01:09:48 2009 From: cabenth at gmail.com (eric clark) Date: Tue, 25 Aug 2009 23:09:48 -0700 Subject: Data Center testing In-Reply-To: <4A92D1C5.6030802@brightok.net> References: <1c2d53bb0908240600u1d9bbd48t38023b9900fc4f43@mail.gmail.com> <5b6f80200908240631q7f711db5m26a4f195c647aaeb@mail.gmail.com> <1c2d53bb0908240638t446b0d18tfc711960b84350fc@mail.gmail.com> <4A92D1C5.6030802@brightok.net> Message-ID: <5b602b520908252309h303a9b49pe18de4a338122f05@mail.gmail.com> Most Provider type datacenters I've worked with get a lot of flak from customers when they announce they're doing network failover testing, because there's always going to be a certain amount of chance (at least) of disruption. Its the exception to find a provider that does it I think (or maybe just one that admits it when they're doing it). Power tests are a different thing. As for testing your own equipment, there are a couple ways to do that, regular failover tests (quarterly, or more likely at 6 month intervals), and/or routing traffic so that you have some of your traffic on all paths (ie internal traffic on one path, external traffic on another). The latter doesn't necessarily tell you that your failover will work perfectly, only that all your gear in the 2nd path is functioning. I prefer doing both. When doing the failover tests, no matter how good your setup is, there's always a chance for taking a hit, so I always do this kind of work during a maintenance window, not too close to quarter end, etc. If you have your equipment set up correctly of course, it goes like butter and is a total non-event. For test procedure, I usually pull cables. I'll go all the way to line cards or power cables if I really want to test, though that can be hard on equipment. E On Mon, Aug 24, 2009 at 10:45 AM, Jack Bates wrote: > Dan Snyder wrote: > >> We have done power tests before and had no problem. I guess I am looking >> for someone who does testing of the network equipment outside of just >> power >> tests. We had an outage due to a configuration mistake that became >> apparent >> when a switch failed. It didn't cause a problem however when we did a >> power >> test for the whole data center. >> >> > The plus side of failure testing is that it can be controlled. The downside > to failure testing is that you can induce a failure. Maintenance windows are > cool, but some people really dislike failures of any type which limits how > often you can test. I personally try for once a year. However, a lot can go > wrong in a year. > > Jack > > From rsk at gsp.org Wed Aug 26 05:16:04 2009 From: rsk at gsp.org (Rich Kulawiec) Date: Wed, 26 Aug 2009 06:16:04 -0400 Subject: SORBS? In-Reply-To: References: Message-ID: <20090826101603.GA29938@gsp.org> On Tue, Aug 25, 2009 at 09:40:53AM -0400, trainier at kalsec.com wrote: > I need a SORBS maintainer to contact me. This should be redirected to the spam-l (preferable) or mailop (possibly) mailing list, where your chances of paging someone working in the DNSBL/RHSBL community are much better. ---Rsk From sharef.mustafa at paltel.net Wed Aug 26 08:50:51 2009 From: sharef.mustafa at paltel.net (Sharef Mustafa) Date: Wed, 26 Aug 2009 16:50:51 +0300 Subject: MTAs used Message-ID: Hi, Can anyone please point me to a list of the most used MTAs (mail servers) and their market share? BR From setient at gmail.com Wed Aug 26 09:10:25 2009 From: setient at gmail.com (Ronald Cotoni) Date: Wed, 26 Aug 2009 09:10:25 -0500 Subject: MTAs used In-Reply-To: References: Message-ID: <2f1d68350908260710o4140360ar21cbf86ac97dfce2@mail.gmail.com> http://www.google.com/search?q=list+of+the+most+used+MTAs&ie=utf-8&oe=utf-8&aq=t&rls=com.frontmotion:en-US:unofficial&client=firefox-aand http://www.google.com/search?q=MTA+market+share&ie=utf-8&oe=utf-8&aq=t&rls=com.frontmotion:en-US:unofficial&client=firefox-a On Wed, Aug 26, 2009 at 8:50 AM, Sharef Mustafa wrote: > Hi, > > > > Can anyone please point me to a list of the most used MTAs (mail > servers) and their market share? > > > > BR > > From allan at allan.org Wed Aug 26 09:17:44 2009 From: allan at allan.org (Allan Liska) Date: Wed, 26 Aug 2009 10:17:44 -0400 Subject: MTAs used In-Reply-To: <2f1d68350908260710o4140360ar21cbf86ac97dfce2@mail.gmail.com> References: <2f1d68350908260710o4140360ar21cbf86ac97dfce2@mail.gmail.com> Message-ID: <915e5e940908260717i36b4733m338a15368c6e1070@mail.gmail.com> According to the Google, the most used MTA is Ez-Pass :) allan On Wed, Aug 26, 2009 at 10:10 AM, Ronald Cotoni wrote: > > http://www.google.com/search?q=list+of+the+most+used+MTAs&ie=utf-8&oe=utf-8&aq=t&rls=com.frontmotion:en-US:unofficial&client=firefox-aand > > http://www.google.com/search?q=MTA+market+share&ie=utf-8&oe=utf-8&aq=t&rls=com.frontmotion:en-US:unofficial&client=firefox-a > > On Wed, Aug 26, 2009 at 8:50 AM, Sharef Mustafa > wrote: > > > Hi, > > > > > > > > Can anyone please point me to a list of the most used MTAs (mail > > servers) and their market share? > > > > > > > > BR > > > > > From jbates at brightok.net Wed Aug 26 09:22:12 2009 From: jbates at brightok.net (Jack Bates) Date: Wed, 26 Aug 2009 09:22:12 -0500 Subject: Data Center testing In-Reply-To: <6eb799ab0908252146i273449c9o2850740456b2b63e@mail.gmail.com> References: <1c2d53bb0908240600u1d9bbd48t38023b9900fc4f43@mail.gmail.com> <5b6f80200908240631q7f711db5m26a4f195c647aaeb@mail.gmail.com> <1c2d53bb0908240638t446b0d18tfc711960b84350fc@mail.gmail.com> <20090825125310.GA67051@eagle.aitken.com> <6eb799ab0908252146i273449c9o2850740456b2b63e@mail.gmail.com> Message-ID: <4A954514.3050603@brightok.net> James Hess wrote: > Config checking can't say much about silent hardware failures. > Unanticipated problems are likely to arise in failover systems, > especially complicated ones. A failover system that has not been > periodically verified may not work as designed. > I've seen 3-4 failover failures in the last year alone on the sonet transport gear. In almost each case, the backup cards were dead when the primary either died or induced errors causing telco to switch to the backup card. I have no doubts that they haven't been testing. While it didn't effect most of my network, I have a few customers that aren't multihomed, and it wiped them out in the middle of the day up to 3 hours. > There can be other types of errors: > Possibly there is a damaged patch cable, dying port, failing power > supply, or other hardware on the warm spare that has silently degraded > and its poor condition won't be detected (until it actually tries > to take a heavy workload, blows a fuse, eats a transceiver, and > everything just falls apart). > Lots of weird things to test for. I remember once rebooting a c5500 that had been cruising along for 3 years and the bootup diag detected 1/2 a linecard as bad, which had been running decently up until the reload. Over the years, I think I've seen or detected everything you mentioned either during routine testing or in production "oh crap" events. Jack From paul at telcodata.us Wed Aug 26 09:54:25 2009 From: paul at telcodata.us (Paul Timmins) Date: Wed, 26 Aug 2009 10:54:25 -0400 Subject: FCCs RFC for the Definition of Broadband In-Reply-To: <41A99CED-7857-4E24-B536-31493DE2EB99@cisco.com> References: <4a9edb810908240917r15739868i93ae029165962e9c@mail.gmail.com> <41A99CED-7857-4E24-B536-31493DE2EB99@cisco.com> Message-ID: <4A954CA1.6010402@telcodata.us> Fred Baker wrote: > > On Aug 24, 2009, at 9:17 AM, Luke Marrott wrote: > >> What are your thoughts on what the definition of Broadband should be >> going >> forward? I would assume this will be the standard definition for a >> number of >> years to come. > > > Historically, narrowband was circuit switched (ISDN etc) and broadband > was packet switched. Narrowband was therefore tied to the digital > signaling hierarchy and was in some way a multiple of 64 KBPS. As the > term was used then, broadband delivery options of course included > virtual circuits bearing packets, like Frame Relay and ATM. of or relating to or being a communications network in which the bandwidth can be divided and shared by multiple simultaneous signals (as for voice or data or video) That's my humble opinion. Let them use a new term, like "High Speed Internet". From dylan.ebner at crlmed.com Wed Aug 26 10:32:42 2009 From: dylan.ebner at crlmed.com (Dylan Ebner) Date: Wed, 26 Aug 2009 15:32:42 +0000 Subject: Data Center testing In-Reply-To: <1c2d53bb0908240638t446b0d18tfc711960b84350fc@mail.gmail.com> References: <1c2d53bb0908240600u1d9bbd48t38023b9900fc4f43@mail.gmail.com> <5b6f80200908240631q7f711db5m26a4f195c647aaeb@mail.gmail.com> <1c2d53bb0908240638t446b0d18tfc711960b84350fc@mail.gmail.com> Message-ID: <017265BF3B9640499754DD48777C3D206612CC1D7E@MBX9.EXCHPROD.USA.NET> I would hope that the data center engineers built and ran suite of tests to find failure points before the network infrastructure was put into production. That said, changes are made constantly to the infrastructure and it can become very difficult very quickly to know if the failovers are still going to work. This is one place where the power and network in a datacenter divulge. The power systems may take on additional load over the course of the life of the facility, but the transfer switches and generators do not get many changes made to them. Also, network infrastructure tests are not going to be zero impact if there is a config problem. Generator tests are much easier. You can start up the generator and do a load test. You can also load test the UPS systems as well. Then you can initiate your failover. Network tests are not going to be zero impact even if there isn't a problem. Let's say you wanted to power fail a edge router participating in BGP, it can take 30 seconds for that routers route to get withdrawn from the BGP tables of the world. The other problem is network failures always seem to come from "unexpected" issues. I always love it when I get an outage report from my ISP's or datacenter and they say an "unexpected issue" or "unforseen issue" caused the problem. Dylan -----Original Message----- From: Dan Snyder [mailto:sliplever at gmail.com] Sent: Monday, August 24, 2009 8:39 AM To: Ken Gilmour Cc: NANOG list Subject: Re: Data Center testing We have done power tests before and had no problem. I guess I am looking for someone who does testing of the network equipment outside of just power tests. We had an outage due to a configuration mistake that became apparent when a switch failed. It didn't cause a problem however when we did a power test for the whole data center. -Dan On Mon, Aug 24, 2009 at 9:31 AM, Ken Gilmour wrote: > I know Peer1 in vancouver reguarly send out notifications of > "non-impacting" generator load testing, like monthly. Also InterXion > in Dublin, Ireland have occasionally sent me notification that there > was a power outage of less than a minute however their backup > successfully took the load. > > I only remember one complete outage in Peer1 a few years ago... Never > seen any outage in InterXion Dublin. > > Also I don't ever remember any power failure at AiNet (Deepak will > probably elaborate) > > 2009/8/24 Dan Snyder : > > Does any one know of any data centers that do failure testing of > > their networking equipment regularly? I mean to verify that > > everything fails over properly after changes have been made over > > time. Is there any best practice guides for doing this? > > > > Thanks, > > Dan > > > From ted at fred.net Wed Aug 26 10:50:03 2009 From: ted at fred.net (Ted Fischer) Date: Wed, 26 Aug 2009 11:50:03 -0400 Subject: FCCs RFC for the Definition of Broadband In-Reply-To: <4A954CA1.6010402@telcodata.us> References: <4a9edb810908240917r15739868i93ae029165962e9c@mail.gmail.com> <41A99CED-7857-4E24-B536-31493DE2EB99@cisco.com> <4A954CA1.6010402@telcodata.us> Message-ID: <4A9559AB.7020508@fred.net> Paul Timmins wrote: > Fred Baker wrote: >> >> On Aug 24, 2009, at 9:17 AM, Luke Marrott wrote: >> >>> What are your thoughts on what the definition of Broadband should be >>> going >>> forward? I would assume this will be the standard definition for a >>> number of >>> years to come. >> >> >> Historically, narrowband was circuit switched (ISDN etc) and broadband >> was packet switched. Narrowband was therefore tied to the digital >> signaling hierarchy and was in some way a multiple of 64 KBPS. As the >> term was used then, broadband delivery options of course included >> virtual circuits bearing packets, like Frame Relay and ATM. > of or relating to or being a communications network in which the > bandwidth can be divided and shared by multiple simultaneous signals (as > for voice or data or video) > > That's my humble opinion. Let them use a new term, like "High Speed > Internet". > > Seconded From carlos at race.com Wed Aug 26 11:44:54 2009 From: carlos at race.com (Carlos Alcantar) Date: Wed, 26 Aug 2009 09:44:54 -0700 Subject: FCCs RFC for the Definition of Broadband Message-ID: <859604546CD1FF488BDB6EA94C896AFB8ABE40@racexchange.race.local> I think the big push to get the fcc to define broadband is highly based on the rus/ntia setting definitions of what broadband is. If any anyone has been fallowing the rus/ntia they are the one handing out all the stimulus infrastructure grant loan money. So there are a lot of political reasons to make the definition of broadband a bit slower than one would think. I guess it doesn't hurt that the larger lec's with the older infrastructure are shelling out the money to lobby to make sure the definition stays as low as can be. They don't want to see the gov funding there competition. Just my 2 cents. -carlos -----Original Message----- From: Ted Fischer [mailto:ted at fred.net] Sent: Wednesday, August 26, 2009 8:50 AM To: nanog at nanog.org Subject: Re: FCCs RFC for the Definition of Broadband Paul Timmins wrote: > Fred Baker wrote: >> >> On Aug 24, 2009, at 9:17 AM, Luke Marrott wrote: >> >>> What are your thoughts on what the definition of Broadband should be >>> going >>> forward? I would assume this will be the standard definition for a >>> number of >>> years to come. >> >> >> Historically, narrowband was circuit switched (ISDN etc) and broadband >> was packet switched. Narrowband was therefore tied to the digital >> signaling hierarchy and was in some way a multiple of 64 KBPS. As the >> term was used then, broadband delivery options of course included >> virtual circuits bearing packets, like Frame Relay and ATM. > of or relating to or being a communications network in which the > bandwidth can be divided and shared by multiple simultaneous signals (as > for voice or data or video) > > That's my humble opinion. Let them use a new term, like "High Speed > Internet". > > Seconded From brunner at nic-naa.net Wed Aug 26 11:57:46 2009 From: brunner at nic-naa.net (Eric Brunner-Williams) Date: Wed, 26 Aug 2009 12:57:46 -0400 Subject: FCCs RFC for the Definition of Broadband In-Reply-To: <4a9edb810908240917r15739868i93ae029165962e9c@mail.gmail.com> References: <4a9edb810908240917r15739868i93ae029165962e9c@mail.gmail.com> Message-ID: <4A95698A.7000600@nic-naa.net> In the applications I wrote earlier this month for BIP (Rural Utilities Services, USDA) and BTOP (NTIA, non-rural) infrastructure, for Maine's 2nd, I was keenly aware that broadband hasn't taken off as a pervasive, if not universal service in rural areas of the US. I don't think the speed metric is the metric that will make non-adoption in sparce clustered demographics distinguishable from adoption in denser demographics. I suspect that issues like symmetry of state signaling, latency, jitter, ... metrics that resemble what I looked for from MPI runs when benchmarking parallel systems, will characterize applications that may be distinguishable from the adoption, market penetration, renewal criteria from the applications that for reasons I can only conjecture, the standard "triple play" killer apps, which simply aren't driving broadband (whatever that is) adoption in rural areas. And no, I don't know what those better-than-triple-play-killer-apps-in-suburbia are. Eric Luke Marrott wrote: > I read an article on DSL Reports the other day ( > http://www.dslreports.com/shownews/FCC-Please-Define-Broadband-104056), in > which the FCC has a document requesting feedback on the definition of > Broadband. > > What are your thoughts on what the definition of Broadband should be going > forward? I would assume this will be the standard definition for a number of > years to come. > > Thanks. > > From brunner at nic-naa.net Wed Aug 26 11:59:43 2009 From: brunner at nic-naa.net (Eric Brunner-Williams) Date: Wed, 26 Aug 2009 12:59:43 -0400 Subject: FCCs RFC for the Definition of Broadband In-Reply-To: <4a9edb810908240917r15739868i93ae029165962e9c@mail.gmail.com> References: <4a9edb810908240917r15739868i93ae029165962e9c@mail.gmail.com> Message-ID: <4A9569FF.5000601@nic-naa.net> In the applications I wrote earlier this month for BIP (Rural Utilities Services, USDA) and BTOP (NTIA, non-rural) infrastructure, for Maine's 2nd, I was keenly aware that broadband hasn't taken off as a pervasive, if not universal service in rural areas of the US. I don't think the speed metric is the metric that will make non-adoption in sparce clustered demographics distinguishable from adoption in denser demographics. I suspect that issues like symmetry of state signaling, latency, jitter, ... metrics that resemble what I looked for from MPI runs when benchmarking parallel systems, will characterize applications that may be distinguishable from the adoption, market penetration, renewal criteria from the applications that for reasons I can only conjecture, the standard "triple play" killer apps, which simply aren't driving broadband (whatever that is) adoption in rural areas. And no, I don't know what those better-than-triple-play-killer-apps-in-suburbia are. My meta-point is that I suspect there are two "broadbands", one where triple-play sells recurring subscriber drops, and one where it doesn't, and for the later a better definition would be more useful than a definition that reads (in fine print) "not available here". Eric Luke Marrott wrote: > I read an article on DSL Reports the other day ( > http://www.dslreports.com/shownews/FCC-Please-Define-Broadband-104056), in > which the FCC has a document requesting feedback on the definition of > Broadband. > > What are your thoughts on what the definition of Broadband should be going > forward? I would assume this will be the standard definition for a number of > years to come. > > Thanks. > > From richard at bennett.com Wed Aug 26 12:25:31 2009 From: richard at bennett.com (Richard Bennett) Date: Wed, 26 Aug 2009 10:25:31 -0700 Subject: FCCs RFC for the Definition of Broadband In-Reply-To: <4A9569FF.5000601@nic-naa.net> References: <4a9edb810908240917r15739868i93ae029165962e9c@mail.gmail.com> <4A9569FF.5000601@nic-naa.net> Message-ID: The trouble with broadband in rural America is the twisted pair loop lengths that average around 20,000 feet. To use VDSL, the loop length needs to down around 3000, so they're stuck with ADSL unless the ILEC wants to install a lot of repeaters. And VDSL is the enabler of triple play over twisted pair. And apparently a number of rural cablecos, who have a suitable copper co-ax plant, haven't seen fit to offer what they call "data service." It's ironic, since cable TV was actually invented to help the rural user. Apparently the purpose of the definition is to ensure that the subsidies don't do down the rathole of supporting easy upgrades, but as others have mentioned, one definition for "broadband" isn't very useful unless it's something like "10 times faster than what I had yesterday." I like to say first gen broadband is 10 times faster than a modem or 500 Kb/s; second gen is 5 Mb/s, and third is 50 or faster. Richard Bennett -----Original Message----- From: Eric Brunner-Williams [mailto:brunner at nic-naa.net] Sent: Wednesday, August 26, 2009 10:00 AM To: Luke Marrott Cc: nanog at nanog.org Subject: Re: FCCs RFC for the Definition of Broadband In the applications I wrote earlier this month for BIP (Rural Utilities Services, USDA) and BTOP (NTIA, non-rural) infrastructure, for Maine's 2nd, I was keenly aware that broadband hasn't taken off as a pervasive, if not universal service in rural areas of the US. I don't think the speed metric is the metric that will make non-adoption in sparce clustered demographics distinguishable from adoption in denser demographics. I suspect that issues like symmetry of state signaling, latency, jitter, ... metrics that resemble what I looked for from MPI runs when benchmarking parallel systems, will characterize applications that may be distinguishable from the adoption, market penetration, renewal criteria from the applications that for reasons I can only conjecture, the standard "triple play" killer apps, which simply aren't driving broadband (whatever that is) adoption in rural areas. And no, I don't know what those better-than-triple-play-killer-apps-in-suburbia are. My meta-point is that I suspect there are two "broadbands", one where triple-play sells recurring subscriber drops, and one where it doesn't, and for the later a better definition would be more useful than a definition that reads (in fine print) "not available here". Eric Luke Marrott wrote: > I read an article on DSL Reports the other day ( > http://www.dslreports.com/shownews/FCC-Please-Define-Broadband-104056) > , in which the FCC has a document requesting feedback on the > definition of Broadband. > > What are your thoughts on what the definition of Broadband should be > going forward? I would assume this will be the standard definition for > a number of years to come. > > Thanks. > > From fred at cisco.com Wed Aug 26 12:38:38 2009 From: fred at cisco.com (Fred Baker) Date: Wed, 26 Aug 2009 10:38:38 -0700 Subject: FCCs RFC for the Definition of Broadband In-Reply-To: <859604546CD1FF488BDB6EA94C896AFB8ABE40@racexchange.race.local> References: <859604546CD1FF488BDB6EA94C896AFB8ABE40@racexchange.race.local> Message-ID: <3A89064E-4F43-4FFC-B535-B4D971CFDEF0@cisco.com> If it's about stimulus money, I'm in favor of saying that broadband implies fiber to the home. That would provide all sorts of stimuli to the economy - infrastructure, equipment sales, jobs digging ditches, and so on. I could pretty quickly argue myself into suggesting special favors for deployment of DNSSEC, multicast, and IPv6. As in, use the stimulus money to propel a leap forward, not just waste it. On Aug 26, 2009, at 9:44 AM, Carlos Alcantar wrote: > I think the big push to get the fcc to define broadband is highly > based > on the rus/ntia setting definitions of what broadband is. If any > anyone > has been fallowing the rus/ntia they are the one handing out all the > stimulus infrastructure grant loan money. So there are a lot of > political reasons to make the definition of broadband a bit slower > than > one would think. I guess it doesn't hurt that the larger lec's with > the > older infrastructure are shelling out the money to lobby to make sure > the definition stays as low as can be. They don't want to see the gov > funding there competition. Just my 2 cents. > > -carlos > > -----Original Message----- > From: Ted Fischer [mailto:ted at fred.net] > Sent: Wednesday, August 26, 2009 8:50 AM > To: nanog at nanog.org > Subject: Re: FCCs RFC for the Definition of Broadband > > > > Paul Timmins wrote: >> Fred Baker wrote: >>> >>> On Aug 24, 2009, at 9:17 AM, Luke Marrott wrote: >>> >>>> What are your thoughts on what the definition of Broadband should >>>> be > >>>> going >>>> forward? I would assume this will be the standard definition for a >>>> number of >>>> years to come. >>> >>> >>> Historically, narrowband was circuit switched (ISDN etc) and > broadband >>> was packet switched. Narrowband was therefore tied to the digital >>> signaling hierarchy and was in some way a multiple of 64 KBPS. As >>> the > >>> term was used then, broadband delivery options of course included >>> virtual circuits bearing packets, like Frame Relay and ATM. >> of or relating to or being a communications network in which the >> bandwidth can be divided and shared by multiple simultaneous signals > (as >> for voice or data or video) >> >> That's my humble opinion. Let them use a new term, like "High Speed >> Internet". >> >> > Seconded > > > From deleskie at gmail.com Wed Aug 26 12:57:10 2009 From: deleskie at gmail.com (jim deleskie) Date: Wed, 26 Aug 2009 13:57:10 -0400 Subject: FCCs RFC for the Definition of Broadband In-Reply-To: <3A89064E-4F43-4FFC-B535-B4D971CFDEF0@cisco.com> References: <859604546CD1FF488BDB6EA94C896AFB8ABE40@racexchange.race.local> <3A89064E-4F43-4FFC-B535-B4D971CFDEF0@cisco.com> Message-ID: I agree we should all be telling the FCC that broadband is fiber to the home. If we spend all kinds of $$ to build a 1.5M/s connection to homes, it's outdated before we even finish. On Wed, Aug 26, 2009 at 1:38 PM, Fred Baker wrote: > If it's about stimulus money, I'm in favor of saying that broadband implies > fiber to the home. That would provide all sorts of stimuli to the economy - > infrastructure, equipment sales, jobs digging ditches, and so on. I could > pretty quickly argue myself into suggesting special favors for deployment of > DNSSEC, multicast, and IPv6. As in, use the stimulus money to propel a leap > forward, not just waste it. > > On Aug 26, 2009, at 9:44 AM, Carlos Alcantar wrote: > >> I think the big push to get the fcc to define broadband is highly based >> on the rus/ntia setting definitions of what broadband is. ?If any anyone >> has been fallowing the rus/ntia they are the one handing out all the >> stimulus infrastructure grant loan money. ?So there are a lot of >> political reasons to make the definition of broadband a bit slower than >> one would think. ?I guess it doesn't hurt that the larger lec's with the >> older infrastructure are shelling out the money to lobby to make sure >> the definition stays as low as can be. ?They don't want to see the gov >> funding there competition. ?Just my 2 cents. >> >> -carlos >> >> -----Original Message----- >> From: Ted Fischer [mailto:ted at fred.net] >> Sent: Wednesday, August 26, 2009 8:50 AM >> To: nanog at nanog.org >> Subject: Re: FCCs RFC for the Definition of Broadband >> >> >> >> Paul Timmins wrote: >>> >>> Fred Baker wrote: >>>> >>>> On Aug 24, 2009, at 9:17 AM, Luke Marrott wrote: >>>> >>>>> What are your thoughts on what the definition of Broadband should be >> >>>>> going >>>>> forward? I would assume this will be the standard definition for a >>>>> number of >>>>> years to come. >>>> >>>> >>>> Historically, narrowband was circuit switched (ISDN etc) and >> >> broadband >>>> >>>> was packet switched. Narrowband was therefore tied to the digital >>>> signaling hierarchy and was in some way a multiple of 64 KBPS. As the >> >>>> term was used then, broadband delivery options of course included >>>> virtual circuits bearing packets, like Frame Relay and ATM. >>> >>> of or relating to or being a communications network in which the >>> bandwidth can be divided and shared by multiple simultaneous signals >> >> (as >>> >>> for voice or data or video) >>> >>> That's my humble opinion. Let them use a new term, like "High Speed >>> Internet". >>> >>> >> Seconded >> >> >> > > > From deepak at ai.net Wed Aug 26 13:22:49 2009 From: deepak at ai.net (Deepak Jain) Date: Wed, 26 Aug 2009 14:22:49 -0400 Subject: Data Center testing In-Reply-To: <017265BF3B9640499754DD48777C3D206612CC1D7E@MBX9.EXCHPROD.USA.NET> References: <1c2d53bb0908240600u1d9bbd48t38023b9900fc4f43@mail.gmail.com> <5b6f80200908240631q7f711db5m26a4f195c647aaeb@mail.gmail.com> <1c2d53bb0908240638t446b0d18tfc711960b84350fc@mail.gmail.com> <017265BF3B9640499754DD48777C3D206612CC1D7E@MBX9.EXCHPROD.USA.NET> Message-ID: The idea of regular testing is to essentially detect failures on your time schedule rather than entropy's (or Murphy's). There can be flaws in your testing methodology too. This is why generic load bank tests and network load simulators rarely tell the whole story. Customers are rightfully unpleased with any testing that affects their normal peace-of-mind, and doubly so when it affects actual operational effectiveness. However, since no system can operate indefinitely without maintenance, failover and other items, the question of taking a window is not negotiable. The only thing that is negotiable (somewhat) is when, and only in one direction (ahead of the item failing on its own). So, taking this concept to networks. It's not negotiable whether a link or a device will fail, the question is only how long you are going to forward bits along the dead path before rerouting and how long that rerouting will take. SONET says about 50ms, standard BGP about 30-300seconds. BFD and other things may improve these dramatically in your setup. You build your network around your business case and vice versa. Clearly, most of the known universe has decided that BGP time is "good enough" for the Internet as a whole right now. Most are aware of the costs in terms of overall jitter, CPU and stability if we reduce those times too far. Its intellectually dishonest to talk about never losing a packet or never forwarding along a dead path for even a nanosecond when the state-of-the-art says something very different indeed. Deepak Jain AiNET > -----Original Message----- > From: Dylan Ebner [mailto:dylan.ebner at crlmed.com] > Sent: Wednesday, August 26, 2009 11:33 AM > To: Dan Snyder; Ken Gilmour > Cc: NANOG list > Subject: RE: Data Center testing > > I would hope that the data center engineers built and ran suite of > tests to find failure points before the network infrastructure was put > into production. That said, changes are made constantly to the > infrastructure and it can become very difficult very quickly to know if > the failovers are still going to work. This is one place where the > power and network in a datacenter divulge. The power systems may take > on additional load over the course of the life of the facility, but the > transfer switches and generators do not get many changes made to them. > Also, network infrastructure tests are not going to be zero impact if > there is a config problem. Generator tests are much easier. You can > start up the generator and do a load test. You can also load test the > UPS systems as well. Then you can initiate your failover. Network tests > are not going to be zero impact even if there isn't a problem. Let's > say you wanted to power fail a edge router participating in BGP, it can > take 30 seconds for that routers route to get withdrawn from the BGP > tables of the world. The other problem is network failures always seem > to come from "unexpected" issues. I always love it when I get an outage > report from my ISP's or datacenter and they say an "unexpected issue" > or "unforseen issue" caused the problem. > > > Dylan > -----Original Message----- > From: Dan Snyder [mailto:sliplever at gmail.com] > Sent: Monday, August 24, 2009 8:39 AM > To: Ken Gilmour > Cc: NANOG list > Subject: Re: Data Center testing > > We have done power tests before and had no problem. I guess I am > looking for someone who does testing of the network equipment outside > of just power tests. We had an outage due to a configuration mistake > that became apparent when a switch failed. It didn't cause a problem > however when we did a power test for the whole data center. > > -Dan > > > On Mon, Aug 24, 2009 at 9:31 AM, Ken Gilmour > wrote: > > > I know Peer1 in vancouver reguarly send out notifications of > > "non-impacting" generator load testing, like monthly. Also InterXion > > in Dublin, Ireland have occasionally sent me notification that there > > was a power outage of less than a minute however their backup > > successfully took the load. > > > > I only remember one complete outage in Peer1 a few years ago... Never > > seen any outage in InterXion Dublin. > > > > Also I don't ever remember any power failure at AiNet (Deepak will > > probably elaborate) > > > > 2009/8/24 Dan Snyder : > > > Does any one know of any data centers that do failure testing of > > > their networking equipment regularly? I mean to verify that > > > everything fails over properly after changes have been made over > > > time. Is there any best practice guides for doing this? > > > > > > Thanks, > > > Dan > > > > > > From carlos at race.com Wed Aug 26 13:38:16 2009 From: carlos at race.com (Carlos Alcantar) Date: Wed, 26 Aug 2009 11:38:16 -0700 Subject: FCCs RFC for the Definition of Broadband Message-ID: <859604546CD1FF488BDB6EA94C896AFB8ABE4E@racexchange.race.local> I believe a lot of people are thinking the same way that fiber to the home is broadband. Looking at some poll results from a calix webinar it looks like most people submitting for stimulus money are going down that path of fiber to the home as gpon and active Ethernet seem to be the front runners. If anyone cares to look at the poll http://www.calix.com/bbs/ bottom right. -carlos -----Original Message----- From: jim deleskie [mailto:deleskie at gmail.com] Sent: Wednesday, August 26, 2009 10:57 AM To: Fred Baker Cc: Carlos Alcantar; nanog at nanog.org Subject: Re: FCCs RFC for the Definition of Broadband I agree we should all be telling the FCC that broadband is fiber to the home. If we spend all kinds of $$ to build a 1.5M/s connection to homes, it's outdated before we even finish. On Wed, Aug 26, 2009 at 1:38 PM, Fred Baker wrote: > If it's about stimulus money, I'm in favor of saying that broadband implies > fiber to the home. That would provide all sorts of stimuli to the economy - > infrastructure, equipment sales, jobs digging ditches, and so on. I could > pretty quickly argue myself into suggesting special favors for deployment of > DNSSEC, multicast, and IPv6. As in, use the stimulus money to propel a leap > forward, not just waste it. > > On Aug 26, 2009, at 9:44 AM, Carlos Alcantar wrote: > >> I think the big push to get the fcc to define broadband is highly based >> on the rus/ntia setting definitions of what broadband is. ?If any anyone >> has been fallowing the rus/ntia they are the one handing out all the >> stimulus infrastructure grant loan money. ?So there are a lot of >> political reasons to make the definition of broadband a bit slower than >> one would think. ?I guess it doesn't hurt that the larger lec's with the >> older infrastructure are shelling out the money to lobby to make sure >> the definition stays as low as can be. ?They don't want to see the gov >> funding there competition. ?Just my 2 cents. >> >> -carlos >> >> -----Original Message----- >> From: Ted Fischer [mailto:ted at fred.net] >> Sent: Wednesday, August 26, 2009 8:50 AM >> To: nanog at nanog.org >> Subject: Re: FCCs RFC for the Definition of Broadband >> >> >> >> Paul Timmins wrote: >>> >>> Fred Baker wrote: >>>> >>>> On Aug 24, 2009, at 9:17 AM, Luke Marrott wrote: >>>> >>>>> What are your thoughts on what the definition of Broadband should be >> >>>>> going >>>>> forward? I would assume this will be the standard definition for a >>>>> number of >>>>> years to come. >>>> >>>> >>>> Historically, narrowband was circuit switched (ISDN etc) and >> >> broadband >>>> >>>> was packet switched. Narrowband was therefore tied to the digital >>>> signaling hierarchy and was in some way a multiple of 64 KBPS. As the >> >>>> term was used then, broadband delivery options of course included >>>> virtual circuits bearing packets, like Frame Relay and ATM. >>> >>> of or relating to or being a communications network in which the >>> bandwidth can be divided and shared by multiple simultaneous signals >> >> (as >>> >>> for voice or data or video) >>> >>> That's my humble opinion. Let them use a new term, like "High Speed >>> Internet". >>> >>> >> Seconded >> >> >> > > > From jbates at brightok.net Wed Aug 26 14:06:24 2009 From: jbates at brightok.net (Jack Bates) Date: Wed, 26 Aug 2009 14:06:24 -0500 Subject: FCCs RFC for the Definition of Broadband In-Reply-To: References: <859604546CD1FF488BDB6EA94C896AFB8ABE40@racexchange.race.local> <3A89064E-4F43-4FFC-B535-B4D971CFDEF0@cisco.com> Message-ID: <4A9587B0.4080306@brightok.net> jim deleskie wrote: > I agree we should all be telling the FCC that broadband is fiber to > the home. If we spend all kinds of $$ to build a 1.5M/s connection to > homes, it's outdated before we even finish. I disagree. I much prefer fiber to the curb with copper to the home. Of course, I haven't had a need for 100mb/s to the house which I can do on copper, much less need for gigabit. Pro's for copper from curb: 1) power over copper for POTS 2) Majority of cuts occur on customer drops and copper is more resilient to splicing by any monkey. Jack From jaitken at aitken.com Wed Aug 26 14:13:14 2009 From: jaitken at aitken.com (Jeff Aitken) Date: Wed, 26 Aug 2009 19:13:14 +0000 Subject: Data Center testing In-Reply-To: References: <1c2d53bb0908240600u1d9bbd48t38023b9900fc4f43@mail.gmail.com> <5b6f80200908240631q7f711db5m26a4f195c647aaeb@mail.gmail.com> <1c2d53bb0908240638t446b0d18tfc711960b84350fc@mail.gmail.com> <20090825125310.GA67051@eagle.aitken.com> Message-ID: <20090826191314.GA838@eagle.aitken.com> On Tue, Aug 25, 2009 at 10:45:07PM -0500, Frank Bulk - iName.com wrote: > There's more to data integrity in a data center (well, anything powered, > that is) than network configurations. Understood and agreed. My point was that induced failure testing isn't the right way to catch incorrect or unauthorized config changes, which is what I understood the original poster to have said was his problem. My apologies if I misunderstood what he was asking. > So while your analogy emphasizes the importance of having good processes in > place to catch the problems up front, it doesn't eliminate throwing the > switch. Yup, and it's precisely why I suggested using planned maintenance events as one way of doing at least limited failure testing. --Jeff From eslerj at gmail.com Wed Aug 26 14:14:03 2009 From: eslerj at gmail.com (Joel Esler) Date: Wed, 26 Aug 2009 15:14:03 -0400 Subject: FCCs RFC for the Definition of Broadband In-Reply-To: <4A9587B0.4080306@brightok.net> References: <859604546CD1FF488BDB6EA94C896AFB8ABE40@racexchange.race.local> <3A89064E-4F43-4FFC-B535-B4D971CFDEF0@cisco.com> <4A9587B0.4080306@brightok.net> Message-ID: <314cf0830908261214j9d8552bnc57dbad692750f81@mail.gmail.com> On Wed, Aug 26, 2009 at 3:06 PM, Jack Bates wrote: > jim deleskie wrote: >> >> I agree we should all be telling the FCC that broadband is fiber to >> the home. ?If we spend all kinds of $$ to build a 1.5M/s connection to >> homes, it's outdated before we even finish. > > I disagree. I much prefer fiber to the curb with copper to the home. Of > course, I haven't had a need for 100mb/s to the house which I can do on > copper, much less need for gigabit. > > Pro's for copper from curb: > > 1) power over copper for POTS > 2) Majority of cuts occur on customer drops and copper is more resilient to > splicing by any monkey. I have fiber to the home. I can't imagine going back to "cable modems" now. eww.. From jbates at brightok.net Wed Aug 26 14:23:40 2009 From: jbates at brightok.net (Jack Bates) Date: Wed, 26 Aug 2009 14:23:40 -0500 Subject: FCCs RFC for the Definition of Broadband In-Reply-To: <314cf0830908261214j9d8552bnc57dbad692750f81@mail.gmail.com> References: <859604546CD1FF488BDB6EA94C896AFB8ABE40@racexchange.race.local> <3A89064E-4F43-4FFC-B535-B4D971CFDEF0@cisco.com> <4A9587B0.4080306@brightok.net> <314cf0830908261214j9d8552bnc57dbad692750f81@mail.gmail.com> Message-ID: <4A958BBC.8000608@brightok.net> Joel Esler wrote: > > I have fiber to the home. I can't imagine going back to "cable > modems" now. eww.. I couldn't imagine leaving my VDSL2. I've seen broadband sent to the house via fiber, coax, and copper. I've seen them all done well, and I've seen them all done poorly. All are capable of hitting >50mb/s. I personally like copper for the splice and cost on drops as well as cost of NID/CPE. Coax has a lot of bandwidth, but requires you to get as close as you would with copper to do it right and has other issues. Fiber is the fastest and can run off fewer remote systems, but it has higher costs and maintenance issues. I would probably run fiber in a densely populated area. In rural America, I would stick with copper off 1.5 mile short loop remotes. A lot depends on what the bandwidth is for. Most of the telco's I work with rarely have a corporate customer paying for more than 10mb/s. Jack From r.engehausen at gmail.com Wed Aug 26 14:27:51 2009 From: r.engehausen at gmail.com (Roy) Date: Wed, 26 Aug 2009 12:27:51 -0700 Subject: FCCs RFC for the Definition of Broadband In-Reply-To: <314cf0830908261214j9d8552bnc57dbad692750f81@mail.gmail.com> References: <859604546CD1FF488BDB6EA94C896AFB8ABE40@racexchange.race.local> <3A89064E-4F43-4FFC-B535-B4D971CFDEF0@cisco.com> <4A9587B0.4080306@brightok.net> <314cf0830908261214j9d8552bnc57dbad692750f81@mail.gmail.com> Message-ID: <4A958CB7.1090300@gmail.com> Joel Esler wrote: > On Wed, Aug 26, 2009 at 3:06 PM, Jack Bates wrote: > >> jim deleskie wrote: >> >>> I agree we should all be telling the FCC that broadband is fiber to >>> the home. If we spend all kinds of $$ to build a 1.5M/s connection to >>> homes, it's outdated before we even finish. >>> >> I disagree. I much prefer fiber to the curb with copper to the home. Of >> course, I haven't had a need for 100mb/s to the house which I can do on >> copper, much less need for gigabit. >> >> Pro's for copper from curb: >> >> 1) power over copper for POTS >> 2) Majority of cuts occur on customer drops and copper is more resilient to >> splicing by any monkey. >> > > I have fiber to the home. I can't imagine going back to "cable > modems" now. eww.. > > The problem that the FCC faces is making a realistic definition that can apply to the whole US and not just cities. How does fiber (home or curb) figure in the rural sections of the country? From jbates at brightok.net Wed Aug 26 14:42:21 2009 From: jbates at brightok.net (Jack Bates) Date: Wed, 26 Aug 2009 14:42:21 -0500 Subject: FCCs RFC for the Definition of Broadband In-Reply-To: <4A958CB7.1090300@gmail.com> References: <859604546CD1FF488BDB6EA94C896AFB8ABE40@racexchange.race.local> <3A89064E-4F43-4FFC-B535-B4D971CFDEF0@cisco.com> <4A9587B0.4080306@brightok.net> <314cf0830908261214j9d8552bnc57dbad692750f81@mail.gmail.com> <4A958CB7.1090300@gmail.com> Message-ID: <4A95901D.6010402@brightok.net> Roy wrote: > The problem that the FCC faces is making a realistic definition that can > apply to the whole US and not just cities. How does fiber (home or > curb) figure in the rural sections of the country? It figures in nicely, thank you. Of course, our definition of curb might be 1.5 miles further than your definition. ;) 2 miles is the cutoff for > 10mb/s reliability, but to deal with future stuff, most of my telco customers have dropped it down to 1.5 miles. This also suited them for handling smaller remote systems with 48 ports and shifting from gr303 to SIP/MGCP, some with gr303 translators at the home office. Our highest supported circuits currently top at 100/50, but customers don't need them, and the telco's aren't pushing video down them. We honestly hope Internet video will continue to grow and we'll just shift into higher Internet bandwidth and stick with transport. We're good at transport. Jack From Valdis.Kletnieks at vt.edu Wed Aug 26 15:01:11 2009 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Wed, 26 Aug 2009 16:01:11 -0400 Subject: MTAs used In-Reply-To: Your message of "Wed, 26 Aug 2009 16:50:51 +0300." References: Message-ID: <14510.1251316871@turing-police.cc.vt.edu> On Wed, 26 Aug 2009 16:50:51 +0300, Sharef Mustafa said: > Can anyone please point me to a list of the most used MTAs (mail > servers) and their market share? Now, did you want that in terms of "number of copies installed" or "amount of mail handled"? There's probably zillions of little Fedora and Ubuntu boxes running whatever MTA came off the disk that are handling 1 or 2 pieces of mail a day, and then there's whatever backends are used by MSN/Hotmail, Yahoo, AOL, etc. "This MTA packed by weight, not by volume. Some settling of contents may have occurred during shipping and spamming." (Seriously - if 95% of the mail out there is spam, then the top 4-5 MTAs are probably the ratware that's sending out the spam. Something to consider...) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 226 bytes Desc: not available URL: From ross at kallisti.us Wed Aug 26 15:04:26 2009 From: ross at kallisti.us (Ross Vandegrift) Date: Wed, 26 Aug 2009 16:04:26 -0400 Subject: Data Center testing In-Reply-To: <20090825125310.GA67051@eagle.aitken.com> References: <1c2d53bb0908240600u1d9bbd48t38023b9900fc4f43@mail.gmail.com> <5b6f80200908240631q7f711db5m26a4f195c647aaeb@mail.gmail.com> <1c2d53bb0908240638t446b0d18tfc711960b84350fc@mail.gmail.com> <20090825125310.GA67051@eagle.aitken.com> Message-ID: <20090826200426.GD10372@kallisti.us> On Tue, Aug 25, 2009 at 12:53:10PM +0000, Jeff Aitken wrote: > you have to have some way of describing the desired state of the network in > machine-parsable format Any suggested tools for describing the desired state of the network? NDL, the only option I'm familiar with, is just a brute-force approach to describing routers in XML. This is hardly better than a router-config, and the visualizations break down on any graph with more than a few nodes or edges. I'd need thousands to describe customer routers. Or do we just give up on describing all of those customer-facing interfaces, and only manage descriptions for the service-provider part of the network? This seems to be what people actually do with network descriptions (oversimplify), and that doesn't seem like much of a description to me. Is there a practical middle-ground between dismissing a multitude of relevant customer configuration and the data overload created by merely replicating the entire network config in a new language? Ross -- Ross Vandegrift ross at kallisti.us "If the fight gets hot, the songs get hotter. If the going gets tough, the songs get tougher." --Woody Guthrie From deepak at ai.net Wed Aug 26 15:09:30 2009 From: deepak at ai.net (Deepak Jain) Date: Wed, 26 Aug 2009 16:09:30 -0400 Subject: MTAs used In-Reply-To: <14510.1251316871@turing-police.cc.vt.edu> References: <14510.1251316871@turing-police.cc.vt.edu> Message-ID: > Now, did you want that in terms of "number of copies installed" or > "amount of mail handled"? There's probably zillions of little Fedora > and > Ubuntu boxes running whatever MTA came off the disk that are handling 1 > or 2 pieces of mail a day, and then there's whatever backends are used > by MSN/Hotmail, Yahoo, AOL, etc. "This MTA packed by weight, not by > volume. > Some settling of contents may have occurred during shipping and > spamming." > > (Seriously - if 95% of the mail out there is spam, then the top 4-5 > MTAs are probably the ratware that's sending out the spam. Something > to consider...) In keeping with this concept, and turning it around. What MTA is exposed to the most spam? (1-x) That should tell you what MTA handles the most "good" mail by also being the destination for the most spam (good, live recipients). Or I could be missing something well known about mail flows. Deepak From dhetzel at gmail.com Wed Aug 26 15:16:05 2009 From: dhetzel at gmail.com (Dorn Hetzel) Date: Wed, 26 Aug 2009 16:16:05 -0400 Subject: FCCs RFC for the Definition of Broadband In-Reply-To: <7db2dcf90908261123o64c8be7qc7a50c4340036b19@mail.gmail.com> References: <859604546CD1FF488BDB6EA94C896AFB8ABE40@racexchange.race.local> <3A89064E-4F43-4FFC-B535-B4D971CFDEF0@cisco.com> <7db2dcf90908261123o64c8be7qc7a50c4340036b19@mail.gmail.com> Message-ID: <7db2dcf90908261316x1dc2edf2sbe2e51915b3e6d47@mail.gmail.com> not to mention all the lightning-blasted-routers that will be prevented by FTTH :) even with several layers of protection I still accumulate about one dead interface of some sort each year on my very rural T-1... On Wed, Aug 26, 2009 at 1:57 PM, jim deleskie wrote: > I agree we should all be telling the FCC that broadband is fiber to > the home. If we spend all kinds of $$ to build a 1.5M/s connection to > homes, it's outdated before we even finish. > > > > On Wed, Aug 26, 2009 at 1:38 PM, Fred Baker wrote: > > If it's about stimulus money, I'm in favor of saying that broadband > implies > > fiber to the home. That would provide all sorts of stimuli to the economy > - > > infrastructure, equipment sales, jobs digging ditches, and so on. I could > > pretty quickly argue myself into suggesting special favors for deployment > of > > DNSSEC, multicast, and IPv6. As in, use the stimulus money to propel a > leap > > forward, not just waste it. > > > > On Aug 26, 2009, at 9:44 AM, Carlos Alcantar wrote: > > > >> I think the big push to get the fcc to define broadband is highly based > >> on the rus/ntia setting definitions of what broadband is. If any anyone > >> has been fallowing the rus/ntia they are the one handing out all the > >> stimulus infrastructure grant loan money. So there are a lot of > >> political reasons to make the definition of broadband a bit slower than > >> one would think. I guess it doesn't hurt that the larger lec's with the > >> older infrastructure are shelling out the money to lobby to make sure > >> the definition stays as low as can be. They don't want to see the gov > >> funding there competition. Just my 2 cents. > >> > >> -carlos > >> > >> -----Original Message----- > >> From: Ted Fischer [mailto:ted at fred.net] > >> Sent: Wednesday, August 26, 2009 8:50 AM > >> To: nanog at nanog.org > >> Subject: Re: FCCs RFC for the Definition of Broadband > >> > >> > >> > >> Paul Timmins wrote: > >>> > >>> Fred Baker wrote: > >>>> > >>>> On Aug 24, 2009, at 9:17 AM, Luke Marrott wrote: > >>>> > >>>>> What are your thoughts on what the definition of Broadband should be > >> > >>>>> going > >>>>> forward? I would assume this will be the standard definition for a > >>>>> number of > >>>>> years to come. > >>>> > >>>> > >>>> Historically, narrowband was circuit switched (ISDN etc) and > >> > >> broadband > >>>> > >>>> was packet switched. Narrowband was therefore tied to the digital > >>>> signaling hierarchy and was in some way a multiple of 64 KBPS. As the > >> > >>>> term was used then, broadband delivery options of course included > >>>> virtual circuits bearing packets, like Frame Relay and ATM. > >>> > >>> of or relating to or being a communications network in which the > >>> bandwidth can be divided and shared by multiple simultaneous signals > >> > >> (as > >>> > >>> for voice or data or video) > >>> > >>> That's my humble opinion. Let them use a new term, like "High Speed > >>> Internet". > >>> > >>> > >> Seconded > >> > >> > >> > > > > > > > > From David_Hiers at adp.com Wed Aug 26 15:30:35 2009 From: David_Hiers at adp.com (Hiers, David) Date: Wed, 26 Aug 2009 15:30:35 -0500 Subject: FCCs RFC for the Definition of Broadband In-Reply-To: <7db2dcf90908261316x1dc2edf2sbe2e51915b3e6d47@mail.gmail.com> References: <859604546CD1FF488BDB6EA94C896AFB8ABE40@racexchange.race.local> <3A89064E-4F43-4FFC-B535-B4D971CFDEF0@cisco.com> <7db2dcf90908261123o64c8be7qc7a50c4340036b19@mail.gmail.com> <7db2dcf90908261316x1dc2edf2sbe2e51915b3e6d47@mail.gmail.com> Message-ID: <81CDFC77FB2DC54DB875D4F8FFC36CE00B7A45B7FE@DSMAIL2HE.ds.ad.adp.com> We're way past the time in which broadband meant more bits than baud, huh? Was it the other way around? I forget... :) Anyway: "Broadband" could be defined as a duplex channel that is some positive multiple of the BW needed to carry the lowest resolution, full-power, public broadcast TV channel currently permitted by FCC regulation. As technology and regulation changes, we'd always have a definition of "broadband" that is implementation independent, technology agnostic, and easy to grasp for most people. David Hiers CCIE (R/S, V), CISSP ADP Dealer Services 2525 SW 1st Ave. Suite 300W Portland, OR 97201 o: 503-205-4467 f: 503-402-3277 -----Original Message----- From: Dorn Hetzel [mailto:dhetzel at gmail.com] Sent: Wednesday, August 26, 2009 1:16 PM To: nanog at nanog.org Subject: FCCs RFC for the Definition of Broadband not to mention all the lightning-blasted-routers that will be prevented by FTTH :) even with several layers of protection I still accumulate about one dead interface of some sort each year on my very rural T-1... On Wed, Aug 26, 2009 at 1:57 PM, jim deleskie wrote: > I agree we should all be telling the FCC that broadband is fiber to > the home. If we spend all kinds of $$ to build a 1.5M/s connection to > homes, it's outdated before we even finish. > > > > On Wed, Aug 26, 2009 at 1:38 PM, Fred Baker wrote: > > If it's about stimulus money, I'm in favor of saying that broadband > implies > > fiber to the home. That would provide all sorts of stimuli to the economy > - > > infrastructure, equipment sales, jobs digging ditches, and so on. I could > > pretty quickly argue myself into suggesting special favors for deployment > of > > DNSSEC, multicast, and IPv6. As in, use the stimulus money to propel a > leap > > forward, not just waste it. > > > > On Aug 26, 2009, at 9:44 AM, Carlos Alcantar wrote: > > > >> I think the big push to get the fcc to define broadband is highly based > >> on the rus/ntia setting definitions of what broadband is. If any anyone > >> has been fallowing the rus/ntia they are the one handing out all the > >> stimulus infrastructure grant loan money. So there are a lot of > >> political reasons to make the definition of broadband a bit slower than > >> one would think. I guess it doesn't hurt that the larger lec's with the > >> older infrastructure are shelling out the money to lobby to make sure > >> the definition stays as low as can be. They don't want to see the gov > >> funding there competition. Just my 2 cents. > >> > >> -carlos > >> > >> -----Original Message----- > >> From: Ted Fischer [mailto:ted at fred.net] > >> Sent: Wednesday, August 26, 2009 8:50 AM > >> To: nanog at nanog.org > >> Subject: Re: FCCs RFC for the Definition of Broadband > >> > >> > >> > >> Paul Timmins wrote: > >>> > >>> Fred Baker wrote: > >>>> > >>>> On Aug 24, 2009, at 9:17 AM, Luke Marrott wrote: > >>>> > >>>>> What are your thoughts on what the definition of Broadband should be > >> > >>>>> going > >>>>> forward? I would assume this will be the standard definition for a > >>>>> number of > >>>>> years to come. > >>>> > >>>> > >>>> Historically, narrowband was circuit switched (ISDN etc) and > >> > >> broadband > >>>> > >>>> was packet switched. Narrowband was therefore tied to the digital > >>>> signaling hierarchy and was in some way a multiple of 64 KBPS. As the > >> > >>>> term was used then, broadband delivery options of course included > >>>> virtual circuits bearing packets, like Frame Relay and ATM. > >>> > >>> of or relating to or being a communications network in which the > >>> bandwidth can be divided and shared by multiple simultaneous signals > >> > >> (as > >>> > >>> for voice or data or video) > >>> > >>> That's my humble opinion. Let them use a new term, like "High Speed > >>> Internet". > >>> > >>> > >> Seconded > >> > >> > >> > > > > > > > > This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. From jabley at hopcount.ca Wed Aug 26 15:41:48 2009 From: jabley at hopcount.ca (Joe Abley) Date: Wed, 26 Aug 2009 16:41:48 -0400 Subject: FCCs RFC for the Definition of Broadband In-Reply-To: <3A89064E-4F43-4FFC-B535-B4D971CFDEF0@cisco.com> References: <859604546CD1FF488BDB6EA94C896AFB8ABE40@racexchange.race.local> <3A89064E-4F43-4FFC-B535-B4D971CFDEF0@cisco.com> Message-ID: <23F0D868-2C40-4280-ACB1-C96F7812131C@hopcount.ca> On 26-Aug-2009, at 13:38, Fred Baker wrote: > If it's about stimulus money, I'm in favor of saying that broadband > implies fiber to the home. I'm sure I remember hearing from someone that the timelines for disbursement of stimulus money were tight enough that many people expected much of the money to remain unspent. Does narrowing the scope of the funding to mandate fibre have the effect of funding more and better infrastructure, or will it simply result in less money being made available? Does it matter? From warren at kumari.net Wed Aug 26 16:39:57 2009 From: warren at kumari.net (Warren Kumari) Date: Wed, 26 Aug 2009 17:39:57 -0400 Subject: Data Center testing In-Reply-To: <1c2d53bb0908240638t446b0d18tfc711960b84350fc@mail.gmail.com> References: <1c2d53bb0908240600u1d9bbd48t38023b9900fc4f43@mail.gmail.com> <5b6f80200908240631q7f711db5m26a4f195c647aaeb@mail.gmail.com> <1c2d53bb0908240638t446b0d18tfc711960b84350fc@mail.gmail.com> Message-ID: On Aug 24, 2009, at 9:38 AM, Dan Snyder wrote: > We have done power tests before and had no problem. I guess I am > looking > for someone who does testing of the network equipment outside of > just power > tests. We had an outage due to a configuration mistake that became > apparent > when a switch failed. So, one of the better ways to make sure that your failover system is working when you need it is just to do away with the concept of a failover system and make your "failover" system be part of your "primary" system . This means that your failover system is always passing traffic and you know that it is alive and well -- it also helps mitigate the pain when a device fails (you are sharing the load over both systems and so only half as much traffic gets disrupted). Scheduled maintenance is also simpler and less stressful as you already know that your other path is alive and well. Your design and use case dictates how exactly you implement this, but in general it involves things like tuning your IGP so you are using all your links, staggering VLANs if you rely on them, multiple VRRP groups per subnet, etc. This does require a tiny bit more planning during the design phase, and also requires that you check every now and then to make sure that you are actually using both devices (and didn't, for example, shift traffic to one device and then forget to shift it back :-)). It also requires that you keep capacity issues in mind -- in a primary and failover scenario you might be able to run devices fairly close to capacity, but if you are sharing the load you need to keep things under 50% (so when you *do* have a failure the remaining device can handle the full load) -it's important to make this clear to the finance folks before going down this path :-) W > It didn't cause a problem however when we did a power > test for the whole data center. > > -Dan > > > On Mon, Aug 24, 2009 at 9:31 AM, Ken Gilmour > wrote: > >> I know Peer1 in vancouver reguarly send out notifications of >> "non-impacting" generator load testing, like monthly. Also InterXion >> in Dublin, Ireland have occasionally sent me notification that there >> was a power outage of less than a minute however their backup >> successfully took the load. >> >> I only remember one complete outage in Peer1 a few years ago... Never >> seen any outage in InterXion Dublin. >> >> Also I don't ever remember any power failure at AiNet (Deepak will >> probably elaborate) >> >> 2009/8/24 Dan Snyder : >>> Does any one know of any data centers that do failure testing of >>> their >>> networking equipment >>> regularly? I mean to verify that everything fails over properly >>> after >>> changes have been made over >>> time. Is there any best practice guides for doing this? >>> >>> Thanks, >>> Dan >>> >> -- "Does Emacs have the Buddha nature? Why not? It has bloody well everything else!" From herrin-nanog at dirtside.com Wed Aug 26 16:45:55 2009 From: herrin-nanog at dirtside.com (William Herrin) Date: Wed, 26 Aug 2009 17:45:55 -0400 Subject: FCCs RFC for the Definition of Broadband In-Reply-To: <41A99CED-7857-4E24-B536-31493DE2EB99@cisco.com> References: <4a9edb810908240917r15739868i93ae029165962e9c@mail.gmail.com> <41A99CED-7857-4E24-B536-31493DE2EB99@cisco.com> Message-ID: <3c3e3fca0908261445y77533dbcscd7945aac532e78d@mail.gmail.com> On Tue, Aug 25, 2009 at 7:30 PM, Fred Baker wrote: > On Aug 24, 2009, at 9:17 AM, Luke Marrott wrote: >> What are your thoughts on what the definition of Broadband should be going >> forward? I would assume this will be the standard definition for a number >> of years to come. > > Historically, narrowband was circuit switched (ISDN etc) and broadband was > packet switched. Narrowband was therefore tied to the digital signaling > hierarchy and was in some way a multiple of 64 KBPS. As the term was used > then, broadband delivery options of course included virtual circuits bearing > packets, like Frame Relay and ATM. Fred, Historically there was no such thing as a "narrowband" Internet connection. We used "bandwidth" as slang for the speed of an Internet connection, possibly because in communications in general you can send more information in a wide frequency band than you can in a narrow frequency band and we knew that a phone line used a 4khz frequency band while a T1 used a 1.5mhz frequency band. When we started selling residential Internet connections that were significantly faster than a modem (i.e. DSL, cable modems) some marketing guru somewhere came up with the idea that if Internet speed is bandwidth then fast internet must be -broad- bandwidth. The same marketing gurus wouldn't be particularly guruish if they had then started referring to their modem products as "narrowband." So the choice was "dialup or broadband" not "narrowband or broadband." As the term caught on, it was the expanded by various marketing and salesfolk to encompass any kind of commodity Internet connection (commodity = not custom, that is not doing anything uncommon like dynamic routing or multiplexing) which was better than a dialup modem. When you start assigning CIDR blocks and what not, that's generally a business service rather than "broadband." So historically speaking, broadband is anything faster than POTS dialup. What it -should- mean for stimulus purposes is another matter... But I'd personally prefer to see the stimulus money only used for delivering rural high speed. The telcos and cable companies are in a race to deliver fast residential Internet access in any densely packed area where the governing authority isn't making it a costly PIA to install. Where they need the swift kick in the tail is in the low density areas. Really where they need the swift kick in the tail is in the product tying where you can't buy a high speed connection to J. Random ISP, you can only buy a high speed connection to monopoly provider's in-house ISP. Which means you can only get commodity service since monopoly provider isn't in the business of providing low-dollar custom solutions. But it sounds like that's outside the scope of what Congress has approved. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From nanog at enger.us Wed Aug 26 17:16:17 2009 From: nanog at enger.us (Robert Enger - NANOG) Date: Wed, 26 Aug 2009 15:16:17 -0700 Subject: FCCs RFC for the Definition of Broadband In-Reply-To: References: <4a9edb810908240917r15739868i93ae029165962e9c@mail.gmail.com> <4A9569FF.5000601@nic-naa.net> Message-ID: <4A95B431.70102@enger.us> As tedious as the downstream can be, engineering the upstream path of a cable plant is worse. A lot of older systems were never designed for upstream service. Even if the amps are retrofitted, the plant is just not tight enough. Desirably, fiber should be pushed deeper; the quantity of cascaded amps reduced, coax fittings and splitters replaced and so on. On 8/26/2009 10:25 AM, Richard Bennett wrote: > The trouble with broadband in rural America is the twisted pair loop lengths > that average around 20,000 feet. To use VDSL, the loop length needs to down > around 3000, so they're stuck with ADSL unless the ILEC wants to install a > lot of repeaters. And VDSL is the enabler of triple play over twisted pair. > > And apparently a number of rural cablecos, who have a suitable copper co-ax > plant, haven't seen fit to offer what they call "data service." It's ironic, > since cable TV was actually invented to help the rural user. > > Apparently the purpose of the definition is to ensure that the subsidies > don't do down the rathole of supporting easy upgrades, but as others have > mentioned, one definition for "broadband" isn't very useful unless it's > something like "10 times faster than what I had yesterday." > > I like to say first gen broadband is 10 times faster than a modem or 500 > Kb/s; second gen is 5 Mb/s, and third is 50 or faster. > > Richard Bennett > > -----Original Message----- > From: Eric Brunner-Williams [mailto:brunner at nic-naa.net] > Sent: Wednesday, August 26, 2009 10:00 AM > To: Luke Marrott > Cc: nanog at nanog.org > Subject: Re: FCCs RFC for the Definition of Broadband > > In the applications I wrote earlier this month for BIP (Rural Utilities > Services, USDA) and BTOP (NTIA, non-rural) infrastructure, for Maine's 2nd, > I was keenly aware that broadband hasn't taken off as a pervasive, if not > universal service in rural areas of the US. > > I don't think the speed metric is the metric that will make non-adoption in > sparce clustered demographics distinguishable from adoption in denser > demographics. I suspect that issues like symmetry of state signaling, > latency, jitter, ... metrics that resemble what I looked for from MPI runs > when benchmarking parallel systems, will characterize applications that may > be distinguishable from the adoption, market penetration, renewal criteria > from the applications that for reasons I can only conjecture, the standard > "triple play" killer apps, which simply aren't driving broadband (whatever > that is) adoption in rural areas. And no, I don't know what those > better-than-triple-play-killer-apps-in-suburbia are. > > My meta-point is that I suspect there are two "broadbands", one where > triple-play sells recurring subscriber drops, and one where it doesn't, and > for the later a better definition would be more useful than a definition > that reads (in fine print) "not available here". > > Eric > > > Luke Marrott wrote: > >> I read an article on DSL Reports the other day ( >> http://www.dslreports.com/shownews/FCC-Please-Define-Broadband-104056) >> , in which the FCC has a document requesting feedback on the >> definition of Broadband. >> >> What are your thoughts on what the definition of Broadband should be >> going forward? I would assume this will be the standard definition for >> a number of years to come. >> >> Thanks. >> >> >> > > > > From nanog at enger.us Wed Aug 26 17:20:06 2009 From: nanog at enger.us (Robert Enger - NANOG) Date: Wed, 26 Aug 2009 15:20:06 -0700 Subject: FCCs RFC for the Definition of Broadband In-Reply-To: <3A89064E-4F43-4FFC-B535-B4D971CFDEF0@cisco.com> References: <859604546CD1FF488BDB6EA94C896AFB8ABE40@racexchange.race.local> <3A89064E-4F43-4FFC-B535-B4D971CFDEF0@cisco.com> Message-ID: <4A95B516.3090205@enger.us> The push to dumb down the definition is not only to benefit the legacy providers. It also benefits the politicians. A lower standard means that a greater quantity of citizens can be deemed to have been given broadband. The politicians will claim that they have served more Americans... The hard underlying issue is cost-justifying expensive OSP builds in low-density areas. Yes, aerial construction is cheaper than UG. But, it is still hard to build a business case for providing service in a low-density area, especially as an over-builder. (And any terrestrial provider is essentially an over-builder now that DBS tv service is so pervasive.) One cannot count on ~100% penetration, as was possible when there was only one game in town. I don't know if we can ever cost-justify bringing *real* broadband (un-capped FE, GigE, fiber) service to the hinterland. Many of the countries with higher speed service that we compare ourselves against (e.g. S.Korea) are able to build at a very low price point because they have a very high percentage of MDUs. MDU builds are comparatively low cost. Urban MDU, where you can piggy-back on an existing building-entrance conduit are even cheaper. This is like farm subsidy or foreign aid. The tax payer is asked to subsidize bringing the benefits of modern urban/suburban technology to the middle of nowhere. However, if the program succeeds in increasing broadband penetration (whatever broadband is) perhaps it will have the beneficial effect of making the nation more homogeneous and harmonious. On 8/26/2009 10:38 AM, Fred Baker wrote: > If it's about stimulus money, I'm in favor of saying that broadband > implies fiber to the home. That would provide all sorts of stimuli to > the economy - infrastructure, equipment sales, jobs digging ditches, > and so on. I could pretty quickly argue myself into suggesting special > favors for deployment of DNSSEC, multicast, and IPv6. As in, use the > stimulus money to propel a leap forward, not just waste it. > > On Aug 26, 2009, at 9:44 AM, Carlos Alcantar wrote: > >> I think the big push to get the fcc to define broadband is highly based >> on the rus/ntia setting definitions of what broadband is. If any anyone >> has been fallowing the rus/ntia they are the one handing out all the >> stimulus infrastructure grant loan money. So there are a lot of >> political reasons to make the definition of broadband a bit slower than >> one would think. I guess it doesn't hurt that the larger lec's with the >> older infrastructure are shelling out the money to lobby to make sure >> the definition stays as low as can be. They don't want to see the gov >> funding there competition. Just my 2 cents. >> >> -carlos >> >> -----Original Message----- >> From: Ted Fischer [mailto:ted at fred.net] >> Sent: Wednesday, August 26, 2009 8:50 AM >> To: nanog at nanog.org >> Subject: Re: FCCs RFC for the Definition of Broadband >> >> >> >> Paul Timmins wrote: >>> Fred Baker wrote: >>>> >>>> On Aug 24, 2009, at 9:17 AM, Luke Marrott wrote: >>>> >>>>> What are your thoughts on what the definition of Broadband should be >> >>>>> going >>>>> forward? I would assume this will be the standard definition for a >>>>> number of >>>>> years to come. >>>> >>>> >>>> Historically, narrowband was circuit switched (ISDN etc) and >> broadband >>>> was packet switched. Narrowband was therefore tied to the digital >>>> signaling hierarchy and was in some way a multiple of 64 KBPS. As the >> >>>> term was used then, broadband delivery options of course included >>>> virtual circuits bearing packets, like Frame Relay and ATM. >>> of or relating to or being a communications network in which the >>> bandwidth can be divided and shared by multiple simultaneous signals >> (as >>> for voice or data or video) >>> >>> That's my humble opinion. Let them use a new term, like "High Speed >>> Internet". >>> >>> >> Seconded >> >> >> > > From nanog at enger.us Wed Aug 26 17:29:10 2009 From: nanog at enger.us (Robert Enger - NANOG) Date: Wed, 26 Aug 2009 15:29:10 -0700 Subject: FCCs RFC for the Definition of Broadband In-Reply-To: <4A9587B0.4080306@brightok.net> References: <859604546CD1FF488BDB6EA94C896AFB8ABE40@racexchange.race.local> <3A89064E-4F43-4FFC-B535-B4D971CFDEF0@cisco.com> <4A9587B0.4080306@brightok.net> Message-ID: <4A95B736.2040409@enger.us> CON: active devices in the OSP. On 8/26/2009 12:06 PM, Jack Bates wrote: > jim deleskie wrote: >> I agree we should all be telling the FCC that broadband is fiber to >> the home. If we spend all kinds of $$ to build a 1.5M/s connection to >> homes, it's outdated before we even finish. > > I disagree. I much prefer fiber to the curb with copper to the home. > Of course, I haven't had a need for 100mb/s to the house which I can > do on copper, much less need for gigabit. > > Pro's for copper from curb: > > 1) power over copper for POTS > 2) Majority of cuts occur on customer drops and copper is more > resilient to splicing by any monkey. > > Jack > From richard at bennett.com Wed Aug 26 17:39:14 2009 From: richard at bennett.com (Richard Bennett) Date: Wed, 26 Aug 2009 15:39:14 -0700 Subject: FCCs RFC for the Definition of Broadband In-Reply-To: <23F0D868-2C40-4280-ACB1-C96F7812131C@hopcount.ca> References: <859604546CD1FF488BDB6EA94C896AFB8ABE40@racexchange.race.local><3A89064E-4F43-4FFC-B535-B4D971CFDEF0@cisco.com> <23F0D868-2C40-4280-ACB1-C96F7812131C@hopcount.ca> Message-ID: <054C97C038464CEDB8AEE9BDDAC60966@Honkin> They have a saying in politics to the effect that "the perfect is the enemy of the good." This is a pretty good illustration. We have the opportunity to improve connectivity in rural America through the wise expenditure of taxpayer funding, and it's best not to squander it by insisting on top-shelf fiber or nothing at all. Let's push the fiber a little deeper, and bridge the last 20,000 feet with something that won't be too expensive to replace in 3-5 years. The budget ($7B) just isn't there to give every barn some nice GigE fiber, even though it would make the cows happy. Richard Bennett -----Original Message----- From: Joe Abley [mailto:jabley at hopcount.ca] Sent: Wednesday, August 26, 2009 1:42 PM To: Fred Baker Cc: nanog at nanog.org Subject: Re: FCCs RFC for the Definition of Broadband On 26-Aug-2009, at 13:38, Fred Baker wrote: > If it's about stimulus money, I'm in favor of saying that broadband > implies fiber to the home. I'm sure I remember hearing from someone that the timelines for disbursement of stimulus money were tight enough that many people expected much of the money to remain unspent. Does narrowing the scope of the funding to mandate fibre have the effect of funding more and better infrastructure, or will it simply result in less money being made available? Does it matter? From scott at sberkman.net Wed Aug 26 17:43:26 2009 From: scott at sberkman.net (Scott Berkman) Date: Wed, 26 Aug 2009 18:43:26 -0400 Subject: MTAs used In-Reply-To: References: <14510.1251316871@turing-police.cc.vt.edu> Message-ID: <033901ca269e$a06014a0$e1203de0$@net> If I had to guess.. Postfix Sendmail Exim ComminigatePro Beyond those you'd probably see a lot of the free webmail carriers (Gmail, yahoo, and hotmail/live all use "custom" MTA's) as well as IPSwitch's iMail and the Windows Server/IIS SMTP service. -Scott -----Original Message----- From: Deepak Jain [mailto:deepak at ai.net] Sent: Wednesday, August 26, 2009 4:10 PM To: Valdis.Kletnieks at vt.edu; Sharef Mustafa Cc: nanog at nanog.org Subject: RE: MTAs used > Now, did you want that in terms of "number of copies installed" or > "amount of mail handled"? There's probably zillions of little Fedora > and > Ubuntu boxes running whatever MTA came off the disk that are handling 1 > or 2 pieces of mail a day, and then there's whatever backends are used > by MSN/Hotmail, Yahoo, AOL, etc. "This MTA packed by weight, not by > volume. > Some settling of contents may have occurred during shipping and > spamming." > > (Seriously - if 95% of the mail out there is spam, then the top 4-5 > MTAs are probably the ratware that's sending out the spam. Something > to consider...) In keeping with this concept, and turning it around. What MTA is exposed to the most spam? (1-x) That should tell you what MTA handles the most "good" mail by also being the destination for the most spam (good, live recipients). Or I could be missing something well known about mail flows. Deepak From David at hughes.com.au Wed Aug 26 17:14:48 2009 From: David at hughes.com.au (David Hughes) Date: Thu, 27 Aug 2009 08:14:48 +1000 Subject: Alternatives to storm-control on Cat 6509. In-Reply-To: <82a67ea80908251321u2217d3en30bff225bd7ccf8a@mail.gmail.com> References: <485ED9BA02629E4BBBA53AC892EDA50E097F98B2@usmsxt104.mwd.h2o> <4A92FF4F.9000109@foobar.org> <82a67ea80908251321u2217d3en30bff225bd7ccf8a@mail.gmail.com> Message-ID: <3649B91F-C6BD-4CD3-9402-F86B86D84812@Hughes.com.au> On 26/08/2009, at 6:21 AM, Mike Bartz wrote: > We experienced the joy of using the X6148 cards with a SAN/ESX > cluster. > Lots of performance issues! A fairly inexpensive solution was to > switch to > the X6148A card instead, which does not suffer the the 8:1 > oversubscription. It also supports MTU's larger than 1500, which was > another shortcoming of the older card. Actually, the "A" variant of the x6148 is still 8:1 oversubscribed. The significant difference between the x6148 and x6148a is the buffer size. The original card had 1.4MB of buffer per port group (8 ports) while the "A" upgrade supports 5.5MB per port. Oh, that and support for 9k jumbo frames. It's still a classic bus card, it still has the same QoS queues, and is still 8:1 over subscribed. David ... From jeffrey.lyon at blacklotus.net Wed Aug 26 18:09:47 2009 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Wed, 26 Aug 2009 19:09:47 -0400 Subject: FCCs RFC for the Definition of Broadband In-Reply-To: <054C97C038464CEDB8AEE9BDDAC60966@Honkin> References: <859604546CD1FF488BDB6EA94C896AFB8ABE40@racexchange.race.local> <3A89064E-4F43-4FFC-B535-B4D971CFDEF0@cisco.com> <23F0D868-2C40-4280-ACB1-C96F7812131C@hopcount.ca> <054C97C038464CEDB8AEE9BDDAC60966@Honkin> Message-ID: <16720fe00908261609x129a539bv33f24dd24542b31c@mail.gmail.com> I would argue that "broadband" is the upper X percentile of bandwidth options available to residential users. For instance, something like Verizon FiOS would be broadband while a 7 Mbps cable wouldn't. Jeff On Wed, Aug 26, 2009 at 6:39 PM, Richard Bennett wrote: > They have a saying in politics to the effect that "the perfect is the enemy > of the good." This is a pretty good illustration. We have the opportunity to > improve connectivity in rural America through the wise expenditure of > taxpayer funding, and it's best not to squander it by insisting on top-shelf > fiber or nothing at all. Let's push the fiber a little deeper, and bridge > the last 20,000 feet with something that won't be too expensive to replace > in 3-5 years. The budget ($7B) just isn't there to give every barn some nice > GigE fiber, even though it would make the cows happy. > > Richard Bennett > > -----Original Message----- > From: Joe Abley [mailto:jabley at hopcount.ca] > Sent: Wednesday, August 26, 2009 1:42 PM > To: Fred Baker > Cc: nanog at nanog.org > Subject: Re: FCCs RFC for the Definition of Broadband > > > On 26-Aug-2009, at 13:38, Fred Baker wrote: > >> If it's about stimulus money, I'm in favor of saying that broadband >> implies fiber to the home. > > I'm sure I remember hearing from someone that the timelines for disbursement > of stimulus money were tight enough that many people expected much of the > money to remain unspent. > > Does narrowing the scope of the funding to mandate fibre have the effect of > funding more and better infrastructure, or will it simply result in less > money being made available? Does it matter? > > > > > -- Jeffrey Lyon, Leadership Team jeffrey.lyon at blacklotus.net | http://www.blacklotus.net Black Lotus Communications of The IRC Company, Inc. Platinum sponsor of HostingCon 2010. Come to Austin, TX on July 19 - 21 to find out how to "protect your booty." From deepak at ai.net Wed Aug 26 18:17:32 2009 From: deepak at ai.net (Deepak Jain) Date: Wed, 26 Aug 2009 19:17:32 -0400 Subject: FCCs RFC for the Definition of Broadband Message-ID: Key characteristics of broadband : always on capability (reasonably, DSL ok, dial up no). I would argue 7mb is broadband even if its over carrier pigeon. (meets always on criteria). I think the threshold for cut off is somewhere between 256kbit/s and 1.5mbit/s. If you don't think 1.5mbit is broadband, you need to consider tiers... Most of the worlds population will not see *that* speed in 20yrs. Deepak ----- Original Message ----- From: Jeffrey Lyon To: nanog at nanog.org Sent: Wed Aug 26 19:09:47 2009 Subject: Re: FCCs RFC for the Definition of Broadband I would argue that "broadband" is the upper X percentile of bandwidth options available to residential users. For instance, something like Verizon FiOS would be broadband while a 7 Mbps cable wouldn't. Jeff On Wed, Aug 26, 2009 at 6:39 PM, Richard Bennett wrote: > They have a saying in politics to the effect that "the perfect is the enemy > of the good." This is a pretty good illustration. We have the opportunity to > improve connectivity in rural America through the wise expenditure of > taxpayer funding, and it's best not to squander it by insisting on top-shelf > fiber or nothing at all. Let's push the fiber a little deeper, and bridge > the last 20,000 feet with something that won't be too expensive to replace > in 3-5 years. The budget ($7B) just isn't there to give every barn some nice > GigE fiber, even though it would make the cows happy. > > Richard Bennett > > -----Original Message----- > From: Joe Abley [mailto:jabley at hopcount.ca] > Sent: Wednesday, August 26, 2009 1:42 PM > To: Fred Baker > Cc: nanog at nanog.org > Subject: Re: FCCs RFC for the Definition of Broadband > > > On 26-Aug-2009, at 13:38, Fred Baker wrote: > >> If it's about stimulus money, I'm in favor of saying that broadband >> implies fiber to the home. > > I'm sure I remember hearing from someone that the timelines for disbursement > of stimulus money were tight enough that many people expected much of the > money to remain unspent. > > Does narrowing the scope of the funding to mandate fibre have the effect of > funding more and better infrastructure, or will it simply result in less > money being made available? Does it matter? > > > > > -- Jeffrey Lyon, Leadership Team jeffrey.lyon at blacklotus.net | http://www.blacklotus.net Black Lotus Communications of The IRC Company, Inc. Platinum sponsor of HostingCon 2010. Come to Austin, TX on July 19 - 21 to find out how to "protect your booty." From rsk at gsp.org Wed Aug 26 18:29:39 2009 From: rsk at gsp.org (Rich Kulawiec) Date: Wed, 26 Aug 2009 19:29:39 -0400 Subject: MTAs used In-Reply-To: <14510.1251316871@turing-police.cc.vt.edu> References: <14510.1251316871@turing-police.cc.vt.edu> Message-ID: <20090826232939.GA6664@gsp.org> On Wed, Aug 26, 2009 at 04:01:11PM -0400, Valdis.Kletnieks at vt.edu wrote: > (Seriously - if 95% of the mail out there is spam, then the top 4-5 MTAs are > probably the ratware that's sending out the spam. Something to consider...) That's true, especially given the size of the installed base. So in terms of (a) installations (b) message count (c) message volume (d) recipient count (e) etc. those ratware programs have got to be so far ahead of the usual suspects (sendmail, postfix, exim, etc.) that it's not even a race. ---Rsk From deleskie at gmail.com Wed Aug 26 18:44:48 2009 From: deleskie at gmail.com (jim deleskie) Date: Wed, 26 Aug 2009 19:44:48 -0400 Subject: FCCs RFC for the Definition of Broadband In-Reply-To: <054C97C038464CEDB8AEE9BDDAC60966@Honkin> References: <859604546CD1FF488BDB6EA94C896AFB8ABE40@racexchange.race.local> <3A89064E-4F43-4FFC-B535-B4D971CFDEF0@cisco.com> <23F0D868-2C40-4280-ACB1-C96F7812131C@hopcount.ca> <054C97C038464CEDB8AEE9BDDAC60966@Honkin> Message-ID: Having worked for rather large MSO in past I can tell you the issue with this that the cost man power and engineering time to go back and replace today with 3-5 forward technology is mostly like more then delta between copper and fiber today. -jim On Wed, Aug 26, 2009 at 6:39 PM, Richard Bennett wrote: > They have a saying in politics to the effect that "the perfect is the enemy > of the good." This is a pretty good illustration. We have the opportunity to > improve connectivity in rural America through the wise expenditure of > taxpayer funding, and it's best not to squander it by insisting on top-shelf > fiber or nothing at all. Let's push the fiber a little deeper, and bridge > the last 20,000 feet with something that won't be too expensive to replace > in 3-5 years. The budget ($7B) just isn't there to give every barn some nice > GigE fiber, even though it would make the cows happy. > > Richard Bennett > > -----Original Message----- > From: Joe Abley [mailto:jabley at hopcount.ca] > Sent: Wednesday, August 26, 2009 1:42 PM > To: Fred Baker > Cc: nanog at nanog.org > Subject: Re: FCCs RFC for the Definition of Broadband > > > On 26-Aug-2009, at 13:38, Fred Baker wrote: > >> If it's about stimulus money, I'm in favor of saying that broadband >> implies fiber to the home. > > I'm sure I remember hearing from someone that the timelines for disbursement > of stimulus money were tight enough that many people expected much of the > money to remain unspent. > > Does narrowing the scope of the funding to mandate fibre have the effect of > funding more and better infrastructure, or will it simply result in less > money being made available? Does it matter? > > > > > From bjorn at mork.no Wed Aug 26 18:51:26 2009 From: bjorn at mork.no (=?utf-8?Q?Bj=C3=B8rn_Mork?=) Date: Thu, 27 Aug 2009 01:51:26 +0200 Subject: MTAs used In-Reply-To: <14510.1251316871@turing-police.cc.vt.edu> (Valdis Kletnieks's message of "Wed, 26 Aug 2009 16:01:11 -0400") References: <14510.1251316871@turing-police.cc.vt.edu> Message-ID: <87iqgadthd.fsf@nemi.mork.no> Valdis.Kletnieks at vt.edu writes: > On Wed, 26 Aug 2009 16:50:51 +0300, Sharef Mustafa said: >> Can anyone please point me to a list of the most used MTAs (mail >> servers) and their market share? > > Now, did you want that in terms of "number of copies installed" or > "amount of mail handled"? Or maybe "used by most real companies"? http://www.oreillynet.com/pub/a/sysadmin/2007/01/05/fingerprinting-mail-servers.html Bj?rn From deleskie at gmail.com Wed Aug 26 18:51:35 2009 From: deleskie at gmail.com (jim deleskie) Date: Wed, 26 Aug 2009 19:51:35 -0400 Subject: FCCs RFC for the Definition of Broadband In-Reply-To: References: Message-ID: And 640k is enough. When I started in this game 15 or so yrs back the 'backbone' in Canada was a 56k figure 8 loop, running frame relay. We moved to T1 a yr or so later. Buy the time I left Canada to work for internetMCI a yr later, we're @ DS3's in Canada. Technology evolves quickly. Just because some place does not have 'high-speed' internet now, doesn't mean they will not in 5 yrs. I sure we could site here and site all the places in the world they will not due to politics/poverty/all other bad things in the world, but its not reason to limit the goals of people that are part of these projects. -jim On Wed, Aug 26, 2009 at 7:17 PM, Deepak Jain wrote: > Key characteristics of broadband : always on capability (reasonably, DSL ok, dial up no). I would argue 7mb is broadband even if its over carrier pigeon. (meets always on criteria). > > I think the threshold for cut off is somewhere between 256kbit/s and 1.5mbit/s. If you don't think 1.5mbit is broadband, you need to consider tiers... Most of the worlds population will not see *that* speed in 20yrs. > > Deepak > > ----- Original Message ----- > From: Jeffrey Lyon > To: nanog at nanog.org > Sent: Wed Aug 26 19:09:47 2009 > Subject: Re: FCCs RFC for the Definition of Broadband > > I would argue that "broadband" is the upper X percentile of bandwidth > options available to residential users. For instance, something like > Verizon FiOS would be broadband while a 7 Mbps cable wouldn't. > > Jeff > > On Wed, Aug 26, 2009 at 6:39 PM, Richard Bennett wrote: >> They have a saying in politics to the effect that "the perfect is the enemy >> of the good." This is a pretty good illustration. We have the opportunity to >> improve connectivity in rural America through the wise expenditure of >> taxpayer funding, and it's best not to squander it by insisting on top-shelf >> fiber or nothing at all. Let's push the fiber a little deeper, and bridge >> the last 20,000 feet with something that won't be too expensive to replace >> in 3-5 years. The budget ($7B) just isn't there to give every barn some nice >> GigE fiber, even though it would make the cows happy. >> >> Richard Bennett >> >> -----Original Message----- >> From: Joe Abley [mailto:jabley at hopcount.ca] >> Sent: Wednesday, August 26, 2009 1:42 PM >> To: Fred Baker >> Cc: nanog at nanog.org >> Subject: Re: FCCs RFC for the Definition of Broadband >> >> >> On 26-Aug-2009, at 13:38, Fred Baker wrote: >> >>> If it's about stimulus money, I'm in favor of saying that broadband >>> implies fiber to the home. >> >> I'm sure I remember hearing from someone that the timelines for disbursement >> of stimulus money were tight enough that many people expected much of the >> money to remain unspent. >> >> Does narrowing the scope of the funding to mandate fibre have the effect of >> funding more and better infrastructure, or will it simply result in less >> money being made available? Does it matter? >> >> >> >> >> > > > > -- > Jeffrey Lyon, Leadership Team > jeffrey.lyon at blacklotus.net | http://www.blacklotus.net > Black Lotus Communications of The IRC Company, Inc. > > Platinum sponsor of HostingCon 2010. Come to Austin, TX on July 19 - > 21 to find out how to "protect your booty." > > From r.engehausen at gmail.com Wed Aug 26 19:00:05 2009 From: r.engehausen at gmail.com (Roy) Date: Wed, 26 Aug 2009 17:00:05 -0700 Subject: FCCs RFC for the Definition of Broadband In-Reply-To: References: Message-ID: <4A95CC85.8080102@gmail.com> I think it has become obvious that the correct definition of broadband depends on the users location. A house in the boonies is not going to get fiber, Perhaps the minimum acceptable bandwidth should vary by area. A definition of "area" could be some sort of user density measurement by census tract. Deepak Jain wrote: > Key characteristics of broadband : always on capability (reasonably, DSL ok, dial up no). I would argue 7mb is broadband even if its over carrier pigeon. (meets always on criteria). > > I think the threshold for cut off is somewhere between 256kbit/s and 1.5mbit/s. If you don't think 1.5mbit is broadband, you need to consider tiers... Most of the worlds population will not see *that* speed in 20yrs. > > Deepak > > ----- Original Message ----- > From: Jeffrey Lyon > To: nanog at nanog.org > Sent: Wed Aug 26 19:09:47 2009 > Subject: Re: FCCs RFC for the Definition of Broadband > > I would argue that "broadband" is the upper X percentile of bandwidth > options available to residential users. For instance, something like > Verizon FiOS would be broadband while a 7 Mbps cable wouldn't. > > Jeff > > On Wed, Aug 26, 2009 at 6:39 PM, Richard Bennett wrote: > >> They have a saying in politics to the effect that "the perfect is the enemy >> of the good." This is a pretty good illustration. We have the opportunity to >> improve connectivity in rural America through the wise expenditure of >> taxpayer funding, and it's best not to squander it by insisting on top-shelf >> fiber or nothing at all. Let's push the fiber a little deeper, and bridge >> the last 20,000 feet with something that won't be too expensive to replace >> in 3-5 years. The budget ($7B) just isn't there to give every barn some nice >> GigE fiber, even though it would make the cows happy. >> >> Richard Bennett >> >> -----Original Message----- >> From: Joe Abley [mailto:jabley at hopcount.ca] >> Sent: Wednesday, August 26, 2009 1:42 PM >> To: Fred Baker >> Cc: nanog at nanog.org >> Subject: Re: FCCs RFC for the Definition of Broadband >> >> >> On 26-Aug-2009, at 13:38, Fred Baker wrote: >> >> >>> If it's about stimulus money, I'm in favor of saying that broadband >>> implies fiber to the home. >>> >> I'm sure I remember hearing from someone that the timelines for disbursement >> of stimulus money were tight enough that many people expected much of the >> money to remain unspent. >> >> Does narrowing the scope of the funding to mandate fibre have the effect of >> funding more and better infrastructure, or will it simply result in less >> money being made available? Does it matter? >> >> >> >> >> >> > > > > From deleskie at gmail.com Wed Aug 26 19:12:41 2009 From: deleskie at gmail.com (jim deleskie) Date: Wed, 26 Aug 2009 20:12:41 -0400 Subject: FCCs RFC for the Definition of Broadband In-Reply-To: <4A95CC85.8080102@gmail.com> References: <4A95CC85.8080102@gmail.com> Message-ID: Why should I person be disadvantage from another in the same country, maybe its the Canadian in me, but isn't there something in the founding documents of the US that define's all men as being equal. I though it was Orewell that made some more equal then others. :) -jim On Wed, Aug 26, 2009 at 8:00 PM, Roy wrote: > I think it has become obvious that the correct definition of broadband > depends on the users location. ?A house in the boonies is not going to get > fiber, ?Perhaps the minimum acceptable bandwidth should vary by area. ?A > definition of "area" could be some sort of user density measurement by > census tract. > > > Deepak Jain wrote: >> >> Key characteristics of broadband : always on capability (reasonably, DSL >> ok, dial up no). I would argue 7mb is broadband even if its over carrier >> pigeon. (meets always on criteria). >> >> I think the threshold for cut off is somewhere between 256kbit/s and >> 1.5mbit/s. If you don't think 1.5mbit is broadband, you need to consider >> tiers... Most of the worlds population will not see *that* speed in 20yrs. >> >> Deepak >> >> ----- Original Message ----- >> From: Jeffrey Lyon >> To: nanog at nanog.org >> Sent: Wed Aug 26 19:09:47 2009 >> Subject: Re: FCCs RFC for the Definition of Broadband >> >> I would argue that "broadband" is the upper X percentile of bandwidth >> options available to residential users. For instance, something like >> Verizon FiOS would be broadband while a 7 Mbps cable wouldn't. >> >> Jeff >> >> On Wed, Aug 26, 2009 at 6:39 PM, Richard Bennett >> wrote: >> >>> >>> They have a saying in politics to the effect that "the perfect is the >>> enemy >>> of the good." This is a pretty good illustration. We have the opportunity >>> to >>> improve connectivity in rural America through the wise expenditure of >>> taxpayer funding, and it's best not to squander it by insisting on >>> top-shelf >>> fiber or nothing at all. Let's push the fiber a little deeper, and bridge >>> the last 20,000 feet with something that won't be too expensive to >>> replace >>> in 3-5 years. The budget ($7B) just isn't there to give every barn some >>> nice >>> GigE fiber, even though it would make the cows happy. >>> >>> Richard Bennett >>> >>> -----Original Message----- >>> From: Joe Abley [mailto:jabley at hopcount.ca] >>> Sent: Wednesday, August 26, 2009 1:42 PM >>> To: Fred Baker >>> Cc: nanog at nanog.org >>> Subject: Re: FCCs RFC for the Definition of Broadband >>> >>> >>> On 26-Aug-2009, at 13:38, Fred Baker wrote: >>> >>> >>>> >>>> If it's about stimulus money, I'm in favor of saying that broadband >>>> implies fiber to the home. >>>> >>> >>> I'm sure I remember hearing from someone that the timelines for >>> disbursement >>> of stimulus money were tight enough that many people expected much of the >>> money to remain unspent. >>> >>> Does narrowing the scope of the funding to mandate fibre have the effect >>> of >>> funding more and better infrastructure, or will it simply result in less >>> money being made available? Does it matter? >>> >>> >>> >>> >>> >>> >> >> >> >> > > > From bicknell at ufp.org Wed Aug 26 19:18:56 2009 From: bicknell at ufp.org (Leo Bicknell) Date: Wed, 26 Aug 2009 20:18:56 -0400 Subject: FCCs RFC for the Definition of Broadband In-Reply-To: <4a9edb810908240917r15739868i93ae029165962e9c@mail.gmail.com> References: <4a9edb810908240917r15739868i93ae029165962e9c@mail.gmail.com> Message-ID: <20090827001856.GA8878@ussenterprise.ufp.org> In a message written on Mon, Aug 24, 2009 at 10:17:02AM -0600, Luke Marrott wrote: > I read an article on DSL Reports the other day ( > http://www.dslreports.com/shownews/FCC-Please-Define-Broadband-104056), in > which the FCC has a document requesting feedback on the definition of > Broadband. > > What are your thoughts on what the definition of Broadband should be going > forward? I would assume this will be the standard definition for a number of > years to come. I'm not sure the defintion of Broadband matters, what matters is that we keep moving forward. We should set a goal of all American's having a speed twice as fast in 5 years. And after that twice as fast again in another 5 years. There is no bar we reach where we are "done". -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 825 bytes Desc: not available URL: From r.engehausen at gmail.com Wed Aug 26 19:20:59 2009 From: r.engehausen at gmail.com (Roy) Date: Wed, 26 Aug 2009 17:20:59 -0700 Subject: FCCs RFC for the Definition of Broadband In-Reply-To: References: <4A95CC85.8080102@gmail.com> Message-ID: <4A95D16B.9080904@gmail.com> We are talking government handouts here and they never make sense.... jim deleskie wrote: > Why should I person be disadvantage from another in the same country, > maybe its the Canadian in me, but isn't there something in the > founding documents of the US that define's all men as being equal. I > though it was Orewell that made some more equal then others. :) > > -jim > > On Wed, Aug 26, 2009 at 8:00 PM, Roy wrote: > >> I think it has become obvious that the correct definition of broadband >> depends on the users location. A house in the boonies is not going to get >> fiber, Perhaps the minimum acceptable bandwidth should vary by area. A >> definition of "area" could be some sort of user density measurement by >> census tract. >> >> >> From mysidia at gmail.com Wed Aug 26 19:46:06 2009 From: mysidia at gmail.com (James Hess) Date: Wed, 26 Aug 2009 19:46:06 -0500 Subject: MTAs used In-Reply-To: <14510.1251316871@turing-police.cc.vt.edu> References: <14510.1251316871@turing-police.cc.vt.edu> Message-ID: <6eb799ab0908261746m1b4b537en55a8b1aaff78cc5f@mail.gmail.com> On Wed, Aug 26, 2009 at 3:01 PM, wrote: > (Seriously - if 95% of the mail out there is spam, then the top 4-5 MTAs are > probably the ratware that's sending out the spam. ?Something to consider...) http://www.mailradar.com/mailstat/ Some of the most popular: 1. Sendmail; (24%) 2. Postfix (20%) 3. Qmail (17%) 4. Microsoft Mail In all fairness, the ratware programs that send out spam are usually MUAs, not MTAs, [RFC2476]. "Message Transfer Agent (MTA) -- A process which conforms to [SMTP-MTA], which acts as an SMTP server to accept messages from an MSA or another MTA" SMTP server installs that do not accept mail from other servers might be MSAs but are not MTAs. (The default mail server installed in Fedora doesn't count as a MTA, unless reconfigured to listen on some network interface, because the default config only accepts a SMTP connection from a local MUA using network loopback.) -- -- -J From carlos at race.com Wed Aug 26 20:49:17 2009 From: carlos at race.com (Carlos Alcantar) Date: Wed, 26 Aug 2009 18:49:17 -0700 Subject: MRLG Message-ID: <859604546CD1FF488BDB6EA94C896AFB8ABE6C@racexchange.race.local> Anyone seem to have the src code to Multi-Router Looking Glass version 5.4.1 Beta (the perl version) seem like the original site that has the src is down. -carlos From carlos at race.com Wed Aug 26 21:11:46 2009 From: carlos at race.com (Carlos Alcantar) Date: Wed, 26 Aug 2009 19:11:46 -0700 Subject: MRLG Message-ID: <859604546CD1FF488BDB6EA94C896AFB8ABE6F@racexchange.race.local> Thanks guys I got it... -carlos -----Original Message----- From: Carlos Alcantar [mailto:carlos at race.com] Sent: Wednesday, August 26, 2009 6:49 PM To: nanog at nanog.org Subject: MRLG Anyone seem to have the src code to Multi-Router Looking Glass version 5.4.1 Beta (the perl version) seem like the original site that has the src is down. -carlos From cmadams at hiwaay.net Wed Aug 26 21:11:57 2009 From: cmadams at hiwaay.net (Chris Adams) Date: Wed, 26 Aug 2009 21:11:57 -0500 Subject: FCCs RFC for the Definition of Broadband In-Reply-To: References: <4A95CC85.8080102@gmail.com> Message-ID: <20090827021157.GA683487@hiwaay.net> Once upon a time, jim deleskie said: > Why should I person be disadvantage from another in the same country, > maybe its the Canadian in me, but isn't there something in the > founding documents of the US that define's all men as being equal. Nobody is forcing anybody to live out where high-speed Internet is not currently feasible (or at least not at a price that those residents want to pay). I live half a mile from a six lane highway; that doesn't mean that we have to build six lane highways to within half a mile of everybody in the country. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From deleskie at gmail.com Wed Aug 26 21:19:32 2009 From: deleskie at gmail.com (jim deleskie) Date: Wed, 26 Aug 2009 22:19:32 -0400 Subject: FCCs RFC for the Definition of Broadband In-Reply-To: <20090827021157.GA683487@hiwaay.net> References: <4A95CC85.8080102@gmail.com> <20090827021157.GA683487@hiwaay.net> Message-ID: Wrong analogy, you have no way to use all 6 lanes @ once. The highway is an aggregation device not access method. Unless you have 6 lanes into your driveway :) On Wed, Aug 26, 2009 at 10:11 PM, Chris Adams wrote: > Once upon a time, jim deleskie said: >> Why should I person be disadvantage from another in the same country, >> maybe its the Canadian in me, but isn't there something in the >> founding documents of the US that define's all men as being equal. > > Nobody is forcing anybody to live out where high-speed Internet is not > currently feasible (or at least not at a price that those residents want > to pay). ?I live half a mile from a six lane highway; that doesn't mean > that we have to build six lane highways to within half a mile of > everybody in the country. > > -- > Chris Adams > Systems and Network Administrator - HiWAAY Internet Services > I don't speak for anybody but myself - that's enough trouble. > > From sean at donelan.com Wed Aug 26 21:52:56 2009 From: sean at donelan.com (Sean Donelan) Date: Wed, 26 Aug 2009 22:52:56 -0400 (EDT) Subject: FCCs RFC for the Definition of Broadband In-Reply-To: <3A89064E-4F43-4FFC-B535-B4D971CFDEF0@cisco.com> References: <859604546CD1FF488BDB6EA94C896AFB8ABE40@racexchange.race.local> <3A89064E-4F43-4FFC-B535-B4D971CFDEF0@cisco.com> Message-ID: <200908262219150.2D3A1E03.27432@clifden.donelan.com> On Wed, 26 Aug 2009, Fred Baker wrote: > If it's about stimulus money, I'm in favor of saying that broadband implies > fiber to the home. That would provide all sorts of stimuli to the economy - > infrastructure, equipment sales, jobs digging ditches, and so on. I could > pretty quickly argue myself into suggesting special favors for deployment of > DNSSEC, multicast, and IPv6. As in, use the stimulus money to propel a leap > forward, not just waste it. Broadband stimulus money = $7,200,000,000 Housing units in USA (2000) = 115,904,641 Stimulus money per housing unit = $62.12 one-time What definition of "broadband" can you achieve for that amount of money? Or for rural housing units (2000) = 25,938,698 Stimulus money per rural housing unit = $277.58 one-time What definition of "broadband" can you achieve for that amount of money in a rural build-out? How much will fiber to the home cost in a rural area? From jbates at brightok.net Wed Aug 26 22:20:22 2009 From: jbates at brightok.net (Jack Bates) Date: Wed, 26 Aug 2009 22:20:22 -0500 Subject: FCCs RFC for the Definition of Broadband In-Reply-To: <4A95B736.2040409@enger.us> References: <859604546CD1FF488BDB6EA94C896AFB8ABE40@racexchange.race.local> <3A89064E-4F43-4FFC-B535-B4D971CFDEF0@cisco.com> <4A9587B0.4080306@brightok.net> <4A95B736.2040409@enger.us> Message-ID: <4A95FB76.7090707@brightok.net> heh. I've seen 3 different plans for FTTH in 3 different telco's; different engineering firms. All 3 had active devices in the OSP. Apparently they couldn't justify putting more fiber in all the way back to the office. Don't get me wrong. I've heard wonderful drawn out arguments concerning vendors that failed to properly handle Oklahoma summers or draw too much power. Brings up new PRO: active devices in the OSP providing longhaul redundancy on fiber rings Another PRO: simple, inexpensive NID Jack Robert Enger - NANOG wrote: > > CON: active devices in the OSP. > > > On 8/26/2009 12:06 PM, Jack Bates wrote: >> jim deleskie wrote: >>> I agree we should all be telling the FCC that broadband is fiber to >>> the home. If we spend all kinds of $$ to build a 1.5M/s connection to >>> homes, it's outdated before we even finish. >> >> I disagree. I much prefer fiber to the curb with copper to the home. >> Of course, I haven't had a need for 100mb/s to the house which I can >> do on copper, much less need for gigabit. >> >> Pro's for copper from curb: >> >> 1) power over copper for POTS >> 2) Majority of cuts occur on customer drops and copper is more >> resilient to splicing by any monkey. >> >> Jack >> From kevin at qis.net Wed Aug 26 22:38:32 2009 From: kevin at qis.net (Kevin Brown) Date: Wed, 26 Aug 2009 23:38:32 -0400 Subject: Qwest IPv6 Message-ID: <4A95FFB8.2000000@qis.net> Does anyone have a contact at Qwest who can help us get the ball rolling to implement an exchange of IPv6 traffic? Their NOC referred us back to our account manager, who said "We don't do IPv6". A quick Google search would seem to indicate otherwise... Thanks! -- ------------------------------------------------------------------------ Kevin W. Brown | 2975B Manchester Rd. | E-Mail: kevin at qis.net Quantum Internet Services | Manchester, MD 21102 | Voice: 410-239-6920 ------------------------------------------------------------------------ My current spamtrap: qstkb74027451 at qis.net From jbates at brightok.net Wed Aug 26 22:40:38 2009 From: jbates at brightok.net (Jack Bates) Date: Wed, 26 Aug 2009 22:40:38 -0500 Subject: FCCs RFC for the Definition of Broadband In-Reply-To: <200908262219150.2D3A1E03.27432@clifden.donelan.com> References: <859604546CD1FF488BDB6EA94C896AFB8ABE40@racexchange.race.local> <3A89064E-4F43-4FFC-B535-B4D971CFDEF0@cisco.com> <200908262219150.2D3A1E03.27432@clifden.donelan.com> Message-ID: <4A960036.6000006@brightok.net> Sean Donelan wrote: > Stimulus money per rural housing unit = $277.58 one-time > > What definition of "broadband" can you achieve for that amount of money > in a rural build-out? > > How much will fiber to the home cost in a rural area? For 1-2k customers in small rural towns I've been hearing numbers in the millions of dollars without FTTH. FTTH projects exceeded all DSL in price and had higher cost NIDs. There are also more engineering details that must be considered in FTTH (and standard telco engineering firms sometimes screw up on it; running the bill up more) to cover voice concerns. And while everyone is arguing about this, I'll let you know right now it is much MUCH harder to get money when putting copper in than fiber; including many of the different types of loans. I've seen people screwed over because of the push to fiber which has often made it cost prohibitive for them to get service and strained the telco finances reducing their overall ability to support service. So, yeah. I'd be happy if everyone would back down and quit pushing FTTH so hard and support sound, reliable, inexpensive FTTC technologies. They both have their place. Just for the record, I still have over 50% of my customer base in dialup. Of course, 98% of those dialups are in AT&T territory. My ILEC/CLEC customers have done well in providing DSL to a majority of their customers. They have even increased bandwidth where they can and tariffs allow. I hope to see AT&T expand further out than 3 miles from the CO, upgrading some of their double ended carrier and putting in DSL capable remotes. Given they probably can't recover costs on some of the existing plant, it is doubtful they'll put in more fiber than necessary. Jack From stephen at sprunk.org Wed Aug 26 23:17:43 2009 From: stephen at sprunk.org (Stephen Sprunk) Date: Wed, 26 Aug 2009 23:17:43 -0500 Subject: FCCs RFC for the Definition of Broadband In-Reply-To: <4A95901D.6010402@brightok.net> References: <859604546CD1FF488BDB6EA94C896AFB8ABE40@racexchange.race.local> <3A89064E-4F43-4FFC-B535-B4D971CFDEF0@cisco.com> <4A9587B0.4080306@brightok.net> <314cf0830908261214j9d8552bnc57dbad692750f81@mail.gmail.com> <4A958CB7.1090300@gmail.com> <4A95901D.6010402@brightok.net> Message-ID: <4A9608E7.9090703@sprunk.org> Jack Bates wrote: > Roy wrote: >> The problem that the FCC faces is making a realistic definition that >> can apply to the whole US and not just cities. If I'm reading this question right, the issue is that Congress appropriated some pork for "rural broadband" and now it's up to the FCC to guess what Congress intended that to mean so they can determine which applicants will be allowed to feed at the public trough. I'd say that most laymen currently consider "broadband" to be an always-on service at 1Mb/s or faster, regardless of the particular technology used. FTTH sounds attractive, but there's just not enough pork to actually do it for a non-trivial number of rural homes; it's barely feasible for (sub)urban homes. FTTC is the only realistic option, with the last mile being either existing copper or existing coax. The "curb" has a slightly different meaning in a rural area, of course, but that doesn't need to be specified in the definition anyway. >> How does fiber (home or curb) figure in the rural sections of the >> country? > > It figures in nicely, thank you. Of course, our definition of curb > might be 1.5 miles further than your definition. ;) > > 2 miles is the cutoff for > 10mb/s reliability, but to deal with > future stuff, most of my telco customers have dropped it down to 1.5 > miles. My ILEC's techs claim they can run VDSL2 several miles but lose about 1Mb/s per 1000ft from the head end. Luckily I'm about 1500ft from mine, and my line tested out at ~58Mb/s -- though they'll only sell me 10Mb/s of that for data and 25Mb/s of it for TV. It's amazing how far we've come in the last two decades since I got my first 2400bps modem. If VDSL2 can't go far enough for rural areas and/or would require more remote units than is feasible, I'd say that ADSL is fast enough that it should also qualify. Supporting triple-play should not be a requirement, IMHO, as customers can always use DBS for TV and most people who claim to have "broadband" today don't have or can't get triple-play. I wouldn't go as far as accepting ISDN/IDSL, though, if anyone is even still selling that junk. 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: 3254 bytes Desc: S/MIME Cryptographic Signature URL: From mpalmer at hezmatt.org Wed Aug 26 15:14:30 2009 From: mpalmer at hezmatt.org (Matthew Palmer) Date: Thu, 27 Aug 2009 06:14:30 +1000 Subject: Data Center testing In-Reply-To: <017265BF3B9640499754DD48777C3D206612CC1D7E@MBX9.EXCHPROD.USA.NET> References: <1c2d53bb0908240600u1d9bbd48t38023b9900fc4f43@mail.gmail.com> <5b6f80200908240631q7f711db5m26a4f195c647aaeb@mail.gmail.com> <1c2d53bb0908240638t446b0d18tfc711960b84350fc@mail.gmail.com> <017265BF3B9640499754DD48777C3D206612CC1D7E@MBX9.EXCHPROD.USA.NET> Message-ID: <20090826201430.GW11576@hezmatt.org> On Wed, Aug 26, 2009 at 03:32:42PM +0000, Dylan Ebner wrote: > I always love it when I get an outage report from my ISP's or datacenter > and they say an "unexpected issue" or "unforseen issue" caused the > problem. Well, at least it's better than "yeah, we knew about it, but didn't think it was worth worrying about". - Matt From a.harrowell at gmail.com Thu Aug 27 03:58:22 2009 From: a.harrowell at gmail.com (Alexander Harrowell) Date: Thu, 27 Aug 2009 09:58:22 +0100 Subject: FCCs RFC for the Definition of Broadband In-Reply-To: <4A95B431.70102@enger.us> References: <4a9edb810908240917r15739868i93ae029165962e9c@mail.gmail.com> <4A95B431.70102@enger.us> Message-ID: <200908270958.46014.alexander.harrowell@stlpartners.com> On Wednesday 26 August 2009 23:16:17 Robert Enger - NANOG wrote: > As tedious as the downstream can be, engineering the upstream path of a > cable plant is worse. A lot of older systems were never designed for > upstream service. Even if the amps are retrofitted, the plant is just not > tight enough. Desirably, fiber should be pushed deeper; the quantity of > cascaded amps reduced, coax fittings and splitters replaced and so on. > > On 8/26/2009 10:25 AM, Richard Bennett wrote: > > The trouble with broadband in rural America is the twisted pair loop > > lengths that average around 20,000 feet. To use VDSL, the loop length > > needs to down around 3000, so they're stuck with ADSL unless the ILEC > > wants to install a lot of repeaters. And VDSL is the enabler of triple > > play over twisted pair. > > An interesting question: as the population gets sparser, the average trench mileage per subscriber increases. At some point this renders fibre deployment uneconomic. Now, this point can change: 1) as we deploy fibre we'll get more efficient at it - I think VZ's cost per sub has come down quite a lot since they started the FIOS rollout. 2) the flip side of the cost to serve a subscriber is of course revenue, and if you can find other services to sell'em you can go further. may also be scope for tiered pricing 3) public sector investment Going the other way, as the population gets denser, it becomes harder to provide an acceptable broadband wireless service because of spectrum limitations. You either need more and more cells (=more and more sites and more and more backhaul), or more and more spectrum. Where's the crossover point? There are clearly places where some fibre investment (like L(3)'s proposed deployment of many more POPs) would make it possible to get good service out using radio from the end of the fibre, precisely because they are sparse. There are clearly places where fibre to the home will eventually arrive. Is there a broadband gap between the two groups, however, where it's not dense enough to ever deploy fibre and too dense to deploy good wireless? Or can we rely on FTTH for one lot and RTTR (Radio to the Ranch) for the other? -------------- 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 simon at darkmere.gen.nz Thu Aug 27 05:15:25 2009 From: simon at darkmere.gen.nz (Simon Lyall) Date: Thu, 27 Aug 2009 22:15:25 +1200 (NZST) Subject: ADMIN: RE: MTAs used In-Reply-To: References: <14510.1251316871@turing-police.cc.vt.edu> Message-ID: Please note that this thread has been moderated as off-topic. The Mail operations email list http://www.mailop.org/ may be a more appropriate venue for the discussion. Simon NANOG MLC -- Simon Lyall | Very Busy | Web: http://www.darkmere.gen.nz/ "To stay awake all night adds a day to your life" - Stilgar | eMT. From drew.weaver at thenap.com Thu Aug 27 07:02:17 2009 From: drew.weaver at thenap.com (Drew Weaver) Date: Thu, 27 Aug 2009 08:02:17 -0400 Subject: Avaya (or other folks) who work with the CNA/APC (route reflector) Message-ID: Hi, All of my contacts within Avaya who work with the CNA/APC system have seemingly vanished, does anyone on the list have any contacts in Avaya which still know about the existence of this product? Also, does anyone have any contact information for someone at Internap who has sales information about the FCP product? thanks, -Drew From brunner at nic-naa.net Thu Aug 27 07:48:36 2009 From: brunner at nic-naa.net (Eric Brunner-Williams) Date: Thu, 27 Aug 2009 08:48:36 -0400 Subject: FCCs RFC for the Definition of Broadband In-Reply-To: <3A89064E-4F43-4FFC-B535-B4D971CFDEF0@cisco.com> References: <859604546CD1FF488BDB6EA94C896AFB8ABE40@racexchange.race.local> <3A89064E-4F43-4FFC-B535-B4D971CFDEF0@cisco.com> Message-ID: <4A9680A4.20808@nic-naa.net> Fred, I picked Aroostook, Washington, and Lincoln counties for a 4g wireless with backhaul infrastructure proposal. A wireline infrastructure proposal for these counties (BIP) would, for some arbitrary amount of capital expense, serve some of the population in towns, but leave the non-in-town populations with no change in infrastructure. I thought about adding a western (mountainous) county to the mix, but for a proof-of-concept those three are representative of most of rural Maine. All qualify as "rural remote", being more than 50 miles from a city of 20,000, or a suburban area of 50,000 (USDA RUS definition of "rural remote"). Not many of either of those in Maine anyway. As I wrote yesterday, "triple play" simply hasn't sold "broadband" (source: USDA stats and Maine ISP experience), therefore uptake and post-stimulus subscriber retention are wicked important. The BTOP vehicle provides two additional non-infrastructure grant opportunities, for "public computer centers" and for "sustainable broadband adoption", so as I wrote those I attempted to make best use of link properties and to-the-centers (not home, or curb) and whatever "sustainable" might mean and the available statutory purposes and therefore services above link to propose something innovative. My guess (its in my proposal so I guess its my proposal writing money bet) is that "rural broadband" means something other than IPv4 DHCP provisioned, fat but flaky pipes allowing access to asymmetric content. That works in the suburban and urban markets, but its failed, according to the USDA and my Maine ISP competitors, in rural USA and Maine. While I share (other hat, we signed our first zone last year and our second zone will be signed this year) the "suggesting special favors for deployment of DNSSEC" discussion with myself, I think this misses the gambled mandatory-to-implement-feature (see "gamble", above) of locality. {Packet|Connection} users in rural areas have some requirement more pressing than parity of access to the service model that meets the requirements of non-rural {Packet|Connection} users. Eric Fred Baker wrote: > If it's about stimulus money, I'm in favor of saying that broadband > implies fiber to the home. That would provide all sorts of stimuli to > the economy - infrastructure, equipment sales, jobs digging ditches, > and so on. I could pretty quickly argue myself into suggesting special > favors for deployment of DNSSEC, multicast, and IPv6. As in, use the > stimulus money to propel a leap forward, not just waste it. > > On Aug 26, 2009, at 9:44 AM, Carlos Alcantar wrote: > >> I think the big push to get the fcc to define broadband is highly based >> on the rus/ntia setting definitions of what broadband is. If any anyone >> has been fallowing the rus/ntia they are the one handing out all the >> stimulus infrastructure grant loan money. So there are a lot of >> political reasons to make the definition of broadband a bit slower than >> one would think. I guess it doesn't hurt that the larger lec's with the >> older infrastructure are shelling out the money to lobby to make sure >> the definition stays as low as can be. They don't want to see the gov >> funding there competition. Just my 2 cents. >> >> -carlos >> >> -----Original Message----- >> From: Ted Fischer [mailto:ted at fred.net] >> Sent: Wednesday, August 26, 2009 8:50 AM >> To: nanog at nanog.org >> Subject: Re: FCCs RFC for the Definition of Broadband >> >> >> >> Paul Timmins wrote: >>> Fred Baker wrote: >>>> >>>> On Aug 24, 2009, at 9:17 AM, Luke Marrott wrote: >>>> >>>>> What are your thoughts on what the definition of Broadband should be >> >>>>> going >>>>> forward? I would assume this will be the standard definition for a >>>>> number of >>>>> years to come. >>>> >>>> >>>> Historically, narrowband was circuit switched (ISDN etc) and >> broadband >>>> was packet switched. Narrowband was therefore tied to the digital >>>> signaling hierarchy and was in some way a multiple of 64 KBPS. As the >> >>>> term was used then, broadband delivery options of course included >>>> virtual circuits bearing packets, like Frame Relay and ATM. >>> of or relating to or being a communications network in which the >>> bandwidth can be divided and shared by multiple simultaneous signals >> (as >>> for voice or data or video) >>> >>> That's my humble opinion. Let them use a new term, like "High Speed >>> Internet". >>> >>> >> Seconded >> >> >> > > > > From chris at uplogon.com Thu Aug 27 08:09:14 2009 From: chris at uplogon.com (Chris Gotstein) Date: Thu, 27 Aug 2009 08:09:14 -0500 Subject: Qwest IPv6 In-Reply-To: <4A95FFB8.2000000@qis.net> References: <4A95FFB8.2000000@qis.net> Message-ID: <4A96857A.5030703@uplogon.com> Qwest is still beta testing IPv6. We turned ours up last week and were one of the first to do so. I can go through my notes and email you the contact info of the people that are working on that. Kevin Brown wrote: > > Does anyone have a contact at Qwest who can help us get the ball rolling > to implement an exchange of IPv6 traffic? Their NOC referred us back to > our account manager, who said "We don't do IPv6". A quick Google search > would seem to indicate otherwise... > > Thanks! > -- Chris Gotstein Sr Network Engineer UP Logon/Computer Connection UP 500 N Stephenson Ave Iron Mountain, MI 49801 Phone: 906-774-4847 Fax: 906-774-0335 chris at uplogon.com From bicknell at ufp.org Thu Aug 27 09:04:59 2009 From: bicknell at ufp.org (Leo Bicknell) Date: Thu, 27 Aug 2009 10:04:59 -0400 Subject: FCCs RFC for the Definition of Broadband In-Reply-To: <200908270958.46014.alexander.harrowell@stlpartners.com> References: <4a9edb810908240917r15739868i93ae029165962e9c@mail.gmail.com> <4A95B431.70102@enger.us> <200908270958.46014.alexander.harrowell@stlpartners.com> Message-ID: <20090827140459.GA64392@ussenterprise.ufp.org> In a message written on Thu, Aug 27, 2009 at 09:58:22AM +0100, Alexander Harrowell wrote: > An interesting question: as the population gets sparser, the average trench > mileage per subscriber increases. At some point this renders fibre deployment > uneconomic. Now, this point can change: This statement makes no sense to me. The cost to dig a trench is cheaper in rural areas than it is in urban areas. A lot cheaper. Rather than closing a road, cutting a trench, avoiding 900 other obsticals, repaving, etc they can often trench or go aerial down the side of a road for miles with no obsticals and nothing but grass to put back. So while mileage per subscriber increases, cost per mile dramatically increases. The only advantage in an urban enviornment is that one trench may serve 200 families in a building, where as a rural trench may serve 20 familes. But more puzzling to me is the idea that fiber becomes uneconomic. This may have once been true, but right now you can buy 10km or even 40km lasers quite cheaply. Compare with copper which for even modest speeds requires a repeater every 2-4km. If you have to reach someone 20km from the CO, the cost of running the ditch-wich down the road in a rural area is not the dominate cost over the next 20 years. It's equipment. If the copper plant takes 4 repeaters to do the job, that's 4 bits of equipment that can fail, and will need to be upgraded at some point. Running something as simple as point to point fiber they can be provided with GigE speeds today with no intermediate equipment; the cost of a 20km GBIC is far less than the cost of installing 4 repeaters. The problem with all of these is ROI, not cost. Somewhere along the line we've decided very short ROI's are required. Do you work at a company where an ROI of over a year is laughed at? When the original rural telephone network was pushed ROI's of 50 years were talked about. There's plenty of infrastructure built every day with ROI's of 20 years. So it would cost $2000 per home to put in fiber. The margin on the service is $5 per month. It's a 33 year ROI. That's ok with me, it's infrastructure, like a road, or a bridge. We're still using copper in the ground put in during the 60's, 70's, and 80's. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 825 bytes Desc: not available URL: From tme at americafree.tv Thu Aug 27 09:27:52 2009 From: tme at americafree.tv (Marshall Eubanks) Date: Thu, 27 Aug 2009 10:27:52 -0400 Subject: FCCs RFC for the Definition of Broadband In-Reply-To: <20090827140459.GA64392@ussenterprise.ufp.org> References: <4a9edb810908240917r15739868i93ae029165962e9c@mail.gmail.com> <4A95B431.70102@enger.us> <200908270958.46014.alexander.harrowell@stlpartners.com> <20090827140459.GA64392@ussenterprise.ufp.org> Message-ID: <8657BCF0-09C1-4F4C-8E67-90BCD16C8E49@americafree.tv> On Aug 27, 2009, at 10:04 AM, Leo Bicknell wrote: > In a message written on Thu, Aug 27, 2009 at 09:58:22AM +0100, > Alexander Harrowell wrote: >> An interesting question: as the population gets sparser, the >> average trench >> mileage per subscriber increases. At some point this renders fibre >> deployment >> uneconomic. Now, this point can change: > > This statement makes no sense to me. > > The cost to dig a trench is cheaper in rural areas than it is in > urban areas. A lot cheaper. Rather than closing a road, cutting > a trench, avoiding 900 other obsticals, repaving, etc they can often > trench or go aerial down the side of a road for miles with no > obsticals and nothing but grass to put back. > > So while mileage per subscriber increases, cost per mile dramatically > increases. I think you meant, "decreases", here. Marshall > The only advantage in an urban enviornment is that one > trench may serve 200 families in a building, where as a rural trench > may serve 20 familes. > > But more puzzling to me is the idea that fiber becomes uneconomic. > This may have once been true, but right now you can buy 10km or > even 40km lasers quite cheaply. Compare with copper which for even > modest speeds requires a repeater every 2-4km. > > If you have to reach someone 20km from the CO, the cost of running > the ditch-wich down the road in a rural area is not the dominate > cost over the next 20 years. It's equipment. If the copper plant > takes 4 repeaters to do the job, that's 4 bits of equipment that > can fail, and will need to be upgraded at some point. Running > something as simple as point to point fiber they can be provided > with GigE speeds today with no intermediate equipment; the cost of > a 20km GBIC is far less than the cost of installing 4 repeaters. > > The problem with all of these is ROI, not cost. Somewhere along the > line we've decided very short ROI's are required. Do you work at a > company where an ROI of over a year is laughed at? When the original > rural telephone network was pushed ROI's of 50 years were talked > about. > There's plenty of infrastructure built every day with ROI's of 20 > years. > > So it would cost $2000 per home to put in fiber. The margin on the > service is $5 per month. It's a 33 year ROI. That's ok with me, it's > infrastructure, like a road, or a bridge. We're still using copper in > the ground put in during the 60's, 70's, and 80's. > > -- > Leo Bicknell - bicknell at ufp.org - CCIE 3440 > PGP keys at http://www.ufp.org/~bicknell/ From cmadams at hiwaay.net Thu Aug 27 09:41:22 2009 From: cmadams at hiwaay.net (Chris Adams) Date: Thu, 27 Aug 2009 09:41:22 -0500 Subject: Qwest IPv6 In-Reply-To: <4A95FFB8.2000000@qis.net> References: <4A95FFB8.2000000@qis.net> Message-ID: <20090827144122.GE1464872@hiwaay.net> Once upon a time, Kevin Brown said: > Does anyone have a contact at Qwest who can help us get the ball rolling > to implement an exchange of IPv6 traffic? Their NOC referred us back to > our account manager, who said "We don't do IPv6". A quick Google search > would seem to indicate otherwise... When I asked a few months ago, the NOC gave me the "we don't do IPv6" answer. Looking at BGP, I only see AS 209 behind HE (with 1 prefix and 2 transit prefixes), so I would guess that's still basically the case. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From paul at telcodata.us Thu Aug 27 09:47:01 2009 From: paul at telcodata.us (Paul Timmins) Date: Thu, 27 Aug 2009 10:47:01 -0400 Subject: FCCs RFC for the Definition of Broadband In-Reply-To: <20090827140459.GA64392@ussenterprise.ufp.org> References: <4a9edb810908240917r15739868i93ae029165962e9c@mail.gmail.com> <4A95B431.70102@enger.us> <200908270958.46014.alexander.harrowell@stlpartners.com> <20090827140459.GA64392@ussenterprise.ufp.org> Message-ID: <4A969C65.8040506@telcodata.us> Leo Bicknell wrote: > If you have to reach someone 20km from the CO, the cost of running > the ditch-wich down the road in a rural area is not the dominate > cost over the next 20 years. It's equipment. If the copper plant > takes 4 repeaters to do the job, that's 4 bits of equipment that > can fail, and will need to be upgraded at some point. Running > something as simple as point to point fiber they can be provided > with GigE speeds today with no intermediate equipment; the cost of > a 20km GBIC is far less than the cost of installing 4 repeaters. > > The problem with all of these is ROI, not cost. Somewhere along the > line we've decided very short ROI's are required. Do you work at a > company where an ROI of over a year is laughed at? When the original > rural telephone network was pushed ROI's of 50 years were talked about. > There's plenty of infrastructure built every day with ROI's of 20 years. > > So it would cost $2000 per home to put in fiber. The margin on the > service is $5 per month. It's a 33 year ROI. That's ok with me, it's > infrastructure, like a road, or a bridge. We're still using copper in > the ground put in during the 60's, 70's, and 80's > Seems like a good idea to the technical side of me, but the business side sees a problem: that the employees like to eat in the 33 year span wherein the company isn't making a dime on its customers. -Paul From cmadams at hiwaay.net Thu Aug 27 09:52:52 2009 From: cmadams at hiwaay.net (Chris Adams) Date: Thu, 27 Aug 2009 09:52:52 -0500 Subject: FCCs RFC for the Definition of Broadband In-Reply-To: <20090827140459.GA64392@ussenterprise.ufp.org> References: <4a9edb810908240917r15739868i93ae029165962e9c@mail.gmail.com> <4A95B431.70102@enger.us> <200908270958.46014.alexander.harrowell@stlpartners.com> <20090827140459.GA64392@ussenterprise.ufp.org> Message-ID: <20090827145252.GF1464872@hiwaay.net> Once upon a time, Leo Bicknell said: > When the original > rural telephone network was pushed ROI's of 50 years were talked about. > There's plenty of infrastructure built every day with ROI's of 20 years. How much of that was built in the last 15 years though (where now it needs to be replaced before it has been paid for)? In the 1990s, BellSouth pushed hard here, rolled out fiber to the neighborhoods, and deployed ISDN-capable equipment everywhere. ISDN was available at every single address in town by around 1995 (allegedly we were one of if not the first moderate-sized city with ISDN everywhere). Then it turned out ISDN was a flop, and DSL came along, which wouldn't run over that nice big fiber plant. They had to start rolling out remote DSLAMs all over town. Shortly after they had most of the city covered, ADSL2 came along, and they had to start upgrading again. Granted, the cable plant (whether copper, fiber, coax, or avian datagram) is not quite the same, but the bean-counters look at it as "we were supposed to have -year ROI on project 1, 2, and 3, and we didn't get it; why should I believe we'll get it on project 4?". -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From bicknell at ufp.org Thu Aug 27 09:58:00 2009 From: bicknell at ufp.org (Leo Bicknell) Date: Thu, 27 Aug 2009 10:58:00 -0400 Subject: FCCs RFC for the Definition of Broadband In-Reply-To: <4A969C65.8040506@telcodata.us> References: <4a9edb810908240917r15739868i93ae029165962e9c@mail.gmail.com> <4A95B431.70102@enger.us> <200908270958.46014.alexander.harrowell@stlpartners.com> <20090827140459.GA64392@ussenterprise.ufp.org> <4A969C65.8040506@telcodata.us> Message-ID: <20090827145800.GA67840@ussenterprise.ufp.org> In a message written on Thu, Aug 27, 2009 at 10:47:01AM -0400, Paul Timmins wrote: > Seems like a good idea to the technical side of me, but the business > side sees a problem: that the employees like to eat in the 33 year span > wherein the company isn't making a dime on its customers. The last letter of ROI is Investment. When Ford decides to build a new car it sinks in billions of dollars over a 5 year period where it makes nothing. It then starts selling the new model, and finally reaches a point where it makes a profit, and uses that to find the next Investment. What Telecom companies have done is confused infrastructure and equipment. It would be stupid to plan on making a profit on your GSR over 30 years, after 10 it will be functionally obsolete. When it comes to equipment the idea of 1-3 year ROI's makes sense. However, when it comes to fiber or copper in the ground or on a pole it has a 20, 30, 40, or even 50 year life span. To require those assets to have a 1-3 year ROI is absurd. I remember when Cable TV was "new". I lived in a neighborhood without it, and the men with ditch wiches came through and wired the entire neighborhood. I don't think it had an ROI of a year, or even 5, but it has now, 30 years later, spawned a multi-billion dollar industry and allowed us to have things like Cable Internet, which weren't even invented at the time. Someone loaned them the money to do it, and it appears to me the investment performed well, overall. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 825 bytes Desc: not available URL: From jbates at brightok.net Thu Aug 27 09:57:56 2009 From: jbates at brightok.net (Jack Bates) Date: Thu, 27 Aug 2009 09:57:56 -0500 Subject: FCCs RFC for the Definition of Broadband In-Reply-To: <20090827140459.GA64392@ussenterprise.ufp.org> References: <4a9edb810908240917r15739868i93ae029165962e9c@mail.gmail.com> <4A95B431.70102@enger.us> <200908270958.46014.alexander.harrowell@stlpartners.com> <20090827140459.GA64392@ussenterprise.ufp.org> Message-ID: <4A969EF4.8020708@brightok.net> Leo Bicknell wrote: > So while mileage per subscriber increases, cost per mile dramatically > increases. The only advantage in an urban enviornment is that one > trench may serve 200 families in a building, where as a rural trench > may serve 20 familes. Cost per subscriber is the only cost that matters. That is what defines your recoup time and profit margins. BTW, in many cases it's actually cheaper to bore the entire way then intermix boring and trenching. And out here, they are heavily against you trenching right through someone's driveway or a road. Then there's the rivers and creeks. > But more puzzling to me is the idea that fiber becomes uneconomic. > This may have once been true, but right now you can buy 10km or > even 40km lasers quite cheaply. Compare with copper which for even > modest speeds requires a repeater every 2-4km. Maintenance. The reason rural companies prefer active equipment in the plant is because of maintenance. 20 splices to restore service to 20 customers vs 1 splice to restore service to 20 customers. This is oversimplified, in reality, many of the FTTH comments in this thread imply bringing all customers back to the CO to keep active equipment out of the plant. This will tend to imply large fiber bundles leaving the CO and breaking down smaller and smaller as you get further from the CO. A large fiber cut may mean 128+ splices to restore service at 1 splice per customer. In addition, it throws away all the money and investment of plant already in the ground from key points to the customers. I haven't seen an installation running repeaters for copper. More common is a remote system fed by a fiber ring (so when the 20km fiber is cut, service isn't lost while repairs are done) and the last 1.5 miles fed by copper which is already there. > with GigE speeds today with no intermediate equipment; the cost of > a 20km GBIC is far less than the cost of installing 4 repeaters. > If someone is setting up like this, I'd agree. More common: Traditional POTS was often served off double ended carrier and load coils, which later became fiber fed integrated carrier with gr303 and load coils. Cheapest solution, replace carrier with DSL capable carrier, remove load coils when not necessary and extend from there for closer carriers where applicable (shorten copper loops, and removal of more load coils). Here locally, we dropped over 90% of our load peds. Only the furthest reaches still have them and of course cannot get DSL. > There's plenty of infrastructure built every day with ROI's of 20 years. Hope they have disaster insurance. A good tornado or wildfire (or backhoe) can do some serious damage. I had both this year in Lone Grove. Fun. Fun. Fiber rings to remote field equipment still gives the best redundancy and maintenance cost (as there is less to splice over the longhaul to the remote system). > service is $5 per month. It's a 33 year ROI. That's ok with me, it's > infrastructure, like a road, or a bridge. We're still using copper in > the ground put in during the 60's, 70's, and 80's. You bet. We're also using fiber and copper put in the ground yesterday. Copper is amazingly resilient. Most of the copper that has to be replaced is old aircore in the ground (which is why aircore shouldn't be in the ground, as it collects water and leads to shorts over long distances) or rehab of aircore in aerial due to bad boots that weren't maintained. The switch to fiber fed remote systems abandoned most of the problematic copper, though. Jack From xaerni at pop.ch Thu Aug 27 10:08:16 2009 From: xaerni at pop.ch (Xaver Aerni) Date: Thu, 27 Aug 2009 17:08:16 +0200 Subject: FCCs RFC for the Definition of Broadband References: <4a9edb810908240917r15739868i93ae029165962e9c@mail.gmail.com> <4A95B431.70102@enger.us><200908270958.46014.alexander.harrowell@stlpartners.com><20090827140459.GA64392@ussenterprise.ufp.org> <20090827145252.GF1464872@hiwaay.net> Message-ID: ----- Original Message ----- From: "Chris Adams" To: Sent: Thursday, August 27, 2009 4:52 PM Subject: Re: FCCs RFC for the Definition of Broadband > Once upon a time, Leo Bicknell said: >> When the original >> rural telephone network was pushed ROI's of 50 years were talked about. >> There's plenty of infrastructure built every day with ROI's of 20 years. > > How much of that was built in the last 15 years though (where now it > needs to be replaced before it has been paid for)? In the 1990s, > BellSouth pushed hard here, rolled out fiber to the neighborhoods, and > deployed ISDN-capable equipment everywhere. ISDN was available at every > single address in town by around 1995 (allegedly we were one of if not > the first moderate-sized city with ISDN everywhere). > > Then it turned out ISDN was a flop, and DSL came along, which wouldn't > run over that nice big fiber plant. They had to start rolling out > remote DSLAMs all over town. Shortly after they had most of the city > covered, ADSL2 came along, and they had to start upgrading again. > I don't think ISDN was a flop. In the middle of the 90 years. The most KMU and bigger Companies have ISDN. At home it was at 1997 a trend two with Internet. Ok in Europe we haven't till begin of the 2000 no Clip Informations on a analoge line. This will be come to begin of the 2000. With ADSL and Clipinformations has the most people at home chanched back to an analog Line. For the companies is ISDN allready a must. You must see. At the End of the last century the most people has a phone, has a fax, has a Modem... The best way was ISDN. Now The childern are skypeing... or take an other IP Fon. Fax doesn't exist at home. The people has E-Mail. And Internet we have on ADSL or VDSL. with many speed. For phoneing 2/3 of the people take the handy (celuar phone) or IP fon. I think this is the bigest part in the last 10 years. Greetings Xaver From bicknell at ufp.org Thu Aug 27 10:10:43 2009 From: bicknell at ufp.org (Leo Bicknell) Date: Thu, 27 Aug 2009 11:10:43 -0400 Subject: FCCs RFC for the Definition of Broadband In-Reply-To: <4A969EF4.8020708@brightok.net> References: <4a9edb810908240917r15739868i93ae029165962e9c@mail.gmail.com> <4A95B431.70102@enger.us> <200908270958.46014.alexander.harrowell@stlpartners.com> <20090827140459.GA64392@ussenterprise.ufp.org> <4A969EF4.8020708@brightok.net> Message-ID: <20090827151043.GC67840@ussenterprise.ufp.org> In a message written on Thu, Aug 27, 2009 at 09:57:56AM -0500, Jack Bates wrote: > oversimplified, in reality, many of the FTTH comments in this thread > imply bringing all customers back to the CO to keep active equipment out > of the plant. This will tend to imply large fiber bundles leaving the CO > and breaking down smaller and smaller as you get further from the CO. A > large fiber cut may mean 128+ splices to restore service at 1 splice per > customer. The interesting technology here of course is split optical networks. A single fiber from the CO to a remote splice box, split to 10-100 customers. I'm not really up on this technology, but my understanding is that development is rapid in this space. > Hope they have disaster insurance. A good tornado or wildfire (or > backhoe) can do some serious damage. I had both this year in Lone Grove. > Fun. Fun. Fiber rings to remote field equipment still gives the best > redundancy and maintenance cost (as there is less to splice over the > longhaul to the remote system). I hate to say it, but this was an advantage to "Ma Bell". Insurance is about spreading risk out over many participants. An alternative strategy is to pool everything into one company! :) My perception is that the rural telecom market is fragmented by many smaller players, which amplifies this problem. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 825 bytes Desc: not available URL: From jbates at brightok.net Thu Aug 27 10:20:00 2009 From: jbates at brightok.net (Jack Bates) Date: Thu, 27 Aug 2009 10:20:00 -0500 Subject: FCCs RFC for the Definition of Broadband In-Reply-To: <20090827151043.GC67840@ussenterprise.ufp.org> References: <4a9edb810908240917r15739868i93ae029165962e9c@mail.gmail.com> <4A95B431.70102@enger.us> <200908270958.46014.alexander.harrowell@stlpartners.com> <20090827140459.GA64392@ussenterprise.ufp.org> <4A969EF4.8020708@brightok.net> <20090827151043.GC67840@ussenterprise.ufp.org> Message-ID: <4A96A420.7010403@brightok.net> Leo Bicknell wrote: > My perception is that the rural telecom market is fragmented by many > smaller players, which amplifies this problem. > I have 12 ILEC and 1 CLEC under my umbrella. I can guarantee that not a single one is the same at the plant, equipment, or business level. That being said, I think we are luckier than Bell, who has only a few dozen concentrated CO's in the state which feed the smaller CO's, or in some cases, entire towns are fed by double ended carrier (where 14.4 is considered the best connection one can hope for). We see unlicensed wireless in a lot of these places, but their customers honestly beg for better service. Jack From a.harrowell at gmail.com Thu Aug 27 10:22:18 2009 From: a.harrowell at gmail.com (Alexander Harrowell) Date: Thu, 27 Aug 2009 16:22:18 +0100 Subject: FCCs RFC for the Definition of Broadband In-Reply-To: <20090827140459.GA64392@ussenterprise.ufp.org> References: <4a9edb810908240917r15739868i93ae029165962e9c@mail.gmail.com> <200908270958.46014.alexander.harrowell@stlpartners.com> <20090827140459.GA64392@ussenterprise.ufp.org> Message-ID: <200908271622.33293.a.harrowell@gmail.com> On Thursday 27 August 2009 15:04:59 Leo Bicknell wrote: > In a message written on Thu, Aug 27, 2009 at 09:58:22AM +0100, Alexander Harrowell wrote: > > An interesting question: as the population gets sparser, the average > > trench mileage per subscriber increases. At some point this renders fibre > > deployment uneconomic. Now, this point can change: > > This statement makes no sense to me. > > The cost to dig a trench is cheaper in rural areas than it is in > urban areas. A lot cheaper. Rather than closing a road, cutting > a trench, avoiding 900 other obsticals, repaving, etc they can often > trench or go aerial down the side of a road for miles with no > obsticals and nothing but grass to put back. > > So while mileage per subscriber increases, cost per mile dramatically > increases. The only advantage in an urban enviornment is that one > trench may serve 200 families in a building, where as a rural trench > may serve 20 familes. > > But more puzzling to me is the idea that fiber becomes uneconomic. > This may have once been true, but right now you can buy 10km or > even 40km lasers quite cheaply. Compare with copper which for even > modest speeds requires a repeater every 2-4km. > True. But there is - there has to be - a limit, when the 70% or so civil works cost eats everything else. The limit may be more or less restrictive, but limit there is. -------------- 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 mike at m5computersecurity.com Thu Aug 27 11:13:36 2009 From: mike at m5computersecurity.com (Michael J McCafferty) Date: Thu, 27 Aug 2009 09:13:36 -0700 Subject: Avaya (or other folks) who work with the CNA/APC (route reflector) In-Reply-To: References: Message-ID: <1251389616.24442.109.camel@mike-desktop> Coincidentally, just this morning someone at InterNAP forwarded me a statement from Avaya that they announced End of Sale on the CNA and Adaptive Path Controller as of Nov 2 2009, and End of Support as of Nov 2 2010. I'll forward you the InterNAP guy's info off-list. On Thu, 2009-08-27 at 08:02 -0400, Drew Weaver wrote: > Hi, > > All of my contacts within Avaya who work with the CNA/APC system have seemingly vanished, does anyone on the list have any contacts in Avaya which still know about the existence of this product? > > Also, does anyone have any contact information for someone at Internap who has sales information about the FCP product? > > thanks, > -Drew > -- ************************************************************ Michael J. McCafferty Principal, Security Engineer M5 Hosting http://www.m5hosting.com You can have your own custom Dedicated Server up and running today ! RedHat Enterprise, CentOS, Ubuntu, Debian, OpenBSD, FreeBSD, and more ************************************************************ From frnkblk at iname.com Thu Aug 27 20:26:53 2009 From: frnkblk at iname.com (Frank Bulk - iName.com) Date: Thu, 27 Aug 2009 20:26:53 -0500 Subject: FCCs RFC for the Definition of Broadband In-Reply-To: <3c3e3fca0908261445y77533dbcscd7945aac532e78d@mail.gmail.com> References: <4a9edb810908240917r15739868i93ae029165962e9c@mail.gmail.com> <41A99CED-7857-4E24-B536-31493DE2EB99@cisco.com> <3c3e3fca0908261445y77533dbcscd7945aac532e78d@mail.gmail.com> Message-ID: As one of the workshops discussed, does the definition of "underserved" and "unserved" include the clause "for a reasonable price"? If the price is unreasonable, do you think its government money well-spent to subsidize bringing a competitor to a market that couldn't make it before? Or are there perhaps other ways to deal with that pricing issue? Frank -----Original Message----- From: William Herrin [mailto:herrin-nanog at dirtside.com] Sent: Wednesday, August 26, 2009 4:46 PM To: Fred Baker Cc: nanog at nanog.org Subject: Re: FCCs RFC for the Definition of Broadband Really where they need the swift kick in the tail is in the product tying where you can't buy a high speed connection to J. Random ISP, you can only buy a high speed connection to monopoly provider's in-house ISP. Which means you can only get commodity service since monopoly provider isn't in the business of providing low-dollar custom solutions. But it sounds like that's outside the scope of what Congress has approved. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From frnkblk at iname.com Thu Aug 27 20:35:57 2009 From: frnkblk at iname.com (Frank Bulk - iName.com) Date: Thu, 27 Aug 2009 20:35:57 -0500 Subject: FCCs RFC for the Definition of Broadband In-Reply-To: <200908262219150.2D3A1E03.27432@clifden.donelan.com> References: <859604546CD1FF488BDB6EA94C896AFB8ABE40@racexchange.race.local> <3A89064E-4F43-4FFC-B535-B4D971CFDEF0@cisco.com> <200908262219150.2D3A1E03.27432@clifden.donelan.com> Message-ID: Estimates to bring FTTH to all of America is in the $100 to $300B range. So yes, the $7.2B is a drop in the bucket. Frank -----Original Message----- From: Sean Donelan [mailto:sean at donelan.com] Sent: Wednesday, August 26, 2009 9:53 PM To: nanog at nanog.org Subject: Re: FCCs RFC for the Definition of Broadband On Wed, 26 Aug 2009, Fred Baker wrote: > If it's about stimulus money, I'm in favor of saying that broadband implies > fiber to the home. That would provide all sorts of stimuli to the economy - > infrastructure, equipment sales, jobs digging ditches, and so on. I could > pretty quickly argue myself into suggesting special favors for deployment of > DNSSEC, multicast, and IPv6. As in, use the stimulus money to propel a leap > forward, not just waste it. Broadband stimulus money = $7,200,000,000 Housing units in USA (2000) = 115,904,641 Stimulus money per housing unit = $62.12 one-time What definition of "broadband" can you achieve for that amount of money? Or for rural housing units (2000) = 25,938,698 Stimulus money per rural housing unit = $277.58 one-time What definition of "broadband" can you achieve for that amount of money in a rural build-out? How much will fiber to the home cost in a rural area? From richard at bennett.com Thu Aug 27 22:11:50 2009 From: richard at bennett.com (Richard Bennett) Date: Thu, 27 Aug 2009 20:11:50 -0700 Subject: FCCs RFC for the Definition of Broadband In-Reply-To: References: <4a9edb810908240917r15739868i93ae029165962e9c@mail.gmail.com> <41A99CED-7857-4E24-B536-31493DE2EB99@cisco.com> <3c3e3fca0908261445y77533dbcscd7945aac532e78d@mail.gmail.com> Message-ID: <4A974AF6.6090006@bennett.com> The background issue is whether satellite-based systems at around 200 Kb/s and high latency can be defined as "broadband." Since everyone in America - including the Alaskans - has access to satellite services, defining that level of service as broadband makes the rest of the exercise academic: everyone is "served." There's no economic argument for government subsidies to multiple firms in a market, of course. It's more interesting considering that DirecTV is about to launch a new satellite with a couple orders of magnitude more capacity than the existing ones offer. I seem to recall their claiming that the service would then improved to some respectable number of megabits/sec. Satellite ISPs locate their ground stations in IXP-friendly locations, so there aren't any worries about backhaul or fiber access costs. But to your actual question, "under-served" is of course quite subjective and cost is clearly part of it. RB Frank Bulk - iName.com wrote: > As one of the workshops discussed, does the definition of "underserved" and > "unserved" include the clause "for a reasonable price"? > > If the price is unreasonable, do you think its government money well-spent > to subsidize bringing a competitor to a market that couldn't make it before? > Or are there perhaps other ways to deal with that pricing issue? > > Frank > > -----Original Message----- > From: William Herrin [mailto:herrin-nanog at dirtside.com] > Sent: Wednesday, August 26, 2009 4:46 PM > To: Fred Baker > Cc: nanog at nanog.org > Subject: Re: FCCs RFC for the Definition of Broadband > > > > Really where they need the swift kick in the tail is in the product > tying where you can't buy a high speed connection to J. Random ISP, > you can only buy a high speed connection to monopoly provider's > in-house ISP. Which means you can only get commodity service since > monopoly provider isn't in the business of providing low-dollar custom > solutions. But it sounds like that's outside the scope of what > Congress has approved. > > Regards, > Bill Herrin > > -- Richard Bennett Research Fellow Information Technology and Innovation Foundation Washington, DC From jcdill.lists at gmail.com Thu Aug 27 23:50:47 2009 From: jcdill.lists at gmail.com (JC Dill) Date: Thu, 27 Aug 2009 21:50:47 -0700 Subject: FCCs RFC for the Definition of Broadband In-Reply-To: <20090827145800.GA67840@ussenterprise.ufp.org> References: <4a9edb810908240917r15739868i93ae029165962e9c@mail.gmail.com> <4A95B431.70102@enger.us> <200908270958.46014.alexander.harrowell@stlpartners.com> <20090827140459.GA64392@ussenterprise.ufp.org> <4A969C65.8040506@telcodata.us> <20090827145800.GA67840@ussenterprise.ufp.org> Message-ID: <4A976227.8080008@gmail.com> Leo Bicknell wrote: > What Telecom companies have done is confused infrastructure and > equipment. It would be stupid to plan on making a profit on your > GSR over 30 years, after 10 it will be functionally obsolete. When > it comes to equipment the idea of 1-3 year ROI's makes sense. > However, when it comes to fiber or copper in the ground or on a > pole it has a 20, 30, 40, or even 50 year life span. To require > those assets to have a 1-3 year ROI is absurd. What happens if we have improvements in data transmission systems such that whatever we put in now is obsolete in 15 years? What happens if we put in billions of dollars of fiber, only to have fiber (and copper) obsolete as we roll out faster and faster wireless solutions? IMHO the biggest obstacle to defining broadband is figuring out how to describe how it is used in a way that prevents an ILEC from installing it so that only the ILEC can use it. If the customer doesn't have at least 3 broadband choices, there's no real choice, and pricing will be artificially high and service options will be stagnant and few. Look at what happened to long distance rates and telephone services once Ma Bell was broken up and businesses started competing for customers. I remember when we paid more than $35 a month for long distance fees alone (and about that much more for our basic service, including phone "rental") when I was a teenager in the 1970s. Without competition, with inflation, that same long distance bill would easily be over $100/month today. Yest today, more than 30 years later you can get a cell phone with unlimited minutes, unlimited domestic long distance, for $35/month (e.g Metro PCS). Let's not make this mistake again and let the ILECs use TARP funds to build "broadband" to the curb/home that only they get to use to provide internet services to the customers. jc From carlos at race.com Fri Aug 28 00:00:44 2009 From: carlos at race.com (Carlos Alcantar) Date: Thu, 27 Aug 2009 22:00:44 -0700 Subject: FCCs RFC for the Definition of Broadband Message-ID: <859604546CD1FF488BDB6EA94C896AFB8ABEDC@racexchange.race.local> That's why I believe all the major lecs are refusing to submit for funds due to all the red tape that comes with that money. Eg. (Nondiscrimination and interconnection obligation) they are really pushing network openness something I don't think the lecs want to do with their fiber plant. Carlos Alcantar Race Telecommunications, Inc. 101 Haskins Way South San Francisco, CA 94080 P: 650.649.3550 x143 F: 650.649.3551 -----Original Message----- From: JC Dill [mailto:jcdill.lists at gmail.com] Sent: Thursday, August 27, 2009 9:51 PM To: NANOG list Subject: Re: FCCs RFC for the Definition of Broadband Leo Bicknell wrote: > What Telecom companies have done is confused infrastructure and > equipment. It would be stupid to plan on making a profit on your > GSR over 30 years, after 10 it will be functionally obsolete. When > it comes to equipment the idea of 1-3 year ROI's makes sense. > However, when it comes to fiber or copper in the ground or on a > pole it has a 20, 30, 40, or even 50 year life span. To require > those assets to have a 1-3 year ROI is absurd. What happens if we have improvements in data transmission systems such that whatever we put in now is obsolete in 15 years? What happens if we put in billions of dollars of fiber, only to have fiber (and copper) obsolete as we roll out faster and faster wireless solutions? IMHO the biggest obstacle to defining broadband is figuring out how to describe how it is used in a way that prevents an ILEC from installing it so that only the ILEC can use it. If the customer doesn't have at least 3 broadband choices, there's no real choice, and pricing will be artificially high and service options will be stagnant and few. Look at what happened to long distance rates and telephone services once Ma Bell was broken up and businesses started competing for customers. I remember when we paid more than $35 a month for long distance fees alone (and about that much more for our basic service, including phone "rental") when I was a teenager in the 1970s. Without competition, with inflation, that same long distance bill would easily be over $100/month today. Yest today, more than 30 years later you can get a cell phone with unlimited minutes, unlimited domestic long distance, for $35/month (e.g Metro PCS). Let's not make this mistake again and let the ILECs use TARP funds to build "broadband" to the curb/home that only they get to use to provide internet services to the customers. jc From egon at egon.cc Fri Aug 28 01:06:31 2009 From: egon at egon.cc (James Downs) Date: Thu, 27 Aug 2009 23:06:31 -0700 Subject: FCCs RFC for the Definition of Broadband In-Reply-To: <4A95CC85.8080102@gmail.com> References: <4A95CC85.8080102@gmail.com> Message-ID: On Aug 26, 2009, at 5:00 PM, Roy wrote: > I think it has become obvious that the correct definition of > broadband depends on the users location. A house in the boonies is > not going to get fiber, Perhaps the minimum acceptable bandwidth > should vary by area. A definition of "area" could be some sort of > user density Except this is exactly what happened. The players with vested interests were allowed a sort of "first refusal" on projects. In areas where they had lots of customers, they passed on the projects. So, we find that in urban areas, you can't get fiber in the home, but there are countless rural farms and homes that have fiber just lying around. I have an acquaintance 60 miles from the closest commercial airport in TN, telling me about the fiber internet he has. -j From tme at americafree.tv Fri Aug 28 06:11:39 2009 From: tme at americafree.tv (Marshall Eubanks) Date: Fri, 28 Aug 2009 07:11:39 -0400 Subject: FCCs RFC for the Definition of Broadband In-Reply-To: <4A974AF6.6090006@bennett.com> References: <4a9edb810908240917r15739868i93ae029165962e9c@mail.gmail.com> <41A99CED-7857-4E24-B536-31493DE2EB99@cisco.com> <3c3e3fca0908261445y77533dbcscd7945aac532e78d@mail.gmail.com> <4A974AF6.6090006@bennett.com> Message-ID: <41B675DB-BF67-41E3-91C9-E5F8D3D9EF14@americafree.tv> On Aug 27, 2009, at 11:11 PM, Richard Bennett wrote: > The background issue is whether satellite-based systems at around > 200 Kb/s and high latency can be defined as "broadband." Since > everyone in America - including the Alaskans - has access to > satellite services, defining that level of service as broadband > makes the rest of the exercise academic: everyone is "served." > There's no economic argument for government subsidies to multiple > firms in a market, of course. It seems to me that there has to be an element of what can be the hardest thing to obtain in Government, judgement. If I lived on Attu Island in the Aleutians, I would probably consider a 200 Kb/s satellite link as broadband. Where I live in Northern Virginia, I would not. If there isn't some form of judgement about what is suitable and possible in a given area, the results are not likely to be good. Regards Marshall > > It's more interesting considering that DirecTV is about to launch a > new satellite with a couple orders of magnitude more capacity than > the existing ones offer. I seem to recall their claiming that the > service would then improved to some respectable number of megabits/ > sec. Satellite ISPs locate their ground stations in IXP-friendly > locations, so there aren't any worries about backhaul or fiber > access costs. > > But to your actual question, "under-served" is of course quite > subjective and cost is clearly part of it. > > RB > > Frank Bulk - iName.com wrote: >> As one of the workshops discussed, does the definition of >> "underserved" and >> "unserved" include the clause "for a reasonable price"? >> If the price is unreasonable, do you think its government money >> well-spent >> to subsidize bringing a competitor to a market that couldn't make >> it before? >> Or are there perhaps other ways to deal with that pricing issue? >> >> Frank >> >> -----Original Message----- >> From: William Herrin [mailto:herrin-nanog at dirtside.com] Sent: >> Wednesday, August 26, 2009 4:46 PM >> To: Fred Baker >> Cc: nanog at nanog.org >> Subject: Re: FCCs RFC for the Definition of Broadband >> >> >> >> Really where they need the swift kick in the tail is in the product >> tying where you can't buy a high speed connection to J. Random ISP, >> you can only buy a high speed connection to monopoly provider's >> in-house ISP. Which means you can only get commodity service since >> monopoly provider isn't in the business of providing low-dollar >> custom >> solutions. But it sounds like that's outside the scope of what >> Congress has approved. >> >> Regards, >> Bill Herrin >> >> > > -- > Richard Bennett > Research Fellow > Information Technology and Innovation Foundation > Washington, DC > > > From thegameiam at yahoo.com Fri Aug 28 08:25:08 2009 From: thegameiam at yahoo.com (David Barak) Date: Fri, 28 Aug 2009 06:25:08 -0700 (PDT) Subject: FCCs RFC for the Definition of Broadband In-Reply-To: References: <4A95CC85.8080102@gmail.com> Message-ID: <702651.75388.qm@web31804.mail.mud.yahoo.com> ----- Original Message ---- From: James Downs Except this is exactly what happened. The players with vested interests were allowed a sort of "first refusal" on projects. In areas where they had lots of customers, they passed on the projects. So, we find that in urban areas, you can't get fiber in the home, but there are countless rural farms and homes that have fiber just lying around. I have an acquaintance 60 miles from the closest commercial airport in TN, telling me about the fiber internet he has. As an example of the above, Verizon has until 2017 to get FIOS to all of the neighborhoods of Washington DC (http://www.bizjournals.com/washington/stories/2008/11/24/daily8.html). I am envious of many of my suburban-dwelling coworkers and friends who already have it. David Barak Need Geek Rock? Try The Franchise: http://www.listentothefranchise.com From rs at seastrom.com Fri Aug 28 08:29:58 2009 From: rs at seastrom.com (Robert E. Seastrom) Date: Fri, 28 Aug 2009 09:29:58 -0400 Subject: FCCs RFC for the Definition of Broadband In-Reply-To: <4A95FB76.7090707@brightok.net> (Jack Bates's message of "Wed, 26 Aug 2009 22:20:22 -0500") References: <859604546CD1FF488BDB6EA94C896AFB8ABE40@racexchange.race.local> <3A89064E-4F43-4FFC-B535-B4D971CFDEF0@cisco.com> <4A9587B0.4080306@brightok.net> <4A95B736.2040409@enger.us> <4A95FB76.7090707@brightok.net> Message-ID: <86ocq0awx5.fsf@seastrom.com> The problem is that if you break down the costs, you'll find out that it almost doesn't matter what you put in as a cost of the total build; the big costs are the engineering and the labor to install, not the "cost of the NID" or anything like that. Nobody cares whether you saved a million bucks on a 2 billion dollar project. One of the cool things about the infrastructure that is now in place (copper pairs) is that it turned out to be relatively future-proof - lots of 50 and 70 year old OSP still in use. In order to get similarly long life out of newly installed fiber assets, the only real solution is home runs to either existing or newly constructed concentration points (not just a box at the side of the road, that's not what I'm talking about here). Distributed splitter designs force forklift upgrades when the Next Big Thing comes along, rather than upgrading the service only for folks who are willing to pay for it. The Next Big Thing is always coming, and 2.4 Gbit/sec down per port GPON is gonna look awfully slow 10 years hence when everyone's demanding gigabit ethernet to the desktop, not to mention 20 years from now with IPv6 multicast of 2000 channels of 4320p pr0n. I used to believe in the FTTC (fiber to the curb) model too - it's the "obvious" solution. That was before I started cranking the numbers myself, playing with some of the new splicing solutions that are out there that require *far* less finesse than the cam-splice stuff I was using 10 years ago. Now I believe in the "other" FTTC (fiber to the couch). Get it as far out into the field as you possibly can, right up to, or even inside, the house. -r Jack Bates writes: > heh. I've seen 3 different plans for FTTH in 3 different telco's; > different engineering firms. All 3 had active devices in the > OSP. Apparently they couldn't justify putting more fiber in all the > way back to the office. > > Don't get me wrong. I've heard wonderful drawn out arguments > concerning vendors that failed to properly handle Oklahoma summers or > draw too much power. > > Brings up new PRO: active devices in the OSP providing longhaul > redundancy on fiber rings > > Another PRO: simple, inexpensive NID > > Jack > > Robert Enger - NANOG wrote: >> CON: active devices in the OSP. >> On 8/26/2009 12:06 PM, Jack Bates wrote: >>> jim deleskie wrote: >>>> I agree we should all be telling the FCC that broadband is fiber to >>>> the home. If we spend all kinds of $$ to build a 1.5M/s connection to >>>> homes, it's outdated before we even finish. >>> >>> I disagree. I much prefer fiber to the curb with copper to the >>> home. Of course, I haven't had a need for 100mb/s to the house >>> which I can do on copper, much less need for gigabit. >>> >>> Pro's for copper from curb: >>> >>> 1) power over copper for POTS >>> 2) Majority of cuts occur on customer drops and copper is more >>> resilient to splicing by any monkey. >>> >>> Jack >>> From deleskie at gmail.com Fri Aug 28 08:34:13 2009 From: deleskie at gmail.com (deleskie at gmail.com) Date: Fri, 28 Aug 2009 13:34:13 +0000 Subject: FCCs RFC for the Definition of Broadband In-Reply-To: <86ocq0awx5.fsf@seastrom.com> References: <859604546CD1FF488BDB6EA94C896AFB8ABE40@racexchange.race.local><3A89064E-4F43-4FFC-B535-B4D971CFDEF0@cisco.com><4A9587B0.4080306@brightok.net> <4A95B736.2040409@enger.us><4A95FB76.7090707@brightok.net><86ocq0awx5.fsf@seastrom.com> Message-ID: <1693791496-1251466472-cardhu_decombobulator_blackberry.rim.net-1592748713-@bxe1156.bisx.prod.on.blackberry> Rob, well put. -jim Sent from my BlackBerry device on the Rogers Wireless Network -----Original Message----- From: "Robert E. Seastrom" Date: Fri, 28 Aug 2009 09:29:58 To: Jack Bates Cc: Robert Enger - NANOG; Subject: Re: FCCs RFC for the Definition of Broadband The problem is that if you break down the costs, you'll find out that it almost doesn't matter what you put in as a cost of the total build; the big costs are the engineering and the labor to install, not the "cost of the NID" or anything like that. Nobody cares whether you saved a million bucks on a 2 billion dollar project. One of the cool things about the infrastructure that is now in place (copper pairs) is that it turned out to be relatively future-proof - lots of 50 and 70 year old OSP still in use. In order to get similarly long life out of newly installed fiber assets, the only real solution is home runs to either existing or newly constructed concentration points (not just a box at the side of the road, that's not what I'm talking about here). Distributed splitter designs force forklift upgrades when the Next Big Thing comes along, rather than upgrading the service only for folks who are willing to pay for it. The Next Big Thing is always coming, and 2.4 Gbit/sec down per port GPON is gonna look awfully slow 10 years hence when everyone's demanding gigabit ethernet to the desktop, not to mention 20 years from now with IPv6 multicast of 2000 channels of 4320p pr0n. I used to believe in the FTTC (fiber to the curb) model too - it's the "obvious" solution. That was before I started cranking the numbers myself, playing with some of the new splicing solutions that are out there that require *far* less finesse than the cam-splice stuff I was using 10 years ago. Now I believe in the "other" FTTC (fiber to the couch). Get it as far out into the field as you possibly can, right up to, or even inside, the house. -r Jack Bates writes: > heh. I've seen 3 different plans for FTTH in 3 different telco's; > different engineering firms. All 3 had active devices in the > OSP. Apparently they couldn't justify putting more fiber in all the > way back to the office. > > Don't get me wrong. I've heard wonderful drawn out arguments > concerning vendors that failed to properly handle Oklahoma summers or > draw too much power. > > Brings up new PRO: active devices in the OSP providing longhaul > redundancy on fiber rings > > Another PRO: simple, inexpensive NID > > Jack > > Robert Enger - NANOG wrote: >> CON: active devices in the OSP. >> On 8/26/2009 12:06 PM, Jack Bates wrote: >>> jim deleskie wrote: >>>> I agree we should all be telling the FCC that broadband is fiber to >>>> the home. If we spend all kinds of $$ to build a 1.5M/s connection to >>>> homes, it's outdated before we even finish. >>> >>> I disagree. I much prefer fiber to the curb with copper to the >>> home. Of course, I haven't had a need for 100mb/s to the house >>> which I can do on copper, much less need for gigabit. >>> >>> Pro's for copper from curb: >>> >>> 1) power over copper for POTS >>> 2) Majority of cuts occur on customer drops and copper is more >>> resilient to splicing by any monkey. >>> >>> Jack >>> From jbates at brightok.net Fri Aug 28 08:34:32 2009 From: jbates at brightok.net (Jack Bates) Date: Fri, 28 Aug 2009 08:34:32 -0500 Subject: FCCs RFC for the Definition of Broadband In-Reply-To: <4A976227.8080008@gmail.com> References: <4a9edb810908240917r15739868i93ae029165962e9c@mail.gmail.com> <4A95B431.70102@enger.us> <200908270958.46014.alexander.harrowell@stlpartners.com> <20090827140459.GA64392@ussenterprise.ufp.org> <4A969C65.8040506@telcodata.us> <20090827145800.GA67840@ussenterprise.ufp.org> <4A976227.8080008@gmail.com> Message-ID: <4A97DCE8.1070405@brightok.net> JC Dill wrote: > IMHO the biggest obstacle to defining broadband is figuring out how to > describe how it is used in a way that prevents an ILEC from installing > it so that only the ILEC can use it. If the customer doesn't have at Oh, that's easy. If the government pays for 90% of the plant cost, I'm sure ILECs would love to share it with everyone else. Until then, put your own plant in. As an added bonus, when you put your own plant in as a CLEC, you can just serve the profitable areas and leave the poor ILEC having to serve the barn 15 miles from the nearest neighbor. Jack From jbates at brightok.net Fri Aug 28 08:47:23 2009 From: jbates at brightok.net (Jack Bates) Date: Fri, 28 Aug 2009 08:47:23 -0500 Subject: FCCs RFC for the Definition of Broadband In-Reply-To: <86ocq0awx5.fsf@seastrom.com> References: <859604546CD1FF488BDB6EA94C896AFB8ABE40@racexchange.race.local> <3A89064E-4F43-4FFC-B535-B4D971CFDEF0@cisco.com> <4A9587B0.4080306@brightok.net> <4A95B736.2040409@enger.us> <4A95FB76.7090707@brightok.net> <86ocq0awx5.fsf@seastrom.com> Message-ID: <4A97DFEB.3090102@brightok.net> Robert E. Seastrom wrote: > The problem is that if you break down the costs, you'll find out that > it almost doesn't matter what you put in as a cost of the total build; > the big costs are the engineering and the labor to install, not the > "cost of the NID" or anything like that. Nobody cares whether you > saved a million bucks on a 2 billion dollar project. > Errr, I've yet to meet a rural ILEC that doesn't take the cost of the NID splitter vs inline splitters into account. ILECs will argue over a single $1/customer, and rightfully so. The cost of the FTTH NID adds considerably to the price per customer. In addition, it generates additional maintenance costs maintaining batteries. I've yet to hear an ILEC suggest that they not have batteries in the NID to support the voice in power outages. Batteries have shelf lives, and maintaining one per household is definitely more costly than maintaining the batteries to power the remotes. Getting rid of costs, FTTH uses more power, and most of the people I've talked to said we can't feed it from the remotes even via copper mixed with the fiber. This creates issues when we need to provide service. Everyone always badmouth's the whole emergency phone thing, but we take it seriously in the rural areas where power outages are not uncommon, natural disasters are expected, and we are the ONLY utility that continues to function. Jack > One of the cool things about the infrastructure that is now in place > (copper pairs) is that it turned out to be relatively future-proof - > lots of 50 and 70 year old OSP still in use. In order to get > similarly long life out of newly installed fiber assets, the only real > solution is home runs to either existing or newly constructed > concentration points (not just a box at the side of the road, that's > not what I'm talking about here). Distributed splitter designs force > forklift upgrades when the Next Big Thing comes along, rather than > upgrading the service only for folks who are willing to pay for it. > The Next Big Thing is always coming, and 2.4 Gbit/sec down per port > GPON is gonna look awfully slow 10 years hence when everyone's > demanding gigabit ethernet to the desktop, not to mention 20 years > from now with IPv6 multicast of 2000 channels of 4320p pr0n. > > I used to believe in the FTTC (fiber to the curb) model too - it's the > "obvious" solution. That was before I started cranking the numbers > myself, playing with some of the new splicing solutions that are out > there that require *far* less finesse than the cam-splice stuff I was > using 10 years ago. Now I believe in the "other" FTTC (fiber to the couch). > Get it as far out into the field as you possibly can, right up to, > or even inside, the house. > > -r > > Jack Bates writes: > >> heh. I've seen 3 different plans for FTTH in 3 different telco's; >> different engineering firms. All 3 had active devices in the >> OSP. Apparently they couldn't justify putting more fiber in all the >> way back to the office. >> >> Don't get me wrong. I've heard wonderful drawn out arguments >> concerning vendors that failed to properly handle Oklahoma summers or >> draw too much power. >> >> Brings up new PRO: active devices in the OSP providing longhaul >> redundancy on fiber rings >> >> Another PRO: simple, inexpensive NID >> >> Jack >> >> Robert Enger - NANOG wrote: >>> CON: active devices in the OSP. >>> On 8/26/2009 12:06 PM, Jack Bates wrote: >>>> jim deleskie wrote: >>>>> I agree we should all be telling the FCC that broadband is fiber to >>>>> the home. If we spend all kinds of $$ to build a 1.5M/s connection to >>>>> homes, it's outdated before we even finish. >>>> I disagree. I much prefer fiber to the curb with copper to the >>>> home. Of course, I haven't had a need for 100mb/s to the house >>>> which I can do on copper, much less need for gigabit. >>>> >>>> Pro's for copper from curb: >>>> >>>> 1) power over copper for POTS >>>> 2) Majority of cuts occur on customer drops and copper is more >>>> resilient to splicing by any monkey. >>>> >>>> Jack >>>> From dhetzel at gmail.com Fri Aug 28 09:00:21 2009 From: dhetzel at gmail.com (Dorn Hetzel) Date: Fri, 28 Aug 2009 10:00:21 -0400 Subject: FCCs RFC for the Definition of Broadband In-Reply-To: <4A97DFEB.3090102@brightok.net> References: <859604546CD1FF488BDB6EA94C896AFB8ABE40@racexchange.race.local> <3A89064E-4F43-4FFC-B535-B4D971CFDEF0@cisco.com> <4A9587B0.4080306@brightok.net> <4A95B736.2040409@enger.us> <4A95FB76.7090707@brightok.net> <86ocq0awx5.fsf@seastrom.com> <4A97DFEB.3090102@brightok.net> Message-ID: <7db2dcf90908280700rd9527c3of770908cc5b63cd@mail.gmail.com> Perhaps the most practical service for both broadband and ALWAYS-on voice service is one pair of copper (POTS) and one pair of fiber everything-else per house. Does anyone have a ballpark guess on the incremental cost of a strand-mile (assuming the ditch is going to be dug and the cable put in it, how much does the per-mile cost of the cable go up for each additional strand in it) ? If the fiber pair goes all the way from some reasonably concentrated location to the house, then excessive locations with batteries should not be required. -Dorn On Fri, Aug 28, 2009 at 9:47 AM, Jack Bates wrote: > Robert E. Seastrom wrote: > >> The problem is that if you break down the costs, you'll find out that >> it almost doesn't matter what you put in as a cost of the total build; >> the big costs are the engineering and the labor to install, not the >> "cost of the NID" or anything like that. Nobody cares whether you >> saved a million bucks on a 2 billion dollar project. >> >> > Errr, I've yet to meet a rural ILEC that doesn't take the cost of the NID > splitter vs inline splitters into account. ILECs will argue over a single > $1/customer, and rightfully so. The cost of the FTTH NID adds considerably > to the price per customer. In addition, it generates additional maintenance > costs maintaining batteries. I've yet to hear an ILEC suggest that they not > have batteries in the NID to support the voice in power outages. Batteries > have shelf lives, and maintaining one per household is definitely more > costly than maintaining the batteries to power the remotes. > > Getting rid of costs, FTTH uses more power, and most of the people I've > talked to said we can't feed it from the remotes even via copper mixed with > the fiber. This creates issues when we need to provide service. Everyone > always badmouth's the whole emergency phone thing, but we take it seriously > in the rural areas where power outages are not uncommon, natural disasters > are expected, and we are the ONLY utility that continues to function. > > > Jack > > > One of the cool things about the infrastructure that is now in place >> (copper pairs) is that it turned out to be relatively future-proof - >> lots of 50 and 70 year old OSP still in use. In order to get >> similarly long life out of newly installed fiber assets, the only real >> solution is home runs to either existing or newly constructed >> concentration points (not just a box at the side of the road, that's >> not what I'm talking about here). Distributed splitter designs force >> forklift upgrades when the Next Big Thing comes along, rather than >> upgrading the service only for folks who are willing to pay for it. >> The Next Big Thing is always coming, and 2.4 Gbit/sec down per port >> GPON is gonna look awfully slow 10 years hence when everyone's >> demanding gigabit ethernet to the desktop, not to mention 20 years >> from now with IPv6 multicast of 2000 channels of 4320p pr0n. >> >> I used to believe in the FTTC (fiber to the curb) model too - it's the >> "obvious" solution. That was before I started cranking the numbers >> myself, playing with some of the new splicing solutions that are out >> there that require *far* less finesse than the cam-splice stuff I was >> using 10 years ago. Now I believe in the "other" FTTC (fiber to the >> couch). >> Get it as far out into the field as you possibly can, right up to, >> or even inside, the house. >> >> -r >> >> Jack Bates writes: >> >> heh. I've seen 3 different plans for FTTH in 3 different telco's; >>> different engineering firms. All 3 had active devices in the >>> OSP. Apparently they couldn't justify putting more fiber in all the >>> way back to the office. >>> >>> Don't get me wrong. I've heard wonderful drawn out arguments >>> concerning vendors that failed to properly handle Oklahoma summers or >>> draw too much power. >>> >>> Brings up new PRO: active devices in the OSP providing longhaul >>> redundancy on fiber rings >>> >>> Another PRO: simple, inexpensive NID >>> >>> Jack >>> >>> Robert Enger - NANOG wrote: >>> >>>> CON: active devices in the OSP. >>>> On 8/26/2009 12:06 PM, Jack Bates wrote: >>>> >>>>> jim deleskie wrote: >>>>> >>>>>> I agree we should all be telling the FCC that broadband is fiber to >>>>>> the home. If we spend all kinds of $$ to build a 1.5M/s connection to >>>>>> homes, it's outdated before we even finish. >>>>>> >>>>> I disagree. I much prefer fiber to the curb with copper to the >>>>> home. Of course, I haven't had a need for 100mb/s to the house >>>>> which I can do on copper, much less need for gigabit. >>>>> >>>>> Pro's for copper from curb: >>>>> >>>>> 1) power over copper for POTS >>>>> 2) Majority of cuts occur on customer drops and copper is more >>>>> resilient to splicing by any monkey. >>>>> >>>>> Jack >>>>> >>>>> > From jgreco at ns.sol.net Fri Aug 28 09:05:38 2009 From: jgreco at ns.sol.net (Joe Greco) Date: Fri, 28 Aug 2009 09:05:38 -0500 (CDT) Subject: FCCs RFC for the Definition of Broadband In-Reply-To: <4A97DCE8.1070405@brightok.net> from "Jack Bates" at Aug 28, 2009 08:34:32 AM Message-ID: <200908281405.n7SE5dJa062396@aurora.sol.net> > JC Dill wrote: > > IMHO the biggest obstacle to defining broadband is figuring out how to > > describe how it is used in a way that prevents an ILEC from installing > > it so that only the ILEC can use it. If the customer doesn't have at > > Oh, that's easy. If the government pays for 90% of the plant cost, I'm > sure ILECs would love to share it with everyone else. Until then, put > your own plant in. As an added bonus, when you put your own plant in as > a CLEC, you can just serve the profitable areas and leave the poor ILEC > having to serve the barn 15 miles from the nearest neighbor. Huh? Wait, don't drink anymore of that, guys! We've *already* subsidized the telcos $200 billion for a next generation broadband-capable plant, that was supposed to be LEC-neutral... http://www.pbs.org/cringely/pulpit/2007/pulpit_20070810_002683.html So, we've *already* paid the plant cost, and we've gotten nothing much in return. ... 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 dts at senie.com Fri Aug 28 09:17:55 2009 From: dts at senie.com (Daniel Senie) Date: Fri, 28 Aug 2009 10:17:55 -0400 Subject: FCCs RFC for the Definition of Broadband In-Reply-To: <4A97DFEB.3090102@brightok.net> References: <859604546CD1FF488BDB6EA94C896AFB8ABE40@racexchange.race.local> <3A89064E-4F43-4FFC-B535-B4D971CFDEF0@cisco.com> <4A9587B0.4080306@brightok.net> <4A95B736.2040409@enger.us> <4A95FB76.7090707@brightok.net> <86ocq0awx5.fsf@seastrom.com> <4A97DFEB.3090102@brightok.net> Message-ID: <34FF258A-3CA1-446C-96FA-69808276A43B@senie.com> On Aug 28, 2009, at 9:47 AM, Jack Bates wrote: > Robert E. Seastrom wrote: >> The problem is that if you break down the costs, you'll find out that >> it almost doesn't matter what you put in as a cost of the total >> build; >> the big costs are the engineering and the labor to install, not the >> "cost of the NID" or anything like that. Nobody cares whether you >> saved a million bucks on a 2 billion dollar project. > > Errr, I've yet to meet a rural ILEC that doesn't take the cost of > the NID splitter vs inline splitters into account. ILECs will argue > over a single $1/customer, and rightfully so. The cost of the FTTH > NID adds considerably to the price per customer. In addition, it > generates additional maintenance costs maintaining batteries. I've > yet to hear an ILEC suggest that they not have batteries in the NID > to support the voice in power outages. Batteries have shelf lives, > and maintaining one per household is definitely more costly than > maintaining the batteries to power the remotes. > > Getting rid of costs, FTTH uses more power, and most of the people > I've talked to said we can't feed it from the remotes even via > copper mixed with the fiber. This creates issues when we need to > provide service. Everyone always badmouth's the whole emergency > phone thing, but we take it seriously in the rural areas where power > outages are not uncommon, natural disasters are expected, and we are > the ONLY utility that continues to function. Before you get too hung up on the emergency phone thing, take a hard look at the present day. The telcos pushed SLC gear out everywhere. Those have batteries, but at least in some areas, no maintenance was done, batteries died, and when the power went out, so did the phones. The SLCs had generator plug-in setups to be used in an emergency, but in any natural disaster, it's unlikely there'd be enough portables deployed and maintained by the telco to keep the multiplexors alive. For myself, I moved my phone service off Verizon to Comcast in part because Comcast service always works through power outages, where Verizon in the last 5 years has always failed. That just means in my neighborhood, Comcast's batteries haven't died yet. If you want to make the emergency phone thing a part of the discussion, then regulations need to exist AND be enforced, and penalties assessed, for failure to provide such during power outages. It's not happening today, so don't expect it in the future either. From jbates at brightok.net Fri Aug 28 09:19:50 2009 From: jbates at brightok.net (Jack Bates) Date: Fri, 28 Aug 2009 09:19:50 -0500 Subject: FCCs RFC for the Definition of Broadband In-Reply-To: <200908281405.n7SE5dJa062396@aurora.sol.net> References: <200908281405.n7SE5dJa062396@aurora.sol.net> Message-ID: <4A97E786.30309@brightok.net> Joe Greco wrote: > We've *already* subsidized the telcos $200 billion for a next generation > broadband-capable plant, that was supposed to be LEC-neutral... Yeah, not every telco participated, though the RBOCs sure did. > So, we've *already* paid the plant cost, and we've gotten nothing much in > return. Looking at just Oklahoma, I'm not sure AT&T could get even 200kb to every household for $200b. More interesting, I'd be curious to see how well NSP's could handle the increase in traffic if every house support 45mb of Internet (not local video/voice). I'd love to see some good data on how the average throughput changes as the rates go up, especially with the continued increase of higher bandwidth video. Jack From bicknell at ufp.org Fri Aug 28 09:29:20 2009 From: bicknell at ufp.org (Leo Bicknell) Date: Fri, 28 Aug 2009 10:29:20 -0400 Subject: FCCs RFC for the Definition of Broadband In-Reply-To: <4A97E786.30309@brightok.net> References: <200908281405.n7SE5dJa062396@aurora.sol.net> <4A97E786.30309@brightok.net> Message-ID: <20090828142920.GA56263@ussenterprise.ufp.org> In a message written on Fri, Aug 28, 2009 at 09:19:50AM -0500, Jack Bates wrote: > Looking at just Oklahoma, I'm not sure AT&T could get even 200kb to > every household for $200b. For an interesting set of cost comparisons.... In most locations every home has electrical service. What's the cost per household? Most houses have a statem maintained road in front of them, what is the cost per household? Many (although a lower number) of "city" water and sewer, what is the cost per household? For a number of reasons I would expect Broadband to be cheaper than any of those, per household; but should definately not exceed any of them in cost. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 825 bytes Desc: not available URL: From michael.holstein at csuohio.edu Fri Aug 28 09:33:02 2009 From: michael.holstein at csuohio.edu (Michael Holstein) Date: Fri, 28 Aug 2009 10:33:02 -0400 Subject: FCCs RFC for the Definition of Broadband In-Reply-To: <4A97DCE8.1070405@brightok.net> References: <4a9edb810908240917r15739868i93ae029165962e9c@mail.gmail.com> <4A95B431.70102@enger.us> <200908270958.46014.alexander.harrowell@stlpartners.com> <20090827140459.GA64392@ussenterprise.ufp.org> <4A969C65.8040506@telcodata.us> <20090827145800.GA67840@ussenterprise.ufp.org> <4A976227.8080008@gmail.com> <4A97DCE8.1070405@brightok.net> Message-ID: <4A97EA9E.6020608@csuohio.edu> > Oh, that's easy. If the government pays for 90% of the plant cost There have been countless times where a local government wanted to install the fiber *themselves*, only to have the ILEC file a lawsuit and/or petition (bribe) the State Legislature to prevent installation. Cheers, Michael Holstein Cleveland State University From jbates at brightok.net Fri Aug 28 09:32:06 2009 From: jbates at brightok.net (Jack Bates) Date: Fri, 28 Aug 2009 09:32:06 -0500 Subject: FCCs RFC for the Definition of Broadband In-Reply-To: <34FF258A-3CA1-446C-96FA-69808276A43B@senie.com> References: <859604546CD1FF488BDB6EA94C896AFB8ABE40@racexchange.race.local> <3A89064E-4F43-4FFC-B535-B4D971CFDEF0@cisco.com> <4A9587B0.4080306@brightok.net> <4A95B736.2040409@enger.us> <4A95FB76.7090707@brightok.net> <86ocq0awx5.fsf@seastrom.com> <4A97DFEB.3090102@brightok.net> <34FF258A-3CA1-446C-96FA-69808276A43B@senie.com> Message-ID: <4A97EA66.7090701@brightok.net> Daniel Senie wrote: > Before you get too hung up on the emergency phone thing, take a hard > look at the present day. The telcos pushed SLC gear out everywhere. I'm the network engineer for 12 ILECs. Over the last 10 years, I've seen several major outages (> 48 hours) where voice has been maintained. One ILEC was disappointed in not being able to maintain DSL as well (as DSLAM/SLC was separate). They've since developed a plan to solve that issue and to maintain DSL as well (just for those households that have power/generators themselves). > If you want to make the emergency phone thing a part of the discussion, > then regulations need to exist AND be enforced, and penalties assessed, > for failure to provide such during power outages. It's not happening > today, so don't expect it in the future either. > That may be. I don't know what RBOCs do. The ILECs here are privately owned companies. They aren't publicly traded. They are a part of their communities. Don't get me wrong, profit is definitely on the top list, but not at the sacrifice of quality and reliability. When your daily life consists of spending time with your customers because it's your community, you do everything you can to protect your name and reputation. A not uncommon statement heard when someone doesn't like the answer given by the helpdesk, "I'm friends with the owner. I'm going to call and complain to him/her." Jack From jbates at brightok.net Fri Aug 28 09:33:01 2009 From: jbates at brightok.net (Jack Bates) Date: Fri, 28 Aug 2009 09:33:01 -0500 Subject: FCCs RFC for the Definition of Broadband In-Reply-To: <4A97EA9E.6020608@csuohio.edu> References: <4a9edb810908240917r15739868i93ae029165962e9c@mail.gmail.com> <4A95B431.70102@enger.us> <200908270958.46014.alexander.harrowell@stlpartners.com> <20090827140459.GA64392@ussenterprise.ufp.org> <4A969C65.8040506@telcodata.us> <20090827145800.GA67840@ussenterprise.ufp.org> <4A976227.8080008@gmail.com> <4A97DCE8.1070405@brightok.net> <4A97EA9E.6020608@csuohio.edu> Message-ID: <4A97EA9D.8050004@brightok.net> Michael Holstein wrote: > There have been countless times where a local government wanted to > install the fiber *themselves*, only to have the ILEC file a lawsuit > and/or petition (bribe) the State Legislature to prevent installation. Out of curiousity, ILEC or RBOC? Have some pointers? Jack From cmadams at hiwaay.net Fri Aug 28 09:59:07 2009 From: cmadams at hiwaay.net (Chris Adams) Date: Fri, 28 Aug 2009 09:59:07 -0500 Subject: FCCs RFC for the Definition of Broadband In-Reply-To: <34FF258A-3CA1-446C-96FA-69808276A43B@senie.com> References: <859604546CD1FF488BDB6EA94C896AFB8ABE40@racexchange.race.local> <3A89064E-4F43-4FFC-B535-B4D971CFDEF0@cisco.com> <4A9587B0.4080306@brightok.net> <4A95B736.2040409@enger.us> <4A95FB76.7090707@brightok.net> <86ocq0awx5.fsf@seastrom.com> <4A97DFEB.3090102@brightok.net> <34FF258A-3CA1-446C-96FA-69808276A43B@senie.com> Message-ID: <20090828145907.GA1426583@hiwaay.net> Once upon a time, Daniel Senie said: > Before you get too hung up on the emergency phone thing, take a hard > look at the present day. The telcos pushed SLC gear out everywhere. > Those have batteries, but at least in some areas, no maintenance was > done, batteries died, and when the power went out, so did the phones. > The SLCs had generator plug-in setups to be used in an emergency, but > in any natural disaster, it's unlikely there'd be enough portables > deployed and maintained by the telco to keep the multiplexors alive. Around here, most BellSouth cabinets have a natural gas generator as part of the setup, so they stay up as long as the gas lines are good (and if something has happened to both the power lines and the gas service, it probably doesn't matter much anyway). We had a fairly large power outage here a few months ago that affected just about everybody except for my house and my sister's house (we're only a mile or so apart). Neither of us even knew the power was out until we left our houses. Her Comcast cable was out (my Knology wasn't), so she decided to go to the store (I just happened to also go out at the same time). Sticking with BellSouth/AT&T for phone service (and DSL for Internet) wasn't such a bad idea after all. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From jbates at brightok.net Fri Aug 28 10:00:32 2009 From: jbates at brightok.net (Jack Bates) Date: Fri, 28 Aug 2009 10:00:32 -0500 Subject: FCCs RFC for the Definition of Broadband In-Reply-To: <20090828142920.GA56263@ussenterprise.ufp.org> References: <200908281405.n7SE5dJa062396@aurora.sol.net> <4A97E786.30309@brightok.net> <20090828142920.GA56263@ussenterprise.ufp.org> Message-ID: <4A97F110.3020406@brightok.net> Leo Bicknell wrote: > In most locations every home has electrical service. What's the > cost per household? $20/mo electric bill. That would so rock. > Most houses have a statem maintained road in front of them, what > is the cost per household? Paid for by City/County or more commonly by the land owner. New development in Lone Grove, for example requires the developer to put the road in, and then it's wrapped into the house cost. The city will not take over the roads otherwise. Lots of gravel roads here. > Many (although a lower number) of "city" water and sewer, what is > the cost per household? Way lower number. I'd be surprised if the "city" water and sewer here covers 25% of the city. Most water is cover by a rural water company. > For a number of reasons I would expect Broadband to be cheaper than any > of those, per household; but should definately not exceed any of them in > cost. A friend has a well and there is a water pipe running just outside their property. They were quoted $20k to "hook on" to the water and they would still have to run the line themselves. A lot of residential services are paid for by the home owners by virtue of the developer. It is easier and more cost efficient to build out during new construction of homes than to retrofit plant after the fact. Jack From bicknell at ufp.org Fri Aug 28 10:07:12 2009 From: bicknell at ufp.org (Leo Bicknell) Date: Fri, 28 Aug 2009 11:07:12 -0400 Subject: FCCs RFC for the Definition of Broadband In-Reply-To: <4A97F110.3020406@brightok.net> References: <200908281405.n7SE5dJa062396@aurora.sol.net> <4A97E786.30309@brightok.net> <20090828142920.GA56263@ussenterprise.ufp.org> <4A97F110.3020406@brightok.net> Message-ID: <20090828150712.GA58799@ussenterprise.ufp.org> In a message written on Fri, Aug 28, 2009 at 10:00:32AM -0500, Jack Bates wrote: > Leo Bicknell wrote: > >In most locations every home has electrical service. What's the > >cost per household? > > $20/mo electric bill. That would so rock. There is the cost to put the line in to your house, and then the cost for the 100Kva of servers you have in your basement. :) Now, $20/month plus $1 per megabit, 95% for a GigE line....that would rock. > >Most houses have a statem maintained road in front of them, what > >is the cost per household? > > Paid for by City/County or more commonly by the land owner. New > development in Lone Grove, for example requires the developer to put the > road in, and then it's wrapped into the house cost. The city will not > take over the roads otherwise. Lots of gravel roads here. Unless I'm mistaken, in new construction the developer pays for the electrical install, the cable install, the telephone install, and the road install. In some cases these are subsidized, and in some the costs are spread around (e.g. when an entire neighborhood is being developed). I don't see why Broadband should be any different. > It is easier and more cost efficient to build out during new > construction of homes than to retrofit plant after the fact. In most areas of the country you can't get a permit to build a house without electrical service (something solar and other off the grid people are fighting). Since it is so much more cost effective to install with new construction, why don't we have codes requring Cat5 drops in every room, and fiber to the home for all new construction? -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 825 bytes Desc: not available URL: From beckman at angryox.com Fri Aug 28 10:14:08 2009 From: beckman at angryox.com (Peter Beckman) Date: Fri, 28 Aug 2009 11:14:08 -0400 Subject: FCCs RFC for the Definition of Broadband In-Reply-To: <20090828150712.GA58799@ussenterprise.ufp.org> References: <200908281405.n7SE5dJa062396@aurora.sol.net> <4A97E786.30309@brightok.net> <20090828142920.GA56263@ussenterprise.ufp.org> <4A97F110.3020406@brightok.net> <20090828150712.GA58799@ussenterprise.ufp.org> Message-ID: On Fri, 28 Aug 2009, Leo Bicknell wrote: > In most areas of the country you can't get a permit to build a house > without electrical service (something solar and other off the grid people > are fighting). Since it is so much more cost effective to install with > new construction, why don't we have codes requring Cat5 drops in every > room, and fiber to the home for all new construction? And where does that fiber go to? Home runs from a central point in the development, so any provider can hook up to any house at the street? Deregulation means those lines should be accessible to any company for a fee. How do you give House A Verizon and House B Cox, especially if Cox doesn't support fiber? Granted, I don't do residential broadband deployments, maybe all of those issues are trivial, but something that needs to be considered. Just because there is only one player in a certain market now doesn't mean we shouldn't plan now for 10 players 10 years from now in the same market. --------------------------------------------------------------------------- Peter Beckman Internet Guy beckman at angryox.com http://www.angryox.com/ --------------------------------------------------------------------------- From jabley at hopcount.ca Fri Aug 28 10:21:34 2009 From: jabley at hopcount.ca (Joe Abley) Date: Fri, 28 Aug 2009 08:21:34 -0700 Subject: FCCs RFC for the Definition of Broadband In-Reply-To: References: <200908281405.n7SE5dJa062396@aurora.sol.net> <4A97E786.30309@brightok.net> <20090828142920.GA56263@ussenterprise.ufp.org> <4A97F110.3020406@brightok.net> <20090828150712.GA58799@ussenterprise.ufp.org> Message-ID: <1C226385-2AB4-45E0-850D-C88C8A98B2A1@hopcount.ca> On 28-Aug-2009, at 08:14, Peter Beckman wrote: > On Fri, 28 Aug 2009, Leo Bicknell wrote: > >> In most areas of the country you can't get a permit to build a house >> without electrical service (something solar and other off the grid >> people >> are fighting). Since it is so much more cost effective to install >> with >> new construction, why don't we have codes requring Cat5 drops in >> every >> room, and fiber to the home for all new construction? > > And where does that fiber go to? Home runs from a central point in > the > development, so any provider can hook up to any house at the street? > Deregulation means those lines should be accessible to any company > for a > fee. How do you give House A Verizon and House B Cox, especially if > Cox > doesn't support fiber? This sounds like some of the scenarios that Bill St Arnaud worked through at CANARIE. I think they got as far as some test deployments in or around Ottawa. His general idea was that the homeowner owns conduit and fibre from the house to a shared neighbourhood colo facility, and has rights to some space in that facility. The facility then acts as a junction point between houses in the neighbourhood (if the neighbours want to connect) or as a place where a service provider could build to in order to deliver service to the homeowner. It has been some time since I read the material, but my memory is that the model was at its essence one of moving the provider/subscriber demarcation point from the house to a central neighbourhood location. Joe From beckman at angryox.com Fri Aug 28 10:28:56 2009 From: beckman at angryox.com (Peter Beckman) Date: Fri, 28 Aug 2009 11:28:56 -0400 Subject: FCCs RFC for the Definition of Broadband In-Reply-To: <1C226385-2AB4-45E0-850D-C88C8A98B2A1@hopcount.ca> References: <200908281405.n7SE5dJa062396@aurora.sol.net> <4A97E786.30309@brightok.net> <20090828142920.GA56263@ussenterprise.ufp.org> <4A97F110.3020406@brightok.net> <20090828150712.GA58799@ussenterprise.ufp.org> <1C226385-2AB4-45E0-850D-C88C8A98B2A1@hopcount.ca> Message-ID: On Fri, 28 Aug 2009, Joe Abley wrote: > On 28-Aug-2009, at 08:14, Peter Beckman wrote: > >> And where does that fiber go to? Home runs from a central point in the >> development, so any provider can hook up to any house at the street? >> Deregulation means those lines should be accessible to any company for a >> fee. How do you give House A Verizon and House B Cox, especially if Cox >> doesn't support fiber? > > His general idea was that the homeowner owns conduit and fibre from the house > to a shared neighbourhood colo facility, and has rights to some space in that > facility. The facility then acts as a junction point between houses in > the neighbourhood (if the neighbours want to connect) or as a place where > a service provider could build to in order to deliver service to the > homeowner. I like that idea, except for the problem that I don't want my neighbors to have access to the colo, or at least my feed, but I want access to my feed to I can reboot whatever device is connected there. There would have to be individual locked cages of some standard size so I could access and reboot or change my router out, but could not disconnect or modify my neighbors connection. It would really suck if my router locked up and it was locked in the colo room and I had to wait for someone to let me in to powercycle it. It would also really suck if my neighbor hated me and simply loosened my connection when they felt like it. I'm sure there are solutions to that problem, but moving the demarc line outside the home does bring up new and interesting challenges. --------------------------------------------------------------------------- Peter Beckman Internet Guy beckman at angryox.com http://www.angryox.com/ --------------------------------------------------------------------------- From jbates at brightok.net Fri Aug 28 10:34:43 2009 From: jbates at brightok.net (Jack Bates) Date: Fri, 28 Aug 2009 10:34:43 -0500 Subject: FCCs RFC for the Definition of Broadband In-Reply-To: References: <200908281405.n7SE5dJa062396@aurora.sol.net> <4A97E786.30309@brightok.net> <20090828142920.GA56263@ussenterprise.ufp.org> <4A97F110.3020406@brightok.net> <20090828150712.GA58799@ussenterprise.ufp.org> <1C226385-2AB4-45E0-850D-C88C8A98B2A1@hopcount.ca> Message-ID: <4A97F913.7050205@brightok.net> Peter Beckman wrote: > I like that idea, except for the problem that I don't want my neighbors to > have access to the colo, or at least my feed, but I want access to my feed > to I can reboot whatever device is connected there. There would have to > be individual locked cages of some standard size so I could access and > reboot or change my router out, but could not disconnect or modify my > neighbors connection. And then there's the matter of who's paying for it. Even if initial cost is covered by the home owners in a new development project, there is maintenance costs associated with such a setup. If the ILEC is responsible, but doesn't subsidize costs by controlling all customers or billing out to the other ISPs, it creates an unfair disadvantage on the ILEC. Jack From carey at ar-ballbat.org Fri Aug 28 11:25:38 2009 From: carey at ar-ballbat.org (Andrew Carey) Date: Fri, 28 Aug 2009 09:25:38 -0700 Subject: FCCs RFC for the Definition of Broadband In-Reply-To: <34FF258A-3CA1-446C-96FA-69808276A43B@senie.com> References: <859604546CD1FF488BDB6EA94C896AFB8ABE40@racexchange.race.local> <3A89064E-4F43-4FFC-B535-B4D971CFDEF0@cisco.com> <4A9587B0.4080306@brightok.net> <4A95B736.2040409@enger.us> <4A95FB76.7090707@brightok.net> <86ocq0awx5.fsf@seastrom.com> <4A97DFEB.3090102@brightok.net> <34FF258A-3CA1-446C-96FA-69808276A43B@senie.com> Message-ID: On Aug 28, 2009, at 7:17 AM, Daniel Senie wrote: > > If you want to make the emergency phone thing a part of the > discussion, then regulations need to exist AND be enforced, and > penalties assessed, for failure to provide such during power > outages. It's not happening today, so don't expect it in the future > either. The FCC has adopted requirements for 24 hours of backup power for central offices and 8 hours for remote switches, digital loop carrier (SLCs), and cell sites among others back in 2007. However those rules have been on hold so far due to the usual wrangling. Unless Katrina fades completely from memory, some sort of requirement will likely come out, at least to maintain existing backup power equipment. Individual states may have their own preexisting regulations. Even in spite of the current state of FCC rulemaking, I've seen a number of new generators placed at cell sites. From kenny.sallee at gmail.com Fri Aug 28 11:28:08 2009 From: kenny.sallee at gmail.com (Kenny Sallee) Date: Fri, 28 Aug 2009 09:28:08 -0700 Subject: MPLS Services Message-ID: <4a80ecce0908280928i42af4129x7de956e3384ec185@mail.gmail.com> Questions for the community: from a Application Service Provider perspective - how / can one provide application access to a group of Enterprises where the ASP provider provides ASP like applications to all Enterprise customers who have multiple locations and who may or may not have overlapping addresses? Each Enterprise is it's own business and we cannot allow connectivity between each other We've struggled internally with this. MPLS and using BGP communities seems to be the solution. But I am trying to understand / think through the configuration of it from a CE and PE side perspective. Lab configs to follow but here's what I'm thinking: - From the CE side we could ask for 2 frame PVC's - each in it's own VRF on the PE side. Call 1 VRF private and 2nd VRF public. In the Private VRF advertise all CE routes between customer A for example. Each CE customer would have their own VRF on the MPLS providers network. - From the CE, In Public VRF advertise a network range we provide the clients and NAT traffic destined for the shared environment to the public range - On each CE router only permit route updates on the Public VRF for BGP communities that belong to that customer and our shared segments. Could also do this with just route filtering by ACL/prefix lists. On the Private VRF no need to filter incoming but filter outgoing to contain routing domain consistency (only send updates for CE networks) - In the Public VRF from ASP side - advertise all shared services routes. Accept all updates on Public VRF. No access to Private VRF's here. Thoughts? Thanks, Kenny From cmadams at hiwaay.net Fri Aug 28 12:31:10 2009 From: cmadams at hiwaay.net (Chris Adams) Date: Fri, 28 Aug 2009 12:31:10 -0500 Subject: FCCs RFC for the Definition of Broadband In-Reply-To: References: <200908281405.n7SE5dJa062396@aurora.sol.net> <4A97E786.30309@brightok.net> <20090828142920.GA56263@ussenterprise.ufp.org> <4A97F110.3020406@brightok.net> <20090828150712.GA58799@ussenterprise.ufp.org> Message-ID: <20090828173110.GB1426583@hiwaay.net> Once upon a time, Peter Beckman said: > And where does that fiber go to? Home runs from a central point in the > development, so any provider can hook up to any house at the street? > Deregulation means those lines should be accessible to any company for a > fee. How do you give House A Verizon and House B Cox, especially if Cox > doesn't support fiber? I have two cable TV providers available at my house. They each have their own cable plant in my neighborhood; there are two runs in each easment, two sets of pylons for access (although they mostly alternate yards, so they aren't digging at the same place when burying new wires). If you switch from one to the other, the new one runs a new wire from their nearest tap and sends somebody else around in a few weeks to "bury" (under maybe 2" of dirt) the wire. On my block, the cable lines are at the back edge of the yard, running between the houses (down the middle of the block), while the phone company wires run along the easment at the front edge of the yard with the utility (power/water/sewer) lines. Not sure why it was done that way, except maybe to keep the cable guys from digging up important stuff on a regular basis (since people switch cable a lot). However, I've seen pictures of the old power lines in New York City and such, when there were a dozen or more power companies. I sure wouldn't want to see anything like that again. IMHO, we'd be better off with a public utility that manages nothing but the cable plant, running one set of wires (a few copper pairs, a coax or two, and a couple of fiber pairs) to each house, and then selling equal access to all takers (ILEC, CLEC, cable TV, direct to ISPs, etc.). The utility would be banned from selling any kind of service themselves, and would be a non-profit; they'd charge everybody the same fees for access to the same type of cable and they'd maintain the plant and colo facilities. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From herrin-nanog at dirtside.com Fri Aug 28 12:59:46 2009 From: herrin-nanog at dirtside.com (William Herrin) Date: Fri, 28 Aug 2009 13:59:46 -0400 Subject: FCCs RFC for the Definition of Broadband In-Reply-To: <4A97DFEB.3090102@brightok.net> References: <859604546CD1FF488BDB6EA94C896AFB8ABE40@racexchange.race.local> <3A89064E-4F43-4FFC-B535-B4D971CFDEF0@cisco.com> <4A9587B0.4080306@brightok.net> <4A95B736.2040409@enger.us> <4A95FB76.7090707@brightok.net> <86ocq0awx5.fsf@seastrom.com> <4A97DFEB.3090102@brightok.net> Message-ID: <3c3e3fca0908281059s45e7e746iecfc2542b2ba885e@mail.gmail.com> On Fri, Aug 28, 2009 at 9:47 AM, Jack Bates wrote: > I've yet to hear an ILEC suggest that they not > have batteries in the NID to support the voice in power outages. The battery in my FTTH NID is completely useless. It maintains the voice side of the NID but drops the Internet side. Only, I cancelled the POTS service years ago and use a Vonage phone. So now I need a second UPS for the already-battery-backed NID or I lose phone service. Brilliant design that. IIRC, when my FTTH was installed, I was told: here's the battery. It's now your problem. When this light goes red, call the number here to BUY a new one. Folks handle batteries for their flashlights and emergency radios and cars and cordless phones. I fail to understand why asking the customer to handle one more battery would stymie them. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From cscora at apnic.net Fri Aug 28 13:12:49 2009 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 29 Aug 2009 04:12:49 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <200908281812.n7SICn9Q013669@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 29 Aug, 2009 Report Website: http://thyme.apnic.net Detailed Analysis: http://thyme.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 294090 Prefixes after maximum aggregation: 139250 Deaggregation factor: 2.11 Unique aggregates announced to Internet: 146854 Total ASes present in the Internet Routing Table: 32061 Prefixes per ASN: 9.17 Origin-only ASes present in the Internet Routing Table: 27872 Origin ASes announcing only one prefix: 13619 Transit ASes present in the Internet Routing Table: 4189 Transit-only ASes present in the Internet Routing Table: 101 Average AS path length visible in the Internet Routing Table: 3.6 Max AS path length visible: 24 Max AS path prepend of ASN (12026) 22 Prefixes from unregistered ASNs in the Routing Table: 396 Unregistered ASNs in the Routing Table: 114 Number of 32-bit ASNs allocated by the RIRs: 251 Prefixes from 32-bit ASNs in the Routing Table: 97 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 327 Number of addresses announced to Internet: 2101238976 Equivalent to 125 /8s, 62 /16s and 92 /24s Percentage of available address space announced: 56.7 Percentage of allocated address space announced: 64.9 Percentage of available address space allocated: 87.3 Percentage of address space in use by end-sites: 78.7 Total number of prefixes smaller than registry allocations: 140768 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 70329 Total APNIC prefixes after maximum aggregation: 24979 APNIC Deaggregation factor: 2.82 Prefixes being announced from the APNIC address blocks: 69774 Unique aggregates announced from the APNIC address blocks: 31721 APNIC Region origin ASes present in the Internet Routing Table: 3759 APNIC Prefixes per ASN: 18.56 APNIC Region origin ASes announcing only one prefix: 1032 APNIC Region transit ASes present in the Internet Routing Table: 575 Average APNIC Region AS path length visible: 3.6 Max APNIC Region AS path length visible: 16 Number of APNIC addresses announced to Internet: 492656320 Equivalent to 29 /8s, 93 /16s and 86 /24s Percentage of available APNIC address space announced: 83.9 APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079 APNIC Address Blocks 43/8, 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, 175/8, 180/8, 182/8, 183/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 124611 Total ARIN prefixes after maximum aggregation: 66436 ARIN Deaggregation factor: 1.88 Prefixes being announced from the ARIN address blocks: 125177 Unique aggregates announced from the ARIN address blocks: 52596 ARIN Region origin ASes present in the Internet Routing Table: 13189 ARIN Prefixes per ASN: 9.49 ARIN Region origin ASes announcing only one prefix: 5096 ARIN Region transit ASes present in the Internet Routing Table: 1301 Average ARIN Region AS path length visible: 3.3 Max ARIN Region AS path length visible: 24 Number of ARIN addresses announced to Internet: 1013478976 Equivalent to 60 /8s, 104 /16s and 118 /24s Percentage of available ARIN address space announced: 88.8 ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 53248-55295 ARIN Address Blocks 3/8, 4/8, 6/8, 7/8, 8/8, 9/8, 11/8, 12/8, 13/8, 15/8, 16/8, 17/8, 18/8, 19/8, 20/8, 21/8, 22/8, 24/8, 26/8, 28/8, 29/8, 30/8, 32/8, 33/8, 34/8, 35/8, 38/8, 40/8, 44/8, 45/8, 47/8, 48/8, 52/8, 54/8, 55/8, 56/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8, 98/8, 99/8, 108/8, 173/8, 174/8, 184/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 214/8, 215/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 67574 Total RIPE prefixes after maximum aggregation: 39857 RIPE Deaggregation factor: 1.70 Prefixes being announced from the RIPE address blocks: 67192 Unique aggregates announced from the RIPE address blocks: 45585 RIPE Region origin ASes present in the Internet Routing Table: 13438 RIPE Prefixes per ASN: 5.00 RIPE Region origin ASes announcing only one prefix: 7031 RIPE Region transit ASes present in the Internet Routing Table: 2013 Average RIPE Region AS path length visible: 4.0 Max RIPE Region AS path length visible: 21 Number of RIPE addresses announced to Internet: 499997888 Equivalent to 29 /8s, 205 /16s and 92 /24s Percentage of available RIPE address space announced: 99.3 RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-52223 RIPE Address Blocks 25/8, 51/8, 62/8, 77/8, 78/8, 79/8, 80/8, 81/8, 82/8, 83/8, 84/8, 85/8, 86/8, 87/8, 88/8, 89/8, 90/8, 91/8, 92/8, 93/8, 94/8, 95/8, 109/8, 178/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 25032 Total LACNIC prefixes after maximum aggregation: 6186 LACNIC Deaggregation factor: 4.05 Prefixes being announced from the LACNIC address blocks: 25006 Unique aggregates announced from the LACNIC address blocks: 14048 LACNIC Region origin ASes present in the Internet Routing Table: 1170 LACNIC Prefixes per ASN: 21.37 LACNIC Region origin ASes announcing only one prefix: 375 LACNIC Region transit ASes present in the Internet Routing Table: 190 Average LACNIC Region AS path length visible: 4.1 Max LACNIC Region AS path length visible: 22 Number of LACNIC addresses announced to Internet: 73430272 Equivalent to 4 /8s, 96 /16s and 117 /24s Percentage of available LACNIC address space announced: 72.9 LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247 plus ERX transfers LACNIC Address Blocks 186/8, 187/8, 189/8, 190/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 6214 Total AfriNIC prefixes after maximum aggregation: 1551 AfriNIC Deaggregation factor: 4.01 Prefixes being announced from the AfriNIC address blocks: 6614 Unique aggregates announced from the AfriNIC address blocks: 2643 AfriNIC Region origin ASes present in the Internet Routing Table: 310 AfriNIC Prefixes per ASN: 21.34 AfriNIC Region origin ASes announcing only one prefix: 85 AfriNIC Region transit ASes present in the Internet Routing Table: 66 Average AfriNIC Region AS path length visible: 3.8 Max AfriNIC Region AS path length visible: 14 Number of AfriNIC addresses announced to Internet: 20196096 Equivalent to 1 /8s, 52 /16s and 43 /24s Percentage of available AfriNIC address space announced: 60.2 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 1718 6981 425 Korea Telecom (KIX) 17488 1548 139 102 Hathway IP Over Cable Interne 4755 1228 292 140 TATA Communications formerly 9583 1092 86 531 Sify Limited 4134 999 18167 389 CHINANET-BACKBONE 18101 949 202 32 Reliance Infocom Ltd Internet 7545 821 198 99 TPG Internet Pty Ltd 9829 807 620 16 BSNL National Internet Backbo 23577 784 34 665 Korea Telecom (ATM-MPLS) 4808 762 1530 180 CNCGROUP IP network: China169 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 4181 3610 313 bellsouth.net, inc. 4323 1919 1049 390 Time Warner Telecom 1785 1733 714 138 PaeTec Communications, Inc. 7018 1488 5875 1049 AT&T WorldNet Services 20115 1474 1475 675 Charter Communications 6478 1385 280 271 AT&T Worldnet Services 2386 1296 657 941 AT&T Data Communications Serv 3356 1216 10980 441 Level 3 Communications, LLC 11492 1112 208 12 Cable One 22773 1090 2604 66 Cox Communications, Inc. Complete listing at http://thyme.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 30890 485 92 195 Evolva Telecom 12479 476 578 6 Uni2 Autonomous System 3292 457 1905 394 TDC Tele Danmark 702 427 1837 344 UUNET - Commercial IP service 35805 381 40 5 United Telecom of Georgia 9198 367 138 12 Kazakhtelecom Data Network Ad 3320 352 7067 303 Deutsche Telekom AG 3301 345 1412 309 TeliaNet Sweden 3215 344 3081 109 France Telecom Transpac 8866 340 109 20 Bulgarian Telecommunication C Complete listing at http://thyme.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 8151 1474 2898 241 UniNet S.A. de C.V. 10620 990 223 101 TVCABLE BOGOTA 28573 669 603 60 NET Servicos de Comunicao S.A 7303 632 334 97 Telecom Argentina Stet-France 22047 542 302 14 VTR PUNTO NET S.A. 11830 475 310 65 Instituto Costarricense de El 11172 443 99 70 Servicios Alestra S.A de C.V 6471 421 96 31 ENTEL CHILE S.A. 7738 416 858 29 Telecomunicacoes da Bahia S.A 3816 395 191 78 Empresa Nacional de Telecomun Complete listing at http://thyme.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 8452 1002 188 7 TEDATA 24863 920 92 52 LINKdotNET AS number 20858 320 34 6 EgyNet 3741 274 856 235 The Internet Solution 2018 201 180 142 Tertiary Education Network 6713 175 166 16 Itissalat Al-MAGHRIB 29571 143 14 6 Ci Telecom Autonomous system 33783 131 10 17 EEPAD TISP TELECOM & INTERNET 24835 130 46 9 RAYA Telecom - Egypt 5536 122 8 13 Internet Egypt Network Complete listing at http://thyme.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 4181 3610 313 bellsouth.net, inc. 4323 1919 1049 390 Time Warner Telecom 1785 1733 714 138 PaeTec Communications, Inc. 4766 1718 6981 425 Korea Telecom (KIX) 17488 1548 139 102 Hathway IP Over Cable Interne 7018 1488 5875 1049 AT&T WorldNet Services 8151 1474 2898 241 UniNet S.A. de C.V. 20115 1474 1475 675 Charter Communications 6478 1385 280 271 AT&T Worldnet Services 2386 1296 657 941 AT&T Data Communications Serv Complete listing at http://thyme.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 1785 1733 1595 PaeTec Communications, Inc. 4323 1919 1529 Time Warner Telecom 17488 1548 1446 Hathway IP Over Cable Interne 4766 1718 1293 Korea Telecom (KIX) 8151 1474 1233 UniNet S.A. de C.V. 6478 1385 1114 AT&T Worldnet Services 11492 1112 1100 Cable One 4755 1228 1088 TATA Communications formerly 18566 1062 1052 Covad Communications 22773 1090 1024 Cox Communications, Inc. Complete listing at http://thyme.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 16927 UNALLOCATED 12.0.252.0/23 7018 AT&T WorldNet Servic 15132 UNALLOCATED 12.9.150.0/24 7018 AT&T WorldNet Servic 32567 UNALLOCATED 12.14.170.0/24 7018 AT&T WorldNet Servic 13746 UNALLOCATED 12.24.56.0/24 7018 AT&T WorldNet Servic 32567 UNALLOCATED 12.25.107.0/24 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.152.0/24 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.154.0/23 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.159.0/24 7018 AT&T WorldNet Servic 32326 UNALLOCATED 12.40.49.0/24 7018 AT&T WorldNet Servic 25639 UNALLOCATED 12.41.169.0/24 7018 AT&T WorldNet Servic Complete listing at http://thyme.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 24.225.128.0/17 36377 PATRIOT MEDIA AND COMMUNICATI 41.223.92.0/22 36936 >>UNKNOWN<< 41.223.176.0/22 36981 >>UNKNOWN<< 41.223.189.0/24 26452 Local Communications Networks 43.245.0.0/16 7502 Internetwork Kyoto 43.245.96.0/20 7502 Internetwork Kyoto 43.245.112.0/20 7502 Internetwork Kyoto 43.245.192.0/20 7502 Internetwork Kyoto 43.245.208.0/20 7502 Internetwork Kyoto 43.245.224.0/20 7502 Internetwork Kyoto 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:25 /11:62 /12:168 /13:351 /14:624 /15:1178 /16:10639 /17:4812 /18:8366 /19:17327 /20:20674 /21:20700 /22:26669 /23:26392 /24:153358 /25:921 /26:1041 /27:580 /28:150 /29:8 /30:7 /31:1 /32:8 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 6389 2709 4181 bellsouth.net, inc. 4766 1405 1718 Korea Telecom (KIX) 17488 1294 1548 Hathway IP Over Cable Interne 1785 1204 1733 PaeTec Communications, Inc. 18566 1043 1062 Covad Communications 11492 1039 1112 Cable One 4323 965 1919 Time Warner Telecom 9583 944 1092 Sify Limited 8452 926 1002 TEDATA 10620 897 990 TVCABLE BOGOTA Complete listing at http://thyme.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 4:14 8:214 12:2132 13:7 15:21 16:3 17:5 20:35 24:1124 32:52 34:2 38:595 40:97 41:1754 43:1 44:2 47:8 52:6 55:2 56:2 57:25 58:624 59:610 60:460 61:972 62:1102 63:2012 64:3658 65:2400 66:3425 67:1742 68:882 69:2763 70:556 71:162 72:1664 73:2 74:1733 75:179 76:317 77:858 78:559 79:375 80:923 81:833 82:602 83:427 84:630 85:1065 86:377 87:670 88:371 89:1463 90:49 91:2504 92:399 93:1118 94:1183 95:1082 96:166 97:267 98:276 99:30 110:180 111:386 112:124 113:149 114:240 115:301 116:1132 117:566 118:342 119:768 120:121 121:650 122:1248 123:755 124:1059 125:1345 128:223 129:219 130:129 131:417 132:75 133:9 134:174 135:42 136:225 137:160 138:169 139:85 140:445 141:124 142:385 143:341 144:389 145:49 146:387 147:156 148:530 149:220 150:207 151:192 152:208 153:152 154:2 155:274 156:167 157:301 158:113 159:350 160:291 161:164 162:270 163:164 164:276 165:524 166:471 167:362 168:701 169:162 170:479 171:41 172:2 173:393 174:322 175:1 178:1 180:8 182:1 186:127 187:152 188:590 189:588 190:2877 192:5783 193:4248 194:3275 195:2706 196:1125 198:3551 199:3360 200:5130 201:1302 202:7764 203:8273 204:3903 205:2191 206:2384 207:2743 208:3939 209:3409 210:2518 211:1106 212:1606 213:1654 214:131 215:29 216:4310 217:1352 218:408 219:422 220:1107 221:463 222:323 End of report From carlos at race.com Fri Aug 28 13:15:57 2009 From: carlos at race.com (Carlos Alcantar) Date: Fri, 28 Aug 2009 11:15:57 -0700 Subject: FCCs RFC for the Definition of Broadband Message-ID: <859604546CD1FF488BDB6EA94C896AFB8ABEEA@racexchange.race.local> The dropping of internet is done on purpose to preserve the battery for the pots when ac power is lost. This is an actual setting in just about all manufacturers of ftth equipment. You'll probably have a hard time to get them to change the profile on the equipment tho but it is possible. Carlos Alcantar Race Telecommunications, Inc. 101 Haskins Way South San Francisco, CA 94080 P: 650.649.3550 F: 650.649.3551 -----Original Message----- From: William Herrin [mailto:herrin-nanog at dirtside.com] Sent: Friday, August 28, 2009 11:00 AM To: Jack Bates Cc: nanog at nanog.org Subject: Re: FCCs RFC for the Definition of Broadband On Fri, Aug 28, 2009 at 9:47 AM, Jack Bates wrote: > I've yet to hear an ILEC suggest that they not > have batteries in the NID to support the voice in power outages. The battery in my FTTH NID is completely useless. It maintains the voice side of the NID but drops the Internet side. Only, I cancelled the POTS service years ago and use a Vonage phone. So now I need a second UPS for the already-battery-backed NID or I lose phone service. Brilliant design that. IIRC, when my FTTH was installed, I was told: here's the battery. It's now your problem. When this light goes red, call the number here to BUY a new one. Folks handle batteries for their flashlights and emergency radios and cars and cordless phones. I fail to understand why asking the customer to handle one more battery would stymie them. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From ip at ioshints.info Fri Aug 28 13:52:21 2009 From: ip at ioshints.info (Ivan Pepelnjak) Date: Fri, 28 Aug 2009 20:52:21 +0200 Subject: MPLS Services In-Reply-To: <4a80ecce0908280928i42af4129x7de956e3384ec185@mail.gmail.com> References: <4a80ecce0908280928i42af4129x7de956e3384ec185@mail.gmail.com> Message-ID: <003c01ca2810$ad8bf9a0$0a00000a@nil.si> This might give you some ideas (also solves the overlapping customer address problem): http://www.nil.com/ipcorner/FlexExtraImplement/ Ivan http://www.ioshints.info/about http://blog.ioshints.info/ > -----Original Message----- > From: Kenny Sallee [mailto:kenny.sallee at gmail.com] > Sent: Friday, August 28, 2009 6:28 PM > To: nanog at nanog.org > Subject: MPLS Services > > Questions for the community: from a Application Service > Provider perspective - how / can one provide application > access to a group of Enterprises where the ASP provider > provides ASP like applications to all Enterprise customers > who have multiple locations and who may or may not have > overlapping addresses? Each Enterprise is it's own business > and we cannot allow connectivity between each other We've > struggled internally with this. MPLS and using BGP > communities seems to be the solution. But I am trying to > understand / think through the configuration of it from a CE > and PE side perspective. Lab configs to follow but here's > what I'm thinking: > > - From the CE side we could ask for 2 frame PVC's - each in > it's own VRF on the PE side. Call 1 VRF private and 2nd VRF > public. In the Private VRF advertise all CE routes between > customer A for example. Each CE customer would have their > own VRF on the MPLS providers network. > > - From the CE, In Public VRF advertise a network range we > provide the clients and NAT traffic destined for the shared > environment to the public range > > - On each CE router only permit route updates on the Public > VRF for BGP communities that belong to that customer and our > shared segments. Could also do this with just route > filtering by ACL/prefix lists. On the Private VRF no need to > filter incoming but filter outgoing to contain routing domain > consistency (only send updates for CE networks) > > - In the Public VRF from ASP side - advertise all shared > services routes. > Accept all updates on Public VRF. No access to Private VRF's here. > > Thoughts? > Thanks, > Kenny > > From herrin-nanog at dirtside.com Fri Aug 28 14:08:05 2009 From: herrin-nanog at dirtside.com (William Herrin) Date: Fri, 28 Aug 2009 15:08:05 -0400 Subject: FCCs RFC for the Definition of Broadband In-Reply-To: <859604546CD1FF488BDB6EA94C896AFB8ABEEA@racexchange.race.local> References: <859604546CD1FF488BDB6EA94C896AFB8ABEEA@racexchange.race.local> Message-ID: <3c3e3fca0908281208s2c78de03vb8603ed949c6518b@mail.gmail.com> On Fri, Aug 28, 2009 at 2:15 PM, Carlos Alcantar wrote: > The dropping of internet is done on purpose to preserve the battery for > the pots when ac power is lost. ?This is an actual setting in just about > all manufacturers of ftth equipment. ?You'll probably have a hard time > to get them to change the profile on the equipment tho but it is > possible. Hi Carlos, I realize why it's done. I merely point out that there are common configurations in which the having the FTTH NID power the POTS circuitry and drop the Internet circuitry is exactly the opposite of correct. Where instead of preserving access to emergency responders, it is intentionally designed to cut that access. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From walter.keen at rainierconnect.net Fri Aug 28 14:10:35 2009 From: walter.keen at rainierconnect.net (Walter Keen) Date: Fri, 28 Aug 2009 12:10:35 -0700 Subject: FCCs RFC for the Definition of Broadband In-Reply-To: <3c3e3fca0908281208s2c78de03vb8603ed949c6518b@mail.gmail.com> References: <859604546CD1FF488BDB6EA94C896AFB8ABEEA@racexchange.race.local> <3c3e3fca0908281208s2c78de03vb8603ed949c6518b@mail.gmail.com> Message-ID: <4A982BAB.4050707@rainierconnect.net> I agree, while the majority of government and service providers have the opinion that POTS is a lifeline service, and ethernet is not, I disagree. I know the service provider I work for is starting to change their views on this, but it will take time for the general populous of managers, etc throughout the nation to realize this. William Herrin wrote: On Fri, Aug 28, 2009 at 2:15 PM, Carlos Alcantar[1] wrote: The dropping of internet is done on purpose to preserve the battery for the pots when ac power is lost. This is an actual setting in just about all manufacturers of ftth equipment. You'll probably have a hard time to get them to change the profile on the equipment tho but it is possible. Hi Carlos, I realize why it's done. I merely point out that there are common configurations in which the having the FTTH NID power the POTS circuitry and drop the Internet circuitry is exactly the opposite of correct. Where instead of preserving access to emergency responders, it is intentionally designed to cut that access. Regards, Bill Herrin -- Walter Keen Network Technician Rainier Connect (o) 360-832-4024 (c) 253-302-0194 References 1. mailto:carlos at race.com From luke.marrott at gmail.com Fri Aug 28 14:17:14 2009 From: luke.marrott at gmail.com (Luke Marrott) Date: Fri, 28 Aug 2009 13:17:14 -0600 Subject: FCCs RFC for the Definition of Broadband In-Reply-To: <4A982BAB.4050707@rainierconnect.net> References: <859604546CD1FF488BDB6EA94C896AFB8ABEEA@racexchange.race.local> <3c3e3fca0908281208s2c78de03vb8603ed949c6518b@mail.gmail.com> <4A982BAB.4050707@rainierconnect.net> Message-ID: <4a9edb810908281217q5d34b04q189d588bf42e410@mail.gmail.com> One thing that I think service providers take into account is that while many people still have phones that do not have their own power source, battery backups for home computers aren't that common as a general rule. There is no need to have battery backup for internet services if the computer doesn't have power. :Luke On Fri, Aug 28, 2009 at 1:10 PM, Walter Keen wrote: > I agree, while the majority of government and service providers have > the opinion that POTS is a lifeline service, and ethernet is not, I > disagree. I know the service provider I work for is starting to change > their views on this, but it will take time for the general populous of > managers, etc throughout the nation to realize this. > William Herrin wrote: > > On Fri, Aug 28, 2009 at 2:15 PM, Carlos Alcantar[1] > wrote: > > The dropping of internet is done on purpose to preserve the battery for > the pots when ac power is lost. This is an actual setting in just about > all manufacturers of ftth equipment. You'll probably have a hard time > to get them to change the profile on the equipment tho but it is > possible. > > Hi Carlos, > > I realize why it's done. I merely point out that there are common > configurations in which the having the FTTH NID power the POTS > circuitry and drop the Internet circuitry is exactly the opposite of > correct. Where instead of preserving access to emergency responders, > it is intentionally designed to cut that access. > > Regards, > Bill Herrin > > > > > -- > > > Walter Keen > Network Technician > Rainier Connect > (o) 360-832-4024 > (c) 253-302-0194 > > References > > 1. mailto:carlos at race.com > -- :Luke Marrott From tme at americafree.tv Fri Aug 28 14:36:24 2009 From: tme at americafree.tv (Marshall Eubanks) Date: Fri, 28 Aug 2009 15:36:24 -0400 Subject: FCCs RFC for the Definition of Broadband In-Reply-To: <4a9edb810908281217q5d34b04q189d588bf42e410@mail.gmail.com> References: <859604546CD1FF488BDB6EA94C896AFB8ABEEA@racexchange.race.local> <3c3e3fca0908281208s2c78de03vb8603ed949c6518b@mail.gmail.com> <4A982BAB.4050707@rainierconnect.net> <4a9edb810908281217q5d34b04q189d588bf42e410@mail.gmail.com> Message-ID: On Aug 28, 2009, at 3:17 PM, Luke Marrott wrote: > One thing that I think service providers take into account is that > while > many people still have phones that do not have their own power source, > battery backups for home computers aren't that common as a general > rule. > There is no need to have battery backup for internet services if the > computer doesn't have power. Most people I know use laptops as their primary computers. These most definitely have battery backup. Regards Marshall > > :Luke > > On Fri, Aug 28, 2009 at 1:10 PM, Walter Keen > wrote: > >> I agree, while the majority of government and service providers have >> the opinion that POTS is a lifeline service, and ethernet is not, I >> disagree. I know the service provider I work for is starting to >> change >> their views on this, but it will take time for the general >> populous of >> managers, etc throughout the nation to realize this. >> William Herrin wrote: >> >> On Fri, Aug 28, 2009 at 2:15 PM, Carlos Alcantar[1] >> wrote: >> >> The dropping of internet is done on purpose to preserve the battery >> for >> the pots when ac power is lost. This is an actual setting in just >> about >> all manufacturers of ftth equipment. You'll probably have a hard >> time >> to get them to change the profile on the equipment tho but it is >> possible. >> >> Hi Carlos, >> >> I realize why it's done. I merely point out that there are common >> configurations in which the having the FTTH NID power the POTS >> circuitry and drop the Internet circuitry is exactly the opposite of >> correct. Where instead of preserving access to emergency responders, >> it is intentionally designed to cut that access. >> >> Regards, >> Bill Herrin >> >> >> >> >> -- >> >> >> Walter Keen >> Network Technician >> Rainier Connect >> (o) 360-832-4024 >> (c) 253-302-0194 >> >> References >> >> 1. mailto:carlos at race.com >> > > > > -- > :Luke Marrott > From herrin-nanog at dirtside.com Fri Aug 28 14:36:47 2009 From: herrin-nanog at dirtside.com (William Herrin) Date: Fri, 28 Aug 2009 15:36:47 -0400 Subject: FCCs RFC for the Definition of Broadband In-Reply-To: <4a9edb810908281217q5d34b04q189d588bf42e410@mail.gmail.com> References: <859604546CD1FF488BDB6EA94C896AFB8ABEEA@racexchange.race.local> <3c3e3fca0908281208s2c78de03vb8603ed949c6518b@mail.gmail.com> <4A982BAB.4050707@rainierconnect.net> <4a9edb810908281217q5d34b04q189d588bf42e410@mail.gmail.com> Message-ID: <3c3e3fca0908281236k7855126bp524b9da488d5da79@mail.gmail.com> On Fri, Aug 28, 2009 at 3:17 PM, Luke Marrott wrote: >> Bill Herrin: >> I realize why it's done. I merely point out that there are common >> configurations in which the having the FTTH NID power the POTS >> circuitry and drop the Internet circuitry is exactly the opposite of >> correct. Where instead of preserving access to emergency responders, >> it is intentionally designed to cut that access. > There is no need to have battery backup for internet services if the > computer doesn't have power. You would suggest treating the Ethernet and POTS ports the same for power backup purposes until the ethernet port drops its carrier for 60 seconds or so? Maybe do the same for the POTs ports wrt detecting whether any phones are attached? Nah, that would make far too much sense; there must be something fatally wrong with the idea. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From jay at west.net Fri Aug 28 14:46:22 2009 From: jay at west.net (Jay Hennigan) Date: Fri, 28 Aug 2009 12:46:22 -0700 Subject: FCCs RFC for the Definition of Broadband In-Reply-To: <3c3e3fca0908281236k7855126bp524b9da488d5da79@mail.gmail.com> References: <859604546CD1FF488BDB6EA94C896AFB8ABEEA@racexchange.race.local> <3c3e3fca0908281208s2c78de03vb8603ed949c6518b@mail.gmail.com> <4A982BAB.4050707@rainierconnect.net> <4a9edb810908281217q5d34b04q189d588bf42e410@mail.gmail.com> <3c3e3fca0908281236k7855126bp524b9da488d5da79@mail.gmail.com> Message-ID: <4A98340E.1070802@west.net> William Herrin wrote: > You would suggest treating the Ethernet and POTS ports the same for > power backup purposes until the ethernet port drops its carrier for 60 > seconds or so? Maybe do the same for the POTs ports wrt detecting > whether any phones are attached? Nah, that would make far too much > sense; there must be something fatally wrong with the idea. Detecting whether an idle phone is attached to a POTS port isn't exactly trivial. This is more true now with modern phones that don't have mechanical ringers. Keeping the ethernet port up on battery if there is link makes sense. For that matter a "Wake-on-LAN" style polling to power it for a second every 30 to detect carrier would be even better. -- 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 dhetzel at gmail.com Fri Aug 28 14:57:58 2009 From: dhetzel at gmail.com (Dorn Hetzel) Date: Fri, 28 Aug 2009 15:57:58 -0400 Subject: FCCs RFC for the Definition of Broadband In-Reply-To: <4A98340E.1070802@west.net> References: <859604546CD1FF488BDB6EA94C896AFB8ABEEA@racexchange.race.local> <3c3e3fca0908281208s2c78de03vb8603ed949c6518b@mail.gmail.com> <4A982BAB.4050707@rainierconnect.net> <4a9edb810908281217q5d34b04q189d588bf42e410@mail.gmail.com> <3c3e3fca0908281236k7855126bp524b9da488d5da79@mail.gmail.com> <4A98340E.1070802@west.net> Message-ID: <7db2dcf90908281257g3ac002d3t4ea7f07a19072d80@mail.gmail.com> If all of the POTS attached phones on the "emergency" circuit are on-hook and there are no incoming calls, then not much power should be required. If a phone goes off-hook it should be much easier to detect. If the network facing side is up it can power up the POTS circuit when an incoming call is detected. Carrier detection for ethernet port power sounds reasonable. For the best of both world, maybe someone needs to build a "black wall phone" that is also the NID and integrates rechargeable D-cells (so flashlight batteries can always be swapped in if the rechargeables are dead). The box would then, of course, know whether it was on or off-hook and could even have a nice display for fiber-carrier status etc... On Fri, Aug 28, 2009 at 3:46 PM, Jay Hennigan wrote: > William Herrin wrote: > > You would suggest treating the Ethernet and POTS ports the same for >> power backup purposes until the ethernet port drops its carrier for 60 >> seconds or so? Maybe do the same for the POTs ports wrt detecting >> whether any phones are attached? Nah, that would make far too much >> sense; there must be something fatally wrong with the idea. >> > > Detecting whether an idle phone is attached to a POTS port isn't exactly > trivial. This is more true now with modern phones that don't have > mechanical ringers. > > Keeping the ethernet port up on battery if there is link makes sense. For > that matter a "Wake-on-LAN" style polling to power it for a second every 30 > to detect carrier would be even better. > > -- > 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 jbates at brightok.net Fri Aug 28 14:57:41 2009 From: jbates at brightok.net (Jack Bates) Date: Fri, 28 Aug 2009 14:57:41 -0500 Subject: FCCs RFC for the Definition of Broadband In-Reply-To: <4A982BAB.4050707@rainierconnect.net> References: <859604546CD1FF488BDB6EA94C896AFB8ABEEA@racexchange.race.local> <3c3e3fca0908281208s2c78de03vb8603ed949c6518b@mail.gmail.com> <4A982BAB.4050707@rainierconnect.net> Message-ID: <4A9836B5.7090504@brightok.net> Walter Keen wrote: > I agree, while the majority of government and service providers have > the opinion that POTS is a lifeline service, and ethernet is not, I > disagree. I know the service provider I work for is starting to change > their views on this, but it will take time for the general populous of > managers, etc throughout the nation to realize this. Since no one is mentioning it, the batteries often can only power POTS for 8 hours. If ethernet is left on, it drastically drops the runtime. This is not acceptable, yet I haven't seen a good setup that can provide 8+ hours for both. Of course, it's been a non-issue for me. We run weeks without power just fine with FTTC. Jack From Skywing at valhallalegends.com Fri Aug 28 15:11:59 2009 From: Skywing at valhallalegends.com (Skywing) Date: Fri, 28 Aug 2009 15:11:59 -0500 Subject: FCCs RFC for the Definition of Broadband Message-ID: <982D8D05B6407A49AD506E6C3AC8E7D60173704BDD38@caralain.haven.nynaeve.net> And how many of them also have a "cable/DSL wireless router" thingie plugged into the wall in between? (Sure, you can unplug it -- if you know to do that, without being able to phone anyone to be told to do so...) - S -----Original Message----- From: Marshall Eubanks Sent: Friday, August 28, 2009 12:36 To: Luke Marrott Cc: nanog at nanog.org Subject: Re: FCCs RFC for the Definition of Broadband On Aug 28, 2009, at 3:17 PM, Luke Marrott wrote: > One thing that I think service providers take into account is that > while > many people still have phones that do not have their own power source, > battery backups for home computers aren't that common as a general > rule. > There is no need to have battery backup for internet services if the > computer doesn't have power. Most people I know use laptops as their primary computers. These most definitely have battery backup. Regards Marshall > > :Luke > > On Fri, Aug 28, 2009 at 1:10 PM, Walter Keen > wrote: > >> I agree, while the majority of government and service providers have >> the opinion that POTS is a lifeline service, and ethernet is not, I >> disagree. I know the service provider I work for is starting to >> change >> their views on this, but it will take time for the general >> populous of >> managers, etc throughout the nation to realize this. >> William Herrin wrote: >> >> On Fri, Aug 28, 2009 at 2:15 PM, Carlos Alcantar[1] >> wrote: >> >> The dropping of internet is done on purpose to preserve the battery >> for >> the pots when ac power is lost. This is an actual setting in just >> about >> all manufacturers of ftth equipment. You'll probably have a hard >> time >> to get them to change the profile on the equipment tho but it is >> possible. >> >> Hi Carlos, >> >> I realize why it's done. I merely point out that there are common >> configurations in which the having the FTTH NID power the POTS >> circuitry and drop the Internet circuitry is exactly the opposite of >> correct. Where instead of preserving access to emergency responders, >> it is intentionally designed to cut that access. >> >> Regards, >> Bill Herrin >> >> >> >> >> -- >> >> >> Walter Keen >> Network Technician >> Rainier Connect >> (o) 360-832-4024 >> (c) 253-302-0194 >> >> References >> >> 1. mailto:carlos at race.com >> > > > > -- > :Luke Marrott > From dhetzel at gmail.com Fri Aug 28 15:17:48 2009 From: dhetzel at gmail.com (Dorn Hetzel) Date: Fri, 28 Aug 2009 16:17:48 -0400 Subject: FCCs RFC for the Definition of Broadband In-Reply-To: <3c3e3fca0908281059s45e7e746iecfc2542b2ba885e@mail.gmail.com> References: <859604546CD1FF488BDB6EA94C896AFB8ABE40@racexchange.race.local> <3A89064E-4F43-4FFC-B535-B4D971CFDEF0@cisco.com> <4A9587B0.4080306@brightok.net> <4A95B736.2040409@enger.us> <4A95FB76.7090707@brightok.net> <86ocq0awx5.fsf@seastrom.com> <4A97DFEB.3090102@brightok.net> <3c3e3fca0908281059s45e7e746iecfc2542b2ba885e@mail.gmail.com> Message-ID: <7db2dcf90908281317i6035670cgf8050d2e288b50f1@mail.gmail.com> Maybe an NID with an integrated phone and a hand-crank-generator so you can always crank it to make a call :) On Fri, Aug 28, 2009 at 1:59 PM, William Herrin wrote: > On Fri, Aug 28, 2009 at 9:47 AM, Jack Bates wrote: > > I've yet to hear an ILEC suggest that they not > > have batteries in the NID to support the voice in power outages. > > The battery in my FTTH NID is completely useless. It maintains the > voice side of the NID but drops the Internet side. Only, I cancelled > the POTS service years ago and use a Vonage phone. So now I need a > second UPS for the already-battery-backed NID or I lose phone service. > Brilliant design that. > > IIRC, when my FTTH was installed, I was told: here's the battery. It's > now your problem. When this light goes red, call the number here to > BUY a new one. > > Folks handle batteries for their flashlights and emergency radios and > cars and cordless phones. I fail to understand why asking the customer > to handle one more battery would stymie them. > > Regards, > Bill Herrin > > > > -- > William D. Herrin ................ herrin at dirtside.com bill at herrin.us > 3005 Crane Dr. ...................... Web: > Falls Church, VA 22042-3004 > > From jbates at brightok.net Fri Aug 28 15:24:53 2009 From: jbates at brightok.net (Jack Bates) Date: Fri, 28 Aug 2009 15:24:53 -0500 Subject: FCCs RFC for the Definition of Broadband In-Reply-To: <7db2dcf90908281317i6035670cgf8050d2e288b50f1@mail.gmail.com> References: <859604546CD1FF488BDB6EA94C896AFB8ABE40@racexchange.race.local> <3A89064E-4F43-4FFC-B535-B4D971CFDEF0@cisco.com> <4A9587B0.4080306@brightok.net> <4A95B736.2040409@enger.us> <4A95FB76.7090707@brightok.net> <86ocq0awx5.fsf@seastrom.com> <4A97DFEB.3090102@brightok.net> <3c3e3fca0908281059s45e7e746iecfc2542b2ba885e@mail.gmail.com> <7db2dcf90908281317i6035670cgf8050d2e288b50f1@mail.gmail.com> Message-ID: <4A983D15.8090603@brightok.net> Dorn Hetzel wrote: > Maybe an NID with an integrated phone and a hand-crank-generator so you > can always crank it to make a call :) Oh, man. If only I were old enough for that to be nostalgic. ;) Jack From kenny.sallee at gmail.com Fri Aug 28 15:27:06 2009 From: kenny.sallee at gmail.com (Kenny Sallee) Date: Fri, 28 Aug 2009 13:27:06 -0700 Subject: MPLS Services In-Reply-To: <003c01ca2810$ad8bf9a0$0a00000a@nil.si> References: <4a80ecce0908280928i42af4129x7de956e3384ec185@mail.gmail.com> <003c01ca2810$ad8bf9a0$0a00000a@nil.si> Message-ID: <4a80ecce0908281327p1b4f1d2cpe18d8d04915c0005@mail.gmail.com> On Fri, Aug 28, 2009 at 11:52 AM, Ivan Pepelnjak wrote: > This might give you some ideas (also solves the overlapping customer > address > problem): > > http://www.nil.com/ipcorner/FlexExtraImplement/ > > Ivan > > http://www.ioshints.info/about > http://blog.ioshints.info/ > That looks very interesting. But it assumes we have a physical interface in the core for every remote customer correct? I guess that can be accomplished via GRE tunnels over a providers MPLS cloud. What about a MPLS provider being the transport where the exCore has a single interface to that provider? That's what I *think* we need to do and why I consider NAT and advertising of a public segment from each customer and using BGP communities to keep each customer from 'knowing' about each other. So in the core router(s) we'd only have unique IP's, each Customer could have a single MPLS drop that reaches our shared segments as well as their internal segments. From kenny.sallee at gmail.com Fri Aug 28 15:31:58 2009 From: kenny.sallee at gmail.com (Kenny Sallee) Date: Fri, 28 Aug 2009 13:31:58 -0700 Subject: MPLS Services In-Reply-To: <4a80ecce0908281327p1b4f1d2cpe18d8d04915c0005@mail.gmail.com> References: <4a80ecce0908280928i42af4129x7de956e3384ec185@mail.gmail.com> <003c01ca2810$ad8bf9a0$0a00000a@nil.si> <4a80ecce0908281327p1b4f1d2cpe18d8d04915c0005@mail.gmail.com> Message-ID: <4a80ecce0908281331h3647c224gf8ca1226890db4e9@mail.gmail.com> On Fri, Aug 28, 2009 at 1:27 PM, Kenny Sallee wrote: > On Fri, Aug 28, 2009 at 11:52 AM, Ivan Pepelnjak wrote: > >> This might give you some ideas (also solves the overlapping customer >> address >> problem): >> >> http://www.nil.com/ipcorner/FlexExtraImplement/ >> >> Ivan >> >> http://www.ioshints.info/about >> http://blog.ioshints.info/ >> > BTW - that was an awesome write up - thanks for sharing From David_Hiers at adp.com Fri Aug 28 16:51:39 2009 From: David_Hiers at adp.com (Hiers, David) Date: Fri, 28 Aug 2009 16:51:39 -0500 Subject: Ready to get your federal computer license? In-Reply-To: <81CDFC77FB2DC54DB875D4F8FFC36CE00A923B797E@DSMAIL2HE.ds.ad.adp.com> References: <81CDFC77FB2DC54DB875D4F8FFC36CE00A923B797E@DSMAIL2HE.ds.ad.adp.com> Message-ID: <81CDFC77FB2DC54DB875D4F8FFC36CE00B7A593500@DSMAIL2HE.ds.ad.adp.com> Governments already license stock brokers, pilots, commercial drivers, accountants, engineers, all sorts of people whose mistakes can be measured in the loss of hundreds of lives and millions of dollars. http://sip-trunking.tmcnet.com/topics/security/articles/63218-bill-give-president-emergency-power-internet-raises-concerns.htm Good times.... David Hiers CCIE (R/S, V), CISSP ADP Dealer Services 2525 SW 1st Ave. Suite 300W Portland, OR 97201 o: 503-205-4467 f: 503-402-3277 This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. From cidr-report at potaroo.net Fri Aug 28 17:00:02 2009 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 28 Aug 2009 22:00:02 GMT Subject: BGP Update Report Message-ID: <200908282200.n7SM02RI011866@wattle.apnic.net> BGP Update Report Interval: 20-Aug-09 -to- 27-Aug-09 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS9198 89505 4.2% 260.9 -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration 2 - AS4961 78920 3.7% 1337.6 -- DISC-AS-KR Daewoo Information System 3 - AS9767 50782 2.4% 1372.5 -- DONGBUIT-AS-KR Dongbulife Insurance co.,LTD 4 - AS23716 46768 2.2% 1670.3 -- CHANGWON23716-AS-KR Changwon College 5 - AS30890 36929 1.7% 76.1 -- EVOLVA Evolva Telecom / iLink Telecom 6 - AS18157 33964 1.6% 1358.6 -- CHUNGJU-AS-KR chungju university 7 - AS9956 31164 1.5% 1355.0 -- KONGJU-AS kongju national university 8 - AS9459 30310 1.4% 1317.8 -- ASKONKUK Konkuk University 9 - AS9686 29346 1.4% 1333.9 -- SKKUNET-AS SungKyunKwan University (SKKU) 10 - AS10159 22554 1.1% 1326.7 -- HAUNET-AS-KR HANKUK Aviation University 11 - AS33783 21632 1.0% 153.4 -- EEPAD 12 - AS9530 21240 1.0% 1327.5 -- SHINSEGAE-AS SHINSEGAE I&C Co., Ltd. 13 - AS9628 18322 0.9% 964.3 -- SSEM-AS-KR Seoul Education Science Research Institute 14 - AS17865 16830 0.8% 1683.0 -- SCOURT-AS-KR Supreme Court of Korea 15 - AS9868 16200 0.8% 1350.0 -- CUTH-AS Catholic University of DAEGU 16 - AS10088 14846 0.7% 1349.6 -- KWANGWOON-UNIV-AS-AP KWANGWOON University in Seoul, Korea 17 - AS9523 14644 0.7% 1627.1 -- MOKWON-AS-KR Mokwon University 18 - AS23561 14526 0.7% 1614.0 -- YONGINUNIVERSITY-AS-KR Yongin University 19 - AS18026 13874 0.7% 1387.4 -- CHEJU-AS-KR Cheju University 20 - AS35805 13857 0.7% 36.4 -- UTG-AS United Telecom AS TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS40060 2466 0.1% 2466.0 -- AAAWI - AAA Wireless, Inc. 2 - AS5050 5998 0.3% 1999.3 -- PSC-EXT - Pittsburgh Supercomputing Center 3 - AS17865 16830 0.8% 1683.0 -- SCOURT-AS-KR Supreme Court of Korea 4 - AS18303 1672 0.1% 1672.0 -- SMARTRO-AS-KR SMARTRO 5 - AS23716 46768 2.2% 1670.3 -- CHANGWON23716-AS-KR Changwon College 6 - AS10053 6660 0.3% 1665.0 -- AYTCNET-AS Anyang Technical College 7 - AS9570 3326 0.2% 1663.0 -- DAEDONG-AS-KR Daedong College 8 - AS38427 9936 0.5% 1656.0 -- STXIDC-AS-KR FORCETEC Co., LTD. 9 - AS18315 4942 0.2% 1647.3 -- SORABOLNET-AS-KR Sorabol College 10 - AS38683 1642 0.1% 1642.0 -- NEC-AS-KR National Electoin Commission 11 - AS9490 1634 0.1% 1634.0 -- NIS-AS National Intelligence Service 12 - AS4790 3264 0.1% 1632.0 -- CHOSUN-AS-KR DIGITAL CHOSUN 13 - AS9523 14644 0.7% 1627.1 -- MOKWON-AS-KR Mokwon University 14 - AS23561 14526 0.7% 1614.0 -- YONGINUNIVERSITY-AS-KR Yongin University 15 - AS9846 1610 0.1% 1610.0 -- FIRSTDATA-AS-KR FDIK 16 - AS4665 1602 0.1% 1602.0 -- YONSEI-AS-KR Yonsei University 17 - AS17600 1446 0.1% 1446.0 -- ENVICO-AS-KR Korea Environment & Resources Corporation 18 - AS9969 1412 0.1% 1412.0 -- WMS-NET-AS-KR KOREA RESOURCES RECOVERY AND REUTILIZATION CORPORATION 19 - AS9974 6970 0.3% 1394.0 -- KRA-AS-KR Korea Racing Association 20 - AS9949 9734 0.5% 1390.6 -- HOSEO-AS HOSEO UNIVERSITY TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 89.218.220.0/23 9641 0.4% AS9198 -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration 2 - 89.218.218.0/23 9639 0.4% AS9198 -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration 3 - 95.59.2.0/23 9636 0.4% AS9198 -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration 4 - 92.46.244.0/23 9634 0.4% AS9198 -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration 5 - 95.59.3.0/24 9634 0.4% AS9198 -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration 6 - 95.59.8.0/23 9632 0.4% AS9198 -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration 7 - 95.59.4.0/22 9632 0.4% AS9198 -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration 8 - 88.204.221.0/24 9593 0.4% AS9198 -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration 9 - 95.59.1.0/24 9583 0.4% AS9198 -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration 10 - 72.23.246.0/24 5995 0.3% AS5050 -- PSC-EXT - Pittsburgh Supercomputing Center 11 - 84.1.45.0/24 4109 0.2% AS41313 -- NOVATEL-AS Novatel Bulgaria 12 - 193.201.184.0/21 3547 0.2% AS25546 -- BROOKLANDCOMP-AS Brookland Computer Services 13 - 196.216.8.0/21 2656 0.1% AS36913 -- BROADBAND-MALAWI 14 - 192.12.120.0/24 2585 0.1% AS5691 -- MITRE-AS-5 - The MITRE Corporation 15 - 85.60.208.0/21 2570 0.1% AS12479 -- UNI2-AS Uni2 Autonomous System 16 - 72.42.193.0/24 2466 0.1% AS40060 -- AAAWI - AAA Wireless, Inc. 17 - 85.60.208.0/22 2399 0.1% AS12479 -- UNI2-AS Uni2 Autonomous System 18 - 203.240.65.0/24 1684 0.1% AS17865 -- SCOURT-AS-KR Supreme Court of Korea 19 - 203.240.68.0/24 1684 0.1% AS17865 -- SCOURT-AS-KR Supreme Court of Korea 20 - 203.240.73.0/24 1684 0.1% AS17865 -- SCOURT-AS-KR Supreme Court of Korea 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 Aug 28 17:00:00 2009 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 28 Aug 2009 22:00:00 GMT Subject: The Cidr Report Message-ID: <200908282200.n7SM00IK011852@wattle.apnic.net> This report has been generated at Fri Aug 28 21:11:40 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 21-08-09 300840 186654 22-08-09 301185 186680 23-08-09 301048 186693 24-08-09 301100 186967 25-08-09 301246 186390 26-08-09 301409 186208 27-08-09 301316 186515 28-08-09 301511 186446 AS Summary 32179 Number of ASes in routing system 13702 Number of ASes announcing only one prefix 4309 Largest number of prefixes announced by an AS AS4323 : TWTC - tw telecom holdings, inc. 89615104 Largest address span announced by an AS (/32s) AS27064: DNIC-ASBLK-27032-27159 - DoD Network Information Center Aggregation Summary The algorithm used in this report proposes aggregation only when there is a precise match using the AS path, so as to preserve traffic transit policies. Aggregation is also proposed across non-advertised address space ('holes'). --- 28Aug09 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 301277 186415 114862 38.1% All ASes AS6389 4179 327 3852 92.2% BELLSOUTH-NET-BLK - BellSouth.net Inc. AS4323 4309 1738 2571 59.7% TWTC - tw telecom holdings, inc. AS4766 1825 542 1283 70.3% KIXS-AS-KR Korea Telecom AS17488 1548 303 1245 80.4% HATHWAY-NET-AP Hathway IP Over Cable Internet AS18566 1062 10 1052 99.1% COVAD - Covad Communications Co. AS22773 1091 71 1020 93.5% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. AS8151 1474 558 916 62.1% Uninet S.A. de C.V. AS18101 949 97 852 89.8% RIL-IDC Reliance Infocom Ltd Internet Data Centre, AS19262 1041 234 807 77.5% VZGNI-TRANSIT - Verizon Internet Services Inc. AS4755 1228 438 790 64.3% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP AS6478 1385 650 735 53.1% ATT-INTERNET3 - AT&T WorldNet Services AS8452 1002 287 715 71.4% TEDATA TEDATA AS3356 1217 573 644 52.9% LEVEL3 Level 3 Communications AS1785 1734 1120 614 35.4% AS-PAETEC-NET - PaeTec Communications, Inc. AS4804 686 90 596 86.9% MPX-AS Microplex PTY LTD AS11492 1112 548 564 50.7% CABLEONE - CABLE ONE, INC. AS4808 762 211 551 72.3% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network AS9498 635 91 544 85.7% BBIL-AP BHARTI Airtel Ltd. AS10620 990 453 537 54.2% TV Cable S.A. AS7303 632 98 534 84.5% Telecom Argentina S.A. AS22047 542 16 526 97.0% VTR BANDA ANCHA S.A. AS4134 999 532 467 46.7% CHINANET-BACKBONE No.31,Jin-rong Street AS7018 1490 1052 438 29.4% ATT-INTERNET4 - AT&T WorldNet Services AS17676 564 127 437 77.5% GIGAINFRA Softbank BB Corp. AS5668 787 353 434 55.1% AS-5668 - CenturyTel Internet Holdings, Inc. AS7011 1011 584 427 42.2% FRONTIER-AND-CITIZENS - Frontier Communications of America, Inc. AS7545 839 413 426 50.8% TPG-INTERNET-AP TPG Internet Pty Ltd AS9443 515 94 421 81.7% INTERNETPRIMUS-AS-AP Primus Telecommunications AS4780 564 146 418 74.1% SEEDNET Digital United Inc. AS4668 695 285 410 59.0% LGNET-AS-KR LG CNS Total 36867 12041 24826 67.3% Top 30 total Possible Bogus Routes 24.225.128.0/17 AS36377 PATRIOT-MEDIA-NJ - Comcast Telecommunications, Inc. 24.245.128.0/17 AS11492 CABLEONE - CABLE ONE, INC. 41.223.92.0/22 AS36936 CELTEL-GABON Celtel Gabon Internet Service 41.223.176.0/22 AS36981 41.223.189.0/24 AS26452 BRING-AS - BringCom, Inc. 43.245.0.0/16 AS7502 IP-KYOTO Internetwork Kyoto 43.245.96.0/20 AS7502 IP-KYOTO Internetwork Kyoto 43.245.112.0/20 AS7502 IP-KYOTO Internetwork Kyoto 43.245.192.0/20 AS7502 IP-KYOTO Internetwork Kyoto 43.245.208.0/20 AS7502 IP-KYOTO Internetwork Kyoto 43.245.224.0/20 AS7502 IP-KYOTO Internetwork Kyoto 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.72.112.0/20 AS19166 64.79.88.0/24 AS26096 LODDEN - Lodden Services 64.79.89.0/24 AS26096 LODDEN - Lodden Services 64.247.160.0/20 AS10937 IIS - Island Internet Services 66.128.38.0/24 AS15246 Telecomunicaciones Satelitales TelesatS.A. 66.180.239.0/24 AS35888 VIGNETTE - VIGNETTE CORPORATION 66.206.32.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.33.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.34.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.35.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.40.0/22 AS174 COGENT Cogent/PSI 66.206.44.0/23 AS174 COGENT Cogent/PSI 66.206.47.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 66.207.32.0/20 AS23011 66.241.112.0/20 AS21547 REVNETS - Revolution Networks 66.245.176.0/20 AS19318 NJIIX-AS-1 - NEW JERSEY INTERNATIONAL INTERNET EXCHANGE LLC 69.6.80.0/24 AS13442 69.6.81.0/24 AS13442 69.71.192.0/20 AS13818 PHX-INTL-TELEPORT - Phoenix International Teleport 69.80.224.0/19 AS19166 74.120.160.0/24 AS19262 VZGNI-TRANSIT - Verizon Internet Services Inc. 74.120.161.0/24 AS19262 VZGNI-TRANSIT - Verizon Internet Services Inc. 74.120.162.0/24 AS19262 VZGNI-TRANSIT - Verizon Internet Services Inc. 74.120.163.0/24 AS19262 VZGNI-TRANSIT - Verizon Internet Services Inc. 74.120.164.0/24 AS19262 VZGNI-TRANSIT - Verizon Internet Services Inc. 74.120.165.0/24 AS19262 VZGNI-TRANSIT - Verizon Internet Services Inc. 74.120.166.0/24 AS19262 VZGNI-TRANSIT - Verizon Internet Services Inc. 74.120.167.0/24 AS19262 VZGNI-TRANSIT - Verizon Internet Services Inc. 74.120.168.0/24 AS19262 VZGNI-TRANSIT - Verizon Internet Services Inc. 74.120.169.0/24 AS19262 VZGNI-TRANSIT - Verizon Internet Services Inc. 74.120.170.0/24 AS19262 VZGNI-TRANSIT - Verizon Internet Services Inc. 74.120.171.0/24 AS19262 VZGNI-TRANSIT - Verizon Internet Services Inc. 74.120.172.0/24 AS19262 VZGNI-TRANSIT - Verizon Internet Services Inc. 74.120.173.0/24 AS19262 VZGNI-TRANSIT - Verizon Internet Services Inc. 74.120.174.0/24 AS19262 VZGNI-TRANSIT - Verizon Internet Services Inc. 74.120.175.0/24 AS19262 VZGNI-TRANSIT - Verizon Internet Services Inc. 80.88.10.0/24 AS33774 DJAWEB 80.88.12.0/24 AS33779 wataniya-telecom-as 96.8.64.0/18 AS19166 96.8.127.0/24 AS19166 100.100.100.0/30 AS38676 AS33005-AS-KR wizsolution co.,Ltd 116.50.0.0/24 AS17754 EXCELL-AS Excellmedia 117.120.56.0/21 AS4755 TATACOMM-AS TATA Communications formerly VSNL is Leading ISP 121.46.0.0/16 AS4134 CHINANET-BACKBONE No.31,Jin-rong Street 121.50.10.0/24 AS38236 121.50.13.0/24 AS38236 121.50.168.0/21 AS9931 CAT-AP The Communication Authoity of Thailand, CAT 122.128.120.0/22 AS38456 PACTEL-AS-AP Pacific Teleports. 158.222.5.0/24 AS21580 SIERRA-ADVANTAGE - Sierra Advantage, Inc. 158.222.70.0/23 AS6137 SISNA - SISNA, Inc. 158.222.72.0/23 AS6137 SISNA - SISNA, Inc. 158.222.224.0/20 AS19864 O1COMM - O1 COMMUNICATIONS 158.222.224.0/22 AS19864 O1COMM - O1 COMMUNICATIONS 158.222.229.0/24 AS19864 O1COMM - O1 COMMUNICATIONS 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.101.45.0/24 AS2905 TICSA-ASN 192.101.46.0/24 AS6503 Avantel, S.A. 192.101.64.0/21 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 192.101.70.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 192.101.71.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 192.101.72.0/24 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 192.101.74.0/24 AS1239 SPRINTLINK - Sprint 192.124.248.0/23 AS680 DFN-IP service X-WiN 192.124.252.0/22 AS680 DFN-IP service X-WiN 192.131.233.0/24 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 192.132.58.0/24 AS20141 QUALITYTECH-SUW-300 - Quality Technology Services, LLC. 192.133.6.0/24 AS10282 ORANGE-BUSINESS-SERVICES-CEEUR Orange Business Services (formerly Equant) AS for CEEUR 192.139.3.0/24 AS23184 PERSONA - PERSONA COMMUNICATIONS INC. 192.153.144.0/21 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 192.154.32.0/19 AS81 NCREN - MCNC 192.188.208.0/20 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 193.24.196.0/22 AS6714 ATOMNET ATOM SA 193.33.148.0/23 AS30890 EVOLVA Evolva Telecom / iLink Telecom 195.16.90.0/24 AS34377 BROKER-AS Przedsiebiorstwo Broker Service Sp. Z o.o. 195.225.58.0/24 AS6714 ATOMNET ATOM SA 196.1.130.0/24 AS3741 IS 196.1.131.0/24 AS3741 IS 196.1.132.0/24 AS3741 IS 196.1.133.0/24 AS3741 IS 196.6.108.0/24 AS5713 SAIX-NET 196.202.224.0/21 AS8818 TELE Greenland Autonomous System 196.207.128.0/20 AS26452 BRING-AS - BringCom, Inc. 198.1.2.0/24 AS4761 INDOSAT-INP-AP INDOSAT Internet Network Provider 198.23.26.0/24 AS33052 VZUNET - Verizon Data Services LLC 198.73.210.0/24 AS21570 ACI-1 - Accelerated Connections Inc. 198.97.72.0/21 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 198.97.96.0/19 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 198.97.240.0/20 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 198.135.236.0/24 AS4358 XNET - XNet Information Systems, Inc. 198.161.87.0/24 AS6539 GT-BELL - Bell Canada 198.161.92.0/24 AS6539 GT-BELL - Bell Canada 198.167.0.0/16 AS7456 INTERHOP - Interhop Network SERVICES Inc. 198.168.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 198.169.0.0/16 AS803 SASKTEL - Saskatchewan Telecommunications 198.180.198.0/24 AS23715 SEOUL-INTGW-GXS-AP Global Exchange Services 199.5.242.0/24 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 199.10.0.0/16 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.16.32.0/19 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 199.114.0.0/21 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.114.128.0/18 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.114.130.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.131.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.132.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.134.0/24 AS3541 ITSDN-U4 - DoD Network Information Center 199.114.136.0/24 AS27044 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.114.138.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.140.0/24 AS3544 ITSDN-U7 - DoD Network Information Center 199.114.142.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.144.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.148.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.150.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.152.0/24 AS27033 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.114.153.0/24 AS27034 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.114.154.0/24 AS1733 CENTAF-SWA - 754th Electronic Systems Group 199.114.156.0/24 AS1733 CENTAF-SWA - 754th Electronic Systems Group 199.114.160.0/24 AS1733 CENTAF-SWA - 754th Electronic Systems Group 199.121.0.0/16 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.123.0.0/18 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.123.16.0/20 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.123.80.0/21 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.189.32.0/19 AS7332 IQUEST-AS - IQuest Internet 199.202.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 199.202.216.0/21 AS577 BACOM - Bell Canada 199.233.92.0/24 AS26896 D102-ITC - Data 102, LLC 199.246.116.0/24 AS813 UUNET-CANADA - MCI Communications Services, Inc. d/b/a Verizon Business 200.9.115.0/24 AS10292 CWJ-1 - Cable & Wireless Jamaica 200.108.176.0/20 AS14551 UUNET-SA - MCI Communications Services, Inc. d/b/a Verizon Business 202.6.176.0/20 AS24316 202.58.113.0/24 AS19161 202.73.144.0/20 AS4788 TMNET-AS-AP TM Net, Internet Service Provider 202.80.192.0/20 AS2706 PI-HK Pacnet Internet (Hong Kong) Limited 202.84.10.0/23 AS9308 CHINA-ABITCOOL Abitcool(China) Inc. 202.86.252.0/22 AS4748 RESOLINK-AS-AP Resources Link Network Limited 202.86.252.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.253.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.254.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.255.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.94.70.0/24 AS2764 AAPT AAPT Limited 202.124.195.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.125.113.0/24 AS9541 CYBERNET-AP Cyber Internet Services (Pvt) Ltd. 202.125.114.0/24 AS9541 CYBERNET-AP Cyber Internet Services (Pvt) Ltd. 202.125.115.0/24 AS9541 CYBERNET-AP Cyber Internet Services (Pvt) Ltd. 202.133.37.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.133.47.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.133.70.0/24 AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited 202.133.73.0/24 AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited 202.136.254.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.136.255.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.140.160.0/24 AS4841 202.140.161.0/24 AS4841 202.140.162.0/24 AS4841 202.140.163.0/24 AS4841 202.140.164.0/24 AS4841 202.140.165.0/24 AS4841 202.140.166.0/24 AS4841 202.140.167.0/24 AS4841 202.140.168.0/24 AS4841 202.140.169.0/24 AS4841 202.140.170.0/24 AS4841 202.140.171.0/24 AS4841 202.140.172.0/24 AS4841 202.140.173.0/24 AS4841 202.140.174.0/24 AS4841 202.140.175.0/24 AS4841 202.140.180.0/24 AS7540 HKCIX-AS-AP HongKong Commercial Internet Exchange 202.140.181.0/24 AS7540 HKCIX-AS-AP HongKong Commercial Internet Exchange 202.140.182.0/24 AS7540 HKCIX-AS-AP HongKong Commercial Internet Exchange 202.150.227.0/24 AS17727 NAPINFO-AS-AP PT. NAP Info Lintas Nusa 202.174.70.0/24 AS21175 M-LINK M-Link Teleport s.a. 202.181.32.0/24 AS4645 ASN-HKNET-AP HKNet Co. Ltd 203.12.45.0/24 AS4854 NETSPACE-AS-AP Netspace Online Systems 203.62.0.0/17 AS7575 AARNET-AS-AP Australian Academic and Reasearch Network (AARNet) 203.78.48.0/20 AS9299 IPG-AS-AP Philippine Long Distance Telephone Company 203.80.136.0/21 AS4759 EVOSERVE-AS-AP EvoServe is a content and online access Internet provider company 203.86.96.0/19 AS4755 TATACOMM-AS TATA Communications formerly VSNL is Leading ISP 203.89.139.0/24 AS17911 BRAINPK-AS-AP Brain Telecommunication Ltd. 203.112.111.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.113.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.114.0/24 AS4802 ASN-IINET iiNet Limited 203.112.116.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.117.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.118.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.119.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.120.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.121.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.127.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.128.128.0/24 AS23849 CNNIC-NET263-AP Beijing Capital-online science development Co.,Ltd. 203.142.219.0/24 AS45149 203.189.96.0/20 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 204.9.216.0/23 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 204.9.218.0/23 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 204.19.14.0/23 AS577 BACOM - Bell Canada 204.89.214.0/24 AS4323 TWTC - tw telecom holdings, inc. 204.138.167.0/24 AS18990 AIRBAND-DALLAS - Airband Communications, Inc 204.197.0.0/16 AS3356 LEVEL3 Level 3 Communications 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.166.112.0/20 AS10937 IIS - Island Internet Services 207.174.0.0/16 AS13790 INTERNAP-BLK3 - Internap Network Services Corporation 207.174.131.0/24 AS30715 NETRACK - Netrack, Inc. 207.174.132.0/23 AS30715 NETRACK - Netrack, Inc. 207.174.151.0/24 AS11500 PEAKPEAK - Peak to Peak Internet 207.174.152.0/22 AS30715 NETRACK - Netrack, Inc. 207.174.177.0/24 AS11500 PEAKPEAK - Peak to Peak Internet 207.174.178.0/24 AS11500 PEAKPEAK - Peak to Peak Internet 207.174.182.0/24 AS29831 FONENET - FONE NET, LLC 207.174.188.0/22 AS30715 NETRACK - Netrack, Inc. 207.174.192.0/24 AS29831 FONENET - FONE NET, LLC 207.174.200.0/24 AS22658 EARTHNET - Earthnet, Inc. 207.174.248.0/21 AS6653 PRIVATEI - privateI, LLC 207.231.96.0/19 AS11194 NUNETPA - NuNet Inc. 208.73.88.0/21 AS36835 208.77.224.0/24 AS36835 208.77.225.0/24 AS36835 208.77.226.0/24 AS36835 208.77.227.0/24 AS36835 208.77.228.0/24 AS36835 208.77.229.0/24 AS36835 208.77.230.0/24 AS36835 208.77.231.0/24 AS36835 208.87.152.0/21 AS25973 MZIMA - Mzima Networks, 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.217.224.0/19 AS6130 AIS-WEST - American Internet Services, LLC. 209.222.5.0/24 AS26699 PSI-CT - Printing For Systems Inc 210.5.128.0/20 AS4837 CHINA169-BACKBONE CNCGROUP China169 Backbone 210.247.224.0/19 AS7496 WEBCENTRAL-AS WebCentral 213.181.70.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.80.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.81.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.82.0/23 AS17175 NSS-UK New Skies Satellites UK AS 213.181.82.0/24 AS17175 NSS-UK New Skies Satellites UK AS 213.181.83.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.84.0/22 AS17175 NSS-UK New Skies Satellites UK AS 213.181.84.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.85.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.86.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.87.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.88.0/21 AS17175 NSS-UK New Skies Satellites UK AS 213.181.88.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.89.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.90.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.91.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.92.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.93.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.94.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.95.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 216.99.20.0/24 AS3356 LEVEL3 Level 3 Communications 216.163.144.0/20 AS35985 ONERINGNET-ATL-1 - One Ring Networks, Inc. 216.172.198.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 216.172.199.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 216.251.207.0/24 AS1239 SPRINTLINK - Sprint 217.78.71.0/24 AS12491 IPPLANET-AS Gilat Satcom 217.78.72.0/24 AS12491 IPPLANET-AS Gilat Satcom 217.78.73.0/24 AS12491 IPPLANET-AS Gilat Satcom Please see http://www.cidr-report.org for the full report ------------------------------------ Copies of this report are mailed to: nanog at merit.edu eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From beckman at angryox.com Fri Aug 28 17:11:09 2009 From: beckman at angryox.com (Peter Beckman) Date: Fri, 28 Aug 2009 18:11:09 -0400 Subject: Ready to get your federal computer license? In-Reply-To: <81CDFC77FB2DC54DB875D4F8FFC36CE00B7A593500@DSMAIL2HE.ds.ad.adp.com> References: <81CDFC77FB2DC54DB875D4F8FFC36CE00A923B797E@DSMAIL2HE.ds.ad.adp.com> <81CDFC77FB2DC54DB875D4F8FFC36CE00B7A593500@DSMAIL2HE.ds.ad.adp.com> Message-ID: On Fri, 28 Aug 2009, Hiers, David wrote: > Governments already license stock brokers, pilots, commercial drivers, > accountants, engineers, all sorts of people whose mistakes can be > measured in the loss of hundreds of lives and millions of dollars. "'The power company allowed their network security to be comprimised by a single Windows computer connected to the Internet in the main control facility, so we unplugged the entire Internet to mitigate the attack,' said Senator Rockefeller, the author of the bill that enabled the President to take swift action after an unknown hacker used the Internet to break into Brominion Power's main control facility and turn off the power to the entire East Coast. 'It will remain unplugged and nobody in the US will be allowed to connect to the Internet until the power is back on and this hacker is brought to justice.' Authorities are having a difficult time locating the hacker due to the unavailability of the Internet and electricity, and cannot communicate with lawmakers via traditional means due to the outage. A formal request to turn the power and Internet back on was sent on a pony earlier this afternoon to lawmakers in DC." Can't wait. Beckman --------------------------------------------------------------------------- Peter Beckman Internet Guy beckman at angryox.com http://www.angryox.com/ --------------------------------------------------------------------------- From davet1 at gmail.com Fri Aug 28 21:47:44 2009 From: davet1 at gmail.com (David Temkin) Date: Fri, 28 Aug 2009 19:47:44 -0700 Subject: Ready to get your federal computer license? In-Reply-To: <81CDFC77FB2DC54DB875D4F8FFC36CE00B7A593500@DSMAIL2HE.ds.ad.adp.com> References: <81CDFC77FB2DC54DB875D4F8FFC36CE00A923B797E@DSMAIL2HE.ds.ad.adp.com> <81CDFC77FB2DC54DB875D4F8FFC36CE00B7A593500@DSMAIL2HE.ds.ad.adp.com> Message-ID: <148641da0908281947t76fe72f8pe4de838dde756d63@mail.gmail.com> On Fri, Aug 28, 2009 at 2:51 PM, Hiers, David wrote: > Governments already license stock brokers, pilots, commercial drivers, > accountants, engineers, all sorts of people whose mistakes can be measured > in the loss of hundreds of lives and millions of dollars. > > > http://sip-trunking.tmcnet.com/topics/security/articles/63218-bill-give-president-emergency-power-internet-raises-concerns.htm > > > Good times.... > > > > David Hiers > > CCIE (R/S, V), CISSP > ADP Dealer Services > It would appear as though your employer should be amongst the first to apply... http://www.baselinemag.com/c/a/Tools-Security%98hold/ADP-Duped-Into-Disclosing-Data/ -Dave (who long ago learned to not post contentious stuff from his employers' e-mail) From frnkblk at iname.com Fri Aug 28 21:55:04 2009 From: frnkblk at iname.com (Frank Bulk) Date: Fri, 28 Aug 2009 21:55:04 -0500 Subject: FCCs RFC for the Definition of Broadband In-Reply-To: References: <4A95CC85.8080102@gmail.com> Message-ID: James: I'm not following you here -- which party has the right of first refusal? If I had to guess, what really happened here is that the rural LEC is able to build out FTTH because they are counting on USF (high cost loop support and interstate common line support) to help pay it, while the LEC in an urban area receives no USF, and is not able to financially justify it even with a dense customer base. Frank -----Original Message----- From: James Downs [mailto:egon at egon.cc] Sent: Friday, August 28, 2009 1:07 AM To: nanog at nanog.org Subject: Re: FCCs RFC for the Definition of Broadband On Aug 26, 2009, at 5:00 PM, Roy wrote: > I think it has become obvious that the correct definition of > broadband depends on the users location. A house in the boonies is > not going to get fiber, Perhaps the minimum acceptable bandwidth > should vary by area. A definition of "area" could be some sort of > user density Except this is exactly what happened. The players with vested interests were allowed a sort of "first refusal" on projects. In areas where they had lots of customers, they passed on the projects. So, we find that in urban areas, you can't get fiber in the home, but there are countless rural farms and homes that have fiber just lying around. I have an acquaintance 60 miles from the closest commercial airport in TN, telling me about the fiber internet he has. -j From frnkblk at iname.com Fri Aug 28 22:05:44 2009 From: frnkblk at iname.com (Frank Bulk) Date: Fri, 28 Aug 2009 22:05:44 -0500 Subject: FCCs RFC for the Definition of Broadband In-Reply-To: <4A976227.8080008@gmail.com> References: <4a9edb810908240917r15739868i93ae029165962e9c@mail.gmail.com> <4A95B431.70102@enger.us> <200908270958.46014.alexander.harrowell@stlpartners.com> <20090827140459.GA64392@ussenterprise.ufp.org> <4A969C65.8040506@telcodata.us> <20090827145800.GA67840@ussenterprise.ufp.org> <4A976227.8080008@gmail.com> Message-ID: Jc: Remember, some rural and high-cost areas can't support multiple wireline providers. May not even a wireless and wireline provider (though satellite is a given). So yes, pricing in these near-monopoly areas might be higher than in an area with real competition, but does that pricing mean the provider is earning an exorbitant rate of return? In the worst case, the price go as high, but no higher, than what would sustain a competitor to enter the market. Other than price regulation, I'm not sure what can be done to get around this potential problem. The areas that are unserved/underserved are the ones that have been least attractive to provide broadband, otherwise someone would have done it. The requirement to provide open access to competitors has obviously been a disincentive for the ILECs to apply. Frank -----Original Message----- From: JC Dill [mailto:jcdill.lists at gmail.com] Sent: Thursday, August 27, 2009 11:51 PM To: NANOG list Subject: Re: FCCs RFC for the Definition of Broadband Leo Bicknell wrote: > What Telecom companies have done is confused infrastructure and > equipment. It would be stupid to plan on making a profit on your > GSR over 30 years, after 10 it will be functionally obsolete. When > it comes to equipment the idea of 1-3 year ROI's makes sense. > However, when it comes to fiber or copper in the ground or on a > pole it has a 20, 30, 40, or even 50 year life span. To require > those assets to have a 1-3 year ROI is absurd. What happens if we have improvements in data transmission systems such that whatever we put in now is obsolete in 15 years? What happens if we put in billions of dollars of fiber, only to have fiber (and copper) obsolete as we roll out faster and faster wireless solutions? IMHO the biggest obstacle to defining broadband is figuring out how to describe how it is used in a way that prevents an ILEC from installing it so that only the ILEC can use it. If the customer doesn't have at least 3 broadband choices, there's no real choice, and pricing will be artificially high and service options will be stagnant and few. Look at what happened to long distance rates and telephone services once Ma Bell was broken up and businesses started competing for customers. I remember when we paid more than $35 a month for long distance fees alone (and about that much more for our basic service, including phone "rental") when I was a teenager in the 1970s. Without competition, with inflation, that same long distance bill would easily be over $100/month today. Yest today, more than 30 years later you can get a cell phone with unlimited minutes, unlimited domestic long distance, for $35/month (e.g Metro PCS). Let's not make this mistake again and let the ILECs use TARP funds to build "broadband" to the curb/home that only they get to use to provide internet services to the customers. jc From frnkblk at iname.com Fri Aug 28 22:08:43 2009 From: frnkblk at iname.com (Frank Bulk) Date: Fri, 28 Aug 2009 22:08:43 -0500 Subject: FCCs RFC for the Definition of Broadband In-Reply-To: <702651.75388.qm@web31804.mail.mud.yahoo.com> References: <4A95CC85.8080102@gmail.com> <702651.75388.qm@web31804.mail.mud.yahoo.com> Message-ID: That deadline is for video. Frank -----Original Message----- From: David Barak [mailto:thegameiam at yahoo.com] Sent: Friday, August 28, 2009 8:25 AM To: nanog at nanog.org Subject: Re: FCCs RFC for the Definition of Broadband ----- Original Message ---- From: James Downs Except this is exactly what happened. The players with vested interests were allowed a sort of "first refusal" on projects. In areas where they had lots of customers, they passed on the projects. So, we find that in urban areas, you can't get fiber in the home, but there are countless rural farms and homes that have fiber just lying around. I have an acquaintance 60 miles from the closest commercial airport in TN, telling me about the fiber internet he has. As an example of the above, Verizon has until 2017 to get FIOS to all of the neighborhoods of Washington DC (http://www.bizjournals.com/washington/stories/2008/11/24/daily8.html). I am envious of many of my suburban-dwelling coworkers and friends who already have it. David Barak Need Geek Rock? Try The Franchise: http://www.listentothefranchise.com From swm at emanon.com Fri Aug 28 22:11:21 2009 From: swm at emanon.com (Scott Morris) Date: Fri, 28 Aug 2009 23:11:21 -0400 Subject: Ready to get your federal computer license? In-Reply-To: References: <81CDFC77FB2DC54DB875D4F8FFC36CE00A923B797E@DSMAIL2HE.ds.ad.adp.com> <81CDFC77FB2DC54DB875D4F8FFC36CE00B7A593500@DSMAIL2HE.ds.ad.adp.com> Message-ID: <4A989C59.10801@emanon.com> I'm trying really hard to find my "paranoia hat", and just to relieve some boredom I read the entire bill to try to figure out where this was all coming from.... "(2) may declare a cybersecurity emergency and order the limitation or shutdown of Internet traffic to and from any compromised Federal Government or United States critical infrastructure information system or network;" Now, I'm sorry, but that doesn't say anything about shutting down the entire Internet. Yes, I understand the idea that since they COULD possibly deem the entire Internet (that Al Gore created?) a critical infrastructure, it would seem simple enough to put a provision in to prevent that. But IMHO the point is to involve people outside the government (read the parts on establishing the committee and voting on rules/regs) as opposed to dictating to them. And it's no different than it is today for groups that have to connect to/from particular agencies within the government. There's already plenty of rules in place about that. So if someone hacks the electric grid, does it not make sense to unplug that portion of the infrastructrure from the Internet until the problem is fixed? (e.g. shut down traffic to/from) I think someone wrote an article after WAY over-thinking this whole thing and everyone else jumps on the bandwagon. So I'm open to hearing about things if I missed them. Reading Senate Bills isn't all that exciting, so it's possible I zoned out a bit, but can someone explain to me where this thought process is coming from? Thanks! Scott Peter Beckman wrote: > On Fri, 28 Aug 2009, Hiers, David wrote: > >> Governments already license stock brokers, pilots, commercial drivers, >> accountants, engineers, all sorts of people whose mistakes can be >> measured in the loss of hundreds of lives and millions of dollars. > > "'The power company allowed their network security to be comprimised > by a > single Windows computer connected to the Internet in the main control > facility, so we unplugged the entire Internet to mitigate the attack,' > said Senator Rockefeller, the author of the bill that enabled the > President to take swift action after an unknown hacker used the > Internet > to break into Brominion Power's main control facility and turn off the > power to the entire East Coast. 'It will remain unplugged and > nobody in > the US will be allowed to connect to the Internet until the power is > back > on and this hacker is brought to justice.' > > Authorities are having a difficult time locating the hacker due to the > unavailability of the Internet and electricity, and cannot communicate > with lawmakers via traditional means due to the outage. A formal > request > to turn the power and Internet back on was sent on a pony earlier this > afternoon to lawmakers in DC." > > Can't wait. > > Beckman > --------------------------------------------------------------------------- > > Peter Beckman > Internet Guy > beckman at angryox.com > http://www.angryox.com/ > --------------------------------------------------------------------------- > > > From frnkblk at iname.com Fri Aug 28 22:23:33 2009 From: frnkblk at iname.com (Frank Bulk) Date: Fri, 28 Aug 2009 22:23:33 -0500 Subject: FCCs RFC for the Definition of Broadband In-Reply-To: <20090828173110.GB1426583@hiwaay.net> References: <200908281405.n7SE5dJa062396@aurora.sol.net> <4A97E786.30309@brightok.net> <20090828142920.GA56263@ussenterprise.ufp.org> <4A97F110.3020406@brightok.net> <20090828150712.GA58799@ussenterprise.ufp.org> <20090828173110.GB1426583@hiwaay.net> Message-ID: Since the features/function/success of the service is so intimately tied to the control/maintenance of that last mile/alley/drop, how do the takers make sure they get what they need? Or that it uses the technology they want? It's an attractive idea from the surface, but one that erodes competitive differentiation. Frank -----Original Message----- From: Chris Adams [mailto:cmadams at hiwaay.net] Sent: Friday, August 28, 2009 12:31 PM To: NANOG list Subject: Re: FCCs RFC for the Definition of Broadband Once upon a time, Peter Beckman said: > And where does that fiber go to? Home runs from a central point in the > development, so any provider can hook up to any house at the street? > Deregulation means those lines should be accessible to any company for a > fee. How do you give House A Verizon and House B Cox, especially if Cox > doesn't support fiber? I have two cable TV providers available at my house. They each have their own cable plant in my neighborhood; there are two runs in each easment, two sets of pylons for access (although they mostly alternate yards, so they aren't digging at the same place when burying new wires). If you switch from one to the other, the new one runs a new wire from their nearest tap and sends somebody else around in a few weeks to "bury" (under maybe 2" of dirt) the wire. On my block, the cable lines are at the back edge of the yard, running between the houses (down the middle of the block), while the phone company wires run along the easment at the front edge of the yard with the utility (power/water/sewer) lines. Not sure why it was done that way, except maybe to keep the cable guys from digging up important stuff on a regular basis (since people switch cable a lot). However, I've seen pictures of the old power lines in New York City and such, when there were a dozen or more power companies. I sure wouldn't want to see anything like that again. IMHO, we'd be better off with a public utility that manages nothing but the cable plant, running one set of wires (a few copper pairs, a coax or two, and a couple of fiber pairs) to each house, and then selling equal access to all takers (ILEC, CLEC, cable TV, direct to ISPs, etc.). The utility would be banned from selling any kind of service themselves, and would be a non-profit; they'd charge everybody the same fees for access to the same type of cable and they'd maintain the plant and colo facilities. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From netfortius at gmail.com Fri Aug 28 22:26:49 2009 From: netfortius at gmail.com (Stefan) Date: Fri, 28 Aug 2009 22:26:49 -0500 Subject: Ready to get your federal computer license? In-Reply-To: <4A989C59.10801@emanon.com> References: <81CDFC77FB2DC54DB875D4F8FFC36CE00A923B797E@DSMAIL2HE.ds.ad.adp.com> <81CDFC77FB2DC54DB875D4F8FFC36CE00B7A593500@DSMAIL2HE.ds.ad.adp.com> <4A989C59.10801@emanon.com> Message-ID: ... this whole issue reminded me of: http://www.youtube.com/watch?v=iRmxXp62O8g and http://www.youtube.com/watch?v=wrQUWUfmR_I On the more serious note: the vagueness of some terms and definitions is what concerns me, for example. I am not sure if the problem could be fixed, though, under a mechanism fundamentally very litigious - thus so very likely to produce laws with potential for [lots of] interpretations (by paid specialists, of course). ***Stefan Mititelu http://twitter.com/netfortius http://www.linkedin.com/in/netfortius On Fri, Aug 28, 2009 at 10:11 PM, Scott Morris wrote: > I'm trying really hard to find my "paranoia hat", and just to relieve > some boredom I read the entire bill to try to figure out where this was > all coming from.... > > "(2) may declare a cybersecurity emergency and order the limitation or > shutdown of Internet traffic to and from any compromised Federal > Government or United States critical infrastructure information system > or network;" > > Now, I'm sorry, but that doesn't say anything about shutting down the > entire Internet. Yes, I understand the idea that since they COULD > possibly deem the entire Internet (that Al Gore created?) a critical > infrastructure, it would seem simple enough to put a provision in to > prevent that. But IMHO the point is to involve people outside the > government (read the parts on establishing the committee and voting on > rules/regs) as opposed to dictating to them. > > And it's no different than it is today for groups that have to connect > to/from particular agencies within the government. There's already > plenty of rules in place about that. > > So if someone hacks the electric grid, does it not make sense to unplug > that portion of the infrastructrure from the Internet until the problem > is fixed? (e.g. shut down traffic to/from) I think someone wrote an > article after WAY over-thinking this whole thing and everyone else jumps > on the bandwagon. > > So I'm open to hearing about things if I missed them. Reading Senate > Bills isn't all that exciting, so it's possible I zoned out a bit, but > can someone explain to me where this thought process is coming from? > > Thanks! > > Scott > > > > > > Peter Beckman wrote: > > On Fri, 28 Aug 2009, Hiers, David wrote: > > > >> Governments already license stock brokers, pilots, commercial drivers, > >> accountants, engineers, all sorts of people whose mistakes can be > >> measured in the loss of hundreds of lives and millions of dollars. > > > > "'The power company allowed their network security to be comprimised > > by a > > single Windows computer connected to the Internet in the main control > > facility, so we unplugged the entire Internet to mitigate the attack,' > > said Senator Rockefeller, the author of the bill that enabled the > > President to take swift action after an unknown hacker used the > > Internet > > to break into Brominion Power's main control facility and turn off the > > power to the entire East Coast. 'It will remain unplugged and > > nobody in > > the US will be allowed to connect to the Internet until the power is > > back > > on and this hacker is brought to justice.' > > > > Authorities are having a difficult time locating the hacker due to the > > unavailability of the Internet and electricity, and cannot communicate > > with lawmakers via traditional means due to the outage. A formal > > request > > to turn the power and Internet back on was sent on a pony earlier this > > afternoon to lawmakers in DC." > > > > Can't wait. > > > > Beckman > > > --------------------------------------------------------------------------- > > > > Peter Beckman > > Internet Guy > > beckman at angryox.com > > http://www.angryox.com/ > > > --------------------------------------------------------------------------- > > > > > > > From fw at deneb.enyo.de Sat Aug 29 03:21:53 2009 From: fw at deneb.enyo.de (Florian Weimer) Date: Sat, 29 Aug 2009 10:21:53 +0200 Subject: Ready to get your federal computer license? In-Reply-To: <4A989C59.10801@emanon.com> (Scott Morris's message of "Fri, 28 Aug 2009 23:11:21 -0400") References: <81CDFC77FB2DC54DB875D4F8FFC36CE00A923B797E@DSMAIL2HE.ds.ad.adp.com> <81CDFC77FB2DC54DB875D4F8FFC36CE00B7A593500@DSMAIL2HE.ds.ad.adp.com> <4A989C59.10801@emanon.com> Message-ID: <873a7bm3mm.fsf@mid.deneb.enyo.de> * Scott Morris: > I'm trying really hard to find my "paranoia hat", and just to relieve > some boredom I read the entire bill to try to figure out where this was > all coming from.... > > "(2) may declare a cybersecurity emergency and order the limitation or > shutdown of Internet traffic to and from any compromised Federal > Government or United States critical infrastructure information system > or network;" Wouldn't this mean you're allowed to set emergency ACLs only if a cybersecurity emergency has been declared by the President? From swm at emanon.com Sat Aug 29 07:57:02 2009 From: swm at emanon.com (Scott Morris) Date: Sat, 29 Aug 2009 08:57:02 -0400 Subject: Ready to get your federal computer license? In-Reply-To: <873a7bm3mm.fsf@mid.deneb.enyo.de> References: <81CDFC77FB2DC54DB875D4F8FFC36CE00A923B797E@DSMAIL2HE.ds.ad.adp.com> <81CDFC77FB2DC54DB875D4F8FFC36CE00B7A593500@DSMAIL2HE.ds.ad.adp.com> <4A989C59.10801@emanon.com> <873a7bm3mm.fsf@mid.deneb.enyo.de> Message-ID: <4A99259E.8000202@emanon.com> I must have missed the phrasing that says "nobody else can make an independent decision regarding any security measure above and beyond the minimum standards"... I'll go back and look for that. Scott Florian Weimer wrote: > * Scott Morris: > > >> I'm trying really hard to find my "paranoia hat", and just to relieve >> some boredom I read the entire bill to try to figure out where this was >> all coming from.... >> >> "(2) may declare a cybersecurity emergency and order the limitation or >> shutdown of Internet traffic to and from any compromised Federal >> Government or United States critical infrastructure information system >> or network;" >> > > Wouldn't this mean you're allowed to set emergency ACLs only if a > cybersecurity emergency has been declared by the President? > > From simon.leinen at switch.ch Sat Aug 29 08:39:35 2009 From: simon.leinen at switch.ch (Simon Leinen) Date: Sat, 29 Aug 2009 15:39:35 +0200 Subject: MRLG In-Reply-To: <859604546CD1FF488BDB6EA94C896AFB8ABE6F@racexchange.race.local> (Carlos Alcantar's message of "Wed, 26 Aug 2009 19:11:46 -0700") References: <859604546CD1FF488BDB6EA94C896AFB8ABE6F@racexchange.race.local> Message-ID: > Thanks guys I got it... Congratulations. But how/where? -- Simon. From cgrundemann at gmail.com Sat Aug 29 09:01:10 2009 From: cgrundemann at gmail.com (Chris Grundemann) Date: Sat, 29 Aug 2009 08:01:10 -0600 Subject: Ready to get your federal computer license? In-Reply-To: <4A99259E.8000202@emanon.com> References: <81CDFC77FB2DC54DB875D4F8FFC36CE00A923B797E@DSMAIL2HE.ds.ad.adp.com> <81CDFC77FB2DC54DB875D4F8FFC36CE00B7A593500@DSMAIL2HE.ds.ad.adp.com> <4A989C59.10801@emanon.com> <873a7bm3mm.fsf@mid.deneb.enyo.de> <4A99259E.8000202@emanon.com> Message-ID: <443de7ad0908290701s2d597b7apd4f9ad87b476396e@mail.gmail.com> On Sat, Aug 29, 2009 at 06:57, Scott Morris wrote: > I must have missed the phrasing that says "nobody else can make an > independent decision regarding any security measure above and beyond the > minimum standards"... > > I'll go back and look for that. > > > > Scott > > > Florian Weimer wrote: >> * Scott Morris: >> >> >>> I'm trying really hard to find my "paranoia hat", and just to relieve >>> some boredom I read the entire bill to try to figure out where this was >>> all coming from.... >>> >>> "(2) may declare a cybersecurity emergency and order the limitation or >>> shutdown of Internet traffic to and from any compromised Federal >>> Government or United States critical infrastructure information system >>> or network;" >>> >> >> Wouldn't this mean you're allowed to set emergency ACLs only if a >> cybersecurity emergency has been declared by the President? >> >> > The EFF summed up the problems with the bill's current text quite well I believe (without any tin-foil hats required): "The Cybersecurity Act is an example of the kind of dramatic proposal that doesn't address the real problems of security, and can actually make matters worse by weakening existing privacy safeguards ? as opposed to simpler, practical measures that create real security by encouraging better computer hygiene." - http://www.eff.org/deeplinks/2009/04/cybersecurity-act $0.02 ~Chris -- Chris Grundemann weblog.chrisgrundemann.com www.burningwiththebush.com www.coisoc.org From j at arpa.com Sat Aug 29 11:35:05 2009 From: j at arpa.com (jamie) Date: Sat, 29 Aug 2009 11:35:05 -0500 Subject: MRLG In-Reply-To: References: <859604546CD1FF488BDB6EA94C896AFB8ABE6F@racexchange.race.local> Message-ID: <6ff30abd0908290935s43dc4b85nef7ba0bd90b38fd6@mail.gmail.com> Can't answer that one for ya, but I have the source.. I've put a copy up on teh webs: https://arpa.com/code/mrlg-5.4.1.tgz (32737 bytes, md5 4a47cde28e41e77168cdefe08114eae1) -jamie -- jamie rishaw On Sat, Aug 29, 2009 at 8:39 AM, Simon Leinen wrote: > > Thanks guys I got it... > > Congratulations. But how/where? > -- > Simon. > > From cmaurand at xyonet.com Sat Aug 29 18:23:54 2009 From: cmaurand at xyonet.com (cmaurand at xyonet.com) Date: Sat, 29 Aug 2009 19:23:54 -0400 (EDT) Subject: Ready to get your federal computer license? In-Reply-To: <4A99259E.8000202@emanon.com> References: <81CDFC77FB2DC54DB875D4F8FFC36CE00A923B797E@DSMAIL2HE.ds.ad.adp.com> <81CDFC77FB2DC54DB875D4F8FFC36CE00B7A593500@DSMAIL2HE.ds.ad.adp.com> <4A989C59.10801@emanon.com> <873a7bm3mm.fsf@mid.deneb.enyo.de> <4A99259E.8000202@emanon.com> Message-ID: I don't know, but #2 reads more like: If the president orders it, compromised federal websites or federal websites under attack can be ordered off the internet. That doesn't look to me like they can shut you down or require you to be a certified cyber-security person. --Curtis > I must have missed the phrasing that says "nobody else can make an > independent decision regarding any security measure above and beyond the > minimum standards"... > > I'll go back and look for that. > > > > Scott > > > Florian Weimer wrote: >> * Scott Morris: >> >> >>> I'm trying really hard to find my "paranoia hat", and just to relieve >>> some boredom I read the entire bill to try to figure out where this was >>> all coming from.... >>> >>> "(2) may declare a cybersecurity emergency and order the limitation or >>> shutdown of Internet traffic to and from any compromised Federal >>> Government or United States critical infrastructure information system >>> or network;" >>> >> >> Wouldn't this mean you're allowed to set emergency ACLs only if a >> cybersecurity emergency has been declared by the President? >> >> > From young at jsyoung.net Sat Aug 29 19:59:34 2009 From: young at jsyoung.net (Jeff Young) Date: Sun, 30 Aug 2009 10:59:34 +1000 Subject: Ready to get your federal computer license? In-Reply-To: References: <81CDFC77FB2DC54DB875D4F8FFC36CE00A923B797E@DSMAIL2HE.ds.ad.adp.com> <81CDFC77FB2DC54DB875D4F8FFC36CE00B7A593500@DSMAIL2HE.ds.ad.adp.com> <4A989C59.10801@emanon.com> <873a7bm3mm.fsf@mid.deneb.enyo.de> <4A99259E.8000202@emanon.com> Message-ID: <5E9C4E81-05BA-42F4-996B-F5BE79F8FEB4@jsyoung.net> Having met more than a few people in government IT, all jokes aside, I think they're pretty well equipped to know when and if they need to disconnect from the Internet, even without an executive order. Like many things in Washington, this all may be an attempt to put the "public" at ease by demonstrating the "we're from the government and we're here to help principle" with regard to Internet security but honestly... If the President wanted to disconnect the working parts of the US Government (beside the Judicial and Legislative branches) from the Internet all it would take is an executive order. The more troubling parts of this bill had to do with the President, at his discretion, classifying parts of public networks as "critical infrastructure" and so on. jy currently living overseas and finding all of this very amusing... On 30/08/2009, at 9:23 AM, cmaurand at xyonet.com wrote: > > I don't know, but #2 reads more like: If the president orders it, > compromised federal websites or federal websites under attack can be > ordered off the internet. That doesn't look to me like they can > shut you > down or require you to be a certified cyber-security person. > > --Curtis > >> I must have missed the phrasing that says "nobody else can make an >> independent decision regarding any security measure above and >> beyond the >> minimum standards"... >> >> I'll go back and look for that. >> >> >> >> Scott >> >> >> Florian Weimer wrote: >>> * Scott Morris: >>> >>> >>>> I'm trying really hard to find my "paranoia hat", and just to >>>> relieve >>>> some boredom I read the entire bill to try to figure out where >>>> this was >>>> all coming from.... >>>> >>>> "(2) may declare a cybersecurity emergency and order the >>>> limitation or >>>> shutdown of Internet traffic to and from any compromised Federal >>>> Government or United States critical infrastructure information >>>> system >>>> or network;" >>>> >>> >>> Wouldn't this mean you're allowed to set emergency ACLs only if a >>> cybersecurity emergency has been declared by the President? >>> >>> >> > > > > From devangnp at gmail.com Sat Aug 29 22:50:41 2009 From: devangnp at gmail.com (devang patel) Date: Sat, 29 Aug 2009 21:50:41 -0600 Subject: Link capacity upgrade threshold Message-ID: Hi All, I just wanted to know what is Link capacity upgrade threshold in terms of % of link utilization? Just to get an idea... thanks, Devang Patel From lists at mtin.net Sat Aug 29 22:54:40 2009 From: lists at mtin.net (Justin Wilson - MTIN) Date: Sat, 29 Aug 2009 23:54:40 -0400 Subject: Link capacity upgrade threshold In-Reply-To: Message-ID: I consider a circuit nearing capacity at 80-85%. Depending on the circuit we start the process of increasing capacity around 70%. There are almost always telco issues, in-building issues, not enough physical ports on the provider end, and other such things that slow you down. Justin From: devang patel Date: Sat, 29 Aug 2009 21:50:41 -0600 To: Subject: Link capacity upgrade threshold Hi All, I just wanted to know what is Link capacity upgrade threshold in terms of % of link utilization? Just to get an idea... thanks, Devang Patel From herrin-nanog at dirtside.com Sat Aug 29 23:15:36 2009 From: herrin-nanog at dirtside.com (William Herrin) Date: Sun, 30 Aug 2009 00:15:36 -0400 Subject: Link capacity upgrade threshold In-Reply-To: References: Message-ID: <3c3e3fca0908292115s12039efch61c0b1138530d814@mail.gmail.com> On Sat, Aug 29, 2009 at 11:50 PM, devang patel wrote: > I just wanted to know what is Link capacity upgrade threshold in terms of % > of link utilization? Just to get an idea... If your 95th percentile utilization is at 80% capacity, it's time to start planning the upgrade. If your 95th percentile utilization is at 95% it's time to finish the upgrade. If you average or median utilizations are at 80% capacity then as often as not it's time for your boss to fire you and replace you with someone who can do the job. Slight variations depending on the resource. Use absolute peak instead of 95th percentile for modem bank utilization -- under normal circumstances a modem bank should never ring busy. And a gig-e can run a little closer to the edge (percentage-wise) before folks notice slowness than a T1 can. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From swmike at swm.pp.se Sun Aug 30 00:23:57 2009 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Sun, 30 Aug 2009 07:23:57 +0200 (CEST) Subject: Link capacity upgrade threshold In-Reply-To: <3c3e3fca0908292115s12039efch61c0b1138530d814@mail.gmail.com> References: <3c3e3fca0908292115s12039efch61c0b1138530d814@mail.gmail.com> Message-ID: On Sun, 30 Aug 2009, William Herrin wrote: > If your 95th percentile utilization is at 80% capacity, it's time to > start planning the upgrade. If your 95th percentile utilization is at > 95% it's time to finish the upgrade. I now see why people at the IETF spoke in a way that "core network congestion" was something natural. If your MRTG graph is showing 95% load in 5 minute average, you're most likely congesting/buffering at some time during that 5 minute interval. If this is acceptable or not in your network (it's not in mine) that's up to you. Also, a gig link on a Cisco will do approx 93-94% of imix of a gig in the values presented via SNMP (around 930-940 megabit/s as seen in "show int") before it's full, because of IFG, ethernet header overhead etc. So personally, I consider a gig link "in desperate need of upgrade" when it's showing around 850-880 megs of traffic in mrtg. -- Mikael Abrahamsson email: swmike at swm.pp.se From randy at psg.com Sun Aug 30 07:04:15 2009 From: randy at psg.com (Randy Bush) Date: Sun, 30 Aug 2009 21:04:15 +0900 Subject: Link capacity upgrade threshold In-Reply-To: <3c3e3fca0908292115s12039efch61c0b1138530d814@mail.gmail.com> References: <3c3e3fca0908292115s12039efch61c0b1138530d814@mail.gmail.com> Message-ID: > If your 95th percentile utilization is at 80% capacity, it's time to > start planning the upgrade. s/80/60/ the normal snmp and other averaging methods *really* miss the bursts. randy From nick at foobar.org Sun Aug 30 07:26:57 2009 From: nick at foobar.org (Nick Hilliard) Date: Sun, 30 Aug 2009 13:26:57 +0100 Subject: Link capacity upgrade threshold In-Reply-To: References: <3c3e3fca0908292115s12039efch61c0b1138530d814@mail.gmail.com> Message-ID: <4A9A7011.1010908@foobar.org> On 30/08/2009 13:04, Randy Bush wrote: > the normal snmp and other averaging methods *really* miss the bursts. Definitely. For fun and giggles, I recently turned on 30 second polling on some kit and it turned up all sorts of interesting peculiarities that were completely blotted out in a 5 minute average. In order to get a really good idea of what's going on at a microburst level, you would need to poll as often as it takes to fill the buffer of the port in question. This is not feasible in the general case, which is why we resort to hacks like QoS to make sure that when there is congestion, it is handled semi-sensibly. There's a lot to the saying that QoS really means "Quantity of Service", because quality of service only ever becomes a problem if there is a shortfall in quantity. Nick From peter.hicks at poggs.co.uk Sun Aug 30 07:34:09 2009 From: peter.hicks at poggs.co.uk (Peter Hicks) Date: Sun, 30 Aug 2009 13:34:09 +0100 Subject: Link capacity upgrade threshold In-Reply-To: <4A9A7011.1010908@foobar.org> References: <3c3e3fca0908292115s12039efch61c0b1138530d814@mail.gmail.com> <4A9A7011.1010908@foobar.org> Message-ID: <4A9A71C1.7020002@poggs.co.uk> Nick Hilliard wrote: > Definitely. For fun and giggles, I recently turned on 30 second polling > on some kit and it turned up all sorts of interesting peculiarities that > were completely blotted out in a 5 minute average. Would RMON History and Alarms help? I've always considered rolling them out to some of my kit to catch microbursts. Poggs From tsands at rackspace.com Sun Aug 30 09:06:39 2009 From: tsands at rackspace.com (Tom Sands) Date: Sun, 30 Aug 2009 09:06:39 -0500 Subject: Link capacity upgrade threshold In-Reply-To: <3c3e3fca0908292115s12039efch61c0b1138530d814@mail.gmail.com> References: <3c3e3fca0908292115s12039efch61c0b1138530d814@mail.gmail.com> Message-ID: <19623_1251641193_n7UE6SMV027747_4A9A876F.8090307@rackspace.com> If talking about just max capacity, I would agree with most of the statements of 80+% being in the right range, likely with a very fine line of when you actually start seeing a performance impact. Operationally, at least in our network, I'd never run anything at that level. Providers that are redundant for each other don't normally operate above 40-45%, in order to accommodate a failure. Other links that have a backup, but don't actively load share, normally run up to about 60-70% before being upgraded. By the time the upgrade is complete, it could be close to 80%. -------------------------------------------------------------------------------- Tom Sands Rackspace Hosting William Herrin wrote: > On Sat, Aug 29, 2009 at 11:50 PM, devang patel wrote: >> I just wanted to know what is Link capacity upgrade threshold in terms of % >> of link utilization? Just to get an idea... > > If your 95th percentile utilization is at 80% capacity, it's time to > start planning the upgrade. If your 95th percentile utilization is at > 95% it's time to finish the upgrade. > > If you average or median utilizations are at 80% capacity then as > often as not it's time for your boss to fire you and replace you with > someone who can do the job. > > Slight variations depending on the resource. Use absolute peak instead > of 95th percentile for modem bank utilization -- under normal > circumstances a modem bank should never ring busy. And a gig-e can run > a little closer to the edge (percentage-wise) before folks notice > slowness than a T1 can. > > Regards, > Bill Herrin > > Confidentiality Notice: This e-mail message (including any attached or embedded documents) is intended for the exclusive and confidential use of the individual or entity to which this message is addressed, and unless otherwise expressly indicated, is confidential and privileged information of Rackspace. Any dissemination, distribution or copying of the enclosed material is prohibited. If you receive this transmission in error, please notify us immediately by e-mail at abuse at rackspace.com, and delete the original message. Your cooperation is appreciated. From oberman at es.net Sun Aug 30 11:22:59 2009 From: oberman at es.net (Kevin Oberman) Date: Sun, 30 Aug 2009 09:22:59 -0700 Subject: Link capacity upgrade threshold In-Reply-To: Your message of "Sun, 30 Aug 2009 21:04:15 +0900." Message-ID: <20090830162259.992201CC09@ptavv.es.net> > Date: Sun, 30 Aug 2009 21:04:15 +0900 > From: Randy Bush > > > If your 95th percentile utilization is at 80% capacity, it's time to > > start planning the upgrade. > > s/80/60/ > > the normal snmp and other averaging methods *really* miss the bursts. s/60/40/ If you need to carry large TCP flows, say 2Gbps on a 10GE, dropping even a single packet due to congestion is unacceptable. Even with fast recovery, the average transmission rate will take a noticeable dip on every drop and even a drop rate under 1% will slow the flow dramatically. The point is, what is acceptable for one traffic profile may be unacceptable for another. Mail and web browsing are generally unaffected by light congestion. Other applications are not so forgiving. -- 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 Sun Aug 30 11:53:35 2009 From: sronan at fattoc.com (Shane Ronan) Date: Sun, 30 Aug 2009 12:53:35 -0400 Subject: Link capacity upgrade threshold In-Reply-To: <4A9A7011.1010908@foobar.org> References: <3c3e3fca0908292115s12039efch61c0b1138530d814@mail.gmail.com> <4A9A7011.1010908@foobar.org> Message-ID: <05F63C7D-76FA-43E3-9AEC-59AF5634BB26@fattoc.com> What system were you using to monitor link usage? Shane On Aug 30, 2009, at 8:26 AM, Nick Hilliard wrote: > On 30/08/2009 13:04, Randy Bush wrote: >> the normal snmp and other averaging methods *really* miss the bursts. > > Definitely. For fun and giggles, I recently turned on 30 second > polling on some kit and it turned up all sorts of interesting > peculiarities that were completely blotted out in a 5 minute average. > > In order to get a really good idea of what's going on at a > microburst level, you would need to poll as often as it takes to > fill the buffer of the port in question. This is not feasible in > the general case, which is why we resort to hacks like QoS to make > sure that when there is congestion, it is handled semi-sensibly. > > There's a lot to the saying that QoS really means "Quantity of > Service", because quality of service only ever becomes a problem if > there is a shortfall in quantity. > > Nick > From nick at foobar.org Sun Aug 30 12:02:48 2009 From: nick at foobar.org (Nick Hilliard) Date: Sun, 30 Aug 2009 18:02:48 +0100 Subject: Link capacity upgrade threshold In-Reply-To: <05F63C7D-76FA-43E3-9AEC-59AF5634BB26@fattoc.com> References: <3c3e3fca0908292115s12039efch61c0b1138530d814@mail.gmail.com> <4A9A7011.1010908@foobar.org> <05F63C7D-76FA-43E3-9AEC-59AF5634BB26@fattoc.com> Message-ID: <4A9AB0B8.1020100@foobar.org> On 30/08/2009 17:53, Shane Ronan wrote: > What system were you using to monitor link usage? yrtg Nick From patrick at ianai.net Sun Aug 30 12:03:35 2009 From: patrick at ianai.net (Patrick W. Gilmore) Date: Sun, 30 Aug 2009 13:03:35 -0400 Subject: Link capacity upgrade threshold In-Reply-To: References: <3c3e3fca0908292115s12039efch61c0b1138530d814@mail.gmail.com> Message-ID: <19E6B20C-64D0-470D-9CA9-4E7B9B37C1A8@ianai.net> On Aug 30, 2009, at 1:23 AM, Mikael Abrahamsson wrote: > On Sun, 30 Aug 2009, William Herrin wrote: > >> If your 95th percentile utilization is at 80% capacity, it's time >> to start planning the upgrade. If your 95th percentile utilization >> is at 95% it's time to finish the upgrade. > > I now see why people at the IETF spoke in a way that "core network > congestion" was something natural. > > If your MRTG graph is showing 95% load in 5 minute average, you're > most likely congesting/buffering at some time during that 5 minute > interval. If this is acceptable or not in your network (it's not in > mine) that's up to you. > > Also, a gig link on a Cisco will do approx 93-94% of imix of a gig > in the values presented via SNMP (around 930-940 megabit/s as seen > in "show int") before it's full, because of IFG, ethernet header > overhead etc. I've heard this said many times. I've also seen 'sho int' say 950,000,000 bits/sec and not see packets get dropped. I was under the impression "show int" showed -every- byte leaving the interface. I could make an argument that IFG would not be included, but things like ethernet headers better be. Does this change between IOS revisions, or hardware, or is it old info, or ... what? -- TTFN, patrick P.S. I agree that without perfect conditions (e.g. using an Ixia to test link speeds), you should upgrade WAAAAAY before 90-something percent. microbursts are real, and buffer space is small these days. I'm just asking what the counters -actually- show. > So personally, I consider a gig link "in desperate need of upgrade" > when it's showing around 850-880 megs of traffic in mrtg. > > -- > Mikael Abrahamsson email: swmike at swm.pp.se > From woody at pch.net Sun Aug 30 13:23:55 2009 From: woody at pch.net (Bill Woodcock) Date: Sun, 30 Aug 2009 11:23:55 -0700 Subject: Link capacity upgrade threshold References: Message-ID: <6E4AE737-9BF0-46BC-AE81-26E443BE9D56@pch.net> >>> If your 95th percentile utilization is at 80% capacity... >> s/80/60/ > s/60/40/ I would suggest that the reason each of you have a different number is because there's a different best number for each case. Looking for any single number to fit all cases, rather than understanding the underlying process, is unlikely to yield good results. First, different people have different requirements. Some people need lowest possible cost, some people need lowest cost per volume of bits delivered, some people need lowest cost per burst capacity, some need low latency, some need low jitter, some want good customer service, some want flexible payment terms, and undoubtedly there are a thousand other possible qualities. Second, this is a binary digital network. It's never 80% full, it's never 60% full, and it's never 40% full. It's always exactly 100% full or exactly 0% full. If SNMP tells you that you've moved 800 megabits in a second on a one-gigabit pipe, then, modulo any bad implementations of SNMP, your pipe was 100% full for eight-tenths of that second. SNMP does not "hide" anything. Applying any percentile function to your data, on the other hand, does hide data. Specifically, it discards all of your data except a single point, irreversibly. So if you want to know anything about your network, you won't be looking at percentiles. Having your circuit be 100% full is a good thing, presuming you're paying for it and the traffic has some value to you. Having it be 100% full as much of the time as possible is a good thing, because that gives you a high ratio of value to cost. Dropping packets, on the other hand, is likely to be a bad thing, both because each packet putatively had value, and because many dropped packets are likely to be resent, and a resent packet is one you've paid for twice, and that's precluded the sending of another new, paid-for packet in that timeframe. The cost of not dropping packets is not having buffers overflow, and the cost of not having buffers overflow is either having deep buffers, which means high latency, or having customers with a predictable flow of traffic. Which brings me to item three. In my experience, the single biggest contributor to buffer overflow is having in-feeding (or downstream customer) circuits which are of burst capacity too close to that of the out-feeding (or upstream transit) circuits. Let's say that your outbound circuit is a gigabit, you have two inbound circuits that are a gigabit and run at 100% utilization 10% of the time each, and you have a megabit of buffer memory allocated to the outbound circuit. 1% of the time, both of the inbound circuits will be at 100% utilization simultaneously. When that's happening, you'll have data flowing in at the rate of two gigabits per second, which will fill the buffer in one twentieth of a second, if it persists. And, just like Rosencrantz and Guildenstern flipping coins, such a run will inevitably persist longer than you'd desire, frequently enough. On the other hand, if you have twenty inbound circuits of 100 megabits each, which are transmitting at 100% of capacity 10% of the time each, you're looking at exactly the same amount of data, however it arrives _much more predictably_, since the 2-gigabit inflow would only occur 0.0000000000000000001% of the time, rather than 1% of the time. And it would also be proportionally unlikely to persist for the longer periods of time necessary to overflow the buffer. Thus Kevin's ESnet customers, who are much more likely to be 10gb or 40gb downstream circuits feeding into his 40gb upstream circuits, are much more likely to overflow buffers, than a consumer Internet provider who's feeding 1mb circuits into a gigabit circuit, even if the aggregation ratio of the latter is hundreds of times higher. So, in summary: Your dropped packet counters are the ones to be looking at as a measure of goodput, more than your utilization counters. And keep the size of your aggregation pipes as much bigger than the size of the pipes you aggregate into them as you can afford to. As always, my apologies to those of you for whom this is unnecessarily remedial, for using NANOG bandwidth and a portion of your Sunday morning. -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 ras at e-gerbil.net Sun Aug 30 13:46:53 2009 From: ras at e-gerbil.net (Richard A Steenbergen) Date: Sun, 30 Aug 2009 13:46:53 -0500 Subject: Link capacity upgrade threshold In-Reply-To: <19E6B20C-64D0-470D-9CA9-4E7B9B37C1A8@ianai.net> References: <3c3e3fca0908292115s12039efch61c0b1138530d814@mail.gmail.com> <19E6B20C-64D0-470D-9CA9-4E7B9B37C1A8@ianai.net> Message-ID: <20090830184652.GU51443@gerbil.cluepon.net> On Sun, Aug 30, 2009 at 01:03:35PM -0400, Patrick W. Gilmore wrote: > >Also, a gig link on a Cisco will do approx 93-94% of imix of a gig > >in the values presented via SNMP (around 930-940 megabit/s as seen > >in "show int") before it's full, because of IFG, ethernet header > >overhead etc. > > I've heard this said many times. I've also seen 'sho int' say > 950,000,000 bits/sec and not see packets get dropped. I was under the > impression "show int" showed -every- byte leaving the interface. I > could make an argument that IFG would not be included, but things like > ethernet headers better be. > > Does this change between IOS revisions, or hardware, or is it old > info, or ... what? Actually Cisco does count layer 2 header overhead in its snmp and show int results, it is Juniper who does not (for most platforms at any rate) due to their hw architecture. I did some tests regarding this a while back on j-nsp, you'll see different results for different platforms and depending on whether you're looking at the tx or rx. Also you'll see different results for vlan overhead and the like, which can further complicate things. That said, "show int" is an epic disaster for a significantly large percentage of the time. I've seen more bugs and false readings on that thing than I can possibly count, so you really shouldn't rely on it for rate readings. The problem is extra special bad on SVIs, where you might see a reading that is 20% high or low from reality at any given second, even on modern code. I'm not aware of any major issues detecting drops though, so you should at least be able to detect them when they happen (which isn't always at line rate). If you're on a 6500/7600 platform running anything SXF+ try "show platform hardware capacity interface" to look for interfaces with lots of drops globally. -- Richard A Steenbergen http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) From sean at donelan.com Sun Aug 30 18:46:19 2009 From: sean at donelan.com (Sean Donelan) Date: Sun, 30 Aug 2009 19:46:19 -0400 (EDT) Subject: Ready to get your federal computer license? In-Reply-To: <5E9C4E81-05BA-42F4-996B-F5BE79F8FEB4@jsyoung.net> References: <81CDFC77FB2DC54DB875D4F8FFC36CE00A923B797E@DSMAIL2HE.ds.ad.adp.com> <81CDFC77FB2DC54DB875D4F8FFC36CE00B7A593500@DSMAIL2HE.ds.ad.adp.com> <4A989C59.10801@emanon.com> <873a7bm3mm.fsf@mid.deneb.enyo.de> <4A99259E.8000202@emanon.com> <5E9C4E81-05BA-42F4-996B-F5BE79F8FEB4@jsyoung.net> Message-ID: <200908301938220.6B95064B.8300@clifden.donelan.com> On Sun, 30 Aug 2009, Jeff Young wrote: > The more troubling parts of this bill had to do with the President, > at his discretion, classifying parts of public networks as "critical > infrastructure" and so on. Whatever your opinion, get involved. Let your representatives know about your better ideas. > currently living overseas and finding all of this very amusing... If any other country has solved the problem of protecting Internet/data/cyber/critical/etc infrastructures and have some great ideas, it would be great to hear what those ideas are and how they did it. From smb at cs.columbia.edu Sun Aug 30 19:11:11 2009 From: smb at cs.columbia.edu (Steven M. Bellovin) Date: Sun, 30 Aug 2009 20:11:11 -0400 Subject: Ready to get your federal computer license? In-Reply-To: <200908301938220.6B95064B.8300@clifden.donelan.com> References: <81CDFC77FB2DC54DB875D4F8FFC36CE00A923B797E@DSMAIL2HE.ds.ad.adp.com> <81CDFC77FB2DC54DB875D4F8FFC36CE00B7A593500@DSMAIL2HE.ds.ad.adp.com> <4A989C59.10801@emanon.com> <873a7bm3mm.fsf@mid.deneb.enyo.de> <4A99259E.8000202@emanon.com> <5E9C4E81-05BA-42F4-996B-F5BE79F8FEB4@jsyoung.net> <200908301938220.6B95064B.8300@clifden.donelan.com> Message-ID: <20090830201111.03018727@cs.columbia.edu> On Sun, 30 Aug 2009 19:46:19 -0400 (EDT) Sean Donelan wrote: > On Sun, 30 Aug 2009, Jeff Young wrote: > > The more troubling parts of this bill had to do with the President, > > at his discretion, classifying parts of public networks as "critical > > infrastructure" and so on. > > Whatever your opinion, get involved. Let your representatives know > about your better ideas. I strongly second this. To quote a bumper sticker/slogan I've seen, "if you didn't vote, you shouldn't complain". Some prominent politicians have proposed something that we -- including me -- believe to be a bad idea, not just on ideological grounds but because we think that it won't accomplish its purported goals and may even be counterproductive. I don't see a lot of network operators in Congress -- if you know better, you really need to tell them. Some folks on this list -- and I know there are a few, very specifically including myself -- spend more than a little bit of time not just worrying about public policy issues, but actually spending time and effort on the subject. (I'm in D.C. right now, largely because of a policy-related meeting on Tuesday.) I'll misuses a security slogan I've seen on mass transit facilities in the New York area: if you see something, say something. If no one tells Congress that this is a bad idea, how should they know? > > > currently living overseas and finding all of this very amusing... > > If any other country has solved the problem of protecting > Internet/data/cyber/critical/etc infrastructures and have some great > ideas, it would be great to hear what those ideas are and how they > did it. > Indeed. --Steve Bellovin, http://www.cs.columbia.edu/~smb From randy at psg.com Sun Aug 30 20:14:28 2009 From: randy at psg.com (Randy Bush) Date: Mon, 31 Aug 2009 10:14:28 +0900 Subject: Ready to get your federal computer license? In-Reply-To: <20090830201111.03018727@cs.columbia.edu> References: <81CDFC77FB2DC54DB875D4F8FFC36CE00A923B797E@DSMAIL2HE.ds.ad.adp.com> <81CDFC77FB2DC54DB875D4F8FFC36CE00B7A593500@DSMAIL2HE.ds.ad.adp.com> <4A989C59.10801@emanon.com> <873a7bm3mm.fsf@mid.deneb.enyo.de> <4A99259E.8000202@emanon.com> <5E9C4E81-05BA-42F4-996B-F5BE79F8FEB4@jsyoung.net> <200908301938220.6B95064B.8300@clifden.donelan.com> <20090830201111.03018727@cs.columbia.edu> Message-ID: > I strongly second this. To quote a bumper sticker/slogan I've seen, > "if you didn't vote, you shouldn't complain". Some prominent > politicians have proposed something that we -- including me -- believe > to be a bad idea, not just on ideological grounds but because we think > that it won't accomplish its purported goals and may even be > counterproductive. I don't see a lot of network operators in Congress > -- if you know better, you really need to tell them. we need an easy way to click and opine, a la moveon.org, and other social and political orgs. maybe forwardon.org? randy From brunner at nic-naa.net Sun Aug 30 21:04:54 2009 From: brunner at nic-naa.net (Eric Brunner-Williams) Date: Sun, 30 Aug 2009 22:04:54 -0400 Subject: Ready to get your federal computer license? In-Reply-To: <20090830201111.03018727@cs.columbia.edu> References: <81CDFC77FB2DC54DB875D4F8FFC36CE00A923B797E@DSMAIL2HE.ds.ad.adp.com> <81CDFC77FB2DC54DB875D4F8FFC36CE00B7A593500@DSMAIL2HE.ds.ad.adp.com> <4A989C59.10801@emanon.com> <873a7bm3mm.fsf@mid.deneb.enyo.de> <4A99259E.8000202@emanon.com> <5E9C4E81-05BA-42F4-996B-F5BE79F8FEB4@jsyoung.net> <200908301938220.6B95064B.8300@clifden.donelan.com> <20090830201111.03018727@cs.columbia.edu> Message-ID: <4A9B2FC6.4000109@nic-naa.net> +1 I operate a Maine ISP/ASP, and Senator Snowe is my lobbying target. Steven M. Bellovin wrote: > On Sun, 30 Aug 2009 19:46:19 -0400 (EDT) > Sean Donelan wrote: > > >> On Sun, 30 Aug 2009, Jeff Young wrote: >> >>> The more troubling parts of this bill had to do with the President, >>> at his discretion, classifying parts of public networks as "critical >>> infrastructure" and so on. >>> >> Whatever your opinion, get involved. Let your representatives know >> about your better ideas. >> > > I strongly second this. To quote a bumper sticker/slogan I've seen, > "if you didn't vote, you shouldn't complain". Some prominent > politicians have proposed something that we -- including me -- believe > to be a bad idea, not just on ideological grounds but because we think > that it won't accomplish its purported goals and may even be > counterproductive. I don't see a lot of network operators in Congress > -- if you know better, you really need to tell them. > > Some folks on this list -- and I know there are a few, very > specifically including myself -- spend more than a little bit of time > not just worrying about public policy issues, but actually spending > time and effort on the subject. (I'm in D.C. right now, largely > because of a policy-related meeting on Tuesday.) I'll misuses a > security slogan I've seen on mass transit facilities in the New York > area: if you see something, say something. If no one tells Congress > that this is a bad idea, how should they know? > >>> currently living overseas and finding all of this very amusing... >>> >> If any other country has solved the problem of protecting >> Internet/data/cyber/critical/etc infrastructures and have some great >> ideas, it would be great to hear what those ideas are and how they >> did it. >> >> > Indeed. > > --Steve Bellovin, http://www.cs.columbia.edu/~smb > > > > From brunner at nic-naa.net Sun Aug 30 21:20:55 2009 From: brunner at nic-naa.net (Eric Brunner-Williams) Date: Sun, 30 Aug 2009 22:20:55 -0400 Subject: Ready to get your federal computer license? In-Reply-To: References: <81CDFC77FB2DC54DB875D4F8FFC36CE00A923B797E@DSMAIL2HE.ds.ad.adp.com> <81CDFC77FB2DC54DB875D4F8FFC36CE00B7A593500@DSMAIL2HE.ds.ad.adp.com> <4A989C59.10801@emanon.com> <873a7bm3mm.fsf@mid.deneb.enyo.de> <4A99259E.8000202@emanon.com> <5E9C4E81-05BA-42F4-996B-F5BE79F8FEB4@jsyoung.net> <200908301938220.6B95064B.8300@clifden.donelan.com> <20090830201111.03018727@cs.columbia.edu> Message-ID: <4A9B3387.7020801@nic-naa.net> randy, moveon is a maine-based org. it is an effective, fund raising, partisan organization. it is much more than a click-and-opine vehicle, it puts hundreds of thousands of dollars into competitive races, and has a competent political director. to create a "NagOn" we would have to hire or appoint a political director, and a financial director, and charge each with framing the issue, and executing a seven figure plan, and a communications director, to put the message with the money in targeted media markets, and finally, to show teeth, drop the margin of error, or on the order of high five, low six figures, in targeted congressional races, for challengers and incumbants. in about a year after starting down this path, the "Congressman, its NagOn on line one" conversation would be slightly different from today, and in several years time, more so. eric Randy Bush wrote: >> I strongly second this. To quote a bumper sticker/slogan I've seen, >> "if you didn't vote, you shouldn't complain". Some prominent >> politicians have proposed something that we -- including me -- believe >> to be a bad idea, not just on ideological grounds but because we think >> that it won't accomplish its purported goals and may even be >> counterproductive. I don't see a lot of network operators in Congress >> -- if you know better, you really need to tell them. >> > > we need an easy way to click and opine, a la moveon.org, and other > social and political orgs. maybe forwardon.org? > > randy > > > > From smb at cs.columbia.edu Sun Aug 30 21:28:29 2009 From: smb at cs.columbia.edu (Steven M. Bellovin) Date: Sun, 30 Aug 2009 22:28:29 -0400 Subject: Ready to get your federal computer license? In-Reply-To: <4A9B3387.7020801@nic-naa.net> References: <81CDFC77FB2DC54DB875D4F8FFC36CE00A923B797E@DSMAIL2HE.ds.ad.adp.com> <81CDFC77FB2DC54DB875D4F8FFC36CE00B7A593500@DSMAIL2HE.ds.ad.adp.com> <4A989C59.10801@emanon.com> <873a7bm3mm.fsf@mid.deneb.enyo.de> <4A99259E.8000202@emanon.com> <5E9C4E81-05BA-42F4-996B-F5BE79F8FEB4@jsyoung.net> <200908301938220.6B95064B.8300@clifden.donelan.com> <20090830201111.03018727@cs.columbia.edu> <4A9B3387.7020801@nic-naa.net> Message-ID: <20090830222829.49286bfc@cs.columbia.edu> On Sun, 30 Aug 2009 22:20:55 -0400 Eric Brunner-Williams wrote: > randy, > > moveon is a maine-based org. it is an effective, fund raising, > partisan organization. it is much more than a click-and-opine > vehicle, it puts hundreds of thousands of dollars into competitive > races, and has a competent political director. > > to create a "NagOn" we would have to hire or appoint a political > director, and a financial director, and charge each with framing the > issue, and executing a seven figure plan, and a communications > director, to put the message with the money in targeted media > markets, and finally, to show teeth, drop the margin of error, or on > the order of high five, low six figures, in targeted congressional > races, for challengers and incumbants. > > in about a year after starting down this path, the "Congressman, its > NagOn on line one" conversation would be slightly different from > today, and in several years time, more so. > "A journey of a thousand miles begins with a single step." I don't know that a NagOn is the best way or the only way to make progress. I do know that the most likely source of that kind of funding is (many of) our employers, who may not have technical excellence on the top of their lists. But I'm even more certain that if technical people never speak up, their message will never be heard, except perhaps by accident. --Steve Bellovin, http://www.cs.columbia.edu/~smb From erik_list at caneris.com Sun Aug 30 21:41:41 2009 From: erik_list at caneris.com (Erik L) Date: Sun, 30 Aug 2009 22:41:41 -0400 Subject: Link capacity upgrade threshold In-Reply-To: <20090830162259.992201CC09@ptavv.es.net> References: Your message of "Sun, 30 Aug 2009 21:04:15 +0900." , <20090830162259.992201CC09@ptavv.es.net> Message-ID: > > > If your 95th percentile utilization is at 80% capacity, > it's time to > > > start planning the upgrade. > > > > s/80/60/ > > > > the normal snmp and other averaging methods *really* miss > the bursts. > > s/60/40/ > What is this "upgrade" thing you all speak of? When your links become saturated, shouldn't you solve the problem by deploying DPI-based application-discriminatory throttling and start double-dipping your customers? After all, it's their fault for using up more bandwidth than your flawed business model told you they will use. (If you're not familiar with Bell Canada, it's OK if you don't get the joke). From hescominsoon at emmanuelcomputerconsulting.com Sun Aug 30 22:16:58 2009 From: hescominsoon at emmanuelcomputerconsulting.com (William Warren) Date: Sun, 30 Aug 2009 23:16:58 -0400 Subject: Ready to get your federal computer license? In-Reply-To: References: <81CDFC77FB2DC54DB875D4F8FFC36CE00A923B797E@DSMAIL2HE.ds.ad.adp.com> <81CDFC77FB2DC54DB875D4F8FFC36CE00B7A593500@DSMAIL2HE.ds.ad.adp.com> Message-ID: <4A9B40AA.9020209@emmanuelcomputerconsulting.com> On 8/28/2009 6:11 PM, Peter Beckman wrote: > On Fri, 28 Aug 2009, Hiers, David wrote: > >> Governments already license stock brokers, pilots, commercial drivers, >> accountants, engineers, all sorts of people whose mistakes can be >> measured in the loss of hundreds of lives and millions of dollars. > > "'The power company allowed their network security to be comprimised > by a > single Windows computer connected to the Internet in the main control > facility, so we unplugged the entire Internet to mitigate the attack,' > said Senator Rockefeller, the author of the bill that enabled the > President to take swift action after an unknown hacker used the > Internet > to break into Brominion Power's main control facility and turn off the > power to the entire East Coast. 'It will remain unplugged and > nobody in > the US will be allowed to connect to the Internet until the power is > back > on and this hacker is brought to justice.' > > Authorities are having a difficult time locating the hacker due to the > unavailability of the Internet and electricity, and cannot communicate > with lawmakers via traditional means due to the outage. A formal > request > to turn the power and Internet back on was sent on a pony earlier this > afternoon to lawmakers in DC." > > Can't wait. > > Beckman > --------------------------------------------------------------------------- > > Peter Beckman > Internet Guy > beckman at angryox.com > http://www.angryox.com/ > --------------------------------------------------------------------------- > > > ROFL! From mohacsi at niif.hu Mon Aug 31 02:41:03 2009 From: mohacsi at niif.hu (Mohacsi Janos) Date: Mon, 31 Aug 2009 09:41:03 +0200 (CEST) Subject: Link capacity upgrade threshold In-Reply-To: References: <3c3e3fca0908292115s12039efch61c0b1138530d814@mail.gmail.com> Message-ID: On Sun, 30 Aug 2009, Randy Bush wrote: >> If your 95th percentile utilization is at 80% capacity, it's time to >> start planning the upgrade. > > s/80/60/ > > the normal snmp and other averaging methods *really* miss the bursts. Agreed. Internet traffic is very burtsy. If you care your customer experience upgrade at 60-65% level. Especially if an interface is towards a customers is similar in bandwith of backbone links... Best Regards, Janos Mohacsi From Valdis.Kletnieks at vt.edu Mon Aug 31 10:42:09 2009 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Mon, 31 Aug 2009 11:42:09 -0400 Subject: Ready to get your federal computer license? In-Reply-To: Your message of "Sun, 30 Aug 2009 10:59:34 +1000." <5E9C4E81-05BA-42F4-996B-F5BE79F8FEB4@jsyoung.net> References: <81CDFC77FB2DC54DB875D4F8FFC36CE00A923B797E@DSMAIL2HE.ds.ad.adp.com> <81CDFC77FB2DC54DB875D4F8FFC36CE00B7A593500@DSMAIL2HE.ds.ad.adp.com> <4A989C59.10801@emanon.com> <873a7bm3mm.fsf@mid.deneb.enyo.de> <4A99259E.8000202@emanon.com> <5E9C4E81-05BA-42F4-996B-F5BE79F8FEB4@jsyoung.net> Message-ID: <40494.1251733329@turing-police.cc.vt.edu> On Sun, 30 Aug 2009 10:59:34 +1000, Jeff Young said: > Having met more than a few people in government IT, all jokes aside, > I think they're pretty well equipped to know when and if they need to > disconnect from the Internet, even without an executive order. Department of the Interior had *how* many court-ordered disconnections? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 226 bytes Desc: not available URL: From cgrundemann at gmail.com Mon Aug 31 10:57:32 2009 From: cgrundemann at gmail.com (Chris Grundemann) Date: Mon, 31 Aug 2009 09:57:32 -0600 Subject: Ready to get your federal computer license? In-Reply-To: <20090830222829.49286bfc@cs.columbia.edu> References: <81CDFC77FB2DC54DB875D4F8FFC36CE00A923B797E@DSMAIL2HE.ds.ad.adp.com> <873a7bm3mm.fsf@mid.deneb.enyo.de> <4A99259E.8000202@emanon.com> <5E9C4E81-05BA-42F4-996B-F5BE79F8FEB4@jsyoung.net> <200908301938220.6B95064B.8300@clifden.donelan.com> <20090830201111.03018727@cs.columbia.edu> <4A9B3387.7020801@nic-naa.net> <20090830222829.49286bfc@cs.columbia.edu> Message-ID: <443de7ad0908310857h5474a4dh8b4b1a8212297f8b@mail.gmail.com> On Sun, Aug 30, 2009 at 20:28, Steven M. Bellovin wrote: > On Sun, 30 Aug 2009 22:20:55 -0400 > Eric Brunner-Williams wrote: > >> randy, >> >> moveon is a maine-based org. it is an effective, fund raising, >> partisan organization. it is much more than a click-and-opine >> vehicle, it puts hundreds of thousands of dollars into competitive >> races, and has a competent political director. >> >> to create a "NagOn" we would have to hire or appoint a political >> director, and a financial director, and charge each with framing the >> issue, and executing a seven figure plan, and a communications >> director, to put the message with the money in targeted media >> markets, and finally, to show teeth, drop the margin of error, or on >> the order of high five, low six figures, in targeted congressional >> races, for challengers and incumbants. >> >> in about a year after starting down this path, the "Congressman, its >> NagOn on line one" conversation would be slightly different from >> today, and in several years time, more so. >> > "A journey of a thousand miles begins with a single step." > > I don't know that a NagOn is the best way or the only way to make > progress. ?I do know that the most likely source of that kind of > funding is (many of) our employers, who may not have technical > excellence on the top of their lists. ?But I'm even more certain that > if technical people never speak up, their message will never be heard, > except perhaps by accident. > > ? ? ? ? ? ? ? ?--Steve Bellovin, http://www.cs.columbia.edu/~smb > > I believe that this is exactly the kind of thing that the US ISOC Chapters should be (and are to varying degrees) involved in -- providing legitimate technical information and expert analysis of local, state and federal policies which impact the Internet, to those making the policies. The global ISOC already does this for ICANN and other international organizations, it seems fitting that the chapters do more of this here inside the USA. I encourage everyone with even a fleeting interest in tech-policy to seek out their local ISOC chapter (http://www.isoc.org/isoc/chapters/list.php?region=worldwide&status=A) and let them know that you care. I can tell you as the founding chair of the Colorado chapter that my largest hurdle today is getting active members to participate - I have funding, etc, just no help... (I invite everyone to contact me directly with suggestions and ideas in this vein - I have some vehicles in place to start making this happen quickly with a bit of help) ~Chris -- Chris Grundemann weblog.chrisgrundemann.com www.burningwiththebush.com www.coisoc.org From Valdis.Kletnieks at vt.edu Mon Aug 31 11:00:16 2009 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Mon, 31 Aug 2009 12:00:16 -0400 Subject: Ready to get your federal computer license? In-Reply-To: Your message of "Fri, 28 Aug 2009 16:51:39 CDT." <81CDFC77FB2DC54DB875D4F8FFC36CE00B7A593500@DSMAIL2HE.ds.ad.adp.com> References: <81CDFC77FB2DC54DB875D4F8FFC36CE00A923B797E@DSMAIL2HE.ds.ad.adp.com> <81CDFC77FB2DC54DB875D4F8FFC36CE00B7A593500@DSMAIL2HE.ds.ad.adp.com> Message-ID: <41445.1251734416@turing-police.cc.vt.edu> On Fri, 28 Aug 2009 16:51:39 CDT, "Hiers, David" said: > Governments already license stock brokers, pilots, commercial drivers, > accountants, engineers, all sorts of people whose mistakes can be measured > in the loss of hundreds of lives and millions of dollars. In many localities, hairdressers require licenses as well. Draw your own conclusions. ;) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 226 bytes Desc: not available URL: From jj at intelequest.com Mon Aug 31 11:16:48 2009 From: jj at intelequest.com (Jason Jenisch) Date: Mon, 31 Aug 2009 11:16:48 -0500 Subject: Ready to get your federal computer license? In-Reply-To: <81CDFC77FB2DC54DB875D4F8FFC36CE00B7A593500@DSMAIL2HE.ds.ad.adp.com> References: <81CDFC77FB2DC54DB875D4F8FFC36CE00A923B797E@DSMAIL2HE.ds.ad.adp.com> <81CDFC77FB2DC54DB875D4F8FFC36CE00B7A593500@DSMAIL2HE.ds.ad.adp.com> Message-ID: <4A9BF770.1080304@intelequest.com> Hiers, David wrote: > Governments already license stock brokers, pilots, commercial drivers, accountants, engineers, all sorts of people whose mistakes can be measured in the loss of hundreds of lives and millions of dollars. > > http://sip-trunking.tmcnet.com/topics/security/articles/63218-bill-give-president-emergency-power-internet-raises-concerns.htm > > > Good times.... > > > > David Hiers > > CCIE (R/S, V), CISSP > ADP Dealer Services > 2525 SW 1st Ave. > Suite 300W > Portland, OR 97201 > o: 503-205-4467 > f: 503-402-3277 > > > > This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. > > > > I must have missed something here... I cannot find in the article or the bill where it states or alludes to a federal computer license requirement for computer users. Is this just more fear mongering or is it in the bill? If it is ... where? Jason Jenisch From reese at inkworkswell.com Mon Aug 31 12:15:10 2009 From: reese at inkworkswell.com (Reese) Date: Mon, 31 Aug 2009 12:15:10 -0500 Subject: Ready to get your federal computer license? In-Reply-To: <40494.1251733329@turing-police.cc.vt.edu> References: <81CDFC77FB2DC54DB875D4F8FFC36CE00A923B797E@DSMAIL2HE.ds.ad.adp.com> <81CDFC77FB2DC54DB875D4F8FFC36CE00B7A593500@DSMAIL2HE.ds.ad.adp.com> <4A989C59.10801@emanon.com> <873a7bm3mm.fsf@mid.deneb.enyo.de> <4A99259E.8000202@emanon.com> <5E9C4E81-05BA-42F4-996B-F5BE79F8FEB4@jsyoung.net> <40494.1251733329@turing-police.cc.vt.edu> Message-ID: <4A9C051E.9090904@inkworkswell.com> Valdis.Kletnieks at vt.edu wrote: > On Sun, 30 Aug 2009 10:59:34 +1000, Jeff Young said: >> Having met more than a few people in government IT, all jokes aside, >> I think they're pretty well equipped to know when and if they need to >> disconnect from the Internet, even without an executive order. > > Department of the Interior had *how* many court-ordered disconnections? Does this tread on open "secrets," inside knowledge, or hoped-for info? Just asking, I'm guessing you know something I don't and I'd like to be in on it. OTOH, I'm pretty sure I agree with you on the merit and worth of licenses for hairdressers. It seems that the silly season besets us from the right and from the left. The M&W of government licenses for IT Pros has been debated and thoroughly discredited, elsewhere. Much like other things that have been thoroughly discredited but keep coming back again and again, until they pass when someone drops the hot potato. Follow the money, is the adage of yore. Who benefits immediately, from licensing IT Pros? Easy answer. Who sponsors them or their cause, if anyone? Or are we to believe that a few (dozen?) independent agencies are truly the source of this concerted, prolonged push? From mairhart at cisco.com Mon Aug 31 11:16:42 2009 From: mairhart at cisco.com (Michael Airhart) Date: Mon, 31 Aug 2009 11:16:42 -0500 Subject: Ready to get your federal computer license? In-Reply-To: <443de7ad0908310857h5474a4dh8b4b1a8212297f8b@mail.gmail.com > References: <81CDFC77FB2DC54DB875D4F8FFC36CE00A923B797E@DSMAIL2HE.ds.ad.adp.com> <873a7bm3mm.fsf@mid.deneb.enyo.de> <4A99259E.8000202@emanon.com> <5E9C4E81-05BA-42F4-996B-F5BE79F8FEB4@jsyoung.net> <200908301938220.6B95064B.8300@clifden.donelan.com> <20090830201111.03018727@cs.columbia.edu> <4A9B3387.7020801@nic-naa.net> <20090830222829.49286bfc@cs.columbia.edu> <443de7ad0908310857h5474a4dh8b4b1a8212297f8b@mail.gmail.com> Message-ID: <7.0.1.0.2.20090831110914.082cadd8@cisco.com> (speaking only for myself and no one else)... You make a good point Chris.. Regardless of any politician or bureaucrat's motive for taking an action, many (most?) are ill prepared to speak or even ponder the topic of "the Internet" (and the fancy series of tubes.. ) [much less make laws about it] I was in a local city council meeting recently while one of the council members was chiding a very polite Time Warner Cable "Gov't affairs" spokesperson on something the council person had obviously no clue about.. I was embarrassed for him and proud the TWC rep was able to remain professional.. Making our expertise available to politcos that want to learn sure seems like a good idea, but I suspect we have to be very careful not to run afoul of our employers rules and desires on such topics. >I believe that this is exactly the kind of thing that the US ISOC >Chapters should be (and are to varying degrees) involved in -- >providing legitimate technical information and expert analysis of >local, state and federal policies which impact the Internet, to those >making the policies. The global ISOC already does this for ICANN and >other international organizations, it seems fitting that the chapters >do more of this here inside the USA. > >I encourage everyone with even a fleeting interest in tech-policy to >seek out their local ISOC chapter >(http://www.isoc.org/isoc/chapters/list.php?region=worldwide&status=A) >and let them know that you care. I can tell you as the founding chair >of the Colorado chapter that my largest hurdle today is getting active >members to participate - I have funding, etc, just no help... (I >invite everyone to contact me directly with suggestions and ideas in >this vein - I have some vehicles in place to start making this happen >quickly with a bit of help) > > >~Chris From beckman at angryox.com Mon Aug 31 11:20:24 2009 From: beckman at angryox.com (Peter Beckman) Date: Mon, 31 Aug 2009 12:20:24 -0400 Subject: Ready to get your federal computer license? In-Reply-To: <4A9BF770.1080304@intelequest.com> References: <81CDFC77FB2DC54DB875D4F8FFC36CE00A923B797E@DSMAIL2HE.ds.ad.adp.com> <81CDFC77FB2DC54DB875D4F8FFC36CE00B7A593500@DSMAIL2HE.ds.ad.adp.com> <4A9BF770.1080304@intelequest.com> Message-ID: On Mon, 31 Aug 2009, Jason Jenisch wrote: > Hiers, David wrote: >> http://sip-trunking.tmcnet.com/topics/security/articles/63218-bill-give-president-emergency-power-internet-raises-concerns.htm > I must have missed something here... I cannot find in the article or the > bill where it states or alludes to a federal computer license > requirement for computer users. "The proposal also includes a federal certification program for "cyber security professionals," and a requirement that certain computer systems and networks in the private sector be managed by people who receive that license, CNET said." --------------------------------------------------------------------------- Peter Beckman Internet Guy beckman at angryox.com http://www.angryox.com/ --------------------------------------------------------------------------- From smb at cs.columbia.edu Mon Aug 31 11:31:02 2009 From: smb at cs.columbia.edu (Steven M. Bellovin) Date: Mon, 31 Aug 2009 12:31:02 -0400 Subject: Ready to get your federal computer license? In-Reply-To: <4A9C051E.9090904@inkworkswell.com> References: <81CDFC77FB2DC54DB875D4F8FFC36CE00A923B797E@DSMAIL2HE.ds.ad.adp.com> <81CDFC77FB2DC54DB875D4F8FFC36CE00B7A593500@DSMAIL2HE.ds.ad.adp.com> <4A989C59.10801@emanon.com> <873a7bm3mm.fsf@mid.deneb.enyo.de> <4A99259E.8000202@emanon.com> <5E9C4E81-05BA-42F4-996B-F5BE79F8FEB4@jsyoung.net> <40494.1251733329@turing-police.cc.vt.edu> <4A9C051E.9090904@inkworkswell.com> Message-ID: <20090831123102.6261e883@cs.columbia.edu> On Mon, 31 Aug 2009 12:15:10 -0500 Reese wrote: > Valdis.Kletnieks at vt.edu wrote: > > On Sun, 30 Aug 2009 10:59:34 +1000, Jeff Young said: > >> Having met more than a few people in government IT, all jokes > >> aside, I think they're pretty well equipped to know when and if > >> they need to disconnect from the Internet, even without an > >> executive order. > > > > Department of the Interior had *how* many court-ordered > > disconnections? > > Does this tread on open "secrets," inside knowledge, or hoped-for > info? Just asking, I'm guessing you know something I don't and I'd > like to be in on it. > I'm not sure what you're asking. Those disconnections were well-covered in the press. Start with http://www.doi.gov/news/grilesmemo.htm but there's a lot more that a quick google search will find. --Steve Bellovin, http://www.cs.columbia.edu/~smb From jbates at brightok.net Mon Aug 31 12:13:00 2009 From: jbates at brightok.net (Jack Bates) Date: Mon, 31 Aug 2009 12:13:00 -0500 Subject: Ready to get your federal computer license? In-Reply-To: References: <81CDFC77FB2DC54DB875D4F8FFC36CE00A923B797E@DSMAIL2HE.ds.ad.adp.com> <81CDFC77FB2DC54DB875D4F8FFC36CE00B7A593500@DSMAIL2HE.ds.ad.adp.com> <4A9BF770.1080304@intelequest.com> Message-ID: <4A9C049C.6080906@brightok.net> Peter Beckman wrote: > "The proposal also includes a federal certification program for "cyber > security professionals," and a requirement that certain computer systems > and networks in the private sector be managed by people who receive that > license, CNET said." Presumably, this is to increase security of private sector networks that interconnect with government networks and high risk networks such as banks and utilities. Presumably it wouldn't mandate the social networking, ESP/ISP sectors. Jack From nanog-amuse at foofus.com Mon Aug 31 12:17:50 2009 From: nanog-amuse at foofus.com (AMuse) Date: Mon, 31 Aug 2009 10:17:50 -0700 Subject: Ready to get your federal computer license? In-Reply-To: <4A9C049C.6080906@brightok.net> References: <81CDFC77FB2DC54DB875D4F8FFC36CE00A923B797E@DSMAIL2HE.ds.ad.adp.com> <81CDFC77FB2DC54DB875D4F8FFC36CE00B7A593500@DSMAIL2HE.ds.ad.adp.com> <4A9BF770.1080304@intelequest.com> <4A9C049C.6080906@brightok.net> Message-ID: <4A9C05BE.9050003@foofus.com> Perhaps it's intended to be a workaround to the current problem with a lot of government IT Security: The (big) contractors are told to follow IT security guidelines, at which point they point back to their contract and say "That's not in the statement of work, lets renegotiate the contract and cost it out." Jack Bates wrote: > Peter Beckman wrote: >> "The proposal also includes a federal certification program for "cyber >> security professionals," and a requirement that certain computer >> systems >> and networks in the private sector be managed by people who receive >> that >> license, CNET said." > > Presumably, this is to increase security of private sector networks > that interconnect with government networks and high risk networks such > as banks and utilities. Presumably it wouldn't mandate the social > networking, ESP/ISP sectors. > > Jack From hiersd at gmail.com Mon Aug 31 12:48:20 2009 From: hiersd at gmail.com (David Hiers) Date: Mon, 31 Aug 2009 10:48:20 -0700 Subject: Ready to get your federal computer license? In-Reply-To: <40494.1251733329@turing-police.cc.vt.edu> References: <81CDFC77FB2DC54DB875D4F8FFC36CE00A923B797E@DSMAIL2HE.ds.ad.adp.com> <81CDFC77FB2DC54DB875D4F8FFC36CE00B7A593500@DSMAIL2HE.ds.ad.adp.com> <4A989C59.10801@emanon.com> <873a7bm3mm.fsf@mid.deneb.enyo.de> <4A99259E.8000202@emanon.com> <5E9C4E81-05BA-42F4-996B-F5BE79F8FEB4@jsyoung.net> <40494.1251733329@turing-police.cc.vt.edu> Message-ID: <2873f3700908311048u728f6631u684faddb3ffa5641@mail.gmail.com> I guess the precedence for blocking is the way cops can close airspace, roads, and any piece of property when needed. If you accept the notion that we've built private and public "roads" and "buildings" on the "information superhighway", the notion of emergency roadblocks, crime-scene tape, traffic cameras, and bears-in-the-air can't be too far behind. I didn't mean to imply that computer *users* would need a license, but that many in NANOG would probably be considered as license candidates by that bill. My message was sent to NANOG (which is not just your average bunch of users) and is best understood in that context. I may be wrong, but I suspect that most NANOG subscribers have a security aspect to their job. Thanks, David >I must have missed something here... I cannot find in the article or the >bill where it states or alludes to a federal computer license >requirement for computer users. >Is this just more fear mongering or is it in the bill? If it is ... where? >Jason Jenisch David On Mon, Aug 31, 2009 at 8:42 AM, wrote: > On Sun, 30 Aug 2009 10:59:34 +1000, Jeff Young said: >> Having met more than a few people in government IT, all jokes aside, >> I think they're pretty well equipped to know when and if they need to >> disconnect from the Internet, even without an executive order. > > Department of the Interior had *how* many court-ordered disconnections? > From reese at inkworkswell.com Mon Aug 31 13:57:24 2009 From: reese at inkworkswell.com (Reese) Date: Mon, 31 Aug 2009 13:57:24 -0500 Subject: Ready to get your federal computer license? In-Reply-To: <20090831123102.6261e883@cs.columbia.edu> References: <81CDFC77FB2DC54DB875D4F8FFC36CE00A923B797E@DSMAIL2HE.ds.ad.adp.com> <81CDFC77FB2DC54DB875D4F8FFC36CE00B7A593500@DSMAIL2HE.ds.ad.adp.com> <4A989C59.10801@emanon.com> <873a7bm3mm.fsf@mid.deneb.enyo.de> <4A99259E.8000202@emanon.com> <5E9C4E81-05BA-42F4-996B-F5BE79F8FEB4@jsyoung.net> <40494.1251733329@turing-police.cc.vt.edu> <4A9C051E.9090904@inkworkswell.com> <20090831123102.6261e883@cs.columbia.edu> Message-ID: <4A9C1D14.9060602@inkworkswell.com> Steven M. Bellovin wrote: > I'm not sure what you're asking. Those disconnections were > well-covered in the press. Start with > http://www.doi.gov/news/grilesmemo.htm but there's a lot more that a > quick google search will find. A news-item or -event I missed for whatever reason, okay. I'll consult Google. Thank you, Reese From marcus.sachs at verizon.com Mon Aug 31 13:06:56 2009 From: marcus.sachs at verizon.com (Sachs, Marcus Hans (Marc)) Date: Mon, 31 Aug 2009 14:06:56 -0400 Subject: Ready to get your federal computer license? In-Reply-To: References: <81CDFC77FB2DC54DB875D4F8FFC36CE00A923B797E@DSMAIL2HE.ds.ad.adp.com><81CDFC77FB2DC54DB875D4F8FFC36CE00B7A593500@DSMAIL2HE.ds.ad.adp.com><4A9BF770.1080304@intelequest.com> Message-ID: <81D582C724CA1046A279A7EE1299638B01D35828@FHDP1LUMXCV24.us.one.verizon.com> It's not a proposed "license for computer users" but rather a proposal to license computer security professionals. Here is the draft bill text, so that we are all on the same sheet of music: TITLE I-WORKFORCE DEVELOPMENT SEC. 101. CERTIFICATION AND TRAINING OF CYBERSECURITY PROFESSIONALS. (a) IN GENERAL.-Within 1 year after the date of enactment of this Act, the Secretary of Commerce, in consultation with relevant Federal agencies, industry sectors, and nongovernmental organizations, shall develop or coordinate and integrate a national certification, and periodic recertification program for cybersecurity professionals. (b) TRAINING AND DEVELOPMENT.-The Secretary of Commerce, in consultation with relevant Federal agencies, industry sectors, and nongovernmental organizations, shall devise a strategy to improve, increase, and coordinate cybersecurity training across all sectors. (c) FEDERAL EMPLOYEES.-The Secretary, in cooperation with the Director of the Office of Personnel Management and other Federal departments and agencies, shall develop and implement a plan to train cybersecurity professionals across the Federal government to ensure they achieve and maintain certification. (d) CERTIFICATION.-Beginning 3 years after the date of enactment of this Act, it shall be unlawful for an individual who is not certified under the program to represent himself or herself as a cybersecurity professional. (e) CERTIFIED SERVICE PROVIDER REQUIREMENT.-Notwithstanding any provision of law to the contrary, the head of a Federal agency may not use, or permit the use of, cybersecurity services for that agency that are not managed by a cybersecurity professional who is certified under the program. It is unlawful for the operator of an information system or network designated by the President, or the President's designee, as a critical infrastructure information system or network, to use, or permit the use of, cybersecurity services for that system or net work that are not managed by a cybersecurity professional who is certified under the program. A question for the NANOG community - if this section were to only apply to US government employees would it be acceptable? In other words, strike any reference to the private sector (except perhaps for those in the private sector who are under contract to perform government work.) Marc -- Marcus H. Sachs, P.E. Executive Director, National Security and Cyber Policy Office of Federal Government Relations Verizon, 1300 I (eye) St. NW Suite 400 W Washington, D.C. 20005 USA tel +1 202 515 2463 fax +1 202 336 7921 -----Original Message----- From: Peter Beckman [mailto:beckman at angryox.com] Sent: Monday, August 31, 2009 12:20 PM To: Jason Jenisch Cc: nanog at nanog.org; Hiers, David Subject: Re: Ready to get your federal computer license? On Mon, 31 Aug 2009, Jason Jenisch wrote: > Hiers, David wrote: >> http://sip-trunking.tmcnet.com/topics/security/articles/63218-bill-give-president-emergency-power-internet-raises-concerns.htm > I must have missed something here... I cannot find in the article or the > bill where it states or alludes to a federal computer license > requirement for computer users. "The proposal also includes a federal certification program for "cyber security professionals," and a requirement that certain computer systems and networks in the private sector be managed by people who receive that license, CNET said." --------------------------------------------------------------------------- Peter Beckman Internet Guy beckman at angryox.com http://www.angryox.com/ --------------------------------------------------------------------------- From jdfalk-lists at cybernothing.org Mon Aug 31 14:22:20 2009 From: jdfalk-lists at cybernothing.org (J.D. Falk) Date: Mon, 31 Aug 2009 13:22:20 -0600 Subject: Ready to get your federal computer license? In-Reply-To: <4A989C59.10801@emanon.com> References: <81CDFC77FB2DC54DB875D4F8FFC36CE00A923B797E@DSMAIL2HE.ds.ad.adp.com> <81CDFC77FB2DC54DB875D4F8FFC36CE00B7A593500@DSMAIL2HE.ds.ad.adp.com> <4A989C59.10801@emanon.com> Message-ID: <4A9C22EC.6060305@cybernothing.org> Scott Morris wrote: > So if someone hacks the electric grid, does it not make sense to unplug > that portion of the infrastructrure from the Internet until the problem > is fixed? (e.g. shut down traffic to/from) I think someone wrote an > article after WAY over-thinking this whole thing and everyone else jumps > on the bandwagon. Declan does that a lot. It's very annoying, but I suppose cnet has never claimed to be an impartial news organization...or have they? -- J.D. Falk From Valdis.Kletnieks at vt.edu Mon Aug 31 14:24:56 2009 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Mon, 31 Aug 2009 15:24:56 -0400 Subject: Ready to get your federal computer license? In-Reply-To: Your message of "Mon, 31 Aug 2009 14:06:56 EDT." <81D582C724CA1046A279A7EE1299638B01D35828@FHDP1LUMXCV24.us.one.verizon.com> References: <81CDFC77FB2DC54DB875D4F8FFC36CE00A923B797E@DSMAIL2HE.ds.ad.adp.com> <81CDFC77FB2DC54DB875D4F8FFC36CE00B7A593500@DSMAIL2HE.ds.ad.adp.com> <4A9BF770.1080304@intelequest.com> <81D582C724CA1046A279A7EE1299638B01D35828@FHDP1LUMXCV24.us.one.verizon.com> Message-ID: <53365.1251746696@turing-police.cc.vt.edu> On Mon, 31 Aug 2009 14:06:56 EDT, "Sachs, Marcus Hans (Marc)" said: > (d) CERTIFICATION.-Beginning 3 years after the date of enactment of > this Act, it shall be unlawful for an individual who is not certified > under the program to represent himself or herself as a cybersecurity > professional. Highly unlikely that 3 years is sufficient time to devise a certification, a testing program, and get enough people certified. 5 years would be much more reasonable. It will probably take over a year just to thrash out what a "certification" is. Consider the vast difference in scope and depth between a CISSP and one of the GIAC certs. (Ghod forbid somebody suggest something rational like "upper managers need a CISSP-ish cert and line emplouees need a relevant GIAC-ish cert.. :) > (e) CERTIFIED SERVICE PROVIDER REQUIREMENT.-Notwithstanding any > provision of law to the contrary, the head of a Federal agency may not > use, or permit the use of, cybersecurity services for that agency that > are not managed by a cybersecurity professional who is certified under > the program. Unintended consequences - will this encourage the head of an agency to instead say "screw it" and *not* use any cybersecurity services? > A question for the NANOG community - if this section were to only apply > to US government employees would it be acceptable? In other words, > strike any reference to the private sector (except perhaps for those in > the private sector who are under contract to perform government work.) Limiting it to "US government agencies, employees, and contractors" would certainly trim out about 95% of the contentious areas. But it still leaves me, personally, on the hot seat - am I on the hook because I'm responsible for research data that's NSF-funded? ;) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 226 bytes Desc: not available URL: From hiersd at gmail.com Mon Aug 31 15:06:34 2009 From: hiersd at gmail.com (David Hiers) Date: Mon, 31 Aug 2009 13:06:34 -0700 Subject: Ready to get your federal computer license? In-Reply-To: <53365.1251746696@turing-police.cc.vt.edu> References: <81CDFC77FB2DC54DB875D4F8FFC36CE00A923B797E@DSMAIL2HE.ds.ad.adp.com> <81CDFC77FB2DC54DB875D4F8FFC36CE00B7A593500@DSMAIL2HE.ds.ad.adp.com> <4A9BF770.1080304@intelequest.com> <81D582C724CA1046A279A7EE1299638B01D35828@FHDP1LUMXCV24.us.one.verizon.com> <53365.1251746696@turing-police.cc.vt.edu> Message-ID: <2873f3700908311306g248f0f66icde294016154b730@mail.gmail.com> > Highly unlikely that 3 years is sufficient time to devise a certification, No big deal; they could just adopt the CISSP/GIAC cert without modification as an interim step. Existing certs are already being used in some court cases: http://www.wisbar.org/AM/Template.cfm?Section=Home&TEMPLATE=/CM/ContentDisplay.cfm&CONTENTID=70438 > Unintended consequences - will this encourage the head of an agency to > instead say "screw it" and *not* use any cybersecurity services? Not likely. Corporate Officers must already make decisions that meet a wide range of existing "reasonable man" tests with respect to security. This is not the only law/regulation in existence. David From justin at justinshore.com Mon Aug 31 16:09:17 2009 From: justin at justinshore.com (Justin Shore) Date: Mon, 31 Aug 2009 16:09:17 -0500 Subject: Ready to get your federal computer license? In-Reply-To: <20090830201111.03018727@cs.columbia.edu> References: <81CDFC77FB2DC54DB875D4F8FFC36CE00A923B797E@DSMAIL2HE.ds.ad.adp.com> <81CDFC77FB2DC54DB875D4F8FFC36CE00B7A593500@DSMAIL2HE.ds.ad.adp.com> <4A989C59.10801@emanon.com> <873a7bm3mm.fsf@mid.deneb.enyo.de> <4A99259E.8000202@emanon.com> <5E9C4E81-05BA-42F4-996B-F5BE79F8FEB4@jsyoung.net> <200908301938220.6B95064B.8300@clifden.donelan.com> <20090830201111.03018727@cs.columbia.edu> Message-ID: <4A9C3BFD.80609@justinshore.com> Steven M. Bellovin wrote: > On Sun, 30 Aug 2009 19:46:19 -0400 (EDT) > Sean Donelan wrote: > >> On Sun, 30 Aug 2009, Jeff Young wrote: >>> The more troubling parts of this bill had to do with the President, >>> at his discretion, classifying parts of public networks as "critical >>> infrastructure" and so on. >> Whatever your opinion, get involved. Let your representatives know >> about your better ideas. > > I strongly second this. To quote a bumper sticker/slogan I've seen, > "if you didn't vote, you shouldn't complain". "Democracy is not a spectator's sport" Justin Shore From nanog at wbsconnect.com Mon Aug 31 16:35:44 2009 From: nanog at wbsconnect.com (nanog at wbsconnect.com) Date: Mon, 31 Aug 2009 15:35:44 -0600 (MDT) Subject: Beware: a very bad precedent set In-Reply-To: <689399765.145151251754503975.JavaMail.root@zimbra.wbsconnect.com> Message-ID: <737736526.145171251754543998.JavaMail.root@zimbra.wbsconnect.com> http://finance.yahoo.com/news/Louis-Vuitton-Awarded-324-bw-3561952192.html?x=0&.v=1 NEW YORK--(BUSINESS WIRE)--Louis Vuitton Malletier, S.A. (?Louis Vuitton?) part of LVMH, the world?s leading luxury group, today announced that it has won the lawsuit it filed in 2007 against the California based Internet hosting business of Akanoc Solutions, Inc., Managed Solutions Group, Inc., and Steven Chen (the ?Akanoc Defendants?) in the United States District Court, Northern District of California (San Jose). On August 28th, the jury found the Akanoc Defendants liable for contributory trademark and copyright infringement, and awarded statutory damages in the amount of $32,400,000.00. The court is expected shortly to issue a permanent injunction banning the Akanoc Defendants from hosting websites that sell counterfeit or infringing Louis Vuitton goods. Any and all nefarious activity alleged in this lawsuit was conducted by a customer, of a customer, of a customer yet the hosting provider was found liable, not the actual criminal manufacturing and selling the fakes. We had all better watch our backs since it seems that claims of not being able to inspected tens of millions of packets per second is no longer a viable excuse. From jbates at brightok.net Mon Aug 31 16:51:14 2009 From: jbates at brightok.net (Jack Bates) Date: Mon, 31 Aug 2009 16:51:14 -0500 Subject: Beware: a very bad precedent set In-Reply-To: <737736526.145171251754543998.JavaMail.root@zimbra.wbsconnect.com> References: <737736526.145171251754543998.JavaMail.root@zimbra.wbsconnect.com> Message-ID: <4A9C45D2.1000605@brightok.net> nanog at wbsconnect.com wrote: > Any and all nefarious activity alleged in this lawsuit was conducted by a customer, of a customer, of a customer yet the hosting provider was found liable, not the actual criminal manufacturing and selling the fakes. > > We had all better watch our backs since it seems that claims of not being able to inspected tens of millions of packets per second is no longer a viable excuse. > Hmmm. I thought DMCA made it quite clear that a service provider cannot ignore reports. "The Akanoc Defendants? specific business model of providing unmanaged server capacity to web hosting resellers does not exempt them from taking active steps to effectively prevent infringing activity upon notification from an intellectual property rights owner. " I consider that the more important statement in the article. The "upon notification" being the largest issue. Don't know if DMCA covers anything outside the scope of copyright, but I think it's been generally accepted that ignoring reports of infringement can bring about liability. Jack From Greg.Whynott at oicr.on.ca Mon Aug 31 16:55:12 2009 From: Greg.Whynott at oicr.on.ca (Greg Whynott) Date: Mon, 31 Aug 2009 17:55:12 -0400 Subject: Beware: a very bad precedent set In-Reply-To: <737736526.145171251754543998.JavaMail.root@zimbra.wbsconnect.com> References: <689399765.145151251754503975.JavaMail.root@zimbra.wbsconnect.com>, <737736526.145171251754543998.JavaMail.root@zimbra.wbsconnect.com> Message-ID: that is so sad.... makes me very angry reading this. -g ________________________________________ From: nanog at wbsconnect.com [nanog at wbsconnect.com] Sent: Monday, August 31, 2009 5:35 PM To: nanog at nanog.org Subject: Beware: a very bad precedent set http://finance.yahoo.com/news/Louis-Vuitton-Awarded-324-bw-3561952192.html?x=0&.v=1 NEW YORK--(BUSINESS WIRE)--Louis Vuitton Malletier, S.A. (?Louis Vuitton?) part of LVMH, the world?s leading luxury group, today announced that it has won the lawsuit it filed in 2007 against the California based Internet hosting business of Akanoc Solutions, Inc., Managed Solutions Group, Inc., and Steven Chen (the ?Akanoc Defendants?) in the United States District Court, Northern District of California (San Jose). On August 28th, the jury found the Akanoc Defendants liable for contributory trademark and copyright infringement, and awarded statutory damages in the amount of $32,400,000.00. The court is expected shortly to issue a permanent injunction banning the Akanoc Defendants from hosting websites that sell counterfeit or infringing Louis Vuitton goods. Any and all nefarious activity alleged in this lawsuit was conducted by a customer, of a customer, of a customer yet the hosting provider was found liable, not the actual criminal manufacturing and selling the fakes. We had all better watch our backs since it seems that claims of not being able to inspected tens of millions of packets per second is no longer a viable excuse. From j at arpa.com Mon Aug 31 17:10:50 2009 From: j at arpa.com (jamie) Date: Mon, 31 Aug 2009 17:10:50 -0500 Subject: OT Re: Beware: a very bad precedent set Message-ID: <6ff30abd0908311510o222e36f3x8f21f208c58efd8b@mail.gmail.com> Wrong, wrong, wrong, Dr. Wrongy W. Wrongenstein. If you're served with notice that you have a downstream customer /conducting business that's illegal or tortious/ , you can't ignore it.. IANAL(yet), but ISPs don't really enjoy the same rights as "public carriers" s/a telcos. And in this case, ISP didnt act to protect itself under safe-harbor. They just liked the cash. They're not responsible for inspecting "tens of millions of packets per second". Where'd that come from? They _are_ responsible for ignoring FedEx'd documents containing C&Ds / notices of infringement. Some 15 violations, if you read the decision. (C07-03952JW) Jury findings: 10: "Did [Louis Vuitton] prove that [ISP] knew ... that one or more of (their) customers were using (their services) to directly infringe the copyrights of [Vuitton] and that (ISP could still provide services but not the infringing website(s))?" -YES- 12: "Did [ISP] (act in a manner that would protect them under DMCA Safe Harbor"? -NO- 13: "Did [ISP] (do this willfully)?" -YES- Your business break the law in the name of the Dollar, your business will pay. That's the precedent here. And, btw, "How do I configure my router for legal discussions on nanog-L?" OT. -j On Mon, Aug 31, 2009 at 4:35 PM, wrote: > > http://finance.yahoo.com/news/Louis-Vuitton-Awarded-324-bw-3561952192.html?x=0&.v=1 > > NEW YORK--(BUSINESS WIRE)--Louis Vuitton Malletier, S.A. (?Louis Vuitton?) > part of LVMH, the world?s leading luxury group, today announced that it has > won the lawsuit it filed in 2007 against the California based Internet > hosting business of Akanoc Solutions, Inc., Managed Solutions Group, Inc., > and Steven Chen (the ?Akanoc Defendants?) in the United States District > Court, Northern District of California (San Jose). On August 28th, the jury > found the Akanoc Defendants liable for contributory trademark and copyright > infringement, and awarded statutory damages in the amount of $32,400,000.00. > The court is expected shortly to issue a permanent injunction banning the > Akanoc Defendants from hosting websites that sell counterfeit or infringing > Louis Vuitton goods. > > Any and all nefarious activity alleged in this lawsuit was conducted by a > customer, of a customer, of a customer yet the hosting provider was found > liable, not the actual criminal manufacturing and selling the fakes. > > We had all better watch our backs since it seems that claims of not being > able to inspected tens of millions of packets per second is no longer a > viable excuse. > > From marka at isc.org Mon Aug 31 17:12:33 2009 From: marka at isc.org (Mark Andrews) Date: Tue, 01 Sep 2009 08:12:33 +1000 Subject: Beware: a very bad precedent set In-Reply-To: Your message of "Mon, 31 Aug 2009 16:51:14 EST." <4A9C45D2.1000605@brightok.net> References: <737736526.145171251754543998.JavaMail.root@zimbra.wbsconnect.com> <4A9C45D2.1000605@brightok.net> Message-ID: <200908312212.n7VMCXtO017475@drugs.dv.isc.org> In message <4A9C45D2.1000605 at brightok.net>, Jack Bates writes: > nanog at wbsconnect.com wrote: > > Any and all nefarious activity alleged in this lawsuit was conducted by a c > ustomer, of a customer, of a customer yet the hosting provider was found liab > le, not the actual criminal manufacturing and selling the fakes. > > > > We had all better watch our backs since it seems that claims of not being a > ble to inspected tens of millions of packets per second is no longer a viable > excuse. > > > > Hmmm. I thought DMCA made it quite clear that a service provider cannot > ignore reports. > > "The Akanoc Defendants??? specific business model of providing unmanaged > server capacity to web hosting resellers does not exempt them from > taking active steps to effectively prevent infringing activity upon > notification from an intellectual property rights owner. " > > I consider that the more important statement in the article. The "upon notification" being the largest issue. Don't know if DMCA covers > anything outside the scope of copyright, but I think it's been generally > accepted that ignoring reports of infringement can bring about liability. > > Jack It will be interesting to see the court cases against ISP's that don't shutdown other illegal activities once they have been notified. abuse@ better not be a blackhole or you are putting yourself at risk based on this. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From bclark at spectraaccess.com Mon Aug 31 17:29:34 2009 From: bclark at spectraaccess.com (Bret Clark) Date: Mon, 31 Aug 2009 18:29:34 -0400 Subject: Beware: a very bad precedent set In-Reply-To: <200908312212.n7VMCXtO017475@drugs.dv.isc.org> References: <737736526.145171251754543998.JavaMail.root@zimbra.wbsconnect.com> <4A9C45D2.1000605@brightok.net> <200908312212.n7VMCXtO017475@drugs.dv.isc.org> Message-ID: <4A9C4ECE.4010501@spectraaccess.com> How does this stuff ever make it to court??? Why is it an ISP is responsible for policing it's customers? I'm constantly getting called up from scammers trying to offering me bogus warranty insurance for cars I don't own...does that mean I can sue Verizon because they are letting scammers use their network? It doesn't mention anything in the article,. but I'm wondering if the ISP received a court order to shut down the customer and ignored it, then I can see why the ISP lost the case. > It will be interesting to see the court cases against ISP's that > don't shutdown other illegal activities once they have been notified. > abuse@ better not be a blackhole or you are putting yourself at risk > based on this. > > Mark > From rrodriguez at ifbyphone.com Mon Aug 31 17:34:27 2009 From: rrodriguez at ifbyphone.com (Robin Rodriguez) Date: Mon, 31 Aug 2009 17:34:27 -0500 Subject: Beware: a very bad precedent set In-Reply-To: <4A9C4ECE.4010501@spectraaccess.com> References: <737736526.145171251754543998.JavaMail.root@zimbra.wbsconnect.com> <4A9C45D2.1000605@brightok.net> <200908312212.n7VMCXtO017475@drugs.dv.isc.org> <4A9C4ECE.4010501@spectraaccess.com> Message-ID: <79B710BE-A5AC-4D01-B966-4F159155D495@ifbyphone.com> On Aug 31, 2009, at 5:29 PM, Bret Clark wrote: > How does this stuff ever make it to court??? Why is it an ISP is > responsible for policing it's customers? I'm constantly getting > called up from scammers trying to offering me bogus warranty > insurance for cars I don't own...does that mean I can sue Verizon > because they are letting scammers use their network? > > It doesn't mention anything in the article,. but I'm wondering if > the ISP received a court order to shut down the customer and ignored > it, then I can see why the ISP lost the case. >> It will be interesting to see the court cases against ISP's that >> don't shutdown other illegal activities once they have been notified. >> abuse@ better not be a blackhole or you are putting yourself at risk >> based on this. >> >> Mark >> > > As was pointed out very early on, you as an xSP do not enjoy common carrier status from the FCC like an ILEC would receive, now whether that is right or wrong is another matter of debate.... -- Robin D. Rodriguez Ifbyphone, Inc. rrodriguez at ifbyphone.com From peter.hicks at poggs.co.uk Mon Aug 31 17:41:58 2009 From: peter.hicks at poggs.co.uk (Peter Hicks) Date: Mon, 31 Aug 2009 23:41:58 +0100 Subject: Beware: a very bad precedent set In-Reply-To: <4A9C4ECE.4010501@spectraaccess.com> References: <737736526.145171251754543998.JavaMail.root@zimbra.wbsconnect.com> <4A9C45D2.1000605@brightok.net> <200908312212.n7VMCXtO017475@drugs.dv.isc.org> <4A9C4ECE.4010501@spectraaccess.com> Message-ID: <4A9C51B6.6050306@poggs.co.uk> Bret Clark wrote: > How does this stuff ever make it to court??? Why is it an ISP is > responsible for policing it's customers? I'm constantly getting called > up from scammers trying to offering me bogus warranty insurance for cars > I don't own...does that mean I can sue Verizon because they are letting > scammers use their network? > > It doesn't mention anything in the article,. but I'm wondering if the > ISP received a court order to shut down the customer and ignored it, > then I can see why the ISP lost the case. There's a world of difference between proactive policing and acting reactively on receipt of notice that your customers are doing specific badness... or not. Poggs From nenolod at systeminplace.net Mon Aug 31 17:47:17 2009 From: nenolod at systeminplace.net (William Pitcock) Date: Mon, 31 Aug 2009 22:47:17 +0000 Subject: Beware: a very bad precedent set Message-ID: <2065159430-1251758639-cardhu_decombobulator_blackberry.rim.net-1581782702-@bda138.bisx.prod.on.blackberry> I would have figured that everyone would have learned that abuse@ being a blackhole is a bad idea from what happened to Atrivo/InterCage. William ------Original Message------ From: Mark Andrews To: nanog at nanog.org Subject: Re: Beware: a very bad precedent set Sent: Aug 31, 2009 5:12 PM In message <4A9C45D2.1000605 at brightok.net>, Jack Bates writes: > nanog at wbsconnect.com wrote: > > Any and all nefarious activity alleged in this lawsuit was conducted by a c > ustomer, of a customer, of a customer yet the hosting provider was found liab > le, not the actual criminal manufacturing and selling the fakes. > > > > We had all better watch our backs since it seems that claims of not being a > ble to inspected tens of millions of packets per second is no longer a viable > excuse. > > > > Hmmm. I thought DMCA made it quite clear that a service provider cannot > ignore reports. > > "The Akanoc Defendants??? specific business model of providing unmanaged > server capacity to web hosting resellers does not exempt them from > taking active steps to effectively prevent infringing activity upon > notification from an intellectual property rights owner. " > > I consider that the more important statement in the article. The "upon notification" being the largest issue. Don't know if DMCA covers > anything outside the scope of copyright, but I think it's been generally > accepted that ignoring reports of infringement can bring about liability. > > Jack It will be interesting to see the court cases against ISP's that don't shutdown other illegal activities once they have been notified. abuse@ better not be a blackhole or you are putting yourself at risk based on this. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org -- William Pitcock SystemInPlace - Simple Hosting Solutions 1-866-519-6149 From simon at darkmere.gen.nz Mon Aug 31 18:42:11 2009 From: simon at darkmere.gen.nz (Simon Lyall) Date: Tue, 1 Sep 2009 11:42:11 +1200 (NZST) Subject: ADMIN: Political and legal threads Message-ID: A reminder that the NANOG acceptable use policy states: 6. Postings of political, philosophical, and legal nature are prohibited. Please ensure that all posts to the list follow this policy. Simon for the NANOG MLC -- Simon Lyall | Very Busy | Web: http://www.darkmere.gen.nz/ "To stay awake all night adds a day to your life" - Stilgar | eMT. From herrin-nanog at dirtside.com Mon Aug 31 18:47:53 2009 From: herrin-nanog at dirtside.com (William Herrin) Date: Mon, 31 Aug 2009 19:47:53 -0400 Subject: Beware: a very bad precedent set In-Reply-To: <4A9C45D2.1000605@brightok.net> References: <737736526.145171251754543998.JavaMail.root@zimbra.wbsconnect.com> <4A9C45D2.1000605@brightok.net> Message-ID: <3c3e3fca0908311647o47b2c467y9bf40c9986e64205@mail.gmail.com> On Mon, Aug 31, 2009 at 5:51 PM, Jack Bates wrote: > "The Akanoc Defendants? specific business model of providing unmanaged > server capacity to web hosting resellers does not exempt them from taking > active steps to effectively prevent infringing activity upon notification > from an intellectual property rights owner. " > > I consider that the more important statement in the article. The "upon > notification" being the largest issue. Don't know if DMCA covers anything > outside the scope of copyright, but I think it's been generally accepted > that ignoring reports of infringement can bring about liability. Does anyone have a link to the decision? If you go to http://blog.ericgoldman.org/archives/2009/01/web_host_faces.htm and click on "Louis Vuitton Malletier, S.A. v. Akanoc Solutions, Inc." you can get an earlier decision regarding Akanoc's motion for summary judgement in the case. Reading between the lines, it sounds like Akanoc had a customer who put a server in their facility. This customer then hosted a bunch of sites including the ones that infringed. On receiving a complaint, Akanoc contacted the customer and more or less said, kill this website or we unplug your server. Then the customer shuffled the site around to another of his servers. Have a look at pages 10 through 12. Page 12 lines 11-13, it reads to me like the judge made a serious error trying to understand the difference between a web site and an IP address. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From j at arpa.com Mon Aug 31 19:03:37 2009 From: j at arpa.com (jamie) Date: Mon, 31 Aug 2009 19:03:37 -0500 Subject: Beware: a very bad precedent set In-Reply-To: <3c3e3fca0908311647o47b2c467y9bf40c9986e64205@mail.gmail.com> References: <737736526.145171251754543998.JavaMail.root@zimbra.wbsconnect.com> <4A9C45D2.1000605@brightok.net> <3c3e3fca0908311647o47b2c467y9bf40c9986e64205@mail.gmail.com> Message-ID: <6ff30abd0908311703x57184cbdr7e8d55d1cccf8d2d@mail.gmail.com> On Mon, Aug 31, 2009 at 6:47 PM, William Herrin wrote: > > Does anyone have a link to the decision? > > https://arpa.com/news/C0703952JW.pdf?n -jamie From morrowc.lists at gmail.com Mon Aug 31 21:03:02 2009 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Mon, 31 Aug 2009 22:03:02 -0400 Subject: Beware: a very bad precedent set In-Reply-To: <2065159430-1251758639-cardhu_decombobulator_blackberry.rim.net-1581782702-@bda138.bisx.prod.on.blackberry> References: <2065159430-1251758639-cardhu_decombobulator_blackberry.rim.net-1581782702-@bda138.bisx.prod.on.blackberry> Message-ID: <75cb24520908311903u728969ddgc0b08c9dfd84eeba@mail.gmail.com> On Mon, Aug 31, 2009 at 6:47 PM, William Pitcock wrote: > I would have figured that everyone would have learned that abuse@ being a blackhole is a bad idea from what happened to Atrivo/InterCage. I don't think that's the lesson learned from that case at all actually. The lesson learned was that you can essentially be a horrible actor in this society for +10 years and no one in LEA or Gov't circles will care (for a variety of reasons)... Only when enough operators get mud flung in their eyes publicly will action be taken. -chris From brunner at nic-naa.net Mon Aug 31 21:18:27 2009 From: brunner at nic-naa.net (Eric Brunner-Williams) Date: Mon, 31 Aug 2009 22:18:27 -0400 Subject: Ready to get your federal computer license? In-Reply-To: <4A9C1D14.9060602@inkworkswell.com> References: <81CDFC77FB2DC54DB875D4F8FFC36CE00A923B797E@DSMAIL2HE.ds.ad.adp.com> <81CDFC77FB2DC54DB875D4F8FFC36CE00B7A593500@DSMAIL2HE.ds.ad.adp.com> <4A989C59.10801@emanon.com> <873a7bm3mm.fsf@mid.deneb.enyo.de> <4A99259E.8000202@emanon.com> <5E9C4E81-05BA-42F4-996B-F5BE79F8FEB4@jsyoung.net> <40494.1251733329@turing-police.cc.vt.edu> <4A9C051E.9090904@inkworkswell.com> <20090831123102.6261e883@cs.columbia.edu> <4A9C1D14.9060602@inkworkswell.com> Message-ID: <4A9C8473.3020602@nic-naa.net> The order arose from Cobell v. Salazar (was C. v. Kempthorne, was C. v. Norton, was C. v. Babbitt). On October 20th, 2005, Judge Royce C. Lamberth ordered the Interior Department to disconnect from the Internet all computer systems that house or provide access to Individual Indian Trust records. "Indian Trust records continue to be in imminent risk of being manipulated and destroyed by computer hackers." The link to the ruling is http://wampum.wabanaki.net/archives/20051020ITPI.pdf Former Interior Deputy Secretary Steven Griles was sentenced to 10 months in prison for obstructing a U.S. Senate investigation of Jack A. Abramoff. He was also ordered to pay a fine of $30,000, and serve a term of three years of supervised release. Eric Reese wrote: > Steven M. Bellovin wrote: > >> I'm not sure what you're asking. Those disconnections were >> well-covered in the press. Start with >> http://www.doi.gov/news/grilesmemo.htm but there's a lot more that a >> quick google search will find. > > > A news-item or -event I missed for whatever reason, okay. > I'll consult Google. Thank you, > > Reese > > > >