From giulianocm at uol.com.br Wed Sep 1 00:25:07 2010 From: giulianocm at uol.com.br (Giuliano Cardozo Medalha) Date: Tue, 31 Aug 2010 21:25:07 -0300 Subject: Q-In-Q using M7i and CISCO Switch In-Reply-To: <4C7D9CA7.1030504@uol.com.br> References: <4C7D9C6A.407@wztech.com.br> <4C7D9CA7.1030504@uol.com.br> Message-ID: <4C7D9D63.7090901@uol.com.br> People, We have a client with the following situation: v1, v2, v3 -------| Switch | ----------| Switch |----------------| Switch|------------- JUNIPER M7i IQ2E ----- Carrier offers only 3 vlans to the client. But he wants to push some more vlans inside the 3 ones. It is possible to initiate and finish Q-In-Q vlans using a cisco ME switch and a JUNIPER M7i with IQ2E interface ? The following link shows stack configuration. It can be used to do Q-In-Q with this situation ? http://www.juniper.com.lv/techpubs/en_US/junos10.0/information-products/topic-collections/config-guide-network-interfaces/id-12155750.html Someone tries to configure it any time ? Thanks a lot, Giuliano From sthaug at nethelp.no Wed Sep 1 06:34:55 2010 From: sthaug at nethelp.no (sthaug at nethelp.no) Date: Wed, 01 Sep 2010 08:34:55 +0200 (CEST) Subject: Q-In-Q using M7i and CISCO Switch In-Reply-To: <4C7D9D63.7090901@uol.com.br> References: <4C7D9C6A.407@wztech.com.br> <4C7D9CA7.1030504@uol.com.br> <4C7D9D63.7090901@uol.com.br> Message-ID: <20100901.083455.41649728.sthaug@nethelp.no> > We have a client with the following situation: > > v1, v2, v3 > -------| Switch | ----------| Switch |----------------| > Switch|------------- JUNIPER M7i IQ2E ----- > > > Carrier offers only 3 vlans to the client. But he wants to push some > more vlans inside the 3 ones. > > It is possible to initiate and finish Q-In-Q vlans using a cisco ME > switch and a JUNIPER M7i with IQ2E interface ? > > The following link shows stack configuration. It can be used to do > Q-In-Q with this situation ? > > http://www.juniper.com.lv/techpubs/en_US/junos10.0/information-products/topic-collections/config-guide-network-interfaces/id-12155750.html > > > Someone tries to configure it any time ? You need to differentiate between *terminating* a dual tagged VLAN, and the operation of pushing/popping a VLAN tag. M7i with IQ2E kan do either. Note that you are *not* guaranteed that a carrier which offers a VLAN transport service will automatically handle dual tagged VLANs - this must be verified. Note also the obvious MTU implication of a 4 byte additional VLAN tag. You might be better off discussing this on the juniper-nsp list. Steinar Haug, Nethelp consulting, sthaug at nethelp.no From randy at psg.com Wed Sep 1 09:43:23 2010 From: randy at psg.com (Randy Bush) Date: Wed, 01 Sep 2010 18:43:23 +0900 Subject: quagga ospfd scaling Message-ID: anyone happily running a quagga ospfd which has O(100) or more peers? randy From neil at domino.org Wed Sep 1 10:28:07 2010 From: neil at domino.org (Neil J. McRae) Date: Wed, 1 Sep 2010 11:28:07 +0100 (BST) Subject: Complain to your vendors (was Re: Did your BGP crash today?) In-Reply-To: References: <20100829073529.GA9681@skywalker.creative.net.au> Message-ID: <26425.62.208.225.86.1283336887.squirrel@webmail2.domino.org> Paul, > Maybe the NANOG conference committee (or whatever its called) could get a > couple of major router vendor gerbils to come to the next NANOG and talk > to > this issue? > > Maybe? > > Okay, I give up. Recently I've been involved in some issues such as this working with Alcatel Lucent and Cisco to jointly test how their routing protocols interact with each other. As I think you try to point out, it was like herding cats, pushing jelly up the wall, mowing the lawn with scissors etc. However one of the aspects that came out of this was that it required some changes by service providers. Burgess from the RTG at Cisco has commited to working with me and Alcatel to put together a presentation on this for the NANOG community (hopefully it would be something that the PC would be interested in). I doubt this will be ready for the next meeting but should be for the one after. If we allow vendors just to throw in the towel on these issues then its the service provider community to blame. In my view we have bit by bit step by step ended up in a very dark place. With our entire planet now completely reliant on Internet and Data networks its time for action. Regards, Neil. -- Neil J. McRae -- Alive and Kicking. neil at DOMINO.ORG From simon.leinen at switch.ch Wed Sep 1 21:18:55 2010 From: simon.leinen at switch.ch (Simon Leinen) Date: Wed, 01 Sep 2010 23:18:55 +0200 Subject: ICMPv6 rate limits breaking PMTUD (and traceroute) [Re: Comcast enables 6to4 relays] In-Reply-To: <4C7C3488.1030202@brightok.net> (Jack Bates's message of "Mon, 30 Aug 2010 17:45:28 -0500") References: <326810.28.1283207579061.JavaMail.franck@franck-martins-macbook-pro.local> <4C7C3488.1030202@brightok.net> Message-ID: Jack Bates writes: > 1) Your originating host may be breaking PMTU (so the packet you send > is too large and doesn't make it, you never resend a smaller packet, > but it works when tracerouting from the other side due to PMTU working > in that direction and you are responding with the same size packet). Your mentioning PMTU discovery issues in connection with 6to4 prompts me to confess how our open 6to4 relay has probably contributed to the perception of brokenness of 6to4 for quite a while *blush*. The relay runs on a Cisco 7600 with PFC3 - btw. this is an excellent platform to run an 6to4 relay on, because it can do the encap/decap in hardware if configured correctly. At some point of the relay becoming popular (load currently fluctuates between 80 Mb/s and 200 Mb/s), I noticed that our router very often failed to send ICMPv6 messages such as "packet too big". First I suspected our control-plane rate-limit (CoPP) configuration, but couldn't find anything there. Finally I found that I had to configure a generous "ipv6 icmp error-interval"[1], because the (invisible) default configuration will only permit one such ICMPv6 message to be generated every 100 milliseconds, and that's WAY insufficient for a popular router. We currently use ipv6 icmp error-interval 2 100 (max. steady state rate 500 ICMPv6s/second - one every 2 milliseonds - with bursts up to 100) with no ill effects. Note that the same rate-limit will also cause stars in IPv6 traceroutes through popular routers if the default setting is used. The issue is probably not restricted to Cisco, as the ICMPv6 standard (RFC 4443) mandates that ICMPv6 error messages be rate limited. It even has good (if hand-wavy) guidance on how to arrive at defaults - the values used on our Cisco 7600 (and possibly all other IOS devices?) correspond to the RFC's suggestion for "a small/mid-size device" *hrmpf* (yes Randy, I know I should get real routers :-). Anybody knows which defaults are used by other devices/vendors? In general, rate limits are very useful for protecting routers' notoriously underpowered control planes, but (1) it's hard to come up with reasonable defaults, and (2) I suspect that not most people don't monitor them (because that's often hard), and thus won't notice when normal traffic levels trip these limits. -- Simon. [1] See http://www.cisco.com/en/US/docs/ios/ipv6/command/reference/ipv6_06.html#wp2135326 From nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org Wed Sep 1 21:50:28 2010 From: nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org (Mark Smith) Date: Thu, 2 Sep 2010 07:20:28 +0930 Subject: ICMPv6 rate limits breaking PMTUD (and traceroute) [Re: Comcast enables 6to4 relays] In-Reply-To: References: <326810.28.1283207579061.JavaMail.franck@franck-martins-macbook-pro.local> <4C7C3488.1030202@brightok.net> Message-ID: <20100902072028.4f3e2706@opy.nosense.org> On Wed, 01 Sep 2010 23:18:55 +0200 Simon Leinen wrote: > Jack Bates writes: > > 1) Your originating host may be breaking PMTU (so the packet you send > > is too large and doesn't make it, you never resend a smaller packet, > > but it works when tracerouting from the other side due to PMTU working > > in that direction and you are responding with the same size packet). > > Your mentioning PMTU discovery issues in connection with 6to4 prompts me > to confess how our open 6to4 relay has probably contributed to the > perception of brokenness of 6to4 for quite a while *blush*. > > The relay runs on a Cisco 7600 with PFC3 - btw. this is an excellent > platform to run an 6to4 relay on, because it can do the encap/decap in > hardware if configured correctly. > > At some point of the relay becoming popular (load currently fluctuates > between 80 Mb/s and 200 Mb/s), I noticed that our router very often > failed to send ICMPv6 messages such as "packet too big". > That potentially starts to explain why I haven't noticed PMTUD issues on my 6to4 tunnel that I've been running for a number of years, and have been quite surprised be and somewhat doubtful of people to say there are issues. I've pumped the MTU up to 1472 on it to suit my PPPoE 1492 MTU, instead of leaving it at 1280, and haven't had any issues that have made me suspect PMTUD. I'm in Asia Pacific so I've probably either been using 6to4 gateways that are lightly used, or ones that have had this parameter changed. > First I suspected our control-plane rate-limit (CoPP) configuration, but > couldn't find anything there. > > Finally I found that I had to configure a generous "ipv6 icmp > error-interval"[1], because the (invisible) default configuration will > only permit one such ICMPv6 message to be generated every 100 > milliseconds, and that's WAY insufficient for a popular router. > We currently use > > ipv6 icmp error-interval 2 100 > > (max. steady state rate 500 ICMPv6s/second - one every 2 milliseonds - > with bursts up to 100) with no ill effects. > > Note that the same rate-limit will also cause stars in IPv6 traceroutes > through popular routers if the default setting is used. > > The issue is probably not restricted to Cisco, as the ICMPv6 standard > (RFC 4443) mandates that ICMPv6 error messages be rate limited. It even > has good (if hand-wavy) guidance on how to arrive at defaults - the > values used on our Cisco 7600 (and possibly all other IOS devices?) > correspond to the RFC's suggestion for "a small/mid-size device" *hrmpf* > (yes Randy, I know I should get real routers :-). > > Anybody knows which defaults are used by other devices/vendors? > > In general, rate limits are very useful for protecting routers' > notoriously underpowered control planes, but (1) it's hard to come up > with reasonable defaults, and (2) I suspect that not most people don't > monitor them (because that's often hard), and thus won't notice when > normal traffic levels trip these limits. > -- > Simon. > [1] See http://www.cisco.com/en/US/docs/ios/ipv6/command/reference/ipv6_06.html#wp2135326 > From franck at genius.com Thu Sep 2 00:10:40 2010 From: franck at genius.com (Franck Martin) Date: Thu, 2 Sep 2010 12:10:40 +1200 (FJT) Subject: ICMPv6 rate limits breaking PMTUD (and traceroute) [Re: Comcast enables 6to4 relays] In-Reply-To: <20100902072028.4f3e2706@opy.nosense.org> Message-ID: <14105412.27.1283386239301.JavaMail.franck@franck-martins-macbook-pro.local> ----- Original Message ----- > From: "Mark Smith" > To: "Simon Leinen" > Cc: "Brzozowski" , "NANOG" , John > Sent: Thursday, 2 September, 2010 9:50:28 AM > Subject: Re: ICMPv6 rate limits breaking PMTUD (and traceroute) [Re: Comcast enables 6to4 relays] > On Wed, 01 Sep 2010 23:18:55 +0200 > Simon Leinen wrote: > > > Jack Bates writes: > > > 1) Your originating host may be breaking PMTU (so the packet you > > > send > > > is too large and doesn't make it, you never resend a smaller > > > packet, > > > but it works when tracerouting from the other side due to PMTU > > > working > > > in that direction and you are responding with the same size > > > packet). > > > > Your mentioning PMTU discovery issues in connection with 6to4 > > prompts me > > to confess how our open 6to4 relay has probably contributed to the > > perception of brokenness of 6to4 for quite a while *blush*. > > > > The relay runs on a Cisco 7600 with PFC3 - btw. this is an excellent > > platform to run an 6to4 relay on, because it can do the encap/decap > > in > > hardware if configured correctly. > > > > At some point of the relay becoming popular (load currently > > fluctuates > > between 80 Mb/s and 200 Mb/s), I noticed that our router very often > > failed to send ICMPv6 messages such as "packet too big". > > > > That potentially starts to explain why I haven't noticed PMTUD issues > on my 6to4 tunnel that I've been running for a number of years, and > have > been quite surprised be and somewhat doubtful of people to say there > are > issues. I've pumped the MTU up to 1472 on it to suit my PPPoE 1492 > MTU, > instead of leaving it at 1280, and haven't had any issues that have > made me suspect PMTUD. I'm in Asia Pacific so I've probably either > been > using 6to4 gateways that are lightly used, or ones that have had this > parameter changed. > Well I have an issue with a MTU of 1434 on a 6to4 link, but on my return path (I'm a client using an airport). The MTU seems real odd, and it fails all the time, but then I notice, some time of the day it is ok, so may be it coincide with load on the relay? I have the strong feeling this is exactly what I'm experiencing... I can provide extensive debug information if interested, but do not want to bore the list with details... From swmike at swm.pp.se Thu Sep 2 05:18:35 2010 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Thu, 2 Sep 2010 07:18:35 +0200 (CEST) Subject: ICMPv6 rate limits breaking PMTUD (and traceroute) [Re: Comcast enables 6to4 relays] In-Reply-To: References: <326810.28.1283207579061.JavaMail.franck@franck-martins-macbook-pro.local> <4C7C3488.1030202@brightok.net> Message-ID: On Wed, 1 Sep 2010, Simon Leinen wrote: > Your mentioning PMTU discovery issues in connection with 6to4 prompts me > to confess how our open 6to4 relay has probably contributed to the > perception of brokenness of 6to4 for quite a while *blush*. We're also doing the same thing, 6to4 on 7600. Could you please share your configuration you're using on the tunnel interfaces? I thought 6to4 traffic was only supposed to be 1280MTU? -- Mikael Abrahamsson email: swmike at swm.pp.se From kompella at cs.purdue.edu Thu Sep 2 05:33:54 2010 From: kompella at cs.purdue.edu (Ramana Kompella) Date: Thu, 2 Sep 2010 01:33:54 -0400 Subject: CFP: COMSNETS 2011 Message-ID: <20100902053354.GA15156@tirupati> *** APOLOGIES IF YOUR RECEIVED MULTIPLE COPIES OF THE CFP *** COMSNETS 2011 The THIRD International Conference on COMunication Systems and NETworks January 4-8, 2011, Bangalore, India http://www.comsnets.org (In Co-operation with ACM SIGMOBILE) (Technically Co-Sponsored by IEEE COMSOC) The Third International Conference on COMmunication Systems and NETworkS (COMSNETS) will be held in Bangalore, India, from 4 January 2011 to 8 January 2011. COMSNETS is a premier international conference dedicated to addressing advances in Networking and Communications Systems, and Telecommunications services. The goal of the conference is to create a world-class gathering of researchers from academia and industry, practitioners, business leaders, intellectual property experts, and venture capitalists, providing a forum for discussing cutting edge research, and directions for new innovative business and technology. The conference will include a highly selective technical program consisting of parallel tracks of submitted papers, a small set of invited papers on important and timely topics from well-known leaders in the field, and poster sessions of work in progress. Focused workshops and panel discussions will be held on emerging topics to allow for a lively exchange of ideas. International business and government leaders will be invited to share their perspectives, thus complementing the technical program. Papers describing original research work and practical experiences/experimental results are solicited on topics including, but not limited to: Topics of Interest ------------------ Internet Architecture and Protocols Network-based Applications Video Distribution (IPTV, Mobile Video, Video on Demand) Network Operations and Management Broadband and Cellular Networks (3G/4G, WiMAX/LTE) Mesh, Sensor and PAN Networks Communication Software (Cognitive Radios, DSA, SDR) Wireless Operating Systems and Mobile Platforms Peer-to-peer Networking Cognitive Radio and White Space Networking Optical Networks Network Security & Cyber Security Technologies Cloud and Utility computing Storage Area Networks Next Generation Web Architectures Vehicular Networking Energy-Efficient Networking Network Science and Emergent Behavior in Socio-Technical Networks Social Networking Analysis, Middleware and Applications Networking Technologies for Smart Energy Grids Disruption/Delay Tolerant Networking Conference Highlights --------------------- Conference Inaugural Speaker: Prof. Pravin Varaiya, U. C. Berkeley, USA Banquet speaker: Dr. Rajeev Rastogi, Yahoo Research, India Keynote Speakers: Prof. Don Towsley, U. Mass Amherst, USA Dr. Pravin Bhagwat, AirTight Networks, India Dr. Jean Bolot, Sprint, USA Workshops WISARD (4, 5 Jan) NetHealth (4 Jan) IAMCOM (5 Jan) Mobile India 2011 (7 Jan) Technical Paper and Poster Sessions Ph.D Forum Panel Discussions Demos & Exhibits Important Deadlines ------------------- Paper submission: September 13, 2010 at 11:59 pm EDT (Sept 14, 9:29 am IST) Notification of Acceptance: November 8, 2010 Camera-Ready Submission: December 8, 2010 Detailed conference information and paper submission guidelines will soon be available on the conference web site. Please see http://www.comsnets.org for detailed information from time to time. The conference email address is: comsnets2011 at gmail.com General Co-Chairs ----------------- David B. Johnson, Rice University, USA Anurag Kumar, IISc Bangalore, India Technical Program Co-Chairs --------------------------- Jon Crowcroft, U. of Cambridge, UK D. Manjunath, IIT Bombay, India Archan Misra, Telcordia Tech., USA Steering Committee Co-Chairs ---------------------------- Uday Desai, IIT Hyderabad, India Giridhar Mandyam, Qualcomm, USA Sanjoy Paul, Infosys, India Rajeev Shorey, NIIT University, India G. Venkatesh, SASKEN, India Panel Co-Chairs --------------- Aditya Akella, U. of Wisconsin, USA Venkat Padmanabhan, MSR, India Ph.D Forum Chair ---------------- Bhaskaran Raman, IIT Bombay, India Publications Chair ------------------ Varsha Apte, IIT Bombay, India Demos and Exhibits Co-Chairs ---------------------------- Aaditeshwar Seth, IIT Delhi, India Ajay Bakre, Netapps, India Sponsorship Chair ----------------- Sudipta Maitra, Delhi, india Workshop Chairs --------------- Sharad Jaiswal, Alcatel-Lucent, India Ravindran Kaliappa, CUNY, USA Neelesh Mehta, IISc Bangalore, India Mobile India 2011 Co-Chairs --------------------------- Gulzar Azad, Google, India Gene Landy, Ruperto-Israel & Weiner, USA Rajaraghavan Setlur, SASKEN, India Sridhar Varadharajan, SASKEN, India Publicity Co-Chair ------------------ Augustin Chaintreau, TTL, France Kameswari Chebrolu, IIT Bombay, India Song Chong, KAIST, Korea Ramana Kompella, Purdue Univ, USA Nishanth Sastry, U. of Cambridge, UK Web Co-Chairs ------------- Santhana Krishnan, IIT Bombay, India Vinay Veerappa, SASKEN, India International Advisory Committee -------------------------------- K. K. Ramakrishnan, AT&T, USA Victor Bahl, Microsoft Research, USA Sunghyun Choi, Seoul National U., Korea Sajal Das, U. Texas at Arlington, USA B. N. Jain, IIT Delhi, India Anurag Kumar, IISc, Bangalore, India L. M. Patnaik, IISc, Bangalore, India Krithi Ramamritham, IIT Bombay, India Parmesh Ramanathan, U. Wisconsin, USA Krishan Sabnani, Alcatel-Lucent, USA Kang Shin, U. Michigan, USA Nitin Vaidya, U. Illinois, USA University Partners: -------------------- IIT Bombay, IIT Delhi, IISc Bangalore, IIT Hyderabad, NIIT University, IIIT Bangalore Patrons: -------- Mobile Monday Bangalore, Sasken, IBM Research, Alcatel Lucent From pekkas at netcore.fi Thu Sep 2 05:57:20 2010 From: pekkas at netcore.fi (Pekka Savola) Date: Thu, 2 Sep 2010 08:57:20 +0300 (EEST) Subject: ICMPv6 rate limits breaking PMTUD (and traceroute) [Re: Comcast enables 6to4 relays] In-Reply-To: References: <326810.28.1283207579061.JavaMail.franck@franck-martins-macbook-pro.local> <4C7C3488.1030202@brightok.net> Message-ID: On Wed, 1 Sep 2010, Simon Leinen wrote: > Note that the same rate-limit will also cause stars in IPv6 traceroutes > through popular routers if the default setting is used. ... > Anybody knows which defaults are used by other devices/vendors? I've noticed 6to4 relay rate-limiter blackholes before (e.g. in Your.org relay in AMS, got quickly fixed once I reported it). FWIW, Linux default is 1000pps and BSD has 100pps which is too low for a popular relay. In our relays we've used 1000-3000pps. The majority of ICMPv6's is caused by windows boxes testing the relay's liveness. Depending on the MTU configuration of the relay's tunnel interface (there isn't a BCP on this I think), you will also get more issues if you run the relay at MTU=1280 rather than (say) 1480. But using 1480 may result in an IPv4 blackhole if you source packets from an anycast address and your destination is e.g. behind PPPoE, so... -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From graham at apolix.co.za Thu Sep 2 09:30:02 2010 From: graham at apolix.co.za (Graham Beneke) Date: Thu, 02 Sep 2010 11:30:02 +0200 Subject: eBGP Multihop Message-ID: <4C7F6E9A.6070203@apolix.co.za> I have been asked to investigate moving an entire network to multi-hop on all the eBGP sessions. Basically all upstreams, downstreams and peers will eBGP with a route reflector located in the core. This RR will be some kind of quagga or similar box. The dev guys want to be able to poke at the BGP feeds directly and do *magic* that standard router aren't capable of. My gut feel is that this is a bad idea. Besides anything else it makes sane link state detection very challenging - especially where we have multiple sessions with a peer. Is their any BCP or operational experience that agrees or disagrees with my gut. ;-) -- Graham Beneke From jmaimon at ttec.com Thu Sep 2 11:47:32 2010 From: jmaimon at ttec.com (Joe Maimon) Date: Thu, 02 Sep 2010 07:47:32 -0400 Subject: Comcast enables 6to4 relays In-Reply-To: <2342928.16.1283206591420.JavaMail.franck@franck-martins-macbook-pro.local> References: <2342928.16.1283206591420.JavaMail.franck@franck-martins-macbook-pro.local> Message-ID: <4C7F8ED4.9090704@ttec.com> So the biggest problem with 6to4 relays is that they are not ubiquitous and/or well run. Does offering your relays to the world, thereby improving the odds of off-net traffic returning through them >0, actually offer an improvement to your own users' experience with 6to4? Joe Franck Martin wrote: > Yes this is the list of visible relays as seen from the BGP backbone monitoring... > > If you don't offer your relays to the rest of the world, they won't show up there... > > ----- Original Message ----- > From: "John Jason Brzozowski" > To: "Franck Martin" > Cc: "NANOG" > Sent: Tuesday, 31 August, 2010 10:09:17 AM > Subject: Re: Comcast enables 6to4 relays > > The Comcast 6to4 relays are not on this list, perhaps this is a list of open > ones? > > John > > > On 8/30/10 5:47 PM, "Franck Martin" wrote: > >> found it: >> >> http://www.bgpmon.net/6to4.php?week=4 >> >> Not what I call a big list, considering... >> >> ----- Original Message ----- >> From: "Franck Martin" >> To: "John Jason Brzozowski" >> Cc: "NANOG" >> Sent: Tuesday, 31 August, 2010 9:21:58 AM >> Subject: Re: Comcast enables 6to4 relays >> >> Is there a list of 6to4 relays? >> >> I'm curious. >> >> Also, I'm also curious to know if ISPs in Europe (which are more advanced in >> IPv6 deployment) have experienced the same issues? >> >> >> >> > > ========================================= > John Jason Brzozowski > Comcast Cable > e) mailto:john_brzozowski at cable.comcast.com > o) 609-377-6594 > m) 484-962-0060 > w) http://www.comcast6.net > ========================================= > > > From lorddoskias at gmail.com Thu Sep 2 12:20:05 2010 From: lorddoskias at gmail.com (lorddoskias) Date: Thu, 02 Sep 2010 15:20:05 +0300 Subject: largest OSPF core Message-ID: <4C7F9675.8050208@gmail.com> I'm just curious - what is the largest OSPF core (in terms of number of routers) out there? From hal.lightwood at gmail.com Thu Sep 2 14:00:12 2010 From: hal.lightwood at gmail.com (Hal Lightwood) Date: Thu, 2 Sep 2010 10:00:12 -0400 Subject: Anyone from Trinidad and Tobago TSTT on list? Message-ID: Please contact me at your convenience. Thank you -- Hal A. Lightwood -- Tel: 510 621 3040 -- Skype: hal.lightwood From jack at crepinc.com Thu Sep 2 14:49:33 2010 From: jack at crepinc.com (Jack Carrozzo) Date: Thu, 2 Sep 2010 10:49:33 -0400 Subject: eBGP Multihop In-Reply-To: <4C7F6E9A.6070203@apolix.co.za> References: <4C7F6E9A.6070203@apolix.co.za> Message-ID: >> The dev guys want to be able to poke at the BGP feeds directly and do *magic* that standard router aren't capable of. This should scare you in a significant manner. -Jack Carrozzo On Thu, Sep 2, 2010 at 5:30 AM, Graham Beneke wrote: > I have been asked to investigate moving an entire network to multi-hop on > all the eBGP sessions. Basically all upstreams, downstreams and peers will > eBGP with a route reflector located in the core. This RR will be some kind > of quagga or similar box. The dev guys want to be able to poke at the BGP > feeds directly and do *magic* that standard router aren't capable of. > > My gut feel is that this is a bad idea. Besides anything else it makes sane > link state detection very challenging - especially where we have multiple > sessions with a peer. > > Is their any BCP or operational experience that agrees or disagrees with my > gut. ;-) > > -- > Graham Beneke > > From sking at kingrst.com Thu Sep 2 14:50:46 2010 From: sking at kingrst.com (Steven King) Date: Thu, 02 Sep 2010 10:50:46 -0400 Subject: eBGP Multihop In-Reply-To: <4C7F6E9A.6070203@apolix.co.za> References: <4C7F6E9A.6070203@apolix.co.za> Message-ID: <4C7FB9C6.70206@kingrst.com> The last company I worked for moved to eBGP Multi-Hop where there were two connections to the same provider (same AS). This allowed them to utilize both links in both directions vs only one link in one direction and have failover. As you have mentioned link state detection gets a bit crazy with this. If you have a MetroE connection (for example) with multiple segments, this could be problematic. If your side of the link goes down, then you stop sending traffic to the provider, but the provider still tries to send traffic to you. If a segment in the middle goes down, then neither side stop sending traffic. Due to the fact that the BGP session is still up, and the interface on your router is still up, BGP sees the link as a valid path. However there is a fix for this. If your provider supports it that is. Ethernet OAM (Ethernet Operations, Administration, and Management) will allow you to monitor the connection on Layer 2 end to end and not switch to switch. If any part of the link breaks, OAM brings your and the other side of the link down, telling BGP that the link is no longer usable, therefore avoiding the issues above. If you are using a POS, MPLS, or other similar technology, then the issues talked about above are either less of an issue, or not an issue at all. The biggest problem with multi segment Ethernet links is that you need OAM to reliably run eBGP Multihop and OAM isn't supported by a lot of providers (mainly because it requires a newer software version). Hope this helps. On 9/2/10 5:30 AM, Graham Beneke wrote: > I have been asked to investigate moving an entire network to multi-hop > on all the eBGP sessions. Basically all upstreams, downstreams and > peers will eBGP with a route reflector located in the core. This RR > will be some kind of quagga or similar box. The dev guys want to be > able to poke at the BGP feeds directly and do *magic* that standard > router aren't capable of. > > My gut feel is that this is a bad idea. Besides anything else it makes > sane link state detection very challenging - especially where we have > multiple sessions with a peer. > > Is their any BCP or operational experience that agrees or disagrees > with my gut. ;-) > -- Steve King Senior Linux Engineer - Advance Internet, Inc. Cisco Certified Network Associate CompTIA Linux+ Certified Professional CompTIA A+ Certified Professional From nick at foobar.org Thu Sep 2 15:11:59 2010 From: nick at foobar.org (Nick Hilliard) Date: Thu, 02 Sep 2010 16:11:59 +0100 Subject: largest OSPF core In-Reply-To: <4C7F9675.8050208@gmail.com> References: <4C7F9675.8050208@gmail.com> Message-ID: <4C7FBEBF.2020208@foobar.org> On 02/09/2010 13:20, lorddoskias wrote: > I'm just curious - what is the largest OSPF core (in terms of number of > routers) out there? You don't expect anyone to actually admit to something like this? :-) Nick From hannes at mailcolloid.de Thu Sep 2 15:44:29 2010 From: hannes at mailcolloid.de (Hannes Frederic Sowa) Date: Thu, 2 Sep 2010 17:44:29 +0200 Subject: eBGP Multihop In-Reply-To: <4C7F6E9A.6070203@apolix.co.za> References: <4C7F6E9A.6070203@apolix.co.za> Message-ID: On Thu, Sep 2, 2010 at 11:30 AM, Graham Beneke wrote: > I have been asked to investigate moving an entire network to multi-hop on > all the eBGP sessions. Basically all upstreams, downstreams and peers will > eBGP with a route reflector located in the core. This RR will be some kind > of quagga or similar box. The dev guys want to be able to poke at the BGP > feeds directly and do *magic* that standard router aren't capable of. > > My gut feel is that this is a bad idea. Besides anything else it makes sane > link state detection very challenging - especially where we have multiple > sessions with a peer. I have not tried yet, but you could have a look at [1]. Perhaps it could be extended to match your needs. Do you run an IGP? Hannes [1] http://kbfd.sourceforge.net/ From nick at foobar.org Thu Sep 2 16:47:54 2010 From: nick at foobar.org (Nick Hilliard) Date: Thu, 02 Sep 2010 17:47:54 +0100 Subject: eBGP Multihop In-Reply-To: <4C7F6E9A.6070203@apolix.co.za> References: <4C7F6E9A.6070203@apolix.co.za> Message-ID: <4C7FD53A.7090408@foobar.org> On 02/09/2010 10:30, Graham Beneke wrote: > I have been asked to investigate moving an entire network to multi-hop > on all the eBGP sessions. Basically all upstreams, downstreams and peers > will eBGP with a route reflector located in the core. This RR will be > some kind of quagga or similar box. The dev guys want to be able to poke > at the BGP feeds directly and do *magic* that standard router aren't > capable of. > > My gut feel is that this is a bad idea. Besides anything else it makes > sane link state detection very challenging - especially where we have > multiple sessions with a peer. Of course, this sort of thing is usually great fun and seems like a Very Good Idea At The Time. You get your cool configuration in place with lots of local hax and the network hums along. Then the developer who wrote the hax leaves because of something or another. And the person who configured the box leaves due to management politics, and then the Windows IT support person takes over, along with the smart person on the front-line tech support desk. Then you hit your first major security bug with your local route reflector and the vendor patch causes your configuration to break horribly. Then hilarity ensues. I've seen extreme local messing-around-with-systems at some companies. Hilarity ensued. But there is a silver lining to all this: all these companies learned from their stupidity and never did things like that again. At least, the ones which didn't go bust. As regards collapsing all your bgp requirements into a single BGP box, well, good luck with that. Can I recommend you call this box "spof.apolix.co.za"? It seems quite appropriate. [You could have another single box called "ospf.apolix.co.za", which dealt with all your ospf requirements... just a thought.] Incidentally, I presume your devs have found some way of patching quagga in memory so that every time they write a new local hack or need to fix the previous one, they don't have to bring down the entire network in order to bring it into production? That would bring the entire experiment to a new level of coolness. Anyway, I wish you well with this experiment in the future of your company's existence. Nick From deepak at ai.net Thu Sep 2 18:12:38 2010 From: deepak at ai.net (Deepak Jain) Date: Thu, 2 Sep 2010 14:12:38 -0400 Subject: largest OSPF core In-Reply-To: <4C7FBEBF.2020208@foobar.org> References: <4C7F9675.8050208@gmail.com> <4C7FBEBF.2020208@foobar.org> Message-ID: > Subject: Re: largest OSPF core > > On 02/09/2010 13:20, lorddoskias wrote: > > I'm just curious - what is the largest OSPF core (in terms of number > of > > routers) out there? > > You don't expect anyone to actually admit to something like this? :-) > For giggles: http://books.google.com/books?id=uBwEAAAAMBAJ&pg=PA59&dq=practical+limits+of+OSPF&hl=en&ei=qud_TNTAFYL68AautJXoAQ&sa=X&oi=book_result&ct=result&resnum=2&ved=0CCwQ6AEwAQ#v=onepage&q=practical%20limit&f=false Network World April 9, 1990 (page 59): "There is no practical limit to the number of interconnected networks OSPF and Dual Intermediate System-to-Intermediate System can support"... "From the onset, OSPF was intended to be short-term, for IP-only".. "Dual routing is intended to be more of a long-term solution because there will be very few pure OSI or TCP/IP routing environments in the future." --- Technology prognosticators shouldn't try their hands in Vegas. Just saying. With respect to these OSPF questions, how many people are running two OSPF processes on each router (v4 and v6) to support dual stack rather than migrating (or just enjoying their existing) ISIS (OSI) implementations? Deepak From Valdis.Kletnieks at vt.edu Thu Sep 2 18:23:13 2010 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Thu, 02 Sep 2010 14:23:13 -0400 Subject: largest OSPF core In-Reply-To: Your message of "Thu, 02 Sep 2010 14:12:38 EDT." References: <4C7F9675.8050208@gmail.com> <4C7FBEBF.2020208@foobar.org> Message-ID: <13087.1283451793@localhost> On Thu, 02 Sep 2010 14:12:38 EDT, Deepak Jain said: > "Dual routing is intended to be more of a long-term solution because there > will be very few pure OSI or TCP/IP routing environments in the future." Well, they were half-right. ;) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From bicknell at ufp.org Thu Sep 2 18:37:55 2010 From: bicknell at ufp.org (Leo Bicknell) Date: Thu, 2 Sep 2010 11:37:55 -0700 Subject: largest OSPF core In-Reply-To: <4C7F9675.8050208@gmail.com> References: <4C7F9675.8050208@gmail.com> Message-ID: <20100902183755.GA7746@ussenterprise.ufp.org> In a message written on Thu, Sep 02, 2010 at 03:20:05PM +0300, lorddoskias wrote: > I'm just curious - what is the largest OSPF core (in terms of number > of routers) out there? I'll admit to having seen a network with over 400 devices in an OSPF area 0, didn't design it, and in the end didn't get to work on it. Far as I know worked just fine though, no issues reported. How well your IGP scales depends a lot more on what you put in it, and how dynamic your network situation is than the protocol or number of devices. -- 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: 826 bytes Desc: not available URL: From r.hyunseog at ieee.org Thu Sep 2 18:42:34 2010 From: r.hyunseog at ieee.org (Alex Ryu) Date: Thu, 2 Sep 2010 13:42:34 -0500 Subject: largest OSPF core In-Reply-To: <20100902183755.GA7746@ussenterprise.ufp.org> References: <4C7F9675.8050208@gmail.com> <20100902183755.GA7746@ussenterprise.ufp.org> Message-ID: I think it is really depending on how your network topology looks like. If you have top-down design with star topology to limit the network connections to individual routers, it may scale well. But if you connect every routers to each other such as full-mesh, it will be a problem during interface flapping or something like that. Alex On Thu, Sep 2, 2010 at 1:37 PM, Leo Bicknell wrote: > In a message written on Thu, Sep 02, 2010 at 03:20:05PM +0300, lorddoskias wrote: >> ?I'm just curious - what is the largest OSPF core (in terms of number >> of routers) out there? > > I'll admit to having seen a network with over 400 devices in an > OSPF area 0, didn't design it, and in the end didn't get to work > on it. > > Far as I know worked just fine though, no issues reported. ?How > well your IGP scales depends a lot more on what you put in it, and > how dynamic your network situation is than the protocol or number > of devices. > > -- > ? ? ? Leo Bicknell - bicknell at ufp.org - CCIE 3440 > ? ? ? ?PGP keys at http://www.ufp.org/~bicknell/ > From christian.martin at teliris.com Thu Sep 2 18:55:00 2010 From: christian.martin at teliris.com (Christian Martin) Date: Thu, 2 Sep 2010 14:55:00 -0400 Subject: largest OSPF core In-Reply-To: <20100902183755.GA7746@ussenterprise.ufp.org> References: <4C7F9675.8050208@gmail.com> <20100902183755.GA7746@ussenterprise.ufp.org> Message-ID: <429B484C-D361-4533-B2E5-1261A896E2C5@teliris.com> > In a message written on Thu, Sep 02, 2010 at 03:20:05PM +0300, lorddoskias wrote: >> I'm just curious - what is the largest OSPF core (in terms of number >> of routers) out there? The stability of the topology plays a most prominent role, but it wouldn't surprise me if a OSPF network largely comprised of router LSAs (no redistribution), using today's hardware, could easily scale to 1000 nodes in an area. Some newer techniques may affect this scale in either direction (ie, subsecond hellos and fast convergence would negatively impact scale on some platforms, while using demand circuit emulation on p2p links would impact scale positively). YMMV... C From nick at brevardwireless.com Thu Sep 2 20:15:45 2010 From: nick at brevardwireless.com (Nick Olsen) Date: Thu, 2 Sep 2010 16:15:45 -0400 Subject: Level3 Contact Message-ID: <5c09fdb5$7f109d78$2b0e2034$@com> Anyone have a Level3 sales contact? I've called the 800 number and was told I would get a call in 48 hours, a week later, and a second call into them and I still haven't gotten a call back. Nick Olsen Network Operations (321) 205-1100 x106 From owen at delong.com Thu Sep 2 20:34:57 2010 From: owen at delong.com (Owen DeLong) Date: Fri, 3 Sep 2010 06:04:57 +0930 Subject: largest OSPF core In-Reply-To: References: <4C7F9675.8050208@gmail.com> <4C7FBEBF.2020208@foobar.org> Message-ID: Sent from my iPad On Sep 3, 2010, at 3:42 AM, Deepak Jain wrote: >> Subject: Re: largest OSPF core >> >> On 02/09/2010 13:20, lorddoskias wrote: >>> I'm just curious - what is the largest OSPF core (in terms of number >> of >>> routers) out there? >> >> You don't expect anyone to actually admit to something like this? :-) >> > > > For giggles: > > http://books.google.com/books?id=uBwEAAAAMBAJ&pg=PA59&dq=practical+limits+of+OSPF&hl=en&ei=qud_TNTAFYL68AautJXoAQ&sa=X&oi=book_result&ct=result&resnum=2&ved=0CCwQ6AEwAQ#v=onepage&q=practical%20limit&f=false > > Network World April 9, 1990 (page 59): > > "There is no practical limit to the number of interconnected networks OSPF and Dual Intermediate System-to-Intermediate System can support"... > > "From the onset, OSPF was intended to be short-term, for IP-only".. > > "Dual routing is intended to be more of a long-term solution because there will be very few pure OSI or TCP/IP routing environments in the future." > > --- > > Technology prognosticators shouldn't try their hands in Vegas. Just saying. > > With respect to these OSPF questions, how many people are running two OSPF processes on each router (v4 and v6) to support dual stack rather than migrating (or just enjoying their existing) ISIS (OSI) implementations? > You left out the option of using ospf3 to do both v4 and v6. Works on juniper and foundry at least. Owen > Deepak > From alan at gtekcommunications.com Thu Sep 2 20:42:13 2010 From: alan at gtekcommunications.com (Alan Bryant) Date: Thu, 2 Sep 2010 15:42:13 -0500 Subject: Level3 Contact In-Reply-To: <5c09fdb5$7f109d78$2b0e2034$@com> References: <5c09fdb5$7f109d78$2b0e2034$@com> Message-ID: Beth Manning Beth.Manning at level3.com On Thu, Sep 2, 2010 at 3:15 PM, Nick Olsen wrote: > Anyone have a Level3 sales contact? > I've called the 800 number and was told I would get a call in 48 hours, a > week later, and a second call into them and I still haven't gotten a call > back. > > Nick Olsen > Network Operations > (321) 205-1100 x106 > > > -- Alan Bryant | Systems Administrator Gtek Computers & Wireless, LLC. alan at gtekcommunications.com | www.gtek.biz O 361-777-1400 | F 361-777-1405 From bdflemin at gmail.com Thu Sep 2 20:43:36 2010 From: bdflemin at gmail.com (Brad Fleming) Date: Thu, 2 Sep 2010 15:43:36 -0500 Subject: Road Runner Abuse Contact Message-ID: Any Road Runner abuse reps on the list? If so, could you please contact me off-list? From harbor235 at gmail.com Thu Sep 2 21:00:55 2010 From: harbor235 at gmail.com (harbor235) Date: Thu, 2 Sep 2010 17:00:55 -0400 Subject: Road Runner Abuse Contact In-Reply-To: References: Message-ID: I always feel bad when roadrunners get abused ......... On Thu, Sep 2, 2010 at 4:43 PM, Brad Fleming wrote: > Any Road Runner abuse reps on the list? > > If so, could you please contact me off-list? > > From trelane at trelane.net Thu Sep 2 21:06:02 2010 From: trelane at trelane.net (Andrew Kirch) Date: Thu, 02 Sep 2010 17:06:02 -0400 Subject: Road Runner Abuse Contact In-Reply-To: References: Message-ID: <4C8011BA.7070100@trelane.net> Did you call Chuck Jones? On 9/2/2010 4:43 PM, Brad Fleming wrote: > Any Road Runner abuse reps on the list? > > If so, could you please contact me off-list? > From deepak at ai.net Thu Sep 2 21:32:30 2010 From: deepak at ai.net (Deepak Jain) Date: Thu, 2 Sep 2010 17:32:30 -0400 Subject: largest OSPF core In-Reply-To: References: <4C7F9675.8050208@gmail.com> <4C7FBEBF.2020208@foobar.org> Message-ID: . > > > > With respect to these OSPF questions, how many people are running two > OSPF processes on each router (v4 and v6) to support dual stack rather > than migrating (or just enjoying their existing) ISIS (OSI) > implementations? > > > You left out the option of using ospf3 to do both v4 and v6. Works on > juniper and foundry at least. > > Owen http://www.cisco.com/web/strategy/docs/gov/OSPFv3_aag.pdf Thank you. Apparently Cisco supports it (or something like it) too. Deepak From cra at WPI.EDU Thu Sep 2 21:41:59 2010 From: cra at WPI.EDU (Chuck Anderson) Date: Thu, 2 Sep 2010 17:41:59 -0400 Subject: largest OSPF core In-Reply-To: References: <4C7F9675.8050208@gmail.com> <4C7FBEBF.2020208@foobar.org> Message-ID: <20100902214159.GJ23425@angus.ind.WPI.EDU> On Thu, Sep 02, 2010 at 05:32:30PM -0400, Deepak Jain wrote: > > > With respect to these OSPF questions, how many people are running two > > OSPF processes on each router (v4 and v6) to support dual stack rather > > than migrating (or just enjoying their existing) ISIS (OSI) > > implementations? > > > > > You left out the option of using ospf3 to do both v4 and v6. Works on > > juniper and foundry at least. > > > > Owen > > http://www.cisco.com/web/strategy/docs/gov/OSPFv3_aag.pdf > > Thank you. Apparently Cisco supports it (or something like it) too. Seems silly to migrate your existing OSPFv2 to an extra instance of OSPFv3, leaving 2 separate OSPFv3 instances. Why not just stick with your existing OSPFv2 and add OSPFv3 for IPv6? Or if you want to migrate your IPv4 IGP, go directly to IS-IS so you can have a single link-state database, single process, etc. for both IPv4 and IPv6. From nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org Thu Sep 2 21:50:18 2010 From: nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org (Mark Smith) Date: Fri, 3 Sep 2010 07:20:18 +0930 Subject: largest OSPF core In-Reply-To: <4C7F9675.8050208@gmail.com> References: <4C7F9675.8050208@gmail.com> Message-ID: <20100903072018.34e4d175@opy.nosense.org> On Thu, 02 Sep 2010 15:20:05 +0300 lorddoskias wrote: > I'm just curious - what is the largest OSPF core (in terms of number > of routers) out there? > Presuming OSPF and IS-IS SPF costs are fairly similar, the following page from "The complete IS-IS routing protocol" (really quite a good book, a bit of a shame that there are occasional minor errors that better technical editing would have picked up) shows that relatively modern (although a number of years old now) routers can perform SPF calcs on SPF databases with 10000 routers and 25000 links in less than a second. From that, it would seem that areas / levels are obsolete for most networks for the purposes of reducing SPF calculation time. Still possibly useful for route aggregation, although if BGP is carrying nearly all your routes, that may not be that useful either. http://books.google.com.au/books?id=NxIadsCKZxMC&lpg=PP1&dq="IS-IS"&pg=PA481#v=onepage&q&f=false From zhiyunq at umich.edu Thu Sep 2 21:59:57 2010 From: zhiyunq at umich.edu (Zhiyun Qian) Date: Thu, 2 Sep 2010 16:59:57 -0500 Subject: ISP port blocking practice In-Reply-To: <13222.1256232797@turing-police.cc.vt.edu> References: <0A08271D-49B9-4382-9F54-1A0BB6A3F2B2@umich.edu> <13222.1256232797@turing-police.cc.vt.edu> Message-ID: Sorry for bringing this old topic back. But we have made some academic effort investigating the spamming behaviors using assymetric routing (we named it "triangualr spamming"). This work appeared in this year's IEEE Security & Privacy conference. You can take a look at it if you are interested (and feedbacks are welcome): http://www.eecs.umich.edu/~zhiyunq/pub/oakland10_triangular-spamming.pdf One of the high-level findings is that we developed probing techniques to verify that indeed most ISPs are only blocking 1) "outgoing traffic of destination port 25" instead of 2) "incoming traffic with source port 25", which means that these ISPs are vulnerable to the assymetric routing attack. Finally, many thanks to all your useful inputs :) Regards. -Zhiyun On Oct 22, 2009, at 12:33 PM, Valdis.Kletnieks at vt.edu wrote: > On Thu, 22 Oct 2009 13:22:17 EDT, Zhiyun Qian said: >> Hi all, >> >> What is the common practice for enforcing port blocking policy (or >> what is the common practice for you and your ISP)? More specifically, >> when ISPs try to block certain outgoing port (port 25 for instance), >> they could do two rules: >> 1). For any outgoing traffic, if the destination port is 25, then drop >> the packets. >> 2). For any incoming traffic, if the source port is 25, then drop the >> packets. >> >> Note that either of the rule would be able to block outgoing port 25 >> traffic since each rule essentially represent one direction in a TCP >> flow. Of course, they could apply both rules. However, based on our >> measurement study, it looks like most of the ISPs are only using rule >> 1). Is there any particular reason why rule 1) instead of rule 2)? Or >> maybe both? > > Note that some spammers use assymetric routing with forged packets - they > spew out a stream of crafted packets from a compromised machine, showing > a different source IP. The claimed source IP is also under the spammer's > control, and just basically has to catch the inbound SYN/ACK and forward > it to the spam-sender (and, if wanted, sink the other ACKs and forward the > SMTP replies from the server to the real sender). So you can have a big > sending pipe that doesn't get ingress-filtered(*) sending the spam, and do the > control from a throwaway that may have a small pipe. > > (*) Of course it's not ingress-filtered - if somebody is selling a spammer > a big pipe for this, they can arrange to fail to filter. ;) > > The upshot is, of course, that you want to do (1) because you never actually > see the (2) packets, they're going someplace else... From bill at herrin.us Thu Sep 2 22:45:47 2010 From: bill at herrin.us (William Herrin) Date: Thu, 2 Sep 2010 18:45:47 -0400 Subject: ISP port blocking practice In-Reply-To: References: <0A08271D-49B9-4382-9F54-1A0BB6A3F2B2@umich.edu> <13222.1256232797@turing-police.cc.vt.edu> Message-ID: On Thu, Sep 2, 2010 at 5:59 PM, Zhiyun Qian wrote: > http://www.eecs.umich.edu/~zhiyunq/pub/oakland10_triangular-spamming.pdf > > One of the high-level findings is that we developed probing techniques > to verify that indeed most ISPs are only blocking 1) "outgoing traffic > of destination port 25" instead of 2) "incoming traffic with source > port 25", which means that these ISPs are vulnerable to the > assymetric routing attack. If I understand your idea correctly: 1. GoodNet filters TCP destination port 25 packets from his customer PwndBox, preventing PwndBox from spamming. 2. BadGuy on BadNet sends a forged TCP SYN packet to SpamVictim allegedly from PwndBox on GoodNet. 3. PwndBox receives the response packets from SpamVictim and tunnels them to BadGuy allowing BadGuy to complete the spam. 4. GoodNet didn't stop it because PwndBox never sent any packets to TCP port 25. 5. Since the IP address used was GoodNet's, GoodNet's reputation is damaged. 6. GoodNet could prevent this attack vector by also blocking packets with TCP source port 25 sent -to- PwndBox. Is that correct? I observe that if PwndBox is behind a stateful firewall such as a COTS NAT box, that also prevents this attack. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From zhiyunq at umich.edu Thu Sep 2 23:05:58 2010 From: zhiyunq at umich.edu (Zhiyun Qian) Date: Thu, 2 Sep 2010 18:05:58 -0500 Subject: ISP port blocking practice In-Reply-To: References: <0A08271D-49B9-4382-9F54-1A0BB6A3F2B2@umich.edu> <13222.1256232797@turing-police.cc.vt.edu> Message-ID: <9141B0C6-B9E9-484F-BD24-84A4C27E6B34@umich.edu> You are exactly right. We also talked about stateful firewall that can protect the GoodNet. For NAT box, depends on the type of NAT, it is possible to setup port forwarding on the router (mostly home routers) via uPnP without any authentication (I think many home routers are like this by default). And since the machine in GoodNet is also compromised, it would not be difficult to achieve this. Regards. -Zhiyun On Sep 2, 2010, at 5:45 PM, William Herrin wrote: > On Thu, Sep 2, 2010 at 5:59 PM, Zhiyun Qian wrote: >> http://www.eecs.umich.edu/~zhiyunq/pub/oakland10_triangular-spamming.pdf >> >> One of the high-level findings is that we developed probing techniques >> to verify that indeed most ISPs are only blocking 1) "outgoing traffic >> of destination port 25" instead of 2) "incoming traffic with source >> port 25", which means that these ISPs are vulnerable to the >> assymetric routing attack. > > If I understand your idea correctly: > > 1. GoodNet filters TCP destination port 25 packets from his customer > PwndBox, preventing PwndBox from spamming. > > 2. BadGuy on BadNet sends a forged TCP SYN packet to SpamVictim > allegedly from PwndBox on GoodNet. > > 3. PwndBox receives the response packets from SpamVictim and tunnels > them to BadGuy allowing BadGuy to complete the spam. > > 4. GoodNet didn't stop it because PwndBox never sent any packets to TCP port 25. > > 5. Since the IP address used was GoodNet's, GoodNet's reputation is damaged.. > > 6. GoodNet could prevent this attack vector by also blocking packets > with TCP source port 25 sent -to- PwndBox. > > Is that correct? > > I observe that if PwndBox is behind a stateful firewall such as a COTS > NAT box, that also prevents this attack. > > Regards, > Bill Herrin > > > > -- > William D. Herrin ................ herrin at dirtside.com bill at herrin.us > 3005 Crane Dr. ...................... Web: > Falls Church, VA 22042-3004 > > From jdfalk-lists at cybernothing.org Thu Sep 2 23:29:49 2010 From: jdfalk-lists at cybernothing.org (J.D. Falk) Date: Thu, 2 Sep 2010 16:29:49 -0700 Subject: Road Runner Abuse Contact In-Reply-To: References: Message-ID: <0CBCBAB2-C38B-4567-AD5F-82042F7C16E0@cybernothing.org> On Sep 2, 2010, at 1:43 PM, Brad Fleming wrote: > Any Road Runner abuse reps on the list? http://postmaster.rr.com/ is a good place to start. From nenolod at systeminplace.net Thu Sep 2 23:35:24 2010 From: nenolod at systeminplace.net (William Pitcock) Date: Thu, 02 Sep 2010 18:35:24 -0500 Subject: Road Runner Abuse Contact In-Reply-To: <0CBCBAB2-C38B-4567-AD5F-82042F7C16E0@cybernothing.org> References: <0CBCBAB2-C38B-4567-AD5F-82042F7C16E0@cybernothing.org> Message-ID: <1283470524.14059.9.camel@petrie.dereferenced.org> On Thu, 2010-09-02 at 16:29 -0700, J.D. Falk wrote: > On Sep 2, 2010, at 1:43 PM, Brad Fleming wrote: > > > Any Road Runner abuse reps on the list? > > http://postmaster.rr.com/ is a good place to start. Quoting that website: | The Postmaster team is part of the Road Runner Mail Operations | team, and we are responsible for blocking and filtering mail | that transits our servers; however, while we have an active | Abuse organization and work closely with them, this is not the | place to report incidents of spam or abuse coming from Road | Runner's mail servers or from our network in general, as Abuse | is a separate organization here. William From randy at psg.com Thu Sep 2 23:35:38 2010 From: randy at psg.com (Randy Bush) Date: Fri, 03 Sep 2010 08:35:38 +0900 Subject: largest OSPF core In-Reply-To: <429B484C-D361-4533-B2E5-1261A896E2C5@teliris.com> References: <4C7F9675.8050208@gmail.com> <20100902183755.GA7746@ussenterprise.ufp.org> <429B484C-D361-4533-B2E5-1261A896E2C5@teliris.com> Message-ID: > The stability of the topology plays a most prominent role, but it > wouldn't surprise me if a OSPF network largely comprised of router > LSAs (no redistribution), using today's hardware, could easily scale > to 1000 nodes in an area. i believe the original poster asked about actual operating deployment, not theory. and, i suspect one wants to know about full mesh under real load, i.e. topology change, which can be exciting when one gets to a network of significant size. randy From ops.lists at gmail.com Fri Sep 3 01:19:36 2010 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Fri, 3 Sep 2010 06:49:36 +0530 Subject: ISP port blocking practice In-Reply-To: References: <0A08271D-49B9-4382-9F54-1A0BB6A3F2B2@umich.edu> <13222.1256232797@turing-police.cc.vt.edu> Message-ID: Zhiyun, this is by far the most comprehensive paper I've seen on asymmetric routing spam .. a technique that's as old as, for example, Alan Ralsky. So been around for about a decade. Congratulations, great effort. Do you have more results available (in more detail than were published in this paper)? Should be worth seeing. thanks --srs On Fri, Sep 3, 2010 at 3:29 AM, Zhiyun Qian wrote: > Sorry for bringing this old topic back. But we have made some academic effort investigating the spamming behaviors using assymetric routing (we named it "triangualr spamming"). This work appeared in this year's IEEE Security & Privacy conference. You can take a look at it if you are interested (and feedbacks are welcome): > > http://www.eecs.umich.edu/~zhiyunq/pub/oakland10_triangular-spamming.pdf -- Suresh Ramasubramanian (ops.lists at gmail.com) From mehmet at icann.org Fri Sep 3 01:21:41 2010 From: mehmet at icann.org (Mehmet Akcin) Date: Thu, 2 Sep 2010 18:21:41 -0700 Subject: justin.tv contact Message-ID: <9B624EC2-9D6E-4E6B-B6E3-CBAC5BCD7175@icann.org> can someone from justin.tv contact me off-list please? thanks mehmet From christian.martin at teliris.com Fri Sep 3 01:40:39 2010 From: christian.martin at teliris.com (Christian Martin) Date: Thu, 2 Sep 2010 21:40:39 -0400 Subject: largest OSPF core In-Reply-To: References: <4C7F9675.8050208@gmail.com> <20100902183755.GA7746@ussenterprise.ufp.org> <429B484C-D361-4533-B2E5-1261A896E2C5@teliris.com> Message-ID: <1CDD0EBD-6E43-4ED3-BB9B-004D095D18F7@teliris.com> On Sep 2, 2010, at 7:35 PM, Randy Bush wrote: >> The stability of the topology plays a most prominent role, but it >> wouldn't surprise me if a OSPF network largely comprised of router >> LSAs (no redistribution), using today's hardware, could easily scale >> to 1000 nodes in an area. > > i believe the original poster asked about actual operating deployment, > not theory. > > and, i suspect one wants to know about full mesh under real load, i.e. > topology change, which can be exciting when one gets to a network of > significant size. Randy, Fair enough. 7 years ago, I was privy to an OSPF BB of 300 or so routers supporting a BGP overlay. No NBMA, passive broadcast subnetworks, all running on systems without the capacity to offload adjacency maintenance into linecards. I'd argue that this type of network is also uninteresting from a NANOG viewership POV. I also operated a network that supported over 70 OSPF VRF instances on a single PE. CPU loads were higher, but we didn't observe intractable workloads. And this was with a 500 route limit per VRF, with who knows what kinds of messiness running in those VRFs. (and yea there were sham links and router LSAs flying around!!) :) There are many variables, and several studies have tried to capture, algorithmically and in terms of computational complexity, a formulaic approach to determining the boundaries of OSPF network scalability. Admittedly, these approaches can be very approximate in nature. But the point stands. Stable topologies absent large, frequent, compulsively updated data can scale extremely well. Unstable topologies with lots of leaf data (20,000 type 5 LSAs, for example), don't. The most interesting point to make, however, is how much legacy thinking in this area continues to be stranded in a rut that emerged 15 years ago. It is not uncommon to hear network folks cringe at the thought of an OSPF area exceeding 100 routers. Really? When simulations using testing tools show that properly tuned OSPF implementations (with ISPF, PRC, etc) comprised of 1000 can run full SPFs in 500 ms? That said, my experience, as stated above, is that 300 routers is completely workable. Cheers Chris > > randy From morrowc.lists at gmail.com Fri Sep 3 01:45:59 2010 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Thu, 2 Sep 2010 21:45:59 -0400 Subject: largest OSPF core In-Reply-To: <20100902183755.GA7746@ussenterprise.ufp.org> References: <4C7F9675.8050208@gmail.com> <20100902183755.GA7746@ussenterprise.ufp.org> Message-ID: On Thu, Sep 2, 2010 at 2:37 PM, Leo Bicknell wrote: > In a message written on Thu, Sep 02, 2010 at 03:20:05PM +0300, lorddoskias wrote: >> ?I'm just curious - what is the largest OSPF core (in terms of number >> of routers) out there? > > I'll admit to having seen a network with over 400 devices in an > OSPF area 0, didn't design it, and in the end didn't get to work > on it. I know of a large enterprise with ~4k devices in area-0, according to their vendor^H^H^H^H^Hdesigner that was all perfectly fine. > Far as I know worked just fine though, no issues reported. ?How > well your IGP scales depends a lot more on what you put in it, and > how dynamic your network situation is than the protocol or number > of devices. > I think the only reason the one I saw worked at all was it was relatively stable. If things happened though (like say the code-red incident in ... whenever that was) the network turned into a steaming pile of fail. really, not a good plan, of course as Leo says ISIS probably gets super unhappy if a large percent of interfaces start to go bouncey-bouncey. -Chris From bicknell at ufp.org Fri Sep 3 02:02:18 2010 From: bicknell at ufp.org (Leo Bicknell) Date: Thu, 2 Sep 2010 19:02:18 -0700 Subject: largest OSPF core In-Reply-To: <1CDD0EBD-6E43-4ED3-BB9B-004D095D18F7@teliris.com> References: <4C7F9675.8050208@gmail.com> <20100902183755.GA7746@ussenterprise.ufp.org> <429B484C-D361-4533-B2E5-1261A896E2C5@teliris.com> <1CDD0EBD-6E43-4ED3-BB9B-004D095D18F7@teliris.com> Message-ID: <20100903020218.GA30961@ussenterprise.ufp.org> In a message written on Thu, Sep 02, 2010 at 09:40:39PM -0400, Christian Martin wrote: > The most interesting point to make, however, is how much legacy > thinking in this area continues to be stranded in a rut that emerged > 15 years ago. It is not uncommon to hear network folks cringe at > the thought of an OSPF area exceeding 100 routers. Really? When > simulations using testing tools show that properly tuned OSPF > implementations (with ISPF, PRC, etc) comprised of 1000 can run > full SPFs in 500 ms? I do think a lot of the thinking is out of date. I strongly agree that all the references I know of about scaling are based on the CPU and RAM limitations of devices made in the 1990's. Heck, a "branch" router today probably has more CPU than a backbone device of that era. The larger issue though is that as an industry we are imprecise. If you talk about when a routing protocol /fails/, that is can't process the updates with the available CPU before the session times out, you're probably talking a network of 250,000 routers on a low end device. Seriously, how large does a network need to be to keep OSPF or ISIS CPU-busy for 10-20 seconds? Huge! Rather, we have scaling based on vauge, often unstated rules. One vendor publishes a white paper based on devices running only the IGP and a stated convergence time of 500ms. Another will assume the IGP gets no more than 50% of the CPU, and must converge in 100ms. Also, how many people have millisecond converging IGP's, but routers with old CPU's so BGP takes 3-5 MINUTES to converge? Yes, for some people that's good, if you have lots of internal VOIP or other things; but if 99% of your traffic is off net it really doesn't matter, you're waiting on BGP. Lastly, the largest myth I see in IGP design is that you can't redistribute connected or statics into your IGP, those go into BGP so the IGP only has to deal with loopbacks. As far as I understand the computational complexity of OSPF and IS-IS depends solely on the number of links running the protocol, so having these things in or out makes no difference in that sense. It does increase the amount of data that needs to be transferred by the IGP's which does slow them a bit, but with modern link speeds and CPU's it's really a non-issue. I'm not saying it's "smart" to redistribute connected and static, it really does depend on your environment. However there seems to be a lot of folks who automatically assume the network is broken if it has such things in the IGP, and that's just silly. Plenty of networks have that data in the IGP and deliver excellent routing performance. Fortunately we've gotten to the point where 95% of the networks don't have to worry about these things, it works however you want to do it. However for the 5% who need to care, almost none of them have engineers who actually understand the programming behind the protocols. How many network architects could write an OSPF implementation or understand your boxes architecture? -- 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: 826 bytes Desc: not available URL: From zhiyunq at umich.edu Fri Sep 3 02:17:47 2010 From: zhiyunq at umich.edu (Zhiyun Qian) Date: Thu, 2 Sep 2010 21:17:47 -0500 Subject: ISP port blocking practice In-Reply-To: References: <0A08271D-49B9-4382-9F54-1A0BB6A3F2B2@umich.edu> <13222.1256232797@turing-police.cc.vt.edu> Message-ID: Suresh, thanks for your interest. I see you've had a lot of experience in fighting spam, so you must have known this. Yes, I know this spamming technique has been around for a while. But it's surprising to see that the majority of the ISPs that we studied are still vulnerable to this attack. That probably indicates that it is not as widely known as we would expect. So I thought it would be beneficial to raise the awareness of the problem. In terms of more results, the paper is the most detailed document we have. Otherwise, if you interested in the data that we collected (which ISPs or IP ranges are vulnerable to this attack). We can chat offline. Regards. -Zhiyun On Sep 2, 2010, at 8:19 PM, Suresh Ramasubramanian wrote: > Zhiyun, this is by far the most comprehensive paper I've seen on > asymmetric routing spam .. a technique that's as old as, for example, > Alan Ralsky. So been around for about a decade. > > Congratulations, great effort. Do you have more results available (in > more detail than were published in this paper)? Should be worth > seeing. > > thanks > --srs > > On Fri, Sep 3, 2010 at 3:29 AM, Zhiyun Qian wrote: >> Sorry for bringing this old topic back. But we have made some academic effort investigating the spamming behaviors using assymetric routing (we named it "triangualr spamming"). This work appeared in this year's IEEE Security & Privacy conference. You can take a look at it if you are interested (and feedbacks are welcome): >> >> http://www.eecs.umich.edu/~zhiyunq/pub/oakland10_triangular-spamming.pdf > > > > -- > Suresh Ramasubramanian (ops.lists at gmail.com) > > From ops.lists at gmail.com Fri Sep 3 02:20:01 2010 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Fri, 3 Sep 2010 07:50:01 +0530 Subject: ISP port blocking practice In-Reply-To: References: <0A08271D-49B9-4382-9F54-1A0BB6A3F2B2@umich.edu> <13222.1256232797@turing-police.cc.vt.edu> Message-ID: BCP38 / RFC2827 were created specifically to address some quite similar problems. And googling either of those two strings on nanog will get you a lot of griping and/or reasons as to why these aren't being more widely adopted :) --srs On Fri, Sep 3, 2010 at 7:47 AM, Zhiyun Qian wrote: > Suresh, thanks for your interest. I see you've had a lot of experience in fighting spam, so you must have known this. Yes, I know this spamming technique has been around for a while. But it's surprising to see that the majority of the ISPs that we studied are still vulnerable to this attack. ?That probably indicates that it is not as widely known as we would expect. So I thought it would be beneficial to raise the awareness of the problem. > > In terms of more results, the paper is the most detailed document we have. Otherwise, if you interested in the data that we collected (which ISPs or IP ranges are vulnerable to this attack). We can chat offline. > > Regards. > -Zhiyun From zhiyunq at umich.edu Fri Sep 3 02:23:46 2010 From: zhiyunq at umich.edu (Zhiyun Qian) Date: Thu, 2 Sep 2010 21:23:46 -0500 Subject: ISP port blocking practice In-Reply-To: References: <0A08271D-49B9-4382-9F54-1A0BB6A3F2B2@umich.edu> <13222.1256232797@turing-police.cc.vt.edu> Message-ID: Great. Thanks for the information. -Zhiyun On Sep 2, 2010, at 9:20 PM, Suresh Ramasubramanian wrote: > BCP38 / RFC2827 were created specifically to address some quite > similar problems. And googling either of those two strings on nanog > will get you a lot of griping and/or reasons as to why these aren't > being more widely adopted :) > > --srs > > On Fri, Sep 3, 2010 at 7:47 AM, Zhiyun Qian wrote: >> Suresh, thanks for your interest. I see you've had a lot of experience in fighting spam, so you must have known this. Yes, I know this spamming technique has been around for a while. But it's surprising to see that the majority of the ISPs that we studied are still vulnerable to this attack. That probably indicates that it is not as widely known as we would expect. So I thought it would be beneficial to raise the awareness of the problem. >> >> In terms of more results, the paper is the most detailed document we have. Otherwise, if you interested in the data that we collected (which ISPs or IP ranges are vulnerable to this attack). We can chat offline. >> >> Regards. >> -Zhiyun > > From zhiyunq at umich.edu Fri Sep 3 02:55:41 2010 From: zhiyunq at umich.edu (Zhiyun Qian) Date: Thu, 2 Sep 2010 21:55:41 -0500 Subject: ISP port blocking practice In-Reply-To: References: <0A08271D-49B9-4382-9F54-1A0BB6A3F2B2@umich.edu> <13222.1256232797@turing-police.cc.vt.edu> Message-ID: I skimmed through these specs. They are useful but seems only related specific to IP spoofing prevention. I see that IP spoofing is part of the asymmetric routing story. But I was more thinking that given that IP spoofing is not widely adopted, the other defenses that they can more perhaps more easily implement is to block incoming traffic with source port 25 (if they already decided to block outgoing traffic with destination port 25). But according to our study, most of the ISPs didn't do that at the time of study (probably still true today). -Zhiyun On Sep 2, 2010, at 9:20 PM, Suresh Ramasubramanian wrote: > BCP38 / RFC2827 were created specifically to address some quite > similar problems. And googling either of those two strings on nanog > will get you a lot of griping and/or reasons as to why these aren't > being more widely adopted :) > > --srs > > On Fri, Sep 3, 2010 at 7:47 AM, Zhiyun Qian wrote: >> Suresh, thanks for your interest. I see you've had a lot of experience in fighting spam, so you must have known this. Yes, I know this spamming technique has been around for a while. But it's surprising to see that the majority of the ISPs that we studied are still vulnerable to this attack. That probably indicates that it is not as widely known as we would expect. So I thought it would be beneficial to raise the awareness of the problem. >> >> In terms of more results, the paper is the most detailed document we have. Otherwise, if you interested in the data that we collected (which ISPs or IP ranges are vulnerable to this attack). We can chat offline. >> >> Regards. >> -Zhiyun > > From dts at senie.com Fri Sep 3 03:04:54 2010 From: dts at senie.com (Daniel Senie) Date: Thu, 2 Sep 2010 23:04:54 -0400 Subject: ISP port blocking practice In-Reply-To: References: <0A08271D-49B9-4382-9F54-1A0BB6A3F2B2@umich.edu> <13222.1256232797@turing-police.cc.vt.edu> Message-ID: <3A97A2BA-C9FE-4554-908D-AD3986CC3E1B@senie.com> Ingress filtering is the correct tool for the job. The whole point here is that packets are coming from somewhere they should not, and they are thus spoofed. The tools have been in place to deal with this for a very long time now. The drafts that became RFC 2267 (precursor of RFC 2827 / BCP38) date from mid-1996. Paul and I wrote the original drafts to solve something else, but the issue is the same. Solving the vector you're concerned about doesn't need another layer of implementation in the mail servers. The packet routing fabric needs to handle it, and doing so addresses far more than just the email situation. I agree it'd be nice to get the asymmetric attack stopped, but disagree we need yet another mechanism to do it. - Dan On Sep 2, 2010, at 10:55 PM, Zhiyun Qian wrote: > I skimmed through these specs. They are useful but seems only related specific to IP spoofing prevention. I see that IP spoofing is part of the asymmetric routing story. But I was more thinking that given that IP spoofing is not widely adopted, the other defenses that they can more perhaps more easily implement is to block incoming traffic with source port 25 (if they already decided to block outgoing traffic with destination port 25). But according to our study, most of the ISPs didn't do that at the time of study (probably still true today). > > -Zhiyun > On Sep 2, 2010, at 9:20 PM, Suresh Ramasubramanian wrote: > >> BCP38 / RFC2827 were created specifically to address some quite >> similar problems. And googling either of those two strings on nanog >> will get you a lot of griping and/or reasons as to why these aren't >> being more widely adopted :) >> >> --srs >> >> On Fri, Sep 3, 2010 at 7:47 AM, Zhiyun Qian wrote: >>> Suresh, thanks for your interest. I see you've had a lot of experience in fighting spam, so you must have known this. Yes, I know this spamming technique has been around for a while. But it's surprising to see that the majority of the ISPs that we studied are still vulnerable to this attack. That probably indicates that it is not as widely known as we would expect. So I thought it would be beneficial to raise the awareness of the problem. >>> >>> In terms of more results, the paper is the most detailed document we have. Otherwise, if you interested in the data that we collected (which ISPs or IP ranges are vulnerable to this attack). We can chat offline. >>> >>> Regards. >>> -Zhiyun >> >> > > From owen at delong.com Fri Sep 3 03:48:20 2010 From: owen at delong.com (Owen DeLong) Date: Fri, 3 Sep 2010 13:18:20 +0930 Subject: ISP port blocking practice In-Reply-To: References: <0A08271D-49B9-4382-9F54-1A0BB6A3F2B2@umich.edu> <13222.1256232797@turing-police.cc.vt.edu> Message-ID: We should be seeking to stop damaging the network for ineffective anti spam measures (blocking outbound 25 for example) rather than to expand this practice to bidirectional brokenness. Owen Sent from my iPad On Sep 3, 2010, at 12:25 PM, Zhiyun Qian wrote: > I skimmed through these specs. They are useful but seems only related specific to IP spoofing prevention. I see that IP spoofing is part of the asymmetric routing story. But I was more thinking that given that IP spoofing is not widely adopted, the other defenses that they can more perhaps more easily implement is to block incoming traffic with source port 25 (if they already decided to block outgoing traffic with destination port 25). But according to our study, most of the ISPs didn't do that at the time of study (probably still true today). > > -Zhiyun > On Sep 2, 2010, at 9:20 PM, Suresh Ramasubramanian wrote: > >> BCP38 / RFC2827 were created specifically to address some quite >> similar problems. And googling either of those two strings on nanog >> will get you a lot of griping and/or reasons as to why these aren't >> being more widely adopted :) >> >> --srs >> >> On Fri, Sep 3, 2010 at 7:47 AM, Zhiyun Qian wrote: >>> Suresh, thanks for your interest. I see you've had a lot of experience in fighting spam, so you must have known this. Yes, I know this spamming technique has been around for a while. But it's surprising to see that the majority of the ISPs that we studied are still vulnerable to this attack. That probably indicates that it is not as widely known as we would expect. So I thought it would be beneficial to raise the awareness of the problem. >>> >>> In terms of more results, the paper is the most detailed document we have. Otherwise, if you interested in the data that we collected (which ISPs or IP ranges are vulnerable to this attack). We can chat offline. >>> >>> Regards. >>> -Zhiyun >> >> > From patrick at ianai.net Fri Sep 3 03:54:28 2010 From: patrick at ianai.net (Patrick W. Gilmore) Date: Thu, 2 Sep 2010 23:54:28 -0400 Subject: ISP port blocking practice In-Reply-To: References: <0A08271D-49B9-4382-9F54-1A0BB6A3F2B2@umich.edu> <13222.1256232797@turing-police.cc.vt.edu> Message-ID: On Sep 2, 2010, at 11:48 PM, Owen DeLong wrote: > We should be seeking to stop damaging the network for ineffective anti spam measures (blocking outbound 25 for example) rather than to expand this practice to bidirectional brokenness. Since at least part of your premise ('ineffective anti-spam measures') has been objectively proven false to fact for many years, I guess we can ignore the rest of your note. But thanx for playing. :) Also, just so everyone doesn't think I'm in favor of "damaging" the network, I would much prefer a completely open 'Net. Who wouldn't? Since that is not possible, we have to do what we can to damage the network as little as possible. Port 25 blocking is completely unnoticeable to something on the order of 5-nines worth of users, and the rest should know how to get around it with a minimum of fuss (including things like "ask your provider to unblock" in many cases). -- TTFN, patrick > On Sep 3, 2010, at 12:25 PM, Zhiyun Qian wrote: > >> I skimmed through these specs. They are useful but seems only related specific to IP spoofing prevention. I see that IP spoofing is part of the asymmetric routing story. But I was more thinking that given that IP spoofing is not widely adopted, the other defenses that they can more perhaps more easily implement is to block incoming traffic with source port 25 (if they already decided to block outgoing traffic with destination port 25). But according to our study, most of the ISPs didn't do that at the time of study (probably still true today). >> >> -Zhiyun >> On Sep 2, 2010, at 9:20 PM, Suresh Ramasubramanian wrote: >> >>> BCP38 / RFC2827 were created specifically to address some quite >>> similar problems. And googling either of those two strings on nanog >>> will get you a lot of griping and/or reasons as to why these aren't >>> being more widely adopted :) >>> >>> --srs >>> >>> On Fri, Sep 3, 2010 at 7:47 AM, Zhiyun Qian wrote: >>>> Suresh, thanks for your interest. I see you've had a lot of experience in fighting spam, so you must have known this. Yes, I know this spamming technique has been around for a while. But it's surprising to see that the majority of the ISPs that we studied are still vulnerable to this attack. That probably indicates that it is not as widely known as we would expect. So I thought it would be beneficial to raise the awareness of the problem. >>>> >>>> In terms of more results, the paper is the most detailed document we have. Otherwise, if you interested in the data that we collected (which ISPs or IP ranges are vulnerable to this attack). We can chat offline. >>>> >>>> Regards. >>>> -Zhiyun >>> >>> >> > From franck at genius.com Fri Sep 3 03:56:46 2010 From: franck at genius.com (Franck Martin) Date: Fri, 3 Sep 2010 15:56:46 +1200 (FJT) Subject: ISP port blocking practice In-Reply-To: Message-ID: <21142480.561.1283486205029.JavaMail.franck@franck-martins-macbook-pro.local> Blocking outbound port 25 in certain conditions (mainly anything with a dynamic IPv4), is a recommended practice from MAAWG.org and others, they have a few useful documents for ISPs to deal with their network. ----- Original Message ----- From: "Owen DeLong" To: "Zhiyun Qian" Cc: "NANOG list" Sent: Friday, 3 September, 2010 3:48:20 PM Subject: Re: ISP port blocking practice We should be seeking to stop damaging the network for ineffective anti spam measures (blocking outbound 25 for example) rather than to expand this practice to bidirectional brokenness. Owen Sent from my iPad On Sep 3, 2010, at 12:25 PM, Zhiyun Qian wrote: > I skimmed through these specs. They are useful but seems only related specific to IP spoofing prevention. I see that IP spoofing is part of the asymmetric routing story. But I was more thinking that given that IP spoofing is not widely adopted, the other defenses that they can more perhaps more easily implement is to block incoming traffic with source port 25 (if they already decided to block outgoing traffic with destination port 25). But according to our study, most of the ISPs didn't do that at the time of study (probably still true today). > > -Zhiyun > On Sep 2, 2010, at 9:20 PM, Suresh Ramasubramanian wrote: > >> BCP38 / RFC2827 were created specifically to address some quite >> similar problems. And googling either of those two strings on nanog >> will get you a lot of griping and/or reasons as to why these aren't >> being more widely adopted :) >> >> --srs >> >> On Fri, Sep 3, 2010 at 7:47 AM, Zhiyun Qian wrote: >>> Suresh, thanks for your interest. I see you've had a lot of experience in fighting spam, so you must have known this. Yes, I know this spamming technique has been around for a while. But it's surprising to see that the majority of the ISPs that we studied are still vulnerable to this attack. That probably indicates that it is not as widely known as we would expect. So I thought it would be beneficial to raise the awareness of the problem. >>> >>> In terms of more results, the paper is the most detailed document we have. Otherwise, if you interested in the data that we collected (which ISPs or IP ranges are vulnerable to this attack). We can chat offline. >>> >>> Regards. >>> -Zhiyun >> >> > From jbates at brightok.net Fri Sep 3 04:08:54 2010 From: jbates at brightok.net (Jack Bates) Date: Thu, 02 Sep 2010 23:08:54 -0500 Subject: ISP port blocking practice In-Reply-To: References: <0A08271D-49B9-4382-9F54-1A0BB6A3F2B2@umich.edu> <13222.1256232797@turing-police.cc.vt.edu> Message-ID: <4C8074D6.9050802@brightok.net> Patrick W. Gilmore wrote: >> We should be seeking to stop damaging the network for ineffective anti spam measures (blocking outbound 25 for example) rather than to expand this practice to bidirectional brokenness. > > Since at least part of your premise ('ineffective anti-spam measures') has been objectively proven false to fact for many years, I guess we can ignore the rest of your note. He's right though. tcp/25 blocks are a hack. Easy man's way out. Honestly, it'd be nicer if edge or even core systems could easily handle higher level filtering for things like this. There's plenty of systems that watch traffic patterns and issue blocks based on those patterns. I was working with a hotel today concerning just that. They were only doing a generic 500 connections in x period, block mac. They are now adding a tighter rule for 15 tcp/25 connections in 1 minute, block tcp/25 (or mac, doesn't matter to me). Of course, we didn't see valid reasons for mail blasts to be leaving a hotel and 15/minute is plenty of grace for a normal user. At an ISP level, it would work fine, though methods for determining exceptions would have to be planned (though that could easily be handled by customer classifications like everything else). > Also, just so everyone doesn't think I'm in favor of "damaging" the network, I would much prefer a completely open 'Net. Who wouldn't? Since that is not possible, we have to do what we can to damage the network as little as possible. Port 25 blocking is completely unnoticeable to something on the order of 5-nines worth of users, and the rest should know how to get around it with a minimum of fuss (including things like "ask your provider to unblock" in many cases). > Blocking inbound vs outbound is another story, though. Getting people to implement spoof protections is more useful. I'd be interested to see your data for concluding 5-nines of users, or did you just make that up? Jack From franck at genius.com Fri Sep 3 05:41:46 2010 From: franck at genius.com (Franck Martin) Date: Fri, 3 Sep 2010 17:41:46 +1200 (FJT) Subject: ISP port blocking practice In-Reply-To: <4C8074D6.9050802@brightok.net> Message-ID: <14226076.567.1283492502703.JavaMail.franck@franck-martins-macbook-pro.local> Have you heard of the submission port? Why Clients of an hotel would run a MTA anyhow? ----- Original Message ----- From: "Jack Bates" To: "NANOG list" Sent: Friday, 3 September, 2010 4:08:54 PM Subject: Re: ISP port blocking practice Patrick W. Gilmore wrote: >> We should be seeking to stop damaging the network for ineffective anti spam measures (blocking outbound 25 for example) rather than to expand this practice to bidirectional brokenness. > > Since at least part of your premise ('ineffective anti-spam measures') has been objectively proven false to fact for many years, I guess we can ignore the rest of your note. He's right though. tcp/25 blocks are a hack. Easy man's way out. Honestly, it'd be nicer if edge or even core systems could easily handle higher level filtering for things like this. There's plenty of systems that watch traffic patterns and issue blocks based on those patterns. I was working with a hotel today concerning just that. They were only doing a generic 500 connections in x period, block mac. They are now adding a tighter rule for 15 tcp/25 connections in 1 minute, block tcp/25 (or mac, doesn't matter to me). Of course, we didn't see valid reasons for mail blasts to be leaving a hotel and 15/minute is plenty of grace for a normal user. At an ISP level, it would work fine, though methods for determining exceptions would have to be planned (though that could easily be handled by customer classifications like everything else). > Also, just so everyone doesn't think I'm in favor of "damaging" the network, I would much prefer a completely open 'Net. Who wouldn't? Since that is not possible, we have to do what we can to damage the network as little as possible. Port 25 blocking is completely unnoticeable to something on the order of 5-nines worth of users, and the rest should know how to get around it with a minimum of fuss (including things like "ask your provider to unblock" in many cases). > Blocking inbound vs outbound is another story, though. Getting people to implement spoof protections is more useful. I'd be interested to see your data for concluding 5-nines of users, or did you just make that up? Jack From igor at ergens.org Fri Sep 3 10:14:52 2010 From: igor at ergens.org (Igor Ybema) Date: Fri, 3 Sep 2010 12:14:52 +0200 Subject: just seen my first IPv6 network abuse scan, is this the start for more? Message-ID: Hi, Since recently we noticed "Neighbour table overflow" warnings from the kernel on a lot of Linux machines. As this was very annoying for us and our customers I started to dump traffic and tried to find the cause. I discovered a external IPv6 host was doing a (rather useless due to the amount of addresses) IPv6 ICMP scan on our network recurring daily and mostly during the nights, sometimes with speeds of 1000 scans per second. Due to the ammount of IPv6 neighbor discoveries from our routers resulting from this scan the Neighbour table overflow messages appeared on the machines. Are there more people who have seen this behaviour recently? Is this a start of hackers/spammers onto the IPv6 network? This is the first scan I have seen. I already contacted the ISP for the source address. No answer yet. If I have more news I will post them here. regards, Igor Ybema the Netherlands From rdobbins at arbor.net Fri Sep 3 10:46:17 2010 From: rdobbins at arbor.net (Dobbins, Roland) Date: Fri, 3 Sep 2010 10:46:17 +0000 Subject: just seen my first IPv6 network abuse scan, is this the start for more? In-Reply-To: References: Message-ID: <6AD92173-D423-49E4-81BF-7E141249222B@arbor.net> On Sep 3, 2010, at 5:14 PM, Igor Ybema wrote: > I discovered a external IPv6 host was doing a (rather useless due to the amount of addresses) IPv6 ICMP scan on our network recurring daily and mostly during the nights, sometimes with speeds of 1000 scans per second. Not necessarily so useless, as it was hitting your boxen, eh? ;> Plus, setting bots to go scan isn't very labor-intensive. All the talk about how scanning isn't viable in IPv6-land due to large netblocks doesn't take into account the benefits of illicit automation. Note that hinted scanning, based upon DNS treewalking and so forth, is a useful refinement. > Due to the ammount of IPv6 neighbor discoveries from our routers resulting from this scan the Neighbour table overflow messages appeared on the machines. Any noticeable effect on router CPU? ----------------------------------------------------------------------- Roland Dobbins // Sell your computer and buy a guitar. From igor at ergens.org Fri Sep 3 11:12:42 2010 From: igor at ergens.org (Igor Ybema) Date: Fri, 3 Sep 2010 13:12:42 +0200 Subject: just seen my first IPv6 network abuse scan, is this the start for more? In-Reply-To: <6AD92173-D423-49E4-81BF-7E141249222B@arbor.net> References: <6AD92173-D423-49E4-81BF-7E141249222B@arbor.net> Message-ID: > Not necessarily so useless, as it was hitting your boxen, eh? True :) > Any noticeable effect on router CPU? Not visible in the graphs. A Foundry XMR was the router and all load on the CPU's in the router didn't change anything. regards, Igor From matthias.flittner at de-cix.net Fri Sep 3 11:43:20 2010 From: matthias.flittner at de-cix.net (Matthias Flittner) Date: Fri, 03 Sep 2010 13:43:20 +0200 Subject: just seen my first IPv6 network abuse scan, is this the start for more? In-Reply-To: References: Message-ID: <4C80DF58.30000@de-cix.net> Hi, > Since recently we noticed "Neighbour table overflow" warnings from > the kernel on a lot of Linux machines. As this was very annoying for > us and our customers I started to dump traffic and tried to find the > cause. sounds for me as an typicall IPv6 DoS attack. (see RFC3756) Sheng Jiang has discussed this issue in his draft: http://tools.ietf.org/html/draft-jiang-v6ops-nc-protection-01 regards, -F -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 552 bytes Desc: OpenPGP digital signature URL: From rdobbins at arbor.net Fri Sep 3 11:49:38 2010 From: rdobbins at arbor.net (Dobbins, Roland) Date: Fri, 3 Sep 2010 11:49:38 +0000 Subject: just seen my first IPv6 network abuse scan, is this the start for more? In-Reply-To: <4C80DF58.30000@de-cix.net> References: <4C80DF58.30000@de-cix.net> Message-ID: <9EEF657F-C5E9-4034-B07C-863C6C95B9AB@arbor.net> On Sep 3, 2010, at 6:43 PM, Matthias Flittner wrote: > sounds for me as an typicall IPv6 DoS attack. (see RFC3756) GMTA. Suggest checking to see if the targets have in fact been compromised (perhaps co-opted as botnet C&Cs, malware drop sites, et. al.?), and are being targeted by a rival gang. ----------------------------------------------------------------------- Roland Dobbins // Sell your computer and buy a guitar. From igor at ergens.org Fri Sep 3 12:02:21 2010 From: igor at ergens.org (Igor Ybema) Date: Fri, 3 Sep 2010 14:02:21 +0200 Subject: just seen my first IPv6 network abuse scan, is this the start for more? In-Reply-To: <4C80DF58.30000@de-cix.net> References: <4C80DF58.30000@de-cix.net> Message-ID: > Sheng Jiang has discussed this issue in his draft: > http://tools.ietf.org/html/draft-jiang-v6ops-nc-protection-01 If I understand the RFC correctly it is based on an attack within the same subnet. Looks a lot like arp-flooding. However this scan was from a external host. The only traffic I saw on the subnet was normal/valid NA lookups from the router towards an increasing IPv6-address (starting with ::1, then ::2 etc). On the router side I clearly saw the icmp traffic from the source doing a scan on these destination hosts. None of these IPv6 addresses are alive so no succes in scanning for comprised machines. regards, Igor From rdobbins at arbor.net Fri Sep 3 12:12:42 2010 From: rdobbins at arbor.net (Dobbins, Roland) Date: Fri, 3 Sep 2010 12:12:42 +0000 Subject: just seen my first IPv6 network abuse scan, is this the start for more? In-Reply-To: References: <4C80DF58.30000@de-cix.net> Message-ID: <991A86FF-B60B-41C6-9633-A25433989B1A@arbor.net> On Sep 3, 2010, at 7:02 PM, Igor Ybema wrote: > The only traffic I saw on the subnet was normal/valid NA lookups from the router towards an > increasing IPv6-address (starting with ::1, then ::2 etc). This could be a deliberately-induced DDoS due to the annoying ND stuff in IPv6, or just an ICMP sweep. Did it seem to concentrate on certain ranges, were the target addresses progressive, et. al.? ----------------------------------------------------------------------- Roland Dobbins // Sell your computer and buy a guitar. From owen at delong.com Fri Sep 3 12:12:01 2010 From: owen at delong.com (Owen DeLong) Date: Fri, 3 Sep 2010 05:12:01 -0700 Subject: ISP port blocking practice In-Reply-To: References: <0A08271D-49B9-4382-9F54-1A0BB6A3F2B2@umich.edu> <13222.1256232797@turing-police.cc.vt.edu> Message-ID: <9C23BD21-9384-4959-AAA5-8F4A31050CE1@delong.com> On Sep 2, 2010, at 8:54 PM, Patrick W. Gilmore wrote: > On Sep 2, 2010, at 11:48 PM, Owen DeLong wrote: > >> We should be seeking to stop damaging the network for ineffective anti spam measures (blocking outbound 25 for example) rather than to expand this practice to bidirectional brokenness. > > Since at least part of your premise ('ineffective anti-spam measures') has been objectively proven false to fact for many years, I guess we can ignore the rest of your note. > Really? So, since so many ISPs are blocking port 25, there's lots less spam hitting our networks? That's really news to me... I'm still seeing an ever increasing number of attempts to deliver spam on my mailservers. I'd say that it has been pretty ineffective. > Also, just so everyone doesn't think I'm in favor of "damaging" the network, I would much prefer a completely open 'Net. Who wouldn't? Since that is not possible, we have to do what we can to damage the network as little as possible. Port 25 blocking is completely unnoticeable to something on the order of 5-nines worth of users, and the rest should know how to get around it with a minimum of fuss (including things like "ask your provider to unblock" in many cases). > Not really true. First, i dispute your 5-nines figure, second, yes, i can usually get around it, but seems each network requires a different workaround. Since, like many of us, I use a lot of transient networks, having to reconfigure for each unique set of brokenness is actually wasting more of my time than the spam this brokenness was alleged to prevent. I suppose I should just shut up and run an instance of my SMTP daemon on port 80. After all, since IPv4 addresses are so abundant, rather than use port numbers for services, let's use IP addresses and force everything to ports 80 and 443. Owen From owen at delong.com Fri Sep 3 12:15:15 2010 From: owen at delong.com (Owen DeLong) Date: Fri, 3 Sep 2010 05:15:15 -0700 Subject: ISP port blocking practice In-Reply-To: <4C8074D6.9050802@brightok.net> References: <0A08271D-49B9-4382-9F54-1A0BB6A3F2B2@umich.edu> <13222.1256232797@turing-police.cc.vt.edu> <4C8074D6.9050802@brightok.net> Message-ID: On Sep 2, 2010, at 9:08 PM, Jack Bates wrote: > Patrick W. Gilmore wrote: >>> We should be seeking to stop damaging the network for ineffective anti spam measures (blocking outbound 25 for example) rather than to expand this practice to bidirectional brokenness. >> Since at least part of your premise ('ineffective anti-spam measures') has been objectively proven false to fact for many years, I guess we can ignore the rest of your note. > > He's right though. tcp/25 blocks are a hack. Easy man's way out. Honestly, it'd be nicer if edge or even core systems could easily handle higher level filtering for things like this. There's plenty of systems that watch traffic patterns and issue blocks based on those patterns. > > I was working with a hotel today concerning just that. They were only doing a generic 500 connections in x period, block mac. They are now adding a tighter rule for 15 tcp/25 connections in 1 minute, block tcp/25 (or mac, doesn't matter to me). Of course, we didn't see valid reasons for mail blasts to be leaving a hotel and 15/minute is plenty of grace for a normal user. At an ISP level, it would work fine, though methods for determining exceptions would have to be planned (though that could easily be handled by customer classifications like everything else). > This seems to me like it would be much more effective and less damaging without being significantly harder to implement. >> Also, just so everyone doesn't think I'm in favor of "damaging" the network, I would much prefer a completely open 'Net. Who wouldn't? Since that is not possible, we have to do what we can to damage the network as little as possible. Port 25 blocking is completely unnoticeable to something on the order of 5-nines worth of users, and the rest should know how to get around it with a minimum of fuss (including things like "ask your provider to unblock" in many cases). > > Blocking inbound vs outbound is another story, though. Getting people to implement spoof protections is more useful. I'd be interested to see your data for concluding 5-nines of users, or did you just make that up? > I'm all for anti-spoof (BCP-38) and strict/loose (as appropriate) RPF. I implement those things on networks I run. That's not damage, that's blocking things that shouldn't happen. I'd also like to see his data to support his claim that it is somehow effective at reducing spam. Owen From johnl at iecc.com Fri Sep 3 12:40:08 2010 From: johnl at iecc.com (John Levine) Date: 3 Sep 2010 12:40:08 -0000 Subject: ISP port blocking practice In-Reply-To: <9C23BD21-9384-4959-AAA5-8F4A31050CE1@delong.com> Message-ID: <20100903124008.72241.qmail@joyce.lan> >Really? So, since so many ISPs are blocking port 25, there's lots less spam >hitting our networks? It's been extremely effective in blocking spam sent by spambots on large ISPs. It's not a magic anti-spam bullet. (If you know one, please let us know.) >workaround. Since, like many of us, I use a lot of transient networks, >having to reconfigure for each unique set of brokenness is actually wasting >more of my time than the spam this brokenness was alleged to prevent. Is there some reason you aren't able to configure your computers to use tunnels or SUBMIT? They seem to work pretty well for other people. R's, John From owen at delong.com Fri Sep 3 12:22:00 2010 From: owen at delong.com (Owen DeLong) Date: Fri, 3 Sep 2010 05:22:00 -0700 Subject: ISP port blocking practice In-Reply-To: <14226076.567.1283492502703.JavaMail.franck@franck-martins-macbook-pro.local> References: <14226076.567.1283492502703.JavaMail.franck@franck-martins-macbook-pro.local> Message-ID: On Sep 2, 2010, at 10:41 PM, Franck Martin wrote: > Have you heard of the submission port? > Yes... Many of the idiots that block outbound 25 also block outbound 587 and sometimes 465. > Why Clients of an hotel would run a MTA anyhow? > Huh? I think you misunderstand... The problem is hotels blocking people from submitting outbound messages to their home MTA, not people trying to run an MTA inside their hotel room. NAT pretty much guarantees running an MTA inside the hotel room is impossible in most circumstances. (That might improve when IPv6 starts hitting hotel rooms, but, for now, it's just not there). Yes, some hotels offer you the option of a public IP (and usually when I take that option, I have fewer network problems in general. One of the reasons I tend to prefer Hilton brands when possible.) Owen > ----- Original Message ----- > From: "Jack Bates" > To: "NANOG list" > Sent: Friday, 3 September, 2010 4:08:54 PM > Subject: Re: ISP port blocking practice > > Patrick W. Gilmore wrote: >>> We should be seeking to stop damaging the network for ineffective anti spam measures (blocking outbound 25 for example) rather than to expand this practice to bidirectional brokenness. >> >> Since at least part of your premise ('ineffective anti-spam measures') has been objectively proven false to fact for many years, I guess we can ignore the rest of your note. > > He's right though. tcp/25 blocks are a hack. Easy man's way out. > Honestly, it'd be nicer if edge or even core systems could easily handle > higher level filtering for things like this. There's plenty of systems > that watch traffic patterns and issue blocks based on those patterns. > > I was working with a hotel today concerning just that. They were only > doing a generic 500 connections in x period, block mac. They are now > adding a tighter rule for 15 tcp/25 connections in 1 minute, block > tcp/25 (or mac, doesn't matter to me). Of course, we didn't see valid > reasons for mail blasts to be leaving a hotel and 15/minute is plenty of > grace for a normal user. At an ISP level, it would work fine, though > methods for determining exceptions would have to be planned (though that > could easily be handled by customer classifications like everything else). > >> Also, just so everyone doesn't think I'm in favor of "damaging" the network, I would much prefer a completely open 'Net. Who wouldn't? Since that is not possible, we have to do what we can to damage the network as little as possible. Port 25 blocking is completely unnoticeable to something on the order of 5-nines worth of users, and the rest should know how to get around it with a minimum of fuss (including things like "ask your provider to unblock" in many cases). >> > > Blocking inbound vs outbound is another story, though. Getting people to > implement spoof protections is more useful. I'd be interested to see > your data for concluding 5-nines of users, or did you just make that up? > > > Jack > From owen at delong.com Fri Sep 3 12:18:38 2010 From: owen at delong.com (Owen DeLong) Date: Fri, 3 Sep 2010 05:18:38 -0700 Subject: ISP port blocking practice In-Reply-To: <21142480.561.1283486205029.JavaMail.franck@franck-martins-macbook-pro.local> References: <21142480.561.1283486205029.JavaMail.franck@franck-martins-macbook-pro.local> Message-ID: <80648C57-E569-403B-8D4F-97C22CC05D14@delong.com> It may be a recommended practice from MAAWG, but, it's still damage to the network which is often routed around. It's a minor inconvenience to spammers and a slightly bigger problem for legitimate users. I don't see the win here. Just because they recommend it doesn't make it a good recommendation. MAAWG appears to have a single priority... Reducing spam by whatever means possible, regardless of cost or efficacy. Some of their recommendations (most, even) are good and useful. Some are easy to implement, ineffective, and ill-conceived. Outbound blocking of port 25 from people attempting to reach their home MTA/MSA with TLS and SMTP-AUTH just because they don't have a static address is an example of easy to implement, ineffective, and ill-conceived. Owen On Sep 2, 2010, at 8:56 PM, Franck Martin wrote: > Blocking outbound port 25 in certain conditions (mainly anything with a dynamic IPv4), is a recommended practice from MAAWG.org and others, they have a few useful documents for ISPs to deal with their network. > > ----- Original Message ----- > From: "Owen DeLong" > To: "Zhiyun Qian" > Cc: "NANOG list" > Sent: Friday, 3 September, 2010 3:48:20 PM > Subject: Re: ISP port blocking practice > > We should be seeking to stop damaging the network for ineffective anti spam measures (blocking outbound 25 for example) rather than to expand this practice to bidirectional brokenness. > > Owen > > Sent from my iPad > > On Sep 3, 2010, at 12:25 PM, Zhiyun Qian wrote: > >> I skimmed through these specs. They are useful but seems only related specific to IP spoofing prevention. I see that IP spoofing is part of the asymmetric routing story. But I was more thinking that given that IP spoofing is not widely adopted, the other defenses that they can more perhaps more easily implement is to block incoming traffic with source port 25 (if they already decided to block outgoing traffic with destination port 25). But according to our study, most of the ISPs didn't do that at the time of study (probably still true today). >> >> -Zhiyun >> On Sep 2, 2010, at 9:20 PM, Suresh Ramasubramanian wrote: >> >>> BCP38 / RFC2827 were created specifically to address some quite >>> similar problems. And googling either of those two strings on nanog >>> will get you a lot of griping and/or reasons as to why these aren't >>> being more widely adopted :) >>> >>> --srs >>> >>> On Fri, Sep 3, 2010 at 7:47 AM, Zhiyun Qian wrote: >>>> Suresh, thanks for your interest. I see you've had a lot of experience in fighting spam, so you must have known this. Yes, I know this spamming technique has been around for a while. But it's surprising to see that the majority of the ISPs that we studied are still vulnerable to this attack. That probably indicates that it is not as widely known as we would expect. So I thought it would be beneficial to raise the awareness of the problem. >>>> >>>> In terms of more results, the paper is the most detailed document we have. Otherwise, if you interested in the data that we collected (which ISPs or IP ranges are vulnerable to this attack). We can chat offline. >>>> >>>> Regards. >>>> -Zhiyun >>> >>> >> > From patrick at ianai.net Fri Sep 3 12:59:59 2010 From: patrick at ianai.net (Patrick W. Gilmore) Date: Fri, 3 Sep 2010 08:59:59 -0400 Subject: ISP port blocking practice In-Reply-To: <9C23BD21-9384-4959-AAA5-8F4A31050CE1@delong.com> References: <0A08271D-49B9-4382-9F54-1A0BB6A3F2B2@umich.edu> <13222.1256232797@turing-police.cc.vt.edu> <9C23BD21-9384-4959-AAA5-8F4A31050CE1@delong.com> Message-ID: <7D47957D-C343-408D-B6DF-033333DCF590@ianai.net> On Sep 3, 2010, at 8:12 AM, Owen DeLong wrote: > On Sep 2, 2010, at 8:54 PM, Patrick W. Gilmore wrote: >> On Sep 2, 2010, at 11:48 PM, Owen DeLong wrote: >> >>> We should be seeking to stop damaging the network for ineffective anti spam measures (blocking outbound 25 for example) rather than to expand this practice to bidirectional brokenness. >> >> Since at least part of your premise ('ineffective anti-spam measures') has been objectively proven false to fact for many years, I guess we can ignore the rest of your note. >> > Really? So, since so many ISPs are blocking port 25, there's lots less spam hitting our networks? > That's really news to me... I'm still seeing an ever increasing number of attempts to deliver spam on my mailservers. > > I'd say that it has been pretty ineffective. I'm not even going to bother replying with the multiple fallacies / logical errors you have made. I've known you for too long to assume you are that stupid, so I have to assume you are trolling. Which is beneath you. >> Also, just so everyone doesn't think I'm in favor of "damaging" the network, I would much prefer a completely open 'Net. Who wouldn't? Since that is not possible, we have to do what we can to damage the network as little as possible. Port 25 blocking is completely unnoticeable to something on the order of 5-nines worth of users, and the rest should know how to get around it with a minimum of fuss (including things like "ask your provider to unblock" in many cases). >> > Not really true. First, i dispute your 5-nines figure Perhaps a bit of hyperbole. Let's call it 3 nines. And before you dispute that more than 1 in a thousand notice, I'd like to see even the slightest shread of evidence. > second, yes, i can usually get around it, but seems each network requires a different workaround. My turn to dispute. SSH tunnels work on all but one network I've tried, even on port 22. And I've tried quite a few networks. Oh, and 100% of those networks allowed VPN. If you mean home networks require different hops to get port 25 opened, how many homes do you have? > Since, like many of us, I use a lot of transient networks, having to reconfigure for each unique set of brokenness is actually wasting more of my time than the spam this brokenness was alleged to prevent. First, life sux. I'm OK causing you more pain to save the 'Net from devolving into a useless mass of pure abuse. Second, if you are not following the RFCs and using the submit port, you get no sympathy. Third, see above with SSH tunnels & VPN. > I suppose I should just shut up and run an instance of my SMTP daemon on port 80. After all, since IPv4 addresses are so abundant, rather than use port numbers for services, let's use IP addresses and force everything to ports 80 and 443. Or you could follow the rules and use SUBMIT. But I agree with the "just shut up" part. :) -- TTFN, patrick From patrick at ianai.net Fri Sep 3 13:02:21 2010 From: patrick at ianai.net (Patrick W. Gilmore) Date: Fri, 3 Sep 2010 09:02:21 -0400 Subject: ISP port blocking practice In-Reply-To: References: <14226076.567.1283492502703.JavaMail.franck@franck-martins-macbook-pro.local> Message-ID: <782DAE51-C0F1-453B-8FEA-96754B6347E2@ianai.net> On Sep 3, 2010, at 8:22 AM, Owen DeLong wrote: > On Sep 2, 2010, at 10:41 PM, Franck Martin wrote: > >> Have you heard of the submission port? >> > Yes... Many of the idiots that block outbound 25 also block outbound 587 and sometimes 465. Could you point to more than one instance? I've not yet found one. And I think I spend at least as much time in hotels & 3G & airports & etc. as you anyone else here. -- TTFN, patrick From owen at delong.com Fri Sep 3 12:58:40 2010 From: owen at delong.com (Owen DeLong) Date: Fri, 3 Sep 2010 05:58:40 -0700 Subject: just seen my first IPv6 network abuse scan, is this the start for more? In-Reply-To: <6AD92173-D423-49E4-81BF-7E141249222B@arbor.net> References: <6AD92173-D423-49E4-81BF-7E141249222B@arbor.net> Message-ID: <3238DBCC-0258-47EA-B804-D8E254492182@delong.com> On Sep 3, 2010, at 3:46 AM, Dobbins, Roland wrote: > > On Sep 3, 2010, at 5:14 PM, Igor Ybema wrote: > >> I discovered a external IPv6 host was doing a (rather useless due to the amount of addresses) IPv6 ICMP scan on our network recurring daily and mostly during the nights, sometimes with speeds of 1000 scans per second. > > Not necessarily so useless, as it was hitting your boxen, eh? > > ;> > > Plus, setting bots to go scan isn't very labor-intensive. All the talk about how scanning isn't viable in IPv6-land due to large netblocks doesn't take into account the benefits of illicit automation. > Uh... He mentioned 1000 addresses/second... At that rate, scanning a /64 will take more than 18,000,000,000,000,000 seconds. Converted to hours, that's 5,000,000,000,000 hours which works out to 208,333,333,333 days or roughly 570,776,255 years. If you want to scan a single IPv6 subnet completely in 1 year, you will need to automate 570,776,255 machines scanning at 1000 ip addresses per second, and, your target network will need to be able to process 570,776,255,000 packets per second. Yes, you can do a certain amount of table-overflow DOS with an IPv6 scan, but, you really can't accomplish much else in practical terms. > Note that hinted scanning, based upon DNS treewalking and so forth, is a useful refinement. > Yes, you can find hosts for which you already know the addresses easily this way. Obviously, there are a few other tricks that make it easy to find individual targets (such as the convention of making a router ::1). However, scanning in IPv6 is not at all like the convenience of comprehensive scanning of the IPv4 address space. >> Due to the ammount of IPv6 neighbor discoveries from our routers resulting from this scan the Neighbour table overflow messages appeared on the machines. > > > Any noticeable effect on router CPU? > Probably not a lot. Probably even less on the boxes reporting the neighbor table overflow. Other than generating some noisy error messages, this should have been pretty much a non- event. Owen From matthias.flittner at de-cix.net Fri Sep 3 13:07:40 2010 From: matthias.flittner at de-cix.net (Matthias Flittner) Date: Fri, 03 Sep 2010 15:07:40 +0200 Subject: just seen my first IPv6 network abuse scan, is this the start for more? In-Reply-To: References: <4C80DF58.30000@de-cix.net> Message-ID: <4C80F31C.1010009@de-cix.net> > However this scan was from a external host. The only traffic I saw on > the subnet was normal/valid NA lookups from the router towards an > increasing IPv6-address (starting with ::1, then ::2 etc). On the > router side I clearly saw the icmp traffic from the source doing a > scan on these destination hosts. typically this fill the NC with faked entries and exhaust the node's cache resources. "This interrupts the normal functions of the targeted IPv6 node." In other words: The attacker sends a lot of ICMPv6 echo requests to your /64 subnet. Your router has to resolve this addresses internaly (each NA is stored in NC of the router). The node's cace resources are exhausted and no "normal" NA could be stored. I think that was your problem. Unfortunately is there no standardized way to mitigate this attacks, yet. However there are many approaches which could help or could be discussed. (like http://www.freepatentsonline.com/20070130427.pdf or other) best regards, -F -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 552 bytes Desc: OpenPGP digital signature URL: From nanog at ilk.net Fri Sep 3 13:49:19 2010 From: nanog at ilk.net (nanog at ilk.net) Date: Fri, 3 Sep 2010 15:49:19 +0200 Subject: seek cable/dsl provider in Troy MI 48083 USA Message-ID: <3F1408F6031841338B648E68AF59E4D6@intra.ilk.net> Hi, for a customer at Stephenson Highway Troy, MI 48083 USA we seek an internet access/service provider, cable/xdsl/... would be ok, fixed ip-address prefered. Please answer off-list. Thank you for your kind support, Have a nice weekend, J?rgen Marenda, ILK From rdobbins at arbor.net Fri Sep 3 13:49:40 2010 From: rdobbins at arbor.net (Dobbins, Roland) Date: Fri, 3 Sep 2010 13:49:40 +0000 Subject: just seen my first IPv6 network abuse scan, is this the start for more? In-Reply-To: <3238DBCC-0258-47EA-B804-D8E254492182@delong.com> References: <6AD92173-D423-49E4-81BF-7E141249222B@arbor.net> <3238DBCC-0258-47EA-B804-D8E254492182@delong.com> Message-ID: On Sep 3, 2010, at 7:58 PM, Owen DeLong wrote: > However, scanning in IPv6 is not at all like the convenience of comprehensive scanning of the IPv4 address space. Concur, but I still maintain that lots of illicit automation plus refined scanning via DNS, et. al. is a viable practice. ----------------------------------------------------------------------- Roland Dobbins // Sell your computer and buy a guitar. From jbates at brightok.net Fri Sep 3 14:03:19 2010 From: jbates at brightok.net (Jack Bates) Date: Fri, 03 Sep 2010 09:03:19 -0500 Subject: ISP port blocking practice In-Reply-To: <782DAE51-C0F1-453B-8FEA-96754B6347E2@ianai.net> References: <14226076.567.1283492502703.JavaMail.franck@franck-martins-macbook-pro.local> <782DAE51-C0F1-453B-8FEA-96754B6347E2@ianai.net> Message-ID: <4C810027.3060100@brightok.net> Patrick W. Gilmore wrote: >> Yes... Many of the idiots that block outbound 25 also block outbound 587 and sometimes 465. > > Could you point to more than one instance? I've not yet found one. And I think I spend at least as much time in hotels & 3G & airports & etc. as you anyone else here. > I can't remember the ISP, but yes, I've run across this. I had to have my helpdesk inform the customer that they'll have to complain and gripe at the ISP they were using or make other arrangements as I only support 25/587 (customer didn't want to use webmail). Problem is, people hear "block ports", they get in the habit, and the next thing you know, they are blocking ports out of ignorance with no comprehension of what they are breaking. I'd much rather see rate detection setups that let me send however I want, but limit the connections per time interval. It implies that some thought might go into determining the rates. Of course, the only setup I've done like this in testing in my network involved flow analyzers and dynamic acl's. Jack From jcdill.lists at gmail.com Fri Sep 3 14:38:31 2010 From: jcdill.lists at gmail.com (JC Dill) Date: Fri, 03 Sep 2010 07:38:31 -0700 Subject: ISP port blocking practice In-Reply-To: <782DAE51-C0F1-453B-8FEA-96754B6347E2@ianai.net> References: <14226076.567.1283492502703.JavaMail.franck@franck-martins-macbook-pro.local> <782DAE51-C0F1-453B-8FEA-96754B6347E2@ianai.net> Message-ID: <4C810867.10202@gmail.com> Patrick W. Gilmore wrote: > On Sep 3, 2010, at 8:22 AM, Owen DeLong wrote: > >> On Sep 2, 2010, at 10:41 PM, Franck Martin wrote: >> >> >>> Have you heard of the submission port? >>> >>> >> Yes... Many of the idiots that block outbound 25 also block outbound 587 and sometimes 465. >> > > Could you point to more than one instance? I've not yet found one. And I think I spend at least as much time in hotels & 3G & airports & etc. as you anyone else here. > > FWIW, I had it happen at a local library. Used their webform to send a message mentioning that blocking 25 was good, but blocking 587 and 465 was bad. It took several days but they did fix it. jc From randy at psg.com Fri Sep 3 15:16:54 2010 From: randy at psg.com (Randy Bush) Date: Sat, 04 Sep 2010 00:16:54 +0900 Subject: ISP port blocking practice In-Reply-To: <4C810867.10202@gmail.com> References: <14226076.567.1283492502703.JavaMail.franck@franck-martins-macbook-pro.local> <782DAE51-C0F1-453B-8FEA-96754B6347E2@ianai.net> <4C810867.10202@gmail.com> Message-ID: > FWIW, I had it happen at a local library. Used their webform to send a > message mentioning that blocking 25 was good, but blocking 587 and 465 > was bad. It took several days but they did fix it. that was the condition at narita red carpet a few years back. had to pull a chain at ugs in chicago to find someone who knew what i meant. randy From warren at kumari.net Fri Sep 3 15:22:15 2010 From: warren at kumari.net (Warren Kumari) Date: Fri, 3 Sep 2010 11:22:15 -0400 Subject: largest OSPF core In-Reply-To: <4C7FBEBF.2020208@foobar.org> References: <4C7F9675.8050208@gmail.com> <4C7FBEBF.2020208@foobar.org> Message-ID: <0B5773E4-33CC-426F-A6D0-E0B8D3709764@kumari.net> On Sep 2, 2010, at 11:11 AM, Nick Hilliard wrote: > On 02/09/2010 13:20, lorddoskias wrote: >> I'm just curious - what is the largest OSPF core (in terms of >> number of >> routers) out there? > > You don't expect anyone to actually admit to something like this? :-) Of course I do -- 'tis much for your reputation to have wrangled a poorly designed, ugly network under control than to have only worked at places with smooth sailing.... I *don't* expect the owner / designers of these to come forward, rather those who inherited a pile of choss to share war stories... :-P I worked on a network that had >350 routers in an (non-zero) area. Now, ~350 routers in an area doesn't sound *that* impressive, but on average these devices had 6 interfaces in OSPF, and many of these links were of the form: [router A]-- {GRE} --- [firewall]-- {GRE in IPSEC} ------- [Internet]------- {GRE in IPSEC} ---[firewall]---{GRE} --- [router B] Routers A and B would form an OSPF adjacency. Much of this was an overlay network (over the Internet) and so the firewalls would build IPSec tunnels. Of course, said firewalls would not pass OSPF, so we had to build GRE tunnels between routers A and D and run OSPF over those -- traffic would enter the router, get encapsulated in GRE and then the GRE would be encapsulated in IPSec and tossed into the void.... In other places (in the same OSPF area) we would purchase parallel T1 / E1s that we would run MLPPP over, and / or plain DS3s. Oh, did I mention that network was primarily to support international call centers that had been outsourced to wherever was *really* cheap, and that many places with very cheap labor have very poor infrastructure? It was not uncommon to have interfaces that would bounce 5 or 10 times a day*.... W *: And yes, we did 'ave to get up out of shoebox at twelve o'clock at night and lick road clean wit' tongue. We had two bits of cold gravel, worked twenty-four hours a day at mill for sixpence every four years, and when we got home our Dad would slice us in two wit' bread knife. > > Nick > -- It's a mistake trying to cheer up camels. You might as well drop meringues into a black hole. -- Terry Prachett From bill at herrin.us Fri Sep 3 15:23:00 2010 From: bill at herrin.us (William Herrin) Date: Fri, 3 Sep 2010 11:23:00 -0400 Subject: ISP port blocking practice In-Reply-To: <3A97A2BA-C9FE-4554-908D-AD3986CC3E1B@senie.com> References: <0A08271D-49B9-4382-9F54-1A0BB6A3F2B2@umich.edu> <13222.1256232797@turing-police.cc.vt.edu> <3A97A2BA-C9FE-4554-908D-AD3986CC3E1B@senie.com> Message-ID: On Thu, Sep 2, 2010 at 11:04 PM, Daniel Senie wrote: > Ingress filtering is the correct tool for the job. Not really. Ingress filtering only ever protected you from being the source of spooding attacks, not the destination. The point of Zhiyun's results is that it doesn't fully protect you from being the source either. Frankly, Zhiyun offers the first truly rational case I've personally seen for packet filtering based on the TCP source port. You should give his work more careful scrutiny. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From nick at foobar.org Fri Sep 3 15:25:14 2010 From: nick at foobar.org (Nick Hilliard) Date: Fri, 03 Sep 2010 16:25:14 +0100 Subject: ISP port blocking practice In-Reply-To: References: <14226076.567.1283492502703.JavaMail.franck@franck-martins-macbook-pro.local> <782DAE51-C0F1-453B-8FEA-96754B6347E2@ianai.net> <4C810867.10202@gmail.com> Message-ID: <4C81135A.3030608@foobar.org> On 03/09/2010 16:16, Randy Bush wrote: > that was the condition at narita red carpet a few years back. had to > pull a chain at ugs in chicago to find someone who knew what i meant. and people wonder why developers implement * over http/https. Sigh. Nick From butche at butchevans.com Fri Sep 3 16:10:09 2010 From: butche at butchevans.com (Butch Evans) Date: Fri, 03 Sep 2010 11:10:09 -0500 Subject: ISP port blocking practice In-Reply-To: <4C8074D6.9050802@brightok.net> References: <0A08271D-49B9-4382-9F54-1A0BB6A3F2B2@umich.edu> <13222.1256232797@turing-police.cc.vt.edu> <4C8074D6.9050802@brightok.net> Message-ID: <1283530209.30467.2.camel@localhost.localdomain> On Thu, 2010-09-02 at 23:08 -0500, Jack Bates wrote: > He's right though. tcp/25 blocks are a hack. Easy man's way out. Also, this can be a little problematic to end users. > Honestly, it'd be nicer if edge or even core systems could easily handle > higher level filtering for things like this. There's plenty of systems > that watch traffic patterns and issue blocks based on those patterns. I am not an ISP, but provide consulting services to ISPs. My approach to this problem is somewhat more dynamic than simple blocking of outbound port 25. Bear in mind, that I don't do much consulting for companies that are transport for other ISPs (though I have a few of those type clients). My approach is quite simple, but has been pretty effective for those clients that are using it: * Watch for outbound mail checking traffic (TCP/110, TCP 143, etc.) and capture the server IPs these users are talking to * Permit outbound SMTP coming FROM known mail servers inside the network * Permit inbound SMTP going TO known mail servers inside the network * Permit outbound SMTP going TO mail servers that our end users use the CHECK their mail * Log the IP of the end users trying to send outbound email via a server that is NOT on the above list. * Deny all other outbound SMTP This method is nearly 100% effective in eliminating spam bots that are currently the most common type. These spam bots originate smtp connections direct to the MX for the list they are sending mail to. This method is relatively problem free for the ISP once it is set up. -- ******************************************************************** * Butch Evans * Professional Network Consultation* * http://www.butchevans.com/ * Network Engineering * * http://store.wispgear.net/ * Wired or Wireless Networks * * http://blog.butchevans.com/ * ImageStream, Mikrotik and MORE! * ******************************************************************** From james at freedomnet.co.nz Fri Sep 3 16:51:54 2010 From: james at freedomnet.co.nz (James Jones) Date: Fri, 03 Sep 2010 12:51:54 -0400 Subject: verizon outage Message-ID: <4C8127AA.5090507@freedomnet.co.nz> anyone experiencing issues with verizon in western mass? -- James Jones +1-413-667-9199 james at freedomnet.co.nz From owen at delong.com Fri Sep 3 17:00:06 2010 From: owen at delong.com (Owen DeLong) Date: Sat, 4 Sep 2010 02:30:06 +0930 Subject: ISP port blocking practice In-Reply-To: <4C810867.10202@gmail.com> References: <14226076.567.1283492502703.JavaMail.franck@franck-martins-macbook-pro.local> <782DAE51-C0F1-453B-8FEA-96754B6347E2@ianai.net> <4C810867.10202@gmail.com> Message-ID: <3219631C-CE91-432F-ACEA-50CA03B321C9@delong.com> I have had it happen in some metro areas on sprint. I have experienced it in at least a dozen hotels over the last 12 months. I have run into it in various airports with free public wifi. I have run into the problem in several coffee shops. By far, the worst offenders are the most expensive hotels where the Internet access, damaged as it is generally goes for $25+ per day. I almost always end up getting free Internet as a result because I report the issue as a problem and their technical support usually can't spell tcp let alone understand what I mean when I say a port is blocked. Even worse is the ones that silently redirect your smtp (regardless of port) session to their MTA. Fortunately, my configuration is good enough that it just breaks in these cases, but I know many people who thought they were connecting to their own server via TLS only to later discover that their mail was relayed in clear text through several third party servers. (most mua's seem to have an unfortunate default to "ssl or tis if available" and keep right on sending even if tis negotiations are rejected.) Owen Sent from my iPad On Sep 4, 2010, at 12:08 AM, JC Dill wrote: > Patrick W. Gilmore wrote: >> On Sep 3, 2010, at 8:22 AM, Owen DeLong wrote: >> >>> On Sep 2, 2010, at 10:41 PM, Franck Martin wrote: >>> >>> >>>> Have you heard of the submission port? >>>> >>>> >>> Yes... Many of the idiots that block outbound 25 also block outbound 587 and sometimes 465. >>> >> >> Could you point to more than one instance? I've not yet found one. And I think I spend at least as much time in hotels & 3G & airports & etc. as you anyone else here. >> >> > FWIW, I had it happen at a local library. Used their webform to send a message mentioning that blocking 25 was good, but blocking 587 and 465 was bad. It took several days but they did fix it. > > jc > From Bryan.Welch at arrisi.com Fri Sep 3 17:03:03 2010 From: Bryan.Welch at arrisi.com (Welch, Bryan) Date: Fri, 3 Sep 2010 10:03:03 -0700 Subject: Juniper to Watchguard IPSEC Message-ID: Anyone have any experience with IPSEC between a WG Firebox and Juniper SRX/SSG? Running into some problems and beginning to think there might be some incompatibilities in their IPSEC options. TIA, Bryan From morrowc.lists at gmail.com Fri Sep 3 17:12:01 2010 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Fri, 3 Sep 2010 13:12:01 -0400 Subject: verizon outage In-Reply-To: <4C8127AA.5090507@freedomnet.co.nz> References: <4C8127AA.5090507@freedomnet.co.nz> Message-ID: On Fri, Sep 3, 2010 at 12:51 PM, James Jones wrote: > ?anyone experiencing issues with verizon in western mass? o this isn't the outages list, that one MAY have more info for you o there are many verizons... which one are you talking about? (wireless, dsl/fios, fUUNET, private-line services, private-network services...) -Chris From smb at cs.columbia.edu Fri Sep 3 17:19:51 2010 From: smb at cs.columbia.edu (Steven Bellovin) Date: Fri, 3 Sep 2010 13:19:51 -0400 Subject: just seen my first IPv6 network abuse scan, is this the start for more? In-Reply-To: References: <6AD92173-D423-49E4-81BF-7E141249222B@arbor.net> <3238DBCC-0258-47EA-B804-D8E254492182@delong.com> Message-ID: <6A6F346A-2AA6-47E4-92D2-967627CE1202@cs.columbia.edu> On Sep 3, 2010, at 9:49 40AM, Dobbins, Roland wrote: > > On Sep 3, 2010, at 7:58 PM, Owen DeLong wrote: > >> However, scanning in IPv6 is not at all like the convenience of comprehensive scanning of the IPv4 address space. > > > Concur, but I still maintain that lots of illicit automation plus refined scanning via DNS, et. al. is a viable practice. See http://www.cs.columbia.edu/~smb/papers/v6worms.pdf --Steve Bellovin, http://www.cs.columbia.edu/~smb From cmaurand at xyonet.com Fri Sep 3 17:44:42 2010 From: cmaurand at xyonet.com (Curtis Maurand) Date: Fri, 03 Sep 2010 13:44:42 -0400 Subject: ISP port blocking practice In-Reply-To: <3219631C-CE91-432F-ACEA-50CA03B321C9@delong.com> References: <14226076.567.1283492502703.JavaMail.franck@franck-martins-macbook-pro.local> <782DAE51-C0F1-453B-8FEA-96754B6347E2@ianai.net> <4C810867.10202@gmail.com> <3219631C-CE91-432F-ACEA-50CA03B321C9@delong.com> Message-ID: <4C81340A.6090501@xyonet.com> I use SSL only and even then, it requires authentication. --Curtis On 9/3/2010 1:00 PM, Owen DeLong wrote: > I have had it happen in some metro areas on sprint. I have experienced it in at least a dozen hotels over the last 12 months. I have run into it in various airports with free public wifi. I have run into the problem in several coffee shops. > > By far, the worst offenders are the most expensive hotels where the Internet access, damaged as it is generally goes for $25+ per day. I almost always end up getting free Internet as a result because I report the issue as a problem and their technical support usually can't spell tcp let alone understand what I mean when I say a port is blocked. > > Even worse is the ones that silently redirect your smtp (regardless of port) session to their MTA. Fortunately, my configuration is good enough that it just breaks in these cases, but I know many people who thought they were connecting to their own server via TLS only to later discover that their mail was relayed in clear text through several third party servers. (most mua's seem to have an unfortunate default to "ssl or tis if available" and keep right on sending even if tis negotiations are rejected.) > > Owen > > > Sent from my iPad > > On Sep 4, 2010, at 12:08 AM, JC Dill wrote: From owen at delong.com Fri Sep 3 18:03:24 2010 From: owen at delong.com (Owen DeLong) Date: Sat, 4 Sep 2010 03:33:24 +0930 Subject: just seen my first IPv6 network abuse scan, is this the start for more? In-Reply-To: References: <6AD92173-D423-49E4-81BF-7E141249222B@arbor.net> <3238DBCC-0258-47EA-B804-D8E254492182@delong.com> Message-ID: <1C59005C-9A0C-42C8-8E56-6ABFAA1DD67C@delong.com> Sent from my iPad On Sep 3, 2010, at 11:19 PM, "Dobbins, Roland" wrote: > > On Sep 3, 2010, at 7:58 PM, Owen DeLong wrote: > >> However, scanning in IPv6 is not at all like the convenience of comprehensive scanning of the IPv4 address space. > > > Concur, but I still maintain that lots of illicit automation plus refined scanning via DNS, et. al. is a viable practice. > Care to elaborate? I'm betting you could find a handful of hosts on my network that are published in DNS (in which case you either already had their names, so, not sure what the scan does for you). I bet you would not easily find the rest. The prefix is 2620:0:930::/48. Have fun, you have my permission to sweep the address space twice. If we are still alive when you think you found everything, or, enough to have learned something from scanning that is meaningful and couldn't have been learned without scanning, send me your information and I'll let you know how well you did. Owen > ----------------------------------------------------------------------- > Roland Dobbins // > > Sell your computer and buy a guitar. > > > > From owen at delong.com Fri Sep 3 18:10:17 2010 From: owen at delong.com (Owen DeLong) Date: Sat, 4 Sep 2010 03:40:17 +0930 Subject: ISP port blocking practice In-Reply-To: <20100903124008.72241.qmail@joyce.lan> References: <20100903124008.72241.qmail@joyce.lan> Message-ID: <918D3F33-E46F-40F0-9325-FAE4AE5E0D05@delong.com> Sent from my iPad On Sep 3, 2010, at 10:10 PM, John Levine wrote: >> Really? So, since so many ISPs are blocking port 25, there's lots less spam >> hitting our networks? > > It's been extremely effective in blocking spam sent by spambots on > large ISPs. It's not a magic anti-spam bullet. (If you know one, > please let us know.) > That simply hasn't been my experience. I still get lots of spam from booted hosts in large provider networks, and yes, that includes many that block 25. As near as I can tell, 25 blocking is not affecting spammers at all, just legitimate users. There was a time when it was effective, but the spammers have long since adapted. Now we are only breaking the Internet. We are no ,onger accomplishing anything ireful. It's pure momentum. >> workaround. Since, like many of us, I use a lot of transient networks, >> having to reconfigure for each unique set of brokenness is actually wasting >> more of my time than the spam this brokenness was alleged to prevent. > > Is there some reason you aren't able to configure your computers to use > tunnels or SUBMIT? They seem to work pretty well for other people. > Many of the transient networks I deal with block 22, 25, 465, and 587. They also often block protocols 41 and 43 or do not provide a public address, rendering those protocols unusable anyway. Yes, I am now running ssh and s,tp processes on ports 80 and 443 to get around this, but, that consumes an extra address for something that should be handled by a port number. Personally, i'd rather use port numbers for l4 uniqueness rather than IP Addresses. Owen > R's, > John From bogstad at pobox.com Fri Sep 3 18:25:14 2010 From: bogstad at pobox.com (Bill Bogstad) Date: Fri, 3 Sep 2010 14:25:14 -0400 Subject: just seen my first IPv6 network abuse scan, is this the start for more? In-Reply-To: References: <6AD92173-D423-49E4-81BF-7E141249222B@arbor.net> <3238DBCC-0258-47EA-B804-D8E254492182@delong.com> Message-ID: On Fri, Sep 3, 2010 at 9:49 AM, Dobbins, Roland wrote: > > On Sep 3, 2010, at 7:58 PM, Owen DeLong wrote: > >> However, scanning in IPv6 is not at all like the convenience of comprehensive scanning of the IPv4 address space. > > > Concur, but I still maintain that lots of illicit automation plus refined scanning via DNS, et. al. is a viable practice. These are very big numbers, so I don't see how. If you use easy to guess/remember host/service names and put them in public DNS then those IP addresses are in some sense already public (whether IPv4 or IPv6). The definition of "easy to guess" is pretty much everything which has ever been used in a wordlist for password cracking programs (plus the code which generates variants of same). Real attackers are going to flood your DNS servers, not do brute force IPv6 ICMP scans. Even a pure brute force DNS scan of all 10 character long hostnames (asuming a-z0-9) is going to take around 5000 times fewer queries then a full ICMP v6 scan of a /64. (Which at an attack speed of 1000pps is still going to take around 100,000 years.) For machines which you want to make it REALLY hard to find, but need publicly accessible addresses, you shouldn't put them in publicly queryable DNS servers at all and use a random number generator to generate their static IPv6 addresses. Even if you put a thousand of these machines in a single subnet, it is going to take half a million years at reasonable packet rates before even one of them is discovered. Hmm, thinking about it in terms of passwords might help. Many people consider a totally random 10 character monocase+numbers password to be reasonably secure against brute force attacks. ICMP scanning a /64 is thousands of times more difficult and all it gives you is the existence of the machine. Even if you find that needle in a hay stack , you don't get access to its resources. I took a quick look at the paper that SMB linked to and I would argue that for wide area attacks, packet sniffing is going to be how people find your "hidden" addresses. Compromising SMB wi-fi hotspot hardware and logging every address accessed is one possibility. Or just compromise people's laptops and have them run network sniffers which generate "seen" address lists which are forwarded to dummy gmail accounts. Bill Bogstad From jbates at brightok.net Fri Sep 3 18:27:20 2010 From: jbates at brightok.net (Jack Bates) Date: Fri, 03 Sep 2010 13:27:20 -0500 Subject: just seen my first IPv6 network abuse scan, is this the start for more? In-Reply-To: <6A6F346A-2AA6-47E4-92D2-967627CE1202@cs.columbia.edu> References: <6AD92173-D423-49E4-81BF-7E141249222B@arbor.net> <3238DBCC-0258-47EA-B804-D8E254492182@delong.com> <6A6F346A-2AA6-47E4-92D2-967627CE1202@cs.columbia.edu> Message-ID: <4C813E08.4000700@brightok.net> Steven Bellovin wrote: > > See http://www.cs.columbia.edu/~smb/papers/v6worms.pdf > Or my lame take on the matter http://geekmerc.livejournal.com/1421.html -Jack *saves yours to read up later* From cscora at apnic.net Fri Sep 3 18:38:23 2010 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 4 Sep 2010 04:38:23 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <201009031838.o83IcN1l008986@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. The posting is sent to APOPS, NANOG, AfNOG, AusNOG, SANOG, PacNOG, LacNOG, CaribNOG and the RIPE Routing Working Group. Daily listings are sent to bgp-stats at lists.apnic.net For historical data, please see http://thyme.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 04 Sep, 2010 Report Website: http://thyme.apnic.net Detailed Analysis: http://thyme.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 330158 Prefixes after maximum aggregation: 151682 Deaggregation factor: 2.18 Unique aggregates announced to Internet: 162121 Total ASes present in the Internet Routing Table: 34721 Prefixes per ASN: 9.51 Origin-only ASes present in the Internet Routing Table: 30112 Origin ASes announcing only one prefix: 14633 Transit ASes present in the Internet Routing Table: 4609 Transit-only ASes present in the Internet Routing Table: 102 Average AS path length visible in the Internet Routing Table: 3.6 Max AS path length visible: 24 Max AS path prepend of ASN (41664) 21 Prefixes from unregistered ASNs in the Routing Table: 1987 Unregistered ASNs in the Routing Table: 969 Number of 32-bit ASNs allocated by the RIRs: 757 Prefixes from 32-bit ASNs in the Routing Table: 991 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 191 Number of addresses announced to Internet: 2279348416 Equivalent to 135 /8s, 220 /16s and 24 /24s Percentage of available address space announced: 61.5 Percentage of allocated address space announced: 65.7 Percentage of available address space allocated: 93.7 Percentage of address space in use by end-sites: 84.6 Total number of prefixes smaller than registry allocations: 156259 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 80332 Total APNIC prefixes after maximum aggregation: 27557 APNIC Deaggregation factor: 2.92 Prefixes being announced from the APNIC address blocks: 77315 Unique aggregates announced from the APNIC address blocks: 34057 APNIC Region origin ASes present in the Internet Routing Table: 4177 APNIC Prefixes per ASN: 18.51 APNIC Region origin ASes announcing only one prefix: 1170 APNIC Region transit ASes present in the Internet Routing Table: 642 Average APNIC Region AS path length visible: 3.7 Max APNIC Region AS path length visible: 16 Number of APNIC addresses announced to Internet: 543003680 Equivalent to 32 /8s, 93 /16s and 148 /24s Percentage of available APNIC address space announced: 77.1 APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079 55296-56319, 131072-132095 APNIC Address Blocks 1/8, 14/8, 27/8, 43/8, 49/8, 58/8, 59/8, 60/8, 61/8, 101/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, 133/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, 223/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 135713 Total ARIN prefixes after maximum aggregation: 69909 ARIN Deaggregation factor: 1.94 Prefixes being announced from the ARIN address blocks: 108391 Unique aggregates announced from the ARIN address blocks: 42744 ARIN Region origin ASes present in the Internet Routing Table: 13888 ARIN Prefixes per ASN: 7.80 ARIN Region origin ASes announcing only one prefix: 5328 ARIN Region transit ASes present in the Internet Routing Table: 1377 Average ARIN Region AS path length visible: 3.4 Max ARIN Region AS path length visible: 22 Number of ARIN addresses announced to Internet: 733182368 Equivalent to 43 /8s, 179 /16s and 121 /24s Percentage of available ARIN address space announced: 62.4 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, 393216-394239 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, 50/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, 107/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: 75380 Total RIPE prefixes after maximum aggregation: 43966 RIPE Deaggregation factor: 1.71 Prefixes being announced from the RIPE address blocks: 68844 Unique aggregates announced from the RIPE address blocks: 45168 RIPE Region origin ASes present in the Internet Routing Table: 14750 RIPE Prefixes per ASN: 4.67 RIPE Region origin ASes announcing only one prefix: 7592 RIPE Region transit ASes present in the Internet Routing Table: 2218 Average RIPE Region AS path length visible: 3.9 Max RIPE Region AS path length visible: 24 Number of RIPE addresses announced to Internet: 436878592 Equivalent to 26 /8s, 10 /16s and 61 /24s Percentage of available RIPE address space announced: 76.6 RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-52223, 196608-197631 RIPE Address Blocks 2/8, 25/8, 31/8, 46/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, 176/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: 30075 Total LACNIC prefixes after maximum aggregation: 7082 LACNIC Deaggregation factor: 4.25 Prefixes being announced from the LACNIC address blocks: 28605 Unique aggregates announced from the LACNIC address blocks: 15336 LACNIC Region origin ASes present in the Internet Routing Table: 1342 LACNIC Prefixes per ASN: 21.32 LACNIC Region origin ASes announcing only one prefix: 417 LACNIC Region transit ASes present in the Internet Routing Table: 235 Average LACNIC Region AS path length visible: 3.9 Max LACNIC Region AS path length visible: 18 Number of LACNIC addresses announced to Internet: 77005696 Equivalent to 4 /8s, 151 /16s and 3 /24s Percentage of available LACNIC address space announced: 57.4 LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 262144-263167 plus ERX transfers LACNIC Address Blocks 177/8, 181/8, 186/8, 187/8, 189/8, 190/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 7421 Total AfriNIC prefixes after maximum aggregation: 1872 AfriNIC Deaggregation factor: 3.96 Prefixes being announced from the AfriNIC address blocks: 5738 Unique aggregates announced from the AfriNIC address blocks: 1658 AfriNIC Region origin ASes present in the Internet Routing Table: 397 AfriNIC Prefixes per ASN: 14.45 AfriNIC Region origin ASes announcing only one prefix: 126 AfriNIC Region transit ASes present in the Internet Routing Table: 89 Average AfriNIC Region AS path length visible: 3.7 Max AfriNIC Region AS path length visible: 14 Number of AfriNIC addresses announced to Internet: 20221952 Equivalent to 1 /8s, 52 /16s and 144 /24s Percentage of available AfriNIC address space announced: 60.3 AfriNIC AS Blocks 36864-37887, 327680-328703 & 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 1866 8412 500 Korea Telecom (KIX) 4755 1483 303 164 TATA Communications formerly 7545 1367 233 82 TPG Internet Pty Ltd 17488 1346 153 128 Hathway IP Over Cable Interne 17974 1206 296 82 PT TELEKOMUNIKASI INDONESIA 24560 1020 303 179 Bharti Airtel Ltd., Telemedia 9583 1017 76 490 Sify Limited 4808 933 1713 260 CNCGROUP IP network: China169 18101 844 95 126 Reliance Infocom Ltd Internet 9829 819 690 35 BSNL National Internet Backbo Complete listing at http://thyme.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 3826 3667 273 bellsouth.net, inc. 4323 2703 1107 392 Time Warner Telecom 19262 1812 4643 282 Verizon Global Networks 1785 1790 698 131 PaeTec Communications, Inc. 20115 1491 1528 651 Charter Communications 7018 1474 5734 951 AT&T WorldNet Services 6478 1332 275 109 AT&T Worldnet Services 2386 1287 554 905 AT&T Data Communications Serv 11492 1189 226 89 Cable One 22773 1181 2858 61 Cox Communications, Inc. Complete listing at http://thyme.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 3292 448 2018 389 TDC Tele Danmark 30890 444 100 212 Evolva Telecom 702 411 1869 324 UUNET - Commercial IP service 8551 403 353 47 Bezeq International 8866 403 117 18 Bulgarian Telecommunication C 3301 374 1416 329 TeliaNet Sweden 3320 372 7328 322 Deutsche Telekom AG 34984 372 90 184 BILISIM TELEKOM 12479 352 576 5 Uni2 Autonomous System 31148 331 17 76 FreeNet ISP 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 1525 3049 245 UniNet S.A. de C.V. 10620 1204 247 148 TVCABLE BOGOTA 28573 1123 863 111 NET Servicos de Comunicao S.A 6503 874 188 272 AVANTEL, S.A. 7303 795 408 102 Telecom Argentina Stet-France 14420 565 36 76 CORPORACION NACIONAL DE TELEC 22047 555 310 15 VTR PUNTO NET S.A. 3816 477 210 94 Empresa Nacional de Telecomun 7738 477 922 30 Telecomunicacoes da Bahia S.A 11172 444 99 76 Servicios Alestra S.A de C.V 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 1149 445 10 TEDATA 24863 725 147 39 LINKdotNET AS number 36992 662 279 177 Etisalat MISR 3741 266 906 224 The Internet Solution 33776 209 12 12 Starcomms Nigeria Limited 6713 203 199 12 Itissalat Al-MAGHRIB 2018 197 277 64 Tertiary Education Network 29571 193 19 11 Ci Telecom Autonomous system 24835 190 78 9 RAYA Telecom - Egypt 16637 150 440 98 MTN Network Solutions 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 3826 3667 273 bellsouth.net, inc. 4323 2703 1107 392 Time Warner Telecom 4766 1866 8412 500 Korea Telecom (KIX) 19262 1812 4643 282 Verizon Global Networks 1785 1790 698 131 PaeTec Communications, Inc. 8151 1525 3049 245 UniNet S.A. de C.V. 20115 1491 1528 651 Charter Communications 4755 1483 303 164 TATA Communications formerly 7018 1474 5734 951 AT&T WorldNet Services 7545 1367 233 82 TPG Internet Pty Ltd Complete listing at http://thyme.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 4323 2703 2311 Time Warner Telecom 1785 1790 1659 PaeTec Communications, Inc. 19262 1812 1530 Verizon Global Networks 4766 1866 1366 Korea Telecom (KIX) 4755 1483 1319 TATA Communications formerly 7545 1367 1285 TPG Internet Pty Ltd 8151 1525 1280 UniNet S.A. de C.V. 6478 1332 1223 AT&T Worldnet Services 17488 1346 1218 Hathway IP Over Cable Interne 8452 1149 1139 TEDATA Complete listing at http://thyme.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 11946 UNALLOCATED 8.12.155.0/24 40913 Quality Technology S 33084 UNALLOCATED 8.15.195.0/24 3356 Level 3 Communicatio 16734 UNALLOCATED 8.18.204.0/24 26914 Global Netoptex, Inc 22015 UNALLOCATED 8.22.137.0/24 14989 Broadview Networks 46856 UNALLOCATED 8.22.184.0/22 3356 Level 3 Communicatio 26169 UNALLOCATED 8.225.177.0/24 20225 TelJet 32249 UNALLOCATED 8.225.178.0/24 3356 Level 3 Communicatio 16927 UNALLOCATED 12.0.252.0/23 7018 AT&T WorldNet Servic 46883 UNALLOCATED 12.4.222.0/24 7018 AT&T WorldNet Servic 15132 UNALLOCATED 12.9.150.0/24 7018 AT&T WorldNet Servic Complete listing at http://thyme.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 31.0.0.0/16 12654 RIPE NCC RIS Project 31.1.0.0/21 12654 RIPE NCC RIS Project 31.1.24.0/24 12654 RIPE NCC RIS Project 41.222.79.0/24 36938 >>UNKNOWN<< 41.223.92.0/22 36936 >>UNKNOWN<< 41.223.189.0/24 6453 Teleglobe Inc. 41.223.196.0/24 36990 Alkan Telecom Ltd 41.223.197.0/24 36990 Alkan Telecom Ltd 41.223.198.0/24 36990 Alkan Telecom Ltd 41.223.199.0/24 36990 Alkan Telecom Ltd 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:25 /11:67 /12:198 /13:414 /14:724 /15:1315 /16:11259 /17:5420 /18:9283 /19:18666 /20:23423 /21:23540 /22:30709 /23:29993 /24:171963 /25:1061 /26:1173 /27:719 /28:116 /29:47 /30:6 /31:0 /32:7 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 6389 2445 3826 bellsouth.net, inc. 4766 1488 1866 Korea Telecom (KIX) 4323 1366 2703 Time Warner Telecom 1785 1253 1790 PaeTec Communications, Inc. 11492 1093 1189 Cable One 10620 1092 1204 TVCABLE BOGOTA 17488 1088 1346 Hathway IP Over Cable Interne 18566 1068 1087 Covad Communications 8452 1040 1149 TEDATA 24560 921 1020 Bharti Airtel Ltd., Telemedia Complete listing at http://thyme.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:60 2:8 4:13 8:303 12:2017 13:8 14:1 15:21 16:3 17:9 20:7 24:1438 27:298 31:1 32:61 33:22 38:692 40:97 41:2519 44:3 46:55 47:16 52:12 55:5 56:2 57:28 58:805 59:504 60:470 61:1078 62:1038 63:1971 64:3734 65:2307 66:3975 67:1870 68:1135 69:2778 70:743 71:372 72:1940 73:2 74:2306 75:275 76:331 77:915 78:635 79:435 80:1016 81:774 82:501 83:438 84:687 85:1040 86:486 87:692 88:318 89:1536 90:96 91:2996 92:426 93:982 94:1166 95:683 96:507 97:218 98:622 99:34 108:64 109:669 110:481 111:570 112:283 113:316 114:450 115:579 116:1101 117:657 118:507 119:884 120:141 121:707 122:1537 123:961 124:1204 125:1244 128:226 129:158 130:170 131:538 132:246 133:17 134:196 135:46 136:221 137:137 138:272 139:105 140:478 141:196 142:343 143:351 144:472 145:53 146:427 147:169 148:677 149:307 150:153 151:233 152:298 153:169 154:3 155:360 156:167 157:332 158:110 159:358 160:313 161:183 162:269 163:167 164:415 165:368 166:468 167:423 168:667 169:157 170:725 171:61 172:2 173:1034 174:476 175:161 176:1 177:1 178:442 180:604 181:1 182:207 183:232 184:153 186:582 187:514 188:799 189:800 190:4020 192:5764 193:4748 194:3429 195:2793 196:1190 198:3575 199:3560 200:5451 201:1590 202:8053 203:8275 204:4011 205:2387 206:2530 207:3068 208:3869 209:3467 210:2547 211:1295 212:1743 213:1667 214:655 215:67 216:4791 217:1581 218:471 219:394 220:1141 221:387 222:313 223:27 End of report From joelja at bogus.com Fri Sep 3 18:42:16 2010 From: joelja at bogus.com (Joel Jaeggli) Date: Fri, 03 Sep 2010 11:42:16 -0700 Subject: just seen my first IPv6 network abuse scan, is this the start for more? In-Reply-To: References: <6AD92173-D423-49E4-81BF-7E141249222B@arbor.net> <3238DBCC-0258-47EA-B804-D8E254492182@delong.com> Message-ID: <4C814188.8040605@bogus.com> On 9/3/10 11:25 AM, Bill Bogstad wrote: > On Fri, Sep 3, 2010 at 9:49 AM, Dobbins, Roland wrote: >> >> On Sep 3, 2010, at 7:58 PM, Owen DeLong wrote: >> >>> However, scanning in IPv6 is not at all like the convenience of comprehensive scanning of the IPv4 address space. >> >> >> Concur, but I still maintain that lots of illicit automation plus refined scanning via DNS, et. al. is a viable practice. > > These are very big numbers, so I don't see how. Consider you have a dual stack deployment. what are the most likely ipv6 numbering schemes you're likely to use to number hosts. If I query one of your hosts in the forward zone and get back and a and a aaaa record what can I likely conclude about the numbering scheme for that net? joelja-mac:~ joelja$ host ns3.xxxxxx.net ns3.xxx.net has address xxxx.xxx.0.81 ns3.xxx.net has IPv6 address xxxx:xxx:1::81 if you do stateful dhcp v6 assignment what are the likely constraints as to the size of the pool you're going to use for that subnet. This is like brute force password guessing... there's some high probability answers that are low hanging fruit you reach for them, they don't exist you move on. > If you use easy to guess/remember host/service names and put them > in public DNS then those IP addresses are in some sense already public > (whether IPv4 or IPv6). The definition of "easy to guess" is pretty > much everything which has ever been used in a wordlist for password > cracking programs (plus the code which generates variants of same). > Real attackers are going to flood > your DNS servers, not do brute force IPv6 ICMP scans. Even a pure > brute force DNS scan of all 10 character long hostnames (asuming > a-z0-9) is going to take around 5000 times fewer queries then a full > ICMP v6 scan of a /64. (Which at an attack speed of 1000pps is still > going to take around 100,000 years.) > > For machines which you want to make it REALLY hard to find, but > need publicly accessible addresses, you shouldn't put them in publicly > queryable DNS servers at all and use a random number generator to > generate their static IPv6 addresses. Even if you put a thousand of > these machines in a single subnet, it is going to take half a million > years at reasonable packet rates before even one of them is > discovered. > > Hmm, thinking about it in terms of passwords might help. Many > people consider a totally random 10 character monocase+numbers > password to be reasonably secure against brute force attacks. ICMP > scanning a /64 is thousands of times more difficult and all it gives > you is the existence of the machine. Even if you find that needle in > a hay stack , you don't get access to its resources. > > I took a quick look at the paper that SMB linked to and I would > argue that for wide area attacks, packet sniffing is going to be how > people find your "hidden" addresses. Compromising SMB wi-fi hotspot > hardware and logging every address accessed is one possibility. Or > just compromise people's laptops and have them run network sniffers > which generate "seen" address lists which are forwarded to dummy gmail > accounts. > > Bill Bogstad > From james at freedomnet.co.nz Fri Sep 3 19:02:43 2010 From: james at freedomnet.co.nz (James Jones) Date: Fri, 03 Sep 2010 15:02:43 -0400 Subject: verizon outage In-Reply-To: References: <4C8127AA.5090507@freedomnet.co.nz> Message-ID: <4C814653.9030305@freedomnet.co.nz> Found out its related to the outage in NJ On 3/09/10 1:12 PM, Christopher Morrow wrote: > On Fri, Sep 3, 2010 at 12:51 PM, James Jones wrote: >> anyone experiencing issues with verizon in western mass? > o this isn't the outages list, that one MAY have more info for you > o there are many verizons... which one are you talking about? > (wireless, dsl/fios, fUUNET, private-line services, private-network > services...) > > -Chris From tony.li at tony.li Fri Sep 3 19:36:36 2010 From: tony.li at tony.li (Tony Li) Date: Fri, 3 Sep 2010 12:36:36 -0700 Subject: eBGP Multihop In-Reply-To: <4C7F6E9A.6070203@apolix.co.za> References: <4C7F6E9A.6070203@apolix.co.za> Message-ID: <4D085AA9-DDD6-430F-A494-0186E31602D1@tony.li> On Sep 2, 2010, at 2:30 AM, Graham Beneke wrote: > I have been asked to investigate moving an entire network to multi-hop on all the eBGP sessions. Basically all upstreams, downstreams and peers will eBGP with a route reflector located in the core. This RR will be some kind of quagga or similar box. The dev guys want to be able to poke at the BGP feeds directly and do *magic* that standard router aren't capable of. > > My gut feel is that this is a bad idea. Besides anything else it makes sane link state detection very challenging - especially where we have multiple sessions with a peer. > > Is their any BCP or operational experience that agrees or disagrees with my gut. ;-) Multihop eBGP is a debugging tool that a developer left in the production code. Tony From rdobbins at arbor.net Fri Sep 3 19:41:54 2010 From: rdobbins at arbor.net (Dobbins, Roland) Date: Fri, 3 Sep 2010 19:41:54 +0000 Subject: just seen my first IPv6 network abuse scan, is this the start for more? In-Reply-To: <6A6F346A-2AA6-47E4-92D2-967627CE1202@cs.columbia.edu> References: <6AD92173-D423-49E4-81BF-7E141249222B@arbor.net> <3238DBCC-0258-47EA-B804-D8E254492182@delong.com> <6A6F346A-2AA6-47E4-92D2-967627CE1202@cs.columbia.edu> Message-ID: On Sep 4, 2010, at 12:19 AM, Steven Bellovin wrote: > See http://www.cs.columbia.edu/~smb/papers/v6worms.pdf I've seen it and concur with regards to worms (which don't seem to be very popular, right now, excepting the 'background radiation' of old Code Red, Nimda, Blaster, Nachi, SQL Slammer, et. al. hosts). I believe that hinted scanning is still viable, and I'd argue that the experience of the OP who kicked off this thread is an indication of same. ----------------------------------------------------------------------- Roland Dobbins // Sell your computer and buy a guitar. From rdobbins at arbor.net Fri Sep 3 20:11:49 2010 From: rdobbins at arbor.net (Dobbins, Roland) Date: Fri, 3 Sep 2010 20:11:49 +0000 Subject: ISP port blocking practice In-Reply-To: References: <0A08271D-49B9-4382-9F54-1A0BB6A3F2B2@umich.edu> <13222.1256232797@turing-police.cc.vt.edu> <3A97A2BA-C9FE-4554-908D-AD3986CC3E1B@senie.com> Message-ID: <9A93BDB8-6513-49A2-9ADF-35959E1836B3@arbor.net> On Sep 3, 2010, at 10:23 PM, William Herrin wrote: > Frankly, Zhiyun offers the first truly rational case I've personally seen for packet filtering based on the TCP source port. While the paper is entertaining and novel, and reflects a lot of creativity and hard work on the part of the research team, it's doubtful that any serious spammer has ever sent spam this way. I've certainly never run across it, nor do I know anyone else who has done so. The lack of citations of documented cases in the footnotes, or indeed any projections or discussion of the postulated commonality of this technique tends to support the above view, IMHO. Spammers typically do business with botmasters, and those botmasters have thousands/tens of thousands/hundreds of thousands/millions of bots at their disposal. The supposed economies of scale achieved by 'triangular spamming' (a better name would be something like 'bifurcated false-flag proxying', as spamming is just a use-case of the more generalized, though esoteric technique described in the paper) are far outweighed by its operational complexity and the sheer volume of botnets available to pump out spam 24/7. The supposed performance benefits described in the paper are likely considerably exaggerated, given the RTT and resultant latency of the return traffic via the remote proxy half. The sheer economies of scale offered by conventional botnets greatly outweigh the benefits and caveats of the described technique. The use of routers cracked via credential brute-forcing (no iACLs, no vty ACLs, no AAA, 'cisco/cisco') and configured with GRE tunnels and NAT, sometimes in conjunction with prefix-hijacking, is a more commonly-used spamming technique than that described in the paper. There are a lot of really smart people engaged in all kinds of security-related research, and it's encouraging to see such talented folks thinking outside of the box. In future, vetting of postulated scenarios with the operational community prior to embarking upon lengthy, resource-intensive research projects may be one way to ensure that subsequent efforts are even more tightly focused on more proximate threats, and can also help reduce the continued citation of canards such as attempts to overload such opaque, arbitrary, and unreliable metrics as TTL with more significance than they actually warrant. ----------------------------------------------------------------------- Roland Dobbins // Sell your computer and buy a guitar. From deepak at ai.net Fri Sep 3 20:33:23 2010 From: deepak at ai.net (Deepak Jain) Date: Fri, 3 Sep 2010 16:33:23 -0400 Subject: just seen my first IPv6 network abuse scan, is this the start for more? In-Reply-To: <3238DBCC-0258-47EA-B804-D8E254492182@delong.com> References: <6AD92173-D423-49E4-81BF-7E141249222B@arbor.net> <3238DBCC-0258-47EA-B804-D8E254492182@delong.com> Message-ID: > > Plus, setting bots to go scan isn't very labor-intensive. All the > talk about how scanning isn't viable in IPv6-land due to large > netblocks doesn't take into account the benefits of illicit automation. > > > Uh... He mentioned 1000 addresses/second... At that rate, scanning a > /64 will take more than > 18,000,000,000,000,000 seconds. Converted to hours, that's > 5,000,000,000,000 hours which > works out to 208,333,333,333 days or roughly 570,776,255 years. > > If you want to scan a single IPv6 subnet completely in 1 year, you will > need to automate > 570,776,255 machines scanning at 1000 ip addresses per second, and, > your target network > will need to be able to process 570,776,255,000 packets per second. > > Yes, you can do a certain amount of table-overflow DOS with an IPv6 > scan, but, you really > can't accomplish much else in practical terms. > Since I mentioned a thread about technology prognostication... Right now 1000 pps per host seems like a number that is on the high end of what could go reasonably unnoticed by a comprised bot-machine. I'm sure if we roll back our clocks to IPv4's origination we'd have never imagined 1000pps scans. If history is any judge, the technology will grow faster and farther than we can see from here. Designers will put stupid kludges in their code [because the space is so vast] like picking Fibonacci numbers as "unique" inside of large sections of space -- who knows. The point is that while every smart person thinks this is a lot of space for current attack technology, in some period of time, it may not seem to difficult and safe to hide in. Moreover, when every enterprise has a /48 or better, network admins are going to need to be able to track down machines/devices/ear pieces/what have you on a better basis then trapping them when they speak up. There is a huge potential for sleepers in IPv6 space that we don't see any more in IPv4 (because the tools are better). Eventually someone will find an approach to do this kind of surveying and then make it cheap enough everyone can do it. (how often do security-admins use NMAP/Nessus/what have you to survey their own space -- an IPv6 analog will *need* to be created eventually). Just my thoughts, Deepak From bicknell at ufp.org Fri Sep 3 20:49:51 2010 From: bicknell at ufp.org (Leo Bicknell) Date: Fri, 3 Sep 2010 13:49:51 -0700 Subject: just seen my first IPv6 network abuse scan, is this the start for more? In-Reply-To: References: <6AD92173-D423-49E4-81BF-7E141249222B@arbor.net> <3238DBCC-0258-47EA-B804-D8E254492182@delong.com> Message-ID: <20100903204951.GA3603@ussenterprise.ufp.org> In a message written on Fri, Sep 03, 2010 at 04:33:23PM -0400, Deepak Jain wrote: > Moreover, when every enterprise has a /48 or better, network admins are going to need to be able to track down machines/devices/ear pieces/what have you on a better basis then trapping them when they speak up. There is a huge potential for sleepers in IPv6 space that we don't see any more in IPv4 (because the tools are better). Eventually someone will find an approach to do this kind of surveying and then make it cheap enough everyone can do it. (how often do security-admins use NMAP/Nessus/what have you to survey their own space -- an IPv6 analog will *need* to be created eventually). If you are the network admin, walking the L2 devices MAC tables and comparing with the L3 devices ARP/ND/whatever tables is likely more efficient for sparse address space. Also keep in mind, IPv6 devices will often have multiple addresses, and may move addresses quite regularly. For instance, I use "privacy" or "temporary" addresses, my machine hops to a new IPv6 address every 10 minutes. A scan will likely be out of date before it completes for these sorts of addresses. -- 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: 826 bytes Desc: not available URL: From rdobbins at arbor.net Fri Sep 3 20:52:08 2010 From: rdobbins at arbor.net (Dobbins, Roland) Date: Fri, 3 Sep 2010 20:52:08 +0000 Subject: ISP port blocking practice In-Reply-To: <9A93BDB8-6513-49A2-9ADF-35959E1836B3@arbor.net> References: <0A08271D-49B9-4382-9F54-1A0BB6A3F2B2@umich.edu> <13222.1256232797@turing-police.cc.vt.edu> <3A97A2BA-C9FE-4554-908D-AD3986CC3E1B@senie.com> <9A93BDB8-6513-49A2-9ADF-35959E1836B3@arbor.net> Message-ID: On Sep 4, 2010, at 3:11 AM, Dobbins, Roland wrote: > I've certainly never run across it, nor do I know anyone else who has done so. I stand corrected - it seems I do in fact know someone who's observed this technique used to send spam, albeit in the past when POTS dial-up pools were the de facto access method for the masses and before the technical and commercial maturity of the botnet business model. I still maintain that even if it's being used today, it's rare, and essentially a corner-case. This isn't meant to detract from the novelty and creativity of the paper in question, but rather to posit the view that it isn't necessarily something for operators to get too worked up about, in the scheme of things. ----------------------------------------------------------------------- Roland Dobbins // Sell your computer and buy a guitar. From rdobbins at arbor.net Fri Sep 3 21:07:49 2010 From: rdobbins at arbor.net (Dobbins, Roland) Date: Fri, 3 Sep 2010 21:07:49 +0000 Subject: ISP port blocking practice In-Reply-To: <782DAE51-C0F1-453B-8FEA-96754B6347E2@ianai.net> References: <14226076.567.1283492502703.JavaMail.franck@franck-martins-macbook-pro.local> <782DAE51-C0F1-453B-8FEA-96754B6347E2@ianai.net> Message-ID: <86F2C53A-7A3C-412A-9798-D87A28F9EAB4@arbor.net> On Sep 3, 2010, at 8:02 PM, Patrick W. Gilmore wrote: > Could you point to more than one instance? I've not yet found one. I've yet to run across this, either, FWIW, except on extremely restrictive special-purpose endpoint networks. Doesn't mean that it doesn't happen, but it doesn't seem to be nearly as prevalent as TCP/25 blockage on general SP access networks. ----------------------------------------------------------------------- Roland Dobbins // Sell your computer and buy a guitar. From iain.t.morris at gmail.com Fri Sep 3 21:20:08 2010 From: iain.t.morris at gmail.com (Iain Morris) Date: Fri, 3 Sep 2010 14:20:08 -0700 Subject: Juniper to Watchguard IPSEC In-Reply-To: References: Message-ID: On Fri, Sep 3, 2010 at 10:03 AM, Welch, Bryan wrote: > Anyone have any experience with IPSEC between a WG Firebox and Juniper > SRX/SSG? Running into some problems and beginning to think there might be > some incompatibilities in their IPSEC options. > > Not WG but I had trouble getting a SSG to talk to a Cisco until I realized > the SSG (ScreenOS) has to have a proxy-id defined, which the Cisco required > to complete the SA. But perhaps you're using Junos on your SSGs if you're > talking SRX as well. -Iain From cidr-report at potaroo.net Fri Sep 3 22:00:04 2010 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 3 Sep 2010 22:00:04 GMT Subject: BGP Update Report Message-ID: <201009032200.o83M04a2073005@wattle.apnic.net> BGP Update Report Interval: 26-Aug-10 -to- 02-Sep-10 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS5416 81217 2.6% 588.5 -- BATELCO-BH 2 - AS35567 62345 2.0% 593.8 -- DASTO-BOSNIA-AS DASTO semtel d.o.o. 3 - AS4323 29881 0.9% 6.7 -- TWTC - tw telecom holdings, inc. 4 - AS6389 25846 0.8% 6.7 -- BELLSOUTH-NET-BLK - BellSouth.net Inc. 5 - AS8151 23885 0.8% 15.6 -- Uninet S.A. de C.V. 6 - AS13880 22045 0.7% 1296.8 -- ACI-AS - american century investments 7 - AS3464 21519 0.7% 489.1 -- ASC-NET - Alabama Supercomputer Network 8 - AS9829 20014 0.6% 24.4 -- BSNL-NIB National Internet Backbone 9 - AS11492 19618 0.6% 15.6 -- CABLEONE - CABLE ONE, INC. 10 - AS32528 17018 0.5% 2127.2 -- ABBOTT Abbot Labs 11 - AS5536 16586 0.5% 144.2 -- Internet-Egypt 12 - AS6478 16075 0.5% 12.1 -- ATT-INTERNET3 - AT&T WorldNet Services 13 - AS14522 14555 0.5% 40.7 -- Satnet 14 - AS20115 14243 0.5% 9.5 -- CHARTER-NET-HKY-NC - Charter Communications 15 - AS19262 14193 0.5% 7.9 -- VZGNI-TRANSIT - Verizon Online LLC 16 - AS35931 14096 0.4% 2349.3 -- ARCHIPELAGO - ARCHIPELAGO HOLDINGS INC 17 - AS17974 13648 0.4% 11.1 -- TELKOMNET-AS2-AP PT Telekomunikasi Indonesia 18 - AS1785 13061 0.4% 7.3 -- AS-PAETEC-NET - PaeTec Communications, Inc. 19 - AS7552 13044 0.4% 19.8 -- VIETEL-AS-AP Vietel Corporation 20 - AS6503 12730 0.4% 14.8 -- Axtel, S.A.B. de C. V. TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS35931 14096 0.4% 2349.3 -- ARCHIPELAGO - ARCHIPELAGO HOLDINGS INC 2 - AS32528 17018 0.5% 2127.2 -- ABBOTT Abbot Labs 3 - AS13880 22045 0.7% 1296.8 -- ACI-AS - american century investments 4 - AS11613 830 0.0% 830.0 -- U-SAVE - U-Save Auto Rental of America, Inc. 5 - AS21017 7301 0.2% 730.1 -- VSI-AS VSI AS 6 - AS15984 729 0.0% 729.0 -- The Joint-Stock Commercial Bank CentroCredit. 7 - AS36129 1367 0.0% 683.5 -- YAHOO-MAVEN - Yahoo 8 - AS27245 1310 0.0% 655.0 -- HEIDRICK-CHICAGO - HEIDRICK 9 - AS50441 610 0.0% 610.0 -- KVNO-AS Kassenaerztliche Vereinigung Nordrhein 10 - AS51211 605 0.0% 605.0 -- ZHIGULI-TELECOM-AS LTD "Zhiguli-Telecom" 11 - AS35567 62345 2.0% 593.8 -- DASTO-BOSNIA-AS DASTO semtel d.o.o. 12 - AS5416 81217 2.6% 588.5 -- BATELCO-BH 13 - AS16861 562 0.0% 562.0 -- REVELEX - Revelex.com 14 - AS3464 21519 0.7% 489.1 -- ASC-NET - Alabama Supercomputer Network 15 - AS41759 874 0.0% 437.0 -- FRYITUK FRY-IT UK As Number 16 - AS27027 715 0.0% 357.5 -- ANBELL ASN-ANBELL 17 - AS37204 3278 0.1% 327.8 -- TELONE 18 - AS50150 288 0.0% 288.0 -- LONGLINE-AS LongLine SRL 19 - AS2 275 0.0% 177.0 -- UPOU-LB-AS-AP University of the Philippines - Open University Los Banos Campus 20 - AS16718 7276 0.2% 259.9 -- EMBARQ-HMBL - Embarq Corporation TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 129.66.128.0/17 10541 0.3% AS3464 -- ASC-NET - Alabama Supercomputer Network 2 - 129.66.0.0/17 10536 0.3% AS3464 -- ASC-NET - Alabama Supercomputer Network 3 - 130.36.35.0/24 8476 0.2% AS32528 -- ABBOTT Abbot Labs 4 - 130.36.34.0/24 8475 0.2% AS32528 -- ABBOTT Abbot Labs 5 - 63.211.68.0/22 8183 0.2% AS35931 -- ARCHIPELAGO - ARCHIPELAGO HOLDINGS INC 6 - 213.196.79.0/24 7228 0.2% AS35567 -- DASTO-BOSNIA-AS DASTO semtel d.o.o. 7 - 213.196.72.0/24 7226 0.2% AS35567 -- DASTO-BOSNIA-AS DASTO semtel d.o.o. 8 - 213.196.77.0/24 7226 0.2% AS35567 -- DASTO-BOSNIA-AS DASTO semtel d.o.o. 9 - 213.196.75.0/24 7226 0.2% AS35567 -- DASTO-BOSNIA-AS DASTO semtel d.o.o. 10 - 213.196.74.0/24 7226 0.2% AS35567 -- DASTO-BOSNIA-AS DASTO semtel d.o.o. 11 - 213.196.76.0/24 7226 0.2% AS35567 -- DASTO-BOSNIA-AS DASTO semtel d.o.o. 12 - 213.196.78.0/24 7226 0.2% AS35567 -- DASTO-BOSNIA-AS DASTO semtel d.o.o. 13 - 213.196.73.0/24 7226 0.2% AS35567 -- DASTO-BOSNIA-AS DASTO semtel d.o.o. 14 - 148.204.141.0/24 7092 0.2% AS8151 -- Uninet S.A. de C.V. 15 - 198.140.43.0/24 5834 0.2% AS35931 -- ARCHIPELAGO - ARCHIPELAGO HOLDINGS INC 16 - 190.65.228.0/22 5480 0.1% AS3816 -- COLOMBIA TELECOMUNICACIONES S.A. ESP 17 - 77.69.148.0/24 4329 0.1% AS5416 -- BATELCO-BH 18 - 77.69.141.0/24 4329 0.1% AS5416 -- BATELCO-BH 19 - 77.69.160.0/19 4329 0.1% AS5416 -- BATELCO-BH 20 - 77.69.145.0/24 4329 0.1% AS5416 -- BATELCO-BH 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 Sep 3 22:00:00 2010 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 3 Sep 2010 22:00:00 GMT Subject: The Cidr Report Message-ID: <201009032200.o83M00MM072985@wattle.apnic.net> This report has been generated at Fri Sep 3 21:11:43 2010 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 27-08-10 333965 206952 28-08-10 335080 207017 29-08-10 335271 207124 30-08-10 335262 204429 31-08-10 335183 207029 01-09-10 335387 206535 02-09-10 335293 206645 03-09-10 335608 206587 AS Summary 35292 Number of ASes in routing system 15028 Number of ASes announcing only one prefix 4451 Largest number of prefixes announced by an AS AS4323 : TWTC - tw telecom holdings, inc. 97246976 Largest address span announced by an AS (/32s) AS4134 : CHINANET-BACKBONE No.31,Jin-rong Street 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'). --- 03Sep10 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 335536 206530 129006 38.4% All ASes AS6389 3824 278 3546 92.7% BELLSOUTH-NET-BLK - BellSouth.net Inc. AS4323 4451 1906 2545 57.2% TWTC - tw telecom holdings, inc. AS19262 1814 284 1530 84.3% VZGNI-TRANSIT - Verizon Online LLC AS4766 1866 514 1352 72.5% KIXS-AS-KR Korea Telecom AS13343 1682 528 1154 68.6% SCRR-13343 - Road Runner HoldCo LLC AS22773 1181 66 1115 94.4% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. AS4755 1483 428 1055 71.1% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP AS17488 1346 302 1044 77.6% HATHWAY-NET-AP Hathway IP Over Cable Internet AS5668 1134 91 1043 92.0% AS-5668 - CenturyTel Internet Holdings, Inc. AS18566 1087 63 1024 94.2% COVAD - Covad Communications Co. AS6478 1332 387 945 70.9% ATT-INTERNET3 - AT&T WorldNet Services AS8151 1526 625 901 59.0% Uninet S.A. de C.V. AS10620 1204 323 881 73.2% Telmex Colombia S.A. AS1785 1790 957 833 46.5% AS-PAETEC-NET - PaeTec Communications, Inc. AS8452 1150 408 742 64.5% TEDATA TEDATA AS7545 1384 696 688 49.7% TPG-INTERNET-AP TPG Internet Pty Ltd AS7303 796 115 681 85.6% Telecom Argentina S.A. AS4808 933 302 631 67.6% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network AS4804 678 73 605 89.2% MPX-AS Microplex PTY LTD AS28573 1123 578 545 48.5% NET Servicos de Comunicao S.A. AS7552 653 121 532 81.5% VIETEL-AS-AP Vietel Corporation AS17676 605 77 528 87.3% GIGAINFRA Softbank BB Corp. AS4780 685 161 524 76.5% SEEDNET Digital United Inc. AS7018 1474 953 521 35.3% ATT-INTERNET4 - AT&T WorldNet Services AS18101 844 323 521 61.7% RIL-IDC Reliance Infocom Ltd Internet Data Centre, AS7011 1155 666 489 42.3% FRONTIER-AND-CITIZENS - Frontier Communications of America, Inc. AS14420 568 87 481 84.7% CORPORACION NACIONAL DE TELECOMUNICACIONES - CNT EP AS22047 555 81 474 85.4% VTR BANDA ANCHA S.A. AS24560 1020 548 472 46.3% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services AS3356 1141 676 465 40.8% LEVEL3 Level 3 Communications Total 40484 12617 27867 68.8% Top 30 total Possible Bogus Routes 31.0.0.0/16 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 31.1.0.0/21 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 31.1.24.0/24 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 41.222.79.0/24 AS36938 AMSCOTELECOMS Amsco Telecommunications Nigeria Limited 41.223.92.0/22 AS36936 CELTEL-GABON Celtel Gabon Internet Service 41.223.189.0/24 AS6453 GLOBEINTERNET TATA Communications 41.223.196.0/24 AS36990 41.223.197.0/24 AS36990 41.223.198.0/24 AS36990 41.223.199.0/24 AS36990 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV 62.61.221.0/24 AS24974 TACHYON-EU Tachyon Europe BV 64.20.80.0/20 AS40028 SPD-NETWORK-1 - SPD NETWORK 64.21.192.0/20 AS11610 INETNEBR-1 - Internet Nebraska Corporation 64.21.212.0/22 AS11610 INETNEBR-1 - Internet Nebraska Corporation 64.21.216.0/21 AS11610 INETNEBR-1 - Internet Nebraska Corporation 64.82.128.0/19 AS16617 COMMUNITYISP - CISP 64.82.160.0/19 AS16617 COMMUNITYISP - CISP 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.47.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 66.207.32.0/20 AS23011 66.230.240.0/20 AS27286 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 71.19.134.0/23 AS3313 INET-AS I.NET S.p.A. 71.19.160.0/23 AS4648 NZIX-2 Netgate 72.22.32.0/19 AS33150 72.22.61.0/24 AS33150 72.22.62.0/24 AS33150 76.77.32.0/19 AS2828 XO-AS15 - XO Communications 79.124.96.0/19 AS44124 RYBNET-AS Rybnet Sp. z o.o. Sp. k. 80.88.10.0/24 AS33774 DJAWEB 80.88.12.0/24 AS33779 wataniya-telecom-as 91.217.191.0/24 AS39700 SERVERIUS-AS Serverius AS 96.45.160.0/24 AS3257 TINET-BACKBONE Tinet SpA 96.45.161.0/24 AS3257 TINET-BACKBONE Tinet SpA 96.45.162.0/24 AS3257 TINET-BACKBONE Tinet SpA 96.45.163.0/24 AS3257 TINET-BACKBONE Tinet SpA 96.45.164.0/24 AS3257 TINET-BACKBONE Tinet SpA 96.45.165.0/24 AS3257 TINET-BACKBONE Tinet SpA 96.45.166.0/24 AS3257 TINET-BACKBONE Tinet SpA 96.45.167.0/24 AS3257 TINET-BACKBONE Tinet SpA 96.45.168.0/21 AS3257 TINET-BACKBONE Tinet SpA 96.47.48.0/20 AS3257 TINET-BACKBONE Tinet SpA 101.0.0.0/8 AS38639 HANABI NTT Communications Corporation 110.34.44.0/22 AS12653 COMTONET KB Impuls Hellas 110.173.64.0/19 AS37963 CNNIC-ALIBABA-CN-NET-AP Alibaba (China) Technology Co., Ltd. 116.68.136.0/21 AS28045 Pantel Communications 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.168.0/21 AS9931 CAT-AP The Communication Authoity of Thailand, CAT 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 173.225.112.0/20 AS3257 TINET-BACKBONE Tinet SpA 176.0.0.0/16 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 176.1.0.0/21 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 176.1.24.0/24 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 177.0.0.0/16 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 177.1.0.0/21 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 177.1.8.0/24 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 181.0.0.0/16 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 181.1.0.0/21 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 181.1.8.0/24 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 190.102.32.0/20 AS30058 ACTIVO-SYSTEMS-AS30058 ACTIVO-SYSTEMS-AS30058 192.9.0.0/16 AS11479 BRM-SUN-AS - Sun Microsystems, Inc 192.64.85.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.69.108.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.101.46.0/24 AS6503 Axtel, S.A.B. de C. V. 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.252.0/22 AS680 DFN-IP service X-WiN 192.131.233.0/24 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 192.154.32.0/19 AS81 NCREN - MCNC 192.154.64.0/19 AS81 NCREN - MCNC 192.188.208.0/20 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 196.2.224.0/22 AS24863 LINKdotNET-AS 196.6.108.0/24 AS5713 SAIX-NET 196.13.201.0/24 AS2018 TENET-1 196.13.202.0/24 AS2018 TENET-1 196.13.203.0/24 AS2018 TENET-1 196.13.204.0/24 AS2018 TENET-1 196.110.105.0/24 AS8513 SKYVISION SkyVision Network Services 196.201.248.0/24 AS30991 SAHANNET Sahannet AS Network 196.201.249.0/24 AS30991 SAHANNET Sahannet AS Network 196.201.250.0/24 AS30991 SAHANNET Sahannet AS Network 196.201.251.0/24 AS30991 SAHANNET Sahannet AS Network 196.201.253.0/24 AS30991 SAHANNET Sahannet AS Network 196.201.255.0/24 AS30991 SAHANNET Sahannet AS Network 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.51.100.0/24 AS16953 ASCENT-MEDIA-GROUP-LLC - Ascent Media Group, LLC 198.73.210.0/24 AS21570 ACI-1 - Accelerated Connections Inc. 198.74.38.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services 198.74.39.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services 198.74.40.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services 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.99.241.0/24 AS11797 AC-NIELSEN-AS AC NIELSEN 198.135.236.0/24 AS4358 XNET - XNet Information Systems, Inc. 198.161.87.0/24 AS6539 GT-BELL - Bell Canada 198.163.214.0/24 AS21804 ACCESS-SK - Access Communications Co-operative Limited 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 198.182.235.0/24 AS3356 LEVEL3 Level 3 Communications 199.10.0.0/16 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center 199.16.32.0/19 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 199.121.0.0/16 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.123.16.0/20 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.185.130.0/23 AS19662 UNISERVE-ONLINE - Uniserve On Line 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.24.73.0/24 AS26061 Equant Colombia 200.24.78.0/26 AS3549 GBLX Global Crossing Ltd. 200.24.78.64/26 AS3549 GBLX Global Crossing Ltd. 202.9.55.0/24 AS2764 AAPT AAPT Limited 202.9.57.0/24 AS2764 AAPT AAPT Limited 202.38.63.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.58.113.0/24 AS19161 202.61.75.0/24 AS9927 PHILCOMNET-PH A Multihomed ISP Company 202.66.128.0/18 AS9584 GENESIS-AP Diyixian.com Limited 202.66.160.0/19 AS9584 GENESIS-AP Diyixian.com Limited 202.66.160.0/20 AS9584 GENESIS-AP Diyixian.com Limited 202.66.176.0/20 AS9584 GENESIS-AP Diyixian.com Limited 202.66.184.0/24 AS9584 GENESIS-AP Diyixian.com Limited 202.66.186.0/24 AS9584 GENESIS-AP Diyixian.com Limited 202.66.188.0/24 AS9584 GENESIS-AP Diyixian.com Limited 202.66.189.0/24 AS9584 GENESIS-AP Diyixian.com Limited 202.66.190.0/24 AS9584 GENESIS-AP Diyixian.com Limited 202.73.144.0/20 AS4788 TMNET-AS-AP TM Net, Internet Service Provider 202.80.192.0/20 AS2706 PI-HK Pacnet Internet (Hong Kong) Limited 202.86.252.0/22 AS4748 RESOLINK-AS-AP Resources Link Network Limited 202.86.252.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.253.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.254.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.255.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.133.37.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.150.227.0/24 AS17727 NAPINFO-AS-AP PT. NAP Info Lintas Nusa 202.174.70.0/24 AS21175 WIS WIS S.A. : WIND International Services 202.174.125.0/24 AS9498 BBIL-AP BHARTI Airtel Ltd. 202.176.1.0/24 AS9942 COMINDICO-AP SOUL Converged Communications Australia 202.179.130.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.179.131.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.179.133.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.179.134.0/24 AS23966 LDN-AS-PK LINKdotNET Telecom Limited 202.179.144.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.179.149.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.179.150.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 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.99.140.0/24 AS45227 VISTA-SKYDIO-PTE-LTD-AP Vista datacenter Skydio Pte Ltd 203.99.141.0/24 AS45227 VISTA-SKYDIO-PTE-LTD-AP Vista datacenter Skydio Pte 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.175.98.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 203.175.99.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 203.175.103.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 203.175.107.0/24 AS45595 PKTELECOM-AS-PK Pakistan Telecom Company Limited 203.175.110.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 203.202.238.0/24 AS45227 VISTA-SKYDIO-PTE-LTD-AP Vista datacenter Skydio Pte Ltd 204.9.216.0/23 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 204.10.232.0/21 AS33150 204.19.14.0/23 AS577 BACOM - Bell Canada 204.28.104.0/21 AS25973 MZIMA - Mzima Networks, Inc. 204.197.0.0/16 AS3356 LEVEL3 Level 3 Communications 204.209.114.0/24 AS13768 PEER1 - Peer 1 Network Inc. 204.238.70.0/24 AS36826 205.150.0.0/15 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 205.189.134.0/24 AS11814 DISTRIBUTEL-AS11814 - DISTRIBUTEL COMMUNICATIONS LTD. 205.196.24.0/22 AS33724 BIZNESSHOSTING - VOLICO 205.210.145.0/24 AS11814 DISTRIBUTEL-AS11814 - DISTRIBUTEL COMMUNICATIONS LTD. 206.72.192.0/23 AS27375 IDS-TELECOM - IDS Telecom 206.72.194.0/23 AS27375 IDS-TELECOM - IDS Telecom 206.72.209.0/24 AS16526 BIRCH-TELECOM - Birch Telecom, Inc. 206.123.129.0/24 AS10790 INREACH-AS - InReach Internet 206.180.240.0/20 AS12083 KNOLOGY-NET - Knology Holdings 206.197.184.0/24 AS23304 DATOTEL-STL-AS - Datotel LLC, a NetLabs LLC Company 207.174.131.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.132.0/23 AS26116 INDRA - Indra's Net Inc. 207.174.152.0/23 AS26116 INDRA - Indra's Net Inc. 207.174.154.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.155.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.188.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.189.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.190.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.191.0/24 AS26116 INDRA - Indra's Net Inc. 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.64.200.0/22 AS11730 CIL-ASN - Circle Internet LTD 208.64.240.0/21 AS13871 TELEBYTE-NW - Telebyte NW 208.73.4.0/22 AS27630 PREMIER - Premier Innovations, LLC 208.78.164.0/24 AS16565 208.78.165.0/24 AS16565 208.78.167.0/24 AS16565 208.84.76.0/22 AS18561 208.92.196.0/22 AS10929 NETELLIGENT - Netelligent Hosting Services Inc. 208.92.199.0/24 AS26198 3MENATWORK - 3Men at Work Integrated Networks, Inc. 209.54.123.0/24 AS6062 NETPLEX - NETPLEX 209.105.224.0/19 AS20074 209.165.239.0/24 AS209 ASN-QWEST - Qwest Communications Company, LLC 209.213.0.0/20 AS33005 ELTOPIA - Eltopia.com, LLC 209.213.1.0/24 AS7849 CROCKERCOM - CROCKER COMMUNICATIONS 209.213.4.0/24 AS7849 CROCKERCOM - CROCKER COMMUNICATIONS 209.236.96.0/20 AS3257 TINET-BACKBONE Tinet SpA 210.5.128.0/20 AS4837 CHINA169-BACKBONE CNCGROUP China169 Backbone 210.56.150.0/23 AS38138 INTECH-TRANSIT-BD InTech Online Limited, INTERNET SERVICE LIMITED 210.247.224.0/19 AS7496 WEBCENTRAL-AS WebCentral 216.10.235.0/24 AS13780 NTNCOMMUNICATIONS - NTN 216.10.236.0/24 AS13780 NTNCOMMUNICATIONS - NTN 216.21.196.0/24 AS12251 INVISION - Invision.com, Inc. 216.21.201.0/24 AS12251 INVISION - Invision.com, Inc. 216.21.202.0/24 AS12251 INVISION - Invision.com, Inc. 216.21.206.0/23 AS12251 INVISION - Invision.com, Inc. 216.47.32.0/20 AS3257 TINET-BACKBONE Tinet SpA 216.58.192.0/24 AS22702 X5SOLUTIONS - X5 Solutions, Inc. 216.58.197.0/24 AS22702 X5SOLUTIONS - X5 Solutions, Inc. 216.58.200.0/24 AS18530 ISOMEDIA-1 - Isomedia 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.250.112.0/20 AS7296 ALCHEMYNET - Alchemy Communications, Inc. 216.250.116.0/24 AS36066 UNI-MARKETING-ALLIANCE - Webhost4life.com 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 johnl at iecc.com Fri Sep 3 22:19:47 2010 From: johnl at iecc.com (John R. Levine) Date: 4 Sep 2010 00:19:47 +0200 Subject: ISP port blocking practice In-Reply-To: <918D3F33-E46F-40F0-9325-FAE4AE5E0D05@delong.com> References: <20100903124008.72241.qmail@joyce.lan> <918D3F33-E46F-40F0-9325-FAE4AE5E0D05@delong.com> Message-ID: >> It's been extremely effective in blocking spam sent by spambots on >> large ISPs. It's not a magic anti-spam bullet. (If you know one, >> please let us know.) >> > That simply hasn't been my experience. I still get lots of spam from booted hosts in large provider networks, and yes, that includes many that block 25. As near as I can tell, 25 blocking is not affecting spammers at all, just legitimate users. I know people at large ISPs with actual data. Port 25 blocking is quite effective. R's, John From pstewart at nexicomgroup.net Fri Sep 3 22:22:33 2010 From: pstewart at nexicomgroup.net (Paul Stewart) Date: Fri, 3 Sep 2010 18:22:33 -0400 Subject: ISP port blocking practice In-Reply-To: References: <20100903124008.72241.qmail@joyce.lan><918D3F33-E46F-40F0-9325-FAE4AE5E0D05@delong.com> Message-ID: It's extremely effective for us (not a large provider by any means). We block outbound 25 on all dynamic IP customers - to date it's never been a problem for our customers. Customer's who have static assignments are not blocked by default. Paul -----Original Message----- From: John R. Levine [mailto:johnl at iecc.com] Sent: Friday, September 03, 2010 3:20 PM To: Owen DeLong Cc: nanog at nanog.org Subject: Re: ISP port blocking practice >> It's been extremely effective in blocking spam sent by spambots on >> large ISPs. It's not a magic anti-spam bullet. (If you know one, >> please let us know.) >> > That simply hasn't been my experience. I still get lots of spam from booted hosts in large provider networks, and yes, that includes many that block 25. As near as I can tell, 25 blocking is not affecting spammers at all, just legitimate users. I know people at large ISPs with actual data. Port 25 blocking is quite effective. R's, John From dougb at dougbarton.us Fri Sep 3 22:41:53 2010 From: dougb at dougbarton.us (Doug Barton) Date: Fri, 03 Sep 2010 15:41:53 -0700 Subject: ISP port blocking practice In-Reply-To: References: <20100903124008.72241.qmail@joyce.lan> <918D3F33-E46F-40F0-9325-FAE4AE5E0D05@delong.com> Message-ID: <4C8179B1.4060603@dougbarton.us> On 9/3/2010 3:19 PM, John R. Levine wrote: > I know people at large ISPs with actual data. Port 25 blocking is quite > effective. Well no one has said it in this thread yet, so I guess it's my turn. :) When talking about spam it often happens that people make statements along the lines of, "Spam still exists, therefore $FOO is not an effective countermeasure." I chose to respond to this message to say that this line of thinking is flawed because this message (to some degree at least) demonstrates that blocking 25 outbound IS effective (again, to some degree); which leads to my larger point. There is no one magic bullet for spam. It's a hydra of a problem if there ever was one, and _every_ option needs to be weighed, both the costs and the benefits. I know that a lot of you know this, but the consistent repetition of the same logical fallacy just gets under my skin, and like I said, it was my turn. Doug From owen at delong.com Fri Sep 3 23:47:18 2010 From: owen at delong.com (Owen DeLong) Date: Sat, 4 Sep 2010 09:17:18 +0930 Subject: just seen my first IPv6 network abuse scan, is this the start for more? In-Reply-To: <4C814188.8040605@bogus.com> References: <6AD92173-D423-49E4-81BF-7E141249222B@arbor.net> <3238DBCC-0258-47EA-B804-D8E254492182@delong.com> <4C814188.8040605@bogus.com> Message-ID: <46ED7543-E402-4848-A70D-4B9EE58BC525@delong.com> Sent from my iPad On Sep 4, 2010, at 4:12 AM, Joel Jaeggli wrote: > On 9/3/10 11:25 AM, Bill Bogstad wrote: >> On Fri, Sep 3, 2010 at 9:49 AM, Dobbins, Roland wrote: >>> >>> On Sep 3, 2010, at 7:58 PM, Owen DeLong wrote: >>> >>>> However, scanning in IPv6 is not at all like the convenience of comprehensive scanning of the IPv4 address space. >>> >>> >>> Concur, but I still maintain that lots of illicit automation plus refined scanning via DNS, et. al. is a viable practice. >> >> These are very big numbers, so I don't see how. > > Consider you have a dual stack deployment. > I do... > what are the most likely ipv6 numbering schemes you're likely to use to > number hosts. > In my case, there are seven numbering schemes in use. > If I query one of your hosts in the forward zone and get back and a and > a aaaa record what can I likely conclude about the numbering scheme for > that net? > > joelja-mac:~ joelja$ host ns3.xxxxxx.net > ns3.xxx.net has address xxxx.xxx.0.81 > ns3.xxx.net has IPv6 address xxxx:xxx:1::81 > In my case, this will only help you find the other hosts which have DNS entries in IPv6. Any host which does not have an AAAA record already uses a different numbering scheme entirely. Even the hosts that do have AAAAs are broken up into different numbering ranges based on my own criteria. > > if you do stateful dhcp v6 assignment what are the likely constraints as > to the size of the pool you're going to use for that subnet. > 1. Stateful DHCP on a subnet is the exception, not the rule. 2. On networks with DHCP, I would give at least a 48 bit pool. > This is like brute force password guessing... there's some high > probability answers that are low hanging fruit you reach for them, they > don't exist you move on. > In other words, you'll get lucky on a few networks where the administrator failed to move beyond IPv4think. >> If you use easy to guess/remember host/service names and put them >> in public DNS then those IP addresses are in some sense already public >> (whether IPv4 or IPv6). The definition of "easy to guess" is pretty >> much everything which has ever been used in a wordlist for password >> cracking programs (plus the code which generates variants of same). >> Real attackers are going to flood >> your DNS servers, not do brute force IPv6 ICMP scans. Even a pure >> brute force DNS scan of all 10 character long hostnames (asuming >> a-z0-9) is going to take around 5000 times fewer queries then a full >> ICMP v6 scan of a /64. (Which at an attack speed of 1000pps is still >> going to take around 100,000 years.) Good luck getting 1000 dns answers per second from most zones. I suspect a useful DNS scan would be limited to something more like 200 qps. Even then, you'll trip over my query rate limiter unless you use a whole lot of hosts to do the scan. >> >> For machines which you want to make it REALLY hard to find, but >> need publicly accessible addresses, you shouldn't put them in publicly >> queryable DNS servers at all and use a random number generator to >> generate their static IPv6 addresses. Even if you put a thousand of >> these machines in a single subnet, it is going to take half a million >> years at reasonable packet rates before even one of them is >> discovered. Or better yet, have the, cycle through privacy addresses using dynamic updates tom private name server. >> >> Hmm, thinking about it in terms of passwords might help. Many >> people consider a totally random 10 character monocase+numbers >> password to be reasonably secure against brute force attacks. ICMP >> scanning a /64 is thousands of times more difficult and all it gives >> you is the existence of the machine. Even if you find that needle in >> a hay stack , you don't get access to its resources. About 6,000 times to be slightly more precise. 36^10 is. ~3,656,158,440,000,000 2^64 is. 18,446,744,073,709,551,616 addresses. >> >> I took a quick look at the paper that SMB linked to and I would >> argue that for wide area attacks, packet sniffing is going to be how >> people find your "hidden" addresses. Compromising SMB wi-fi hotspot >> hardware and logging every address accessed is one possibility. Or >> just compromise people's laptops and have them run network sniffers >> which generate "seen" address lists which are forwarded to dummy gmail >> accounts. >> >> Bill Bogstad >> > I think that's much more likely. Owen From franck at genius.com Fri Sep 3 23:49:33 2010 From: franck at genius.com (Franck Martin) Date: Sat, 4 Sep 2010 11:49:33 +1200 (FJT) Subject: ISP port blocking practice In-Reply-To: <4C8179B1.4060603@dougbarton.us> Message-ID: <26250618.28.1283557772937.JavaMail.franck@franck-martins-macbook-pro.local> I asked around and got this presentation, but you can search for OP25B too: http://www.anacom.pt/streaming/Honda.pdf?contentId=988141&field=ATTACHED_FILE Some non-anecdotal data about the effectiveness of blocking port 25. From hiroo.wumf at gmail.com Sat Sep 4 00:12:40 2010 From: hiroo.wumf at gmail.com (hiroo) Date: Sat, 4 Sep 2010 09:12:40 +0900 Subject: p Message-ID: <277D736C-683E-4940-B4EB-CA287A153B1B@gmail.com> From owen at delong.com Sat Sep 4 00:12:25 2010 From: owen at delong.com (Owen DeLong) Date: Sat, 4 Sep 2010 09:42:25 +0930 Subject: just seen my first IPv6 network abuse scan, is this the start for more? In-Reply-To: References: <6AD92173-D423-49E4-81BF-7E141249222B@arbor.net> <3238DBCC-0258-47EA-B804-D8E254492182@delong.com> Message-ID: <3469A3EE-C168-4614-A5D1-C7BA3CCC642F@delong.com> I was not attempting to defend security through obscurity. It doesn't ultimately help at all. However, compared to the network and other resource costs of scanning, even at more than a billion pps, I think there will be more effective vectors of attack that are more likely to be used in IPv6. In IPv4, an exhaustive scan is quite feasible. In IPv6, scanning a single subnet is 4 billion times harder than scanning the entire IPv4 Internet. My point isn't that hiding hosts in arbitrarily large address space makes them safe. My point is that scanning is not the vector by which they are most likely to get discovered. Owen Sent from my iPad On Sep 4, 2010, at 6:03 AM, Deepak Jain wrote: > >>> Plus, setting bots to go scan isn't very labor-intensive. All the >> talk about how scanning isn't viable in IPv6-land due to large >> netblocks doesn't take into account the benefits of illicit automation. >>> >> Uh... He mentioned 1000 addresses/second... At that rate, scanning a >> /64 will take more than >> 18,000,000,000,000,000 seconds. Converted to hours, that's >> 5,000,000,000,000 hours which >> works out to 208,333,333,333 days or roughly 570,776,255 years. >> >> If you want to scan a single IPv6 subnet completely in 1 year, you will >> need to automate >> 570,776,255 machines scanning at 1000 ip addresses per second, and, >> your target network >> will need to be able to process 570,776,255,000 packets per second. >> >> Yes, you can do a certain amount of table-overflow DOS with an IPv6 >> scan, but, you really >> can't accomplish much else in practical terms. >> > > Since I mentioned a thread about technology prognostication... > > Right now 1000 pps per host seems like a number that is on the high end of what could go reasonably unnoticed by a comprised bot-machine. I'm sure if we roll back our clocks to IPv4's origination we'd have never imagined 1000pps scans. > > If history is any judge, the technology will grow faster and farther than we can see from here. Designers will put stupid kludges in their code [because the space is so vast] like picking Fibonacci numbers as "unique" inside of large sections of space -- who knows. > > The point is that while every smart person thinks this is a lot of space for current attack technology, in some period of time, it may not seem to difficult and safe to hide in. > > Moreover, when every enterprise has a /48 or better, network admins are going to need to be able to track down machines/devices/ear pieces/what have you on a better basis then trapping them when they speak up. There is a huge potential for sleepers in IPv6 space that we don't see any more in IPv4 (because the tools are better). Eventually someone will find an approach to do this kind of surveying and then make it cheap enough everyone can do it. (how often do security-admins use NMAP/Nessus/what have you to survey their own space -- an IPv6 analog will *need* to be created eventually). > > Just my thoughts, > > Deepak From owen at delong.com Sat Sep 4 00:16:43 2010 From: owen at delong.com (Owen DeLong) Date: Sat, 4 Sep 2010 09:46:43 +0930 Subject: Juniper to Watchguard IPSEC In-Reply-To: References: Message-ID: Sent from my iPad On Sep 4, 2010, at 6:50 AM, Iain Morris wrote: > On Fri, Sep 3, 2010 at 10:03 AM, Welch, Bryan wrote: > >> Anyone have any experience with IPSEC between a WG Firebox and Juniper >> SRX/SSG? Running into some problems and beginning to think there might be >> some incompatibilities in their IPSEC options. >> > > >> Not WG but I had trouble getting a SSG to talk to a Cisco until I realized >> the SSG (ScreenOS) has to have a proxy-id defined, which the Cisco required >> to complete the SA. But perhaps you're using Junos on your SSGs if you're >> talking SRX as well. > > Same requirement in JunOS as well. Owen > -Iain From owen at delong.com Sat Sep 4 00:20:25 2010 From: owen at delong.com (Owen DeLong) Date: Sat, 4 Sep 2010 09:50:25 +0930 Subject: ISP port blocking practice In-Reply-To: References: <20100903124008.72241.qmail@joyce.lan> <918D3F33-E46F-40F0-9325-FAE4AE5E0D05@delong.com> Message-ID: <546D5FD6-42BB-487A-B41B-EB6AA93DCB1F@delong.com> Sent from my iPad On Sep 4, 2010, at 7:49 AM, "John R. Levine" wrote: >>> It's been extremely effective in blocking spam sent by spambots on >>> large ISPs. It's not a magic anti-spam bullet. (If you know one, >>> please let us know.) >>> >> That simply hasn't been my experience. I still get lots of spam from booted hosts in large provider networks, and yes, that includes many that block 25. As near as I can tell, 25 blocking is not affecting spammers at all, just legitimate users. > > I know people at large ISPs with actual data. Port 25 blocking is quite effective. > Does the data show that blocking was effective, as in the host didn't detect the block and proceed around it, or, merely that lots of hosts try the direct approach first? Merely tripping over the filter, even repeatedly does not in and of itself prove efficacy. Owen > R's, > John From sethm at rollernet.us Sat Sep 4 00:31:10 2010 From: sethm at rollernet.us (Seth Mattinen) Date: Fri, 03 Sep 2010 17:31:10 -0700 Subject: just seen my first IPv6 network abuse scan, is this the start for more? In-Reply-To: <3469A3EE-C168-4614-A5D1-C7BA3CCC642F@delong.com> References: <6AD92173-D423-49E4-81BF-7E141249222B@arbor.net> <3238DBCC-0258-47EA-B804-D8E254492182@delong.com> <3469A3EE-C168-4614-A5D1-C7BA3CCC642F@delong.com> Message-ID: <4C81934E.6000309@rollernet.us> On 9/3/2010 17:12, Owen DeLong wrote: > I was not attempting to defend security through obscurity. It doesn't ultimately help at all. > > However, compared to the network and other resource costs of scanning, even at more than a billion pps, I think there will be more effective vectors of attack that are more likely to be used in IPv6. In IPv4, an exhaustive scan is quite feasible. In IPv6, scanning a single subnet is 4 billion times harder than scanning the entire IPv4 Internet. > > My point isn't that hiding hosts in arbitrarily large address space makes them safe. My point is that scanning is not the vector by which they are most likely to get discovered. > Even so, it won't stop the uninitiated from scanning the crap out of IPv6 space. ~Seth From jfbeam at gmail.com Sat Sep 4 02:30:19 2010 From: jfbeam at gmail.com (Ricky Beam) Date: Fri, 03 Sep 2010 22:30:19 -0400 Subject: ISP port blocking practice In-Reply-To: <9C23BD21-9384-4959-AAA5-8F4A31050CE1@delong.com> References: <0A08271D-49B9-4382-9F54-1A0BB6A3F2B2@umich.edu> <13222.1256232797@turing-police.cc.vt.edu> <9C23BD21-9384-4959-AAA5-8F4A31050CE1@delong.com> Message-ID: On Fri, 03 Sep 2010 08:12:01 -0400, Owen DeLong wrote: > Really? So, since so many ISPs are blocking port 25, there's lots less > spam hitting our networks? Less than there could be. It appears a lot less effective because there are so many ISPs not doing any blocking. Both of my residential connections are open, and always have been. (even dialup was unblocked. which I always found odd since the UUNET wholesale dialup agreement requires the RADIUS response contain a packet filter limiting port 25 to your mail server(s).) If I block port 25 on my network, no spam will originate from it. (probablly) The spammers will move on to a network that doesn't block their crap. As long as there are such open networks, spam will be rampant. If, overnight, every network filtered port 25, spam would all but disappear. But spam would not completely disappear -- it would just be coming from known mailservers :-) thus enters outbound scanning and the frustrated user complaints from poorly tuned systems... --Ricky From patrick at ianai.net Sat Sep 4 04:18:47 2010 From: patrick at ianai.net (Patrick W. Gilmore) Date: Sat, 4 Sep 2010 00:18:47 -0400 Subject: ISP port blocking practice In-Reply-To: <71B2435D-88D3-4A3C-BF7C-EF09BB0A4789@delong.com> References: <0A08271D-49B9-4382-9F54-1A0BB6A3F2B2@umich.edu> <13222.1256232797@turing-police.cc.vt.edu> <9C23BD21-9384-4959-AAA5-8F4A31050CE1@delong.com> <71B2435D-88D3-4A3C-BF7C-EF09BB0A4789@delong.com> Message-ID: <55DFC36A-9375-4985-A0D3-AC3CDAC317AE@ianai.net> Composed on a virtual keyboard, please forgive typos. On Sep 3, 2010, at 23:50, Owen DeLong wrote: > I think you overestimate the efficacy of this. > > First, why [snip] I think I see the problem here. You are using logic & though experiments, while others have this thing called "data". I'm going to go with data over your assumptions. Call me silly, but that's how I roll. -- TTFN, patrick From johnl at iecc.com Sat Sep 4 05:06:42 2010 From: johnl at iecc.com (John R. Levine) Date: 4 Sep 2010 07:06:42 +0200 Subject: ISP port blocking practice In-Reply-To: <546D5FD6-42BB-487A-B41B-EB6AA93DCB1F@delong.com> References: <20100903124008.72241.qmail@joyce.lan> <918D3F33-E46F-40F0-9325-FAE4AE5E0D05@delong.com> <546D5FD6-42BB-487A-B41B-EB6AA93DCB1F@delong.com> Message-ID: > Does the data show that blocking was effective, as in the host didn't detect the block and proceed around it, or, merely that lots of hosts try the direct approach first? Yes. R's, John From rdobbins at arbor.net Sat Sep 4 05:56:17 2010 From: rdobbins at arbor.net (Dobbins, Roland) Date: Sat, 4 Sep 2010 05:56:17 +0000 Subject: just seen my first IPv6 network abuse scan, is this the start for more? In-Reply-To: <3469A3EE-C168-4614-A5D1-C7BA3CCC642F@delong.com> References: <6AD92173-D423-49E4-81BF-7E141249222B@arbor.net> <3238DBCC-0258-47EA-B804-D8E254492182@delong.com> <3469A3EE-C168-4614-A5D1-C7BA3CCC642F@delong.com> Message-ID: <74B822B2-6D4C-486B-8F8F-0323541D4C27@arbor.net> On Sep 4, 2010, at 7:12 AM, Owen DeLong wrote: > My point is that scanning is not the vector by which they are most likely to get discovered. I do agree with this, definitely, with regards to blind scanning. ----------------------------------------------------------------------- Roland Dobbins // Sell your computer and buy a guitar. From donghong.qin at gmail.com Sat Sep 4 09:36:48 2010 From: donghong.qin at gmail.com (Henry Qin) Date: Sat, 4 Sep 2010 17:36:48 +0800 Subject: Mailing List Archive Message-ID: I subscribe Mailing List Archive. From ryanshea at google.com Sat Sep 4 13:35:00 2010 From: ryanshea at google.com (Ryan Shea) Date: Sat, 4 Sep 2010 09:35:00 -0400 Subject: IPv6 Glue Records at Dotster / Domain.com Message-ID: Anyone with a contact at Doster with the ability to make things happen? Apparently they do not support v6 glue records and they have been unresponsive to my ticket. This seems a kooky reason to change registrars. The table of registrars over at sixxs who have at least some way to get v6 glue records has been getting greener and greener, but no love from Dotster. http://www.sixxs.net/faq/dns/?faq=ipv6glue -Ryan From swmike at swm.pp.se Sat Sep 4 13:43:06 2010 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Sat, 4 Sep 2010 15:43:06 +0200 (CEST) Subject: IPv6 Glue Records at Dotster / Domain.com In-Reply-To: References: Message-ID: On Sat, 4 Sep 2010, Ryan Shea wrote: > Anyone with a contact at Doster with the ability to make things happen? > Apparently they do not support v6 glue records and they have been > unresponsive to my ticket. This seems a kooky reason to change > registrars. If they're not interested in giving you the service you want, why is that a "kooky" reason to take your business elsewhere? Just leave. -- Mikael Abrahamsson email: swmike at swm.pp.se From jared at puck.nether.net Sat Sep 4 15:17:36 2010 From: jared at puck.nether.net (Jared Mauch) Date: Sat, 4 Sep 2010 11:17:36 -0400 Subject: IPv6 Glue Records at Dotster / Domain.com In-Reply-To: References: Message-ID: Opensrs also suffers from lack of v6 glue disease. Last I saw on their forums it said "coming soon" for about a year. Jared Mauch On Sep 4, 2010, at 9:43 AM, Mikael Abrahamsson wrote: > On Sat, 4 Sep 2010, Ryan Shea wrote: > >> Anyone with a contact at Doster with the ability to make things happen? Apparently they do not support v6 glue records and they have been unresponsive to my ticket. This seems a kooky reason to change registrars. > > If they're not interested in giving you the service you want, why is that a "kooky" reason to take your business elsewhere? > > Just leave. > > -- > Mikael Abrahamsson email: swmike at swm.pp.se From jared at puck.nether.net Sat Sep 4 15:20:06 2010 From: jared at puck.nether.net (Jared Mauch) Date: Sat, 4 Sep 2010 11:20:06 -0400 Subject: IPv6 Glue Records at Dotster / Domain.com In-Reply-To: References: Message-ID: Here is the thread: https://forums.opensrs.com/viewtopic.php?f=8&t=83&sid=7db4069af99cfa3aca17f1443cf93522&start=20 Jared Mauch On Sep 4, 2010, at 11:17 AM, Jared Mauch wrote: > Opensrs also suffers from lack of v6 glue disease. Last I saw on their forums it said "coming soon" for about a year. > > Jared Mauch > > On Sep 4, 2010, at 9:43 AM, Mikael Abrahamsson wrote: > >> On Sat, 4 Sep 2010, Ryan Shea wrote: >> >>> Anyone with a contact at Doster with the ability to make things happen? Apparently they do not support v6 glue records and they have been unresponsive to my ticket. This seems a kooky reason to change registrars. >> >> If they're not interested in giving you the service you want, why is that a "kooky" reason to take your business elsewhere? >> >> Just leave. >> >> -- >> Mikael Abrahamsson email: swmike at swm.pp.se From sethm at rollernet.us Sat Sep 4 16:31:43 2010 From: sethm at rollernet.us (Seth Mattinen) Date: Sat, 04 Sep 2010 09:31:43 -0700 Subject: IPv6 Glue Records at Dotster / Domain.com In-Reply-To: References: Message-ID: <4C82746F.4020704@rollernet.us> On 9/4/10 6:35 AM, Ryan Shea wrote: > Anyone with a contact at Doster with the ability to make things happen? > Apparently they do not support v6 glue records and they have been > unresponsive to my ticket. This seems a kooky reason to change registrars. > > The table of registrars over at sixxs who have at least some way to get v6 > glue records has been getting greener and greener, but no love from Dotster. > http://www.sixxs.net/faq/dns/?faq=ipv6glue > Why are DynDNS.com and DNS Exit on that list? Do they register domains (I can't find it if they do)? ~Seth From joelja at bogus.com Sat Sep 4 17:30:45 2010 From: joelja at bogus.com (Joel Jaeggli) Date: Sat, 04 Sep 2010 10:30:45 -0700 Subject: IPv6 Glue Records at Dotster / Domain.com In-Reply-To: <4C82746F.4020704@rollernet.us> References: <4C82746F.4020704@rollernet.us> Message-ID: <4C828245.5040902@bogus.com> On 9/4/10 9:31 AM, Seth Mattinen wrote: > On 9/4/10 6:35 AM, Ryan Shea wrote: >> Anyone with a contact at Doster with the ability to make things happen? >> Apparently they do not support v6 glue records and they have been >> unresponsive to my ticket. This seems a kooky reason to change registrars. >> >> The table of registrars over at sixxs who have at least some way to get v6 >> glue records has been getting greener and greener, but no love from Dotster. >> http://www.sixxs.net/faq/dns/?faq=ipv6glue >> > > Why are DynDNS.com and DNS Exit on that list? Do they register domains > (I can't find it if they do)? Dynamic Network Services does, and they do support ipv6 glue. > ~Seth > From sethm at rollernet.us Sat Sep 4 17:47:43 2010 From: sethm at rollernet.us (Seth Mattinen) Date: Sat, 04 Sep 2010 10:47:43 -0700 Subject: IPv6 Glue Records at Dotster / Domain.com In-Reply-To: <4C828245.5040902@bogus.com> References: <4C82746F.4020704@rollernet.us> <4C828245.5040902@bogus.com> Message-ID: <4C82863F.7020500@rollernet.us> On 9/4/10 10:30 AM, Joel Jaeggli wrote: > On 9/4/10 9:31 AM, Seth Mattinen wrote: >> On 9/4/10 6:35 AM, Ryan Shea wrote: >>> Anyone with a contact at Doster with the ability to make things happen? >>> Apparently they do not support v6 glue records and they have been >>> unresponsive to my ticket. This seems a kooky reason to change registrars. >>> >>> The table of registrars over at sixxs who have at least some way to get v6 >>> glue records has been getting greener and greener, but no love from Dotster. >>> http://www.sixxs.net/faq/dns/?faq=ipv6glue >>> >> >> Why are DynDNS.com and DNS Exit on that list? Do they register domains >> (I can't find it if they do)? > > Dynamic Network Services does, and they do support ipv6 glue. > Ah, I see it now. And I guess the "whois lookup" form on DNS Exit actually means "register domain", I didn't make that connection. ~Seth From sethm at rollernet.us Sat Sep 4 17:55:46 2010 From: sethm at rollernet.us (Seth Mattinen) Date: Sat, 04 Sep 2010 10:55:46 -0700 Subject: IPv6 Glue Records at Dotster / Domain.com In-Reply-To: References: Message-ID: <4C828822.4040506@rollernet.us> On 9/4/10 6:35 AM, Ryan Shea wrote: > Anyone with a contact at Doster with the ability to make things happen? > Apparently they do not support v6 glue records and they have been > unresponsive to my ticket. This seems a kooky reason to change registrars. > > The table of registrars over at sixxs who have at least some way to get v6 > glue records has been getting greener and greener, but no love from Dotster. > http://www.sixxs.net/faq/dns/?faq=ipv6glue > It's not kooky at all. If you need a service your current provider can't/won't provide, then find a new one that will. ~Seth From ryanshea at google.com Sat Sep 4 18:59:12 2010 From: ryanshea at google.com (Ryan Shea) Date: Sat, 4 Sep 2010 14:59:12 -0400 Subject: IPv6 Glue Records at Dotster / Domain.com In-Reply-To: <4C828822.4040506@rollernet.us> References: <4C828822.4040506@rollernet.us> Message-ID: Righto, perhaps it's not kooky. Despite the admittedly small demand, it just seems such a trivial "feature" to have to jump through administrative hoops of swapping registrars for. I'll do what I need to do, but of course if there is a way to make the magic happen without the pain that is great :) -Ryan On Sat, Sep 4, 2010 at 1:55 PM, Seth Mattinen wrote: > On 9/4/10 6:35 AM, Ryan Shea wrote: > > Anyone with a contact at Doster with the ability to make things happen? > > Apparently they do not support v6 glue records and they have been > > unresponsive to my ticket. This seems a kooky reason to change > registrars. > > > > The table of registrars over at sixxs who have at least some way to get > v6 > > glue records has been getting greener and greener, but no love from > Dotster. > > http://www.sixxs.net/faq/dns/?faq=ipv6glue > > > > It's not kooky at all. If you need a service your current provider > can't/won't provide, then find a new one that will. > > ~Seth > > From morrowc.lists at gmail.com Sat Sep 4 19:10:52 2010 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Sat, 4 Sep 2010 15:10:52 -0400 Subject: IPv6 Glue Records at Dotster / Domain.com In-Reply-To: References: <4C828822.4040506@rollernet.us> Message-ID: On Sat, Sep 4, 2010 at 2:59 PM, Ryan Shea wrote: > Righto, perhaps it's not kooky. ?Despite the admittedly small demand, > it just seems such a trivial "feature" to have to jump through > administrative hoops of swapping registrars for. I'll do what I need to do, > but of course if there is a way to make the magic happen without the pain > that is great :) honestly I had thought this came up before (wrt dotster) and someone mentioned after their ordeal that some jiggery-pokery with the techsupport folks got it 'fixed'?? This problem did involve some long phone conversation where you have to reboot your 'windows only' machine a few times to be sure though, of course... -chris > -Ryan > > On Sat, Sep 4, 2010 at 1:55 PM, Seth Mattinen wrote: > >> On 9/4/10 6:35 AM, Ryan Shea wrote: >> > Anyone with a contact at Doster with the ability to make things happen? >> > Apparently they do not support v6 glue records and they have been >> > unresponsive to my ticket. This seems a kooky reason to change >> registrars. >> > >> > The table of registrars over at sixxs who have at least some way to get >> v6 >> > glue records has been getting greener and greener, but no love from >> Dotster. >> > http://www.sixxs.net/faq/dns/?faq=ipv6glue >> > >> >> It's not kooky at all. If you need a service your current provider >> can't/won't provide, then find a new one that will. >> >> ~Seth >> >> > From william.allen.simpson at gmail.com Sat Sep 4 22:24:06 2010 From: william.allen.simpson at gmail.com (William Allen Simpson) Date: Sat, 04 Sep 2010 18:24:06 -0400 Subject: just seen my first IPv6 network abuse scan, is this the start for more? In-Reply-To: <4C80F31C.1010009@de-cix.net> References: <4C80DF58.30000@de-cix.net> <4C80F31C.1010009@de-cix.net> Message-ID: <4C82C706.4070500@gmail.com> On 9/3/10 7:43 AM, Matthias Flittner wrote: >> Since recently we noticed "Neighbour table overflow" warnings from >> the kernel on a lot of Linux machines. As this was very annoying for >> us and our customers I started to dump traffic and tried to find the >> cause. > sounds for me as an typicall IPv6 DoS attack. (see RFC3756) > > Sheng Jiang has discussed this issue in his draft: > http://tools.ietf.org/html/draft-jiang-v6ops-nc-protection-01 > That's what happens when you rip all the security assumptions and requirements out of neighbor discovery! The original design wasn't subject to any of these problems, because: (1) Every request was assumed to be authenticated. Every system was assumed to have a public/private key pair, or a unique secret burned-in at manufacture, paired with its MAC address. A thing you have and a thing you know. [There were supposed exceptions for light bulbs, but good security practices dictate that light bulbs aren't globally accessible. Nowadays, I wouldn't agree to a light bulb exception, as even the puniest system on a chip has plenty of room to store a key pair, and far more processing power than we were using in the old pizza box sized cell phones!] (2) Every router wouldn't send anything from upstream until the downstream had registered its local address and been assigned one or more global dynamic addresses. Back in the day, we'd already seen subnets bigger than the 30 allowed by thinnet, we actually discussed the ARP pollution problem, and we designed to eliminate it. And by "we", I don't include the folks that mangled present-day neighbor discovery. I used to have a recording of one of them made at Xerox PARC claiming the existing ethernet process was good enough, we didn't need that extra stuff for security, mobility, unidirectional satellite links, hidden (radio) terminals, etc. On 9/3/10 9:07 AM, Matthias Flittner wrote: > typically this fill the NC with faked entries and exhaust the node's > cache resources. "This interrupts the normal functions of the targeted > IPv6 node." > > In other words: The attacker sends a lot of ICMPv6 echo requests to your > /64 subnet. Your router has to resolve this addresses internaly (each NA > is stored in NC of the router). The node's cace resources are exhausted > and no "normal" NA could be stored. I think that was your problem. > > Unfortunately is there no standardized way to mitigate this attacks, yet. > > However there are many approaches which could help or could be discussed. > (like http://www.freepatentsonline.com/20070130427.pdf or other) > That caused me to burst out laughing! Wow, all it takes is another 15 years, and more folk just rediscover lessons learned in the first 15 years.... Now, they "patent" it. Kinda fails the "skilled in the art" test. From william.allen.simpson at gmail.com Sat Sep 4 22:37:35 2010 From: william.allen.simpson at gmail.com (William Allen Simpson) Date: Sat, 04 Sep 2010 18:37:35 -0400 Subject: [OT} Re: seek cable/dsl provider in Troy MI 48083 USA In-Reply-To: <3F1408F6031841338B648E68AF59E4D6@intra.ilk.net> References: <3F1408F6031841338B648E68AF59E4D6@intra.ilk.net> Message-ID: <4C82CA2F.3040509@gmail.com> On 9/3/10 9:49 AM, nanog at ilk.net wrote: > for a customer at > Stephenson Highway > Troy, MI 48083 USA > we seek an internet access/service provider, > cable/xdsl/... would be ok, > fixed ip-address prefered. > I use WOW hereabouts, have sometimes used Comcast elsewhere, and have been known (in one instance) to rip the ATT lines and access box off the side of the building and loop it (nicely tied) over the lowest pole rung.... Unless, of course, you are a budding ISP yourself; in which case you have to use ATT -- or run your own competing fiber. > Please answer off-list. > Why? You've bothered a hundred thousand network engineers with a local sales query, so it must be really really important to the North American Network Operations! From jared at puck.nether.net Sat Sep 4 23:07:23 2010 From: jared at puck.nether.net (Jared Mauch) Date: Sat, 4 Sep 2010 19:07:23 -0400 Subject: [OT} Re: seek cable/dsl provider in Troy MI 48083 USA In-Reply-To: <4C82CA2F.3040509@gmail.com> References: <3F1408F6031841338B648E68AF59E4D6@intra.ilk.net> <4C82CA2F.3040509@gmail.com> Message-ID: <8D42A237-DE42-4655-BB97-B4F7F1E4289C@puck.nether.net> On Sep 4, 2010, at 6:37 PM, William Allen Simpson wrote: > On 9/3/10 9:49 AM, nanog at ilk.net wrote: >> for a customer at >> Stephenson Highway >> Troy, MI 48083 USA >> we seek an internet access/service provider, >> cable/xdsl/... would be ok, >> fixed ip-address prefered. >> > I use WOW hereabouts, have sometimes used Comcast elsewhere, and > have been known (in one instance) to rip the ATT lines and access > box off the side of the building and loop it (nicely tied) over the > lowest pole rung.... > > Unless, of course, you are a budding ISP yourself; in which case > you have to use ATT -- or run your own competing fiber. You can also contact tkns.net or www.fiberlinkinc.com for local fiber builds. they will do it all end-to-end for you. (including managing the pole agreement with dte/consumers). tkns is a corporate relative of us signal, you may be able to get the combination of the two to give you good local access. >> Please answer off-list. >> > Why? You've bothered a hundred thousand network engineers with a > local sales query, so it must be really really important to the > North American Network Operations! - Jared From jbfixurpc at gmail.com Sun Sep 5 03:03:46 2010 From: jbfixurpc at gmail.com (Joe Blanchard) Date: Sat, 4 Sep 2010 22:03:46 -0500 Subject: [OT} Re: seek cable/dsl provider in Troy MI 48083 USA In-Reply-To: <8D42A237-DE42-4655-BB97-B4F7F1E4289C@puck.nether.net> References: <3F1408F6031841338B648E68AF59E4D6@intra.ilk.net> <4C82CA2F.3040509@gmail.com> <8D42A237-DE42-4655-BB97-B4F7F1E4289C@puck.nether.net> Message-ID: Simple: http://www.lmgtfy.com/?q=Broadband+providers+Troy%2C+MI (: -Joe > On Sep 4, 2010, at 6:37 PM, William Allen Simpson wrote: > > > On 9/3/10 9:49 AM, nanog at ilk.net wrote: > >> for a customer at > >> Stephenson Highway > >> Troy, MI 48083 USA > >> we seek an internet access/service provider, > >> cable/xdsl/... would be ok, > >> fixed ip-address prefered. > >> > From M.Hotze at hotze.com Sun Sep 5 06:22:51 2010 From: M.Hotze at hotze.com (Martin Hotze) Date: Sun, 5 Sep 2010 06:22:51 +0000 Subject: IPv6 Glue Records at Dotster / Domain.com In-Reply-To: References: Message-ID: <6A4EBE06CF13034585C3F773EAF836A33B88A060@exsrv01.hotzecom.local> > Date: Sat, 4 Sep 2010 11:17:36 -0400 > From: Jared Mauch > Subject: Re: IPv6 Glue Records at Dotster / Domain.com > > Opensrs also suffers from lack of v6 glue disease. Last I saw on their > forums it said "coming soon" for about a year. IBTD. We register our domains with them (Tucows/OpenSRS) and we got the entry, but you have to contact support and it is done manually. Check my domain hotze.com for proving it. #m hotze.com / AS8596 From oberman at es.net Sun Sep 5 06:28:42 2010 From: oberman at es.net (Kevin Oberman) Date: Sat, 04 Sep 2010 23:28:42 -0700 Subject: ISP port blocking practice In-Reply-To: Your message of "Fri, 03 Sep 2010 21:07:49 -0000." <86F2C53A-7A3C-412A-9798-D87A28F9EAB4@arbor.net> Message-ID: <20100905062842.6B66A1CC3A@ptavv.es.net> > From: "Dobbins, Roland" > Date: Fri, 3 Sep 2010 21:07:49 +0000 > > On Sep 3, 2010, at 8:02 PM, Patrick W. Gilmore wrote: > > > Could you point to more than one instance? I've not yet found one. > > I've yet to run across this, either, FWIW, except on extremely > restrictive special-purpose endpoint networks. Doesn't mean that it > doesn't happen, but it doesn't seem to be nearly as prevalent as > TCP/25 blockage on general SP access networks. Worst case I have seen was the visitors network at EBC at one of the nation's largest telephone and Internet transit providers. They seemed to block ALL outgoing ports except 80, 443, and 22. No VPN. No submission port. No IMAP. (Didn't try POP3.) I tunneled mail over ssh, but I can imagine that a lot of corporate types who meet there are rather annoyed that they can't access mail. -- 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 joelja at bogus.com Sun Sep 5 17:02:44 2010 From: joelja at bogus.com (Joel Jaeggli) Date: Sun, 5 Sep 2010 10:02:44 -0700 Subject: just seen my first IPv6 network abuse scan, is this the start for more? In-Reply-To: <4C82C706.4070500@gmail.com> References: <4C80DF58.30000@de-cix.net> <4C80F31C.1010009@de-cix.net> <4C82C706.4070500@gmail.com> Message-ID: Inline... On Sep 4, 2010, at 15:24, William Allen Simpson wrote: > On 9/3/10 7:43 AM, Matthias Flittner wrote: > >> Since recently we noticed "Neighbour table overflow" warnings from > >> the kernel on a lot of Linux machines. As this was very annoying for > >> us and our customers I started to dump traffic and tried to find the > >> cause. > > sounds for me as an typicall IPv6 DoS attack. (see RFC3756) > > > > Sheng Jiang has discussed this issue in his draft: > > http://tools.ietf.org/html/draft-jiang-v6ops-nc-protection-01 > > > That's what happens when you rip all the security assumptions and > requirements out of neighbor discovery! The original design wasn't > subject to any of these problems, because: > > (1) Every request was assumed to be authenticated. Every system > was assumed to have a public/private key pair, or a unique secret > burned-in at manufacture, paired with its MAC address. A thing youdoubt hhave and a thing you know. What we get instead is much like what happens in ipv4 (a flood of arp traffic). There are Implementation specific techniques that can be used to mitigate the cost of that traffic both to the router and the local net. > [There were supposed exceptions for light bulbs, but good security > practices dictate that light bulbs aren't globally accessible. > Nowadays, I wouldn't agree to a light bulb exception, as even the > puniest system on a chip has plenty of room to store a key pair, > and far more processing power than we were using in the old pizza > box sized cell phones!] Ask on 6lowpan about that, I doubt that they would agree. > (2) Every router wouldn't send anything from upstream until the > downstream had registered its local address and been assigned one or > more global dynamic addresses. > > Back in the day, we'd already seen subnets bigger than the 30 allowed > by thinnet, we actually discussed the ARP pollution problem, and we > designed to eliminate it. Right, and when you in v4 have a couple wireless nets that's are /20s the background load can be considerable across all of them and you need to mitigate accordingly. > And by "we", I don't include the folks that mangled present-day neighbor > discovery. I used to have a recording of one of them made at Xerox PARC > claiming the existing ethernet process was good enough, we didn't need > that extra stuff for security, mobility, unidirectional satellite links, > hidden (radio) terminals, etc. > > > On 9/3/10 9:07 AM, Matthias Flittner wrote: >> typically this fill the NC with faked entries and exhaust the node's >> cache resources. "This interrupts the normal functions of the targeted >> IPv6 node." >> >> In other words: The attacker sends a lot of ICMPv6 echo requests to your >> /64 subnet. Your router has to resolve this addresses internaly (each NA >> is stored in NC of the router). The node's cace resources are exhausted >> and no "normal" NA could be stored. I think that was your problem. >> >> Unfortunately is there no standardized way to mitigate this attacks, yet. >> >> However there are many approaches which could help or could be discussed. >> (like http://www.freepatentsonline.com/20070130427.pdf or other) >> > That caused me to burst out laughing! > > Wow, all it takes is another 15 years, and more folk just rediscover > lessons learned in the first 15 years.... > > Now, they "patent" it. Kinda fails the "skilled in the art" test. > From clapidus at gmail.com Sun Sep 5 17:36:30 2010 From: clapidus at gmail.com (Claudio Lapidus) Date: Sun, 5 Sep 2010 14:36:30 -0300 Subject: ISP port blocking practice In-Reply-To: References: <0A08271D-49B9-4382-9F54-1A0BB6A3F2B2@umich.edu> <13222.1256232797@turing-police.cc.vt.edu> <9C23BD21-9384-4959-AAA5-8F4A31050CE1@delong.com> Message-ID: Hello all, On Fri, Sep 3, 2010 at 11:30 PM, Ricky Beam wrote: > > If I block port 25 on my network, no spam will originate from it. > (probablly) The spammers will move on to a network that doesn't block their > crap. ?As long as there are such open networks, spam will be rampant. ?If, > overnight, every network filtered port 25, spam would all but disappear. > ?But spam would not completely disappear -- it would just be coming from > known mailservers :-) ?thus enters outbound scanning and the frustrated user > complaints from poorly tuned systems... > That won't be probably the case. Here recently we conducted a rather comprehensive analysis on dns activity from subscribers, and we've found that in IP ranges that already have outgoing 25 blocked we were still getting complaints about originating spam. It turned out that the bots also know how to send through webmail, so port 25 blocking renders ineffective there. --cl. From jcbender at bendorius.com Sun Sep 5 18:17:30 2010 From: jcbender at bendorius.com (Joseph C. Bender) Date: Sun, 05 Sep 2010 14:17:30 -0400 Subject: IPv6 Glue Records at Dotster / Domain.com In-Reply-To: <6A4EBE06CF13034585C3F773EAF836A33B88A060@exsrv01.hotzecom.local> References: <6A4EBE06CF13034585C3F773EAF836A33B88A060@exsrv01.hotzecom.local> Message-ID: <4C83DEBA.5080203@bendorius.com> Martin Hotze wrote: >> Date: Sat, 4 Sep 2010 11:17:36 -0400 From: Jared Mauch >> Subject: Re: IPv6 Glue Records at Dotster / >> Domain.com >> >> Opensrs also suffers from lack of v6 glue disease. Last I saw on >> their forums it said "coming soon" for about a year. > > IBTD. We register our domains with them (Tucows/OpenSRS) and we got > the entry, but you have to contact support and it is done manually. > Check my domain hotze.com for proving it. > I concur with this. I just finished up bolting V6 glue to a few of my domains to test and see how they handled it. They took care of it within a few hours of sending the request. What proved to be more disturbing was the response I got from an exit survey I'd filled out from a registrar I was transferring domains out from (due to lack of V6 support). I'd told them as such, and got the response that while they were, in fact, working on updating their DNS/domains handling to deal with IPv6, they *had not considered glue records to be part of that*, AND as a result of my feedback they were adding handling such to their project. This is an established registrar that I'd been dealing with for years, they're not exactly fly-by-night. I have to give them credit for admitting it wasn't something they'd considered and were adding it, but still terrible they hadn't even thought of something as basic as IPv6 DNS glue until I mentioned it. The OP in this thread said "This seems a kooky reason to change registrars." At this point and time, I consider that any registrar that can't handle IPv6 to be one that's worth transferring away from and not giving any new business to, assuming one is in the process of deploying IPv6 across their infrastructure. Perhaps economic pressure will be a good enough reason for the registrars to actually get moving and make progress with better support. OpenSRS kept my business because they at least have a mechanism for handling glue, albeit not an automated one. -- Joseph C. Bender jcbender at bendorius dot com From sethm at rollernet.us Sun Sep 5 18:39:07 2010 From: sethm at rollernet.us (Seth Mattinen) Date: Sun, 05 Sep 2010 11:39:07 -0700 Subject: IPv6 Glue Records at Dotster / Domain.com In-Reply-To: <4C83DEBA.5080203@bendorius.com> References: <6A4EBE06CF13034585C3F773EAF836A33B88A060@exsrv01.hotzecom.local> <4C83DEBA.5080203@bendorius.com> Message-ID: <4C83E3CB.7000000@rollernet.us> On 9/5/2010 11:17, Joseph C. Bender wrote: > > Perhaps economic pressure will be a good enough reason for the > registrars to actually get moving and make progress with better support. > OpenSRS kept my business because they at least have a mechanism for > handling glue, albeit not an automated one. > Ah, that's good to know. I have a handful of domains through OpenSRS and in the past they have not been responsive to IPv6 glue inquires. I'll give them another go around. ~Seth From patrick at ianai.net Mon Sep 6 00:11:16 2010 From: patrick at ianai.net (Patrick W. Gilmore) Date: Mon, 6 Sep 2010 08:11:16 +0800 Subject: ISP port blocking practice In-Reply-To: References: <0A08271D-49B9-4382-9F54-1A0BB6A3F2B2@umich.edu> <13222.1256232797@turing-police.cc.vt.edu> <9C23BD21-9384-4959-AAA5-8F4A31050CE1@delong.com> Message-ID: Composed on a virtual keyboard, please forgive typos. On Sep 6, 2010, at 1:36, Claudio Lapidus wrote: > Hello all, > > On Fri, Sep 3, 2010 at 11:30 PM, Ricky Beam wrote: >> >> If I block port 25 on my network, no spam will originate from it. >> (probablly) The spammers will move on to a network that doesn't block their >> crap. As long as there are such open networks, spam will be rampant. If, >> overnight, every network filtered port 25, spam would all but disappear. >> But spam would not completely disappear -- it would just be coming from >> known mailservers :-) thus enters outbound scanning and the frustrated user >> complaints from poorly tuned systems... >> > > That won't be probably the case. Here recently we conducted a rather > comprehensive analysis on dns activity from subscribers, and we've > found that in IP ranges that already have outgoing 25 blocked we were > still getting complaints about originating spam. It turned out that > the bots also know how to send through webmail, so port 25 blocking > renders ineffective there. I believe you have confused "not 100% effective" with "ineffective". And webmail is but one additional vector. Bots know how to use smarthosts, corporate e-mail, triangulation, etc. If you gave up on each because one step did not solve the problem, you would have no chance at a solution. When you unblocked port 25, did spam complaints go up or down? There are a great many providers who have evidence that port 25 blocking lowers complaints even if there are bots that know their way around it. Second, assume you can wave a magic wand and block all webmail access. Do you honestly believe the bots will not use port 25 to send spam directly? Security requires layers. And it is a bit shocking how many people do not realize this. -- TTFN, patrick From franck at genius.com Mon Sep 6 01:13:35 2010 From: franck at genius.com (Franck Martin) Date: Mon, 6 Sep 2010 13:13:35 +1200 (FJT) Subject: ISP port blocking practice In-Reply-To: Message-ID: <8356180.642.1283735612748.JavaMail.franck@franck-martins-macbook-pro.local> In many countries, the presence of bots consume a non-trivial amount of bandwidth. In developing countries, this is a non trivial amount of $$$ (http://mobile.slashdot.org/story/10/09/05/1620212/UN-Tech-Group-Finds-Most-Expensive-Broadband) Blocking port 25 allows to help identify which hosts are consuming bandwidth (likely to have a bot). Identifying and removing these hosts from the network is crucial and economically viable, unfortunately these are skills sometimes not available in such countries. Just saying... ----- Original Message ----- From: "Patrick W. Gilmore" To: "North American Operators' Group" Sent: Monday, 6 September, 2010 12:11:16 PM Subject: Re: ISP port blocking practice Composed on a virtual keyboard, please forgive typos. On Sep 6, 2010, at 1:36, Claudio Lapidus wrote: > Hello all, > > On Fri, Sep 3, 2010 at 11:30 PM, Ricky Beam wrote: >> >> If I block port 25 on my network, no spam will originate from it. >> (probablly) The spammers will move on to a network that doesn't block their >> crap. As long as there are such open networks, spam will be rampant. If, >> overnight, every network filtered port 25, spam would all but disappear. >> But spam would not completely disappear -- it would just be coming from >> known mailservers :-) thus enters outbound scanning and the frustrated user >> complaints from poorly tuned systems... >> > > That won't be probably the case. Here recently we conducted a rather > comprehensive analysis on dns activity from subscribers, and we've > found that in IP ranges that already have outgoing 25 blocked we were > still getting complaints about originating spam. It turned out that > the bots also know how to send through webmail, so port 25 blocking > renders ineffective there. I believe you have confused "not 100% effective" with "ineffective". And webmail is but one additional vector. Bots know how to use smarthosts, corporate e-mail, triangulation, etc. If you gave up on each because one step did not solve the problem, you would have no chance at a solution. When you unblocked port 25, did spam complaints go up or down? There are a great many providers who have evidence that port 25 blocking lowers complaints even if there are bots that know their way around it. Second, assume you can wave a magic wand and block all webmail access. Do you honestly believe the bots will not use port 25 to send spam directly? Security requires layers. And it is a bit shocking how many people do not realize this. -- TTFN, patrick From jlewis at lewis.org Mon Sep 6 01:18:54 2010 From: jlewis at lewis.org (Jon Lewis) Date: Sun, 5 Sep 2010 21:18:54 -0400 (EDT) Subject: ISP port blocking practice In-Reply-To: References: <0A08271D-49B9-4382-9F54-1A0BB6A3F2B2@umich.edu> <13222.1256232797@turing-police.cc.vt.edu> <9C23BD21-9384-4959-AAA5-8F4A31050CE1@delong.com> Message-ID: On Sun, 5 Sep 2010, Claudio Lapidus wrote: >> If I block port 25 on my network, no spam will originate from it. >> (probablly) The spammers will move on to a network that doesn't block their >> crap. ?As long as there are such open networks, spam will be rampant. ?If, >> overnight, every network filtered port 25, spam would all but disappear. >> ?But spam would not completely disappear -- it would just be coming from >> known mailservers :-) ?thus enters outbound scanning and the frustrated user >> complaints from poorly tuned systems... > > That won't be probably the case. Here recently we conducted a rather > comprehensive analysis on dns activity from subscribers, and we've > found that in IP ranges that already have outgoing 25 blocked we were > still getting complaints about originating spam. It turned out that > the bots also know how to send through webmail, so port 25 blocking > renders ineffective there. Anti-spam is a never ending arms race. Originally, the default config for most SMTP servers was to relay for anyone. 10 years ago, sending spam through open SMTP relays was quite common. Eventually, the default changed, nearly all SMTP relays now restrict access by either client IP or password authentication, and the spammers adapted to open proxies. Today, nobody in their right mind sets up an open HTTP proxy, because if they do, it'll be found and abused by spammers in no time. These too have mostly been eliminated, so the spammers had to adapt again, this time to botted end user systems. Getting rid of the vast majority of open relays and open proxies didn't solve the spam problem, but there'd be more ways to send spam if those methods were still generally available. The idea that doing away with open relays and proxies was ineffective, so we may as well not have done and should go back to deploying open relays and open proxies it is silly. With all the different webmail systems, it seems unlikely to me (though I definitely wouldn't say impossible) that bots are spamming through your webmail (unless you work for gmail, hotmail, etc. and are an attractive enough target that it made sense to code a bot to automate utilizing your webmail interface). Bots being used as proxies seems far more likely to me for the general case of "bots" spamming through an ISP's webmail. ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From jared at puck.nether.net Mon Sep 6 01:20:33 2010 From: jared at puck.nether.net (Jared Mauch) Date: Sun, 5 Sep 2010 21:20:33 -0400 Subject: IPv6 Glue Records at OpenSRS/Tucows In-Reply-To: <6A4EBE06CF13034585C3F773EAF836A33B88A060@exsrv01.hotzecom.local> References: <6A4EBE06CF13034585C3F773EAF836A33B88A060@exsrv01.hotzecom.local> Message-ID: On Sep 5, 2010, at 2:22 AM, Martin Hotze wrote: >> Date: Sat, 4 Sep 2010 11:17:36 -0400 >> From: Jared Mauch >> Subject: Re: IPv6 Glue Records at Dotster / Domain.com >> >> Opensrs also suffers from lack of v6 glue disease. Last I saw on their >> forums it said "coming soon" for about a year. > > IBTD. We register our domains with them (Tucows/OpenSRS) and we got the entry, but you have to contact support and it is done manually. Check my domain hotze.com for proving it. Appears someone just posted that to the thread. Sorry, I've not considered that their "official" thread where their EVP says "oops, we've dropped the ball" would not hold better data in this case. Either way, it's lingered on for a year and I hesitate to go through a manual process at this point with a registrar in 2010 to add this glue. Once someone gets back my AA answer, they will have the AAAA address at this point, and can utilize that. It will not drive as much v6 traffic as if the glue were there, but at the same time, I guess I need to move my business elsewhere. Not something I'm looking forward to moving, but I guess it's about time.... I've given them a year to demonstrate progress. It's not like they have to IPv6 enable anything other than their database I'm sure one of my "dns buddies" will offer me a deal to move my domains to them. - Jared From fergdawgster at gmail.com Mon Sep 6 01:38:50 2010 From: fergdawgster at gmail.com (Paul Ferguson) Date: Sun, 5 Sep 2010 18:38:50 -0700 Subject: ISP port blocking practice In-Reply-To: <8356180.642.1283735612748.JavaMail.franck@franck-martins-macbook-pro.local> References: <8356180.642.1283735612748.JavaMail.franck@franck-martins-macbook-pro.local> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sun, Sep 5, 2010 at 6:13 PM, Franck Martin wrote: > In many countries, the presence of bots consume a non-trivial amount of > bandwidth. In developing countries, this is a non trivial amount of $$$ > (http://mobile.slashdot.org/story/10/09/05/1620212/UN-Tech-Group-Finds-Mo > st-Expensive-Broadband) > > Blocking port 25 allows to help identify which hosts are consuming > bandwidth (likely to have a bot). Identifying and removing these hosts > from the network is crucial and economically viable, unfortunately these > are skills sometimes not available in such countries. > > Just saying... > It looks like Germany is now all aboard a program regarding this: http://www.cio.com.au/article/359491/germany_launch_antibotnet_program_cons umers/ FYI, - - ferg -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.5.3 (Build 5003) wj8DBQFMhEYkq1pz9mNUZTMRAkA0AJ44e0uMzlR4iXwpZAE8RQSUM3NmegCg4kV1 WOyT+X0/daNa92gGYG53Rtg= =yMOX -----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 owen at delong.com Mon Sep 6 02:43:27 2010 From: owen at delong.com (Owen DeLong) Date: Sun, 5 Sep 2010 19:43:27 -0700 Subject: ISP port blocking practice In-Reply-To: References: <0A08271D-49B9-4382-9F54-1A0BB6A3F2B2@umich.edu> <13222.1256232797@turing-police.cc.vt.edu> <9C23BD21-9384-4959-AAA5-8F4A31050CE1@delong.com> Message-ID: On Sep 5, 2010, at 10:36 AM, Claudio Lapidus wrote: > Hello all, > > On Fri, Sep 3, 2010 at 11:30 PM, Ricky Beam wrote: >> >> If I block port 25 on my network, no spam will originate from it. >> (probablly) The spammers will move on to a network that doesn't block their >> crap. As long as there are such open networks, spam will be rampant. If, >> overnight, every network filtered port 25, spam would all but disappear. >> But spam would not completely disappear -- it would just be coming from >> known mailservers :-) thus enters outbound scanning and the frustrated user >> complaints from poorly tuned systems... >> > > That won't be probably the case. Here recently we conducted a rather > comprehensive analysis on dns activity from subscribers, and we've > found that in IP ranges that already have outgoing 25 blocked we were > still getting complaints about originating spam. It turned out that > the bots also know how to send through webmail, so port 25 blocking > renders ineffective there. > > --cl. Perhaps a new BCP is coming from MAAWG suggesting we now block outbound port 80. Owen From owen at delong.com Mon Sep 6 03:06:29 2010 From: owen at delong.com (Owen DeLong) Date: Sun, 5 Sep 2010 20:06:29 -0700 Subject: ISP port blocking practice In-Reply-To: References: <0A08271D-49B9-4382-9F54-1A0BB6A3F2B2@umich.edu> <13222.1256232797@turing-police.cc.vt.edu> <9C23BD21-9384-4959-AAA5-8F4A31050CE1@delong.com> Message-ID: <126D663B-2090-4A12-9EBA-E124D1D20729@delong.com> On Sep 5, 2010, at 6:18 PM, Jon Lewis wrote: > On Sun, 5 Sep 2010, Claudio Lapidus wrote: > >>> If I block port 25 on my network, no spam will originate from it. >>> (probablly) The spammers will move on to a network that doesn't block their >>> crap. As long as there are such open networks, spam will be rampant. If, >>> overnight, every network filtered port 25, spam would all but disappear. >>> But spam would not completely disappear -- it would just be coming from >>> known mailservers :-) thus enters outbound scanning and the frustrated user >>> complaints from poorly tuned systems... >> >> That won't be probably the case. Here recently we conducted a rather >> comprehensive analysis on dns activity from subscribers, and we've >> found that in IP ranges that already have outgoing 25 blocked we were >> still getting complaints about originating spam. It turned out that >> the bots also know how to send through webmail, so port 25 blocking >> renders ineffective there. > > Anti-spam is a never ending arms race. Originally, the default config for most SMTP servers was to relay for anyone. 10 years ago, sending spam through open SMTP relays was quite common. Eventually, the default changed, nearly all SMTP relays now restrict access by either client IP or password authentication, and the spammers adapted to open proxies. Today, nobody in their right mind sets up an open HTTP proxy, because if they do, it'll be found and abused by spammers in no time. These too have mostly been eliminated, so the spammers had to adapt again, this time to botted end user systems. > > Getting rid of the vast majority of open relays and open proxies didn't solve the spam problem, but there'd be more ways to send spam if those methods were still generally available. The idea that doing away with open relays and proxies was ineffective, so we may as well not have done and should go back to deploying open relays and open proxies it is silly. > Doing away with open relays and open proxies didn't really interfere with legitimate traffic on a meaningful level. Blocking outbound SMTP is causing such problems. If a better job was done of blocking only 25, perhaps this would be less so. Unfortunately, many hotel networks and such are doing one or more of the following: Blocking ALL SMTP ports (25, 465, 587) Blocking SSH in some cases (fortunately rare, rendering the SMTP thing mostly easy to work around) Blocking IMAPs (while leaving IMAP open?!?) Blocking POP3s (while leaving POP3 open?!?) Blocking just about everything except 80 and 443 The absolute worst ones are proxying ALL SMTP traffic to their server whether it is the address you tried to relay through or not. Generally the ones that have done this have cited the complaints they got from outright blocking SMTP as the reason they felt the need to do so. When I pointed out that not blocking SMTP and only blocking 25 could be a viable alternative, they basically laughed at me. The question isn't just what is or isn't effective, or, even how much it reduces spam complaints. There is also the question of how much legitimate traffic suffers collateral damage in your spam mitiigation techniques. Owen From franck at genius.com Mon Sep 6 04:28:51 2010 From: franck at genius.com (Franck Martin) Date: Mon, 6 Sep 2010 16:28:51 +1200 (FJT) Subject: ISP port blocking practice In-Reply-To: <126D663B-2090-4A12-9EBA-E124D1D20729@delong.com> Message-ID: <14703034.678.1283747330776.JavaMail.franck@franck-martins-macbook-pro.local> ----- Original Message ----- > From: "Owen DeLong" > To: "Jon Lewis" > Cc: "NANOG list" > Sent: Monday, 6 September, 2010 3:06:29 PM > Subject: Re: ISP port blocking practice > On Sep 5, 2010, at 6:18 PM, Jon Lewis wrote: > > > On Sun, 5 Sep 2010, Claudio Lapidus wrote: > > > >>> If I block port 25 on my network, no spam will originate from it. > >>> (probablly) The spammers will move on to a network that doesn't > >>> block their > >>> crap. As long as there are such open networks, spam will be > >>> rampant. If, > >>> overnight, every network filtered port 25, spam would all but > >>> disappear. > >>> But spam would not completely disappear -- it would just be > >>> coming from > >>> known mailservers :-) thus enters outbound scanning and the > >>> frustrated user > >>> complaints from poorly tuned systems... > >> > >> That won't be probably the case. Here recently we conducted a > >> rather > >> comprehensive analysis on dns activity from subscribers, and we've > >> found that in IP ranges that already have outgoing 25 blocked we > >> were > >> still getting complaints about originating spam. It turned out that > >> the bots also know how to send through webmail, so port 25 blocking > >> renders ineffective there. > > > > Anti-spam is a never ending arms race. Originally, the default > > config for most SMTP servers was to relay for anyone. 10 years ago, > > sending spam through open SMTP relays was quite common. Eventually, > > the default changed, nearly all SMTP relays now restrict access by > > either client IP or password authentication, and the spammers > > adapted to open proxies. Today, nobody in their right mind sets up > > an open HTTP proxy, because if they do, it'll be found and abused by > > spammers in no time. These too have mostly been eliminated, so the > > spammers had to adapt again, this time to botted end user systems. > > > > Getting rid of the vast majority of open relays and open proxies > > didn't solve the spam problem, but there'd be more ways to send spam > > if those methods were still generally available. The idea that doing > > away with open relays and proxies was ineffective, so we may as well > > not have done and should go back to deploying open relays and open > > proxies it is silly. > > > Doing away with open relays and open proxies didn't really interfere > with > legitimate traffic on a meaningful level. > > Blocking outbound SMTP is causing such problems. > > If a better job was done of blocking only 25, perhaps this would be > less so. > > Unfortunately, many hotel networks and such are doing one or more of > the > following: > > Blocking ALL SMTP ports (25, 465, 587) > Blocking SSH in some cases (fortunately rare, rendering the SMTP thing > mostly easy to work around) > Blocking IMAPs (while leaving IMAP open?!?) > Blocking POP3s (while leaving POP3 open?!?) > Blocking just about everything except 80 and 443 > > The absolute worst ones are proxying ALL SMTP traffic to their server > whether it is the > address you tried to relay through or not. Generally the ones that > have done this have > cited the complaints they got from outright blocking SMTP as the > reason they felt the > need to do so. When I pointed out that not blocking SMTP and only > blocking 25 could > be a viable alternative, they basically laughed at me. > > The question isn't just what is or isn't effective, or, even how much > it reduces spam > complaints. There is also the question of how much legitimate traffic > suffers collateral > damage in your spam mitiigation techniques. > They do even worse, they charge you USD30 a day for Internet when you have already paid USD250 for the room. I'm not obliging you to stay at these hotels... Read customers review...and write some... From lou at metron.com Mon Sep 6 05:47:00 2010 From: lou at metron.com (Lou Katz) Date: Sun, 5 Sep 2010 22:47:00 -0700 Subject: IPv6 Glue Records at Dotster / Domain.com In-Reply-To: <4C83E3CB.7000000@rollernet.us> References: <6A4EBE06CF13034585C3F773EAF836A33B88A060@exsrv01.hotzecom.local> <4C83DEBA.5080203@bendorius.com> <4C83E3CB.7000000@rollernet.us> Message-ID: <20100906054700.GA44634@metron.com> On Sun, Sep 05, 2010 at 11:39:07AM -0700, Seth Mattinen wrote: > On 9/5/2010 11:17, Joseph C. Bender wrote: > > > > Perhaps economic pressure will be a good enough reason for the > > registrars to actually get moving and make progress with better support. > > OpenSRS kept my business because they at least have a mechanism for > > handling glue, albeit not an automated one. > > > > Ah, that's good to know. I have a handful of domains through OpenSRS and > in the past they have not been responsive to IPv6 glue inquires. I'll > give them another go around. > > ~Seth It only took me one or two E-mails to OpenSRS to get the glue records done. (But - Disclosure - I am an OpenSRS Reseller). Response was polite, but not super swift, but I was not in a hurry. -- -=[L]=- Sent from the luminiferous aether Contact me if you do not receive this message. From jda at tapodi.net Mon Sep 6 08:42:48 2010 From: jda at tapodi.net (Jon Auer) Date: Mon, 6 Sep 2010 03:42:48 -0500 Subject: ISP port blocking practice In-Reply-To: <14703034.678.1283747330776.JavaMail.franck@franck-martins-macbook-pro.local> References: <126D663B-2090-4A12-9EBA-E124D1D20729@delong.com> <14703034.678.1283747330776.JavaMail.franck@franck-martins-macbook-pro.local> Message-ID: > With all the different webmail systems, it seems unlikely to me (though I definitely wouldn't say impossible) that bots are spamming through your webmail (unless you work for gmail, hotmail, etc. and are an attractive enough target that it made sense to code a bot to automate utilizing your webmail interface). ?Bots being used as proxies seems far more likely to me for the general case of "bots" spamming through an ISP's webmail. > Many providers and hosts use the same webmail packages so the work to automate is a bit lower than one might think. We have seen bots sending spam using our squirrelmail and roundcube webmail using credentials gleaned from phishing activity. From rhsv6 at hushmail.com Mon Sep 6 10:26:25 2010 From: rhsv6 at hushmail.com (rhsv6 at hushmail.com) Date: Mon, 06 Sep 2010 11:26:25 +0100 Subject: Juniper to Watchguard IPSEC Message-ID: <20100906102625.5BC2428051@smtp.hushmail.com> You have not specified what sort of settings you are using (PSK vs CERTS, Algos , route based VPN etc) However something along the following lines is working fine for me: set ike gateway "**************" address 172.16.250.1 Main outgoing- interface "ethernet0/8" preshare "**************" proposal "pre-g2- 3des-sha" set vpn "**************" gateway "**************" replay tunnel idletime 0 proposal "g2-esp-aes128-sha" set vpn "**************" id 0x7 bind interface tunnel.40 set vpn "**************" proxy-id local-ip 192.168.1.0/24 remote-ip 10.1.2.0/24 "ANY" >Anyone have any experience with IPSEC between a WG Firebox and Juniper >SRX/SSG? Running into some problems and beginning to think there might be >some incompatibilities in their IPSEC options. > TIA, > Bryan From rbf+nanog at panix.com Mon Sep 6 13:22:05 2010 From: rbf+nanog at panix.com (Brett Frankenberger) Date: Mon, 6 Sep 2010 08:22:05 -0500 Subject: ISP port blocking practice In-Reply-To: References: <9C23BD21-9384-4959-AAA5-8F4A31050CE1@delong.com> Message-ID: <20100906132205.GA21165@panix.com> On Sun, Sep 05, 2010 at 09:18:54PM -0400, Jon Lewis wrote: > > Anti-spam is a never ending arms race. That's really the question at hand here -- whether or not there's any benefit to continuing the "never ending arms race" game. Some people think there is. Others question whether anything is really being accomplished. Certainly we're playing it out like an arms race -- ISPs block something, spammers find a new way to inject spam, and so on. The end result of lots of time spend on blocking thins, less functionality for customers ... but no decrease in spam. > Originally, the default config > for most SMTP servers was to relay for anyone. 10 years ago, sending > spam through open SMTP relays was quite common. Eventually, the default > changed, nearly all SMTP relays now restrict access by either client IP > or password authentication, and the spammers adapted to open proxies. > Today, nobody in their right mind sets up an open HTTP proxy, because if > they do, it'll be found and abused by spammers in no time. These too > have mostly been eliminated, so the spammers had to adapt again, this > time to botted end user systems. > > Getting rid of the vast majority of open relays and open proxies didn't > solve the spam problem, but there'd be more ways to send spam if those > methods were still generally available. The idea that doing away with > open relays and proxies was ineffective, so we may as well not have done > and should go back to deploying open relays and open proxies it is silly. Is it? It's likely true that the amount of span sent through open relays today is smaller than the amount of spam send through open relays 10 years ago. If the objective is "less spam via open relays", closing down open relays was a raging success. But that's not the objective. The objective is less spam, and there's certainly not less spam today than there was 10 years ago. Of course, those who worked to close open relays might argue that there would be even more spam today if there were still open relays. But they don't know that and there's no real evidence to support that. The theory behind closing open relays, blocking port 25, etc., seems to be: (a) That will make it harder on spammers, and that will reduce spam -- some of the spammers will find other other ways to inject spam, but some will just stop, OR (b) Eventually, we'll find technical solutions to *all* the ways spam is injected, and then there will be no more spam. There's little evidence for either. -- Brett From patrick at ianai.net Mon Sep 6 21:54:49 2010 From: patrick at ianai.net (Patrick W. Gilmore) Date: Mon, 6 Sep 2010 17:54:49 -0400 Subject: ISP port blocking practice In-Reply-To: <20100906132205.GA21165@panix.com> References: <9C23BD21-9384-4959-AAA5-8F4A31050CE1@delong.com> <20100906132205.GA21165@panix.com> Message-ID: <7B17CACC-A9B2-4FC2-9B3B-93B1C41D6485@ianai.net> On Sep 6, 2010, at 9:22 AM, Brett Frankenberger wrote: > On Sun, Sep 05, 2010 at 09:18:54PM -0400, Jon Lewis wrote: >> >> Getting rid of the vast majority of open relays and open proxies didn't >> solve the spam problem, but there'd be more ways to send spam if those >> methods were still generally available. The idea that doing away with >> open relays and proxies was ineffective, so we may as well not have done >> and should go back to deploying open relays and open proxies it is silly. > > Is it? It's likely true that the amount of span sent through open > relays today is smaller than the amount of spam send through open > relays 10 years ago. If the objective is "less spam via open relays", > closing down open relays was a raging success. But that's not the > objective. The objective is less spam, and there's certainly not less > spam today than there was 10 years ago. > > Of course, those who worked to close open relays might argue that there > would be even more spam today if there were still open relays. But > they don't know that and there's no real evidence to support that. You are incorrect. There is vast evidence that closing open relays resulted in less spam. You can do a very simple experiment to satisfy your own curiosity. Open your SMTP host or HTTP proxy, wait a couple days and see what happens. > The theory behind closing open relays, blocking port 25, etc., seems to > be: > (a) That will make it harder on spammers, and that will reduce spam -- > some of the spammers will find other other ways to inject spam, but > some will just stop, OR > (b) Eventually, we'll find technical solutions to *all* the ways spam > is injected, and then there will be no more spam. To be clear, even if there were not "vast evidence" blocking port 25 helped lower spam loads (and there _is_), it should still be filtered on residential / dynamic pools. There is more DDoS today than ever before. I guess we should all enable directed broadcast again. Miscreants aren't using smurf attacks (or at least I haven't seen it, therefore it doesn't exist, right?), and there are other tons of other ways to DDoS people. So we should just open them back up, right? If that doesn't sound ridiculously stupid to you, then you know nothing of DDoS fighting either. And if it does sound stupid to you, .. well, I think you get the point. > There's little evidence for either. You are wrong. If you do not actually know something (and "I haven't heard of it" or "my friends don't like it" or "I don't see how ..." does not equal "I -know-"), then please refrain from making factual sounding statements. [Yeah, yeah, this is NANOG. Chances of that happening are nil. But at least the people who are willing to make such statements are self-identifying for easy future reference.] -- TTFN, patrick From deleskie at gmail.com Mon Sep 6 22:38:15 2010 From: deleskie at gmail.com (deleskie at gmail.com) Date: Mon, 6 Sep 2010 22:38:15 +0000 Subject: ISP port blocking practice In-Reply-To: <7B17CACC-A9B2-4FC2-9B3B-93B1C41D6485@ianai.net> References: <9C23BD21-9384-4959-AAA5-8F4A31050CE1@delong.com><20100906132205.GA21165@panix.com><7B17CACC-A9B2-4FC2-9B3B-93B1C41D6485@ianai.net> Message-ID: <652107151-1283812694-cardhu_decombobulator_blackberry.rim.net-1600909933-@bda002.bisx.prod.on.blackberry> Having worked in past @ 3 large ISPs with residential customer pools I can tell you we saw a very direct drop in spam issues when we blocked port 25. -jim Sent from my BlackBerry device on the Rogers Wireless Network -----Original Message----- From: "Patrick W. Gilmore" Date: Mon, 6 Sep 2010 17:54:49 To: NANOG list Subject: Re: ISP port blocking practice On Sep 6, 2010, at 9:22 AM, Brett Frankenberger wrote: > On Sun, Sep 05, 2010 at 09:18:54PM -0400, Jon Lewis wrote: >> >> Getting rid of the vast majority of open relays and open proxies didn't >> solve the spam problem, but there'd be more ways to send spam if those >> methods were still generally available. The idea that doing away with >> open relays and proxies was ineffective, so we may as well not have done >> and should go back to deploying open relays and open proxies it is silly. > > Is it? It's likely true that the amount of span sent through open > relays today is smaller than the amount of spam send through open > relays 10 years ago. If the objective is "less spam via open relays", > closing down open relays was a raging success. But that's not the > objective. The objective is less spam, and there's certainly not less > spam today than there was 10 years ago. > > Of course, those who worked to close open relays might argue that there > would be even more spam today if there were still open relays. But > they don't know that and there's no real evidence to support that. You are incorrect. There is vast evidence that closing open relays resulted in less spam. You can do a very simple experiment to satisfy your own curiosity. Open your SMTP host or HTTP proxy, wait a couple days and see what happens. > The theory behind closing open relays, blocking port 25, etc., seems to > be: > (a) That will make it harder on spammers, and that will reduce spam -- > some of the spammers will find other other ways to inject spam, but > some will just stop, OR > (b) Eventually, we'll find technical solutions to *all* the ways spam > is injected, and then there will be no more spam. To be clear, even if there were not "vast evidence" blocking port 25 helped lower spam loads (and there_is_), it should still be filtered on residential / dynamic pools. There is more DDoS today than ever before. I guess we should all enable directed broadcast again. Miscreants aren't using smurf attacks (or at least I haven't seen it, therefore it doesn't exist, right?), and there are other tons of other ways to DDoS people. So we should just open them back up, right? If that doesn't sound ridiculously stupid to you, then you know nothing of DDoS fighting either. And if it does sound stupid to you, .. well, I think you get the point. > There's little evidence for either. You are wrong. If you do not actually know something (and "I haven't heard of it" or "my friends don't like it" or "I don't see how ..." does not equal "I -know-"), then please refrain from making factual sounding statements. [Yeah, yeah, this is NANOG. Chances of that happening are nil. But at least the people who are willing to make such statements are self-identifying for easy future reference.] -- TTFN, patrick From rbf+nanog at panix.com Tue Sep 7 00:55:06 2010 From: rbf+nanog at panix.com (Brett Frankenberger) Date: Mon, 6 Sep 2010 19:55:06 -0500 Subject: ISP port blocking practice In-Reply-To: <652107151-1283812694-cardhu_decombobulator_blackberry.rim.net-1600909933-@bda002.bisx.prod.on.blackberry> References: <7B17CACC-A9B2-4FC2-9B3B-93B1C41D6485@ianai.net> <652107151-1283812694-cardhu_decombobulator_blackberry.rim.net-1600909933-@bda002.bisx.prod.on.blackberry> Message-ID: <20100907005506.GA7763@panix.com> On Mon, Sep 06, 2010 at 10:38:15PM +0000, deleskie at gmail.com wrote: > > Having worked in past @ 3 large ISPs with residential customer pools > I can tell you we saw a very direct drop in spam issues when we > blocked port 25. No one is disputing that. Or, at least, I'm not disputing that. I'm questioning whether or not the *Internet* has experienced any decrease in aggregate spam as a result of ISPs blocking port 25. Did the spam you blocked disappear, or did it all get sent some other way? I'm questioning the evidence for the claim that it didn't just all get sent some other way. (By "all", I mean "almost all". I'm sure at least one piece of spam has been permanently prevented from getting sent as a result of port 25 filters.) I'm not suggesting ISPs should or shouldn't block port 25. That's a decision each must make for itself. And I'm not questioning that blocking offers benefits for those who choose to block it. What I'm questioning is whether or not it results in any meaningful reduction in aggregate spam. (That is, are people *receiving* less spam becuase the three ISPs you describe above -- along with many others -- blocked port 25.) -- Brett From randy at psg.com Tue Sep 7 01:30:04 2010 From: randy at psg.com (Randy Bush) Date: Tue, 07 Sep 2010 10:30:04 +0900 Subject: ISP port blocking practice In-Reply-To: <20100906132205.GA21165@panix.com> References: <9C23BD21-9384-4959-AAA5-8F4A31050CE1@delong.com> <20100906132205.GA21165@panix.com> Message-ID: > The theory behind closing open relays, blocking port 25, etc., seems to > be: > (a) That will make it harder on spammers, and that will reduce spam -- > some of the spammers will find other other ways to inject spam, but > some will just stop, OR > (b) Eventually, we'll find technical solutions to *all* the ways spam > is injected, and then there will be no more spam. > > There's little evidence for either. the empirical evicence seems to support this theory. spam has continually increased, wich occasional dips when the spammers have to find a new path when an old one is covered. i suspect that, if we opened smtp relays again, unblocked 25 for consumer chokeband, etc., total spam received would likely increase a bit. but my guess, and i mean guess, is that the limiting parameter could well be how many bots the perps can get, not how well those bots are blocked. but, let's look at the upside. with the dying economy, the spam war provides employment for many of our friends. randy From ops.lists at gmail.com Tue Sep 7 01:36:53 2010 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Tue, 7 Sep 2010 07:06:53 +0530 Subject: ISP port blocking practice In-Reply-To: References: <9C23BD21-9384-4959-AAA5-8F4A31050CE1@delong.com> <20100906132205.GA21165@panix.com> Message-ID: No. It'd just increase a LOT, astronomically. Something on the lines of turning a firehose of petrol on a wildfire On Tue, Sep 7, 2010 at 7:00 AM, Randy Bush wrote: > i suspect that, if we opened smtp relays again, unblocked 25 for > consumer chokeband, etc., total spam received would likely increase a > bit. ?but my guess, and i mean guess, is that the limiting parameter > could well be how many bots the perps can get, not how well those bots > are blocked. -- Suresh Ramasubramanian (ops.lists at gmail.com) From randy at psg.com Tue Sep 7 01:59:23 2010 From: randy at psg.com (Randy Bush) Date: Tue, 07 Sep 2010 10:59:23 +0900 Subject: ISP port blocking practice In-Reply-To: References: <9C23BD21-9384-4959-AAA5-8F4A31050CE1@delong.com> <20100906132205.GA21165@panix.com> Message-ID: > No. It'd just increase a LOT, astronomically. >> i suspect that, if we opened smtp relays again, unblocked 25 for >> consumer chokeband, etc., total spam received would likely increase a >> bit. ?but my guess, and i mean guess, is that the limiting parameter >> could well be how many bots the perps can get, not how well those >> bots are blocked. i keep hearing that, but am having a hard time finding supporting data. randy From ryanshea at google.com Tue Sep 7 01:59:28 2010 From: ryanshea at google.com (Ryan Shea) Date: Mon, 6 Sep 2010 21:59:28 -0400 Subject: IPv6 Glue Records at Dotster / Domain.com In-Reply-To: <20100906054700.GA44634@metron.com> References: <6A4EBE06CF13034585C3F773EAF836A33B88A060@exsrv01.hotzecom.local> <4C83DEBA.5080203@bendorius.com> <4C83E3CB.7000000@rollernet.us> <20100906054700.GA44634@metron.com> Message-ID: Hmm, transaction id, security code, a 21 minute hold time with GoDaddy, and two dozen Danica Patrick pictures and I am quickly realizing that this glue is going to be much more costly than the ~$8 transfer fee. -Ryan On Mon, Sep 6, 2010 at 1:47 AM, Lou Katz wrote: > On Sun, Sep 05, 2010 at 11:39:07AM -0700, Seth Mattinen wrote: > > On 9/5/2010 11:17, Joseph C. Bender wrote: > > > > > > Perhaps economic pressure will be a good enough reason for the > > > registrars to actually get moving and make progress with better > support. > > > OpenSRS kept my business because they at least have a mechanism for > > > handling glue, albeit not an automated one. > > > > > > > Ah, that's good to know. I have a handful of domains through OpenSRS and > > in the past they have not been responsive to IPv6 glue inquires. I'll > > give them another go around. > > > > ~Seth > > It only took me one or two E-mails to OpenSRS to get the glue records done. > (But - Disclosure - I am an OpenSRS Reseller). Response was polite, but not > super swift, but I was not in a hurry. > -- > > -=[L]=- > Sent from the luminiferous aether > > Contact me if you do not receive this message. > > From ops.lists at gmail.com Tue Sep 7 02:22:04 2010 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Tue, 7 Sep 2010 07:52:04 +0530 Subject: ISP port blocking practice In-Reply-To: References: <9C23BD21-9384-4959-AAA5-8F4A31050CE1@delong.com> <20100906132205.GA21165@panix.com> Message-ID: On Tue, Sep 7, 2010 at 7:29 AM, Randy Bush wrote: > i keep hearing that, but am having a hard time finding supporting data. Might see the stats from http://cbl.abuseat.org - by AS. Then compare the stats on a non port 25 filtered network (they have stats by AS) to stats on a network that is filtered on port 25 The networks that are filtered on port 25 will of course have any bots on that network originating spam by other means (social networks, webmail scripting etc), or other types of nastiness (DDoS etc). But you won't find them mailing out direct on port 25. The bots are very much there - and if the port 25 filtering were to be taken out, you'd at once see the increase in spam volumes. --srs -- Suresh Ramasubramanian (ops.lists at gmail.com) From Tero.Toikkanen at nebula.fi Tue Sep 7 08:24:05 2010 From: Tero.Toikkanen at nebula.fi (Tero Toikkanen) Date: Tue, 7 Sep 2010 08:24:05 +0000 Subject: IPv4 squatters on the move again? Message-ID: Anyone hear of the SundownGroup? On Thursday we received an interesting RFQ from them and suspect their intentions for requesting an IP assignment isn't exactly what they state. We have already turned them down, but thought others might be interested in their activities as well. RIPE NCC has also been notified of this. In brief they wanted to buy colo form us: "P4 single core @ 2 Ghz, 1 GB RAM, 60 GB HD, Linux CentOS 5x.x, 10 Mbps bandwidth. A single /21 or /20 net block of IP Adresses" Their reason for requesting such a large address block was "As we are currently launching our WholesaleVOIP operation we are in desperate need of this IP space as part of our ARIN process we will need these ranges SWIPd to us and we will in turn renumber with ARIN and return the netblocks to you as soon as ours are allocated and routed." Interesting tidbits about the company we and the networking community have already found out: Compare http://sundowngroup.com/ and http://www.edgecast.com/ (Edgecast has been notified). The contact address is the same as National University Nevada (nu.edu): Sundown Capital Management LLC 2850 Horizon Ridge Parkway Henderson, Nevada 89052 United States of America They also have virtually no Internet presence (http://www.google.com/search?q=%22Sundown+Capital+Management%22) The first result shows them as a franchicing company with contact address in California: http://www.scribd.com/doc/14385124/QFA-Unit-Final-PDF-File-of-32709-FDD-With-Exhibits I'd say this case is pretty obvious... With Kind Regards, -- Tero Toikkanen Nebula Oy Internet Services From jeffrey.lyon at blacklotus.net Tue Sep 7 08:51:58 2010 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Tue, 7 Sep 2010 13:21:58 +0430 Subject: IPv4 squatters on the move again? In-Reply-To: References: Message-ID: We see this all the time, usually it involves either a /20 or multiple-/xx that change every month. Jeff On Tue, Sep 7, 2010 at 12:54 PM, Tero Toikkanen wrote: > Anyone hear of the SundownGroup? > > On Thursday we received an interesting RFQ from them and suspect their > intentions for requesting an IP assignment isn't exactly what they state. We > have already turned them down, but thought others might be interested in > their activities as well. RIPE NCC has also been notified of this. > > In brief they wanted to buy colo form us: "P4 single core @ 2 Ghz, 1 GB > RAM, 60 GB HD, Linux CentOS 5x.x, 10 Mbps bandwidth. A single /21 or /20 net > block of IP Adresses" > > Their reason for requesting such a large address block was "As we are > currently launching our WholesaleVOIP operation we are in desperate need of > this IP space as part of our ARIN process we will need these ranges SWIPd to > us and we will in turn renumber with ARIN and return the netblocks to you as > soon as ours are allocated and routed." > > Interesting tidbits about the company we and the networking community have > already found out: > > Compare http://sundowngroup.com/ and http://www.edgecast.com/ (Edgecast > has been notified). > > The contact address is the same as National University Nevada (nu.edu): > > Sundown Capital Management LLC > 2850 Horizon Ridge Parkway > Henderson, Nevada 89052 > United States of America > > They also have virtually no Internet presence ( > http://www.google.com/search?q=%22Sundown+Capital+Management%22) > The first result shows them as a franchicing company with contact address > in California: > http://www.scribd.com/doc/14385124/QFA-Unit-Final-PDF-File-of-32709-FDD-With-Exhibits > > I'd say this case is pretty obvious... > > With Kind Regards, > -- > Tero Toikkanen > Nebula Oy Internet Services > > -- Jeffrey Lyon, Leadership Team jeffrey.lyon at blacklotus.net | http://www.blacklotus.net Black Lotus Communications - AS32421 First and Leading in DDoS Protection Solutions From khatfield at socllc.net Tue Sep 7 10:18:48 2010 From: khatfield at socllc.net (khatfield at socllc.net) Date: Tue, 7 Sep 2010 10:18:48 +0000 Subject: IPv4 squatters on the move again? In-Reply-To: References: Message-ID: <2002772359-1283854730-cardhu_decombobulator_blackberry.rim.net-1960445652-@bda903.bisx.prod.on.blackberry> Kind of funny how they intend to do enough 'WholesaleVoIP" on a 10Mbps connection/1GB RAM for a /20 :) That is a giveaway in itself. -----Original Message----- From: Tero Toikkanen Date: Tue, 7 Sep 2010 08:24:05 To: NANOG list Subject: IPv4 squatters on the move again? Anyone hear of the SundownGroup? On Thursday we received an interesting RFQ from them and suspect their intentions for requesting an IP assignment isn't exactly what they state. We have already turned them down, but thought others might be interested in their activities as well. RIPE NCC has also been notified of this. In brief they wanted to buy colo form us: "P4 single core @ 2 Ghz, 1 GB RAM, 60 GB HD, Linux CentOS 5x.x, 10 Mbps bandwidth. A single /21 or /20 net block of IP Adresses" Their reason for requesting such a large address block was "As we are currently launching our WholesaleVOIP operation we are in desperate need of this IP space as part of our ARIN process we will need these ranges SWIPd to us and we will in turn renumber with ARIN and return the netblocks to you as soon as ours are allocated and routed." Interesting tidbits about the company we and the networking community have already found out: Compare http://sundowngroup.com/ and http://www.edgecast.com/ (Edgecast has been notified). The contact address is the same as National University Nevada (nu.edu): Sundown Capital Management LLC 2850 Horizon Ridge Parkway Henderson, Nevada 89052 United States of America They also have virtually no Internet presence (http://www.google.com/search?q=%22Sundown+Capital+Management%22) The first result shows them as a franchicing company with contact address in California: http://www.scribd.com/doc/14385124/QFA-Unit-Final-PDF-File-of-32709-FDD-With-Exhibits I'd say this case is pretty obvious... With Kind Regards, -- Tero Toikkanen Nebula Oy Internet Services From Tero.Toikkanen at nebula.fi Tue Sep 7 10:34:46 2010 From: Tero.Toikkanen at nebula.fi (Tero Toikkanen) Date: Tue, 7 Sep 2010 10:34:46 +0000 Subject: IPv4 squatters on the move again? In-Reply-To: <2002772359-1283854730-cardhu_decombobulator_blackberry.rim.net-1960445652-@bda903.bisx.prod.on.blackberry> References: <2002772359-1283854730-cardhu_decombobulator_blackberry.rim.net-1960445652-@bda903.bisx.prod.on.blackberry> Message-ID: Yeah, it's pretty obvious from the start. I'd like to see the VoIP-system with those requirements... I just think these cases should be made public to at least slow these guys down, just in case someone else is less cluefull :) If these really happen all the time in the big world, this list may not be the right place, but just something Google can find. This is not first case we have come across requests like this, but still not so common in the Finnish hosting scene. With Kind Regards, -- Tero Toikkanen Nebula Oy Internet Services > Kind of funny how they intend to do enough 'WholesaleVoIP" on a 10Mbps > connection/1GB RAM for a /20 :) > > That is a giveaway in itself. > -----Original Message----- > From: Tero Toikkanen > Date: Tue, 7 Sep 2010 08:24:05 > To: NANOG list > Subject: IPv4 squatters on the move again? > > Anyone hear of the SundownGroup? > > On Thursday we received an interesting RFQ from them and suspect their > intentions for requesting an IP assignment isn't exactly what they state. We > have already turned them down, but thought others might be interested in > their activities as well. RIPE NCC has also been notified of this. > > In brief they wanted to buy colo form us: "P4 single core @ 2 Ghz, 1 GB RAM, > 60 GB HD, Linux CentOS 5x.x, 10 Mbps bandwidth. A single /21 or /20 net block > of IP Adresses" > > Their reason for requesting such a large address block was "As we are > currently launching our WholesaleVOIP operation we are in desperate need of > this IP space as part of our ARIN process we will need these ranges SWIPd to > us and we will in turn renumber with ARIN and return the netblocks to you as > soon as ours are allocated and routed." > > Interesting tidbits about the company we and the networking community have > already found out: > > Compare http://sundowngroup.com/ and http://www.edgecast.com/ (Edgecast has > been notified). > > The contact address is the same as National University Nevada (nu.edu): > > Sundown Capital Management LLC > 2850 Horizon Ridge Parkway > Henderson, Nevada 89052 > United States of America > > They also have virtually no Internet presence > (http://www.google.com/search?q=%22Sundown+Capital+Management%22) > The first result shows them as a franchicing company with contact address in > California: http://www.scribd.com/doc/14385124/QFA-Unit-Final-PDF-File-of- > 32709-FDD-With-Exhibits > > I'd say this case is pretty obvious... > > With Kind Regards, > -- > Tero Toikkanen > Nebula Oy Internet Services From jamie at photon.com Tue Sep 7 13:03:12 2010 From: jamie at photon.com (Jamie Bowden) Date: Tue, 7 Sep 2010 09:03:12 -0400 Subject: just seen my first IPv6 network abuse scan, is this the startfor more? In-Reply-To: References: <6AD92173-D423-49E4-81BF-7E141249222B@arbor.net><3238DBCC-0258-47EA-B804-D8E254492182@delong.com><6A6F346A-2AA6-47E4-92D2-967627CE1202@cs.columbia.edu> Message-ID: <5C836A1A98186142A6BEC393FD5E2A860156DF@hal.photon.com> Forgive the top posting, but Lookout is the corporate standard. Now, on to the topic at hand. Why would you scan the address space in the first place? Wouldn't it be easier to compromise a known host and look at the ARP table? Or better yet, the router on the edge? If it's moving packets, something on the network has mapped the MAC address to its IP at some point. Jamie -----Original Message----- From: Dobbins, Roland [mailto:rdobbins at arbor.net] Sent: Friday, September 03, 2010 3:42 PM To: NANOG list Subject: Re: just seen my first IPv6 network abuse scan, is this the startfor more? On Sep 4, 2010, at 12:19 AM, Steven Bellovin wrote: > See http://www.cs.columbia.edu/~smb/papers/v6worms.pdf I've seen it and concur with regards to worms (which don't seem to be very popular, right now, excepting the 'background radiation' of old Code Red, Nimda, Blaster, Nachi, SQL Slammer, et. al. hosts). I believe that hinted scanning is still viable, and I'd argue that the experience of the OP who kicked off this thread is an indication of same. ----------------------------------------------------------------------- Roland Dobbins // Sell your computer and buy a guitar. From sergevautour at yahoo.ca Tue Sep 7 13:16:16 2010 From: sergevautour at yahoo.ca (Serge Vautour) Date: Tue, 7 Sep 2010 06:16:16 -0700 (PDT) Subject: OAM and QinQ Message-ID: <478147.54222.qm@web53605.mail.re2.yahoo.com> Hello, We're working on deploying some L2 services over an MPLS network. Our model includes a CPE with OAM capabilities and QinQ from the PE to the CPE. For now we want to do simple OAM functions from CPE-CPE (no MIPs in the MPLS network). Our lab testing has shown some sort of incompatibilities between OAM and QinQ. OAM frames are encapsulated with a single VLAN tag (the SVLAN) on the CPE. When the PEs only perform SVLAN swapping, everything works fine. If we configure the PE to also perform CVLAN manipulation, it drops OAM frames. It likely does not know how to process them because they don't have a CVLAN tag. We're working with 2 CPE vendors and neither of them are able to add 2 VLAN tags to the OAM frames. Has anyone else encountered this problem? How do you get around it? One option we're looking at is to simply not perform CVLAN manipulation on the PE. This means limiting our service to customers. Our PEs are all Juniper MX boxes if it helps. Thanks, Serge From jlewis at lewis.org Tue Sep 7 14:00:01 2010 From: jlewis at lewis.org (Jon Lewis) Date: Tue, 7 Sep 2010 10:00:01 -0400 (EDT) Subject: IPv4 squatters on the move again? In-Reply-To: References: Message-ID: On Tue, 7 Sep 2010, Tero Toikkanen wrote: > Anyone hear of the SundownGroup? > > On Thursday we received an interesting RFQ from them and suspect their intentions for requesting an IP assignment isn't exactly what they state. We have already turned them down, but thought others might be interested in their activities as well. RIPE NCC has also been notified of this. > > In brief they wanted to buy colo form us: "P4 single core @ 2 Ghz, 1 GB RAM, 60 GB HD, Linux CentOS 5x.x, 10 Mbps bandwidth. A single /21 or /20 net block of IP Adresses" > > Their reason for requesting such a large address block was "As we are currently launching our WholesaleVOIP operation we are in desperate need of this IP space as part of our ARIN process we will need these ranges SWIPd to us and we will in turn renumber with ARIN and return the netblocks to you as soon as ours are allocated and routed." > > Interesting tidbits about the company we and the networking community have already found out: > > Compare http://sundowngroup.com/ and http://www.edgecast.com/ (Edgecast has been notified). They hit up one of our sales guys last week. I gave it an immediate two thumbs down. I think the sales guy knew the request was bogus and was really just showing it to me out of humor. ---------------------------------------------------------------------- Jon Lewis, MCP :) | 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 Tue Sep 7 14:00:56 2010 From: randy at psg.com (Randy Bush) Date: Tue, 07 Sep 2010 23:00:56 +0900 Subject: ISP port blocking practice In-Reply-To: References: <9C23BD21-9384-4959-AAA5-8F4A31050CE1@delong.com> <20100906132205.GA21165@panix.com> Message-ID: >> i keep hearing that, but am having a hard time finding supporting data. > > Might see the stats from http://cbl.abuseat.org - by AS. Then compare > the stats on a non port 25 filtered network (they have stats by AS) to > stats on a network that is filtered on port 25 > > The networks that are filtered on port 25 will of course have any bots > on that network originating spam by other means (social networks, > webmail scripting etc), or other types of nastiness (DDoS etc). But > you won't find them mailing out direct on port 25. > > The bots are very much there - and if the port 25 filtering were to be > taken out, you'd at once see the increase in spam volumes. thank you. this make sense. i'm more focused on the receiving end and signatures. so more of the same spam does not bother me much. but i can see that pure count would matter to many. randy From jlewis at lewis.org Tue Sep 7 14:03:00 2010 From: jlewis at lewis.org (Jon Lewis) Date: Tue, 7 Sep 2010 10:03:00 -0400 (EDT) Subject: IPv4 squatters on the move again? In-Reply-To: References: Message-ID: On Tue, 7 Sep 2010, Jeffrey Lyon wrote: > We see this all the time, usually it involves either a /20 or multiple-/xx > that change every month. If they want frequently changing IPs, it's almost certainly for spamming. I got the impression with these people they were just trying to get a bunch of SWIPs in order to go to ARIN and request as big a block of ipv4 as they could get with the intent to chop it up and resell it in pieces as soon as ARIN runs out of IPs to satisfy normal requests. ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From morrowc.lists at gmail.com Tue Sep 7 14:21:36 2010 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Tue, 7 Sep 2010 10:21:36 -0400 Subject: IPv4 squatters on the move again? In-Reply-To: References: Message-ID: On Tue, Sep 7, 2010 at 10:03 AM, Jon Lewis wrote: > On Tue, 7 Sep 2010, Jeffrey Lyon wrote: > >> We see this all the time, usually it involves either a /20 or multiple-/xx >> that change every month. > > If they want frequently changing IPs, it's almost certainly for spamming. > > I got the impression with these people they were just trying to get a bunch > of SWIPs in order to go to ARIN and request as big a block of ipv4 as they > could get with the intent to chop it up and resell it in pieces as soon as > ARIN runs out of IPs to satisfy normal requests. it used to be (~4-5 years ago) that the spammer code of 'voip service provider' was really 'we intend on raping proxies all over the planet' ... when you call them out on the random port traffic out of their pipe they point at their 'business' model that this is 'voip traffic, you know that rtp uses random ports, right?' I used to have some quick/dirty instructions for how to verify that the traffic was in fact proxy traffic, something like: 1) log traffic from the soon-to-be-ex-customer (acl logs are fine) 2) pick an external 'top talker' 3) route that /32 to a host you control 4) run NC on the port that /32 is being contacted on 5) rejoice (and shut now ex-customer interface) when you see: "CONNECT smtp.xxxxx:25" from the connection... -Chris From jgreco at ns.sol.net Tue Sep 7 14:26:54 2010 From: jgreco at ns.sol.net (Joe Greco) Date: Tue, 7 Sep 2010 09:26:54 -0500 (CDT) Subject: just seen my first IPv6 network abuse scan, In-Reply-To: <5C836A1A98186142A6BEC393FD5E2A860156DF@hal.photon.com> Message-ID: <201009071426.o87EQstR097929@aurora.sol.net> > Forgive the top posting, but Lookout is the corporate standard. It prevents you from typing at the bottom? How quaint :-) > Now, on to the topic at hand. Why would you scan the address space in > the first place? Maybe because you haven't really thought about the magnitude of the task? Maybe you feel that there's some likelihood of certain addresses being used? We've seen stupid things under IPv4, and it seems certain that IPv6 won't be immune to stupid vendor tricks. > Wouldn't it be easier to compromise a known host and > look at the ARP table? Maybe; however, it's not clear that this would be useful in generating a complete list of available hosts, though it would certainly provide the opportunity for finding more of them. > Or better yet, the router on the edge? If it's > moving packets, something on the network has mapped the MAC address to > its IP at some point. And if it isn't moving packets, then maybe nothing has. The devices on a network that are just idling and may be forgotten or unloved may be at a fairly high risk for exploits and all that. Eventually this sort of thing is going to be a problem, as the number of network- attached devices is exploding. What's going to be more interesting is the number of devices that are (re-)programmable; we'll eventually see malware networks that are able to target more than just your CPE/router device, and will have attack vectors against your ATA, your TV, your DVR, your fridge, etc. The trick is to find those devices, but even in a bad case scenario, where you might have to scan the network to find additional devices to infect, the use of scanning alone isn't practical, but scanning for devices from a given manufacturer's MAC assignment pool might be, especially if you've essentially got forever in which to do it, and certainly sitting there passively on the network snooping is very practical. The fact that many people walk around with a cell phone that has a high speed processor and lots of memory in it says a lot about where consumer electronics is going, and that we're likely to be seeing a lot more of this sort of low-level bad guy activity that is able to target a list of heterogeneous targets. ... 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 jlewis at lewis.org Tue Sep 7 14:35:33 2010 From: jlewis at lewis.org (Jon Lewis) Date: Tue, 7 Sep 2010 10:35:33 -0400 (EDT) Subject: IPv4 squatters on the move again? In-Reply-To: References: Message-ID: On Tue, 7 Sep 2010, Christopher Morrow wrote: > it used to be (~4-5 years ago) that the spammer code of 'voip service > provider' was really 'we intend on raping proxies all over the planet' > ... when you call them out on the random port traffic out of their > pipe they point at their 'business' model that this is 'voip traffic, > you know that rtp uses random ports, right?' I haven't seen that excuse/justification from customers. What I did see recently that I have to admit was very slick was a customer who claimed they were going to be doing a bunch of remote "terminals" in stores VPN'd into their dedi servers and would be streaming video from the servers to the clients. This was of course 99% BS. There was VPN involved....they used the dedi servers as VPN endpoints for their spam servers that were hosted elsewhere. When we shut them down, there was absolutely nothing incriminating of spam operations on their servers...and all they had to do was sign up for service at another hosting company, setup the VPN server, change the IPs their spam servers VPN to, and they're back in business. When sales brought me their initial request, I really didn't believe it, but I didn't have good enough cause to reject it. > I used to have some quick/dirty instructions for how to verify that > the traffic was in fact proxy traffic, something like: > 1) log traffic from the soon-to-be-ex-customer (acl logs are fine) > 2) pick an external 'top talker' > 3) route that /32 to a host you control > 4) run NC on the port that /32 is being contacted on > 5) rejoice (and shut now ex-customer interface) when you see: "CONNECT > smtp.xxxxx:25" Seems like a lot of work when you could just setup a monitor session on their port and capture a few minutes of actual spam traffic as evidence just before shutting their port. ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From ops.lists at gmail.com Tue Sep 7 14:49:08 2010 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Tue, 7 Sep 2010 20:19:08 +0530 Subject: IPv4 squatters on the move again? In-Reply-To: References: Message-ID: Yeah. This is just the way snowshoe spammers operate - GRE or VPN tunnels back to a master server, and a /24 full of output points with throwaway hostnames / reverse dns On Tue, Sep 7, 2010 at 8:05 PM, Jon Lewis wrote: > I haven't seen that excuse/justification from customers. ?What I did see > recently that I have to admit was very slick was a customer who claimed they > were going to be doing a bunch of remote "terminals" in stores VPN'd into > their dedi servers and would be streaming video from the servers to the > clients. ?This was of course 99% BS. ?There was VPN involved....they used > the dedi servers as VPN endpoints for their spam servers that were hosted > elsewhere. ?When we shut them down, there was absolutely nothing > incriminating of spam operations on their servers...and all they had to do > was sign up for service at another hosting company, setup the VPN server, > change the IPs their spam servers VPN to, and they're back in business. > When sales brought me their initial request, I really didn't believe it, but > I didn't have good enough cause to reject it. -- Suresh Ramasubramanian (ops.lists at gmail.com) From fgabut at nautile.fr Tue Sep 7 14:57:11 2010 From: fgabut at nautile.fr (=?iso-8859-15?Q?Fr=E9d=E9ric?= Gabut-Deloraine) Date: Tue, 7 Sep 2010 16:57:11 +0200 Subject: OAM and QinQ In-Reply-To: <478147.54222.qm@web53605.mail.re2.yahoo.com> References: <478147.54222.qm@web53605.mail.re2.yahoo.com> Message-ID: <20100907145711.GO30591@nautile.fr> Hello, >We're working on deploying some L2 services over an MPLS network. Our model >includes a CPE with OAM capabilities and QinQ from the PE to the CPE. For now we >want to do simple OAM functions from CPE-CPE (no MIPs in the MPLS network). > > >Our lab testing has shown some sort of incompatibilities between OAM and QinQ. >OAM frames are encapsulated with a single VLAN tag (the SVLAN) on the CPE. When >the PEs only perform SVLAN swapping, everything works fine. If we configure the >PE to also perform CVLAN manipulation, it drops OAM frames. It likely does not >know how to process them because they don't have a CVLAN tag. We're working with >2 CPE vendors and neither of them are able to add 2 VLAN tags to the OAM frames. When we tried OAM with our CPE we activated the MEP on the client subif, so the OAM frames were encapsulated in both vlan (S and C) and everything worked fine : it was Telco System CPE (T280 or T380) -- Fr?d?ric Gabut-Deloraine From peter.rudasingwa at altechstream.rw Tue Sep 7 14:09:21 2010 From: peter.rudasingwa at altechstream.rw (Peter Rudasingwa) Date: Tue, 07 Sep 2010 17:09:21 +0300 Subject: Looking Glass Message-ID: <4C864791.1050603@altechstream.rw> I have a linux (ubuntu) box and I would like to install a BGP looking glass. Are there any out there for free and how can one go about it? Is linux the best OS to use? Thanks, Peter R. From jwbensley at gmail.com Tue Sep 7 15:29:31 2010 From: jwbensley at gmail.com (James Bensley) Date: Tue, 7 Sep 2010 16:29:31 +0100 Subject: Looking Glass In-Reply-To: References: <4C864791.1050603@altechstream.rw> Message-ID: Hmm, Google says you could use http://www.zebra.org/ to set your box up as a route, and then you can just view the routes from there? Or look here; http://www.bgp4.as/tools -- Regards, James. http://www.jamesbensley.co.cc/ There are 10 kinds of people in the world; Those who understand Vigesimal, and J others...? From randy at psg.com Tue Sep 7 15:33:49 2010 From: randy at psg.com (Randy Bush) Date: Wed, 08 Sep 2010 00:33:49 +0900 Subject: Looking Glass In-Reply-To: <4C864791.1050603@altechstream.rw> References: <4C864791.1050603@altechstream.rw> Message-ID: > I have a linux (ubuntu) box and I would like to install a BGP looking > glass. Are there any out there for free and how can one go about it? > Is linux the best OS to use? i gave up. all but one required telnet access to the router(s). and the one that did ssh did so by including half of the world's archives of some abhorrent language's libraries. randy From ryanshea at google.com Tue Sep 7 15:33:05 2010 From: ryanshea at google.com (Ryan Shea) Date: Tue, 7 Sep 2010 11:33:05 -0400 Subject: Looking Glass In-Reply-To: References: <4C864791.1050603@altechstream.rw> Message-ID: The rancid package includes a perl based looking glass CGI thing. You may want to look at that and modify it to suit your needs. -Ryan On Tue, Sep 7, 2010 at 11:29 AM, James Bensley wrote: > Hmm, Google says you could use http://www.zebra.org/ to set your box > up as a route, and then you can just view the routes from there? > > Or look here; http://www.bgp4.as/tools > > -- > Regards, > James. > > http://www.jamesbensley.co.cc/ > > There are 10 kinds of people in the world; Those who understand > Vigesimal, and J others...? > > From dhill at mindcry.org Tue Sep 7 16:07:41 2010 From: dhill at mindcry.org (David Hill) Date: Tue, 7 Sep 2010 12:07:41 -0400 Subject: Looking Glass In-Reply-To: <4C864791.1050603@altechstream.rw> References: <4C864791.1050603@altechstream.rw> Message-ID: <20100907160740.GA17034@olive.mindcry.lan> On Tue, Sep 07, 2010 at 05:09:21PM +0300, Peter Rudasingwa wrote: :I have a linux (ubuntu) box and I would like to install a BGP looking :glass. Are there any out there for free and how can one go about it? :Is linux the best OS to use? : :Thanks, :Peter R. Try OpenBSD w/ OpenBGPd. It includes a looking glass cgi script. -- The longer I am out of office, the more infallible I appear to myself. -- Henry Kissinger -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available URL: From jchambers at ucla.edu Tue Sep 7 16:07:34 2010 From: jchambers at ucla.edu (Jason Chambers) Date: Tue, 07 Sep 2010 09:07:34 -0700 Subject: Looking Glass In-Reply-To: <4C864791.1050603@altechstream.rw> References: <4C864791.1050603@altechstream.rw> Message-ID: <4C866346.1080609@ucla.edu> On 9/7/10 7:09 AM, Peter Rudasingwa wrote: > I have a linux (ubuntu) box and I would like to install a BGP looking > glass. Are there any out there for free and how can one go about it? Is > linux the best OS to use? > Setup quagga [1] and write a perl script [2] to "peer" with the box. The perl script updates a database as BGP events occur. The rest is easy web programming. [1] http://www.quagga.net/ [2] http://search.cpan.org/dist/Net-BGP/ Regards, --Jason From morrowc.lists at gmail.com Tue Sep 7 16:14:12 2010 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Tue, 7 Sep 2010 12:14:12 -0400 Subject: IPv4 squatters on the move again? In-Reply-To: References: Message-ID: On Tue, Sep 7, 2010 at 10:35 AM, Jon Lewis wrote: > On Tue, 7 Sep 2010, Christopher Morrow wrote: >> I used to have some quick/dirty instructions for how to verify that >> the traffic was in fact proxy traffic, something like: >> 1) log traffic from the soon-to-be-ex-customer (acl logs are fine) >> 2) pick an external 'top talker' >> 3) route that /32 to a host you control >> 4) run NC on the port that /32 is being contacted on >> 5) rejoice (and shut now ex-customer interface) when you see: "CONNECT >> smtp.xxxxx:25" > > Seems like a lot of work when you could just setup a monitor session on > their port and capture a few minutes of actual spam traffic as evidence just > before shutting their port. sorry, can't do monitor on a ptp oc-12 link :( From jlewis at lewis.org Tue Sep 7 17:23:15 2010 From: jlewis at lewis.org (Jon Lewis) Date: Tue, 7 Sep 2010 13:23:15 -0400 (EDT) Subject: whois at rest Message-ID: More often than not today the only replies I've been getting back from the ARIN whois servers is: ERROR 503: Unable to service request due to high volume. Is there really high volume today, or is the new restful thing broken again? ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From tglassey at earthlink.net Tue Sep 7 17:28:11 2010 From: tglassey at earthlink.net (todd glassey) Date: Tue, 07 Sep 2010 10:28:11 -0700 Subject: IPv4 squatters on the move again? In-Reply-To: References: Message-ID: <4C86762B.2090004@earthlink.net> On 9/7/2010 1:24 AM, Tero Toikkanen wrote: > Anyone hear of the SundownGroup? yes it is the fictional name - it pertains to a covert operations group from a Tommy Lee Scott & Gene Hackman movie called "The Package". As I recall "Operation Sundown" was the op name and it was a bunch of assassins but there were a number of instances used. In this instance the SundownGroup (or Sundowner Group) was a specialized Army strikeforce who was about to assassinate the Russian Prime Minister or somesuch. TGlassey > > On Thursday we received an interesting RFQ from them and suspect their intentions for requesting an IP assignment isn't exactly what they state. We have already turned them down, but thought others might be interested in their activities as well. RIPE NCC has also been notified of this. > > In brief they wanted to buy colo form us: "P4 single core @ 2 Ghz, 1 GB RAM, 60 GB HD, Linux CentOS 5x.x, 10 Mbps bandwidth. A single /21 or /20 net block of IP Adresses" > > Their reason for requesting such a large address block was "As we are currently launching our WholesaleVOIP operation we are in desperate need of this IP space as part of our ARIN process we will need these ranges SWIPd to us and we will in turn renumber with ARIN and return the netblocks to you as soon as ours are allocated and routed." > > Interesting tidbits about the company we and the networking community have already found out: > > Compare http://sundowngroup.com/ and http://www.edgecast.com/ (Edgecast has been notified). > > The contact address is the same as National University Nevada (nu.edu): > > Sundown Capital Management LLC > 2850 Horizon Ridge Parkway > Henderson, Nevada 89052 > United States of America > > They also have virtually no Internet presence (http://www.google.com/search?q=%22Sundown+Capital+Management%22) > The first result shows them as a franchicing company with contact address in California: http://www.scribd.com/doc/14385124/QFA-Unit-Final-PDF-File-of-32709-FDD-With-Exhibits > > I'd say this case is pretty obvious... > > With Kind Regards, > -- > Tero Toikkanen > Nebula Oy Internet Services > > > > > No virus found in this incoming message. > Checked by AVG - www.avg.com > Version: 9.0.851 / Virus Database: 271.1.1/3118 - Release Date: 09/06/10 11:34:00 > -- //----------------------------------------------------------------- This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. From sethm at rollernet.us Tue Sep 7 17:41:17 2010 From: sethm at rollernet.us (Seth Mattinen) Date: Tue, 07 Sep 2010 10:41:17 -0700 Subject: whois at rest In-Reply-To: References: Message-ID: <4C86793D.60800@rollernet.us> On 9/7/10 10:23 AM, Jon Lewis wrote: > More often than not today the only replies I've been getting back from > the ARIN whois servers is: > > ERROR 503: Unable to service request due to high volume. > > Is there really high volume today, or is the new restful thing broken > again? > Shhhh, it's an improvement over the old ways. ~Seth From Valdis.Kletnieks at vt.edu Tue Sep 7 18:48:19 2010 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Tue, 07 Sep 2010 14:48:19 -0400 Subject: just seen my first IPv6 network abuse scan, is this the startfor more? In-Reply-To: Your message of "Tue, 07 Sep 2010 09:03:12 EDT." <5C836A1A98186142A6BEC393FD5E2A860156DF@hal.photon.com> References: <6AD92173-D423-49E4-81BF-7E141249222B@arbor.net> <3238DBCC-0258-47EA-B804-D8E254492182@delong.com> <6A6F346A-2AA6-47E4-92D2-967627CE1202@cs.columbia.edu> <5C836A1A98186142A6BEC393FD5E2A860156DF@hal.photon.com> Message-ID: <11128.1283885299@localhost> On Tue, 07 Sep 2010 09:03:12 EDT, Jamie Bowden said: > Now, on to the topic at hand. Why would you scan the address space in > the first place? Wouldn't it be easier to compromise a known host and > look at the ARP table? Or better yet, the router on the edge? If it's > moving packets, something on the network has mapped the MAC address to > its IP at some point. Remember that although there are some truly scary black hats out there, the vast majority of them are even less technically savvy than your average trainee banana eater, and will do things so mind-bogglingly stupid that you have to roll a saving throw at -5 to disbelieve ;) True incident I worked on sometime last century: I get called about this AIX box, it's been hosed for "a while", and they can't login to run the one application they ran literally once a year that they kept this box around for. Preliminary indications are /etc/passwd is scrozzled. So I boot off an install CD and start looking. Takes about 10 seconds to figure out the box was hacked. I'm amazed - the machine wasn't fully hardened, and was *way* behind on patches. On the other hand, it *was* at least tcp-wrappered, and the attacker managed to fingerprint it as an AIX box without setting any of the wrappers off. The guy whacked it with either a telnetd or ftpd exploit, and by looking at process accounting, I was able to verify it worked on the *first* try. I'm suitably impressed at this point - even 15 years ago, AIX wasn't common enough that most black hats kept exploits in their back pockets (much less know enough to use them on the first try). Guy whacks the box on the very first try, and then it gets interesting. Guy says 'cat > /etc/paswd^[[D^[[Dswd' because he doesn't realize his exploit rootshell doesn't have line editing. Guy tries to get in on a second session, realizes his attempt to set a root backdoor didn't work, so he does this for his second try: cat > /etc/passwd foo::1:0::/: ^D Yep. 1. Not zero. And > not >>. So then when he tries to come in via telnet again, inetd won't do it because inetd.conf says 'root' and there's no 'root' in /etc/passwd anymore. Actual forensics work: about 15 mins. Convincing myself it was a damned lucky ankle-biter and not a uberhacker leaving a false trail: most of an 8-hour day. Or as I said on another list - "Sometimes the data makes a lot more sense if you ask yourself 'What if the Three Stooges were hackers?'". And there's no indication that the bell curve of black hat clue levels has shifted any since last century. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From lists at quux.de Tue Sep 7 20:09:06 2010 From: lists at quux.de (Jens Link) Date: Tue, 07 Sep 2010 22:09:06 +0200 Subject: Looking Glass In-Reply-To: (James Bensley's message of "Tue, 7 Sep 2010 16:29:31 +0100") References: <4C864791.1050603@altechstream.rw> Message-ID: <87aantwc2l.fsf@oban.berlin.quux.de> James Bensley writes: > Hmm, Google says you could use http://www.zebra.org/ to set your box > up as a route, and then you can just view the routes from there? Aehm, Zebra is dead. Quagga it the successor. Last change date on zebra.org website is 5 years old. Jens -- ------------------------------------------------------------------------- | Foelderichstr. 40 | 13595 Berlin, Germany | +49-151-18721264 | | http://blog.quux.de | jabber: jenslink at guug.de | ------------------- | ------------------------------------------------------------------------- From ken at sizone.org Tue Sep 7 20:19:58 2010 From: ken at sizone.org (Ken Chase) Date: Tue, 7 Sep 2010 16:19:58 -0400 Subject: yahoo crawlers hammering us Message-ID: <20100907201958.GM24371@sizone.org> So i guess im new at internets as my colleagues told me because I havent gone around to 30-40 systems I control (minus customer self-managed gear) and installed a restrictive robots.txt everywhere to make the web less useful to everyone. Does that really mean that a big outfit like yahoo should be expected to download stuff at high speed off my customers servers? For varying values of 'high speed', ~500K/s (4Mbps+) for a 3 gig file is kinda... a bit harsh. Especially for an exe a user left exposed in a webdir, thats possibly (C) software and shouldnt have been there (now removed by customer, some kinda OS boot cd/toolset thingy). This makes it look like Yahoo is actually trafficking in pirated software, but that's kinda too funny to expect to be true, unless some yahoo tech decided to use that IP/server @yahoo for his nefarious activity, but there are better sites than my customer's box to get his 'juarez'. At any rate: >From Address To Address Proto Bytes CPS ============================================================================================================================================================================================== 67.196.xx.xx..80 67.195.112.151..44507 tcp 14872000 523000 $ host 67.195.112.151 8.8.8.8 151.112.195.67.in-addr.arpa domain name pointer b3091122.crawl.yahoo.net. CIDR: 67.195.0.0/16 NetName: A-YAHOO-US8 so that's yahoo, or really well spoofed. Is this expected/my own fault or what? A number of years ago, there were 1000s of videos on a customer site (training for elderly care, extremely exciting stuff for someone into -1-day movies to post on torrent sites). Customer called me to say his bw was gone, and I checked and found 12 yahoo crawlers hitting the site at 300K/s each (~30Mbps +) downloading all the videos. This was all the more injurious as it was only 2004 and bandwidth was more than $1/mbps back then. I did the really crass thing and nullrouted the whole /20 or whatever they were on per ARIN. It was the new-at-the-time video.yahoo.com search engine coming to index the whole site. I suppose they cant be too slow about it, or they'll never index a whole webfull of videos this century, but still, 12x 300K/s in 2004? (At the time Rasmus though it was kinda funny. I do too, now.) /kc -- Ken Chase - ken at heavycomputing.ca - +1 416 897 6284 - Toronto CANADA Heavy Computing - Clued bandwidth, colocation and managed linux VPS @151 Front St. W. From jack at crepinc.com Tue Sep 7 20:23:57 2010 From: jack at crepinc.com (Jack Carrozzo) Date: Tue, 7 Sep 2010 16:23:57 -0400 Subject: Looking Glass In-Reply-To: <87aantwc2l.fsf@oban.berlin.quux.de> References: <4C864791.1050603@altechstream.rw> <87aantwc2l.fsf@oban.berlin.quux.de> Message-ID: FWIW Quagga works fine as a looking glass if you don't mind the telnet interface. Though, if you really want ssh, you could make a user on the machine whose login script runs 'vtysh' and logs out on exit, however it's admittedly less elegant. -Jack Carrozzo On Tue, Sep 7, 2010 at 4:09 PM, Jens Link wrote: > James Bensley writes: > > > Hmm, Google says you could use http://www.zebra.org/ to set your box > > up as a route, and then you can just view the routes from there? > > Aehm, Zebra is dead. Quagga it the successor. > > Last change date on zebra.org website is 5 years old. > > Jens > -- > ------------------------------------------------------------------------- > | Foelderichstr. 40 | 13595 Berlin, Germany | +49-151-18721264 | > | http://blog.quux.de | jabber: jenslink at guug.de | ------------------- | > ------------------------------------------------------------------------- > > From leslie at craigslist.org Tue Sep 7 20:42:42 2010 From: leslie at craigslist.org (Leslie) Date: Tue, 07 Sep 2010 13:42:42 -0700 Subject: yahoo crawlers hammering us In-Reply-To: <20100907201958.GM24371@sizone.org> References: <20100907201958.GM24371@sizone.org> Message-ID: <4C86A3C2.9050603@craigslist.org> That speed doesn't seem too bad to me - robots.txt is our friend when one had bandwidth limitations. Leslie On 9/7/10 1:19 PM, Ken Chase wrote: > So i guess im new at internets as my colleagues told me because I havent gone > around to 30-40 systems I control (minus customer self-managed gear) and > installed a restrictive robots.txt everywhere to make the web less useful to > everyone. > > Does that really mean that a big outfit like yahoo should be expected to > download stuff at high speed off my customers servers? For varying values of > 'high speed', ~500K/s (4Mbps+) for a 3 gig file is kinda... a bit harsh. > Especially for an exe a user left exposed in a webdir, thats possibly (C) > software and shouldnt have been there (now removed by customer, some kinda OS boot > cd/toolset thingy). > > This makes it look like Yahoo is actually trafficking in pirated software, but > that's kinda too funny to expect to be true, unless some yahoo tech decided to > use that IP/server @yahoo for his nefarious activity, but there are better sites > than my customer's box to get his 'juarez'. > > At any rate: > >> From Address To Address Proto Bytes CPS > ============================================================================================================================================================================================== > 67.196.xx.xx..80 67.195.112.151..44507 tcp 14872000 523000 > > $ host 67.195.112.151 8.8.8.8 > > 151.112.195.67.in-addr.arpa domain name pointer b3091122.crawl.yahoo.net. > > CIDR: 67.195.0.0/16 > NetName: A-YAHOO-US8 > > so that's yahoo, or really well spoofed. > > Is this expected/my own fault or what? > > A number of years ago, there were 1000s of videos on a customer site (training > for elderly care, extremely exciting stuff for someone into -1-day movies to > post on torrent sites). Customer called me to say his bw was gone, and I > checked and found 12 yahoo crawlers hitting the site at 300K/s each (~30Mbps > +) downloading all the videos. This was all the more injurious as it was only > 2004 and bandwidth was more than $1/mbps back then. I did the really crass > thing and nullrouted the whole /20 or whatever they were on per ARIN. It was > the new-at-the-time video.yahoo.com search engine coming to index the whole > site. I suppose they cant be too slow about it, or they'll never index a whole > webfull of videos this century, but still, 12x 300K/s in 2004? (At the time > Rasmus though it was kinda funny. I do too, now.) > > /kc From nathan at robotics.net Tue Sep 7 22:35:48 2010 From: nathan at robotics.net (Nathan Stratton) Date: Tue, 7 Sep 2010 17:35:48 -0500 (CDT) Subject: Looking Glass In-Reply-To: References: <4C864791.1050603@altechstream.rw> <87aantwc2l.fsf@oban.berlin.quux.de> Message-ID: On Tue, 7 Sep 2010, Jack Carrozzo wrote: > FWIW Quagga works fine as a looking glass if you don't mind the telnet > interface. Though, if you really want ssh, you could make a user on the > machine whose login script runs 'vtysh' and logs out on exit, however it's > admittedly less elegant. Anyone know of a good http looking glass that works with quagga? ><> Nathan Stratton CTO, BlinkMind, Inc. nathan at robotics.net nathan at blinkmind.com http://www.robotics.net http://www.blinkmind.com From jack at crepinc.com Wed Sep 8 00:43:15 2010 From: jack at crepinc.com (Jack Carrozzo) Date: Tue, 7 Sep 2010 20:43:15 -0400 Subject: Looking Glass In-Reply-To: References: <4C864791.1050603@altechstream.rw> <87aantwc2l.fsf@oban.berlin.quux.de> Message-ID: On Tue, Sep 7, 2010 at 6:35 PM, Nathan Stratton wrote: > > Anyone know of a good http looking glass that works with quagga? > I realize this is probably more hacking than you want to do, but Quagga can expose much of it's info via SNMP. Thus it would be fairly trivial to write an http front end to it if you were so motivated (or, have some interns on hand without enough to do). -Jack Carrozzo From pstewart at nexicomgroup.net Wed Sep 8 00:52:36 2010 From: pstewart at nexicomgroup.net (Paul Stewart) Date: Tue, 7 Sep 2010 20:52:36 -0400 Subject: Inline Traffic Management / Tracking - Usage Based Billing Message-ID: Hi there... We are examining several options currently for appliances/devices that sit inline (most likely) and can perform all/some of these services: -Track customer usage and generate monthly reports based on username (PPPOE) or cable MAC (DHCP) - and doesn't require any changes to our Radius infrastructure. In other words, it has the smarts to gather the username/IP combination along with the Radius Start/Stop to do accurate reporting. -Throttling of certain services/applications at certain times of day (looking for fairly extensive options here including ability to take total link capacity into account - reasonably dynamic) -24X7X365 support and hardware coverage (no next business day shipping - 4 hour response onsite kind of stuff) -Clustering/HA options -Centralized management/reporting This is NOT an open invitation for sales people to contact me - I'm asking here for operational feedback with likes/dislikes. I can appreciate if most folks prefer to reply offline. We have trialled the Arbor solution to date but that is the only comparison we have so far. Thanks, Paul Stewart From ryanshea at google.com Wed Sep 8 01:13:51 2010 From: ryanshea at google.com (Ryan Shea) Date: Tue, 7 Sep 2010 21:13:51 -0400 Subject: Looking Glass In-Reply-To: References: <4C864791.1050603@altechstream.rw> <87aantwc2l.fsf@oban.berlin.quux.de> Message-ID: *Install quagga and rancid sudo apt-get install rancid rancid-cgi quagga *Enable bgpd in /etc/quagga/daemons *Hook up your Quagga.conf with all the fun bgp configuration bits. Search on the intarwebs or man pages for configuration details. *Set up a user with vtysh as their shell. *Set up the rancid cloginrc file with the login stuff for your quagga router using the user with vtysh access. To Randy's point, it can certainly do ssh... but Rancid certainly uses "some abhorrent language's libraries". *Edit the configuration for the looking glass CGI /etc/rancid/lg.conf *Tweak out the CGI to be less horrible. *Profit. -Ryan On Tue, Sep 7, 2010 at 6:35 PM, Nathan Stratton wrote: > > On Tue, 7 Sep 2010, Jack Carrozzo wrote: > > FWIW Quagga works fine as a looking glass if you don't mind the telnet >> interface. Though, if you really want ssh, you could make a user on the >> machine whose login script runs 'vtysh' and logs out on exit, however it's >> admittedly less elegant. >> > > Anyone know of a good http looking glass that works with quagga? > > <> >> > Nathan Stratton CTO, BlinkMind, Inc. > nathan at robotics.net nathan at blinkmind.com > http://www.robotics.net http://www.blinkmind.com > > From craig at codestorm.org Wed Sep 8 03:16:38 2010 From: craig at codestorm.org (Craig Van Tassle) Date: Tue, 7 Sep 2010 22:16:38 -0500 Subject: Looking Glass In-Reply-To: <4C864791.1050603@altechstream.rw> References: <4C864791.1050603@altechstream.rw> Message-ID: <20100907221638.4175a775@dragon.codestorm.org> On Tue, 07 Sep 2010 17:09:21 +0300 Peter Rudasingwa wrote: > I have a linux (ubuntu) box and I would like to install a BGP looking > glass. Are there any out there for free and how can one go about it? > Is linux the best OS to use? > > Thanks, > Peter R. I have used Mult-Router Looking Glass in the past and it's been pretty good. http://freshmeat.net/projects/mrlg4php/ -- -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From bonomi at mail.r-bonomi.com Wed Sep 8 05:05:04 2010 From: bonomi at mail.r-bonomi.com (Robert Bonomi) Date: Wed, 8 Sep 2010 00:05:04 -0500 (CDT) Subject: ISP port blocking practice Message-ID: <201009080505.o88554WC003740@mail.r-bonomi.com> > From nanog-bounces+bonomi=mail.r-bonomi.com at nanog.org Tue Sep 7 15:15:13 2010 > Date: Mon, 6 Sep 2010 19:55:06 -0500 > From: Brett Frankenberger > To: deleskie at gmail.com > Subject: Re: ISP port blocking practice > Cc: NANOG list > > On Mon, Sep 06, 2010 at 10:38:15PM +0000, deleskie at gmail.com wrote: > > > > Having worked in past @ 3 large ISPs with residential customer pools > > I can tell you we saw a very direct drop in spam issues when we > > blocked port 25. > > No one is disputing that. Or, at least, I'm not disputing that. I'm > questioning whether or not the *Internet* has experienced any decrease > in aggregate spam as a result of ISPs blocking port 25. Did the spam > you blocked disappear, or did it all get sent some other way? _I_ can't say about 'some other way', but, on average, between 1/4 and 1/3 of the all the incoming spam at my personal server is 'direct to MX', that would have been been, at least 'slowed a little bit' by "classical, dumb" port 25 blocking. Now, a *smart* port 25 enforcer -- where traffic outbound to port 25 was selectively NATted into a 'data sink' -- something that replies "200" to everything up to the DATA command, and _always_ gives a 5xy response to that (with text like "you must send outgoing mail though our server'), WOULD kill the traffic dead. Or, at least, force the spamware writers to start paying attention to SMTP response codes, *IF* they wanted to count deliveries. All available evidence says that -most- spammers/spamware/ botnets pay no attention to such -- as established by the effectiveness of GreetPause, and greylisting. It is worth noting that this kind of 'smart' port 25 blocking would also automatically identify 'infected' machines, and by consulting the records of who is corrently on that IP address, tell _which_customer_ is has the infected machine, *AND* notify the customer of their problem. all without any need for any (expensive) human involvement. Aside, if spamware _had_ to 'obey the rules' of SMTP transactions, regarding reading reply codes, that alone would probalbly reduce by 50%, if not more, the aggregate sending _capacity_ of the world's spam sources. Whether that would make much of a difference, I don''t know -- depnds on how far existing 'capacity' exeeeds existing usage/demand.133-136 140 142-145 147 From harry.nanog at harry.lu Wed Sep 8 05:54:55 2010 From: harry.nanog at harry.lu (Harry Strongburg) Date: Wed, 8 Sep 2010 05:54:55 +0000 Subject: yahoo crawlers hammering us In-Reply-To: <20100907201958.GM24371@sizone.org> References: <20100907201958.GM24371@sizone.org> Message-ID: <20100908055455.GA3771@harry.lu> On Tue, Sep 07, 2010 at 04:19:58PM -0400, Ken Chase wrote: > This makes it look like Yahoo is actually trafficking in pirated software, but > that's kinda too funny to expect to be true, unless some yahoo tech decided to > use that IP/server @yahoo for his nefarious activity, but there are better sites > than my customer's box to get his 'juarez'. It's not uncommon at all for a web-spider to find large files and download them. I don't think there's some conspiracy at Yahoo to find warez; they are just opperating as a normal spider, indexing the Internet. > ~500K/s (4Mbps+) for a 3 gig file is kinda... a bit harsh. What speed would you like a spider to download at? You could configure the speeds to Yahoo's blocks server-side if you care enough. Ideally, request your customer doesn't throw large programs on there if you're concerned about bandwidth. 4 Mb/s isn't abnormal at all for a spider, and especially on a larger file. > Is this expected/my own fault or what? A little bit of both :) From artem at aws-net.org.ua Wed Sep 8 05:58:59 2010 From: artem at aws-net.org.ua (Artyom Viklenko) Date: Wed, 08 Sep 2010 08:58:59 +0300 Subject: Looking Glass In-Reply-To: References: <4C864791.1050603@altechstream.rw> <87aantwc2l.fsf@oban.berlin.quux.de> Message-ID: <4C872623.9090305@aws-net.org.ua> 08.09.2010 01:35, Nathan Stratton ?????: > > On Tue, 7 Sep 2010, Jack Carrozzo wrote: > >> FWIW Quagga works fine as a looking glass if you don't mind the telnet >> interface. Though, if you really want ssh, you could make a user on the >> machine whose login script runs 'vtysh' and logs out on exit, however >> it's >> admittedly less elegant. > > Anyone know of a good http looking glass that works with quagga? Try http://wiki.version6.net/LG > >> <> > Nathan Stratton CTO, BlinkMind, Inc. > nathan at robotics.net nathan at blinkmind.com > http://www.robotics.net http://www.blinkmind.com > -- Sincerely yours, Artyom Viklenko. ------------------------------------------------------- artem at aws-net.org.ua | http://www.aws-net.org.ua/~artem artem at viklenko.net | ================================ FreeBSD: The Power to Serve - http://www.freebsd.org From mpetach at netflight.com Wed Sep 8 07:04:07 2010 From: mpetach at netflight.com (Matthew Petach) Date: Wed, 8 Sep 2010 00:04:07 -0700 Subject: yahoo crawlers hammering us In-Reply-To: <20100907201958.GM24371@sizone.org> References: <20100907201958.GM24371@sizone.org> Message-ID: On Tue, Sep 7, 2010 at 1:19 PM, Ken Chase wrote: > So i guess im new at internets as my colleagues told me because I havent gone > around to 30-40 systems I control (minus customer self-managed gear) and > installed a restrictive robots.txt everywhere to make the web less useful to > everyone. > > Does that really mean that a big outfit like yahoo should be expected to > download stuff at high speed off my customers servers? For varying values of > 'high speed', ~500K/s (4Mbps+) for a 3 gig file is kinda... a bit harsh. > Especially for an exe a user left exposed in a webdir, thats possibly (C) > software and shouldnt have been there (now removed by customer, some kinda OS boot > cd/toolset thingy). The large search engines like Google, Bing, and Yahoo do try to be good netizens, and not have multiple crawlers hitting a given machine at the same time, and they put delays between each request, to be nice to the CPU load and bandwidth of the machines; but I don't think any of the crawlers explicitly make efforts to slow down single-file-fetches. Ordinarily, the transfer speed doesn't matter as much for a single URL fetch, as it lasts a very short period of time, and then the crawler waits before doing another fetch from the same machine/same site, reducing the load on the machine being crawled. I doubt any of them rate-limit down individual fetches, though, so you're likely to see more of an impact when serving up large single files like that. I *am* curious--what makes it any worse for a search engine like Google to fetch the file than any other random user on the Internet? In either case, the machine doing the fetch isn't going to rate-limit the fetch, so you're likely to see the same impact on the machine, and on the bandwidth. > Is this expected/my own fault or what? Well...if you put a 3GB file out on the web, unprotected, you've got to figure at some point someone's going to stumble across it and download it to see what it is. If you don't want to be serving it, it's probably best to not put it up on an unprotected web server where people can get to it. ^_^; Speaking purely for myself in this manner, as a random user who sometimes sucks down random files left in unprotected directories, just to see what they are. Matt (now where did I put that antivirus software again...?) From williams.bruce at gmail.com Wed Sep 8 09:21:31 2010 From: williams.bruce at gmail.com (Bruce Williams) Date: Wed, 8 Sep 2010 02:21:31 -0700 Subject: yahoo crawlers hammering us In-Reply-To: References: <20100907201958.GM24371@sizone.org> Message-ID: > I *am* curious--what makes it any worse for a search engine like Google > to fetch the file than any other random user on the Internet Possibly because that other user is who the customer pays have their content delivered to? Bruce Williams ----------------------------------------------------------------------------------------------------------------------------- You can close your eyes to things you don't want to see, but you can't close your heart to the things you don't want to feel. On Wed, Sep 8, 2010 at 12:04 AM, Matthew Petach wrote: > On Tue, Sep 7, 2010 at 1:19 PM, Ken Chase wrote: >> So i guess im new at internets as my colleagues told me because I havent gone >> around to 30-40 systems I control (minus customer self-managed gear) and >> installed a restrictive robots.txt everywhere to make the web less useful to >> everyone. >> >> Does that really mean that a big outfit like yahoo should be expected to >> download stuff at high speed off my customers servers? For varying values of >> 'high speed', ~500K/s (4Mbps+) for a 3 gig file is kinda... a bit harsh. >> Especially for an exe a user left exposed in a webdir, thats possibly (C) >> software and shouldnt have been there (now removed by customer, some kinda OS boot >> cd/toolset thingy). > > The large search engines like Google, Bing, and Yahoo do try to be good > netizens, and not have multiple crawlers hitting a given machine at the same > time, and they put delays between each request, to be nice to the CPU load > and bandwidth of the machines; but I don't think any of the crawlers explicitly > make efforts to slow down single-file-fetches. ?Ordinarily, the transfer speed > doesn't matter as much for a single URL fetch, as it lasts a very short period > of time, and then the crawler waits before doing another fetch from the same > machine/same site, reducing the load on the machine being crawled. ?I doubt > any of them rate-limit down individual fetches, though, so you're likely to see > more of an impact when serving up large single files like that. > > I *am* curious--what makes it any worse for a search engine like Google > to fetch the file than any other random user on the Internet? ?In either case, > the machine doing the fetch isn't going to rate-limit the fetch, so > you're likely > to see the same impact on the machine, and on the bandwidth. > >> Is this expected/my own fault or what? > > Well...if you put a 3GB file out on the web, unprotected, you've got to figure > at some point someone's going to stumble across it and download it to see > what it is. ?If you don't want to be serving it, it's probably best to > not put it up > on an unprotected web server where people can get to it. ?^_^; > > Speaking purely for myself in this manner, as a random user who sometimes > sucks down random files left in unprotected directories, just to see what they > are. > > Matt > (now where did I put that antivirus software again...?) > > From nathan at atlasnetworks.us Wed Sep 8 10:24:38 2010 From: nathan at atlasnetworks.us (Nathan Eisenberg) Date: Wed, 8 Sep 2010 10:24:38 +0000 Subject: yahoo crawlers hammering us In-Reply-To: References: <20100907201958.GM24371@sizone.org> Message-ID: <8C26A4FDAE599041A13EB499117D3C28164AC3A7@ex-mb-1.corp.atlasnetworks.us> > Possibly because that other user is who the customer pays have their content > delivered to? Customers don't want to deliver their content to search engines? That seems silly. http://www.last.fm/robots.txt (Note the final 3 disallow lines...) From williams.bruce at gmail.com Wed Sep 8 10:35:17 2010 From: williams.bruce at gmail.com (Bruce Williams) Date: Wed, 8 Sep 2010 03:35:17 -0700 Subject: yahoo crawlers hammering us In-Reply-To: <8C26A4FDAE599041A13EB499117D3C28164AC3A7@ex-mb-1.corp.atlasnetworks.us> References: <20100907201958.GM24371@sizone.org> <8C26A4FDAE599041A13EB499117D3C28164AC3A7@ex-mb-1.corp.atlasnetworks.us> Message-ID: > > Customers don't want to deliver their content to search engines? ?That seems silly. > Got me there! :-) Bruce Williams From thomas.mangin at exa-networks.co.uk Wed Sep 8 11:15:57 2010 From: thomas.mangin at exa-networks.co.uk (Thomas Mangin) Date: Wed, 8 Sep 2010 12:15:57 +0100 Subject: Fwd: [swinog] IP address are now personal data References: Message-ID: FYI Begin forwarded message: > From: Pascal Gloor > Date: 8 September 2010 11:25:18 GMT+01:00 > To: "swinog at swinog.ch" > Subject: [swinog] IP address are now personal data > > Dear community, > > something important for us happened today that may have some impact on our daily business. > > Our Federal Court just decided that IP addresses are personal data and the federal law about data protection must also be followed also for IP addresses. Collecting IP adresses for private (corporate) investigation is not legal. Companies like Logistep have to stop their activities imm?diately! > > As ISP be carefull not to publish traffic information containing IP addresses. > > see you, > Pascal > > _______________________________________________ > swinog mailing list > swinog at lists.swinog.ch > http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog From jared at puck.nether.net Wed Sep 8 12:56:35 2010 From: jared at puck.nether.net (Jared Mauch) Date: Wed, 8 Sep 2010 08:56:35 -0400 Subject: [swinog] IP address are now personal data In-Reply-To: References: Message-ID: <69BD9231-E6EF-4FBD-993C-7DA3782244F1@puck.nether.net> This is something that has been expected out of the EU as it relates to PII for a few years now. - jared On Sep 8, 2010, at 7:15 AM, Thomas Mangin wrote: > FYI > > Begin forwarded message: > >> From: Pascal Gloor >> Date: 8 September 2010 11:25:18 GMT+01:00 >> To: "swinog at swinog.ch" >> Subject: [swinog] IP address are now personal data >> >> Dear community, >> >> something important for us happened today that may have some impact on our daily business. >> >> Our Federal Court just decided that IP addresses are personal data and the federal law about data protection must also be followed also for IP addresses. Collecting IP adresses for private (corporate) investigation is not legal. Companies like Logistep have to stop their activities imm?diately! >> >> As ISP be carefull not to publish traffic information containing IP addresses. >> >> see you, >> Pascal >> >> _______________________________________________ >> swinog mailing list >> swinog at lists.swinog.ch >> http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog > > From jeroen at unfix.org Wed Sep 8 13:14:31 2010 From: jeroen at unfix.org (Jeroen Massar) Date: Wed, 08 Sep 2010 15:14:31 +0200 Subject: [swinog] IP address are now personal data In-Reply-To: <69BD9231-E6EF-4FBD-993C-7DA3782244F1@puck.nether.net> References: <69BD9231-E6EF-4FBD-993C-7DA3782244F1@puck.nether.net> Message-ID: <4C878C37.9080806@unfix.org> On 2010-09-08 14:56, Jared Mauch wrote: > This is something that has been expected out of the EU as it relates > to PII for a few years now. Fortunately Switzerland is NOT part of the European Union, even though it seems there are a lot of influences and political pulls.... Court verdict (german): http://www.bger.ch/index/press/press-inherit-template/press-mitteilungen.htm?id=tf1 Greets, Jeroen From jared at puck.nether.net Wed Sep 8 13:26:57 2010 From: jared at puck.nether.net (Jared Mauch) Date: Wed, 8 Sep 2010 09:26:57 -0400 Subject: [swinog] IP address are now personal data In-Reply-To: <4C878C37.9080806@unfix.org> References: <69BD9231-E6EF-4FBD-993C-7DA3782244F1@puck.nether.net> <4C878C37.9080806@unfix.org> Message-ID: On Sep 8, 2010, at 9:14 AM, Jeroen Massar wrote: > On 2010-09-08 14:56, Jared Mauch wrote: >> This is something that has been expected out of the EU as it relates >> to PII for a few years now. > > Fortunately Switzerland is NOT part of the European Union, even though > it seems there are a lot of influences and political pulls.... Sorry for dragging you into some of the other European folks policy chats... (But I've been expecting a decision of this sort out of the EU, and other pan-european nations for about 2-3 years). > Court verdict (german): > http://www.bger.ch/index/press/press-inherit-template/press-mitteilungen.htm?id=tf1 This looks a bit more limited than I originally thought, it seems (unless I'm misreading it) the issue has more to do with disclosure (to end-user) that they were being investigated. (similar to having your home be searched by police when you are not around and them not leaving a copy of the warrant, nor any hints your home has been searched). - Jared From kompella at cs.purdue.edu Wed Sep 8 13:51:27 2010 From: kompella at cs.purdue.edu (Ramana Kompella) Date: Wed, 8 Sep 2010 09:51:27 -0400 Subject: CFP: COMSNETS 2011 (Deadline in five days!) Message-ID: <20100908135127.GA7356@tirupati> *** APOLOGIES IF YOUR RECEIVED MULTIPLE COPIES OF THE CFP *** COMSNETS 2011 The THIRD International Conference on COMunication Systems and NETworks January 4-8, 2011, Bangalore, India http://www.comsnets.org (In Co-operation with ACM SIGMOBILE) (Technically Co-Sponsored by IEEE COMSOC) The Third International Conference on COMmunication Systems and NETworkS (COMSNETS) will be held in Bangalore, India, from 4 January 2011 to 8 January 2011. COMSNETS is a premier international conference dedicated to addressing advances in Networking and Communications Systems, and Telecommunications services. The goal of the conference is to create a world-class gathering of researchers from academia and industry, practitioners, business leaders, intellectual property experts, and venture capitalists, providing a forum for discussing cutting edge research, and directions for new innovative business and technology. The conference will include a highly selective technical program consisting of parallel tracks of submitted papers, a small set of invited papers on important and timely topics from well-known leaders in the field, and poster sessions of work in progress. Focused workshops and panel discussions will be held on emerging topics to allow for a lively exchange of ideas. International business and government leaders will be invited to share their perspectives, thus complementing the technical program. Papers describing original research work and practical experiences/experimental results are solicited on topics including, but not limited to: Topics of Interest ------------------ Internet Architecture and Protocols Network-based Applications Video Distribution (IPTV, Mobile Video, Video on Demand) Network Operations and Management Broadband and Cellular Networks (3G/4G, WiMAX/LTE) Mesh, Sensor and PAN Networks Communication Software (Cognitive Radios, DSA, SDR) Wireless Operating Systems and Mobile Platforms Peer-to-peer Networking Cognitive Radio and White Space Networking Optical Networks Network Security & Cyber Security Technologies Cloud and Utility computing Storage Area Networks Next Generation Web Architectures Vehicular Networking Energy-Efficient Networking Network Science and Emergent Behavior in Socio-Technical Networks Social Networking Analysis, Middleware and Applications Networking Technologies for Smart Energy Grids Disruption/Delay Tolerant Networking Conference Highlights --------------------- Conference Inaugural Speaker: Prof. Pravin Varaiya, U. C. Berkeley, USA Banquet speaker: Dr. Rajeev Rastogi, Yahoo Research, India Keynote Speakers: Prof. Don Towsley, U. Mass Amherst, USA Dr. Pravin Bhagwat, AirTight Networks, India Dr. Jean Bolot, Sprint, USA Workshops WISARD (4, 5 Jan) NetHealth (4 Jan) IAMCOM (5 Jan) Mobile India 2011 (7 Jan) Technical Paper and Poster Sessions Ph.D Forum Panel Discussions Demos & Exhibits Important Deadlines ------------------- Paper submission: September 13, 2010 at 11:59 pm EDT (Sept 14, 9:29 am IST) Notification of Acceptance: November 8, 2010 Camera-Ready Submission: December 8, 2010 Detailed conference information and paper submission guidelines will soon be available on the conference web site. Please see http://www.comsnets.org for detailed information from time to time. The conference email address is: comsnets2011 at gmail.com General Co-Chairs ----------------- David B. Johnson, Rice University, USA Anurag Kumar, IISc Bangalore, India Technical Program Co-Chairs --------------------------- Jon Crowcroft, U. of Cambridge, UK D. Manjunath, IIT Bombay, India Archan Misra, Telcordia Tech., USA Steering Committee Co-Chairs ---------------------------- Uday Desai, IIT Hyderabad, India Giridhar Mandyam, Qualcomm, USA Sanjoy Paul, Infosys, India Rajeev Shorey, NIIT University, India G. Venkatesh, SASKEN, India Panel Co-Chairs --------------- Aditya Akella, U. of Wisconsin, USA Venkat Padmanabhan, MSR, India Ph.D Forum Chair ---------------- Bhaskaran Raman, IIT Bombay, India Publications Chair ------------------ Varsha Apte, IIT Bombay, India Demos and Exhibits Co-Chairs ---------------------------- Aaditeshwar Seth, IIT Delhi, India Ajay Bakre, Netapps, India Sponsorship Chair ----------------- Sudipta Maitra, Delhi, india Workshop Chairs --------------- Sharad Jaiswal, Alcatel-Lucent, India Ravindran Kaliappa, CUNY, USA Neelesh Mehta, IISc Bangalore, India Mobile India 2011 Co-Chairs --------------------------- Gulzar Azad, Google, India Gene Landy, Ruperto-Israel & Weiner, USA Rajaraghavan Setlur, SASKEN, India Sridhar Varadharajan, SASKEN, India Publicity Co-Chair ------------------ Augustin Chaintreau, TTL, France Kameswari Chebrolu, IIT Bombay, India Song Chong, KAIST, Korea Ramana Kompella, Purdue Univ, USA Nishanth Sastry, U. of Cambridge, UK Web Co-Chairs ------------- Santhana Krishnan, IIT Bombay, India Vinay Veerappa, SASKEN, India International Advisory Committee -------------------------------- K. K. Ramakrishnan, AT&T, USA Victor Bahl, Microsoft Research, USA Sunghyun Choi, Seoul National U., Korea Sajal Das, U. Texas at Arlington, USA B. N. Jain, IIT Delhi, India Anurag Kumar, IISc, Bangalore, India L. M. Patnaik, IISc, Bangalore, India Krithi Ramamritham, IIT Bombay, India Parmesh Ramanathan, U. Wisconsin, USA Krishan Sabnani, Alcatel-Lucent, USA Kang Shin, U. Michigan, USA Nitin Vaidya, U. Illinois, USA University Partners: -------------------- IIT Bombay, IIT Delhi, IISc Bangalore, IIT Hyderabad, NIIT University, IIIT Bangalore Patrons: -------- Mobile Monday Bangalore, Sasken, IBM Research, Alcatel Lucent From Valdis.Kletnieks at vt.edu Wed Sep 8 14:07:46 2010 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Wed, 08 Sep 2010 10:07:46 -0400 Subject: yahoo crawlers hammering us In-Reply-To: Your message of "Wed, 08 Sep 2010 02:21:31 PDT." References: <20100907201958.GM24371@sizone.org> Message-ID: <77925.1283954866@localhost> On Wed, 08 Sep 2010 02:21:31 PDT, Bruce Williams said: > > I *am* curious--what makes it any worse for a search engine like Google > > to fetch the file than any other random user on the Internet > > Possibly because that other user is who the customer pays have their > content delivered to? Seems to me that if you're doing content-for-pay and are upset when some(body|thing) downloads it without paying for it, you shouldn't be leaving gigabytes of said content where even a stupid bot can find it and download it without paying for it. Just sayin'. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From M.Hotze at hotze.com Wed Sep 8 14:47:18 2010 From: M.Hotze at hotze.com (Martin Hotze) Date: Wed, 8 Sep 2010 14:47:18 +0000 Subject: NANOG Digest, Vol 32, Issue 25 In-Reply-To: References: Message-ID: <6A4EBE06CF13034585C3F773EAF836A33B897CAD@exsrv01.hotzecom.local> > -----Original Message----- > Message: 3 > Date: Wed, 8 Sep 2010 10:24:38 +0000 > From: Nathan Eisenberg > Subject: RE: yahoo crawlers hammering us > To: "nanog at nanog.org" > Message-ID: > <8C26A4FDAE599041A13EB499117D3C28164AC3A7 at ex-mb- > 1.corp.atlasnetworks.us> > > Customers don't want to deliver their content to search engines? That > seems silly. I have a private website; I don't want the site to be listed or content found via a search engine. I want to be able to give the URL out to friends etc. but I don't want all of the world hotlink or whatever - sure, I can password protect the site, but for now I have a ton of rewrite conditions in place. #m From charles at knownelement.com Wed Sep 8 15:54:20 2010 From: charles at knownelement.com (Charles N Wyble) Date: Wed, 08 Sep 2010 08:54:20 -0700 Subject: NOC Automation / Best Practices Message-ID: <4C87B1AC.4040900@knownelement.com> NOGGERS, The recent thread on ISP port blocking practice mentioned a way to identify infected machines through a highly automated manner. This got me thinking about other ways to automate aspects of network/system operations when it comes to tier-1 end user support (is it plugged in/is your wireless working etc) and tier-2/3 NOC support (abuse desk/incident response/routing issues etc) . I'm putting in a very high degree of monitoring/healing in place to reduce the amount of end user support calls that come in, and only bother a human when it's a real issue. I'm in the process of launching a small regional wireless ISP / ad delivery network in Los Angeles CA. I have a small staff (I'm the only full time engineer, I have a couple NOC techs and 1 help desk tech who will provide escalation for any serious issues). My initial thoughts/questions on the matter: 1) Are people integrating their PBX with their OSS/CRM systems? So when a call comes in the tech has all the relevant information? (perhaps even things like traceroute/port scan/AV/security health status based on their phone number or customer number?). This way if I take a user offline because they are spewing spam/virii the tech can refer them to our IT support partner organization to clean up their PC. :) 2) What sort of automated alerting/reporting/circuit turn down/RADIUS lock out is done in regards to alerting customers or even taking them offline when they have a security issue? 3) What are folks doing in terms of frontline offloading? Do you have your PBX set to play a different recording when you have an outage so the NOC techs phones don't go crazy and leave them free to deal with the issue? 4) Your comments here. :) The way I see it, an ounce of prevention is worth a pound of cure. Along those lines, I'm putting in some mitigation techniques are as follows (hopefully this will reduce the number of incidents and therefore calls to the abuse desk). I would appreciate any feedback folks can give me. A) Force any outbound mail through my SMTP server with AV/spam filtering. B) Force HTTP traffic through a SQUID proxy with SNORT/ClamAV running (several other WISPs are doing this with fairly substantial bandwidth savings. However I realize that many sites aren't cache friendly. Anyone know of a good way to check for that? Look at HTTP headers?). Do the bandwidth savings/security checking outweigh the increased support calls due to "broken" web sites? C) Force DNS to go through my server. I hope to reduce DNS hijacking attacks this way. Thanks! From rdobbins at arbor.net Wed Sep 8 16:05:44 2010 From: rdobbins at arbor.net (Dobbins, Roland) Date: Wed, 8 Sep 2010 16:05:44 +0000 Subject: NOC Automation / Best Practices In-Reply-To: <4C87B1AC.4040900@knownelement.com> References: <4C87B1AC.4040900@knownelement.com> Message-ID: <35949190-1954-4DE3-9F26-E92B8FE673C0@arbor.net> On Sep 8, 2010, at 10:54 PM, Charles N Wyble wrote: > I would appreciate any feedback folks can give me. ----------------------------------------------------------------------- Roland Dobbins // Sell your computer and buy a guitar. From ken at sizone.org Wed Sep 8 16:20:07 2010 From: ken at sizone.org (Ken Chase) Date: Wed, 8 Sep 2010 12:20:07 -0400 Subject: yahoo crawlers hammering us In-Reply-To: References: <20100907201958.GM24371@sizone.org> Message-ID: <20100908162006.GM30630@sizone.org> On Wed, Sep 08, 2010 at 12:04:07AM -0700, Matthew Petach said: >I *am* curious--what makes it any worse for a search engine like Google >to fetch the file than any other random user on the Internet? In either case, >the machine doing the fetch isn't going to rate-limit the fetch, so >you're likely >to see the same impact on the machine, and on the bandwidth. I think that the difference is that there's a way to get to Yahoo and ask them WTF. Whereas the guy who mass downloads your site with a script in 2 hrs you have no recourse to (modulo well funded banks dispatching squads with baseball bats to resolve hacking incidents). I also expect that Yahoo's behaviour is driven by policy, not random assholishness (I hope :), and therefore I should expect such incidents often. I also expect whinging on nanog might get me some visiblity into said policy and leverage to change it! /kc -- Ken Chase - ken at heavycomputing.ca - +1 416 897 6284 - Toronto CANADA Heavy Computing - Clued bandwidth, colocation and managed linux VPS @151 Front St. W. From mpetach at netflight.com Wed Sep 8 16:46:12 2010 From: mpetach at netflight.com (Matthew Petach) Date: Wed, 8 Sep 2010 09:46:12 -0700 Subject: yahoo crawlers hammering us In-Reply-To: <20100908162006.GM30630@sizone.org> References: <20100907201958.GM24371@sizone.org> <20100908162006.GM30630@sizone.org> Message-ID: On Wed, Sep 8, 2010 at 9:20 AM, Ken Chase wrote: > On Wed, Sep 08, 2010 at 12:04:07AM -0700, Matthew Petach said: > > ?>I *am* curious--what makes it any worse for a search engine like Google > ?>to fetch the file than any other random user on the Internet? ?In either case, > ?>the machine doing the fetch isn't going to rate-limit the fetch, so > ?>you're likely > ?>to see the same impact on the machine, and on the bandwidth. > > I think that the difference is that there's a way to get to Yahoo and ask them > WTF. Whereas the guy who mass downloads your site with a script in 2 hrs you > have no recourse to (modulo well funded banks dispatching squads with baseball > bats to resolve hacking incidents). ?I also expect that Yahoo's behaviour is > driven by policy, not random assholishness (I hope :), and therefore I should > expect such incidents often. I also expect whinging on nanog might get me some > visiblity into said policy and leverage to change it! Well, I'd hazard a guess that the policy of the webcrawling machines at Bing, Google, Yahoo, Ask.com, and every other large search engine is probably to crawl the Internet, pulling down pages and indexing them for their search engine, always checking for a robots.txt file and carefully following the instructions located within said file. Lacking any such file, one might suppose that the policy is to limit how many pages are fetched per interval of time, to avoid hammering a single server unnecessarily, and to space out intervals at which the site is visited, to balance out the desire to maintain a current, fresh view of the content, while at the same time being mindful of the limited server resources available for serving said content. Note that I have no actual knowledge of the crawling policies present at any of the aforementioned sites, I'm simply hypothesizing at what their policies might logically be. I'm curious--what level of visibility are you seeking into the crawling policies of the search engines, and what changes are you hoping to gain leverage to make to said policies? Thanks! Matt (speaking only for myself, not for any current or past employer) > /kc > -- > Ken Chase - ken at heavycomputing.ca - +1 416 897 6284 - Toronto CANADA > Heavy Computing - Clued bandwidth, colocation and managed linux VPS @151 Front St. W. From M.Hotze at hotze.com Wed Sep 8 16:59:14 2010 From: M.Hotze at hotze.com (Martin Hotze) Date: Wed, 8 Sep 2010 16:59:14 +0000 Subject: NOC Automation / Best Practices In-Reply-To: References: Message-ID: <6A4EBE06CF13034585C3F773EAF836A33B897E0A@exsrv01.hotzecom.local> > -----Original Message----- > Date: Wed, 08 Sep 2010 08:54:20 -0700 > From: Charles N Wyble > Subject: NOC Automation / Best Practices > To: nanog at nanog.org > > NOGGERS, > > (...) > The way I see it, an ounce of prevention is worth a pound of cure. > Along > those lines, I'm putting in some mitigation techniques are as follows > (hopefully this will reduce the number of incidents and therefore calls > to the abuse desk). I would appreciate any feedback folks can give me. > > A) Force any outbound mail through my SMTP server with AV/spam > filtering. > B) Force HTTP traffic through a SQUID proxy with SNORT/ClamAV running > (several other WISPs are doing this with fairly substantial bandwidth > savings. However I realize that many sites aren't cache friendly. > Anyone > know of a good way to check for that? Look at HTTP headers?). Do the > bandwidth savings/security checking outweigh the increased support > calls > due to "broken" web sites? > C) Force DNS to go through my server. I hope to reduce DNS hijacking > attacks this way. > > Thanks! For either A, B or C you won't get my business, let alone a combination of all 3. *wah!* There is too much FORCE here. :-) #m From jared at puck.nether.net Wed Sep 8 17:34:09 2010 From: jared at puck.nether.net (Jared Mauch) Date: Wed, 8 Sep 2010 13:34:09 -0400 Subject: NOC Automation / Best Practices In-Reply-To: <6A4EBE06CF13034585C3F773EAF836A33B897E0A@exsrv01.hotzecom.local> References: <6A4EBE06CF13034585C3F773EAF836A33B897E0A@exsrv01.hotzecom.local> Message-ID: On Sep 8, 2010, at 12:59 PM, Martin Hotze wrote: >> -----Original Message----- >> Date: Wed, 08 Sep 2010 08:54:20 -0700 >> From: Charles N Wyble >> Subject: NOC Automation / Best Practices >> To: nanog at nanog.org >> >> NOGGERS, >> >> (...) >> The way I see it, an ounce of prevention is worth a pound of cure. >> Along >> those lines, I'm putting in some mitigation techniques are as follows >> (hopefully this will reduce the number of incidents and therefore calls >> to the abuse desk). I would appreciate any feedback folks can give me. >> >> A) Force any outbound mail through my SMTP server with AV/spam >> filtering. >> B) Force HTTP traffic through a SQUID proxy with SNORT/ClamAV running >> (several other WISPs are doing this with fairly substantial bandwidth >> savings. However I realize that many sites aren't cache friendly. >> Anyone >> know of a good way to check for that? Look at HTTP headers?). Do the >> bandwidth savings/security checking outweigh the increased support >> calls >> due to "broken" web sites? >> C) Force DNS to go through my server. I hope to reduce DNS hijacking >> attacks this way. >> >> Thanks! > > For either A, B or C you won't get my business, let alone a combination of all 3. *wah!* There is too much FORCE here. :-) So A) is fairly common in "hotel" networks. Make sure you only are looking at tcp/25 and not tcp/587. B) is fairly common in "hotel" networks. There are a lot of things you need to do to make things work "correctly". I've found some websites will actually block you if you are behind a cache and it adds the Via: headers per standard. I've had to turn a lot of these options off in my home setup (ie: break standards on purpose). You may also want to reach out to the CDNs themselves, eg:akamai, llnw, etc.. as they may have a way to just drop the cache in your network and send your customers there automagically. C) is also common in a number of networks. You may want to 'whitelist' some other common open resolvers that are intended to be open. (eg: OpenDNS). You may be able to approach dns operators to have them put an instance in your network. Make sure you don't construct the network such that you're forced to do this for all subscribers. Many WISPs have a 'flat' or simple routed network. This is because the hardware doesn't always support nice routing protocols eg: OSPF/ISIS so you're stuck with RIP/RIPv2 (ick!). Here's some settings that I use, to optimize for software updates and other items. If you have a lot of Windows machines, you may need to read this page: http://wiki.squid-cache.org/SquidFaq/WindowsUpdate -- snip -- # hide our existance forwarded_for off via off # workaround facebook bug ignore_expect_100 on # Comcast is sometimes busted ignore_unknown_nameservers off # allow up to 8G to be cached maximum_object_size 8192 MB # allow squid daemon to get 1024 MB ahead of client read_ahead_gap 1024 MB From khatfield at socllc.net Wed Sep 8 17:56:16 2010 From: khatfield at socllc.net (khatfield at socllc.net) Date: Wed, 8 Sep 2010 17:56:16 +0000 Subject: NOC Automation / Best Practices In-Reply-To: <6A4EBE06CF13034585C3F773EAF836A33B897E0A@exsrv01.hotzecom.local> References: <6A4EBE06CF13034585C3F773EAF836A33B897E0A@exsrv01.hotzecom.local> Message-ID: <2010465135-1283968577-cardhu_decombobulator_blackberry.rim.net-495333337-@bda903.bisx.prod.on.blackberry> We run a *free* WISP and block 25 but I'm not sure why you would want to force all traffic through it. That's a touchy argument but it would really bother me as a paying subscriber. We use customized squid to haproxy (custom) to route traffic. Our main business is ddos protection and we use datacenters in multiple places. However, when we wanted to offer free wireless out of our office in Oxford, MS we found getting 10Mbps+ of bandwidth was nearly impossible. So we setup a few caching load balancers in the Oxford office which connect out through two load-balanced proxy systems sitting in the datacenter on 1Gbps connections. Works well - some sites cannot be cached but we are able to enforce gzip compression on everything, cache dns, images, etc. We get upwards of 100 users concurrently. Works beautifully - we can see our office pushing 40Mbps+ and the downstream at 5Mbps or less (total available we have is 2x10Mbps links). Requires some serious tuning but if you got time, this is the way to go. We do block bittorrent traffic which we find more of a threat than properly monitored smtp traffic. -----Original Message----- From: Martin Hotze Date: Wed, 8 Sep 2010 16:59:14 To: nanog at nanog.org Subject: RE: NOC Automation / Best Practices > -----Original Message----- > Date: Wed, 08 Sep 2010 08:54:20 -0700 > From: Charles N Wyble > Subject: NOC Automation / Best Practices > To: nanog at nanog.org > > NOGGERS, > > (...) > The way I see it, an ounce of prevention is worth a pound of cure. > Along > those lines, I'm putting in some mitigation techniques are as follows > (hopefully this will reduce the number of incidents and therefore calls > to the abuse desk). I would appreciate any feedback folks can give me. > > A) Force any outbound mail through my SMTP server with AV/spam > filtering. > B) Force HTTP traffic through a SQUID proxy with SNORT/ClamAV running > (several other WISPs are doing this with fairly substantial bandwidth > savings. However I realize that many sites aren't cache friendly. > Anyone > know of a good way to check for that? Look at HTTP headers?). Do the > bandwidth savings/security checking outweigh the increased support > calls > due to "broken" web sites? > C) Force DNS to go through my server. I hope to reduce DNS hijacking > attacks this way. > > Thanks! For either A, B or C you won't get my business, let alone a combination of all 3. *wah!* There is too much FORCE here. :-) #m From nathan at atlasnetworks.us Wed Sep 8 17:59:23 2010 From: nathan at atlasnetworks.us (Nathan Eisenberg) Date: Wed, 8 Sep 2010 17:59:23 +0000 Subject: NOC Automation / Best Practices In-Reply-To: <6A4EBE06CF13034585C3F773EAF836A33B897E0A@exsrv01.hotzecom.local> References: <6A4EBE06CF13034585C3F773EAF836A33B897E0A@exsrv01.hotzecom.local> Message-ID: <8C26A4FDAE599041A13EB499117D3C28164ACB20@ex-mb-1.corp.atlasnetworks.us> > For either A, B or C you won't get my business, let alone a combination of all 3. > *wah!* There is too much FORCE here. :-) > Agreed. Just provide tubes and shut down infected customers until they clean up. Keep it simple. For content delivery, there are several non-evil ways of doing localization that don't involve caching the internet to hell and back - they'll work a LOT better and they place support in the content distributors court . At the very least, peering with them at the local IX should help a lot. If you're going to try to control mail, do it explicitly. Block 25 and provide a ratelimited, scoped relay server that people have to manually use if they NEED to use 25 - again, they should be using MSA instead, but... From rs at seastrom.com Wed Sep 8 19:52:27 2010 From: rs at seastrom.com (Robert E. Seastrom) Date: Wed, 08 Sep 2010 15:52:27 -0400 Subject: ISP port blocking practice In-Reply-To: <546D5FD6-42BB-487A-B41B-EB6AA93DCB1F@delong.com> (Owen DeLong's message of "Sat, 4 Sep 2010 09:50:25 +0930") References: <20100903124008.72241.qmail@joyce.lan> <918D3F33-E46F-40F0-9325-FAE4AE5E0D05@delong.com> <546D5FD6-42BB-487A-B41B-EB6AA93DCB1F@delong.com> Message-ID: <86pqworp1g.fsf@seastrom.com> Owen DeLong writes: >> I know people at large ISPs with actual data. Port 25 blocking is >> quite effective. > > Does the data show that blocking was effective, as in the host > didn't detect the block and proceed around it, or, merely that lots > of hosts try the direct approach first? Only a single data point and a few years old, but when I was at Inter.Net, my personal cell phone number was in the OrgTechContact for our blocks, we blocked port 25, and my cell phone rang like three times in a period of three years for calls regarding our netblocks. One was for "why is this machine scanning me?", two were "why is DNS geodata broken?". The latter two came within days of each other so I'm thinking news story or something. No spam complaints. YMMV, I'd do it again in a heartbeat though if I were running consumer edge. -r From owen at delong.com Wed Sep 8 20:45:13 2010 From: owen at delong.com (Owen DeLong) Date: Wed, 8 Sep 2010 13:45:13 -0700 Subject: NOC Automation / Best Practices In-Reply-To: <6A4EBE06CF13034585C3F773EAF836A33B897E0A@exsrv01.hotzecom.local> References: <6A4EBE06CF13034585C3F773EAF836A33B897E0A@exsrv01.hotzecom.local> Message-ID: On Sep 8, 2010, at 9:59 AM, Martin Hotze wrote: >> -----Original Message----- >> Date: Wed, 08 Sep 2010 08:54:20 -0700 >> From: Charles N Wyble >> Subject: NOC Automation / Best Practices >> To: nanog at nanog.org >> >> NOGGERS, >> >> (...) >> The way I see it, an ounce of prevention is worth a pound of cure. >> Along >> those lines, I'm putting in some mitigation techniques are as follows >> (hopefully this will reduce the number of incidents and therefore calls >> to the abuse desk). I would appreciate any feedback folks can give me. >> >> A) Force any outbound mail through my SMTP server with AV/spam >> filtering. >> B) Force HTTP traffic through a SQUID proxy with SNORT/ClamAV running >> (several other WISPs are doing this with fairly substantial bandwidth >> savings. However I realize that many sites aren't cache friendly. >> Anyone >> know of a good way to check for that? Look at HTTP headers?). Do the >> bandwidth savings/security checking outweigh the increased support >> calls >> due to "broken" web sites? >> C) Force DNS to go through my server. I hope to reduce DNS hijacking >> attacks this way. >> >> Thanks! > > For either A, B or C you won't get my business, let alone a combination of all 3. *wah!* There is too much FORCE here. :-) > > #m > +1 Owen From surfer at mauigateway.com Wed Sep 8 23:17:46 2010 From: surfer at mauigateway.com (Scott Weeks) Date: Wed, 8 Sep 2010 16:17:46 -0700 Subject: NANOG Digest, Vol 32, Issue 25 Message-ID: <20100908161746.EED996D8@resin18.mta.everyone.net> --- M.Hotze at hotze.com wrote: From: Martin Hotze I have a private website; I don't want the site to be listed or content found via a search engine. I want to be able to give the URL out to friends etc. but I don't want all of the world hotlink or whatever[...] -------------------------------------------------- Don't put links on the main page. Put up example.com with only or nothing even. Then your friends have to know to go to example.com/mypage.html but the web crawlers never know about mypage.html because there's no link on the top page. scott From paul at neoverve.com Wed Sep 8 23:18:49 2010 From: paul at neoverve.com (Paul Norton) Date: Wed, 08 Sep 2010 16:18:49 -0700 Subject: Speakeasy Contact Message-ID: <4C8819D9.4090607@neoverve.com> Someone from Speakeasy please contact me off-list. This is for business T-1 service. I've been seeing major packet loss on one of your peering nodes for a week now and am experiencing degraded service due to this. Support has been unable to resolve and has been unresponsive for the past 24 hours. Also, Account Manager has been non-responsive for 6 days now. -- Paul Norton Systems Administrator Neoverve -www.neoverve.com Neoverve Blog -http://blog.neoverve.com/ From trelane at trelane.net Wed Sep 8 23:21:15 2010 From: trelane at trelane.net (Andrew Kirch) Date: Wed, 08 Sep 2010 19:21:15 -0400 Subject: Speakeasy Contact In-Reply-To: <4C8819D9.4090607@neoverve.com> References: <4C8819D9.4090607@neoverve.com> Message-ID: <4C881A6B.9030905@trelane.net> On 9/8/2010 7:18 PM, Paul Norton wrote: > Someone from Speakeasy please contact me off-list. This is for > business T-1 service. > > I've been seeing major packet loss on one of your peering nodes for a > week now and am experiencing degraded service due to this. > > Support has been unable to resolve and has been unresponsive for the > past 24 hours. Also, Account Manager has been non-responsive for 6 > days now. > Speakeasy no longer exists. You're going to want to get ahold of MegaPath. Speakeasy/Covad/MegaPath merged Andrew From w3yni1 at gmail.com Thu Sep 9 02:34:50 2010 From: w3yni1 at gmail.com (Charles Mills) Date: Wed, 8 Sep 2010 22:34:50 -0400 Subject: Cogent issues Message-ID: Anyone notice any issues with Cogent? Internet Health Report showing some high latency to Verizon and a couple of other carriers. From brandon.galbraith at gmail.com Thu Sep 9 04:45:51 2010 From: brandon.galbraith at gmail.com (Brandon Galbraith) Date: Wed, 8 Sep 2010 23:45:51 -0500 Subject: Copyright Enforcement DoS/DDoS Attacks Message-ID: http://www.smh.com.au/technology/technology-news/film-industry-hires-cyber-hitmen-to-take-down-internet-pirates-20100907-14ypv.html Has anyone dealt with this in the wild? I wasn't aware DoS/DDoS attacks were suddenly legal. -- Brandon Galbraith Voice: 630.492.0464 From ops.lists at gmail.com Thu Sep 9 04:57:12 2010 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Thu, 9 Sep 2010 10:27:12 +0530 Subject: Copyright Enforcement DoS/DDoS Attacks In-Reply-To: References: Message-ID: If that's the india story .. seems to be a press release fed by the vendor - which from their website also offers "medical transcription" and "SEO" On Thu, Sep 9, 2010 at 10:15 AM, Brandon Galbraith wrote: > http://www.smh.com.au/technology/technology-news/film-industry-hires-cyber-hitmen-to-take-down-internet-pirates-20100907-14ypv.html > > Has > anyone dealt with this in the wild? I wasn't aware DoS/DDoS attacks were > suddenly legal. > > -- > Brandon Galbraith > Voice: 630.492.0464 > -- Suresh Ramasubramanian (ops.lists at gmail.com) From tvhawaii at shaka.com Thu Sep 9 05:13:41 2010 From: tvhawaii at shaka.com (Michael Painter) Date: Wed, 8 Sep 2010 19:13:41 -1000 Subject: Copyright Enforcement DoS/DDoS Attacks References: Message-ID: <180F69C113834A6E9EA678F6742480BC@DELL16> Brandon Galbraith wrote: > http://www.smh.com.au/technology/technology-news/film-industry-hires-cyber-hitmen-to-take-down-internet-pirates-20100907-14ypv.html > > Has > anyone dealt with this in the wild? I wasn't aware DoS/DDoS attacks were > suddenly legal. It's gotta' be tough reading that when you're in the slammer, eh? http://www.theregister.co.uk/2010/05/25/second_scientology_ddoser_jailed/ From jeffrey.lyon at blacklotus.net Thu Sep 9 05:55:17 2010 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Thu, 9 Sep 2010 10:25:17 +0430 Subject: Copyright Enforcement DoS/DDoS Attacks In-Reply-To: <180F69C113834A6E9EA678F6742480BC@DELL16> References: <180F69C113834A6E9EA678F6742480BC@DELL16> Message-ID: I look forward to receiving those attacks. Jeff On Thu, Sep 9, 2010 at 9:43 AM, Michael Painter wrote: > Brandon Galbraith wrote: >> >> >> http://www.smh.com.au/technology/technology-news/film-industry-hires-cyber-hitmen-to-take-down-internet-pirates-20100907-14ypv.html >> >> >> Has >> anyone dealt with this in the wild? I wasn't aware DoS/DDoS attacks were >> suddenly legal. > > It's gotta' be tough reading that when you're in the slammer, eh? > > http://www.theregister.co.uk/2010/05/25/second_scientology_ddoser_jailed/ > > -- Jeffrey Lyon, Leadership Team jeffrey.lyon at blacklotus.net | http://www.blacklotus.net Black Lotus Communications - AS32421 First and Leading in DDoS Protection Solutions From khatfield at socllc.net Thu Sep 9 06:02:03 2010 From: khatfield at socllc.net (khatfield at socllc.net) Date: Thu, 9 Sep 2010 06:02:03 +0000 Subject: Copyright Enforcement DoS/DDoS Attacks Message-ID: <683013117-1284012124-cardhu_decombobulator_blackberry.rim.net-1362634181-@bda903.bisx.prod.on.blackberry> No matter how they spin it, it isn't legal. Likely he won't be touched in India but in the U.S. he and the industry paying him would be facing a judge. The guy is a moron. Wanna be elitist. ------Original Message------ From: Michael Painter To: nanog at nanog.org Subject: Re: Copyright Enforcement DoS/DDoS Attacks Sent: Sep 9, 2010 12:13 AM Brandon Galbraith wrote: > http://www.smh.com.au/technology/technology-news/film-industry-hires-cyber-hitmen-to-take-down-internet-pirates-20100907-14ypv.html > > Has > anyone dealt with this in the wild? I wasn't aware DoS/DDoS attacks were > suddenly legal. It's gotta' be tough reading that when you're in the slammer, eh? http://www.theregister.co.uk/2010/05/25/second_scientology_ddoser_jailed/ From eugen at leitl.org Thu Sep 9 10:23:26 2010 From: eugen at leitl.org (Eugen Leitl) Date: Thu, 9 Sep 2010 12:23:26 +0200 Subject: Sustaining the Internet with hyperbolic mapping Message-ID: <20100909102326.GJ14773@leitl.org> http://www.nature.com/ncomms/journal/v1/n6/full/ncomms1063.html Sustaining the Internet with hyperbolic mapping Mari?n Bogu??, Fragkiskos Papadopoulos & Dmitri Krioukov Nature Communications 1 , Article number: 62 doi:10.1038/ncomms1063 Received 06 April 2010 Accepted 06 August 2010 Published 07 September 2010 Abstract The Internet infrastructure is severely stressed. Rapidly growing overheads associated with the primary function of the Internet?routing information packets between any two computers in the world?cause concerns among Internet experts that the existing Internet routing architecture may not sustain even another decade. In this paper, we present a method to map the Internet to a hyperbolic space. Guided by a constructed map, which we release with this paper, Internet routing exhibits scaling properties that are theoretically close to the best possible, thus resolving serious scaling limitations that the Internet faces today. Besides this immediate practical viability, our network mapping method can provide a different perspective on the community structure in complex networks. [full text snipped] -- Eugen* Leitl leitl http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE From bclark at spectraaccess.com Thu Sep 9 11:09:53 2010 From: bclark at spectraaccess.com (Bret Clark) Date: Thu, 09 Sep 2010 07:09:53 -0400 Subject: Cogent issues In-Reply-To: References: Message-ID: <4C88C081.3080300@spectraaccess.com> We've been noticing high latency for some time with Verizon (UUNET) connections at least through the NY area. On 09/08/2010 10:34 PM, Charles Mills wrote: > Anyone notice any issues with Cogent? > > Internet Health Report showing some high latency to Verizon and a couple of > other carriers. > From jared at puck.nether.net Thu Sep 9 12:24:21 2010 From: jared at puck.nether.net (Jared Mauch) Date: Thu, 9 Sep 2010 08:24:21 -0400 Subject: Sustaining the Internet with hyperbolic mapping In-Reply-To: <20100909102326.GJ14773@leitl.org> References: <20100909102326.GJ14773@leitl.org> Message-ID: <63DE3C6E-1BE0-47D6-B774-CC16FEB6B3F8@puck.nether.net> On Sep 9, 2010, at 6:23 AM, Eugen Leitl wrote: > > http://www.nature.com/ncomms/journal/v1/n6/full/ncomms1063.html I had read this as well last night. It's an interesting read and I was going to send the authors some feedback as it relates to the asymmetrical nature of BGP announcements impact on ASes, and seeking some of the data on the node/edge layouts that have been done. I'm quite excited to see research continue in this space. I'm also hoping someone will spend time performing comparable analysis within the IPv6 sphere over the T-6 months and T+18/24 from now to watch what happens at this critical time in the IPv4 lifecycle. - Jared From nick at brevardwireless.com Thu Sep 9 12:41:15 2010 From: nick at brevardwireless.com (Nick Olsen) Date: Thu, 9 Sep 2010 08:41:15 -0400 Subject: Cogent issues Message-ID: <50ddcc63$7052ac02$69c8d600$@com> No Cogent issues here in Florida. Nick Olsen Network Operations (877) 804-3001 x106 ---------------------------------------- From: "Charles Mills" Sent: Wednesday, September 08, 2010 10:35 PM To: "NANOG list" Subject: Cogent issues Anyone notice any issues with Cogent? Internet Health Report showing some high latency to Verizon and a couple of other carriers. From compuwizz at gmail.com Thu Sep 9 13:22:14 2010 From: compuwizz at gmail.com (Jared Geiger) Date: Thu, 9 Sep 2010 09:22:14 -0400 Subject: Anyone seeing problems with PCCW? Message-ID: I'm seeing routes die on PCCW's network both in Amsterdam and Washington DC with destinations to Asia (Hong Kong is mainly what I've tested). However the routes are fine from Los Angeles. Does anyone know of any fiber cuts or issues that would be causing this? From w3yni1 at gmail.com Thu Sep 9 13:31:37 2010 From: w3yni1 at gmail.com (Charles Mills) Date: Thu, 9 Sep 2010 09:31:37 -0400 Subject: Cogent issues In-Reply-To: <4C88C081.3080300@spectraaccess.com> References: <4C88C081.3080300@spectraaccess.com> Message-ID: A lot of our traffic hits VZ as well and goes either to DC or points in NY..... Been happening off and on since Labor Day weekend. CM On Thu, Sep 9, 2010 at 7:09 AM, Bret Clark wrote: > We've been noticing high latency for some time with Verizon (UUNET) > connections at least through the NY area. > > > > On 09/08/2010 10:34 PM, Charles Mills wrote: > >> Anyone notice any issues with Cogent? >> >> Internet Health Report showing some high latency to Verizon and a couple >> of >> other carriers. >> >> > > > From zeusdadog at gmail.com Thu Sep 9 15:33:43 2010 From: zeusdadog at gmail.com (Jay Nakamura) Date: Thu, 9 Sep 2010 11:33:43 -0400 Subject: DS3 mux recommendation Message-ID: I haven't researched stand alone DS3 mux in a long time and was wondering if anyone can recommend a DS3 Mux. I have used Adtran before. (Long ago) The products back then worked fine on line level but management interface was awful and if you threw too much SNMP at it and the management interface locked up. Are there anything better out there these days? TIA, -Jay From lists at mtin.net Thu Sep 9 15:38:36 2010 From: lists at mtin.net (Justin Wilson) Date: Thu, 09 Sep 2010 11:38:36 -0400 Subject: DS3 mux recommendation In-Reply-To: Message-ID: The adtran TA 3000 is a solid product. -- Justin Wilson http://www.mtin.net/blog ? xISP News http://www.twitter.com/j2sw ? Follow me on Twitter Wisp Consulting ? Tower Climbing ? Network Support From: Jay Nakamura Date: Thu, 9 Sep 2010 11:33:43 -0400 To: NANOG Subject: DS3 mux recommendation I haven't researched stand alone DS3 mux in a long time and was wondering if anyone can recommend a DS3 Mux. I have used Adtran before. (Long ago) The products back then worked fine on line level but management interface was awful and if you threw too much SNMP at it and the management interface locked up. Are there anything better out there these days? TIA, -Jay From sjk at sleepycatz.com Thu Sep 9 15:38:56 2010 From: sjk at sleepycatz.com (sjk) Date: Thu, 09 Sep 2010 10:38:56 -0500 Subject: DS3 mux recommendation In-Reply-To: References: Message-ID: <4C88FF90.1060403@sleepycatz.com> We use Adtran MX2820s which have been pretty reliable. They are designed for medium density, so I am not sure if they'll be applicable to your situation. We pull and trap a fair amount of snmp from them with no problems. Jay Nakamura wrote: > I haven't researched stand alone DS3 mux in a long time and was > wondering if anyone can recommend a DS3 Mux. I have used Adtran > before. (Long ago) The products back then worked fine on line level > but management interface was awful and if you threw too much SNMP at > it and the management interface locked up. > > Are there anything better out there these days? > > TIA, > > -Jay > From jlewis at lewis.org Thu Sep 9 16:03:26 2010 From: jlewis at lewis.org (Jon Lewis) Date: Thu, 9 Sep 2010 12:03:26 -0400 (EDT) Subject: DS3 mux recommendation In-Reply-To: References: Message-ID: On Thu, 9 Sep 2010, Jay Nakamura wrote: > I haven't researched stand alone DS3 mux in a long time and was > wondering if anyone can recommend a DS3 Mux. I have used Adtran > before. (Long ago) The products back then worked fine on line level > but management interface was awful and if you threw too much SNMP at > it and the management interface locked up. We've used a lot of the Carrier Access Widebank28. They work, but you have to figure on the controller cards dying every roughly 5 years. I've lost track of how many times we've had to send a tech on a long drive to an unmanned POP to swap cards. AFAICT, they're insufficiently cooled (ineffective heat sink / no active ventilation unless you spring for the front cover with built-in fans, which IMO should have been standard). The few Adtrans I've used have had issues with putting out too hot a signal for cisco MCT3 interfaces, requiring either an attenuator or long service loop. The orientation of the T1 cable connectors on the backs of the Widebank28 and Adtrans differ, making swapping one for the other post-deployment a royal PITA. ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From matt.taber.nanog at gmail.com Thu Sep 9 16:03:26 2010 From: matt.taber.nanog at gmail.com (Matt Taber) Date: Thu, 9 Sep 2010 12:03:26 -0400 Subject: DS3 mux recommendation In-Reply-To: <4C88FF90.1060403@sleepycatz.com> References: <4C88FF90.1060403@sleepycatz.com> Message-ID: <98A07AA89D204D34B69029813C9C9388@mattt> I can 2nd the recommendation for the MX2820 series. 9 DS3 mux per 2U chassis w/ redundancy. Very nice product if you're needing to save space in a rack. mrt -----Original Message----- From: sjk [mailto:sjk at sleepycatz.com] Sent: Thursday, September 09, 2010 11:39 AM To: Jay Nakamura Cc: NANOG Subject: Re: DS3 mux recommendation We use Adtran MX2820s which have been pretty reliable. They are designed for medium density, so I am not sure if they'll be applicable to your situation. We pull and trap a fair amount of snmp from them with no problems. Jay Nakamura wrote: > I haven't researched stand alone DS3 mux in a long time and was > wondering if anyone can recommend a DS3 Mux. I have used Adtran > before. (Long ago) The products back then worked fine on line level > but management interface was awful and if you threw too much SNMP at > it and the management interface locked up. > > Are there anything better out there these days? > > TIA, > > -Jay > From bruns at 2mbit.com Thu Sep 9 16:04:44 2010 From: bruns at 2mbit.com (Brielle Bruns) Date: Thu, 09 Sep 2010 10:04:44 -0600 Subject: DS3 mux recommendation In-Reply-To: References: Message-ID: <4C89059C.9030405@2mbit.com> On 9/9/10 9:33 AM, Jay Nakamura wrote: > I haven't researched stand alone DS3 mux in a long time and was > wondering if anyone can recommend a DS3 Mux. I have used Adtran > before. (Long ago) The products back then worked fine on line level > but management interface was awful and if you threw too much SNMP at > it and the management interface locked up. > > Are there anything better out there these days? > > TIA, > I used to use Kentrox EZT3s for feeding customers in bulk to my 7513s. They don't have much in the way of management, but they Just Work(tm). Back then, it was mostly serial based, but I think theres more current versions that have ethernet management. -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org / http://www.ahbl.org From matt.taber.nanog at gmail.com Thu Sep 9 16:09:30 2010 From: matt.taber.nanog at gmail.com (Matt Taber) Date: Thu, 9 Sep 2010 12:09:30 -0400 Subject: DS3 mux recommendation In-Reply-To: References: Message-ID: I've run into the same situations w/ the Widebanks. Controllers like to die in the middle of the night. I also ran into a situation where a tech went to replace a Widebank w/ an Adtran and jammed the Amphenol connectors onto the Adtran the wrong way. That was an interesting night... My supply of DS3 attenuators have dwindled thanks to the MCT3 issue, too. -----Original Message----- From: Jon Lewis [mailto:jlewis at lewis.org] Sent: Thursday, September 09, 2010 12:03 PM To: Jay Nakamura Cc: NANOG Subject: Re: DS3 mux recommendation On Thu, 9 Sep 2010, Jay Nakamura wrote: > I haven't researched stand alone DS3 mux in a long time and was > wondering if anyone can recommend a DS3 Mux. I have used Adtran > before. (Long ago) The products back then worked fine on line level > but management interface was awful and if you threw too much SNMP at > it and the management interface locked up. We've used a lot of the Carrier Access Widebank28. They work, but you have to figure on the controller cards dying every roughly 5 years. I've lost track of how many times we've had to send a tech on a long drive to an unmanned POP to swap cards. AFAICT, they're insufficiently cooled (ineffective heat sink / no active ventilation unless you spring for the front cover with built-in fans, which IMO should have been standard). The few Adtrans I've used have had issues with putting out too hot a signal for cisco MCT3 interfaces, requiring either an attenuator or long service loop. The orientation of the T1 cable connectors on the backs of the Widebank28 and Adtrans differ, making swapping one for the other post-deployment a royal PITA. ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From lriemer at bestline.net Thu Sep 9 16:12:12 2010 From: lriemer at bestline.net (Lee Riemer) Date: Thu, 09 Sep 2010 11:12:12 -0500 Subject: DS3 mux recommendation In-Reply-To: References: Message-ID: <4C89075C.7010603@bestline.net> We've switched away from the CAC Widebank28s for the denser, cooler Adtran MX2820s. Our reasons were for the exact issues explained below. On 9/9/2010 11:03 AM, Jon Lewis wrote: > On Thu, 9 Sep 2010, Jay Nakamura wrote: > >> I haven't researched stand alone DS3 mux in a long time and was >> wondering if anyone can recommend a DS3 Mux. I have used Adtran >> before. (Long ago) The products back then worked fine on line level >> but management interface was awful and if you threw too much SNMP at >> it and the management interface locked up. > > We've used a lot of the Carrier Access Widebank28. They work, but you > have to figure on the controller cards dying every roughly 5 years. > I've lost track of how many times we've had to send a tech on a long > drive to an unmanned POP to swap cards. > > AFAICT, they're insufficiently cooled (ineffective heat sink / no > active ventilation unless you spring for the front cover with built-in > fans, which IMO should have been standard). The few Adtrans I've used > have had issues with putting out too hot a signal for cisco MCT3 > interfaces, requiring either an attenuator or long service loop. The > orientation of the T1 cable connectors on the backs of the Widebank28 > and Adtrans differ, making swapping one for the other post-deployment > a royal PITA. > > ---------------------------------------------------------------------- > Jon Lewis, MCP :) | I route > Senior Network Engineer | therefore you are > Atlantic Net | > _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ > -- Lee Riemer Director of Technical Operations Bestline Communications, L.P. Voice: 1+512.328.9095 Fax: 1+512.328.0038 From jbates at brightok.net Thu Sep 9 16:12:50 2010 From: jbates at brightok.net (Jack Bates) Date: Thu, 09 Sep 2010 11:12:50 -0500 Subject: Sustaining the Internet with hyperbolic mapping In-Reply-To: <63DE3C6E-1BE0-47D6-B774-CC16FEB6B3F8@puck.nether.net> References: <20100909102326.GJ14773@leitl.org> <63DE3C6E-1BE0-47D6-B774-CC16FEB6B3F8@puck.nether.net> Message-ID: <4C890782.60209@brightok.net> On 9/9/2010 7:24 AM, Jared Mauch wrote: > > > I had read this as well last night. It's an interesting read and I was going to send the authors some feedback as it relates to the asymmetrical nature of BGP announcements impact on ASes, and seeking some of the data on the node/edge layouts that have been done. > > I'm quite excited to see research continue in this space. I'm also hoping someone will spend time performing comparable analysis within the IPv6 sphere over the T-6 months and T+18/24 from now to watch what happens at this critical time in the IPv4 lifecycle. It's interesting, but it reverts from the desired approach. Greedy routing? I thought only Cogent did that. :P Seriously, I took from it that we can make routing more scalable if we remove features in common use today. Yet business demand is that we are actually trying to increase the information we want to pass between AS's. Between multicast/unicast v4/v6, mpls, extensive traffic engineering, I don't see how the research could be applied. Jack From pfunix at gmail.com Thu Sep 9 16:26:01 2010 From: pfunix at gmail.com (Beavis) Date: Thu, 9 Sep 2010 10:26:01 -0600 Subject: Copyright Enforcement DoS/DDoS Attacks In-Reply-To: References: Message-ID: man.. this guy is retarded.. good luck posing your company, face and such. lol From jeffrey.lyon at blacklotus.net Thu Sep 9 16:43:06 2010 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Thu, 9 Sep 2010 21:13:06 +0430 Subject: Copyright Enforcement DoS/DDoS Attacks In-Reply-To: References: Message-ID: He may get some business out of it, now that he has effectively put out a DDoS for hire ad. Jeff On Thu, Sep 9, 2010 at 8:56 PM, Beavis wrote: > man.. this guy is retarded.. good luck posing your company, face and such. lol > > -- Jeffrey Lyon, Leadership Team jeffrey.lyon at blacklotus.net | http://www.blacklotus.net Black Lotus Communications - AS32421 First and Leading in DDoS Protection Solutions From rdobbins at arbor.net Thu Sep 9 16:49:16 2010 From: rdobbins at arbor.net (Dobbins, Roland) Date: Thu, 9 Sep 2010 16:49:16 +0000 Subject: Copyright Enforcement DoS/DDoS Attacks In-Reply-To: References: Message-ID: On Sep 9, 2010, at 11:43 PM, Jeffrey Lyon wrote: > He may get some business out of it, now that he has effectively put out a DDoS for hire ad. The relevant Indian authorities have been notified - my guess is that he'll soon be receiving some interesting visitors. ;> ----------------------------------------------------------------------- Roland Dobbins // Sell your computer and buy a guitar. From alan at gtekcommunications.com Thu Sep 9 17:59:43 2010 From: alan at gtekcommunications.com (Alan Bryant) Date: Thu, 9 Sep 2010 12:59:43 -0500 Subject: POS to Ethernet Converter Message-ID: I did a quick google search for a converter but either I'm not understanding, or I'm not searching for the right thing. We currently have a POS OC-3 that I would like to be able to convert it to Ethernet, if possible. Do such devices exist? -- Alan Bryant | Systems Administrator Gtek Computers & Wireless, LLC. alan at gtekcommunications.com | www.gtek.biz O 361-777-1400 | F 361-777-1405 From mksmith at adhost.com Thu Sep 9 18:05:04 2010 From: mksmith at adhost.com (Michael K. Smith - Adhost) Date: Thu, 9 Sep 2010 11:05:04 -0700 Subject: POS to Ethernet Converter In-Reply-To: References: Message-ID: <17838240D9A5544AAA5FF95F8D52031608C90B9F@ad-exh01.adhost.lan> -- Michael K. Smith - CISSP, GSEC, GISP Chief Technical Officer - Adhost Internet LLC mksmith at adhost.com w: +1 (206) 404-9500 f: +1 (206) 404-9050 PGP: B49A DDF5 8611 27F3 08B9 84BB E61E 38C0 (Key ID: 0x9A96777D) > -----Original Message----- > From: Alan Bryant [mailto:alan at gtekcommunications.com] > Sent: Thursday, September 09, 2010 11:00 AM > To: nanog at nanog.org > Subject: POS to Ethernet Converter > > I did a quick google search for a converter but either I'm not > understanding, or I'm not searching for the right thing. > > We currently have a POS OC-3 that I would like to be able to convert > it to Ethernet, if possible. > > Do such devices exist? > > -- > Alan Bryant | Systems Administrator > Gtek Computers & Wireless, LLC. > alan at gtekcommunications.com | www.gtek.biz > O 361-777-1400 | F 361-777-1405 You mean something like this? http://www.rad.com/10/GbE-over-STM-1-OC-3-SFP-Converter/17834/ Regards, Mike From swm at emanon.com Thu Sep 9 18:05:04 2010 From: swm at emanon.com (Scott Morris) Date: Thu, 09 Sep 2010 14:05:04 -0400 Subject: POS to Ethernet Converter In-Reply-To: References: Message-ID: <4C8921D0.3010406@emanon.com> They're called "routers". ;) Otherwise, your framing is completely different between those mediums, so it's not like going from 100Base-FX ethernet to 100Base-TX ethernet! HTH, Scott Morris, CCIEx4 (R&S/ISP-Dial/Security/Service Provider) #4713, CCDE #2009::D, JNCIE-M #153, JNCIS-ER, CISSP, et al. CCSI #21903, JNCI-M, JNCI-ER [1]swm at emanon.com Knowledge is power. Power corrupts. Study hard and be Eeeeviiiil...... On 9/9/10 1:59 PM, Alan Bryant wrote: I did a quick google search for a converter but either I'm not understanding, or I'm not searching for the right thing. We currently have a POS OC-3 that I would like to be able to convert it to Ethernet, if possible. Do such devices exist? References 1. mailto:swm at emanon.com From swmike at swm.pp.se Thu Sep 9 18:06:54 2010 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Thu, 9 Sep 2010 20:06:54 +0200 (CEST) Subject: POS to Ethernet Converter In-Reply-To: References: Message-ID: On Thu, 9 Sep 2010, Alan Bryant wrote: > We currently have a POS OC-3 that I would like to be able to convert > it to Ethernet, if possible. > > Do such devices exist? Yeah, and it's pretty sweet idea. Haven't used it myself but it seems really nice. RAD?s MiRICi-155 connects Gigabit Ethernet LANs over wireline or wireless STM-1 or OC-3 links. The miniature Ethernet over STM-1/OC-3 converter provides TDM connectivity to any Ethernet device with an SFP (small form factor pluggable)-compatible, GbE port. Hot-swappable and software-configurable, the intelligent SFP converter is a fully managed device supporting standard GFP encapsulation. It delivers a complete Ethernet over SDH/SONET solution in a finger-sized SFP enclosure and enables a quick rollout of new Ethernet services over legacy TDM infrastructure. The MiRICi-155 is part of RAD?s ?System on an SFP? product line. -- Mikael Abrahamsson email: swmike at swm.pp.se From johnl at iecc.com Thu Sep 9 18:33:26 2010 From: johnl at iecc.com (John Levine) Date: 9 Sep 2010 18:33:26 -0000 Subject: ISP port blocking practice In-Reply-To: <20100906132205.GA21165@panix.com> Message-ID: <20100909183326.97445.qmail@joyce.lan> >That's really the question at hand here -- whether or not there's any >benefit to continuing the "never ending arms race" game. Some people >think there is. Others question whether anything is really being >accomplished. Certainly we're playing it out like an arms race -- ISPs >block something, spammers find a new way to inject spam, and so on. >The end result of lots of time spend on blocking thins, less >functionality for customers ... but no decrease in spam. I take it you've never run a mail system other than perhaps a tiny one for your friends. The alternative to the arms race is to abandon e-mail altogether. >The theory behind closing open relays, blocking port 25, etc., seems to >be: >(a) That will make it harder on spammers, and that will reduce spam -- >some of the spammers will find other other ways to inject spam, but >some will just stop, OR >(b) Eventually, we'll find technical solutions to *all* the ways spam >is injected, and then there will be no more spam. Interesting guesses, but wrong. R's, John From jackson.tim at gmail.com Thu Sep 9 19:24:52 2010 From: jackson.tim at gmail.com (Tim Jackson) Date: Thu, 9 Sep 2010 14:24:52 -0500 Subject: POS to Ethernet Converter In-Reply-To: References: Message-ID: You could always use a pair of SONET ADMs on both sides with OC-3 cards and ethernet cards. Cisco 15454 is a little big, but maybe the 15327 would have OC-3 cards... -- Tim On Thu, Sep 9, 2010 at 12:59 PM, Alan Bryant wrote: > I did a quick google search for a converter but either I'm not > understanding, or I'm not searching for the right thing. > > We currently have a POS OC-3 that I would like to be able to convert > it to Ethernet, if possible. > > Do such devices exist? > > -- > Alan Bryant | Systems Administrator > Gtek Computers & Wireless, LLC. > alan at gtekcommunications.com | www.gtek.biz > O 361-777-1400 | F 361-777-1405 > > From khatfield at socllc.net Thu Sep 9 19:59:52 2010 From: khatfield at socllc.net (khatfield at socllc.net) Date: Thu, 9 Sep 2010 19:59:52 +0000 Subject: Copyright Enforcement DoS/DDoS Attacks Message-ID: <1661448030-1284062393-cardhu_decombobulator_blackberry.rim.net-881323590-@bda903.bisx.prod.on.blackberry> He mentioned doing work (for hire) in AU and such. I think he may be in for a rude awakening since our past experience with the Australian authorities is they are more active chasing ddos/cyber-crimes than the U.S. Those guys pull out all the stops to prosecute. (Which I am happy to see) Sadly, here in the U.S. you have little to no chance of getting assistance unless the client is a bank or very public company. In fact, that doesn't always work. (Even with direct FBI contacts in multiple field offices) Kind of a shame.. We are likely already tracking his botnets so I almost welcome it as well. Out of curiosity, I did pull some stats over the last 60 days and we have seen more attacks originating from the India area than we have seen in the past 12 months. Maybe it's a coincidence. I would almost bet this guy has never carried out an attack in his life and simply trying to gain some publicity. *shrug* ------Original Message------ From: Jeffrey Lyon To: Beavis Cc: nanog at nanog.org Subject: Re: Copyright Enforcement DoS/DDoS Attacks Sent: Sep 9, 2010 11:43 AM He may get some business out of it, now that he has effectively put out a DDoS for hire ad. Jeff On Thu, Sep 9, 2010 at 8:56 PM, Beavis wrote: > man.. this guy is retarded.. good luck posing your company, face and such. lol > > -- Jeffrey Lyon, Leadership Team jeffrey.lyon at blacklotus.net | http://www.blacklotus.net Black Lotus Communications - AS32421 First and Leading in DDoS Protection Solutions From christopher.morrow at gmail.com Thu Sep 9 20:22:07 2010 From: christopher.morrow at gmail.com (Christopher Morrow) Date: Thu, 9 Sep 2010 16:22:07 -0400 Subject: Reverse traceroute and spoofing of sources of packets? Message-ID: I missed this meeting/preso when it happened (yes, 5+ meetings ago) I note the talks about using spoofed source packets to do some measurement, I didn't see anyone in the video say: "But spoofing is bad, but you want YOU to be able to do this? what? isn't that a little hypocritical?" Isn't it? and why would someone (an isp) disable BCP38 for this sort of activity? -Chris From rbeverly at rbeverly.net Thu Sep 9 20:45:06 2010 From: rbeverly at rbeverly.net (Robert Beverly) Date: Thu, 9 Sep 2010 16:45:06 -0400 Subject: ISP port blocking practice In-Reply-To: References: <0A08271D-49B9-4382-9F54-1A0BB6A3F2B2@umich.edu> <13222.1256232797@turing-police.cc.vt.edu> Message-ID: <20100909204506.GA21350@rbeverly.net> On Thu, Sep 02, 2010 at 04:59:57PM -0500, Zhiyun Qian wrote: > One of the high-level findings is that we developed probing techniques > to verify that indeed most ISPs are only blocking 1) "outgoing traffic > of destination port 25" instead of 2) "incoming traffic with source > port 25", which means that these ISPs are vulnerable to the assymetric > routing attack. Folks interested in port blocking may also find useful another academic work we did a few years ago that sought to broadly characterize the prevalence of port blocking, albeit under the guise of neutrality: http://rbeverly.net/research/papers/truck-pam07.html While we found that email ports (e.g. 25, 110, 143) were more than twice as likely to be blocked than a control port, other ports such as 136 were more widely blocked (136 is an innocuous profile port, but often suffers collateral damage because it lies between the microsoft and netbios 135-139 ports). Also, the asymmetric spam problem is covered in some detail in our 2009 IMC spoofer paper: http://rbeverly.net/research/papers/spoofer-imc09.html rob From william.mccall at gmail.com Thu Sep 9 20:49:26 2010 From: william.mccall at gmail.com (William McCall) Date: Thu, 9 Sep 2010 15:49:26 -0500 Subject: POS to Ethernet Converter In-Reply-To: References: Message-ID: I can vouch for the RAD gear. Pretty simple and to the point. On 9/9/10, Mikael Abrahamsson wrote: > On Thu, 9 Sep 2010, Alan Bryant wrote: > >> We currently have a POS OC-3 that I would like to be able to convert >> it to Ethernet, if possible. >> >> Do such devices exist? > > Yeah, and it's pretty sweet idea. Haven't used it myself but it seems > really nice. > > > > RAD?s MiRICi-155 connects Gigabit Ethernet LANs over wireline or wireless > STM-1 or OC-3 links. The miniature Ethernet over STM-1/OC-3 converter > provides TDM connectivity to any Ethernet device with an SFP (small form > factor pluggable)-compatible, GbE port. Hot-swappable and > software-configurable, the intelligent SFP converter is a fully managed > device supporting standard GFP encapsulation. It delivers a complete > Ethernet over SDH/SONET solution in a finger-sized SFP enclosure and > enables a quick rollout of new Ethernet services over legacy TDM > infrastructure. The MiRICi-155 is part of RAD?s ?System on an SFP? product > line. > > -- > Mikael Abrahamsson email: swmike at swm.pp.se -- Sent from my mobile device William McCall, CCIE #25044 From ekat at onyxlight.net Thu Sep 9 20:59:18 2010 From: ekat at onyxlight.net (Eric Katanich) Date: Thu, 9 Sep 2010 16:59:18 -0400 Subject: POS to Ethernet Converter In-Reply-To: References: Message-ID: <3887672486120547ACEB7B3ACA6E46EC1B45DD88@exchange> I can vouch for the RAD gear. Pretty simple and to the point. On 9/9/10, Mikael Abrahamsson wrote: > On Thu, 9 Sep 2010, Alan Bryant wrote: > >> We currently have a POS OC-3 that I would like to be able to convert >> it to Ethernet, if possible. >> >> Do such devices exist? > > Yeah, and it's pretty sweet idea. Haven't used it myself but it seems > really nice. > > > > RAD?s MiRICi-155 connects Gigabit Ethernet LANs over wireline or wireless > STM-1 or OC-3 links. The miniature Ethernet over STM-1/OC-3 converter > provides TDM connectivity to any Ethernet device with an SFP (small form > factor pluggable)-compatible, GbE port. Hot-swappable and > software-configurable, the intelligent SFP converter is a fully managed > device supporting standard GFP encapsulation. It delivers a complete > Ethernet over SDH/SONET solution in a finger-sized SFP enclosure and > enables a quick rollout of new Ethernet services over legacy TDM > infrastructure. The MiRICi-155 is part of RAD?s ?System on an SFP? product > line. > > -- > Mikael Abrahamsson email: swmike at swm.pp.se -- Sent from my mobile device William McCall, CCIE #25044 From ekat at onyxlight.net Thu Sep 9 20:59:19 2010 From: ekat at onyxlight.net (Eric Katanich) Date: Thu, 9 Sep 2010 16:59:19 -0400 Subject: ISP port blocking practice In-Reply-To: References: <0A08271D-49B9-4382-9F54-1A0BB6A3F2B2@umich.edu> <13222.1256232797@turing-police.cc.vt.edu> Message-ID: <3887672486120547ACEB7B3ACA6E46EC1B45DD89@exchange> On Thu, Sep 02, 2010 at 04:59:57PM -0500, Zhiyun Qian wrote: > One of the high-level findings is that we developed probing techniques > to verify that indeed most ISPs are only blocking 1) "outgoing traffic > of destination port 25" instead of 2) "incoming traffic with source > port 25", which means that these ISPs are vulnerable to the assymetric > routing attack. Folks interested in port blocking may also find useful another academic work we did a few years ago that sought to broadly characterize the prevalence of port blocking, albeit under the guise of neutrality: http://rbeverly.net/research/papers/truck-pam07.html While we found that email ports (e.g. 25, 110, 143) were more than twice as likely to be blocked than a control port, other ports such as 136 were more widely blocked (136 is an innocuous profile port, but often suffers collateral damage because it lies between the microsoft and netbios 135-139 ports). Also, the asymmetric spam problem is covered in some detail in our 2009 IMC spoofer paper: http://rbeverly.net/research/papers/spoofer-imc09.html rob From ekat at onyxlight.net Thu Sep 9 20:59:19 2010 From: ekat at onyxlight.net (Eric Katanich) Date: Thu, 9 Sep 2010 16:59:19 -0400 Subject: Copyright Enforcement DoS/DDoS Attacks Message-ID: <3887672486120547ACEB7B3ACA6E46EC1B45DD8A@exchange> He mentioned doing work (for hire) in AU and such. I think he may be in for a rude awakening since our past experience with the Australian authorities is they are more active chasing ddos/cyber-crimes than the U.S. Those guys pull out all the stops to prosecute. (Which I am happy to see) Sadly, here in the U.S. you have little to no chance of getting assistance unless the client is a bank or very public company. In fact, that doesn't always work. (Even with direct FBI contacts in multiple field offices) Kind of a shame.. We are likely already tracking his botnets so I almost welcome it as well. Out of curiosity, I did pull some stats over the last 60 days and we have seen more attacks originating from the India area than we have seen in the past 12 months. Maybe it's a coincidence. I would almost bet this guy has never carried out an attack in his life and simply trying to gain some publicity. *shrug* ------Original Message------ From: Jeffrey Lyon To: Beavis Cc: nanog at nanog.org Subject: Re: Copyright Enforcement DoS/DDoS Attacks Sent: Sep 9, 2010 11:43 AM He may get some business out of it, now that he has effectively put out a DDoS for hire ad. Jeff On Thu, Sep 9, 2010 at 8:56 PM, Beavis wrote: > man.. this guy is retarded.. good luck posing your company, face and such. lol > > -- Jeffrey Lyon, Leadership Team jeffrey.lyon at blacklotus.net | http://www.blacklotus.net Black Lotus Communications - AS32421 First and Leading in DDoS Protection Solutions From laidlaw at consecro.com Thu Sep 9 21:03:35 2010 From: laidlaw at consecro.com (Robert laidlaw) Date: Thu, 9 Sep 2010 16:03:35 -0500 Subject: POS to Ethernet Converter In-Reply-To: References: Message-ID: I currently have several dozen ONS 15310-MA's deployed to do exactly that, convert OC12's and OC48's into 1 or 2 gige's. Its a bookend solution, so you need a box for each end of the circuit, but in our case the cost of the two boxes was still cheaper than the router POS interfaces. There are cheaper options compared to Cisco, like the Force10 Traverse series, but for the size and cost of the 15310-MA, its hard to find a better box. There are two model cards that will do the conversion for you, the ML card which operates more like a transparent switch and bridges the traffic, or the CE card which mimics more of a media converter, layer 1 3/4 :-). I use the CE card most often and its works great. For the CE card, the ONS uses GFP can VCAT to mimic a direct physical connection and it can even turn the remote TX laser off if the local RX losses link. If you want more info or a parts list, let me know. The optical division within Cisco is a tricky place to navigate and most of the SE's I have spoken with didn't even want to do anything with the optical side of the business. Some of the interesting things I have learned about the Optical division: - They have literally a thousand times more part numbers than the rest of the division - every part in the chassis order ala carte, and the config tool doesn't build it for you (chassis, fan tray, front door kit, sup card, blanks, etc) - they give you more than enough rope to hang yourself and then some - support is ala carte as well, per piece (chassis, fan tray, sup card, etc :-) GL -Rob On Thu, Sep 9, 2010 at 1:06 PM, Mikael Abrahamsson wrote: > On Thu, 9 Sep 2010, Alan Bryant wrote: > > We currently have a POS OC-3 that I would like to be able to convert >> it to Ethernet, if possible. >> >> Do such devices exist? >> > > Yeah, and it's pretty sweet idea. Haven't used it myself but it seems > really nice. > > > > > RAD?s MiRICi-155 connects Gigabit Ethernet LANs over wireline or wireless > STM-1 or OC-3 links. The miniature Ethernet over STM-1/OC-3 converter > provides TDM connectivity to any Ethernet device with an SFP (small form > factor pluggable)-compatible, GbE port. Hot-swappable and > software-configurable, the intelligent SFP converter is a fully managed > device supporting standard GFP encapsulation. It delivers a complete > Ethernet over SDH/SONET solution in a finger-sized SFP enclosure and enables > a quick rollout of new Ethernet services over legacy TDM infrastructure. The > MiRICi-155 is part of RAD?s ?System on an SFP? product line. > > -- > Mikael Abrahamsson email: swmike at swm.pp.se From sethm at rollernet.us Thu Sep 9 21:04:02 2010 From: sethm at rollernet.us (Seth Mattinen) Date: Thu, 09 Sep 2010 14:04:02 -0700 Subject: POS to Ethernet Converter In-Reply-To: References: Message-ID: <4C894BC2.8030000@rollernet.us> On 9/9/2010 10:59, Alan Bryant wrote: > I did a quick google search for a converter but either I'm not > understanding, or I'm not searching for the right thing. > > We currently have a POS OC-3 that I would like to be able to convert > it to Ethernet, if possible. > > Do such devices exist? > By "convert" do you mean: 1) You have a POS OC-3 from an upstream and you don't want to buy a router that can take a serial OC-3. or 2) You have a PTP OC-3 that you control both ends of and you want to make it into a really long Ethernet cable. ~Seth From ryanshea at google.com Thu Sep 9 21:35:41 2010 From: ryanshea at google.com (Ryan Shea) Date: Thu, 9 Sep 2010 17:35:41 -0400 Subject: Reverse traceroute and spoofing of sources of packets? In-Reply-To: References: Message-ID: According to the presentation they were planning on releasing a downloadable tool by May 2009, but in searching around I found no evidence that this was ever released. -Ryan On Thu, Sep 9, 2010 at 4:22 PM, Christopher Morrow wrote: > > I missed this meeting/preso when it happened (yes, 5+ meetings ago) > > > > I note the talks about using spoofed source packets to do some > measurement, I didn't see anyone in the video say: "But spoofing is > bad, but you want YOU to be able to do this? what? isn't that a little > hypocritical?" > > Isn't it? and why would someone (an isp) disable BCP38 for this sort > of activity? > > -Chris > From james at freedomnet.co.nz Thu Sep 9 22:17:58 2010 From: james at freedomnet.co.nz (James Jones) Date: Thu, 9 Sep 2010 18:17:58 -0400 Subject: Cogent issues In-Reply-To: <4C88C081.3080300@spectraaccess.com> References: <4C88C081.3080300@spectraaccess.com> Message-ID: <6615360C-89D3-408B-BCB6-8AAF9BB1C3C2@freedomnet.co.nz> Verizon had huge fiber break on Friday. It effect a large portion of the north east. It would imagine there would left over issues Sent from my iPhone On Sep 9, 2010, at 7:09 AM, Bret Clark wrote: > We've been noticing high latency for some time with Verizon (UUNET) connections at least through the NY area. > > > On 09/08/2010 10:34 PM, Charles Mills wrote: >> Anyone notice any issues with Cogent? >> >> Internet Health Report showing some high latency to Verizon and a couple of >> other carriers. >> > > From ops.lists at gmail.com Fri Sep 10 01:35:00 2010 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Fri, 10 Sep 2010 07:05:00 +0530 Subject: Copyright Enforcement DoS/DDoS Attacks In-Reply-To: <1661448030-1284062393-cardhu_decombobulator_blackberry.rim.net-881323590-@bda903.bisx.prod.on.blackberry> References: <1661448030-1284062393-cardhu_decombobulator_blackberry.rim.net-881323590-@bda903.bisx.prod.on.blackberry> Message-ID: On Fri, Sep 10, 2010 at 1:29 AM, wrote: > > Kind of a shame.. ?We are likely already tracking his botnets so I almost welcome it as well. Out of curiosity, I did pull some stats over the last 60 days and we have seen more attacks originating from the India area than we have seen in the past 12 months. There's no shortage of botted PCs and wide open dsl providers in India - extremely high # of cbl listings for massmailer bots for example. So could be any number of bots .. not like russian, brazilian etc botmasters arent able to compromise PCs in India, or in Outer Mongolia if they want to. -- Suresh Ramasubramanian (ops.lists at gmail.com) From rdobbins at arbor.net Fri Sep 10 04:30:10 2010 From: rdobbins at arbor.net (Dobbins, Roland) Date: Fri, 10 Sep 2010 04:30:10 +0000 Subject: Sustaining the Internet with hyperbolic mapping In-Reply-To: <20100909102326.GJ14773@leitl.org> References: <20100909102326.GJ14773@leitl.org> Message-ID: <017F51C9-8D56-42F8-AEA7-87CF0AB66E38@arbor.net> On Sep 9, 2010, at 5:23 PM, Eugen Leitl wrote: > http://www.nature.com/ncomms/journal/v1/n6/full/ncomms1063.html At first glance, this looks a bit familiar: ----------------------------------------------------------------------- Roland Dobbins // Sell your computer and buy a guitar. From truman at suspicious.org Fri Sep 10 05:06:51 2010 From: truman at suspicious.org (Truman Boyes) Date: Fri, 10 Sep 2010 13:06:51 +0800 Subject: eBGP Multihop In-Reply-To: <4C7F6E9A.6070203@apolix.co.za> References: <4C7F6E9A.6070203@apolix.co.za> Message-ID: <06F7A2A4-022B-48BB-9034-14155CDE51EA@suspicious.org> On 2 Sep 2010, at 5:30 PM, Graham Beneke wrote: > I have been asked to investigate moving an entire network to multi-hop on all the eBGP sessions. Basically all upstreams, downstreams and peers will eBGP with a route reflector located in the core. This RR will be some kind of quagga or similar box. The dev guys want to be able to poke at the BGP feeds directly and do *magic* that standard router aren't capable of. > > My gut feel is that this is a bad idea. Besides anything else it makes sane link state detection very challenging - especially where we have multiple sessions with a peer. > > Is their any BCP or operational experience that agrees or disagrees with my gut. ;-) > > -- > Graham Beneke Even in lab environments I would say that eBGP multihop is a bad idea. Production networks that try to make money should not embark on such a mission. Trust your gut :) If some box wants to take a feed of routes, it should just iBGP peer with your RRs. Truman From truman at suspicious.org Fri Sep 10 05:10:29 2010 From: truman at suspicious.org (Truman Boyes) Date: Fri, 10 Sep 2010 13:10:29 +0800 Subject: largest OSPF core In-Reply-To: <4C7F9675.8050208@gmail.com> References: <4C7F9675.8050208@gmail.com> Message-ID: On 2 Sep 2010, at 8:20 PM, lorddoskias wrote: > I'm just curious - what is the largest OSPF core (in terms of number of routers) out there? I have seen (as a consultant, not operator) a production SP network that had over 800 routers in the backbone area. The LSDB was rather small as the network only carried links and loopbacks for P/PE routers. All other prefixes were in MP-BGP. Truman From achatz at forthnet.gr Fri Sep 10 07:16:44 2010 From: achatz at forthnet.gr (Tassos Chatzithomaoglou) Date: Fri, 10 Sep 2010 10:16:44 +0300 Subject: Reverse traceroute and spoofing of sources of packets? In-Reply-To: References: Message-ID: <4C89DB5C.2000601@forthnet.gr> http://revtr.cs.washington.edu/ I was also looking for a such a kind of tool some days ago. -- Tassos Ryan Shea wrote on 10/09/2010 00:35: > According to the presentation they were planning on releasing a > downloadable tool by May 2009, but in searching around I found no > evidence that this was ever released. > > -Ryan > > On Thu, Sep 9, 2010 at 4:22 PM, Christopher Morrow > wrote: > >> I missed this meeting/preso when it happened (yes, 5+ meetings ago) >> >> >> >> I note the talks about using spoofed source packets to do some >> measurement, I didn't see anyone in the video say: "But spoofing is >> bad, but you want YOU to be able to do this? what? isn't that a little >> hypocritical?" >> >> Isn't it? and why would someone (an isp) disable BCP38 for this sort >> of activity? >> >> -Chris >> >> > > From sil at infiltrated.net Fri Sep 10 16:49:32 2010 From: sil at infiltrated.net (J. Oquendo) Date: Fri, 10 Sep 2010 12:49:32 -0400 Subject: AT&T Hiccup Message-ID: <4C8A619C.5060904@infiltrated.net> Alright, since things are mighty quiet on a Friday (either that or everyone on NANOG is now blacklisted somehow and I'm not getting mail), I'd figure to go the PITA route (as usual) and I'd ask a simple question worthy of the mandatory responses of: "on topic questions are not the topic of this list!", "this is not the outage list", "how is this related to networking operations" Did anyone see AT&T flake off the face of the map within the last 30-40 minutes? I know I did! (Seriously I did I did!) Client: "We has no Internet" Me: thinking to myself... "they need to call their provider... Due diligence tracepath/ping/isitdownforeveryoneorjustme time... Global --> AT&T looks sketchy" # tracepath 12.200.xx.xx 3: so-1-3-1.585.ar1.JFK1.gblx.net (208.48.236.105) asymm 4 3.416ms 4: po3-40G.ar2.ATL2.gblx.net (67.16.131.198) asymm 7 141.179ms 5: no reply 6: no reply NO REPLY 24 more x 31: no reply Too many hops: pmtu 1500 Resume: pmtu 1500 AnotherClient (seconds later): "We has no VoIP" Me: thinking to myself... "Damnit GBLX not again" Another_Nother_Client (like even seconds after the first: "We has no p2p!" Me: "time to tweet this question... No... post it to facebook... No - make sure I update LinkedIn... wait?! NANOG" Common denominator... All were on AT&T. So, was it only me or did one of AT&T's cores take a long (3-5 minute) hiccup. Post WTFH: # tracepath 12.200.xx.xx 3: so-1-3-1.585.ar1.JFK1.gblx.net (208.48.236.105) asymm 4 3.774ms 4: te4-4-10G.ar5.NYC1.gblx.net (67.16.134.158) asymm 7 189.496ms 5: 192.205.37.137 (192.205.37.137) asymm 7 5.979ms 6: cr1.n54ny.ip.att.net (12.122.81.58) asymm 9 20.088ms 7: cr84.n54ny.ip.att.net (12.122.115.94) asymm 9 19.585ms 8: gar1.chsct.ip.att.net (12.122.105.117) asymm 7 10.234ms 9: 12.91.181.170 (12.91.18x.xxx) asymm 8 24.811ms 10: 12.200.42.67 (12.200.xx.xx) asymm 9 29.104ms reached Resume: pmtu 1500 hops 10 back 9 Just wanted to know if someone else saw it. All clients were spread through the 12.x.x.x block not solely on 12.200.x.x -- =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ J. Oquendo SGFA, SGFE, C|EH, CNDA, CHFI, OSCP, CPT "It takes 20 years to build a reputation and five minutes to ruin it. If you think about that, you'll do things differently." - Warren Buffett 227C 5D35 7DCB 0893 95AA 4771 1DCE 1FD1 5CCD 6B5E http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x5CCD6B5E From reese at inkworkswell.com Fri Sep 10 17:05:48 2010 From: reese at inkworkswell.com (Reese) Date: Fri, 10 Sep 2010 13:05:48 -0400 Subject: Convenience or slippery slope... or something else? Message-ID: A friend brought this to my attention: http://ipq.co/ He saw it at http://news.ycombinator.com/item?id=1678324 I'm not sure whether to shriek in joy or in pain. Will data from this service - if it is a worthy service - propagate properly? Play nicely with or break other people's toys? Is it a gimmick? Reese From jack at crepinc.com Fri Sep 10 17:17:38 2010 From: jack at crepinc.com (Jack Carrozzo) Date: Fri, 10 Sep 2010 13:17:38 -0400 Subject: Convenience or slippery slope... or something else? In-Reply-To: References: Message-ID: It's just a bunch of subdomain A records, what's it matter.... there are already thousands of such services in existence. -Jack Carrozzo On Fri, Sep 10, 2010 at 1:05 PM, Reese wrote: > A friend brought this to my attention: > > http://ipq.co/ > > He saw it at http://news.ycombinator.com/item?id=1678324 > > I'm not sure whether to shriek in joy or in pain. Will data from > this service - if it is a worthy service - propagate properly? > Play nicely with or break other people's toys? Is it a gimmick? > > Reese > > > > From Robert.MacDonald at Haworth.com Fri Sep 10 17:27:28 2010 From: Robert.MacDonald at Haworth.com (Robert MacDonald) Date: Fri, 10 Sep 2010 13:27:28 -0400 Subject: AT&T Hiccup In-Reply-To: <4C8A619C.5060904@infiltrated.net> References: <4C8A619C.5060904@infiltrated.net> Message-ID: No issues with AT&T. Two DS3's in West MI: Qwest towards NYC and AT&T towards Chicago. Now I did have a Qwest issue and it apepars that others towards NYC may have had similar based on route ages of about ~1:45hrs ago. --- Original Message --- From: J. Oquendo [sil at infiltrated.net] Sent: Friday, September 10, 2010 12:49 PM To: NANOG list Alright, since things are mighty quiet on a Friday (either that or everyone on NANOG is now blacklisted somehow and I'm not getting mail), I'd figure to go the PITA route (as usual) and I'd ask a simple question worthy of the mandatory responses of: "on topic questions are not the topic of this list!", "this is not the outage list", "how is this related to networking operations" Did anyone see AT&T flake off the face of the map within the last 30-40 minutes? I know I did! (Seriously I did I did!) Client: "We has no Internet" Me: thinking to myself... "they need to call their provider... Due diligence tracepath/ping/isitdownforeveryoneorjustme time... Global --> AT&T looks sketchy" # tracepath 12.200.xx.xx 3: so-1-3-1.585.ar1.JFK1.gblx.net (208.48.236.105) asymm 4 3.416ms 4: po3-40G.ar2.ATL2.gblx.net (67.16.131.198) asymm 7 141.179ms 5: no reply 6: no reply NO REPLY 24 more x 31: no reply Too many hops: pmtu 1500 Resume: pmtu 1500 AnotherClient (seconds later): "We has no VoIP" Me: thinking to myself... "Damnit GBLX not again" Another_Nother_Client (like even seconds after the first: "We has no p2p!" Me: "time to tweet this question... No... post it to facebook... No - make sure I update LinkedIn... wait?! NANOG" Common denominator... All were on AT&T. So, was it only me or did one of AT&T's cores take a long (3-5 minute) hiccup. Post WTFH: # tracepath 12.200.xx.xx 3: so-1-3-1.585.ar1.JFK1.gblx.net (208.48.236.105) asymm 4 3.774ms 4: te4-4-10G.ar5.NYC1.gblx.net (67.16.134.158) asymm 7 189.496ms 5: 192.205.37.137 (192.205.37.137) asymm 7 5.979ms 6: cr1.n54ny.ip.att.net (12.122.81.58) asymm 9 20.088ms 7: cr84.n54ny.ip.att.net (12.122.115.94) asymm 9 19.585ms 8: gar1.chsct.ip.att.net (12.122.105.117) asymm 7 10.234ms 9: 12.91.181.170 (12.91.18x.xxx) asymm 8 24.811ms 10: 12.200.42.67 (12.200.xx.xx) asymm 9 29.104ms reached Resume: pmtu 1500 hops 10 back 9 Just wanted to know if someone else saw it. All clients were spread through the 12.x.x.x block not solely on 12.200.x.x From jlewis at lewis.org Fri Sep 10 17:44:02 2010 From: jlewis at lewis.org (Jon Lewis) Date: Fri, 10 Sep 2010 13:44:02 -0400 (EDT) Subject: Convenience or slippery slope... or something else? In-Reply-To: References: Message-ID: On Fri, 10 Sep 2010, Reese wrote: > A friend brought this to my attention: > > http://ipq.co/ > > He saw it at http://news.ycombinator.com/item?id=1678324 > > I'm not sure whether to shriek in joy or in pain. Will data from > this service - if it is a worthy service - propagate properly? > Play nicely with or break other people's toys? Is it a gimmick? How's it going to break anything? I just created one... tentententen.ipq.co. 86400 IN A 10.10.10.10 so...now I can use tentententen.ipq.co as a name that resolves to 10.10.10.10...assuming I trust ipq.co to keep that A record and not delete or change it at some point. Other than the fact that you can't change it[1], how is this any different (other than being less useful) or scarier than DynDNS? 1. EMAIL ADDRESS optional, but will allow you to update the record later (once we implement it) ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From cscora at apnic.net Fri Sep 10 18:43:01 2010 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 11 Sep 2010 04:43:01 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <201009101843.o8AIh1wa024117@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. The posting is sent to APOPS, NANOG, AfNOG, AusNOG, SANOG, PacNOG, LacNOG, CaribNOG and the RIPE Routing Working Group. Daily listings are sent to bgp-stats at lists.apnic.net For historical data, please see http://thyme.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 11 Sep, 2010 Report Website: http://thyme.apnic.net Detailed Analysis: http://thyme.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 331078 Prefixes after maximum aggregation: 151868 Deaggregation factor: 2.18 Unique aggregates announced to Internet: 162291 Total ASes present in the Internet Routing Table: 34754 Prefixes per ASN: 9.53 Origin-only ASes present in the Internet Routing Table: 30146 Origin ASes announcing only one prefix: 14627 Transit ASes present in the Internet Routing Table: 4608 Transit-only ASes present in the Internet Routing Table: 104 Average AS path length visible in the Internet Routing Table: 3.6 Max AS path length visible: 35 Max AS path prepend of ASN (45127) 27 Prefixes from unregistered ASNs in the Routing Table: 2342 Unregistered ASNs in the Routing Table: 1103 Number of 32-bit ASNs allocated by the RIRs: 763 Prefixes from 32-bit ASNs in the Routing Table: 1006 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 187 Number of addresses announced to Internet: 2264627392 Equivalent to 134 /8s, 251 /16s and 120 /24s Percentage of available address space announced: 61.1 Percentage of allocated address space announced: 65.2 Percentage of available address space allocated: 93.7 Percentage of address space in use by end-sites: 84.7 Total number of prefixes smaller than registry allocations: 156686 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 80589 Total APNIC prefixes after maximum aggregation: 27550 APNIC Deaggregation factor: 2.93 Prefixes being announced from the APNIC address blocks: 77583 Unique aggregates announced from the APNIC address blocks: 34032 APNIC Region origin ASes present in the Internet Routing Table: 4179 APNIC Prefixes per ASN: 18.56 APNIC Region origin ASes announcing only one prefix: 1166 APNIC Region transit ASes present in the Internet Routing Table: 645 Average APNIC Region AS path length visible: 3.7 Max APNIC Region AS path length visible: 35 Number of APNIC addresses announced to Internet: 543897888 Equivalent to 32 /8s, 107 /16s and 57 /24s Percentage of available APNIC address space announced: 77.2 APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079 55296-56319, 131072-132095 APNIC Address Blocks 1/8, 14/8, 27/8, 43/8, 49/8, 58/8, 59/8, 60/8, 61/8, 101/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, 133/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, 223/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 135897 Total ARIN prefixes after maximum aggregation: 69980 ARIN Deaggregation factor: 1.94 Prefixes being announced from the ARIN address blocks: 108534 Unique aggregates announced from the ARIN address blocks: 42821 ARIN Region origin ASes present in the Internet Routing Table: 13893 ARIN Prefixes per ASN: 7.81 ARIN Region origin ASes announcing only one prefix: 5328 ARIN Region transit ASes present in the Internet Routing Table: 1375 Average ARIN Region AS path length visible: 3.4 Max ARIN Region AS path length visible: 22 Number of ARIN addresses announced to Internet: 733340320 Equivalent to 43 /8s, 181 /16s and 226 /24s Percentage of available ARIN address space announced: 62.4 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, 393216-394239 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, 50/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, 107/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: 75671 Total RIPE prefixes after maximum aggregation: 44053 RIPE Deaggregation factor: 1.72 Prefixes being announced from the RIPE address blocks: 69110 Unique aggregates announced from the RIPE address blocks: 45303 RIPE Region origin ASes present in the Internet Routing Table: 14768 RIPE Prefixes per ASN: 4.68 RIPE Region origin ASes announcing only one prefix: 7593 RIPE Region transit ASes present in the Internet Routing Table: 2218 Average RIPE Region AS path length visible: 3.9 Max RIPE Region AS path length visible: 24 Number of RIPE addresses announced to Internet: 438226944 Equivalent to 26 /8s, 30 /16s and 208 /24s Percentage of available RIPE address space announced: 76.8 RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-52223, 196608-197631 RIPE Address Blocks 2/8, 25/8, 31/8, 46/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, 176/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: 30221 Total LACNIC prefixes after maximum aggregation: 7101 LACNIC Deaggregation factor: 4.26 Prefixes being announced from the LACNIC address blocks: 28778 Unique aggregates announced from the LACNIC address blocks: 15291 LACNIC Region origin ASes present in the Internet Routing Table: 1345 LACNIC Prefixes per ASN: 21.40 LACNIC Region origin ASes announcing only one prefix: 419 LACNIC Region transit ASes present in the Internet Routing Table: 233 Average LACNIC Region AS path length visible: 4.0 Max LACNIC Region AS path length visible: 17 Number of LACNIC addresses announced to Internet: 76470144 Equivalent to 4 /8s, 142 /16s and 215 /24s Percentage of available LACNIC address space announced: 57.0 LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 262144-263167 plus ERX transfers LACNIC Address Blocks 177/8, 181/8, 186/8, 187/8, 189/8, 190/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 7448 Total AfriNIC prefixes after maximum aggregation: 1868 AfriNIC Deaggregation factor: 3.99 Prefixes being announced from the AfriNIC address blocks: 5723 Unique aggregates announced from the AfriNIC address blocks: 1653 AfriNIC Region origin ASes present in the Internet Routing Table: 399 AfriNIC Prefixes per ASN: 14.34 AfriNIC Region origin ASes announcing only one prefix: 121 AfriNIC Region transit ASes present in the Internet Routing Table: 89 Average AfriNIC Region AS path length visible: 3.7 Max AfriNIC Region AS path length visible: 14 Number of AfriNIC addresses announced to Internet: 20156416 Equivalent to 1 /8s, 51 /16s and 144 /24s Percentage of available AfriNIC address space announced: 60.1 AfriNIC AS Blocks 36864-37887, 327680-328703 & 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 1868 8412 500 Korea Telecom (KIX) 4755 1459 367 163 TATA Communications formerly 7545 1364 234 83 TPG Internet Pty Ltd 17488 1346 153 123 Hathway IP Over Cable Interne 17974 1212 296 66 PT TELEKOMUNIKASI INDONESIA 24560 1027 303 177 Bharti Airtel Ltd., Telemedia 9583 1017 76 490 Sify Limited 4808 932 1713 260 CNCGROUP IP network: China169 18101 847 97 127 Reliance Infocom Ltd Internet 9829 818 691 36 BSNL National Internet Backbo Complete listing at http://thyme.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 3807 3667 273 bellsouth.net, inc. 4323 2709 1107 393 Time Warner Telecom 19262 1814 4644 284 Verizon Global Networks 1785 1791 698 131 PaeTec Communications, Inc. 20115 1492 1529 652 Charter Communications 7018 1473 5734 949 AT&T WorldNet Services 6478 1329 273 150 AT&T Worldnet Services 2386 1288 554 906 AT&T Data Communications Serv 11492 1193 227 90 Cable One 22773 1185 2858 61 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 8551 544 353 46 Bezeq International 3292 448 2026 389 TDC Tele Danmark 30890 444 100 212 Evolva Telecom 702 411 1869 324 UUNET - Commercial IP service 8866 404 117 19 Bulgarian Telecommunication C 3301 376 1672 331 TeliaNet Sweden 34984 372 90 184 BILISIM TELEKOM 3320 367 7327 321 Deutsche Telekom AG 12479 357 576 5 Uni2 Autonomous System 31148 336 18 77 FreeNet ISP 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 1505 2908 283 UniNet S.A. de C.V. 10620 1319 247 148 TVCABLE BOGOTA 28573 1120 862 111 NET Servicos de Comunicao S.A 6503 884 194 280 AVANTEL, S.A. 7303 796 408 101 Telecom Argentina Stet-France 14420 569 36 76 CORPORACION NACIONAL DE TELEC 22047 561 310 15 VTR PUNTO NET S.A. 3816 480 209 94 Empresa Nacional de Telecomun 7738 477 922 30 Telecomunicacoes da Bahia S.A 11172 444 99 76 Servicios Alestra S.A de C.V 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 1153 445 10 TEDATA 24863 728 147 39 LINKdotNET AS number 36992 662 279 177 Etisalat MISR 3741 266 906 224 The Internet Solution 33776 209 12 12 Starcomms Nigeria Limited 6713 203 199 12 Itissalat Al-MAGHRIB 29571 198 19 11 Ci Telecom Autonomous system 2018 197 277 64 Tertiary Education Network 24835 190 78 9 RAYA Telecom - Egypt 16637 154 440 97 MTN Network Solutions 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 3807 3667 273 bellsouth.net, inc. 4323 2709 1107 393 Time Warner Telecom 4766 1868 8412 500 Korea Telecom (KIX) 19262 1814 4644 284 Verizon Global Networks 1785 1791 698 131 PaeTec Communications, Inc. 8151 1505 2908 283 UniNet S.A. de C.V. 20115 1492 1529 652 Charter Communications 7018 1473 5734 949 AT&T WorldNet Services 4755 1459 367 163 TATA Communications formerly 7545 1364 234 83 TPG Internet Pty Ltd Complete listing at http://thyme.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 4323 2709 2316 Time Warner Telecom 1785 1791 1660 PaeTec Communications, Inc. 19262 1814 1530 Verizon Global Networks 4766 1868 1368 Korea Telecom (KIX) 4755 1459 1296 TATA Communications formerly 7545 1364 1281 TPG Internet Pty Ltd 17488 1346 1223 Hathway IP Over Cable Interne 8151 1505 1222 UniNet S.A. de C.V. 6478 1329 1179 AT&T Worldnet Services 10620 1319 1171 TVCABLE BOGOTA Complete listing at http://thyme.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 11946 UNALLOCATED 8.12.155.0/24 40913 Quality Technology S 33084 UNALLOCATED 8.15.195.0/24 3356 Level 3 Communicatio 16734 UNALLOCATED 8.18.204.0/24 26914 Global Netoptex, Inc 53562 UNALLOCATED 8.19.94.0/24 3356 Level 3 Communicatio 22015 UNALLOCATED 8.22.137.0/24 14989 Broadview Networks 46856 UNALLOCATED 8.22.184.0/22 3356 Level 3 Communicatio 26169 UNALLOCATED 8.225.177.0/24 20225 TelJet 32249 UNALLOCATED 8.225.178.0/24 3356 Level 3 Communicatio 16927 UNALLOCATED 12.0.252.0/23 7018 AT&T WorldNet Servic 46883 UNALLOCATED 12.4.222.0/24 7018 AT&T WorldNet Servic Complete listing at http://thyme.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 31.0.0.0/16 12654 RIPE NCC RIS Project 31.1.0.0/21 12654 RIPE NCC RIS Project 31.1.24.0/24 12654 RIPE NCC RIS Project 41.222.79.0/24 36938 >>UNKNOWN<< 41.223.196.0/24 36990 Alkan Telecom Ltd 41.223.197.0/24 36990 Alkan Telecom Ltd 41.223.198.0/24 36990 Alkan Telecom Ltd 41.223.199.0/24 36990 Alkan Telecom Ltd 62.61.220.0/24 24974 Tachyon Europe BV - Wireless 62.61.221.0/24 24974 Tachyon Europe BV - Wireless Complete listing at http://thyme.apnic.net/current/data-add-IANA Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:19 /9:10 /10:25 /11:67 /12:199 /13:414 /14:729 /15:1317 /16:11282 /17:5436 /18:9300 /19:18612 /20:23478 /21:23608 /22:30739 /23:30142 /24:172526 /25:1068 /26:1181 /27:703 /28:163 /29:47 /30:6 /31:0 /32:7 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 6389 2427 3807 bellsouth.net, inc. 4766 1490 1868 Korea Telecom (KIX) 4323 1370 2709 Time Warner Telecom 1785 1254 1791 PaeTec Communications, Inc. 10620 1207 1319 TVCABLE BOGOTA 11492 1095 1193 Cable One 17488 1087 1346 Hathway IP Over Cable Interne 18566 1068 1087 Covad Communications 8452 1044 1153 TEDATA 24560 928 1027 Bharti Airtel Ltd., Telemedia Complete listing at http://thyme.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:66 2:10 4:13 8:305 12:2014 13:8 14:2 15:21 16:3 17:9 20:7 24:1445 27:335 31:1 32:60 33:22 38:694 40:97 41:2529 44:3 46:62 47:16 49:1 52:12 55:6 56:2 57:29 58:825 59:498 60:474 61:1082 62:1108 63:1968 64:3734 65:2306 66:3987 67:1865 68:1131 69:2794 70:724 71:371 72:1932 73:2 74:2327 75:279 76:331 77:906 78:650 79:434 80:993 81:812 82:490 83:442 84:679 85:1040 86:448 87:686 88:323 89:1550 90:96 91:3004 92:424 93:989 94:1170 95:692 96:510 97:218 98:622 99:34 101:1 108:64 109:665 110:499 111:573 112:298 113:298 114:451 115:584 116:1096 117:657 118:508 119:874 120:141 121:709 122:1543 123:928 124:1214 125:1240 128:226 129:157 130:169 131:539 132:258 133:17 134:196 135:46 136:222 137:137 138:272 139:107 140:478 141:197 142:343 143:351 144:474 145:54 146:420 147:169 148:665 149:303 150:152 151:233 152:287 153:170 154:3 155:362 156:167 157:332 158:112 159:358 160:313 161:183 162:271 163:167 164:417 165:368 166:468 167:422 168:649 169:156 170:727 171:61 172:2 173:1045 174:487 175:167 176:1 177:1 178:462 180:641 181:1 182:208 183:236 184:155 186:606 187:522 188:806 189:806 190:4109 192:5771 193:4734 194:3436 195:2797 196:1226 198:3579 199:3570 200:5439 201:1598 202:8091 203:8265 204:4020 205:2393 206:2529 207:3068 208:3880 209:3466 210:2554 211:1291 212:1782 213:1683 214:660 215:67 216:4784 217:1592 218:473 219:398 220:1143 221:386 222:313 223:40 End of report From dmm at 1-4-5.net Fri Sep 10 18:34:34 2010 From: dmm at 1-4-5.net (David Meyer) Date: Fri, 10 Sep 2010 11:34:34 -0700 Subject: [NANOG-announce] NANOG 50 agenda posted! Message-ID: Please see http://www.nanog.org/meetings/nanog50/agenda.php. A few dates of interest: (i). The registration fee increases on September 22. (ii). The special group rate at the hotel expires September 15. We're looking forward to seeing you all in Atlanta. Thanks, Dave (for the NANOG PC) -------------- next part -------------- _______________________________________________ NANOG-announce mailing list NANOG-announce at nanog.org https://mailman.nanog.org/mailman/listinfo/nanog-announce From fernando at gont.com.ar Fri Sep 10 20:04:51 2010 From: fernando at gont.com.ar (Fernando Gont) Date: Fri, 10 Sep 2010 17:04:51 -0300 Subject: List of Teredo servers and teredo relays Message-ID: <4C8A8F63.9020400@gont.com.ar> Hi, Does any body maintain a list of Teredo servers and Teredo relays? Thanks! Kind regards, -- Fernando Gont e-mail: fernando at gont.com.ar || fgont at acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From cidr-report at potaroo.net Fri Sep 10 22:00:05 2010 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 10 Sep 2010 22:00:05 GMT Subject: BGP Update Report Message-ID: <201009102200.o8AM05nW008746@wattle.apnic.net> BGP Update Report Interval: 02-Sep-10 -to- 09-Sep-10 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS8151 31195 2.6% 4.3 -- Uninet S.A. de C.V. 2 - AS35567 29787 2.5% 286.4 -- DASTO-BOSNIA-AS DASTO semtel d.o.o. 3 - AS3464 21780 1.8% 1815.0 -- 4 - AS32528 17666 1.5% 2944.3 -- ABBOTT Abbot Labs 5 - AS13880 17346 1.5% 2478.0 -- 6 - AS9829 17122 1.4% 60.3 -- BSNL-NIB National Internet Backbone 7 - AS5536 16891 1.4% 155.0 -- Internet-Egypt 8 - AS6298 15283 1.3% 17.5 -- 9 - AS23700 12043 1.0% 25.1 -- BM-AS-ID PT. Broadband Multimedia, Tbk 10 - AS3816 8729 0.7% 24.5 -- COLOMBIA TELECOMUNICACIONES S.A. ESP 11 - AS17974 8434 0.7% 9.0 -- TELKOMNET-AS2-AP PT Telekomunikasi Indonesia 12 - AS35931 8381 0.7% 2793.7 -- 13 - AS16718 8160 0.7% 582.9 -- 14 - AS7552 7871 0.7% 13.6 -- VIETEL-AS-AP Vietel Corporation 15 - AS21017 7458 0.6% 128.6 -- VSI-AS VSI AS 16 - AS45464 7093 0.6% 236.4 -- NEXTWEB-AS-AP Room 201, TGU Bldg 17 - AS36129 6965 0.6% 3482.5 -- 18 - AS8452 6838 0.6% 7.1 -- TE-AS TE-AS 19 - AS39435 6322 0.5% 119.3 -- EVOLGOGRAD-AS CJSC "ER-Telecom Company" Vologograd Autonomous System 20 - AS45951 5939 0.5% 144.9 -- AUGERE-AS-AP Augere Wireless Broadband Bangladesh Limited TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS36129 6965 0.6% 3482.5 -- 2 - AS32528 17666 1.5% 2944.3 -- ABBOTT Abbot Labs 3 - AS35931 8381 0.7% 2793.7 -- 4 - AS13880 17346 1.5% 2478.0 -- 5 - AS3464 21780 1.8% 1815.0 -- 6 - AS17029 1148 0.1% 1148.0 -- 7 - AS1959 2209 0.2% 736.3 -- 8 - AS15984 728 0.1% 728.0 -- The Joint-Stock Commercial Bank CentroCredit. 9 - AS11613 728 0.1% 728.0 -- 10 - AS2 667 0.1% 177.0 -- UPOU-LB-AS-AP University of the Philippines - Open University Los Banos Campus 11 - AS16718 8160 0.7% 582.9 -- 12 - AS18163 2241 0.2% 560.2 -- JINJU18163-AS-KR jinju national university 13 - AS11384 556 0.1% 556.0 -- 14 - AS16861 480 0.0% 480.0 -- 15 - AS32211 2324 0.2% 464.8 -- 16 - AS21530 452 0.0% 452.0 -- 17 - AS37204 3934 0.3% 393.4 -- TELONE 18 - AS35894 348 0.0% 348.0 -- 19 - AS15384 696 0.1% 348.0 -- CD CONTACT DIRECT AS 15384 20 - AS31403 343 0.0% 343.0 -- INVA-AS IN.VA.'s Autonomous System TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 129.66.128.0/17 10864 0.9% AS3464 -- 2 - 129.66.0.0/17 10863 0.9% AS3464 -- 3 - 130.36.34.0/24 8829 0.7% AS32528 -- ABBOTT Abbot Labs 4 - 130.36.35.0/24 8826 0.7% AS32528 -- ABBOTT Abbot Labs 5 - 190.65.228.0/22 5477 0.4% AS3816 -- COLOMBIA TELECOMUNICACIONES S.A. ESP 6 - 63.211.68.0/22 4877 0.4% AS35931 -- 7 - 195.39.181.0/24 4274 0.3% AS1 -- AS6755 -- ASN - TURNET AS9155 -- QNET QualityNet AS number 8 - 8.8.178.0/24 3694 0.3% AS36129 -- 9 - 95.32.192.0/18 3605 0.3% AS21017 -- VSI-AS VSI AS 10 - 216.126.136.0/22 3517 0.3% AS6316 -- 11 - 95.32.128.0/18 3508 0.3% AS21017 -- VSI-AS VSI AS 12 - 198.140.43.0/24 3482 0.3% AS35931 -- 13 - 213.196.76.0/24 3479 0.3% AS35567 -- DASTO-BOSNIA-AS DASTO semtel d.o.o. 14 - 213.196.78.0/24 3479 0.3% AS35567 -- DASTO-BOSNIA-AS DASTO semtel d.o.o. 15 - 213.196.79.0/24 3479 0.3% AS35567 -- DASTO-BOSNIA-AS DASTO semtel d.o.o. 16 - 213.196.77.0/24 3479 0.3% AS35567 -- DASTO-BOSNIA-AS DASTO semtel d.o.o. 17 - 213.196.72.0/24 3473 0.3% AS35567 -- DASTO-BOSNIA-AS DASTO semtel d.o.o. 18 - 213.196.75.0/24 3473 0.3% AS35567 -- DASTO-BOSNIA-AS DASTO semtel d.o.o. 19 - 213.196.74.0/24 3473 0.3% AS35567 -- DASTO-BOSNIA-AS DASTO semtel d.o.o. 20 - 213.196.73.0/24 3473 0.3% AS35567 -- DASTO-BOSNIA-AS DASTO semtel d.o.o. 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 Sep 10 22:00:00 2010 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 10 Sep 2010 22:00:00 GMT Subject: The Cidr Report Message-ID: <201009102200.o8AM00Dc008741@wattle.apnic.net> This report has been generated at Fri Sep 10 21:12:21 2010 AEST. The report analyses the BGP Routing Table of AS2.0 router and generates a report on aggregation potential within the table. Check http://www.cidr-report.org for a current version of this report. Recent Table History Date Prefixes CIDR Agg 03-09-10 335608 206419 04-09-10 335605 206566 05-09-10 335543 206762 06-09-10 335821 206959 07-09-10 336034 207222 08-09-10 336046 207259 09-09-10 336231 207455 10-09-10 335938 207673 AS Summary 35344 Number of ASes in routing system 15034 Number of ASes announcing only one prefix 4447 Largest number of prefixes announced by an AS AS4323 : 97312512 Largest address span announced by an AS (/32s) AS4134 : CHINANET-BACKBONE No.31,Jin-rong Street 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'). --- 10Sep10 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 336434 207648 128786 38.3% All ASes AS6389 3807 280 3527 92.6% AS4323 4447 1907 2540 57.1% AS19262 1815 285 1530 84.3% AS4766 1868 514 1354 72.5% KIXS-AS-KR Korea Telecom AS22773 1185 66 1119 94.4% AS4755 1459 402 1057 72.4% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP AS17488 1346 292 1054 78.3% HATHWAY-NET-AP Hathway IP Over Cable Internet AS5668 1132 89 1043 92.1% AS18566 1087 63 1024 94.2% AS13343 1603 585 1018 63.5% AS10620 1319 343 976 74.0% Telmex Colombia S.A. AS6478 1329 423 906 68.2% AS8151 1506 661 845 56.1% Uninet S.A. de C.V. AS1785 1792 958 834 46.5% AS8452 1152 410 742 64.4% TE-AS TE-AS AS7545 1382 689 693 50.1% TPG-INTERNET-AP TPG Internet Pty Ltd AS7303 796 115 681 85.6% Telecom Argentina S.A. AS4808 932 303 629 67.5% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network AS4804 677 73 604 89.2% MPX-AS Microplex PTY LTD AS7552 648 103 545 84.1% VIETEL-AS-AP Vietel Corporation AS28573 1121 582 539 48.1% NET Servicos de Comunicao S.A. AS4780 698 165 533 76.4% SEEDNET Digital United Inc. AS17676 605 76 529 87.4% GIGAINFRA Softbank BB Corp. AS18101 847 325 522 61.6% RIL-IDC Reliance Infocom Ltd Internet Data Centre, AS7018 1472 953 519 35.3% AS7011 1153 664 489 42.4% AS14420 569 84 485 85.2% CORPORACION NACIONAL DE TELECOMUNICACIONES - CNT EP AS24560 1027 544 483 47.0% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services AS22047 561 79 482 85.9% VTR BANDA ANCHA S.A. AS3356 1140 675 465 40.8% LEVEL3 Level 3 Communications Total 40475 12708 27767 68.6% Top 30 total Possible Bogus Routes 31.0.0.0/16 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 31.1.0.0/21 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 31.1.24.0/24 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 41.222.79.0/24 AS36938 AMSCOTELECOMS Amsco Telecommunications Nigeria Limited 41.223.196.0/24 AS36990 41.223.197.0/24 AS36990 41.223.198.0/24 AS36990 41.223.199.0/24 AS36990 49.0.0.0/24 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 49.50.0.0/22 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 49.255.0.0/16 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV 62.61.221.0/24 AS24974 TACHYON-EU Tachyon Europe BV 64.20.80.0/20 AS40028 64.21.192.0/20 AS11610 64.21.212.0/22 AS11610 64.21.216.0/21 AS11610 64.82.128.0/19 AS16617 64.82.160.0/19 AS16617 66.180.239.0/24 AS35888 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.47.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 66.207.32.0/20 AS23011 66.230.240.0/20 AS27286 66.245.176.0/20 AS19318 69.6.80.0/24 AS13442 69.6.81.0/24 AS13442 71.19.134.0/23 AS3313 INET-AS I.NET S.p.A. 71.19.160.0/23 AS4648 NZIX-2 Netgate 72.22.32.0/19 AS33150 72.22.61.0/24 AS33150 72.22.62.0/24 AS33150 76.77.32.0/19 AS2828 80.88.10.0/24 AS33774 DJAWEB 80.88.12.0/24 AS33779 wataniya-telecom-as 96.45.160.0/24 AS3257 TINET-BACKBONE Tinet SpA 96.45.161.0/24 AS3257 TINET-BACKBONE Tinet SpA 96.45.162.0/24 AS3257 TINET-BACKBONE Tinet SpA 96.45.163.0/24 AS3257 TINET-BACKBONE Tinet SpA 96.45.164.0/24 AS3257 TINET-BACKBONE Tinet SpA 96.45.165.0/24 AS3257 TINET-BACKBONE Tinet SpA 96.45.166.0/24 AS3257 TINET-BACKBONE Tinet SpA 96.45.167.0/24 AS3257 TINET-BACKBONE Tinet SpA 96.45.168.0/21 AS3257 TINET-BACKBONE Tinet SpA 96.47.48.0/20 AS3257 TINET-BACKBONE Tinet SpA 101.0.0.0/24 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 101.50.0.0/22 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 101.255.0.0/16 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 110.34.44.0/22 AS12653 COMTONET KB Impuls Hellas 110.173.64.0/19 AS37963 CNNIC-ALIBABA-CN-NET-AP Alibaba (China) Technology Co., Ltd. 116.68.136.0/21 AS28045 Pantel Communications 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.168.0/21 AS9931 CAT-AP The Communication Authoity of Thailand, CAT 158.222.70.0/23 AS6137 158.222.72.0/23 AS6137 158.222.224.0/20 AS19864 158.222.224.0/22 AS19864 158.222.229.0/24 AS19864 173.225.112.0/20 AS3257 TINET-BACKBONE Tinet SpA 176.0.0.0/16 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 176.1.0.0/21 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 176.1.24.0/24 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 177.0.0.0/16 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 177.1.0.0/21 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 177.1.8.0/24 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 181.0.0.0/16 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 181.1.0.0/21 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 181.1.8.0/24 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 190.102.32.0/20 AS30058 ACTIVO-SYSTEMS-AS30058 ACTIVO-SYSTEMS-AS30058 192.9.0.0/16 AS11479 192.64.85.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.69.108.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.101.46.0/24 AS6503 Axtel, S.A.B. de C. V. 192.101.64.0/21 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 192.101.70.0/24 AS701 192.101.71.0/24 AS701 192.101.72.0/24 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 192.101.74.0/24 AS1239 192.124.252.0/22 AS680 DFN-IP service X-WiN 192.131.233.0/24 AS6389 192.154.32.0/19 AS81 192.154.64.0/19 AS81 192.188.208.0/20 AS27064 196.2.224.0/22 AS24863 LINKdotNET-AS 196.6.108.0/24 AS5713 SAIX-NET 196.13.201.0/24 AS2018 TENET-1 196.13.202.0/24 AS2018 TENET-1 196.13.203.0/24 AS2018 TENET-1 196.13.204.0/24 AS2018 TENET-1 196.110.105.0/24 AS8513 SKYVISION SkyVision Network Services 196.201.248.0/24 AS30991 SAHANNET Sahannet AS Network 196.201.249.0/24 AS30991 SAHANNET Sahannet AS Network 196.201.250.0/24 AS30991 SAHANNET Sahannet AS Network 196.201.251.0/24 AS30991 SAHANNET Sahannet AS Network 196.201.253.0/24 AS30991 SAHANNET Sahannet AS Network 196.201.255.0/24 AS30991 SAHANNET Sahannet AS Network 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 198.51.100.0/24 AS16953 198.73.210.0/24 AS21570 198.74.38.0/24 AS16966 198.74.39.0/24 AS16966 198.74.40.0/24 AS16966 198.97.72.0/21 AS27064 198.97.96.0/19 AS27064 198.97.240.0/20 AS27064 198.99.241.0/24 AS11797 AC-NIELSEN-AS AC NIELSEN 198.135.236.0/24 AS4358 198.161.87.0/24 AS6539 198.163.214.0/24 AS21804 198.167.0.0/16 AS7456 198.168.0.0/16 AS701 198.169.0.0/16 AS803 198.180.198.0/24 AS23715 SEOUL-INTGW-GXS-AP Global Exchange Services 198.182.235.0/24 AS3356 LEVEL3 Level 3 Communications 199.10.0.0/16 AS721 199.16.32.0/19 AS6389 199.121.0.0/16 AS27064 199.123.16.0/20 AS27064 199.185.130.0/23 AS19662 199.202.0.0/16 AS701 199.202.216.0/21 AS577 199.233.92.0/24 AS26896 199.246.116.0/24 AS813 200.24.73.0/24 AS26061 Equant Colombia 200.24.78.0/26 AS3549 GBLX Global Crossing Ltd. 200.24.78.64/26 AS3549 GBLX Global Crossing Ltd. 202.9.55.0/24 AS2764 AAPT AAPT Limited 202.9.57.0/24 AS2764 AAPT AAPT Limited 202.38.63.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.58.113.0/24 AS19161 202.61.75.0/24 AS9927 PHILCOMNET-PH A Multihomed ISP Company 202.66.128.0/18 AS9584 GENESIS-AP Diyixian.com Limited 202.66.160.0/19 AS9584 GENESIS-AP Diyixian.com Limited 202.66.160.0/20 AS9584 GENESIS-AP Diyixian.com Limited 202.66.176.0/20 AS9584 GENESIS-AP Diyixian.com Limited 202.66.184.0/24 AS9584 GENESIS-AP Diyixian.com Limited 202.66.186.0/24 AS9584 GENESIS-AP Diyixian.com Limited 202.66.188.0/24 AS9584 GENESIS-AP Diyixian.com Limited 202.66.189.0/24 AS9584 GENESIS-AP Diyixian.com Limited 202.66.190.0/24 AS9584 GENESIS-AP Diyixian.com Limited 202.73.144.0/20 AS4788 TMNET-AS-AP TM Net, Internet Service Provider 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.133.37.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.150.227.0/24 AS17727 NAPINFO-AS-AP PT. NAP Info Lintas Nusa 202.174.70.0/24 AS21175 WIS WIS S.A. : WIND International Services 202.174.125.0/24 AS9498 BBIL-AP BHARTI Airtel Ltd. 202.174.125.128/26 AS9498 BBIL-AP BHARTI Airtel Ltd. 202.176.1.0/24 AS9942 COMINDICO-AP SOUL Converged Communications Australia 202.179.131.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.179.133.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.179.134.0/24 AS23966 LDN-AS-PK LINKdotNET Telecom Limited 202.179.144.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.179.149.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.179.150.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 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.99.140.0/24 AS45227 VISTA-SKYDIO-PTE-LTD-AP Vista datacenter Skydio Pte Ltd 203.99.141.0/24 AS45227 VISTA-SKYDIO-PTE-LTD-AP Vista datacenter Skydio Pte 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.175.98.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 203.175.99.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 203.175.103.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 203.175.107.0/24 AS45595 PKTELECOM-AS-PK Pakistan Telecom Company Limited 203.175.110.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 203.202.238.0/24 AS45227 VISTA-SKYDIO-PTE-LTD-AP Vista datacenter Skydio Pte Ltd 204.9.216.0/23 AS6389 204.10.232.0/21 AS33150 204.19.14.0/23 AS577 204.28.104.0/21 AS25973 204.197.0.0/16 AS3356 LEVEL3 Level 3 Communications 204.209.114.0/24 AS13768 204.238.70.0/24 AS36826 205.150.0.0/15 AS701 205.189.134.0/24 AS11814 205.196.24.0/22 AS33724 205.210.145.0/24 AS11814 206.72.192.0/23 AS27375 206.72.194.0/23 AS27375 206.72.209.0/24 AS16526 206.123.129.0/24 AS10790 206.180.240.0/20 AS12083 206.197.184.0/24 AS23304 207.174.131.0/24 AS26116 207.174.132.0/23 AS26116 207.174.152.0/23 AS26116 207.174.154.0/24 AS26116 207.174.155.0/24 AS26116 207.174.188.0/24 AS26116 207.174.189.0/24 AS26116 207.174.190.0/24 AS26116 207.174.191.0/24 AS26116 207.174.200.0/24 AS22658 207.174.248.0/21 AS6653 207.231.96.0/19 AS11194 208.64.200.0/22 AS11730 208.64.240.0/21 AS13871 208.73.4.0/22 AS27630 208.78.164.0/24 AS16565 208.78.165.0/24 AS16565 208.78.167.0/24 AS16565 208.84.76.0/22 AS18561 208.92.196.0/22 AS10929 209.54.123.0/24 AS6062 209.105.224.0/19 AS20074 209.165.239.0/24 AS209 209.213.0.0/20 AS33005 209.213.1.0/24 AS7849 209.213.4.0/24 AS7849 209.236.96.0/20 AS3257 TINET-BACKBONE Tinet SpA 210.5.128.0/20 AS4837 CHINA169-BACKBONE CNCGROUP China169 Backbone 210.56.150.0/23 AS38138 INTECH-TRANSIT-BD InTech Online Limited, INTERNET SERVICE LIMITED 210.247.224.0/19 AS7496 WEBCENTRAL-AS WebCentral 216.10.235.0/24 AS13780 216.10.236.0/24 AS13780 216.21.196.0/24 AS12251 216.21.201.0/24 AS12251 216.21.202.0/24 AS12251 216.21.206.0/23 AS12251 216.47.32.0/20 AS3257 TINET-BACKBONE Tinet SpA 216.58.192.0/24 AS22702 216.58.197.0/24 AS22702 216.58.200.0/24 AS18530 216.172.198.0/24 AS22773 216.172.199.0/24 AS22773 216.250.112.0/20 AS7296 216.250.116.0/24 AS36066 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 leigh.porter at ukbroadband.com Fri Sep 10 22:05:04 2010 From: leigh.porter at ukbroadband.com (Leigh Porter) Date: Fri, 10 Sep 2010 23:05:04 +0100 Subject: Convenience or slippery slope... or something else? In-Reply-To: References: Message-ID: <92495213-00AF-4359-A94E-ABBA6D5BD84E@ukbroadband.com> You need to go to qqwqaaqws.ipq.co to find out more... On 10 Sep 2010, at 18:44, Jon Lewis wrote: > On Fri, 10 Sep 2010, Reese wrote: > >> A friend brought this to my attention: >> >> http://ipq.co/ >> >> He saw it at http://news.ycombinator.com/item?id=1678324 >> >> I'm not sure whether to shriek in joy or in pain. Will data from >> this service - if it is a worthy service - propagate properly? >> Play nicely with or break other people's toys? Is it a gimmick? > > How's it going to break anything? I just created one... > > tentententen.ipq.co. 86400 IN A 10.10.10.10 > > so...now I can use tentententen.ipq.co as a name that resolves to 10.10.10.10...assuming I trust ipq.co to keep that A record and not delete or change it at some point. Other than the fact that you can't change it[1], how is this any different (other than being less useful) or scarier than DynDNS? > > > 1. EMAIL ADDRESS > optional, but will allow you to update the record later (once we implement it) > > ---------------------------------------------------------------------- > Jon Lewis, MCP :) | I route > Senior Network Engineer | therefore you are > Atlantic Net | > _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ > From tony at lava.net Fri Sep 10 23:11:43 2010 From: tony at lava.net (Antonio Querubin) Date: Fri, 10 Sep 2010 13:11:43 -1000 (HST) Subject: List of Teredo servers and teredo relays In-Reply-To: <4C8A8F63.9020400@gont.com.ar> References: <4C8A8F63.9020400@gont.com.ar> Message-ID: On Fri, 10 Sep 2010, Fernando Gont wrote: > Does any body maintain a list of Teredo servers and Teredo relays? A list of public Teredo servers might be useful. But a list of public relays - not so much. If you google around you'll eventually stumble across the following public servers: teredo.ipv6.microsoft.com teredo.remlab.net teredo2.remlab.net debian-miredo.progsoc.org teredo.ginzado.ne.jp teredo.iks-jena.de The first is the default for Windows. The second is the initial default for most Miredo installs. The fourth is supposedly the default for the Debian Miredo package. You can get an idea of where some public relays might be at: http://www.bgpmon.net/teredo.php But there may be a bunch of others not listed. The relay used varies on a per-connection basis. It'll generally be the closest relay to the non-teredo host. Antonio Querubin 808-545-5282 x3003 e-mail/xmpp: tony at lava.net From morrowc.lists at gmail.com Sat Sep 11 15:39:05 2010 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Sat, 11 Sep 2010 11:39:05 -0400 Subject: Convenience or slippery slope... or something else? In-Reply-To: References: Message-ID: On Fri, Sep 10, 2010 at 1:05 PM, Reese wrote: > A friend brought this to my attention: > > http://ipq.co/ as an aside: note the cert in used for the NIC's website... surely the .CO ccTLD could use a real cert? -chris From morrowc.lists at gmail.com Sat Sep 11 15:43:26 2010 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Sat, 11 Sep 2010 11:43:26 -0400 Subject: Convenience or slippery slope... or something else? In-Reply-To: References: Message-ID: On Sat, Sep 11, 2010 at 11:39 AM, Christopher Morrow wrote: > On Fri, Sep 10, 2010 at 1:05 PM, Reese wrote: >> A friend brought this to my attention: >> >> http://ipq.co/ > > as an aside: > > > > note the cert in used for the NIC's website... surely the .CO ccTLD > could use a real cert? also it's not clear that the ipq.co service is really all that robust (if that'd matter to anyone) since ipq.co's nameservers: ;; QUESTION SECTION: ;ipq.co. IN NS ;; AUTHORITY SECTION: ipq.co. 900 IN NS A.NS.ipq.co. ipq.co. 900 IN NS B.NS.ipq.co. ;; ADDITIONAL SECTION: A.NS.ipq.co. 900 IN A 212.110.169.105 B.NS.ipq.co. 900 IN A 212.110.169.105 are the same host/ip. From jared at puck.nether.net Sat Sep 11 16:28:04 2010 From: jared at puck.nether.net (Jared Mauch) Date: Sat, 11 Sep 2010 12:28:04 -0400 Subject: List of Teredo servers and teredo relays In-Reply-To: References: <4C8A8F63.9020400@gont.com.ar> Message-ID: <4086450A-224E-4D0D-BCFE-57A985A318CA@puck.nether.net> I would be careful actually using teredo, as some of them (eg: Microsoft) have swaths of native IPv6 networks that are unreachable. I'm hoping they will correct some of the problems with it, but it makes IPv6 harder to use for some people as the Microsoft one does not appear to be well supported/connected. I'm not sure if there is an effort under way on Microsofts behalf to correct this, but I hope so. - Jared On Sep 10, 2010, at 7:11 PM, Antonio Querubin wrote: > On Fri, 10 Sep 2010, Fernando Gont wrote: > >> Does any body maintain a list of Teredo servers and Teredo relays? > > A list of public Teredo servers might be useful. But a list of public relays - not so much. > > If you google around you'll eventually stumble across the following public servers: > > teredo.ipv6.microsoft.com > teredo.remlab.net > teredo2.remlab.net > debian-miredo.progsoc.org > teredo.ginzado.ne.jp > teredo.iks-jena.de > > The first is the default for Windows. The second is the initial default for most Miredo installs. The fourth is supposedly the default for the Debian Miredo package. > > You can get an idea of where some public relays might be at: > > http://www.bgpmon.net/teredo.php > > But there may be a bunch of others not listed. The relay used varies on a per-connection basis. It'll generally be the closest relay to the non-teredo host. > > Antonio Querubin > 808-545-5282 x3003 > e-mail/xmpp: tony at lava.net From owen at delong.com Sat Sep 11 17:28:31 2010 From: owen at delong.com (Owen DeLong) Date: Sat, 11 Sep 2010 10:28:31 -0700 Subject: List of Teredo servers and teredo relays In-Reply-To: <4086450A-224E-4D0D-BCFE-57A985A318CA@puck.nether.net> References: <4C8A8F63.9020400@gont.com.ar> <4086450A-224E-4D0D-BCFE-57A985A318CA@puck.nether.net> Message-ID: Even Micr0$0ft refers to Teredo as "The absolute last resort for IPv6 connectivity". Owen On Sep 11, 2010, at 9:28 AM, Jared Mauch wrote: > I would be careful actually using teredo, as some of them (eg: Microsoft) have swaths of native IPv6 networks that are unreachable. > > I'm hoping they will correct some of the problems with it, but it makes IPv6 harder to use for some people as the Microsoft one does not appear to be well supported/connected. I'm not sure if there is an effort under way on Microsofts behalf to correct this, but I hope so. > > - Jared > > On Sep 10, 2010, at 7:11 PM, Antonio Querubin wrote: > >> On Fri, 10 Sep 2010, Fernando Gont wrote: >> >>> Does any body maintain a list of Teredo servers and Teredo relays? >> >> A list of public Teredo servers might be useful. But a list of public relays - not so much. >> >> If you google around you'll eventually stumble across the following public servers: >> >> teredo.ipv6.microsoft.com >> teredo.remlab.net >> teredo2.remlab.net >> debian-miredo.progsoc.org >> teredo.ginzado.ne.jp >> teredo.iks-jena.de >> >> The first is the default for Windows. The second is the initial default for most Miredo installs. The fourth is supposedly the default for the Debian Miredo package. >> >> You can get an idea of where some public relays might be at: >> >> http://www.bgpmon.net/teredo.php >> >> But there may be a bunch of others not listed. The relay used varies on a per-connection basis. It'll generally be the closest relay to the non-teredo host. >> >> Antonio Querubin >> 808-545-5282 x3003 >> e-mail/xmpp: tony at lava.net > From jeff-kell at utc.edu Sat Sep 11 18:39:45 2010 From: jeff-kell at utc.edu (Jeff Kell) Date: Sat, 11 Sep 2010 14:39:45 -0400 Subject: List of Teredo servers and teredo relays In-Reply-To: References: <4C8A8F63.9020400@gont.com.ar> <4086450A-224E-4D0D-BCFE-57A985A318CA@puck.nether.net> Message-ID: <4C8BCCF1.5080208@utc.edu> On 9/11/2010 1:28 PM, Owen DeLong wrote: > Even Micr0$0ft refers to Teredo as "The absolute last resort for IPv6 connectivity". > Yeah, but "they'll take it over IPv4 if they can get it" :-( Jeff From khatfield at socllc.net Sat Sep 11 19:29:33 2010 From: khatfield at socllc.net (khatfield at socllc.net) Date: Sat, 11 Sep 2010 19:29:33 +0000 Subject: List of Teredo servers and teredo relays Message-ID: <208008211-1284233373-cardhu_decombobulator_blackberry.rim.net-976534877-@bda903.bisx.prod.on.blackberry> I may be missing the point here completely but to me Teredo just seems like a glorified hack/workaround for a bigger problem. Isn't is better (yes less cost-effective) to just upgrade equipment? I really don't see the advantage here. Maybe someone can explain away my ignorance to the concept? ------Original Message------ From: Antonio Querubin To: Fernando Gont Cc: NANOG Subject: Re: List of Teredo servers and teredo relays Sent: Sep 10, 2010 6:11 PM On Fri, 10 Sep 2010, Fernando Gont wrote: > Does any body maintain a list of Teredo servers and Teredo relays? A list of public Teredo servers might be useful. But a list of public relays - not so much. If you google around you'll eventually stumble across the following public servers: teredo.ipv6.microsoft.com teredo.remlab.net teredo2.remlab.net debian-miredo.progsoc.org teredo.ginzado.ne.jp teredo.iks-jena.de The first is the default for Windows. The second is the initial default for most Miredo installs. The fourth is supposedly the default for the Debian Miredo package. You can get an idea of where some public relays might be at: http://www.bgpmon.net/teredo.php But there may be a bunch of others not listed. The relay used varies on a per-connection basis. It'll generally be the closest relay to the non-teredo host. Antonio Querubin 808-545-5282 x3003 e-mail/xmpp: tony at lava.net From jeff-kell at utc.edu Sat Sep 11 20:22:33 2010 From: jeff-kell at utc.edu (Jeff Kell) Date: Sat, 11 Sep 2010 16:22:33 -0400 Subject: List of Teredo servers and teredo relays In-Reply-To: <208008211-1284233373-cardhu_decombobulator_blackberry.rim.net-976534877-@bda903.bisx.prod.on.blackberry> References: <208008211-1284233373-cardhu_decombobulator_blackberry.rim.net-976534877-@bda903.bisx.prod.on.blackberry> Message-ID: <4C8BE509.1090904@utc.edu> On 9/11/2010 3:29 PM, khatfield at socllc.net wrote: > I may be missing the point here completely but to me Teredo just seems like a glorified hack/workaround for a bigger problem. Isn't is better (yes less cost-effective) to just upgrade equipment? > > I really don't see the advantage here. Maybe someone can explain away my ignorance to the concept? > Teredo is a "last-ditch" solution, but unfortunately in the Microsoft world, and acceptable and preferable solution over IPv4. Pure speculation, but the IPv6 efforts of many (looking at current MacOS, Windows, and a growing segment of PDAs/phones) are making tremendous effort to obtain "some" form of IPv6 connectivity. This makes sense if there were (a) only IPv6 connectivity at the client endpoint, or (b) only IPv6 connectivity at the service endpoint. That would insure things would work if either case were true. What is currently "breaking" things is the preference of IPv6 over IPv4. If you're running a default Win2K8 active directory, it's publishing all of it's goodies for login in IPv6 form complete with AAAA address records. If your network isn't end-to-end IPv6 compliant, but some Win7 client across the hall (on another subnet) has found *any* IPv6 connectivity (6to4, Teredo, doesn't matter how good/bad/ugly/slow), it is going to try to communicate with the domain controller over that IPv6 connection. I have seen this in action, and stacks of trouble tickets of slow / intermittent / no connectivity with the domain. As it currently stands, if you're not 100% end-to-end IPv6 ready with compliant transport, these "preferences" break or cripple things. Of course, this all may be by IPv6 design (make it so horribly painful not to accomodate to push you to provide better alternatives) :-) Jeff From jeroen at unfix.org Sat Sep 11 20:54:29 2010 From: jeroen at unfix.org (Jeroen Massar) Date: Sat, 11 Sep 2010 22:54:29 +0200 Subject: List of Teredo servers and teredo relays In-Reply-To: <4C8BE509.1090904@utc.edu> References: <208008211-1284233373-cardhu_decombobulator_blackberry.rim.net-976534877-@bda903.bisx.prod.on.blackberry> <4C8BE509.1090904@utc.edu> Message-ID: <4C8BEC85.30806@unfix.org> On 2010-09-11 22:22, Jeff Kell wrote: [..] > What is currently "breaking" things is the preference of IPv6 over > IPv4. If you're running a default Win2K8 active directory, it's > publishing all of it's goodies for login in IPv6 form complete with AAAA > address records. If your network isn't end-to-end IPv6 compliant, but > some Win7 client across the hall (on another subnet) has found *any* > IPv6 connectivity (6to4, Teredo, doesn't matter how good/bad/ugly/slow), > it is going to try to communicate with the domain controller over that > IPv6 connection. I have seen this in action, and stacks of trouble > tickets of slow / intermittent / no connectivity with the domain. It would be nice that if you make these kind of statements that you would have actually read up on things which are active already for a long long time. Please try google and read up on RFC 3484. Indeed, Teredo is prioritized AFTER native IPv4. Greets, Jeroen From khatfield at socllc.net Sat Sep 11 22:18:57 2010 From: khatfield at socllc.net (khatfield at socllc.net) Date: Sat, 11 Sep 2010 22:18:57 +0000 Subject: List of Teredo servers and teredo relays Message-ID: <1334422950-1284243538-cardhu_decombobulator_blackberry.rim.net-1223597161-@bda903.bisx.prod.on.blackberry> Thanks for the explanation. And Owen: thanks, I just thought most networks/facilities (colo/private) should be close to ipv6 now days. At least capable, maybe not configured. I think I was just making an assumption so thanks for the info. ------Original Message------ From: Jeff Kell To: Kevin Hatfield Cc: NANOG Subject: Re: List of Teredo servers and teredo relays Sent: Sep 11, 2010 3:22 PM On 9/11/2010 3:29 PM, khatfield at socllc.net wrote: > I may be missing the point here completely but to me Teredo just seems like a glorified hack/workaround for a bigger problem. Isn't is better (yes less cost-effective) to just upgrade equipment? > > I really don't see the advantage here. Maybe someone can explain away my ignorance to the concept? > Teredo is a "last-ditch" solution, but unfortunately in the Microsoft world, and acceptable and preferable solution over IPv4. Pure speculation, but the IPv6 efforts of many (looking at current MacOS, Windows, and a growing segment of PDAs/phones) are making tremendous effort to obtain "some" form of IPv6 connectivity. This makes sense if there were (a) only IPv6 connectivity at the client endpoint, or (b) only IPv6 connectivity at the service endpoint. That would insure things would work if either case were true. What is currently "breaking" things is the preference of IPv6 over IPv4. If you're running a default Win2K8 active directory, it's publishing all of it's goodies for login in IPv6 form complete with AAAA address records. If your network isn't end-to-end IPv6 compliant, but some Win7 client across the hall (on another subnet) has found *any* IPv6 connectivity (6to4, Teredo, doesn't matter how good/bad/ugly/slow), it is going to try to communicate with the domain controller over that IPv6 connection. I have seen this in action, and stacks of trouble tickets of slow / intermittent / no connectivity with the domain. As it currently stands, if you're not 100% end-to-end IPv6 ready with compliant transport, these "preferences" break or cripple things. Of course, this all may be by IPv6 design (make it so horribly painful not to accomodate to push you to provide better alternatives) :-) Jeff From owen at delong.com Sat Sep 11 22:27:04 2010 From: owen at delong.com (Owen DeLong) Date: Sat, 11 Sep 2010 15:27:04 -0700 Subject: List of Teredo servers and teredo relays In-Reply-To: <1334422950-1284243538-cardhu_decombobulator_blackberry.rim.net-1223597161-@bda903.bisx.prod.on.blackberry> References: <1334422950-1284243538-cardhu_decombobulator_blackberry.rim.net-1223597161-@bda903.bisx.prod.on.blackberry> Message-ID: On Sep 11, 2010, at 3:18 PM, khatfield at socllc.net wrote: > Thanks for the explanation. > > And Owen: thanks, I just thought most networks/facilities (colo/private) should be close to ipv6 now days. At least capable, maybe not configured. > Would that it were so. The ones I work on all are. > I think I was just making an assumption so thanks for the info. Any time. Life will get more interesting in February. Life will get very interesting somewhere around August of next year. Owen > ------Original Message------ > From: Jeff Kell > To: Kevin Hatfield > Cc: NANOG > Subject: Re: List of Teredo servers and teredo relays > Sent: Sep 11, 2010 3:22 PM > > On 9/11/2010 3:29 PM, khatfield at socllc.net wrote: >> I may be missing the point here completely but to me Teredo just seems like a glorified hack/workaround for a bigger problem. Isn't is better (yes less cost-effective) to just upgrade equipment? >> >> I really don't see the advantage here. Maybe someone can explain away my ignorance to the concept? >> > > Teredo is a "last-ditch" solution, but unfortunately in the Microsoft > world, and acceptable and preferable solution over IPv4. > > Pure speculation, but the IPv6 efforts of many (looking at current > MacOS, Windows, and a growing segment of PDAs/phones) are making > tremendous effort to obtain "some" form of IPv6 connectivity. This > makes sense if there were (a) only IPv6 connectivity at the client > endpoint, or (b) only IPv6 connectivity at the service endpoint. That > would insure things would work if either case were true. > > What is currently "breaking" things is the preference of IPv6 over > IPv4. If you're running a default Win2K8 active directory, it's > publishing all of it's goodies for login in IPv6 form complete with AAAA > address records. If your network isn't end-to-end IPv6 compliant, but > some Win7 client across the hall (on another subnet) has found *any* > IPv6 connectivity (6to4, Teredo, doesn't matter how good/bad/ugly/slow), > it is going to try to communicate with the domain controller over that > IPv6 connection. I have seen this in action, and stacks of trouble > tickets of slow / intermittent / no connectivity with the domain. > > As it currently stands, if you're not 100% end-to-end IPv6 ready with > compliant transport, these "preferences" break or cripple things. > > Of course, this all may be by IPv6 design (make it so horribly painful > not to accomodate to push you to provide better alternatives) :-) > > Jeff > From scott at doc.net.au Sun Sep 12 01:29:11 2010 From: scott at doc.net.au (Scott Howard) Date: Sat, 11 Sep 2010 18:29:11 -0700 Subject: ISP port blocking practice In-Reply-To: <126D663B-2090-4A12-9EBA-E124D1D20729@delong.com> References: <0A08271D-49B9-4382-9F54-1A0BB6A3F2B2@umich.edu> <13222.1256232797@turing-police.cc.vt.edu> <9C23BD21-9384-4959-AAA5-8F4A31050CE1@delong.com> <126D663B-2090-4A12-9EBA-E124D1D20729@delong.com> Message-ID: On Sun, Sep 5, 2010 at 8:06 PM, Owen DeLong wrote: > Doing away with open relays and open proxies didn't really interfere with > legitimate traffic on a meaningful level. > > Blocking outbound SMTP is causing such problems. > You keep saying this, but can you provide any examples of situations where ISP that have done this RIGHT, and have caused anything more than a very minor inconvenience to a very small percentage of their users, and no impact at all to the rest? Nobody is talking about blocking port 465 or 587 as being a good thing - only port 25. I've been involved with multiple ISPs in multiple countries that have implemented port 25 blocking. Those that did it right (dynamic IPs only, self opt-out, communication, etc) all reported sufficiently small volumes of end-user problems that it could almost be considered noise in the normal support load. If a better job was done of blocking only 25, perhaps this would be less so. > Name an ISP that is blocking port 465 or 587? Not a hotel or a library - but an ISP. The question isn't just what is or isn't effective, or, even how much it > reduces spam > complaints. There is also the question of how much legitimate traffic > suffers collateral > damage in your spam mitiigation techniques. > >From the data I have, which comes from multiple implementations of blocking, it is very clear that the answer is that it had a significant impact on the amount of spam being originated from the network, and with very little to zero collateral damage. To a large extent, this isn't about the impact that such changes have on the total global volume of spam being sent - and if you think it is you're missing the point. This is about ISP taking an interest in stopping spam originating from their network, and getting themselves off the various "Top 10 spammers" lists (hello Telefonica, are you listening?). If you're not taking an interest in the spam that's originating from your network, then you're a part of the problem (and given that only a few weeks ago people on spam-l were discussing blocking all oh HE... well...) Scott From awacs at ziskind.us Sun Sep 12 03:24:51 2010 From: awacs at ziskind.us (N. Yaakov Ziskind) Date: Sat, 11 Sep 2010 23:24:51 -0400 Subject: Convenience or slippery slope... or something else? In-Reply-To: References: Message-ID: <20100911232451.A28712@egps.ziskind.us> Jon Lewis wrote (on Fri, Sep 10, 2010 at 01:44:02PM -0400): > On Fri, 10 Sep 2010, Reese wrote: > > >A friend brought this to my attention: > > > >http://ipq.co/ > > > >He saw it at http://news.ycombinator.com/item?id=1678324 > > > >I'm not sure whether to shriek in joy or in pain. Will data from > >this service - if it is a worthy service - propagate properly? > >Play nicely with or break other people's toys? Is it a gimmick? > > How's it going to break anything? I just created one... > > tentententen.ipq.co. 86400 IN A 10.10.10.10 > > so...now I can use tentententen.ipq.co as a name that resolves to > 10.10.10.10...assuming I trust ipq.co to keep that A record and not delete > or change it at some point. Other than the fact that you can't change > it[1], how is this any different (other than being less useful) or scarier > than DynDNS? > > > 1. EMAIL ADDRESS > optional, but will allow you to update the record later (once we implement > it) And now FF blocks it as a "reported attack page." -- _________________________________________ Nachman Yaakov Ziskind, FSPA, LLM awacs at ziskind.us Attorney and Counselor-at-Law http://ziskind.us Economic Group Pension Services http://egps.com Actuaries and Employee Benefit Consultants From scott at doc.net.au Sun Sep 12 03:36:36 2010 From: scott at doc.net.au (Scott Howard) Date: Sat, 11 Sep 2010 20:36:36 -0700 Subject: Convenience or slippery slope... or something else? In-Reply-To: <20100911232451.A28712@egps.ziskind.us> References: <20100911232451.A28712@egps.ziskind.us> Message-ID: On Sat, Sep 11, 2010 at 8:24 PM, N. Yaakov Ziskind wrote: > Jon Lewis wrote (on Fri, Sep 10, 2010 at 01:44:02PM -0400): > > On Fri, 10 Sep 2010, Reese wrote: > > > > >A friend brought this to my attention: > > > > > >http://ipq.co/ > > And now FF blocks it as a "reported attack page." > Bound to happen... http://safebrowsing.clients.google.com/safebrowsing/diagnostic?site=http://ipq.co/ "Over the past 90 days, ipq.co appeared to function as an intermediary for the infection of 4 site(s) including [...]" (Domains removed so as to not trigger anyones anti-spam software...) Scott From tony at lava.net Sun Sep 12 06:42:02 2010 From: tony at lava.net (Antonio Querubin) Date: Sat, 11 Sep 2010 20:42:02 -1000 (HST) Subject: List of Teredo servers and teredo relays In-Reply-To: <4086450A-224E-4D0D-BCFE-57A985A318CA@puck.nether.net> References: <4C8A8F63.9020400@gont.com.ar> <4086450A-224E-4D0D-BCFE-57A985A318CA@puck.nether.net> Message-ID: On Sat, 11 Sep 2010, Jared Mauch wrote: > I would be careful actually using teredo, as some of them (eg: > Microsoft) have swaths of native IPv6 networks that are unreachable. While I would agree in principle, in practice we have little control over what customers use. > I'm hoping they will correct some of the problems with it, but it makes > IPv6 harder to use for some people as the Microsoft one does not appear > to be well supported/connected. I'm not sure if there is an effort > under way on Microsofts behalf to correct this, but I hope so. This could be a host or relay-specific problem which may not be under Microsoft control at all. All the more reason for ISPs to run their own local Teredo relay. Antonio Querubin 808-545-5282 x3003 e-mail/xmpp: tony at lava.net From leen at consolejunkie.net Sun Sep 12 11:33:17 2010 From: leen at consolejunkie.net (Leen Besselink) Date: Sun, 12 Sep 2010 13:33:17 +0200 Subject: List of Teredo servers and teredo relays In-Reply-To: References: <4C8A8F63.9020400@gont.com.ar> <4086450A-224E-4D0D-BCFE-57A985A318CA@puck.nether.net> Message-ID: <4C8CBA7D.4050701@consolejunkie.net> On 09/12/2010 08:42 AM, Antonio Querubin wrote: > On Sat, 11 Sep 2010, Jared Mauch wrote: > >> I would be careful actually using teredo, as some of them (eg: >> Microsoft) have swaths of native IPv6 networks that are unreachable. > > While I would agree in principle, in practice we have little control > over what customers use. > I don't agree, if you are an accessproivder I think it would there is one very important thing you can do or if you not yet able to do the next best thing: 1. provide native IPv6 to customers 2. setup your own tunnelservice or if you think people won't use your tunnelservice, setup relays The more IPv6 the accessprovider provides the bettter the results. Native or the closer the transition point the better. Atleast that is the theory. :-) >> I'm hoping they will correct some of the problems with it, but it >> makes IPv6 harder to use for some people as the Microsoft one does >> not appear to be well supported/connected. I'm not sure if there is >> an effort under way on Microsofts behalf to correct this, but I hope so. > > This could be a host or relay-specific problem which may not be under > Microsoft control at all. All the more reason for ISPs to run their > own local Teredo relay. > > > Antonio Querubin > 808-545-5282 x3003 > e-mail/xmpp: tony at lava.net > > From tglassey at earthlink.net Sun Sep 12 16:04:06 2010 From: tglassey at earthlink.net (todd glassey) Date: Sun, 12 Sep 2010 09:04:06 -0700 Subject: HE - anyone run into power issues with HE Colo Services? In-Reply-To: References: Message-ID: <4C8CF9F6.3030501@earthlink.net> Has anyone run into issues with HE's power and the limitations therein? For instance they seem to want to sell a second rack of space to get any reasonable amount of power into their enclosures. The basic 40U Rack only comes with a single source of power which is limited to 15A meaning it is really difficult to properly build out N+1 type operations. We also had a power outage which they claim hasn't happened in 12 years previously but I somehow doubt that FM2 has existed for 12 years. Anyone have a connection to Mike L directly? Todd Glassey From tony at lava.net Sun Sep 12 16:30:15 2010 From: tony at lava.net (Antonio Querubin) Date: Sun, 12 Sep 2010 06:30:15 -1000 (HST) Subject: List of Teredo servers and teredo relays In-Reply-To: <4C8CBA7D.4050701@consolejunkie.net> References: <4C8A8F63.9020400@gont.com.ar> <4086450A-224E-4D0D-BCFE-57A985A318CA@puck.nether.net> <4C8CBA7D.4050701@consolejunkie.net> Message-ID: On Sun, 12 Sep 2010, Leen Besselink wrote: > On 09/12/2010 08:42 AM, Antonio Querubin wrote: >> On Sat, 11 Sep 2010, Jared Mauch wrote: >> >>> I would be careful actually using teredo, as some of them (eg: >>> Microsoft) have swaths of native IPv6 networks that are unreachable. >> >> While I would agree in principle, in practice we have little control >> over what customers use. >> > > I don't agree, if you are an accessproivder I think it would there is > one very important thing you can do or if you not yet able to do the > next best thing: > > 1. provide native IPv6 to customers > 2. setup your own tunnelservice or if you think people won't use your > tunnelservice, setup relays > > The more IPv6 the accessprovider provides the bettter the results. > Native or the closer the transition point the better. > > Atleast that is the theory. :-) What makes you think we're not already doing all of the above? :) As I said, the problem is an ISP doesn't have control over what their customers choos to purchase and run in their own network. An ISP can setup a fully dual-stack network everywhere in their own infrastructure but if the customer chooses to use only NATed IPv4 (for whatever reason) on their own equipment, it would be a foolish ISP that insists the customer must change out all their equipment. Users will migrate to IPv6 in their own time and their own way. But if they happen to be behind some $50 NATed IPv4 router, it behooves the ISP to accomodate those out-of-the-box-running-Teredo devices as best as possible instead of relying on somebody elses Teredo relay. Antonio Querubin 808-545-5282 x3003 e-mail/xmpp: tony at lava.net From sean at donelan.com Sun Sep 12 16:40:53 2010 From: sean at donelan.com (Sean Donelan) Date: Sun, 12 Sep 2010 12:40:53 -0400 (EDT) Subject: UK key roll-over - may need to flush name server caches Message-ID: If you are experiencing DNSSEC lookup validation failures for domains under the .UK TLD, you may (engineering-speak for almost definitely) need to flush your name server caches. http://www.nominet.org.uk/registrars/systems/serviceannouncements/ DNSSEC validation issue Due to a failure of a Hardware Security Module (HSM), as a matter of precaution, we failed over to our backup signing system this afternoon. As the backup system did not use the exact same Zone Signing Keys (ZSK), there is the possibility of validation failures. To make sure validators use the correct zone signing keys, caches might need to be flushed. From nathan at atlasnetworks.us Sun Sep 12 20:54:49 2010 From: nathan at atlasnetworks.us (Nathan Eisenberg) Date: Sun, 12 Sep 2010 20:54:49 +0000 Subject: List of Teredo servers and teredo relays In-Reply-To: References: <4C8A8F63.9020400@gont.com.ar> <4086450A-224E-4D0D-BCFE-57A985A318CA@puck.nether.net> <4C8CBA7D.4050701@consolejunkie.net> Message-ID: <8C26A4FDAE599041A13EB499117D3C28164B456D@ex-mb-1.corp.atlasnetworks.us> > While I would agree in principle, in practice we have little control > over what customers use. You won't have a good time at Disneyland if you ride Space Mountain in the unsupported configuration of 'not belted in'. An ISP has no control over what I set my MTU to, and they won't support me if I change it. > Users will migrate to IPv6 in their own time and their own way. An object at rest tends to remain at rest until outside force is applied. The lifetime of many of the IPv4 SOHO NAT devices out there exceeds both the exhaustion timer and the most optimistic depletion estimates for the RIRs. For most people, generally only a failed NAT device comprises the outside force required to buy new equipment. Most users won't actively migrate to IPv6 in their own time and their own way; the ISP needs to take an active stance that starts with "we're only supporting IPv4/6 devices starting $date", and ends with "we're terminating all legacy IPv4 support on Jan 1, 2350 at 1:30PM.' Nathan From khatfield at socllc.net Sun Sep 12 21:11:40 2010 From: khatfield at socllc.net (khatfield at socllc.net) Date: Sun, 12 Sep 2010 21:11:40 +0000 Subject: List of Teredo servers and teredo relays In-Reply-To: <8C26A4FDAE599041A13EB499117D3C28164B456D@ex-mb-1.corp.atlasnetworks.us> References: <4C8A8F63.9020400@gont.com.ar><4086450A-224E-4D0D-BCFE-57A985A318CA@puck.nether.net><4C8CBA7D.4050701@consolejunkie.net><8C26A4FDAE599041A13EB499117D3C28164B456D@ex-mb-1.corp.atlasnetworks.us> Message-ID: <952318161-1284325900-cardhu_decombobulator_blackberry.rim.net-355890673-@bda903.bisx.prod.on.blackberry> 2350 is about an accurate date considering how quickly migration is happening in most places :) -----Original Message----- From: Nathan Eisenberg Date: Sun, 12 Sep 2010 20:54:49 To: nanog at nanog.org Subject: RE: List of Teredo servers and teredo relays > While I would agree in principle, in practice we have little control > over what customers use. You won't have a good time at Disneyland if you ride Space Mountain in the unsupported configuration of 'not belted in'. An ISP has no control over what I set my MTU to, and they won't support me if I change it. > Users will migrate to IPv6 in their own time and their own way. An object at rest tends to remain at rest until outside force is applied. The lifetime of many of the IPv4 SOHO NAT devices out there exceeds both the exhaustion timer and the most optimistic depletion estimates for the RIRs. For most people, generally only a failed NAT device comprises the outside force required to buy new equipment. Most users won't actively migrate to IPv6 in their own time and their own way; the ISP needs to take an active stance that starts with "we're only supporting IPv4/6 devices starting $date", and ends with "we're terminating all legacy IPv4 support on Jan 1, 2350 at 1:30PM.' Nathan From francois at menards.ca Mon Sep 13 02:06:47 2010 From: francois at menards.ca (Francois Menard) Date: Sun, 12 Sep 2010 22:06:47 -0400 Subject: Transporting QinQ across a Layer 2 link locked at 1518 octets AND across a Layer 3 link Message-ID: Folks, Question #1: Is it possible for me to put an MPLS router on both ends of a circuit leased from a transport service provider which does not support QinQ (i.e. packets of 1526 bytes), and which requires us to tag traffic onto a well specified set of VLANs (i.e. if we want two VLANs, the service provider tells us which two VLANs to use). I was thinking of lowering the MTU size on my MPLS router such that I could do QinQ over VPLS, over MPLS, over Ethernet transport locked at @ 1514 octets. I would imagine that my effective IPv4 payload would be reduced to something like (not taking into account CRC removed in the Ethernet driver) 1514 minus 8 bytes for MPLS label minus 4 bytes for VPLS control word minus 4 bytes for VLAN tag #1 minus 4 bytes for VLAN tag #2 = 1514 -8 -4 -4 -4 -4 = 1490 octets So if I set my MTU on my MPLS router at 1490 octets and send QinQ over VPLS over , wouldn't that allow for all of the above mentioned overhead to pile-up without exceeding the 1514 octets size allowed by my transport provider ? Question #2: I have another link, which is restricted by the transport service provider, which is an MPLS-VPN service, and which does not support QinQ, nor supports layer 2 bridging. An option available to me is to use an EoIP tunnel on a Mikrotik RouterOS router, which maps Ethernet over GRE over IP, causing some 28 octets of overhead. This is proprietary to Mikrotik. So in this case, assuming that I want to do something as dangerous as: QinQ over VPLS over MPLS over Ethernet over EoIP (over GRE, over IP) And accordingly set my MTU to: 1480 (from above) minus 28 octets (Ethernet over GRE over IP) = 1452 octets So if I set my MTU on my MPLS router at 1452 octets, wouldn't that allow for all of the above mentioned overhead to be successfully transported across an IP layer 3 circuit, effectively ending up with QinQ over MPLS over Ethernet over IP ? What are the consequences of setting the MTU as low as 1452 octets? What applications end-up breaking ? -=Francois=- From francois at menards.ca Mon Sep 13 02:12:17 2010 From: francois at menards.ca (Francois Menard) Date: Sun, 12 Sep 2010 22:12:17 -0400 Subject: Transporting QinQ across a Layer 2 link locked at 1518 octets AND across a Layer 3 link In-Reply-To: References: Message-ID: Oops two typos - sunday evening casualties. On 2010-09-12, at 10:06 PM, Francois Menard wrote: > Folks, > > Question #1: > > Is it possible for me to put an MPLS router on both ends of a circuit leased from a transport service provider which does not support QinQ (i.e. packets of 1526 bytes), and which requires us to tag traffic onto a well specified set of VLANs (i.e. if we want two VLANs, the service provider tells us which two VLANs to use). > > I was thinking of lowering the MTU size on my MPLS router such that I could do QinQ over VPLS, over MPLS, over Ethernet transport locked at @ 1514 octets. > > I would imagine that my effective IPv4 payload would be reduced to something like (not taking into account CRC removed in the Ethernet driver) > > 1514 minus 8 bytes for MPLS label minus 4 bytes for VPLS control word minus 4 bytes for VLAN tag #1 minus 4 bytes for VLAN tag #2 = > 1514 -8 -4 -4 -4 -4 = 1490 octets > > So if I set my MTU on my MPLS router at 1490 octets and send QinQ over VPLS over , wouldn't that allow for all of the above mentioned overhead to pile-up without exceeding the 1514 octets size allowed by my transport provider ? > So if I set my MTU on my MPLS router at 1490 octets and send QinQ over VPLS over MPLS over Ethernet, wouldn't that allow for all of the above mentioned overhead to pile-up without exceeding the 1514 octets size allowed by my transport provider ? > Question #2: > > I have another link, which is restricted by the transport service provider, which is an MPLS-VPN service, and which does not support QinQ, nor supports layer 2 bridging. > > An option available to me is to use an EoIP tunnel on a Mikrotik RouterOS router, which maps Ethernet over GRE over IP, causing some 28 octets of overhead. This is proprietary to Mikrotik. > > So in this case, assuming that I want to do something as dangerous as: > > QinQ over VPLS over MPLS over Ethernet over EoIP (over GRE, over IP) > > And accordingly set my MTU to: > > 1480 (from above) minus 28 octets (Ethernet over GRE over IP) = 1452 octets > 1490 (from above) minus 28 octets (Ethernet over GRE over IP) = 1462 octets > So if I set my MTU on my MPLS router at 1452 octets, wouldn't that allow for all of the above mentioned overhead to be successfully transported across an IP layer 3 circuit, effectively ending up with > 1462 octets > QinQ over MPLS over Ethernet over IP ? > > What are the consequences of setting the MTU as low as 1452 octets? What applications end-up breaking ? > 1462 octets > -=Francois=- > > > > From bjohnson at drtel.com Mon Sep 13 02:34:28 2010 From: bjohnson at drtel.com (Brian Johnson) Date: Sun, 12 Sep 2010 21:34:28 -0500 Subject: ISP port blocking practice In-Reply-To: <918D3F33-E46F-40F0-9325-FAE4AE5E0D05@delong.com> References: <20100903124008.72241.qmail@joyce.lan> <918D3F33-E46F-40F0-9325-FAE4AE5E0D05@delong.com> Message-ID: <29A54911243620478FF59F00EBB12F47020BC7D0@ex01.drtel.lan> >-----Original Message----- >From: Owen DeLong [mailto:owen at delong.com] >Sent: Friday, September 03, 2010 1:10 PM >To: John Levine >Cc: nanog at nanog.org >Subject: Re: ISP port blocking practice > > > >Sent from my iPad COOL! > >On Sep 3, 2010, at 10:10 PM, John Levine wrote: > >>> Really? So, since so many ISPs are blocking port 25, there's lots less spam >>> hitting our networks? >> >> It's been extremely effective in blocking spam sent by spambots on >> large ISPs. It's not a magic anti-spam bullet. (If you know one, >> please let us know.) >> >That simply hasn't been my experience. I still get lots of spam from booted >hosts in large provider networks, and yes, that includes many that block 25. As >near as I can tell, 25 blocking is not affecting spammers at all, just legitimate >users. > >There was a time when it was effective, but the spammers have long since >adapted. Now we are only breaking the Internet. We are no ,onger >accomplishing anything ireful. It's pure momentum. So.... How are you getting messages from a user who is sending a message from a network with port 25 blocked? If there is some kind of alternate port usage, or tunneling going on, then there would have been no way to stop it with a filter without doing even more filtering. This additional filtering would likely increase the number of blocked port numbers. This would start breaking other valid protocols. Since you have no suggestions on how to actually handle this issue, I would suggest that you stop criticizing the ones trying to solve the problem for the excessive majority (likely < 99.999%) of users. It is OK to represent the needs of a minority, but the average user doesn't even notice these types of filters and it prevents (largely) ISPs from spending time removing customer IP addresses from RBLs and other filtering mechanisms. > >>> workaround. Since, like many of us, I use a lot of transient networks, >>> having to reconfigure for each unique set of brokenness is actually wasting >>> more of my time than the spam this brokenness was alleged to prevent. >> >> Is there some reason you aren't able to configure your computers to use >> tunnels or SUBMIT? They seem to work pretty well for other people. >> >Many of the transient networks I deal with block 22, 25, 465, and 587. They >also often block protocols 41 and 43 or do not provide a public address, >rendering those protocols unusable anyway. > >Yes, I am now running ssh and s,tp processes on ports 80 and 443 to get >around this, but, that consumes an extra address for something that should >be handled by a port number. > I'm sorry that you have/had to deal with a provider doing this. I would call it bad form to block ports used for completely valid reasons (not abused services) and would stand by you on those issues. >Personally, i'd rather use port numbers for l4 uniqueness rather than IP >Addresses. > With you here brother. :) >Owen BTW... In a previous post you mentioned "Net Neutrality". Port 25 blocking has NOTHING to do with "Net Neutrality" as long as you block port 25 in a non-partisan manner. If I block port 25 to provider X and not to provider Y for any reason other than abuse/security/network stability specific reasons (meaning to be financially or ethically unreasonable), then it may be considered not being "neutral" in the terms of "Net Neutrality". I would NEVER do such a thing. - Brian CONFIDENTIALITY NOTICE: This email message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, copying, use, disclosure, or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. Thank you. From jeffrey.lyon at blacklotus.net Mon Sep 13 04:59:54 2010 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Mon, 13 Sep 2010 09:29:54 +0430 Subject: HE - anyone run into power issues with HE Colo Services? In-Reply-To: <4C8CF9F6.3030501@earthlink.net> References: <4C8CF9F6.3030501@earthlink.net> Message-ID: Todd, You're not supposed to build out N+1 with HE's co-lo specials. They offer the cabinet with a limited amount of power to prevent full utilization of the unlimited bandwidth that comes with the bundle. I'm sure they'll sell you space with whatever power and bandwidth you require, but not at the same great deals you're probably looking at now. Everyone has power outages once in a blue moon, we lost an entire row of cabinets at Peer1 for about 45 minutes last year due to some faulty gear on their side. Best regards, Jeff On Sun, Sep 12, 2010 at 8:34 PM, todd glassey wrote: > Has anyone run into issues with HE's power and the limitations therein? > For instance they seem to want to sell a second rack of space to get any > reasonable amount of power into their enclosures. > > The basic 40U Rack only comes with a single source of power which is > limited to 15A meaning it is really difficult to properly build out N+1 > type operations. ?We also had a power outage which they claim hasn't > happened in 12 years previously but I somehow doubt that FM2 has existed > for 12 years. > > Anyone have a connection to Mike L directly? > > Todd Glassey > > -- Jeffrey Lyon, Leadership Team jeffrey.lyon at blacklotus.net | http://www.blacklotus.net Black Lotus Communications - AS32421 First and Leading in DDoS Protection Solutions From mleber at he.net Mon Sep 13 05:47:20 2010 From: mleber at he.net (Mike Leber) Date: Sun, 12 Sep 2010 22:47:20 -0700 Subject: HE - anyone run into power issues with HE Colo Services? In-Reply-To: <4C8CF9F6.3030501@earthlink.net> References: <4C8CF9F6.3030501@earthlink.net> Message-ID: <4C8DBAE8.4020909@he.net> On 9/12/10 9:04 AM, todd glassey wrote: > Has anyone run into issues with HE's power and the limitations therein? > For instance they seem to want to sell a second rack of space to get any > reasonable amount of power into their enclosures. Perhaps that was several years ago when we didn't offer custom power or recently and we failed to communicate our flexibility, however nowadays you can get as much power per cabinet in our facilities as you want to buy. We have customers with 30 amp 120 volt circuits, others with dual 20 amp 208 volt circuits plus a 15 amp 120 volt circuit, and we even have some customers with three phase 30 amp 208 volt electrical circuits. Since the power delivered to a cabinet is the primary cost of a basic cabinet with one electrical circuit, the cost of additional 15 amp circuit is the same as a 15 amp cabinet. > The basic 40U Rack only comes with a single source of power which is > limited to 15A meaning it is really difficult to properly build out N+1 > type operations. We can source electrical circuits from different PDUs if you specify it at the time of ordering. Mike. From hank at efes.iucc.ac.il Mon Sep 13 07:22:16 2010 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Mon, 13 Sep 2010 09:22:16 +0200 (IST) Subject: Did Internet Founders Actually Anticipate Paid, Prioritized Traffic? Message-ID: http://www.wired.com/epicenter/2010/09/paid-prioritized-traffic -Hank From william.mccall at gmail.com Mon Sep 13 11:50:12 2010 From: william.mccall at gmail.com (William McCall) Date: Mon, 13 Sep 2010 06:50:12 -0500 Subject: Did Internet Founders Actually Anticipate Paid, Prioritized Traffic? In-Reply-To: References: Message-ID: Is it remotely relevant what the founders anticipated? I doubt they anticipated Amazon, Ebay and Google too. On 9/13/10, Hank Nussbacher wrote: > http://www.wired.com/epicenter/2010/09/paid-prioritized-traffic > > -Hank > > -- Sent from my mobile device William McCall, CCIE #25044 From nick at brevardwireless.com Mon Sep 13 13:00:02 2010 From: nick at brevardwireless.com (Nick Olsen) Date: Mon, 13 Sep 2010 09:00:02 -0400 Subject: Transporting QinQ across a Layer 2 link locked at 1518 octets AND across a Layer 3 link Message-ID: <4b1f8e7f$467502d4$647af4df$@com> Only input I can give is on EOIP tunnels and MTU. Scenario is we had 1 remote router running, Tunneled back to our network using EOIP so that the remote network could use our ip space. Don't remember how I figured it out, But I was using the MTU of 1458 (On the EOIP interface). Everything was great, But weird things started happening. Certain sites wouldn't load, MSN.com....etc it was strange. Jacking it back up to 1500 flat fixed it. Nick Olsen Network Operations (877) 804-3001 x106 ---------------------------------------- From: "Francois Menard" Sent: Sunday, September 12, 2010 10:13 PM To: "Francois Menard" Subject: Re: Transporting QinQ across a Layer 2 link locked at 1518 octets AND across a Layer 3 link Oops two typos - sunday evening casualties. On 2010-09-12, at 10:06 PM, Francois Menard wrote: > Folks, > > Question #1: > > Is it possible for me to put an MPLS router on both ends of a circuit leased from a transport service provider which does not support QinQ (i.e. packets of 1526 bytes), and which requires us to tag traffic onto a well specified set of VLANs (i.e. if we want two VLANs, the service provider tells us which two VLANs to use). > > I was thinking of lowering the MTU size on my MPLS router such that I could do QinQ over VPLS, over MPLS, over Ethernet transport locked at @ 1514 octets. > > I would imagine that my effective IPv4 payload would be reduced to something like (not taking into account CRC removed in the Ethernet driver) > > 1514 minus 8 bytes for MPLS label minus 4 bytes for VPLS control word minus 4 bytes for VLAN tag #1 minus 4 bytes for VLAN tag #2 = > 1514 -8 -4 -4 -4 -4 = 1490 octets > > So if I set my MTU on my MPLS router at 1490 octets and send QinQ over VPLS over , wouldn't that allow for all of the above mentioned overhead to pile-up without exceeding the 1514 octets size allowed by my transport provider ? > So if I set my MTU on my MPLS router at 1490 octets and send QinQ over VPLS over MPLS over Ethernet, wouldn't that allow for all of the above mentioned overhead to pile-up without exceeding the 1514 octets size allowed by my transport provider ? > Question #2: > > I have another link, which is restricted by the transport service provider, which is an MPLS-VPN service, and which does not support QinQ, nor supports layer 2 bridging. > > An option available to me is to use an EoIP tunnel on a Mikrotik RouterOS router, which maps Ethernet over GRE over IP, causing some 28 octets of overhead. This is proprietary to Mikrotik. > > So in this case, assuming that I want to do something as dangerous as: > > QinQ over VPLS over MPLS over Ethernet over EoIP (over GRE, over IP) > > And accordingly set my MTU to: > > 1480 (from above) minus 28 octets (Ethernet over GRE over IP) = 1452 octets > 1490 (from above) minus 28 octets (Ethernet over GRE over IP) = 1462 octets > So if I set my MTU on my MPLS router at 1452 octets, wouldn't that allow for all of the above mentioned overhead to be successfully transported across an IP layer 3 circuit, effectively ending up with > 1462 octets > QinQ over MPLS over Ethernet over IP ? > > What are the consequences of setting the MTU as low as 1452 octets? What applications end-up breaking ? > 1462 octets > -=Francois=- > > > > From rodrick.brown at gmail.com Mon Sep 13 13:28:09 2010 From: rodrick.brown at gmail.com (Rodrick Brown) Date: Mon, 13 Sep 2010 09:28:09 -0400 Subject: Did Internet Founders Actually Anticipate Paid, Prioritized Traffic? In-Reply-To: References: Message-ID: <1208F446-25F1-4735-A309-B8745E35E59B@gmail.com> Its unrealistic to believe payment for priority access isn't going to happen this model is used for many other outlets today I'm not sure why so many are against it when it comes to net access. Sent from my iPhone 4. On Sep 13, 2010, at 3:22 AM, Hank Nussbacher wrote: > http://www.wired.com/epicenter/2010/09/paid-prioritized-traffic > > -Hank > From julien at gormotte.info Mon Sep 13 13:40:10 2010 From: julien at gormotte.info (Julien Gormotte) Date: Mon, 13 Sep 2010 13:40:10 +0000 Subject: Did Internet Founders Actually Anticipate Paid, Prioritized =?UTF-8?Q?Traffic=3F?= In-Reply-To: <1208F446-25F1-4735-A309-B8745E35E59B@gmail.com> References: <1208F446-25F1-4735-A309-B8745E35E59B@gmail.com> Message-ID: On Mon, 13 Sep 2010 09:28:09 -0400, Rodrick Brown wrote: > Its unrealistic to believe payment for priority access isn't going to > happen this model is used for many other outlets today I'm not sure why so > many are against it when it comes to net access. Because of net neutrality ? > > Sent from my iPhone 4. > > On Sep 13, 2010, at 3:22 AM, Hank Nussbacher wrote: > >> http://www.wired.com/epicenter/2010/09/paid-prioritized-traffic >> >> -Hank >> From jeffrey.lyon at blacklotus.net Mon Sep 13 13:45:27 2010 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Mon, 13 Sep 2010 18:15:27 +0430 Subject: Did Internet Founders Actually Anticipate Paid, Prioritized Traffic? In-Reply-To: References: <1208F446-25F1-4735-A309-B8745E35E59B@gmail.com> Message-ID: Why not, we (collectively) already pay for peering either directly or indirectly through restrictive peering policies. Jeff On Mon, Sep 13, 2010 at 6:10 PM, Julien Gormotte wrote: > On Mon, 13 Sep 2010 09:28:09 -0400, Rodrick Brown > wrote: >> Its unrealistic to believe payment for priority access isn't going to >> happen this model is used for many other outlets today I'm not sure why > so >> many are against it when it comes to net access. > > Because of net neutrality ? > >> >> Sent from my iPhone 4. >> >> On Sep 13, 2010, at 3:22 AM, Hank Nussbacher > wrote: >> >>> http://www.wired.com/epicenter/2010/09/paid-prioritized-traffic >>> >>> -Hank >>> > > -- Jeffrey Lyon, Leadership Team jeffrey.lyon at blacklotus.net | http://www.blacklotus.net Black Lotus Communications - AS32421 First and Leading in DDoS Protection Solutions From cian.brennan at redbrick.dcu.ie Mon Sep 13 13:47:44 2010 From: cian.brennan at redbrick.dcu.ie (Cian Brennan) Date: Mon, 13 Sep 2010 14:47:44 +0100 Subject: Did Internet Founders Actually Anticipate Paid, Prioritized Traffic? In-Reply-To: <1208F446-25F1-4735-A309-B8745E35E59B@gmail.com> References: <1208F446-25F1-4735-A309-B8745E35E59B@gmail.com> Message-ID: <20100913134744.GA1592@minerva.redbrick.dcu.ie> On Mon, Sep 13, 2010 at 09:28:09AM -0400, Rodrick Brown wrote: > Its unrealistic to believe payment for priority access isn't going to happen this model is used for many other outlets today I'm not sure why so many are against it when it comes to net access. > Because I pay my ISP for internet access. Not for google and their pre-approved list of websites access. > Sent from my iPhone 4. > > On Sep 13, 2010, at 3:22 AM, Hank Nussbacher wrote: > > > http://www.wired.com/epicenter/2010/09/paid-prioritized-traffic > > > > -Hank > > > > From nanog-post at rsuc.gweep.net Mon Sep 13 13:50:21 2010 From: nanog-post at rsuc.gweep.net (Joe Provo) Date: Mon, 13 Sep 2010 09:50:21 -0400 Subject: Did Internet Founders Actually Anticipate Paid, Prioritized Traffic? In-Reply-To: References: <1208F446-25F1-4735-A309-B8745E35E59B@gmail.com> Message-ID: <20100913135021.GA32993@gweep.net> On Mon, Sep 13, 2010 at 01:40:10PM +0000, Julien Gormotte wrote: > On Mon, 13 Sep 2010 09:28:09 -0400, Rodrick Brown > wrote: > > Its unrealistic to believe payment for priority access isn't going to > > happen this model is used for many other outlets today I'm not sure why > so > > many are against it when it comes to net access. > > Because of net neutrality ? Much like Santa Claus or the Tooth Fairy, that's one of the many "re-assurance" myths that one eventually abandons in the course of maturing. [cue endless thread of knee-jerk responses; can we just Godwin it now please?] -- RSUC / GweepNet / Spunk / FnB / Usenix / SAGE From bjohnson at drtel.com Mon Sep 13 13:54:35 2010 From: bjohnson at drtel.com (Brian Johnson) Date: Mon, 13 Sep 2010 08:54:35 -0500 Subject: ISP port blocking practice In-Reply-To: References: <0A08271D-49B9-4382-9F54-1A0BB6A3F2B2@umich.edu><13222.1256232797@turing-police.cc.vt.edu><9C23BD21-9384-4959-AAA5-8F4A31050CE1@delong.com> Message-ID: <29A54911243620478FF59F00EBB12F47020BC7E9@ex01.drtel.lan> Brian J. >-----Original Message----- >From: Ricky Beam [mailto:jfbeam at gmail.com] >Sent: Friday, September 03, 2010 9:30 PM >To: Owen DeLong; Patrick W. Gilmore >Cc: NANOG list >Subject: Re: ISP port blocking practice > >On Fri, 03 Sep 2010 08:12:01 -0400, Owen DeLong >wrote: >> Really? So, since so many ISPs are blocking port 25, there's lots less >> spam hitting our networks? > >Less than there could be. It appears a lot less effective because there >are so many ISPs not doing any blocking. Both of my residential >connections are open, and always have been. (even dialup was unblocked. >which I always found odd since the UUNET wholesale dialup agreement >requires the RADIUS response contain a packet filter limiting port 25 to >your mail server(s).) > >If I block port 25 on my network, no spam will originate from it. >(probablly) The spammers will move on to a network that doesn't block >their crap. As long as there are such open networks, spam will be >rampant. If, overnight, every network filtered port 25, spam would all >but disappear. But spam would not completely disappear -- it would just >be coming from known mailservers :-) thus enters outbound scanning and >the frustrated user complaints from poorly tuned systems... > >--Ricky This is what we (network admins) get paid to do! If we are running a server that is a security risk to the net, then we can't complain when it gets filtered. It is our job to do our due diligence and ensure our servers are not spam hot-beds or open relays (or other bad stuff, etc...). The port 25 blocking simply prevents the largest volume of hosts in an ISP network, the users, from being a spam delivery platform. - Brian CONFIDENTIALITY NOTICE: This email message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, copying, use, disclosure, or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. Thank you. From dseagrav at humancapitaldev.com Mon Sep 13 14:00:00 2010 From: dseagrav at humancapitaldev.com (Daniel Seagraves) Date: Mon, 13 Sep 2010 09:00:00 -0500 Subject: Did Internet Founders Actually Anticipate Paid, Prioritized Traffic? In-Reply-To: <20100913135021.GA32993@gweep.net> References: <1208F446-25F1-4735-A309-B8745E35E59B@gmail.com> <20100913135021.GA32993@gweep.net> Message-ID: <6B86FD36-BBAD-470D-AF37-4FFCE302A9D3@humancapitaldev.com> On Sep 13, 2010, at 8:50 AM, Joe Provo wrote: > On Mon, Sep 13, 2010 at 01:40:10PM +0000, Julien Gormotte wrote: >> On Mon, 13 Sep 2010 09:28:09 -0400, Rodrick Brown >> wrote: >>> Its unrealistic to believe payment for priority access isn't going to >>> happen this model is used for many other outlets today I'm not sure why >> so >>> many are against it when it comes to net access. >> >> Because of net neutrality ? > > Much like Santa Claus or the Tooth Fairy, that's one of the many > "re-assurance" myths that one eventually abandons in the course > of maturing. Well, speaking as a web-based service provider, I oppose it because I quite simply can't afford to operate otherwise. If we start having to pay for access based on geographical area or customer type or some other arbitrary classification we won't be able to stay open. We have enough problems as it is, I don't need my ISP telling me I have to pay for transit on a per-destination basis. If this becomes reality, we are going out of business, and I bet we aren't alone in this. From patrick at zill.net Mon Sep 13 14:05:49 2010 From: patrick at zill.net (Patrick Giagnocavo) Date: Mon, 13 Sep 2010 10:05:49 -0400 Subject: Did Internet Founders Actually Anticipate Paid, Prioritized Traffic? In-Reply-To: <1208F446-25F1-4735-A309-B8745E35E59B@gmail.com> References: <1208F446-25F1-4735-A309-B8745E35E59B@gmail.com> Message-ID: <4C8E2FBD.7090707@zill.net> On 9/13/2010 9:28 AM, Rodrick Brown wrote: > Its unrealistic to believe payment for priority access isn't going to > happen this model is used for many other outlets today I'm not sure > why so many are against it when it comes to net access. > Who is paying for access to the Internet? I thought it was the end-user / customer who was paying, that with their payment is paying for the ISP to gain access to the rest of the net. I would hope that my monthly internet charges would keep me from being a set of "eyeballs" that are to be "monetized" by my ISP. Otherwise give me the service for free... --Patrick From jamie at photon.com Mon Sep 13 14:15:02 2010 From: jamie at photon.com (Jamie Bowden) Date: Mon, 13 Sep 2010 10:15:02 -0400 Subject: Did Internet Founders Actually Anticipate Paid, PrioritizedTraffic? In-Reply-To: References: <1208F446-25F1-4735-A309-B8745E35E59B@gmail.com> Message-ID: <5C836A1A98186142A6BEC393FD5E2A860156EF@hal.photon.com> I was thinking more along the lines of the fact that I pay for access at home, my employer pays for access here at work, and Google, Apple, etc. pay for access (unless they've moved into the DFZ, which only happens when it's beneficial for all players that you're there). Why should we pay extra for what we're already supposed to be getting. If the ISps can't deliver what we're already paying for, they're broken. Jamie -----Original Message----- From: Julien Gormotte [mailto:julien at gormotte.info] Sent: Monday, September 13, 2010 9:40 AM To: Rodrick Brown Cc: nanog at nanog.org Subject: Re: Did Internet Founders Actually Anticipate Paid, PrioritizedTraffic? On Mon, 13 Sep 2010 09:28:09 -0400, Rodrick Brown wrote: > Its unrealistic to believe payment for priority access isn't going to > happen this model is used for many other outlets today I'm not sure why so > many are against it when it comes to net access. Because of net neutrality ? From bicknell at ufp.org Mon Sep 13 14:31:48 2010 From: bicknell at ufp.org (Leo Bicknell) Date: Mon, 13 Sep 2010 07:31:48 -0700 Subject: Did Internet Founders Actually Anticipate Paid, Prioritized Traffic? In-Reply-To: <20100913135021.GA32993@gweep.net> References: <1208F446-25F1-4735-A309-B8745E35E59B@gmail.com> <20100913135021.GA32993@gweep.net> Message-ID: <20100913143148.GA59991@ussenterprise.ufp.org> In a message written on Mon, Sep 13, 2010 at 09:50:21AM -0400, Joe Provo wrote: > [cue endless thread of knee-jerk responses; can we just Godwin it > now please?] Of course Hitler was the first to propose pay-to-play internet traffic. :) Consumers are more in need of regulatory protection than business customers, at $19.95 a month they are viewed as expendable by many of the companies that offer consumer services, and are often served by a monopoly or duopoly, often at the encouragement of government. They can't vote with their dollars as we like to say, and need some protection. However, the proposed "remedies" of banning all filtering ever, or requiring free peering to everyone (taking both to the extreme, of course) don't match the operational real world. Many of those who are pushing for network neutrality are pushing for an ideal that the network simply cannot deliver, no matter what. Rather than network neutrality, I'd simply like to see truth in advertising applied. If my provider advertises "8 Mbps" service then I should be able to get 8 Mbps from Google, or Yahoo, or you, or anyone else on the network, provided of course they have also purchased an 8 Mbps or higher plan from their provider. I don't care if it is done with transit, peering, paid priorization, or any other mechanism, those are back end details that will change over time. I don't care if it is Google building their own network, or you buying 8Mbps service from your local monopoly ISP. -- 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: 826 bytes Desc: not available URL: From bjohnson at drtel.com Mon Sep 13 14:44:40 2010 From: bjohnson at drtel.com (Brian Johnson) Date: Mon, 13 Sep 2010 09:44:40 -0500 Subject: Did Internet Founders Actually Anticipate Paid, Prioritized Traffic? In-Reply-To: <20100913143148.GA59991@ussenterprise.ufp.org> References: <1208F446-25F1-4735-A309-B8745E35E59B@gmail.com><20100913135021.GA32993@gweep.net> <20100913143148.GA59991@ussenterprise.ufp.org> Message-ID: <29A54911243620478FF59F00EBB12F47020BC7F2@ex01.drtel.lan> >-----Original Message----- >From: Leo Bicknell [mailto:bicknell at ufp.org] >Sent: Monday, September 13, 2010 9:32 AM >To: nanog at nanog.org >Subject: Re: Did Internet Founders Actually Anticipate Paid,Prioritized Traffic? > >In a message written on Mon, Sep 13, 2010 at 09:50:21AM -0400, Joe Provo >wrote: >> [cue endless thread of knee-jerk responses; can we just Godwin it >> now please?] > >Of course Hitler was the first to propose pay-to-play internet >traffic. :) > Well done. :) >Consumers are more in need of regulatory protection than business >customers, at $19.95 a month they are viewed as expendable by many >of the companies that offer consumer services, and are often served >by a monopoly or duopoly, often at the encouragement of government. >They can't vote with their dollars as we like to say, and need some >protection. > OK... so doesn't this speak to the commoditization of service providers? I'm against more regulation and for competition. >However, the proposed "remedies" of banning all filtering ever, or >requiring free peering to everyone (taking both to the extreme, of >course) don't match the operational real world. Many of those who >are pushing for network neutrality are pushing for an ideal that >the network simply cannot deliver, no matter what. > Agreed. The bulk of the "Net Neutrality" crowd lives in a dream world. Most (maybe some, maybe a few depending on your view) approach filtering as a solution to a technical problem not as a money making proposition. I have always espoused it only as a fix to technical (security, abuse and the like) issues. >Rather than network neutrality, I'd simply like to see truth in >advertising applied. If my provider advertises "8 Mbps" service >then I should be able to get 8 Mbps from Google, or Yahoo, or you, >or anyone else on the network, provided of course they have also >purchased an 8 Mbps or higher plan from their provider. I don't >care if it is done with transit, peering, paid priorization, or any >other mechanism, those are back end details that will change over >time. I don't care if it is Google building their own network, or >you buying 8Mbps service from your local monopoly ISP. > Explain how the provider of access is supposed to be able to control all of the systems outside it's control to get a specific speed from a content provider. If you are espousing contracts with each content provider, then you will quickly be destroying the Internet. We advertise a rate and ensure we have no congestion on our Internet connection to ensure that all demands for traffic are met on our side. I cannot ensure that site X will not be flooded or have other restrictions on its bandwidth that will prevent your full utilization of the bandwidth. - Brian J. CONFIDENTIALITY NOTICE: This email message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, copying, use, disclosure, or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. Thank you. From Valdis.Kletnieks at vt.edu Mon Sep 13 14:50:59 2010 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Mon, 13 Sep 2010 10:50:59 -0400 Subject: Did Internet Founders Actually Anticipate Paid, Prioritized Traffic? In-Reply-To: Your message of "Mon, 13 Sep 2010 09:28:09 EDT." <1208F446-25F1-4735-A309-B8745E35E59B@gmail.com> References: <1208F446-25F1-4735-A309-B8745E35E59B@gmail.com> Message-ID: <53854.1284389459@localhost> On Mon, 13 Sep 2010 09:28:09 EDT, Rodrick Brown said: > Its unrealistic to believe payment for priority access isn't going to happen > this model is used for many other outlets today I'm not sure why so many are > against it when it comes to net access. Sure - I would have to pay $$/mo if I wanted satellite radio. But failure to do so doesn't interfere in the slightest with my ability to receive local free-air stations, or impact my neighbor's radio. If 15 of my neighbors pay extra each month to watch HBO or other premium content, I still get a reasonable level of performance watching MSNBC in the basic-cable package. That's the way it works for many other outlets now - you pay extra, you get extra, but if you don't, other people's choices don't affect you. But it's *not* how it works for the Internet. Think about it for a moment - if the net is uncongested, then paying for priority doesn't make economic sense. If it *is* congested, then the only way to give priority to some traffic is to screw the non-paid traffic. That's the dirty little secret of QOS. For the sake of argument, let's call TCP's current implementation of window management and congestion avoidance "the fairest and most equal we know how to build". I don't mind fighting for bandwidth with 30 (or whatever it is) neighbors on my cable feed on that sort of an equal basis. Yes, I recognize that I'm actually sharing resources upstream, so my "6M" pipe may get sluggish because I'm sharing with 15 people watching some live pay-per-view event. I'm OK with that. What I'm *NOT* OK with is some media conglomerate literally coming along and buying 4M of that bandwidth (that *I* *already* *paid* *for*, remember?) out from under me, and using it for that pay-per-view event. It's the difference between how mad you get at the supermarket when the person in front of you has a full basket and was already in line when you got there, and a person with a full basket slipping the cashier a $20 to cut in line in front of your half-full basket. Does that explain it better? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From bicknell at ufp.org Mon Sep 13 15:06:03 2010 From: bicknell at ufp.org (Leo Bicknell) Date: Mon, 13 Sep 2010 08:06:03 -0700 Subject: Did Internet Founders Actually Anticipate Paid, Prioritized Traffic? In-Reply-To: <29A54911243620478FF59F00EBB12F47020BC7F2@ex01.drtel.lan> References: <20100913143148.GA59991@ussenterprise.ufp.org> <29A54911243620478FF59F00EBB12F47020BC7F2@ex01.drtel.lan> Message-ID: <20100913150603.GA63307@ussenterprise.ufp.org> In a message written on Mon, Sep 13, 2010 at 09:44:40AM -0500, Brian Johnson wrote: > OK... so doesn't this speak to the commoditization of service providers? > I'm against more regulation and for competition. Competition would be wonderful, but is simply not practical in many cases. Most people and companies don't want to hear this, but from a consumer perspective the Internet is a utility, and very closely resembles water/sewer/electric/gas service. That is, having 20 people run fiber past your home when you're only going to buy from one of them makes no economic sense. Indeed, we probably wouldn't have both cable and DSL service if those were both to the home for other reasons already. > Explain how the provider of access is supposed to be able to control all > of the systems outside it's control to get a specific speed from a > content provider. If you are espousing contracts with each content > provider, then you will quickly be destroying the Internet. That's not exactly what I am proposing; rather I'm proposing we (the industry) develop a set of technical specifications and testing where we can generally demonstrate this to be the case. Of course, things may happen at any time, this isn't about individual machines, or flash mobs. -- 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: 826 bytes Desc: not available URL: From jbates at brightok.net Mon Sep 13 15:34:10 2010 From: jbates at brightok.net (Jack Bates) Date: Mon, 13 Sep 2010 10:34:10 -0500 Subject: Did Internet Founders Actually Anticipate Paid, PrioritizedTraffic? In-Reply-To: <5C836A1A98186142A6BEC393FD5E2A860156EF@hal.photon.com> References: <1208F446-25F1-4735-A309-B8745E35E59B@gmail.com> <5C836A1A98186142A6BEC393FD5E2A860156EF@hal.photon.com> Message-ID: <4C8E4472.2030808@brightok.net> On 9/13/2010 9:15 AM, Jamie Bowden wrote: > I was thinking more along the lines of the fact that I pay for access at home, my employer pays for access here at work, and Google, Apple, etc. pay for access (unless they've moved into the DFZ, which only happens when it's beneficial for all players that you're there). Why should we pay extra for what we're already supposed to be getting. If the ISps can't deliver what we're already paying for, they're broken. > It gets more confusing. See media licensing such as ESPN3, which is provider based. Unfortunately, they treat it the same as they do the cable channel, so if you don't run video services, it puts you in a really bad position. It's also doesn't scale. Sure, with just ESPN3, we might be able to do some billing stuffers, but what about the next 50 video streaming sites that decide they want to do provider based licensing. How many stuffers can you put in with a bill? Jack From bill at herrin.us Mon Sep 13 16:05:09 2010 From: bill at herrin.us (William Herrin) Date: Mon, 13 Sep 2010 12:05:09 -0400 Subject: Did Internet Founders Actually Anticipate Paid, Prioritized Traffic? In-Reply-To: References: Message-ID: On Mon, Sep 13, 2010 at 3:22 AM, Hank Nussbacher wrote: > http://www.wired.com/epicenter/2010/09/paid-prioritized-traffic No, the founders anticipated source-declared priorities for unpaid military and government traffic. Commercial Internet really wasn't on their radar. On Mon, Sep 13, 2010 at 9:28 AM, Rodrick Brown wrote: > Its unrealistic to believe payment for priority access isn't > going to happen this model is used for many other outlets > today I'm not sure why so many are against it when it comes > to net access. It's a question of double-billing. I've already paid you to send and receive packets on my behalf. Detuning my packets because a second party hasn't also paid you is cheating, maybe fraudulent. It'd be like the post office treating first class mail like bulk mail unless the recipient pays a first class mailbox fee in addition to the sender paying for first class delivery. On Mon, Sep 13, 2010 at 10:31 AM, Leo Bicknell wrote: > However, the proposed "remedies" of banning all filtering ever, or > requiring free peering to everyone (taking both to the extreme, of > course) don't match the operational real world. Many of those who > are pushing for network neutrality are pushing for an ideal that > the network simply cannot deliver, no matter what. The network could deliver "cost-reimbursable" peering, in which any service provider above a particular size is by regulation compelled to provide peering at the cost of the basic connection in at least one location in each state in which they operate Internet infrastructure. As a matter of simple fairness, someone else has already paid them to move the packets. Why should you have to pay them more than the cost of the port? A small number of transit-frees would resent it, but it would damage them only in that it levels the playing field for small businesses, enhancing the small businesses' capabilities without enhancing their own. > Rather than network neutrality, I'd simply like to see truth in > advertising applied. Now you're talking about something that truly can't happen. You can't sell a service that, on paper, delivers less than the other guy's. Advertising is a constant race to the bottom because that's the behavior consumers reward. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From source_route at yahoo.com Mon Sep 13 16:31:06 2010 From: source_route at yahoo.com (Philip Lavine) Date: Mon, 13 Sep 2010 09:31:06 -0700 (PDT) Subject: Multicast issues in windows TCP/IP stack Message-ID: <748911.75359.qm@web30803.mail.mud.yahoo.com> Not sure if this the the right venue for this, but would anyone happen to know if there is any changes or "enhancements" in the Windows 2008 64 Bit R2 TCP/IP stack or in TOE that would cause multicast or microsecond bursts of UDP to be dropped between the physical layer (NIC) and OS. I am running the same multicast app on Windows 2008 64 bit NOT R2 or standard and do not have this issue. -thx Philip From tim at pelican.org Mon Sep 13 16:52:36 2010 From: tim at pelican.org (Tim Franklin) Date: Mon, 13 Sep 2010 16:52:36 +0000 (GMT) Subject: Did Internet Founders Actually Anticipate Paid, Prioritized Traffic? In-Reply-To: <2144845.151284396539936.JavaMail.root@jennyfur.pelican.org> Message-ID: <13370774.171284396756396.JavaMail.root@jennyfur.pelican.org> > Competition would be wonderful, but is simply not practical in many > cases. Most people and companies don't want to hear this, but from > a consumer perspective the Internet is a utility, and very closely > resembles water/sewer/electric/gas service. That is, having 20 > people run fiber past your home when you're only going to buy from > one of them makes no economic sense. Indeed, we probably wouldn't > have both cable and DSL service if those were both to the home for > other reasons already. The copper pair from your house to the exchange isn't congested (at least, between you and other people), by definition. The fibre from your house to somewhere isn't congested, in the same way - although the 'somewhere' may be closer to you than the exchange. There's no reason to have competition here - but there's no reason to have a commercial entity trying to make a profit here either. Treat it like a real, basic utility, and run it on a cost-recovery basis, either directly by your local government entity, or by a dedicated organisation acting on their behalf. Whatever entity owns the local-loop sells access to competing service providers on an equal and transparent basis. Providers can then compete on level of network congestion, amongst other things, because they can directly control it in terms of how much backhaul they want to build from the exchange / FTTP street cab / whatever the aggregation point is against the volume of subscribers they sell off that aggregation point. For places which have it, this seems to work much better, or least break far less, than the alternatives (Openreach in the UK, Stokab in Stockholm being two I've dealt with). Exactly like electricity and gas - I only have one set of wires / pipes to my house, but there's a plethora of companies I can choose to buy energy services from. Regards, Tim. From mike at mtcc.com Mon Sep 13 16:58:46 2010 From: mike at mtcc.com (Michael Thomas) Date: Mon, 13 Sep 2010 09:58:46 -0700 Subject: Did Internet Founders Actually Anticipate Paid, Prioritized Traffic? In-Reply-To: <1208F446-25F1-4735-A309-B8745E35E59B@gmail.com> References: <1208F446-25F1-4735-A309-B8745E35E59B@gmail.com> Message-ID: <4C8E5846.6010904@mtcc.com> On 09/13/2010 06:28 AM, Rodrick Brown wrote: > Its unrealistic to believe payment for priority access isn't going to happen this model is used for many other outlets today I'm not sure why so many are against it when it comes to net access. > > Sent from my iPhone 4. > > On Sep 13, 2010, at 3:22 AM, Hank Nussbacher wrote: > >> http://www.wired.com/epicenter/2010/09/paid-prioritized-traffic This genie has long since escaped the bottle, hasn't it? I remember the voip wars of the late 90's where there was lots and lots and lots of hand wringing about qos... but how much penetration does RSVP have, say? Approximately zero? And that's because, in reality, voice is a tiny fraction of net traffic and all of the visions of RSVP and AAL2 and TCRTP and all of the rest of the crazy things have basically come to naught. Does Skype care about qos? It doesn't even care about RTP. So the new bete noir is video and it's easier to be seduced because the traffic volumes are potentially horrific. But i'll place my money on the bet that by the time any scheme to wring money out of that volume could be implemented, the pipes transporting it will be asking what all the hand wringing is about. Just like voice. The human and technological complications of grafting qos/settlement on top of the net are huge in comparison to stuffing more bits into glass. Mike, brute force and ignorance always wins From bjohnson at drtel.com Mon Sep 13 17:01:55 2010 From: bjohnson at drtel.com (Brian Johnson) Date: Mon, 13 Sep 2010 12:01:55 -0500 Subject: Did Internet Founders Actually Anticipate Paid, Prioritized Traffic? In-Reply-To: References: Message-ID: <29A54911243620478FF59F00EBB12F47020BC80A@ex01.drtel.lan> >-----Original Message----- >From: William Herrin [mailto:bill at herrin.us] >Sent: Monday, September 13, 2010 11:05 AM >To: Hank Nussbacher >Cc: nanog at nanog.org >Subject: Re: Did Internet Founders Actually Anticipate Paid,Prioritized Traffic? >On Mon, Sep 13, 2010 at 9:28 AM, Rodrick Brown >wrote: >> Its unrealistic to believe payment for priority access isn't >> going to happen this model is used for many other outlets >> today I'm not sure why so many are against it when it comes >> to net access. > >It's a question of double-billing. I've already paid you to send and >receive packets on my behalf. Detuning my packets because a second >party hasn't also paid you is cheating, maybe fraudulent. > >It'd be like the post office treating first class mail like bulk mail >unless the recipient pays a first class mailbox fee in addition to the >sender paying for first class delivery. > This is a pretty clunky analogy. First class mail is treated differently (better?) than bulk mail in the USPS. There is no double payment for this service. > >On Mon, Sep 13, 2010 at 10:31 AM, Leo Bicknell wrote: >> However, the proposed "remedies" of banning all filtering ever, or >> requiring free peering to everyone (taking both to the extreme, of >> course) don't match the operational real world. Many of those who >> are pushing for network neutrality are pushing for an ideal that >> the network simply cannot deliver, no matter what. > >The network could deliver "cost-reimbursable" peering, in which any >service provider above a particular size is by regulation compelled to >provide peering at the cost of the basic connection in at least one >location in each state in which they operate Internet infrastructure. >As a matter of simple fairness, someone else has already paid them to >move the packets. Why should you have to pay them more than the cost >of the port? > So for clarity... who pays for the peering? >A small number of transit-frees would resent it, but it would damage >them only in that it levels the playing field for small businesses, >enhancing the small businesses' capabilities without enhancing their >own. > HUH? Inanimate objects (transit-frees) do not have the ability to resent. Providers being forced to do something do not resent it (unless they are personally Invested), but they do have to recover their costs and as such would have to raise rates given nothing else changes. > >> Rather than network neutrality, I'd simply like to see truth in >> advertising applied. > >Now you're talking about something that truly can't happen. You can't >sell a service that, on paper, delivers less than the other guy's. >Advertising is a constant race to the bottom because that's the >behavior consumers reward. > I'm with you here. Keep in mind that it is the CONSUMER'S RESPONSIBILITY to understand what they are buying. I've seen tons of people buy something, not understanding it, then, realizing their mistake, blaming the supplier. I have also seen providers blatantly use wordsmithing (is that a word?) to "trick" people into buying there snake oil. Then hold people to contracts entered under suspicious circumstances. It's all so frustrating. - Brian J. CONFIDENTIALITY NOTICE: This email message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, copying, use, disclosure, or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. Thank you. From arnold at nipper.de Mon Sep 13 17:03:05 2010 From: arnold at nipper.de (Arnold Nipper) Date: Mon, 13 Sep 2010 19:03:05 +0200 Subject: Did Internet Founders Actually Anticipate Paid, Prioritized Traffic? In-Reply-To: <13370774.171284396756396.JavaMail.root@jennyfur.pelican.org> References: <13370774.171284396756396.JavaMail.root@jennyfur.pelican.org> Message-ID: <4C8E5949.3050702@nipper.de> On 13.09.2010 18:52 Tim Franklin wrote > Exactly like electricity and gas - I only have one set of wires / > pipes to my house, but there's a plethora of companies I can choose > to buy energy services from. > Sounds like paradise to me. Just my 0.02?, Arnold -- Arnold Nipper / nIPper consulting, Sandhausen, Germany email: arnold at nipper.de phone: +49 6224 9259 299 mobile: +49 172 2650958 fax: +49 6224 9259 333 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From bzs at world.std.com Mon Sep 13 17:20:59 2010 From: bzs at world.std.com (Barry Shein) Date: Mon, 13 Sep 2010 13:20:59 -0400 Subject: Did Internet Founders Actually Anticipate Paid, Prioritized Traffic? In-Reply-To: References: Message-ID: <19598.23931.727753.112045@world.std.com> The article seems to jump around between 1973 and 1998 pretty easily. I guess for some "10 years ago" will always be "the early internet". That said, the author says AT&T hinges on the use of the word 'pricing' in RFC2475 which is dated December 1998, founders? Besides, "pricing" is a term of art, like "cost". It could well have been intended to mean money, just like "a big pile" could be referring to money or it could be referring to horse leavings. THAT SAID, I agree that the only problem is lack of competition. I don't care if someone implements network non-neutrality so long as there is a realistic opportunity for someone else to compete with a neutral network. Right now the net has oligopolized, largely through govt granted monopolies. *THAT SAID*, my suspicion is that the whole thing is a bluff and they (for some value of "they") can't implement network non-neutrality. It's some kind of big bluff to accomplish something else, probably just to sell FUD to large customers -- ooh, we better get a link to XYZ, otherwise when this non-neutral thing flies we're gonna be out in the cold! Then they're gonna REALLY charge the big bucks to get on their net. Something like that, I could propose other motivations more in the regulatory realm these players live in. -- -Barry Shein The World | bzs at TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: 800-THE-WRLD | Dial-Up: US, PR, Canada Software Tool & Die | Public Access Internet | SINCE 1989 *oo* From bill at herrin.us Mon Sep 13 17:29:42 2010 From: bill at herrin.us (William Herrin) Date: Mon, 13 Sep 2010 13:29:42 -0400 Subject: Did Internet Founders Actually Anticipate Paid, Prioritized Traffic? In-Reply-To: <29A54911243620478FF59F00EBB12F47020BC80A@ex01.drtel.lan> References: <29A54911243620478FF59F00EBB12F47020BC80A@ex01.drtel.lan> Message-ID: On Mon, Sep 13, 2010 at 1:01 PM, Brian Johnson wrote: >>The network could deliver "cost-reimbursable" peering, in which any >>service provider above a particular size is by regulation compelled to >>provide peering at the cost of the basic connection in at least one >>location in each state in which they operate Internet infrastructure. >>As a matter of simple fairness, someone else has already paid them to >>move the packets. Why should you have to pay them more than the cost >>of the port? >> > > So for clarity... who pays for the peering? Hi Brian, Whichever party forces the other to accept peering under the regs. Of course, that's not what would happen. People being people, what would happen is that having been forced that close to balance, most of the companies would go ahead and offer settlement free peering to whoever showed up at locations where they peer with anyone else. Ethernet ports are relatively cheap, even on big iron, and their "generosity" positions them at the next regulatory challenge to say, "See, fairness doesn't require us to unbundle our fiber services because we already have open third-party access here." And unlike open peering, unbundling really is expensive and difficult. >>A small number of transit-frees would resent it, but it would damage >>them only in that it levels the playing field for small businesses, >>enhancing the small businesses' capabilities without enhancing their >>own. > > HUH? Inanimate objects (transit-frees) do not have the ?ability to > resent. > > Providers being forced to do something do not resent it (unless they are > personally Invested), but they do have to recover their costs and as > such would have to raise rates given nothing else changes. By stating "resent," I suppose I'm personifying a process in which a large company warns of dire consequences for the consumer should it be forced to accept reasonable regulation after which the consequences either don't materialize at all or show up in some other way significantly less destructive than the obstructed behavior. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From bzs at world.std.com Mon Sep 13 17:39:31 2010 From: bzs at world.std.com (Barry Shein) Date: Mon, 13 Sep 2010 13:39:31 -0400 Subject: Did Internet Founders Actually Anticipate Paid, Prioritized Traffic? In-Reply-To: References: Message-ID: <19598.25043.581492.654328@world.std.com> Oh and one more thing... In the "early internet", let's call that prior to 1990, the hierarchy wasn't price etc, it was: 1. ARPA/ONR (and later NSF) Research sites and actual network research 2. Faculty with funding from 1 at major university research sites 3. Faculty with funding from 1 at not so major universities 4. Faculty at 2 and 3 w/o actual research grants from 1 4. Students at 2 and 3 (tho less so at 3) 5. Everyone else who managed to sneak onto the net (DEC salesmen etc) People worried a fair amount about bandwidth on a network with a 56kb backbone. And those thoughts tended to turn to those hierarchies. I remember when word got out that some UK postal facility had demanded and gotten a set-up so they could sample email traffic on the ARPAnet (circa 1980?) to determine whether or not it was all truly research or were people using this govt-funded research facility to chit-chat and thereby depriving them of postage. They basically wanted postage on email paid to them and were trying to make their case. Warnings went out, I used the arpanet via an acct at MIT at the time so that must be where I saw the warnings about non-professional use of the arpanet. Anyhow, that was the pecking order. The point being that there was a sense that there were "real" people (i.e., properly funded faculty) who needed to do "real" work and some of them expressed concern from time to time that they needed priority. Remember that an early motivation for funding the net was so big fast computers could be accessed by researchers who weren't at the same facility as they were located, and that wasn't solved by cries for their own big fast computer. And that certainly went on in practice. I was involved in writing a $100M proposal for Boston University for a super-computing facility around 1986 and a major requirement was describing how you would get remote researchers to it. It wasn't for BU, per se, it was to be housed at BU. This was the competition that gave us ETF and the Jon von Neumann computing center and all that (that is, BU got nothing, which is probably about what they deserved, but it was my job to help w/ their proposal so I did.) You also had to figure out where to put 50-100 tons of chilled water and where to get about 1.5MW of electric service if I remember the numbers right, "a lot". -- -Barry Shein The World | bzs at TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: 800-THE-WRLD | Dial-Up: US, PR, Canada Software Tool & Die | Public Access Internet | SINCE 1989 *oo* From joshua.klubi at gmail.com Mon Sep 13 19:10:09 2010 From: joshua.klubi at gmail.com (Joshua William Klubi) Date: Mon, 13 Sep 2010 19:10:09 +0000 Subject: ISP port blocking practice In-Reply-To: <29A54911243620478FF59F00EBB12F47020BC7E9@ex01.drtel.lan> References: <0A08271D-49B9-4382-9F54-1A0BB6A3F2B2@umich.edu> <13222.1256232797@turing-police.cc.vt.edu> <9C23BD21-9384-4959-AAA5-8F4A31050CE1@delong.com> <29A54911243620478FF59F00EBB12F47020BC7E9@ex01.drtel.lan> Message-ID: Most of us tend to do only default settings,it would better if we dig better into our settings and apply stricter rules to enhance security Sent from my HTC HD2 on Android On 13 Sep 2010 13:55, "Brian Johnson" wrote: > > > Brian J. > >>-----Original Message----- >>From: Ricky Beam [mailto:jfbeam at gmail.com] >>Sent: Friday, September 03, 2010 9:30 PM >>To: Owen DeLong; Patrick W. Gilmore >>Cc: NANOG list >>Subject: Re: ISP port blocking practice >> >>On Fri, 03 Sep 2010 08:12:01 -0400, Owen DeLong >>wrote: >>> Really? So, since so many ISPs are blocking port 25, there's lots > less >>> spam hitting our networks? >> >>Less than there could be. It appears a lot less effective because > there >>are so many ISPs not doing any blocking. Both of my residential >>connections are open, and always have been. (even dialup was unblocked. >>which I always found odd since the UUNET wholesale dialup agreement >>requires the RADIUS response contain a packet filter limiting port 25 > to >>your mail server(s).) >> >>If I block port 25 on my network, no spam will originate from it. >>(probablly) The spammers will move on to a network that doesn't block >>their crap. As long as there are such open networks, spam will be >>rampant. If, overnight, every network filtered port 25, spam would all >>but disappear. But spam would not completely disappear -- it would > just >>be coming from known mailservers :-) thus enters outbound scanning and >>the frustrated user complaints from poorly tuned systems... >> >>--Ricky > > This is what we (network admins) get paid to do! If we are running a > server that is a security risk to the net, then we can't complain when > it gets filtered. It is our job to do our due diligence and ensure our > servers are not spam hot-beds or open relays (or other bad stuff, > etc...). > > The port 25 blocking simply prevents the largest volume of hosts in an > ISP network, the users, from being a spam delivery platform. > > - Brian > > > CONFIDENTIALITY NOTICE: This email message, including any attachments, is for the sole use of the > intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, > copying, use, disclosure, or distribution is prohibited. If you are not the intended recipient, please > contact the sender by reply e-mail and destroy all copies of the original message. Thank you. > From rbf+nanog at panix.com Mon Sep 13 19:48:22 2010 From: rbf+nanog at panix.com (Brett Frankenberger) Date: Mon, 13 Sep 2010 14:48:22 -0500 Subject: Did Internet Founders Actually Anticipate Paid, PrioritizedTraffic? In-Reply-To: <5C836A1A98186142A6BEC393FD5E2A860156EF@hal.photon.com> References: <5C836A1A98186142A6BEC393FD5E2A860156EF@hal.photon.com> Message-ID: <20100913194822.GA13219@panix.com> On Mon, Sep 13, 2010 at 10:15:02AM -0400, Jamie Bowden wrote: > > I was thinking more along the lines of the fact that I pay for access > at home, my employer pays for access here at work, and Google, Apple, > etc. pay for access (unless they've moved into the DFZ, which only > happens when it's beneficial for all players that you're there). Moving into the DFZ is different from not paying for access. Many enterprises and providers take full BGP routes and have no default, but they're still paying for connectivity. > Why should we pay extra for what we're already supposed to be > getting. If the ISps can't deliver what we're already paying for, > they're broken. The little secret (for some values of secret) that no one isn this thread is talking about is that consumer Internet access is a low margin cutthroat business. Consumers demand ever-increasing amounts of bandwidth and don't want to pay more for it. Providers figure out a way to deliver or lose the business to another provider who figures out a way. Of course they're going to try to monetize the other end, so they can charge the customer less and keep his business, and of course they're going to do things that the purists object to and that are harmful, because most of the customers won't care and they'll like the low price. It's the same reason we have NAT boxes in everyone's homes. It saves money, and consumers are heavily cost driven, and they don't know or don't care what they are losing when they buy purely, or almost purely, on price. There's no NAT in my house, and I'll switch to commercial grade Internet service (and pay the appropriate price) if residential service drops to an unacceptable level of quality for me. (Right now, I can opt out of their attempts to monetize the other end -- for example, I run my own DNS server rather than use my provider's that redirects typos somewhere that gets them money.) But my costs -- for more than one IP address, for a real router rather than a consumer grade toy -- are considerably higher than what most people are willing to pay. Companies of any significant size probably aren't going to fall prey to net-non-neutrality ... but they're going to pay business prices for Internet, and that's going to cover the costs of providing the service and a reasonable profit. If that's what you want at home, then pay that price and you can get that. But most people at home will choose to pay less for their service and let their provider monetize both ends of the connection. To be clear, I'm not staking out a philosophical postion here. I'm a purist -- see above, I don't NAT and I'll pay for a better connection if my consumer connections become insufficiently neutral -- but most people won't and there is and will be a real market in providing cheap, less pure, bandwidth. -- Brett From sean at donelan.com Mon Sep 13 21:39:15 2010 From: sean at donelan.com (Sean Donelan) Date: Mon, 13 Sep 2010 17:39:15 -0400 (EDT) Subject: Did Internet Founders Actually Anticipate Paid, Prioritized Traffic? In-Reply-To: <19598.25043.581492.654328@world.std.com> References: <19598.25043.581492.654328@world.std.com> Message-ID: On Mon, 13 Sep 2010, Barry Shein wrote: > Oh and one more thing... > > In the "early internet", let's call that prior to 1990, the hierarchy > wasn't price etc, it was: > > 1. ARPA/ONR (and later NSF) Research sites and actual network research > 2. Faculty with funding from 1 at major university research sites > 3. Faculty with funding from 1 at not so major universities > 4. Faculty at 2 and 3 w/o actual research grants from 1 > 4. Students at 2 and 3 (tho less so at 3) > 5. Everyone else who managed to sneak onto the net (DEC salesmen etc) > > People worried a fair amount about bandwidth on a network with a 56kb > backbone. And those thoughts tended to turn to those hierarchies. And don't forget the research & education network folks almost always charged commercial institutions a "premium" (sometimes called a "donation") to connect to the Internet in the early days. Even in the early 1990's during privatization, ANS charged differentiated pricing with educational instituations being charged less and commercial institutions being charged more. During the pre-1990's, I doubt any of the Internet "founders" were thinking of how to pay for networks other than asking for more grant money. ARPA and friends paid the bills, and asked for things like TOS/COS long before DiffServ because the military likes to prioritize things for all sorts of reasons besides price. From wavetossed at googlemail.com Tue Sep 14 06:37:10 2010 From: wavetossed at googlemail.com (Michael Dillon) Date: Tue, 14 Sep 2010 07:37:10 +0100 Subject: Did Internet Founders Actually Anticipate Paid, Prioritized Traffic? In-Reply-To: References: <19598.25043.581492.654328@world.std.com> Message-ID: >> In the "early internet", let's call that prior to 1990, the hierarchy >> wasn't price etc, it was: > During the pre-1990's, I doubt any of the Internet "founders" were thinking > of how to pay for networks other than asking for more grant money. ?ARPA and > friends paid the bills, and asked for things like TOS/COS long before > DiffServ because the military likes to prioritize > things for all sorts of reasons besides price. And let's not forget that the article which came up with the title of this thread equates IETF with "Internet Founders" and is talking about the 1990s and the introduction of diffserv. --Michael Dillon From fred at cisco.com Tue Sep 14 07:17:25 2010 From: fred at cisco.com (Fred Baker) Date: Tue, 14 Sep 2010 02:17:25 -0500 Subject: Did Internet Founders Actually Anticipate Paid, Prioritized Traffic? In-Reply-To: References: <19598.25043.581492.654328@world.std.com> Message-ID: <8626EF19-F165-4FDE-B7CF-9F67A03CC7D3@cisco.com> On Sep 14, 2010, at 1:37 AM, Michael Dillon wrote: > And let's not forget that the article which came up with the title of this thread equates IETF with "Internet Founders" and is talking about the 1990s and the introduction of diffserv. If that's the case, the proceedings of ISOC's INET '98 should be of interest. The speakers were not working in the IETF, but they were very aware of IETF proceedings at the time. Basically, the IETF was formalizing a tool that had been in various products in various forms for a decade or more already, in response to specific requests from operators, and which the operators wanted to have in a generalized fashion from any vendor. These guys were commenting on the expected use of the tool by the operators. http://www.isoc.org/inet98/proceedings/3e/3e_2.htm From williams.bruce at gmail.com Tue Sep 14 07:49:09 2010 From: williams.bruce at gmail.com (Bruce Williams) Date: Tue, 14 Sep 2010 00:49:09 -0700 Subject: Did Internet Founders Actually Anticipate Paid, Prioritized Traffic? In-Reply-To: <8626EF19-F165-4FDE-B7CF-9F67A03CC7D3@cisco.com> References: <19598.25043.581492.654328@world.std.com> <8626EF19-F165-4FDE-B7CF-9F67A03CC7D3@cisco.com> Message-ID: Since I am a dinosaur and remember what was going on then ( one of many on this list I am sure ) 1) There was no clue that what we have today would develop. 2) General solutions to what were then abstract problems caused a lot of "open" things to be thrown around. And what does this "appeal to the ancient wisdom" have to do with technology and business today anyway? Bruce Williams . From fweimer at bfk.de Tue Sep 14 07:55:19 2010 From: fweimer at bfk.de (Florian Weimer) Date: Tue, 14 Sep 2010 07:55:19 +0000 Subject: Did Internet Founders Actually Anticipate Paid, Prioritized Traffic? In-Reply-To: <20100913143148.GA59991@ussenterprise.ufp.org> (Leo Bicknell's message of "Mon\, 13 Sep 2010 07\:31\:48 -0700") References: <1208F446-25F1-4735-A309-B8745E35E59B@gmail.com> <20100913135021.GA32993@gweep.net> <20100913143148.GA59991@ussenterprise.ufp.org> Message-ID: <82aankhi8o.fsf@mid.bfk.de> * Leo Bicknell: > Rather than network neutrality, I'd simply like to see truth in > advertising applied. If my provider advertises "8 Mbps" service > then I should be able to get 8 Mbps from Google, or Yahoo, or you, > or anyone else on the network, provided of course they have also > purchased an 8 Mbps or higher plan from their provider. The interesting question is not so much bandwidth, but if the traffic counts against your monthly usage cap. For IPTV offered by your ISP, it won't. Likewise for Internet video platforms where your ISP has obtained an ad-sharing deal. -- 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 elmi at 4ever.de Tue Sep 14 12:27:59 2010 From: elmi at 4ever.de (Elmar K. Bins) Date: Tue, 14 Sep 2010 14:27:59 +0200 Subject: Reverse DNS for IPv6 client networks Message-ID: <20100914122758.GK63203@ronin.4ever.de> Hi guys, I am looking for operational experience here. We have just turned up IPv6 in our "guest wireless", by way of using RA for address distribution and DHCPv6 for the DNS server address (stupid, yup). Apart from the dhcp6 part seemingly not working on Juniper ISGs (or maybe it's my windows *and* that Ubuntu), I now see IPv6 addresses instead of names. I as a networking droid have not much quarrel with that, but I am interested in how or whether at all others handle this. Are you creating DNS entries somehow (reverse and, ultimately, forward), are you using BIND "generate" statements, are you using wildcards...or are you just ignoring this for the "dynamic boxes"? Please enlighten me! Elmar. From jeroen at unfix.org Tue Sep 14 12:38:35 2010 From: jeroen at unfix.org (Jeroen Massar) Date: Tue, 14 Sep 2010 14:38:35 +0200 Subject: Reverse DNS for IPv6 client networks In-Reply-To: <20100914122758.GK63203@ronin.4ever.de> References: <20100914122758.GK63203@ronin.4ever.de> Message-ID: <4C8F6CCB.1050109@unfix.org> On 2010-09-14 14:27, Elmar K. Bins wrote: > Hi guys, > > I am looking for operational experience here. > > We have just turned up IPv6 in our "guest wireless", by way of using RA > for address distribution and DHCPv6 for the DNS server address (stupid, yup). Unfortunately not a lot of gear understands RFC5006 yet. One can opt though to just use DHCPv4 for DNS/IPv4 and RA for the IPv6 address, that is how most setups work; you don't get DNS over IPv6, but who truly cares about that? IPv4 works fine too. > Apart from the dhcp6 part seemingly not working on Juniper ISGs (or maybe it's > my windows *and* that Ubuntu), I now see IPv6 addresses instead of names. > > I as a networking droid have not much quarrel with that, but I am interested > in how or whether at all others handle this. > > Are you creating DNS entries somehow (reverse and, ultimately, forward), > are you using BIND "generate" statements, are you using wildcards...or > are you just ignoring this for the "dynamic boxes"? It all depends on the environment and why one would want to enabled reverse DNS. Do 'guests' really need reverse DNS, and if so, how would you control what those gets get in there? Instead of handpicking names or letting people insert data into your DNS servers, some people are deploying PowerDNS with custom backends for this that either convert the IPv6 address into a 128bit hex number, optionally stripping the first 64 bits and replacing that with 'autogen' or 'wlan-' or similar. Something else that I have seen is that the backend randomly picks a name from a dictionary and then assigns that 'statically' to that address. I personally only put hosts in reverse DNS that re-appear more than once. Jeroen From joelja at bogus.com Tue Sep 14 13:00:52 2010 From: joelja at bogus.com (Joel Jaeggli) Date: Tue, 14 Sep 2010 06:00:52 -0700 Subject: Reverse DNS for IPv6 client networks In-Reply-To: <4C8F6CCB.1050109@unfix.org> References: <20100914122758.GK63203@ronin.4ever.de> <4C8F6CCB.1050109@unfix.org> Message-ID: <4C8F7204.1010103@bogus.com> On 9/14/10 5:38 AM, Jeroen Massar wrote: > Instead of handpicking names or letting people insert data into your DNS > servers, some people are deploying PowerDNS with custom backends for > this that either convert the IPv6 address into a 128bit hex number, > optionally stripping the first 64 bits and replacing that with 'autogen' > or 'wlan-' or similar. Something else that I have seen is that the > backend randomly picks a name from a dictionary and then assigns that > 'statically' to that address. I wildcarded the subnets that we use for dynamic assignments. statically assigned hosts get statically assigned reverse entries. > I personally only put hosts in reverse DNS that re-appear more than once. > > Jeroen > From zaphodb at zaphods.net Tue Sep 14 14:51:54 2010 From: zaphodb at zaphods.net (Stefan Schmidt) Date: Tue, 14 Sep 2010 16:51:54 +0200 Subject: Reverse DNS for IPv6 client networks In-Reply-To: <4C8F6CCB.1050109@unfix.org> References: <20100914122758.GK63203@ronin.4ever.de> <4C8F6CCB.1050109@unfix.org> Message-ID: <20100914145153.GC9401@zaphods.net> On Tue, Sep 14, 2010 at 02:38:35PM +0200, Jeroen Massar wrote: > Instead of handpicking names or letting people insert data into your DNS > servers, some people are deploying PowerDNS with custom backends for > this that either convert the IPv6 address into a 128bit hex number, > optionally stripping the first 64 bits and replacing that with 'autogen' > or 'wlan-' or similar. Something else that I have seen is that the > backend randomly picks a name from a dictionary and then assigns that > 'statically' to that address. As i repaired my adaption of Wichert Modderman's PowerDNS ipv6 forward/reverse walldns-style backend just yesterday, this is probably the right moment to share it [1] with you. It works with netaddr [2] > 0.7, however beware of an odd issue [3] with PowerDNS and python's sys.platform. The good thing about PowerDNS is that it is modular, so you can run several backends and type of backends at once which will get exhaused for queries in the order they are specified. [4] With a pipebackend such as the aforementioned beeing called _after_ your regular authoritative backend, you can have customized records for certain ipv6 addresses in your ranges while still providing a consistent mapping of forward and reverse records for the gazillion of ipv6 addresses. $ dig @mandelbrot.zaphods.net -x 2001:67c:1400:1220::af +short node-4v.ipv6.zaphods.net. $ dig @mandelbrot.zaphods.net aaaa node-4v.ipv6.zaphods.net +short 2001:67c:1400:1220::af Stefan [1] http://zaphods.net/~zaphodb/pdns-ipv6-reverse-backend.py [2] http://code.google.com/p/netaddr/ [3] http://code.google.com/p/netaddr/issues/detail?id=59 [4] http://doc.powerdns.com/modules.html [5] http://wiki.powerdns.com/trac PS: find the powerdns community [5] on #powerdns @ irc.oftc.net -- Hardware is the part of a computer system you can kick. Software is what makes you want to kick the hardware. From saku at ytti.fi Tue Sep 14 14:57:16 2010 From: saku at ytti.fi (Saku Ytti) Date: Tue, 14 Sep 2010 17:57:16 +0300 Subject: Reverse DNS for IPv6 client networks In-Reply-To: <20100914122758.GK63203@ronin.4ever.de> References: <20100914122758.GK63203@ronin.4ever.de> Message-ID: <20100914145716.GA6265@mx.ytti.net> On (2010-09-14 14:27 +0200), Elmar K. Bins wrote: > I as a networking droid have not much quarrel with that, but I am interested > in how or whether at all others handle this. About year ago I spent half and hour hacking together base36 and rfc2289 stateless DNS for IPv6. I'm not making any statements on its sensibility or lack of it. I don't use it myself, as we aren't that far in our IPv6 deployment that we need to think about the problem. [ytti at lintukoto ~]% dig -x c001:dead::babe @62.236.255.181 +short bd80m2ztp38uc3l76b06mk33y.ip.fi. [ytti at lintukoto ~]% dig -x c001:dead::babe @62.236.255.182 +short mudd-do-lava-0-off-bit.ip.fi. [ytti at lintukoto ~]% dig bd80m2ztp38uc3l76b06mk33y.ip.fi. AAAA @62.236.255.181 +short c001:dead::babe [ytti at lintukoto ~]% dig mudd-do-lava-0-off-bit.ip.fi. AAAA @62.236.255.182 +short c001:dead::babe -- ++ytti From owen at delong.com Tue Sep 14 15:08:45 2010 From: owen at delong.com (Owen DeLong) Date: Tue, 14 Sep 2010 08:08:45 -0700 Subject: Reverse DNS for IPv6 client networks In-Reply-To: <20100914122758.GK63203@ronin.4ever.de> References: <20100914122758.GK63203@ronin.4ever.de> Message-ID: <86CBC21B-676F-4E8C-B2C6-CB1CD0861795@delong.com> On Sep 14, 2010, at 5:27 AM, Elmar K. Bins wrote: > Hi guys, > > I am looking for operational experience here. > > We have just turned up IPv6 in our "guest wireless", by way of using RA > for address distribution and DHCPv6 for the DNS server address (stupid, yup). > > Apart from the dhcp6 part seemingly not working on Juniper ISGs (or maybe it's > my windows *and* that Ubuntu), I now see IPv6 addresses instead of names. > > I as a networking droid have not much quarrel with that, but I am interested > in how or whether at all others handle this. > > Are you creating DNS entries somehow (reverse and, ultimately, forward), > are you using BIND "generate" statements, are you using wildcards...or > are you just ignoring this for the "dynamic boxes"? > > Please enlighten me! > > Elmar. I would strongly discourage $GENERATE statements... You won't have enough memory or even disk space to hold the results. I think the choices are either live with numbers, use a wildcard, or use dynamic DNS name registration. Owen From william.allen.simpson at gmail.com Tue Sep 14 15:39:03 2010 From: william.allen.simpson at gmail.com (William Allen Simpson) Date: Tue, 14 Sep 2010 11:39:03 -0400 Subject: Did Internet Founders Actually Anticipate Paid, Prioritized Traffic? In-Reply-To: References: <19598.25043.581492.654328@world.std.com> Message-ID: <4C8F9717.2030009@gmail.com> On 9/13/10 5:39 PM, Sean Donelan wrote: > On Mon, 13 Sep 2010, Barry Shein wrote: >> In the "early internet", let's call that prior to 1990, the hierarchy >> wasn't price etc, it was: >> >> 1. ARPA/ONR (and later NSF) Research sites and actual network research >> 2. Faculty with funding from 1 at major university research sites >> 3. Faculty with funding from 1 at not so major universities >> 4. Faculty at 2 and 3 w/o actual research grants from 1 >> 4. Students at 2 and 3 (tho less so at 3) >> 5. Everyone else who managed to sneak onto the net (DEC salesmen etc) >> >> People worried a fair amount about bandwidth on a network with a 56kb >> backbone. And those thoughts tended to turn to those hierarchies. > > And don't forget the research & education network folks almost always charged commercial institutions a "premium" (sometimes called a "donation") to connect to the Internet in the early days. > > Even in the early 1990's during privatization, ANS charged differentiated pricing with educational instituations being charged less and commercial institutions being charged more. > > During the pre-1990's, I doubt any of the Internet "founders" were thinking of how to pay for networks other than asking for more grant money. ARPA and friends paid the bills, and asked for things like TOS/COS long before DiffServ because the military > likes to prioritize > things for all sorts of reasons besides price. > Another dinosaur speaking. I spent some 8 years in the '80s-'90s looking at pricing for the Michigan House Fiscal Agency, and wrote the legislative boilerplate for funding the Michigan NSFnet contribution. If you think of Cerf et alia as the "fathers" of the Internet, think of me as the midwife.... Barry is correct. Sean is partly correct (we talked about funding beyond grants). ATT is simply wrong. While we talked *a* *lot* about public-private partnerships, we *never* agreed on pricing per packet. On the contrary, whenever it was discussed, that was shot down. Vigorously! Vociferously! Micro economists Hal Varian and Jeff MacKie-Mason were *not* Internet founders! Every so often, I like to brag that for a $5 million annual initial investment, we saved Michigan alone $100 million in telecommunication and computing costs over the first few years. ATT + Ameritech + CWA *hated* me! (As did some of the department folks that justified their salaries and empire building by the dollar totals that flowed through their department.) Reminder: when we specified the first few PPP Over ISDN products, we assumed bits are bits are bits. Then the "I Smell Dollars Now" incumbents decided "data" bits were more valuable than "voice" bits. We went back to the drawing board, and *CHANGED* the specification to require the capability to send PPP Over ISDN voice without losing to robbed bit signaling (56Kbps), so that we could provision around the pricing problem. But there's only so much we can do technically, when they use lawyers and lobbying to outlaw our technical solutions that route around problems. ISPs really need to re-invigorate the old CIX, ISP/C, whatever. Otherwise, you will not survive as NANOG. From dsparro at gmail.com Tue Sep 14 15:47:38 2010 From: dsparro at gmail.com (Dave Sparro) Date: Tue, 14 Sep 2010 11:47:38 -0400 Subject: Did Internet Founders Actually Anticipate Paid, Prioritized Traffic? In-Reply-To: References: Message-ID: <4C8F991A.70309@gmail.com> On 9/13/2010 12:05 PM, William Herrin wrote: > > It's a question of double-billing. I've already paid you to send and > receive packets on my behalf. Detuning my packets because a second > party hasn't also paid you is cheating, maybe fraudulent. > Would you object to an ISP model where a content provider could pay to get an ISP subscriber's package upgraded on a dynamic basis? It would look something like my Road Runner PowerBoost(tm) service, only it never cuts off when the consumer is accessing a particular content provider's service. That would allow Netflix/Hulu/OnLive/whoever to offer me a streaming service that requires a 15Mbps connection even though I'm not willing to upgrade my 10 up/1 down ISP connection to get it. -- Dave From bill at herrin.us Tue Sep 14 16:25:15 2010 From: bill at herrin.us (William Herrin) Date: Tue, 14 Sep 2010 12:25:15 -0400 Subject: Did Internet Founders Actually Anticipate Paid, Prioritized Traffic? In-Reply-To: <4C8F991A.70309@gmail.com> References: <4C8F991A.70309@gmail.com> Message-ID: On Tue, Sep 14, 2010 at 11:47 AM, Dave Sparro wrote: > On 9/13/2010 12:05 PM, William Herrin wrote: >> >> It's a question of double-billing. I've already paid you to send and >> receive packets on my behalf. Detuning my packets because a second >> party hasn't also paid you is cheating, maybe fraudulent. >> > > Would you object to an ISP model where a content provider could pay to get > an ISP subscriber's package upgraded on a dynamic basis? > > It would look something like my Road Runner PowerBoost(tm) service, only it > never cuts off when the consumer is accessing a particular content > provider's service. > > That would allow Netflix/Hulu/OnLive/whoever to offer me a streaming service > that requires a 15Mbps connection even though I'm not willing to upgrade my > 10 up/1 down ISP connection to get it. Hi Dave, That depends. Can I trust you to handle packets in such a way that my 10/1 circuit consistently gets 10 megs to the hosts that haven't paid you for a boost? That was a rhetorical question. The answer, of course, is "no," I can't trust you to do that. You don't always stay ahead of the upgrade curve now. You allow some internal and upstream links to reach capacity, where congestion control slows everybody down. We all do it. Some products would cost more than we can recover if we didn't. In order to sell Netflix the ability to dynamically upgrade my circuit, you'd also have to give their packets priority on the congested links, beating out packets to the systems that are the most important to me. You *might* be able to convince me that it would be OK to let *me* pay for port bursting to designated sites. 10/1 plus the video package which unlimits the link to netflix/hulu/etc. But that's a different story: someone else isn't paying you to mess with my link, *I'm* paying you to mess with my link. Even then, I'd want to see you prohibited from prioritizing their packets anywhere except my immediate link to you. You want my extra money, I expect you to keep the total system capacity high enough to handle the total demand. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From Valdis.Kletnieks at vt.edu Tue Sep 14 16:47:21 2010 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Tue, 14 Sep 2010 12:47:21 -0400 Subject: Did Internet Founders Actually Anticipate Paid, Prioritized Traffic? In-Reply-To: Your message of "Tue, 14 Sep 2010 11:47:38 EDT." <4C8F991A.70309@gmail.com> References: <4C8F991A.70309@gmail.com> Message-ID: <13479.1284482841@localhost> On Tue, 14 Sep 2010 11:47:38 EDT, Dave Sparro said: > Would you object to an ISP model where a content provider could pay to > get an ISP subscriber's package upgraded on a dynamic basis? > > It would look something like my Road Runner PowerBoost(tm) service, only > it never cuts off when the consumer is accessing a particular content > provider's service. > > That would allow Netflix/Hulu/OnLive/whoever to offer me a streaming > service that requires a 15Mbps connection even though I'm not willing to > upgrade my 10 up/1 down ISP connection to get it. What happens to your neighbor's 10M while you're doing this? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From nathan at atlasnetworks.us Tue Sep 14 16:58:58 2010 From: nathan at atlasnetworks.us (Nathan Eisenberg) Date: Tue, 14 Sep 2010 16:58:58 +0000 Subject: Did Internet Founders Actually Anticipate Paid, Prioritized Traffic? In-Reply-To: <4C8F991A.70309@gmail.com> References: <4C8F991A.70309@gmail.com> Message-ID: <8C26A4FDAE599041A13EB499117D3C28164B8DB2@ex-mb-1.corp.atlasnetworks.us> > Would you object to an ISP model where a content provider could pay to get an > ISP subscriber's package upgraded on a dynamic basis? Yes - and the reason is extremely simple. There are a lot of ISPs and a lot of plans. If I'm an entrepreneur looking to build Hulu from the ground up in a pre-Hulu world, am I really going to find EVERY ISP who supports this, and then raise the funding to pay them to allow their paying customers to get to my servers? The answer is no. Implementing this kind of system would stunt innovative new ideas that require a level playing field. The more disturbing effect, though, is this: What if I'm a content provider that your ISP doesn't like? I'm out of luck because you won't take my money to deliver my content at the rate I need to your customers - even though you will take my competitors? I don't see how anyone wins. Innovators lose for want of being able to execute. Content providers lose due to having to manage, maintain, and pay out a fee structure that's almost as complex as the routing table. Customers lose as a result of inconsistent and unpredictable usability. ISPs lose as function of customers losing confidence in their ability to provide service (to them, it 'just doesn't work for everything'). Yes, I would object. Nathan From owen at delong.com Tue Sep 14 17:08:32 2010 From: owen at delong.com (Owen DeLong) Date: Tue, 14 Sep 2010 10:08:32 -0700 Subject: Did Internet Founders Actually Anticipate Paid, Prioritized Traffic? In-Reply-To: <4C8F991A.70309@gmail.com> References: <4C8F991A.70309@gmail.com> Message-ID: On Sep 14, 2010, at 8:47 AM, Dave Sparro wrote: > On 9/13/2010 12:05 PM, William Herrin wrote: >> >> It's a question of double-billing. I've already paid you to send and >> receive packets on my behalf. Detuning my packets because a second >> party hasn't also paid you is cheating, maybe fraudulent. >> > > Would you object to an ISP model where a content provider could pay to get an ISP subscriber's package upgraded on a dynamic basis? > Yes... Because the reality is that it wouldn't be an upgrade. It would be a euphemism for downgrading the subscriber's experience with other content providers. > It would look something like my Road Runner PowerBoost(tm) service, only it never cuts off when the consumer is accessing a particular content provider's service. > Except that PowerBoost(tm) provides a burstable service where the capacity is already available and using it would not negatively impact other subscribers. This, on the other had, would create an SLA requiring your ISP to either build out quite a bit of additional capacity (not so likely) or to negatively impact their other subscribers in order to deliver content to the subscriber using this enhanced service. > That would allow Netflix/Hulu/OnLive/whoever to offer me a streaming service that requires a 15Mbps connection even though I'm not willing to upgrade my 10 up/1 down ISP connection to get it. > There's little difference in my mind between this model and a model where service provider X is in bed with content provider Y (perhaps they share common ownership) and subscribers to provider X are given a dramatically better user experience to content Y than to other content of a similar nature. Owen From wavetossed at googlemail.com Tue Sep 14 18:39:19 2010 From: wavetossed at googlemail.com (Michael Dillon) Date: Tue, 14 Sep 2010 19:39:19 +0100 Subject: Did Internet Founders Actually Anticipate Paid, Prioritized Traffic? In-Reply-To: References: <4C8F991A.70309@gmail.com> Message-ID: >> Would you object to an ISP model where a content provider could pay to get an ISP subscriber's package upgraded on a dynamic basis? >> > Yes... Because the reality is that it wouldn't be an upgrade. It would be a euphemism for downgrading the subscriber's experience with other content providers. A lot of people hear the term "quality of service" and think that it refers to some mechanism that makes some packets go faster like a JATO rocket pack made late 40's, early 50's airplanes go faster. But that is not how the mechanism works. QOS mechanisms are based on making some packets go slower, either by delaying them or deleting them so that they have to be resent. This creates the illusion of speed for the remaining untouched packets if the QOS is successful in preventing congestion at network bottlenecks. QOS does not always prevent congestion; it just reduces the likelihood that congestion will occur. If the delayed/deleted packets belong to the same organization as the so-called boosted packets, then this works OK because this organization will have reasons for preferring that certain packets be delayed/deleted. The problem begins when the delayed/deleted packets belong to a different organization than the boosted ones. That is not net neutrality even if the packets have different diffserv markings. It is even worse when the network operator selectively remarks packets from one organization to cause them to be delayed/deleted. In this second scenario both organizations inject packets into the network with the same IETF diffserv markings but another network operator degrades the service for one organization. --Michael Dillon From dsparro at gmail.com Tue Sep 14 18:57:46 2010 From: dsparro at gmail.com (Dave Sparro) Date: Tue, 14 Sep 2010 14:57:46 -0400 Subject: Did Internet Founders Actually Anticipate Paid, Prioritized Traffic? In-Reply-To: References: <4C8F991A.70309@gmail.com> Message-ID: <4C8FC5AA.8090702@gmail.com> On 9/14/2010 1:08 PM, Owen DeLong wrote: > > On Sep 14, 2010, at 8:47 AM, Dave Sparro wrote: > >> On 9/13/2010 12:05 PM, William Herrin wrote: >>> >>> It's a question of double-billing. I've already paid you to send and >>> receive packets on my behalf. Detuning my packets because a second >>> party hasn't also paid you is cheating, maybe fraudulent. >>> >> >> Would you object to an ISP model where a content provider could pay to get an ISP subscriber's package upgraded on a dynamic basis? >> > Yes... Because the reality is that it wouldn't be an upgrade. It would be a euphemism for downgrading the subscriber's experience with other content providers. > So it's not fair for an ISP to limit a consumer's circuit to the speed they paid for, if there's excess capacity in the network? ie. If the ISP has capacity to offer 15Mbps down, that's what they should provide to a customer that has paid for 10Mbps. Where's the cut-off? >> It would look something like my Road Runner PowerBoost(tm) service, only it never cuts off when the consumer is accessing a particular content provider's service. >> > Except that PowerBoost(tm) provides a burstable service where the capacity is already available and using it would not negatively impact other subscribers. This, on the other had, would create an SLA requiring your ISP to either build out quite a bit of additional capacity (not so likely) or to negatively impact their other subscribers in order to deliver content to the subscriber using this enhanced service. > I would think that the content provider's bag of cash is what would provide the incentive to add to capacity where needed. >> That would allow Netflix/Hulu/OnLive/whoever to offer me a streaming service that requires a 15Mbps connection even though I'm not willing to upgrade my 10 up/1 down ISP connection to get it. >> > > There's little difference in my mind between this model and a model where service provider X is in bed with content provider Y (perhaps they share common ownership) and subscribers to provider X are given a dramatically better user experience to content Y than to other content of a similar nature. > I just don't see a way to get passed the current impasse. The consumers are saying "I want faster, as long as I don't have to pay more." Content providers are saying, "If consumers had faster, I'd be able to invent 'Killer App'. I sure wish the ISPs would upgrade their networks." ISPs are saying, "Why should we upgrade our networks, nobody is willing to pay us to do so." From harry.nanog at harry.lu Tue Sep 14 19:08:08 2010 From: harry.nanog at harry.lu (Harry Strongburg) Date: Tue, 14 Sep 2010 19:08:08 +0000 Subject: Reverse DNS for IPv6 client networks In-Reply-To: <20100914122758.GK63203@ronin.4ever.de> References: <20100914122758.GK63203@ronin.4ever.de> Message-ID: <20100914190808.GA20501@harry.lu> On Tue, Sep 14, 2010 at 02:27:59PM +0200, Elmar K. Bins wrote: > Are you creating DNS entries somehow (reverse and, ultimately, forward), > are you using BIND "generate" statements, are you using wildcards...or > are you just ignoring this for the "dynamic boxes"? I haven't had my coffee yet this morning, so I may be misunderstanding you... I think you're asking for some way for your v6 subnet to both have proper forward and reverse DNS, right? If so, I personally find http://member.wide.ad.jp/~fujiwara/v6rev.html very useful. If you run a "normal" DNS server on the same IP, it probably will be hard to get it working. But, if you don't, it's pretty easy. You'd want to get v6rev.pl from the page above. Here is my config example: server_address: 0.0.0.0, 2001:470:892c:3432::1 server_port: 53 pid_file: /var/run/v6rev.pid reconfig_interval: 3600 reverse_domainname: c.2.9.8.0.7.4.0.1.0.0.2.ip6.arpa #/48 tbroker home reverse_domainname: 1.0.8.c.0.7.4.0.1.0.0.2.ip6.arpa #/48 tbroker work forward_domainname: dyn.harry.lu keyfile_dir: /home/v6rev/keys ttl: 3600 nsname: dyn.harry.lu enable_dnssec: 0 querylog: 1 static_ptr: 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.3.4.3.c.2.9.8.0.7.4.0.1.0.0.2.ip6.arpa harry.lu static_ptr: 5.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.1.0.8.c.0.7.4.0.1.0.0.2.ip6.arpa staticsample.harry.lu Now, if you check the forward and reverse DNS entries for the subnets you defined in reverse_domainname: $ dig -x 2001:470:892c::7 +short 20010470892c00000000000000000007.dyn.harry.lu. $ dig AAAA 20010470892c00000000000000000007.dyn.harry.lu +short 2001:470:892c::7 Pretty cool, eh? You can also add in your own static ones on the same subnet using static_ptr. However, I bet I totally misunderstood your question! From jcdill.lists at gmail.com Tue Sep 14 19:27:21 2010 From: jcdill.lists at gmail.com (JC Dill) Date: Tue, 14 Sep 2010 12:27:21 -0700 Subject: Did Internet Founders Actually Anticipate Paid, Prioritized Traffic? In-Reply-To: <4C8FC5AA.8090702@gmail.com> References: <4C8F991A.70309@gmail.com> <4C8FC5AA.8090702@gmail.com> Message-ID: <4C8FCC99.40205@gmail.com> Dave Sparro wrote: > > I just don't see a way to get passed the current impasse. > The consumers are saying "I want faster, as long as I don't have to > pay more." > Content providers are saying, "If consumers had faster, I'd be able to > invent 'Killer App'. I sure wish the ISPs would upgrade their networks." > ISPs are saying, "Why should we upgrade our networks, nobody is > willing to pay us to do so." > I predict a future where major content providers (MCPs) (such as Google, or Yahoo or MSN) offer customers access for free[1]. When you enroll in free MCP internet access, MCP content and apps will stream to you as fast as their network can possibly get them to you. What MCPs will do with content that comes from other networks is another question. One reason traffic shaping hasn't caught on yet is that it hasn't been beneficial to the people selling access to slow down traffic (which is the only way to shape traffic). Their bean counters keep thinking there's a market behind this service, but each time they try to create a market, someone else simply says "here, I'll get *everything* to you as fast as possible[2], why get your access from that other guy?". This was the Above.net model. So, when one of the MCPs (e.g. Google) comes out with their own access product (which will happen sooner or later), will they find that there's a market to give consumers faster access to Google's content? Or, will Yahoo or MSN or Facebook decide to give customers a product where they get everyone's content as fast as possible, thus negating the value of the free service from Google (or whoever) that is only as fast as possible for that company's content? My bet is on the above.net model - as soon as someone puts up a service with different speeds depending on where the content comes from, someone else will come out with a service that is everything, as fast as possible, and that second offering will win. The technology to stream everything as fast as possible will not be that much more expensive than the technology to provide different speeds for different sources, and the customer will flock to the "everything as fast as possible" offerings. jc [1] And then once everyone is getting their consumer access for free, will they start paying consumers to sign up with their service? We are getting quite close to this in other areas, such as "fill out this form get a free coupon".... [2] Sonic.net is offering "as fast as we can get it to you" now (for one price, no more tiered service for tiered pricing) to home customers in the SF Bay Area. From leland at taranta.discpro.org Tue Sep 14 19:45:12 2010 From: leland at taranta.discpro.org (Leland Vandervort) Date: Tue, 14 Sep 2010 21:45:12 +0200 Subject: perl lib for management of NX-OS ? Message-ID: <97561238-B127-482E-A530-682118365D10@taranta.discpro.org> Hi All, I have an XMLRPC server/API that I implemented (written in perl) to manage most of the cisco kit on the network, with most of the "worker" methods using Net::Telnet::Cisco. Our new datacenter, however, has Cisco Nexus equipment which totally breaks the API since Net::Telnet::Cisco doesn't work at all with NX-OS. I've done some scouring around to try to find something useful for NX-OS, but have come up with nil... Don't suppose anyone has any pointers or has heard of a similar lib for perl to be able to manage NX-OS based systems? I've tried to find a netconf-xmlrpc-ssh lib, but everything that I've found is specifically geared towards juniper rather than Cisco -- and while netconf is supposed to be "standard" (more or less), there are significant differences between the two implementations sufficient enough to make the libs that I've found incompatible with NX-OS. Anyone happen to have any ideas ? Many thanks, Leland From nathan at atlasnetworks.us Tue Sep 14 20:02:18 2010 From: nathan at atlasnetworks.us (Nathan Eisenberg) Date: Tue, 14 Sep 2010 20:02:18 +0000 Subject: Did Internet Founders Actually Anticipate Paid, Prioritized Traffic? In-Reply-To: <4C8FC5AA.8090702@gmail.com> References: <4C8F991A.70309@gmail.com> <4C8FC5AA.8090702@gmail.com> Message-ID: <8C26A4FDAE599041A13EB499117D3C28164B9113@ex-mb-1.corp.atlasnetworks.us> > The consumers are saying "I want faster, as long as I don't have to pay more." > Content providers are saying, "If consumers had faster, I'd be able to invent > 'Killer App'. I sure wish the ISPs would upgrade their networks." > ISPs are saying, "Why should we upgrade our networks, nobody is willing to pay > us to do so." Find me an ISP that is asking why they should upgrade their network if no one is going to pay them to do so. From a business perspective, this is a ludicrous claim. The answer is simple: because your competitors are upgrading their networks RIGHT NOW, and your customers will use them instead if you make them wait too long. There's no deadlock. Content providers that truly have a next generation product that modern broadband isn't good enough for are stuck, like anyone else who invents something that existing infrastructure can't support. Inventing a bizarre service prioritization model doesn't solve the infrastructure problem. > My bet is on the above.net model - as soon as someone puts up a service with > different speeds depending on where the content comes from, someone else > will come out with a service that is everything, as fast as possible, and that > second offering will win. The technology to stream everything as fast as > possible will not be that much more expensive than the technology to provide > different speeds for different sources, and the customer will flock to the > "everything as fast as possible" offerings. Bingo. Keep it simple, and you win. Make it complex, and you create vulnerabilities through which your marketshare will be removed. If capacity is an issue, then as they say in Starcraft - you must construct additional pylons. Nathan From dsparro at gmail.com Tue Sep 14 20:41:22 2010 From: dsparro at gmail.com (Dave Sparro) Date: Tue, 14 Sep 2010 16:41:22 -0400 Subject: Did Internet Founders Actually Anticipate Paid, Prioritized Traffic? In-Reply-To: <8C26A4FDAE599041A13EB499117D3C28164B9113@ex-mb-1.corp.atlasnetworks.us> References: <4C8F991A.70309@gmail.com> <4C8FC5AA.8090702@gmail.com> <8C26A4FDAE599041A13EB499117D3C28164B9113@ex-mb-1.corp.atlasnetworks.us> Message-ID: <4C8FDDF2.5000006@gmail.com> On 9/14/2010 4:02 PM, Nathan Eisenberg wrote: >> The consumers are saying "I want faster, as long as I don't have to pay more." >> Content providers are saying, "If consumers had faster, I'd be able to invent >> 'Killer App'. I sure wish the ISPs would upgrade their networks." >> ISPs are saying, "Why should we upgrade our networks, nobody is willing to pay >> us to do so." > > Find me an ISP that is asking why they should upgrade their network if no one is going to pay them to do so. From a business perspective, this is a ludicrous claim. The answer is simple: because your competitors are upgrading their networks RIGHT NOW, and your customers will use them instead if you make them wait too long. > > There's no deadlock. Content providers that truly have a next generation product that modern broadband isn't good enough for are stuck, like anyone else who invents something that existing infrastructure can't support. Inventing a bizarre service prioritization model doesn't solve the infrastructure problem. > I don't see much competition from here. What I am seeing is a bunch of ISPs sitting on their hands waiting for the Feds to unlock the USF for broadband, or some other form of mana from heaven. -- Dave From Greg.Whynott at oicr.on.ca Tue Sep 14 20:51:33 2010 From: Greg.Whynott at oicr.on.ca (Greg Whynott) Date: Tue, 14 Sep 2010 16:51:33 -0400 Subject: ip block history. Message-ID: probably an odd question ? we have been assigned a few large blocks of IPs, and while configuring BGP i got to wondering what these block's history might be. who had them in the past, etc.. is there a publicly accessible db or similar which tracks that type of information, or is that liability concern? thanks! greg From Jay.Murphy at state.nm.us Tue Sep 14 20:56:03 2010 From: Jay.Murphy at state.nm.us (Murphy, Jay, DOH) Date: Tue, 14 Sep 2010 14:56:03 -0600 Subject: ip block history. In-Reply-To: References: Message-ID: www.Whois.net; whois.arin.net, etc. ~Jay Murphy IP Network Specialist NM State Government "We move the information that moves your world." ?Good engineering demands that we understand what we?re doing and why, keep an open mind, and learn from experience.? ?Engineering is about finding the sweet spot between what's solvable and what isn't." Radia Perlman ? Please consider the environment before printing e-mail -----Original Message----- From: Greg Whynott [mailto:Greg.Whynott at oicr.on.ca] Sent: Tuesday, September 14, 2010 2:52 PM To: nanog at nanog.org list Subject: ip block history. probably an odd question ? we have been assigned a few large blocks of IPs, and while configuring BGP i got to wondering what these block's history might be. who had them in the past, etc.. is there a publicly accessible db or similar which tracks that type of information, or is that liability concern? thanks! greg Confidentiality Notice: This e-mail, including all attachments is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited unless specifically provided under the New Mexico Inspection of Public Records Act. If you are not the intended recipient, please contact the sender and destroy all copies of this message. -- This email has been scanned by the Sybari - Antigen Email System. From mksmith at adhost.com Tue Sep 14 20:58:12 2010 From: mksmith at adhost.com (Michael K. Smith - Adhost) Date: Tue, 14 Sep 2010 13:58:12 -0700 Subject: [NANOG-announce] Call for Nominations - Communications Committee Message-ID: <17838240D9A5544AAA5FF95F8D52031608F03B4E@ad-exh01.adhost.lan> Hello: Nominations for the NANOG Communications Committee are now open. This is a great way to become involved and serve the NANOG community. From the website: "The Communications Committee is a group of five individuals from the NANOG community who together are responsible for the administration and moderation of the NANOG mailing lists. A new Communications Committee will be selected by the Steering Committee after the election in October. Two positions are to be filled. The currently-serving Communications Committee members whose terms are expiring are Randy Epstein and Tim Yocum. The main NANOG mailing list serves an important role in the community by providing a day-to-day forum for network operators. Participating as a member of the Communications Committee gives you the opportunity to make a noticeable contribution. The Communications Committee is covered under section 7.1.2 of the NANOG charter." If you are interested in volunteering on the Communications Committee, please either volunteer yourself or nominate someone you feel would be willing and able to serve. Please send nominations to nominations at nanog.org and include your name, company affiliation, a brief biography and a statement of interest. This information will be posted to the NANOG website in the coming weeks. Please see http://www.nanog.org/governance/elections/2010elections/index.php for more information as well as samples of previous candidate submissions. Kind Regards, Michael K. Smith NANOG Communications Committee Chair _______________________________________________ NANOG-announce mailing list NANOG-announce at nanog.org https://mailman.nanog.org/mailman/listinfo/nanog-announce From Greg.Whynott at oicr.on.ca Tue Sep 14 21:00:53 2010 From: Greg.Whynott at oicr.on.ca (Greg Whynott) Date: Tue, 14 Sep 2010 17:00:53 -0400 Subject: ip block history. In-Reply-To: References: Message-ID: <176C276F-FBAE-4A08-8AEC-87BF37558963@oicr.on.ca> that will show past whois records or just current? I didn't see any options for historic records on arin, thanks by the way. -g On Sep 14, 2010, at 4:56 PM, Murphy, Jay, DOH wrote: > www.Whois.net; whois.arin.net, etc. > > ~Jay Murphy > IP Network Specialist > NM State Government > "We move the information that moves your world." > ?Good engineering demands that we understand what we?re doing and why, keep an open mind, and learn from experience.? > ?Engineering is about finding the sweet spot between what's solvable and what isn't." > Radia Perlman > ? Please consider the environment before printing e-mail > > -----Original Message----- > From: Greg Whynott [mailto:Greg.Whynott at oicr.on.ca] > Sent: Tuesday, September 14, 2010 2:52 PM > To: nanog at nanog.org list > Subject: ip block history. > > probably an odd question ? > > we have been assigned a few large blocks of IPs, and while configuring BGP i got to wondering what these block's history might be. who had them in the past, etc.. > > > is there a publicly accessible db or similar which tracks that type of information, or is that liability concern? > > thanks! > greg > > > > > > > Confidentiality Notice: This e-mail, including all attachments is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited unless specifically provided under the New Mexico Inspection of Public Records Act. If you are not the intended recipient, please contact the sender and destroy all copies of this message. -- This email has been scanned by the Sybari - Antigen Email System. > > > From joelja at bogus.com Tue Sep 14 21:01:19 2010 From: joelja at bogus.com (Joel Jaeggli) Date: Tue, 14 Sep 2010 14:01:19 -0700 Subject: ip block history. In-Reply-To: References: Message-ID: <4C8FE29F.3030108@bogus.com> assuming the whois data has been cleaned up the next resource to look at is: routeviews or ris table dumps to see where or if it was advertised in the past, and from where. google and rbl lists are also worth querying in that context. joel On 9/14/10 1:51 PM, Greg Whynott wrote: > probably an odd question ? > > we have been assigned a few large blocks of IPs, and while configuring BGP i got to wondering what these block's history might be. who had them in the past, etc.. > > > is there a publicly accessible db or similar which tracks that type of information, or is that liability concern? > > thanks! > greg > > > > > From Jay.Murphy at state.nm.us Tue Sep 14 21:04:52 2010 From: Jay.Murphy at state.nm.us (Murphy, Jay, DOH) Date: Tue, 14 Sep 2010 15:04:52 -0600 Subject: ip block history. In-Reply-To: <4C8FE29F.3030108@bogus.com> References: <4C8FE29F.3030108@bogus.com> Message-ID: I second this... ~Jay Murphy IP Network Specialist NM State Government "We move the information that moves your world." ?Good engineering demands that we understand what we?re doing and why, keep an open mind, and learn from experience.? ?Engineering is about finding the sweet spot between what's solvable and what isn't." Radia Perlman ? Please consider the environment before printing e-mail -----Original Message----- From: Joel Jaeggli [mailto:joelja at bogus.com] Sent: Tuesday, September 14, 2010 3:01 PM To: Greg Whynott Cc: nanog at nanog.org list Subject: Re: ip block history. assuming the whois data has been cleaned up the next resource to look at is: routeviews or ris table dumps to see where or if it was advertised in the past, and from where. google and rbl lists are also worth querying in that context. joel On 9/14/10 1:51 PM, Greg Whynott wrote: > probably an odd question ? > > we have been assigned a few large blocks of IPs, and while configuring BGP i got to wondering what these block's history might be. who had them in the past, etc.. > > > is there a publicly accessible db or similar which tracks that type of information, or is that liability concern? > > thanks! > greg > > > > > Confidentiality Notice: This e-mail, including all attachments is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited unless specifically provided under the New Mexico Inspection of Public Records Act. If you are not the intended recipient, please contact the sender and destroy all copies of this message. -- This email has been scanned by the Sybari - Antigen Email System. From mohitlad at gmail.com Tue Sep 14 21:29:15 2010 From: mohitlad at gmail.com (Mohit Lad) Date: Tue, 14 Sep 2010 14:29:15 -0700 Subject: Present at The Tools Track at NANOG 50 Message-ID: Dear all, The Tools track at NANOG Atlanta is a chance to talk about and discover non-commercial network tools of interest to network operations. If you have open-source or non-commercial software that you wrote or use and is relevant to NANOG, consider presenting at this NANOGs Tools Track. Please get in touch with me directly if you are attending NANOG 50 and interested. Thanks Mohit From Greg.Whynott at oicr.on.ca Tue Sep 14 21:46:14 2010 From: Greg.Whynott at oicr.on.ca (Greg Whynott) Date: Tue, 14 Sep 2010 17:46:14 -0400 Subject: ip block history. In-Reply-To: <4C8FE29F.3030108@bogus.com> References: <4C8FE29F.3030108@bogus.com> Message-ID: Thanks for the pointers Joel! google knows all, scary isn't it? -g On Sep 14, 2010, at 5:01 PM, Joel Jaeggli wrote: > assuming the whois data has been cleaned up the next resource to look at > is: > > routeviews or ris table dumps to see where or if it was advertised in > the past, and from where. > > google and rbl lists are also worth querying in that context. > > joel > > On 9/14/10 1:51 PM, Greg Whynott wrote: >> probably an odd question ? >> >> we have been assigned a few large blocks of IPs, and while configuring BGP i got to wondering what these block's history might be. who had them in the past, etc.. >> >> >> is there a publicly accessible db or similar which tracks that type of information, or is that liability concern? >> >> thanks! >> greg >> >> >> >> >> > From owen at delong.com Tue Sep 14 21:55:07 2010 From: owen at delong.com (Owen DeLong) Date: Tue, 14 Sep 2010 14:55:07 -0700 Subject: Did Internet Founders Actually Anticipate Paid, Prioritized Traffic? In-Reply-To: <4C8FC5AA.8090702@gmail.com> References: <4C8F991A.70309@gmail.com> <4C8FC5AA.8090702@gmail.com> Message-ID: On Sep 14, 2010, at 11:57 AM, Dave Sparro wrote: > On 9/14/2010 1:08 PM, Owen DeLong wrote: >> >> On Sep 14, 2010, at 8:47 AM, Dave Sparro wrote: >> >>> On 9/13/2010 12:05 PM, William Herrin wrote: >>>> >>>> It's a question of double-billing. I've already paid you to send and >>>> receive packets on my behalf. Detuning my packets because a second >>>> party hasn't also paid you is cheating, maybe fraudulent. >>>> >>> >>> Would you object to an ISP model where a content provider could pay to get an ISP subscriber's package upgraded on a dynamic basis? >>> >> Yes... Because the reality is that it wouldn't be an upgrade. It would be a euphemism for downgrading the subscriber's experience with other content providers. >> > > So it's not fair for an ISP to limit a consumer's circuit to the speed they paid for, if there's excess capacity in the network? ie. If the ISP has capacity to offer 15Mbps down, that's what they should provide to a customer that has paid for 10Mbps. Where's the cut-off? > If they only downgraded things to the capacity I paid for, sure. However, that isn't what happens. >>> It would look something like my Road Runner PowerBoost(tm) service, only it never cuts off when the consumer is accessing a particular content provider's service. >>> >> Except that PowerBoost(tm) provides a burstable service where the capacity is already available and using it would not negatively impact other subscribers. This, on the other had, would create an SLA requiring your ISP to either build out quite a bit of additional capacity (not so likely) or to negatively impact their other subscribers in order to deliver content to the subscriber using this enhanced service. >> > I would think that the content provider's bag of cash is what would provide the incentive to add to capacity where needed. > It hasn't worked that way in similar situations I have observed in the past. In my experience, they pocket the cash as a windfall and move on. >>> That would allow Netflix/Hulu/OnLive/whoever to offer me a streaming service that requires a 15Mbps connection even though I'm not willing to upgrade my 10 up/1 down ISP connection to get it. >>> >> >> There's little difference in my mind between this model and a model where service provider X is in bed with content provider Y (perhaps they share common ownership) and subscribers to provider X are given a dramatically better user experience to content Y than to other content of a similar nature. >> > > I just don't see a way to get passed the current impasse. > The consumers are saying "I want faster, as long as I don't have to pay more." > Content providers are saying, "If consumers had faster, I'd be able to invent 'Killer App'. I sure wish the ISPs would upgrade their networks." > ISPs are saying, "Why should we upgrade our networks, nobody is willing to pay us to do so." > > I'm actually happy with the speed I currently have. For $99/month I get about 30mbps down and about 8mbps up. That's adequate for my household needs. I haven't encountered a content provider that has content I want that requires more than that. Where I have trouble is AT&T where I have paid them and they still haven't upgraded their wireless network. Owen From nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org Tue Sep 14 22:27:08 2010 From: nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org (Mark Smith) Date: Wed, 15 Sep 2010 07:57:08 +0930 Subject: Did Internet Founders Actually Anticipate Paid, Prioritized Traffic? In-Reply-To: <20100913150603.GA63307@ussenterprise.ufp.org> References: <20100913143148.GA59991@ussenterprise.ufp.org> <29A54911243620478FF59F00EBB12F47020BC7F2@ex01.drtel.lan> <20100913150603.GA63307@ussenterprise.ufp.org> Message-ID: <20100915075708.20032ba2@opy.nosense.org> On Mon, 13 Sep 2010 08:06:03 -0700 Leo Bicknell wrote: > In a message written on Mon, Sep 13, 2010 at 09:44:40AM -0500, Brian Johnson wrote: > > OK... so doesn't this speak to the commoditization of service providers? > > I'm against more regulation and for competition. > > Competition would be wonderful, but is simply not practical in many > cases. Most people and companies don't want to hear this, but from > a consumer perspective the Internet is a utility, and very closely > resembles water/sewer/electric/gas service. That is, having 20 > people run fiber past your home when you're only going to buy from > one of them makes no economic sense. Indeed, we probably wouldn't > have both cable and DSL service if those were both to the home for > other reasons already. > > > Explain how the provider of access is supposed to be able to control all > > of the systems outside it's control to get a specific speed from a > > content provider. If you are espousing contracts with each content > > provider, then you will quickly be destroying the Internet. > > That's not exactly what I am proposing; rather I'm proposing we > (the industry) develop a set of technical specifications and testing > where we can generally demonstrate this to be the case. Of course, > things may happen at any time, this isn't about individual machines, > or flash mobs. > That's why there isn't much value in them. You can't predict when these sorts of events are going to happen, so why would you want to make any sort of illusionary statements about assurances of service. The Internet is a best effort, not perfect effort, network. It does it's best with what is available at the time. There seems to be a fair bit of confusion between access rate and committed rate - some customers think access rate is committed rate. As mentioned earlier, because an ISP doesn't control the Internet, they can't make any committed rate assurances. What they can control is the access rate, and try to ensure that the access rate, which is dependent on what the customer is paying, marginally exceeds the common rate they can deliver to the customer, so that most of the time the customer sees the value in the bandwidth they've purchased. If there is too big a gap i.e. the customer never sees their link fully utilised, rather than occasionally, and hopefully quite often, they'll feel they've been sold something that isn't being delivered. > -- > Leo Bicknell - bicknell at ufp.org - CCIE 3440 > PGP keys at http://www.ufp.org/~bicknell/ From bzs at world.std.com Wed Sep 15 01:30:32 2010 From: bzs at world.std.com (Barry Shein) Date: Tue, 14 Sep 2010 21:30:32 -0400 Subject: Did Internet Founders Actually Anticipate Paid, Prioritized Traffic? In-Reply-To: References: <19598.25043.581492.654328@world.std.com> <8626EF19-F165-4FDE-B7CF-9F67A03CC7D3@cisco.com> Message-ID: <19600.8632.814275.641127@world.std.com> On September 14, 2010 at 00:49 williams.bruce at gmail.com (Bruce Williams) wrote: > > And what does this "appeal to the ancient wisdom" have to do with > technology and business today anyway? The article claimed that AT&T is claiming (to the FCC I think it was) that net non-neutrality was an early design goal of the internet, so they should be allowed to do whatever it is they want to do. Well, of course it was, only big research sites got IMPs with real 56k connections. Little guys like Apple, e.g., had to live on X.25 links from CSNET. BU was hooked up for a while via a 9600bps "cypress" link (a Vax 11/725* later Sun3/50 imp-a-like, via a serial port.) And we won't even talk about who got /8s. AT&T got 2 if I remember right though that company had no relationship to this AT&T which is just a rename of SBC after they bought some AT&T assets which owned the original trademark which is kind of like the old "if my grandmother had wheels they'd call her a trolley car" but I digress. As Jimmy Carter said: Life isn't fair. But that doesn't necessarily implore one to make it *more* unfair. * Never heard of a Vax 11/725? Then you are truly blessed. -- -Barry Shein The World | bzs at TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: 800-THE-WRLD | Dial-Up: US, PR, Canada Software Tool & Die | Public Access Internet | SINCE 1989 *oo* From smb at cs.columbia.edu Wed Sep 15 01:51:45 2010 From: smb at cs.columbia.edu (Steven Bellovin) Date: Tue, 14 Sep 2010 21:51:45 -0400 Subject: Did Internet Founders Actually Anticipate Paid, Prioritized Traffic? In-Reply-To: <19600.8632.814275.641127@world.std.com> References: <19598.25043.581492.654328@world.std.com> <8626EF19-F165-4FDE-B7CF-9F67A03CC7D3@cisco.com> <19600.8632.814275.641127@world.std.com> Message-ID: <67B4FDC4-295F-4242-B622-B4C4203B5C03@cs.columbia.edu> On Sep 14, 2010, at 9:30 32PM, Barry Shein wrote: > > On September 14, 2010 at 00:49 williams.bruce at gmail.com (Bruce Williams) wrote: >> >> And what does this "appeal to the ancient wisdom" have to do with >> technology and business today anyway? > > The article claimed that AT&T is claiming (to the FCC I think it was) > that net non-neutrality was an early design goal of the internet, so > they should be allowed to do whatever it is they want to do. > > Well, of course it was, only big research sites got IMPs with real 56k > connections. Little guys like Apple, e.g., had to live on X.25 links > from CSNET. BU was hooked up for a while via a 9600bps "cypress" link > (a Vax 11/725* later Sun3/50 imp-a-like, via a serial port.) > > And we won't even talk about who got /8s. AT&T got 2 if I remember > right though that company had no relationship to this AT&T which is > just a rename of SBC after they bought some AT&T assets which owned > the original trademark which is kind of like the old "if my > grandmother had wheels they'd call her a trolley car" but I digress. No, they bought AT&T, which had an ISP business, a long distance business, a private line business, and AT&T Labs, as well as other miscellaneous pieces like the brand name. We can wonder if AT&T would have survived as an independent company, but it was a going concern and not in bankruptcy at the time of the transaction. But yes, SBC is the controlling piece of the new AT&T. As for the two /8s -- not quite. Back in the 1980s, AT&T got 12/8. We soon learned that we couldn't make good use of it, since multiple levels of subnetting didn't exist. We offered it back to Postel in exchange for 135/8 -- i.e., the equivalent in class B space -- but Postel said to keep 12/8 since no one else could use it, either. This was all long before addresses were tight. When AT&T decided to go into the ISP business, circa 1995, 12/8 was still lying around, unused except for a security experiment I was running.* However, a good chunk of 135/8 went to Lucent (now Alcatel-Lucent) in 1996, though I don't know how much. --Steve Bellovin, http://www.cs.columbia.edu/~smb *The early sequence number guessing attack tools required a dead host that would be impersonated by the attacker. By chance, one of the early tools used something in 12/8. I started announcing it from Murray Hill, to catch the back-scatter from the victims. We found some of that; we also found lots of folks who were using 12/8 themselves, probably internally. From joe.abley at icann.org Wed Sep 15 01:56:14 2010 From: joe.abley at icann.org (Joe Abley) Date: Wed, 15 Sep 2010 01:56:14 +0000 Subject: IANA DNSSEC Testbed has been Decommissioned Message-ID: Colleagues, Following advanced notice sent to this list on 2010-08-03, the IANA testbed was shut down on 2010-09-03. For more details on the IANA DNSSEC testbed, see . For more details on DNSSEC deployment in the Root Zone, see . Queries to the nameserver bound to NS.IANA.ORG (208.77.188.32, 2620:0:2d0:1::32) now fail with ICMP type 3 code 3 (Destination Unreachable, Port Unreachable). We suggest that anybody using the DNSSEC testbed for anything resembling production services make plans to stop doing so at their earliest convenience, if operational necessity has not already made that obvious. ICANN would once again like to thank Packet Clearing House (PCH) and Dyn.com DynTLD for their support and generous donation of global DNS resources to the IANA DNSSEC testbed. Regards, Joe Abley Director DNS Operations, ICANN From richard.barnes at gmail.com Wed Sep 15 02:50:15 2010 From: richard.barnes at gmail.com (Richard Barnes) Date: Tue, 14 Sep 2010 22:50:15 -0400 Subject: ip block history. In-Reply-To: References: <4C8FE29F.3030108@bogus.com> Message-ID: RIPE has been developing a couple of projects to support this sort of history searching: Internet Resource Database (INRDB): Resource EXplainer (REX): On Tue, Sep 14, 2010 at 5:46 PM, Greg Whynott wrote: > Thanks for the pointers Joel! > google knows all, ?scary isn't it? > > -g > > > On Sep 14, 2010, at 5:01 PM, Joel Jaeggli wrote: > >> assuming the whois data has been cleaned up the next resource to look at >> is: >> >> routeviews or ris table dumps to see where or if it was advertised in >> the past, and from where. >> >> google and rbl lists are also worth querying in that context. >> >> joel >> >> On 9/14/10 1:51 PM, Greg Whynott wrote: >>> probably an odd question ? >>> >>> we have been assigned a few large blocks of IPs, ?and while configuring BGP i got to wondering what these block's history might be. ?who had them in the past, ? ?etc.. >>> >>> >>> is there a publicly accessible db or similar which tracks that type of information, ?or is that liability concern? >>> >>> thanks! >>> greg >>> >>> >>> >>> >>> >> > > > From packetgrrl at gmail.com Wed Sep 15 02:57:55 2010 From: packetgrrl at gmail.com (cja@daydream.com) Date: Tue, 14 Sep 2010 20:57:55 -0600 Subject: ip block history. In-Reply-To: References: Message-ID: There has been a suggestion in the ARIN region for a whowas service. - Suggestion 2008.15 ? WHOWAS service. Implementation to be completed as part of ARIN Online - ---CJ On Tue, Sep 14, 2010 at 2:51 PM, Greg Whynott wrote: > probably an odd question ? > > we have been assigned a few large blocks of IPs, and while configuring BGP > i got to wondering what these block's history might be. who had them in the > past, etc.. > > > is there a publicly accessible db or similar which tracks that type of > information, or is that liability concern? > > thanks! > greg > > > > > From cfp at cscjournals.org Thu Sep 16 05:36:59 2010 From: cfp at cscjournals.org (CFP- CSC Journals) Date: Wed, 15 Sep 2010 22:36:59 -0700 Subject: IJCN Call For Paper Message-ID: <032801cb5561$32f53330$0501a8c0@csc530c725574d> ***Apologies for cross-postings*** FINAL CALL FOR PAPER Submission deadline; September 30 2010 The 2nd volume and 5th Issue of International Journal of Computer Networks (IJCN) http://www.cscjournals.org/csc/description.php?JCode=IJCN BRIEF DESCRIPTION AND OBJECTIVES The International Journal of Computer Networks (IJCN) is an archival, bimonthly journal committed to the timely publications of peer-reviewed and original papers that advance the state-of-the-art and practical applications of computer networks. It provides a publication vehicle for complete coverage of all topics of interest to network professionals and brings to its readers the latest and most important findings in computer networks. To build its International reputation, we are disseminating the publication information through Google Books, Google Scholar, Directory of Open Access Journals (DOAJ), Open J Gate, ScientificCommons, Docstoc and many more. Our International Editors are working on establishing ISI listing and a good impact factor for IJCN. List of Topics The realm of International Journal of Computer Networks (IJCN) extends, but not limited, to the following: a.. Algorithms, Systems and Applications a.. Ad-hoc Wireless Networks a.. ATM Networks a.. Body Sensor Networks a.. Cellular Networks a.. Cognitive Radio Networks a.. Congestion and Flow Control a.. Cooperative Networks a.. Delay Tolerant Networks a.. Fault Tolerant Networks a.. Information Theory a.. Local Area Networks a.. Metropolitan Area Networks a.. MIMO Networks a.. Mobile Computing a.. Mobile Satellite Networks a.. Multicast and Broadcast Networks a.. Multimedia Networks a.. Network Architectures and Protocols a.. Network Coding a.. Network Modeling and Performance Analysis Network a.. Network Operation and Management a.. Network Security and Privacy a.. Network Services and Applications a.. Optical Networks a.. Peer-to-Peer Networks a.. Personal Area Networks a.. Switching and Routing a.. Telecommunication Networks a.. Trust Worth Computing a.. Ubiquitous Computing a.. Web-based Services a.. Wide Area Networks a.. Wireless Local Area Networks a.. Wireless Mesh Networks a.. Wireless Sensor Networks IMPORTANT DATES FOR TECHNICAL PAPERS AND POSTERS: Paper Submission: September 30 2010 Author Notification: November 01, 2010 Issue Publication: November / December 2010 For general inquiries regarding IJCN; including contact information of IJCN editors, please visit http://www.cscjournals.org/csc/description.php?JCode=IJCN or http://www.cscjournals.org. Sincerely, CFP-CSC Journals, Computer Science Journals M-3-19, Plaza Damas, Sri Hartamas 50480, Kuala Lumpur, Malaysia Phone: +603 6207 1607 Fax: 00603 6201 1664 Url: http://www.cscjournals.org From elmi at 4ever.de Wed Sep 15 08:29:18 2010 From: elmi at 4ever.de (Elmar K. Bins) Date: Wed, 15 Sep 2010 10:29:18 +0200 Subject: Reverse DNS for IPv6 client networks In-Reply-To: <20100914190808.GA20501@harry.lu> References: <20100914122758.GK63203@ronin.4ever.de> <20100914190808.GA20501@harry.lu> Message-ID: <20100915082918.GN63203@ronin.4ever.de> Re Harry, Owen and all the others, first, thank you for your feedback. Seems there is no real consensus, but people are leaning more towards "if it's dynamic, forget rDNS". The PowerDNS solution looks nice to me (alas, another chunk of software the system droids would have to maintain). I am also always fond of homegrown Scripts that get the job done. And yes, Harry... harry.nanog at harry.lu (Harry Strongburg) wrote: > However, I bet I totally misunderstood your question! You lose your that bet :-) Thanks for the pointer to the paper. Cheers, Elmar. -- "Machen Sie sich erst einmal unbeliebt. Dann werden Sie auch ernstgenommen." (Konrad Adenauer) --------------------------------------------------------------[ ELMI-RIPE ]--- From robert at ripe.net Wed Sep 15 08:53:51 2010 From: robert at ripe.net (Robert Kisteleki) Date: Wed, 15 Sep 2010 10:53:51 +0200 Subject: ip block history. In-Reply-To: References: <4C8FE29F.3030108@bogus.com> Message-ID: <4C90899F.2080205@ripe.net> On 2010.09.15. 4:50, Richard Barnes wrote: > RIPE has been developing a couple of projects to support this sort of > history searching: > > Internet Resource Database (INRDB): > > > Resource EXplainer (REX): > Indeed, REX is our prototype tool for these kind of questions. It has its own limitations, but so far it's the best tool I'm aware of. Robert From kompella at cs.purdue.edu Wed Sep 15 18:06:46 2010 From: kompella at cs.purdue.edu (Ramana Kompella) Date: Wed, 15 Sep 2010 14:06:46 -0400 Subject: CFP: COMSNETS 2011 (EXTENDED FIRM DEADLINE: Sept 27, 11:59pm PDT!) Message-ID: <20100915180646.GA20556@tirupati> *** APOLOGIES IF YOUR RECEIVED MULTIPLE COPIES OF THE CFP *** *** EXTENDED FIRM DEADLINE: Sept 27, 11:59pm PDT *** COMSNETS 2011 The THIRD International Conference on COMunication Systems and NETworks January 4-8, 2011, Bangalore, India http://www.comsnets.org (In Co-operation with ACM SIGMOBILE) (Technically Co-Sponsored by IEEE COMSOC) The Third International Conference on COMmunication Systems and NETworkS (COMSNETS) will be held in Bangalore, India, from 4 January 2011 to 8 January 2011. COMSNETS is a premier international conference dedicated to addressing advances in Networking and Communications Systems, and Telecommunications services. The goal of the conference is to create a world-class gathering of researchers from academia and industry, practitioners, business leaders, intellectual property experts, and venture capitalists, providing a forum for discussing cutting edge research, and directions for new innovative business and technology. The conference will include a highly selective technical program consisting of parallel tracks of submitted papers, a small set of invited papers on important and timely topics from well-known leaders in the field, and poster sessions of work in progress. Focused workshops and panel discussions will be held on emerging topics to allow for a lively exchange of ideas. International business and government leaders will be invited to share their perspectives, thus complementing the technical program. Papers describing original research work and practical experiences/experimental results are solicited on topics including, but not limited to: Topics of Interest ------------------ Internet Architecture and Protocols Network-based Applications Video Distribution (IPTV, Mobile Video, Video on Demand) Network Operations and Management Broadband and Cellular Networks (3G/4G, WiMAX/LTE) Mesh, Sensor and PAN Networks Communication Software (Cognitive Radios, DSA, SDR) Wireless Operating Systems and Mobile Platforms Peer-to-peer Networking Cognitive Radio and White Space Networking Optical Networks Network Security & Cyber Security Technologies Cloud and Utility computing Storage Area Networks Next Generation Web Architectures Vehicular Networking Energy-Efficient Networking Network Science and Emergent Behavior in Socio-Technical Networks Social Networking Analysis, Middleware and Applications Networking Technologies for Smart Energy Grids Disruption/Delay Tolerant Networking Conference Highlights --------------------- Conference Inaugural Speaker: Prof. Pravin Varaiya, U. C. Berkeley, USA Banquet speaker: Dr. Rajeev Rastogi, Yahoo Research, India Keynote Speakers: ? Prof. Don Towsley, U. Mass Amherst, USA ? Dr. Pravin Bhagwat, AirTight Networks, India ? Dr. Jean Bolot, Sprint, USA Workshops ? WISARD (4, 5 Jan) ? NetHealth (4 Jan) ? IAMCOM (5 Jan) ? Mobile India 2011 (7 Jan) Technical Paper and Poster Sessions Ph.D Forum Panel Discussions Demos & Exhibits Important Deadlines ------------------- Paper submission (FIRM, ABSOLUTELY NO EXTENSIONS): September 27, 2010 at 11:59 pm EDT (Sept 28, 9:29 am IST) Notification of Acceptance: November 8, 2010 Camera-Ready Submission: December 8, 2010 Detailed conference information and paper submission guidelines is available on the conference web site. Please see http://www.comsnets.org for detailed information from time to time. The conference email address is: comsnets2011 at gmail.com General Co-Chairs ----------------- David B. Johnson, Rice University, USA Anurag Kumar, IISc Bangalore, India Technical Program Co-Chairs --------------------------- Jon Crowcroft, U. of Cambridge, UK D. Manjunath, IIT Bombay, India Archan Misra, Telcordia Tech., USA Steering Committee Co-Chairs ---------------------------- Uday Desai, IIT Hyderabad, India Giridhar Mandyam, Qualcomm, USA Sanjoy Paul, Infosys, India Rajeev Shorey, NIIT University, India G. Venkatesh, SASKEN, India Panel Co-Chairs --------------- Aditya Akella, U. of Wisconsin, USA Venkat Padmanabhan, MSR, India Ph.D Forum Chair ---------------- Bhaskaran Raman, IIT Bombay, India Publications Chair ------------------ Varsha Apte, IIT Bombay, India Demos and Exhibits Co-Chairs ---------------------------- Aaditeshwar Seth, IIT Delhi, India Ajay Bakre, Netapps, India Sponsorship Chair ----------------- Sudipta Maitra, Delhi, india Workshop Chairs --------------- Sharad Jaiswal, Alcatel-Lucent, India Ravindran Kaliappa, CUNY, USA Neelesh Mehta, IISc Bangalore, India Mobile India 2011 Co-Chairs --------------------------- Gulzar Azad, Google, India Gene Landy, Ruperto-Israel & Weiner, USA Rajaraghavan Setlur, SASKEN, India Sridhar Varadharajan, SASKEN, India Publicity Co-Chair ------------------ Augustin Chaintreau, TTL, France Kameswari Chebrolu, IIT Bombay, India Song Chong, KAIST, Korea Ramana Kompella, Purdue Univ, USA Nishanth Sastry, U. of Cambridge, UK Web Co-Chairs ------------- Santhana Krishnan, IIT Bombay, India Vinay Veerappa, SASKEN, India International Advisory Committee -------------------------------- K. K. Ramakrishnan, AT&T, USA Victor Bahl, Microsoft Research, USA Sunghyun Choi, Seoul National U., Korea Sajal Das, U. Texas at Arlington, USA B. N. Jain, IIT Delhi, India Anurag Kumar, IISc, Bangalore, India L. M. Patnaik, IISc, Bangalore, India Krithi Ramamritham, IIT Bombay, India Parmesh Ramanathan, U. Wisconsin, USA Krishan Sabnani, Alcatel-Lucent, USA Kang Shin, U. Michigan, USA Nitin Vaidya, U. Illinois, USA University Partners: -------------------- IIT Bombay, IIT Delhi, IISc Bangalore, IIT Hyderabad, NIIT University, IIIT Bangalore Patrons: -------- Mobile Monday Bangalore, Sasken, IBM Research, Alcatel Lucent From gbonser at seven.com Thu Sep 16 05:15:30 2010 From: gbonser at seven.com (George Bonser) Date: Wed, 15 Sep 2010 22:15:30 -0700 Subject: Did Internet Founders Actually Anticipate Paid, Prioritized Traffic? In-Reply-To: References: Message-ID: <5A6D953473350C4B9995546AFE9939EE0A52AD76@RWC-EX1.corp.seven.com> The problem I have with the concept is that paid prioritization only really has an impact once there is congestion. If your buffers are empty, then there is no real benefit to priority because everything is still being sent as it comes in. If you have paid prioritization, there is a financial incentive to have congestion in order to collect "toll" on the expressway. So if I have a network that is not congested, nobody is going to pay me to ride on a special lane. If I neglect upgrading the network and it becomes congested, I can make money by selling access to an express lane. I believe a network should be able to sell priotitization at the edge, but not in the core. I have no problem with Y!, for example, paying a network to be prioritized ahead of bit torrent on the segment to the end user but I do have a problem with networks selling prioritized access through the core as that only gives an incentive to congest the network to create revenue. G > -----Original Message----- > From: Hank Nussbacher [mailto:hank at efes.iucc.ac.il] > Sent: Monday, September 13, 2010 12:22 AM > To: nanog at nanog.org > Subject: Did Internet Founders Actually Anticipate Paid, Prioritized > Traffic? > > http://www.wired.com/epicenter/2010/09/paid-prioritized-traffic > > -Hank From gordslater at ieee.org Thu Sep 16 06:22:13 2010 From: gordslater at ieee.org (gordon b slater) Date: Thu, 16 Sep 2010 07:22:13 +0100 Subject: Did Internet Founders Actually Anticipate Paid, Prioritized Traffic? In-Reply-To: <5A6D953473350C4B9995546AFE9939EE0A52AD76@RWC-EX1.corp.seven.com> References: <5A6D953473350C4B9995546AFE9939EE0A52AD76@RWC-EX1.corp.seven.com> Message-ID: <1284618133.8445.22.camel@ub-g-d2> inline... On Wed, 2010-09-15 at 22:15 -0700, George Bonser wrote: > The problem I have with the concept is that paid prioritization only > really has an impact once there is congestion. If your buffers are > empty, then there is no real benefit to priority because everything is > still being sent as it comes in. If you have paid prioritization, there > is a financial incentive to have congestion in order to collect "toll" > on the expressway. So if I have a network that is not congested, nobody > is going to pay me to ride on a special lane. That's a serious problem that came up verbatim in an overheard (#1) conversation yesterday. The bean-counters (who must, unfortunately, remain nameless) coined the phrase "fill your buffers and fill your boots". I was left with the distinct unsavoury impression that they were drawing up a (contingency) plan for that exact eventuality. > I believe a network should be able to sell priotitization at the edge, > but not in the core. I have no problem with Y!, for example, paying a > network to be prioritized ahead of bit torrent on the segment to the end > user but I do have a problem with networks selling prioritized access > through the core as that only gives an incentive to congest the network > to create revenue. > +1, because anything other than that Paid-Edge-Prio(#2), to me, smells of theft, fraud, and frankly, B-S. IANAL Gord (#1) on a comletely unrelated topic, twisted pairs could possibly great mike leads, don't you think? (#2) you heard it here first. Like wise, Paid-Core-Prio. Hey, I could patent-troll this stuff :) -- $ cowsay paid-prio ( rip-off ) -------- o ^__^ o (oo)\_______ (__)\ )\/\ \ ||----w | \_____ || || From kweheria at gmail.com Thu Sep 16 12:58:15 2010 From: kweheria at gmail.com (Kweheria Erick) Date: Thu, 16 Sep 2010 15:58:15 +0300 Subject: SONET/SDH virtual tributary mapping to use KLM mode Message-ID: <1284641895.20799.6.camel@kweheria.uunet.co.ke> Hi, Someone please help me understand, in the SONET/SDH virtual tributary mapping context, K-L-M numbers are used to describe E1 positions. What do the initials KLM stand for? Regards, kweheria From theghost101 at gmail.com Thu Sep 16 12:57:56 2010 From: theghost101 at gmail.com (Danijel) Date: Thu, 16 Sep 2010 14:57:56 +0200 Subject: SONET/SDH virtual tributary mapping to use KLM mode In-Reply-To: <1284641895.20799.6.camel@kweheria.uunet.co.ke> References: <1284641895.20799.6.camel@kweheria.uunet.co.ke> Message-ID: Hi K describes TUG-3 group (1-3) L describes a TUG-2 group inside a TUG-3 (1-7) M describes a TU-12/VC12/E1 inside a TUG-2 (1-3) I'm not sure if they actually have some meaning. -- *blap* On Thu, Sep 16, 2010 at 14:58, Kweheria Erick wrote: > Hi, > > Someone please help me understand, in the SONET/SDH virtual tributary > mapping context, K-L-M numbers are used to describe E1 positions. > What do the initials KLM stand for? > > Regards, > kweheria > > > From cboyd at gizmopartners.com Thu Sep 16 13:19:27 2010 From: cboyd at gizmopartners.com (Chris Boyd) Date: Thu, 16 Sep 2010 08:19:27 -0500 Subject: Did Internet Founders Actually Anticipate Paid, Prioritized Traffic? In-Reply-To: <5A6D953473350C4B9995546AFE9939EE0A52AD76@RWC-EX1.corp.seven.com> References: <5A6D953473350C4B9995546AFE9939EE0A52AD76@RWC-EX1.corp.seven.com> Message-ID: <6F3DB878-64EF-4590-952C-0D5C81733EA4@gizmopartners.com> On Sep 16, 2010, at 12:15 AM, George Bonser wrote: > I believe a network should be able to sell priotitization at the edge, > but not in the core. I have no problem with Y!, for example, paying a > network to be prioritized ahead of bit torrent on the segment to the end > user but I do have a problem with networks selling prioritized access > through the core as that only gives an incentive to congest the network > to create revenue. I DO have a problem with a content provider paying to get priority access on the last mile. I have no particular interest in any of the content that Yahoo provides, but I do have an interest in downloading my Linux updates via torrents. Should I have to go back and bid against Yahoo just so I can get my packets in a timely fashion? I understand that the last mile is going to be a congestion point, but the idea of allowing a bidding war for priority access for that capacity seems to be a path to madness. --Chris From christian.martin at teliris.com Thu Sep 16 13:47:57 2010 From: christian.martin at teliris.com (Christian Martin) Date: Thu, 16 Sep 2010 09:47:57 -0400 Subject: SONET/SDH virtual tributary mapping to use KLM mode In-Reply-To: References: <1284641895.20799.6.camel@kweheria.uunet.co.ke> Message-ID: On Sep 16, 2010, at 8:57 AM, Danijel wrote: > > K describes TUG-3 group (1-3) > L describes a TUG-2 group inside a TUG-3 (1-7) > M describes a TU-12/VC12/E1 inside a TUG-2 (1-3) > > I'm not sure if they actually have some meaning. They are merely alphabetical indexes. C From kweheria at gmail.com Thu Sep 16 14:05:06 2010 From: kweheria at gmail.com (Kweheria Erick) Date: Thu, 16 Sep 2010 17:05:06 +0300 Subject: SONET/SDH virtual tributary mapping to use KLM mode In-Reply-To: References: <1284641895.20799.6.camel@kweheria.uunet.co.ke> Message-ID: <1284645906.20799.39.camel@kweheria.uunet.co.ke> Thanks, Always wondered what the motivation behind those exact letters was. -----Original Message----- From: Christian Martin To: Danijel Cc: Kweheria Erick , nanog at nanog.org Subject: Re: SONET/SDH virtual tributary mapping to use KLM mode Date: Thu, 16 Sep 2010 09:47:57 -0400 On Sep 16, 2010, at 8:57 AM, Danijel wrote: > > K describes TUG-3 group (1-3) > L describes a TUG-2 group inside a TUG-3 (1-7) > M describes a TU-12/VC12/E1 inside a TUG-2 (1-3) > > I'm not sure if they actually have some meaning. They are merely alphabetical indexes. C From jgreco at ns.sol.net Thu Sep 16 13:59:23 2010 From: jgreco at ns.sol.net (Joe Greco) Date: Thu, 16 Sep 2010 08:59:23 -0500 (CDT) Subject: Did Internet Founders Actually Anticipate Paid, In-Reply-To: <6F3DB878-64EF-4590-952C-0D5C81733EA4@gizmopartners.com> Message-ID: <201009161359.o8GDxNQ0044586@aurora.sol.net> > On Sep 16, 2010, at 12:15 AM, George Bonser wrote: > > I believe a network should be able to sell priotitization at the edge, > > but not in the core. I have no problem with Y!, for example, paying a > > network to be prioritized ahead of bit torrent on the segment to the = > end > > user but I do have a problem with networks selling prioritized access > > through the core as that only gives an incentive to congest the = > network > > to create revenue. > > > I DO have a problem with a content provider paying to get priority = > access on the last mile. I have no particular interest in any of the = > content that Yahoo provides, but I do have an interest in downloading my = > Linux updates via torrents. Should I have to go back and bid against = > Yahoo just so I can get my packets in a timely fashion? > > > I understand that the last mile is going to be a congestion point, but = > the idea of allowing a bidding war for priority access for that capacity = > seems to be a path to madness. Well, that's really the whole problem here. All of the serious "paid priority access" schemes appear to exist to try to squeeze money out of the other end of the connection. You, as a consumer, are already paying your ISP for the privilege of connecting to the Internet. It shouldn't be your ISP's role to determine what your intended use of that connection is. If you're using it for VoIP and videoconferencing, you gain no benefit from Yahoo!(*) paying for "priority" access. If you use it for VPN into your employer's corporate network, there's no advantage to Netflix(*) shoving your packets aside for theirs. If you use it for torrents for your FreeBSD updates, etc... [requoting a bit of the above] > > I have no problem with Y!, for example, paying a network to be > > prioritized ahead of bit torrent on the segment to the end user I *do* see a problem with prioritizing traffic type A ahead of traffic type B. If I'm your customer and you've sold me a 15M/2M circuit, maybe I plan to use that to access my employer's network via VPN. Now you want to declare my traffic "unworthy" because Yahoo!(*) has paid extra for "priority"? So I get "leftovers"? On one hand, we all recognize oversubscription as an issue. As an industry, service providers have worked hard to avoid committing to any particular service level, especially for end-user products like cable and DSL. The usual reasoning is that there's no way to guarantee it once it leaves their network. However, on the other hand, no attempt is made to guarantee it even on their network. What prevents a service provider from saying "We're selling you a 15M/2M circuit, and we guarantee that we've got sufficient capacity to consistently deliver at least 4M/512K through our network and to our peers/upstreams?" If all my neighbors suddenly decide one day to watch YouTube(*) due to some major event, and YouTube(*) has paid for priority access, and my 15M circuit suddenly drops to a few tens of kilobits because everyone else on this leg is competing for bandwidth, and there's more prioritized traffic than the leg can handle, how is that in any way a benefit to the consumer? There are some real risks associated with paid prioritization. Put it a different way: [restating the above] "I have no problem with ${a major drug manufacturer}, for example, paying my doctor to prescribe their products instead of their competitor's, even where the competitor's product might be a better fit for my medical needs." Now, really, just think about that for a little while. (*) All companies listed are just used as hypothetical examples, and should not be considered as anything more than 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 lee at asgard.org Thu Sep 16 14:09:24 2010 From: lee at asgard.org (Lee Howard) Date: Thu, 16 Sep 2010 10:09:24 -0400 Subject: Reverse DNS for IPv6 client networks In-Reply-To: <20100914122758.GK63203@ronin.4ever.de> References: <20100914122758.GK63203@ronin.4ever.de> Message-ID: <000001cb55a8$c553c7e0$4ffb57a0$@org> I've written an internet-draft on the subject: http://tools.ietf.org/html/draft-howard-isp-ip6rdns-04 The latest update was to add a Recommendations section: The best option is for ISPs to delegate authority along with address delegation. Where users do not operate authoritative name servers, the next best option is dynamic DNS updates. Where dynamic DNS is impractical, the next best option is to dynamically generate PTR records when queried. In other words, when you do prefix delegation to a residential customer, generate records on the fly. Ask your DNS vendor to show you how. Wildcards work if all you want is a non-null response. I'm looking for support or opposition to this. I just can't see any better way to do it. Lee > -----Original Message----- > From: Elmar K. Bins [mailto:elmi at 4ever.de] > Sent: Tuesday, September 14, 2010 8:28 AM > To: nanog at nanog.org > Subject: Reverse DNS for IPv6 client networks > > Hi guys, > > I am looking for operational experience here. > > We have just turned up IPv6 in our "guest wireless", by way of using RA > for address distribution and DHCPv6 for the DNS server address (stupid, yup). > > Apart from the dhcp6 part seemingly not working on Juniper ISGs (or maybe it's > my windows *and* that Ubuntu), I now see IPv6 addresses instead of names. > > I as a networking droid have not much quarrel with that, but I am interested > in how or whether at all others handle this. > > Are you creating DNS entries somehow (reverse and, ultimately, forward), > are you using BIND "generate" statements, are you using wildcards...or > are you just ignoring this for the "dynamic boxes"? > > Please enlighten me! > > Elmar. From jbates at brightok.net Thu Sep 16 15:33:55 2010 From: jbates at brightok.net (Jack Bates) Date: Thu, 16 Sep 2010 10:33:55 -0500 Subject: Did Internet Founders Actually Anticipate Paid, Prioritized Traffic? In-Reply-To: <6F3DB878-64EF-4590-952C-0D5C81733EA4@gizmopartners.com> References: <5A6D953473350C4B9995546AFE9939EE0A52AD76@RWC-EX1.corp.seven.com> <6F3DB878-64EF-4590-952C-0D5C81733EA4@gizmopartners.com> Message-ID: <4C9238E3.6000705@brightok.net> On 9/16/2010 8:19 AM, Chris Boyd wrote: > > I DO have a problem with a content provider paying to get priority access on the last mile. I have no particular interest in any of the content that Yahoo provides, but I do have an interest in downloading my Linux updates via torrents. Should I have to go back and bid against Yahoo just so I can get my packets in a timely fashion? > Depends on what constitutes last mile, really. For me, it would be prioritizing traffic over a customer's saturated DSL line (ie, you paid for and saturated your bandwidth). Although, to be honest, I've been extremely tempted to just prioritize for free. Your case in point, if you are streaming video from Y' and doing a bittorrent, there is still the presumption that you want the bittorrent to play nice and let your video stream. Of course, proper prioritizing really requires both sides working together. I've had more issues with upstreams saturating and killing a video stream than I have with downstreams saturating. > I understand that the last mile is going to be a congestion point, but the idea of allowing a bidding war for priority access for that capacity seems to be a path to madness. It seems pointless, really. Customer has to request the content, for the priority to matter. It only makes sense in a shared pipe, and that's where bottlenecks shouldn't be (ie, customer A's video shouldn't have precedence over Customer B's p2p (which may be valid WoW updates, iso downloads, etc). Jack From stefan at csudsu.com Thu Sep 16 15:55:13 2010 From: stefan at csudsu.com (Stefan Molnar) Date: Thu, 16 Sep 2010 08:55:13 -0700 (PDT) Subject: XO Routing Message-ID: <20100916085237.V46129@clockwork> Anyone know the impact on the XO Routing/Peering that is happening right now? We have had spotty connectivity for the last hour. Stefan From w3yni1 at gmail.com Thu Sep 16 15:59:20 2010 From: w3yni1 at gmail.com (Charles Mills) Date: Thu, 16 Sep 2010 11:59:20 -0400 Subject: XO Routing In-Reply-To: <20100916085237.V46129@clockwork> References: <20100916085237.V46129@clockwork> Message-ID: The internet health report is showing high latency to most of their peers. Chuck. On Sep 16, 2010 11:57 AM, "Stefan Molnar" wrote: > > Anyone know the impact on the XO Routing/Peering that is happening right > now? We have had spotty connectivity for the last hour. > > Stefan > From dhubbard at dino.hostasaurus.com Thu Sep 16 15:59:16 2010 From: dhubbard at dino.hostasaurus.com (David Hubbard) Date: Thu, 16 Sep 2010 11:59:16 -0400 Subject: XO Routing Message-ID: I know their own phone systems went down, or perhaps were overloaded; we lost our office connection to them but our phones remained online. I called their tech line by cell, was told thanks for calling XO, we are experiencing technical difficulties and then it hung up on me. :-) This seems to happen about once a month with them though so I'm used to it. David > -----Original Message----- > From: Stefan Molnar [mailto:stefan at csudsu.com] > Sent: Thursday, September 16, 2010 11:55 AM > To: nanog at nanog.org > Subject: XO Routing > > > Anyone know the impact on the XO Routing/Peering that is > happening right > now? We have had spotty connectivity for the last hour. > > Stefan > > > From patrick at ianai.net Thu Sep 16 16:04:38 2010 From: patrick at ianai.net (Patrick W. Gilmore) Date: Thu, 16 Sep 2010 12:04:38 -0400 Subject: XO Routing In-Reply-To: References: <20100916085237.V46129@clockwork> Message-ID: <97F4705B-0169-4552-B69D-4603A6A22E8B@ianai.net> This should probably be on outages@, but XO is definitely having problems to places like speedtest.com & RCN from Boston. -- TTFN, patrick On Sep 16, 2010, at 11:59 AM, Charles Mills wrote: > The internet health report is showing high latency to most of their peers. > > Chuck. > > On Sep 16, 2010 11:57 AM, "Stefan Molnar" wrote: >> >> Anyone know the impact on the XO Routing/Peering that is happening right >> now? We have had spotty connectivity for the last hour. >> >> Stefan >> > From stefan at csudsu.com Thu Sep 16 16:04:17 2010 From: stefan at csudsu.com (Stefan Molnar) Date: Thu, 16 Sep 2010 09:04:17 -0700 (PDT) Subject: XO Routing In-Reply-To: References: Message-ID: <20100916090239.W46129@clockwork> I get the same hang up message, but did get in queue. The PSTN side is working fine from what I can see as our phones at a few locations are fine, but it is a shot in the dark for anything IP. On Thu, 16 Sep 2010, David Hubbard wrote: > I know their own phone systems went down, or perhaps > were overloaded; we lost our office connection to them > but our phones remained online. I called their tech > line by cell, was told thanks for calling XO, we are > experiencing technical difficulties and then it hung > up on me. :-) This seems to happen about once a month > with them though so I'm used to it. > > David > >> -----Original Message----- >> From: Stefan Molnar [mailto:stefan at csudsu.com] >> Sent: Thursday, September 16, 2010 11:55 AM >> To: nanog at nanog.org >> Subject: XO Routing >> >> >> Anyone know the impact on the XO Routing/Peering that is >> happening right >> now? We have had spotty connectivity for the last hour. >> >> Stefan >> >> >> > > > From will at collier-byrd.net Thu Sep 16 16:09:12 2010 From: will at collier-byrd.net (William Byrd) Date: Thu, 16 Sep 2010 12:09:12 -0400 Subject: XO Routing In-Reply-To: <97F4705B-0169-4552-B69D-4603A6A22E8B@ianai.net> References: <20100916085237.V46129@clockwork> <97F4705B-0169-4552-B69D-4603A6A22E8B@ianai.net> Message-ID: XO Engineers are telling us that they are aware of packet loss across their network and are looking into it. We're experiencing slow/degraded connectivity out of St. Louis and Nashville but Atlanta and Dallas are problem free. William Collier-Byrd will at collier-byrd.net On Thu, Sep 16, 2010 at 12:04 PM, Patrick W. Gilmore wrote: > This should probably be on outages@, but XO is definitely having problems > to places like speedtest.com & RCN from Boston. > > -- > TTFN, > patrick > > > On Sep 16, 2010, at 11:59 AM, Charles Mills wrote: > > > The internet health report is showing high latency to most of their > peers. > > > > Chuck. > > > > On Sep 16, 2010 11:57 AM, "Stefan Molnar" wrote: > >> > >> Anyone know the impact on the XO Routing/Peering that is happening right > >> now? We have had spotty connectivity for the last hour. > >> > >> Stefan > From Valdis.Kletnieks at vt.edu Thu Sep 16 16:10:11 2010 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Thu, 16 Sep 2010 12:10:11 -0400 Subject: Did Internet Founders Actually Anticipate Paid, In-Reply-To: Your message of "Thu, 16 Sep 2010 08:59:23 CDT." <201009161359.o8GDxNQ0044586@aurora.sol.net> References: <201009161359.o8GDxNQ0044586@aurora.sol.net> Message-ID: <12942.1284653411@localhost> On Thu, 16 Sep 2010 08:59:23 CDT, Joe Greco said: > What prevents a service provider from saying "We're selling you a > 15M/2M circuit, and we guarantee that we've got sufficient capacity > to consistently deliver at least 4M/512K through our network and to > our peers/upstreams?" Can I have that as "4M guaranteed, burstable to 15M, 95th percentile billing"? I'd rather have that than pay for 15M for the 1 hour a month I actually need it. (And yes, I'm fully aware of what the margin is on the consumer-grade cable I have, and why cookie-cutter installs are required to make even that margin, and why it won't happen unless I jump to the business-class side. Doesn't mean I can't dream... :) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From sil at infiltrated.net Thu Sep 16 16:11:36 2010 From: sil at infiltrated.net (J. Oquendo) Date: Thu, 16 Sep 2010 12:11:36 -0400 Subject: XO Routing In-Reply-To: <20100916085237.V46129@clockwork> References: <20100916085237.V46129@clockwork> Message-ID: <4C9241B8.80008@infiltrated.net> Stefan Molnar wrote: > > > > Anyone know the impact on the XO Routing/Peering that is happening > > right now? We have had spotty connectivity for the last hour. > > > > Stefan > > > > > I don't know the exact impact but I've had my Covad and AT&T customers ready to hang me because of what's going on. As of right this moment, my Covad connections are slowly coming back but have been acting spotty, I haven't heard complaints about the AT&T side for about 30-40 minutes. My POV, Covad is shaky because of their peering to XO. AT&T might have corrected itself. David Hubbard wrote: > > I know their own phone systems went down, or perhaps > > were overloaded; we lost our office connection to them > > but our phones remained online. I called their tech > > line by cell, was told thanks for calling XO, we are > > experiencing technical difficulties and then it hung > > up on me. :-) This seems to happen about once a month > > with them though so I'm used to it. > > > > David > > > Their own phone systems... I have a lot of clients whose providers peer with XO whose phone systems went kaput (one way audio, resolved, nope, resolved, nope). This is one of the downsides of working an ITSP. Trying to explain to clients why another provider they've never heard of is impacting their business. Oy VoIP, how I loathe you. -- =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ J. Oquendo SGFA, SGFE, C|EH, CNDA, CHFI, OSCP, CPT "It takes 20 years to build a reputation and five minutes to ruin it. If you think about that, you'll do things differently." - Warren Buffett 227C 5D35 7DCB 0893 95AA 4771 1DCE 1FD1 5CCD 6B5E http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x5CCD6B5E -- =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ J. Oquendo SGFA, SGFE, C|EH, CNDA, CHFI, OSCP, CPT "It takes 20 years to build a reputation and five minutes to ruin it. If you think about that, you'll do things differently." - Warren Buffett 227C 5D35 7DCB 0893 95AA 4771 1DCE 1FD1 5CCD 6B5E http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x5CCD6B5E From awacs at ziskind.us Thu Sep 16 16:13:35 2010 From: awacs at ziskind.us (N. Yaakov Ziskind) Date: Thu, 16 Sep 2010 12:13:35 -0400 Subject: Chase.com outage Message-ID: <20100916121335.C19215@egps.ziskind.us> Does anyone have any information (beyond the wimpy statement that "technical issues" were to blame) on the Chase outage? It seems that when a multibillion dollar company's major web site is down for more than a day, there must be juicy "technical issues" that beg to be told. So, can anyone dish? :-) -- _________________________________________ Nachman Yaakov Ziskind, FSPA, LLM awacs at ziskind.us Attorney and Counselor-at-Law http://ziskind.us Economic Group Pension Services http://egps.com Actuaries and Employee Benefit Consultants From Mark.Calkins at twtelecom.com Thu Sep 16 16:18:23 2010 From: Mark.Calkins at twtelecom.com (Calkins, Mark) Date: Thu, 16 Sep 2010 11:18:23 -0500 Subject: XO Routing In-Reply-To: References: <20100916085237.V46129@clockwork><97F4705B-0169-4552-B69D-4603A6A22E8B@ianai.net> Message-ID: XO began advertising way too many prefixes, a few hours ago. Most likely tripping most of their peers max-prefix limits. Filters are your friends. ~mark -----Original Message----- From: William Byrd [mailto:will at collier-byrd.net] Sent: Thursday, September 16, 2010 10:09 AM To: Patrick W. Gilmore Cc: NANOG list Subject: Re: XO Routing XO Engineers are telling us that they are aware of packet loss across their network and are looking into it. We're experiencing slow/degraded connectivity out of St. Louis and Nashville but Atlanta and Dallas are problem free. William Collier-Byrd will at collier-byrd.net On Thu, Sep 16, 2010 at 12:04 PM, Patrick W. Gilmore wrote: > This should probably be on outages@, but XO is definitely having > problems to places like speedtest.com & RCN from Boston. > > -- > TTFN, > patrick > > > On Sep 16, 2010, at 11:59 AM, Charles Mills wrote: > > > The internet health report is showing high latency to most of their > peers. > > > > Chuck. > > > > On Sep 16, 2010 11:57 AM, "Stefan Molnar" wrote: > >> > >> Anyone know the impact on the XO Routing/Peering that is happening > >> right now? We have had spotty connectivity for the last hour. > >> > >> Stefan > --- The content contained in this electronic message is not intended to constitute formation of a contract binding tw telecom. tw telecom will be contractually bound only upon execution, by an authorized officer, of a contract including agreed terms and conditions or by express application of its tariffs. This message is intended only for the use of the individual or entity to which it is addressed. If the reader of this message is not the intended recipient, or the employee or agent responsible for delivering the message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this message is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the sender of this E-Mail or by telephone. From zaid at zaidali.com Thu Sep 16 16:27:40 2010 From: zaid at zaidali.com (Zaid Ali) Date: Thu, 16 Sep 2010 09:27:40 -0700 Subject: Chase.com outage In-Reply-To: <20100916121335.C19215@egps.ziskind.us> Message-ID: Isn't that reserved for beer sessions at NANOG? On 9/16/10 9:13 AM, "N. Yaakov Ziskind" wrote: > Does anyone have any information (beyond the wimpy statement that > "technical issues" were to blame) on the Chase outage? > > It seems that when a multibillion dollar company's major web site is > down for more than a day, there must be juicy "technical issues" that > beg to be told. So, can anyone dish? :-) > > -- > _________________________________________ > Nachman Yaakov Ziskind, FSPA, LLM awacs at ziskind.us > Attorney and Counselor-at-Law http://ziskind.us > Economic Group Pension Services http://egps.com > Actuaries and Employee Benefit Consultants > From Mark.Calkins at twtelecom.com Thu Sep 16 16:28:08 2010 From: Mark.Calkins at twtelecom.com (Calkins, Mark) Date: Thu, 16 Sep 2010 11:28:08 -0500 Subject: XO Routing In-Reply-To: References: <20100916085237.V46129@clockwork><97F4705B-0169-4552-B69D-4603A6A22E8B@ianai.net> Message-ID: Looks like XO has stopped advertising its peer's prefixes. Sessions coming back up and stable. -----Original Message----- From: Calkins, Mark [mailto:Mark.Calkins at twtelecom.com] Sent: Thursday, September 16, 2010 10:18 AM To: William Byrd Cc: NANOG list Subject: RE: XO Routing XO began advertising way too many prefixes, a few hours ago. Most likely tripping most of their peers max-prefix limits. Filters are your friends. ~mark -----Original Message----- From: William Byrd [mailto:will at collier-byrd.net] Sent: Thursday, September 16, 2010 10:09 AM To: Patrick W. Gilmore Cc: NANOG list Subject: Re: XO Routing XO Engineers are telling us that they are aware of packet loss across their network and are looking into it. We're experiencing slow/degraded connectivity out of St. Louis and Nashville but Atlanta and Dallas are problem free. William Collier-Byrd will at collier-byrd.net On Thu, Sep 16, 2010 at 12:04 PM, Patrick W. Gilmore wrote: > This should probably be on outages@, but XO is definitely having > problems to places like speedtest.com & RCN from Boston. > > -- > TTFN, > patrick > > > On Sep 16, 2010, at 11:59 AM, Charles Mills wrote: > > > The internet health report is showing high latency to most of their > peers. > > > > Chuck. > > > > On Sep 16, 2010 11:57 AM, "Stefan Molnar" wrote: > >> > >> Anyone know the impact on the XO Routing/Peering that is happening > >> right now? We have had spotty connectivity for the last hour. > >> > >> Stefan > --- The content contained in this electronic message is not intended to constitute formation of a contract binding tw telecom. tw telecom will be contractually bound only upon execution, by an authorized officer, of a contract including agreed terms and conditions or by express application of its tariffs. This message is intended only for the use of the individual or entity to which it is addressed. If the reader of this message is not the intended recipient, or the employee or agent responsible for delivering the message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this message is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the sender of this E-Mail or by telephone. --- The content contained in this electronic message is not intended to constitute formation of a contract binding tw telecom. tw telecom will be contractually bound only upon execution, by an authorized officer, of a contract including agreed terms and conditions or by express application of its tariffs. This message is intended only for the use of the individual or entity to which it is addressed. If the reader of this message is not the intended recipient, or the employee or agent responsible for delivering the message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this message is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the sender of this E-Mail or by telephone. From bill at herrin.us Thu Sep 16 16:33:36 2010 From: bill at herrin.us (William Herrin) Date: Thu, 16 Sep 2010 12:33:36 -0400 Subject: Did Internet Founders Actually Anticipate Paid, In-Reply-To: <12942.1284653411@localhost> References: <201009161359.o8GDxNQ0044586@aurora.sol.net> <12942.1284653411@localhost> Message-ID: On Thu, Sep 16, 2010 at 12:10 PM, wrote: > On Thu, 16 Sep 2010 08:59:23 CDT, Joe Greco said: >> What prevents a service provider from saying "We're selling you a >> 15M/2M circuit, and we guarantee that we've got sufficient capacity >> to consistently deliver at least 4M/512K through our network and to >> our peers/upstreams?" > > Can I have that as "4M guaranteed, burstable to 15M, 95th percentile billing"? No, you can't. You're buying a consumer-oriented commodity product. Your few words pack a powerful amount of insider knowledge that the overwhelming majority of consumers don't want to have to learn in order to compare vendor offerings. So they aren't asked to. If you want a non-commodity product you'll have to pay a non-commodity price to a niche vendor. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From jeffrey.lyon at blacklotus.net Thu Sep 16 16:35:17 2010 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Thu, 16 Sep 2010 21:05:17 +0430 Subject: XO Routing In-Reply-To: References: <20100916085237.V46129@clockwork> <97F4705B-0169-4552-B69D-4603A6A22E8B@ianai.net> Message-ID: Hopefully they don't treat this the same way they treat their billing, otherwise you all will be degraded for months or even years. It is absolutely amazing that this company is still in business. Jeff On Thu, Sep 16, 2010 at 8:48 PM, Calkins, Mark wrote: > XO began advertising way too many prefixes, a few hours ago. ?Most > likely tripping most of their peers max-prefix limits. Filters are your > friends. > ~mark > > -----Original Message----- > From: William Byrd [mailto:will at collier-byrd.net] > Sent: Thursday, September 16, 2010 10:09 AM > To: Patrick W. Gilmore > Cc: NANOG list > Subject: Re: XO Routing > > XO Engineers are telling us that they are aware of packet loss across > their network and are looking into it. We're experiencing slow/degraded > connectivity out of St. Louis and Nashville but Atlanta and Dallas are > problem free. > > William Collier-Byrd > will at collier-byrd.net > > > On Thu, Sep 16, 2010 at 12:04 PM, Patrick W. Gilmore > wrote: > >> This should probably be on outages@, but XO is definitely having >> problems to places like speedtest.com & RCN from Boston. >> >> -- >> TTFN, >> patrick >> >> >> On Sep 16, 2010, at 11:59 AM, Charles Mills wrote: >> >> > The internet health report is showing high latency to most of their >> peers. >> > >> > Chuck. >> > >> > On Sep 16, 2010 11:57 AM, "Stefan Molnar" wrote: >> >> >> >> Anyone know the impact on the XO Routing/Peering that is happening >> >> right now? We have had spotty connectivity for the last hour. >> >> >> >> Stefan >> > > > --- > > > The content contained in this electronic message is not intended to constitute > formation of a contract binding tw telecom. ?tw telecom will be contractually > bound only upon execution, by an authorized officer, of a contract including > agreed terms and conditions or by express application of its tariffs. ?This message > is intended only for the use of the individual or entity to which it is addressed. If > the reader of this message is not the intended recipient, or the employee or agent > responsible for delivering the message to the intended recipient, you are hereby > notified that any dissemination, distribution or copying of this message is strictly > prohibited. If you have received this communication in error, please notify us > immediately by replying to the sender of this E-Mail or by telephone. > > -- Jeffrey Lyon, Leadership Team jeffrey.lyon at blacklotus.net | http://www.blacklotus.net Black Lotus Communications - AS32421 First and Leading in DDoS Protection Solutions From sil at infiltrated.net Thu Sep 16 16:35:03 2010 From: sil at infiltrated.net (J. Oquendo) Date: Thu, 16 Sep 2010 12:35:03 -0400 Subject: Chase.com outage In-Reply-To: <20100916121335.C19215@egps.ziskind.us> References: <20100916121335.C19215@egps.ziskind.us> Message-ID: <4C924737.6030904@infiltrated.net> N. Yaakov Ziskind wrote: > Does anyone have any information (beyond the wimpy statement that > "technical issues" were to blame) on the Chase outage? > > It seems that when a multibillion dollar company's major web site is > down for more than a day, there must be juicy "technical issues" that > beg to be told. So, can anyone dish? :-) > > Cloud be ... The cloud... Mushroomcloud http://www.infiltrated.net/mushroomcloud/ It's (proven to be) theoretically possible ;) -- =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ J. Oquendo SGFA, SGFE, C|EH, CNDA, CHFI, OSCP, CPT "It takes 20 years to build a reputation and five minutes to ruin it. If you think about that, you'll do things differently." - Warren Buffett 227C 5D35 7DCB 0893 95AA 4771 1DCE 1FD1 5CCD 6B5E http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x5CCD6B5E From rekoil at semihuman.com Thu Sep 16 16:47:45 2010 From: rekoil at semihuman.com (Chris Woodfield) Date: Thu, 16 Sep 2010 09:47:45 -0700 Subject: XO Routing In-Reply-To: References: <20100916085237.V46129@clockwork> <97F4705B-0169-4552-B69D-4603A6A22E8B@ianai.net> Message-ID: The unconfirmed chatter I'm hearing is that they were leaking peering routes to other peers. Can anyone check and confirm this? Renesys? -C On Sep 16, 2010, at 9:09 12AM, William Byrd wrote: > XO Engineers are telling us that they are aware of packet loss across their > network and are looking into it. We're experiencing slow/degraded > connectivity out of St. Louis and Nashville but Atlanta and Dallas are > problem free. > > William Collier-Byrd > will at collier-byrd.net > > > On Thu, Sep 16, 2010 at 12:04 PM, Patrick W. Gilmore wrote: > >> This should probably be on outages@, but XO is definitely having problems >> to places like speedtest.com & RCN from Boston. >> >> -- >> TTFN, >> patrick >> >> >> On Sep 16, 2010, at 11:59 AM, Charles Mills wrote: >> >>> The internet health report is showing high latency to most of their >> peers. >>> >>> Chuck. >>> >>> On Sep 16, 2010 11:57 AM, "Stefan Molnar" wrote: >>>> >>>> Anyone know the impact on the XO Routing/Peering that is happening right >>>> now? We have had spotty connectivity for the last hour. >>>> >>>> Stefan >> From stefan at csudsu.com Thu Sep 16 16:48:52 2010 From: stefan at csudsu.com (Stefan Molnar) Date: Thu, 16 Sep 2010 09:48:52 -0700 (PDT) Subject: XO Routing In-Reply-To: References: <20100916085237.V46129@clockwork> <97F4705B-0169-4552-B69D-4603A6A22E8B@ianai.net> Message-ID: <20100916094837.O46129@clockwork> My sales director said it was their peering. On Thu, 16 Sep 2010, Chris Woodfield wrote: > The unconfirmed chatter I'm hearing is that they were leaking peering routes to other peers. Can anyone check and confirm this? Renesys? > > -C > > On Sep 16, 2010, at 9:09 12AM, William Byrd wrote: > >> XO Engineers are telling us that they are aware of packet loss across their >> network and are looking into it. We're experiencing slow/degraded >> connectivity out of St. Louis and Nashville but Atlanta and Dallas are >> problem free. >> >> William Collier-Byrd >> will at collier-byrd.net >> >> >> On Thu, Sep 16, 2010 at 12:04 PM, Patrick W. Gilmore wrote: >> >>> This should probably be on outages@, but XO is definitely having problems >>> to places like speedtest.com & RCN from Boston. >>> >>> -- >>> TTFN, >>> patrick >>> >>> >>> On Sep 16, 2010, at 11:59 AM, Charles Mills wrote: >>> >>>> The internet health report is showing high latency to most of their >>> peers. >>>> >>>> Chuck. >>>> >>>> On Sep 16, 2010 11:57 AM, "Stefan Molnar" wrote: >>>>> >>>>> Anyone know the impact on the XO Routing/Peering that is happening right >>>>> now? We have had spotty connectivity for the last hour. >>>>> >>>>> Stefan >>> > > > > From sethm at rollernet.us Thu Sep 16 16:53:10 2010 From: sethm at rollernet.us (Seth Mattinen) Date: Thu, 16 Sep 2010 09:53:10 -0700 Subject: XO Routing In-Reply-To: References: <20100916085237.V46129@clockwork> <97F4705B-0169-4552-B69D-4603A6A22E8B@ianai.net> Message-ID: <4C924B76.7040908@rollernet.us> On 9/16/10 9:35 AM, Jeffrey Lyon wrote: > Hopefully they don't treat this the same way they treat their billing, > otherwise you all will be degraded for months or even years. It is > absolutely amazing that this company is still in business. > The "big guys" will always remain in business, or be absorbed into another equal or larger entity to form an even bigger one, regardless of their practices. (A fringe exception would be AT&T's court ordered breakup.) The larger they get the much more spectacular the faults tend to be. Whereas with smaller providers like myself, how I treat my customers factors in as a major aspect to whether or not they stick around. I can't compete strictly on price with the big guys, but I do absorb their BS and shield my customers from it as much as possible. If I treated my customers like the big guys do, I wouldn't have any. ~Seth From virendra.rode at gmail.com Thu Sep 16 16:46:39 2010 From: virendra.rode at gmail.com (virendra rode) Date: Thu, 16 Sep 2010 09:46:39 -0700 Subject: Chase.com outage In-Reply-To: <20100916121335.C19215@egps.ziskind.us> References: <20100916121335.C19215@egps.ziskind.us> Message-ID: <4C9249EF.4030507@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 09/16/2010 09:13 AM, N. Yaakov Ziskind wrote: > Does anyone have any information (beyond the wimpy statement that > "technical issues" were to blame) on the Chase outage? - ---------------- - From my understanding their back-end database suffered from some sort of corruption that caused login to fail. regards, /virendra > > It seems that when a multibillion dollar company's major web site is > down for more than a day, there must be juicy "technical issues" that > beg to be told. So, can anyone dish? :-) > > -- > _________________________________________ > Nachman Yaakov Ziskind, FSPA, LLM awacs at ziskind.us > Attorney and Counselor-at-Law http://ziskind.us > Economic Group Pension Services http://egps.com > Actuaries and Employee Benefit Consultants > > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkySSe8ACgkQpbZvCIJx1beISgCdHerBst0K7Ktv8LzYvNtXmPY2 WHgAnA01VHy75DvnRcyG1JF5WyCAafQB =KQ6Y -----END PGP SIGNATURE----- From awacs at ziskind.us Thu Sep 16 16:54:50 2010 From: awacs at ziskind.us (N. Yaakov Ziskind) Date: Thu, 16 Sep 2010 12:54:50 -0400 Subject: Chase.com outage In-Reply-To: References: <20100916121335.C19215@egps.ziskind.us> Message-ID: <20100916125450.D19215@egps.ziskind.us> Zaid Ali wrote (on Thu, Sep 16, 2010 at 09:27:40AM -0700): > Isn't that reserved for beer sessions at NANOG? Bummer. I heard they don't lawyers into the beer sessions. :-) > On 9/16/10 9:13 AM, "N. Yaakov Ziskind" wrote: > > > Does anyone have any information (beyond the wimpy statement that > > "technical issues" were to blame) on the Chase outage? > > > > It seems that when a multibillion dollar company's major web site is > > down for more than a day, there must be juicy "technical issues" that > > beg to be told. So, can anyone dish? :-) The most intelligent thing I've found so far is this, bankingblog.celent.com: "Actually, they did have maintenance scheduled for Sunday Morning. Sunday afternoon and night site worked and crashed Monday evening before 4 pm or so, also noteworthy is that the site crashed last month as well, but made no news splash as the outage was mostly in the weekend. It did captured by a few websites that collect Chase gripes.. "So, it is unlikely that this is an attack. if it is one, it was a prolonged attack. It is more likely that they crashed and corrupted databases, in which case, they are restoring from tape, and will likely have to validate many things. That sort of suggests that we might see it come back up sometime tomorrow afternoon, or later if the restore fails and they have to revert to a different backup." -- _________________________________________ Nachman Yaakov Ziskind, FSPA, LLM awacs at ziskind.us Attorney and Counselor-at-Law http://ziskind.us Economic Group Pension Services http://egps.com Actuaries and Employee Benefit Consultants From patrick at ianai.net Thu Sep 16 16:54:59 2010 From: patrick at ianai.net (Patrick W. Gilmore) Date: Thu, 16 Sep 2010 12:54:59 -0400 Subject: XO Routing In-Reply-To: <20100916094837.O46129@clockwork> References: <20100916085237.V46129@clockwork> <97F4705B-0169-4552-B69D-4603A6A22E8B@ianai.net> <20100916094837.O46129@clockwork> Message-ID: <3270DA2D-B183-41CF-8636-725670528CAD@ianai.net> On Sep 16, 2010, at 12:48 PM, Stefan Molnar wrote: > My sales director said it was their peering. First problem with a statement talking about technical problems: "My sales director said...." Second problem: "Peering" does not cause internal routing loops. Er, should not. Third problem: "Was". -- TTFN, patrick > On Thu, 16 Sep 2010, Chris Woodfield wrote: > >> The unconfirmed chatter I'm hearing is that they were leaking peering routes to other peers. Can anyone check and confirm this? Renesys? >> >> -C >> >> On Sep 16, 2010, at 9:09 12AM, William Byrd wrote: >> >>> XO Engineers are telling us that they are aware of packet loss across their >>> network and are looking into it. We're experiencing slow/degraded >>> connectivity out of St. Louis and Nashville but Atlanta and Dallas are >>> problem free. >>> >>> William Collier-Byrd >>> will at collier-byrd.net >>> >>> >>> On Thu, Sep 16, 2010 at 12:04 PM, Patrick W. Gilmore wrote: >>> >>>> This should probably be on outages@, but XO is definitely having problems >>>> to places like speedtest.com & RCN from Boston. >>>> >>>> -- >>>> TTFN, >>>> patrick >>>> >>>> >>>> On Sep 16, 2010, at 11:59 AM, Charles Mills wrote: >>>> >>>>> The internet health report is showing high latency to most of their >>>> peers. >>>>> >>>>> Chuck. >>>>> >>>>> On Sep 16, 2010 11:57 AM, "Stefan Molnar" wrote: >>>>>> >>>>>> Anyone know the impact on the XO Routing/Peering that is happening right >>>>>> now? We have had spotty connectivity for the last hour. >>>>>> >>>>>> Stefan >>>> >> >> >> >> > From gbonser at seven.com Thu Sep 16 17:57:07 2010 From: gbonser at seven.com (George Bonser) Date: Thu, 16 Sep 2010 10:57:07 -0700 Subject: Did Internet Founders Actually Anticipate Paid, Prioritized Traffic? In-Reply-To: <6F3DB878-64EF-4590-952C-0D5C81733EA4@gizmopartners.com> References: <5A6D953473350C4B9995546AFE9939EE0A52AD76@RWC-EX1.corp.seven.com> <6F3DB878-64EF-4590-952C-0D5C81733EA4@gizmopartners.com> Message-ID: <5A6D953473350C4B9995546AFE9939EE0A52AD81@RWC-EX1.corp.seven.com> > I DO have a problem with a content provider paying to get priority > access on the last mile. I have no particular interest in any of the > content that Yahoo provides, but I do have an interest in downloading > my Linux updates via torrents. Should I have to go back and bid > against Yahoo just so I can get my packets in a timely fashion? > > > I understand that the last mile is going to be a congestion point, but > the idea of allowing a bidding war for priority access for that > capacity seems to be a path to madness. > > --Chris Hi Chris, Since prioritization would work ONLY when the link us saturated (congested), without it, nothing is going to work well, not your torrents, not your email, not your browsing. By prioritizing the traffic, the torrents might back off but they would still continue to flow, they wouldn't be completely blocked, they would just slow down. QoS can be a good thing for allowing your VIOP to work while someone else in the home is watching a streaming movie or something. Without it, everything breaks once the circuit is congested. From rekoil at semihuman.com Thu Sep 16 18:35:51 2010 From: rekoil at semihuman.com (Chris Woodfield) Date: Thu, 16 Sep 2010 11:35:51 -0700 Subject: Did Internet Founders Actually Anticipate Paid, Prioritized Traffic? In-Reply-To: <5A6D953473350C4B9995546AFE9939EE0A52AD81@RWC-EX1.corp.seven.com> References: <5A6D953473350C4B9995546AFE9939EE0A52AD76@RWC-EX1.corp.seven.com> <6F3DB878-64EF-4590-952C-0D5C81733EA4@gizmopartners.com> <5A6D953473350C4B9995546AFE9939EE0A52AD81@RWC-EX1.corp.seven.com> Message-ID: <9CBEC49C-9106-4C7C-AC92-8C525AD9AEBE@semihuman.com> On Sep 16, 2010, at 10:57 07AM, George Bonser wrote: >> > > Hi Chris, > > Since prioritization would work ONLY when the link us saturated > (congested), without it, nothing is going to work well, not your > torrents, not your email, not your browsing. By prioritizing the > traffic, the torrents might back off but they would still continue to > flow, they wouldn't be completely blocked, they would just slow down. > QoS can be a good thing for allowing your VIOP to work while someone > else in the home is watching a streaming movie or something. Without > it, everything breaks once the circuit is congested. > > Your statement misses the point, which is, *who* gets to decide what traffic is prioritized? And will that prioritization be determined by who is paying my carrier for that prioritization, potentially against my own preferences? For some damn reason, I might *prefer* that my torrent traffic get prioritized over, say, email. Or, I might not appreciate the eventuality that a stream I'm watching on hulu.com stutters because my neighbor's watching a movie on Netflix and it just happens that Netflix has paid my carrier for prioritized traffic. The other point, as mentioned previously, is that paid prioritization doesn't mean a thing unless there's congestion to be managed. It's not a far stretch to see exec-level types seeing the potential financial benefits to, well, ensuring that such congestion does show up in their network in order to create the practical incentives for paid prioritization. -C From gbonser at seven.com Thu Sep 16 18:44:27 2010 From: gbonser at seven.com (George Bonser) Date: Thu, 16 Sep 2010 11:44:27 -0700 Subject: Did Internet Founders Actually Anticipate Paid, Prioritized Traffic? In-Reply-To: <9CBEC49C-9106-4C7C-AC92-8C525AD9AEBE@semihuman.com> References: <5A6D953473350C4B9995546AFE9939EE0A52AD76@RWC-EX1.corp.seven.com> <6F3DB878-64EF-4590-952C-0D5C81733EA4@gizmopartners.com> <5A6D953473350C4B9995546AFE9939EE0A52AD81@RWC-EX1.corp.seven.com> <9CBEC49C-9106-4C7C-AC92-8C525AD9AEBE@semihuman.com> Message-ID: <5A6D953473350C4B9995546AFE9939EE0A52AD92@RWC-EX1.corp.seven.com> > Your statement misses the point, which is, *who* gets to decide what > traffic is prioritized? And will that prioritization be determined by > who is paying my carrier for that prioritization, potentially against > my own preferences? I would say that with standard "run of the mill" consumer service, the provider decides. If you want something custom, that would be reasonable to offer, but you should be expected to pay a bit more for that in order to maintain the non-standard configuration. Maintaining a different configuration for each user would be more expensive for the provider than a "cookie-cutter" solution that makes the internet a better experience for say 85% or more of the people out there. G From bill at herrin.us Thu Sep 16 19:02:40 2010 From: bill at herrin.us (William Herrin) Date: Thu, 16 Sep 2010 15:02:40 -0400 Subject: Did Internet Founders Actually Anticipate Paid, Prioritized Traffic? In-Reply-To: <5A6D953473350C4B9995546AFE9939EE0A52AD92@RWC-EX1.corp.seven.com> References: <5A6D953473350C4B9995546AFE9939EE0A52AD76@RWC-EX1.corp.seven.com> <6F3DB878-64EF-4590-952C-0D5C81733EA4@gizmopartners.com> <5A6D953473350C4B9995546AFE9939EE0A52AD81@RWC-EX1.corp.seven.com> <9CBEC49C-9106-4C7C-AC92-8C525AD9AEBE@semihuman.com> <5A6D953473350C4B9995546AFE9939EE0A52AD92@RWC-EX1.corp.seven.com> Message-ID: On Thu, Sep 16, 2010 at 2:44 PM, George Bonser wrote: >> Your statement misses the point, which is, *who* gets to decide what >> traffic is prioritized? And will that prioritization be determined by >> who is paying my carrier for that prioritization, potentially against >> my own preferences? > > I would say that with standard "run of the mill" consumer service, the > provider decides. George, Will the provider unbundle the components so that it's feasible for a niche vendor to sell me custom connection services? No? Then the provider doesn't get to decide. It's about control. As the customer, the guy with the green, I should have it. A combination of decisions on the provider's part which strips me of control is unacceptable. You want prioritization? Give me unbundling. You don't want to unbundle? Don't mess with my packets. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From owen at delong.com Thu Sep 16 19:10:32 2010 From: owen at delong.com (Owen DeLong) Date: Thu, 16 Sep 2010 12:10:32 -0700 Subject: Did Internet Founders Actually Anticipate Paid, Prioritized Traffic? In-Reply-To: <5A6D953473350C4B9995546AFE9939EE0A52AD81@RWC-EX1.corp.seven.com> References: <5A6D953473350C4B9995546AFE9939EE0A52AD76@RWC-EX1.corp.seven.com> <6F3DB878-64EF-4590-952C-0D5C81733EA4@gizmopartners.com> <5A6D953473350C4B9995546AFE9939EE0A52AD81@RWC-EX1.corp.seven.com> Message-ID: On Sep 16, 2010, at 10:57 AM, George Bonser wrote: >> I DO have a problem with a content provider paying to get priority >> access on the last mile. I have no particular interest in any of the >> content that Yahoo provides, but I do have an interest in downloading >> my Linux updates via torrents. Should I have to go back and bid >> against Yahoo just so I can get my packets in a timely fashion? >> >> >> I understand that the last mile is going to be a congestion point, but >> the idea of allowing a bidding war for priority access for that >> capacity seems to be a path to madness. >> >> --Chris > > Hi Chris, > > Since prioritization would work ONLY when the link us saturated > (congested), without it, nothing is going to work well, not your > torrents, not your email, not your browsing. By prioritizing the > traffic, the torrents might back off but they would still continue to > flow, they wouldn't be completely blocked, they would just slow down. > QoS can be a good thing for allowing your VIOP to work while someone > else in the home is watching a streaming movie or something. Without > it, everything breaks once the circuit is congested. > It depends. If you're talking about prioritization of the end link, then, that's one thing... If the ISP wants to implement prioritization there based on the END USER's preferences, that's a nice value-add service. If you're talking about the aggregation point of several customer's links, then, prioritizing customer A's Yahoo traffic because Yahoo paid over customer B's torrent traffic when customer A and B have paid the same for their connection is not so good, IMHO. Owen From owen at delong.com Thu Sep 16 19:12:30 2010 From: owen at delong.com (Owen DeLong) Date: Thu, 16 Sep 2010 12:12:30 -0700 Subject: Did Internet Founders Actually Anticipate Paid, Prioritized Traffic? In-Reply-To: <9CBEC49C-9106-4C7C-AC92-8C525AD9AEBE@semihuman.com> References: <5A6D953473350C4B9995546AFE9939EE0A52AD76@RWC-EX1.corp.seven.com> <6F3DB878-64EF-4590-952C-0D5C81733EA4@gizmopartners.com> <5A6D953473350C4B9995546AFE9939EE0A52AD81@RWC-EX1.corp.seven.com> <9CBEC49C-9106-4C7C-AC92-8C525AD9AEBE@semihuman.com> Message-ID: On Sep 16, 2010, at 11:35 AM, Chris Woodfield wrote: > On Sep 16, 2010, at 10:57 07AM, George Bonser wrote: >>> >> >> Hi Chris, >> >> Since prioritization would work ONLY when the link us saturated >> (congested), without it, nothing is going to work well, not your >> torrents, not your email, not your browsing. By prioritizing the >> traffic, the torrents might back off but they would still continue to >> flow, they wouldn't be completely blocked, they would just slow down. >> QoS can be a good thing for allowing your VIOP to work while someone >> else in the home is watching a streaming movie or something. Without >> it, everything breaks once the circuit is congested. >> >> > > Your statement misses the point, which is, *who* gets to decide what traffic is prioritized? And will that prioritization be determined by who is paying my carrier for that prioritization, potentially against my own preferences? For some damn reason, I might *prefer* that my torrent traffic get prioritized over, say, email. Or, I might not appreciate the eventuality that a stream I'm watching on hulu.com stutters because my neighbor's watching a movie on Netflix and it just happens that Netflix has paid my carrier for prioritized traffic. > > The other point, as mentioned previously, is that paid prioritization doesn't mean a thing unless there's congestion to be managed. It's not a far stretch to see exec-level types seeing the potential financial benefits to, well, ensuring that such congestion does show up in their network in order to create the practical incentives for paid prioritization. > > -C Yep... If you don't believe that will happen, I refer you to Enron vs. California ISO and the lovely changes to the electricity market in California around that time. Owen From owen at delong.com Thu Sep 16 19:16:44 2010 From: owen at delong.com (Owen DeLong) Date: Thu, 16 Sep 2010 12:16:44 -0700 Subject: Did Internet Founders Actually Anticipate Paid, Prioritized Traffic? In-Reply-To: <5A6D953473350C4B9995546AFE9939EE0A52AD92@RWC-EX1.corp.seven.com> References: <5A6D953473350C4B9995546AFE9939EE0A52AD76@RWC-EX1.corp.seven.com> <6F3DB878-64EF-4590-952C-0D5C81733EA4@gizmopartners.com> <5A6D953473350C4B9995546AFE9939EE0A52AD81@RWC-EX1.corp.seven.com> <9CBEC49C-9106-4C7C-AC92-8C525AD9AEBE@semihuman.com> <5A6D953473350C4B9995546AFE9939EE0A52AD92@RWC-EX1.corp.seven.com> Message-ID: <1089A30C-661E-47F6-BF51-90937524374F@delong.com> On Sep 16, 2010, at 11:44 AM, George Bonser wrote: >> Your statement misses the point, which is, *who* gets to decide what >> traffic is prioritized? And will that prioritization be determined by >> who is paying my carrier for that prioritization, potentially against >> my own preferences? > > I would say that with standard "run of the mill" consumer service, the > provider decides. If you want something custom, that would be > reasonable to offer, but you should be expected to pay a bit more for > that in order to maintain the non-standard configuration. Maintaining a > different configuration for each user would be more expensive for the > provider than a "cookie-cutter" solution that makes the internet a > better experience for say 85% or more of the people out there. > > G > The point is that if the provider is deciding based on some third party paying them and thus my neighbors are getting more bandwidth than I am, not because they're paying more, but, because they're choosing to use the services that bribed my provider, then that's not a good thing. Owen From sthaug at nethelp.no Thu Sep 16 19:28:21 2010 From: sthaug at nethelp.no (sthaug at nethelp.no) Date: Thu, 16 Sep 2010 21:28:21 +0200 (CEST) Subject: Did Internet Founders Actually Anticipate Paid, Prioritized Traffic? In-Reply-To: References: <9CBEC49C-9106-4C7C-AC92-8C525AD9AEBE@semihuman.com> <5A6D953473350C4B9995546AFE9939EE0A52AD92@RWC-EX1.corp.seven.com> Message-ID: <20100916.212821.74712800.sthaug@nethelp.no> > Will the provider unbundle the components so that it's feasible for a > niche vendor to sell me custom connection services? > > No? > > Then the provider doesn't get to decide. > > It's about control. As the customer, the guy with the green, I should > have it. A combination of decisions on the provider's part which > strips me of control is unacceptable. > > You want prioritization? Give me unbundling. You don't want to > unbundle? Don't mess with my packets. If you want control: Don't buy the cheapest commodity product. Steinar Haug, Nethelp consulting, sthaug at nethelp.no From bjohnson at drtel.com Thu Sep 16 19:38:12 2010 From: bjohnson at drtel.com (Brian Johnson) Date: Thu, 16 Sep 2010 14:38:12 -0500 Subject: Did Internet Founders Actually Anticipate Paid, Prioritized Traffic? In-Reply-To: <1089A30C-661E-47F6-BF51-90937524374F@delong.com> References: <5A6D953473350C4B9995546AFE9939EE0A52AD76@RWC-EX1.corp.seven.com><6F3DB878-64EF-4590-952C-0D5C81733EA4@gizmopartners.com><5A6D953473350C4B9995546AFE9939EE0A52AD81@RWC-EX1.corp.seven.com><9CBEC49C-9106-4C7C-AC92-8C525AD9AEBE@semihuman.com><5A6D953473350C4B9995546AFE9939EE0A52AD92@RWC-EX1.corp.seven.com> <1089A30C-661E-47F6-BF51-90937524374F@delong.com> Message-ID: <29A54911243620478FF59F00EBB12F47020BC95D@ex01.drtel.lan> >-----Original Message----- >From: Owen DeLong [mailto:owen at delong.com] >Sent: Thursday, September 16, 2010 2:17 PM >To: George Bonser >Cc: NANOG list >Subject: Re: Did Internet Founders Actually Anticipate Paid,Prioritized Traffic? > > >The point is that if the provider is deciding based on some third party >paying them and thus my neighbors are getting more bandwidth >than I am, not because they're paying more, but, because they're >choosing to use the services that bribed my provider, then that's >not a good thing. This actually is a case for net neutrality. I worry about things like ACLS to prevent SPAM or abuse/security will get tarred with the same feathers. - Brian CONFIDENTIALITY NOTICE: This email message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, copying, use, disclosure, or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. Thank you. From bill at herrin.us Thu Sep 16 20:37:33 2010 From: bill at herrin.us (William Herrin) Date: Thu, 16 Sep 2010 16:37:33 -0400 Subject: Did Internet Founders Actually Anticipate Paid, Prioritized Traffic? In-Reply-To: <20100916.212821.74712800.sthaug@nethelp.no> References: <9CBEC49C-9106-4C7C-AC92-8C525AD9AEBE@semihuman.com> <5A6D953473350C4B9995546AFE9939EE0A52AD92@RWC-EX1.corp.seven.com> <20100916.212821.74712800.sthaug@nethelp.no> Message-ID: On Thu, Sep 16, 2010 at 3:28 PM, wrote: >> Will the provider unbundle the components so that it's feasible for a >> niche vendor to sell me custom connection services? >> >> No? >> >> Then the provider doesn't get to decide. >> >> It's about control. As the customer, the guy with the green, I should >> have it. A combination of decisions on the provider's part which >> strips me of control is unacceptable. >> >> You want prioritization? Give me unbundling. You don't want to >> unbundle? Don't mess with my packets. > > If you want control: Don't buy the cheapest commodity product. When you sell 15 megs as a commodity for $50 and 1.5 megs non-commidity for $700, don't pretend that I have that I have a choice. But then you're writing from Norway, so perhaps you're not up to speed on the situation in NANOG territory. 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 Thu Sep 16 20:52:33 2010 From: jbates at brightok.net (Jack Bates) Date: Thu, 16 Sep 2010 15:52:33 -0500 Subject: Did Internet Founders Actually Anticipate Paid, Prioritized Traffic? In-Reply-To: <20100916.212821.74712800.sthaug@nethelp.no> References: <9CBEC49C-9106-4C7C-AC92-8C525AD9AEBE@semihuman.com> <5A6D953473350C4B9995546AFE9939EE0A52AD92@RWC-EX1.corp.seven.com> <20100916.212821.74712800.sthaug@nethelp.no> Message-ID: <4C928391.4050701@brightok.net> On 9/16/2010 2:28 PM, sthaug at nethelp.no wrote: > > If you want control: Don't buy the cheapest commodity product. > +1 Next we'll be arguing that akamai nodes are evil because they can have better service levels than other sites. The p2p guys are also getting special treatment, as they can grab files faster than the direct download guy. Oh, and provider met google's bandwidth requirements for peering, so their peering with google gives better service to google than yahoo/hotmail; which was unfair to the provider who didn't meet the requirements and has to go the long way around. :P Provider may also have met ll's requirements, so peering accepted there, and here come the better netflix streams. Of course, anywhere a provider has a direct peer, they'll want to prioritize that traffic over any other. True net-neutrality means no provider can have a better service than another. This totally screws with private peering and the variety of requirements, as well as special services (such as akamai nodes). Many of these cases aren't about saturation, but better connectivity between content provider and ISP. Adding money or QOS to the equation is just icing on the cake. Jack From deric.kwok2000 at gmail.com Thu Sep 16 21:47:12 2010 From: deric.kwok2000 at gmail.com (Deric Kwok) Date: Thu, 16 Sep 2010 17:47:12 -0400 Subject: fibr question - Please help Message-ID: Hi all I don't have two fibr card so that I can't test it If i have one setting as mode "NOT negot, one is using AU To mode Can they ping each other? Thank you for your help From streiner at cluebyfour.org Fri Sep 17 00:45:41 2010 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Thu, 16 Sep 2010 20:45:41 -0400 (EDT) Subject: fibr question - Please help In-Reply-To: References: Message-ID: On Thu, 16 Sep 2010, Deric Kwok wrote: > I don't have two fibr card so that I can't test it > > If i have one setting as mode "NOT negot, one is using AU To mode What kinds of cards are you talking about? Gigabit? 10G? 100baseFX? I'm also assuming since you mentioned negotiation that you're talking about Ethernet as the transport. Are these NICs in a computer, interfaces on a router/switch, or some combination of the two? Also, what do you mean by negotiation? This could be speed and duplex negotiation, but depending on the kinds of equipment you're talking about, negotiation could mean a few different things. Assuming you're talking about speed and duplex, having one side locked at a specific speed and/or duplex, and letting the other side autonegotiate can be dangerous in that the two devices can end up trying to use different settings. More than likely, this would result in poor performance of the link due to collisions and retransmissions. Try setting both sides to autonegotiate (if possible) first. > Can they ping each other? The cards themselves are just a means to connect two devices and pass (again, I'm making the assumption) Ethernet frames. Pinging is a function of things running further up the network stack. jms From nathan at atlasnetworks.us Fri Sep 17 09:52:13 2010 From: nathan at atlasnetworks.us (Nathan Eisenberg) Date: Fri, 17 Sep 2010 09:52:13 +0000 Subject: Did Internet Founders Actually Anticipate Paid, Prioritized Traffic? In-Reply-To: <4C928391.4050701@brightok.net> References: <9CBEC49C-9106-4C7C-AC92-8C525AD9AEBE@semihuman.com> <5A6D953473350C4B9995546AFE9939EE0A52AD92@RWC-EX1.corp.seven.com> <20100916.212821.74712800.sthaug@nethelp.no> <4C928391.4050701@brightok.net> Message-ID: <8C26A4FDAE599041A13EB499117D3C28405E0809@ex-mb-2.corp.atlasnetworks.us> > True net-neutrality means no provider can have a better service than another. This statement is not true - or at least, I am not convinced of its truth. True net neutrality means no provider will artificially de-neutralize their service by introducing destination based priority on congested links. > This totally screws with private peering and the variety of requirements, as well > as special services (such as akamai nodes). Many of these cases aren't about > saturation, but better connectivity between content provider and ISP. Adding > money or QOS to the equation is just icing on the cake. >From a false assumption follows false conclusions. Why do you feel it's true that net-neutrality treads on private (or even public) peering, or content delivery platforms? In my understanding, they are two separate topics: Net (non)-neutrality is literally about prioritizing different packets on the *same* wire based on whether the destination or source is from an ACL of IPs. IE this link is congested, Netflix sends me a check every month, send their packets before the ones from Hulu and Youtube. The act of sending traffic down a different link directly to a peers' network does not affect the neutrality of either party one iota - in fact, it works to solve the congested link problem (Look! Adding capacity fixed it!). The ethics of path distances, peering relationships and vector routing, while interesting, are out of scope in a discussion of neutrality. An argument which makes this a larger issue encompassing peering and vector routing is, in my opinion, either a straw man or a red herring (depending on how well it's presented) attempt to generate a second technoethical issue in order to defeat the first one. Nathan From jbates at brightok.net Fri Sep 17 13:48:02 2010 From: jbates at brightok.net (Jack Bates) Date: Fri, 17 Sep 2010 08:48:02 -0500 Subject: Did Internet Founders Actually Anticipate Paid, Prioritized Traffic? In-Reply-To: <8C26A4FDAE599041A13EB499117D3C28405E0809@ex-mb-2.corp.atlasnetworks.us> References: <9CBEC49C-9106-4C7C-AC92-8C525AD9AEBE@semihuman.com> <5A6D953473350C4B9995546AFE9939EE0A52AD92@RWC-EX1.corp.seven.com> <20100916.212821.74712800.sthaug@nethelp.no> <4C928391.4050701@brightok.net> <8C26A4FDAE599041A13EB499117D3C28405E0809@ex-mb-2.corp.atlasnetworks.us> Message-ID: <4C937192.2090603@brightok.net> On 9/17/2010 4:52 AM, Nathan Eisenberg wrote: >> True net-neutrality means no provider can have a better service than another. > > This statement is not true - or at least, I am not convinced of its truth. True net neutrality means no provider will artificially de-neutralize their service by introducing destination based priority on congested links. This is what you want it to mean. If I create a private peer to google, I have de-neutralized their service(destination based priority, even though in both cases, it's the source of the packets we care about) by allowing dedicated bandwidth and lower latency to their cloud. Also, let's not forget that the design of many p2p programs were specifically designed to ignore and bypass congestion controls... ie, screw other apps, I will take every bit of bandwidth I can get. This type of behavior causes p2p to have higher priority than other apps in a network that has no traffic prioritized. While I agree that traffic type prioritization would be preferred over destination based priorities, it often isn't feasible with hardware. Understanding the amount of traffic between your customers and a content provider helps you decide which content providers might be prioritized to give an overall service increase to your customer base. The fact that a content provider would even pay an ISP, is a high indicator that the content provider is sending a high load of traffic to the ISP, and bandwidth constraints are an issue with the service. Video and voice, in particular, should always try and have precedence over p2p, as they completely break and become unusable, where p2p will just be forced to move slower. >> From a false assumption follows false conclusions. Not really. It's not a neutral world. Private peering is by no means neutral. The provider that does enough traffic with google to warrant a private peering will have better service levels than the smaller guy who has to take the public paths. You view net neutrality as customers within an ISP, while I view it as a provider within a network of providers. The levels of service and pricing I can maintain as a rural ISP can't be compared to the metropolitan ISPs. A west coast ISP won't have the same level of service as an east coast ISP when dealing with geographical based content. We could take it to the international scale, where countries don't have equal service levels to content. > > Why do you feel it's true that net-neutrality treads on private (or even public) peering, or content delivery platforms? In my understanding, they are two separate topics: Net (non)-neutrality is literally about prioritizing different packets on the *same* wire based on whether the destination or source is from an ACL of IPs. IE this link is congested, Netflix sends me a check every month, send their packets before the ones from Hulu and Youtube. The act of sending traffic down a different link directly to a peers' network does not affect the neutrality of either party one iota - in fact, it works to solve the congested link problem (Look! Adding capacity fixed it!). > So you are saying, it's perfectly okay to improve one service over another by adding bandwidth directly to that service, but it's unacceptable to prioritize it's traffic on congested links (which effectively adds more bandwidth for that service). It's the same thing, using two different methods. If we consider all bandwidth available between the customer and content (and consider latency as well, as it has an effect on the traffic, especially during congestion), a private peer dedicates bandwidth to content the same as prioritizing it's traffic. If anything, the private peer provides even more bandwidth. ISP has 2xDS3 available for bandwidth total. Netflix traffic is 20mb/s. Bandwidth is considered saturated. 1) 45mb public + 45 mb private = 90mb w/ 45mb prioritized traffic due to private peering 2) 90mb public = 90mb w/ 20mb prioritized traffic via destination prioritization (actual usage) It appears that the second is a better deal. The fact that netflix got better service levels was an ISP decision. By using prioritization on shared pipes, it actually gave customers more bandwidth than using separate pipes. > The ethics of path distances, peering relationships and vector routing, while interesting, are out of scope in a discussion of neutrality. An argument which makes this a larger issue encompassing peering and vector routing is, in my opinion, either a straw man or a red herring (depending on how well it's presented) attempt to generate a second technoethical issue in order to defeat the first one. > It's a matter of viewpoint. It's convenient to talk about net-neutrality when it's scoped, but not when we widen the scope. Customer A gets better service than Customer B because he want to a site that had prioritization. Never mind that while they fight over the saturated link, Customer C beat both of them because he was on a separate segment that wasn't saturated. All 3 paid the same amount of money. C > A > B, yet C doesn't fall into this net-neutrality discussion, and the provider, who wants to keep customers, has more C customers than A, and more A customers than B, so B is the most expendable. My viewpoint is that of an ISP, and as such, I think of net-neutrality at a level above some last mile that's saturated at some other ISP. Jack From jgreco at ns.sol.net Fri Sep 17 14:05:29 2010 From: jgreco at ns.sol.net (Joe Greco) Date: Fri, 17 Sep 2010 09:05:29 -0500 (CDT) Subject: Did Internet Founders Actually Anticipate Paid, In-Reply-To: <5A6D953473350C4B9995546AFE9939EE0A52AD81@RWC-EX1.corp.seven.com> Message-ID: <201009171405.o8HE5TuP062008@aurora.sol.net> > > I DO have a problem with a content provider paying to get priority > > access on the last mile. I have no particular interest in any of the > > content that Yahoo provides, but I do have an interest in downloading > > my Linux updates via torrents. Should I have to go back and bid > > against Yahoo just so I can get my packets in a timely fashion? > > > >=20 > > I understand that the last mile is going to be a congestion point, but > > the idea of allowing a bidding war for priority access for that > > capacity seems to be a path to madness. > >=20 > > --Chris > > Hi Chris, > > Since prioritization would work ONLY when the link us saturated > (congested), without it, nothing is going to work well, not your > torrents, not your email, not your browsing. By prioritizing the > traffic, the torrents might back off but they would still continue to > flow, they wouldn't be completely blocked, they would just slow down. > QoS can be a good thing for allowing your VIOP to work while someone > else in the home is watching a streaming movie or something. Without > it, everything breaks once the circuit is congested. The problem with this theory is that it /sounds/ nice - but the reality is that eventually ISP's will use it to justify deprioritizing one customer's traffic over another, i.e. because your neighbor is doing realtime video and you're doing bittorrent, because their networks are not sufficiently beefy to handle all the traffic their customers may generate at once. If you're spending $60/month for an Internet connection, though, and your neighbor's spending the same, why would your ISP be permitted to determine that your traffic was less valuable? You want prioritization on a customer's link? Fine, allow for that, let the customer decide what should have priority, and I've certainly got zero problem with that. However, the moment we talk "paid" prioritization, we get into all sorts of troubling issues. What happens if YouTube doesn't want to pay for "paid" prioritization of their traffic? Does my ISP decide to route them through Timbuktu in order to punish them, effectively holding me as a hostage until YouTube pays up? ... 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 jgreco at ns.sol.net Fri Sep 17 14:13:48 2010 From: jgreco at ns.sol.net (Joe Greco) Date: Fri, 17 Sep 2010 09:13:48 -0500 (CDT) Subject: Did Internet Founders Actually Anticipate Paid, Prioritized In-Reply-To: <20100916.212821.74712800.sthaug@nethelp.no> Message-ID: <201009171413.o8HEDm59062085@aurora.sol.net> > > Will the provider unbundle the components so that it's feasible for a > > niche vendor to sell me custom connection services? > > > > No? > > > > Then the provider doesn't get to decide. > > > > It's about control. As the customer, the guy with the green, I should > > have it. A combination of decisions on the provider's part which > > strips me of control is unacceptable. > > > > You want prioritization? Give me unbundling. You don't want to > > unbundle? Don't mess with my packets. > > If you want control: Don't buy the cheapest commodity product. You think it won't happen with all the other tiers of commodity products? That seems to imply that you think people who don't want to suffer this sort of thing need to buy something like a T1? Let me just sum it up for you: Get real. Rather than allowing service providers to pick and choose who subscribers can communicate with, we're much more likely to see regulation intervene to enforce reasonable rules. ... 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 Valdis.Kletnieks at vt.edu Fri Sep 17 14:29:43 2010 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Fri, 17 Sep 2010 10:29:43 -0400 Subject: Did Internet Founders Actually Anticipate Paid, Prioritized In-Reply-To: Your message of "Fri, 17 Sep 2010 09:13:48 CDT." <201009171413.o8HEDm59062085@aurora.sol.net> References: <201009171413.o8HEDm59062085@aurora.sol.net> Message-ID: <76757.1284733783@localhost> On Fri, 17 Sep 2010 09:13:48 CDT, Joe Greco said: > Rather than allowing service providers to pick and choose who subscribers > can communicate with, we're much more likely to see regulation intervene > to enforce reasonable rules. We are indeed likely to see regulation intervene to enforce rules. Whether they're reasonable will likely depend on who wins the "My lobbyist can beat up your lobbyist" battle - and of course, the winning lobbyist will declare the rules reasonable, and the losing lobbyist will issue a press release stating how totally unreasonable the rules are. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From jgreco at ns.sol.net Fri Sep 17 14:49:17 2010 From: jgreco at ns.sol.net (Joe Greco) Date: Fri, 17 Sep 2010 09:49:17 -0500 (CDT) Subject: Did Internet Founders Actually Anticipate Paid, In-Reply-To: <4C928391.4050701@brightok.net> Message-ID: <201009171449.o8HEnH6w062387@aurora.sol.net> > On 9/16/2010 2:28 PM, sthaug at nethelp.no wrote: > > > > If you want control: Don't buy the cheapest commodity product. > > +1 -1 > Next we'll be arguing that akamai nodes are evil because they can have > better service levels than other sites. The p2p guys are also getting > special treatment, as they can grab files faster than the direct > download guy. Oh, and provider met google's bandwidth requirements for > peering, so their peering with google gives better service to google > than yahoo/hotmail; which was unfair to the provider who didn't meet the > requirements and has to go the long way around. :P > > Provider may also have met ll's requirements, so peering accepted there, > and here come the better netflix streams. Of course, anywhere a provider > has a direct peer, they'll want to prioritize that traffic over any other. > > True net-neutrality means no provider can have a better service than > another. This totally screws with private peering and the variety of > requirements, as well as special services (such as akamai nodes). Many > of these cases aren't about saturation, but better connectivity between > content provider and ISP. Adding money or QOS to the equation is just > icing on the cake. There are some excellent points in this, but I disagree as to the conclusions you seem to be drawing. One could look at peering as an opportunity to do some backdoor prioritization, and there's some legitimacy to that fear. My basic expectation as a customer is that you can provide me with some level of service. Since most service providers are unwilling to actually commit to a level of service, I might take the numbers attached to the service tier you sold me. So if I'm now downloading my latest FreeBSD via BitTorrent, my basic expectation is ultimately that I'll get fair treatment. What's "fair treatment" though? I think at the end of the day, it means that I've got to have reasonable access to the Internet. That means that if I can get packets in and out of your transit without fuss, that's probably good enough. If you've short-circuited things with peering that gives me faster access, that's great too. However, if your transit is 100% saturated for 20% of the day, every day, that's NOT good enough. ... 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 jbates at brightok.net Fri Sep 17 15:11:13 2010 From: jbates at brightok.net (Jack Bates) Date: Fri, 17 Sep 2010 10:11:13 -0500 Subject: Did Internet Founders Actually Anticipate Paid, In-Reply-To: <201009171449.o8HEnH6w062387@aurora.sol.net> References: <201009171449.o8HEnH6w062387@aurora.sol.net> Message-ID: <4C938511.50108@brightok.net> On 9/17/2010 9:49 AM, Joe Greco wrote: > So if I'm now downloading my latest FreeBSD via BitTorrent, my basic > expectation is ultimately that I'll get fair treatment. > And this is always a debate. You might say letting someone with voice or video have queue priority during saturation as being unfair, yet your p2p will work when it's running slower, where as their voice or video might fail and be completely unusable. If a provider has to deal with saturation, they have to make such decisions. Their goal, ideally would be to have a majority of the customers able to do what they need to do during saturation, allowing traffic to slow down that can afford to, and giving priority to traffic that to be usable must maintain certain QOS. > What's "fair treatment" though? > > I think at the end of the day, it means that I've got to have reasonable > access to the Internet. That means that if I can get packets in and out > of your transit without fuss, that's probably good enough. If you've > short-circuited things with peering that gives me faster access, that's > great too. However, if your transit is 100% saturated for 20% of the > day, every day, that's NOT good enough. I'm all for rules to limit saturation levels. This has nothing to do with neutrality, but to me it is the more important point. Consider telco world and voice communications. I could be wrong, but I seem to recall there be rules as to how long or often or what percentage of customers could experience issues with getting a line out. I'm also a strong believer in enforcing honest business practices. If you sell prioritization to one company, you should offer it to all others. The practice itself doesn't scale, so given an all or nothing, it is a business model that will burn out. The short-circuits and QOS applications are just methods of improving service for a majority of customers (those who use those destinations/services). This means, of course, p2p will usually be the loser. As an ISP, p2p means little to me. The QOS to the sites that hold a majority of my customers captive is the issue. Even without saturation, I have an obligation to see how I can improve video and voice quality in an erratic environment. This includes dealing with things such as microbursts and last mile saturation (which for me isn't shared, but customer's run multiple applications and the goal is to allow that with a smooth policy to assist in keeping one application from butchering the performance of another, ie, p2p killing their video streams from netflix/hulu/cbs/etc). Jack From bicknell at ufp.org Fri Sep 17 15:17:51 2010 From: bicknell at ufp.org (Leo Bicknell) Date: Fri, 17 Sep 2010 08:17:51 -0700 Subject: Did Internet Founders Actually Anticipate Paid, Prioritized Traffic? In-Reply-To: <20100916.212821.74712800.sthaug@nethelp.no> References: <9CBEC49C-9106-4C7C-AC92-8C525AD9AEBE@semihuman.com> <5A6D953473350C4B9995546AFE9939EE0A52AD92@RWC-EX1.corp.seven.com> <20100916.212821.74712800.sthaug@nethelp.no> Message-ID: <20100917151751.GA12476@ussenterprise.ufp.org> In a message written on Thu, Sep 16, 2010 at 09:28:21PM +0200, sthaug at nethelp.no wrote: > If you want control: Don't buy the cheapest commodity product. > > Steinar Haug, Nethelp consulting, sthaug at nethelp.no It may be hard for those in Europe to understand the situation in the US, so let me explain in real numbers. I live in an upper-middle class suburb of a "tier 2" city, large enough it has everything but not a primary market for anyone. Due to a combination of geography, legacy, and government regulations (how licences are granted, specifically) I have two wireline providers, the local "Cable Company" which is Comcast, and the local "Telephone Company", which is AT&T (ex SBC territory, if it matters). There are no land-based wireless (WiFi, LTE, etc) providers in my area. I am not considering satellite viable for a number of reasons, but if you care there are two providers that cover the whole US, as far as I know. I'd link directly to the pages with prices, but due to the fact that the price and service varies with your ZIP code here I can't do that, you have to fill out a set of forms to even see what you can buy. Here are my choices: Comcast: "Performance": 12 down, 2 up with "Powerboost". Norton Security Suite 7 e-mails, each with 10GB. $42.95 per month. "Performance PLUS": 16 down, 2 up with "Powerboost". Norton Security Suite 7 e-mails, each with 10GB. $52.95 per month. Both include a single IP assigned via DHCP, you bring your own CPE or you can rent from them for a few dollars a month. AT&T U-Verse: "Pro": 3 down $41 "Elite": 6 down $46 "Max": 12 down $48 "Max Plus": 18 down $58 "Max Turbo": 24 down $68 Note that the only change with each product is speed. These all require the use of AT&T CPE (and thus I added in the $3 they charge you for it), and come with the same features the AT&T box presents you a private IP space network and does the NAT for you with a single outside IP. Same number of e-mail accounts (but I can't find the number listed anywhere). Also note they don't list upload speeds on the web site at all. NOTE: Both providers offer discounts for bundling with TV or Phone service, and both offer discounts for the first few months for new customers, I have left off all of these, comparing regular price to regular price for Internet only service. That's it, a total list of my "consumer package" choices. Comcast will offer business service, which is the exact same service over the exact same modems and network, except you can have static IP's and get priority support for about $25-30 extra. AT&T won't sell me business service as I live in a residential neighborhood. Beyond that my choice is to order a T1, 1.5 symmetric from a "real" provider. I can get all the static IP's I want, a real SLA, priority support, and so on. I'll have to supply my own CPE, and it will run somewhere between $700 and $900 a month. I hope that helps folks outside the US understand the situation here. There really isn't a lot of choice, 2 providers, and some minor choice in how much speed you want to pay for with each one. I hear rumors of how good it is in Japan, or Korea, or Sweeden, I would love for folks from those places to post their options. -- 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: 826 bytes Desc: not available URL: From rekoil at semihuman.com Fri Sep 17 15:17:59 2010 From: rekoil at semihuman.com (Chris Woodfield) Date: Fri, 17 Sep 2010 08:17:59 -0700 Subject: Did Internet Founders Actually Anticipate Paid, Prioritized Traffic? In-Reply-To: <4C937192.2090603@brightok.net> References: <9CBEC49C-9106-4C7C-AC92-8C525AD9AEBE@semihuman.com> <5A6D953473350C4B9995546AFE9939EE0A52AD92@RWC-EX1.corp.seven.com> <20100916.212821.74712800.sthaug@nethelp.no> <4C928391.4050701@brightok.net> <8C26A4FDAE599041A13EB499117D3C28405E0809@ex-mb-2.corp.atlasnetworks.us> <4C937192.2090603@brightok.net> Message-ID: <58F283A9-5551-4C15-AFCC-74B01F741E87@semihuman.com> On Sep 17, 2010, at 6:48 02AM, Jack Bates wrote: > On 9/17/2010 4:52 AM, Nathan Eisenberg wrote: >>> True net-neutrality means no provider can have a better service than another. >> >> This statement is not true - or at least, I am not convinced of its truth. True net neutrality means no provider will artificially de-neutralize their service by introducing destination based priority on congested links. > > This is what you want it to mean. If I create a private peer to google, I have de-neutralized their service(destination based priority, even though in both cases, it's the source of the packets we care about) by allowing dedicated bandwidth and lower latency to their cloud. > Practically, this is not the case. These days, most congestion tends to happen at the customer edge - the cable head-end or the DSL DSLAM, not the backbone or peering points. Also, Google, Yahoo, et al tend to base their peering decisions on technical, not business, standards, which makes sense because peering, above all other interconnect types, is mutually beneficial to both parties. More to the point, even the likes of Comcast won't shut down their peers to Yahoo because Google sends them a check. > Also, let's not forget that the design of many p2p programs were specifically designed to ignore and bypass congestion controls... ie, screw other apps, I will take every bit of bandwidth I can get. This type of behavior causes p2p to have higher priority than other apps in a network that has no traffic prioritized. > > While I agree that traffic type prioritization would be preferred over destination based priorities, it often isn't feasible with hardware. Understanding the amount of traffic between your customers and a content provider helps you decide which content providers might be prioritized to give an overall service increase to your customer base. > > The fact that a content provider would even pay an ISP, is a high indicator that the content provider is sending a high load of traffic to the ISP, and bandwidth constraints are an issue with the service. Video and voice, in particular, should always try and have precedence over p2p, as they completely break and become unusable, where p2p will just be forced to move slower. > >>> From a false assumption follows false conclusions. > > Not really. It's not a neutral world. Private peering is by no means neutral. The provider that does enough traffic with google to warrant a private peering will have better service levels than the smaller guy who has to take the public paths. You view net neutrality as customers within an ISP, while I view it as a provider within a network of providers. > It may not be neutral, but it's hardly discrinatory in the ways that I've seen many of the Non-net-neutrality schemes play out, which seems to be all about *deliberately* - either proactively or via actively deciding to not upgrade capacity - creating congestion in order to create a financial incentive for content providers to have their traffic prioritized. And I do agree, a private peer is definitely one technical means by which this prioritization could happen, but that's not the practice today. > The levels of service and pricing I can maintain as a rural ISP can't be compared to the metropolitan ISPs. A west coast ISP won't have the same level of service as an east coast ISP when dealing with geographical based content. We could take it to the international scale, where countries don't have equal service levels to content. > >> >> Why do you feel it's true that net-neutrality treads on private (or even public) peering, or content delivery platforms? In my understanding, they are two separate topics: Net (non)-neutrality is literally about prioritizing different packets on the *same* wire based on whether the destination or source is from an ACL of IPs. IE this link is congested, Netflix sends me a check every month, send their packets before the ones from Hulu and Youtube. The act of sending traffic down a different link directly to a peers' network does not affect the neutrality of either party one iota - in fact, it works to solve the congested link problem (Look! Adding capacity fixed it!). >> > So you are saying, it's perfectly okay to improve one service over another by adding bandwidth directly to that service, but it's unacceptable to prioritize it's traffic on congested links (which effectively adds more bandwidth for that service). It's the same thing, using two different methods. > > If we consider all bandwidth available between the customer and content (and consider latency as well, as it has an effect on the traffic, especially during congestion), a private peer dedicates bandwidth to content the same as prioritizing it's traffic. If anything, the private peer provides even more bandwidth. > > ISP has 2xDS3 available for bandwidth total. Netflix traffic is 20mb/s. Bandwidth is considered saturated. > > 1) 45mb public + 45 mb private = 90mb w/ 45mb prioritized traffic due to private peering > > 2) 90mb public = 90mb w/ 20mb prioritized traffic via destination prioritization (actual usage) > > It appears that the second is a better deal. The fact that netflix got better service levels was an ISP decision. By using prioritization on shared pipes, it actually gave customers more bandwidth than using separate pipes. > >> The ethics of path distances, peering relationships and vector routing, while interesting, are out of scope in a discussion of neutrality. An argument which makes this a larger issue encompassing peering and vector routing is, in my opinion, either a straw man or a red herring (depending on how well it's presented) attempt to generate a second technoethical issue in order to defeat the first one. >> > > It's a matter of viewpoint. It's convenient to talk about net-neutrality when it's scoped, but not when we widen the scope. Customer A gets better service than Customer B because he want to a site that had prioritization. Never mind that while they fight over the saturated link, Customer C beat both of them because he was on a separate segment that wasn't saturated. All 3 paid the same amount of money. C > A > B, yet C doesn't fall into this net-neutrality discussion, and the provider, who wants to keep customers, has more C customers than A, and more A customers than B, so B is the most expendable. > > My viewpoint is that of an ISP, and as such, I think of net-neutrality at a level above some last mile that's saturated at some other ISP. > > Jack > > From wavetossed at googlemail.com Fri Sep 17 15:22:24 2010 From: wavetossed at googlemail.com (Michael Dillon) Date: Fri, 17 Sep 2010 16:22:24 +0100 Subject: Did Internet Founders Actually Anticipate Paid, Prioritized Traffic? In-Reply-To: <4C937192.2090603@brightok.net> References: <9CBEC49C-9106-4C7C-AC92-8C525AD9AEBE@semihuman.com> <5A6D953473350C4B9995546AFE9939EE0A52AD92@RWC-EX1.corp.seven.com> <20100916.212821.74712800.sthaug@nethelp.no> <4C928391.4050701@brightok.net> <8C26A4FDAE599041A13EB499117D3C28405E0809@ex-mb-2.corp.atlasnetworks.us> <4C937192.2090603@brightok.net> Message-ID: > So you are saying, it's perfectly okay to improve one service over another > by adding bandwidth directly to that service, but it's unacceptable to > prioritize it's traffic on congested links (which effectively adds more > bandwidth for that service). It's the same thing, using two different > methods. On TCP/IP networks you cannot prioritize a service and you certainly cannot add bandwidth unless you have an underlying ATM or Frame Relay that has bandwidth in reserve. On a TCP/IP network, QOS features work by deprioritising traffic, either by delaying the traffic or by dropping packets. Many ISPs do deprioritise P2P traffic to prevent it from creating congestion, but that is not something that you can productize. At best you can use it as a feature to encourage customers to use your network. Are you suggesting that ISPs who receive protection money from one service provider, should then deprioritise all the other traffic on their network? > ISP has 2xDS3 available for bandwidth total. Netflix traffic is 20mb/s. > Bandwidth is considered saturated. Now you are talking about circuit capacities well below what ISPs typically use. In fact, two 45Mbps DS3 circuits are less than the 100Mbps Ethernet broadband service that many consumers now use. --Michael Dillon From jbates at brightok.net Fri Sep 17 15:59:45 2010 From: jbates at brightok.net (Jack Bates) Date: Fri, 17 Sep 2010 10:59:45 -0500 Subject: Did Internet Founders Actually Anticipate Paid, Prioritized Traffic? In-Reply-To: References: <9CBEC49C-9106-4C7C-AC92-8C525AD9AEBE@semihuman.com> <5A6D953473350C4B9995546AFE9939EE0A52AD92@RWC-EX1.corp.seven.com> <20100916.212821.74712800.sthaug@nethelp.no> <4C928391.4050701@brightok.net> <8C26A4FDAE599041A13EB499117D3C28405E0809@ex-mb-2.corp.atlasnetworks.us> <4C937192.2090603@brightok.net> Message-ID: <4C939071.6090405@brightok.net> On 9/17/2010 10:22 AM, Michael Dillon wrote: > On a TCP/IP network, QOS features work by deprioritising traffic, > either by delaying > the traffic or by dropping packets. Many ISPs do deprioritise P2P > traffic to prevent > it from creating congestion, but that is not something that you can productize. > At best you can use it as a feature to encourage customers to use your network. > It's not just that. Many p2p apps don't play fair, and their nature causes them to exceed other applications in cases of congestion. You adjust priorities to give a better overall experience on average. > Are you suggesting that ISPs who receive protection money from one service > provider, should then deprioritise all the other traffic on their network? > Is consumer grade bandwidth not deprioritised to business grade bandwidth? The provider is running a reverse business model, charging the content provider as well for better class of service. It doesn't scale, so it is heavily limited, but so long as the provider offers the same service to anyone (ie, anyone can play in this class of service), it seems to be a fair business practice. What should be illegal is the ability to hurt competitors of services offered by the provider (ie, provider offers voip, so they destroy traffic to other voip carriers). In fact, I think it was considered illegal years ago, though I admit that I didn't follow the case to it's conclusion. >> ISP has 2xDS3 available for bandwidth total. Netflix traffic is 20mb/s. >> Bandwidth is considered saturated. > > Now you are talking about circuit capacities well below what ISPs typically > use. In fact, two 45Mbps DS3 circuits are less than the 100Mbps Ethernet > broadband service that many consumers now use. 1) My logic scales, so I saw no reason to use larger numbers. 2) You must live in the City and are making a bad assumption on available capacities. 3) It's easier for those who don't have 100Mb, 1G, 10G, to grasp smaller numbers. Jack From jbates at brightok.net Fri Sep 17 16:23:09 2010 From: jbates at brightok.net (Jack Bates) Date: Fri, 17 Sep 2010 11:23:09 -0500 Subject: Did Internet Founders Actually Anticipate Paid, Prioritized Traffic? In-Reply-To: <58F283A9-5551-4C15-AFCC-74B01F741E87@semihuman.com> References: <9CBEC49C-9106-4C7C-AC92-8C525AD9AEBE@semihuman.com> <5A6D953473350C4B9995546AFE9939EE0A52AD92@RWC-EX1.corp.seven.com> <20100916.212821.74712800.sthaug@nethelp.no> <4C928391.4050701@brightok.net> <8C26A4FDAE599041A13EB499117D3C28405E0809@ex-mb-2.corp.atlasnetworks.us> <4C937192.2090603@brightok.net> <58F283A9-5551-4C15-AFCC-74B01F741E87@semihuman.com> Message-ID: <4C9395ED.9090103@brightok.net> On 9/17/2010 10:17 AM, Chris Woodfield wrote: > Also, Google, Yahoo, et al tend to base their peering decisions on technical, not business, standards, which makes sense because peering, above all other interconnect types, is mutually beneficial to both parties. More to the point, even the likes of Comcast won't shut down their peers to Yahoo because Google sends them a check. > I disagree. Minimum throughput for wasting a port on a router is a business reason, not technical. Peering is all about business and equal equity. Not to say that technical reasons don't play a part. Limitations of throughput requires some peering, but there is definitely a business model attached to it to determine the equity of the peers. > And I do agree, a private peer is definitely one technical means by which this prioritization could happen, but that's not the practice today. > Penny saved is a penny earned. Peering is generally cheaper than transit. In addition, it usually provides higher class of service. Money doesn't have to change hands for there to be value attached to the action. At the same time, when money does change hands, the paying party feels they are getting something of value. Is it unfair that I pay streaming sites to get more/earlier video feeds over the free users? I still have to deal with advertisements in some cases, which generates the primary revenue for the streaming site. Why shouldn't a content provider be able to pay for a higher class of service, so long as others are equally allowed to pay for it? Jack From rekoil at semihuman.com Fri Sep 17 16:27:28 2010 From: rekoil at semihuman.com (Chris Woodfield) Date: Fri, 17 Sep 2010 09:27:28 -0700 Subject: Did Internet Founders Actually Anticipate Paid, Prioritized Traffic? In-Reply-To: <4C9395ED.9090103@brightok.net> References: <9CBEC49C-9106-4C7C-AC92-8C525AD9AEBE@semihuman.com> <5A6D953473350C4B9995546AFE9939EE0A52AD92@RWC-EX1.corp.seven.com> <20100916.212821.74712800.sthaug@nethelp.no> <4C928391.4050701@brightok.net> <8C26A4FDAE599041A13EB499117D3C28405E0809@ex-mb-2.corp.atlasnetworks.us> <4C937192.2090603@brightok.net> <58F283A9-5551-4C15-AFCC-74B01F741E87@semihuman.com> <4C9395ED.9090103@brightok.net> Message-ID: <99F0FBCF-5128-428B-8F0B-5D5803839324@semihuman.com> On Sep 17, 2010, at 9:23 09AM, Jack Bates wrote: > > Is it unfair that I pay streaming sites to get more/earlier video feeds over the free users? I still have to deal with advertisements in some cases, which generates the primary revenue for the streaming site. Why shouldn't a content provider be able to pay for a higher class of service, so long as others are equally allowed to pay for it? No, it is definitely not, because *you* are the one paying for priority access for the content *you* feel is worth paying extra for faster access to. This is not the same thing as a content provider paying the carrier for priority access to your DSL line to the detriment of other sites you are interested it. How would you feel if you paid for priority access to hulu.com via this means, only to see your carrier de-prioritize that traffic because they're getting a check from Netflix? > Jack From drew.weaver at thenap.com Fri Sep 17 16:43:50 2010 From: drew.weaver at thenap.com (Drew Weaver) Date: Fri, 17 Sep 2010 12:43:50 -0400 Subject: Did Internet Founders Actually Anticipate Paid, Prioritized Traffic? In-Reply-To: <99F0FBCF-5128-428B-8F0B-5D5803839324@semihuman.com> References: <9CBEC49C-9106-4C7C-AC92-8C525AD9AEBE@semihuman.com> <5A6D953473350C4B9995546AFE9939EE0A52AD92@RWC-EX1.corp.seven.com> <20100916.212821.74712800.sthaug@nethelp.no> <4C928391.4050701@brightok.net> <8C26A4FDAE599041A13EB499117D3C28405E0809@ex-mb-2.corp.atlasnetworks.us> <4C937192.2090603@brightok.net> <58F283A9-5551-4C15-AFCC-74B01F741E87@semihuman.com> <4C9395ED.9090103@brightok.net> <99F0FBCF-5128-428B-8F0B-5D5803839324@semihuman.com> Message-ID: >How would you feel if you paid for priority access to hulu.com via this means, only to see >your carrier de-prioritize that traffic because they're getting a check from Netflix? Isn't this where "competition/may the best provider win" comes into play? -Drew From msokolov at ivan.Harhan.ORG Fri Sep 17 16:44:04 2010 From: msokolov at ivan.Harhan.ORG (Michael Sokolov) Date: Fri, 17 Sep 2010 16:44:04 GMT Subject: Did Internet Founders Actually Anticipate Paid, Prioritized Traffic? Message-ID: <1009171644.AA02827@ivan.Harhan.ORG> Leo Bicknell wrote: > There really isn't a lot of choice, 2 providers, and some minor choice > in how much speed you want to pay for with each one. Does that mean no CLECs like Covad or DSL.net who colocate in the AT&T CO, rent unbundled dry copper pairs and take it up from there themselves? Does that mean no ISPs who buy/rent last+middle mile transport from AT&T ADSL network at Layer 2 (ATM) and provide their own IP layer? MS From jbates at brightok.net Fri Sep 17 16:44:40 2010 From: jbates at brightok.net (Jack Bates) Date: Fri, 17 Sep 2010 11:44:40 -0500 Subject: Did Internet Founders Actually Anticipate Paid, Prioritized Traffic? In-Reply-To: <99F0FBCF-5128-428B-8F0B-5D5803839324@semihuman.com> References: <9CBEC49C-9106-4C7C-AC92-8C525AD9AEBE@semihuman.com> <5A6D953473350C4B9995546AFE9939EE0A52AD92@RWC-EX1.corp.seven.com> <20100916.212821.74712800.sthaug@nethelp.no> <4C928391.4050701@brightok.net> <8C26A4FDAE599041A13EB499117D3C28405E0809@ex-mb-2.corp.atlasnetworks.us> <4C937192.2090603@brightok.net> <58F283A9-5551-4C15-AFCC-74B01F741E87@semihuman.com> <4C9395ED.9090103@brightok.net> <99F0FBCF-5128-428B-8F0B-5D5803839324@semihuman.com> Message-ID: <4C939AF8.7070307@brightok.net> On 9/17/2010 11:27 AM, Chris Woodfield wrote: > How would you feel if you paid for priority access to hulu.com > via this means, only to see your carrier de-prioritize > that traffic because they're getting a check from Netflix? The same as I'd feel if netflix paid them for pop transit which bypassed the congestion (even if it was via mpls-te or dedicated circuit instead of just priorities on a congested link). Netflix apparently felt that there was value in having a higher class of service and paid for it. Of course, I'd be against congested links in my ISP to begin with. I'd move and get a new ISP if I could. If I was stuck, then I'd be stuck. My distaste for my ISP having congested links wouldn't equate to distaste that a content provider paid to have better class of service due to the ISP having poor overall service. If said class of service completely wiped out the bandwidth and caused all normal traffic to be unusable, then the ISP most likely is in violation of their agreement with me (ie, not providing access, as it is unusable). This would be no different than selling off bandwidth to commercial grade customers to the point that consumer grade didn't work at all. Jack From jbates at brightok.net Fri Sep 17 16:50:13 2010 From: jbates at brightok.net (Jack Bates) Date: Fri, 17 Sep 2010 11:50:13 -0500 Subject: Did Internet Founders Actually Anticipate Paid, Prioritized Traffic? In-Reply-To: References: <9CBEC49C-9106-4C7C-AC92-8C525AD9AEBE@semihuman.com> <5A6D953473350C4B9995546AFE9939EE0A52AD92@RWC-EX1.corp.seven.com> <20100916.212821.74712800.sthaug@nethelp.no> <4C928391.4050701@brightok.net> <8C26A4FDAE599041A13EB499117D3C28405E0809@ex-mb-2.corp.atlasnetworks.us> <4C937192.2090603@brightok.net> <58F283A9-5551-4C15-AFCC-74B01F741E87@semihuman.com> <4C9395ED.9090103@brightok.net> <99F0FBCF-5128-428B-8F0B-5D5803839324@semihuman.com> Message-ID: <4C939C45.80109@brightok.net> On 9/17/2010 11:43 AM, Drew Weaver wrote: >> How would you feel if you paid for priority access to hulu.com via this means, only to see>your carrier de-prioritize that traffic because they're getting a check from Netflix? > > Isn't this where "competition/may the best provider win" comes into play? > That argument may not work, as there are many non-competitive jurisdictions. Of course, the non-compete areas aren't necessarily where a content provider would pay for such a service. Content provider must see value in the higher class service, which generally means they send a lot of traffic to where they are paying, which implies a lot of customers on the ISP side, which implies a high probability that we are talking metropolitan areas where there is more competition (or a massive NSP which will have a mix of rural and metro). Jack From cb.list6 at gmail.com Fri Sep 17 16:59:58 2010 From: cb.list6 at gmail.com (Cameron Byrne) Date: Fri, 17 Sep 2010 09:59:58 -0700 Subject: IPv4 literals and IPv6-only hosts Message-ID: In planning for IPv4 exhaust, i have been tinkering with NAT64/DNS64 in preparation to launch it with customers. In my experience it works well, my phone has been Ipv6-only + NAT64 for over 6 months.... no major roadblocks. There have also been other documented NAT64 deployments that work well, especially on mobile devices http://tools.ietf.org/html/draft-arkko-ipv6-only-experience-01 I do not believe that there is much risk in deploying NAT64, the customer experience can be engineered on mobile to be very good, but there is some minor risk that does not need to be there because of content providers using IPv4 literals, which are IPv4 address embedded in content (HTML, XML, apps...). I think across the industry people believe using names (FQDNs) is a better practice than embedding IPv4 addresses, nonetheless it happens. So, in an effort to help content providers understand that IPv6-only customers will not be able to access their IPv4 literal laden content, i have created this group http://groups.google.com/group/ipv4literals The group is not about name and shame or fixing every instance of literals, it is about making sure that the risks of using IPv4 literals are known by the content providers and that they have a good opportunity to fix it, start using FQDNs or deploy IPv6. Also, if anyone has a good nytimes.com or Amazon video on demand contact, you may want to forward this on to them. Thanks, Cameron http://groups.google.com/group/ipv4literals http://groups.google.com/group/tmoipv6beta From bicknell at ufp.org Fri Sep 17 17:15:11 2010 From: bicknell at ufp.org (Leo Bicknell) Date: Fri, 17 Sep 2010 10:15:11 -0700 Subject: Did Internet Founders Actually Anticipate Paid, Prioritized Traffic? In-Reply-To: <1009171644.AA02827@ivan.Harhan.ORG> References: <1009171644.AA02827@ivan.Harhan.ORG> Message-ID: <20100917171511.GA24909@ussenterprise.ufp.org> In a message written on Fri, Sep 17, 2010 at 04:44:04PM +0000, Michael Sokolov wrote: > Does that mean no CLECs like Covad or DSL.net who colocate in the AT&T > CO, rent unbundled dry copper pairs and take it up from there themselves? > > Does that mean no ISPs who buy/rent last+middle mile transport from AT&T > ADSL network at Layer 2 (ATM) and provide their own IP layer? In my area, from the research I have done, no. Part of the reason for this is "U-Verse" is FTTN, Fiber to the Node. AT&T has run fiber to my neighborhood, I believe the node in my case is about 1000 feet away (I drive past it on the way out). The electronics sit there, so the old model of colocating in the CO and getting the dry pair is no longer possible, the copper stops at the node and it's a largeish (6' wide, 3' deep, 5' tall) cabinet, so there's no colo. The other model of the last mile being done by AT&T and handed off over PPoE or ATM is still possible with this design, but to my knowledge there are no local CLEC's that do that here, and I do not know why. Just to be sure I just went to www.megapath.com (they bought DSL.net and Covad) and put in my address. I got back: Available Services for:
Available broadband type(s): T1 , IDSL , DDSL , Cable , ADSL Duet Voice and Data service is available at this location My experience is when they can't give you prices online they don't actually offer any consumer services and are simply going to try and sell you a T1 for $750 a month. If enough people care I might call, or if there is a Megapath person on here who can contact me off list I can give them my address and they can tell me/us what is really possible. -- 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: 826 bytes Desc: not available URL: From msokolov at ivan.Harhan.ORG Fri Sep 17 17:44:15 2010 From: msokolov at ivan.Harhan.ORG (Michael Sokolov) Date: Fri, 17 Sep 2010 17:44:15 GMT Subject: Did Internet Founders Actually Anticipate Paid, Prioritized Traffic? Message-ID: <1009171744.AA02979@ivan.Harhan.ORG> Leo Bicknell wrote: > Part of the reason for this is "U-Verse" is FTTN, Fiber to the Node. > AT&T has run fiber to my neighborhood, I believe the node in my > case is about 1000 feet away (I drive past it on the way out). The > electronics sit there, so the old model of colocating in the CO and > getting the dry pair is no longer possible, the copper stops at the > node and it's a largeish (6' wide, 3' deep, 5' tall) cabinet, so > there's no colo. We have that exact same stuff in my area too: I've actually talked to the AT&T tech who was setting that cabinet up on one of our streets. The explanation he gave me was that even though they want everyone to go to this new-fangled fiber thing, they still have to maintain a small number of copper pairs running all the way to the real CO like it used to be. The reason is that if some kooky customer like me wants a service like ISDN that's only available from the real Class 5 switch and not from the "U-Verse" remote terminal, they are still required to provide that as a regulated telco. Ditto with CLECs like Covad-now-MegaPath: even though they don't get access to the FTTN infrastructure, no telco is evicting their legacy CO presence. Therefore, if a kooky customer like me wishes to forego fiber speeds and prefers the slower all-copper solution, I can still get SDSL from the CLEC, and the ILEC (AT&T) will be required to provide a direct copper pair from that CLEC's cage inside the CO to the customer premise, no matter how much they wish for these copper pairs to die. Long live copper! MS From owen at delong.com Fri Sep 17 18:27:34 2010 From: owen at delong.com (Owen DeLong) Date: Fri, 17 Sep 2010 11:27:34 -0700 Subject: Did Internet Founders Actually Anticipate Paid, Prioritized Traffic? In-Reply-To: <8C26A4FDAE599041A13EB499117D3C28405E0809@ex-mb-2.corp.atlasnetworks.us> References: <9CBEC49C-9106-4C7C-AC92-8C525AD9AEBE@semihuman.com> <5A6D953473350C4B9995546AFE9939EE0A52AD92@RWC-EX1.corp.seven.com> <20100916.212821.74712800.sthaug@nethelp.no> <4C928391.4050701@brightok.net> <8C26A4FDAE599041A13EB499117D3C28405E0809@ex-mb-2.corp.atlasnetworks.us> Message-ID: On Sep 17, 2010, at 2:52 AM, Nathan Eisenberg wrote: >> True net-neutrality means no provider can have a better service than another. > > This statement is not true - or at least, I am not convinced of its truth. True net neutrality means no provider will artificially de-neutralize their service by introducing destination based priority on congested links. > >> This totally screws with private peering and the variety of requirements, as well >> as special services (such as akamai nodes). Many of these cases aren't about >> saturation, but better connectivity between content provider and ISP. Adding >> money or QOS to the equation is just icing on the cake. > >> From a false assumption follows false conclusions. > > Why do you feel it's true that net-neutrality treads on private (or even public) peering, or content delivery platforms? In my understanding, they are two separate topics: Net (non)-neutrality is literally about prioritizing different packets on the *same* wire based on whether the destination or source is from an ACL of IPs. IE this link is congested, Netflix sends me a check every month, send their packets before the ones from Hulu and Youtube. The act of sending traffic down a different link directly to a peers' network does not affect the neutrality of either party one iota - in fact, it works to solve the congested link problem (Look! Adding capacity fixed it!). > > The ethics of path distances, peering relationships and vector routing, while interesting, are out of scope in a discussion of neutrality. An argument which makes this a larger issue encompassing peering and vector routing is, in my opinion, either a straw man or a red herring (depending on how well it's presented) attempt to generate a second technoethical issue in order to defeat the first one. > > Nathan > A big part of the problem here is that net neutrality has been given a variety of definitions, some of which I agree with, some of which I don't... Here are my understanding of some of the definitions (along with my basic opinion of each): 1. All potential peers are treated equally. (As much as I'd like to see this happen, it isn't realistic to expect it will happen and any imaginable attempt at legislating it will do more harm than good). 2. Traffic is not artificially prioritized on congested links due to subsidies from the source or destination. Note: This does not include prioritization requested by the link customer. (I think that it is important to have this for the internet to continue as a tool for the democratization of communication. I think that this will require legislative protection). 3. Net neutrality requires an open peering policy. (Personally, I am a fan of open peering policies. However, a network should have the freedom of choice to implement whatever peering policy they wish.) I'm sure there are more definitions floating around. People are welcome to comment on them. These are the ones I have seen take hold amongst various community stakeholders. Owen From cscora at apnic.net Fri Sep 17 18:48:06 2010 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 18 Sep 2010 04:48:06 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <201009171848.o8HIm6Z5001328@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. The posting is sent to APOPS, NANOG, AfNOG, AusNOG, SANOG, PacNOG, LacNOG, CaribNOG and the RIPE Routing Working Group. Daily listings are sent to bgp-stats at lists.apnic.net For historical data, please see http://thyme.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 18 Sep, 2010 Report Website: http://thyme.apnic.net Detailed Analysis: http://thyme.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 331135 Prefixes after maximum aggregation: 152252 Deaggregation factor: 2.17 Unique aggregates announced to Internet: 162663 Total ASes present in the Internet Routing Table: 34823 Prefixes per ASN: 9.51 Origin-only ASes present in the Internet Routing Table: 30197 Origin ASes announcing only one prefix: 14661 Transit ASes present in the Internet Routing Table: 4626 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 (41664) 21 Prefixes from unregistered ASNs in the Routing Table: 2711 Unregistered ASNs in the Routing Table: 1247 Number of 32-bit ASNs allocated by the RIRs: 777 Prefixes from 32-bit ASNs in the Routing Table: 1013 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 195 Number of addresses announced to Internet: 2269815744 Equivalent to 135 /8s, 74 /16s and 163 /24s Percentage of available address space announced: 61.2 Percentage of allocated address space announced: 65.4 Percentage of available address space allocated: 93.7 Percentage of address space in use by end-sites: 84.8 Total number of prefixes smaller than registry allocations: 156540 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 80501 Total APNIC prefixes after maximum aggregation: 27663 APNIC Deaggregation factor: 2.91 Prefixes being announced from the APNIC address blocks: 77482 Unique aggregates announced from the APNIC address blocks: 34148 APNIC Region origin ASes present in the Internet Routing Table: 4193 APNIC Prefixes per ASN: 18.48 APNIC Region origin ASes announcing only one prefix: 1170 APNIC Region transit ASes present in the Internet Routing Table: 649 Average APNIC Region AS path length visible: 3.7 Max APNIC Region AS path length visible: 15 Number of APNIC addresses announced to Internet: 548634656 Equivalent to 32 /8s, 179 /16s and 128 /24s Percentage of available APNIC address space announced: 77.9 APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079 55296-56319, 131072-132095 APNIC Address Blocks 1/8, 14/8, 27/8, 43/8, 49/8, 58/8, 59/8, 60/8, 61/8, 101/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, 133/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, 223/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 135830 Total ARIN prefixes after maximum aggregation: 70008 ARIN Deaggregation factor: 1.94 Prefixes being announced from the ARIN address blocks: 108483 Unique aggregates announced from the ARIN address blocks: 42882 ARIN Region origin ASes present in the Internet Routing Table: 13915 ARIN Prefixes per ASN: 7.80 ARIN Region origin ASes announcing only one prefix: 5331 ARIN Region transit ASes present in the Internet Routing Table: 1382 Average ARIN Region AS path length visible: 3.4 Max ARIN Region AS path length visible: 22 Number of ARIN addresses announced to Internet: 733654048 Equivalent to 43 /8s, 186 /16s and 172 /24s Percentage of available ARIN address space announced: 62.5 ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 53248-55295, 393216-394239 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, 50/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, 107/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: 76004 Total RIPE prefixes after maximum aggregation: 44137 RIPE Deaggregation factor: 1.72 Prefixes being announced from the RIPE address blocks: 69440 Unique aggregates announced from the RIPE address blocks: 45491 RIPE Region origin ASes present in the Internet Routing Table: 14793 RIPE Prefixes per ASN: 4.69 RIPE Region origin ASes announcing only one prefix: 7615 RIPE Region transit ASes present in the Internet Routing Table: 2223 Average RIPE Region AS path length visible: 3.9 Max RIPE Region AS path length visible: 24 Number of RIPE addresses announced to Internet: 439134848 Equivalent to 26 /8s, 44 /16s and 170 /24s Percentage of available RIPE address space announced: 77.0 RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-52223, 196608-197631 RIPE Address Blocks 2/8, 25/8, 31/8, 46/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, 176/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: 30120 Total LACNIC prefixes after maximum aggregation: 7214 LACNIC Deaggregation factor: 4.18 Prefixes being announced from the LACNIC address blocks: 28673 Unique aggregates announced from the LACNIC address blocks: 15258 LACNIC Region origin ASes present in the Internet Routing Table: 1350 LACNIC Prefixes per ASN: 21.24 LACNIC Region origin ASes announcing only one prefix: 421 LACNIC Region transit ASes present in the Internet Routing Table: 235 Average LACNIC Region AS path length visible: 4.0 Max LACNIC Region AS path length visible: 19 Number of LACNIC addresses announced to Internet: 75506304 Equivalent to 4 /8s, 128 /16s and 34 /24s Percentage of available LACNIC address space announced: 56.3 LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 262144-263167 plus ERX transfers LACNIC Address Blocks 177/8, 181/8, 186/8, 187/8, 189/8, 190/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 7414 Total AfriNIC prefixes after maximum aggregation: 1892 AfriNIC Deaggregation factor: 3.92 Prefixes being announced from the AfriNIC address blocks: 5721 Unique aggregates announced from the AfriNIC address blocks: 1674 AfriNIC Region origin ASes present in the Internet Routing Table: 405 AfriNIC Prefixes per ASN: 14.13 AfriNIC Region origin ASes announcing only one prefix: 124 AfriNIC Region transit ASes present in the Internet Routing Table: 90 Average AfriNIC Region AS path length visible: 3.8 Max AfriNIC Region AS path length visible: 15 Number of AfriNIC addresses announced to Internet: 20253184 Equivalent to 1 /8s, 53 /16s and 10 /24s Percentage of available AfriNIC address space announced: 60.4 AfriNIC AS Blocks 36864-37887, 327680-328703 & 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 1860 9436 501 Korea Telecom (KIX) 7545 1369 298 84 TPG Internet Pty Ltd 4755 1346 370 160 TATA Communications formerly 17488 1346 153 123 Hathway IP Over Cable Interne 17974 1234 298 70 PT TELEKOMUNIKASI INDONESIA 24560 1029 304 177 Bharti Airtel Ltd., Telemedia 9583 1016 76 490 Sify Limited 4808 931 1713 260 CNCGROUP IP network: China169 18101 879 99 131 Reliance Infocom Ltd Internet 9829 821 691 36 BSNL National Internet Backbo Complete listing at http://thyme.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 3792 3667 278 bellsouth.net, inc. 4323 2702 1107 390 Time Warner Telecom 19262 1816 4668 286 Verizon Global Networks 1785 1793 698 131 PaeTec Communications, Inc. 20115 1494 1529 653 Charter Communications 7018 1459 5732 946 AT&T WorldNet Services 6478 1341 274 132 AT&T Worldnet Services 2386 1293 554 911 AT&T Data Communications Serv 11492 1194 228 89 Cable One 22773 1193 2858 61 Cox Communications, Inc. Complete listing at http://thyme.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 3292 448 2026 389 TDC Tele Danmark 30890 439 99 209 Evolva Telecom 702 409 1869 323 UUNET - Commercial IP service 8866 403 117 19 Bulgarian Telecommunication C 8551 402 353 46 Bezeq International 3301 376 1672 331 TeliaNet Sweden 34984 374 90 185 BILISIM TELEKOM 3320 371 7328 323 Deutsche Telekom AG 12479 360 576 5 Uni2 Autonomous System 31148 338 18 79 FreeNet ISP 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 1381 2655 343 UniNet S.A. de C.V. 10620 1319 247 148 TVCABLE BOGOTA 28573 1095 866 109 NET Servicos de Comunicao S.A 7303 794 408 101 Telecom Argentina Stet-France 6503 772 193 277 AVANTEL, S.A. 14420 578 37 74 CORPORACION NACIONAL DE TELEC 22047 559 310 15 VTR PUNTO NET S.A. 3816 480 209 94 Empresa Nacional de Telecomun 7738 477 922 30 Telecomunicacoes da Bahia S.A 11172 444 99 76 Servicios Alestra S.A de C.V 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 1152 445 10 TEDATA 24863 728 147 39 LINKdotNET AS number 36992 661 279 176 Etisalat MISR 3741 266 906 224 The Internet Solution 6713 203 199 12 Itissalat Al-MAGHRIB 29571 200 19 11 Ci Telecom Autonomous system 2018 197 277 64 Tertiary Education Network 33776 196 12 14 Starcomms Nigeria Limited 24835 165 78 9 RAYA Telecom - Egypt 16637 155 440 93 MTN Network Solutions 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 3792 3667 278 bellsouth.net, inc. 4323 2702 1107 390 Time Warner Telecom 4766 1860 9436 501 Korea Telecom (KIX) 19262 1816 4668 286 Verizon Global Networks 1785 1793 698 131 PaeTec Communications, Inc. 20115 1494 1529 653 Charter Communications 7018 1459 5732 946 AT&T WorldNet Services 8151 1381 2655 343 UniNet S.A. de C.V. 7545 1369 298 84 TPG Internet Pty Ltd 4755 1346 370 160 TATA Communications formerly Complete listing at http://thyme.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 4323 2702 2312 Time Warner Telecom 1785 1793 1662 PaeTec Communications, Inc. 19262 1816 1530 Verizon Global Networks 4766 1860 1359 Korea Telecom (KIX) 7545 1369 1285 TPG Internet Pty Ltd 17488 1346 1223 Hathway IP Over Cable Interne 6478 1341 1209 AT&T Worldnet Services 4755 1346 1186 TATA Communications formerly 10620 1319 1171 TVCABLE BOGOTA 17974 1234 1164 PT TELEKOMUNIKASI INDONESIA Complete listing at http://thyme.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 11946 UNALLOCATED 8.12.155.0/24 40913 Quality Technology S 33084 UNALLOCATED 8.15.195.0/24 3356 Level 3 Communicatio 18826 UNALLOCATED 8.17.208.0/20 2828 XO Communications 16734 UNALLOCATED 8.18.204.0/24 26914 Global Netoptex, Inc 53562 UNALLOCATED 8.19.94.0/24 3356 Level 3 Communicatio 22015 UNALLOCATED 8.22.137.0/24 14989 Broadview Networks 46856 UNALLOCATED 8.22.184.0/22 3356 Level 3 Communicatio 21893 UNALLOCATED 8.26.33.0/24 3356 Level 3 Communicatio 26169 UNALLOCATED 8.225.177.0/24 20225 TelJet 32249 UNALLOCATED 8.225.178.0/24 3356 Level 3 Communicatio Complete listing at http://thyme.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 31.0.0.0/16 12654 RIPE NCC RIS Project 31.1.0.0/21 12654 RIPE NCC RIS Project 31.1.24.0/24 12654 RIPE NCC RIS Project 41.222.79.0/24 36938 >>UNKNOWN<< 41.223.196.0/24 36990 Alkan Telecom Ltd 41.223.197.0/24 36990 Alkan Telecom Ltd 41.223.198.0/24 36990 Alkan Telecom Ltd 41.223.199.0/24 36990 Alkan Telecom Ltd 46.45.128.0/21 42926 RIPE Network Coordination Cen 46.45.136.0/21 42926 RIPE Network Coordination Cen 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:67 /12:201 /13:419 /14:730 /15:1320 /16:11275 /17:5437 /18:9283 /19:18511 /20:23458 /21:23639 /22:30953 /23:30252 /24:172587 /25:1015 /26:1124 /27:583 /28:167 /29:47 /30:6 /31:0 /32:7 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 6389 2418 3792 bellsouth.net, inc. 4766 1477 1860 Korea Telecom (KIX) 4323 1367 2702 Time Warner Telecom 1785 1256 1793 PaeTec Communications, Inc. 10620 1207 1319 TVCABLE BOGOTA 11492 1096 1194 Cable One 17488 1087 1346 Hathway IP Over Cable Interne 18566 1068 1087 Covad Communications 8452 1044 1152 TEDATA 24560 930 1029 Bharti Airtel Ltd., Telemedia Complete listing at http://thyme.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:71 2:11 4:13 8:307 12:2012 13:8 14:4 15:20 16:3 17:9 20:8 24:1393 27:339 31:1 32:61 33:12 38:701 40:97 41:2526 44:3 46:72 47:13 49:1 52:12 55:6 56:2 57:29 58:827 59:497 60:474 61:1081 62:1020 63:1968 64:3722 65:2300 66:3998 67:1862 68:1136 69:2797 70:739 71:372 72:1948 73:2 74:2326 75:284 76:329 77:906 78:647 79:414 80:1011 81:781 82:496 83:445 84:680 85:1036 86:432 87:682 88:324 89:1562 90:96 91:3044 92:426 93:992 94:1419 95:705 96:380 97:219 98:623 99:34 101:1 108:64 109:667 110:502 111:580 112:298 113:291 114:453 115:587 116:1098 117:658 118:510 119:869 120:137 121:703 122:1541 123:918 124:1221 125:1242 128:226 129:157 130:170 131:541 132:258 133:20 134:201 135:46 136:223 137:138 138:273 139:109 140:479 141:197 142:345 143:353 144:475 145:54 146:428 147:169 148:630 149:294 150:152 151:233 152:288 153:170 154:3 155:365 156:169 157:335 158:112 159:359 160:313 161:190 162:268 163:167 164:418 165:370 166:468 167:413 168:666 169:156 170:727 171:61 172:2 173:1078 174:500 175:169 176:1 177:1 178:483 180:648 181:1 182:211 183:254 184:156 186:644 187:479 188:809 189:811 190:4139 192:5775 193:4736 194:3435 195:2798 196:1188 198:3557 199:3579 200:5398 201:1578 202:8098 203:8290 204:3996 205:2383 206:2537 207:3065 208:3868 209:3469 210:2560 211:1307 212:1742 213:1684 214:673 215:66 216:4753 217:1573 218:473 219:398 220:1176 221:386 222:316 223:45 End of report From ekim.ittag at gmail.com Fri Sep 17 18:49:57 2010 From: ekim.ittag at gmail.com (Mike Gatti) Date: Fri, 17 Sep 2010 14:49:57 -0400 Subject: Netflow Tool Message-ID: <8E440D28-42C6-4875-8E0A-D9E3D9E8DF41@gmail.com> Anyone out there using a good netflow collector that has the capability data to export to CSV? Open Source would be best, but any suggestions are welcome. Thanks, =+=+=+=+=+=+=+=+=+=+=+=+= Michael Gatti cell.703.347.4412 ekim.ittag at gmail.com =+=+=+=+=+=+=+=+=+=+=+=+= From hhoffman at ip-solutions.net Fri Sep 17 19:02:22 2010 From: hhoffman at ip-solutions.net (Harry Hoffman) Date: Fri, 17 Sep 2010 15:02:22 -0400 Subject: Netflow Tool In-Reply-To: <8E440D28-42C6-4875-8E0A-D9E3D9E8DF41@gmail.com> References: <8E440D28-42C6-4875-8E0A-D9E3D9E8DF41@gmail.com> Message-ID: <1284750142.18201.17.camel@n1-20-152.dhcp.drexel.edu> argus, www.qosient.com/argus On Fri, 2010-09-17 at 14:49 -0400, Mike Gatti wrote: > Anyone out there using a good netflow collector that has the capability data to export to CSV? > Open Source would be best, but any suggestions are welcome. > > Thanks, > =+=+=+=+=+=+=+=+=+=+=+=+= > Michael Gatti > cell.703.347.4412 > ekim.ittag at gmail.com > =+=+=+=+=+=+=+=+=+=+=+=+= > > > > > From nathan at atlasnetworks.us Fri Sep 17 19:05:00 2010 From: nathan at atlasnetworks.us (Nathan Eisenberg) Date: Fri, 17 Sep 2010 19:05:00 +0000 Subject: Did Internet Founders Actually Anticipate Paid, Prioritized Traffic? In-Reply-To: <4C937192.2090603@brightok.net> References: <9CBEC49C-9106-4C7C-AC92-8C525AD9AEBE@semihuman.com> <5A6D953473350C4B9995546AFE9939EE0A52AD92@RWC-EX1.corp.seven.com> <20100916.212821.74712800.sthaug@nethelp.no> <4C928391.4050701@brightok.net> <8C26A4FDAE599041A13EB499117D3C28405E0809@ex-mb-2.corp.atlasnetworks.us> <4C937192.2090603@brightok.net> Message-ID: <8C26A4FDAE599041A13EB499117D3C28405E483D@ex-mb-2.corp.atlasnetworks.us> > It's a matter of viewpoint. It's convenient to talk about net-neutrality when it's > scoped, but not when we widen the scope. Customer A gets better service than > Customer B because he want to a site that had prioritization. Never mind that > while they fight over the saturated link, Customer C beat both of them because > he was on a separate segment that wasn't saturated. All 3 paid the same > amount of money. C > A > B, yet C doesn't fall into this net-neutrality > discussion, and the provider, who wants to keep customers, has more C > customers than A, and more A customers than B, so B is the most expendable. It's convenient to talk about NN when we're talking about NN, and not about the ethical implications of peering with Comcast but not with ATT. There are things that NN is, and there are things that it isn't. There are a good deal of ethical and emotional issues involved, and while they're interesting to opine about, they're difficult to successfully argue. However, from a purely technical perspective, your above example illustrates my point. Customer A and B both lose. Why? Because prioritization and destination based discrimination are not real solutions. Capacity is. Customer A and B have saturation and discrimination. Customer C has capacity. Want to keep A and B (and your reputation)? Add capacity. > My viewpoint is that of an ISP, and as such, I think of net-neutrality at a level > above some last mile that's saturated at some other ISP. I have the same point of view but it appears that we disagree anyways. It must be the case that the perspective does not define the opinion. Appreciated the thinly veiled appeal to authority, though. Capacity is cheap. Discriminatory traffic management for-profit is a fantastically expensive way of killing off your customer base in exchange for short-term revenue opportunities. You MUST construct additional pylons, or the guy that does WILL take your customers. Nathan From everton.marques at gmail.com Fri Sep 17 19:06:33 2010 From: everton.marques at gmail.com (Everton Marques) Date: Fri, 17 Sep 2010 16:06:33 -0300 Subject: Netflow Tool In-Reply-To: <8E440D28-42C6-4875-8E0A-D9E3D9E8DF41@gmail.com> References: <8E440D28-42C6-4875-8E0A-D9E3D9E8DF41@gmail.com> Message-ID: On Fri, Sep 17, 2010 at 3:49 PM, Mike Gatti wrote: > Anyone out there using a good netflow collector that has the capability > data to export to CSV? > Open Source would be best, but any suggestions are welcome. > nfdump with custom output. Custom output format: -o fmt:.. This is the most flexibel format, as you can specify yourself how the output looks like. The output format is defined using element tags as well as plain ascii text. http://nfdump.sourceforge.net/ Everton From owen at delong.com Fri Sep 17 19:08:11 2010 From: owen at delong.com (Owen DeLong) Date: Fri, 17 Sep 2010 12:08:11 -0700 Subject: Did Internet Founders Actually Anticipate Paid, Prioritized Traffic? In-Reply-To: <4C937192.2090603@brightok.net> References: <9CBEC49C-9106-4C7C-AC92-8C525AD9AEBE@semihuman.com> <5A6D953473350C4B9995546AFE9939EE0A52AD92@RWC-EX1.corp.seven.com> <20100916.212821.74712800.sthaug@nethelp.no> <4C928391.4050701@brightok.net> <8C26A4FDAE599041A13EB499117D3C28405E0809@ex-mb-2.corp.atlasnetworks.us> <4C937192.2090603@brightok.net> Message-ID: <0CB6A373-7372-41E2-A896-B27E0F64BB67@delong.com> On Sep 17, 2010, at 6:48 AM, Jack Bates wrote: > On 9/17/2010 4:52 AM, Nathan Eisenberg wrote: >>> True net-neutrality means no provider can have a better service than another. >> >> This statement is not true - or at least, I am not convinced of its truth. True net neutrality means no provider will artificially de-neutralize their service by introducing destination based priority on congested links. > > This is what you want it to mean. If I create a private peer to google, I have de-neutralized their service(destination based priority, even though in both cases, it's the source of the packets we care about) by allowing dedicated bandwidth and lower latency to their cloud. > No, you have not de-neutralized their service. You have improved access asymmetrically. You haven't de-neutralized their service until you REFUSE to create a private peer with Yahoo on the same terms as Google, even assuming we stick to your rather byzantine definition of neutrality. There is a difference between neutrality and symmetry. > Also, let's not forget that the design of many p2p programs were specifically designed to ignore and bypass congestion controls... ie, screw other apps, I will take every bit of bandwidth I can get. This type of behavior causes p2p to have higher priority than other apps in a network that has no traffic prioritized. > Again, this is not part of the neutrality debate, it is a separate operational concern. Network neutrality is not about making sure every user gets a fair shake from every protocol. It's about making sure that source/destination pairs are not subject to divergent priorities on shared links. > While I agree that traffic type prioritization would be preferred over destination based priorities, it often isn't feasible with hardware. Understanding the amount of traffic between your customers and a content provider helps you decide which content providers might be prioritized to give an overall service increase to your customer base. > You're talking about different kinds of prioritization. Nobody is objecting to the idea of building out capacity and peering to places it makes sense. What people are objecting to is the idea that their upstream provider could take a bribe from a content provider in order to reduce the quality of service to their customers trying to reach other content providers. > The fact that a content provider would even pay an ISP, is a high indicator that the content provider is sending a high load of traffic to the ISP, and bandwidth constraints are an issue with the service. Video and voice, in particular, should always try and have precedence over p2p, as they completely break and become unusable, where p2p will just be forced to move slower. > Not necessarily. It might just mean that the traffic they are sending is sufficiently lucrative that it is worth subsidizing. It might mean that the content provider believes they can gain an (anti-)competitive advantage by reducing the quality of the user experience for subscribers that are going to their competitors. You keep coming back to this anti-p2p-centric rant, but, that's got almost nothing to do with the issue everyone else is attempting to discuss. >>> From a false assumption follows false conclusions. > > Not really. It's not a neutral world. Private peering is by no means neutral. The provider that does enough traffic with google to warrant a private peering will have better service levels than the smaller guy who has to take the public paths. You view net neutrality as customers within an ISP, while I view it as a provider within a network of providers. > Private peering is completely neutral IF it is available on identical terms and conditions to all players. It won't be symmetrical, but, it is neutral. Again, there is a difference between symmetry and neutrality. The world is not symmetrical. There is no reason it cannot or should not be neutral. In fact, there is good argument that being non-neutral is a violation of the Sherman anti-trust act. > The levels of service and pricing I can maintain as a rural ISP can't be compared to the metropolitan ISPs. A west coast ISP won't have the same level of service as an east coast ISP when dealing with geographical based content. We could take it to the international scale, where countries don't have equal service levels to content. > Again, you are talking about symmetry and mistaking that for neutrality. Neutrality is about whether or not everyone faces a consistent set of terms and conditions, not identical service or traffic levels. Neutrality is about letting the customer decide which content they want, not the ISP and expecting the ISP to be a fair broker in connecting customers to content. >> >> Why do you feel it's true that net-neutrality treads on private (or even public) peering, or content delivery platforms? In my understanding, they are two separate topics: Net (non)-neutrality is literally about prioritizing different packets on the *same* wire based on whether the destination or source is from an ACL of IPs. IE this link is congested, Netflix sends me a check every month, send their packets before the ones from Hulu and Youtube. The act of sending traffic down a different link directly to a peers' network does not affect the neutrality of either party one iota - in fact, it works to solve the congested link problem (Look! Adding capacity fixed it!). >> > So you are saying, it's perfectly okay to improve one service over another by adding bandwidth directly to that service, but it's unacceptable to prioritize it's traffic on congested links (which effectively adds more bandwidth for that service). It's the same thing, using two different methods. > Only so long as you are willing to add bandwidth to the other service(s) on the same terms and conditions as the one service. Yes. The former is adding capacity to meet demand. The latter is not effectively adding bandwidth, it is reducing bandwidth for one to reward the other. In the former case, you are not penalizing other services, you are improving one. In the latter case, you are improving one service at the expense of all others. It's the expense of all others part that people have a problem with. > If we consider all bandwidth available between the customer and content (and consider latency as well, as it has an effect on the traffic, especially during congestion), a private peer dedicates bandwidth to content the same as prioritizing it's traffic. If anything, the private peer provides even more bandwidth. > The private peer doesn't do this by reducing the available bandwidth for the other services. > ISP has 2xDS3 available for bandwidth total. Netflix traffic is 20mb/s. Bandwidth is considered saturated. > > 1) 45mb public + 45 mb private = 90mb w/ 45mb prioritized traffic due to private peering > > 2) 90mb public = 90mb w/ 20mb prioritized traffic via destination prioritization (actual usage) > > It appears that the second is a better deal. The fact that netflix got better service levels was an ISP decision. By using prioritization on shared pipes, it actually gave customers more bandwidth than using separate pipes. > Fiction. The way this would work in the real world (and what people are objecting to) is that the ISP would transition from 1) 90mb public with no prioritization to 2) 90mb public with N mb prioritized via destination where N is the number of mbps that the destination wanted to pay for. More importantly, it's not the 90mb public circuits where this is the real concern. The real concern is on the shared customer infrastructure side closer to the end-user where it's, say, 45mbps to the DSLAM going form 45mbps public to 45mbps public with 20mbps prioritized for content-provider-A while users trying to use content-provider-B get a degraded experience compared to A if their neighbors are using A. (Hence my belief that this is already a Sherman Anti-Trust issue). >> The ethics of path distances, peering relationships and vector routing, while interesting, are out of scope in a discussion of neutrality. An argument which makes this a larger issue encompassing peering and vector routing is, in my opinion, either a straw man or a red herring (depending on how well it's presented) attempt to generate a second technoethical issue in order to defeat the first one. >> > > It's a matter of viewpoint. It's convenient to talk about net-neutrality when it's scoped, but not when we widen the scope. Customer A gets better service than Customer B because he want to a site that had prioritization. Never mind that while they fight over the saturated link, Customer C beat both of them because he was on a separate segment that wasn't saturated. All 3 paid the same amount of money. C > A > B, yet C doesn't fall into this net-neutrality discussion, and the provider, who wants to keep customers, has more C customers than A, and more A customers than B, so B is the most expendable. > No, it's more a matter of failing to understand the difference between neutrality and symmetry. Neutrality means everyone faces the same odds and the same terms and conditions. It means that amongst the other customers sharing the same ISP infrastructure we are all treated fairly and consistently. It does not mean symmetry. It means that you are not artificially penalizing access to content providers that are not paying you in order to prioritize access to content providers that are. > My viewpoint is that of an ISP, and as such, I think of net-neutrality at a level above some last mile that's saturated at some other ISP. > Apparently not an ISP that I would subscribe to. Owen From jcdill.lists at gmail.com Fri Sep 17 19:18:50 2010 From: jcdill.lists at gmail.com (JC Dill) Date: Fri, 17 Sep 2010 12:18:50 -0700 Subject: Did Internet Founders Actually Anticipate Paid, Prioritized Traffic? In-Reply-To: <4C939071.6090405@brightok.net> References: <9CBEC49C-9106-4C7C-AC92-8C525AD9AEBE@semihuman.com> <5A6D953473350C4B9995546AFE9939EE0A52AD92@RWC-EX1.corp.seven.com> <20100916.212821.74712800.sthaug@nethelp.no> <4C928391.4050701@brightok.net> <8C26A4FDAE599041A13EB499117D3C28405E0809@ex-mb-2.corp.atlasnetworks.us> <4C937192.2090603@brightok.net> <4C939071.6090405@brightok.net> Message-ID: <4C93BF1A.1090703@gmail.com> Jack Bates wrote: > > Is consumer grade bandwidth not deprioritised to business grade > bandwidth? No. Today a provider doesn't move packets *within their network* faster or slower based on if the recipient is a consumer or business customer. Today, all providers move all packets as fast as they can be moved on the links each customer has contracted for service on. (If you know of an exception to this practice, today, I'd love to see cites.) The usual congestion point is the end-user customer's line, and the customer can only receive packets as fast as their line allows but all packets are allowed over the customer's line with equal priority. There may also be congestion on backbone ingress lines, but again all packets are allowed over each of those lines with equal priority. Rarely, there is congestion within the network - not by design but (usually) due to equipment failure. Even then, all traffic is (usually) allowed thru with equal priority. I don't know of any networks that intentionally design their networks with interior systems that prioritize traffic thru their network. It doesn't pay. In the long run it's cheaper and easier to simply upgrade capacity than to figure out some way to delay some packets while letting others thru. Prioritization necessarily involves moving some traffic slower (because you can't move traffic faster) than some link (within the provider's network) allows, to allow "priority" traffic to more fully utilize the link while the other (non-priority) traffic is slowed. It effectively creates congestion points within the provider's network, if none existed prior to implementing the prioritization scheme. "I encourage all my competitors to do that." jc From owen at delong.com Fri Sep 17 19:22:05 2010 From: owen at delong.com (Owen DeLong) Date: Fri, 17 Sep 2010 12:22:05 -0700 Subject: Did Internet Founders Actually Anticipate Paid, Prioritized Traffic? In-Reply-To: <1009171644.AA02827@ivan.Harhan.ORG> References: <1009171644.AA02827@ivan.Harhan.ORG> Message-ID: <32CBFCBE-D686-4446-8C1F-7C30410D9939@delong.com> On Sep 17, 2010, at 9:44 AM, Michael Sokolov wrote: > Leo Bicknell wrote: > >> There really isn't a lot of choice, 2 providers, and some minor choice >> in how much speed you want to pay for with each one. > > Does that mean no CLECs like Covad or DSL.net who colocate in the AT&T > CO, rent unbundled dry copper pairs and take it up from there themselves? > > Does that mean no ISPs who buy/rent last+middle mile transport from AT&T > ADSL network at Layer 2 (ATM) and provide their own IP layer? > > MS In many metros, yes. Owen From netfortius at gmail.com Fri Sep 17 19:28:34 2010 From: netfortius at gmail.com (Stefan) Date: Fri, 17 Sep 2010 14:28:34 -0500 Subject: Netflow Tool In-Reply-To: <8E440D28-42C6-4875-8E0A-D9E3D9E8DF41@gmail.com> References: <8E440D28-42C6-4875-8E0A-D9E3D9E8DF41@gmail.com> Message-ID: Always liked Luca Deri's set of solutions: http://www.ntop.org/news.php (not necessarily for netflow, exclusiovely) ***Stefan Mititelu http://twitter.com/netfortius http://www.linkedin.com/in/netfortius On Fri, Sep 17, 2010 at 1:49 PM, Mike Gatti wrote: > Anyone out there using a good netflow collector that has the capability > data to export to CSV? > Open Source would be best, but any suggestions are welcome. > > Thanks, > =+=+=+=+=+=+=+=+=+=+=+=+= > Michael Gatti > cell.703.347.4412 > ekim.ittag at gmail.com > =+=+=+=+=+=+=+=+=+=+=+=+= > > > > > From regnauld at nsrc.org Fri Sep 17 19:33:43 2010 From: regnauld at nsrc.org (Phil Regnauld) Date: Fri, 17 Sep 2010 21:33:43 +0200 Subject: Netflow Tool In-Reply-To: References: <8E440D28-42C6-4875-8E0A-D9E3D9E8DF41@gmail.com> Message-ID: On 17/09/2010, at 21.06, Everton Marques wrote: > > nfdump with custom output. > > Custom output format: -o fmt:.. > This is the most flexibel format, as you can specify yourself how the output > looks like. The output format is defined using element tags as well as plain > ascii text. > > http://nfdump.sourceforge.net/ > > Everton And to complement that: - nfsen - netflow dashboard - pmGraph The first one relies on nfdump, and offers a nice drill down web based analysis tool with the nifty feature that it shows the nfdump commands to be run on the cli to obtain the data output used to represent the current interval Haven't tried the second one yet, but it uses postgresql to store samples. Might be easy to dump csv from that. Beware though of table growth. Pmgraph is developed by aptivate.org and I'm sure Chris Wilson will have something good to say about it :) Sorry for no URLs, using big fingers on small Iphone. From scott at sberkman.net Fri Sep 17 19:45:08 2010 From: scott at sberkman.net (Scott Berkman) Date: Fri, 17 Sep 2010 15:45:08 -0400 Subject: Netflow Tool In-Reply-To: <8E440D28-42C6-4875-8E0A-D9E3D9E8DF41@gmail.com> References: <8E440D28-42C6-4875-8E0A-D9E3D9E8DF41@gmail.com> Message-ID: <01b101cb56a0$d6431df0$82c959d0$@net> If you want something scalable and commercial (read: with support) check out these guys, I have been using it for a while and it has tons of features and very flexible reporting (including exports to PDF, CSV, etc): http://www.netflowauditor.com/ They have a free version as well with limits. -Scott -----Original Message----- From: Mike Gatti [mailto:ekim.ittag at gmail.com] Sent: Friday, September 17, 2010 2:50 PM To: nanog at nanog.org Subject: Netflow Tool Anyone out there using a good netflow collector that has the capability data to export to CSV? Open Source would be best, but any suggestions are welcome. Thanks, =+=+=+=+=+=+=+=+=+=+=+=+= Michael Gatti cell.703.347.4412 ekim.ittag at gmail.com =+=+=+=+=+=+=+=+=+=+=+=+= From sparctacus at gmail.com Fri Sep 17 19:56:25 2010 From: sparctacus at gmail.com (Bryan Irvine) Date: Fri, 17 Sep 2010 12:56:25 -0700 Subject: Netflow Tool In-Reply-To: <01b101cb56a0$d6431df0$82c959d0$@net> References: <8E440D28-42C6-4875-8E0A-D9E3D9E8DF41@gmail.com> <01b101cb56a0$d6431df0$82c959d0$@net> Message-ID: If you want yours to come with rap videos look at scrutinizer (no I've not ever used it) http://www.youtube.com/watch?v=uUPkGvdXDIM http://www.youtube.com/watch?v=ilxknbKJ0Pc On Fri, Sep 17, 2010 at 12:45 PM, Scott Berkman wrote: > If you want something scalable and commercial (read: with support) check out > these guys, I have been using it for a while and it has tons of features and > very flexible reporting (including exports to PDF, CSV, etc): > > http://www.netflowauditor.com/ > > They have a free version as well with limits. > > ? ? ? ?-Scott > > -----Original Message----- > From: Mike Gatti [mailto:ekim.ittag at gmail.com] > Sent: Friday, September 17, 2010 2:50 PM > To: nanog at nanog.org > Subject: Netflow Tool > > Anyone out there using a good netflow collector that has the capability data > to export to CSV? > Open Source would be best, but any suggestions are welcome. > > Thanks, > =+=+=+=+=+=+=+=+=+=+=+=+= > Michael Gatti > cell.703.347.4412 > ekim.ittag at gmail.com > =+=+=+=+=+=+=+=+=+=+=+=+= > > > > > > > From jeroen at mompl.net Fri Sep 17 20:10:11 2010 From: jeroen at mompl.net (Jeroen van Aart) Date: Fri, 17 Sep 2010 13:10:11 -0700 Subject: Did Internet Founders Actually Anticipate Paid, Prioritized Traffic? In-Reply-To: <5A6D953473350C4B9995546AFE9939EE0A52AD76@RWC-EX1.corp.seven.com> References: <5A6D953473350C4B9995546AFE9939EE0A52AD76@RWC-EX1.corp.seven.com> Message-ID: <4C93CB23.9060903@mompl.net> George Bonser wrote: > I believe a network should be able to sell priotitization at the edge, > but not in the core. I have no problem with Y!, for example, paying a > network to be prioritized ahead of bit torrent on the segment to the end Considering yahoo (as any other big freemailer) is (unwillingly for the most part) facilitating a lot of spam traffic this would mean a lot of spam traffic gets prioritised. I can see that as an undesirable and unfortunate side effect. Regards, Jeroen -- http://goldmark.org/jeff/stupid-disclaimers/ http://linuxmafia.com/~rick/faq/plural-of-virus.html From jbates at brightok.net Fri Sep 17 20:21:05 2010 From: jbates at brightok.net (Jack Bates) Date: Fri, 17 Sep 2010 15:21:05 -0500 Subject: Did Internet Founders Actually Anticipate Paid, Prioritized Traffic? In-Reply-To: <0CB6A373-7372-41E2-A896-B27E0F64BB67@delong.com> References: <9CBEC49C-9106-4C7C-AC92-8C525AD9AEBE@semihuman.com> <5A6D953473350C4B9995546AFE9939EE0A52AD92@RWC-EX1.corp.seven.com> <20100916.212821.74712800.sthaug@nethelp.no> <4C928391.4050701@brightok.net> <8C26A4FDAE599041A13EB499117D3C28405E0809@ex-mb-2.corp.atlasnetworks.us> <4C937192.2090603@brightok.net> <0CB6A373-7372-41E2-A896-B27E0F64BB67@delong.com> Message-ID: <4C93CDB1.5070807@brightok.net> On 9/17/2010 2:08 PM, Owen DeLong wrote: > Again, you are talking about symmetry and mistaking that for neutrality. > > Neutrality is about whether or not everyone faces a consistent set of terms and conditions, not identical service or traffic levels. > Charging content providers for higher class service is perfectly neutral by your definition. So long as you offered the same class of service to all content providers who wished to pay. > Neutrality is about letting the customer decide which content they want, not the ISP and expecting the ISP to be a fair broker > in connecting customers to content. Offering better options to content providers would be perfectly acceptable here, as well, so long as you offer it to all. > The former is adding capacity to meet demand. The latter is not effectively adding bandwidth, it is reducing bandwidth for one to > reward the other. > Which is fine, so long as you offer that class of service to all. > The way this would work in the real world (and what people are objecting to) is that the ISP would transition from > > 1) 90mb public with no prioritization > > to > > 2) 90mb public with N mb prioritized via destination where N is the number of mbps that the destination > wanted to pay for. > Except my fictional account follows real world saturation experience historically. What you are giving is considered ideal compared to breaking the 90mb up to allow separate throughput for the service, which I guarantee a provider would do for enough money; given restriction of total available bandwidth. > More importantly, it's not the 90mb public circuits where this is the real concern. The real concern is > on the shared customer infrastructure side closer to the end-user where it's, say, 45mbps to the > DSLAM going form 45mbps public to 45mbps public with 20mbps prioritized for content-provider-A > while users trying to use content-provider-B get a degraded experience compared to A if their > neighbors are using A. (Hence my belief that this is already a Sherman Anti-Trust issue). I think that only qualifies if content-provider-B doesn't care to pay for such a service, but it is available to them. > Neutrality means everyone faces the same odds and the same terms and conditions. > It means that amongst the other customers sharing the same ISP infrastructure we are > all treated fairly and consistently. All customers can access the premium and non-premium content the same. ISP based licensing by content providers seems like a bigger scam. > Apparently not an ISP that I would subscribe to. Nope. You'd probably stick with a saturated bandwidth ISP and gripe about net-neutrality because your service is slightly more piss poor than your neighbors when your neighbor happens to go to a premium site and you don't. I'll stick with not having saturation on shared links. Jack From jbates at brightok.net Fri Sep 17 20:25:36 2010 From: jbates at brightok.net (Jack Bates) Date: Fri, 17 Sep 2010 15:25:36 -0500 Subject: Did Internet Founders Actually Anticipate Paid, Prioritized Traffic? In-Reply-To: <4C93BF1A.1090703@gmail.com> References: <9CBEC49C-9106-4C7C-AC92-8C525AD9AEBE@semihuman.com> <5A6D953473350C4B9995546AFE9939EE0A52AD92@RWC-EX1.corp.seven.com> <20100916.212821.74712800.sthaug@nethelp.no> <4C928391.4050701@brightok.net> <8C26A4FDAE599041A13EB499117D3C28405E0809@ex-mb-2.corp.atlasnetworks.us> <4C937192.2090603@brightok.net> <4C939071.6090405@brightok.net> <4C93BF1A.1090703@gmail.com> Message-ID: <4C93CEC0.9050709@brightok.net> On 9/17/2010 2:18 PM, JC Dill wrote: > Jack Bates wrote: >> >> Is consumer grade bandwidth not deprioritised to business grade >> bandwidth? > > Prioritization necessarily involves moving some traffic slower (because > you can't move traffic faster) than some link (within the provider's > network) allows, to allow "priority" traffic to more fully utilize the > link while the other (non-priority) traffic is slowed. It effectively > creates congestion points within the provider's network, if none existed > prior to implementing the prioritization scheme. "I encourage all my > competitors to do that." > And yet, I'm pretty sure there are providers that have different pipes for business than they do for consumer, and probably riding some of the same physical medium. This creates saturated and unsaturated pipes, which is just as bad or worse than using QOS. The reason I'm pretty sure about it, is business circuits generally are guaranteed, while consumer are not. Jack From mike.hertrick at neovera.com Fri Sep 17 20:46:22 2010 From: mike.hertrick at neovera.com (Michael Hertrick) Date: Fri, 17 Sep 2010 16:46:22 -0400 Subject: Netflow Tool In-Reply-To: <8E440D28-42C6-4875-8E0A-D9E3D9E8DF41@gmail.com> References: <8E440D28-42C6-4875-8E0A-D9E3D9E8DF41@gmail.com> Message-ID: <4C93D39E.4040809@neovera.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Mike Gatti wrote: > Anyone out there using a good netflow collector that has the capability data to export to CSV? > Open Source would be best, but any suggestions are welcome. There are so many ways to do it. Once you capture the flow data and store it in raw files, it's just a matter of filtering and converting the data to whatever format you want. The flow-tools suite has everything you'd need if you wanted to write some scripts of your own. For example, flow-export takes a raw flow file as input and can output in various formats, including ASCII CSV. See `man flow-tools` for more information on flow-export and other useful flow tools. That said, I'm using a variation of this setup, from Robert S. Galloway: http://www.dynamicnetworks.us/netflow/ If you set it up as documented by Mr. Galloway, you'll end up with your netflow data (IIRC, just networks, octets, and packets) organized into various RRD files, depending on how you set up CUFlow.cf. For example, one RRD file per customer. By default, flowscan will delete the raw flow files after it parses them into RRDs. Optionally, you can retain your raw flow files by creating a "saved" directory in your flows path (see flowscan docs). For visualization, I import the RRD files into Cacti. For CSV output I wrote a perl script. It pulls data from the resulting RRD files, computes the 95th percentile(s), among other things, and e-mails the CSV(s) to the appropriate people at the appropriate times. Like I said, though, there are so many ways to do it. The way you need to do it will depend on what you're trying to get out of the netflow data. Regards, Michael Hertrick Neovera, Inc. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkyT05oACgkQcJVdtfpkLb85lQCfTBLcpfZMxqszfHNFUV7opFVj 1DQAoI0wGv9NgefnwDpTv5e2+BDoMQbV =Hzrs -----END PGP SIGNATURE----- From nonobvious at gmail.com Fri Sep 17 21:12:54 2010 From: nonobvious at gmail.com (Bill Stewart) Date: Fri, 17 Sep 2010 14:12:54 -0700 Subject: Did Internet Founders Actually Anticipate Paid, Prioritized Traffic? In-Reply-To: <67B4FDC4-295F-4242-B622-B4C4203B5C03@cs.columbia.edu> References: <19598.25043.581492.654328@world.std.com> <8626EF19-F165-4FDE-B7CF-9F67A03CC7D3@cisco.com> <19600.8632.814275.641127@world.std.com> <67B4FDC4-295F-4242-B622-B4C4203B5C03@cs.columbia.edu> Message-ID: On Tue, Sep 14, 2010 at 6:51 PM, Steven Bellovin wrote: > No, they bought AT&T, which [...] ?But yes, SBC is the controlling piece of the new AT&T. > > As for the two /8s -- not quite. ?Back in the 1980s, AT&T got 12/8. ?We soon learned that we couldn't make good use of it, since multiple levels of subnetting didn't exist. ?We offered it back to Postel in exchange for 135/8 -- i.e., the equivalent in class B space -- but Postel said to keep 12/8 since no one else could use it, either. ?This was all long before addresses were tight. ?When AT&T decided to go into the ISP business, circa 1995, 12/8 was still lying around, unused except for a security experiment I was running.* ? ?However, a good chunk of 135/8 went to Lucent (now Alcatel-Lucent) in 1996, though I don't know how much. ---- ? ? ? ? ? ?? Thanks;? ?? Bill Note that this isn't my regular email account - It's still experimental so far. And Google probably logs and indexes everything you send it. From nonobvious at gmail.com Fri Sep 17 21:20:46 2010 From: nonobvious at gmail.com (Bill Stewart) Date: Fri, 17 Sep 2010 14:20:46 -0700 Subject: Did Internet Founders Actually Anticipate Paid, Prioritized Traffic? In-Reply-To: References: <19598.25043.581492.654328@world.std.com> <8626EF19-F165-4FDE-B7CF-9F67A03CC7D3@cisco.com> <19600.8632.814275.641127@world.std.com> <67B4FDC4-295F-4242-B622-B4C4203B5C03@cs.columbia.edu> Message-ID: Sorry, fat-fingered something when I was trying to edit. On Fri, Sep 17, 2010 at 2:12 PM, Bill Stewart wrote: > On Tue, Sep 14, 2010 at 6:51 PM, Steven Bellovin wrote: >> No, they bought AT&T, which [...] ?But yes, SBC is the controlling piece of the new AT&T. Most of the wide-area ISP network is the old AT&T, while much of the consumer broadband grew out of the SBC DSL side. >> As for the two /8s -- not quite. ?Back in the 1980s, AT&T got 12/8. ?We soon learned that we couldn't make good use of it, since multiple levels of subnetting didn't exist. ?We offered it back to Postel in exchange for 135/8 -- i.e., the equivalent in class B space -- but Postel said to keep 12/8 since no one else could use it, either. ?This was all long before addresses were tight. ?When AT&T decided to go into the ISP business, circa 1995, 12/8 was still lying around, unused except for a security experiment I was running.* ? ?However, a good chunk of 135/8 went to Lucent (now Alcatel-Lucent) in 1996, though I don't know how much. The AT&T bits kept some fraction of 135; I don't know how much without dredging through ARIN Whois, but at least 135.63/16 is on my desktop. If I remember correctly, which is unlikely at this point, 12/8 was the Murray Hill Cray's Hyperchannel network, which I'd heard didn't know how to do subnetting except on classful boundaries, so it could happily handle 16M hosts on its Class A, and in fact only had two or three. -- ---- ? ? ? ? ? ?? Thanks;? ?? Bill Note that this isn't my regular email account - It's still experimental so far. And Google probably logs and indexes everything you send it. From pstewart at nexicomgroup.net Fri Sep 17 21:34:24 2010 From: pstewart at nexicomgroup.net (Paul Stewart) Date: Fri, 17 Sep 2010 17:34:24 -0400 Subject: Netflow Tool In-Reply-To: References: <8E440D28-42C6-4875-8E0A-D9E3D9E8DF41@gmail.com><01b101cb56a0$d6431df0$82c959d0$@net> Message-ID: We've ran Scrutizer and also Netflow Auditor (also a few others) ... they are ok for "smaller" traffic levels (depending of course on sampling rates). None of them held up though to our expectations and we ended up going with Arbor Peakflow and been extremely happy ever since. I'd definitely suggest a trial of anything you are considering - we ran out and bought package after package and it didn't work out for us ;) Paul -----Original Message----- From: Bryan Irvine [mailto:sparctacus at gmail.com] Sent: September-17-10 3:56 PM To: Scott Berkman Cc: nanog at nanog.org Subject: Re: Netflow Tool If you want yours to come with rap videos look at scrutinizer (no I've not ever used it) http://www.youtube.com/watch?v=uUPkGvdXDIM http://www.youtube.com/watch?v=ilxknbKJ0Pc On Fri, Sep 17, 2010 at 12:45 PM, Scott Berkman wrote: > If you want something scalable and commercial (read: with support) check out > these guys, I have been using it for a while and it has tons of features and > very flexible reporting (including exports to PDF, CSV, etc): > > http://www.netflowauditor.com/ > > They have a free version as well with limits. > > ? ? ? ?-Scott > > -----Original Message----- > From: Mike Gatti [mailto:ekim.ittag at gmail.com] > Sent: Friday, September 17, 2010 2:50 PM > To: nanog at nanog.org > Subject: Netflow Tool > > Anyone out there using a good netflow collector that has the capability data > to export to CSV? > Open Source would be best, but any suggestions are welcome. > > Thanks, > =+=+=+=+=+=+=+=+=+=+=+=+= > Michael Gatti > cell.703.347.4412 > ekim.ittag at gmail.com > =+=+=+=+=+=+=+=+=+=+=+=+= > > > > > > > From owen at delong.com Fri Sep 17 21:43:56 2010 From: owen at delong.com (Owen DeLong) Date: Fri, 17 Sep 2010 14:43:56 -0700 Subject: Did Internet Founders Actually Anticipate Paid, Prioritized Traffic? In-Reply-To: <4C93CDB1.5070807@brightok.net> References: <9CBEC49C-9106-4C7C-AC92-8C525AD9AEBE@semihuman.com> <5A6D953473350C4B9995546AFE9939EE0A52AD92@RWC-EX1.corp.seven.com> <20100916.212821.74712800.sthaug@nethelp.no> <4C928391.4050701@brightok.net> <8C26A4FDAE599041A13EB499117D3C28405E0809@ex-mb-2.corp.atlasnetworks.us> <4C937192.2090603@brightok.net> <0CB6A373-7372-41E2-A896-B27E0F64BB67@delong.com> <4C93CDB1.5070807@brightok.net> Message-ID: On Sep 17, 2010, at 1:21 PM, Jack Bates wrote: > On 9/17/2010 2:08 PM, Owen DeLong wrote: >> Again, you are talking about symmetry and mistaking that for neutrality. >> >> Neutrality is about whether or not everyone faces a consistent set of terms and conditions, not identical service or traffic levels. >> > > Charging content providers for higher class service is perfectly neutral by your definition. So long as you offered the same class of service to all content providers who wished to pay. > Charging them for higher class service on the circuits which connect directly to them is neutral. Charging them to effect the profile of the circuits directly connected to your other customers is non-neutral. >> Neutrality is about letting the customer decide which content they want, not the ISP and expecting the ISP to be a fair broker >> in connecting customers to content. > > Offering better options to content providers would be perfectly acceptable here, as well, so long as you offer it to all. > Again, nobody is opposing offering better connectivity to content providers. What they are opposing is selling content providers the right to screw your customers that choose to use said content providers competitors. >> The former is adding capacity to meet demand. The latter is not effectively adding bandwidth, it is reducing bandwidth for one to >> reward the other. >> > > Which is fine, so long as you offer that class of service to all. > You can't offer that class of service to all, and, even if you do, no, it's no neutral when you do it that way. >> The way this would work in the real world (and what people are objecting to) is that the ISP would transition from >> >> 1) 90mb public with no prioritization >> >> to >> >> 2) 90mb public with N mb prioritized via destination where N is the number of mbps that the destination >> wanted to pay for. >> > > Except my fictional account follows real world saturation experience historically. What you are giving is considered ideal compared to breaking the 90mb up to allow separate throughput for the service, which I guarantee a provider would do for enough money; given restriction of total available bandwidth. > Total available bandwidth isn't what AT&T is pushing the FCC to allow them to carve up this way. AT&T is pushing for the right to sell (or select) content providers prioritized bandwidth closer to the consumer tail-circuit. >> More importantly, it's not the 90mb public circuits where this is the real concern. The real concern is >> on the shared customer infrastructure side closer to the end-user where it's, say, 45mbps to the >> DSLAM going form 45mbps public to 45mbps public with 20mbps prioritized for content-provider-A >> while users trying to use content-provider-B get a degraded experience compared to A if their >> neighbors are using A. (Hence my belief that this is already a Sherman Anti-Trust issue). > > I think that only qualifies if content-provider-B doesn't care to pay for such a service, but it is available to them. > What if the service simply isn't available to content-provider-B because content-provider-A is a relater party to said ISP or said ISP simply chooses not to offer it on a neutral basis? (Which is exactly what AT&T has stated they want to do.) >> Neutrality means everyone faces the same odds and the same terms and conditions. >> It means that amongst the other customers sharing the same ISP infrastructure we are >> all treated fairly and consistently. > > All customers can access the premium and non-premium content the same. ISP based licensing by content providers seems like a bigger scam. > I'm not sure what you mean by "ISP based licensing by content providers". >> Apparently not an ISP that I would subscribe to. > > Nope. You'd probably stick with a saturated bandwidth ISP and gripe about net-neutrality because your service is slightly more piss poor than your neighbors when your neighbor happens to go to a premium site and you don't. I'll stick with not having saturation on shared links. > Actually, no. I've got good unsaturated service from both of the ISPs providing circuits into my house and from the upstreams that I use their circuits to reach for my real routing. (I'm unusual... I use Comcast and DSL to provide layer 2 transport to colo facilities where I have routers. I then use the routers in the colo facilties to advertise my addresses into BGP and trade my real packets. As far as Comcast and my DSL provider are concerned, I'm just running a whole lot of protocol 43 traffic to a very small set of destinations.) I use the two providers in question because they are, generally, neutral in their approach and do not play funky QoS games with my traffic. Owen From cidr-report at potaroo.net Fri Sep 17 22:00:02 2010 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 17 Sep 2010 22:00:02 GMT Subject: BGP Update Report Message-ID: <201009172200.o8HM02Lk007553@wattle.apnic.net> BGP Update Report Interval: 09-Sep-10 -to- 16-Sep-10 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS34984 31696 1.3% 84.7 -- TELLCOM-AS Tellcom Iletisim Hizmetleri 2 - AS3464 23020 0.9% 511.6 -- ASC-NET - Alabama Supercomputer Network 3 - AS5536 22242 0.9% 200.4 -- Internet-Egypt 4 - AS32528 17289 0.7% 2161.1 -- ABBOTT Abbot Labs 5 - AS8151 16120 0.6% 9.0 -- Uninet S.A. de C.V. 6 - AS6389 15537 0.6% 4.1 -- BELLSOUTH-NET-BLK - BellSouth.net Inc. 7 - AS35931 15308 0.6% 2551.3 -- ARCHIPELAGO - ARCHIPELAGO HOLDINGS INC 8 - AS4323 14972 0.6% 3.3 -- TWTC - tw telecom holdings, inc. 9 - AS8866 13592 0.5% 33.6 -- BTC-AS Bulgarian Telecommunication Company Plc. 10 - AS7545 12945 0.5% 9.3 -- TPG-INTERNET-AP TPG Internet Pty Ltd 11 - AS5668 12042 0.5% 10.6 -- AS-5668 - CenturyTel Internet Holdings, Inc. 12 - AS42910 11748 0.5% 107.8 -- SADECEHOSTING-COM Sadecehosting-Com 13 - AS9829 11678 0.5% 14.2 -- BSNL-NIB National Internet Backbone 14 - AS16718 11004 0.4% 393.0 -- EMBARQ-HMBL - Embarq Corporation 15 - AS3816 10912 0.4% 22.6 -- COLOMBIA TELECOMUNICACIONES S.A. ESP 16 - AS17488 10679 0.4% 7.5 -- HATHWAY-NET-AP Hathway IP Over Cable Internet 17 - AS24560 10496 0.4% 10.2 -- AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services 18 - AS17974 10315 0.4% 8.4 -- TELKOMNET-AS2-AP PT Telekomunikasi Indonesia 19 - AS8452 10159 0.4% 8.7 -- TE-AS TE-AS 20 - AS5800 9783 0.4% 46.1 -- DNIC-ASBLK-05800-06055 - DoD Network Information Center TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS35931 15308 0.6% 2551.3 -- ARCHIPELAGO - ARCHIPELAGO HOLDINGS INC 2 - AS32528 17289 0.7% 2161.1 -- ABBOTT Abbot Labs 3 - AS37204 8943 0.4% 894.3 -- TELONE 4 - AS1959 4246 0.2% 849.2 -- DMSLABNET - DoD Network Information Center 5 - AS15984 830 0.0% 830.0 -- The Joint-Stock Commercial Bank CentroCredit. 6 - AS21017 6570 0.3% 657.0 -- VSI-AS VSI AS 7 - AS11384 653 0.0% 653.0 -- 8 - AS50150 653 0.0% 653.0 -- LONGLINE-AS LongLine SRL 9 - AS11613 584 0.0% 584.0 -- U-SAVE - U-Save Auto Rental of America, Inc. 10 - AS17029 1125 0.0% 562.5 -- CHP-NET - California Highway Patrol 11 - AS27859 555 0.0% 555.0 -- Internet Systems Consortium 12 - AS18163 2158 0.1% 539.5 -- JINJU18163-AS-KR jinju national university 13 - AS3464 23020 0.9% 511.6 -- ASC-NET - Alabama Supercomputer Network 14 - AS6755 2037 0.1% 509.2 -- ASN - TURNET 15 - AS16861 480 0.0% 480.0 -- REVELEX - Revelex.com 16 - AS49879 472 0.0% 472.0 -- HOSTHANE ISIK Bilgisayar Internet ve Yayincilik Hizmetleri 17 - AS13880 7173 0.3% 421.9 -- ACI-AS - american century investments 18 - AS45600 394 0.0% 394.0 -- UPM-AS-AP University of the Philippines, Manila 19 - AS16718 11004 0.4% 393.0 -- EMBARQ-HMBL - Embarq Corporation 20 - AS51361 383 0.0% 383.0 -- ALARMNET-ASN Alarmnet Guvenlik Hizmetleri A.S TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 129.66.128.0/17 11412 0.4% AS3464 -- ASC-NET - Alabama Supercomputer Network 2 - 129.66.0.0/17 11402 0.4% AS3464 -- ASC-NET - Alabama Supercomputer Network 3 - 63.211.68.0/22 9483 0.4% AS35931 -- ARCHIPELAGO - ARCHIPELAGO HOLDINGS INC 4 - 130.36.34.0/24 8633 0.3% AS32528 -- ABBOTT Abbot Labs 5 - 130.36.35.0/24 8630 0.3% AS32528 -- ABBOTT Abbot Labs 6 - 195.39.181.0/24 8295 0.3% AS6755 -- ASN - TURNET AS9155 -- QNET QualityNet AS number 7 - 198.140.43.0/24 5774 0.2% AS35931 -- ARCHIPELAGO - ARCHIPELAGO HOLDINGS INC 8 - 190.65.228.0/22 5534 0.2% AS3816 -- COLOMBIA TELECOMUNICACIONES S.A. ESP 9 - 64.86.26.0/23 4479 0.2% AS37204 -- TELONE 10 - 95.32.192.0/18 3589 0.1% AS21017 -- VSI-AS VSI AS 11 - 216.126.136.0/22 3287 0.1% AS6316 -- AS-PAETEC-NET - PaeTec Communications, Inc. 12 - 148.204.141.0/24 3280 0.1% AS8151 -- Uninet S.A. de C.V. 13 - 196.29.32.0/21 3150 0.1% AS37204 -- TELONE 14 - 206.184.16.0/24 3008 0.1% AS174 -- COGENT Cogent/PSI 15 - 95.32.128.0/18 2941 0.1% AS21017 -- VSI-AS VSI AS 16 - 216.118.245.0/24 2330 0.1% AS22150 -- CARRIERHOUSE - Carrierhouse Corp. AS25747 -- VSC-SATELLITE-CO - VSC Satellite Co. 17 - 202.92.235.0/24 2238 0.1% AS9498 -- BBIL-AP BHARTI Airtel Ltd. 18 - 202.167.253.0/24 1738 0.1% AS17819 -- ASN-EQUINIX-AP Equinix Asia Pacific 19 - 202.177.223.0/24 1738 0.1% AS17819 -- ASN-EQUINIX-AP Equinix Asia Pacific 20 - 62.193.117.0/24 1510 0.1% AS5536 -- Internet-Egypt 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 Sep 17 22:00:00 2010 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 17 Sep 2010 22:00:00 GMT Subject: The Cidr Report Message-ID: <201009172200.o8HM000I007545@wattle.apnic.net> This report has been generated at Fri Sep 17 21:11:58 2010 AEST. The report analyses the BGP Routing Table of AS2.0 router and generates a report on aggregation potential within the table. Check http://www.cidr-report.org for a current version of this report. Recent Table History Date Prefixes CIDR Agg 10-09-10 335938 207551 11-09-10 336408 207230 12-09-10 336564 206952 13-09-10 336191 208106 14-09-10 336372 207484 15-09-10 336810 207396 16-09-10 336289 207762 17-09-10 336284 207815 AS Summary 35426 Number of ASes in routing system 15084 Number of ASes announcing only one prefix 4460 Largest number of prefixes announced by an AS AS4323 : TWTC - tw telecom holdings, inc. 97386240 Largest address span announced by an AS (/32s) AS4134 : CHINANET-BACKBONE No.31,Jin-rong Street 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'). --- 17Sep10 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 336388 207735 128653 38.2% All ASes AS6389 3793 282 3511 92.6% BELLSOUTH-NET-BLK - BellSouth.net Inc. AS4323 4460 1927 2533 56.8% TWTC - tw telecom holdings, inc. AS19262 1816 286 1530 84.3% VZGNI-TRANSIT - Verizon Online LLC AS4766 1860 515 1345 72.3% KIXS-AS-KR Korea Telecom AS22773 1193 66 1127 94.5% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. AS17488 1346 285 1061 78.8% HATHWAY-NET-AP Hathway IP Over Cable Internet AS4755 1346 301 1045 77.6% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP AS5668 1131 89 1042 92.1% AS-5668 - CenturyTel Internet Holdings, Inc. AS18566 1087 63 1024 94.2% COVAD - Covad Communications Co. AS10620 1319 343 976 74.0% Telmex Colombia S.A. AS6478 1340 412 928 69.3% ATT-INTERNET3 - AT&T WorldNet Services AS13343 1510 610 900 59.6% SCRR-13343 - Road Runner HoldCo LLC AS1785 1793 959 834 46.5% AS-PAETEC-NET - PaeTec Communications, Inc. AS8452 1154 434 720 62.4% TE-AS TE-AS AS8151 1381 670 711 51.5% Uninet S.A. de C.V. AS7545 1381 692 689 49.9% TPG-INTERNET-AP TPG Internet Pty Ltd AS7303 793 114 679 85.6% Telecom Argentina S.A. AS18101 879 242 637 72.5% RIL-IDC Reliance Infocom Ltd Internet Data Centre, AS4808 931 303 628 67.5% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network AS4804 677 73 604 89.2% MPX-AS Microplex PTY LTD AS7552 644 97 547 84.9% VIETEL-AS-AP Vietel Corporation AS4780 700 166 534 76.3% SEEDNET Digital United Inc. AS17676 605 76 529 87.4% GIGAINFRA Softbank BB Corp. AS7018 1458 949 509 34.9% ATT-INTERNET4 - AT&T WorldNet Services AS28573 1095 591 504 46.0% NET Servicos de Comunicao S.A. AS9443 572 76 496 86.7% INTERNETPRIMUS-AS-AP Primus Telecommunications AS14420 578 87 491 84.9% CORPORACION NACIONAL DE TELECOMUNICACIONES - CNT EP AS7011 1153 664 489 42.4% FRONTIER-AND-CITIZENS - Frontier Communications of America, Inc. AS22047 559 80 479 85.7% VTR BANDA ANCHA S.A. AS24560 1029 553 476 46.3% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services Total 39583 12005 27578 69.7% Top 30 total Possible Bogus Routes 31.0.0.0/16 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 31.1.0.0/21 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 31.1.24.0/24 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 41.222.79.0/24 AS36938 AMSCOTELECOMS Amsco Telecommunications Nigeria Limited 41.223.196.0/24 AS36990 41.223.197.0/24 AS36990 41.223.198.0/24 AS36990 41.223.199.0/24 AS36990 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV 62.61.221.0/24 AS24974 TACHYON-EU Tachyon Europe BV 64.20.80.0/20 AS40028 SPD-NETWORK-1 - SPD NETWORK 64.21.192.0/20 AS11610 INETNEBR-1 - Internet Nebraska Corporation 64.21.212.0/22 AS11610 INETNEBR-1 - Internet Nebraska Corporation 64.21.216.0/21 AS11610 INETNEBR-1 - Internet Nebraska Corporation 64.82.128.0/19 AS16617 COMMUNITYISP - CISP 64.82.160.0/19 AS16617 COMMUNITYISP - CISP 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.47.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 66.207.32.0/20 AS23011 66.230.240.0/20 AS27286 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 71.19.134.0/23 AS3313 INET-AS I.NET S.p.A. 71.19.160.0/23 AS4648 NZIX-2 Netgate 72.22.32.0/19 AS33150 72.22.61.0/24 AS33150 72.22.62.0/24 AS33150 76.77.32.0/19 AS2828 XO-AS15 - XO Communications 80.88.10.0/24 AS33774 DJAWEB 80.88.12.0/24 AS33779 wataniya-telecom-as 96.45.160.0/24 AS3257 TINET-BACKBONE Tinet SpA 96.45.161.0/24 AS3257 TINET-BACKBONE Tinet SpA 96.45.162.0/24 AS3257 TINET-BACKBONE Tinet SpA 96.45.163.0/24 AS3257 TINET-BACKBONE Tinet SpA 96.45.164.0/24 AS3257 TINET-BACKBONE Tinet SpA 96.45.165.0/24 AS3257 TINET-BACKBONE Tinet SpA 96.45.166.0/24 AS3257 TINET-BACKBONE Tinet SpA 96.45.167.0/24 AS3257 TINET-BACKBONE Tinet SpA 96.45.168.0/21 AS3257 TINET-BACKBONE Tinet SpA 96.47.48.0/20 AS3257 TINET-BACKBONE Tinet SpA 110.34.44.0/22 AS12653 COMTONET KB Impuls Hellas 110.173.64.0/19 AS37963 CNNIC-ALIBABA-CN-NET-AP Alibaba (China) Technology Co., Ltd. 116.68.136.0/21 AS28045 Pantel Communications 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.168.0/21 AS9931 CAT-AP The Communication Authoity of Thailand, CAT 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 173.225.112.0/20 AS3257 TINET-BACKBONE Tinet SpA 176.0.0.0/16 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 176.1.0.0/21 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 176.1.24.0/24 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 177.0.0.0/16 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 177.1.0.0/21 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 177.1.8.0/24 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 178.239.240.0/21 AS29119 SERVIHOSTING-AS ServiHosting Networks S.L. 178.239.248.0/21 AS29119 SERVIHOSTING-AS ServiHosting Networks S.L. 181.0.0.0/16 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 181.1.0.0/21 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 181.1.8.0/24 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 190.102.32.0/20 AS30058 ACTIVO-SYSTEMS-AS30058 ACTIVO-SYSTEMS-AS30058 192.9.0.0/16 AS11479 BRM-SUN-AS - Sun Microsystems, Inc 192.64.85.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.69.108.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.101.46.0/24 AS6503 Axtel, S.A.B. de C. V. 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.252.0/22 AS680 DFN-IP service X-WiN 192.131.233.0/24 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 192.154.32.0/19 AS81 NCREN - MCNC 192.154.64.0/19 AS81 NCREN - MCNC 192.188.208.0/20 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 196.2.224.0/22 AS24863 LINKdotNET-AS 196.6.108.0/24 AS5713 SAIX-NET 196.13.201.0/24 AS2018 TENET-1 196.13.202.0/24 AS2018 TENET-1 196.13.203.0/24 AS2018 TENET-1 196.13.204.0/24 AS2018 TENET-1 196.110.105.0/24 AS8513 SKYVISION SkyVision Network Services 196.201.248.0/24 AS30991 SAHANNET Sahannet AS Network 196.201.249.0/24 AS30991 SAHANNET Sahannet AS Network 196.201.250.0/24 AS30991 SAHANNET Sahannet AS Network 196.201.251.0/24 AS30991 SAHANNET Sahannet AS Network 196.201.253.0/24 AS30991 SAHANNET Sahannet AS Network 196.201.255.0/24 AS30991 SAHANNET Sahannet AS Network 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.51.100.0/24 AS16953 ASCENT-MEDIA-GROUP-LLC - Ascent Media Group, LLC 198.73.210.0/24 AS21570 ACI-1 - Accelerated Connections Inc. 198.74.38.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services 198.74.39.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services 198.74.40.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services 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.99.241.0/24 AS11797 AC-NIELSEN-AS AC NIELSEN 198.135.236.0/24 AS4358 XNET - XNet Information Systems, Inc. 198.161.87.0/24 AS6539 GT-BELL - Bell Canada 198.163.214.0/24 AS21804 ACCESS-SK - Access Communications Co-operative Limited 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 198.182.235.0/24 AS3356 LEVEL3 Level 3 Communications 199.10.0.0/16 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center 199.16.32.0/19 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 199.121.0.0/16 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.123.16.0/20 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.185.130.0/23 AS19662 UNISERVE-ONLINE - Uniserve On Line 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.24.73.0/24 AS26061 Equant Colombia 200.24.78.0/26 AS3549 GBLX Global Crossing Ltd. 200.24.78.64/26 AS3549 GBLX Global Crossing Ltd. 202.9.55.0/24 AS2764 AAPT AAPT Limited 202.9.57.0/24 AS2764 AAPT AAPT Limited 202.38.63.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.58.113.0/24 AS19161 202.61.75.0/24 AS9927 PHILCOMNET-PH A Multihomed ISP Company 202.66.128.0/18 AS9584 GENESIS-AP Diyixian.com Limited 202.66.160.0/19 AS9584 GENESIS-AP Diyixian.com Limited 202.66.160.0/20 AS9584 GENESIS-AP Diyixian.com Limited 202.66.176.0/20 AS9584 GENESIS-AP Diyixian.com Limited 202.66.184.0/24 AS9584 GENESIS-AP Diyixian.com Limited 202.66.186.0/24 AS9584 GENESIS-AP Diyixian.com Limited 202.66.188.0/24 AS9584 GENESIS-AP Diyixian.com Limited 202.66.189.0/24 AS9584 GENESIS-AP Diyixian.com Limited 202.66.190.0/24 AS9584 GENESIS-AP Diyixian.com Limited 202.73.144.0/20 AS4788 TMNET-AS-AP TM Net, Internet Service Provider 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.133.37.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.150.227.0/24 AS17727 NAPINFO-AS-AP PT. NAP Info Lintas Nusa 202.174.70.0/24 AS21175 WIS WIS S.A. : WIND International Services 202.174.125.0/24 AS9498 BBIL-AP BHARTI Airtel Ltd. 202.174.125.128/26 AS9498 BBIL-AP BHARTI Airtel Ltd. 202.176.1.0/24 AS9942 COMINDICO-AP SOUL Converged Communications Australia 202.179.131.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.179.133.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.179.134.0/24 AS23966 LDN-AS-PK LINKdotNET Telecom Limited 202.179.144.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.179.149.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.179.150.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 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.99.140.0/24 AS45227 VISTA-SKYDIO-PTE-LTD-AP Vista datacenter Skydio Pte Ltd 203.99.141.0/24 AS45227 VISTA-SKYDIO-PTE-LTD-AP Vista datacenter Skydio Pte 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.175.98.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 203.175.99.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 203.175.103.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 203.175.107.0/24 AS45595 PKTELECOM-AS-PK Pakistan Telecom Company Limited 203.175.110.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 203.202.238.0/24 AS45227 VISTA-SKYDIO-PTE-LTD-AP Vista datacenter Skydio Pte Ltd 204.9.216.0/23 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 204.10.232.0/21 AS33150 204.19.14.0/23 AS577 BACOM - Bell Canada 204.28.104.0/21 AS25973 MZIMA - Mzima Networks, Inc. 204.197.0.0/16 AS3356 LEVEL3 Level 3 Communications 204.209.114.0/24 AS13768 PEER1 - Peer 1 Network Inc. 204.238.70.0/24 AS36826 205.150.0.0/15 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 205.189.134.0/24 AS11814 DISTRIBUTEL-AS11814 - DISTRIBUTEL COMMUNICATIONS LTD. 205.196.24.0/22 AS33724 BIZNESSHOSTING - VOLICO 205.210.145.0/24 AS11814 DISTRIBUTEL-AS11814 - DISTRIBUTEL COMMUNICATIONS LTD. 206.72.192.0/23 AS27375 IDS-TELECOM - IDS Telecom 206.72.194.0/23 AS27375 IDS-TELECOM - IDS Telecom 206.123.129.0/24 AS10790 INREACH-AS - InReach Internet 206.180.240.0/20 AS12083 KNOLOGY-NET - Knology Holdings 206.197.184.0/24 AS23304 DATOTEL-STL-AS - Datotel LLC, a NetLabs LLC Company 207.174.131.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.132.0/23 AS26116 INDRA - Indra's Net Inc. 207.174.152.0/23 AS26116 INDRA - Indra's Net Inc. 207.174.154.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.155.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.188.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.189.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.190.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.191.0/24 AS26116 INDRA - Indra's Net Inc. 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.64.200.0/22 AS11730 CIL-ASN - Circle Internet LTD 208.64.240.0/21 AS13871 TELEBYTE-NW - Telebyte NW 208.73.4.0/22 AS27630 PREMIER - Premier Innovations, LLC 208.78.165.0/24 AS16565 208.84.76.0/22 AS18561 208.92.196.0/22 AS10929 NETELLIGENT - Netelligent Hosting Services Inc. 209.54.123.0/24 AS6062 NETPLEX - NETPLEX 209.105.224.0/19 AS20074 209.165.239.0/24 AS209 ASN-QWEST - Qwest Communications Company, LLC 209.213.0.0/20 AS33005 ELTOPIA - Eltopia.com, LLC 209.213.1.0/24 AS7849 CROCKERCOM - CROCKER COMMUNICATIONS 209.213.4.0/24 AS7849 CROCKERCOM - CROCKER COMMUNICATIONS 209.236.96.0/20 AS3257 TINET-BACKBONE Tinet SpA 210.5.128.0/20 AS4837 CHINA169-BACKBONE CNCGROUP China169 Backbone 210.56.150.0/23 AS38138 INTECH-TRANSIT-BD InTech Online Limited, INTERNET SERVICE LIMITED 210.247.224.0/19 AS7496 WEBCENTRAL-AS WebCentral 216.10.235.0/24 AS13780 NTNCOMMUNICATIONS - NTN 216.10.236.0/24 AS13780 NTNCOMMUNICATIONS - NTN 216.21.196.0/24 AS12251 INVISION - Invision.com, Inc. 216.21.201.0/24 AS12251 INVISION - Invision.com, Inc. 216.21.202.0/24 AS12251 INVISION - Invision.com, Inc. 216.21.206.0/23 AS12251 INVISION - Invision.com, Inc. 216.47.32.0/20 AS3257 TINET-BACKBONE Tinet SpA 216.58.192.0/24 AS22702 X5SOLUTIONS - X5 Solutions, Inc. 216.58.197.0/24 AS22702 X5SOLUTIONS - X5 Solutions, Inc. 216.58.200.0/24 AS18530 ISOMEDIA-1 - Isomedia 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.250.112.0/20 AS7296 ALCHEMYNET - Alchemy Communications, Inc. 216.250.116.0/24 AS36066 UNI-MARKETING-ALLIANCE - Webhost4life.com 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 bicknell at ufp.org Fri Sep 17 23:24:42 2010 From: bicknell at ufp.org (Leo Bicknell) Date: Fri, 17 Sep 2010 16:24:42 -0700 Subject: Did Internet Founders Actually Anticipate Paid, Prioritized Traffic? In-Reply-To: <1009171644.AA02827@ivan.Harhan.ORG> References: <1009171644.AA02827@ivan.Harhan.ORG> Message-ID: <20100917232442.GA46793@ussenterprise.ufp.org> In a message written on Fri, Sep 17, 2010 at 04:44:04PM +0000, Michael Sokolov wrote: > Does that mean no CLECs like Covad or DSL.net who colocate in the AT&T > CO, rent unbundled dry copper pairs and take it up from there themselves? I found someone off list with access to Megapath's "Partner Portal" where they can get the real scoop, and did that for my specific location. Short form: They can resell AT&T's lower speed ADSL (but not their top speeds) at a markup. They can resell Comcast's cable modem service at a markup. They can offer IDSL (ISDN Speeds) or SDSL from the actual CO, which they claim is 19k feet away, my google maps says 23k feet away. The estimate is I could get 768k symmetric at that distance, which would mean 1/10th the bandwidth I have now at approximately 5 times the cost I have now. So I'm sure if you're a government bean counter or AT&T lobbyest there is "competition" out of my CO, and I have options. As a consumer looking at the practical side of it I see no options, I have a Telco or Cable company, with basically the same offerings at the same speed at the same prices. YMMV, likely a lot with where you live. -- 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: 826 bytes Desc: not available URL: From jreeves at 18-30chat.net Fri Sep 17 23:34:09 2010 From: jreeves at 18-30chat.net (Jeromie Reeves) Date: Fri, 17 Sep 2010 16:34:09 -0700 Subject: Did Internet Founders Actually Anticipate Paid, Prioritized Traffic? In-Reply-To: <20100917232442.GA46793@ussenterprise.ufp.org> References: <1009171644.AA02827@ivan.Harhan.ORG> <20100917232442.GA46793@ussenterprise.ufp.org> Message-ID: I have the same problem getting decent fiber out here. They keep wanting to do a loop clear back to the other side of the state. I will jsut keep building out my towers to towns where I know I can co-lo or get QMOE at least. On Fri, Sep 17, 2010 at 4:24 PM, Leo Bicknell wrote: > In a message written on Fri, Sep 17, 2010 at 04:44:04PM +0000, Michael Sokolov wrote: >> Does that mean no CLECs like Covad or DSL.net who colocate in the AT&T >> CO, rent unbundled dry copper pairs and take it up from there themselves? > > I found someone off list with access to Megapath's "Partner Portal" > where they can get the real scoop, and did that for my specific > location. > > Short form: > ?They can resell AT&T's lower speed ADSL (but not their top speeds) > ?at a markup. > > ?They can resell Comcast's cable modem service at a markup. > > ?They can offer IDSL (ISDN Speeds) or SDSL from the actual CO, > ?which they claim is 19k feet away, my google maps says 23k feet > ?away. ?The estimate is I could get 768k symmetric at that distance, > ?which would mean 1/10th the bandwidth I have now at approximately > ?5 times the cost I have now. > > So I'm sure if you're a government bean counter or AT&T lobbyest > there is "competition" out of my CO, and I have options. ? As a > consumer looking at the practical side of it I see no options, I > have a Telco or Cable company, with basically the same offerings > at the same speed at the same prices. > > YMMV, likely a lot with where you live. > > -- > ? ? ? Leo Bicknell - bicknell at ufp.org - CCIE 3440 > ? ? ? ?PGP keys at http://www.ufp.org/~bicknell/ > From aalejandro at worldnetpr.com Sat Sep 18 00:06:09 2010 From: aalejandro at worldnetpr.com (Abel Alejandro) Date: Fri, 17 Sep 2010 20:06:09 -0400 Subject: Troubleshooting TCP performance tutorial Message-ID: <79BBBA445314D14C927525E537E603631F7B92@wnetexchg01.worldnetpr.com> Greetings, This past week I have been trying to find the root cause of tcp performance problems of a few clients that are using a third party metro Ethernet for transport. RFC2544 tests (Layer 2) and iperf using UDP give good symmetric performance almost 100% the speed of the circuit. However all kind of TCP tests result in some kind of asymmetrical deficiency, either the upstream or downstream of the client is hugely different. The latency is not a huge factor since all the metro Ethernet connections have less than 2 ms. So the question basically if is there a good tutorial or white paper for troubleshooting tcp with emphasis of using tools like Wireshark to debug and track this kind of problems. Regards, Abel. From joe at nethead.com Sat Sep 18 00:33:40 2010 From: joe at nethead.com (Joe Hamelin) Date: Fri, 17 Sep 2010 17:33:40 -0700 Subject: Troubleshooting TCP performance tutorial In-Reply-To: <79BBBA445314D14C927525E537E603631F7B92@wnetexchg01.worldnetpr.com> References: <79BBBA445314D14C927525E537E603631F7B92@wnetexchg01.worldnetpr.com> Message-ID: In a situation like yours I found Internet Core Protocols: The Definitive Guide by Eric Hall an easy to read guide to insuring that what you are seeing via wireshark. I was able to find an issue with the DF bit in a load balancer that was causing confounding headaches in a network using wireshark and this book. Walk it through the syn-ack dance and don't trust that the devices are handling it correctly. Start at one end and work your way through and insure to YOUR satisfaction that every device proscribes to the protocol. Don't rush, don't jump to conclusions. Just follow the packet. That's the best advice I can give you. http://oreilly.com/catalog/9781565925724/ -- Joe Hamelin, W7COM, Tulalip, WA, 360-474-7474 On Fri, Sep 17, 2010 at 5:06 PM, Abel Alejandro wrote: > Greetings, > > This past week I have been trying to find the root cause of tcp > performance problems of a few clients that are using a third party metro > Ethernet for transport. RFC2544 tests (Layer 2) and iperf using UDP give > good symmetric performance almost 100% the speed of the circuit. However > all kind of TCP tests result in some kind of asymmetrical deficiency, > either the upstream or downstream of the client is hugely different. The > latency is not a huge factor since all the metro Ethernet connections > have less than 2 ms. > > So the question basically if is there a good tutorial or white paper for > troubleshooting tcp with emphasis of using tools like Wireshark to debug > and track this kind of problems. > > Regards, > Abel. > > > > > From xmin0s at gmail.com Sat Sep 18 01:00:49 2010 From: xmin0s at gmail.com (Tim Eberhard) Date: Fri, 17 Sep 2010 20:00:49 -0500 Subject: Troubleshooting TCP performance tutorial In-Reply-To: References: <79BBBA445314D14C927525E537E603631F7B92@wnetexchg01.worldnetpr.com> Message-ID: To add on to that. Recently Wireshark Network Analysis was released. It's an excellent book covering wireshark and reading packet captures in general by Laura Chappell. I just finished reading it and I have to say it's an excellent book. Highly recommended. Between those two books I think you'll be very close to being a wireshark/packet capture guru. I hope this helps, -Tim Eberhard On Fri, Sep 17, 2010 at 7:33 PM, Joe Hamelin wrote: > In a situation like yours I found Internet Core Protocols: The > Definitive Guide by Eric Hall an easy to read guide to insuring that > what you are seeing via wireshark. I was able to find an issue with > the DF bit in a load balancer that was causing confounding headaches > in a network using wireshark and this book. > > Walk it through the syn-ack dance and don't trust that the devices are > handling it correctly. Start at one end and work your way through and > insure to YOUR satisfaction that every device proscribes to the > protocol. Don't rush, don't jump to conclusions. Just follow the > packet. That's the best advice I can give you. > > > http://oreilly.com/catalog/9781565925724/ > -- > Joe Hamelin, W7COM, Tulalip, WA, 360-474-7474 > > > > On Fri, Sep 17, 2010 at 5:06 PM, Abel Alejandro > wrote: > > Greetings, > > > > This past week I have been trying to find the root cause of tcp > > performance problems of a few clients that are using a third party metro > > Ethernet for transport. RFC2544 tests (Layer 2) and iperf using UDP give > > good symmetric performance almost 100% the speed of the circuit. However > > all kind of TCP tests result in some kind of asymmetrical deficiency, > > either the upstream or downstream of the client is hugely different. The > > latency is not a huge factor since all the metro Ethernet connections > > have less than 2 ms. > > > > So the question basically if is there a good tutorial or white paper for > > troubleshooting tcp with emphasis of using tools like Wireshark to debug > > and track this kind of problems. > > > > Regards, > > Abel. > > > > > > > > > > > > From joe at nethead.com Sat Sep 18 01:09:45 2010 From: joe at nethead.com (Joe Hamelin) Date: Fri, 17 Sep 2010 18:09:45 -0700 Subject: Troubleshooting TCP performance tutorial In-Reply-To: References: <79BBBA445314D14C927525E537E603631F7B92@wnetexchg01.worldnetpr.com> Message-ID: http://www.amazon.com/Wireshark-Network-Analysis-Official-Certified/dp/1893939995 Spendy but looks good. I'll have to pick it up when the next consulting check comes in. Thanks! I was sad to see that Eric Hall's book was out of print. At least cheap used copies are available. I forgot my copy a few jobs ago... I'm sure someone is getting help from it. -- Joe Hamelin, W7COM, Tulalip, WA, 360-474-7474 On Fri, Sep 17, 2010 at 6:00 PM, Tim Eberhard wrote: > To add on to that. Recently Wireshark Network Analysis was released. It's an > excellent book covering wireshark and reading packet captures in general by > Laura Chappell. I just finished reading it and I have to say it's an > excellent book. Highly recommended. > > Between those two books I think you'll be very close to being a > wireshark/packet capture guru. > > I hope this helps, > -Tim Eberhard > > > On Fri, Sep 17, 2010 at 7:33 PM, Joe Hamelin wrote: >> >> In a situation like yours I found Internet Core Protocols: The >> Definitive Guide by Eric Hall an easy to read guide to insuring that >> what you are seeing via wireshark. ?I was able to find an issue with >> the DF bit in a load balancer that was causing confounding headaches >> in a network using wireshark and this book. >> >> Walk it through the syn-ack dance and don't trust that the devices are >> handling it correctly. Start at one end and work your way through and >> insure to YOUR satisfaction that every device proscribes to the >> protocol. ?Don't rush, don't jump to conclusions. ?Just follow the >> packet. ?That's the best advice I can give you. >> >> >> http://oreilly.com/catalog/9781565925724/ >> -- >> Joe Hamelin, W7COM, Tulalip, WA, 360-474-7474 >> >> >> >> On Fri, Sep 17, 2010 at 5:06 PM, Abel Alejandro >> wrote: >> > Greetings, >> > >> > This past week I have been trying to find the root cause of tcp >> > performance problems of a few clients that are using a third party metro >> > Ethernet for transport. RFC2544 tests (Layer 2) and iperf using UDP give >> > good symmetric performance almost 100% the speed of the circuit. However >> > all kind of TCP tests result in some kind of asymmetrical deficiency, >> > either the upstream or downstream of the client is hugely different. The >> > latency is not a huge factor since all the metro Ethernet connections >> > have less than 2 ms. >> > >> > So the question basically if is there a good tutorial or white paper for >> > troubleshooting tcp with emphasis of using tools like Wireshark to debug >> > and track this kind of problems. >> > >> > Regards, >> > Abel. >> > >> > >> > >> > >> > >> > > From dedelman at iname.com Sat Sep 18 01:51:07 2010 From: dedelman at iname.com (Dave Edelman) Date: Fri, 17 Sep 2010 21:51:07 -0400 Subject: Netflow Tool In-Reply-To: <1284750142.18201.17.camel@n1-20-152.dhcp.drexel.edu> References: <8E440D28-42C6-4875-8E0A-D9E3D9E8DF41@gmail.com> <1284750142.18201.17.camel@n1-20-152.dhcp.drexel.edu> Message-ID: <011701cb56d3$f5e70f80$e1b52e80$@com> I have to agree. Scales very well, open source, more options than you are likely to ever use. --Dave -----Original Message----- From: Harry Hoffman [mailto:hhoffman at ip-solutions.net] Sent: Friday, September 17, 2010 3:02 PM To: Mike Gatti Cc: nanog at nanog.org Subject: Re: Netflow Tool argus, www.qosient.com/argus On Fri, 2010-09-17 at 14:49 -0400, Mike Gatti wrote: > Anyone out there using a good netflow collector that has the capability data to export to CSV? > Open Source would be best, but any suggestions are welcome. > > Thanks, > =+=+=+=+=+=+=+=+=+=+=+=+= > Michael Gatti > cell.703.347.4412 > ekim.ittag at gmail.com > =+=+=+=+=+=+=+=+=+=+=+=+= > > > > > From oberman at es.net Sat Sep 18 05:37:46 2010 From: oberman at es.net (Kevin Oberman) Date: Fri, 17 Sep 2010 22:37:46 -0700 Subject: Troubleshooting TCP performance tutorial In-Reply-To: Your message of "Fri, 17 Sep 2010 20:06:09 EDT." <79BBBA445314D14C927525E537E603631F7B92@wnetexchg01.worldnetpr.com> Message-ID: <20100918053746.122411CC3C@ptavv.es.net> > Date: Fri, 17 Sep 2010 20:06:09 -0400 > From: "Abel Alejandro" > > Greetings, > > This past week I have been trying to find the root cause of tcp > performance problems of a few clients that are using a third party metro > Ethernet for transport. RFC2544 tests (Layer 2) and iperf using UDP give > good symmetric performance almost 100% the speed of the circuit. However > all kind of TCP tests result in some kind of asymmetrical deficiency, > either the upstream or downstream of the client is hugely different. The > latency is not a huge factor since all the metro Ethernet connections > have less than 2 ms. > > So the question basically if is there a good tutorial or white paper for > troubleshooting tcp with emphasis of using tools like Wireshark to debug > and track this kind of problems. > > Regards, > Abel. You might look at http://fasterdata.es.net. A lot of it is aimed at very large volume data transfers, but quite a bit is relevant to all TCP issues. -- 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 tvhawaii at shaka.com Sat Sep 18 07:25:04 2010 From: tvhawaii at shaka.com (Michael Painter) Date: Fri, 17 Sep 2010 21:25:04 -1000 Subject: Did Internet Founders Actually Anticipate Paid, Prioritized Traffic? References: <1009171644.AA02827@ivan.Harhan.ORG> Message-ID: Michael Sokolov wrote: > Leo Bicknell wrote: > >> There really isn't a lot of choice, 2 providers, and some minor choice >> in how much speed you want to pay for with each one. > > Does that mean no CLECs like Covad or DSL.net who colocate in the AT&T > CO, rent unbundled dry copper pairs and take it up from there themselves? > > Does that mean no ISPs who buy/rent last+middle mile transport from AT&T > ADSL network at Layer 2 (ATM) and provide their own IP layer? > > MS There used to be an abundance of small ISPs, but the FCC changed all that in 2005 when they eliminated "Line Sharing". "The Federal Communications Commission on Friday voted to reclassify DSL broadband service, thus freeing phone companies of regulations that require them to share their infrastructure with Internet service providers. DSL will now be considered an "information service" instead of a "telecommunications service," a distinction that puts DSL in line with the classification of cable modem services. The change in semantics was expected after the U.S. Supreme Court's ruling in the Brand X case just five weeks ago. The court's decision upheld the FCC's classification of cable modem service as an information service. Now the phone companies and the cable companies are exempt from "common carrier" rules that require them to share their infrastructure with Internet service providers." http://news.cnet.com/FCC-changes-DSL-classification/2100-1034_3-5820713.html From jcdill.lists at gmail.com Sat Sep 18 09:34:49 2010 From: jcdill.lists at gmail.com (JC Dill) Date: Sat, 18 Sep 2010 02:34:49 -0700 Subject: Did Internet Founders Actually Anticipate Paid, Prioritized Traffic? In-Reply-To: <4C93CEC0.9050709@brightok.net> References: <9CBEC49C-9106-4C7C-AC92-8C525AD9AEBE@semihuman.com> <5A6D953473350C4B9995546AFE9939EE0A52AD92@RWC-EX1.corp.seven.com> <20100916.212821.74712800.sthaug@nethelp.no> <4C928391.4050701@brightok.net> <8C26A4FDAE599041A13EB499117D3C28405E0809@ex-mb-2.corp.atlasnetworks.us> <4C937192.2090603@brightok.net> <4C939071.6090405@brightok.net> <4C93BF1A.1090703@gmail.com> <4C93CEC0.9050709@brightok.net> Message-ID: <4C9487B9.4080904@gmail.com> Jack Bates wrote: > > And yet, I'm pretty sure there are providers that have different pipes > for business than they do for consumer, and probably riding some of > the same physical medium. This creates saturated and unsaturated > pipes, which is just as bad or worse than using QOS. The reason I'm > pretty sure about it, is business circuits generally are guaranteed, > while consumer are not. I'm pretty sure you are mistaken. The reason is, it's adding an additional layer of complexity inside the network for no good reason. The only difference between the guaranteed speed provided to business circuits and the not-guaranteed consumer circuits is if they get a reduction in their fees if the ISP can't deliver (business customers), AND they notice the outage, AND they complain and ask for a credit, AND the outage is long enough to trigger the contract clause for reducing the fee. The complaint structure is rigged in favor of the ISP. Further the easiest way to avoid paying out is simply to have enough capacity across their entire network that they don't have capacity related outages. Most outages are the result of equipment failures, and if they have a separate network for business and consumer customers it just makes the outage that much worse for whatever network is affected, leading to more complaints, more refunds (to those customers). "I encourage all my competitors to do that." jc From brandon.galbraith at gmail.com Sat Sep 18 15:08:44 2010 From: brandon.galbraith at gmail.com (Brandon Galbraith) Date: Sat, 18 Sep 2010 10:08:44 -0500 Subject: Troubleshooting TCP performance tutorial In-Reply-To: <20100918053746.122411CC3C@ptavv.es.net> References: <79BBBA445314D14C927525E537E603631F7B92@wnetexchg01.worldnetpr.com> <20100918053746.122411CC3C@ptavv.es.net> Message-ID: On Saturday, September 18, 2010, Kevin Oberman wrote: > > You might look at http://fasterdata.es.net. A lot of it is aimed at very > large volume data transfers, but quite a bit is relevant to all TCP > issues. > -- > 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 > > +1 fasterdata.es.net. Excellent resource. -brandon -- Brandon Galbraith US Voice: 630.492.0464 From dmfh at dmfh.cx Sat Sep 18 17:01:59 2010 From: dmfh at dmfh.cx (DMFH) Date: Sat, 18 Sep 2010 13:01:59 -0400 Subject: TCP Performance (NANOG Digest, Vol 32, Issue 60) In-Reply-To: References: Message-ID: <20100918170159.1584325826@127.0.0.1> Sat, 18 Sep 2010 09:34:55 +0000 nanog-request at nanog.org fuream loqour : >From: "Abel Alejandro" >Subject: Troubleshooting TCP performance tutorial > >This past week I have been trying to find the root cause of tcp >performance problems of a few clients that are using a third party metro >Ethernet for transport. RFC2544 tests (Layer 2) and iperf using UDP give >good symmetric performance almost 100% the speed of the circuit. However >all kind of TCP tests result in some kind of asymmetrical deficiency, Walking through the layers, if L2 checks out, & UDP checks out, but TCP does not, you might have a problem "up the stack", @ L4 with TCP. I don't know your test rig / setup, but a few ideas come to mind: - Mismatch in the TCP personality between the hosts - mixing Windows & some UNIX OS flavors, like Sun Solaris 2.8 or others can produce incredible degradation in streaming TCP performance either due to buggy TCP behavior, or one TCP stack supports options the other doesn't, like one side is doing Classic Reno TCP (max 64K) window, doesn't respect or process RFC1323 window-sizing options, but the other side does. It happens UNIX-to-UNIX too, and embedded devices usually don't have robust TCP/IP stacks as well (like hand-held barcode readers, etc.). Any client patch an OS recently? - Someone is doing QoS of some type either expressly or indirectly by effect. Stream / test TCP on multiple ports / sockets to multiple hosts, different OS combinations, or a known good combination - Knoppix Linux boot CD's are great for this kind of thing - send them to a client, pop 'em in, do some testing - once built a test CD for this, fun, gets rid of that long "troubleshoot loop". - MTU / other issue? Did your UDP stream pack full-size payloads? If not, walk up the size of the test packets to the maximum, see what happens. If it breaks somewhere, you have the beginning of an answer, etc. - Not thinking it's the client app since you mentioned you've run a whole set of TCP-based tests. /dmfh -- __| |_ __ / _| |_ 01100100 01101101 / _` | ' \| _| ' \ 01100110 01101000 \__,_|_|_|_|_| |_||_| dmfh(-2)dmfh.cx From paulgkeny at gmail.com Sat Sep 18 17:41:51 2010 From: paulgkeny at gmail.com (Georges-Keny PAUL) Date: Sat, 18 Sep 2010 13:41:51 -0400 Subject: Specifications for Internet services on public frequency Message-ID: Hello all, My team is working on technical and technological specifications of a document for the deployment of Internet service on public frequencies in rural areas. We welcome your thoughts on the topic in terms of previous experiences and, well sure, you recommendation in terms of equipment. You should note that the environment in question is very mountainous with very precarious infrastructure conditions: no electricity, poor access, etc. We would like to deploy a service at minimal cost, using mainly open source software. All comments, suggestions, recommendations, draft, success stories are well come. Feel free to contact me for additional information. Warms regards, Georges-Keny PAUL From tvarriale at comcast.net Sat Sep 18 17:44:05 2010 From: tvarriale at comcast.net (Tony Varriale) Date: Sat, 18 Sep 2010 12:44:05 -0500 Subject: Did Internet Founders Actually Anticipate Paid, References: <201009161359.o8GDxNQ0044586@aurora.sol.net> Message-ID: <133F71305823402FBDF9C700FF623F31@flamdt01> ----- Original Message ----- From: "Joe Greco" To: "Chris Boyd" Cc: "NANOG" Sent: Thursday, September 16, 2010 8:59 AM Subject: Re: Did Internet Founders Actually Anticipate Paid, > On one hand, we all recognize oversubscription as an issue. The high-level of oversub isn't the issue, it's part of the business model. tv From paulgkeny at gmail.com Sat Sep 18 18:37:39 2010 From: paulgkeny at gmail.com (Georges-Keny PAUL) Date: Sat, 18 Sep 2010 14:37:39 -0400 Subject: Specifications for Internet services on public frequency In-Reply-To: <4C95040B.8070101@nic-naa.net> References: <4C95040B.8070101@nic-naa.net> Message-ID: Eric, Thanks for your reply. We're located in Haiti (Caribbean), we use basically the same template than rural S. America and Africa. I'm waiting for you. Regards, Georges-Keny PAUL 2010/9/18 Eric Brunner-Williams > Georges-Keny, > > Well, I wrote a WiMAX based BTOP application last year for rural Maine. It > didn't get a dime but I had a bit to think about. Put me in your co-think'um > mailing list since NANOG won't be a place for long discussion or rural > service. There's interesting wireless work done in rural S. America and > Africa to keep abreast of as well. > > Eric > From jgreco at ns.sol.net Sat Sep 18 18:38:01 2010 From: jgreco at ns.sol.net (Joe Greco) Date: Sat, 18 Sep 2010 13:38:01 -0500 (CDT) Subject: Did Internet Founders Actually Anticipate Paid, In-Reply-To: <133F71305823402FBDF9C700FF623F31@flamdt01> Message-ID: <201009181838.o8IIc1NM080494@aurora.sol.net> > > On one hand, we all recognize oversubscription as an issue. > > The high-level of oversub isn't the issue, it's part of the business model. Of course the high level of oversub is an issue, because service providers are not willing to commit to providing some particular level of service. The business model has kind-of worked up to this point, with the scary boogeyman of evil illegal P2P filesharing used as justification for traffic engineering on shared pipes that are too small to handle the deluge of data that is growing daily. Consider: the practical reality is that we're seeing more and more gizmos that do more and more network things. We're going to see DVR's downloading content over the Internet, you'll see your nav system downloading map updates over the Internet, these are all "new" devices that didn't exist ~10 years ago in their current form, and they're changing consumer usage patterns. ISP's developed a "business model" that allowed profitability in an environment where each access line had marginal usage associated with it. The environment continues to evolve. There is no reason to expect that the "business model" will remain useful or that any component of it, such as massive oversubscription, must necessarily be correct and remain viable in its current form, just because it worked a decade ago. ... 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 tvarriale at comcast.net Sat Sep 18 18:51:44 2010 From: tvarriale at comcast.net (Tony Varriale) Date: Sat, 18 Sep 2010 13:51:44 -0500 Subject: Did Internet Founders Actually Anticipate Paid, References: <201009181838.o8IIc1NM080494@aurora.sol.net> Message-ID: > Of course the high level of oversub is an issue.... We'll disagree then. Oversub makes access affordable. >..with the scary boogeyman of evil illegal P2P filesharing That just tips the money in the wrong direction. And it's a real threat (amongst others)...not just that deadly clown hiding under your bed. > Consider: the practical reality is that we're seeing more and more > gizmos that do more and more network things. We're going to see > DVR's downloading content over the Internet, you'll see your nav > system downloading map updates over the Internet, these are all > "new" devices that didn't exist ~10 years ago in their current form, > and they're changing consumer usage patterns. Yeah, I think we all know and see that stuff. But, unless some technological model changes bit pricing, the premise of oversub still wins. Going 1:1 today (or in the near future) makes no sense unless you layer something on top (advertising, qos, buttercream icing?). >There is no reason to > expect that the "business model" will remain useful or that any > component of it, such as massive oversubscription, must necessarily > be correct and remain viable in its current form, just because it > worked a decade ago. Well, I'm talking 10 years ago up until present. How do you see the sub model turning? 1:1? If so, how? And, still some profit? tv From Charles at knownelement.com Sat Sep 18 20:32:27 2010 From: Charles at knownelement.com (Charles n wyble) Date: Sat, 18 Sep 2010 13:32:27 -0700 Subject: Specifications for Internet services on public frequency In-Reply-To: References: Message-ID: Check out the openbts and tier wireless projects. "Georges-Keny PAUL" wrote: >Hello all, > >My team is working on technical and technological specifications of a >document for the deployment of Internet service on public frequencies in >rural areas. We welcome your thoughts on the topic in terms of previous >experiences and, well sure, you recommendation in terms of equipment. You >should note that the environment in question is very mountainous with very >precarious infrastructure conditions: no electricity, poor access, etc. We >would like to deploy a service at minimal cost, using mainly open source >software. > > >All comments, suggestions, recommendations, draft, success stories are well >come. > > >Feel free to contact me for additional information. > > > >Warms regards, >Georges-Keny PAUL -- from the desk of Charles wyble ceo & president known element enterprises xmpp/sip/smtp: charles at knownelement.com legacy pstn: 818 280 7059 From tvhawaii at shaka.com Sat Sep 18 21:42:30 2010 From: tvhawaii at shaka.com (Michael Painter) Date: Sat, 18 Sep 2010 11:42:30 -1000 Subject: Troubleshooting TCP performance tutorial References: <79BBBA445314D14C927525E537E603631F7B92@wnetexchg01.worldnetpr.com> Message-ID: <6132293C9E264AC6BE15AA2A4CFA12DA@DELL16> Abel Alejandro wrote: > Greetings, > > This past week I have been trying to find the root cause of tcp > performance problems of a few clients that are using a third party metro > Ethernet for transport. RFC2544 tests (Layer 2) and iperf using UDP give > good symmetric performance almost 100% the speed of the circuit. However > all kind of TCP tests result in some kind of asymmetrical deficiency, > either the upstream or downstream of the client is hugely different. The > latency is not a huge factor since all the metro Ethernet connections > have less than 2 ms. > > So the question basically if is there a good tutorial or white paper for > troubleshooting tcp with emphasis of using tools like Wireshark to debug > and track this kind of problems. > > Regards, > Abel. It might be worth your while to run the analysis found here: http://netalyzr.icsi.berkeley.edu/index.html From tvhawaii at shaka.com Sun Sep 19 00:02:15 2010 From: tvhawaii at shaka.com (Michael Painter) Date: Sat, 18 Sep 2010 14:02:15 -1000 Subject: Did Internet Founders Actually Anticipate Paid, References: <201009181838.o8IIc1NM080494@aurora.sol.net> Message-ID: <0C9A4BB27F3946BFBF6DB740BFCC3815@DELL16> I 'bookmarked' these folks: http://www.plus.net/?home=hometop on June 18, 2008 because they were one of the few who openly admitted to using DPI to enforce QOS. Two + years later, they're still around and apparently successful. Just glancing through the site, I could no longer find any mention of DPI, but instead they say this: http://www.plus.net/support/broadband/speed_guide/traffic_management.shtml For what it's worth... From nonobvious at gmail.com Sun Sep 19 06:59:37 2010 From: nonobvious at gmail.com (Bill Stewart) Date: Sat, 18 Sep 2010 23:59:37 -0700 Subject: Did Internet Founders Actually Anticipate Paid, Prioritized Traffic? In-Reply-To: <4C9487B9.4080904@gmail.com> References: <9CBEC49C-9106-4C7C-AC92-8C525AD9AEBE@semihuman.com> <5A6D953473350C4B9995546AFE9939EE0A52AD92@RWC-EX1.corp.seven.com> <20100916.212821.74712800.sthaug@nethelp.no> <4C928391.4050701@brightok.net> <8C26A4FDAE599041A13EB499117D3C28405E0809@ex-mb-2.corp.atlasnetworks.us> <4C937192.2090603@brightok.net> <4C939071.6090405@brightok.net> <4C93BF1A.1090703@gmail.com> <4C93CEC0.9050709@brightok.net> <4C9487B9.4080904@gmail.com> Message-ID: On Sat, Sep 18, 2010 at 2:34 AM, JC Dill wrote: > Jack Bates wrote: >> And yet, I'm pretty sure there are providers that have different pipes for >> business than they do for consumer, and probably riding some of the same >> physical medium. This creates saturated and unsaturated pipes, which is just >> as bad or worse than using QOS. The reason I'm pretty sure about it, is >> business circuits generally are guaranteed, while consumer are not. > > I'm pretty sure you are mistaken. ?The reason is, it's adding an additional > layer of complexity inside the network for no good reason. Real ISPs have all sorts of different layers of complexity, for lots of reasons ranging from equipment performance to Layer 8 differences to mergers&acquisitions to willingness-to-pay to marketing objectives to historical accident. An ISP that's also a telco-ish carrier will typically offer multiple services at Layer 1, Layer 2, MPLS, Layer 3, and other variants on transport. Copper's different economically from fiber pairs, SONET, Ethernet, CWDM, DWDM, some services get multiplexed by using bundles of copper or fiber, some get multiplexed by using different kinds of wavelength or time division, some get shared by packet-switching, some packet switches are smarter on some transport media than on others, some services will use edge equipment from Brand C or J or A because they were the first or cheapest to get Feature X when it was needed, some services are designed for Layer 9 problems like different taxes on different kinds of access services. An ISP that isn't an end-to-end vertically integrated provider will be buying stuff from other carriers that influences what services they offer, but the integrated providers often do that too. There are some kinds of service where the difference between business-grade and consumer-grade is mainly about options for types of billing, or for guarantees around how fast they'll get a truck to your place to fix things - that's especially common in access networks. Most consumer home internet service is running on DSL or cable modems, and that's going to behave differently than T1 access or 10 Gbps WAN-PHY or LAN-PHY gear. Different priced services may get connected to circuits or boxes that have different amounts of oversubscription. Different protocols give you different feedback mechanisms that affect performance. Or higher-priced services may have measuring mechanisms built in to them or bolted alongside, so that performance problems can generate a trouble ticket faster or get a refund on the bill, and come with a sales person who doesn't really understand how they work but is being pressured to provide 110% uptime. A common design these days is to have an MPLS backbone supporting multiple services including private networks and public internet, and the private networks may get dedicated chunks of the trunking, or may get higher MPLS prioritization. But separately from that, the IP edges may support Diffserv, and maybe the backbones do or maybe they don't, or maybe some parts of the trunking are only accessible to the higher-priority services. And maybe the diffserv gets implemented differently on the equipment that's used for different transmission media, or maybe the box that has the better port density doesn't have as many queues as the lower-density box, or maybe it's different between different port cards with the same vendor. A very common design is that businesses can get diffserv (or the MPLS equivalents) on end-to-end services provided by ISP X, but the peering arrangements with ISP Y don't pass diffserv bits, or pass it but ignore it, or use different sets of bits. It's very frustrating to me as a consumer, because what I'd really like would be for the main bottleneck point (my downstream connection at home) to either respect the diffserv bits set by the senders, or else to give UDP higher priority and TCP lower priority, and put Bittorrent and its ilk in a scavenger class, so VOIP and real-time video work regardless of my web activity and the web gets more priority than BitTorrent. -- ---- ? ? ? ? ? ?? Thanks;? ?? Bill Note that this isn't my regular email account - It's still experimental so far. And Google probably logs and indexes everything you send it. From randy at psg.com Sun Sep 19 08:17:11 2010 From: randy at psg.com (Randy Bush) Date: Sun, 19 Sep 2010 04:17:11 -0400 Subject: caribbean cable ip contact Message-ID: if a clued engineer at caribbean cable happens to read this message, i would be thankful if they contacted me privately. thank you. randy -- From: Randy Bush Subject: very strange internet behavior To: customersupport at caribcable.com Date: Sun, 19 Sep 2010 04:14:08 -0400 [ this needs to be escalated to an internet engineer ] hi, i am an old senior internet geek vacationing on nevis's nesbit beach. the cottage has your tv and internet service. during what i suspect are the busy hours of the day, your internet service borders on useless. it is as if an overloaded NAT is in the middle. one can reach very few web sites. one can reach (ping, ssh, ...) some hosts and not others. and the hosts are in the same rack and same ip address space in a stateside colo. one can ping a host but not ssh to it. or i can be sshed into a host and yet not be able to ping it. very twisty stuff. if i turn on the tv, the cable seems to be working. i can run an openvpn tunnel to a stateside or japan-based host and then everything is reachable. of course i have to try three or four of my openvpn serving hosts before i find one which is reachable. this is not a great solution, and certainly not one available to the vast majority of your customers. from an engineer's point of view, i would love to understand what the cause of all this really is. randy From rudi.daniel at gmail.com Sun Sep 19 13:52:48 2010 From: rudi.daniel at gmail.com (Rudolph Daniel) Date: Sun, 19 Sep 2010 09:52:48 -0400 Subject: Nevis Internet Message-ID: Very interesting Randy, this sounds like what we endure on a regular basis in the eastern Caribbean....I too would like to know why myself since I have always wondered whether our local networks are set up. Rudi Daniel > From: Randy Bush > Subject: very strange internet behavior > To: customersupport at caribcable.com > Date: Sun, 19 Sep 2010 04:14:08 -0400 > > [ this needs to be escalated to an internet engineer ] > > hi, > > i am an old senior internet geek vacationing on nevis's nesbit beach. > the cottage has your tv and internet service. > > during what i suspect are the busy hours of the day, your internet > service borders on useless. it is as if an overloaded NAT is in the > middle. one can reach very few web sites. one can reach (ping, ssh, > ...) some hosts and not others. and the hosts are in the same rack and > same ip address space in a stateside colo. one can ping a host but not > ssh to it. or i can be sshed into a host and yet not be able to ping > it. very twisty stuff. > > if i turn on the tv, the cable seems to be working. > > i can run an openvpn tunnel to a stateside or japan-based host and then > everything is reachable. of course i have to try three or four of my > openvpn serving hosts before i find one which is reachable. this is not > a great solution, and certainly not one available to the vast majority > of your customers. > > from an engineer's point of view, i would love to understand what the > cause of all this really is. > > randy > > > > ------------------------------ > > _______________________________________________ > NANOG mailing list > NANOG at nanog.org > https://mailman.nanog.org/mailman/listinfo/nanog > > End of NANOG Digest, Vol 32, Issue 62 > ************************************* > -- Rudi Daniel *danielcharles * consulting *ICT4Dev & e Business and services * *1-784 498 8277 * ** *h ttp://csisvg.ning.com * From randy at psg.com Sun Sep 19 14:17:50 2010 From: randy at psg.com (Randy Bush) Date: Sun, 19 Sep 2010 10:17:50 -0400 Subject: Nevis Internet In-Reply-To: References: Message-ID: > Very interesting Randy, this sounds like what we endure on a regular > basis in the eastern Caribbean....I too would like to know why myself > since I have always wondered whether our local networks are set up. well, here is the netalyzer report from caribbean cable on north nevis at a good time http://netalyzr.icsi.berkeley.edu/restore/id=43ca253f-6723-1110f506-4d39-465b-8b1d of course, this is a rough state of the art measurement of services and performance. but i am not aware of a tool that will help diagnose connectivity issues such as i am seeing, see OP. anyone with clue on that please holler. it smells to me as if there is a middle-box or three which think they are too smart and just do not scale. but i really have no idea. randy From rudi.daniel at gmail.com Sun Sep 19 14:22:22 2010 From: rudi.daniel at gmail.com (Rudolph Daniel) Date: Sun, 19 Sep 2010 10:22:22 -0400 Subject: Randy in Nevis Message-ID: Dont know if this may assist, but here is another from St Vincent...lime network. Sunday 19th sep. 2010 http://n1.netalyzr.icsi.berkeley.edu/summary/id=43ca253f-6714-b0f7e7b0-d08e-4729-b491#BufferResult RD From randy at psg.com Sun Sep 19 14:26:34 2010 From: randy at psg.com (Randy Bush) Date: Sun, 19 Sep 2010 10:26:34 -0400 Subject: Randy in Nevis In-Reply-To: References: Message-ID: > http://n1.netalyzr.icsi.berkeley.edu/summary/id=43ca253f-6714-b0f7e7b0-d08e-4729-b491#BufferResult wow! lime's buffering and 587 hacking make me like caribbean cable more and more. randy From jcdill.lists at gmail.com Sun Sep 19 14:54:14 2010 From: jcdill.lists at gmail.com (JC Dill) Date: Sun, 19 Sep 2010 07:54:14 -0700 Subject: Did Internet Founders Actually Anticipate Paid, Prioritized Traffic? In-Reply-To: References: <9CBEC49C-9106-4C7C-AC92-8C525AD9AEBE@semihuman.com> <5A6D953473350C4B9995546AFE9939EE0A52AD92@RWC-EX1.corp.seven.com> <20100916.212821.74712800.sthaug@nethelp.no> <4C928391.4050701@brightok.net> <8C26A4FDAE599041A13EB499117D3C28405E0809@ex-mb-2.corp.atlasnetworks.us> <4C937192.2090603@brightok.net> <4C939071.6090405@brightok.net> <4C93BF1A.1090703@gmail.com> <4C93CEC0.9050709@brightok.net> <4C9487B9.4080904@gmail.com> Message-ID: <4C962416.3090209@gmail.com> Bill Stewart wrote: > A very common design is that businesses can get diffserv (or the MPLS > equivalents) on end-to-end services provided by ISP X, but the peering > arrangements with ISP Y don't pass diffserv bits, or pass it but > ignore it, or use different sets of bits. It's very frustrating to me > as a consumer, because what I'd really like would be for the main > bottleneck point (my downstream connection at home) to either respect > the diffserv bits set by the senders, or else to give UDP higher > priority and TCP lower priority, and put Bittorrent and its ilk in a > scavenger class, so VOIP and real-time video work regardless of my web > activity and the web gets more priority than BitTorrent. > I can understand you wanting this done on YOUR bottleneck, in the connection between the ISP and you. And you want it done to YOUR specifications. That is entirely reasonable. But would you want the ISP doing it elsewhere in the network, and done to their priorities, not yours? (A "one size fits all" congestion prioritization solution.) Further, would you be happy with an ISP that HAS a bottleneck elsewhere in their network - not just in the last mile to your door? IMHO it's stupid for an ISP to intentionally design for and allow bottlenecks to exist within their network. The bottleneck to the end user is currently unavoidable, and users with bandwidth intensive uses might prefer some prioritization (to their own specifications) on that part of the link. Bottlenecks within the ISP network and between ISPs should be avoidable, and should be avoided. Any ISP that fails to mitigate those bottlenecks will quickly find customers streaming to another ISP that will advertise "no network congestion here, no traffic shaping that slows down traffic that might be important to YOU" etc. jc PS. Bill, if you aren't using Sonic, give their Fusion service a look. It's better than Kadu. :-) From randy at psg.com Sun Sep 19 15:00:06 2010 From: randy at psg.com (Randy Bush) Date: Sun, 19 Sep 2010 11:00:06 -0400 Subject: Did Internet Founders Actually Anticipate Paid, Prioritized Traffic? In-Reply-To: <4C962416.3090209@gmail.com> References: <9CBEC49C-9106-4C7C-AC92-8C525AD9AEBE@semihuman.com> <5A6D953473350C4B9995546AFE9939EE0A52AD92@RWC-EX1.corp.seven.com> <20100916.212821.74712800.sthaug@nethelp.no> <4C928391.4050701@brightok.net> <8C26A4FDAE599041A13EB499117D3C28405E0809@ex-mb-2.corp.atlasnetworks.us> <4C937192.2090603@brightok.net> <4C939071.6090405@brightok.net> <4C93BF1A.1090703@gmail.com> <4C93CEC0.9050709@brightok.net> <4C9487B9.4080904@gmail.com> <4C962416.3090209@gmail.com> Message-ID: $whatever folk. qos is about whose packets to drop. who here is paid to drop packets? if this was $customer-list, i could understand wanting to drop some packets on the link you were too cheap to provision reasonably (which is pretty st00pid in today's pricing environment). but this is a net ops list. randy From jeffrey.lyon at blacklotus.net Sun Sep 19 15:15:29 2010 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Sun, 19 Sep 2010 19:45:29 +0430 Subject: Randy in Nevis In-Reply-To: References: Message-ID: I'm sure it's a lot better than our Afghanistan satellite systems (84% uptime on two of them, 41% on the third). Luckily we load balance the WAN ports so it's not *too* painful. Jeff On Sun, Sep 19, 2010 at 6:56 PM, Randy Bush wrote: >> http://n1.netalyzr.icsi.berkeley.edu/summary/id=43ca253f-6714-b0f7e7b0-d08e-4729-b491#BufferResult > > wow! ?lime's buffering and 587 hacking make me like caribbean cable more > and more. > > randy > > -- Jeffrey Lyon, Leadership Team jeffrey.lyon at blacklotus.net | http://www.blacklotus.net Black Lotus Communications - AS32421 First and Leading in DDoS Protection Solutions From jgammons at gmail.com Sun Sep 19 18:59:51 2010 From: jgammons at gmail.com (John Gammons) Date: Sun, 19 Sep 2010 14:59:51 -0400 Subject: Specifications for Internet services on public frequency In-Reply-To: References: Message-ID: Ubiquiti Networks - www.ubnt.com I have deployed numerous rural wireless provider nets with a variety of technologies and vendors and this is by far, the most cost effective and reliable last mile solution. IMHO, based on testing and real life lessons learned, unlicensed is the only way to go in rural. The benefits of licensed frequencies are "typically" lost in rural environments as there aren't many contending devices. The above N based equipment performs roughly at the same level as fixed wimax, without the expense of the wimax chipsets. Of course I am generalizing a bit and each deployment has it's own requirements and challenges to be considered. John On Saturday, September 18, 2010, Georges-Keny PAUL wrote: > Hello all, > > My team is working on technical and technological specifications of a > document for the deployment of Internet service on public frequencies in > rural areas. We welcome your thoughts on the topic in terms of previous > experiences and, well sure, you recommendation in terms of equipment. You > should note that the environment in question is very mountainous with very > precarious infrastructure conditions: no electricity, poor access, etc. We > would like to deploy a service at minimal cost, using mainly open source > software. > > > All comments, suggestions, recommendations, draft, success stories are well > come. > > > Feel free to contact me for additional information. > > > > Warms regards, > Georges-Keny PAUL > From da.shi at 3z.ca Sun Sep 19 22:04:35 2010 From: da.shi at 3z.ca (Da Shi) Date: Sun, 19 Sep 2010 15:04:35 -0700 (PDT) Subject: Da Shi wants to stay in touch on LinkedIn Message-ID: <464466749.6469676.1284933875803.JavaMail.app@ech3-cdn10.prod> LinkedIn ------------ I'd like to add you to my professional network on LinkedIn. - Da Shi Da Shi Managing Director at 3z Canada Toronto, Canada Area Confirm that you know Da Shi https://www.linkedin.com/e/-voa23o-geaggbx4-2z/isd/1686347474/EeHY08Xk/ -- (c) 2010, LinkedIn Corporation From gbonser at seven.com Sun Sep 19 23:09:49 2010 From: gbonser at seven.com (George Bonser) Date: Sun, 19 Sep 2010 16:09:49 -0700 Subject: Did Internet Founders Actually Anticipate Paid, Prioritized Traffic? In-Reply-To: <4C962416.3090209@gmail.com> References: <9CBEC49C-9106-4C7C-AC92-8C525AD9AEBE@semihuman.com> <5A6D953473350C4B9995546AFE9939EE0A52AD92@RWC-EX1.corp.seven.com> <20100916.212821.74712800.sthaug@nethelp.no> <4C928391.4050701@brightok.net> <8C26A4FDAE599041A13EB499117D3C28405E0809@ex-mb-2.corp.atlasnetworks.us> <4C937192.2090603@brightok.net> <4C939071.6090405@brightok.net><4C93BF1A.1090703@gmail.com> <4C93CEC0.9050709@brightok.net><4C9487B9.4080904@gmail.com> <4C962416.3090209@gmail.com> Message-ID: <5A6D953473350C4B9995546AFE9939EE0A52ADEF@RWC-EX1.corp.seven.com> > IMHO it's stupid for an ISP to intentionally design for and allow > bottlenecks to exist within their network. The bottleneck to the end > user is currently unavoidable, and users with bandwidth intensive uses > might prefer some prioritization (to their own specifications) on that > part of the link. Bottlenecks within the ISP network and between ISPs > should be avoidable, and should be avoided. Any ISP that fails to > mitigate those bottlenecks will quickly find customers streaming to > another ISP that will advertise "no network congestion here, no traffic > shaping that slows down traffic that might be important to YOU" etc. > > jc I think the extent to which one favors prioritization or not will depend on who they are and what is going on at the moment. If I am an ISP that is not a telecom provider of circuits, I might be more in favor of prioritization. If I am a provider of bandwidth to others, I would be against it as I want to sell bandwidth to them. It might also depend on circumstances that vary from time to time. If an application suddenly appears that becomes wildly popular practically overnight and is a bandwidth hog, it might be difficult to move fast enough to accommodate that usage. I seem to remember that when Napster first appeared, it swamped many networks. If a situation occurs such as a disaster of national or global or even local interest, maybe the sudden demand swamps the existing infrastructure. If I were providing consumer access, I might provide two methods. The first would be no prioritization, just treat everything equally. The second might be a "canned" prioritization profile that a user could elect for application to their connection. This might not prioritize any specific content provider over another so much as prioritize certain protocols over another. So it might prioritize VOIP up, and p2p protocols down as an example. A "value added" situation might be one that allows a user to specify their own prioritization profile for some additional fee. In an emergency situation, a provider might possibly want to have some prioritization profiles "on the shelf" ready to apply if needed. This might prioritize traffic to certain government, emergency, and information services up and traffic to some other services and protocols down. Generally, I would want to see every network have enough bandwidth for every contingency but that is somewhat unrealistic because we don't have a crystal ball. What would be the demand today in the case of another 9/11/01 type of event? I don't think anyone really knows. In that case, not having some prioritization plan in place might render a network completely useless. Having one might allow some services to work at the expense of others. I would rather be connected to a network that would allow access to government sites, news and information sites, email, and voice communications at the expense of, say, gaming, streaming content, gambling, and porn for the duration of the emergency. It would also be better, in my opinion, for networks to have their own emergency plans than to put in place a mechanism where government dictates what gets done and when. You can flee a network that does something you don't like for one that has a plan more in line with your priorities, fleeing a government is more difficult. From jared at puck.nether.net Sun Sep 19 23:30:17 2010 From: jared at puck.nether.net (Jared Mauch) Date: Sun, 19 Sep 2010 19:30:17 -0400 Subject: Specifications for Internet services on public frequency In-Reply-To: References: Message-ID: <4FBC0159-A61B-426C-91F3-963FD3C13E67@puck.nether.net> On Sep 19, 2010, at 2:59 PM, John Gammons wrote: > Ubiquiti Networks - www.ubnt.com > > I have deployed numerous rural wireless provider nets with a variety > of technologies and vendors and this is by far, the most cost > effective and reliable last mile solution. > > IMHO, based on testing and real life lessons learned, unlicensed is > the only way to go in rural. The benefits of licensed frequencies are > "typically" lost in rural environments as there aren't many contending > devices. The above N based equipment performs roughly at the same > level as fixed wimax, without the expense of the wimax chipsets. Of > course I am generalizing a bit and each deployment has it's own > requirements and challenges to be considered. +1 UBNT. Can not beat the price/performance of the equipment. ($160 for a pair of dual-pol 802.11n equipment). - Jared From smb at cs.columbia.edu Mon Sep 20 01:54:05 2010 From: smb at cs.columbia.edu (Steven Bellovin) Date: Sun, 19 Sep 2010 21:54:05 -0400 Subject: Did Internet Founders Actually Anticipate Paid, Prioritized Traffic? In-Reply-To: References: <19598.25043.581492.654328@world.std.com> <8626EF19-F165-4FDE-B7CF-9F67A03CC7D3@cisco.com> <19600.8632.814275.641127@world.std.com> <67B4FDC4-295F-4242-B622-B4C4203B5C03@cs.columbia.edu> Message-ID: <427BD03A-29D4-4ADA-B476-D8502D166F6C@cs.columbia.edu> On Sep 17, 2010, at 5:20 46PM, Bill Stewart wrote: > Sorry, fat-fingered something when I was trying to edit. > > On Fri, Sep 17, 2010 at 2:12 PM, Bill Stewart wrote: >> On Tue, Sep 14, 2010 at 6:51 PM, Steven Bellovin wrote: >>> No, they bought AT&T, which [...] But yes, SBC is the controlling piece of the new AT&T. > Most of the wide-area ISP network is the old AT&T, while > much of the consumer broadband grew out of the SBC DSL side. Yup. > >>> As for the two /8s -- not quite. Back in the 1980s, AT&T got 12/8. We soon learned that we couldn't make good use of it, since multiple levels of subnetting didn't exist. We offered it back to Postel in exchange for 135/8 -- i.e., the equivalent in class B space -- but Postel said to keep 12/8 since no one else could use it, either. This was all long before addresses were tight. When AT&T decided to go into the ISP business, circa 1995, 12/8 was still lying around, unused except for a security experiment I was running.* However, a good chunk of 135/8 went to Lucent (now Alcatel-Lucent) in 1996, though I don't know how much. > > The AT&T bits kept some fraction of 135; I don't know how > much without dredging through ARIN Whois, but at least 135.63/16 is on > my desktop. I know -- that's why I wrote "a good chunk", but I sure don't know who got what. (FYI, I'm still a very part-time AT&T employee.) > > If I remember correctly, which is unlikely at this point, > 12/8 was the Murray Hill Cray's Hyperchannel network, which I'd heard > didn't know how to do subnetting except on classful boundaries, so it > could happily handle 16M hosts on its Class A, and in fact only had > two or three. Good point. I don't remember what time frame that was true, though. I'm certain about why Mark Horton got 12/8 and 135/8, but I don't remember the years, either. --Steve Bellovin, http://www.cs.columbia.edu/~smb From jeffrey.lyon at blacklotus.net Mon Sep 20 06:33:09 2010 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Mon, 20 Sep 2010 11:03:09 +0430 Subject: Specifications for Internet services on public frequency In-Reply-To: <4FBC0159-A61B-426C-91F3-963FD3C13E67@puck.nether.net> References: <4FBC0159-A61B-426C-91F3-963FD3C13E67@puck.nether.net> Message-ID: Another +1 UBNT. We're using the NanoStation2 to deliver 802.11g to remote camps in Afghanistan. They advertise a 60 deg LOS signal but it seems to do much better. Supposedly they will reach 15 km but we've never tried to use them that far. What's really neat is they come ready to mount with some heavy duty zip ties. I'm also a fan of the Cisco Aironet 1310, but we're using the built-in omni-directional antennae so the range isn't as nice as the Ubiquity and they cost about five times as much. The terminations are RG6 and the mount kit comes with the cable and weather strips to protect the terminations. The Ubiquity by comparison is all PoE so you'll want to use loom to protect the ethernet cable. I would venture to say that the UBNT omni-directional devices (eg. PicoStation2HP) have better range than the aforementioned Aironet 1310. Jeff On Mon, Sep 20, 2010 at 4:00 AM, Jared Mauch wrote: > > On Sep 19, 2010, at 2:59 PM, John Gammons wrote: > >> Ubiquiti Networks - www.ubnt.com >> >> I have deployed numerous rural wireless provider nets with a variety >> of technologies and vendors and this is by far, the most cost >> effective and reliable last mile solution. >> >> IMHO, based on testing and real life lessons learned, unlicensed is >> the only way to go in rural. ?The benefits of licensed frequencies are >> "typically" lost in rural environments as there aren't many contending >> devices. ?The above N based equipment performs roughly at the same >> level as fixed wimax, without the expense of the wimax chipsets. ?Of >> course I am generalizing a bit and each deployment has it's own >> requirements and challenges to be considered. > > +1 UBNT. > > Can not beat the price/performance of the equipment. ($160 for a pair of dual-pol 802.11n equipment). > > - Jared > > > > -- Jeffrey Lyon, Leadership Team jeffrey.lyon at blacklotus.net | http://www.blacklotus.net Black Lotus Communications - AS32421 First and Leading in DDoS Protection Solutions From dmburgess at linktechs.net Mon Sep 20 13:27:14 2010 From: dmburgess at linktechs.net (Dennis Burgess) Date: Mon, 20 Sep 2010 08:27:14 -0500 Subject: Specifications for Internet services on public frequency References: <4FBC0159-A61B-426C-91F3-963FD3C13E67@puck.nether.net> Message-ID: <91522911795E174F97E7EF8B792A103131515B@ltiserver.LTI.local> UBNT is fine if you need a bridged network, using them in junction to MikroTik's RouterBOARDs will give you all of the tools you will need to be successful as well. Routing, traffic shaping etc. Contact me off-list if you need pre-built / configured solutions with either hardware. ----------------------------------------------------------- Dennis Burgess, Mikrotik Certified Trainer Link Technologies, Inc -- Mikrotik & WISP Support Services Office: 314-735-0270 Website: http://www.linktechs.net LIVE On-Line Mikrotik Training - Author of "Learn RouterOS" -----Original Message----- From: Jeffrey Lyon [mailto:jeffrey.lyon at blacklotus.net] Sent: Monday, September 20, 2010 1:33 AM To: Jared Mauch Cc: nanog at nanog.org Subject: Re: Specifications for Internet services on public frequency Another +1 UBNT. We're using the NanoStation2 to deliver 802.11g to remote camps in Afghanistan. They advertise a 60 deg LOS signal but it seems to do much better. Supposedly they will reach 15 km but we've never tried to use them that far. What's really neat is they come ready to mount with some heavy duty zip ties. I'm also a fan of the Cisco Aironet 1310, but we're using the built-in omni-directional antennae so the range isn't as nice as the Ubiquity and they cost about five times as much. The terminations are RG6 and the mount kit comes with the cable and weather strips to protect the terminations. The Ubiquity by comparison is all PoE so you'll want to use loom to protect the ethernet cable. I would venture to say that the UBNT omni-directional devices (eg. PicoStation2HP) have better range than the aforementioned Aironet 1310. Jeff On Mon, Sep 20, 2010 at 4:00 AM, Jared Mauch wrote: > > On Sep 19, 2010, at 2:59 PM, John Gammons wrote: > >> Ubiquiti Networks - www.ubnt.com >> >> I have deployed numerous rural wireless provider nets with a variety >> of technologies and vendors and this is by far, the most cost >> effective and reliable last mile solution. >> >> IMHO, based on testing and real life lessons learned, unlicensed is >> the only way to go in rural. ?The benefits of licensed frequencies >> are "typically" lost in rural environments as there aren't many >> contending devices. ?The above N based equipment performs roughly at >> the same level as fixed wimax, without the expense of the wimax >> chipsets. ?Of course I am generalizing a bit and each deployment has >> it's own requirements and challenges to be considered. > > +1 UBNT. > > Can not beat the price/performance of the equipment. ($160 for a pair of dual-pol 802.11n equipment). > > - Jared > > > > -- Jeffrey Lyon, Leadership Team jeffrey.lyon at blacklotus.net | http://www.blacklotus.net Black Lotus Communications - AS32421 First and Leading in DDoS Protection Solutions From jgreco at ns.sol.net Mon Sep 20 14:04:26 2010 From: jgreco at ns.sol.net (Joe Greco) Date: Mon, 20 Sep 2010 09:04:26 -0500 (CDT) Subject: Did Internet Founders Actually Anticipate Paid, In-Reply-To: Message-ID: <201009201404.o8KE4QRI006288@aurora.sol.net> > > Of course the high level of oversub is an issue.... > > We'll disagree then. Oversub makes access affordable. We don't disagree. Of course oversub makes access affordable. The point here is that carriers aren't willing to commit to supporting some level of service. Many people have recognized that a lack of net neutrality is an incentive for service providers to either tacitly allow congestion points to evolve in their networks, or, worse, deliberately engineer such a situation, with dollar signs flashing in Ed Whitacre's eyes at the idea of being able to bill a third party. That's pretty much the opposite end of the spectrum from committing to supporting some level of service. > >..with the scary boogeyman of evil illegal P2P filesharing > > That just tips the money in the wrong direction. And it's a real threat > (amongst others)...not just that deadly clown hiding under your bed. A real threat? Oh, please, get real. A _real_ threat is what happens as cable and satellite providers keep jacking their rates, and more and more of the "next generation" of television viewers stop subscribing to conventional television distribution because they're able to get content over the Internet. That's a real threat. When your HD television comes with Netflix Live On Demand built in, even grandma will be clicking on movies, I'll bet. > > Consider: the practical reality is that we're seeing more and more > > gizmos that do more and more network things. We're going to see > > DVR's downloading content over the Internet, you'll see your nav > > system downloading map updates over the Internet, these are all > > "new" devices that didn't exist ~10 years ago in their current form, > > and they're changing consumer usage patterns. > > Yeah, I think we all know and see that stuff. But, unless some > technological model changes bit pricing, the premise of oversub still wins. > Going 1:1 today (or in the near future) makes no sense unless you layer > something on top (advertising, qos, buttercream icing?). Why is it that you are talking about 1:1? > >There is no reason to > > expect that the "business model" will remain useful or that any > > component of it, such as massive oversubscription, must necessarily > > be correct and remain viable in its current form, just because it > > worked a decade ago. > > Well, I'm talking 10 years ago up until present. How do you see the sub > model turning? 1:1? If so, how? And, still some profit? If you want something interesting to ponder: In the last ~10 years, wholesale bandwidth costs have fallen, what, from maybe $100/mbit to $1/mbit? I don't even know or care just how accurate that is, but roughly speaking it's true. In the last ~10 years, DSL and cable prices have stayed pretty much consistent. Our local cable connections have maybe doubled in speed in that time. DSL speeds haven't changed, except for Uverse, which is a bit of an exception for a number of reasons. Now obviously building the network costs something, but fifteen years after they started providing service, I'm guessing that's been paid for. They don't seem to be dumping lots of funds into increasing their network speeds. That suggests profit. Do you have an alternative explanation? I'm looking at the current scenario, and what I see are monopolies who are afraid of the future. at&t is already witnessing the destruction of its legacy telephony business, the demise of ridiculous long distance rates, etc. The Comcasts of the world have got to recognize that the ability for customers to avoid paying a monthly cable fee by getting video over the net is bad for business. So you have cable and telco, both telecom businesses with Something To Lose, both of whom incidentally are also the gatekeepers of residential Internet service. The killer point, though, is when you look at what's happening in other areas of the world. You can see broadband Internet services elsewhere evolving. You can even see rogues here in the US (I'm looking at you, Sonic!) who are pushing the envelope. The reality is that the world is changing, and subscribers are going to be pushing more and more data, often without even recognizing that fact. ... 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 tmikelson at gmail.com Mon Sep 20 14:04:49 2010 From: tmikelson at gmail.com (Tom Mikelson) Date: Mon, 20 Sep 2010 08:04:49 -0600 Subject: Active Directory requires Microsoft DNS? Message-ID: Presently our organization utilizes BIND for DNS services, with the Networking team administering. We are now being told by the Systems team that they will be responsible for DNS services and that it will be changed over to the Microsoft DNS service run on domain controllers. The reason given is that the Active Directory implementation requires the Microsoft DNS service and dynamic DNS. Not being a Microsoft administrator I do not know the veracity of these claims. Anyone out there had any experiences with a situation like this? I am a bit leery of changing something that is already working. From jared at puck.nether.net Mon Sep 20 14:09:52 2010 From: jared at puck.nether.net (Jared Mauch) Date: Mon, 20 Sep 2010 10:09:52 -0400 Subject: Active Directory requires Microsoft DNS? In-Reply-To: References: Message-ID: http://technet.microsoft.com/en-us/library/dd316373.aspx On Sep 20, 2010, at 10:04 AM, Tom Mikelson wrote: > Presently our organization utilizes BIND for DNS services, with the > Networking team administering. We are now being told by the Systems team > that they will be responsible for DNS services and that it will be changed > over to the Microsoft DNS service run on domain controllers. The reason > given is that the Active Directory implementation requires the Microsoft DNS > service and dynamic DNS. Not being a Microsoft administrator I do not know > the veracity of these claims. Anyone out there had any experiences with a > situation like this? I am a bit leery of changing something that is already > working. From mhuff at ox.com Mon Sep 20 14:11:14 2010 From: mhuff at ox.com (Matthew Huff) Date: Mon, 20 Sep 2010 10:11:14 -0400 Subject: Active Directory requires Microsoft DNS? In-Reply-To: References: Message-ID: <483E6B0272B0284BA86D7596C40D29F9E2C7B8063E@PUR-EXCH07.ox.com> Microsoft Active directory absolutely needs dynamic DNS. However, I know that it has been integrated with bind, so I don't believe it needs Microsoft DNS. A common procedure is to delegate a subdomain to the microsoft dns server and let the Active Directory forest be built within that environment. ---- 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: Tom Mikelson [mailto:tmikelson at gmail.com] > Sent: Monday, September 20, 2010 10:05 AM > To: nanog at nanog.org > Subject: Active Directory requires Microsoft DNS? > > Presently our organization utilizes BIND for DNS services, with the > Networking team administering. We are now being told by the Systems team > that they will be responsible for DNS services and that it will be changed > over to the Microsoft DNS service run on domain controllers. The reason > given is that the Active Directory implementation requires the Microsoft DNS > service and dynamic DNS. Not being a Microsoft administrator I do not know > the veracity of these claims. Anyone out there had any experiences with a > situation like this? I am a bit leery of changing something that is already > working. -------------- next part -------------- A non-text attachment was scrubbed... Name: Matthew Huff.vcf Type: text/x-vcard Size: 1612 bytes Desc: Matthew Huff.vcf URL: From john-nanog at johnpeach.com Mon Sep 20 14:12:11 2010 From: john-nanog at johnpeach.com (John Peach) Date: Mon, 20 Sep 2010 10:12:11 -0400 Subject: Active Directory requires Microsoft DNS? In-Reply-To: References: Message-ID: <20100920101211.0334d1c6@jpeach-desktop> It does not need MS DNS. $dayjob uses Infoblox appliances (BIND under the hood) for DNS and it works fine with AD. You just need to make sure you allow the Domain Controllers to do dynamic updates (AD uses SRV records). On Mon, 20 Sep 2010 08:04:49 -0600 Tom Mikelson wrote: > Presently our organization utilizes BIND for DNS services, with the > Networking team administering. We are now being told by the Systems > team that they will be responsible for DNS services and that it will > be changed over to the Microsoft DNS service run on domain > controllers. The reason given is that the Active Directory > implementation requires the Microsoft DNS service and dynamic DNS. > Not being a Microsoft administrator I do not know the veracity of > these claims. Anyone out there had any experiences with a situation > like this? I am a bit leery of changing something that is already > working. -- John From jeroen at unfix.org Mon Sep 20 14:12:31 2010 From: jeroen at unfix.org (Jeroen Massar) Date: Mon, 20 Sep 2010 16:12:31 +0200 Subject: Active Directory requires Microsoft DNS? In-Reply-To: References: Message-ID: <4C976BCF.9060306@unfix.org> On 2010-09-20 16:04, Tom Mikelson wrote: > Presently our organization utilizes BIND for DNS services, with the > Networking team administering. We are now being told by the Systems team > that they will be responsible for DNS services and that it will be changed > over to the Microsoft DNS service run on domain controllers. The reason > given is that the Active Directory implementation requires the Microsoft DNS > service and dynamic DNS. Not being a Microsoft administrator I do not know > the veracity of these claims. Anyone out there had any experiences with a > situation like this? I am a bit leery of changing something that is already > working. Use the Force: google(Active Directory BIND) http://technet.microsoft.com/en-us/library/dd316373.aspx which is a document from 2001 btw.... Greets, Jeroen From MatlockK at exempla.org Mon Sep 20 14:13:03 2010 From: MatlockK at exempla.org (Matlock, Kenneth L) Date: Mon, 20 Sep 2010 08:13:03 -0600 Subject: Active Directory requires Microsoft DNS? In-Reply-To: References: Message-ID: <4288131ED5E3024C9CD4782CECCAD2C70B9A2E09@LMC-MAIL2.exempla.org> Active directly is tied fairly closely to it's DNS. For example, if a client needs to find a Domain Controller, it does a DNS 'SRV' query for (I think, I'm doing this from memory) '_LDAP._TCP.domain.com/org/net/whatever'. I assume other 'services' like LDAP are 'advertised' (if you can call it that) via DNS as well. You MAY be able to duplicate all the records in BIND, but expect random things to not work, and have to do a bunch of research figuring out what DNS query it's doing, and what the proper answer is. Ken Matlock Network Analyst Exempla Healthcare (303) 467-4671 matlockk at exempla.org -----Original Message----- From: Tom Mikelson [mailto:tmikelson at gmail.com] Sent: Monday, September 20, 2010 8:05 AM To: nanog at nanog.org Subject: Active Directory requires Microsoft DNS? Presently our organization utilizes BIND for DNS services, with the Networking team administering. We are now being told by the Systems team that they will be responsible for DNS services and that it will be changed over to the Microsoft DNS service run on domain controllers. The reason given is that the Active Directory implementation requires the Microsoft DNS service and dynamic DNS. Not being a Microsoft administrator I do not know the veracity of these claims. Anyone out there had any experiences with a situation like this? I am a bit leery of changing something that is already working. From jeff-kell at utc.edu Mon Sep 20 14:17:28 2010 From: jeff-kell at utc.edu (Jeff Kell) Date: Mon, 20 Sep 2010 10:17:28 -0400 Subject: Active Directory requires Microsoft DNS? In-Reply-To: References: Message-ID: <4C976CF8.8070906@utc.edu> That has been the stock MS answer for a long time, but at least W2K8 makes a few concessions. Technet has some references on making "bind" configurations to work with AD, specifically the statement (and here's perhaps the best place to start...): > When a domain controller is promoted, a file named NETLOGON.DNS is created in the > %systemroot%\system32\config folder. This file contains all of the DNS entries the > domain controller would register. This file can be used to aid in statically entering > Active Directory DNS records. There are still "assumptions" that not only will MS provide DNS, but also DHCP, and even if you poke both of them properly with non-MS tools, you still have to insure that your naming conventions are going to work together properly (e.g., search suffix on DNS lookups to resolve domain resources when Windows clients will inevitably use an unqualified \\servername\sharename to access things). Get your windows folks in the habit of fully-qualifying servernames.domain.tld instead. Jeff On 9/20/2010 10:04 AM, Tom Mikelson wrote: > Presently our organization utilizes BIND for DNS services, with the > Networking team administering. We are now being told by the Systems team > that they will be responsible for DNS services and that it will be changed > over to the Microsoft DNS service run on domain controllers. The reason > given is that the Active Directory implementation requires the Microsoft DNS > service and dynamic DNS. Not being a Microsoft administrator I do not know > the veracity of these claims. Anyone out there had any experiences with a > situation like this? I am a bit leery of changing something that is already > working. > From joesox at gmail.com Mon Sep 20 14:23:08 2010 From: joesox at gmail.com (JoeSox) Date: Mon, 20 Sep 2010 07:23:08 -0700 Subject: Active Directory requires Microsoft DNS? In-Reply-To: <4288131ED5E3024C9CD4782CECCAD2C70B9A2E09@LMC-MAIL2.exempla.org> References: <4288131ED5E3024C9CD4782CECCAD2C70B9A2E09@LMC-MAIL2.exempla.org> Message-ID: I have seen BIND to MS DNS zone transfers work fine before. -- Thanks, Joe On Mon, Sep 20, 2010 at 7:13 AM, Matlock, Kenneth L wrote: > Active directly is tied fairly closely to it's DNS. > > For example, if a client needs to find a Domain Controller, it does a > DNS 'SRV' query for (I think, I'm doing this from memory) > '_LDAP._TCP.domain.com/org/net/whatever'. I assume other 'services' like > LDAP are 'advertised' (if you can call it that) via DNS as well. > > You MAY be able to duplicate all the records in BIND, but expect random > things to not work, and have to do a bunch of research figuring out what > DNS query it's doing, and what the proper answer is. > > Ken Matlock > Network Analyst > Exempla Healthcare > (303) 467-4671 > matlockk at exempla.org > > > > -----Original Message----- > From: Tom Mikelson [mailto:tmikelson at gmail.com] > Sent: Monday, September 20, 2010 8:05 AM > To: nanog at nanog.org > Subject: Active Directory requires Microsoft DNS? > > Presently our organization utilizes BIND for DNS services, with the > Networking team administering. ?We are now being told by the Systems > team > that they will be responsible for DNS services and that it will be > changed > over to the Microsoft DNS service run on domain controllers. ?The reason > given is that the Active Directory implementation requires the Microsoft > DNS > service and dynamic DNS. ?Not being a Microsoft administrator I do not > know > the veracity of these claims. ?Anyone out there had any experiences with > a > situation like this? ?I am a bit leery of changing something that is > already > working. > > From jamie at photon.com Mon Sep 20 14:51:57 2010 From: jamie at photon.com (Jamie Bowden) Date: Mon, 20 Sep 2010 10:51:57 -0400 Subject: Active Directory requires Microsoft DNS? In-Reply-To: References: Message-ID: <5C836A1A98186142A6BEC393FD5E2A86015701@hal.photon.com> Our Corporate Overlords run DNS on a mixed environment of Windows and Other (mostly other). Back when we were still a small company, we moved our DNS from BIND to Windows for ease of administration. It CAN be done, but it's a huge PITA since AD does things in DNS that aren't standard (and in fact, violate it willfully and knowingly to make MS Kerberos bits happy). I had my Unix servers acting as secondary servers to serve their clients off the AD primary servers, and that worked just fine. Windows Server 2003 and later are extremely stable and we've had no issues with them taking over DNS duties (I've long since just pointed all my Unix boxes at the Windows servers for DNS since the Windows servers have been so stable and reliable). Jamie -----Original Message----- From: Tom Mikelson [mailto:tmikelson at gmail.com] Sent: Monday, September 20, 2010 10:05 AM To: nanog at nanog.org Subject: Active Directory requires Microsoft DNS? Presently our organization utilizes BIND for DNS services, with the Networking team administering. We are now being told by the Systems team that they will be responsible for DNS services and that it will be changed over to the Microsoft DNS service run on domain controllers. The reason given is that the Active Directory implementation requires the Microsoft DNS service and dynamic DNS. Not being a Microsoft administrator I do not know the veracity of these claims. Anyone out there had any experiences with a situation like this? I am a bit leery of changing something that is already working. From bill at herrin.us Mon Sep 20 15:11:26 2010 From: bill at herrin.us (William Herrin) Date: Mon, 20 Sep 2010 11:11:26 -0400 Subject: Did Internet Founders Actually Anticipate Paid, Prioritized Traffic? In-Reply-To: <1009171744.AA02979@ivan.Harhan.ORG> References: <1009171744.AA02979@ivan.Harhan.ORG> Message-ID: On Fri, Sep 17, 2010 at 1:44 PM, Michael Sokolov wrote: > Ditto with CLECs like Covad-now-MegaPath: even though they don't get > access to the FTTN infrastructure, no telco is evicting their legacy CO > presence. ?Therefore, if a kooky customer like me wishes to forego fiber > speeds and prefers the slower all-copper solution, I can still get SDSL > from the CLEC, and the ILEC (AT&T) will be required to provide a direct > copper pair from that CLEC's cage inside the CO to the customer premise, > no matter how much they wish for these copper pairs to die. As I understand it, that's not quite true. The ILEC is only required to provide a copper pair to a CLEC as an unbundled element IF ONE IS AVAILABLE. The ILEC has no deadline for installing new copper for the CLEC, only the requirement that the CLEC gets the next one available. If you think about it, it's obvious why: unbundling was intended to require ILECs to share in the businesses in which they already engage, not enter or remain in businesses they don't want to be in. And of course when Verizon installs Fios, they remove the old copper pairs so that they're no longer available for use. After all, Verizon wants to retire the copper infrastructure as quickly as possible so they can quit maintaining it. There are some games one can play. You can order an then cancel a service from the ILEC that would require them to install new copper, and that'll sometimes induce the copper installation that the CLEC needs to have their outstanding order. But that doesn't always work. It gets... labyrinthine. > if a kooky customer like me wishes to forego fiber > speeds and prefers the slower all-copper solution, Of course, if the companies were required to unbundle *all* of the physical path elements (including fiber) we might not need a network neutrality debate. Sadly, the cable companies' technology does not easily unbundle and it would probably be unfair to require the telcos to unbundle when the same burden isn't placed on the cable companies. So, the debate moves to a different chokepoint where both technologies can be treated the same: packet treatment. 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 Mon Sep 20 16:02:34 2010 From: jbates at brightok.net (Jack Bates) Date: Mon, 20 Sep 2010 11:02:34 -0500 Subject: Active Directory requires Microsoft DNS? In-Reply-To: <4288131ED5E3024C9CD4782CECCAD2C70B9A2E09@LMC-MAIL2.exempla.org> References: <4288131ED5E3024C9CD4782CECCAD2C70B9A2E09@LMC-MAIL2.exempla.org> Message-ID: <4C97859A.4050500@brightok.net> On 9/20/2010 9:13 AM, Matlock, Kenneth L wrote: > You MAY be able to duplicate all the records in BIND, but expect random > things to not work, and have to do a bunch of research figuring out what > DNS query it's doing, and what the proper answer is. > The AD server will populate out the necessary records to the dDNS server. I setup an empty base dDNS subdomain and everything was populated out by the AD server. Handles a long list of SRV records, and v4/v6 forwards were automatically populated for both servers and clients. I have a very basic setup, which works perfectly for my needs. As to if more advanced features are broken by using BIND, I have no idea. Jack From nathan at atlasnetworks.us Mon Sep 20 16:16:24 2010 From: nathan at atlasnetworks.us (Nathan Eisenberg) Date: Mon, 20 Sep 2010 16:16:24 +0000 Subject: Active Directory requires Microsoft DNS? In-Reply-To: References: Message-ID: <8C26A4FDAE599041A13EB499117D3C28405EB70A@ex-mb-2.corp.atlasnetworks.us> If your AD domain is a subdomain, like corp.job.com, you can always delegate the subdomain's name service to the MS DNS servers from the BIND servers. That way, you don't have to make huge changes to your existing environment. > -----Original Message----- > From: Tom Mikelson [mailto:tmikelson at gmail.com] > Sent: Monday, September 20, 2010 7:05 AM > To: nanog at nanog.org > Subject: Active Directory requires Microsoft DNS? > > Presently our organization utilizes BIND for DNS services, with the Networking > team administering. We are now being told by the Systems team that they will > be responsible for DNS services and that it will be changed over to the > Microsoft DNS service run on domain controllers. The reason given is that the > Active Directory implementation requires the Microsoft DNS service and > dynamic DNS. Not being a Microsoft administrator I do not know the veracity > of these claims. Anyone out there had any experiences with a situation like > this? I am a bit leery of changing something that is already working. > > From bill at herrin.us Mon Sep 20 15:59:44 2010 From: bill at herrin.us (William Herrin) Date: Mon, 20 Sep 2010 11:59:44 -0400 Subject: Did Internet Founders Actually Anticipate Paid, In-Reply-To: References: <201009181838.o8IIc1NM080494@aurora.sol.net> Message-ID: On Sat, Sep 18, 2010 at 2:51 PM, Tony Varriale wrote: >> Of course the high level of oversub is an issue.... > > We'll disagree then. ?Oversub makes access affordable. Sure, at 10:1. At 100:1, oversub makes the service perform like crap. With QOS, it still performs like crap. The difference is that the popular stuff is modestly less crappy while all the not-as-popular stuff goes from crappy to non-functional. In my career I've encountered many QOS implementations. Only one of them did more good than harm: a college customer of mine had a T3's worth of demand but was only willing to pay for a pair of T1s. In other words, the *customer* intentionally chose to operate with a badly saturated pipe. QOS targetted only at peer to peer brought the rest of the uses back to a more or less tolerable level of performance. I note that I lost the customer the next year anyway. Tolerable != pleasant. They were unhappy with the service, even if it was their own fault. I might be more sympathetic to your viewpoint if "pick your oversub level" was part of the signup process, but it isn't. You hide that decision where your customers can't even find out what decision you made. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From jcdill.lists at gmail.com Mon Sep 20 16:55:19 2010 From: jcdill.lists at gmail.com (JC Dill) Date: Mon, 20 Sep 2010 09:55:19 -0700 Subject: Did Internet Founders Actually Anticipate Paid, In-Reply-To: <201009201404.o8KE4QRI006288@aurora.sol.net> References: <201009201404.o8KE4QRI006288@aurora.sol.net> Message-ID: <4C9791F7.90306@gmail.com> Joe Greco wrote: > In the last ~10 years, wholesale bandwidth costs have fallen, what, from > maybe $100/mbit to $1/mbit? I don't even know or care just how accurate > that is, but roughly speaking it's true. > > In the last ~10 years, DSL and cable prices have stayed pretty much > consistent. Our local cable connections have maybe doubled in speed in > that time. DSL speeds haven't changed, except for Uverse, which is a > bit of an exception for a number of reasons. > > Now obviously building the network costs something, but fifteen years > after they started providing service, I'm guessing that's been paid for. > They don't seem to be dumping lots of funds into increasing their network > speeds. That suggests profit. Do you have an alternative explanation? Physics. The reason consumer connection speeds haven't increased is pure physics, they haven't figured out how to get packets to flow any faster over the last mile on the existing copper network, without spending megabucks to trench fiber to the home. The Telcos are afraid to spend the CapX to proactively trench in new technology (e.g. fiber) only to find that a new technology (e.g. 5G or 6G cell service) delivers faster bandwidth over some other path, and whoever trenches in the fiber goes BK before they can recover their costs. Anyone remember Ricochet? They spent a fortune on putting in a wireless network in Silicon Valley that was over-run by the cellular networks moving into broadband, providing faster and more ubiquitous service, service that worked while you were in-motion (Ricochet didn't work on a bus or train, it wasn't designed to hand off to neighboring cells). Buh By Richchet. Meanwhile, consumer utilization of their available last-mile bandwidth has gone up. 10 years ago how many people were watching downloaded movies, exchanging software with P2P, using skype video, etc? # Feb. 12, 2008. In a net neutrality filing with the FCC, Comcast stated (p. 13, footnote 31) that "[o]n average, each Comcast High-Speed Internet customer uses more than 40% more bandwidth today than one year ago." (Cite: ) Anyone have handy graphs showing end user bandwidth consumption on broadband connections over time, say from ~2000-2010? A big part of the cost in providing service to end consumers is customer support and install costs, not the cost to move bits. Wild-ass speculation: This is why your base cable bill, your base broadband bill, your base POTS phone bill, your base cell phone bill, etc. hovers in the $20-30/month range, it simply costs that much to provide the people network (customer support, truck roll technical support, etc.) to support the customer, even though the underlying network cost to deliver the actual product is far less. (This is also why many systems dropped per-minute and per-call billing for local and in-country calls, because the cost to measure and bill for, and deal with customer complaints about, these metrics aren't worth doing - it's cheaper to raise the price slightly and give the user "unlimited" calling.) Of course, I could be wrong, but I know which way I'd bet on this question - do you want to give me odds? :-) jc From owen at delong.com Mon Sep 20 17:11:57 2010 From: owen at delong.com (Owen DeLong) Date: Mon, 20 Sep 2010 10:11:57 -0700 Subject: Did Internet Founders Actually Anticipate Paid, In-Reply-To: <201009201404.o8KE4QRI006288@aurora.sol.net> References: <201009201404.o8KE4QRI006288@aurora.sol.net> Message-ID: <29FCF084-33C9-452A-8EF9-A85F5C604FD8@delong.com> On Sep 20, 2010, at 7:04 AM, Joe Greco wrote: >>> Of course the high level of oversub is an issue.... >> >> We'll disagree then. Oversub makes access affordable. > > We don't disagree. Of course oversub makes access affordable. The point > here is that carriers aren't willing to commit to supporting some level > of service. Many people have recognized that a lack of net neutrality is > an incentive for service providers to either tacitly allow congestion > points to evolve in their networks, or, worse, deliberately engineer such > a situation, with dollar signs flashing in Ed Whitacre's eyes at the idea > of being able to bill a third party. That's pretty much the opposite end > of the spectrum from committing to supporting some level of service. > Exactly... Have we learned nothing from the Enron experience in California? >>> ..with the scary boogeyman of evil illegal P2P filesharing >> >> That just tips the money in the wrong direction. And it's a real threat >> (amongst others)...not just that deadly clown hiding under your bed. > > A real threat? Oh, please, get real. A _real_ threat is what happens as > cable and satellite providers keep jacking their rates, and more and more > of the "next generation" of television viewers stop subscribing to > conventional television distribution because they're able to get content > over the Internet. That's a real threat. When your HD television comes > with Netflix Live On Demand built in, even grandma will be clicking on > movies, I'll bet. > You lost me here, Joe. Threat to whom? How is it a bad thing that consumers gain additional choices for sourcing content they want? What is wrong with Grandma enjoying Netflix from her built-in interface in her television? > >>> There is no reason to >>> expect that the "business model" will remain useful or that any >>> component of it, such as massive oversubscription, must necessarily >>> be correct and remain viable in its current form, just because it >>> worked a decade ago. >> >> Well, I'm talking 10 years ago up until present. How do you see the sub >> model turning? 1:1? If so, how? And, still some profit? > > If you want something interesting to ponder: > > In the last ~10 years, wholesale bandwidth costs have fallen, what, from > maybe $100/mbit to $1/mbit? I don't even know or care just how accurate > that is, but roughly speaking it's true. > > In the last ~10 years, DSL and cable prices have stayed pretty much > consistent. Our local cable connections have maybe doubled in speed in > that time. DSL speeds haven't changed, except for Uverse, which is a > bit of an exception for a number of reasons. > > Now obviously building the network costs something, but fifteen years > after they started providing service, I'm guessing that's been paid for. > They don't seem to be dumping lots of funds into increasing their network > speeds. That suggests profit. Do you have an alternative explanation? > Actually a lot of money goes into evolving technologies on the last-mile side. It's a bit of an arms race. For example, the reason your cable connections have doubled in speed is some pretty massive hardware upgrades to get from DOCSIS2 to DOCSIS3. There's also going to be quite a bit of investment to get the DSL networks ready for IPv6. The last mile remains an expensive place to play with minimal margins. The costs there have little to do with wholesale bandwidth pricing where your statements about once the network is built it costs less to keep it running are much more accurate. > I'm looking at the current scenario, and what I see are monopolies who > are afraid of the future. at&t is already witnessing the destruction of > its legacy telephony business, the demise of ridiculous long distance > rates, etc. The Comcasts of the world have got to recognize that the > ability for customers to avoid paying a monthly cable fee by getting > video over the net is bad for business. So you have cable and telco, > both telecom businesses with Something To Lose, both of whom incidentally > are also the gatekeepers of residential Internet service. > Yes and no. To some extent, I think the smarter ones (I won't name names on either side in this message) actually see this as an opportunity to simplify their network and treat IP as a unified delivery platform for all of those traditionally disparate services. Yes, there's got to be some fear, but, a smart and sustainable business turns fear into opportunity. > The killer point, though, is when you look at what's happening in other > areas of the world. You can see broadband Internet services elsewhere > evolving. You can even see rogues here in the US (I'm looking at you, > Sonic!) who are pushing the envelope. > > The reality is that the world is changing, and subscribers are going to > be pushing more and more data, often without even recognizing that fact. > Yep. Especially when we get the end-to-end model back and subscribers are able to be publishers just as easily as anyone else. That's a good thing. We should seek to embrace it. Owen From owen at delong.com Mon Sep 20 17:43:20 2010 From: owen at delong.com (Owen DeLong) Date: Mon, 20 Sep 2010 10:43:20 -0700 Subject: Did Internet Founders Actually Anticipate Paid, In-Reply-To: References: <201009181838.o8IIc1NM080494@aurora.sol.net> Message-ID: <47C24175-66AA-47D9-B8AA-2EF21300F911@delong.com> On Sep 20, 2010, at 8:59 AM, William Herrin wrote: > On Sat, Sep 18, 2010 at 2:51 PM, Tony Varriale wrote: >>> Of course the high level of oversub is an issue.... >> >> We'll disagree then. Oversub makes access affordable. > > Sure, at 10:1. At 100:1, oversub makes the service perform like crap. > With QOS, it still performs like crap. The difference is that the > popular stuff is modestly less crappy while all the not-as-popular > stuff goes from crappy to non-functional. > Only if the QoS is tilted in favor of the popular stuff. The concern here isn't QoS in favor of the popular stuff... The concern here is QoS in favor of one particular brand of service X vs another. (e.g. Netflix vs. Hulu). If QoS favors unpopular but more profitable services, it can make the user experience for those services significantly less crappy than the competing more popular services and actually drive shifts in consumer behavior towards the less popular services. Of course, as this succeeds, it becomes self-defeating over the long run, but, only if your goal is to provide good service to your customers. If your goal is to keep your customers spending $minimal per month and stay attached to your service while using QoS payments from content providers to drive much larger margins, then, you can make a circuit through the content providers watching each one's popularity wax and wane as you screw with their QoS based on the money you get. This is very bad for the consumer and, IMHO, should not be allowed. > In my career I've encountered many QOS implementations. Only one of > them did more good than harm: a college customer of mine had a T3's > worth of demand but was only willing to pay for a pair of T1s. In > other words, the *customer* intentionally chose to operate with a > badly saturated pipe. QOS targetted only at peer to peer brought the > rest of the uses back to a more or less tolerable level of > performance. > You are still making the mistake of assuming that the ISP is interested primarily in providing good service to their customers. When you move this from customer-oriented good service model to profit-oriented model built around keeping the pain threshold just barely within the consumer's tolerance, it becomes an entirely different game. Owen From justin.horstman at gorillanation.com Mon Sep 20 18:08:43 2010 From: justin.horstman at gorillanation.com (Justin Horstman) Date: Mon, 20 Sep 2010 11:08:43 -0700 Subject: Did Internet Founders Actually Anticipate Paid, In-Reply-To: <47C24175-66AA-47D9-B8AA-2EF21300F911@delong.com> References: <201009181838.o8IIc1NM080494@aurora.sol.net> <47C24175-66AA-47D9-B8AA-2EF21300F911@delong.com> Message-ID: <8C164D3BAF7C7F41B9B286385037B1310D3646D67D@lax-exch-fe-01.gorillanation.local> > -----Original Message----- > From: Owen DeLong [mailto:owen at delong.com] > Sent: Monday, September 20, 2010 10:43 AM > To: William Herrin > Cc: NANOG > Subject: Re: Did Internet Founders Actually Anticipate Paid, > > > On Sep 20, 2010, at 8:59 AM, William Herrin wrote: > > > On Sat, Sep 18, 2010 at 2:51 PM, Tony Varriale > wrote: > >>> Of course the high level of oversub is an issue.... > >> > >> We'll disagree then. Oversub makes access affordable. > > > > Sure, at 10:1. At 100:1, oversub makes the service perform like crap. > > With QOS, it still performs like crap. The difference is that the > > popular stuff is modestly less crappy while all the not-as-popular > > stuff goes from crappy to non-functional. > > > Only if the QoS is tilted in favor of the popular stuff. The concern > here isn't QoS in favor of the popular stuff... The concern here > is QoS in favor of one particular brand of service X vs another. > (e.g. Netflix vs. Hulu). > > If QoS favors unpopular but more profitable services, it can make > the user experience for those services significantly less crappy > than the competing more popular services and actually drive > shifts in consumer behavior towards the less popular services. > > Of course, as this succeeds, it becomes self-defeating over the > long run, but, only if your goal is to provide good service to your > customers. > > If your goal is to keep your customers spending $minimal per month > and stay attached to your service while using QoS payments from > content providers to drive much larger margins, then, you can > make a circuit through the content providers watching each > one's popularity wax and wane as you screw with their QoS > based on the money you get. > > This is very bad for the consumer and, IMHO, should not be allowed. > > > In my career I've encountered many QOS implementations. Only one of > > them did more good than harm: a college customer of mine had a T3's > > worth of demand but was only willing to pay for a pair of T1s. In > > other words, the *customer* intentionally chose to operate with a > > badly saturated pipe. QOS targetted only at peer to peer brought the > > rest of the uses back to a more or less tolerable level of > > performance. > > > You are still making the mistake of assuming that the ISP is interested > primarily in providing good service to their customers. When you move > this from customer-oriented good service model to profit-oriented > model built around keeping the pain threshold just barely within > the consumer's tolerance, it becomes an entirely different game. > > Owen > Devil's Advocate here, What would you say to ISP A that provided similar speeds as ISP B, but B took payments from content providers and then provided the service for free? Gives you the choice, ISP A, which costs, and ISP B, which is free, and most people wouldn't know the difference. ~J From jgreco at ns.sol.net Mon Sep 20 18:19:43 2010 From: jgreco at ns.sol.net (Joe Greco) Date: Mon, 20 Sep 2010 13:19:43 -0500 (CDT) Subject: Did Internet Founders Actually Anticipate Paid, In-Reply-To: <29FCF084-33C9-452A-8EF9-A85F5C604FD8@delong.com> Message-ID: <201009201819.o8KIJhXD009111@aurora.sol.net> > > A real threat? Oh, please, get real. A _real_ threat is what happens as > > cable and satellite providers keep jacking their rates, and more and more > > of the "next generation" of television viewers stop subscribing to > > conventional television distribution because they're able to get content > > over the Internet. That's a real threat. When your HD television comes > > with Netflix Live On Demand built in, even grandma will be clicking on > > movies, I'll bet. > > You lost me here, Joe. Threat to whom? How is it a bad thing that > consumers gain additional choices for sourcing content they want? > What is wrong with Grandma enjoying Netflix from her built-in interface > in her television? I'm sorry, "threat" in the primary ways that one could mean that, as something that's destined to melt down Internet connections and slag service provider infrastructure, and as a threat to existing revenue. *I* see it as perfectly reasonable that consumers should gain additional choices for sourcing content that they want, and if you look at the archives of NANOG, you'll find out I bring out stuff like this from time to time when talking about the future of consumer Internet access. Certain service providers, and I'm guessing most notably anyone with a legacy infrastructure, companies such as at&t and Comcast, will view as a threat any models where they are bypassed and used solely as a pipe. Pipe is commodity, pipe is not particularly profitable. It's the content that generates profit, and I'm pretty sure that some executives somewhere have done the math: * Charge $39.99 a month for an Internet pipe, and no annual increases * Charge $74.99 a month for basic Cable, plus upsell potential for PPV, set-top box/DVR rental, premium channels, etc. etc, and a 5%-10% annual increase (http://money.cnn.com/2010/01/06/news/companies/cable_bill_cost_increase/index.htm) I don't have easily verifiable numbers as to the profit in each of those numbers, but it seems obvious that the one that's a bigger number and has upsell potential is going to seem more attractive to service providers. Now, the question you have to ask yourself is this, if you have a great revenue stream in the form of cable TV subscribers, and you can slow the adoption of a transition to Internet based TV by controlling and slowing the growth of broadband speeds, would it make sense to do that? My personal feeling is that the legacy providers feel threatened, and are intent on dragging their heels into the modern age. > >>> There is no reason to > >>> expect that the "business model" will remain useful or that any > >>> component of it, such as massive oversubscription, must necessarily > >>> be correct and remain viable in its current form, just because it > >>> worked a decade ago. > >> > >> Well, I'm talking 10 years ago up until present. How do you see the sub > >> model turning? 1:1? If so, how? And, still some profit? > > > > If you want something interesting to ponder: > > > > In the last ~10 years, wholesale bandwidth costs have fallen, what, from > > maybe $100/mbit to $1/mbit? I don't even know or care just how accurate > > that is, but roughly speaking it's true. > > > > In the last ~10 years, DSL and cable prices have stayed pretty much > > consistent. Our local cable connections have maybe doubled in speed in > > that time. DSL speeds haven't changed, except for Uverse, which is a > > bit of an exception for a number of reasons. > > > > Now obviously building the network costs something, but fifteen years > > after they started providing service, I'm guessing that's been paid for. > > They don't seem to be dumping lots of funds into increasing their network > > speeds. That suggests profit. Do you have an alternative explanation? > > Actually a lot of money goes into evolving technologies on the last-mile > side. It's a bit of an arms race. For example, the reason your cable > connections have doubled in speed is some pretty massive hardware > upgrades to get from DOCSIS2 to DOCSIS3. Ahhhh, no. DOCSIS2. And the last speed increase was some years ago. But what's a mere doubling? Look at other technology: In 2000, 100Mbps was "fast" and 1000baseT was bleeding edge brand new. In 2005, 1000baseT was commonplace and we were working on 10GbaseT. In 2010, 10GbaseT is now "fast" and now 100GbaseT is bleeding edge brand new. Approximate factor: 100x. In 2000, 80GB was a very large hard drive. In 2005, 500GB was a very large hard drive. In 2010, 3TB is a very large hard drive. Approximate factor: 37x. In 2000, a 1000MHz single-core CPU was a very fast CPU. In 2010, a 2500MHz 8-core CPU is a very fast CPU. Approximate factor: 20x. But fine, let's pretend for a moment that there's something special and magical about last-mile technology. Let's just look around at the rest of the world. Sweden: In Sweden, household broadband is mainly available through cable (in speeds of 128 kbit/s to 100 Mbit/s) and ADSL (256 kbit/s to 60 Mbit/s) [courtesy Wikipedia]. Boy, that sounds nothing like what's available here. > There's also going to be quite a bit of investment to get the DSL > networks ready for IPv6. The last mile remains an expensive place > to play with minimal margins. The costs there have little to do with > wholesale bandwidth pricing where your statements about once > the network is built it costs less to keep it running are much more > accurate. Have you looked at what Sonic is doing? > > I'm looking at the current scenario, and what I see are monopolies who > > are afraid of the future. at&t is already witnessing the destruction of > > its legacy telephony business, the demise of ridiculous long distance > > rates, etc. The Comcasts of the world have got to recognize that the > > ability for customers to avoid paying a monthly cable fee by getting > > video over the net is bad for business. So you have cable and telco, > > both telecom businesses with Something To Lose, both of whom incidentally > > are also the gatekeepers of residential Internet service. > > Yes and no. To some extent, I think the smarter ones (I won't name > names on either side in this message) actually see this as an > opportunity to simplify their network and treat IP as a unified delivery > platform for all of those traditionally disparate services. Yes, there's > got to be some fear, but, a smart and sustainable business turns > fear into opportunity. It could, but it also appears to have turned into a frenzy of lobbying in support of things that do not favor the consumer. > > The killer point, though, is when you look at what's happening in other > > areas of the world. You can see broadband Internet services elsewhere > > evolving. You can even see rogues here in the US (I'm looking at you, > > Sonic!) who are pushing the envelope. > > > > The reality is that the world is changing, and subscribers are going to > > be pushing more and more data, often without even recognizing that fact. > > Yep. Especially when we get the end-to-end model back and subscribers > are able to be publishers just as easily as anyone else. > > That's a good thing. We should seek to embrace it. Oh, absolutely. I just don't see that actually happening. ... 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 bill at herrin.us Mon Sep 20 18:25:31 2010 From: bill at herrin.us (William Herrin) Date: Mon, 20 Sep 2010 14:25:31 -0400 Subject: Did Internet Founders Actually Anticipate Paid, In-Reply-To: <8C164D3BAF7C7F41B9B286385037B1310D3646D67D@lax-exch-fe-01.gorillanation.local> References: <201009181838.o8IIc1NM080494@aurora.sol.net> <47C24175-66AA-47D9-B8AA-2EF21300F911@delong.com> <8C164D3BAF7C7F41B9B286385037B1310D3646D67D@lax-exch-fe-01.gorillanation.local> Message-ID: On Mon, Sep 20, 2010 at 2:08 PM, Justin Horstman wrote: > Devil's Advocate here, > > What would you say to ISP A that provided similar > speeds as ISP B, but B took payments from content > providers and then provided the service for free? > > Gives you the choice, ISP A, which costs, and ISP B, > which is free, and most people wouldn't know the difference. Justin, I'd say ISP B was incorrectly described. He doesn't provide service for free; he merely has a different customer. In ISP A, the end user is the customer but in ISP B, he isn't. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From nathan at atlasnetworks.us Mon Sep 20 18:38:04 2010 From: nathan at atlasnetworks.us (Nathan Eisenberg) Date: Mon, 20 Sep 2010 18:38:04 +0000 Subject: Did Internet Founders Actually Anticipate Paid, In-Reply-To: <8C164D3BAF7C7F41B9B286385037B1310D3646D67D@lax-exch-fe-01.gorillanation.local> References: <201009181838.o8IIc1NM080494@aurora.sol.net> <47C24175-66AA-47D9-B8AA-2EF21300F911@delong.com> <8C164D3BAF7C7F41B9B286385037B1310D3646D67D@lax-exch-fe-01.gorillanation.local> Message-ID: <8C26A4FDAE599041A13EB499117D3C28405EBA09@ex-mb-2.corp.atlasnetworks.us> > Devil's Advocate here, > > What would you say to ISP A that provided similar speeds as ISP B, but B took > payments from content providers and then provided the service for free? > > Gives you the choice, ISP A, which costs, and ISP B, which is free, and most > people wouldn't know the difference. > > ~J I would say that it's an interesting and unprecedented (to my knowledge) model. Could be an interesting business plan. I'm not sure if it's realistically viable, and it's certainly a risky proposition, but it's definitely unusual. Nathan From joelja at bogus.com Mon Sep 20 18:44:07 2010 From: joelja at bogus.com (Joel Jaeggli) Date: Mon, 20 Sep 2010 11:44:07 -0700 Subject: Did Internet Founders Actually Anticipate Paid, In-Reply-To: <8C26A4FDAE599041A13EB499117D3C28405EBA09@ex-mb-2.corp.atlasnetworks.us> References: <201009181838.o8IIc1NM080494@aurora.sol.net> <47C24175-66AA-47D9-B8AA-2EF21300F911@delong.com> <8C164D3BAF7C7F41B9B286385037B1310D3646D67D@lax-exch-fe-01.gorillanation.local> <8C26A4FDAE599041A13EB499117D3C28405EBA09@ex-mb-2.corp.atlasnetworks.us> Message-ID: <4C97AB77.9090900@bogus.com> On 9/20/10 11:38 AM, Nathan Eisenberg wrote: >> Devil's Advocate here, >> >> What would you say to ISP A that provided similar speeds as ISP B, >> but B took payments from content providers and then provided the >> service for free? >> >> Gives you the choice, ISP A, which costs, and ISP B, which is free, >> and most people wouldn't know the difference. >> >> ~J > > I would say that it's an interesting and unprecedented (to my > knowledge) model. Could be an interesting business plan. I'm not > sure if it's realistically viable, and it's certainly a risky > proposition, but it's definitely unusual. It is called netzero... state of the art 1998 business model... advertisers pay for the right to spew crap at cheapskate modem users. > Nathan > > > From bonomi at mail.r-bonomi.com Mon Sep 20 19:09:55 2010 From: bonomi at mail.r-bonomi.com (Robert Bonomi) Date: Mon, 20 Sep 2010 14:09:55 -0500 (CDT) Subject: Did Internet Founders Actually Anticipate Paid, Message-ID: <201009201909.o8KJ9tI7014557@mail.r-bonomi.com> > From nanog-bounces+bonomi=mail.r-bonomi.com at nanog.org Mon Sep 20 13:24:42 2010 > From: William Herrin > Date: Mon, 20 Sep 2010 14:25:31 -0400 > Subject: Re: Did Internet Founders Actually Anticipate Paid, > To: Justin Horstman > Cc: NANOG > > On Mon, Sep 20, 2010 at 2:08 PM, Justin Horstman > wrote: > > Devil's Advocate here, > > > > What would you say to ISP A that provided similar > > speeds as ISP B, but B took payments from content > > providers and then provided the service for free? > > > > Gives you the choice, ISP A, which costs, and ISP B, > > which is free, and most people wouldn't know the difference. > > Justin, > > I'd say ISP B was incorrectly described. He doesn't provide service > for free; he merely has a different customer. In ISP A, the end user > is the customer but in ISP B, he isn't. I'm tempted to point out that there have been severl attempts at the ISP B model. None of which are still in existance. I take that back, one or two of them may still exist, but they're not using that business model any more. From gbonser at seven.com Tue Sep 21 04:01:58 2010 From: gbonser at seven.com (George Bonser) Date: Mon, 20 Sep 2010 21:01:58 -0700 Subject: Did Internet Founders Actually Anticipate Paid, In-Reply-To: <47C24175-66AA-47D9-B8AA-2EF21300F911@delong.com> References: <201009181838.o8IIc1NM080494@aurora.sol.net> <47C24175-66AA-47D9-B8AA-2EF21300F911@delong.com> Message-ID: <5A6D953473350C4B9995546AFE9939EE0A52AE25@RWC-EX1.corp.seven.com> > Only if the QoS is tilted in favor of the popular stuff. The concern > here isn't QoS in favor of the popular stuff... The concern here > is QoS in favor of one particular brand of service X vs another. > (e.g. Netflix vs. Hulu). > > If QoS favors unpopular but more profitable services, it can make > the user experience for those services significantly less crappy > than the competing more popular services and actually drive > shifts in consumer behavior towards the less popular services. > > Of course, as this succeeds, it becomes self-defeating over the > long run, but, only if your goal is to provide good service to your > customers. Absolutely agree. This goes back to my original comment on the thread in that having a content provider pay for higher priority gives a financial incentive to the network to create congestion (or allow such congestion to occur during the course of normal bandwidth consumption increases over time) in order to collect that revenue. But there is a potential problem here in that content providers are producing applications and content requiring increasing amounts of bandwidth but are not bearing the cost of delivering that content to the end user. If the ISPs are directly peering with the content provider at some IX, the content provider gets what amounts to a free ride to the end user. They then release a new version of something that uses more bandwidth (say, going to HD video and then maybe 3D HD at some point) which puts pressure on the ISPs network resources. Do you then increase prices to the consumer in a highly competitive market and run the risk of driving your customers away, do you absorb the cost of required upgrades and run at a loss for a while only to see the applications increase in bandwidth requirements again? Do you try to get the content provider to pay for some of the "shipping" cost? In a pure transit model, the content provider's expenses would go up if they increased their bandwidth utilization which gave them a financial incentive to be innovative in ways of delivering higher quality with the lowest possible bandwidth consumption. As more people move to peering over public IX points, the burden falls on the ISPs internal network to deliver the goods and they have no control at all over the applications themselves. So bandwidth is practically "free" for the content provider and not so free for the eyeball provider. So where a content provider might be forced to upgrade from GigE to 10GigE links at exchange points (maybe adding a blade to a chassis), a service provider might be faced with congestion on potentially thousands of end user links and the gear that interconnect the PoPs. In that light I can see where they might want a fee. But a better way of looking at it is not in prioritizing anyone up, look at it the other way. Imagine an ISP says "if you don't pay us, we are going to prioritize your traffic down". So anyone who pays gets their traffic at the normal default priority, those who don't pay get in the "space available" line. Now a content provider who does not pay the toll sees a drop in users which equates to a possible drop in ad revenue. George From positivelyoptimistic at gmail.com Tue Sep 21 05:07:14 2010 From: positivelyoptimistic at gmail.com (Positively Optimistic) Date: Tue, 21 Sep 2010 01:07:14 -0400 Subject: Cisco 6509/6513 cable management... Message-ID: Do any of our fellow nanog members have experience with cable management on 6509/6513 cisco switches? We're upgrading infrastructure in some of our facilities,.. and until it came to cable management, the switches seemed to be a great idea... 8 48port blades.. pose a challenge.. or a problem.. Pictures are welcomed... off-list contact would be great. Thanks From mpalmer at hezmatt.org Tue Sep 21 05:14:18 2010 From: mpalmer at hezmatt.org (Matthew Palmer) Date: Tue, 21 Sep 2010 15:14:18 +1000 Subject: Did Internet Founders Actually Anticipate Paid, In-Reply-To: <5A6D953473350C4B9995546AFE9939EE0A52AE25@RWC-EX1.corp.seven.com> References: <47C24175-66AA-47D9-B8AA-2EF21300F911@delong.com> <5A6D953473350C4B9995546AFE9939EE0A52AE25@RWC-EX1.corp.seven.com> Message-ID: <20100921051418.GW3803@hezmatt.org> On Mon, Sep 20, 2010 at 09:01:58PM -0700, George Bonser wrote: > But there is a potential problem here in that content providers are > producing applications and content requiring increasing amounts of > bandwidth but are not bearing the cost of delivering that content to the > end user. Yes they are -- content providers aren't getting their connections to the Internet for free (and if they are, how can I get me some of that?). > If the ISPs are directly peering with the content provider at > some IX, the content provider gets what amounts to a free ride to the > end user. Say wha? ISPs don't *have* to peer at an IX; if they think that it's cheaper to buy transit from someone than it is to peer, they're more than capable of doing so. > They then release a new version of something that uses more > bandwidth (say, going to HD video and then maybe 3D HD at some point) > which puts pressure on the ISPs network resources. Do you then increase > prices to the consumer in a highly competitive market and run the risk > of driving your customers away, do you absorb the cost of required > upgrades and run at a loss for a while only to see the applications > increase in bandwidth requirements again? The customer's requesting this traffic, therefore the customer needs a bigger pipe, therefore the customer pays more. > Do you try to get the content provider to pay for some of the "shipping" > cost? Why? It was your customer who requested the traffic be delivered to them. - Matt From rdobbins at arbor.net Tue Sep 21 05:32:29 2010 From: rdobbins at arbor.net (Dobbins, Roland) Date: Tue, 21 Sep 2010 05:32:29 +0000 Subject: Did Internet Founders Actually Anticipate Paid, In-Reply-To: <5A6D953473350C4B9995546AFE9939EE0A52AE25@RWC-EX1.corp.seven.com> References: <201009181838.o8IIc1NM080494@aurora.sol.net> <47C24175-66AA-47D9-B8AA-2EF21300F911@delong.com> <5A6D953473350C4B9995546AFE9939EE0A52AE25@RWC-EX1.corp.seven.com> Message-ID: <83A77287-16FB-4587-A197-41D17D1705A7@arbor.net> On Sep 21, 2010, at 11:01 AM, George Bonser wrote: > If the ISPs are directly peering with the content provider at some IX, the content provider gets what amounts to a free ride to the end user. The counterargument is that the end-user has *already paid* the transit feeds for said content. ----------------------------------------------------------------------- Roland Dobbins // Sell your computer and buy a guitar. From yamu at ciklum.net Tue Sep 21 05:49:59 2010 From: yamu at ciklum.net (Yasir Munir Abbasi) Date: Tue, 21 Sep 2010 05:49:59 +0000 Subject: Juniper SSG-140, Monitoring and control the usage of the Internet Message-ID: <261E17F810EEC548ACD322ED2E847CE30B9B28@exten02.kyiv.ciklum.net> Hi, I have a SSG-140 Juniper Firewall. I need to ask, how can I Monitor the individual IP traffic? I mean I want to see who is taking more bandwidth. Please help me out. Thanks Yasir Munir Abbasi Senior Network Engineer EMail: yamu at ciklum.net From bill at herrin.us Tue Sep 21 05:51:11 2010 From: bill at herrin.us (William Herrin) Date: Tue, 21 Sep 2010 01:51:11 -0400 Subject: Did Internet Founders Actually Anticipate Paid, In-Reply-To: <5A6D953473350C4B9995546AFE9939EE0A52AE25@RWC-EX1.corp.seven.com> References: <201009181838.o8IIc1NM080494@aurora.sol.net> <47C24175-66AA-47D9-B8AA-2EF21300F911@delong.com> <5A6D953473350C4B9995546AFE9939EE0A52AE25@RWC-EX1.corp.seven.com> Message-ID: On Tue, Sep 21, 2010 at 12:01 AM, George Bonser wrote: > But there is a potential problem here in that content providers are > producing applications and content requiring increasing amounts of > bandwidth but are not bearing the cost of delivering that content to the > end user. ?If the ISPs are directly peering with the content provider at > some IX, the content provider gets what amounts to a free ride to the > end user. My friend, that is a straw man. ISPs have complete control over who they peer with, the size of the peering pipe they accept and whether that peering session is free or paid. If peering with Netflix will cost you more than you gain, you just don't do it. While there may well be advantages to compelling ISPs to accept peering, that's an entirely different discussion. The network neutrality debate is centered on what you do to packets while they're within your network, not who you choose to directly connect to. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From ryan.finnesey at HarrierInvestments.com Tue Sep 21 08:36:08 2010 From: ryan.finnesey at HarrierInvestments.com (Ryan Finnesey) Date: Tue, 21 Sep 2010 01:36:08 -0700 Subject: financial peering? Message-ID: <6EFFEFBAC68377459A2E972105C759EC02F1D873@EXVBE005-2.exch005intermedia.net> Does anyone know if there is a peering point setup to pass traffic to credit card processes such as First Data and or the ATM interexchange networks? Cheers Ryan From nick at foobar.org Tue Sep 21 08:43:41 2010 From: nick at foobar.org (Nick Hilliard) Date: Tue, 21 Sep 2010 09:43:41 +0100 Subject: Cisco 6509/6513 cable management... In-Reply-To: References: Message-ID: <4C98703D.7010809@foobar.org> On 21/09/2010 06:07, Positively Optimistic wrote: > Do any of our fellow nanog members have experience with cable management on > 6509/6513 cisco switches? We're upgrading infrastructure in some of our > facilities,.. and until it came to cable management, the switches seemed to > be a great idea... 8 48port blades.. pose a challenge.. or a problem.. courtesy of Richard Steenbergen: http://cluepon.net/ras/betterfiber.jpg Nick From m.lukaszuk at gmail.com Tue Sep 21 09:02:10 2010 From: m.lukaszuk at gmail.com (Marek Lukaszuk) Date: Tue, 21 Sep 2010 11:02:10 +0200 Subject: Juniper SSG-140, Monitoring and control the usage of the Internet In-Reply-To: <261E17F810EEC548ACD322ED2E847CE30B9B28@exten02.kyiv.ciklum.net> References: <261E17F810EEC548ACD322ED2E847CE30B9B28@exten02.kyiv.ciklum.net> Message-ID: On Tue, Sep 21, 2010 at 07:49, Yasir Munir Abbasi wrote: > Hi, Hi, > I have a SSG-140 Juniper Firewall. I need to ask, how can I Monitor the individual IP traffic? I mean I want to see who is taking more bandwidth. > > Please help me out. Thanks As far as I know, you will not be able to get any bandwidth usage per host from the ScreenOS. You can still get a pretty good idea who is hammering your network either by enabling logging on the policies or by analyzing the session table. In both cases you you will probably need to analyze the data on some remote host (traffic/policy logs can be send by syslog, get session output can be copy over tftp) and not on the device itself. There is no support for anything like JFlow or NetFlow on ScreenOS. > Yasir Munir Abbasi Thanks, Marek From eugen at leitl.org Tue Sep 21 10:04:52 2010 From: eugen at leitl.org (Eugen Leitl) Date: Tue, 21 Sep 2010 12:04:52 +0200 Subject: US hunters shoot down Google fibre Message-ID: <20100921100452.GQ14773@leitl.org> http://www.itnews.com.au/News/232831,us-hunters-shoot-down-google-fibre.aspx Repairers forced to ski in to Oregon back woods. Google has revealed that aerial fibre links to its data centre in Oregon were "regularly" shot down by hunters, forcing the company to put its cables underground. The search and advertising giant's network engineering manager Vijay Gill told the AusNOG conference in Sydney last week that people were trying to hit insulators on electricity distribution poles. The poles also hosted aerially-deployed fibre connected to Google's $US600 million ($A635 million) data centre in the Dalles, a small city on the Columbia River in the US state of Oregon. "What people do for sport or because they're bored, they try to shoot at the insulators," Gill said. "I have yet to see them actually hit the insulator, but they regularly shoot down the fibre. "Every November when hunting season starts invariably we know that the fibre will be shot down, so much so that we are now building an underground path [for it]." Gill said that on one occasion, a snowstorm and avalanche prevented Google from transporting repairers and gear into the area of the cut. It usually used a helicopter or a Caterpillar D9 tractor for transport. It improvised by sending three technicians on skis to "repair the fibre that got shot down". "These guys had to cross country ski for three days," Gill said. "[One guy] is carrying what is known as a fusion splicing kit on his backpack." He joked: "These guys had to go in and fix the fibre while facing gunshots "So [the] internet... [it's] more dangerous than you realise." From bill at herrin.us Tue Sep 21 12:38:37 2010 From: bill at herrin.us (William Herrin) Date: Tue, 21 Sep 2010 08:38:37 -0400 Subject: Cisco 6509/6513 cable management... In-Reply-To: References: Message-ID: On Tue, Sep 21, 2010 at 1:07 AM, Positively Optimistic wrote: > Do any of our fellow nanog members have experience with cable management on > 6509/6513 cisco switches? ? We're upgrading infrastructure in some of our > facilities,.. ?and until it came to cable management, the switches seemed to > be a great idea... ? 8 48port blades.. ?pose a challenge.. or a problem.. > > Pictures are welcomed... ? off-list contact would be great. >From Google image search: http://pics.poisonnuke.de/upload/2/Kabelsalat_Nexus7010.jpg http://pics.poisonnuke.de/upload/2/Cisco6513.jpg http://joost.blogsite.org/wordpress/wp-content/uploads/2009/03/26092008014.jpg http://lh3.ggpht.com/_jqU6k3eD83g/SYCVZXpBQMI/AAAAAAAAARg/odmVcFK3jzo/dec2008+019.JPG http://lh4.ggpht.com/_jqU6k3eD83g/So7MFuzfitI/AAAAAAAABjw/qL7ad0ZefP8/DSC01782.JPG And, of course, the easy way: http://bill.herrin.us/pictures/2008/cables-sm.jpg Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From streiner at cluebyfour.org Tue Sep 21 13:09:41 2010 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Tue, 21 Sep 2010 09:09:41 -0400 (EDT) Subject: financial peering? In-Reply-To: <6EFFEFBAC68377459A2E972105C759EC02F1D873@EXVBE005-2.exch005intermedia.net> References: <6EFFEFBAC68377459A2E972105C759EC02F1D873@EXVBE005-2.exch005intermedia.net> Message-ID: On Tue, 21 Sep 2010, Ryan Finnesey wrote: > Does anyone know if there is a peering point setup to pass traffic to > credit card processes such as First Data and or the ATM interexchange > networks? If you're talking about exchanging IP traffic with a payment processor, I don't think there is an exchange point dedicated to them. They would either buy transit from a provider, or have a presence at one or more public exchange points. If you want to use a specific payment processor, many of the ones I've seen have a way to move payment info securely over the public Internet, or if you have a large enough transaction volume (or your business policies require it), a circuit directly to the processor's network might be an option. I'm not exactly sure what you mean by an "ATM interexchange network". jms From jgreco at ns.sol.net Tue Sep 21 13:12:11 2010 From: jgreco at ns.sol.net (Joe Greco) Date: Tue, 21 Sep 2010 08:12:11 -0500 (CDT) Subject: Did Internet Founders Actually Anticipate Paid, In-Reply-To: <5A6D953473350C4B9995546AFE9939EE0A52AE25@RWC-EX1.corp.seven.com> Message-ID: <201009211312.o8LDCBiT021940@aurora.sol.net> > But there is a potential problem here in that content providers are > producing applications and content requiring increasing amounts of > bandwidth but are not bearing the cost of delivering that content to the > end user. If the ISPs are directly peering with the content provider at > some IX, the content provider gets what amounts to a free ride to the > end user. [...] > In that light I can see where they might want a fee. But a better way > of looking at it is not in prioritizing anyone up, look at it the other > way. Imagine an ISP says "if you don't pay us, we are going to > prioritize your traffic down". So anyone who pays gets their traffic at > the normal default priority, those who don't pay get in the "space > available" line. Now a content provider who does not pay the toll sees > a drop in users which equates to a possible drop in ad revenue. There's a huge risk in this. Service providers have to recognize that their customers have already paid for access; when I pay a provider for an "Internet" connection, I am not paying them to deprioritize the destination I'm trying to reach, and that would be an epic fail of "best effort". Content providers already pay fees. No content is generated and served entirely for free. Even in a "free peering" model, electricity costs money, cooling costs money, space costs money, servers cost money, and meeting some network's peering requirements generally involves peering at multiple locations. Content authors usually prefer to be paid, net ops people usually prefer to be paid, system admins usually prefer to be paid, etc. Content providers pay a lot. There are some key bits that people miss about all of this. First off, Internet Service Providers get customers because people want access to all this fantastic content that's out on the Internet. No Yahoo!, no Google, no YouTube, no Facebook, no Netflix, none of that? Can you honestly tell me that customers would keep their subscriptions to a service provider without anywhere to go? Is it the content providers who are getting a free ride? Or is it the Internet Service Providers? Perhaps they're a symbiotic relationship. Next, content providers are generally already paying their own Service Providers for access to the Internet. That might be a Cogent or a Hurricane or a ServerCentral. This covers most of the "small fry". A large guy like Google may have settlement-free peering with eyeball networks, but then again, they've invested an incredible amount of money in being a destination your customers want to get to... the truth of the matter is you, your customer, and Google all benefit from it. Finally, there's a risk that this double-edged sword could slice back at service providers. Content networks often raise funds through advertising. What happens when one day, some network (*cough ESPN360*), decides that a *SERVICE PROVIDER* should pay for the privilege of getting access to their content? I mean, after all, two can play at the game of holding the ISP's subscribers hostage, and in many areas, subscribers do have a choice between at least two service providers, in case their first choice sucks. I don't think we want this, but it could be a natural backlash. What if Google came to you and said "you will pay us a dollar per sub per month, or we will route all your traffic through a 56k link in Timbuktu"? Would most eyeball networks even have a realistic *choice*? At the end of the day, after stripping away all the distractions, the concept of prioritizing traffic looks to me like something that is ultimately intended to squeeze more revenue out of the network, and this happens by not giving the customer some of what they have already paid for: in other words, this happens at the customer's expense. ... 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 morrowc.lists at gmail.com Tue Sep 21 13:19:42 2010 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Tue, 21 Sep 2010 09:19:42 -0400 Subject: US hunters shoot down Google fibre In-Reply-To: <20100921100452.GQ14773@leitl.org> References: <20100921100452.GQ14773@leitl.org> Message-ID: this was presented at the nanog in ... SF I think as well: not really news... On Tue, Sep 21, 2010 at 6:04 AM, Eugen Leitl wrote: > > http://www.itnews.com.au/News/232831,us-hunters-shoot-down-google-fibre.aspx > > Repairers forced to ski in to Oregon back woods. > > Google has revealed that aerial fibre links to its data centre in Oregon were > "regularly" shot down by hunters, forcing the company to put its cables > underground. > > The search and advertising giant's network engineering manager Vijay Gill > told the AusNOG conference in Sydney last week that people were trying to hit > insulators on electricity distribution poles. > > The poles also hosted aerially-deployed fibre connected to Google's $US600 > million ($A635 million) data centre in the Dalles, a small city on the > Columbia River in the US state of Oregon. > > "What people do for sport or because they're bored, they try to shoot at the > insulators," Gill said. > > "I have yet to see them actually hit the insulator, but they regularly shoot > down the fibre. > > "Every November when hunting season starts invariably we know that the fibre > will be shot down, so much so that we are now building an underground path > [for it]." > > Gill said that on one occasion, a snowstorm and avalanche prevented Google > from transporting repairers and gear into the area of the cut. > > It usually used a helicopter or a Caterpillar D9 tractor for transport. It > improvised by sending three technicians on skis to "repair the fibre that got > shot down". > > "These guys had to cross country ski for three days," Gill said. > > "[One guy] is carrying what is known as a fusion splicing kit on his > backpack." > > He joked: "These guys had to go in and fix the fibre while facing gunshots > > "So [the] internet... [it's] more dangerous than you realise." > > From jbates at brightok.net Tue Sep 21 13:38:06 2010 From: jbates at brightok.net (Jack Bates) Date: Tue, 21 Sep 2010 08:38:06 -0500 Subject: Did Internet Founders Actually Anticipate Paid, In-Reply-To: <201009211312.o8LDCBiT021940@aurora.sol.net> References: <201009211312.o8LDCBiT021940@aurora.sol.net> Message-ID: <4C98B53E.8020102@brightok.net> On 9/21/2010 8:12 AM, Joe Greco wrote: > Finally, there's a risk that this double-edged sword could slice back > at service providers. Content networks often raise funds through > advertising. What happens when one day, some network (*cough ESPN360*), > decides that a *SERVICE PROVIDER* should pay for the privilege of > getting access to their content? I mean, after all, two can play at > the game of holding the ISP's subscribers hostage, and in many areas, > subscribers do have a choice between at least two service providers, > in case their first choice sucks. I don't think we want this, but it > could be a natural backlash. What if Google came to you and said "you > will pay us a dollar per sub per month, or we will route all your > traffic through a 56k link in Timbuktu"? Would most eyeball networks > even have a realistic *choice*? Yeah, wish that was illegal. The size of the provider determines the cost per capable subscriber, along with other perks, so it's a better deal for the AT&T and Verizons of the world, and sucks for the "We have 13 independent ILECs and each has to have a separate deal." Word is, they designed it with their current cable customers in mind, not the traditional ISP, so it pushes people towards the cable company. I'd accept any ISP net-neutrality arguement for content providers to stop doing that crap and support per user subscription fees. The whole beauty of the Internet video is people can pick and choose and not have to pay for things they don't use (ie, for espn3, I have to account the per customer charges into my bills and pester my customers with espn3 advertising in their bills even if they hate sports or don't watch video/tv/movies). Jack From tme at americafree.tv Tue Sep 21 13:38:37 2010 From: tme at americafree.tv (Marshall Eubanks) Date: Tue, 21 Sep 2010 09:38:37 -0400 Subject: financial peering? In-Reply-To: <6EFFEFBAC68377459A2E972105C759EC02F1D873@EXVBE005-2.exch005intermedia.net> References: <6EFFEFBAC68377459A2E972105C759EC02F1D873@EXVBE005-2.exch005intermedia.net> Message-ID: On Sep 21, 2010, at 4:36 AM, Ryan Finnesey wrote: > Does anyone know if there is a peering point setup to pass traffic to > credit card processes such as First Data and or the ATM interexchange > networks? > Cheers > Ryan > What features would you want / need that are not present on a normal Layer 3 exchange ? Exchange mediated NAT/PAT ? Regards Marshall > > From streiner at cluebyfour.org Tue Sep 21 13:38:57 2010 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Tue, 21 Sep 2010 09:38:57 -0400 (EDT) Subject: Cisco 6509/6513 cable management... In-Reply-To: References: Message-ID: On Tue, 21 Sep 2010, Positively Optimistic wrote: > Do any of our fellow nanog members have experience with cable management on > 6509/6513 cisco switches? We're upgrading infrastructure in some of our > facilities,.. and until it came to cable management, the switches seemed to > be a great idea... 8 48port blades.. pose a challenge.. or a problem.. The biggest things with 6500s, or any high-density configuration for that matter, are: 1. Using racks/cabinets that have ample space for your vertical and horizontal cabling. If you don't have this, things can get ugly in a hurry. Make sure the kit you choose has plenty of wire management channel space left over even after the racks are fully populated. Having to tear overstuffed wire management channels apart to back-pull a bad cable or jumper at 3 AM is no fun. 2. Emphasizing the importance of following established cabling standards to the people who will be touching this equipment. Having visual aids, i.e. "Here are some pictures of the quality of work we expect", usually go a lot farther to drive this point home than handing someone a 20-page cabling standards document with no pictures. 3. Dont forget about your inter-rack/overhead wiring channels/trays. I've seen a few places that had things neatly dressed in the racks, but the overhead channels were a complete mess... assumingly because they were hidden from view :). If your overhead distribution has separate channels/lanes for power/copper/fiber, even better. 4. Labeling and documentation. 5. See 4. jms From tme at americafree.tv Tue Sep 21 13:50:53 2010 From: tme at americafree.tv (Marshall Eubanks) Date: Tue, 21 Sep 2010 09:50:53 -0400 Subject: Did Internet Founders Actually Anticipate Paid, In-Reply-To: <201009211312.o8LDCBiT021940@aurora.sol.net> References: <201009211312.o8LDCBiT021940@aurora.sol.net> Message-ID: <17ABDF60-0F2C-4530-BFDE-DAAFAB81C6A5@americafree.tv> On Sep 21, 2010, at 9:12 AM, Joe Greco wrote: >> But there is a potential problem here in that content providers are >> producing applications and content requiring increasing amounts of >> bandwidth but are not bearing the cost of delivering that content to the >> end user. If the ISPs are directly peering with the content provider at >> some IX, the content provider gets what amounts to a free ride to the >> end user. > [...] >> In that light I can see where they might want a fee. But a better way >> of looking at it is not in prioritizing anyone up, look at it the other >> way. Imagine an ISP says "if you don't pay us, we are going to >> prioritize your traffic down". So anyone who pays gets their traffic at >> the normal default priority, those who don't pay get in the "space >> available" line. Now a content provider who does not pay the toll sees >> a drop in users which equates to a possible drop in ad revenue. > > There's a huge risk in this. > > Service providers have to recognize that their customers have already > paid for access; when I pay a provider for an "Internet" connection, I > am not paying them to deprioritize the destination I'm trying to reach, > and that would be an epic fail of "best effort". > > Content providers already pay fees. No content is generated and served > entirely for free. Even in a "free peering" model, electricity costs > money, cooling costs money, space costs money, servers cost money, and > meeting some network's peering requirements generally involves peering > at multiple locations. Content authors usually prefer to be paid, net > ops people usually prefer to be paid, system admins usually prefer to be > paid, etc. Content providers pay a lot. > +1 > There are some key bits that people miss about all of this. > > First off, Internet Service Providers get customers because people want > access to all this fantastic content that's out on the Internet. No > Yahoo!, no Google, no YouTube, no Facebook, no Netflix, none of that? > Can you honestly tell me that customers would keep their subscriptions > to a service provider without anywhere to go? Is it the content > providers who are getting a free ride? Or is it the Internet Service > Providers? Perhaps they're a symbiotic relationship. > > Next, content providers are generally already paying their own Service > Providers for access to the Internet. That might be a Cogent or a > Hurricane or a ServerCentral. This covers most of the "small fry". A > large guy like Google may have settlement-free peering with eyeball > networks, but then again, they've invested an incredible amount of > money in being a destination your customers want to get to... the truth > of the matter is you, your customer, and Google all benefit from it. > Every content provider, large or small, in my experience pays for Internet. Where the checks go to may vary (dark fiber vs colo charges vs ISP payments vs ...), but every content provider has (or has service providers that have) some sort of contractual arrangement with the entities they connect to and has spent money based on that. Sure, those contracts can be mutually renegotiated, prices may go up or down, etc., but letting third parties interfere with these arrangements sets a very dangerous precedent that cannot be good for the Internet as a whole (again, IMO). Regards Marshall > Finally, there's a risk that this double-edged sword could slice back > at service providers. Content networks often raise funds through > advertising. What happens when one day, some network (*cough ESPN360*), > decides that a *SERVICE PROVIDER* should pay for the privilege of > getting access to their content? I mean, after all, two can play at > the game of holding the ISP's subscribers hostage, and in many areas, > subscribers do have a choice between at least two service providers, > in case their first choice sucks. I don't think we want this, but it > could be a natural backlash. What if Google came to you and said "you > will pay us a dollar per sub per month, or we will route all your > traffic through a 56k link in Timbuktu"? Would most eyeball networks > even have a realistic *choice*? > > At the end of the day, after stripping away all the distractions, the > concept of prioritizing traffic looks to me like something that is > ultimately intended to squeeze more revenue out of the network, and > this happens by not giving the customer some of what they have already > paid for: in other words, this happens at the customer's expense. > > ... 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 tglassey at earthlink.net Tue Sep 21 13:53:38 2010 From: tglassey at earthlink.net (todd glassey) Date: Tue, 21 Sep 2010 06:53:38 -0700 Subject: financial peering? In-Reply-To: References: <6EFFEFBAC68377459A2E972105C759EC02F1D873@EXVBE005-2.exch005intermedia.net> Message-ID: <4C98B8E2.3050904@earthlink.net> On 9/21/2010 6:09 AM, Justin M. Streiner wrote: > On Tue, 21 Sep 2010, Ryan Finnesey wrote: > >> Does anyone know if there is a peering point setup to pass traffic to >> credit card processes such as First Data and or the ATM interexchange >> networks? > > If you're talking about exchanging IP traffic with a payment processor, > I don't think there is an exchange point dedicated to them. They would > either buy transit from a provider, or have a presence at one or more > public exchange points. If you want to use a specific payment > processor, many of the ones I've seen have a way to move payment info > securely over the public Internet, or if you have a large enough > transaction volume (or your business policies require it), a circuit > directly to the processor's network might be an option. > > I'm not exactly sure what you mean by an "ATM interexchange network". There are financial networking providers like SAVVIS and others who handle this. There are a number of others including parties with PCI-DSS competence in their compliance models. The evidence capture and maintanence requirements for these closed networks are very strict so, they dont allow non-players to participate in their activities. The Banking Service orgs like DIRBOLD Financial for instance or NCR or any of a couple dozen other providers do this type of thing... What specifically are you looking to do with them? > > jms > > > > > No virus found in this incoming message. > Checked by AVG - www.avg.com > Version: 9.0.851 / Virus Database: 271.1.1/3148 - Release Date: 09/20/10 10:04:00 > -- //----------------------------------------------------------------- This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. From jmamodio at gmail.com Tue Sep 21 13:58:30 2010 From: jmamodio at gmail.com (Jorge Amodio) Date: Tue, 21 Sep 2010 08:58:30 -0500 Subject: Twitter web interface exploit ... Message-ID: Don't believe it will create any network waves but just FYI, history reached mainstream media http://www.cnn.com/2010/TECH/social.media/09/21/twitter.security.flaw/index.html?on.cnn=1 According to the birdy folks the exploit is being patched right now. J From mhuff at ox.com Tue Sep 21 14:12:22 2010 From: mhuff at ox.com (Matthew Huff) Date: Tue, 21 Sep 2010 10:12:22 -0400 Subject: IPv6 tunnel brokers that provide BGP other than HE? Message-ID: <483E6B0272B0284BA86D7596C40D29F9E2C7B8064D@PUR-EXCH07.ox.com> Neither of our upstream providers offer direct ipv6 although both claim deployment in Q1 2011. In the meantime, we have a tunnel with BGP to HE announcing our /48, but we are looking for redundancy. Is there anyone else out there offering services like Hurricane Electric? ---- 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 jbates at brightok.net Tue Sep 21 14:16:44 2010 From: jbates at brightok.net (Jack Bates) Date: Tue, 21 Sep 2010 09:16:44 -0500 Subject: IPv6 tunnel brokers that provide BGP other than HE? In-Reply-To: <483E6B0272B0284BA86D7596C40D29F9E2C7B8064D@PUR-EXCH07.ox.com> References: <483E6B0272B0284BA86D7596C40D29F9E2C7B8064D@PUR-EXCH07.ox.com> Message-ID: <4C98BE4C.6020908@brightok.net> On 9/21/2010 9:12 AM, Matthew Huff wrote: > Neither of our upstream providers offer direct ipv6 although both claim deployment in Q1 2011. In the meantime, we have a tunnel with BGP to HE announcing our /48, but we are looking for redundancy. Is there anyone else out there offering services like Hurricane Electric? Many are, though generally you'll pay a fee for the tunnel, and some have bandwidth limitations for the tunnel. In particular, talk with NTTA, L3, or glbx who all have dual stack and tunnel capabilities. Jack From brandon at burn.net Tue Sep 21 14:19:50 2010 From: brandon at burn.net (Brandon Applegate) Date: Tue, 21 Sep 2010 10:19:50 -0400 (EDT) Subject: Cisco 6509/6513 cable management... In-Reply-To: References: Message-ID: On Tue, 21 Sep 2010, Positively Optimistic wrote: > Do any of our fellow nanog members have experience with cable management on > 6509/6513 cisco switches? We're upgrading infrastructure in some of our > facilities,.. and until it came to cable management, the switches seemed to > be a great idea... 8 48port blades.. pose a challenge.. or a problem.. > > Pictures are welcomed... off-list contact would be great. > > Thanks > http://www.cecommunication.com/pages/cablemgmtproducts.html I have no affiliation with them nor do I even have any - but they do look nice. They claim to not block blade swaps or fan tray removal. If you notice about half the pics/links posted - folks have ALL cabling leaving the 6500 to one side. If you don't do this, you must disconnect cables to get the fan tray out. The folks fanning to both sides are either ignorant or overly optimistic (no pun intended WRT your email address) :) -- Brandon Applegate - CCIE 10273 PGP Key fingerprint: 7407 DC86 AA7B A57F 62D1 A715 3C63 66A1 181E 6996 "SH1-0151. This is the serial number, of our orbital gun." From obriapqz at bc.edu Tue Sep 21 14:34:01 2010 From: obriapqz at bc.edu (Christopher O'Brien) Date: Tue, 21 Sep 2010 10:34:01 -0400 Subject: async serial fiber transceivers Message-ID: <4C98C259.7020309@bc.edu> Greetings, I am planning on deploying a console access server on my network for 20-30 network devices including routers, wireless controllers and other devices. The design is to have one central device for all console access. Due to the geographic diversity of my campus, I will need need to carry the async serial connections over my fiber plant with long reach optics and single mode fiber. I have the fiber plant to support this design. I have been researching solutions to implement the serial part, but I am not very familiar with the vendors I am coming up with. For instance, I know Black Box Networks makes products like this but they only seem to have stand alone devices. I was hoping for something rack mountable since I will have a dense deployment of these devices. Does anyone have experience deploying a solution like this or with async serial fiber transceivers in general? I welcome any suggestions. -Chris From sethm at rollernet.us Tue Sep 21 14:47:07 2010 From: sethm at rollernet.us (Seth Mattinen) Date: Tue, 21 Sep 2010 07:47:07 -0700 Subject: Cisco 6509/6513 cable management... In-Reply-To: References: Message-ID: <4C98C56B.3080401@rollernet.us> On 9/21/10 5:38 AM, William Herrin wrote: > > And, of course, the easy way: > > http://bill.herrin.us/pictures/2008/cables-sm.jpg > A similar way would be MRJ21 cables and patch panels or fan out ends, but Cisco doesn't make any line cards with it. http://www.flickr.com/photos/vax-o-matic/2465615611/in/photostream/ ~Seth From owen at delong.com Tue Sep 21 15:04:03 2010 From: owen at delong.com (Owen DeLong) Date: Tue, 21 Sep 2010 08:04:03 -0700 Subject: IPv6 tunnel brokers that provide BGP other than HE? In-Reply-To: <483E6B0272B0284BA86D7596C40D29F9E2C7B8064D@PUR-EXCH07.ox.com> References: <483E6B0272B0284BA86D7596C40D29F9E2C7B8064D@PUR-EXCH07.ox.com> Message-ID: Not a complete solution, but, you could always do a second HE tunnel to a different site for at least some level of redundancy. Owen On Sep 21, 2010, at 7:12 AM, Matthew Huff wrote: > Neither of our upstream providers offer direct ipv6 although both claim deployment in Q1 2011. In the meantime, we have a tunnel with BGP to HE announcing our /48, but we are looking for redundancy. Is there anyone else out there offering services like Hurricane Electric? > > > > ---- > 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 topperm9 at gmail.com Tue Sep 21 15:23:12 2010 From: topperm9 at gmail.com (Matthew Topper) Date: Tue, 21 Sep 2010 11:23:12 -0400 Subject: Cisco 6509/6513 cable management... In-Reply-To: <4C98703D.7010809@foobar.org> References: <4C98703D.7010809@foobar.org> Message-ID: Maybe I'm thinking about this the wrong way, but it seems to be that that would be a huge problem when you need to change out a cable or move something. Do the benefits outweigh the headaches with this kind of setup? On Tue, Sep 21, 2010 at 4:43 AM, Nick Hilliard wrote: > On 21/09/2010 06:07, Positively Optimistic wrote: >> >> Do any of our fellow nanog members have experience with cable management >> on >> 6509/6513 cisco switches? ? We're upgrading infrastructure in some of our >> facilities,.. ?and until it came to cable management, the switches seemed >> to >> be a great idea... ? 8 48port blades.. ?pose a challenge.. or a problem.. > > courtesy of Richard Steenbergen: > > http://cluepon.net/ras/betterfiber.jpg > > Nick > > > From cra at WPI.EDU Tue Sep 21 15:25:03 2010 From: cra at WPI.EDU (Chuck Anderson) Date: Tue, 21 Sep 2010 11:25:03 -0400 Subject: Cisco 6509/6513 cable management... In-Reply-To: References: Message-ID: <20100921152503.GR23425@angus.ind.WPI.EDU> On Tue, Sep 21, 2010 at 10:19:50AM -0400, Brandon Applegate wrote: > On Tue, 21 Sep 2010, Positively Optimistic wrote: > http://www.cecommunication.com/pages/cablemgmtproducts.html > > I have no affiliation with them nor do I even have any - but they do look > nice. They claim to not block blade swaps or fan tray removal. > > If you notice about half the pics/links posted - folks have ALL cabling > leaving the 6500 to one side. If you don't do this, you must disconnect > cables to get the fan tray out. The folks fanning to both sides are > either ignorant or overly optimistic (no pun intended WRT your email > address) :) Also in line with this, make sure the cables are bundled per-card, leaving a service loop big enough to be able to pull the line card out all the way without disconnecting the cables. This allows you to swap a line card and then move the cables one-by-one to the new card without losing track of where each cable connects. From leslie at craigslist.org Tue Sep 21 15:29:17 2010 From: leslie at craigslist.org (Leslie) Date: Tue, 21 Sep 2010 08:29:17 -0700 Subject: US hunters shoot down Google fibre In-Reply-To: References: <20100921100452.GQ14773@leitl.org> Message-ID: <4C98CF4D.9030801@craigslist.org> Hunters, backhoes, and ship anchors are all fiber's natural enemies - I'm surprised Discovery Channel hasn't done a special on it! On 9/21/10 6:19 AM, Christopher Morrow wrote: > this was presented at the nanog in ... SF I think as well: > > > not really news... > > On Tue, Sep 21, 2010 at 6:04 AM, Eugen Leitl wrote: >> >> http://www.itnews.com.au/News/232831,us-hunters-shoot-down-google-fibre.aspx >> >> Repairers forced to ski in to Oregon back woods. >> >> Google has revealed that aerial fibre links to its data centre in Oregon were >> "regularly" shot down by hunters, forcing the company to put its cables >> underground. >> >> The search and advertising giant's network engineering manager Vijay Gill >> told the AusNOG conference in Sydney last week that people were trying to hit >> insulators on electricity distribution poles. >> >> The poles also hosted aerially-deployed fibre connected to Google's $US600 >> million ($A635 million) data centre in the Dalles, a small city on the >> Columbia River in the US state of Oregon. >> >> "What people do for sport or because they're bored, they try to shoot at the >> insulators," Gill said. >> >> "I have yet to see them actually hit the insulator, but they regularly shoot >> down the fibre. >> >> "Every November when hunting season starts invariably we know that the fibre >> will be shot down, so much so that we are now building an underground path >> [for it]." >> >> Gill said that on one occasion, a snowstorm and avalanche prevented Google >> from transporting repairers and gear into the area of the cut. >> >> It usually used a helicopter or a Caterpillar D9 tractor for transport. It >> improvised by sending three technicians on skis to "repair the fibre that got >> shot down". >> >> "These guys had to cross country ski for three days," Gill said. >> >> "[One guy] is carrying what is known as a fusion splicing kit on his >> backpack." >> >> He joked: "These guys had to go in and fix the fibre while facing gunshots >> >> "So [the] internet... [it's] more dangerous than you realise." >> >> From reese at inkworkswell.com Tue Sep 21 15:30:12 2010 From: reese at inkworkswell.com (Reese) Date: Tue, 21 Sep 2010 11:30:12 -0400 Subject: US hunters shoot down Google fibre In-Reply-To: References: <20100921100452.GQ14773@leitl.org> Message-ID: At 09:19 21 09 10, Christopher Morrow wrote: >this was presented at the nanog in ... SF I think as well: > > >not really news... > >On Tue, Sep 21, 2010 at 6:04 AM, Eugen Leitl wrote: > > > > > I don't want to start an off-topic subthread but I have to call bullshit on this so-called "news" story. So it is my intent that this be my first, last, and only post on this topic. Was it addressed at NANOG (in SF?) that many rifles and amateur shooters both, are capable of sub-MOA accuracy at short distances? By short, I mean ~50 yards or less. Or that a hunter with even modest self-training, who was aiming at an insulator with a properly sighted-in rifle at short range, has a significantly greater probability of hitting the insulator being aimed at than of hitting the supported wire? That wasn't addressed in the buttwipe propaganda from down under. Need I remind anyone of the Dunblane and Port Arthur incidents and the subsequent gun control crackdowns in each of those countries. I wouldn't expect any crown- influenced news agency to give issues involving our Second Amendment a fair shake. Just like I don't expect logic or sanity from the Brady Campaign on the 2A issue. Nor should anyone else. The story smacks of deliberately painting hunters as irresponsible ruffians and worse. What sort of repair rates do the power or other companies running wire across that expanse contend with? Given the remoteness, the identity of the affected client (Google) and the apparent absence of additional information, corporate sabotage seems just-as or even-more probable than random irresponsible hunters. To be fair, some shooters are irresponsible, but deliberate sabotage cannot be ruled out with only the information currently available. Reese From jack at crepinc.com Tue Sep 21 15:31:16 2010 From: jack at crepinc.com (Jack Carrozzo) Date: Tue, 21 Sep 2010 11:31:16 -0400 Subject: IPv6 tunnel brokers that provide BGP other than HE? In-Reply-To: References: <483E6B0272B0284BA86D7596C40D29F9E2C7B8064D@PUR-EXCH07.ox.com> Message-ID: OCCAID has been doing this for a while but I don't see anything on their site about it. Might try contacting them. -Jack Carrozzo On Tue, Sep 21, 2010 at 11:04 AM, Owen DeLong wrote: > Not a complete solution, but, you could always do a second HE tunnel to a > different site for at least > some level of redundancy. > > Owen > > On Sep 21, 2010, at 7:12 AM, Matthew Huff wrote: > > > Neither of our upstream providers offer direct ipv6 although both claim > deployment in Q1 2011. In the meantime, we have a tunnel with BGP to HE > announcing our /48, but we are looking for redundancy. Is there anyone else > out there offering services like Hurricane Electric? > > > > > > > > ---- > > 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 tsnyder at rim.com Tue Sep 21 15:33:34 2010 From: tsnyder at rim.com (Todd Snyder) Date: Tue, 21 Sep 2010 11:33:34 -0400 Subject: US hunters shoot down Google fibre In-Reply-To: <4C98CF4D.9030801@craigslist.org> References: <20100921100452.GQ14773@leitl.org> <4C98CF4D.9030801@craigslist.org> Message-ID: <886120ECC98DE0499B7CBAAE3ED5422B10D35A95@XCH110CNC.rim.net> "Fiber Week"? -----Original Message----- From: Leslie [mailto:leslie at craigslist.org] Sent: Tuesday, September 21, 2010 11:29 AM To: Christopher Morrow Cc: nanog at nanog.org Subject: Re: US hunters shoot down Google fibre Hunters, backhoes, and ship anchors are all fiber's natural enemies - I'm surprised Discovery Channel hasn't done a special on it! On 9/21/10 6:19 AM, Christopher Morrow wrote: > this was presented at the nanog in ... SF I think as well: > > > not really news... > > On Tue, Sep 21, 2010 at 6:04 AM, Eugen Leitl wrote: >> >> http://www.itnews.com.au/News/232831,us-hunters-shoot-down-google-fibre.aspx >> >> Repairers forced to ski in to Oregon back woods. >> >> Google has revealed that aerial fibre links to its data centre in Oregon were >> "regularly" shot down by hunters, forcing the company to put its cables >> underground. >> >> The search and advertising giant's network engineering manager Vijay Gill >> told the AusNOG conference in Sydney last week that people were trying to hit >> insulators on electricity distribution poles. >> >> The poles also hosted aerially-deployed fibre connected to Google's $US600 >> million ($A635 million) data centre in the Dalles, a small city on the >> Columbia River in the US state of Oregon. >> >> "What people do for sport or because they're bored, they try to shoot at the >> insulators," Gill said. >> >> "I have yet to see them actually hit the insulator, but they regularly shoot >> down the fibre. >> >> "Every November when hunting season starts invariably we know that the fibre >> will be shot down, so much so that we are now building an underground path >> [for it]." >> >> Gill said that on one occasion, a snowstorm and avalanche prevented Google >> from transporting repairers and gear into the area of the cut. >> >> It usually used a helicopter or a Caterpillar D9 tractor for transport. It >> improvised by sending three technicians on skis to "repair the fibre that got >> shot down". >> >> "These guys had to cross country ski for three days," Gill said. >> >> "[One guy] is carrying what is known as a fusion splicing kit on his >> backpack." >> >> He joked: "These guys had to go in and fix the fibre while facing gunshots >> >> "So [the] internet... [it's] more dangerous than you realise." >> >> --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. From sethm at rollernet.us Tue Sep 21 15:41:49 2010 From: sethm at rollernet.us (Seth Mattinen) Date: Tue, 21 Sep 2010 08:41:49 -0700 Subject: Cisco 6509/6513 cable management... In-Reply-To: References: <4C98703D.7010809@foobar.org> Message-ID: <4C98D23D.7030700@rollernet.us> On 9/21/10 8:23 AM, Matthew Topper wrote: > Maybe I'm thinking about this the wrong way, but it seems to be that > that would be a huge problem when you need to change out a cable or > move something. Do the benefits outweigh the headaches with this kind > of setup? > I can't speak for others, but I find it's rarely necessary to move a physical cable. If I need to "move" something I do it virtually in the config. ~Seth From streiner at cluebyfour.org Tue Sep 21 15:54:39 2010 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Tue, 21 Sep 2010 11:54:39 -0400 (EDT) Subject: Cisco 6509/6513 cable management... In-Reply-To: References: <4C98703D.7010809@foobar.org> Message-ID: On Tue, 21 Sep 2010, Matthew Topper wrote: > Maybe I'm thinking about this the wrong way, but it seems to be that > that would be a huge problem when you need to change out a cable or > move something. Do the benefits outweigh the headaches with this kind > of setup? Keeping the 'unseen' copper/fiber bundles neatly organized can actually make those moves easier. If you have to replace a jumper, sure it means taking some extra time to undo and re-do the velcro tape loops as you go, but if done properly, it shouldn't add much extra time. The argument could also be made that a properly run and dressed cabling job would need to be touched less frequently, and by extension, is less prone to physical failures that would require changing out a cable. jms > On Tue, Sep 21, 2010 at 4:43 AM, Nick Hilliard wrote: >> On 21/09/2010 06:07, Positively Optimistic wrote: >>> >>> Do any of our fellow nanog members have experience with cable management >>> on >>> 6509/6513 cisco switches? ? We're upgrading infrastructure in some of our >>> facilities,.. ?and until it came to cable management, the switches seemed >>> to >>> be a great idea... ? 8 48port blades.. ?pose a challenge.. or a problem.. >> >> courtesy of Richard Steenbergen: >> >> http://cluepon.net/ras/betterfiber.jpg >> >> Nick >> >> >> > > From dylan.ebner at crlmed.com Tue Sep 21 16:01:34 2010 From: dylan.ebner at crlmed.com (Dylan Ebner) Date: Tue, 21 Sep 2010 16:01:34 +0000 Subject: Cisco 6509/6513 cable management... In-Reply-To: References: Message-ID: <017265BF3B9640499754DD48777C3D20691E57F2FD@MBX9.EXCHPROD.USA.NET> Justin really hit in on the head with points 4 and 5. You can have the the most organized cabling in the work and lack of labeling and documentation can kill you in a second. A long time ago I was introduced to the rule of 8s. 80% of network outages are caused by cable failure, 80% of the time to repair is finding the cable, and for a mid to large organization, it costs 80K per hour of downtime. We took this to heart and borrowed an idea from Sun. Every cable in our DC has two labels per end. One label for the near end and one for the far. This way you always know where you came from and where you are going. It takes a lot of time to setup, but it is worth every penny, Dylan Ebner, Network Engineer Consulting Radiologists, Ltd. -----Original Message----- From: Justin M. Streiner [mailto:streiner at cluebyfour.org] Sent: Tuesday, September 21, 2010 8:39 AM To: nanog at nanog.org Subject: Re: Cisco 6509/6513 cable management... On Tue, 21 Sep 2010, Positively Optimistic wrote: > Do any of our fellow nanog members have experience with cable management on > 6509/6513 cisco switches? We're upgrading infrastructure in some of our > facilities,.. and until it came to cable management, the switches seemed to > be a great idea... 8 48port blades.. pose a challenge.. or a problem.. The biggest things with 6500s, or any high-density configuration for that matter, are: 1. Using racks/cabinets that have ample space for your vertical and horizontal cabling. If you don't have this, things can get ugly in a hurry. Make sure the kit you choose has plenty of wire management channel space left over even after the racks are fully populated. Having to tear overstuffed wire management channels apart to back-pull a bad cable or jumper at 3 AM is no fun. 2. Emphasizing the importance of following established cabling standards to the people who will be touching this equipment. Having visual aids, i.e. "Here are some pictures of the quality of work we expect", usually go a lot farther to drive this point home than handing someone a 20-page cabling standards document with no pictures. 3. Dont forget about your inter-rack/overhead wiring channels/trays. I've seen a few places that had things neatly dressed in the racks, but the overhead channels were a complete mess... assumingly because they were hidden from view :). If your overhead distribution has separate channels/lanes for power/copper/fiber, even better. 4. Labeling and documentation. 5. See 4. jms From leslie at craigslist.org Tue Sep 21 15:39:36 2010 From: leslie at craigslist.org (Leslie) Date: Tue, 21 Sep 2010 08:39:36 -0700 Subject: US hunters shoot down Google fibre In-Reply-To: References: <20100921100452.GQ14773@leitl.org> Message-ID: <4C98D1B8.2070503@craigslist.org> > > I don't want to start an off-topic subthread but I have to call > bullshit on this so-called "news" story. So it is my intent that > this be my first, last, and only post on this topic. > > Was it addressed at NANOG (in SF?) that many rifles and amateur > shooters both, are capable of sub-MOA accuracy at short distances? > By short, I mean ~50 yards or less. > > Or that a hunter with even modest self-training, who was aiming at > an insulator with a properly sighted-in rifle at short range, has > a significantly greater probability of hitting the insulator being > aimed at than of hitting the supported wire? That wasn't addressed > in the buttwipe propaganda from down under. Need I remind anyone of > the Dunblane and Port Arthur incidents and the subsequent gun control > crackdowns in each of those countries. I wouldn't expect any crown- > influenced news agency to give issues involving our Second Amendment > a fair shake. Just like I don't expect logic or sanity from the Brady > Campaign on the 2A issue. Nor should anyone else. The story smacks of > deliberately painting hunters as irresponsible ruffians and worse. > > What sort of repair rates do the power or other companies running > wire across that expanse contend with? Given the remoteness, the > identity of the affected client (Google) and the apparent absence of > additional information, corporate sabotage seems just-as or even-more > probable than random irresponsible hunters. To be fair, some shooters > are irresponsible, but deliberate sabotage cannot be ruled out with > only the information currently available. In my experience, there's really two types of shootings (which really depend on the region) -- Number one is using shotguns, not rifles, and bird hunting - for example when goose hunting season happens, you'll see fiber shot out over lakes/rivers more often - I think this is both bad aim and not really caring. (Occasionally the shot will even be stuck in the lines or insulation so you can tell it was a shotgun) The second is drunk idiots shooting at the lines - this is more universal and happens closer to civilization. Power companies will also have repair issues with either of these, but fiber, phone, and cable lines are more likely as they are lower to the ground due to regulations that state they have to be at least X feet away from the power lines. I don't think anyone is claiming all hunters/gun owners are irresponsible, but, as with any segment of the population, when you have a large group there will be a percentage of complete idiots out there who take stupid actions. As for the 2nd amendment stuff - I'm not touching that one with a 10 foot fiber ;) Leslie From dot at dotat.at Tue Sep 21 16:29:29 2010 From: dot at dotat.at (Tony Finch) Date: Tue, 21 Sep 2010 17:29:29 +0100 Subject: US hunters shoot down Google fibre In-Reply-To: References: <20100921100452.GQ14773@leitl.org> Message-ID: On Tue, 21 Sep 2010, Reese wrote: > > I don't want to start an off-topic subthread but I have to call > bullshit on this so-called "news" story. Several years ago I heard of a Swiss ISP having the same problem. They built their network by running fibre along the earth conductor of high voltage transmission lines (like Energis in the UK). I was told that it was common for hunters to verify the setting of their sights by shooting at the lines. Tony. -- f.anthony.n.finch http://dotat.at/ HUMBER THAMES DOVER WIGHT PORTLAND: NORTH BACKING WEST OR NORTHWEST, 5 TO 7, DECREASING 4 OR 5, OCCASIONALLY 6 LATER IN HUMBER AND THAMES. MODERATE OR ROUGH. RAIN THEN FAIR. GOOD. From gbonser at seven.com Tue Sep 21 16:31:07 2010 From: gbonser at seven.com (George Bonser) Date: Tue, 21 Sep 2010 09:31:07 -0700 Subject: Did Internet Founders Actually Anticipate Paid, In-Reply-To: <20100921051418.GW3803@hezmatt.org> References: <47C24175-66AA-47D9-B8AA-2EF21300F911@delong.com><5A6D953473350C4B9995546AFE9939EE0A52AE25@RWC-EX1.corp.seven.com> <20100921051418.GW3803@hezmatt.org> Message-ID: <5A6D953473350C4B9995546AFE9939EE0A52AE39@RWC-EX1.corp.seven.com> > Yes they are -- content providers aren't getting their connections to > the > Internet for free (and if they are, how can I get me some of that?). Maybe I wasn't clear. Traffic is moving away from "transit" to direct peering at private exchanges in many cases. Since most exchanges are "flat rate" and aren't all that expensive, it is "practically" free. For example, if I have a 10G connection to an exchange (say Equinix IX, or DEIX in Germany, or LINX in the UK, or PARIX in France, or INIX in Ireland among other) it doesn't cost me any more to send 1G than it does to send 5G of traffic. So if something happens that increases the bandwidth utilization, my monthly cost does not change until I have to change to higher capacity media and that is a step change. > > If the ISPs are directly peering with the content provider at > > some IX, the content provider gets what amounts to a free ride to the > > end user. > > Say wha? ISPs don't *have* to peer at an IX; if they think that it's > cheaper to buy transit from someone than it is to peer, they're more > than > capable of doing so. Transit would have to get extremely cheap to compete with exchange peering. I don't see it getting that low any time soon. > > The customer's requesting this traffic, therefore the customer needs a > bigger pipe, therefore the customer pays more. The problem is that maybe the customer is doing nothing different than they have always done. They didn't request more bandwidth. The product they have always used now consumes more bandwidth through no fault of their own. It would be as if you regularly ordered some product every month and the product keeps getting heavier and heavier and the shipping costs go up until the weight is higher than the carrier will ship. You are ordering the same thing you always did, you didn't ask for it to be heavier, the producer decided to make it heavier. But that is not a perfect analogy because a consumer pays a flat monthly "shipping fee" for Internet traffic. The problem comes in when the content providers make it "heavier" or higher bandwidth utilization beyond the control of the customer. Now the customer's pipe is saturated and they aren't doing anything different than what they did before. Or maybe some new product is released that is an out and out bandwidth hog. MOST people using consumer Internet have no idea of things like that nor should they need to. All they know is that now their Internet performs like crap and their ISP wants more money to make it work better. They might feel they have been ripped off. As time goes by, their Internet performs worse and worse, they begin to blame their network provider for that, not the content provider who produces a product that consumes increasing amounts of bandwidth as time goes by. Consider, for example, the number of sites that have streaming media of some sort that begins to play as soon as you land on the page. > - Matt From dmm at 1-4-5.net Mon Sep 20 23:38:05 2010 From: dmm at 1-4-5.net (David Meyer) Date: Mon, 20 Sep 2010 16:38:05 -0700 Subject: [NANOG-announce] Final agenda posted for NANOG 50 Message-ID: Folks, The agenda for NANOG 50 has been updated. The agenda looks very good and we are looking forward to seeing you all in Atlanta. Please note that tomorrow (09/21) is the last day before late registration kicks in. So please register tomorrow if you haven't already. Looking forward to Atlanta, Dave (for the NANOG PC) -------------- next part -------------- _______________________________________________ NANOG-announce mailing list NANOG-announce at nanog.org https://mailman.nanog.org/mailman/listinfo/nanog-announce From tthornt at centurylink.net Tue Sep 21 17:11:57 2010 From: tthornt at centurylink.net (Tony Thornton) Date: Tue, 21 Sep 2010 12:11:57 -0500 Subject: Cisco 6509/6513 cable management... In-Reply-To: Message-ID: <03F92E914A3142F7B2DE1B077D37834E@office> http://hardforum.com/showthread.php?t=1040489 -----Original Message----- From: Positively Optimistic [mailto:positivelyoptimistic at gmail.com] Sent: Tuesday, September 21, 2010 12:07 AM To: nanog at nanog.org Subject: Cisco 6509/6513 cable management... Do any of our fellow nanog members have experience with cable management on 6509/6513 cisco switches? We're upgrading infrastructure in some of our facilities,.. and until it came to cable management, the switches seemed to be a great idea... 8 48port blades.. pose a challenge.. or a problem.. Pictures are welcomed... off-list contact would be great. Thanks From gbonser at seven.com Tue Sep 21 17:16:25 2010 From: gbonser at seven.com (George Bonser) Date: Tue, 21 Sep 2010 10:16:25 -0700 Subject: Did Internet Founders Actually Anticipate Paid, In-Reply-To: References: <201009181838.o8IIc1NM080494@aurora.sol.net> <47C24175-66AA-47D9-B8AA-2EF21300F911@delong.com> <5A6D953473350C4B9995546AFE9939EE0A52AE25@RWC-EX1.corp.seven.com> Message-ID: <5A6D953473350C4B9995546AFE9939EE0A52AE3D@RWC-EX1.corp.seven.com> > > My friend, that is a straw man. ISPs have complete control over who > they peer with, the size of the peering pipe they accept and whether > that peering session is free or paid. If peering with Netflix will > cost you more than you gain, you just don't do it. > > > Regards, > Bill Herrin To some extent, yes, it is. There is a certain amount of "devil's advocate" being played on my part to help flesh out the nature of the problem and other ideas from other folks and their insight. Sometimes you just have to run something up the pole and see who shoots at it and what they shoot. I suppose what I am saying is that in general, selling express treatment in the core is probably a bad idea as it gives the bean counters an incentive not to approve capacity increases in order to increase revenue from selling "premium" access. In some cases, prioritizing on the customer edge might be a good idea so your 16yo downloading movies or sharing his porn collection doesn't keep your VIOP phone from working. There is room for innovation to decrease bandwidth utilization at least in the core and at the Internet edge of the provider's network. Multicast, for example, has never really reached its potential for streaming live events such as sporting, news, or live entertainment events. Sometimes the investment in innovation must be caused by feeling some pain if things are left as they are. Currently the ones feeling the pain are not the ones who would have to undertake that investment; there is nothing the ISP or consumer can do to improve the content provider's application. The point I was trying to make is maybe if those content providers did experience some or more financial consequence of increased bandwidth consumption, they would be more sensitive to it and we would all benefit as a result. G From trelane at trelane.net Tue Sep 21 17:30:38 2010 From: trelane at trelane.net (Andrew Kirch) Date: Tue, 21 Sep 2010 13:30:38 -0400 Subject: US hunters shoot down Google fibre In-Reply-To: References: <20100921100452.GQ14773@leitl.org> Message-ID: <4C98EBBE.3010609@trelane.net> On 9/21/2010 12:29 PM, Tony Finch wrote: > On Tue, 21 Sep 2010, Reese wrote: > Several years ago I heard of a Swiss ISP having the same problem. They > built their network by running fibre along the earth conductor of high > voltage transmission lines (like Energis in the UK). I was told that it > was common for hunters to verify the setting of their sights by shooting > at the lines. > > Tony. I shoot competition rifle, and rifles just aren't that accurate. You certainly CAN shoot out a fiber or utility line on the pole, from point blank, but it's not actually useful in diagnosing or correcting problems with the rifle. A good rifle will shoot 1" groups (`MOA) at 100 yards, and most lines on the pole are smaller, fiber being much smaller. There are rifles that exceed 1MOA, but most hunters quite frankly can't afford them, nor are they necessary for hunting. Andrew From dholmes at mwdh2o.com Tue Sep 21 17:52:42 2010 From: dholmes at mwdh2o.com (Holmes,David A) Date: Tue, 21 Sep 2010 10:52:42 -0700 Subject: US hunters shoot down Google fibre In-Reply-To: <20100921100452.GQ14773@leitl.org> References: <20100921100452.GQ14773@leitl.org> Message-ID: <485ED9BA02629E4BBBA53AC892EDA50E0BBCAB69@usmsxt104.mwd.h2o> Modern telephone pole aerial fiber uses all dialectric self-supporting (ADSS) technology, where the self-supporting component consists primarily of aramid yarn, the same material used for bullet-proof vests. This makes for an extremely light weight, almost indestructible fiber bundle. My guess is that ADSS fiber would deflect any bullets, or it would take a very good marksman using a very high caliber weapon to actually sever an aerial fiber. Now in the case described below where optical ground wire (OPGW) fiber is used as a component in the ground wire running at the top of high voltage transmission towers, it may be possible to hit the insulators at the top of the towers, but the ground wire itself is usually armored, with ADSS inside. Seems far-fetched to me. -----Original Message----- From: Eugen Leitl [mailto:eugen at leitl.org] Sent: Tuesday, September 21, 2010 3:05 AM To: nanog at nanog.org Subject: US hunters shoot down Google fibre http://www.itnews.com.au/News/232831,us-hunters-shoot-down-google-fibre. aspx Repairers forced to ski in to Oregon back woods. Google has revealed that aerial fibre links to its data centre in Oregon were "regularly" shot down by hunters, forcing the company to put its cables underground. The search and advertising giant's network engineering manager Vijay Gill told the AusNOG conference in Sydney last week that people were trying to hit insulators on electricity distribution poles. The poles also hosted aerially-deployed fibre connected to Google's $US600 million ($A635 million) data centre in the Dalles, a small city on the Columbia River in the US state of Oregon. "What people do for sport or because they're bored, they try to shoot at the insulators," Gill said. "I have yet to see them actually hit the insulator, but they regularly shoot down the fibre. "Every November when hunting season starts invariably we know that the fibre will be shot down, so much so that we are now building an underground path [for it]." Gill said that on one occasion, a snowstorm and avalanche prevented Google from transporting repairers and gear into the area of the cut. It usually used a helicopter or a Caterpillar D9 tractor for transport. It improvised by sending three technicians on skis to "repair the fibre that got shot down". "These guys had to cross country ski for three days," Gill said. "[One guy] is carrying what is known as a fusion splicing kit on his backpack." He joked: "These guys had to go in and fix the fibre while facing gunshots "So [the] internet... [it's] more dangerous than you realise." From sethm at rollernet.us Tue Sep 21 18:02:52 2010 From: sethm at rollernet.us (Seth Mattinen) Date: Tue, 21 Sep 2010 11:02:52 -0700 Subject: US hunters shoot down Google fibre In-Reply-To: <485ED9BA02629E4BBBA53AC892EDA50E0BBCAB69@usmsxt104.mwd.h2o> References: <20100921100452.GQ14773@leitl.org> <485ED9BA02629E4BBBA53AC892EDA50E0BBCAB69@usmsxt104.mwd.h2o> Message-ID: <4C98F34C.5000706@rollernet.us> On 9/21/2010 10:52, Holmes,David A wrote: > Modern telephone pole aerial fiber uses all dialectric self-supporting > (ADSS) technology, where the self-supporting component consists > primarily of aramid yarn, the same material used for bullet-proof vests. > This makes for an extremely light weight, almost indestructible fiber > bundle. My guess is that ADSS fiber would deflect any bullets, or it > would take a very good marksman using a very high caliber weapon to > actually sever an aerial fiber. > > Now in the case described below where optical ground wire (OPGW) fiber > is used as a component in the ground wire running at the top of high > voltage transmission towers, it may be possible to hit the insulators at > the top of the towers, but the ground wire itself is usually armored, > with ADSS inside. Seems far-fetched to me. > Back in my ISP days it was more common for people to take pot shots at remote equipment cabinets than the cable/fiber itself. Any field enclosure is as easy a target as your average bullet-ridden road sign. Although this was extremely rare; I can only recall one instance where it was the direct cause of an outage. ~Seth From kevin at safelink.net Tue Sep 21 18:10:38 2010 From: kevin at safelink.net (Kevin Neal) Date: Tue, 21 Sep 2010 12:10:38 -0600 Subject: US hunters shoot down Google fibre In-Reply-To: <4C98F34C.5000706@rollernet.us> References: <20100921100452.GQ14773@leitl.org> <485ED9BA02629E4BBBA53AC892EDA50E0BBCAB69@usmsxt104.mwd.h2o> <4C98F34C.5000706@rollernet.us> Message-ID: How are the guys sent out on cross-country skis going to get up to the fiber to repair it? I'm sure that the cable isn't low enough for them to reach it without a ladder, bucket truck, helicopter.... all of which you don't pack in on skis... -Kevin On Tue, Sep 21, 2010 at 12:02 PM, Seth Mattinen wrote: > On 9/21/2010 10:52, Holmes,David A wrote: > > Modern telephone pole aerial fiber uses all dialectric self-supporting > > (ADSS) technology, where the self-supporting component consists > > primarily of aramid yarn, the same material used for bullet-proof vests. > > This makes for an extremely light weight, almost indestructible fiber > > bundle. My guess is that ADSS fiber would deflect any bullets, or it > > would take a very good marksman using a very high caliber weapon to > > actually sever an aerial fiber. > > > > Now in the case described below where optical ground wire (OPGW) fiber > > is used as a component in the ground wire running at the top of high > > voltage transmission towers, it may be possible to hit the insulators at > > the top of the towers, but the ground wire itself is usually armored, > > with ADSS inside. Seems far-fetched to me. > > > > > Back in my ISP days it was more common for people to take pot shots at > remote equipment cabinets than the cable/fiber itself. Any field > enclosure is as easy a target as your average bullet-ridden road sign. > Although this was extremely rare; I can only recall one instance where > it was the direct cause of an outage. > > ~Seth > > From mark at viviotech.net Tue Sep 21 18:18:06 2010 From: mark at viviotech.net (Mark Keymer) Date: Tue, 21 Sep 2010 11:18:06 -0700 Subject: US hunters shoot down Google fibre In-Reply-To: References: <20100921100452.GQ14773@leitl.org> <485ED9BA02629E4BBBA53AC892EDA50E0BBCAB69@usmsxt104.mwd.h2o> <4C98F34C.5000706@rollernet.us> Message-ID: <4C98F6DE.9000000@viviotech.net> Hi Kevin, That is easy. "Tree Climbing Spurs / Tree Climbing Spikes" A quick Google search found these for sale. http://wesspur.com/spurs/spurs.html :) Sincerely, Mark Kevin Neal wrote: > How are the guys sent out on cross-country skis going to get up to the fiber > to repair it? I'm sure that the cable isn't low enough for them to reach it > without a ladder, bucket truck, helicopter.... all of which you don't pack > in on skis... > > > -Kevin > > On Tue, Sep 21, 2010 at 12:02 PM, Seth Mattinen wrote: > > >> On 9/21/2010 10:52, Holmes,David A wrote: >> >>> Modern telephone pole aerial fiber uses all dialectric self-supporting >>> (ADSS) technology, where the self-supporting component consists >>> primarily of aramid yarn, the same material used for bullet-proof vests. >>> This makes for an extremely light weight, almost indestructible fiber >>> bundle. My guess is that ADSS fiber would deflect any bullets, or it >>> would take a very good marksman using a very high caliber weapon to >>> actually sever an aerial fiber. >>> >>> Now in the case described below where optical ground wire (OPGW) fiber >>> is used as a component in the ground wire running at the top of high >>> voltage transmission towers, it may be possible to hit the insulators at >>> the top of the towers, but the ground wire itself is usually armored, >>> with ADSS inside. Seems far-fetched to me. >>> >>> >> Back in my ISP days it was more common for people to take pot shots at >> remote equipment cabinets than the cable/fiber itself. Any field >> enclosure is as easy a target as your average bullet-ridden road sign. >> Although this was extremely rare; I can only recall one instance where >> it was the direct cause of an outage. >> >> ~Seth >> >> >> From kevin at safelink.net Tue Sep 21 18:38:29 2010 From: kevin at safelink.net (Kevin Neal) Date: Tue, 21 Sep 2010 12:38:29 -0600 Subject: US hunters shoot down Google fibre In-Reply-To: <4C98F6DE.9000000@viviotech.net> References: <20100921100452.GQ14773@leitl.org> <485ED9BA02629E4BBBA53AC892EDA50E0BBCAB69@usmsxt104.mwd.h2o> <4C98F34C.5000706@rollernet.us> <4C98F6DE.9000000@viviotech.net> Message-ID: I guess it depends on whether these are wooden poles or the metal towers that I find around here for long haul power. -Kevin On Tue, Sep 21, 2010 at 12:18 PM, Mark Keymer wrote: > Hi Kevin, > > That is easy. "Tree Climbing Spurs / Tree Climbing Spikes" A quick > Google search found these for sale. http://wesspur.com/spurs/spurs.html > > :) > > Sincerely, > > Mark > > > Kevin Neal wrote: > > How are the guys sent out on cross-country skis going to get up to the > fiber > > to repair it? I'm sure that the cable isn't low enough for them to reach > it > > without a ladder, bucket truck, helicopter.... all of which you don't > pack > > in on skis... > > > > > > -Kevin > > > > On Tue, Sep 21, 2010 at 12:02 PM, Seth Mattinen > wrote: > > > > > >> On 9/21/2010 10:52, Holmes,David A wrote: > >> > >>> Modern telephone pole aerial fiber uses all dialectric self-supporting > >>> (ADSS) technology, where the self-supporting component consists > >>> primarily of aramid yarn, the same material used for bullet-proof > vests. > >>> This makes for an extremely light weight, almost indestructible fiber > >>> bundle. My guess is that ADSS fiber would deflect any bullets, or it > >>> would take a very good marksman using a very high caliber weapon to > >>> actually sever an aerial fiber. > >>> > >>> Now in the case described below where optical ground wire (OPGW) fiber > >>> is used as a component in the ground wire running at the top of high > >>> voltage transmission towers, it may be possible to hit the insulators > at > >>> the top of the towers, but the ground wire itself is usually armored, > >>> with ADSS inside. Seems far-fetched to me. > >>> > >>> > >> Back in my ISP days it was more common for people to take pot shots at > >> remote equipment cabinets than the cable/fiber itself. Any field > >> enclosure is as easy a target as your average bullet-ridden road sign. > >> Although this was extremely rare; I can only recall one instance where > >> it was the direct cause of an outage. > >> > >> ~Seth > >> > >> > >> > > > From Valdis.Kletnieks at vt.edu Tue Sep 21 18:45:11 2010 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Tue, 21 Sep 2010 14:45:11 -0400 Subject: US hunters shoot down Google fibre In-Reply-To: Your message of "Tue, 21 Sep 2010 12:10:38 MDT." References: <20100921100452.GQ14773@leitl.org> <485ED9BA02629E4BBBA53AC892EDA50E0BBCAB69@usmsxt104.mwd.h2o> <4C98F34C.5000706@rollernet.us> Message-ID: <9000.1285094711@localhost> On Tue, 21 Sep 2010 12:10:38 MDT, Kevin Neal said: > How are the guys sent out on cross-country skis going to get up to the fiber > to repair it? I'm sure that the cable isn't low enough for them to reach it > without a ladder, bucket truck, helicopter.... all of which you don't pack > in on skis... Of course it's easily reachable - it's been shot down and is on the ground. If it was still on the pole you wouldn't be out there on skis with a splice kit. :) What I have to wonder about is how often hunter-inflicted damage is intentional and located at the insulator (which makes for a good story) and how often it's a totally accidental stray bullet nicking the cable many yards from the nearest pole (which makes for a poor story). I'd expect that since the fiber is usually hung much closer to the ground, it would get hit a lot more than the power cables higher up. Also, you're less likely to notice a 1mm divot taken out of a (usually thicker and sturdier and essentially single fat conductor) power cable than a 1mm divot out of a 48 pair. (Consider that even today, it is *still* relatively common to visit some CIvil War battlegrounds and find 2 bullets that hit each other in mid-air. Of course, most of those were probably going down a narrow cone pointed at the source of the other bullet, but still, it indicates that with enough hunters and enough bullets, somebody's going to nick that 300 miles of cable hanging just a few yards above the deer.... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From jgreco at ns.sol.net Tue Sep 21 18:46:28 2010 From: jgreco at ns.sol.net (Joe Greco) Date: Tue, 21 Sep 2010 13:46:28 -0500 (CDT) Subject: Did Internet Founders Actually Anticipate Paid, In-Reply-To: <5A6D953473350C4B9995546AFE9939EE0A52AE39@RWC-EX1.corp.seven.com> Message-ID: <201009211846.o8LIkToW025943@aurora.sol.net> > > Yes they are -- content providers aren't getting their connections to > > the > > Internet for free (and if they are, how can I get me some of that?). > > Maybe I wasn't clear. Traffic is moving away from "transit" to direct > peering at private exchanges in many cases. Since most exchanges are > "flat rate" and aren't all that expensive, it is "practically" free. > For example, if I have a 10G connection to an exchange (say Equinix IX, > or DEIX in Germany, or LINX in the UK, or PARIX in France, or INIX in > Ireland among other) it doesn't cost me any more to send 1G than it does > to send 5G of traffic. So if something happens that increases the > bandwidth utilization, my monthly cost does not change until I have to > change to higher capacity media and that is a step change. =20 That only happens if both parties choose to peer. Even though the cost per incremental *bit* might appear to be zero, there's a large cost in terms of exchange membership, colocating equipment, etc. > > > If the ISPs are directly peering with the content provider at > > > some IX, the content provider gets what amounts to a free ride to > the > > > end user. > >=20 > > Say wha? ISPs don't *have* to peer at an IX; if they think that it's > > cheaper to buy transit from someone than it is to peer, they're more > > than > > capable of doing so. > > Transit would have to get extremely cheap to compete with exchange > peering. I don't see it getting that low any time soon. I thought I heard some folks were bailing on peering because transit was so cheap. Last time I looked, Equinix Exchange wasn't exactly cheap, it was quite a bit cheaper to run private cross-connects. > >=20 > > The customer's requesting this traffic, therefore the customer needs a > > bigger pipe, therefore the customer pays more. > > The problem is that maybe the customer is doing nothing different than > they have always done. They didn't request more bandwidth. The product > they have always used now consumes more bandwidth through no fault of > their own. It would be as if you regularly ordered some product every > month and the product keeps getting heavier and heavier and the shipping > costs go up until the weight is higher than the carrier will ship. You > are ordering the same thing you always did, you didn't ask for it to be > heavier, the producer decided to make it heavier. But that is not a > perfect analogy because a consumer pays a flat monthly "shipping fee" > for Internet traffic. The problem comes in when the content providers > make it "heavier" or higher bandwidth utilization beyond the control of > the customer. Now the customer's pipe is saturated and they aren't > doing anything different than what they did before. Or maybe some new > product is released that is an out and out bandwidth hog. Okay, so it's kind of like the evolution of the modern road. Years ago, we had cars that resembled horse buggies and dirt or gravel roads. As time passes, cars improve and roads improve. Now we have cars that are capable of 200MPH and the pavers on the Autobahn use lasers to make sure the road is sufficiently smooth that drivers don't wreck at those speeds. At the same time, we no longer have manual laborers doing most of the laying of the roads by hand, even the Germans figured out really quickly that machines were better at it. So on one hand, machinery drives the cost of laying road down, and on the other, increased automobile use and more roads drives the cost of maintaining our system of roads up. Mapped back to the world of NANOG, we need to be aware that the computer of today, the storage technology of today, the home entertainment systems of today, etc., are all much faster and more sophisticated than just what we had ten years ago. We've made it very difficult for users to continue to use older computers: the web browsers are hungrier and piggier, and a 233 MHz 32MB Win98 machine that was perfectly suitable in 1998 is only good for being sent to India for recycling today. It seems unlikely to me that we're going to slow the evolution of modern computing and modern media consumption. Perhaps we need to find a better way to connect people. I know that the legacy communications providers are very hesitant to start replacing their "gravel road" coax with faster stuff, but really, that's the point we're at. In the last decade, the thing that's been dragging us down is that last mile pipe. We already know that it is reasonably economical to arrange for faster access. One just has to look around elsewhere to see what's been done. Other countries are providing speeds of up to 100Mbps to residential. We're still hearing our telcos argue for definitions of "broadband" that are less than 1Mbps. Talk about dirt road lovers. > MOST people > using consumer Internet have no idea of things like that nor should they > need to. All they know is that now their Internet performs like crap > and their ISP wants more money to make it work better. They might feel > they have been ripped off. As time goes by, their Internet performs > worse and worse, they begin to blame their network provider for that, > not the content provider who produces a product that consumes increasing > amounts of bandwidth as time goes by. Consider, for example, the number > of sites that have streaming media of some sort that begins to play as > soon as you land on the page. =20 "Kill HTML5! Kill HTML5!" ... Or maybe let's fix those roads. ... 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 davidd at corp.nac.net Tue Sep 21 19:02:35 2010 From: davidd at corp.nac.net (David DiGiacomo) Date: Tue, 21 Sep 2010 15:02:35 -0400 Subject: US hunters shoot down Google fibre In-Reply-To: <4C98F34C.5000706@rollernet.us> References: <20100921100452.GQ14773@leitl.org> <485ED9BA02629E4BBBA53AC892EDA50E0BBCAB69@usmsxt104.mwd.h2o> <4C98F34C.5000706@rollernet.us> Message-ID: Instead of a rifle, how about a shotgun? It fires a nice wide spread shot pattern. I think you would be much more likely to do some damage (ie: knock fiber off a pole) with something like that. Here in New Jersey it is illegal to use a rifle to hunt deer, so typically you will find hunters using a bow/arrow or Shotgun and you will see a lot of road signs (or other abandon junk) that has been victim of a shotgun blast. ~Dave -----Original Message----- From: Seth Mattinen [mailto:sethm at rollernet.us] Sent: Tuesday, September 21, 2010 2:03 PM To: nanog at nanog.org Subject: Re: US hunters shoot down Google fibre On 9/21/2010 10:52, Holmes,David A wrote: > Modern telephone pole aerial fiber uses all dialectric self-supporting > (ADSS) technology, where the self-supporting component consists > primarily of aramid yarn, the same material used for bullet-proof vests. > This makes for an extremely light weight, almost indestructible fiber > bundle. My guess is that ADSS fiber would deflect any bullets, or it > would take a very good marksman using a very high caliber weapon to > actually sever an aerial fiber. > > Now in the case described below where optical ground wire (OPGW) fiber > is used as a component in the ground wire running at the top of high > voltage transmission towers, it may be possible to hit the insulators at > the top of the towers, but the ground wire itself is usually armored, > with ADSS inside. Seems far-fetched to me. > Back in my ISP days it was more common for people to take pot shots at remote equipment cabinets than the cable/fiber itself. Any field enclosure is as easy a target as your average bullet-ridden road sign. Although this was extremely rare; I can only recall one instance where it was the direct cause of an outage. ~Seth From web at typo.org Tue Sep 21 19:11:17 2010 From: web at typo.org (Wayne E. Bouchard) Date: Tue, 21 Sep 2010 12:11:17 -0700 Subject: US hunters shoot down Google fibre In-Reply-To: <9000.1285094711@localhost> References: <20100921100452.GQ14773@leitl.org> <485ED9BA02629E4BBBA53AC892EDA50E0BBCAB69@usmsxt104.mwd.h2o> <4C98F34C.5000706@rollernet.us> <9000.1285094711@localhost> Message-ID: <20100921191117.GA27301@typo.org> On Tue, Sep 21, 2010 at 02:45:11PM -0400, Valdis.Kletnieks at vt.edu wrote: > What I have to wonder about is how often hunter-inflicted damage is intentional > and located at the insulator (which makes for a good story) and how often it's > a totally accidental stray bullet nicking the cable many yards from the nearest > pole (which makes for a poor story). I'd expect that since the fiber is > usually hung much closer to the ground, it would get hit a lot more than the > power cables higher up. Also, you're less likely to notice a 1mm divot taken > out of a (usually thicker and sturdier and essentially single fat conductor) > power cable than a 1mm divot out of a 48 pair. What I want to know is, even if the story is bogus, why is anyone surprised by the prospect? It's been my experience that when Bubba goes out into the woods that anything manmade becomes a target. Microwave reflectors, telephone poles, road signs, water towers, windmills.... you name it and some low-brow will shoot at it. That and leave shell casings and shotgun hulls all over the place when he's done. Gives all us responsible folks a bad name... Now I just have one more good reason to loathe that behavior. (and we're now drifting well off topic so this thread should probably die pretty quickly.) -Wayne --- Wayne Bouchard web at typo.org Network Dude http://www.typo.org/~web/ From reese at inkworkswell.com Tue Sep 21 19:35:55 2010 From: reese at inkworkswell.com (Reese) Date: Tue, 21 Sep 2010 15:35:55 -0400 Subject: US hunters shoot down Google fibre In-Reply-To: <4C98D1B8.2070503@craigslist.org> References: <20100921100452.GQ14773@leitl.org> <4C98D1B8.2070503@craigslist.org> Message-ID: At 11:39 21 09 10, Leslie wrote: >I don't think anyone is claiming all hunters/gun owners are irresponsible, Re-read the article. "[h]unters" it said, not "some hunters" or "irresponsible hunters". How broad must the brush be, before you feel personally impugned and maligned? >but, as with any segment of the population, when you have a large >group there will be a percentage of complete idiots out there who >take stupid actions. I acknowledged that. I regret its truthiness. But with Google and only Google as a named victim of the hardware DoS, I have yet to read anything that convinces me that it was not corporate sabotage. My point was not that wires and insulators do not get shot or shot at, but that "hunters" was a convenient excuse that other things could be too-conveniently classified with. Who, here, hunts? Shoot at wires and insulators on towers, do you? Reese From patrick at zill.net Tue Sep 21 19:53:04 2010 From: patrick at zill.net (Patrick Giagnocavo) Date: Tue, 21 Sep 2010 15:53:04 -0400 Subject: US hunters shoot down Google fibre In-Reply-To: <20100921100452.GQ14773@leitl.org> References: <20100921100452.GQ14773@leitl.org> Message-ID: <4C990D20.8060105@zill.net> On 9/21/2010 6:04 AM, Eugen Leitl wrote: > > http://www.itnews.com.au/News/232831,us-hunters-shoot-down-google-fibre.aspx > 1. Deer tend to hang out in little clearings while eating. Little clearings like the right of way clearing 25 or 50 feet on each side of an electricity pylon. 2. Deer are easier to shoot when their silhouette is seen at or near the top of a ridge, especially if they are in a clearing as well. Combine #1 and #2, it is logical that even without "bubbas" the deer/fiber coincidence level would be high. --Patrick From bdantzig at medline.com Tue Sep 21 19:53:58 2010 From: bdantzig at medline.com (Dantzig, Brian) Date: Tue, 21 Sep 2010 14:53:58 -0500 Subject: Cisco 6509/6513 cable management... Message-ID: <1F26704905C4804AAF98B0AE6BE029510352E095@MUNEXBE1.medline.com> On Tue, 21 Sep 2010, Positively Optimistic wrote: > Do any of our fellow nanog members have experience with cable management on > 6509/6513 cisco switches? We're upgrading infrastructure in some of our > facilities,.. and until it came to cable management, the switches seemed to > be a great idea... 8 48port blades.. pose a challenge.. or a problem.. > > Pictures are welcomed... off-list contact would be great. > > Thanks > If you can choose your rack equipment, you should look at Ortronics Might Mo 10. It is very stable and has plenty of cable management options. They are kind of a cross between a two post and a cabinet. Basicaly the side cannel is 16.25 inces deep. Unfortunatly, the 6500 has slot spacing that doesn't line up with rack U's so most cable management will not work perfectly. The Might Mo can handle the density but make sure you use the largest vertical channels you have room for. You probably are not interested in doors but in locations where this is desired, the doors over the vertical channels hinge both wasy and remove easier than anything I've seen. You probably want to look at the air baffles since the 6509/6513 have right to left airflow rather than front to back. One fo the features in the Mighty Mo 10 is the ventilated side channels and available baffles. The airflow can actualy be one of your biggest challenges if you have 6509/6513's in adjacent cabinets. The warm air from one can blow into the input of the switch to the left. You could also look at using the WS-C6509-V-E chassis with front to back airflow and built in cable management. From: Brian Dantzig Senior Network Engineer Medline Industries, Inc. bdantzig at medline.com From jeffw at smoe.org Tue Sep 21 20:16:44 2010 From: jeffw at smoe.org (Jeff Wasilko) Date: Tue, 21 Sep 2010 16:16:44 -0400 Subject: Cisco 6509/6513 cable management... In-Reply-To: <1F26704905C4804AAF98B0AE6BE029510352E095@MUNEXBE1.medline.com> References: <1F26704905C4804AAF98B0AE6BE029510352E095@MUNEXBE1.medline.com> Message-ID: <20100921201644.GA31574@fs1.rfc1918.smoe.org> On Tue, Sep 21, 2010 at 02:53:58PM -0500, Dantzig, Brian wrote: > On Tue, 21 Sep 2010, Positively Optimistic wrote: > > > Do any of our fellow nanog members have experience with cable > management on > > 6509/6513 cisco switches? We're upgrading infrastructure in some of > our > > facilities,.. and until it came to cable management, the switches > seemed to > > be a great idea... 8 48port blades.. pose a challenge.. or a > problem.. > > > > Pictures are welcomed... off-list contact would be great. > > > > Thanks > > > > If you can choose your rack equipment, you should look at Ortronics > Might Mo 10. It is very stable and has plenty of cable management Let me 2nd the mighty mo! We went with them, and had our cabling contractor pre-wire the switch faces to patch panels. They're really nice--probably the nicest rack system I've worked with. In the photo http://www.flickr.com/photos/jwasilko/3213527881/in/set-72157612760455411/ the first 2 racks with black patches are for patching switch ports to racks. The Ciscos are in the 3rd and 4th racks. One of the things we did that worked out very nice was on the switch/rack patch panel, we interspersed switch ports and rack ports every 2U. This means that we can often patch servers to switch ports with a 2 or 3' cable, which really minimizes the amount of extra cable running up and down patch panels. I've got a bunch of other photos at: http://www.smoe.org/jeffw/gallery-new/e_dc_build_2008-10-06 http://www.smoe.org/jeffw/gallery-new/e_dc_build_2008-07-15 From mksmith at adhost.com Tue Sep 21 20:59:03 2010 From: mksmith at adhost.com (Michael K. Smith - Adhost) Date: Tue, 21 Sep 2010 13:59:03 -0700 Subject: US hunters shoot down Google fibre In-Reply-To: References: <20100921100452.GQ14773@leitl.org> <4C98D1B8.2070503@craigslist.org> Message-ID: <17838240D9A5544AAA5FF95F8D52031608F040A8@ad-exh01.adhost.lan> > -----Original Message----- > From: Reese [mailto:reese at inkworkswell.com] > Sent: Tuesday, September 21, 2010 12:36 PM > To: nanog at nanog.org > Subject: Re: US hunters shoot down Google fibre > > At 11:39 21 09 10, Leslie wrote: > > >I don't think anyone is claiming all hunters/gun owners are irresponsible, > > Re-read the article. "[h]unters" it said, not "some hunters" or > "irresponsible hunters". How broad must the brush be, before you > feel personally impugned and maligned? > > >but, as with any segment of the population, when you have a large > >group there will be a percentage of complete idiots out there who > >take stupid actions. > > I acknowledged that. I regret its truthiness. But with Google and > only Google as a named victim of the hardware DoS, I have yet to > read anything that convinces me that it was not corporate sabotage. > > My point was not that wires and insulators do not get shot or shot > at, but that "hunters" was a convenient excuse that other things > could be too-conveniently classified with. > > Who, here, hunts? Shoot at wires and insulators on towers, do you? > > Reese > > I live in Washington State and have managed a fiber network along paths similar to the ones being taken by Google. Every winter we had at least 4 shotgun-blast outages, sometimes in the middle of nowhere and sometimes with a direct line of site to the back porch of a local "manufactured home". You would be amazed at what people find fun with during a long, cold winter and a belly full of libations. And I can almost guarantee you it wasn't sabotage. In many cases, the revelers were shooting at power lines and happened to hit the fibers wrapped around the ground wire. These are 500 kV lines by the way. Long story short, you can't account for stupid. Mike -- Michael K. Smith - CISSP, GSEC, GISP Chief Technical Officer - Adhost Internet LLC mksmith at adhost.com w: +1 (206) 404-9500 f: +1 (206) 404-9050 PGP: B49A DDF5 8611 27F3 08B9 84BB E61E 38C0 (Key ID: 0x9A96777D) From mpalmer at hezmatt.org Tue Sep 21 20:54:14 2010 From: mpalmer at hezmatt.org (Matthew Palmer) Date: Wed, 22 Sep 2010 06:54:14 +1000 Subject: Did Internet Founders Actually Anticipate Paid, In-Reply-To: <5A6D953473350C4B9995546AFE9939EE0A52AE39@RWC-EX1.corp.seven.com> References: <20100921051418.GW3803@hezmatt.org> <5A6D953473350C4B9995546AFE9939EE0A52AE39@RWC-EX1.corp.seven.com> Message-ID: <20100921205414.GA660@hezmatt.org> On Tue, Sep 21, 2010 at 09:31:07AM -0700, George Bonser wrote: > > Yes they are -- content providers aren't getting their connections to > > the > > Internet for free (and if they are, how can I get me some of that?). > > Maybe I wasn't clear. Traffic is moving away from "transit" to direct > peering at private exchanges in many cases. [Citation needed] > > > If the ISPs are directly peering with the content provider at > > > some IX, the content provider gets what amounts to a free ride to > the > > > end user. > > > > Say wha? ISPs don't *have* to peer at an IX; if they think that it's > > cheaper to buy transit from someone than it is to peer, they're more > > than > > capable of doing so. > > Transit would have to get extremely cheap to compete with exchange > peering. I don't see it getting that low any time soon. So it *is* cheaper to peer than to buy transit. Take the money you save from not buying transit and put it towards upgrading your core. - Matt -- Generally the folk who love the environment in vague, frilly ways are at odds with folk who love the environment next to the mashed potatoes. -- Anthony de Boer, in a place that does not exist From tvhawaii at shaka.com Tue Sep 21 21:10:25 2010 From: tvhawaii at shaka.com (Michael Painter) Date: Tue, 21 Sep 2010 11:10:25 -1000 Subject: US hunters shoot down Google fibre References: <20100921100452.GQ14773@leitl.org><485ED9BA02629E4BBBA53AC892EDA50E0BBCAB69@usmsxt104.mwd.h2o><4C98F34C.5000706@rollernet.us> Message-ID: David DiGiacomo wrote: > Instead of a rifle, how about a shotgun? It fires a nice wide spread shot pattern. I think you would be much more likely > to do > some damage (ie: knock fiber off a pole) with something like that. Here in New Jersey it is illegal to use a rifle to > hunt deer, > so typically you will find hunters using a bow/arrow or Shotgun and you will see a lot of road signs (or other abandon > junk) that > has been victim of a shotgun blast. > > ~Dave Birds like to sit on wires and assholes like to shoot them. 50 years ago I carried around the .22 slug I dug out of the lead-sheathed cable while troubleshooting the outer marker for McClellan AFB in the middle of a rainy night. --Michael From joelja at bogus.com Tue Sep 21 21:27:21 2010 From: joelja at bogus.com (Joel Jaeggli) Date: Tue, 21 Sep 2010 14:27:21 -0700 Subject: US hunters shoot down Google fibre In-Reply-To: References: <20100921100452.GQ14773@leitl.org><485ED9BA02629E4BBBA53AC892EDA50E0BBCAB69@usmsxt104.mwd.h2o><4C98F34C.5000706@rollernet.us> Message-ID: <4C992339.6030805@bogus.com> On 9/21/10 2:10 PM, Michael Painter wrote: > David DiGiacomo wrote: >> Instead of a rifle, how about a shotgun? It fires a nice wide spread >> shot pattern. I think you would be much more likely to do >> some damage (ie: knock fiber off a pole) with something like that. >> Here in New Jersey it is illegal to use a rifle to hunt deer, >> so typically you will find hunters using a bow/arrow or Shotgun and >> you will see a lot of road signs (or other abandon junk) that >> has been victim of a shotgun blast. you don't hunt deer with buckshot... the shotgun consideration is due to the range, and the expectation is that your target is under 100 meters. http://en.wikipedia.org/wiki/Shotgun_slug >> ~Dave > > Birds like to sit on wires and assholes like to shoot them. > 50 years ago I carried around the .22 slug I dug out of the > lead-sheathed cable while troubleshooting the outer marker for McClellan > AFB in the middle of a rainy night. > > --Michael > From nanog-post at rsuc.gweep.net Tue Sep 21 21:29:10 2010 From: nanog-post at rsuc.gweep.net (Joe Provo) Date: Tue, 21 Sep 2010 17:29:10 -0400 Subject: US hunters shoot down Google fibre In-Reply-To: <17838240D9A5544AAA5FF95F8D52031608F040A8@ad-exh01.adhost.lan> References: <4C98D1B8.2070503@craigslist.org> <17838240D9A5544AAA5FF95F8D52031608F040A8@ad-exh01.adhost.lan> Message-ID: <20100921212909.GA8291@gweep.net> ...and I used to live in parts of Virginia where rednecks took out signs with shotguns and no doubt now [if not run out by gentrification] take out fiber. On Tue, Sep 21, 2010 at 01:59:03PM -0700, Michael K. Smith - Adhost wrote: [snip] > Long story short, you can't account for stupid. ...and the same presentation reported on from AUSNOG was at last NANOG in SF by the same presenter. Can some kind hunter deliver the coup de grace to this thread? Just cruel to keep beating this horse with the same anecdote sticks. -- RSUC / GweepNet / Spunk / FnB / Usenix / SAGE From jbates at brightok.net Tue Sep 21 21:39:16 2010 From: jbates at brightok.net (Jack Bates) Date: Tue, 21 Sep 2010 16:39:16 -0500 Subject: US hunters shoot down Google fibre In-Reply-To: <4C990D20.8060105@zill.net> References: <20100921100452.GQ14773@leitl.org> <4C990D20.8060105@zill.net> Message-ID: <4C992604.9090206@brightok.net> On 9/21/2010 2:53 PM, Patrick Giagnocavo wrote: > On 9/21/2010 6:04 AM, Eugen Leitl wrote: >> >> http://www.itnews.com.au/News/232831,us-hunters-shoot-down-google-fibre.aspx >> > > 1. Deer tend to hang out in little clearings while eating. Little > clearings like the right of way clearing 25 or 50 feet on each side of > an electricity pylon. > Deer hang out in a lot of places that I wouldn't shoot them. > 2. Deer are easier to shoot when their silhouette is seen at or near > the top of a ridge, especially if they are in a clearing as well. > This is why most states require hunter safety courses, which among other things points out that not only should you be able to identify your target, but you should have good visibility behind your target. Bullets pass through animals (or miss), and continue to travel. Silhouette on a ridge shootings is how people get shot accidentally. > Combine #1 and #2, it is logical that even without "bubbas" the > deer/fiber coincidence level would be high. Any true hunter combining #1 and #2 should have his license permanently revoked. Why not just shoot deer in headlights or on roads, or in populated areas with people and houses behind them? (sarcasm) That being said, there are plenty of people that just shoot things; inanimate objects or animals (often without a license). The article wasn't meant to be, but is insulting. Incidents involving guns, cars, ATVs, etc, etc aren't too uncommon, though the damage for us is usually less than a single wildfire (which melts the peds for the ground cable and destroys the poles and cable for the aerial). Heck, we had a semi riding the back roads (possibly to avoid highway patrol) snag an aerial crossing the road. It was witnessed by the local gas station attendant. he dragged the cabled for 1000 feet or so, ripping down poles. Stopped, unhooked the cable from the truck, and drove off. Jack From tvhawaii at shaka.com Tue Sep 21 23:14:58 2010 From: tvhawaii at shaka.com (Michael Painter) Date: Tue, 21 Sep 2010 13:14:58 -1000 Subject: Juniper SSG-140, Monitoring and control the usage of the Internet References: <261E17F810EEC548ACD322ED2E847CE30B9B28@exten02.kyiv.ciklum.net> Message-ID: Yasir Munir Abbasi wrote: > Hi, > > I have a SSG-140 Juniper Firewall. I need to ask, how can I Monitor the individual IP traffic? I mean I want to see who > is taking > more bandwidth. > > Please help me out. Thanks > > Yasir Munir Abbasi > Senior Network Engineer > EMail: yamu at ciklum.net ntop? http://www.ntop.org/overview.html From tvhawaii at shaka.com Wed Sep 22 00:06:50 2010 From: tvhawaii at shaka.com (Michael Painter) Date: Tue, 21 Sep 2010 14:06:50 -1000 Subject: async serial fiber transceivers References: <4C98C259.7020309@bc.edu> Message-ID: <00F62D83D5544102B39F6AD9F9169AF3@DELL16> Christopher O'Brien wrote: > Greetings, > I am planning on deploying a console access server on my network for > 20-30 network devices including routers, wireless controllers and other > devices. The design is to have one central device for all console access. > > Due to the geographic diversity of my campus, I will need need to carry > the async serial connections over my fiber plant with long reach optics > and single mode fiber. I have the fiber plant to support this design. > I have been researching solutions to implement the serial part, but I am > not very familiar with the vendors I am coming up with. For instance, I > know Black Box Networks makes products like this but they only seem to > have stand alone devices. I was hoping for something rack mountable > since I will have a dense deployment of these devices. > > Does anyone have experience deploying a solution like this or with async > serial fiber transceivers in general? I welcome any suggestions. > -Chris You could try calling these folks: http://www.bb-elec.com/custom.asp http://www.bb-elec.com/SubCategory.asp?SubCategoryId=34&Trail=11&TrailType=Main From nite97m at gmail.com Wed Sep 22 14:03:23 2010 From: nite97m at gmail.com (Matthew Schlegel) Date: Wed, 22 Sep 2010 09:03:23 -0500 Subject: Cisco 6509/6513 cable management... In-Reply-To: <20100921201644.GA31574@fs1.rfc1918.smoe.org> References: <1F26704905C4804AAF98B0AE6BE029510352E095@MUNEXBE1.medline.com> <20100921201644.GA31574@fs1.rfc1918.smoe.org> Message-ID: On Tue, Sep 21, 2010 at 15:16, Jeff Wasilko wrote: > On Tue, Sep 21, 2010 at 02:53:58PM -0500, Dantzig, Brian wrote: > > On Tue, 21 Sep 2010, Positively Optimistic wrote: > > > > Let me 2nd the mighty mo! We went with them, and had our cabling > contractor pre-wire the switch faces to patch panels. They're really > nice--probably the nicest rack system I've worked with. > > > I'll give a hearty second to prewired patch panels. Even with the best cable management systems, patching directly into the switch is likely to eventually get messy. At least with the patch panels, even if cabling there gets messy for any reason, the front of the switches stay nice and clean, which makes a huge difference if you ever have a line card swap. From ryanshea at google.com Wed Sep 22 14:32:09 2010 From: ryanshea at google.com (Ryan Shea) Date: Wed, 22 Sep 2010 10:32:09 -0400 Subject: IPv6 tunnel brokers that provide BGP other than HE? In-Reply-To: References: <483E6B0272B0284BA86D7596C40D29F9E2C7B8064D@PUR-EXCH07.ox.com> Message-ID: Maybe I am not clear, but without being able to detect when the 6in4 tunnel goes away, how does a second tunnel provide useful redundancy? -Ryan On Tue, Sep 21, 2010 at 11:31 AM, Jack Carrozzo wrote: > OCCAID has been doing this for a while but I don't see anything on their > site about it. Might try contacting them. > > -Jack Carrozzo > > On Tue, Sep 21, 2010 at 11:04 AM, Owen DeLong wrote: > > > Not a complete solution, but, you could always do a second HE tunnel to a > > different site for at least > > some level of redundancy. > > > > Owen > > > > On Sep 21, 2010, at 7:12 AM, Matthew Huff wrote: > > > > > Neither of our upstream providers offer direct ipv6 although both claim > > deployment in Q1 2011. In the meantime, we have a tunnel with BGP to HE > > announcing our /48, but we are looking for redundancy. Is there anyone > else > > out there offering services like Hurricane Electric? > > > > > > > > > > > > ---- > > > 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 mhuff at ox.com Wed Sep 22 14:35:17 2010 From: mhuff at ox.com (Matthew Huff) Date: Wed, 22 Sep 2010 10:35:17 -0400 Subject: IPv6 tunnel brokers that provide BGP other than HE? In-Reply-To: References: <483E6B0272B0284BA86D7596C40D29F9E2C7B8064D@PUR-EXCH07.ox.com> Message-ID: <483E6B0272B0284BA86D7596C40D29F9E2C7B80666@PUR-EXCH07.ox.com> With BGP it does. We are announcing a provider independent /48 address space, and receive the ipv6 bgp routes. ---- 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: Ryan Shea [mailto:ryanshea at google.com] > Sent: Wednesday, September 22, 2010 10:32 AM > To: Jack Carrozzo > Cc: (nanog at nanog.org) > Subject: Re: IPv6 tunnel brokers that provide BGP other than HE? > > Maybe I am not clear, but without being able to detect when the 6in4 tunnel > goes away, how does a second tunnel provide useful redundancy? > > -Ryan > > On Tue, Sep 21, 2010 at 11:31 AM, Jack Carrozzo wrote: > > > OCCAID has been doing this for a while but I don't see anything on their > > site about it. Might try contacting them. > > > > -Jack Carrozzo > > > > On Tue, Sep 21, 2010 at 11:04 AM, Owen DeLong wrote: > > > > > Not a complete solution, but, you could always do a second HE tunnel to a > > > different site for at least > > > some level of redundancy. > > > > > > Owen > > > > > > On Sep 21, 2010, at 7:12 AM, Matthew Huff wrote: > > > > > > > Neither of our upstream providers offer direct ipv6 although both claim > > > deployment in Q1 2011. In the meantime, we have a tunnel with BGP to HE > > > announcing our /48, but we are looking for redundancy. Is there anyone > > else > > > out there offering services like Hurricane Electric? > > > > > > > > > > > > > > > > ---- > > > > Matthew Huff | One Manhattanville Rd > > > > OTA Management LLC | Purchase, NY 10577 > > > > http://www.ox.com | Phone: 914-460-4039 > > > > aim: matthewbhuff | Fax: 914-460-4139 > > > > > > > > > > > > > > > > > > > > > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: Matthew Huff.vcf Type: text/x-vcard Size: 1612 bytes Desc: Matthew Huff.vcf URL: From nick at brevardwireless.com Wed Sep 22 14:51:15 2010 From: nick at brevardwireless.com (Nick Olsen) Date: Wed, 22 Sep 2010 10:51:15 -0400 Subject: IPv6 tunnel brokers that provide BGP other than HE? Message-ID: <20dd9a5d$47b8d1f3$5965c8bb$@com> We do the same with HE, but we announce a /32 we have from arin. I think most of our upstreams do native ipv6 I'm just to lazy to flip the switches. Considering were not really giving ipv6 to customers yet(soon). Even when we go native, I figure we'll keep a session with HE, Don't see any disadvantages of it.. Nick Olsen Network Operations (877) 804-3001 x106 ---------------------------------------- From: "Matthew Huff" Sent: Wednesday, September 22, 2010 10:36 AM To: "Ryan Shea" , "Jack Carrozzo" Subject: RE: IPv6 tunnel brokers that provide BGP other than HE? With BGP it does. We are announcing a provider independent /48 address space, and receive the ipv6 bgp routes. ---- 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: Ryan Shea [mailto:ryanshea at google.com] > Sent: Wednesday, September 22, 2010 10:32 AM > To: Jack Carrozzo > Cc: (nanog at nanog.org) > Subject: Re: IPv6 tunnel brokers that provide BGP other than HE? > > Maybe I am not clear, but without being able to detect when the 6in4 tunnel > goes away, how does a second tunnel provide useful redundancy? > > -Ryan > > On Tue, Sep 21, 2010 at 11:31 AM, Jack Carrozzo wrote: > > > OCCAID has been doing this for a while but I don't see anything on their > > site about it. Might try contacting them. > > > > -Jack Carrozzo > > > > On Tue, Sep 21, 2010 at 11:04 AM, Owen DeLong wrote: > > > > > Not a complete solution, but, you could always do a second HE tunnel to a > > > different site for at least > > > some level of redundancy. > > > > > > Owen > > > > > > On Sep 21, 2010, at 7:12 AM, Matthew Huff wrote: > > > > > > > Neither of our upstream providers offer direct ipv6 although both claim > > > deployment in Q1 2011. In the meantime, we have a tunnel with BGP to HE > > > announcing our /48, but we are looking for redundancy. Is there anyone > > else > > > out there offering services like Hurricane Electric? > > > > > > > > > > > > > > > > ---- > > > > 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 hj1980 at gmail.com Wed Sep 22 15:18:15 2010 From: hj1980 at gmail.com (Heath Jones) Date: Wed, 22 Sep 2010 16:18:15 +0100 Subject: Odd BGP AS Path Message-ID: Hi all, Probably a silly question, but can anyone explain to me this: 3561 3356 9031 {35821,35821,35821,35821} i To explain it a bit better, I'm looking at real routing information from routeviews (#3). According to RFC 4271 (9.2.2.2 Aggregating Routing Information): > For the purpose of aggregating AS_PATH attributes, we model > each AS within the AS_PATH attribute as a tuple , > where "type" identifies a type of the path segment the AS > belongs to (e.g., AS_SEQUENCE, AS_SET), and "value" identifies > the AS number. > ... > No tuple of type AS_SET with the same value SHALL appear > more than once in the aggregated AS_PATH. Am I misreading things, or is this path information out of spec? Cheers Heath From randy at psg.com Wed Sep 22 15:30:44 2010 From: randy at psg.com (Randy Bush) Date: Wed, 22 Sep 2010 11:30:44 -0400 Subject: Odd BGP AS Path In-Reply-To: References: Message-ID: > Probably a silly question, but can anyone explain to me this: > 3561 3356 9031 {35821,35821,35821,35821} i please support draft-wkumari-deprecate-as-sets-00.txt randy From hj1980 at gmail.com Wed Sep 22 15:33:36 2010 From: hj1980 at gmail.com (Heath Jones) Date: Wed, 22 Sep 2010 16:33:36 +0100 Subject: Odd BGP AS Path In-Reply-To: References: Message-ID: > please support draft-wkumari-deprecate-as-sets-00.txt I just noticed that then - looking through idr list archives. I'll give it a read.. What is the best way to support, just email the list? Cheers From morrowc.lists at gmail.com Wed Sep 22 15:39:26 2010 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Wed, 22 Sep 2010 11:39:26 -0400 Subject: Odd BGP AS Path In-Reply-To: References: Message-ID: On Wed, Sep 22, 2010 at 11:33 AM, Heath Jones wrote: >> please support draft-wkumari-deprecate-as-sets-00.txt > I just noticed that then - looking through idr list archives. I'll > give it a read.. > What is the best way to support, just email the list? yes From randy at psg.com Wed Sep 22 15:42:51 2010 From: randy at psg.com (Randy Bush) Date: Wed, 22 Sep 2010 11:42:51 -0400 Subject: Odd BGP AS Path In-Reply-To: References: Message-ID: >> please support draft-wkumari-deprecate-as-sets-00.txt > I just noticed that then - looking through idr list archives. I'll > give it a read.. > What is the best way to support, just email the list? i am not sure, as truth be told, i do not follow idr. a fair but not sure inference from its name (not being draft-ietf-idr-...) is folk need to push for it to be taken on as a wg work item/draft. the ietf ops cabal was certainly behind it, and encouraged warren to don the kevlar and venture forth. and, while you are tilting at windmills, you can help push the full prefix match draft, draft-kohno-ipv6-prefixlen-p2p-02.txt, in 6man. now all we need is someone to write draft-deprecate-ipv6-subnet-anycast randy From psirt at cisco.com Wed Sep 22 16:00:00 2010 From: psirt at cisco.com (Cisco Systems Product Security Incident Response Team) Date: Wed, 22 Sep 2010 18:00:00 +0200 Subject: Cisco Security Advisory: Cisco Unified Communications Manager Session Initiation Protocol Denial of Service Vulnerabilities Message-ID: <201009221801.cucmsip@psirt.cisco.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Cisco Unified Communications Manager Session Initiation Protocol Denial of Service Vulnerabilities Advisory ID: cisco-sa-20100922-cucmsip http://www.cisco.com/warp/public/707/cisco-sa-20100922-cucmsip.shtml Revision 1.0 For Public Release 2010 September 22 1600 UTC (GMT) - --------------------------------------------------------------------- Summary ======= Cisco Unified Communications Manager contains two denial of service (DoS) vulnerabilities that affect the processing of Session Initiation Protocol (SIP) messages. Exploitation of these vulnerabilities could cause an interruption of voice services. To address these vulnerabilities, Cisco has released free software updates. There is a workaround for these vulnerabilities. This advisory is posted at http://www.cisco.com/warp/public/707/cisco-sa-20100922-cucmsip.shtml Note: Cisco IOS Software is also affected by the vulnerabilities described in this advisory. A companion advisory for Cisco IOS software is available at: http://www.cisco.com/warp/public/707/cisco-sa-20100922-sip.shtml Note: The September 22, 2010, Cisco IOS Software Security Advisory bundled publication includes six Cisco Security Advisories. Five of the advisories address vulnerabilities in Cisco IOS Software and one advisory addresses vulnerabilities in Cisco Unified Communications Manager. Each advisory lists the releases that correct the vulnerability or vulnerabilities detailed in the advisory. The table at the following URL lists releases that correct all Cisco IOS Software vulnerabilities that have been published on September 22, 2010, or earlier: http://www.cisco.com/warp/public/707/cisco-sa-20100922-bundle.shtml Individual publication links are in "Cisco Event Response: Semiannual Cisco IOS Software Security Advisory Bundled Publication" at the following link: http://www.cisco.com/web/about/security/intelligence/Cisco_ERP_sep10.html Affected Products ================= Vulnerable Products +------------------ The following products are affected by the vulnerabilities that are described in this advisory: * Cisco Unified Communications Manager 6.x * Cisco Unified Communications Manager 7.x * Cisco Unified Communications Manager 8.x Administrators of systems that are running Cisco Unified Communications Manager versions 6.x, 7.x and 8.x can determine the software version by viewing the main page of the Cisco Unified Communications Manager Administration interface. The software version can also be determined by running the show version active command via the command-line interface. Products Confirmed Not Vulnerable +-------------------------------- Cisco Unified Communications Manager version 4.x is not affected by these vulnerabilities. No other Cisco products are currently known to be affected by these vulnerabilities. Details ======= Cisco Unified Communications Manager is the call processing component of the Cisco IP Telephony solution that extends enterprise telephony features and functions to packet telephony network devices such as IP phones, media processing devices, VoIP gateways, and multimedia applications. Cisco Unified Communications Manager contains two DoS vulnerabilities that involve the processing of SIP messages. Each vulnerability is triggered by a malformed SIP message that could cause a critical process to fail, which could result in the disruption of voice services. All SIP ports (TCP ports 5060 and 5061 and UDP ports 5060 and 5061) are affected. The first SIP DoS vulnerability is documented in Cisco Bug ID CSCta31358 ( registered customers only) and has been assigned the CVE identifier CVE-2010-2835. This vulnerability is fixed in Cisco Unified Communications Manager versions 6.1(5), 7.0(2a)su3, 7.1(3b) su2, 7.1(5) and 8.0(1). The corresponding IOS defect is CSCta20040. The second SIP DoS vulnerability is documented in Cisco Bug ID CSCtf14987 ( registered customers only) and has been assigned the CVE identifier CVE-2010-2834. The second vulnerability is fixed in Cisco Unified Communications Manager versions 6.1(5)SU1, 7.1(5) and 8.0(2). The corresponding IOS defect is CSCtf72678. Vulnerability Scoring Details ============================= Cisco has provided scores for the vulnerabilities in this advisory based on the Common Vulnerability Scoring System (CVSS). The CVSS scoring in this Security Advisory is done in accordance with CVSS version 2.0. CVSS is a standards-based scoring method that conveys vulnerability severity and helps determine urgency and priority of response. Cisco has provided a base and temporal score. Customers can then compute environmental scores to assist in determining the impact of the vulnerability in individual networks. Cisco has provided an FAQ to answer additional questions regarding CVSS at: http://www.cisco.com/web/about/security/intelligence/cvss-qandas.html Cisco has also provided a CVSS calculator to help compute the environmental impact for individual networks at: http://intellishield.cisco.com/security/alertmanager/cvss CSCta31358 - c3945 GW crashes while testing REFER method with invalid Refer-To header 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 CSCtf14987 - CCM Coredump Generated During UDP SIP Registration Fuzzing 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 vulnerabilities that are described in this advisory could result in the interruption of voice services. Cisco Unified Communications Manager will restart the affected processes, but repeated attacks may result in a sustained DoS Condition. Software Versions and Fixes =========================== When considering software upgrades, also consult http://www.cisco.com/go/psirt and any subsequent advisories to determine exposure and a complete upgrade solution. In all cases, customers should exercise caution to be certain the devices to be upgraded contain sufficient memory and that current hardware and software configurations will continue to be supported properly by the new release. If the information is not clear, contact the Cisco Technical Assistance Center (TAC) or your contracted maintenance provider for assistance. +---------------------------------------+ | Cisco Unified | Recommended | | Communication Manager | Release | | Version | | |-------------------------+-------------| | 6.x | 6.1(5)SU1 | |-------------------------+-------------| | 7.x | 7.1(5b)SU2 | |-------------------------+-------------| | 8.x | 8.0(3a) | +---------------------------------------+ Note: The recommended releases listed in the table above are the latest Cisco Unified Communications Manager versions available at the publication of this advisory, and each release includes software fixes for all the vulnerabilities described in this advisory. Cisco Unified Communications Manager software can be downloaded at the following link: http://tools.cisco.com/support/downloads/go/Redirect.x?mdfid=268439621 Workarounds =========== For customers who do not use SIP in their environment, there is a workaround for these vulnerabilities. Cisco Unified Communication Manager versions 6.1(4), 7.1(2) and 8.0(1) introduced the ability to disable SIP processing. SIP processing is enabled by default. Use the following instructions to disable SIP processing: Step 1: Log into the Cisco Unified CM Administration web interface. Step 2: Navigate to System > Service Parameters and select the appropriate Cisco Unified Communications Manager server and the "Cisco CallManager" service. Step 3: Change the "SIP Interoperability Enabled" parameter to False, and click Save. Note: For a SIP processing change to take effect, the Cisco CallManager Service must be restarted. For information on how to restart the service, refer to the "Restarting the Cisco CallManager Service" section of the document at: http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/admin/7_1_2/ccmcfg/b03dpi.html#wp1075124 It is possible to mitigate these vulnerabilities by implementing filtering on screening devices and permitting access to TCP ports 5060 and 5061 and UDP ports 5060 and 5061 only from networks that require SIP access to Cisco Unified Communications Manager servers. Additional mitigations that can be deployed on Cisco devices in the network are available in the companion document "Cisco Applied Mitigation Bulletin: Identifying and Mitigating Exploitation of the Multiple Vulnerabilities in Cisco Voice Products", which is available at the following location: http://www.cisco.com/warp/public/707/cisco-amb-20100922-voice.shtml Obtaining Fixed Software ======================== Cisco has released free software updates that address these vulnerabilities. Prior to deploying software, customers should consult their maintenance provider or check the software for feature set compatibility and known issues specific to their environment. Customers may only install and expect support for the feature sets they have purchased. By installing, downloading, accessing or otherwise using such software upgrades, customers agree to be bound by the terms of Cisco's software license terms found at http://www.cisco.com/en/US/docs/general/warranty/English/EU1KEN_.html or as otherwise set forth at Cisco.com Downloads at http://www.cisco.com/public/sw-center/sw-usingswc.shtml Do not contact psirt at cisco.com or security-alert at cisco.com for software upgrades. Customers with Service Contracts +------------------------------- Customers with contracts should obtain upgraded software through their regular update channels. For most customers, this means that upgrades should be obtained through the Software Center on Cisco's worldwide website at http://www.cisco.com Customers using Third Party Support Organizations +------------------------------------------------ Customers whose Cisco products are provided or maintained through prior or existing agreements with third-party support organizations, such as Cisco Partners, authorized resellers, or service providers should contact that support organization for guidance and assistance with the appropriate course of action in regards to this advisory. The effectiveness of any workaround or fix is dependent on specific customer situations, such as product mix, network topology, traffic behavior, and organizational mission. Due to the variety of affected products and releases, customers should consult with their service provider or support organization to ensure any applied workaround or fix is the most appropriate for use in the intended network before it is deployed. Customers without Service Contracts +---------------------------------- Customers who purchase direct from Cisco but do not hold a Cisco service contract, and customers who purchase through third-party vendors but are unsuccessful in obtaining fixed software through their point of sale should acquire upgrades by contacting the Cisco Technical Assistance Center (TAC). TAC contacts are as follows. * +1 800 553 2447 (toll free from within North America) * +1 408 526 7209 (toll call from anywhere in the world) * e-mail: tac at cisco.com Customers should have their product serial number available and be prepared to give the URL of this notice as evidence of entitlement to a free upgrade. Free upgrades for non-contract customers must be requested through the TAC. Refer to http://www.cisco.com/en/US/support/tsd_cisco_worldwide_contacts.html for additional TAC contact information, including localized telephone numbers, and instructions and e-mail addresses for use in various languages. Exploitation and Public Announcements ===================================== The Cisco PSIRT is not aware of any public announcements or malicious use of the vulnerabilities described in this advisory. All vulnerabilities described in this advisory were discovered as a result of internal testing conducted by Cisco. 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-20100922-cucmsip.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 | 2010-September-22 | 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.10 (Darwin) iEYEARECAAYFAkyaIp0ACgkQ86n/Gc8U/uCsDQCbBrZ7ciwiNVxErJOxLLICNgXv dE0An3lej+RKwoUMMf+GKTm/BBOHmlQL =dwdr -----END PGP SIGNATURE----- From psirt at cisco.com Wed Sep 22 16:00:00 2010 From: psirt at cisco.com (Cisco Systems Product Security Incident Response Team) Date: Wed, 22 Sep 2010 18:00:00 +0200 Subject: Cisco Security Advisory: Cisco IOS Software Network Address Translation Vulnerabilities Message-ID: <201009221801.nat@psirt.cisco.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Cisco Security Advisory: Cisco IOS Software Network Address Translation Vulnerabilities Advisory ID: cisco-sa-20100922-nat http://www.cisco.com/warp/public/707/cisco-sa-20100922-nat.shtml Revision 1.0 For Public Release 2010 September 22 1600 UTC (GMT) - --------------------------------------------------------------------- Summary ======= The Cisco IOS Software Network Address Translation functionality contains three denial of service (DoS) vulnerabilities. The first vulnerability is in the translation of Session Initiation Protocol (SIP) packets, the second vulnerability in the translation of H.323 packets and the third vulnerability is in the translation of H.225.0 call signaling for H.323 packets. Cisco has released free software updates that address these vulnerabilities. This advisory is posted at http://www.cisco.com/warp/public/707/cisco-sa-20100922-nat.shtml Note: The September 22, 2010, Cisco IOS Software Security Advisory bundled publication includes six Cisco Security Advisories. Five of the advisories address vulnerabilities in Cisco IOS Software, and one advisory addresses vulnerabilities in Cisco Unified Communications Manager. Each advisory lists the releases that correct the vulnerability or vulnerabilities detailed in the advisory. The table at the following URL lists releases that correct all Cisco IOS Software vulnerabilities that have been published on September 22, 2010, or earlier: http://www.cisco.com/warp/public/707/cisco-sa-20100922-bundle.shtml Individual publication links are in "Cisco Event Response: Semiannual Cisco IOS Software Security Advisory Bundled Publication" at the following link: http://www.cisco.com/web/about/security/intelligence/Cisco_ERP_sep10.html Affected Products ================= Vulnerable Products +------------------ Cisco devices running Cisco IOS Software that are configured for NAT and that support NAT for SIP, H.323, or H.225.0 call signaling for H.323 packets are affected. To verify whether NAT is enabled on a Cisco IOS device log in to the device and issue the show ip nat statistics command. The following example shows a device that is configured with NAT: Router#show ip nat statistics Total translations: 2 (0 static, 2 dynamic; 0 extended) Outside interfaces: Serial0 Inside interfaces: Ethernet1 Hits: 135 Misses: 5 Expired translations: 2 Dynamic mappings: -- Inside Source access-list 1 pool mypool refcount 2 pool mypool: netmask 255.255.255.0 start 192.168.10.1 end 192.168.10.254 type generic, total addresses 14, allocated 2 (14%), misses 0 Alternatively, administrators can use the show running-config | include ip nat command to verify if NAT has been enabled on the router interfaces. For NAT to be enabled in a router either the ip nat inside and ip nat outside commands must be present in different interfaces or, in the case of NAT Virtual Interface, if the ip nat enable interface command is present. In order to determine the software that runs on a Cisco IOS product, log in to the device and issue the show version command to display the system banner. Cisco IOS software identifies itself as "Internetwork Operating System Software" or simply "IOS." On the next line of output, the image name displays between parentheses, followed by "Version" and the Cisco IOS release name. Other Cisco devices do not have the show version command or give different output. The following example shows output from a device that runs an IOS image: Router> show version Cisco IOS Software, C3900 Software (C3900-UNIVERSALK9-M), Version 15.0(1)M1, RELEASE SOFTWARE (fc1) Technical Support: http://www.cisco.com/techsupport Copyright (c) 1986-2009 by Cisco Systems, Inc. Compiled Wed 02-Dec-09 17:17 by prod_rel_team Products Confirmed Not Vulnerable +-------------------------------- Cisco IOS devices not explicitly configured for NAT are not vulnerable. Cisco IOS XE Software is not affected by these vulnerabilities. Cisco IOS XR Software is not affected by these vulnerabilities. No other Cisco products are currently known to be affected by these vulnerabilities. Details ======= The three vulnerabilities are triggered by transit traffic that needs to be processed by the NAT feature. Each vulnerability is independent of each other. NAT for SIP DoS Vulnerability +---------------------------- SIP is a popular signaling protocol that is used to manage voice and video calls across IP networks such as the Internet. SIP is responsible for handling all aspects of call setup and termination. Voice and video are the most popular types of sessions that SIP handles, but the protocol has the flexibility to accommodate other applications that require call setup and termination. NAT for SIP translates packets using UDP (port 5060) or TCP (port 5060) as the underlying transport protocol. The NAT for SIP DoS vulnerability can be exploited only with the use of UDP port 5060 packets. This vulnerability is documented in Cisco bug ID CSCtf17624 and has been assigned Common Vulnerabilities and Exposures (CVE) ID CVE-2010-2831. NAT for H.323 DoS Vulnerability +------------------------------ H.323 is the International Telecommunication Union (ITU) standard for real-time multimedia communications and conferencing over packet-based (IP) networks. NAT for H.323 translates packets on TCP port 1720. There is a DoS vulnerability in the NAT procession of H.323 packets. The vulnerability does not require the completion of a TCP three-way handshake. This vulnerability is documented in Cisco bug ID CSCtf91428 and has been assigned Common Vulnerabilities and Exposures (CVE) IDs CVE-2010-2832. NAT for H.225.0 DoS vulnerability +-------------------------------- H.323 is the ITU standard for real-time multimedia communications and conferencing over packet-based (IP) networks. A subset of the H.323 standard is H.225.0, a standard used for call signaling protocols and media stream packetization over IP networks. NAT for H.225.0 translates packets on TCP port 1720. There is a DoS vulnerability in the NAT translation of H.225.0 call signaling for H.323 packets. This vulnerability is documented in Cisco bug ID CSCtd86472 and has been assigned Common Vulnerabilities and Exposures (CVE) IDs CVE-2010-2833. Vulnerability Scoring Details ============================= Cisco has provided scores for the vulnerabilities in this advisory based on the Common Vulnerability Scoring System (CVSS). The CVSS scoring in this Security Advisory is done in accordance with CVSS version 2.0. CVSS is a standards-based scoring method that conveys vulnerability severity and helps determine urgency and priority of response. Cisco has provided a base and temporal score. Customers can then compute environmental scores to assist in determining the impact of the vulnerability in individual networks. Cisco has provided an FAQ to answer additional questions regarding CVSS at: http://www.cisco.com/web/about/security/intelligence/cvss-qandas.html Cisco has also provided a CVSS calculator to help compute the environmental impact for individual networks at: http://intellishield.cisco.com/security/alertmanager/cvss CSCtf17624 - NAT SIP DoS Vulnerability 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 CSCtf91428 - NAT for H.323 DoS 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 CSCtd86472 - NAT for H.225.0 DoS 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 any of the vulnerabilities described in this document may cause the affected device to reload. Repeated exploitation will result in an extended denial of service (DoS) condition. Software Versions and Fixes =========================== When considering software upgrades, also consult http://www.cisco.com/go/psirt and any subsequent advisories to determine exposure and a complete upgrade solution. In all cases, customers should exercise caution to be certain the devices to be upgraded contain sufficient memory and that current hardware and software configurations will continue to be supported properly by the new release. If the information is not clear, contact the Cisco Technical Assistance Center (TAC) or your contracted maintenance provider for assistance. Each row of the following Cisco IOS Software table corresponds to a Cisco IOS Software train. If a particular train is vulnerable, the earliest releases that contain the fix are listed in the First Fixed Release For This Advisory column. The First Fixed Release for All Advisories in the September 2010 Bundle Publication column lists the earliest possible releases that correct all the published vulnerabilities in the Cisco IOS Software Security Advisory bundled publication. Cisco recommends upgrading to the latest available release, where possible. +-------------------------------------------------------------------+ | Major | Availability of Repaired Releases | | Release | | |------------+------------------------------------------------------| | Affected | | First Fixed Release for | | 12.0-Based | First Fixed Release for | All Advisories in the | | Releases | This Advisory | September 2010 Bundle | | | | Publication | |-------------------------------------------------------------------| | There are no affected 12.0 based releases | |-------------------------------------------------------------------| | Affected | | First Fixed Release for | | 12.1-Based | First Fixed Release for | All Advisories in the | | Releases | This Advisory | September 2010 Bundle | | | | Publication | |------------+--------------------------+---------------------------| | | Vulnerable; first fixed | Vulnerable; first fixed | | | in 12.4 | in 12.4T | | 12.1 | | | | | Releases up to and | Releases up to and | | | including 12.1(4b) are | including 12.1(4b) are | | | not vulnerable. | not vulnerable. | |------------+--------------------------+---------------------------| | 12.1AA | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | 12.1AX | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | 12.1AY | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | 12.1AZ | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | 12.1CX | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | 12.1DA | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | 12.1DB | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | 12.1DC | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | 12.1E | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | 12.1EA | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | 12.1EB | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | 12.1EC | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | 12.1EO | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | 12.1EU | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | 12.1EV | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | 12.1EW | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | 12.1EX | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | 12.1EY | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | 12.1EZ | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | 12.1GA | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | 12.1GB | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | | | Vulnerable; first fixed | | | | in 12.4T | | 12.1T | Not Vulnerable | | | | | Releases up to and | | | | including 12.1(3a)T8 are | | | | not vulnerable. | |------------+--------------------------+---------------------------| | 12.1XA | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | 12.1XB | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | 12.1XC | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | 12.1XD | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | 12.1XE | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | 12.1XF | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | 12.1XG | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | 12.1XH | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | 12.1XI | Not Vulnerable | Vulnerable; first fixed | | | | in 12.4T | |------------+--------------------------+---------------------------| | 12.1XJ | Not Vulnerable | Vulnerable; first fixed | | | | in 12.4T | |------------+--------------------------+---------------------------| | 12.1XL | Not Vulnerable | Vulnerable; first fixed | | | | in 12.4T | |------------+--------------------------+---------------------------| | 12.1XM | Not Vulnerable | Vulnerable; first fixed | | | | in 12.4T | |------------+--------------------------+---------------------------| | 12.1XP | Not Vulnerable | Vulnerable; first fixed | | | | in 12.4T | |------------+--------------------------+---------------------------| | 12.1XQ | Not Vulnerable | Vulnerable; first fixed | | | | in 12.4T | |------------+--------------------------+---------------------------| | 12.1XR | Not Vulnerable | Vulnerable; first fixed | | | | in 12.4T | |------------+--------------------------+---------------------------| | | | Vulnerable; first fixed | | | | in 12.4T | | 12.1XS | Not Vulnerable | | | | | Releases up to and | | | | including 12.1(3)XS are | | | | not vulnerable. | |------------+--------------------------+---------------------------| | | | Vulnerable; first fixed | | | | in 12.4T | | 12.1XT | Not Vulnerable | | | | | Releases up to and | | | | including 12.1(2)XT2 are | | | | not vulnerable. | |------------+--------------------------+---------------------------| | 12.1XU | Not Vulnerable | Vulnerable; first fixed | | | | in 12.4T | |------------+--------------------------+---------------------------| | 12.1XV | Not Vulnerable | Vulnerable; first fixed | | | | in 12.4T | |------------+--------------------------+---------------------------| | 12.1XW | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | 12.1XX | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | | | Vulnerable; first fixed | | | | in 12.4T | | 12.1XY | Not Vulnerable | | | | | Releases up to and | | | | including 12.1(4)XY are | | | | not vulnerable. | |------------+--------------------------+---------------------------| | 12.1XZ | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | 12.1YA | Not Vulnerable | Vulnerable; first fixed | | | | in 12.4T | |------------+--------------------------+---------------------------| | 12.1YB | Not Vulnerable | Vulnerable; first fixed | | | | in 12.4T | |------------+--------------------------+---------------------------| | 12.1YC | Not Vulnerable | Vulnerable; first fixed | | | | in 12.4T | |------------+--------------------------+---------------------------| | 12.1YD | Not Vulnerable | Vulnerable; first fixed | | | | in 12.4T | |------------+--------------------------+---------------------------| | | | Releases prior to 12.1(5) | | | | YE6 are vulnerable, | | 12.1YE | Not Vulnerable | release 12.1(5)YE6 and | | | | later are not vulnerable; | | | | first fixed in 12.4T | |------------+--------------------------+---------------------------| | 12.1YF | Not Vulnerable | Vulnerable; first fixed | | | | in 12.4T | |------------+--------------------------+---------------------------| | 12.1YH | Not Vulnerable | Vulnerable; first fixed | | | | in 12.4T | |------------+--------------------------+---------------------------| | | | Vulnerable; Contact your | | | | support organization per | | 12.1YI | Not Vulnerable | the instructions in | | | | Obtaining Fixed Software | | | | section of this advisory | |------------+--------------------------+---------------------------| | 12.1YJ | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | Affected | | First Fixed Release for | | 12.2-Based | First Fixed Release for | All Advisories in the | | Releases | This Advisory | September 2010 Bundle | | | | Publication | |------------+--------------------------+---------------------------| | | Vulnerable; first fixed | | | | in 12.4 | | | 12.2 | | Vulnerable; first fixed | | | Releases up to and | in 12.4T | | | including 12.2(16f) are | | | | not vulnerable. | | |------------+--------------------------+---------------------------| | | | Vulnerable; first fixed | | | | in 12.4T | | 12.2B | Not Vulnerable | | | | | Releases up to and | | | | including 12.2(2)B7 are | | | | not vulnerable. | |------------+--------------------------+---------------------------| | 12.2BC | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | 12.2BW | Not Vulnerable | Vulnerable; first fixed | | | | in 12.4T | |------------+--------------------------+---------------------------| | | | Vulnerable; first fixed | | | | in 12.2SB | | 12.2BX | Not Vulnerable | | | | | Releases up to and | | | | including 12.2(15)BX are | | | | not vulnerable. | |------------+--------------------------+---------------------------| | | | Vulnerable; first fixed | | | | in 12.4T | | 12.2BY | Not Vulnerable | | | | | Releases up to and | | | | including 12.2(2)BY3 are | | | | not vulnerable. | |------------+--------------------------+---------------------------| | 12.2BZ | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | 12.2CX | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | 12.2CY | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | | | Vulnerable; Contact your | | | | support organization per | | 12.2CZ | Not Vulnerable | the instructions in | | | | Obtaining Fixed Software | | | | section of this advisory | |------------+--------------------------+---------------------------| | 12.2DA | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | 12.2DD | Not Vulnerable | Vulnerable; first fixed | | | | in 12.4T | |------------+--------------------------+---------------------------| | 12.2DX | Not Vulnerable | Vulnerable; first fixed | | | | in 12.4T | |------------+--------------------------+---------------------------| | 12.2EW | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | 12.2EWA | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | 12.2EX | Vulnerable; migrate to | Not Vulnerable | | | any release in 12.2SE | | |------------+--------------------------+---------------------------| | 12.2EY | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | 12.2EZ | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | 12.2FX | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | 12.2FY | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | 12.2FZ | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | | Vulnerable; Contact your | Vulnerable; Contact your | | | support organization per | support organization per | | 12.2IRA | the instructions in | the instructions in | | | Obtaining Fixed Software | Obtaining Fixed Software | | | section of this advisory | section of this advisory | |------------+--------------------------+---------------------------| | | Vulnerable; Contact your | Vulnerable; Contact your | | | support organization per | support organization per | | 12.2IRB | the instructions in | the instructions in | | | Obtaining Fixed Software | Obtaining Fixed Software | | | section of this advisory | section of this advisory | |------------+--------------------------+---------------------------| | | Vulnerable; Contact your | Vulnerable; Contact your | | | support organization per | support organization per | | 12.2IRC | the instructions in | the instructions in | | | Obtaining Fixed Software | Obtaining Fixed Software | | | section of this advisory | section of this advisory | |------------+--------------------------+---------------------------| | | Vulnerable; Contact your | Vulnerable; Contact your | | | support organization per | support organization per | | 12.2IRD | the instructions in | the instructions in | | | Obtaining Fixed Software | Obtaining Fixed Software | | | section of this advisory | section of this advisory | |------------+--------------------------+---------------------------| | | Vulnerable; Contact your | Vulnerable; Contact your | | | support organization per | support organization per | | 12.2IRE | the instructions in | the instructions in | | | Obtaining Fixed Software | Obtaining Fixed Software | | | section of this advisory | section of this advisory | |------------+--------------------------+---------------------------| | | Vulnerable; Contact your | Vulnerable; Contact your | | | support organization per | support organization per | | 12.2IXA | the instructions in | the instructions in | | | Obtaining Fixed Software | Obtaining Fixed Software | | | section of this advisory | section of this advisory | |------------+--------------------------+---------------------------| | | Vulnerable; Contact your | Vulnerable; Contact your | | | support organization per | support organization per | | 12.2IXB | the instructions in | the instructions in | | | Obtaining Fixed Software | Obtaining Fixed Software | | | section of this advisory | section of this advisory | |------------+--------------------------+---------------------------| | | Vulnerable; Contact your | Vulnerable; Contact your | | | support organization per | support organization per | | 12.2IXC | the instructions in | the instructions in | | | Obtaining Fixed Software | Obtaining Fixed Software | | | section of this advisory | section of this advisory | |------------+--------------------------+---------------------------| | | Vulnerable; Contact your | Vulnerable; Contact your | | | support organization per | support organization per | | 12.2IXD | the instructions in | the instructions in | | | Obtaining Fixed Software | Obtaining Fixed Software | | | section of this advisory | section of this advisory | |------------+--------------------------+---------------------------| | | Vulnerable; Contact your | Vulnerable; Contact your | | | support organization per | support organization per | | 12.2IXE | the instructions in | the instructions in | | | Obtaining Fixed Software | Obtaining Fixed Software | | | section of this advisory | section of this advisory | |------------+--------------------------+---------------------------| | | Vulnerable; Contact your | Vulnerable; Contact your | | | support organization per | support organization per | | 12.2IXF | the instructions in | the instructions in | | | Obtaining Fixed Software | Obtaining Fixed Software | | | section of this advisory | section of this advisory | |------------+--------------------------+---------------------------| | | Vulnerable; Contact your | Vulnerable; Contact your | | | support organization per | support organization per | | 12.2IXG | the instructions in | the instructions in | | | Obtaining Fixed Software | Obtaining Fixed Software | | | section of this advisory | section of this advisory | |------------+--------------------------+---------------------------| | | Vulnerable; Contact your | Vulnerable; Contact your | | | support organization per | support organization per | | 12.2IXH | the instructions in | the instructions in | | | Obtaining Fixed Software | Obtaining Fixed Software | | | section of this advisory | section of this advisory | |------------+--------------------------+---------------------------| | 12.2JA | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | 12.2JK | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | 12.2MB | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | | | Releases up to and | | | | including 12.2(15)MC1 are | | 12.2MC | Not Vulnerable | not vulnerable. Releases | | | | 12.2(15)MC2b and later | | | | are not vulnerable; first | | | | fixed in 12.4T | |------------+--------------------------+---------------------------| | | Vulnerable; Contact your | Vulnerable; Contact your | | | support organization per | support organization per | | 12.2MRA | the instructions in | the instructions in | | | Obtaining Fixed Software | Obtaining Fixed Software | | | section of this advisory | section of this advisory | |------------+--------------------------+---------------------------| | 12.2MRB | 12.2(33)MRB2 | 12.2(33)MRB2 | |------------+--------------------------+---------------------------| | | Releases prior to 12.2 | Releases prior to 12.2 | | 12.2S | (30)S are vulnerable, | (30)S are vulnerable, | | | release 12.2(30)S and | release 12.2(30)S and | | | later are not vulnerable | later are not vulnerable | |------------+--------------------------+---------------------------| | | | 12.2(31)SB19; Releases | | | | prior to 12.2(33)SB5 are | | 12.2SB | Not Vulnerable | vulnerable, release 12.2 | | | | (33)SB5 and later are not | | | | vulnerable | |------------+--------------------------+---------------------------| | 12.2SBC | Vulnerable; first fixed | Vulnerable; first fixed | | | in 12.2SB | in 12.2SB | |------------+--------------------------+---------------------------| | 12.2SCA | Not Vulnerable | Vulnerable; first fixed | | | | in 12.2SCB | |------------+--------------------------+---------------------------| | | 12.2(33)SCB10 | | | 12.2SCB | | 12.2(33)SCB9 | | | 12.2(33)SCB9 | | |------------+--------------------------+---------------------------| | 12.2SCC | 12.2(33)SCC5 | 12.2(33)SCC5 | |------------+--------------------------+---------------------------| | | 12.2(33)SCD3 | | | 12.2SCD | | 12.2(33)SCD3 | | | 12.2(33)SCD4 | | |------------+--------------------------+---------------------------| | 12.2SE | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | 12.2SEA | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | 12.2SEB | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | 12.2SEC | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | 12.2SED | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | 12.2SEE | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | 12.2SEF | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | 12.2SEG | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | | Releases prior to 12.2 | Releases prior to 12.2 | | | (40)SG are vulnerable, | (40)SG are vulnerable, | | 12.2SG | release 12.2(40)SG and | release 12.2(40)SG and | | | later are not | later are not vulnerable; | | | vulnerable; migrate to | migrate to any release in | | | any release in 12.2SGA | 12.2SGA | |------------+--------------------------+---------------------------| | 12.2SGA | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | 12.2SL | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | 12.2SM | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | 12.2SO | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | 12.2SQ | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | | | Releases prior to 12.2 | | 12.2SRA | Not Vulnerable | (33)SRA6 are vulnerable, | | | | release 12.2(33)SRA6 and | | | | later are not vulnerable | |------------+--------------------------+---------------------------| | | | Releases prior to 12.2 | | 12.2SRB | Not Vulnerable | (33)SRB1 are vulnerable, | | | | release 12.2(33)SRB1 and | | | | later are not vulnerable | |------------+--------------------------+---------------------------| | 12.2SRC | Not Vulnerable | Not vulnerable | |------------+--------------------------+---------------------------| | 12.2SRD | Not Vulnerable | Not vulnerable | |------------+--------------------------+---------------------------| | 12.2SRE | 12.2(33)SRE1 | 12.2(33)SRE1 | |------------+--------------------------+---------------------------| | 12.2STE | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | 12.2SU | Not Vulnerable | Vulnerable; first fixed | | | | in 12.4T | |------------+--------------------------+---------------------------| | | Releases prior to 12.2 | Releases prior to 12.2 | | | (29b)SV1 are vulnerable, | (29b)SV1 are vulnerable, | | 12.2SV | release 12.2(29b)SV1 and | release 12.2(29b)SV1 and | | | later are not | later are not vulnerable; | | | vulnerable; migrate to | migrate to any release in | | | any release in 12.2SVD | 12.2SVD | |------------+--------------------------+---------------------------| | 12.2SVA | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | 12.2SVC | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | 12.2SVD | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | 12.2SVE | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | | Releases up to and | | | | including 12.2(25)SW3 | Releases up to and | | | are not vulnerable. | including 12.2(21)SW1 are | | 12.2SW | | not vulnerable. Releases | | | Releases 12.2(25)SW12 | 12.2(25)SW12 and later | | | and later are not | are not vulnerable; first | | | vulnerable; first fixed | fixed in 12.4T | | | in 12.4T | | |------------+--------------------------+---------------------------| | | Releases up to and | Releases up to and | | 12.2SX | including 12.2(14)SX2 | including 12.2(14)SX2 are | | | are not vulnerable. | not vulnerable. | |------------+--------------------------+---------------------------| | | Vulnerable; Contact your | Vulnerable; Contact your | | | support organization per | support organization per | | 12.2SXA | the instructions in | the instructions in | | | Obtaining Fixed Software | Obtaining Fixed Software | | | section of this advisory | section of this advisory | |------------+--------------------------+---------------------------| | | Vulnerable; Contact your | Vulnerable; Contact your | | | support organization per | support organization per | | 12.2SXB | the instructions in | the instructions in | | | Obtaining Fixed Software | Obtaining Fixed Software | | | section of this advisory | section of this advisory | |------------+--------------------------+---------------------------| | | Vulnerable; Contact your | Vulnerable; Contact your | | | support organization per | support organization per | | 12.2SXD | the instructions in | the instructions in | | | Obtaining Fixed Software | Obtaining Fixed Software | | | section of this advisory | section of this advisory | |------------+--------------------------+---------------------------| | | Vulnerable; Contact your | Vulnerable; Contact your | | | support organization per | support organization per | | 12.2SXE | the instructions in | the instructions in | | | Obtaining Fixed Software | Obtaining Fixed Software | | | section of this advisory | section of this advisory | |------------+--------------------------+---------------------------| | | Releases prior to 12.2 | Releases prior to 12.2 | | | (18)SXF11 are | (18)SXF11 are vulnerable, | | 12.2SXF | vulnerable, releases | releases 12.2(18)SXF11 | | | 12.2(18)SXF11 and later | and later are not | | | are not vulnerable | vulnerable | |------------+--------------------------+---------------------------| | 12.2SXH | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | 12.2SXI | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | | Vulnerable; Contact your | | | | support organization per | | | 12.2SY | the instructions in | Not Vulnerable | | | Obtaining Fixed Software | | | | section of this advisory | | |------------+--------------------------+---------------------------| | | | Vulnerable; Contact your | | | | support organization per | | 12.2SZ | Not Vulnerable | the instructions in | | | | Obtaining Fixed Software | | | | section of this advisory | |------------+--------------------------+---------------------------| | 12.2T | Not Vulnerable | Vulnerable; first fixed | | | | in 12.4T | |------------+--------------------------+---------------------------| | | | Vulnerable; Contact your | | | | support organization per | | 12.2TPC | Not Vulnerable | the instructions in | | | | Obtaining Fixed Software | | | | section of this advisory | |------------+--------------------------+---------------------------| | 12.2XA | Not Vulnerable | Vulnerable; first fixed | | | | in 12.4T | |------------+--------------------------+---------------------------| | 12.2XB | Not Vulnerable | Vulnerable; first fixed | | | | in 12.4T | |------------+--------------------------+---------------------------| | 12.2XC | Not Vulnerable | Vulnerable; first fixed | | | | in 12.4T | |------------+--------------------------+---------------------------| | 12.2XD | Not Vulnerable | Vulnerable; first fixed | | | | in 12.4T | |------------+--------------------------+---------------------------| | 12.2XE | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | 12.2XF | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | 12.2XG | Not Vulnerable | Vulnerable; first fixed | | | | in 12.4T | |------------+--------------------------+---------------------------| | 12.2XH | Not Vulnerable | Vulnerable; first fixed | | | | in 12.4T | |------------+--------------------------+---------------------------| | 12.2XI | Not Vulnerable | Vulnerable; first fixed | | | | in 12.4T | |------------+--------------------------+---------------------------| | 12.2XJ | Not Vulnerable | Vulnerable; first fixed | | | | in 12.4T | |------------+--------------------------+---------------------------| | 12.2XK | Not Vulnerable | Vulnerable; first fixed | | | | in 12.4T | |------------+--------------------------+---------------------------| | 12.2XL | Not Vulnerable | Vulnerable; first fixed | | | | in 12.4T | |------------+--------------------------+---------------------------| | 12.2XM | Not Vulnerable | Vulnerable; first fixed | | | | in 12.4T | |------------+--------------------------+---------------------------| | 12.2XN | Vulnerable; first fixed | Vulnerable; first fixed | | | in 12.2SB | in 12.2SB | |------------+--------------------------+---------------------------| | 12.2XNA | Please see Cisco IOS-XE | Please see Cisco IOS-XE | | | Software Availability | Software Availability | |------------+--------------------------+---------------------------| | 12.2XNB | Please see Cisco IOS-XE | Please see Cisco IOS-XE | | | Software Availability | Software Availability | |------------+--------------------------+---------------------------| | 12.2XNC | Please see Cisco IOS-XE | Please see Cisco IOS-XE | | | Software Availability | Software Availability | |------------+--------------------------+---------------------------| | 12.2XND | Please see Cisco IOS-XE | Please see Cisco IOS-XE | | | Software Availability | Software Availability | |------------+--------------------------+---------------------------| | 12.2XNE | Please see Cisco IOS-XE | Please see Cisco IOS-XE | | | Software Availability | Software Availability | |------------+--------------------------+---------------------------| | 12.2XNF | Please see Cisco IOS-XE | Please see Cisco IOS-XE | | | Software Availability | Software Availability | |------------+--------------------------+---------------------------| | 12.2XO | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | 12.2XQ | Not Vulnerable | Vulnerable; first fixed | | | | in 12.4T | |------------+--------------------------+---------------------------| | 12.2XR | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | 12.2XS | Not Vulnerable | Vulnerable; first fixed | | | | in 12.4T | |------------+--------------------------+---------------------------| | 12.2XT | Not Vulnerable | Vulnerable; first fixed | | | | in 12.4T | |------------+--------------------------+---------------------------| | 12.2XU | Not Vulnerable | Vulnerable; first fixed | | | | in 12.4T | |------------+--------------------------+---------------------------| | 12.2XV | Not Vulnerable | Vulnerable; first fixed | | | | in 12.4T | |------------+--------------------------+---------------------------| | 12.2XW | Not Vulnerable | Vulnerable; first fixed | | | | in 12.4T | |------------+--------------------------+---------------------------| | 12.2YA | Not Vulnerable | Vulnerable; first fixed | | | | in 12.4T | |------------+--------------------------+---------------------------| | | | Vulnerable; Contact your | | | | support organization per | | 12.2YB | Not Vulnerable | the instructions in | | | | Obtaining Fixed Software | | | | section of this advisory | |------------+--------------------------+---------------------------| | | | Vulnerable; Contact your | | | | support organization per | | 12.2YC | Not Vulnerable | the instructions in | | | | Obtaining Fixed Software | | | | section of this advisory | |------------+--------------------------+---------------------------| | | | Vulnerable; Contact your | | | | support organization per | | 12.2YD | Not Vulnerable | the instructions in | | | | Obtaining Fixed Software | | | | section of this advisory | |------------+--------------------------+---------------------------| | | | Vulnerable; Contact your | | | | support organization per | | 12.2YE | Not Vulnerable | the instructions in | | | | Obtaining Fixed Software | | | | section of this advisory | |------------+--------------------------+---------------------------| | | | Vulnerable; Contact your | | | | support organization per | | 12.2YF | Not Vulnerable | the instructions in | | | | Obtaining Fixed Software | | | | section of this advisory | |------------+--------------------------+---------------------------| | 12.2YG | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | | | Vulnerable; Contact your | | | | support organization per | | 12.2YH | Not Vulnerable | the instructions in | | | | Obtaining Fixed Software | | | | section of this advisory | |------------+--------------------------+---------------------------| | | | Vulnerable; Contact your | | | | support organization per | | 12.2YJ | Not Vulnerable | the instructions in | | | | Obtaining Fixed Software | | | | section of this advisory | |------------+--------------------------+---------------------------| | | | Vulnerable; Contact your | | | | support organization per | | 12.2YK | Not Vulnerable | the instructions in | | | | Obtaining Fixed Software | | | | section of this advisory | |------------+--------------------------+---------------------------| | | | Vulnerable; Contact your | | | | support organization per | | 12.2YL | Not Vulnerable | the instructions in | | | | Obtaining Fixed Software | | | | section of this advisory | |------------+--------------------------+---------------------------| | 12.2YM | Not Vulnerable | Vulnerable; first fixed | | | | in 12.4T | |------------+--------------------------+---------------------------| | | | Vulnerable; Contact your | | | | support organization per | | 12.2YN | Not Vulnerable | the instructions in | | | | Obtaining Fixed Software | | | | section of this advisory | |------------+--------------------------+---------------------------| | 12.2YO | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | 12.2YP | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | 12.2YQ | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | 12.2YR | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | 12.2YS | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | | | Vulnerable; Contact your | | | | support organization per | | 12.2YT | Not Vulnerable | the instructions in | | | | Obtaining Fixed Software | | | | section of this advisory | |------------+--------------------------+---------------------------| | | | Vulnerable; Contact your | | | | support organization per | | 12.2YU | Not Vulnerable | the instructions in | | | | Obtaining Fixed Software | | | | section of this advisory | |------------+--------------------------+---------------------------| | | | Releases prior to 12.2 | | 12.2YV | Not Vulnerable | (11)YV1 are vulnerable, | | | | release 12.2(11)YV1 and | | | | later are not vulnerable | |------------+--------------------------+---------------------------| | | | Vulnerable; Contact your | | | | support organization per | | 12.2YW | Not Vulnerable | the instructions in | | | | Obtaining Fixed Software | | | | section of this advisory | |------------+--------------------------+---------------------------| | | | Vulnerable; Contact your | | | | support organization per | | 12.2YX | Not Vulnerable | the instructions in | | | | Obtaining Fixed Software | | | | section of this advisory | |------------+--------------------------+---------------------------| | | | Vulnerable; Contact your | | | | support organization per | | 12.2YY | Not Vulnerable | the instructions in | | | | Obtaining Fixed Software | | | | section of this advisory | |------------+--------------------------+---------------------------| | | | Vulnerable; Contact your | | | | support organization per | | 12.2YZ | Not Vulnerable | the instructions in | | | | Obtaining Fixed Software | | | | section of this advisory | |------------+--------------------------+---------------------------| | 12.2ZA | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | | | Releases up to and | | 12.2ZB | Not Vulnerable | including 12.2(8)ZB are | | | | not vulnerable. | |------------+--------------------------+---------------------------| | | | Vulnerable; Contact your | | | | support organization per | | 12.2ZC | Not Vulnerable | the instructions in | | | | Obtaining Fixed Software | | | | section of this advisory | |------------+--------------------------+---------------------------| | | | Vulnerable; Contact your | | | | support organization per | | 12.2ZD | Not Vulnerable | the instructions in | | | | Obtaining Fixed Software | | | | section of this advisory | |------------+--------------------------+---------------------------| | 12.2ZE | Not Vulnerable | Vulnerable; first fixed | | | | in 12.4T | |------------+--------------------------+---------------------------| | 12.2ZF | Not Vulnerable | Vulnerable; first fixed | | | | in 12.4T | |------------+--------------------------+---------------------------| | 12.2ZG | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | 12.2ZH | Not Vulnerable | Vulnerable; first fixed | | | | in 12.4T | |------------+--------------------------+---------------------------| | | | Vulnerable; Contact your | | | | support organization per | | 12.2ZJ | Not Vulnerable | the instructions in | | | | Obtaining Fixed Software | | | | section of this advisory | |------------+--------------------------+---------------------------| | | Vulnerable; Contact your | Vulnerable; Contact your | | | support organization per | support organization per | | 12.2ZL | the instructions in | the instructions in | | | Obtaining Fixed Software | Obtaining Fixed Software | | | section of this advisory | section of this advisory | |------------+--------------------------+---------------------------| | | | Vulnerable; Contact your | | | | support organization per | | 12.2ZP | Not Vulnerable | the instructions in | | | | Obtaining Fixed Software | | | | section of this advisory | |------------+--------------------------+---------------------------| | | Vulnerable; Contact your | Vulnerable; Contact your | | | support organization per | support organization per | | 12.2ZU | the instructions in | the instructions in | | | Obtaining Fixed Software | Obtaining Fixed Software | | | section of this advisory | section of this advisory | |------------+--------------------------+---------------------------| | 12.2ZX | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | | Vulnerable; Contact your | Vulnerable; Contact your | | | support organization per | support organization per | | 12.2ZY | the instructions in | the instructions in | | | Obtaining Fixed Software | Obtaining Fixed Software | | | section of this advisory | section of this advisory | |------------+--------------------------+---------------------------| | | Vulnerable; Contact your | Vulnerable; Contact your | | | support organization per | support organization per | | 12.2ZYA | the instructions in | the instructions in | | | Obtaining Fixed Software | Obtaining Fixed Software | | | section of this advisory | section of this advisory | |------------+--------------------------+---------------------------| | Affected | | First Fixed Release for | | 12.3-Based | First Fixed Release for | All Advisories in the | | Releases | This Advisory | September 2010 Bundle | | | | Publication | |------------+--------------------------+---------------------------| | 12.3 | Not Vulnerable | Vulnerable; first fixed | | | | in 12.4T | |------------+--------------------------+---------------------------| | 12.3B | Not Vulnerable | Vulnerable; first fixed | | | | in 12.4T | |------------+--------------------------+---------------------------| | 12.3BC | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | 12.3BW | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | 12.3EU | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | 12.3JA | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | 12.3JEA | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | 12.3JEB | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | 12.3JEC | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | 12.3JED | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | | Releases up to and | | | | including 12.3(2)JK3 are | Releases up to and | | | not vulnerable. | including 12.3(2)JK3 are | | 12.3JK | | not vulnerable. Releases | | | Releases 12.3(8)JK1 and | 12.3(8)JK1 and later are | | | later are not | not vulnerable; first | | | vulnerable; first fixed | fixed in 12.4T | | | in 12.4T | | |------------+--------------------------+---------------------------| | 12.3JL | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | 12.3JX | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | 12.3T | Vulnerable; first fixed | Vulnerable; first fixed | | | in 12.4 | in 12.4T | |------------+--------------------------+---------------------------| | | Vulnerable; Contact your | Vulnerable; Contact your | | | support organization per | support organization per | | 12.3TPC | the instructions in | the instructions in | | | Obtaining Fixed Software | Obtaining Fixed Software | | | section of this advisory | section of this advisory | |------------+--------------------------+---------------------------| | 12.3VA | Vulnerable; first fixed | Vulnerable; first fixed | | | in 12.4T | in 12.4T | |------------+--------------------------+---------------------------| | 12.3XA | Vulnerable; first fixed | Vulnerable; first fixed | | | in 12.4T | in 12.4T | |------------+--------------------------+---------------------------| | | | Vulnerable; Contact your | | | | support organization per | | 12.3XB | Not Vulnerable | the instructions in | | | | Obtaining Fixed Software | | | | section of this advisory | |------------+--------------------------+---------------------------| | 12.3XC | Vulnerable; first fixed | Vulnerable; first fixed | | | in 12.4T | in 12.4T | |------------+--------------------------+---------------------------| | 12.3XD | Vulnerable; first fixed | Vulnerable; first fixed | | | in 12.4T | in 12.4T | |------------+--------------------------+---------------------------| | 12.3XE | Vulnerable; first fixed | Vulnerable; first fixed | | | in 12.4T | in 12.4T | |------------+--------------------------+---------------------------| | | Vulnerable; Contact your | Vulnerable; Contact your | | | support organization per | support organization per | | 12.3XF | the instructions in | the instructions in | | | Obtaining Fixed Software | Obtaining Fixed Software | | | section of this advisory | section of this advisory | |------------+--------------------------+---------------------------| | 12.3XG | Vulnerable; first fixed | Vulnerable; first fixed | | | in 12.4T | in 12.4T | |------------+--------------------------+---------------------------| | | Releases prior to 12.3 | Releases prior to 12.3(7) | | | (7)XI11 are vulnerable, | XI11 are vulnerable, | | 12.3XI | release 12.3(7)XI11 and | releases 12.3(7)XI11 and | | | later are not | later are not vulnerable; | | | vulnerable; first fixed | first fixed in 12.2SB | | | in 12.2SB | | |------------+--------------------------+---------------------------| | 12.3XJ | Vulnerable; first fixed | Vulnerable; first fixed | | | in 12.3YX | in 12.4XR | |------------+--------------------------+---------------------------| | 12.3XK | Vulnerable; first fixed | Vulnerable; first fixed | | | in 12.4T | in 12.4T | |------------+--------------------------+---------------------------| | 12.3XL | Vulnerable; first fixed | Vulnerable; first fixed | | | in 12.4T | in 12.4T | |------------+--------------------------+---------------------------| | 12.3XQ | Vulnerable; first fixed | Vulnerable; first fixed | | | in 12.4T | in 12.4T | |------------+--------------------------+---------------------------| | 12.3XR | Vulnerable; first fixed | Vulnerable; first fixed | | | in 12.4T | in 12.4T | |------------+--------------------------+---------------------------| | 12.3XS | Vulnerable; first fixed | Vulnerable; first fixed | | | in 12.4T | in 12.4T | |------------+--------------------------+---------------------------| | 12.3XU | Vulnerable; first fixed | Vulnerable; first fixed | | | in 12.4T | in 12.4T | |------------+--------------------------+---------------------------| | 12.3XW | Vulnerable; first fixed | Vulnerable; first fixed | | | in 12.4T | in 12.4T | |------------+--------------------------+---------------------------| | 12.3XX | Vulnerable; first fixed | Vulnerable; first fixed | | | in 12.4T | in 12.4T | |------------+--------------------------+---------------------------| | 12.3XY | Not Vulnerable | Vulnerable; first fixed | | | | in 12.4T | |------------+--------------------------+---------------------------| | 12.3XZ | Vulnerable; first fixed | Vulnerable; first fixed | | | in 12.4T | in 12.4T | |------------+--------------------------+---------------------------| | 12.3YA | Vulnerable; first fixed | Vulnerable; first fixed | | | in 12.4T | in 12.4T | |------------+--------------------------+---------------------------| | 12.3YD | Vulnerable; first fixed | Vulnerable; first fixed | | | in 12.4T | in 12.4T | |------------+--------------------------+---------------------------| | 12.3YF | Vulnerable; first fixed | Vulnerable; first fixed | | | in 12.3YX | in 12.4XR | |------------+--------------------------+---------------------------| | 12.3YG | Vulnerable; first fixed | Vulnerable; first fixed | | | in 12.4T | in 12.4T | |------------+--------------------------+---------------------------| | 12.3YH | Vulnerable; first fixed | Vulnerable; first fixed | | | in 12.4T | in 12.4T | |------------+--------------------------+---------------------------| | 12.3YI | Vulnerable; first fixed | Vulnerable; first fixed | | | in 12.4T | in 12.4T | |------------+--------------------------+---------------------------| | 12.3YJ | Vulnerable; first fixed | Vulnerable; first fixed | | | in 12.4T | in 12.4T | |------------+--------------------------+---------------------------| | 12.3YK | Vulnerable; first fixed | Vulnerable; first fixed | | | in 12.4T | in 12.4T | |------------+--------------------------+---------------------------| | 12.3YM | Vulnerable; first fixed | Vulnerable; first fixed | | | in 12.4T | in 12.4T | |------------+--------------------------+---------------------------| | 12.3YQ | Vulnerable; first fixed | Vulnerable; first fixed | | | in 12.4T | in 12.4T | |------------+--------------------------+---------------------------| | 12.3YS | Vulnerable; first fixed | Vulnerable; first fixed | | | in 12.4T | in 12.4T | |------------+--------------------------+---------------------------| | 12.3YT | Vulnerable; first fixed | Vulnerable; first fixed | | | in 12.4T | in 12.4T | |------------+--------------------------+---------------------------| | 12.3YU | Vulnerable; first fixed | Vulnerable; first fixed | | | in 12.4T | in 12.4T | |------------+--------------------------+---------------------------| | 12.3YX | 12.3(14)YX17 | Vulnerable; first fixed | | | | in 12.4XR | |------------+--------------------------+---------------------------| | | Vulnerable; Contact your | Vulnerable; Contact your | | | support organization per | support organization per | | 12.3YZ | the instructions in | the instructions in | | | Obtaining Fixed Software | Obtaining Fixed Software | | | section of this advisory | section of this advisory | |------------+--------------------------+---------------------------| | 12.3ZA | Vulnerable; first fixed | Vulnerable; first fixed | | | in 12.4T | in 12.4T | |------------+--------------------------+---------------------------| | Affected | | First Fixed Release for | | 12.4-Based | First Fixed Release for | All Advisories in the | | Releases | This Advisory | September 2010 Bundle | | | | Publication | |------------+--------------------------+---------------------------| | 12.4 | 12.4(25d) | 12.4(25d) | |------------+--------------------------+---------------------------| | 12.4GC | 12.4(24)GC2 | 12.4(24)GC2 | |------------+--------------------------+---------------------------| | 12.4JA | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | 12.4JDA | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | 12.4JDC | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | 12.4JDD | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | 12.4JHA | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | 12.4JHB | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | 12.4JK | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | 12.4JL | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | 12.4JMA | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | 12.4JMB | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | 12.4JX | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | 12.4JY | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | 12.4MD | 12.4(22)MD2 | 12.4(24)MD2 | |------------+--------------------------+---------------------------| | 12.4MDA | 12.4(22)MDA4 | 12.4(22)MDA4 | |------------+--------------------------+---------------------------| | 12.4MR | Vulnerable; first fixed | Vulnerable; first fixed | | | in 12.4MRA | in 12.4MRA | |------------+--------------------------+---------------------------| | 12.4MRA | 12.4(20)MRA1 | 12.4(20)MRA1 | |------------+--------------------------+---------------------------| | | Releases prior to 12.4 | | | | (15)SW6 are vulnerable, | | | 12.4SW | release 12.4(15)SW6 and | Vulnerable; first fixed | | | later are not | in 12.4T | | | vulnerable; first fixed | | | | in 12.4T | | |------------+--------------------------+---------------------------| | | 12.4(15)T14 | 12.4(15)T14 | | | | | | 12.4T | 12.4(20)T6 | 12.4(20)T6 | | | | | | | 12.4(24)T4 | 12.4(24)T4 | |------------+--------------------------+---------------------------| | 12.4XA | Vulnerable; first fixed | Vulnerable; first fixed | | | in 12.4T | in 12.4T | |------------+--------------------------+---------------------------| | 12.4XB | Vulnerable; first fixed | Vulnerable; first fixed | | | in 12.4T | in 12.4T | |------------+--------------------------+---------------------------| | 12.4XC | Vulnerable; first fixed | Vulnerable; first fixed | | | in 12.4T | in 12.4T | |------------+--------------------------+---------------------------| | 12.4XD | Vulnerable; first fixed | Vulnerable; first fixed | | | in 12.4T | in 12.4T | |------------+--------------------------+---------------------------| | | Releases prior to 12.4 | Releases prior to 12.4(6) | | | (6)XE5 are vulnerable, | XE5 are vulnerable, | | 12.4XE | release 12.4(6)XE5 and | release 12.4(6)XE5 and | | | later are not | later are not vulnerable; | | | vulnerable; first fixed | first fixed in 12.4T | | | in 12.4T | | |------------+--------------------------+---------------------------| | 12.4XF | Vulnerable; first fixed | Vulnerable; first fixed | | | in 12.4T | in 12.4T | |------------+--------------------------+---------------------------| | 12.4XG | Vulnerable; first fixed | Vulnerable; first fixed | | | in 12.4T | in 12.4T | |------------+--------------------------+---------------------------| | 12.4XJ | Vulnerable; first fixed | Vulnerable; first fixed | | | in 12.4T | in 12.4T | |------------+--------------------------+---------------------------| | 12.4XK | Vulnerable; first fixed | Vulnerable; first fixed | | | in 12.4T | in 12.4T | |------------+--------------------------+---------------------------| | | Vulnerable; Contact your | Vulnerable; Contact your | | | support organization per | support organization per | | 12.4XL | the instructions in | the instructions in | | | Obtaining Fixed Software | Obtaining Fixed Software | | | section of this advisory | section of this advisory | |------------+--------------------------+---------------------------| | 12.4XM | Vulnerable; first fixed | Vulnerable; first fixed | | | in 12.4T | in 12.4T | |------------+--------------------------+---------------------------| | | Vulnerable; Contact your | Vulnerable; Contact your | | | support organization per | support organization per | | 12.4XN | the instructions in | the instructions in | | | Obtaining Fixed Software | Obtaining Fixed Software | | | section of this advisory | section of this advisory | |------------+--------------------------+---------------------------| | | Vulnerable; Contact your | Vulnerable; Contact your | | | support organization per | support organization per | | 12.4XP | the instructions in | the instructions in | | | Obtaining Fixed Software | Obtaining Fixed Software | | | section of this advisory | section of this advisory | |------------+--------------------------+---------------------------| | 12.4XQ | 12.4(15)XQ6; Available | 12.4(15)XQ6; Available on | | | on 22-SEP-10 | 22-SEP-10 | |------------+--------------------------+---------------------------| | | 12.4(15)XR9 | 12.4(15)XR9 | | 12.4XR | | | | | 12.4(22)XR7 | 12.4(22)XR7 | |------------+--------------------------+---------------------------| | 12.4XT | Vulnerable; first fixed | Vulnerable; first fixed | | | in 12.4T | in 12.4T | |------------+--------------------------+---------------------------| | | Vulnerable; Contact your | Vulnerable; Contact your | | | support organization per | support organization per | | 12.4XV | the instructions in | the instructions in | | | Obtaining Fixed Software | Obtaining Fixed Software | | | section of this advisory | section of this advisory | |------------+--------------------------+---------------------------| | 12.4XW | Vulnerable; first fixed | Vulnerable; first fixed | | | in 12.4T | in 12.4T | |------------+--------------------------+---------------------------| | 12.4XY | Vulnerable; first fixed | Vulnerable; first fixed | | | in 12.4T | in 12.4T | |------------+--------------------------+---------------------------| | 12.4XZ | Vulnerable; first fixed | Vulnerable; first fixed | | | in 12.4T | in 12.4T | |------------+--------------------------+---------------------------| | 12.4YA | Vulnerable; first fixed | Vulnerable; first fixed | | | in 12.4T | in 12.4T | |------------+--------------------------+---------------------------| | | Vulnerable; Contact your | Vulnerable; Contact your | | | support organization per | support organization per | | 12.4YB | the instructions in | the instructions in | | | Obtaining Fixed Software | Obtaining Fixed Software | | | section of this advisory | section of this advisory | |------------+--------------------------+---------------------------| | | Vulnerable; Contact your | Vulnerable; Contact your | | | support organization per | support organization per | | 12.4YD | the instructions in | the instructions in | | | Obtaining Fixed Software | Obtaining Fixed Software | | | section of this advisory | section of this advisory | |------------+--------------------------+---------------------------| | 12.4YE | Vulnerable; first fixed | 12.4(24)YE1 | | | in 12.4T | | |------------+--------------------------+---------------------------| | 12.4YG | 12.4(24)YG3 | 12.4(24)YG3 | |------------+--------------------------+---------------------------| | Affected | | First Fixed Release for | | 15.0-Based | First Fixed Release for | All Advisories in the | | Releases | This Advisory | September 2010 Bundle | | | | Publication | |------------+--------------------------+---------------------------| | 15.0M | 15.0(1)M3 | 15.0(1)M3 | |------------+--------------------------+---------------------------| | | Cisco 7600 and 10000 | Cisco 7600 and 10000 | | | Series routers: 15.0(1) | Series routers: 15.0(1)S1 | | | S1 | | | 15.0S | | Cisco ASR 1000 Series | | | Cisco ASR 1000 Series | routers: Please see Cisco | | | routers: Please see | IOS-XE Software | | | Cisco IOS-XE Software | Availability | | | Availability | | |------------+--------------------------+---------------------------| | 15.0XA | Vulnerable; first fixed | Vulnerable; first fixed | | | in 15.1T | in 15.1T | |------------+--------------------------+---------------------------| | 15.0XO | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | Affected | | First Fixed Release for | | 15.1-Based | First Fixed Release for | All Advisories in the | | Releases | This Advisory | September 2010 Bundle | | | | Publication | |------------+--------------------------+---------------------------| | 15.1T | 15.1(1)T1 | 15.1(2)T1 | |------------+--------------------------+---------------------------| | 15.1XB | 15.1(1)XB2 | Vulnerable; first fixed | | | | in 15.1T | +-------------------------------------------------------------------+ Cisco IOS XE Software +-------------------- +-------------------------------------------------------------------+ | Cisco IOS | First Fixed | First Fixed Release for All | | XE | Release for This | Advisories in the September 2010 | | Release | Advisory | Bundle Publication | |-----------+------------------+------------------------------------| | 2.1.x | Not Vulnerable | Not Vulnerable | |-----------+------------------+------------------------------------| | 2.2.x | Not Vulnerable | Not Vulnerable | |-----------+------------------+------------------------------------| | 2.3.x | Not Vulnerable | Not Vulnerable | |-----------+------------------+------------------------------------| | 2.4.x | Not Vulnerable | Not Vulnerable | |-----------+------------------+------------------------------------| | 2.5.x | Not Vulnerable | Vulnerable; migrate to 2.6.2 or | | | | later | |-----------+------------------+------------------------------------| | 2.6.x | Not Vulnerable | 2.6.2 | |-----------+------------------+------------------------------------| | 3.1.xS | Not Vulnerable | Not Vulnerable | +-------------------------------------------------------------------+ For mapping of Cisco IOS XE Software releases to Cisco IOS Software releases, refer to the Cisco IOS XE 2 and Cisco IOS XE 3S Release Notes. Cisco IOS XR Software Table +-------------------------- Cisco IOS XR Software is not affected by the vulnerabilities disclosed in the September 22, 2010, Cisco IOS Software Security Advisory bundle publication. Workarounds =========== The mitigations for the NAT vulnerabilities disable the respective Application Layer Gateway NAT processing. That is, packets will continue to be translated at the network and transport layers, but the embedded IP addresses will not be translated. NAT for Session Initiation Protocol DoS Vulnerability +---------------------------------------------------- Mitigation for this vulnerability consists of disabling NAT for SIP over the UDP transport by using the no ip nat service udp port 5060 global configuration command. NAT for H.323 DoS Vulnerability +------------------------------ Mitigation for this vulnerability consists of disabling NAT for H.323 and H.225.0 using the no ip nat service h225 global configuration command. NAT for H.225.0 DoS vulnerability +-------------------------------- Mitigation for this vulnerability consists of disabling NAT for H.323 and H.225.0 using the no ip nat service h225 global configuration command. Obtaining Fixed Software ======================== Cisco has released free software updates that address these vulnerabilities. Prior to deploying software, customers should consult their maintenance provider or check the software for feature set compatibility and known issues specific to their environment. Customers may only install and expect support for the feature sets they have purchased. By installing, downloading, accessing or otherwise using such software upgrades, customers agree to be bound by the terms of Cisco's software license terms found at http://www.cisco.com/en/US/docs/general/warranty/English/EU1KEN_.html or as otherwise set forth at Cisco.com Downloads at http://www.cisco.com/public/sw-center/sw-usingswc.shtml Do not contact psirt at cisco.com or security-alert at cisco.com for software upgrades. Customers with Service Contracts +------------------------------- Customers with contracts should obtain upgraded software through their regular update channels. For most customers, this means that upgrades should be obtained through the Software Center on Cisco's worldwide website at http://www.cisco.com Customers using Third Party Support Organizations +------------------------------------------------ Customers whose Cisco products are provided or maintained through prior or existing agreements with third-party support organizations, such as Cisco Partners, authorized resellers, or service providers should contact that support organization for guidance and assistance with the appropriate course of action in regards to this advisory. The effectiveness of any workaround or fix is dependent on specific customer situations, such as product mix, network topology, traffic behavior, and organizational mission. Due to the variety of affected products and releases, customers should consult with their service provider or support organization to ensure any applied workaround or fix is the most appropriate for use in the intended network before it is deployed. Customers without Service Contracts +---------------------------------- Customers who purchase direct from Cisco but do not hold a Cisco service contract, and customers who purchase through third-party vendors but are unsuccessful in obtaining fixed software through their point of sale should acquire upgrades by contacting the Cisco Technical Assistance Center (TAC). TAC contacts are as follows. * +1 800 553 2447 (toll free from within North America) * +1 408 526 7209 (toll call from anywhere in the world) * e-mail: tac at cisco.com Customers should have their product serial number available and be prepared to give the URL of this notice as evidence of entitlement to a free upgrade. Free upgrades for non-contract customers must be requested through the TAC. Refer to http://www.cisco.com/en/US/support/tsd_cisco_worldwide_contacts.html for additional TAC contact information, including localized telephone numbers, and instructions and e-mail addresses for use in various languages. Exploitation and Public Announcements ===================================== The Cisco PSIRT is not aware of any public announcements or malicious use of the vulnerabilities described in this advisory. The NAT for SIP DoS vulnerability was found during internal testing. The NAT for H.323 DoS and the NAT for H.225.0 DoS vulnerabilities were found during the resolution of customer service requests. 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-20100922-nat.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 | 2010-Sep-22 | 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.10 (Darwin) iEYEARECAAYFAkyZ/SkACgkQ86n/Gc8U/uAspwCcD7e0kd3Am/wQynOLnZ1j8RiE SE8AnA447FqSKGuXC9tKS4PFdZpsRb8f =fe0l -----END PGP SIGNATURE----- From psirt at cisco.com Wed Sep 22 16:00:00 2010 From: psirt at cisco.com (Cisco Systems Product Security Incident Response Team) Date: Wed, 22 Sep 2010 18:00:00 +0200 Subject: Cisco Security Advisory: Cisco IOS SSL VPN Vulnerability Message-ID: <201009221801.sslvpn@psirt.cisco.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Cisco IOS SSL VPN Vulnerability Advisory ID: cisco-sa-20100922-sslvpn http://www.cisco.com/warp/public/707/cisco-sa-20100922-sslvpn.shtml Revision 1.0 For Public Release 2010 September 22 1600 UTC (GMT) - --------------------------------------------------------------------- Summary ======= Cisco IOS Software contains a vulnerability when the Cisco IOS SSL VPN feature is configured with an HTTP redirect. Exploitation could allow a remote, unauthenticated user to cause a memory leak on the affected devices, that could result in a memory exhaustion condition that may cause device reloads, the inability to service new TCP connections, and other denial of service (DoS) conditions. Cisco has released free software updates that address this vulnerability. There is a workaround to mitigate this vulnerability. This advisory is posted at http://www.cisco.com/warp/public/707/cisco-sa-20100922-sslvpn.shtml Note: The September 22, 2010, Cisco IOS Software Security Advisory bundled publication includes six Cisco Security Advisories. Five of the advisories address vulnerabilities in Cisco IOS Software, and one advisory addresses vulnerabilities in Cisco Unified Communications Manager. Each advisory lists the releases that correct the vulnerability or vulnerabilities detailed in the advisory. The table at the following URL lists releases that correct all Cisco IOS Software vulnerabilities that have been published on September 22, 2010, or earlier: http://www.cisco.com/warp/public/707/cisco-sa-20100922-bundle.shtml Individual publication links are in "Cisco Event Response: Semiannual Cisco IOS Software Security Advisory Bundled Publication" at the following link: http://www.cisco.com/web/about/security/intelligence/Cisco_ERP_sep10.html Affected Products ================= Vulnerable Products +------------------ Devices running affected versions of Cisco IOS Software are vulnerable if configured with SSL VPN and HTTP port redirection. The following methods may be used to confirm if the device is configured for Cisco IOS SSL VPNs and is vulnerable: If the output from show running-config | include webvpn contains "webvpn gateway " then the device is supporting the Cisco IOS SSL VPN feature. A device is vulnerable if it has the inservice command in at least one of the "webvpn gateway" sections and is configured for HTTP port redirection. The following example shows a vulnerable device configured with Cisco IOS SSL VPN: Router#show running | section webvpn webvpn gateway Gateway ip address 10.1.1.1 port 443 http-redirect port 80 ssl trustpoint Gateway-TP inservice ! Router# A device that supports the Cisco IOS SSL VPN is not vulnerable if "webvpn gateway" is not configured. To determine the Cisco IOS Software release that is running on a Cisco product, administrators can log in to the device and issue the show version command to display the system banner. The system banner confirms that the device is running Cisco IOS Software by displaying text similar to "Cisco Internetwork Operating System Software" or "Cisco IOS Software." The image name displays in parentheses, followed by "Version" and the Cisco IOS Software release name. Other Cisco devices do not have the show version command or may provide different output. The following example identifies a Cisco product that is running Cisco IOS Software Release 12.4(20)T with an installed image name of C2800NM-ADVSECURITYK9-M: Router#show version Cisco IOS Software, 2800 Software (C2800NM-ADVSECURITYK9-M), Version 12.4(20)T, RELEASE SOFTWARE (fc3) Technical Support: http://www.cisco.com/techsupport Copyright (c) 1986-2008 by Cisco Systems, Inc. Compiled Thu 10-Jul-08 22:00 by prod_rel_team ! --- output truncated Additional information about Cisco IOS Software release naming conventions is available in "White Paper: Cisco IOS Reference Guide" at the following link: http://www.cisco.com/warp/public/620/1.html Products Confirmed Not Vulnerable +-------------------------------- The following products are not affected by this vulnerability: * Cisco ASA 5500 Series Adaptive Security Appliances * Cisco IOS XR Software * Cisco IOS XE Software No other Cisco products are currently known to be affected by this vulnerability. Details ======= The Cisco IOS SSL VPN feature provides remote access to enterprise sites to users anywhere on the Internet. The SSL VPN provides users with secure access to specific enterprise applications, such as e-mail and web browsing, without requiring them to have VPN client software installed on their end-user devices. Further information about Cisco IOS SSL VPN is available in the "Cisco IOS Software Release 12.4T SSL VPN feature guide" at the following link: http://www.cisco.com/en/US/docs/ios/12_4t/12_4t11/htwebvpn.html leavingcisco.com A device configured for SSL VPN with HTTP port redirection may leak transmission control blocks (TCBs) when processing an abnormally disconnected SSL session. Continued exploitation may cause the device to deplete memory resources, which could result in device reloads, the inability to service new TCP connections, and other DoS conditions. Authentication is not required to exploit this vulnerability. A complete TCP 3-way handshake is required to exploit this vulnerability. The memory leak can be detected by running the command show tcp brief as shown in the following example: Router#show tcp brief TCB Local Address Foreign Address (state) 468BBDC0 192.168.0.22.80 192.168.0.33.19794 CLOSEWAIT 482D4730 192.168.0.22.80 192.168.0.33.22092 CLOSEWAIT 482779A4 192.168.0.22.80 192.168.0.33.16978 CLOSEWAIT 4693DEBC 192.168.0.22.80 192.168.0.33.21580 CLOSEWAIT 482D3418 192.168.0.22.80 192.168.0.33.17244 CLOSEWAIT 482B8ACC 192.168.0.22.80 192.168.0.33.16564 CLOSEWAIT 46954EB0 192.168.0.22.80 192.168.0.33.19532 CLOSEWAIT 468BA9B8 192.168.0.22.80 192.168.0.33.15781 CLOSEWAIT 482908C4 192.168.0.22.80 192.168.0.33.19275 CLOSEWAIT 4829D66C 192.168.0.22.80 192.168.0.33.19314 CLOSEWAIT 468A2D94 192.168.0.22.80 192.168.0.33.14736 CLOSEWAIT 4688F590 192.168.0.22.80 192.168.0.33.18786 CLOSEWAIT 4693CBA4 192.168.0.22.80 192.168.0.33.12176 CLOSEWAIT 4829ABC4 192.168.0.22.80 192.168.0.33.39629 CLOSEWAIT 4691206C 192.168.0.22.80 192.168.0.33.17818 CLOSEWAIT 46868224 192.168.0.22.80 192.168.0.33.16774 CLOSEWAIT 4832BFAC 192.168.0.22.80 192.168.0.33.39883 CLOSEWAIT 482D10CC 192.168.0.22.80 192.168.0.33.13677 CLOSEWAIT 4829B120 192.168.0.22.80 192.168.0.33.20870 CLOSEWAIT 482862FC 192.168.0.22.80 192.168.0.33.17035 CLOSEWAIT 482EC13C 192.168.0.22.80 192.168.0.33.16053 CLOSEWAIT 482901D8 192.168.0.22.80 192.168.0.33.16200 CLOSEWAIT In the output above, the Transmission Control Blocks (TCBs) in the state CLOSEWAIT will not transition and represent a memory leak. Note that only TCP connections with a local TCP port of 80 (the well-known port for HTTP), as evidenced in the above example by a Local Address of 192.168.0.22.80, are relevant. This vulnerability is documented in Cisco bug ID CSCtg21685 and Common Vulnerabilities and Exposures (CVE) identifier CVE-2010-2836 has been assigned to this vulnerability. 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 CSCtg21685 - SSLVPN : TCP remains stuck in closewait state 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 result in a lack of available memory resources on the affected device, which could affect new connections to the device such as SSH and Telnet connections. Depletion of memory resources may also result in failing of routing protocols and other services. 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 following Cisco IOS Software table corresponds to a Cisco IOS Software train. If a particular train is vulnerable, the earliest releases that contain the fix are listed in the First Fixed Release For This Advisory column. The First Fixed Release for All Advisories in the September 2010 Bundle Publication column lists the earliest possible releases that correct all the published vulnerabilities in the Cisco IOS Software Security Advisory bundled publication. Cisco recommends upgrading to the latest available release, where possible. +-------------------------------------------------------------------+ | Major | Availability of Repaired Releases | | Release | | |------------+------------------------------------------------------| | Affected | First Fixed Release | First Fixed Release for All | | 12.0-Based | for This Advisory | Advisories in the September | | Releases | | 2010 Bundle Publication | |-------------------------------------------------------------------| | There are no affected 12.0 based releases | |-------------------------------------------------------------------| | Affected | First Fixed Release | First Fixed Release for All | | 12.1-Based | for This Advisory | Advisories in the September | | Releases | | 2010 Bundle Publication | |-------------------------------------------------------------------| | There are no affected 12.1 based releases | |-------------------------------------------------------------------| | Affected | First Fixed Release | First Fixed Release for All | | 12.2-Based | for This Advisory | Advisories in the September | | Releases | | 2010 Bundle Publication | |-------------------------------------------------------------------| | There are no affected 12.2 based releases | |-------------------------------------------------------------------| | Affected | First Fixed Release | First Fixed Release for All | | 12.3-Based | for This Advisory | Advisories in the September | | Releases | | 2010 Bundle Publication | |-------------------------------------------------------------------| | There are no affected 12.3 based releases | |-------------------------------------------------------------------| | Affected | First Fixed Release | First Fixed Release for All | | 12.4-Based | for This Advisory | Advisories in the September | | Releases | | 2010 Bundle Publication | |------------+----------------------+-------------------------------| | 12.4 | Not Vulnerable | 12.4(25d) | |------------+----------------------+-------------------------------| | 12.4GC | Not Vulnerable | 12.4(24)GC2 | |------------+----------------------+-------------------------------| | 12.4JA | Not Vulnerable | Not Vulnerable | |------------+----------------------+-------------------------------| | 12.4JDA | Not Vulnerable | Not Vulnerable | |------------+----------------------+-------------------------------| | 12.4JDC | Not Vulnerable | Not Vulnerable | |------------+----------------------+-------------------------------| | 12.4JDD | Not Vulnerable | Not Vulnerable | |------------+----------------------+-------------------------------| | 12.4JHA | Not Vulnerable | Not Vulnerable | |------------+----------------------+-------------------------------| | 12.4JHB | Not Vulnerable | Not Vulnerable | |------------+----------------------+-------------------------------| | 12.4JK | Not Vulnerable | Not Vulnerable | |------------+----------------------+-------------------------------| | 12.4JL | Not Vulnerable | Not Vulnerable | |------------+----------------------+-------------------------------| | 12.4JMA | Not Vulnerable | Not Vulnerable | |------------+----------------------+-------------------------------| | 12.4JMB | Not Vulnerable | Not Vulnerable | |------------+----------------------+-------------------------------| | 12.4JX | Not Vulnerable | Not Vulnerable | |------------+----------------------+-------------------------------| | 12.4JY | Not Vulnerable | Not Vulnerable | |------------+----------------------+-------------------------------| | 12.4MD | Not Vulnerable | 12.4(24)MD2 | |------------+----------------------+-------------------------------| | | | 12.4(22)MDA4 | | 12.4MDA | Not Vulnerable | | | | | 12.4(24)MDA1 | |------------+----------------------+-------------------------------| | 12.4MR | Not Vulnerable | Vulnerable; first fixed in | | | | 12.4MRA | |------------+----------------------+-------------------------------| | 12.4MRA | Not Vulnerable | 12.4(20)MRA1 | |------------+----------------------+-------------------------------| | 12.4SW | Not Vulnerable | Vulnerable; first fixed in | | | | 12.4T | |------------+----------------------+-------------------------------| | | Releases Prior to | | | | 12.4(15)T13 are not | | | | vulnerable. First | | | | fixed 12.4(15)T14 | | | | | 12.4(15)T14 | | | Releases Prior to | | | 12.4T | 12.4(20)T5 are not | 12.4(20)T6 | | | vulnerable. First | | | | fixed 12.4(20)T6 | 12.4(24)T4 | | | | | | | Releases Prior to | | | | 12.4(24)T2 are not | | | | vulnerable. First | | | | fixed 12.4(24)T4 | | |------------+----------------------+-------------------------------| | 12.4XA | Not Vulnerable | Vulnerable; first fixed in | | | | 12.4T | |------------+----------------------+-------------------------------| | 12.4XB | Not Vulnerable | Vulnerable; first fixed in | | | | 12.4T | |------------+----------------------+-------------------------------| | 12.4XC | Not Vulnerable | Vulnerable; first fixed in | | | | 12.4T | |------------+----------------------+-------------------------------| | 12.4XD | Not Vulnerable | Vulnerable; first fixed in | | | | 12.4T | |------------+----------------------+-------------------------------| | | | Releases prior to 12.4(6)XE5 | | | | are vulnerable, release 12.4 | | 12.4XE | Not Vulnerable | (6)XE5 and later are not | | | | vulnerable; first fixed in | | | | 12.4T | |------------+----------------------+-------------------------------| | 12.4XF | Not Vulnerable | Vulnerable; first fixed in | | | | 12.4T | |------------+----------------------+-------------------------------| | 12.4XG | Not Vulnerable | Vulnerable; first fixed in | | | | 12.4T | |------------+----------------------+-------------------------------| | 12.4XJ | Not Vulnerable | Vulnerable; first fixed in | | | | 12.4T | |------------+----------------------+-------------------------------| | 12.4XK | Not Vulnerable | Vulnerable; first fixed in | | | | 12.4T | |------------+----------------------+-------------------------------| | | | Vulnerable; Contact your | | | | support organization per the | | 12.4XL | Not Vulnerable | instructions in Obtaining | | | | Fixed Software section of | | | | this advisory | |------------+----------------------+-------------------------------| | 12.4XM | Not Vulnerable | Vulnerable; first fixed in | | | | 12.4T | |------------+----------------------+-------------------------------| | | | Vulnerable; Contact your | | | | support organization per the | | 12.4XN | Not Vulnerable | instructions in Obtaining | | | | Fixed Software section of | | | | this advisory | |------------+----------------------+-------------------------------| | | | Vulnerable; Contact your | | | | support organization per the | | 12.4XP | Not Vulnerable | instructions in Obtaining | | | | Fixed Software section of | | | | this advisory | |------------+----------------------+-------------------------------| | 12.4XQ | Not Vulnerable | 12.4(15)XQ6; Available on | | | | 22-SEP-10 | |------------+----------------------+-------------------------------| | | | 12.4(15)XR9 | | 12.4XR | Not Vulnerable | | | | | 12.4(22)XR7 | |------------+----------------------+-------------------------------| | 12.4XT | Not Vulnerable | Vulnerable; first fixed in | | | | 12.4T | |------------+----------------------+-------------------------------| | | | Vulnerable; Contact your | | | | support organization per the | | 12.4XV | Not Vulnerable | instructions in Obtaining | | | | Fixed Software section of | | | | this advisory | |------------+----------------------+-------------------------------| | 12.4XW | Not Vulnerable | Vulnerable; first fixed in | | | | 12.4T | |------------+----------------------+-------------------------------| | 12.4XY | Not Vulnerable | Vulnerable; first fixed in | | | | 12.4T | |------------+----------------------+-------------------------------| | 12.4XZ | Not Vulnerable | Vulnerable; first fixed in | | | | 12.4T | |------------+----------------------+-------------------------------| | 12.4YA | Not Vulnerable | Vulnerable; first fixed in | | | | 12.4T | |------------+----------------------+-------------------------------| | | | Vulnerable; Contact your | | | | support organization per the | | 12.4YB | Not Vulnerable | instructions in Obtaining | | | | Fixed Software section of | | | | this advisory | |------------+----------------------+-------------------------------| | | | Vulnerable; Contact your | | | | support organization per the | | 12.4YD | Not Vulnerable | instructions in Obtaining | | | | Fixed Software section of | | | | this advisory | |------------+----------------------+-------------------------------| | 12.4YE | Not Vulnerable | 12.4(24)YE1 | |------------+----------------------+-------------------------------| | 12.4YG | Not Vulnerable | 12.4(24)YG3 | |------------+----------------------+-------------------------------| | Affected | First Fixed Release | First Fixed Release for All | | 15.0-Based | for This Advisory | Advisories in the September | | Releases | | 2010 Bundle Publication | |------------+----------------------+-------------------------------| | 15.0M | 15.0(1)M3 | 15.0(1)M3 | |------------+----------------------+-------------------------------| | | Cisco 7600 and 10000 | Cisco 7600 and 10000 Series | | | Series routers: Not | routers: 15.0(1)S1 (available | | | vulnerable | early October 2010) | | 15.0S | | | | | Please see Cisco | Please see Cisco IOS-XE | | | IOS-XE Software | Software Availability | | | Availability | | |------------+----------------------+-------------------------------| | 15.0XA | Not Vulnerable | Vulnerable; first fixed in | | | | 15.1T | |------------+----------------------+-------------------------------| | 15.0XO | Not Vulnerable | Not Vulnerable | |------------+----------------------+-------------------------------| | Affected | First Fixed Release | First Fixed Release for All | | 15.1-Based | for This Advisory | Advisories in the September | | Releases | | 2010 Bundle Publication | |------------+----------------------+-------------------------------| | | 15.1(1)T1 | | | 15.1T | | 15.1(2)T1 | | | 15.1(2)T0a | | |------------+----------------------+-------------------------------| | | Vulnerability | Vulnerable; first fixed in | | 15.1XB | limited to 15.1(1) | 15.1T | | | XB1. | | +-------------------------------------------------------------------+ Cisco IOS XE Software +-------------------- +-------------------------------------------------------------------+ | Cisco IOS | First Fixed | First Fixed Release for All | | XE | Release for This | Advisories in the September 2010 | | Release | Advisory | Bundle Publication | |-----------+------------------+------------------------------------| | 2.1.x | Not Vulnerable | Not Vulnerable | |-----------+------------------+------------------------------------| | 2.2.x | Not Vulnerable | Not Vulnerable | |-----------+------------------+------------------------------------| | 2.3.x | Not Vulnerable | Not Vulnerable | |-----------+------------------+------------------------------------| | 2.4.x | Not Vulnerable | Not Vulnerable | |-----------+------------------+------------------------------------| | 2.5.x | Not Vulnerable | Vulnerable; migrate to 2.6.2 or | | | | later | |-----------+------------------+------------------------------------| | 2.6.x | Not Vulnerable | 2.6.2 | |-----------+------------------+------------------------------------| | 3.1.xS | Not Vulnerable | Not Vulnerable | +-------------------------------------------------------------------+ For mapping of Cisco IOS XE Software to Cisco IOS Software releases, please refer to the Cisco IOS XE 2 and Cisco IOS XE 3S Release Notes. Cisco IOS XR System Software +--------------------------- Cisco IOS XR Software is not affected by the vulnerabilities disclosed in the September 22, 2010, Cisco IOS Software Security Advisory bundled publication. Workarounds =========== Disabling HTTP redirection for SSL VPN connections can be used as a workaround for this vulnerability. HTTP redirection for SSL VPN connections is disabled by executing the command no http-redirect port in webvpn gateway configuration mode. In addition, manually clearing the hung TCBs with the command clear tcp tcb * will transition the TCBs into a CLOSED state. After a time they will clear the CLOSED state and the memory will be released. Note: Clearing the TCB will clear both legitimate and hung connections, including remote connections to the device such as Telnet and SSH connections. The Cisco Applied Mitigation Bulletin (AMB) "Identifying and Mitigating Exploitation of the TCP State Manipulation Denial of Service Vulnerabilities in Multiple Cisco Products", available at http://www.cisco.com/warp/public/707/cisco-amb-20090908-tcp24.shtml, contains two mitigations (EEM scripts and SNMP) that can be used to detect and clear hung TCP connections. Embedded Event Manager (EEM) +--------------------------- A Cisco IOS Embedded Event Manager (EEM) policy that is based on Tool Command Language (Tcl) can be used on vulnerable Cisco IOS devices to identify and detect a hung, extended, or indefinite TCP connection that is caused by this vulnerability. The policy allows administrators to monitor TCP connections on a Cisco IOS device. When Cisco IOS EEM detects potential exploitation of this vulnerability, the policy can trigger a response by sending a syslog message or a Simple Network Management Protocol (SNMP) trap to clear the TCP connection. The example policy provided in this document is based on a Tcl script that monitors and parses the output from two commands at defined intervals, produces a syslog message when the monitor threshold reaches its configured value, and can reset the TCP connection. The Tcl script is available for download at the "Cisco Beyond: Embedded Event Manager (EEM) Scripting Community" at the following link: http://forums.cisco.com/eforum/servlet/EEM?page=eem&fn=script&scriptId=2041 A sample device configuration is provided below. ! !-- Location where the Tcl script will be stored ! event manager directory user policy disk0:/eem ! !-- Define variable and set the monitoring interval !-- as an integer (expressed in seconds) ! event manager environment EEM_MONITOR_INTERVAL 60 ! !-- Define variable and set the threshold value as !-- an integer for the number of retransmissions !-- that determine if the TCP connection is hung !-- (a recommended value to use is 15) ! event manager environment EEM_MONITOR_THRESHOLD 15 ! !-- Define variable and set the value to "yes" to !-- enable the clearing of hung TCP connections ! event manager environment EEM_MONITOR_CLEAR yes ! !-- Define variable and set to the TCP connection !-- state or states that script will monitor, which !-- can be a single state or a space-separated list !-- of states ! event manager environment EEM_MONITOR_STATES CLOSEWAIT ! !-- Register the script as a Cisco EEM policy ! event manager policy monitor-sockets.tcl ! For more details, refer to the sections "EEM Detecting And Clearing Hung TCP Connection" and "Identification: Detecting and Clearing Hung TCP Connection Using SNMP" of this AMB at the following link: http://www.cisco.com/warp/public/707/cisco-amb-20090908-tcp24.shtml Obtaining Fixed Software ======================== Cisco has released free software updates that address these vulnerabilities. Prior to deploying software, customers should consult their maintenance provider or check the software for feature set compatibility and known issues specific to their environment. Customers may only install and expect support for the feature sets they have purchased. By installing, downloading, accessing or otherwise using such software upgrades, customers agree to be bound by the terms of Cisco's software license terms found at http://www.cisco.com/en/US/docs/general/warranty/English/EU1KEN_.html or as otherwise set forth at Cisco.com Downloads at http://www.cisco.com/public/sw-center/sw-usingswc.shtml Do not contact psirt at cisco.com or security-alert at cisco.com for software upgrades. Customers with Service Contracts +------------------------------- Customers with contracts should obtain upgraded software through their regular update channels. For most customers, this means that upgrades should be obtained through the Software Center on Cisco's worldwide website at http://www.cisco.com Customers using Third Party Support Organizations +------------------------------------------------ Customers whose Cisco products are provided or maintained through prior or existing agreements with third-party support organizations, such as Cisco Partners, authorized resellers, or service providers should contact that support organization for guidance and assistance with the appropriate course of action in regards to this advisory. The effectiveness of any workaround or fix is dependent on specific customer situations, such as product mix, network topology, traffic behavior, and organizational mission. Due to the variety of affected products and releases, customers should consult with their service provider or support organization to ensure any applied workaround or fix is the most appropriate for use in the intended network before it is deployed. Customers without Service Contracts +---------------------------------- Customers who purchase direct from Cisco but do not hold a Cisco service contract, and customers who purchase through third-party vendors but are unsuccessful in obtaining fixed software through their point of sale should acquire upgrades by contacting the Cisco Technical Assistance Center (TAC). TAC contacts are as follows. * +1 800 553 2447 (toll free from within North America) * +1 408 526 7209 (toll call from anywhere in the world) * e-mail: tac at cisco.com Customers should have their product serial number available and be prepared to give the URL of this notice as evidence of entitlement to a free upgrade. Free upgrades for non-contract customers must be requested through the TAC. Refer to http://www.cisco.com/en/US/support/tsd_cisco_worldwide_contacts.html for additional TAC contact information, including localized telephone numbers, and instructions and e-mail addresses for use in various languages. Exploitation and Public Announcements ===================================== The Cisco PSIRT is not aware of any public announcements or malicious use of the vulnerability described in this advisory. This vulnerability was found during the troubleshooting of a customer service request. 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-20100922-sslvpn.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 | 2010-September-22 | 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.10 (Darwin) iEYEARECAAYFAkyZ/SwACgkQ86n/Gc8U/uBPYgCeOBY4HQKl1sgyp7mu9zl98VNK w84AoIVgVbW4s5KylgyKFiRAxFVUkiSZ =eC+N -----END PGP SIGNATURE----- From psirt at cisco.com Wed Sep 22 16:00:00 2010 From: psirt at cisco.com (Cisco Systems Product Security Incident Response Team) Date: Wed, 22 Sep 2010 18:00:00 +0200 Subject: Cisco Security Advisory: Cisco IOS Software H.323 Denial of Service Vulnerabilities Message-ID: <201009221801.h323@psirt.cisco.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Cisco Security Advisory: Cisco IOS Software H.323 Denial of Service Vulnerabilities Advisory ID: cisco-sa-20100922-h323 http://www.cisco.com/warp/public/707/cisco-sa-20100922-h323.shtml Revision 1.0 For Public Release 2010 September 22 1600 UTC (GMT) - --------------------------------------------------------------------- Summary ======= The H.323 implementation in Cisco IOS Software contains two vulnerabilities that may be exploited remotely to cause a denial of service (DoS) condition on a device that is running a vulnerable version of Cisco IOS Software. Cisco has released free software updates that address these vulnerabilities. There are no workarounds to mitigate these vulnerabilities other than disabling H.323 on the vulnerable device. This advisory is posted at http://www.cisco.com/warp/public/707/cisco-sa-20100922-h323.shtml Note: The September 22, 2010, Cisco IOS Software Security Advisory bundled publication includes six Cisco Security Advisories. Five of the advisories address vulnerabilities in Cisco IOS Software, and one advisory addresses vulnerabilities in Cisco Unified Communications Manager. Each advisory lists the releases that correct the vulnerability or vulnerabilities detailed in the advisory. The table at the following URL lists releases that correct all Cisco IOS Software vulnerabilities that have been published on September 22, 2010, or earlier: http://www.cisco.com/warp/public/707/cisco-sa-20100922-bundle.shtml Individual publication links are in "Cisco Event Response: Semiannual Cisco IOS Software Security Advisory Bundled Publication" at the following link: http://www.cisco.com/web/about/security/intelligence/Cisco_ERP_sep10.html Affected Products ================= These vulnerabilities only affect devices that are running Cisco IOS Software with H.323 voice services enabled. Vulnerable Products +------------------ Cisco devices that are running affected Cisco IOS Software versions that are configured to process H.323 messages are affected by these vulnerabilities. H.323 is not enabled by default. To determine if the Cisco IOS Software device is running H.323 services, issue the show process cpu | include H323 command, as shown in this example: Router# show process cpu | include H323 249 16000 3 5333 0.00% 0.00% 0.00% 0 CCH323_CT 250 0 1 0 0.00% 0.00% 0.00% 0 CCH323_DNS Router# In the previous example the processes CCH323_CT and CCH323_DNS are running on the device; therefore, the device is listening to H.323 messages. The device is vulnerable if any of these processes (or similar) are active. Note: Creating a dial peer by issuing the dial-peer voice command will start the H.323 processes, which causes the Cisco IOS device to process H.323 messages. To determine the Cisco IOS Software release that is running on a Cisco product, administrators can log in to the device and issue the show version command to display the system banner. The system banner confirms that the device is running Cisco IOS Software by displaying text similar to "Cisco Internetwork Operating System Software" or "Cisco IOS Software." The image name displays in parentheses, followed by "Version" and the Cisco IOS Software release name. Other Cisco devices do not have the show version command or may provide different output. The following example identifies a Cisco product that is running Cisco IOS Software Release 12.3(26) with an installed image name of C2500-IS-L: Router# show version Cisco Internetwork Operating System Software IOS (tm) 2500 Software (C2500-IS-L), Version 12.3(26), RELEASE SOFTWARE (fc2) Technical Support: http://www.cisco.com/techsupport Copyright (c) 1986-2008 by cisco Systems, Inc. Compiled Mon 17-Mar-08 14:39 by dchih !--- output truncated The following example identifies a Cisco product that is running Cisco IOS Software Release 12.4(20)T with an installed image name of C1841-ADVENTERPRISEK9-M: Router# show version Cisco IOS Software, 1841 Software (C1841-ADVENTERPRISEK9-M), Version 12.4(20)T, RELEASE SOFTWARE (fc3) Technical Support: http://www.cisco.com/techsupport Copyright (c) 1986-2008 by Cisco Systems, Inc. Compiled Thu 10-Jul-08 20:25 by prod_rel_team !--- output truncated Additional information about Cisco IOS Software release naming conventions is available in "White Paper: Cisco IOS Reference Guide" at the following link: http://www.cisco.com/web/about/security/intelligence/ios-ref.html Products Confirmed Not Vulnerable +-------------------------------- Cisco IOS XR Software is not affected by these vulnerabilities. No other Cisco products are currently known to be affected by these vulnerabilities. Details ======= H.323 is the International Telecommunication Union (ITU) standard for real-time multimedia communications and conferencing over packet-based (IP) networks. A subset of the H.323 standard is H.225.0, a standard that is used for call signaling protocols and media stream packetization over IP networks. The H.323 implementation in Cisco IOS Software contains two DoS vulnerabilities. An attacker can exploit these vulnerabilities remotely by sending crafted H.323 packets to an affected device that is running Cisco IOS Software. A TCP three-way handshake is required to exploit these vulnerabilities. These vulnerabilities are documented in Cisco Bug IDs CSCtc73759 ( registered customers only) and CSCtd33567 ( registered customers only) , and have been assigned Common Vulnerabilities and Exposures (CVE) IDs CVE-2010-2828 and CVE-2010-2829, respectively. Vulnerability Scoring Details ============================= Cisco has provided scores for the vulnerabilities in this advisory based on the Common Vulnerability Scoring System (CVSS). The CVSS scoring in this Security Advisory is done in accordance with CVSS version 2.0. CVSS is a standards-based scoring method that conveys vulnerability severity and helps determine urgency and priority of response. Cisco has provided a base and temporal score. Customers can then compute environmental scores to assist in determining the impact of the vulnerability in individual networks. Cisco has provided an FAQ to answer additional questions regarding CVSS at http://www.cisco.com/web/about/security/intelligence/cvss-qandas.html Cisco has also provided a CVSS calculator to help compute the environmental impact for individual networks at http://intellishield.cisco.com/security/alertmanager/cvss CSCtc73759 - Device crashing upon receipt of specific traffic 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 CSCtd33567 - Traceback seen when receiving crafted H.323 packets 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 vulnerabilities described in this advisory may cause the affected device to reload. Theses vulnerabilities could be exploited repeatedly to cause an extended DoS condition. Software Versions and Fixes =========================== When considering software upgrades, also consult http://www.cisco.com/go/psirt and any subsequent advisories to determine exposure and a complete upgrade solution. In all cases, customers should exercise caution to be certain the devices to be upgraded contain sufficient memory and that current hardware and software configurations will continue to be supported properly by the new release. If the information is not clear, contact the Cisco Technical Assistance Center (TAC) or your contracted maintenance provider for assistance. Each row of the following Cisco IOS Software table corresponds to a Cisco IOS Software train. If a particular train is vulnerable, the earliest releases that contain the fix are listed in the First Fixed Release For This Advisory column. The First Fixed Release for All Advisories in the September 2010 Bundle Publication column lists the earliest possible releases that correct all the published vulnerabilities in the Cisco IOS Software Security Advisory bundled publication. Cisco recommends upgrading to the latest available release, where possible. +--------------------------------------------------------------------+ | Major | Availability of Repaired Releases | | Release | | |------------+-------------------------------------------------------| | Affected | | First Fixed Release for | | 12.0-Based | First Fixed Release for | All Advisories in the | | Releases | This Advisory | September 2010 Bundle | | | | Publication | |--------------------------------------------------------------------| | There are no affected 12.0-based releases | |--------------------------------------------------------------------| | Affected | | First Fixed Release for | | 12.1-Based | First Fixed Release for | All Advisories in the | | Releases | This Advisory | September 2010 Bundle | | | | Publication | |------------+---------------------------+---------------------------| | | | Vulnerable; first fixed | | | | in 12.4T | | 12.1 | Not Vulnerable | | | | | Releases up to and | | | | including 12.1(4b) are | | | | not vulnerable. | |------------+---------------------------+---------------------------| | 12.1AA | Not Vulnerable | Not Vulnerable | |------------+---------------------------+---------------------------| | 12.1AX | Not Vulnerable | Not Vulnerable | |------------+---------------------------+---------------------------| | 12.1AY | Not Vulnerable | Not Vulnerable | |------------+---------------------------+---------------------------| | 12.1AZ | Not Vulnerable | Not Vulnerable | |------------+---------------------------+---------------------------| | 12.1CX | Not Vulnerable | Not Vulnerable | |------------+---------------------------+---------------------------| | 12.1DA | Not Vulnerable | Not Vulnerable | |------------+---------------------------+---------------------------| | 12.1DB | Not Vulnerable | Not Vulnerable | |------------+---------------------------+---------------------------| | 12.1DC | Not Vulnerable | Not Vulnerable | |------------+---------------------------+---------------------------| | 12.1E | Not Vulnerable | Not Vulnerable | |------------+---------------------------+---------------------------| | 12.1EA | Not Vulnerable | Not Vulnerable | |------------+---------------------------+---------------------------| | 12.1EB | Not Vulnerable | Not Vulnerable | |------------+---------------------------+---------------------------| | 12.1EC | Not Vulnerable | Not Vulnerable | |------------+---------------------------+---------------------------| | 12.1EO | Not Vulnerable | Not Vulnerable | |------------+---------------------------+---------------------------| | 12.1EU | Not Vulnerable | Not Vulnerable | |------------+---------------------------+---------------------------| | 12.1EV | Not Vulnerable | Not Vulnerable | |------------+---------------------------+---------------------------| | 12.1EW | Not Vulnerable | Not Vulnerable | |------------+---------------------------+---------------------------| | 12.1EX | Not Vulnerable | Not Vulnerable | |------------+---------------------------+---------------------------| | 12.1EY | Not Vulnerable | Not Vulnerable | |------------+---------------------------+---------------------------| | 12.1EZ | Not Vulnerable | Not Vulnerable | |------------+---------------------------+---------------------------| | 12.1GA | Not Vulnerable | Not Vulnerable | |------------+---------------------------+---------------------------| | 12.1GB | Not Vulnerable | Not Vulnerable | |------------+---------------------------+---------------------------| | | Vulnerable; first fixed | Vulnerable; first fixed | | | in 12.4 | in 12.4T | | 12.1T | | | | | Releases up to and | Releases up to and | | | including 12.1(3a)T8 are | including 12.1(3a)T8 are | | | not vulnerable. | not vulnerable. | |------------+---------------------------+---------------------------| | 12.1XA | Not Vulnerable | Not Vulnerable | |------------+---------------------------+---------------------------| | 12.1XB | Not Vulnerable | Not Vulnerable | |------------+---------------------------+---------------------------| | 12.1XC | Not Vulnerable | Not Vulnerable | |------------+---------------------------+---------------------------| | 12.1XD | Not Vulnerable | Not Vulnerable | |------------+---------------------------+---------------------------| | 12.1XE | Not Vulnerable | Not Vulnerable | |------------+---------------------------+---------------------------| | 12.1XF | Not Vulnerable | Not Vulnerable | |------------+---------------------------+---------------------------| | 12.1XG | Not Vulnerable | Not Vulnerable | |------------+---------------------------+---------------------------| | 12.1XH | Not Vulnerable | Not Vulnerable | |------------+---------------------------+---------------------------| | 12.1XI | Vulnerable; first fixed | Vulnerable; first fixed | | | in 12.4 | in 12.4T | |------------+---------------------------+---------------------------| | 12.1XJ | Vulnerable; first fixed | Vulnerable; first fixed | | | in 12.4 | in 12.4T | |------------+---------------------------+---------------------------| | 12.1XL | Vulnerable; first fixed | Vulnerable; first fixed | | | in 12.4 | in 12.4T | |------------+---------------------------+---------------------------| | 12.1XM | Vulnerable; first fixed | Vulnerable; first fixed | | | in 12.4 | in 12.4T | |------------+---------------------------+---------------------------| | 12.1XP | Vulnerable; first fixed | Vulnerable; first fixed | | | in 12.4 | in 12.4T | |------------+---------------------------+---------------------------| | 12.1XQ | Vulnerable; first fixed | Vulnerable; first fixed | | | in 12.4 | in 12.4T | |------------+---------------------------+---------------------------| | 12.1XR | Vulnerable; first fixed | Vulnerable; first fixed | | | in 12.4 | in 12.4T | |------------+---------------------------+---------------------------| | | Vulnerable; first fixed | Vulnerable; first fixed | | | in 12.4 | in 12.4T | | 12.1XS | | | | | Releases up to and | Releases up to and | | | including 12.1(3)XS are | including 12.1(3)XS are | | | not vulnerable. | not vulnerable. | |------------+---------------------------+---------------------------| | | Vulnerable; first fixed | Vulnerable; first fixed | | | in 12.4 | in 12.4T | | 12.1XT | | | | | Releases up to and | Releases up to and | | | including 12.1(2)XT2 are | including 12.1(2)XT2 are | | | not vulnerable. | not vulnerable. | |------------+---------------------------+---------------------------| | 12.1XU | Vulnerable; first fixed | Vulnerable; first fixed | | | in 12.4 | in 12.4T | |------------+---------------------------+---------------------------| | 12.1XV | Vulnerable; first fixed | Vulnerable; first fixed | | | in 12.4 | in 12.4T | |------------+---------------------------+---------------------------| | 12.1XW | Not Vulnerable | Not Vulnerable | |------------+---------------------------+---------------------------| | 12.1XX | Not Vulnerable | Not Vulnerable | |------------+---------------------------+---------------------------| | | Vulnerable; first fixed | Vulnerable; first fixed | | | in 12.4 | in 12.4T | | 12.1XY | | | | | Releases up to and | Releases up to and | | | including 12.1(4)XY are | including 12.1(4)XY are | | | not vulnerable. | not vulnerable. | |------------+---------------------------+---------------------------| | 12.1XZ | Not Vulnerable | Not Vulnerable | |------------+---------------------------+---------------------------| | 12.1YA | Vulnerable; first fixed | Vulnerable; first fixed | | | in 12.4 | in 12.4T | |------------+---------------------------+---------------------------| | 12.1YB | Vulnerable; first fixed | Vulnerable; first fixed | | | in 12.4 | in 12.4T | |------------+---------------------------+---------------------------| | 12.1YC | Vulnerable; first fixed | Vulnerable; first fixed | | | in 12.4 | in 12.4T | |------------+---------------------------+---------------------------| | 12.1YD | Vulnerable; first fixed | Vulnerable; first fixed | | | in 12.4 | in 12.4T | |------------+---------------------------+---------------------------| | | Releases prior to 12.1(5) | Releases prior to 12.1(5) | | | YE6 are vulnerable, | YE6 are vulnerable, | | 12.1YE | release 12.1(5)YE6 and | release 12.1(5)YE6 and | | | later are not vulnerable; | later are not vulnerable; | | | first fixed in 12.4 | first fixed in 12.4T | |------------+---------------------------+---------------------------| | 12.1YF | Vulnerable; first fixed | Vulnerable; first fixed | | | in 12.4 | in 12.4T | |------------+---------------------------+---------------------------| | 12.1YH | Vulnerable; first fixed | Vulnerable; first fixed | | | in 12.4 | in 12.4T | |------------+---------------------------+---------------------------| | | Vulnerable; Contact your | Vulnerable; Contact your | | | support organization per | support organization per | | 12.1YI | the instructions in | the instructions in | | | Obtaining Fixed Software | Obtaining Fixed Software | | | section of this advisory | section of this advisory | |------------+---------------------------+---------------------------| | 12.1YJ | Not Vulnerable | Not Vulnerable | |------------+---------------------------+---------------------------| | Affected | | First Fixed Release for | | 12.2-Based | First Fixed Release for | All Advisories in the | | Releases | This Advisory | September 2010 Bundle | | | | Publication | |------------+---------------------------+---------------------------| | 12.2 | Vulnerable; first fixed | Vulnerable; first fixed | | | in 12.4 | in 12.4T | |------------+---------------------------+---------------------------| | | Vulnerable; first fixed | Vulnerable; first fixed | | | in 12.4 | in 12.4T | | 12.2B | | | | | Releases up to and | Releases up to and | | | including 12.2(2)B7 are | including 12.2(2)B7 are | | | not vulnerable. | not vulnerable. | |------------+---------------------------+---------------------------| | 12.2BC | Not Vulnerable | Not Vulnerable | |------------+---------------------------+---------------------------| | 12.2BW | Vulnerable; first fixed | Vulnerable; first fixed | | | in 12.4 | in 12.4T | |------------+---------------------------+---------------------------| | | Vulnerable; first fixed | Vulnerable; first fixed | | | in 12.2SB | in 12.2SB | | 12.2BX | | | | | Releases up to and | Releases up to and | | | including 12.2(15)BX are | including 12.2(15)BX are | | | not vulnerable. | not vulnerable. | |------------+---------------------------+---------------------------| | | Vulnerable; first fixed | Vulnerable; first fixed | | | in 12.4 | in 12.4T | | 12.2BY | | | | | Releases up to and | Releases up to and | | | including 12.2(2)BY3 are | including 12.2(2)BY3 are | | | not vulnerable. | not vulnerable. | |------------+---------------------------+---------------------------| | 12.2BZ | Not Vulnerable | Not Vulnerable | |------------+---------------------------+---------------------------| | 12.2CX | Not Vulnerable | Not Vulnerable | |------------+---------------------------+---------------------------| | 12.2CY | Not Vulnerable | Not Vulnerable | |------------+---------------------------+---------------------------| | | Vulnerable; Contact your | Vulnerable; Contact your | | | support organization per | support organization per | | 12.2CZ | the instructions in | the instructions in | | | Obtaining Fixed Software | Obtaining Fixed Software | | | section of this advisory | section of this advisory | |------------+---------------------------+---------------------------| | 12.2DA | Not Vulnerable | Not Vulnerable | |------------+---------------------------+---------------------------| | 12.2DD | Vulnerable; first fixed | Vulnerable; first fixed | | | in 12.4 | in 12.4T | |------------+---------------------------+---------------------------| | 12.2DX | Vulnerable; first fixed | Vulnerable; first fixed | | | in 12.4 | in 12.4T | |------------+---------------------------+---------------------------| | 12.2EW | Not Vulnerable | Not Vulnerable | |------------+---------------------------+---------------------------| | 12.2EWA | Not Vulnerable | Not Vulnerable | |------------+---------------------------+---------------------------| | 12.2EX | Vulnerable; migrate to | Not Vulnerable | | | any release in 12.2SE | | |------------+---------------------------+---------------------------| | 12.2EY | Not Vulnerable | Not Vulnerable | |------------+---------------------------+---------------------------| | 12.2EZ | Not Vulnerable | Not Vulnerable | |------------+---------------------------+---------------------------| | 12.2FX | Not Vulnerable | Not Vulnerable | |------------+---------------------------+---------------------------| | 12.2FY | Not Vulnerable | Not Vulnerable | |------------+---------------------------+---------------------------| | 12.2FZ | Not Vulnerable | Not Vulnerable | |------------+---------------------------+---------------------------| | | | Vulnerable; Contact your | | | | support organization per | | 12.2IRA | Not Vulnerable | the instructions in | | | | Obtaining Fixed Software | | | | section of this advisory | |------------+---------------------------+---------------------------| | | | Vulnerable; Contact your | | | | support organization per | | 12.2IRB | Not Vulnerable | the instructions in | | | | Obtaining Fixed Software | | | | section of this advisory | |------------+---------------------------+---------------------------| | | | Vulnerable; Contact your | | | | support organization per | | 12.2IRC | Not Vulnerable | the instructions in | | | | Obtaining Fixed Software | | | | section of this advisory | |------------+---------------------------+---------------------------| | | | Vulnerable; Contact your | | | | support organization per | | 12.2IRD | Not Vulnerable | the instructions in | | | | Obtaining Fixed Software | | | | section of this advisory | |------------+---------------------------+---------------------------| | | | Vulnerable; Contact your | | | | support organization per | | 12.2IRE | Not Vulnerable | the instructions in | | | | Obtaining Fixed Software | | | | section of this advisory | |------------+---------------------------+---------------------------| | | | Vulnerable; Contact your | | | | support organization per | | 12.2IXA | Not Vulnerable | the instructions in | | | | Obtaining Fixed Software | | | | section of this advisory | |------------+---------------------------+---------------------------| | | | Vulnerable; Contact your | | | | support organization per | | 12.2IXB | Not Vulnerable | the instructions in | | | | Obtaining Fixed Software | | | | section of this advisory | |------------+---------------------------+---------------------------| | | | Vulnerable; Contact your | | | | support organization per | | 12.2IXC | Not Vulnerable | the instructions in | | | | Obtaining Fixed Software | | | | section of this advisory | |------------+---------------------------+---------------------------| | | | Vulnerable; Contact your | | | | support organization per | | 12.2IXD | Not Vulnerable | the instructions in | | | | Obtaining Fixed Software | | | | section of this advisory | |------------+---------------------------+---------------------------| | | | Vulnerable; Contact your | | | | support organization per | | 12.2IXE | Not Vulnerable | the instructions in | | | | Obtaining Fixed Software | | | | section of this advisory | |------------+---------------------------+---------------------------| | | | Vulnerable; Contact your | | | | support organization per | | 12.2IXF | Not Vulnerable | the instructions in | | | | Obtaining Fixed Software | | | | section of this advisory | |------------+---------------------------+---------------------------| | | | Vulnerable; Contact your | | | | support organization per | | 12.2IXG | Not Vulnerable | the instructions in | | | | Obtaining Fixed Software | | | | section of this advisory | |------------+---------------------------+---------------------------| | | | Vulnerable; Contact your | | | | support organization per | | 12.2IXH | Not Vulnerable | the instructions in | | | | Obtaining Fixed Software | | | | section of this advisory | |------------+---------------------------+---------------------------| | 12.2JA | Not Vulnerable | Not Vulnerable | |------------+---------------------------+---------------------------| | 12.2JK | Not Vulnerable | Not Vulnerable | |------------+---------------------------+---------------------------| | 12.2MB | Not Vulnerable | Not Vulnerable | |------------+---------------------------+---------------------------| | | Releases up to and | Releases up to and | | | including 12.2(15)MC1 are | including 12.2(15)MC1 are | | | not vulnerable. | not vulnerable. Releases | | 12.2MC | | 12.2(15)MC2b and later | | | Releases 12.2(15)MC2b and | are not vulnerable; first | | | later are not vulnerable; | fixed in 12.4T | | | first fixed in 12.4 | | |------------+---------------------------+---------------------------| | | | Vulnerable; Contact your | | | | support organization per | | 12.2MRA | Not Vulnerable | the instructions in | | | | Obtaining Fixed Software | | | | section of this advisory | |------------+---------------------------+---------------------------| | 12.2MRB | Not Vulnerable | 12.2(33)MRB2 | |------------+---------------------------+---------------------------| | | Releases prior to 12.2 | Releases prior to 12.2 | | 12.2S | (30)S are vulnerable, | (30)S are vulnerable, | | | release 12.2(30)S and | release 12.2(30)S and | | | later are not vulnerable | later are not vulnerable | |------------+---------------------------+---------------------------| | | 12.2(31)SB19 | 12.2(31)SB19 | | | | | | 12.2SB | Releases prior to 12.2 | Releases prior to 12.2 | | | (33)SB5 are vulnerable, | (33)SB5 are vulnerable, | | | release 12.2(33)SB5 and | release 12.2(33)SB5 and | | | later are not vulnerable | later are not vulnerable | |------------+---------------------------+---------------------------| | 12.2SBC | Vulnerable; first fixed | Vulnerable; first fixed | | | in 12.2SB | in 12.2SB | |------------+---------------------------+---------------------------| | 12.2SCA | Vulnerable; first fixed | Vulnerable; first fixed | | | in 12.2SCB | in 12.2SCB | |------------+---------------------------+---------------------------| | | 12.2(33)SCB10 | | | | | | | 12.2SCB | 12.2(33)SCB9 | 12.2(33)SCB9 | | | | | | | 12.2(33)SCB8 | | |------------+---------------------------+---------------------------| | | 12.2(33)SCC5 | | | 12.2SCC | | 12.2(33)SCC5 | | | 12.2(33)SCC4 | | |------------+---------------------------+---------------------------| | | 12.2(33)SCD3 | | | 12.2SCD | | 12.2(33)SCD3 | | | 12.2(33)SCD4 | | |------------+---------------------------+---------------------------| | 12.2SE | Not Vulnerable | Not Vulnerable | |------------+---------------------------+---------------------------| | 12.2SEA | Not Vulnerable | Not Vulnerable | |------------+---------------------------+---------------------------| | 12.2SEB | Not Vulnerable | Not Vulnerable | |------------+---------------------------+---------------------------| | 12.2SEC | Not Vulnerable | Not Vulnerable | |------------+---------------------------+---------------------------| | 12.2SED | Not Vulnerable | Not Vulnerable | |------------+---------------------------+---------------------------| | 12.2SEE | Not Vulnerable | Not Vulnerable | |------------+---------------------------+---------------------------| | 12.2SEF | Not Vulnerable | Not Vulnerable | |------------+---------------------------+---------------------------| | 12.2SEG | Not Vulnerable | Not Vulnerable | |------------+---------------------------+---------------------------| | | Releases prior to 12.2 | Releases prior to 12.2 | | | (40)SG are vulnerable, | (40)SG are vulnerable, | | 12.2SG | release 12.2(40)SG and | release 12.2(40)SG and | | | later are not vulnerable; | later are not vulnerable; | | | migrate to any release in | migrate to any release in | | | 12.2SGA | 12.2SGA | |------------+---------------------------+---------------------------| | 12.2SGA | Not Vulnerable | Not Vulnerable | |------------+---------------------------+---------------------------| | 12.2SL | Not Vulnerable | Not Vulnerable | |------------+---------------------------+---------------------------| | 12.2SM | Not Vulnerable | Not Vulnerable | |------------+---------------------------+---------------------------| | 12.2SO | Not Vulnerable | Not Vulnerable | |------------+---------------------------+---------------------------| | 12.2SQ | Not Vulnerable | Not Vulnerable | |------------+---------------------------+---------------------------| | | Releases prior to 12.2 | Releases prior to 12.2 | | 12.2SRA | (33)SRA6 are vulnerable, | (33)SRA6 are vulnerable, | | | release 12.2(33)SRA6 and | release 12.2(33)SRA6 and | | | later are not vulnerable | later are not vulnerable | |------------+---------------------------+---------------------------| | | Releases prior to 12.2 | Releases prior to 12.2 | | 12.2SRB | (33)SRB1 are vulnerable, | (33)SRB1 are vulnerable, | | | release 12.2(33)SRB1 and | release 12.2(33)SRB1 and | | | later are not vulnerable | later are not vulnerable | |------------+---------------------------+---------------------------| | 12.2SRC | Not Vulnerable | Not Vulnerable | |------------+---------------------------+---------------------------| | 12.2SRD | Not Vulnerable | Not Vulnerable | |------------+---------------------------+---------------------------| | 12.2SRE | Not Vulnerable | 12.2(33)SRE1 | |------------+---------------------------+---------------------------| | 12.2STE | Not Vulnerable | Not Vulnerable | |------------+---------------------------+---------------------------| | 12.2SU | Vulnerable; first fixed | Vulnerable; first fixed | | | in 12.4 | in 12.4T | |------------+---------------------------+---------------------------| | | Releases prior to 12.2 | Releases prior to 12.2 | | | (29b)SV1 are vulnerable, | (29b)SV1 are vulnerable, | | 12.2SV | release 12.2(29b)SV1 and | release 12.2(29b)SV1 and | | | later are not vulnerable; | later are not vulnerable; | | | migrate to any release in | migrate to any release in | | | 12.2SVD | 12.2SVD | |------------+---------------------------+---------------------------| | 12.2SVA | Not Vulnerable | Not Vulnerable | |------------+---------------------------+---------------------------| | 12.2SVC | Not Vulnerable | Not Vulnerable | |------------+---------------------------+---------------------------| | 12.2SVD | Not Vulnerable | Not Vulnerable | |------------+---------------------------+---------------------------| | 12.2SVE | Not Vulnerable | Not Vulnerable | |------------+---------------------------+---------------------------| | | Releases up to and | Releases up to and | | | including 12.2(21)SW1 are | including 12.2(21)SW1 are | | | not vulnerable. | not vulnerable. Releases | | 12.2SW | | 12.2(25)SW12 and later | | | Releases 12.2(25)SW12 and | are not vulnerable; first | | | later are not vulnerable; | fixed in 12.4T | | | first fixed in 12.4T | | |------------+---------------------------+---------------------------| | | | Releases up to and | | 12.2SX | Not Vulnerable | including 12.2(14)SX2 are | | | | not vulnerable. | |------------+---------------------------+---------------------------| | | Releases prior to 12.2 | Vulnerable; Contact your | | | (17b)SXA2 are vulnerable, | support organization per | | 12.2SXA | release 12.2(17b)SXA2 and | the instructions in | | | later are not vulnerable | Obtaining Fixed Software | | | | section of this advisory | |------------+---------------------------+---------------------------| | | Releases prior to 12.2 | Vulnerable; Contact your | | | (17d)SXB7 are vulnerable, | support organization per | | 12.2SXB | release 12.2(17d)SXB7 and | the instructions in | | | later are not vulnerable; | Obtaining Fixed Software | | | migrate to any release in | section of this advisory | | | 12.2SXE | | |------------+---------------------------+---------------------------| | | Releases prior to 12.2 | Vulnerable; Contact your | | | (18)SXD2 are vulnerable, | support organization per | | 12.2SXD | release 12.2(18)SXD2 and | the instructions in | | | later are not vulnerable | Obtaining Fixed Software | | | | section of this advisory | |------------+---------------------------+---------------------------| | | | Vulnerable; Contact your | | | | support organization per | | 12.2SXE | Not Vulnerable | the instructions in | | | | Obtaining Fixed Software | | | | section of this advisory | |------------+---------------------------+---------------------------| | | Only 12.2(18)SXF7 and | Releases prior to 12.2 | | 12.2SXF | 12.2(18)SXF8 are | (18)SXF11 are vulnerable, | | | vulnerable | release 12.2(18)SXF11 and | | | | later are not vulnerable | |------------+---------------------------+---------------------------| | 12.2SXH | Not Vulnerable | Not Vulnerable | |------------+---------------------------+---------------------------| | 12.2SXI | Not Vulnerable | Not Vulnerable | |------------+---------------------------+---------------------------| | | Vulnerable; Contact your | | | | support organization per | | | 12.2SY | the instructions in | Not Vulnerable | | | Obtaining Fixed Software | | | | section of this advisory | | |------------+---------------------------+---------------------------| | | Vulnerable; Contact your | Vulnerable; Contact your | | | support organization per | support organization per | | 12.2SZ | the instructions in | the instructions in | | | Obtaining Fixed Software | Obtaining Fixed Software | | | section of this advisory | section of this advisory | |------------+---------------------------+---------------------------| | 12.2T | Vulnerable; first fixed | Vulnerable; first fixed | | | in 12.4 | in 12.4T | |------------+---------------------------+---------------------------| | | Vulnerable; Contact your | Vulnerable; Contact your | | | support organization per | support organization per | | 12.2TPC | the instructions in | the instructions in | | | Obtaining Fixed Software | Obtaining Fixed Software | | | section of this advisory | section of this advisory | |------------+---------------------------+---------------------------| | | Vulnerable; first fixed | | | | in 12.4 | | | 12.2XA | | Vulnerable; first fixed | | | Releases up to and | in 12.4T | | | including 12.2(1)XA are | | | | not vulnerable. | | |------------+---------------------------+---------------------------| | 12.2XB | Vulnerable; first fixed | Vulnerable; first fixed | | | in 12.4 | in 12.4T | |------------+---------------------------+---------------------------| | 12.2XC | Vulnerable; first fixed | Vulnerable; first fixed | | | in 12.4 | in 12.4T | |------------+---------------------------+---------------------------| | 12.2XD | Vulnerable; first fixed | Vulnerable; first fixed | | | in 12.4 | in 12.4T | |------------+---------------------------+---------------------------| | 12.2XE | Not Vulnerable | Not Vulnerable | |------------+---------------------------+---------------------------| | 12.2XF | Not Vulnerable | Not Vulnerable | |------------+---------------------------+---------------------------| | 12.2XG | Vulnerable; first fixed | Vulnerable; first fixed | | | in 12.4 | in 12.4T | |------------+---------------------------+---------------------------| | 12.2XH | Vulnerable; first fixed | Vulnerable; first fixed | | | in 12.4 | in 12.4T | |------------+---------------------------+---------------------------| | 12.2XI | Vulnerable; first fixed | Vulnerable; first fixed | | | in 12.4 | in 12.4T | |------------+---------------------------+---------------------------| | 12.2XJ | Vulnerable; first fixed | Vulnerable; first fixed | | | in 12.4 | in 12.4T | |------------+---------------------------+---------------------------| | 12.2XK | Vulnerable; first fixed | Vulnerable; first fixed | | | in 12.4 | in 12.4T | |------------+---------------------------+---------------------------| | 12.2XL | Vulnerable; first fixed | Vulnerable; first fixed | | | in 12.4 | in 12.4T | |------------+---------------------------+---------------------------| | 12.2XM | Vulnerable; first fixed | Vulnerable; first fixed | | | in 12.4 | in 12.4T | |------------+---------------------------+---------------------------| | | Releases prior to 12.2 | | | | (33)XN1 are vulnerable, | Vulnerable; first fixed | | 12.2XN | release 12.2(33)XN1 and | in 12.2SB | | | later are not vulnerable; | | | | first fixed in 12.2SB | | |------------+---------------------------+---------------------------| | 12.2XNA | Please see Cisco IOS-XE | Please see Cisco IOS-XE | | | Software Availability | Software Availability | |------------+---------------------------+---------------------------| | 12.2XNB | Please see Cisco IOS-XE | Please see Cisco IOS-XE | | | Software Availability | Software Availability | |------------+---------------------------+---------------------------| | 12.2XNC | Please see Cisco IOS-XE | Please see Cisco IOS-XE | | | Software Availability | Software Availability | |------------+---------------------------+---------------------------| | 12.2XND | Please see Cisco IOS-XE | Please see Cisco IOS-XE | | | Software Availability | Software Availability | |------------+---------------------------+---------------------------| | 12.2XNE | Please see Cisco IOS-XE | Please see Cisco IOS-XE | | | Software Availability | Software Availability | |------------+---------------------------+---------------------------| | 12.2XNF | Please see Cisco IOS-XE | Please see Cisco IOS-XE | | | Software Availability | Software Availability | |------------+---------------------------+---------------------------| | 12.2XO | Not Vulnerable | Not Vulnerable | |------------+---------------------------+---------------------------| | 12.2XQ | Vulnerable; first fixed | Vulnerable; first fixed | | | in 12.4 | in 12.4T | |------------+---------------------------+---------------------------| | 12.2XR | Not Vulnerable | Not Vulnerable | |------------+---------------------------+---------------------------| | 12.2XS | Vulnerable; first fixed | Vulnerable; first fixed | | | in 12.4 | in 12.4T | |------------+---------------------------+---------------------------| | 12.2XT | Vulnerable; first fixed | Vulnerable; first fixed | | | in 12.4 | in 12.4T | |------------+---------------------------+---------------------------| | 12.2XU | Vulnerable; first fixed | Vulnerable; first fixed | | | in 12.4 | in 12.4T | |------------+---------------------------+---------------------------| | 12.2XV | Vulnerable; first fixed | Vulnerable; first fixed | | | in 12.4 | in 12.4T | |------------+---------------------------+---------------------------| | 12.2XW | Vulnerable; first fixed | Vulnerable; first fixed | | | in 12.4 | in 12.4T | |------------+---------------------------+---------------------------| | 12.2YA | Vulnerable; first fixed | Vulnerable; first fixed | | | in 12.4 | in 12.4T | |------------+---------------------------+---------------------------| | | Vulnerable; Contact your | Vulnerable; Contact your | | | support organization per | support organization per | | 12.2YB | the instructions in | the instructions in | | | Obtaining Fixed Software | Obtaining Fixed Software | | | section of this advisory | section of this advisory | |------------+---------------------------+---------------------------| | | Vulnerable; Contact your | Vulnerable; Contact your | | | support organization per | support organization per | | 12.2YC | the instructions in | the instructions in | | | Obtaining Fixed Software | Obtaining Fixed Software | | | section of this advisory | section of this advisory | |------------+---------------------------+---------------------------| | | Vulnerable; Contact your | Vulnerable; Contact your | | | support organization per | support organization per | | 12.2YD | the instructions in | the instructions in | | | Obtaining Fixed Software | Obtaining Fixed Software | | | section of this advisory | section of this advisory | |------------+---------------------------+---------------------------| | | Vulnerable; Contact your | Vulnerable; Contact your | | | support organization per | support organization per | | 12.2YE | the instructions in | the instructions in | | | Obtaining Fixed Software | Obtaining Fixed Software | | | section of this advisory | section of this advisory | |------------+---------------------------+---------------------------| | | Vulnerable; Contact your | Vulnerable; Contact your | | | support organization per | support organization per | | 12.2YF | the instructions in | the instructions in | | | Obtaining Fixed Software | Obtaining Fixed Software | | | section of this advisory | section of this advisory | |------------+---------------------------+---------------------------| | 12.2YG | Not Vulnerable | Not Vulnerable | |------------+---------------------------+---------------------------| | | Vulnerable; Contact your | Vulnerable; Contact your | | | support organization per | support organization per | | 12.2YH | the instructions in | the instructions in | | | Obtaining Fixed Software | Obtaining Fixed Software | | | section of this advisory | section of this advisory | |------------+---------------------------+---------------------------| | | Vulnerable; Contact your | Vulnerable; Contact your | | | support organization per | support organization per | | 12.2YJ | the instructions in | the instructions in | | | Obtaining Fixed Software | Obtaining Fixed Software | | | section of this advisory | section of this advisory | |------------+---------------------------+---------------------------| | | Vulnerable; Contact your | Vulnerable; Contact your | | | support organization per | support organization per | | 12.2YK | the instructions in | the instructions in | | | Obtaining Fixed Software | Obtaining Fixed Software | | | section of this advisory | section of this advisory | |------------+---------------------------+---------------------------| | | Vulnerable; Contact your | Vulnerable; Contact your | | | support organization per | support organization per | | 12.2YL | the instructions in | the instructions in | | | Obtaining Fixed Software | Obtaining Fixed Software | | | section of this advisory | section of this advisory | |------------+---------------------------+---------------------------| | 12.2YM | Vulnerable; first fixed | Vulnerable; first fixed | | | in 12.4 | in 12.4T | |------------+---------------------------+---------------------------| | | Vulnerable; Contact your | Vulnerable; Contact your | | | support organization per | support organization per | | 12.2YN | the instructions in | the instructions in | | | Obtaining Fixed Software | Obtaining Fixed Software | | | section of this advisory | section of this advisory | |------------+---------------------------+---------------------------| | | Vulnerable; Contact your | | | | support organization per | | | 12.2YO | the instructions in | Not Vulnerable | | | Obtaining Fixed Software | | | | section of this advisory | | |------------+---------------------------+---------------------------| | 12.2YP | Not Vulnerable | Not Vulnerable | |------------+---------------------------+---------------------------| | 12.2YQ | Not Vulnerable | Not Vulnerable | |------------+---------------------------+---------------------------| | 12.2YR | Not Vulnerable | Not Vulnerable | |------------+---------------------------+---------------------------| | 12.2YS | Not Vulnerable | Not Vulnerable | |------------+---------------------------+---------------------------| | | Vulnerable; Contact your | Vulnerable; Contact your | | | support organization per | support organization per | | 12.2YT | the instructions in | the instructions in | | | Obtaining Fixed Software | Obtaining Fixed Software | | | section of this advisory | section of this advisory | |------------+---------------------------+---------------------------| | | Vulnerable; Contact your | Vulnerable; Contact your | | | support organization per | support organization per | | 12.2YU | the instructions in | the instructions in | | | Obtaining Fixed Software | Obtaining Fixed Software | | | section of this advisory | section of this advisory | |------------+---------------------------+---------------------------| | | Releases prior to 12.2 | Releases prior to 12.2 | | 12.2YV | (11)YV1 are vulnerable, | (11)YV1 are vulnerable, | | | release 12.2(11)YV1 and | release 12.2(11)YV1 and | | | later are not vulnerable | later are not vulnerable | |------------+---------------------------+---------------------------| | | Vulnerable; Contact your | Vulnerable; Contact your | | | support organization per | support organization per | | 12.2YW | the instructions in | the instructions in | | | Obtaining Fixed Software | Obtaining Fixed Software | | | section of this advisory | section of this advisory | |------------+---------------------------+---------------------------| | | Vulnerable; Contact your | Vulnerable; Contact your | | | support organization per | support organization per | | 12.2YX | the instructions in | the instructions in | | | Obtaining Fixed Software | Obtaining Fixed Software | | | section of this advisory | section of this advisory | |------------+---------------------------+---------------------------| | | Vulnerable; Contact your | Vulnerable; Contact your | | | support organization per | support organization per | | 12.2YY | the instructions in | the instructions in | | | Obtaining Fixed Software | Obtaining Fixed Software | | | section of this advisory | section of this advisory | |------------+---------------------------+---------------------------| | | Vulnerable; Contact your | Vulnerable; Contact your | | | support organization per | support organization per | | 12.2YZ | the instructions in | the instructions in | | | Obtaining Fixed Software | Obtaining Fixed Software | | | section of this advisory | section of this advisory | |------------+---------------------------+---------------------------| | 12.2ZA | Not Vulnerable | Not Vulnerable | |------------+---------------------------+---------------------------| | | Releases up to and | Releases up to and | | 12.2ZB | including 12.2(8)ZB are | including 12.2(8)ZB are | | | not vulnerable. | not vulnerable. | |------------+---------------------------+---------------------------| | | Vulnerable; Contact your | Vulnerable; Contact your | | | support organization per | support organization per | | 12.2ZC | the instructions in | the instructions in | | | Obtaining Fixed Software | Obtaining Fixed Software | | | section of this advisory | section of this advisory | |------------+---------------------------+---------------------------| | | Vulnerable; Contact your | Vulnerable; Contact your | | | support organization per | support organization per | | 12.2ZD | the instructions in | the instructions in | | | Obtaining Fixed Software | Obtaining Fixed Software | | | section of this advisory | section of this advisory | |------------+---------------------------+---------------------------| | 12.2ZE | Vulnerable; first fixed | Vulnerable; first fixed | | | in 12.4 | in 12.4T | |------------+---------------------------+---------------------------| | 12.2ZF | Vulnerable; first fixed | Vulnerable; first fixed | | | in 12.4 | in 12.4T | |------------+---------------------------+---------------------------| | 12.2ZG | Not Vulnerable | Not Vulnerable | |------------+---------------------------+---------------------------| | 12.2ZH | Vulnerable; first fixed | Vulnerable; first fixed | | | in 12.4 | in 12.4T | |------------+---------------------------+---------------------------| | | Vulnerable; Contact your | Vulnerable; Contact your | | | support organization per | support organization per | | 12.2ZJ | the instructions in | the instructions in | | | Obtaining Fixed Software | Obtaining Fixed Software | | | section of this advisory | section of this advisory | |------------+---------------------------+---------------------------| | | Vulnerable; Contact your | Vulnerable; Contact your | | | support organization per | support organization per | | 12.2ZL | the instructions in | the instructions in | | | Obtaining Fixed Software | Obtaining Fixed Software | | | section of this advisory | section of this advisory | |------------+---------------------------+---------------------------| | | Vulnerable; Contact your | Vulnerable; Contact your | | | support organization per | support organization per | | 12.2ZP | the instructions in | the instructions in | | | Obtaining Fixed Software | Obtaining Fixed Software | | | section of this advisory | section of this advisory | |------------+---------------------------+---------------------------| | | Vulnerable; migrate to | Vulnerable; Contact your | | | any release in 12.2SXH | support organization per | | 12.2ZU | | the instructions in | | | Releases up to and | Obtaining Fixed Software | | | including 12.2(18)ZU are | section of this advisory | | | not vulnerable. | | |------------+---------------------------+---------------------------| | 12.2ZX | Not Vulnerable | Not Vulnerable | |------------+---------------------------+---------------------------| | | | Vulnerable; Contact your | | | | support organization per | | 12.2ZY | Not Vulnerable | the instructions in | | | | Obtaining Fixed Software | | | | section of this advisory | |------------+---------------------------+---------------------------| | | | Vulnerable; Contact your | | | | support organization per | | 12.2ZYA | Not Vulnerable | the instructions in | | | | Obtaining Fixed Software | | | | section of this advisory | |------------+---------------------------+---------------------------| | Affected | | First Fixed Release for | | 12.3-Based | First Fixed Release for | All Advisories in the | | Releases | This Advisory | September 2010 Bundle | | | | Publication | |------------+---------------------------+---------------------------| | 12.3 | Vulnerable; first fixed | Vulnerable; first fixed | | | in 12.4 | in 12.4T | |------------+---------------------------+---------------------------| | 12.3B | Vulnerable; first fixed | Vulnerable; first fixed | | | in 12.4 | in 12.4T | |------------+---------------------------+---------------------------| | 12.3BC | Not Vulnerable | Not Vulnerable | |------------+---------------------------+---------------------------| | 12.3BW | Not Vulnerable | Not Vulnerable | |------------+---------------------------+---------------------------| | 12.3EU | Not Vulnerable | Not Vulnerable | |------------+---------------------------+---------------------------| | 12.3JA | Not Vulnerable | Not Vulnerable | |------------+---------------------------+---------------------------| | 12.3JEA | Not Vulnerable | Not Vulnerable | |------------+---------------------------+---------------------------| | 12.3JEB | Not Vulnerable | Not Vulnerable | |------------+---------------------------+---------------------------| | 12.3JEC | Not Vulnerable | Not Vulnerable | |------------+---------------------------+---------------------------| | 12.3JED | Not Vulnerable | Not Vulnerable | |------------+---------------------------+---------------------------| | | Releases up to and | Releases up to and | | | including 12.3(2)JK3 are | including 12.3(2)JK3 are | | | not vulnerable. | not vulnerable. Releases | | 12.3JK | | 12.3(8)JK1 and later are | | | Releases 12.3(8)JK1 and | not vulnerable; first | | | later are not vulnerable; | fixed in 12.4T | | | first fixed in 12.4 | | |------------+---------------------------+---------------------------| | 12.3JL | Not Vulnerable | Not Vulnerable | |------------+---------------------------+---------------------------| | 12.3JX | Not Vulnerable | Not Vulnerable | |------------+---------------------------+---------------------------| | 12.3T | Vulnerable; first fixed | Vulnerable; first fixed | | | in 12.4 | in 12.4T | |------------+---------------------------+---------------------------| | | | Vulnerable; Contact your | | | Releases up to and | support organization per | | 12.3TPC | including 12.3(4)TPC11a | the instructions in | | | are not vulnerable. | Obtaining Fixed Software | | | | section of this advisory | |------------+---------------------------+---------------------------| | 12.3VA | Vulnerable; first fixed | Vulnerable; first fixed | | | in 12.4T | in 12.4T | |------------+---------------------------+---------------------------| | | Releases prior to 12.3(2) | | | | XA7 are vulnerable, | Vulnerable; first fixed | | 12.3XA | release 12.3(2)XA7 and | in 12.4T | | | later are not vulnerable; | | | | first fixed in 12.4 | | |------------+---------------------------+---------------------------| | | Vulnerable; Contact your | Vulnerable; Contact your | | | support organization per | support organization per | | 12.3XB | the instructions in | the instructions in | | | Obtaining Fixed Software | Obtaining Fixed Software | | | section of this advisory | section of this advisory | |------------+---------------------------+---------------------------| | 12.3XC | Vulnerable; first fixed | Vulnerable; first fixed | | | in 12.4 | in 12.4T | |------------+---------------------------+---------------------------| | 12.3XD | Vulnerable; first fixed | Vulnerable; first fixed | | | in 12.4 | in 12.4T | |------------+---------------------------+---------------------------| | 12.3XE | Vulnerable; first fixed | Vulnerable; first fixed | | | in 12.4 | in 12.4T | |------------+---------------------------+---------------------------| | | Vulnerable; Contact your | Vulnerable; Contact your | | | support organization per | support organization per | | 12.3XF | the instructions in | the instructions in | | | Obtaining Fixed Software | Obtaining Fixed Software | | | section of this advisory | section of this advisory | |------------+---------------------------+---------------------------| | 12.3XG | Vulnerable; first fixed | Vulnerable; first fixed | | | in 12.4 | in 12.4T | |------------+---------------------------+---------------------------| | | Releases prior to 12.3(7) | Releases prior to 12.3(7) | | | XI11 are vulnerable, | XI11 are vulnerable, | | 12.3XI | release 12.3(7)XI11 and | release 12.3(7)XI11 and | | | later are not vulnerable; | later are not vulnerable; | | | first fixed in 12.2SB | first fixed in 12.2SB | |------------+---------------------------+---------------------------| | 12.3XJ | Vulnerable; first fixed | Vulnerable; first fixed | | | in 12.3YX | in 12.4XR | |------------+---------------------------+---------------------------| | 12.3XK | Vulnerable; first fixed | Vulnerable; first fixed | | | in 12.4 | in 12.4T | |------------+---------------------------+---------------------------| | 12.3XL | Vulnerable; first fixed | Vulnerable; first fixed | | | in 12.4T | in 12.4T | |------------+---------------------------+---------------------------| | 12.3XQ | Vulnerable; first fixed | Vulnerable; first fixed | | | in 12.4 | in 12.4T | |------------+---------------------------+---------------------------| | 12.3XR | Vulnerable; first fixed | Vulnerable; first fixed | | | in 12.4 | in 12.4T | |------------+---------------------------+---------------------------| | 12.3XS | Not Vulnerable | Vulnerable; first fixed | | | | in 12.4T | |------------+---------------------------+---------------------------| | | Vulnerable; first fixed | | | | in 12.4T | | | 12.3XU | | Vulnerable; first fixed | | | Releases up to and | in 12.4T | | | including 12.3(8)XU1 are | | | | not vulnerable. | | |------------+---------------------------+---------------------------| | 12.3XW | Vulnerable; first fixed | Vulnerable; first fixed | | | in 12.3YX | in 12.4T | |------------+---------------------------+---------------------------| | 12.3XX | Vulnerable; first fixed | Vulnerable; first fixed | | | in 12.4 | in 12.4T | |------------+---------------------------+---------------------------| | 12.3XY | Vulnerable; first fixed | Vulnerable; first fixed | | | in 12.4 | in 12.4T | |------------+---------------------------+---------------------------| | 12.3XZ | Vulnerable; first fixed | Vulnerable; first fixed | | | in 12.4 | in 12.4T | |------------+---------------------------+---------------------------| | 12.3YA | Not Vulnerable | Vulnerable; first fixed | | | | in 12.4T | |------------+---------------------------+---------------------------| | 12.3YD | Not Vulnerable | Vulnerable; first fixed | | | | in 12.4T | |------------+---------------------------+---------------------------| | 12.3YF | Vulnerable; first fixed | Vulnerable; first fixed | | | in 12.3YX | in 12.4XR | |------------+---------------------------+---------------------------| | 12.3YG | Vulnerable; first fixed | Vulnerable; first fixed | | | in 12.4T | in 12.4T | |------------+---------------------------+---------------------------| | 12.3YH | Not Vulnerable | Vulnerable; first fixed | | | | in 12.4T | |------------+---------------------------+---------------------------| | 12.3YI | Not Vulnerable | Vulnerable; first fixed | | | | in 12.4T | |------------+---------------------------+---------------------------| | 12.3YJ | Not Vulnerable | Vulnerable; first fixed | | | | in 12.4T | |------------+---------------------------+---------------------------| | | Releases prior to 12.3 | | | | (11)YK3 are vulnerable, | Vulnerable; first fixed | | 12.3YK | release 12.3(11)YK3 and | in 12.4T | | | later are not vulnerable; | | | | first fixed in 12.4T | | |------------+---------------------------+---------------------------| | 12.3YM | Vulnerable; first fixed | Vulnerable; first fixed | | | in 12.4T | in 12.4T | |------------+---------------------------+---------------------------| | 12.3YQ | Vulnerable; first fixed | Vulnerable; first fixed | | | in 12.4T | in 12.4T | |------------+---------------------------+---------------------------| | | Vulnerable; first fixed | | | | in 12.4T | | | 12.3YS | | Vulnerable; first fixed | | | Releases up to and | in 12.4T | | | including 12.3(11)YS1 are | | | | not vulnerable. | | |------------+---------------------------+---------------------------| | 12.3YT | Vulnerable; first fixed | Vulnerable; first fixed | | | in 12.4T | in 12.4T | |------------+---------------------------+---------------------------| | 12.3YU | Vulnerable; first fixed | Vulnerable; first fixed | | | in 12.4T | in 12.4T | |------------+---------------------------+---------------------------| | 12.3YX | 12.3(14)YX17 | Vulnerable; first fixed | | | | in 12.4XR | |------------+---------------------------+---------------------------| | | Vulnerable; Contact your | Vulnerable; Contact your | | | support organization per | support organization per | | 12.3YZ | the instructions in | the instructions in | | | Obtaining Fixed Software | Obtaining Fixed Software | | | section of this advisory | section of this advisory | |------------+---------------------------+---------------------------| | 12.3ZA | Vulnerable; first fixed | Vulnerable; first fixed | | | in 12.4T | in 12.4T | |------------+---------------------------+---------------------------| | Affected | | First Fixed Release for | | 12.4-Based | First Fixed Release for | All Advisories in the | | Releases | This Advisory | September 2010 Bundle | | | | Publication | |------------+---------------------------+---------------------------| | 12.4 | 12.4(25d) | 12.4(25d) | |------------+---------------------------+---------------------------| | 12.4GC | 12.4(24)GC2 | 12.4(24)GC2 | |------------+---------------------------+---------------------------| | 12.4JA | Not Vulnerable | Not Vulnerable | |------------+---------------------------+---------------------------| | 12.4JDA | Not Vulnerable | Not Vulnerable | |------------+---------------------------+---------------------------| | 12.4JDC | Not Vulnerable | Not Vulnerable | |------------+---------------------------+---------------------------| | 12.4JDD | Not Vulnerable | Not Vulnerable | |------------+---------------------------+---------------------------| | 12.4JHA | Not Vulnerable | Not Vulnerable | |------------+---------------------------+---------------------------| | 12.4JHB | Not Vulnerable | Not Vulnerable | |------------+---------------------------+---------------------------| | 12.4JK | Not Vulnerable | Not Vulnerable | |------------+---------------------------+---------------------------| | 12.4JL | Not Vulnerable | Not Vulnerable | |------------+---------------------------+---------------------------| | 12.4JMA | Not Vulnerable | Not Vulnerable | |------------+---------------------------+---------------------------| | 12.4JMB | Not Vulnerable | Not Vulnerable | |------------+---------------------------+---------------------------| | 12.4JX | Not Vulnerable | Not Vulnerable | |------------+---------------------------+---------------------------| | 12.4JY | Not Vulnerable | Not Vulnerable | |------------+---------------------------+---------------------------| | 12.4MD | Not Vulnerable | 12.4(24)MD2 | |------------+---------------------------+---------------------------| | 12.4MDA | 12.4(22)MDA4 | 12.4(22)MDA4 | |------------+---------------------------+---------------------------| | 12.4MR | Vulnerable; first fixed | Vulnerable; first fixed | | | in 12.4MRA | in 12.4MRA | |------------+---------------------------+---------------------------| | 12.4MRA | 12.4(20)MRA1 | 12.4(20)MRA1 | |------------+---------------------------+---------------------------| | | Releases prior to 12.4 | | | | (15)SW6 are vulnerable, | Vulnerable; first fixed | | 12.4SW | release 12.4(15)SW6 and | in 12.4T | | | later are not vulnerable; | | | | first fixed in 12.4T | | |------------+---------------------------+---------------------------| | | 12.4(15)T14 | 12.4(15)T14 | | | | | | 12.4T | 12.4(20)T6 | 12.4(20)T6 | | | | | | | 12.4(24)T4 | 12.4(24)T4 | |------------+---------------------------+---------------------------| | 12.4XA | Vulnerable; first fixed | Vulnerable; first fixed | | | in 12.4T | in 12.4T | |------------+---------------------------+---------------------------| | 12.4XB | Vulnerable; first fixed | Vulnerable; first fixed | | | in 12.4T | in 12.4T | |------------+---------------------------+---------------------------| | 12.4XC | Vulnerable; first fixed | Vulnerable; first fixed | | | in 12.4T | in 12.4T | |------------+---------------------------+---------------------------| | 12.4XD | Vulnerable; first fixed | Vulnerable; first fixed | | | in 12.4T | in 12.4T | |------------+---------------------------+---------------------------| | | Releases prior to 12.4(6) | Releases prior to 12.4(6) | | | XE5 are vulnerable, | XE5 are vulnerable, | | 12.4XE | release 12.4(6)XE5 and | release 12.4(6)XE5 and | | | later are not vulnerable; | later are not vulnerable; | | | first fixed in 12.4T | first fixed in 12.4T | |------------+---------------------------+---------------------------| | 12.4XF | Vulnerable; first fixed | Vulnerable; first fixed | | | in 12.4T | in 12.4T | |------------+---------------------------+---------------------------| | | Releases prior to 12.4(9) | | | | XG5 are vulnerable, | Vulnerable; first fixed | | 12.4XG | release 12.4(9)XG5 and | in 12.4T | | | later are not vulnerable; | | | | first fixed in 12.4T | | |------------+---------------------------+---------------------------| | 12.4XJ | Vulnerable; first fixed | Vulnerable; first fixed | | | in 12.4T | in 12.4T | |------------+---------------------------+---------------------------| | 12.4XK | Vulnerable; first fixed | Vulnerable; first fixed | | | in 12.4T | in 12.4T | |------------+---------------------------+---------------------------| | | Vulnerable; Contact your | Vulnerable; Contact your | | | support organization per | support organization per | | 12.4XL | the instructions in | the instructions in | | | Obtaining Fixed Software | Obtaining Fixed Software | | | section of this advisory | section of this advisory | |------------+---------------------------+---------------------------| | | Releases prior to 12.4 | | | | (15)XM3 are vulnerable, | Vulnerable; first fixed | | 12.4XM | release 12.4(15)XM3 and | in 12.4T | | | later are not vulnerable; | | | | first fixed in 12.4T | | |------------+---------------------------+---------------------------| | | Vulnerable; Contact your | Vulnerable; Contact your | | | support organization per | support organization per | | 12.4XN | the instructions in | the instructions in | | | Obtaining Fixed Software | Obtaining Fixed Software | | | section of this advisory | section of this advisory | |------------+---------------------------+---------------------------| | | Vulnerable; Contact your | Vulnerable; Contact your | | | support organization per | support organization per | | 12.4XP | the instructions in | the instructions in | | | Obtaining Fixed Software | Obtaining Fixed Software | | | section of this advisory | section of this advisory | |------------+---------------------------+---------------------------| | | Releases up to and | | | | including 12.4(15)XQ are | | | | not vulnerable. | 12.4(15)XQ6; Available on | | 12.4XQ | | 22-SEP-10 | | | Releases 12.4(15)XQ6 and | | | | later are not vulnerable; | | | | first fixed in 12.4T | | |------------+---------------------------+---------------------------| | | | 12.4(15)XR9 | | 12.4XR | Not Vulnerable | | | | | 12.4(22)XR7 | |------------+---------------------------+---------------------------| | 12.4XT | Vulnerable; first fixed | Vulnerable; first fixed | | | in 12.4T | in 12.4T | |------------+---------------------------+---------------------------| | | Vulnerable; Contact your | Vulnerable; Contact your | | | support organization per | support organization per | | 12.4XV | the instructions in | the instructions in | | | Obtaining Fixed Software | Obtaining Fixed Software | | | section of this advisory | section of this advisory | |------------+---------------------------+---------------------------| | 12.4XW | Vulnerable; first fixed | Vulnerable; first fixed | | | in 12.4T | in 12.4T | |------------+---------------------------+---------------------------| | 12.4XY | Vulnerable; first fixed | Vulnerable; first fixed | | | in 12.4T | in 12.4T | |------------+---------------------------+---------------------------| | 12.4XZ | Vulnerable; first fixed | Vulnerable; first fixed | | | in 12.4T | in 12.4T | |------------+---------------------------+---------------------------| | 12.4YA | Vulnerable; first fixed | Vulnerable; first fixed | | | in 12.4T | in 12.4T | |------------+---------------------------+---------------------------| | | Vulnerable; Contact your | Vulnerable; Contact your | | | support organization per | support organization per | | 12.4YB | the instructions in | the instructions in | | | Obtaining Fixed Software | Obtaining Fixed Software | | | section of this advisory | section of this advisory | |------------+---------------------------+---------------------------| | | Vulnerable; Contact your | Vulnerable; Contact your | | | support organization per | support organization per | | 12.4YD | the instructions in | the instructions in | | | Obtaining Fixed Software | Obtaining Fixed Software | | | section of this advisory | section of this advisory | |------------+---------------------------+---------------------------| | | Releases prior to 12.4 | | | | (24)YE1 are vulnerable, | | | 12.4YE | release 12.4(24)YE1 and | 12.4(24)YE1 | | | later are not vulnerable; | | | | first fixed in 12.4T | | |------------+---------------------------+---------------------------| | 12.4YG | 12.4(24)YG3 | 12.4(24)YG3 | |------------+---------------------------+---------------------------| | Affected | | First Fixed Release for | | 15.0-Based | First Fixed Release for | All Advisories in the | | Releases | This Advisory | September 2010 Bundle | | | | Publication | |------------+---------------------------+---------------------------| | 15.0M | 15.0(1)M3 | 15.0(1)M3 | |------------+---------------------------+---------------------------| | | Cisco 7600 and 10000 | Cisco 7600 and 10000 | | | Series routers: Not | Series routers: 15.0(1)S1 | | | Vulnerable | (available early October | | | | 2010) | | 15.0S | Cisco ASR 1000 Series | | | | routes: Please see Cisco | Cisco ASR 1000 Series | | | IOS-XE Software | routes: Please see Cisco | | | Availability | IOS-XE Software | | | | Availability | |------------+---------------------------+---------------------------| | 15.0XA | Vulnerable; first fixed | Vulnerable; first fixed | | | in 15.1T | in 15.1T | |------------+---------------------------+---------------------------| | 15.0XO | Not Vulnerable | Not Vulnerable | |------------+---------------------------+---------------------------| | Affected | | First Fixed Release for | | 15.1-Based | First Fixed Release for | All Advisories in the | | Releases | This Advisory | September 2010 Bundle | | | | Publication | |------------+---------------------------+---------------------------| | | 15.1(1)T1 | | | 15.1T | | 15.1(2)T1 | | | 15.1(2)T0a | | |------------+---------------------------+---------------------------| | 15.1XB | Vulnerable; first fixed | Vulnerable; first fixed | | | in 15.1T | in 15.1T | +--------------------------------------------------------------------+ Cisco IOS XE Software +-------------------- +-------------------------------------------------------------------+ | Cisco IOS | First Fixed | First Fixed Release for All | | XE | Release for This | Advisories in the September 2010 | | Release | Advisory | Bundle Publication | |-----------+------------------+------------------------------------| | 2.1.x | Not Vulnerable | Not Vulnerable | |-----------+------------------+------------------------------------| | 2.2.x | Not Vulnerable | Not Vulnerable | |-----------+------------------+------------------------------------| | 2.3.x | Not Vulnerable | Not Vulnerable | |-----------+------------------+------------------------------------| | 2.4.x | Not Vulnerable | Not Vulnerable | |-----------+------------------+------------------------------------| | 2.5.x | 2.5.2 | Vulnerable; migrate to 2.6.2 or | | | | later | |-----------+------------------+------------------------------------| | 2.6.x | 2.6.1 | 2.6.2 | |-----------+------------------+------------------------------------| | 3.1.xS | Not Vulnerable | Not Vulnerable | +-------------------------------------------------------------------+ For mapping of Cisco IOS XE to Cisco IOS releases, please refer to the Cisco IOS XE 2 and Cisco IOS XE 3S Release Notes. Workarounds =========== There are no workarounds to mitigate these vulnerabilities apart from disabling H.323 if the Cisco IOS device does not require it. Applying access lists on interfaces that should not accept H.323 traffic and placing firewalls in strategic locations may greatly reduce exposure until an upgrade can be performed. Cisco provides Solution Reference Network Design (SRND) guides to help design and deploy networking solutions, which can be found at http://www.cisco.com/go/srnd Voice Security best practices are covered in the Cisco Unified Communications SRND Based on Cisco Unified Communications Manager 6.x at http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/srnd/6x/security.html To disable all H.323 call processing, administrators can issue the call service stop forced command under the voice service voip mode, as shown in this example: voice service voip h323 call service stop forced Note: The call service stop forced command disables all H.323 call processing. Additional mitigations that can be deployed on Cisco devices within the network are available in the companion document "Cisco Applied Mitigation Bulletin: Identifying and Mitigating Exploitation of the Multiple Vulnerabilities in Cisco Voice Products", which is available at the following location: http://www.cisco.com/warp/public/707/cisco-amb-20100922-voice.shtml Obtaining Fixed Software ======================== Cisco has released free software updates that address these vulnerabilities. Prior to deploying software, customers should consult their maintenance provider or check the software for feature set compatibility and known issues specific to their environment. Customers may only install and expect support for the feature sets they have purchased. By installing, downloading, accessing or otherwise using such software upgrades, customers agree to be bound by the terms of Cisco's software license terms found at http://www.cisco.com/en/US/docs/general/warranty/English/EU1KEN_.html or as otherwise set forth at Cisco.com Downloads at http://www.cisco.com/public/sw-center/sw-usingswc.shtml Do not contact psirt at cisco.com or security-alert at cisco.com for software upgrades. Customers with Service Contracts +------------------------------- Customers with contracts should obtain upgraded software through their regular update channels. For most customers, this means that upgrades should be obtained through the Software Center on Cisco's worldwide website at http://www.cisco.com Customers using Third Party Support Organizations +------------------------------------------------ Customers whose Cisco products are provided or maintained through prior or existing agreements with third-party support organizations, such as Cisco Partners, authorized resellers, or service providers should contact that support organization for guidance and assistance with the appropriate course of action in regards to this advisory. The effectiveness of any workaround or fix is dependent on specific customer situations, such as product mix, network topology, traffic behavior, and organizational mission. Due to the variety of affected products and releases, customers should consult with their service provider or support organization to ensure any applied workaround or fix is the most appropriate for use in the intended network before it is deployed. Customers without Service Contracts +---------------------------------- Customers who purchase direct from Cisco but do not hold a Cisco service contract, and customers who purchase through third-party vendors but are unsuccessful in obtaining fixed software through their point of sale should acquire upgrades by contacting the Cisco Technical Assistance Center (TAC). TAC contacts are as follows. * +1 800 553 2447 (toll free from within North America) * +1 408 526 7209 (toll call from anywhere in the world) * e-mail: tac at cisco.com Customers should have their product serial number available and be prepared to give the URL of this notice as evidence of entitlement to a free upgrade. Free upgrades for non-contract customers must be requested through the TAC. Refer to http://www.cisco.com/en/US/support/tsd_cisco_worldwide_contacts.html for additional TAC contact information, including localized telephone numbers, and instructions and e-mail addresses for use in various languages. Exploitation and Public Announcements ===================================== The Cisco PSIRT is not aware of any public announcements or malicious use of the vulnerabilities described in this advisory. These vulnerabilities were found during Cisco internal testing. 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-2010922-h323.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 | 2010-September-22 | 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.10 (Darwin) iEYEARECAAYFAkyZ/SoACgkQ86n/Gc8U/uCR8ACfbSQwX1PMeEwUVJWTSeGDtyrW jTMAnRuYshIzCis7CHMiORtLxeSKi80b =B67E -----END PGP SIGNATURE----- From psirt at cisco.com Wed Sep 22 16:00:00 2010 From: psirt at cisco.com (Cisco Systems Product Security Incident Response Team) Date: Wed, 22 Sep 2010 18:00:00 +0200 Subject: Cisco Security Advisory: Cisco IOS Software Session Initiation Protocol Denial of Service Vulnerabilities Message-ID: <201009221801.sip@psirt.cisco.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Cisco Security Advisory: Cisco IOS Software Session Initiation Protocol Denial of Service Vulnerabilities Advisory ID: cisco-sa-20100922-sip http://www.cisco.com/warp/public/707/cisco-sa-20100922-sip.shtml Revision 1.0 For Public Release 2010 September 22 1600 UTC (GMT) - --------------------------------------------------------------------- Summary ======= Multiple vulnerabilities exist in the Session Initiation Protocol (SIP) implementation in Cisco IOS^ Software that could allow an unauthenticated, remote attacker to cause a reload of an affected device when SIP operation is enabled. Cisco has released free software updates that address these vulnerabilities. There are no workarounds for devices that must run SIP; however, mitigations are available to limit exposure to the vulnerabilities. This advisory is posted at http://www.cisco.com/warp/public/707/cisco-sa-20100922-sip.shtml Note: The September 22, 2010, Cisco IOS Software Security Advisory bundled publication includes six Cisco Security Advisories. Five of the advisories address vulnerabilities in Cisco IOS Software, and one advisory addresses vulnerabilities in Cisco Unified Communications Manager. Each advisory lists the releases that correct the vulnerability or vulnerabilities detailed in the advisory. The table at the following URL lists releases that correct all Cisco IOS Software vulnerabilities that have been published on September 22, 2010, or earlier: http://www.cisco.com/warp/public/707/cisco-sa-20100922-bundle.shtml Individual publication links are in "Cisco Event Response: Semiannual Cisco IOS Software Security Advisory Bundled Publication" at the following link: http://www.cisco.com/web/about/security/intelligence/Cisco_ERP_sep10.html Cisco Unified Communications Manager (CUCM) is affected by the vulnerabilities described in this advisory. Two separate Cisco Security Advisories have been published to disclose the vulnerabilities that affect the Cisco Unified Communications Manager at the following locations: http://www.cisco.com/warp/public/707/cisco-sa-20090826-cucm.shtml http://www.cisco.com/warp/public/707/cisco-sa-20100922-cucm.shtml Affected Products ================= These vulnerabilities only affect devices running Cisco IOS Software with SIP voice services enabled. Vulnerable Products +------------------ Cisco devices are affected when they are running affected Cisco IOS Software versions that are configured to process SIP messages. Recent versions of Cisco IOS Software do not process SIP messages by default. Creating a dial peer by issuing the dial-peer voice command will start the SIP processes, causing the Cisco IOS device to process SIP messages. In addition, several features within Cisco Unified Communications Manager Express, such as ePhones, will also automatically start the SIP process when they are configured, causing the device to start processing SIP messages. An example of an affected configuration follows: dial-peer voice voip ... ! In addition to inspecting the Cisco IOS device configuration for a dial-peer command that causes the device to process SIP messages, administrators can also use the show processes | include SIP command to determine whether Cisco IOS Software is running the processes that handle SIP messages. In the following example, the presence of the processes CCSIP_UDP_SOCKET or CCSIP_TCP_SOCKET indicates that the Cisco IOS device will process SIP messages: Router# show processes | include SIP 149 Mwe 40F48254 4 1 400023108/24000 0 CCSIP_UDP_SOCKET 150 Mwe 40F48034 4 1 400023388/24000 0 CCSIP_TCP_SOCKET Note: Because there are several ways a device running Cisco IOS Software can start processing SIP messages, it is recommended that the show processes | include SIP command be used to determine whether the device is processing SIP messages instead of relying on the presence of specific configuration commands. Cisco Unified Border Element images are also affected by two of these vulnerabilities. Note: The Cisco Unified Border Element feature (previously known as the Cisco Multiservice IP-to-IP Gateway) is a special Cisco IOS Software image that runs on Cisco multiservice gateway platforms. It provides a network-to-network interface point for billing, security, call admission control, quality of service, and signaling interworking. To determine the Cisco IOS Software release that is running on a Cisco product, administrators can log in to the device and issue the show version command to display the system banner. The system banner confirms that the device is running Cisco IOS Software by displaying text similar to "Cisco Internetwork Operating System Software" or "Cisco IOS Software." The image name displays in parentheses, followed by "Version" and the Cisco IOS Software release name. Other Cisco devices do not have the show version command or may provide different output. The following example identifies a Cisco product that is running Cisco IOS Software Release 12.3(26) with an installed image name of C2500-IS-L: Router# show version Cisco Internetwork Operating System Software IOS (tm) 2500 Software (C2500-IS-L), Version 12.3(26), RELEASE SOFTWARE (fc2) Technical Support: http://www.cisco.com/techsupport Copyright (c) 1986-2008 by cisco Systems, Inc. Compiled Mon 17-Mar-08 14:39 by dchih !--- output truncated The following example identifies a Cisco product that is running Cisco IOS Software Release 12.4(20)T with an installed image name of C1841-ADVENTERPRISEK9-M: Router# show version Cisco IOS Software, 1841 Software (C1841-ADVENTERPRISEK9-M), Version 12.4(20)T, RELEASE SOFTWARE (fc3) Technical Support: http://www.cisco.com/techsupport Copyright (c) 1986-2008 by Cisco Systems, Inc. Compiled Thu 10-Jul-08 20:25 by prod_rel_team !--- output truncated Additional information about Cisco IOS Software release naming conventions is available in "White Paper: Cisco IOS Reference Guide" at the following link: http://www.cisco.com/warp/public/620/1.html Note: CUCM is affected by the vulnerabilities described in this advisory. Two separate Cisco Security Advisories have been published to disclose the vulnerabilities that affect the Cisco Unified Communications Manager at the following locations: http://www.cisco.com/warp/public/707/cisco-sa-20090826-cucm.shtml http://www.cisco.com/warp/public/707/cisco-sa-20100922-cucm.shtml Products Confirmed Not Vulnerable +-------------------------------- The SIP Application Layer Gateway (ALG), which is used by the Cisco IOS NAT and firewall features of Cisco IOS Software, is not affected by these vulnerabilities. Cisco IOS XR Software is not affected by these vulnerabilities. No other Cisco products are currently known to be affected by these vulnerabilities. Details ======= SIP is a popular signaling protocol that is used to manage voice and video calls across IP networks such as the Internet. SIP is responsible for handling all aspects of call setup and termination. Voice and video are the most popular types of sessions that SIP handles, but the protocol has the flexibility to accommodate other applications that require call setup and termination. SIP call signaling can use UDP (port 5060), TCP (port 5060), or Transport Layer Security (TLS; TCP port 5061) as the underlying transport protocol. Three vulnerabilities exist in the SIP implementation in Cisco IOS Software that may allow a remote attacker to cause an affected device to reload. These vulnerabilities are triggered when the device running Cisco IOS Software processes crafted SIP messages. Note: In cases where SIP is running over TCP transport, a TCP three-way handshake is necessary to exploit these vulnerabilities. These vulnerabilities are addressed by Cisco bug IDs CSCta20040, CSCsz43987 and CSCtf72678, and have been assigned Common Vulnerabilities and Exposures (CVE) IDs CVE-2010-2835, CVE-2009-2051 and CVE-2010-2834, respectively. Vulnerability Scoring Details ============================= Cisco has provided scores for the vulnerabilities in this advisory based on the Common Vulnerability Scoring System (CVSS). The CVSS scoring in this Security Advisory is done in accordance with CVSS version 2.0. CVSS is a standards-based scoring method that conveys vulnerability severity and helps determine urgency and priority of response. Cisco has provided a base and temporal score. Customers can then compute environmental scores to assist in determining the impact of the vulnerability in individual networks. Cisco has provided an FAQ to answer additional questions regarding CVSS at http://www.cisco.com/web/about/security/intelligence/cvss-qandas.html Cisco has also provided a CVSS calculator to help compute the environmental impact for individual networks at http://intellishield.cisco.com/security/alertmanager/cvss CSCta20040 - Device crashes when receiving crafted SIP message 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 CSCsz43987 - IOS coredump when sending crafted packets 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 CSCtf72678 - IOS Coredump Generated when sending crafted packets 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 vulnerabilities in this advisory may result in a reload of the device. Repeated exploitation could result in a sustained denial of service condition. Software Versions and Fixes =========================== When considering software upgrades, also consult http://www.cisco.com/go/psirt and any subsequent advisories to determine exposure and a complete upgrade solution. In all cases, customers should exercise caution to be certain the devices to be upgraded contain sufficient memory and that current hardware and software configurations will continue to be supported properly by the new release. If the information is not clear, contact the Cisco Technical Assistance Center (TAC) or your contracted maintenance provider for assistance. Each row of the following Cisco IOS Software table corresponds to a Cisco IOS Software train. If a particular train is vulnerable, the earliest releases that contain the fix are listed in the First Fixed Release For This Advisory column. The First Fixed Release for All Advisories in the September 2010 Bundle Publication column lists the earliest possible releases that correct all the published vulnerabilities in the Cisco IOS Software Security Advisory bundled publication. Cisco recommends upgrading to the latest available release, where possible. +-------------------------------------------------------------------+ | Major | Availability of Repaired Releases | | Release | | |------------+------------------------------------------------------| | Affected | | First Fixed Release for | | 12.0-Based | First Fixed Release for | All Advisories in the | | Releases | This Advisory | September 2010 Bundle | | | | Publication | |-------------------------------------------------------------------| | There are no affected 12.0-based releases | |-------------------------------------------------------------------| | Affected | | First Fixed Release for | | 12.1-Based | First Fixed Release for | All Advisories in the | | Releases | This Advisory | September 2010 Bundle | | | | Publication | |-------------------------------------------------------------------| | There are no affected 12.1-based releases | |-------------------------------------------------------------------| | Affected | | First Fixed Release for | | 12.2-Based | First Fixed Release for | All Advisories in the | | Releases | This Advisory | September 2010 Bundle | | | | Publication | |------------+--------------------------+---------------------------| | 12.2 | Not Vulnerable | Vulnerable; first fixed | | | | in 12.4T | |------------+--------------------------+---------------------------| | | | Vulnerable; first fixed | | | | in 12.4T | | 12.2B | Not Vulnerable | | | | | Releases up to and | | | | including 12.2(2)B7 are | | | | not vulnerable. | |------------+--------------------------+---------------------------| | 12.2BC | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | 12.2BW | Not Vulnerable | Vulnerable; first fixed | | | | in 12.4T | |------------+--------------------------+---------------------------| | | | Vulnerable; first fixed | | | | in 12.2SB | | 12.2BX | Not Vulnerable | | | | | Releases up to and | | | | including 12.2(15)BX are | | | | not vulnerable. | |------------+--------------------------+---------------------------| | | | Vulnerable; first fixed | | | | in 12.4T | | 12.2BY | Not Vulnerable | | | | | Releases up to and | | | | including 12.2(2)BY3 are | | | | not vulnerable. | |------------+--------------------------+---------------------------| | 12.2BZ | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | 12.2CX | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | 12.2CY | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | | | Vulnerable; Contact your | | | | support organization per | | 12.2CZ | Not Vulnerable | the instructions in | | | | Obtaining Fixed Software | | | | section of this advisory | |------------+--------------------------+---------------------------| | 12.2DA | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | 12.2DD | Not Vulnerable | Vulnerable; first fixed | | | | in 12.4T | |------------+--------------------------+---------------------------| | 12.2DX | Not Vulnerable | Vulnerable; first fixed | | | | in 12.4T | |------------+--------------------------+---------------------------| | 12.2EW | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | 12.2EWA | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | 12.2EX | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | 12.2EY | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | 12.2EZ | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | 12.2FX | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | 12.2FY | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | 12.2FZ | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | | | Vulnerable; Contact your | | | | support organization per | | 12.2IRA | Not Vulnerable | the instructions in | | | | Obtaining Fixed Software | | | | section of this advisory | |------------+--------------------------+---------------------------| | | | Vulnerable; Contact your | | | | support organization per | | 12.2IRB | Not Vulnerable | the instructions in | | | | Obtaining Fixed Software | | | | section of this advisory | |------------+--------------------------+---------------------------| | | | Vulnerable; Contact your | | | | support organization per | | 12.2IRC | Not Vulnerable | the instructions in | | | | Obtaining Fixed Software | | | | section of this advisory | |------------+--------------------------+---------------------------| | | | Vulnerable; Contact your | | | | support organization per | | 12.2IRD | Not Vulnerable | the instructions in | | | | Obtaining Fixed Software | | | | section of this advisory | |------------+--------------------------+---------------------------| | | | Vulnerable; Contact your | | | | support organization per | | 12.2IRE | Not Vulnerable | the instructions in | | | | Obtaining Fixed Software | | | | section of this advisory | |------------+--------------------------+---------------------------| | | | Vulnerable; Contact your | | | | support organization per | | 12.2IXA | Not Vulnerable | the instructions in | | | | Obtaining Fixed Software | | | | section of this advisory | |------------+--------------------------+---------------------------| | | | Vulnerable; Contact your | | | | support organization per | | 12.2IXB | Not Vulnerable | the instructions in | | | | Obtaining Fixed Software | | | | section of this advisory | |------------+--------------------------+---------------------------| | | | Vulnerable; Contact your | | | | support organization per | | 12.2IXC | Not Vulnerable | the instructions in | | | | Obtaining Fixed Software | | | | section of this advisory | |------------+--------------------------+---------------------------| | | | Vulnerable; Contact your | | | | support organization per | | 12.2IXD | Not Vulnerable | the instructions in | | | | Obtaining Fixed Software | | | | section of this advisory | |------------+--------------------------+---------------------------| | | | Vulnerable; Contact your | | | | support organization per | | 12.2IXE | Not Vulnerable | the instructions in | | | | Obtaining Fixed Software | | | | section of this advisory | |------------+--------------------------+---------------------------| | | | Vulnerable; Contact your | | | | support organization per | | 12.2IXF | Not Vulnerable | the instructions in | | | | Obtaining Fixed Software | | | | section of this advisory | |------------+--------------------------+---------------------------| | | | Vulnerable; Contact your | | | | support organization per | | 12.2IXG | Not Vulnerable | the instructions in | | | | Obtaining Fixed Software | | | | section of this advisory | |------------+--------------------------+---------------------------| | | | Vulnerable; Contact your | | | | support organization per | | 12.2IXH | Not Vulnerable | the instructions in | | | | Obtaining Fixed Software | | | | section of this advisory | |------------+--------------------------+---------------------------| | 12.2JA | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | 12.2JK | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | 12.2MB | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | | | Releases up to and | | | | including 12.2(15)MC1 are | | 12.2MC | Not Vulnerable | not vulnerable. Releases | | | | 12.2(15)MC2b and later | | | | are not vulnerable; first | | | | fixed in 12.4T | |------------+--------------------------+---------------------------| | | | Vulnerable; Contact your | | | | support organization per | | 12.2MRA | Not Vulnerable | the instructions in | | | | Obtaining Fixed Software | | | | section of this advisory | |------------+--------------------------+---------------------------| | 12.2MRB | Not Vulnerable | 12.2(33)MRB2 | |------------+--------------------------+---------------------------| | | | Releases prior to 12.2 | | 12.2S | Not Vulnerable | (30)S are vulnerable, | | | | release 12.2(30)S and | | | | later are not vulnerable | |------------+--------------------------+---------------------------| | | | 12.2(31)SB19 | | | | | | 12.2SB | Not Vulnerable | Releases prior to 12.2 | | | | (33)SB5 are vulnerable, | | | | release 12.2(33)SB5 and | | | | later are not vulnerable | |------------+--------------------------+---------------------------| | 12.2SBC | Not Vulnerable | Vulnerable; first fixed | | | | in 12.2SB | |------------+--------------------------+---------------------------| | 12.2SCA | Not Vulnerable | Vulnerable; first fixed | | | | in 12.2SCB | |------------+--------------------------+---------------------------| | 12.2SCB | Not Vulnerable | 12.2(33)SCB9 | |------------+--------------------------+---------------------------| | 12.2SCC | Not Vulnerable | 12.2(33)SCC5 | |------------+--------------------------+---------------------------| | 12.2SCD | Not Vulnerable | 12.2(33)SCD3 | |------------+--------------------------+---------------------------| | 12.2SE | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | 12.2SEA | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | 12.2SEB | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | 12.2SEC | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | 12.2SED | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | 12.2SEE | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | 12.2SEF | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | 12.2SEG | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | | | Releases prior to 12.2 | | | | (40)SG are vulnerable, | | 12.2SG | Not Vulnerable | release 12.2(40)SG and | | | | later are not vulnerable; | | | | migrate to any release in | | | | 12.2SGA | |------------+--------------------------+---------------------------| | 12.2SGA | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | 12.2SL | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | 12.2SM | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | 12.2SO | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | 12.2SQ | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | | | Releases prior to 12.2 | | 12.2SRA | Not Vulnerable | (33)SRA6 are vulnerable, | | | | release 12.2(33)SRA6 and | | | | later are not vulnerable | |------------+--------------------------+---------------------------| | | | Releases prior to 12.2 | | 12.2SRB | Not Vulnerable | (33)SRB1 are vulnerable, | | | | release 12.2(33)SRB1 and | | | | later are not vulnerable | |------------+--------------------------+---------------------------| | 12.2SRC | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | 12.2SRD | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | 12.2SRE | Not Vulnerable | 12.2(33)SRE1 | |------------+--------------------------+---------------------------| | 12.2STE | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | 12.2SU | Not Vulnerable | Vulnerable; first fixed | | | | in 12.4T | |------------+--------------------------+---------------------------| | | | Releases prior to 12.2 | | | | (29b)SV1 are vulnerable, | | 12.2SV | Not Vulnerable | release 12.2(29b)SV1 and | | | | later are not vulnerable; | | | | migrate to any release in | | | | 12.2SVD | |------------+--------------------------+---------------------------| | 12.2SVA | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | 12.2SVC | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | 12.2SVD | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | 12.2SVE | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | | | Releases up to and | | | | including 12.2(21)SW1 are | | 12.2SW | Not Vulnerable | not vulnerable. Releases | | | | 12.2(25)SW12 and later | | | | are not vulnerable; first | | | | fixed in 12.4T | |------------+--------------------------+---------------------------| | | | Releases up to and | | 12.2SX | Not Vulnerable | including 12.2(14)SX2 are | | | | not vulnerable. | |------------+--------------------------+---------------------------| | | | Vulnerable; Contact your | | | | support organization per | | 12.2SXA | Not Vulnerable | the instructions in | | | | Obtaining Fixed Software | | | | section of this advisory | |------------+--------------------------+---------------------------| | | | Vulnerable; Contact your | | | | support organization per | | 12.2SXB | Not Vulnerable | the instructions in | | | | Obtaining Fixed Software | | | | section of this advisory | |------------+--------------------------+---------------------------| | | | Vulnerable; Contact your | | | | support organization per | | 12.2SXD | Not Vulnerable | the instructions in | | | | Obtaining Fixed Software | | | | section of this advisory | |------------+--------------------------+---------------------------| | | | Vulnerable; Contact your | | | | support organization per | | 12.2SXE | Not Vulnerable | the instructions in | | | | Obtaining Fixed Software | | | | section of this advisory | |------------+--------------------------+---------------------------| | | | Releases prior to 12.2 | | 12.2SXF | Not Vulnerable | (18)SXF11 are vulnerable, | | | | release 12.2(18)SXF11 and | | | | later are not vulnerable | |------------+--------------------------+---------------------------| | 12.2SXH | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | 12.2SXI | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | 12.2SY | Vulnerable; migrate to | Not Vulnerable | | | any release in 12.2S | | |------------+--------------------------+---------------------------| | | | Vulnerable; Contact your | | | | support organization per | | 12.2SZ | Not Vulnerable | the instructions in | | | | Obtaining Fixed Software | | | | section of this advisory | |------------+--------------------------+---------------------------| | 12.2T | Not Vulnerable | Vulnerable; first fixed | | | | in 12.4T | |------------+--------------------------+---------------------------| | | | Vulnerable; Contact your | | | | support organization per | | 12.2TPC | Not Vulnerable | the instructions in | | | | Obtaining Fixed Software | | | | section of this advisory | |------------+--------------------------+---------------------------| | 12.2XA | Not Vulnerable | Vulnerable; first fixed | | | | in 12.4T | |------------+--------------------------+---------------------------| | 12.2XB | Not Vulnerable | Vulnerable; first fixed | | | | in 12.4T | |------------+--------------------------+---------------------------| | 12.2XC | Not Vulnerable | Vulnerable; first fixed | | | | in 12.4T | |------------+--------------------------+---------------------------| | 12.2XD | Not Vulnerable | Vulnerable; first fixed | | | | in 12.4T | |------------+--------------------------+---------------------------| | 12.2XE | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | 12.2XF | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | 12.2XG | Not Vulnerable | Vulnerable; first fixed | | | | in 12.4T | |------------+--------------------------+---------------------------| | 12.2XH | Not Vulnerable | Vulnerable; first fixed | | | | in 12.4T | |------------+--------------------------+---------------------------| | 12.2XI | Not Vulnerable | Vulnerable; first fixed | | | | in 12.4T | |------------+--------------------------+---------------------------| | 12.2XJ | Not Vulnerable | Vulnerable; first fixed | | | | in 12.4T | |------------+--------------------------+---------------------------| | 12.2XK | Not Vulnerable | Vulnerable; first fixed | | | | in 12.4T | |------------+--------------------------+---------------------------| | 12.2XL | Not Vulnerable | Vulnerable; first fixed | | | | in 12.4T | |------------+--------------------------+---------------------------| | 12.2XM | Not Vulnerable | Vulnerable; first fixed | | | | in 12.4T | |------------+--------------------------+---------------------------| | 12.2XN | Not Vulnerable | Vulnerable; first fixed | | | | in 12.2SB | |------------+--------------------------+---------------------------| | 12.2XNA | Please see Cisco IOS-XE | Please see Cisco IOS-XE | | | Software Availability | Software Availability | |------------+--------------------------+---------------------------| | 12.2XNB | Please see Cisco IOS-XE | Please see Cisco IOS-XE | | | Software Availability | Software Availability | |------------+--------------------------+---------------------------| | 12.2XNC | Please see Cisco IOS-XE | Please see Cisco IOS-XE | | | Software Availability | Software Availability | |------------+--------------------------+---------------------------| | 12.2XND | Please see Cisco IOS-XE | Please see Cisco IOS-XE | | | Software Availability | Software Availability | |------------+--------------------------+---------------------------| | 12.2XNE | Please see Cisco IOS-XE | Please see Cisco IOS-XE | | | Software Availability | Software Availability | |------------+--------------------------+---------------------------| | 12.2XNF | Please see Cisco IOS-XE | Please see Cisco IOS-XE | | | Software Availability | Software Availability | |------------+--------------------------+---------------------------| | 12.2XO | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | 12.2XQ | Not Vulnerable | Vulnerable; first fixed | | | | in 12.4T | |------------+--------------------------+---------------------------| | 12.2XR | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | 12.2XS | Not Vulnerable | Vulnerable; first fixed | | | | in 12.4T | |------------+--------------------------+---------------------------| | 12.2XT | Not Vulnerable | Vulnerable; first fixed | | | | in 12.4T | |------------+--------------------------+---------------------------| | 12.2XU | Not Vulnerable | Vulnerable; first fixed | | | | in 12.4T | |------------+--------------------------+---------------------------| | 12.2XV | Not Vulnerable | Vulnerable; first fixed | | | | in 12.4T | |------------+--------------------------+---------------------------| | 12.2XW | Not Vulnerable | Vulnerable; first fixed | | | | in 12.4T | |------------+--------------------------+---------------------------| | 12.2YA | Not Vulnerable | Vulnerable; first fixed | | | | in 12.4T | |------------+--------------------------+---------------------------| | | | Vulnerable; Contact your | | | | support organization per | | 12.2YB | Not Vulnerable | the instructions in | | | | Obtaining Fixed Software | | | | section of this advisory | |------------+--------------------------+---------------------------| | | | Vulnerable; Contact your | | | | support organization per | | 12.2YC | Not Vulnerable | the instructions in | | | | Obtaining Fixed Software | | | | section of this advisory | |------------+--------------------------+---------------------------| | | | Vulnerable; Contact your | | | | support organization per | | 12.2YD | Not Vulnerable | the instructions in | | | | Obtaining Fixed Software | | | | section of this advisory | |------------+--------------------------+---------------------------| | | | Vulnerable; Contact your | | | | support organization per | | 12.2YE | Not Vulnerable | the instructions in | | | | Obtaining Fixed Software | | | | section of this advisory | |------------+--------------------------+---------------------------| | | | Vulnerable; Contact your | | | | support organization per | | 12.2YF | Not Vulnerable | the instructions in | | | | Obtaining Fixed Software | | | | section of this advisory | |------------+--------------------------+---------------------------| | 12.2YG | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | | | Vulnerable; Contact your | | | | support organization per | | 12.2YH | Not Vulnerable | the instructions in | | | | Obtaining Fixed Software | | | | section of this advisory | |------------+--------------------------+---------------------------| | | | Vulnerable; Contact your | | | | support organization per | | 12.2YJ | Not Vulnerable | the instructions in | | | | Obtaining Fixed Software | | | | section of this advisory | |------------+--------------------------+---------------------------| | | | Vulnerable; Contact your | | | | support organization per | | 12.2YK | Not Vulnerable | the instructions in | | | | Obtaining Fixed Software | | | | section of this advisory | |------------+--------------------------+---------------------------| | | | Vulnerable; Contact your | | | | support organization per | | 12.2YL | Not Vulnerable | the instructions in | | | | Obtaining Fixed Software | | | | section of this advisory | |------------+--------------------------+---------------------------| | 12.2YM | Not Vulnerable | Vulnerable; first fixed | | | | in 12.4T | |------------+--------------------------+---------------------------| | | | Vulnerable; Contact your | | | | support organization per | | 12.2YN | Not Vulnerable | the instructions in | | | | Obtaining Fixed Software | | | | section of this advisory | |------------+--------------------------+---------------------------| | 12.2YO | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | 12.2YP | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | 12.2YQ | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | 12.2YR | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | 12.2YS | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | | | Vulnerable; Contact your | | | | support organization per | | 12.2YT | Not Vulnerable | the instructions in | | | | Obtaining Fixed Software | | | | section of this advisory | |------------+--------------------------+---------------------------| | | | Vulnerable; Contact your | | | | support organization per | | 12.2YU | Not Vulnerable | the instructions in | | | | Obtaining Fixed Software | | | | section of this advisory | |------------+--------------------------+---------------------------| | | | Releases prior to 12.2 | | 12.2YV | Not Vulnerable | (11)YV1 are vulnerable, | | | | release 12.2(11)YV1 and | | | | later are not vulnerable | |------------+--------------------------+---------------------------| | | | Vulnerable; Contact your | | | | support organization per | | 12.2YW | Not Vulnerable | the instructions in | | | | Obtaining Fixed Software | | | | section of this advisory | |------------+--------------------------+---------------------------| | | | Vulnerable; Contact your | | | | support organization per | | 12.2YX | Not Vulnerable | the instructions in | | | | Obtaining Fixed Software | | | | section of this advisory | |------------+--------------------------+---------------------------| | | | Vulnerable; Contact your | | | | support organization per | | 12.2YY | Not Vulnerable | the instructions in | | | | Obtaining Fixed Software | | | | section of this advisory | |------------+--------------------------+---------------------------| | | | Vulnerable; Contact your | | | | support organization per | | 12.2YZ | Not Vulnerable | the instructions in | | | | Obtaining Fixed Software | | | | section of this advisory | |------------+--------------------------+---------------------------| | 12.2ZA | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | | | Releases up to and | | 12.2ZB | Not Vulnerable | including 12.2(8)ZB are | | | | not vulnerable. | |------------+--------------------------+---------------------------| | | | Vulnerable; Contact your | | | | support organization per | | 12.2ZC | Not Vulnerable | the instructions in | | | | Obtaining Fixed Software | | | | section of this advisory | |------------+--------------------------+---------------------------| | | | Vulnerable; Contact your | | | | support organization per | | 12.2ZD | Not Vulnerable | the instructions in | | | | Obtaining Fixed Software | | | | section of this advisory | |------------+--------------------------+---------------------------| | 12.2ZE | Not Vulnerable | Vulnerable; first fixed | | | | in 12.4T | |------------+--------------------------+---------------------------| | 12.2ZF | Not Vulnerable | Vulnerable; first fixed | | | | in 12.4T | |------------+--------------------------+---------------------------| | 12.2ZG | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | 12.2ZH | Not Vulnerable | Vulnerable; first fixed | | | | in 12.4T | |------------+--------------------------+---------------------------| | | | Vulnerable; Contact your | | | | support organization per | | 12.2ZJ | Not Vulnerable | the instructions in | | | | Obtaining Fixed Software | | | | section of this advisory | |------------+--------------------------+---------------------------| | | | Vulnerable; Contact your | | | | support organization per | | 12.2ZL | Not Vulnerable | the instructions in | | | | Obtaining Fixed Software | | | | section of this advisory | |------------+--------------------------+---------------------------| | | | Vulnerable; Contact your | | | | support organization per | | 12.2ZP | Not Vulnerable | the instructions in | | | | Obtaining Fixed Software | | | | section of this advisory | |------------+--------------------------+---------------------------| | | | Vulnerable; Contact your | | | | support organization per | | 12.2ZU | Not Vulnerable | the instructions in | | | | Obtaining Fixed Software | | | | section of this advisory | |------------+--------------------------+---------------------------| | 12.2ZX | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | | | Vulnerable; Contact your | | | | support organization per | | 12.2ZY | Not Vulnerable | the instructions in | | | | Obtaining Fixed Software | | | | section of this advisory | |------------+--------------------------+---------------------------| | | | Vulnerable; Contact your | | | | support organization per | | 12.2ZYA | Not Vulnerable | the instructions in | | | | Obtaining Fixed Software | | | | section of this advisory | |------------+--------------------------+---------------------------| | Affected | | First Fixed Release for | | 12.3-Based | First Fixed Release for | All Advisories in the | | Releases | This Advisory | September 2010 Bundle | | | | Publication | |------------+--------------------------+---------------------------| | 12.3 | Not Vulnerable | Vulnerable; first fixed | | | | in 12.4T | |------------+--------------------------+---------------------------| | 12.3B | Not Vulnerable | Vulnerable; first fixed | | | | in 12.4T | |------------+--------------------------+---------------------------| | 12.3BC | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | 12.3BW | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | 12.3EU | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | 12.3JA | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | 12.3JEA | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | 12.3JEB | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | 12.3JEC | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | 12.3JED | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | | Releases up to and | | | | including 12.3(2)JK3 are | Releases up to and | | | not vulnerable. | including 12.3(2)JK3 are | | 12.3JK | | not vulnerable. Releases | | | Releases 12.3(8)JK1 and | 12.3(8)JK1 and later are | | | later are not | not vulnerable; first | | | vulnerable; first fixed | fixed in 12.4T | | | in 12.4T | | |------------+--------------------------+---------------------------| | 12.3JL | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | 12.3JX | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | | Vulnerable; first fixed | | | | in 12.4T | | | 12.3T | | Vulnerable; first fixed | | | Releases up to and | in 12.4T | | | including 12.3(4)T11 are | | | | not vulnerable. | | |------------+--------------------------+---------------------------| | | | Vulnerable; Contact your | | | | support organization per | | 12.3TPC | Not Vulnerable | the instructions in | | | | Obtaining Fixed Software | | | | section of this advisory | |------------+--------------------------+---------------------------| | 12.3VA | Vulnerable; first fixed | Vulnerable; first fixed | | | in 12.4T | in 12.4T | |------------+--------------------------+---------------------------| | 12.3XA | Not Vulnerable | Vulnerable; first fixed | | | | in 12.4T | |------------+--------------------------+---------------------------| | | | Vulnerable; Contact your | | | | support organization per | | 12.3XB | Not Vulnerable | the instructions in | | | | Obtaining Fixed Software | | | | section of this advisory | |------------+--------------------------+---------------------------| | 12.3XC | Not Vulnerable | Vulnerable; first fixed | | | | in 12.4T | |------------+--------------------------+---------------------------| | 12.3XD | Vulnerable; first fixed | Vulnerable; first fixed | | | in 12.4T | in 12.4T | |------------+--------------------------+---------------------------| | 12.3XE | Not Vulnerable | Vulnerable; first fixed | | | | in 12.4T | |------------+--------------------------+---------------------------| | | Vulnerable; Contact your | Vulnerable; Contact your | | | support organization per | support organization per | | 12.3XF | the instructions in | the instructions in | | | Obtaining Fixed Software | Obtaining Fixed Software | | | section of this advisory | section of this advisory | |------------+--------------------------+---------------------------| | 12.3XG | Vulnerable; first fixed | Vulnerable; first fixed | | | in 12.4T | in 12.4T | |------------+--------------------------+---------------------------| | | Releases prior to 12.3 | Releases prior to 12.3(7) | | | (7)XI11 are vulnerable, | XI11 are vulnerable, | | 12.3XI | release 12.3(7)XI11 and | release 12.3(7)XI11 and | | | later are not vulnerable | later are not vulnerable; | | | | first fixed in 12.2SB | |------------+--------------------------+---------------------------| | 12.3XJ | Vulnerable; migrate to | Vulnerable; first fixed | | | any release in 12.4XN | in 12.4XR | |------------+--------------------------+---------------------------| | 12.3XK | Vulnerable; first fixed | Vulnerable; first fixed | | | in 12.4T | in 12.4T | |------------+--------------------------+---------------------------| | 12.3XL | Vulnerable; first fixed | Vulnerable; first fixed | | | in 12.4T | in 12.4T | |------------+--------------------------+---------------------------| | 12.3XQ | Vulnerable; first fixed | Vulnerable; first fixed | | | in 12.4T | in 12.4T | |------------+--------------------------+---------------------------| | 12.3XR | Vulnerable; first fixed | Vulnerable; first fixed | | | in 12.4T | in 12.4T | |------------+--------------------------+---------------------------| | 12.3XS | Not Vulnerable | Vulnerable; first fixed | | | | in 12.4T | |------------+--------------------------+---------------------------| | | Vulnerable; first fixed | | | | in 12.4T | | | 12.3XU | | Vulnerable; first fixed | | | Releases up to and | in 12.4T | | | including 12.3(8)XU1 are | | | | not vulnerable. | | |------------+--------------------------+---------------------------| | 12.3XW | Vulnerable; migrate to | Vulnerable; first fixed | | | any release in 12.4XN | in 12.4T | |------------+--------------------------+---------------------------| | 12.3XX | Vulnerable; first fixed | Vulnerable; first fixed | | | in 12.4T | in 12.4T | |------------+--------------------------+---------------------------| | 12.3XY | Vulnerable; first fixed | Vulnerable; first fixed | | | in 12.4T | in 12.4T | |------------+--------------------------+---------------------------| | 12.3XZ | Not Vulnerable | Vulnerable; first fixed | | | | in 12.4T | |------------+--------------------------+---------------------------| | 12.3YA | Not Vulnerable | Vulnerable; first fixed | | | | in 12.4T | |------------+--------------------------+---------------------------| | 12.3YD | Not Vulnerable | Vulnerable; first fixed | | | | in 12.4T | |------------+--------------------------+---------------------------| | 12.3YF | Vulnerable; migrate to | Vulnerable; first fixed | | | any release in 12.4XN | in 12.4XR | |------------+--------------------------+---------------------------| | 12.3YG | Vulnerable; first fixed | Vulnerable; first fixed | | | in 12.4T | in 12.4T | |------------+--------------------------+---------------------------| | 12.3YH | Not Vulnerable | Vulnerable; first fixed | | | | in 12.4T | |------------+--------------------------+---------------------------| | 12.3YI | Not Vulnerable | Vulnerable; first fixed | | | | in 12.4T | |------------+--------------------------+---------------------------| | 12.3YJ | Not Vulnerable | Vulnerable; first fixed | | | | in 12.4T | |------------+--------------------------+---------------------------| | | Releases prior to 12.3 | | | | (11)YK3 are vulnerable, | | | 12.3YK | release 12.3(11)YK3 and | Vulnerable; first fixed | | | later are not | in 12.4T | | | vulnerable; first fixed | | | | in 12.4T | | |------------+--------------------------+---------------------------| | 12.3YM | Vulnerable; first fixed | Vulnerable; first fixed | | | in 12.4T | in 12.4T | |------------+--------------------------+---------------------------| | 12.3YQ | Vulnerable; first fixed | Vulnerable; first fixed | | | in 12.4T | in 12.4T | |------------+--------------------------+---------------------------| | | Vulnerable; first fixed | | | | in 12.4T | | | 12.3YS | | Vulnerable; first fixed | | | Releases up to and | in 12.4T | | | including 12.3(11)YS1 | | | | are not vulnerable. | | |------------+--------------------------+---------------------------| | 12.3YT | Vulnerable; first fixed | Vulnerable; first fixed | | | in 12.4T | in 12.4T | |------------+--------------------------+---------------------------| | 12.3YU | Vulnerable; first fixed | Vulnerable; first fixed | | | in 12.4T | in 12.4T | |------------+--------------------------+---------------------------| | 12.3YX | Vulnerable; migrate to | Vulnerable; first fixed | | | any release in 12.4XN | in 12.4XR | |------------+--------------------------+---------------------------| | | Vulnerable; Contact your | Vulnerable; Contact your | | | support organization per | support organization per | | 12.3YZ | the instructions in | the instructions in | | | Obtaining Fixed Software | Obtaining Fixed Software | | | section of this advisory | section of this advisory | |------------+--------------------------+---------------------------| | 12.3ZA | Vulnerable; first fixed | Vulnerable; first fixed | | | in 12.4T | in 12.4T | |------------+--------------------------+---------------------------| | Affected | | First Fixed Release for | | 12.4-Based | First Fixed Release for | All Advisories in the | | Releases | This Advisory | September 2010 Bundle | | | | Publication | |------------+--------------------------+---------------------------| | 12.4 | 12.4(25d) | 12.4(25d) | |------------+--------------------------+---------------------------| | 12.4GC | 12.4(24)GC2 | 12.4(24)GC2 | |------------+--------------------------+---------------------------| | 12.4JA | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | 12.4JDA | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | 12.4JDC | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | 12.4JDD | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | 12.4JHA | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | 12.4JHB | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | 12.4JK | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | 12.4JL | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | 12.4JMA | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | 12.4JMB | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | 12.4JX | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | 12.4JY | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | 12.4MD | Not Vulnerable | 12.4(24)MD2 | |------------+--------------------------+---------------------------| | 12.4MDA | Not Vulnerable | 12.4(22)MDA4 | |------------+--------------------------+---------------------------| | 12.4MR | Vulnerable; first fixed | Vulnerable; first fixed | | | in 12.4MRA | in 12.4MRA | |------------+--------------------------+---------------------------| | 12.4MRA | 12.4(20)MRA1 | 12.4(20)MRA1 | |------------+--------------------------+---------------------------| | 12.4SW | Not Vulnerable | Vulnerable; first fixed | | | | in 12.4T | |------------+--------------------------+---------------------------| | | 12.4(15)T14 | 12.4(15)T14 | | | | | | 12.4T | 12.4(24)T4 | 12.4(24)T4 | | | | | | | 12.4(20)T6 | 12.4(20)T6 | |------------+--------------------------+---------------------------| | 12.4XA | Vulnerable; first fixed | Vulnerable; first fixed | | | in 12.4T | in 12.4T | |------------+--------------------------+---------------------------| | 12.4XB | Vulnerable; first fixed | Vulnerable; first fixed | | | in 12.4T | in 12.4T | |------------+--------------------------+---------------------------| | 12.4XC | Vulnerable; first fixed | Vulnerable; first fixed | | | in 12.4T | in 12.4T | |------------+--------------------------+---------------------------| | 12.4XD | Vulnerable; first fixed | Vulnerable; first fixed | | | in 12.4T | in 12.4T | |------------+--------------------------+---------------------------| | | Releases prior to 12.4 | Releases prior to 12.4(6) | | | (6)XE5 are vulnerable, | XE5 are vulnerable, | | 12.4XE | release 12.4(6)XE5 and | release 12.4(6)XE5 and | | | later are not | later are not vulnerable; | | | vulnerable; first fixed | first fixed in 12.4T | | | in 12.4T | | |------------+--------------------------+---------------------------| | 12.4XF | Not Vulnerable | Vulnerable; first fixed | | | | in 12.4T | |------------+--------------------------+---------------------------| | 12.4XG | Not Vulnerable | Vulnerable; first fixed | | | | in 12.4T | |------------+--------------------------+---------------------------| | 12.4XJ | Vulnerable; first fixed | Vulnerable; first fixed | | | in 12.4T | in 12.4T | |------------+--------------------------+---------------------------| | 12.4XK | Not Vulnerable | Vulnerable; first fixed | | | | in 12.4T | |------------+--------------------------+---------------------------| | | Vulnerable; Contact your | Vulnerable; Contact your | | | support organization per | support organization per | | 12.4XL | the instructions in | the instructions in | | | Obtaining Fixed Software | Obtaining Fixed Software | | | section of this advisory | section of this advisory | |------------+--------------------------+---------------------------| | | Releases up to and | | | | including 12.4(15)XM are | | | | not vulnerable. | | | 12.4XM | | Vulnerable; first fixed | | | Releases 12.4(15)XM3 and | in 12.4T | | | later are not | | | | vulnerable; first fixed | | | | in 12.4T | | |------------+--------------------------+---------------------------| | | | Vulnerable; Contact your | | | | support organization per | | 12.4XN | Not Vulnerable | the instructions in | | | | Obtaining Fixed Software | | | | section of this advisory | |------------+--------------------------+---------------------------| | | Vulnerable; Contact your | Vulnerable; Contact your | | | support organization per | support organization per | | 12.4XP | the instructions in | the instructions in | | | Obtaining Fixed Software | Obtaining Fixed Software | | | section of this advisory | section of this advisory | |------------+--------------------------+---------------------------| | 12.4XQ | Not Vulnerable | 12.4(15)XQ6; Available on | | | | 22-SEP-10 | |------------+--------------------------+---------------------------| | | | 12.4(15)XR9 | | 12.4XR | Not Vulnerable | | | | | 12.4(22)XR7 | |------------+--------------------------+---------------------------| | 12.4XT | Vulnerable; first fixed | Vulnerable; first fixed | | | in 12.4T | in 12.4T | |------------+--------------------------+---------------------------| | | Vulnerable; Contact your | Vulnerable; Contact your | | | support organization per | support organization per | | 12.4XV | the instructions in | the instructions in | | | Obtaining Fixed Software | Obtaining Fixed Software | | | section of this advisory | section of this advisory | |------------+--------------------------+---------------------------| | 12.4XW | Vulnerable; first fixed | Vulnerable; first fixed | | | in 12.4T | in 12.4T | |------------+--------------------------+---------------------------| | 12.4XY | Vulnerable; first fixed | Vulnerable; first fixed | | | in 12.4T | in 12.4T | |------------+--------------------------+---------------------------| | 12.4XZ | Vulnerable; first fixed | Vulnerable; first fixed | | | in 12.4T | in 12.4T | |------------+--------------------------+---------------------------| | 12.4YA | Vulnerable; first fixed | Vulnerable; first fixed | | | in 12.4T | in 12.4T | |------------+--------------------------+---------------------------| | | Vulnerable; Contact your | Vulnerable; Contact your | | | support organization per | support organization per | | 12.4YB | the instructions in | the instructions in | | | Obtaining Fixed Software | Obtaining Fixed Software | | | section of this advisory | section of this advisory | |------------+--------------------------+---------------------------| | | | Vulnerable; Contact your | | | | support organization per | | 12.4YD | Not Vulnerable | the instructions in | | | | Obtaining Fixed Software | | | | section of this advisory | |------------+--------------------------+---------------------------| | 12.4YE | Not Vulnerable | 12.4(24)YE1 | |------------+--------------------------+---------------------------| | 12.4YG | Not Vulnerable | 12.4(24)YG3 | |------------+--------------------------+---------------------------| | Affected | | First Fixed Release for | | 15.0-Based | First Fixed Release for | All Advisories in the | | Releases | This Advisory | September 2010 Bundle | | | | Publication | |------------+--------------------------+---------------------------| | 15.0M | 15.0(1)M3 | 15.0(1)M3 | |------------+--------------------------+---------------------------| | | Cisco 7600 and 10000 | Cisco 7600 and 10000 | | | Series routers: Not | Series routers: 15.0(1)S1 | | | Vulnerable | (available early October | | | | 2010). | | 15.0S | Cisco ASR 1000 Series | | | | routes: Please see Cisco | Cisco ASR 1000 Series | | | IOS-XE Software | routes: Please see Cisco | | | Availability | IOS-XE Software | | | | Availability | |------------+--------------------------+---------------------------| | 15.0XA | 15.0(1)XA4 | Vulnerable; first fixed | | | | in 15.1T | |------------+--------------------------+---------------------------| | 15.0XO | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | Affected | | First Fixed Release for | | 15.1-Based | First Fixed Release for | All Advisories in the | | Releases | This Advisory | September 2010 Bundle | | | | Publication | |------------+--------------------------+---------------------------| | | 15.1(2)T0a | | | 15.1T | | 15.1(2)T1 | | | 15.1(1)T1 | | |------------+--------------------------+---------------------------| | 15.1XB | 15.1(1)XB | Vulnerable; first fixed | | | | in 15.1T | +-------------------------------------------------------------------+ Cisco IOS XE Software +-------------------- +-------------------------------------------------------------------+ | Cisco IOS | First Fixed | First Fixed Release for All | | XE | Release for This | Advisories in the September 2010 | | Release | Advisory | Bundle Publication | |-----------+------------------+------------------------------------| | 2.1.x | Not Vulnerable | Not Vulnerable | |-----------+------------------+------------------------------------| | 2.2.x | Not Vulnerable | Not Vulnerable | |-----------+------------------+------------------------------------| | 2.3.x | Not Vulnerable | Not Vulnerable | |-----------+------------------+------------------------------------| | 2.4.x | Not Vulnerable | Not Vulnerable | |-----------+------------------+------------------------------------| | | Vulnerable; | Vulnerable; migrate to 2.6.2 or | | 2.5.x | migrate to 2.6.2 | later | | | or later | | |-----------+------------------+------------------------------------| | 2.6.x | 2.6.1 | 2.6.2 | |-----------+------------------+------------------------------------| | 3.1.xS | Not Vulnerable | Not Vulnerable | +-------------------------------------------------------------------+ For mapping of Cisco IOS XE to Cisco IOS releases, please refer to the Cisco IOS XE 2 and Cisco IOS XE 3S Release Notes. Cisco IOS XR System Software +--------------------------- Cisco IOS XR Software is not affected by the vulnerabilities disclosed in the September 22, 2010, Cisco IOS Software Security Advisory bundled publication. Workarounds =========== If the affected Cisco IOS device requires SIP for VoIP services, SIP cannot be disabled, and no workarounds are available. Users are advised to apply mitigation techniques to help limit exposure to the vulnerabilities. Mitigation consists of allowing only legitimate devices to connect to affected devices. To increase effectiveness, the mitigation must be coupled with anti-spoofing measures on the network edge. This action is required because SIP can use UDP as the transport protocol. Additional mitigations that can be deployed on Cisco devices within the network are available in the companion document "Cisco Applied Mitigation Bulletin:Identifying and Mitigating Exploitation of the Multiple Vulnerabilities in Cisco Voice Products", which is available at the following location: http://www.cisco.com/warp/public/707/cisco-amb-20100922-voice.shtml Disabling SIP Listening Ports +---------------------------- For devices that do not require SIP to be enabled, the simplest and most effective workaround is to disable SIP processing on the device. Some versions of Cisco IOS Software allow administrators to disable SIP with the following commands: sip-ua no transport udp no transport tcp no transport tcp tls warning Warning: When applying this workaround to devices that are processing Media Gateway Control Protocol (MGCP) or H.323 calls, the device will not stop SIP processing while active calls are being processed. Under these circumstances, this workaround should be implemented during a maintenance window when active calls can be briefly stopped. The show udp connections, show tcp brief all, and show processes | include SIP commands can be used to confirm that the SIP UDP and TCP ports are closed after applying this workaround. Depending on the Cisco IOS Software version in use, the output from the show ip sockets command may still show the SIP ports open, but sending traffic to them will cause the SIP process to emit the following message: *Jun 2 11:36:47.691: sip_udp_sock_process_read: SIP UDP Listener is DISABLED Control Plane Policing +--------------------- For devices that need to offer SIP services, it is possible to use Control Plane Policing (CoPP) to block SIP traffic to the device from untrusted sources. Cisco IOS Releases 12.0S, 12.2SX, 12.2S, 12.3T, 12.4, and 12.4T support the CoPP feature. CoPP may be configured on a device to protect the management and control planes to minimize the risk and effectiveness of direct infrastructure attacks by explicitly permitting only authorized traffic sent to infrastructure devices in accordance with existing security policies and configurations. The following example can be adapted to specific network configurations: !-- The 192.168.1.0/24 network and the 172.16.1.1 host are trusted. !-- Everything else is not trusted. The following access list is used !-- to determine what traffic needs to be dropped by a control plane !-- policy (the CoPP feature.) If the access list matches (permit) !-- then traffic will be dropped and if the access list does not !-- match (deny) then traffic will be processed by the router. access-list 100 deny udp 192.168.1.0 0.0.0.255 any eq 5060 access-list 100 deny tcp 192.168.1.0 0.0.0.255 any eq 5060 access-list 100 deny tcp 192.168.1.0 0.0.0.255 any eq 5061 access-list 100 deny udp host 172.16.1.1 any eq 5060 access-list 100 deny tcp host 172.16.1.1 any eq 5060 access-list 100 deny tcp host 172.16.1.1 any eq 5061 access-list 100 permit udp any any eq 5060 access-list 100 permit tcp any any eq 5060 access-list 100 permit tcp any any eq 5061 !-- Permit (Police or Drop)/Deny (Allow) all other Layer3 and Layer4 !-- traffic in accordance with existing security policies and !-- configurations for traffic that is authorized to be sent !-- to infrastructure devices. !-- Create a Class-Map for traffic to be policed by !-- the CoPP feature. class-map match-all drop-sip-class match access-group 100 !-- Create a Policy-Map that will be applied to the !-- Control-Plane of the device. policy-map control-plane-policy class drop-sip-class drop !-- Apply the Policy-Map to the Control-Plane of the !-- device. control-plane service-policy input control-plane-policy Note: Because SIP can use UDP as a transport protocol, it is possible to easily spoof the IP address of the sender, which may defeat access control lists that permit communication to these ports from trusted IP addresses. In the above CoPP example, the access control entries (ACEs) that match the potential exploit packets with the "permit" action result in these packets being discarded by the policy-map "drop" function, while packets that match the "deny" action (not shown) are not affected by the policy-map drop function. Additional information on the configuration and use of the CoPP feature can be found at http://www.cisco.com/web/about/security/intelligence/coppwp_gs.html and http://www.cisco.com/en/US/docs/ios/12_3t/12_3t4/feature/guide/gtrtlimt.html Obtaining Fixed Software ======================== Cisco has released free software updates that address these vulnerabilities. Prior to deploying software, customers should consult their maintenance provider or check the software for feature set compatibility and known issues specific to their environment. Customers may only install and expect support for the feature sets they have purchased. By installing, downloading, accessing or otherwise using such software upgrades, customers agree to be bound by the terms of Cisco's software license terms found at http://www.cisco.com/en/US/docs/general/warranty/English/EU1KEN_.html or as otherwise set forth at Cisco.com Downloads at http://www.cisco.com/public/sw-center/sw-usingswc.shtml Do not contact psirt at cisco.com or security-alert at cisco.com for software upgrades. Customers with Service Contracts +------------------------------- Customers with contracts should obtain upgraded software through their regular update channels. For most customers, this means that upgrades should be obtained through the Software Center on Cisco's worldwide website at http://www.cisco.com Customers using Third Party Support Organizations +------------------------------------------------ Customers whose Cisco products are provided or maintained through prior or existing agreements with third-party support organizations, such as Cisco Partners, authorized resellers, or service providers should contact that support organization for guidance and assistance with the appropriate course of action in regards to this advisory. The effectiveness of any workaround or fix is dependent on specific customer situations, such as product mix, network topology, traffic behavior, and organizational mission. Due to the variety of affected products and releases, customers should consult with their service provider or support organization to ensure any applied workaround or fix is the most appropriate for use in the intended network before it is deployed. Customers without Service Contracts +---------------------------------- Customers who purchase direct from Cisco but do not hold a Cisco service contract, and customers who purchase through third-party vendors but are unsuccessful in obtaining fixed software through their point of sale should acquire upgrades by contacting the Cisco Technical Assistance Center (TAC). TAC contacts are as follows. * +1 800 553 2447 (toll free from within North America) * +1 408 526 7209 (toll call from anywhere in the world) * e-mail: tac at cisco.com Customers should have their product serial number available and be prepared to give the URL of this notice as evidence of entitlement to a free upgrade. Free upgrades for non-contract customers must be requested through the TAC. Refer to http://www.cisco.com/en/US/support/tsd_cisco_worldwide_contacts.html for additional TAC contact information, including localized telephone numbers, and instructions and e-mail addresses for use in various languages. Exploitation and Public Announcements ===================================== The Cisco PSIRT is not aware of any public announcements or malicious use of the vulnerability described in this advisory. These vulnerabilities were discovered by Cisco during internal testing. 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-20100922-sip.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 | 2010-September-22 | 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.10 (Darwin) iEYEARECAAYFAkyZ/SsACgkQ86n/Gc8U/uAExQCePGMUBQypd2bPNr1CbH19j1h3 9WgAn0czHTv1JOH6pJl2Bz4MRrPzokRR =6+8R -----END PGP SIGNATURE----- From joshua.klubi at gmail.com Wed Sep 22 16:11:51 2010 From: joshua.klubi at gmail.com (Joshua William Klubi) Date: Wed, 22 Sep 2010 16:11:51 +0000 Subject: IDS IPS Message-ID: Hi, I have been tasked to get the best IDS and IPS for our internal LAN and WAN in a Banking infrastructure. I would like ask if any one has deployed in any network with such technology, and also if any one can recommend a very good IDS and IPS for me to recommend to management Thank you. Joshua From afisayo at gmail.com Wed Sep 22 16:24:38 2010 From: afisayo at gmail.com (Adefisayo Adegoke) Date: Wed, 22 Sep 2010 10:24:38 -0600 Subject: IDS IPS In-Reply-To: References: Message-ID: ISS .... ideal for the Defense and Banking industry ....... 'Ayo On Wed, Sep 22, 2010 at 10:11 AM, Joshua William Klubi < joshua.klubi at gmail.com> wrote: > Hi, > > I have been tasked to get the best IDS and IPS for our internal LAN and WAN > in a Banking infrastructure. > I would like ask if any one has deployed in any network with such > technology, and also if any one can recommend > a very good IDS and IPS for me to recommend to management > > Thank you. > > Joshua > -- ........... the sky is too low to be my limit. .... Success is getting what you want, happiness is wanting what you get - Ingrid Bergman From joshua.klubi at gmail.com Wed Sep 22 16:29:37 2010 From: joshua.klubi at gmail.com (Joshua William Klubi) Date: Wed, 22 Sep 2010 16:29:37 +0000 Subject: IDS IPS In-Reply-To: References: Message-ID: What is ISS Joshua On Wed, Sep 22, 2010 at 4:24 PM, Adefisayo Adegoke wrote: > ISS .... ideal for the Defense and Banking industry ....... > > 'Ayo > > On Wed, Sep 22, 2010 at 10:11 AM, Joshua William Klubi < > joshua.klubi at gmail.com> wrote: > >> Hi, >> >> I have been tasked to get the best IDS and IPS for our internal LAN and >> WAN >> in a Banking infrastructure. >> I would like ask if any one has deployed in any network with such >> technology, and also if any one can recommend >> a very good IDS and IPS for me to recommend to management >> >> Thank you. >> >> Joshua >> > > > > -- > ........... the sky is too low to be my limit. > > .... Success is getting what you want, happiness is wanting what you get - > Ingrid Bergman > > From chris.hall.list at highwayman.com Wed Sep 22 16:42:22 2010 From: chris.hall.list at highwayman.com (Chris Hall) Date: Wed, 22 Sep 2010 17:42:22 +0100 Subject: FW: Odd BGP AS Path Message-ID: <057801cb5a75$2162fd00$6428f700$@hall.list@highwayman.com> Randy Bush wrote (on Wed 22-Sep-2010 at 16:31 +0100): .... > > Probably a silly question, but can anyone explain to me this: > > 3561 3356 9031 {35821,35821,35821,35821} i I suppose it could be trying to convey the aggregation of four routes from 35821 ? Or perhaps an AS with multiple personality disorder ? Or an aggregator with a sssstaaammer. > please support draft-wkumari-deprecate-as-sets-00.txt It seems to me that this is really deprecating the aggregation of routes by BGP, except where the result is an existing less specific route ? That obviously means that AS_SET would not be necessary, but as an effect rather than the cause. One could also dump the AGGREGATOR and the AS4_AGGREGATOR attributes in the nearest waste bin. AND it would simplify the merging of AS_PATH and AS4_PATH attributes, which is a complete dogs breakfast... because it tries, in vain, to finesse its way out of the problem of an AS2 speaker aggregating routes with AS4_PATHs ! [Made even more galling by the sure and certain knowledge that aggregated routes are as exquisitely rare as they are useful.] And what about the truly, madly, deeply useless AS_CONFED_SET ? [A carbuncle's carbuncle if ever I saw one.] Vote early and vote often, say I. Chris From frederic at placenet.org Wed Sep 22 16:44:55 2010 From: frederic at placenet.org (=?UTF-8?B?RnLDqWRlcmlj?=) Date: Wed, 22 Sep 2010 18:44:55 +0200 Subject: IDS IPS In-Reply-To: References: Message-ID: <4C9A3287.3030504@placenet.org> http://en.lmgtfy.com/?q=ips+iss bst rgds Le 22/09/2010 18:29, Joshua William Klubi a ?crit : > What is ISS > > Joshua > > On Wed, Sep 22, 2010 at 4:24 PM, Adefisayo Adegoke wrote: > >> ISS .... ideal for the Defense and Banking industry ....... >> >> 'Ayo >> >> On Wed, Sep 22, 2010 at 10:11 AM, Joshua William Klubi < >> joshua.klubi at gmail.com> wrote: >> >>> Hi, >>> >>> I have been tasked to get the best IDS and IPS for our internal LAN and >>> WAN >>> in a Banking infrastructure. >>> I would like ask if any one has deployed in any network with such >>> technology, and also if any one can recommend >>> a very good IDS and IPS for me to recommend to management >>> >>> Thank you. >>> >>> Joshua >>> >> >> >> >> -- >> ........... the sky is too low to be my limit. >> >> .... Success is getting what you want, happiness is wanting what you get - >> Ingrid Bergman >> >> > From psirt at cisco.com Wed Sep 22 16:00:00 2010 From: psirt at cisco.com (Cisco Systems Product Security Incident Response Team) Date: Wed, 22 Sep 2010 18:00:00 +0200 Subject: Cisco Security Advisory: Cisco IOS Software Internet Group Management Protocol Denial of Service Vulnerability Message-ID: <201009221801.igmp@psirt.cisco.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Cisco Security Advisory: Cisco IOS Software Internet Group Management Protocol Denial of Service Vulnerability Advisory ID: cisco-sa-20100922-igmp http://www.cisco.com/warp/public/707/cisco-sa-20100922-igmp.shtml Revision 1.0 For Public Release 2010 September 22 1600 UTC (GMT) - --------------------------------------------------------------------- Summary ======= A vulnerability in the Internet Group Management Protocol (IGMP) version 3 implementation of Cisco IOS Software and Cisco IOS XE Software allows a remote unauthenticated attacker to cause a reload of an affected device. Repeated attempts to exploit this vulnerability could result in a sustained denial of service (DoS) condition. Cisco has released free software updates that address this vulnerability. This advisory is posted at http://www.cisco.com/warp/public/707/cisco-sa-20100922-igmp.shtml Note: The September 22, 2010, Cisco IOS Software Security Advisory bundled publication includes six Cisco Security Advisories. Five of the advisories address vulnerabilities in Cisco IOS Software, and one advisory addresses vulnerabilities in Cisco Unified Communications Manager. Each advisory lists the releases that correct the vulnerability or vulnerabilities detailed in the advisory. The table at the following URL lists releases that correct all Cisco IOS Software vulnerabilities that have been published on September 22, 2010, or earlier: http://www.cisco.com/warp/public/707/cisco-sa-20100922-bundle.shtml Individual publication links are in "Cisco Event Response: Semiannual Cisco IOS Software Security Advisory Bundled Publication" at the following link: http://www.cisco.com/web/about/security/intelligence/Cisco_ERP_sep10.html Affected Products ================= Vulnerable Products +------------------ The following products are affected by this vulnerability: * Cisco IOS Software * Cisco IOS XE Software To determine the Cisco IOS Software release that is running on a Cisco product, administrators can log in to the device and issue the show version command to display the system banner. The system banner confirms that the device is running Cisco IOS Software by displaying text similar to "Cisco Internetwork Operating System Software" or "Cisco IOS Software." The image name displays in parentheses, followed by "Version" and the Cisco IOS Software release name. Other Cisco devices do not have the show version command or may provide different output. The following example identifies a Cisco product that is running Cisco IOS Software Release 12.4(20)T with an installed image name of C1841-ADVENTERPRISEK9-M: Router#show version Cisco IOS Software, 1841 Software (C1841-ADVENTERPRISEK9-M), Version 12.4(20)T, RELEASE SOFTWARE (fc3) Technical Support: http://www.cisco.com/techsupport Copyright (c) 1986-2008 by Cisco Systems, Inc. Compiled Thu 10-Jul-08 20:25 by prod_rel_team Additional information about Cisco IOS Software release naming conventions is available in White Paper: Cisco IOS and NX-OS Software Reference Guide. Products Confirmed Not Vulnerable +-------------------------------- No other Cisco products are currently known to be affected by this vulnerability. Cisco IOS XR Software is not affected by this vulnerability. The IGMP version 1, IGMP version 2, and IPv6 Multicast Listener Discovery protocol (MLD) features in Cisco IOS and Cisco IOS XE Software are not affected by this vulnerability. Details ======= Internet Group Management Protocol (IGMP) is the protocol used by hosts and adjacent routers to manage membership in IP multicast groups. The IGMP version 3 protocol permits source-specific multicast which allows hosts to specify the IP address of the multicast source. A malformed IGMP packet can cause a vulnerable device to reload. This vulnerability can only be exploited if the malformed IGMP packet is received on an interface that has been enabled for IGMP version 3 and Protocol Independent Multicast (PIM). The malformed IGMP packet destination address can be unicast, multicast, or broadcast and can be addressed to any IP address in the vulnerable device, including loopback addresses. To exploit this vulnerability, a malformed packet must be received on a vulnerable interface, but it can be addressed to any IP address on the vulnerable device. Transit traffic will not trigger this vulnerability. A vulnerable interface configuration requires the PIM mode of operation (sparse-dense, sparse, or dense) to be configured in addition to the ip igmp version 3 command. The three possible configurations that permit exploitation of this vulnerability are: !--- Interface configured for PIM sparse and IGMPv3 interface GigabitEthernet0/0 ip address 192.168.0.1 255.255.255.0 ip pim sparse-mode ip igmp version 3 !--- Interface configured for PIM sparse-dense and IGMPv3 interface GigabitEthernet0/1 ip address 192.168.1.1 255.255.255.0 ip pim sparse-dense-mode ip igmp version 3 !--- Interface configured for PIM dense and IGMPv3 interface GigabitEthernet0/2 ip address 192.168.2.1 255.255.255.0 ip pim dense-mode ip igmp version 3 The IGMP version 3 lite feature is unrelated to this vulnerability, in that the presence or absence of the ip igmp v3lite command on an interface does not change the vulnerable condition of that interface. The IP router alert option may or may not be present in packets attempting to exploit the vulnerability described in this document. This vulnerability is documented in Cisco bug ID CSCte14603 ( registered customers only) . This vulnerability has been assigned Common Vulnerabilities and Exposures (CVE) ID CVE-2010-2830. 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 CSCte14603 - IGMPv3 DoS Vulnerability CVSS Base Score - 7.1 Access Vector Network Access Complexity Medium Authentication None Confidentiality Impact None Integrity Impact None Availability Impact Complete CVSS Temporal Score - 5.9 Exploitability Functional Remediation Level Official Fix Report Confidence Confirmed Impact ====== Successful exploitation of this vulnerability may cause the affected device vulnerable device to reload. Repeated exploitation may result in a sustained DoS condition. Software Versions and Fixes =========================== When considering software upgrades, also consult http://www.cisco.com/go/psirt and any subsequent advisories to determine exposure and a complete upgrade solution. In all cases, customers should exercise caution to be certain the devices to be upgraded contain sufficient memory and that current hardware and software configurations will continue to be supported properly by the new release. If the information is not clear, contact the Cisco Technical Assistance Center (TAC) or your contracted maintenance provider for assistance. Each row of the following Cisco IOS Software table corresponds to a Cisco IOS Software train. If a particular train is vulnerable, the earliest releases that contain the fix are listed in the First Fixed Release For This Advisory column. The First Fixed Release for All Advisories in the September 2010 Bundle Publication column lists the earliest possible releases that correct all the published vulnerabilities in the Cisco IOS Software Security Advisory bundled publication. Cisco recommends upgrading to the latest available release, where possible. +-------------------------------------------------------------------+ | Major | Availability of Repaired Releases | | Release | | |------------+------------------------------------------------------| | Affected | | First Fixed Release for | | 12.0-Based | First Fixed Release for | All Advisories in the | | Releases | This Advisory | September 2010 Bundle | | | | Publication | |-------------------------------------------------------------------| | There are no affected 12.0 based releases | |-------------------------------------------------------------------| | Affected | | First Fixed Release for | | 12.1-Based | First Fixed Release for | All Advisories in the | | Releases | This Advisory | September 2010 Bundle | | | | Publication | |-------------------------------------------------------------------| | There are no affected 12.1 based releases | |-------------------------------------------------------------------| | Affected | | First Fixed Release for | | 12.2-Based | First Fixed Release for | All Advisories in the | | Releases | This Advisory | September 2010 Bundle | | | | Publication | |------------+--------------------------+---------------------------| | 12.2 | Not Vulnerable | Vulnerable; first fixed | | | | in 12.4T | |------------+--------------------------+---------------------------| | | | Vulnerable; first fixed | | | | in 12.4T | | 12.2B | Not Vulnerable | | | | | Releases up to and | | | | including 12.2(2)B7 are | | | | not vulnerable. | |------------+--------------------------+---------------------------| | 12.2BC | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | 12.2BW | Not Vulnerable | Vulnerable; first fixed | | | | in 12.4T | |------------+--------------------------+---------------------------| | | | Vulnerable; first fixed | | | | in 12.2SB | | 12.2BX | Not Vulnerable | | | | | Releases up to and | | | | including 12.2(15)BX are | | | | not vulnerable. | |------------+--------------------------+---------------------------| | | | Vulnerable; first fixed | | | | in 12.4T | | 12.2BY | Not Vulnerable | | | | | Releases up to and | | | | including 12.2(2)BY3 are | | | | not vulnerable. | |------------+--------------------------+---------------------------| | 12.2BZ | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | 12.2CX | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | 12.2CY | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | | | Vulnerable; Contact your | | | | support organization per | | 12.2CZ | Not Vulnerable | the instructions in | | | | Obtaining Fixed Software | | | | section of this advisory | |------------+--------------------------+---------------------------| | 12.2DA | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | 12.2DD | Not Vulnerable | Vulnerable; first fixed | | | | in 12.4T | |------------+--------------------------+---------------------------| | 12.2DX | Not Vulnerable | Vulnerable; first fixed | | | | in 12.4T | |------------+--------------------------+---------------------------| | 12.2EW | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | 12.2EWA | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | 12.2EX | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | 12.2EY | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | 12.2EZ | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | 12.2FX | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | 12.2FY | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | 12.2FZ | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | | | Vulnerable; Contact your | | | | support organization per | | 12.2IRA | Not Vulnerable | the instructions in | | | | Obtaining Fixed Software | | | | section of this advisory | |------------+--------------------------+---------------------------| | | | Vulnerable; Contact your | | | | support organization per | | 12.2IRB | Not Vulnerable | the instructions in | | | | Obtaining Fixed Software | | | | section of this advisory | |------------+--------------------------+---------------------------| | | | Vulnerable; Contact your | | | | support organization per | | 12.2IRC | Not Vulnerable | the instructions in | | | | Obtaining Fixed Software | | | | section of this advisory | |------------+--------------------------+---------------------------| | | | Vulnerable; Contact your | | | | support organization per | | 12.2IRD | Not Vulnerable | the instructions in | | | | Obtaining Fixed Software | | | | section of this advisory | |------------+--------------------------+---------------------------| | | | Vulnerable; Contact your | | | | support organization per | | 12.2IRE | Not Vulnerable | the instructions in | | | | Obtaining Fixed Software | | | | section of this advisory | |------------+--------------------------+---------------------------| | | | Vulnerable; Contact your | | | | support organization per | | 12.2IXA | Not Vulnerable | the instructions in | | | | Obtaining Fixed Software | | | | section of this advisory | |------------+--------------------------+---------------------------| | | | Vulnerable; Contact your | | | | support organization per | | 12.2IXB | Not Vulnerable | the instructions in | | | | Obtaining Fixed Software | | | | section of this advisory | |------------+--------------------------+---------------------------| | | | Vulnerable; Contact your | | | | support organization per | | 12.2IXC | Not Vulnerable | the instructions in | | | | Obtaining Fixed Software | | | | section of this advisory | |------------+--------------------------+---------------------------| | | | Vulnerable; Contact your | | | | support organization per | | 12.2IXD | Not Vulnerable | the instructions in | | | | Obtaining Fixed Software | | | | section of this advisory | |------------+--------------------------+---------------------------| | | | Vulnerable; Contact your | | | | support organization per | | 12.2IXE | Not Vulnerable | the instructions in | | | | Obtaining Fixed Software | | | | section of this advisory | |------------+--------------------------+---------------------------| | | | Vulnerable; Contact your | | | | support organization per | | 12.2IXF | Not Vulnerable | the instructions in | | | | Obtaining Fixed Software | | | | section of this advisory | |------------+--------------------------+---------------------------| | | | Vulnerable; Contact your | | | | support organization per | | 12.2IXG | Not Vulnerable | the instructions in | | | | Obtaining Fixed Software | | | | section of this advisory | |------------+--------------------------+---------------------------| | | | Vulnerable; Contact your | | | | support organization per | | 12.2IXH | Not Vulnerable | the instructions in | | | | Obtaining Fixed Software | | | | section of this advisory | |------------+--------------------------+---------------------------| | 12.2JA | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | 12.2JK | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | 12.2MB | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | | | Releases up to and | | | | including 12.2(15)MC1 are | | 12.2MC | Not Vulnerable | not vulnerable. Releases | | | | 12.2(15)MC2b and later | | | | are not vulnerable; first | | | | fixed in 12.4T | |------------+--------------------------+---------------------------| | | | Vulnerable; Contact your | | | | support organization per | | 12.2MRA | Not Vulnerable | the instructions in | | | | Obtaining Fixed Software | | | | section of this advisory | |------------+--------------------------+---------------------------| | 12.2MRB | Not Vulnerable | 12.2(33)MRB2 | |------------+--------------------------+---------------------------| | | | Releases prior to 12.2 | | 12.2S | Not Vulnerable | (30)S are vulnerable, | | | | release 12.2(30)S and | | | | later are not vulnerable | |------------+--------------------------+---------------------------| | | | 12.2(31)SB19; Releases | | | | prior to 12.2(33)SB5 are | | 12.2SB | Not Vulnerable | vulnerable, release 12.2 | | | | (33)SB5 and later are not | | | | vulnerable | |------------+--------------------------+---------------------------| | 12.2SBC | Not Vulnerable | Vulnerable; first fixed | | | | in 12.2SB | |------------+--------------------------+---------------------------| | 12.2SCA | Not Vulnerable | Vulnerable; first fixed | | | | in 12.2SCB | |------------+--------------------------+---------------------------| | 12.2SCB | Not Vulnerable | 12.2(33)SCB9 | |------------+--------------------------+---------------------------| | 12.2SCC | Not Vulnerable | 12.2(33)SCC5 | |------------+--------------------------+---------------------------| | 12.2SCD | Not Vulnerable | 12.2(33)SCD3 | |------------+--------------------------+---------------------------| | 12.2SE | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | 12.2SEA | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | 12.2SEB | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | 12.2SEC | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | 12.2SED | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | 12.2SEE | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | 12.2SEF | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | 12.2SEG | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | | | Releases prior to 12.2 | | | | (40)SG are vulnerable, | | 12.2SG | Not Vulnerable | release 12.2(40)SG and | | | | later are not vulnerable; | | | | migrate to any release in | | | | 12.2SGA | |------------+--------------------------+---------------------------| | 12.2SGA | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | 12.2SL | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | 12.2SM | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | 12.2SO | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | 12.2SQ | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | | | Releases prior to 12.2 | | 12.2SRA | Not Vulnerable | (33)SRA6 are vulnerable, | | | | release 12.2(33)SRA6 and | | | | later are not vulnerable | |------------+--------------------------+---------------------------| | | | Releases prior to 12.2 | | 12.2SRB | Not Vulnerable | (33)SRB1 are vulnerable, | | | | release 12.2(33)SRB1 and | | | | later are not vulnerable | |------------+--------------------------+---------------------------| | 12.2SRC | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | 12.2SRD | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | 12.2SRE | 12.2(33)SRE1 | 12.2(33)SRE1 | |------------+--------------------------+---------------------------| | 12.2STE | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | 12.2SU | Not Vulnerable | Vulnerable; first fixed | | | | in 12.4T | |------------+--------------------------+---------------------------| | | | Releases prior to 12.2 | | | | (29b)SV1 are vulnerable, | | 12.2SV | Not Vulnerable | release 12.2(29b)SV1 and | | | | later are not vulnerable; | | | | migrate to any release in | | | | 12.2SVD | |------------+--------------------------+---------------------------| | 12.2SVA | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | 12.2SVC | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | 12.2SVD | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | 12.2SVE | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | | | Releases up to and | | | | including 12.2(21)SW1 are | | 12.2SW | Not Vulnerable | not vulnerable. Releases | | | | 12.2(25)SW12 and later | | | | are not vulnerable; first | | | | fixed in 12.4T | |------------+--------------------------+---------------------------| | | | Releases up to and | | 12.2SX | Not Vulnerable | including 12.2(14)SX2 are | | | | not vulnerable. | |------------+--------------------------+---------------------------| | | | Vulnerable; Contact your | | | | support organization per | | 12.2SXA | Not Vulnerable | the instructions in | | | | Obtaining Fixed Software | | | | section of this advisory | |------------+--------------------------+---------------------------| | | | Vulnerable; Contact your | | | | support organization per | | 12.2SXB | Not Vulnerable | the instructions in | | | | Obtaining Fixed Software | | | | section of this advisory | |------------+--------------------------+---------------------------| | | | Vulnerable; Contact your | | | | support organization per | | 12.2SXD | Not Vulnerable | the instructions in | | | | Obtaining Fixed Software | | | | section of this advisory | |------------+--------------------------+---------------------------| | | | Vulnerable; Contact your | | | | support organization per | | 12.2SXE | Not Vulnerable | the instructions in | | | | Obtaining Fixed Software | | | | section of this advisory | |------------+--------------------------+---------------------------| | | | Releases prior to 12.2 | | | | (18)SXF11 are vulnerable, | | 12.2SXF | Not Vulnerable | releases 12.2(18)SXF11 | | | | and later are not | | | | vulnerable | |------------+--------------------------+---------------------------| | 12.2SXH | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | 12.2SXI | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | 12.2SY | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | | | Vulnerable; Contact your | | | | support organization per | | 12.2SZ | Not Vulnerable | the instructions in | | | | Obtaining Fixed Software | | | | section of this advisory | |------------+--------------------------+---------------------------| | 12.2T | Not Vulnerable | Vulnerable; first fixed | | | | in 12.4T | |------------+--------------------------+---------------------------| | | | Vulnerable; Contact your | | | | support organization per | | 12.2TPC | Not Vulnerable | the instructions in | | | | Obtaining Fixed Software | | | | section of this advisory | |------------+--------------------------+---------------------------| | 12.2XA | Not Vulnerable | Vulnerable; first fixed | | | | in 12.4T | |------------+--------------------------+---------------------------| | 12.2XB | Not Vulnerable | Vulnerable; first fixed | | | | in 12.4T | |------------+--------------------------+---------------------------| | 12.2XC | Not Vulnerable | Vulnerable; first fixed | | | | in 12.4T | |------------+--------------------------+---------------------------| | 12.2XD | Not Vulnerable | Vulnerable; first fixed | | | | in 12.4T | |------------+--------------------------+---------------------------| | 12.2XE | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | 12.2XF | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | 12.2XG | Not Vulnerable | Vulnerable; first fixed | | | | in 12.4T | |------------+--------------------------+---------------------------| | 12.2XH | Not Vulnerable | Vulnerable; first fixed | | | | in 12.4T | |------------+--------------------------+---------------------------| | 12.2XI | Not Vulnerable | Vulnerable; first fixed | | | | in 12.4T | |------------+--------------------------+---------------------------| | 12.2XJ | Not Vulnerable | Vulnerable; first fixed | | | | in 12.4T | |------------+--------------------------+---------------------------| | 12.2XK | Not Vulnerable | Vulnerable; first fixed | | | | in 12.4T | |------------+--------------------------+---------------------------| | 12.2XL | Not Vulnerable | Vulnerable; first fixed | | | | in 12.4T | |------------+--------------------------+---------------------------| | 12.2XM | Not Vulnerable | Vulnerable; first fixed | | | | in 12.4T | |------------+--------------------------+---------------------------| | 12.2XN | Not Vulnerable | Vulnerable; first fixed | | | | in 12.2SB | |------------+--------------------------+---------------------------| | 12.2XNA | Please see Cisco IOS-XE | Please see Cisco IOS-XE | | | Software Availability | Software Availability | |------------+--------------------------+---------------------------| | 12.2XNB | Please see Cisco IOS-XE | Please see Cisco IOS-XE | | | Software Availability | Software Availability | |------------+--------------------------+---------------------------| | 12.2XNC | Please see Cisco IOS-XE | Please see Cisco IOS-XE | | | Software Availability | Software Availability | |------------+--------------------------+---------------------------| | 12.2XND | Please see Cisco IOS-XE | Please see Cisco IOS-XE | | | Software Availability | Software Availability | |------------+--------------------------+---------------------------| | 12.2XNE | Please see Cisco IOS-XE | Please see Cisco IOS-XE | | | Software Availability | Software Availability | |------------+--------------------------+---------------------------| | 12.2XNF | Please see Cisco IOS-XE | Please see Cisco IOS-XE | | | Software Availability | Software Availability | |------------+--------------------------+---------------------------| | 12.2XO | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | 12.2XQ | Not Vulnerable | Vulnerable; first fixed | | | | in 12.4T | |------------+--------------------------+---------------------------| | 12.2XR | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | 12.2XS | Not Vulnerable | Vulnerable; first fixed | | | | in 12.4T | |------------+--------------------------+---------------------------| | 12.2XT | Not Vulnerable | Vulnerable; first fixed | | | | in 12.4T | |------------+--------------------------+---------------------------| | 12.2XU | Not Vulnerable | Vulnerable; first fixed | | | | in 12.4T | |------------+--------------------------+---------------------------| | 12.2XV | Not Vulnerable | Vulnerable; first fixed | | | | in 12.4T | |------------+--------------------------+---------------------------| | 12.2XW | Not Vulnerable | Vulnerable; first fixed | | | | in 12.4T | |------------+--------------------------+---------------------------| | 12.2YA | Not Vulnerable | Vulnerable; first fixed | | | | in 12.4T | |------------+--------------------------+---------------------------| | | | Vulnerable; Contact your | | | | support organization per | | 12.2YB | Not Vulnerable | the instructions in | | | | Obtaining Fixed Software | | | | section of this advisory | |------------+--------------------------+---------------------------| | | | Vulnerable; Contact your | | | | support organization per | | 12.2YC | Not Vulnerable | the instructions in | | | | Obtaining Fixed Software | | | | section of this advisory | |------------+--------------------------+---------------------------| | | | Vulnerable; Contact your | | | | support organization per | | 12.2YD | Not Vulnerable | the instructions in | | | | Obtaining Fixed Software | | | | section of this advisory | |------------+--------------------------+---------------------------| | | | Vulnerable; Contact your | | | | support organization per | | 12.2YE | Not Vulnerable | the instructions in | | | | Obtaining Fixed Software | | | | section of this advisory | |------------+--------------------------+---------------------------| | | | Vulnerable; Contact your | | | | support organization per | | 12.2YF | Not Vulnerable | the instructions in | | | | Obtaining Fixed Software | | | | section of this advisory | |------------+--------------------------+---------------------------| | 12.2YG | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | | | Vulnerable; Contact your | | | | support organization per | | 12.2YH | Not Vulnerable | the instructions in | | | | Obtaining Fixed Software | | | | section of this advisory | |------------+--------------------------+---------------------------| | | | Vulnerable; Contact your | | | | support organization per | | 12.2YJ | Not Vulnerable | the instructions in | | | | Obtaining Fixed Software | | | | section of this advisory | |------------+--------------------------+---------------------------| | | | Vulnerable; Contact your | | | | support organization per | | 12.2YK | Not Vulnerable | the instructions in | | | | Obtaining Fixed Software | | | | section of this advisory | |------------+--------------------------+---------------------------| | | | Vulnerable; Contact your | | | | support organization per | | 12.2YL | Not Vulnerable | the instructions in | | | | Obtaining Fixed Software | | | | section of this advisory | |------------+--------------------------+---------------------------| | 12.2YM | Not Vulnerable | Vulnerable; first fixed | | | | in 12.4T | |------------+--------------------------+---------------------------| | | | Vulnerable; Contact your | | | | support organization per | | 12.2YN | Not Vulnerable | the instructions in | | | | Obtaining Fixed Software | | | | section of this advisory | |------------+--------------------------+---------------------------| | 12.2YO | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | 12.2YP | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | 12.2YQ | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | 12.2YR | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | 12.2YS | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | | | Vulnerable; Contact your | | | | support organization per | | 12.2YT | Not Vulnerable | the instructions in | | | | Obtaining Fixed Software | | | | section of this advisory | |------------+--------------------------+---------------------------| | | | Vulnerable; Contact your | | | | support organization per | | 12.2YU | Not Vulnerable | the instructions in | | | | Obtaining Fixed Software | | | | section of this advisory | |------------+--------------------------+---------------------------| | | | Releases prior to 12.2 | | 12.2YV | Not Vulnerable | (11)YV1 are vulnerable, | | | | release 12.2(11)YV1 and | | | | later are not vulnerable | |------------+--------------------------+---------------------------| | | | Vulnerable; Contact your | | | | support organization per | | 12.2YW | Not Vulnerable | the instructions in | | | | Obtaining Fixed Software | | | | section of this advisory | |------------+--------------------------+---------------------------| | | | Vulnerable; Contact your | | | | support organization per | | 12.2YX | Not Vulnerable | the instructions in | | | | Obtaining Fixed Software | | | | section of this advisory | |------------+--------------------------+---------------------------| | | | Vulnerable; Contact your | | | | support organization per | | 12.2YY | Not Vulnerable | the instructions in | | | | Obtaining Fixed Software | | | | section of this advisory | |------------+--------------------------+---------------------------| | | | Vulnerable; Contact your | | | | support organization per | | 12.2YZ | Not Vulnerable | the instructions in | | | | Obtaining Fixed Software | | | | section of this advisory | |------------+--------------------------+---------------------------| | 12.2ZA | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | | | Releases up to and | | 12.2ZB | Not Vulnerable | including 12.2(8)ZB are | | | | not vulnerable. | |------------+--------------------------+---------------------------| | | | Vulnerable; Contact your | | | | support organization per | | 12.2ZC | Not Vulnerable | the instructions in | | | | Obtaining Fixed Software | | | | section of this advisory | |------------+--------------------------+---------------------------| | | | Vulnerable; Contact your | | | | support organization per | | 12.2ZD | Not Vulnerable | the instructions in | | | | Obtaining Fixed Software | | | | section of this advisory | |------------+--------------------------+---------------------------| | 12.2ZE | Not Vulnerable | Vulnerable; first fixed | | | | in 12.4T | |------------+--------------------------+---------------------------| | 12.2ZF | Not Vulnerable | Vulnerable; first fixed | | | | in 12.4T | |------------+--------------------------+---------------------------| | 12.2ZG | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | 12.2ZH | Not Vulnerable | Vulnerable; first fixed | | | | in 12.4T | |------------+--------------------------+---------------------------| | | | Vulnerable; Contact your | | | | support organization per | | 12.2ZJ | Not Vulnerable | the instructions in | | | | Obtaining Fixed Software | | | | section of this advisory | |------------+--------------------------+---------------------------| | | | Vulnerable; Contact your | | | | support organization per | | 12.2ZL | Not Vulnerable | the instructions in | | | | Obtaining Fixed Software | | | | section of this advisory | |------------+--------------------------+---------------------------| | | | Vulnerable; Contact your | | | | support organization per | | 12.2ZP | Not Vulnerable | the instructions in | | | | Obtaining Fixed Software | | | | section of this advisory | |------------+--------------------------+---------------------------| | | | Vulnerable; Contact your | | | | support organization per | | 12.2ZU | Not Vulnerable | the instructions in | | | | Obtaining Fixed Software | | | | section of this advisory | |------------+--------------------------+---------------------------| | 12.2ZX | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | | | Vulnerable; Contact your | | | | support organization per | | 12.2ZY | Not Vulnerable | the instructions in | | | | Obtaining Fixed Software | | | | section of this advisory | |------------+--------------------------+---------------------------| | | | Vulnerable; Contact your | | | | support organization per | | 12.2ZYA | Not Vulnerable | the instructions in | | | | Obtaining Fixed Software | | | | section of this advisory | |------------+--------------------------+---------------------------| | Affected | | First Fixed Release for | | 12.3-Based | First Fixed Release for | All Advisories in the | | Releases | This Advisory | September 2010 Bundle | | | | Publication | |------------+--------------------------+---------------------------| | 12.3 | Not Vulnerable | Vulnerable; first fixed | | | | in 12.4T | |------------+--------------------------+---------------------------| | 12.3B | Not Vulnerable | Vulnerable; first fixed | | | | in 12.4T | |------------+--------------------------+---------------------------| | 12.3BC | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | 12.3BW | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | 12.3EU | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | 12.3JA | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | 12.3JEA | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | 12.3JEB | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | 12.3JEC | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | 12.3JED | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | | | Releases up to and | | | | including 12.3(2)JK3 are | | 12.3JK | Not Vulnerable | not vulnerable. Releases | | | | 12.3(8)JK1 and later are | | | | not vulnerable; first | | | | fixed in 12.4T | |------------+--------------------------+---------------------------| | 12.3JL | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | 12.3JX | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | | Vulnerable; first fixed | | | | in 12.4 | | | 12.3T | | Vulnerable; first fixed | | | Releases up to and | in 12.4T | | | including 12.3(11)T11 | | | | are not vulnerable. | | |------------+--------------------------+---------------------------| | | | Vulnerable; Contact your | | | | support organization per | | 12.3TPC | Not Vulnerable | the instructions in | | | | Obtaining Fixed Software | | | | section of this advisory | |------------+--------------------------+---------------------------| | 12.3VA | Not Vulnerable | Vulnerable; first fixed | | | | in 12.4T | |------------+--------------------------+---------------------------| | 12.3XA | Not Vulnerable | Vulnerable; first fixed | | | | in 12.4T | |------------+--------------------------+---------------------------| | | | Vulnerable; Contact your | | | | support organization per | | 12.3XB | Not Vulnerable | the instructions in | | | | Obtaining Fixed Software | | | | section of this advisory | |------------+--------------------------+---------------------------| | 12.3XC | Not Vulnerable | Vulnerable; first fixed | | | | in 12.4T | |------------+--------------------------+---------------------------| | 12.3XD | Not Vulnerable | Vulnerable; first fixed | | | | in 12.4T | |------------+--------------------------+---------------------------| | 12.3XE | Not Vulnerable | Vulnerable; first fixed | | | | in 12.4T | |------------+--------------------------+---------------------------| | | | Vulnerable; Contact your | | | | support organization per | | 12.3XF | Not Vulnerable | the instructions in | | | | Obtaining Fixed Software | | | | section of this advisory | |------------+--------------------------+---------------------------| | 12.3XG | Not Vulnerable | Vulnerable; first fixed | | | | in 12.4T | |------------+--------------------------+---------------------------| | | | Releases prior to 12.3(7) | | | | XI11 are vulnerable, | | 12.3XI | Not Vulnerable | release 12.3(7)XI11 and | | | | later are not vulnerable; | | | | first fixed in 12.2SB | |------------+--------------------------+---------------------------| | 12.3XJ | Not Vulnerable | Vulnerable; first fixed | | | | in 12.4XR | |------------+--------------------------+---------------------------| | 12.3XK | Not Vulnerable | Vulnerable; first fixed | | | | in 12.4T | |------------+--------------------------+---------------------------| | 12.3XL | Not Vulnerable | Vulnerable; first fixed | | | | in 12.4T | |------------+--------------------------+---------------------------| | 12.3XQ | Not Vulnerable | Vulnerable; first fixed | | | | in 12.4T | |------------+--------------------------+---------------------------| | 12.3XR | Not Vulnerable | Vulnerable; first fixed | | | | in 12.4T | |------------+--------------------------+---------------------------| | 12.3XS | Not Vulnerable | Vulnerable; first fixed | | | | in 12.4T | |------------+--------------------------+---------------------------| | 12.3XU | Not Vulnerable | Vulnerable; first fixed | | | | in 12.4T | |------------+--------------------------+---------------------------| | 12.3XW | Not Vulnerable | Vulnerable; first fixed | | | | in 12.4T | |------------+--------------------------+---------------------------| | 12.3XX | Not Vulnerable | Vulnerable; first fixed | | | | in 12.4T | |------------+--------------------------+---------------------------| | 12.3XY | Not Vulnerable | Vulnerable; first fixed | | | | in 12.4T | |------------+--------------------------+---------------------------| | 12.3XZ | Not Vulnerable | Vulnerable; first fixed | | | | in 12.4T | |------------+--------------------------+---------------------------| | 12.3YA | Not Vulnerable | Vulnerable; first fixed | | | | in 12.4T | |------------+--------------------------+---------------------------| | 12.3YD | Not Vulnerable | Vulnerable; first fixed | | | | in 12.4T | |------------+--------------------------+---------------------------| | 12.3YF | Not Vulnerable | Vulnerable; first fixed | | | | in 12.4XR | |------------+--------------------------+---------------------------| | 12.3YG | Not Vulnerable | Vulnerable; first fixed | | | | in 12.4T | |------------+--------------------------+---------------------------| | 12.3YH | Not Vulnerable | Vulnerable; first fixed | | | | in 12.4T | |------------+--------------------------+---------------------------| | 12.3YI | Not Vulnerable | Vulnerable; first fixed | | | | in 12.4T | |------------+--------------------------+---------------------------| | 12.3YJ | Not Vulnerable | Vulnerable; first fixed | | | | in 12.4T | |------------+--------------------------+---------------------------| | 12.3YK | Vulnerable; first fixed | Vulnerable; first fixed | | | in 12.4T | in 12.4T | |------------+--------------------------+---------------------------| | 12.3YM | Vulnerable; first fixed | Vulnerable; first fixed | | | in 12.4T | in 12.4T | |------------+--------------------------+---------------------------| | 12.3YQ | Vulnerable; first fixed | Vulnerable; first fixed | | | in 12.4T | in 12.4T | |------------+--------------------------+---------------------------| | 12.3YS | Vulnerable; first fixed | Vulnerable; first fixed | | | in 12.4T | in 12.4T | |------------+--------------------------+---------------------------| | 12.3YT | Vulnerable; first fixed | Vulnerable; first fixed | | | in 12.4T | in 12.4T | |------------+--------------------------+---------------------------| | 12.3YU | Vulnerable; first fixed | Vulnerable; first fixed | | | in 12.4T | in 12.4T | |------------+--------------------------+---------------------------| | 12.3YX | 12.3(14)YX17 | Vulnerable; first fixed | | | | in 12.4XR | |------------+--------------------------+---------------------------| | | | Vulnerable; Contact your | | | | support organization per | | 12.3YZ | Not Vulnerable | the instructions in | | | | Obtaining Fixed Software | | | | section of this advisory | |------------+--------------------------+---------------------------| | 12.3ZA | Not Vulnerable | Vulnerable; first fixed | | | | in 12.4T | |------------+--------------------------+---------------------------| | Affected | | First Fixed Release for | | 12.4-Based | First Fixed Release for | All Advisories in the | | Releases | This Advisory | September 2010 Bundle | | | | Publication | |------------+--------------------------+---------------------------| | 12.4 | 12.4(25d) | 12.4(25d) | |------------+--------------------------+---------------------------| | 12.4GC | 12.4(24)GC2 | 12.4(24)GC2 | |------------+--------------------------+---------------------------| | 12.4JA | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | 12.4JDA | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | 12.4JDC | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | 12.4JDD | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | 12.4JHA | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | 12.4JHB | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | 12.4JK | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | 12.4JL | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | 12.4JMA | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | 12.4JMB | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | 12.4JX | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | 12.4JY | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | 12.4MD | 12.4(24)MD2 | 12.4(24)MD2 | |------------+--------------------------+---------------------------| | | 12.4(24)MDA1 | | | 12.4MDA | | 12.4(22)MDA4 | | | 12.4(22)MDA4 | | |------------+--------------------------+---------------------------| | 12.4MR | Vulnerable; first fixed | Vulnerable; first fixed | | | in 12.4MRA | in 12.4MRA | |------------+--------------------------+---------------------------| | 12.4MRA | 12.4(20)MRA1 | 12.4(20)MRA1 | |------------+--------------------------+---------------------------| | | Releases prior to 12.4 | | | | (15)SW6 are vulnerable, | | | 12.4SW | release 12.4(15)SW6 and | Vulnerable; first fixed | | | later are not | in 12.4T | | | vulnerable; first fixed | | | | in 12.4T | | |------------+--------------------------+---------------------------| | | 12.4(24)T3 | | | | | 12.4(15)T14 | | | 12.4(22)T5 | | | 12.4T | | 12.4(20)T6 | | | 12.4(20)T5 | | | | | 12.4(24)T4 | | | 12.4(15)T14 | | |------------+--------------------------+---------------------------| | 12.4XA | Vulnerable; first fixed | Vulnerable; first fixed | | | in 12.4T | in 12.4T | |------------+--------------------------+---------------------------| | 12.4XB | Vulnerable; first fixed | Vulnerable; first fixed | | | in 12.4T | in 12.4T | |------------+--------------------------+---------------------------| | 12.4XC | Vulnerable; first fixed | Vulnerable; first fixed | | | in 12.4T | in 12.4T | |------------+--------------------------+---------------------------| | 12.4XD | Vulnerable; first fixed | Vulnerable; first fixed | | | in 12.4T | in 12.4T | |------------+--------------------------+---------------------------| | | Releases prior to 12.4 | Releases prior to 12.4(6) | | | (6)XE5 are vulnerable, | XE5 are vulnerable, | | 12.4XE | release 12.4(6)XE5 and | release 12.4(6)XE5 and | | | later are not | later are not vulnerable; | | | vulnerable; first fixed | first fixed in 12.4T | | | in 12.4T | | |------------+--------------------------+---------------------------| | 12.4XF | Vulnerable; first fixed | Vulnerable; first fixed | | | in 12.4T | in 12.4T | |------------+--------------------------+---------------------------| | 12.4XG | Vulnerable; first fixed | Vulnerable; first fixed | | | in 12.4T | in 12.4T | |------------+--------------------------+---------------------------| | 12.4XJ | Vulnerable; first fixed | Vulnerable; first fixed | | | in 12.4T | in 12.4T | |------------+--------------------------+---------------------------| | 12.4XK | Vulnerable; first fixed | Vulnerable; first fixed | | | in 12.4T | in 12.4T | |------------+--------------------------+---------------------------| | | Vulnerable; Contact your | Vulnerable; Contact your | | | support organization per | support organization per | | 12.4XL | the instructions in | the instructions in | | | Obtaining Fixed Software | Obtaining Fixed Software | | | section of this advisory | section of this advisory | |------------+--------------------------+---------------------------| | 12.4XM | Vulnerable; first fixed | Vulnerable; first fixed | | | in 12.4T | in 12.4T | |------------+--------------------------+---------------------------| | | Vulnerable; Contact your | Vulnerable; Contact your | | | support organization per | support organization per | | 12.4XN | the instructions in | the instructions in | | | Obtaining Fixed Software | Obtaining Fixed Software | | | section of this advisory | section of this advisory | |------------+--------------------------+---------------------------| | | Vulnerable; Contact your | Vulnerable; Contact your | | | support organization per | support organization per | | 12.4XP | the instructions in | the instructions in | | | Obtaining Fixed Software | Obtaining Fixed Software | | | section of this advisory | section of this advisory | |------------+--------------------------+---------------------------| | 12.4XQ | 12.4(15)XQ6; Available | 12.4(15)XQ6; Available on | | | on 22-SEP-10 | 22-SEP-10 | |------------+--------------------------+---------------------------| | | 12.4(15)XR9 | 12.4(15)XR9 | | 12.4XR | | | | | 12.4(22)XR7 | 12.4(22)XR7 | |------------+--------------------------+---------------------------| | 12.4XT | Vulnerable; first fixed | Vulnerable; first fixed | | | in 12.4T | in 12.4T | |------------+--------------------------+---------------------------| | | Vulnerable; Contact your | Vulnerable; Contact your | | | support organization per | support organization per | | 12.4XV | the instructions in | the instructions in | | | Obtaining Fixed Software | Obtaining Fixed Software | | | section of this advisory | section of this advisory | |------------+--------------------------+---------------------------| | 12.4XW | Vulnerable; first fixed | Vulnerable; first fixed | | | in 12.4T | in 12.4T | |------------+--------------------------+---------------------------| | 12.4XY | Vulnerable; first fixed | Vulnerable; first fixed | | | in 12.4T | in 12.4T | |------------+--------------------------+---------------------------| | 12.4XZ | Vulnerable; first fixed | Vulnerable; first fixed | | | in 12.4T | in 12.4T | |------------+--------------------------+---------------------------| | 12.4YA | Vulnerable; first fixed | Vulnerable; first fixed | | | in 12.4T | in 12.4T | |------------+--------------------------+---------------------------| | | | Vulnerable; Contact your | | | | support organization per | | 12.4YB | 12.4(22)YB6 | the instructions in | | | | Obtaining Fixed Software | | | | section of this advisory | |------------+--------------------------+---------------------------| | | Vulnerable; Contact your | Vulnerable; Contact your | | | support organization per | support organization per | | 12.4YD | the instructions in | the instructions in | | | Obtaining Fixed Software | Obtaining Fixed Software | | | section of this advisory | section of this advisory | |------------+--------------------------+---------------------------| | | 12.4(24)YE1 | | | 12.4YE | | 12.4(24)YE1 | | | 12.4(22)YE4 | | |------------+--------------------------+---------------------------| | 12.4YG | 12.4(24)YG3 | 12.4(24)YG3 | |------------+--------------------------+---------------------------| | Affected | | First Fixed Release for | | 15.0-Based | First Fixed Release for | All Advisories in the | | Releases | This Advisory | September 2010 Bundle | | | | Publication | |------------+--------------------------+---------------------------| | 15.0M | 15.0(1)M2 | 15.0(1)M3 | |------------+--------------------------+---------------------------| | | Cisco 7600 and 10000 | Cisco 7600 and 10000 | | | Series routers: Not | Series routers: 15.0(1)S1 | | | vulnerable | (Available early October | | | | 2010) | | 15.0S | Cisco ASR 1000 Series | | | | routes: Please see Cisco | Cisco ASR 1000 Series | | | IOS-XE Software | routes: Please see Cisco | | | Availability | IOS-XE Software | | | | Availability | |------------+--------------------------+---------------------------| | 15.0XA | Vulnerable; migrate to | Vulnerable; first fixed | | | any release in 15.1T | in 15.1T | |------------+--------------------------+---------------------------| | 15.0XO | Not Vulnerable | Not Vulnerable | |------------+--------------------------+---------------------------| | Affected | | First Fixed Release for | | 15.1-Based | First Fixed Release for | All Advisories in the | | Releases | This Advisory | September 2010 Bundle | | | | Publication | |-------------------------------------------------------------------| | There are no affected 15.1 based releases | +-------------------------------------------------------------------+ Cisco IOS XE Software +-------------------- +-------------------------------------------------------------------+ | Cisco IOS | First Fixed | First Fixed Release for All | | XE | Release for This | Advisories in the September 2010 | | Release | Advisory | Bundle Publication | |-----------+------------------+------------------------------------| | 2.1.x | Not Vulnerable | Not Vulnerable | |-----------+------------------+------------------------------------| | 2.2.x | Not Vulnerable | Not Vulnerable | |-----------+------------------+------------------------------------| | 2.3.x | Not Vulnerable | Not Vulnerable | |-----------+------------------+------------------------------------| | 2.4.x | Not Vulnerable | Not Vulnerable | |-----------+------------------+------------------------------------| | 2.5.x | 2.5.2 | Vulnerable; migrate to 2.6.2 or | | | | later | |-----------+------------------+------------------------------------| | 2.6.x | Not Vulnerable | 2.6.2 | |-----------+------------------+------------------------------------| | 3.1.xS | Not Vulnerable | Not Vulnerable | +-------------------------------------------------------------------+ To map Cisco IOS XE Software releases to Cisco IOS Software releases, refer to the Cisco IOS XE 2 and Cisco IOS XE 3S Release Notes. Cisco IOS XR Software Table +-------------------------- Cisco IOS XR Software is not affected by the vulnerabilities disclosed in the September 22, 2010, Cisco IOS Software Security Advisory bundle publication. Workarounds =========== 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-20100922-igmp.shtml IGMP version 2 +------------- Customers who do not require the Source Specific Multicast (SSM) functionality can use IGMP version 2 as a workaround. interface GigabitEthernet0/0 ip address 192.168.0.1 255.255.255.0 ip pim sparse-mode ip igmp version 2 Control Plane Policing +--------------------- A partial mitigation of the vulnerability described in this document is to block IGMP packets with an IP Time to Live (TTL) field value that is not equal to 1. RFC1054 leavingcisco.com, "Host Extensions for IP Multicasting" RFC2236 leavingcisco.com, "Internet Group Management Protocol Version 2", and RFC3376 leavingcisco.com, "Internet Group Management Protocol Version 3", indicate that every IGMP message is sent with an IP TTL of 1. CoPP may be configured on a device to protect the management and control planes, and minimize the risk and effectiveness of direct infrastructure attacks by explicitly permitting only authorized traffic sent to infrastructure devices in accordance with existing security policies and configurations. The following example can be adapted to your network. Drop of IGMP packets with unicast IP destination addresses can also be implemented with CoPP if the network is using all multicast applications that utilize only multicast group destination addresses for IGMP packets. ! !-- The following access list is used !-- to determine what traffic needs to be dropped by a control plane !-- policy (the CoPP feature.) If the access list matches (permit), !-- then traffic will be dropped. If the access list does not !-- match (deny), then traffic will be processed by the router. !-- all IGMP packets with ttl different from 1 will be selected !-- by this acl and the "drop" action will be applied in the !-- corresponding CoPP polisy ! ip access-list extended IGMP-ACL permit igmp any any ttl neq 1 ! !-- Permit (Police or Drop)/Deny (Allow) all other Layer3 and Layer4 !-- traffic in accordance with existing security policies and !-- configurations for traffic that is authorized to be sent !-- to infrastructure devices. !-- Create a class map for traffic that will be policed by !-- the CoPP feature. ! class-map match-all drop-IGMP-class match access-group name IGMP-ACL ! !-- Create a policy map that will be applied to the !-- Control Plane of the device, and add the "drop-tcp-traffic" !-- class map. ! policy-map CoPP-policy class drop-IGMP-class drop ! !-- Apply the policy map to the control plane of the !-- device. ! control-plane service-policy input CoPP-policy Additional information on the configuration and use of the CoPP feature is available in the Control Plane Policing Implementation Best Practices. 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. This vulnerability was reported to Cisco by a customer. 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-20100922-igmp.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 | 2010-Sep-22 | 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.10 (Darwin) iEYEARECAAYFAkyZ/SsACgkQ86n/Gc8U/uCbNgCfXPOxAGWckAe7qNCH3ji+tE3n tlcAniKclgzM+5lzNmRCpt3M7yJqDzcT =MXP9 -----END PGP SIGNATURE----- From bruce at yoafrica.com Wed Sep 22 16:56:17 2010 From: bruce at yoafrica.com (Bruce Grobler) Date: Wed, 22 Sep 2010 18:56:17 +0200 Subject: IDS IPS In-Reply-To: <4C9A3287.3030504@placenet.org> References: <4C9A3287.3030504@placenet.org> Message-ID: <00e101cb5a77$12c3a1d0$384ae570$@yoafrica.com> Brilliant!!!! that went directly to my sense of humour! -----Original Message----- From: Fr?deric [mailto:frederic at placenet.org] Sent: Wednesday, September 22, 2010 6:45 PM To: nanog at nanog.org Subject: Re: IDS IPS http://en.lmgtfy.com/?q=ips+iss bst rgds Le 22/09/2010 18:29, Joshua William Klubi a ?crit : > What is ISS > > Joshua > > On Wed, Sep 22, 2010 at 4:24 PM, Adefisayo Adegoke wrote: > >> ISS .... ideal for the Defense and Banking industry ....... >> >> 'Ayo >> >> On Wed, Sep 22, 2010 at 10:11 AM, Joshua William Klubi < >> joshua.klubi at gmail.com> wrote: >> >>> Hi, >>> >>> I have been tasked to get the best IDS and IPS for our internal LAN >>> and WAN in a Banking infrastructure. >>> I would like ask if any one has deployed in any network with such >>> technology, and also if any one can recommend a very good IDS and >>> IPS for me to recommend to management >>> >>> Thank you. >>> >>> Joshua >>> >> >> >> >> -- >> ........... the sky is too low to be my limit. >> >> .... Success is getting what you want, happiness is wanting what you >> get - Ingrid Bergman >> >> > From drew.weaver at thenap.com Wed Sep 22 16:56:41 2010 From: drew.weaver at thenap.com (Drew Weaver) Date: Wed, 22 Sep 2010 12:56:41 -0400 Subject: Avaya Converged Network Analyzer Message-ID: All argument aside about whether these products are worthwhile (hopefully) I am having a very strange and random technical problem with one of these boxes and I know in the past there were folks on NANOG who used them, if possible can anyone who falls into that category contact me off-list please? thanks, -Drew From chip.gwyn at gmail.com Wed Sep 22 17:05:58 2010 From: chip.gwyn at gmail.com (chip) Date: Wed, 22 Sep 2010 13:05:58 -0400 Subject: IDS IPS In-Reply-To: References: Message-ID: The dog and pony show for the Tipping Point products was pretty interesting. Looks like they've been swalled up by HP now. http://h10144.www1.hp.com/products/security/index.htm#Intrusion Prevention Systems (IPS) On Wed, Sep 22, 2010 at 12:11 PM, Joshua William Klubi < joshua.klubi at gmail.com> wrote: > Hi, > > I have been tasked to get the best IDS and IPS for our internal LAN and WAN > in a Banking infrastructure. > I would like ask if any one has deployed in any network with such > technology, and also if any one can recommend > a very good IDS and IPS for me to recommend to management > > Thank you. > > Joshua > -- Just my $.02, your mileage may vary, batteries not included, etc.... From morrowc.lists at gmail.com Wed Sep 22 17:17:55 2010 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Wed, 22 Sep 2010 13:17:55 -0400 Subject: FW: Odd BGP AS Path In-Reply-To: <-5950227353538590009@unknownmsgid> References: <-5950227353538590009@unknownmsgid> Message-ID: On Wed, Sep 22, 2010 at 12:42 PM, Chris Hall wrote: > And what about the truly, madly, deeply useless AS_CONFED_SET ? ?[A > carbuncle's carbuncle if ever I saw one.] AS_CONFED_SET is included in the next version of this draft... From scott at sberkman.net Wed Sep 22 17:19:01 2010 From: scott at sberkman.net (Scott Berkman) Date: Wed, 22 Sep 2010 13:19:01 -0400 Subject: IDS IPS In-Reply-To: References: Message-ID: <005501cb5a7a$40837ca0$c18a75e0$@net> You should look into SecureWorks as well. http://secureworks.com/services/network_intrusion_prevention_detection.html -Scott -----Original Message----- From: Joshua William Klubi [mailto:joshua.klubi at gmail.com] Sent: Wednesday, September 22, 2010 12:12 PM To: North American Network Operators Group Subject: IDS IPS Hi, I have been tasked to get the best IDS and IPS for our internal LAN and WAN in a Banking infrastructure. I would like ask if any one has deployed in any network with such technology, and also if any one can recommend a very good IDS and IPS for me to recommend to management Thank you. Joshua From bdantzig at medline.com Wed Sep 22 17:18:34 2010 From: bdantzig at medline.com (Dantzig, Brian) Date: Wed, 22 Sep 2010 12:18:34 -0500 Subject: IDS IPS Message-ID: <1F26704905C4804AAF98B0AE6BE029510356B703@MUNEXBE1.medline.com> > Hi, > > I have been tasked to get the best IDS and IPS for our internal LAN and WAN > in a Banking infrastructure. > I would like ask if any one has deployed in any network with such > technology, and also if any one can recommend > a very good IDS and IPS for me to recommend to management > > Thank you. > > Joshua > ISS (acquired by IBM) is a verry strong product and you should look at it. We ran a demo/pilot od ISS in our production network for a couple of monthes and were pleased with it. Junipers IDP is another product to look at. I am currently running IDP and it was a better fit than ISS for us. From fw at deneb.enyo.de Wed Sep 22 20:15:03 2010 From: fw at deneb.enyo.de (Florian Weimer) Date: Wed, 22 Sep 2010 22:15:03 +0200 Subject: Odd BGP AS Path In-Reply-To: (Randy Bush's message of "Wed, 22 Sep 2010 11:30:44 -0400") References: Message-ID: <87bp7pbkmw.fsf@mid.deneb.enyo.de> * Randy Bush: >> Probably a silly question, but can anyone explain to me this: >> 3561 3356 9031 {35821,35821,35821,35821} i > > please support draft-wkumari-deprecate-as-sets-00.txt Mere deprecation does not stop propagation of such paths. From robert at ripe.net Wed Sep 22 20:19:25 2010 From: robert at ripe.net (Robert Kisteleki) Date: Wed, 22 Sep 2010 22:19:25 +0200 Subject: IDS IPS In-Reply-To: References: Message-ID: <4C9A64CD.1040408@ripe.net> http://en.wikipedia.org/wiki/ISS On 2010.09.22. 18:29, Joshua William Klubi wrote: > What is ISS > > Joshua > > On Wed, Sep 22, 2010 at 4:24 PM, Adefisayo Adegokewrote: > >> ISS .... ideal for the Defense and Banking industry ....... >> >> 'Ayo >> >> On Wed, Sep 22, 2010 at 10:11 AM, Joshua William Klubi< >> joshua.klubi at gmail.com> wrote: >> >>> Hi, >>> >>> I have been tasked to get the best IDS and IPS for our internal LAN and >>> WAN >>> in a Banking infrastructure. >>> I would like ask if any one has deployed in any network with such >>> technology, and also if any one can recommend >>> a very good IDS and IPS for me to recommend to management >>> >>> Thank you. >>> >>> Joshua >>> >> >> >> >> -- >> ........... the sky is too low to be my limit. >> >> .... Success is getting what you want, happiness is wanting what you get - >> Ingrid Bergman >> >> From michael.holstein at csuohio.edu Wed Sep 22 20:28:40 2010 From: michael.holstein at csuohio.edu (Michael Holstein) Date: Wed, 22 Sep 2010 16:28:40 -0400 Subject: IDS IPS In-Reply-To: References: Message-ID: <4C9A66F8.1050700@csuohio.edu> > What is ISS > > It's a hole in space into which governments pour money. See also, IBM. ~Mike. From Tim.Green at boemre.gov Wed Sep 22 20:32:04 2010 From: Tim.Green at boemre.gov (Green, Tim R) Date: Wed, 22 Sep 2010 16:32:04 -0400 Subject: IDS IPS In-Reply-To: <4C9A66F8.1050700@csuohio.edu> References: <4C9A66F8.1050700@csuohio.edu> Message-ID: <2C52BAD40424C1448409220FDF725F5960421E@IMSHEXPRI10.service.agency.mms.pri> See also Webinspect, Appscan, etc..... -----Original Message----- From: Michael Holstein [mailto:michael.holstein at csuohio.edu] Sent: Wednesday, September 22, 2010 4:29 PM To: Joshua William Klubi Cc: North American Network Operators Group Subject: Re: IDS IPS > What is ISS > > It's a hole in space into which governments pour money. See also, IBM. ~Mike. From kaeo at merike.com Wed Sep 22 20:52:26 2010 From: kaeo at merike.com (Merike Kaeo) Date: Wed, 22 Sep 2010 13:52:26 -0700 Subject: IDS IPS In-Reply-To: References: Message-ID: <718A62CE-5E57-41B4-AA9C-2BE77DBF8816@merike.com> Hi... I'll take this offline with you but this is quite a generic question and you have to look at requirements for the bank infrastructure and also what level of knowledge is available from staff to actually make the device you buy useful. Any answer you get with just a product name will tell you nothing. You have to do some more legwork on your own. - merike On Sep 22, 2010, at 9:11 AM, Joshua William Klubi wrote: > Hi, > > I have been tasked to get the best IDS and IPS for our internal LAN and WAN > in a Banking infrastructure. > I would like ask if any one has deployed in any network with such > technology, and also if any one can recommend > a very good IDS and IPS for me to recommend to management > > Thank you. > > Joshua From randy at psg.com Wed Sep 22 22:54:24 2010 From: randy at psg.com (Randy Bush) Date: Wed, 22 Sep 2010 18:54:24 -0400 Subject: Odd BGP AS Path In-Reply-To: <87bp7pbkmw.fsf@mid.deneb.enyo.de> References: <87bp7pbkmw.fsf@mid.deneb.enyo.de> Message-ID: >>> Probably a silly question, but can anyone explain to me this: >>> 3561 3356 9031 {35821,35821,35821,35821} i >> please support draft-wkumari-deprecate-as-sets-00.txt > Mere deprecation does not stop propagation of such paths. over time, routers will no longer generate or accept in the meantime, i will watch while you and king canute try to cure st00pidity. randy From rbradley at a1fcu.org Thu Sep 23 13:58:40 2010 From: rbradley at a1fcu.org (Ryan Bradley) Date: Thu, 23 Sep 2010 09:58:40 -0400 Subject: IDS IPS In-Reply-To: References: Message-ID: <661FEAF65459994780CE520E3F212EE4DF51D7@a1server4.a1fcu.org> Joshua, We use the Juniper 2xx series IDP; highly recommended. We are a small financial intuition with about 200 employees and 13 branch locations. I'd stay far away from SecureWorks if you're looking to manage the device yourself; if you're looking for an overpriced managed solution then they'd be okay. Ryan -----Original Message----- From: Joshua William Klubi [mailto:joshua.klubi at gmail.com] Sent: Wednesday, September 22, 2010 12:12 PM To: North American Network Operators Group Subject: IDS IPS Hi, I have been tasked to get the best IDS and IPS for our internal LAN and WAN in a Banking infrastructure. I would like ask if any one has deployed in any network with such technology, and also if any one can recommend a very good IDS and IPS for me to recommend to management Thank you. Joshua From warren at kumari.net Thu Sep 23 14:48:43 2010 From: warren at kumari.net (Warren Kumari) Date: Thu, 23 Sep 2010 10:48:43 -0400 Subject: Odd BGP AS Path In-Reply-To: <87bp7pbkmw.fsf@mid.deneb.enyo.de> References: <87bp7pbkmw.fsf@mid.deneb.enyo.de> Message-ID: <303A7C18-0831-4A8E-85BA-3600F87D067D@kumari.net> On Sep 22, 2010, at 4:15 PM, Florian Weimer wrote: > * Randy Bush: > >>> Probably a silly question, but can anyone explain to me this: >>> 3561 3356 9031 {35821,35821,35821,35821} i >> >> please support draft-wkumari-deprecate-as-sets-00.txt > > Mere deprecation does not stop propagation of such paths. That's very true, but it *does* move us in the right direction -- saying "Aggregation that results in AS_SETs is prohibited, off with your head" isn't going to fly in the IDR WG when there are routes that use them... Suggesting the people do not perform aggregation that results in the creation of AS_SETs (and AS_CONFED_SETs), and that operators filter such announcements will lead to a time where they just don't exist any more [0] (and then can be removed from the protocol). We are also specifying that new BGP work does not need to support AS_.*SET ;-) W -- "Being the Fun-Police in the global Internet is a thankless - and probably futile - task." -- R. Whittle ("draft-whittle-sram-ip-forwarding-01.txt") From randy at psg.com Thu Sep 23 14:59:07 2010 From: randy at psg.com (Randy Bush) Date: Thu, 23 Sep 2010 10:59:07 -0400 Subject: Odd BGP AS Path In-Reply-To: <303A7C18-0831-4A8E-85BA-3600F87D067D@kumari.net> References: <87bp7pbkmw.fsf@mid.deneb.enyo.de> <303A7C18-0831-4A8E-85BA-3600F87D067D@kumari.net> Message-ID: just to uncloak a bit. when we first decided to look at deprecating as-sets et alia, we begged olaf maennel to analyse the use thereof. the following is edited from internal email from early august. we then begged one of our number, warren, to do the dirty, and he was kind enough to do so. we owe him. --- using data from ripe r00 years total real stable as-sets as-sets 7 4 2 6 6 2 5 20 3 4 22 5 3 64 16 2 214 87 1 875 289 years stable is how many years that as-set was announced for that prefix. total as-sets is the number of prefixes that had any as-set. real as-sets is the number of prefixes with as-sets which were not singleton asns and were not private asns. olaf scanned for ten years but none were stable for more than seven. in ten years, 1205 different prefixes with as-sets were seen. removing private asns and removing singletons left only 404 prefixes over the ten years. he did not check for covering prefixes, i.e. two prefixes with the same as-set where one was a sub-prefix of the other, longer, one. and i suspect the data are somewhat self-similar. i.e. the 289 that were stable for the last year may have shorter term components which were much higher. i.e. looking at data for a week or a day may give higher values. a graph which should be pretty self-explanitory may be found at http://archive.psg.com/fraction-and-absolute-number-of-ASsets-in-table-over-time-valids-only.pdf it is interesting that, at no time, i.e. in no single rib dump, were there more than 23 prefixes with as-sets. while this is suspicious, it seems to be true. randy From kompella at cs.purdue.edu Thu Sep 23 16:10:57 2010 From: kompella at cs.purdue.edu (Ramana Kompella) Date: Thu, 23 Sep 2010 12:10:57 -0400 Subject: CFP: COMSNETS 2011 (Deadline in 4 days: Sept 27, 11:59pm PDT) Message-ID: <20100923161057.GA7221@tirupati> *** APOLOGIES IF YOUR RECEIVED MULTIPLE COPIES OF THE CFP *** *** EXTENDED FIRM DEADLINE in exactly 4 days: Sept 27, 11:59pm PDT *** COMSNETS 2011 The THIRD International Conference on COMunication Systems and NETworks January 4-8, 2011, Bangalore, India http://www.comsnets.org (In Co-operation with ACM SIGMOBILE) (Technically Co-Sponsored by IEEE COMSOC) The Third International Conference on COMmunication Systems and NETworkS (COMSNETS) will be held in Bangalore, India, from 4 January 2011 to 8 January 2011. COMSNETS is a premier international conference dedicated to addressing advances in Networking and Communications Systems, and Telecommunications services. The goal of the conference is to create a world-class gathering of researchers from academia and industry, practitioners, business leaders, intellectual property experts, and venture capitalists, providing a forum for discussing cutting edge research, and directions for new innovative business and technology. The conference will include a highly selective technical program consisting of parallel tracks of submitted papers, a small set of invited papers on important and timely topics from well-known leaders in the field, and poster sessions of work in progress. Focused workshops and panel discussions will be held on emerging topics to allow for a lively exchange of ideas. International business and government leaders will be invited to share their perspectives, thus complementing the technical program. Papers describing original research work and practical experiences/experimental results are solicited on topics including, but not limited to: Topics of Interest ------------------ Internet Architecture and Protocols Network-based Applications Video Distribution (IPTV, Mobile Video, Video on Demand) Network Operations and Management Broadband and Cellular Networks (3G/4G, WiMAX/LTE) Mesh, Sensor and PAN Networks Communication Software (Cognitive Radios, DSA, SDR) Wireless Operating Systems and Mobile Platforms Peer-to-peer Networking Cognitive Radio and White Space Networking Optical Networks Network Security & Cyber Security Technologies Cloud and Utility computing Storage Area Networks Next Generation Web Architectures Vehicular Networking Energy-Efficient Networking Network Science and Emergent Behavior in Socio-Technical Networks Social Networking Analysis, Middleware and Applications Networking Technologies for Smart Energy Grids Disruption/Delay Tolerant Networking Conference Highlights --------------------- Banquet speaker: Dr. Rajeev Rastogi, Yahoo Research, India Keynote Speakers: ? Prof. Don Towsley, U. Mass Amherst, USA ? Dr. Pravin Bhagwat, AirTight Networks, India ? Dr. Jean Bolot, Sprint, USA Workshops ? WISARD (4, 5 Jan) ? NetHealth (4 Jan) ? IAMCOM (5 Jan) ? Mobile India 2011 (7 Jan) Technical Paper and Poster Sessions Ph.D Forum Panel Discussions Demos & Exhibits Important Deadlines ------------------- Paper submission (FIRM, ABSOLUTELY NO EXTENSIONS): September 27, 2010 at 11:59 pm EDT (Sept 28, 9:29 am IST) Notification of Acceptance: November 8, 2010 Camera-Ready Submission: December 8, 2010 Detailed conference information and paper submission guidelines is available on the conference web site. Please see http://www.comsnets.org for detailed information from time to time. The conference email address is: comsnets2011 at gmail.com General Co-Chairs ----------------- David B. Johnson, Rice University, USA Anurag Kumar, IISc Bangalore, India Technical Program Co-Chairs --------------------------- Jon Crowcroft, U. of Cambridge, UK D. Manjunath, IIT Bombay, India Archan Misra, Telcordia Tech., USA Steering Committee Co-Chairs ---------------------------- Uday Desai, IIT Hyderabad, India Giridhar Mandyam, Qualcomm, USA Sanjoy Paul, Infosys, India Rajeev Shorey, NIIT University, India G. Venkatesh, SASKEN, India Panel Co-Chairs --------------- Aditya Akella, U. of Wisconsin, USA Venkat Padmanabhan, MSR, India Ph.D Forum Chair ---------------- Bhaskaran Raman, IIT Bombay, India Publications Chair ------------------ Varsha Apte, IIT Bombay, India Demos and Exhibits Co-Chairs ---------------------------- Aaditeshwar Seth, IIT Delhi, India Ajay Bakre, Netapps, India Sponsorship Chair ----------------- Sudipta Maitra, Delhi, india Workshop Chairs --------------- Sharad Jaiswal, Alcatel-Lucent, India Ravindran Kaliappa, CUNY, USA Neelesh Mehta, IISc Bangalore, India Mobile India 2011 Co-Chairs --------------------------- Gulzar Azad, Google, India Gene Landy, Ruperto-Israel & Weiner, USA Rajaraghavan Setlur, SASKEN, India Sridhar Varadharajan, SASKEN, India Publicity Co-Chair ------------------ Augustin Chaintreau, TTL, France Kameswari Chebrolu, IIT Bombay, India Song Chong, KAIST, Korea Ramana Kompella, Purdue Univ, USA Nishanth Sastry, U. of Cambridge, UK Web Co-Chairs ------------- Santhana Krishnan, IIT Bombay, India Vinay Veerappa, SASKEN, India International Advisory Committee -------------------------------- K. K. Ramakrishnan, AT&T, USA Victor Bahl, Microsoft Research, USA Sunghyun Choi, Seoul National U., Korea Sajal Das, U. Texas at Arlington, USA B. N. Jain, IIT Delhi, India Anurag Kumar, IISc, Bangalore, India L. M. Patnaik, IISc, Bangalore, India Krithi Ramamritham, IIT Bombay, India Parmesh Ramanathan, U. Wisconsin, USA Krishan Sabnani, Alcatel-Lucent, USA Kang Shin, U. Michigan, USA Nitin Vaidya, U. Illinois, USA University Partners: -------------------- IIT Bombay, IIT Delhi, IISc Bangalore, IIT Hyderabad, NIIT University, IIIT Bangalore, BITS Pilani Patrons: -------- Mobile Monday Bangalore, Sasken, IBM Research, Alcatel Lucent From ernesto at cs.fiu.edu Thu Sep 23 19:39:15 2010 From: ernesto at cs.fiu.edu (Ernie Rubi) Date: Thu, 23 Sep 2010 15:39:15 -0400 Subject: Facebook Issues/Outage in Southeast? Message-ID: Anyone else having trouble? We're colo'ed at the NOTA in Miami and directly peer with them - even though our session hasn't gone down we still can't reach them. Ernesto M. Rubi Sr. Network Engineer AMPATH/CIARA Florida International Univ, Miami Reply-to: ernesto at cs.fiu.edu Cell: 786-282-6783 From pstewart at nexicomgroup.net Thu Sep 23 19:40:59 2010 From: pstewart at nexicomgroup.net (Paul Stewart) Date: Thu, 23 Sep 2010 15:40:59 -0400 Subject: Facebook Issues/Outage in Southeast? In-Reply-To: References: Message-ID: Over on the outages list there is a lot of discussion... I believe everyone is effected - we are peered with them in several locations and cannot reach them. Paul -----Original Message----- From: Ernie Rubi [mailto:ernesto at cs.fiu.edu] Sent: Thursday, September 23, 2010 3:39 PM To: nanog at nanog.org Subject: Facebook Issues/Outage in Southeast? Anyone else having trouble? We're colo'ed at the NOTA in Miami and directly peer with them - even though our session hasn't gone down we still can't reach them. Ernesto M. Rubi Sr. Network Engineer AMPATH/CIARA Florida International Univ, Miami Reply-to: ernesto at cs.fiu.edu Cell: 786-282-6783 From chaim.rieger at gmail.com Thu Sep 23 19:41:04 2010 From: chaim.rieger at gmail.com (chaim rieger) Date: Thu, 23 Sep 2010 19:41:04 +0000 Subject: Facebook Issues/Outage in Southeast? Message-ID: <471277240-1285270865-cardhu_decombobulator_blackberry.rim.net-1324398093-@bda899.bisx.prod.on.blackberry> Yes tis down. Watch productivity go up ------Original Message------ From: Ernie Rubi To: nanog at nanog.org Subject: Facebook Issues/Outage in Southeast? Sent: Sep 23, 2010 12:39 Anyone else having trouble? We're colo'ed at the NOTA in Miami and directly peer with them - even though our session hasn't gone down we still can't reach them. Ernesto M. Rubi Sr. Network Engineer AMPATH/CIARA Florida International Univ, Miami Reply-to: ernesto at cs.fiu.edu Cell: 786-282-6783 From andrew.wallace at rocketmail.com Thu Sep 23 19:41:45 2010 From: andrew.wallace at rocketmail.com (andrew.wallace) Date: Thu, 23 Sep 2010 12:41:45 -0700 (PDT) Subject: Facebook Issues/Outage in Southeast? In-Reply-To: References: Message-ID: <581294.59169.qm@web59605.mail.ac4.yahoo.com> Over the last 30 minutes or more (UK) Andrew ----- Original Message ---- From: Ernie Rubi To: nanog at nanog.org Sent: Thu, 23 September, 2010 20:39:15 Subject: Facebook Issues/Outage in Southeast? Anyone else having trouble? We're colo'ed at the NOTA in Miami and directly peer with them - even though our session hasn't gone down we still can't reach them. Ernesto M. Rubi Sr. Network Engineer AMPATH/CIARA Florida International Univ, Miami Reply-to: ernesto at cs.fiu.edu Cell: 786-282-6783 From ernesto at cs.fiu.edu Thu Sep 23 19:39:15 2010 From: ernesto at cs.fiu.edu (Ernie Rubi) Date: Thu, 23 Sep 2010 15:39:15 -0400 Subject: Facebook Issues/Outage in Southeast? Message-ID: Anyone else having trouble? We're colo'ed at the NOTA in Miami and directly peer with them - even though our session hasn't gone down we still can't reach them. Ernesto M. Rubi Sr. Network Engineer AMPATH/CIARA Florida International Univ, Miami Reply-to: ernesto at cs.fiu.edu Cell: 786-282-6783 From justin.horstman at gorillanation.com Thu Sep 23 19:43:44 2010 From: justin.horstman at gorillanation.com (Justin Horstman) Date: Thu, 23 Sep 2010 12:43:44 -0700 Subject: Facebook Issues/Outage in Southeast? In-Reply-To: References: Message-ID: <8C164D3BAF7C7F41B9B286385037B1310D3646D683@lax-exch-fe-01.gorillanation.local> Via http://downforeveryoneorjustme.com/facebook.com It's not just you! http://facebook.com looks down from here. Also down from LA, qwest has been having issues today as well, not sure if its related. > -----Original Message----- > From: Ernie Rubi [mailto:ernesto at cs.fiu.edu] > Sent: Thursday, September 23, 2010 12:39 PM > To: nanog at nanog.org > Subject: Facebook Issues/Outage in Southeast? > > Anyone else having trouble? We're colo'ed at the NOTA in Miami and > directly peer with them - even though our session hasn't gone down we > still can't reach them. > > Ernesto M. Rubi > Sr. Network Engineer > AMPATH/CIARA > Florida International Univ, Miami > Reply-to: ernesto at cs.fiu.edu > Cell: 786-282-6783 > > > From smb at cs.columbia.edu Thu Sep 23 19:46:33 2010 From: smb at cs.columbia.edu (Steven Bellovin) Date: Thu, 23 Sep 2010 15:46:33 -0400 Subject: Facebook Issues/Outage in Southeast? In-Reply-To: References: Message-ID: <9DFEEE61-5562-4157-841A-5C1B9EEA55EF@cs.columbia.edu> On Sep 23, 2010, at 3:40 59PM, Paul Stewart wrote: > Over on the outages list there is a lot of discussion... I believe > everyone is effected - we are peered with them in several locations and > cannot reach them. > http://blogs.wsj.com/digits/2010/09/22/facebook-goes-down-for-some-users/ > --Steve Bellovin, http://www.cs.columbia.edu/~smb From justin.horstman at gorillanation.com Thu Sep 23 19:47:43 2010 From: justin.horstman at gorillanation.com (Justin Horstman) Date: Thu, 23 Sep 2010 12:47:43 -0700 Subject: Facebook Issues/Outage in Southeast? In-Reply-To: <471277240-1285270865-cardhu_decombobulator_blackberry.rim.net-1324398093-@bda899.bisx.prod.on.blackberry> References: <471277240-1285270865-cardhu_decombobulator_blackberry.rim.net-1324398093-@bda899.bisx.prod.on.blackberry> Message-ID: <8C164D3BAF7C7F41B9B286385037B1310D3646D685@lax-exch-fe-01.gorillanation.local> Productivity grinds to a hault as everyone goes onto twitter to talk about facebook being down.... > -----Original Message----- > From: chaim rieger [mailto:chaim.rieger at gmail.com] > Sent: Thursday, September 23, 2010 12:41 PM > To: Ernie Rubi; nanog at nanog.org > Subject: Re: Facebook Issues/Outage in Southeast? > > Yes tis down. Watch productivity go up > ------Original Message------ > From: Ernie Rubi > To: nanog at nanog.org > Subject: Facebook Issues/Outage in Southeast? > Sent: Sep 23, 2010 12:39 > > Anyone else having trouble? We're colo'ed at the NOTA in Miami and > directly peer with them - even though our session hasn't gone down we > still can't reach them. > > Ernesto M. Rubi > Sr. Network Engineer > AMPATH/CIARA > Florida International Univ, Miami > Reply-to: ernesto at cs.fiu.edu > Cell: 786-282-6783 > > > > > > From deleskie at gmail.com Thu Sep 23 19:48:41 2010 From: deleskie at gmail.com (deleskie at gmail.com) Date: Thu, 23 Sep 2010 19:48:41 +0000 Subject: Facebook Issues/Outage in Southeast? Message-ID: <680640083-1285271322-cardhu_decombobulator_blackberry.rim.net-1824705191-@bda002.bisx.prod.on.blackberry> Having issues from the north east as well. ------Original Message------ From: Ernie Rubi To: nanog at nanog.org Subject: Facebook Issues/Outage in Southeast? Sent: Sep 23, 2010 4:39 PM Anyone else having trouble? We're colo'ed at the NOTA in Miami and directly peer with them - even though our session hasn't gone down we still can't reach them. Ernesto M. Rubi Sr. Network Engineer AMPATH/CIARA Florida International Univ, Miami Reply-to: ernesto at cs.fiu.edu Cell: 786-282-6783 Sent from my BlackBerry device on the Rogers Wireless Network From tme at americafree.tv Thu Sep 23 19:54:52 2010 From: tme at americafree.tv (Marshall Eubanks) Date: Thu, 23 Sep 2010 15:54:52 -0400 Subject: Facebook Issues/Outage in Southeast? In-Reply-To: <471277240-1285270865-cardhu_decombobulator_blackberry.rim.net-1324398093-@bda899.bisx.prod.on.blackberry> References: <471277240-1285270865-cardhu_decombobulator_blackberry.rim.net-1324398093-@bda899.bisx.prod.on.blackberry> Message-ID: I can ping them but not access them over Cogent here in Tysons Corner, Virginia - looks like a server issue to me. server:temp tme$ wget www.facebook.com --15:52:17-- http://www.facebook.com/ => `index.html' Resolving www.facebook.com... 216.66.8.178, 216.66.8.225 Connecting to www.facebook.com|216.66.8.178|:80... connected. HTTP request sent, awaiting response... 500 Internal Server Error 15:53:03 ERROR 500: Internal Server Error. server:temp tme$ ping -c 5 216.66.8.178 PING 216.66.8.178 (216.66.8.178): 56 data bytes 64 bytes from 216.66.8.178: icmp_seq=0 ttl=55 time=15.865 ms 64 bytes from 216.66.8.178: icmp_seq=1 ttl=55 time=15.693 ms 64 bytes from 216.66.8.178: icmp_seq=2 ttl=55 time=15.851 ms 64 bytes from 216.66.8.178: icmp_seq=3 ttl=55 time=15.953 ms 64 bytes from 216.66.8.178: icmp_seq=4 ttl=55 time=15.823 ms --- 216.66.8.178 ping statistics --- 5 packets transmitted, 5 packets received, 0% packet loss round-trip min/avg/max/stddev = 15.693/15.837/15.953/0.084 ms server:temp tme$ Regards Marshall On Sep 23, 2010, at 3:41 PM, chaim rieger wrote: > Yes tis down. Watch productivity go up > ------Original Message------ > From: Ernie Rubi > To: nanog at nanog.org > Subject: Facebook Issues/Outage in Southeast? > Sent: Sep 23, 2010 12:39 > > Anyone else having trouble? We're colo'ed at the NOTA in Miami and directly peer with them - even though our session hasn't gone down we still can't reach them. > > Ernesto M. Rubi > Sr. Network Engineer > AMPATH/CIARA > Florida International Univ, Miami > Reply-to: ernesto at cs.fiu.edu > Cell: 786-282-6783 > > > > > > > > From james at cs.fiu.edu Thu Sep 23 19:57:47 2010 From: james at cs.fiu.edu (James Grace) Date: Thu, 23 Sep 2010 15:57:47 -0400 Subject: Facebook Issues/Outage in Southeast? In-Reply-To: References: Message-ID: <9C0EF4B3-A4B5-42D6-AB19-DECB714049B9@cs.fiu.edu> Which outages list? James On Sep 23, 2010, at 3:40 PM, Paul Stewart wrote: > Over on the outages list there is a lot of discussion... I believe > everyone is effected - we are peered with them in several locations and > cannot reach them. > > Paul > > > -----Original Message----- > From: Ernie Rubi [mailto:ernesto at cs.fiu.edu] > Sent: Thursday, September 23, 2010 3:39 PM > To: nanog at nanog.org > Subject: Facebook Issues/Outage in Southeast? > > Anyone else having trouble? We're colo'ed at the NOTA in Miami and > directly peer with them - even though our session hasn't gone down we > still can't reach them. > > Ernesto M. Rubi > Sr. Network Engineer > AMPATH/CIARA > Florida International Univ, Miami > Reply-to: ernesto at cs.fiu.edu > Cell: 786-282-6783 > > > > From jjn at nuge.com Thu Sep 23 19:58:50 2010 From: jjn at nuge.com (Jay Nugent) Date: Thu, 23 Sep 2010 15:58:50 -0400 (EDT) Subject: Facebook Issues/Outage in Southeast? In-Reply-To: <8C164D3BAF7C7F41B9B286385037B1310D3646D683@lax-exch-fe-01.gorillanation.local> Message-ID: Greetings, On Thu, 23 Sep 2010, Justin Horstman wrote: > Via http://downforeveryoneorjustme.com/facebook.com > > It's not just you! http://facebook.com looks down from here. > > Also down from LA, qwest has been having issues today as well, not sure if its related. About 45 minutes ago traceroutes died... [jjn at K2 ~]$ traceroute www.facebook.com traceroute to www.facebook.com (66.220.149.18), 30 hops max, 60 byte packets 1 DR-LVL3.nuge.com (216.144.208.1) 1.083 ms 1.695 ms 1.934 ms 2 * * * 3 166.90.244.19 (166.90.244.19) 31.257 ms 34.148 ms 37.801 ms 4 ge-5-0-155.hsa1.Detroit1.Level3.net (63.211.20.93) 41.258 ms 43.576 5 so-8-1.car1.Detroit1.Level3.net (4.69.140.118) 51.752 ms 54.577 ms 6 ae-8-8.ebr2.Chicago1.Level3.net (4.69.133.242) 76.007 ms 75.161 ms 7 ae-5-5.ebr2.Chicago2.Level3.net (4.69.140.194) 76.469 ms 48.544 ms 8 ae-6-6.ebr2.Washington12.Level3.net (4.69.148.145) 64.813 ms 63.952 9 ae-5-5.ebr2.Washington1.Level3.net (4.69.143.221) 61.980 ms 63.616 10 ae-92-92.csw4.Washington1.Level3.net (4.69.134.158) 74.941 ms 73.267 ms ae-72-72.csw2.Washington1.Level3.net (4.69.134.150) 80.951 ms 11 ae-2-79.edge3.Washington4.Level3.net (4.68.17.85) 74.694 ms ae-1-69.edge3.Washington4.Level3.net (4.68.17.21) 108.301 ms ae-2-79.edge3.Washington4.Level3.net (4.68.17.85) 80.238 ms 12 FACEBOOK-IN.edge3.Washington4.Level3.net (4.53.116.6) 110.998 ms 13 ae2.bb02.iad2.tfbnw.net (74.119.77.148) 89.248 ms 86.623 ms 85.374 14 ae11.bb02.sjc1.tfbnw.net (74.119.77.199) 114.421 ms 117.183 ms 15 ae1.dr01.snc5.tfbnw.net (74.119.77.182) 96.802 ms ae2.dr01.snc5.tfbnw.net (74.119.77.184) 99.674 ms ae1.dr02.snc5.tfbnw.net (74.119.77.190) 98.270 ms 16 po509.csw02b.snc5.tfbnw.net (74.119.78.28) 94.258 ms po509.csw02a.snc5.tfbnw.net (74.119.78.24) 94.511 ms po510.csw02b.snc5.tfbnw.net (74.119.78.26) 94.792 ms 17 * * * 18 * * * 19 * * * The 10 minutes ago the Aikami frontend answered with this: ----------------------------------------------- Service Unavailable - Zero size object The server is temporarily unable to service your request. Please try again later. Reference #15.16ce33b8.1285271433.6b82b ----------------------------------------------- Looks like the FaceBook backend is still down. We wait (and be more productive in our *real* job) :) --- Jay Nugent Nugent Telecommunications Ypsilanti, Michigan Train how you will Operate, and you will Operate how you were Trained. +------------------------------------------------------------------------+ | Jay Nugent jjn at nuge.com (734)484-5105 (734)649-0850/Cell | | Nugent Telecommunications [www.nuge.com] | | Internet Consulting/Linux SysAdmin/Engineering & Design/ISP Reseller | | ISP Monitoring [www.ispmonitor.org] ISP & Modem Performance Monitoring | | Web-Pegasus [www.webpegasus.com] Web Hosting/DNS Hosting/Shell Accts| +------------------------------------------------------------------------+ 3:01pm up 15 days, 23:02, 4 users, load average: 0.03, 0.03, 0.03 From pstewart at nexicomgroup.net Thu Sep 23 19:58:30 2010 From: pstewart at nexicomgroup.net (Paul Stewart) Date: Thu, 23 Sep 2010 15:58:30 -0400 Subject: Facebook Issues/Outage in Southeast? In-Reply-To: <9C0EF4B3-A4B5-42D6-AB19-DECB714049B9@cs.fiu.edu> References: <9C0EF4B3-A4B5-42D6-AB19-DECB714049B9@cs.fiu.edu> Message-ID: outages at outages.org ;) -----Original Message----- From: James Grace [mailto:james at cs.fiu.edu] Sent: Thursday, September 23, 2010 3:58 PM To: Paul Stewart Cc: Ernie Rubi; nanog at nanog.org Subject: Re: Facebook Issues/Outage in Southeast? Which outages list? James On Sep 23, 2010, at 3:40 PM, Paul Stewart wrote: > Over on the outages list there is a lot of discussion... I believe > everyone is effected - we are peered with them in several locations and > cannot reach them. > > Paul > > > -----Original Message----- > From: Ernie Rubi [mailto:ernesto at cs.fiu.edu] > Sent: Thursday, September 23, 2010 3:39 PM > To: nanog at nanog.org > Subject: Facebook Issues/Outage in Southeast? > > Anyone else having trouble? We're colo'ed at the NOTA in Miami and > directly peer with them - even though our session hasn't gone down we > still can't reach them. > > Ernesto M. Rubi > Sr. Network Engineer > AMPATH/CIARA > Florida International Univ, Miami > Reply-to: ernesto at cs.fiu.edu > Cell: 786-282-6783 > > > > From jeroen at mompl.net Thu Sep 23 20:00:04 2010 From: jeroen at mompl.net (Jeroen van Aart) Date: Thu, 23 Sep 2010 13:00:04 -0700 Subject: Facebook Issues/Outage in Southeast? In-Reply-To: References: Message-ID: <4C9BB1C4.3010701@mompl.net> (apologies for cross posting) Ernie Rubi wrote: > Anyone else having trouble? We're colo'ed at the NOTA in Miami and directly peer with them - even though our session hasn't gone down we still can't reach them. It will be interesting to see if global spam traffic goes down as well? Since that's pretty much facebook's raison d'?tre. -- http://goldmark.org/jeff/stupid-disclaimers/ http://linuxmafia.com/~rick/faq/plural-of-virus.html From wbailey at gci.com Thu Sep 23 20:02:02 2010 From: wbailey at gci.com (Warren Bailey) Date: Thu, 23 Sep 2010 12:02:02 -0800 Subject: Facebook Issues/Outage in Southeast? In-Reply-To: <680640083-1285271322-cardhu_decombobulator_blackberry.rim.net-1824705191-@bda002.bisx.prod.on.blackberry> References: <680640083-1285271322-cardhu_decombobulator_blackberry.rim.net-1824705191-@bda002.bisx.prod.on.blackberry> Message-ID: <1560B9D6-9F37-46E5-BB22-87BD7491D6D2@gci.com> We have our guys here in Alaska checking SIX in Seattle now. Sent from a mobile phone with a small keyboard, please excuse my mistakes. On Sep 23, 2010, at 11:59 AM, "deleskie at gmail.com" wrote: > Having issues from the north east as well. > ------Original Message------ > From: Ernie Rubi > To: nanog at nanog.org > Subject: Facebook Issues/Outage in Southeast? > Sent: Sep 23, 2010 4:39 PM > > Anyone else having trouble? We're colo'ed at the NOTA in Miami and directly peer with them - even though our session hasn't gone down we still can't reach them. > > Ernesto M. Rubi > Sr. Network Engineer > AMPATH/CIARA > Florida International Univ, Miami > Reply-to: ernesto at cs.fiu.edu > Cell: 786-282-6783 > > > > > > > Sent from my BlackBerry device on the Rogers Wireless Network > From jlewis at lewis.org Thu Sep 23 20:01:19 2010 From: jlewis at lewis.org (Jon Lewis) Date: Thu, 23 Sep 2010 16:01:19 -0400 (EDT) Subject: Facebook Issues/Outage in Southeast? In-Reply-To: <9DFEEE61-5562-4157-841A-5C1B9EEA55EF@cs.columbia.edu> References: <9DFEEE61-5562-4157-841A-5C1B9EEA55EF@cs.columbia.edu> Message-ID: On Thu, 23 Sep 2010, Steven Bellovin wrote: > > On Sep 23, 2010, at 3:40 59PM, Paul Stewart wrote: > >> Over on the outages list there is a lot of discussion... I believe >> everyone is effected - we are peered with them in several locations and >> cannot reach them. >> > > http://blogs.wsj.com/digits/2010/09/22/facebook-goes-down-for-some-users/ That's about yesterday's outage...but it has a helpful link to Facebook's twitter, where they apparently just posted[1] We've fixed the issue with a third-party networking provider, and anyone impacted should be able to access Facebook normally. yet facebook.com is still largely busted. The main page took quite a while, but did eventually load. Clicking links on it yields: Service Unavailable - DNS failure The server is temporarily unable to service your request. Please try again later. Reference #11.e321d0d1.1285271763.14f5425 I think they're still dealing with some issues. [1] I don't use twitter, and though it says that was posted "less than 20 seconds ago via HootSuite", I call BS...because minutes later, it still says "less than 20 seconds ago..." So for all I know, that could be their tweet from yesterday. ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From daodennis at gmail.com Thu Sep 23 20:03:25 2010 From: daodennis at gmail.com (Dennis) Date: Thu, 23 Sep 2010 13:03:25 -0700 Subject: Facebook Issues/Outage in Southeast? In-Reply-To: <680640083-1285271322-cardhu_decombobulator_blackberry.rim.net-1824705191-@bda002.bisx.prod.on.blackberry> References: <680640083-1285271322-cardhu_decombobulator_blackberry.rim.net-1824705191-@bda002.bisx.prod.on.blackberry> Message-ID: It's up in the PNW for me. Then again we peer with them at the six... From jmamodio at gmail.com Thu Sep 23 20:03:45 2010 From: jmamodio at gmail.com (Jorge Amodio) Date: Thu, 23 Sep 2010 15:03:45 -0500 Subject: Facebook Issues/Outage in Southeast? In-Reply-To: References: <471277240-1285270865-cardhu_decombobulator_blackberry.rim.net-1324398093-@bda899.bisx.prod.on.blackberry> Message-ID: It may be some chunk of akamai being down/unreachable, no noticeable issues from TWC in SATX. J From hj1980 at gmail.com Thu Sep 23 20:04:10 2010 From: hj1980 at gmail.com (Heath Jones) Date: Thu, 23 Sep 2010 21:04:10 +0100 Subject: Facebook Issues/Outage in Southeast? In-Reply-To: References: <471277240-1285270865-cardhu_decombobulator_blackberry.rim.net-1324398093-@bda899.bisx.prod.on.blackberry> Message-ID: > I can ping them but not access them over Cogent here in Tysons Corner, Virginia - looks like a server issue to me. Want to see something funnier: http://downrightnow.com/ Exactly the same as what your seeing for facebook. Working icmp, broken http. I wonder if 10^234 people are all trying to find out if facebook is down by going to this site, and crashing it.. :) From cb.list6 at gmail.com Thu Sep 23 20:04:56 2010 From: cb.list6 at gmail.com (Cameron Byrne) Date: Thu, 23 Sep 2010 13:04:56 -0700 Subject: Facebook Issues/Outage in Southeast? In-Reply-To: References: <471277240-1285270865-cardhu_decombobulator_blackberry.rim.net-1324398093-@bda899.bisx.prod.on.blackberry> Message-ID: IPv6 seems to be working fine for me www.v6.facebook.com :) Cameron ========== http://groups.google.com/group/tmoipv6beta =========== From Greg.Whynott at oicr.on.ca Thu Sep 23 20:05:11 2010 From: Greg.Whynott at oicr.on.ca (Greg Whynott) Date: Thu, 23 Sep 2010 16:05:11 -0400 Subject: Facebook Issues/Outage in Southeast? In-Reply-To: References: Message-ID: <83D42F3C-A666-460C-8AC9-962C6754B79E@oicr.on.ca> productivity in NA just sky rocketed! -g On Sep 23, 2010, at 3:39 PM, Ernie Rubi wrote: > Anyone else having trouble? We're colo'ed at the NOTA in Miami and directly peer with them - even though our session hasn't gone down we still can't reach them. > > Ernesto M. Rubi > Sr. Network Engineer > AMPATH/CIARA > Florida International Univ, Miami > Reply-to: ernesto at cs.fiu.edu > Cell: 786-282-6783 > > > > From randy at psg.com Thu Sep 23 20:05:45 2010 From: randy at psg.com (Randy Bush) Date: Thu, 23 Sep 2010 16:05:45 -0400 Subject: Facebook Issues/Outage in Southeast? In-Reply-To: <9C0EF4B3-A4B5-42D6-AB19-DECB714049B9@cs.fiu.edu> References: <9C0EF4B3-A4B5-42D6-AB19-DECB714049B9@cs.fiu.edu> Message-ID: fb is looking good from nevis. dunno about st kitts. randy From bclark at spectraaccess.com Thu Sep 23 20:07:25 2010 From: bclark at spectraaccess.com (bret clark) Date: Thu, 23 Sep 2010 16:07:25 -0400 Subject: Facebook Issues/Outage in Southeast? In-Reply-To: <9DFEEE61-5562-4157-841A-5C1B9EEA55EF@cs.columbia.edu> References: <9DFEEE61-5562-4157-841A-5C1B9EEA55EF@cs.columbia.edu> Message-ID: <4C9BB37D.7060806@spectraaccess.com> Whoa...there is clairvoyance for you...that article is from yesterday...wonder if the author provides stock tips??? Facebook down...where is the "Like" button? On 9/23/2010 3:46 PM, Steven Bellovin wrote: > > http://blogs.wsj.com/digits/2010/09/22/facebook-goes-down-for-some-users/ > > --Steve Bellovin, http://www.cs.columbia.edu/~smb > > > > > > From harry.nanog at harry.lu Thu Sep 23 20:08:48 2010 From: harry.nanog at harry.lu (Harry Strongburg) Date: Thu, 23 Sep 2010 20:08:48 +0000 Subject: Facebook Issues/Outage in Southeast? In-Reply-To: <8C164D3BAF7C7F41B9B286385037B1310D3646D683@lax-exch-fe-01.gorillanation.local> References: <8C164D3BAF7C7F41B9B286385037B1310D3646D683@lax-exch-fe-01.gorillanation.local> Message-ID: <20100923200848.GA8135@harry.lu> On Thu, Sep 23, 2010 at 12:43:44PM -0700, Justin Horstman wrote: > Via http://downforeveryoneorjustme.com/facebook.com > It's not just you! http://facebook.com looks down from here. That tool is very inefficient and often incorrect. It's up for me in the North-East. Should be back now, I hope. From jmamodio at gmail.com Thu Sep 23 20:10:01 2010 From: jmamodio at gmail.com (Jorge Amodio) Date: Thu, 23 Sep 2010 15:10:01 -0500 Subject: Facebook Issues/Outage in Southeast? In-Reply-To: References: <471277240-1285270865-cardhu_decombobulator_blackberry.rim.net-1324398093-@bda899.bisx.prod.on.blackberry> Message-ID: On Thu, Sep 23, 2010 at 3:03 PM, Jorge Amodio wrote: > It may be some chunk of akamai being down/unreachable, no noticeable > issues from TWC in SATX. Change that, it is down from here too now ... packets don't get out of tbone.rr.com from here. J From rudi.daniel at gmail.com Thu Sep 23 20:10:59 2010 From: rudi.daniel at gmail.com (Rudolph Daniel) Date: Thu, 23 Sep 2010 16:10:59 -0400 Subject: facebook outrage Message-ID: Facebook from the Caribbean Service Unavailable - DNS failureThe server is temporarily unable to service your request. Please try again later. Reference #11.1d9c1160.1285272538.81cae85 RD On Thu, Sep 23, 2010 at 3:46 PM, wrote: > Send NANOG mailing list submissions to > nanog at nanog.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://mailman.nanog.org/mailman/listinfo/nanog > or, via email, send a message with subject or body 'help' to > nanog-request at nanog.org > > You can reach the person managing the list at > nanog-owner at nanog.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of NANOG digest..." > > > Today's Topics: > > 1. RE: IDS IPS (Ryan Bradley) > 2. Re: Odd BGP AS Path (Warren Kumari) > 3. Re: Odd BGP AS Path (Randy Bush) > 4. CFP: COMSNETS 2011 (Deadline in 4 days: Sept 27, 11:59pm PDT) > (Ramana Kompella) > 5. Facebook Issues/Outage in Southeast? (Ernie Rubi) > 6. RE: Facebook Issues/Outage in Southeast? (Paul Stewart) > 7. Re: Facebook Issues/Outage in Southeast? (chaim rieger) > 8. Re: Facebook Issues/Outage in Southeast? (andrew.wallace) > 9. Facebook Issues/Outage in Southeast? (Ernie Rubi) > 10. RE: Facebook Issues/Outage in Southeast? (Justin Horstman) > 11. Re: Facebook Issues/Outage in Southeast? (Steven Bellovin) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 23 Sep 2010 09:58:40 -0400 > From: "Ryan Bradley" > Subject: RE: IDS IPS > To: "Joshua William Klubi" , "North American > Network Operators Group" > Message-ID: > <661FEAF65459994780CE520E3F212EE4DF51D7 at a1server4.a1fcu.org> > Content-Type: text/plain; charset="us-ascii" > > Joshua, > > We use the Juniper 2xx series IDP; highly recommended. We are a small > financial intuition with about 200 employees and 13 branch locations. > > I'd stay far away from SecureWorks if you're looking to manage the > device yourself; if you're looking for an overpriced managed solution > then they'd be okay. > > Ryan > > -----Original Message----- > From: Joshua William Klubi [mailto:joshua.klubi at gmail.com] > Sent: Wednesday, September 22, 2010 12:12 PM > To: North American Network Operators Group > Subject: IDS IPS > > Hi, > > I have been tasked to get the best IDS and IPS for our internal LAN and > WAN > in a Banking infrastructure. > I would like ask if any one has deployed in any network with such > technology, and also if any one can recommend > a very good IDS and IPS for me to recommend to management > > Thank you. > > Joshua > > > > ------------------------------ > > Message: 2 > Date: Thu, 23 Sep 2010 10:48:43 -0400 > From: Warren Kumari > Subject: Re: Odd BGP AS Path > To: Florian Weimer > Cc: nanog at nanog.org > Message-ID: <303A7C18-0831-4A8E-85BA-3600F87D067D at kumari.net> > Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes > > > On Sep 22, 2010, at 4:15 PM, Florian Weimer wrote: > > > * Randy Bush: > > > >>> Probably a silly question, but can anyone explain to me this: > >>> 3561 3356 9031 {35821,35821,35821,35821} i > >> > >> please support draft-wkumari-deprecate-as-sets-00.txt > > > > Mere deprecation does not stop propagation of such paths. > > That's very true, but it *does* move us in the right direction -- > saying "Aggregation that results in AS_SETs is prohibited, off with > your head" isn't going to fly in the IDR WG when there are routes > that use them... > > Suggesting the people do not perform aggregation that results in the > creation of AS_SETs (and AS_CONFED_SETs), and that operators filter > such announcements will lead to a time where they just don't exist any > more [0] (and then can be removed from the protocol). > > We are also specifying that new BGP work does not need to support > AS_.*SET ;-) > > W > > -- > "Being the Fun-Police in the global Internet is a thankless - and > probably futile - task." > -- R. Whittle ("draft-whittle-sram-ip-forwarding-01.txt") > > > > > > > > > ------------------------------ > > Message: 3 > Date: Thu, 23 Sep 2010 10:59:07 -0400 > From: Randy Bush > Subject: Re: Odd BGP AS Path > To: Warren Kumari > Cc: nanog at nanog.org > Message-ID: > > Content-Type: text/plain; charset=US-ASCII > > just to uncloak a bit. when we first decided to look at deprecating > as-sets et alia, we begged olaf maennel to analyse the use thereof. the > following is edited from internal email from early august. we then > begged one of our number, warren, to do the dirty, and he was kind > enough to do so. we owe him. > > --- > > using data from ripe r00 > > years total real > stable as-sets as-sets > 7 4 2 > 6 6 2 > 5 20 3 > 4 22 5 > 3 64 16 > 2 214 87 > 1 875 289 > > years stable is how many years that as-set was announced for that > prefix. > > total as-sets is the number of prefixes that had any as-set. > > real as-sets is the number of prefixes with as-sets which were not > singleton asns and were not private asns. > > olaf scanned for ten years but none were stable for more than seven. > > in ten years, 1205 different prefixes with as-sets were seen. removing > private asns and removing singletons left only 404 prefixes over the ten > years. > > he did not check for covering prefixes, i.e. two prefixes with the same > as-set where one was a sub-prefix of the other, longer, one. > > and i suspect the data are somewhat self-similar. i.e. the 289 that > were stable for the last year may have shorter term components which > were much higher. i.e. looking at data for a week or a day may give > higher values. > > a graph which should be pretty self-explanitory may be found at > > > http://archive.psg.com/fraction-and-absolute-number-of-ASsets-in-table-over-time-valids-only.pdf > > it is interesting that, at no time, i.e. in no single rib dump, were > there more than 23 prefixes with as-sets. while this is suspicious, it > seems to be true. > > randy > > > > ------------------------------ > > Message: 4 > Date: Thu, 23 Sep 2010 12:10:57 -0400 > From: Ramana Kompella > Subject: CFP: COMSNETS 2011 (Deadline in 4 days: Sept 27, 11:59pm PDT) > > To: nanog at nanog.org > Message-ID: <20100923161057.GA7221 at tirupati> > Content-Type: text/plain; charset=utf-8 > > *** APOLOGIES IF YOUR RECEIVED MULTIPLE COPIES OF THE CFP *** > > *** EXTENDED FIRM DEADLINE in exactly 4 days: Sept 27, 11:59pm PDT *** > > > COMSNETS 2011 > The THIRD International Conference on COMunication Systems and NETworks > January 4-8, 2011, Bangalore, India > http://www.comsnets.org > (In Co-operation with ACM SIGMOBILE) > (Technically Co-Sponsored by IEEE COMSOC) > > The Third International Conference on COMmunication Systems and > NETworkS (COMSNETS) will be held in Bangalore, India, from 4 January > 2011 to 8 January 2011. COMSNETS is a premier international conference > dedicated to addressing advances in Networking and Communications > Systems, and Telecommunications services. The goal of the conference > is to create a world-class gathering of researchers from academia and > industry, practitioners, business leaders, intellectual property > experts, and venture capitalists, providing a forum for discussing > cutting edge research, and directions for new innovative business and > technology. > > The conference will include a highly selective technical program > consisting of parallel tracks of submitted papers, a small set of > invited papers on important and timely topics from well-known leaders > in the field, and poster sessions of work in progress. Focused > workshops and panel discussions will be held on emerging topics to > allow for a lively exchange of ideas. International business and > government leaders will be invited to share their perspectives, thus > complementing the technical program. > > Papers describing original research work and practical > experiences/experimental results are solicited on topics including, > but not limited to: > > > > Topics of Interest > ------------------ > Internet Architecture and Protocols > Network-based Applications > Video Distribution (IPTV, Mobile Video, Video on Demand) > Network Operations and Management > Broadband and Cellular Networks (3G/4G, WiMAX/LTE) > Mesh, Sensor and PAN Networks > Communication Software (Cognitive Radios, DSA, SDR) > Wireless Operating Systems and Mobile Platforms > Peer-to-peer Networking > Cognitive Radio and White Space Networking > Optical Networks > Network Security & Cyber Security Technologies > Cloud and Utility computing > Storage Area Networks > Next Generation Web Architectures > Vehicular Networking > Energy-Efficient Networking > Network Science and Emergent Behavior in Socio-Technical Networks > Social Networking Analysis, Middleware and Applications > Networking Technologies for Smart Energy Grids > Disruption/Delay Tolerant Networking > > Conference Highlights > --------------------- > Banquet speaker: > Dr. Rajeev Rastogi, Yahoo Research, India > Keynote Speakers: > ? Prof. Don Towsley, U. Mass Amherst, USA > ? Dr. Pravin Bhagwat, AirTight Networks, India > ? Dr. Jean Bolot, Sprint, USA > Workshops > ? WISARD (4, 5 Jan) > ? NetHealth (4 Jan) > ? IAMCOM (5 Jan) > ? Mobile India 2011 (7 Jan) > Technical Paper and Poster Sessions > Ph.D Forum > Panel Discussions > Demos & Exhibits > > Important Deadlines > ------------------- > Paper submission (FIRM, ABSOLUTELY NO EXTENSIONS): September 27, 2010 at > 11:59 pm EDT (Sept 28, 9:29 am IST) > Notification of Acceptance: November 8, 2010 > Camera-Ready Submission: December 8, 2010 > > Detailed conference information and paper submission guidelines is > available on the conference web site. Please see > http://www.comsnets.org for detailed information from time to > time. The conference email address is: comsnets2011 at gmail.com > > General Co-Chairs > ----------------- > David B. Johnson, Rice University, USA > Anurag Kumar, IISc Bangalore, India > > Technical Program Co-Chairs > --------------------------- > Jon Crowcroft, U. of Cambridge, UK > D. Manjunath, IIT Bombay, India > Archan Misra, Telcordia Tech., USA > > Steering Committee Co-Chairs > ---------------------------- > Uday Desai, IIT Hyderabad, India > Giridhar Mandyam, Qualcomm, USA > Sanjoy Paul, Infosys, India > Rajeev Shorey, NIIT University, India > G. Venkatesh, SASKEN, India > > Panel Co-Chairs > --------------- > Aditya Akella, U. of Wisconsin, USA > Venkat Padmanabhan, MSR, India > > Ph.D Forum Chair > ---------------- > Bhaskaran Raman, IIT Bombay, India > > Publications Chair > ------------------ > Varsha Apte, IIT Bombay, India > > Demos and Exhibits Co-Chairs > ---------------------------- > Aaditeshwar Seth, IIT Delhi, India > Ajay Bakre, Netapps, India > > Sponsorship Chair > ----------------- > Sudipta Maitra, Delhi, india > > Workshop Chairs > --------------- > Sharad Jaiswal, Alcatel-Lucent, India > Ravindran Kaliappa, CUNY, USA > Neelesh Mehta, IISc Bangalore, India > > Mobile India 2011 Co-Chairs > --------------------------- > Gulzar Azad, Google, India > Gene Landy, Ruperto-Israel & Weiner, USA > Rajaraghavan Setlur, SASKEN, India > Sridhar Varadharajan, SASKEN, India > > Publicity Co-Chair > ------------------ > Augustin Chaintreau, TTL, France > Kameswari Chebrolu, IIT Bombay, India > Song Chong, KAIST, Korea > Ramana Kompella, Purdue Univ, USA > Nishanth Sastry, U. of Cambridge, UK > > Web Co-Chairs > ------------- > Santhana Krishnan, IIT Bombay, India > Vinay Veerappa, SASKEN, India > > International Advisory Committee > -------------------------------- > K. K. Ramakrishnan, AT&T, USA > Victor Bahl, Microsoft Research, USA > Sunghyun Choi, Seoul National U., Korea > Sajal Das, U. Texas at Arlington, USA > B. N. Jain, IIT Delhi, India > Anurag Kumar, IISc, Bangalore, India > L. M. Patnaik, IISc, Bangalore, India > Krithi Ramamritham, IIT Bombay, India > Parmesh Ramanathan, U. Wisconsin, USA > Krishan Sabnani, Alcatel-Lucent, USA > Kang Shin, U. Michigan, USA > Nitin Vaidya, U. Illinois, USA > > University Partners: > -------------------- > IIT Bombay, IIT Delhi, IISc Bangalore, IIT Hyderabad, NIIT University, IIIT > Bangalore, BITS Pilani > > > Patrons: > -------- > Mobile Monday Bangalore, Sasken, IBM Research, Alcatel Lucent > > > > ------------------------------ > > Message: 5 > Date: Thu, 23 Sep 2010 15:39:15 -0400 > From: Ernie Rubi > Subject: Facebook Issues/Outage in Southeast? > To: nanog at nanog.org > Message-ID: > Content-Type: text/plain; charset=us-ascii > > Anyone else having trouble? We're colo'ed at the NOTA in Miami and directly > peer with them - even though our session hasn't gone down we still can't > reach them. > > Ernesto M. Rubi > Sr. Network Engineer > AMPATH/CIARA > Florida International Univ, Miami > Reply-to: ernesto at cs.fiu.edu > Cell: 786-282-6783 > > > > > > > ------------------------------ > > Message: 6 > Date: Thu, 23 Sep 2010 15:40:59 -0400 > From: "Paul Stewart" > Subject: RE: Facebook Issues/Outage in Southeast? > To: "Ernie Rubi" , > Message-ID: > > Content-Type: text/plain; charset="us-ascii" > > Over on the outages list there is a lot of discussion... I believe > everyone is effected - we are peered with them in several locations and > cannot reach them. > > Paul > > > -----Original Message----- > From: Ernie Rubi [mailto:ernesto at cs.fiu.edu] > Sent: Thursday, September 23, 2010 3:39 PM > To: nanog at nanog.org > Subject: Facebook Issues/Outage in Southeast? > > Anyone else having trouble? We're colo'ed at the NOTA in Miami and > directly peer with them - even though our session hasn't gone down we > still can't reach them. > > Ernesto M. Rubi > Sr. Network Engineer > AMPATH/CIARA > Florida International Univ, Miami > Reply-to: ernesto at cs.fiu.edu > Cell: 786-282-6783 > > > > > > > > ------------------------------ > > Message: 7 > Date: Thu, 23 Sep 2010 19:41:04 +0000 > From: "chaim rieger" > Subject: Re: Facebook Issues/Outage in Southeast? > To: "Ernie Rubi" ,nanog at nanog.org > Message-ID: > > <471277240-1285270865-cardhu_decombobulator_blackberry.rim.net-1324398093- at bda899.bisx.prod.on.blackberry > > > > Content-Type: text/plain > > Yes tis down. Watch productivity go up > ------Original Message------ > From: Ernie Rubi > To: nanog at nanog.org > Subject: Facebook Issues/Outage in Southeast? > Sent: Sep 23, 2010 12:39 > > Anyone else having trouble? We're colo'ed at the NOTA in Miami and directly > peer with them - even though our session hasn't gone down we still can't > reach them. > > Ernesto M. Rubi > Sr. Network Engineer > AMPATH/CIARA > Florida International Univ, Miami > Reply-to: ernesto at cs.fiu.edu > Cell: 786-282-6783 > > > > > > > > > > ------------------------------ > > Message: 8 > Date: Thu, 23 Sep 2010 12:41:45 -0700 (PDT) > From: "andrew.wallace" > Subject: Re: Facebook Issues/Outage in Southeast? > To: Ernie Rubi > Cc: nanog at nanog.org > Message-ID: <581294.59169.qm at web59605.mail.ac4.yahoo.com> > Content-Type: text/plain; charset=utf-8 > > Over the last 30 minutes or more (UK) > > Andrew > > > > ----- Original Message ---- > From: Ernie Rubi > To: nanog at nanog.org > Sent: Thu, 23 September, 2010 20:39:15 > Subject: Facebook Issues/Outage in Southeast? > > Anyone else having trouble? We're colo'ed at the NOTA in Miami and directly > peer > with them - even though our session hasn't gone down we still can't reach > them. > > Ernesto M. Rubi > Sr. Network Engineer > AMPATH/CIARA > Florida International Univ, Miami > Reply-to: ernesto at cs.fiu.edu > Cell: 786-282-6783 > > > > > > > > ------------------------------ > > Message: 9 > Date: Thu, 23 Sep 2010 15:39:15 -0400 > From: Ernie Rubi > Subject: Facebook Issues/Outage in Southeast? > To: nanog at nanog.org > Message-ID: > Content-Type: text/plain; charset=us-ascii > > Anyone else having trouble? We're colo'ed at the NOTA in Miami and directly > peer with them - even though our session hasn't gone down we still can't > reach them. > > Ernesto M. Rubi > Sr. Network Engineer > AMPATH/CIARA > Florida International Univ, Miami > Reply-to: ernesto at cs.fiu.edu > Cell: 786-282-6783 > > > > > > > ------------------------------ > > Message: 10 > Date: Thu, 23 Sep 2010 12:43:44 -0700 > From: Justin Horstman > Subject: RE: Facebook Issues/Outage in Southeast? > To: 'Ernie Rubi' , "nanog at nanog.org" > > Message-ID: > > <8C164D3BAF7C7F41B9B286385037B1310D3646D683 at lax-exch-fe-01.gorillanation.local > > > > Content-Type: text/plain; charset="us-ascii" > > Via http://downforeveryoneorjustme.com/facebook.com > > It's not just you! http://facebook.com looks down from here. > > Also down from LA, qwest has been having issues today as well, not sure if > its related. > > > > > > > -----Original Message----- > > From: Ernie Rubi [mailto:ernesto at cs.fiu.edu] > > Sent: Thursday, September 23, 2010 12:39 PM > > To: nanog at nanog.org > > Subject: Facebook Issues/Outage in Southeast? > > > > Anyone else having trouble? We're colo'ed at the NOTA in Miami and > > directly peer with them - even though our session hasn't gone down we > > still can't reach them. > > > > Ernesto M. Rubi > > Sr. Network Engineer > > AMPATH/CIARA > > Florida International Univ, Miami > > Reply-to: ernesto at cs.fiu.edu > > Cell: 786-282-6783 > > > > > > > > > > > ------------------------------ > > Message: 11 > Date: Thu, 23 Sep 2010 15:46:33 -0400 > From: Steven Bellovin > Subject: Re: Facebook Issues/Outage in Southeast? > To: Paul Stewart > Cc: nanog at nanog.org > Message-ID: <9DFEEE61-5562-4157-841A-5C1B9EEA55EF at cs.columbia.edu> > Content-Type: text/plain; charset=us-ascii > > > On Sep 23, 2010, at 3:40 59PM, Paul Stewart wrote: > > > Over on the outages list there is a lot of discussion... I believe > > everyone is effected - we are peered with them in several locations and > > cannot reach them. > > > > http://blogs.wsj.com/digits/2010/09/22/facebook-goes-down-for-some-users/ > > > > > --Steve Bellovin, http://www.cs.columbia.edu/~smb > > > > > > > > > ------------------------------ > > _______________________________________________ > NANOG mailing list > NANOG at nanog.org > https://mailman.nanog.org/mailman/listinfo/nanog > > End of NANOG Digest, Vol 32, Issue 82 > ************************************* > -- Rudi Daniel *danielcharles consulting **1-784 498 8277 * * * From sethm at rollernet.us Thu Sep 23 20:13:19 2010 From: sethm at rollernet.us (Seth Mattinen) Date: Thu, 23 Sep 2010 13:13:19 -0700 Subject: Facebook Issues/Outage in Southeast? In-Reply-To: <8C164D3BAF7C7F41B9B286385037B1310D3646D683@lax-exch-fe-01.gorillanation.local> References: <8C164D3BAF7C7F41B9B286385037B1310D3646D683@lax-exch-fe-01.gorillanation.local> Message-ID: <4C9BB4DF.9060102@rollernet.us> On 9/23/2010 12:43, Justin Horstman wrote: > Via http://downforeveryoneorjustme.com/facebook.com > > It's not just you! http://facebook.com looks down from here. > > Also down from LA, qwest has been having issues today as well, not sure if its related. > > However, www.v6.facebook.com works fine. ~Seth From jeff at briworks.com Thu Sep 23 20:15:18 2010 From: jeff at briworks.com (Jeff Cornejo) Date: Thu, 23 Sep 2010 13:15:18 -0700 Subject: Facebook Issues/Outage in Southeast? In-Reply-To: References: Message-ID: <2CEBFFDE-8CCE-43FB-AE19-9229A6C49C84@briworks.com> http://developers.facebook.com/live_status They are having a major API latency issue. Jeff Cornejo Blue Ridge InternetWorks 321 East Main St | Suite 200 | Charlottesville, VA | 22902 +1.434.817.0707 office +1.434.531.4141 mobile On Sep 23, 2010, at 3:39 PM, Ernie Rubi wrote: Anyone else having trouble? We're colo'ed at the NOTA in Miami and directly peer with them - even though our session hasn't gone down we still can't reach them. Ernesto M. Rubi Sr. Network Engineer AMPATH/CIARA Florida International Univ, Miami Reply-to: ernesto at cs.fiu.edu Cell: 786-282-6783 From jmamodio at gmail.com Thu Sep 23 20:15:59 2010 From: jmamodio at gmail.com (Jorge Amodio) Date: Thu, 23 Sep 2010 15:15:59 -0500 Subject: Facebook Issues/Outage in Southeast? In-Reply-To: References: <471277240-1285270865-cardhu_decombobulator_blackberry.rim.net-1324398093-@bda899.bisx.prod.on.blackberry> Message-ID: Looks that it came back up now ... root at tango:/var/cache/bind# ping -c 10 www.facebook.com PING a1254.g.akamai.net (209.18.43.169) 56(84) bytes of data. 64 bytes from 209-18-43-169.dfw10.tbone.rr.com (209.18.43.169): icmp_seq=1 ttl=57 time=15.8 ms 64 bytes from 209-18-43-169.dfw10.tbone.rr.com (209.18.43.169): icmp_seq=2 ttl=57 time=16.9 ms 64 bytes from 209-18-43-169.dfw10.tbone.rr.com (209.18.43.169): icmp_seq=3 ttl=57 time=17.2 ms 64 bytes from 209-18-43-169.dfw10.tbone.rr.com (209.18.43.169): icmp_seq=4 ttl=57 time=16.6 ms 64 bytes from 209-18-43-169.dfw10.tbone.rr.com (209.18.43.169): icmp_seq=5 ttl=57 time=17.2 ms 64 bytes from 209-18-43-169.dfw10.tbone.rr.com (209.18.43.169): icmp_seq=6 ttl=57 time=16.2 ms 64 bytes from 209-18-43-169.dfw10.tbone.rr.com (209.18.43.169): icmp_seq=7 ttl=57 time=17.0 ms 64 bytes from 209-18-43-169.dfw10.tbone.rr.com (209.18.43.169): icmp_seq=8 ttl=57 time=17.2 ms 64 bytes from 209-18-43-169.dfw10.tbone.rr.com (209.18.43.169): icmp_seq=9 ttl=57 time=16.7 ms 64 bytes from 209-18-43-169.dfw10.tbone.rr.com (209.18.43.169): icmp_seq=10 ttl=57 time=16.7 ms J From jcdill.lists at gmail.com Thu Sep 23 20:20:29 2010 From: jcdill.lists at gmail.com (JC Dill) Date: Thu, 23 Sep 2010 13:20:29 -0700 Subject: Facebook Issues/Outage in Southeast? In-Reply-To: <8C164D3BAF7C7F41B9B286385037B1310D3646D683@lax-exch-fe-01.gorillanation.local> References: <8C164D3BAF7C7F41B9B286385037B1310D3646D683@lax-exch-fe-01.gorillanation.local> Message-ID: <4C9BB68D.8020808@gmail.com> Justin Horstman wrote: > Via http://downforeveryoneorjustme.com/facebook.com > > It's not just you! http://facebook.com looks down from here. Is downforeveryoneorjustme.com down for everyone, or just me? > Error: Server Error > The server encountered an error and could not complete your request. > > If the problem persists, please report your problem and mention this > error message and the query that caused it. I wonder if it's melting under the load of people checking to see if facebook is down for everyone.... jc From tme at americafree.tv Thu Sep 23 20:20:50 2010 From: tme at americafree.tv (Marshall Eubanks) Date: Thu, 23 Sep 2010 16:20:50 -0400 Subject: Facebook Issues/Outage in Southeast? In-Reply-To: References: <9DFEEE61-5562-4157-841A-5C1B9EEA55EF@cs.columbia.edu> Message-ID: On Sep 23, 2010, at 4:01 PM, Jon Lewis wrote: > On Thu, 23 Sep 2010, Steven Bellovin wrote: > >> >> On Sep 23, 2010, at 3:40 59PM, Paul Stewart wrote: >> >>> Over on the outages list there is a lot of discussion... I believe >>> everyone is effected - we are peered with them in several locations and >>> cannot reach them. >>> >> >> http://blogs.wsj.com/digits/2010/09/22/facebook-goes-down-for-some-users/ > > That's about yesterday's outage...but it has a helpful link to Facebook's twitter, where they apparently just posted[1] > > We've fixed the issue with a third-party networking provider, and anyone > impacted should be able to access Facebook normally. > > yet facebook.com is still largely busted. The main page took quite a while, but did eventually load. Clicking links on it yields: > > Service Unavailable - DNS failure > > The server is temporarily unable to service your request. Please try > again later. > Reference #11.e321d0d1.1285271763.14f5425 > > I think they're still dealing with some issues. > > [1] I don't use twitter, and though it says that was posted "less than 20 seconds ago via HootSuite", I call BS...because minutes later, it still says "less than 20 seconds ago..." So for all I know, that could be their tweet from yesterday. If you are talking about the direct twitter GUI, it doesn't change the estimated delay time until you do something to refresh it (refresh the page, send new content, etc.). Regards Marshall > > ---------------------------------------------------------------------- > Jon Lewis, MCP :) | I route > Senior Network Engineer | therefore you are > Atlantic Net | > _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ > > From pfunix at gmail.com Thu Sep 23 20:27:27 2010 From: pfunix at gmail.com (Beavis) Date: Thu, 23 Sep 2010 14:27:27 -0600 Subject: Facebook Issues/Outage in Southeast? In-Reply-To: References: <471277240-1285270865-cardhu_decombobulator_blackberry.rim.net-1324398093-@bda899.bisx.prod.on.blackberry> Message-ID: are they down coz of DDoS? On Thu, Sep 23, 2010 at 2:04 PM, Cameron Byrne wrote: > IPv6 seems to be working fine for me www.v6.facebook.com :) > > > Cameron > ========== > http://groups.google.com/group/tmoipv6beta > =========== > > -- ()? ascii ribbon campaign - against html e-mail /\? www.asciiribbon.org?? - against proprietary attachments From drais at icantclick.org Thu Sep 23 20:28:08 2010 From: drais at icantclick.org (david raistrick) Date: Thu, 23 Sep 2010 16:28:08 -0400 (EDT) Subject: Facebook Issues/Outage in Southeast? In-Reply-To: References: <471277240-1285270865-cardhu_decombobulator_blackberry.rim.net-1324398093-@bda899.bisx.prod.on.blackberry> Message-ID: > Want to see something funnier: > http://downrightnow.com/ > > Exactly the same as what your seeing for facebook. Working icmp, broken http. downforeveryoneorjustme.com is/was returning intermittent 500 errors, too. fun day. ..d (twiddling his thumbs waiting to test newly built servers that require facebook) -- david raistrick http://www.netmeister.org/news/learn2quote.html drais at icantclick.org http://www.expita.com/nomime.html From surfer at mauigateway.com Thu Sep 23 20:29:11 2010 From: surfer at mauigateway.com (Scott Weeks) Date: Thu, 23 Sep 2010 13:29:11 -0700 Subject: Facebook Issues/Outage in Southeast? Message-ID: <20100923132911.1E698DB7@resin12.mta.everyone.net> --- jeroen at mompl.net wrote: From: Jeroen van Aart (apologies for cross posting) -------------------------------------- Then don't. Number 3: http://www.nanog.org/mailinglist scott From grobe0ba at gmail.com Thu Sep 23 20:30:16 2010 From: grobe0ba at gmail.com (Atticus) Date: Thu, 23 Sep 2010 16:30:16 -0400 Subject: Facebook Issues/Outage in Southeast? In-Reply-To: <83D42F3C-A666-460C-8AC9-962C6754B79E@oicr.on.ca> References: <83D42F3C-A666-460C-8AC9-962C6754B79E@oicr.on.ca> Message-ID: Forgot to CC my last reply. Managed to load over v6 once, then shot me the finger and said no more. Somebody forget to pay the internet bill this month? -- Byron Grobe From sethm at rollernet.us Thu Sep 23 20:31:05 2010 From: sethm at rollernet.us (Seth Mattinen) Date: Thu, 23 Sep 2010 13:31:05 -0700 Subject: Facebook Issues/Outage in Southeast? In-Reply-To: References: <471277240-1285270865-cardhu_decombobulator_blackberry.rim.net-1324398093-@bda899.bisx.prod.on.blackberry> Message-ID: <4C9BB909.8030805@rollernet.us> On 9/23/2010 13:04, Cameron Byrne wrote: > IPv6 seems to be working fine for me www.v6.facebook.com :) > Yep, works great. You guys should really upgrade your networks to something that works. ;) ~Seth From jabley at hopcount.ca Thu Sep 23 20:36:03 2010 From: jabley at hopcount.ca (Joe Abley) Date: Thu, 23 Sep 2010 16:36:03 -0400 Subject: Facebook Issues/Outage in Southeast? In-Reply-To: <8C164D3BAF7C7F41B9B286385037B1310D3646D683@lax-exch-fe-01.gorillanation.local> References: <8C164D3BAF7C7F41B9B286385037B1310D3646D683@lax-exch-fe-01.gorillanation.local> Message-ID: <9293270E-96DA-4668-85CC-122902D51D30@hopcount.ca> On 2010-09-23, at 15:43, Justin Horstman wrote: > Via http://downforeveryoneorjustme.com/facebook.com downforeveryoneorjustme.com is down for me. How about everybody else? :-) From strizhov at cs.colostate.edu Thu Sep 23 20:38:48 2010 From: strizhov at cs.colostate.edu (Mikhail Strizhov) Date: Thu, 23 Sep 2010 14:38:48 -0600 Subject: Facebook Issues/Outage in Southeast? In-Reply-To: References: Message-ID: <4C9BBAD8.2040602@cs.colostate.edu> Are they switching to Akamai ? From Northern Colorado: $ traceroute www.facebook.com traceroute to www.facebook.com (129.19.157.16), 30 hops max, 60 byte packets 3 129.82.2.9 (129.82.2.9) 6.284 ms 6.257 ms 6.229 ms 4 l3-gw-1-vl804.frgp.net (192.43.217.225) 6.201 ms 6.178 ms 6.155 ms 5 frgp-gw-2-te1-1.frgp.net (192.43.217.193) 6.114 ms 6.090 ms 6.063 ms 6 a129-19-157-16.deploy.akamaitechnologies.com (129.19.157.16) 6.003 ms 6.845 ms 6.796 ms From Russia: $ traceroute www.facebook.com 3 ttk-1-gw.smr.runnet.ru (194.85.43.133) 1.100 ms 1.333 ms 1.323 ms 4 m9-1-gw.msk.runnet.ru (194.85.43.181) 18.289 ms 18.403 ms 18.391 ms 5 b57-1-gw.spb.runnet.ru (194.85.40.134) 38.982 ms 38.656 ms 38.944 ms 6 tug11-1-gw.sth.runnet.ru (194.85.40.130) 43.814 ms 43.910 ms 43.901 ms 7 tug-1-gw.sth.runnet.ru (194.85.40.173) 193.293 ms 193.286 ms 193.386 ms 8 xe520-200.RT.TC1.STO.SE.retn.net (87.245.249.49) 40.957 ms 40.948 ms 41.057 ms 9 netnod-ix-ge-b-sth-1500.akamai.com (194.68.128.170) 41.909 ms 41.186 ms 41.157 ms 10 a92-123-155-73.deploy.akamaitechnologies.com (92.123.155.73) 40.886 ms 40.933 ms 40.911 ms -- Sincerely, Mikhail Strizhov Email: strizhov at cs.colostate.edu On 09/23/2010 01:58 PM, Jay Nugent wrote: > Greetings, > > On Thu, 23 Sep 2010, Justin Horstman wrote: > >> Via http://downforeveryoneorjustme.com/facebook.com >> >> It's not just you! http://facebook.com looks down from here. >> >> Also down from LA, qwest has been having issues today as well, not sure if its related. > About 45 minutes ago traceroutes died... > > [jjn at K2 ~]$ traceroute www.facebook.com > traceroute to www.facebook.com (66.220.149.18), 30 hops max, 60 byte > packets > 1 DR-LVL3.nuge.com (216.144.208.1) 1.083 ms 1.695 ms 1.934 ms > 2 * * * > 3 166.90.244.19 (166.90.244.19) 31.257 ms 34.148 ms 37.801 ms > 4 ge-5-0-155.hsa1.Detroit1.Level3.net (63.211.20.93) 41.258 ms 43.576 > 5 so-8-1.car1.Detroit1.Level3.net (4.69.140.118) 51.752 ms 54.577 ms > 6 ae-8-8.ebr2.Chicago1.Level3.net (4.69.133.242) 76.007 ms 75.161 ms > 7 ae-5-5.ebr2.Chicago2.Level3.net (4.69.140.194) 76.469 ms 48.544 ms > 8 ae-6-6.ebr2.Washington12.Level3.net (4.69.148.145) 64.813 ms 63.952 > 9 ae-5-5.ebr2.Washington1.Level3.net (4.69.143.221) 61.980 ms 63.616 > 10 ae-92-92.csw4.Washington1.Level3.net (4.69.134.158) 74.941 ms 73.267 > ms ae-72-72.csw2.Washington1.Level3.net (4.69.134.150) 80.951 ms > 11 ae-2-79.edge3.Washington4.Level3.net (4.68.17.85) 74.694 ms > ae-1-69.edge3.Washington4.Level3.net (4.68.17.21) 108.301 ms > ae-2-79.edge3.Washington4.Level3.net (4.68.17.85) 80.238 ms > 12 FACEBOOK-IN.edge3.Washington4.Level3.net (4.53.116.6) 110.998 ms > 13 ae2.bb02.iad2.tfbnw.net (74.119.77.148) 89.248 ms 86.623 ms 85.374 > 14 ae11.bb02.sjc1.tfbnw.net (74.119.77.199) 114.421 ms 117.183 ms > 15 ae1.dr01.snc5.tfbnw.net (74.119.77.182) 96.802 ms > ae2.dr01.snc5.tfbnw.net (74.119.77.184) 99.674 ms > ae1.dr02.snc5.tfbnw.net (74.119.77.190) 98.270 ms > 16 po509.csw02b.snc5.tfbnw.net (74.119.78.28) 94.258 ms > po509.csw02a.snc5.tfbnw.net (74.119.78.24) 94.511 ms > po510.csw02b.snc5.tfbnw.net (74.119.78.26) 94.792 ms > 17 * * * > 18 * * * > 19 * * * > > > > The 10 minutes ago the Aikami frontend answered with this: > > ----------------------------------------------- > Service Unavailable - Zero size object > The server is temporarily unable to service your request. Please try again > later. > > Reference #15.16ce33b8.1285271433.6b82b > ----------------------------------------------- > > > Looks like the FaceBook backend is still down. We wait (and be more > productive in our *real* job) :) > > > --- Jay Nugent > Nugent Telecommunications > Ypsilanti, Michigan > > > Train how you will Operate, and you will Operate how you were Trained. > +------------------------------------------------------------------------+ > | Jay Nugent jjn at nuge.com (734)484-5105 (734)649-0850/Cell | > | Nugent Telecommunications [www.nuge.com] | > | Internet Consulting/Linux SysAdmin/Engineering& Design/ISP Reseller | > | ISP Monitoring [www.ispmonitor.org] ISP& Modem Performance Monitoring | > | Web-Pegasus [www.webpegasus.com] Web Hosting/DNS Hosting/Shell Accts| > +------------------------------------------------------------------------+ > 3:01pm up 15 days, 23:02, 4 users, load average: 0.03, 0.03, 0.03 > > From wbailey at gci.com Thu Sep 23 20:45:57 2010 From: wbailey at gci.com (Warren Bailey) Date: Thu, 23 Sep 2010 12:45:57 -0800 Subject: Facebook Issues/Outage in Southeast? In-Reply-To: References: <8C164D3BAF7C7F41B9B286385037B1310D3646D683@lax-exch-fe-01.gorillanation.local> Message-ID: <09F712D9B8F7AF40BE523224B2487BA10FD14C3B@dtn1mbx01.gci.com> Here in Alaska, we have fiber going from Anchorage down to Seattle - where we peer with Facebook via SIX. We also host localized content for akamai, who in turn caches data for facebook. Our requests to facebook.com (dns wise) are handled through the akamai cluster on our internal 10 gig link - which gives the error: Service Unavailable - DNS failure The server is temporarily unable to service your request. Please try again later. Reference #11.1496a5d1.1285274423.4657e30a -----Original Message----- From: Jay Nugent [mailto:jjn at nuge.com] Sent: Thursday, September 23, 2010 11:59 AM To: Justin Horstman Cc: nanog at nanog.org Subject: RE: Facebook Issues/Outage in Southeast? Greetings, On Thu, 23 Sep 2010, Justin Horstman wrote: > Via http://downforeveryoneorjustme.com/facebook.com > > It's not just you! http://facebook.com looks down from here. > > Also down from LA, qwest has been having issues today as well, not sure if its related. About 45 minutes ago traceroutes died... [jjn at K2 ~]$ traceroute www.facebook.com traceroute to www.facebook.com (66.220.149.18), 30 hops max, 60 byte packets 1 DR-LVL3.nuge.com (216.144.208.1) 1.083 ms 1.695 ms 1.934 ms 2 * * * 3 166.90.244.19 (166.90.244.19) 31.257 ms 34.148 ms 37.801 ms 4 ge-5-0-155.hsa1.Detroit1.Level3.net (63.211.20.93) 41.258 ms 43.576 5 so-8-1.car1.Detroit1.Level3.net (4.69.140.118) 51.752 ms 54.577 ms 6 ae-8-8.ebr2.Chicago1.Level3.net (4.69.133.242) 76.007 ms 75.161 ms 7 ae-5-5.ebr2.Chicago2.Level3.net (4.69.140.194) 76.469 ms 48.544 ms 8 ae-6-6.ebr2.Washington12.Level3.net (4.69.148.145) 64.813 ms 63.952 9 ae-5-5.ebr2.Washington1.Level3.net (4.69.143.221) 61.980 ms 63.616 10 ae-92-92.csw4.Washington1.Level3.net (4.69.134.158) 74.941 ms 73.267 ms ae-72-72.csw2.Washington1.Level3.net (4.69.134.150) 80.951 ms 11 ae-2-79.edge3.Washington4.Level3.net (4.68.17.85) 74.694 ms ae-1-69.edge3.Washington4.Level3.net (4.68.17.21) 108.301 ms ae-2-79.edge3.Washington4.Level3.net (4.68.17.85) 80.238 ms 12 FACEBOOK-IN.edge3.Washington4.Level3.net (4.53.116.6) 110.998 ms 13 ae2.bb02.iad2.tfbnw.net (74.119.77.148) 89.248 ms 86.623 ms 85.374 14 ae11.bb02.sjc1.tfbnw.net (74.119.77.199) 114.421 ms 117.183 ms 15 ae1.dr01.snc5.tfbnw.net (74.119.77.182) 96.802 ms ae2.dr01.snc5.tfbnw.net (74.119.77.184) 99.674 ms ae1.dr02.snc5.tfbnw.net (74.119.77.190) 98.270 ms 16 po509.csw02b.snc5.tfbnw.net (74.119.78.28) 94.258 ms po509.csw02a.snc5.tfbnw.net (74.119.78.24) 94.511 ms po510.csw02b.snc5.tfbnw.net (74.119.78.26) 94.792 ms 17 * * * 18 * * * 19 * * * The 10 minutes ago the Aikami frontend answered with this: ----------------------------------------------- Service Unavailable - Zero size object The server is temporarily unable to service your request. Please try again later. Reference #15.16ce33b8.1285271433.6b82b ----------------------------------------------- Looks like the FaceBook backend is still down. We wait (and be more productive in our *real* job) :) --- Jay Nugent Nugent Telecommunications Ypsilanti, Michigan Train how you will Operate, and you will Operate how you were Trained. +------------------------------------------------------------------------+ | Jay Nugent jjn at nuge.com (734)484-5105 (734)649-0850/Cell | | Nugent Telecommunications [www.nuge.com] | | Internet Consulting/Linux SysAdmin/Engineering & Design/ISP Reseller | | ISP Monitoring [www.ispmonitor.org] ISP & Modem Performance Monitoring | | Web-Pegasus [www.webpegasus.com] Web Hosting/DNS Hosting/Shell Accts| +------------------------------------------------------------------------+ 3:01pm up 15 days, 23:02, 4 users, load average: 0.03, 0.03, 0.03 From wbailey at gci.com Thu Sep 23 20:52:14 2010 From: wbailey at gci.com (Warren Bailey) Date: Thu, 23 Sep 2010 12:52:14 -0800 Subject: Facebook Issues/Outage in Southeast? In-Reply-To: References: <471277240-1285270865-cardhu_decombobulator_blackberry.rim.net-1324398093-@bda899.bisx.prod.on.blackberry> Message-ID: <09F712D9B8F7AF40BE523224B2487BA10FD14C47@dtn1mbx01.gci.com> We've always been able to ping facebook, it seems the people with the most trouble are hitting akamai's caching. The 209.165.150.24 is local to us, as we host akamai for facebook in Alaska. ping www.facebook.com Pinging a1254.g.akamai.net [209.165.150.24] with 32 bytes of data: Reply from 209.165.150.24: bytes=32 time=41ms TTL=57 Reply from 209.165.150.24: bytes=32 time=4ms TTL=57 Reply from 209.165.150.24: bytes=32 time=4ms TTL=57 Reply from 209.165.150.24: bytes=32 time=8ms TTL=57 Ping statistics for 209.165.150.24: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 4ms, Maximum = 41ms, Average = 14ms -----Original Message----- From: Jorge Amodio [mailto:jmamodio at gmail.com] Sent: Thursday, September 23, 2010 12:16 PM To: nanog at nanog.org Subject: Re: Facebook Issues/Outage in Southeast? Looks that it came back up now ... root at tango:/var/cache/bind# ping -c 10 www.facebook.com PING a1254.g.akamai.net (209.18.43.169) 56(84) bytes of data. 64 bytes from 209-18-43-169.dfw10.tbone.rr.com (209.18.43.169): icmp_seq=1 ttl=57 time=15.8 ms 64 bytes from 209-18-43-169.dfw10.tbone.rr.com (209.18.43.169): icmp_seq=2 ttl=57 time=16.9 ms 64 bytes from 209-18-43-169.dfw10.tbone.rr.com (209.18.43.169): icmp_seq=3 ttl=57 time=17.2 ms 64 bytes from 209-18-43-169.dfw10.tbone.rr.com (209.18.43.169): icmp_seq=4 ttl=57 time=16.6 ms 64 bytes from 209-18-43-169.dfw10.tbone.rr.com (209.18.43.169): icmp_seq=5 ttl=57 time=17.2 ms 64 bytes from 209-18-43-169.dfw10.tbone.rr.com (209.18.43.169): icmp_seq=6 ttl=57 time=16.2 ms 64 bytes from 209-18-43-169.dfw10.tbone.rr.com (209.18.43.169): icmp_seq=7 ttl=57 time=17.0 ms 64 bytes from 209-18-43-169.dfw10.tbone.rr.com (209.18.43.169): icmp_seq=8 ttl=57 time=17.2 ms 64 bytes from 209-18-43-169.dfw10.tbone.rr.com (209.18.43.169): icmp_seq=9 ttl=57 time=16.7 ms 64 bytes from 209-18-43-169.dfw10.tbone.rr.com (209.18.43.169): icmp_seq=10 ttl=57 time=16.7 ms J From jared at puck.nether.net Thu Sep 23 20:53:30 2010 From: jared at puck.nether.net (Jared Mauch) Date: Thu, 23 Sep 2010 16:53:30 -0400 Subject: LISP Works - Re: Facebook Issues/Outage in Southeast? In-Reply-To: References: Message-ID: <846318A5-87EE-4F65-9A43-138D1B0236AF@puck.nether.net> It's working over LISP: http://www.lisp4.facebook.com/ On Sep 23, 2010, at 3:39 PM, Ernie Rubi wrote: > Anyone else having trouble? We're colo'ed at the NOTA in Miami and directly peer with them - even though our session hasn't gone down we still can't reach them. > > Ernesto M. Rubi > Sr. Network Engineer > AMPATH/CIARA > Florida International Univ, Miami > Reply-to: ernesto at cs.fiu.edu > Cell: 786-282-6783 > > > > From andrew.wallace at rocketmail.com Thu Sep 23 21:06:30 2010 From: andrew.wallace at rocketmail.com (andrew.wallace) Date: Thu, 23 Sep 2010 14:06:30 -0700 (PDT) Subject: Facebook Issues/Outage in Southeast? In-Reply-To: <20100923200848.GA8135@harry.lu> References: <8C164D3BAF7C7F41B9B286385037B1310D3646D683@lax-exch-fe-01.gorillanation.local> <20100923200848.GA8135@harry.lu> Message-ID: <357393.27987.qm@web59616.mail.ac4.yahoo.com> Up in United Kingdom. Andrew ----- Original Message ---- From: Harry Strongburg To: nanog at nanog.org Sent: Thu, 23 September, 2010 21:08:48 Subject: Re: Facebook Issues/Outage in Southeast? It's up for me in the North-East. Should be back now, I hope. From tme at americafree.tv Thu Sep 23 21:15:40 2010 From: tme at americafree.tv (Marshall Eubanks) Date: Thu, 23 Sep 2010 17:15:40 -0400 Subject: Facebook Issues/Outage in Southeast? In-Reply-To: <9293270E-96DA-4668-85CC-122902D51D30@hopcount.ca> References: <8C164D3BAF7C7F41B9B286385037B1310D3646D683@lax-exch-fe-01.gorillanation.local> <9293270E-96DA-4668-85CC-122902D51D30@hopcount.ca> Message-ID: <17FC9C8D-30F0-400D-999C-3A3EED186763@americafree.tv> It's up here in Virginia It's not just you! http://facebook.com looks down from here. Marshall On Sep 23, 2010, at 4:36 PM, Joe Abley wrote: > > On 2010-09-23, at 15:43, Justin Horstman wrote: > >> Via http://downforeveryoneorjustme.com/facebook.com > > downforeveryoneorjustme.com is down for me. How about everybody else? > > > :-) > > > From sikandar.raman at gmail.com Thu Sep 23 21:24:08 2010 From: sikandar.raman at gmail.com (Ramanpreet Singh) Date: Thu, 23 Sep 2010 14:24:08 -0700 Subject: Facebook Issues/Outage in Southeast? In-Reply-To: <09F712D9B8F7AF40BE523224B2487BA10FD14C47@dtn1mbx01.gci.com> References: <471277240-1285270865-cardhu_decombobulator_blackberry.rim.net-1324398093-@bda899.bisx.prod.on.blackberry> <09F712D9B8F7AF40BE523224B2487BA10FD14C47@dtn1mbx01.gci.com> Message-ID: its up and running now. try 69.63.189.16 On Thu, Sep 23, 2010 at 1:52 PM, Warren Bailey wrote: > We've always been able to ping facebook, it seems the people with the most trouble are hitting akamai's caching. The 209.165.150.24 is local to us, as we host akamai for facebook in Alaska. > > ping www.facebook.com > > Pinging a1254.g.akamai.net [209.165.150.24] with 32 bytes of data: > > Reply from 209.165.150.24: bytes=32 time=41ms TTL=57 > Reply from 209.165.150.24: bytes=32 time=4ms TTL=57 > Reply from 209.165.150.24: bytes=32 time=4ms TTL=57 > Reply from 209.165.150.24: bytes=32 time=8ms TTL=57 > > Ping statistics for 209.165.150.24: > ? ?Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), > Approximate round trip times in milli-seconds: > ? ?Minimum = 4ms, Maximum = 41ms, Average = 14ms > > > -----Original Message----- > From: Jorge Amodio [mailto:jmamodio at gmail.com] > Sent: Thursday, September 23, 2010 12:16 PM > To: nanog at nanog.org > Subject: Re: Facebook Issues/Outage in Southeast? > > Looks that it came back up now ... > > root at tango:/var/cache/bind# ping -c 10 www.facebook.com > PING a1254.g.akamai.net (209.18.43.169) 56(84) bytes of data. > 64 bytes from 209-18-43-169.dfw10.tbone.rr.com (209.18.43.169): > icmp_seq=1 ttl=57 time=15.8 ms > 64 bytes from 209-18-43-169.dfw10.tbone.rr.com (209.18.43.169): > icmp_seq=2 ttl=57 time=16.9 ms > 64 bytes from 209-18-43-169.dfw10.tbone.rr.com (209.18.43.169): > icmp_seq=3 ttl=57 time=17.2 ms > 64 bytes from 209-18-43-169.dfw10.tbone.rr.com (209.18.43.169): > icmp_seq=4 ttl=57 time=16.6 ms > 64 bytes from 209-18-43-169.dfw10.tbone.rr.com (209.18.43.169): > icmp_seq=5 ttl=57 time=17.2 ms > 64 bytes from 209-18-43-169.dfw10.tbone.rr.com (209.18.43.169): > icmp_seq=6 ttl=57 time=16.2 ms > 64 bytes from 209-18-43-169.dfw10.tbone.rr.com (209.18.43.169): > icmp_seq=7 ttl=57 time=17.0 ms > 64 bytes from 209-18-43-169.dfw10.tbone.rr.com (209.18.43.169): > icmp_seq=8 ttl=57 time=17.2 ms > 64 bytes from 209-18-43-169.dfw10.tbone.rr.com (209.18.43.169): > icmp_seq=9 ttl=57 time=16.7 ms > 64 bytes from 209-18-43-169.dfw10.tbone.rr.com (209.18.43.169): > icmp_seq=10 ttl=57 time=16.7 ms > > J > > > From surfer at mauigateway.com Thu Sep 23 21:50:24 2010 From: surfer at mauigateway.com (Scott Weeks) Date: Thu, 23 Sep 2010 14:50:24 -0700 Subject: LISP Works - Re: Facebook Issues/Outage in Southeast? Message-ID: <20100923145024.1E69986D@resin12.mta.everyone.net> --- jared at puck.nether.net wrote: From: Jared Mauch It's working over LISP: http://www.lisp4.facebook.com/ ------------------------------------- LISP as in Locator/ID Separation Protocol? scott From golson at markettools.com Thu Sep 23 22:13:45 2010 From: golson at markettools.com (Greg Olson) Date: Thu, 23 Sep 2010 22:13:45 +0000 Subject: Facebook Issues/Outage in Southeast? In-Reply-To: References: <471277240-1285270865-cardhu_decombobulator_blackberry.rim.net-1324398093-@bda899.bisx.prod.on.blackberry> <09F712D9B8F7AF40BE523224B2487BA10FD14C47@dtn1mbx01.gci.com> Message-ID: <4D9535BECBA6144C9E481866FB3F964B033BCB@WDCCPMAIL01.markettools.com> I heard it's an issue with users going through Quest. -----Original Message----- From: Ramanpreet Singh [mailto:sikandar.raman at gmail.com] Sent: Thursday, September 23, 2010 2:24 PM To: Warren Bailey Cc: nanog at nanog.org Subject: Re: Facebook Issues/Outage in Southeast? its up and running now. try 69.63.189.16 On Thu, Sep 23, 2010 at 1:52 PM, Warren Bailey wrote: > We've always been able to ping facebook, it seems the people with the most trouble are hitting akamai's caching. The 209.165.150.24 is local to us, as we host akamai for facebook in Alaska. > > ping www.facebook.com > > Pinging a1254.g.akamai.net [209.165.150.24] with 32 bytes of data: > > Reply from 209.165.150.24: bytes=32 time=41ms TTL=57 Reply from > 209.165.150.24: bytes=32 time=4ms TTL=57 Reply from 209.165.150.24: > bytes=32 time=4ms TTL=57 Reply from 209.165.150.24: bytes=32 time=8ms > TTL=57 > > Ping statistics for 209.165.150.24: > ? ?Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate > round trip times in milli-seconds: > ? ?Minimum = 4ms, Maximum = 41ms, Average = 14ms > > > -----Original Message----- > From: Jorge Amodio [mailto:jmamodio at gmail.com] > Sent: Thursday, September 23, 2010 12:16 PM > To: nanog at nanog.org > Subject: Re: Facebook Issues/Outage in Southeast? > > Looks that it came back up now ... > > root at tango:/var/cache/bind# ping -c 10 www.facebook.com PING > a1254.g.akamai.net (209.18.43.169) 56(84) bytes of data. > 64 bytes from 209-18-43-169.dfw10.tbone.rr.com (209.18.43.169): > icmp_seq=1 ttl=57 time=15.8 ms > 64 bytes from 209-18-43-169.dfw10.tbone.rr.com (209.18.43.169): > icmp_seq=2 ttl=57 time=16.9 ms > 64 bytes from 209-18-43-169.dfw10.tbone.rr.com (209.18.43.169): > icmp_seq=3 ttl=57 time=17.2 ms > 64 bytes from 209-18-43-169.dfw10.tbone.rr.com (209.18.43.169): > icmp_seq=4 ttl=57 time=16.6 ms > 64 bytes from 209-18-43-169.dfw10.tbone.rr.com (209.18.43.169): > icmp_seq=5 ttl=57 time=17.2 ms > 64 bytes from 209-18-43-169.dfw10.tbone.rr.com (209.18.43.169): > icmp_seq=6 ttl=57 time=16.2 ms > 64 bytes from 209-18-43-169.dfw10.tbone.rr.com (209.18.43.169): > icmp_seq=7 ttl=57 time=17.0 ms > 64 bytes from 209-18-43-169.dfw10.tbone.rr.com (209.18.43.169): > icmp_seq=8 ttl=57 time=17.2 ms > 64 bytes from 209-18-43-169.dfw10.tbone.rr.com (209.18.43.169): > icmp_seq=9 ttl=57 time=16.7 ms > 64 bytes from 209-18-43-169.dfw10.tbone.rr.com (209.18.43.169): > icmp_seq=10 ttl=57 time=16.7 ms > > J > > > From andrew.wallace at rocketmail.com Thu Sep 23 23:22:07 2010 From: andrew.wallace at rocketmail.com (andrew.wallace) Date: Thu, 23 Sep 2010 16:22:07 -0700 (PDT) Subject: Facebook Issues/Outage in Southeast? In-Reply-To: <4D9535BECBA6144C9E481866FB3F964B033BCB@WDCCPMAIL01.markettools.com> References: <471277240-1285270865-cardhu_decombobulator_blackberry.rim.net-1324398093-@bda899.bisx.prod.on.blackberry> <09F712D9B8F7AF40BE523224B2487BA10FD14C47@dtn1mbx01.gci.com> <4D9535BECBA6144C9E481866FB3F964B033BCB@WDCCPMAIL01.markettools.com> Message-ID: <44017.1922.qm@web59605.mail.ac4.yahoo.com> Completely down again (UK). From deleskie at gmail.com Thu Sep 23 23:23:57 2010 From: deleskie at gmail.com (jim deleskie) Date: Thu, 23 Sep 2010 20:23:57 -0300 Subject: Facebook Issues/Outage in Southeast? In-Reply-To: <44017.1922.qm@web59605.mail.ac4.yahoo.com> References: <471277240-1285270865-cardhu_decombobulator_blackberry.rim.net-1324398093-@bda899.bisx.prod.on.blackberry> <09F712D9B8F7AF40BE523224B2487BA10FD14C47@dtn1mbx01.gci.com> <4D9535BECBA6144C9E481866FB3F964B033BCB@WDCCPMAIL01.markettools.com> <44017.1922.qm@web59605.mail.ac4.yahoo.com> Message-ID: +1 north eastern north america On Thu, Sep 23, 2010 at 8:22 PM, andrew.wallace < andrew.wallace at rocketmail.com> wrote: > Completely down again (UK). > > > > > > From jared at puck.nether.net Thu Sep 23 23:39:24 2010 From: jared at puck.nether.net (Jared Mauch) Date: Thu, 23 Sep 2010 19:39:24 -0400 Subject: LISP Works - Re: Facebook Issues/Outage in Southeast? In-Reply-To: <20100923145024.1E69986D@resin12.mta.everyone.net> References: <20100923145024.1E69986D@resin12.mta.everyone.net> Message-ID: <82DC8A25-F68D-45BF-99C2-038F0966EF97@puck.nether.net> Yes. Jared Mauch On Sep 23, 2010, at 5:50 PM, "Scott Weeks" wrote: > > > --- jared at puck.nether.net wrote: > From: Jared Mauch > > It's working over LISP: > > http://www.lisp4.facebook.com/ > ------------------------------------- > > > > LISP as in Locator/ID Separation Protocol? > > scott From bblackford at gmail.com Thu Sep 23 23:52:35 2010 From: bblackford at gmail.com (Bill Blackford) Date: Thu, 23 Sep 2010 16:52:35 -0700 Subject: Facebook Issues/Outage in Southeast? In-Reply-To: References: <471277240-1285270865-cardhu_decombobulator_blackberry.rim.net-1324398093-@bda899.bisx.prod.on.blackberry> <09F712D9B8F7AF40BE523224B2487BA10FD14C47@dtn1mbx01.gci.com> <4D9535BECBA6144C9E481866FB3F964B033BCB@WDCCPMAIL01.markettools.com> <44017.1922.qm@web59605.mail.ac4.yahoo.com> Message-ID: yes, and Qwest is no longer experiencing issues according to IHR. -b -- Bill Blackford Network Engineer Logged into reality and abusing my sudo privileges..... From surfer at mauigateway.com Fri Sep 24 00:33:47 2010 From: surfer at mauigateway.com (Scott Weeks) Date: Thu, 23 Sep 2010 17:33:47 -0700 Subject: LISP Works - Re: Facebook Issues/Outage in Southeast? Message-ID: <20100923173347.1E6D67EA@resin06.mta.everyone.net> On Sep 23, 2010, at 5:50 PM, "Scott Weeks" wrote: > --- jared at puck.nether.net wrote: > It's working over LISP: > > http://www.lisp4.facebook.com/ > ------------------------------------- > > LISP as in Locator/ID Separation Protocol? ------------------------------------------- --- jared at puck.nether.net wrote: From: Jared Mauch Yes. --------------------------------- Wow, that's cool. I didn't know LISP had progressed that far... scott From cb.list6 at gmail.com Fri Sep 24 00:56:15 2010 From: cb.list6 at gmail.com (Cameron Byrne) Date: Thu, 23 Sep 2010 17:56:15 -0700 Subject: LISP Works - Re: Facebook Issues/Outage in Southeast? In-Reply-To: <20100923173347.1E6D67EA@resin06.mta.everyone.net> References: <20100923173347.1E6D67EA@resin06.mta.everyone.net> Message-ID: On Thu, Sep 23, 2010 at 5:33 PM, Scott Weeks wrote: > On Sep 23, 2010, at 5:50 PM, "Scott Weeks" wrote: >> --- jared at puck.nether.net wrote: > >> It's working over LISP: >> >> http://www.lisp4.facebook.com/ >> ------------------------------------- >> >> LISP as in Locator/ID Separation Protocol? > ------------------------------------------- > > --- jared at puck.nether.net wrote: > From: Jared Mauch > > Yes. > --------------------------------- > > > > Wow, that's cool. ?I didn't know LISP had progressed that far... I would have to agree, i am surprised that there is a single Cisco 3800 series router running test code of LISP at any content provider.... which is all this is. Facebook made it clear that LISP was an experiment, not a technology direction. I don't think this example represents anything in particular. As a network operator, i am afraid LISP is going to turn into the next 6to4 .. an interesting idea that causes more harm than good. Sorry to the fans of 6to4 and LISP, i just long for the day when real IPv6 restores the real e2e internet without strange trickery along the way. Cameron From jra at baylink.com Fri Sep 24 02:17:12 2010 From: jra at baylink.com (Jay R. Ashworth) Date: Thu, 23 Sep 2010 22:17:12 -0400 (EDT) Subject: Facebook Engineering on today's outage In-Reply-To: <44017.1922.qm@web59605.mail.ac4.yahoo.com> Message-ID: <3355550.3590.1285294632830.JavaMail.root@benjamin.baylink.com> http://www.facebook.com/notes/facebook-engineering/more-details-on-todays-outage/431441338919 Apparently, our surmise about Akamai notwithstanding, the problem was actually internal to their app-specific caching facilities, which went into Sorcerer's Apprentice mode, and they had to kill them all and let ghod sort them out. More if I get it; hope that posting's public. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com '87 e24 St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 Start a man a fire, and he'll be warm all night. Set a man on fire, and he'll be warm for the rest of his life. From gordslater at ieee.org Fri Sep 24 09:30:31 2010 From: gordslater at ieee.org (gordon b slater) Date: Fri, 24 Sep 2010 10:30:31 +0100 Subject: Facebook Issues/Outage in Southeast? In-Reply-To: <8C164D3BAF7C7F41B9B286385037B1310D3646D685@lax-exch-fe-01.gorillanation.local> References: <471277240-1285270865-cardhu_decombobulator_blackberry.rim.net-1324398093-@bda899.bisx.prod.on.blackberry> <8C164D3BAF7C7F41B9B286385037B1310D3646D685@lax-exch-fe-01.gorillanation.local> Message-ID: <1285320631.19479.26.camel@ub-g-d2> On Thu, 2010-09-23 at 12:47 -0700, Justin Horstman wrote: > Productivity grinds to a halt as everyone goes onto twitter to talk about facebook being down.... I'm hoping (desperately) that someone other than me sees the full irony in this statement? I also have visions of hundreds of techs worldwide thinking their snort boxes have hung. Gord -- oink From vnktshsriram at gmail.com Fri Sep 24 10:22:22 2010 From: vnktshsriram at gmail.com (Venkatesh Sriram) Date: Fri, 24 Sep 2010 15:52:22 +0530 Subject: Routers in Data Centers Message-ID: Hi, Can somebody educate me on (or pass some pointers) what differentiates a router operating and optimized for data centers versus, say a router work in the metro ethernet space? What is it thats required for routers operating in data centers? High throughput, what else? Thanks, Venkatesh From Valdis.Kletnieks at vt.edu Fri Sep 24 12:21:00 2010 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Fri, 24 Sep 2010 08:21:00 -0400 Subject: Routers in Data Centers In-Reply-To: Your message of "Fri, 24 Sep 2010 15:52:22 +0530." References: Message-ID: <70855.1285330860@localhost> On Fri, 24 Sep 2010 15:52:22 +0530, Venkatesh Sriram said: > Can somebody educate me on (or pass some pointers) what differentiates > a router operating and optimized for data centers versus, say a router > work in the metro ethernet space? What is it thats required for > routers operating in data centers? High throughput, what else? There's corporate data centers and there's colo data centers. The two are sufficiently different that the requirements are divergent. For starters, in a colo, the guy on blade 3 port 5 is quite possibly a competitor of the guy who's got blade 2 port 17. In the corporate data center, we maintain the polite fiction that those two are working together for a common goal. This has implications for security features, billing, bandwidth engineering, and almost every other feature on a router. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From james at gitflorida.com Fri Sep 24 12:47:14 2010 From: james at gitflorida.com (James P. Ashton) Date: Fri, 24 Sep 2010 08:47:14 -0400 (EDT) Subject: Routers in Data Centers In-Reply-To: Message-ID: <13157893.2642.1285332433963.JavaMail.root@mail.gitflorida.com> The biggest difference that I see is that you generally use different resources in a Datacenter. (Colo Datacenter). For example, I run out of HSRP groups on a 6500 long before I run out of ports or capacity. I don't need to worry about QoS much but a less complex rate limit command (As opposed to Policing) is very useful. Also, Front to back cooling is optimal in a Datacenter and often not available. James ----- Original Message ----- From: "Venkatesh Sriram" To: nanog at nanog.org Sent: Friday, September 24, 2010 6:22:22 AM Subject: Routers in Data Centers Hi, Can somebody educate me on (or pass some pointers) what differentiates a router operating and optimized for data centers versus, say a router work in the metro ethernet space? What is it thats required for routers operating in data centers? High throughput, what else? Thanks, Venkatesh From tme at americafree.tv Fri Sep 24 15:41:29 2010 From: tme at americafree.tv (Marshall Eubanks) Date: Fri, 24 Sep 2010 11:41:29 -0400 Subject: Routers in Data Centers In-Reply-To: References: Message-ID: <479F272E-0F5C-4CB8-9F08-0ABEDCC1E1DE@americafree.tv> On Sep 24, 2010, at 6:22 AM, Venkatesh Sriram wrote: > Hi, > > Can somebody educate me on (or pass some pointers) what differentiates > a router operating and optimized for data centers versus, say a router > work in the metro ethernet space? What is it thats required for > routers operating in data centers? High throughput, what else? > > Thanks, Venkatesh Well, they generally have to be rack mountable. Besides that, I have seen everything from tiny Linux boxes to big refrigerator sized units (of course, the latter may be on the floor). I don't think you are going to find much commonality there, so you need to refine what it is you want to do. (For example, to move 10 Mbps or 100 Gbps or... ? Run BGP or NAT or ... ?) Regards Marshall > > From warren at kumari.net Fri Sep 24 17:08:23 2010 From: warren at kumari.net (Warren Kumari) Date: Fri, 24 Sep 2010 13:08:23 -0400 Subject: Routers in Data Centers In-Reply-To: References: Message-ID: On Sep 24, 2010, at 6:22 AM, Venkatesh Sriram wrote: > Hi, > > Can somebody educate me on (or pass some pointers) what differentiates > a router operating and optimized for data centers versus, say a router > work in the metro ethernet space? What is it thats required for > routers operating in data centers? High throughput, what else? While this question has many dimensions and there is no real definition of either I suspect that what many people mean when they talk about a DC routers is: Primarily Ethernet interfaces High port density Designed to deal with things like VRRP / VLAN / ethernet type features. Possibly CAM based, possibly smaller buffers. Less likely to be taking full routes. This is very similar to the religious debate about "What's the difference between a 'real' router and a L3 switch?" Just my 2 cents. W > > Thanks, Venkatesh > -- Consider orang-utans. In all the worlds graced by their presence, it is suspected that they can talk but choose not to do so in case humans put them to work, possibly in the television industry. In fact they can talk. It's just that they talk in Orang-utan. Humans are only capable of listening in Bewilderment. -- Terry Practhett From black at csulb.edu Fri Sep 24 17:15:13 2010 From: black at csulb.edu (Matthew Black) Date: Fri, 24 Sep 2010 10:15:13 -0700 Subject: Facebook Issues/Outage ... what about Yahoo! Answers In-Reply-To: References: Message-ID: I didn't have trouble with Facebook, but the last two evenings Yahoo! Answers [http://answers.yahoo.com] seems 99.47% unresponsive. Verizon DSL customer. matthew black e-mail postmaster california state university, long beach From bmanning at vacation.karoshi.com Fri Sep 24 17:16:23 2010 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Fri, 24 Sep 2010 17:16:23 +0000 Subject: Routers in Data Centers In-Reply-To: References: Message-ID: <20100924171623.GC17530@vacation.karoshi.com.> the power/cooling budget for a rack full of router vs a rack full of cores might be distinction to make. I know that historically, the data center operator made no distinction and a client decided to "push past the envelope" and replaced their kit with space heaters. most data centers now are fairly restrictive on the power/cooling budget for a given footprint. --bill On Fri, Sep 24, 2010 at 01:08:23PM -0400, Warren Kumari wrote: > > On Sep 24, 2010, at 6:22 AM, Venkatesh Sriram wrote: > > >Hi, > > > >Can somebody educate me on (or pass some pointers) what differentiates > >a router operating and optimized for data centers versus, say a router > >work in the metro ethernet space? What is it thats required for > >routers operating in data centers? High throughput, what else? > > > While this question has many dimensions and there is no real > definition of either I suspect that what many people mean when they > talk about a DC routers is: > Primarily Ethernet interfaces > High port density > Designed to deal with things like VRRP / VLAN / ethernet type features. > Possibly CAM based, possibly smaller buffers. > Less likely to be taking full routes. > > This is very similar to the religious debate about "What's the > difference between a 'real' router and a L3 switch?" > > Just my 2 cents. > W > > > > > >Thanks, Venkatesh > > > > -- > Consider orang-utans. > In all the worlds graced by their presence, it is suspected that they > can talk but choose not to do so in case humans put them to work, > possibly in the television industry. In fact they can talk. It's just > that they talk in Orang-utan. Humans are only capable of listening in > Bewilderment. > -- Terry Practhett > > From nanog at bitfreak.org Fri Sep 24 17:17:16 2010 From: nanog at bitfreak.org (Darren Pilgrim) Date: Fri, 24 Sep 2010 10:17:16 -0700 Subject: Active Directory requires Microsoft DNS? In-Reply-To: References: Message-ID: <4C9CDD1C.5090609@bitfreak.org> Tom Mikelson wrote: > Presently our organization utilizes BIND for DNS services, with the > Networking team administering. We are now being told by the Systems team > that they will be responsible for DNS services and that it will be changed > over to the Microsoft DNS service run on domain controllers. The reason > given is that the Active Directory implementation requires the Microsoft DNS > service and dynamic DNS. Bunk. At work we have a network of ~1500 computers with over 600 of them running Windows. Our nameservers are all BIND, which have dynamic DNS enabled for updates sent from our 2003 and 2008R2 DCs. The DCs have no problem creating, updating and deleting the various RR's they use to publish the domain. The Systems team folks will see errors/warnings in the Windows logs because the Windows machines are unable to set up secure connections to the nameservers and due to an implementation difference between what BIND accepts and what Microsoft's OSes send; but in practice these seem to be little more than noise. From regnauld at nsrc.org Fri Sep 24 17:45:09 2010 From: regnauld at nsrc.org (Phil Regnauld) Date: Fri, 24 Sep 2010 19:45:09 +0200 Subject: Active Directory requires Microsoft DNS? In-Reply-To: <4C9CDD1C.5090609@bitfreak.org> References: <4C9CDD1C.5090609@bitfreak.org> Message-ID: <20100924174508.GQ31091@macbook.catpipe.net> Darren Pilgrim (nanog) writes: > Tom Mikelson wrote: > >Presently our organization utilizes BIND for DNS services, with the > >Networking team administering. We are now being told by the Systems team > >that they will be responsible for DNS services and that it will be changed > >over to the Microsoft DNS service run on domain controllers. The reason > >given is that the Active Directory implementation requires the Microsoft DNS > >service and dynamic DNS. > > Bunk. At work we have a network of ~1500 computers with over 600 of > them running Windows. Our nameservers are all BIND, which have > dynamic DNS enabled for updates sent from our 2003 and 2008R2 DCs. > The DCs have no problem creating, updating and deleting the various > RR's they use to publish the domain. The Systems team folks will > see errors/warnings in the Windows logs because the Windows machines > are unable to set up secure connections to the nameservers and due > to an implementation difference between what BIND accepts and what > Microsoft's OSes send; but in practice these seem to be little more > than noise. Agreed. What about dynamic updates of the client ? It's usually not a problem in this direction (Windows client -> BIND DNS), but as you say it won't be secure (GSS-TSIG). Cheers, Phil From accesss801 at gmail.com Fri Sep 24 17:49:35 2010 From: accesss801 at gmail.com (Daniel) Date: Fri, 24 Sep 2010 11:49:35 -0600 Subject: Active Directory requires Microsoft DNS? In-Reply-To: <4C9CDD1C.5090609@bitfreak.org> References: <4C9CDD1C.5090609@bitfreak.org> Message-ID: AD works just fine with BIND as long as dynamic updates are allowed to the AD zone's from the DC's. Exchange 2007 by default also wants to be able to dynamically register it's record's but it can be disabled. All you need to do is configure the DNS server's in the IP settings and restart the net logon service on the DC's and watch all the records get populated into the zone on BIND. That's all you need to do to migrate from MS DNS to BIND as well. The only issue I ran into was old records not being deleted properly in BIND (removing a DC) so you had to manually delete them from the zone but it wasn't a big deal since there's not many records and easy to identify. If your worried about all the records not being registered properly you can look at a local file on the DC and it will list the records that should be in DNS. http://support.microsoft.com/kb/816587 There is also a utility you can run on the DC's that will verify all the records that should be in DNS and report any errors. I don't recall for sure but I think it was netdiag. http://support.microsoft.com/kb/321708 -Dan On Fri, Sep 24, 2010 at 11:17 AM, Darren Pilgrim wrote: > Tom Mikelson wrote: > >> Presently our organization utilizes BIND for DNS services, with the >> Networking team administering. We are now being told by the Systems team >> that they will be responsible for DNS services and that it will be changed >> over to the Microsoft DNS service run on domain controllers. The reason >> given is that the Active Directory implementation requires the Microsoft >> DNS >> service and dynamic DNS. >> > > Bunk. At work we have a network of ~1500 computers with over 600 of them > running Windows. Our nameservers are all BIND, which have dynamic DNS > enabled for updates sent from our 2003 and 2008R2 DCs. The DCs have no > problem creating, updating and deleting the various RR's they use to publish > the domain. The Systems team folks will see errors/warnings in the Windows > logs because the Windows machines are unable to set up secure connections to > the nameservers and due to an implementation difference between what BIND > accepts and what Microsoft's OSes send; but in practice these seem to be > little more than noise. > > From nanog at bitfreak.org Fri Sep 24 17:50:59 2010 From: nanog at bitfreak.org (Darren Pilgrim) Date: Fri, 24 Sep 2010 10:50:59 -0700 Subject: Active Directory requires Microsoft DNS? In-Reply-To: <20100924174508.GQ31091@macbook.catpipe.net> References: <4C9CDD1C.5090609@bitfreak.org> <20100924174508.GQ31091@macbook.catpipe.net> Message-ID: <4C9CE503.1070505@bitfreak.org> Phil Regnauld wrote: > Darren Pilgrim (nanog) writes: >> Tom Mikelson wrote: >>> Presently our organization utilizes BIND for DNS services, with the >>> Networking team administering. We are now being told by the Systems team >>> that they will be responsible for DNS services and that it will be changed >>> over to the Microsoft DNS service run on domain controllers. The reason >>> given is that the Active Directory implementation requires the Microsoft DNS >>> service and dynamic DNS. >> Bunk. At work we have a network of ~1500 computers with over 600 of >> them running Windows. Our nameservers are all BIND, which have >> dynamic DNS enabled for updates sent from our 2003 and 2008R2 DCs. >> The DCs have no problem creating, updating and deleting the various >> RR's they use to publish the domain. The Systems team folks will >> see errors/warnings in the Windows logs because the Windows machines >> are unable to set up secure connections to the nameservers and due >> to an implementation difference between what BIND accepts and what >> Microsoft's OSes send; but in practice these seem to be little more >> than noise. > > Agreed. What about dynamic updates of the client ? It's usually not > a problem in this direction (Windows client -> BIND DNS), but as you > say it won't be secure (GSS-TSIG). Yes, Windows logs on all 600+ machines have warnings about insecure DNS updates, but they still update. There's effort to delegate the DS subdomain to the DCs just to get rid of the thousands-per-day nonsense. From cscora at apnic.net Fri Sep 24 18:53:04 2010 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 25 Sep 2010 04:53:04 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <201009241853.o8OIr4dH017951@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. The posting is sent to APOPS, NANOG, AfNOG, AusNOG, SANOG, PacNOG, LacNOG, CaribNOG and the RIPE Routing Working Group. Daily listings are sent to bgp-stats at lists.apnic.net For historical data, please see http://thyme.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 25 Sep, 2010 Report Website: http://thyme.apnic.net Detailed Analysis: http://thyme.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 331883 Prefixes after maximum aggregation: 152525 Deaggregation factor: 2.18 Unique aggregates announced to Internet: 161648 Total ASes present in the Internet Routing Table: 34863 Prefixes per ASN: 9.52 Origin-only ASes present in the Internet Routing Table: 30227 Origin ASes announcing only one prefix: 14677 Transit ASes present in the Internet Routing Table: 4636 Transit-only ASes present in the Internet Routing Table: 101 Average AS path length visible in the Internet Routing Table: 3.7 Max AS path length visible: 24 Max AS path prepend of ASN (41664) 21 Prefixes from unregistered ASNs in the Routing Table: 3160 Unregistered ASNs in the Routing Table: 1399 Number of 32-bit ASNs allocated by the RIRs: 794 Prefixes from 32-bit ASNs in the Routing Table: 1017 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 228 Number of addresses announced to Internet: 2273798848 Equivalent to 135 /8s, 135 /16s and 106 /24s Percentage of available address space announced: 61.3 Percentage of allocated address space announced: 65.5 Percentage of available address space allocated: 93.7 Percentage of address space in use by end-sites: 84.9 Total number of prefixes smaller than registry allocations: 156837 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 80968 Total APNIC prefixes after maximum aggregation: 27719 APNIC Deaggregation factor: 2.92 Prefixes being announced from the APNIC address blocks: 77853 Unique aggregates announced from the APNIC address blocks: 32742 APNIC Region origin ASes present in the Internet Routing Table: 4196 APNIC Prefixes per ASN: 18.55 APNIC Region origin ASes announcing only one prefix: 1167 APNIC Region transit ASes present in the Internet Routing Table: 648 Average APNIC Region AS path length visible: 3.7 Max APNIC Region AS path length visible: 15 Number of APNIC addresses announced to Internet: 551901216 Equivalent to 32 /8s, 229 /16s and 88 /24s Percentage of available APNIC address space announced: 78.3 APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079 55296-56319, 131072-132095 APNIC Address Blocks 1/8, 14/8, 27/8, 43/8, 49/8, 58/8, 59/8, 60/8, 61/8, 101/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, 133/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, 223/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 135903 Total ARIN prefixes after maximum aggregation: 70118 ARIN Deaggregation factor: 1.94 Prefixes being announced from the ARIN address blocks: 108637 Unique aggregates announced from the ARIN address blocks: 43091 ARIN Region origin ASes present in the Internet Routing Table: 13925 ARIN Prefixes per ASN: 7.80 ARIN Region origin ASes announcing only one prefix: 5334 ARIN Region transit ASes present in the Internet Routing Table: 1380 Average ARIN Region AS path length visible: 3.4 Max ARIN Region AS path length visible: 22 Number of ARIN addresses announced to Internet: 734124576 Equivalent to 43 /8s, 193 /16s and 218 /24s Percentage of available ARIN address space announced: 62.5 ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 53248-55295, 393216-394239 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, 50/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, 107/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: 76059 Total RIPE prefixes after maximum aggregation: 44153 RIPE Deaggregation factor: 1.72 Prefixes being announced from the RIPE address blocks: 69455 Unique aggregates announced from the RIPE address blocks: 45623 RIPE Region origin ASes present in the Internet Routing Table: 14816 RIPE Prefixes per ASN: 4.69 RIPE Region origin ASes announcing only one prefix: 7631 RIPE Region transit ASes present in the Internet Routing Table: 2237 Average RIPE Region AS path length visible: 3.9 Max RIPE Region AS path length visible: 24 Number of RIPE addresses announced to Internet: 439384960 Equivalent to 26 /8s, 48 /16s and 123 /24s Percentage of available RIPE address space announced: 77.0 RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-52223, 196608-197631 RIPE Address Blocks 2/8, 25/8, 31/8, 46/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, 176/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: 30249 Total LACNIC prefixes after maximum aggregation: 7285 LACNIC Deaggregation factor: 4.15 Prefixes being announced from the LACNIC address blocks: 28745 Unique aggregates announced from the LACNIC address blocks: 15259 LACNIC Region origin ASes present in the Internet Routing Table: 1354 LACNIC Prefixes per ASN: 21.23 LACNIC Region origin ASes announcing only one prefix: 422 LACNIC Region transit ASes present in the Internet Routing Table: 232 Average LACNIC Region AS path length visible: 4.0 Max LACNIC Region AS path length visible: 19 Number of LACNIC addresses announced to Internet: 75452800 Equivalent to 4 /8s, 127 /16s and 81 /24s Percentage of available LACNIC address space announced: 56.2 LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 262144-263167 plus ERX transfers LACNIC Address Blocks 177/8, 181/8, 186/8, 187/8, 189/8, 190/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 7427 Total AfriNIC prefixes after maximum aggregation: 1881 AfriNIC Deaggregation factor: 3.95 Prefixes being announced from the AfriNIC address blocks: 5745 Unique aggregates announced from the AfriNIC address blocks: 1675 AfriNIC Region origin ASes present in the Internet Routing Table: 404 AfriNIC Prefixes per ASN: 14.22 AfriNIC Region origin ASes announcing only one prefix: 123 AfriNIC Region transit ASes present in the Internet Routing Table: 93 Average AfriNIC Region AS path length visible: 3.8 Max AfriNIC Region AS path length visible: 17 Number of AfriNIC addresses announced to Internet: 20374016 Equivalent to 1 /8s, 54 /16s and 226 /24s Percentage of available AfriNIC address space announced: 60.7 AfriNIC AS Blocks 36864-37887, 327680-328703 & 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 1859 9436 501 Korea Telecom (KIX) 7545 1395 297 83 TPG Internet Pty Ltd 4755 1348 368 160 TATA Communications formerly 17488 1347 155 124 Hathway IP Over Cable Interne 17974 1240 299 70 PT TELEKOMUNIKASI INDONESIA 24560 1036 304 177 Bharti Airtel Ltd., Telemedia 9583 1015 75 488 Sify Limited 4808 932 1714 261 CNCGROUP IP network: China169 18101 883 100 132 Reliance Infocom Ltd Internet 9829 823 692 33 BSNL National Internet Backbo Complete listing at http://thyme.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 3780 3667 278 bellsouth.net, inc. 4323 2708 1107 388 Time Warner Telecom 19262 1818 4676 286 Verizon Global Networks 1785 1797 698 132 PaeTec Communications, Inc. 20115 1494 1531 652 Charter Communications 7018 1461 5747 947 AT&T WorldNet Services 6478 1352 275 123 AT&T Worldnet Services 2386 1293 554 912 AT&T Data Communications Serv 11492 1207 229 85 Cable One 22773 1195 2858 61 Cox Communications, Inc. Complete listing at http://thyme.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 3292 447 2026 388 TDC Tele Danmark 30890 442 99 211 Evolva Telecom 8866 405 117 19 Bulgarian Telecommunication C 702 404 1868 318 UUNET - Commercial IP service 8551 402 353 46 Bezeq International 3301 378 1688 333 TeliaNet Sweden 34984 376 90 185 BILISIM TELEKOM 3320 373 7328 323 Deutsche Telekom AG 12479 361 576 5 Uni2 Autonomous System 31148 349 18 75 FreeNet ISP 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 1341 2559 367 UniNet S.A. de C.V. 10620 1319 247 148 TVCABLE BOGOTA 28573 1114 869 108 NET Servicos de Comunicao S.A 7303 809 424 103 Telecom Argentina Stet-France 6503 746 223 258 AVANTEL, S.A. 14420 580 38 76 CORPORACION NACIONAL DE TELEC 22047 558 310 15 VTR PUNTO NET S.A. 3816 482 209 95 Empresa Nacional de Telecomun 7738 477 922 30 Telecomunicacoes da Bahia S.A 11172 444 99 76 Servicios Alestra S.A de C.V 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 1129 445 10 TEDATA 24863 728 147 39 LINKdotNET AS number 36992 660 279 178 Etisalat MISR 3741 266 906 224 The Internet Solution 6713 203 199 12 Itissalat Al-MAGHRIB 29571 202 19 11 Ci Telecom Autonomous system 2018 197 277 64 Tertiary Education Network 33776 197 12 14 Starcomms Nigeria Limited 24835 165 78 9 RAYA Telecom - Egypt 16637 154 440 92 MTN Network Solutions 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 3780 3667 278 bellsouth.net, inc. 4323 2708 1107 388 Time Warner Telecom 4766 1859 9436 501 Korea Telecom (KIX) 19262 1818 4676 286 Verizon Global Networks 1785 1797 698 132 PaeTec Communications, Inc. 20115 1494 1531 652 Charter Communications 7018 1461 5747 947 AT&T WorldNet Services 7545 1395 297 83 TPG Internet Pty Ltd 6478 1352 275 123 AT&T Worldnet Services 4755 1348 368 160 TATA Communications formerly Complete listing at http://thyme.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 4323 2708 2320 Time Warner Telecom 1785 1797 1665 PaeTec Communications, Inc. 19262 1818 1532 Verizon Global Networks 4766 1859 1358 Korea Telecom (KIX) 7545 1395 1312 TPG Internet Pty Ltd 6478 1352 1229 AT&T Worldnet Services 17488 1347 1223 Hathway IP Over Cable Interne 4755 1348 1188 TATA Communications formerly 10620 1319 1171 TVCABLE BOGOTA 17974 1240 1170 PT TELEKOMUNIKASI INDONESIA Complete listing at http://thyme.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 11946 UNALLOCATED 8.12.155.0/24 40913 Quality Technology S 15040 UNALLOCATED 8.12.156.0/24 3356 Level 3 Communicatio 33084 UNALLOCATED 8.15.195.0/24 3356 Level 3 Communicatio 18826 UNALLOCATED 8.17.208.0/20 2828 XO Communications 16734 UNALLOCATED 8.18.204.0/24 26914 Global Netoptex, Inc 53562 UNALLOCATED 8.19.94.0/24 3356 Level 3 Communicatio 22015 UNALLOCATED 8.22.137.0/24 14989 Broadview Networks 46856 UNALLOCATED 8.22.184.0/22 3356 Level 3 Communicatio 21893 UNALLOCATED 8.26.33.0/24 3356 Level 3 Communicatio 26169 UNALLOCATED 8.225.177.0/24 20225 TelJet Complete listing at http://thyme.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 31.0.0.0/16 12654 RIPE NCC RIS Project 31.1.0.0/21 12654 RIPE NCC RIS Project 31.1.24.0/24 12654 RIPE NCC RIS Project 41.222.79.0/24 36938 >>UNKNOWN<< 41.223.92.0/22 36936 >>UNKNOWN<< 41.223.196.0/24 36990 Alkan Telecom Ltd 41.223.197.0/24 36990 Alkan Telecom Ltd 41.223.198.0/24 36990 Alkan Telecom Ltd 41.223.199.0/24 36990 Alkan Telecom Ltd 46.20.80.0/20 5602 KPNQwest Italia S.p.a 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:25 /11:67 /12:202 /13:420 /14:730 /15:1318 /16:11289 /17:5447 /18:9267 /19:18479 /20:23532 /21:23780 /22:31095 /23:30369 /24:172749 /25:1048 /26:1163 /27:646 /28:170 /29:47 /30:3 /31:0 /32:7 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 6389 2407 3780 bellsouth.net, inc. 4766 1476 1859 Korea Telecom (KIX) 4323 1367 2708 Time Warner Telecom 1785 1259 1797 PaeTec Communications, Inc. 10620 1207 1319 TVCABLE BOGOTA 11492 1099 1207 Cable One 17488 1087 1347 Hathway IP Over Cable Interne 18566 1068 1087 Covad Communications 8452 1029 1129 TEDATA 24560 937 1036 Bharti Airtel Ltd., Telemedia Complete listing at http://thyme.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:72 2:13 4:13 8:310 12:2012 13:8 14:9 15:20 16:3 17:9 20:8 24:1365 27:345 31:1 32:61 33:12 38:702 40:97 41:2519 44:3 46:97 47:10 49:4 52:12 55:5 56:2 57:30 58:867 59:505 60:477 61:1080 62:1049 63:1964 64:3715 65:2305 66:4025 67:1841 68:1136 69:2800 70:739 71:374 72:1959 73:2 74:2312 75:285 76:318 77:873 78:645 79:418 80:1021 81:798 82:498 83:454 84:680 85:1035 86:431 87:688 88:314 89:1574 90:98 91:3061 92:429 93:995 94:1167 95:703 96:397 97:219 98:634 99:32 101:3 108:64 109:711 110:430 111:579 112:297 113:284 114:452 115:594 116:1102 117:659 118:526 119:881 120:158 121:709 122:1541 123:923 124:1222 125:1241 128:226 129:157 130:168 131:558 132:259 133:19 134:207 135:46 136:223 137:138 138:274 139:109 140:478 141:197 142:346 143:351 144:479 145:54 146:428 147:171 148:629 149:305 150:152 151:233 152:288 153:171 154:3 155:366 156:170 157:335 158:111 159:362 160:315 161:189 162:268 163:165 164:414 165:368 166:468 167:409 168:677 169:156 170:724 171:62 172:2 173:1052 174:531 175:171 176:1 177:1 178:498 180:654 181:1 182:210 183:254 184:160 186:647 187:469 188:819 189:786 190:4156 192:5779 193:4739 194:3430 195:2822 196:1200 198:3552 199:3594 200:5397 201:1583 202:8111 203:8288 204:3995 205:2394 206:2554 207:3054 208:3885 209:3492 210:2582 211:1301 212:1773 213:1684 214:674 215:66 216:4753 217:1579 218:473 219:399 220:1176 221:389 222:314 223:42 End of report From rekoil at semihuman.com Fri Sep 24 20:43:23 2010 From: rekoil at semihuman.com (Chris Woodfield) Date: Fri, 24 Sep 2010 13:43:23 -0700 Subject: Facebook Engineering on today's outage In-Reply-To: <3355550.3590.1285294632830.JavaMail.root@benjamin.baylink.com> References: <3355550.3590.1285294632830.JavaMail.root@benjamin.baylink.com> Message-ID: Agreed; my reading of this suggests database caching issues (i.e. all the frontend/middleware clients hitting the main sql cluster at once instead of the memcached farm they normally use), not HTTP/CDN caching issues. -C On Sep 23, 2010, at 7:17 12PM, Jay R. Ashworth wrote: > http://www.facebook.com/notes/facebook-engineering/more-details-on-todays-outage/431441338919 > > Apparently, our surmise about Akamai notwithstanding, the problem was actually > internal to their app-specific caching facilities, which went into Sorcerer's > Apprentice mode, and they had to kill them all and let ghod sort them out. > > More if I get it; hope that posting's public. > > Cheers, > -- jra > > -- > Jay R. Ashworth Baylink jra at baylink.com > Designer The Things I Think RFC 2100 > Ashworth & Associates http://baylink.pitas.com '87 e24 > St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 > > Start a man a fire, and he'll be warm all night. > Set a man on fire, and he'll be warm for the rest of his life. > From rekoil at semihuman.com Fri Sep 24 20:55:19 2010 From: rekoil at semihuman.com (Chris Woodfield) Date: Fri, 24 Sep 2010 13:55:19 -0700 Subject: Routers in Data Centers In-Reply-To: References: Message-ID: <7EB7A7A0-58D1-4FB6-853D-1021D25EE73E@semihuman.com> Historically, you would find that routers designed for long-haul transport (Cisco GSR/CRS, Juniper M-series, etc) generally had deeper buffers per-port and more robust QoS capabilities than datacenter routers that were effectively switches with Layer 3 logic bolted on (*coughMSFCcough*). That line has blurred quite a bit lately, however - Cisco's ES line cards are an example. That said, there's plenty of debate as to whether or not these features actually make for a better long-haul router or not - I've seen more metro and national backbones built with Cat6500^H^H^H^H7600s than you'd think. -C On Sep 24, 2010, at 3:22 22AM, Venkatesh Sriram wrote: > Hi, > > Can somebody educate me on (or pass some pointers) what differentiates > a router operating and optimized for data centers versus, say a router > work in the metro ethernet space? What is it thats required for > routers operating in data centers? High throughput, what else? > > Thanks, Venkatesh > From nanogf at spoofer.com Fri Sep 24 21:10:27 2010 From: nanogf at spoofer.com (nanogf .) Date: Fri, 24 Sep 2010 14:10:27 -0700 Subject: OpenFlow Message-ID: <20100924141027.1E687BEC@resin11.mta.everyone.net> Hello, I plan to distribute OpenFlow switches, which is why I would like to further dis cuss about this technology with NANOGers. Firstly, to get a better overview of OpenFlow, I would greatly appreciate to in vite you to a further reading of the latest presentation on the subject from NEC entitled "Future Internet Research Using OpenFlow" [1]. I) Definition a) Commercial I'd note that Flow-based networking is not a new concept and is currently suppor ted by Anagran [2], whose founder is none other than Larry Roberts [3]. b) Dynamic Switch Control Protocols By the way, I would greatly appreciate to invite you to a further reading of th e thesis entitled "Implementation and Evaluation of a Network Element Control Pr otocol" [4] where different Dynamic Switch Control Protocols (Strengths, and GSM P OpenFlow) are compared (page 17-23). -Note: the source code is available at the web page titled "Work ETNA Package 4 "[5]. II) Business Model 1) Capex The advantage of OpenFlow is to separate the Data Plane from the Control Plane, thus simplifying the switches (see page 15 of "Future Internet Research Using Op enFlow "[0]) which results in a reduction of Capex (see page 23 of the presentat ion entitled "OpenFlow / Software Defined Networks" [6]). >From a cost-perspective you can deploy a cheaper networking gear basedon "dummy OpenFlow-only" switches, provided a controller applicationthat takes care of th e network intelligence (e.g., installing flows,VM directory, etc.). To illustrate this argument, I would greatly appreciate to invite you to a furth er reading of the presentation entitled "OpenFlow / Software Defined Networks" [ 6] from Clean Slate project at Stanford and the one entitled "Data Center Networ ks Are in My Way" [7] from Cloud Provider, Amazon. 2) Opex Moreover, intelligence is centralized through the OpenFlow controller therefore easier, resulting in a reduction of Opex (see page 26 of the presentation entitl ed "OpenFlow / Software Defined Networks" [6]). >From a functional perspective you have the potential gains ofre-thinking the pa cket forwarding departing from spanning trees orVLAN segmentations (cf. SIGCOMM0 9 Portland paper). To illustrate this second argument, I would greatly appreciate to invite you to a further reading of the presentation entitled "An Experimenter's Guide to Open Flow" [8] of Deutsche Telekom R&D Labs and the one entitled "OpenFlow : Operatio nal Experiences" [9] from the GRNOC at the University of Illinois (who will also give an OpenFlow track at NANOG50 [10]) -Note: as an example of research application, I would greatly appreciate to invi te you to a further reading of the presentation entitled "Towards a Flow-level N etwork Security System "[11]. III) Open Source For those wishing to experiment with this technology, I would advise the followi ng setup: -HW : Pronto 3290 [12] -Firmware : Pica8 XorPlus 1.1 that includes the L2/L3 management for VLAN, LACP, STP/RSTP, L LDP, OSPF, RIP, static route, PIM-SM, VRRP, IGMP, IGMP Snooping, IPv6, Radius/Ta cacs+ as well as OpenFlow 1.0 (available at later Oct, 2010) [13] -OpenFlow-Controller : Beacon: Java OpenFlow Controller [14] Have a good week-end :) ! I look forward to your answer, Best Regards, [1] [1]https://docs.google.com/fileview?id=0B6oJAUODOgEsNDk5ZDMyOTctZDFhNC00NThl LThlYjUtZjc4ZjhhMzUxY2Mx&authkey=CPTO4NMF&hl=en [2] [2]http://spectrum.ieee.org/computing/networks/a-radical-new-router/0 [3] [3]http://www.packet.cc/ [4] [4]http://docs.google.com/viewer?url=http://lib.tkk.fi/Dipl/2010/urn100214.p df [5] [5]http://etna.netlab.tkk.fi/ [6] [6]http://docs.google.com/viewer?url=http://www.thequilt.net/meetings/GENI%2 0WKSP/GENI%20Workshop%20Presentations/OF-intro-Quilt-workshop%20(new)%20-%2016%2 0July%202010.ppt [7] [7]http://docs.google.com/viewer?url=http://mvdirona.com/jrh/TalksAndPapers/ JamesHamilton_CleanSlateCTO2009.pdf [8] [8]http://docs.google.com/viewer?url=http://www.deutsche-telekom-laboratorie s.de/~robert/GENI-Experimenters-Workshop.ppt [9] [9]http://docs.google.com/viewer?url=http://groups.geni.net/geni/attachment/ wiki/OFIU/iu_openflow-apan.pdf?format%3Draw&pli=1 [10] [10]http://www.nanog.org/meetings/nanog50/abstracts.php?pt=MTY2OSZuYW5vZzUw &nm=nanog50 [11] [11]https://docs.google.com/present/edit?id=0AaoJAUODOgEsZGdwY2JiczlfMTEwN2 RyOXAyd2R0&hl=en&authkey=CKCgltYO [12] [12]http://www.prontosys.net/pronto3290.htm [13] [13]http://www.pica8.com [14] [14]https://docs.google.com/fileview?id=0BxAl_URIEW6dNmE4ZTM5MzUtNTNlZC00Ym Q3LWEyMWEtMjhjN2IxZWM2MzA1&authkey=CPWO_c0M&hl=en Guillaume FORTAINE Tel : +33(0)631092519 Mail : gfortaine at gfortaine.biz __________________________________________________________________ Get your own *free* email address like this one from www.OwnEmail.com References 1. https://docs.google.com/fileview?id=0B6oJAUODOgEsNDk5ZDMyOTctZDFhNC00NThlLThlYjUtZjc4ZjhhMzUxY2Mx&authkey=CPTO4NMF&hl=en 2. http://spectrum.ieee.org/computing/networks/a-radical-new-router/0 3. http://www.packet.cc/ 4. http://docs.google.com/viewer?url=http://lib.tkk.fi/Dipl/2010/urn100214.pdf 5. http://etna.netlab.tkk.fi/ 6. http://docs.google.com/viewer?url=http://www.thequilt.net/meetings/GENI%20WKSP/GENI%20Workshop%20Presentations/OF-intro-Quilt-workshop%20 7. http://docs.google.com/viewer?url=http://mvdirona.com/jrh/TalksAndPapers/JamesHamilton_CleanSlateCTO2009.pdf 8. http://docs.google.com/viewer?url=http://www.deutsche-telekom-laboratories.de/~robert/GENI-Experimenters-Workshop.ppt 9. http://docs.google.com/viewer?url=http://groups.geni.net/geni/attachment/wiki/OFIU/iu_openflow-apan.pdf?format%3Draw&pli=1 10. http://www.nanog.org/meetings/nanog50/abstracts.php?pt=MTY2OSZuYW5vZzUw&nm=nanog50 11. https://docs.google.com/present/edit?id=0AaoJAUODOgEsZGdwY2JiczlfMTEwN2RyOXAyd2R0&hl=en&authkey=CKCgltYO 12. http://www.prontosys.net/pronto3290.htm 13. http://www.pica8.com/ 14. https://docs.google.com/fileview?id=0BxAl_URIEW6dNmE4ZTM5MzUtNTNlZC00YmQ3LWEyMWEtMjhjN2IxZWM2MzA1&authkey=CPWO_c0M&hl=en From MatlockK at exempla.org Fri Sep 24 21:25:22 2010 From: MatlockK at exempla.org (Matlock, Kenneth L) Date: Fri, 24 Sep 2010 15:25:22 -0600 Subject: OpenFlow In-Reply-To: <20100924141027.1E687BEC@resin11.mta.everyone.net> References: <20100924141027.1E687BEC@resin11.mta.everyone.net> Message-ID: <4288131ED5E3024C9CD4782CECCAD2C70B9A2E3C@LMC-MAIL2.exempla.org> Wow, resorting to using a spoofed email address to propagate your spam, and forget to remove your .sig Some people just don't take a hint, do they? I know which software package I WON'T be recommending to anyone (in fact, quite the opposite!) Ken Matlock Network Analyst Exempla Healthcare (303) 467-4671 matlockk at exempla.org From jeroen at unfix.org Fri Sep 24 21:30:55 2010 From: jeroen at unfix.org (Jeroen Massar) Date: Fri, 24 Sep 2010 23:30:55 +0200 Subject: OpenFlow In-Reply-To: <4288131ED5E3024C9CD4782CECCAD2C70B9A2E3C@LMC-MAIL2.exempla.org> References: <20100924141027.1E687BEC@resin11.mta.everyone.net> <4288131ED5E3024C9CD4782CECCAD2C70B9A2E3C@LMC-MAIL2.exempla.org> Message-ID: <4C9D188F.2050802@unfix.org> On 2010-09-24 23:25, Matlock, Kenneth L wrote: > Wow, resorting to using a spoofed email address to propagate your spam, > and forget to remove your .sig > > Some people just don't take a hint, do they? I know which software > package I WON'T be recommending to anyone (in fact, quite the opposite!) And also, there is a nice agenda item at NANOG50; http://www.nanog.org/meetings/nanog50/abstracts.php?pt=MTY2OSZuYW5vZzUw&nm=nanog50 8<----------------------------------------------------------------- Track: Open Flow Nick McKeown, Stanford University; Matt Davy, Indiana University Presentation Date: October 4, 2010, 4:30 PM - 6:00 PM Abstract: OpenFlow: An Update [..] OpenFlow Trials and Deployments ----------------------------------------------------------------->8 Thus as it is a NANOG-ish topic, I wonder why somebody needs to hide. Greets, Jeroen From chesteve at gmail.com Fri Sep 24 21:37:17 2010 From: chesteve at gmail.com (Christian Esteve) Date: Fri, 24 Sep 2010 18:37:17 -0300 Subject: OpenFlow In-Reply-To: <4C9D188F.2050802@unfix.org> References: <20100924141027.1E687BEC@resin11.mta.everyone.net> <4288131ED5E3024C9CD4782CECCAD2C70B9A2E3C@LMC-MAIL2.exempla.org> <4C9D188F.2050802@unfix.org> Message-ID: There is another related item planned for NANOG50: http://www.nanog.org/meetings/nanog50/abstracts.php?pt=MTYzNSZuYW5vZzUw&nm=nanog50 ----------------------------------------------------------------- An Open-Source Interoperable MPLS LSR Scott Whyte, Google Presentation Date: October 4, 2010, 12:30 PM - 1:00 PM Room: Ellington Abstract: We demonstrate a low-cost MPLS LSR capable of forwarding 4x1GE in hardware. It utilizes an open-source implementation of LDP in Quagga, open-source modifications to the Linux kernel to support MPLS, an open-source implementation of an OpenFlow controller modified to support MPLS, and a NetFPGA card as the open platform to program the hardware for MPLS forwarding. ----------------------------------------------------------------- -Christian On Fri, Sep 24, 2010 at 18:30, Jeroen Massar wrote: > On 2010-09-24 23:25, Matlock, Kenneth L wrote: >> Wow, resorting to using a spoofed email address to propagate your spam, >> and forget to remove your .sig >> >> Some people just don't take a hint, do they? I know which software >> package I WON'T be recommending to anyone (in fact, quite the opposite!) > > And also, there is a nice agenda item at NANOG50; > > http://www.nanog.org/meetings/nanog50/abstracts.php?pt=MTY2OSZuYW5vZzUw&nm=nanog50 > > 8<----------------------------------------------------------------- > Track: Open Flow > Nick McKeown, Stanford University; Matt Davy, Indiana University > Presentation Date: October 4, 2010, 4:30 PM - 6:00 PM > > Abstract: > OpenFlow: An Update > [..] > OpenFlow Trials and Deployments > ----------------------------------------------------------------->8 > > Thus as it is a NANOG-ish topic, I wonder why somebody needs to hide. > > Greets, > ?Jeroen > > -- Christian From tammy-lists at wiztech.biz Fri Sep 24 21:38:04 2010 From: tammy-lists at wiztech.biz (tammy-lists at wiztech.biz) Date: Fri, 24 Sep 2010 21:38:04 +0000 Subject: OpenFlow In-Reply-To: <4C9D188F.2050802@unfix.org> References: <20100924141027.1E687BEC@resin11.mta.everyone.net><4288131ED5E3024C9CD4782CECCAD2C70B9A2E3C@LMC-MAIL2.exempla.org><4C9D188F.2050802@unfix.org> Message-ID: <102103841-1285364285-cardhu_decombobulator_blackberry.rim.net-31604481-@bda880.bisx.prod.on.blackberry> It could be because his dumb ass got the banhammer from nanog Mods: can you pleeeease get rid of him again? Tammy Sent from my Verizon Wireless BlackBerry -----Original Message----- From: Jeroen Massar Date: Fri, 24 Sep 2010 23:30:55 To: Matlock, Kenneth L Cc: Subject: Re: OpenFlow On 2010-09-24 23:25, Matlock, Kenneth L wrote: > Wow, resorting to using a spoofed email address to propagate your spam, > and forget to remove your .sig > > Some people just don't take a hint, do they? I know which software > package I WON'T be recommending to anyone (in fact, quite the opposite!) And also, there is a nice agenda item at NANOG50; http://www.nanog.org/meetings/nanog50/abstracts.php?pt=MTY2OSZuYW5vZzUw&nm=nanog50 8<----------------------------------------------------------------- Track: Open Flow Nick McKeown, Stanford University; Matt Davy, Indiana University Presentation Date: October 4, 2010, 4:30 PM - 6:00 PM Abstract: OpenFlow: An Update [..] OpenFlow Trials and Deployments ----------------------------------------------------------------->8 Thus as it is a NANOG-ish topic, I wonder why somebody needs to hide. Greets, Jeroen From MatlockK at exempla.org Fri Sep 24 21:41:59 2010 From: MatlockK at exempla.org (Matlock, Kenneth L) Date: Fri, 24 Sep 2010 15:41:59 -0600 Subject: OpenFlow In-Reply-To: <4C9D188F.2050802@unfix.org> References: <20100924141027.1E687BEC@resin11.mta.everyone.net> <4288131ED5E3024C9CD4782CECCAD2C70B9A2E3C@LMC-MAIL2.exempla.org> <4C9D188F.2050802@unfix.org> Message-ID: <4288131ED5E3024C9CD4782CECCAD2C70B9A2E3D@LMC-MAIL2.exempla.org> Which is fine and all (being that it's on-topic). My main beef is that a certain person can't take a hint. Using an 'anonymous' re-mailer to try and get people to read nothing more than copy/paste, and then 5 billion 'references' (most of which use asinine 'docs.google.com' references instead of the actual document) strikes me as unprofessional at the least, if not infantile. I'd have thought he'd have learned the last 50 times he got smacked down for this. But of course, I'm just an ignorant American! :) Ken Matlock Network Analyst Exempla Healthcare (303) 467-4671 matlockk at exempla.org -----Original Message----- From: Jeroen Massar [mailto:jeroen at unfix.org] Sent: Friday, September 24, 2010 3:31 PM To: Matlock, Kenneth L Cc: nanog at nanog.org Subject: Re: OpenFlow On 2010-09-24 23:25, Matlock, Kenneth L wrote: > Wow, resorting to using a spoofed email address to propagate your spam, > and forget to remove your .sig > > Some people just don't take a hint, do they? I know which software > package I WON'T be recommending to anyone (in fact, quite the opposite!) And also, there is a nice agenda item at NANOG50; http://www.nanog.org/meetings/nanog50/abstracts.php?pt=MTY2OSZuYW5vZzUw& nm=nanog50 8<----------------------------------------------------------------- Track: Open Flow Nick McKeown, Stanford University; Matt Davy, Indiana University Presentation Date: October 4, 2010, 4:30 PM - 6:00 PM Abstract: OpenFlow: An Update [..] OpenFlow Trials and Deployments ----------------------------------------------------------------->8 Thus as it is a NANOG-ish topic, I wonder why somebody needs to hide. Greets, Jeroen From jeroen at unfix.org Fri Sep 24 21:45:59 2010 From: jeroen at unfix.org (Jeroen Massar) Date: Fri, 24 Sep 2010 23:45:59 +0200 Subject: OpenFlow In-Reply-To: <4288131ED5E3024C9CD4782CECCAD2C70B9A2E3D@LMC-MAIL2.exempla.org> References: <20100924141027.1E687BEC@resin11.mta.everyone.net> <4288131ED5E3024C9CD4782CECCAD2C70B9A2E3C@LMC-MAIL2.exempla.org> <4C9D188F.2050802@unfix.org> <4288131ED5E3024C9CD4782CECCAD2C70B9A2E3D@LMC-MAIL2.exempla.org> Message-ID: <4C9D1C17.3050202@unfix.org> On 2010-09-24 23:41, Matlock, Kenneth L wrote: > Which is fine and all (being that it's on-topic). My main beef is that a > certain person can't take a hint. Using an 'anonymous' re-mailer to try > and get people to read nothing more than copy/paste, and then 5 billion > 'references' (most of which use asinine 'docs.google.com' references > instead of the actual document) strikes me as unprofessional at the > least, if not infantile. > > I'd have thought he'd have learned the last 50 times he got smacked down > for this. But of course, I'm just an ignorant American! :) If you where less ignorant and more ignoring then nobody else would notice it due to their killfiles... aka 'be quiet and the trolls won't have any fun'. The mods are doing quite a fine job already from what I heard, they can't always be on guard though, sometimes they drink a bit too much whiskey ;) Greets, Jeroen From bruns at 2mbit.com Fri Sep 24 21:47:13 2010 From: bruns at 2mbit.com (Brielle Bruns) Date: Fri, 24 Sep 2010 15:47:13 -0600 Subject: OpenFlow In-Reply-To: <20100924141027.1E687BEC@resin11.mta.everyone.net> References: <20100924141027.1E687BEC@resin11.mta.everyone.net> Message-ID: <4C9D1C61.6020301@2mbit.com> On 9/24/10 3:10 PM, nanogf . wrote: > > Guillaume FORTAINE > Tel : +33(0)631092519 > Mail : gfortaine at gfortaine.biz GO AWAY FORTAINE! Geeze, do some people never take the hint? -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org / http://www.ahbl.org From tammy-lists at wiztech.biz Fri Sep 24 21:51:36 2010 From: tammy-lists at wiztech.biz (tammy-lists at wiztech.biz) Date: Fri, 24 Sep 2010 21:51:36 +0000 Subject: OpenFlow In-Reply-To: <4C9D1C17.3050202@unfix.org> References: <20100924141027.1E687BEC@resin11.mta.everyone.net><4288131ED5E3024C9CD4782CECCAD2C70B9A2E3C@LMC-MAIL2.exempla.org><4C9D188F.2050802@unfix.org><4288131ED5E3024C9CD4782CECCAD2C70B9A2E3D@LMC-MAIL2.exempla.org><4C9D1C17.3050202@unfix.org> Message-ID: <1836955139-1285365098-cardhu_decombobulator_blackberry.rim.net-489968144-@bda880.bisx.prod.on.blackberry> We all would love too but dumba$$ keeps getting new domains & email addresses. I think he ate lead paint as a kid or something. He is absolutly 190% insane Mods:: please show gilliam the door :) Sent from my Verizon Wireless BlackBerry -----Original Message----- From: Jeroen Massar Date: Fri, 24 Sep 2010 23:45:59 To: Matlock, Kenneth L Cc: Subject: Re: OpenFlow On 2010-09-24 23:41, Matlock, Kenneth L wrote: > Which is fine and all (being that it's on-topic). My main beef is that a > certain person can't take a hint. Using an 'anonymous' re-mailer to try > and get people to read nothing more than copy/paste, and then 5 billion > 'references' (most of which use asinine 'docs.google.com' references > instead of the actual document) strikes me as unprofessional at the > least, if not infantile. > > I'd have thought he'd have learned the last 50 times he got smacked down > for this. But of course, I'm just an ignorant American! :) If you where less ignorant and more ignoring then nobody else would notice it due to their killfiles... aka 'be quiet and the trolls won't have any fun'. The mods are doing quite a fine job already from what I heard, they can't always be on guard though, sometimes they drink a bit too much whiskey ;) Greets, Jeroen From cidr-report at potaroo.net Fri Sep 24 22:00:02 2010 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 24 Sep 2010 22:00:02 GMT Subject: BGP Update Report Message-ID: <201009242200.o8OM02nb054979@wattle.apnic.net> BGP Update Report Interval: 16-Sep-10 -to- 23-Sep-10 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS8151 29705 1.6% 11.9 -- Uninet S.A. de C.V. 2 - AS3464 22140 1.2% 492.0 -- ASC-NET - Alabama Supercomputer Network 3 - AS32528 17447 0.9% 2180.9 -- ABBOTT Abbot Labs 4 - AS34984 15911 0.9% 42.3 -- TELLCOM-AS Tellcom Iletisim Hizmetleri 5 - AS35931 14631 0.8% 2438.5 -- ARCHIPELAGO - ARCHIPELAGO HOLDINGS INC 6 - AS7011 13318 0.7% 11.5 -- FRONTIER-AND-CITIZENS - Frontier Communications of America, Inc. 7 - AS5536 12851 0.7% 110.8 -- Internet-Egypt 8 - AS5668 11618 0.6% 10.2 -- AS-5668 - CenturyTel Internet Holdings, Inc. 9 - AS8866 11147 0.6% 27.5 -- BTC-AS Bulgarian Telecommunication Company Plc. 10 - AS14420 10222 0.6% 17.4 -- CORPORACION NACIONAL DE TELECOMUNICACIONES - CNT EP 11 - AS24560 10197 0.6% 9.8 -- AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services 12 - AS1785 9677 0.5% 5.4 -- AS-PAETEC-NET - PaeTec Communications, Inc. 13 - AS8452 9318 0.5% 7.9 -- TE-AS TE-AS 14 - AS3816 8799 0.5% 18.2 -- COLOMBIA TELECOMUNICACIONES S.A. ESP 15 - AS10620 8691 0.5% 6.6 -- Telmex Colombia S.A. 16 - AS9155 8395 0.5% 35.7 -- QNET QualityNet AS number 17 - AS18566 8294 0.5% 7.6 -- COVAD - Covad Communications Co. 18 - AS36992 8142 0.4% 12.2 -- ETISALAT-MISR 19 - AS7545 8104 0.4% 5.7 -- TPG-INTERNET-AP TPG Internet Pty Ltd 20 - AS4755 7987 0.4% 5.9 -- TATACOMM-AS TATA Communications formerly VSNL is Leading ISP TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS35931 14631 0.8% 2438.5 -- ARCHIPELAGO - ARCHIPELAGO HOLDINGS INC 2 - AS32528 17447 0.9% 2180.9 -- ABBOTT Abbot Labs 3 - AS50571 1488 0.1% 1488.0 -- PRLIB FGBU Presidential Library named after NB Yeltsin 4 - AS53532 1451 0.1% 1451.0 -- KINGMETALS - King Architectural Metals 5 - AS22753 3789 0.2% 947.2 -- REDHAT-STUTTGART REDHAT Stuttgart 6 - AS15984 719 0.0% 719.0 -- The Joint-Stock Commercial Bank CentroCredit. 7 - AS27092 652 0.0% 652.0 -- DNIC-ASBLK-27032-27159 - DoD Network Information Center 8 - AS11613 650 0.0% 650.0 -- U-SAVE - U-Save Auto Rental of America, Inc. 9 - AS21017 5784 0.3% 578.4 -- VSI-AS VSI AS 10 - AS16861 497 0.0% 497.0 -- REVELEX - Revelex.com 11 - AS3464 22140 1.2% 492.0 -- ASC-NET - Alabama Supercomputer Network 12 - AS190 2795 0.1% 465.8 -- NSYPTSMH-POE-AS - Navy Network Information Center (NNIC) 13 - AS27094 883 0.1% 441.5 -- DNIC-ASBLK-27032-27159 - DoD Network Information Center 14 - AS38531 387 0.0% 387.0 -- SULLCROM-HK Sullivan & Cromwell LLP, Hong Kong Site, International Law Firm. 15 - AS37204 3851 0.2% 385.1 -- TELONE 16 - AS3 367 0.0% 333.0 -- NVT-AS Closed Joint Stock Company NOVOTEL 17 - AS49970 350 0.0% 350.0 -- RKRS-ISDP Rangin Kaman Rayaneh Sepahan ISDP 18 - AS48309 335 0.0% 335.0 -- AGS-AS Ariana Gostar Spadana Autonomous Number 19 - AS48431 650 0.0% 325.0 -- MAXNET MAXNET Autonomous System 20 - AS41152 650 0.0% 325.0 -- AFTAB Aftab Internet Service Provider TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 129.66.128.0/17 11021 0.6% AS3464 -- ASC-NET - Alabama Supercomputer Network 2 - 129.66.0.0/17 11020 0.6% AS3464 -- ASC-NET - Alabama Supercomputer Network 3 - 130.36.34.0/24 8713 0.5% AS32528 -- ABBOTT Abbot Labs 4 - 130.36.35.0/24 8713 0.5% AS32528 -- ABBOTT Abbot Labs 5 - 201.134.18.0/24 8656 0.5% AS8151 -- Uninet S.A. de C.V. 6 - 195.39.181.0/24 8461 0.4% AS6755 -- ASN - TURNET AS9155 -- QNET QualityNet AS number 7 - 63.211.68.0/22 8301 0.4% AS35931 -- ARCHIPELAGO - ARCHIPELAGO HOLDINGS INC 8 - 198.140.43.0/24 6237 0.3% AS35931 -- ARCHIPELAGO - ARCHIPELAGO HOLDINGS INC 9 - 216.126.136.0/22 5954 0.3% AS6316 -- AS-PAETEC-NET - PaeTec Communications, Inc. 10 - 190.65.228.0/22 5783 0.3% AS3816 -- COLOMBIA TELECOMUNICACIONES S.A. ESP 11 - 148.204.141.0/24 5089 0.3% AS8151 -- Uninet S.A. de C.V. 12 - 66.187.234.0/24 3782 0.2% AS22753 -- REDHAT-STUTTGART REDHAT Stuttgart 13 - 206.184.16.0/24 3123 0.2% AS174 -- COGENT Cogent/PSI 14 - 95.32.128.0/18 2882 0.1% AS21017 -- VSI-AS VSI AS 15 - 202.92.235.0/24 2812 0.1% AS9498 -- BBIL-AP BHARTI Airtel Ltd. 16 - 95.32.192.0/18 2780 0.1% AS21017 -- VSI-AS VSI AS 17 - 216.118.245.0/24 2763 0.1% AS22150 -- CARRIERHOUSE - Carrierhouse Corp. AS25747 -- VSC-SATELLITE-CO - VSC Satellite Co. 18 - 64.86.26.0/23 2465 0.1% AS37204 -- TELONE 19 - 193.232.105.0/24 1488 0.1% AS50571 -- PRLIB FGBU Presidential Library named after NB Yeltsin 20 - 208.51.46.0/24 1451 0.1% AS53532 -- KINGMETALS - King Architectural Metals 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 Sep 24 22:00:00 2010 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 24 Sep 2010 22:00:00 GMT Subject: The Cidr Report Message-ID: <201009242200.o8OM00V6054967@wattle.apnic.net> This report has been generated at Fri Sep 24 21:12:04 2010 AEST. The report analyses the BGP Routing Table of AS2.0 router and generates a report on aggregation potential within the table. Check http://www.cidr-report.org for a current version of this report. Recent Table History Date Prefixes CIDR Agg 17-09-10 336284 207825 18-09-10 336415 207604 19-09-10 336058 207474 20-09-10 336248 207788 21-09-10 336492 207756 22-09-10 336436 207987 23-09-10 336770 208046 24-09-10 336850 208076 AS Summary 35479 Number of ASes in routing system 15112 Number of ASes announcing only one prefix 4468 Largest number of prefixes announced by an AS AS4323 : TWTC - tw telecom holdings, inc. 97402624 Largest address span announced by an AS (/32s) AS4134 : CHINANET-BACKBONE No.31,Jin-rong Street 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'). --- 24Sep10 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 337009 208022 128987 38.3% All ASes AS6389 3779 282 3497 92.5% BELLSOUTH-NET-BLK - BellSouth.net Inc. AS4323 4468 1924 2544 56.9% TWTC - tw telecom holdings, inc. AS19262 1819 285 1534 84.3% VZGNI-TRANSIT - Verizon Online LLC AS4766 1859 515 1344 72.3% KIXS-AS-KR Korea Telecom AS22773 1195 66 1129 94.5% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. AS17488 1347 284 1063 78.9% HATHWAY-NET-AP Hathway IP Over Cable Internet AS4755 1346 288 1058 78.6% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP AS18566 1087 63 1024 94.2% COVAD - Covad Communications Co. AS5668 1111 94 1017 91.5% AS-5668 - CenturyTel Internet Holdings, Inc. AS10620 1319 345 974 73.8% Telmex Colombia S.A. AS6478 1352 413 939 69.5% ATT-INTERNET3 - AT&T WorldNet Services AS1785 1797 961 836 46.5% AS-PAETEC-NET - PaeTec Communications, Inc. AS13343 1423 642 781 54.9% SCRR-13343 - Road Runner HoldCo LLC AS8452 1130 418 712 63.0% TE-AS TE-AS AS7303 783 101 682 87.1% Telecom Argentina S.A. AS8151 1340 679 661 49.3% Uninet S.A. de C.V. AS7545 1407 752 655 46.6% TPG-INTERNET-AP TPG Internet Pty Ltd AS18101 883 247 636 72.0% RIL-IDC Reliance Infocom Ltd Internet Data Centre, AS4808 936 304 632 67.5% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network AS4804 670 73 597 89.1% MPX-AS Microplex PTY LTD AS28573 1114 581 533 47.8% NET Servicos de Comunicao S.A. AS4780 704 177 527 74.9% SEEDNET Digital United Inc. AS17676 606 81 525 86.6% GIGAINFRA Softbank BB Corp. AS7552 643 126 517 80.4% VIETEL-AS-AP Vietel Corporation AS7018 1459 951 508 34.8% ATT-INTERNET4 - AT&T WorldNet Services AS24560 1036 535 501 48.4% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services AS9443 572 76 496 86.7% INTERNETPRIMUS-AS-AP Primus Telecommunications AS7011 1157 667 490 42.4% FRONTIER-AND-CITIZENS - Frontier Communications of America, Inc. AS14420 580 90 490 84.5% CORPORACION NACIONAL DE TELECOMUNICACIONES - CNT EP AS22047 558 80 478 85.7% VTR BANDA ANCHA S.A. Total 39480 12100 27380 69.4% Top 30 total Possible Bogus Routes 31.0.0.0/16 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 31.1.0.0/21 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 31.1.24.0/24 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 41.222.79.0/24 AS36938 AMSCOTELECOMS Amsco Telecommunications Nigeria Limited 41.223.92.0/22 AS36936 CELTEL-GABON Celtel Gabon Internet Service 41.223.196.0/24 AS36990 41.223.197.0/24 AS36990 41.223.198.0/24 AS36990 41.223.199.0/24 AS36990 50.32.0.0/12 AS5650 FRONTIER-FRTR - Frontier Communications of America, Inc. 50.48.0.0/13 AS5650 FRONTIER-FRTR - Frontier Communications of America, Inc. 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV 62.61.221.0/24 AS24974 TACHYON-EU Tachyon Europe BV 64.20.80.0/20 AS40028 SPD-NETWORK-1 - SPD NETWORK 64.21.192.0/20 AS11610 INETNEBR-1 - Internet Nebraska Corporation 64.21.212.0/22 AS11610 INETNEBR-1 - Internet Nebraska Corporation 64.21.216.0/21 AS11610 INETNEBR-1 - Internet Nebraska Corporation 64.82.128.0/19 AS16617 COMMUNITYISP - CISP 64.82.160.0/19 AS16617 COMMUNITYISP - CISP 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.47.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 66.207.32.0/20 AS23011 66.230.240.0/20 AS27286 66.245.176.0/20 AS19318 NJIIX-AS-1 - NEW JERSEY INTERNATIONAL INTERNET EXCHANGE LLC 68.234.0.0/20 AS40430 COLO4JAX-AS - colo4jax, LLC 68.234.16.0/20 AS40430 COLO4JAX-AS - colo4jax, LLC 69.6.80.0/24 AS13442 69.6.81.0/24 AS13442 71.19.134.0/23 AS3313 INET-AS I.NET S.p.A. 71.19.160.0/23 AS4648 NZIX-2 Netgate 72.22.32.0/19 AS33150 72.22.61.0/24 AS33150 72.22.62.0/24 AS33150 76.77.32.0/19 AS2828 XO-AS15 - XO Communications 80.88.10.0/24 AS33774 DJAWEB 80.88.12.0/24 AS33779 wataniya-telecom-as 96.45.160.0/24 AS3257 TINET-BACKBONE Tinet SpA 96.45.161.0/24 AS3257 TINET-BACKBONE Tinet SpA 96.45.162.0/24 AS3257 TINET-BACKBONE Tinet SpA 96.45.163.0/24 AS3257 TINET-BACKBONE Tinet SpA 96.45.164.0/24 AS3257 TINET-BACKBONE Tinet SpA 96.45.165.0/24 AS3257 TINET-BACKBONE Tinet SpA 96.45.166.0/24 AS3257 TINET-BACKBONE Tinet SpA 96.45.167.0/24 AS3257 TINET-BACKBONE Tinet SpA 96.45.168.0/21 AS3257 TINET-BACKBONE Tinet SpA 96.47.48.0/20 AS3257 TINET-BACKBONE Tinet SpA 110.34.44.0/22 AS12653 COMTONET KB Impuls Hellas 110.173.64.0/19 AS37963 CNNIC-ALIBABA-CN-NET-AP Alibaba (China) Technology Co., Ltd. 114.142.160.0/21 AS38595 OCEAN-AS-AU Ocean Broadband - Wireless Broadband Internet provider, Perth 114.142.160.0/22 AS38595 OCEAN-AS-AU Ocean Broadband - Wireless Broadband Internet provider, Perth 114.142.168.0/21 AS38595 OCEAN-AS-AU Ocean Broadband - Wireless Broadband Internet provider, Perth 114.142.168.0/23 AS38595 OCEAN-AS-AU Ocean Broadband - Wireless Broadband Internet provider, Perth 114.142.171.0/24 AS38595 OCEAN-AS-AU Ocean Broadband - Wireless Broadband Internet provider, Perth 114.142.172.0/24 AS38595 OCEAN-AS-AU Ocean Broadband - Wireless Broadband Internet provider, Perth 115.42.0.0/24 AS24541 FORTYFIVERU-AS-AU 45RU Pty Ltd. Internet Service Provider, Perth, Western Australia. 115.42.5.0/24 AS24541 FORTYFIVERU-AS-AU 45RU Pty Ltd. Internet Service Provider, Perth, Western Australia. 115.42.6.0/24 AS24541 FORTYFIVERU-AS-AU 45RU Pty Ltd. Internet Service Provider, Perth, Western Australia. 115.42.11.0/24 AS24541 FORTYFIVERU-AS-AU 45RU Pty Ltd. Internet Service Provider, Perth, Western Australia. 115.42.20.0/24 AS24541 FORTYFIVERU-AS-AU 45RU Pty Ltd. Internet Service Provider, Perth, Western Australia. 115.42.28.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.29.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.30.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.31.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.40.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.42.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.43.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.44.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.47.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.48.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.49.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.50.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.51.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.52.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.53.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.54.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.55.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.56.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.57.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.58.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.59.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.61.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.62.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.63.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 116.68.136.0/21 AS28045 Pantel Communications 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.168.0/21 AS9931 CAT-AP The Communication Authoity of Thailand, CAT 122.0.0.0/8 AS38356 TIMENET BeiJing Sincerity-times Network Technology Project Ltd. 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 173.225.112.0/20 AS3257 TINET-BACKBONE Tinet SpA 176.0.0.0/16 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 176.1.0.0/21 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 176.1.24.0/24 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 177.0.0.0/16 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 177.1.0.0/21 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 177.1.8.0/24 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 181.0.0.0/16 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 181.1.0.0/21 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 181.1.8.0/24 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 190.102.32.0/20 AS30058 ACTIVO-SYSTEMS-AS30058 ACTIVO-SYSTEMS-AS30058 192.9.0.0/16 AS11479 BRM-SUN-AS - Sun Microsystems, Inc 192.64.85.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.69.108.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.101.46.0/24 AS6503 Axtel, S.A.B. de C. V. 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.252.0/22 AS680 DFN-IP service X-WiN 192.131.233.0/24 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 192.154.32.0/19 AS81 NCREN - MCNC 192.154.64.0/19 AS81 NCREN - MCNC 192.188.208.0/20 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 196.2.224.0/22 AS24863 LINKdotNET-AS 196.6.108.0/24 AS5713 SAIX-NET 196.13.201.0/24 AS2018 TENET-1 196.13.202.0/24 AS2018 TENET-1 196.13.203.0/24 AS2018 TENET-1 196.13.204.0/24 AS2018 TENET-1 196.110.105.0/24 AS8513 SKYVISION SkyVision Network Services 196.201.248.0/24 AS30991 SAHANNET Sahannet AS Network 196.201.249.0/24 AS30991 SAHANNET Sahannet AS Network 196.201.250.0/24 AS30991 SAHANNET Sahannet AS Network 196.201.251.0/24 AS30991 SAHANNET Sahannet AS Network 196.201.253.0/24 AS30991 SAHANNET Sahannet AS Network 196.201.255.0/24 AS30991 SAHANNET Sahannet AS Network 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.51.100.0/24 AS16953 ASCENT-MEDIA-GROUP-LLC - Ascent Media Group, LLC 198.73.210.0/24 AS21570 ACI-1 - Accelerated Connections Inc. 198.74.38.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services 198.74.39.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services 198.74.40.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services 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.99.241.0/24 AS11797 AC-NIELSEN-AS AC NIELSEN 198.135.236.0/24 AS4358 XNET - XNet Information Systems, Inc. 198.161.87.0/24 AS6539 GT-BELL - Bell Canada 198.163.214.0/24 AS21804 ACCESS-SK - Access Communications Co-operative Limited 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 198.182.235.0/24 AS3356 LEVEL3 Level 3 Communications 199.10.0.0/16 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center 199.16.32.0/19 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 199.121.0.0/16 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.123.16.0/20 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.185.130.0/23 AS19662 UNISERVE-ONLINE - Uniserve On Line 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.1.112.0/24 AS29754 GO2TEL GO2TEL.COM INC. 200.24.73.0/24 AS26061 Equant Colombia 200.24.78.0/26 AS3549 GBLX Global Crossing Ltd. 200.24.78.64/26 AS3549 GBLX Global Crossing Ltd. 202.9.55.0/24 AS2764 AAPT AAPT Limited 202.9.57.0/24 AS2764 AAPT AAPT Limited 202.38.63.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.58.113.0/24 AS19161 202.61.75.0/24 AS9927 PHILCOMNET-PH A Multihomed ISP Company 202.66.128.0/18 AS9584 GENESIS-AP Diyixian.com Limited 202.66.160.0/19 AS9584 GENESIS-AP Diyixian.com Limited 202.66.160.0/20 AS9584 GENESIS-AP Diyixian.com Limited 202.66.176.0/20 AS9584 GENESIS-AP Diyixian.com Limited 202.66.184.0/24 AS9584 GENESIS-AP Diyixian.com Limited 202.66.186.0/24 AS9584 GENESIS-AP Diyixian.com Limited 202.66.188.0/24 AS9584 GENESIS-AP Diyixian.com Limited 202.66.189.0/24 AS9584 GENESIS-AP Diyixian.com Limited 202.66.190.0/24 AS9584 GENESIS-AP Diyixian.com Limited 202.73.144.0/20 AS4788 TMNET-AS-AP TM Net, Internet Service Provider 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.133.37.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.150.227.0/24 AS17727 NAPINFO-AS-AP PT. NAP Info Lintas Nusa 202.174.70.0/24 AS21175 WIS WIS S.A. : WIND International Services 202.174.125.0/24 AS9498 BBIL-AP BHARTI Airtel Ltd. 202.174.125.128/26 AS9498 BBIL-AP BHARTI Airtel Ltd. 202.176.1.0/24 AS9942 COMINDICO-AP SOUL Converged Communications Australia 202.179.130.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.179.131.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.179.133.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.179.134.0/24 AS23966 LDN-AS-PK LINKdotNET Telecom Limited 202.179.144.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.179.149.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.179.150.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 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.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.175.98.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 203.175.99.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 203.175.103.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 203.175.107.0/24 AS45595 PKTELECOM-AS-PK Pakistan Telecom Company Limited 203.175.110.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 204.9.216.0/23 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 204.10.232.0/21 AS33150 204.19.14.0/23 AS577 BACOM - Bell Canada 204.28.104.0/21 AS25973 MZIMA - Mzima Networks, Inc. 204.209.114.0/24 AS13768 PEER1 - Peer 1 Network Inc. 204.238.70.0/24 AS36826 205.150.0.0/15 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 205.189.134.0/24 AS11814 DISTRIBUTEL-AS11814 - DISTRIBUTEL COMMUNICATIONS LTD. 205.196.24.0/22 AS33724 BIZNESSHOSTING - VOLICO 205.210.145.0/24 AS11814 DISTRIBUTEL-AS11814 - DISTRIBUTEL COMMUNICATIONS LTD. 206.72.192.0/23 AS27375 IDS-TELECOM - IDS Telecom 206.72.194.0/23 AS27375 IDS-TELECOM - IDS Telecom 206.123.129.0/24 AS10790 INREACH-AS - InReach Internet 206.180.240.0/20 AS12083 KNOLOGY-NET - Knology Holdings 206.197.184.0/24 AS23304 DATOTEL-STL-AS - Datotel LLC, a NetLabs LLC Company 207.174.131.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.132.0/23 AS26116 INDRA - Indra's Net Inc. 207.174.152.0/23 AS26116 INDRA - Indra's Net Inc. 207.174.154.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.155.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.188.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.189.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.190.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.191.0/24 AS26116 INDRA - Indra's Net Inc. 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.64.200.0/22 AS11730 CIL-ASN - Circle Internet LTD 208.64.240.0/21 AS13871 TELEBYTE-NW - Telebyte NW 208.73.4.0/22 AS27630 PREMIER - Premier Innovations, LLC 208.78.165.0/24 AS16565 208.92.196.0/22 AS10929 NETELLIGENT - Netelligent Hosting Services Inc. 208.92.199.0/24 AS26198 3MENATWORK - 3Men at Work Integrated Networks, Inc. 209.54.123.0/24 AS6062 NETPLEX - NETPLEX 209.105.224.0/19 AS20074 209.165.239.0/24 AS209 ASN-QWEST - Qwest Communications Company, LLC 209.177.64.0/20 AS6461 MFNX MFN - Metromedia Fiber Network 209.213.0.0/20 AS33005 ELTOPIA - Eltopia.com, LLC 209.213.1.0/24 AS7849 CROCKERCOM - CROCKER COMMUNICATIONS 209.213.4.0/24 AS7849 CROCKERCOM - CROCKER COMMUNICATIONS 209.236.96.0/20 AS3257 TINET-BACKBONE Tinet SpA 210.5.128.0/20 AS4837 CHINA169-BACKBONE CNCGROUP China169 Backbone 210.56.150.0/23 AS38138 INTECH-TRANSIT-BD InTech Online Limited, INTERNET SERVICE LIMITED 210.247.224.0/19 AS7496 WEBCENTRAL-AS WebCentral 216.10.235.0/24 AS13780 NTNCOMMUNICATIONS - NTN 216.10.236.0/24 AS13780 NTNCOMMUNICATIONS - NTN 216.21.196.0/24 AS12251 INVISION - Invision.com, Inc. 216.21.201.0/24 AS12251 INVISION - Invision.com, Inc. 216.21.202.0/24 AS12251 INVISION - Invision.com, Inc. 216.21.206.0/23 AS12251 INVISION - Invision.com, Inc. 216.47.32.0/20 AS3257 TINET-BACKBONE Tinet SpA 216.58.192.0/24 AS22702 X5SOLUTIONS - X5 Solutions, Inc. 216.58.197.0/24 AS22702 X5SOLUTIONS - X5 Solutions, Inc. 216.58.200.0/24 AS18530 ISOMEDIA-1 - Isomedia 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.250.112.0/20 AS7296 ALCHEMYNET - Alchemy Communications, Inc. 216.250.116.0/24 AS36066 UNI-MARKETING-ALLIANCE - Webhost4life.com 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 alex at corp.nac.net Sat Sep 25 00:28:12 2010 From: alex at corp.nac.net (Alex Rubenstein) Date: Fri, 24 Sep 2010 20:28:12 -0400 Subject: Routers in Data Centers In-Reply-To: References: Message-ID: > While this question has many dimensions and there is no real > definition of either I suspect that what many people mean when they > talk about a DC routers is: >From the datacenter operator prospective, it would be nice if some of these vendors would acknowledge the need for front-to-back cooling. I mean, it is 2010. From ras at e-gerbil.net Sat Sep 25 01:28:37 2010 From: ras at e-gerbil.net (Richard A Steenbergen) Date: Fri, 24 Sep 2010 20:28:37 -0500 Subject: Routers in Data Centers In-Reply-To: References: Message-ID: <20100925012837.GN1946@gerbil.cluepon.net> On Fri, Sep 24, 2010 at 03:52:22PM +0530, Venkatesh Sriram wrote: > Hi, > > Can somebody educate me on (or pass some pointers) what differentiates > a router operating and optimized for data centers versus, say a router > work in the metro ethernet space? What is it thats required for > routers operating in data centers? High throughput, what else? A "datacenter router" is a box which falls into a particular market segment, characterized by extremely low cost, low latency, and high density ethernet-centric boxes, at the expense of "advanced" features typically found in more traditional routers. For example, these boxes tend to lack any support for non-ethernet interfaces, MPLS, advanced VLAN tag manipulation, advanced packet filters, and many have limited FIB sizes. These days it also tends to mean you'll be getting a box with only (or mostly) SFP+ interfaces, which are cheaper and easier to do high density 10GE with, but at the expense of "long reach" optic availability. A "metro ethernet" box also implies a particular market segment, typically a smaller box (1-2U) that has certain advanced features which are typically not found in other "small" boxes. Specifically, you're likely to see advanced VLAN tag manipulation and stacking capabilities, MPLS support for doing pseudowire/vpn PE termination, etc, that you might normally only expect to see on a large carrier-class router. Also, an interesting side-effect of the quest for high density 10GE at low prices is that modern datacenter routers are largely built on third party "commodity" silicon rather than the traditional in-house ASIC designs. Many of the major router vendors (Cisco, Juniper, Foundry, Force10, etc) are currently producing "datacenter routers" which are actually just their software (or worse, someone else's software with a little search and replace action on a few strings) wrapped around third party ASICs (EZchip, Marvell, Broadcom, Fulcrum, etc). These boxes can definitely offer some excellent price/performance numbers, but one unfortunate side effect is that many (actually, most) of these chips have not been fully baked by the years of experience the more traditional router vendors have developed. Many of them have some very VERY serious design flaws, causing everything from preventing them from fully implementing some of the features you would normally except from a quality rouer (multi-label stack MPLS, routed vlan interface counters, proper control-plane DoS filter/policing capabilities, etc), or worse (in some cases, much, much worse). YYMV, but the 30 second summary is that many vendors consider "datacenter" users and/or use cases to be unsophisticated, and they're hoping you won't notice or care about some of these serious design flaws, just the price per port. Depending on your application, that may or may not be true. :) -- Richard A Steenbergen http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) From vgill at vijaygill.com Sat Sep 25 05:07:36 2010 From: vgill at vijaygill.com (vijay gill) Date: Fri, 24 Sep 2010 22:07:36 -0700 Subject: Facebook Engineering on today's outage In-Reply-To: <3355550.3590.1285294632830.JavaMail.root@benjamin.baylink.com> References: <44017.1922.qm@web59605.mail.ac4.yahoo.com> <3355550.3590.1285294632830.JavaMail.root@benjamin.baylink.com> Message-ID: On Thu, Sep 23, 2010 at 7:17 PM, Jay R. Ashworth wrote: > http://www.facebook.com/notes/facebook-engineering/more-details-on-todays-outage/431441338919 > > Apparently, our surmise about Akamai notwithstanding, the problem was actually > internal to their app-specific caching facilities, which went into Sorcerer's > Apprentice mode, and they had to kill them all and let ghod sort them out. > > More if I get it; hope that posting's public. That was a model postmortem. Wish more companies had that sort of detail and clarity around what went wrong and what was being done to fix it. /vijay > > Cheers, > -- jra > > -- > Jay R. Ashworth ? ? ? ? ? ? ? ? ? Baylink ? ? ? ? ? ? ? ? ? ? ?jra at baylink.com > Designer ? ? ? ? ? ? ? ? ? ? The Things I Think ? ? ? ? ? ? ? ? ? ? ? RFC 2100 > Ashworth & Associates ? ? http://baylink.pitas.com ? ? ? ? ? ? ? ? ? ? '87 e24 > St Petersburg FL USA ? ? ?http://photo.imageinc.us ? ? ? ? ? ? +1 727 647 1274 > > ? ?Start a man a fire, and he'll be warm all night. > ? ? Set a man on fire, and he'll be warm for the rest of his life. > > From sking at kingrst.com Sat Sep 25 07:11:25 2010 From: sking at kingrst.com (Steven King) Date: Sat, 25 Sep 2010 03:11:25 -0400 Subject: Routers in Data Centers In-Reply-To: <20100925012837.GN1946@gerbil.cluepon.net> References: <20100925012837.GN1946@gerbil.cluepon.net> Message-ID: <4C9DA09D.9080801@kingrst.com> Cisco uses their own ASICS is their higher end flag ship devices. Devices such as the Catalyst 6500 series or the 2960 switches. You pretty much singled out all the major players, including those who have been bought out (Foundry by HP) and claimed they do not provide their own, yet 3rd party flawed ASICS. I am actually surprised you didn't mention HP, Linksys or Dell as they are the most guilty of using 3rd party ASICS and shotty software. If you are buying data center grade equipment from these vendors, it will be quality hardware backed by their support (if purchased) such as Cisco's SmartNet agreements. Moral of the story, do your research on the devices you plan to implement and ask for data sheets on how the features you need are handled (in software or hardware). I know Juniper and Cisco provide such documentation for their devices. Quality hardware, however more expensive, will give you less trouble in the long run. You truly get what you pay for in the networking industry. On 9/24/10 9:28 PM, Richard A Steenbergen wrote: > On Fri, Sep 24, 2010 at 03:52:22PM +0530, Venkatesh Sriram wrote: >> Hi, >> >> Can somebody educate me on (or pass some pointers) what differentiates >> a router operating and optimized for data centers versus, say a router >> work in the metro ethernet space? What is it thats required for >> routers operating in data centers? High throughput, what else? > A "datacenter router" is a box which falls into a particular market > segment, characterized by extremely low cost, low latency, and high > density ethernet-centric boxes, at the expense of "advanced" features > typically found in more traditional routers. For example, these boxes > tend to lack any support for non-ethernet interfaces, MPLS, advanced > VLAN tag manipulation, advanced packet filters, and many have limited > FIB sizes. These days it also tends to mean you'll be getting a box with > only (or mostly) SFP+ interfaces, which are cheaper and easier to do > high density 10GE with, but at the expense of "long reach" optic > availability. > > A "metro ethernet" box also implies a particular market segment, > typically a smaller box (1-2U) that has certain advanced features which > are typically not found in other "small" boxes. Specifically, you're > likely to see advanced VLAN tag manipulation and stacking capabilities, > MPLS support for doing pseudowire/vpn PE termination, etc, that you > might normally only expect to see on a large carrier-class router. > > Also, an interesting side-effect of the quest for high density 10GE at > low prices is that modern datacenter routers are largely built on third > party "commodity" silicon rather than the traditional in-house ASIC > designs. Many of the major router vendors (Cisco, Juniper, Foundry, > Force10, etc) are currently producing "datacenter routers" which are > actually just their software (or worse, someone else's software with a > little search and replace action on a few strings) wrapped around third > party ASICs (EZchip, Marvell, Broadcom, Fulcrum, etc). These boxes can > definitely offer some excellent price/performance numbers, but one > unfortunate side effect is that many (actually, most) of these chips > have not been fully baked by the years of experience the more > traditional router vendors have developed. Many of them have some very > VERY serious design flaws, causing everything from preventing them from > fully implementing some of the features you would normally except from a > quality rouer (multi-label stack MPLS, routed vlan interface counters, > proper control-plane DoS filter/policing capabilities, etc), or worse > (in some cases, much, much worse). YYMV, but the 30 second summary is > that many vendors consider "datacenter" users and/or use cases to be > unsophisticated, and they're hoping you won't notice or care about some > of these serious design flaws, just the price per port. Depending on > your application, that may or may not be true. :) > -- Steve King Senior Linux Engineer - Advance Internet, Inc. Cisco Certified Network Associate CompTIA Linux+ Certified Professional CompTIA A+ Certified Professional From ras at e-gerbil.net Sat Sep 25 09:35:01 2010 From: ras at e-gerbil.net (Richard A Steenbergen) Date: Sat, 25 Sep 2010 04:35:01 -0500 Subject: Routers in Data Centers In-Reply-To: <4C9DA09D.9080801@kingrst.com> References: <20100925012837.GN1946@gerbil.cluepon.net> <4C9DA09D.9080801@kingrst.com> Message-ID: <20100925093501.GQ1946@gerbil.cluepon.net> On Sat, Sep 25, 2010 at 03:11:25AM -0400, Steven King wrote: > Cisco uses their own ASICS is their higher end flag ship devices. > Devices such as the Catalyst 6500 series or the 2960 switches. You > pretty much singled out all the major players, including those who > have been bought out (Foundry by HP) and claimed they do not provide > their own, yet 3rd party flawed ASICS. I am actually surprised you > didn't mention HP, Linksys or Dell as they are the most guilty of > using 3rd party ASICS and shotty software. If you are buying data > center grade equipment from these vendors, it will be quality hardware > backed by their support (if purchased) such as Cisco's SmartNet > agreements. My point was that every major vendor, even the ones who normally make their own in-house ASICs, are also actively selling third party silicon (or in some cases complete third party boxes) in order to compete in the "cheap" "datacenter optimized" space. Folks like HP and Dell were never in the business of making real routers to begin with, so them selling a Broadcom reference design with 30 seconds of search and replace action on the bundled software is not much of a shocker. The guys who do a better job of it, like Foundry (who was bought by Brocade, not HP), at least manage to use their own OS as a wrapper around the third party hardware. But my other major point was that almost all of these third party ASICs are sub-par in some way compared to the more traditional in-house hardware. Many of them have critical design flaws that will limit them greatly, and many of these design flaws are only just now being discovered by the router vendors who are selling them. BTW, Cisco is actually the exception to the "datacenter optimized" boxes being third party, as their Nexus 7K is an evolution of the 6500/7600 EARL ASICs, and their third party hw boxes are EZchip based ASR9k's. Of course their Nexus software roadmap looks surprisingly similar to other vendors doing it with third party hw, go figure. :) > Moral of the story, do your research on the devices you plan to > implement and ask for data sheets on how the features you need are > handled (in software or hardware). I know Juniper and Cisco provide > such documentation for their devices. Quality hardware, however more > expensive, will give you less trouble in the long run. You truly get > what you pay for in the networking industry. It takes a pretty significant amount of experience and inside knowledge to know who is producing the hardware and what the particular issues are, which is probably well beyond most people. The vendors aren't going to come out and tell you "Oh woops we can't actually install a full routing table in our FIB like we said we could", or "Oh btw this box can't filter control-plane traffic and any packet kiddie with a T1 can take you down", or "FYI you won't be able to bill your customers 'cause the vlan counters don't work", or "just so you know, this box can't load balance for shit, and L2 netflow won't work", or "yeah sorry you'll never be able to do a double stack MPLS VPN". The devil is in the caveats, and the commodity silicon that's all over the datacenter space right now is certainly full of them. -- Richard A Steenbergen http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) From sethm at rollernet.us Sat Sep 25 16:05:29 2010 From: sethm at rollernet.us (Seth Mattinen) Date: Sat, 25 Sep 2010 09:05:29 -0700 Subject: Routers in Data Centers In-Reply-To: References: Message-ID: <4C9E1DC9.1010809@rollernet.us> On 9/24/10 5:28 PM, Alex Rubenstein wrote: >> While this question has many dimensions and there is no real >> definition of either I suspect that what many people mean when they >> talk about a DC routers is: > >>From the datacenter operator prospective, it would be nice if some of these vendors would acknowledge the need for front-to-back cooling. I mean, it is 2010. > Well, if you look at the hardware it's dead obvious: airflow goes across the linecards. Nexus 7k 10-slot has front bottom to back top airflow because it uses vertically oriented cards. ~Seth From sking at kingrst.com Sat Sep 25 17:16:14 2010 From: sking at kingrst.com (Steven King) Date: Sat, 25 Sep 2010 13:16:14 -0400 Subject: Routers in Data Centers In-Reply-To: <20100925093501.GQ1946@gerbil.cluepon.net> References: <20100925012837.GN1946@gerbil.cluepon.net> <4C9DA09D.9080801@kingrst.com> <20100925093501.GQ1946@gerbil.cluepon.net> Message-ID: <4C9E2E5E.6070107@kingrst.com> On 9/25/10 5:35 AM, Richard A Steenbergen wrote: > On Sat, Sep 25, 2010 at 03:11:25AM -0400, Steven King wrote: >> Cisco uses their own ASICS is their higher end flag ship devices. >> Devices such as the Catalyst 6500 series or the 2960 switches. You >> pretty much singled out all the major players, including those who >> have been bought out (Foundry by HP) and claimed they do not provide >> their own, yet 3rd party flawed ASICS. I am actually surprised you >> didn't mention HP, Linksys or Dell as they are the most guilty of >> using 3rd party ASICS and shotty software. If you are buying data >> center grade equipment from these vendors, it will be quality hardware >> backed by their support (if purchased) such as Cisco's SmartNet >> agreements. > My point was that every major vendor, even the ones who normally make > their own in-house ASICs, are also actively selling third party silicon > (or in some cases complete third party boxes) in order to compete in the > "cheap" "datacenter optimized" space. Folks like HP and Dell were never > in the business of making real routers to begin with, so them selling a > Broadcom reference design with 30 seconds of search and replace action > on the bundled software is not much of a shocker. The guys who do a > better job of it, like Foundry (who was bought by Brocade, not HP), at > least manage to use their own OS as a wrapper around the third party > hardware. But my other major point was that almost all of these third > party ASICs are sub-par in some way compared to the more traditional > in-house hardware. Many of them have critical design flaws that will > limit them greatly, and many of these design flaws are only just now > being discovered by the router vendors who are selling them. > > BTW, Cisco is actually the exception to the "datacenter optimized" boxes > being third party, as their Nexus 7K is an evolution of the 6500/7600 > EARL ASICs, and their third party hw boxes are EZchip based ASR9k's. Of > course their Nexus software roadmap looks surprisingly similar to other > vendors doing it with third party hw, go figure. :) Cisco definitely is doing some interesting things with the Nexus. Have you seen the virtualized version? >> Moral of the story, do your research on the devices you plan to >> implement and ask for data sheets on how the features you need are >> handled (in software or hardware). I know Juniper and Cisco provide >> such documentation for their devices. Quality hardware, however more >> expensive, will give you less trouble in the long run. You truly get >> what you pay for in the networking industry. > It takes a pretty significant amount of experience and inside knowledge > to know who is producing the hardware and what the particular issues > are, which is probably well beyond most people. The vendors aren't going > to come out and tell you "Oh woops we can't actually install a full > routing table in our FIB like we said we could", or "Oh btw this box > can't filter control-plane traffic and any packet kiddie with a T1 can > take you down", or "FYI you won't be able to bill your customers 'cause > the vlan counters don't work", or "just so you know, this box can't load > balance for shit, and L2 netflow won't work", or "yeah sorry you'll > never be able to do a double stack MPLS VPN". The devil is in the > caveats, and the commodity silicon that's all over the datacenter space > right now is certainly full of them. I agree it takes a significant amount of experience to know that informatin off the top of your head, but I am able to find block diagrams, and part information for 98% of Cisco's hardware. Old or new. One needs to do their research on the device to know if it meets their needs. The caveats are everywhere I agree, even some of the experienced network guys get tripped up with them if they aren't careful. Planning is the key to overcoming these problems. -- Steve King Senior Linux Engineer - Advance Internet, Inc. Cisco Certified Network Associate CompTIA Linux+ Certified Professional CompTIA A+ Certified Professional From joelja at bogus.com Sat Sep 25 19:16:33 2010 From: joelja at bogus.com (Joel Jaeggli) Date: Sat, 25 Sep 2010 12:16:33 -0700 Subject: Routers in Data Centers In-Reply-To: <4C9E1DC9.1010809@rollernet.us> References: <4C9E1DC9.1010809@rollernet.us> Message-ID: <556A0EF3-0038-4DD1-B752-FE272F2EB0DF@bogus.com> On Sep 25, 2010, at 9:05, Seth Mattinen wrote: > On 9/24/10 5:28 PM, Alex Rubenstein wrote: >>> While this question has many dimensions and there is no real >>> definition of either I suspect that what many people mean when they >>> talk about a DC routers is: >> >>> From the datacenter operator prospective, it would be nice if some of these vendors would acknowledge the need for front-to-back cooling. I mean, it is 2010. Bakplanes make direct front to back cooling hard. non-modular platforms can do it just fine however. >> > > Well, if you look at the hardware it's dead obvious: airflow goes across > the linecards. Nexus 7k 10-slot has front bottom to back top airflow > because it uses vertically oriented cards. > > ~Seth > From phschmidt at alum.mit.edu Sat Sep 25 19:36:56 2010 From: phschmidt at alum.mit.edu (Peter H. Schmidt) Date: Sat, 25 Sep 2010 15:36:56 -0400 Subject: MPLS service pricing Message-ID: <5B1AA555-FAD1-460E-83F7-A6E98E5FDC7F@alum.mit.edu> This is a bit of a long shot, but I am wondering if anyone can share the prices they are seeing for MPLS service in North America? I will be happy to anonymize, collate and share back to the list for everyone's information. I am working on some economic modeling for enterprise WANs in NA, but finding out the prices in this commodity market has gotten very challenging. If you have it by port speed, number of COS, number of sites, that would be great - but I don't really expect it. A total monthly charge with some estimate of how many sites at which speeds and with how many classes will be good enough. You don't need to name your vendor if you don't wish to. Any/all numbers will be greatly appreciated! Thanks -- Peter -- Peter H. Schmidt phschmidt at alum.mit.edu From rodrick.brown at gmail.com Sat Sep 25 20:16:46 2010 From: rodrick.brown at gmail.com (Rodrick Brown) Date: Sat, 25 Sep 2010 16:16:46 -0400 Subject: Online games stealing your bandwidth Message-ID: I think most people are aware that the Blizzard "World of WarcCraft" patcher distributes files through Bittorrent, however apparently a number of other MMO companies (LotR, Lego) are apparently doing something similar but aren't as upfront about it, and are installing Windows services which seed whenever the computer is online. Game Companies Should Play Fair With P2P | TorrentFreak If you follow the links in the article people are complaining that the LotR process has served 70gb in a week, others are complaining that the service is resulting in 300ms pings, and unusable connections. This is a very grey area it will be interesting how this issue unfolds in the long run. -- [ Rodrick R. Brown ] http://www.rodrickbrown.com http://www.linkedin.com/in/rodrickbrown From leo.woltz at gmail.com Sat Sep 25 20:37:10 2010 From: leo.woltz at gmail.com (Leo Woltz) Date: Sat, 25 Sep 2010 16:37:10 -0400 Subject: Mobile Operator Connectivity Message-ID: I am looking for some guidance from the list. We will soon be deploying wireless payment devices (CDMA/GSM). We are looking at options on where to locate the servers that will run the backend payment gateways; we would like the least amount of latency between the servers and the wireless networks as possible. The wireless networks we will be deploying the devices on are: AT&T Wireless Verizon Wireless Sprint PCS Rogers Wireless Bell Mobility Telus Mobility Vodafone I was thinking we have a few options, to try and peer with the wireless networks directly, buy bandwidth from networks that are directly peered with the wireless operators or the Global Roaming Exchange Peering service that Equinix runs but I have not been able to find out much more then what is on Equinix?s public web site. We also have a need to peer with PayPal and Amazon. I welcome the lists comments and recommendations. From matthew at walster.org Sat Sep 25 20:43:25 2010 From: matthew at walster.org (Matthew Walster) Date: Sat, 25 Sep 2010 21:43:25 +0100 Subject: Online games stealing your bandwidth In-Reply-To: References: Message-ID: On 25 September 2010 21:16, Rodrick Brown wrote: > I think most people are aware that the Blizzard "World of WarcCraft" patcher > distributes files through Bittorrent, I once read an article talking about making BitTorrent scalable by using anycasted caching services at the ISP's closest POP to the end user. Given sufficient traffic on a specified torrent, the caching device would build up the file, then distribute that direct to the subscriber in the form of an additional (preferred) peer. Similar to a CDN or Usenet, but where it was cached rather than deliberately pushed out from a locus. Was anything ever standardised in that field? I imagine with much of P2P traffic being (how shall I put this...) less than legal, it's of questionable legality and the ISPs would not want to be held liable for the content cached there? M From jlewis at lewis.org Sat Sep 25 20:56:21 2010 From: jlewis at lewis.org (Jon Lewis) Date: Sat, 25 Sep 2010 16:56:21 -0400 (EDT) Subject: Online games stealing your bandwidth In-Reply-To: References: Message-ID: On Sat, 25 Sep 2010, Rodrick Brown wrote: > If you follow the links in the article people are complaining that the LotR > process has served 70gb in a week, others are complaining that the service > is resulting in 300ms pings, and unusable connections. > This is a very grey area it will be interesting how this issue unfolds in > the long run. I haven't played any of these things, so I don't know what they put in the fine print, but unless LotR makes it clear that they're going to utilize your (i.e. players of the game) bandwidth to PTP distribute their software, I'd call that theft and unauthorized use of a computer network. Are these companies not making enough in monthly subscriptions to afford Akamai or similar CDN services to distribute their software updates? ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From harry.nanog at harry.lu Sat Sep 25 21:03:43 2010 From: harry.nanog at harry.lu (Harry Strongburg) Date: Sat, 25 Sep 2010 21:03:43 +0000 Subject: Online games stealing your bandwidth In-Reply-To: References: Message-ID: <20100925210343.GA27248@harry.lu> On Sat, Sep 25, 2010 at 04:16:46PM -0400, Rodrick Brown wrote: > I think most people are aware that the Blizzard "World of WarcCraft" patcher > distributes files through Bittorrent I personally love Bittorrent. It is wonderful for CDN - for both legal and not-so-legal files. I however despise the game-loaders not giving you more options to control this traffic. For example, many run as a daemon that does not stop seeding - even when you're in-game. You could manually kill it, but it will re-run again. If you remove it, enjoy not being able to continue to play the game if it updates. "Pando Media Booster" (which I have had to deal with), detects your upload speed and uses about 3/4ths of it. The game installer never even had you accept an EULA - just when PMB.exe started when it was installed, it says on the bottom "you have accepted the EULA". EULAs don't really mean much now of days, sadly. This ruins the network quality, especially on large LANs, and most people don't even realize it's using all their connection. My personal verdict on it is: Give the users the option to limit the upload speed to whatever they want, and an option to disable it when they don't need to download any updates; if this is done, I personally see no problem with it. If this option is not added, I see it as malware that should be deleted. As I said above, I have no problems with using Bittorrent as a method of CDN - it's actually one of the best methods. But, the end-users need more control over it. From harry.nanog at harry.lu Sat Sep 25 21:05:24 2010 From: harry.nanog at harry.lu (Harry Strongburg) Date: Sat, 25 Sep 2010 21:05:24 +0000 Subject: Online games stealing your bandwidth In-Reply-To: References: Message-ID: <20100925210524.GB27248@harry.lu> On Sat, Sep 25, 2010 at 04:56:21PM -0400, Jon Lewis wrote: > Are these companies not making enough in monthly subscriptions to > afford Akamai or similar CDN services to distribute their software > updates? If you read the article, you will see that Akami is one of the perpetrators, via the "Akamai NetSession Interface". :) From Valdis.Kletnieks at vt.edu Sat Sep 25 21:53:00 2010 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Sat, 25 Sep 2010 17:53:00 -0400 Subject: Online games stealing your bandwidth In-Reply-To: Your message of "Sat, 25 Sep 2010 21:43:25 BST." References: Message-ID: <96428.1285451580@localhost> On Sat, 25 Sep 2010 21:43:25 BST, Matthew Walster said: > Was anything ever standardised in that field? I imagine with much of > P2P traffic being (how shall I put this...) less than legal, it's of > questionable legality and the ISPs would not want to be held liable > for the content cached there? The ISP is off the hook on that one. 17 USC 512(2) specifically carves out an ISP safe-harbor for data that's only cached on an ISP's servers due to an end user's request. IANAL, so have somebody you pay for legal advice read 17 USC 512(2) and tell you what they think. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From khatfield at socllc.net Sat Sep 25 21:56:15 2010 From: khatfield at socllc.net (khatfield at socllc.net) Date: Sat, 25 Sep 2010 21:56:15 +0000 Subject: Online games stealing your bandwidth In-Reply-To: <20100925210343.GA27248@harry.lu> References: <20100925210343.GA27248@harry.lu> Message-ID: <821631489-1285451776-cardhu_decombobulator_blackberry.rim.net-1944657469-@bda903.bisx.prod.on.blackberry> Speaking to your example with Blizzard: The Blizzard downloader does provide an option to disable P2P transfers which then downloads direct via http from Blizzard. Yes, the update software defaults to allow P2P but it isn't like they are forcing it upon their users. I have seen Sony do the same thing and have never seen a downloader that you couldn't disable that option if you like. -Kevin -----Original Message----- From: Harry Strongburg Date: Sat, 25 Sep 2010 21:03:43 To: Subject: Re: Online games stealing your bandwidth On Sat, Sep 25, 2010 at 04:16:46PM -0400, Rodrick Brown wrote: > I think most people are aware that the Blizzard "World of WarcCraft" patcher > distributes files through Bittorrent I personally love Bittorrent. It is wonderful for CDN - for both legal and not-so-legal files. I however despise the game-loaders not giving you more options to control this traffic. For example, many run as a daemon that does not stop seeding - even when you're in-game. You could manually kill it, but it will re-run again. If you remove it, enjoy not being able to continue to play the game if it updates. "Pando Media Booster" (which I have had to deal with), detects your upload speed and uses about 3/4ths of it. The game installer never even had you accept an EULA - just when PMB.exe started when it was installed, it says on the bottom "you have accepted the EULA". EULAs don't really mean much now of days, sadly. This ruins the network quality, especially on large LANs, and most people don't even realize it's using all their connection. My personal verdict on it is: Give the users the option to limit the upload speed to whatever they want, and an option to disable it when they don't need to download any updates; if this is done, I personally see no problem with it. If this option is not added, I see it as malware that should be deleted. As I said above, I have no problems with using Bittorrent as a method of CDN - it's actually one of the best methods. But, the end-users need more control over it. From jeroen at unfix.org Sat Sep 25 22:01:38 2010 From: jeroen at unfix.org (Jeroen Massar) Date: Sun, 26 Sep 2010 00:01:38 +0200 Subject: Online games stealing your bandwidth In-Reply-To: <96428.1285451580@localhost> References: <96428.1285451580@localhost> Message-ID: <4C9E7142.5040305@unfix.org> On 2010-09-25 23:53, Valdis.Kletnieks at vt.edu wrote: > On Sat, 25 Sep 2010 21:43:25 BST, Matthew Walster said: > >> Was anything ever standardised in that field? I imagine with much of >> P2P traffic being (how shall I put this...) less than legal, it's of >> questionable legality and the ISPs would not want to be held liable >> for the content cached there? > > The ISP is off the hook on that one. 17 USC 512(2) specifically carves out an ISP > safe-harbor for data that's only cached on an ISP's servers due to an end > user's request. IANAL, so have somebody you pay for legal advice read 17 USC 512(2) > and tell you what they think. So it that is true, if you define "news server" as a "cache", even though you have to buy several terabytes, make that several petabytes, to "be able to "cache" this data one along with all the network environment to support getting data out of this "cache", the ISP is completely in the clear even though that "cache" is the sole single point where one can retrieve that "cached" data from even years after the data was originally put on the network, the original is gone and that "cache" works without anything being attached to it ? :) Oh, one just have to love these things called laws... good that they are protecting the right parts of the distribution network eh ;) Greets, Jeroen From harry.nanog at harry.lu Sat Sep 25 22:37:25 2010 From: harry.nanog at harry.lu (Harry Strongburg) Date: Sat, 25 Sep 2010 22:37:25 +0000 Subject: Online games stealing your bandwidth In-Reply-To: <821631489-1285451776-cardhu_decombobulator_blackberry.rim.net-1944657469-@bda903.bisx.prod.on.blackberry> References: <20100925210343.GA27248@harry.lu> <821631489-1285451776-cardhu_decombobulator_blackberry.rim.net-1944657469-@bda903.bisx.prod.on.blackberry> Message-ID: <20100925223725.GA31295@harry.lu> On Sat, Sep 25, 2010 at 09:56:15PM +0000, khatfield at socllc.net wrote: > Speaking to your example with Blizzard: It was not my example, I do not play Blizzard games. > The Blizzard downloader does provide an option to disable P2P > transfers which then downloads direct via http from Blizzard. This is nice. Many other games using Pando and other such P2P downloaders do not. > Yes, the update software defaults to allow P2P but it isn't like they > are forcing it upon their users. I have seen Sony do the same thing > and have never seen a downloader that you couldn't disable that option > if you like. I am 100% sure "Pando Media Booster" do not give you the option of disabling it. Unless they hide it very, very deep. From bonomi at mail.r-bonomi.com Sat Sep 25 22:41:16 2010 From: bonomi at mail.r-bonomi.com (Robert Bonomi) Date: Sat, 25 Sep 2010 17:41:16 -0500 (CDT) Subject: Online games stealing your bandwidth Message-ID: <201009252241.o8PMfGQu028466@mail.r-bonomi.com> > From nanog-bounces+bonomi=mail.r-bonomi.com at nanog.org Sat Sep 25 17:00:42 2010 > Date: Sun, 26 Sep 2010 00:01:38 +0200 > From: Jeroen Massar > To: Valdis.Kletnieks at vt.edu > Subject: Re: Online games stealing your bandwidth > Cc: NANOG > > On 2010-09-25 23:53, Valdis.Kletnieks at vt.edu wrote: > > On Sat, 25 Sep 2010 21:43:25 BST, Matthew Walster said: > > > >> Was anything ever standardised in that field? I imagine with much of > >> P2P traffic being (how shall I put this...) less than legal, it's of > >> questionable legality and the ISPs would not want to be held liable > >> for the content cached there? > > > > The ISP is off the hook on that one. 17 USC 512(2) specifically carves out an ISP > > safe-harbor for data that's only cached on an ISP's servers due to an end > > user's request. IANAL, so have somebody you pay for legal advice read 17 USC 512(2) > > and tell you what they think. > > So it that is true, if you define "news server" as a "cache", even > though you have to buy several terabytes, make that several petabytes, > to "be able to "cache" this data one along with all the network > environment to support getting data out of this "cache", the ISP is > completely in the clear even though that "cache" is the sole single > point where one can retrieve that "cached" data from even years after > the data was originally put on the network, the original is gone and > that "cache" works without anything being attached to it ? :) There is existant _recent case law, specifically with regard to operating a newsserver, that holds otherwise. Of course the server operator was blatently _advertizing_ the copyright-infringing (and more) nature of their content. Several of the major ISPs who recently discontinued providing USENET did so as a direct result of the above-mentioned case -- attorney-generals were 'making noises' -- and the ISP chose not to risk a confrontation. From young at jsyoung.net Sat Sep 25 23:35:37 2010 From: young at jsyoung.net (Jeffrey S. Young) Date: Sun, 26 Sep 2010 09:35:37 +1000 Subject: Online games stealing your bandwidth In-Reply-To: References: Message-ID: t On 26/09/2010, at 6:43 AM, Matthew Walster wrote: > On 25 September 2010 21:16, Rodrick Brown wrote: >> I think most people are aware that the Blizzard "World of WarcCraft" patcher >> distributes files through Bittorrent, > > > > I once read an article talking about making BitTorrent scalable by > using anycasted caching services at the ISP's closest POP to the end > user. Given sufficient traffic on a specified torrent, the caching > device would build up the file, then distribute that direct to the > subscriber in the form of an additional (preferred) peer. Similar to a > CDN or Usenet, but where it was cached rather than deliberately pushed > out from a locus. > > Was anything ever standardised in that field? I imagine with much of > P2P traffic being (how shall I put this...) less than legal, it's of > questionable legality and the ISPs would not want to be held liable > for the content cached there? > > M > > IMHO, Sooner or later our community will catch on and begin to deploy such technology. P2P is a really elegant 'tool' when used to distribute large files (which we all know). I expect that even the biggest last-mile providers will lose the arms race they currently engage in against this 'tool' and start participating in and controlling the flow of data. Throwing millions into technologies to thwart this 'tool,' technologies such as DPI only takes away from a last-mile provider's ability to offer service. I believe this is one reason the USA lags the Rest of the World in broadband deployment. Ultimately, I believe it will make sense to design last-mile networks to benefit from P2P (e.g. allow end stations to communicate locally rather than force traffic that could stay local to a central office through a session- based router). Then take advantage by deploying a scenario such as the one you've outlined to keep swarms local. Before we do that though, we need to cut the paranoia about this particular tool (created by the RIAA and others) and we need to see a few more exec's with vision. jy From adrian at creative.net.au Sat Sep 25 23:47:34 2010 From: adrian at creative.net.au (Adrian Chadd) Date: Sun, 26 Sep 2010 07:47:34 +0800 Subject: Online games stealing your bandwidth In-Reply-To: References: Message-ID: <20100925234734.GA19927@skywalker.creative.net.au> On Sat, Sep 25, 2010, Matthew Walster wrote: > I once read an article talking about making BitTorrent scalable by > using anycasted caching services at the ISP's closest POP to the end > user. Given sufficient traffic on a specified torrent, the caching > device would build up the file, then distribute that direct to the > subscriber in the form of an additional (preferred) peer. Similar to a > CDN or Usenet, but where it was cached rather than deliberately pushed > out from a locus. > > Was anything ever standardised in that field? I imagine with much of > P2P traffic being (how shall I put this...) less than legal, it's of > questionable legality and the ISPs would not want to be held liable > for the content cached there? I don't recall any protocols being standard. Plenty of people sell p2p caches but they all work using magic, smoke and mirrors. Adrian -- - Xenion - http://www.xenion.com.au/ - VPS Hosting - Commercial Squid Support - - $24/pm+GST entry-level VPSes w/ capped bandwidth charges available in WA - From matthew at walster.org Sun Sep 26 00:17:59 2010 From: matthew at walster.org (Matthew Walster) Date: Sun, 26 Sep 2010 01:17:59 +0100 Subject: Online games stealing your bandwidth In-Reply-To: <20100925234734.GA19927@skywalker.creative.net.au> References: <20100925234734.GA19927@skywalker.creative.net.au> Message-ID: On 26 September 2010 00:47, Adrian Chadd wrote: > I don't recall any protocols being standard. > > Plenty of people sell p2p caches but they all work using magic, smoke > and mirrors. I had the P4P (http://en.wikipedia.org/wiki/Proactive_network_Provider_Participation_for_P2P) pointed out to me - but like you said, it's hardly going to be an open standard if it gets anywhere. M From jeff-kell at utc.edu Sun Sep 26 01:32:15 2010 From: jeff-kell at utc.edu (Jeff Kell) Date: Sat, 25 Sep 2010 21:32:15 -0400 Subject: Online games stealing your bandwidth In-Reply-To: References: Message-ID: <4C9EA29F.5080301@utc.edu> Games? Yes a few, but... Ever seen Skype on an open, non-NAT'ed internet connection? Capture some netflow on a self-promoted supernode sometime. Or seen Octoshape in action? Jeff From fedorafans at gmail.com Sun Sep 26 02:57:53 2010 From: fedorafans at gmail.com (fedora fedora) Date: Sat, 25 Sep 2010 21:57:53 -0500 Subject: large icmp packet issue Message-ID: I am having problem getting ping to work to a specific destination host when using large size icmp packet and i am hoping someone here can offer some suggestion. With regular ping, i can ping this remote host without any problem, but if i crank up the packet size to above 1500 (1500 still works), i won't get any icmp reply. My first thought was this was a pmtu issue. but when I ran tcpdump on this remote host, i saw the incoming ping requests and this host actually sent back icmp replies, so it appears that there is some device in between blocking these large size icmp reply packets. Here is the question, how can i find out which hop on the path is causing this behavior? FD From bonomi at mail.r-bonomi.com Sun Sep 26 03:18:07 2010 From: bonomi at mail.r-bonomi.com (Robert Bonomi) Date: Sat, 25 Sep 2010 22:18:07 -0500 (CDT) Subject: large icmp packet issue Message-ID: <201009260318.o8Q3I7Cb029792@mail.r-bonomi.com> > From nanog-bounces+bonomi=mail.r-bonomi.com at nanog.org Sat Sep 25 21:56:30 2010 > Date: Sat, 25 Sep 2010 21:57:53 -0500 > Subject: large icmp packet issue > From: fedora fedora > To: nanog at nanog.org > > I am having problem getting ping to work to a specific destination host when > using large size icmp packet and i am hoping someone here can offer some > suggestion. > > With regular ping, i can ping this remote host without any problem, but if i > crank up the packet size to above 1500 (1500 still works), i won't get any > icmp reply. > > My first thought was this was a pmtu issue. but when I ran tcpdump on this > remote host, i saw the incoming ping requests and this host actually sent > back icmp replies, so it appears that there is some device in between > blocking these large size icmp reply packets. > > Here is the question, how can i find out which hop on the path is causing > this behavior? Did you consider doing a traceroute? And then pinging the intermediate machines? with the big packets, that is. you'll get a response from the 'near side' of the problem, but -not- from any machine on the far side of it. Ping with small packets first, to discovr machines that dont respond to pings at all. From fedorafans at gmail.com Sun Sep 26 03:33:31 2010 From: fedorafans at gmail.com (fedora fedora) Date: Sat, 25 Sep 2010 22:33:31 -0500 Subject: large icmp packet issue In-Reply-To: <201009260318.o8Q3I7Cb029792@mail.r-bonomi.com> References: <201009260318.o8Q3I7Cb029792@mail.r-bonomi.com> Message-ID: Thanks, the thing is How can i be sure even if a device blocks my ping , it might have policy blocking ping at it at all. On Sat, Sep 25, 2010 at 10:18 PM, Robert Bonomi wrote: > > From nanog-bounces+bonomi=mail.r-bonomi.com at nanog.org Sat Sep 25 > 21:56:30 2010 > > Date: Sat, 25 Sep 2010 21:57:53 -0500 > > Subject: large icmp packet issue > > From: fedora fedora > > To: nanog at nanog.org > > > > I am having problem getting ping to work to a specific destination host > when > > using large size icmp packet and i am hoping someone here can offer some > > suggestion. > > > > With regular ping, i can ping this remote host without any problem, but > if i > > crank up the packet size to above 1500 (1500 still works), i won't get > any > > icmp reply. > > > > My first thought was this was a pmtu issue. but when I ran tcpdump on > this > > remote host, i saw the incoming ping requests and this host actually sent > > back icmp replies, so it appears that there is some device in between > > blocking these large size icmp reply packets. > > > > Here is the question, how can i find out which hop on the path is causing > > this behavior? > > Did you consider doing a traceroute? > > And then pinging the intermediate machines? with the big packets, that is. > > you'll get a response from the 'near side' of the problem, but -not- > from any machine on the far side of it. > > Ping with small packets first, to discovr machines that dont respond to > pings at all. > > From gordslater at ieee.org Sun Sep 26 07:50:27 2010 From: gordslater at ieee.org (gordon b slater) Date: Sun, 26 Sep 2010 08:50:27 +0100 Subject: Online games stealing your bandwidth In-Reply-To: <20100925234734.GA19927@skywalker.creative.net.au> References: <20100925234734.GA19927@skywalker.creative.net.au> Message-ID: <1285487427.4495.43.camel@ub-g-d2> On Sun, 2010-09-26 at 07:47 +0800, Adrian Chadd wrote: > I don't recall any protocols being standard. > > Plenty of people sell p2p caches but they all work using magic, smoke > and mirrors. > > > Adrian Less smoky is the relatively common practice (at least in Europe) of tech-friendly ISPs running bittorrent for "release days" of Linux and BSD distros; Ubuntu releases especially because they have a large proportion of release-day installs (!) and the servers get hit hard. How much of this is just staff doing their customers a favor is debateable, but I know two places where it's written into SOPs for Debian and FreeBSD major releases (about a week or two after the release). Linux distribution by bittorrent is sometimes harder now that more Tier 1 ISPs block or inspect the P2P traffic By a bit of quick fiddling you can ensure that users outside your blocks don't get served. I'm talking installation ISOs, not the ports or packages - the rsyncs and mirrors take care of that as normal. For the Debian 5.05 release I provided 700GB+ in a week for the x86 Gnome CD alone via BT, the AMD64 CD was about twice that, yet most of the Debian stuff will be done using Jigdo, so that's a fraction of the actual traffic. The Debian Netboot CD's seem quite popular too but especially for exotic hardware archs. The 5.06 release is still flowing nicely. The last few FreeBSD releases I've pushed 500GB each time though I hold them open for much longer for the less popular architectures. The thought of it all flying round in such long circles dismays me somewhat. There's probably an reasonable argument for temporary ISP-BT of this stuff, as it'll save us all a tiny bit of peak and a lot of packets, all for very little kit, space and man-hours. The rest of the torrent users, (games or copytheft), can surely be /dev/null-ed ? :) Hmm, can I smell burning torches in the distance? Gord -- # Hahaha, hehehe, I'm a little Gnome and I hate KDE From nccariaga at stluke.com.ph Sun Sep 26 09:41:40 2010 From: nccariaga at stluke.com.ph (Nathanael C. Cariaga) Date: Sun, 26 Sep 2010 17:41:40 +0800 (PHT) Subject: Software-based Border Router In-Reply-To: <1981894704.6437.1285493639414.JavaMail.root@mailserver> Message-ID: <553474862.6446.1285494100818.JavaMail.root@mailserver> Hi All! Just want to ask if anyone here had experience deploying software-based routers to serve as perimeter / border router? How does it gauge with hardware-based routers? Any past experiences will be very much appreciated. I wanted to know because we've been asked if we want to assume full control of the internet link (up to the router). By assuming control up to the router, we still want to configure iBGP with our parent network so that we can take advantage of some routes available to the parent network's gateway. The saddest part is presently we do not have the router to serve as our gateway this is why we are considering the use of software-based routers. Thank you. From sthaug at nethelp.no Sun Sep 26 09:59:21 2010 From: sthaug at nethelp.no (sthaug at nethelp.no) Date: Sun, 26 Sep 2010 11:59:21 +0200 (CEST) Subject: Software-based Border Router In-Reply-To: <553474862.6446.1285494100818.JavaMail.root@mailserver> References: <1981894704.6437.1285493639414.JavaMail.root@mailserver> <553474862.6446.1285494100818.JavaMail.root@mailserver> Message-ID: <20100926.115921.74701327.sthaug@nethelp.no> > Just want to ask if anyone here had experience deploying software-based routers to serve as perimeter / border router? How does it gauge with hardware-based routers? Any past experiences will be very much appreciated. Software based routers (e.g. Cisco 7200 series) have been used as border routers for many years - this is hardly anything new. The question you should ask is probably: Can such a router handle a full link's worth of DDoS using minimum sized packets? The answer, of course, depends on your link capacity, the router itself, features enabled (ACLs, QoS, ...) etc. There are quite a few people using Quagga based boxes running Linux or FreeBSD as border routers - this is a possible solution too, giving you more bang for the buck than a traditional software based router from the big vendors. Make sure you have enough expertise for the relevant OS and routing software available. Steinar Haug, Nethelp consulting, sthaug at nethelp.no From nccariaga at stluke.com.ph Sun Sep 26 10:15:20 2010 From: nccariaga at stluke.com.ph (Nathanael C. Cariaga) Date: Sun, 26 Sep 2010 18:15:20 +0800 (PHT) Subject: Software-based Border Router In-Reply-To: <20100926.115921.74701327.sthaug@nethelp.no> Message-ID: <221425418.6450.1285496120772.JavaMail.root@mailserver> Thank you for the prompt response. Just to clarify my previous post, I was actually referring to Linux/Unix-based routers. We've been considering this solution because presently we don't have any budget for equipment acquisition this year. To be honest, I came across Vyatta Core while searching for viable Linux/Unix-based solution that we can adopt and I'm currently reading its reference guides. Has anyone here used this software before? Thanks a lot. ----- Original Message ----- From: sthaug at nethelp.no To: nccariaga at stluke.com.ph Cc: nanog at nanog.org Sent: Sunday, September 26, 2010 5:59:21 PM Subject: Re: Software-based Border Router > Just want to ask if anyone here had experience deploying software-based routers to serve as perimeter / border router? How does it gauge with hardware-based routers? Any past experiences will be very much appreciated. Software based routers (e.g. Cisco 7200 series) have been used as border routers for many years - this is hardly anything new. The question you should ask is probably: Can such a router handle a full link's worth of DDoS using minimum sized packets? The answer, of course, depends on your link capacity, the router itself, features enabled (ACLs, QoS, ...) etc. There are quite a few people using Quagga based boxes running Linux or FreeBSD as border routers - this is a possible solution too, giving you more bang for the buck than a traditional software based router from the big vendors. Make sure you have enough expertise for the relevant OS and routing software available. Steinar Haug, Nethelp consulting, sthaug at nethelp.no From hj1980 at gmail.com Sun Sep 26 11:49:21 2010 From: hj1980 at gmail.com (Heath Jones) Date: Sun, 26 Sep 2010 12:49:21 +0100 Subject: large icmp packet issue In-Reply-To: References: <201009260318.o8Q3I7Cb029792@mail.r-bonomi.com> Message-ID: > How can i be sure even if a device blocks my ping , it might have policy > blocking ping at it at all. Correct in a lot of cases and that is why icmp should not be used by itself when diagnosing issues. >> I am having problem getting ping to work to a specific destination host when >> using large size icmp packet and i am hoping someone here can offer some >> suggestion. With regular ping, i can ping this remote host without any problem, >> but if i crank up the packet size to above 1500 (1500 still works), i won't get any icmp reply. >> My first thought was this was a pmtu issue. but when I ran tcpdump on this remote host, >> i saw the incoming ping requests and this host actually sent back icmp replies, so it appears >> that there is some device in between blocking these large size icmp reply packets. It is possible that the MTU for interface facing you and interface facing away from you are different on some middle hop. It is interesting that you state the packet size to be >1500, are you talking about jumbo frames? (and do you mean frame size, not packet size?) >> Here is the question, how can i find out which hop on the path is causing this behavior? Robert is correct. You need to use traceroute, or alter the TTL values when you send the icmp requests. By setting dont-fragment and varying ttl & frame sizes, you should find your issue. From Valdis.Kletnieks at vt.edu Sun Sep 26 13:24:30 2010 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Sun, 26 Sep 2010 09:24:30 -0400 Subject: Online games stealing your bandwidth In-Reply-To: Your message of "Sat, 25 Sep 2010 17:41:16 CDT." <201009252241.o8PMfGQu028466@mail.r-bonomi.com> References: <201009252241.o8PMfGQu028466@mail.r-bonomi.com> Message-ID: <164832.1285507470@localhost> On Sat, 25 Sep 2010 17:41:16 CDT, Robert Bonomi said: > On Sun, 26 Sep 2010 00:01:38 , Jeroen Massar said: > > So it that is true, if you define "news server" as a "cache", even > > though you have to buy several terabytes, make that several petabytes, > > to "be able to "cache" this data one along with all the network > > environment to support getting data out of this "cache", the ISP is > > completely in the clear even though that "cache" is the sole single > > point where one can retrieve that "cached" data from even years after > > the data was originally put on the network, the original is gone and > > that "cache" works without anything being attached to it ? :) "sole single point" is a sticking point, since at that point you've crossed over from "cache" to "archive" - see below. > There is existant _recent case law, specifically with regard to operating > a newsserver, that holds otherwise. Of course the server operator was > blatently _advertizing_ the copyright-infringing (and more) nature of > their content. Haven't read that case law yes, but I'm willing to guess the operator of the newsserver was running it in violation of 17 USC 512 (b)(2)(E)(i) - which basically says you need to respond to takedown requests if the upstream copy has already been removed (which will often be the case with netnews). So if you're the sole single point caching something that's now gone from upstream, you have a problem (and a stale cache). But of course, we all run technically competent caches that expire stuff when it goes stale (unless your business model includes advertising you have a stale cache)... The *real* fun for Bittorrent is (b)(2)(E)(ii): "The party giving the notification includes in the notification a statement confirming that the material has been removed from the originating site or access to it has been disabled or that a court has ordered that the material be removed from the originating site or that access to the material on the originating site be disabled." - which could be difficult to do when the material has been assembled block-by-block from dozens of other sources and few records kept of the actual provenance of any given block. They might have to resort to finding a helpful judge willing to sign a "John Doe" order for each takedown. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From ml at kenweb.org Sun Sep 26 14:49:48 2010 From: ml at kenweb.org (ML) Date: Sun, 26 Sep 2010 10:49:48 -0400 Subject: large icmp packet issue In-Reply-To: References: Message-ID: <4C9F5D8C.6030307@kenweb.org> On 9/25/2010 10:57 PM, fedora fedora wrote: > I am having problem getting ping to work to a specific destination host when > using large size icmp packet and i am hoping someone here can offer some > suggestion. > > With regular ping, i can ping this remote host without any problem, but if i > crank up the packet size to above 1500 (1500 still works), i won't get any > icmp reply. > > My first thought was this was a pmtu issue. but when I ran tcpdump on this > remote host, i saw the incoming ping requests and this host actually sent > back icmp replies, so it appears that there is some device in between > blocking these large size icmp reply packets. > > Here is the question, how can i find out which hop on the path is causing > this behavior? > > FD Can you provide a pcap file? From if at xip.at Sun Sep 26 15:09:06 2010 From: if at xip.at (Ingo Flaschberger) Date: Sun, 26 Sep 2010 17:09:06 +0200 (CEST) Subject: Software-based Border Router In-Reply-To: <553474862.6446.1285494100818.JavaMail.root@mailserver> References: <553474862.6446.1285494100818.JavaMail.root@mailserver> Message-ID: Dear Nathanael, > Just want to ask if anyone here had experience deploying software-based > routers to serve as perimeter / border router? How does it gauge with > hardware-based routers? Any past experiences will be very much > appreciated. > I wanted to know because we've been asked if we want to assume full > control of the internet link (up to the router). By assuming control up > to the router, we still want to configure iBGP with our parent network > so that we can take advantage of some routes available to the parent > network's gateway. The saddest part is presently we do not have the > router to serve as our gateway this is why we are considering the use of > software-based routers. I operate freebsd / quagga core routers since 4 years. pro: cheap, tcpdump at router con: no support, no wirespeed expected performance: 100kpps (1,2ghz pentium m) - 700kpps (quad intel core 2, 3ghz) - and much more with 10gige cards issues: 4byte asn produced a crash at quagga (downtime 2h in 4 years) to develop a good core-router, this means not only to setup a pc with unix and for example quagga, but setup an embedded unix to an appliance, for example with cf-cards (readonly). Kind regards, Ingo Flaschberger From dmburgess at linktechs.net Sun Sep 26 15:10:53 2010 From: dmburgess at linktechs.net (Dennis Burgess) Date: Sun, 26 Sep 2010 10:10:53 -0500 Subject: Software-based Border Router References: <221425418.6450.1285496120772.JavaMail.root@mailserver> Message-ID: <91522911795E174F97E7EF8B792A1031315247@ltiserver.LTI.local> While Vyatta is a good piece of software for the Free version, the costs quickly increases as you have to purchase support and the version updates are few and far between with the Free version. The production (paid) version though is quite nice. Another option though would be RouterOS. If it is a small site, doing BGP could be as little as $399 including the hardware! However, most people that do BGP will need a bit more horsepower. RouterOS will do your iBGP, OSPF, bandwidth controls, firewalling etc. The software license there is $45 beans! Super cheap. Hardware runs as low as $49 bucks to 10k depending on what you are needing. If you would like, please feel free to contact me off-list and I will be glad to recommend the proper hardware. ----------------------------------------------------------- Dennis Burgess, CCNA, A+, Mikrotik Certified Trainer Link Technologies, Inc -- Mikrotik & WISP Support Services Office: 314-735-0270 Website: http://www.linktechs.net LIVE On-Line Mikrotik Training - Author of "Learn RouterOS" -----Original Message----- From: Nathanael C. Cariaga [mailto:nccariaga at stluke.com.ph] Sent: Sunday, September 26, 2010 5:15 AM To: sthaug at nethelp.no Cc: nanog at nanog.org Subject: Re: Software-based Border Router Thank you for the prompt response. Just to clarify my previous post, I was actually referring to Linux/Unix-based routers. We've been considering this solution because presently we don't have any budget for equipment acquisition this year. To be honest, I came across Vyatta Core while searching for viable Linux/Unix-based solution that we can adopt and I'm currently reading its reference guides. Has anyone here used this software before? Thanks a lot. ----- Original Message ----- From: sthaug at nethelp.no To: nccariaga at stluke.com.ph Cc: nanog at nanog.org Sent: Sunday, September 26, 2010 5:59:21 PM Subject: Re: Software-based Border Router > Just want to ask if anyone here had experience deploying software-based routers to serve as perimeter / border router? How does it gauge with hardware-based routers? Any past experiences will be very much appreciated. Software based routers (e.g. Cisco 7200 series) have been used as border routers for many years - this is hardly anything new. The question you should ask is probably: Can such a router handle a full link's worth of DDoS using minimum sized packets? The answer, of course, depends on your link capacity, the router itself, features enabled (ACLs, QoS, ...) etc. There are quite a few people using Quagga based boxes running Linux or FreeBSD as border routers - this is a possible solution too, giving you more bang for the buck than a traditional software based router from the big vendors. Make sure you have enough expertise for the relevant OS and routing software available. Steinar Haug, Nethelp consulting, sthaug at nethelp.no From cmadams at hiwaay.net Sun Sep 26 15:26:59 2010 From: cmadams at hiwaay.net (Chris Adams) Date: Sun, 26 Sep 2010 10:26:59 -0500 Subject: Routers in Data Centers In-Reply-To: <556A0EF3-0038-4DD1-B752-FE272F2EB0DF@bogus.com> References: <4C9E1DC9.1010809@rollernet.us> <556A0EF3-0038-4DD1-B752-FE272F2EB0DF@bogus.com> Message-ID: <20100926152659.GA8790@hiwaay.net> Once upon a time, Joel Jaeggli said: > On Sep 25, 2010, at 9:05, Seth Mattinen wrote: > >>> From the datacenter operator prospective, it would be nice if some of these vendors would acknowledge the need for front-to-back cooling. I mean, it is 2010. > > Bakplanes make direct front to back cooling hard. non-modular platforms can do it just fine however. There are servers and storage arrays that have a front that is nothing but hot-swap hard drive bays (plugged into backplanes), and they've been doing front-to-back cooling since day one. Maybe the router vendors need to buy a Dell, open the case, and take a look. The server vendors also somehow manage to make an empty case that costs less than $10,000 (they'll even fill it up with useful stuff for less than that). -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From kotikalapudi.sriram at nist.gov Sun Sep 26 16:46:55 2010 From: kotikalapudi.sriram at nist.gov (Sriram, Kotikalapudi) Date: Sun, 26 Sep 2010 12:46:55 -0400 Subject: Odd BGP AS Path In-Reply-To: References: Message-ID: We (at NIST) performed some additional data analysis to characterize AS_SETs in BGP updates in RIB entries. The results can be found in the slides at this link: http://www.antd.nist.gov/~ksriram/AS_SET_Aggregator_Stats.pdf This work was presented at the IETF SIDR WG meeting in Maastricht in July 2010. Please look at mainly slides #3 and #4. The findings are consistent with Olaf Maennel's (that Randy posted) in term of how few updates have AS_SETs in them. We additionally looked at the the question of -- when AS_SET is present, how often does the ASN in the AGGRGATOR field in the update matches the originating AS? This question has relevance to origin AS validation using ROAs in RPKI -- to try to propose how origin validation can be done if AS_SET is present in an update. Please look into my slides if you are interested in the details. I will be happy to answer any questions. Currently, the push from several of us (Warren Kumari, Randy, many others -- I support it too) is to deprecate AS_SETs altogether in future BGP enhancements such as RPKI. This would mean an update will not pass origin validation (in fact, origin validation using ROAs will not even be attempted) if AS_SET is present in an update. Comments/reaction/feedback to this from ops people who currently use AS_SETs would be very useful. (This would be good for discussion of Warren's draft in the IDR WG. http://tools.ietf.org/html/draft-wkumari-deprecate-as-sets-00 ) Sriram ==================================================== >Date: Thu, 23 Sep 2010 10:59:07 -0400 >From: Randy Bush >Subject: Re: Odd BGP AS Path >To: Warren Kumari >Cc: nanog at nanog.org > >just to uncloak a bit. when we first decided to look at deprecating >as-sets et alia, we begged olaf maennel to analyse the use thereof. the >following is edited from internal email from early august. we then >begged one of our number, warren, to do the dirty, and he was kind >enough to do so. we owe him. > >--- > >using data from ripe r00 >years total real >stable as-sets as-sets > 7 4 2 > 6 6 2 > 5 20 3 > 4 22 5 > 3 64 16 > 2 214 87 > 1 875 289 > > years stable is how many years that as-set was announced for that > prefix. > > total as-sets is the number of prefixes that had any as-set. > >real as-sets is the number of prefixes with as-sets which were not >singleton asns and were not private asns. > >olaf scanned for ten years but none were stable for more than seven. > >in ten years, 1205 different prefixes with as-sets were seen. removing >private asns and removing singletons left only 404 prefixes over the ten >years. > >he did not check for covering prefixes, i.e. two prefixes with the same >as-set where one was a sub-prefix of the other, longer, one. > >and i suspect the data are somewhat self-similar. i.e. the 289 that >were stable for the last year may have shorter term components which >were much higher. i.e. looking at data for a week or a day may give >higher values. > >a graph which should be pretty self-explanitory may be found at > > http://archive.psg.com/fraction-and-absolute-number-of-ASsets-in-table-over-time-valids-only.pdf > >it is interesting that, at no time, i.e. in no single rib dump, were >there more than 23 prefixes with as-sets. while this is suspicious, it >seems to be true. > >randy From joelja at bogus.com Sun Sep 26 17:03:53 2010 From: joelja at bogus.com (Joel Jaeggli) Date: Sun, 26 Sep 2010 10:03:53 -0700 Subject: Software-based Border Router In-Reply-To: <553474862.6446.1285494100818.JavaMail.root@mailserver> References: <553474862.6446.1285494100818.JavaMail.root@mailserver> Message-ID: <42188761-A52E-45F6-BDA0-38280120BBD5@bogus.com> If one has a cisco 7200, then you have a software based border router. Considerations, for a given router platform are capacity, susceptability to dos, features required etc. Depending on the capacity required a software device could do fine. If it's in front of hosting environment you want to know that it doesn't take dirt nap from a couple hundred mb/s of small packet. Joel's widget number 2 On Sep 26, 2010, at 2:41, "Nathanael C. Cariaga" wrote: > Hi All! > > > Just want to ask if anyone here had experience deploying software-based routers to serve as perimeter / border router? How does it gauge with hardware-based routers? Any past experiences will be very much appreciated. > > > I wanted to know because we've been asked if we want to assume full control of the internet link (up to the router). By assuming control up to the router, we still want to configure iBGP with our parent network so that we can take advantage of some routes available to the parent network's gateway. The saddest part is presently we do not have the router to serve as our gateway this is why we are considering the use of software-based routers. > > > Thank you. > From joelja at bogus.com Sun Sep 26 17:17:07 2010 From: joelja at bogus.com (Joel Jaeggli) Date: Sun, 26 Sep 2010 10:17:07 -0700 Subject: Routers in Data Centers In-Reply-To: <20100926152659.GA8790@hiwaay.net> References: <4C9E1DC9.1010809@rollernet.us> <556A0EF3-0038-4DD1-B752-FE272F2EB0DF@bogus.com> <20100926152659.GA8790@hiwaay.net> Message-ID: <7392622F-F7CF-446B-A7AF-E1CD5516039C@bogus.com> On Sep 26, 2010, at 8:26, Chris Adams wrote: > Once upon a time, Joel Jaeggli said: >> On Sep 25, 2010, at 9:05, Seth Mattinen wrote: >>>>> From the datacenter operator prospective, it would be nice if some of these vendors would acknowledge the need for front-to-back cooling. I mean, it is 2010. >> >> Bakplanes make direct front to back cooling hard. non-modular platforms can do it just fine however. > > There are servers and storage arrays that have a front that is nothing > but hot-swap hard drive bays (plugged into backplanes), and they've been > doing front-to-back cooling since day one. Maybe the router vendors > need to buy a Dell, open the case, and take a look. The backplane for a sata disk array is 8 wires per drive plus a common power bus. > > The server vendors also somehow manage to make an empty case that costs > less than $10,000 (they'll even fill it up with useful stuff for less > than that). Unit volume is little higher, and the margins kind of suck. There's a reason why hp would rather sell you a blade server chassis than 16 1us. Equating servers and routers is like equating bouncy castle prices with renting an oil platform. > -- > Chris Adams > Systems and Network Administrator - HiWAAY Internet Services > I don't speak for anybody but myself - that's enough trouble. > From cmadams at hiwaay.net Sun Sep 26 17:47:55 2010 From: cmadams at hiwaay.net (Chris Adams) Date: Sun, 26 Sep 2010 12:47:55 -0500 Subject: Routers in Data Centers In-Reply-To: <7392622F-F7CF-446B-A7AF-E1CD5516039C@bogus.com> References: <4C9E1DC9.1010809@rollernet.us> <556A0EF3-0038-4DD1-B752-FE272F2EB0DF@bogus.com> <20100926152659.GA8790@hiwaay.net> <7392622F-F7CF-446B-A7AF-E1CD5516039C@bogus.com> Message-ID: <20100926174755.GB18648@hiwaay.net> Once upon a time, Joel Jaeggli said: > On Sep 26, 2010, at 8:26, Chris Adams wrote: > > There are servers and storage arrays that have a front that is nothing > > but hot-swap hard drive bays (plugged into backplanes), and they've been > > doing front-to-back cooling since day one. Maybe the router vendors > > need to buy a Dell, open the case, and take a look. > > The backplane for a sata disk array is 8 wires per drive plus a common power bus. Server vendors managed cooling just fine for years with 80 pin SCA connectors. Hard drives are also harder to cool, as they are a solid block, filling the space, unlike a card of chips. I'm not saying the problems are the same, but I am saying that a backplane making cooling "hard" is not a good excuse, especially when the small empty chassis costs $10K+. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From joelja at bogus.com Sun Sep 26 18:09:24 2010 From: joelja at bogus.com (Joel Jaeggli) Date: Sun, 26 Sep 2010 11:09:24 -0700 Subject: Routers in Data Centers In-Reply-To: <20100926174755.GB18648@hiwaay.net> References: <4C9E1DC9.1010809@rollernet.us> <556A0EF3-0038-4DD1-B752-FE272F2EB0DF@bogus.com> <20100926152659.GA8790@hiwaay.net> <7392622F-F7CF-446B-A7AF-E1CD5516039C@bogus.com> <20100926174755.GB18648@hiwaay.net> Message-ID: Joel's widget number 2 On Sep 26, 2010, at 10:47, Chris Adams wrote: > Once upon a time, Joel Jaeggli said: >> On Sep 26, 2010, at 8:26, Chris Adams wrote: >>> There are servers and storage arrays that have a front that is nothing >>> but hot-swap hard drive bays (plugged into backplanes), and they've been >>> doing front-to-back cooling since day one. Maybe the router vendors >>> need to buy a Dell, open the case, and take a look. >> >> The backplane for a sata disk array is 8 wires per drive plus a common power bus. > > Server vendors managed cooling just fine for years with 80 pin SCA > connectors. Hard drives are also harder to cool, as they are a solid > block, filling the space, unlike a card of chips. It's the same 80 wires on every single drive in the string. There are fewer conductors embedded in 12 drive sca backplane as there are in a 12 drive sata backplane, in both cases they are generally two layer pcbs. Compared to what 10+ layer pcbs that are a approaching 1/4" thick on the router. Hard drives are 6-12w each, a processor complex that's north of 200w per card is a rather different cooling exercise. > I'm not saying the problems are the same, but I am saying that a > backplane making cooling "hard" is not a good excuse, especially when > the small empty chassis costs $10K+. > -- > Chris Adams > Systems and Network Administrator - HiWAAY Internet Services > I don't speak for anybody but myself - that's enough trouble. > From sethm at rollernet.us Sun Sep 26 19:17:14 2010 From: sethm at rollernet.us (Seth Mattinen) Date: Sun, 26 Sep 2010 12:17:14 -0700 Subject: Routers in Data Centers In-Reply-To: References: <4C9E1DC9.1010809@rollernet.us> <556A0EF3-0038-4DD1-B752-FE272F2EB0DF@bogus.com> <20100926152659.GA8790@hiwaay.net> <7392622F-F7CF-446B-A7AF-E1CD5516039C@bogus.com> <20100926174755.GB18648@hiwaay.net> Message-ID: <4C9F9C3A.9050506@rollernet.us> On 9/26/10 11:09 AM, Joel Jaeggli wrote: > > > Joel's widget number 2 > > On Sep 26, 2010, at 10:47, Chris Adams wrote: > >> Once upon a time, Joel Jaeggli said: >>> On Sep 26, 2010, at 8:26, Chris Adams wrote: >>>> There are servers and storage arrays that have a front that is nothing >>>> but hot-swap hard drive bays (plugged into backplanes), and they've been >>>> doing front-to-back cooling since day one. Maybe the router vendors >>>> need to buy a Dell, open the case, and take a look. >>> >>> The backplane for a sata disk array is 8 wires per drive plus a common power bus. >> >> Server vendors managed cooling just fine for years with 80 pin SCA >> connectors. Hard drives are also harder to cool, as they are a solid >> block, filling the space, unlike a card of chips. > > It's the same 80 wires on every single drive in the string. > > There are fewer conductors embedded in 12 drive sca backplane as there are in a 12 drive sata backplane, in both cases they are generally two layer pcbs. Compared to what 10+ layer pcbs that are a approaching 1/4" thick on the router. Aw come on, that's no reason you can't just drill it full of holes. I mean, it is 2010. It should be wireless by now. ~Seth From bill at herrin.us Sun Sep 26 20:35:41 2010 From: bill at herrin.us (William Herrin) Date: Sun, 26 Sep 2010 16:35:41 -0400 Subject: Software-based Border Router In-Reply-To: <221425418.6450.1285496120772.JavaMail.root@mailserver> References: <20100926.115921.74701327.sthaug@nethelp.no> <221425418.6450.1285496120772.JavaMail.root@mailserver> Message-ID: On Sun, Sep 26, 2010 at 6:15 AM, Nathanael C. Cariaga wrote: > Thank you for the prompt response. ?Just to clarify my previous > post, I was actually referring to Linux/Unix-based routers. >?We've been considering this solution because presently we > don't have any budget for equipment acquisition this year. What's your time worth? Quagga on Linux is a fine software, but messing with the idiosyncrasies is far more time consuming than buying a Cisco 2811, adding enough RAM to handle BGP, configuring it once and forgetting about it. Also bear in mind that while your ISP's engineers can help you configure your Cisco router, Quagga is a mystery to them. You can still get help... but not from someone who also knows how the ISP's network is configured. This is not a problem if you have lots of experience with BGP routing. Do you? Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From fkittred at staff.gwi.net Sun Sep 26 21:21:57 2010 From: fkittred at staff.gwi.net (Fletcher Kittredge) Date: Sun, 26 Sep 2010 17:21:57 -0400 Subject: Software-based Border Router In-Reply-To: References: <20100926.115921.74701327.sthaug@nethelp.no> <221425418.6450.1285496120772.JavaMail.root@mailserver> Message-ID: Another big problem for Linux/Unix-based routers of this size/cost is upgrade-ability. If you need to add cards, you are going to have to bring the router down for extended periods. Likewise, a software upgrade can be a bigger deal than on a purpose designed router. If a router is mission critical, Linux/Unixed-based has issues over extended periods. regards, Fletcher On Sun, Sep 26, 2010 at 4:35 PM, William Herrin wrote: > On Sun, Sep 26, 2010 at 6:15 AM, Nathanael C. Cariaga > wrote: > > Thank you for the prompt response. Just to clarify my previous > > post, I was actually referring to Linux/Unix-based routers. > > We've been considering this solution because presently we > > don't have any budget for equipment acquisition this year. > > What's your time worth? > > Quagga on Linux is a fine software, but messing with the > idiosyncrasies is far more time consuming than buying a Cisco 2811, > adding enough RAM to handle BGP, configuring it once and forgetting > about it. > > Also bear in mind that while your ISP's engineers can help you > configure your Cisco router, Quagga is a mystery to them. You can > still get help... but not from someone who also knows how the ISP's > network is configured. > > This is not a problem if you have lots of experience with BGP routing. Do > you? > > Regards, > Bill Herrin > > > > -- > William D. Herrin ................ herrin at dirtside.com bill at herrin.us > 3005 Crane Dr. ...................... Web: > Falls Church, VA 22042-3004 > > -- Fletcher Kittredge GWI 8 Pomerleau Street Biddeford, ME 04005-9457 207-602-1134 From if at xip.at Sun Sep 26 21:58:29 2010 From: if at xip.at (Ingo Flaschberger) Date: Sun, 26 Sep 2010 23:58:29 +0200 (CEST) Subject: Software-based Border Router In-Reply-To: References: <20100926.115921.74701327.sthaug@nethelp.no> <221425418.6450.1285496120772.JavaMail.root@mailserver> Message-ID: > Another big problem for Linux/Unix-based routers of this size/cost is > upgrade-ability. If you need to add cards, you are going to have to bring > the router down for extended periods. Likewise, a software upgrade can be > a bigger deal than on a purpose designed router. If a router is mission > critical, Linux/Unixed-based has issues over extended periods. depends on knowledge, as mentioned in previous post. I have 2 software based border routers - no problem bringing one down. 700kpps for 1200eur that can handle a full view. and changing line-cards - could be really funny at c6500. kind regards, Ingo Flaschberger From khatfield at socllc.net Sun Sep 26 22:12:11 2010 From: khatfield at socllc.net (khatfield at socllc.net) Date: Sun, 26 Sep 2010 22:12:11 +0000 Subject: Software-based Border Router In-Reply-To: References: <20100926.115921.74701327.sthaug@nethelp.no><221425418.6450.1285496120772.JavaMail.root@mailserver> Message-ID: <1543058641-1285539133-cardhu_decombobulator_blackberry.rim.net-1680996671-@bda903.bisx.prod.on.blackberry> I do agree here. If you are not moving a lot of data then something like BSD or Vyatta may be a good alternative. You do still have possible reboots required and things you would not see as often with a hardware-appliance model. However, for cheaper than the cost of 1 appliance you could build in redundancy. I guess the question is how many PPS you plan to push, whether you have regularly scheduled maintenance windows that you could bring it down for a reboot, and whether the additional maintenance involved still keeps you in the black? I am a big proponent of open source every thing. Although, I am a bigger proponent of stability and less maintenance. If you could prove out a software-based solution against the cost of a hardware solution then I don't see any reason not to go that route. -----Original Message----- From: Fletcher Kittredge Date: Sun, 26 Sep 2010 17:21:57 To: William Herrin Cc: Subject: Re: Software-based Border Router Another big problem for Linux/Unix-based routers of this size/cost is upgrade-ability. If you need to add cards, you are going to have to bring the router down for extended periods. Likewise, a software upgrade can be a bigger deal than on a purpose designed router. If a router is mission critical, Linux/Unixed-based has issues over extended periods. regards, Fletcher On Sun, Sep 26, 2010 at 4:35 PM, William Herrin wrote: > On Sun, Sep 26, 2010 at 6:15 AM, Nathanael C. Cariaga > wrote: > > Thank you for the prompt response. Just to clarify my previous > > post, I was actually referring to Linux/Unix-based routers. > > We've been considering this solution because presently we > > don't have any budget for equipment acquisition this year. > > What's your time worth? > > Quagga on Linux is a fine software, but messing with the > idiosyncrasies is far more time consuming than buying a Cisco 2811, > adding enough RAM to handle BGP, configuring it once and forgetting > about it. > > Also bear in mind that while your ISP's engineers can help you > configure your Cisco router, Quagga is a mystery to them. You can > still get help... but not from someone who also knows how the ISP's > network is configured. > > This is not a problem if you have lots of experience with BGP routing. Do > you? > > Regards, > Bill Herrin > > > > -- > William D. Herrin ................ herrin at dirtside.com bill at herrin.us > 3005 Crane Dr. ...................... Web: > Falls Church, VA 22042-3004 > > -- Fletcher Kittredge GWI 8 Pomerleau Street Biddeford, ME 04005-9457 207-602-1134 From lists at memetic.org Sat Sep 25 22:18:05 2010 From: lists at memetic.org (Adam Armstrong) Date: Sat, 25 Sep 2010 23:18:05 +0100 Subject: Routers in Data Centers In-Reply-To: References: Message-ID: <4C9E751D.3090507@memetic.org> On 24/09/2010 11:22, Venkatesh Sriram wrote: > Hi, > > Can somebody educate me on (or pass some pointers) what differentiates > a router operating and optimized for data centers versus, say a router > work in the metro ethernet space? What is it thats required for > routers operating in data centers? High throughput, what else? Depending upon the specific requirements of the scenario at each type of site, the optimal devices could be either identical, or completely different. :) adam. From ym1r.jr at gmail.com Sun Sep 26 23:54:48 2010 From: ym1r.jr at gmail.com (ym1r.jr at gmail.com) Date: Sun, 26 Sep 2010 23:54:48 +0000 Subject: Routers in Data Centers Message-ID: <814741965-1285545281-cardhu_decombobulator_blackberry.rim.net-1896844482-@bda929.bisx.prod.on.blackberry> As far as I know open source solutions doesn't have support for fabric or high speed asics. So the throughput will always be a big difference. Unless you are comparing a pure packet software interrupt platform. ------Original Message------ From: Adam Armstrong To: Venkatesh Sriram To: nanog at nanog.org Subject: Re: Routers in Data Centers Sent: Sep 25, 2010 7:18 PM On 24/09/2010 11:22, Venkatesh Sriram wrote: > Hi, > > Can somebody educate me on (or pass some pointers) what differentiates > a router operating and optimized for data centers versus, say a router > work in the metro ethernet space? What is it thats required for > routers operating in data centers? High throughput, what else? Depending upon the specific requirements of the scenario at each type of site, the optimal devices could be either identical, or completely different. :) adam. Sent via my BlackBerry? device from Claro From adrian at creative.net.au Mon Sep 27 00:01:12 2010 From: adrian at creative.net.au (Adrian Chadd) Date: Mon, 27 Sep 2010 08:01:12 +0800 Subject: Routers in Data Centers In-Reply-To: <814741965-1285545281-cardhu_decombobulator_blackberry.rim.net-1896844482-@bda929.bisx.prod.on.blackberry> References: <814741965-1285545281-cardhu_decombobulator_blackberry.rim.net-1896844482-@bda929.bisx.prod.on.blackberry> Message-ID: <20100927000112.GA16467@skywalker.creative.net.au> On Sun, Sep 26, 2010, ym1r.jr at gmail.com wrote: > As far as I know open source solutions doesn't have support for fabric or high speed asics. So the throughput will always be a big difference. Unless you are comparing a pure packet software interrupt platform. Hasn't there been a post about this to the contrary? Isn't someone from Google presenting at NANOG about this? Adrian From rubensk at gmail.com Mon Sep 27 00:35:34 2010 From: rubensk at gmail.com (Rubens Kuhl) Date: Sun, 26 Sep 2010 21:35:34 -0300 Subject: Routers in Data Centers In-Reply-To: <814741965-1285545281-cardhu_decombobulator_blackberry.rim.net-1896844482-@bda929.bisx.prod.on.blackberry> References: <814741965-1285545281-cardhu_decombobulator_blackberry.rim.net-1896844482-@bda929.bisx.prod.on.blackberry> Message-ID: On Sun, Sep 26, 2010 at 8:54 PM, wrote: > As far as I know open source solutions doesn't have support for fabric or high speed asics. So the throughput will always be a big difference. Unless you are comparing a pure packet software interrupt platform. Not high speed ASICs, but there are hardware-forwarding open-source(in a broad definition) solutions: http://netfpga.org There are 3 related presentations on NANOG 50, which suggests these solutions are reaching "real ops" quality. Rubens From adrian at creative.net.au Mon Sep 27 00:42:18 2010 From: adrian at creative.net.au (Adrian Chadd) Date: Mon, 27 Sep 2010 08:42:18 +0800 Subject: Routers in Data Centers In-Reply-To: References: <814741965-1285545281-cardhu_decombobulator_blackberry.rim.net-1896844482-@bda929.bisx.prod.on.blackberry> Message-ID: <20100927004218.GB16467@skywalker.creative.net.au> On Sun, Sep 26, 2010, Rubens Kuhl wrote: > Not high speed ASICs, but there are hardware-forwarding open-source(in > a broad definition) solutions: > http://netfpga.org > > There are 3 related presentations on NANOG 50, which suggests these > solutions are reaching "real ops" quality. I hate to sound (more) like a broken record but if people want to see open source hardware forwarding platforms succeeding (and the software platforms get better), then look at trying to be involved in their development. Too many companies seem to think open source equates to "free stuff that I can use and not pay for"; rather than thinking of it as a normal product (with development cycles, resources, etc that any commercial development requires) that gives them the ability to choose their own direction rather than be beholden to the whims of a vendor. One of the fun divides in open source at times is the big gap between "works" and "works in practice". The only way to get "ops ready" stuff is to work with open source people to make it actually work in your environment rather than "what works for them". :-) (Or you could wait for Google - but doesn't that make you beholden to them as your vendor? :) Adrian -- - Xenion - http://www.xenion.com.au/ - VPS Hosting - Commercial Squid Support - - $24/pm+GST entry-level VPSes w/ capped bandwidth charges available in WA - From hj1980 at gmail.com Mon Sep 27 01:04:34 2010 From: hj1980 at gmail.com (Heath Jones) Date: Mon, 27 Sep 2010 02:04:34 +0100 Subject: Routers in Data Centers In-Reply-To: <20100927004218.GB16467@skywalker.creative.net.au> References: <814741965-1285545281-cardhu_decombobulator_blackberry.rim.net-1896844482-@bda929.bisx.prod.on.blackberry> <20100927004218.GB16467@skywalker.creative.net.au> Message-ID: I'm more than interested in developing a much cheaper, hardware forwarding router.. I think there is a lot of room for innovation - especially at the target market in this thread. If anyone wants to work with me on this, just let me know! I've got a tonne of ideas and a bit of free time.. NetFPGA is a good platform, im saving my pennies to buy one and do some development. Its only a 4 port device, so not a device you would really use in production however. > I hate to sound (more) like a broken record but if people want > to see open source hardware forwarding platforms succeeding > (and the software platforms get better), then look at trying to be > involved in their development. From alex at corp.nac.net Mon Sep 27 01:24:54 2010 From: alex at corp.nac.net (Alex Rubenstein) Date: Sun, 26 Sep 2010 21:24:54 -0400 Subject: Routers in Data Centers In-Reply-To: <20100926174755.GB18648@hiwaay.net> References: <4C9E1DC9.1010809@rollernet.us> <556A0EF3-0038-4DD1-B752-FE272F2EB0DF@bogus.com> <20100926152659.GA8790@hiwaay.net> <7392622F-F7CF-446B-A7AF-E1CD5516039C@bogus.com> <20100926174755.GB18648@hiwaay.net> Message-ID: > > I'm not saying the problems are the same, but I am saying that a > backplane making cooling "hard" is not a good excuse, especially when > the small empty chassis costs $10K+. And, not to mention that some vendors do it sometimes. "The 9-slot Cisco Catalyst 6509 Enhanced Vertical Switch (6509-V-E) provides [stuff]. It also provides front-to-back airflow that is optimized for hot and cold aisle designs in colocated data center and service provider deployments and is compliant with Network Equipment Building Standards (NEBS) deployments." It only took 298 years from the inception of the 6509 to get a front-to-back version. If you can do it with that oversized thing, it certainly can be done on a 7200, XMR, juniper whatever, or whatever else you fancy. There is no good excuse. The datacenter of today (and yesterday) really needs front to back cooling; the datacenter of tomorrow requires and demands it. If vendors cared, they'd do it. Problem is, there is a disconnect between datacenter designer, datacenter builder, datacenter operator, IT operator, and IT manufacturer. No one is smart enough, yet, to say, "if you want to put that hunk of crap in my datacenter, it needs to suck in the front and put out in the back, otherwise my PUE will be 1.3 instead of 1.2 and you will be to blame for my oversized utility bills." Perhaps when a bean-counter paying the power bill sees the difference, it will matter. I dunno. I'll crawl back under my rock now. From if at xip.at Mon Sep 27 01:31:33 2010 From: if at xip.at (Ingo Flaschberger) Date: Mon, 27 Sep 2010 03:31:33 +0200 (CEST) Subject: Routers in Data Centers In-Reply-To: References: <814741965-1285545281-cardhu_decombobulator_blackberry.rim.net-1896844482-@bda929.bisx.prod.on.blackberry> <20100927004218.GB16467@skywalker.creative.net.au> Message-ID: > I'm more than interested in developing a much cheaper, hardware > forwarding router.. > I think there is a lot of room for innovation - especially at the > target market in this thread. > If anyone wants to work with me on this, just let me know! > I've got a tonne of ideas and a bit of free time.. > > NetFPGA is a good platform, im saving my pennies to buy one and do > some development. > Its only a 4 port device, so not a device you would really use in > production however. But it seems, that NetFPGA has not enough memory to hold a full view (current 340k routes). From ras at e-gerbil.net Mon Sep 27 02:29:07 2010 From: ras at e-gerbil.net (Richard A Steenbergen) Date: Sun, 26 Sep 2010 21:29:07 -0500 Subject: Routers in Data Centers In-Reply-To: References: <4C9E1DC9.1010809@rollernet.us> <556A0EF3-0038-4DD1-B752-FE272F2EB0DF@bogus.com> <20100926152659.GA8790@hiwaay.net> <7392622F-F7CF-446B-A7AF-E1CD5516039C@bogus.com> <20100926174755.GB18648@hiwaay.net> Message-ID: <20100927022907.GW1946@gerbil.cluepon.net> On Sun, Sep 26, 2010 at 09:24:54PM -0400, Alex Rubenstein wrote: > > And, not to mention that some vendors do it sometimes. > > "The 9-slot Cisco Catalyst 6509 Enhanced Vertical Switch (6509-V-E) > provides [stuff]. It also provides front-to-back airflow that is > optimized for hot and cold aisle designs in colocated data center and > service provider deployments and is compliant with Network Equipment > Building Standards (NEBS) deployments." A classic 6509 is under 15U, a 6509-V-E is 21U. Anyone can do front to back airflow if they're willing to bloat the size of the chassis (in this case by 40%) to do all the fans and baffling, but then you'd have people whining about the size of the box. :) > It only took 298 years from the inception of the 6509 to get a > front-to-back version. If you can do it with that oversized thing, it > certainly can be done on a 7200, XMR, juniper whatever, or whatever > else you fancy. Well, a lot of people who buy 7200s, baby XMRs, etc, are doing it for the size. Lord knows I certainly bought enough 7606s instead of 6509s over the years for that very reason. I'm sure the vendors prefer to optimize the size footprint on the smaller boxes, and only do front to back airflow on the boxes with large thermal loads (like all the modern 16+ slot chassis that are rapidly approaching 800W/card). Also, remember the 6509 has been around since its 9 slots were lucky to see 100W/card, which is a far cry from a box loaded with 6716s at 400W/card or other power hungry configs. Remember the original XMR 32 chassis, which had side to side airflow? They quickly disappeared that sucker and replaced it with the much larger version they have today, I can only imagine how bad that was. :) -- Richard A Steenbergen http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) From cmadams at hiwaay.net Mon Sep 27 02:45:24 2010 From: cmadams at hiwaay.net (Chris Adams) Date: Sun, 26 Sep 2010 21:45:24 -0500 Subject: Software-based Border Router In-Reply-To: References: <20100926.115921.74701327.sthaug@nethelp.no> <221425418.6450.1285496120772.JavaMail.root@mailserver> Message-ID: <20100927024524.GB30796@hiwaay.net> Once upon a time, William Herrin said: > Quagga on Linux is a fine software, but messing with the > idiosyncrasies is far more time consuming than buying a Cisco 2811, > adding enough RAM to handle BGP, configuring it once and forgetting > about it. Yeah, because IOS and JUNOS don't have idiosyncrasies. :-) -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From christian.martin at teliris.com Mon Sep 27 02:46:48 2010 From: christian.martin at teliris.com (Christian Martin) Date: Sun, 26 Sep 2010 22:46:48 -0400 Subject: Routers in Data Centers In-Reply-To: <20100927022907.GW1946@gerbil.cluepon.net> References: <4C9E1DC9.1010809@rollernet.us> <556A0EF3-0038-4DD1-B752-FE272F2EB0DF@bogus.com> <20100926152659.GA8790@hiwaay.net> <7392622F-F7CF-446B-A7AF-E1CD5516039C@bogus.com> <20100926174755.GB18648@hiwaay.net> <20100927022907.GW1946@gerbil.cluepon.net> Message-ID: On Sep 26, 2010, at 10:29 PM, Richard A Steenbergen wrote: > On Sun, Sep 26, 2010 at 09:24:54PM -0400, Alex Rubenstein wrote: >> >> And, not to mention that some vendors do it sometimes. >> >> "The 9-slot Cisco Catalyst 6509 Enhanced Vertical Switch (6509-V-E) >> provides [stuff]. It also provides front-to-back airflow that is >> optimized for hot and cold aisle designs in colocated data center and >> service provider deployments and is compliant with Network Equipment >> Building Standards (NEBS) deployments." > > A classic 6509 is under 15U, a 6509-V-E is 21U. Anyone can do front to > back airflow if they're willing to bloat the size of the chassis (in > this case by 40%) to do all the fans and baffling, but then you'd have > people whining about the size of the box. :) I would point out that it is quite possible to build a compact (say 4-5 U) front-back airflow platform if vendors were willing to pay to engineer a small midplane and leverage modular I/O cards in a single vertical arrangement. As an example, envisage an M10i with 8 single height PIC slots, rear mounted RE/PFE combos, and a top/bottom impeller. Same for a 72/73xx, or whatever platform you fancy. But would it make business sense? You'd lose rack space in favor of thermal efficiency. I think the push toward cloud computing and the re-emergence of big datacenters with far more stringent power and heat restrictions may actually drive such a move. I guess we'll see... C > >> It only took 298 years from the inception of the 6509 to get a >> front-to-back version. If you can do it with that oversized thing, it >> certainly can be done on a 7200, XMR, juniper whatever, or whatever >> else you fancy. > > Well, a lot of people who buy 7200s, baby XMRs, etc, are doing it for > the size. Lord knows I certainly bought enough 7606s instead of 6509s > over the years for that very reason. I'm sure the vendors prefer to > optimize the size footprint on the smaller boxes, and only do front to > back airflow on the boxes with large thermal loads (like all the modern > 16+ slot chassis that are rapidly approaching 800W/card). Also, remember > the 6509 has been around since its 9 slots were lucky to see 100W/card, > which is a far cry from a box loaded with 6716s at 400W/card or other > power hungry configs. > > Remember the original XMR 32 chassis, which had side to side airflow? > They quickly disappeared that sucker and replaced it with the much > larger version they have today, I can only imagine how bad that was. :) > > -- > Richard A Steenbergen http://www.e-gerbil.net/ras > GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) > From hj1980 at gmail.com Mon Sep 27 03:02:38 2010 From: hj1980 at gmail.com (Heath Jones) Date: Mon, 27 Sep 2010 04:02:38 +0100 Subject: Routers in Data Centers In-Reply-To: References: <814741965-1285545281-cardhu_decombobulator_blackberry.rim.net-1896844482-@bda929.bisx.prod.on.blackberry> <20100927004218.GB16467@skywalker.creative.net.au> Message-ID: > But it seems, that NetFPGA has not enough memory to hold a full view > (current 340k routes). It's just a development platform for prototyping designs, not something you would use in production... I want to use it to implement and test ideas that I have, and play with some different forwarding architectures, not use it as a final product :) From morrowc.lists at gmail.com Mon Sep 27 03:12:58 2010 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Sun, 26 Sep 2010 23:12:58 -0400 Subject: Routers in Data Centers In-Reply-To: References: <814741965-1285545281-cardhu_decombobulator_blackberry.rim.net-1896844482-@bda929.bisx.prod.on.blackberry> <20100927004218.GB16467@skywalker.creative.net.au> Message-ID: On Sun, Sep 26, 2010 at 11:02 PM, Heath Jones wrote: >> But it seems, that NetFPGA has not enough memory to hold a full view >> (current 340k routes). > > It's just a development platform for prototyping designs, not > something you would use in production... > I want to use it to implement and test ideas that I have, and play > with some different forwarding architectures, not use it as a final > product :) also, does a datacenter router/switch need a full table? isn't that the job of the peering/transit routers in your scheme? From james at gitflorida.com Mon Sep 27 03:57:04 2010 From: james at gitflorida.com (James P. Ashton) Date: Sun, 26 Sep 2010 23:57:04 -0400 (EDT) Subject: Routers in Data Centers In-Reply-To: Message-ID: <7322923.233.1285559823953.JavaMail.root@mail.gitflorida.com> ----- Original Message ----- On Sun, Sep 26, 2010 at 11:02 PM, Heath Jones wrote: >> But it seems, that NetFPGA has not enough memory to hold a full view >> (current 340k routes). > > It's just a development platform for prototyping designs, not > something you would use in production... > I want to use it to implement and test ideas that I have, and play > with some different forwarding architectures, not use it as a final > product :) also, does a datacenter router/switch need a full table? isn't that the job of the peering/transit routers in your scheme? Sometimes, but often you get odd results when internal gateway routers only see a pair of default gateways via OSPF or IS-IS. Sometimes the only real fix is to have a full table on these routers as well as your border/peering routers. James From simon at darkmere.gen.nz Mon Sep 27 04:04:35 2010 From: simon at darkmere.gen.nz (Simon Lyall) Date: Mon, 27 Sep 2010 17:04:35 +1300 (NZDT) Subject: Routers in Data Centers In-Reply-To: References: <4C9E1DC9.1010809@rollernet.us> <556A0EF3-0038-4DD1-B752-FE272F2EB0DF@bogus.com> <20100926152659.GA8790@hiwaay.net> <7392622F-F7CF-446B-A7AF-E1CD5516039C@bogus.com> <20100926174755.GB18648@hiwaay.net> Message-ID: A few Blog posts on Datacentre network equipment that people may find interesting and relivant: http://perspectives.mvdirona.com/2009/12/19/NetworkingTheLastBastionOfMainframeComputing.aspx http://mvdirona.com/jrh/TalksAndPapers/JamesHamilton_CleanSlateCTO2009.pdf http://perspectives.mvdirona.com/2010/08/01/EnergyProportionalDatacenterNetworks.aspx -- Simon Lyall | Very Busy | Web: http://www.darkmere.gen.nz/ "To stay awake all night adds a day to your life" - Stilgar | eMT. From if at xip.at Mon Sep 27 11:10:03 2010 From: if at xip.at (Ingo Flaschberger) Date: Mon, 27 Sep 2010 13:10:03 +0200 (CEST) Subject: Routers in Data Centers In-Reply-To: References: <814741965-1285545281-cardhu_decombobulator_blackberry.rim.net-1896844482-@bda929.bisx.prod.on.blackberry> <20100927004218.GB16467@skywalker.creative.net.au> Message-ID: >>> But it seems, that NetFPGA has not enough memory to hold a full view >>> (current 340k routes). >> >> It's just a development platform for prototyping designs, not >> something you would use in production... >> I want to use it to implement and test ideas that I have, and play >> with some different forwarding architectures, not use it as a final >> product :) > > also, does a datacenter router/switch need a full table? isn't that > the job of the peering/transit routers in your scheme? In my small network the datacenter router is also the peering/transit router. From rs at seastrom.com Mon Sep 27 14:20:13 2010 From: rs at seastrom.com (Robert E. Seastrom) Date: Mon, 27 Sep 2010 10:20:13 -0400 Subject: Randy in Nevis In-Reply-To: (Randy Bush's message of "Sun, 19 Sep 2010 10:26:34 -0400") References: Message-ID: <86tylbtgiq.fsf@seastrom.com> Randy Bush writes: >> http://n1.netalyzr.icsi.berkeley.edu/summary/id=43ca253f-6714-b0f7e7b0-d08e-4729-b491#BufferResult > > wow! lime's buffering and 587 hacking make me like caribbean cable more > and more. hmm, 587 hacking, issue with configuration, or typo? Direct TCP connections to remote authenticated SMTP servers (port 587) succeed, but do not receive the expected content. The applet received the following reply instead of our expected header: "421 Cannot establish SSL with SMTP server 67.202.37.63:465, SSL_connect error 336031996 " "Cannot establish SSL with SMTP server 67.202.37.63:465" does not sound like a 587 problem to me. netalyzr folks? comment? -r From lyndon at orthanc.ca Mon Sep 27 16:24:26 2010 From: lyndon at orthanc.ca (Lyndon Nerenberg) Date: Mon, 27 Sep 2010 09:24:26 -0700 Subject: Randy in Nevis In-Reply-To: <86tylbtgiq.fsf@seastrom.com> References: <86tylbtgiq.fsf@seastrom.com> Message-ID: <4CA0C53A.1010700@orthanc.ca> On 10-09-27 7:20 AM, Robert E. Seastrom wrote: > "Cannot establish SSL with SMTP server 67.202.37.63:465" does not > sound like a 587 problem to me. > > netalyzr folks? comment? Cisco PIX? From lyndon at orthanc.ca Mon Sep 27 16:30:06 2010 From: lyndon at orthanc.ca (Lyndon Nerenberg) Date: Mon, 27 Sep 2010 09:30:06 -0700 Subject: Randy in Nevis In-Reply-To: <86tylbtgiq.fsf@seastrom.com> References: <86tylbtgiq.fsf@seastrom.com> Message-ID: <4CA0C68E.2070501@orthanc.ca> On 10-09-27 7:20 AM, Robert E. Seastrom wrote: > "Cannot establish SSL with SMTP server 67.202.37.63:465" does not > sound like a 587 problem to me. > > netalyzr folks? comment? Sorry, I hit send too soon ... I've heard from a couple of people that the PIX will remap 587 (and 25) to oddball ports if you fiddle the config just right. Given all the other bogosity that box does with SMTP I wonder if there's truth to the rumour. (I haven't found anyone who can reproduce this on demand, so it's still apocryphal for now.) From jbates at brightok.net Mon Sep 27 16:39:11 2010 From: jbates at brightok.net (Jack Bates) Date: Mon, 27 Sep 2010 11:39:11 -0500 Subject: Online games stealing your bandwidth In-Reply-To: <20100925234734.GA19927@skywalker.creative.net.au> References: <20100925234734.GA19927@skywalker.creative.net.au> Message-ID: <4CA0C8AF.7000808@brightok.net> On 9/25/2010 6:47 PM, Adrian Chadd wrote: > > I don't recall any protocols being standard. > I don't either, though I recall bittorrent actually supporting it once and pushing to have ISP support and stay away from encryption/ISP circumvention. That was years ago. Haven't stayed current. > Plenty of people sell p2p caches but they all work using magic, smoke > and mirrors. Seem to recall some law suits concerning a few of them. Even if we had ISP supporting caches, there is always the problem getting p2p clients to support them (given they often are too busy trying to circumvent). A good standard would be nice, though, and at least offer a middle ground for trying to get support for such technology as well as pushing it back to open source, legitimate caching vs lying to p2p clients, and solving many issues that pop up from time to time of upstreams not supporting the downstream loads, which a cache could heavily alleviate. Jack From Valdis.Kletnieks at vt.edu Mon Sep 27 16:44:04 2010 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Mon, 27 Sep 2010 12:44:04 -0400 Subject: Randy in Nevis In-Reply-To: Your message of "Mon, 27 Sep 2010 09:30:06 PDT." <4CA0C68E.2070501@orthanc.ca> References: <86tylbtgiq.fsf@seastrom.com> <4CA0C68E.2070501@orthanc.ca> Message-ID: <17357.1285605844@localhost> On Mon, 27 Sep 2010 09:30:06 PDT, Lyndon Nerenberg said: > I've heard from a couple of people that the PIX will remap 587 (and 25) > to oddball ports if you fiddle the config just right. Given all the > other bogosity that box does with SMTP I wonder if there's truth to the > rumour. (I haven't found anyone who can reproduce this on demand, so > it's still apocryphal for now.) I've heard some people say that reproducing totally compliant SMTP behavior on those boxes on demand is apocryphal as well. :) (I have to admit I haven't actually tracked a user complaint down to a misbehaving PIX in a year or two, but I can't say if the software has gotten better or if its market share is just small enough to fly under my radar - the type of people who send e-mail from behind a PIX don't interact with my users all that often) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From leigh.porter at ukbroadband.com Mon Sep 27 16:44:37 2010 From: leigh.porter at ukbroadband.com (Leigh Porter) Date: Mon, 27 Sep 2010 17:44:37 +0100 Subject: Online games stealing your bandwidth In-Reply-To: <4CA0C8AF.7000808@brightok.net> References: <20100925234734.GA19927@skywalker.creative.net.au> <4CA0C8AF.7000808@brightok.net> Message-ID: -----Original Message----- From: Jack Bates [mailto:jbates at brightok.net] Sent: 27 September 2010 17:39 To: Adrian Chadd Cc: NANOG Subject: Re: Online games stealing your bandwidth On 9/25/2010 6:47 PM, Adrian Chadd wrote: >> >> I don't recall any protocols being standard. >> >I don't either, though I recall bittorrent actually supporting it once >and pushing to have ISP support and stay away from encryption/ISP >circumvention. That was years ago. Haven't stayed current. >> Plenty of people sell p2p caches but they all work using magic, smoke >> and mirrors. >Seem to recall some law suits concerning a few of them. Even if we had >ISP supporting caches, there is always the problem getting p2p clients >to support them (given they often are too busy trying to circumvent). We had a great P2P cache from Cache Appliance. Did anybody else try them? -- Leigh From Valdis.Kletnieks at vt.edu Mon Sep 27 17:01:17 2010 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Mon, 27 Sep 2010 13:01:17 -0400 Subject: Online games stealing your bandwidth In-Reply-To: Your message of "Mon, 27 Sep 2010 17:44:37 BST." References: <20100925234734.GA19927@skywalker.creative.net.au> <4CA0C8AF.7000808@brightok.net> Message-ID: <18294.1285606877@localhost> On Mon, 27 Sep 2010 17:44:37 BST, Leigh Porter said: > We had a great P2P cache from Cache Appliance. Did anybody else try > them? Can you say anything about what size cache it was, and what amount of bandwidth savings it produced? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From dholmes at mwdh2o.com Mon Sep 27 17:07:37 2010 From: dholmes at mwdh2o.com (Holmes,David A) Date: Mon, 27 Sep 2010 10:07:37 -0700 Subject: Mobile Operator Connectivity In-Reply-To: References: Message-ID: <485ED9BA02629E4BBBA53AC892EDA50E0BBCB36F@usmsxt104.mwd.h2o> With the assumption that you will have a wired backhaul to your HQ over which the retail access-layer devices connect to commerce servers, make sure that the wireless carrier's gateways to their wired network (where the wired backhaul is connected to) are geographically well-dispersed such that wireless access traffic from (for example) suburban Los Angeles destined for a Los Angeles HQ data center, does not traverse the US back to the east coast before it enters the carrier's wired backbone. Surprisingly, some large wireless carriers appear to think that 2 continental traversals for each packet is an acceptable network design. I have experienced round trip latency between sites 50 miles apart measured at 750-1500 milliseconds when using GSM/CDMA wireless as the access layer method. The key is to ask the wireless carrier where the network-to-network interfaces between the wireless and wired backbone networks are located, and moreover, how many interfaces are there. Some large wireless carriers have a single wireless/wired gateway for the entire US! -----Original Message----- From: Leo Woltz [mailto:leo.woltz at gmail.com] Sent: Saturday, September 25, 2010 1:37 PM To: nanog at nanog.org Subject: Mobile Operator Connectivity I am looking for some guidance from the list. We will soon be deploying wireless payment devices (CDMA/GSM). We are looking at options on where to locate the servers that will run the backend payment gateways; we would like the least amount of latency between the servers and the wireless networks as possible. The wireless networks we will be deploying the devices on are: AT&T Wireless Verizon Wireless Sprint PCS Rogers Wireless Bell Mobility Telus Mobility Vodafone I was thinking we have a few options, to try and peer with the wireless networks directly, buy bandwidth from networks that are directly peered with the wireless operators or the Global Roaming Exchange Peering service that Equinix runs but I have not been able to find out much more then what is on Equinix's public web site. We also have a need to peer with PayPal and Amazon. I welcome the lists comments and recommendations. From khuon at neebu.net Mon Sep 27 17:36:31 2010 From: khuon at neebu.net (Jake Khuon) Date: Mon, 27 Sep 2010 10:36:31 -0700 Subject: Software-based Border Router In-Reply-To: <20100927024524.GB30796@hiwaay.net> References: <20100926.115921.74701327.sthaug@nethelp.no> <221425418.6450.1285496120772.JavaMail.root@mailserver> <20100927024524.GB30796@hiwaay.net> Message-ID: <1285608991.2342.6.camel@Decaf.NEEBU.Net> On Sun, 2010-09-26 at 21:45 -0500, Chris Adams wrote: > Yeah, because IOS and JUNOS don't have idiosyncrasies. :-) Not gonna argue with you on that one. However, the world has changed since the days where the chances of clueful unix systems engineering knowledge and clueful BGP routing knowledge was highly guaranteed to be found cohabitating in a single lifeform. You are far more likely to find that relatively speaking most network engineers have very little knowledge in unix systems engineering. This list may be an exception but I would gather that the bulk of the network engineering workforce are little more than power users (if that) when it comes to operating systems. -- /*=================[ Jake Khuon ]=================+ | Packet Plumber, Network Engineers /| / [~ [~ |) | | -------- | | for Effective Bandwidth Utilisation / |/ [_ [_ |) |_| NETWORKS | +==================================================================*/ From brandon at rd.bbc.co.uk Mon Sep 27 18:27:28 2010 From: brandon at rd.bbc.co.uk (Brandon Butterworth) Date: Mon, 27 Sep 2010 19:27:28 +0100 (BST) Subject: Online games stealing your bandwidth Message-ID: <201009271827.TAA11225@sunf10.rd.bbc.co.uk> > Even if we had > ISP supporting caches, there is always the problem getting p2p clients > to support them (given they often are too busy trying to circumvent). I fail to see the point. If an ISP needs to add caches they may as well just add a simple, cheaper, standard, http cache. No special clients required, no fiddling to make locality work and no extra, expensive in some architectures, last mile traffic brandon From mksmith at adhost.com Mon Sep 27 19:20:43 2010 From: mksmith at adhost.com (Michael K. Smith - Adhost) Date: Mon, 27 Sep 2010 12:20:43 -0700 Subject: Randy in Nevis In-Reply-To: <4CA0C68E.2070501@orthanc.ca> References: <86tylbtgiq.fsf@seastrom.com> <4CA0C68E.2070501@orthanc.ca> Message-ID: <17838240D9A5544AAA5FF95F8D52031608F0442A@ad-exh01.adhost.lan> > -----Original Message----- > From: Lyndon Nerenberg [mailto:lyndon at orthanc.ca] > Sent: Monday, September 27, 2010 9:30 AM > To: nanog at nanog.org > Subject: Re: Randy in Nevis > > On 10-09-27 7:20 AM, Robert E. Seastrom wrote: > > "Cannot establish SSL with SMTP server 67.202.37.63:465" does not > > sound like a 587 problem to me. > > > > netalyzr folks? comment? > > Sorry, I hit send too soon ... > > I've heard from a couple of people that the PIX will remap 587 (and 25) > to oddball ports if you fiddle the config just right. Given all the > other bogosity that box does with SMTP I wonder if there's truth to the > rumour. (I haven't found anyone who can reproduce this on demand, so > it's still apocryphal for now.) Static (inside,outside) tcp 25 65535 Access-list outside_acl permit tcp any any eq 25 No fixup smtp That will redirect port 25 to port 65535, allow port 25 through the firewall, and remove the fixup that changes the server banner to *************, which breaks most mail communications. Regards, Mike From Valdis.Kletnieks at vt.edu Mon Sep 27 19:25:35 2010 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Mon, 27 Sep 2010 15:25:35 -0400 Subject: Online games stealing your bandwidth In-Reply-To: Your message of "Mon, 27 Sep 2010 19:27:28 BST." <201009271827.TAA11225@sunf10.rd.bbc.co.uk> References: <201009271827.TAA11225@sunf10.rd.bbc.co.uk> Message-ID: <25588.1285615535@localhost> On Mon, 27 Sep 2010 19:27:28 BST, Brandon Butterworth said: > I fail to see the point. If an ISP needs to add caches they may > as well just add a simple, cheaper, standard, http cache. It's a bang-per-buck issue, and depends highly on whether your particular network sees more HTTP or P2P traffic. If HTTP is 60% of your traffic, an http cache makes sense. If P2P is 70% and HTTP is 20%, it probably doesn't make sense. And the only numbers that matter here are what *you* measure at the point you intend to install the cache - I've seen so many conflicting numbers for different parts of the net that no firm conclusions can be drawn. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From brandon at rd.bbc.co.uk Mon Sep 27 19:54:27 2010 From: brandon at rd.bbc.co.uk (Brandon Butterworth) Date: Mon, 27 Sep 2010 20:54:27 +0100 (BST) Subject: Online games stealing your bandwidth Message-ID: <201009271954.UAA18678@sunf10.rd.bbc.co.uk> > > I fail to see the point. If an ISP needs to add caches they may > > as well just add a simple, cheaper, standard, http cache. > > It's a bang-per-buck issue, and depends highly on whether your > particular network sees more HTTP or P2P traffic. Orly. No, I mean if there have to be caches why use p2p in the first place, once there's a network of caches p2p becomes a more complicated http and that model has been well optimised by some. I know the people stealing things don't want to pay akamai but games charging for access are a different matter. brandon From leigh.porter at ukbroadband.com Mon Sep 27 20:01:39 2010 From: leigh.porter at ukbroadband.com (Leigh Porter) Date: Mon, 27 Sep 2010 21:01:39 +0100 Subject: Online games stealing your bandwidth In-Reply-To: <201009271954.UAA18678@sunf10.rd.bbc.co.uk> References: <201009271954.UAA18678@sunf10.rd.bbc.co.uk> Message-ID: <56635CDC-EF12-4402-BE60-C822EDAC574A@ukbroadband.com> On 27 Sep 2010, at 20:54, Brandon Butterworth wrote: >>> I fail to see the point. If an ISP needs to add caches they may >>> as well just add a simple, cheaper, standard, http cache. >> >> It's a bang-per-buck issue, and depends highly on whether your >> particular network sees more HTTP or P2P traffic. > > Orly. > > No, I mean if there have to be caches why use p2p in the first place, > once there's a network of caches p2p becomes a more complicated http > and that model has been well optimised by some. > > I know the people stealing things don't want to pay akamai but games > charging for access are a different matter. > > brandon > I agree but it isnt the SP who drives P2P use, its the users.. So whilst they use it, networks kind of have to make it work. We used the P2P cache for a very specific reason. We had a wireless uplink constrained network and the P2P cache cached users uplink traffic and served it from the cache, saving us about 50% up our P2P uplink load. -- Leigh Porter From sethm at rollernet.us Mon Sep 27 20:13:49 2010 From: sethm at rollernet.us (Seth Mattinen) Date: Mon, 27 Sep 2010 13:13:49 -0700 Subject: Mobile Operator Connectivity In-Reply-To: References: Message-ID: <4CA0FAFD.30802@rollernet.us> On 9/25/2010 13:37, Leo Woltz wrote: > I am looking for some guidance from the list. We will soon be deploying > wireless payment devices (CDMA/GSM). We are looking at options on where to > locate the servers that will run the backend payment gateways; we would like > the least amount of latency between the servers and the wireless networks as > possible. The wireless networks we will be deploying the devices on are: > > > Sprint PCS > For Sprint you can get a circuit to AS1239 and just take customer routes. Their PCS network is AS10507, but as far as I know the closest you can get to it is 1239. ~Seth From jbates at brightok.net Mon Sep 27 20:37:46 2010 From: jbates at brightok.net (Jack Bates) Date: Mon, 27 Sep 2010 15:37:46 -0500 Subject: Online games stealing your bandwidth In-Reply-To: <201009271954.UAA18678@sunf10.rd.bbc.co.uk> References: <201009271954.UAA18678@sunf10.rd.bbc.co.uk> Message-ID: <4CA1009A.3070809@brightok.net> On 9/27/2010 2:54 PM, Brandon Butterworth wrote: > No, I mean if there have to be caches why use p2p in the first place, > once there's a network of caches p2p becomes a more complicated http > and that model has been well optimised by some. > It's a redundancy factor. By participating in a p2p network as a cache, and even feeding clients information which would be important to them (ie, I'm actually better than your neighbor's house). p2p can be optimized. A p2p cache generally wouldn't cache items which don't have repeatability, so there would probably need to be multiple hits for the cache to grab the data. The cache itself would use p2p to obtain it's copy, providing information to it's clients even as the current clients and the cache server are both pulling from remotes. At no point should you consider such a caching solution to equate to a standard http cache. A proper standardized p2p cache shouldn't just be about caching information for local clients, but should also be about giving clients additional information to optimize them. Clients who are seeding information should be able to inform the cache of such, and should enough traffic be involved, the cache itself should be able to pull the necessary information and start providing to remotes instead of the client, so long as the client shows it's seeding (ie, client is seeding, but actually isn't transferring data since the cache is announcing it will on behalf of the client). This would, of course, not drop the overall outbound p2p traffic from an ISP at it's core, but could reduce last mile bandwidth while still participating as necessary. It meets the legal caching framework, as if the client stops providing, the cache will stop providing. Such a solution, of course should still maintain a "hey, IP x seeding, but cache at IP y has the data" (similar to proxy headers, but this works in a cloud which complicates it a bit) to meet any dmca tracking issues or ISPs will run from the legal nightmare. Jack From dylan.ebner at crlmed.com Mon Sep 27 20:59:15 2010 From: dylan.ebner at crlmed.com (Dylan Ebner) Date: Mon, 27 Sep 2010 20:59:15 +0000 Subject: Software-based Border Router In-Reply-To: <553474862.6446.1285494100818.JavaMail.root@mailserver> References: <1981894704.6437.1285493639414.JavaMail.root@mailserver> <553474862.6446.1285494100818.JavaMail.root@mailserver> Message-ID: <017265BF3B9640499754DD48777C3D206A0E2CE566@MBX9.EXCHPROD.USA.NET> We have looked at using open source routers for our border, but in the end we cannot make the numbers add up. Once Cisco released the x9xx ISR2 routers, the x8xx have tanked in price on the used market. So, for about the same as a vyatta router running on newer hardware that you can trust you can get a 28xx or 38xx. If you also want support, Cisco will support these at less than $100/month and that gets you access to the IOS upgrades and a 4 hr. replacement window. I know I sleep better knowing Cisco will drop off a router in less than 4 hours if one of mine fails. Dylan -----Original Message----- From: Nathanael C. Cariaga [mailto:nccariaga at stluke.com.ph] Sent: Sunday, September 26, 2010 4:42 AM To: nanog at nanog.org Subject: Software-based Border Router Hi All! Just want to ask if anyone here had experience deploying software-based routers to serve as perimeter / border router? How does it gauge with hardware-based routers? Any past experiences will be very much appreciated. I wanted to know because we've been asked if we want to assume full control of the internet link (up to the router). By assuming control up to the router, we still want to configure iBGP with our parent network so that we can take advantage of some routes available to the parent network's gateway. The saddest part is presently we do not have the router to serve as our gateway this is why we are considering the use of software-based routers. Thank you. From bclark at spectraaccess.com Mon Sep 27 21:14:33 2010 From: bclark at spectraaccess.com (Bret Clark) Date: Mon, 27 Sep 2010 17:14:33 -0400 Subject: Software-based Border Router In-Reply-To: <017265BF3B9640499754DD48777C3D206A0E2CE566@MBX9.EXCHPROD.USA.NET> References: <1981894704.6437.1285493639414.JavaMail.root@mailserver> <553474862.6446.1285494100818.JavaMail.root@mailserver> <017265BF3B9640499754DD48777C3D206A0E2CE566@MBX9.EXCHPROD.USA.NET> Message-ID: <4CA10939.10707@spectraaccess.com> We use a mix of software and hardware based routers, have found little difference between the two platforms in terms of performance and stability. Our software base routers are serving a couple 100Mbps upstream links running on some HP Proliants with dual PS and dual HD's that we picked up on ebay for a $150 then loaded Quagga on them. I actually have to give a little bit of a edge to the Linux based systems only because of all the all the other wealth of diagnostics/troubleshooting tools one gets with Linux in general...Its nice to be able to run Wireshark right on the systems if we need too. As for troubleshooting, I've found the Quagga mailing list to be just as responsive (if not more responsive at times) as Cisco, but clearly your mileage will vary there. Bret On 09/27/2010 04:59 PM, Dylan Ebner wrote: > We have looked at using open source routers for our border, but in the end we cannot make the numbers add up. Once Cisco released the x9xx ISR2 routers, the x8xx have tanked in price on the used market. So, for about the same as a vyatta router running on newer hardware that you can trust you can get a 28xx or 38xx. If you also want support, Cisco will support these at less than $100/month and that gets you access to the IOS upgrades and a 4 hr. replacement window. I know I sleep better knowing Cisco will drop off a router in less than 4 hours if one of mine fails. > > Dylan > -----Original Message----- > From: Nathanael C. Cariaga [mailto:nccariaga at stluke.com.ph] > Sent: Sunday, September 26, 2010 4:42 AM > To: nanog at nanog.org > Subject: Software-based Border Router > > Hi All! > > > Just want to ask if anyone here had experience deploying software-based routers to serve as perimeter / border router? How does it gauge with hardware-based routers? Any past experiences will be very much appreciated. > > > I wanted to know because we've been asked if we want to assume full control of the internet link (up to the router). By assuming control up to the router, we still want to configure iBGP with our parent network so that we can take advantage of some routes available to the parent network's gateway. The saddest part is presently we do not have the router to serve as our gateway this is why we are considering the use of software-based routers. > > > Thank you. > From cmaurand at xyonet.com Mon Sep 27 22:06:25 2010 From: cmaurand at xyonet.com (cmaurand at xyonet.com) Date: Mon, 27 Sep 2010 18:06:25 -0400 Subject: Software-based Border Router In-Reply-To: References: <20100926.115921.74701327.sthaug@nethelp.no> <221425418.6450.1285496120772.JavaMail.root@mailserver> Message-ID: <632cd89a3c2601509f182619bcfe669a.squirrel@www.xyonet.com> I haven't found that to be the case. The larger memory space available to the kernel allows for larger BGP tables and filtering tables. I've seen BSD based systems running thousands of concurrent tunnels and the processors available in the linux/BSD space bury anything that the router manufacturers are overcharging you for. A properly planned upgrade or addition of a card should take a maximum of 15 minutes as everything should be plug and play. Some of the software based systems also come from the manufacturer with the hardware. If the network is configured properly with failover capabilities and only one unit down at a time, down time is minimal or non existent. Software upgrades happen in a matter of minutes. Cheers, --Curtis > Another big problem for Linux/Unix-based routers of this size/cost is > upgrade-ability. If you need to add cards, you are going to have to > bring > the router down for extended periods. Likewise, a software upgrade can > be > a bigger deal than on a purpose designed router. If a router is mission > critical, Linux/Unixed-based has issues over extended periods. > > regards, > Fletcher > > On Sun, Sep 26, 2010 at 4:35 PM, William Herrin wrote: > >> On Sun, Sep 26, 2010 at 6:15 AM, Nathanael C. Cariaga >> wrote: >> > Thank you for the prompt response. Just to clarify my previous >> > post, I was actually referring to Linux/Unix-based routers. >> > We've been considering this solution because presently we >> > don't have any budget for equipment acquisition this year. >> >> What's your time worth? >> >> Quagga on Linux is a fine software, but messing with the >> idiosyncrasies is far more time consuming than buying a Cisco 2811, >> adding enough RAM to handle BGP, configuring it once and forgetting >> about it. >> >> Also bear in mind that while your ISP's engineers can help you >> configure your Cisco router, Quagga is a mystery to them. You can >> still get help... but not from someone who also knows how the ISP's >> network is configured. >> >> This is not a problem if you have lots of experience with BGP routing. >> Do >> you? >> >> Regards, >> Bill Herrin >> >> >> >> -- >> William D. Herrin ................ herrin at dirtside.com bill at herrin.us >> 3005 Crane Dr. ...................... Web: >> Falls Church, VA 22042-3004 >> >> > > > -- > Fletcher Kittredge > GWI > 8 Pomerleau Street > Biddeford, ME 04005-9457 > 207-602-1134 > From hj1980 at gmail.com Mon Sep 27 22:48:04 2010 From: hj1980 at gmail.com (Heath Jones) Date: Mon, 27 Sep 2010 23:48:04 +0100 Subject: Software-based Border Router In-Reply-To: <632cd89a3c2601509f182619bcfe669a.squirrel@www.xyonet.com> References: <20100926.115921.74701327.sthaug@nethelp.no> <221425418.6450.1285496120772.JavaMail.root@mailserver> <632cd89a3c2601509f182619bcfe669a.squirrel@www.xyonet.com> Message-ID: Do jitter sensitive applications have problems at all running? What would you say is the point at which people should be looking for a hardware forwarding solution? Differences: - Hardware forwarding - Interface options - Port density - Redundancy - Power consumption - Service Provider stuff - MPLS TE? VPLS? VRF?? Any others? From hj1980 at gmail.com Mon Sep 27 22:48:51 2010 From: hj1980 at gmail.com (Heath Jones) Date: Mon, 27 Sep 2010 23:48:51 +0100 Subject: Software-based Border Router In-Reply-To: References: <20100926.115921.74701327.sthaug@nethelp.no> <221425418.6450.1285496120772.JavaMail.root@mailserver> <632cd89a3c2601509f182619bcfe669a.squirrel@www.xyonet.com> Message-ID: Oh, support contract!!? > Differences: > - Hardware forwarding > - Interface options > - Port density > - Redundancy > - Power consumption > - Service Provider stuff - MPLS TE? VPLS? VRF?? > > Any others? > From pde at eff.org Mon Sep 27 23:40:25 2010 From: pde at eff.org (Peter Eckersley) Date: Mon, 27 Sep 2010 16:40:25 -0700 Subject: EFF needs your help to stop the Senate's DNS censorship bill Message-ID: <20100927234025.GA18304@tapdance> Dear network operators, I apologise for a posting that contains some politics; I hope you'll agree that it also has fairly substantial short-to-medium term operational implications. As you may or may not have heard, there is a censor-DNS-to-enforce-copyright bill that is going to be passed by the Senate Judiciary Committee this Wednesday. It will require service providers to censor the DNS entries of blacklisted domains where piracy is deemed too "central" to the site's purpose. Senators are claiming that they haven't heard any opposition to this bill, and it is being sponsored by 14 of the 19 committee members. We believe it needs to be stopped, and we need your help. What EFF needs right now is sign-ons to an open letter, from the engineers who helped build the Internet in the first place. The text of our letter is below. If you agree with it and would like to sign, please send me an email at pde at eff.org, with your name and a one-line summary of what part of the Internet you have helped to design, implement, debug or run. This is URGENT. I need your sign-ons by 4:00pm, US Eastern time (1pm Pacific), tomorrow. Unfortunately, the civil liberties community has been ambushed by this bill. You can find out more details on the bill here: https://eff.org/coica --------------------------- Open letter from Internet engineers to members of the Senate Judiciary Committee: We, the undersigned, have played various parts in building a network called the Internet. We wrote and debugged the software; we defined the standards and protocols that talk over that network. Many of us invented parts of it. We're just a little proud of the social and economic benefits that our project, the Internet, has brought with it. We are writing to oppose the Committee's proposed new Internet censorship and copyright bill. If enacted, this legislation will risk fragmenting the Internet's global domain name system (DNS), create an environment of tremendous fear and uncertainty for technological innovation, and seriously harm the credibility of the United States in its role as a steward of key Internet infrastructure. In exchange for this, the bill will introduce censorship that will simultaneously be circumvented by deliberate infringers while hampering innocent parties' ability to communicate. All censorship schemes impact speech beyond the category they were intended to restrict, but this bill will be particularly egregious in that regard because it causes entire domains to vanish from the Web, not just infringing pages or files. Worse, an incredible range of useful, law-abiding sites can be blacklisted under this bill. These problems will be enough to ensure that alternative name-lookup infrastructures will come into widespread use, outside the control of US service providers but easily used by American citizens. Errors and divergences will appear between these new services and the current global DNS, and contradictory addresses will confuse browsers and frustrate the people using them. These problems will be widespread and will affect sites other than those blacklisted by the American government. The US government has regularly claimed that it supports a free and open Internet, both domestically and abroad. We can't have a free and open Internet without a global domain name system that sits above the political concerns and objectives of any one government or industry. To date, the leading role the US has played in this infrastructure has been fairly uncontroversial because America is seen as a trustworthy arbiter and a neutral bastion of free expression. If the US suddenly begins to use its central position in the DNS for censorship that advances its political and economic agenda, the consequences will be far-reaching and destructive. Senators, we believe the Internet is too important and too valuable to be endangered in this way, and implore you to put this bill aside. -- Peter Eckersley pde at eff.org Senior Staff Technologist Tel +1 415 436 9333 x131 Electronic Frontier Foundation Fax +1 415 436 9993 From manavbhatia at gmail.com Tue Sep 28 00:03:31 2010 From: manavbhatia at gmail.com (Manav Bhatia) Date: Tue, 28 Sep 2010 05:33:31 +0530 Subject: OSPFv3 Authentication Message-ID: Hi, I am doing a survey and was interested in knowing if network operators are using OSPFv3 with authentication [RFC 4552] turned on? I know that most providers turn on authentication with OSPFv2, but given that OSPFv3 needs IPsec integration and can thus get little cumbersome to configure, wanted to understand if a similar % of folks also turn on authentication for OSPFv3? You can unicast me your responses (if you dont wish to share it on the list) and i will collate all data and post a summary on the list. Cheers, Manav From richard.barnes at gmail.com Tue Sep 28 00:31:28 2010 From: richard.barnes at gmail.com (Richard Barnes) Date: Mon, 27 Sep 2010 20:31:28 -0400 Subject: Online games stealing your bandwidth In-Reply-To: References: Message-ID: There's some standardization work being done in the IETF ALTO working group. They're looking at ways ISPs can inform P2P clints about which peers are "better", I.e., topologically nearby. http://tools.ietf.org/wg/alto/ I'm less familiar with DECADE, but I believe they're working on more directly cache-related stuff. http://tools.ietf.org/wg/decade/ On Sep 25, 2010 4:44 PM, "Matthew Walster" wrote: On 25 September 2010 21:16, Rodrick Brown wrote: > I think most people are... I once read an article talking about making BitTorrent scalable by using anycasted caching services at the ISP's closest POP to the end user. Given sufficient traffic on a specified torrent, the caching device would build up the file, then distribute that direct to the subscriber in the form of an additional (preferred) peer. Similar to a CDN or Usenet, but where it was cached rather than deliberately pushed out from a locus. Was anything ever standardised in that field? I imagine with much of P2P traffic being (how shall I put this...) less than legal, it's of questionable legality and the ISPs would not want to be held liable for the content cached there? M From wbailey at gci.com Tue Sep 28 00:35:17 2010 From: wbailey at gci.com (Warren Bailey) Date: Mon, 27 Sep 2010 16:35:17 -0800 Subject: Online games stealing your bandwidth In-Reply-To: References: Message-ID: Can someone name an ISP that encourages P2P traffic?? ;) Sent from a mobile phone with a small keyboard, please excuse my mistakes. On Sep 27, 2010, at 4:32 PM, "Richard Barnes" wrote: > There's some standardization work being done in the IETF ALTO working > group. They're looking at ways ISPs can inform P2P clints about which peers > are "better", I.e., topologically nearby. > http://tools.ietf.org/wg/alto/ > > I'm less familiar with DECADE, but I believe they're working on more > directly cache-related stuff. > http://tools.ietf.org/wg/decade/ > > On Sep 25, 2010 4:44 PM, "Matthew Walster" wrote: > > On 25 September 2010 21:16, Rodrick Brown wrote: >> I think most people are... > > > I once read an article talking about making BitTorrent scalable by > using anycasted caching services at the ISP's closest POP to the end > user. Given sufficient traffic on a specified torrent, the caching > device would build up the file, then distribute that direct to the > subscriber in the form of an additional (preferred) peer. Similar to a > CDN or Usenet, but where it was cached rather than deliberately pushed > out from a locus. > > Was anything ever standardised in that field? I imagine with much of > P2P traffic being (how shall I put this...) less than legal, it's of > questionable legality and the ISPs would not want to be held liable > for the content cached there? > > M From richard.barnes at gmail.com Tue Sep 28 01:41:23 2010 From: richard.barnes at gmail.com (Richard Barnes) Date: Mon, 27 Sep 2010 21:41:23 -0400 Subject: Online games stealing your bandwidth In-Reply-To: References: Message-ID: I thought the issue was more about ISPs encouraging *responsible* P2P. On Mon, Sep 27, 2010 at 8:35 PM, Warren Bailey wrote: > Can someone name an ISP that encourages P2P traffic?? ;) > > Sent from a mobile phone with a small keyboard, please excuse my mistakes. > > On Sep 27, 2010, at 4:32 PM, "Richard Barnes" wrote: > >> There's some standardization work being done in the IETF ALTO working >> group. ?They're looking at ways ISPs can inform P2P clints about which peers >> are "better", I.e., topologically nearby. >> http://tools.ietf.org/wg/alto/ >> >> I'm less familiar with DECADE, but I believe they're working on more >> directly cache-related stuff. >> http://tools.ietf.org/wg/decade/ >> >> On Sep 25, 2010 4:44 PM, "Matthew Walster" wrote: >> >> On 25 September 2010 21:16, Rodrick Brown wrote: >>> I think most people are... >> >> >> I once read an article talking about making BitTorrent scalable by >> using anycasted caching services at the ISP's closest POP to the end >> user. Given sufficient traffic on a specified torrent, the caching >> device would build up the file, then distribute that direct to the >> subscriber in the form of an additional (preferred) peer. Similar to a >> CDN or Usenet, but where it was cached rather than deliberately pushed >> out from a locus. >> >> Was anything ever standardised in that field? I imagine with much of >> P2P traffic being (how shall I put this...) less than legal, it's of >> questionable legality and the ISPs would not want to be held liable >> for the content cached there? >> >> M > From dholmes at mwdh2o.com Tue Sep 28 01:41:39 2010 From: dholmes at mwdh2o.com (Holmes,David A) Date: Mon, 27 Sep 2010 18:41:39 -0700 Subject: Mobile Operator Connectivity In-Reply-To: <4CA0FAFD.30802@rollernet.us> References: <4CA0FAFD.30802@rollernet.us> Message-ID: <485ED9BA02629E4BBBA53AC892EDA50E0BBCB490@usmsxt104.mwd.h2o> Some large telcos with wireless and wireline operations in the US maintain 2 separate backbones: one that I call "wired", that corresponds to traditional wired access where commerce servers are usually located; and one that I call a "wireless" backbone, where GSM/CDMA wireless devices are used to aggregate access-layer traffic. Both backbones consist of national fiber-optic, BGP-based networks. Surprisingly, some large telcos have a presence of both wireline and wireless backbones in the same colos, but the 2 backbone networks are interconnected, not in that colo, but at a single geographic location (with perhaps a single hot standby interconnection site), located, for example in northern Virginia. So, the worst case is that if the servers and GSM/CDMA devices are located in Southern California, even though the telco has a wireline and wireless presence in the local LA colo, GSM/CDMA access-layer traffic must traverse the continental US to northern Virginia and back to get to the server. -----Original Message----- From: Seth Mattinen [mailto:sethm at rollernet.us] Sent: Monday, September 27, 2010 1:14 PM To: nanog at nanog.org Subject: Re: Mobile Operator Connectivity On 9/25/2010 13:37, Leo Woltz wrote: > I am looking for some guidance from the list. We will soon be deploying > wireless payment devices (CDMA/GSM). We are looking at options on where to > locate the servers that will run the backend payment gateways; we would like > the least amount of latency between the servers and the wireless networks as > possible. The wireless networks we will be deploying the devices on are: > > > Sprint PCS > For Sprint you can get a circuit to AS1239 and just take customer routes. Their PCS network is AS10507, but as far as I know the closest you can get to it is 1239. ~Seth From pde at eff.org Tue Sep 28 02:13:28 2010 From: pde at eff.org (Peter Eckersley) Date: Mon, 27 Sep 2010 19:13:28 -0700 Subject: EFF needs your help to stop the Senate's DNS censorship bill Message-ID: <20100928021328.GA22663@tapdance> As you may or may not have heard, there is a censor-DNS-to-enforce-copyright bill that is going to be passed by the Senate Judiciary Committee this Wednesday (!!!). It will require service providers to censor the DNS entries of blacklisted domains where piracy is deemed too "central" to the site's purpose. Senators are claiming that they haven't heard any opposition to this bill, and it is being sponsored by 14 of the 19 committee members. We believe it needs to be stopped, and we need your help. What EFF needs right now is sign-ons to an open letter, from the engineers who helped build the Internet in the first place. The text of our letter is below. If you agree with it and would like to sign, please send me an email at pde at eff.org, with your name and a one-line summary of what part of the Internet you have helped to design, implement, debug or run. This is URGENT. I need your sign-ons by 4:00pm, US Eastern time (1pm Pacific), tomorrow. Unfortunately, the civil liberties community has been ambushed by this bill. You can find out more details on the bill here: https://eff.org/coica --------------------------- Open letter from Internet engineers to members of the Senate Judiciary Committee: We, the undersigned, have played various parts in building a network called the Internet. We wrote and debugged the software; we defined the standards and protocols that talk over that network. Many of us invented parts of it. We're just a little proud of the social and economic benefits that our project, the Internet, has brought with it. We are writing to oppose the Committee's proposed new Internet censorship and copyright bill. If enacted, this legislation will risk fragmenting the Internet's global domain name system (DNS), create an environment of tremendous fear and uncertainty for technological innovation, and seriously harm the credibility of the United States in its role as a steward of key Internet infrastructure. In exchange for this, the bill will introduce censorship that will simultaneously be circumvented by deliberate infringers while hampering innocent parties' ability to communicate. All censorship schemes impact speech beyond the category they were intended to restrict, but this bill will be particularly egregious in that regard because it causes entire domains to vanish from the Web, not just infringing pages or files. Worse, an incredible range of useful, law-abiding sites can be blacklisted under this bill. These problems will be enough to ensure that alternative name-lookup infrastructures will come into widespread use, outside the control of US service providers but easily used by American citizens. Errors and divergences will appear between these new services and the current global DNS, and contradictory addresses will confuse browsers and frustrate the people using them. These problems will be widespread and will affect sites other than those blacklisted by the American government. The US government has regularly claimed that it supports a free and open Internet, both domestically and abroad. We can't have a free and open Internet without a global domain name system that sits above the political concerns and objectives of any one government or industry. To date, the leading role the US has played in this infrastructure has been fairly uncontroversial because America is seen as a trustworthy arbiter and a neutral bastion of free expression. If the US suddenly begins to use its central position in the DNS for censorship that advances its political and economic agenda, the consequences will be far-reaching and destructive. Senators, we believe the Internet is too important and too valuable to be endangered in this way, and implore you to put this bill aside. -- Peter Eckersley pde at eff.org Senior Staff Technologist Tel +1 415 436 9333 x131 Electronic Frontier Foundation Fax +1 415 436 9993 From nanog at deman.com Tue Sep 28 03:02:30 2010 From: nanog at deman.com (Michael DeMan) Date: Mon, 27 Sep 2010 20:02:30 -0700 Subject: Software-based Border Router In-Reply-To: References: <20100926.115921.74701327.sthaug@nethelp.no> <221425418.6450.1285496120772.JavaMail.root@mailserver> <632cd89a3c2601509f182619bcfe669a.squirrel@www.xyonet.com> Message-ID: <118F6462-3745-49DB-BD8A-59FAC100435F@deman.com> I have seen software based routers (FreeBSD+Quagga) in production at pennies on the dollar compared to Cisco for quite some years. Up front, as other people have noted, you need to know what you are doing. There is no 'crying for help 24x7'. By the same token, if you know what you are doing then they can be a very cost effective solutions. I have yet to see (or try out) MPLS and such, so if requirements need features like that, then probably open source may not be the solution. The above said, other comments inline below... On Sep 27, 2010, at 3:48 PM, Heath Jones wrote: > Do jitter sensitive applications have problems at all running? > What would you say is the point at which people should be looking for > a hardware forwarding solution? > > Differences: > - Hardware forwarding Yes, absolutely, no hardware forwarding. This must be compensated for by utilizing as advanced/expensive 'commodity PC hardware' as possible. You want lots of CPU horsepower, fast busses (PCI-E x16 if possible) and good NICs so the OS can offload as much as possible to the hardware and not be bandwidth constrained. Even then, no way are you going to get anything close to what you can from a 'real' router. A classic trade off between technical needs & desires vs. financial constraints. > - Interface options Make sure there are least two NIC platforms. i.e., a pair of onboard dual gigabit plus another dual gigabit card. Bond the interfaces between the separate NIC platforms so one each gigabit link is off say the onboard and one off the NIC card. Utilize LACP. > - Port density Use VLANs - again, a quality NIC will help with this by offloading a good portion of the overhead to hardware. > - Redundancy Use a /29 to your eBGP provider and turn up two routers side-by-side. Again, if you are looking for hard core 'carrier grade' stuff, you should not be asking about open source. Pair the two routers, for eBGP sessions, and use a separate interface for them to talk to each other. > - Power consumption Always an issue, no way are you going to get pps from this kind of stuff like you would from Cisco. > - Service Provider stuff - MPLS TE? VPLS? VRF?? Yup. > > Any others? > If somebody is on an extremely tight budget, is technically capable of doing utilizing open source to do what they need, and their requirements are limited enough that an open source platform would work for them, I would suggest they check into it. Ultimately, as always, it is buyer beware. Often with dedicated routers a support contract can cost as much as the router itself after a year or two, but sometimes companies need that support contract because they don't have the in-house skills already, etc. I would never recommend either open source or dedicated hardware routers to anybody as a 'this is the only way to go' solution. From owen at delong.com Tue Sep 28 03:29:49 2010 From: owen at delong.com (Owen DeLong) Date: Mon, 27 Sep 2010 20:29:49 -0700 Subject: Randy in Nevis In-Reply-To: <4CA0C68E.2070501@orthanc.ca> References: <86tylbtgiq.fsf@seastrom.com> <4CA0C68E.2070501@orthanc.ca> Message-ID: <3FDF6338-0C7E-49FB-B3E5-85BBD4100EC1@delong.com> On Sep 27, 2010, at 9:30 AM, Lyndon Nerenberg wrote: > On 10-09-27 7:20 AM, Robert E. Seastrom wrote: >> "Cannot establish SSL with SMTP server 67.202.37.63:465" does not >> sound like a 587 problem to me. >> >> netalyzr folks? comment? > > Sorry, I hit send too soon ... > > I've heard from a couple of people that the PIX will remap 587 (and 25) > to oddball ports if you fiddle the config just right. Given all the > other bogosity that box does with SMTP I wonder if there's truth to the > rumour. (I haven't found anyone who can reproduce this on demand, so > it's still apocryphal for now.) 465 is not an odd-ball port, it's the standard well-known port for STMPS. Fortunately, few people actually use SMTPS, preferring instead to do their security via TLS using the STARTTLS model after connecting to 25/587. Owen From vnktshsriram at gmail.com Tue Sep 28 10:09:31 2010 From: vnktshsriram at gmail.com (Venkatesh Sriram) Date: Tue, 28 Sep 2010 15:39:31 +0530 Subject: OSPFv3 Authentication In-Reply-To: References: Message-ID: While I have used MD5 with OSPFv2, I never used authentication with OSPFv3 since IPsec is (a) not available on all platforms (or/and requires a special license) and (b) requires too much of coordination with other folks to bring it up. I know operators who use authentication with ISIS for v6, but very little auth for OSPFv3.Obviously, you'll find an equal number that enthusiastically use auth with OSPFv3, so really there isnt any one right answer. Sriram On Tue, Sep 28, 2010 at 5:33 AM, Manav Bhatia wrote: > Hi, > > I am doing a survey and was interested in knowing if network operators > are using OSPFv3 with authentication [RFC 4552] turned on? I know that > most providers turn on authentication with OSPFv2, but given that > OSPFv3 needs IPsec integration and can thus get little cumbersome to > configure, wanted to understand if a similar % of folks also turn on > authentication for OSPFv3? > > You can unicast me your responses (if you dont wish to share it on the > list) and i will collate all data and post a summary on the list. > > Cheers, Manav > > From rs at seastrom.com Tue Sep 28 12:40:12 2010 From: rs at seastrom.com (Robert E. Seastrom) Date: Tue, 28 Sep 2010 08:40:12 -0400 Subject: Randy in Nevis In-Reply-To: <3FDF6338-0C7E-49FB-B3E5-85BBD4100EC1@delong.com> (Owen DeLong's message of "Mon, 27 Sep 2010 20:29:49 -0700") References: <86tylbtgiq.fsf@seastrom.com> <4CA0C68E.2070501@orthanc.ca> <3FDF6338-0C7E-49FB-B3E5-85BBD4100EC1@delong.com> Message-ID: <86tyla9h3n.fsf@seastrom.com> Owen DeLong writes: > On Sep 27, 2010, at 9:30 AM, Lyndon Nerenberg wrote: > >> On 10-09-27 7:20 AM, Robert E. Seastrom wrote: >>> "Cannot establish SSL with SMTP server 67.202.37.63:465" does not >>> sound like a 587 problem to me. >>> >>> netalyzr folks? comment? >> >> Sorry, I hit send too soon ... >> >> I've heard from a couple of people that the PIX will remap 587 (and 25) >> to oddball ports if you fiddle the config just right. Given all the >> other bogosity that box does with SMTP I wonder if there's truth to the >> rumour. (I haven't found anyone who can reproduce this on demand, so >> it's still apocryphal for now.) > > 465 is not an odd-ball port, it's the standard well-known port for STMPS. > Fortunately, few people actually use SMTPS, preferring instead to do their > security via TLS using the STARTTLS model after connecting to 25/587. That doesn't explain why the test of port 587/starttls is trying to connect to the well-known port for smtps. -r From cmaurand at xyonet.com Tue Sep 28 12:54:34 2010 From: cmaurand at xyonet.com (Curtis Maurand) Date: Tue, 28 Sep 2010 08:54:34 -0400 Subject: Software-based Border Router In-Reply-To: References: <20100926.115921.74701327.sthaug@nethelp.no> <221425418.6450.1285496120772.JavaMail.root@mailserver> <632cd89a3c2601509f182619bcfe669a.squirrel@www.xyonet.com> Message-ID: <4CA1E58A.3000104@xyonet.com> Vyatta has support contracts. If you want hardware, they've got that, too. On 9/27/2010 6:48 PM, Heath Jones wrote: > Oh, support contract!!? > >> Differences: >> - Hardware forwarding >> - Interface options >> - Port density >> - Redundancy >> - Power consumption >> - Service Provider stuff - MPLS TE? VPLS? VRF?? >> >> Any others? >> From mohacsi at niif.hu Tue Sep 28 13:15:25 2010 From: mohacsi at niif.hu (Mohacsi Janos) Date: Tue, 28 Sep 2010 15:15:25 +0200 (CEST) Subject: OSPFv3 Authentication In-Reply-To: References: Message-ID: On Tue, 28 Sep 2010, Venkatesh Sriram wrote: > While I have used MD5 with OSPFv2, I never used authentication with > OSPFv3 since IPsec is (a) not available on all platforms (or/and > requires a special license) and (b) requires too much of coordination > with other folks to bring it up. I know operators who use > authentication with ISIS for v6, but very little auth for > OSPFv3.Obviously, you'll find an equal number that enthusiastically > use auth with OSPFv3, so really there isnt any one right answer. Dear Sriram, Can you list/name the platforms does not support IPsec for OSPFv3 without special license? e.g. to avoid such a platform.... Best Regards, Janos > > Sriram > > On Tue, Sep 28, 2010 at 5:33 AM, Manav Bhatia wrote: >> Hi, >> >> I am doing a survey and was interested in knowing if network operators >> are using OSPFv3 with authentication [RFC 4552] turned on? I know that >> most providers turn on authentication with OSPFv2, but given that >> OSPFv3 needs IPsec integration and can thus get little cumbersome to >> configure, wanted to understand if a similar % of folks also turn on >> authentication for OSPFv3? >> >> You can unicast me your responses (if you dont wish to share it on the >> list) and i will collate all data and post a summary on the list. >> >> Cheers, Manav >> >> > > From jared at compuwizz.net Tue Sep 28 13:57:49 2010 From: jared at compuwizz.net (Jared Geiger) Date: Tue, 28 Sep 2010 09:57:49 -0400 Subject: Mobile Operator Connectivity In-Reply-To: <485ED9BA02629E4BBBA53AC892EDA50E0BBCB490@usmsxt104.mwd.h2o> References: <4CA0FAFD.30802@rollernet.us> <485ED9BA02629E4BBBA53AC892EDA50E0BBCB490@usmsxt104.mwd.h2o> Message-ID: I would suggest getting on the GRX network. As an enterprise you should be able to get IPX service from any number of providers. Belgacom, Syniverse, and Sybase365 all offer IP data service onto the GRX. Then you aren't limited to just the US carriers, you'll be able to reach most all carriers globally. ~Jared From jbates at brightok.net Tue Sep 28 13:58:10 2010 From: jbates at brightok.net (Jack Bates) Date: Tue, 28 Sep 2010 08:58:10 -0500 Subject: Online games stealing your bandwidth In-Reply-To: References: Message-ID: <4CA1F472.10104@brightok.net> On 9/27/2010 7:35 PM, Warren Bailey wrote: > Can someone name an ISP that encourages P2P traffic?? ;) > A proper ISP doesn't encourage any type of traffic. We're indifferent. Of course, we'll be happy to mention the benefits and draw backs of using various protocols on the Internet. Demand wise, video streaming to point and click boxes will load the network far more than p2p ever has; granted, in the opposite direction of the normal p2p complaint. My, and my company's, biggest complaint is the lack of improvement on these protocols to play more friendly with customer's other traffic. It is not so much the effects of it on my network, as much as how it effects my customer's unshared link. The "give me everything" tactic, especially on outbound traffic, saturates the link, which in turn lowers the customer's other traffic. Am I the only one who likes to stream video while running bittorrent, surfing the web, checking my email, and playing some online game all at the same time? I'm not going to rag on bittorrent, though. I do have adjustments in my clients to cap the upstream/downstream to allow my other traffic through. Many clients and protocols don't have this ability, though. Some purposefully hide themselves and what they are doing. The only indication is the fact that the "Internet is slow." The people who make this software should sit in a call center troubleshooting why "The Internet is slow!" when various software products are bandwidth hogs (and sometimes are hidden from the customer completely). We, of course, detect the link saturation, but there is no indicator for us to help the customer figure out what they need to disable. Jack From leo.vegoda at icann.org Tue Sep 28 14:49:22 2010 From: leo.vegoda at icann.org (Leo Vegoda) Date: Tue, 28 Sep 2010 07:49:22 -0700 Subject: Randy in Nevis In-Reply-To: <3FDF6338-0C7E-49FB-B3E5-85BBD4100EC1@delong.com> References: <86tylbtgiq.fsf@seastrom.com> <4CA0C68E.2070501@orthanc.ca> <3FDF6338-0C7E-49FB-B3E5-85BBD4100EC1@delong.com> Message-ID: On 27 Sep 2010, at 8:29, Owen DeLong wrote: [...] > 465 is not an odd-ball port, it's the standard well-known port for STMPS. It is? That's not what's recorded at: http://www.iana.org/assignments/port-numbers urd 465/tcp URL Rendesvous Directory for SSM igmpv3lite 465/udp IGMP over UDP for SSM Regards, Leo From sethm at rollernet.us Tue Sep 28 15:19:35 2010 From: sethm at rollernet.us (Seth Mattinen) Date: Tue, 28 Sep 2010 08:19:35 -0700 Subject: Randy in Nevis In-Reply-To: References: <86tylbtgiq.fsf@seastrom.com> <4CA0C68E.2070501@orthanc.ca> <3FDF6338-0C7E-49FB-B3E5-85BBD4100EC1@delong.com> Message-ID: <4CA20787.40906@rollernet.us> On 9/28/10 7:49 AM, Leo Vegoda wrote: > On 27 Sep 2010, at 8:29, Owen DeLong wrote: > > [...] > >> 465 is not an odd-ball port, it's the standard well-known port for STMPS. > > It is? That's not what's recorded at: http://www.iana.org/assignments/port-numbers > > urd 465/tcp URL Rendesvous Directory for SSM > igmpv3lite 465/udp IGMP over UDP for SSM > Microsoft frequently has different ideas about things. ~Seth From nathan at atlasnetworks.us Tue Sep 28 16:58:21 2010 From: nathan at atlasnetworks.us (Nathan Eisenberg) Date: Tue, 28 Sep 2010 16:58:21 +0000 Subject: Software-based Border Router In-Reply-To: <4CA1E58A.3000104@xyonet.com> References: <20100926.115921.74701327.sthaug@nethelp.no> <221425418.6450.1285496120772.JavaMail.root@mailserver> <632cd89a3c2601509f182619bcfe669a.squirrel@www.xyonet.com> <4CA1E58A.3000104@xyonet.com> Message-ID: <8C26A4FDAE599041A13EB499117D3C28405FA766@ex-mb-2.corp.atlasnetworks.us> Vyatta has hardware forwarding? Real hardware forwarding? Where? Best Regards, Nathan Eisenberg > -----Original Message----- > From: Curtis Maurand [mailto:cmaurand at xyonet.com] > Sent: Tuesday, September 28, 2010 5:55 AM > To: Heath Jones > Cc: nanog at nanog.org > Subject: Re: Software-based Border Router > > Vyatta has support contracts. If you want hardware, they've got that, too. > > > > On 9/27/2010 6:48 PM, Heath Jones wrote: > > Oh, support contract!!? > > > >> Differences: > >> - Hardware forwarding > >> - Interface options > >> - Port density > >> - Redundancy > >> - Power consumption > >> - Service Provider stuff - MPLS TE? VPLS? VRF?? > >> > >> Any others? > >> From hj1980 at gmail.com Tue Sep 28 17:11:24 2010 From: hj1980 at gmail.com (Heath Jones) Date: Tue, 28 Sep 2010 18:11:24 +0100 Subject: Software-based Border Router In-Reply-To: <8C26A4FDAE599041A13EB499117D3C28405FA766@ex-mb-2.corp.atlasnetworks.us> References: <20100926.115921.74701327.sthaug@nethelp.no> <221425418.6450.1285496120772.JavaMail.root@mailserver> <632cd89a3c2601509f182619bcfe669a.squirrel@www.xyonet.com> <4CA1E58A.3000104@xyonet.com> <8C26A4FDAE599041A13EB499117D3C28405FA766@ex-mb-2.corp.atlasnetworks.us> Message-ID: He must have meant the actual chassis/box/case... > Vyatta has hardware forwarding? ?Real hardware forwarding? ?Where? >> -----Original Message----- >> From: Curtis Maurand [mailto:cmaurand at xyonet.com] >> ? Vyatta has support contracts. ?If you want hardware, they've got that, too. From nathan at atlasnetworks.us Tue Sep 28 17:35:03 2010 From: nathan at atlasnetworks.us (Nathan Eisenberg) Date: Tue, 28 Sep 2010 17:35:03 +0000 Subject: Software-based Border Router In-Reply-To: References: <20100926.115921.74701327.sthaug@nethelp.no> <221425418.6450.1285496120772.JavaMail.root@mailserver> <632cd89a3c2601509f182619bcfe669a.squirrel@www.xyonet.com> <4CA1E58A.3000104@xyonet.com> <8C26A4FDAE599041A13EB499117D3C28405FA766@ex-mb-2.corp.atlasnetworks.us> Message-ID: <8C26A4FDAE599041A13EB499117D3C28405FA829@ex-mb-2.corp.atlasnetworks.us> Doh. Serves me right for posting BEFORE having my coffee. Though, on reflection was anyone claiming Vyatta didn't have hardware to sell you? Best Regards, Nathan Eisenberg ? > -----Original Message----- > From: Heath Jones [mailto:hj1980 at gmail.com] > Sent: Tuesday, September 28, 2010 10:11 AM > To: Nathan Eisenberg > Cc: nanog at nanog.org > Subject: Re: Software-based Border Router > > He must have meant the actual chassis/box/case... > > > Vyatta has hardware forwarding? ?Real hardware forwarding? ?Where? > > >> -----Original Message----- > >> From: Curtis Maurand [mailto:cmaurand at xyonet.com] > >> ? Vyatta has support contracts. ?If you want hardware, they've got that, > too. > > From nathan at atlasnetworks.us Tue Sep 28 17:39:33 2010 From: nathan at atlasnetworks.us (Nathan Eisenberg) Date: Tue, 28 Sep 2010 17:39:33 +0000 Subject: Randy in Nevis In-Reply-To: <4CA20787.40906@rollernet.us> References: <86tylbtgiq.fsf@seastrom.com> <4CA0C68E.2070501@orthanc.ca> <3FDF6338-0C7E-49FB-B3E5-85BBD4100EC1@delong.com> <4CA20787.40906@rollernet.us> Message-ID: <8C26A4FDAE599041A13EB499117D3C28405FA863@ex-mb-2.corp.atlasnetworks.us> > >> 465 is not an odd-ball port, it's the standard well-known port for STMPS. > > > > It is? That's not what's recorded at: > http://www.iana.org/assignments/port-numbers > > > > urd 465/tcp URL Rendesvous Directory for SSM > > igmpv3lite 465/udp IGMP over UDP for SSM > > > > Microsoft frequently has different ideas about things. > > ~Seth FWIW - 465 is widely deployed as SMTPS, in more than just MS products. I'm actually quite surprised it's not in the well known ports list. Best Regards, Nathan Eisenberg From richard.barnes at gmail.com Tue Sep 28 17:57:15 2010 From: richard.barnes at gmail.com (Richard Barnes) Date: Tue, 28 Sep 2010 13:57:15 -0400 Subject: Online games stealing your bandwidth In-Reply-To: <4CA1F472.10104@brightok.net> References: <4CA1F472.10104@brightok.net> Message-ID: BitTorrent have been active contributors to the IETF LEDBAT working group, which is looking at transport protocols that back off much more aggressively than TCP, with exactly the idea of making P2P have a lower impact on other things at the customer edge. On Tue, Sep 28, 2010 at 9:58 AM, Jack Bates wrote: > On 9/27/2010 7:35 PM, Warren Bailey wrote: >> >> Can someone name an ISP that encourages P2P traffic?? ;) >> > > A proper ISP doesn't encourage any type of traffic. We're indifferent. Of > course, we'll be happy to mention the benefits and draw backs of using > various protocols on the Internet. Demand wise, video streaming to point and > click boxes will load the network far more than p2p ever has; granted, in > the opposite direction of the normal p2p complaint. > > My, and my company's, biggest complaint is the lack of improvement on these > protocols to play more friendly with customer's other traffic. It is not so > much the effects of it on my network, as much as how it effects my > customer's unshared link. The "give me everything" tactic, especially on > outbound traffic, saturates the link, which in turn lowers the customer's > other traffic. Am I the only one who likes to stream video while running > bittorrent, surfing the web, checking my email, and playing some online game > all at the same time? > > I'm not going to rag on bittorrent, though. I do have adjustments in my > clients to cap the upstream/downstream to allow my other traffic through. > Many clients and protocols don't have this ability, though. Some > purposefully hide themselves and what they are doing. The only indication is > the fact that the "Internet is slow." The people who make this software > should sit in a call center troubleshooting why "The Internet is slow!" when > various software products are bandwidth hogs (and sometimes are hidden from > the customer completely). We, of course, detect the link saturation, but > there is no indicator for us to help the customer figure out what they need > to disable. > > > Jack > From wbailey at gci.com Tue Sep 28 18:00:48 2010 From: wbailey at gci.com (Warren Bailey) Date: Tue, 28 Sep 2010 10:00:48 -0800 Subject: Online games stealing your bandwidth In-Reply-To: <4CA1F472.10104@brightok.net> References: <4CA1F472.10104@brightok.net> Message-ID: <09F712D9B8F7AF40BE523224B2487BA10FD15911@dtn1mbx01.gci.com> Jack, Forgive me if I'm mistaken, but looking at your website - do you only offer dial up services? This could be the background for a statement like "a proper ISP doesn't encourage any type of traffic." We have a couple of OC-192 running to Seattle, so certain "types" of traffic can make a good day turn very badly without some traffic "management". -----Original Message----- From: Jack Bates [mailto:jbates at brightok.net] Sent: Tuesday, September 28, 2010 5:58 AM To: Warren Bailey Cc: Richard Barnes; NANOG Subject: Re: Online games stealing your bandwidth On 9/27/2010 7:35 PM, Warren Bailey wrote: > Can someone name an ISP that encourages P2P traffic?? ;) > A proper ISP doesn't encourage any type of traffic. We're indifferent. Of course, we'll be happy to mention the benefits and draw backs of using various protocols on the Internet. Demand wise, video streaming to point and click boxes will load the network far more than p2p ever has; granted, in the opposite direction of the normal p2p complaint. My, and my company's, biggest complaint is the lack of improvement on these protocols to play more friendly with customer's other traffic. It is not so much the effects of it on my network, as much as how it effects my customer's unshared link. The "give me everything" tactic, especially on outbound traffic, saturates the link, which in turn lowers the customer's other traffic. Am I the only one who likes to stream video while running bittorrent, surfing the web, checking my email, and playing some online game all at the same time? I'm not going to rag on bittorrent, though. I do have adjustments in my clients to cap the upstream/downstream to allow my other traffic through. Many clients and protocols don't have this ability, though. Some purposefully hide themselves and what they are doing. The only indication is the fact that the "Internet is slow." The people who make this software should sit in a call center troubleshooting why "The Internet is slow!" when various software products are bandwidth hogs (and sometimes are hidden from the customer completely). We, of course, detect the link saturation, but there is no indicator for us to help the customer figure out what they need to disable. Jack From john-nanog at johnpeach.com Tue Sep 28 18:05:11 2010 From: john-nanog at johnpeach.com (John Peach) Date: Tue, 28 Sep 2010 14:05:11 -0400 Subject: Randy in Nevis In-Reply-To: <8C26A4FDAE599041A13EB499117D3C28405FA863@ex-mb-2.corp.atlasnetworks.us> References: <86tylbtgiq.fsf@seastrom.com> <4CA0C68E.2070501@orthanc.ca> <3FDF6338-0C7E-49FB-B3E5-85BBD4100EC1@delong.com> <4CA20787.40906@rollernet.us> <8C26A4FDAE599041A13EB499117D3C28405FA863@ex-mb-2.corp.atlasnetworks.us> Message-ID: <20100928140511.77b9f1a2@jpeach-desktop> On Tue, 28 Sep 2010 17:39:33 +0000 Nathan Eisenberg wrote: > > >> 465 is not an odd-ball port, it's the standard well-known port > > >> for STMPS. > > > > > > It is? That's not what's recorded at: > > http://www.iana.org/assignments/port-numbers > > > > > > urd 465/tcp URL Rendesvous Directory for SSM > > > igmpv3lite 465/udp IGMP over UDP for SSM > > > > > > > Microsoft frequently has different ideas about things. > > > > ~Seth > > FWIW - 465 is widely deployed as SMTPS, in more than just MS > products. I'm actually quite surprised it's not in the well known > ports list. > It is on all Linux distros: ssmtp 465/tcp smtps # SMTP over SSL -- John From leo.woltz at gmail.com Tue Sep 28 18:16:14 2010 From: leo.woltz at gmail.com (Leo Woltz) Date: Tue, 28 Sep 2010 14:16:14 -0400 Subject: Mobile Operator Connectivity In-Reply-To: References: <4CA0FAFD.30802@rollernet.us> <485ED9BA02629E4BBBA53AC892EDA50E0BBCB490@usmsxt104.mwd.h2o> Message-ID: Hi Jared Is this different then the service at Equinix? Leo On Tue, Sep 28, 2010 at 9:57 AM, Jared Geiger wrote: > I would suggest getting on the GRX network. As an enterprise you > should be able to get IPX service from any number of providers. > Belgacom, Syniverse, and Sybase365 all offer IP data service onto the > GRX. Then you aren't limited to just the US carriers, you'll be able > to reach most all carriers globally. > > ~Jared > > From jbates at brightok.net Tue Sep 28 18:25:41 2010 From: jbates at brightok.net (Jack Bates) Date: Tue, 28 Sep 2010 13:25:41 -0500 Subject: Online games stealing your bandwidth In-Reply-To: <09F712D9B8F7AF40BE523224B2487BA10FD15911@dtn1mbx01.gci.com> References: <4CA1F472.10104@brightok.net> <09F712D9B8F7AF40BE523224B2487BA10FD15911@dtn1mbx01.gci.com> Message-ID: <4CA23325.30408@brightok.net> On 9/28/2010 1:00 PM, Warren Bailey wrote: > Jack, > > Forgive me if I'm mistaken, but looking at your website - do you only offer dial up services? This could be the background for a statement like "a proper ISP doesn't encourage any type of traffic." We have a couple of OC-192 running to Seattle, so certain "types" of traffic can make a good day turn very badly without some traffic "management". > BrightNet itself has ILEC's as customers. We're a turnkey glue for ILECs nearby. Among other things, I provide engineering support and advise for each ILEC. Each has their own levels of service, management, and technologies deployed including wireless, cellular, DSL, FTTH, and cable. I'm currently running around 1.2gbit between us and 4 NSP transits with 3gbit available. Some of the ILECs have additional load shifting with other transits. I estimate the need to go 10Gig ring or split transit in less than 5 years at current growth rates, and the largest problem we've run into is getting infrastructure to handle gig-e speeds out of rural ILECs for the 100+ mile longhauls. I've had issues with gig-e connectivity just getting out of OKC to enough NSP transits and it will become more difficult/expensive when we do hit 10G. As it currently stands, we usually have no problems with event spikes, though we sometimes have to tweek the traffic paths depending on how the NSPs do. The largest issues have always been the last mile. As we resolve last mile costs (which dropping 100% fiber in a rural area today doesn't have the safety nets and guarantees that were provided when copper was dropped in), we'll then have to tackle the longhaul connectivity issues, but hopefully the cost to handle that will drop as well. Jack From cb.list6 at gmail.com Tue Sep 28 18:32:40 2010 From: cb.list6 at gmail.com (Cameron Byrne) Date: Tue, 28 Sep 2010 11:32:40 -0700 Subject: Mobile Operator Connectivity In-Reply-To: References: <4CA0FAFD.30802@rollernet.us> <485ED9BA02629E4BBBA53AC892EDA50E0BBCB490@usmsxt104.mwd.h2o> Message-ID: On Tue, Sep 28, 2010 at 6:57 AM, Jared Geiger wrote: > I would suggest getting on the GRX network. As an enterprise you > should be able to get IPX service from any number of providers. > Belgacom, Syniverse, and Sybase365 all offer IP data service onto the > GRX. Then you aren't limited to just the US carriers, you'll be able > to reach most all carriers globally. Folks, GRX is for data roaming between mobile providers, not for connecting eye balls and content. Only mobile operators are members of the GRX, not customers of mobile operators or content of any sort. http://en.wikipedia.org/wiki/GPRS_Roaming_Exchange Here's an example, I am a T-Mobile USA subscriber. I travel to Canada and roam on to Rogers's network. When i start a data session on my mobile phone, Rogers passes all the data traffic back to T-Mobile via the GRX peering exchange. When in Canada, my HTTP traffic does not exit in Canada, it is tunneled back via GRX peering to T-Mobile in the USA and exit's in the USA. The roamed into network (Roger's in my example) is just an access network to reach the network that i subscriber to (T-Mobile USA). As someone else may have noted, your best best is to figure out where the mobile providers peer out on the Internet and purchase access in the same region and ISP as the mobile provider. Also, as someone else noted, some mobile providers do a lot of aggregation that adds latency, other mobile providers are more distributed and punt to the ISP closer to the user. Regards, Cameron ======== http://groups.google.com/group/tmoipv6beta ======== From wbailey at gci.com Tue Sep 28 19:01:57 2010 From: wbailey at gci.com (Warren Bailey) Date: Tue, 28 Sep 2010 11:01:57 -0800 Subject: Online games stealing your bandwidth In-Reply-To: <4CA23325.30408@brightok.net> References: <4CA1F472.10104@brightok.net> <09F712D9B8F7AF40BE523224B2487BA10FD15911@dtn1mbx01.gci.com> <4CA23325.30408@brightok.net> Message-ID: <09F712D9B8F7AF40BE523224B2487BA10FE2373A@dtn1mbx01.gci.com> Jack, Apologies, I did not realize that you guys were doing so much. Please don't take my last email as anything which was intended to question or insult you guys. Up here (Alaska) we have about 100,000 cable subscribers along with mixed Fiber/DSL/POTS access and nearly 50,000 cellular customers with high speed data around our Metro network. I am an RF Engineer, however the network I run is IP based (satellite) and I run in the neighborhood of 250mbps forward and 30mbps return to most of the State of Alaska. I find that anywhere from 40-65% of our total traffic is "questionable", which is why I was asking about an ISP who liked their users downloading torrents. It is very difficult to gauge a users behavior if they are on an "all out" downloading binge over a weekend. Normally, a user logs in and does what they need to in a relatively short amount of time (hours). In the case of most providers, we oversubscribe our resources and have found this model is beginning to not apply to user behavior changes. Long gone are the days of the user turning off their computers, and our customer base (rural Alaska) have few things to do besides use the internet. This has made a "perfect storm" of sorts, as we are now seeing most of our users utilizing 70%+ of their allocated (purchased) bandwidth 24 hours a day. The vast majority of the night use is gaming, and bit torrent. It makes things much more complicated when trying to give an experience to people.. //warren -----Original Message----- From: Jack Bates [mailto:jbates at brightok.net] Sent: Tuesday, September 28, 2010 10:26 AM To: Warren Bailey Cc: Richard Barnes; NANOG Subject: Re: Online games stealing your bandwidth On 9/28/2010 1:00 PM, Warren Bailey wrote: > Jack, > > Forgive me if I'm mistaken, but looking at your website - do you only offer dial up services? This could be the background for a statement like "a proper ISP doesn't encourage any type of traffic." We have a couple of OC-192 running to Seattle, so certain "types" of traffic can make a good day turn very badly without some traffic "management". > BrightNet itself has ILEC's as customers. We're a turnkey glue for ILECs nearby. Among other things, I provide engineering support and advise for each ILEC. Each has their own levels of service, management, and technologies deployed including wireless, cellular, DSL, FTTH, and cable. I'm currently running around 1.2gbit between us and 4 NSP transits with 3gbit available. Some of the ILECs have additional load shifting with other transits. I estimate the need to go 10Gig ring or split transit in less than 5 years at current growth rates, and the largest problem we've run into is getting infrastructure to handle gig-e speeds out of rural ILECs for the 100+ mile longhauls. I've had issues with gig-e connectivity just getting out of OKC to enough NSP transits and it will become more difficult/expensive when we do hit 10G. As it currently stands, we usually have no problems with event spikes, though we sometimes have to tweek the traffic paths depending on how the NSPs do. The largest issues have always been the last mile. As we resolve last mile costs (which dropping 100% fiber in a rural area today doesn't have the safety nets and guarantees that were provided when copper was dropped in), we'll then have to tackle the longhaul connectivity issues, but hopefully the cost to handle that will drop as well. Jack From rfg at tristatelogic.com Tue Sep 28 19:21:43 2010 From: rfg at tristatelogic.com (Ronald F. Guilmette) Date: Tue, 28 Sep 2010 12:21:43 -0700 Subject: AS11296 -- Hijacked? Message-ID: <63619.1285701703@tristatelogic.com> Evidence strongly suggests that AS11296 together with all of the IPv4 space it is currently announcing routes for, i.e.: 63.247.160.0/19 199.241.64.0/19 206.226.64.0/24 206.226.65.0/24 206.226.66.0/24 206.226.67.0/24 206.226.68.0/24 206.226.69.0/24 206.226.70.0/24 206.226.71.0/24 206.226.72.0/24 206.226.73.0/24 206.226.74.0/24 206.226.75.0/24 206.226.76.0/24 206.226.77.0/24 206.226.78.0/24 206.226.79.0/24 206.226.96.0/19 have all been hijacked. I will be reporting this formally to ARIN today, via their helpful fraud reporting web form. In the meantime, while this case is being carefully adjudicated by ARIN, some folks may wish to blackhole the above. (The IP space appears to be in use by some sort of snowshoe spamming operation.) Regards, rfg P.S. Connectivity for AS11296 appears to come from only one place: http://www.robtex.com/as/as11296.html#graph From mhernand1 at comcast.net Tue Sep 28 19:22:18 2010 From: mhernand1 at comcast.net (manolo hernandez) Date: Tue, 28 Sep 2010 15:22:18 -0400 Subject: Online games stealing your bandwidth In-Reply-To: <09F712D9B8F7AF40BE523224B2487BA10FE2373A@dtn1mbx01.gci.com> References: <4CA1F472.10104@brightok.net> <09F712D9B8F7AF40BE523224B2487BA10FD15911@dtn1mbx01.gci.com> <4CA23325.30408@brightok.net> <09F712D9B8F7AF40BE523224B2487BA10FE2373A@dtn1mbx01.gci.com> Message-ID: <4CA2406A.6080702@comcast.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 9/28/10 3:01 PM, Warren Bailey wrote: > Jack, > > Apologies, I did not realize that you guys were doing so much. Please don't take my last email as anything which was intended to question or insult you guys. Up here (Alaska) we have about 100,000 cable subscribers along with mixed Fiber/DSL/POTS access and nearly 50,000 cellular customers with high speed data around our Metro network. I am an RF Engineer, however the network I run is IP based (satellite) and I run in the neighborhood of 250mbps forward and 30mbps return to most of the State of Alaska. I find that anywhere from 40-65% of our total traffic is "questionable", which is why I was asking about an ISP who liked their users downloading torrents. It is very difficult to gauge a users behavior if they are on an "all out" downloading binge over a weekend. Normally, a user logs in and does what they need to in a relatively short amount of time (hours). In the case of most providers, we oversubscribe our resources and have found this model is beginning to not apply to user behavior changes. Long gone are the days of the user turning off their computers, and our customer base (rural Alaska) have few things to do besides use the internet. This has made a "perfect storm" of sorts, as we are now seeing most of our users utilizing 70%+ of their allocated (purchased) bandwidth 24 hours a day. The vast majority of the night use is gaming, and bit torrent. It makes things much more complicated when trying to give an experience to people.. > > //warren > > -----Original Message----- > From: Jack Bates [mailto:jbates at brightok.net] > Sent: Tuesday, September 28, 2010 10:26 AM > To: Warren Bailey > Cc: Richard Barnes; NANOG > Subject: Re: Online games stealing your bandwidth > > On 9/28/2010 1:00 PM, Warren Bailey wrote: >> Jack, >> >> Forgive me if I'm mistaken, but looking at your website - do you only offer dial up services? This could be the background for a statement like "a proper ISP doesn't encourage any type of traffic." We have a couple of OC-192 running to Seattle, so certain "types" of traffic can make a good day turn very badly without some traffic "management". >> > > BrightNet itself has ILEC's as customers. We're a turnkey glue for ILECs > nearby. Among other things, I provide engineering support and advise for > each ILEC. Each has their own levels of service, management, and > technologies deployed including wireless, cellular, DSL, FTTH, and > cable. I'm currently running around 1.2gbit between us and 4 NSP > transits with 3gbit available. Some of the ILECs have additional load > shifting with other transits. I estimate the need to go 10Gig ring or > split transit in less than 5 years at current growth rates, and the > largest problem we've run into is getting infrastructure to handle gig-e > speeds out of rural ILECs for the 100+ mile longhauls. I've had issues > with gig-e connectivity just getting out of OKC to enough NSP transits > and it will become more difficult/expensive when we do hit 10G. > > As it currently stands, we usually have no problems with event spikes, > though we sometimes have to tweek the traffic paths depending on how the > NSPs do. The largest issues have always been the last mile. As we > resolve last mile costs (which dropping 100% fiber in a rural area today > doesn't have the safety nets and guarantees that were provided when > copper was dropped in), we'll then have to tackle the longhaul > connectivity issues, but hopefully the cost to handle that will drop as > well. > > > Jack > > What is keeping your company from buying more bandwidth? I find the excuse of over subscription to be a fail. If that's your companies business model then it should not be whining when people are using what you sell them. Provision bandwidth accordingly and stop being cheap and squeezing every last dime from the end user for bandwidth that can be had for less than the price of a burger in some places. Manny -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.12 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJMokBqAAoJEOcnyWxdB1IrGBMH/RCg7zy3L171hwGuilZHRWyA 9B4k+DoTF0Cp8Gt30zamKly90BERKiilryyhxSpAtepUa4wQs4bOGwk5HKx06jkF YJokQpqmNNmY4MU/bwWtUpkjrQjYT6Dt8967iEA3SWBbqdUhRdyejFLaZbDoV43u 61NzEU/JGdxnRvO/MkleP95/+XPCWuQy0EIDAuwlwcWIzr/i9ra9nD5Nf6x9AE/u XTJoTLwY6y2xP93gTBp12MBmzf07AkPxwvpMAbcYIu+94O/twbpWysuceC3EH2bW cMKLPAIROxZaropgSSJYSu8hFNPWlODkOD7MHiY8Ilcv6B4v7XEa6QpCd/lfDxE= =ZPwF -----END PGP SIGNATURE----- From hj1980 at gmail.com Tue Sep 28 19:49:12 2010 From: hj1980 at gmail.com (Heath Jones) Date: Tue, 28 Sep 2010 20:49:12 +0100 Subject: AS11296 -- Hijacked? In-Reply-To: <63619.1285701703@tristatelogic.com> References: <63619.1285701703@tristatelogic.com> Message-ID: Out of curiosity, what led you to this conclusion? > Evidence strongly suggests that AS11296 together with all of the IPv4 > space it is currently announcing routes for, i.e.: > have all been hijacked. ?I will be reporting this formally to ARIN today, > via their helpful fraud reporting web form. From jason.iannone at gmail.com Tue Sep 28 19:49:33 2010 From: jason.iannone at gmail.com (Jason Iannone) Date: Tue, 28 Sep 2010 13:49:33 -0600 Subject: Online games stealing your bandwidth In-Reply-To: <4CA2406A.6080702@comcast.net> References: <4CA1F472.10104@brightok.net> <09F712D9B8F7AF40BE523224B2487BA10FD15911@dtn1mbx01.gci.com> <4CA23325.30408@brightok.net> <09F712D9B8F7AF40BE523224B2487BA10FE2373A@dtn1mbx01.gci.com> <4CA2406A.6080702@comcast.net> Message-ID: In my experience users aren't willing to pay for dedicated bandwidth. On Tue, Sep 28, 2010 at 1:22 PM, manolo hernandez wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 9/28/10 3:01 PM, Warren Bailey wrote: >> Jack, >> >> Apologies, I did not realize that you guys were doing so much. Please don't take my last email as anything which was intended to question or insult you guys. Up here (Alaska) we have about 100,000 cable subscribers along with mixed Fiber/DSL/POTS access and nearly 50,000 cellular customers with high speed data around our Metro network. I am an RF Engineer, however the network I run is IP based (satellite) and I run in the neighborhood of 250mbps forward and 30mbps return to most of the State of Alaska. I find that anywhere from 40-65% of our total traffic is "questionable", which is why I was asking about an ISP who liked their users downloading torrents. It is very difficult to gauge a users behavior if they are on an "all out" downloading binge over a weekend. Normally, a user logs in and does what they need to in a relatively short amount of time (hours). In the case of most providers, we oversubscribe our resources and have found this model is beginning to not apply to > user behavior changes. Long gone are the days of the user turning off their computers, and our customer base (rural Alaska) have few things to do besides use the internet. This has made a "perfect storm" of sorts, as we are now seeing most of our users utilizing 70%+ of their allocated (purchased) bandwidth 24 hours a day. The vast majority of the night use is gaming, and bit torrent. It makes things much more complicated when trying to give an experience to people.. >> >> //warren >> >> -----Original Message----- >> From: Jack Bates [mailto:jbates at brightok.net] >> Sent: Tuesday, September 28, 2010 10:26 AM >> To: Warren Bailey >> Cc: Richard Barnes; NANOG >> Subject: Re: Online games stealing your bandwidth >> >> On 9/28/2010 1:00 PM, Warren Bailey wrote: >>> Jack, >>> >>> Forgive me if I'm mistaken, but looking at your website - do you only offer dial up services? This could be the background for a statement like "a proper ISP doesn't encourage any type of traffic." We have a couple of OC-192 running to Seattle, so certain "types" of traffic can make a good day turn very badly without some traffic "management". >>> >> >> BrightNet itself has ILEC's as customers. We're a turnkey glue for ILECs >> nearby. Among other things, I provide engineering support and advise for >> each ILEC. Each has their own levels of service, management, and >> technologies deployed including wireless, cellular, DSL, FTTH, and >> cable. I'm currently running around 1.2gbit between us and 4 NSP >> transits with 3gbit available. Some of the ILECs have additional load >> shifting with other transits. I estimate the need to go 10Gig ring or >> split transit in less than 5 years at current growth rates, and the >> largest problem we've run into is getting infrastructure to handle gig-e >> speeds out of rural ILECs for the 100+ mile longhauls. I've had issues >> with gig-e connectivity just getting out of OKC to enough NSP transits >> and it will become more difficult/expensive when we do hit 10G. >> >> As it currently stands, we usually have no problems with event spikes, >> though we sometimes have to tweek the traffic paths depending on how the >> NSPs do. The largest issues have always been the last mile. As we >> resolve last mile costs (which dropping 100% fiber in a rural area today >> doesn't have the safety nets and guarantees that were provided when >> copper was dropped in), we'll then have to tackle the longhaul >> connectivity issues, but hopefully the cost to handle that will drop as >> well. >> >> >> Jack >> >> > What is keeping your company from buying more bandwidth? I find the > excuse of over subscription to be a fail. If that's your companies > business model then it should not be whining when people are using what > you sell them. Provision bandwidth accordingly and stop being cheap and > squeezing every last dime from the end user for bandwidth that can be > had for less than the price of a burger in some places. > > > > Manny > -----BEGIN PGP SIGNATURE----- > Version: GnuPG/MacGPG2 v2.0.12 (Darwin) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iQEcBAEBAgAGBQJMokBqAAoJEOcnyWxdB1IrGBMH/RCg7zy3L171hwGuilZHRWyA > 9B4k+DoTF0Cp8Gt30zamKly90BERKiilryyhxSpAtepUa4wQs4bOGwk5HKx06jkF > YJokQpqmNNmY4MU/bwWtUpkjrQjYT6Dt8967iEA3SWBbqdUhRdyejFLaZbDoV43u > 61NzEU/JGdxnRvO/MkleP95/+XPCWuQy0EIDAuwlwcWIzr/i9ra9nD5Nf6x9AE/u > XTJoTLwY6y2xP93gTBp12MBmzf07AkPxwvpMAbcYIu+94O/twbpWysuceC3EH2bW > cMKLPAIROxZaropgSSJYSu8hFNPWlODkOD7MHiY8Ilcv6B4v7XEa6QpCd/lfDxE= > =ZPwF > -----END PGP SIGNATURE----- > > From nathan at atlasnetworks.us Tue Sep 28 20:02:16 2010 From: nathan at atlasnetworks.us (Nathan Eisenberg) Date: Tue, 28 Sep 2010 20:02:16 +0000 Subject: Online games stealing your bandwidth In-Reply-To: References: <4CA1F472.10104@brightok.net> <09F712D9B8F7AF40BE523224B2487BA10FD15911@dtn1mbx01.gci.com> <4CA23325.30408@brightok.net> <09F712D9B8F7AF40BE523224B2487BA10FE2373A@dtn1mbx01.gci.com> <4CA2406A.6080702@comcast.net> Message-ID: <8C26A4FDAE599041A13EB499117D3C28405FAA78@ex-mb-2.corp.atlasnetworks.us> > -----Original Message----- > From: Jason Iannone [mailto:jason.iannone at gmail.com] > Sent: Tuesday, September 28, 2010 12:50 PM > To: manolo hernandez > Cc: nanog at nanog.org > Subject: Re: Online games stealing your bandwidth > > In my experience users aren't willing to pay for dedicated bandwidth. That's not the point. The point is that if your users are using the net available bandwidth, it's time to add more bandwidth, not to mess with your users' traffic. 'Dedicated' has nothing to do with it. Best Regards, Nathan Eisenberg From hj1980 at gmail.com Tue Sep 28 20:05:58 2010 From: hj1980 at gmail.com (Heath Jones) Date: Tue, 28 Sep 2010 21:05:58 +0100 Subject: AS11296 -- Hijacked? Message-ID: He blocked google mail? WTF? ---------- Forwarded message ---------- From: Mail Delivery Subsystem Date: 28 September 2010 20:49 Subject: Delivery Status Notification (Failure) To: hj1980 at gmail.com Delivery to the following recipient failed permanently: ? ? rfg at tristatelogic.com Technical details of permanent failure: Google tried to deliver your message, but it was rejected by the recipient domain. We recommend contacting the other email provider for further information about the cause of this error. The error that the other server returned was: 550 550 5.7.1 : Client host rejected: Domain google.com BLACKLISTED - Use http://www.tristatelogic.com/contact.html (state 14). ----- Original message ----- MIME-Version: 1.0 Received: by 10.224.62.217 with SMTP id y25mr308053qah.193.1285703359508; Tue, ?28 Sep 2010 12:49:19 -0700 (PDT) Received: by 10.229.226.204 with HTTP; Tue, 28 Sep 2010 12:49:12 -0700 (PDT) In-Reply-To: <63619.1285701703 at tristatelogic.com> References: <63619.1285701703 at tristatelogic.com> Date: Tue, 28 Sep 2010 20:49:12 +0100 Message-ID: Subject: Re: AS11296 -- Hijacked? From: Heath Jones To: "Ronald F. Guilmette" Cc: nanog at nanog.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Out of curiosity, what led you to this conclusion? > Evidence strongly suggests that AS11296 together with all of the IPv4 > space it is currently announcing routes for, i.e.: > have all been hijacked. ?I will be reporting this formally to ARIN today, > via their helpful fraud reporting web form. From owen at delong.com Tue Sep 28 20:11:32 2010 From: owen at delong.com (Owen DeLong) Date: Tue, 28 Sep 2010 13:11:32 -0700 Subject: Randy in Nevis In-Reply-To: References: <86tylbtgiq.fsf@seastrom.com> <4CA0C68E.2070501@orthanc.ca> <3FDF6338-0C7E-49FB-B3E5-85BBD4100EC1@delong.com> Message-ID: Whether recorded with IANA or not, it certainly is what you will find if you google: smtp ssl port It's also what just about every MUA and MTA I've seen expects for that purpose. Owen On Sep 28, 2010, at 7:49 AM, Leo Vegoda wrote: > On 27 Sep 2010, at 8:29, Owen DeLong wrote: > > [...] > >> 465 is not an odd-ball port, it's the standard well-known port for STMPS. > > It is? That's not what's recorded at: http://www.iana.org/assignments/port-numbers > > urd 465/tcp URL Rendesvous Directory for SSM > igmpv3lite 465/udp IGMP over UDP for SSM > > Regards, > > Leo From erik_list at caneris.com Tue Sep 28 20:15:09 2010 From: erik_list at caneris.com (Erik L) Date: Tue, 28 Sep 2010 16:15:09 -0400 (EDT) Subject: What must one do to avoid Gmail's retarded non-spam filtering? In-Reply-To: <7040875.28.1285704814582.JavaMail.root@zimbra.caneris.com> Message-ID: <22257558.30.1285704909402.JavaMail.root@zimbra.caneris.com> I realize that this is somewhat OT, but I'm sure that others on the list encounter the same issues and that at least some folks might have useful comments. An increasingly large number of our customers are using Gmail or Google Apps and almost all of our OSS/BSS mail is getting spam filtered by Google. Among others, these e-mails include invoices, order confirmations, payment notifications, customer portal logins, and tickets. Almost anything we send to customers on Google ends up in their spam folder. This results in a lot of calls and makes much of our automation pointless, never mind all the lost sales. The problem is compounded by those who use mail clients and do not log in to the webmail at all, since they would never see the contents of the Google spam folder. We have proper A+PTR records on the edge MTAs, proper SPF records for the originating domain, proper Return-Path and other headers, and so on. There isn't anything that I can think of other than the content itself which would be abnormal, and obviously the content is repetitive and can't be changed much. Is there something obvious which we've missed? Aside from the following clearly impractical solutions, what can we do? 1. Asking everyone (including those we don't even know yet) to whitelist all of our addresses, to check their spam folders, and to click on "this is not spam" 2. Providing our own free e-mail service to everyone (including those we don't even know yet) and putting up "don't use Google" ads on all of our customer-facing systems At least this isn't Hotmail where mail is just silently deleted with no NDR after it's accepted by their MTAs. The call volume has been going up instead of down lately and it's gotten to the point where we're sending MTA log extracts to people to prove to them that we really did e-mail them. Would greatly appreciate any advice. Erik From khatfield at socllc.net Tue Sep 28 20:19:21 2010 From: khatfield at socllc.net (khatfield at socllc.net) Date: Tue, 28 Sep 2010 16:19:21 -0400 (EDT) Subject: =?UTF-8?Q?Re:=20AS11296=20--=20Hijacked=3F?= In-Reply-To: References: Message-ID: <1285705161.082820940@192.168.2.228> Now that's some paranoia ;) -----Original Message----- From: "Heath Jones" Sent: Tuesday, September 28, 2010 4:05pm To: nanog at nanog.org Subject: Re: AS11296 -- Hijacked? He blocked google mail? WTF? ---------- Forwarded message ---------- From: Mail Delivery Subsystem Date: 28 September 2010 20:49 Subject: Delivery Status Notification (Failure) To: hj1980 at gmail.com Delivery to the following recipient failed permanently: ? ? rfg at tristatelogic.com Technical details of permanent failure: Google tried to deliver your message, but it was rejected by the recipient domain. We recommend contacting the other email provider for further information about the cause of this error. The error that the other server returned was: 550 550 5.7.1 : Client host rejected: Domain google.com BLACKLISTED - Use http://www.tristatelogic.com/contact.html (state 14). ----- Original message ----- MIME-Version: 1.0 Received: by 10.224.62.217 with SMTP id y25mr308053qah.193.1285703359508; Tue, ?28 Sep 2010 12:49:19 -0700 (PDT) Received: by 10.229.226.204 with HTTP; Tue, 28 Sep 2010 12:49:12 -0700 (PDT) In-Reply-To: <63619.1285701703 at tristatelogic.com> References: <63619.1285701703 at tristatelogic.com> Date: Tue, 28 Sep 2010 20:49:12 +0100 Message-ID: Subject: Re: AS11296 -- Hijacked? From: Heath Jones To: "Ronald F. Guilmette" Cc: nanog at nanog.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Out of curiosity, what led you to this conclusion? > Evidence strongly suggests that AS11296 together with all of the IPv4 > space it is currently announcing routes for, i.e.: > have all been hijacked. ?I will be reporting this formally to ARIN today, > via their helpful fraud reporting web form. From jbates at brightok.net Tue Sep 28 20:20:00 2010 From: jbates at brightok.net (Jack Bates) Date: Tue, 28 Sep 2010 15:20:00 -0500 Subject: Online games stealing your bandwidth In-Reply-To: <4CA2406A.6080702@comcast.net> References: <4CA1F472.10104@brightok.net> <09F712D9B8F7AF40BE523224B2487BA10FD15911@dtn1mbx01.gci.com> <4CA23325.30408@brightok.net> <09F712D9B8F7AF40BE523224B2487BA10FE2373A@dtn1mbx01.gci.com> <4CA2406A.6080702@comcast.net> Message-ID: <4CA24DF0.4080002@brightok.net> On 9/28/2010 2:22 PM, manolo hernandez wrote: > What is keeping your company from buying more bandwidth? I find the > excuse of over subscription to be a fail. If that's your companies > business model then it should not be whining when people are using what > you sell them. Provision bandwidth accordingly and stop being cheap and > squeezing every last dime from the end user for bandwidth that can be > had for less than the price of a burger in some places. > You replied to him but under my quoted text, so I'm not sure who you were referring to. However, my company has issues in buying long haul. Bandwidth is cheap, yes. Getting a circuit is not. Currently I have 1 option for a 10Gig circuit if I needed it today. That's not very redundant. It took 6 months to get facility upgrades by a large NSP to give me 1gig-e in OKC from DFW (very few NSPs have routers or high speed facilities in Oklahoma and even fewer in OKC. Tulsa has a few extra options). I'm still waiting on what looks like it'll be 1 year+ for a gig-e from another NSP. Going to remote ILEC towns, there's shortages of long haul facilities (in some areas, a single OC-12 sonet run is all that exists and it's dropped off in 3-5 places to various other companies on the way to the ILEC, and the fiber dwindles to 6 meaning primary pair, secondary pair, and backup dark pair is all that exists). The cost to bore new fiber and light it is extremely prohibitive. We actually have no problems with people using what we sell, and we still have nice oversell margins which makes up our profit (0% oversell would be roughly break even). Many of our problems aren't with users using their bandwidth, but with applications screwing with the user's bandwidth (against the user's will). Someone linked bittorrent's work on latency based fallback for congestion control. I think that is an awesome piece of work. However, not all p2p applications do this, and some even install and work in the background without customers knowing. This gives the perception to the customer that things are slow and not working right. We care what our customer's think, so we absolutely hate such products as we can see the bandwidth usage itself, but helping a computer illiterate customer fix the problem without them spending money at a computer tech is difficult at best. Jack From bill at herrin.us Tue Sep 28 20:44:24 2010 From: bill at herrin.us (William Herrin) Date: Tue, 28 Sep 2010 16:44:24 -0400 Subject: What must one do to avoid Gmail's retarded non-spam filtering? In-Reply-To: <22257558.30.1285704909402.JavaMail.root@zimbra.caneris.com> References: <7040875.28.1285704814582.JavaMail.root@zimbra.caneris.com> <22257558.30.1285704909402.JavaMail.root@zimbra.caneris.com> Message-ID: On Tue, Sep 28, 2010 at 4:15 PM, Erik L wrote: > An increasingly large number of our customers are using > Gmail or Google Apps and almost all of our OSS/BSS mail > is getting spam filtered by Google. Among others, these > e-mails include invoices, order confirmations, payment > notifications, customer portal logins, and tickets. Almost > anything we send to customers on Google ends up in their > spam folder. Erik, Do you send marketing information to your customers from the same IP addresses as you send your invoices? Have you checked the source IPs against the RBLs with, e.g. http://rbls.org/? What about the source IP of the specific machine the originates the invoices et. al? Is the invoicing machine also in SPF? One of the companies I do business with accidentally excluded their billing mailer from the SPF record. Have you sent copies of the various types of documents to a mail server running Spam Assassin in order to see which qualms Spam Assassin flags? Careless mistakes with the headers or the clock can get your message flagged as spam. Even something as simple as ALL CAPS can get you flagged. Have you added your invoicing mailer, the one you can guarantee sends no marketing materials, in to the whitelist at http://www.dnswl.org/? Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From nenolod at systeminplace.net Tue Sep 28 22:06:49 2010 From: nenolod at systeminplace.net (William Pitcock) Date: Tue, 28 Sep 2010 17:06:49 -0500 Subject: What must one do to avoid Gmail's retarded non-spam filtering? In-Reply-To: <22257558.30.1285704909402.JavaMail.root@zimbra.caneris.com> References: <22257558.30.1285704909402.JavaMail.root@zimbra.caneris.com> Message-ID: <1285711609.29882.9.camel@petrie.dereferenced.org> Hi, Have you checked the IronPort reputation scores for your mailserver IPs? Google uses this data as part of it's spam detection method. William On Tue, 2010-09-28 at 16:15 -0400, Erik L wrote: > I realize that this is somewhat OT, but I'm sure that others on the list encounter the same issues and that at least some folks might have useful comments. > > An increasingly large number of our customers are using Gmail or Google Apps and almost all of our OSS/BSS mail is getting spam filtered by Google. Among others, these e-mails include invoices, order confirmations, payment notifications, customer portal logins, and tickets. Almost anything we send to customers on Google ends up in their spam folder. This results in a lot of calls and makes much of our automation pointless, never mind all the lost sales. > > The problem is compounded by those who use mail clients and do not log in to the webmail at all, since they would never see the contents of the Google spam folder. > > We have proper A+PTR records on the edge MTAs, proper SPF records for the originating domain, proper Return-Path and other headers, and so on. There isn't anything that I can think of other than the content itself which would be abnormal, and obviously the content is repetitive and can't be changed much. Is there something obvious which we've missed? > > Aside from the following clearly impractical solutions, what can we do? > 1. Asking everyone (including those we don't even know yet) to whitelist all of our addresses, to check their spam folders, and to click on "this is not spam" > 2. Providing our own free e-mail service to everyone (including those we don't even know yet) and putting up "don't use Google" ads on all of our customer-facing systems > > At least this isn't Hotmail where mail is just silently deleted with no NDR after it's accepted by their MTAs. > > The call volume has been going up instead of down lately and it's gotten to the point where we're sending MTA log extracts to people to prove to them that we really did e-mail them. > > Would greatly appreciate any advice. > > Erik > From job at instituut.net Tue Sep 28 22:13:35 2010 From: job at instituut.net (Job W. J. Snijders) Date: Wed, 29 Sep 2010 00:13:35 +0200 Subject: LISP Works - Re: Facebook Issues/Outage in Southeast? In-Reply-To: References: <20100923173347.1E6D67EA@resin06.mta.everyone.net> Message-ID: <1E9490CA-3AC3-43DD-AE46-051927DE4C86@instituut.net> Hi Cameron, On 24 sep 2010, at 02:56, Cameron Byrne wrote: > On Thu, Sep 23, 2010 at 5:33 PM, Scott Weeks wrote: >> On Sep 23, 2010, at 5:50 PM, "Scott Weeks" wrote: >>> --- jared at puck.nether.net wrote: >> >>> It's working over LISP: >>> >>> http://www.lisp4.facebook.com/ >>> ------------------------------------- >> Wow, that's cool. I didn't know LISP had progressed that far... Yes, LISP is good for you! :-) > I would have to agree, i am surprised that there is a single Cisco > 3800 series router running test code of LISP at any content > provider.... which is all this is. Facebook made it clear that LISP > was an experiment, not a technology direction. I don't think this > example represents anything in particular. As a network operator, i > am afraid LISP is going to turn into the next 6to4 .. an interesting > idea that causes more harm than good. Sorry to the fans of 6to4 and > LISP, i just long for the day when real IPv6 restores the real e2e > internet without strange trickery along the way. There is a huge difference between using LISP and 6to4 that you're not considering here. 6to4 was specifically invented to solve the particular problem of IPv6/IPv4 transition. That is its sole purpose for existence. LISP was not invented to solve this problem - it was invented to address a much broader set of problems that neither IPv4 or IPv6 address (e.g. overloaded address semantics, multi-homing simplicity, IP mobility, and address portability). The fact that LISP does help in IPv6 Transition solutions (due to its inherent AF agnostic design), is compelling. As you say, real edge 2 edge is the goal - and LISP helps here, regardless of the AF. (you'll will still want to do multi-homing in IPv6, and ingress TE, and mobility, etc.). So it won't have the the same fate as 6to4. Kind regards, Job Snijders From wbailey at gci.com Tue Sep 28 23:10:23 2010 From: wbailey at gci.com (Warren Bailey) Date: Tue, 28 Sep 2010 15:10:23 -0800 Subject: Online games stealing your bandwidth In-Reply-To: <4CA24DF0.4080002@brightok.net> References: <4CA1F472.10104@brightok.net> <09F712D9B8F7AF40BE523224B2487BA10FD15911@dtn1mbx01.gci.com> <4CA23325.30408@brightok.net> <09F712D9B8F7AF40BE523224B2487BA10FE2373A@dtn1mbx01.gci.com> <4CA2406A.6080702@comcast.net> <4CA24DF0.4080002@brightok.net> Message-ID: <09F712D9B8F7AF40BE523224B2487BA10FE238EB@dtn1mbx01.gci.com> Our excuse? We have purchased every available transponder on every spacecraft suitable for transmission out of Alaska. Granted, there are additional spacecraft out there with Alaska footprints. We however, being a service provider, are interested in space segment which gives us quality over quantity. Sometimes fiber just isn't an option. So that burger analogy doesn't quite apply here .. because the burger is 100mbps, it space segment alone is 150k a month. Not to mention the modems (and remote people who admin them) in the neighborhood of 140k each side of the link. Plus, the diesel used to provide power to the Earth station (9$ a gallon) so it can transmit. Expensive happy meal. -----Original Message----- From: Jack Bates [mailto:jbates at brightok.net] Sent: Tuesday, September 28, 2010 12:20 PM To: manolo hernandez Cc: nanog at nanog.org Subject: Re: Online games stealing your bandwidth On 9/28/2010 2:22 PM, manolo hernandez wrote: > What is keeping your company from buying more bandwidth? I find the > excuse of over subscription to be a fail. If that's your companies > business model then it should not be whining when people are using what > you sell them. Provision bandwidth accordingly and stop being cheap and > squeezing every last dime from the end user for bandwidth that can be > had for less than the price of a burger in some places. > You replied to him but under my quoted text, so I'm not sure who you were referring to. However, my company has issues in buying long haul. Bandwidth is cheap, yes. Getting a circuit is not. Currently I have 1 option for a 10Gig circuit if I needed it today. That's not very redundant. It took 6 months to get facility upgrades by a large NSP to give me 1gig-e in OKC from DFW (very few NSPs have routers or high speed facilities in Oklahoma and even fewer in OKC. Tulsa has a few extra options). I'm still waiting on what looks like it'll be 1 year+ for a gig-e from another NSP. Going to remote ILEC towns, there's shortages of long haul facilities (in some areas, a single OC-12 sonet run is all that exists and it's dropped off in 3-5 places to various other companies on the way to the ILEC, and the fiber dwindles to 6 meaning primary pair, secondary pair, and backup dark pair is all that exists). The cost to bore new fiber and light it is extremely prohibitive. We actually have no problems with people using what we sell, and we still have nice oversell margins which makes up our profit (0% oversell would be roughly break even). Many of our problems aren't with users using their bandwidth, but with applications screwing with the user's bandwidth (against the user's will). Someone linked bittorrent's work on latency based fallback for congestion control. I think that is an awesome piece of work. However, not all p2p applications do this, and some even install and work in the background without customers knowing. This gives the perception to the customer that things are slow and not working right. We care what our customer's think, so we absolutely hate such products as we can see the bandwidth usage itself, but helping a computer illiterate customer fix the problem without them spending money at a computer tech is difficult at best. Jack From erik_list at caneris.com Tue Sep 28 23:16:14 2010 From: erik_list at caneris.com (Erik L) Date: Tue, 28 Sep 2010 19:16:14 -0400 (EDT) Subject: What must one do to avoid Gmail's retarded non-spam filtering? In-Reply-To: Message-ID: <14393847.0.1285715774095.JavaMail.root@zimbra.caneris.com> Bill, Thanks for the response and excellent ideas. The OSS/BSS box is in our internal network with a RFC1918 address and it relays to outside via another box which sits in the DMZ and which is in SPF records for the domain that appears in From/Return-Path, etc. That DMZ machine does not appear on RBLs nor is it whitelisted anywhere. Google adds headers like these: Received-SPF: pass ... Authentication-Results: mx.google.com; spf=pass ... So the problem is unlikely to be a SPF issue, as mentioned in my first e-mail. We haven't sent any marketing mail from the same IP in months, but I believe that we did previously. We do send out once every few months a network maintenance notice with identical content for all recipients, except their name and To header. Clocks are set correctly everywhere via NTP and Received headers in the messages are >= each of the previous Received headers as you go up. We do use ALL CAPS in some subjects (rare) but more commonly, some customer names and other data in the body does appear in caps. We also have a www.caneris.com link on most e-mails (removing it doesn't change gmail's behaviour). Messages without anything ALL CAPS in them end up in spam as well. I created a new mailbox under a Google Apps domain and sent it one of the typical messages. It went into spam. I also ran the same message through SpamAssassin as per your suggestion and it came out clean. A test message sent directly from the same edge MTA but with a From address in a different domain is not delivered to spam, even though Return-Path there is still an @caneris.com address (but different than our usual one). A test message sent from our corporate mail system (Zimbra box in internal network relaying to the same edge MTA as the one used by the OSS/BSS box) goes to spam. I've received several off-list responses, including those from Google Apps users, asking for sample messages, so will be forwarding those. Ideas: -Message-Id @ "non-existant host" (ones in our internal network) -Received headers showing that the message was relayed, and again from a "non-existant host" Unlikely to be an IP repuation issue given the one message above did go through fine. Erik ----- Original Message ----- From: "William Herrin" To: "Erik L" Cc: nanog at nanog.org Sent: Tuesday, September 28, 2010 4:44:24 PM Subject: Re: What must one do to avoid Gmail's retarded non-spam filtering? On Tue, Sep 28, 2010 at 4:15 PM, Erik L wrote: > An increasingly large number of our customers are using > Gmail or Google Apps and almost all of our OSS/BSS mail > is getting spam filtered by Google. Among others, these > e-mails include invoices, order confirmations, payment > notifications, customer portal logins, and tickets. Almost > anything we send to customers on Google ends up in their > spam folder. Erik, Do you send marketing information to your customers from the same IP addresses as you send your invoices? Have you checked the source IPs against the RBLs with, e.g. http://rbls.org/? What about the source IP of the specific machine the originates the invoices et. al? Is the invoicing machine also in SPF? One of the companies I do business with accidentally excluded their billing mailer from the SPF record. Have you sent copies of the various types of documents to a mail server running Spam Assassin in order to see which qualms Spam Assassin flags? Careless mistakes with the headers or the clock can get your message flagged as spam. Even something as simple as ALL CAPS can get you flagged. Have you added your invoicing mailer, the one you can guarantee sends no marketing materials, in to the whitelist at http://www.dnswl.org/? Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From erik_list at caneris.com Tue Sep 28 23:17:45 2010 From: erik_list at caneris.com (Erik L) Date: Tue, 28 Sep 2010 19:17:45 -0400 (EDT) Subject: What must one do to avoid Gmail's retarded non-spam filtering? In-Reply-To: <1285711609.29882.9.camel@petrie.dereferenced.org> Message-ID: <31958224.2.1285715865793.JavaMail.root@zimbra.caneris.com> Hi William, I do so for our entire IP space on a regular basis. The edge MTA I mentioned in the reply to Bill shows up as "Neutral" there. Thanks Erik ----- Original Message ----- From: "William Pitcock" To: "Erik L" Cc: nanog at nanog.org Sent: Tuesday, September 28, 2010 6:06:49 PM Subject: Re: What must one do to avoid Gmail's retarded non-spam filtering? Hi, Have you checked the IronPort reputation scores for your mailserver IPs? Google uses this data as part of it's spam detection method. William On Tue, 2010-09-28 at 16:15 -0400, Erik L wrote: > I realize that this is somewhat OT, but I'm sure that others on the > list encounter the same issues and that at least some folks might have > useful comments. > > An increasingly large number of our customers are using Gmail or > Google Apps and almost all of our OSS/BSS mail is getting spam > filtered by Google. Among others, these e-mails include invoices, > order confirmations, payment notifications, customer portal logins, > and tickets. Almost anything we send to customers on Google ends up in > their spam folder. This results in a lot of calls and makes much of > our automation pointless, never mind all the lost sales. > > The problem is compounded by those who use mail clients and do not log > in to the webmail at all, since they would never see the contents of > the Google spam folder. > > We have proper A+PTR records on the edge MTAs, proper SPF records for > the originating domain, proper Return-Path and other headers, and so > on. There isn't anything that I can think of other than the content > itself which would be abnormal, and obviously the content is > repetitive and can't be changed much. Is there something obvious which > we've missed? > > Aside from the following clearly impractical solutions, what can we > do? 1. Asking everyone (including those we don't even know yet) to > whitelist all of our addresses, to check their spam folders, and to > click on "this is not spam" > 2. Providing our own free e-mail service to everyone (including those > we don't even know yet) and putting up "don't use Google" ads on all > of our customer-facing systems > > At least this isn't Hotmail where mail is just silently deleted with > no NDR after it's accepted by their MTAs. > > The call volume has been going up instead of down lately and it's > gotten to the point where we're sending MTA log extracts to people to > prove to them that we really did e-mail them. > > Would greatly appreciate any advice. > > Erik > From nonobvious at gmail.com Wed Sep 29 01:21:11 2010 From: nonobvious at gmail.com (Bill Stewart) Date: Tue, 28 Sep 2010 18:21:11 -0700 Subject: Online games stealing your bandwidth In-Reply-To: References: <20100925234734.GA19927@skywalker.creative.net.au> Message-ID: On Sat, Sep 25, 2010 at 5:17 PM, Matthew Walster wrote: >> Plenty of people sell p2p caches but they all work using magic, smoke and mirrors. Somehow that seems appropriate for gaming networks; maybe add some swords or old Gandalf boxes. In general distributing gaming software isn't going to have a big impact on your traffic levels - the average user will upload at most about as many megabytes as he downloaded (though obviously some will upload much more and some much less), and if the P2P is implemented well the uploads will mostly go to other customers of the same ISP, reducing the amount that comes through their peering point. And it'll all be a lot less than somebody pirating movies, because the game doesn't get DVD-sized updates multiple times a day or even a month. If you're running a satellite ISP, you probably care a lot more about upstream bandwidth, but it'll be much faster for one satellite user to get bits from Anchorage or even Seattle than to get it from another user two satellite hops away, especially if your uplinks are smaller than your downlinks, so if the P2P is implemented well (no idea if it is), you'll get very little uploading. (Does it save you money to get a WoW subscription for a box that sits in a server rack at your hub site with nobody actually playing it, to further reduce your bandwidth needs? Maybe.) -- ---- ? ? ? ? ? ?? Thanks;? ?? Bill Note that this isn't my regular email account - It's still experimental so far. And Google probably logs and indexes everything you send it. From cb.list6 at gmail.com Wed Sep 29 01:27:07 2010 From: cb.list6 at gmail.com (Cameron Byrne) Date: Tue, 28 Sep 2010 18:27:07 -0700 Subject: LISP Works - Re: Facebook Issues/Outage in Southeast? In-Reply-To: <1E9490CA-3AC3-43DD-AE46-051927DE4C86@instituut.net> References: <20100923173347.1E6D67EA@resin06.mta.everyone.net> <1E9490CA-3AC3-43DD-AE46-051927DE4C86@instituut.net> Message-ID: On Tue, Sep 28, 2010 at 3:13 PM, Job W. J. Snijders wrote: > Hi Cameron, > > On 24 sep 2010, at 02:56, Cameron Byrne wrote: > >> On Thu, Sep 23, 2010 at 5:33 PM, Scott Weeks wrote: >>> On Sep 23, 2010, at 5:50 PM, "Scott Weeks" wrote: >>>> --- jared at puck.nether.net wrote: >>> >>>> It's working over LISP: >>>> >>>> http://www.lisp4.facebook.com/ >>>> ------------------------------------- > >>> Wow, that's cool. ?I didn't know LISP had progressed that far... > > Yes, LISP is good for you! :-) > >> I would have to agree, i am surprised that there is a single Cisco >> 3800 series router running test code of LISP at any content >> provider.... which is all this is. ?Facebook made it clear that LISP >> was an experiment, not a technology direction. ?I don't think this >> example represents anything in particular. ?As a network operator, i >> am afraid LISP is going to turn into the next 6to4 .. an interesting >> idea that causes more harm than good. ?Sorry to the fans of 6to4 and >> LISP, i just long for the day when real IPv6 restores the real e2e >> internet without strange trickery along the way. > > > There is a huge difference between using LISP and 6to4 that you're not considering here. > Agreed, my context for the comment was narrow. > 6to4 was specifically invented to solve the particular problem of IPv6/IPv4 transition. That is its sole purpose for existence. > > LISP was not invented to solve this problem - it was invented to address a much broader set of problems that neither IPv4 or IPv6 address (e.g. overloaded address semantics, multi-homing simplicity, IP mobility, and address portability). > > The fact that LISP does help in IPv6 Transition solutions (due to its inherent AF agnostic design), is compelling. As you say, real edge 2 edge is the goal - and LISP helps here, regardless of the AF. (you'll will still want to do multi-homing in IPv6, and ingress TE, and mobility, etc.). > Sorry, when i said e2e w.r.t IPv6 i was talking about end to end, not edge to edge. I think there is a big difference. There are a lot of solutions in this space, and no clear winner is the official outcome, for now. http://tools.ietf.org/html/draft-irtf-rrg-recommendation-14 IMHO, ILNP is the more interesting solution and avoids expensive encapsulation and questionable assumptions about ISP MTU, all my ISP links are GigE and 10GigE and they are all set to default 1500 bytes ... good or bad, this is just how they roll off the line from every ISP in every city i buy transit... and LISP tunnels do not work so well with 1500 byte MTU. The only real take away here is that routers will continue to route on the internet, for now. They even route IPv6 well, today. Cameron ======= http://groups.google.com/group/tmoipv6beta ======= > So it won't have the the same fate as 6to4. > > Kind regards, > > Job Snijders From zeusdadog at gmail.com Wed Sep 29 01:27:32 2010 From: zeusdadog at gmail.com (Jay Nakamura) Date: Tue, 28 Sep 2010 21:27:32 -0400 Subject: tagged vs. untagged VLAN Message-ID: In a SP environment, you need to hand off two VLANs to a customer, is there any advantage or disadvantage in doing the following two setups? - One untagged and one tagged VLAN - Two tagged VLAN and no untagged VLAN I can't think of anything other than some equipment may not let you have no untagged VLAN. But it's bugging me that something could go wrong by not having untagged native VLAN that I can't think of. From franck at genius.com Wed Sep 29 01:28:17 2010 From: franck at genius.com (Franck Martin) Date: Wed, 29 Sep 2010 13:28:17 +1200 (FJT) Subject: Online games stealing your bandwidth In-Reply-To: Message-ID: <24948047.2177.1285723693312.JavaMail.franck@franck-martins-macbook-pro.local> As for online experience, any action game with players 200ms away from each others, is not really playable. By the time you aim, shoot, and the info register on the server and other user player PC, it has moved far away from the shot... From brandon.kim at brandontek.com Wed Sep 29 01:51:10 2010 From: brandon.kim at brandontek.com (Brandon Kim) Date: Tue, 28 Sep 2010 21:51:10 -0400 Subject: tagged vs. untagged VLAN In-Reply-To: References: Message-ID: I'd think that going with two tagged VLAN's is the better route. You will then be forcing the customer to adhere to the VLAN's that you have specified and reserved for them. It's also a security advantage because if you go with untagged, who knows if someone might be able to vlan hop/double tag their way into someone elses network.... > Date: Tue, 28 Sep 2010 21:27:32 -0400 > Subject: tagged vs. untagged VLAN > From: zeusdadog at gmail.com > To: nanog at nanog.org > > In a SP environment, you need to hand off two VLANs to a customer, is > there any advantage or disadvantage in doing the following two setups? > > - One untagged and one tagged VLAN > - Two tagged VLAN and no untagged VLAN > > I can't think of anything other than some equipment may not let you > have no untagged VLAN. But it's bugging me that something could go > wrong by not having untagged native VLAN that I can't think of. > From jeffrey.lyon at blacklotus.net Wed Sep 29 02:59:44 2010 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Wed, 29 Sep 2010 07:29:44 +0430 Subject: Requesting assistance from Telia netop (Fwd: Prefix Preference at Level3) Message-ID: We're trying to help a downstream customer with an issue and require assistance from a clued Telia netop. The customer is running a GRE tunnel from Los Angeles to Brazil for international transit and needs to avoid carrying local traffic over the tunnel. He is requesting a pref of > 150 for Level3 prefixes. We sent a request to carrier-csc at teliasonera.com and here is the response we received: > We do not manipulate the prefixes that comes to us from peers. Customer may configure this on their side, but peers are always set to 150. > Please do not hesitate to contact us is you have any questions, we will close our ticket in 4 hours. Hoping to get ahold of someone at Telia with a much higher degree of awesome than this. -- Jeffrey Lyon, Leadership Team jeffrey.lyon at blacklotus.net | http://www.blacklotus.net Black Lotus Communications - AS32421 First and Leading in DDoS Protection Solutions From nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org Wed Sep 29 03:11:03 2010 From: nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org (Mark Smith) Date: Wed, 29 Sep 2010 12:41:03 +0930 Subject: Online games stealing your bandwidth In-Reply-To: References: Message-ID: <20100929124103.4de5761b@opy.nosense.org> On Sat, 25 Sep 2010 16:56:21 -0400 (EDT) Jon Lewis wrote: > On Sat, 25 Sep 2010, Rodrick Brown wrote: > > > If you follow the links in the article people are complaining that the LotR > > process has served 70gb in a week, others are complaining that the service > > is resulting in 300ms pings, and unusable connections. > > This is a very grey area it will be interesting how this issue unfolds in > > the long run. > > I haven't played any of these things, so I don't know what they put in > the fine print, but unless LotR makes it clear that they're going to > utilize your (i.e. players of the game) bandwidth to PTP distribute their > software, I'd call that theft and unauthorized use of a computer network. Skype have been doing this for years to ISP users who have public IP addresses, which is how they get around NAT without having giant publicly addressed relay servers. I don't know how much effort they got to to notify users via the T&Cs. The only real difference here seems to be the volume of traffic involved. > Are these companies not making enough in monthly subscriptions to afford > Akamai or similar CDN services to distribute their software updates? > > ---------------------------------------------------------------------- > Jon Lewis, MCP :) | I route > Senior Network Engineer | therefore you are > Atlantic Net | > _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ > From erik_list at caneris.com Wed Sep 29 04:05:33 2010 From: erik_list at caneris.com (Erik L) Date: Wed, 29 Sep 2010 00:05:33 -0400 (EDT) Subject: What must one do to avoid Gmail's retarded non-spam filtering? In-Reply-To: <33359443.134.1285732542520.JavaMail.root@zimbra.caneris.com> Message-ID: <10950451.138.1285733133371.JavaMail.root@zimbra.caneris.com> Google appears to have blacklisted our domain. From the edge MTA, I sent three messages, differing only in the From header: 1. valid email @klssys.com 2. valid email @caneris.com 3. abc123 at caneris.com 1 not spam; 2 & 3 spam Return-Path of all three was still another address @caneris.com and the two SPF passed headers were still there. The body & subject of all messages was simply "testing5". The recipient even clicked on "not spam" on #2 prior to #3 being sent. At least it explains why all the other standard stuff we all looked at didn't explain the issue. The next (and last) question is: does anyone have a clueful Google mail ops contact? Thanks again for all the help and sorry for the OT noise. Erik ----- Original Message ----- From: "Erik L" To: "William Pitcock" Cc: nanog at nanog.org Sent: Tuesday, September 28, 2010 7:17:45 PM Subject: Re: What must one do to avoid Gmail's retarded non-spam filtering? Hi William, I do so for our entire IP space on a regular basis. The edge MTA I mentioned in the reply to Bill shows up as "Neutral" there. Thanks Erik ----- Original Message ----- From: "William Pitcock" To: "Erik L" Cc: nanog at nanog.org Sent: Tuesday, September 28, 2010 6:06:49 PM Subject: Re: What must one do to avoid Gmail's retarded non-spam filtering? Hi, Have you checked the IronPort reputation scores for your mailserver IPs? Google uses this data as part of it's spam detection method. William On Tue, 2010-09-28 at 16:15 -0400, Erik L wrote: > I realize that this is somewhat OT, but I'm sure that others on the > list encounter the same issues and that at least some folks might have > useful comments. > > An increasingly large number of our customers are using Gmail or > Google Apps and almost all of our OSS/BSS mail is getting spam > filtered by Google. Among others, these e-mails include invoices, > order confirmations, payment notifications, customer portal logins, > and tickets. Almost anything we send to customers on Google ends up in > their spam folder. This results in a lot of calls and makes much of > our automation pointless, never mind all the lost sales. > > The problem is compounded by those who use mail clients and do not log > in to the webmail at all, since they would never see the contents of > the Google spam folder. > > We have proper A+PTR records on the edge MTAs, proper SPF records for > the originating domain, proper Return-Path and other headers, and so > on. There isn't anything that I can think of other than the content > itself which would be abnormal, and obviously the content is > repetitive and can't be changed much. Is there something obvious which > we've missed? > > Aside from the following clearly impractical solutions, what can we > do? 1. Asking everyone (including those we don't even know yet) to > whitelist all of our addresses, to check their spam folders, and to > click on "this is not spam" > 2. Providing our own free e-mail service to everyone (including those > we don't even know yet) and putting up "don't use Google" ads on all > of our customer-facing systems > > At least this isn't Hotmail where mail is just silently deleted with > no NDR after it's accepted by their MTAs. > > The call volume has been going up instead of down lately and it's > gotten to the point where we're sending MTA log extracts to people to > prove to them that we really did e-mail them. > > Would greatly appreciate any advice. > > Erik > From daniel.dib at reaper.nu Wed Sep 29 04:15:23 2010 From: daniel.dib at reaper.nu (Daniel Dib) Date: Wed, 29 Sep 2010 06:15:23 +0200 Subject: tagged vs. untagged VLAN In-Reply-To: References: Message-ID: <001201cb5f8c$f39d3ee0$dad7bca0$@dib@reaper.nu> -----Original Message----- From: Jay Nakamura [mailto:zeusdadog at gmail.com] Sent: den 29 september 2010 03:28 To: NANOG Subject: tagged vs. untagged VLAN >In a SP environment, you need to hand off two VLANs to a customer, is >there any advantage or disadvantage in doing the following two setups? > >- One untagged and one tagged VLAN >- Two tagged VLAN and no untagged VLAN > >I can't think of anything other than some equipment may not let you >have no untagged VLAN. But it's bugging me that something could go >wrong by not having untagged native VLAN that I can't think of. I would go with tagged for both VLANs. If you can't tag the native in your equipment create a dummy VLAN and use it as native on the link and all VLANs will be tagged. If you know the customer will be using more VLANs later on Q-in-Q might be a good solution or you will have to transport a lot of VLANs in your network and they might collide with other customers etc. /Daniel From darren at bolding.org Wed Sep 29 07:56:38 2010 From: darren at bolding.org (Darren Bolding) Date: Wed, 29 Sep 2010 00:56:38 -0700 Subject: What must one do to avoid Gmail's retarded non-spam filtering? In-Reply-To: <10950451.138.1285733133371.JavaMail.root@zimbra.caneris.com> References: <33359443.134.1285732542520.JavaMail.root@zimbra.caneris.com> <10950451.138.1285733133371.JavaMail.root@zimbra.caneris.com> Message-ID: Ignoring the irony, you could signup with Microsoft's spam filtering service (formerly frontbridge) or postini (now google) and use them as outbound relays. They will do outbound relay, with attendant spam filtering and increases in deliverability. That means a lot more people will accept your mail when it is being relayed by postini/front bridge. I believe postini will do this for any account, even one that has only, say, one e-mail address being filtered by them and the rest silently passed. Heck, you may not even need to point your mx records to their servers- they just need a reinjection method for outbound filtering if I recall correctly. Again, I acknowledge the irony involved in such a solution. --D On Tue, Sep 28, 2010 at 9:05 PM, Erik L wrote: > Google appears to have blacklisted our domain. From the edge MTA, I sent > three messages, differing only in the From header: > 1. valid email @klssys.com > 2. valid email @caneris.com > 3. abc123 at caneris.com > > 1 not spam; 2 & 3 spam > > Return-Path of all three was still another address @caneris.com and the > two SPF passed headers were still there. The body & subject of all messages > was simply "testing5". The recipient even clicked on "not spam" on #2 prior > to #3 being sent. > > At least it explains why all the other standard stuff we all looked at > didn't explain the issue. > > The next (and last) question is: does anyone have a clueful Google mail ops > contact? > > Thanks again for all the help and sorry for the OT noise. > > Erik > > ----- Original Message ----- > From: "Erik L" > To: "William Pitcock" > Cc: nanog at nanog.org > Sent: Tuesday, September 28, 2010 7:17:45 PM > Subject: Re: What must one do to avoid Gmail's retarded non-spam filtering? > > Hi William, > > I do so for our entire IP space on a regular basis. The edge MTA I > mentioned in the reply to Bill shows up as "Neutral" there. > > Thanks > > Erik > > ----- Original Message ----- > From: "William Pitcock" > To: "Erik L" > Cc: nanog at nanog.org > Sent: Tuesday, September 28, 2010 6:06:49 PM > Subject: Re: What must one do to avoid Gmail's retarded non-spam > filtering? > > Hi, > > Have you checked the IronPort reputation scores for your mailserver IPs? > Google uses this data as part of it's spam detection method. > > William > > On Tue, 2010-09-28 at 16:15 -0400, Erik L wrote: > > I realize that this is somewhat OT, but I'm sure that others on the > > list encounter the same issues and that at least some folks might have > > useful comments. > > > > An increasingly large number of our customers are using Gmail or > > Google Apps and almost all of our OSS/BSS mail is getting spam > > filtered by Google. Among others, these e-mails include invoices, > > order confirmations, payment notifications, customer portal logins, > > and tickets. Almost anything we send to customers on Google ends up in > > their spam folder. This results in a lot of calls and makes much of > > our automation pointless, never mind all the lost sales. > > > > The problem is compounded by those who use mail clients and do not log > > in to the webmail at all, since they would never see the contents of > > the Google spam folder. > > > > We have proper A+PTR records on the edge MTAs, proper SPF records for > > the originating domain, proper Return-Path and other headers, and so > > on. There isn't anything that I can think of other than the content > > itself which would be abnormal, and obviously the content is > > repetitive and can't be changed much. Is there something obvious which > > we've missed? > > > > Aside from the following clearly impractical solutions, what can we > > do? 1. Asking everyone (including those we don't even know yet) to > > whitelist all of our addresses, to check their spam folders, and to > > click on "this is not spam" > > 2. Providing our own free e-mail service to everyone (including those > > we don't even know yet) and putting up "don't use Google" ads on all > > of our customer-facing systems > > > > At least this isn't Hotmail where mail is just silently deleted with > > no NDR after it's accepted by their MTAs. > > > > The call volume has been going up instead of down lately and it's > > gotten to the point where we're sending MTA log extracts to people to > > prove to them that we really did e-mail them. > > > > Would greatly appreciate any advice. > > > > Erik > > > > -- -- Darren Bolding -- -- darren at bolding.org -- From ljakab at ac.upc.edu Wed Sep 29 08:57:55 2010 From: ljakab at ac.upc.edu (=?UTF-8?B?TG9yw6FuZCBKYWthYg==?=) Date: Wed, 29 Sep 2010 10:57:55 +0200 Subject: What must one do to avoid Gmail's retarded non-spam filtering? In-Reply-To: <22257558.30.1285704909402.JavaMail.root@zimbra.caneris.com> References: <22257558.30.1285704909402.JavaMail.root@zimbra.caneris.com> Message-ID: <4CA2FF93.7070607@ac.upc.edu> On 09/28/2010 10:15 PM, Erik L wrote: > I realize that this is somewhat OT, but I'm sure that others on the list encounter the same issues and that at least some folks might have useful comments. > > An increasingly large number of our customers are using Gmail or Google Apps and almost all of our OSS/BSS mail is getting spam filtered by Google. Among others, these e-mails include invoices, order confirmations, payment notifications, customer portal logins, and tickets. Almost anything we send to customers on Google ends up in their spam folder. This results in a lot of calls and makes much of our automation pointless, never mind all the lost sales. > > The problem is compounded by those who use mail clients and do not log in to the webmail at all, since they would never see the contents of the Google spam folder. > > We have proper A+PTR records on the edge MTAs, proper SPF records for the originating domain, proper Return-Path and other headers, and so on. There isn't anything that I can think of other than the content itself which would be abnormal, and obviously the content is repetitive and can't be changed much. Is there something obvious which we've missed? Have you tried DKIM signing? All email sent from Gmail is DKIM signed, so they probably also support checking it and a valid signature may lower your spam score. Regards, -Lorand Jakab > Aside from the following clearly impractical solutions, what can we do? > 1. Asking everyone (including those we don't even know yet) to whitelist all of our addresses, to check their spam folders, and to click on "this is not spam" > 2. Providing our own free e-mail service to everyone (including those we don't even know yet) and putting up "don't use Google" ads on all of our customer-facing systems > > At least this isn't Hotmail where mail is just silently deleted with no NDR after it's accepted by their MTAs. > > The call volume has been going up instead of down lately and it's gotten to the point where we're sending MTA log extracts to people to prove to them that we really did e-mail them. > > Would greatly appreciate any advice. > > Erik > From rfg at tristatelogic.com Wed Sep 29 11:22:57 2010 From: rfg at tristatelogic.com (Ronald F. Guilmette) Date: Wed, 29 Sep 2010 04:22:57 -0700 Subject: AS11296 -- Hijacked? Message-ID: <72132.1285759377@tristatelogic.com> Heath Jones wrote: >Out of curiosity, what led you to this conclusion? A number of factors, actually. Although I had started to type up a lengthy and elaborate response to your eminently reasonable question, on second thought, I don't think that I actually want to go into detail on this case, as anything I might say as regards to how I detected this would just allow future hijackers to evade me that much more effectively. So I'm sorry to be giving you a non-answer, but actually, I think that's best for now. In any case, further discussion of this particular case now appears to be moot. As of now, it appears that AS11296 is no longer announcing any routes at all, so I'm assuming that Nishant Ramachandran (Xeex/AS27524) and/or whoever else may have been involved in this has now been adequately spanked. (And my personal thanks go out to whoever did that.) Regards, rfg P.S. Yes, I actually _am_ blocking inbound e-mail from google/gmail. Too much spam from there, and far too little action to correct the abundant problem(s). (Can you spell E-V-I-L?) Also blocked here: Yahoo and Hotmail, for the same reasons. (To big to fail? No. Just too big to care. They don't need me, and I sure as hell don't need them.) I guess you don't have a real mail server of your own that you can use. For that, you have my sympathies. From deleskie at gmail.com Wed Sep 29 11:38:17 2010 From: deleskie at gmail.com (jim deleskie) Date: Wed, 29 Sep 2010 08:38:17 -0300 Subject: AS11296 -- Hijacked? In-Reply-To: <72132.1285759377@tristatelogic.com> References: <72132.1285759377@tristatelogic.com> Message-ID: WOW full of yourself much. Many of us use gmail and others to manage the load of mail we received from various lists. I doubt we anyone needs your sympathies, Good luck getting assistance from the list in the future, but I doubt you need it, you see to be able to do everything on your own. -jim On Wed, Sep 29, 2010 at 8:22 AM, Ronald F. Guilmette wrote: > > Heath Jones wrote: > > >Out of curiosity, what led you to this conclusion? > > A number of factors, actually. > > Although I had started to type up a lengthy and elaborate response to > your eminently reasonable question, on second thought, I don't think > that I actually want to go into detail on this case, as anything I > might say as regards to how I detected this would just allow future > hijackers to evade me that much more effectively. > > So I'm sorry to be giving you a non-answer, but actually, I think that's > best for now. > > In any case, further discussion of this particular case now appears to > be moot. As of now, it appears that AS11296 is no longer announcing any > routes at all, so I'm assuming that Nishant Ramachandran (Xeex/AS27524) > and/or whoever else may have been involved in this has now been adequately > spanked. (And my personal thanks go out to whoever did that.) > > > Regards, > rfg > > > P.S. Yes, I actually _am_ blocking inbound e-mail from google/gmail. > Too much spam from there, and far too little action to correct the > abundant problem(s). (Can you spell E-V-I-L?) Also blocked here: > Yahoo and Hotmail, for the same reasons. (To big to fail? No. Just > too big to care. They don't need me, and I sure as hell don't need > them.) > > I guess you don't have a real mail server of your own that you can use. > For that, you have my sympathies. > > From rfg at tristatelogic.com Wed Sep 29 11:56:34 2010 From: rfg at tristatelogic.com (Ronald F. Guilmette) Date: Wed, 29 Sep 2010 04:56:34 -0700 Subject: AS10392 -- Hijacked? Message-ID: <72584.1285761394@tristatelogic.com> Evidence strongly suggests that AS10392 together with all of the IPv4 space it is currently announcing routes for, i.e.: 192.171.64.0/19 204.137.224.0/19 205.164.0.0/20 205.164.16.0/20 205.164.32.0/20 205.164.48.0/20 have all been hijacked. I will be reporting this formally to ARIN today, via their helpful fraud reporting web form. In the meantime, while this case is being carefully adjudicated by ARIN, some folks may wish to blackhole the above. (The IP space appears to be in use by some sort of snowshoe spamming operation.) Regards, rfg P.S. Connectivity for AS10392 appears to come from only one place: http://www.robtex.com/as/as10392.html#graph From bjorn at mork.no Wed Sep 29 12:13:51 2010 From: bjorn at mork.no (=?utf-8?Q?Bj=C3=B8rn_Mork?=) Date: Wed, 29 Sep 2010 14:13:51 +0200 Subject: Randy in Nevis In-Reply-To: <20100928140511.77b9f1a2@jpeach-desktop> (John Peach's message of "Tue, 28 Sep 2010 14:05:11 -0400") References: <86tylbtgiq.fsf@seastrom.com> <4CA0C68E.2070501@orthanc.ca> <3FDF6338-0C7E-49FB-B3E5-85BBD4100EC1@delong.com> <4CA20787.40906@rollernet.us> <8C26A4FDAE599041A13EB499117D3C28405FA863@ex-mb-2.corp.atlasnetworks.us> <20100928140511.77b9f1a2@jpeach-desktop> Message-ID: <87tyl89280.fsf@nemi.mork.no> John Peach writes: > It is on all Linux distros: > > ssmtp 465/tcp smtps # SMTP over SSL So file bug reports. Bj?rn From hj1980 at gmail.com Wed Sep 29 12:16:01 2010 From: hj1980 at gmail.com (Heath Jones) Date: Wed, 29 Sep 2010 13:16:01 +0100 Subject: AS11296 -- Hijacked? In-Reply-To: <72132.1285759377@tristatelogic.com> References: <72132.1285759377@tristatelogic.com> Message-ID: >>Out of curiosity, what led you to this conclusion? > > A number of factors, actually. > Although I had started to type up a lengthy and elaborate response to > your eminently reasonable question, on second thought, I don't think > that I actually want to go into detail on this case, as anything I > might say as regards to how I detected this would just allow future > hijackers to evade me that much more effectively. > So I'm sorry to be giving you a non-answer, but actually, I think that's > best for now. Let me reword... What is stopping someone coming on the list, making a claim like you have in an attempt to actually cause a DOS attack, by having some clumsy network engineers starting to block traffic in reaction to your post? I'm sure that you've done your investigation (dont get me wrong) and your might sure be right in your assertions, nevertheless evidence is pretty much needed for a claim like that! > In any case, further discussion of this particular case now appears to > be moot. Ok, but back to my point - what is the evidence and how are people to trust what your saying? > P.S. ?Yes, I actually _am_ blocking inbound e-mail from google/gmail. > Too much spam from there, and far too little action to correct the > abundant problem(s). ?(Can you spell E-V-I-L?) ?Also blocked here: > Yahoo and Hotmail, for the same reasons. (To big to fail? ?No. ?Just > too big to care. ?They don't need me, and I sure as hell don't need > them.) Let me get this right.. You use your own mail server and have problems filtering spam. I use gmail and don't have that problem. > I guess you don't have a real mail server of your own that you can use. > For that, you have my sympathies. The only time I have problems is when I try and send an email to some muppet that has blocked gmail & hotmail & god knows what else. Perhaps you should do yourself a favour, turn off your mail server and open up a gmail/hotmail account like the rest of the population. From rsk at gsp.org Wed Sep 29 12:25:20 2010 From: rsk at gsp.org (Rich Kulawiec) Date: Wed, 29 Sep 2010 08:25:20 -0400 Subject: AS11296 -- Hijacked? In-Reply-To: References: <72132.1285759377@tristatelogic.com> Message-ID: <20100929122520.GA12933@gsp.org> On Wed, Sep 29, 2010 at 08:38:17AM -0300, jim deleskie wrote: > WOW full of yourself much. Many of us use gmail and others to manage the > load of mail we received from various lists. I doubt we anyone needs > your sympathies, > Good luck getting assistance from the list in the future, but I doubt you > need it, you see to be able to do everything on your own. Ron is one of the most senior anti-spam people on this planet, and has long since demonstrated not only serious clue, but formidable research and analysis skills. You may safely trust that if he's made the decision to post a message like the referenced one in a public forum that he's done his homework. As to his decision to block Gmail (or any other freemail provider), everyone with sufficient knowledge in the field knows that these operations are prolific and habitual sources of spam (via multiple vectors, not just SMTP; Google accounts for more Usenet spam hitting my filters than all other sources combined). It's thus not at all unreasonable for some operations to revoke (some oor all of) their privileges by way of self-defense. So I think a better response would be to skip the snark and instead reconsider the decision to use a freemail provider for professional (outbound [1]) communications. ---rsk [1] Using one as a sink for mailing list traffic isn't an entirely bad idea; I do some of that myself. Those which provide POP/IMAP service make it relatively easy to do so -- although one should accept that they're, in general, not high-quality mail services, and that incoming mailing list traffic may variously be denied, lost, misclassified or otherwise not handled as expected. From john-nanog at johnpeach.com Wed Sep 29 12:26:03 2010 From: john-nanog at johnpeach.com (John Peach) Date: Wed, 29 Sep 2010 08:26:03 -0400 Subject: Randy in Nevis In-Reply-To: <87tyl89280.fsf@nemi.mork.no> References: <86tylbtgiq.fsf@seastrom.com> <4CA0C68E.2070501@orthanc.ca> <3FDF6338-0C7E-49FB-B3E5-85BBD4100EC1@delong.com> <4CA20787.40906@rollernet.us> <8C26A4FDAE599041A13EB499117D3C28405FA863@ex-mb-2.corp.atlasnetworks.us> <20100928140511.77b9f1a2@jpeach-desktop> <87tyl89280.fsf@nemi.mork.no> Message-ID: <20100929082603.28efd43c@jpeach-desktop> On Wed, 29 Sep 2010 14:13:51 +0200 Bj?rn Mork wrote: > John Peach writes: > > > It is on all Linux distros: > > > > ssmtp 465/tcp smtps # SMTP over SSL > > So file bug reports. With IANA? It's common knowledge that 465 is smtps, whatever else IANA might say. > > > Bj?rn > -- John From Valdis.Kletnieks at vt.edu Wed Sep 29 12:25:16 2010 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Wed, 29 Sep 2010 08:25:16 -0400 Subject: Randy in Nevis In-Reply-To: Your message of "Wed, 29 Sep 2010 14:13:51 +0200." <87tyl89280.fsf@nemi.mork.no> References: <86tylbtgiq.fsf@seastrom.com> <4CA0C68E.2070501@orthanc.ca> <3FDF6338-0C7E-49FB-B3E5-85BBD4100EC1@delong.com> <4CA20787.40906@rollernet.us> <8C26A4FDAE599041A13EB499117D3C28405FA863@ex-mb-2.corp.atlasnetworks.us> <20100928140511.77b9f1a2@jpeach-desktop> <87tyl89280.fsf@nemi.mork.no> Message-ID: <79587.1285763116@localhost> On Wed, 29 Sep 2010 14:13:51 +0200, =?utf-8?Q?Bj=C3=B8rn_Mork?= said: > John Peach writes: > > > It is on all Linux distros: > > > > ssmtp 465/tcp smtps # SMTP over SSL > > So file bug reports. bug-reports at iana.org seems to bounce. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From deleskie at gmail.com Wed Sep 29 12:40:39 2010 From: deleskie at gmail.com (deleskie at gmail.com) Date: Wed, 29 Sep 2010 12:40:39 +0000 Subject: AS11296 -- Hijacked? In-Reply-To: <20100929122520.GA12933@gsp.org> References: <72132.1285759377@tristatelogic.com><20100929122520.GA12933@gsp.org> Message-ID: <604187968-1285764041-cardhu_decombobulator_blackberry.rim.net-96385670-@bda002.bisx.prod.on.blackberry> I have no issue with Ron's level of clue or his personal choice to block whichever domain, or blocks of IP space he wishes. That's one of the true beauties of the internet, we can all do as we see fit with out little corner of if. But it goes the same with who we choose to help or which mail systems we choose to use. Ron choose to set the tone, in his last email, I'll choose not offer assistance in the future unless it relates to my bits of the internet. No real issue here. -jim Sent from my BlackBerry device on the Rogers Wireless Network -----Original Message----- From: Rich Kulawiec Date: Wed, 29 Sep 2010 08:25:20 To: Subject: Re: AS11296 -- Hijacked? On Wed, Sep 29, 2010 at 08:38:17AM -0300, jim deleskie wrote: > WOW full of yourself much. Many of us use gmail and others to manage the > load of mail we received from various lists. I doubt we anyone needs > your sympathies, > Good luck getting assistance from the list in the future, but I doubt you > need it, you see to be able to do everything on your own. Ron is one of the most senior anti-spam people on this planet, and has long since demonstrated not only serious clue, but formidable research and analysis skills. You may safely trust that if he's made the decision to post a message like the referenced one in a public forum that he's done his homework. As to his decision to block Gmail (or any other freemail provider), everyone with sufficient knowledge in the field knows that these operations are prolific and habitual sources of spam (via multiple vectors, not just SMTP; Google accounts for more Usenet spam hitting my filters than all other sources combined). It's thus not at all unreasonable for some operations to revoke (some oor all of) their privileges by way of self-defense. So I think a better response would be to skip the snark and instead reconsider the decision to use a freemail provider for professional (outbound [1]) communications. ---rsk [1] Using one as a sink for mailing list traffic isn't an entirely bad idea; I do some of that myself. Those which provide POP/IMAP service make it relatively easy to do so -- although one should accept that they're, in general, not high-quality mail services, and that incoming mailing list traffic may variously be denied, lost, misclassified or otherwise not handled as expected. From hj1980 at gmail.com Wed Sep 29 12:42:59 2010 From: hj1980 at gmail.com (Heath Jones) Date: Wed, 29 Sep 2010 13:42:59 +0100 Subject: AS11296 -- Hijacked? In-Reply-To: <20100929122520.GA12933@gsp.org> References: <72132.1285759377@tristatelogic.com> <20100929122520.GA12933@gsp.org> Message-ID: > As to his decision to block Gmail (or any other freemail provider), > everyone with sufficient knowledge in the field knows that these > operations are prolific and habitual sources of spam (via multiple > vectors, not just SMTP; Google accounts for more Usenet spam hitting > my filters than all other sources combined). ?It's thus not at all > unreasonable for some operations to revoke (some oor all of) their > privileges by way of self-defense. ?So I think a better response > would be to skip the snark and instead reconsider the decision to > use a freemail provider for professional (outbound [1]) communications. They are also prolific and habitual sources of people who might want to use email.. By your measure (and everyone that blocks these services), when is it appropriate to have a gmail/hotmail account? Are you saying that the general population are all doing it wrong and that we should all change? Or am I missing your point entirely? From cmaurand at xyonet.com Wed Sep 29 12:53:25 2010 From: cmaurand at xyonet.com (Curtis Maurand) Date: Wed, 29 Sep 2010 08:53:25 -0400 Subject: Software-based Border Router In-Reply-To: <8C26A4FDAE599041A13EB499117D3C28405FA766@ex-mb-2.corp.atlasnetworks.us> References: <20100926.115921.74701327.sthaug@nethelp.no> <221425418.6450.1285496120772.JavaMail.root@mailserver> <632cd89a3c2601509f182619bcfe669a.squirrel@www.xyonet.com> <4CA1E58A.3000104@xyonet.com> <8C26A4FDAE599041A13EB499117D3C28405FA766@ex-mb-2.corp.atlasnetworks.us> Message-ID: <4CA336C5.5000000@xyonet.com> I didn't say hardware forwarding. I said hardware. They have appliances that run up to 3Mpps and support 8000 tunnels. This is all information from their website. I've been running vyatta on a small dual core supermicro shallow box for 455 days without a reboot. Except for the occasional tunnel drop (which I've managed to automate restarting that service via a shell script) its been rock solid. Its been as rock solid as the OpenRoute router it replaced and that router ran for 10 years. There are lots of interfaces you can purchase for the thing including 10Gbps if you need them. Some of those might have hardware forwarding, they might not. Running server quality interfaces is always better than the cheap little Realtek. However, those cheap little Realteks get it done...reliably. On 9/28/2010 12:58 PM, Nathan Eisenberg wrote: > Vyatta has hardware forwarding? Real hardware forwarding? Where? > > Best Regards, > Nathan Eisenberg > >> -----Original Message----- >> From: Curtis Maurand [mailto:cmaurand at xyonet.com] >> Sent: Tuesday, September 28, 2010 5:55 AM >> To: Heath Jones >> Cc: nanog at nanog.org >> Subject: Re: Software-based Border Router >> >> Vyatta has support contracts. If you want hardware, they've got that, too. >> >> >> >> On 9/27/2010 6:48 PM, Heath Jones wrote: >>> Oh, support contract!!? >>> >>>> Differences: >>>> - Hardware forwarding >>>> - Interface options >>>> - Port density >>>> - Redundancy >>>> - Power consumption >>>> - Service Provider stuff - MPLS TE? VPLS? VRF?? >>>> >>>> Any others? >>>> > From hj1980 at gmail.com Wed Sep 29 12:59:47 2010 From: hj1980 at gmail.com (Heath Jones) Date: Wed, 29 Sep 2010 13:59:47 +0100 Subject: Software-based Border Router In-Reply-To: <4CA336C5.5000000@xyonet.com> References: <20100926.115921.74701327.sthaug@nethelp.no> <221425418.6450.1285496120772.JavaMail.root@mailserver> <632cd89a3c2601509f182619bcfe669a.squirrel@www.xyonet.com> <4CA1E58A.3000104@xyonet.com> <8C26A4FDAE599041A13EB499117D3C28405FA766@ex-mb-2.corp.atlasnetworks.us> <4CA336C5.5000000@xyonet.com> Message-ID: What's the real-world power consumption and heat like? 455 days shows some pretty good reliability! Cheers for the info Curtis From jabley at hopcount.ca Wed Sep 29 12:59:40 2010 From: jabley at hopcount.ca (Joe Abley) Date: Wed, 29 Sep 2010 12:59:40 +0000 Subject: Randy in Nevis In-Reply-To: <79587.1285763116@localhost> References: <86tylbtgiq.fsf@seastrom.com> <4CA0C68E.2070501@orthanc.ca> <3FDF6338-0C7E-49FB-B3E5-85BBD4100EC1@delong.com> <4CA20787.40906@rollernet.us> <8C26A4FDAE599041A13EB499117D3C28405FA863@ex-mb-2.corp.atlasnetworks.us> <20100928140511.77b9f1a2@jpeach-desktop> <87tyl89280.fsf@nemi.mork.no> <79587.1285763116@localhost> Message-ID: On 2010-09-29, at 12:25, Valdis.Kletnieks at vt.edu wrote: > On Wed, 29 Sep 2010 14:13:51 +0200, =?utf-8?Q?Bj=C3=B8rn_Mork?= said: >> John Peach writes: >> >>> It is on all Linux distros: >>> >>> ssmtp 465/tcp smtps # SMTP over SSL >> >> So file bug reports. > > bug-reports at iana.org seems to bounce. I don't know the history of 465/tcp as an entry in the registry found at <, but assuming the current entry is there for a reason (and hence is not an error that might be corrected), I believe this is the workflow required to change it. The port-number registry is maintained according to the directions in RFC 2780. To change an entry in the registry you need to write and submit an internet-draft which contains an IANA Considerations section specifying the change that is required. Those specifications will be executed (and the registry updated) if/when the I-D makes it through to that stage in the RFC publication process. RFC 2780 gives the following guidance for how such an I-D might reach that stage. 9.1 TCP Source and Destination Port fields Both the Source and Destination Port fields use the same namespace. Values in this namespace are assigned following a Specification Required, Expert Review, IESG Approval, IETF Consensus, or Standards Action process. Note that some assignments may involve non- disclosure information. Joe From cboyd at gizmopartners.com Wed Sep 29 13:01:00 2010 From: cboyd at gizmopartners.com (Chris Boyd) Date: Wed, 29 Sep 2010 08:01:00 -0500 Subject: Randy in Nevis In-Reply-To: <20100929082603.28efd43c@jpeach-desktop> References: <86tylbtgiq.fsf@seastrom.com> <4CA0C68E.2070501@orthanc.ca> <3FDF6338-0C7E-49FB-B3E5-85BBD4100EC1@delong.com> <4CA20787.40906@rollernet.us> <8C26A4FDAE599041A13EB499117D3C28405FA863@ex-mb-2.corp.atlasnetworks.us> <20100928140511.77b9f1a2@jpeach-desktop> <87tyl89280.fsf@nemi.mork.no> <20100929082603.28efd43c@jpeach-desktop> Message-ID: On Sep 29, 2010, at 7:26 AM, John Peach wrote: > With IANA? > > It's common knowledge that 465 is smtps, whatever else IANA might say. http://www.ietf.org/rfc/rfc4409.txt Here's what they've had to say over time: http://web.archive.org/web/20010519080902/http://www.iana.org/assignments/port-numbers Says it's "unassigned." Then they assign it to "URL Rendezvous" a few months after that. http://web.archive.org/web/20010813015738/http://www.iana.org/assignments/port-numbers We currently support SMTP submission over 465 since there are still some old cranky Outlook versions out there that simply don't appear to be able to support connecting to 587, but it's been 18 months since we got a call like that, so we'll probably be shutting that off soon. --Chris From bjorn at mork.no Wed Sep 29 13:06:02 2010 From: bjorn at mork.no (=?utf-8?Q?Bj=C3=B8rn_Mork?=) Date: Wed, 29 Sep 2010 15:06:02 +0200 Subject: Randy in Nevis In-Reply-To: <20100929082603.28efd43c@jpeach-desktop> (John Peach's message of "Wed, 29 Sep 2010 08:26:03 -0400") References: <86tylbtgiq.fsf@seastrom.com> <4CA0C68E.2070501@orthanc.ca> <3FDF6338-0C7E-49FB-B3E5-85BBD4100EC1@delong.com> <4CA20787.40906@rollernet.us> <8C26A4FDAE599041A13EB499117D3C28405FA863@ex-mb-2.corp.atlasnetworks.us> <20100928140511.77b9f1a2@jpeach-desktop> <87tyl89280.fsf@nemi.mork.no> <20100929082603.28efd43c@jpeach-desktop> Message-ID: <87mxr08zt1.fsf@nemi.mork.no> John Peach writes: > It's common knowledge that 465 is smtps, whatever else IANA might say. It's common knowledge that 465 *was* smtps. A decade ago. But it has never gone anywhere, and it is way overdue for an "obsolete" tag. Everyone actually caring about SMTP over SSL are using STARTTLS on port 25 and 587. The faster we kill SMTPS the better. Keeping it in current /etc/services and the like is only going to confuse people. Bj?rn From john-nanog at johnpeach.com Wed Sep 29 13:10:55 2010 From: john-nanog at johnpeach.com (John Peach) Date: Wed, 29 Sep 2010 09:10:55 -0400 Subject: Randy in Nevis In-Reply-To: <87mxr08zt1.fsf@nemi.mork.no> References: <86tylbtgiq.fsf@seastrom.com> <4CA0C68E.2070501@orthanc.ca> <3FDF6338-0C7E-49FB-B3E5-85BBD4100EC1@delong.com> <4CA20787.40906@rollernet.us> <8C26A4FDAE599041A13EB499117D3C28405FA863@ex-mb-2.corp.atlasnetworks.us> <20100928140511.77b9f1a2@jpeach-desktop> <87tyl89280.fsf@nemi.mork.no> <20100929082603.28efd43c@jpeach-desktop> <87mxr08zt1.fsf@nemi.mork.no> Message-ID: <20100929091055.27e73b33@jpeach-desktop> On Wed, 29 Sep 2010 15:06:02 +0200 Bj?rn Mork wrote: > John Peach writes: > > > It's common knowledge that 465 is smtps, whatever else IANA might > > say. > > It's common knowledge that 465 *was* smtps. A decade ago. But it has > never gone anywhere, and it is way overdue for an "obsolete" tag. > Everyone actually caring about SMTP over SSL are using STARTTLS on > port 25 and 587. The faster we kill SMTPS the better. Keeping it in > current /etc/services and the like is only going to confuse people. You obviously don't use a Blackberry with an imap(s) server..... -- John From owen at delong.com Wed Sep 29 13:16:04 2010 From: owen at delong.com (Owen DeLong) Date: Wed, 29 Sep 2010 06:16:04 -0700 Subject: Randy in Nevis In-Reply-To: <20100929091055.27e73b33@jpeach-desktop> References: <86tylbtgiq.fsf@seastrom.com> <4CA0C68E.2070501@orthanc.ca> <3FDF6338-0C7E-49FB-B3E5-85BBD4100EC1@delong.com> <4CA20787.40906@rollernet.us> <8C26A4FDAE599041A13EB499117D3C28405FA863@ex-mb-2.corp.atlasnetworks.us> <20100928140511.77b9f1a2@jpeach-desktop> <87tyl89280.fsf@nemi.mork.no> <20100929082603.28efd43c@jpeach-desktop> <87mxr08zt1.fsf@nemi.mork.no> <20100929091055.27e73b33@jpeach-desktop> Message-ID: <21187E8C-5204-4CCA-B145-B48FBED771AD@delong.com> On Sep 29, 2010, at 6:10 AM, John Peach wrote: > On Wed, 29 Sep 2010 15:06:02 +0200 > Bj?rn Mork wrote: > >> John Peach writes: >> >>> It's common knowledge that 465 is smtps, whatever else IANA might >>> say. >> >> It's common knowledge that 465 *was* smtps. A decade ago. But it has >> never gone anywhere, and it is way overdue for an "obsolete" tag. >> Everyone actually caring about SMTP over SSL are using STARTTLS on >> port 25 and 587. The faster we kill SMTPS the better. Keeping it in >> current /etc/services and the like is only going to confuse people. > > You obviously don't use a Blackberry with an imap(s) server..... > What does imap(s) have to do with 465/SMTP? Owen From john-nanog at johnpeach.com Wed Sep 29 13:23:10 2010 From: john-nanog at johnpeach.com (John Peach) Date: Wed, 29 Sep 2010 09:23:10 -0400 Subject: Randy in Nevis In-Reply-To: <21187E8C-5204-4CCA-B145-B48FBED771AD@delong.com> References: <86tylbtgiq.fsf@seastrom.com> <4CA0C68E.2070501@orthanc.ca> <3FDF6338-0C7E-49FB-B3E5-85BBD4100EC1@delong.com> <4CA20787.40906@rollernet.us> <8C26A4FDAE599041A13EB499117D3C28405FA863@ex-mb-2.corp.atlasnetworks.us> <20100928140511.77b9f1a2@jpeach-desktop> <87tyl89280.fsf@nemi.mork.no> <20100929082603.28efd43c@jpeach-desktop> <87mxr08zt1.fsf@nemi.mork.no> <20100929091055.27e73b33@jpeach-desktop> <21187E8C-5204-4CCA-B145-B48FBED771AD@delong.com> Message-ID: <20100929092310.348a15c4@jpeach-desktop> On Wed, 29 Sep 2010 06:16:04 -0700 Owen DeLong wrote: > > On Sep 29, 2010, at 6:10 AM, John Peach wrote: > > > On Wed, 29 Sep 2010 15:06:02 +0200 > > Bj?rn Mork wrote: > > > >> John Peach writes: > >> > >>> It's common knowledge that 465 is smtps, whatever else IANA might > >>> say. > >> > >> It's common knowledge that 465 *was* smtps. A decade ago. But it > >> has never gone anywhere, and it is way overdue for an "obsolete" > >> tag. Everyone actually caring about SMTP over SSL are using > >> STARTTLS on port 25 and 587. The faster we kill SMTPS the > >> better. Keeping it in current /etc/services and the like is only > >> going to confuse people. > > > > You obviously don't use a Blackberry with an imap(s) server..... > > > What does imap(s) have to do with 465/SMTP? Too early in the morning and I was not advocating maintaining SMTPS. -- John From cmaurand at xyonet.com Wed Sep 29 13:23:42 2010 From: cmaurand at xyonet.com (Curtis Maurand) Date: Wed, 29 Sep 2010 09:23:42 -0400 Subject: Software-based Border Router In-Reply-To: References: <20100926.115921.74701327.sthaug@nethelp.no> <221425418.6450.1285496120772.JavaMail.root@mailserver> <632cd89a3c2601509f182619bcfe669a.squirrel@www.xyonet.com> <4CA1E58A.3000104@xyonet.com> <8C26A4FDAE599041A13EB499117D3C28405FA766@ex-mb-2.corp.atlasnetworks.us> <4CA336C5.5000000@xyonet.com> Message-ID: <4CA33DDE.5010706@xyonet.com> On 9/29/2010 8:59 AM, Heath Jones wrote: > What's the real-world power consumption and heat like? 455 days shows > some pretty good reliability! > Cheers for the info Curtis That's a really good question. This is a small 260 watt supermicro short depth (14") 1u system I purchased from tigerdirect. Its roughly the same type of system that barracuda networks would sell you. You can purchase one from newegg with dual core atom 330 processors which would be even lower power for around $414. Its a nothing box and its not even breathing hard. its running on a 100mbps fiber. The speed tests that I've run show it running close to wire speed. It would probably run even better if I were using real server NIC's on it. I'm just using the two on board GB NIC's. It has an available PCI slot. Intel(R) Pentium(R) Dual CPU E2220 @ 2.40GHz Would I run an ISP on it? No. Would I deploy a much more capable box for a more robust environment, absolutely. This particular box is firewalling an insurance company. --Curtis From bjorn at mork.no Wed Sep 29 13:29:35 2010 From: bjorn at mork.no (=?utf-8?Q?Bj=C3=B8rn_Mork?=) Date: Wed, 29 Sep 2010 15:29:35 +0200 Subject: Randy in Nevis In-Reply-To: <20100929091055.27e73b33@jpeach-desktop> (John Peach's message of "Wed, 29 Sep 2010 09:10:55 -0400") References: <86tylbtgiq.fsf@seastrom.com> <4CA0C68E.2070501@orthanc.ca> <3FDF6338-0C7E-49FB-B3E5-85BBD4100EC1@delong.com> <4CA20787.40906@rollernet.us> <8C26A4FDAE599041A13EB499117D3C28405FA863@ex-mb-2.corp.atlasnetworks.us> <20100928140511.77b9f1a2@jpeach-desktop> <87tyl89280.fsf@nemi.mork.no> <20100929082603.28efd43c@jpeach-desktop> <87mxr08zt1.fsf@nemi.mork.no> <20100929091055.27e73b33@jpeach-desktop> Message-ID: <87iq1o8yps.fsf@nemi.mork.no> John Peach writes: > On Wed, 29 Sep 2010 15:06:02 +0200 > Bj?rn Mork wrote: > >> It's common knowledge that 465 *was* smtps. A decade ago. But it has >> never gone anywhere, and it is way overdue for an "obsolete" tag. >> Everyone actually caring about SMTP over SSL are using STARTTLS on >> port 25 and 587. The faster we kill SMTPS the better. Keeping it in >> current /etc/services and the like is only going to confuse people. > > You obviously don't use a Blackberry with an imap(s) server..... No, I obviously don't. But I'm eager to be educated: What the heck does imap(s) have to do with port 465/tcp? I can guess... I have also been frustrated while trying to configure all sorts of MUAs. But don't you think that you had been better off if the 465/tcp entry in /etc/services had been updated when it should, 5 years ago, on the system where that Blackberry MUA was developed? If you fix /etc/services today then maybe you don't have the same problem with your new Blackberry 5 years from now. Bj?rn From if at xip.at Wed Sep 29 13:39:51 2010 From: if at xip.at (Ingo Flaschberger) Date: Wed, 29 Sep 2010 15:39:51 +0200 (CEST) Subject: Software-based Border Router In-Reply-To: References: <20100926.115921.74701327.sthaug@nethelp.no> <221425418.6450.1285496120772.JavaMail.root@mailserver> <632cd89a3c2601509f182619bcfe669a.squirrel@www.xyonet.com> <4CA1E58A.3000104@xyonet.com> <8C26A4FDAE599041A13EB499117D3C28405FA766@ex-mb-2.corp.atlasnetworks.us> <4CA336C5.5000000@xyonet.com> Message-ID: > What's the real-world power consumption and heat like? 455 days shows > some pretty good reliability! I reached more than 700 days - then power cycle due (planned) power maintenance works. From dot at dotat.at Wed Sep 29 13:59:56 2010 From: dot at dotat.at (Tony Finch) Date: Wed, 29 Sep 2010 14:59:56 +0100 Subject: Randy in Nevis In-Reply-To: <87mxr08zt1.fsf@nemi.mork.no> References: <86tylbtgiq.fsf@seastrom.com> <4CA0C68E.2070501@orthanc.ca> <3FDF6338-0C7E-49FB-B3E5-85BBD4100EC1@delong.com> <4CA20787.40906@rollernet.us> <8C26A4FDAE599041A13EB499117D3C28405FA863@ex-mb-2.corp.atlasnetworks.us> <20100928140511.77b9f1a2@jpeach-desktop> <87tyl89280.fsf@nemi.mork.no> <20100929082603.28efd43c@jpeach-desktop> <87mxr08zt1.fsf@nemi.mork.no> Message-ID: On Wed, 29 Sep 2010, Bj?rn Mork wrote: > > It's common knowledge that 465 *was* smtps. A decade ago. But it has > never gone anywhere, and it is way overdue for an "obsolete" tag. > Everyone actually caring about SMTP over SSL are using STARTTLS on port > 25 and 587. Microsoft MUAs only supported STARTTLS on port 25 until Outlook 2007. If you wanted to do secure remote message submission and you wanted to avoid blocks on port 25, you had to use smtps on port 465. Lots of people are still using old Microsoft MUAs so service providers should still support smtps. This is typical of the Outlook team's attitude to standards. Tony. -- f.anthony.n.finch http://dotat.at/ HUMBER THAMES DOVER WIGHT PORTLAND: NORTH BACKING WEST OR NORTHWEST, 5 TO 7, DECREASING 4 OR 5, OCCASIONALLY 6 LATER IN HUMBER AND THAMES. MODERATE OR ROUGH. RAIN THEN FAIR. GOOD. From sethm at rollernet.us Wed Sep 29 14:53:38 2010 From: sethm at rollernet.us (Seth Mattinen) Date: Wed, 29 Sep 2010 07:53:38 -0700 Subject: Software-based Border Router In-Reply-To: <4CA33DDE.5010706@xyonet.com> References: <20100926.115921.74701327.sthaug@nethelp.no> <221425418.6450.1285496120772.JavaMail.root@mailserver> <632cd89a3c2601509f182619bcfe669a.squirrel@www.xyonet.com> <4CA1E58A.3000104@xyonet.com> <8C26A4FDAE599041A13EB499117D3C28405FA766@ex-mb-2.corp.atlasnetworks.us> <4CA336C5.5000000@xyonet.com> <4CA33DDE.5010706@xyonet.com> Message-ID: <4CA352F2.8040904@rollernet.us> On 9/29/10 6:23 AM, Curtis Maurand wrote: > be even lower power for around $414. Its a nothing box and its not even > breathing hard. its running on a 100mbps fiber. The speed tests that > I've run show it running close to wire speed. It would probably run > even better if I were using real server NIC's on it. I'm just using the > two on board GB NIC's. It has an available PCI slot. > What size packets? ~Seth From awacs at ziskind.us Wed Sep 29 16:26:48 2010 From: awacs at ziskind.us (N. Yaakov Ziskind) Date: Wed, 29 Sep 2010 12:26:48 -0400 Subject: AS11296 -- Hijacked? In-Reply-To: <20100929122520.GA12933@gsp.org> References: <72132.1285759377@tristatelogic.com> <20100929122520.GA12933@gsp.org> Message-ID: <20100929122647.C26503@egps.ziskind.us> Rich Kulawiec wrote (on Wed, Sep 29, 2010 at 08:25:20AM -0400): > On Wed, Sep 29, 2010 at 08:38:17AM -0300, jim deleskie wrote: > > As to his decision to block Gmail (or any other freemail provider), > everyone with sufficient knowledge in the field knows that these > operations are prolific and habitual sources of spam (via multiple > vectors, not just SMTP; Google accounts for more Usenet spam hitting > my filters than all other sources combined). It's thus not at all > unreasonable for some operations to revoke (some oor all of) their > privileges by way of self-defense. And, even if it *is* unreasonable, well, his network, his rules, right? "I block all SMTP traffic from IPV4 servers (clients?) which have odd numbers in the third octet." might not be a good idea for a high volume mail server with clients, but if it's your network, go for it. -- _________________________________________ Nachman Yaakov Ziskind, FSPA, LLM awacs at ziskind.us Attorney and Counselor-at-Law http://ziskind.us Economic Group Pension Services http://egps.com Actuaries and Employee Benefit Consultants From trelane at trelane.net Wed Sep 29 17:10:08 2010 From: trelane at trelane.net (Andrew Kirch) Date: Wed, 29 Sep 2010 13:10:08 -0400 Subject: AS11296 -- Hijacked? In-Reply-To: <20100929122647.C26503@egps.ziskind.us> References: <72132.1285759377@tristatelogic.com> <20100929122520.GA12933@gsp.org> <20100929122647.C26503@egps.ziskind.us> Message-ID: <4CA372F0.6000203@trelane.net> On 9/29/2010 12:26 PM, N. Yaakov Ziskind wrote: > "I block all SMTP traffic from IPV4 servers (clients?) which have odd > numbers in the third octet." might not be a good idea for a high volume > mail server with clients, but if it's your network, go for it. > Sadly this method would on average block 97% spam, 3% ham, and statistically be highly effective. From gbonser at seven.com Wed Sep 29 17:43:32 2010 From: gbonser at seven.com (George Bonser) Date: Wed, 29 Sep 2010 10:43:32 -0700 Subject: AS11296 -- Hijacked? In-Reply-To: References: <72132.1285759377@tristatelogic.com> Message-ID: <5A6D953473350C4B9995546AFE9939EE0A52B00F@RWC-EX1.corp.seven.com> > -----Original Message----- > From: Heath Jones > Sent: Wednesday, September 29, 2010 5:16 AM > To: Ronald F. Guilmette > Cc: nanog at nanog.org > Subject: Re: AS11296 -- Hijacked? > > Let me reword... > What is stopping someone coming on the list, making a claim like you > have in an attempt to actually cause a DOS attack, by having some > clumsy network engineers starting to block traffic in reaction to your > post? There would be several filters for this. Is the person reporting this a known network operator that people trust or is it some Joe Blow out of nowhere that nobody has heard of before? That would make a huge difference. Is the AS assigned to a company that is known to be defunct? That would be another flag. Why would a company that no longer exists have its ASN active and its IPs sending traffic? This would be particularly interesting if the carrier handling the traffic is not a carrier known to have a relationship with that AS in the past. So a pattern of ... AS works for many years, disappears for some period of time, company goes defunct, and some period of time later the AS appears on a completely different carrier without any reassignment from the registrar. Bottom line, there is more to it than someone just popping up on a list saying something. g From johnl at iecc.com Wed Sep 29 17:58:28 2010 From: johnl at iecc.com (John Levine) Date: 29 Sep 2010 17:58:28 -0000 Subject: What must one do to avoid Gmail's retarded non-spam filtering? In-Reply-To: <22257558.30.1285704909402.JavaMail.root@zimbra.caneris.com> Message-ID: <20100929175828.6135.qmail@joyce.lan> >We have proper A+PTR records on the edge MTAs, proper SPF records for >the originating domain, proper Return-Path and other headers, and so >on. There isn't anything that I can think of other than the content >itself which would be abnormal, and obviously the content is >repetitive and can't be changed much. Is there something obvious >which we've missed? What else goes out from that MTA? User forwarded mail? Mailing lists? random customer junk? It is a really good idea to separate your mail streams. These days it means separate IPs for users, transactions, forwards, and such, eventually different DKIM signatures will do the trick. R's, John From jeroen at mompl.net Wed Sep 29 18:11:43 2010 From: jeroen at mompl.net (Jeroen van Aart) Date: Wed, 29 Sep 2010 11:11:43 -0700 Subject: What must one do to avoid Gmail's retarded non-spam filtering? In-Reply-To: <14393847.0.1285715774095.JavaMail.root@zimbra.caneris.com> References: <14393847.0.1285715774095.JavaMail.root@zimbra.caneris.com> Message-ID: <4CA3815F.507@mompl.net> Erik L wrote: > Received-SPF: pass ... > Authentication-Results: mx.google.com; spf=pass ... > > So the problem is unlikely to be a SPF issue, as mentioned in my first e-mail. http://david.woodhou.se/why-not-spf.html The lack of SPF records should never be the reason to block an email. It's about time SPF is being laid to rest, it's broken, ineffective and a flawed concept. Well, it's effective in legitimising spammers and breaking forwarding for example, but otherwise... -- http://goldmark.org/jeff/stupid-disclaimers/ http://linuxmafia.com/~rick/faq/plural-of-virus.html From hj1980 at gmail.com Wed Sep 29 18:17:07 2010 From: hj1980 at gmail.com (Heath Jones) Date: Wed, 29 Sep 2010 19:17:07 +0100 Subject: AS11296 -- Hijacked? In-Reply-To: <5A6D953473350C4B9995546AFE9939EE0A52B00F@RWC-EX1.corp.seven.com> References: <72132.1285759377@tristatelogic.com> <5A6D953473350C4B9995546AFE9939EE0A52B00F@RWC-EX1.corp.seven.com> Message-ID: > Bottom line, there is more to it than someone just popping up on a list > saying something. If you have the time to go and investigate all of that yourself, its good to know you've thought about the metrics you would use. Sometimes, people do this thing called 'referencing'. Its basically where you list your sources of information and associated evidence that led you to your conclusion :) My question is a pretty simple one "Out of curiosity, what led you to this conclusion?", because there were no references.. Apparantly he has super-duper top secret methods that he doesn't want to share. That's fine - I won't waste my time with it anymore. From nathan at atlasnetworks.us Wed Sep 29 18:32:06 2010 From: nathan at atlasnetworks.us (Nathan Eisenberg) Date: Wed, 29 Sep 2010 18:32:06 +0000 Subject: AS11296 -- Hijacked? In-Reply-To: <5A6D953473350C4B9995546AFE9939EE0A52B00F@RWC-EX1.corp.seven.com> References: <72132.1285759377@tristatelogic.com> <5A6D953473350C4B9995546AFE9939EE0A52B00F@RWC-EX1.corp.seven.com> Message-ID: <8C26A4FDAE599041A13EB499117D3C28405FC28D@ex-mb-2.corp.atlasnetworks.us> > There would be several filters for this. Is the person reporting this a known > network operator that people trust or is it some Joe Blow out of nowhere > that nobody has heard of before? That would make a huge difference. Is > the AS assigned to a company that is known to be defunct? That would be > another flag. Why would a company that no longer exists have its ASN active > and its IPs sending traffic? This would be particularly interesting if the carrier > handling the traffic is not a carrier known to have a relationship with that AS > in the past. So a pattern of ... AS works for many years, disappears for some > period of time, company goes defunct, and some period of time later the AS > appears on a completely different carrier without any reassignment from the > registrar. Agree, and those are all good filters (except for the perilously fallacious appeal to authority). But none of these claims were made, and that's the source of this extended discussion. If those claims had been made, then this entire discussion could have been circumvented - and those that care could independently validate the claims. There is a LOT of danger to blindly blackholing networks simply because a trusted email address posts on a netops list. In my experience, netops people (NANOG'ers being an especially good example) tend to be largely logical, rational, skeptical beings. So in a nutshell: if the post had included what you're suggesting, we could at least go out and go: "oh, yes, he's right - that AS belongs to a dead company, and is coming from a very different carrier than it did when it was operating" AND "his email address has a history of posting reliable information of a similar nature" AND "his message is validly PGP signed so that we can trust that the owner of the email address sent the message" AND "his email is written in a way that recognizes that clued, skeptical individuals are going to carefully analyze it" THEN I would expect a very different set of responses from the list. But an email that says "I'm going to deliberately withhold all of the vital information I used to come to this conclusion, but request that you take action anyways" is going to consistently be roundfiled. Nathan From job at instituut.net Wed Sep 29 18:32:58 2010 From: job at instituut.net (Job W. J. Snijders) Date: Wed, 29 Sep 2010 20:32:58 +0200 Subject: LISP Works - Re: Facebook Issues/Outage in Southeast? In-Reply-To: References: <20100923173347.1E6D67EA@resin06.mta.everyone.net> <1E9490CA-3AC3-43DD-AE46-051927DE4C86@instituut.net> Message-ID: Dear Cameron, On Wed, Sep 29, 2010 at 3:27 AM, Cameron Byrne wrote: >> The fact that LISP does help in IPv6 Transition solutions (due to its inherent AF agnostic design), is compelling. As you say, real edge 2 edge is the goal - and LISP helps here, regardless of the AF. (you'll will still want to do multi-homing in IPv6, and ingress TE, and mobility, etc.). >> > > Sorry, when i said e2e w.r.t IPv6 i was talking about end to end, not > edge to edge. I think there is a big difference. Oops, i meant end to end too, don't know why I typed edge2edge. :-) > IMHO, ILNP is the more interesting solution and avoids expensive > encapsulation and questionable assumptions about ISP MTU, all my ISP > links are GigE and 10GigE and they are all set to default 1500 bytes > ... good or bad, this is just how they roll off the line from every > ISP in every city i buy transit... and LISP tunnels do not work so > well with 1500 byte MTU. I beg to differ, LISP works excellent with 1500 byte MTU. But you point out a significant aspect of LISP; hosts behind LISP rely a bit on path MTU discovery, with all it's benefits and drawbacks. But that's not a show stopper i've seen on the lisp beta network. We live in a world where PMTUD is daily practice, ILNP will not make PMTUD go away. My major concern with ILNP is that eventually all hosts need to be upgraded/changed to take advantage of ILNP. If we take a hard look at something like SCTP... it never was really populair in the wild even though it's in the Linux kernel. I'd rather load new software on hundreds CPE's then change ten thousands of hosts, with all variations, versions, servicepacks. Another example: the rate at which IPv6 has been adopted in operating systems is horrible, we cannot wait another 10 or so years. So I actually consider it one of the best features of LISP that hosts don't need to be changed and the scope has been reduced to just the 'edge' or 'CPE'. In this sense one might even consider LISP to be more backwards compatible then ILNP. :-) Last, ILNP has no viable plan for IPv4, an address family we cannot easily discard. The critique in draft-irtf-rrg-recommendation-14 on ILNP's hIPv4 is heavy, and can be summerized with: "It appears that hIPv4 involves major practical difficulties which mean that in its current form it is not suitable for IETF development.." Kind regards, Job Snijders From bbillon-ml at splio.fr Wed Sep 29 18:35:25 2010 From: bbillon-ml at splio.fr (Benjamin Billon) Date: Wed, 29 Sep 2010 20:35:25 +0200 Subject: What must one do to avoid Gmail's retarded non-spam filtering? In-Reply-To: <4CA2FF93.7070607@ac.upc.edu> References: <22257558.30.1285704909402.JavaMail.root@zimbra.caneris.com> <4CA2FF93.7070607@ac.upc.edu> Message-ID: <4CA386ED.3090209@splio.fr> > Have you tried DKIM signing? All email sent from Gmail is DKIM signed, > so they probably also support checking it and a valid signature may > lower your spam score. DKIM is definitively a must have for gmail. >> At least this isn't Hotmail where mail is just silently deleted with no NDR after it's accepted by their MTAs. If Hotmail is doing that to your messages, you're in a quite bad posture. That's their way to tell you "we don't like what you're sending at all". Did you consider hiring deliverability consultants? I'm afraid there is no magical way to reach inbox without a audit of your process and systems. Benjamin From erik_list at caneris.com Wed Sep 29 18:48:03 2010 From: erik_list at caneris.com (Erik L) Date: Wed, 29 Sep 2010 14:48:03 -0400 (EDT) Subject: What must one do to avoid Gmail's retarded non-spam filtering? In-Reply-To: <20100929175828.6135.qmail@joyce.lan> Message-ID: <30578298.214.1285786083304.JavaMail.root@zimbra.caneris.com> Thanks John. This was a common question that was asked off-list. That edge MTA is not used and has never been used by anything/anyone other than us. No customer mail flows or has flowed in or out via it ever. As I mentioned in my follow-up post, the issue at this point is that the domain has been blacklisted. I can send an identical message from the same MTA, changing only the From header, and it will be delivered to Inbox. Only when the From header contains @caneris.com will the message be delivered to spam. Any changes to the MTA IP, content, headers, etc. don't have any effect. Erik ----- Original Message ----- From: "John Levine" To: nanog at nanog.org Cc: "erik list" Sent: Wednesday, September 29, 2010 1:58:28 PM Subject: Re: What must one do to avoid Gmail's retarded non-spam filtering? >We have proper A+PTR records on the edge MTAs, proper SPF records for >the originating domain, proper Return-Path and other headers, and so >on. There isn't anything that I can think of other than the content >itself which would be abnormal, and obviously the content is >repetitive and can't be changed much. Is there something obvious >which we've missed? What else goes out from that MTA? User forwarded mail? Mailing lists? random customer junk? It is a really good idea to separate your mail streams. These days it means separate IPs for users, transactions, forwards, and such, eventually different DKIM signatures will do the trick. R's, John From erik_list at caneris.com Wed Sep 29 18:49:56 2010 From: erik_list at caneris.com (Erik L) Date: Wed, 29 Sep 2010 14:49:56 -0400 (EDT) Subject: What must one do to avoid Gmail's retarded non-spam filtering? In-Reply-To: <4CA3815F.507@mompl.net> Message-ID: <13351972.216.1285786196572.JavaMail.root@zimbra.caneris.com> I don't believe in SPF, which is why we don't use it to check inbound mail. I do believe in being able to communicate with our customers irrespective of which provider they use, and given that Hotmail in particular is extremely unforgiving with respect to SPF, we have no choice but to publish such records. ----- Original Message ----- From: "Jeroen van Aart" To: "nanog" Sent: Wednesday, September 29, 2010 2:11:43 PM Subject: Re: What must one do to avoid Gmail's retarded non-spam filtering? Erik L wrote: > Received-SPF: pass ... > Authentication-Results: mx.google.com; spf=pass ... > > So the problem is unlikely to be a SPF issue, as mentioned in my first > e-mail. http://david.woodhou.se/why-not-spf.html The lack of SPF records should never be the reason to block an email. It's about time SPF is being laid to rest, it's broken, ineffective and a flawed concept. Well, it's effective in legitimising spammers and breaking forwarding for example, but otherwise... -- http://goldmark.org/jeff/stupid-disclaimers/ http://linuxmafia.com/~rick/faq/plural-of-virus.html From sethm at rollernet.us Wed Sep 29 18:51:49 2010 From: sethm at rollernet.us (Seth Mattinen) Date: Wed, 29 Sep 2010 11:51:49 -0700 Subject: What must one do to avoid Gmail's retarded non-spam filtering? In-Reply-To: <30578298.214.1285786083304.JavaMail.root@zimbra.caneris.com> References: <30578298.214.1285786083304.JavaMail.root@zimbra.caneris.com> Message-ID: <4CA38AC5.2070704@rollernet.us> On 9/29/2010 11:48, Erik L wrote: > Thanks John. This was a common question that was asked off-list. That edge MTA is not used and has never been used by anything/anyone other than us. No customer mail flows or has flowed in or out via it ever. > > As I mentioned in my follow-up post, the issue at this point is that the domain has been blacklisted. I can send an identical message from the same MTA, changing only the From header, and it will be delivered to Inbox. Only when the From header contains @caneris.com will the message be delivered to spam. Any changes to the MTA IP, content, headers, etc. don't have any effect. > Do you let customers have addresses under that domain? ~Seth From bill at herrin.us Wed Sep 29 18:51:37 2010 From: bill at herrin.us (William Herrin) Date: Wed, 29 Sep 2010 14:51:37 -0400 Subject: AS11296 -- Hijacked? In-Reply-To: <20100929122520.GA12933@gsp.org> References: <72132.1285759377@tristatelogic.com> <20100929122520.GA12933@gsp.org> Message-ID: On Wed, Sep 29, 2010 at 8:25 AM, Rich Kulawiec wrote: > On Wed, Sep 29, 2010 at 08:38:17AM -0300, jim deleskie wrote: >> WOW full of yourself much. ? Many of us use gmail and others to manage the >> load of mail we received from various lists. ?I doubt we anyone needs >> your sympathies, > > Ron is one of the most senior anti-spam people on this planet, and > has long since demonstrated not only serious clue, but formidable > research and analysis skills. Yet he has so much trouble programming his mail filter to differentiate between legitimate and spam email coming out of Google that he feels the need to block all email from Google. Are we to question his skill? Or just his judgment? If Ron's as smart as you say then he's smart enough to take some famous advice: "A decent respect to the opinions of mankind requires that they should declare the causes." If it's good enough for creating a country, it's good enough for a lesser call to action -- like filtering an AS and its netblocks. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From gbonser at seven.com Wed Sep 29 18:44:27 2010 From: gbonser at seven.com (George Bonser) Date: Wed, 29 Sep 2010 11:44:27 -0700 Subject: AS11296 -- Hijacked? In-Reply-To: <8C26A4FDAE599041A13EB499117D3C28405FC28D@ex-mb-2.corp.atlasnetworks.us> References: <72132.1285759377@tristatelogic.com><5A6D953473350C4B9995546AFE9939EE0A52B00F@RWC-EX1.corp.seven.com> <8C26A4FDAE599041A13EB499117D3C28405FC28D@ex-mb-2.corp.atlasnetworks.us> Message-ID: <5A6D953473350C4B9995546AFE9939EE0A52B014@RWC-EX1.corp.seven.com> > -----Original Message----- > From: Nathan Eisenberg > Sent: Wednesday, September 29, 2010 11:32 AM > To: nanog at nanog.org > Subject: RE: AS11296 -- Hijacked? > from the list. > > But an email that says "I'm going to deliberately withhold all of the > vital information I used to come to this conclusion, but request that > you take action anyways" is going to consistently be roundfiled. > > Nathan > Maybe you didn't recognize the original poster, but I did, and I would take what he had to say at least seriously enough to have a look. His followup mail, while not giving people the information they wanted (as if it really matters) did mention that the upstream appears to have cut them off. That is a pretty good indication that *something* was going on there. I don't believe it is anyone's job here to conform to the expectations of anyone else aside from general list etiquette and some level of sanity. He put the information out, it is up to the reader in how they weight it. I don't understand your continued banging on the issue. All he did was put information out there. He doesn't need to meet your criteria, you are free to apply that as you will in the privacy of your own cubicle. G From justin.horstman at gorillanation.com Wed Sep 29 18:53:27 2010 From: justin.horstman at gorillanation.com (Justin Horstman) Date: Wed, 29 Sep 2010 11:53:27 -0700 Subject: AS11296 -- Hijacked? In-Reply-To: <5A6D953473350C4B9995546AFE9939EE0A52B00F@RWC-EX1.corp.seven.com> References: <72132.1285759377@tristatelogic.com> <5A6D953473350C4B9995546AFE9939EE0A52B00F@RWC-EX1.corp.seven.com> Message-ID: <8C164D3BAF7C7F41B9B286385037B1310FAD4596F6@lax-exch-fe-01.gorillanation.local> > -----Original Message----- > From: George Bonser [mailto:gbonser at seven.com] > Sent: Wednesday, September 29, 2010 10:44 AM > To: Heath Jones; Ronald F. Guilmette > Cc: nanog at nanog.org > Subject: RE: AS11296 -- Hijacked? Is the person reporting this > a > known network operator that people trust or is it some Joe Blow out of > nowhere that nobody has heard of before? That would make a huge > difference. Going to his website....looks like Joe Blow...Googling his name/email/domain, still nothing that would lead me to believe he is network Savvy. So coming from Joe Blow network Dude....he too is just Joe Blow. Just a little perspective for you from the bottom of the pile. ~J From nathan at atlasnetworks.us Wed Sep 29 19:05:12 2010 From: nathan at atlasnetworks.us (Nathan Eisenberg) Date: Wed, 29 Sep 2010 19:05:12 +0000 Subject: AS11296 -- Hijacked? In-Reply-To: <5A6D953473350C4B9995546AFE9939EE0A52B014@RWC-EX1.corp.seven.com> References: <72132.1285759377@tristatelogic.com><5A6D953473350C4B9995546AFE9939EE0A52B00F@RWC-EX1.corp.seven.com> <8C26A4FDAE599041A13EB499117D3C28405FC28D@ex-mb-2.corp.atlasnetworks.us> <5A6D953473350C4B9995546AFE9939EE0A52B014@RWC-EX1.corp.seven.com> Message-ID: <8C26A4FDAE599041A13EB499117D3C28405FC332@ex-mb-2.corp.atlasnetworks.us> > Maybe you didn't recognize the original poster, but I did, and I would take > what he had to say at least seriously enough to have a look. His followup > mail, while not giving people the information they wanted (as if it really > matters) did mention that the upstream appears to have cut them off. That > is a pretty good indication that *something* was going on there. > > I don't believe it is anyone's job here to conform to the expectations of > anyone else aside from general list etiquette and some level of sanity. He > put the information out, it is up to the reader in how they weight it. I don't > understand your continued banging on the issue. All he did was put > information out there. He doesn't need to meet your criteria, you are free to > apply that as you will in the privacy of your own cubicle. George, Again - appealing to personal authority is a fallacy. It carries no logical weight who the poster is, and has no place in a decision making process of such magnitude. No one has to conform to any standard, and I don't think I suggested otherwise. What I did suggest is what would be required in such an email to convince me personally to take any action. The very point of posting a hijacking notification is to convince people to take action, so it's only reasonable to make such a notification as thorough and supported as possible. And it is in the best interests of the process to review communications issues afterwards - if the OP is genuinely interested in helping the internet by letting us know when an AS has been hijacked, then he should certainly appreciate any feedback on how to make those notifications more effective. I'm also not sure what you mean by 'continued banging on the issue'. This is my first email in this thread... Nathan From joseph.sniderman at thoroquel.org Wed Sep 29 19:29:10 2010 From: joseph.sniderman at thoroquel.org (Joe Sniderman) Date: Wed, 29 Sep 2010 15:29:10 -0400 Subject: What must one do to avoid Gmail's retarded non-spam filtering? In-Reply-To: <10950451.138.1285733133371.JavaMail.root@zimbra.caneris.com> References: <10950451.138.1285733133371.JavaMail.root@zimbra.caneris.com> Message-ID: <4CA39390.6F38544A5447496F303132393339@mid.thoroquel.org> On 09/29/2010 12:05 AM, Erik L wrote: > Google appears to have blacklisted our domain. From the edge MTA, I > sent three messages, differing only in the From header: 1. valid > email @klssys.com 2. valid email @caneris.com 3. abc123 at caneris.com > > 1 not spam; 2 & 3 spam Ok, so its the domain not the IP. You're a DSL provider, right? IP's assigned to customers have PTR's in caneris.com, right? [..snip..] > ----- Original Message ----- From: "Erik L" > To: "William Pitcock" Cc: > nanog at nanog.org Sent: Tuesday, September 28, 2010 7:17:45 PM Subject: > Re: What must one do to avoid Gmail's retarded non-spam filtering? > > Hi William, > > I do so for our entire IP space on a regular basis. The edge MTA I > mentioned in the reply to Bill shows up as "Neutral" there. Ok, but there are a couple customer IP's that show up as "Poor" there, with rDNS in caneris.com not in klssys.com. One of those is on CBL (and XBL) and PSBL, and is spamming using your domain: http://psbl.surriel.com/evidence?ip=199.19.168.33&action=Check+evidence Its not PBL listed even though its a dynamic IP it seems: http://www.spamhaus.org/query/bl?ip=199.19.168.33 That would be an SPF pass as well, because of: caneris.com. 3600 IN TXT "v=spf1 a mx ptr -all" So, from the receiving end it could easily look like its one of caneris.com's outbound servers.. But not one of klssys.com's servers. Maybe this has something to do with the problem. HTH, Joe -- Joe Sniderman From gbonser at seven.com Wed Sep 29 19:31:21 2010 From: gbonser at seven.com (George Bonser) Date: Wed, 29 Sep 2010 12:31:21 -0700 Subject: AS11296 -- Hijacked? In-Reply-To: <8C26A4FDAE599041A13EB499117D3C28405FC332@ex-mb-2.corp.atlasnetworks.us> References: <72132.1285759377@tristatelogic.com><5A6D953473350C4B9995546AFE9939EE0A52B00F@RWC-EX1.corp.seven.com><8C26A4FDAE599041A13EB499117D3C28405FC28D@ex-mb-2.corp.atlasnetworks.us><5A6D953473350C4B9995546AFE9939EE0A52B014@RWC-EX1.corp.seven.com> <8C26A4FDAE599041A13EB499117D3C28405FC332@ex-mb-2.corp.atlasnetworks.us> Message-ID: <5A6D953473350C4B9995546AFE9939EE0A52B019@RWC-EX1.corp.seven.com> > -----Original Message----- > From: Nathan Eisenberg [mailto:nathan at atlasnetworks.us] > Sent: Wednesday, September 29, 2010 12:05 PM > To: nanog at nanog.org > Subject: RE: AS11296 -- Hijacked? > > > Maybe you didn't recognize the original poster, but I did, and I > would take > > what he had to say at least seriously enough to have a look. His > followup > > mail, while not giving people the information they wanted (as if it > really > > matters) did mention that the upstream appears to have cut them off. > That > > is a pretty good indication that *something* was going on there. > > > > I don't believe it is anyone's job here to conform to the > expectations of > > anyone else aside from general list etiquette and some level of > sanity. He > > put the information out, it is up to the reader in how they weight > it. I don't > > understand your continued banging on the issue. All he did was put > > information out there. He doesn't need to meet your criteria, you > are free to > > apply that as you will in the privacy of your own cubicle. > > George, > > Again - appealing to personal authority is a fallacy. It carries no > logical weight who the poster is, and has no place in a decision making > process of such magnitude. Again, nobody said the original poster had any authority over anything. He posted a suspicion. It would be up to the individual entities involved to decide if they actually want to take any action based on that or not. Nobody said anyone had to do anything and anyone who blocks traffic based ONLY on a message to a mailing list is an imbecile anyway. Nobody handing any major amounts of traffic is going to base their filtration on third party mailing list postings so I really don't see what the issue is. I read the original post as a call to look into it and that they were going to be reported to ARIN for further looking into. The original posting said "some folks may wish to blackhole the above" and that is all. But it did strike me as odd that a North Carolina regional ISP would have only a single peer and that peer has no presence that I can determine in North Carolina. From johnl at iecc.com Wed Sep 29 19:49:16 2010 From: johnl at iecc.com (John R. Levine) Date: 29 Sep 2010 15:49:16 -0400 Subject: What must one do to avoid Gmail's retarded non-spam filtering? In-Reply-To: <30578298.214.1285786083304.JavaMail.root@zimbra.caneris.com> References: <30578298.214.1285786083304.JavaMail.root@zimbra.caneris.com> Message-ID: > As I mentioned in my follow-up post, the issue at this point is that the > domain has been blacklisted. Most peculiar. Since gmail is driven by algorithms, that would suggest that a lot of your recipients are reporting your mail as spam, which I can assure you people do, no matter how legitimate and opt-in it is. Do you have feedback loops set up? Google doesn't offer one, but AOL, Yahoo, Hotmail, and other large ISPs do, which will let you figure out what sorts of mail people are complaining about so you can perhaps send less of it. R's, John From a.goermer at ecircle.com Wed Sep 29 19:53:55 2010 From: a.goermer at ecircle.com (=?Windows-1252?Q?Andr=E9_G=F6rmer?=) Date: Wed, 29 Sep 2010 21:53:55 +0200 Subject: AW: What must one do to avoid Gmail's retarded non-spam filtering? In-Reply-To: References: <30578298.214.1285786083304.JavaMail.root@zimbra.caneris.com> Message-ID: <6EB60DFB1099634AA8DAF3FF69235590015A5DCFF0@humboldt.muc.ecircle.de> Hello, I would also recommend to implement the list unsubscribe header, because google is supporting that kind of user feedback to senders. http://www.list-unsubscribe.com/ Regards, Andr? Andr? G?rmer Senior Deliverability Manager eCircle P: +49 89 12009-762 | F: +49 89 12009-750 | E: a.goermer at ecircle.com Nymphenburger Str. 86, 80636 M?nchen Stay in touch Web: www.ecircle.com/de | Newsletter: www.ecircle.com/index.php?id=63&L=0 F?r Hilfe mit dem eC-messenger wenden Sie sich bitte an unseren Support unter Tel +49 (0)89 120 09 600 oder support-de at ecircle.com Neuste Untersuchungen Ein unschlagbares Doppel: E-Mail-Marketing & Webanalyse Download Whitepaper: www.ecircle.com/index.php?id=61&L=0 eCircle GmbH, HRB 184 478, Handelsregister M?nchen, Gesch?ftsf?hrung: Volker Wiewer (Vorsitzender), Alexander Meyer, Thomas Wilke, Vorsitzender des Aufsichtsrates: Dr. Arnold Bahlmann-----Urspr?ngliche Nachricht----- Von: John R. Levine [mailto:johnl at iecc.com] Gesendet: Mittwoch, 29. September 2010 21:49 An: Erik L Cc: nanog at nanog.org Betreff: Re: What must one do to avoid Gmail's retarded non-spam filtering? > As I mentioned in my follow-up post, the issue at this point is that the > domain has been blacklisted. Most peculiar. Since gmail is driven by algorithms, that would suggest that a lot of your recipients are reporting your mail as spam, which I can assure you people do, no matter how legitimate and opt-in it is. Do you have feedback loops set up? Google doesn't offer one, but AOL, Yahoo, Hotmail, and other large ISPs do, which will let you figure out what sorts of mail people are complaining about so you can perhaps send less of it. R's, John From erik_list at caneris.com Wed Sep 29 20:03:46 2010 From: erik_list at caneris.com (Erik L) Date: Wed, 29 Sep 2010 16:03:46 -0400 (EDT) Subject: What must one do to avoid Gmail's retarded non-spam filtering? In-Reply-To: <29383196.244.1285789865259.JavaMail.root@zimbra.caneris.com> Message-ID: <21007373.246.1285790626812.JavaMail.root@zimbra.caneris.com> Thanks, this is a possibility. However, that customer IP has been dealt with and hasn't been spamming for more than 60 hours at most (it's actually part of a dynamic DSL pool where port 25 outbound was supposed to have been blocked). Our problem appears to have started before the 27th. Earlier today I noticed that the SPF record had "a" and "ptr" in it and changed it to "mx" only, as it should be in our case. What I find most peculiar is none of these having problems: 1. Competitors over 10 times our size (similar % of gmail users), with invalid SPF records, no DKIM, who don't do *ANY* of what anyone here or off-list has suggested, who have PTRs for their DSL customers similar to ours (and didn't have a port 25 block), who've been blasting maintenance notices for years 2. Amazon, eBay, PayPal, Dell, etc. 3. Facebook with their ***user-generated content, in HTML*** ----- Original Message ----- From: "Joe Sniderman" To: nanog at nanog.org Sent: Wednesday, September 29, 2010 3:29:10 PM Subject: Re: What must one do to avoid Gmail's retarded non-spam filtering? On 09/29/2010 12:05 AM, Erik L wrote: > Google appears to have blacklisted our domain. From the edge MTA, I > sent three messages, differing only in the From header: 1. valid > email @klssys.com 2. valid email @caneris.com 3. abc123 at caneris.com > > 1 not spam; 2 & 3 spam Ok, so its the domain not the IP. You're a DSL provider, right? IP's assigned to customers have PTR's in caneris.com, right? [..snip..] > ----- Original Message ----- From: "Erik L" > To: "William Pitcock" Cc: > nanog at nanog.org Sent: Tuesday, September 28, 2010 7:17:45 PM Subject: > Re: What must one do to avoid Gmail's retarded non-spam filtering? > > Hi William, > > I do so for our entire IP space on a regular basis. The edge MTA I > mentioned in the reply to Bill shows up as "Neutral" there. Ok, but there are a couple customer IP's that show up as "Poor" there, with rDNS in caneris.com not in klssys.com. One of those is on CBL (and XBL) and PSBL, and is spamming using your domain: http://psbl.surriel.com/evidence?ip=199.19.168.33&action=Check+evidence Its not PBL listed even though its a dynamic IP it seems: http://www.spamhaus.org/query/bl?ip=199.19.168.33 That would be an SPF pass as well, because of: caneris.com. 3600 IN TXT "v=spf1 a mx ptr -all" So, from the receiving end it could easily look like its one of caneris.com's outbound servers.. But not one of klssys.com's servers. Maybe this has something to do with the problem. HTH, Joe -- Joe Sniderman From erik_list at caneris.com Wed Sep 29 20:04:17 2010 From: erik_list at caneris.com (Erik L) Date: Wed, 29 Sep 2010 16:04:17 -0400 (EDT) Subject: What must one do to avoid Gmail's retarded non-spam filtering? In-Reply-To: <4CA38AC5.2070704@rollernet.us> Message-ID: <22150298.248.1285790657218.JavaMail.root@zimbra.caneris.com> No ----- Original Message ----- From: "Seth Mattinen" To: nanog at nanog.org Sent: Wednesday, September 29, 2010 2:51:49 PM Subject: Re: What must one do to avoid Gmail's retarded non-spam filtering? On 9/29/2010 11:48, Erik L wrote: > Thanks John. This was a common question that was asked off-list. That > edge MTA is not used and has never been used by anything/anyone other > than us. No customer mail flows or has flowed in or out via it ever. > > As I mentioned in my follow-up post, the issue at this point is that > the domain has been blacklisted. I can send an identical message from > the same MTA, changing only the From header, and it will be delivered > to Inbox. Only when the From header contains @caneris.com will the > message be delivered to spam. Any changes to the MTA IP, content, > headers, etc. don't have any effect. > Do you let customers have addresses under that domain? ~Seth From scott at doc.net.au Wed Sep 29 20:06:31 2010 From: scott at doc.net.au (Scott Howard) Date: Wed, 29 Sep 2010 13:06:31 -0700 Subject: AS11296 -- Hijacked? In-Reply-To: <20100929122647.C26503@egps.ziskind.us> References: <72132.1285759377@tristatelogic.com> <20100929122520.GA12933@gsp.org> <20100929122647.C26503@egps.ziskind.us> Message-ID: On Wed, Sep 29, 2010 at 9:26 AM, N. Yaakov Ziskind wrote: > And, even if it *is* unreasonable, well, his network, his rules, right? > > "I block all SMTP traffic from IPV4 servers (clients?) which have odd > numbers in the third octet." might not be a good idea for a high volume > mail server with clients, but if it's your network, go for it. > Except that this thread started with a recommendation to block an entire AS, containing a reasonable number of networks. Recommendations such as that are only as credible as the source they are coming from, and knowing that the person making the request also believes that blocking all mail from gmail.com is a valid anti-spam technique probably results in a "different" credibility level than one might otherwise have. Scott. From jlogginsccie at gmail.com Wed Sep 29 20:20:48 2010 From: jlogginsccie at gmail.com (Jesse Loggins) Date: Wed, 29 Sep 2010 13:20:48 -0700 Subject: RIP Justification Message-ID: A group of engineers and I were having a design discussion about routing protocols including RIP and static routing and the justifications of use for each protocol. One very interesting discussion was surrounding RIP and its use versus a protocol like OSPF. It seems that many Network Engineers consider RIP an old antiquated protocol that should be thrown in back of a closet "never to be seen or heard from again". Some even preferred using a more complex protocol like OSPF instead of RIP. I am of the opinion that every protocol has its place, which seems to be contrary to some engineers way of thinking. This leads to my question. What are your views of when and where the RIP protocol is useful? Please excuse me if this is the incorrect forum for such questions. -- Jesse Loggins CCIE#14661 (R&S, Service Provider) From patrick at ianai.net Wed Sep 29 20:27:05 2010 From: patrick at ianai.net (Patrick W. Gilmore) Date: Wed, 29 Sep 2010 16:27:05 -0400 Subject: RIP Justification In-Reply-To: References: Message-ID: <5F3648B7-3B61-4E8C-8B64-03740830F5AE@ianai.net> On Sep 29, 2010, at 4:20 PM, Jesse Loggins wrote: > A group of engineers and I were having a design discussion about routing > protocols including RIP and static routing and the justifications of use for > each protocol. One very interesting discussion was surrounding RIP and its > use versus a protocol like OSPF. It seems that many Network Engineers > consider RIP an old antiquated protocol that should be thrown in back of a > closet "never to be seen or heard from again". Some even preferred using a > more complex protocol like OSPF instead of RIP. I am of the opinion that > every protocol has its place, which seems to be contrary to some engineers > way of thinking. This leads to my question. What are your views of when and > where the RIP protocol is useful? Please excuse me if this is the incorrect > forum for such questions. RIP has one property no "modern" protocol has. It works on simplex links (e.g. high-speed satellite downlink with low-speed terrestrial uplink). Is that useful? I don't know, but it is still a fact. -- TTFN, patrick From gladney at stsci.edu Wed Sep 29 20:29:16 2010 From: gladney at stsci.edu (Gary Gladney) Date: Wed, 29 Sep 2010 16:29:16 -0400 Subject: RIP Justification In-Reply-To: References: Message-ID: <003801cb6014$fd2f0280$f78d0780$@edu> I would think it would depend on the complexity of the network and how the network advertises routes to peer networks. I'm always in favor the simpler the better but with RIP you do lose the ability to use variable bit masks (CIDR) and faster routing algorithms like DUAL used in Cisco routers and I'm not a big fan of OSPF. Gary -----Original Message----- From: Jesse Loggins [mailto:jlogginsccie at gmail.com] Sent: Wednesday, September 29, 2010 4:21 PM To: nanog at nanog.org Subject: RIP Justification A group of engineers and I were having a design discussion about routing protocols including RIP and static routing and the justifications of use for each protocol. One very interesting discussion was surrounding RIP and its use versus a protocol like OSPF. It seems that many Network Engineers consider RIP an old antiquated protocol that should be thrown in back of a closet "never to be seen or heard from again". Some even preferred using a more complex protocol like OSPF instead of RIP. I am of the opinion that every protocol has its place, which seems to be contrary to some engineers way of thinking. This leads to my question. What are your views of when and where the RIP protocol is useful? Please excuse me if this is the incorrect forum for such questions. -- Jesse Loggins CCIE#14661 (R&S, Service Provider) From hj1980 at gmail.com Wed Sep 29 20:33:39 2010 From: hj1980 at gmail.com (Heath Jones) Date: Wed, 29 Sep 2010 21:33:39 +0100 Subject: RIP Justification In-Reply-To: References: Message-ID: IPVPN arrangement with multiple sites & no redundancy for each small site. RIP to advertise networks from each site towards cloud, quick and easy. From w3yni1 at gmail.com Wed Sep 29 20:34:59 2010 From: w3yni1 at gmail.com (Charles Mills) Date: Wed, 29 Sep 2010 16:34:59 -0400 Subject: RIP Justification In-Reply-To: <5F3648B7-3B61-4E8C-8B64-03740830F5AE@ianai.net> References: <5F3648B7-3B61-4E8C-8B64-03740830F5AE@ianai.net> Message-ID: Loss of using VLSM's is a big thing to give up. You can go to RIPv2 and get that however. Would work for small networks to stay under the hop-count limit as it is still distance-vector. On Wed, Sep 29, 2010 at 4:27 PM, Patrick W. Gilmore wrote: > On Sep 29, 2010, at 4:20 PM, Jesse Loggins wrote: > > > A group of engineers and I were having a design discussion about routing > > protocols including RIP and static routing and the justifications of use > for > > each protocol. One very interesting discussion was surrounding RIP and > its > > use versus a protocol like OSPF. It seems that many Network Engineers > > consider RIP an old antiquated protocol that should be thrown in back of > a > > closet "never to be seen or heard from again". Some even preferred using > a > > more complex protocol like OSPF instead of RIP. I am of the opinion that > > every protocol has its place, which seems to be contrary to some > engineers > > way of thinking. This leads to my question. What are your views of when > and > > where the RIP protocol is useful? Please excuse me if this is the > incorrect > > forum for such questions. > > RIP has one property no "modern" protocol has. It works on simplex links > (e.g. high-speed satellite downlink with low-speed terrestrial uplink). > > Is that useful? I don't know, but it is still a fact. > > -- > TTFN, > patrick > > > -- ===================================== Charles L. Mills Westmoreland Co. ARES EC Amateur Radio Callsign W3YNI Email: w3yni1 at gmail.com From chris at travelingtech.net Wed Sep 29 20:35:06 2010 From: chris at travelingtech.net (Christopher Gatlin) Date: Wed, 29 Sep 2010 15:35:06 -0500 Subject: RIP Justification In-Reply-To: <003801cb6014$fd2f0280$f78d0780$@edu> References: <003801cb6014$fd2f0280$f78d0780$@edu> Message-ID: RIPv2 is a great dynamic routing protocol for exchanging routes with untrusted networks. RIPv2 has adjustable timers, filters, supports VLSM and MD5 authentication. Since it's distance vector it's much easier to filter than a protocol that uses a link state database that must be the same across an entire area. Chris On Wed, Sep 29, 2010 at 3:29 PM, Gary Gladney wrote: > I would think it would depend on the complexity of the network and how the > network advertises routes to peer networks. I'm always in favor the > simpler > the better but with RIP you do lose the ability to use variable bit masks > (CIDR) and faster routing algorithms like DUAL used in Cisco routers and > I'm > not a big fan of OSPF. > > Gary > > -----Original Message----- > From: Jesse Loggins [mailto:jlogginsccie at gmail.com] > Sent: Wednesday, September 29, 2010 4:21 PM > To: nanog at nanog.org > Subject: RIP Justification > > A group of engineers and I were having a design discussion about routing > protocols including RIP and static routing and the justifications of use > for > each protocol. One very interesting discussion was surrounding RIP and its > use versus a protocol like OSPF. It seems that many Network Engineers > consider RIP an old antiquated protocol that should be thrown in back of a > closet "never to be seen or heard from again". Some even preferred using a > more complex protocol like OSPF instead of RIP. I am of the opinion that > every protocol has its place, which seems to be contrary to some engineers > way of thinking. This leads to my question. What are your views of when and > where the RIP protocol is useful? Please excuse me if this is the incorrect > forum for such questions. > > -- > Jesse Loggins > CCIE#14661 (R&S, Service Provider) > > > From gbonser at seven.com Wed Sep 29 20:37:27 2010 From: gbonser at seven.com (George Bonser) Date: Wed, 29 Sep 2010 13:37:27 -0700 Subject: RIP Justification In-Reply-To: <003801cb6014$fd2f0280$f78d0780$@edu> References: <003801cb6014$fd2f0280$f78d0780$@edu> Message-ID: <5A6D953473350C4B9995546AFE9939EE0A52B01E@RWC-EX1.corp.seven.com> > -----Original Message----- > From: Gary Gladney > Sent: Wednesday, September 29, 2010 1:29 PM > To: 'Jesse Loggins'; nanog at nanog.org > Subject: RE: RIP Justification > > with RIP you do lose the ability to use variable bit > masks > (CIDR) and faster routing algorithms like DUAL used in Cisco routers > and I'm > not a big fan of OSPF. > > Gary I would think most people using RIP with IPv4 would use RIPv2 which does allow CIDR. From christian.martin at teliris.com Wed Sep 29 20:40:44 2010 From: christian.martin at teliris.com (Christian Martin) Date: Wed, 29 Sep 2010 20:40:44 -0000 Subject: RIP Justification In-Reply-To: References: Message-ID: <12713BE2-1F84-42AC-A29C-97E0B092138A@teliris.com> On Sep 29, 2010, at 4:20 PM, Jesse Loggins wrote: > A group of engineers and I were having a design discussion about routing > protocols including RIP and static routing and the justifications of use for > each protocol. One very interesting discussion was surrounding RIP and its > use versus a protocol like OSPF. It seems that many Network Engineers > consider RIP an old antiquated protocol that should be thrown in back of a > closet "never to be seen or heard from again". Some even preferred using a > more complex protocol like OSPF instead of RIP. I am of the opinion that > every protocol has its place, which seems to be contrary to some engineers > way of thinking. This leads to my question. What are your views of when and > where the RIP protocol is useful? Please excuse me if this is the incorrect > forum for such questions. > I'd argue that in order to do anything useful (read: moderately sized) with RIP (aside from supporting legacy devices lacking anything else and as Patrick mentioned handling asymmetric links), you actually need to _add_ complexity in order to make it work ?? if you can at all. The lack of path vectoring limits network diameter due to counting to infinity, redundancy requires the use of hold down timers (which are proportionate to the diameter of the network), etc. Antilock brakes are "complex" from an mechanical perspective. But the act of braking is the same. Turn on the protocol. Add the necessary interfaces. Subnet accordingly. Summarize where possible. Walk away. "Let the machines do the work." -Vijay Gill (most recently as I recall) C > -- > Jesse Loggins > CCIE#14661 (R&S, Service Provider) From jfbeam at gmail.com Wed Sep 29 20:47:01 2010 From: jfbeam at gmail.com (Ricky Beam) Date: Wed, 29 Sep 2010 16:47:01 -0400 Subject: RIP Justification In-Reply-To: References: Message-ID: On Wed, 29 Sep 2010 16:20:48 -0400, Jesse Loggins wrote: > It seems that many Network Engineers consider RIP an old antiquated > protocol that should be thrown in back of a closet "never to be seen or > heard from again". That is the correct way to think about RIP. (RIPv1 specific) In 99% of the cases where I've seen RIP used (over 2 decades), they would've been better off with static routes. (or they needed something a lot more complex/robust... say, a power company running RIPv1 over their entire network.) The 1% where it was a necessary evil... dialup networking where the only routing protocol supported was RIP (v2) [netblazers] -- static IP clients had to be able to land anywhere -- but RIP only lived on the local segment, OSPF took over network-wide. (Later MaxTNT's were setup with OSPF stub areas so they didn't have to have a full route table.) BTW, ALL other routing protocols are more complex than RIP. One cannot get any simpler than RIP. --Ricky From stephen at sprunk.org Wed Sep 29 20:45:43 2010 From: stephen at sprunk.org (Stephen Sprunk) Date: Wed, 29 Sep 2010 15:45:43 -0500 Subject: RIP Justification In-Reply-To: References: Message-ID: <4CA3A577.1080508@sprunk.org> On 29 Sep 2010 15:20, Jesse Loggins wrote: > A group of engineers and I were having a design discussion about routing protocols including RIP and static routing and the justifications of use for each protocol. One very interesting discussion was surrounding RIP and its use versus a protocol like OSPF. It seems that many Network Engineers consider RIP an old antiquated protocol that should be thrown in back of a closet "never to be seen or heard from again". Some even preferred using a more complex protocol like OSPF instead of RIP. I am of the opinion that every protocol has its place, which seems to be contrary to some engineers way of thinking. This leads to my question. What are your views of when and where the RIP protocol is useful? Please excuse me if this is the incorrect forum for such questions. (I assume "RIP" above refers to RIPv2.) When the automobile was developed, plenty of folks thought horses were obsolete and would fall completely out of use. However, the reality is that there are still some things horses are better at, e.g. terrain that automobiles (even 4WD) simply can't navigate, places where automobiles are banned for safety, aesthetic and/or environmental reasons, etc. Newer isn't always better. 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/pkcs7-signature Size: 3646 bytes Desc: S/MIME Cryptographic Signature URL: From hj1980 at gmail.com Wed Sep 29 20:52:01 2010 From: hj1980 at gmail.com (Heath Jones) Date: Wed, 29 Sep 2010 21:52:01 +0100 Subject: RIP Justification In-Reply-To: References: Message-ID: Jesse - just to clarify, are you talking about v1 or v2? There is also a proposal for v3.. In my previous post, I was assuming v2. From egon at egon.cc Wed Sep 29 20:53:40 2010 From: egon at egon.cc (James Downs) Date: Wed, 29 Sep 2010 13:53:40 -0700 Subject: RIP Justification In-Reply-To: References: Message-ID: On Sep 29, 2010, at 1:47 PM, Ricky Beam wrote: > The 1% where it was a necessary evil... dialup networking where the > only routing protocol supported was RIP (v2) [netblazers] -- static > IP clients had to be able to land anywhere -- but RIP only lived on > the local segment, OSPF took over network-wide. (Later MaxTNT's were > setup with OSPF I remember RIP across chassis for the TotalControl bonded dialup stuff, and as you mention, static IPs, but I haven't seen it in serious use for a long time. Cheers, -j From ryguillian at gmail.com Wed Sep 29 21:08:18 2010 From: ryguillian at gmail.com (Ryan Hayes) Date: Wed, 29 Sep 2010 16:08:18 -0500 Subject: What must one do to avoid Gmail's retarded non-spam filtering? In-Reply-To: <22257558.30.1285704909402.JavaMail.root@zimbra.caneris.com> References: <7040875.28.1285704814582.JavaMail.root@zimbra.caneris.com> <22257558.30.1285704909402.JavaMail.root@zimbra.caneris.com> Message-ID: Can you please not use the word "retarded" in a pejorative sense? On Tue, Sep 28, 2010 at 3:15 PM, Erik L wrote: > I realize that this is somewhat OT, but I'm sure that others on the list encounter the same issues and that at least some folks might have useful comments. > > An increasingly large number of our customers are using Gmail or Google Apps and almost all of our OSS/BSS mail is getting spam filtered by Google. Among others, these e-mails include invoices, order confirmations, payment notifications, customer portal logins, and tickets. Almost anything we send to customers on Google ends up in their spam folder. This results in a lot of calls and makes much of our automation pointless, never mind all the lost sales. > > The problem is compounded by those who use mail clients and do not log in to the webmail at all, since they would never see the contents of the Google spam folder. > > We have proper A+PTR records on the edge MTAs, proper SPF records for the originating domain, proper Return-Path and other headers, and so on. There isn't anything that I can think of other than the content itself which would be abnormal, and obviously the content is repetitive and can't be changed much. Is there something obvious which we've missed? > > Aside from the following clearly impractical solutions, what can we do? > 1. Asking everyone (including those we don't even know yet) to whitelist all of our addresses, to check their spam folders, and to click on "this is not spam" > 2. Providing our own free e-mail service to everyone (including those we don't even know yet) and putting up "don't use Google" ads on all of our customer-facing systems > > At least this isn't Hotmail where mail is just silently deleted with no NDR after it's accepted by their MTAs. > > The call volume has been going up instead of down lately and it's gotten to the point where we're sending MTA log extracts to people to prove to them that we really did e-mail them. > > Would greatly appreciate any advice. > > Erik > > From fred at cisco.com Wed Sep 29 21:13:18 2010 From: fred at cisco.com (Fred Baker) Date: Wed, 29 Sep 2010 14:13:18 -0700 Subject: RIP Justification In-Reply-To: References: Message-ID: <54D4E200-0A8A-411F-95A4-D35A73261546@cisco.com> On Sep 29, 2010, at 1:20 PM, Jesse Loggins wrote: > A group of engineers and I were having a design discussion about routing > protocols including RIP and static routing and the justifications of use for > each protocol. One very interesting discussion was surrounding RIP and its > use versus a protocol like OSPF. It seems that many Network Engineers > consider RIP an old antiquated protocol that should be thrown in back of a > closet "never to be seen or heard from again". Some even preferred using a > more complex protocol like OSPF instead of RIP. I am of the opinion that > every protocol has its place, which seems to be contrary to some engineers > way of thinking. This leads to my question. What are your views of when and > where the RIP protocol is useful? Please excuse me if this is the incorrect > forum for such questions. For RIP, the attraction is simplicity, and the down-side is count-to-infinity. If you have a network in which count-to-infinity is a non-issue - often true of residential networks, for example - the simplicity of RIP can be very attractive. If you have anything resembling complexity in your network, protocols like OSPF are far more appropriate. From jlogginsccie at gmail.com Wed Sep 29 21:20:04 2010 From: jlogginsccie at gmail.com (Jesse Loggins) Date: Wed, 29 Sep 2010 14:20:04 -0700 Subject: RIP Justification In-Reply-To: References: Message-ID: I am referring to RIPv2 On Wed, Sep 29, 2010 at 1:52 PM, Heath Jones wrote: > Jesse - just to clarify, are you talking about v1 or v2? There is also > a proposal for v3.. > In my previous post, I was assuming v2. > -- Jesse Loggins CCIE#14661 (R&S, Service Provider) From brandon.kim at brandontek.com Wed Sep 29 21:22:03 2010 From: brandon.kim at brandontek.com (Brandon Kim) Date: Wed, 29 Sep 2010 17:22:03 -0400 Subject: RIP Justification In-Reply-To: References: , , Message-ID: I see nothing wrong with using RIPV2 for small networks as it is more dynamic and faster convergence. As for RIPv1, I think we can all say, RIP!! (no pun intended) Ok yes it was intended.... LOL... I think some engineers get lost in the "whatever is newer is better" and you don't need to use a complicated protocol for small simple networks. Now, you should think ahead if that's possible and if you do know it can get complicated, you can implement the right protocol from the start. I have not heard about RIPv3. I suppose I should start looking into it...... > From: egon at egon.cc > To: nanog at nanog.org > Subject: Re: RIP Justification > Date: Wed, 29 Sep 2010 13:53:40 -0700 > > > On Sep 29, 2010, at 1:47 PM, Ricky Beam wrote: > > > The 1% where it was a necessary evil... dialup networking where the > > only routing protocol supported was RIP (v2) [netblazers] -- static > > IP clients had to be able to land anywhere -- but RIP only lived on > > the local segment, OSPF took over network-wide. (Later MaxTNT's were > > setup with OSPF > > I remember RIP across chassis for the TotalControl bonded dialup > stuff, and as you mention, static IPs, but I haven't seen it in > serious use for a long time. > > Cheers, > -j > From dseagrav at humancapitaldev.com Wed Sep 29 21:31:06 2010 From: dseagrav at humancapitaldev.com (Daniel Seagraves) Date: Wed, 29 Sep 2010 16:31:06 -0500 Subject: What must one do to avoid Gmail's overachieving spam filtering? In-Reply-To: References: <7040875.28.1285704814582.JavaMail.root@zimbra.caneris.com> <22257558.30.1285704909402.JavaMail.root@zimbra.caneris.com> Message-ID: <6364BE95-EBDB-4D4C-A1FC-12886CD04D8D@humancapitaldev.com> On Sep 29, 2010, at 4:08 PM, Ryan Hayes wrote: > Can you please not use the word "retarded" in a pejorative sense? The word "please" is probably not required, since using that word in this manner is prosecutable hate speech in some jurisdictions. From dwcarder at wisc.edu Wed Sep 29 21:36:01 2010 From: dwcarder at wisc.edu (Dale W. Carder) Date: Wed, 29 Sep 2010 16:36:01 -0500 Subject: RIP Justification In-Reply-To: References: Message-ID: <20100929213601.GE11338@ricotta.doit.wisc.edu> Thus spake Jesse Loggins (jlogginsccie at gmail.com) on Wed, Sep 29, 2010 at 01:20:48PM -0700: > This leads to my question. What are your views of when and > where the RIP protocol is useful? I most often see RIPv2 used simply to avoid paying vendor license fees to run more sophisticated things such as OSPF. Dale From m.hallgren at free.fr Wed Sep 29 21:42:33 2010 From: m.hallgren at free.fr (Michael Hallgren) Date: Wed, 29 Sep 2010 23:42:33 +0200 Subject: What must one do to avoid Gmail's overachieving spam filtering? In-Reply-To: <6364BE95-EBDB-4D4C-A1FC-12886CD04D8D@humancapitaldev.com> References: <7040875.28.1285704814582.JavaMail.root@zimbra.caneris.com> <22257558.30.1285704909402.JavaMail.root@zimbra.caneris.com> <6364BE95-EBDB-4D4C-A1FC-12886CD04D8D@humancapitaldev.com> Message-ID: <1285796553.7648.21.camel@home> Le mercredi 29 septembre 2010 ? 16:31 -0500, Daniel Seagraves a ?crit : > On Sep 29, 2010, at 4:08 PM, Ryan Hayes wrote: > > > Can you please not use the word "retarded" in a pejorative sense? > > The word "please" is probably not required, since using that word in this manner is prosecutable hate speech in some jurisdictions. You're serious? :) mh > From bmanning at vacation.karoshi.com Wed Sep 29 21:47:41 2010 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Wed, 29 Sep 2010 21:47:41 +0000 Subject: the lazy mans HW research Message-ID: <20100929214741.GD940@vacation.karoshi.com.> morning gentle people. i find myself in need of a multiport (8-16) 1 Gig ethernet HUB. or a switch smart enough to do transparant port mirroring to at least four ports. some kind soul pointed me here, http://www.dlink.com/products/?pid=337 but its not clear if this will actually perform as desired. suggest to the suggestable listener? --bill From nick at foobar.org Wed Sep 29 21:48:07 2010 From: nick at foobar.org (Nick Hilliard) Date: Wed, 29 Sep 2010 22:48:07 +0100 Subject: RIP Justification In-Reply-To: <20100929213601.GE11338@ricotta.doit.wisc.edu> References: <20100929213601.GE11338@ricotta.doit.wisc.edu> Message-ID: <4CA3B417.7080409@foobar.org> On 29/09/2010 22:36, Dale W. Carder wrote: > I most often see RIPv2 used simply to avoid paying vendor license fees to run > more sophisticated things such as OSPF. The good thing about vendors who charge license fees to run more sophisticated things such as OSPF is that there are always other vendors out there who don't charge license fees for bread and butter protocols - such as OSPF. Nick From Jonathon.Exley at kordia.co.nz Wed Sep 29 21:50:54 2010 From: Jonathon.Exley at kordia.co.nz (Jonathon Exley) Date: Thu, 30 Sep 2010 10:50:54 +1300 Subject: RIP Justification In-Reply-To: References: Message-ID: <035FE016D625174BA7C7A9FA83E6C17987147CE602@winexmp02> RIP is useful as an edge protocol where there is a single access - less system overhead than OSPF. The service provider and the customer can redistribute the routes into whatever routing protocol they use in their own networks. Jonathon -----Original Message----- From: Jesse Loggins [mailto:jlogginsccie at gmail.com] Sent: Thursday, 30 September 2010 9:21 a.m. To: nanog at nanog.org Subject: RIP Justification A group of engineers and I were having a design discussion about routing protocols including RIP and static routing and the justifications of use for each protocol. One very interesting discussion was surrounding RIP and its use versus a protocol like OSPF. It seems that many Network Engineers consider RIP an old antiquated protocol that should be thrown in back of a closet "never to be seen or heard from again". Some even preferred using a more complex protocol like OSPF instead of RIP. I am of the opinion that every protocol has its place, which seems to be contrary to some engineers way of thinking. This leads to my question. What are your views of when and where the RIP protocol is useful? Please excuse me if this is the incorrect forum for such questions. -- Jesse Loggins CCIE#14661 (R&S, Service Provider) This email and attachments: are confidential; may be protected by privilege and copyright; if received in error may not be used,copied, or kept; are not guaranteed to be virus-free; may not express the views of Kordia(R); do not designate an information system; and do not give rise to any liability for Kordia(R). From cra at WPI.EDU Wed Sep 29 21:54:33 2010 From: cra at WPI.EDU (Chuck Anderson) Date: Wed, 29 Sep 2010 17:54:33 -0400 Subject: the lazy mans HW research In-Reply-To: <20100929214741.GD940@vacation.karoshi.com.> References: <20100929214741.GD940@vacation.karoshi.com.> Message-ID: <20100929215433.GF23425@angus.ind.WPI.EDU> On Wed, Sep 29, 2010 at 09:47:41PM +0000, bmanning at vacation.karoshi.com wrote: > i find myself in need of a multiport (8-16) 1 Gig ethernet HUB. > > or a switch smart enough to do transparant port mirroring to at least > four ports. > > some kind soul pointed me here, http://www.dlink.com/products/?pid=337 > but its not clear if this will actually perform as desired. I was recently pointed at this: http://www.dual-comm.com/gigabit_port-mirroring-LAN_switch.htm Haven't ordered one to try yet, but it looks very useful for troubleshooting GigE and PoE links, alas only 5 ports a 1 mirror. From bill at herrin.us Wed Sep 29 21:57:11 2010 From: bill at herrin.us (William Herrin) Date: Wed, 29 Sep 2010 17:57:11 -0400 Subject: the lazy mans HW research In-Reply-To: <20100929214741.GD940@vacation.karoshi.com.> References: <20100929214741.GD940@vacation.karoshi.com.> Message-ID: On Wed, Sep 29, 2010 at 5:47 PM, wrote: > ? ? ? ?i find myself in need of a multiport (8-16) 1 Gig ethernet HUB. > ? ? ? ?or a switch smart enough to do transparant port mirroring to at least > ? ? ? ?four ports. Bill, Out of curiousity, why? Would a set of gig-e taps do what you need? Something like: http://www.netoptics.com/products/product_family_details.asp?cid=1&pid=54&Section=products&menuitem=1 Regards, Bill -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From egon at egon.cc Wed Sep 29 22:06:00 2010 From: egon at egon.cc (James Downs) Date: Wed, 29 Sep 2010 15:06:00 -0700 Subject: What must one do to avoid Gmail's overachieving spam filtering? In-Reply-To: <6364BE95-EBDB-4D4C-A1FC-12886CD04D8D@humancapitaldev.com> References: <7040875.28.1285704814582.JavaMail.root@zimbra.caneris.com> <22257558.30.1285704909402.JavaMail.root@zimbra.caneris.com> <6364BE95-EBDB-4D4C-A1FC-12886CD04D8D@humancapitaldev.com> Message-ID: <80C2C927-70C0-4459-B6F9-1A85C6908136@egon.cc> On Sep 29, 2010, at 2:31 PM, Daniel Seagraves wrote: > On Sep 29, 2010, at 4:08 PM, Ryan Hayes wrote: > >> Can you please not use the word "retarded" in a pejorative sense? > > The word "please" is probably not required, since using that word in > this manner is prosecutable hate speech in some jurisdictions. Really? Where? Seems to me equating "retarded" used as an adjective to say, speech of the KKK seems... lame. Also, "retarded" was applied to software, which to date, has not been entered as a protected group. -j From bonomi at mail.r-bonomi.com Wed Sep 29 22:04:44 2010 From: bonomi at mail.r-bonomi.com (Robert Bonomi) Date: Wed, 29 Sep 2010 17:04:44 -0500 (CDT) Subject: AS11296 -- Hijacked? Message-ID: <201009292204.o8TM4iZu004335@mail.r-bonomi.com> > From nanog-bounces+bonomi=mail.r-bonomi.com at nanog.org Wed Sep 29 13:59:15 2010 > From: Justin Horstman > To: "'George Bonser'" , Heath Jones , > "Ronald F. Guilmette" > Date: Wed, 29 Sep 2010 11:53:27 -0700 > Subject: RE: AS11296 -- Hijacked? > Cc: "nanog at nanog.org" > > > -----Original Message----- > > From: George Bonser [mailto:gbonser at seven.com] > > Sent: Wednesday, September 29, 2010 10:44 AM > > To: Heath Jones; Ronald F. Guilmette > > Cc: nanog at nanog.org > > Subject: RE: AS11296 -- Hijacked? > Is the person reporting this > > a > > known network operator that people trust or is it some Joe Blow out of > > nowhere that nobody has heard of before? That would make a huge > > difference. =20 > > > Going to his website....looks like Joe Blow...Googling his name/email/domai= > n, still nothing that would lead me to believe he is network Savvy. So comi= > ng from Joe Blow network Dude....he too is just Joe Blow. Just a little per= > spective for you from the bottom of the pile. > At least some of us -- who have been on the net for multiple decades -- know who the OP is. He's kept a low profile for a number of years, but he was very active in the early days of the anti-spam wars. Anyone actively involved in anti-spam activities in the days when promiscuous mail relays were common, (and Sun was still shipping 'sendmail 8.6.4') will likely recogize the name. They may have to think for a while, due to the time involved, but he was very well known in those days. 'Notorious' would be considered by some to be an accurate description. Absolutely top-notch technical skills, but a bit of a loose cannon in implementing things _he_ decided were 'for the good of the community'. 'Active' techniques, not just passive ones. *IF* he was accurate in his assessment, and it is my personal opinioin that it is *highly*likely* that there _was_ some sort of 'funny business' involved, whether or not his idenfitication was 100% accurate (and, based on personal experience again, I regard it a probable that he was =entirely= correct in his assessment), *THEN* the odds are quite good that one or more of the parties ivolved is a subscriber to this list. Considered in _that_ light, it would be simply 'stupid' -- which Ron is _not_ -- to tip them off as to where they screwed up, and what gave them away. From erik_list at caneris.com Wed Sep 29 22:12:24 2010 From: erik_list at caneris.com (Erik L) Date: Wed, 29 Sep 2010 18:12:24 -0400 (EDT) Subject: Google blocks ISP arbitrarily contrary to their "don't be evil", ignorant fools debate merits of political correctness on NANOG In-Reply-To: <22973825.282.1285797525550.JavaMail.root@zimbra.caneris.com> Message-ID: <28722387.284.1285798344717.JavaMail.root@zimbra.caneris.com> After you're done adding hate speech and spamming to my list of alleged criminal offences, can you and others please not post or e-mail me off-list if you have nothing new to contribute to the resolution of the problem? ----- Original Message ----- From: "Ryan Hayes" To: "Erik L" , nanog at nanog.org Sent: Wednesday, September 29, 2010 5:08:18 PM Subject: Re: What must one do to avoid Gmail's retarded non-spam filtering? Can you please not use the word "retarded" in a pejorative sense? On Tue, Sep 28, 2010 at 3:15 PM, Erik L wrote: > I realize that this is somewhat OT, but I'm sure that others on the > list encounter the same issues and that at least some folks might have > useful comments. > > An increasingly large number of our customers are using Gmail or > Google Apps and almost all of our OSS/BSS mail is getting spam > filtered by Google. Among others, these e-mails include invoices, > order confirmations, payment notifications, customer portal logins, > and tickets. Almost anything we send to customers on Google ends up in > their spam folder. This results in a lot of calls and makes much of > our automation pointless, never mind all the lost sales. > > The problem is compounded by those who use mail clients and do not log > in to the webmail at all, since they would never see the contents of > the Google spam folder. > > We have proper A+PTR records on the edge MTAs, proper SPF records for > the originating domain, proper Return-Path and other headers, and so > on. There isn't anything that I can think of other than the content > itself which would be abnormal, and obviously the content is > repetitive and can't be changed much. Is there something obvious which > we've missed? > > Aside from the following clearly impractical solutions, what can we > do? 1. Asking everyone (including those we don't even know yet) to > whitelist all of our addresses, to check their spam folders, and to > click on "this is not spam" > 2. Providing our own free e-mail service to everyone (including those > we don't even know yet) and putting up "don't use Google" ads on all > of our customer-facing systems > > At least this isn't Hotmail where mail is just silently deleted with > no NDR after it's accepted by their MTAs. > > The call volume has been going up instead of down lately and it's > gotten to the point where we're sending MTA log extracts to people to > prove to them that we really did e-mail them. > > Would greatly appreciate any advice. > > Erik > > From bonomi at mail.r-bonomi.com Wed Sep 29 22:37:23 2010 From: bonomi at mail.r-bonomi.com (Robert Bonomi) Date: Wed, 29 Sep 2010 17:37:23 -0500 (CDT) Subject: AS11296 -- Hijacked? Message-ID: <201009292237.o8TMbNFY004539@mail.r-bonomi.com> > Date: Wed, 29 Sep 2010 13:06:31 -0700 > Subject: Re: AS11296 -- Hijacked? > From: Scott Howard > > On Wed, Sep 29, 2010 at 9:26 AM, N. Yaakov Ziskind wrote: > > > Recommendations such as that are only as credible as the source they are > coming from, and knowing that the person making the request also believes > that blocking all mail from gmail.com is a valid anti-spam technique > probably results in a "different" credibility level than one might otherwise > have. I have to ask one question -- who are _you_ to judge what is 'valid' for *HIS* situation? He's not running a 'provider' network, with any responsibility to others, it's his personal environment. On _my_ personal servers, I block *LARGE* swaths of the world -- because I _do_ get significant amounts of spam from those locales, and have *zero* expectation of any 'legitimate' mail therefrom. The service denial messages _do_ provide info on how to get past the blocks. I can state with authority that in close to a million messages so rejected, -not-a-single-one- has been from someone with a serious interest in communicationg with me. The web-page with the explanatory data has not had so much as a single hit in over 8 years. Now, on systems I manage for others, I do things very differently, according to -their- needs. The rationale for such decisions is straightforward, and easy to understand. It's called the 'cost-benefit' ratio. _How_much_ work does it take to let that 'rare' piece of 'useful' mail through from a source that generates almost exclusively spam, and _is_ getting that occasional piece of mail 'worth the effort'. Ron has decided 'not', with regard to gmail. To argue that decision, _you_ would have to know how much 'valid' traffic he can reasonably expect to get from gmail, and the amount of effort it would take in his existing environment to accomplish that end. From cvuljanic at gmail.com Wed Sep 29 21:26:17 2010 From: cvuljanic at gmail.com (Craig) Date: Wed, 29 Sep 2010 17:26:17 -0400 Subject: RIP Justification In-Reply-To: References: Message-ID: <7D228D09-4C49-4A45-A985-F7305AED9A62@gmail.com> We have a design for our wan where we use rip v2 and it works very well, we were using ospf but it was additional config, so in our case simple was better, and it works well.. I could discuss it more with you off-line if you like. On Sep 29, 2010, at 4:20 PM, Jesse Loggins wrote: > A group of engineers and I were having a design discussion about routing > protocols including RIP and static routing and the justifications of use for > each protocol. One very interesting discussion was surrounding RIP and its > use versus a protocol like OSPF. It seems that many Network Engineers > consider RIP an old antiquated protocol that should be thrown in back of a > closet "never to be seen or heard from again". Some even preferred using a > more complex protocol like OSPF instead of RIP. I am of the opinion that > every protocol has its place, which seems to be contrary to some engineers > way of thinking. This leads to my question. What are your views of when and > where the RIP protocol is useful? Please excuse me if this is the incorrect > forum for such questions. > > -- > Jesse Loggins > CCIE#14661 (R&S, Service Provider) From jgreco at ns.sol.net Wed Sep 29 23:24:59 2010 From: jgreco at ns.sol.net (Joe Greco) Date: Wed, 29 Sep 2010 18:24:59 -0500 (CDT) Subject: RIP Justification In-Reply-To: <5F3648B7-3B61-4E8C-8B64-03740830F5AE@ianai.net> Message-ID: <201009292324.o8TNOxaP093631@aurora.sol.net> > > where the RIP protocol is useful? Please excuse me if this is the = > incorrect > > forum for such questions. > > RIP has one property no "modern" protocol has. It works on simplex = > links (e.g. high-speed satellite downlink with low-speed terrestrial = > uplink). > > Is that useful? I don't know, but it is still a fact. I once had cause to write a RIP broadcast daemon while on-site with a client; they had some specific brokenness with a Novell server and some other gear that was "fixed" by a UNIX box, a C compiler, and maybe 20 or 30 minutes of programming (mostly to remember the grimy specifics of UDP broadcast programming). I do not recall the specific routing issue, but being able to just inject a periodic "spoofed" packet was sufficient to repair them. While not the correct way to engineer a network, sometimes being able to bring a client's network back on-line in a crisis is more important than technical correctness. I feel reasonably certain that I would not have been able to cobble together a quick solution if they had been relying on OSPF, etc. A simple protocol can be a blessing. I concede it is more often a curse. ... 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 hj1980 at gmail.com Wed Sep 29 23:38:12 2010 From: hj1980 at gmail.com (Heath Jones) Date: Thu, 30 Sep 2010 00:38:12 +0100 Subject: AS11296 -- Hijacked? In-Reply-To: <201009292237.o8TMbNFY004539@mail.r-bonomi.com> References: <201009292237.o8TMbNFY004539@mail.r-bonomi.com> Message-ID: Robert, I dont think you quite get it. Don't worry, you don't seem to be alone. The point here is simple. If someone posts making a recommendation for every AS to filter some prefixes, not provide any references by default, its not helpful. When questioned about the rationale, if said person then declines to provide evidence, the picture starts to form. It is relatively easy to detect spam, it is easy to have enough honeypots & filters matching corresponding bgp lookups to find out path information. Immediately you have a technique which - regardless of the lists a spammer reads - will catch spammer. By working as a community, the accuracy and speed of detection increases. By sharing information, things improve. The problem is certainly not detection!! (in contrast to the clamed need to hide detection methods) Posting to a list like this telling everyone to block traffic might be in some people's eyes as ok, but there are a few problems: 1) No peer review. The data has not been checked, the prefixes might be incorrect. The methods might be completely wrong - who knows! This is certainly the #1 issue. 2) Length of time to implement. Most serious ASs would do sanity checking and even possibly a change window or atleast a signoff. 2) Post advertisment removal. What process to ASs have in place to check and remove these rules? More sanity checking and another change. 3) The comment about ARIN, as if to imply that they are supposed to somehow 'police' the internet. This shows a complete lack of understanding of the architecture of the internet. 4) A person who blocks gmail for their own - non customer affecting - mail server cannot be in a position to advise of real - customer affecting - changes, and shows a recklessness towards adhoc blocking of anything. As a hypothetical situation, say a new customer pops up on a network with a prefix and origin that haven't been seen before. This customer badly configured their mail server, its an open relay. Spammers being smart, watch new BGP advertisments knowing that this might be the case. Some kind sir sees the spam coming from the open relay and posts on here, telling everyone to block it, thus completely killling the new customer network before its even got off the ground properly. By the time it has come around, half the ISPs are blocking it and they are completely screwed all because of 1 mistake and someone not having their information peer reviewed and no action to notify or help out the isp. Posting ASs & prefixes for people to block without any questioning is just plain stupid and not the way to handle it. If the goal is to get rid of spam, then why not put brains together and come up with a much better system. IETF? Independant working group? I can think of a number of ideas as I am typing this that could be beneficial. I am happy of course to share with anyone interested. Sure, people can post pretty much what they want and people can choose to use or ignore, but we are a bit past that argument now. There has been (to use your method) *zero* technical reasons supporting the argument of blocking these prefixes. If you know of one, please voice it. ps. I have also received posts offline about the support for blocking gmail / hotmail / whatever. I can appreciate that it is your own personal infrastructure, you have your reasons, and if it works for you then good. I certainly wouldn't do it for my customers, otherwise they would constantly call. Phone spam :) From brandon.kim at brandontek.com Wed Sep 29 23:42:09 2010 From: brandon.kim at brandontek.com (Brandon Kim) Date: Wed, 29 Sep 2010 19:42:09 -0400 Subject: RIP Justification In-Reply-To: <201009292324.o8TNOxaP093631@aurora.sol.net> References: <5F3648B7-3B61-4E8C-8B64-03740830F5AE@ianai.net>, <201009292324.o8TNOxaP093631@aurora.sol.net> Message-ID: Thanks Joe! You just added a new term to my vocabulary! "Technical Correctness" I think I'm going to go out of my way now to use this in the office... =) > From: jgreco at ns.sol.net > Subject: Re: RIP Justification > To: patrick at ianai.net > Date: Wed, 29 Sep 2010 18:24:59 -0500 > CC: nanog at nanog.org > > > > where the RIP protocol is useful? Please excuse me if this is the = > > incorrect > > > forum for such questions. > > > > RIP has one property no "modern" protocol has. It works on simplex = > > links (e.g. high-speed satellite downlink with low-speed terrestrial = > > uplink). > > > > Is that useful? I don't know, but it is still a fact. > > I once had cause to write a RIP broadcast daemon while on-site with a > client; they had some specific brokenness with a Novell server and some > other gear that was "fixed" by a UNIX box, a C compiler, and maybe 20 > or 30 minutes of programming (mostly to remember the grimy specifics of > UDP broadcast programming). I do not recall the specific routing issue, > but being able to just inject a periodic "spoofed" packet was sufficient > to repair them. > > While not the correct way to engineer a network, sometimes being able to > bring a client's network back on-line in a crisis is more important than > technical correctness. I feel reasonably certain that I would not have > been able to cobble together a quick solution if they had been relying > on OSPF, etc. A simple protocol can be a blessing. I concede it is more > often a curse. > > .... 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 hj1980 at gmail.com Wed Sep 29 23:54:43 2010 From: hj1980 at gmail.com (Heath Jones) Date: Thu, 30 Sep 2010 00:54:43 +0100 Subject: RIP Justification In-Reply-To: <201009292324.o8TNOxaP093631@aurora.sol.net> References: <5F3648B7-3B61-4E8C-8B64-03740830F5AE@ianai.net> <201009292324.o8TNOxaP093631@aurora.sol.net> Message-ID: This is why they need a 'like' button on nanog!! :) > I once had cause to write a RIP broadcast daemon while on-site with a > client; they had some specific brokenness with a Novell server and some > other gear that was "fixed" by a UNIX box, a C compiler, and maybe 20 > or 30 minutes of programming (mostly to remember the grimy specifics of > UDP broadcast programming). ?I do not recall the specific routing issue, > but being able to just inject a periodic "spoofed" packet was sufficient > to repair them. From nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org Wed Sep 29 23:57:05 2010 From: nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org (Mark Smith) Date: Thu, 30 Sep 2010 09:27:05 +0930 Subject: RIP Justification In-Reply-To: References: <003801cb6014$fd2f0280$f78d0780$@edu> Message-ID: <20100930092705.3a05d811@opy.nosense.org> On Wed, 29 Sep 2010 15:35:06 -0500 Christopher Gatlin wrote: > RIPv2 is a great dynamic routing protocol for exchanging routes with > untrusted networks. RIPv2 has adjustable timers, filters, supports VLSM and > MD5 authentication. Since it's distance vector it's much easier to filter > than a protocol that uses a link state database that must be the same across > an entire area. > I think BGP is better for that job, ultimately because it was specifically designed for that job, but also because it's now available in commodity routers for commodity prices e.g. Cisco 800 series. > > Chris > > > On Wed, Sep 29, 2010 at 3:29 PM, Gary Gladney wrote: > > > I would think it would depend on the complexity of the network and how the > > network advertises routes to peer networks. I'm always in favor the > > simpler > > the better but with RIP you do lose the ability to use variable bit masks > > (CIDR) and faster routing algorithms like DUAL used in Cisco routers and > > I'm > > not a big fan of OSPF. > > > > Gary > > > > -----Original Message----- > > From: Jesse Loggins [mailto:jlogginsccie at gmail.com] > > Sent: Wednesday, September 29, 2010 4:21 PM > > To: nanog at nanog.org > > Subject: RIP Justification > > > > A group of engineers and I were having a design discussion about routing > > protocols including RIP and static routing and the justifications of use > > for > > each protocol. One very interesting discussion was surrounding RIP and its > > use versus a protocol like OSPF. It seems that many Network Engineers > > consider RIP an old antiquated protocol that should be thrown in back of a > > closet "never to be seen or heard from again". Some even preferred using a > > more complex protocol like OSPF instead of RIP. I am of the opinion that > > every protocol has its place, which seems to be contrary to some engineers > > way of thinking. This leads to my question. What are your views of when and > > where the RIP protocol is useful? Please excuse me if this is the incorrect > > forum for such questions. > > > > -- > > Jesse Loggins > > CCIE#14661 (R&S, Service Provider) > > > > > > From franck at genius.com Thu Sep 30 00:04:16 2010 From: franck at genius.com (Franck Martin) Date: Wed, 29 Sep 2010 17:04:16 -0700 (PDT) Subject: AS11296 -- Hijacked? In-Reply-To: Message-ID: <1747956.223.1285805055702.JavaMail.franck@linko-biatch-6.genius.local> This is not what the Team Cymru Bogons list for? http://www.team-cymru.org/Services/Bogons/ List bad ASNs after proper investigation? It then depends if you trust Team Cymru or not, like you would trust or not Spamhaus... ----- Original Message ----- From: "Heath Jones" To: "Robert Bonomi" Cc: nanog at nanog.org Sent: Wednesday, 29 September, 2010 4:38:12 PM Subject: Re: AS11296 -- Hijacked? Robert, I dont think you quite get it. Don't worry, you don't seem to be alone. The point here is simple. If someone posts making a recommendation for every AS to filter some prefixes, not provide any references by default, its not helpful. When questioned about the rationale, if said person then declines to provide evidence, the picture starts to form. It is relatively easy to detect spam, it is easy to have enough honeypots & filters matching corresponding bgp lookups to find out path information. Immediately you have a technique which - regardless of the lists a spammer reads - will catch spammer. By working as a community, the accuracy and speed of detection increases. By sharing information, things improve. The problem is certainly not detection!! (in contrast to the clamed need to hide detection methods) Posting to a list like this telling everyone to block traffic might be in some people's eyes as ok, but there are a few problems: 1) No peer review. The data has not been checked, the prefixes might be incorrect. The methods might be completely wrong - who knows! This is certainly the #1 issue. 2) Length of time to implement. Most serious ASs would do sanity checking and even possibly a change window or atleast a signoff. 2) Post advertisment removal. What process to ASs have in place to check and remove these rules? More sanity checking and another change. 3) The comment about ARIN, as if to imply that they are supposed to somehow 'police' the internet. This shows a complete lack of understanding of the architecture of the internet. 4) A person who blocks gmail for their own - non customer affecting - mail server cannot be in a position to advise of real - customer affecting - changes, and shows a recklessness towards adhoc blocking of anything. As a hypothetical situation, say a new customer pops up on a network with a prefix and origin that haven't been seen before. This customer badly configured their mail server, its an open relay. Spammers being smart, watch new BGP advertisments knowing that this might be the case. Some kind sir sees the spam coming from the open relay and posts on here, telling everyone to block it, thus completely killling the new customer network before its even got off the ground properly. By the time it has come around, half the ISPs are blocking it and they are completely screwed all because of 1 mistake and someone not having their information peer reviewed and no action to notify or help out the isp. Posting ASs & prefixes for people to block without any questioning is just plain stupid and not the way to handle it. If the goal is to get rid of spam, then why not put brains together and come up with a much better system. IETF? Independant working group? I can think of a number of ideas as I am typing this that could be beneficial. I am happy of course to share with anyone interested. Sure, people can post pretty much what they want and people can choose to use or ignore, but we are a bit past that argument now. There has been (to use your method) *zero* technical reasons supporting the argument of blocking these prefixes. If you know of one, please voice it. ps. I have also received posts offline about the support for blocking gmail / hotmail / whatever. I can appreciate that it is your own personal infrastructure, you have your reasons, and if it works for you then good. I certainly wouldn't do it for my customers, otherwise they would constantly call. Phone spam :) From fergdawgster at gmail.com Thu Sep 30 00:10:57 2010 From: fergdawgster at gmail.com (Paul Ferguson) Date: Wed, 29 Sep 2010 17:10:57 -0700 Subject: Reputation Services [WAS: Re: AS11296 -- Hijacked?] Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wed, Sep 29, 2010 at 5:04 PM, Franck Martin wrote: > This is not what the Team Cymru Bogons list for? > http://www.team-cymru.org/Services/Bogons/ > > List bad ASNs after proper investigation? > > It then depends if you trust Team Cymru or not, like you would trust or > not Spamhaus... > Of course all policy should be local -- each organization can make their own determination whose DNSBL, reputation service, or filter list to employ. $.02, - - ferg -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.5.3 (Build 5003) wj8DBQFMo9WDq1pz9mNUZTMRAjUQAKCJc/hHDTUX9L3WHq+QaIDLpru8YgCg7O3h DTLrkDZZV4+obb97YODC57A= =kW01 -----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 Crist.Clark at globalstar.com Thu Sep 30 00:11:55 2010 From: Crist.Clark at globalstar.com (Crist Clark) Date: Wed, 29 Sep 2010 17:11:55 -0700 Subject: RIP Justification In-Reply-To: <201009292324.o8TNOxaP093631@aurora.sol.net> References: <5F3648B7-3B61-4E8C-8B64-03740830F5AE@ianai.net> <201009292324.o8TNOxaP093631@aurora.sol.net> Message-ID: <4CA3735B.33E4.0097.1@globalstar.com> >>> On 9/29/2010 at 4:24 PM, Joe Greco wrote: >> > where the RIP protocol is useful? Please excuse me if this is the = >> incorrect >> > forum for such questions. >> >> RIP has one property no "modern" protocol has. It works on simplex = >> links (e.g. high-speed satellite downlink with low-speed terrestrial = >> uplink). >> >> Is that useful? I don't know, but it is still a fact. > > I once had cause to write a RIP broadcast daemon while on-site with a > client; they had some specific brokenness with a Novell server and some > other gear that was "fixed" by a UNIX box, a C compiler, and maybe 20 > or 30 minutes of programming (mostly to remember the grimy specifics of > UDP broadcast programming). I do not recall the specific routing issue, > but being able to just inject a periodic "spoofed" packet was sufficient > to repair them. I've got a RIPv2 daemon written in a few dozen lines of Perl to do something very similar. In other situations, RIPv2 has strong KISS appeal. From hj1980 at gmail.com Thu Sep 30 00:22:02 2010 From: hj1980 at gmail.com (Heath Jones) Date: Thu, 30 Sep 2010 01:22:02 +0100 Subject: AS11296 -- Hijacked? In-Reply-To: <1747956.223.1285805055702.JavaMail.franck@linko-biatch-6.genius.local> References: <1747956.223.1285805055702.JavaMail.franck@linko-biatch-6.genius.local> Message-ID: > This is not what the Team Cymru Bogons list for? http://www.team-cymru.org/Services/Bogons/ I just had a very quick look at that site and it seems at first glance to just be providing information on unallocated prefixes/ASs.. They are prefixes/ASs that spammers can and do use, but if you have a look at cidr report or potaroo then you will see that an ISP who filters based on that will cause some issues (allocation records are not always up to date). > List bad ASNs after proper investigation? Not really, just based on registry information as far as I can see. For instance, if a known and stable AS suddenly started originating spam, it doesnt look like that would appear on the site. > It then depends if you trust Team Cymru or not, like you would trust or not Spamhaus... Trust will always be the issue. Peer review and communication is one way of building trust. From chris at travelingtech.net Thu Sep 30 00:31:26 2010 From: chris at travelingtech.net (Christopher Gatlin) Date: Wed, 29 Sep 2010 19:31:26 -0500 Subject: RIP Justification In-Reply-To: <20100930092705.3a05d811@opy.nosense.org> References: <003801cb6014$fd2f0280$f78d0780$@edu> <20100930092705.3a05d811@opy.nosense.org> Message-ID: My point here is untrusted networks, such as business partners exchanging routes with each other. Not many hops and less than a 100 prefixes. Using BGP to exchange routes between these types of untrusted networks is like using a sledgehammer to crack a nut. BGP was designed for unique AS's to peer in large scale networks such as the internet. A far cry from business partners exchanging dynamic routes for fault tolerance. I've seen RIPv2 very successfully deployed in modern networks in this fashion. I advocate using an appropriate tool for the job. Christopher Gatlin CCIE #15245 (R&S/Security) On Wed, Sep 29, 2010 at 6:57 PM, Mark Smith < nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org> wrote: > On Wed, 29 Sep 2010 15:35:06 -0500 > Christopher Gatlin wrote: > > > RIPv2 is a great dynamic routing protocol for exchanging routes with > > untrusted networks. RIPv2 has adjustable timers, filters, supports VLSM > and > > MD5 authentication. Since it's distance vector it's much easier to > filter > > than a protocol that uses a link state database that must be the same > across > > an entire area. > > > > I think BGP is better for that job, ultimately because it was > specifically designed for that job, but also because it's now available > in commodity routers for commodity prices e.g. Cisco 800 series. > > > From franck at genius.com Thu Sep 30 00:47:16 2010 From: franck at genius.com (Franck Martin) Date: Wed, 29 Sep 2010 17:47:16 -0700 (PDT) Subject: AS11296 -- Hijacked? In-Reply-To: Message-ID: <17409710.363.1285807632584.JavaMail.franck@linko-biatch-6.genius.local> Then you have: http://www.uceprotect.net/en/rblcheck.php Which has a level to identify IPs belonging to an ASN which has been reported as spewing spam... The only issue here, is that this site has listed whole countries... Yes, some countries are behind one ASN only... ----- Original Message ----- From: "Heath Jones" To: "Franck Martin" Cc: nanog at nanog.org Sent: Wednesday, 29 September, 2010 5:22:02 PM Subject: Re: AS11296 -- Hijacked? > This is not what the Team Cymru Bogons list for? http://www.team-cymru.org/Services/Bogons/ I just had a very quick look at that site and it seems at first glance to just be providing information on unallocated prefixes/ASs.. They are prefixes/ASs that spammers can and do use, but if you have a look at cidr report or potaroo then you will see that an ISP who filters based on that will cause some issues (allocation records are not always up to date). > List bad ASNs after proper investigation? Not really, just based on registry information as far as I can see. For instance, if a known and stable AS suddenly started originating spam, it doesnt look like that would appear on the site. > It then depends if you trust Team Cymru or not, like you would trust or not Spamhaus... Trust will always be the issue. Peer review and communication is one way of building trust. From leo.woltz at gmail.com Thu Sep 30 00:50:17 2010 From: leo.woltz at gmail.com (Leo Woltz) Date: Wed, 29 Sep 2010 20:50:17 -0400 Subject: First Data Corporation? Message-ID: Anyone on the list from First Data Corporation or familar with there network? From swm at emanon.com Thu Sep 30 01:14:05 2010 From: swm at emanon.com (Scott Morris) Date: Wed, 29 Sep 2010 21:14:05 -0400 Subject: RIP Justification In-Reply-To: References: Message-ID: <4CA3E45D.5070900@emanon.com> I think you're right that everything has its' place. But you gotta know where that is and why you choose it! RIP(v2) is great in that there aren't neighbor relationships, so you can shoot routes around in a semi-sane-haphazard fashion if need be. Whatever your reality you exist in like satellite (or other one-way links from the hinterlands). But anything, ask why you are using it. To exchange routes, yes... but how many. Is sending those every 30 seconds good? Sure, tweak it. But are you gaining anything over static routes? Perhaps you are, and if so, it's a great choice in that situation. But I'd certainly think it would be considered to be the "edge" variety of your network and hopefully not planning to use it through your entire network! :) But yeah, I'd agree with the "time and place" argument for it. If you have a Cisco-only shop, ODR can be kinda cool in situations like that as well. Something to think about! My two cents. Scott On 9/29/10 4:20 PM, Jesse Loggins wrote: > A group of engineers and I were having a design discussion about routing > protocols including RIP and static routing and the justifications of use for > each protocol. One very interesting discussion was surrounding RIP and its > use versus a protocol like OSPF. It seems that many Network Engineers > consider RIP an old antiquated protocol that should be thrown in back of a > closet "never to be seen or heard from again". Some even preferred using a > more complex protocol like OSPF instead of RIP. I am of the opinion that > every protocol has its place, which seems to be contrary to some engineers > way of thinking. This leads to my question. What are your views of when and > where the RIP protocol is useful? Please excuse me if this is the incorrect > forum for such questions. > From owen at delong.com Thu Sep 30 02:49:48 2010 From: owen at delong.com (Owen DeLong) Date: Wed, 29 Sep 2010 19:49:48 -0700 Subject: RIP Justification In-Reply-To: References: Message-ID: <5ACF48CB-9683-42A9-BA9B-870A99FA5AF5@delong.com> On Sep 29, 2010, at 1:20 PM, Jesse Loggins wrote: > A group of engineers and I were having a design discussion about routing > protocols including RIP and static routing and the justifications of use for > each protocol. One very interesting discussion was surrounding RIP and its > use versus a protocol like OSPF. It seems that many Network Engineers > consider RIP an old antiquated protocol that should be thrown in back of a > closet "never to be seen or heard from again". Some even preferred using a I would rather say it should be thrown under a bus, squashed, then left on a set of very active railway tracks to be thoroughly mutilated, then discarded never to be seen again. > more complex protocol like OSPF instead of RIP. I am of the opinion that > every protocol has its place, which seems to be contrary to some engineers > way of thinking. This leads to my question. What are your views of when and Here's my thinking... If your network is not complex enough to require a dynamic routing protocol, then, you don't need RIP. If it is, then, you have scaled beyond the point where RIP is more useful than harmful. Yes, OSPF is a more complex protocol. It is also quite a bit more robust and far less susceptible to bizarre looping behaviors when it misbehaves or encounters lost state packets. It has a much shorter fall-over time for dead links and provides a much more accurate and up to date picture of the state of the network. It's a more complex world now than when RIP was developed. Owen From rekoil at semihuman.com Thu Sep 30 03:19:41 2010 From: rekoil at semihuman.com (Chris Woodfield) Date: Wed, 29 Sep 2010 20:19:41 -0700 Subject: RIP Justification In-Reply-To: <035FE016D625174BA7C7A9FA83E6C17987147CE602@winexmp02> References: <035FE016D625174BA7C7A9FA83E6C17987147CE602@winexmp02> Message-ID: I know of one large-ish provider that does it exactly like that - RIPv2 between POP edge routers and provider-managed CPE. In addition to the simplicity, it lets them filter routes at redistribution without having to fiddle with inter-area OSPF (or, ghod forbid, multiple OSPF processes redistributing between each other...) Where folks run into trouble is vendors that decide that RIP is so under-utilized they don't need to fully support or QA it anymore. Implementations tend to be a bit more..."quirky" than OSPF or BGP running on the same box. And occasionally you run into the odd vendor that doesn't care about things like being able to adjust hello/dead intervals... -C On Sep 29, 2010, at 2:50 PM, Jonathon Exley wrote: > RIP is useful as an edge protocol where there is a single access - less system overhead than OSPF. > The service provider and the customer can redistribute the routes into whatever routing protocol they use in their own networks. > > Jonathon > > -----Original Message----- > From: Jesse Loggins [mailto:jlogginsccie at gmail.com] > Sent: Thursday, 30 September 2010 9:21 a.m. > To: nanog at nanog.org > Subject: RIP Justification > > A group of engineers and I were having a design discussion about routing protocols including RIP and static routing and the justifications of use for each protocol. One very interesting discussion was surrounding RIP and its use versus a protocol like OSPF. It seems that many Network Engineers consider RIP an old antiquated protocol that should be thrown in back of a closet "never to be seen or heard from again". Some even preferred using a more complex protocol like OSPF instead of RIP. I am of the opinion that every protocol has its place, which seems to be contrary to some engineers way of thinking. This leads to my question. What are your views of when and where the RIP protocol is useful? Please excuse me if this is the incorrect forum for such questions. > > -- > Jesse Loggins > CCIE#14661 (R&S, Service Provider) > This email and attachments: are confidential; may be protected by > privilege and copyright; if received in error may not be used,copied, > or kept; are not guaranteed to be virus-free; may not express the > views of Kordia(R); do not designate an information system; and do not > give rise to any liability for Kordia(R). > > From rekoil at semihuman.com Thu Sep 30 03:32:37 2010 From: rekoil at semihuman.com (Chris Woodfield) Date: Wed, 29 Sep 2010 20:32:37 -0700 Subject: RIP Justification In-Reply-To: <4CA3E45D.5070900@emanon.com> References: <4CA3E45D.5070900@emanon.com> Message-ID: <0A131ECD-D7F3-408F-8D9B-B71DD69B4C76@semihuman.com> On Sep 29, 2010, at 6:14 PM, Scott Morris wrote: > But anything, ask why you are using it. To exchange routes, yes... but > how many. Is sending those every 30 seconds good? Sure, tweak it. But > are you gaining anything over static routes? For simple networks, RIP(v2, mind you) works fine. You're correct that the number of advertisements sent over the wire every 30 seconds won't scale, but with today's routers and bandwidths it takes quite a lot to start to cause issues. The real nail in RIP's coffin is that with most (if not all) routers out there today, it's no more work to turn on and configure OSPF than it is to do RIP, and OSPF will help you scale much better as you go without being too complex for the simpler setups as well. As such, it really doesn't make sense to go with RIP for mere nostalgia's sake. If you have a specific reason not to run OSPF, fine, but those reasons are few and far between. -C From yasu at jaist.ac.jp Thu Sep 30 03:37:37 2010 From: yasu at jaist.ac.jp (Yasuhiro Ohara) Date: Thu, 30 Sep 2010 12:37:37 +0900 (JST) Subject: RIP Justification In-Reply-To: <4CA3E45D.5070900@emanon.com> References: <4CA3E45D.5070900@emanon.com> Message-ID: <20100930.123737.51946961.yasu@jaist.ac.jp> hi, I summarize the discussion in my way. Please add or fix it. * RIP works okay in topologies without topological loops. I would like to elaborate the term "small networks" in "RIP works well in small networks". Specifically the term "small network" would mean: 1) the diameter of the network is less than 15 hops, 2) the network does not include topological loop, and 3) the #routes exchanged in it is small. One does not need to care about 1) unless he or she wants to use the path with more than 15 hops. 2) is important to care because it leads to counting-to-infinity. For 3), if the #routes is large, the routing message may seem to be really redundant or painfull (refer poisonous reverse discussion). I am wondering whether someone saying "working well in small networks" checks if the counting-to-infinity occurs on their networks. I guess Counting-to-infinity is really hard to catch. I think RIP works "okay" in a whatever-large network, if above 3 points are fine with us. But I would not like to call the case "works well". * Routing control message seems more redundant in RIP. Every 30 seconds may seem redundant. You may need to advertise the prefix that doesn't exist in some cases (poisonous reverse). * RIP have rooms to fix, tweak, or hack the routes. The algorithm works okay with rejecting and modifying the routes (filters) at an arbitrary point in the network. Link State routing protocols including OSPF and IS-IS basically do not support this. This is the pros in RIP. * RIP algorithm is simple, but debugging is really hard. You would never want to debug what is happening in RIP, when a problem occurs such as Counting-to-infinity. The state of the routes changes too quickly to catch, and you must track the logs of all the routers on the way. This is almost impossible. * OSPF algorithm (i.e. DB exchange) is complex, but debugging is simple. OSPF is easy to debug because one can point out the bad part easily by comparing DBs. If DBs are sync'ed, they are okay. If DBs are not sync'ed, the source of the problem lies in either (or both) of the routers. If the DB is sync'ed but routes are strange, then the problem lies in the Dijkstra code in the router. Most operators prefers this characteristic (feature). In all of the above case, you can simply replace the router to fix the problem. (Check if the router-id conflicts first, when DB changes so quickly.) Most people hates DB exchange in OSPF since it is hard to understand. So, some prefers IS-IS more, because the DB exchange algorithm is simpler. Complex algorithm in DB exchange may produce bugs, but may prevent (or at least alert) some problems that is hard to debug. * Complexities in configuring them are not much different. As someone stated, tasks necessary to configure, e.g., turn on protocol, include network I/F, ..., walk away, are equivalent for both. I support "everything has its place". In summary, if you can avoid topological loop in your network, I think RIP works okay even in a large network. regards, yasu From nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org Thu Sep 30 03:42:34 2010 From: nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org (Mark Smith) Date: Thu, 30 Sep 2010 13:12:34 +0930 Subject: RIP Justification In-Reply-To: <7D228D09-4C49-4A45-A985-F7305AED9A62@gmail.com> References: <7D228D09-4C49-4A45-A985-F7305AED9A62@gmail.com> Message-ID: <20100930131234.52a833f7@opy.nosense.org> On Wed, 29 Sep 2010 17:26:17 -0400 Craig wrote: > We have a design for our wan where we use rip v2 and it works very well, we were using ospf but it was additional config, so in our case simple was better, and it works well.. > I'm don't really buy the extra config argument. It's literally differences measured in seconds or minutes between the configuration effort, and in the context of the operational benefits over time of link state verses distance vector, I think they're worth spending. However, if you want a really simple OSPF config, the following two lines will make OSPF just work everywhere it can on a Cisco router router ospf 64512 network 0.0.0.0 255.255.255.255 area 0 One of the large delays you see in OSPF is election of the designated router on multi-access links such as ethernets. As ethernet is being very commonly used for point-to-point non-edge links, you can eliminate that delay and also the corresponding network LSA by making OSPF treat the link as a point-to-point link e.g. int ethernet0 ip ospf network point-to-point If your implementation doesn't support point-to-point mode for an interface, point-to-multipoint mode on an ethernet would achieve something somewhat equivalent. > I could discuss it more with you off-line if you like. > > > > On Sep 29, 2010, at 4:20 PM, Jesse Loggins wrote: > > > A group of engineers and I were having a design discussion about routing > > protocols including RIP and static routing and the justifications of use for > > each protocol. One very interesting discussion was surrounding RIP and its > > use versus a protocol like OSPF. It seems that many Network Engineers > > consider RIP an old antiquated protocol that should be thrown in back of a > > closet "never to be seen or heard from again". Some even preferred using a > > more complex protocol like OSPF instead of RIP. I am of the opinion that > > every protocol has its place, which seems to be contrary to some engineers > > way of thinking. This leads to my question. What are your views of when and > > where the RIP protocol is useful? Please excuse me if this is the incorrect > > forum for such questions. > > > > -- > > Jesse Loggins > > CCIE#14661 (R&S, Service Provider) > From owen at delong.com Thu Sep 30 03:40:16 2010 From: owen at delong.com (Owen DeLong) Date: Wed, 29 Sep 2010 20:40:16 -0700 Subject: RIP Justification In-Reply-To: References: <003801cb6014$fd2f0280$f78d0780$@edu> <20100930092705.3a05d811@opy.nosense.org> Message-ID: On Sep 29, 2010, at 5:31 PM, Christopher Gatlin wrote: > My point here is untrusted networks, such as business partners exchanging > routes with each other. Not many hops and less than a 100 prefixes. > > Using BGP to exchange routes between these types of untrusted networks is > like using a sledgehammer to crack a nut. BGP was designed for unique AS's > to peer in large scale networks such as the internet. A far cry from > business partners exchanging dynamic routes for fault tolerance. > No, it's like using a wrench to tighten a nut. Using RIPv2 for the task is like using a pair of pliers. > I've seen RIPv2 very successfully deployed in modern networks in this > fashion. I advocate using an appropriate tool for the job. > So do I. Use a wrench, not a pair of pliers, no matter how much it seems easier to reach the piers. Owen > > Christopher Gatlin > CCIE #15245 (R&S/Security) > > > On Wed, Sep 29, 2010 at 6:57 PM, Mark Smith < > nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org> wrote: > >> On Wed, 29 Sep 2010 15:35:06 -0500 >> Christopher Gatlin wrote: >> >>> RIPv2 is a great dynamic routing protocol for exchanging routes with >>> untrusted networks. RIPv2 has adjustable timers, filters, supports VLSM >> and >>> MD5 authentication. Since it's distance vector it's much easier to >> filter >>> than a protocol that uses a link state database that must be the same >> across >>> an entire area. >>> >> >> I think BGP is better for that job, ultimately because it was >> specifically designed for that job, but also because it's now available >> in commodity routers for commodity prices e.g. Cisco 800 series. >> >> >> From rfg at tristatelogic.com Thu Sep 30 03:50:05 2010 From: rfg at tristatelogic.com (Ronald F. Guilmette) Date: Wed, 29 Sep 2010 20:50:05 -0700 Subject: AS11296 -- Hijacked? Message-ID: <90723.1285818605@tristatelogic.com> I confess that I find it somewhat tedious to try to answer all criticisms, individually, on a mailing list when people start ``piling on'', so I hope you'll all forgive me if I just try to to do this in one go. First, as regards to the lack of detail and/or specific in my reports, I was specifically insructed, by a gentleman who has far more experience participating here, on the NANOG mailing list, that I do, that I should NOT include too much lengthy elaboration and/or detail because (rough quote) ``... those folks in NANOG really only much care about routers and stuff like that, so don't even digress into topics like spam and such, or give a whole lot of lengthy details, because their eyes will just glaze over and/or you'll be accused of being off-topic. Many of them probably don't even know what the term `snowshoe spamming' refers to anyway.'' I'll be happy to provide all of the abundant evidence I've collected to anyone I can verify as being a legitimate network op offlist. I do need to say however that much of the relevantevidence can be ob- tained quite easily, and without any spoon feeding from me, i.e. directly in the form of applicable/relevant ARIN whois records, all of which are available to anyone. Other evidence, specifically the routes that _were_ being announced by AS11296 (and those that still are, currently, by AS10392) is also freely and publically available from you local friendly looking glass server. I have additional evidence... not so much of hijacking, but more relating to possible/probable snowshoe spamming activity... that is derived, indirectly, from public data sources, upon which I perform additional crunching with personally-developed, proprietary software... and that is stuff that I'll be happy to make available to anybody who can convince me that they are not playing for the other team. To the gentleman who wished me good luck in ``getting assistance from the list in the future'', I thank you for the generosity implied by your sentiment, and would only like to point out that on this occasion, at least (and on none others that I can remember off the top of my head) did I or have I requested assistance from the NANOG mailing list. On this occasion, I believe (and believed) that I was _offering_ my help to NANOG, rather than the other way 'round.) But again, I thank you for your concern anyway. To the gentleman who asked (with respect to the widespread... but certainly not universal... use of freemail accounts) whether or not ``the general population are all doing it wrong'', I would answer in the affirmative, generally, and not specifically with respect to the use of freemail accounts. As supporting evidence, I ask that you please begin reading here: http://en.wikipedia.org/wiki/Financial_crisis_of_2007%E2%80%932010 (I have a small mountain of documentation available to support the view that ``the general population are all doing it wrong'' with respect to almost anything you can name, and will be only too happy to provide more links as required/requested.) To the gentleman who suggested that my un-acceptance of e-mail from gmail, specifically, might be a black mark aganist my credibility, that's fine, I have no problem with that. I certainly never expected nor hoped that anybody would take any action of any kind based either on my perceived ephemeral and transitory credibility, or the perceived lack therof. For the two recent reports I have made here, and others I may make in future, the publically available evidence speaks for itself, and my personal credibility, or lack thereof, is neither here nor there, as a practical matter. I am not running for office, and I'm not tring to sell aluminum siding. What you think of me personally doesn't affect whether a given AS or IP block either is or isn't hijacked. Facts are facts... in this case mostly publically available... and thankfully are not dependant upon any one person for validation, least of all me. To the gentleman who quoted "A decent respect to the opinions of mankind requires that they should declare the causes.", the beauty and elegance of that sentiment, and its formulation, while undeniable and holding great appeal for any and all who call these United States home, actually applied to a rather different and more serious situation, I think, i.e. the dis- solution of political bands... dissolution which, I think everyone knew at the time, was highly likely to lead to a costly and bloody war... a rather more serious outcome than any likely to derive from a mere NANOG posting. Still, you make a reasonable point, and my only response is to reiterate what I have said above, i.e. that most of the substantiating documentation is readily and freely available from various public sources, and requires only the most modest amounts of motivation to independently obtain. To the gentleman who suggested that one could perpetrate what amounted to a DDoS attack, simply by making a derogatory posting about a given network on the NANOG mailing list, I can only ask ``Does that really work??'' If it does, then I'll have to remember to try it sometime, when I'm bored. (There are lots of naughty people on the Internet I'd like to spank, but I think that if I was really of a mind to seriously spank some of them, I might try route injection first. More effective and far more 31337. Plus I think the Russians are having a half price sale on that service next month. :-) To the gentleman who pointed out that a so-called ``appeal to authority'' is a lousey way to try to support any given claim, yea, you're absolutely right. I try never to do it myself. Personally, I find facts much more persuasive that anybody's rep. That same gentleman apparently took issue with my original post, apparently asserting that it wasn't ``...written in a way that recognizes that clued, skeptical individuals are going to carefully analyze it.'' All I can say is that in my own humble opinion, it actually _was_ written in _precisely_ that way. (The fact that it was witten that way partly explains why it was so terse.) To the gentleman who suggested that I was "Joe Blow", I can only say "Yea? So? Even if I am, what's yer point?" Just as nobody should evaluate important claims based only on somone's positive reputation alone, likewise, in my view, nobody should evaluate important claims exclusively on the basis of anyones negative or non-existant reputation either. I _am_ Joe Blow, and proud of it! To paraphrase an old TV commercial ``Don't hate me because I'm pretty. Don't believe me because I'm "somebody". Don't dis-believe me because I'm "nobody". You've got a keybord and eyes of your own. May I respectfully suggest that you use them?'' Regards, rfg From nanog at studio442.com.au Thu Sep 30 04:13:11 2010 From: nanog at studio442.com.au (Julien Goodwin) Date: Thu, 30 Sep 2010 14:13:11 +1000 Subject: RIP Justification In-Reply-To: <20100930131234.52a833f7@opy.nosense.org> References: <7D228D09-4C49-4A45-A985-F7305AED9A62@gmail.com> <20100930131234.52a833f7@opy.nosense.org> Message-ID: <4CA40E57.1070406@studio442.com.au> On 30/09/10 13:42, Mark Smith wrote: > One of the large delays you see in OSPF is election of the designated > router on multi-access links such as ethernets. As ethernet is being > very commonly used for point-to-point non-edge links, you can eliminate > that delay and also the corresponding network LSA by making OSPF treat > the link as a point-to-point link e.g. > > int ethernet0 > ip ospf network point-to-point > > > If your implementation doesn't support point-to-point mode for an > interface, point-to-multipoint mode on an ethernet would achieve > something somewhat equivalent. Do any implementations go point-to-point automatically if an ethernet has a /30 or /31 mask? From nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org Thu Sep 30 04:29:41 2010 From: nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org (Mark Smith) Date: Thu, 30 Sep 2010 13:59:41 +0930 Subject: RIP Justification In-Reply-To: References: <003801cb6014$fd2f0280$f78d0780$@edu> <20100930092705.3a05d811@opy.nosense.org> Message-ID: <20100930135941.33ff03e2@opy.nosense.org> On Wed, 29 Sep 2010 19:31:26 -0500 Christopher Gatlin wrote: > My point here is untrusted networks, such as business partners exchanging > routes with each other. Not many hops and less than a 100 prefixes. > > Using BGP to exchange routes between these types of untrusted networks is > like using a sledgehammer to crack a nut. BGP was designed for unique AS's > to peer in large scale networks such as the internet. A far cry from > business partners exchanging dynamic routes for fault tolerance. > I've used BGP quite a fair bit, for both Internet scale and small scale routing scenarios such as the one I recommended. How do you prevent those business partners spoofing specific route announcements within the RIP update, intentionally or otherwise, such as a default route, causing either outages or attracting traffic towards their networks that shouldn't be? A shared RIP MD5 key between the routers doesn't validate the route information within the RIP update. All the routers within your business partner domain will blindly accept and trust the routing information in any and all of the RIP updates they receive. Do the businesses attached have a multilateral or bi-lateral routing relationship? If routing relationship is multilateral, which is likely because you're using RIP, are the business partners using IPsec to ensure that if the routing is subverted, their traffic isn't disclosed to partners it shouldn't be? The scenario you're describing sounds pretty much exactly like a internet/peering exchange is between ISPs. The routing security issues are similar if not the same. In either multilateral or bi-lateral routing scenarios, BGP will provide you with the mechanisms needed to provide more trustworthy routing in these peer exchange type scenarios. > I've seen RIPv2 very successfully deployed in modern networks in this > fashion. Popular doesn't always equal good. Britney Spear's music is a testament to that. The threshold of success isn't if something works. It's whether it continues to work in the face of adversity. I'd think your business partner customers would expect a highly available service that is resilient to predictable and preventable adverse events, with a fairly likely one to be accidental route injection. > I advocate using an appropriate tool for the job. > As do I, and therefore I don't worry to much about the specific scenarios the tool was designed for - if the chosen tool provides the most appropriate and relevant benefits for an acceptable cost, the original design scenario doesn't matter. Regards, Mark. From nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org Thu Sep 30 04:57:32 2010 From: nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org (Mark Smith) Date: Thu, 30 Sep 2010 14:27:32 +0930 Subject: RIP Justification In-Reply-To: <4CA40E57.1070406@studio442.com.au> References: <7D228D09-4C49-4A45-A985-F7305AED9A62@gmail.com> <20100930131234.52a833f7@opy.nosense.org> <4CA40E57.1070406@studio442.com.au> Message-ID: <20100930142732.39aa5869@opy.nosense.org> On Thu, 30 Sep 2010 14:13:11 +1000 Julien Goodwin wrote: > On 30/09/10 13:42, Mark Smith wrote: > > One of the large delays you see in OSPF is election of the designated > > router on multi-access links such as ethernets. As ethernet is being > > very commonly used for point-to-point non-edge links, you can eliminate > > that delay and also the corresponding network LSA by making OSPF treat > > the link as a point-to-point link e.g. > > > > int ethernet0 > > ip ospf network point-to-point > > > > > > If your implementation doesn't support point-to-point mode for an > > interface, point-to-multipoint mode on an ethernet would achieve > > something somewhat equivalent. > > Do any implementations go point-to-point automatically if an ethernet > has a /30 or /31 mask? Don't know. If you want to see what interface model OSPF is using, on a Cisco you use show ip ospf interface The interface type for loopback interfaces can be a bit surprising and the consequences a bit unexpected if you're intentionally or otherwise not using a /32 prefix length on one. Regards, Mark. From william.mccall at gmail.com Thu Sep 30 06:15:45 2010 From: william.mccall at gmail.com (William McCall) Date: Thu, 30 Sep 2010 01:15:45 -0500 Subject: RIP Justification In-Reply-To: References: <035FE016D625174BA7C7A9FA83E6C17987147CE602@winexmp02> Message-ID: On Wed, Sep 29, 2010 at 7:31 PM, Christopher Gatlin wrote: > Using BGP to exchange routes between these types of untrusted networks is > like using a sledgehammer to crack a nut. BGP was designed for unique AS's > to peer in large scale networks such as the internet. A far cry from > business partners exchanging dynamic routes for fault tolerance. But on the flipside, arguing that we're providing this business parter service with no sort of broadcast mechanism, does the complexity actually increase between a proper implementation of BGP versus properly implementing RIP for the same scenario? Consider this example: 2 business partners terminating on the same device, we are advertising 1 prefix to both and receiving 1 prefix from each. Each has redundant connections to another router. Goals: 1) Prevent BP A from advertising routes owned by BP B and vice-versa 2) Advertise only the single prefix to the BPs 3) No broadcast medium, so we'll need neighbor statements 4) Prefix advertised to peers originates from IGP Mentally configuring this (in cisco terms), it seems about the same in terms of config complexity. Filtering the prefixes from each of the neighbors is required and the ACL to do this looks kind of nasty in RIP. Also, you'll need to redistribute from the IGP and add either an egress distribute list or a route map on the redistribution into RIP. Finally, redistribute back into the IGP for the received prefixes. BGP gives a slightly nicer-looking policy with a route map for each of the neighbors and policy building features that make scaling the solution slightly easier since route-maps can be reused and attached to the neighbor through whatever mechanism you want. And no funky-looking ACLs to describe how to accept prefixes and no need to redistribute from the IGP. Also, if choosing to run iBGP between redundant nodes, its quite a bit more simplified to set metrics to determine primary and redundant paths since this can be done on the same ingress policy. On Wed, Sep 29, 2010 at 10:19 PM, Chris Woodfield wrote: > (or, ghod forbid, multiple OSPF processes redistributing between each other...) > I think I have an anxiety disorder from this sort of "design".. On Wed, Sep 29, 2010 at 11:29 PM, Mark Smith wrote: > How do you prevent those business partners spoofing specific > route announcements within the RIP update, intentionally or otherwise, > such as a default route, causing either outages or attracting traffic > towards their networks that shouldn't be? Ingress filtering for prefixes can be performed with RIP. It just looks really funky compared to route maps for neighbors in BGP. > [...] I don't worry to much about the specific > scenarios the tool was designed for - if the chosen tool provides the > most appropriate and relevant benefits for an acceptable cost, > the original design scenario doesn't matter. True that BGP is generally better in most external routing instances. But there are other cost factors involved with doing BGP - fear and knowledge. A lot of less experienced folk out there are outright afraid of the concepts behind BGP and/or do not have the requisite skills to maintain it. That shouldn't justify bad design decisions, but it often does. Plus, it could be postulated that proper implementation of RIP in the same scenario would be hindered by the lack of knowledge still. Also, it should be pointed out that there are security products and others that don't support BGP. In those instances, it might make some sense to choose RIP. Other limiting factors can include resource and feature availablity on the terminating device(s) (as addressed by others). -- William McCall From rfg at tristatelogic.com Thu Sep 30 06:44:38 2010 From: rfg at tristatelogic.com (Ronald F. Guilmette) Date: Wed, 29 Sep 2010 23:44:38 -0700 Subject: What must one do to avoid Gmail's retarded non-spam filtering? In-Reply-To: Message-ID: <92850.1285829078@tristatelogic.com> In message , Ryan Hayes wrote: >Can you please not use the word "retarded" in a pejorative sense? Obviously not a Colbert fan. http://www.huffingtonpost.com/2010/02/09/colbert-sarah-palin-is-a_n_454744.html Regards, rfg P.S. It's satire. From nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org Thu Sep 30 08:38:48 2010 From: nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org (Mark Smith) Date: Thu, 30 Sep 2010 18:08:48 +0930 Subject: RIP Justification In-Reply-To: References: <035FE016D625174BA7C7A9FA83E6C17987147CE602@winexmp02> Message-ID: <20100930180848.6659f769@opy.nosense.org> On Thu, 30 Sep 2010 01:15:45 -0500 William McCall wrote: > On Wed, Sep 29, 2010 at 7:31 PM, Christopher Gatlin > wrote: > > Using BGP to exchange routes between these types of untrusted networks is > > like using a sledgehammer to crack a nut. BGP was designed for unique AS's > > to peer in large scale networks such as the internet. A far cry from > > business partners exchanging dynamic routes for fault tolerance. > > But on the flipside, arguing that we're providing this business parter > service with no sort of broadcast mechanism, does the complexity > actually increase between a proper implementation of BGP versus > properly implementing RIP for the same scenario? > > Consider this example: > 2 business partners terminating on the same device, we are advertising > 1 prefix to both and receiving 1 prefix from each. Each has redundant > connections to another router. > > Goals: > 1) Prevent BP A from advertising routes owned by BP B and vice-versa > 2) Advertise only the single prefix to the BPs > 3) No broadcast medium, so we'll need neighbor statements > 4) Prefix advertised to peers originates from IGP > > Mentally configuring this (in cisco terms), it seems about the same in > terms of config complexity. Filtering the prefixes from each of the > neighbors is required and the ACL to do this looks kind of nasty in > RIP. Also, you'll need to redistribute from the IGP and add either an > egress distribute list or a route map on the redistribution into RIP. > Finally, redistribute back into the IGP for the received prefixes. > > BGP gives a slightly nicer-looking policy with a route map for each of > the neighbors and policy building features that make scaling the > solution slightly easier since route-maps can be reused and attached > to the neighbor through whatever mechanism you want. And no > funky-looking ACLs to describe how to accept prefixes and no need to > redistribute from the IGP. Also, if choosing to run iBGP between > redundant nodes, its quite a bit more simplified to set metrics to > determine primary and redundant paths since this can be done on the > same ingress policy. > > > On Wed, Sep 29, 2010 at 10:19 PM, Chris Woodfield wrote: > > (or, ghod forbid, multiple OSPF processes redistributing between each other...) > > > I think I have an anxiety disorder from this sort of "design".. > > On Wed, Sep 29, 2010 at 11:29 PM, Mark Smith > wrote: > > How do you prevent those business partners spoofing specific > > route announcements within the RIP update, intentionally or otherwise, > > such as a default route, causing either outages or attracting traffic > > towards their networks that shouldn't be? > > Ingress filtering for prefixes can be performed with RIP. It just > looks really funky compared to route maps for neighbors in BGP. > The best place to configure the prefix filtering would be on admission to the routing domain, rather than on exit. To achieve any sort of accurate route filtering in a RIP environment you'd have to maintain ingress route filters on all of the business partner routers. That'd be much harder to maintain accurately due to the number of business partner routers than a single per-business customer inbound route filter on a couple of BGP Route Reflectors/Servers. Those business customers may not trust you to operate their routers, so your routing accuracy is dependent on how well administered those business partner routers are maintained, which is likely to be very inconsistently. If you were operating the business peering exchange as a paid third party, and were providing SLAs for the service, then you wouldn't be in control of something that is essential to maintaining the quality and availability of the service. > > [...] I don't worry to much about the specific > > scenarios the tool was designed for - if the chosen tool provides the > > most appropriate and relevant benefits for an acceptable cost, > > the original design scenario doesn't matter. > > True that BGP is generally better in most external routing instances. > But there are other cost factors involved with doing BGP - fear and > knowledge. A lot of less experienced folk out there are outright > afraid of the concepts behind BGP and/or do not have the requisite > skills to maintain it. Then they're not the right people to be operating this network because they're not competent to. It sounds a bit like you're justifying people saying "I want to be paid to be an expert in this field, but I don't want to actually be an expert." I find this cop-out extremely irritating. You either know what you're doing or you don't, and if you don't, you shouldn't be selling yourself as somebody who does. > That shouldn't justify bad design decisions, > but it often does. Plus, it could be postulated that proper > implementation of RIP in the same scenario would be hindered by the > lack of knowledge still. > > Also, it should be pointed out that there are security products and > others that don't support BGP. In those instances, it might make some > sense to choose RIP. Other limiting factors can include resource and > feature availablity on the terminating device(s) (as addressed by > others). > Then you buy a cheap BGP speaking device e.g. a Cisco 800 to put in front of it. Regards, Mark. From tim at pelican.org Thu Sep 30 09:32:59 2010 From: tim at pelican.org (Tim Franklin) Date: Thu, 30 Sep 2010 09:32:59 +0000 (GMT) Subject: RIP Justification In-Reply-To: <19118529.01285839050094.JavaMail.root@jennyfur.pelican.org> Message-ID: <23856110.21285839179181.JavaMail.root@jennyfur.pelican.org> > I think BGP is better for that job, ultimately because it was > specifically designed for that job, but also because it's now > available > in commodity routers for commodity prices e.g. Cisco 800 series. +1 - for me, if I need a dynamic routing protocol between trust / administrative domains, it's BGP unless there's a good reason not to. I find it more straightforward to work with (albeit slightly more up-front to configure it and get it right) than anything else - the information available is a very clear "who am I talking to?" / "what routes do I send them?" / "what routes do they send me?". Plus I can work through the route-selection process by hand from the information displayed, and have it make sense. Regards, Tim. From hj1980 at gmail.com Thu Sep 30 09:49:17 2010 From: hj1980 at gmail.com (Heath Jones) Date: Thu, 30 Sep 2010 10:49:17 +0100 Subject: BGP next-hop Message-ID: Hi all, Is there an easy way to see which iBGP routes are not being selected due to next-hop not being in IGP? Before and after IGP route added shown below, note both are marked as valid.. -- BEFORE IGP-- AS5000_LA#show ip bgp BGP table version is 5, local router ID is 10.0.0.5 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S Stale Origin codes: i - IGP, e - EGP, ? - incomplete Network Next Hop Metric LocPrf Weight Path * i100.10.0.0/16 10.0.0.10 0 100 0 2000 3000 ? *> 10.0.0.6 0 1000 3000 3000 ? -- AFTER IGP-- AS5000_LA#show ip bgp BGP table version is 6, local router ID is 10.0.0.5 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S Stale Origin codes: i - IGP, e - EGP, ? - incomplete Network Next Hop Metric LocPrf Weight Path *>i100.10.0.0/16 10.0.0.10 0 100 0 2000 3000 ? * 10.0.0.6 0 1000 3000 3000 ? Cheers Heath ps. I've posted this to cisco-nsp also (a day ago) - so apologies in advance if you are on both and seeing it twice. From jsaxe at briworks.com Thu Sep 30 11:13:51 2010 From: jsaxe at briworks.com (Jeff Saxe) Date: Thu, 30 Sep 2010 04:13:51 -0700 Subject: BGP next-hop In-Reply-To: References: Message-ID: Yes, I believe the command is "show ip bgp rib-failure". This shows routes that are in the BGP table, theoretically eligible to be used as actual traffic-forwarding routes, but are failing to be inserted into the Routing Information Base (RIB) for one reason or another. I don't have a lab router handy to lab it up, and of course on my normal production router it comes up empty (lists column headers, but no routes) because I don't have any edge cases on there right now. But I think this is what you want. -- Jeff Saxe Network Engineer, Blue Ridge InternetWorks Charlottesville, VA ________________________________________ From: Heath Jones [hj1980 at gmail.com] Sent: Thursday, September 30, 2010 5:49 AM To: nanog at nanog.org Subject: BGP next-hop Hi all, Is there an easy way to see which iBGP routes are not being selected due to next-hop not being in IGP? Before and after IGP route added shown below, note both are marked as valid.. -- BEFORE IGP-- AS5000_LA#show ip bgp BGP table version is 5, local router ID is 10.0.0.5 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S Stale Origin codes: i - IGP, e - EGP, ? - incomplete Network Next Hop Metric LocPrf Weight Path * i100.10.0.0/16 10.0.0.10 0 100 0 2000 3000 ? *> 10.0.0.6 0 1000 3000 3000 ? -- AFTER IGP-- AS5000_LA#show ip bgp BGP table version is 6, local router ID is 10.0.0.5 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S Stale Origin codes: i - IGP, e - EGP, ? - incomplete Network Next Hop Metric LocPrf Weight Path *>i100.10.0.0/16 10.0.0.10 0 100 0 2000 3000 ? * 10.0.0.6 0 1000 3000 3000 ? Cheers Heath ps. I've posted this to cisco-nsp also (a day ago) - so apologies in advance if you are on both and seeing it twice. From hj1980 at gmail.com Thu Sep 30 13:14:13 2010 From: hj1980 at gmail.com (Heath Jones) Date: Thu, 30 Sep 2010 14:14:13 +0100 Subject: BGP next-hop In-Reply-To: References: Message-ID: Cheers Jeff. I thought i'd give that a go, but it doesnt seem to be working for some reason! (This is without next-hop in IGP) AS5000_LA#show ip bgp BGP table version is 3, local router ID is 10.0.0.5 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S Stale Origin codes: i - IGP, e - EGP, ? - incomplete Network Next Hop Metric LocPrf Weight Path *> 100.10.0.0/16 10.0.0.6 0 1000 3000 3000 ? * i 10.0.0.10 0 100 0 2000 3000 ? AS5000_LA#show ip bgp rib-failure Network Next Hop RIB-failure RIB-NH Matches AS5000_LA# AS5000_LA#show ip bgp 100.10.0.0 BGP routing table entry for 100.10.0.0/16, version 3 Paths: (2 available, best #1, table Default-IP-Routing-Table) Flag: 0x820 Advertised to update-groups: 2 1000 3000 3000 10.0.0.6 from 10.0.0.6 (10.0.0.13) Origin incomplete, localpref 100, valid, external, best 2000 3000 10.0.0.10 (inaccessible) from 10.0.0.2 (10.0.0.9) Origin incomplete, metric 0, localpref 100, valid, internal >From the detail view, the route is marked as inaccessible. Perhaps this is the only way to get to it.. Heath From jbates at brightok.net Thu Sep 30 13:27:29 2010 From: jbates at brightok.net (Jack Bates) Date: Thu, 30 Sep 2010 08:27:29 -0500 Subject: RIP Justification In-Reply-To: References: Message-ID: <4CA49041.1080305@brightok.net> On 9/29/2010 3:20 PM, Jesse Loggins wrote: > What are your views of when and > where the RIP protocol is useful? Home networks when dual NAT isn't being used. It's also the perfect protocol for v6 on home networks where multiple home routers might be connected in a variety of ways. Shocked I didn't even see v6 mentioned in the thread (though you did clarify v2, which isn't the v6 implementation). :( Jack From owen at delong.com Thu Sep 30 13:46:17 2010 From: owen at delong.com (Owen DeLong) Date: Thu, 30 Sep 2010 06:46:17 -0700 Subject: RIP Justification In-Reply-To: <4CA49041.1080305@brightok.net> References: <4CA49041.1080305@brightok.net> Message-ID: <712B5BDF-D6CC-4FE4-ABAF-C2958DF974DE@delong.com> On Sep 30, 2010, at 6:27 AM, Jack Bates wrote: > On 9/29/2010 3:20 PM, Jesse Loggins wrote: >> What are your views of when and >> where the RIP protocol is useful? > > Home networks when dual NAT isn't being used. It's also the perfect protocol for v6 on home networks where multiple home routers might be connected in a variety of ways. > I have no NAT whatsoever in my home network. RIP is not at all useful in my scenario. I have multiple routers in my home network. They use a combination of BGP and OSPFv3. > Shocked I didn't even see v6 mentioned in the thread (though you did clarify v2, which isn't the v6 implementation). :( > If your network is of a scale where it exceeds the utility of static, then, it is almost certainly of a scale and topology where it exceeds the utility of RIP. Owen From swm at emanon.com Thu Sep 30 13:50:05 2010 From: swm at emanon.com (Scott Morris) Date: Thu, 30 Sep 2010 09:50:05 -0400 Subject: RIP Justification In-Reply-To: <0A131ECD-D7F3-408F-8D9B-B71DD69B4C76@semihuman.com> References: <4CA3E45D.5070900@emanon.com> <0A131ECD-D7F3-408F-8D9B-B71DD69B4C76@semihuman.com> Message-ID: <4CA4958D.2080808@emanon.com> One would assume you aren't doing this for nostalgic reasons. At least I would hope that! Like anything, if you decide to vary outside the 'accepted norms', then have a reason for it! Understand your technology, understand your topology (re: before about RIP not needing peered neighbors whereas OSPF does) and you may have your justification. If it's for nostalgia or "just because", then I'd say everyone agrees that RIP has passed its usefulness! Scott On 9/29/10 11:32 PM, Chris Woodfield wrote: > On Sep 29, 2010, at 6:14 PM, Scott Morris wrote: > >> But anything, ask why you are using it. To exchange routes, yes... but >> how many. Is sending those every 30 seconds good? Sure, tweak it. But >> are you gaining anything over static routes? > For simple networks, RIP(v2, mind you) works fine. You're correct that the number of advertisements sent over the wire every 30 seconds won't scale, but with today's routers and bandwidths it takes quite a lot to start to cause issues. > > The real nail in RIP's coffin is that with most (if not all) routers out there today, it's no more work to turn on and configure OSPF than it is to do RIP, and OSPF will help you scale much better as you go without being too complex for the simpler setups as well. As such, it really doesn't make sense to go with RIP for mere nostalgia's sake. If you have a specific reason not to run OSPF, fine, but those reasons are few and far between. > > -C > From swm at emanon.com Thu Sep 30 13:55:17 2010 From: swm at emanon.com (Scott Morris) Date: Thu, 30 Sep 2010 09:55:17 -0400 Subject: RIP Justification In-Reply-To: <20100930142732.39aa5869@opy.nosense.org> References: <7D228D09-4C49-4A45-A985-F7305AED9A62@gmail.com> <20100930131234.52a833f7@opy.nosense.org> <4CA40E57.1070406@studio442.com.au> <20100930142732.39aa5869@opy.nosense.org> Message-ID: <4CA496C5.8020806@emanon.com> On 9/30/10 12:57 AM, Mark Smith wrote: On Thu, 30 Sep 2010 14:13:11 +1000 Julien Goodwin [1] wrote: On 30/09/10 13:42, Mark Smith wrote: One of the large delays you see in OSPF is election of the designated router on multi-access links such as ethernets. As ethernet is being very commonly used for point-to-point non-edge links, you can eliminate that delay and also the corresponding network LSA by making OSPF treat the link as a point-to-point link e.g. int ethernet0 ip ospf network point-to-point If your implementation doesn't support point-to-point mode for an interface, point-to-multipoint mode on an ethernet would achieve something somewhat equivalent. Do any implementations go point-to-point automatically if an ethernet has a /30 or /31 mask? Don't know. Nope. Not Cisco anyway. NDC-R1-CustA(config)#int f0/0 NDC-R1-CustA(config-if)#ip addr 10.111.1.1 255.255.255.254 % Warning: use /31 mask on non point-to-point interface cautiously NDC-R1-CustA(config-if)# *Sep 30 15:18:22.710: %OSPF-5-ADJCHG: Process 1, Nbr 10.133.1.2 on FastEthernet0/0 from FULL to DOWN, Neighbor Down: Interface down or detached NDC-R1-CustA(config-if)# NDC-R1-CustA(config-if)#do sh ip o i f0/0 | i Type|Address Internet Address 10.111.1.1/31, Area 0 Process ID 1, Router ID 192.168.1.1, Network Type BROADCAST, Cost: 1 NDC-R1-CustA(config-if)# HTH, Scott On 9/30/10 12:57 AM, Mark Smith wrote: On Thu, 30 Sep 2010 14:13:11 +1000 Julien Goodwin [2] wrote: On 30/09/10 13:42, Mark Smith wrote: One of the large delays you see in OSPF is election of the designated router on multi-access links such as ethernets. As ethernet is being very commonly used for point-to-point non-edge links, you can eliminate that delay and also the corresponding network LSA by making OSPF treat the link as a point-to-point link e.g. int ethernet0 ip ospf network point-to-point If your implementation doesn't support point-to-point mode for an interface, point-to-multipoint mode on an ethernet would achieve something somewhat equivalent. Do any implementations go point-to-point automatically if an ethernet has a /30 or /31 mask? Don't know. If you want to see what interface model OSPF is using, on a Cisco you use show ip ospf interface The interface type for loopback interfaces can be a bit surprising and the consequences a bit unexpected if you're intentionally or otherwise not using a /32 prefix length on one. Regards, Mark. References 1. mailto:nanog at studio442.com.au 2. mailto:nanog at studio442.com.au From jbates at brightok.net Thu Sep 30 13:56:36 2010 From: jbates at brightok.net (Jack Bates) Date: Thu, 30 Sep 2010 08:56:36 -0500 Subject: RIP Justification In-Reply-To: <712B5BDF-D6CC-4FE4-ABAF-C2958DF974DE@delong.com> References: <4CA49041.1080305@brightok.net> <712B5BDF-D6CC-4FE4-ABAF-C2958DF974DE@delong.com> Message-ID: <4CA49714.40007@brightok.net> On 9/30/2010 8:46 AM, Owen DeLong wrote: > I have no NAT whatsoever in my home network. RIP is not at all useful in my scenario. > > I have multiple routers in my home network. They use a combination of BGP and OSPFv3. > Except you must configure those things. The average home user cannot. > If your network is of a scale where it exceeds the utility of static, then, it is almost certainly of a scale > and topology where it exceeds the utility of RIP. While it is possible for a router to create static routes automatically based on DHCPv6 assignment information, this has no loop prevention and is suboptimal depending on the configuration that things get plugged in. I'm not talking good network design here. I'm talking, buy box, plug in wherever it fits. Things should work. Jack From bicknell at ufp.org Thu Sep 30 14:01:19 2010 From: bicknell at ufp.org (Leo Bicknell) Date: Thu, 30 Sep 2010 07:01:19 -0700 Subject: BGP next-hop In-Reply-To: References: Message-ID: <20100930140119.GA6643@ussenterprise.ufp.org> In a message written on Thu, Sep 30, 2010 at 10:49:17AM +0100, Heath Jones wrote: > Is there an easy way to see which iBGP routes are not being selected > due to next-hop not being in IGP? I have suggested more than a few times to vendors that the command: show bgp ipv4 unicast 100.10.0.0/16 why-chosen Would be insanely useful. Yes, you can recreate the 7+ BGP decision steps in your mind by running a pile of show commands, but when you're trying to figure out several odd routes at the same time this is very hard to keep in your head and very labor intensive. The box knows why it chose the route, and should be able to show that to you. Of course most boxes can't show you outgoing BGP communities either. *sigh* Is it really too hard to ask to get a show bgp neighbor ... advertised that shows ALL of the attributes? -- 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: 826 bytes Desc: not available URL: From william.mccall at gmail.com Thu Sep 30 14:22:04 2010 From: william.mccall at gmail.com (William McCall) Date: Thu, 30 Sep 2010 09:22:04 -0500 Subject: RIP Justification In-Reply-To: <20100930180848.6659f769@opy.nosense.org> References: <035FE016D625174BA7C7A9FA83E6C17987147CE602@winexmp02> <20100930180848.6659f769@opy.nosense.org> Message-ID: On Thu, Sep 30, 2010 at 3:38 AM, Mark Smith wrote: > On Thu, 30 Sep 2010 01:15:45 -0500 > William McCall wrote: > >> On Wed, Sep 29, 2010 at 7:31 PM, Christopher Gatlin >> wrote: >> > Using BGP to exchange routes between these types of untrusted networks is >> > like using a sledgehammer to crack a nut. ?BGP was designed for unique AS's >> > to peer in large scale networks such as the internet. ?A far cry from >> > business partners exchanging dynamic routes for fault tolerance. >> >> But on the flipside, arguing that we're providing this business parter >> service with no sort of broadcast mechanism, does the complexity >> actually increase between a proper implementation of BGP versus >> properly implementing RIP for the same scenario? >> >> Consider this example: >> 2 business partners terminating on the same device, we are advertising >> 1 prefix to both and receiving 1 prefix from each. Each has redundant >> connections to another router. >> >> Goals: >> 1) Prevent BP A from advertising routes owned by BP B and vice-versa >> 2) Advertise only the single prefix to the BPs >> 3) No broadcast medium, so we'll need neighbor statements >> 4) Prefix advertised to peers originates from IGP >> >> Mentally configuring this (in cisco terms), it seems about the same in >> terms of config complexity. Filtering the prefixes from each of the >> neighbors is required and the ACL to do this looks kind of nasty in >> RIP. Also, you'll need to redistribute from the IGP and add either an >> egress distribute list or a route map on the redistribution into RIP. >> Finally, redistribute back into the IGP for the received prefixes. >> >> BGP gives a slightly nicer-looking policy with a route map for each of >> the neighbors and policy building features that make scaling the >> solution slightly easier since route-maps can be reused and attached >> to the neighbor through whatever mechanism you want. And no >> funky-looking ACLs to describe how to accept prefixes and no need to >> redistribute from the IGP. Also, if choosing to run iBGP between >> redundant nodes, its quite a bit more simplified to set metrics to >> determine primary and redundant paths since this can be done on the >> same ingress policy. >> >> >> On Wed, Sep 29, 2010 at 10:19 PM, Chris Woodfield wrote: >> > (or, ghod forbid, multiple OSPF processes redistributing between each other...) >> > >> I think I have an anxiety disorder from this sort of "design".. >> >> On Wed, Sep 29, 2010 at 11:29 PM, Mark Smith >> wrote: >> > How do you prevent those business partners spoofing specific >> > route announcements within the RIP update, intentionally or otherwise, >> > such as a default route, causing either outages or attracting traffic >> > towards their networks that shouldn't be? >> >> Ingress filtering for prefixes can be performed with RIP. It just >> looks really funky compared to route maps for neighbors in BGP. >> > > The best place to configure the prefix filtering would be on admission > to the routing domain, rather than on exit. To achieve any sort of > accurate route filtering in a RIP environment you'd have to ?maintain > ingress route filters on all of the business partner routers. That'd be > much harder to maintain accurately due to the number of business > partner routers than a single per-business customer inbound route filter > on a couple of BGP Route Reflectors/Servers. > > Those business customers may not trust you to operate their routers, so > your routing accuracy is dependent on how well administered those > business partner routers are maintained, which is likely to be very > inconsistently. If you were operating the business peering exchange as a > paid third party, and were providing SLAs for the service, then you > wouldn't be in control of something that is essential to maintaining > the quality and availability of the service. > Agreed, but rarely is this option presented. For this reason, the operator must still protect the network from other's misconfiguration, etc. >> > [...] I don't worry to much about the specific >> > scenarios the tool was designed for - if the chosen tool provides the >> > most appropriate and relevant benefits for an acceptable cost, >> > the original design scenario doesn't matter. >> >> True that BGP is generally better in most external routing instances. >> But there are other cost factors involved with doing BGP - fear and >> knowledge. A lot of less experienced folk out there are outright >> afraid of the concepts behind BGP and/or do not have the requisite >> skills to maintain it. > > Then they're not the right people to be operating this network because > they're not competent to. > > It sounds a bit like you're justifying people saying "I want to be paid > to be an expert in this field, but I don't want to actually be an > expert." I find this cop-out extremely irritating. You either know what > you're doing or you don't, and if you don't, you shouldn't be selling > yourself as somebody who does. > No no... True that it happens that "experts" are often not quite "experts", I am not a fan, but it is a reality of the business. Once upon a time, not long ago, I had a manager explain to me that our team must set up a business partner scenario with either: A) Static routes and IP SLA or B) RIP I told him BGP made more sense and he just said "It's too complicated, don't do it." Not like he had to support it (the senior engineers, who all knew BGP, had to support it regardless). Long story short, we did static routes and IP SLA because the BP would only do BGP or static routing. Anyway, as I indicated in the statement you quoted, I don't support bad design decisions and, as an extension, gross incompetence, but it is rife in most technical and professional fields. And still, even if that incompetent administrator attempted to implement RIP versus BGP for this scenario, they'd probably still screw it up. (As another recent example of professional incompetence outside of networks, consider a set of medical professionals attempting to give more morphine to a surgery patient when the patient had a heartbeat of around 40 BPM and telling said patient that they must be having a panic attack. Twice.) >> That shouldn't justify bad design decisions, >> but it often does. Plus, it could be postulated that proper >> implementation of RIP in the same scenario would be hindered by the >> lack of knowledge still. >> >> Also, it should be pointed out that there are security products and >> others that don't support BGP. In those instances, it might make some >> sense to choose RIP. Other limiting factors can include resource and >> feature availablity on the terminating device(s) (as addressed by >> others). >> > > Then you buy a cheap BGP speaking device e.g. a Cisco 800 to put in > front of it. Again, I don't disagree. In the proposals I have designed, it is usually some sort of termination router for the tunnel or attachment circuit and then a security device behind that somewhere where it makes sense. Management is sort of responsible though for making that happen and often enough they'd rather not, usually to save the relatively few dollars here and there and get a slightly larger bonus at the end of the year. Or the other approach is where the "security" team (firewall jockey and/or fear mongering CSO) has dictated that they handle termination of all of these circuits, etc and they HAVE to handle the BP routing (so even the hack known as eBGP multihop is not an option). The reason? "Security." > Regards, > Mark. > Often times, technical decisions are made into "business" decisions when they shouldn't be. Also, incompetence is common, if not promoted in a lot of these "business" decisions. If you haven't had to deal with this inside of your firm, then I really really want to ask you about a job with your firm. I'll relocate just about anywhere and I shower daily or more often as necessary. (This should not be construed as to say my current firm is run by incompetent folks, quite to the contrary is true). -- William McCall From job at instituut.net Thu Sep 30 15:15:06 2010 From: job at instituut.net (Job W. J. Snijders) Date: Thu, 30 Sep 2010 17:15:06 +0200 Subject: LISP Works - Re: Facebook Issues/Outage in Southeast? In-Reply-To: References: <20100923173347.1E6D67EA@resin06.mta.everyone.net> <1E9490CA-3AC3-43DD-AE46-051927DE4C86@instituut.net> Message-ID: Dear Cameron & everybody, On Wed, Sep 29, 2010 at 8:32 PM, Job W. J. Snijders wrote: >>> The fact that LISP does help in IPv6 Transition solutions (due to its >>> inherent AF agnostic design), is compelling. As you say, real end 2 end is >>> the goal - and LISP helps here, regardless of the AF. (you'll will still >>> want to do multi-homing in IPv6, and ingress TE, and mobility, etc.). Have you already joined the LISP Beta Network? All you need is a router that can run the LISP images (871, 1841, 2821, 7200 etc) It's completely open, and the guys behind lisp-support at external.cisco.com can hook you up for free, provide you with everything you need: beta image, a block of public ipv4/ipv6 space and configuration guides, although it's only about 10 lines of config. :-) You could use LISP at home, like I do, and get some hands on experience - enjoy the net behind LISP! http://lisp4.cisco.com/ provides more information. Kind regards, Job Snijders From jtk at cymru.com Thu Sep 30 15:53:57 2010 From: jtk at cymru.com (John Kristoff) Date: Thu, 30 Sep 2010 10:53:57 -0500 Subject: RIP Justification In-Reply-To: References: Message-ID: <20100930105357.0084eeb7@t61p> On Wed, 29 Sep 2010 13:20:48 -0700 Jesse Loggins wrote: > OSPF. It seems that many Network Engineers consider RIP an old > antiquated protocol that should be thrown in back of a closet "never > to be seen or heard from again". Some even preferred using a more > complex protocol like OSPF instead of RIP. I am of the opinion that Complexity depending on your perspective. The implementation might be more complicated to code, but by and large the major implementations after years of experience seem to be very stable now. If the physical topology and stability is increasingly "interesting", RIP may be a more complex protocol to use and troubleshoot than OSPF. In essence, dealing with loops and topology changes in RIP involves a set of incomplete and unsatisfactory hacks for more than the simplest of environments. > every protocol has its place, which seems to be contrary to some > engineers way of thinking. This leads to my question. What are your > views of when and where the RIP protocol is useful? Please excuse me > if this is the incorrect forum for such questions. As an implementation of distance vector, its at least useful as a teaching tool about routing theory, history and implementations. John From peter.hicks at poggs.co.uk Thu Sep 30 16:04:13 2010 From: peter.hicks at poggs.co.uk (Peter Hicks) Date: Thu, 30 Sep 2010 17:04:13 +0100 Subject: BGP next-hop In-Reply-To: <20100930140119.GA6643@ussenterprise.ufp.org> References: <20100930140119.GA6643@ussenterprise.ufp.org> Message-ID: <1285862653.30784.23.camel@angel> On Thu, 2010-09-30 at 07:01 -0700, Leo Bicknell wrote: > I have suggested more than a few times to vendors that the command: > > show bgp ipv4 unicast 100.10.0.0/16 why-chosen > > Would be insanely useful. +1 for that, in a similar manner to packet-tracer on ASAs. Peter From jack at crepinc.com Thu Sep 30 16:43:48 2010 From: jack at crepinc.com (Jack Carrozzo) Date: Thu, 30 Sep 2010 12:43:48 -0400 Subject: RIP Justification In-Reply-To: <20100930105357.0084eeb7@t61p> References: <20100930105357.0084eeb7@t61p> Message-ID: Dynamic routing is hard, let's go shopping. Seriously though, I can't think of a topology I've ever encountered where RIP would have made more sense than OSPF or BGP, or if you're really die-hard, IS-IS. Let it die... My $0.02, -Jack On Thu, Sep 30, 2010 at 11:53 AM, John Kristoff wrote: > On Wed, 29 Sep 2010 13:20:48 -0700 > Jesse Loggins wrote: > > > OSPF. It seems that many Network Engineers consider RIP an old > > antiquated protocol that should be thrown in back of a closet "never > > to be seen or heard from again". Some even preferred using a more > > complex protocol like OSPF instead of RIP. I am of the opinion that > > Complexity depending on your perspective. The implementation might be > more complicated to code, but by and large the major implementations > after years of experience seem to be very stable now. If the physical > topology and stability is increasingly "interesting", RIP may be a more > complex protocol to use and troubleshoot than OSPF. In essence, > dealing with loops and topology changes in RIP involves a set of > incomplete and unsatisfactory hacks for more than the simplest of > environments. > > > every protocol has its place, which seems to be contrary to some > > engineers way of thinking. This leads to my question. What are your > > views of when and where the RIP protocol is useful? Please excuse me > > if this is the incorrect forum for such questions. > > As an implementation of distance vector, its at least useful as a teaching > tool about routing theory, history and implementations. > > John > > From manavbhatia at gmail.com Thu Sep 30 16:53:22 2010 From: manavbhatia at gmail.com (Manav Bhatia) Date: Thu, 30 Sep 2010 22:23:22 +0530 Subject: OSPFv3 Authentication In-Reply-To: References: Message-ID: Hi, I received 12 responses for the query that i had put up. o 1 response stated that the provider was using IS-IS for IPv6 and not using any authentication. o 7 responses where OSPFv3 was being used without any authentication. o 2 responses where OSPFv3 is being used with authentication o 2 responses where they were using OSPFv2 with authentication turned on. I asked the 7 people who had replied in negative about why they were not using authentication with OSPFv3. 5 responded stating a mix of the following reasons: o IPsec not available on all platforms o IPsec required interoperability testing, which was perceived as a hassle o Troubleshooting becomes much harder. OSPF operation should be kept as simple as possible, especially when used in the core. o Complex configuration o Required coordination between different boxes which is a deterrent. o IPSec on some platforms requires a special license which can be expensive. o Unsure of how well is the IPsec implemented on the boxes Cheers, Manav On Tue, Sep 28, 2010 at 5:33 AM, Manav Bhatia wrote: > Hi, > > I am doing a survey and was interested in knowing if network operators > are using OSPFv3 with authentication [RFC 4552] turned on? I know that > most providers turn on authentication with OSPFv2, but given that > OSPFv3 needs IPsec integration and can thus get little cumbersome to > configure, wanted to understand if a similar % of folks also turn on > authentication for OSPFv3? > > You can unicast me your responses (if you dont wish to share it on the > list) and i will collate all data and post a summary on the list. > > Cheers, Manav > From glen.kent at gmail.com Thu Sep 30 16:59:46 2010 From: glen.kent at gmail.com (Glen Kent) Date: Thu, 30 Sep 2010 22:29:46 +0530 Subject: RIP Justification In-Reply-To: References: <20100930105357.0084eeb7@t61p> Message-ID: RIP cannot also be used for traffic engineering; so if you want MPLS then you MUST use either OSPF or ISIS. RIP, like any other distance vector protocol, converges extremely slowly - so if you want faster convergence then you have to use one of ISIS or OSPF. Glen From gbonser at seven.com Thu Sep 30 17:05:27 2010 From: gbonser at seven.com (George Bonser) Date: Thu, 30 Sep 2010 10:05:27 -0700 Subject: RIP Justification In-Reply-To: References: <20100930105357.0084eeb7@t61p> Message-ID: <5A6D953473350C4B9995546AFE9939EE0A52B03A@RWC-EX1.corp.seven.com> > -----Original Message----- > From: Jack Carrozzo > Sent: Thursday, September 30, 2010 9:44 AM > To: John Kristoff > Cc: nanog at nanog.org > Subject: Re: RIP Justification > > Dynamic routing is hard, let's go shopping. > > Seriously though, I can't think of a topology I've ever encountered > where > RIP would have made more sense than OSPF or BGP, or if you're really > die-hard, IS-IS. Let it die... > > My $0.02, > > -Jack The one and only place I have used RIPv2 and RIPng is for distributing igp information on links between BGP routers. Say I have a cluster of such routers with some /30 links (for IPv4) to transit, peers and each other. Basically I run RIP with "redistribute connected" on them and only running on the internal interfaces connecting the routers. All RIP is doing at that point is providing an igp path to the BGP next hop. There is really no need to run OSPF for that and frankly I don't WANT OSPF running there for other reasons. From brokenflea at gmail.com Thu Sep 30 17:32:00 2010 From: brokenflea at gmail.com (Khurram Khan) Date: Thu, 30 Sep 2010 11:32:00 -0600 Subject: L3 Issues this Morning? Message-ID: Hello All, This is my first time writing to this list and wanted to check if anyone experienced issues with L3 circuits between 12:50 ET and 13:05 ET. All our core backbone circuits re-converged and we saw a significant drop in traffic. Regards, Khurram From brokenflea at gmail.com Thu Sep 30 17:39:09 2010 From: brokenflea at gmail.com (Khurram Khan) Date: Thu, 30 Sep 2010 11:39:09 -0600 Subject: L3 Issues this Morning? In-Reply-To: <9FAB2254-CA63-4A1F-84EA-84C3B7918065@smithwaysecurity.com> References: <9FAB2254-CA63-4A1F-84EA-84C3B7918065@smithwaysecurity.com> Message-ID: Learn something new everyday, that's awesome. We've got several data centers between San Diego, Denver, Tulsa, Chicago, Washington DC. All of the circuit's between those POP's , and all are L3, just dropped traffic. On Thu, Sep 30, 2010 at 11:35 AM, James Smith wrote: > None Down here in Canada > > Sent from my iPhone > > On Sep 30, 2010, at 2:32 PM, Khurram Khan wrote: > >> Hello All, >> >> This is my first time writing to this list and wanted to check if >> anyone experienced issues with L3 circuits between 12:50 ET and 13:05 >> ET. All our core backbone circuits re-converged and we saw a >> significant drop in traffic. >> >> Regards, >> >> Khurram >> > -- Please use the following public key for encrypted transport. ??BEGIN PGP SIGNATURE?? Version: GnuPG v1.4.7 (GNU/Linux) iD8DBQFGZO+K6ECuipL6LVERAjSvAJsFslrQU61la+yCqD2bfDSW/OGKigCg0QOK LQTWZQDmFma6eh7onZfi99A= =LlU0 ??END PGP SIGNATURE?? From neal.rauhauser at gmail.com Thu Sep 30 17:44:08 2010 From: neal.rauhauser at gmail.com (Neal Rauhauser) Date: Thu, 30 Sep 2010 12:44:08 -0500 Subject: Cogent security contact for non-BGP issue? Message-ID: Can someone from Cogent responsible for security contact me? I'm seeing some troubles that appear to originate within Cogent itself. What I am seeing does not effect global BGP at all, it's some other area. Thanks in advance ... From job at instituut.net Thu Sep 30 18:28:36 2010 From: job at instituut.net (Job W. J. Snijders) Date: Thu, 30 Sep 2010 20:28:36 +0200 Subject: LISP Works - Re: Facebook Issues/Outage in Southeast? In-Reply-To: References: <20100923173347.1E6D67EA@resin06.mta.everyone.net> <1E9490CA-3AC3-43DD-AE46-051927DE4C86@instituut.net> Message-ID: Sorry guys, > Have you already joined the LISP Beta Network? All you need is a > router that can run the LISP images (871, 1841, 2821, 7200 etc) > > It's completely open, and the guys behind > lisp-support at external.cisco.com can hook you up for free, The correct address is lisp-support at cisco.com Kind regards, Job From tme at americafree.tv Thu Sep 30 18:37:26 2010 From: tme at americafree.tv (Marshall Eubanks) Date: Thu, 30 Sep 2010 14:37:26 -0400 Subject: RIP Justification In-Reply-To: References: <20100930105357.0084eeb7@t61p> Message-ID: <8405B6DB-4DBF-400D-BA60-6EBEAFB37DCA@americafree.tv> On Sep 30, 2010, at 12:43 PM, Jack Carrozzo wrote: > Dynamic routing is hard, let's go shopping. > > Seriously though, I can't think of a topology I've ever encountered where > RIP would have made more sense than OSPF or BGP, or if you're really > die-hard, IS-IS. Let it die... But what about all of those students even now working on getting their Lab RIP routing to work ? Surely such a huge crowd-sourcing will solve any remaining problems with the protocol by the end of the term! Regards Marshall > > My $0.02, > > -Jack > > On Thu, Sep 30, 2010 at 11:53 AM, John Kristoff wrote: > >> On Wed, 29 Sep 2010 13:20:48 -0700 >> Jesse Loggins wrote: >> >>> OSPF. It seems that many Network Engineers consider RIP an old >>> antiquated protocol that should be thrown in back of a closet "never >>> to be seen or heard from again". Some even preferred using a more >>> complex protocol like OSPF instead of RIP. I am of the opinion that >> >> Complexity depending on your perspective. The implementation might be >> more complicated to code, but by and large the major implementations >> after years of experience seem to be very stable now. If the physical >> topology and stability is increasingly "interesting", RIP may be a more >> complex protocol to use and troubleshoot than OSPF. In essence, >> dealing with loops and topology changes in RIP involves a set of >> incomplete and unsatisfactory hacks for more than the simplest of >> environments. >> >>> every protocol has its place, which seems to be contrary to some >>> engineers way of thinking. This leads to my question. What are your >>> views of when and where the RIP protocol is useful? Please excuse me >>> if this is the incorrect forum for such questions. >> >> As an implementation of distance vector, its at least useful as a teaching >> tool about routing theory, history and implementations. >> >> John >> >> > From jack at crepinc.com Thu Sep 30 18:39:17 2010 From: jack at crepinc.com (Jack Carrozzo) Date: Thu, 30 Sep 2010 14:39:17 -0400 Subject: RIP Justification In-Reply-To: <8405B6DB-4DBF-400D-BA60-6EBEAFB37DCA@americafree.tv> References: <20100930105357.0084eeb7@t61p> <8405B6DB-4DBF-400D-BA60-6EBEAFB37DCA@americafree.tv> Message-ID: Yes, clearly the next crowd of CCNAs will save the world. You know what they say about giving CCNAs enable... -Jack On Thu, Sep 30, 2010 at 2:37 PM, Marshall Eubanks wrote: > > On Sep 30, 2010, at 12:43 PM, Jack Carrozzo wrote: > > > Dynamic routing is hard, let's go shopping. > > > > Seriously though, I can't think of a topology I've ever encountered where > > RIP would have made more sense than OSPF or BGP, or if you're really > > die-hard, IS-IS. Let it die... > > But what about all of those students even now working on getting their Lab > RIP routing to work ? > Surely such a huge crowd-sourcing will solve any remaining problems with > the protocol by the end of the term! > > Regards > Marshall > > > > > My $0.02, > > > > -Jack > > > > On Thu, Sep 30, 2010 at 11:53 AM, John Kristoff wrote: > > > >> On Wed, 29 Sep 2010 13:20:48 -0700 > >> Jesse Loggins wrote: > >> > >>> OSPF. It seems that many Network Engineers consider RIP an old > >>> antiquated protocol that should be thrown in back of a closet "never > >>> to be seen or heard from again". Some even preferred using a more > >>> complex protocol like OSPF instead of RIP. I am of the opinion that > >> > >> Complexity depending on your perspective. The implementation might be > >> more complicated to code, but by and large the major implementations > >> after years of experience seem to be very stable now. If the physical > >> topology and stability is increasingly "interesting", RIP may be a more > >> complex protocol to use and troubleshoot than OSPF. In essence, > >> dealing with loops and topology changes in RIP involves a set of > >> incomplete and unsatisfactory hacks for more than the simplest of > >> environments. > >> > >>> every protocol has its place, which seems to be contrary to some > >>> engineers way of thinking. This leads to my question. What are your > >>> views of when and where the RIP protocol is useful? Please excuse me > >>> if this is the incorrect forum for such questions. > >> > >> As an implementation of distance vector, its at least useful as a > teaching > >> tool about routing theory, history and implementations. > >> > >> John > >> > >> > > > > From zaid at zaidali.com Thu Sep 30 18:39:58 2010 From: zaid at zaidali.com (Zaid Ali) Date: Thu, 30 Sep 2010 11:39:58 -0700 Subject: L3 Issues this Morning? In-Reply-To: Message-ID: Not sure if this is related but my Level 3 BGP peer went down at 3:33:57 GMT for just over 6 hours. This was in the San Jose/Santa Clara area. Their reason was an OSPF problem. Zaid On 9/30/10 10:39 AM, "Khurram Khan" wrote: > Learn something new everyday, that's awesome. We've got several data > centers between San Diego, Denver, Tulsa, Chicago, Washington DC. All > of the circuit's between those POP's , and all are L3, just dropped > traffic. > > On Thu, Sep 30, 2010 at 11:35 AM, James Smith > wrote: >> None Down here in Canada >> >> Sent from my iPhone >> >> On Sep 30, 2010, at 2:32 PM, Khurram Khan wrote: >> >>> Hello All, >>> >>> This is my first time writing to this list and wanted to check if >>> anyone experienced issues with L3 circuits between 12:50 ET and 13:05 >>> ET. All our core backbone circuits re-converged and we saw a >>> significant drop in traffic. >>> >>> Regards, >>> >>> Khurram >>> >> > > From tonyb at go-concepts.com Thu Sep 30 20:02:36 2010 From: tonyb at go-concepts.com (Tony Bunce) Date: Thu, 30 Sep 2010 20:02:36 +0000 Subject: Frontier DSL Contact Message-ID: <38C452D903F47349B03EC558C5863D98691E2D@EXCH2010.gont> Can someone from Frontier DSL (formally Verizon) please contact me off list? It appears Frontier DSL customers (at least in Ohio) can't access websites that we host. I have tried contacting the ISIS NOC, the Ohio NOC and the MCO and they were unable to assist. Or if there is anyone on the list using Frontier DSL if they could send me a traceroute to 208.2.209.110 and/or 208.2.213.96 that might also help me track down the issue. Thanks, Tony -------------------------------------------------------------------------- Tony Bunce: tonyb at go-concepts.com Sr. Programming Systems Administrator - GO Concepts Inc. From nathan at atlasnetworks.us Thu Sep 30 20:16:10 2010 From: nathan at atlasnetworks.us (Nathan Eisenberg) Date: Thu, 30 Sep 2010 20:16:10 +0000 Subject: RIP Justification In-Reply-To: References: <20100930105357.0084eeb7@t61p> Message-ID: <8C26A4FDAE599041A13EB499117D3C28405FE046@ex-mb-2.corp.atlasnetworks.us> > Seriously though, I can't think of a topology I've ever encountered where RIP > would have made more sense than OSPF or BGP, or if you're really die-hard, > IS-IS. Let it die... I was just curious - why would IS-IS be more die-hard than OSPF or iBGP? Best Regards, Nathan Eisenberg From jack at crepinc.com Thu Sep 30 20:32:12 2010 From: jack at crepinc.com (Jack Carrozzo) Date: Thu, 30 Sep 2010 16:32:12 -0400 Subject: RIP Justification In-Reply-To: <8C26A4FDAE599041A13EB499117D3C28405FE046@ex-mb-2.corp.atlasnetworks.us> References: <20100930105357.0084eeb7@t61p> <8C26A4FDAE599041A13EB499117D3C28405FE046@ex-mb-2.corp.atlasnetworks.us> Message-ID: > > I was just curious - why would IS-IS be more die-hard than OSPF or iBGP? > It's like running apps on Solaris and Oracle these days instead of Linux and MySQL. Both options work if you know what you're doing, but it's way easier (and cheaper) to hire admins for the latter. When was the last time you ran into a younger neteng designing his topology who went "Yes! IS-IS!"? It works fine (very well in fact) but it's just less used. I know there are a lot of guys on here using IS-IS and I'm certainly not knocking it... -Jack From swm at emanon.com Thu Sep 30 20:44:48 2010 From: swm at emanon.com (Scott Morris) Date: Thu, 30 Sep 2010 16:44:48 -0400 Subject: RIP Justification In-Reply-To: References: <20100930105357.0084eeb7@t61p> Message-ID: <4CA4F6C0.2080704@emanon.com> Maybe I WAY under-read the initial poster's question, but I was pretty sure he wasn't talking about running it as a CORE routing protocol or anything on the middle of their network where MPLS would be expected on top of it! If I missed it and he did intend that, then I'd certainly agree with you (among many other reasons why it would be a horrible idea)! ;) Scott On 9/30/10 12:59 PM, Glen Kent wrote: > RIP cannot also be used for traffic engineering; so if you want MPLS > then you MUST use either OSPF or ISIS. RIP, like any other distance > vector protocol, converges extremely slowly - so if you want faster > convergence then you have to use one of ISIS or OSPF. > > Glen > > > From brandon.galbraith at gmail.com Thu Sep 30 20:52:57 2010 From: brandon.galbraith at gmail.com (Brandon Galbraith) Date: Thu, 30 Sep 2010 15:52:57 -0500 Subject: AT&T Dry Pairs? Message-ID: Has anyone had any luck lately getting dry pairs from AT&T? I'm in the Chicago area attempting to get a dry pair between two buildings (100ft apart) for some equipment, but when speaking to several folks at AT&T the response I get is "You want AT&T service without the service? That's not logical!". Had no problems 3-4 years ago getting these sorts of "circuits", but it appears it's gone the way of the dodo now. Any emails off-list are appreciated. -- Brandon Galbraith US Voice: 630.492.0464 From jbates at brightok.net Thu Sep 30 20:58:21 2010 From: jbates at brightok.net (Jack Bates) Date: Thu, 30 Sep 2010 15:58:21 -0500 Subject: RIP Justification In-Reply-To: References: <20100930105357.0084eeb7@t61p> <8C26A4FDAE599041A13EB499117D3C28405FE046@ex-mb-2.corp.atlasnetworks.us> Message-ID: <4CA4F9ED.1000007@brightok.net> On 9/30/2010 3:32 PM, Jack Carrozzo wrote: > When was the last time you ran into a younger neteng designing his topology > who went "Yes! IS-IS!"? It works fine (very well in fact) but it's just less > used. Which makes no sense to me. I originally looked at both and thought OSPF to be inferior to IS-IS. That being said, OSPF is supported on more (and cheaper) hardware. IS-IS can have additional licensing with some hardware (where OSPF does not) and is often considered a "service provider" protocol by vendors. Jack From jack at crepinc.com Thu Sep 30 21:11:40 2010 From: jack at crepinc.com (Jack Carrozzo) Date: Thu, 30 Sep 2010 17:11:40 -0400 Subject: RIP Justification In-Reply-To: <4CA4F9ED.1000007@brightok.net> References: <20100930105357.0084eeb7@t61p> <8C26A4FDAE599041A13EB499117D3C28405FE046@ex-mb-2.corp.atlasnetworks.us> <4CA4F9ED.1000007@brightok.net> Message-ID: As it was explained to me, the main difference is that you can have $lots of prefixes in IS-IS without it falling over, whereas Dijkstra is far more resource-intensive and as such OSPF doesn't get too happy after $a_lot_less prefixes. Those numbers can be debated as you like, but I think if you were to redist bgp ospf on a lab machine you'd get the point. Disclaimer: I've never run IS-IS operationally, just in the lab. -Jack > Which makes no sense to me. I originally looked at both and thought OSPF to > be inferior to IS-IS. That being said, OSPF is supported on more (and > cheaper) hardware. IS-IS can have additional licensing with some hardware > (where OSPF does not) and is often considered a "service provider" protocol > by vendors. > > > Jack > From ryanshea at google.com Thu Sep 30 21:20:52 2010 From: ryanshea at google.com (Ryan Shea) Date: Thu, 30 Sep 2010 17:20:52 -0400 Subject: AT&T Dry Pairs? In-Reply-To: References: Message-ID: Years ago I managed to get a dry pair from Verizon for some homebrew DSL, but there was some telco specific term for the dry pair, like "series 7 alarm circuit" or something. AT&T may have their own term. -Ryan On Thu, Sep 30, 2010 at 4:52 PM, Brandon Galbraith < brandon.galbraith at gmail.com> wrote: > Has anyone had any luck lately getting dry pairs from AT&T? I'm in the > Chicago area attempting to get a dry pair between two buildings (100ft > apart) for some equipment, but when speaking to several folks at AT&T the > response I get is "You want AT&T service without the service? That's not > logical!". Had no problems 3-4 years ago getting these sorts of "circuits", > but it appears it's gone the way of the dodo now. Any emails off-list are > appreciated. > > -- > Brandon Galbraith > US Voice: 630.492.0464 > From gbonser at seven.com Thu Sep 30 21:30:22 2010 From: gbonser at seven.com (George Bonser) Date: Thu, 30 Sep 2010 14:30:22 -0700 Subject: AT&T Dry Pairs? In-Reply-To: References: Message-ID: <5A6D953473350C4B9995546AFE9939EE0A52B04C@RWC-EX1.corp.seven.com> > -----Original Message----- > From: Ryan Shea > Sent: Thursday, September 30, 2010 2:21 PM > To: Brandon Galbraith > Cc: nanog at nanog.org > Subject: Re: AT&T Dry Pairs? > > Years ago I managed to get a dry pair from Verizon for some homebrew > DSL, > but there was some telco specific term for the dry pair, like "series 7 > alarm circuit" or something. AT&T may have their own term. > > -Ryan > Just plain "alarm circuit" works in most cases but it has been a while here as well. From randy at psg.com Thu Sep 30 21:37:43 2010 From: randy at psg.com (Randy Bush) Date: Fri, 01 Oct 2010 06:37:43 +0900 Subject: BGP next-hop In-Reply-To: <1285862653.30784.23.camel@angel> References: <20100930140119.GA6643@ussenterprise.ufp.org> <1285862653.30784.23.camel@angel> Message-ID: i was recently bitten by a cousin of this research router getting an ebgp multi-hop full feed from 147.28.0.1 (address is relevant) it is on a lan with a default gateway 42.666.77.11 (address not relevant), so it has ip route 0.0.0.0 0.0.0.0 42.666.77.11 massive flapping results. it seems it gets the bgp route for 147.28.0.0/16 and then can not resolve the next hop. it would not recurse to the default exit. of course it was solved by ip route 147.28.0.0 255.255.0.0 42.666.77.11 but i do not really understand in my heart why i needed to do this. randy From franck at genius.com Thu Sep 30 22:00:08 2010 From: franck at genius.com (Franck Martin) Date: Thu, 30 Sep 2010 15:00:08 -0700 (PDT) Subject: BGP next-hop In-Reply-To: Message-ID: <21751668.592.1285884004620.JavaMail.franck@linko-biatch-6.genius.local> Because the path was broken everytime the bgp session was established and rewriting the routing table with more specific routes? ----- Original Message ----- From: "Randy Bush" To: "North American Network Operators Group" Sent: Thursday, 30 September, 2010 2:37:43 PM Subject: Re: BGP next-hop i was recently bitten by a cousin of this research router getting an ebgp multi-hop full feed from 147.28.0.1 (address is relevant) it is on a lan with a default gateway 42.666.77.11 (address not relevant), so it has ip route 0.0.0.0 0.0.0.0 42.666.77.11 massive flapping results. it seems it gets the bgp route for 147.28.0.0/16 and then can not resolve the next hop. it would not recurse to the default exit. of course it was solved by ip route 147.28.0.0 255.255.0.0 42.666.77.11 but i do not really understand in my heart why i needed to do this. randy From if at xip.at Thu Sep 30 22:01:10 2010 From: if at xip.at (Ingo Flaschberger) Date: Fri, 1 Oct 2010 00:01:10 +0200 (CEST) Subject: BGP next-hop In-Reply-To: References: <20100930140119.GA6643@ussenterprise.ufp.org> <1285862653.30784.23.camel@angel> Message-ID: > i was recently bitten by a cousin of this > > research router getting an ebgp multi-hop full feed from 147.28.0.1 > (address is relevant) > > it is on a lan with a default gateway 42.666.77.11 (address not > relevant), so it has > > ip route 0.0.0.0 0.0.0.0 42.666.77.11 > > massive flapping results. > > it seems it gets the bgp route for 147.28.0.0/16 and then can not > resolve the next hop. it would not recurse to the default exit. > > of course it was solved by > > ip route 147.28.0.0 255.255.0.0 42.666.77.11 > > but i do not really understand in my heart why i needed to do this. last time severall years ago on cisco I used a route-map to rewrite the next-hop. route-map xx-in permit 10 set ip next-hop 42.666.77.11 route-map xx-out permit 10 set ip next-hop x.x.x.x neighbor 147.28.0.1 remote-as yyy neighbor 147.28.0.1 ebgp-multihop 8 neighbor 147.28.0.1 route-map xx-in in neighbor 147.28.0.1 route-map xx-out out something like this. From fasterfourier at gmail.com Thu Sep 30 22:08:24 2010 From: fasterfourier at gmail.com (Robert Johnson) Date: Thu, 30 Sep 2010 18:08:24 -0400 Subject: AT&T Dry Pairs? In-Reply-To: References: Message-ID: If your sales contact don't know what an alarm circuit is, go find AT&T's tariff filed with your state's PUC. It will contain the name of the service. This will take some digging... Verizon Maryland calls this an "Intraexchange local channel, regular voice grade" and they go for $15.53/month. There are a plethora of different types of "dry pairs" that you can order depending on the signal bandwidth of the circuit and allowed attenuation. On Thu, Sep 30, 2010 at 4:52 PM, Brandon Galbraith < brandon.galbraith at gmail.com> wrote: > Has anyone had any luck lately getting dry pairs from AT&T? I'm in the > Chicago area attempting to get a dry pair between two buildings (100ft > apart) for some equipment, but when speaking to several folks at AT&T the > response I get is "You want AT&T service without the service? That's not > logical!". Had no problems 3-4 years ago getting these sorts of "circuits", > but it appears it's gone the way of the dodo now. Any emails off-list are > appreciated. > > -- > Brandon Galbraith > US Voice: 630.492.0464 > From bclark at spectraaccess.com Thu Sep 30 22:12:47 2010 From: bclark at spectraaccess.com (Bret Clark) Date: Thu, 30 Sep 2010 18:12:47 -0400 Subject: AT&T Dry Pairs? In-Reply-To: References: Message-ID: <4CA50B5F.2070101@spectraaccess.com> If the buildings are a 100ft apart, can't you just go with a wireless connection? Speeds would probably be better and no monthly fee! On 09/30/2010 06:08 PM, Robert Johnson wrote: > If your sales contact don't know what an alarm circuit is, go find > AT&T's tariff filed with your state's PUC. It will contain the name of the > service. This will take some digging... > > Verizon Maryland calls this an "Intraexchange local channel, regular voice > grade" and they go for $15.53/month. There are a plethora of different types > of "dry pairs" that you can order depending on the signal bandwidth of the > circuit and allowed attenuation. > > On Thu, Sep 30, 2010 at 4:52 PM, Brandon Galbraith< > brandon.galbraith at gmail.com> wrote: > > >> Has anyone had any luck lately getting dry pairs from AT&T? I'm in the >> Chicago area attempting to get a dry pair between two buildings (100ft >> apart) for some equipment, but when speaking to several folks at AT&T the >> response I get is "You want AT&T service without the service? That's not >> logical!". Had no problems 3-4 years ago getting these sorts of "circuits", >> but it appears it's gone the way of the dodo now. Any emails off-list are >> appreciated. >> >> -- >> Brandon Galbraith >> US Voice: 630.492.0464 >> >> From randy at psg.com Thu Sep 30 22:20:09 2010 From: randy at psg.com (Randy Bush) Date: Fri, 01 Oct 2010 07:20:09 +0900 Subject: BGP next-hop In-Reply-To: References: <20100930140119.GA6643@ussenterprise.ufp.org> <1285862653.30784.23.camel@angel> Message-ID: > last time severall years ago on cisco I used a route-map to rewrite the > next-hop. > route-map xx-in permit 10 > set ip next-hop 42.666.77.11 > route-map xx-out permit 10 > set ip next-hop x.x.x.x > > neighbor 147.28.0.1 remote-as yyy > neighbor 147.28.0.1 ebgp-multihop 8 > neighbor 147.28.0.1 route-map xx-in in > neighbor 147.28.0.1 route-map xx-out out > > something like this. as i showed, i knew how to hack out of the problem. and yes, there are many ways. the question is why i am in the corner in the first place. randy From sethm at rollernet.us Thu Sep 30 22:30:13 2010 From: sethm at rollernet.us (Seth Mattinen) Date: Thu, 30 Sep 2010 15:30:13 -0700 Subject: AT&T Dry Pairs? In-Reply-To: <4CA50B5F.2070101@spectraaccess.com> References: <4CA50B5F.2070101@spectraaccess.com> Message-ID: <4CA50F75.9090305@rollernet.us> On 9/30/2010 15:12, Bret Clark wrote: > If the buildings are a 100ft apart, can't you just go with a wireless > connection? Speeds would probably be better and no monthly fee! > Wireless is not the end all solution for everything. ~Seth From jared at puck.nether.net Thu Sep 30 22:34:10 2010 From: jared at puck.nether.net (Jared Mauch) Date: Thu, 30 Sep 2010 18:34:10 -0400 Subject: AT&T Dry Pairs? In-Reply-To: <4CA50F75.9090305@rollernet.us> References: <4CA50B5F.2070101@spectraaccess.com> <4CA50F75.9090305@rollernet.us> Message-ID: <1C9BB008-F3DD-42D2-8E2F-980ECB7317C2@puck.nether.net> On Sep 30, 2010, at 6:30 PM, Seth Mattinen wrote: > On 9/30/2010 15:12, Bret Clark wrote: >> If the buildings are a 100ft apart, can't you just go with a wireless >> connection? Speeds would probably be better and no monthly fee! >> > > Wireless is not the end all solution for everything. Understood, but for $160 you can get equipment that acts as a L2 bridge with RJ45 and PoE at 50Mb/s duplex. (UBNT Nanobridge 5, they're $79 per and do 5Ghz 802.11n MCS-15 @ 40Mhz channels). Just trying to help :) You may now shoot the off-topic messenger. - Jared From jfbeam at gmail.com Thu Sep 30 22:37:19 2010 From: jfbeam at gmail.com (Ricky Beam) Date: Thu, 30 Sep 2010 18:37:19 -0400 Subject: AT&T Dry Pairs? In-Reply-To: References: Message-ID: On Thu, 30 Sep 2010 17:20:52 -0400, Ryan Shea wrote: > AT&T may have their own term. The industry standard term is "UNE" (unbundled network element.) However, the sales drones may not recognize that either. --Ricky From jfbeam at gmail.com Thu Sep 30 22:37:19 2010 From: jfbeam at gmail.com (Ricky Beam) Date: Thu, 30 Sep 2010 18:37:19 -0400 Subject: AT&T Dry Pairs? In-Reply-To: References: Message-ID: On Thu, 30 Sep 2010 17:20:52 -0400, Ryan Shea wrote: > AT&T may have their own term. The industry standard term is "UNE" (unbundled network element.) However, the sales drones may not recognize that either. --Ricky From jfbeam at gmail.com Thu Sep 30 22:37:19 2010 From: jfbeam at gmail.com (Ricky Beam) Date: Thu, 30 Sep 2010 18:37:19 -0400 Subject: AT&T Dry Pairs? In-Reply-To: References: Message-ID: On Thu, 30 Sep 2010 17:20:52 -0400, Ryan Shea wrote: > AT&T may have their own term. The industry standard term is "UNE" (unbundled network element.) However, the sales drones may not recognize that either. --Ricky From ras at e-gerbil.net Thu Sep 30 22:44:10 2010 From: ras at e-gerbil.net (Richard A Steenbergen) Date: Thu, 30 Sep 2010 17:44:10 -0500 Subject: BGP next-hop In-Reply-To: <20100930140119.GA6643@ussenterprise.ufp.org> References: <20100930140119.GA6643@ussenterprise.ufp.org> Message-ID: <20100930224410.GC1946@gerbil.cluepon.net> On Thu, Sep 30, 2010 at 07:01:19AM -0700, Leo Bicknell wrote: > I have suggested more than a few times to vendors that the command: > > show bgp ipv4 unicast 100.10.0.0/16 why-chosen > > Would be insanely useful. Been in JUNOS "show route" since day one, and IMHO is easily in the top 10 list of why I still buy Juniper instead of Cisco despite all the $%^&*ing bugs these days. -- Richard A Steenbergen http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) From sethm at rollernet.us Thu Sep 30 22:46:29 2010 From: sethm at rollernet.us (Seth Mattinen) Date: Thu, 30 Sep 2010 15:46:29 -0700 Subject: AT&T Dry Pairs? In-Reply-To: <1C9BB008-F3DD-42D2-8E2F-980ECB7317C2@puck.nether.net> References: <4CA50B5F.2070101@spectraaccess.com> <4CA50F75.9090305@rollernet.us> <1C9BB008-F3DD-42D2-8E2F-980ECB7317C2@puck.nether.net> Message-ID: <4CA51345.8080601@rollernet.us> On 9/30/2010 15:34, Jared Mauch wrote: > > On Sep 30, 2010, at 6:30 PM, Seth Mattinen wrote: > >> On 9/30/2010 15:12, Bret Clark wrote: >>> If the buildings are a 100ft apart, can't you just go with a wireless >>> connection? Speeds would probably be better and no monthly fee! >>> >> >> Wireless is not the end all solution for everything. > > Understood, but for $160 you can get equipment that acts as a L2 bridge with RJ45 and PoE at 50Mb/s duplex. (UBNT Nanobridge 5, they're $79 per and do 5Ghz 802.11n MCS-15 @ 40Mhz channels). > > Just trying to help :) > The biggest laugh I always got when I worked at the local university as a student were trouble tickets to the Faraday cage rooms because the campus wireless internet didn't work inside them. "But it's wireless!" "Yes, that's the problem. Please just use the damn cable." ~Seth From hj1980 at gmail.com Thu Sep 30 22:47:46 2010 From: hj1980 at gmail.com (Heath Jones) Date: Thu, 30 Sep 2010 23:47:46 +0100 Subject: RIP Justification In-Reply-To: References: <20100930105357.0084eeb7@t61p> <8C26A4FDAE599041A13EB499117D3C28405FE046@ex-mb-2.corp.atlasnetworks.us> <4CA4F9ED.1000007@brightok.net> Message-ID: On 30 September 2010 22:11, Jack Carrozzo wrote: > As it was explained to me, the main difference is that you can have $lots of > prefixes in IS-IS without it falling over, whereas Dijkstra is far more > resource-intensive and as such OSPF doesn't get too happy after $a_lot_less > prefixes. Those numbers can be debated as you like, but I think if you were > to redist bgp ospf on a lab machine you'd get the point. Both OSPF and IS-IS use Dijkstra. IS-IS isn't as widely used because of the ISO addressing. Atleast thats my take on it.. RIPv2 is great for simple route injection. I'm talking really simple, just to avoid statics. From jack at crepinc.com Thu Sep 30 22:50:55 2010 From: jack at crepinc.com (Jack Carrozzo) Date: Thu, 30 Sep 2010 18:50:55 -0400 Subject: RIP Justification In-Reply-To: References: <20100930105357.0084eeb7@t61p> <8C26A4FDAE599041A13EB499117D3C28405FE046@ex-mb-2.corp.atlasnetworks.us> <4CA4F9ED.1000007@brightok.net> Message-ID: > Both OSPF and IS-IS use Dijkstra. IS-IS isn't as widely used because > of the ISO addressing. Atleast thats my take on it.. Sorry, my mistake. I'll go sit in my corner now... -Jack From hj1980 at gmail.com Thu Sep 30 22:56:06 2010 From: hj1980 at gmail.com (Heath Jones) Date: Thu, 30 Sep 2010 23:56:06 +0100 Subject: BGP next-hop In-Reply-To: <20100930224410.GC1946@gerbil.cluepon.net> References: <20100930140119.GA6643@ussenterprise.ufp.org> <20100930224410.GC1946@gerbil.cluepon.net> Message-ID: >> show bgp ipv4 unicast 100.10.0.0/16 why-chosen >> Would be insanely useful. > Been in JUNOS "show route" since day one, and IMHO is easily in the top > 10 list of why I still buy Juniper instead of Cisco despite all the > $%^&*ing bugs these days. Its interesting, I was heavy into cisco years back and then juniper for a while. Going back to cisco now is great (always good for me to keep my exposure up), but there is just so much unclear in it's CLI. It wasn't until going back that I realised. I guess they would have to balance keeping the old timers & scripts etc happy VS bringing in new features that make the output look different.. Do you keep something that isn't perfect but people know how to use, or change it and cause more issues than good? ps. Juniper has really gone to $h!t lately. There's a website called glassdoor.com that I found - go look up what employees have to say about it.. reflects exactly the support we were getting, even as as an 'elite' partner.. From hj1980 at gmail.com Thu Sep 30 23:06:22 2010 From: hj1980 at gmail.com (Heath Jones) Date: Fri, 1 Oct 2010 00:06:22 +0100 Subject: RIP Justification In-Reply-To: References: <20100930105357.0084eeb7@t61p> <8C26A4FDAE599041A13EB499117D3C28405FE046@ex-mb-2.corp.atlasnetworks.us> <4CA4F9ED.1000007@brightok.net> Message-ID: Haha It's all good :) You are right about IS-IS being less resource intensive than OSPF, and that it scales better! On 30 September 2010 23:50, Jack Carrozzo wrote: > >> >> Both OSPF and IS-IS use Dijkstra. IS-IS isn't as widely used because >> of the ISO addressing. Atleast thats my take on it.. > > Sorry, my mistake. I'll go sit in my corner now... > -Jack From ras at e-gerbil.net Thu Sep 30 23:32:13 2010 From: ras at e-gerbil.net (Richard A Steenbergen) Date: Thu, 30 Sep 2010 18:32:13 -0500 Subject: BGP next-hop In-Reply-To: References: <20100930140119.GA6643@ussenterprise.ufp.org> <20100930224410.GC1946@gerbil.cluepon.net> Message-ID: <20100930233213.GF1946@gerbil.cluepon.net> On Thu, Sep 30, 2010 at 11:56:06PM +0100, Heath Jones wrote: > > Its interesting, I was heavy into cisco years back and then juniper > for a while. Going back to cisco now is great (always good for me to > keep my exposure up), but there is just so much unclear in it's CLI. > It wasn't until going back that I realised. > > I guess they would have to balance keeping the old timers & scripts > etc happy VS bringing in new features that make the output look > different.. Do you keep something that isn't perfect but people know > how to use, or change it and cause more issues than good? Personally I still can't believe that it's the year 2010, and IOS still shows routes in classful notation (i.e. if it's in 192.0.0.0/3 and is a /24, the /24 part isn't displayed because it's assumed to be "Class C"). Of course I say that every year, and so far the only thing that has changed is the year I say it about. > ps. Juniper has really gone to $h!t lately. There's a website called > glassdoor.com that I found - go look up what employees have to say > about it.. reflects exactly the support we were getting, even as as an > 'elite' partner.. Don't get me started, I could complain for days and still not run out of material, but alas it doesn't accomplish anything. Sadly, many of the best Juniper people I know are incredibly disaffected, and are leaving (or have already left) in droves. I think the way I heard it put best was, "I'm convinced that $somenewexecfromcisco is actually on a secret 5 year mission to come over to Juniper, completely $%^* the company, and then go back to Cisco and get a big bonus for it". :) -- Richard A Steenbergen http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) From hj1980 at gmail.com Thu Sep 30 23:32:17 2010 From: hj1980 at gmail.com (Heath Jones) Date: Fri, 1 Oct 2010 00:32:17 +0100 Subject: BGP next-hop In-Reply-To: References: <20100930140119.GA6643@ussenterprise.ufp.org> <1285862653.30784.23.camel@angel> Message-ID: > it seems it gets the bgp route for 147.28.0.0/16 and then can not > resolve the next hop. ?it would not recurse to the default exit. > > of course it was solved by > ? ?ip route 147.28.0.0 ?255.255.0.0 ?42.666.77.11 > but i do not really understand in my heart why i needed to do this. Neither do I, Randy. I have seen recursive routing done - perhaps on a juniper - i really cannot remember. Given that the packet would be originating from the device itself (not hardware forwarded), it would make sense that it should be able to perform a recursive lookup. I'd put it down to an implementation thing.. Unrelated, I was doing some thinking about a multihomed site and using BGP advertisments sent out one link (provider 1) to influence the sending of the advertisments out of the other link (provider 2). Long story short I needed to know how long bgp nlri's take to traverse the net, and subsequently have a paper that you co-authored open in another tab - well done! :) From randy at psg.com Thu Sep 30 23:57:52 2010 From: randy at psg.com (Randy Bush) Date: Fri, 01 Oct 2010 08:57:52 +0900 Subject: BGP next-hop In-Reply-To: References: <20100930140119.GA6643@ussenterprise.ufp.org> <1285862653.30784.23.camel@angel> Message-ID: >> it seems it gets the bgp route for 147.28.0.0/16 and then can not >> resolve the next hop. ?it would not recurse to the default exit. >> >> of course it was solved by >> ? ?ip route 147.28.0.0 ?255.255.0.0 ?42.666.77.11 >> but i do not really understand in my heart why i needed to do this. > > Neither do I, Randy. a good friend at cisco says he will take the time to write up why in the next day or two. > I needed to know how long bgp nlri's take to traverse the net high variance randy