From mcalhoun at iodatacenters.com Fri May 1 03:01:05 2009 From: mcalhoun at iodatacenters.com (Calhoun, Matthew) Date: Fri, 1 May 2009 01:01:05 -0700 Subject: how to fix incorrect GeoIP data? In-Reply-To: <20090501042538.GE12911@angus.ind.WPI.EDU> References: <20090501005154.GA26724@angus.ind.WPI.EDU> <20090501042538.GE12911@angus.ind.WPI.EDU> Message-ID: <57F018B226E004449B318DAF71A6014656F65F9E9E@IO-SCD-EX-M-01.corp.iodatacenters.com> We've had this happen with many new IP allocations. There's a Google FAQ for it at... http://www.google.com/support/websearch/bin/answer.py?hl=en&answer=873 Take care, Matt -----Original Message----- From: Chuck Anderson [mailto:cra at WPI.EDU] Sent: Thursday, April 30, 2009 9:26 PM To: nanog at nanog.org Subject: Re: how to fix incorrect GeoIP data? On Thu, Apr 30, 2009 at 11:57:23PM -0400, Martin Hannigan wrote: > On Thu, Apr 30, 2009 at 8:51 PM, Chuck Anderson wrote: > > > I have a customer who received a new assignment from ARIN, but the > > GeoIP data is returning Canada rather than the US as the location of > > the IP prefix. Google redirects to www.google.ca and some other sites > > aren't working correctly because they expect a US IP. Does anyone > > have any advice on how to update the GeoIP and other similar > > databases? > > What's the allocation? 74.112.8.0/21 Google has been contacted and they said it will take a month for stuff to update. The customer has also updated hostip.info. From cidr-report at potaroo.net Fri May 1 07:00:03 2009 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 1 May 2009 22:00:03 +1000 (EST) Subject: The Cidr Report Message-ID: <200905011200.n41C03MP036460@wattle.apnic.net> This report has been generated at Fri May 1 21:14:35 2009 AEST. The report analyses the BGP Routing Table of AS2.0 router and generates a report on aggregation potential within the table. Check http://www.cidr-report.org for a current version of this report. Recent Table History Date Prefixes CIDR Agg 24-04-09 293508 183193 25-04-09 293368 183008 26-04-09 293365 183060 27-04-09 293353 183017 28-04-09 293240 182847 29-04-09 293688 183208 30-04-09 293994 183201 01-05-09 293917 183533 AS Summary 31223 Number of ASes in routing system 13291 Number of ASes announcing only one prefix 4312 Largest number of prefixes announced by an AS AS6389 : BELLSOUTH-NET-BLK - BellSouth.net Inc. 89676288 Largest address span announced by an AS (/32s) AS27064: DDN-ASNBLK1 - DoD Network Information Center Aggregation Summary The algorithm used in this report proposes aggregation only when there is a precise match using the AS path, so as to preserve traffic transit policies. Aggregation is also proposed across non-advertised address space ('holes'). --- 01May09 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 293920 183310 110610 37.6% All ASes AS6389 4312 358 3954 91.7% BELLSOUTH-NET-BLK - BellSouth.net Inc. AS4323 4265 1743 2522 59.1% TWTC - tw telecom holdings, inc. AS209 2631 1159 1472 55.9% ASN-QWEST - Qwest Communications Corporation AS4766 1804 522 1282 71.1% KIXS-AS-KR Korea Telecom AS17488 1555 297 1258 80.9% HATHWAY-NET-AP Hathway IP Over Cable Internet AS4755 1239 146 1093 88.2% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP AS22773 1049 67 982 93.6% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. AS8452 1235 323 912 73.8% TEDATA TEDATA AS8151 1446 580 866 59.9% Uninet S.A. de C.V. AS1785 1752 891 861 49.1% AS-PAETEC-NET - PaeTec Communications, Inc. AS19262 990 239 751 75.9% VZGNI-TRANSIT - Verizon Internet Services Inc. AS18566 1062 421 641 60.4% COVAD - Covad Communications Co. AS18101 753 161 592 78.6% RIL-IDC Reliance Infocom Ltd Internet Data Centre, AS6478 1390 803 587 42.2% ATT-INTERNET3 - AT&T WorldNet Services AS11492 1096 538 558 50.9% CABLEONE - CABLE ONE, INC. AS17908 615 76 539 87.6% TCISL Tata Communications AS855 620 97 523 84.4% CANET-ASN-4 - Bell Aliant Regional Communications, Inc. AS22047 617 99 518 84.0% VTR BANDA ANCHA S.A. AS4804 574 66 508 88.5% MPX-AS Microplex PTY LTD AS2706 543 41 502 92.4% HKSUPER-HK-AP Pacific Internet (Hong Kong) Limited AS4808 615 163 452 73.5% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network AS7018 1468 1017 451 30.7% ATT-INTERNET4 - AT&T WorldNet Services AS24560 684 246 438 64.0% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services AS9443 525 95 430 81.9% INTERNETPRIMUS-AS-AP Primus Telecommunications AS10620 905 478 427 47.2% TV Cable S.A. AS17676 565 140 425 75.2% GIGAINFRA BB TECHNOLOGY Corp. AS6517 655 237 418 63.8% RELIANCEGLOBALCOM - Reliance Globalcom Services, Inc AS4134 898 485 413 46.0% CHINANET-BACKBONE No.31,Jin-rong Street AS7545 806 396 410 50.9% TPG-INTERNET-AP TPG Internet Pty Ltd AS7011 958 551 407 42.5% FRONTIER-AND-CITIZENS - Frontier Communications of America, Inc. Total 37627 12435 25192 67.0% Top 30 total Possible Bogus Routes 24.75.116.0/22 AS10796 SCRR-10796 - Road Runner HoldCo LLC 24.245.128.0/17 AS11492 CABLEONE - CABLE ONE, INC. 24.246.0.0/17 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 24.246.128.0/18 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 41.223.112.0/22 AS5713 SAIX-NET 41.223.176.0/22 AS36981 41.223.188.0/24 AS22351 INTELSAT Intelsat Global BGP Routing Policy 41.223.189.0/24 AS26452 BRING-AS - BringCom, Inc. 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV - Wireless Broadband via Satellite 62.61.221.0/24 AS24974 TACHYON-EU Tachyon Europe BV - Wireless Broadband via Satellite 63.140.213.0/24 AS22555 UTC - Universal Talkware Corporation 63.143.251.0/24 AS22555 UTC - Universal Talkware Corporation 64.31.32.0/19 AS11955 SCRR-11955 - Road Runner HoldCo LLC 64.31.32.0/22 AS10796 SCRR-10796 - Road Runner HoldCo LLC 64.31.36.0/23 AS10796 SCRR-10796 - Road Runner HoldCo LLC 64.31.38.0/23 AS12262 RR-CINCINNATI-ASN-01 - Road Runner HoldCo LLC 64.31.40.0/23 AS12262 RR-CINCINNATI-ASN-01 - Road Runner HoldCo LLC 64.31.42.0/23 AS10796 SCRR-10796 - Road Runner HoldCo LLC 64.31.44.0/23 AS10796 SCRR-10796 - Road Runner HoldCo LLC 64.31.46.0/24 AS10796 SCRR-10796 - Road Runner HoldCo LLC 64.31.48.0/22 AS11060 NEO-RR-COM - Road Runner HoldCo LLC 64.31.53.0/24 AS10796 SCRR-10796 - Road Runner HoldCo LLC 64.31.55.0/24 AS10796 SCRR-10796 - Road Runner HoldCo LLC 64.31.59.0/24 AS7017 SCRR-7015 - Road Runner HoldCo LLC 64.31.60.0/24 AS7017 SCRR-7015 - Road Runner HoldCo LLC 64.79.88.0/24 AS26096 LODDEN - Lodden Services 64.79.89.0/24 AS26096 LODDEN - Lodden Services 64.147.64.0/19 AS40156 THEOPT-HOU - The Optimal Link Corporation 66.11.32.0/20 AS6261 VISINET - Visionary Systems, Inc. 66.11.40.0/21 AS6261 VISINET - Visionary Systems, Inc. 66.54.91.0/24 AS30506 BLACKSUN-1 - Blacksun Technologies LLC 66.55.160.0/19 AS29994 66.128.38.0/24 AS15246 Telecomunicaciones Satelitales TelesatS.A. 66.180.239.0/24 AS35888 VIGNETTE - VIGNETTE CORPORATION 66.206.32.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.33.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.34.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.35.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.40.0/22 AS174 COGENT Cogent/PSI 66.206.44.0/23 AS174 COGENT Cogent/PSI 66.206.47.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 66.207.32.0/20 AS23011 66.245.176.0/20 AS19318 NJIIX-AS-1 - NEW JERSEY INTERNATIONAL INTERNET EXCHANGE LLC 69.71.192.0/20 AS13818 PHX-INTL-TELEPORT - Phoenix International Teleport 80.88.0.0/21 AS33774 DJAWEB 80.88.8.0/22 AS33774 DJAWEB 80.88.10.0/24 AS33774 DJAWEB 80.88.12.0/24 AS33779 wataniya-telecom-as 98.96.0.0/13 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 100.100.100.0/30 AS38676 AS33005-AS-KR wizsolution co.,Ltd 109.0.0.0/16 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 109.1.0.0/21 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 109.1.24.0/24 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 110.76.156.0/24 AS45062 CNNIC-FKT-AP FEIKE TECH LIMITED 110.76.157.0/24 AS45062 CNNIC-FKT-AP FEIKE TECH LIMITED 121.46.0.0/16 AS4134 CHINANET-BACKBONE No.31,Jin-rong Street 121.50.168.0/21 AS9931 CAT-AP The Communication Authoity of Thailand, CAT 122.128.120.0/22 AS38456 PACTEL-AS-AP Pacific Teleports. 137.0.0.0/13 AS27064 DDN-ASNBLK1 - DoD Network Information Center 150.0.2.0/24 AS9730 BHARTITELESONIC-AS-IN-AP Bharti Telesonic Ltd 150.0.3.0/24 AS9730 BHARTITELESONIC-AS-IN-AP Bharti Telesonic Ltd 150.0.11.0/24 AS9730 BHARTITELESONIC-AS-IN-AP Bharti Telesonic Ltd 158.222.5.0/24 AS21580 DIRCON - Direct Connect 158.222.70.0/23 AS6137 SISNA - SISNA, Inc. 158.222.72.0/23 AS6137 SISNA - SISNA, Inc. 158.222.224.0/20 AS19864 O1COMM - O1 COMMUNICATIONS 158.222.224.0/22 AS19864 O1COMM - O1 COMMUNICATIONS 158.222.229.0/24 AS19864 O1COMM - O1 COMMUNICATIONS 163.142.0.0/16 AS2500 WIDE-BB WIDE Project 168.253.0.0/16 AS13649 ASN-VINS - ViaWest 168.253.0.0/21 AS13649 ASN-VINS - ViaWest 172.7.0.0/24 AS28175 172.10.1.0/30 AS18305 POSNET POSDATA Co.,Ltd 178.0.0.0/16 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 178.1.0.0/21 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 178.1.24.0/24 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 192.9.0.0/16 AS11479 BRM-SUN-AS - Sun Microsystems, Inc 192.9.200.0/24 AS3602 AS3602-RTI - Rogers Telecom Inc. 192.64.85.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.69.107.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.69.108.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.69.177.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.70.164.0/24 AS25689 NRCNET-AS - National Research Council of Canada 192.96.37.0/24 AS10474 NETACTIVE 192.96.135.0/24 AS2018 TENET-1 192.96.136.0/23 AS2018 TENET-1 192.96.141.0/24 AS2018 TENET-1 192.96.143.0/24 AS2018 TENET-1 192.96.145.0/24 AS2018 TENET-1 192.96.177.0/24 AS6083 POSIX-AFRICA 192.101.45.0/24 AS2905 TICSA-ASN 192.101.46.0/24 AS6503 Avantel, S.A. 192.101.64.0/21 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 192.101.70.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 192.101.71.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 192.101.72.0/24 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 192.101.74.0/24 AS1239 SPRINTLINK - Sprint 192.124.248.0/23 AS680 DFN-IP service G-WiN 192.124.252.0/22 AS680 DFN-IP service G-WiN 192.131.233.0/24 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 192.132.58.0/24 AS20141 QUALITYTECH-SUW-300 - Quality Technology Services, LLC. 192.133.6.0/24 AS10282 ORANGE-BUSINESS-SERVICES-CEEUR Orange Business Services (formerly Equant) AS for CEEUR 192.153.144.0/21 AS27064 DDN-ASNBLK1 - DoD Network Information Center 192.154.32.0/19 AS81 NCREN - MCNC 192.188.208.0/20 AS27064 DDN-ASNBLK1 - DoD Network Information Center 196.6.108.0/24 AS5713 SAIX-NET 196.10.119.0/24 AS2018 TENET-1 196.10.122.0/23 AS2018 TENET-1 196.10.251.0/24 AS2018 TENET-1 196.10.252.0/23 AS2018 TENET-1 196.10.254.0/24 AS2018 TENET-1 196.13.101.0/24 AS2018 TENET-1 196.13.102.0/23 AS2018 TENET-1 196.13.104.0/24 AS2018 TENET-1 196.13.121.0/24 AS2018 TENET-1 196.13.125.0/24 AS2018 TENET-1 196.13.126.0/24 AS2018 TENET-1 196.13.169.0/24 AS2018 TENET-1 196.13.174.0/23 AS2018 TENET-1 196.13.176.0/21 AS2018 TENET-1 196.13.192.0/22 AS2018 TENET-1 196.13.196.0/24 AS2018 TENET-1 196.202.224.0/21 AS8818 TELE Greenland Autonomous System 198.1.2.0/24 AS4761 INDOSAT-INP-AP INDOSAT Internet Network Provider 198.23.26.0/24 AS4390 BELLATLANTIC-COM - Bell Atlantic, Inc. 198.54.82.0/24 AS2018 TENET-1 198.54.92.0/24 AS2018 TENET-1 198.54.222.0/24 AS2018 TENET-1 198.73.210.0/24 AS21570 ACI-1 - Accelerated Connections Inc. 198.97.72.0/21 AS27064 DDN-ASNBLK1 - DoD Network Information Center 198.97.96.0/19 AS27064 DDN-ASNBLK1 - DoD Network Information Center 198.97.240.0/20 AS27064 DDN-ASNBLK1 - DoD Network Information Center 198.135.236.0/24 AS4358 XNET - XNet Information Systems, Inc. 198.161.87.0/24 AS6539 GT-BELL - Bell Canada 198.161.92.0/24 AS6539 GT-BELL - Bell Canada 198.167.0.0/16 AS7456 INTERHOP - Interhop Network SERVICES Inc. 198.168.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 198.169.0.0/16 AS803 SASKTEL - Saskatchewan Telecommunications 198.180.198.0/24 AS23715 SEOUL-INTGW-GXS-AP Global Exchange Services 199.5.242.0/24 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 199.10.0.0/16 AS27064 DDN-ASNBLK1 - DoD Network Information Center 199.19.0.0/24 AS3848 WORLDLINX-2 - WorldLinx Telecommunications, Inc. 199.114.0.0/21 AS27064 DDN-ASNBLK1 - DoD Network Information Center 199.114.128.0/18 AS27064 DDN-ASNBLK1 - DoD Network Information Center 199.114.130.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.131.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.132.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.134.0/24 AS3541 ITSDN-U4 - DoD Network Information Center 199.114.136.0/24 AS27044 DDN-ASNBLK1 - DoD Network Information Center 199.114.138.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.140.0/24 AS3544 ITSDN-U7 - DoD Network Information Center 199.114.142.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.144.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.148.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.150.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.152.0/24 AS27033 DDN-ASNBLK1 - DoD Network Information Center 199.114.153.0/24 AS27034 DDN-ASNBLK1 - DoD Network Information Center 199.114.154.0/24 AS1733 CENTAF-SWA - 754th Electronic Systems Group 199.114.156.0/24 AS1733 CENTAF-SWA - 754th Electronic Systems Group 199.114.160.0/24 AS1733 CENTAF-SWA - 754th Electronic Systems Group 199.121.0.0/16 AS27064 DDN-ASNBLK1 - DoD Network Information Center 199.123.0.0/18 AS27064 DDN-ASNBLK1 - DoD Network Information Center 199.123.16.0/20 AS27064 DDN-ASNBLK1 - DoD Network Information Center 199.123.80.0/21 AS27064 DDN-ASNBLK1 - DoD Network Information Center 199.189.32.0/19 AS7332 IQUEST-AS - IQuest Internet 199.202.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 199.202.216.0/21 AS577 BACOM - Bell Canada 199.246.116.0/24 AS813 UUNET-CANADA - MCI Communications Services, Inc. d/b/a Verizon Business 202.6.176.0/20 AS24316 202.58.113.0/24 AS19161 INNOCOM-TELECOM - INNOCOM TELECOM 202.73.144.0/20 AS4788 TMNET-AS-AP TM Net, Internet Service Provider 202.80.192.0/20 AS2706 HKSUPER-HK-AP Pacific Internet (Hong Kong) Limited 202.86.252.0/22 AS4748 RESOLINK-AS-AP Resources Link Network Limited 202.86.252.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.253.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.254.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.255.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.94.70.0/24 AS2764 AAPT AAPT Limited 202.122.120.0/21 AS17494 BTTB-AS-AP Telecom Operator & Internet Service Provider as well 202.124.195.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.133.70.0/24 AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited 202.133.73.0/24 AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited 202.136.254.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.136.255.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.140.160.0/24 AS4841 202.140.161.0/24 AS4841 202.140.162.0/24 AS4841 202.140.163.0/24 AS4841 202.140.164.0/24 AS4841 202.140.165.0/24 AS4841 202.140.166.0/24 AS4841 202.140.167.0/24 AS4841 202.140.168.0/24 AS4841 202.140.169.0/24 AS4841 202.140.170.0/24 AS4841 202.140.171.0/24 AS4841 202.140.172.0/24 AS4841 202.140.173.0/24 AS4841 202.140.174.0/24 AS4841 202.140.175.0/24 AS4841 202.140.180.0/24 AS7540 HKCIX-AS-AP HongKong Commercial Internet Exchange 202.140.181.0/24 AS7540 HKCIX-AS-AP HongKong Commercial Internet Exchange 202.140.182.0/24 AS7540 HKCIX-AS-AP HongKong Commercial Internet Exchange 202.150.227.0/24 AS17727 NAPINFO-AS-AP PT. NAP Info Lintas Nusa 202.181.32.0/24 AS4645 ASN-HKNET-AP HKNet Co. Ltd 203.12.45.0/24 AS4854 NETSPACE-AS-AP Netspace Online Systems 203.62.0.0/17 AS7575 AARNET-AS-AP Australian Academic and Reasearch Network (AARNet) 203.78.48.0/20 AS9299 IPG-AS-AP Philippine Long Distance Telephone Company 203.89.139.0/24 AS17911 BRAINPK-AS-AP Brain Telecommunication Ltd. 203.111.192.0/20 AS7473 SINGTEL-AS-AP Singapore Telecommunications Ltd 203.112.111.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.113.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.114.0/24 AS4802 ASN-IINET iiNet Limited 203.112.116.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.117.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.118.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.119.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.120.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.121.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.127.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.128.128.0/19 AS4134 CHINANET-BACKBONE No.31,Jin-rong Street 203.128.128.0/24 AS23849 CNNIC-NET263-AP Beijing Capital-online science development Co.,Ltd. 203.152.154.0/23 AS9583 SIFY-AS-IN Sify Limited 204.9.216.0/23 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 204.9.218.0/23 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 204.13.140.0/22 AS7270 NET2PHONE - Net2Phone Corp. 204.13.140.0/24 AS7270 NET2PHONE - Net2Phone Corp. 204.13.141.0/24 AS7270 NET2PHONE - Net2Phone Corp. 204.13.142.0/24 AS7270 NET2PHONE - Net2Phone Corp. 204.13.143.0/24 AS7270 NET2PHONE - Net2Phone Corp. 204.13.184.0/23 AS35967 204.13.186.0/23 AS35967 204.13.186.0/24 AS35967 204.13.187.0/24 AS35967 204.19.14.0/23 AS577 BACOM - Bell Canada 204.89.214.0/24 AS4323 TWTC - tw telecom holdings, inc. 204.138.167.0/24 AS18990 AIRBAND-DALLAS - Airband Communications, Inc 205.150.0.0/15 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 205.189.134.0/24 AS11814 CYBERSURF - Cybersurf Inc. 205.210.145.0/24 AS11814 CYBERSURF - Cybersurf Inc. 206.180.240.0/20 AS12083 KNOLOGY-NET - Knology Holdings 207.174.0.0/16 AS13790 INTERNAP-BLK3 - Internap Network Services Corporation 207.174.131.0/24 AS30715 NETRACK - Netrack, Inc. 207.174.132.0/23 AS30715 NETRACK - Netrack, Inc. 207.174.151.0/24 AS11500 PEAKPEAK - Peak to Peak Internet 207.174.152.0/22 AS30715 NETRACK - Netrack, Inc. 207.174.158.0/24 AS11500 PEAKPEAK - Peak to Peak Internet 207.174.177.0/24 AS11500 PEAKPEAK - Peak to Peak Internet 207.174.178.0/24 AS11500 PEAKPEAK - Peak to Peak Internet 207.174.182.0/24 AS29831 FONENET - FONE NET, LLC 207.174.188.0/22 AS30715 NETRACK - Netrack, Inc. 207.174.192.0/24 AS29831 FONENET - FONE NET, LLC 207.174.200.0/24 AS22658 EARTHNET - Earthnet, Inc. 207.174.248.0/21 AS6653 PRIVATEI - privateI, LLC 207.231.96.0/19 AS11194 NUNETPA - NuNet Inc. 209.54.123.0/24 AS6062 NETPLEX - NETPLEX 209.54.240.0/21 AS10887 BPSI-AS - BPSI Internet Services 209.74.96.0/19 AS10912 INTERNAP-BLK - Internap Network Services Corporation 209.140.90.0/24 AS14461 NTSL - NET SOLUTIONS 209.141.48.0/22 AS14461 NTSL - NET SOLUTIONS 209.145.192.0/18 AS3043 AMPHIB-AS - Amphibian Media Corporation 209.177.93.0/24 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 209.222.5.0/24 AS26699 PSI-CT - Printing For Systems Inc 209.222.6.0/24 AS26699 PSI-CT - Printing For Systems Inc 210.5.128.0/20 AS4837 CHINA169-BACKBONE CNCGROUP China169 Backbone 216.37.114.0/23 AS3549 GBLX Global Crossing Ltd. 216.99.20.0/24 AS6395 LVLT-6395 - Level 3 Communications, Inc. 216.172.198.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 216.172.199.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 216.240.240.0/24 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 216.240.241.0/24 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 216.240.242.0/24 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 216.251.207.0/24 AS1239 SPRINTLINK - Sprint 217.78.71.0/24 AS12491 IPPLANET-AS IPPlanet 217.78.72.0/24 AS12491 IPPLANET-AS IPPlanet 217.78.73.0/24 AS12491 IPPLANET-AS IPPlanet Please see http://www.cidr-report.org for the full report ------------------------------------ Copies of this report are mailed to: nanog at merit.edu eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From cidr-report at potaroo.net Fri May 1 07:00:25 2009 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 1 May 2009 22:00:25 +1000 (EST) Subject: BGP Update Report Message-ID: <200905011200.n41C0P8B036479@wattle.apnic.net> BGP Update Report Interval: 30-Mar-09 -to- 30-Apr-09 (32 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS6389 371436 4.1% 85.1 -- BELLSOUTH-NET-BLK - BellSouth.net Inc. 2 - AS3130 123394 1.4% 478.3 -- RGNET-3130 RGnet/PSGnet 3 - AS2386 111342 1.2% 85.3 -- INS-AS - AT&T Data Communications Services 4 - AS8452 97850 1.1% 69.2 -- TEDATA TEDATA 5 - AS6478 83258 0.9% 59.5 -- ATT-INTERNET3 - AT&T WorldNet Services 6 - AS17488 77778 0.9% 49.9 -- HATHWAY-NET-AP Hathway IP Over Cable Internet 7 - AS11492 69963 0.8% 56.7 -- CABLEONE - CABLE ONE, INC. 8 - AS29049 67638 0.8% 208.1 -- DELTA-TELECOM-AS Delta Telecom LTD. 9 - AS4323 62131 0.7% 14.4 -- TWTC - tw telecom holdings, inc. 10 - AS7018 60224 0.7% 39.5 -- ATT-INTERNET4 - AT&T WorldNet Services 11 - AS19262 58605 0.7% 59.1 -- VZGNI-TRANSIT - Verizon Internet Services Inc. 12 - AS35805 54928 0.6% 167.5 -- UTG-AS United Telecom AS 13 - AS20115 49616 0.6% 29.5 -- CHARTER-NET-HKY-NC - Charter Communications 14 - AS9829 49466 0.6% 76.6 -- BSNL-NIB National Internet Backbone 15 - AS10796 49370 0.6% 85.0 -- SCRR-10796 - Road Runner HoldCo LLC 16 - AS4755 48369 0.5% 38.6 -- TATACOMM-AS TATA Communications formerly VSNL is Leading ISP 17 - AS8151 44307 0.5% 30.3 -- Uninet S.A. de C.V. 18 - AS21491 42886 0.5% 1383.4 -- UTL-ON-LINE UTL On-line is RF broadband ISP in Uganda - Africa 19 - AS9498 37662 0.4% 50.4 -- BBIL-AP BHARTI Airtel Ltd. 20 - AS12978 37120 0.4% 206.2 -- DOGAN-ONLINE Dogan Iletisim Elektronik Servis Hizmetleri AS TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS15045 18729 0.2% 6243.0 -- KITTELSON - KITTELSON AND ASSOCIATES, INC. 2 - AS46653 15874 0.2% 5291.3 -- FREDRIKSON---BYRON - Fredrikson & Byron, P.A. 3 - AS40967 4236 0.1% 4236.0 -- CSF-AS CSF Computersoftware fuer Fachanwendungen GmbH 4 - AS32398 19356 0.2% 3226.0 -- REALNET-ASN-1 5 - AS7717 2763 0.0% 2763.0 -- OPENIXP-AS-ID-AP OpenIXP ASN 6 - AS14223 5285 0.1% 2642.5 -- NYSDOH - New York State Department of Health 7 - AS30423 4076 0.1% 2038.0 -- AMEDI-3-ASN1 - Amedisys, Inc. 8 - AS46328 18132 0.2% 2014.7 -- PTCNEBRASKA - PIERCE TELEPHONE COMPANY, INCORPORATED 9 - AS47640 5467 0.1% 1822.3 -- TRICOMPAS Tricomp Sp. z. o. o. 10 - AS5050 24977 0.3% 1665.1 -- PSC-EXT - Pittsburgh Supercomputing Center 11 - AS13325 11776 0.1% 1472.0 -- STOMI - State of Michigan, DMB-CNOC 12 - AS21491 42886 0.5% 1383.4 -- UTL-ON-LINE UTL On-line is RF broadband ISP in Uganda - Africa 13 - AS9796 3831 0.0% 1277.0 -- WIPRO Internet Service Providers 14 - AS34321 2274 0.0% 1137.0 -- LDK-AS Institute of strategic marks, Kiev, Ukraine 15 - AS19398 2003 0.0% 1001.5 -- INDENET - Indenet.net 16 - AS17975 8139 0.1% 904.3 -- APT-AP AS# for peering purpose with IX and ISP. 17 - AS5691 10515 0.1% 808.8 -- MITRE-AS-5 - The MITRE Corporation 18 - AS34996 791 0.0% 791.0 -- ANADOLUSIGORTA-AS Anadolu Sigorta AS 19 - AS41492 787 0.0% 787.0 -- EXIMBANK-AS SC Eximbank SA 20 - AS25412 1520 0.0% 760.0 -- CCRTV-AS CCRTV AS Barcelona Spain TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 72.23.246.0/24 24846 0.3% AS5050 -- PSC-EXT - Pittsburgh Supercomputing Center 2 - 41.204.2.0/24 19003 0.2% AS32398 -- REALNET-ASN-1 3 - 199.45.13.0/24 15854 0.2% AS46653 -- FREDRIKSON---BYRON - Fredrikson & Byron, P.A. 4 - 192.12.120.0/24 10327 0.1% AS5691 -- MITRE-AS-5 - The MITRE Corporation 6 - 192.35.129.0/24 7976 0.1% AS6629 -- NOAA-AS - NOAA 7 - 198.77.177.0/24 7907 0.1% AS6629 -- NOAA-AS - NOAA 8 - 192.102.88.0/24 7894 0.1% AS6629 -- NOAA-AS - NOAA 9 - 63.103.104.0/22 6486 0.1% AS15045 -- KITTELSON - KITTELSON AND ASSOCIATES, INC. 10 - 63.103.108.0/23 6486 0.1% AS15045 -- KITTELSON - KITTELSON AND ASSOCIATES, INC. 11 - 195.96.69.0/24 6143 0.1% AS8225 -- ASTELIT-MSK-AS Astelit Autonomous System 12 - 63.103.110.0/24 5757 0.1% AS15045 -- KITTELSON - KITTELSON AND ASSOCIATES, INC. 13 - 193.201.184.0/21 5649 0.1% AS25546 -- BROOKLANDCOMP-AS Brookland Computer Services 14 - 94.124.16.0/21 5424 0.1% AS47640 -- TRICOMPAS Tricomp Sp. z. o. o. 15 - 123.49.152.0/24 5358 0.1% AS18118 -- CITICNET-AP CITIC Networks Management Co.,Ltd. 16 - 192.135.176.0/24 5268 0.1% AS14223 -- NYSDOH - New York State Department of Health 17 - 202.92.235.0/24 4899 0.1% AS9498 -- BBIL-AP BHARTI Airtel Ltd. 18 - 123.49.144.0/21 4804 0.1% AS18118 -- CITICNET-AP CITIC Networks Management Co.,Ltd. 19 - 205.104.240.0/20 4701 0.1% AS5237 -- DODNIC - DoD Network Information Center AS5839 -- DDN-ASNBLK - DoD Network Information Center 20 - 81.199.18.0/24 4418 0.1% AS21491 -- UTL-ON-LINE UTL On-line is RF broadband ISP in Uganda - Africa Details at http://bgpupdates.potaroo.net ------------------------------------ Copies of this report are mailed to: nanog at merit.edu eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From frnkblk at iname.com Fri May 1 12:23:43 2009 From: frnkblk at iname.com (Frank Bulk) Date: Fri, 1 May 2009 12:23:43 -0500 Subject: how to fix incorrect GeoIP data? In-Reply-To: <57F018B226E004449B318DAF71A6014656F65F9E9E@IO-SCD-EX-M-01.corp.iodatacenters.com> References: <20090501005154.GA26724@angus.ind.WPI.EDU> <20090501042538.GE12911@angus.ind.WPI.EDU> <57F018B226E004449B318DAF71A6014656F65F9E9E@IO-SCD-EX-M-01.corp.iodatacenters.com> Message-ID: Thanks for that link, it must be relatively new, cause I couldn't find that around Christmas time last year. What we need is a "master update" form where Akamai, Google, Maxmind, hostip.info, Geobytes, ip2location, ipgeo, etc can be notified about changes. Frank -----Original Message----- From: Calhoun, Matthew [mailto:mcalhoun at iodatacenters.com] Sent: Friday, May 01, 2009 3:01 AM To: Chuck Anderson; nanog at nanog.org Subject: RE: how to fix incorrect GeoIP data? We've had this happen with many new IP allocations. There's a Google FAQ for it at... http://www.google.com/support/websearch/bin/answer.py?hl=en&answer=873 Take care, Matt -----Original Message----- From: Chuck Anderson [mailto:cra at WPI.EDU] Sent: Thursday, April 30, 2009 9:26 PM To: nanog at nanog.org Subject: Re: how to fix incorrect GeoIP data? On Thu, Apr 30, 2009 at 11:57:23PM -0400, Martin Hannigan wrote: > On Thu, Apr 30, 2009 at 8:51 PM, Chuck Anderson wrote: > > > I have a customer who received a new assignment from ARIN, but the > > GeoIP data is returning Canada rather than the US as the location of > > the IP prefix. Google redirects to www.google.ca and some other sites > > aren't working correctly because they expect a US IP. Does anyone > > have any advice on how to update the GeoIP and other similar > > databases? > > What's the allocation? 74.112.8.0/21 Google has been contacted and they said it will take a month for stuff to update. The customer has also updated hostip.info. From jdshoemaker at gmail.com Fri May 1 12:55:46 2009 From: jdshoemaker at gmail.com (Jason Shoemaker) Date: Fri, 1 May 2009 13:55:46 -0400 Subject: 10-GigE for servers Message-ID: <81ecd7700905011055y3fd14276pbb78c2b80882da63@mail.gmail.com> My company is looking for ways to improve throughput for data transfers between individual servers. We?re exploring the creation of Etherchannels using multiple server NICs, but Etherchannel seems to have the limitation of not supporting per-packet load-balancing, therefore limiting traffic between two individual hosts to 1 Gig. In most of my research, I?ve seen 10-GigE used for traffic aggregation and for the ?unified fabric? solution that Cisco and others are pushing. I?m interested in knowing if any of you have attempted to implement 10-GigE at the host level to improve network throughput between individual servers and what your experience was in doing so. Thanks in advance, Jason From alex at blastro.com Fri May 1 13:05:10 2009 From: alex at blastro.com (Alex Thurlow) Date: Fri, 01 May 2009 13:05:10 -0500 Subject: 10-GigE for servers In-Reply-To: <81ecd7700905011055y3fd14276pbb78c2b80882da63@mail.gmail.com> References: <81ecd7700905011055y3fd14276pbb78c2b80882da63@mail.gmail.com> Message-ID: <49FB39D6.9020506@blastro.com> As long as it's not a single connection that you're looking to get over 1Gb, etherchannel should actually work. It uses a hash based on (I believe) source and destination IP and port, so it should roughly balance connections between the servers. The other option, if you're using Linux, is to use balance-rr mode on the bonding driver. This should deliver per-packet balancing and the switch doesn't have to know anything about the bonding. Documentation for the bonding driver is here: http://www.cyberciti.biz/howto/question/static/linux-ethernet-bonding-driver-howto.php -- Alex Thurlow Blastro Networks http://www.blastro.com http://www.roxwel.com http://www.yallwire.com On 5/1/2009 12:55 PM, Jason Shoemaker wrote: > My company is looking for ways to improve throughput for data transfers > between individual servers. We?re exploring the creation of Etherchannels > using multiple server NICs, but Etherchannel seems to have the limitation of > not supporting per-packet load-balancing, therefore limiting traffic between > two individual hosts to 1 Gig. > > In most of my research, I?ve seen 10-GigE used for traffic aggregation and > for the ?unified fabric? solution that Cisco and others are pushing. I?m > interested in knowing if any of you have attempted to implement 10-GigE at > the host level to improve network throughput between individual servers and > what your experience was in doing so. > > Thanks in advance, > > Jason > > -- Alex Thurlow Blastro Networks http://www.blastro.com http://www.roxwel.com http://www.yallwire.com From swmike at swm.pp.se Fri May 1 13:06:09 2009 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Fri, 1 May 2009 20:06:09 +0200 (CEST) Subject: how to fix incorrect GeoIP data? In-Reply-To: References: <20090501005154.GA26724@angus.ind.WPI.EDU> <20090501042538.GE12911@angus.ind.WPI.EDU> <57F018B226E004449B318DAF71A6014656F65F9E9E@IO-SCD-EX-M-01.corp.iodatacenters.com> Message-ID: On Fri, 1 May 2009, Frank Bulk wrote: > What we need is a "master update" form where Akamai, Google, Maxmind, > hostip.info, Geobytes, ip2location, ipgeo, etc can be notified about > changes. Perhaps we as the ISP community need to realise that we need to somehow publish this data (town or something alike) via some kind of standardized API? Right now I guess they use tracking cookies together with e-commerce account registration to deduct where an IP is from? -- Mikael Abrahamsson email: swmike at swm.pp.se From cmadams at hiwaay.net Fri May 1 13:15:58 2009 From: cmadams at hiwaay.net (Chris Adams) Date: Fri, 1 May 2009 13:15:58 -0500 Subject: 10-GigE for servers In-Reply-To: <49FB39D6.9020506@blastro.com> References: <81ecd7700905011055y3fd14276pbb78c2b80882da63@mail.gmail.com> <49FB39D6.9020506@blastro.com> Message-ID: <20090501181558.GB911164@hiwaay.net> Once upon a time, Alex Thurlow said: > As long as it's not a single connection that you're looking to get over > 1Gb, etherchannel should actually work. It uses a hash based on (I > believe) source and destination IP and port, so it should roughly > balance connections between the servers. That depends on the devices on each end. For example, some switches can only hash on MAC addresses, some can look at IPs, and some can look at ports. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From cscora at apnic.net Fri May 1 13:18:39 2009 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 2 May 2009 04:18:39 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <200905011818.n41IIdlK032179@thyme.apnic.net> This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. Daily listings are sent to bgp-stats at lists.apnic.net For historical data, please see http://thyme.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 02 May, 2009 Report Website: http://thyme.apnic.net Detailed Analysis: http://thyme.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 288051 Prefixes after maximum aggregation: 136022 Deaggregation factor: 2.12 Unique aggregates announced to Internet: 141369 Total ASes present in the Internet Routing Table: 31138 Prefixes per ASN: 9.25 Origin-only ASes present in the Internet Routing Table: 27105 Origin ASes announcing only one prefix: 13215 Transit ASes present in the Internet Routing Table: 4033 Transit-only ASes present in the Internet Routing Table: 92 Average AS path length visible in the Internet Routing Table: 3.6 Max AS path length visible: 33 Max AS path prepend of ASN (43683) 31 Prefixes from unregistered ASNs in the Routing Table: 469 Unregistered ASNs in the Routing Table: 153 Number of 32-bit ASNs allocated by the RIRs: 139 Prefixes from 32-bit ASNs in the Routing Table: 28 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 194 Number of addresses announced to Internet: 2038219584 Equivalent to 121 /8s, 124 /16s and 195 /24s Percentage of available address space announced: 55.0 Percentage of allocated address space announced: 63.6 Percentage of available address space allocated: 86.4 Percentage of address space in use by end-sites: 76.6 Total number of prefixes smaller than registry allocations: 142557 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 67520 Total APNIC prefixes after maximum aggregation: 24106 APNIC Deaggregation factor: 2.80 Prefixes being announced from the APNIC address blocks: 64190 Unique aggregates announced from the APNIC address blocks: 28896 APNIC Region origin ASes present in the Internet Routing Table: 3608 APNIC Prefixes per ASN: 17.79 APNIC Region origin ASes announcing only one prefix: 973 APNIC Region transit ASes present in the Internet Routing Table: 550 Average APNIC Region AS path length visible: 3.5 Max APNIC Region AS path length visible: 18 Number of APNIC addresses announced to Internet: 412626208 Equivalent to 24 /8s, 152 /16s and 45 /24s Percentage of available APNIC address space announced: 76.9 APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079 APNIC Address Blocks 58/8, 59/8, 60/8, 61/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 180/8, 183/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 125338 Total ARIN prefixes after maximum aggregation: 66038 ARIN Deaggregation factor: 1.90 Prefixes being announced from the ARIN address blocks: 94482 Unique aggregates announced from the ARIN address blocks: 36854 ARIN Region origin ASes present in the Internet Routing Table: 12953 ARIN Prefixes per ASN: 7.29 ARIN Region origin ASes announcing only one prefix: 5000 ARIN Region transit ASes present in the Internet Routing Table: 1251 Average ARIN Region AS path length visible: 3.3 Max ARIN Region AS path length visible: 24 Number of ARIN addresses announced to Internet: 428374528 Equivalent to 25 /8s, 136 /16s and 122 /24s Percentage of available ARIN address space announced: 82.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 ARIN Address Blocks 24/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8, 98/8, 99/8, 108/8, 173/8, 174/8, 184/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 66051 Total RIPE prefixes after maximum aggregation: 38227 RIPE Deaggregation factor: 1.73 Prefixes being announced from the RIPE address blocks: 60366 Unique aggregates announced from the RIPE address blocks: 40195 RIPE Region origin ASes present in the Internet Routing Table: 12951 RIPE Prefixes per ASN: 4.66 RIPE Region origin ASes announcing only one prefix: 6792 RIPE Region transit ASes present in the Internet Routing Table: 1950 Average RIPE Region AS path length visible: 4.0 Max RIPE Region AS path length visible: 33 Number of RIPE addresses announced to Internet: 393305888 Equivalent to 23 /8s, 113 /16s and 95 /24s Percentage of available RIPE address space announced: 83.7 RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-52223 RIPE Address Blocks 62/8, 77/8, 78/8, 79/8, 80/8, 81/8, 82/8, 83/8, 84/8, 85/8, 86/8, 87/8, 88/8, 89/8, 90/8, 91/8, 92/8, 93/8, 94/8, 95/8, 109/8, 178/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 23793 Total LACNIC prefixes after maximum aggregation: 5880 LACNIC Deaggregation factor: 4.05 Prefixes being announced from the LACNIC address blocks: 21946 Unique aggregates announced from the LACNIC address blocks: 12120 LACNIC Region origin ASes present in the Internet Routing Table: 1104 LACNIC Prefixes per ASN: 19.88 LACNIC Region origin ASes announcing only one prefix: 360 LACNIC Region transit ASes present in the Internet Routing Table: 182 Average LACNIC Region AS path length visible: 4.1 Max LACNIC Region AS path length visible: 28 Number of LACNIC addresses announced to Internet: 62785280 Equivalent to 3 /8s, 190 /16s and 7 /24s Percentage of available LACNIC address space announced: 62.4 LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247 plus ERX transfers LACNIC Address Blocks 186/8, 187/8, 189/8, 190/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 4921 Total AfriNIC prefixes after maximum aggregation: 1428 AfriNIC Deaggregation factor: 3.45 Prefixes being announced from the AfriNIC address blocks: 4582 Unique aggregates announced from the AfriNIC address blocks: 1400 AfriNIC Region origin ASes present in the Internet Routing Table: 293 AfriNIC Prefixes per ASN: 15.64 AfriNIC Region origin ASes announcing only one prefix: 90 AfriNIC Region transit ASes present in the Internet Routing Table: 59 Average AfriNIC Region AS path length visible: 3.9 Max AfriNIC Region AS path length visible: 15 Number of AfriNIC addresses announced to Internet: 11304960 Equivalent to 0 /8s, 172 /16s and 128 /24s Percentage of available AfriNIC address space announced: 33.7 AfriNIC AS Blocks 36864-37887 & ERX transfers AfriNIC Address Blocks 41/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4766 1697 6930 402 Korea Telecom (KIX) 17488 1555 124 98 Hathway IP Over Cable Interne 4755 1238 466 124 TATA Communications formerly 9583 1085 86 536 Sify Limited 4134 898 16676 373 CHINANET-BACKBONE 7545 787 168 107 TPG Internet Pty Ltd 23577 779 34 662 Korea Telecom (ATM-MPLS) 18101 753 217 31 Reliance Infocom Ltd Internet 24560 684 229 175 Bharti Airtel Ltd. 9498 644 295 51 BHARTI BT INTERNET LTD. Complete listing at http://thyme.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 4312 3653 344 bellsouth.net, inc. 209 2627 4151 621 Qwest 4323 1846 1051 376 Time Warner Telecom 1785 1752 717 139 PaeTec Communications, Inc. 20115 1603 1442 724 Charter Communications 7018 1470 5896 1018 AT&T WorldNet Services 6478 1391 308 427 AT&T Worldnet Services 2386 1260 682 909 AT&T Data Communications Serv 3356 1197 10980 452 Level 3 Communications, LLC 11492 1096 192 11 Cable One Complete listing at http://thyme.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 8452 1235 188 7 TEDATA 30890 541 88 200 Evolva Telecom 3292 454 1763 393 TDC Tele Danmark 12479 448 578 6 Uni2 Autonomous System 8866 366 109 23 Bulgarian Telecommunication C 3320 347 7082 298 Deutsche Telekom AG 3215 343 3041 108 France Telecom Transpac 3301 343 1670 307 TeliaNet Sweden 35805 332 24 4 United Telecom of Georgia 29049 321 26 3 AzerSat LLC. Complete listing at http://thyme.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 8151 1442 2847 235 UniNet S.A. de C.V. 10620 905 208 88 TVCABLE BOGOTA 22047 617 302 14 VTR PUNTO NET S.A. 7303 522 270 75 Telecom Argentina Stet-France 11830 516 294 34 Instituto Costarricense de El 11172 443 102 72 Servicios Alestra S.A de C.V 6471 442 96 31 ENTEL CHILE S.A. 28573 423 557 27 NET Servicos de Comunicao S.A 16814 409 31 10 NSS, S.A. 7738 397 794 28 Telecomunicacoes da Bahia S.A Complete listing at http://thyme.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 24863 859 79 37 LINKdotNET AS number 20858 299 34 4 This AS will be used to conne 3741 277 860 237 The Internet Solution 2018 243 215 143 Tertiary Education Network 6713 159 150 15 Itissalat Al-MAGHRIB 33783 151 10 8 EEPAD TISP TELECOM & INTERNET 29571 139 15 9 Ci Telecom Autonomous system 5536 123 8 9 Internet Egypt Network 5713 115 507 66 Telkom SA Ltd 24835 107 46 9 RAYA Telecom - Egypt 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 4312 3653 344 bellsouth.net, inc. 209 2627 4151 621 Qwest 4323 1846 1051 376 Time Warner Telecom 1785 1752 717 139 PaeTec Communications, Inc. 4766 1697 6930 402 Korea Telecom (KIX) 20115 1603 1442 724 Charter Communications 17488 1555 124 98 Hathway IP Over Cable Interne 7018 1470 5896 1018 AT&T WorldNet Services 8151 1442 2847 235 UniNet S.A. de C.V. 6478 1391 308 427 AT&T Worldnet Services Complete listing at http://thyme.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 209 2627 2006 Qwest 1785 1752 1613 PaeTec Communications, Inc. 4323 1846 1470 Time Warner Telecom 17488 1555 1457 Hathway IP Over Cable Interne 4766 1697 1295 Korea Telecom (KIX) 8452 1235 1228 TEDATA 8151 1442 1207 UniNet S.A. de C.V. 4755 1238 1114 TATA Communications formerly 11492 1096 1085 Cable One 18566 1062 1052 Covad Communications Complete listing at http://thyme.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 16927 UNALLOCATED 12.0.252.0/23 7018 AT&T WorldNet Servic 15132 UNALLOCATED 12.9.150.0/24 7018 AT&T WorldNet Servic 32567 UNALLOCATED 12.14.170.0/24 7018 AT&T WorldNet Servic 13746 UNALLOCATED 12.24.56.0/24 7018 AT&T WorldNet Servic 32567 UNALLOCATED 12.25.107.0/24 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.152.0/24 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.154.0/23 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.159.0/24 7018 AT&T WorldNet Servic 32326 UNALLOCATED 12.40.49.0/24 7018 AT&T WorldNet Servic 25639 UNALLOCATED 12.41.169.0/24 7018 AT&T WorldNet Servic Complete listing at http://thyme.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 24.75.116.0/22 10796 ServiceCo LLC - Road Runner 24.246.0.0/17 7018 AT&T WorldNet Services 24.246.128.0/18 7018 AT&T WorldNet Services 41.223.112.0/22 5713 Telkom SA Ltd 41.223.176.0/22 36981 >>UNKNOWN<< 41.223.188.0/24 22351 Intelsat 41.223.189.0/24 26452 Local Communications Networks 62.61.220.0/24 24974 Tachyon Europe BV - Wireless 62.61.221.0/24 24974 Tachyon Europe BV - Wireless 63.140.213.0/24 22555 Universal Talkware Corporatio Complete listing at http://thyme.apnic.net/current/data-add-IANA Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:19 /9:10 /10:20 /11:58 /12:166 /13:336 /14:597 /15:1147 /16:10439 /17:4716 /18:8093 /19:17101 /20:20371 /21:20238 /22:25913 /23:25432 /24:150686 /25:902 /26:1051 /27:540 /28:161 /29:37 /30:10 /31:0 /32:8 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 6389 2809 4312 bellsouth.net, inc. 4766 1391 1697 Korea Telecom (KIX) 209 1334 2627 Qwest 17488 1306 1555 Hathway IP Over Cable Interne 8452 1209 1235 TEDATA 1785 1158 1752 PaeTec Communications, Inc. 18566 1043 1062 Covad Communications 11492 1034 1096 Cable One 2386 958 1260 AT&T Data Communications Serv 4323 952 1846 Time Warner Telecom Complete listing at http://thyme.apnic.net/current/data/sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1 4:13 8:197 12:2217 13:6 15:19 16:3 17:4 20:35 24:1051 32:50 38:529 40:97 41:2006 43:1 44:2 47:22 52:4 55:2 56:3 57:25 58:577 59:635 60:459 61:1124 62:1111 63:2049 64:3669 65:2390 66:3619 67:1533 68:721 69:2583 70:533 71:145 72:1649 73:2 74:1482 75:170 76:311 77:829 78:549 79:331 80:973 81:819 82:561 83:422 84:602 85:1052 86:394 87:648 88:356 89:1455 90:47 91:2170 92:335 93:1058 94:1215 95:1145 96:123 97:201 98:465 99:17 109:1 110:89 112:114 113:101 114:230 115:250 116:1163 117:522 118:290 119:687 120:146 121:715 122:1012 123:686 124:972 125:1312 128:222 129:232 130:127 131:416 132:73 133:9 134:183 135:215 136:242 137:153 138:159 139:80 140:441 141:107 142:376 143:348 144:361 145:47 146:373 147:154 148:515 149:236 150:181 151:199 152:147 153:138 154:2 155:273 156:169 157:300 158:115 159:306 160:280 161:133 162:273 163:151 164:484 165:539 166:276 167:361 168:683 169:161 170:472 171:39 172:10 173:277 174:200 178:1 186:9 187:82 188:9 189:336 190:2643 192:5796 193:4226 194:3312 195:2686 196:1059 198:3715 199:3344 200:5424 201:1384 202:7851 203:8193 204:3815 205:2147 206:2426 207:2803 208:3912 209:3381 210:2701 211:1108 212:1514 213:1692 214:71 215:30 216:4636 217:1266 218:367 219:429 220:1211 221:470 222:293 End of report From mhuff at ox.com Fri May 1 13:27:02 2009 From: mhuff at ox.com (Matthew Huff) Date: Fri, 1 May 2009 14:27:02 -0400 Subject: 10-GigE for servers In-Reply-To: <20090501181558.GB911164@hiwaay.net> References: <81ecd7700905011055y3fd14276pbb78c2b80882da63@mail.gmail.com> <49FB39D6.9020506@blastro.com> <20090501181558.GB911164@hiwaay.net> Message-ID: <483E6B0272B0284BA86D7596C40D29F9C38082C2EB@PUR-EXCH07.ox.com> It's also host dependent. The switch will hash based on the algorithms it supports, however it can be asymmetrical if the host doesn't support the same ones. Most host OS's don't hash outbound to the switch based on layer 4 or above. Most only hash at layer 2. There are 10GE cards for most hardware and OS platforms. Getting them to run at a fraction of that speed depends on application and IP stack tuning. Even then, there are significant bottlenecks. That's one reason Infiniband for HPC has taken off. ---- 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: Chris Adams [mailto:cmadams at hiwaay.net] > Sent: Friday, May 01, 2009 2:16 PM > To: nanog at nanog.org > Subject: Re: 10-GigE for servers > > Once upon a time, Alex Thurlow said: > > As long as it's not a single connection that you're looking to get > over > > 1Gb, etherchannel should actually work. It uses a hash based on (I > > believe) source and destination IP and port, so it should roughly > > balance connections between the servers. > > That depends on the devices on each end. For example, some switches > can > only hash on MAC addresses, some can look at IPs, and some can look at > ports. > > -- > Chris Adams > Systems and Network Administrator - HiWAAY Internet Services > I don't speak for anybody but myself - that's enough trouble. From LEdouard at edrnet.com Fri May 1 13:29:24 2009 From: LEdouard at edrnet.com (LEdouard Louis) Date: Fri, 1 May 2009 14:29:24 -0400 Subject: Where to buy Internet IP addresses Message-ID: <2039ACC84D552B46A292559F7A45A1460248D298@edrmail01.southport.edr.cc> Optimum Online business only offer 5 static IP address. Where can I buy a block of Internet IP address for Business? How much does it cost? Most of our devices only require an internal IP address to reach the internet, but we have a Juniper DX for load balancing. We must provide Juniper DX with an internet IP address and point it to internal IP address for customers to be able to reach it from the internet. this is for testing and development purposes and will expect several servers on Load-balancer. The 5 static IP addresses just won't be enough. Thanks in advance Louis From sethm at rollernet.us Fri May 1 13:35:00 2009 From: sethm at rollernet.us (Seth Mattinen) Date: Fri, 01 May 2009 11:35:00 -0700 Subject: Where to buy Internet IP addresses In-Reply-To: <2039ACC84D552B46A292559F7A45A1460248D298@edrmail01.southport.edr.cc> References: <2039ACC84D552B46A292559F7A45A1460248D298@edrmail01.southport.edr.cc> Message-ID: <49FB40D4.1060305@rollernet.us> LEdouard Louis wrote: > Optimum Online business only offer 5 static IP address. > > > > Where can I buy a block of Internet IP address for Business? How much > does it cost? > > > > Most of our devices only require an internal IP address to reach the > internet, but we have a Juniper DX for load balancing. > > > > We must provide Juniper DX with an internet IP address and point it to > internal IP address for customers to be able to reach it from the > internet. this is for testing and development purposes and will expect > several servers on Load-balancer. The 5 static IP addresses just won't > be enough. > Get a different ISP. You can't "buy addresses." You can apply to your RIR for addresses, but it sounds like you wouldn't qualify if your price range is 5 statics from your ISP. Also see huge debate on arin-ppml about buying and selling addresses. ~Seth From jay at west.net Fri May 1 13:58:41 2009 From: jay at west.net (Jay Hennigan) Date: Fri, 01 May 2009 11:58:41 -0700 Subject: Where to buy Internet IP addresses In-Reply-To: <2039ACC84D552B46A292559F7A45A1460248D298@edrmail01.southport.edr.cc> References: <2039ACC84D552B46A292559F7A45A1460248D298@edrmail01.southport.edr.cc> Message-ID: <49FB4661.8090503@west.net> LEdouard Louis wrote: > Optimum Online business only offer 5 static IP address. > > Where can I buy a block of Internet IP address for Business? How much > does it cost? Only five? Really? Our basic residential users get 18 quintillion addresses, and business users get 65536 times that many. Tell them you need a few more. :-) Seriously, we do indeed provide that many addresses, but that's on a new protocol being implemented to avoid the exact problem you're having. Talk to your sales guy and see if they will assign a "/28" to you, which would give you 13 usable addresses for your hosts. If not, and you have a valid need for more space, switch ISPs. -- Jay Hennigan - CCIE #7880 - Network Engineering - jay at impulse.net Impulse Internet Service - http://www.impulse.net/ Your local telephone and internet company - 805 884-6323 - WB6RDV From nathan at robotics.net Fri May 1 13:59:23 2009 From: nathan at robotics.net (Nathan Stratton) Date: Fri, 1 May 2009 13:59:23 -0500 (CDT) Subject: 10-GigE for servers In-Reply-To: <81ecd7700905011055y3fd14276pbb78c2b80882da63@mail.gmail.com> References: <81ecd7700905011055y3fd14276pbb78c2b80882da63@mail.gmail.com> Message-ID: On Fri, 1 May 2009, Jason Shoemaker wrote: > My company is looking for ways to improve throughput for data transfers > between individual servers. We?re exploring the creation of Etherchannels > using multiple server NICs, but Etherchannel seems to have the limitation of > not supporting per-packet load-balancing, therefore limiting traffic between > two individual hosts to 1 Gig. Have you thought about Infiniband? Dual 10 gig cards cost about $50 and 24 port switches about $1200 on ebay. Infiniband has just a fraction of the latency of ethernet (even 10 get eth). You get the lowest latency if your application supports Infiniband, but if not you can run IP over IB. ><> Nathan Stratton CTO, BlinkMind, Inc. nathan at robotics.net nathan at blinkmind.com http://www.robotics.net http://www.blinkmind.com From bmanning at vacation.karoshi.com Fri May 1 14:06:41 2009 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Fri, 1 May 2009 19:06:41 +0000 Subject: Where to buy Internet IP addresses In-Reply-To: <2039ACC84D552B46A292559F7A45A1460248D298@edrmail01.southport.edr.cc> References: <2039ACC84D552B46A292559F7A45A1460248D298@edrmail01.southport.edr.cc> Message-ID: <20090501190641.GD27381@vacation.karoshi.com.> On Fri, May 01, 2009 at 02:29:24PM -0400, LEdouard Louis wrote: > Optimum Online business only offer 5 static IP address. > > > > Where can I buy a block of Internet IP address for Business? How much > does it cost? how much is Optimum Online charging you for each of the five? practically, you can not buy IP addresses. you can buy companies who have the right to use IP addresses (hard), or you can go to ARIN and justify your own "right to use" (not as hard, but then you have to deal w/ your ISP accepting routes for them), -OR- switch ISPs. if you are willing to wait for a while (12-18 months) - rumors are that folks might be able to swap/trade their IP space IRU's fairly easily... but thats just a rumor at the moment. Check the ARIN meeting minutes for the SAT mtg last week. > Thanks in advance > > Louis > --bill From darden at armc.org Fri May 1 14:10:19 2009 From: darden at armc.org (Darden, Patrick S.) Date: Fri, 1 May 2009 15:10:19 -0400 Subject: AT&T Having Difficulties--anybody know what they are? In-Reply-To: Message-ID: Athens GA, tried to call in a ticket (Metro Ethernet) and was told a master ticket was already in place for my circuits. Other than the ticket # they wouldn't give me any details. Anybody know anything? --p From LEdouard at edrnet.com Fri May 1 14:58:11 2009 From: LEdouard at edrnet.com (LEdouard Louis) Date: Fri, 1 May 2009 15:58:11 -0400 Subject: Where to buy Internet IP addresses In-Reply-To: <20090501190641.GD27381@vacation.karoshi.com.> References: <2039ACC84D552B46A292559F7A45A1460248D298@edrmail01.southport.edr.cc> <20090501190641.GD27381@vacation.karoshi.com.> Message-ID: <2039ACC84D552B46A292559F7A45A1460248D309@edrmail01.southport.edr.cc> Thanks all! I will look into the various suggestions. --Louis -----Original Message----- From: bmanning at vacation.karoshi.com [mailto:bmanning at vacation.karoshi.com] Sent: Friday, May 01, 2009 3:07 PM To: LEdouard Louis Cc: nanog at nanog.org Subject: Re: Where to buy Internet IP addresses On Fri, May 01, 2009 at 02:29:24PM -0400, LEdouard Louis wrote: > Optimum Online business only offer 5 static IP address. > > > > Where can I buy a block of Internet IP address for Business? How much > does it cost? how much is Optimum Online charging you for each of the five? practically, you can not buy IP addresses. you can buy companies who have the right to use IP addresses (hard), or you can go to ARIN and justify your own "right to use" (not as hard, but then you have to deal w/ your ISP accepting routes for them), -OR- switch ISPs. if you are willing to wait for a while (12-18 months) - rumors are that folks might be able to swap/trade their IP space IRU's fairly easily... but thats just a rumor at the moment. Check the ARIN meeting minutes for the SAT mtg last week. > Thanks in advance > > Louis > --bill From frnkblk at iname.com Fri May 1 15:09:44 2009 From: frnkblk at iname.com (Frank Bulk) Date: Fri, 1 May 2009 15:09:44 -0500 Subject: how to fix incorrect GeoIP data? In-Reply-To: References: <20090501005154.GA26724@angus.ind.WPI.EDU> <20090501042538.GE12911@angus.ind.WPI.EDU> <57F018B226E004449B318DAF71A6014656F65F9E9E@IO-SCD-EX-M-01.corp.iodatacenters.com> Message-ID: I bet each company uses a variety of methods to build their data set, not least of which is the one you mentioned. I don't think the larger (and by larger, I meant the ones with the most users) ISP community is so concerned about the accuracy of geoIP info, or even need to follow the routes we do, but there would be benefit to everyone else. And I don't think the interested members here on NANOG have the collective ability (in this virtual world) to interest any of the mentioned geoIP sites to work with us (NANOG). The most successful strategy would be for a NANOG member to work through their corporate (physical) channels to establish the relationships, and then bring the rest of NANOG on board. Sorry to rain on the parade, but face-to-face seems to be what it takes to make things like this happen. Frank -----Original Message----- From: Mikael Abrahamsson [mailto:swmike at swm.pp.se] Sent: Friday, May 01, 2009 1:06 PM To: nanog at nanog.org Subject: RE: how to fix incorrect GeoIP data? On Fri, 1 May 2009, Frank Bulk wrote: > What we need is a "master update" form where Akamai, Google, Maxmind, > hostip.info, Geobytes, ip2location, ipgeo, etc can be notified about > changes. Perhaps we as the ISP community need to realise that we need to somehow publish this data (town or something alike) via some kind of standardized API? Right now I guess they use tracking cookies together with e-commerce account registration to deduct where an IP is from? -- Mikael Abrahamsson email: swmike at swm.pp.se From morrowc.lists at gmail.com Fri May 1 15:29:56 2009 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Fri, 1 May 2009 16:29:56 -0400 Subject: how to fix incorrect GeoIP data? In-Reply-To: References: <20090501005154.GA26724@angus.ind.WPI.EDU> <20090501042538.GE12911@angus.ind.WPI.EDU> <57F018B226E004449B318DAF71A6014656F65F9E9E@IO-SCD-EX-M-01.corp.iodatacenters.com> Message-ID: <75cb24520905011329t6bb7f6fak64a1cc93b90f0b3c@mail.gmail.com> On Fri, May 1, 2009 at 2:06 PM, Mikael Abrahamsson wrote: > On Fri, 1 May 2009, Frank Bulk wrote: > >> What we need is a "master update" form where Akamai, Google, Maxmind, >> hostip.info, Geobytes, ip2location, ipgeo, etc can be notified about >> changes. > > Perhaps we as the ISP community need to realise that we need to somehow > publish this data (town or something alike) via some kind of standardized > API? hey lookie! dns TXT records!! :) > Right now I guess they use tracking cookies together with e-commerce account > registration to deduct where an IP is from? there are probably many ways to do this, sure... but if there were a standard API that was updated and accurate it might make things simpler for all involved, eh? From jlw at jlw.com Fri May 1 15:42:16 2009 From: jlw at jlw.com (Jeff Woolsey) Date: Fri, 01 May 2009 13:42:16 -0700 Subject: how to fix incorrect GeoIP data? In-Reply-To: <75cb24520905011329t6bb7f6fak64a1cc93b90f0b3c@mail.gmail.com> References: <20090501005154.GA26724@angus.ind.WPI.EDU> <20090501042538.GE12911@angus.ind.WPI.EDU> <57F018B226E004449B318DAF71A6014656F65F9E9E@IO-SCD-EX-M-01.corp.iodatacenters.com> <75cb24520905011329t6bb7f6fak64a1cc93b90f0b3c@mail.gmail.com> Message-ID: <49FB5EA8.7060700@jlw.com> Christopher Morrow wrote: > > hey lookie! dns TXT records!! :) > > dns LOC records. -- Jeff Woolsey {woolsey,jlw}@jlw.com,first.last at gmail.com Nature abhors a straight antenna, a clean lens, and unused storage capacity. "Delete! Delete! OK!" -Dr. Bronner on disk space management From wmaton at ryouko.imsb.nrc.ca Fri May 1 15:43:59 2009 From: wmaton at ryouko.imsb.nrc.ca (William F. Maton Sotomayor) Date: Fri, 1 May 2009 16:43:59 -0400 (EDT) Subject: how to fix incorrect GeoIP data? In-Reply-To: <75cb24520905011329t6bb7f6fak64a1cc93b90f0b3c@mail.gmail.com> References: <20090501005154.GA26724@angus.ind.WPI.EDU> <20090501042538.GE12911@angus.ind.WPI.EDU> <57F018B226E004449B318DAF71A6014656F65F9E9E@IO-SCD-EX-M-01.corp.iodatacenters.com> <75cb24520905011329t6bb7f6fak64a1cc93b90f0b3c@mail.gmail.com> Message-ID: On Fri, 1 May 2009, Christopher Morrow wrote: > On Fri, May 1, 2009 at 2:06 PM, Mikael Abrahamsson wrote: >> On Fri, 1 May 2009, Frank Bulk wrote: >> >>> What we need is a "master update" form where Akamai, Google, Maxmind, >>> hostip.info, Geobytes, ip2location, ipgeo, etc can be notified about >>> changes. >> >> Perhaps we as the ISP community need to realise that we need to somehow >> publish this data (town or something alike) via some kind of standardized >> API? > > hey lookie! dns TXT records!! :) LOC records too. :-) dig @prisoner.iana.org hostname.as112.net any ;; QUESTION SECTION: ;hostname.as112.net. IN ANY ;; ANSWER SECTION: hostname.as112.net. 604800 IN SOA as112.gigafed.net. dns.ryouko.imsb.nrc.ca. 1 604800 60 604800 604800 hostname.as112.net. 604800 IN LOC 45 25 0.000 N 75 42 0.000 W 80.00m 1m 10000m 10m Helpful for folks like CAIDA too. wfms From swmike at swm.pp.se Fri May 1 16:13:29 2009 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Fri, 1 May 2009 23:13:29 +0200 (CEST) Subject: how to fix incorrect GeoIP data? In-Reply-To: References: <20090501005154.GA26724@angus.ind.WPI.EDU> <20090501042538.GE12911@angus.ind.WPI.EDU> <57F018B226E004449B318DAF71A6014656F65F9E9E@IO-SCD-EX-M-01.corp.iodatacenters.com> <75cb24520905011329t6bb7f6fak64a1cc93b90f0b3c@mail.gmail.com> Message-ID: On Fri, 1 May 2009, William F. Maton Sotomayor wrote: > LOC records too. :-) > > dig @prisoner.iana.org hostname.as112.net any Have this seen any widespread use? I mean, there needs to be tens of percent of users having these before they'll get used by the GeoIP people. -- Mikael Abrahamsson email: swmike at swm.pp.se From beckman at angryox.com Fri May 1 16:23:11 2009 From: beckman at angryox.com (Peter Beckman) Date: Fri, 1 May 2009 17:23:11 -0400 Subject: how to fix incorrect GeoIP data? In-Reply-To: References: <20090501005154.GA26724@angus.ind.WPI.EDU> <20090501042538.GE12911@angus.ind.WPI.EDU> <57F018B226E004449B318DAF71A6014656F65F9E9E@IO-SCD-EX-M-01.corp.iodatacenters.com> <75cb24520905011329t6bb7f6fak64a1cc93b90f0b3c@mail.gmail.com> Message-ID: On Fri, 1 May 2009, Mikael Abrahamsson wrote: > On Fri, 1 May 2009, William F. Maton Sotomayor wrote: > >> LOC records too. :-) >> >> dig @prisoner.iana.org hostname.as112.net any > > Have this seen any widespread use? I mean, there needs to be tens of percent > of users having these before they'll get used by the GeoIP people. People who are evil (or people seeking privacy) will intentionally put bad data, thus ruining the whole thing. I don't think self-reporting is the answer. You MIGHT be able to determine location based on a traceroute, though anycast would surely derail such attempts. I suspect most people rely on 3rd party GeoIP databases, and that those companies aren't interested in hearing from you about your location change, mostly because they are worried that if they do, the evildoers will overrun them with bad requests, or bait and switch, making their data less accurate than it is now without your block being correct. Which I can understand. --------------------------------------------------------------------------- Peter Beckman Internet Guy beckman at angryox.com http://www.angryox.com/ --------------------------------------------------------------------------- From frnkblk at iname.com Fri May 1 16:39:17 2009 From: frnkblk at iname.com (Frank Bulk) Date: Fri, 1 May 2009 16:39:17 -0500 Subject: how to fix incorrect GeoIP data? In-Reply-To: References: <20090501005154.GA26724@angus.ind.WPI.EDU> <20090501042538.GE12911@angus.ind.WPI.EDU> <57F018B226E004449B318DAF71A6014656F65F9E9E@IO-SCD-EX-M-01.corp.iodatacenters.com> <75cb24520905011329t6bb7f6fak64a1cc93b90f0b3c@mail.gmail.com> Message-ID: I wouldn't mind create LOC records for our IP address ranges, but doesn't make much sense if the "GeoIP people" don't look at it or care. Hence the need for someone who is relevant to them to open the dialog. I've never received a negative comment when submitting a correction request to "GeoIP people". Of course, they don't make it really easy to do so and it seems that half the time it needs to be done via back-channels. Of course the "GeoIP people" are going to vet the submissions, but if existing entry is Spain or Germany and the traceroute shows that the previous hop was somewhere in the US midwest, I think they can figure it out. =) I'm sure they have mechanisms to track changes and new allocations, but some things will slip through the cracks or in the case of use sales data, be delayed. The process that I'm suggesting is for corrective action, not to be the basis for the "GeoIP people" to build their database. That's why I'm suggesting a comprehensive form that gets sent to all the "GeoIP people". It's a way they can receive requests in a systematic way that can help them improve the accuracy of their database. Frank -----Original Message----- From: Peter Beckman [mailto:beckman at angryox.com] Sent: Friday, May 01, 2009 4:23 PM To: Mikael Abrahamsson Cc: nanog at nanog.org Subject: Re: how to fix incorrect GeoIP data? On Fri, 1 May 2009, Mikael Abrahamsson wrote: > On Fri, 1 May 2009, William F. Maton Sotomayor wrote: > >> LOC records too. :-) >> >> dig @prisoner.iana.org hostname.as112.net any > > Have this seen any widespread use? I mean, there needs to be tens of percent > of users having these before they'll get used by the GeoIP people. People who are evil (or people seeking privacy) will intentionally put bad data, thus ruining the whole thing. I don't think self-reporting is the answer. You MIGHT be able to determine location based on a traceroute, though anycast would surely derail such attempts. I suspect most people rely on 3rd party GeoIP databases, and that those companies aren't interested in hearing from you about your location change, mostly because they are worried that if they do, the evildoers will overrun them with bad requests, or bait and switch, making their data less accurate than it is now without your block being correct. Which I can understand. --------------------------------------------------------------------------- Peter Beckman Internet Guy beckman at angryox.com http://www.angryox.com/ --------------------------------------------------------------------------- From blakjak at blakjak.net Fri May 1 16:58:08 2009 From: blakjak at blakjak.net (Mark Foster) Date: Sat, 2 May 2009 09:58:08 +1200 (NZST) Subject: how to fix incorrect GeoIP data? In-Reply-To: References: <20090501005154.GA26724@angus.ind.WPI.EDU> <20090501042538.GE12911@angus.ind.WPI.EDU> <57F018B226E004449B318DAF71A6014656F65F9E9E@IO-SCD-EX-M-01.corp.iodatacenters.com> <75cb24520905011329t6bb7f6fak64a1cc93b90f0b3c@mail.gmail.com> Message-ID: > I don't think self-reporting is the answer. > > You MIGHT be able to determine location based on a traceroute, though > anycast would surely derail such attempts. I suspect most people rely on > 3rd party GeoIP databases, and that those companies aren't interested in > hearing from you about your location change, mostly because they are > worried that if they do, the evildoers will overrun them with bad > requests, or bait and switch, making their data less accurate than it is > now without your block being correct. > Having recently leapt through a few GeoIP hoops to see about getting records fixed[1], perhaps the NANOG wiki could feature 'known ways to fix GeoIP' and be used as a reference? Seems to be something that's going to be more, not less, significant to customers and network operators alike going forward. Mark. [1] http://www.merit.edu/mail.archives/nanog/msg13895.html From randy at psg.com Fri May 1 17:12:59 2009 From: randy at psg.com (Randy Bush) Date: Fri, 01 May 2009 17:12:59 -0500 Subject: how to fix incorrect GeoIP data? In-Reply-To: <75cb24520905011329t6bb7f6fak64a1cc93b90f0b3c@mail.gmail.com> References: <20090501005154.GA26724@angus.ind.WPI.EDU> <20090501042538.GE12911@angus.ind.WPI.EDU> <57F018B226E004449B318DAF71A6014656F65F9E9E@IO-SCD-EX-M-01.corp.iodatacenters.com> <75cb24520905011329t6bb7f6fak64a1cc93b90f0b3c@mail.gmail.com> Message-ID: >> Perhaps we as the ISP community need to realise that we need to somehow >> publish this data (town or something alike) via some kind of standardized >> API? > hey lookie! dns TXT records!! :) LOC randy From patrick at ianai.net Fri May 1 18:15:12 2009 From: patrick at ianai.net (Patrick W. Gilmore) Date: Fri, 1 May 2009 19:15:12 -0400 Subject: how to fix incorrect GeoIP data? In-Reply-To: References: <20090501005154.GA26724@angus.ind.WPI.EDU> <20090501042538.GE12911@angus.ind.WPI.EDU> <57F018B226E004449B318DAF71A6014656F65F9E9E@IO-SCD-EX-M-01.corp.iodatacenters.com> <75cb24520905011329t6bb7f6fak64a1cc93b90f0b3c@mail.gmail.com> Message-ID: <8E346B69-01AC-4D79-A1F3-AB00A1DB4A5D@ianai.net> > Of course the "GeoIP people" are going to vet the submissions, but if > existing entry is Spain or Germany and the traceroute shows that the > previous hop was somewhere in the US midwest, I think they can > figure it > out. =) The "hop before it" is not necessarily a good indication these days with MPLS tunnels. There is this thing called the Speed Of Light. It's very annoying most of the time, but it can be useful for geo location if you have multiple vantage points to ping / trace to a destination. The return packet can be delayed infinitely, but it cannot be sped up past c. Really about 0.666c if you believe the path is in fiber, which I personally believe is a useful assumption for every path on the 'Net to several decimal places (since things like satellite hops, while not in fiber, will give your far higher latency, and microwave just is not used enough to matter). If you ping something from San Jose and get a response in under 50 ms, the machine which sent the reply packet _cannot_ be in Germany or China. Those pesky Laws of Physics get in the way.[*] What's more, if you ping the same destination from, say, Los Angeles and Boston, and each test returns in 40 ms, you now have narrowed the possible locations down quite a bit. There are always exceptions, but sometimes they are obvious. Pinging the same destination from LAX & BOS and getting 5 ms each... well, that's obviously anycast (or a broken test). Fortunately, most destinations are unicast and stationary, so there are ways to narrow down the location using tools like this. -- TTFN, patrick [*] Technically it's the Theory of Relativity which gets in the way. This means some people will argue I am wrong because it is "only a theory" and not proven fact. Hopefully no NANOG reader has ever used lines like "it is only a theory" against "theories" which are better proven than some "laws" (e.g. the Law of Gravity, which, as it turns out, is wrong). On May 1, 2009, at 5:39 PM, Frank Bulk wrote: > I wouldn't mind create LOC records for our IP address ranges, but > doesn't > make much sense if the "GeoIP people" don't look at it or care. > Hence the > need for someone who is relevant to them to open the dialog. > > I've never received a negative comment when submitting a correction > request > to "GeoIP people". Of course, they don't make it really easy to do > so and > it seems that half the time it needs to be done via back-channels. > > Of course the "GeoIP people" are going to vet the submissions, but if > existing entry is Spain or Germany and the traceroute shows that the > previous hop was somewhere in the US midwest, I think they can > figure it > out. =) I'm sure they have mechanisms to track changes and new > allocations, > but some things will slip through the cracks or in the case of use > sales > data, be delayed. > > The process that I'm suggesting is for corrective action, not to be > the > basis for the "GeoIP people" to build their database. That's why I'm > suggesting a comprehensive form that gets sent to all the "GeoIP > people". > It's a way they can receive requests in a systematic way that can > help them > improve the accuracy of their database. > > Frank > > -----Original Message----- > From: Peter Beckman [mailto:beckman at angryox.com] > Sent: Friday, May 01, 2009 4:23 PM > To: Mikael Abrahamsson > Cc: nanog at nanog.org > Subject: Re: how to fix incorrect GeoIP data? > > On Fri, 1 May 2009, Mikael Abrahamsson wrote: > >> On Fri, 1 May 2009, William F. Maton Sotomayor wrote: >> >>> LOC records too. :-) >>> >>> dig @prisoner.iana.org hostname.as112.net any >> >> Have this seen any widespread use? I mean, there needs to be tens of > percent >> of users having these before they'll get used by the GeoIP people. > > People who are evil (or people seeking privacy) will intentionally > put bad > data, thus ruining the whole thing. > > I don't think self-reporting is the answer. > > You MIGHT be able to determine location based on a traceroute, though > anycast would surely derail such attempts. I suspect most people > rely on > 3rd party GeoIP databases, and that those companies aren't > interested in > hearing from you about your location change, mostly because they are > worried that if they do, the evildoers will overrun them with bad > requests, or bait and switch, making their data less accurate than > it is > now without your block being correct. > > Which I can understand. > > --------------------------------------------------------------------------- > Peter Beckman > Internet Guy > beckman at angryox.com http://www.angryox.com/ > --------------------------------------------------------------------------- > > > From Mark_Andrews at isc.org Fri May 1 18:40:23 2009 From: Mark_Andrews at isc.org (Mark Andrews) Date: Sat, 02 May 2009 09:40:23 +1000 Subject: Where to buy Internet IP addresses In-Reply-To: Your message of "Fri, 01 May 2009 11:58:41 MST." <49FB4661.8090503@west.net> Message-ID: <200905012340.n41NeNKD093855@drugs.dv.isc.org> In message <49FB4661.8090503 at west.net>, Jay Hennigan writes: > LEdouard Louis wrote: > > Optimum Online business only offer 5 static IP address. > > > > Where can I buy a block of Internet IP address for Business? How much > > does it cost? > > Only five? Really? Our basic residential users get 18 quintillion > addresses, and business users get 65536 times that many. Tell them you > need a few more. :-) Actually residential users do. One /64 is not enough. On can argue about whether a /56 or a /48 is appropriate for residential users but a single /64 isn't and residential ISP's should be planning to hand out more than a single /64 to their customers. > Seriously, we do indeed provide that many addresses, but that's on a new > protocol being implemented to avoid the exact problem you're having. > > Talk to your sales guy and see if they will assign a "/28" to you, which > would give you 13 usable addresses for your hosts. If not, and you have > a valid need for more space, switch ISPs. > > -- > Jay Hennigan - CCIE #7880 - Network Engineering - jay at impulse.net > Impulse Internet Service - http://www.impulse.net/ > Your local telephone and internet company - 805 884-6323 - WB6RDV > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews at isc.org From mpalmer at hezmatt.org Fri May 1 19:24:06 2009 From: mpalmer at hezmatt.org (Matthew Palmer) Date: Sat, 2 May 2009 10:24:06 +1000 Subject: Where to buy Internet IP addresses In-Reply-To: <200905012340.n41NeNKD093855@drugs.dv.isc.org> References: <49FB4661.8090503@west.net> <200905012340.n41NeNKD093855@drugs.dv.isc.org> Message-ID: <20090502002406.GK4507@hezmatt.org> On Sat, May 02, 2009 at 09:40:23AM +1000, Mark Andrews wrote: > > In message <49FB4661.8090503 at west.net>, Jay Hennigan writes: > > LEdouard Louis wrote: > > > Optimum Online business only offer 5 static IP address. > > > > > > Where can I buy a block of Internet IP address for Business? How much > > > does it cost? > > > > Only five? Really? Our basic residential users get 18 quintillion > > addresses, and business users get 65536 times that many. Tell them you > > need a few more. :-) > > Actually residential users do. One /64 is not enough. On > can argue about whether a /56 or a /48 is appropriate for > residential users but a single /64 isn't and residential > ISP's should be planning to hand out more than a single /64 > to their customers. How many home users (or even small businesses) have more than one subnet at the moment (behind NAT, presumably)? As a percentage of subscribers, what does that equate to? Handing out an IPv6 /56 to a DSL or cable customer should be handled much the same way as giving them an IPv4 /29 is today -- ask, and it shall be provided, but it's wasteful[1] to do so by default. - Matt [1] Just because we've got a lot of it, doesn't mean we should be pissing it up against the wall unnecessarily. A motto for network engineers and economists alike. -- [M]ost of the other people here [...] drive cars that they have personally built (starting with iron ore, charcoal, and a Malaysian turn-signal tree) [...] but I wimp out on all of those points. Sometimes there are advantages to paying somebody else to do it for you. -- Matt Roberds, in the Monastery From sethm at rollernet.us Fri May 1 19:57:42 2009 From: sethm at rollernet.us (Seth Mattinen) Date: Fri, 01 May 2009 17:57:42 -0700 Subject: Where to buy Internet IP addresses In-Reply-To: <200905012340.n41NeNKD093855@drugs.dv.isc.org> References: <200905012340.n41NeNKD093855@drugs.dv.isc.org> Message-ID: <49FB9A86.1080101@rollernet.us> Mark Andrews wrote: > In message <49FB4661.8090503 at west.net>, Jay Hennigan writes: >> LEdouard Louis wrote: >>> Optimum Online business only offer 5 static IP address. >>> >>> Where can I buy a block of Internet IP address for Business? How much >>> does it cost? >> Only five? Really? Our basic residential users get 18 quintillion >> addresses, and business users get 65536 times that many. Tell them you >> need a few more. :-) > > Actually residential users do. One /64 is not enough. On > can argue about whether a /56 or a /48 is appropriate for > residential users but a single /64 isn't and residential > ISP's should be planning to hand out more than a single /64 > to their customers. > I hear this a lot, but how many "linksys default channel 6" end users really have more than one subnet, or even know what a subnet is? ~Seth From mike.lyon at gmail.com Fri May 1 19:59:33 2009 From: mike.lyon at gmail.com (Mike Lyon) Date: Fri, 1 May 2009 17:59:33 -0700 Subject: Slightly OT: Calculating HVAC requirements for server rooms Message-ID: <1b5c1c150905011759p6b6a31berf8f0afc2bc7e2125@mail.gmail.com> Hello All, I am curious what formulas/equations folks use to figure out required cooling for small datacenters in offices. The variables I am using are the size of the room, the total amount of power available for usage and the lightning. Specifically, I am using the guide posted at: http://www.openxtra.co.uk/articles/calculating-heat-load Any other recommendations or suggestions from those folks that have done this before? Thank You in advance. Cheers, Mike From davids at webmaster.com Fri May 1 20:11:29 2009 From: davids at webmaster.com (David Schwartz) Date: Fri, 1 May 2009 18:11:29 -0700 Subject: Where to buy Internet IP addresses In-Reply-To: <49FB9A86.1080101@rollernet.us> Message-ID: > I hear this a lot, but how many "linksys default channel 6" end users > really have more than one subnet, or even know what a subnet is? > > ~Seth Wrong question. The right question is, how many would if reachable address scarcity weren't a factor. DS From sethm at rollernet.us Fri May 1 20:18:15 2009 From: sethm at rollernet.us (Seth Mattinen) Date: Fri, 01 May 2009 18:18:15 -0700 Subject: Where to buy Internet IP addresses In-Reply-To: References: Message-ID: <49FB9F57.7060300@rollernet.us> David Schwartz wrote: >> I hear this a lot, but how many "linksys default channel 6" end users >> really have more than one subnet, or even know what a subnet is? >> >> ~Seth > > Wrong question. The right question is, how many would if reachable address scarcity weren't a factor. > They're reachable right now as long as you're in radio range. ~Seth From hescominsoon at emmanuelcomputerconsulting.com Fri May 1 20:32:19 2009 From: hescominsoon at emmanuelcomputerconsulting.com (William Warren) Date: Fri, 01 May 2009 21:32:19 -0400 Subject: Slightly OT: Calculating HVAC requirements for server rooms In-Reply-To: <1b5c1c150905011759p6b6a31berf8f0afc2bc7e2125@mail.gmail.com> References: <1b5c1c150905011759p6b6a31berf8f0afc2bc7e2125@mail.gmail.com> Message-ID: <49FBA2A3.3030401@emmanuelcomputerconsulting.com> Mike Lyon wrote: > Hello All, > > I am curious what formulas/equations folks use to figure out required > cooling for small datacenters in offices. > > The variables I am using are the size of the room, the total amount of power > available for usage and the lightning. > > Specifically, I am using the guide posted at: > http://www.openxtra.co.uk/articles/calculating-heat-load > > Any other recommendations or suggestions from those folks that have done > this before? > > Thank You in advance. > > Cheers, > Mike > > You also have to take into account the environment surrounding the data room. At my wife's work The ceiling above is only separated with a false ceiling to the metal roof above but the rest of hte spaces surrounding the room are climate controled. They ahd to significantly upsize to account for the heat load of that ceiling. From joelja at bogus.com Fri May 1 20:46:02 2009 From: joelja at bogus.com (Joel Jaeggli) Date: Fri, 01 May 2009 18:46:02 -0700 Subject: Where to buy Internet IP addresses In-Reply-To: <49FB9A86.1080101@rollernet.us> References: <200905012340.n41NeNKD093855@drugs.dv.isc.org> <49FB9A86.1080101@rollernet.us> Message-ID: <49FBA5DA.2020707@bogus.com> Seth Mattinen wrote: > > I hear this a lot, but how many "linksys default channel 6" end users > really have more than one subnet, or even know what a subnet is? By definition, every single one of them that buys wireless router, then buys another and hangs it off the first. That happens more often then you would think. > ~Seth > From frnkblk at iname.com Fri May 1 21:13:52 2009 From: frnkblk at iname.com (Frank Bulk) Date: Fri, 1 May 2009 21:13:52 -0500 Subject: Where to buy Internet IP addresses In-Reply-To: <49FBA5DA.2020707@bogus.com> References: <200905012340.n41NeNKD093855@drugs.dv.isc.org> <49FB9A86.1080101@rollernet.us> <49FBA5DA.2020707@bogus.com> Message-ID: At our helpdesk we hear customers hanging their wireless router off their NATed PPPoA DSL modem all the time, such that its double-NATed. That things work as well as they do is a testament to the resiliency of IP (and applications and servers) in the face of NAT. Frank -----Original Message----- From: Joel Jaeggli [mailto:joelja at bogus.com] Sent: Friday, May 01, 2009 8:46 PM To: Seth Mattinen Cc: nanog at nanog.org Subject: Re: Where to buy Internet IP addresses Seth Mattinen wrote: > > I hear this a lot, but how many "linksys default channel 6" end users > really have more than one subnet, or even know what a subnet is? By definition, every single one of them that buys wireless router, then buys another and hangs it off the first. That happens more often then you would think. > ~Seth > From Mark_Andrews at isc.org Fri May 1 21:25:03 2009 From: Mark_Andrews at isc.org (Mark Andrews) Date: Sat, 02 May 2009 12:25:03 +1000 Subject: Where to buy Internet IP addresses In-Reply-To: Your message of "Sat, 02 May 2009 10:24:06 +1000." <20090502002406.GK4507@hezmatt.org> Message-ID: <200905020225.n422P3iq094988@drugs.dv.isc.org> In message <20090502002406.GK4507 at hezmatt.org>, Matthew Palmer writes: > On Sat, May 02, 2009 at 09:40:23AM +1000, Mark Andrews wrote: > > > > In message <49FB4661.8090503 at west.net>, Jay Hennigan writes: > > > LEdouard Louis wrote: > > > > Optimum Online business only offer 5 static IP address. > > > > > > > > Where can I buy a block of Internet IP address for Business? How much > > > > does it cost? > > > > > > Only five? Really? Our basic residential users get 18 quintillion > > > addresses, and business users get 65536 times that many. Tell them you > > > need a few more. :-) > > > > Actually residential users do. One /64 is not enough. On > > can argue about whether a /56 or a /48 is appropriate for > > residential users but a single /64 isn't and residential > > ISP's should be planning to hand out more than a single /64 > > to their customers. > > How many home users (or even small businesses) have more than one subnet at > the moment (behind NAT, presumably)? As a percentage of subscribers, what > does that equate to? I know on quite a few none geek households that have multiple nets today using double or triple NAT. These households will be your multi-subnet IPv6 customers. The NAT boxes will be replaced with ones that do DHCPv6 PD (both up and down stream). > Handing out an IPv6 /56 to a DSL or cable customer should be handled much > the same way as giving them an IPv4 /29 is today -- ask, and it shall be > provided, but it's wasteful[1] to do so by default. One won't hand out a /56. Think about how the above CPE boxes will work with PD. You will get multiple /64 requests from the border CPE box with different IAID on them, one for each subnet in use. The border CPE box could also consolidate the requests from downstream if it so desired but I would expect that would not be the default configuration. Mark > - Matt > > [1] Just because we've got a lot of it, doesn't mean we should be pissing it > up against the wall unnecessarily. A motto for network engineers and > economists alike. > -- > [M]ost of the other people here [...] drive cars that they have personally > built (starting with iron ore, charcoal, and a Malaysian turn-signal tree) > [...] but I wimp out on all of those points. Sometimes there are advantages > to paying somebody else to do it for you. -- Matt Roberds, in the Monastery > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews at isc.org From jbates at brightok.net Fri May 1 21:52:45 2009 From: jbates at brightok.net (Jack Bates) Date: Fri, 01 May 2009 21:52:45 -0500 Subject: Where to buy Internet IP addresses In-Reply-To: References: Message-ID: <49FBB57D.9030409@brightok.net> David Schwartz wrote: >> I hear this a lot, but how many "linksys default channel 6" end users >> really have more than one subnet, or even know what a subnet is? >> >> ~Seth > > Wrong question. The right question is, how many would if reachable address scarcity weren't a factor. > Also the wrong question. The question will become, what will the home routers support. The most common expectation of home routers will decide the defaults for most ISPs. One thing I currently dislike with implementations (and probably in the spec, though I haven't checked), is lack of support for variable PD requests. Sure, it's possible to configure radius to hand out specific prefixes, but what about variability. Many households will only need a single /64, while some will need a /60 (being nice on the nibbles). A more dynamic protocol would have been nice given that they were redesigning everything. That way a router needing only one subnet could request a /64, and then another router hooked up behind it could request a /64 proxied through the first, or perhaps when the second router asks the first, it renumbers asking for a /63, which the ISP might instead respond with a /60. A boy can dream. Jack From jfbeam at gmail.com Fri May 1 23:06:29 2009 From: jfbeam at gmail.com (Ricky Beam) Date: Sat, 02 May 2009 00:06:29 -0400 Subject: Slightly OT: Calculating HVAC requirements for server rooms In-Reply-To: <49FBA2A3.3030401@emmanuelcomputerconsulting.com> References: <1b5c1c150905011759p6b6a31berf8f0afc2bc7e2125@mail.gmail.com> <49FBA2A3.3030401@emmanuelcomputerconsulting.com> Message-ID: On Fri, 01 May 2009 21:32:19 -0400, William Warren wrote: >> Specifically, I am using the guide posted at: >> http://www.openxtra.co.uk/articles/calculating-heat-load "Before you decide on an air conditioning unit you should commission an audit from a suitably qualified air conditioning equipment specialist or installer." Translation: Hire a f***ing professional. And that's exactly what you need to do. Qualified HVAC installers (with specific data center experience) will know far more than us "network types" will ever want to know about cooling. They do this for a living, and thus, know all the tiny details and odd edge cases to look for. (like looking above the drop ceiling -- that's what it's called, btw -- and seeing what's up there long before pencil meets paper (not that anyone uses paper anymore.)) > You also have to take into account the environment surrounding the data > room. At my wife's work The ceiling above is only separated with a > false ceiling to the metal roof above but the rest of hte spaces > surrounding the room are climate controled. They [had] to significantly > upsize to account for the heat load of that ceiling. Unless you are pulling air through the plenum (that space above the drop ceiling), the air up there shouldn't matter much -- there should be plenum returns up there to begin with venting the air to the surrounding plenum(s) (i.e. the rest of the office, hallway, neighboring office, etc.) However, I've seen more than enough office setups where the "engineers" planning the space completely ignore the plenum. In my current office building the static pressure pushes the bathroom doors open by almost 2". And they placed our server room directly under the building air handlers -- meaning all the air on the 3rd floor eventually passes through the plenum above my servers. (also, the sprinkler system riser room is in there.) Bottom line, again, ask a professional. NANOG is a bunch of network geeks (in theory.) I'd be surprised if there's even one licensed HVAC "geek" on the list. ('tho I'm sure many may *know* an HVAC engineer.) --Ricky From sethm at rollernet.us Fri May 1 23:22:24 2009 From: sethm at rollernet.us (Seth Mattinen) Date: Fri, 01 May 2009 21:22:24 -0700 Subject: Slightly OT: Calculating HVAC requirements for server rooms In-Reply-To: References: <1b5c1c150905011759p6b6a31berf8f0afc2bc7e2125@mail.gmail.com> <49FBA2A3.3030401@emmanuelcomputerconsulting.com> Message-ID: <49FBCA80.6060607@rollernet.us> Ricky Beam wrote: > On Fri, 01 May 2009 21:32:19 -0400, William Warren > wrote: >>> Specifically, I am using the guide posted at: >>> http://www.openxtra.co.uk/articles/calculating-heat-load > > "Before you decide on an air conditioning unit you should commission an > audit from a suitably qualified air conditioning equipment specialist or > installer." > > Translation: Hire a f***ing professional. > > And that's exactly what you need to do. Qualified HVAC installers (with > specific data center experience) will know far more than us "network > types" will ever want to know about cooling. They do this for a living, > and thus, know all the tiny details and odd edge cases to look for. > (like looking above the drop ceiling -- that's what it's called, btw -- > and seeing what's up there long before pencil meets paper (not that > anyone uses paper anymore.)) > >> You also have to take into account the environment surrounding the >> data room. At my wife's work The ceiling above is only separated with >> a false ceiling to the metal roof above but the rest of hte spaces >> surrounding the room are climate controled. They [had] to >> significantly upsize to account for the heat load of that ceiling. > > Unless you are pulling air through the plenum (that space above the drop > ceiling), the air up there shouldn't matter much -- there should be > plenum returns up there to begin with venting the air to the surrounding > plenum(s) (i.e. the rest of the office, hallway, neighboring office, > etc.) However, I've seen more than enough office setups where the > "engineers" planning the space completely ignore the plenum. In my > current office building the static pressure pushes the bathroom doors > open by almost 2". And they placed our server room directly under the > building air handlers -- meaning all the air on the 3rd floor eventually > passes through the plenum above my servers. (also, the sprinkler system > riser room is in there.) The space above the drop ceiling is only a plenum if it's used as air handling space opposed to ducting the returns everywhere. If it's not an air handling space, it's not a plenum, it's just where spiders might be. It's easier to throw grated panels in all over the place for returns in large systems. Now, back on topic, plus nifty graphics explaining the difference: http://en.wikipedia.org/wiki/Plenum_cable > Bottom line, again, ask a professional. NANOG is a bunch of network > geeks (in theory.) I'd be surprised if there's even one licensed HVAC > "geek" on the list. ('tho I'm sure many may *know* an HVAC engineer.) But yes, please, don't learn how to make your own system from what we say here. HVAC systems are their own world. You wouldn't want an HVAC guy designing your network just because he's seen a lot of server rooms, would you? ~Seth From web at typo.org Fri May 1 23:26:37 2009 From: web at typo.org (Wayne E. Bouchard) Date: Fri, 1 May 2009 21:26:37 -0700 Subject: Slightly OT: Calculating HVAC requirements for server rooms In-Reply-To: <49FBCA80.6060607@rollernet.us> References: <1b5c1c150905011759p6b6a31berf8f0afc2bc7e2125@mail.gmail.com> <49FBA2A3.3030401@emmanuelcomputerconsulting.com> <49FBCA80.6060607@rollernet.us> Message-ID: <20090502042637.GA45183@typo.org> While all the below is true, I would put forward that many of us networking types, especially those who operate their own datacenters, generally know how to do an approximation. Afterall, if you don't have an idea of magnitude, if you haven't done your homework, your conversation with that professional will not go well. So it is appropriate for someone being tasked with researching cooling for a datacenter to learn how to do these approximations. My $0.73. (inflations's a bear.) -Wayne On Fri, May 01, 2009 at 09:22:24PM -0700, Seth Mattinen wrote: > Ricky Beam wrote: > > On Fri, 01 May 2009 21:32:19 -0400, William Warren > > wrote: > >>> Specifically, I am using the guide posted at: > >>> http://www.openxtra.co.uk/articles/calculating-heat-load > > > > "Before you decide on an air conditioning unit you should commission an > > audit from a suitably qualified air conditioning equipment specialist or > > installer." > > > > Translation: Hire a f***ing professional. > > > > And that's exactly what you need to do. Qualified HVAC installers (with > > specific data center experience) will know far more than us "network > > types" will ever want to know about cooling. They do this for a living, > > and thus, know all the tiny details and odd edge cases to look for. > > (like looking above the drop ceiling -- that's what it's called, btw -- > > and seeing what's up there long before pencil meets paper (not that > > anyone uses paper anymore.)) > > > >> You also have to take into account the environment surrounding the > >> data room. At my wife's work The ceiling above is only separated with > >> a false ceiling to the metal roof above but the rest of hte spaces > >> surrounding the room are climate controled. They [had] to > >> significantly upsize to account for the heat load of that ceiling. > > > > Unless you are pulling air through the plenum (that space above the drop > > ceiling), the air up there shouldn't matter much -- there should be > > plenum returns up there to begin with venting the air to the surrounding > > plenum(s) (i.e. the rest of the office, hallway, neighboring office, > > etc.) However, I've seen more than enough office setups where the > > "engineers" planning the space completely ignore the plenum. In my > > current office building the static pressure pushes the bathroom doors > > open by almost 2". And they placed our server room directly under the > > building air handlers -- meaning all the air on the 3rd floor eventually > > passes through the plenum above my servers. (also, the sprinkler system > > riser room is in there.) > > The space above the drop ceiling is only a plenum if it's used as air > handling space opposed to ducting the returns everywhere. If it's not an > air handling space, it's not a plenum, it's just where spiders might be. > It's easier to throw grated panels in all over the place for returns in > large systems. > > Now, back on topic, plus nifty graphics explaining the difference: > > http://en.wikipedia.org/wiki/Plenum_cable > > > > Bottom line, again, ask a professional. NANOG is a bunch of network > > geeks (in theory.) I'd be surprised if there's even one licensed HVAC > > "geek" on the list. ('tho I'm sure many may *know* an HVAC engineer.) > > But yes, please, don't learn how to make your own system from what we > say here. HVAC systems are their own world. You wouldn't want an HVAC > guy designing your network just because he's seen a lot of server rooms, > would you? > > ~Seth --- Wayne Bouchard web at typo.org Network Dude http://www.typo.org/~web/ From jfbeam at gmail.com Fri May 1 23:55:32 2009 From: jfbeam at gmail.com (Ricky Beam) Date: Sat, 02 May 2009 00:55:32 -0400 Subject: Slightly OT: Calculating HVAC requirements for server rooms In-Reply-To: <20090502042637.GA45183@typo.org> References: <1b5c1c150905011759p6b6a31berf8f0afc2bc7e2125@mail.gmail.com> <49FBA2A3.3030401@emmanuelcomputerconsulting.com> <49FBCA80.6060607@rollernet.us> <20090502042637.GA45183@typo.org> Message-ID: On Sat, 02 May 2009 00:26:37 -0400, Wayne E. Bouchard wrote: > ... approximation Even an approximation is hard to make. One might think the simple math of "how much power is fed into the room" would do, but it ignores numerous factors that greatly effect the answer. I can rattle off example after example, but it's unnecessary. You'll need professionals to install the hardware, so there's no point not calling them in for a consult. (And the elephant in the room no one has mentioned is "air flow". Cooling capacity is only half the equation. Air flow *volume* is just as important.) --Ricky From swmike at swm.pp.se Sat May 2 00:42:21 2009 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Sat, 2 May 2009 07:42:21 +0200 (CEST) Subject: Where to buy Internet IP addresses In-Reply-To: <20090502002406.GK4507@hezmatt.org> References: <49FB4661.8090503@west.net> <200905012340.n41NeNKD093855@drugs.dv.isc.org> <20090502002406.GK4507@hezmatt.org> Message-ID: On Sat, 2 May 2009, Matthew Palmer wrote: > Handing out an IPv6 /56 to a DSL or cable customer should be handled much > the same way as giving them an IPv4 /29 is today -- ask, and it shall be > provided, but it's wasteful[1] to do so by default. > > [1] Just because we've got a lot of it, doesn't mean we should be pissing it > up against the wall unnecessarily. A motto for network engineers and > economists alike. You can't be wasteful with something that you know is already extremely plentyful. We currently have 72 million billion /56:es. If we do /56:es of the current /16 being handed out and then change our mind, we can still hand out 1100 billion /56:es before we can discover this was wasteful and then we will have spent one 65536th of the address space available. Give people a /56 and if they only use one NOW, you still won't have to handle administration of the customer when they change their mind. Current NAT boxes solve the problem of people only getting a single IP address. People adapt to the conditions we give them. When IPv6 is readily available there will be products that use several subnets in the home, if we start to just give them a single /64 there won't be a market to solve it this way, and people will continue to use a single /64. You can say you were right, there was no need, but you killed the multisubnet solution before it was even born. -- Mikael Abrahamsson email: swmike at swm.pp.se From herrin-nanog at dirtside.com Sat May 2 05:13:38 2009 From: herrin-nanog at dirtside.com (William Herrin) Date: Sat, 2 May 2009 06:13:38 -0400 Subject: Slightly OT: Calculating HVAC requirements for server rooms In-Reply-To: References: <1b5c1c150905011759p6b6a31berf8f0afc2bc7e2125@mail.gmail.com> <49FBA2A3.3030401@emmanuelcomputerconsulting.com> Message-ID: <3c3e3fca0905020313v2477d406q8fdff470b4c1f176@mail.gmail.com> On Sat, May 2, 2009 at 12:06 AM, Ricky Beam wrote: > Translation: Hire a f***ing professional. > > And that's exactly what you need to do. ?Qualified HVAC installers (with > specific data center experience) will know far more than us "network types" > will ever want to know about cooling. ?They do this for a living, and thus, > know all the tiny details and odd edge cases to look for. (like looking > above the drop ceiling -- that's what it's called, btw -- and seeing what's > up there long before pencil meets paper (not that anyone uses paper > anymore.)) Ricky, You shouldn't even *have* a drop ceiling in a modern computer room. You want the room to be as tall as practical so that the air from the hot aisles has somewhere to go on its way back to the HVAC, other than back through and around the cabinets. Personally, I've found that there's a pretty wide disparity between HVAC professionals that are capable of hooking up a CRAC and turning it on versus HVAC professionals that understand the holistic picture including hot aisles, cold aisles, humidity control and flow. I wouldn't want to call in a professional without first understanding the problem well enough to assess whether I was getting a competent answer. 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 Sat May 2 06:52:32 2009 From: jbates at brightok.net (Jack Bates) Date: Sat, 02 May 2009 06:52:32 -0500 Subject: Slightly OT: Calculating HVAC requirements for server rooms In-Reply-To: <3c3e3fca0905020313v2477d406q8fdff470b4c1f176@mail.gmail.com> References: <1b5c1c150905011759p6b6a31berf8f0afc2bc7e2125@mail.gmail.com> <49FBA2A3.3030401@emmanuelcomputerconsulting.com> <3c3e3fca0905020313v2477d406q8fdff470b4c1f176@mail.gmail.com> Message-ID: <49FC3400.5000208@brightok.net> William Herrin wrote: > You shouldn't even *have* a drop ceiling in a modern computer room. > You want the room to be as tall as practical so that the air from the > hot aisles has somewhere to go on its way back to the HVAC, other than > back through and around the cabinets. > I love my 30' ceiling. Even with all the things that are wrong with our HVAC setup, the servers survive due to that ceiling. > Personally, I've found that there's a pretty wide disparity between > HVAC professionals that are capable of hooking up a CRAC and turning > it on versus HVAC professionals that understand the holistic picture > including hot aisles, cold aisles, humidity control and flow. I > wouldn't want to call in a professional without first understanding > the problem well enough to assess whether I was getting a competent > answer. I had this issue. They hooked up the redundant systems, but didn't bother with much else. The return feed is below the units pulling ambient air, and the cold air is injected 15+ feet above the isle behind the servers, intermixing with the hot air as it rises up the wall. At least it works, but it could be better and changes will need to be made before I can reach 50% capacity in the racks. Jack From joel.mercado at verizon.net Sat May 2 08:25:30 2009 From: joel.mercado at verizon.net (joel.mercado at verizon.net) Date: Sat, 02 May 2009 08:25:30 -0500 (CDT) Subject: Slightly OT: Calculating HVAC requirements for server rooms Message-ID: <9868653.35097.1241270730540.JavaMail.root@vms076.mailsrvcs.net> In modern data Centers drop ceiling is installed. The reason being you can create a AIR plenum. If your not going to have a air plenum then you should not have a drop ceiling. If you look at the in the link below you will see were the red arrows are thats were you would installed drop ceiling perferated tiles. Then the crack you will have a housing that sits ontop of the crack unit connected the ceiling to it and pulls air in. [1]http://www.panduit.com/stellent/groups/marketing-corp/documents/land ing_pages/~export/CMSCONT_034718~13/34864-5.gif Jmercado May 2, 2009 06:53:16 AM, [2]jbates at brightok.net wrote: William Herrin wrote: > You shouldn't even *have* a drop ceiling in a modern computer room. > You want the room to be as tall as practical so that the air from the > hot aisles has somewhere to go on its way back to the HVAC, other than > back through and around the cabinets. > I love my 30' ceiling. Even with all the things that are wrong with our HVAC setup, the servers survive due to that ceiling. > Personally, I've found that there's a pretty wide disparity between > HVAC professionals that are capable of hooking up a CRAC and turning > it on versus HVAC professionals that understand the holistic picture > including hot aisles, cold aisles, humidity control and flow. I > wouldn't want to call in a professional without first understanding > the problem well enough to assess whether I was getting a competent > answer. I had this issue. They hooked up the redundant systems, but didn't bother with much else. The return feed is below the units pulling ambient air, and the cold air is injected 15+ feet above the isle behind the servers, intermixing with the hot air as it rises up the wall. At least it works, but it could be better and changes will need to be made before I can reach 50% capacity in the racks. Jack References 1. http://www.panduit.com/stellent/groups/marketing-corp/documents/landing_pages/~export/CMSCONT_034718~13/34864-5.gif 2. mailto:jbates at brightok.net From frnkblk at iname.com Sat May 2 08:28:15 2009 From: frnkblk at iname.com (Frank Bulk) Date: Sat, 2 May 2009 08:28:15 -0500 Subject: Slightly OT: Calculating HVAC requirements for server rooms In-Reply-To: References: <1b5c1c150905011759p6b6a31berf8f0afc2bc7e2125@mail.gmail.com> <49FBA2A3.3030401@emmanuelcomputerconsulting.com> Message-ID: And when he writes "professional", that might mean someone with more expertise than your average commercial HVAC shop. I've seen it countless times where general contractors do a great job on almost every aspect of the building but fail miserably when it comes to setting aside space for network equipment and remembering to cool that gear in the IMF rooms. Those experiences have put me on the offensive when working with such folk -- you literally have to stake out your ground and remind them of the cooling needs every step along the way. Frank -----Original Message----- From: Ricky Beam [mailto:jfbeam at gmail.com] Sent: Friday, May 01, 2009 11:06 PM To: NANOG Subject: Re: Slightly OT: Calculating HVAC requirements for server rooms On Fri, 01 May 2009 21:32:19 -0400, William Warren wrote: >> Specifically, I am using the guide posted at: >> http://www.openxtra.co.uk/articles/calculating-heat-load "Before you decide on an air conditioning unit you should commission an audit from a suitably qualified air conditioning equipment specialist or installer." Translation: Hire a f***ing professional. And that's exactly what you need to do. Qualified HVAC installers (with specific data center experience) will know far more than us "network types" will ever want to know about cooling. They do this for a living, and thus, know all the tiny details and odd edge cases to look for. (like looking above the drop ceiling -- that's what it's called, btw -- and seeing what's up there long before pencil meets paper (not that anyone uses paper anymore.)) > You also have to take into account the environment surrounding the data > room. At my wife's work The ceiling above is only separated with a > false ceiling to the metal roof above but the rest of hte spaces > surrounding the room are climate controled. They [had] to significantly > upsize to account for the heat load of that ceiling. Unless you are pulling air through the plenum (that space above the drop ceiling), the air up there shouldn't matter much -- there should be plenum returns up there to begin with venting the air to the surrounding plenum(s) (i.e. the rest of the office, hallway, neighboring office, etc.) However, I've seen more than enough office setups where the "engineers" planning the space completely ignore the plenum. In my current office building the static pressure pushes the bathroom doors open by almost 2". And they placed our server room directly under the building air handlers -- meaning all the air on the 3rd floor eventually passes through the plenum above my servers. (also, the sprinkler system riser room is in there.) Bottom line, again, ask a professional. NANOG is a bunch of network geeks (in theory.) I'd be surprised if there's even one licensed HVAC "geek" on the list. ('tho I'm sure many may *know* an HVAC engineer.) --Ricky From jgreco at ns.sol.net Sat May 2 08:28:38 2009 From: jgreco at ns.sol.net (Joe Greco) Date: Sat, 2 May 2009 08:28:38 -0500 (CDT) Subject: Slightly OT: Calculating HVAC requirements for server rooms In-Reply-To: from "Ricky Beam" at May 02, 2009 12:06:29 AM Message-ID: <200905021328.n42DScZM012439@aurora.sol.net> > On Fri, 01 May 2009 21:32:19 -0400, William Warren > wrote: > >> Specifically, I am using the guide posted at: > >> http://www.openxtra.co.uk/articles/calculating-heat-load > > "Before you decide on an air conditioning unit you should commission an > audit from a suitably qualified air conditioning equipment specialist or > installer." > > Translation: Hire a f***ing professional. > > And that's exactly what you need to do. Qualified HVAC installers (with > specific data center experience) will know far more than us "network > types" will ever want to know about cooling. They do this for a living, > and thus, know all the tiny details and odd edge cases to look for. (like > looking above the drop ceiling -- that's what it's called, btw -- and > seeing what's up there long before pencil meets paper (not that anyone > uses paper anymore.)) [...] > Bottom line, again, ask a professional. NANOG is a bunch of network geeks > (in theory.) I'd be surprised if there's even one licensed HVAC "geek" on > the list. ('tho I'm sure many may *know* an HVAC engineer.) The problem is that you're ultimately responsible for determining the competence of that "professional." I've seen a number of them who have talked about their "data center" experience, when it turns out that their idea of "data center" is "I went down to $FooCo and set up their 200 sq ft of server room with a mini-split system". So, here's better advice. Take some time. Educate yourself. There's a ton of useful information out there that should give you some basic grasp of what's important and what's not. Airflow and BTU are important. Do not be afraid to get into it a bit: learn what "latent" and "sensible" mean in the HVAC world. Knowing about realistic layouts for data centers is important. If you run into a "professional" that looks at you funny when you say "cold aisle," you know that you can wind up the conversation and thank them for their time, and then call someone else. But when you find the right guy, you should be able to hold an intelligent conversation with him, he should be able to make plausible and reasonable explanations of where you've misunderstood things, and the best guys will not mind that you are trying to work with them closer to their level, because ultimately it means that their task is also more likely to be successfully completed, and that you'll be coming back to them in the future. Best to not just blindly hand things off to a "professional." Be sure that they do, in fact, have the skill sets and experience you need. Know too that they are relying on you for critical bits, and that the best situation for both parties is when you each understand the other's stuff well enough that you can actually get the right thing done. ... 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 ken.gilmour at gmail.com Sat May 2 08:34:53 2009 From: ken.gilmour at gmail.com (Ken Gilmour) Date: Sat, 2 May 2009 07:34:53 -0600 Subject: Minnesota to block online gambling sites? In-Reply-To: <5b6f80200904291438j2fb6238fs50b93c59b912c41e@mail.gmail.com> References: <5b6f80200904291438j2fb6238fs50b93c59b912c41e@mail.gmail.com> Message-ID: <5b6f80200905020634h3dc34ecclb98fab3839762488@mail.gmail.com> For anyone who cares, IMEGA released the letter from the state of Minnesota: http://www.imega.org/wp-content/uploads/2009/05/ab001dd4.pdf 2009/4/29 Ken Gilmour : > Hi there, > > I am just wondering if anyone knows any more about the attempt by > Minnesota to block online gambling companies other than what's > publicly available (e.g. > http://www.gambling911.com/gambling-news/minnesota-regulators-try-block-access-gambing-sites-042909.html)? > Such as a list or the letter to the providers? > > Thank you! > > Ken > From jeffrey.lyon at blacklotus.net Sat May 2 08:39:02 2009 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Sat, 2 May 2009 09:39:02 -0400 Subject: Minnesota to block online gambling sites? In-Reply-To: <5b6f80200905020634h3dc34ecclb98fab3839762488@mail.gmail.com> References: <5b6f80200904291438j2fb6238fs50b93c59b912c41e@mail.gmail.com> <5b6f80200905020634h3dc34ecclb98fab3839762488@mail.gmail.com> Message-ID: <16720fe00905020639l381dba73t8df219e6bfacc8f0@mail.gmail.com> What a pile of garbage. I would definitely get a legal review of a request like that before blocking any of my customer's traffic. -- Jeffrey Lyon, Leadership Team jeffrey.lyon at blacklotus.net | http://www.blacklotus.net Black Lotus Communications of The IRC Company, Inc. Look for us at HostingCon 2009 in Washington, DC on August 10th - 12th at Booth #401. On Sat, May 2, 2009 at 9:34 AM, Ken Gilmour wrote: > For anyone who cares, IMEGA released the letter from the state of Minnesota: > > http://www.imega.org/wp-content/uploads/2009/05/ab001dd4.pdf > > 2009/4/29 Ken Gilmour : >> Hi there, >> >> I am just wondering if anyone knows any more about the attempt by >> Minnesota to block online gambling companies other than what's >> publicly available (e.g. >> http://www.gambling911.com/gambling-news/minnesota-regulators-try-block-access-gambing-sites-042909.html)? >> Such as a list or the letter to the providers? >> >> Thank you! >> >> Ken >> > > From alex at corp.nac.net Sat May 2 08:40:04 2009 From: alex at corp.nac.net (Alex Rubenstein) Date: Sat, 2 May 2009 09:40:04 -0400 Subject: Slightly OT: Calculating HVAC requirements for server rooms In-Reply-To: <1b5c1c150905011759p6b6a31berf8f0afc2bc7e2125@mail.gmail.com> References: <1b5c1c150905011759p6b6a31berf8f0afc2bc7e2125@mail.gmail.com> Message-ID: Calculating heat load in a datacenter is pretty easy. That's not the hard part. Some comments: > I am curious what formulas/equations folks use to figure out required > cooling for small datacenters in offices. The simplest equation to use assumes that you know how much power is going into the room. Btu/hr = watts * 3.412 This further assumes that a typical IT load is very inefficient (which they are).. meaning that, for every watt that goes to a computer / server / router, a significant portion is converted to heat (we assume 100% for design purposes). So, if you have a datacenter consuming 100kw, you'd need 341,200 btu/hr of cooling, or 28 tons of HVAC. Of course, there are other issues (like leakage, windows, doors, humans, lights) but these tend to be a little bit of line noise in a modern datacenter. Also outside environment (is this Quebec or is this Cuba), insulation, design delivery temperature, humidity requirements -- all play a part. > Translation: Hire a f***ing professional. > > And that's exactly what you need to do. Qualified HVAC installers Two comments on this... first of all, the last thing you want is an HVAC 'installer' to design your HVAC system in a datacenter. Secondly, if you find an HVAC engineer who *really* knows datacenter dynamics, that could be a help. But, frankly, there aren't a lot of them. If you need some help with this, let me know. There are a significant amount of questions that need to be asked to give a qualified answer. The cooling capacity question is secondary to the delivery and extraction method. I also submit that any good datacenter operator, who has had years of experience of trial and error, years of engineers who say they know something and don't, and had scores of contractors who say they know something and don't, is in a much better position to talk about this than a PE who designs comfort cooling systems. "Question everything, assume nothing, discuss all, and resolve quickly." -- Alex Rubenstein, AR97, K2AHR, alex at nac.net, latency, Al Reuben -- -- Net Access Corporation, 800-NET-ME-36, http://www.nac.net -- From joel.mercado at verizon.net Sat May 2 08:50:09 2009 From: joel.mercado at verizon.net (joel.mercado at verizon.net) Date: Sat, 02 May 2009 08:50:09 -0500 (CDT) Subject: Slightly OT: Calculating HVAC requirements for server rooms Message-ID: <11080308.35610.1241272209935.JavaMail.root@vms076.mailsrvcs.net> Just knowing your spacing and were to places perforated tiles is very helpful in maxmizing air and not shortcycling it.. Establishing a Floor Plan [1]http://www.apcmedia.com/salestools/VAVR-6KYMZ7_R0_EN.pdf May 2, 2009 08:41:50 AM, [2]alex at corp.nac.net wrote: Calculating heat load in a datacenter is pretty easy. That's not the hard part. Some comments: > I am curious what formulas/equations folks use to figure out required > cooling for small datacenters in offices. The simplest equation to use assumes that you know how much power is going into the room. Btu/hr = watts * 3.412 This further assumes that a typical IT load is very inefficient (which they are).. meaning that, for every watt that goes to a computer / server / router, a significant portion is converted to heat (we assume 100% for design purposes). So, if you have a datacenter consuming 100kw, you'd need 341,200 btu/hr of cooling, or 28 tons of HVAC. Of course, there are other issues (like leakage, windows, doors, humans, lights) but these tend to be a little bit of line noise in a modern datacenter. Also outside environment (is this Quebec or is this Cuba), insulation, design delivery temperature, humidity requirements -- all play a part. > Translation: Hire a f***ing professional. > > And that's exactly what you need to do. Qualified HVAC installers Two comments on this... first of all, the last thing you want is an HVAC 'installer' to design your HVAC system in a datacenter. Secondly, if you find an HVAC engineer who *really* knows datacenter dynamics, that could be a help. But, frankly, there aren't a lot of them. If you need some help with this, let me know. There are a significant amount of questions that need to be asked to give a qualified answer. The cooling capacity question is secondary to the delivery and extraction method. I also submit that any good datacenter operator, who has had years of experience of trial and error, years of engineers who say they know something and don't, and had scores of contractors who say they know something and don't, is in a much better position to talk about this than a PE who designs comfort cooling systems. "Question everything, assume nothing, discuss all, and resolve quickly." -- Alex Rubenstein, AR97, K2AHR, [3]alex at nac.net, latency, Al Reuben -- -- Net Access Corporation, 800-NET-ME-36, [4]http://www.nac.net -- References Visible links 1. http://www.apcmedia.com/salestools/VAVR-6KYMZ7_R0_EN.pdf 2. mailto:alex at corp.nac.net 3. mailto:alex at nac.net 4. http://www.nac.net/ Hidden links: 5. http://www.apcmedia.com/salestools/VAVR-6KYMZ7_R0_EN.pdf From trejrco at gmail.com Sat May 2 11:06:32 2009 From: trejrco at gmail.com (trejrco at gmail.com) Date: Sat, 2 May 2009 16:06:32 +0000 Subject: Where to buy Internet IP addresses In-Reply-To: References: <49FB4661.8090503@west.net><200905012340.n41NeNKD093855@drugs.dv.isc.org><20090502002406.GK4507@hezmatt.org> Message-ID: <1448415994-1241280382-cardhu_decombobulator_blackberry.rim.net-1091775455-@bxe1295.bisx.prod.on.blackberry> @Mikael - "I agree 100% with the give them more than they know they need, so when they do need it we don't need to do anything" (Nit-we are allocating from a /3 (2000::/3) today) @Matthew - Obviously, I (respectfully) disagree with treating IPv6 allocations that similarly to IPv4 allocations - the "v6 way" is to let the protocol encourage innovation, not stifle it ... If it turns out to be a bad idea, we can revise the procedures for 4000::/3 (although I doubt it will be a problem). :) /TJ Sent from my Verizon Wireless BlackBerry -----Original Message----- From: Mikael Abrahamsson Date: Sat, 2 May 2009 07:42:21 To: Matthew Palmer Cc: Subject: Re: Where to buy Internet IP addresses On Sat, 2 May 2009, Matthew Palmer wrote: > Handing out an IPv6 /56 to a DSL or cable customer should be handled much > the same way as giving them an IPv4 /29 is today -- ask, and it shall be > provided, but it's wasteful[1] to do so by default. > > [1] Just because we've got a lot of it, doesn't mean we should be pissing it > up against the wall unnecessarily. A motto for network engineers and > economists alike. You can't be wasteful with something that you know is already extremely plentyful. We currently have 72 million billion /56:es. If we do /56:es of the current /16 being handed out and then change our mind, we can still hand out 1100 billion /56:es before we can discover this was wasteful and then we will have spent one 65536th of the address space available. Give people a /56 and if they only use one NOW, you still won't have to handle administration of the customer when they change their mind. Current NAT boxes solve the problem of people only getting a single IP address. People adapt to the conditions we give them. When IPv6 is readily available there will be products that use several subnets in the home, if we start to just give them a single /64 there won't be a market to solve it this way, and people will continue to use a single /64. You can say you were right, there was no need, but you killed the multisubnet solution before it was even born. -- Mikael Abrahamsson email: swmike at swm.pp.se From alan at routingloop.com Sat May 2 14:22:31 2009 From: alan at routingloop.com (Alan Hannan) Date: Sat, 02 May 2009 12:22:31 -0700 Subject: 10-GigE for servers In-Reply-To: <81ecd7700905011055y3fd14276pbb78c2b80882da63@mail.gmail.com> References: <81ecd7700905011055y3fd14276pbb78c2b80882da63@mail.gmail.com> Message-ID: <49FC9D77.5070201@routingloop.com> The 10G cards from Neterion (http://www.neterion.com/products/xframeE.html) perform extremely well. Much of your potential limiting rate will be in the CPU and networking resources. I agree with many of the other folks that etherchannel should work exceedingly well, but if you want to consolidate, there are many choices for single-system 10G ethernet cards. -alan Jason Shoemaker wrote: > My company is looking for ways to improve throughput for data transfers > between individual servers. We?re exploring the creation of Etherchannels > using multiple server NICs, but Etherchannel seems to have the limitation of > not supporting per-packet load-balancing, therefore limiting traffic between > two individual hosts to 1 Gig. > > In most of my research, I?ve seen 10-GigE used for traffic aggregation and > for the ?unified fabric? solution that Cisco and others are pushing. I?m > interested in knowing if any of you have attempted to implement 10-GigE at > the host level to improve network throughput between individual servers and > what your experience was in doing so. > > Thanks in advance, > > Jason > From mysidia at gmail.com Sat May 2 23:20:25 2009 From: mysidia at gmail.com (James Hess) Date: Sat, 2 May 2009 23:20:25 -0500 Subject: Where to buy Internet IP addresses In-Reply-To: <49FBA5DA.2020707@bogus.com> References: <200905012340.n41NeNKD093855@drugs.dv.isc.org> <49FB9A86.1080101@rollernet.us> <49FBA5DA.2020707@bogus.com> Message-ID: <6eb799ab0905022120o5be64c56ye664a8d00bd4eb91@mail.gmail.com> On Fri, May 1, 2009 at 8:46 PM, Joel Jaeggli wrote: > By definition, every single one of them that buys wireless router, then > buys another and hangs it off the first. That happens more often then > you would think. A /62 takes care of that unusual case, no real need for a /56 for the average residential user; that's just excessive. Before wondering about the capabilities of home routers.. one might wonder if there will even be _home_ "routers" ? The consumer-level boxes for home users that do NAT for V4, for V6 may well act more like Layer 3 bridges, and (once need for IPv4 support goes away) be simple Layer 2 bridges that can be small lower-powered, fairly dumb devices that just act as pass-through for the ISP router with a basic transparent firewall. And only route/NAT for IPv4. There are reasons to doubt that PD will be supported on consumer level devices; or to expect devices may have only limited support for PD. The availability of an entire /64 means users' 'internet sharing boxes' no longer benefit from NAT or routing capabilities; the user has all the IPs they need from the ISP, and doesn't _need_ to create their own subnets. NAT'ing/routing in IPv6 becomes more of a feature only Service providers and large entities really need. -- -J From jmaimon at ttec.com Sun May 3 00:30:52 2009 From: jmaimon at ttec.com (Joe Maimon) Date: Sun, 03 May 2009 01:30:52 -0400 Subject: Where to buy Internet IP addresses In-Reply-To: References: <49FB4661.8090503@west.net> <200905012340.n41NeNKD093855@drugs.dv.isc.org> <20090502002406.GK4507@hezmatt.org> Message-ID: <49FD2C0C.8080204@ttec.com> Mikael Abrahamsson wrote: > On Sat, 2 May 2009, Matthew Palmer wrote: >> [1] Just because we've got a lot of it, doesn't mean we should be >> pissing it >> up against the wall unnecessarily. A motto for network engineers and >> economists alike. > > You can't be wasteful with something that you know is already extremely > plentyful. There is no resource that cannot be pissed away, if you try hard enough. > > We currently have 72 million billion /56:es. If we do /56:es of the > current /16 being handed out and then change our mind, we can still hand > out 1100 billion /56:es before we can discover this was wasteful and > then we will have spent one 65536th of the address space available. > Philosophical: You know, if we are just going to act as if ipv6 has only 64 bits, why didnt we just design it with only 64? Practical: Think of the routing table. How many /48's in a /32? > Give people a /56 and if they only use one NOW, Give people a /96. Thats a whole internet. Whats that? They resurrected classfull addressing for ipv6? From mmc at internode.com.au Sun May 3 02:53:25 2009 From: mmc at internode.com.au (Matthew Moyle-Croft) Date: Sun, 03 May 2009 17:23:25 +0930 Subject: Where to buy Internet IP addresses In-Reply-To: <6eb799ab0905022120o5be64c56ye664a8d00bd4eb91@mail.gmail.com> References: <200905012340.n41NeNKD093855@drugs.dv.isc.org> <49FB9A86.1080101@rollernet.us> <49FBA5DA.2020707@bogus.com> <6eb799ab0905022120o5be64c56ye664a8d00bd4eb91@mail.gmail.com> Message-ID: <49FD4D75.40702@internode.com.au> James Hess wrote: > > A /62 takes care of that unusual case, no real need for a /56 for > the average residential user; that's just excessive. Before wondering > about the capabilities of home routers.. one might wonder if there > will even be _home_ "routers" ? > > I think you'd want to do a /60 so it's on a "nibble" boundary. But by then you might as well do a /56. My personal feeling is that 99% of home networks will use a single /64, but we'll be giving out /60s and /56s to placate the 1% who are going to jump up and down and shout at us about it because of some reason that they feel makes it all unfair or that we're "thinking like ipv4 not ipv6" etc. It's possible that home networks will gain some ability (in a standard fashion) to use more than one /64, but I doubt it - it's much easier to do resource discovery on a single broadcast domain for things like printers, file sharing etc. MMC From swmike at swm.pp.se Sun May 3 03:03:57 2009 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Sun, 3 May 2009 10:03:57 +0200 (CEST) Subject: Where to buy Internet IP addresses In-Reply-To: <49FD4D75.40702@internode.com.au> References: <200905012340.n41NeNKD093855@drugs.dv.isc.org> <49FB9A86.1080101@rollernet.us> <49FBA5DA.2020707@bogus.com> <6eb799ab0905022120o5be64c56ye664a8d00bd4eb91@mail.gmail.com> <49FD4D75.40702@internode.com.au> Message-ID: On Sun, 3 May 2009, Matthew Moyle-Croft wrote: > My personal feeling is that 99% of home networks will use a single /64, > but we'll be giving out /60s and /56s to placate the 1% who are going to > jump up and down and shout at us about it because of some reason that > they feel makes it all unfair or that we're "thinking like ipv4 not > ipv6" etc. IPv6 was designed around handing out /48s to everybody. There are 281 thousand billion /48s in the IPv6 space. We are 6 billion people on the earth. If we hand out a /48 to each, we still have a lot to spare (99.999% left), then we can decide if this was a problem or not. > It's possible that home networks will gain some ability (in a standard > fashion) to use more than one /64, but I doubt it - it's much easier to do > resource discovery on a single broadcast domain for things like printers, > file sharing etc. Don't think now or next year, think in 10 years. Think hundreds of devices in your home, you don't want your sensor network to be on the same subnet as your computers, and you want a DMZ, and you want your video on a separate subnet (because you have cheap switches which do not have MLD snooping) etc. There is NO reason of scarcity to NOT hand out at least a /56 to each end user. Stop thinking IPv4 and start to think IPv6, we're going to be living with this for tens of years and you have no idea what people want to do in the future. Give them the chance to innovate and they (or someone they purchase products from) will. It's short sighted and silly to design your service around handing out /64s to people and then you have to redesign it when demand for multiple subnets come around. Design it around /56 to begin with, and you will have solved the problem for the future, not just for now. -- Mikael Abrahamsson email: swmike at swm.pp.se From randy at psg.com Sun May 3 03:36:29 2009 From: randy at psg.com (Randy Bush) Date: Sun, 03 May 2009 10:36:29 +0200 Subject: Where to buy Internet IP addresses In-Reply-To: <49FD4D75.40702@internode.com.au> References: <200905012340.n41NeNKD093855@drugs.dv.isc.org> <49FB9A86.1080101@rollernet.us> <49FBA5DA.2020707@bogus.com> <6eb799ab0905022120o5be64c56ye664a8d00bd4eb91@mail.gmail.com> <49FD4D75.40702@internode.com.au> Message-ID: > My personal feeling is that 99% of home networks will use a single > /64, but we'll be giving out /60s and /56s to placate the 1% who are > going to jump up and down and shout at us about it because of some > reason that they feel makes it all unfair or that we're "thinking like > ipv4 not ipv6" etc. a consumer auto-provisioning system which only gives out one size? there is not a web site on which the customer can choose dynamically? how 20th century. folk who think about provisioning consumers should go to paris for a week and be a free.fr customer. brilliantly done. [ and i am sure you can find other things to do in paris as well. ] randy From jgreco at ns.sol.net Sun May 3 05:01:10 2009 From: jgreco at ns.sol.net (Joe Greco) Date: Sun, 3 May 2009 05:01:10 -0500 (CDT) Subject: Where to buy Internet IP addresses In-Reply-To: <49FD2C0C.8080204@ttec.com> from "Joe Maimon" at May 03, 2009 01:30:52 AM Message-ID: <200905031001.n43A1AOO092384@aurora.sol.net> > Mikael Abrahamsson wrote: > > On Sat, 2 May 2009, Matthew Palmer wrote: > > >> [1] Just because we've got a lot of it, doesn't mean we should be > >> pissing it > >> up against the wall unnecessarily. A motto for network engineers and > >> economists alike. > > > > You can't be wasteful with something that you know is already extremely > > plentyful. > > There is no resource that cannot be pissed away, if you try hard enough. Oh! You mean, like the way we piss away IPv4 addresses? > > We currently have 72 million billion /56:es. If we do /56:es of the > > current /16 being handed out and then change our mind, we can still hand > > out 1100 billion /56:es before we can discover this was wasteful and > > then we will have spent one 65536th of the address space available. > > Philosophical: > > You know, if we are just going to act as if ipv6 has only 64 bits, why > didnt we just design it with only 64? Well, if you look at it the right way, we *did*. While you can drill down into the lower 64 bits, the design intent was clearly to let that be handled by end users and stateless autoconfig, etc. So, from a design viewpoint, you treat a /64 the way we treat an IP address. Except that unlike an IP address, there's a lot more /64's, and each /64 can hold an IPv4 Internet - squared. > Practical: > > Think of the routing table. How many /48's in a /32? > > > > Give people a /56 and if they only use one NOW, > > Give people a /96. Thats a whole internet. No! That's very bad. That breaks stateless autoconfig. That's awful. What in the world is the justification for that? We can give every person likely to be on the planet in the next 100 years a /48 and not be even remotely close to running out. > Whats that? They resurrected classfull addressing for ipv6? Pfft. We *want* things like IPv6 stateless autoconfig to work. It's a great idea. We *want* a protocol simple enough that we don't have to deal with stateful DHCP, we *want* something that is hard to screw up. We also don't want to force everyone into a single broadcast domain, or to have to break stateless autoconfig by subnetting deeper than a /64. Sure, *today*, the average person has a handful of networked devices, and *today*, the average person might not need more than a "public" net and a "local/printer" net. However... twenty years ago, only a few of us had a network at home. It's hard to predict what will be coming in twenty years, but I expect there'll be more networking, not less. Microprocessors are getting smaller and cheaper. The devices that support Internet connections are growing, such as all the ethernet ports that have sprouted on televisions in recent years. In order to get multiple broadcast domains and retain stateless autoconfig, you give people more space than a /64. But there are plenty of reasons that you might want the wifi on a separate network from the home computer network, and both of that separate from other networks with highly restrictive access, such as a network for the printer, or your light switches, or your HVAC management, or your alarm system, or your gaming network, or your kitchen electronics, or your A/V, etc. Under IPv6, there will (hopefully) be a demand for home networking switches and firewalls that greatly simplify security, and one of the things I'd like to see is the separation of devices at L3, so that a home user can use a graphical firewall tool that simply determines which networks are accessible from which other networks in a visual manner, etc. This is so much easier with something greater than a /64. So if you can justify giving people a /96, but you can't see why it'd be better to give them (at least!) a /56 instead, that just makes no damn sense. IPv6 was built around the concept that we wanted to make space as close to *free* as possible. The designers intended that it not be a horribly big deal to have to choose between a /64 and a /56 and a /48; space is plentiful enough that if you're not absolutely positive that one size is adequate, that you should then go a little larger. Just to be safe. Because, remember, we're talking tiny slivers of space. Think about what a /48 *means*. Today, you get a single IP address on the IPv4 Internet, one single IP address, and that's a /32. We're talking much smaller allocations, and a /48 is an extremely powerful allocation from the user's point of view. We will find creative uses for the space. Look at RFC3041, which is a credible use for a /64's worth of space that provides a variety of benefits. Any IPv4 engineer who has been working for the last decade will look at IPv6 and be aghast over the apparent waste, but take a little time to look at the realities and possibilities before reaching rash conclusions. I do see the sheer vastness of a /64 as something that's very difficult to wrap your head around: all of the space on today's Internet would be just a drop in a /64 bucket. However, if you can get past that and see the /64 as just a basic "network," that's a good first step in understanding IPv6. Then you should be thinking about the fact that we will probably be living with this for many years to come, and if we make poor choices now about how we allocate to users, that will haunt us for years to come. ... 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 sthaug at nethelp.no Sun May 3 05:12:45 2009 From: sthaug at nethelp.no (sthaug at nethelp.no) Date: Sun, 03 May 2009 12:12:45 +0200 (CEST) Subject: Where to buy Internet IP addresses In-Reply-To: <200905031001.n43A1AOO092384@aurora.sol.net> References: <49FD2C0C.8080204@ttec.com> <200905031001.n43A1AOO092384@aurora.sol.net> Message-ID: <20090503.121245.74738221.sthaug@nethelp.no> > We *want* things like IPv6 stateless autoconfig to work. It's a great > idea. We *want* a protocol simple enough that we don't have to deal > with stateful DHCP, we *want* something that is hard to screw up. You should be aware that this is by no means a universal viewpoint. IPv6 stateless autoconfig can be screwed up, DHCP can be screwed up. For my IPv6 networks I plan to stick with fixed IPv6 address or DHCP. Steinar Haug, Nethelp consulting, sthaug at nethelp.no From jgreco at ns.sol.net Sun May 3 05:17:21 2009 From: jgreco at ns.sol.net (Joe Greco) Date: Sun, 3 May 2009 05:17:21 -0500 (CDT) Subject: Where to buy Internet IP addresses In-Reply-To: <20090503.121245.74738221.sthaug@nethelp.no> from "sthaug@nethelp.no" at May 03, 2009 12:12:45 PM Message-ID: <200905031017.n43AHLU8093464@aurora.sol.net> > > We *want* things like IPv6 stateless autoconfig to work. It's a great > > idea. We *want* a protocol simple enough that we don't have to deal > > with stateful DHCP, we *want* something that is hard to screw up. > > You should be aware that this is by no means a universal viewpoint. Very few viewpoints are universal. I've just waded through a debate on another mailing list about how broadband providers are going to only want to allocate you a single IPv6 address... bleah. > IPv6 stateless autoconfig can be screwed up, DHCP can be screwed up. Everything *can* be screwed up. You know what Scotty says. > For my IPv6 networks I plan to stick with fixed IPv6 address or DHCP. That's fine, but I don't want to lose the option of stateless autoconfig just because someone doesn't grasp the size of the address space and the intent of the designers. Allocating everyone a /48 does not preclude the use of stateless autoconfig, DHCP, or manual configuration. Allocating everyone a /96, on the other hand? ... 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 rodrick.brown at gmail.com Sun May 3 08:54:05 2009 From: rodrick.brown at gmail.com (Rodrick Brown) Date: Sun, 3 May 2009 09:54:05 -0400 Subject: 10-GigE for servers In-Reply-To: References: <81ecd7700905011055y3fd14276pbb78c2b80882da63@mail.gmail.com> Message-ID: 2009/5/1 Nathan Stratton : > On Fri, 1 May 2009, Jason Shoemaker wrote: > >> My company is looking for ways to improve throughput for data transfers >> between individual servers. ?We?re exploring the creation of Etherchannels >> using multiple server NICs, but Etherchannel seems to have the limitation >> of >> not supporting per-packet load-balancing, therefore limiting traffic >> between >> two individual hosts to 1 Gig. > > Have you thought about Infiniband? Dual 10 gig cards cost about $50 and 24 > port switches about $1200 on ebay. Infiniband has just a fraction of the > latency of ethernet (even 10 get eth). You get the lowest latency if your > application supports Infiniband, but if not you can run IP over IB. > Infiniband is dying technology.. > >> <> > > Nathan Stratton ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?CTO, BlinkMind, Inc. > nathan at robotics.net ? ? ? ? ? ? ? ? ? ? ? ? nathan at blinkmind.com > http://www.robotics.net ? ? ? ? ? ? ? ? ? ? ? ?http://www.blinkmind.com -- [ Rodrick R. Brown ] http://www.rodrickbrown.com http://www.linkedin.com/in/rodrickbrown From vixie at isc.org Sun May 3 10:57:16 2009 From: vixie at isc.org (Paul Vixie) Date: Sun, 03 May 2009 15:57:16 +0000 Subject: Slightly OT: Calculating HVAC requirements for server rooms In-Reply-To: (Ricky Beam's message of "Sat\, 02 May 2009 00\:55\:32 -0400") References: <1b5c1c150905011759p6b6a31berf8f0afc2bc7e2125@mail.gmail.com> <49FBA2A3.3030401@emmanuelcomputerconsulting.com> <49FBCA80.6060607@rollernet.us> <20090502042637.GA45183@typo.org> Message-ID: warning-- it's sunday. pontification alert. "Ricky Beam" writes: > On Sat, 02 May 2009 00:26:37 -0400, Wayne E. Bouchard wrote: > >> ... approximation > > Even an approximation is hard to make. One might think the simple math of > "how much power is fed into the room" would do, but it ignores numerous > factors that greatly effect the answer. I can rattle off example after > example, but it's unnecessary. You'll need professionals to install the > hardware, so there's no point not calling them in for a consult. "Always listen to experts. They'll tell you what can't be done and why. Then do it." --Robert Heinlein after 1993 i stopped letting HVAC people do design work for me, either at home or at work. i've had to sign several waiver letters promising not to sue an HVAC company if the system they built to my spec failed to perform. astoundingly, not everyone "in the business" knows the difference between conduction, convection, and radiation. consult, sure, but with suspicion. same thing for power, structural, security, insurance, finance, network, hardware, software, and legal people, many of whom have never questioned their own assumptions nor those of their certification boards, state and county governments, or teachers/mentors. they don't have to live with the results ... but i do ... thus my willingness to dive deep.) YMMV. -- Paul Vixie KI6YSY From cgucker at onesc.net Sun May 3 15:31:07 2009 From: cgucker at onesc.net (Charles Gucker) Date: Sun, 3 May 2009 16:31:07 -0400 Subject: Where to buy Internet IP addresses In-Reply-To: <2039ACC84D552B46A292559F7A45A1460248D298@edrmail01.southport.edr.cc> References: <2039ACC84D552B46A292559F7A45A1460248D298@edrmail01.southport.edr.cc> Message-ID: On Fri, May 1, 2009 at 2:29 PM, LEdouard Louis wrote: > Optimum Online business only offer 5 static IP address. Correct, this is a business grade cable modem service, where the only allocation they will provide is a /29. But what do you expect for a triple play residential product for ~150/month that is asymmetric in nature (since it's designed around a residential users experience). > Where can I buy a block of Internet IP address for Business? How much > does it cost? If you need a larger allocation of IP space, you would need to look at the commercial grade services, specifically within Cablevision, that would be the Optimum Lightpath, but there are alternatives. There is a huge difference in quality and price between the OOL and the OLP product sets, but the later is symmetric. > Most of our devices only require an internal IP address to reach the > internet, but we have a Juniper DX for load balancing. The symmetric, commercial service seems a lot more up your alley if you are looking for server load balancing. Also, keep in mind, with the greater price tag comes a much greater SLA for service guarantees. > We must provide Juniper DX with an internet IP address and point it to > internal IP address for customers to be able to reach it from the > internet. this is for testing and development purposes and will expect > several servers on Load-balancer. The 5 static IP addresses just won't > be enough. Well, in the OLP product set you would be able to obtain as much address space as you can reasonably justify (as is with most commercial product offerings). charles From mpalmer at hezmatt.org Sun May 3 15:19:24 2009 From: mpalmer at hezmatt.org (Matthew Palmer) Date: Mon, 4 May 2009 06:19:24 +1000 Subject: Where to buy Internet IP addresses In-Reply-To: <200905031001.n43A1AOO092384@aurora.sol.net> References: <49FD2C0C.8080204@ttec.com> <200905031001.n43A1AOO092384@aurora.sol.net> Message-ID: <20090503201924.GC28753@hezmatt.org> On Sun, May 03, 2009 at 05:01:10AM -0500, Joe Greco wrote: > > Mikael Abrahamsson wrote: > > > On Sat, 2 May 2009, Matthew Palmer wrote: > > > > >> [1] Just because we've got a lot of it, doesn't mean we should be > > >> pissing it > > >> up against the wall unnecessarily. A motto for network engineers and > > >> economists alike. > > > > > > You can't be wasteful with something that you know is already extremely > > > plentyful. > > > > There is no resource that cannot be pissed away, if you try hard enough. > > Oh! You mean, like the way we piss away IPv4 addresses? That's pretty much what I'm thinking of. I'm sure that, had their been a NANOG at the time IPv4 was being rolled out, there would have been an equivalent discussion, except substitute /8 for /48, and probably site for end user -- but the arguments, I'm sure, would have been the same, and they would have sounded just as rational to the participants then, too. In fact, there are probably people on this list now who *were* around when the initial IPv4 addressing policies were thought up... - Matt -- "People can be divided into three classes: The few who make things happen, the many who watch things happen, and the overwhelming majority who have no idea what has happened." (Author unknown) From swmike at swm.pp.se Sun May 3 17:34:20 2009 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Mon, 4 May 2009 00:34:20 +0200 (CEST) Subject: Where to buy Internet IP addresses In-Reply-To: <20090503201924.GC28753@hezmatt.org> References: <49FD2C0C.8080204@ttec.com> <200905031001.n43A1AOO092384@aurora.sol.net> <20090503201924.GC28753@hezmatt.org> Message-ID: On Mon, 4 May 2009, Matthew Palmer wrote: >> Oh! You mean, like the way we piss away IPv4 addresses? > > That's pretty much what I'm thinking of. I'm sure that, had their been a > NANOG at the time IPv4 was being rolled out, there would have been an > equivalent discussion, except substitute /8 for /48, and probably site for > end user -- but the arguments, I'm sure, would have been the same, and they > would have sounded just as rational to the participants then, too. > > In fact, there are probably people on this list now who *were* around when > the initial IPv4 addressing policies were thought up... We shouldn't waste the IPv6 addresses, but giving each end user a /56 isn't wasteful. It's even less than the protocol was designed for, and there is nobody who has conceived so far how this would be a problem before we've even used up 1/(2^16) of the available space and we can fix any problem seen by then with 65536 times more addresses to use in a less "wasteful" manner. Crippling IPv6 by just giving people a /64 isn't helping anybody, it's just delaying and complicating the IPv6 rollout to end users. We should make sure people are used to the fact to have routing in their home (or at least the possibility to do so). -- Mikael Abrahamsson email: swmike at swm.pp.se From jgreco at ns.sol.net Sun May 3 18:26:52 2009 From: jgreco at ns.sol.net (Joe Greco) Date: Sun, 3 May 2009 18:26:52 -0500 (CDT) Subject: Where to buy Internet IP addresses In-Reply-To: from "Mikael Abrahamsson" at May 04, 2009 12:34:20 AM Message-ID: <200905032326.n43NQqQR029672@aurora.sol.net> > On Mon, 4 May 2009, Matthew Palmer wrote: > >> Oh! You mean, like the way we piss away IPv4 addresses? > > > > That's pretty much what I'm thinking of. I'm sure that, had their been a > > NANOG at the time IPv4 was being rolled out, there would have been an > > equivalent discussion, except substitute /8 for /48, and probably site for > > end user -- but the arguments, I'm sure, would have been the same, and they > > would have sounded just as rational to the participants then, too. > > > > In fact, there are probably people on this list now who *were* around when > > the initial IPv4 addressing policies were thought up... > > We shouldn't waste the IPv6 addresses, but giving each end user a /56 > isn't wasteful. It's even less than the protocol was designed for, and > there is nobody who has conceived so far how this would be a problem > before we've even used up 1/(2^16) of the available space and we can fix > any problem seen by then with 65536 times more addresses to use in a less > "wasteful" manner. > > Crippling IPv6 by just giving people a /64 isn't helping anybody, it's > just delaying and complicating the IPv6 rollout to end users. We should > make sure people are used to the fact to have routing in their home (or at > least the possibility to do so). And I think I'd like to say that, as someone who was around in some of the earlier days of the 'net, there were a lot of questions even at that time about allocation of /8's - it was obvious that, even at the time, we weren't going to be able to allocate every school a /8, and there were questions about how to make the class B and C spaces work well. Regardless of your opinion of what might have happened at the time, we were aware that there were limits. IPv6 was explicitly designed for this. If it would happen to turn out to be a problem, which appears exceedingly unlikely within any reasonable timeframe, as noted, we have the option to change strategy. Allocating smaller blocks will just encourage brokenness. This is not a desirable goal. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples. From nanog at daork.net Sun May 3 18:29:09 2009 From: nanog at daork.net (Nathan Ward) Date: Mon, 4 May 2009 11:29:09 +1200 Subject: Where to buy Internet IP addresses In-Reply-To: <49FD4D75.40702@internode.com.au> References: <200905012340.n41NeNKD093855@drugs.dv.isc.org> <49FB9A86.1080101@rollernet.us> <49FBA5DA.2020707@bogus.com> <6eb799ab0905022120o5be64c56ye664a8d00bd4eb91@mail.gmail.com> <49FD4D75.40702@internode.com.au> Message-ID: <472D869B-D227-4DA6-9AFD-724BABB39024@daork.net> On 3/05/2009, at 7:53 PM, Matthew Moyle-Croft wrote: > James Hess wrote: >> >> A /62 takes care of that unusual case, no real need for a /56 for >> the average residential user; that's just excessive. Before >> wondering >> about the capabilities of home routers.. one might wonder if there >> will even be _home_ "routers" ? >> >> > I think you'd want to do a /60 so it's on a "nibble" boundary. But > by then you might as well do a /56. > > My personal feeling is that 99% of home networks will use a single / > 64, but we'll be giving out /60s and /56s to placate the 1% who are > going to jump up and down and shout at us about it because of some > reason that they feel makes it all unfair or that we're "thinking > like ipv4 not ipv6" etc. 17% of packets leaving an ISP here in NZ were from behind double NAT. (or, they went through 2 routing hops in the home, which I suspect is fairly rare) Why does this happen? $customer has an ADSL router with no wireless, then they go buy a "wireless router" and plug the ADSL router in to the "internet" port. I suspect your market is not that different to NZ. > It's possible that home networks will gain some ability (in a > standard fashion) to use more than one /64, but I doubt it - it's > much easier to do resource discovery on a single broadcast domain > for things like printers, file sharing etc. The above mentioned sort of stuff will keep happening, I'm sure, and because the ADSL router and the wireless router are the only devices on the same subnet, no service discovery things need to happen. I have an idea brewing to allow routers to forward PD requests. The idea would be that a BRAS/LNS only assigns a /64 for each PD request, and the customer router forwards PD requests for routers attached to their inside interface. That way, we can chain up to 16 subnets in the home. The BRAS can reserve a /60 or /56 or whatever for each customer so they are contiguous, or whatever. -- Nathan Ward From if at xip.at Sun May 3 18:45:28 2009 From: if at xip.at (Ingo Flaschberger) Date: Mon, 4 May 2009 01:45:28 +0200 (CEST) Subject: [quagga-users 10587] bgpd crash - apologies (fwd) Message-ID: ---------- Forwarded message ---------- Date: Mon, 04 May 2009 00:38:54 +0300 From: Geert Jan de Groot To: quagga-users at lists.quagga.net Subject: [quagga-users 10587] bgpd crash - apologies Hello, I learned today that a BGP announcement for which I am the tech-c, is causing difficulties with Quagga. First of all, I apologise; it's only today that I heard about these difficulties. I arrived less than 20 hours ago in Cairo as part of a setup-team for the upcoming AfNOG-10 meeting. We will be multi-homed this time, and hence applied for (and obtained) an ASN. Per RIR-policy active since 1-1-2009, these ASNs are 32-bit ASNs so AS327686 (AS5.6) is what is used. Currently, the local host team is provisioning links etc and hence you may have seen this problem come and go. I do not know why they choose to do prepending, but suspect it has to do with ability to set policy. I have a very, very long list of things to set up for the conference but will try any of the workarounds that have been suggested to me today. At the same time, I kindly but strongly ask to implement the fix that has been posted on various lists. One of the aims of this setup is to demonstrate that 32-bit ASNs do work and people should not steer away from them, especially since the pool of 16-bit ASNs is shrinking fast. A showcase network goes a long way in this regard. I do apologise for this unexpected, undesired side-effect. This was obviously not intended, and I apologise. It was 1996 when Paul Traina, at that time with Cisco, was doing AS path prepending for the very first time. This caused an assertion error with gated, which (among others) ANS was using at that time. I did administer AS3333 back then and my gated boxes, too, did crash, so I have been "victimized" myself before. It is perhaps ironic that 12 years later I'm again involved. Again, my sincere apologies. Geert Jan _______________________________________________ Quagga-users mailing list Quagga-users at lists.quagga.net http://lists.quagga.net/mailman/listinfo/quagga-users From ccaputo at alt.net Sun May 3 23:48:49 2009 From: ccaputo at alt.net (Chris Caputo) Date: Mon, 4 May 2009 04:48:49 +0000 (UTC) Subject: [quagga-users 10587] bgpd crash - apologies (fwd) In-Reply-To: References: Message-ID: On Mon, 4 May 2009, Ingo Flaschberger wrote: > ---------- Forwarded message ---------- > Date: Mon, 04 May 2009 00:38:54 +0300 > From: Geert Jan de Groot > To: quagga-users at lists.quagga.net > Subject: [quagga-users 10587] bgpd crash - apologies > > Hello, > > I learned today that a BGP announcement for which I am the tech-c, > is causing difficulties with Quagga. First of all, I apologise; > it's only today that I heard about these difficulties. [...] A fix is here: https://www.caputo.com/foss/quagga-0.99.10-BGP-4-byte-ASN-bug-fixes.patch https://www.caputo.com/foss/quagga-0.99.11-BGP-4-byte-ASN-bug-fixes.patch (the patches are identical. naming is just for clarity.) Chris From barton at gnaps.com Mon May 4 00:14:19 2009 From: barton at gnaps.com (Barton F Bruce) Date: Mon, 4 May 2009 01:14:19 -0400 Subject: Slightly OT: Calculating HVAC requirements for server rooms References: <1b5c1c150905011759p6b6a31berf8f0afc2bc7e2125@mail.gmail.com><49FBA2A3.3030401@emmanuelcomputerconsulting.com> <3c3e3fca0905020313v2477d406q8fdff470b4c1f176@mail.gmail.com> Message-ID: Below are a few snippets from recent posts, in no particular order, that had me saying to myself "does not anyone remember an interesting alternative I thought had come up on NANOG a few years ago?" Well maybe it was some other list, but it is not really worth going back and looking. It isn't quite true, or totally wise, but you can EASILY ignore HOT and COLD isle systems, and you could even have adjacent cabinets in any row blowing opposite directions and randoml;y facing across the isle to a cabinet in the next row that could be facing EITHER WAY, and you need not care! (don't really do it, BUT YOU SAFELY COULD) No raised floors needed, unless you need to for cables, and relatively low ceilings and ladder racks / cable trays with massive wads of cables that would block normally required air flow being no problem at all. And NO it isn't chilled water to leak and destroy your equipment Oh, and at maybe only 30KW capacity per cabinet (with an extra very REAL 50% reserve capacity) - is that enough for you...?? And no problem with random cabinets or multiple whole rows with no equipment yet or even just turned off until they pay their bill. Nothing freezes, and nothing roasts. Just works. All the pieces I snipped below are about trying to get the heat from the cabinets to the CRAC and the cold air back with as little mixing and possible. The more you mix, the more total air you have to circulate and the lower your efficiency goes. *** start of snips *** (And the elephant in the room no one has mentioned is "air flow". Cooling capacity is only half the equation. Air flow *volume* is just as important.) You shouldn't even *have* a drop ceiling in a modern computer room. You want the room to be as tall as practical so that the air from the hot aisles has somewhere to go on its way back to the HVAC, other than back through and around the cabinets. > I love my 30' ceiling. Even with all the things that are wrong with our > HVAC setup, the servers survive due to that ceiling. > >> ... versus HVAC professionals that understand the holistic picture >> including hot aisles, cold aisles, humidity control and flow. I >> wouldn't want to call in a professional without first understanding >> the problem well enough to assess whether I was getting a competent >> answer. > The return feed is below the units pulling > ambient air, and the cold air is injected 15+ feet above the isle behind > the servers, intermixing with the hot air as it rises up the wall. > > At least it works, but it could be better and changes will need to be > made before I can reach 50% capacity in the racks. *** end of snips *** A few simplifying ground rules. An existing "dumb-ass" grade CRAC system can be used to control humidity and to do any required fresh air changes, etc. With cabinets of electronics, we are ONLY talking about a sensible load with the stuff below. We DO NOT WANT or need to deal with humidity with the system I'm referring to. It is designed to JUST remove sensible heat VERY VERY efficiently. Its refrigerant lines, both supply and return, are almost at room temperature. No sweating, no dripping, no insulation really needed! Piping from the mechanical room is designed for low pressure drop for efficiency, but this refrigerant, R744, does a lot of cooling with very small pipes. The regular refrigeration systems we are used to have oil circulating with the refrigerant and special care is needed to ensure its return to the compressor. Also, the traditional system needs a thermostatic expansion valve (TXV) so the evaporator has liquid refrigerant until almost the end of the coil, but no liquid is returned to damage the compressor. A typical TXV may have a MOPD (minimum operating pressure differential) of 100PSI. In some cool outside weather conditions, you artificially throttle fans or even bypass some of the condenser coils to keep your head pressure up to keep that 100PSI MOPD so you get adequate liquid flow through the TXV and don't starve the evaporator (which cuts its capacity and can lead to icing that can progress across the face of some coil designs and then blocks air flow). But keeping that 100 PSI in mild weather is inefficient, too. Anyway, with NO oil circulation, and NO compressor in the loop at all and NO TXV needed, you have something that is very close to a two pipe steam heating system with a condensate return pump for the boiler. Typical of many buildings and even some larger homes especially some years ago. Here, however, the "BOILER" is a finned coil on the back of each of your cabinets. This coil is fed from a local manifold via ball valves, excess flow safety shutoff valves, and flexible metal hoses. The finned coil equipped rear door also has its own fans. It gets raw undiluted hot air exiting your equipment, passes it over coils loaded with a liquid refrigerant just below room temperature and AT a system pressure that any additional heat added will just boil off some of the liquid which will be entrained as bubbles in the slurry. The cabinet air exiting the coil-door's fans is AT room temperature. You have enough excess liquid R744 flowing that you could handle a 50% overload beyond rated capacity. This excess liquid flow costs almost nothing as the piping is all designed for low pressure drop and it is a low head pressure centrifugal pump that keeps each evaporator swept with enough liquid for 50% overload and yet there are NO ISSUES at all with partial or no load cabinets. No super cold spots, etc. Instead of the "radiator" in your house, the condenser here looks like a classic shell and tube heat exchanger where the returning refrigerant gas and liquid slurry is simply dumped into the shell and any entrained liquid drops to the sump at the bottom or even to a seperate "receiver" tank below if so equipped, and the returning gas simply is condensed on the outside surfaces of the tubes in the tube bundle. These tubes themselves can be cooled by chilled water that may exist in many big buildings, or may be DX coils for any traditional refrigeration system that comfortably can be modulated to run over a wide range of loads and always keep the R744 just below room temperature. There is even a simpler system these folks make that doesn't even have the R744 pump, but depends on the "shell and tube" condenser and receiver to be physicall enough ABOVE the cabinets that gravity adequately feeds the cabinets (those with no heat load will simply have their coils stay full of liquid) and only gas goes back to the condenser. This is a great way to have you building chilled water system do the work for you and yet you can keep water piping offset to the next room and so OUT of your datacenter (could be on the floor above if that next room isn't high enough). This is still the classic 2 pipe steam system but all gravity return with no condensate pump needed. So why isn't everyone doing this? TOO DARN EXPENSIVE! - needs competition. Europeans selling un USA. "NOT INVENTED HERE"? And, of course, R744 is simply CO2! At a little over 80F liquid CO2 gets to 1000PSI. The piping for this needs to be done by folks a bit better trained than the average refrigeration guy. Some would be fine, but many need a little training. Thick walled copper could be used, but I think all this datacenter CO2 stuff is being done in welded stainless steel and any unions would be bolted flanged connections. Properly trained datacenter staff can valve off and simply VENT (slowly) off any remaining CO2 and remove a leaking or whatever door assembly that needs to be changed. Normal chassis fans and if needed a floor fan in front of the cabinet will move enough heat out of the cabinet so it keeps running and the inlet air for a few adjacent cabinets is now a few degrees hotter but their exit air is ALL at normal room temperature. The rest of the room isn't impacted at all. The replacement door gets connected, refrigerant valve cracked at one end lets in R744 to sweep out any air to a vent you open at the other end of the coil (unlike regular refrigerants, this is LEGAL!!!) vent plenty excess, no problem (you MUST NOT ADD AIR the the big system). Seal it up, open bothsupply and return valves fully, and you are back in business. Your equipment in that rack could have had its "cooling door" non functional for weeks if necessary with NO PROBLEM (assuming the others near by were all working). Real world high reliability configuration would have several systems running in parallel. Perhaps no two adjacent rows on the same system. Simple valving could allow sections of one normally isolated system to be shared with another or a built in spare in an emergency. There are none of the oil return to many parallel compressors issues. You simply DO need to be sure each running section has enough liquid CO2 to work and that could be easily taken from an overfilled other system or the LARGE on site refrigerated bulk thermos like storage tank typically running just under 300PSI you probably should have available, anyway. It might also do double duty as a CO2 fire suppression flooding system, but CO2 flooding can kill people if done wrong. Maybe the onsite soft drink system in the cafeteria already has a bulk delivered CO2 system that could be tapped in an emergency for some CO2. Clickable brochures and such on the lower half of this following page will be of interest: http://www.trox.co.uk/aitcs/products/CO2OLrac/index.html They are in the USA, too. From fweimer at bfk.de Mon May 4 02:03:20 2009 From: fweimer at bfk.de (Florian Weimer) Date: Mon, 04 May 2009 09:03:20 +0200 Subject: Where to buy Internet IP addresses In-Reply-To: <49FBA5DA.2020707@bogus.com> (Joel Jaeggli's message of "Fri, 01 May 2009 18:46:02 -0700") References: <200905012340.n41NeNKD093855@drugs.dv.isc.org> <49FB9A86.1080101@rollernet.us> <49FBA5DA.2020707@bogus.com> Message-ID: <82y6tds62v.fsf@mid.bfk.de> * Joel Jaeggli: > Seth Mattinen wrote: > >> >> I hear this a lot, but how many "linksys default channel 6" end users >> really have more than one subnet, or even know what a subnet is? > > By definition, every single one of them that buys wireless router, then > buys another and hangs it off the first. That happens more often then > you would think. Isn't the traffic bridged, so that you don't have to route WINS and other stuff? Then it's still a single subnet. -- 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 swmike at swm.pp.se Mon May 4 02:19:23 2009 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Mon, 4 May 2009 09:19:23 +0200 (CEST) Subject: Where to buy Internet IP addresses In-Reply-To: <82y6tds62v.fsf@mid.bfk.de> References: <200905012340.n41NeNKD093855@drugs.dv.isc.org> <49FB9A86.1080101@rollernet.us> <49FBA5DA.2020707@bogus.com> <82y6tds62v.fsf@mid.bfk.de> Message-ID: On Mon, 4 May 2009, Florian Weimer wrote: >> By definition, every single one of them that buys wireless router, then >> buys another and hangs it off the first. That happens more often then >> you would think. > > Isn't the traffic bridged, so that you don't have to route WINS and > other stuff? Then it's still a single subnet. Most people don't have the skill to do this, so they just hang the second NAT box behind the first and it "works". So the lesson from this is that any home IPv6 gateway needs to be able to both receive (from ISP) and provide PD (towards other home devices), as this is something people will want to do (because they do it today). -- Mikael Abrahamsson email: swmike at swm.pp.se From nanog at daork.net Mon May 4 03:08:02 2009 From: nanog at daork.net (Nathan Ward) Date: Mon, 4 May 2009 20:08:02 +1200 Subject: Where to buy Internet IP addresses In-Reply-To: References: <200905012340.n41NeNKD093855@drugs.dv.isc.org> <49FB9A86.1080101@rollernet.us> <49FBA5DA.2020707@bogus.com> <82y6tds62v.fsf@mid.bfk.de> Message-ID: <214A65F4-209E-401D-B67D-DBC33A515D09@daork.net> On 4/05/2009, at 7:19 PM, Mikael Abrahamsson wrote: > On Mon, 4 May 2009, Florian Weimer wrote: > >>> By definition, every single one of them that buys wireless router, >>> then >>> buys another and hangs it off the first. That happens more often >>> then >>> you would think. >> >> Isn't the traffic bridged, so that you don't have to route WINS and >> other stuff? Then it's still a single subnet. > > Most people don't have the skill to do this, so they just hang the > second NAT box behind the first and it "works". > > So the lesson from this is that any home IPv6 gateway needs to be > able to both receive (from ISP) and provide PD (towards other home > devices), as this is something people will want to do (because they > do it today). I think that they have to be forwarded. What do you do if people chain three routers? How does your actual CPE know to dish out a /60 and not a /64 or something? What if someone chains four? What if someone puts three devices behind the second? These are weird topologies, sure, but coming up with some algorithm to handle some of them and not others is going to be too complicated, and leave some people without a workable solution. Forwarding these requests up to the ISP's router and having several PDs per end customer is in my opinion the best way to go. -- Nathan Ward From swmike at swm.pp.se Mon May 4 03:31:10 2009 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Mon, 4 May 2009 10:31:10 +0200 (CEST) Subject: Where to buy Internet IP addresses In-Reply-To: <214A65F4-209E-401D-B67D-DBC33A515D09@daork.net> References: <200905012340.n41NeNKD093855@drugs.dv.isc.org> <49FB9A86.1080101@rollernet.us> <49FBA5DA.2020707@bogus.com> <82y6tds62v.fsf@mid.bfk.de> <214A65F4-209E-401D-B67D-DBC33A515D09@daork.net> Message-ID: On Mon, 4 May 2009, Nathan Ward wrote: > I think that they have to be forwarded. What do you do if people chain > three routers? How does your actual CPE know to dish out a /60 and not a > /64 or something? What if someone chains four? What if someone puts > three devices behind the second? This is a CPE problem, the main homegateway can decide to dish out /64s to all other home routers, this means they can have a bunch. It also means they can't chain 3 in serial, unless the home user decides to hand out /60s to each and only have 3 of them connected to the main CPE. > These are weird topologies, sure, but coming up with some algorithm to handle > some of them and not others is going to be too complicated, and leave some > people without a workable solution. This is where innovation will happen in the home market, but only if we hand them a /56 to start with. > Forwarding these requests up to the ISP's router and having several PDs per > end customer is in my opinion the best way to go. Why is this better? Why do you want to waste your tcam entries like that? A single /56 per customer makes you have the fewest amount of tcam entries in any solution I can imagine. All other solutions require more. -- Mikael Abrahamsson email: swmike at swm.pp.se From nanog at daork.net Mon May 4 04:20:15 2009 From: nanog at daork.net (Nathan Ward) Date: Mon, 4 May 2009 21:20:15 +1200 Subject: Where to buy Internet IP addresses In-Reply-To: References: <200905012340.n41NeNKD093855@drugs.dv.isc.org> <49FB9A86.1080101@rollernet.us> <49FBA5DA.2020707@bogus.com> <82y6tds62v.fsf@mid.bfk.de> <214A65F4-209E-401D-B67D-DBC33A515D09@daork.net> Message-ID: <9D015E0D-53C1-4155-A6F4-C3158F06396F@daork.net> On 4/05/2009, at 8:31 PM, Mikael Abrahamsson wrote: > On Mon, 4 May 2009, Nathan Ward wrote: > >> I think that they have to be forwarded. What do you do if people >> chain three routers? How does your actual CPE know to dish out a / >> 60 and not a /64 or something? What if someone chains four? What if >> someone puts three devices behind the second? > > This is a CPE problem, the main homegateway can decide to dish out / > 64s to all other home routers, this means they can have a bunch. It > also means they can't chain 3 in serial, unless the home user > decides to hand out /60s to each and only have 3 of them connected > to the main CPE. That is one way to do it, sure. However it makes things hard for end users, having to figure out how all this stuff fits together. My non technical friends have a enough time with 3.5mm jack to RCA audio cables, but they managed to get a wireless router and plug it in and have it magically work for them. >> Forwarding these requests up to the ISP's router and having several >> PDs per end customer is in my opinion the best way to go. > > Why is this better? Why do you want to waste your tcam entries like > that? A single /56 per customer makes you have the fewest amount of > tcam entries in any solution I can imagine. All other solutions > require more. Because it allows the home user to arrange their network however they want, up to 16 subnets, without having to have any knowledge of how things actually work. I'm sure we can both think of a few ways to make this not cost a whole lot of TCAM entries, either with protocol support, or in internal implementation specific ways. I can immediately think of two ways that cost no extra TCAM entries. -- Nathan Ward From swmike at swm.pp.se Mon May 4 05:41:47 2009 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Mon, 4 May 2009 12:41:47 +0200 (CEST) Subject: Where to buy Internet IP addresses In-Reply-To: <9D015E0D-53C1-4155-A6F4-C3158F06396F@daork.net> References: <200905012340.n41NeNKD093855@drugs.dv.isc.org> <49FB9A86.1080101@rollernet.us> <49FBA5DA.2020707@bogus.com> <82y6tds62v.fsf@mid.bfk.de> <214A65F4-209E-401D-B67D-DBC33A515D09@daork.net> <9D015E0D-53C1-4155-A6F4-C3158F06396F@daork.net> Message-ID: On Mon, 4 May 2009, Nathan Ward wrote: > Because it allows the home user to arrange their network however they > want, up to 16 subnets, without having to have any knowledge of how > things actually work. I don't see how your idea of doing on-demand-/64 is any easier than handing them 256 /64:s to begin with. But it seems we're nog getting any further here. I don't understand why you want to complicate things, you don't understand why I want to do things the way I do, let's just leave it at that. -- Mikael Abrahamsson email: swmike at swm.pp.se From bmanning at vacation.karoshi.com Mon May 4 06:34:20 2009 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Mon, 4 May 2009 11:34:20 +0000 Subject: Where to buy Internet IP addresses In-Reply-To: References: <200905012340.n41NeNKD093855@drugs.dv.isc.org> <49FB9A86.1080101@rollernet.us> <49FBA5DA.2020707@bogus.com> <82y6tds62v.fsf@mid.bfk.de> <214A65F4-209E-401D-B67D-DBC33A515D09@daork.net> <9D015E0D-53C1-4155-A6F4-C3158F06396F@daork.net> Message-ID: <20090504113420.GA30079@vacation.karoshi.com.> back to the subject matter... i've been told that in the (roughly) NANOG region, that ARIN's 2008-6 or some rough analog should be in place on or before 01jun2009. What is 2008-6? https://www.arin.net/policy/proposals/2008_6.html Draft Policy 2008-6 Emergency Transfer Policy for IPv4 Addresses Author: Bill Darte Date: 24 January 2009 Policy statement: 8.4 Emergency Transfer Policy for IPv4 Addresses For a period of 3 years from policy implementation, authorized resource holders served by ARIN may designate a recipient for number resources they release to ARIN. ok... so lets just presume, for the mo, that I am an "authorized resource holder served by ARIN" and I have a /9 that is becoming a bother. One of my clients, holding discontigious /16's in that /9, desires to use 2008-6 ... and I have no problems w/ that ... HOWEVER. I want to dump the whole /9. How do I find viable receipients for the rest of the space? Get out my pushcart and roam the streets with my bullhorn; "... /16's, /24's... alive, alive Oh!...." --bill From jgreco at ns.sol.net Mon May 4 06:39:15 2009 From: jgreco at ns.sol.net (Joe Greco) Date: Mon, 4 May 2009 06:39:15 -0500 (CDT) Subject: Where to buy Internet IP addresses In-Reply-To: <214A65F4-209E-401D-B67D-DBC33A515D09@daork.net> from "Nathan Ward" at May 04, 2009 08:08:02 PM Message-ID: <200905041139.n44BdFYA093271@aurora.sol.net> > I think that they have to be forwarded. What do you do if people chain > three routers? How does your actual CPE know to dish out a /60 and not > a /64 or something? What if someone chains four? What if someone puts > three devices behind the second? > > These are weird topologies, sure, but coming up with some algorithm to > handle some of them and not others is going to be too complicated, and > leave some people without a workable solution. > > Forwarding these requests up to the ISP's router and having several > PDs per end customer is in my opinion the best way to go. How is it the ISP's router is able to handle this? Be specific. Now explain why that can't be made to work at the CPE level. There hasn't been a lot of consensus on exactly how this should work (haberman, bykim, arunt, rao, stenberg, etc). so I am conveniently doing a bit of handwaving, perhaps. One of the goals of providing larger address spaces was to reduce (and hopefully eliminate) the need to burn forwarding table entries where doing so isn't strictly necessary. When we forget this, it leads us to the same sorts of disasters that we currently have in v4. ... 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 bicknell at ufp.org Mon May 4 08:14:47 2009 From: bicknell at ufp.org (Leo Bicknell) Date: Mon, 4 May 2009 09:14:47 -0400 Subject: Where to buy Internet IP addresses In-Reply-To: <20090504113420.GA30079@vacation.karoshi.com.> References: <200905012340.n41NeNKD093855@drugs.dv.isc.org> <49FB9A86.1080101@rollernet.us> <49FBA5DA.2020707@bogus.com> <82y6tds62v.fsf@mid.bfk.de> <214A65F4-209E-401D-B67D-DBC33A515D09@daork.net> <9D015E0D-53C1-4155-A6F4-C3158F06396F@daork.net> <20090504113420.GA30079@vacation.karoshi.com.> Message-ID: <20090504131446.GA35312@ussenterprise.ufp.org> In a message written on Mon, May 04, 2009 at 11:34:20AM +0000, bmanning at vacation.karoshi.com wrote: > i've been told that in the (roughly) NANOG region, that ARIN's 2008-6 or some rough > analog should be in place on or before 01jun2009. What is 2008-6? I strongly recommend waiting a few days before thinking about this issue too hard. The policy results of ARIN XXIII will be posted in a few days to arin-ppml and should provide some clarity. The wait will not be long. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From jbates at brightok.net Mon May 4 08:20:33 2009 From: jbates at brightok.net (Jack Bates) Date: Mon, 04 May 2009 08:20:33 -0500 Subject: Where to buy Internet IP addresses In-Reply-To: References: <200905012340.n41NeNKD093855@drugs.dv.isc.org> <49FB9A86.1080101@rollernet.us> <49FBA5DA.2020707@bogus.com> <6eb799ab0905022120o5be64c56ye664a8d00bd4eb91@mail.gmail.com> <49FD4D75.40702@internode.com.au> Message-ID: <49FEEBA1.10306@brightok.net> Mikael Abrahamsson wrote: > It's short sighted and silly to design your service around handing out > /64s to people and then you have to redesign it when demand for multiple > subnets come around. Design it around /56 to begin with, and you will > have solved the problem for the future, not just for now. > Then tell RIR's to quit insisting that /56's have SWIP's. They can't very well be dynamic in nature via PD if they are being SWIP'd. Until then, /60 sounds fine. Allows higher capacity per /48 on a node and will give most customers more than they will ever use. Jack From tore at linpro.no Mon May 4 08:41:23 2009 From: tore at linpro.no (Tore Anderson) Date: Mon, 04 May 2009 15:41:23 +0200 Subject: Where to buy Internet IP addresses In-Reply-To: <49FEEBA1.10306@brightok.net> References: <200905012340.n41NeNKD093855@drugs.dv.isc.org> <49FB9A86.1080101@rollernet.us> <49FBA5DA.2020707@bogus.com> <6eb799ab0905022120o5be64c56ye664a8d00bd4eb91@mail.gmail.com> <49FD4D75.40702@internode.com.au> <49FEEBA1.10306@brightok.net> Message-ID: <49FEF083.3080706@linpro.no> * Jack Bates > Then tell RIR's to quit insisting that /56's have SWIP's. They can't > very well be dynamic in nature via PD if they are being SWIP'd. I believe this is not the case with RIPE, you'll only need to register assignments that are larger than /48 in their database. See ripe-466 section 5.5. BR, -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com/ From swmike at swm.pp.se Mon May 4 08:43:35 2009 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Mon, 4 May 2009 15:43:35 +0200 (CEST) Subject: Where to buy Internet IP addresses In-Reply-To: <49FEEBA1.10306@brightok.net> References: <200905012340.n41NeNKD093855@drugs.dv.isc.org> <49FB9A86.1080101@rollernet.us> <49FBA5DA.2020707@bogus.com> <6eb799ab0905022120o5be64c56ye664a8d00bd4eb91@mail.gmail.com> <49FD4D75.40702@internode.com.au> <49FEEBA1.10306@brightok.net> Message-ID: On Mon, 4 May 2009, Jack Bates wrote: > Then tell RIR's to quit insisting that /56's have SWIP's. They can't > very well be dynamic in nature via PD if they are being SWIP'd. I never heard of this requirement before, but I am not in the ARIN region. There is no technical reason why you can't give the user the same /56 each time via PD, the same way some offer static IPs via DHCP. > Until then, /60 sounds fine. Allows higher capacity per /48 on a node and > will give most customers more than they will ever use. Try to change the policy instead. -- Mikael Abrahamsson email: swmike at swm.pp.se From cabo at tzi.org Mon May 4 08:57:53 2009 From: cabo at tzi.org (Carsten Bormann) Date: Mon, 4 May 2009 15:57:53 +0200 Subject: Where to buy Internet IP addresses In-Reply-To: <214A65F4-209E-401D-B67D-DBC33A515D09@daork.net> References: <200905012340.n41NeNKD093855@drugs.dv.isc.org> <49FB9A86.1080101@rollernet.us> <49FBA5DA.2020707@bogus.com> <82y6tds62v.fsf@mid.bfk.de> <214A65F4-209E-401D-B67D-DBC33A515D09@daork.net> Message-ID: <667472E7-31AA-4154-B37B-3A18F72E376B@tzi.org> On May 4, 2009, at 10:08, Nathan Ward wrote: > Forwarding these requests up to the ISP's router and having several > PDs per end customer is in my opinion the best way to go. If the ISP sees (and has to hand out) the PD, some bean counter will put a price tag on it ("differential pricing"). If there is a price tag on it, nobody will pay the higher price, and everybody will put in a kludge to get by with one /64. Think about it: That's exactly the reason why we got mired in the InterNAT. Really, /56 for everyone is the only way back to an Internet. Gruesse, Carsten From jmaimon at ttec.com Mon May 4 09:03:44 2009 From: jmaimon at ttec.com (Joe Maimon) Date: Mon, 04 May 2009 10:03:44 -0400 Subject: Where to buy Internet IP addresses In-Reply-To: <200905041139.n44BdFYA093271@aurora.sol.net> References: <200905041139.n44BdFYA093271@aurora.sol.net> Message-ID: <49FEF5C0.9050109@ttec.com> Joe Greco wrote: > One of the goals of providing larger address spaces was to reduce (and > hopefully eliminate) the need to burn forwarding table entries where > doing so isn't strictly necessary. When we forget this, it leads us > to the same sorts of disasters that we currently have in v4. > > ... JG And if you are encouraging /48 handouts, /32 isnt large enough to prevent that on the global level. From leo.vegoda at icann.org Mon May 4 09:06:26 2009 From: leo.vegoda at icann.org (Leo Vegoda) Date: Mon, 4 May 2009 07:06:26 -0700 Subject: Where to buy Internet IP addresses In-Reply-To: <49FEEBA1.10306@brightok.net> References: <200905012340.n41NeNKD093855@drugs.dv.isc.org> <49FB9A86.1080101@rollernet.us> <49FBA5DA.2020707@bogus.com> <6eb799ab0905022120o5be64c56ye664a8d00bd4eb91@mail.gmail.com> <49FD4D75.40702@internode.com.au> <49FEEBA1.10306@brightok.net> Message-ID: On May 4, 2009, at 6:21 AM, "Jack Bates" wrote: [...] >> > Then tell RIR's to quit insisting that /56's have SWIP's. They can't > very well be dynamic in nature via PD if they are being SWIP'd. If you are referring to section 6.5.4.4 of ARIN's NRPM, it does not require you to use SWIP. It requires that an ISP have records which allow ARIN to evaluate a request for a subsequent allocation. SWIP would work if ARIN wanted potentially 10s of millions of /56s in its whois database but it is not explicitly required and ARIN staff can presumably advise on suitable alternatives. Regards, Leo From jbates at brightok.net Mon May 4 09:10:08 2009 From: jbates at brightok.net (Jack Bates) Date: Mon, 04 May 2009 09:10:08 -0500 Subject: Where to buy Internet IP addresses In-Reply-To: <200905041139.n44BdFYA093271@aurora.sol.net> References: <200905041139.n44BdFYA093271@aurora.sol.net> Message-ID: <49FEF740.5020904@brightok.net> Joe Greco wrote: > How is it the ISP's router is able to handle this? Be specific. > The primary benefit of chaining is to allocate the correct network length to a router. We are not just talking from the ISP to the customer, but from the customer's CPE out to other routers. I believe chaining also needs support for network length memory (ie, hey, I've been handing out 18 networks, so a /59 is my aggregate I should ask for), and of course, network length negotiation for PD. > Now explain why that can't be made to work at the CPE level. > If the ISP hands out a /56, the CPE will still need support for chaining. All devices from the ISP out to the furthest customer daisy chained router would need support for it. Anything else requires manual configuration which is beyond some people's capabilities. If someone wants to daisy chain 4 routers serially, with 2 subnets per router off a routing CPE, then even if the ISP hands out a /56, each of those routers needs to support chaining PD requests and ideally support only requesting exactly what they need. So: ISP -> CPE router /56 -> Linksys1 /61 -> Linksys2 /62 & /63 -> Linksys3 /62 -> Linksys4 /63 This is without the ISP participating in the chaining since they are automatically assigning a /56. However, with negotiation in place, an ISP could set a cap on network length (/56 or /48 as they may see fit) and can participate in chaining. So customer starts out with a /64, adds a router than supports 4 networks and the ISP switches them to at least a /61, possibly even just issuing a renumber, reclaiming the original /64. It would also be possible to define boundary caps in addition to upper caps in negotiation. ie, if you only want a /64, we give that to you. If you want a /62, perhaps a /60 is handed out instead. This is probably more useful for the ISP than it is CPE side, as the CPE has no idea up front how much they can obtain and wasting networks downstream through the home network could cause them to run out of assignment space. In addition, most home network equipment should be able to support individual /64 chained PD's without that much trouble given their smaller routing tables. So a chained PD request for /64's across home networks might work. however, How's a home router supposed to know it's actually chaining in the home and not talking to an ISP? So whatever we did, it would have to be somewhat generic to support both topologies. Or the protocols need to also support flags to define "Hey! I'm an ISP!" Which actually isn't a bad idea. See below. > One of the goals of providing larger address spaces was to reduce (and > hopefully eliminate) the need to burn forwarding table entries where > doing so isn't strictly necessary. When we forget this, it leads us > to the same sorts of disasters that we currently have in v4. I agree. That being said, if I presume one table entry per customer, it doesn't matter if that entry is a /64, /60, or a /56. Unfortunately, DHCPv6 itself doesn't seem to support dynamic length negotiation at this time, or chaining requests for supporting the automatic numbering of an entire home network with 5+ routers connected however the user wanted to connect them, perhaps completely inefficient and with routing loops. To work properly, this will have to be standardized, or home router implementations won't handle clueless home networking very well in a number of configurations. It may be useful to treat PD or some other protocol that handles the numbering, routing, and loop detection differently for home based networks where there is a presumption that just plugging something in should work without any knowledge of what happens inside the device. Jack From jgreco at ns.sol.net Mon May 4 09:27:41 2009 From: jgreco at ns.sol.net (Joe Greco) Date: Mon, 4 May 2009 09:27:41 -0500 (CDT) Subject: Where to buy Internet IP addresses In-Reply-To: <49FEF5C0.9050109@ttec.com> from "Joe Maimon" at May 04, 2009 10:03:44 AM Message-ID: <200905041427.n44ERf0A003326@aurora.sol.net> > Joe Greco wrote: > > One of the goals of providing larger address spaces was to reduce (and > > hopefully eliminate) the need to burn forwarding table entries where > > doing so isn't strictly necessary. When we forget this, it leads us > > to the same sorts of disasters that we currently have in v4. > > And if you are encouraging /48 handouts, /32 isnt large enough to > prevent that on the global level. I don't know that I'm *en*couraging /48 handouts, but on the other hand, I'm not sure I'm *dis*couraging it either. On one hand, there's a reasonable argument to be made that the average home user does not currently have enough devices to fill more than a /124's worth of space. But. You have RFC3041 and similar techniques, stateless autoconfig, and a variety of other general things that make it really awful for the default ethernet network size to be something besides a /64. Further, it seems clear from most discussions I've had, that people really do want or need the ability to have multiple networks, for a variety of practical reasons. Many of these have to do with keeping different zones firewalled in particular ways, So, really, I think the question is, how many unique firewalling policies is a household likely to have, and then, maybe how many other neighbors/friends/etc are also freeloading on that connection, each with the same needs? A /56 allows up to 256 networks. For today, that's pretty clearly all that I can reasonably imagine even a sophisticated home network along with several neighbors needing. Probably even within the next ten years. At some point, however, it is possible that a /48 would be a better choice. I would definitely prefer to see a /56, or maybe a /48, handed out today. If we get into the practice of handing out /64's, it is just going to encourage bad hacky design compromises and CPE/SOHO gear kludges in the future? ... 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 trejrco at gmail.com Mon May 4 09:37:20 2009 From: trejrco at gmail.com (TJ) Date: Mon, 4 May 2009 10:37:20 -0400 Subject: Where to buy Internet IP addresses In-Reply-To: <49FEF5C0.9050109@ttec.com> References: <200905041139.n44BdFYA093271@aurora.sol.net> <49FEF5C0.9050109@ttec.com> Message-ID: <003101c9ccc5$d570c190$805244b0$@com> >-----Original Message----- >From: Joe Maimon [mailto:jmaimon at ttec.com] >Sent: Monday, May 04, 2009 10:04 AM >To: Joe Greco >Cc: nanog list >Subject: Re: Where to buy Internet IP addresses > > > >Joe Greco wrote: > >> One of the goals of providing larger address spaces was to reduce (and >> hopefully eliminate) the need to burn forwarding table entries where >> doing so isn't strictly necessary. When we forget this, it leads us >> to the same sorts of disasters that we currently have in v4. >> >> ... JG > >And if you are encouraging /48 handouts, /32 isnt large enough to prevent that >on the global level. If you are handing out /48s then if have more than 64k clients (or will in the next few years) then You should ask (or should have asked) for more than a /32 (Need 128k clients? == /31) ... (Need 512k clients? == /29) ... ... ... (Need ~512,000k clients? == /19) And, again, each of those clients has 64k subnets. With each subnet supporting as many hosts as they want to put there. And, we can allocate 2^16 (64k) of THOSE (/19) sized allocations from the CURRENT (2000::)/3. IMHO - While that should last us a "long time", we can follow that up with 4000::/3 - and revisit policies then, as needed. And, we could do something like use /56s for home-users and the math above "shifts larger" ... Ask, and ye shall receive. /TJ From black at csulb.edu Mon May 4 10:53:30 2009 From: black at csulb.edu (Matthew Black) Date: Mon, 04 May 2009 08:53:30 -0700 Subject: Minnesota to block online gambling sites? In-Reply-To: <16720fe00905020639l381dba73t8df219e6bfacc8f0@mail.gmail.com> References: <5b6f80200904291438j2fb6238fs50b93c59b912c41e@mail.gmail.com> <5b6f80200905020634h3dc34ecclb98fab3839762488@mail.gmail.com> <16720fe00905020639l381dba73t8df219e6bfacc8f0@mail.gmail.com> Message-ID: Instead of huffing and puffing your libertarian perspective (you called the AG's letter garbage), you might make a quick Google search of "18USC1084(d)," which provides a wealth of information on the legality of such enforcement actions. http://openjurist.org/325/f2d/148 Excerpted from the court decision: 18 U.S.C. 1084(d). 'When any common carrier, subject to the jurisdiction of the Federal Communications Commission, is notified in writing by a Federal, State, or local law enforcement agency, acting within its jurisdiction, that any facility furnished by it is being used or will be used for the purpose of transmitting or receiving gambling information in interstate or foreign commerce in violation of Federal, State or local law, it shall discontinue or refuse, the leasing, furnishing, or maintaining of such facility, after reasonable notice to the subscriber, but no damages, penalty or forfeiture, civil or criminal, shall be found against any common carrier for any act done in compliance with any notice received from a law enforcement agency. Nothing in this section shall be deemed to prejudice the right of any person affected thereby to secure an appropriate determination, as otherwise provided by law, in a Federal court or in a State or local tribunal or agency, that such facility should not be discontinued or removed, or should be restored.' matthew black speaking only for myself and not my employer california state university, long beach On Sat, 2 May 2009 09:39:02 -0400 Jeffrey Lyon wrote: > What a pile of garbage. I would definitely get a legal review of a > request like that before blocking any of my customer's traffic. > > > -- > Jeffrey Lyon, Leadership Team > jeffrey.lyon at blacklotus.net | http://www.blacklotus.net > Black Lotus Communications of The IRC Company, Inc. > > Look for us at HostingCon 2009 in Washington, DC on August 10th - 12th > at Booth #401. > > > > On Sat, May 2, 2009 at 9:34 AM, Ken Gilmour wrote: >> For anyone who cares, IMEGA released the letter from the state of >>Minnesota: >> >> http://www.imega.org/wp-content/uploads/2009/05/ab001dd4.pdf >> >> 2009/4/29 Ken Gilmour : >>> Hi there, >>> >>> I am just wondering if anyone knows any more about the attempt by >>> Minnesota to block online gambling companies other than what's >>> publicly available (e.g. >>> http://www.gambling911.com/gambling-news/minnesota-regulators-try-block-access-gambing-sites-042909.html)? >>> Such as a list or the letter to the providers? >>> >>> Thank you! >>> >>> Ken From pfunix at gmail.com Mon May 4 11:06:45 2009 From: pfunix at gmail.com (Beavis) Date: Mon, 4 May 2009 10:06:45 -0600 Subject: Minnesota to block online gambling sites? In-Reply-To: <5b6f80200904291438j2fb6238fs50b93c59b912c41e@mail.gmail.com> References: <5b6f80200904291438j2fb6238fs50b93c59b912c41e@mail.gmail.com> Message-ID: Hi, I host some gambling sites (off-shore) and I would like to get some info on how i can put minnesota IP blocks on my Filter-List to comply with their 'wacked politics' -beavis On Wed, Apr 29, 2009 at 3:38 PM, Ken Gilmour wrote: > Hi there, > > I am just wondering if anyone knows any more about the attempt by > Minnesota to block online gambling companies other than what's > publicly available (e.g. > http://www.gambling911.com/gambling-news/minnesota-regulators-try-block-access-gambing-sites-042909.html)? > Such as a list or the letter to the providers? > > Thank you! > > Ken > > -- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments From peiffer at umn.edu Mon May 4 11:03:54 2009 From: peiffer at umn.edu (Tim Peiffer) Date: Mon, 04 May 2009 11:03:54 -0500 Subject: Minnesota to block online gambling sites? In-Reply-To: References: <5b6f80200904291438j2fb6238fs50b93c59b912c41e@mail.gmail.com> <5b6f80200905020634h3dc34ecclb98fab3839762488@mail.gmail.com> <16720fe00905020639l381dba73t8df219e6bfacc8f0@mail.gmail.com> Message-ID: <49FF11EA.7030101@umn.edu> Not withstanding the legality of such an order, how would one operationally enforce that order? Does this order force carriers into transparent proxy so that L7 filtering can be done? Is the carrier also required to go through geolocator matching any given IP address with 'Minnesota' so that the filtering can be selectively applied? Tim Peiffer Network Support Engineer OIT / Networking and Telecommunications Services University of Minnesota / NorthernLights GigaPOP >> >> On Sat, May 2, 2009 at 9:34 AM, Ken Gilmour >> wrote: >>> For anyone who cares, IMEGA released the letter from the state of >>> Minnesota: >>> >>> http://www.imega.org/wp-content/uploads/2009/05/ab001dd4.pdf >>> >>> 2009/4/29 Ken Gilmour : >>>> Hi there, >>>> >>>> I am just wondering if anyone knows any more about the attempt by >>>> Minnesota to block online gambling companies other than what's >>>> publicly available (e.g. >>>> http://www.gambling911.com/gambling-news/minnesota-regulators-try-block-access-gambing-sites-042909.html)? >>>> >>>> Such as a list or the letter to the providers? >>>> >>>> Thank you! >>>> >>>> Ken -- Tim Peiffer Network Support Engineer Office of Information Technology University of Minnesota/NorthernLights GigaPOP From brandon.galbraith at gmail.com Mon May 4 11:10:07 2009 From: brandon.galbraith at gmail.com (Brandon Galbraith) Date: Mon, 4 May 2009 11:10:07 -0500 Subject: Minnesota to block online gambling sites? In-Reply-To: References: <5b6f80200904291438j2fb6238fs50b93c59b912c41e@mail.gmail.com> Message-ID: <366100670905040910h278ff46aha0f02f6f6a15a07e@mail.gmail.com> On Mon, May 4, 2009 at 11:06 AM, Beavis wrote: > Hi, > > ?I host some gambling sites (off-shore) and I would like to get some > info on how i can put minnesota IP blocks on my Filter-List to comply > with their 'wacked politics' > > -beavis > > On Wed, Apr 29, 2009 at 3:38 PM, Ken Gilmour wrote: >> Hi there, >> >> I am just wondering if anyone knows any more about the attempt by >> Minnesota to block online gambling companies other than what's >> publicly available (e.g. >> http://www.gambling911.com/gambling-news/minnesota-regulators-try-block-access-gambing-sites-042909.html)? >> Such as a list or the letter to the providers? >> >> Thank you! >> >> Ken Please see ongoing thread on geoIP to see how to go about doing this =) -brandon -- Brandon Galbraith Mobile: 630.400.6992 From johnl at iecc.com Mon May 4 12:35:23 2009 From: johnl at iecc.com (John Levine) Date: 4 May 2009 17:35:23 -0000 Subject: Minnesota to block online gambling sites? In-Reply-To: <49FF11EA.7030101@umn.edu> Message-ID: <20090504173523.50690.qmail@simone.iecc.com> >Not withstanding the legality of such an order, how would one >operationally enforce that order? The order has a list of IP addresses, so I expect the ISPs will just block those IPs in routers somewhere. Since offshore online gambling is equally illegal everywhere in the U.S., the ISPs have little reason to limit the block to Minnesota customers, giving them a lot of latitude in where they implement the block. Regards, John Levine, johnl at iecc.com, Primary Perpetrator of "The Internet for Dummies", Information Superhighwayman wanna-be, http://www.johnlevine.com, ex-Mayor "More Wiener schnitzel, please", said Tom, revealingly. From ken.gilmour at gmail.com Mon May 4 12:53:36 2009 From: ken.gilmour at gmail.com (Ken Gilmour) Date: Mon, 4 May 2009 11:53:36 -0600 Subject: Minnesota to block online gambling sites? In-Reply-To: <20090504173523.50690.qmail@simone.iecc.com> References: <49FF11EA.7030101@umn.edu> <20090504173523.50690.qmail@simone.iecc.com> Message-ID: <5b6f80200905041053m75d7689ct92b075ee7ba3a3da@mail.gmail.com> So is this going to become like the great firewall of China eventually? You can see in the letters that they are "going to see how it goes and then maybe start blocking more stuff" if they are successful. I can see a big nightmare heading this way if ISPs start caving in to requests like this. 2009/5/4 John Levine : >>Not withstanding the legality of such an order, how would one >>operationally enforce that order? > > The order has a list of IP addresses, so I expect the ISPs will just > block those IPs in routers somewhere. > > Since offshore online gambling is equally illegal everywhere in the > U.S., the ISPs have little reason to limit the block to Minnesota > customers, giving them a lot of latitude in where they implement the > block. > > Regards, > John Levine, johnl at iecc.com, Primary Perpetrator of "The Internet for Dummies", > Information Superhighwayman wanna-be, http://www.johnlevine.com, ex-Mayor > "More Wiener schnitzel, please", said Tom, revealingly. > > From jlewis at lewis.org Mon May 4 12:57:51 2009 From: jlewis at lewis.org (Jon Lewis) Date: Mon, 4 May 2009 13:57:51 -0400 (EDT) Subject: ground control to TWTelecom Message-ID: Seems like we were just here, but yet again, I'm having trouble verifying you're accepting a customer route (a different one than last week), and since sending me a copy of our prefix filter was apparently too much to ask, and you make it so easy to talk on the phone with anyone who knows what BGP is, here we are. Perhaps I'll track down our sales person and chew their ear. ---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From cgrundemann at gmail.com Mon May 4 13:09:10 2009 From: cgrundemann at gmail.com (Chris Grundemann) Date: Mon, 4 May 2009 12:09:10 -0600 Subject: ground control to TWTelecom In-Reply-To: References: Message-ID: <443de7ad0905041109p6f1597e1vcf09889fedd8f3c@mail.gmail.com> On Mon, May 4, 2009 at 11:57, Jon Lewis wrote: > Seems like we were just here, but yet again, I'm having trouble verifying > you're accepting a customer route (a different one than last week), and > since sending me a copy of our prefix filter was apparently too much to ask, > and you make it so easy to talk on the phone with anyone who knows what BGP > is, here we are. ?Perhaps I'll track down our sales person and chew their > ear. > > ---------------------------------------------------------------------- > ?Jon Lewis ? ? ? ? ? ? ? ? ? | ?I route > ?Senior Network Engineer ? ? | ?therefore you are > ?Atlantic Net ? ? ? ? ? ? ? ?| > _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ > > I assume you checked route-server.twtelecom.net for the route? -- Chris Grundemann weblog.chrisgrundemann.com From mcdermj at xenotropic.com Mon May 4 13:22:34 2009 From: mcdermj at xenotropic.com (Jeremy McDermond) Date: Mon, 4 May 2009 14:22:34 -0400 Subject: Minnesota to block online gambling sites? In-Reply-To: References: <5b6f80200904291438j2fb6238fs50b93c59b912c41e@mail.gmail.com> <5b6f80200905020634h3dc34ecclb98fab3839762488@mail.gmail.com> <16720fe00905020639l381dba73t8df219e6bfacc8f0@mail.gmail.com> Message-ID: On May 4, 2009, at 11:53 AM, Matthew Black wrote: > Instead of huffing and puffing your libertarian perspective (you > called the AG's letter garbage), you might make a quick Google > search of "18USC1084(d)," which provides a wealth of information on > the legality of such enforcement actions. > > http://openjurist.org/325/f2d/148 > But the Seventh Circuit specifically refuses to rule on any Constitutional issues surrounding the statute, instead choosing to rely on the district court's order that the defendants activities did not violate the law under 18 USC ?1084(d). The statute, as applied by Minnesota, could very well be unconstitutional and unenforceable in the manner that Minnesota seeks. In this case the First Amendment may be applicable because this seems to be a prior restraint on speech. Additionally, it is content based because it seeks to restrict speech due to its transmission or reception of gambling information. This means that the courts will apply a "strict scrutiny" test to it, requiring that the government have compelling reason to restrict the speech, and that they are applying the least restrictive method of controlling the speech. This is usually a difficult burden for them to sustain. In this case, the gambling issue seems much like the pornography issue. In _Center for Democracy and Technology v. Pappert_, 337 F.Supp 606 (W.D. Pa. 2004), the Eastern District of Pennsylvania looked at a Pennsylvania state law that looks much like this federal law and required ISPs operating in the state to block based on a letter from the state attorney general. In trying to determine whether the law provided the least restrictive method, the court looked to the types of blocking that the ISPs could employ. Specifically they examined DNS blocking, IP blocking, and URL filtering. The court decided that DNS blocking wasn't particularly effective and would require ISPs to deploy additional equipment. Additionally, URL filtering was impractical because of the deployment costs as well. The only practical alternative the court recognized was IP blocking, but they said that because it could severely overblock (because of name based virtual hosting) that it wasn't narrowly tailored enough block to pass Constitutional muster. The situation in _Center for Democracy_ seems remarkably similar to what Minnesota seems to be trying to do with the federal statute. There's certainly the chance that the federal district courts in Minnesota, or the appeals courts will disagree with the Western District of Pennsylvania's assessment of the situation, but as long as the strict scrutiny standard is applied, and there's a danger of overblocking, then I would expect the Supreme Court to uphold any as applied challenges to the statute. Disclaimer: I am not a lawyer. This is not legal advice. If you need legal advice, you should hire a real lawyer licensed in your jurisdiction. > matthew black > speaking only for myself and not my employer > california state university, long beach -- Jeremy McDermond Xenotropic Systems mcdermj at xenotropic.com From jbates at brightok.net Mon May 4 13:29:45 2009 From: jbates at brightok.net (Jack Bates) Date: Mon, 04 May 2009 13:29:45 -0500 Subject: Minnesota to block online gambling sites? In-Reply-To: References: <5b6f80200904291438j2fb6238fs50b93c59b912c41e@mail.gmail.com> <5b6f80200905020634h3dc34ecclb98fab3839762488@mail.gmail.com> <16720fe00905020639l381dba73t8df219e6bfacc8f0@mail.gmail.com> Message-ID: <49FF3419.7030407@brightok.net> Jeremy McDermond wrote: > manner that Minnesota seeks. In this case the First Amendment may be > applicable because this seems to be a prior restraint on speech. > Additionally, it is content based because it seeks to restrict speech > due to its transmission or reception of gambling information. This Well, one does have to wonder if first applies, as there is perfectly legal information on some of those sites(ie, reading about strategy is not illegal). I believe some of those listed also had support for freeplay, which is not illegal (and probably why gambling sites like to combine the two). Jack From cboyd at gizmopartners.com Mon May 4 13:41:51 2009 From: cboyd at gizmopartners.com (Chris Boyd) Date: Mon, 4 May 2009 13:41:51 -0500 Subject: Intel wants to hook 15 billion embedded devices to the Internet in 6 years Message-ID: <09762D9F-914B-45F7-AA9A-7E5F8A76449A@gizmopartners.com> Oddly, none of the courses in the event discuss IPv6. http://www.intelembeddedevent.com/ Intel? Embedded eVent We?re standing at the forefront of the Embedded Internet Era. The opportunities are yours. The networked world is growing at a tremendous pace. In just six years, it?s expected that 15 Billion intelligent devices will be connected to the internet. And, with your imagination and hard work, Intel can be a part of many of the devices that will revolutionize the way we work, talk, play and move. So, Intel is hosting our first virtual tradeshow, the Intel Embedded eVent, and we want you to join us! It?s a one day event that will showcase Intel technologies and our customers? innovation in intelligent, connected devices. From sethm at rollernet.us Mon May 4 13:42:19 2009 From: sethm at rollernet.us (Seth Mattinen) Date: Mon, 04 May 2009 11:42:19 -0700 Subject: Where to buy Internet IP addresses In-Reply-To: <49FEF5C0.9050109@ttec.com> References: <200905041139.n44BdFYA093271@aurora.sol.net> <49FEF5C0.9050109@ttec.com> Message-ID: <49FF370B.9080902@rollernet.us> Joe Maimon wrote: > > > Joe Greco wrote: > >> One of the goals of providing larger address spaces was to reduce (and >> hopefully eliminate) the need to burn forwarding table entries where >> doing so isn't strictly necessary. When we forget this, it leads us >> to the same sorts of disasters that we currently have in v4. >> >> ... JG > > And if you are encouraging /48 handouts, /32 isnt large enough to > prevent that on the global level. > What remains to be seen is what will happen when someone says "hey, my /32 is full, I need another one". Will it be: a) Sure, here's another /32, have fun! b) You didn't subnet very efficiently by current standards even though it was encouraged in the past; try to reclaim some space internally. ~Seth From johnl at iecc.com Mon May 4 13:43:15 2009 From: johnl at iecc.com (John R. Levine) Date: Mon, 4 May 2009 19:43:15 +0100 (BST) Subject: Minnesota to block online gambling sites? In-Reply-To: <5b6f80200905041053m75d7689ct92b075ee7ba3a3da@mail.gmail.com> References: <49FF11EA.7030101@umn.edu> <20090504173523.50690.qmail@simone.iecc.com> <5b6f80200905041053m75d7689ct92b075ee7ba3a3da@mail.gmail.com> Message-ID: > So is this going to become like the great firewall of China > eventually? Who knows. It's hardly the first government attempt to block illegal content, viz. the secret Pennsylvania list of child porn sites. R's, John From sethm at rollernet.us Mon May 4 13:47:22 2009 From: sethm at rollernet.us (Seth Mattinen) Date: Mon, 04 May 2009 11:47:22 -0700 Subject: Where to buy Internet IP addresses In-Reply-To: <667472E7-31AA-4154-B37B-3A18F72E376B@tzi.org> References: <200905012340.n41NeNKD093855@drugs.dv.isc.org> <49FB9A86.1080101@rollernet.us> <49FBA5DA.2020707@bogus.com> <82y6tds62v.fsf@mid.bfk.de> <214A65F4-209E-401D-B67D-DBC33A515D09@daork.net> <667472E7-31AA-4154-B37B-3A18F72E376B@tzi.org> Message-ID: <49FF383A.5060500@rollernet.us> Carsten Bormann wrote: > On May 4, 2009, at 10:08, Nathan Ward wrote: > >> Forwarding these requests up to the ISP's router and having several >> PDs per end customer is in my opinion the best way to go. > > If the ISP sees (and has to hand out) the PD, some bean counter will put > a price tag on it ("differential pricing"). > If there is a price tag on it, nobody will pay the higher price, and > everybody will put in a kludge to get by with one /64. > Think about it: That's exactly the reason why we got mired in the InterNAT. > > Really, /56 for everyone is the only way back to an Internet. > As cool as it would be to have the internet fully routable, I would be surprised if it would happen because of the "how little can we get away with giving the customer so we can charge for upgrades" mentality. ~Seth From swmike at swm.pp.se Mon May 4 14:09:58 2009 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Mon, 4 May 2009 21:09:58 +0200 (CEST) Subject: Where to buy Internet IP addresses In-Reply-To: <49FF370B.9080902@rollernet.us> References: <200905041139.n44BdFYA093271@aurora.sol.net> <49FEF5C0.9050109@ttec.com> <49FF370B.9080902@rollernet.us> Message-ID: On Mon, 4 May 2009, Seth Mattinen wrote: > What remains to be seen is what will happen when someone says "hey, my > /32 is full, I need another one". Will it be: > > a) Sure, here's another /32, have fun! > b) You didn't subnet very efficiently by current standards even though > it was encouraged in the past; try to reclaim some space internally. We returned our vintage year 2000 /32 to RIPE and got a brand shiny new /25 instead. It helps to have a couple of tens of million customers. We hope we never have to pollute the DFZ, by just having a single prefix for the forseeable future. -- Mikael Abrahamsson email: swmike at swm.pp.se From jlewis at lewis.org Mon May 4 14:43:01 2009 From: jlewis at lewis.org (Jon Lewis) Date: Mon, 4 May 2009 15:43:01 -0400 (EDT) Subject: ground control to TWTelecom In-Reply-To: <443de7ad0905041109p6f1597e1vcf09889fedd8f3c@mail.gmail.com> References: <443de7ad0905041109p6f1597e1vcf09889fedd8f3c@mail.gmail.com> Message-ID: On Mon, 4 May 2009, Chris Grundemann wrote: > > I assume you checked route-server.twtelecom.net for the route? Yeah...that's why I'm pretty sure they're not accepting it. Their only path is a longer as-path than what they'd get from us. Checking route-server.twtelecom.net is pretty much the only way I get confirmation from TWiT that they're accepting routes from us. ---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From sjk at sleepycatz.com Mon May 4 14:55:38 2009 From: sjk at sleepycatz.com (sjk) Date: Mon, 04 May 2009 14:55:38 -0500 Subject: DSX cross-connect solution Message-ID: <49FF483A.4040508@sleepycatz.com> I am trying to find hardware for a rebuild of our DS1 cross-connect frame and can't seem to find much out there. We've got ~300 DS1s that need to be x-connected between our M13s and I'm seeking an easy to manage solution. I've looked at the Telect panels but I'm concerned that my staff can't deal with wirewrap terminations. Has anyone seen, simply, a high density 66 field that can fit in a 23" rack? TIA -- steve From robert at ufl.edu Mon May 4 15:04:29 2009 From: robert at ufl.edu (Robert D. Scott) Date: Mon, 4 May 2009 16:04:29 -0400 Subject: DSX cross-connect solution In-Reply-To: <49FF483A.4040508@sleepycatz.com> References: <49FF483A.4040508@sleepycatz.com> Message-ID: <0ca701c9ccf3$888497c0$998dc740$@edu> You would get better density from a 110 patch than a 66, and telco frames for 19 and 23 are readily available. Robert D. Scott Robert at ufl.edu Senior Network Engineer 352-273-0113 Phone CNS - Network Services 352-392-2061 CNS Phone Tree University of Florida 352-392-9440 FAX Florida Lambda Rail 352-294-3571 FLR NOC Gainesville, FL 32611 321-663-0421 Cell -----Original Message----- From: sjk [mailto:sjk at sleepycatz.com] Sent: Monday, May 04, 2009 3:56 PM To: nanog at nanog.org Subject: DSX cross-connect solution I am trying to find hardware for a rebuild of our DS1 cross-connect frame and can't seem to find much out there. We've got ~300 DS1s that need to be x-connected between our M13s and I'm seeking an easy to manage solution. I've looked at the Telect panels but I'm concerned that my staff can't deal with wirewrap terminations. Has anyone seen, simply, a high density 66 field that can fit in a 23" rack? TIA -- steve From kwallace at pcconnection.com Mon May 4 15:05:30 2009 From: kwallace at pcconnection.com (Wallace Keith) Date: Mon, 4 May 2009 16:05:30 -0400 Subject: DSX cross-connect solution In-Reply-To: <49FF483A.4040508@sleepycatz.com> References: <49FF483A.4040508@sleepycatz.com> Message-ID: <0E8773C725A1674E9F7B35EABB5EEEB1053A04A2@MKA134.pcc.int> I would stick with wire wrap, 66 blocks make an inferior connection. If someone cannot deal with wire wrapping, they are not living in a telecom world. Find a contractor who can do this properly. Both Telect and ADC have good DSX panels in varying densities. -Keith -----Original Message----- From: sjk [mailto:sjk at sleepycatz.com] Sent: Monday, May 04, 2009 3:56 PM To: nanog at nanog.org Subject: DSX cross-connect solution I am trying to find hardware for a rebuild of our DS1 cross-connect frame and can't seem to find much out there. We've got ~300 DS1s that need to be x-connected between our M13s and I'm seeking an easy to manage solution. I've looked at the Telect panels but I'm concerned that my staff can't deal with wirewrap terminations. Has anyone seen, simply, a high density 66 field that can fit in a 23" rack? TIA -- steve From frnkblk at iname.com Mon May 4 15:07:36 2009 From: frnkblk at iname.com (Frank Bulk) Date: Mon, 4 May 2009 15:07:36 -0500 Subject: DSX cross-connect solution In-Reply-To: <49FF483A.4040508@sleepycatz.com> References: <49FF483A.4040508@sleepycatz.com> Message-ID: We use the ADC D1M-1A0019, happily: http://www.launch3telecom.com/adc/dsxpanels/D1M-1A0019.html Frank -----Original Message----- From: sjk [mailto:sjk at sleepycatz.com] Sent: Monday, May 04, 2009 2:56 PM To: nanog at nanog.org Subject: DSX cross-connect solution I am trying to find hardware for a rebuild of our DS1 cross-connect frame and can't seem to find much out there. We've got ~300 DS1s that need to be x-connected between our M13s and I'm seeking an easy to manage solution. I've looked at the Telect panels but I'm concerned that my staff can't deal with wirewrap terminations. Has anyone seen, simply, a high density 66 field that can fit in a 23" rack? TIA -- steve From jimpop at gmail.com Mon May 4 15:33:31 2009 From: jimpop at gmail.com (Jim Popovitch) Date: Mon, 4 May 2009 13:33:31 -0700 Subject: Minnesota to block online gambling sites? In-Reply-To: <5b6f80200905041053m75d7689ct92b075ee7ba3a3da@mail.gmail.com> References: <49FF11EA.7030101@umn.edu> <20090504173523.50690.qmail@simone.iecc.com> <5b6f80200905041053m75d7689ct92b075ee7ba3a3da@mail.gmail.com> Message-ID: On Mon, May 4, 2009 at 10:53, Ken Gilmour wrote: > So is this going to become like the great firewall of China > eventually? You can see in the letters that they are "going to see how > it goes and then maybe start blocking more stuff" if they are > successful. I can see a big nightmare heading this way if ISPs start > caving in to requests like this. Isn't this akin to a state legislature mandating that the DOT block drugs at the state's border? Also, why is the order to block sites rather than monitoring and arresting Minnesotans who are violating the law? Sort'a looks like the MN legislature is trying to hide the bad behavior of it's citizens. ;-) -Jim P. From nonobvious at gmail.com Mon May 4 16:03:31 2009 From: nonobvious at gmail.com (Bill Stewart) Date: Mon, 4 May 2009 14:03:31 -0700 Subject: Where to buy Internet IP addresses In-Reply-To: <200905041427.n44ERf0A003326@aurora.sol.net> References: <49FEF5C0.9050109@ttec.com> <200905041427.n44ERf0A003326@aurora.sol.net> Message-ID: <18a5e7cb0905041403q47b78c1cvaba1452c6e6e4f0@mail.gmail.com> > You have RFC3041 and similar techniques, stateless autoconfig, and a > variety of other general things that make it really awful for the default > ethernet network size to be something besides a /64. ... > I would definitely prefer to see a /56, or maybe a /48, handed out > today. When I first started looking at IPv6, the bottom 64 bits were divided into the bottom 48 bits for a MAC address and 16 more bits that could either be zeros or could be used as a subnet number in roughly Novell Netware style (modulo a local/global bit if you needed one). If you wanted to assign addresses instead of autoconfiguring, that was ok too, but it was obvious how autoconfig would work. It was simple, clean, and flexible, and obviously intended that an ISP would hand most customers a /64, which could easily handle an entire building or medium-complexity campus. Then I ignored those bits for a decade or more, because nobody's IPv6 was much more than experimental. When I came back, I found this ugly EUI-64 thing instead, so not only was autoconfiguration much uglier, but you needed a /56 instead of a /64 if you were going to subnet. Does anybody know why anybody thought it was a good idea to put the extra bits in the middle, or for IPv6 to adopt them? -- ---- 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 jrhett at netconsonance.com Mon May 4 16:08:23 2009 From: jrhett at netconsonance.com (Jo Rhett) Date: Mon, 4 May 2009 14:08:23 -0700 Subject: who provides bandwidth to Telehouse? Message-ID: <500F759C-CFA6-4705-B50E-E0A8E37691A9@netconsonance.com> Besides the obvious KDD which shows up in traceroute, does anyone else provide bandwidth to Telehouse? They are spamming contact addresses from the PAIX peering list, and claiming they have every right to do so. We'd like to convince them otherwise. Replies would be best off- list. Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.28]) by kininvie.sv.svcolo.com (8.14.1/8.14.2) with ESMTP id n3NIKkTW095522 for ; Thu, 23 Apr 2009 11:20:46 -0700 (PDT) (envelope-from managedservice at telehouse.com) Received: by yw-out-2324.google.com with SMTP id 2so198588ywt.47 for ; Thu, 23 Apr 2009 11:20:46 -0700 (PDT) Received: by 10.100.171.15 with SMTP id t15mr1759646ane. 99.1240510845890; Thu, 23 Apr 2009 11:20:45 -0700 (PDT) Received: from wohlarsb (fw.telehouse.com [209.137.140.2]) by mx.google.com with ESMTPS id c29sm637866anc.10.2009.04.23.11.20.43 (version=SSLv3 cipher=RC4-MD5); Thu, 23 Apr 2009 11:20:45 -0700 (PDT) Subject: The Security information you missed last Friday Thread-Index: AcnEP/Q6yPwCzf2XRgmtpXMo9zh8vA== Date: Thu, 23 Apr 2009 14:19:00 -0400 To: From: "Managed Services" X-Mailer: Microsoft Office Outlook 11 X-Mimeole: Produced By Microsoft MimeOLE V6.00.2900.5579 Message-ID: Reply-To: Organization: TELEHOUSE America Jo, You missed the Telehouse WebEx Friday on Security Threats from Virtualization. But good news - we can forward you a copy of the presentation, if you would like to review the security threats that most IT groups are missing. The top threats reviewed include: * The inability to monitor the virtualized environment including machines, OS, and network * How virtualization impacts compliance * Forensic challenges of a virtualized environment * Virtualized machines as attack tools * Why the hypervisor is the weakest security link Just reply to this email for a copy or let us know who at Silicon ValleyColocation we should forward it to. Regards, Ken Rubin Senior Global Account Manager Telehouse America (T) 718-313-1221 (M) 917-829-0397 (F) 718-355-2517 ken.rubin at telehouse.com www.telehouse.com -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness From jfbeam at gmail.com Mon May 4 16:23:13 2009 From: jfbeam at gmail.com (Ricky Beam) Date: Mon, 04 May 2009 17:23:13 -0400 Subject: DSX cross-connect solution In-Reply-To: <0E8773C725A1674E9F7B35EABB5EEEB1053A04A2@MKA134.pcc.int> References: <49FF483A.4040508@sleepycatz.com> <0E8773C725A1674E9F7B35EABB5EEEB1053A04A2@MKA134.pcc.int> Message-ID: On Mon, 04 May 2009 16:05:30 -0400, Wallace Keith wrote: > I would stick with wire wrap, 66 blocks make an inferior connection. True, but a 66 block will work. Usually. And is easily re-punched. > If someone cannot deal with wire wrapping, they are not living in a > telecom world. Really. Seriously, who cannot do wire wrap? It takes, literally, 5 minutes to learn to do it. And that's with a "screw driver" wirewrap tool. With one of these [http://www.datacomtools.com/catalog/Wire-Wrap-tools/jonard-wire-wrap-gun.htm], it takes about 10s, and you get a consistent, near perfect wrap every time. (yes, it's a bit pricey, but very worth the cost even if you only use it once to wire a single panel.) --Ricky PS: That's just the gun; it'll need a tip/sleeve. I recommend a complete kit. [http://www.datacomtools.com/catalog/Wire-Wrap-tools/wire-wrap-kits.htm] From surfer at mauigateway.com Mon May 4 16:31:37 2009 From: surfer at mauigateway.com (Scott Weeks) Date: Mon, 4 May 2009 14:31:37 -0700 Subject: Minnesota to block online gambling sites? Message-ID: <20090504143137.F87C6F71@resin15.mta.everyone.net> --------------------------------------- > successful. I can see a big nightmare heading this way if ISPs start > caving in to requests like this. --------------------------------------- It's happening all over the place. Not picking on any country or list, just to post a few examples... [AusNOG] Conroy censoring dissent? http://lists.ausnog.net/pipermail/ausnog/2008-October/thread.html http://lists.ausnog.net/pipermail/ausnog/2008-November/thread.html http://www.news.com.au/story/0,23599,22999659-2,00.html [swinog] Censurship in Germany http://www.mail-archive.com/swinog at lists.swinog.ch/msg03581.html [swinog] Justice Order to block websites http://lists.swinog.ch/public/swinog/2008-January/thread.html scott From stephen at sprunk.org Mon May 4 16:36:16 2009 From: stephen at sprunk.org (Stephen Sprunk) Date: Mon, 04 May 2009 16:36:16 -0500 Subject: Where to buy Internet IP addresses In-Reply-To: <18a5e7cb0905041403q47b78c1cvaba1452c6e6e4f0@mail.gmail.com> References: <49FEF5C0.9050109@ttec.com> <200905041427.n44ERf0A003326@aurora.sol.net> <18a5e7cb0905041403q47b78c1cvaba1452c6e6e4f0@mail.gmail.com> Message-ID: <49FF5FD0.6010304@sprunk.org> Bill Stewart wrote: > When I came back, I found this ugly EUI-64 thing instead, so not only was autoconfiguration much uglier, but you needed a /56 instead of a /64 if you were going to subnet. It's supposed to be a /48 per customer, on the assumption that 16 bits of subnet information is sufficient for virtually anyone; exceptions should be rare enough that they can be handled as special cases. The /56 monstrosity came about because a US cable company wanted to assign a prefix to every home they passed, regardless of whether it contained a customer, so that they'd never need to renumber anything ever again. However, that would require they get more than the /32 minimum allocation, and ARIN policy doesn't allow _potential_ customers as a justification for getting a larger allocation, so they had to shrink the per-customer prefix down to a /56 to fit them all into a single /32. If all those assignments were to _real_ customers, they could have gotten a /24 and given each customer a /48 as expected. And, after that, many folks who can't wrap their heads around the size of the IPv6 address space appear to be obsessed with doing the same in other cases where even that weak justification doesn't apply... > Does anybody know why anybody thought it was a good idea to put the extra bits in the middle, or for IPv6 to adopt them? > Why the switch from EUI-48 to EUI-64? Someone in the IEEE got worried about running short of MAC (er, EUI-48) addresses at some point in the future, so they inserted 16 bits in the middle (after the OUI) to form an EUI-64 and are now "discouraging" new uses of EUI-48. The IETF decided to follow the IEEE's guidance and switch IPv6 autoconfig from EUI-48 to EUI-64, but FireWire is the only significant user of EUI-64 addresses to date; if you're using a link layer with EUI-48 addresses (e.g. Ethernet), an extra 16 bits (FFFE) get stuffed in the middle to transform it into the EUI-64 that IPv6 expects. S -- Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3241 bytes Desc: S/MIME Cryptographic Signature URL: From Terry.Chatfield at neustar.biz Mon May 4 16:37:00 2009 From: Terry.Chatfield at neustar.biz (Chatfield, Terry) Date: Mon, 4 May 2009 17:37:00 -0400 Subject: DSX cross-connect solution In-Reply-To: References: <49FF483A.4040508@sleepycatz.com><0E8773C725A1674E9F7B35EABB5EEEB1053A04A2@MKA134.pcc.int> Message-ID: <2079AFC3AB79A64993D3D7B18A12319F098A69@STNTEXCH12.cis.neustar.com> Alternatively, one could use a digital cross-connect. Terry -----Original Message----- From: Ricky Beam [mailto:jfbeam at gmail.com] Sent: Monday, May 04, 2009 5:23 PM To: nanog at nanog.org Subject: Re: DSX cross-connect solution On Mon, 04 May 2009 16:05:30 -0400, Wallace Keith wrote: > I would stick with wire wrap, 66 blocks make an inferior connection. True, but a 66 block will work. Usually. And is easily re-punched. > If someone cannot deal with wire wrapping, they are not living in a > telecom world. Really. Seriously, who cannot do wire wrap? It takes, literally, 5 minutes to learn to do it. And that's with a "screw driver" wirewrap tool. With one of these [http://www.datacomtools.com/catalog/Wire-Wrap-tools/jonard-wire-wrap-gu n.htm], it takes about 10s, and you get a consistent, near perfect wrap every time. (yes, it's a bit pricey, but very worth the cost even if you only use it once to wire a single panel.) --Ricky PS: That's just the gun; it'll need a tip/sleeve. I recommend a complete kit. [http://www.datacomtools.com/catalog/Wire-Wrap-tools/wire-wrap-kits.htm] From jfbeam at gmail.com Mon May 4 16:43:13 2009 From: jfbeam at gmail.com (Ricky Beam) Date: Mon, 04 May 2009 17:43:13 -0400 Subject: Where to buy Internet IP addresses In-Reply-To: <18a5e7cb0905041403q47b78c1cvaba1452c6e6e4f0@mail.gmail.com> References: <49FEF5C0.9050109@ttec.com> <200905041427.n44ERf0A003326@aurora.sol.net> <18a5e7cb0905041403q47b78c1cvaba1452c6e6e4f0@mail.gmail.com> Message-ID: On Mon, 04 May 2009 17:03:31 -0400, Bill Stewart wrote: > When I came back, I found this ugly EUI-64 thing instead, > so not only was autoconfiguration much uglier, > but you needed a /56 instead of a /64 if you were going to subnet. > Does anybody know why anybody thought it was a good idea > to put the extra bits in the middle, or for IPv6 to adopt them? "64bit MAC" -- which pretty much exists nowhere. It's a repeat of the mistakes from IPv4's early days: CLASSFUL ROUTING. I'm with you. I wish vendors and spec designers would just get over it and let people subnet however they want. If I want to set a network to be /96 or /120, I should be allowed to do so. Yes, I know autoconfig will not work -- and I don't want it to. I can make /31 IPv4 routes -- no router I've ever used complained about it. (that sends 2 addresses to one place; what happens in the place is not the router's concern.) From Charles at thewybles.com Mon May 4 16:57:49 2009 From: Charles at thewybles.com (Charles at thewybles.com) Date: Mon, 4 May 2009 21:57:49 +0000 Subject: Where to buy Internet IP addresses In-Reply-To: <49FF5FD0.6010304@sprunk.org> References: <49FEF5C0.9050109@ttec.com> <200905041427.n44ERf0A003326@aurora.sol.net><18a5e7cb0905041403q47b78c1cvaba1452c6e6e4f0@mail.gmail.com><49FF5FD0.6010304@sprunk.org> Message-ID: <1160419770-1241474283-cardhu_decombobulator_blackberry.rim.net-255591761-@bxe1197.bisx.prod.on.blackberry> This has been a fascinating theoritcal discussion.. how do existing providers hand out space? Hurricane electric (via its tunnel service) hands out a /64 by default and a /48 is a click away. How do other providers handle it? I'm in the us and only have native v4 connectivity :( Do the various traditional last mile providers (sprint/Verizon/att/patch etc ) offer it for t1 and better? If they do then what do they hand out by default, what's available, at what price point and what's the upgrade path? Is it one click like he? No provider I have talked to offers it for residential connectivity in the united states. What does free.fr do? If there is this level of confusion and disagreement around addressing schemes then will it ever be offered to residences over traditional last mile loops? Sent via BlackBerry from T-Mobile -----Original Message----- From: Stephen Sprunk Date: Mon, 04 May 2009 16:36:16 To: Bill Stewart Cc: north American Noise and Off-topic Gripes; Joe Greco Subject: Re: Where to buy Internet IP addresses Bill Stewart wrote: > When I came back, I found this ugly EUI-64 thing instead, so not only was autoconfiguration much uglier, but you needed a /56 instead of a /64 if you were going to subnet. It's supposed to be a /48 per customer, on the assumption that 16 bits of subnet information is sufficient for virtually anyone; exceptions should be rare enough that they can be handled as special cases. The /56 monstrosity came about because a US cable company wanted to assign a prefix to every home they passed, regardless of whether it contained a customer, so that they'd never need to renumber anything ever again. However, that would require they get more than the /32 minimum allocation, and ARIN policy doesn't allow _potential_ customers as a justification for getting a larger allocation, so they had to shrink the per-customer prefix down to a /56 to fit them all into a single /32. If all those assignments were to _real_ customers, they could have gotten a /24 and given each customer a /48 as expected. And, after that, many folks who can't wrap their heads around the size of the IPv6 address space appear to be obsessed with doing the same in other cases where even that weak justification doesn't apply... > Does anybody know why anybody thought it was a good idea to put the extra bits in the middle, or for IPv6 to adopt them? > Why the switch from EUI-48 to EUI-64? Someone in the IEEE got worried about running short of MAC (er, EUI-48) addresses at some point in the future, so they inserted 16 bits in the middle (after the OUI) to form an EUI-64 and are now "discouraging" new uses of EUI-48. The IETF decided to follow the IEEE's guidance and switch IPv6 autoconfig from EUI-48 to EUI-64, but FireWire is the only significant user of EUI-64 addresses to date; if you're using a link layer with EUI-48 addresses (e.g. Ethernet), an extra 16 bits (FFFE) get stuffed in the middle to transform it into the EUI-64 that IPv6 expects. S -- Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking From jbates at brightok.net Mon May 4 17:01:32 2009 From: jbates at brightok.net (Jack Bates) Date: Mon, 04 May 2009 17:01:32 -0500 Subject: Where to buy Internet IP addresses In-Reply-To: References: <49FEF5C0.9050109@ttec.com> <200905041427.n44ERf0A003326@aurora.sol.net> <18a5e7cb0905041403q47b78c1cvaba1452c6e6e4f0@mail.gmail.com> Message-ID: <49FF65BC.2040207@brightok.net> Ricky Beam wrote: > "64bit MAC" -- which pretty much exists nowhere. It's a repeat of the > mistakes from IPv4's early days: CLASSFUL ROUTING. > Given there is no CLASS, but just a separation of network and host, I'd hate to compare it to classful routing. They probably would have been happy with a /96 network except for stateless autoconfig, which is quite nice for some stuff actually. > I'm with you. I wish vendors and spec designers would just get over it > and let people subnet however they want. If I want to set a network to > be /96 or /120, I should be allowed to do so. Yes, I know autoconfig > will not work -- and I don't want it to. I can make /31 IPv4 routes -- > no router I've ever used complained about it. (that sends 2 addresses to > one place; what happens in the place is not the router's concern.) I've not tried every vendor out there, but I've noticed some implementations handle /127 just fine from a routing perspective. I personally enjoy my /64 of /128 loopbacks. I'll be dead before I run out. :) Jack From jgreco at ns.sol.net Mon May 4 17:09:04 2009 From: jgreco at ns.sol.net (Joe Greco) Date: Mon, 4 May 2009 17:09:04 -0500 (CDT) Subject: Where to buy Internet IP addresses In-Reply-To: from "Ricky Beam" at May 04, 2009 05:43:13 PM Message-ID: <200905042209.n44M95lb024221@aurora.sol.net> > On Mon, 04 May 2009 17:03:31 -0400, Bill Stewart > wrote: > > When I came back, I found this ugly EUI-64 thing instead, > > so not only was autoconfiguration much uglier, > > but you needed a /56 instead of a /64 if you were going to subnet. > > Does anybody know why anybody thought it was a good idea > > to put the extra bits in the middle, or for IPv6 to adopt them? > > "64bit MAC" -- which pretty much exists nowhere. It's a repeat of the > mistakes from IPv4's early days: CLASSFUL ROUTING. Actually, that's exactly wrong. It takes the good stuff from one of the failures of IPv4... CLASSFUL ROUTING... and does it right: Fundamentally, IPv4 got one part of it right with classful routing. Giving service providers large blocks of space, large enough to allow them to announce a single route out on the Internet. The problem is that the address space wasn't really large enough to support this in a sane manner, because growth wasn't predictable and mistakes would result in waste. IPv6 is *designed* for waste. You are *expected* to have vast realms of completely unused IP(v6) addresses. So there is no damage to be had by giving someone a delegation that's an order of magnitude too large, and even giving someone a delegation that's an order of magnitude too small is survivable without real problems. We can also delegate based on much more distant projections. Reducing the routing table size is one of the BEST ideas from classful routing, it just didn't pan out because it was done as classful routing. Now, we get a chance to learn from that mistake, and we can do it right. Using a 64-bit MAC when most current MAC's are 48 is not a mistake. It shows that someone somewhere had some vision towards the future. > I'm with you. I wish vendors and spec designers would just get over it > and let people subnet however they want. If I want to set a network to be > /96 or /120, I should be allowed to do so. Yes, I know autoconfig will > not work -- and I don't want it to. You *can* do that. Nobody has said that it is impossible to set up an interface with a /130-slash-/131 if you want a point to point. But what we're talking about is service providers delegating to customers. Customers should *also* be allowed to subnet "however they want." Something they can't do right now, because they aren't given the space. If service providers are allowed to delegate teeny prefixes (meaning /64 or less), we're going to see consumers finding "ways" around that restriction, and then we're down an ugly road that's reminiscent of IPv4 and NAT and "you get one IP address, deal with it." That should be avoided at all costs. ... 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 Mon May 4 17:27:32 2009 From: jbates at brightok.net (Jack Bates) Date: Mon, 04 May 2009 17:27:32 -0500 Subject: Where to buy Internet IP addresses In-Reply-To: <200905042209.n44M95lb024221@aurora.sol.net> References: <200905042209.n44M95lb024221@aurora.sol.net> Message-ID: <49FF6BD4.1020505@brightok.net> Joe Greco wrote: > But what we're talking about is service providers delegating to customers. > Customers should *also* be allowed to subnet "however they want." > Something they can't do right now, because they aren't given the space. > If service providers are allowed to delegate teeny prefixes (meaning /64 > or less), we're going to see consumers finding "ways" around that > restriction, and then we're down an ugly road that's reminiscent of IPv4 > and NAT and "you get one IP address, deal with it." > Customers should also be able to implement multiple networks with support for stateless autoconfig. Doing away with NAT means new ways of handing out networks, which I believe the IETF has come short on, but the start is to accept that they'll need at least a /64 per layer two segment for compatibility reasons. Implementations will vary, as will the knowledge of the customer, but it is safe to assume at this point that there will be implementations with support for stateless autoconfig and multiple networks/subnets/etc. Jack From jfbeam at gmail.com Mon May 4 17:38:13 2009 From: jfbeam at gmail.com (Ricky Beam) Date: Mon, 04 May 2009 18:38:13 -0400 Subject: Where to buy Internet IP addresses In-Reply-To: <49FF65BC.2040207@brightok.net> References: <49FEF5C0.9050109@ttec.com> <200905041427.n44ERf0A003326@aurora.sol.net> <18a5e7cb0905041403q47b78c1cvaba1452c6e6e4f0@mail.gmail.com> <49FF65BC.2040207@brightok.net> Message-ID: On Mon, 04 May 2009 18:01:32 -0400, Jack Bates wrote: > Given there is no CLASS, but just a separation of network and host, I'd > hate to compare it to classful routing. They probably would have been > happy with a /96 network except for stateless autoconfig, which is quite > nice for some stuff actually. Ok, calling it "classful routing" might be a little melodramatic. I would love to be able to set interfaces on my cisco hardware to /96's, but it's not allowed. Autoconfig screws that up. Even if it's not used, you're forced to live with it. Linux, BSD, etc. don't care. (and the instant they do, I can remove that stupid code.) > I've not tried every vendor out there, but I've noticed some > implementations handle /127 just fine from a routing perspective. So far, Cisco's gear is the only IPv6 routers I've messed with. And they will not let you set an interface to anything smaller than a /64. Loopbacks have slightly different rules, but in my case (IPv6 tunnels) that fact hasn't proven very useful. From president at ukraine.su Mon May 4 17:42:21 2009 From: president at ukraine.su (Max Tulyev) Date: Tue, 05 May 2009 01:42:21 +0300 Subject: Where to buy Internet IP addresses In-Reply-To: <2039ACC84D552B46A292559F7A45A1460248D298@edrmail01.southport.edr.cc> References: <2039ACC84D552B46A292559F7A45A1460248D298@edrmail01.southport.edr.cc> Message-ID: <49FF6F4D.4090008@ukraine.su> Louis, may be a provider independent network is what you are looking for. This is an end-user block of IP addresses moving with you from one ISP to another, also can be multihomed to several ISPs together. Our company helps to obtain such networks and autonomous system numbers, from /24 (256 IPs, the least routed block in Internet) to even /18. There is no huge hardware requirements for obtain and using such networks, even PC router with free quagga software is enough. LEdouard Louis wrote: > Optimum Online business only offer 5 static IP address. > > > > Where can I buy a block of Internet IP address for Business? How much > does it cost? > > > > Most of our devices only require an internal IP address to reach the > internet, but we have a Juniper DX for load balancing. > > > > We must provide Juniper DX with an internet IP address and point it to > internal IP address for customers to be able to reach it from the > internet. this is for testing and development purposes and will expect > several servers on Load-balancer. The 5 static IP addresses just won't > be enough. > > > > Thanks in advance > > Louis > > > > -- WBR, Max Tulyev (MT6561-RIPE, 2:463/253 at FIDO) From carlos at race.com Mon May 4 17:44:16 2009 From: carlos at race.com (Carlos Alcantar) Date: Mon, 4 May 2009 15:44:16 -0700 Subject: DSX cross-connect solution Message-ID: <859604546CD1FF488BDB6EA94C896AFB77669D@racexchange.race.local> Digital cross connect is the way to go if you have the budget to do that. Turin now force 10 make a good dacs and or the cisco 15454 with a ds3-12xm card can do it as well. -carlos -----Original Message----- From: Chatfield, Terry [mailto:Terry.Chatfield at neustar.biz] Sent: Monday, May 04, 2009 2:37 PM To: nanog at nanog.org Subject: RE: DSX cross-connect solution Alternatively, one could use a digital cross-connect. Terry -----Original Message----- From: Ricky Beam [mailto:jfbeam at gmail.com] Sent: Monday, May 04, 2009 5:23 PM To: nanog at nanog.org Subject: Re: DSX cross-connect solution On Mon, 04 May 2009 16:05:30 -0400, Wallace Keith wrote: > I would stick with wire wrap, 66 blocks make an inferior connection. True, but a 66 block will work. Usually. And is easily re-punched. > If someone cannot deal with wire wrapping, they are not living in a > telecom world. Really. Seriously, who cannot do wire wrap? It takes, literally, 5 minutes to learn to do it. And that's with a "screw driver" wirewrap tool. With one of these [http://www.datacomtools.com/catalog/Wire-Wrap-tools/jonard-wire-wrap-gu n.htm], it takes about 10s, and you get a consistent, near perfect wrap every time. (yes, it's a bit pricey, but very worth the cost even if you only use it once to wire a single panel.) --Ricky PS: That's just the gun; it'll need a tip/sleeve. I recommend a complete kit. [http://www.datacomtools.com/catalog/Wire-Wrap-tools/wire-wrap-kits.htm] From bicknell at ufp.org Mon May 4 17:50:04 2009 From: bicknell at ufp.org (Leo Bicknell) Date: Mon, 4 May 2009 18:50:04 -0400 Subject: Where to buy Internet IP addresses In-Reply-To: References: <49FEF5C0.9050109@ttec.com> <200905041427.n44ERf0A003326@aurora.sol.net> <18a5e7cb0905041403q47b78c1cvaba1452c6e6e4f0@mail.gmail.com> <49FF65BC.2040207@brightok.net> Message-ID: <20090504225004.GA76011@ussenterprise.ufp.org> In a message written on Mon, May 04, 2009 at 06:38:13PM -0400, Ricky Beam wrote: > So far, Cisco's gear is the only IPv6 routers I've messed with. And they > will not let you set an interface to anything smaller than a /64. > Loopbacks have slightly different rules, but in my case (IPv6 tunnels) > that fact hasn't proven very useful. My 12.0(S), 12.4, and IOS-XR boxes are operating quite well with /112's and /127's on GigE interfaces to each other, on GSR's, 7300's, and 7200's. We also use /128's on loopbacks. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From jfbeam at gmail.com Mon May 4 18:08:13 2009 From: jfbeam at gmail.com (Ricky Beam) Date: Mon, 04 May 2009 19:08:13 -0400 Subject: Where to buy Internet IP addresses In-Reply-To: <49FF6BD4.1020505@brightok.net> References: <200905042209.n44M95lb024221@aurora.sol.net> <49FF6BD4.1020505@brightok.net> Message-ID: On Mon, 04 May 2009 18:27:32 -0400, Jack Bates wrote: > Customers should also be able to implement multiple networks with > support for stateless autoconfig. Doing away with NAT means new ways of > handing out networks, ... If I'm allowed to subnet my single /64, then I'm still not using NAT. And as long as I don't go beyond /80, autoconfig can still work, at least on ethernet -- which is pretty much 99.999% of cases. (not that I advocate the use of autoconfig. *grin*) From owen at delong.com Mon May 4 18:12:37 2009 From: owen at delong.com (Owen DeLong) Date: Mon, 4 May 2009 16:12:37 -0700 Subject: Minnesota to block online gambling sites? In-Reply-To: <5b6f80200905041053m75d7689ct92b075ee7ba3a3da@mail.gmail.com> References: <49FF11EA.7030101@umn.edu> <20090504173523.50690.qmail@simone.iecc.com> <5b6f80200905041053m75d7689ct92b075ee7ba3a3da@mail.gmail.com> Message-ID: <9BCDA840-484F-40C7-94B7-3D0EE2962F89@delong.com> To me, the bigger question is "Are ISPs common carriers?" To the best of my knowledge, the ISP businesses even of the telcos are not of common carrier status under federal law. If that is the case, my understanding of statute in question is that it does not apply and the ISPs should tell the MN government to go find a workable statute. Owen On May 4, 2009, at 10:53 AM, Ken Gilmour wrote: > So is this going to become like the great firewall of China > eventually? You can see in the letters that they are "going to see how > it goes and then maybe start blocking more stuff" if they are > successful. I can see a big nightmare heading this way if ISPs start > caving in to requests like this. > > > > 2009/5/4 John Levine : >>> Not withstanding the legality of such an order, how would one >>> operationally enforce that order? >> >> The order has a list of IP addresses, so I expect the ISPs will just >> block those IPs in routers somewhere. >> >> Since offshore online gambling is equally illegal everywhere in the >> U.S., the ISPs have little reason to limit the block to Minnesota >> customers, giving them a lot of latitude in where they implement the >> block. >> >> Regards, >> John Levine, johnl at iecc.com, Primary Perpetrator of "The Internet >> for Dummies", >> Information Superhighwayman wanna-be, http://www.johnlevine.com, ex- >> Mayor >> "More Wiener schnitzel, please", said Tom, revealingly. >> >> -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2105 bytes Desc: not available URL: From jfbeam at gmail.com Mon May 4 18:23:13 2009 From: jfbeam at gmail.com (Ricky Beam) Date: Mon, 04 May 2009 19:23:13 -0400 Subject: Where to buy Internet IP addresses In-Reply-To: <20090504225004.GA76011@ussenterprise.ufp.org> References: <49FEF5C0.9050109@ttec.com> <200905041427.n44ERf0A003326@aurora.sol.net> <18a5e7cb0905041403q47b78c1cvaba1452c6e6e4f0@mail.gmail.com> <49FF65BC.2040207@brightok.net> <20090504225004.GA76011@ussenterprise.ufp.org> Message-ID: On Mon, 04 May 2009 18:50:04 -0400, Leo Bicknell wrote: > My 12.0(S), 12.4, and IOS-XR boxes are operating quite well with > /112's and /127's on GigE interfaces to each other, on GSR's, 7300's, > and 7200's. We also use /128's on loopbacks. Must have been old (very old?) code when I first tried this. 12.4(15)T doesn't seem to care. But it still doesn't allow transitional addresses: gw(config-if)#ipv6 address 0::101:101/96 %FastEthernet0/0: Error: ::1.1.1.1/96 is invalid gw(config-if)#ipv6 address 0::101:101/128 %FastEthernet0/0: Error: ::1.1.1.1/128 is invalid If I cannot set an IPv4 address like that, the tunnel won't work. DHCPv6 requests end up outside the tunnel. (it's been many months since I messed with it, so the interface isn't in the config anymore, but the IPSEC setup still is :-)) I can send you the packet dumps if you want to scratch your head over it. From nanog at ian.co.uk Mon May 4 18:43:12 2009 From: nanog at ian.co.uk (Ian Mason) Date: Tue, 5 May 2009 00:43:12 +0100 Subject: Where to buy Internet IP addresses In-Reply-To: <6eb799ab0905022120o5be64c56ye664a8d00bd4eb91@mail.gmail.com> References: <200905012340.n41NeNKD093855@drugs.dv.isc.org> <49FB9A86.1080101@rollernet.us> <49FBA5DA.2020707@bogus.com> <6eb799ab0905022120o5be64c56ye664a8d00bd4eb91@mail.gmail.com> Message-ID: <8D4934F9-A041-4400-89E5-A2C566231F6A@ian.co.uk> On 3 May 2009, at 05:20, James Hess wrote: > > A /62 takes care of that unusual case, no real need for a /56 for > the average residential user; that's just excessive. There are about 11 million /56s per person on the planet, we're not about to run out. As there's nothing to conserve why follow the conservative strategy implied by shifting to longer netmasks? Why not stick with a regular scheme of escalating /64 -> /56 rather than an irregular one of /64 -> /62 -> /56? From jay at west.net Mon May 4 18:51:46 2009 From: jay at west.net (Jay Hennigan) Date: Mon, 04 May 2009 16:51:46 -0700 Subject: Where to buy Internet IP addresses In-Reply-To: <8D4934F9-A041-4400-89E5-A2C566231F6A@ian.co.uk> References: <200905012340.n41NeNKD093855@drugs.dv.isc.org> <49FB9A86.1080101@rollernet.us> <49FBA5DA.2020707@bogus.com> <6eb799ab0905022120o5be64c56ye664a8d00bd4eb91@mail.gmail.com> <8D4934F9-A041-4400-89E5-A2C566231F6A@ian.co.uk> Message-ID: <49FF7F92.3030503@west.net> Ian Mason wrote: > There are about 11 million /56s per person on the planet, we're not > about to run out. "We have enough addresses for about four billion of these." http://www.cs.utexas.edu/users/chris/think/ARPANET/images/imp.gif "We're not about to run out." -- Jay Hennigan - CCIE #7880 - Network Engineering - jay at impulse.net Impulse Internet Service - http://www.impulse.net/ Your local telephone and internet company - 805 884-6323 - WB6RDV From barton at gnaps.com Mon May 4 19:25:17 2009 From: barton at gnaps.com (Barton F Bruce) Date: Mon, 4 May 2009 20:25:17 -0400 Subject: DSX cross-connect solution References: <49FF483A.4040508@sleepycatz.com> <0E8773C725A1674E9F7B35EABB5EEEB1053A04A2@MKA134.pcc.int> Message-ID: Use the ADC 84 port DSX blocks with six 32 pair CHAMP connectors on the rear. You will stay saner if use the ones with three sections - A B C - on the front each with 1-14 jacks on the top row and 15-28 on the bottom. The alternate that looks the same from a distance simply has a top row of 1-42 and the bottom row is 43-84. We use and LIKE the ones that have 1/2 the wirewrap pins on the left and the other half on the right - ON THE FRONT. ADC has dropped hundreds of oddball custom DSX they used to make for every primadonna boonies telco and have standardised on the higher volume items at LOWER prices. Ten years ago, I could save a couple of hundred $s by ordering a particular DSX pannel from North Supply and yet their price would suck compared to Anixter's on some other panel and Alltel (now Windstream) would beat them all on yet another one. It all boiled down to ITEM VOLUME PRICING and not product family volume pricing from ADC. You had to use the supply house that had LOTS of other customers that used the panel you wanted. The plus there was that they would also be in stock and you didn't have to wait a couple of weeks for the truck from Mexico to arrive. In ALL cases, wire the 5th green "TL" (tag light) wire when you crossconnect, and so when you jack intio the monitor port, you are also grounding the TL wire and the tag led at each end of the xconnect flashes for the 1st minute and then stays solidly on. Use REAL ADC xconnect wire - two pairs and the green TL wire. It is TINNED, and you really WANT tinned wire if you are wrapping. Trivial to learn. Get any of several styles of cut-and-strip-to-wrap-length tools and a good squeeze the long trigger bar manual wrap gun. Don't get an manual twisty pencil size one - that is for the tech's emergency tool bag. An electric wrap gun or even a pneumatic one is crazy for your volume. The UNWRAP tool can be the manual pencil size one. ALL 5 wires can be stripped at once. DO NOT play with cut-strip-wrap bits - they are for assembly line work with HIGH TORQUE tools and where incoming QA makes sure THE ONE WIRE TYPE being used meets the special standards needed for such tools. I LIKE single guage bits, but reality is that maybe 22-24 is good if you have much 22GA ABAM you need to wrap, but more likely you want a 24-26ga combo bit and can use it for everything else. Extra long bits and sleeves may be a plus, too, depending on your panel. OK tool in NY makes all the pieces you would need. It is pure nonsense in a small shop where you are NOT feeding copper T1s out to the boonies on your own cable plant to be even thinking of 22GA. In our COLOs where the typical customers are all ISPs in racks less than 100 feet away, we use a lot of 24GA and now 26GA cable and it is rats-ass Cat-3. NOT ABAM, and there are no problems. We always will have O and I in seperate cables, but that is more how panels come than necessity. The big EVIL ABAM shields avoids is NEXT and there simply isn't any Near End Cross Talk when everything is very close and all signal levels are about the same. If there is any chance it will be wrapped ever, get TINNED cable. If I'm ordering 28 pair cable with 32 pair connectors on both ends, I still get tinned. It may be cut into two blunt tailed shorter cables that get that end wrapped. It costs almost nothing more if your suppliers are well stocked and typically are using the same cable for many other customers. DO NOT think of wrapping cat-5! you will hate straightening out each wire so you can stick it in the wrap bit. And you won't be able to strip more than one pair at a time and even then you may want to do a wire at a time. If I have 30 M13s per rack, the wad of cables going up to ladder rack between racks is 60 cables. Using 26 ga, 28 or 32 pair TINNED but unshielded cat-3 cable will make you very happy. If you are is a LARGE building even way smaller than 111 8th ave, 26 ga is not for you. VZ uses 26 ga where they can. for T1s too, but it is shielded. You only have 300 T1s so you can stay reasonably sane no matter what you do, but this is NOT the place to cheap out. The ability to jack in and do testing or an end to end frontal patch in an emergency is great. Be absolutely POSITIVE you get the I and O connections done correctly and your head and arms around the DSX terminology. O is OUT - and that is NOT going away from you but is pissing bits at you from the "TRANSMIT" side of whatever is connected there. O is what the Monitor port is padded down from, also. I is IN and where you stick bits IN towards whatever is connected beyond that port and it would be "RECEIVE" in datacomm terminology at that device. With 32 pair champ connectors on the back it is trivial to FIX if some tech mixes things up on the back of the DSX (unlike when EVERYTHING was wirewrapped), but just don't start letting the techs mess up. If you do ONE wrong, cross connects to it will not work CROSSED, and so techs wire them straight through, and now you have two M test ports looking at the signal in one direction and NOTHING to monitor the other flow. M should be looking at the signal COMING FROM that direction. Get a couple crossed, and then any xconnects between those panels will need to be Xconnected but M jacks are looking the WRONG direction, and it just gets worse as time goes on... NEVER let it start. The ONLY X-connection is at the DSX panels t1 by t1 - O goes to the other's I and I goes to the other's O. Again ONLY at DS-X does the "X" happen. The 28 pair cable (32 pair connector) from the O port on an M13 simply goes to the O port on its DSX panel, etc. Beware the Telect panels that achieved high density by your needing their blue SLIM plugs that cost more. and where each adjacent T1 was zigzagged vertically from the adjacent ones to let them pack more densely. Fine if you are buying used, but don't buy into the proprietary cord game - you don't have any where near enough for it to matter. How many acres of lower manhatten real estate must you save at any price? etc. ADC cords WILL work but NOT if an adjacent T1 is patched. I think Telect dropped that game when pissed off customers dropped them. DAMN cisco. The PA-MC-2T3+ card, as over priced as it is, should have been almost immediately upstaged by a PA-MC-OC3 card. PMC Sierra has had the chips to do that "right" for ages now. Each STS should then have been able to be optioned for M13 or VT1.5 format. In M13 format, at least, each T2 (4 T1s or 96 DS0s) should have been easily optioned to instead be 3 E1s - also 96 DS0s). But the real real benefit here is not E1 support (which they DID DO WELL on the OC3 european card) but would be having the 84 T1s be in VT1.5 mode so all your DACSing could be done in a cerent (cisco 15454) chassis. Even the old XC-VT cards did 336 T1s of any to any. That is 24 STSes max each with 28 VT1.5 ports but when xconnected that makes 336 T1s crossconnected as full bidirectional T1s. And NOW the higher density XC-VXC-10G does 48 STSes of full bidirectional T1s (ie 96 STSes can go to the VT1.5 capable subsystem on the XC card). That card on EBAY the other day was BUY IT NOW for $2500 and the MAX price seen was $4500 also a BIN price. The EVIL game you want to avoid if at all possible is using cerent TRANSMUX cards that go from M13 format to VT1.5 format. The original DS3XM-6 cards ONLY connected the M13 side via electrical BNC or SMB etc jacks on the back, but the newer DS3XM-12 cards finally delivered the "portless transmux" (no BNCs needed) originally promised way way back. The DS3XM-12 can on a port by port basis deliver the M13 side to either external jacks OR internally via an STS logical crossconnect (ie PORTLESS mode), The VT1.5 STSes are always done internally via the STS xconnect matrix. Even used, transmux cards are rare and EXPENSIVE even by cisco's arrogant standards.. But many of your interconnections to others can these days be ordered as VT1.5s especially if you have an optical connection to them just as easily as getting the growing old M13 format. Then do all crossconnecting from your keyboard.. Copper DSX sucks. Real DACSes $$$SUCK$$$ too. But back to elcheapo but sane copper crossconnect for T1s. ADC bought the KRONE punch block line. Not only are these better blocks than 66 blocks, but they also can have jack in and look both way testing or just jack in monitoring. They make various assemblies of these with 25 pair and possibly 32 pair CHAMP jacks on the back, but I never saw one that fit the "COLO-DSX" model where the normal through connection would be from one 32 pair CHAMP to another and there would be NO cross connections punched in needed UNLESS you needed to break the "NORMALLED THROUGH" connection the block provides. In that case you plug in an insulater or broken end of a popsicle stick in an emergency, and simply punch in whatever crossconnects you need. You would also need some custom cables to break the cross connect for testing and these would end in a conventional but cord mounted pair of M OI jacks (little 6 jack cluster) that would be themselves normalled X-connect wise (O-I and I-O) but could then be accessed with the same test cables used in a real DSX panel. I tried to "sell" one of their application engineers on the idea that they should have built this, and he did me a good mock-up drawing and then said he had discovered that Adtran had asked for something similar (and without some of my enhancements) and THAT had been turned by down product mgmt presumably because price or volume issues. But rather than have a PREWIRED to a 32 pair CHAMPs backed Krone blocks, just take 32 pair CHAMP ended cables to your M13s or whatever and punch the tails of 28 pairs on one side of each Krone block. If you REALLY want to get fancy, interleave O and I cables so an adjacent odd / even pair of pairs was a T1. O cables go the ODD pairs, and I cables to EVEN numbered pairs. Then x-connect from the other side as normal with a 2 pair jumper with the pairs flopped at ONE end. No 5th green TL wire but at this low density, so what. And you can make or have made frontal patch cables that override the punched in jumpers just as you do with TRUE DSX panels. IE intrusive test without breaking the punched in x-connect. I'm amazed at how many folks that occasionally use Krone blocks do not know those little slots are test access and even crossconnect capable mini jacks that are normaled through when nothing is plugged in. You can get bars that go across 19 or 23" racks that are designed to dense mount 66 or Krone or similar blocks. Your own back room and NOT some ILEC COLO? two strips of 5/8 prywood and you still leave open the center for block assemblies that have side or rear CHAMP connectors, or even the 66 blocks with rear tywrap tails. Someone like Homaco or AllenTel may have just what you want readybuilt. ----- Original Message ----- From: "Wallace Keith" To: Sent: Monday, May 04, 2009 4:05 PM Subject: RE: DSX cross-connect solution *This message was transferred with a trial version of CommuniGate(r) Pro* I would stick with wire wrap, 66 blocks make an inferior connection. If someone cannot deal with wire wrapping, they are not living in a telecom world. Find a contractor who can do this properly. Both Telect and ADC have good DSX panels in varying densities. -Keith -----Original Message----- From: sjk [mailto:sjk at sleepycatz.com] Sent: Monday, May 04, 2009 3:56 PM To: nanog at nanog.org Subject: DSX cross-connect solution I am trying to find hardware for a rebuild of our DS1 cross-connect frame and can't seem to find much out there. We've got ~300 DS1s that need to be x-connected between our M13s and I'm seeking an easy to manage solution. I've looked at the Telect panels but I'm concerned that my staff can't deal with wirewrap terminations. Has anyone seen, simply, a high density 66 field that can fit in a 23" rack? TIA -- steve From ops.lists at gmail.com Mon May 4 20:04:01 2009 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Tue, 5 May 2009 06:34:01 +0530 Subject: several messages In-Reply-To: References: <20090325093549.6738884b@milhouse.peachfamily.net> Message-ID: Oh lord, just when I thought it was safe to clean out the filter file .. is it kook season again, already? On Tue, May 5, 2009 at 2:38 AM, Dean Anderson wrote: > > This would be a good time to do a little background research on John > Levine, and discover that he's a spammer, pretending to be an > anti-spammer, with all the anticipated ill-effects on spam blocking. > > http://www.av8.net/IETF-watch/People/JohnLevine/index.html > > John Levine is a spammer: > > http://www.iadl.org/whitehat/whitehat-story.html > > As are a couple of other prominent "anti-spammers". > > ? ? ? ? ? ? ? ?--Dean From trejrco at gmail.com Mon May 4 20:26:45 2009 From: trejrco at gmail.com (TJ) Date: Mon, 4 May 2009 21:26:45 -0400 Subject: Where to buy Internet IP addresses In-Reply-To: References: <49FEF5C0.9050109@ttec.com> <200905041427.n44ERf0A003326@aurora.sol.net> <18a5e7cb0905041403q47b78c1cvaba1452c6e6e4f0@mail.gmail.com> <49FF65BC.2040207@brightok.net> Message-ID: <005f01c9cd20$904972f0$b0dc58d0$@com> >-----Original Message----- >From: Ricky Beam [mailto:jfbeam at gmail.com] >Sent: Monday, May 04, 2009 6:38 PM >To: nanog list >Subject: Re: Where to buy Internet IP addresses > >On Mon, 04 May 2009 18:01:32 -0400, Jack Bates wrote: >> Given there is no CLASS, but just a separation of network and host, >> I'd hate to compare it to classful routing. They probably would have >> been happy with a /96 network except for stateless autoconfig, which >> is quite nice for some stuff actually. > >Ok, calling it "classful routing" might be a little melodramatic. > >I would love to be able to set interfaces on my cisco hardware to /96's, but >it's not allowed. Autoconfig screws that up. Even if it's not used, you're >forced to live with it. Linux, BSD, etc. don't care. (and the instant they do, >I can remove that stupid code.) Actually, they will - you can set them to any arbitrary value between 1 and 128 (inclusive), atleast on every piece of gear I've tried to use. > >> I've not tried every vendor out there, but I've noticed some >> implementations handle /127 just fine from a routing perspective. > >So far, Cisco's gear is the only IPv6 routers I've messed with. And they >will not let you set an interface to anything smaller than a /64. >Loopbacks have slightly different rules, but in my case (IPv6 tunnels) that >fact hasn't proven very useful. See above. Maybe true on some gear, or some old IOS, or when using the auto-config key word ... ? /TJ From trejrco at gmail.com Mon May 4 20:29:44 2009 From: trejrco at gmail.com (TJ) Date: Mon, 4 May 2009 21:29:44 -0400 Subject: Where to buy Internet IP addresses In-Reply-To: References: <49FEF5C0.9050109@ttec.com> <200905041427.n44ERf0A003326@aurora.sol.net> <18a5e7cb0905041403q47b78c1cvaba1452c6e6e4f0@mail.gmail.com> <49FF65BC.2040207@brightok.net> <20090504225004.GA76011@ussenterprise.ufp.org> Message-ID: <006601c9cd20$f9204920$eb60db60$@com> >-----Original Message----- >From: Ricky Beam [mailto:jfbeam at gmail.com] >Sent: Monday, May 04, 2009 7:23 PM >To: Leo Bicknell; nanog list >Subject: Re: Where to buy Internet IP addresses > >On Mon, 04 May 2009 18:50:04 -0400, Leo Bicknell wrote: >> My 12.0(S), 12.4, and IOS-XR boxes are operating quite well with >> /112's and /127's on GigE interfaces to each other, on GSR's, 7300's, >> and 7200's. We also use /128's on loopbacks. > >Must have been old (very old?) code when I first tried this. 12.4(15)T doesn't >seem to care. > >But it still doesn't allow transitional addresses: >gw(config-if)#ipv6 address 0::101:101/96 >%FastEthernet0/0: Error: ::1.1.1.1/96 is invalid > >gw(config-if)#ipv6 address 0::101:101/128 >%FastEthernet0/0: Error: ::1.1.1.1/128 is invalid FWIW - ::/96 based addresses ave been deprecated for quite a few years. /TJ From trejrco at gmail.com Mon May 4 20:35:02 2009 From: trejrco at gmail.com (TJ) Date: Mon, 4 May 2009 21:35:02 -0400 Subject: Where to buy Internet IP addresses In-Reply-To: <49FF7F92.3030503@west.net> References: <200905012340.n41NeNKD093855@drugs.dv.isc.org> <49FB9A86.1080101@rollernet.us> <49FBA5DA.2020707@bogus.com> <6eb799ab0905022120o5be64c56ye664a8d00bd4eb91@mail.gmail.com> <8D4934F9-A041-4400-89E5-A2C566231F6A@ian.co.uk> <49FF7F92.3030503@west.net> Message-ID: <006a01c9cd21$b6a41030$23ec3090$@com> >> There are about 11 million /56s per person on the planet, we're not >> about to run out. > >"We have enough addresses for about four billion of these." > >http://www.cs.utexas.edu/users/chris/think/ARPANET/images/imp.gif > >"We're not about to run out." And while the two bear some level of similarity, and the comparison makes a great throw-away joke - the difference is in scale. Orders of orders of orders of orders (give or take a few more orders) of magnitude in difference. Taking the usual liberty with the math - 4.3B maximum addresses, compared to 18BB or so network segments (each of which supports as many hosts as we want). Also, the quote was accurate - they were not about to run out. That was more than several years down the road. Not bad for an experiment that escaped the lab ... Accounting for the aforementioned growth in the space, a run life of several centuries for IPv6 should be sufficient. /TJ From jbates at brightok.net Mon May 4 21:29:29 2009 From: jbates at brightok.net (Jack Bates) Date: Mon, 04 May 2009 21:29:29 -0500 Subject: Where to buy Internet IP addresses In-Reply-To: References: <200905042209.n44M95lb024221@aurora.sol.net> <49FF6BD4.1020505@brightok.net> Message-ID: <49FFA489.6060000@brightok.net> Ricky Beam wrote: > If I'm allowed to subnet my single /64, then I'm still not using NAT. > And as long as I don't go beyond /80, autoconfig can still work, at > least on ethernet -- which is pretty much 99.999% of cases. (not that I > advocate the use of autoconfig. *grin*) Sorry, Ricky. But that won't work. EUI-64 is required for autoconfig, and it expands the 48 bits to 64 bits by inserting FFFF or FFFE depending on if the original is a MAC-48 or EUI-48 identifier. That being said, you might be able to use stateless with tokens which can be less than 64 bits, though not sure how well implementations will handle stateless autoconfig with less than a /64. You can also use DHCPv6 with TA/NA addresses, though Cisco doesn't support those options in their IOS implementation at this time, open source DHCPv6 servers do. You can also backup to static assignments. Jack From randy at psg.com Mon May 4 21:49:02 2009 From: randy at psg.com (Randy Bush) Date: Tue, 05 May 2009 04:49:02 +0200 Subject: Where to buy Internet IP addresses In-Reply-To: References: <49FEF5C0.9050109@ttec.com> <200905041427.n44ERf0A003326@aurora.sol.net> <18a5e7cb0905041403q47b78c1cvaba1452c6e6e4f0@mail.gmail.com> Message-ID: > "64bit MAC" -- which pretty much exists nowhere. It's a repeat of the > mistakes from IPv4's early days: CLASSFUL ROUTING. > > I'm with you. I wish vendors and spec designers would just get over it > and let people subnet however they want. you can. there was a bit of a war in the ietf some years back, and yhe 64 bit boundary is a convention. hardware must route and forward on 128 bits. do other than 64 and you do not get auto-conf. some do not consider this a loss, others do. > So far, Cisco's gear is the only IPv6 routers I've messed with. And > they will not let you set an interface to anything smaller than a /64. i wonder what strange gear you tried. all routers, cisco and other, i play with operate on 128 bits. randy From Valdis.Kletnieks at vt.edu Mon May 4 21:51:46 2009 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Mon, 04 May 2009 22:51:46 -0400 Subject: Where to buy Internet IP addresses In-Reply-To: Your message of "Mon, 04 May 2009 21:29:29 CDT." <49FFA489.6060000@brightok.net> References: <200905042209.n44M95lb024221@aurora.sol.net> <49FF6BD4.1020505@brightok.net> <49FFA489.6060000@brightok.net> Message-ID: <58432.1241491906@turing-police.cc.vt.edu> On Mon, 04 May 2009 21:29:29 CDT, Jack Bates said: > Ricky Beam wrote: > > If I'm allowed to subnet my single /64, then I'm still not using NAT. > > And as long as I don't go beyond /80, autoconfig can still work, at > > least on ethernet -- which is pretty much 99.999% of cases. (not that I > > advocate the use of autoconfig. *grin*) > > Sorry, Ricky. But that won't work. EUI-64 is required for autoconfig, > and it expands the 48 bits to 64 bits by inserting FFFF or FFFE > depending on if the original is a MAC-48 or EUI-48 identifier. I think Ricky's point is that he could do autoconfig in a /80 as long as there isn't the semi-gratuitous MAC-48->EUI-64 expansion. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 226 bytes Desc: not available URL: From jbates at brightok.net Mon May 4 21:58:08 2009 From: jbates at brightok.net (Jack Bates) Date: Mon, 04 May 2009 21:58:08 -0500 Subject: Where to buy Internet IP addresses In-Reply-To: <58432.1241491906@turing-police.cc.vt.edu> References: <200905042209.n44M95lb024221@aurora.sol.net> <49FF6BD4.1020505@brightok.net> <49FFA489.6060000@brightok.net> <58432.1241491906@turing-police.cc.vt.edu> Message-ID: <49FFAB40.1070603@brightok.net> Valdis.Kletnieks at vt.edu wrote: > > I think Ricky's point is that he could do autoconfig in a /80 as long as there > isn't the semi-gratuitous MAC-48->EUI-64 expansion. > Is there an implementation of autoconfig that doesn't do the expansion? I haven't tested it, but I'm not even sure that autoconfig would work with a token using a smaller than /64 prefix. It may work, but it's definitely outside the standard and would be implementation specific. Jack From kauer at biplane.com.au Mon May 4 22:04:49 2009 From: kauer at biplane.com.au (Karl Auer) Date: Tue, 05 May 2009 13:04:49 +1000 Subject: Where to buy Internet IP addresses In-Reply-To: References: <49FEF5C0.9050109@ttec.com> <200905041427.n44ERf0A003326@aurora.sol.net> <18a5e7cb0905041403q47b78c1cvaba1452c6e6e4f0@mail.gmail.com> Message-ID: <1241492690.8158.7.camel@karl> On Tue, 2009-05-05 at 04:49 +0200, Randy Bush wrote: > > I'm with you. I wish vendors and spec designers would just get over it > > and let people subnet however they want. > [...] > do other than 64 and you do not get auto-conf. some do not consider > this a loss, others do. This is an important distinction. - you CAN subnet however you like, with any number of bits in your prefixes - autoconfiguration will work only in subnets with a 64 bit prefix. The two matters are quite independent of each other, as far as I can tell. Regards, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer at biplane.com.au) +61-2-64957160 (h) http://www.biplane.com.au/~kauer/ +61-428-957160 (mob) GPG fingerprint: 07F3 1DF9 9D45 8BCD 7DD5 00CE 4A44 6A03 F43A 7DEF -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From Charles at thewybles.com Mon May 4 22:17:44 2009 From: Charles at thewybles.com (Charles at thewybles.com) Date: Tue, 5 May 2009 03:17:44 +0000 Subject: Where to buy Internet IP addresses Message-ID: <1919352140-1241493478-cardhu_decombobulator_blackberry.rim.net-997240557-@bxe1197.bisx.prod.on.blackberry> Re sending... I know operational content is frowned on :) ... However in an effort to avoid this thread getting kicked to the curb... we have just seen days of the same arguments between the same posters over and over. Let's gather some data on current operational (there's that evil word again) practices and see how its working or not working out. Anyone care to field my question? how do existing providers hand out space? I know that Hurricane electric (via its tunnel service) hands out a /64 by default and a /48 is a click away. How do other providers handle it? I'm in the us and only have native v4 connectivity :( Do the various traditional last mile providers (sprint/Verizon/att/patch etc ) offer it for t1 and better? If they do then what do they hand out by default, what's available, at what price point and what's the upgrade path? Is it one click like he? No provider I have talked to offers it for residential connectivity in the united states. What does free.fr do? If there is this level of confusion and disagreement around addressing schemes then will it ever be offered to residences over traditional last mile loops? ------Original Message------ From: Stephen Sprunk To: Bill Stewart Cc: north American Noise and Off-topic Gripes Cc: Joe Greco Subject: Re: Where to buy Internet IP addresses Sent: May 4, 2009 2:36 PM Bill Stewart wrote: > When I came back, I found this ugly EUI-64 thing instead, so not only was autoconfiguration much uglier, but you needed a /56 instead of a /64 if you were going to subnet. It's supposed to be a /48 per customer, on the assumption that 16 bits of subnet information is sufficient for virtually anyone; exceptions should be rare enough that they can be handled as special cases. The /56 monstrosity came about because a US cable company wanted to assign a prefix to every home they passed, regardless of whether it contained a customer, so that they'd never need to renumber anything ever again. However, that would require they get more than the /32 minimum allocation, and ARIN policy doesn't allow _potential_ customers as a justification for getting a larger allocation, so they had to shrink the per-customer prefix down to a /56 to fit them all into a single /32. If all those assignments were to _real_ customers, they could have gotten a /24 and given each customer a /48 as expected. And, after that, many folks who can't wrap their heads around the size of the IPv6 address space appear to be obsessed with doing the same in other cases where even that weak justification doesn't apply... > Does anybody know why anybody thought it was a good idea to put the extra bits in the middle, or for IPv6 to adopt them? > Why the switch from EUI-48 to EUI-64? Someone in the IEEE got worried about running short of MAC (er, EUI-48) addresses at some point in the future, so they inserted 16 bits in the middle (after the OUI) to form an EUI-64 and are now "discouraging" new uses of EUI-48. The IETF decided to follow the IEEE's guidance and switch IPv6 autoconfig from EUI-48 to EUI-64, but FireWire is the only significant user of EUI-64 addresses to date; if you're using a link layer with EUI-48 addresses (e.g. Ethernet), an extra 16 bits (FFFE) get stuffed in the middle to transform it into the EUI-64 that IPv6 expects. 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 Sent via BlackBerry from T-Mobile From jfbeam at gmail.com Mon May 4 22:28:14 2009 From: jfbeam at gmail.com (Ricky Beam) Date: Mon, 04 May 2009 23:28:14 -0400 Subject: Where to buy Internet IP addresses In-Reply-To: <49FFA489.6060000@brightok.net> References: <200905042209.n44M95lb024221@aurora.sol.net> <49FF6BD4.1020505@brightok.net> <49FFA489.6060000@brightok.net> Message-ID: On Mon, 04 May 2009 22:29:29 -0400, Jack Bates wrote: > EUI-64 is required for autoconfig... "On paper" :-) There's no technological reason why the 48bit MAC wouldn't be enough on it's own. Tacking on an extra (fixed) 16bit value doesn't make it any more unique. Doing so also would not add any level of complexity to address determination -- it's still a simple concat. Show of hands. How many people have massive firewire based IP networks? *crickets* Right. (I've used ip1394 like twice in over a decade... a file transfer between a laptop and desktop.) From jgreco at ns.sol.net Mon May 4 23:08:51 2009 From: jgreco at ns.sol.net (Joe Greco) Date: Mon, 4 May 2009 23:08:51 -0500 (CDT) Subject: Where to buy Internet IP addresses In-Reply-To: from "Ricky Beam" at May 04, 2009 11:28:14 PM Message-ID: <200905050408.n4548pQO038066@aurora.sol.net> > On Mon, 04 May 2009 22:29:29 -0400, Jack Bates wrote: > > EUI-64 is required for autoconfig... > > "On paper" :-) There's no technological reason why the 48bit MAC wouldn't > be enough on it's own. For today. But, remember, this sort of shortsightedness is what landed us in the current IPv4 pain. Do you have anything beyond hysterical raisins to justify not making a future-proofing change now, before IPv6 is widely deployed, and changes can be easily made? > Tacking on an extra (fixed) 16bit value doesn't > make it any more unique. For ethernet, today. > Doing so also would not add any level of > complexity to address determination -- it's still a simple concat. Correct. So it's trivial to do, and it future-proofs us to be able to support EUI-64. That means that when the next great networking technology comes about, we don't need to make invasive changes, devise transition strategies, or wreak havoc. > Show of hands. How many people have massive firewire based IP networks? Who the fsck cares. > *crickets* Right. (I've used ip1394 like twice in over a decade... a file > transfer between a laptop and desktop.) Yeah, that's nice. Who the fsck cares. Most of the significant problems with IPv4 are due to people thinking small, and not having a vision towards the future. Back when "computers" meant something the size of a VAX 11/750 or bigger, it is easy to see how designers didn't really have the concept that maybe someday there would be microprocessors all around us, that we'd be walking around with cell phones that had more computational capabilities than their entire computer. Likewise, I am afraid to wonder what we're going to see in another 30 years, but my bet is that it'll be networked! So, please, please, either explain why EUI-64 is such a horrible, awful, terrible hardship for you to endure. If it's because your Atari 400 doesn't have the cycles to keep up with EUI-64 translation at gigabit speed, then say that. Or you can outline some other way in which it is fundamentally a bad idea to future-proof by using the latest EUI standard, rather than an old, dated standard. If you don't actually have a rational explanation, then you just appear to be a troll. ... 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 Tue May 5 00:09:15 2009 From: jbates at brightok.net (Jack Bates) Date: Tue, 05 May 2009 00:09:15 -0500 Subject: Where to buy Internet IP addresses In-Reply-To: <1919352140-1241493478-cardhu_decombobulator_blackberry.rim.net-997240557-@bxe1197.bisx.prod.on.blackberry> References: <1919352140-1241493478-cardhu_decombobulator_blackberry.rim.net-997240557-@bxe1197.bisx.prod.on.blackberry> Message-ID: <49FFC9FB.4020606@brightok.net> Charles at thewybles.com wrote: > Anyone care to field my question? > I think many of your questions have been answered in past threads this month a couple of times. > how do existing providers hand out space? > I know that Hurricane electric (via its tunnel service) hands out a /64 by default and a /48 is a click away. > First, I hate to compare HE's tunnel service to anything other than a tunnel service. Second, I don't think I've seen any last mile providers offering IPv6 without a tunnel setup of some type. The primary reasons being, there are service issues with deployed IPv6 and the CPE market is limited. Business class services hand out IPv6 like anything else. Here's your circuit, here's your static/BGP setup, do you need use to assign you some or did you bring your own? > How do other providers handle it? I'm in the us and only have native v4 connectivity :( > Tunneling is probably your only option for v6. Some small/medium providers have v6 deployed at the edge, but I suspect it's a limited deployment due to the QOS issues and lack of CPE support issues. Deploying to the mass residential market it doesn't make much sense right now. > Do the various traditional last mile providers (sprint/Verizon/att/patch etc ) offer it for t1 and better? If they do then what do they hand out by default, what's available, at what price point and what's the upgrade path? Is it one click like he? > Sprint I believe will give you tunnel service if you're a transit customer, and I'll keep my personal viewpoint on their IPv6 connectivity to myself. I believe Verizon business offers it, but I think they specialize in colo??? NTT and Global Crossing offer dual stack and are the only NSPs I know to do so (If HE qualifies, forgive me, as I don't know their network topology, but I do believe they offer dual stack in their POPs as well). So if you can get a circuit to any of those, you could probably get native v6 on that circuit. > No provider I have talked to offers it for residential connectivity in the united states. I do, but I'm not in your area, and I only offer it on a customer requested basis and with a billion and one disclaimers. After all, there's a lot missing on the home network side of things. > What does free.fr do? > Provides services to France? Just guessing. > If there is this level of confusion and disagreement around addressing schemes then will it ever be offered to residences over traditional last mile loops? > It will be offered, and it will probably be bumpy. If the IETF doesn't narrow down and standardize some home network protocols to make home networking as plug and play as the current NAT double/triple NAT layouts that currently exist, then customers will be restricted on what they can use. Providers will deploy as they can or as they have to, but there will be restrictions to keep support costs down. Some of the addressing scheme arguments have valid issues, while others are a matter of local preference. The preference arguments can be safely ignored, as even in IPv4 world there are a variety of layouts. Some ISP's only allow a single IPv4 address, while others allow multiple. Some require PPP sessions, while others do not. Some require mandated equipment do MAC locking, etc. These types of preferences and differences between ISPs will not change with IPv6. The CPEs will have to cope. Example, an ISP may require DHCPv6 IA_TA addressing to CPE's with DHCPv6-PD. Another may require auto-config with DHCPv6-PD. Some will still use PPP while others will not. I'm sure there will be at least one ISP that won't support DHCPv6-PD at all. Jack From Charles at thewybles.com Tue May 5 00:19:42 2009 From: Charles at thewybles.com (Charles at thewybles.com) Date: Tue, 5 May 2009 05:19:42 +0000 Subject: Where to buy Internet IP addresses Message-ID: <888720438-1241500796-cardhu_decombobulator_blackberry.rim.net-299453910-@bxe1197.bisx.prod.on.blackberry> Thanks for the in depth reply. There have been many v6 threads and perhaps I haven't paid enough attention or looked hard enough for the answers. :) I will send a more detailed reply tomorrow when I'm at a mail client that can do in line replies. :) Sent via BlackBerry from T-Mobile From cabo at tzi.org Tue May 5 00:26:14 2009 From: cabo at tzi.org (Carsten Bormann) Date: Tue, 5 May 2009 07:26:14 +0200 Subject: Where to buy Internet IP addresses In-Reply-To: <49FF5FD0.6010304@sprunk.org> References: <49FEF5C0.9050109@ttec.com> <200905041427.n44ERf0A003326@aurora.sol.net> <18a5e7cb0905041403q47b78c1cvaba1452c6e6e4f0@mail.gmail.com> <49FF5FD0.6010304@sprunk.org> Message-ID: On May 4, 2009, at 23:36, Stephen Sprunk wrote: > FireWire is the only significant user of EUI-64 addresses Yesterday, it was. You might want to read up about IEEE 802.15.4 and 6LoWPAN. We are not joking when we talk about the next billion nodes on the Internet. For those who are worried about running out on /56s: There are 9000 trillion of those in the current 2000::/3 that is being handed out. Each /56 is about a customer relationship, a home, a wire, ... Say, each of them only needs a single dollar to get set up. We are talking about 9000 trillion dollars being spent before we have to open up the next /3. (2008's world domestic product, measured in purchasing power parity was about $ 69.49 trillion, by the way. I'm talking about spending 129.6 years of world productivity for one dollar per /56, here.) Folks: There will *never* be a reason to hand out /60s, /62s, /64s, or, heaven forbid, /96s. And I mean *never*: It's much more useful to discuss this issue on fundamentals than on past practices. Really, /56 for everyone is the only way back to an Internet. Gruesse, Carsten From jfbeam at gmail.com Tue May 5 01:18:14 2009 From: jfbeam at gmail.com (Ricky Beam) Date: Tue, 05 May 2009 02:18:14 -0400 Subject: Where to buy Internet IP addresses In-Reply-To: <200905050408.n4548pQO038066@aurora.sol.net> References: <200905050408.n4548pQO038066@aurora.sol.net> Message-ID: On Tue, 05 May 2009 00:08:51 -0400, Joe Greco wrote: > For today. But, remember, this sort of shortsightedness is what landed > us in the current IPv4 pain. 48bit MACs have caused IPv4 address exhaustion? Wow. I didn't know that. > ... justify not making a future-proofing change now, before IPv6 > is widely deployed, and changes can be easily made? It's not very widely deployed now, and it's already too late to make simple changes. ONE single, simple protocol change requires a lot of people to do a lot of work. > For ethernet, today. IPv6 is a decade old and there still aren't many people using it. Ethernet is 30 years old. Do you honestly think you'd be able to roll out EthernetV2(tm) with 64bit MACs anytime in the next century? Ethernet is far more fundamental than IPv4, grown into the silicon of almost everything. Even though there are alternatives to ethernet (infiniband anyone?) ethernet is still *everywhere*. > Correct. So it's trivial to do, and it future-proofs us to be able to > support EUI-64. ... And the only reason we'd need to use EUI-64? Because some twits decided to use a Layer 2 address in a Layer 3 address. Or have we exhausted EUI-48 as well? > Most of the significant problems with IPv4 are due to people thinking > small, and not having a vision towards the future. ... I'm thinking small? No. I'm being frugal and efficient -- "conservative". FORCING networks to be no smaller than /64 -- per the fundamental requirement for SLAAC -- when there's absolutely no forseeable need for 18billion billion hosts per network is wasteful beyond measure. I see this a fundamentally the same as handing out /8's 25 years ago -- "because the protocol (classfulness) requires it." Just because *we* see the IPv6 address space as unbelievablly huge *today*, doesn't mean we should carve it up in recklessly huge chunks. That's exactly how IPv4 was seen long ago, and we've been and will be living with that mistake for decades. So, to sum up... we're being locked into using /64's as a minimum allocation simply because a fundamental part of IPv6 (SLAAC) requires an EUI-64 -- taking a layer-2 address and promoting it to a layer-3 address, more or less because it's there and supposed to be globally unique (read: we're lazy and don't want to figure out another way to be "stateless".) This despite no current internet devices using EUI-64[*], and the overwelming technology leader (ethernet) doesn't and very likely never will (given the millions of tons of existing hardware in use.) ([*] according to the wiki, firewire and zigbee are the only things using EUI-64. I don't know of anyone using firewire as a network backbone. (obviously, not that you care.) Zigbee is relatively new and similar to bluetooth; will people use them as a NIC or connect little zigbee gadgets to the internet -- well, there are coffee makers, vending machines, and christmas lights on the internet, so as a novelty, certainly. How many bluetooth devices are running IP over bluetooth? That said, I could see PAN meshes (personal area networks) eating a huge number of addresses, but /64???) From swmike at swm.pp.se Tue May 5 01:34:17 2009 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Tue, 5 May 2009 08:34:17 +0200 (CEST) Subject: Where to buy Internet IP addresses In-Reply-To: References: <200905050408.n4548pQO038066@aurora.sol.net> Message-ID: On Tue, 5 May 2009, Ricky Beam wrote: > That's exactly how IPv4 was seen long ago, and we've been and will be living > with that mistake for decades. It was fixed 15 years ago, but not before more than half the space was "wasted". With IPv6 we can use current policy and only "waste" a /3 and then we can change policy and do something smarter if needed. This /3 will last us a long time and we have plenty of time to create something better than SLAAC. It's time to deploy IPv6 *NOW* with what we have, not to start to change it in fundamental ways and delay deployment several more years by starting to change IPv6 stacks who are by now fairly mature. -- Mikael Abrahamsson email: swmike at swm.pp.se From mohacsi at niif.hu Tue May 5 02:07:54 2009 From: mohacsi at niif.hu (Mohacsi Janos) Date: Tue, 5 May 2009 09:07:54 +0200 (CEST) Subject: Where to buy Internet IP addresses In-Reply-To: References: <49FEF5C0.9050109@ttec.com> <200905041427.n44ERf0A003326@aurora.sol.net> <18a5e7cb0905041403q47b78c1cvaba1452c6e6e4f0@mail.gmail.com> Message-ID: On Mon, 4 May 2009, Ricky Beam wrote: > On Mon, 04 May 2009 17:03:31 -0400, Bill Stewart > wrote: >> When I came back, I found this ugly EUI-64 thing instead, >> so not only was autoconfiguration much uglier, >> but you needed a /56 instead of a /64 if you were going to subnet. >> Does anybody know why anybody thought it was a good idea >> to put the extra bits in the middle, or for IPv6 to adopt them? > > "64bit MAC" -- which pretty much exists nowhere. It's a repeat of the > mistakes from IPv4's early days: CLASSFUL ROUTING. Blame IEEE. They claimed that for identifying network cards 64 bit ID will be used in th future.... (Already used in IEEE 1394) > > I'm with you. I wish vendors and spec designers would just get over it and > let people subnet however they want. If I want to set a network to be /96 or > /120, I should be allowed to do so. Yes, I know autoconfig will not work -- > and I don't want it to. I can make /31 IPv4 routes -- no router I've ever > used complained about it. (that sends 2 addresses to one place; what happens > in the place is not the router's concern.) I did not get any problem setting up any sunet length manually all the systems I tested. Best Regards, Janos Mohacsi From timtuppence at yahoo.de Tue May 5 02:22:58 2009 From: timtuppence at yahoo.de (Tim Tuppence) Date: Tue, 5 May 2009 00:22:58 -0700 (PDT) Subject: Why is www.google.cat resolving? Message-ID: <562916.65528.qm@web24606.mail.ird.yahoo.com> Hello, I am seeing that www.google.cat resolves from three different networks. It even resolves from here: http://www.squish.net/dnscheck/ What is going on? Thanks, Tim From bruns at 2mbit.com Tue May 5 02:26:42 2009 From: bruns at 2mbit.com (Brielle Bruns) Date: Tue, 05 May 2009 01:26:42 -0600 Subject: Why is www.google.cat resolving? In-Reply-To: <562916.65528.qm@web24606.mail.ird.yahoo.com> References: <562916.65528.qm@web24606.mail.ird.yahoo.com> Message-ID: <49FFEA32.9080805@2mbit.com> On 5/5/09 1:22 AM, Tim Tuppence wrote: > Hello, > > I am seeing that www.google.cat resolves from three different networks. > It even resolves from here: http://www.squish.net/dnscheck/ > > What is going on? > > Thanks, > > Tim > > > > A quick google and wikipedia check shows... http://en.wikipedia.org/wiki/.cat .cat is a sponsored top-level domain intended to be used to highlight the Catalan language and culture. Its policy has been developed by ICANN and Fundaci? puntCAT. It was approved in September 2005. :) -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org / http://www.ahbl.org From Jon.Kibler at aset.com Tue May 5 02:29:52 2009 From: Jon.Kibler at aset.com (Jon Kibler) Date: Tue, 05 May 2009 03:29:52 -0400 Subject: Why is www.google.cat resolving? In-Reply-To: <562916.65528.qm@web24606.mail.ird.yahoo.com> References: <562916.65528.qm@web24606.mail.ird.yahoo.com> Message-ID: <49FFEAF0.8000504@aset.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Tim Tuppence wrote: > Hello, > > I am seeing that www.google.cat resolves from three different networks. > It even resolves from here: http://www.squish.net/dnscheck/ > > What is going on? > > Thanks, > > Tim Because .CAT is a valid TLD: http://en.wikipedia.org/wiki/.cat Jon - -- Jon R. Kibler Chief Technical Officer Advanced Systems Engineering Technology, Inc. Charleston, SC USA o: 843-849-8214 c: 843-813-2924 (NEW!) s: 843-564-4224 http://www.linkedin.com/in/jonrkibler My PGP Fingerprint is: BAA2 1F2C 5543 5D25 4636 A392 515C 5045 CF39 4253 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkn/6u8ACgkQUVxQRc85QlOZBQCeLlZDnZulKt1mcRWtGGxcSJp8 RRgAn2DphdhNZBB3HgRByswCW5ai/B5G =mND3 -----END PGP SIGNATURE----- ================================================== Filtered by: TRUSTEM.COM's Email Filtering Service http://www.trustem.com/ No Spam. No Viruses. Just Good Clean Email. From timtuppence at yahoo.de Tue May 5 02:31:37 2009 From: timtuppence at yahoo.de (Tim Tuppence) Date: Tue, 5 May 2009 00:31:37 -0700 (PDT) Subject: AW: Why is www.google.cat resolving? In-Reply-To: <49FFEA32.9080805@2mbit.com> References: <562916.65528.qm@web24606.mail.ird.yahoo.com> <49FFEA32.9080805@2mbit.com> Message-ID: <391167.48118.qm@web24614.mail.ird.yahoo.com> > A quick google and wikipedia check shows... > > http://en.wikipedia.org/wiki/.cat Thanks. From sethm at rollernet.us Tue May 5 02:33:23 2009 From: sethm at rollernet.us (Seth Mattinen) Date: Tue, 05 May 2009 00:33:23 -0700 Subject: Why is www.google.cat resolving? In-Reply-To: <562916.65528.qm@web24606.mail.ird.yahoo.com> References: <562916.65528.qm@web24606.mail.ird.yahoo.com> Message-ID: <49FFEBC3.9060504@rollernet.us> Tim Tuppence wrote: > Hello, > > I am seeing that www.google.cat resolves from three different networks. > It even resolves from here: http://www.squish.net/dnscheck/ > > What is going on? > Why are you expecting it not to? ~Seth From bortzmeyer at nic.fr Tue May 5 02:35:30 2009 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Tue, 5 May 2009 09:35:30 +0200 Subject: Why is www.google.cat resolving? In-Reply-To: <562916.65528.qm@web24606.mail.ird.yahoo.com> References: <562916.65528.qm@web24606.mail.ird.yahoo.com> Message-ID: <20090505073530.GA26930@nic.fr> On Tue, May 05, 2009 at 12:22:58AM -0700, Tim Tuppence wrote a message of 14 lines which said: > I am seeing that www.google.cat resolves from three different networks. New trend on NANOG? Complaining when things work and not when they fail? From cmeidinger at sendmail.com Tue May 5 02:41:41 2009 From: cmeidinger at sendmail.com (Chris Meidinger) Date: Tue, 5 May 2009 09:41:41 +0200 Subject: Why is www.google.cat resolving? In-Reply-To: <49FFEBC3.9060504@rollernet.us> References: <562916.65528.qm@web24606.mail.ird.yahoo.com> <49FFEBC3.9060504@rollernet.us> Message-ID: On 05.05.2009, at 09:33, Seth Mattinen wrote: > Tim Tuppence wrote: >> Hello, >> >> I am seeing that www.google.cat resolves from three different >> networks. >> It even resolves from here: http://www.squish.net/dnscheck/ >> >> What is going on? >> > > Why are you expecting it not to? I think the real question here is why does schroedingers.cat not resolve, and who will be the first person able to jump through the requisite hoops make it do so. From bruns at 2mbit.com Tue May 5 02:51:29 2009 From: bruns at 2mbit.com (Brielle Bruns) Date: Tue, 5 May 2009 07:51:29 +0000 Subject: AW: Why is www.google.cat resolving? Message-ID: <1823268073-1241509906-cardhu_decombobulator_blackberry.rim.net-1054269883-@bxe1227.bisx.prod.on.blackberry> 12mbit DSL: $80 Firefox for platform of choice: $0 Knowing you can do a 10 second google search for answers to simple questions: priceless For everything else, there's I Can Has Cheezburger. Brielle (Bored, tired, and on her blackberry) ------Original Message------ From: Tim Tuppence To: Brielle Bruns Cc: nanog at nanog.org Subject: AW: Why is www.google.cat resolving? Sent: May 5, 2009 1:31 AM > A quick google and wikipedia check shows... > > http://en.wikipedia.org/wiki/.cat Thanks. -- Brielle Bruns http://www.sosdg.org / http://www.ahbl.org From bortzmeyer at nic.fr Tue May 5 02:52:23 2009 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Tue, 5 May 2009 09:52:23 +0200 Subject: Why is www.google.cat resolving? In-Reply-To: References: <562916.65528.qm@web24606.mail.ird.yahoo.com> <49FFEBC3.9060504@rollernet.us> Message-ID: <20090505075223.GB28527@nic.fr> On Tue, May 05, 2009 at 09:41:41AM +0200, Chris Meidinger wrote a message of 17 lines which said: > I think the real question here is why does schroedingers.cat not > resolve, That's because ".cat" has IDN and therefore it should be schr?dingers.cat From fweimer at bfk.de Tue May 5 03:15:12 2009 From: fweimer at bfk.de (Florian Weimer) Date: Tue, 05 May 2009 10:15:12 +0200 Subject: Where to buy Internet IP addresses In-Reply-To: <49FFA489.6060000@brightok.net> (Jack Bates's message of "Mon, 04 May 2009 21:29:29 -0500") References: <200905042209.n44M95lb024221@aurora.sol.net> <49FF6BD4.1020505@brightok.net> <49FFA489.6060000@brightok.net> Message-ID: <827i0wm0dr.fsf@mid.bfk.de> * Jack Bates: > Sorry, Ricky. But that won't work. EUI-64 is required for autoconfig, > and it expands the 48 bits to 64 bits by inserting FFFF or FFFE > depending on if the original is a MAC-48 or EUI-48 identifier. I'm rather puzzled why this blatant layering violation is still sold as a must-have feature. -- 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 jmaimon at ttec.com Tue May 5 07:19:52 2009 From: jmaimon at ttec.com (Joe Maimon) Date: Tue, 05 May 2009 08:19:52 -0400 Subject: Where to buy Internet IP addresses In-Reply-To: References: <200905050408.n4548pQO038066@aurora.sol.net> Message-ID: <4A002EE8.2070002@ttec.com> Mikael Abrahamsson wrote: > On Tue, 5 May 2009, Ricky Beam wrote: > >> That's exactly how IPv4 was seen long ago, and we've been and will be >> living with that mistake for decades. > > It was fixed 15 years ago, but not before more than half the space was > "wasted". With IPv6 we can use current policy and only "waste" a /3 and > then we can change policy and do something smarter if needed. This /3 > will last us a long time and we have plenty of time to create something > better than SLAAC. Fixing ipv4 didnt erase the pain of the brokeness. Odds are it will be much much worse if that happens with ipv6. Doing potentially stupid things now because we can fix it later isnt intelligent. One potential problem scenario is larger proliferation of DFZ routes than would have otherwise been necessary - simultaneous with large scale ipv4 de-aggregation. About 13% of ipv6 is assigned for addressing purposes. According to IANA, the /3 is about 0.8% allocated and we already have 1700 ipv6 routes, which according to statistics is about 0.014% of the /3. And we arent even using it for anything important yet, meaning something that could not be done over ipv4 internet or ipv4 vpn. At this rate, the /3 will be full with about 12 million routes. That isnt far fetched assuming most corporations and other tech savvy users go with PI over the next 15-30 years. Even if we can stick to roughly one prefix per AS, my best guesstimate is anywhere between 50-250k ipv6 routes until ipv4 routes start declining, depending on how long that takes. Expecting organizations to renumber into larger assignments in order to keep overall prefixes low is an unrealistic hardship. If the goal is to keep each organization to a single prefix, /48 per customer suggest a minimum allocation on the order of either /24 (16m customers, 2m per /3) or a /28 (1m customers, 34m in the /3) instead of a /32 (65k customers, 530m in the /3). Are there any better numbers out there other than these hastily scribbled back of envelope ones? I suppose the question is, are we building a system that can stand for decades or centuries? Right now it seems to be optimizing for both. Joe From mmoriniaux at prosodie.com Tue May 5 07:27:42 2009 From: mmoriniaux at prosodie.com (Moriniaux Michel) Date: Tue, 5 May 2009 14:27:42 +0200 Subject: Where to buy Internet IP addresses References: <1919352140-1241493478-cardhu_decombobulator_blackberry.rim.net-997240557-@bxe1197.bisx.prod.on.blackberry> Message-ID: Hello all, Free.fr gives us a /64 to our ADSL/FTTH boxes, the autoprov interface does not give an option for more. For insights of how Free.fr does thing please see this RIPE presentation: http://www.ripe.net/ripe/meetings/ripe-58/content/presentations/ipv6-free.pdf best regards, Michel -----Message d'origine----- De?: Charles at thewybles.com [mailto:Charles at thewybles.com] Envoy??: mardi 5 mai 2009 05:18 ??: nanog at merit.edu Objet?: Re: Where to buy Internet IP addresses Re sending... I know operational content is frowned on :) ... However in an effort to avoid this thread getting kicked to the curb... we have just seen days of the same arguments between the same posters over and over. Let's gather some data on current operational (there's that evil word again) practices and see how its working or not working out. Anyone care to field my question? how do existing providers hand out space? I know that Hurricane electric (via its tunnel service) hands out a /64 by default and a /48 is a click away. How do other providers handle it? I'm in the us and only have native v4 connectivity :( Do the various traditional last mile providers (sprint/Verizon/att/patch etc ) offer it for t1 and better? If they do then what do they hand out by default, what's available, at what price point and what's the upgrade path? Is it one click like he? No provider I have talked to offers it for residential connectivity in the united states. What does free.fr do? If there is this level of confusion and disagreement around addressing schemes then will it ever be offered to residences over traditional last mile loops? ------Original Message------ From: Stephen Sprunk To: Bill Stewart Cc: north American Noise and Off-topic Gripes Cc: Joe Greco Subject: Re: Where to buy Internet IP addresses Sent: May 4, 2009 2:36 PM Bill Stewart wrote: > When I came back, I found this ugly EUI-64 thing instead, so not only was autoconfiguration much uglier, but you needed a /56 instead of a /64 if you were going to subnet. It's supposed to be a /48 per customer, on the assumption that 16 bits of subnet information is sufficient for virtually anyone; exceptions should be rare enough that they can be handled as special cases. The /56 monstrosity came about because a US cable company wanted to assign a prefix to every home they passed, regardless of whether it contained a customer, so that they'd never need to renumber anything ever again. However, that would require they get more than the /32 minimum allocation, and ARIN policy doesn't allow _potential_ customers as a justification for getting a larger allocation, so they had to shrink the per-customer prefix down to a /56 to fit them all into a single /32. If all those assignments were to _real_ customers, they could have gotten a /24 and given each customer a /48 as expected. And, after that, many folks who can't wrap their heads around the size of the IPv6 address space appear to be obsessed with doing the same in other cases where even that weak justification doesn't apply... > Does anybody know why anybody thought it was a good idea to put the extra bits in the middle, or for IPv6 to adopt them? > Why the switch from EUI-48 to EUI-64? Someone in the IEEE got worried about running short of MAC (er, EUI-48) addresses at some point in the future, so they inserted 16 bits in the middle (after the OUI) to form an EUI-64 and are now "discouraging" new uses of EUI-48. The IETF decided to follow the IEEE's guidance and switch IPv6 autoconfig from EUI-48 to EUI-64, but FireWire is the only significant user of EUI-64 addresses to date; if you're using a link layer with EUI-48 addresses (e.g. Ethernet), an extra 16 bits (FFFE) get stuffed in the middle to transform it into the EUI-64 that IPv6 expects. 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 Sent via BlackBerry from T-Mobile From jbates at brightok.net Tue May 5 07:29:39 2009 From: jbates at brightok.net (Jack Bates) Date: Tue, 05 May 2009 07:29:39 -0500 Subject: Where to buy Internet IP addresses In-Reply-To: <827i0wm0dr.fsf@mid.bfk.de> References: <200905042209.n44M95lb024221@aurora.sol.net> <49FF6BD4.1020505@brightok.net> <49FFA489.6060000@brightok.net> <827i0wm0dr.fsf@mid.bfk.de> Message-ID: <4A003133.3050005@brightok.net> Florian Weimer wrote: > * Jack Bates: > >> Sorry, Ricky. But that won't work. EUI-64 is required for autoconfig, >> and it expands the 48 bits to 64 bits by inserting FFFF or FFFE >> depending on if the original is a MAC-48 or EUI-48 identifier. > > I'm rather puzzled why this blatant layering violation is still sold > as a must-have feature. > It's not a must have if you manage your own network. There are always other options. That being said, if you are an ISP handing out prefixes to customers, there is an expectation that the customer will probably use it given the direction CPE implementations are going. Thus you have to predict that if you don't want to setup all your customer's networks for them, they'll probably be using /64 per subnet. Jack From jmaimon at ttec.com Tue May 5 07:42:31 2009 From: jmaimon at ttec.com (Joe Maimon) Date: Tue, 05 May 2009 08:42:31 -0400 Subject: Where to buy Internet IP addresses In-Reply-To: References: <49FEF5C0.9050109@ttec.com> <200905041427.n44ERf0A003326@aurora.sol.net> <18a5e7cb0905041403q47b78c1cvaba1452c6e6e4f0@mail.gmail.com> Message-ID: <4A003437.4010808@ttec.com> Mohacsi Janos wrote: > > > On Mon, 4 May 2009, Ricky Beam wrote: > >> On Mon, 04 May 2009 17:03:31 -0400, Bill Stewart >> wrote: >>> When I came back, I found this ugly EUI-64 thing instead, >>> so not only was autoconfiguration much uglier, >>> but you needed a /56 instead of a /64 if you were going to subnet. >>> Does anybody know why anybody thought it was a good idea >>> to put the extra bits in the middle, or for IPv6 to adopt them? >> >> "64bit MAC" -- which pretty much exists nowhere. It's a repeat of the >> mistakes from IPv4's early days: CLASSFUL ROUTING. > > > Blame IEEE. They claimed that for identifying network cards 64 bit ID > will be used in th future.... (Already used in IEEE 1394) > Even if that is true and doesnt require ethernet as we know it to be forklifted which may be enough to rule it out from ever happening (see 1500 mtu for reference), address auto configuration does not require 64 bits. Its just nicer that way. What IEEE is concerned about is global uniqueness purity. Global uniqueness into perpetuity isnt required operationally on a lan, its just nicer that way. Gateway directed auto-conf enable-able on any bit length, with icmp conflict detection seems no worse that what we have now with either dhcpv4 or apipa. Joe From jmaimon at ttec.com Tue May 5 07:58:41 2009 From: jmaimon at ttec.com (Joe Maimon) Date: Tue, 05 May 2009 08:58:41 -0400 Subject: Where to buy Internet IP addresses In-Reply-To: <200905041139.n44BdFYA093271@aurora.sol.net> References: <200905041139.n44BdFYA093271@aurora.sol.net> Message-ID: <4A003801.8090606@ttec.com> Joe Greco wrote: >> Forwarding these requests up to the ISP's router and having several >> PDs per end customer is in my opinion the best way to go. > > How is it the ISP's router is able to handle this? Be specific. I view with suspicion the notion that an ISP is going to take addressing direction from their customers, willy-nilly. > > Now explain why that can't be made to work at the CPE level. Home devices chain with NAT because that is the scheme most likely to work well enough by default 99% of the time out of the box, without requiring ANY upstream cooperation. Home devices that work out of the box for the common usage scenarios generate profit, those that dont generate loss. Joe From jgreco at ns.sol.net Tue May 5 08:13:06 2009 From: jgreco at ns.sol.net (Joe Greco) Date: Tue, 5 May 2009 08:13:06 -0500 (CDT) Subject: Where to buy Internet IP addresses In-Reply-To: from "Ricky Beam" at May 05, 2009 02:18:14 AM Message-ID: <200905051313.n45DD6ar096138@aurora.sol.net> > On Tue, 05 May 2009 00:08:51 -0400, Joe Greco wrote: > > For today. But, remember, this sort of shortsightedness is what landed > > us in the current IPv4 pain. > > 48bit MACs have caused IPv4 address exhaustion? Wow. I didn't know that. No, thinking small is what landed us in the current IPv4 pain. > > ... justify not making a future-proofing change now, before IPv6 > > is widely deployed, and changes can be easily made? > > It's not very widely deployed now, and it's already too late to make > simple changes. ONE single, simple protocol change requires a lot of > people to do a lot of work. No, it's not too late to make simple changes. We're still figuring out lots of bits about it. > > For ethernet, today. > > IPv6 is a decade old and there still aren't many people using it. > Ethernet is 30 years old. Do you honestly think you'd be able to roll out > EthernetV2(tm) with 64bit MACs anytime in the next century? Ethernet is > far more fundamental than IPv4, grown into the silicon of almost > everything. Even though there are alternatives to ethernet (infiniband > anyone?) ethernet is still *everywhere*. Yes, I do think that something fundamental like that will happen at some point. On the other hand, can you *guarantee* that it will not? Because if you cannot *guarantee* that it will not, then that raises doubts as to the wisdom of your advice. And quite frankly, you've already conceded that a technology - firewire - exists that does use EUI-64. > > Correct. So it's trivial to do, and it future-proofs us to be able to > > support EUI-64. ... > > And the only reason we'd need to use EUI-64? Because some twits decided to > use a Layer 2 address in a Layer 3 address. Do you have an equally brilliant but completely different suggestion as to how to implement reliable stateless autoconfig in IPv6? But it's not the only reason we need to use EUI-64. We know that someday, even if it's many years out, we'll run out. And further, I believe that the rate of depletion will only increase, as the number of network-capable devices explodes. > Or have we exhausted EUI-48 > as well? No. Do we have to do that before we figure out what to do next? Are we too stupid to learn from the period of history we're going through right now? With IPv4, we've waited until we're just about out in order to figure out where to go from here. That was dumb. Predictable but dumb. Why wait for resource depletion in another realm, when we already know that's a bad thing to do? > > Most of the significant problems with IPv4 are due to people thinking > > small, and not having a vision towards the future. ... > > I'm thinking small? No. I'm being frugal and efficient -- > "conservative". Yes, that's thinking small, because IPv6 was *designed* to be liberal. Intentionally. By massive amounts, so that no credible claims could be mounted that there was any good reason for "being [excessively] frugal." > FORCING networks to be no smaller than /64 -- per the > fundamental requirement for SLAAC -- when there's absolutely no forseeable > need for 18billion billion hosts per network is wasteful beyond measure. RFC3041. That's a need. It works today. It's implemented on FreeBSD, Linux, and Microsoft stacks, among others. We just went through an educational process with the DNS protocol to learn why the ability to do this sort of thing is a completely credible "need", as well. So I'm sorry to say, but you're just wrong, that's a need, and it's there now. > I see this a fundamentally the same as handing out /8's 25 years ago -- > "because the protocol (classfulness) requires it." Just because *we* see > the IPv6 address space as unbelievablly huge *today*, doesn't mean we > should carve it up in recklessly huge chunks. That's exactly how IPv4 was > seen long ago, and we've been and will be living with that mistake for > decades. You don't think that the IPv6 designers thought long and hard on that very question? You're second-guessing them? I'm sure we'd all appreciate a presentation as to why 128 bits isn't enough. Really, if it's a problem, now is the time to decide to go to 256 bits and IPvX. These are huge numbers that we're talking about. At the time IPv4 was created, people were looking at 4 billion and refrigerator-sized routers and thinking, "this'll last us for a while." And it did. But I don't recall them assuming that IPv4 was the end of the road. With IPv6, we've made some very clear decisions about what we need to last us for a while. One of the most visionary things we've done is to set aside a huge space for local network addressing. This leaves us with a huge amount of space to work with in the future, if, for whatever reason, the current ideas don't pan out. > So, to sum up... we're being locked into using /64's as a minimum > allocation simply because a fundamental part of IPv6 (SLAAC) requires an > EUI-64 -- taking a layer-2 address and promoting it to a layer-3 address, > more or less because it's there and supposed to be globally unique (read: > we're lazy and don't want to figure out another way to be "stateless".) You're not being locked into it. Nobody's forcing you to use it. I'm sure that you can find someone willing to delegate you a single /64 for you to subnet along the lines of the traditional IPv4 ways. > This despite no current internet devices using EUI-64[*], and the > overwelming technology leader (ethernet) doesn't and very likely never > will (given the millions of tons of existing hardware in use.) > > ([*] according to the wiki, firewire and zigbee are the only things using > EUI-64. I don't know of anyone using firewire as a network backbone. They have to use it as a network backbone? Why, exactly? It has to be a technology that we are using today? We're not allowed to look at the way technology has developed and extrapolate that we might have many, many more uses, new technologies, and needs in the future? Hey, you know what, I'm just going to say this. Your thinking is definitely small-scale. There is nothing in IPv6 that prevents you from making a network work on the teeny scale. However, if we were to deploy your ideas IPv6-wide, then those of us who can think on the grand scale would find ourselves shortchanged for no good reason. Therefore, IPv6 deployment needs to continue in the way it was designed and envisioned, so that you are able to do your thing, and I am able to do mine. HTH, HAND, etc. I'm out of here. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples. From nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org Tue May 5 08:13:29 2009 From: nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org (Mark Smith) Date: Tue, 5 May 2009 22:43:29 +0930 Subject: Where to buy Internet IP addresses In-Reply-To: <1241492690.8158.7.camel@karl> References: <49FEF5C0.9050109@ttec.com> <200905041427.n44ERf0A003326@aurora.sol.net> <18a5e7cb0905041403q47b78c1cvaba1452c6e6e4f0@mail.gmail.com> <1241492690.8158.7.camel@karl> Message-ID: <20090505224329.ca62bf5d.nanog@85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org> On Tue, 05 May 2009 13:04:49 +1000 Karl Auer wrote: > On Tue, 2009-05-05 at 04:49 +0200, Randy Bush wrote: > > > I'm with you. I wish vendors and spec designers would just get over it > > > and let people subnet however they want. > > [...] > > do other than 64 and you do not get auto-conf. some do not consider > > this a loss, others do. > > This is an important distinction. > > - you CAN subnet however you like, with any number of bits in > your prefixes > > - autoconfiguration will work only in subnets with a 64 bit prefix. > > The two matters are quite independent of each other, as far as I can > tell. > Older protocols, like classful IPv4, Appletalk etc. put a hard boundary between the network and node portion. That was simple and, in the case of IPX, Appletalk and DECNET, it was very convenient to have fixed length network and node portions. IPv4 originally had a single boundary between the network and node portion - if you look up the early RFCs/IENs, the IPv4 addressing format was similar to Class A. Of course in the case of IPv4, those classful hard boundaries caused problems when we needed to squeeze more addresses out of the 32 bits by moving to a fully varying boundary between the network and node portions. IPv4 software in all nodes needed to be upgraded to work. I think of the way IPv6 has done it is the middle ground. For forwarding, the boundary between the network and node portions isn't hard - it's purely longest match on the whole 128 bits. However, because we've got so many bits, within a portion of the address space, a harder (but not hard) boundary exists, to benefit from the convenience of having fixed length node addresses, which results in things such as much simpler autoconfiguration etc. Regards, Mark. From mauritz at lho.co.za Tue May 5 09:29:43 2009 From: mauritz at lho.co.za (Mauritz Lewies) Date: Tue, 05 May 2009 16:29:43 +0200 Subject: Alcatel as Peering and MSE(PE) Message-ID: <1241533783.8170.5.camel@mauritzlewies> Hi I'm based in Africa and involved in SP/Telco consulting and deployments. We have a customer that has chosen Alcatel (political choice) as their Layer-3 core devices for P, MSE, BGP Route Servers and Peering/Transit devices. All based on the Alcatel 7750 chassis. Unfortunately Alcatel is not very widely used in Africa on layer-3 (But as transmission and Layer-2 kit they are widely deployed) and so we have very little experience with them at this layer. What is the general consensus of them in these layers of the network and can anyone point out some strong points/short falls? We've mostly worked on Juniper/Cisco and a little experience on Redback so I can not comment much on the Alcatel layer-3 kit and need some advise on the true technical abilities of the kit. (ie non vendor marketing or competitor shoot down information) Thanks, Mauritz Lewies From sliplever at gmail.com Tue May 5 10:22:35 2009 From: sliplever at gmail.com (Dan Snyder) Date: Tue, 5 May 2009 11:22:35 -0400 Subject: Alcatel as Peering and MSE(PE) In-Reply-To: <1241533783.8170.5.camel@mauritzlewies> References: <1241533783.8170.5.camel@mauritzlewies> Message-ID: <1c2d53bb0905050822m2a462553q4c12ad4d4703376e@mail.gmail.com> We have 42 Alcatel 7x50's deployed currently that are being used as P and PE devices on our network. We have been very happy with them. We are using them to offer both VPLS and VPRN service. If you have any specific questions about what we have seen let me know. Thanks, Dan On Tue, May 5, 2009 at 10:29 AM, Mauritz Lewies wrote: > Hi > > I'm based in Africa and involved in SP/Telco consulting and deployments. > > We have a customer that has chosen Alcatel (political choice) as their > Layer-3 core devices for P, MSE, BGP Route Servers and Peering/Transit > devices. > All based on the Alcatel 7750 chassis. > > Unfortunately Alcatel is not very widely used in Africa on layer-3 (But > as transmission and Layer-2 kit they are widely deployed) and so we have > very little experience with them at this layer. > > What is the general consensus of them in these layers of the network and > can anyone point out some strong points/short falls? > > We've mostly worked on Juniper/Cisco and a little experience on Redback > so I can not comment much on the Alcatel layer-3 kit and need some > advise on the true technical abilities of the kit. (ie non vendor > marketing or competitor shoot down information) > > Thanks, > > Mauritz Lewies > From charles at thewybles.com Tue May 5 12:28:25 2009 From: charles at thewybles.com (Charles Wyble) Date: Tue, 05 May 2009 10:28:25 -0700 Subject: Where to buy Internet IP addresses In-Reply-To: References: <200905050408.n4548pQO038066@aurora.sol.net> Message-ID: <4A007739.3010808@thewybles.com> > ([*] according to the wiki, firewire and zigbee are the only things > using EUI-64. I don't know of anyone using firewire as a network > backbone. (obviously, not that you care.) Zigbee is relatively new and > similar to bluetooth; will people use them as a NIC or connect little > zigbee gadgets to the internet -- well, there are coffee makers, vending > machines, and christmas lights on the internet, so as a novelty, > certainly. How many bluetooth devices are running IP over bluetooth? > That said, I could see PAN meshes (personal area networks) eating a huge > number of addresses, but /64???) Utility companies utilize Zigbee pretty extensively. So that's millions and millions of addresses right there. From jbates at brightok.net Tue May 5 12:29:10 2009 From: jbates at brightok.net (Jack Bates) Date: Tue, 05 May 2009 12:29:10 -0500 Subject: several messages In-Reply-To: References: Message-ID: <4A007766.8060509@brightok.net> Dean Anderson wrote: > Suresh: Did you know that Vixie, Levine, and Joffe were owners and > directors of Whitehat, a spam company that 'listwashes' spam-trap > addresses? If so, then you seem to have some discredit coming, too. > Did you mistake nanog for an anti-spam mailing list? If Vixie was the largest spammer on the planet, it wouldn't really effect network operations, unless his spam clogged up our bgp sessions or he started stealing IP blocks or something similarly boring. ;) Jack From nantoniello at antel.net.uy Tue May 5 12:32:55 2009 From: nantoniello at antel.net.uy (Nicolas Antoniello) Date: Tue, 05 May 2009 14:32:55 -0300 Subject: Alcatel as Peering and MSE(PE) In-Reply-To: <1c2d53bb0905050822m2a462553q4c12ad4d4703376e@mail.gmail.com> References: <1241533783.8170.5.camel@mauritzlewies> <1c2d53bb0905050822m2a462553q4c12ad4d4703376e@mail.gmail.com> Message-ID: <4A007847.4020100@antel.net.uy> They work quite well, specially in combination with Alcatel 5620SAM management software... we use it for managing most of the "aggregation" backbone (MPLS, VPLS, VPRN, etc...). Also use some of them as "border" routers to hold some STM-4 and STM-1 links. I recomend OS version 7. Mostly because of some bugs with version 4+. And specially because (If I'm not wrong), you need version 7+ to have 32 bit ASN support. Regards, N. Dan Snyder wrote: > We have 42 Alcatel 7x50's deployed currently that are being used as P and PE > devices on our network. We have been very happy with them. We are using > them to offer both VPLS and VPRN service. If you have any specific > questions about what we have seen let me know. > > Thanks, > Dan > > On Tue, May 5, 2009 at 10:29 AM, Mauritz Lewies wrote: > >> Hi >> >> I'm based in Africa and involved in SP/Telco consulting and deployments. >> >> We have a customer that has chosen Alcatel (political choice) as their >> Layer-3 core devices for P, MSE, BGP Route Servers and Peering/Transit >> devices. >> All based on the Alcatel 7750 chassis. >> >> Unfortunately Alcatel is not very widely used in Africa on layer-3 (But >> as transmission and Layer-2 kit they are widely deployed) and so we have >> very little experience with them at this layer. >> >> What is the general consensus of them in these layers of the network and >> can anyone point out some strong points/short falls? >> >> We've mostly worked on Juniper/Cisco and a little experience on Redback >> so I can not comment much on the Alcatel layer-3 kit and need some >> advise on the true technical abilities of the kit. (ie non vendor >> marketing or competitor shoot down information) >> >> Thanks, >> >> Mauritz Lewies >> From kris.foster at gmail.com Tue May 5 12:39:53 2009 From: kris.foster at gmail.com (kris foster) Date: Tue, 5 May 2009 10:39:53 -0700 Subject: Why is www.google.cat resolving? In-Reply-To: <49FFEA32.9080805@2mbit.com> References: <562916.65528.qm@web24606.mail.ird.yahoo.com> <49FFEA32.9080805@2mbit.com> Message-ID: <7F5D5A1E-6B0D-4F10-AE75-069B1677D1F0@gmail.com> Hi everyone This is a quick note to let you know that this thread has been moderated (trivially off topic). We will continue to assess follow ups in this thread for operational content, and forward relevant messages to the list. If you have any comments on this, please post them to the nanog- futures list. Kris MLC Chair On May 5, 2009, at 12:26 AM, Brielle Bruns wrote: > On 5/5/09 1:22 AM, Tim Tuppence wrote: >> Hello, >> >> I am seeing that www.google.cat resolves from three different >> networks. >> It even resolves from here: http://www.squish.net/dnscheck/ >> >> What is going on? >> >> Thanks, >> >> Tim >> >> >> >> > > A quick google and wikipedia check shows... > > http://en.wikipedia.org/wiki/.cat > > > .cat is a sponsored top-level domain intended to be used to > highlight the Catalan language and culture. Its policy has been > developed by ICANN and Fundaci? puntCAT. It was approved in > September 2005. > > :) > > -- > Brielle Bruns > The Summit Open Source Development Group > http://www.sosdg.org / http://www.ahbl.org > From martin at theicelandguy.com Tue May 5 13:18:42 2009 From: martin at theicelandguy.com (Martin Hannigan) Date: Tue, 5 May 2009 14:18:42 -0400 Subject: Minnesota to block online gambling sites? In-Reply-To: <9BCDA840-484F-40C7-94B7-3D0EE2962F89@delong.com> References: <49FF11EA.7030101@umn.edu> <20090504173523.50690.qmail@simone.iecc.com> <5b6f80200905041053m75d7689ct92b075ee7ba3a3da@mail.gmail.com> <9BCDA840-484F-40C7-94B7-3D0EE2962F89@delong.com> Message-ID: >From a strictly operational perspective: The only concern that I had with that request was with the v4 address blocking. That ought to be rethought in the grand scheme of things i.e. v4 exhaustion. There's a reasonable case to make regarding not tainting hosts or specific blocks in this manner. Creating "less usable" v4 resources as we approach exhaustion is not helpful, IMHO. Best Regards, Martin > 2009/5/4 John Levine : >> >>> Not withstanding the legality of such an order, how would one >>>> operationally enforce that order? >>>> >>> >>> The order has a list of IP addresses, so I expect the ISPs will just >>> block those IPs in routers somewhere. >>> >>> Since offshore online gambling is equally illegal everywhere in the >>> U.S., the ISPs have little reason to limit the block to Minnesota >>> customers, giving them a lot of latitude in where they implement the >>> block. >>> >> -- Martin Hannigan martin at theicelandguy.com p: +16178216079 Power, Network, and Costs Consulting for Iceland Datacenters and Occupants From stephen at sprunk.org Tue May 5 13:39:25 2009 From: stephen at sprunk.org (Stephen Sprunk) Date: Tue, 05 May 2009 13:39:25 -0500 Subject: Where to buy Internet IP addresses In-Reply-To: <4A007739.3010808@thewybles.com> References: <200905050408.n4548pQO038066@aurora.sol.net> <4A007739.3010808@thewybles.com> Message-ID: <4A0087DD.4030002@sprunk.org> Charles Wyble wrote: >> ([*] according to the wiki, firewire and zigbee are the only things >> using EUI-64. I don't know of anyone using firewire as a network >> backbone. (obviously, not that you care.) Zigbee is relatively new >> and similar to bluetooth; will people use them as a NIC or connect >> little zigbee gadgets to the internet -- well, there are coffee >> makers, vending machines, and christmas lights on the internet, so as >> a novelty, certainly. How many bluetooth devices are running IP over >> bluetooth? That said, I could see PAN meshes (personal area >> networks) eating a huge number of addresses, but /64???) > > Utility companies utilize Zigbee pretty extensively. So that's > millions and millions of addresses right there. A million addresses is 1/16th of one OUI in EUI-48, and there are 4,194,304 OUIs (after you take out the local/global and multicast/unicast bits). Billions or even trillions of addresses are manageable without needing EUI-64; millions is a drop in the bucket. Still, it's good to know that another link layer -- which people _will_ be running large IPv6 networks on -- is using EUI-64 and that it's not just a FireWire thing. S -- Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3241 bytes Desc: S/MIME Cryptographic Signature URL: From jgreco at ns.sol.net Tue May 5 13:45:56 2009 From: jgreco at ns.sol.net (Joe Greco) Date: Tue, 5 May 2009 13:45:56 -0500 (CDT) Subject: Where to buy Internet IP addresses In-Reply-To: <4A003801.8090606@ttec.com> from "Joe Maimon" at May 05, 2009 08:58:41 AM Message-ID: <200905051845.n45IjuFl011800@aurora.sol.net> > Joe Greco wrote: > >> Forwarding these requests up to the ISP's router and having several > >> PDs per end customer is in my opinion the best way to go. > > > > How is it the ISP's router is able to handle this? Be specific. > > I view with suspicion the notion that an ISP is going to take addressing > direction from their customers, willy-nilly. You snipped two of the three paragraphs I was responding to. The reply I made was not a response to the last sentence, which was all that you quoted, and so you may be confused about what I meant. I was talking the other direction. Internet routes a prefix to the ISP. ISP routes a (smaller) prefix to the access concentrator. Access concentrator routes a (smaller) prefix to the customer. Now, the question is, if you're sending all these prefix requests up to the ISP's router, why is *that* device able to cope with it, and why is the CPE device *not* able to cope with it? > > Now explain why that can't be made to work at the CPE level. > > Home devices chain with NAT because that is the scheme most likely to > work well enough by default 99% of the time out of the box, without > requiring ANY upstream cooperation. > > Home devices that work out of the box for the common usage scenarios > generate profit, those that dont generate loss. Again, since I think you misunderstood my earlier question, I don't think my opinion was different than that. Throwing out any real world implementations, for the sake of a clean slate to see what "makes sense," let's sketch. You have an ISP network, with a large amount of space available, and a lesser amount of space dedicated to the POP. You have a customer network, assumed to live within some customer delegation. So what we want is something that can intelligently handle delegation in an automatic fashion, which probably includes configurable settings to request/register delegations upstream, and to accept/manage them downstream. There's no reason that this shouldn't be basic router capabilities. ... 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 Tue May 5 14:11:23 2009 From: jbates at brightok.net (Jack Bates) Date: Tue, 05 May 2009 14:11:23 -0500 Subject: Where to buy Internet IP addresses In-Reply-To: <200905051845.n45IjuFl011800@aurora.sol.net> References: <200905051845.n45IjuFl011800@aurora.sol.net> Message-ID: <4A008F5B.5030009@brightok.net> Joe Greco wrote: > Now, the question is, if you're sending all these prefix requests up to > the ISP's router, why is *that* device able to cope with it, and why is > the CPE device *not* able to cope with it? > The CPE cannot cope with it due to lack of a chaining standard and the lack of customer understanding of configuring a router. An ISP, as currently designed will manually assign prefix lengths and how they are handed out at each layer of the network. A home user should not be expected to understand this level of complexity. A CPE would have to be told HOW to divide it's variably received prefix to assign it's own networks and then issue prefixes to other routers behind it. What is missing, unless I've missed a protocol (which is always possible), is an automated way for a CPE to assign it's networks, pass other networks out to downstream routers in an on-need basis. I say on-need, as there may be 3 routers directly behind the CPE and each of those may get additional routers and so on and so forth. A presumption could be made that route efficiency is not necessary at this level. ie, would it be practical or expected that an automatically configured network support > 100 routes or whatever a CPE can normally handle? Of course, if this support is built at a CPE level, there's no reason the protocol can't be extended and supported at the ISP level as well for those who wish to utilize it. An ISP, would of course prefer prefix aggregation and controls to set minimum and maximum aggregate space for a customer. > You have an ISP network, with a large amount of space available, and a > lesser amount of space dedicated to the POP. > This setup in the ISP network is handled by hopefully clueful engineers and probably not automatically assigned by some cool protocol that routers speak (which would be cool, though, even if impractical). > So what we want is something that can intelligently handle delegation > in an automatic fashion, which probably includes configurable settings > to request/register delegations upstream, and to accept/manage them > downstream. There's no reason that this shouldn't be basic router > capabilities. For the home router, I believe that this is mandatory if we wish to continue to allow self configuring networks for home users. A little extended logic and it can also be useful in larger networks, possibly even to the point of an enterprise network able to completely number itself (including renumbering itself as necessary). Jack From swmike at swm.pp.se Tue May 5 14:21:40 2009 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Tue, 5 May 2009 21:21:40 +0200 (CEST) Subject: Where to buy Internet IP addresses In-Reply-To: <4A008F5B.5030009@brightok.net> References: <200905051845.n45IjuFl011800@aurora.sol.net> <4A008F5B.5030009@brightok.net> Message-ID: On Tue, 5 May 2009, Jack Bates wrote: > What is missing, unless I've missed a protocol (which is always possible), is > an automated way for a CPE to assign it's networks, pass other networks out > to downstream routers in an on-need basis. I say on-need, as there may be 3 > routers directly behind the CPE and each of those may get additional routers > and so on and so forth. A presumption could be made that route efficiency is Why wouldn't DHCPv6-PD work within the home as well as between the ISP and the home? I see little reason why the main home gateway can't get a /56 from the ISP, and then hand out /62 (or whatever) to any routers within the home that asks for PD? -- Mikael Abrahamsson email: swmike at swm.pp.se From charles at thewybles.com Tue May 5 14:47:35 2009 From: charles at thewybles.com (Charles Wyble) Date: Tue, 05 May 2009 12:47:35 -0700 Subject: EVDO followup Message-ID: <4A0097D7.9020406@thewybles.com> So I found an article about updating the EVDO modem PRL in Linux (or I should say via a standard AT method) http://kenkinder.com/using-verizon-wireless-evdo-pc5740-and-linux/ I'll let folks know how it goes. From jbates at brightok.net Tue May 5 14:49:01 2009 From: jbates at brightok.net (Jack Bates) Date: Tue, 05 May 2009 14:49:01 -0500 Subject: Where to buy Internet IP addresses In-Reply-To: References: <200905051845.n45IjuFl011800@aurora.sol.net> <4A008F5B.5030009@brightok.net> Message-ID: <4A00982D.1060209@brightok.net> Mikael Abrahamsson wrote: > Why wouldn't DHCPv6-PD work within the home as well as between the ISP > and the home? > DHCPv6-PD requires manual configuration. > I see little reason why the main home gateway can't get a /56 from the > ISP, and then hand out /62 (or whatever) to any routers within the home > that asks for PD? > Sure, but how does the router know it needs to hand out a /62? Then what about the router after that? Does it hand out a /61? then the router behind that? What if the ISP only gave a /60? The problem with automatic arbitrary splitting of a prefix into smaller prefixes is that the entire topology is unknown. In such a case, bidirectional communication is useful, as is multiple prefix assignments to a single node generated from chaining DHCPv6-PD requests. PD is not designed for multiple stage delegations without manual configuration for each stage. Even the PD clients I tried on linux failed horribly in how they assigned a prefix to the interfaces. One of them just took the prefix length and divided it by the number of interfaces. Another, which I ended up using allowed you to set the bits to use as a subnet, but that meant you had to know the length from the ISP, and then the desired length on each of the interfaces to set the appropriate SLA (ie, I couldn't tell it I want a /64 on the interface, but instead had to tell it the SLA is 4 bits, which from a /60 would give a /64, but if I received a /56 it would break and have to be changed to 8 bits). -Jack From jfbeam at gmail.com Tue May 5 14:58:16 2009 From: jfbeam at gmail.com (Ricky Beam) Date: Tue, 05 May 2009 15:58:16 -0400 Subject: Where to buy Internet IP addresses In-Reply-To: <200905051313.n45DD6ar096138@aurora.sol.net> References: <200905051313.n45DD6ar096138@aurora.sol.net> Message-ID: On Tue, 05 May 2009 09:13:06 -0400, Joe Greco wrote: > No, it's not too late to make simple changes. We're still figuring out > lots of bits about it. Yes, it is too late. IPv6 as it stands is a huge pile of crap and bloat. We'd be better off straping the whole mess and starting over, but that ain't gonna happen. Over the next dozen decades and hundreds of RFCs, we might have something that looks like it was designed by competent people instead of glued together mess we have today that was created by committees with multiple personal and political agendas. > On the other hand, can you *guarantee* that it will not? Yes. Yes, I can. Ethernet has been around for decades from 10M to 100M to 1G to 10G and now we're working on 100G. Look around the room and count the number of devices containing ethernet technology. It's f'ing EVERY. WHERE. Every single piece will have to be replaced to support EUI-64. It's grown into the silicon, so there's no amount of software updates that can fix it like we're attempting to do with IPv4-to-IPv6. > And quite frankly, you've already conceded that > a technology - firewire - exists that does use EUI-64. True. But you ignore the fact that firewire isn't used as an internet transport technology. Where's the 24 or 48 port firewire switches? You can run IP over fibre channel, but I don't know of anyone who does so outside of private (read: internal) networks. (Clusters often use FC-IP within the SAN for node-to-node signaling.) Ethernet won. It uses 48bit addressing. It's not going to change. That "mistake" is now cast in diamond. The world is not going to throw away all the ethernet gear because someone wants to change the addressing scheme. > Do you have an equally brilliant but completely different suggestion as > to how to implement reliable stateless autoconfig in IPv6? Sure I do. And I'm not the only one. In fact, many IPv4 systems have an address generator... the thing that builds "local" 169 addresses. The simple fact is they took the dirty, brainless simple path of using what is supposed to be a unique identifier (Layer-2's MAC-48) and directly attching it to the layer-3 (IPv6) address. Everyone is confusing "stateless" with "constant" and "consistent". SLAAC doesn't need to generate the exact same address everytime the system is started. Stateless simply implies a host is not depending on data maintained from an external source. A host can generate whatever random number it needs. It doesn't have to be *globally* unique; it only need be *locally* unique. There are plenty of ways to generate and verify local uniqueness. > No. Do we have to do that before we figure out what to do next? Do we have to replace trillions of dollars in hardware because of a problem we don't have? > Are we too stupid to learn from the period of history we're going > through right now? With IPv4, we've waited until we're just about > out in order to figure out where to go from here. That was dumb. > Predictable but dumb. Why wait for resource depletion in another > realm, when we already know that's a bad thing to do? You must be new here. IPv6 was designed a long time ago. Long before we "ran out of addresses". Nobody has deployed it because nobody has deployed it. IPv4 works. We still have address space to hand out -- and will for several more years. IPv4 will *continue* to work long after IANA has no more blocks to assign. Bottom line... there's no pressing reason to make the jump, and a whole bunch of reasons to hold off. But you don't seem to care about any of that -- we should all continue driving our pintos with the exploding gas tank until your local shop has time to replace it. No. Thanks. > RFC3041. Ah, so you conceed there *are* ways to generate addresses that aren't the MAC address. Therefore, they don't have to be 64bits. However, it's easier to be unique with larger numbers. > You don't think that the IPv6 designers thought long and hard on that > very question? You're second-guessing them? I'm sure we'd all > appreciate a > presentation as to why 128 bits isn't enough. I'm not guessing at all. I know they didn't. And where the f*** have I ever said 128bit isn't enough. My whole issue is with forcing people into 0% utilization of their address space "because we have lots of address space" and "eventually we'll need that space." Yet, you seem to think we're justified in giving people billions upon billions upon billions of addresses because we might, someday, somehow, have millions of gadgets that need to be globally addressable. But that's completely different from the mess we have with IPv4... handing out /8's because we could, then throwing on the breaks and promoting (even demanding) "responsible use", all the way to today where everyone asks for more address space than they currently need because "we might need it later" but later never comes. 128bit addressing is uber-plenty and will last us a long time as long as we continue to practice "responsible use". > These are huge numbers that we're talking about. At the time IPv4 was > created, people were looking at 4 billion and refrigerator-sized routers > and thinking, "this'll last us for a while." And it did. But I don't > recall them assuming that IPv4 was the end of the road. And you don't see the repeat with IPv6? *sigh* I see it everywhere... the address space is *HUGE*. there's no way we'll ever use it all. "enough addresses to assign every grain of sand on the planet it's very own..." But yet, day one we slice the address space in half and place a "globally unique" (probablly) number in the lower half. And then propose slicing the uper half into chunks large enough to give every house 256 to 65,536 *individual* globally unique spaces. > You're not being locked into it. Nobody's forcing you to use it. I'm > sure that you can find someone willing to delegate you a single /64 for > you to subnet along the lines of the traditional IPv4 ways. Yes, we all are. We will all be given a minimum of a /64, while no one has a need for even a billionth of that space, and aren't likely to for the forseeable future. When they do, *then* give them the space they need. Ah, but "renumbering is a pain", you say. That's another of those IPv6 fundamentals... renumbering your network is supposed to be easy -- prefix delegation and autoconfig makes it all Magic(tm). From swmike at swm.pp.se Tue May 5 15:11:54 2009 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Tue, 5 May 2009 22:11:54 +0200 (CEST) Subject: Where to buy Internet IP addresses In-Reply-To: <4A00982D.1060209@brightok.net> References: <200905051845.n45IjuFl011800@aurora.sol.net> <4A008F5B.5030009@brightok.net> <4A00982D.1060209@brightok.net> Message-ID: On Tue, 5 May 2009, Jack Bates wrote: > DHCPv6-PD requires manual configuration. Are you sure? Isn't it just that the current implementations do? > Sure, but how does the router know it needs to hand out a /62? Then what > about the router after that? Does it hand out a /61? then the router behind > that? > > What if the ISP only gave a /60? Guess someone needs to write a draft with BCP regarding this, or perhaps extend the protocol to include that the requestor can ask for a preferred size (or do multiple /64 PDs). > PD is not designed for multiple stage delegations without manual > configuration for each stage. I see no problem with sane defaults solving that problem. Now, if every ISP now adhered to handing out at least a /56 to each home, sane defaults could be created. If each ISP does it its own way, sane defaults won't work. So just hand out a /56 or /48 and be done with it. Your idea of chained /64 doesn't really solve anything that couldn't be solved with a /64 default PD handout in the home gateway as far as I can see it? -- Mikael Abrahamsson email: swmike at swm.pp.se From jbates at brightok.net Tue May 5 15:13:05 2009 From: jbates at brightok.net (Jack Bates) Date: Tue, 05 May 2009 15:13:05 -0500 Subject: Where to buy Internet IP addresses In-Reply-To: References: <200905051313.n45DD6ar096138@aurora.sol.net> Message-ID: <4A009DD1.4060604@brightok.net> Ricky Beam wrote: > Yes, we all are. We will all be given a minimum of a /64, while no one > has a need for even a billionth of that space, and aren't likely to for > the forseeable future. When they do, *then* give them the space they > need. Ah, but "renumbering is a pain", you say. That's another of > those IPv6 fundamentals... renumbering your network is supposed to be > easy -- prefix delegation and autoconfig makes it all Magic(tm). Actually, they probably would have stuck to a 64 bit address space and it was debated. Then it came down to, let's make it a 64 bit network space, and give another 64 bits for hosts (96 bits probably would have worked, but someone apparently feels the next bump from 64bit is 128bit so there we go). Renumbering, when the system works is a breeze. Of course there are a billion places where autoconfiguration doesn't work well, and those will still require effort to renumber. At least with this method, if Cisco supports DHCPv6 IA_TA option and proxy-nd similar to how they support IPv4, then a single pool will handle an entire pop no matter what. I'm sure 32bit host addressing would have been fine too, but then we're stuck with that 96bit value that no one likes. Jack From David_Hankins at isc.org Tue May 5 15:20:03 2009 From: David_Hankins at isc.org (David W. Hankins) Date: Tue, 5 May 2009 13:20:03 -0700 Subject: DHCPv6 PD In-Reply-To: <4A00982D.1060209@brightok.net> References: <200905051845.n45IjuFl011800@aurora.sol.net> <4A008F5B.5030009@brightok.net> <4A00982D.1060209@brightok.net> Message-ID: <20090505202002.GD3245@isc.org> On Tue, May 05, 2009 at 02:49:01PM -0500, Jack Bates wrote: > Sure, but how does the router know it needs to hand out a /62? Then what > about the router after that? Does it hand out a /61? then the router behind > that? In IA_NA's, there is a (undocumented in RFC 3315) convention to permit a client to supply an IAADDR with a zeroed address. This convention allows the client to supply preferred and valid lifetime hints without knowing a specific address it would like. I see no reason why a similar convention can't take root here; the bottom-most client supplies an IAPREFIX in its IA_PD with a zeroed network number, and the desired prefix length (suppose: /64 for its one downstream interface). The next hop combines the sum total of bitspaces required by its clients and presents a suitable requested size upstream (with memory, and resizing/renumbering as you go). > What if the ISP only gave a /60? Then someone gets a STATUS_NoAddrsAvail. -- David W. Hankins "If you don't do it right the first time, Software Engineer you'll just have to do it again." Internet Systems Consortium, Inc. -- Jack T. Hankins -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From paul at telcodata.us Tue May 5 15:22:04 2009 From: paul at telcodata.us (Paul Timmins) Date: Tue, 05 May 2009 16:22:04 -0400 Subject: Where to buy Internet IP addresses In-Reply-To: <4A008F5B.5030009@brightok.net> References: <200905051845.n45IjuFl011800@aurora.sol.net> <4A008F5B.5030009@brightok.net> Message-ID: <4A009FEC.7080004@telcodata.us> Sorry for the top post, but as a crazy thought here, why not throw out an RA, and if answered, go into transparent bridge mode? Let the sophisticated users who want routed behavior override it manually. Jack Bates wrote: > Joe Greco wrote: >> Now, the question is, if you're sending all these prefix requests up to >> the ISP's router, why is *that* device able to cope with it, and why is >> the CPE device *not* able to cope with it? >> > The CPE cannot cope with it due to lack of a chaining standard and the > lack of customer understanding of configuring a router. An ISP, as > currently designed will manually assign prefix lengths and how they > are handed out at each layer of the network. A home user should not be > expected to understand this level of complexity. A CPE would have to > be told HOW to divide it's variably received prefix to assign it's own > networks and then issue prefixes to other routers behind it. > > What is missing, unless I've missed a protocol (which is always > possible), is an automated way for a CPE to assign it's networks, pass > other networks out to downstream routers in an on-need basis. I say > on-need, as there may be 3 routers directly behind the CPE and each of > those may get additional routers and so on and so forth. A presumption > could be made that route efficiency is not necessary at this level. > ie, would it be practical or expected that an automatically configured > network support > 100 routes or whatever a CPE can normally handle? > > Of course, if this support is built at a CPE level, there's no reason > the protocol can't be extended and supported at the ISP level as well > for those who wish to utilize it. An ISP, would of course prefer > prefix aggregation and controls to set minimum and maximum aggregate > space for a customer. > >> You have an ISP network, with a large amount of space available, and a >> lesser amount of space dedicated to the POP. >> > > This setup in the ISP network is handled by hopefully clueful > engineers and probably not automatically assigned by some cool > protocol that routers speak (which would be cool, though, even if > impractical). > >> So what we want is something that can intelligently handle delegation >> in an automatic fashion, which probably includes configurable settings >> to request/register delegations upstream, and to accept/manage them >> downstream. There's no reason that this shouldn't be basic router >> capabilities. > > For the home router, I believe that this is mandatory if we wish to > continue to allow self configuring networks for home users. A little > extended logic and it can also be useful in larger networks, possibly > even to the point of an enterprise network able to completely number > itself (including renumbering itself as necessary). > > > Jack > From jfbeam at gmail.com Tue May 5 15:23:17 2009 From: jfbeam at gmail.com (Ricky Beam) Date: Tue, 05 May 2009 16:23:17 -0400 Subject: Where to buy Internet IP addresses In-Reply-To: <4A007739.3010808@thewybles.com> References: <200905050408.n4548pQO038066@aurora.sol.net> <4A007739.3010808@thewybles.com> Message-ID: On Tue, 05 May 2009 13:28:25 -0400, Charles Wyble wrote: > Utility companies utilize Zigbee pretty extensively. So that's millions > and millions of addresses right there. But does the entire planet need to talk to those critters? No. Nor should they even be able to. Those little gadgets can very happily live within a link-local only network, or isolated private network. I know the subject of "nat" in IPv6 will have people chasing me with pitchforks, but there are a lot of things in the world that don't need to be accessable by the entire world and should be (must be) protected from even accidentally being exposed to the Evil Internet(tm). Everyone will chime in with "firewall them", but the risk exists as long as they have global addresses. Having to break into a machine in order to get at the internal network (ala today's NAT) makes the network much safer -- not "safe", but safer than directly naked on the internet. (If you want to do numbers... the utility company could hang 2billion zigbee's on every human on Earth and still not fill *one* /64. [global pop ~ 6.77 billion]) From charles at thewybles.com Tue May 5 15:35:21 2009 From: charles at thewybles.com (Charles Wyble) Date: Tue, 05 May 2009 13:35:21 -0700 Subject: Where to buy Internet IP addresses In-Reply-To: References: <200905050408.n4548pQO038066@aurora.sol.net> <4A007739.3010808@thewybles.com> Message-ID: <4A00A309.3060300@thewybles.com> Ricky Beam wrote: > On Tue, 05 May 2009 13:28:25 -0400, Charles Wyble > wrote: >> Utility companies utilize Zigbee pretty extensively. So that's >> millions and millions of addresses right there. > > But does the entire planet need to talk to those critters? No. Nor > should they even be able to. Really.... we don't have enough debates going on in this thread? > > Those little gadgets can very happily live within a link-local only > network, or isolated private network. Exactly. Behind the utilities (closely monitored and highly restrictive) firewall. Most likely behind multiple firewalls. (border fw, internal operations fw, monitoring network firewall). No reason they shouldn't have a fully routeable address. > > I know the subject of "nat" in IPv6 will have people chasing me with > pitchforks, but there are a lot of things in the world that don't need > to be accessable by the entire world and should be (must be) protected > from even accidentally being exposed to the Evil Internet(tm). Everyone > will chime in with "firewall them", but the risk exists as long as they > have global addresses. Having to break into a machine in order to get > at the internal network (ala today's NAT) makes the network much safer > -- not "safe", but safer than directly naked on the internet. This is no different then having machines with a public IP on the net today. A firewall is such a small part of an overall security architecture. Don't troll. From David_Hankins at isc.org Tue May 5 15:38:17 2009 From: David_Hankins at isc.org (David W. Hankins) Date: Tue, 5 May 2009 13:38:17 -0700 Subject: DHCPv6 PD chains vs bridging In-Reply-To: <4A009FEC.7080004@telcodata.us> References: <200905051845.n45IjuFl011800@aurora.sol.net> <4A008F5B.5030009@brightok.net> <4A009FEC.7080004@telcodata.us> Message-ID: <20090505203817.GE3245@isc.org> On Tue, May 05, 2009 at 04:22:04PM -0400, Paul Timmins wrote: > Sorry for the top post, but as a crazy thought here, why not throw out an > RA, and if answered, go into transparent bridge mode? Let the sophisticated > users who want routed behavior override it manually. Customer premise gear has a 'front side' and a 'back side', and it is already well ingrained behaviour for 'back-to-back port chaining' to create a single large bridged network in the home. What is the customer's anticipated result from front-to-back chaining? That seems much more reliable a hint to me than conditional behaviour. DHCPv6 PD is applicable to the ISP customer premise. DHCPv6 PD 'chaining' however is probably only applicable in some promised future where there are alternative home network medias to Ethernet, or to the Enterprise where the boundaries drawn in broadcast domains are administrative in nature and not technical (but still, all automated). -- David W. Hankins "If you don't do it right the first time, Software Engineer you'll just have to do it again." Internet Systems Consortium, Inc. -- Jack T. Hankins -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From jgreco at ns.sol.net Tue May 5 15:38:43 2009 From: jgreco at ns.sol.net (Joe Greco) Date: Tue, 5 May 2009 15:38:43 -0500 (CDT) Subject: Where to buy Internet IP addresses In-Reply-To: <4A008F5B.5030009@brightok.net> from "Jack Bates" at May 05, 2009 02:11:23 PM Message-ID: <200905052038.n45Kciqp017160@aurora.sol.net> > Joe Greco wrote: > > Now, the question is, if you're sending all these prefix requests up to > > the ISP's router, why is *that* device able to cope with it, and why is > > the CPE device *not* able to cope with it? > > The CPE cannot cope with it due to lack of a chaining standard and the > lack of customer understanding of configuring a router. An ISP, as > currently designed will manually assign prefix lengths and how they are > handed out at each layer of the network. A home user should not be > expected to understand this level of complexity. A CPE would have to be > told HOW to divide it's variably received prefix to assign it's own > networks and then issue prefixes to other routers behind it. That doesn't seem like a problem from the set of unsolvable problems. We have current protocols that do substantially more complicated things in a standard and interoperable way. Your average current everyday IPv4 CPE has a DHCP server on it, for example, which very roughly approximates the complexity of the issue. > What is missing, unless I've missed a protocol (which is always > possible), is an automated way for a CPE to assign it's networks, pass > other networks out to downstream routers in an on-need basis. I say > on-need, as there may be 3 routers directly behind the CPE and each of > those may get additional routers and so on and so forth. A presumption > could be made that route efficiency is not necessary at this level. ie, > would it be practical or expected that an automatically configured > network support > 100 routes or whatever a CPE can normally handle? Actually, my own belief is that this /would/ be practical, and it might even be made to work efficiently. A "home router" maintains a list of space that it has been delegated, and a list of actually-used space (assigned to directly connected interfaces, along with any routed blocks). Upon receipt of a delegation request, the router starts an algorithm to see what it can do. Because it has been allocating out of a /56, the "primary" /64 was delegated at offset 0. Two requests from secondary routers came in, one was offered a /64 at offset 128, one at offset 192. That ought to make reasonable sense. The first "secondary" router learns that it has a bunch of downstream routers, and in the worst case asks for a delegation one at a time for each. The primary router assigns the subnet at offset 129, updates its route to the larger netmask, and away it goes. There's actually no increase in the number of forwarding entries, and this can be done a number of times. Further, if the primary router decides that it is allocating a lot of space to a secondary router, it can assign a larger hunk of space, saving some setup time, or it can try to optimize for bit boundaries. Not all cases will be this optimal. However, it seems reasonable to try. > Of course, if this support is built at a CPE level, there's no reason > the protocol can't be extended and supported at the ISP level as well > for those who wish to utilize it. An ISP, would of course prefer prefix > aggregation and controls to set minimum and maximum aggregate space for > a customer. Exactly. > > You have an ISP network, with a large amount of space available, and a > > lesser amount of space dedicated to the POP. > > This setup in the ISP network is handled by hopefully clueful engineers > and probably not automatically assigned by some cool protocol that > routers speak (which would be cool, though, even if impractical). Yes, but I'm really just talking about the idea of doing meaningful aggregation and simplification. > > So what we want is something that can intelligently handle delegation > > in an automatic fashion, which probably includes configurable settings > > to request/register delegations upstream, and to accept/manage them > > downstream. There's no reason that this shouldn't be basic router > > capabilities. > > For the home router, I believe that this is mandatory if we wish to > continue to allow self configuring networks for home users. Oh, yeah, let me say: I am assuming that it *is* mandatory that we come to a solution of some sort. It may not need to be day 1, but it ought to be. > A little > extended logic and it can also be useful in larger networks, possibly > even to the point of an enterprise network able to completely number > itself (including renumbering itself as necessary). A little pie in the sky, but I *want* to see that as an option. Not to trivialize Real Network Engineers(tm), but not everything has to be super complicated. I would like to see IPv6 reach a point where a mildly clueful person could plug in a "workgroup switch" into a managed corporate network, maybe even a few of them daisy-chained, and run a little web setup GUI that allows some basic network setup in fairly abstract terms, such as setting up a "protected" printer network that was only accessible to certain parties. ... 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 stephen at sprunk.org Tue May 5 15:43:20 2009 From: stephen at sprunk.org (Stephen Sprunk) Date: Tue, 05 May 2009 15:43:20 -0500 Subject: Where to buy Internet IP addresses In-Reply-To: <4A00982D.1060209@brightok.net> References: <200905051845.n45IjuFl011800@aurora.sol.net> <4A008F5B.5030009@brightok.net> <4A00982D.1060209@brightok.net> Message-ID: <4A00A4E8.2040802@sprunk.org> Jack Bates wrote: > Mikael Abrahamsson wrote: >> Why wouldn't DHCPv6-PD work within the home as well as between the >> ISP and the home? > DHCPv6-PD requires manual configuration. It doesn't need to; that's just a flaw in current implementations. >> I see little reason why the main home gateway can't get a /56 from >> the ISP, and then hand out /62 (or whatever) to any routers within >> the home that asks for PD? > > Sure, but how does the router know it needs to hand out a /62? Then > what about the router after that? Does it hand out a /61? then the > router behind that? > > What if the ISP only gave a /60? I think some folks are getting the model wrong. Each router requests from its upstream router the delegation of a /64 for each downstream link and inserts the appropriate route when a response arrives. If it receives a PD request on its downstream interface, it forwards it upstream; when the reply comes back, it inserts the appropriate route and forwards the reply to the requester. Presto, a non-geek user can chain as many CPE devices as desired and they automagically configure themselves. (The ISP who's serving all these requests _could_ preallocate a /48 or /56 per customer, which might make aggregation in the PE router easier, or they could just have a gigantic pool per PE router and hand out as many /64s as required to each customer, which would [unnecessarily, IMHO] conserve address space.) However, as interesting as this may be, it's not particularly useful to discuss how consumer ISPs _might_ do DHCPv6 PD when none of them have shown much interest in providing any IPv6 connectivity at all and many are blocking (through mandatory NAT) even 6to4. And, until the eyeballs can speak IPv6, the content isn't going to speak it either... S -- Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3241 bytes Desc: S/MIME Cryptographic Signature URL: From Alain_Durand at cable.comcast.com Tue May 5 15:44:59 2009 From: Alain_Durand at cable.comcast.com (Durand, Alain) Date: Tue, 05 May 2009 16:44:59 -0400 Subject: DHCPv6 PD chains vs bridging In-Reply-To: <20090505203817.GE3245@isc.org> Message-ID: On 5/5/09 4:38 PM, "David W. Hankins" wrote: > On Tue, May 05, 2009 at 04:22:04PM -0400, Paul Timmins wrote: >> Sorry for the top post, but as a crazy thought here, why not throw out an >> RA, and if answered, go into transparent bridge mode? Let the sophisticated >> users who want routed behavior override it manually. > > Customer premise gear has a 'front side' and a 'back side', and it is > already well ingrained behaviour for 'back-to-back port chaining' to > create a single large bridged network in the home. What is the > customer's anticipated result from front-to-back chaining? What you really want to avoid is to have customer A's home network accidentally bridged to customer B's. L3 isolation of L2 domains helps. - Alain. From jfbeam at gmail.com Tue May 5 15:53:16 2009 From: jfbeam at gmail.com (Ricky Beam) Date: Tue, 05 May 2009 16:53:16 -0400 Subject: Where to buy Internet IP addresses In-Reply-To: <4A009DD1.4060604@brightok.net> References: <200905051313.n45DD6ar096138@aurora.sol.net> <4A009DD1.4060604@brightok.net> Message-ID: On Tue, 05 May 2009 16:13:05 -0400, Jack Bates wrote: > Actually, they probably would have stuck to a 64 bit address space and > it was debated. Then it came down to, let's make it a 64 bit network > space, and give another 64 bits for hosts (96 bits probably would have > worked, but someone apparently feels the next bump from 64bit is 128bit > so there we go). Ah, but they half-assed the solution. IPv6 makes no distinction between network and host (eg. "classless"), yet SLAAC forces this oddball, classful boundry. Routing doesn't care. Even the hosts don't care. Only the tiny craplet of autoconfig demands the network and host each be 64bits. That's brilliant! From charles at thewybles.com Tue May 5 15:57:38 2009 From: charles at thewybles.com (Charles Wyble) Date: Tue, 05 May 2009 13:57:38 -0700 Subject: DHCPv6 PD chains vs bridging In-Reply-To: <20090505203817.GE3245@isc.org> References: <200905051845.n45IjuFl011800@aurora.sol.net> <4A008F5B.5030009@brightok.net> <4A009FEC.7080004@telcodata.us> <20090505203817.GE3245@isc.org> Message-ID: <4A00A842.7000007@thewybles.com> David W. Hankins wrote: > On Tue, May 05, 2009 at 04:22:04PM -0400, Paul Timmins wrote: >> Sorry for the top post, but as a crazy thought here, why not throw out an >> RA, and if answered, go into transparent bridge mode? Let the sophisticated >> users who want routed behavior override it manually. > > Customer premise gear has a 'front side' and a 'back side', I presume by front you mean wan and back you mean lan? and it is > already well ingrained behaviour for 'back-to-back port chaining' to > create a single large bridged network in the home. Really? What CPE? My topology at home is motorolla dsl modem[1]->cisco 1841->catalyst 2924->wireless router->clients The connection between the modem and router is a routed connection. The default configuration of the Linksys kit I have seen is routed. I had to change it to operate as a bridge (a one click option in the gui), and turn off the local DHCP server to make a flat wired/wireless network. Otherwise it insists on being a router. [1] (It would appear that SBC recently changed their network to only allow their CPE with it's very limited configuration options. It's routed. Public IP on the WAN and a fixed private IP (192.168.1.254). It hands out 1 private DHCP address (192.168.1.64) What is the > customer's anticipated result from front-to-back chaining? I'm not sure how many people do this. Many people have one integrated device hanging off their DSL modem. They then purchase wireless extenders to increase the reach. This is what I overhear being recommend by Frys and BestBuy sales folks, and it seems to work well. I don't know how many will do it in the future. I imagine that vendors will just make beefer wireless routers to handle increased load. They already have different models and software feature sets for "high end gamers". From trejrco at gmail.com Tue May 5 16:02:19 2009 From: trejrco at gmail.com (trejrco at gmail.com) Date: Tue, 5 May 2009 21:02:19 +0000 Subject: Where to buy Internet IP addresses In-Reply-To: References: <200905051313.n45DD6ar096138@aurora.sol.net> Message-ID: <2124016175-1241557358-cardhu_decombobulator_blackberry.rim.net-892738330-@bxe1295.bisx.prod.on.blackberry> I would venture a guess that there are atleast two divergent opinions here that will "never" be reconciled. I propose you agree to disagree and move forward ... or take the argument back in time about 15 years, when these issues were being debated and solutions (great, good, mediocre, bad - efficient, wasteful - constraining, freeing ... whatever) were decided upon. /TJ ... Also thinking the level of vitriol is a bit counter-productive, but this is the Internet ... Sent from my Verizon Wireless BlackBerry -----Original Message----- From: "Ricky Beam" Date: Tue, 05 May 2009 15:58:16 To: Joe Greco Cc: nanog list Subject: Re: Where to buy Internet IP addresses On Tue, 05 May 2009 09:13:06 -0400, Joe Greco wrote: > No, it's not too late to make simple changes. We're still figuring out > lots of bits about it. Yes, it is too late. IPv6 as it stands is a huge pile of crap and bloat. We'd be better off straping the whole mess and starting over, but that ain't gonna happen. Over the next dozen decades and hundreds of RFCs, we might have something that looks like it was designed by competent people instead of glued together mess we have today that was created by committees with multiple personal and political agendas. > On the other hand, can you *guarantee* that it will not? Yes. Yes, I can. Ethernet has been around for decades from 10M to 100M to 1G to 10G and now we're working on 100G. Look around the room and count the number of devices containing ethernet technology. It's f'ing EVERY. WHERE. Every single piece will have to be replaced to support EUI-64. It's grown into the silicon, so there's no amount of software updates that can fix it like we're attempting to do with IPv4-to-IPv6. > And quite frankly, you've already conceded that > a technology - firewire - exists that does use EUI-64. True. But you ignore the fact that firewire isn't used as an internet transport technology. Where's the 24 or 48 port firewire switches? You can run IP over fibre channel, but I don't know of anyone who does so outside of private (read: internal) networks. (Clusters often use FC-IP within the SAN for node-to-node signaling.) Ethernet won. It uses 48bit addressing. It's not going to change. That "mistake" is now cast in diamond. The world is not going to throw away all the ethernet gear because someone wants to change the addressing scheme. > Do you have an equally brilliant but completely different suggestion as > to how to implement reliable stateless autoconfig in IPv6? Sure I do. And I'm not the only one. In fact, many IPv4 systems have an address generator... the thing that builds "local" 169 addresses. The simple fact is they took the dirty, brainless simple path of using what is supposed to be a unique identifier (Layer-2's MAC-48) and directly attching it to the layer-3 (IPv6) address. Everyone is confusing "stateless" with "constant" and "consistent". SLAAC doesn't need to generate the exact same address everytime the system is started. Stateless simply implies a host is not depending on data maintained from an external source. A host can generate whatever random number it needs. It doesn't have to be *globally* unique; it only need be *locally* unique. There are plenty of ways to generate and verify local uniqueness. > No. Do we have to do that before we figure out what to do next? Do we have to replace trillions of dollars in hardware because of a problem we don't have? > Are we too stupid to learn from the period of history we're going > through right now? With IPv4, we've waited until we're just about > out in order to figure out where to go from here. That was dumb. > Predictable but dumb. Why wait for resource depletion in another > realm, when we already know that's a bad thing to do? You must be new here. IPv6 was designed a long time ago. Long before we "ran out of addresses". Nobody has deployed it because nobody has deployed it. IPv4 works. We still have address space to hand out -- and will for several more years. IPv4 will *continue* to work long after IANA has no more blocks to assign. Bottom line... there's no pressing reason to make the jump, and a whole bunch of reasons to hold off. But you don't seem to care about any of that -- we should all continue driving our pintos with the exploding gas tank until your local shop has time to replace it. No. Thanks. > RFC3041. Ah, so you conceed there *are* ways to generate addresses that aren't the MAC address. Therefore, they don't have to be 64bits. However, it's easier to be unique with larger numbers. > You don't think that the IPv6 designers thought long and hard on that > very question? You're second-guessing them? I'm sure we'd all > appreciate a > presentation as to why 128 bits isn't enough. I'm not guessing at all. I know they didn't. And where the f*** have I ever said 128bit isn't enough. My whole issue is with forcing people into 0% utilization of their address space "because we have lots of address space" and "eventually we'll need that space." Yet, you seem to think we're justified in giving people billions upon billions upon billions of addresses because we might, someday, somehow, have millions of gadgets that need to be globally addressable. But that's completely different from the mess we have with IPv4... handing out /8's because we could, then throwing on the breaks and promoting (even demanding) "responsible use", all the way to today where everyone asks for more address space than they currently need because "we might need it later" but later never comes. 128bit addressing is uber-plenty and will last us a long time as long as we continue to practice "responsible use". > These are huge numbers that we're talking about. At the time IPv4 was > created, people were looking at 4 billion and refrigerator-sized routers > and thinking, "this'll last us for a while." And it did. But I don't > recall them assuming that IPv4 was the end of the road. And you don't see the repeat with IPv6? *sigh* I see it everywhere... the address space is *HUGE*. there's no way we'll ever use it all. "enough addresses to assign every grain of sand on the planet it's very own..." But yet, day one we slice the address space in half and place a "globally unique" (probablly) number in the lower half. And then propose slicing the uper half into chunks large enough to give every house 256 to 65,536 *individual* globally unique spaces. > You're not being locked into it. Nobody's forcing you to use it. I'm > sure that you can find someone willing to delegate you a single /64 for > you to subnet along the lines of the traditional IPv4 ways. Yes, we all are. We will all be given a minimum of a /64, while no one has a need for even a billionth of that space, and aren't likely to for the forseeable future. When they do, *then* give them the space they need. Ah, but "renumbering is a pain", you say. That's another of those IPv6 fundamentals... renumbering your network is supposed to be easy -- prefix delegation and autoconfig makes it all Magic(tm). From bzs at world.std.com Tue May 5 16:17:38 2009 From: bzs at world.std.com (Barry Shein) Date: Tue, 5 May 2009 17:17:38 -0400 Subject: Where to buy Internet IP addresses In-Reply-To: <006a01c9cd21$b6a41030$23ec3090$@com> References: <200905012340.n41NeNKD093855@drugs.dv.isc.org> <49FB9A86.1080101@rollernet.us> <49FBA5DA.2020707@bogus.com> <6eb799ab0905022120o5be64c56ye664a8d00bd4eb91@mail.gmail.com> <8D4934F9-A041-4400-89E5-A2C566231F6A@ian.co.uk> <49FF7F92.3030503@west.net> <006a01c9cd21$b6a41030$23ec3090$@com> Message-ID: <18944.44274.294199.870154@world.std.com> The potential problem is segmentation. Start assigning meanings to chunks of bits, like routing info or even customer type (mobile, static, etc) or geography, and the bits can get used up pretty quickly. Or put another way the address space becomes sparsely populated but inflexible. I know, "don't do that", well, when they give you (for any "you") that job be sure to send us a postcard... Any resource which is cheap (free!) and seemingly plentiful will get "abused", used in a way the engineers never intended (one word: spam!) Hey, anyone want to buy an ipv6 prefix which spells out their last name or company name when interpreted as UTF-8?! Q00l! :-) -- -Barry Shein The World | bzs at TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: 800-THE-WRLD | Login: Nationwide Software Tool & Die | Public Access Internet | SINCE 1989 *oo* From trejrco at gmail.com Tue May 5 16:19:58 2009 From: trejrco at gmail.com (trejrco at gmail.com) Date: Tue, 5 May 2009 21:19:58 +0000 Subject: Where to buy Internet IP addresses Message-ID: <1040222487-1241558539-cardhu_decombobulator_blackberry.rim.net-1647856809-@bxe1295.bisx.prod.on.blackberry> Jumping in against my better judgment ... The /64 boundary was for a number of reasons, the fact that "only" autoconfig breaks when that isn't the case is irrelevant (and not entirely true, but many of the breakages are minor/not intractable). Complaining about it now doesn't help, and many other decisions have since been made that rely on /64s. So, half-assed or not - this is the protocol we have, and it works today ... So what is the operational debate? /TJ ------Original Message------ From: Ricky Beam To: Jack Bates Cc: nanog list Subject: Re: Where to buy Internet IP addresses Sent: May 5, 2009 16:53 On Tue, 05 May 2009 16:13:05 -0400, Jack Bates wrote: > Actually, they probably would have stuck to a 64 bit address space and > it was debated. Then it came down to, let's make it a 64 bit network > space, and give another 64 bits for hosts (96 bits probably would have > worked, but someone apparently feels the next bump from 64bit is 128bit > so there we go). Ah, but they half-assed the solution. IPv6 makes no distinction between network and host (eg. "classless"), yet SLAAC forces this oddball, classful boundry. Routing doesn't care. Even the hosts don't care. Only the tiny craplet of autoconfig demands the network and host each be 64bits. That's brilliant! Sent from my Verizon Wireless BlackBerry From jbates at brightok.net Tue May 5 16:58:07 2009 From: jbates at brightok.net (Jack Bates) Date: Tue, 05 May 2009 16:58:07 -0500 Subject: Where to buy Internet IP addresses In-Reply-To: References: <200905051313.n45DD6ar096138@aurora.sol.net> <4A009DD1.4060604@brightok.net> Message-ID: <4A00B66F.8020904@brightok.net> Ricky Beam wrote: > Ah, but they half-assed the solution. IPv6 makes no distinction between > network and host (eg. "classless"), yet SLAAC forces this oddball, > classful boundry. Routing doesn't care. Even the hosts don't care. > Only the tiny craplet of autoconfig demands the network and host each be > 64bits. That's brilliant! So ask the IETF to drop it to generic 32bits. I presume they can draw up mathematical formulas to show that 32 bits can autogen and avoid a conflict with the maximum number of IPs likely to be found on a segment without having to do excessive DAD requests. Of course, they'll have to obsolete the 64 bit model and I suspect the vendors will complain about it. Jack From deleskie at gmail.com Tue May 5 18:24:25 2009 From: deleskie at gmail.com (jim deleskie) Date: Tue, 5 May 2009 20:24:25 -0300 Subject: Minnesota to block online gambling sites? In-Reply-To: References: <49FF11EA.7030101@umn.edu> <20090504173523.50690.qmail@simone.iecc.com> <5b6f80200905041053m75d7689ct92b075ee7ba3a3da@mail.gmail.com> <9BCDA840-484F-40C7-94B7-3D0EE2962F89@delong.com> Message-ID: Not only do we create "less usable" v4 address space, if these guys had a clue, and what ever you think of them with $$ envolved clue will be found... they will just add more IP's from diffrent block, further 'wasting' IP space. -jim On Tue, May 5, 2009 at 3:18 PM, Martin Hannigan wrote: > >From a strictly operational perspective: > > The only concern that I had with that request was with the v4 address > blocking. That ought to be rethought in the grand scheme of things i.e. v4 > exhaustion. ?There's a reasonable case to make regarding not tainting hosts > or specific blocks in this manner. Creating "less usable" v4 resources as we > approach exhaustion is not helpful, IMHO. > > Best Regards, > > Martin > > > > > >> 2009/5/4 John Levine : >>> >>>> Not withstanding the legality of such an order, how would one >>>>> operationally enforce that order? >>>>> >>>> >>>> The order has a list of IP addresses, so I expect the ISPs will just >>>> block those IPs in routers somewhere. >>>> >>>> Since offshore online gambling is equally illegal everywhere in the >>>> U.S., the ISPs have little reason to limit the block to Minnesota >>>> customers, giving them a lot of latitude in where they implement the >>>> block. >>>> >>> > > > -- > Martin Hannigan ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? martin at theicelandguy.com > p: +16178216079 > Power, Network, and Costs Consulting for Iceland Datacenters and Occupants > From kauer at biplane.com.au Tue May 5 19:39:23 2009 From: kauer at biplane.com.au (Karl Auer) Date: Wed, 06 May 2009 10:39:23 +1000 Subject: Where to buy Internet IP addresses In-Reply-To: References: <200905051313.n45DD6ar096138@aurora.sol.net> Message-ID: <1241570363.8158.81.camel@karl> On Tue, 2009-05-05 at 15:58 -0400, Ricky Beam wrote: > "stateless" with "constant" and "consistent". SLAAC doesn't need to > generate the exact same address everytime the system is started. No - but it is *phenomenally useful* if it does. Changing addresses is only ever something you want in very specific circumstances. > Bottom line... there's no pressing reason to make the jump, and a whole > bunch of reasons to hold off. But you don't seem to care about any of > that -- we should all continue driving our pintos with the exploding gas > tank until your local shop has time to replace it. No. Thanks. Wow, that's a metaphor that has been not merely mixed, but shaken and stirred as well. Are you for a move to IPv6 now or not? Is the Pinto IPv4 or IPv6? What does the exploding gas tank represent? If you mean we should hold off on moving to IPv6, then I disagree strongly. Here's a quote I like (because it's mine :-) "[...] the storm clouds have well and truly gathered, thunder is rolling in the hills, great big rain drops are splotting into the dust all around us, and what are we doing? Wandering around the outside of the Ark tut-tutting about the quality of the woodwork and loudly suggesting the construction of various sorts of rowboats." For what it's worth, I actually agree with you that 64 bits is way too short a prefix for the job. 80 would have been better, and some framework for *choosing* the prefix length and (say) hashing the MAC would have been even better. As it does you, the waste offends me, because I DO think we are repeating an IPv4 mistake. On the other hand - we have DHCPv6 to work around it. Noone HAS to use SLAAC. DHCPv4 is in every piece of home kit these days, with useful defaults, there's no show-stopper reason that DHCPv6 cannot do the same job. With a bit of work it could do a much better job. Regards, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer at biplane.com.au) +61-2-64957160 (h) http://www.biplane.com.au/~kauer/ +61-428-957160 (mob) GPG fingerprint: 07F3 1DF9 9D45 8BCD 7DD5 00CE 4A44 6A03 F43A 7DEF -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From bmanning at vacation.karoshi.com Tue May 5 19:46:01 2009 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Wed, 6 May 2009 00:46:01 +0000 Subject: Where to buy Internet IP addresses In-Reply-To: <1241570363.8158.81.camel@karl> References: <200905051313.n45DD6ar096138@aurora.sol.net> <1241570363.8158.81.camel@karl> Message-ID: <20090506004601.GA19998@vacation.karoshi.com.> On Wed, May 06, 2009 at 10:39:23AM +1000, Karl Auer wrote: > On Tue, 2009-05-05 at 15:58 -0400, Ricky Beam wrote: > > "stateless" with "constant" and "consistent". SLAAC doesn't need to > > generate the exact same address everytime the system is started. > > No - but it is *phenomenally useful* if it does. Changing addresses is > only ever something you want in very specific circumstances. pretty much every time the node moves in/across networks. if the node doesn't move, it keeps the same address. --bill From jfbeam at gmail.com Tue May 5 21:43:17 2009 From: jfbeam at gmail.com (Ricky Beam) Date: Tue, 05 May 2009 22:43:17 -0400 Subject: Where to buy Internet IP addresses In-Reply-To: <1241570363.8158.81.camel@karl> References: <200905051313.n45DD6ar096138@aurora.sol.net> <1241570363.8158.81.camel@karl> Message-ID: On Tue, 05 May 2009 20:39:23 -0400, Karl Auer wrote: > Wow, that's a metaphor that has been not merely mixed, but shaken and > stirred as well. Are you for a move to IPv6 now or not? Is the Pinto > IPv4 or IPv6? What does the exploding gas tank represent? I'm complaining that the IPv6 we're all being asked to use is a buggy contraption that's best parked until more of it's issues are resolved. Once we start down the path capable of supporting SLAAC's /64 requirement, there's no going back. The address space has be carved out; there's no "uncutting" that pie. (much in the same way the /8 handed out in the early 80's aren't being reclaimed.) > If you mean we should hold off on moving to IPv6, then I disagree > strongly. Here's a quote I like (because it's mine :-) The flood hasn't started yet. And the ark isn't finished; with enough people bailing water, it might stay afloat. :-) > On the other hand - we have DHCPv6 to work around it. Noone HAS to use > SLAAC. ... Yes, but as long as it exists, someone *will*. From jbates at brightok.net Tue May 5 22:02:32 2009 From: jbates at brightok.net (Jack Bates) Date: Tue, 05 May 2009 22:02:32 -0500 Subject: Where to buy Internet IP addresses In-Reply-To: References: <200905051313.n45DD6ar096138@aurora.sol.net> <1241570363.8158.81.camel@karl> Message-ID: <4A00FDC8.2090905@brightok.net> Ricky Beam wrote: > On Tue, 05 May 2009 20:39:23 -0400, Karl Auer wrote: >> On the other hand - we have DHCPv6 to work around it. Noone HAS to use >> SLAAC. ... > > Yes, but as long as it exists, someone *will*. Actually everyone does. The same formula is used for the link local addresses, which annoyingly show in all the routing tables. Jack From gormantatinus at gmail.com Tue May 5 23:08:42 2009 From: gormantatinus at gmail.com (=?ISO-8859-1?B?s6q72yCwzcC6ILXowfa1tSC4u7DtILq4wfa1tSC4?= =?ISO-8859-1?B?u7DtLCC4u8fPwfa1tSC4u7bz?=) Date: Wed, 6 May 2009 00:08:42 -0400 Subject: IRC channel? Message-ID: Is there a nanog IRC channel without all the white power aids herpes 4chan placenta fag beaner kike asr licks my fat diseased cock jokes? thanks. From kris.foster at gmail.com Tue May 5 23:26:10 2009 From: kris.foster at gmail.com (kris foster) Date: Tue, 5 May 2009 21:26:10 -0700 Subject: IRC channel? In-Reply-To: References: Message-ID: <7C115D38-B02E-48B6-BB11-11AB8B49657B@gmail.com> For the sake of everyone's sanity this thread has been moderated. Also, #nanog on efnet is in no way affiliated with NANOG. Kris MLC Chair From kauer at biplane.com.au Wed May 6 00:12:58 2009 From: kauer at biplane.com.au (Karl Auer) Date: Wed, 06 May 2009 15:12:58 +1000 Subject: Where to buy Internet IP addresses In-Reply-To: References: <200905051313.n45DD6ar096138@aurora.sol.net> <1241570363.8158.81.camel@karl> Message-ID: <1241586778.8158.146.camel@karl> On Tue, 2009-05-05 at 22:43 -0400, Ricky Beam wrote: > I'm complaining that the IPv6 we're all being asked to use is a buggy > contraption that's best parked until more of it's issues are resolved. Using it is the fastest way to get issues resolved. It worked for IPv4... :-) Expecting all the issues to be fixed before we start using it is the best way of all to ensure that it never gets off the ground at all. It's an excuse, and not a very good one. > Once we start down the path capable of supporting SLAAC's /64 requirement, > there's no going back. The address space has be carved out; there's no > "uncutting" that pie. I disagree. I can see several ways to retrofit more and better functionality in this area later. > The flood hasn't started yet. And the ark isn't finished; with enough > people bailing water, it might stay afloat. :-) Hm, like the fellow falling out of a tall building. As he flashed past each window on his way down, people on each floor heard him murmuring "so far so good...". Look, the Ark *is* finished. It floats. It can be steered. It has space for everyone. The fact that some of the plumbing is a bit iffy is just not a major issue right now; getting everybody on board is. We have LOTS of very clever people ready to bail, many of whom are quite capable of inventing bilge pumps from scratch. Sure the flood hasn't started. The fact that we are up to our ankles in water is a purely temporary phenomenon, nothing to worry about. Regards, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer at biplane.com.au) +61-2-64957160 (h) http://www.biplane.com.au/~kauer/ +61-428-957160 (mob) GPG fingerprint: 07F3 1DF9 9D45 8BCD 7DD5 00CE 4A44 6A03 F43A 7DEF -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From cabo at tzi.org Wed May 6 00:12:42 2009 From: cabo at tzi.org (Carsten Bormann) Date: Wed, 6 May 2009 07:12:42 +0200 Subject: Where to buy Internet IP addresses In-Reply-To: <4A00982D.1060209@brightok.net> References: <200905051845.n45IjuFl011800@aurora.sol.net> <4A008F5B.5030009@brightok.net> <4A00982D.1060209@brightok.net> Message-ID: <218A7056-7CCD-468B-892A-9CACD42C0D89@tzi.org> > Sure, but how does the router know it needs to hand out a /62? Then > what about the router after that? Does it hand out a /61? then the > router behind that? For now: Reserve a /64 for your own allocations (SAA), then hand out half of what you have (i.e., of a /56 for the first CPE, so a /57) to the first asker, then a /58, then a /59 etc. The first asker (nested CPE) has a /57, reserves a /64 for itself (SAA), hands out a /58 to its first child (double-nested CPE), then a /59. This algorithm restricts width plus depth to 8 (64 - 56), which is probably fine for most residential applications. The probabilistic aspect (FCFS) may cause you cognitive dissonance, but little technical problem. (Something that could be said about many of the "I grew up on IPv4 so I don't understand IPv6" postings here.) > What if the ISP only gave a /60? Don't do that then! (http://www.jargondb.org/glossary/dont-do-that-then) Really, /56 for everyone is the only way back to an Internet. Gruesse, Carsten From kauer at biplane.com.au Wed May 6 00:27:50 2009 From: kauer at biplane.com.au (Karl Auer) Date: Wed, 06 May 2009 15:27:50 +1000 Subject: Where to buy Internet IP addresses In-Reply-To: <218A7056-7CCD-468B-892A-9CACD42C0D89@tzi.org> References: <200905051845.n45IjuFl011800@aurora.sol.net> <4A008F5B.5030009@brightok.net> <4A00982D.1060209@brightok.net> <218A7056-7CCD-468B-892A-9CACD42C0D89@tzi.org> Message-ID: <1241587670.8158.149.camel@karl> On Wed, 2009-05-06 at 07:12 +0200, Carsten Bormann wrote: > Really, /56 for everyone is the only way back to an Internet. Sorry, I don't see why /56 is qualitatively different to a /60. Honest question - what's the difference? > Gruesse, Carsten Gruesse, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer at biplane.com.au) +61-2-64957160 (h) http://www.biplane.com.au/~kauer/ +61-428-957160 (mob) GPG fingerprint: 07F3 1DF9 9D45 8BCD 7DD5 00CE 4A44 6A03 F43A 7DEF -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From swmike at swm.pp.se Wed May 6 00:49:27 2009 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Wed, 6 May 2009 07:49:27 +0200 (CEST) Subject: Where to buy Internet IP addresses In-Reply-To: <1241587670.8158.149.camel@karl> References: <200905051845.n45IjuFl011800@aurora.sol.net> <4A008F5B.5030009@brightok.net> <4A00982D.1060209@brightok.net> <218A7056-7CCD-468B-892A-9CACD42C0D89@tzi.org> <1241587670.8158.149.camel@karl> Message-ID: On Wed, 6 May 2009, Karl Auer wrote: > On Wed, 2009-05-06 at 07:12 +0200, Carsten Bormann wrote: >> Really, /56 for everyone is the only way back to an Internet. > > Sorry, I don't see why /56 is qualitatively different to a /60. > > Honest question - what's the difference? Because more is more, and it makes it less likely that people will start to invent silly solutions to problems that do not really exist. With a /56, I can't really imagine this being not enough for 99.9% of households in 10 years, whereas I CAN imagine a household that needs more than 16 subnetworks, plus the PD model described in an earlier email makes a /56 more suited for chaining. We have no address shortage, there is little good to come out of trying to use as few IPv6 addresses as possible by means of constraints that are not necessary (let's be "wasteful" the first 50-100 years and "waste" the first /3, then we can look into if this is a problem or not). -- Mikael Abrahamsson email: swmike at swm.pp.se From mansaxel at besserwisser.org Wed May 6 01:12:29 2009 From: mansaxel at besserwisser.org (Mans Nilsson) Date: Wed, 6 May 2009 08:12:29 +0200 Subject: Where to buy Internet IP addresses In-Reply-To: References: <200905051313.n45DD6ar096138@aurora.sol.net> <1241570363.8158.81.camel@karl> Message-ID: <20090506061229.GA27438@besserwisser.org> Subject: Re: Where to buy Internet IP addresses Date: Tue, May 05, 2009 at 10:43:17PM -0400 Quoting Ricky Beam (jfbeam at gmail.com): > The address space has be carved out; > there's no "uncutting" that pie. (much in the same way the /8 handed out > in the early 80's aren't being reclaimed.) I believe Net 14 has been. http://www.ripe.net/ripe/meetings/ripe-55/presentations/vegoda-reclaiming-our.pdf Please do note that a /8 is being eaten every month by todays consumption rate. > The flood hasn't started yet. And the ark isn't finished; with enough > people bailing water, it might stay afloat. :-) My feet are humid... Not from Python boots. -- M?ns Nilsson From kauer at biplane.com.au Wed May 6 01:44:03 2009 From: kauer at biplane.com.au (Karl Auer) Date: Wed, 06 May 2009 16:44:03 +1000 Subject: Where to buy Internet IP addresses In-Reply-To: References: <200905051845.n45IjuFl011800@aurora.sol.net> <4A008F5B.5030009@brightok.net> <4A00982D.1060209@brightok.net> <218A7056-7CCD-468B-892A-9CACD42C0D89@tzi.org> <1241587670.8158.149.camel@karl> Message-ID: <1241592243.8158.177.camel@karl> On Wed, 2009-05-06 at 07:49 +0200, Mikael Abrahamsson wrote: > > Sorry, I don't see why /56 is qualitatively different to a /60. > Because more is more, and it makes it less likely that people will start > to invent silly solutions to problems that do not really exist. With a > /56, I can't really imagine this being not enough for 99.9% of households > in 10 years, whereas I CAN imagine a household that needs more than 16 > subnetworks, plus the PD model described in an earlier email makes a /56 > more suited for chaining. OK, I'm convinced :-) Thanks, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer at biplane.com.au) +61-2-64957160 (h) http://www.biplane.com.au/~kauer/ +61-428-957160 (mob) GPG fingerprint: 07F3 1DF9 9D45 8BCD 7DD5 00CE 4A44 6A03 F43A 7DEF -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From david.binet at orange-ftgroup.com Wed May 6 02:13:03 2009 From: david.binet at orange-ftgroup.com (david.binet at orange-ftgroup.com) Date: Wed, 6 May 2009 09:13:03 +0200 Subject: Where to buy Internet IP addresses In-Reply-To: References: <200905051845.n45IjuFl011800@aurora.sol.net><4A008F5B.5030009@brightok.net> Message-ID: <1B2E7539FECD9048B261B791B1B24A7C09E5C2EC0C@PUEXCB1A.nanterre.francetelecom.fr> Some times ago, i would say 6 or 7 years, there was a BoF proposition at IETF to deal with such issue. Work areas were to propagate routing mesh configuration information and automatic assignment of subnet prefixes to links. There were quite a lot of persons interested in such issues and some drafts were proposed. The name of the BoF was zerouter. Unfortunately, the working group was not created despite some real interest. David > -----Message d'origine----- > De : Mikael Abrahamsson [mailto:swmike at swm.pp.se] > Envoy? : mardi 5 mai 2009 21:22 > ? : nanog list > Objet : Re: Where to buy Internet IP addresses > > On Tue, 5 May 2009, Jack Bates wrote: > > > What is missing, unless I've missed a protocol (which is always > > possible), is an automated way for a CPE to assign it's > networks, pass > > other networks out to downstream routers in an on-need basis. I say > > on-need, as there may be 3 routers directly behind the CPE > and each of > > those may get additional routers and so on and so forth. A > presumption > > could be made that route efficiency is > > Why wouldn't DHCPv6-PD work within the home as well as > between the ISP and the home? > > I see little reason why the main home gateway can't get a /56 > from the ISP, and then hand out /62 (or whatever) to any > routers within the home that asks for PD? > > -- > Mikael Abrahamsson email: swmike at swm.pp.se > > ********************************* This message and any attachments (the "message") are confidential and intended solely for the addressees. Any unauthorised use or dissemination is prohibited. Messages are susceptible to alteration. France Telecom Group shall not be liable for the message if altered, changed or falsified. If you are not the intended addressee of this message, please cancel it immediately and inform the sender. ******************************** From jbates at brightok.net Wed May 6 07:52:22 2009 From: jbates at brightok.net (Jack Bates) Date: Wed, 06 May 2009 07:52:22 -0500 Subject: Where to buy Internet IP addresses In-Reply-To: <218A7056-7CCD-468B-892A-9CACD42C0D89@tzi.org> References: <200905051845.n45IjuFl011800@aurora.sol.net> <4A008F5B.5030009@brightok.net> <4A00982D.1060209@brightok.net> <218A7056-7CCD-468B-892A-9CACD42C0D89@tzi.org> Message-ID: <4A018806.9090304@brightok.net> Carsten Bormann wrote: > For now: Reserve a /64 for your own allocations (SAA), then hand out > half of what you have (i.e., of a /56 for the first CPE, so a /57) to > the first asker, then a /58, then a /59 etc. The first asker (nested > CPE) has a /57, reserves a /64 for itself (SAA), hands out a /58 to its > first child (double-nested CPE), then a /59. > This algorithm restricts width plus depth to 8 (64 - 56), which is > probably fine for most residential applications. > This makes a lot of assumptions that may not hold true and restricts home devices to treating IPv6 similar to how they treat IPv4. It's not scalable and it doesn't promote usage of multiple segments per device. The restriction is actually 6 if you make a more sane assumption of /61 per device and not /64. Standard CPE's can support multiple wireless networks and Ethernet segments. An ISP might divide up in a provided CPE, for example, wireless, data, voice, and video (which still needs unicast in addition to multicast). The netgear I configured last night for a customer supports 4 wireless networks plus ethernet. > The probabilistic aspect (FCFS) may cause you cognitive dissonance, but > little technical problem. > (Something that could be said about many of the "I grew up on IPv4 so I > don't understand IPv6" postings here.) > I have little trouble with understanding IPv6, but I do have issues with the current state of it both in standards and in implementations. FCFS only works if home routers continue to work similar to the way they do. >> What if the ISP only gave a /60? > > Don't do that then! > (http://www.jargondb.org/glossary/dont-do-that-then) > > Really, /56 for everyone is the only way back to an Internet. > See, that's where we disagree. Better standards is the only way back to the Internet. Solving all problems from end to end in diverse networks is the way back to the Internet. /56 is arbitrary. Making assumptions about how a network will be restricts the Internet. Jack From cabo at tzi.org Wed May 6 08:13:06 2009 From: cabo at tzi.org (Carsten Bormann) Date: Wed, 6 May 2009 15:13:06 +0200 Subject: Where to buy Internet IP addresses In-Reply-To: <4A018806.9090304@brightok.net> References: <200905051845.n45IjuFl011800@aurora.sol.net> <4A008F5B.5030009@brightok.net> <4A00982D.1060209@brightok.net> <218A7056-7CCD-468B-892A-9CACD42C0D89@tzi.org> <4A018806.9090304@brightok.net> Message-ID: On May 6, 2009, at 14:52, Jack Bates wrote: > Better standards Sure! (You are preaching to the choir here.) While we are still on the way there, we just: 1) Shouldn't waste time reinventing decisions that are a done deal (say, EUI-64 in SAA). 2) Shouldn't use the lack of our favorite feature as an excuse to do nothing (or worse, to dig the NAT hole deeper). 3) Shouldn't practice denial, but plan for at least a /56 for every customer relationship. Really, /56 for everyone is the only way back to an Internet. Gruesse, Carsten (This is my last message on this subject.) From dot at dotat.at Wed May 6 08:24:09 2009 From: dot at dotat.at (Tony Finch) Date: Wed, 6 May 2009 14:24:09 +0100 Subject: Where to buy Internet IP addresses In-Reply-To: <1241570363.8158.81.camel@karl> References: <200905051313.n45DD6ar096138@aurora.sol.net> <1241570363.8158.81.camel@karl> Message-ID: On Wed, 6 May 2009, Karl Auer wrote: > On Tue, 2009-05-05 at 15:58 -0400, Ricky Beam wrote: > > "stateless" with "constant" and "consistent". SLAAC doesn't need to > > generate the exact same address everytime the system is started. > > No - but it is *phenomenally useful* if it does. Changing addresses is > only ever something you want in very specific circumstances. You'll love RFC 4941 as implemented by Windows Vista and later. Tony. -- f.anthony.n.finch http://dotat.at/ GERMAN BIGHT HUMBER: SOUTHWEST 5 TO 7. MODERATE OR ROUGH. SQUALLY SHOWERS. MODERATE OR GOOD. From drc at virtualized.org Wed May 6 08:57:53 2009 From: drc at virtualized.org (David Conrad) Date: Wed, 6 May 2009 06:57:53 -0700 Subject: Where to buy Internet IP addresses In-Reply-To: <1241586778.8158.146.camel@karl> References: <200905051313.n45DD6ar096138@aurora.sol.net> <1241570363.8158.81.camel@karl> <1241586778.8158.146.camel@karl> Message-ID: <05A462F0-927A-4403-9BA8-DA78C951E09A@virtualized.org> On May 5, 2009, at 10:12 PM, Karl Auer wrote: > Look, the Ark *is* finished. It floats. It can be steered. It has > space > for everyone. The fact that some of the plumbing is a bit iffy is just > not a major issue right now; getting everybody on board is. We have > LOTS > of very clever people ready to bail, many of whom are quite capable of > inventing bilge pumps from scratch. Of course, the builders used screen doors and windows for the below- the-waterline openings, but not to worry, the bilge pump equivalent of Moore's Law will undoubtedly save us. Regards, -drc From kauer at biplane.com.au Wed May 6 09:31:02 2009 From: kauer at biplane.com.au (Karl Auer) Date: Thu, 07 May 2009 00:31:02 +1000 Subject: Where to buy Internet IP addresses In-Reply-To: References: <200905051313.n45DD6ar096138@aurora.sol.net> <1241570363.8158.81.camel@karl> Message-ID: <1241620262.8158.187.camel@karl> On Wed, 2009-05-06 at 14:24 +0100, Tony Finch wrote: > On Wed, 6 May 2009, Karl Auer wrote: > > On Tue, 2009-05-05 at 15:58 -0400, Ricky Beam wrote: > > > "stateless" with "constant" and "consistent". SLAAC doesn't need to > > > generate the exact same address everytime the system is started. > > > > No - but it is *phenomenally useful* if it does. Changing addresses is > > only ever something you want in very specific circumstances. > > You'll love RFC 4941 as implemented by Windows Vista and later. The fact that MS chose to use that as the default with Vista is odd, and I think a bad choice, but RFC4941 is not a bad thing in itself. It is an alternative that makes good sense in some contexts - but not, I think, in most contexts. And it's easy enough to turn off. XP uses temporary addresses too, also easy to turn off. Regards, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer at biplane.com.au) +61-2-64957160 (h) http://www.biplane.com.au/~kauer/ +61-428-957160 (mob) GPG fingerprint: 07F3 1DF9 9D45 8BCD 7DD5 00CE 4A44 6A03 F43A 7DEF -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From trejrco at gmail.com Wed May 6 09:44:45 2009 From: trejrco at gmail.com (TJ) Date: Wed, 6 May 2009 10:44:45 -0400 Subject: Where to buy Internet IP addresses In-Reply-To: <1241620262.8158.187.camel@karl> References: <200905051313.n45DD6ar096138@aurora.sol.net> <1241570363.8158.81.camel@karl> <1241620262.8158.187.camel@karl> Message-ID: <008701c9ce59$336889b0$9a399d10$@com> >-----Original Message----- >> > > "stateless" with "constant" and "consistent". SLAAC doesn't need >> > > to generate the exact same address everytime the system is started. >> > >> > No - but it is *phenomenally useful* if it does. Changing addresses >> > is only ever something you want in very specific circumstances. >> >> You'll love RFC 4941 as implemented by Windows Vista and later. > >The fact that MS chose to use that as the default with Vista is odd, and I >think a bad choice, but RFC4941 is not a bad thing in itself. It is an >alternative that makes good sense in some contexts - but not, I think, in most >contexts. > While I was initially inclined to agree, operating this way does allow some interesting capabilities - and I would be very interested in hearing from someone @MS as to their thinking behind this decision. /TJ From KaeglerM at tessco.com Wed May 6 10:10:45 2009 From: KaeglerM at tessco.com (Kaegler, Mike) Date: Wed, 06 May 2009 11:10:45 -0400 Subject: Testing LFNs Message-ID: I have a new T3 thats 65msec long. I'd usually be using iperf to test new links, but at 65msec, even at the maximum window size, I can only get 6-8mbit through. No combination of options I've been able to find has gotten me more than 6mbit through this link. Should I just shotgun 9 copies of it? Are there better ways to test these links? Can one verify this link with just a pair of 7200s and linux machines on either side? Or is this something one really needs "real" test hardware for? If 6mbit go through clean, is there a real chance 44 will not? TIA, -mKaegler -- Michael Kaegler, TESSCO Technologies: Engineering, 410 229 1295 Your wireless success, nothing less. http://www.tessco.com/ From dga at cs.cmu.edu Wed May 6 10:17:09 2009 From: dga at cs.cmu.edu (David Andersen) Date: Wed, 6 May 2009 11:17:09 -0400 Subject: Testing LFNs In-Reply-To: References: Message-ID: <0B0E2AC7-B426-46FE-A5E0-2F1C972C53A2@cs.cmu.edu> set your system send and receive TCP buffers larger. You're probably being limited by that. With linux, make sure you have window auto- scaling enabled and have increased the maximum size it can grow to to at least 4MB. Or test with UDP and blast as fast as you can so that you're not seeing TCP weirdness. IOS includes a 'ttcp' command you can use on the router itself: http://www.cisco.com/en/US/tech/tk801/tk36/technologies_tech_note09186a0080094694.shtml -Dave On May 6, 2009, at 11:10 AM, Kaegler, Mike wrote: > I have a new T3 thats 65msec long. I'd usually be using iperf to > test new > links, but at 65msec, even at the maximum window size, I can only get > 6-8mbit through. No combination of options I've been able to find > has gotten > me more than 6mbit through this link. Should I just shotgun 9 copies > of it? > > Are there better ways to test these links? Can one verify this link > with > just a pair of 7200s and linux machines on either side? Or is this > something > one really needs "real" test hardware for? If 6mbit go through > clean, is > there a real chance 44 will not? > > TIA, > -mKaegler > > > -- > Michael Kaegler, TESSCO Technologies: Engineering, 410 229 1295 > Your wireless success, nothing less. http://www.tessco.com/ > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 194 bytes Desc: This is a digitally signed message part URL: From jeremy at evilrouters.net Wed May 6 10:41:55 2009 From: jeremy at evilrouters.net (Jeremy L. Gaddis) Date: Wed, 6 May 2009 11:41:55 -0400 Subject: Minnesota Sends List of Blacklisted Gambling Sites to ISPs, Telcos Message-ID: <8623d07f0905060841h1cc070fbu7a27b65f18aa5f6b@mail.gmail.com> With regard to the recent discussion... "Late last month the Minnesota Department of Public Safety announced it would require ISPs and telcos to block computers located in the state from accessing gambling sites, and said non-compliant companies would be referred to the FCC. Now, the state has sent each ISP and telco the enclosed blacklist of sites and URLs." http://www.govtech.com/gt/articles/656645 -- Jeremy L. Gaddis From oberman at es.net Wed May 6 11:07:39 2009 From: oberman at es.net (Kevin Oberman) Date: Wed, 06 May 2009 09:07:39 -0700 Subject: Testing LFNs In-Reply-To: Your message of "Wed, 06 May 2009 11:10:45 EDT." Message-ID: <20090506160740.010AA1CC0C@ptavv.es.net> > Date: Wed, 06 May 2009 11:10:45 -0400 > From: "Kaegler, Mike" > > I have a new T3 thats 65msec long. I'd usually be using iperf to test new > links, but at 65msec, even at the maximum window size, I can only get > 6-8mbit through. No combination of options I've been able to find has gotten > me more than 6mbit through this link. Should I just shotgun 9 copies of it? > > Are there better ways to test these links? Can one verify this link with > just a pair of 7200s and linux machines on either side? Or is this something > one really needs "real" test hardware for? If 6mbit go through clean, is > there a real chance 44 will not? What is "maximum window size"? For T3 at 65 ms (is that one-way or RTT?) you don't need a really big window. Sounds like the system may need tuning. See http://fasterdata.es.net/ I use iperf at multiple Gigabit speeds and it works on a tuned system. You might want to use UDP for testing. It does not care about RTT, but is less efficient to receive. At 45 Mbps, there should be no problems, though. If all else fails, run 4 or 5 iperf jobs in parallel. (Use a different port for each.) -- 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 David_Hankins at isc.org Wed May 6 11:56:20 2009 From: David_Hankins at isc.org (David W. Hankins) Date: Wed, 6 May 2009 09:56:20 -0700 Subject: Where to buy Internet IP addresses In-Reply-To: <05A462F0-927A-4403-9BA8-DA78C951E09A@virtualized.org> References: <200905051313.n45DD6ar096138@aurora.sol.net> <1241570363.8158.81.camel@karl> <1241586778.8158.146.camel@karl> <05A462F0-927A-4403-9BA8-DA78C951E09A@virtualized.org> Message-ID: <20090506165619.GA4111@isc.org> On Wed, May 06, 2009 at 06:57:53AM -0700, David Conrad wrote: > Of course, the builders used screen doors and windows for the > below-the-waterline openings, but not to worry, the bilge pump equivalent > of Moore's Law will undoubtedly save us. Speaking as a builder, I have to say the screen doors were on the plans when I got there. I gather the planners believed they would facillitate use of the ark by hybrid human-acquatic lifeforms that did not exist at the time, nor do they exist today, but were hoped to exist because mermaids and mermen are, like, totally hot. -- David W. Hankins "If you don't do it right the first time, Software Engineer you'll just have to do it again." Internet Systems Consortium, Inc. -- Jack T. Hankins -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 194 bytes Desc: not available URL: From KaeglerM at tessco.com Wed May 6 12:20:49 2009 From: KaeglerM at tessco.com (Kaegler, Mike) Date: Wed, 06 May 2009 13:20:49 -0400 Subject: Testing LFNs (Wrapup) In-Reply-To: Message-ID: Thanks to everyone who responded on and off-list! It seems evident that I didn't have a complete understanding of the iperf switches which alter buffer sizes. Several people made a few neat points, which I'll quickly summarize: * In iperf, -P will allow one to run multiple tcp tests at once. * IOS has a built-in tester... ttcp. http://tinyurl.com/6fp75j * For suggestions on changing the kernel buffer sizes: * . http://www.29west.com/docs/THPM/ (section 8) * . http://fasterdata.es.net/ * Linux.com has a related writeup: http://www.linux.com/feature/144532 Finally, "past performance does not indicate future results" applies here. 44mbit will not necessarily go clean just because 6 did. Thanks for the tips, -mKaegler On 5/6/09 11:10 AM, "Michael Kaegler" wrote: > I have a new T3 thats 65msec long. I'd usually be using iperf to test new > links, but at 65msec, even at the maximum window size, I can only get > 6-8mbit through. No combination of options I've been able to find has gotten > me more than 6mbit through this link. Should I just shotgun 9 copies of it? > > Are there better ways to test these links? Can one verify this link with > just a pair of 7200s and linux machines on either side? Or is this something > one really needs "real" test hardware for? If 6mbit go through clean, is > there a real chance 44 will not? > > TIA, > -mKaegler > -- Michael Kaegler, TESSCO Technologies: Engineering, 410 229 1295 Your wireless success, nothing less. http://www.tessco.com/ From goemon at anime.net Wed May 6 12:25:03 2009 From: goemon at anime.net (goemon at anime.net) Date: Wed, 6 May 2009 10:25:03 -0700 (PDT) Subject: Minnesota Sends List of Blacklisted Gambling Sites to ISPs, Telcos In-Reply-To: <8623d07f0905060841h1cc070fbu7a27b65f18aa5f6b@mail.gmail.com> References: <8623d07f0905060841h1cc070fbu7a27b65f18aa5f6b@mail.gmail.com> Message-ID: On Wed, 6 May 2009, Jeremy L. Gaddis wrote: > With regard to the recent discussion... > > "Late last month the Minnesota Department of Public Safety announced > it would require ISPs and telcos to block computers located in the > state from accessing gambling sites, and said non-compliant companies > would be referred to the FCC. Now, the state has sent each ISP and > telco the enclosed blacklist of sites and URLs." > > http://www.govtech.com/gt/articles/656645 On the topic of gambling websites, is the minnesota state lottery website going to be blocked as well? -Dan From web at typo.org Wed May 6 12:33:17 2009 From: web at typo.org (Wayne E. Bouchard) Date: Wed, 6 May 2009 10:33:17 -0700 Subject: Minnesota Sends List of Blacklisted Gambling Sites to ISPs, Telcos In-Reply-To: <8623d07f0905060841h1cc070fbu7a27b65f18aa5f6b@mail.gmail.com> References: <8623d07f0905060841h1cc070fbu7a27b65f18aa5f6b@mail.gmail.com> Message-ID: <20090506173317.GA82238@typo.org> Lets see... so that list of domain names and IP addresses will be out of date, what, 3 weeks ago? I don't see how something so terribly arbitary can be long lived. On Wed, May 06, 2009 at 11:41:55AM -0400, Jeremy L. Gaddis wrote: > With regard to the recent discussion... > > "Late last month the Minnesota Department of Public Safety announced > it would require ISPs and telcos to block computers located in the > state from accessing gambling sites, and said non-compliant companies > would be referred to the FCC. Now, the state has sent each ISP and > telco the enclosed blacklist of sites and URLs." > > http://www.govtech.com/gt/articles/656645 > > -- > Jeremy L. Gaddis --- Wayne Bouchard web at typo.org Network Dude http://www.typo.org/~web/ From surfer at mauigateway.com Wed May 6 14:37:40 2009 From: surfer at mauigateway.com (Scott Weeks) Date: Wed, 6 May 2009 12:37:40 -0700 Subject: Alcatel as Peering and MSE(PE) Message-ID: <20090506123740.1678C590@resin14.mta.everyone.net> On Tue, May 5, 2009 at 10:29 AM, Mauritz Lewies wrote: > All based on the Alcatel 7750 chassis. > What is the general consensus of them in these layers of the network and > can anyone point out some strong points/short falls? ------------------------------------------------------ I've been on them for over a year and I like them. However, they operate very differently than other routers I have worked on. Also, there're definitely bugs here and there if you push them (7750/7450/7710) hard enough... ;-) There is a list here: https://puck.nether.net/mailman/listinfo/alcatel-nsp Not very many posts, though. scott From jfbeam at gmail.com Wed May 6 15:28:19 2009 From: jfbeam at gmail.com (Ricky Beam) Date: Wed, 06 May 2009 16:28:19 -0400 Subject: Where to buy Internet IP addresses In-Reply-To: References: <200905051313.n45DD6ar096138@aurora.sol.net> <1241570363.8158.81.camel@karl> Message-ID: On Wed, 06 May 2009 09:24:09 -0400, Tony Finch wrote: >> No - but it is *phenomenally useful* if it does. Changing addresses is >> only ever something you want in very specific circumstances. > > You'll love RFC 4941 as implemented by Windows Vista and later. Their awful experimental IPv6 stack in XP already does 3041, so I assume Vista, 2008, and 7 all do the same. In the XP case, it's not very agressive in rotating addresses. From jfbeam at gmail.com Wed May 6 15:38:19 2009 From: jfbeam at gmail.com (Ricky Beam) Date: Wed, 06 May 2009 16:38:19 -0400 Subject: Testing LFNs In-Reply-To: <0B0E2AC7-B426-46FE-A5E0-2F1C972C53A2@cs.cmu.edu> References: <0B0E2AC7-B426-46FE-A5E0-2F1C972C53A2@cs.cmu.edu> Message-ID: On Wed, 06 May 2009 11:17:09 -0400, David Andersen wrote: > Or test with UDP and blast as fast as you can so that you're not > seeing TCP weirdness. That's the best option... spew packets. Just make sure they are as large as possible without needing fragmentation. And if your setup can support it, set the ethernet MTUs to match the serial interface (4470). Not that PPS should be an issue -- even an ancient NPE150 should be able to process switch enough packets to flood a T3. From trejrco at gmail.com Wed May 6 15:50:15 2009 From: trejrco at gmail.com (TJ) Date: Wed, 6 May 2009 16:50:15 -0400 Subject: Where to buy Internet IP addresses In-Reply-To: References: <200905051313.n45DD6ar096138@aurora.sol.net> <1241570363.8158.81.camel@karl> Message-ID: <013201c9ce8c$4720b940$d5622bc0$@com> >>> No - but it is *phenomenally useful* if it does. Changing addresses >>> is only ever something you want in very specific circumstances. >> >> You'll love RFC 4941 as implemented by Windows Vista and later. > >Their awful experimental IPv6 stack in XP already does 3041, so I assume Vista, >2008, and 7 all do the same. In the XP case, it's not very agressive in >rotating addresses. Nope, different. No EUI64 at all - goes straight to randomized IIDs, but (cough) not to be confused with Temporary/Privacy IIDs. Randomized Link-local, randomized non-link local (Site|UniqueLocal|Global). FWIW - WinXP uses 24hours/change_in_prefix/reboot as the default criteria for new Privacy IID creation, is that not aggressive enough? I'd be curious to know what makes it "awful" IYO, I use it daily and have few complaints ... ? (I think the bigger / better complaint against WinXP is the lack of IPv6-transport support for DNS ... and perhaps the lack of DHCPv6 client functionality as well) /TJ From jfbeam at gmail.com Wed May 6 16:18:18 2009 From: jfbeam at gmail.com (Ricky Beam) Date: Wed, 06 May 2009 17:18:18 -0400 Subject: Where to buy Internet IP addresses In-Reply-To: <013201c9ce8c$4720b940$d5622bc0$@com> References: <200905051313.n45DD6ar096138@aurora.sol.net> <1241570363.8158.81.camel@karl> <013201c9ce8c$4720b940$d5622bc0$@com> Message-ID: On Wed, 06 May 2009 16:50:15 -0400, TJ wrote: > FWIW - WinXP uses 24hours/change_in_prefix/reboot as the default criteria > for new Privacy IID creation, is that not aggressive enough? I define that as "not aggressive". (I've seen ISPs rotate addresses (DHCP) faster than that.) > I'd be curious to know what makes it "awful" IYO, I use it daily and > have few complaints ... ? Where's the GUI for dealing with it? It's Windows(tm) after all. And it brings along a few other things we didn't ask for... a Toredo(?) tunnel interface, for one. But yes, it is functional. It'll get you to the small assortment of ipv6 websites around. > (I think the bigger / better complaint against WinXP is the lack of > IPv6-transport support for DNS ... and perhaps the lack of DHCPv6 client > functionality as well) Yes, but those things require more than just an IPv6 stack. Service components have to be changed to handle DNSv6 and DHCPv6. From trejrco at gmail.com Wed May 6 18:54:10 2009 From: trejrco at gmail.com (TJ) Date: Wed, 6 May 2009 19:54:10 -0400 Subject: Where to buy Internet IP addresses In-Reply-To: References: <200905051313.n45DD6ar096138@aurora.sol.net> <1241570363.8158.81.camel@karl> <013201c9ce8c$4720b940$d5622bc0$@com> Message-ID: <000f01c9cea5$f54b0570$dfe11050$@com> >> FWIW - WinXP uses 24hours/change_in_prefix/reboot as the default >> criteria for new Privacy IID creation, is that not aggressive enough? >I define that as "not aggressive". (I've seen ISPs rotate addresses (DHCP) >faster than that.) Fair enough, but IMHO it is aggressive enough to accomplish the design goal. >> I'd be curious to know what makes it "awful" IYO, I use it daily and >> have few complaints ... ? >Where's the GUI for dealing with it? It's Windows(tm) after all. Gotchya, sure some GUI would be nice ... but "netsh inter ipv6 install" + SLAAC (+IPv4 DHCP) isn't too bad :) >And it brings along a few other things we didn't ask for... a Toredo(?) tunnel >interface, for one. 6to4, ISATAP and Teredo all come along for the ride. While they may not have been asked for, the catch there is to make it easier for us poor users during this "transition" period ("transition in scary quotes because that is a terrible name ... much better : integration / co-existence). >But yes, it is functional. It'll get you to the small assortment of ipv6 >websites around. >> (I think the bigger / better complaint against WinXP is the lack of >> IPv6-transport support for DNS ... and perhaps the lack of DHCPv6 >> client functionality as well) >Yes, but those things require more than just an IPv6 stack. Service components >have to be changed to handle DNSv6 and DHCPv6. From bruns at 2mbit.com Thu May 7 00:39:14 2009 From: bruns at 2mbit.com (Brielle Bruns) Date: Wed, 06 May 2009 22:39:14 -0700 Subject: Contact for Verizon Wireless data Message-ID: <4A027402.80209@2mbit.com> Hello all, Does anyone have a contact within Verizon Wireless data (ie: EV-DO) that could help with some... odd (for lack of a better word) connection problems from an EV-DO modem? I think there may be some sort of packet filtering going on, but I can't tell for sure. It's kinda annoying... I'm in Los Angeles on a trip, and I have to VPN back home just to work around the filtering. Offlist would be great! Thank you! -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org / http://www.ahbl.org From youssef.ghorbal at gmail.com Thu May 7 04:43:37 2009 From: youssef.ghorbal at gmail.com (Youssef Ghorbal) Date: Thu, 7 May 2009 11:43:37 +0200 Subject: Where to buy Internet IP addresses In-Reply-To: <1160419770-1241474283-cardhu_decombobulator_blackberry.rim.net-255591761-@bxe1197.bisx.prod.on.blackberry> References: <49FEF5C0.9050109@ttec.com> <200905041427.n44ERf0A003326@aurora.sol.net> <18a5e7cb0905041403q47b78c1cvaba1452c6e6e4f0@mail.gmail.com> <49FF5FD0.6010304@sprunk.org> <1160419770-1241474283-cardhu_decombobulator_blackberry.rim.net-255591761-@bxe1197.bisx.prod.on.blackberry> Message-ID: On Mon, May 4, 2009 at 11:57 PM, wrote: > This has been a fascinating theoritcal discussion.. how do existing providers hand out space? > > Hurricane electric (via its tunnel service) hands out a /64 by default and a /48 is a click away. > > How do other providers handle it? I'm in the us and only have native v4 connectivity :( > > Do the various traditional last mile providers (sprint/Verizon/att/patch etc ) offer it for t1 and better? If they do then what do they hand out by default, what's available, at what price point and what's the upgrade path? Is it one click like he? > > No provider I have talked to offers it for residential connectivity in the united states. > What does free.fr do? Free does 6rd and allocate a /64 per customer. Here is a presentation how they do this : http://www.ripe.net/ripe/meetings/ripe-58/content/presentations/ipv6-free.pdf > > If there is this level of confusion and disagreement around addressing schemes then will it ever be offered to residences over traditional last mile loops? > > > Sent via BlackBerry from T-Mobile > > -----Original Message----- > From: Stephen Sprunk > > Date: Mon, 04 May 2009 16:36:16 > To: Bill Stewart > Cc: north American Noise and Off-topic Gripes; Joe Greco > Subject: Re: Where to buy Internet IP addresses > > > Bill Stewart wrote: >> When I came back, I found this ugly EUI-64 thing instead, so not only was autoconfiguration much uglier, but you needed a /56 instead of a /64 if you were going to subnet. > > It's supposed to be a /48 per customer, on the assumption that 16 bits > of subnet information is sufficient for virtually anyone; exceptions > should be rare enough that they can be handled as special cases. > > The /56 monstrosity came about because a US cable company wanted to > assign a prefix to every home they passed, regardless of whether it > contained a customer, so that they'd never need to renumber anything > ever again. ?However, that would require they get more than the /32 > minimum allocation, and ARIN policy doesn't allow _potential_ customers > as a justification for getting a larger allocation, so they had to > shrink the per-customer prefix down to a /56 to fit them all into a > single /32. ?If all those assignments were to _real_ customers, they > could have gotten a /24 and given each customer a /48 as expected. ?And, > after that, many folks who can't wrap their heads around the size of the > IPv6 address space appear to be obsessed with doing the same in other > cases where even that weak justification doesn't apply... > >> Does anybody know why anybody thought it was a good idea to put the extra bits in the middle, or for IPv6 to adopt them? >> > > Why the switch from EUI-48 to EUI-64? ?Someone in the IEEE got worried > about running short of MAC (er, EUI-48) addresses at some point in the > future, so they inserted 16 bits in the middle (after the OUI) to form > an EUI-64 and are now "discouraging" new uses of EUI-48. ?The IETF > decided to follow the IEEE's guidance and switch IPv6 autoconfig from > EUI-48 to EUI-64, but FireWire is the only significant user of EUI-64 > addresses to date; if you're using a link layer with EUI-48 addresses > (e.g. Ethernet), an extra 16 bits (FFFE) get stuffed in the middle to > transform it into the EUI-64 that IPv6 expects. > > S > > -- > Stephen Sprunk ? ? ? ? "God does not play dice." ?--Albert Einstein > CCIE #3723 ? ? ? ? "God is an inveterate gambler, and He throws the > K5SSS ? ? ? ?dice at every possible opportunity." --Stephen Hawking > > > From rs at seastrom.com Thu May 7 06:56:43 2009 From: rs at seastrom.com (Robert E. Seastrom) Date: Thu, 07 May 2009 07:56:43 -0400 Subject: Where to buy Internet IP addresses In-Reply-To: <49FF5FD0.6010304@sprunk.org> (Stephen Sprunk's message of "Mon, 04 May 2009 16:36:16 -0500") References: <49FEF5C0.9050109@ttec.com> <200905041427.n44ERf0A003326@aurora.sol.net> <18a5e7cb0905041403q47b78c1cvaba1452c6e6e4f0@mail.gmail.com> <49FF5FD0.6010304@sprunk.org> Message-ID: <86ljp9dt38.fsf@seastrom.com> Stephen Sprunk writes: > FireWire is the only significant user of EUI-64 addresses to date; > if you're using a link layer with EUI-48 addresses Zigbee has been around a lot less time than FireWire, but is hardly insignificant (ask anyone who's working on smartgrid or green home stuff). I'm sure there are others that just aren't on any of our personal radars. -r From jeffrey at exobitnetworks.com Thu May 7 07:59:39 2009 From: jeffrey at exobitnetworks.com (Jeffrey Meltzer) Date: Thu, 7 May 2009 08:59:39 -0400 (EDT) Subject: Alcatel 6850/Service Mode In-Reply-To: <9481128.7521241700507575.JavaMail.JEFF-PC$@jeff-pc> Message-ID: <18673399.7621241701101648.JavaMail.JEFF-PC$@jeff-pc> While Alcatel is somewhat on-topic -- if anyone is using 6850/6400 with Service Mode/Stacked VLAN's, can you drop me a note off list? Looking for anyone with experience building rings with them as points on the rings (CPE). Thanks, Jeff -- Jeffrey Meltzer Director of Network Operations Long Island Fiber Exchange / Exobit Networks (A LIFE Company) From deric.kwok2000 at gmail.com Thu May 7 09:25:55 2009 From: deric.kwok2000 at gmail.com (Deric Kwok) Date: Thu, 7 May 2009 10:25:55 -0400 Subject: Data centre info Message-ID: <40d8a95a0905070725g434b4145xc593e599524bc59b@mail.gmail.com> Hi all Any suggestion about data center 1/ to put on the switch in rack? eg: top. middle or bottom position 2/ There is no raise floor - adv - disadv Thank you for your information From lionair at samsung.com Thu May 7 09:35:19 2009 From: lionair at samsung.com (=?euc-kr?B?waTEob+1?=) Date: Thu, 07 May 2009 14:35:19 +0000 (GMT) Subject: Network performance monitoring tools Message-ID: <10319344.121691241706918947.JavaMail.weblogic@epml14> Hi, Could anyone recommend a free performance monitoring tool ? I am already using smokeping the best tool provides delay, packet loss and graphical delay variation and so on. But, additionally I would like to periodically measure the jitter of multi destinations. Best regards Chiyoung ============================================= Chi-Young Joung SAMSUNG NETWORKS Inc. Email: lionair at samsung.com Tel +82 70 7015 0623, Mobile +82 17 520 9193 Fax +82 70 7016 0031 ============================================= From hammersd at forest.net Thu May 7 10:21:38 2009 From: hammersd at forest.net (Shawn Hammer) Date: Thu, 7 May 2009 08:21:38 -0700 Subject: Data centre info In-Reply-To: <40d8a95a0905070725g434b4145xc593e599524bc59b@mail.gmail.com> References: <40d8a95a0905070725g434b4145xc593e599524bc59b@mail.gmail.com> Message-ID: <9E565717-A710-42ED-BC36-75620FCB7D38@forest.net> On May 7, 2009, at 7:25 AM, Deric Kwok wrote: > Hi all > > Any suggestion about data center > > 1/ to put on the switch in rack? > > eg: top. middle or bottom position > > 2/ There is no raise floor > - adv > - disadv > > Thank you for your information We like to see switch gear in the top of the rack and exhausting put the back (provided it doesn't have side to side air flow) Not having raised floor doesn't matter so long as cooling is delivered properly to the racks (top down, in row, or in rack), and cable management is available above the rack (ladder, trough, or rack-top like APC offers) From rs at seastrom.com Thu May 7 10:39:10 2009 From: rs at seastrom.com (Robert E. Seastrom) Date: Thu, 07 May 2009 11:39:10 -0400 Subject: Network performance monitoring tools In-Reply-To: <10319344.121691241706918947.JavaMail.weblogic@epml14> (=?iso-8859-1?Q?=C1=A4=C4=A1=BF=B5?= Message-ID: <86eiv0zzvl.fsf@seastrom.com> ?????? writes: > Could anyone recommend a free performance monitoring tool ? I am > already using smokeping the best tool provides delay, packet loss > and graphical delay variation and so on. But, additionally I would > like to periodically measure the jitter of multi destinations. Are you by any chance the person who inquired on IRC a few days ago about testing this for IPTV multicast? -r From jcdill.lists at gmail.com Thu May 7 10:51:19 2009 From: jcdill.lists at gmail.com (JC Dill) Date: Thu, 07 May 2009 08:51:19 -0700 Subject: Data centre info In-Reply-To: <9E565717-A710-42ED-BC36-75620FCB7D38@forest.net> References: <40d8a95a0905070725g434b4145xc593e599524bc59b@mail.gmail.com> <9E565717-A710-42ED-BC36-75620FCB7D38@forest.net> Message-ID: <4A030377.7000304@gmail.com> Shawn Hammer wrote: > Not having raised floor doesn't matter so long as cooling is delivered > properly to the racks (top down, in row, or in rack), Why do you believe that it is proper to deliver the cooling "top down"? Heat rises! The cool air needs to be delivered to the bottom (raised floor) or front (alternate row cooling) so that it flows over/thru the computers on its way to the hot air intakes which should be located above the back of the cabinet (above the "hot row") or top of the room (for raised floors). Disadvantages of no raised floor: IMHO the cooling is not as efficiently delivered or managed. Since electrical costs (and by extension, cooling costs) is one of the biggest costs for data centers, this cost is a large part of what you pay. If they aren't being efficient in the design, their costs are higher, and you end up paying higher fees. Yes, the build-out costs are higher, but it's the ongoing hosting costs that go ever higher year after year that will rack up your bill. Advantages of no raised floor: Someone can't sneak (a person or data line) into your cabinet or cage thru the floor. Racks are more stable in the event of an earthquake. Overhead cabling is easier to follow, maintain, repair. jc From jcdill.lists at gmail.com Thu May 7 11:53:49 2009 From: jcdill.lists at gmail.com (JC Dill) Date: Thu, 07 May 2009 09:53:49 -0700 Subject: Data centre info In-Reply-To: <86ws8sswpy.fsf@seastrom.com> References: <40d8a95a0905070725g434b4145xc593e599524bc59b@mail.gmail.com> <9E565717-A710-42ED-BC36-75620FCB7D38@forest.net> <4A030377.7000304@gmail.com> <86ws8sswpy.fsf@seastrom.com> Message-ID: <4A03121D.2040909@gmail.com> > >> JC Dill writes: >> >> >>> Why do you believe that it is proper to deliver the cooling "top >>> down"? Heat rises! The cool air needs to be delivered to the bottom >>> (raised floor) or front (alternate row cooling) so that it flows >>> over/thru the computers on its way to the hot air intakes which should >>> be located above the back of the cabinet (above the "hot row") or top >>> of the room (for raised floors). >>> >> >> This would be true if the computers were all mounted within several >> inches of the floor, but they're not. >> >> Just as heat rises, cold sinks. Discharging cool air up high in a >> data center will cause it to end up where it needs to be for all >> computers in a rack, not just the ones in the bottom. >> In theory, this should work. In theory, there is no difference between theory and practice. In practice, there is. >> Visit any Equinix for an example of this principle in action I disagree, and I've been in several Equinix locations. Computers produce heat / hot air, and this hot air rises. As the hot air rises and moves away from the computers, new air has to circulate in from *somewhere*. There isn't a vacuum of "no air" between the cold air sinking/sitting at the bottom of the room and the hot air rising up to the ceiling. :-) When you have cold air entering the bottom and/or front of a rack, and hot air exiting out the back (and then up) then you don't have cold air mixed with hot air circulating in the room before it gets to the computers. The fans located in the building's hot air intakes, the action of the rising hot air, and the fans blowing the cold air into the data center all create the air flow that pulls the "heavier" cold air up into and across the computers. When you have cold air coming down in the same area with hot air going up, it just mixes up into warm air, and truly cold air never gets to the bottom - you get warm (or hot) air flowing across the bottom computers in the racks. This is not an efficient air flow, and not a good way to keep the hot and cold air separate so you can get cold air (not warm air) flowing over the equipment. It works great for offices full of people (where you want an even temp everywhere in the room) but isn't great for computers (where you want cold air entering the equipment for maximum cooling effect and hot air being removed as quickly as possible.) I've never been happy with the room temps or equipment temps in any data center that used this "blow cold air from the ceiling" approach. But hey, if it works for your equipment, more power to you. I encourage all my competitors to do this. jc From if at xip.at Thu May 7 11:59:46 2009 From: if at xip.at (Ingo Flaschberger) Date: Thu, 7 May 2009 18:59:46 +0200 (CEST) Subject: Data centre info In-Reply-To: <40d8a95a0905070725g434b4145xc593e599524bc59b@mail.gmail.com> References: <40d8a95a0905070725g434b4145xc593e599524bc59b@mail.gmail.com> Message-ID: Dear Deric, > Any suggestion about data center > > 1/ to put on the switch in rack? Top > eg: top. middle or bottom position > > 2/ There is no raise floor > - adv hot/cool corridor solution (air-condition standing between racks, apc has solutions) easy cabling > - disadv you can not hide cables kind regards, Ingo Flaschberger From rapple at rapidlink.com Thu May 7 13:34:01 2009 From: rapple at rapidlink.com (Raleigh Apple) Date: Thu, 07 May 2009 14:34:01 -0400 Subject: UCEProtect Level 3 Message-ID: <4A032999.8000707@rapidlink.com> Is anyone else out there aware that the UCEProtect Level 3 email blacklist blocks entire AS? r From aaron at wholesaleinternet.net Thu May 7 13:43:14 2009 From: aaron at wholesaleinternet.net (Aaron Wendel) Date: Thu, 7 May 2009 13:43:14 -0500 Subject: UCEProtect Level 3 In-Reply-To: <4A032999.8000707@rapidlink.com> References: <4A032999.8000707@rapidlink.com> Message-ID: <289601c9cf43$ae519370$0af4ba50$@net> Yes. Is that a problem? -----Original Message----- From: Raleigh Apple [mailto:rapple at rapidlink.com] Sent: Thursday, May 07, 2009 1:34 PM To: nanog at nanog.org Subject: UCEProtect Level 3 Is anyone else out there aware that the UCEProtect Level 3 email blacklist blocks entire AS? r From sethm at rollernet.us Thu May 7 13:44:07 2009 From: sethm at rollernet.us (Seth Mattinen) Date: Thu, 07 May 2009 11:44:07 -0700 Subject: UCEProtect Level 3 In-Reply-To: <4A032999.8000707@rapidlink.com> References: <4A032999.8000707@rapidlink.com> Message-ID: <4A032BF7.4040809@rollernet.us> Raleigh Apple wrote: > Is anyone else out there aware that the UCEProtect Level 3 email > blacklist blocks entire AS? > http://lmgtfy.com/?q=uceprotect+level+3 From sethm at rollernet.us Thu May 7 13:56:03 2009 From: sethm at rollernet.us (Seth Mattinen) Date: Thu, 07 May 2009 11:56:03 -0700 Subject: Data centre info In-Reply-To: References: <40d8a95a0905070725g434b4145xc593e599524bc59b@mail.gmail.com> Message-ID: <4A032EC3.80707@rollernet.us> Ingo Flaschberger wrote: >> - disadv > > you can not hide cables > I think well-dressed visible overhead cable arrangements look kind of cool. I'd rather see nice cables than a hidden rat's nest. ~Seth From karnaugh at karnaugh.za.net Thu May 7 15:06:30 2009 From: karnaugh at karnaugh.za.net (Colin Alston) Date: Thu, 07 May 2009 22:06:30 +0200 Subject: UCEProtect Level 3 In-Reply-To: <4A032999.8000707@rapidlink.com> References: <4A032999.8000707@rapidlink.com> Message-ID: <4A033F46.5020209@karnaugh.za.net> On 2009/05/07 08:34 PM Raleigh Apple wrote: > Is anyone else out there aware that the UCEProtect Level 3 email > blacklist blocks entire AS? Yes. We don't use them anymore. From darcy at druid.net Thu May 7 15:10:41 2009 From: darcy at druid.net (D'Arcy J.M. Cain) Date: Thu, 7 May 2009 16:10:41 -0400 Subject: UCEProtect Level 3 In-Reply-To: <289601c9cf43$ae519370$0af4ba50$@net> References: <4A032999.8000707@rapidlink.com> <289601c9cf43$ae519370$0af4ba50$@net> Message-ID: <20090507161041.f1711126.darcy@druid.net> On Thu, 7 May 2009 13:43:14 -0500 "Aaron Wendel" wrote: > Yes. Is that a problem? It is. I understand what they are trying to do but we were cut off from some places because someone else in the huge upstream we are with did something that appeared to be spam. It's too broad of a brush. -- D'Arcy J.M. Cain | Democracy is three wolves http://www.druid.net/darcy/ | and a sheep voting on +1 416 425 1212 (DoD#0082) (eNTP) | what's for dinner. From pauldotwall at gmail.com Thu May 7 15:14:15 2009 From: pauldotwall at gmail.com (Paul Wall) Date: Thu, 7 May 2009 16:14:15 -0400 Subject: Data centre info In-Reply-To: <4A03121D.2040909@gmail.com> References: <40d8a95a0905070725g434b4145xc593e599524bc59b@mail.gmail.com> <9E565717-A710-42ED-BC36-75620FCB7D38@forest.net> <4A030377.7000304@gmail.com> <86ws8sswpy.fsf@seastrom.com> <4A03121D.2040909@gmail.com> Message-ID: <620fd17c0905071314j152a682cg33ade2c2b066521b@mail.gmail.com> On Thu, May 7, 2009 at 12:53 PM, JC Dill wrote: > I've never been happy with the room temps or equipment temps in any data > center that used this "blow cold air from the ceiling" approach. ?But hey, > if it works for your equipment, more power to you. ?I encourage all my > competitors to do this. All joking and invoking Randy aside, are you really providing datacenter HVAC advice to other promising young equine photographers? Care to enlighten us with some of their top concerns in data center design? I always suspected there was some sort of unspoken back-story behind Equinix's big red silo. Drive Slow, Paul Wall From jeffrey at exobitnetworks.com Thu May 7 15:16:02 2009 From: jeffrey at exobitnetworks.com (Jeffrey Meltzer) Date: Thu, 7 May 2009 16:16:02 -0400 (EDT) Subject: UCEProtect Level 3 In-Reply-To: <4A032999.8000707@rapidlink.com> Message-ID: <16907251.8001241727229961.JavaMail.JEFF-PC$@jeff-pc> We stopped using UCEProtect in most places recently after using for I think a year or two -- Level 2 was blacklisting giant-sized netblocks (ie, most Cablevision cablemodem IP Space, twice, as well as large chunks of AboveNet space, and that's just what I noticed). ----- Original Message ----- From: "Raleigh Apple" To: nanog at nanog.org Sent: Thursday, May 7, 2009 2:34:01 PM GMT -05:00 US/Canada Eastern Subject: UCEProtect Level 3 Is anyone else out there aware that the UCEProtect Level 3 email blacklist blocks entire AS? r From rsk at gsp.org Thu May 7 15:21:26 2009 From: rsk at gsp.org (Rich Kulawiec) Date: Thu, 7 May 2009 16:21:26 -0400 Subject: No subject Message-ID: <20090507202126.GA26174@gsp.org> Cc Bcc: Subject: Re: UCEProtect Level 3 Reply-To: In-Reply-To: <20090507161041.f1711126.darcy at druid.net> On Thu, May 07, 2009 at 04:10:41PM -0400, D'Arcy J.M. Cain wrote: > It is. I understand what they are trying to do but we were cut off > from some places because someone else in the huge upstream we are with > did something that appeared to be spam. It's too broad of a brush. (a) This discussion should probably be happening someplace other than NANOG (spam-l or mailop, perhaps?), and (b) If you feel that UCEProtect L3 paints with too broad a brush, then you're certainly free not to use it. I happen to agree with you on this particular level of this particular DNSBL for my particular applications, so I don't use it either. However: I'm aware of other folks who are using it quite effectively as *part* of a scoring system. ---Rsk From mliotta at r337.com Thu May 7 15:26:20 2009 From: mliotta at r337.com (Matt Liotta) Date: Thu, 7 May 2009 16:26:20 -0400 Subject: UCEProtect Level 3 In-Reply-To: <20090507161041.f1711126.darcy@druid.net> References: <4A032999.8000707@rapidlink.com> <289601c9cf43$ae519370$0af4ba50$@net> <20090507161041.f1711126.darcy@druid.net> Message-ID: <322E1AC8-9DE6-41B2-A108-BB4EC6039DA4@r337.com> On May 7, 2009, at 4:10 PM, D'Arcy J.M. Cain wrote: > It is. I understand what they are trying to do but we were cut off > from some places because someone else in the huge upstream we are with > did something that appeared to be spam. It's too broad of a brush. > Indeed. That is the sort of vigilantism that leads to filtering chaos. What happens when other ASNs start filtering the entire AS of UCEProtect's upstream(s) as a response? -Matt From darcy at druid.net Thu May 7 15:29:19 2009 From: darcy at druid.net (D'Arcy J.M. Cain) Date: Thu, 7 May 2009 16:29:19 -0400 Subject: UCEProtect Level 3 In-Reply-To: <20090507202126.GA26174@gsp.org> References: <20090507202126.GA26174@gsp.org> Message-ID: <20090507162919.ef4853bf.darcy@druid.net> On Thu, 7 May 2009 16:21:26 -0400 Rich Kulawiec wrote: > (a) This discussion should probably be happening someplace other > than NANOG (spam-l or mailop, perhaps?), and True. I didn't bring it up but this is my last post on the subject. > (b) If you feel that UCEProtect L3 paints with too broad a brush, > then you're certainly free not to use it. I happen to agree with you > on this particular level of this particular DNSBL for my particular > applications, so I don't use it either. However: I'm aware of other > folks who are using it quite effectively as *part* of a scoring system. I don't use it but my problem was that other ISPs whose clients were trying to email my clients were using it. -- D'Arcy J.M. Cain | Democracy is three wolves http://www.druid.net/darcy/ | and a sheep voting on +1 416 425 1212 (DoD#0082) (eNTP) | what's for dinner. From tomb at byrneit.net Fri May 8 00:13:05 2009 From: tomb at byrneit.net (Tomas L. Byrnes) Date: Thu, 7 May 2009 22:13:05 -0700 Subject: UCEProtect Level 3 In-Reply-To: <4A032BF7.4040809@rollernet.us> References: <4A032999.8000707@rapidlink.com> <4A032BF7.4040809@rollernet.us> Message-ID: <70D072392E56884193E3D2DE09C097A91F3E4C@pascal.zaphodb.org> Anyone who reads their description of it would be: http://www.uceprotect.net/en/index.php?m=3&s=5 Are you one of the ASes they blacklist on that list? >-----Original Message----- >From: Seth Mattinen [mailto:sethm at rollernet.us] >Sent: Thursday, May 07, 2009 11:44 AM >To: nanog at nanog.org >Subject: Re: UCEProtect Level 3 > >Raleigh Apple wrote: >> Is anyone else out there aware that the UCEProtect Level 3 email >> blacklist blocks entire AS? >> > > >http://lmgtfy.com/?q=uceprotect+level+3 From ops.lists at gmail.com Fri May 8 00:24:29 2009 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Fri, 8 May 2009 10:54:29 +0530 Subject: UCEProtect Level 3 In-Reply-To: <4A032999.8000707@rapidlink.com> References: <4A032999.8000707@rapidlink.com> Message-ID: On Fri, May 8, 2009 at 12:04 AM, Raleigh Apple wrote: > Is anyone else out there aware that the UCEProtect Level 3 email blacklist > blocks entire AS? > Is there anyone out there aware of any significant (or larger than 'man and his dog on a DSL') mail provider using UCEPROTECT? -- Suresh Ramasubramanian (ops.lists at gmail.com) From Skywing at valhallalegends.com Fri May 8 00:30:49 2009 From: Skywing at valhallalegends.com (Skywing) Date: Fri, 8 May 2009 00:30:49 -0500 Subject: UCEProtect Level 3 Message-ID: <982D8D05B6407A49AD506E6C3AC8E7D60108AEBF4EB7@caralain.haven.nynaeve.net> I seem to recall that Mailstreet/MXlogic firewalls off (not rejects at SMTP level) any AS listed in UCEProtect, at least of about a year or so ago. - S -----Original Message----- From: Suresh Ramasubramanian Sent: Thursday, May 07, 2009 22:25 To: Raleigh Apple Cc: nanog at nanog.org Subject: Re: UCEProtect Level 3 On Fri, May 8, 2009 at 12:04 AM, Raleigh Apple wrote: > Is anyone else out there aware that the UCEProtect Level 3 email blacklist > blocks entire AS? > Is there anyone out there aware of any significant (or larger than 'man and his dog on a DSL') mail provider using UCEPROTECT? -- Suresh Ramasubramanian (ops.lists at gmail.com) From oliver.hookins at anchor.com.au Fri May 8 00:33:36 2009 From: oliver.hookins at anchor.com.au (Oliver Hookins) Date: Fri, 8 May 2009 15:33:36 +1000 Subject: Checking bogon status of new address space Message-ID: <20090508053336.GC7171@captain.bridge.anchor.net.au> Hi, my company has just been allocated some new IPv4 address space, and I want to do some sort of automated testing to find out any ASs out there that haven't removed the /8 it's on from their bogon list (the allocation to our local registry only occurred in November last year). Has anybody attempted to do this? It is worth bothering? Currently I'm considering pulling out all the endpoint ASs out of the BGP table, finding at least one subnet for each of them and attempting to ping or reach other common ports on a single IP for each AS from our currently working address space, and then the new address space and comparing results. -- Regards, Oliver Hookins Anchor Systems From ops.lists at gmail.com Fri May 8 00:43:04 2009 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Fri, 8 May 2009 11:13:04 +0530 Subject: UCEProtect Level 3 In-Reply-To: <982D8D05B6407A49AD506E6C3AC8E7D60108AEBF4EB7@caralain.haven.nynaeve.net> References: <982D8D05B6407A49AD506E6C3AC8E7D60108AEBF4EB7@caralain.haven.nynaeve.net> Message-ID: On Fri, May 8, 2009 at 11:00 AM, Skywing wrote: > I seem to recall that Mailstreet/MXlogic firewalls off (not rejects at SMTP level) any AS listed in UCEProtect, at least of about a year or so ago. > > - S > I would be very surprised indeed if MX Logic did something like that. srs From john at vanoppen.com Fri May 8 02:26:31 2009 From: john at vanoppen.com (John van Oppen) Date: Fri, 8 May 2009 00:26:31 -0700 Subject: UCEProtect Level 3 References: <982D8D05B6407A49AD506E6C3AC8E7D60108AEBF4EB7@caralain.haven.nynaeve.net> Message-ID: We had complaints about our entire ASN being listed too, due to a bunch of infected hosts in a sub-allocated /23 (out of our nearly /16 of space). The best part is they don't bother to report the abuse, they just block the entire ASN, not terribly productive. John van Oppen Spectrum Networks LLC Direct: 206.973.8302 Main: 206.973.8300 Website: http://spectrumnetworks.us -----Original Message----- From: Skywing [mailto:Skywing at valhallalegends.com] Sent: Thursday, May 07, 2009 10:31 PM To: Suresh Ramasubramanian; Raleigh Apple Cc: nanog at nanog.org Subject: RE: UCEProtect Level 3 I seem to recall that Mailstreet/MXlogic firewalls off (not rejects at SMTP level) any AS listed in UCEProtect, at least of about a year or so ago. - S -----Original Message----- From: Suresh Ramasubramanian Sent: Thursday, May 07, 2009 22:25 To: Raleigh Apple Cc: nanog at nanog.org Subject: Re: UCEProtect Level 3 On Fri, May 8, 2009 at 12:04 AM, Raleigh Apple wrote: > Is anyone else out there aware that the UCEProtect Level 3 email blacklist > blocks entire AS? > Is there anyone out there aware of any significant (or larger than 'man and his dog on a DSL') mail provider using UCEPROTECT? -- Suresh Ramasubramanian (ops.lists at gmail.com) From joelja at bogus.com Fri May 8 02:57:14 2009 From: joelja at bogus.com (Joel Jaeggli) Date: Fri, 08 May 2009 00:57:14 -0700 Subject: Network performance monitoring tools In-Reply-To: <10319344.121691241706918947.JavaMail.weblogic@epml14> References: <10319344.121691241706918947.JavaMail.weblogic@epml14> Message-ID: <4A03E5DA.5020703@bogus.com> Jitter (e.g. variability in one way or rtt) smokeping is rather good at measuring... The question is do you want to instrument the phenomena through active measurement as smokeping is doing or do you have some application (e.g. streaming media as an example) that you'd like to instrument because the later may be more descriptive of the overall service experience with that application... ??? wrote: > Hi, > > Could anyone recommend a free performance monitoring tool ? > I am already using smokeping the best tool provides delay, packet loss and graphical delay variation and so on. > But, additionally I would like to periodically measure the jitter of multi destinations. > > Best regards > Chiyoung > ============================================= > Chi-Young Joung > SAMSUNG NETWORKS Inc. > Email: lionair at samsung.com > Tel +82 70 7015 0623, Mobile +82 17 520 9193 > Fax +82 70 7016 0031 > ============================================= From cidr-report at potaroo.net Fri May 8 07:00:05 2009 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 8 May 2009 22:00:05 +1000 (EST) Subject: The Cidr Report Message-ID: <200905081200.n48C05oC031731@wattle.apnic.net> This report has been generated at Fri May 8 21:15:47 2009 AEST. The report analyses the BGP Routing Table of AS2.0 router and generates a report on aggregation potential within the table. Check http://www.cidr-report.org for a current version of this report. Recent Table History Date Prefixes CIDR Agg 01-05-09 293917 183484 02-05-09 294085 181319 03-05-09 293622 180638 04-05-09 292601 181458 05-05-09 293746 181941 06-05-09 293836 182155 07-05-09 293603 182383 08-05-09 294143 182320 AS Summary 31275 Number of ASes in routing system 13311 Number of ASes announcing only one prefix 4307 Largest number of prefixes announced by an AS AS6389 : BELLSOUTH-NET-BLK - BellSouth.net Inc. 89676544 Largest address span announced by an AS (/32s) AS27064: DDN-ASNBLK1 - DoD Network Information Center Aggregation Summary The algorithm used in this report proposes aggregation only when there is a precise match using the AS path, so as to preserve traffic transit policies. Aggregation is also proposed across non-advertised address space ('holes'). --- 08May09 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 294012 182446 111566 37.9% All ASes AS6389 4307 356 3951 91.7% BELLSOUTH-NET-BLK - BellSouth.net Inc. AS4323 4267 1747 2520 59.1% TWTC - tw telecom holdings, inc. AS209 2564 1147 1417 55.3% ASN-QWEST - Qwest Communications Corporation AS4766 1808 525 1283 71.0% KIXS-AS-KR Korea Telecom AS17488 1573 297 1276 81.1% HATHWAY-NET-AP Hathway IP Over Cable Internet AS4755 1241 146 1095 88.2% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP AS22773 1056 67 989 93.7% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. AS8452 1231 251 980 79.6% TEDATA TEDATA AS1785 1755 802 953 54.3% AS-PAETEC-NET - PaeTec Communications, Inc. AS8151 1449 556 893 61.6% Uninet S.A. de C.V. AS19262 991 239 752 75.9% VZGNI-TRANSIT - Verizon Internet Services Inc. AS18566 1062 421 641 60.4% COVAD - Covad Communications Co. AS6478 1398 806 592 42.3% ATT-INTERNET3 - AT&T WorldNet Services AS18101 756 167 589 77.9% RIL-IDC Reliance Infocom Ltd Internet Data Centre, AS11492 1102 535 567 51.5% CABLEONE - CABLE ONE, INC. AS22047 616 99 517 83.9% VTR BANDA ANCHA S.A. AS855 621 110 511 82.3% CANET-ASN-4 - Bell Aliant Regional Communications, Inc. AS4804 574 66 508 88.5% MPX-AS Microplex PTY LTD AS2706 534 42 492 92.1% HKSUPER-HK-AP Pacific Internet (Hong Kong) Limited AS17676 565 81 484 85.7% GIGAINFRA BB TECHNOLOGY Corp. AS17908 616 142 474 76.9% TCISL Tata Communications AS10620 924 451 473 51.2% TV Cable S.A. AS4808 627 166 461 73.5% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network AS24560 684 234 450 65.8% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services AS7018 1463 1015 448 30.6% ATT-INTERNET4 - AT&T WorldNet Services AS7545 806 366 440 54.6% TPG-INTERNET-AP TPG Internet Pty Ltd AS9443 527 98 429 81.4% INTERNETPRIMUS-AS-AP Primus Telecommunications AS6517 660 241 419 63.5% RELIANCEGLOBALCOM - Reliance Globalcom Services, Inc AS7011 960 552 408 42.5% FRONTIER-AND-CITIZENS - Frontier Communications of America, Inc. AS4668 688 282 406 59.0% LGNET-AS-KR LG CNS Total 37425 12007 25418 67.9% Top 30 total Possible Bogus Routes 24.245.128.0/17 AS11492 CABLEONE - CABLE ONE, INC. 24.246.0.0/17 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 24.246.128.0/18 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 41.223.112.0/22 AS5713 SAIX-NET 41.223.176.0/22 AS36981 41.223.188.0/24 AS22351 INTELSAT Intelsat Global BGP Routing Policy 41.223.189.0/24 AS26452 BRING-AS - BringCom, Inc. 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV - Wireless Broadband via Satellite 62.61.221.0/24 AS24974 TACHYON-EU Tachyon Europe BV - Wireless Broadband via Satellite 63.140.213.0/24 AS22555 UTC - Universal Talkware Corporation 63.143.251.0/24 AS22555 UTC - Universal Talkware Corporation 64.31.32.0/19 AS11955 SCRR-11955 - Road Runner HoldCo LLC 64.31.59.0/24 AS7017 SCRR-7015 - Road Runner HoldCo LLC 64.31.60.0/24 AS7017 SCRR-7015 - Road Runner HoldCo LLC 64.79.88.0/24 AS26096 LODDEN - Lodden Services 64.79.89.0/24 AS26096 LODDEN - Lodden Services 64.147.64.0/19 AS40156 THEOPT-HOU - The Optimal Link Corporation 66.11.32.0/20 AS6261 VISINET - Visionary Systems, Inc. 66.11.40.0/21 AS6261 VISINET - Visionary Systems, Inc. 66.54.91.0/24 AS30506 BLACKSUN-1 - Blacksun Technologies LLC 66.55.160.0/19 AS29994 66.128.38.0/24 AS15246 Telecomunicaciones Satelitales TelesatS.A. 66.180.239.0/24 AS35888 VIGNETTE - VIGNETTE CORPORATION 66.206.32.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.33.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.34.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.35.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.40.0/22 AS174 COGENT Cogent/PSI 66.206.44.0/23 AS174 COGENT Cogent/PSI 66.206.47.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 66.207.32.0/20 AS23011 66.245.176.0/20 AS19318 NJIIX-AS-1 - NEW JERSEY INTERNATIONAL INTERNET EXCHANGE LLC 69.71.192.0/20 AS13818 PHX-INTL-TELEPORT - Phoenix International Teleport 80.88.0.0/21 AS33774 DJAWEB 80.88.8.0/22 AS33774 DJAWEB 80.88.10.0/24 AS33774 DJAWEB 80.88.12.0/24 AS33779 wataniya-telecom-as 100.100.100.0/30 AS38676 AS33005-AS-KR wizsolution co.,Ltd 109.0.0.0/16 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 109.1.0.0/21 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 109.1.24.0/24 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 110.76.156.0/24 AS45062 CNNIC-FKT-AP FEIKE TECH LIMITED 110.76.157.0/24 AS45062 CNNIC-FKT-AP FEIKE TECH LIMITED 121.46.0.0/16 AS4134 CHINANET-BACKBONE No.31,Jin-rong Street 121.50.168.0/21 AS9931 CAT-AP The Communication Authoity of Thailand, CAT 122.128.120.0/22 AS38456 PACTEL-AS-AP Pacific Teleports. 137.0.0.0/13 AS27064 DDN-ASNBLK1 - DoD Network Information Center 150.0.2.0/24 AS9730 BHARTITELESONIC-AS-IN-AP Bharti Telesonic Ltd 150.0.3.0/24 AS9730 BHARTITELESONIC-AS-IN-AP Bharti Telesonic Ltd 150.0.11.0/24 AS9730 BHARTITELESONIC-AS-IN-AP Bharti Telesonic Ltd 158.222.5.0/24 AS21580 DIRCON - Direct Connect 158.222.70.0/23 AS6137 SISNA - SISNA, Inc. 158.222.72.0/23 AS6137 SISNA - SISNA, Inc. 158.222.224.0/20 AS19864 O1COMM - O1 COMMUNICATIONS 158.222.224.0/22 AS19864 O1COMM - O1 COMMUNICATIONS 158.222.229.0/24 AS19864 O1COMM - O1 COMMUNICATIONS 163.142.0.0/16 AS2500 WIDE-BB WIDE Project 168.253.0.0/16 AS13649 ASN-VINS - ViaWest 168.253.0.0/21 AS13649 ASN-VINS - ViaWest 172.7.0.0/24 AS28175 172.10.1.0/30 AS18305 POSNET POSDATA Co.,Ltd 178.0.0.0/16 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 178.1.0.0/21 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 178.1.24.0/24 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 192.9.0.0/16 AS11479 BRM-SUN-AS - Sun Microsystems, Inc 192.9.200.0/24 AS3602 AS3602-RTI - Rogers Telecom Inc. 192.64.85.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.69.107.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.69.108.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.69.177.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.70.164.0/24 AS25689 NRCNET-AS - National Research Council of Canada 192.96.37.0/24 AS10474 NETACTIVE 192.96.135.0/24 AS2018 TENET-1 192.96.136.0/23 AS2018 TENET-1 192.96.141.0/24 AS2018 TENET-1 192.96.143.0/24 AS2018 TENET-1 192.96.145.0/24 AS2018 TENET-1 192.96.177.0/24 AS6083 POSIX-AFRICA 192.101.45.0/24 AS2905 TICSA-ASN 192.101.46.0/24 AS6503 Avantel, S.A. 192.101.64.0/21 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 192.101.70.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 192.101.71.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 192.101.72.0/24 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 192.101.74.0/24 AS1239 SPRINTLINK - Sprint 192.124.248.0/23 AS680 DFN-IP service G-WiN 192.124.252.0/22 AS680 DFN-IP service G-WiN 192.131.233.0/24 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 192.132.58.0/24 AS20141 QUALITYTECH-SUW-300 - Quality Technology Services, LLC. 192.133.6.0/24 AS10282 ORANGE-BUSINESS-SERVICES-CEEUR Orange Business Services (formerly Equant) AS for CEEUR 192.153.144.0/21 AS27064 DDN-ASNBLK1 - DoD Network Information Center 192.154.32.0/19 AS81 NCREN - MCNC 192.188.208.0/20 AS27064 DDN-ASNBLK1 - DoD Network Information Center 193.33.148.0/23 AS30890 EVOLVA Evolva Telecom 196.6.108.0/24 AS5713 SAIX-NET 196.10.119.0/24 AS2018 TENET-1 196.10.122.0/23 AS2018 TENET-1 196.10.251.0/24 AS2018 TENET-1 196.10.252.0/23 AS2018 TENET-1 196.10.254.0/24 AS2018 TENET-1 196.13.101.0/24 AS2018 TENET-1 196.13.102.0/23 AS2018 TENET-1 196.13.104.0/24 AS2018 TENET-1 196.13.121.0/24 AS2018 TENET-1 196.13.125.0/24 AS2018 TENET-1 196.13.126.0/24 AS2018 TENET-1 196.13.169.0/24 AS2018 TENET-1 196.13.174.0/23 AS2018 TENET-1 196.13.176.0/21 AS2018 TENET-1 196.13.192.0/22 AS2018 TENET-1 196.13.196.0/24 AS2018 TENET-1 196.202.224.0/21 AS8818 TELE Greenland Autonomous System 198.1.2.0/24 AS4761 INDOSAT-INP-AP INDOSAT Internet Network Provider 198.23.26.0/24 AS4390 BELLATLANTIC-COM - Bell Atlantic, Inc. 198.54.82.0/24 AS2018 TENET-1 198.54.92.0/24 AS2018 TENET-1 198.54.222.0/24 AS2018 TENET-1 198.73.210.0/24 AS21570 ACI-1 - Accelerated Connections Inc. 198.97.72.0/21 AS27064 DDN-ASNBLK1 - DoD Network Information Center 198.97.96.0/19 AS27064 DDN-ASNBLK1 - DoD Network Information Center 198.97.240.0/20 AS27064 DDN-ASNBLK1 - DoD Network Information Center 198.135.236.0/24 AS4358 XNET - XNet Information Systems, Inc. 198.161.87.0/24 AS6539 GT-BELL - Bell Canada 198.161.92.0/24 AS6539 GT-BELL - Bell Canada 198.167.0.0/16 AS7456 INTERHOP - Interhop Network SERVICES Inc. 198.168.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 198.169.0.0/16 AS803 SASKTEL - Saskatchewan Telecommunications 198.180.198.0/24 AS23715 SEOUL-INTGW-GXS-AP Global Exchange Services 199.5.242.0/24 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 199.10.0.0/16 AS27064 DDN-ASNBLK1 - DoD Network Information Center 199.19.0.0/24 AS3848 WORLDLINX-2 - WorldLinx Telecommunications, Inc. 199.114.0.0/21 AS27064 DDN-ASNBLK1 - DoD Network Information Center 199.114.128.0/18 AS27064 DDN-ASNBLK1 - DoD Network Information Center 199.114.130.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.131.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.132.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.134.0/24 AS3541 ITSDN-U4 - DoD Network Information Center 199.114.136.0/24 AS27044 DDN-ASNBLK1 - DoD Network Information Center 199.114.138.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.140.0/24 AS3544 ITSDN-U7 - DoD Network Information Center 199.114.142.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.144.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.148.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.150.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.152.0/24 AS27033 DDN-ASNBLK1 - DoD Network Information Center 199.114.153.0/24 AS27034 DDN-ASNBLK1 - DoD Network Information Center 199.114.154.0/24 AS1733 CENTAF-SWA - 754th Electronic Systems Group 199.114.156.0/24 AS1733 CENTAF-SWA - 754th Electronic Systems Group 199.114.160.0/24 AS1733 CENTAF-SWA - 754th Electronic Systems Group 199.121.0.0/16 AS27064 DDN-ASNBLK1 - DoD Network Information Center 199.123.0.0/18 AS27064 DDN-ASNBLK1 - DoD Network Information Center 199.123.16.0/20 AS27064 DDN-ASNBLK1 - DoD Network Information Center 199.123.80.0/21 AS27064 DDN-ASNBLK1 - DoD Network Information Center 199.189.32.0/19 AS7332 IQUEST-AS - IQuest Internet 199.202.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 199.202.216.0/21 AS577 BACOM - Bell Canada 199.246.116.0/24 AS813 UUNET-CANADA - MCI Communications Services, Inc. d/b/a Verizon Business 202.6.176.0/20 AS24316 202.58.113.0/24 AS19161 INNOCOM-TELECOM - INNOCOM TELECOM 202.73.144.0/20 AS4788 TMNET-AS-AP TM Net, Internet Service Provider 202.80.192.0/20 AS2706 HKSUPER-HK-AP Pacific Internet (Hong Kong) Limited 202.86.252.0/22 AS4748 RESOLINK-AS-AP Resources Link Network Limited 202.86.252.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.253.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.254.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.255.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.94.70.0/24 AS2764 AAPT AAPT Limited 202.122.120.0/21 AS17494 BTTB-AS-AP Telecom Operator & Internet Service Provider as well 202.124.195.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.133.70.0/24 AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited 202.133.73.0/24 AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited 202.136.254.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.136.255.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.140.160.0/24 AS4841 202.140.161.0/24 AS4841 202.140.162.0/24 AS4841 202.140.163.0/24 AS4841 202.140.164.0/24 AS4841 202.140.165.0/24 AS4841 202.140.166.0/24 AS4841 202.140.167.0/24 AS4841 202.140.168.0/24 AS4841 202.140.169.0/24 AS4841 202.140.170.0/24 AS4841 202.140.171.0/24 AS4841 202.140.172.0/24 AS4841 202.140.173.0/24 AS4841 202.140.174.0/24 AS4841 202.140.175.0/24 AS4841 202.140.180.0/24 AS7540 HKCIX-AS-AP HongKong Commercial Internet Exchange 202.140.181.0/24 AS7540 HKCIX-AS-AP HongKong Commercial Internet Exchange 202.140.182.0/24 AS7540 HKCIX-AS-AP HongKong Commercial Internet Exchange 202.150.227.0/24 AS17727 NAPINFO-AS-AP PT. NAP Info Lintas Nusa 202.181.32.0/24 AS4645 ASN-HKNET-AP HKNet Co. Ltd 203.12.45.0/24 AS4854 NETSPACE-AS-AP Netspace Online Systems 203.62.0.0/17 AS7575 AARNET-AS-AP Australian Academic and Reasearch Network (AARNet) 203.78.48.0/20 AS9299 IPG-AS-AP Philippine Long Distance Telephone Company 203.89.139.0/24 AS17911 BRAINPK-AS-AP Brain Telecommunication Ltd. 203.111.192.0/20 AS7473 SINGTEL-AS-AP Singapore Telecommunications Ltd 203.112.111.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.113.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.114.0/24 AS4802 ASN-IINET iiNet Limited 203.112.116.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.117.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.118.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.119.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.120.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.121.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.127.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.128.128.0/19 AS4134 CHINANET-BACKBONE No.31,Jin-rong Street 203.128.128.0/24 AS23849 CNNIC-NET263-AP Beijing Capital-online science development Co.,Ltd. 203.152.154.0/23 AS9583 SIFY-AS-IN Sify Limited 204.9.216.0/23 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 204.9.218.0/23 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 204.13.140.0/22 AS7270 NET2PHONE - Net2Phone Corp. 204.13.140.0/24 AS7270 NET2PHONE - Net2Phone Corp. 204.13.141.0/24 AS7270 NET2PHONE - Net2Phone Corp. 204.13.142.0/24 AS7270 NET2PHONE - Net2Phone Corp. 204.13.143.0/24 AS7270 NET2PHONE - Net2Phone Corp. 204.13.184.0/23 AS35967 204.13.186.0/23 AS35967 204.13.186.0/24 AS35967 204.13.187.0/24 AS35967 204.19.14.0/23 AS577 BACOM - Bell Canada 204.89.214.0/24 AS4323 TWTC - tw telecom holdings, inc. 204.138.167.0/24 AS18990 AIRBAND-DALLAS - Airband Communications, Inc 205.150.0.0/15 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 205.189.134.0/24 AS11814 CYBERSURF - Cybersurf Inc. 205.210.145.0/24 AS11814 CYBERSURF - Cybersurf Inc. 206.180.240.0/20 AS12083 KNOLOGY-NET - Knology Holdings 207.174.0.0/16 AS13790 INTERNAP-BLK3 - Internap Network Services Corporation 207.174.131.0/24 AS30715 NETRACK - Netrack, Inc. 207.174.132.0/23 AS30715 NETRACK - Netrack, Inc. 207.174.151.0/24 AS11500 PEAKPEAK - Peak to Peak Internet 207.174.152.0/22 AS30715 NETRACK - Netrack, Inc. 207.174.158.0/24 AS11500 PEAKPEAK - Peak to Peak Internet 207.174.177.0/24 AS11500 PEAKPEAK - Peak to Peak Internet 207.174.178.0/24 AS11500 PEAKPEAK - Peak to Peak Internet 207.174.182.0/24 AS29831 FONENET - FONE NET, LLC 207.174.188.0/22 AS30715 NETRACK - Netrack, Inc. 207.174.192.0/24 AS29831 FONENET - FONE NET, LLC 207.174.200.0/24 AS22658 EARTHNET - Earthnet, Inc. 207.174.248.0/21 AS6653 PRIVATEI - privateI, LLC 207.231.96.0/19 AS11194 NUNETPA - NuNet Inc. 209.54.123.0/24 AS6062 NETPLEX - NETPLEX 209.54.240.0/21 AS10887 BPSI-AS - BPSI Internet Services 209.74.96.0/19 AS10912 INTERNAP-BLK - Internap Network Services Corporation 209.140.90.0/24 AS14461 NTSL - NET SOLUTIONS 209.141.48.0/22 AS14461 NTSL - NET SOLUTIONS 209.145.192.0/18 AS3043 AMPHIB-AS - Amphibian Media Corporation 209.177.93.0/24 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 209.222.5.0/24 AS26699 PSI-CT - Printing For Systems Inc 209.222.6.0/24 AS26699 PSI-CT - Printing For Systems Inc 210.5.128.0/20 AS4837 CHINA169-BACKBONE CNCGROUP China169 Backbone 216.37.114.0/23 AS3549 GBLX Global Crossing Ltd. 216.99.20.0/24 AS3356 LEVEL3 Level 3 Communications 216.172.198.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 216.172.199.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 216.240.240.0/24 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 216.240.241.0/24 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 216.240.242.0/24 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 216.251.207.0/24 AS1239 SPRINTLINK - Sprint 217.78.71.0/24 AS12491 IPPLANET-AS IPPlanet 217.78.72.0/24 AS12491 IPPLANET-AS IPPlanet 217.78.73.0/24 AS12491 IPPLANET-AS IPPlanet Please see http://www.cidr-report.org for the full report ------------------------------------ Copies of this report are mailed to: nanog at merit.edu eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From cidr-report at potaroo.net Fri May 8 07:00:31 2009 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 8 May 2009 22:00:31 +1000 (EST) Subject: BGP Update Report Message-ID: <200905081200.n48C0VOv031741@wattle.apnic.net> BGP Update Report Interval: 06-Apr-09 -to- 07-May-09 (32 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS6389 392748 4.1% 90.1 -- BELLSOUTH-NET-BLK - BellSouth.net Inc. 2 - AS3130 137093 1.4% 531.4 -- RGNET-3130 RGnet/PSGnet 3 - AS2386 116477 1.2% 89.6 -- INS-AS - AT&T Data Communications Services 4 - AS8452 112790 1.2% 81.0 -- TEDATA TEDATA 5 - AS6478 86719 0.9% 61.4 -- ATT-INTERNET3 - AT&T WorldNet Services 6 - AS17488 80855 0.8% 51.0 -- HATHWAY-NET-AP Hathway IP Over Cable Internet 7 - AS11492 75669 0.8% 61.4 -- CABLEONE - CABLE ONE, INC. 8 - AS7018 66390 0.7% 43.7 -- ATT-INTERNET4 - AT&T WorldNet Services 9 - AS4323 63847 0.7% 14.8 -- TWTC - tw telecom holdings, inc. 10 - AS19262 59691 0.6% 60.1 -- VZGNI-TRANSIT - Verizon Internet Services Inc. 11 - AS29049 57957 0.6% 179.4 -- DELTA-TELECOM-AS Delta Telecom LTD. 12 - AS9829 55044 0.6% 84.4 -- BSNL-NIB National Internet Backbone 13 - AS35805 54897 0.6% 162.4 -- UTG-AS United Telecom AS 14 - AS21491 54046 0.6% 1743.4 -- UTL-ON-LINE UTL On-line is RF broadband ISP in Uganda - Africa 15 - AS20115 53058 0.6% 31.2 -- CHARTER-NET-HKY-NC - Charter Communications 16 - AS10796 52523 0.5% 101.6 -- SCRR-10796 - Road Runner HoldCo LLC 17 - AS4755 48911 0.5% 39.0 -- TATACOMM-AS TATA Communications formerly VSNL is Leading ISP 18 - AS8151 45529 0.5% 31.2 -- Uninet S.A. de C.V. 19 - AS12978 37903 0.4% 210.6 -- DOGAN-ONLINE Dogan Iletisim Elektronik Servis Hizmetleri AS 20 - AS33776 36400 0.4% 311.1 -- STARCOMMS-ASN TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS15045 28705 0.3% 9568.3 -- KITTELSON - KITTELSON AND ASSOCIATES, INC. 2 - AS40967 4229 0.0% 4229.0 -- CSF-AS CSF Computersoftware fuer Fachanwendungen GmbH 3 - AS46653 12377 0.1% 4125.7 -- FREDRIKSON---BYRON - Fredrikson & Byron, P.A. 4 - AS32398 20650 0.2% 3441.7 -- REALNET-ASN-1 5 - AS13153 2544 0.0% 2544.0 -- ONEWORLD OneWorld S.A. 6 - AS29229 2444 0.0% 2444.0 -- ASDA-AS Assotiation for the Development of West Athens 7 - AS13325 18957 0.2% 2369.6 -- STOMI - State of Michigan, DMB-CNOC 8 - AS8499 2171 0.0% 2171.0 -- Space Hellas Network Operation Center (NOC) 9 - AS30423 4073 0.0% 2036.5 -- AMEDI-3-ASN1 - Amedisys, Inc. 10 - AS28256 1952 0.0% 1952.0 -- 11 - AS47640 5811 0.1% 1937.0 -- TRICOMPAS Tricomp Sp. z. o. o. 12 - AS5050 25297 0.3% 1806.9 -- PSC-EXT - Pittsburgh Supercomputing Center 13 - AS21491 54046 0.6% 1743.4 -- UTL-ON-LINE UTL On-line is RF broadband ISP in Uganda - Africa 14 - AS46328 15393 0.2% 1710.3 -- PTCNEBRASKA - PIERCE TELEPHONE COMPANY, INCORPORATED 15 - AS28953 2325 0.0% 1162.5 -- PIRAEUSBANK Greek banking institution 16 - AS14223 2323 0.0% 1161.5 -- NYSDOH - New York State Department of Health 17 - AS48881 1082 0.0% 1082.0 -- DATA-NODE-AS SC Data Node SRL 18 - AS47299 1080 0.0% 1080.0 -- DRSA-AS Dlugie Rozmowy S.A. 19 - AS34321 2081 0.0% 1040.5 -- LDK-AS Institute of strategic marks, Kiev, Ukraine 20 - AS19398 2040 0.0% 1020.0 -- INDENET - Indenet.net TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 72.23.246.0/24 24848 0.2% AS5050 -- PSC-EXT - Pittsburgh Supercomputing Center 2 - 41.204.2.0/24 20294 0.2% AS32398 -- REALNET-ASN-1 3 - 199.45.13.0/24 12357 0.1% AS46653 -- FREDRIKSON---BYRON - Fredrikson & Byron, P.A. 4 - 192.12.120.0/24 10388 0.1% AS5691 -- MITRE-AS-5 - The MITRE Corporation 5 - 63.103.104.0/22 9975 0.1% AS15045 -- KITTELSON - KITTELSON AND ASSOCIATES, INC. 6 - 63.103.108.0/23 9975 0.1% AS15045 -- KITTELSON - KITTELSON AND ASSOCIATES, INC. 7 - 63.103.110.0/24 8755 0.1% AS15045 -- KITTELSON - KITTELSON AND ASSOCIATES, INC. 8 - 123.49.152.0/24 7059 0.1% AS18118 -- CITICNET-AP CITIC Networks Management Co.,Ltd. 9 - 195.96.69.0/24 6592 0.1% AS8225 -- ASTELIT-MSK-AS Astelit Autonomous System 11 - 123.49.144.0/21 6305 0.1% AS18118 -- CITICNET-AP CITIC Networks Management Co.,Ltd. 12 - 94.124.16.0/21 5723 0.1% AS47640 -- TRICOMPAS Tricomp Sp. z. o. o. 13 - 193.201.184.0/21 5630 0.1% AS25546 -- BROOKLANDCOMP-AS Brookland Computer Services 14 - 81.199.18.0/24 5588 0.1% AS21491 -- UTL-ON-LINE UTL On-line is RF broadband ISP in Uganda - Africa 15 - 81.199.16.0/22 5269 0.1% AS21491 -- UTL-ON-LINE UTL On-line is RF broadband ISP in Uganda - Africa 16 - 81.199.23.0/24 5262 0.1% AS21491 -- UTL-ON-LINE UTL On-line is RF broadband ISP in Uganda - Africa 17 - 81.199.22.0/24 5207 0.1% AS21491 -- UTL-ON-LINE UTL On-line is RF broadband ISP in Uganda - Africa 18 - 196.0.0.0/16 5182 0.1% AS21491 -- UTL-ON-LINE UTL On-line is RF broadband ISP in Uganda - Africa 19 - 81.199.28.0/22 5144 0.1% AS21491 -- UTL-ON-LINE UTL On-line is RF broadband ISP in Uganda - Africa 20 - 192.35.129.0/24 5116 0.1% AS6629 -- NOAA-AS - NOAA 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 frnkblk at iname.com Fri May 8 07:44:04 2009 From: frnkblk at iname.com (Frank Bulk) Date: Fri, 8 May 2009 07:44:04 -0500 Subject: Checking bogon status of new address space In-Reply-To: <20090508053336.GC7171@captain.bridge.anchor.net.au> References: <20090508053336.GC7171@captain.bridge.anchor.net.au> Message-ID: Please set up a pingable IP address for each new netblock and post it to NANOG with a request to have us ping it. It's not automated, but it's a good start. Frank -----Original Message----- From: Oliver Hookins [mailto:oliver.hookins at anchor.com.au] Sent: Friday, May 08, 2009 12:34 AM To: nanog at nanog.org Subject: Checking bogon status of new address space Hi, my company has just been allocated some new IPv4 address space, and I want to do some sort of automated testing to find out any ASs out there that haven't removed the /8 it's on from their bogon list (the allocation to our local registry only occurred in November last year). Has anybody attempted to do this? It is worth bothering? Currently I'm considering pulling out all the endpoint ASs out of the BGP table, finding at least one subnet for each of them and attempting to ping or reach other common ports on a single IP for each AS from our currently working address space, and then the new address space and comparing results. -- Regards, Oliver Hookins Anchor Systems From marcoh at marcoh.net Fri May 8 07:57:31 2009 From: marcoh at marcoh.net (Marco Hogewoning) Date: Fri, 8 May 2009 14:57:31 +0200 Subject: Checking bogon status of new address space In-Reply-To: References: <20090508053336.GC7171@captain.bridge.anchor.net.au> Message-ID: <5A2D8C9C-16F4-41E5-A89E-841CA1E12532@marcoh.net> On May 8, 2009, at 2:44 PM, Frank Bulk wrote: > Please set up a pingable IP address for each new netblock and post > it to > NANOG with a request to have us ping it. It's not automated, but > it's a > good start. > > Frank You might also want to have a look at the RIPE NCC's beacon stuff: http://www.ripe.net/ris/docs/beacon.html I do recall them to use this mechanism to test new iana assignments (/ 8) they got. Grtx, Marco From jlewis at lewis.org Fri May 8 07:59:08 2009 From: jlewis at lewis.org (Jon Lewis) Date: Fri, 8 May 2009 08:59:08 -0400 (EDT) Subject: Checking bogon status of new address space In-Reply-To: <20090508053336.GC7171@captain.bridge.anchor.net.au> References: <20090508053336.GC7171@captain.bridge.anchor.net.au> Message-ID: On Fri, 8 May 2009, Oliver Hookins wrote: > my company has just been allocated some new IPv4 address space, and I want > to do some sort of automated testing to find out any ASs out there that > haven't removed the /8 it's on from their bogon list (the allocation to our > local registry only occurred in November last year). > > Has anybody attempted to do this? I don't think so. If I'd done this a little more than 6 years ago, I'd remember it, wouldn't I? > It is worth bothering? Depends on what you're going to use the IPs for. If you did just a bit of googling, you'd find all sorts of info on this topic. ---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From mysidia at gmail.com Fri May 8 08:02:14 2009 From: mysidia at gmail.com (James Hess) Date: Fri, 8 May 2009 08:02:14 -0500 Subject: UCEProtect Level 3 In-Reply-To: <20090507161041.f1711126.darcy@druid.net> References: <4A032999.8000707@rapidlink.com> <289601c9cf43$ae519370$0af4ba50$@net> <20090507161041.f1711126.darcy@druid.net> Message-ID: <6eb799ab0905080602x2c22e707o430fda78087c9845@mail.gmail.com> On Thu, May 7, 2009 at 3:10 PM, D'Arcy J.M. Cain wrote: > It is. ?I understand what they are trying to do but we were cut off > from some places because someone else in the huge upstream we are with > did something that appeared to be spam. ?It's too broad of a brush. It's not the tool or list itself, but the horrible manner in which someone chose to use the list. Those places who chose to perform cut offs blindly based on the listing are responsible, and have their own users to answer to.. The UceProtect L3 website displays a very prominent admission of guilt (they are open about their listing criteria): "This blacklist has been created for HARDLINERS. It can, and probably will cause collateral damage to innocent users when used to block email." So there should be little ignorance on the matter by users. The value of the list is heuristic, for scoring, e.g. SpamAssassin score, and use of the list should be combined with an informed decision, before blocking mail from a sender based on it. Under those conditions, lists like that can be quite useful. If you try hard enough, you can find virus scanners that identify clean system-critical files as possible malware, and firewalls that identify normal surfers as evil hackers... If you have that software and didn't do the research, that's your problem. If you have that software and set it to automatically delete files, or if you have the overzealous firewall and you wrote a script to IPban based on firewall log, the firewall is not responsible for _that_ problem. The list/tool provider is only an accomplice, to the extent that they misinform you, or encourage you to use the list/tool in a poor way given the tool's limitations.... -- -J From sronan at fattoc.com Fri May 8 08:09:59 2009 From: sronan at fattoc.com (Shane Ronan) Date: Fri, 8 May 2009 09:09:59 -0400 Subject: Network performance monitoring tools In-Reply-To: <4A03E5DA.5020703@bogus.com> References: <10319344.121691241706918947.JavaMail.weblogic@epml14> <4A03E5DA.5020703@bogus.com> Message-ID: <5C38D45D-DCC8-4FF7-B366-0EAF10AAC9B2@fattoc.com> OpenNMS has a good tool called Strafeping that is based on Smokeping that is integrated into the overall system. On May 8, 2009, at 3:57 AM, Joel Jaeggli wrote: > Jitter (e.g. variability in one way or rtt) smokeping is rather good > at > measuring... > > The question is do you want to instrument the phenomena through active > measurement as smokeping is doing or do you have some application > (e.g. > streaming media as an example) that you'd like to instrument because > the > later may be more d From wnagele at ripe.net Fri May 8 08:26:39 2009 From: wnagele at ripe.net (Wolfgang Nagele) Date: Fri, 08 May 2009 15:26:39 +0200 Subject: Checking bogon status of new address space In-Reply-To: <5A2D8C9C-16F4-41E5-A89E-841CA1E12532@marcoh.net> References: <20090508053336.GC7171@captain.bridge.anchor.net.au> <5A2D8C9C-16F4-41E5-A89E-841CA1E12532@marcoh.net> Message-ID: <4A04330F.1010801@ripe.net> Hi, Yes, we do this for all new /8 issued to RIR's. You can find the details here: http://www.ris.ripe.net/debogon/ Regards, Wolfgang Marco Hogewoning wrote: > > On May 8, 2009, at 2:44 PM, Frank Bulk wrote: > >> Please set up a pingable IP address for each new netblock and post it to >> NANOG with a request to have us ping it. It's not automated, but it's a >> good start. >> >> Frank > > You might also want to have a look at the RIPE NCC's beacon stuff: > > http://www.ripe.net/ris/docs/beacon.html > > I do recall them to use this mechanism to test new iana assignments (/8) > they got. > > Grtx, > > Marco > > From c.v.wolfhausen at spamkiller.uceprotect.net Fri May 8 08:31:51 2009 From: c.v.wolfhausen at spamkiller.uceprotect.net (Claus v. Wolfhausen) Date: Fri, 8 May 2009 15:31:51 +0200 (CEST) Subject: UCEProtect Level 3 Message-ID: <4A043447.000013.01060@PROMETHEUS> Why do you believe people which are using Level 3 are not aware what it is doing? We have given a very detailed description how it works and also recommendations how to use it. See: http://www.uceprotect.net/en/index.php?m=3&s=5 Additionaly we are writing BIG FAT warnings also into the downloadable zonefile See: http://wget-mirrors.uceprotect.net/rbldnsd-all/dnsbl-3.uceprotect.net gz As you can see we don't make a secret out of what it is: A boycottlist. Therefore we have to assume that those which are using it for blocking do exactly know what they are doing. It clearly depends on where you are and where you expect mail from, if you can or cannot use it for blocking.According to Al Iverson's stats (which didn't get updated since summer 2008) it looks like it is not doing so much false positives if used in North America.See: http://stats.dnsbl.com/uce3 html If used in Germany, Austria or Switzerland it even looks better: See our stats: http://stats.uceprotect.net/week.html Of course it will almost always be necessary to use a whitelist in combination with ASN-Blocking. YMMV Claus von Wolfhausen UCEPROTECT-Network -----Original Message----- From: Raleigh Apple [mailto:rapple at rapidlink.com] Sent: Thursday, May 07, 2009 1:34 PM To: nanog at nanog.org Subject: UCEProtect Level 3 Is anyone else out there aware that the UCEProtect Level 3 email blacklist blocks entire AS? r From mliotta at r337.com Fri May 8 08:46:38 2009 From: mliotta at r337.com (Matt Liotta) Date: Fri, 8 May 2009 09:46:38 -0400 Subject: UCEProtect Level 3 In-Reply-To: <4A043447.000013.01060@PROMETHEUS> References: <4A043447.000013.01060@PROMETHEUS> Message-ID: <39DD8490-DC10-4BB8-BE98-73A7935D6E86@r337.com> On May 8, 2009, at 9:31 AM, Claus v. Wolfhausen wrote: > Why do you believe people which are using Level 3 are not aware what > it is > doing? I am guessing the emails from uninformed victims wondering why their mail isn't getting through. Vigilantes always start out with the right intentions and then take it too far. One day you are going to filter the wrong AS. -Matt From ka at pacific.net Fri May 8 08:54:17 2009 From: ka at pacific.net (Ken A) Date: Fri, 08 May 2009 08:54:17 -0500 Subject: UCEProtect Level 3 In-Reply-To: References: <4A032999.8000707@rapidlink.com> Message-ID: <4A043989.5040101@pacific.net> Suresh Ramasubramanian wrote: > On Fri, May 8, 2009 at 12:04 AM, Raleigh Apple wrote: >> Is anyone else out there aware that the UCEProtect Level 3 email blacklist >> blocks entire AS? >> > > Is there anyone out there aware of any significant (or larger than > 'man and his dog on a DSL') mail provider using UCEPROTECT? > dnsbl-1.uceprotect.net and dnsbl-2.uceprotect.net work good with SpamAssassin (scoring system). http://stats.dnsbl.com/ keeps some ham/spam stats on various lists. ymmv. Problems arise when 'admin' gets hands on inexpensive anti-spam appliance that makes enabling blacklists a checkbox on a web form with little or no documentation about each list. Ken -- Ken Anderson Pacific Internet - http://www.pacific.net From john-nanog at johnpeach.com Fri May 8 08:56:33 2009 From: john-nanog at johnpeach.com (John Peach) Date: Fri, 08 May 2009 09:56:33 -0400 Subject: UCEProtect Level 3 In-Reply-To: <39DD8490-DC10-4BB8-BE98-73A7935D6E86@r337.com> References: <4A043447.000013.01060@PROMETHEUS> <39DD8490-DC10-4BB8-BE98-73A7935D6E86@r337.com> Message-ID: <20090508095633.0259b629@jpeach-desktop.1425mad.mountsinai.org> On Fri, 8 May 2009 09:46:38 -0400 "Matt Liotta" wrote: > > On May 8, 2009, at 9:31 AM, Claus v. Wolfhausen wrote: > > > Why do you believe people which are using Level 3 are not aware > > what it is > > doing? > > I am guessing the emails from uninformed victims wondering why their > mail isn't getting through. > > Vigilantes always start out with the right intentions and then take > it too far. One day you are going to filter the wrong AS. You are blaming the wrong people. It is very clear on their website that this list should not be used for blocking. It states that there will be FPs and that you should use it as part of an overall scoring system. If you must blame someone, blame the idiots who use it to block email. -- John From karnaugh at karnaugh.za.net Fri May 8 09:06:09 2009 From: karnaugh at karnaugh.za.net (Colin Alston) Date: Fri, 08 May 2009 16:06:09 +0200 Subject: UCEProtect Level 3 In-Reply-To: <4A043447.000013.01060@PROMETHEUS> References: <4A043447.000013.01060@PROMETHEUS> Message-ID: <4A043C51.6070203@karnaugh.za.net> On 2009/05/08 03:31 PM Claus v. Wolfhausen wrote: > Why do you believe people which are using Level 3 are not aware what it is > doing? The real problem is it's not just UCEProtect. http://www.senderbase.org/ I see too many IronPort's at ISP's using these reputation filters and blocking anyone who accidentally got infected with a virus for weeks on end well after the problem is solved. From c.v.wolfhausen at spamkiller.uceprotect.net Fri May 8 09:11:38 2009 From: c.v.wolfhausen at spamkiller.uceprotect.net (Claus v. Wolfhausen) Date: Fri, 8 May 2009 16:11:38 +0200 (CEST) Subject: UCEProtect Level 3 References: <4A032999.8000707@rapidlink.com> <289601c9cf43$ae519370$0af4ba50$@net> <20090507161041.f1711126.darcy@druid.net> <6eb799ab0905080602x2c22e707o430fda78087c9845@mail.gmail.com> Message-ID: <4A043D8F.000021.01060@PROMETHEUS> James Hess wrote: >It's not the tool or list itself, but the horrible manner in which >someone chose to use the list. Exactly. We can't be responsible for what our users are doing. >Those places who chose to perform cut offs blindly based on the >listing are responsible, and have their own users to answer to.. The >UceProtect L3 website displays a very prominent admission of guilt >(they are open about their listing criteria): >"This blacklist has been created for HARDLINERS. It can, and probably >will cause collateral damage to innocent users when used to block >email." >So there should be little ignorance on the matter by users. The >value of the list is heuristic, for scoring, e.g. SpamAssassin score, >and use of the list should be combined with an informed decision, >before blocking mail from a sender based on it. Under those >conditions, lists like that can be quite useful. I will give you some more examples how it can be very useful: You can use it to block emails from systems with no PTR or Generic PTR's. You can use it to block emails from systems having non FQDN HELO/EHLO You can use it to block emails from systems which are also listed in very aggressive point blocklists (Single IP blocklists). You can use it to do excessive greylistings (i recommend at least 2 hours) to find out if the system will show up on other blocklists in the meantime. As you can see the only limit is your imagination. --- Claus von Wolfhausen Technical Director UCEPROTECT-Network http://www.uceprotect.net From steve+nanog at sendithere.com Fri May 8 09:44:58 2009 From: steve+nanog at sendithere.com (Steve Dalberg) Date: Fri, 8 May 2009 07:44:58 -0700 Subject: Checking bogon status of new address space In-Reply-To: <20090508053336.GC7171@captain.bridge.anchor.net.au> References: <20090508053336.GC7171@captain.bridge.anchor.net.au> Message-ID: Having recently received some de-bogon'ed addressing in or about this March, I can tell you that the one problem I had was people that had not updated their Bind Bogon filters ( http://www.cymru.com/Documents/secure-bind-template.html) and so were not responding to requests from our address space, so we just moved our dns cache boxes back to our older Level3 address space. Took a while to figure that one out though. Steve 2009/5/7 Oliver Hookins > Hi, > > my company has just been allocated some new IPv4 address space, and I want > to do some sort of automated testing to find out any ASs out there that > haven't removed the /8 it's on from their bogon list (the allocation to our > local registry only occurred in November last year). > > Has anybody attempted to do this? It is worth bothering? Currently I'm > considering pulling out all the endpoint ASs out of the BGP table, finding > at least one subnet for each of them and attempting to ping or reach other > common ports on a single IP for each AS from our currently working > address space, and then the new address space and comparing results. > > -- > Regards, > Oliver Hookins > Anchor Systems > > From c.v.wolfhausen at spamkiller.uceprotect.net Fri May 8 10:30:18 2009 From: c.v.wolfhausen at spamkiller.uceprotect.net (Claus v. Wolfhausen) Date: Fri, 8 May 2009 17:30:18 +0200 (CEST) Subject: Responsible blocklist usage Message-ID: <4A045005.000045.01060@PROMETHEUS> Seriously if you want to stop most of the spam with only a very minimal risk of false positives you will have to use a combination of list, because there is really *NO BLOCKLIST* which always does 0 False Positives if measured against an mixed but real mailflow: See: http://stats.uceprotect.net What you see there is the the real mailflow of those UCEPROTECT-customers that have freely chosen to select "Transmit Statistics and nominate Spammers in their Appliances. Actually 45 Systems are running the upcoming Release V4.1 in Betatest and what you see there is their real traffic. What you can't see yet is the traffic from all other customers that are still running the latest official Release V4.07 This is how we are counting Spamtrap hits and also False positives: All Lists are queried at every connection after RCPT TO: Spamtrap hits (Displayed in green): Every mail send to a spamtrap is counted as hit for those blocklists that reports the IP / domain as listed. False positives (Displayed in red): Every mail send to an existing recipient is counted as false positive for those blocklists that report the IP / domain as listed and the sender is in the recipients automatic or manual whitelist. Counters for the nonexisting (virtual) zone: uceprotect.combined are counted ONE only according to the description above if any of the 4 real existing dnsbl-*.uceprotect.net zones would report listed. As you can see the most accurate and effective single blocklist in our comparison is cbl.abuseat.org but even it would have rejected 14 of 8475031 HAM's last week while catching 73.3% spam. That is excellent for a single blocklist, but you can get a better result if you are using following combination of lists: Delay any incoming connection which is listed at dnsbl-0.uceprotect.net aka UCEPROTECT Level 0 with a tempfail (450) after RCPT TO. This is important because Level 0 is a delaylist, not a blocklist. Listings there will expire as soon as an Operator has moved them to UCEPROTECT Level 1 otherwise latest after 3 hours. Block if at least 2 of the following 8 lists are indicating "listed": bl.spamcop.net, cbl.abuseat.org, dnsbl-1.uceprotect.net, dnsbl-2.uceprotect.net, dnsbl-3.uceprotect.net, dnsbl.sorbs.net, ix.dnsbl.manitu.net and psbl.surriel.com. If you follow my instruction, you will end up with a system that has as good as no false positives and will block most of all spams. As always YMMV. -- Claus von Wolfhausen Technical Director UCEPROTECT-Network http://www.uceprotect.net From joelja at bogus.com Fri May 8 10:46:55 2009 From: joelja at bogus.com (Joel Jaeggli) Date: Fri, 08 May 2009 08:46:55 -0700 Subject: Call for interested parties: Switching BOF NANOG 46 June 14-17 Message-ID: <4A0453EF.6010001@bogus.com> Greetings NANOG, We're closing in on the 1 month mark and as I see the BOF that I am trying to organize now has a slot I thought I'd see if there's anyone I haven't bugged in person who'd like to participate. In rough terms the topic is as follows. Best hopes for low cost high density routers, what feature mix can we expect from .1 to ~.5Tb/s top of the rack sized l3 switches. To expand on that idea a little bit I think subject areas might include: Where these things can be appropriately deployed How network architecture changes as a result of them The outlook for their future I am of course open to suggestions, as well. If you are a consumer of these products and you have an experience to relate (favorable bad or other) there are other's at nanog who would be interested in your experience. We are presuming that the NANOG audience is wider than simply transit backbone providers, but rather includes, CDN's and asp/content people, metro-e, consumer isp and some large enterprise users etc. If you are a switch vendor that participates at NANOG and I missed you or never connected with the right person, Don't take it personally and please drop me a line. Thanks for your consideration, and I look forward to seeing you all in Philadelphia. joel From robt at cymru.com Fri May 8 12:27:29 2009 From: robt at cymru.com (Rob Thomas) Date: Fri, 08 May 2009 12:27:29 -0500 Subject: Checking bogon status of new address space In-Reply-To: References: <20090508053336.GC7171@captain.bridge.anchor.net.au> Message-ID: <4A046B81.9010500@cymru.com> Hi, Steve. > Having recently received some de-bogon'ed addressing in or about this March, > I can tell you that the one problem I had was people that had not updated > their Bind Bogon filters ( > http://www.cymru.com/Documents/secure-bind-template.html) ... This is the primary reason we removed the static bogon lists from our Secure [BIND|IOS|BGP] Templates. My thanks to Randy Bush (and a few other folks) for the suggestion. We still have the bogon list and the dynamic bogon route-servers. Thanks, Rob. -- Rob Thomas Team Cymru http://www.team-cymru.org/ cmn_err(CEO_PANIC, "Out of coffee!"); From bicknell at ufp.org Fri May 8 12:39:55 2009 From: bicknell at ufp.org (Leo Bicknell) Date: Fri, 8 May 2009 13:39:55 -0400 Subject: Checking bogon status of new address space In-Reply-To: <4A046B81.9010500@cymru.com> References: <20090508053336.GC7171@captain.bridge.anchor.net.au> <4A046B81.9010500@cymru.com> Message-ID: <20090508173955.GA49860@ussenterprise.ufp.org> In a message written on Fri, May 08, 2009 at 12:27:29PM -0500, Rob Thomas wrote: > This is the primary reason we removed the static bogon lists from our > Secure [BIND|IOS|BGP] Templates. My thanks to Randy Bush (and a few > other folks) for the suggestion. I want to thank Team Cymru for their effort in maintaining this list over time, it's done a lot of people a lot of good. I would also like to recommend that it's time to completely update the text on http://www.cymru.com/Documents/bogon-list.html to reflect the new reality. Looking at http://www.cymru.com/Documents/bogon-bn-nonagg.txt (bogns, bit notation, not aggregated) I see there are only 39 entries in the list. Ten of these entries are martians, and should remain: 0.0.0.0/8 10.0.0.0/8 127.0.0.0/8 169.254.0.0/16 172.16.0.0/12 192.0.2.0/24 192.168.0.0/16 198.18.0.0/15 223.0.0.0/8 224.0.0.0/3 The other 29 are the unallocated /8's: 1.0.0.0/8 2.0.0.0/8 5.0.0.0/8 14.0.0.0/8 23.0.0.0/8 27.0.0.0/8 31.0.0.0/8 36.0.0.0/8 37.0.0.0/8 39.0.0.0/8 42.0.0.0/8 46.0.0.0/8 49.0.0.0/8 50.0.0.0/8 100.0.0.0/8 101.0.0.0/8 102.0.0.0/8 103.0.0.0/8 104.0.0.0/8 105.0.0.0/8 106.0.0.0/8 107.0.0.0/8 175.0.0.0/8 176.0.0.0/8 177.0.0.0/8 179.0.0.0/8 181.0.0.0/8 182.0.0.0/8 185.0.0.0/8 29/256 = 11% of the available address space. My argument is, if someone is scanning you from random source addresses blocking 10% of the scan traffic is reaching a point of very little return for the effort of updating the address lists, and as we all know it is getting smaller and smaller. To that end, I believe the recommendation should be to move to a martian-only filter over the next 12-24 months. This lines up with the time frame at which all /8's are likely to be allocated. Of course the full list of unallocated /8's should still be produced for those who want it, I'm not advocating that anything go away, just that I feel like we are at the point where the value of the list is lower than the effort to maintain it for the /average/ user of the list. I think this is in-line with the removal of the static bogon filters from the secure templates and would provide better advice to people reading the document for the first time. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 825 bytes Desc: not available URL: From cscora at apnic.net Fri May 8 13:16:02 2009 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 9 May 2009 04:16:02 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <200905081816.n48IG207016979@thyme.apnic.net> This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. Daily listings are sent to bgp-stats at lists.apnic.net For historical data, please see http://thyme.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 09 May, 2009 Report Website: http://thyme.apnic.net Detailed Analysis: http://thyme.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 288037 Prefixes after maximum aggregation: 136199 Deaggregation factor: 2.11 Unique aggregates announced to Internet: 140785 Total ASes present in the Internet Routing Table: 31199 Prefixes per ASN: 9.23 Origin-only ASes present in the Internet Routing Table: 27142 Origin ASes announcing only one prefix: 13239 Transit ASes present in the Internet Routing Table: 4057 Transit-only ASes present in the Internet Routing Table: 96 Average AS path length visible in the Internet Routing Table: 3.6 Max AS path length visible: 33 Max AS path prepend of ASN (43683) 31 Prefixes from unregistered ASNs in the Routing Table: 461 Unregistered ASNs in the Routing Table: 151 Number of 32-bit ASNs allocated by the RIRs: 142 Prefixes from 32-bit ASNs in the Routing Table: 30 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 194 Number of addresses announced to Internet: 2039977920 Equivalent to 121 /8s, 151 /16s and 151 /24s Percentage of available address space announced: 55.0 Percentage of allocated address space announced: 63.7 Percentage of available address space allocated: 86.4 Percentage of address space in use by end-sites: 76.9 Total number of prefixes smaller than registry allocations: 142407 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 67704 Total APNIC prefixes after maximum aggregation: 24092 APNIC Deaggregation factor: 2.81 Prefixes being announced from the APNIC address blocks: 64376 Unique aggregates announced from the APNIC address blocks: 28909 APNIC Region origin ASes present in the Internet Routing Table: 3610 APNIC Prefixes per ASN: 17.83 APNIC Region origin ASes announcing only one prefix: 974 APNIC Region transit ASes present in the Internet Routing Table: 548 Average APNIC Region AS path length visible: 3.5 Max APNIC Region AS path length visible: 18 Number of APNIC addresses announced to Internet: 413123104 Equivalent to 24 /8s, 159 /16s and 194 /24s Percentage of available APNIC address space announced: 77.0 APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079 APNIC Address Blocks 58/8, 59/8, 60/8, 61/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 180/8, 183/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 125398 Total ARIN prefixes after maximum aggregation: 66155 ARIN Deaggregation factor: 1.90 Prefixes being announced from the ARIN address blocks: 94539 Unique aggregates announced from the ARIN address blocks: 36627 ARIN Region origin ASes present in the Internet Routing Table: 12984 ARIN Prefixes per ASN: 7.28 ARIN Region origin ASes announcing only one prefix: 5014 ARIN Region transit ASes present in the Internet Routing Table: 1264 Average ARIN Region AS path length visible: 3.3 Max ARIN Region AS path length visible: 24 Number of ARIN addresses announced to Internet: 428554240 Equivalent to 25 /8s, 139 /16s and 56 /24s Percentage of available ARIN address space announced: 82.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 ARIN Address Blocks 24/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8, 98/8, 99/8, 108/8, 173/8, 174/8, 184/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 65823 Total RIPE prefixes after maximum aggregation: 38233 RIPE Deaggregation factor: 1.72 Prefixes being announced from the RIPE address blocks: 60147 Unique aggregates announced from the RIPE address blocks: 39883 RIPE Region origin ASes present in the Internet Routing Table: 12974 RIPE Prefixes per ASN: 4.64 RIPE Region origin ASes announcing only one prefix: 6798 RIPE Region transit ASes present in the Internet Routing Table: 1959 Average RIPE Region AS path length visible: 4.0 Max RIPE Region AS path length visible: 33 Number of RIPE addresses announced to Internet: 393192480 Equivalent to 23 /8s, 111 /16s and 164 /24s Percentage of available RIPE address space announced: 83.7 RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-52223 RIPE Address Blocks 62/8, 77/8, 78/8, 79/8, 80/8, 81/8, 82/8, 83/8, 84/8, 85/8, 86/8, 87/8, 88/8, 89/8, 90/8, 91/8, 92/8, 93/8, 94/8, 95/8, 109/8, 178/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 23762 Total LACNIC prefixes after maximum aggregation: 5894 LACNIC Deaggregation factor: 4.03 Prefixes being announced from the LACNIC address blocks: 21941 Unique aggregates announced from the LACNIC address blocks: 12057 LACNIC Region origin ASes present in the Internet Routing Table: 1107 LACNIC Prefixes per ASN: 19.82 LACNIC Region origin ASes announcing only one prefix: 361 LACNIC Region transit ASes present in the Internet Routing Table: 184 Average LACNIC Region AS path length visible: 4.0 Max LACNIC Region AS path length visible: 26 Number of LACNIC addresses announced to Internet: 63068288 Equivalent to 3 /8s, 194 /16s and 88 /24s Percentage of available LACNIC address space announced: 62.7 LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247 plus ERX transfers LACNIC Address Blocks 186/8, 187/8, 189/8, 190/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 4921 Total AfriNIC prefixes after maximum aggregation: 1487 AfriNIC Deaggregation factor: 3.31 Prefixes being announced from the AfriNIC address blocks: 4562 Unique aggregates announced from the AfriNIC address blocks: 1412 AfriNIC Region origin ASes present in the Internet Routing Table: 295 AfriNIC Prefixes per ASN: 15.46 AfriNIC Region origin ASes announcing only one prefix: 92 AfriNIC Region transit ASes present in the Internet Routing Table: 58 Average AfriNIC Region AS path length visible: 3.9 Max AfriNIC Region AS path length visible: 18 Number of AfriNIC addresses announced to Internet: 11303168 Equivalent to 0 /8s, 172 /16s and 121 /24s Percentage of available AfriNIC address space announced: 33.7 AfriNIC AS Blocks 36864-37887 & ERX transfers AfriNIC Address Blocks 41/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4766 1700 6930 405 Korea Telecom (KIX) 17488 1573 127 101 Hathway IP Over Cable Interne 4755 1243 466 126 TATA Communications formerly 9583 1077 86 539 Sify Limited 4134 898 16676 373 CHINANET-BACKBONE 7545 792 166 102 TPG Internet Pty Ltd 23577 780 34 663 Korea Telecom (ATM-MPLS) 18101 756 217 32 Reliance Infocom Ltd Internet 24560 685 229 176 Bharti Airtel Ltd. 9829 654 560 18 BSNL National Internet Backbo Complete listing at http://thyme.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 4306 3653 342 bellsouth.net, inc. 209 2559 4149 604 Qwest 4323 1848 1035 373 Time Warner Telecom 1785 1758 717 139 PaeTec Communications, Inc. 20115 1631 1449 728 Charter Communications 7018 1464 5911 1014 AT&T WorldNet Services 6478 1398 309 414 AT&T Worldnet Services 2386 1264 698 911 AT&T Data Communications Serv 3356 1235 10981 469 Level 3 Communications, LLC 11492 1102 192 11 Cable One Complete listing at http://thyme.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 8452 1231 188 7 TEDATA 30890 541 88 200 Evolva Telecom 3292 455 1893 394 TDC Tele Danmark 12479 448 578 6 Uni2 Autonomous System 8866 368 110 24 Bulgarian Telecommunication C 3320 348 7082 299 Deutsche Telekom AG 3215 343 3041 108 France Telecom Transpac 3301 340 1668 304 TeliaNet Sweden 35805 338 24 4 United Telecom of Georgia 29049 317 26 3 AzerSat LLC. Complete listing at http://thyme.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 8151 1449 2848 232 UniNet S.A. de C.V. 10620 930 207 106 TVCABLE BOGOTA 22047 616 302 14 VTR PUNTO NET S.A. 7303 524 272 76 Telecom Argentina Stet-France 11830 516 294 34 Instituto Costarricense de El 28573 456 562 26 NET Servicos de Comunicao S.A 11172 443 102 72 Servicios Alestra S.A de C.V 6471 435 95 31 ENTEL CHILE S.A. 7738 397 794 28 Telecomunicacoes da Bahia S.A 3816 349 163 73 Empresa Nacional de Telecomun Complete listing at http://thyme.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 24863 823 76 48 LINKdotNET AS number 20858 302 34 5 This AS will be used to conne 3741 278 860 238 The Internet Solution 2018 243 215 143 Tertiary Education Network 6713 159 150 15 Itissalat Al-MAGHRIB 29571 139 15 9 Ci Telecom Autonomous system 5536 123 8 9 Internet Egypt Network 33783 120 8 40 EEPAD TISP TELECOM & INTERNET 5713 115 507 66 Telkom SA Ltd 24835 107 46 9 RAYA Telecom - Egypt 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 4306 3653 342 bellsouth.net, inc. 209 2559 4149 604 Qwest 4323 1848 1035 373 Time Warner Telecom 1785 1758 717 139 PaeTec Communications, Inc. 4766 1700 6930 405 Korea Telecom (KIX) 20115 1631 1449 728 Charter Communications 17488 1573 127 101 Hathway IP Over Cable Interne 7018 1464 5911 1014 AT&T WorldNet Services 8151 1449 2848 232 UniNet S.A. de C.V. 6478 1398 309 414 AT&T Worldnet Services Complete listing at http://thyme.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 209 2559 1955 Qwest 1785 1758 1619 PaeTec Communications, Inc. 4323 1848 1475 Time Warner Telecom 17488 1573 1472 Hathway IP Over Cable Interne 4766 1700 1295 Korea Telecom (KIX) 8452 1231 1224 TEDATA 8151 1449 1217 UniNet S.A. de C.V. 4755 1243 1117 TATA Communications formerly 11492 1102 1091 Cable One 18566 1062 1052 Covad Communications Complete listing at http://thyme.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 16927 UNALLOCATED 12.0.252.0/23 7018 AT&T WorldNet Servic 15132 UNALLOCATED 12.9.150.0/24 7018 AT&T WorldNet Servic 32567 UNALLOCATED 12.14.170.0/24 7018 AT&T WorldNet Servic 13746 UNALLOCATED 12.24.56.0/24 7018 AT&T WorldNet Servic 32567 UNALLOCATED 12.25.107.0/24 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.152.0/24 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.154.0/23 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.159.0/24 7018 AT&T WorldNet Servic 32326 UNALLOCATED 12.40.49.0/24 7018 AT&T WorldNet Servic 25639 UNALLOCATED 12.41.169.0/24 7018 AT&T WorldNet Servic Complete listing at http://thyme.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 24.246.0.0/17 7018 AT&T WorldNet Services 24.246.128.0/18 7018 AT&T WorldNet Services 41.223.112.0/22 5713 Telkom SA Ltd 41.223.176.0/22 36981 >>UNKNOWN<< 41.223.188.0/24 22351 Intelsat 41.223.189.0/24 26452 Local Communications Networks 62.61.220.0/24 24974 Tachyon Europe BV - Wireless 62.61.221.0/24 24974 Tachyon Europe BV - Wireless 63.140.213.0/24 22555 Universal Talkware Corporatio 63.143.251.0/24 22555 Universal Talkware Corporatio Complete listing at http://thyme.apnic.net/current/data-add-IANA Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:19 /9:10 /10:20 /11:58 /12:166 /13:337 /14:597 /15:1146 /16:10463 /17:4724 /18:8128 /19:17124 /20:20385 /21:20268 /22:25947 /23:25487 /24:150459 /25:900 /26:1041 /27:543 /28:160 /29:37 /30:10 /31:0 /32:8 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 6389 2804 4306 bellsouth.net, inc. 4766 1391 1700 Korea Telecom (KIX) 17488 1306 1573 Hathway IP Over Cable Interne 209 1295 2559 Qwest 8452 1207 1231 TEDATA 1785 1163 1758 PaeTec Communications, Inc. 18566 1043 1062 Covad Communications 11492 1038 1102 Cable One 2386 962 1264 AT&T Data Communications Serv 4323 952 1848 Time Warner Telecom Complete listing at http://thyme.apnic.net/current/data/sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 4:13 8:199 12:2222 13:10 15:19 16:3 17:4 20:35 24:1063 32:50 38:528 40:97 41:2015 43:1 44:2 47:22 52:4 55:2 56:3 57:25 58:581 59:637 60:459 61:1121 62:1112 63:2075 64:3664 65:2393 66:3621 67:1630 68:754 69:2590 70:531 71:144 72:1654 73:2 74:1499 75:171 76:311 77:833 78:561 79:336 80:971 81:814 82:530 83:417 84:613 85:1083 86:403 87:652 88:355 89:1442 90:47 91:2191 92:317 93:1003 94:1181 95:961 96:125 97:205 98:221 99:22 109:1 110:92 112:112 113:102 114:251 115:271 116:1162 117:520 118:290 119:691 120:142 121:721 122:1011 123:689 124:967 125:1315 128:221 129:232 130:126 131:414 132:73 133:9 134:185 135:214 136:242 137:152 138:159 139:81 140:444 141:107 142:377 143:357 144:362 145:47 146:373 147:152 148:518 149:237 150:181 151:200 152:147 153:139 154:2 155:274 156:169 157:300 158:115 159:310 160:281 161:135 162:274 163:149 164:482 165:503 166:278 167:363 168:685 169:167 170:475 171:40 172:10 173:276 174:204 178:1 186:10 187:88 188:13 189:343 190:2605 192:5797 193:4236 194:3305 195:2701 196:1075 198:3656 199:3348 200:5346 201:1367 202:7867 203:8197 204:3818 205:2144 206:2450 207:2814 208:3921 209:3391 210:2710 211:1112 212:1510 213:1706 214:74 215:30 216:4642 217:1264 218:368 219:432 220:1220 221:475 222:296 End of report From owen at delong.com Fri May 8 13:49:01 2009 From: owen at delong.com (Owen DeLong) Date: Fri, 8 May 2009 11:49:01 -0700 Subject: Checking bogon status of new address space In-Reply-To: <20090508173955.GA49860@ussenterprise.ufp.org> References: <20090508053336.GC7171@captain.bridge.anchor.net.au> <4A046B81.9010500@cymru.com> <20090508173955.GA49860@ussenterprise.ufp.org> Message-ID: <6AEEB32B-C756-42A3-BB67-4F7371BFAE40@delong.com> > > 29/256 = 11% of the available address space. My argument is, if > someone is scanning you from random source addresses blocking 10% > of the scan traffic is reaching a point of very little return for > the effort of updating the address lists, and as we all know it is > getting smaller and smaller. > True, but, random is not the only thing at issue here. It is popular for fraudulent web sites to set up within these unallocated /8s, and, having them rejected by route filters is a good thing. Having Team Cymru able to further deploy lists of addresses with no valid POCs will be an additional win in this arena, and, I encourage them to do so. > To that end, I believe the recommendation should be to move to a > martian-only filter over the next 12-24 months. This lines up with > the time frame at which all /8's are likely to be allocated. Of > course the full list of unallocated /8's should still be produced > for those who want it, I'm not advocating that anything go away, > just that I feel like we are at the point where the value of the > list is lower than the effort to maintain it for the /average/ user > of the list. > I think that's premature at best, and, a boon to abuse at worst. Owen From bburke at merit.edu Fri May 8 14:11:37 2009 From: bburke at merit.edu (Betty Burke) Date: Fri, 8 May 2009 15:11:37 -0400 (EDT) Subject: [NANOG-announce] NANOG46 Updates In-Reply-To: <1938051525.4200501241809138855.JavaMail.root@crono> Message-ID: <1650327365.4203151241809897143.JavaMail.root@crono> NANOG Community: On behalf of the Merit NANOG-Support team, we look forward to seeing many of you in Philadelphia for NANOG46. IF you have not, we certainly encourage you to take a look at the meeting agenda. Once again, the NANOG Program Committee has, and continues, to bring a strong program to our meetings! We also encourage you to consider investing in NANOG sponsorship opportunities. The NANOG Marketing Working group along with Merit have a new list of ideas/opportunities your organization may find of interest. The NANOG community clearly benefits from the Sponsorship support, and a great marketing opportunity for your organization. Of importance to those who have not registered, there are JUST DAYS Left to Save $75.00. Early Bird Pricing Expires at Midnight, Sunday, 5-10-09. The Hotel NANOG Group rate at expires May 29, 2009. Do not be left behind, Register now! https://nanog.merit.edu/registration/ Consider sponsorship OPPORTUNITIES! http://nanog.org/meetings/nanog46/agenda.php Make sure to check out... http://nanog.org/meetings/nanog46/agenda.php If you have questions, concerns, comments feel free to send them to nanog-support at nanog.org. Sincerely, Betty Burke Merit Network Inc. NANOG Community Project Manager NANOG Steering Committee Member _______________________________________________ NANOG-announce mailing list NANOG-announce at nanog.org http://mailman.nanog.org/mailman/listinfo/nanog-announce From ops.lists at gmail.com Fri May 8 18:35:00 2009 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Sat, 9 May 2009 05:05:00 +0530 Subject: massive snowshoe operations may be a cause for concern (was: Re:UCEProtect Level 3) In-Reply-To: References: <982D8D05B6407A49AD506E6C3AC8E7D60108AEBF4EB7@caralain.haven.nynaeve.net> <20090508172616.GC20326@hesketh.com> Message-ID: You wont find me holding up uceprotect or apews as fine examples of properly or even competently run lists, I'd point you to spamhaus for that. But, in this day and age, and with the volumes of spam around, I'd counsel you NOT to wait for or expect manual complaints to your abuse desk, almost nobody does that these days. Feel free to signup for AOL etc feedback loops and you'd probably get a much higher volume of complaints - enough that you'd have to dedicate an email address to it, and use the scriptability of the ARF format these feedback loops are sent in, so you can get / generate stats. Periodic rDNS scans of your network, and either making rDNS requests manual, or at least running periodic rDNS scans of your network to spot that kind of customer would make sense too. You must admit that the kind of rDNS Steve Champeon posted in in that very long list upthread sticks out like a sore thumb. --srs On Sat, May 9, 2009 at 4:20 AM, John van Oppen wrote: > My favorite part of uceprotect was that there was basically no way to get them to send us actual reports or even IPs > (without us paying for them). We canned this customer a month or two ago for abuse but gave them time to migrate > out of our IP space (they were announcing it with their ASN to their other provider even after we cut transit) and > swore up and down they were using it for virtual hosting (as did their ARIN justification forms). I just requested > directly to their other provider that announcements be filtered and removed the SWIP. That /20 had only ever > had about 15 reports for it to our abuse desk and we are actually responsive hence the kicking of the customer From john at vanoppen.com Fri May 8 19:08:30 2009 From: john at vanoppen.com (John van Oppen) Date: Fri, 8 May 2009 17:08:30 -0700 Subject: massive snowshoe operations may be a cause for concern (was: Re:UCEProtect Level 3) References: <982D8D05B6407A49AD506E6C3AC8E7D60108AEBF4EB7@caralain.haven.nynaeve.net> <20090508172616.GC20326@hesketh.com> Message-ID: I agree, spamhaus has always been great. We were on a few feedback loops and senderbase.org did not show much for that subnet... anyway solved now. Got the ex-customer's other ISP to block the announcement since we killed it a while ago, also removed the SWIP. ;) John van Oppen Spectrum Networks LLC Direct: 206.973.8302 Main: 206.973.8300 Website: http://spectrumnetworks.us -----Original Message----- From: Suresh Ramasubramanian [mailto:ops.lists at gmail.com] Sent: Friday, May 08, 2009 4:35 PM To: John van Oppen Cc: Steven Champeon; Skywing; Raleigh Apple; nanog at nanog.org Subject: Re: massive snowshoe operations may be a cause for concern (was: Re:UCEProtect Level 3) You wont find me holding up uceprotect or apews as fine examples of properly or even competently run lists, I'd point you to spamhaus for that. But, in this day and age, and with the volumes of spam around, I'd counsel you NOT to wait for or expect manual complaints to your abuse desk, almost nobody does that these days. Feel free to signup for AOL etc feedback loops and you'd probably get a much higher volume of complaints - enough that you'd have to dedicate an email address to it, and use the scriptability of the ARF format these feedback loops are sent in, so you can get / generate stats. Periodic rDNS scans of your network, and either making rDNS requests manual, or at least running periodic rDNS scans of your network to spot that kind of customer would make sense too. You must admit that the kind of rDNS Steve Champeon posted in in that very long list upthread sticks out like a sore thumb. --srs On Sat, May 9, 2009 at 4:20 AM, John van Oppen wrote: > My favorite part of uceprotect was that there was basically no way to get them to send us actual reports or even IPs > (without us paying for them). We canned this customer a month or two ago for abuse but gave them time to migrate > out of our IP space (they were announcing it with their ASN to their other provider even after we cut transit) and > swore up and down they were using it for virtual hosting (as did their ARIN justification forms). I just requested > directly to their other provider that announcements be filtered and removed the SWIP. That /20 had only ever > had about 15 reports for it to our abuse desk and we are actually responsive hence the kicking of the customer From simon at darkmere.gen.nz Fri May 8 20:13:34 2009 From: simon at darkmere.gen.nz (Simon Lyall) Date: Sat, 9 May 2009 13:13:34 +1200 (NZST) Subject: ADMIN: "UCEProtect" threads moderated. Message-ID: The thread "UCEProtect Level 3" ( and related threads ) have been moderated. We suggest using the spam-l or www.mailop.org lists to discuss Spam and DNSBLs. Simon Lyall (on behalf of) NANOG MLC -- Simon Lyall | Very Busy | Web: http://www.darkmere.gen.nz/ "To stay awake all night adds a day to your life" - Stilgar | eMT. From frnkblk at iname.com Fri May 8 23:41:36 2009 From: frnkblk at iname.com (Frank Bulk) Date: Fri, 8 May 2009 23:41:36 -0500 Subject: Checking bogon status of new address space In-Reply-To: References: <20090508053336.GC7171@captain.bridge.anchor.net.au> Message-ID: Ran across two different DNS hosters in the last two weeks that were blocking space that was de-bogoned 2.5 years ago... =( One started as an e-mail issue, the other as a web access. The e-mail issue showed up as the server sending the sender an "I can't deliver this e-mail because I can't resolve the DNS info", and digs from the e-mail server confirmed the case. Testing from our old IP address space worked, so it was clear it was some kind of block based on IP address. The web browsing one was easy, too, because the customer was able to browse (when they had old DNS servers) and then couldn't (when we handed out new DNS servers). Since the e-mail issue was fresh in our mind, it was one of the first things we tested. I hope both DNS hosters took the time to update the rest of their bogon lists, too, not just remove our space from the bogon list. Frank -----Original Message----- From: Steve Dalberg [mailto:steve+nanog at sendithere.com] Sent: Friday, May 08, 2009 9:45 AM To: Oliver Hookins Cc: nanog at nanog.org Subject: Re: Checking bogon status of new address space Having recently received some de-bogon'ed addressing in or about this March, I can tell you that the one problem I had was people that had not updated their Bind Bogon filters ( http://www.cymru.com/Documents/secure-bind-template.html) and so were not responding to requests from our address space, so we just moved our dns cache boxes back to our older Level3 address space. Took a while to figure that one out though. Steve 2009/5/7 Oliver Hookins > Hi, > > my company has just been allocated some new IPv4 address space, and I want > to do some sort of automated testing to find out any ASs out there that > haven't removed the /8 it's on from their bogon list (the allocation to our > local registry only occurred in November last year). > > Has anybody attempted to do this? It is worth bothering? Currently I'm > considering pulling out all the endpoint ASs out of the BGP table, finding > at least one subnet for each of them and attempting to ping or reach other > common ports on a single IP for each AS from our currently working > address space, and then the new address space and comparing results. > > -- > Regards, > Oliver Hookins > Anchor Systems > > From mysidia at gmail.com Sat May 9 09:10:49 2009 From: mysidia at gmail.com (James Hess) Date: Sat, 9 May 2009 09:10:49 -0500 Subject: Checking bogon status of new address space In-Reply-To: <20090508173955.GA49860@ussenterprise.ufp.org> References: <20090508053336.GC7171@captain.bridge.anchor.net.au> <4A046B81.9010500@cymru.com> <20090508173955.GA49860@ussenterprise.ufp.org> Message-ID: <6eb799ab0905090710r1afc3ca5md61b76e884a4076d@mail.gmail.com> > 29/256 = 11% of the available address space. ?My argument is, if > someone is scanning you from random source addresses blocking 10% > of the scan traffic is reaching a point of very little return for > the effort of updating the address lists, and as we all know it is > getting smaller and smaller. Granted, if the filters aren't updated very frequently, they're pretty bad. But.. I would suggest, basically, filtering bogons is still great and pretty important, it serves as an ongoing deterrant against random unruly networks trying to pick up the unassigned addresses, or treating the space as "Up for grabs" just because some space happens to be unannounced (and unassigned). This is a behavioral effect: possibly fewer scans are attempted from those networks than would be attempted if nobody filtered bogons. As a result, the assumption of randomness may not be warranted; if bogons weren't filtered, there would be reasons hijackers would target them (not having a "legitimate assignee" to contend with); 10% of the space doesn't mean 10% of the scans; it could mean 40% of the scans, if enough scanners had a policy of preferring to scan from unassigned space. With looming IP exhaustion it's possibly even more important... I'd be worried about this scenario: APNIC denied your /12 request? No problem... pick a random bogon from the last 30 unassigned /8s and somehow sneak a line into your Tier1 provider contracts requiring they propagate only your announcements to the /12.... The space might otherwise be very enticing for evil scanners to use, because it's "easy pickings" no legitimate assignee of the address space to hunt them down and send armies of lawyers on a raid... -- -J From mhw at WittsEnd.com Sat May 9 09:47:09 2009 From: mhw at WittsEnd.com (Michael H. Warfield) Date: Sat, 09 May 2009 10:47:09 -0400 Subject: [quagga-users 10587] bgpd crash - apologies (fwd) In-Reply-To: References: Message-ID: <1241880429.28696.63.camel@canyon.wittsend.com> On Mon, 2009-05-04 at 04:48 +0000, Chris Caputo wrote: > On Mon, 4 May 2009, Ingo Flaschberger wrote: > > ---------- Forwarded message ---------- > > Date: Mon, 04 May 2009 00:38:54 +0300 > > From: Geert Jan de Groot > > To: quagga-users at lists.quagga.net > > Subject: [quagga-users 10587] bgpd crash - apologies > > > > Hello, > > > > I learned today that a BGP announcement for which I am the tech-c, > > is causing difficulties with Quagga. First of all, I apologise; > > it's only today that I heard about these difficulties. > [...] > A fix is here: > https://www.caputo.com/foss/quagga-0.99.10-BGP-4-byte-ASN-bug-fixes.patch > https://www.caputo.com/foss/quagga-0.99.11-BGP-4-byte-ASN-bug-fixes.patch > (the patches are identical. naming is just for clarity.) > Chris Quagga 0.99.12 has been released to address these problems. Announcement on their home page: http://www.quagga.net Regards, Mike -- Michael H. Warfield (AI4NB) | (770) 985-6132 | mhw at WittsEnd.com /\/\|=mhw=|\/\/ | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0xDF1DD471 | possible worlds. A pessimist is sure of it! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 307 bytes Desc: This is a digitally signed message part URL: From wyystar at gmail.com Sun May 10 05:51:43 2009 From: wyystar at gmail.com (yangyang. wang) Date: Sun, 10 May 2009 18:51:43 +0800 Subject: ASPATH Loop Message-ID: <10fbbf5a0905100351p1663830aq78b2f82f836ad54c@mail.gmail.com> Hi? NANOG? When I was analyzing the BGP RIB data from RouteViews, I found that there were aspath loop in many bgp rib entries. For example, in the file rib.wide.20090301.0319, the peer 202.249.2.169 in AS2497 observed the following aspaths: 3130 29283 3130 2914 2497 3130 7337 3130 2914 2497 3130 34486 3130 2914 2497 3130 38001 3130 2914 2497 3130 13977 3130 2914 2497 3130 25147 3130 2914 2497 3130 5433 3130 2914 2497 3130 26164 3130 2914 2497 3130 34026 3130 2914 2497 3130 31535 3130 2914 2497 3130 14363 3130 2914 2497 3130 29648 3130 2914 2497 3130 27582 3130 2914 2497 3130 39737 3130 2914 2497 3130 33796 3130 2914 2497 3130 15108 3130 2914 2497 3130 9600 3130 2914 2497 ...... As we know, BGP instance running on routers don't allow loop in ASPATH, why they can be seen in RIBs? It's some particular technical configuration in practice? OR What's wrong with AS3130?? Thanks Yangyang From nanog at daork.net Sun May 10 05:59:31 2009 From: nanog at daork.net (Nathan Ward) Date: Sun, 10 May 2009 22:59:31 +1200 Subject: ASPATH Loop In-Reply-To: <10fbbf5a0905100351p1663830aq78b2f82f836ad54c@mail.gmail.com> References: <10fbbf5a0905100351p1663830aq78b2f82f836ad54c@mail.gmail.com> Message-ID: On 10/05/2009, at 10:51 PM, yangyang. wang wrote: > As we know, BGP instance running on routers don't allow loop in > ASPATH, why they can be seen in RIBs? It's some particular technical > configuration in practice? OR What's wrong with AS3130?? Look at the WHOIS entry for AS3130, and notice in the comments field: http://psg.com/as3130/ "Regarding strange announcements by AS 3130 of prefixes in 98.128.0.0/16" is in the big headings on the top of that page. He is no doubt announcing it with an origin AS of 3130 so no person or router complains about inconsistent origins. -- Nathan Ward From wyystar at gmail.com Sun May 10 06:13:07 2009 From: wyystar at gmail.com (yangyang. wang) Date: Sun, 10 May 2009 19:13:07 +0800 Subject: ASPATH Loop In-Reply-To: References: <10fbbf5a0905100351p1663830aq78b2f82f836ad54c@mail.gmail.com> Message-ID: <10fbbf5a0905100413g594ce8e3u7d56bef58a680432@mail.gmail.com> OK?I see, Thanks? 2009/5/10 Nathan Ward : > On 10/05/2009, at 10:51 PM, yangyang. wang wrote: > >> As we know, BGP instance running on routers don't allow loop in >> ASPATH, why they can be seen in RIBs? It's some particular technical >> configuration in practice? OR What's wrong with AS3130?? > > > Look at the WHOIS entry for AS3130, and notice in the comments field: > http://psg.com/as3130/ > > "Regarding strange announcements by AS 3130 of prefixes in 98.128.0.0/16" is > in the big headings on the top of that page. > > He is no doubt announcing it with an origin AS of 3130 so no person or > router complains about inconsistent origins. > > -- > Nathan Ward > > > From ip at ioshints.info Sun May 10 07:33:39 2009 From: ip at ioshints.info (Ivan Pepelnjak) Date: Sun, 10 May 2009 14:33:39 +0200 Subject: ASPATH Loop In-Reply-To: <10fbbf5a0905100351p1663830aq78b2f82f836ad54c@mail.gmail.com> References: <10fbbf5a0905100351p1663830aq78b2f82f836ad54c@mail.gmail.com> Message-ID: <000a01c9d16b$8d1eed90$0a00000a@nil.si> Multiple discontiguous copies of an AS number in the AS-path can also be caused by the "original" Cisco IOS "local-as" feature, but in that case the AS number in the middle would be fixed. http://bit.ly/7TnCi And there's always the AS-path prepending. Cisco IOS allows you to insert anything in the AS path. Ivan http://www.ioshints.info/about http://blog.ioshints.info/ > -----Original Message----- > From: yangyang. wang [mailto:wyystar at gmail.com] > Sent: Sunday, May 10, 2009 12:52 PM > To: nanog at nanog.org > Subject: ASPATH Loop > > Hi? NANOG? > > When I was analyzing the BGP RIB data from RouteViews, > I found that there were aspath loop in many bgp rib entries. > For example, in the file rib.wide.20090301.0319, the peer > 202.249.2.169 in AS2497 observed the following aspaths: > > 3130 29283 3130 2914 2497 > 3130 7337 3130 2914 2497 From jb at langports.com Sun May 10 19:22:34 2009 From: jb at langports.com (Juraj Benak) Date: Mon, 11 May 2009 10:22:34 +1000 Subject: webpage doesn't worok from specific address Message-ID: <15F5C994D461472A89F195525F941A9E@LANGPORTS.local> Hi everyone, I've got very unique (at least I think) problem. I have a webpage hosted on fatcow.com -> www.langports.fatcow.com The problem is that I can't access it from my computer! I'm working in an English language college and we have 2 separated networks - one for staff and the other one for students. I'm able to connect to the webpage from student's network but not from the staff's. I contacted fatcow support, they checked it from their end everything seems all right so they told me to contact my ISP. I contacted Telstra which is managing our both connections; they checked it from their end and say there is nothing wrong, they don't block anything and I should again contact fatcow. I got as well different results from tracert - 2 more hops while going through student's network (the one that works). Do you have any idea what could be wrong? I'm using Fortigate A100 as router and there has been no change last few months. Could you please advise me what program should I use to find out exactly where the problem occurs and what is the cause? Firefow return this message: Connection Interrupted. The document contains no data. The network link was interrupted while negotiating a connection. Please try again. Thanks, Juraj From jb at langports.com Sun May 10 19:48:33 2009 From: jb at langports.com (Juraj Benak) Date: Mon, 11 May 2009 10:48:33 +1000 Subject: webpage doesn't worok from specific address In-Reply-To: <8B79B73777E7D544A24BEB8FC50D35DB55C2D6@MERCURY.socrdu.com> References: <15F5C994D461472A89F195525F941A9E@LANGPORTS.local> <8B79B73777E7D544A24BEB8FC50D35DB55C2D6@MERCURY.socrdu.com> Message-ID: Hi Dave, Yes I did check it by IP address. Internal DNS - no changes at all. All other webpages work without any problem so I'm sure it can't be DNS. I tried ping on langports.fatcow.com from the Fortigate and there is no response either... -----Original Message----- From: Dave Larter [mailto:dave at stayonline.com] Sent: Monday, 11 May 2009 10:29 AM To: Juraj Benak Subject: RE: webpage doesn't worok from specific address Links work for me on the outside, maybe internal DNS? Have you checked by IP? Hosts if a Win env? -----Original Message----- From: Juraj Benak [mailto:jb at langports.com] Sent: Sunday, May 10, 2009 8:23 PM To: nanog at nanog.org Subject: webpage doesn't worok from specific address Hi everyone, I've got very unique (at least I think) problem. I have a webpage hosted on fatcow.com -> www.langports.fatcow.com The problem is that I can't access it from my computer! I'm working in an English language college and we have 2 separated networks - one for staff and the other one for students. I'm able to connect to the webpage from student's network but not from the staff's. I contacted fatcow support, they checked it from their end everything seems all right so they told me to contact my ISP. I contacted Telstra which is managing our both connections; they checked it from their end and say there is nothing wrong, they don't block anything and I should again contact fatcow. I got as well different results from tracert - 2 more hops while going through student's network (the one that works). Do you have any idea what could be wrong? I'm using Fortigate A100 as router and there has been no change last few months. Could you please advise me what program should I use to find out exactly where the problem occurs and what is the cause? Firefow return this message: Connection Interrupted. The document contains no data. The network link was interrupted while negotiating a connection. Please try again. Thanks, Juraj __________ Information from ESET NOD32 Antivirus, version of virus signature database 4063 (20090508) __________ The message was checked by ESET NOD32 Antivirus. http://www.eset.com __________ Information from ESET NOD32 Antivirus, version of virus signature database 4063 (20090508) __________ The message was checked by ESET NOD32 Antivirus. http://www.eset.com From simon at darkmere.gen.nz Sun May 10 20:35:36 2009 From: simon at darkmere.gen.nz (Simon Lyall) Date: Mon, 11 May 2009 13:35:36 +1200 (NZST) Subject: webpage doesn't worok from specific address In-Reply-To: <15F5C994D461472A89F195525F941A9E@LANGPORTS.local> References: <15F5C994D461472A89F195525F941A9E@LANGPORTS.local> Message-ID: This thread has been moderated. Please contact the original poster directly if you wish to help. Simon. NANOG MLC On Mon, 11 May 2009, Juraj Benak wrote: > Hi everyone, > > > > I've got very unique (at least I think) problem. > > > > I have a webpage hosted on fatcow.com -> www.langports.fatcow.com > > > The problem is that I can't access it from my computer! > > > > I'm working in an English language college and we have 2 separated networks > - one for staff and the other one for students. I'm able to connect to the > webpage from student's network but not from the staff's. > > I contacted fatcow support, they checked it from their end everything seems > all right so they told me to contact my ISP. I contacted Telstra which is > managing our both connections; they checked it from their end and say there > is nothing wrong, they don't block anything and I should again contact > fatcow. > > > > I got as well different results from tracert - 2 more hops while going > through student's network (the one that works). > > > > Do you have any idea what could be wrong? I'm using Fortigate A100 as router > and there has been no change last few months. > > > > Could you please advise me what program should I use to find out exactly > where the problem occurs and what is the cause? > > > > Firefow return this message: Connection Interrupted. The document contains > no data. The network link was interrupted while negotiating a connection. > Please try again. > > > > Thanks, > > > > Juraj > > > > > -- Simon Lyall | Very Busy | Web: http://www.darkmere.gen.nz/ "To stay awake all night adds a day to your life" - Stilgar | eMT. From twright at internode.com.au Mon May 11 02:30:49 2009 From: twright at internode.com.au (Tom Wright) Date: Mon, 11 May 2009 17:00:49 +0930 Subject: host.net contact person Message-ID: <9D5BCAD8-2E26-4BE9-8D54-8A08E65FD9DA@internode.com.au> Hi - I'm trying to resolve an IRRD mirroring issue. The contact e-mail "db-admin at rr.host.net" bounces. http://rr.host.net/help-mirroring.html Does anyone have the correct address or the details of someone at host.net who could give me a hand? Thanks! -- Kind Regards, Tom Wright Internode Network Operations P: +61 8 8228 2999 W: http://www.internode.on.net From deric.kwok2000 at gmail.com Mon May 11 05:57:38 2009 From: deric.kwok2000 at gmail.com (Deric Kwok) Date: Mon, 11 May 2009 06:57:38 -0400 Subject: need help in bandwidth Message-ID: <40d8a95a0905110357q21da7297qe6776b2f007cabc0@mail.gmail.com> Hi all Any better ways to contr ol the bandwidth? and how? eg: in hardware : switch, router or software: iptables...tc, access-list Thank you for your help From andrey.gordon at gmail.com Mon May 11 09:37:25 2009 From: andrey.gordon at gmail.com (Andrey Gordon) Date: Mon, 11 May 2009 10:37:25 -0400 Subject: PPP multilink help Message-ID: <90ccfc90905110737h7b0c432nfa44ac0c2f113e63@mail.gmail.com> Hey folks, I'm sure to you it's peanuts, but I'm a bit puzzled (most likely because of the lack of knowledge, I bet). I'm buying an IP backbone from VNZ (presumably MPLS). I get a MLPPP hand off on all sites, so I don't do the actual labeling and switching, so I guess for practical purposes what I'm trying to say is that I have no physical control over the other side of my MLPPP links. When I transfer a large file over FTP (or CIFS, or anything else), I'd expect it to max out either one or both T1, but instead utilization on the T1s is hoovering at 70% on both and sometimes MLPPP link utilization even drops below 50%. What am I'm not gettting here? Tx, Andrey Below is a snip of my config. controller T1 0/0/0 cablelength long 0db channel-group 1 timeslots 1-24 ! controller T1 0/0/1 cablelength long 0db channel-group 1 timeslots 1-24 ! ip nbar custom rdesktop tcp 3389 ip cef ! class-map match-any VoIP match dscp ef class-map match-any interactive match protocol rdesktop match protocol telnet match protocol ssh ! policy-map QWAS class VoIP priority 100 class interactive bandwidth 500 class class-default fair-queue 4096 ! interface Multilink1 description Verizon Business MPLS Circuit ip address x.x.x.150 255.255.255.252 ip flow ingress ip nat inside ip virtual-reassembly load-interval 30 no peer neighbor-route ppp chap hostname R1 ppp multilink ppp multilink links minimum 1 ppp multilink group 1 ppp multilink fragment disable service-policy output QWAS ! interface Serial0/0/0:1 no ip address ip flow ingress encapsulation ppp load-interval 30 fair-queue 4096 256 0 ppp chap hostname R1 ppp multilink ppp multilink group 1 ! interface Serial0/0/1:1 no ip address ip flow ingress encapsulation ppp load-interval 30 fair-queue 4096 256 0 ppp chap hostname R1 ppp multilink ppp multilink group 1 ----- Andrey Gordon [andrey.gordon at gmail.com] From dwhite at olp.net Mon May 11 09:54:29 2009 From: dwhite at olp.net (Dan White) Date: Mon, 11 May 2009 09:54:29 -0500 Subject: PPP multilink help In-Reply-To: <90ccfc90905110737h7b0c432nfa44ac0c2f113e63@mail.gmail.com> References: <90ccfc90905110737h7b0c432nfa44ac0c2f113e63@mail.gmail.com> Message-ID: <4A083C25.10809@olp.net> Andrey Gordon wrote: > Hey folks, I'm sure to you it's peanuts, but I'm a bit puzzled (most likely > because of the lack of knowledge, I bet). > > I'm buying an IP backbone from VNZ (presumably MPLS). I get a MLPPP hand off > on all sites, so I don't do the actual labeling and switching, so I guess > for practical purposes what I'm trying to say is that I have no physical > control over the other side of my MLPPP links. > > When I transfer a large file over FTP (or CIFS, or anything else), I'd > expect it to max out either one or both T1, but instead utilization on the > T1s is hoovering at 70% on both and sometimes MLPPP link utilization even > drops below 50%. What am I'm not gettting here? > I seem to be in a similar situation as you (but with AT&T). I have not noticed any unexpected missing bandwidth. I don't see any specific problems with your config, but I'll include mine in hopes it will be useful: controller T1 0/0/0 framing esf linecode b8zs channel-group 0 timeslots 1-24 ! controller T1 0/0/1 framing esf linecode b8zs channel-group 0 timeslots 1-24 ! class-map match-any imaging match access-group 112 class-map match-any rdp match access-group 113 class-map match-any voice match ip dscp ef match access-group 110 ! policy-map private_wan class voice priority percent 60 set ip dscp ef class rdp bandwidth percent 32 set ip dscp af31 class imaging bandwidth percent 4 set ip dscp af21 class class-default bandwidth percent 4 set ip dscp default ! interface Multilink1 ip address x.x.x.38 255.255.255.252 no keepalive no cdp enable ppp chap hostname xxxxxxx ppp multilink ppp multilink fragment disable ppp multilink group 1 max-reserved-bandwidth 100 service-policy output private_wan ! interface Serial0/0/0:0 no ip address encapsulation ppp no cdp enable ppp chap hostname xxxxxxxxxx ppp multilink ppp multilink group 1 max-reserved-bandwidth 100 ! interface Serial0/0/1:0 no ip address encapsulation ppp no cdp enable ppp chap hostname xxxxxxxxxx ppp multilink ppp multilink group 1 max-reserved-bandwidth 100 ! access-list 110 permit ip any 10.0.0.0 0.0.255.255 access-list 110 permit ip 10.0.0.0 0.0.255.255 any access-list 110 permit icmp any any access-list 112 permit ip any host x.x.x.x access-list 113 permit ip any host x.x.x.x From jay at west.net Mon May 11 10:30:18 2009 From: jay at west.net (Jay Hennigan) Date: Mon, 11 May 2009 08:30:18 -0700 Subject: Anomalies with AS13214 ? Message-ID: <4A08448A.7020403@west.net> We're getting cyclops[1] alerts that AS13214 is advertising itself as origin for all of our prefixes. Their anomaly report shows thousands of prefixes originating there. Anyone else seeing evidence of this or being affected? [1] http://cyclops.cs.ucla.edu/ -- Jay Hennigan - CCIE #7880 - Network Engineering - jay at impulse.net Impulse Internet Service - http://www.impulse.net/ Your local telephone and internet company - 805 884-6323 - WB6RDV From jhary at unsane.co.uk Mon May 11 11:01:42 2009 From: jhary at unsane.co.uk (Vincent Hoffman) Date: Mon, 11 May 2009 17:01:42 +0100 Subject: Anomalies with AS13214 ? In-Reply-To: <4A08448A.7020403@west.net> References: <4A08448A.7020403@west.net> Message-ID: <4A084BE6.5080501@unsane.co.uk> On 11/5/09 16:30, Jay Hennigan wrote: > We're getting cyclops[1] alerts that AS13214 is advertising itself as > origin for all of our prefixes. Their anomaly report shows thousands > of prefixes originating there. > > Anyone else seeing evidence of this or being affected? > > > [1] http://cyclops.cs.ucla.edu/ > I'm seeing alerts for AS13214 advertising our prefixes from cyclops also. However a quick look at a few looking glasses and route servers doesnt seem to show any rogue advertisments, and we havent see any drop in traffic as yet. Vince > > -- > Jay Hennigan - CCIE #7880 - Network Engineering - jay at impulse.net > Impulse Internet Service - http://www.impulse.net/ > Your local telephone and internet company - 805 884-6323 - WB6RDV From tkapela at gmail.com Mon May 11 11:02:40 2009 From: tkapela at gmail.com (Anton Kapela) Date: Mon, 11 May 2009 12:02:40 -0400 Subject: PPP multilink help In-Reply-To: <4A083C25.10809@olp.net> References: <90ccfc90905110737h7b0c432nfa44ac0c2f113e63@mail.gmail.com> <4A083C25.10809@olp.net> Message-ID: <2e9d8ae50905110902t2a63a19pca413c95d4f96920@mail.gmail.com> Gents, On Mon, May 11, 2009 at 10:54 AM, Dan White wrote: > Andrey Gordon wrote: [snip] >> When I transfer a large file over FTP (or CIFS, or anything else), I'd >> expect it to max out either one or both T1, but instead utilization on the >> T1s is hoovering at 70% on both and sometimes MLPPP link utilization even >> drops below 50%. What am I'm not gettting here? Sounds like the TCP window is either set 'small' or TCP window scaling either isn't enabled or isn't scaling to your bandwidth/delay product (for the hosts in question). Since FTP is a 'stream' based transport of file data (like http), you should see this scale to nearly all of or most of your links (assuming TCP isn't your issue). Additionally, when using CIFS, SMB, TFTP, NFS, and other command->acknowledgment style protocols over wide-area links (which aren't stream-based operations, but rather iterative operations on blocks or parts of a file), you likely will never observe a single transfer filling up the links. -Tk From chewtoy at s8n.net Mon May 11 11:04:46 2009 From: chewtoy at s8n.net (Russell Heilling) Date: Mon, 11 May 2009 17:04:46 +0100 Subject: Anomalies with AS13214 ? In-Reply-To: <4A08448A.7020403@west.net> References: <4A08448A.7020403@west.net> Message-ID: <647fc4230905110904l1dc842cby72d6206ff8ce5af@mail.gmail.com> Same here. Cyclops reporting an origin change but we are seeing no change in traffic levels. Still investigating at the moment... 2009/5/11 Jay Hennigan > We're getting cyclops[1] alerts that AS13214 is advertising itself as > origin for all of our prefixes. Their anomaly report shows thousands of > prefixes originating there. > > Anyone else seeing evidence of this or being affected? > > > [1] http://cyclops.cs.ucla.edu/ > > > -- > Jay Hennigan - CCIE #7880 - Network Engineering - jay at impulse.net > Impulse Internet Service - http://www.impulse.net/ > Your local telephone and internet company - 805 884-6323 - WB6RDV > > From rodunn at cisco.com Mon May 11 11:06:02 2009 From: rodunn at cisco.com (Rodney Dunn) Date: Mon, 11 May 2009 12:06:02 -0400 Subject: PPP multilink help In-Reply-To: <90ccfc90905110737h7b0c432nfa44ac0c2f113e63@mail.gmail.com> References: <90ccfc90905110737h7b0c432nfa44ac0c2f113e63@mail.gmail.com> Message-ID: <20090511160602.GI127@rtp-cse-489.cisco.com> On Mon, May 11, 2009 at 10:37:25AM -0400, Andrey Gordon wrote: > Hey folks, I'm sure to you it's peanuts, but I'm a bit puzzled (most likely > because of the lack of knowledge, I bet). > > I'm buying an IP backbone from VNZ (presumably MPLS). I get a MLPPP hand off > on all sites, so I don't do the actual labeling and switching, so I guess > for practical purposes what I'm trying to say is that I have no physical > control over the other side of my MLPPP links. > > When I transfer a large file over FTP (or CIFS, or anything else), I'd > expect it to max out either one or both T1, Most MLPPP implementations don't has the flows at the IP layer to an individual MLPPP member link. The bundle is a virtual L3 interface and the packets themselves are distributed over the member links. Some people reference it as a "load balancing" scenario vs. "load sharing" as the traffic is given to the link that isn't currently "busy". but instead utilization on the > T1s is hoovering at 70% on both and sometimes MLPPP link utilization even > drops below 50%. What am I'm not gettting here? If you have Multilink fragmentation disabled it sends a packet down each path. It could be a reordering delay causing just enough variance in the packet stream that the application thorttles back. If you have a bunch of individual streams going you would probably see a higher throughput. Remember there is additional overhead for the MLPPP. Rodney > > Tx, > Andrey > > Below is a snip of my config. > > controller T1 0/0/0 > cablelength long 0db > channel-group 1 timeslots 1-24 > ! > controller T1 0/0/1 > cablelength long 0db > channel-group 1 timeslots 1-24 > ! > ip nbar custom rdesktop tcp 3389 > ip cef > ! > class-map match-any VoIP > match dscp ef > class-map match-any interactive > match protocol rdesktop > match protocol telnet > match protocol ssh > ! > policy-map QWAS > class VoIP > priority 100 > class interactive > bandwidth 500 > class class-default > fair-queue 4096 > ! > interface Multilink1 > description Verizon Business MPLS Circuit > ip address x.x.x.150 255.255.255.252 > ip flow ingress > ip nat inside > ip virtual-reassembly > load-interval 30 > no peer neighbor-route > ppp chap hostname R1 > ppp multilink > ppp multilink links minimum 1 > ppp multilink group 1 > ppp multilink fragment disable > service-policy output QWAS > ! > interface Serial0/0/0:1 > no ip address > ip flow ingress > encapsulation ppp > load-interval 30 > fair-queue 4096 256 0 > ppp chap hostname R1 > ppp multilink > ppp multilink group 1 > ! > interface Serial0/0/1:1 > no ip address > ip flow ingress > encapsulation ppp > load-interval 30 > fair-queue 4096 256 0 > ppp chap hostname R1 > ppp multilink > ppp multilink group 1 > > > > > ----- > Andrey Gordon [andrey.gordon at gmail.com] From jlewis at lewis.org Mon May 11 11:13:04 2009 From: jlewis at lewis.org (Jon Lewis) Date: Mon, 11 May 2009 12:13:04 -0400 (EDT) Subject: Anomalies with AS13214 ? In-Reply-To: <647fc4230905110904l1dc842cby72d6206ff8ce5af@mail.gmail.com> References: <4A08448A.7020403@west.net> <647fc4230905110904l1dc842cby72d6206ff8ce5af@mail.gmail.com> Message-ID: On Mon, 11 May 2009, Russell Heilling wrote: > Same here. Cyclops reporting an origin change but we are seeing no change > in traffic levels. > Still investigating at the moment... Somewhere, something is confused. I'm seeing cyclops report some of my prefixes with origins of 6364 (correct), 13214 6364 (no), and 6364 13214 (not right either). I'm also not seeing any unusual reduction of input traffic. ---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From jkelty at pandora.com Mon May 11 11:20:06 2009 From: jkelty at pandora.com (James Kelty) Date: Mon, 11 May 2009 09:20:06 -0700 Subject: Anomalies with AS13214 ? In-Reply-To: <4A084BE6.5080501@unsane.co.uk> References: <4A08448A.7020403@west.net> <4A084BE6.5080501@unsane.co.uk> Message-ID: <8FDD3859-44C7-4865-A61F-01F5D978C13D@pandora.com> Seeing the same issues with AS13214 and no corresponding drop in traffic, route views doesn't show any rogue adverts for out prefixes either. -James On May 11, 2009, at 9:01 AM, Vincent Hoffman wrote: > On 11/5/09 16:30, Jay Hennigan wrote: >> We're getting cyclops[1] alerts that AS13214 is advertising itself as >> origin for all of our prefixes. Their anomaly report shows thousands >> of prefixes originating there. >> >> Anyone else seeing evidence of this or being affected? >> >> >> [1] http://cyclops.cs.ucla.edu/ >> > > I'm seeing alerts for AS13214 advertising our prefixes from > cyclops also. However a quick look at a few looking glasses and route > servers doesnt seem to show any rogue advertisments, and we havent see > any drop in traffic as yet. > > Vince > >> >> -- >> Jay Hennigan - CCIE #7880 - Network Engineering - jay at impulse.net >> Impulse Internet Service - http://www.impulse.net/ >> Your local telephone and internet company - 805 884-6323 - WB6RDV > > "Ravioli is the square root of pasta." - Max K., Age 11 From mhuff at ox.com Mon May 11 11:32:03 2009 From: mhuff at ox.com (Matthew Huff) Date: Mon, 11 May 2009 12:32:03 -0400 Subject: PPP multilink help In-Reply-To: <20090511160602.GI127@rtp-cse-489.cisco.com> References: <90ccfc90905110737h7b0c432nfa44ac0c2f113e63@mail.gmail.com> <20090511160602.GI127@rtp-cse-489.cisco.com> Message-ID: <483E6B0272B0284BA86D7596C40D29F9C3811FCE19@PUR-EXCH07.ox.com> I would also think the problem is with flow control not allowing the maximum bandwidth. Trying multiple ftp streams and seeing if that would max it out would help. I would think you would want to add a WRED to the class-default entry to prevent global tcp synchronization ... class class-default fair-queue 4096 random-detect dscp-based ---- 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: Rodney Dunn [mailto:rodunn at cisco.com] Sent: Monday, May 11, 2009 12:06 PM To: Andrey Gordon Cc: nanog at nanog.org Subject: Re: PPP multilink help On Mon, May 11, 2009 at 10:37:25AM -0400, Andrey Gordon wrote: > Hey folks, I'm sure to you it's peanuts, but I'm a bit puzzled (most likely > because of the lack of knowledge, I bet). > > I'm buying an IP backbone from VNZ (presumably MPLS). I get a MLPPP hand off > on all sites, so I don't do the actual labeling and switching, so I guess > for practical purposes what I'm trying to say is that I have no physical > control over the other side of my MLPPP links. > > When I transfer a large file over FTP (or CIFS, or anything else), I'd > expect it to max out either one or both T1, Most MLPPP implementations don't has the flows at the IP layer to an individual MLPPP member link. The bundle is a virtual L3 interface and the packets themselves are distributed over the member links. Some people reference it as a "load balancing" scenario vs. "load sharing" as the traffic is given to the link that isn't currently "busy". but instead utilization on the > T1s is hoovering at 70% on both and sometimes MLPPP link utilization even > drops below 50%. What am I'm not gettting here? If you have Multilink fragmentation disabled it sends a packet down each path. It could be a reordering delay causing just enough variance in the packet stream that the application thorttles back. If you have a bunch of individual streams going you would probably see a higher throughput. Remember there is additional overhead for the MLPPP. Rodney > > Tx, > Andrey > > Below is a snip of my config. > > controller T1 0/0/0 > cablelength long 0db > channel-group 1 timeslots 1-24 > ! > controller T1 0/0/1 > cablelength long 0db > channel-group 1 timeslots 1-24 > ! > ip nbar custom rdesktop tcp 3389 > ip cef > ! > class-map match-any VoIP > match dscp ef > class-map match-any interactive > match protocol rdesktop > match protocol telnet > match protocol ssh > ! > policy-map QWAS > class VoIP > priority 100 > class interactive > bandwidth 500 > class class-default > fair-queue 4096 > ! > interface Multilink1 > description Verizon Business MPLS Circuit > ip address x.x.x.150 255.255.255.252 > ip flow ingress > ip nat inside > ip virtual-reassembly > load-interval 30 > no peer neighbor-route > ppp chap hostname R1 > ppp multilink > ppp multilink links minimum 1 > ppp multilink group 1 > ppp multilink fragment disable > service-policy output QWAS > ! > interface Serial0/0/0:1 > no ip address > ip flow ingress > encapsulation ppp > load-interval 30 > fair-queue 4096 256 0 > ppp chap hostname R1 > ppp multilink > ppp multilink group 1 > ! > interface Serial0/0/1:1 > no ip address > ip flow ingress > encapsulation ppp > load-interval 30 > fair-queue 4096 256 0 > ppp chap hostname R1 > ppp multilink > ppp multilink group 1 > > > > > ----- > Andrey Gordon [andrey.gordon at gmail.com] From david.freedman at uk.clara.net Mon May 11 11:41:36 2009 From: david.freedman at uk.clara.net (David Freedman) Date: Mon, 11 May 2009 17:41:36 +0100 Subject: Anomalies with AS13214 ? In-Reply-To: <4A08448A.7020403@west.net> References: <4A08448A.7020403@west.net> Message-ID: Randy doing testing again? Jay Hennigan wrote: > We're getting cyclops[1] alerts that AS13214 is advertising itself as > origin for all of our prefixes. Their anomaly report shows thousands of > prefixes originating there. > > Anyone else seeing evidence of this or being affected? > > > [1] http://cyclops.cs.ucla.edu/ > > > -- > Jay Hennigan - CCIE #7880 - Network Engineering - jay at impulse.net > Impulse Internet Service - http://www.impulse.net/ > Your local telephone and internet company - 805 884-6323 - WB6RDV > > From morrowc.lists at gmail.com Mon May 11 11:44:07 2009 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Mon, 11 May 2009 12:44:07 -0400 Subject: Anomalies with AS13214 ? In-Reply-To: References: <4A08448A.7020403@west.net> Message-ID: <75cb24520905110944x74fc6f9av3de81c4c6569315b@mail.gmail.com> On Mon, May 11, 2009 at 12:41 PM, David Freedman wrote: > Randy doing testing again? 13214 != 3130 From robert at ufl.edu Mon May 11 11:46:01 2009 From: robert at ufl.edu (Robert D. Scott) Date: Mon, 11 May 2009 12:46:01 -0400 Subject: Anomalies with AS13214 ? In-Reply-To: <8FDD3859-44C7-4865-A61F-01F5D978C13D@pandora.com> References: <4A08448A.7020403@west.net> <4A084BE6.5080501@unsane.co.uk> <8FDD3859-44C7-4865-A61F-01F5D978C13D@pandora.com> Message-ID: <00ad01c9d257$f7ae41f0$e70ac5d0$@edu> It looks like Cyclops is seeing these from AS 48285, but I see no indication they are being advertised to any production upstream provider. Our /16 is being alerted in Cyclops, but I can not find any advert on any looking glass. >From Cyclops: BGP protocol Time (UTC) W/A/B Peer IP Peer ASN Prefix AS_PATH Origin NEXT_HOP LOCAL_PREF MED Community Atomic Agg Aggregator BGP4MP 1242044196 A 194.71.0.1 48285 128.227.0.0/16 48285 13214 INCOMPLETE 194.71.0.1 0 0 NAG Robert D. Scott Robert at ufl.edu Senior Network Engineer 352-273-0113 Phone CNS - Network Services 352-392-2061 CNS Phone Tree University of Florida 352-392-9440 FAX Florida Lambda Rail 352-294-3571 FLR NOC Gainesville, FL 32611 321-663-0421 Cell -----Original Message----- From: James Kelty [mailto:jkelty at pandora.com] Sent: Monday, May 11, 2009 12:20 PM To: nanog at nanog.org Subject: Re: Anomalies with AS13214 ? Seeing the same issues with AS13214 and no corresponding drop in traffic, route views doesn't show any rogue adverts for out prefixes either. -James On May 11, 2009, at 9:01 AM, Vincent Hoffman wrote: > On 11/5/09 16:30, Jay Hennigan wrote: >> We're getting cyclops[1] alerts that AS13214 is advertising itself as >> origin for all of our prefixes. Their anomaly report shows thousands >> of prefixes originating there. >> >> Anyone else seeing evidence of this or being affected? >> >> >> [1] http://cyclops.cs.ucla.edu/ >> > > I'm seeing alerts for AS13214 advertising our prefixes from > cyclops also. However a quick look at a few looking glasses and route > servers doesnt seem to show any rogue advertisments, and we havent see > any drop in traffic as yet. > > Vince > >> >> -- >> Jay Hennigan - CCIE #7880 - Network Engineering - jay at impulse.net >> Impulse Internet Service - http://www.impulse.net/ >> Your local telephone and internet company - 805 884-6323 - WB6RDV > > "Ravioli is the square root of pasta." - Max K., Age 11 From bmanning at vacation.karoshi.com Mon May 11 11:45:30 2009 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Mon, 11 May 2009 16:45:30 +0000 Subject: Anomalies with AS13214 ? In-Reply-To: References: <4A08448A.7020403@west.net> Message-ID: <20090511164530.GA2168@vacation.karoshi.com.> anyone but me find it "unusual" that we accept behaviours by some that we would find unacceptable by others... its stuff like that which provides my strongest motivation for things like SIDR... --bill On Mon, May 11, 2009 at 05:41:36PM +0100, David Freedman wrote: > Randy doing testing again? > > > Jay Hennigan wrote: > > We're getting cyclops[1] alerts that AS13214 is advertising itself as > > origin for all of our prefixes. Their anomaly report shows thousands of > > prefixes originating there. > > > > Anyone else seeing evidence of this or being affected? > > > > > > [1] http://cyclops.cs.ucla.edu/ > > > > > > -- > > Jay Hennigan - CCIE #7880 - Network Engineering - jay at impulse.net > > Impulse Internet Service - http://www.impulse.net/ > > Your local telephone and internet company - 805 884-6323 - WB6RDV > > > > > From david.freedman at uk.clara.net Mon May 11 11:47:15 2009 From: david.freedman at uk.clara.net (David Freedman) Date: Mon, 11 May 2009 17:47:15 +0100 Subject: Anomalies with AS13214 ? In-Reply-To: <75cb24520905110944x74fc6f9av3de81c4c6569315b@mail.gmail.com> References: <4A08448A.7020403@west.net> <75cb24520905110944x74fc6f9av3de81c4c6569315b@mail.gmail.com> Message-ID: Yeah, interesting contact name on this: person: Fredrik Neij address: DCPNetworks address: Box 161 address: SE-11479 Stockholm address: Sweden mnt-by: MNT-DCP phone: +46 707 323819 nic-hdl: FN2233-RIPE source: RIPE # Filtered Christopher Morrow wrote: > On Mon, May 11, 2009 at 12:41 PM, David Freedman > wrote: >> Randy doing testing again? > > 13214 != 3130 > > From jay at west.net Mon May 11 11:55:28 2009 From: jay at west.net (Jay Hennigan) Date: Mon, 11 May 2009 09:55:28 -0700 Subject: Anomalies with AS13214 ? In-Reply-To: <00ad01c9d257$f7ae41f0$e70ac5d0$@edu> References: <4A08448A.7020403@west.net> <4A084BE6.5080501@unsane.co.uk> <8FDD3859-44C7-4865-A61F-01F5D978C13D@pandora.com> <00ad01c9d257$f7ae41f0$e70ac5d0$@edu> Message-ID: <4A085880.8020107@west.net> Robert D. Scott wrote: > It looks like Cyclops is seeing these from AS 48285, but I see no indication > they are being advertised to any production upstream provider. Our /16 is > being alerted in Cyclops, but I can not find any advert on any looking > glass. That's what I'm seeing as well. It's possible that 13214 is broken but not causing an issue except to their customers. Or 48285 is broken or just giving bad data to Cyclops. Cyclops has hundreds of monitors and this is the only one showing the issue. I suspect that if there's a real problem it isn't affecting anyone other than 48285 and maybe 13214. -- Jay Hennigan - CCIE #7880 - Network Engineering - jay at impulse.net Impulse Internet Service - http://www.impulse.net/ Your local telephone and internet company - 805 884-6323 - WB6RDV From andrey.gordon at gmail.com Mon May 11 12:01:24 2009 From: andrey.gordon at gmail.com (Andrey Gordon) Date: Mon, 11 May 2009 13:01:24 -0400 Subject: PPP multilink help In-Reply-To: <483E6B0272B0284BA86D7596C40D29F9C3811FCE19@PUR-EXCH07.ox.com> References: <90ccfc90905110737h7b0c432nfa44ac0c2f113e63@mail.gmail.com> <20090511160602.GI127@rtp-cse-489.cisco.com> <483E6B0272B0284BA86D7596C40D29F9C3811FCE19@PUR-EXCH07.ox.com> Message-ID: <90ccfc90905111001rf941083tf69ba525f7ff805d@mail.gmail.com> To address the concerns about the overhead (FTP is still transferring that file: core.bvzn#sh proc cpu hist core.bvzn 12:44:07 PM Monday May 11 2009 EST 333344444222222222222222222223333333333222222222233333222222 100 90 80 70 60 50 40 30 20 10 0....5....1....1....2....2....3....3....4....4....5....5....6 0 5 0 5 0 5 0 5 0 5 0 CPU% per second (last 60 seconds) 4 4 333334344353344455444444444554544445455664445551444445454544 100 90 80 70 60 50 40 * * 30 * * 20 * * 10 * ** ** * * ****# ***# * * * 0....5....1....1....2....2....3....3....4....4....5....5....6 0 5 0 5 0 5 0 5 0 5 0 CPU% per minute (last 60 minutes) * = maximum CPU% # = average CPU% 1 433433344444434344444444443344444433444443444433333333434444344334301332 497289281236443538550242449336950644007664423513486377362431706922208088 100 * 90 * 80 * 70 * 60 * 50 * * *** *** * *** * * * 40 ****** ****** ************* ****** ***** **** ** ************ * * * 30 ******************************************************************** *** 20 *******************************************************************#**** 10 *******************************************************************#**** 0....5....1....1....2....2....3....3....4....4....5....5....6....6....7.. 0 5 0 5 0 5 0 5 0 5 0 5 0 CPU% per hour (last 72 hours) * = maximum CPU% # = average CPU% core.bvzn#sh inv NAME: "2821 chassis", DESCR: "2821 chassis" Serial0/0/0:1 is up, line protocol is up Hardware is GT96K Serial Description: MTU 1500 bytes, BW 1536 Kbit/sec, DLY 20000 usec, reliability 255/255, txload 149/255, rxload 15/255 Encapsulation PPP, LCP Open, multilink Open Link is a member of Multilink bundle Multilink1, loopback not set Keepalive set (10 sec) Last input 00:00:00, output 00:00:00, output hang never Last clearing of "show interface" counters 14w0d Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0 Queueing strategy: weighted fair [suspended, using FIFO] FIFO output queue 0/40, 0 drops 30 second input rate 93000 bits/sec, 86 packets/sec 30 second output rate 899000 bits/sec, 122 packets/sec 105433994 packets input, 3520749026 bytes, 0 no buffer Received 0 broadcasts, 0 runts, 0 giants, 0 throttles 0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort 155813204 packets output, 1174780375 bytes, 0 underruns 0 output errors, 0 collisions, 1 interface resets 0 unknown protocol drops 0 output buffer failures, 0 output buffers swapped out 1 carrier transitions Timeslot(s) Used:1-24, SCC: 0, Transmitter delay is 0 flags Serial0/0/1:1 is up, line protocol is up Hardware is GT96K Serial Description: MTU 1500 bytes, BW 1536 Kbit/sec, DLY 20000 usec, reliability 255/255, txload 149/255, rxload 15/255 Encapsulation PPP, LCP Open, multilink Open Link is a member of Multilink bundle Multilink1, loopback not set Keepalive set (10 sec) Last input 00:00:00, output 00:00:00, output hang never Last clearing of "show interface" counters 14w0d Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0 Queueing strategy: weighted fair [suspended, using FIFO] FIFO output queue 0/40, 0 drops 30 second input rate 94000 bits/sec, 86 packets/sec 30 second output rate 898000 bits/sec, 122 packets/sec 105441924 packets input, 3518841511 bytes, 0 no buffer Received 0 broadcasts, 0 runts, 0 giants, 0 throttles 0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort 155734625 packets output, 1156759105 bytes, 0 underruns 0 output errors, 0 collisions, 1 interface resets 0 unknown protocol drops 0 output buffer failures, 0 output buffers swapped out 1 carrier transitions Timeslot(s) Used:1-24, SCC: 1, Transmitter delay is 0 flags Multilink1 is up, line protocol is up Hardware is multilink group interface Description: Verizon Business MPLS Circuit Internet address is x.x.x.150/30 MTU 1500 bytes, BW 3072 Kbit/sec, DLY 100000 usec, reliability 255/255, txload 148/255, rxload 14/255 Encapsulation PPP, LCP Open, multilink Open Listen: CDPCP Open: IPCP, loopback not set Keepalive set (10 sec) DTR is pulsed for 2 seconds on reset Last input 00:00:00, output never, output hang never Last clearing of "show interface" counters 14w0d Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 252140 Queueing strategy: Class-based queueing Output queue: 3/1000/0 (size/max total/drops) 30 second input rate 179000 bits/sec, 172 packets/sec 30 second output rate 1795000 bits/sec, 243 packets/sec 207501114 packets input, 1445648459 bytes, 0 no buffer Received 0 broadcasts, 0 runts, 0 giants, 0 throttles 42 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort 307484312 packets output, 2277871516 bytes, 0 underruns 0 output errors, 0 collisions, 3 interface resets 0 unknown protocol drops 0 output buffer failures, 0 output buffers swapped out 0 carrier transitions I also ran 6 flows worth of iperf between a server at the site and my laptop while the transfer was running (iperf -i 2 - P 6 -t 120 -c 10.1.150.4) in the same direction core.bvzn#sh policy-map int mu1 Multilink1 Service-policy output: QWAS queue stats for all priority classes: queue limit 64 packets (queue depth/total drops/no-buffer drops) 0/0/0 (pkts output/bytes output) 0/0 Class-map: VoIP (match-any) 0 packets, 0 bytes 30 second offered rate 0 bps, drop rate 0 bps Match: dscp ef (46) 0 packets, 0 bytes 30 second rate 0 bps Priority: 100 kbps, burst bytes 2500, b/w exceed drops: 0 Class-map: interactive (match-any) 31490239 packets, 14882494949 bytes 30 second offered rate 4000 bps, drop rate 0 bps Match: protocol rdesktop 10981329 packets, 1277510597 bytes 30 second rate 3000 bps Match: protocol telnet 1104192 packets, 183832229 bytes 30 second rate 0 bps Match: protocol ssh 9263601 packets, 11659456657 bytes 30 second rate 0 bps Queueing queue limit 64 packets (queue depth/total drops/no-buffer drops) 0/1103/0 (pkts output/bytes output) 31489136/14887505365 bandwidth 500 kbps Class-map: class-default (match-any) 275000011 packets, 120951145536 bytes 30 second offered rate 1494000 bps, drop rate 0 bps Match: any Queueing queue limit 64 packets (queue depth/total drops/no-buffer drops/flowdrops) 0/251092/0/251092 (pkts output/bytes output) 276085337/122442704318 Fair-queue: per-flow queue limit 16 core.bvzn# ----- Andrey Gordon [andrey.gordon at gmail.com] > From andree+nanog at toonk.nl Mon May 11 13:29:30 2009 From: andree+nanog at toonk.nl (Andree Toonk) Date: Mon, 11 May 2009 20:29:30 +0200 Subject: Anomalies with AS13214 ? In-Reply-To: <4A08448A.7020403@west.net> References: <4A08448A.7020403@west.net> Message-ID: <20090511182930.GA20954@toonk.nl> .-- My secret spy satellite informs me that at Mon, 11 May 2009, Jay Hennigan wrote: > We're getting cyclops[1] alerts that AS13214 is advertising itself as > origin for all of our prefixes. Their anomaly report shows thousands of > prefixes originating there. > > Anyone else seeing evidence of this or being affected? It seems it was picked up by route-views4. Non of the RIS peers seem to have seen this. Looking at the raw bgp data from route-views4: AS13214 leaked a full table (~266294 prefixes) with 13214 as OriginAS to AS48285 which is a routeviews4 peer. Routeviews4 saw these announcements as: ASpath 48285 13214. It seems to have happend twice: ~ 11:03:45 GMT to 12:16:31 GMT (here AS48285 start announcing a valid path to routeviews again) then a few seconds later again: ~ 12:16:36 GMT to 12:18:14 GMT After that AS48285 announced ???normal??? ASpath to routeviews again. So looks like it wasn???t a global hijack, it was only seen by one routeview peer. This is a very similar event as the one we saw on November 11 2008: http://bgpmon.net/blog/?p=80 This again shows that it???s hard to determine if an event is a ???real??? hijack or not. Some will say it???s irrelevant some want to be notified in all cases. Based on received feedback regarding the November 11 event, BGPmon.net implemented peer thresholds (http://bgpmon.net/blog/?p=88). Cheers, Andree From morrowc.lists at gmail.com Mon May 11 13:39:38 2009 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Mon, 11 May 2009 14:39:38 -0400 Subject: Anomalies with AS13214 ? In-Reply-To: <20090511182930.GA20954@toonk.nl> References: <4A08448A.7020403@west.net> <20090511182930.GA20954@toonk.nl> Message-ID: <75cb24520905111139q428b23cfo6b3aaf5dcb407c56@mail.gmail.com> On Mon, May 11, 2009 at 2:29 PM, Andree Toonk wrote: > .-- My secret spy satellite informs me that at Mon, 11 May 2009, Jay Hennigan wrote: > >> We're getting cyclops[1] alerts that AS13214 is advertising itself as >> origin for all of our prefixes. ?Their anomaly report shows thousands of >> prefixes originating there. >> >> Anyone else seeing evidence of this or being affected? > > It seems it was picked up by route-views4. Non of the RIS peers seem to have seen this. > > Looking at the raw bgp data from route-views4: > AS13214 leaked a full table (~266294 prefixes) with 13214 ?as OriginAS to AS48285 which is a routeviews4 peer. > Routeviews4 saw these announcements as: ASpath 48285 13214. > Since 48285 == robtex, is it possible TPB was just setting up a monitoring/route-feed session to robtex and either missed their outbound policy or sent them the wrong form of outbound policy (full routes not customer only routes)?? -chris From seitz at strato-rz.de Mon May 11 14:00:04 2009 From: seitz at strato-rz.de (Christian Seitz) Date: Mon, 11 May 2009 21:00:04 +0200 Subject: Anomalies with AS13214 ? In-Reply-To: <4A08448A.7020403@west.net> References: <4A08448A.7020403@west.net> Message-ID: <4A0875B4.4@strato-rz.de> Hello, Jay Hennigan wrote: > We're getting cyclops[1] alerts that AS13214 is advertising itself as > origin for all of our prefixes. Their anomaly report shows thousands of > prefixes originating there. > > Anyone else seeing evidence of this or being affected? I have also seen this today for our prefixes where Cyclops reported the as path "48285 13214". After sending an e-mail to both ASN I got the following answer from AS48285: "Our transit 13214 had interesting router problems affecting bgp origins for the entire bgp table. The next-hop and thus routing was still working fine though. Since we collect bgp data from several transits and announce it to multiple route servers and for our own publicly available bgp-tools, it looked worse than it was, but as far as we can tell it was actually never propagated by them to the Internet except to downstreams, where traffic still worked, although via an unusually short path." Regards, Christian Seitz Network Operations From rveloso at cs.ucla.edu Mon May 11 14:05:15 2009 From: rveloso at cs.ucla.edu (Ricardo Oliveira) Date: Mon, 11 May 2009 12:05:15 -0700 Subject: Anomalies with AS13214 ? In-Reply-To: <4A08448A.7020403@west.net> References: <4A08448A.7020403@west.net> Message-ID: <4426C119-52FA-4D3D-9BD5-00CEC831D964@cs.ucla.edu> Hi all, First, thanks for using Cyclops, and thanks for all the Cyclops users that drop me a message about this. It seems some router in AS13214 decided to originate all the prefixes and send them to AS48285 in the Caymans, all the ASPATHs are 48285 13214. The first announcement was on 2009-05-11 11:03:11 UTC and last on 2009-05-11 12:16:32 UTC, there were 266,289 prefixes leaked (they were withdrawn afterwards) As indicated in the Cyclops alerts, only a single monitor(AS48285) in route-views4 detected this leak. I checked on other neighbors of AS13214 and they seem fine, so it seems it was only a single router issue. This incident shows the advantage of having a wide set of peers for detection, it seems Cyclops was the only tool to detect this incident. Given the amount of banks and financial institutions in the Caymans, i would otherwise have raised a red flag, but it seems this case was an unintentional misconfig by AS13214. Would appreciate any further comment on the tool, and happy cyclopying! --Ricardo the Cyclops guy http://cyclops.cs.ucla.edu On May 11, 2009, at 8:30 AM, Jay Hennigan wrote: > We're getting cyclops[1] alerts that AS13214 is advertising itself > as origin for all of our prefixes. Their anomaly report shows > thousands of prefixes originating there. > > Anyone else seeing evidence of this or being affected? > > > [1] http://cyclops.cs.ucla.edu/ > > > -- > Jay Hennigan - CCIE #7880 - Network Engineering - jay at impulse.net > Impulse Internet Service - http://www.impulse.net/ > Your local telephone and internet company - 805 884-6323 - WB6RDV From jlewis at packetnexus.com Mon May 11 14:33:46 2009 From: jlewis at packetnexus.com (Jason Lewis) Date: Mon, 11 May 2009 15:33:46 -0400 Subject: Speaking of weird ASPATHs Message-ID: <4A087D9A.8020906@packetnexus.com> I started seeing these on May 8th. * 95.87.192.0/18 3257 9070 43561 {196738} * 8928 9070 43561 {196738} *> 8928 9070 43561 {196738} * 1273 9050 8866 43561 {196738} * 6762 8400 8866 43561 {196738} From hank at efes.iucc.ac.il Mon May 11 14:45:25 2009 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Mon, 11 May 2009 22:45:25 +0300 (IDT) Subject: Anomalies with AS13214 ? In-Reply-To: <20090511164530.GA2168@vacation.karoshi.com.> References: <4A08448A.7020403@west.net> <20090511164530.GA2168@vacation.karoshi.com.> Message-ID: On Mon, 11 May 2009, bmanning at vacation.karoshi.com wrote: I certainly do. This time it is a config error, next time it will be researcher X doing some testing for a NANOG paper, and the time after that it will be some RBN test to see if anyone cares anymore to look deeply into what they are trying to pull off. Our level of sensitivity will eventually be nullified and we will all be the worse for it. -Hank > > > anyone but me find it "unusual" that we accept behaviours > by some that we would find unacceptable by others... > > its stuff like that which provides my strongest motivation > for things like SIDR... > > --bill > > > On Mon, May 11, 2009 at 05:41:36PM +0100, David Freedman wrote: >> Randy doing testing again? >> >> >> Jay Hennigan wrote: >>> We're getting cyclops[1] alerts that AS13214 is advertising itself as >>> origin for all of our prefixes. Their anomaly report shows thousands of >>> prefixes originating there. >>> >>> Anyone else seeing evidence of this or being affected? >>> >>> >>> [1] http://cyclops.cs.ucla.edu/ >>> >>> >>> -- >>> Jay Hennigan - CCIE #7880 - Network Engineering - jay at impulse.net >>> Impulse Internet Service - http://www.impulse.net/ >>> Your local telephone and internet company - 805 884-6323 - WB6RDV >>> >>> >> > From jeroen at unfix.org Mon May 11 15:06:05 2009 From: jeroen at unfix.org (Jeroen Massar) Date: Mon, 11 May 2009 22:06:05 +0200 Subject: Speaking of weird ASPATHs In-Reply-To: <4A087D9A.8020906@packetnexus.com> References: <4A087D9A.8020906@packetnexus.com> Message-ID: <4A08852D.5090206@spaghetti.zurich.ibm.com> Jason Lewis wrote: > I started seeing these on May 8th. > > * 95.87.192.0/18 3257 9070 43561 {196738} > * 8928 9070 43561 {196738} > *> 8928 9070 43561 {196738} > * 1273 9050 8866 43561 {196738} > * 6762 8400 8866 43561 {196738} > Google(32bit ASN) Greets, Jeroen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 187 bytes Desc: OpenPGP digital signature URL: From cmeidinger at sendmail.com Mon May 11 15:29:27 2009 From: cmeidinger at sendmail.com (Chris Meidinger) Date: Mon, 11 May 2009 22:29:27 +0200 Subject: two interfaces one subnet Message-ID: <4B3726C0-20FE-4598-B4DA-44FA74FDFC71@sendmail.com> Hi, This is a pretty moronic question, but I've been searching RFC's on- and-off for a couple of weeks and can't find an answer. So I'm hoping someone here will know it offhand. I've been looking through RFC's trying to find a clear statement that having two interfaces in the same subnet does not work, but can't find it that statement anywhere. The OS in this case is Linux. I know it can be done with clever routing and prioritization and such, but this has to do with vanilla config, just setting up two interfaces in one network. I would be grateful for a pointer to such an RFC statement, assuming it exists. Thanks! Chris From patrick at ianai.net Mon May 11 15:34:05 2009 From: patrick at ianai.net (Patrick W. Gilmore) Date: Mon, 11 May 2009 16:34:05 -0400 Subject: two interfaces one subnet In-Reply-To: <4B3726C0-20FE-4598-B4DA-44FA74FDFC71@sendmail.com> References: <4B3726C0-20FE-4598-B4DA-44FA74FDFC71@sendmail.com> Message-ID: <4183F952-A7B3-41E3-9C6B-FDB8245B301F@ianai.net> On May 11, 2009, at 4:29 PM, Chris Meidinger wrote: > This is a pretty moronic question, but I've been searching RFC's on- > and-off for a couple of weeks and can't find an answer. So I'm > hoping someone here will know it offhand. > > I've been looking through RFC's trying to find a clear statement > that having two interfaces in the same subnet does not work, but > can't find it that statement anywhere. > > The OS in this case is Linux. I know it can be done with clever > routing and prioritization and such, but this has to do with vanilla > config, just setting up two interfaces in one network. > > I would be grateful for a pointer to such an RFC statement, assuming > it exists. Why would an RFC prohibit this? Most _implementations_ do, but as far as network "rules" in general it is a valid configuration. -- TTFN, patrick From swmike at swm.pp.se Mon May 11 15:39:08 2009 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Mon, 11 May 2009 22:39:08 +0200 (CEST) Subject: two interfaces one subnet In-Reply-To: <4B3726C0-20FE-4598-B4DA-44FA74FDFC71@sendmail.com> References: <4B3726C0-20FE-4598-B4DA-44FA74FDFC71@sendmail.com> Message-ID: On Mon, 11 May 2009, Chris Meidinger wrote: > I've been looking through RFC's trying to find a clear statement that > having two interfaces in the same subnet does not work, but can't find > it that statement anywhere. I don't know if it still works, but it did in Linux little over 10 years back. Proxy-arp:ed all the IPs in the /27 in the /24 and everything was fine (legacy reasons plus radiolink which I didn't want to run a lot of broadcasts over). There are "legitimate" cases where you might want to do this. -- Mikael Abrahamsson email: swmike at swm.pp.se From cmeidinger at sendmail.com Mon May 11 15:45:53 2009 From: cmeidinger at sendmail.com (Chris Meidinger) Date: Mon, 11 May 2009 22:45:53 +0200 Subject: two interfaces one subnet In-Reply-To: <4183F952-A7B3-41E3-9C6B-FDB8245B301F@ianai.net> References: <4B3726C0-20FE-4598-B4DA-44FA74FDFC71@sendmail.com> <4183F952-A7B3-41E3-9C6B-FDB8245B301F@ianai.net> Message-ID: <388309A6-5E66-45C9-9F7C-65FAC8475CC1@sendmail.com> On 11.05.2009, at 22:34, Patrick W. Gilmore wrote: > On May 11, 2009, at 4:29 PM, Chris Meidinger wrote: > >> I would be grateful for a pointer to such an RFC statement, >> assuming it exists. > > Why would an RFC prohibit this? > > Most _implementations_ do, but as far as network "rules" in general > it is a valid configuration. That was essentially my conclusion as well: logically it can't work, but I wasn't certain where it might be forbidden. Thusly did I come to NANOG with the question, thinking smarter people than I might know. If it's completely down to implementation, or really to the interaction between TCP and underlying IP, then so be it. I was hoping that I might just not have thought of the right place to look. On 11.05.2009, at 22:39, Mikael Abrahamsson wrote: > On Mon, 11 May 2009, Chris Meidinger wrote: > >> I've been looking through RFC's trying to find a clear statement >> that having two interfaces in the same subnet does not work, but >> can't find it that statement anywhere. > > I don't know if it still works, but it did in Linux little over 10 > years back. Proxy-arp:ed all the IPs in the /27 in the /24 and > everything was fine (legacy reasons plus radiolink which I didn't > want to run a lot of broadcasts over). There are "legitimate" cases > where you might want to do this. Yes, I've gotten it to work as well as little as 10 days ago, but it's not something that $random_customer should be doing as a matter of practice. Thus, again, my hope that I just wasn't thinking of the right place to look to find an IETF recommendation against doing so. Thanks for the input! Chris From duane.waddle at gmail.com Mon May 11 15:48:54 2009 From: duane.waddle at gmail.com (Duane Waddle) Date: Mon, 11 May 2009 15:48:54 -0500 Subject: two interfaces one subnet In-Reply-To: References: <4B3726C0-20FE-4598-B4DA-44FA74FDFC71@sendmail.com> Message-ID: <80e7195b0905111348m6da9d190g1e81049960bc5d06@mail.gmail.com> On Mon, May 11, 2009 at 3:39 PM, Mikael Abrahamsson wrote: > ... There are "legitimate" cases where you might want to do > this. > NetApp filers consider this to be a legitimate configuration, even a "supported and recommended one". If I understand the documentation correctly, NetApp will (somehow) remember the physical interface a request arrived on, and make sure to its send replies out same. It sounds like a slight breakage of the expected behavior in order to gain load-sharing for their multiple NICs attached to the same subnet. IIRC, you can turn the feature off if it makes an issue. --D From charles at thewybles.com Mon May 11 16:00:30 2009 From: charles at thewybles.com (Charles Wyble) Date: Mon, 11 May 2009 14:00:30 -0700 Subject: two interfaces one subnet In-Reply-To: References: <4B3726C0-20FE-4598-B4DA-44FA74FDFC71@sendmail.com> Message-ID: <4A0891EE.4010208@thewybles.com> What does two interfaces in one subnet mean? Two NICs? Or virtual interfaces? Mikael Abrahamsson wrote: > On Mon, 11 May 2009, Chris Meidinger wrote: > >> I've been looking through RFC's trying to find a clear statement that >> having two interfaces in the same subnet does not work, but can't find >> it that statement anywhere. > > I don't know if it still works, but it did in Linux little over 10 years > back. Proxy-arp:ed all the IPs in the /27 in the /24 and everything was > fine (legacy reasons plus radiolink which I didn't want to run a lot of > broadcasts over). There are "legitimate" cases where you might want to > do this. > From cmeidinger at sendmail.com Mon May 11 16:03:23 2009 From: cmeidinger at sendmail.com (Chris Meidinger) Date: Mon, 11 May 2009 23:03:23 +0200 Subject: two interfaces one subnet In-Reply-To: <4A0891EE.4010208@thewybles.com> References: <4B3726C0-20FE-4598-B4DA-44FA74FDFC71@sendmail.com> <4A0891EE.4010208@thewybles.com> Message-ID: <78E4FA4D-5C1F-4455-91BA-C425C89C7840@sendmail.com> On 11.05.2009, at 23:00, Charles Wyble wrote: > What does two interfaces in one subnet mean? > > Two NICs? Or virtual interfaces? Two NICs, as in physical interfaces. From r.hyunseog at ieee.org Mon May 11 16:19:56 2009 From: r.hyunseog at ieee.org (Alex H. Ryu) Date: Mon, 11 May 2009 16:19:56 -0500 Subject: two interfaces one subnet In-Reply-To: <4B3726C0-20FE-4598-B4DA-44FA74FDFC71@sendmail.com> References: <4B3726C0-20FE-4598-B4DA-44FA74FDFC71@sendmail.com> Message-ID: <4A08967C.7010901@ieee.org> Unless you configure Layer 2 for two interfaces, it's not going to work. It is invalid from networking principle. If you have to send the traffic for host in same subnet you configured, which interface it should send out ? Basically it may create broadcast storm loop by putting two ip addresses in same subnet in different interface. It may be allowed from host-level, but from router equipment, I don't think it was allowed at all. Alex Chris Meidinger wrote: > Hi, > > This is a pretty moronic question, but I've been searching RFC's > on-and-off for a couple of weeks and can't find an answer. So I'm > hoping someone here will know it offhand. > > I've been looking through RFC's trying to find a clear statement that > having two interfaces in the same subnet does not work, but can't find > it that statement anywhere. > > The OS in this case is Linux. I know it can be done with clever > routing and prioritization and such, but this has to do with vanilla > config, just setting up two interfaces in one network. > > I would be grateful for a pointer to such an RFC statement, assuming > it exists. > > Thanks! > > Chris > > > From ddevereauxweber at gmail.com Mon May 11 16:22:37 2009 From: ddevereauxweber at gmail.com (David Devereaux-Weber) Date: Mon, 11 May 2009 16:22:37 -0500 Subject: two interfaces one subnet In-Reply-To: <4B3726C0-20FE-4598-B4DA-44FA74FDFC71@sendmail.com> References: <4B3726C0-20FE-4598-B4DA-44FA74FDFC71@sendmail.com> Message-ID: Chris, I work with iHDTV , a project that sends uncompressed high definition television (1.5 Gbps) as UDP over two 1 Gbps interfaces. If both interfaces are on the same subnet, the OS sees the same router (gateway) address on both interfaces, and the results are sub-optimal ... around 50% packet loss. Dave On Mon, May 11, 2009 at 3:29 PM, Chris Meidinger wrote: > Hi, > > This is a pretty moronic question, but I've been searching RFC's on-and-off > for a couple of weeks and can't find an answer. So I'm hoping someone here > will know it offhand. > > I've been looking through RFC's trying to find a clear statement that > having two interfaces in the same subnet does not work, but can't find it > that statement anywhere. > > The OS in this case is Linux. I know it can be done with clever routing and > prioritization and such, but this has to do with vanilla config, just > setting up two interfaces in one network. > > I would be grateful for a pointer to such an RFC statement, assuming it > exists. > > Thanks! > > Chris > > From cmeidinger at sendmail.com Mon May 11 16:23:11 2009 From: cmeidinger at sendmail.com (Chris Meidinger) Date: Mon, 11 May 2009 23:23:11 +0200 Subject: two interfaces one subnet In-Reply-To: <4A08967C.7010901@ieee.org> References: <4B3726C0-20FE-4598-B4DA-44FA74FDFC71@sendmail.com> <4A08967C.7010901@ieee.org> Message-ID: <6479299C-8F4E-4D11-BEDD-8690AE2DF7D0@sendmail.com> On 11.05.2009, at 23:19, Alex H. Ryu wrote: > Unless you configure Layer 2 for two interfaces, it's not going to > work. > It is invalid from networking principle. > If you have to send the traffic for host in same subnet you > configured, > which interface it should send out ? > Basically it may create broadcast storm loop by putting two ip > addresses > in same subnet in different interface. > It may be allowed from host-level, but from router equipment, I don't > think it was allowed at all. Alex, I _personally_ know that it's a problem. I was hoping for an RFC- reference, or similar standards document, to show to customers to convince them to stop trying to hack things to make it work. Chris From hectorherrera at gmail.com Mon May 11 16:28:07 2009 From: hectorherrera at gmail.com (Hector Herrera) Date: Mon, 11 May 2009 14:28:07 -0700 Subject: two interfaces one subnet In-Reply-To: References: <4B3726C0-20FE-4598-B4DA-44FA74FDFC71@sendmail.com> Message-ID: On Mon, May 11, 2009 at 2:22 PM, David Devereaux-Weber wrote: > Chris, > > I work with iHDTV , a project that sends uncompressed high > definition television (1.5 Gbps) as UDP over two 1 Gbps interfaces. ?If both > interfaces are on the same subnet, the OS sees the same router (gateway) > address on both interfaces, and the results are sub-optimal ... around 50% > packet loss. packet loss is probably due to the network switch having to re-learn the location of the MAC address constantly as it sees packets on two or more ports with the same MAC address (think STP loops). If your network stack and network device (switch) supports LACP, then you can have multiple connections between a host and a network device. That is a very easy way to increase capacity and add redundancy. That is how all of our VMWare ESX 3.5i servers are connected. Hector From dwhite at olp.net Mon May 11 16:31:31 2009 From: dwhite at olp.net (Dan White) Date: Mon, 11 May 2009 16:31:31 -0500 Subject: two interfaces one subnet In-Reply-To: <4B3726C0-20FE-4598-B4DA-44FA74FDFC71@sendmail.com> References: <4B3726C0-20FE-4598-B4DA-44FA74FDFC71@sendmail.com> Message-ID: <4A089933.1060705@olp.net> Chris Meidinger wrote: > Hi, > > This is a pretty moronic question, but I've been searching RFC's > on-and-off for a couple of weeks and can't find an answer. So I'm > hoping someone here will know it offhand. > I've been looking through RFC's trying to find a clear statement that > having two interfaces in the same subnet does not work, but can't find > it that statement anywhere. > The OS in this case is Linux. I know it can be done with clever > routing and prioritization and such, but this has to do with vanilla > config, just setting up two interfaces in one network. > I would be grateful for a pointer to such an RFC statement, assuming > it exists. If your goal is to achieve redundancy or to increase bandwidth, you can bond the interfaces together - assuming that you have a switch / switch stack that supports 802.3ad. Then you could assign multiple IPs to the bonded interface without any layer 3 messyness. - Dan From cmeidinger at sendmail.com Mon May 11 16:38:30 2009 From: cmeidinger at sendmail.com (Chris Meidinger) Date: Mon, 11 May 2009 23:38:30 +0200 Subject: two interfaces one subnet In-Reply-To: <4A089933.1060705@olp.net> References: <4B3726C0-20FE-4598-B4DA-44FA74FDFC71@sendmail.com> <4A089933.1060705@olp.net> Message-ID: <5AF650D0-1378-494D-B4A6-09B099E64B84@sendmail.com> On 11.05.2009, at 23:31, Dan White wrote: > Chris Meidinger wrote: >> Hi, >> >> This is a pretty moronic question, but I've been searching RFC's on- >> and-off for a couple of weeks and can't find an answer. So I'm >> hoping someone here will know it offhand. >> I've been looking through RFC's trying to find a clear statement >> that having two interfaces in the same subnet does not work, but >> can't find it that statement anywhere. >> The OS in this case is Linux. I know it can be done with clever >> routing and prioritization and such, but this has to do with >> vanilla config, just setting up two interfaces in one network. >> I would be grateful for a pointer to such an RFC statement, >> assuming it exists. > > If your goal is to achieve redundancy or to increase bandwidth, you > can bond the interfaces together - assuming that you have a switch / > switch stack that supports 802.3ad. > > Then you could assign multiple IPs to the bonded interface without > any layer 3 messyness. I should have been clearer. The case in point is having two physical interfaces, each with a unique IP, in the same subnet. For example, eth0 is 10.0.0.1/24 and eth1 is 10.0.0.2/24, nothing like bonding going on. The customers usually have the idea of running one interface for administration and another for production (which is a _good_ idea) but they want to do it in the same subnet (not such a good idea...) Chris From mailvortex at gmail.com Mon May 11 16:40:33 2009 From: mailvortex at gmail.com (Ben Scott) Date: Mon, 11 May 2009 17:40:33 -0400 Subject: two interfaces one subnet In-Reply-To: References: <4B3726C0-20FE-4598-B4DA-44FA74FDFC71@sendmail.com> Message-ID: <59f980d60905111440i5b4894b6hfdfe8c3a6a5777d9@mail.gmail.com> On Mon, May 11, 2009 at 5:28 PM, Hector Herrera wrote: > On Mon, May 11, 2009 at 2:22 PM, David Devereaux-Weber > wrote: >> ... both> interfaces are on the same subnet, the OS sees the same router (gateway) >> address on both interfaces, and the results are sub-optimal ... around 50% >> packet loss. > > packet loss is probably due to the network switch having to re-learn > the location of the MAC address constantly as it sees packets on two > or more ports with the same MAC address (think STP loops). My understand of the scenario is: Two physical interfaces, each with a unique IP address, in the same Ethernet broadcast domain, on the same IP (sub)network. If that's the case, the MAC address won't change. The cards stay put. So a layer two switch will be none the wiser. The reason this doesn't work (for most implementations) is that most IP routers look only at the destination IP address, and keep no state. (Here, I'm using "router" to include the routing engine built-in to any full IP implementation, not just dedicated equipment from Cisco, et. al.) So we have a host with IP addresses A and B on the same subnet. A packet comes in from some other host X. The application software does whatever it does, and sends a response. The router looks at the destination IP address X, and sees that it has two routes, A and B. Depending on implementation, the router may send everything out the first interface it finds in the routing table (e.g., use A and ignore B), or round-robin between the two, or who-knows-what. Either way, if the packet *from* X was addressed *to* B but the response comes back from *A*, then host X is going to drop the packet as invalid/irrelevant/etc. With Linux, at least, you *can* use the routing policy database to configure the kernel router to pay attention to more than just the destination IP address. For example, you can have it look at the source IP address (A or B), and route out the appropriate interface. However, IIRC, this only works if the application software binds to individual network interfaces. If the app software just listens for anything (0.0.0.0), then the kernel gets to pick the source IP address for any response. I can post examples with gory details from our firewall, if anyone needs them. -- Ben From oberman at es.net Mon May 11 16:42:40 2009 From: oberman at es.net (Kevin Oberman) Date: Mon, 11 May 2009 14:42:40 -0700 Subject: two interfaces one subnet In-Reply-To: Your message of "Mon, 11 May 2009 16:19:56 CDT." <4A08967C.7010901@ieee.org> Message-ID: <20090511214240.56A251CC0B@ptavv.es.net> > Date: Mon, 11 May 2009 16:19:56 -0500 > From: "Alex H. Ryu" > > Unless you configure Layer 2 for two interfaces, it's not going to work. > It is invalid from networking principle. > If you have to send the traffic for host in same subnet you configured, > which interface it should send out ? > Basically it may create broadcast storm loop by putting two ip addresses > in same subnet in different interface. > It may be allowed from host-level, but from router equipment, I don't > think it was allowed at all. > > Alex I am a bit baffled as to why people think: 1. It won't work 2. It is a bad thing to do if it would work Neither is true. If it is two separate interfaces with two MAC addresses, it will work fine IF one of the interfaces is configured with a netmask of 255.255.255.255 (/32). Of course, you will have to add routes for the second interface if you expect to source traffic from it, but it really in not rare. Many network devices are intended to be configured this way. NetApp was mentioned, but it is not unique. Doing this is expressly covered in the documentation for FreeBSD. -- 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 > > > Chris Meidinger wrote: > > Hi, > > > > This is a pretty moronic question, but I've been searching RFC's > > on-and-off for a couple of weeks and can't find an answer. So I'm > > hoping someone here will know it offhand. > > > > I've been looking through RFC's trying to find a clear statement that > > having two interfaces in the same subnet does not work, but can't find > > it that statement anywhere. > > > > The OS in this case is Linux. I know it can be done with clever > > routing and prioritization and such, but this has to do with vanilla > > config, just setting up two interfaces in one network. > > > > I would be grateful for a pointer to such an RFC statement, assuming > > it exists. > > > > Thanks! > > > > Chris > > > > > > > > From chris.ranch at nokia.com Mon May 11 16:46:21 2009 From: chris.ranch at nokia.com (chris.ranch at nokia.com) Date: Mon, 11 May 2009 23:46:21 +0200 Subject: two interfaces one subnet In-Reply-To: <4B3726C0-20FE-4598-B4DA-44FA74FDFC71@sendmail.com> References: <4B3726C0-20FE-4598-B4DA-44FA74FDFC71@sendmail.com> Message-ID: Hi Chris, I remember this. I remember it in an early IP RFC, but couldn't find it in 10 minutes of searching. It had to do with intefaces cannot have overlapping address space. One of the IETF greybeards ought to know. It's been a while since I was writing code with marked up rfc's in front of me... Chris From patrick at ianai.net Mon May 11 16:47:43 2009 From: patrick at ianai.net (Patrick W. Gilmore) Date: Mon, 11 May 2009 17:47:43 -0400 Subject: two interfaces one subnet In-Reply-To: <4A08967C.7010901@ieee.org> References: <4B3726C0-20FE-4598-B4DA-44FA74FDFC71@sendmail.com> <4A08967C.7010901@ieee.org> Message-ID: On May 11, 2009, at 5:19 PM, Alex H. Ryu wrote: > Unless you configure Layer 2 for two interfaces, it's not going to > work. It can work. Of course it _may_ not, depending upon your implementation, but then some implementations can't get a single interface to work properly per subnet. > It is invalid from networking principle. You are confused, there is nothing invalid about the configuration. > If you have to send the traffic for host in same subnet you > configured, > which interface it should send out ? Pick an interface and send the packet. It's not rocket science. I can come up with half a dozen algorithms off the top of my head while typing the last sentence. > Basically it may create broadcast storm loop by putting two ip > addresses > in same subnet in different interface. That is an interesting statement. Could you explain how this can happen without crafting an idiotic implementation spec (e.g. every packet goes out both interfaces)? > It may be allowed from host-level, but from router equipment, I don't > think it was allowed at all. Ever used HSRP / VRRP? Two interfaces in the same subnet. Works fine. In fact, most people think it works _better_ than one interface in the same subnet. -- TTFN, patrick From mailvortex at gmail.com Mon May 11 16:48:30 2009 From: mailvortex at gmail.com (Ben Scott) Date: Mon, 11 May 2009 17:48:30 -0400 Subject: two interfaces one subnet In-Reply-To: <5AF650D0-1378-494D-B4A6-09B099E64B84@sendmail.com> References: <4B3726C0-20FE-4598-B4DA-44FA74FDFC71@sendmail.com> <4A089933.1060705@olp.net> <5AF650D0-1378-494D-B4A6-09B099E64B84@sendmail.com> Message-ID: <59f980d60905111448u3c4a2ef7rbc9928d2ba1a3290@mail.gmail.com> On Mon, May 11, 2009 at 5:38 PM, Chris Meidinger wrote: > For example, eth0 is 10.0.0.1/24 and eth1 is 10.0.0.2/24, nothing like > bonding going on. The customers usually have the idea of running one > interface for administration and another for production (which is a _good_ > idea) but they want to do it in the same subnet (not such a good idea...) I just posted on this, but I didn't really address your original question, so: I'm not aware of anything in the RFCs or other standards which prohibits this. But then, I haven't gone looking, because... It *can* be made to work in practice, for certain scenarios. For example, if you're talking a web server, and you bind the "production" site to 10.0.0.2 and the "administration" site to 10.0.0.1, and configure policy routing (you said Linux, right?) to route appropriately, it should work. It works because Apache can bind sites to individual interfaces. -- Ben From mjo at dojo.mi.org Mon May 11 16:39:51 2009 From: mjo at dojo.mi.org (Mike O'Connor) Date: Mon, 11 May 2009 21:39:51 +0000 Subject: two interfaces one subnet In-Reply-To: <4B3726C0-20FE-4598-B4DA-44FA74FDFC71@sendmail.com> References: <4B3726C0-20FE-4598-B4DA-44FA74FDFC71@sendmail.com> Message-ID: <20090511213951.GC28211@dojo.mi.org> :Hi, : :This is a pretty moronic question, but I've been searching RFC's on- :and-off for a couple of weeks and can't find an answer. So I'm hoping :someone here will know it offhand. : :I've been looking through RFC's trying to find a clear statement that :having two interfaces in the same subnet does not work, but can't find :it that statement anywhere. : :The OS in this case is Linux. I know it can be done with clever :routing and prioritization and such, but this has to do with vanilla :config, just setting up two interfaces in one network. : :I would be grateful for a pointer to such an RFC statement, assuming :it exists. RFC1122, Section 3.3.4.1 explicitly says this IS a legal config from an IP perspective: 3.3.4 Local Multihoming 3.3.4.1 Introduction A multihomed host has multiple IP addresses, which we may think of as "logical interfaces". These logical interfaces may be associated with one or more physical interfaces, and these physical interfaces may be connected to the same or different networks. There are other considerations here -- OS, link-layer, etc. Obviously, you want to do such things with care. But simply from a "standards" perspective, it's ok. There are a lot of hosts that historically didn't have enough RFC1122 compliance to make such configurations problematic (e.g. section 3.3.1.2 and multiple default route support vs. old BSD IP stacks) but that doesn't invalidate the standards. -- Michael J. O'Connor mjo at dojo.mi.org =--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--= "Pain has an element of blank." -Emily Dickinson From cmeidinger at sendmail.com Mon May 11 16:49:22 2009 From: cmeidinger at sendmail.com (Chris Meidinger) Date: Mon, 11 May 2009 23:49:22 +0200 Subject: two interfaces one subnet In-Reply-To: <20090511214240.56A251CC0B@ptavv.es.net> References: <20090511214240.56A251CC0B@ptavv.es.net> Message-ID: <64030A58-9C47-402E-96F4-6D07D1B62C44@sendmail.com> On 11.05.2009, at 23:42, Kevin Oberman wrote: >> Date: Mon, 11 May 2009 16:19:56 -0500 >> From: "Alex H. Ryu" >> >> Unless you configure Layer 2 for two interfaces, it's not going to >> work. >> It is invalid from networking principle. >> If you have to send the traffic for host in same subnet you >> configured, >> which interface it should send out ? >> Basically it may create broadcast storm loop by putting two ip >> addresses >> in same subnet in different interface. >> It may be allowed from host-level, but from router equipment, I don't >> think it was allowed at all. >> >> Alex > > > I am a bit baffled as to why people think: > 1. It won't work > 2. It is a bad thing to do if it would work > > Neither is true. If it is two separate interfaces with two MAC > addresses, it will work fine IF one of the interfaces is configured > with > a netmask of 255.255.255.255 (/32). Of course, you will have to add > routes for the second interface if you expect to source traffic from > it, > but it really in not rare. This is, of course, how I've done it at times in the past. Routing management can, however, become quite a pain over time. The customer expectation is, naturally, that any traffic related to a connection that comes in to the first interface should go back out that interface, and anything related to a connection that came into the second interface should go back out there. (All this without any specific routing etc.) I think we both know that that's not going to happen automagically. Chris From oberman at es.net Mon May 11 16:50:28 2009 From: oberman at es.net (Kevin Oberman) Date: Mon, 11 May 2009 14:50:28 -0700 Subject: two interfaces one subnet In-Reply-To: Your message of "Mon, 11 May 2009 23:38:30 +0200." <5AF650D0-1378-494D-B4A6-09B099E64B84@sendmail.com> Message-ID: <20090511215028.136B61CC0B@ptavv.es.net> > From: Chris Meidinger > Date: Mon, 11 May 2009 23:38:30 +0200 > > On 11.05.2009, at 23:31, Dan White wrote: > > > Chris Meidinger wrote: > >> Hi, > >> > >> This is a pretty moronic question, but I've been searching RFC's on- > >> and-off for a couple of weeks and can't find an answer. So I'm > >> hoping someone here will know it offhand. > >> I've been looking through RFC's trying to find a clear statement > >> that having two interfaces in the same subnet does not work, but > >> can't find it that statement anywhere. > >> The OS in this case is Linux. I know it can be done with clever > >> routing and prioritization and such, but this has to do with > >> vanilla config, just setting up two interfaces in one network. > >> I would be grateful for a pointer to such an RFC statement, > >> assuming it exists. > > > > If your goal is to achieve redundancy or to increase bandwidth, you > > can bond the interfaces together - assuming that you have a switch / > > switch stack that supports 802.3ad. > > > > Then you could assign multiple IPs to the bonded interface without > > any layer 3 messyness. > > I should have been clearer. The case in point is having two physical > interfaces, each with a unique IP, in the same subnet. > > For example, eth0 is 10.0.0.1/24 and eth1 is 10.0.0.2/24, nothing like > bonding going on. The customers usually have the idea of running one > interface for administration and another for production (which is a > _good_ idea) but they want to do it in the same subnet (not such a > good idea...) This will not work right. One interface can be 10.0.0.1/24, but any added interfaces would need to be /32 (10.0.0.2/32). What your customer wants can probably be done, but it is a really bad idea. Put them in different subnets. If you need to, break off a /30 from the /24. (That is a bit messy as you meed to break the /24 into a /25, a /26, a /27..., but it should work fine. Since the main interface has to talk to ALL of the subnets, you will need to use one address from each and that is pretty wasteful, but it should work.) Just really UGLY! If only a part of the address space need be used, it gets easier and less ugly. If a /25 will work, it's pretty much normal configuration on both interfaces. -- 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 MatlockK at exempla.org Mon May 11 16:50:42 2009 From: MatlockK at exempla.org (Matlock, Kenneth L) Date: Mon, 11 May 2009 15:50:42 -0600 Subject: two interfaces one subnet In-Reply-To: <5AF650D0-1378-494D-B4A6-09B099E64B84@sendmail.com> References: <4B3726C0-20FE-4598-B4DA-44FA74FDFC71@sendmail.com><4A089933.1060705@olp.net> <5AF650D0-1378-494D-B4A6-09B099E64B84@sendmail.com> Message-ID: <4288131ED5E3024C9CD4782CECCAD2C7065D35B7@LMC-MAIL2.exempla.org> If it were me and had the requirement of having both NICs in the same L2 segment, but unique IP addresses, I'd assign a secondary IP address to the Layer3 SVI on the upstream device, and give the 2nd NIC on the server an IP on that secondary IP block. Ken Matlock Network Analyst Exempla Healthcare (303) 467-4671 matlockk at exempla.org -----Original Message----- From: Chris Meidinger [mailto:cmeidinger at sendmail.com] Sent: Monday, May 11, 2009 3:39 PM To: Dan White Cc: nanog at nanog.org Subject: Re: two interfaces one subnet On 11.05.2009, at 23:31, Dan White wrote: > Chris Meidinger wrote: >> Hi, >> >> This is a pretty moronic question, but I've been searching RFC's on- >> and-off for a couple of weeks and can't find an answer. So I'm >> hoping someone here will know it offhand. >> I've been looking through RFC's trying to find a clear statement >> that having two interfaces in the same subnet does not work, but >> can't find it that statement anywhere. >> The OS in this case is Linux. I know it can be done with clever >> routing and prioritization and such, but this has to do with >> vanilla config, just setting up two interfaces in one network. >> I would be grateful for a pointer to such an RFC statement, >> assuming it exists. > > If your goal is to achieve redundancy or to increase bandwidth, you > can bond the interfaces together - assuming that you have a switch / > switch stack that supports 802.3ad. > > Then you could assign multiple IPs to the bonded interface without > any layer 3 messyness. I should have been clearer. The case in point is having two physical interfaces, each with a unique IP, in the same subnet. For example, eth0 is 10.0.0.1/24 and eth1 is 10.0.0.2/24, nothing like bonding going on. The customers usually have the idea of running one interface for administration and another for production (which is a _good_ idea) but they want to do it in the same subnet (not such a good idea...) Chris From patrick at ianai.net Mon May 11 16:51:58 2009 From: patrick at ianai.net (Patrick W. Gilmore) Date: Mon, 11 May 2009 17:51:58 -0400 Subject: two interfaces one subnet In-Reply-To: <388309A6-5E66-45C9-9F7C-65FAC8475CC1@sendmail.com> References: <4B3726C0-20FE-4598-B4DA-44FA74FDFC71@sendmail.com><4183F952-A7B3-41E3-9C6B-FDB8245B301F@ianai.net> <388309A6-5E66-45C9-9F7C-65FAC8475CC1@sendmail.com> Message-ID: On May 11, 2009, at 4:45 PM, Chris Meidinger wrote: > On 11.05.2009, at 22:34, Patrick W. Gilmore wrote: > >> On May 11, 2009, at 4:29 PM, Chris Meidinger wrote: >> >>> I would be grateful for a pointer to such an RFC statement, >>> assuming it exists. >> >> Why would an RFC prohibit this? >> >> Most _implementations_ do, but as far as network "rules" in general >> it is a valid configuration. > > That was essentially my conclusion as well: logically it can't work, > but I wasn't certain where it might be forbidden. How did you read what I wrote and say what you said? I've read it several times and I can't get from point A to point B. Did you do a major typo or something? I said it is valid. After saying you came to the same conclusion, you then said "logically it can't work". Your statement not only contradicts what I said, but contradicts the fact is has and does work. Let me be clear: IT IS NOT FORBIDDEN. IT WORKS FINE. -- TTFN, patrick From bruns at 2mbit.com Mon May 11 16:52:19 2009 From: bruns at 2mbit.com (Brielle Bruns) Date: Mon, 11 May 2009 15:52:19 -0600 Subject: two interfaces one subnet In-Reply-To: <6479299C-8F4E-4D11-BEDD-8690AE2DF7D0@sendmail.com> References: <4B3726C0-20FE-4598-B4DA-44FA74FDFC71@sendmail.com> <4A08967C.7010901@ieee.org> <6479299C-8F4E-4D11-BEDD-8690AE2DF7D0@sendmail.com> Message-ID: <4A089E13.2080708@2mbit.com> On 5/11/09 3:23 PM, Chris Meidinger wrote: > On 11.05.2009, at 23:19, Alex H. Ryu wrote: > >> Unless you configure Layer 2 for two interfaces, it's not going to work. >> It is invalid from networking principle. >> If you have to send the traffic for host in same subnet you configured, >> which interface it should send out ? >> Basically it may create broadcast storm loop by putting two ip addresses >> in same subnet in different interface. >> It may be allowed from host-level, but from router equipment, I don't >> think it was allowed at all. > > Alex, I _personally_ know that it's a problem. I was hoping for an > RFC-reference, or similar standards document, to show to customers to > convince them to stop trying to hack things to make it work. > > Chris > In Linux, I ran into the exact situation talked about in the link: http://lwn.net/Articles/45373/ Basically, recent versions of Linux will respond to arp requests for IPs on another interface on the receiving interface. Basically, you end up with traffic going in/out of unexpected interfaces. I discovered my iptables rules weren't quite working right and I couldn't get into one of my boxen because the allow was set to eth0, and the packets were coming in/out of eth1 even though the IP was bound to eth0. One of the more interesting gotchas that had me stumped for hours before I found out what was really going on. -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org / http://www.ahbl.org From cmeidinger at sendmail.com Mon May 11 16:59:18 2009 From: cmeidinger at sendmail.com (Chris Meidinger) Date: Mon, 11 May 2009 23:59:18 +0200 Subject: two interfaces one subnet In-Reply-To: <59f980d60905111448u3c4a2ef7rbc9928d2ba1a3290@mail.gmail.com> References: <4B3726C0-20FE-4598-B4DA-44FA74FDFC71@sendmail.com> <4A089933.1060705@olp.net> <5AF650D0-1378-494D-B4A6-09B099E64B84@sendmail.com> <59f980d60905111448u3c4a2ef7rbc9928d2ba1a3290@mail.gmail.com> Message-ID: <79EB9847-01DA-47F3-921F-DFF996598188@sendmail.com> On 11.05.2009, at 23:48, Ben Scott wrote: > On Mon, May 11, 2009 at 5:38 PM, Chris Meidinger > wrote: >> For example, eth0 is 10.0.0.1/24 and eth1 is 10.0.0.2/24, nothing >> like >> bonding going on. The customers usually have the idea of running one >> interface for administration and another for production (which is a >> _good_ >> idea) but they want to do it in the same subnet (not such a good >> idea...) > > I just posted on this, but I didn't really address your original > question, so: I'm not aware of anything in the RFCs or other standards > which prohibits this. But then, I haven't gone looking, because... > > It *can* be made to work in practice, for certain scenarios. For > example, if you're talking a web server, and you bind the "production" > site to 10.0.0.2 and the "administration" site to 10.0.0.1, and > configure policy routing (you said Linux, right?) to route > appropriately, it should work. It works because Apache can bind sites > to individual interfaces. Just to restate here, for people who have been responding both publicly and privately: I know that *I* can make it work, and I know that *you* can make it work. But I also know that it's not likely to stay working. One day, down the road, something will break. Then, my poor support team will spend days trying to diagnose the problem. So I want to stop the customer from trying to force a round peg into a square hole, and just use separate subnets for the different interfaces. As someone said before, it's not rocket science. Still though, thanks for all the input; it's really useful. Chris From cmeidinger at sendmail.com Mon May 11 17:00:52 2009 From: cmeidinger at sendmail.com (Chris Meidinger) Date: Tue, 12 May 2009 00:00:52 +0200 Subject: two interfaces one subnet - SOLVED In-Reply-To: <20090511213951.GC28211@dojo.mi.org> References: <4B3726C0-20FE-4598-B4DA-44FA74FDFC71@sendmail.com> <20090511213951.GC28211@dojo.mi.org> Message-ID: <0005EFF3-5A58-488F-864C-61549EEF031D@sendmail.com> On 11.05.2009, at 23:39, Mike O'Connor wrote: > :Hi, > : > :This is a pretty moronic question, but I've been searching RFC's on- > :and-off for a couple of weeks and can't find an answer. So I'm hoping > :someone here will know it offhand. > : > :I've been looking through RFC's trying to find a clear statement that > :having two interfaces in the same subnet does not work, but can't > find > :it that statement anywhere. > : > :The OS in this case is Linux. I know it can be done with clever > :routing and prioritization and such, but this has to do with vanilla > :config, just setting up two interfaces in one network. > : > :I would be grateful for a pointer to such an RFC statement, assuming > :it exists. > > RFC1122, Section 3.3.4.1 explicitly says this IS a legal config > from an IP perspective: > > 3.3.4 Local Multihoming > > 3.3.4.1 Introduction > > A multihomed host has multiple IP addresses, which we may > think of as "logical interfaces". These logical interfaces > may be associated with one or more physical interfaces, and > these physical interfaces may be connected to the same or > different networks. > > There are other considerations here -- OS, link-layer, etc. > Obviously, you want to do such things with care. But simply > from a "standards" perspective, it's ok. There are a lot of > hosts that historically didn't have enough RFC1122 compliance > to make such configurations problematic (e.g. section 3.3.1.2 > and multiple default route support vs. old BSD IP stacks) but > that doesn't invalidate the standards. Thank you! This is what I (wasn't) looking for, but was destined to find. I'll look for other arguments against the practice. And again, because I didn't say it before: Thanks for the pointer!! This is just what I was looking for to stop looking. Best, Chris From patrick at ianai.net Mon May 11 17:01:29 2009 From: patrick at ianai.net (Patrick W. Gilmore) Date: Mon, 11 May 2009 18:01:29 -0400 Subject: two interfaces one subnet In-Reply-To: <59f980d60905111440i5b4894b6hfdfe8c3a6a5777d9@mail.gmail.com> References: <4B3726C0-20FE-4598-B4DA-44FA74FDFC71@sendmail.com> <59f980d60905111440i5b4894b6hfdfe8c3a6a5777d9@mail.gmail.com> Message-ID: On May 11, 2009, at 5:40 PM, Ben Scott wrote: > On Mon, May 11, 2009 at 5:28 PM, Hector Herrera > wrote: >> On Mon, May 11, 2009 at 2:22 PM, David Devereaux-Weber >> wrote: >>> ... both> interfaces are on the same subnet, the OS sees the same >>> router (gateway) >>> address on both interfaces, and the results are sub-optimal ... >>> around 50% >>> packet loss. >> >> packet loss is probably due to the network switch having to re-learn >> the location of the MAC address constantly as it sees packets on two >> or more ports with the same MAC address (think STP loops). > > My understand of the scenario is: Two physical interfaces, each with > a unique IP address, in the same Ethernet broadcast domain, on the > same IP (sub)network. > > If that's the case, the MAC address won't change. The cards stay > put. So a layer two switch will be none the wiser. > > The reason this doesn't work (for most implementations) is that most > IP routers look only at the destination IP address, and keep no state. > (Here, I'm using "router" to include the routing engine built-in to > any full IP implementation, not just dedicated equipment from Cisco, > et. al.) > > So we have a host with IP addresses A and B on the same subnet. A > packet comes in from some other host X. The application software does > whatever it does, and sends a response. The router looks at the > destination IP address X, and sees that it has two routes, A and B. > > Depending on implementation, the router may send everything out the > first interface it finds in the routing table (e.g., use A and ignore > B), or round-robin between the two, or who-knows-what. Either way, if > the packet *from* X was addressed *to* B but the response comes back > from *A*, then host X is going to drop the packet as > invalid/irrelevant/etc. You are assuming facts not in evidence. It doesn't matter which physical interface transmits the packet. For instance, if I ping a router's loopback interface, there is nothing stopping the router from making the loopback the source IP address of the return packet even though the (virtual) loopback interface _obviously_ did not physically transmit the packet. Another example: Imagine a web server with two uplinks in _different_ subnets running Quagga. Now assume the web server gets an HTTP request and the route back to the requesting host changes before all the packets are returned. Does the download break? Sure, if you use an implementation too broken for words. If not, things work just fine. Could everyone please stop coming up with "if people are stupid and break things, things don't work" examples. We all agree on that. Back in reality land, things that broken tend not to be used. (And please no jokes about cisco or microsoft or whatever.) -- TTFN, patrick > With Linux, at least, you *can* use the routing policy database to > configure the kernel router to pay attention to more than just the > destination IP address. For example, you can have it look at the > source IP address (A or B), and route out the appropriate interface. > However, IIRC, this only works if the application software binds to > individual network interfaces. If the app software just listens for > anything (0.0.0.0), then the kernel gets to pick the source IP address > for any response. > > I can post examples with gory details from our firewall, if anyone > needs them. > > -- Ben > From ddevereauxweber at gmail.com Mon May 11 17:08:45 2009 From: ddevereauxweber at gmail.com (David Devereaux-Weber) Date: Mon, 11 May 2009 17:08:45 -0500 Subject: two interfaces one subnet In-Reply-To: References: <4B3726C0-20FE-4598-B4DA-44FA74FDFC71@sendmail.com> Message-ID: In my case, each Ethernet interface has its own unique MAC address. Dave On Mon, May 11, 2009 at 4:28 PM, Hector Herrera wrote: > On Mon, May 11, 2009 at 2:22 PM, David Devereaux-Weber > wrote: > > Chris, > > > > I work with iHDTV , a project that sends uncompressed > high > > definition television (1.5 Gbps) as UDP over two 1 Gbps interfaces. If > both > > interfaces are on the same subnet, the OS sees the same router (gateway) > > address on both interfaces, and the results are sub-optimal ... around > 50% > > packet loss. > > packet loss is probably due to the network switch having to re-learn > the location of the MAC address constantly as it sees packets on two > or more ports with the same MAC address (think STP loops). > > If your network stack and network device (switch) supports LACP, then > you can have multiple connections between a host and a network device. > That is a very easy way to increase capacity and add redundancy. > > That is how all of our VMWare ESX 3.5i servers are connected. > > Hector > From nanog at daork.net Mon May 11 17:08:49 2009 From: nanog at daork.net (Nathan Ward) Date: Tue, 12 May 2009 10:08:49 +1200 Subject: two interfaces one subnet In-Reply-To: <4A0891EE.4010208@thewybles.com> References: <4B3726C0-20FE-4598-B4DA-44FA74FDFC71@sendmail.com> <4A0891EE.4010208@thewybles.com> Message-ID: <24F5463D-C5B0-46BD-AB6A-1C376BE742EF@daork.net> On 12/05/2009, at 9:00 AM, Charles Wyble wrote: > What does two interfaces in one subnet mean? > > Two NICs? Or virtual interfaces? Also, what does one subnet mean? A. Using the same IP prefix on two different networks (ie. ethernet broadcast domains) with an interface in to each, or B. running two interfaces in to the same network (ie. ethernet broadcast domain). In the case of A, are you re-using numbers on each side? In the case of B, are you wanting both interfaces to have the same number(s)? -- Nathan Ward From arnold at nipper.de Mon May 11 17:13:19 2009 From: arnold at nipper.de (Arnold Nipper) Date: Tue, 12 May 2009 00:13:19 +0200 Subject: two interfaces one subnet In-Reply-To: References: <4B3726C0-20FE-4598-B4DA-44FA74FDFC71@sendmail.com> <4A08967C.7010901@ieee.org> Message-ID: <4A08A2FF.4040306@nipper.de> On 11.05.2009 23:47 Patrick W. Gilmore wrote > On May 11, 2009, at 5:19 PM, Alex H. Ryu wrote: > >> It may be allowed from host-level, but from router equipment, I don't >> think it was allowed at all. > > Ever used HSRP / VRRP? Two interfaces in the same subnet. Works > fine. In fact, most people think it works _better_ than one interface > in the same subnet. > I guess you are mixing interfaces with IPs now. Don't you? Arnold -- Arnold Nipper / nIPper consulting, Sandhausen, Germany email: arnold at nipper.de phone: +49 6224 9259 299 mobile: +49 172 2650958 fax: +49 6224 9259 333 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 250 bytes Desc: OpenPGP digital signature URL: From patrick at ianai.net Mon May 11 17:16:22 2009 From: patrick at ianai.net (Patrick W. Gilmore) Date: Mon, 11 May 2009 18:16:22 -0400 Subject: two interfaces one subnet In-Reply-To: <79EB9847-01DA-47F3-921F-DFF996598188@sendmail.com> References: <4B3726C0-20FE-4598-B4DA-44FA74FDFC71@sendmail.com> <4A089933.1060705@olp.net> <5AF650D0-1378-494D-B4A6-09B099E64B84@sendmail.com> <59f980d60905111448u3c4a2ef7rbc9928d2ba1a3290@mail.gmail.com> <79EB9847-01DA-47F3-921F-DFF996598188@sendmail.com> Message-ID: <1AE0407D-4A99-41B9-820D-11EF2A27A739@ianai.net> On May 11, 2009, at 5:59 PM, Chris Meidinger wrote: > Just to restate here, for people who have been responding both > publicly and privately: > > I know that *I* can make it work, and I know that *you* can make it > work. But I also know that it's not likely to stay working. > > One day, down the road, something will break. Then, my poor support > team will spend days trying to diagnose the problem. Could you show me a network configuration that does not qualify for that last sentence? Or for that matter, _anything_ related to ... well, anything? -- TTFN, patrick From patrick at ianai.net Mon May 11 17:25:02 2009 From: patrick at ianai.net (Patrick W. Gilmore) Date: Mon, 11 May 2009 18:25:02 -0400 Subject: two interfaces one subnet In-Reply-To: <4A08A2FF.4040306@nipper.de> References: <4B3726C0-20FE-4598-B4DA-44FA74FDFC71@sendmail.com> <4A08967C.7010901@ieee.org> <4A08A2FF.4040306@nipper.de> Message-ID: On May 11, 2009, at 6:13 PM, Arnold Nipper wrote: > On 11.05.2009 23:47 Patrick W. Gilmore wrote >> On May 11, 2009, at 5:19 PM, Alex H. Ryu wrote: >> >>> It may be allowed from host-level, but from router equipment, I >>> don't >>> think it was allowed at all. >> >> Ever used HSRP / VRRP? Two interfaces in the same subnet. Works >> fine. In fact, most people think it works _better_ than one >> interface >> in the same subnet. > > I guess you are mixing interfaces with IPs now. Don't you? Each interface has its own IP address. The two Interfaces _also_ share a virtual IP address. IOW: No. Are you? -- TTFN, patrick From dholmes at mwdh2o.com Mon May 11 17:27:13 2009 From: dholmes at mwdh2o.com (Holmes,David A) Date: Mon, 11 May 2009 15:27:13 -0700 Subject: two interfaces one subnet In-Reply-To: <4B3726C0-20FE-4598-B4DA-44FA74FDFC71@sendmail.com> References: <4B3726C0-20FE-4598-B4DA-44FA74FDFC71@sendmail.com> Message-ID: <485ED9BA02629E4BBBA53AC892EDA50E08E2D64D@usmsxt104.mwd.h2o> I think the idea of one interface per subnet originates in the early RFCs, such as RFC 1009 "Requirements for Internet Gateways": "Section 1.1.2 Networks and Gateways ... A gateway is connected to two or more networks, appearing to each of these networks as a connected host. Thus, it has a physical interface and an IP address on each of the connected networks ... " So by using singular terminology ( "a connected host", "a physical interface", "an IP address") instead of plural, a single interface per subnet for gateways (read routers) is implied. This is not to say that it will not work, at least on servers. Standards aside, a good reason why this is not a best practice is the concept of asynchronous routing where a packet arrives on one interface, and the reply leaves on the other interface with a different source IP on the reply. Most firewalls will reject packets such as this. -----Original Message----- From: Chris Meidinger [mailto:cmeidinger at sendmail.com] Sent: Monday, May 11, 2009 1:29 PM To: nanog at nanog.org Subject: two interfaces one subnet Hi, This is a pretty moronic question, but I've been searching RFC's on- and-off for a couple of weeks and can't find an answer. So I'm hoping someone here will know it offhand. I've been looking through RFC's trying to find a clear statement that having two interfaces in the same subnet does not work, but can't find it that statement anywhere. The OS in this case is Linux. I know it can be done with clever routing and prioritization and such, but this has to do with vanilla config, just setting up two interfaces in one network. I would be grateful for a pointer to such an RFC statement, assuming it exists. Thanks! Chris From arnold at nipper.de Mon May 11 17:35:20 2009 From: arnold at nipper.de (Arnold Nipper) Date: Tue, 12 May 2009 00:35:20 +0200 Subject: two interfaces one subnet In-Reply-To: References: <4B3726C0-20FE-4598-B4DA-44FA74FDFC71@sendmail.com> <4A08967C.7010901@ieee.org> <4A08A2FF.4040306@nipper.de> Message-ID: <4A08A828.4040104@nipper.de> On 12.05.2009 00:25 Patrick W. Gilmore wrote > On May 11, 2009, at 6:13 PM, Arnold Nipper wrote: >> On 11.05.2009 23:47 Patrick W. Gilmore wrote >>> On May 11, 2009, at 5:19 PM, Alex H. Ryu wrote: >>> >>>> It may be allowed from host-level, but from router equipment, I >>>> don't >>>> think it was allowed at all. >>> >>> Ever used HSRP / VRRP? Two interfaces in the same subnet. Works >>> fine. In fact, most people think it works _better_ than one >>> interface >>> in the same subnet. >> >> I guess you are mixing interfaces with IPs now. Don't you? > > Each interface has its own IP address. The two Interfaces _also_ > share a virtual IP address. > > IOW: No. Are you? > But still each device only has _one_ interface in the same subnet. Though with two IP addresses sometimes. Arnold -- Arnold Nipper / nIPper consulting, Sandhausen, Germany email: arnold at nipper.de phone: +49 6224 9259 299 mobile: +49 172 2650958 fax: +49 6224 9259 333 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 250 bytes Desc: OpenPGP digital signature URL: From patrick at ianai.net Mon May 11 17:37:42 2009 From: patrick at ianai.net (Patrick W. Gilmore) Date: Mon, 11 May 2009 18:37:42 -0400 Subject: two interfaces one subnet In-Reply-To: <4A08A828.4040104@nipper.de> References: <4B3726C0-20FE-4598-B4DA-44FA74FDFC71@sendmail.com> <4A08967C.7010901@ieee.org> <4A08A2FF.4040306@nipper.de> <4A08A828.4040104@nipper.de> Message-ID: On May 11, 2009, at 6:35 PM, Arnold Nipper wrote: > On 12.05.2009 00:25 Patrick W. Gilmore wrote >> On May 11, 2009, at 6:13 PM, Arnold Nipper wrote: >>> On 11.05.2009 23:47 Patrick W. Gilmore wrote >>>> On May 11, 2009, at 5:19 PM, Alex H. Ryu wrote: >>>> >>>>> It may be allowed from host-level, but from router equipment, I >>>>> don't >>>>> think it was allowed at all. >>>> >>>> Ever used HSRP / VRRP? Two interfaces in the same subnet. Works >>>> fine. In fact, most people think it works _better_ than one >>>> interface >>>> in the same subnet. >>> >>> I guess you are mixing interfaces with IPs now. Don't you? >> >> Each interface has its own IP address. The two Interfaces _also_ >> share a virtual IP address. >> >> IOW: No. Are you? >> > > But still each device only has _one_ interface in the same subnet. > Though with two IP addresses sometimes. Of course, was thinking about using it on the same router. But I guess that doesn't work so well, does it? :) -- TTFN, patrick From cmadams at hiwaay.net Mon May 11 18:29:08 2009 From: cmadams at hiwaay.net (Chris Adams) Date: Mon, 11 May 2009 18:29:08 -0500 Subject: two interfaces one subnet In-Reply-To: <20090511215028.136B61CC0B@ptavv.es.net> References: <5AF650D0-1378-494D-B4A6-09B099E64B84@sendmail.com> <20090511215028.136B61CC0B@ptavv.es.net> Message-ID: <20090511232908.GB622256@hiwaay.net> Once upon a time, Kevin Oberman said: > > From: Chris Meidinger > > For example, eth0 is 10.0.0.1/24 and eth1 is 10.0.0.2/24, nothing like > > bonding going on. The customers usually have the idea of running one > > interface for administration and another for production (which is a > > _good_ idea) but they want to do it in the same subnet (not such a > > good idea...) > > This will not work right. One interface can be 10.0.0.1/24, but any > added interfaces would need to be /32 (10.0.0.2/32). I don't know which OS(es) you are using, but that's not true in Linux. I see this all the time at home; if I plug my notebook into the wired LAN and still have the wireless enabled, both will get an IP (in the same subnet) from DHCP. The wired link is the preferred default route by default, but you can easily set up routes for some networks via the wireless link. You can also set up multipath routing to send packets out both links. I think you can also use IP policy routing to control the choice of outbound interface by rule (e.g. based on source address). -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From oberman at es.net Mon May 11 18:47:50 2009 From: oberman at es.net (Kevin Oberman) Date: Mon, 11 May 2009 16:47:50 -0700 Subject: two interfaces one subnet In-Reply-To: Your message of "Mon, 11 May 2009 18:29:08 CDT." <20090511232908.GB622256@hiwaay.net> Message-ID: <20090511234750.2804A1CC0B@ptavv.es.net> > Date: Mon, 11 May 2009 18:29:08 -0500 > From: Chris Adams > > Once upon a time, Kevin Oberman said: > > > From: Chris Meidinger > > > For example, eth0 is 10.0.0.1/24 and eth1 is 10.0.0.2/24, nothing like > > > bonding going on. The customers usually have the idea of running one > > > interface for administration and another for production (which is a > > > _good_ idea) but they want to do it in the same subnet (not such a > > > good idea...) > > > > This will not work right. One interface can be 10.0.0.1/24, but any > > added interfaces would need to be /32 (10.0.0.2/32). > > I don't know which OS(es) you are using, but that's not true in Linux. > I see this all the time at home; if I plug my notebook into the wired > LAN and still have the wireless enabled, both will get an IP (in the > same subnet) from DHCP. The wired link is the preferred default route > by default, but you can easily set up routes for some networks via the > wireless link. > > You can also set up multipath routing to send packets out both links. I > think you can also use IP policy routing to control the choice of > outbound interface by rule (e.g. based on source address). This is true if you are using the WPA supplicant. It does a bit of magic. (You can do the magic by hand without the supplicant, but it is a pain or was the last time I tried.) -- 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 mailvortex at gmail.com Mon May 11 19:04:27 2009 From: mailvortex at gmail.com (Ben Scott) Date: Mon, 11 May 2009 20:04:27 -0400 Subject: two interfaces one subnet In-Reply-To: References: <4B3726C0-20FE-4598-B4DA-44FA74FDFC71@sendmail.com> <59f980d60905111440i5b4894b6hfdfe8c3a6a5777d9@mail.gmail.com> Message-ID: <59f980d60905111704x8b5610u35d790668cf68022@mail.gmail.com> On Mon, May 11, 2009 at 6:01 PM, Patrick W. Gilmore wrote: > You are assuming facts not in evidence. I *have* actually done this before, so I'd like to think, for my own purposes at least, my experiences are factual. :) > It doesn't matter which physical interface transmits the packet. Well, in the general sense, I suppose not. The computer can put whatever it wants in an Ethernet frame, and as long as it's valid for the receiving system, it will work. But in the Linux IP stack, at least, and by default, the physical interface used to send a datagram is determined by the route selected, and that also determines the source IP address put on the datagram. At the same time, the only thing which influences route selection is the destination IP address. In particular, there's no concept of "session" or "connection" in that. So client X attempts to open a TCP connection to IP address B on my example server. When the server sends its SYN-ACK response, it doesn't pay attention to the fact that the connection "came in on" B. It just looks at destination X. If it decides A is the best route, then the SYN-ACK datagram will have source IP address A. But X is looking for a datagram from A. The datagram from B will get to X, but X will promptly drop it, as it's not expecting anything from B. Again, this is all by default. If you configure policy routing properly, many things can be made to work. > Another example: Imagine a web server with two uplinks in _different_ > subnets running Quagga. That's a different scenario entirely. Diverse routes work fine because all the intermediate routers work the same way I describe above: They don't care where the packet came from, they don't know about "connections", they just forward packets to the destination. If the actual interface went down, you can bet that the HTTP request in progress will be killed, because the TCP session is dependent on an IP address that just evaporated. :) -- Ben From mysidia at gmail.com Mon May 11 20:13:46 2009 From: mysidia at gmail.com (James Hess) Date: Mon, 11 May 2009 20:13:46 -0500 Subject: two interfaces one subnet In-Reply-To: <59f980d60905111704x8b5610u35d790668cf68022@mail.gmail.com> References: <4B3726C0-20FE-4598-B4DA-44FA74FDFC71@sendmail.com> <59f980d60905111440i5b4894b6hfdfe8c3a6a5777d9@mail.gmail.com> <59f980d60905111704x8b5610u35d790668cf68022@mail.gmail.com> Message-ID: <6eb799ab0905111813h33b42620t9c6ce4b80ec38c1a@mail.gmail.com> On Mon, May 11, 2009 at 7:04 PM, Ben Scott wrote: > On Mon, May 11, 2009 at 6:01 PM, Patrick W. Gilmore wrote: >[snip] Many OSes should handle it correctly, in principle, there's nothing wrong with hosts homed twice to the same network and addressed inside the same subnet, but for Linux hosts, no.... Unless you have a _very_ special need: just use IP aliasing and bonding (with supported NICs); I say you'll probably be a lot happier. But go ahead... try testing multiple interfaces on the same subnet for a while on a Linux host, see how well that works out, that's how you can truly see..... Possible dangers to keep in mind (bad defaults of Linux), with multiple interfaces on same subnet (without bonding): * ARP Flux: Linux treats IP addresses as owned by the "host" not the "interface", the first interface to receive an ARP request replies. So if Linux receives an ARP request for interface B's IP address on interface A, it will reply on interface A, thus associating interface B's IP with interface A's hardware address. Oh, but next time an ARP request comes in, interface B might get it instead. (*even if the IP is outside interface A's subnet range, Linux just always responds to ARP for any IP it thinks it owns in global scope, no matter what interface received the ARP.... this can enable connectivity you never intended, i.e. If you have a Linux-based firewall, the inside interface's IP can be detected from outside by ARP requesting for random private IPs. ....) * Some popular distros set net.ipv4.rp_filter (Reverse Path Forwarding) on by default. This means Linux can reject the very traffic that said promiscuous ARP activity brought in, unless outgoing traffic for that destination would be routed using the interface it was received on. Get ready to tune arp_ignore, arp_filter, turn off rp_filter, and possibly have to apply some kernel patches (depending on OS version).. -- -J From david at davidcoulson.net Mon May 11 20:16:42 2009 From: david at davidcoulson.net (David Coulson) Date: Mon, 11 May 2009 21:16:42 -0400 Subject: two interfaces one subnet In-Reply-To: <6eb799ab0905111813h33b42620t9c6ce4b80ec38c1a@mail.gmail.com> References: <4B3726C0-20FE-4598-B4DA-44FA74FDFC71@sendmail.com> <59f980d60905111440i5b4894b6hfdfe8c3a6a5777d9@mail.gmail.com> <59f980d60905111704x8b5610u35d790668cf68022@mail.gmail.com> <6eb799ab0905111813h33b42620t9c6ce4b80ec38c1a@mail.gmail.com> Message-ID: <4A08CDFA.909@davidcoulson.net> Remember, Linux has no concept of downing an interface when the link goes away, so even if you have two interfaces with the same subnet config, the kernel will continue to send traffic to a disconnected interface. Utilizing the bonding kernel module is the only really effective way to handle layer-2 redundancy for a Linux system. I use it for a large number of production Linux systems and it works pretty much flawlessly. James Hess wrote: > On Mon, May 11, 2009 at 7:04 PM, Ben Scott wrote: > >> On Mon, May 11, 2009 at 6:01 PM, Patrick W. Gilmore wrote: >> [snip] >> > > Many OSes should handle it correctly, in principle, there's nothing wrong with > hosts homed twice to the same network and addressed inside the same > subnet, but for Linux hosts, no.... > > Unless you have a _very_ special need: > just use IP aliasing and bonding (with supported NICs); I say you'll > probably be a lot happier. > > But go ahead... try testing multiple interfaces on the same subnet > for a while on a Linux host, see how well that works out, that's > how you can truly see..... > > > Possible dangers to keep in mind (bad defaults of Linux), with > multiple interfaces on same subnet (without bonding): > > * ARP Flux: Linux treats IP addresses as owned by the "host" not the > "interface", the first interface to receive an ARP request replies. > So if Linux receives an ARP request for interface B's IP address on > interface A, > it will reply on interface A, thus associating interface B's IP > with interface A's hardware address. > > Oh, but next time an ARP request comes in, interface B might get it instead. > > (*even if the IP is outside interface A's subnet range, Linux just > always responds to ARP for any IP it thinks it owns in global scope, > no matter what interface received the ARP.... this can enable > connectivity you never intended, i.e. If you have a Linux-based > firewall, the inside interface's IP can be detected from outside by > ARP requesting for random private IPs. ....) > > * Some popular distros set net.ipv4.rp_filter (Reverse Path > Forwarding) on by default. > This means Linux can reject the very traffic that said promiscuous ARP > activity brought in, unless outgoing traffic for that destination > would be routed using the interface it was received on. Get ready to > tune arp_ignore, arp_filter, turn off rp_filter, and possibly have > to apply some kernel patches (depending on OS version).. > > > > -- > -J > > From cmadams at hiwaay.net Mon May 11 20:23:58 2009 From: cmadams at hiwaay.net (Chris Adams) Date: Mon, 11 May 2009 20:23:58 -0500 Subject: two interfaces one subnet In-Reply-To: <4A08CDFA.909@davidcoulson.net> References: <4B3726C0-20FE-4598-B4DA-44FA74FDFC71@sendmail.com> <59f980d60905111440i5b4894b6hfdfe8c3a6a5777d9@mail.gmail.com> <59f980d60905111704x8b5610u35d790668cf68022@mail.gmail.com> <6eb799ab0905111813h33b42620t9c6ce4b80ec38c1a@mail.gmail.com> <4A08CDFA.909@davidcoulson.net> Message-ID: <20090512012358.GE622256@hiwaay.net> Once upon a time, David Coulson said: > Remember, Linux has no concept of downing an interface when the link > goes away Not true in several different ways. You can run netplugd or Network Manager to control it. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From Skywing at valhallalegends.com Mon May 11 20:31:37 2009 From: Skywing at valhallalegends.com (Skywing) Date: Mon, 11 May 2009 20:31:37 -0500 Subject: two interfaces one subnet Message-ID: <982D8D05B6407A49AD506E6C3AC8E7D60108AEBF4EE3@caralain.haven.nynaeve.net> Yes, similar happens to me all the time with both Windows Server 2008 and Vista with respect to 802.11 putting two interfaces on the same subnet (and LAN segment). I typically am never the wiser until I notice that a SMB connection had gone over to 802.11 first, because that associated before the wire was plugged in, causing data transfers on that connection to be much slower than on a hardline. This is something that happens every day to a great many laptop users, I'd wager. Certainly not by any means up there in "does not work at all, period / incompatible with networking" land, as, at the very least, emperical evidence has a quite different story to say. - S -----Original Message----- From: Chris Adams Sent: Monday, May 11, 2009 16:29 To: nanog at nanog.org Subject: Re: two interfaces one subnet Once upon a time, Kevin Oberman said: > > From: Chris Meidinger > > For example, eth0 is 10.0.0.1/24 and eth1 is 10.0.0.2/24, nothing like > > bonding going on. The customers usually have the idea of running one > > interface for administration and another for production (which is a > > _good_ idea) but they want to do it in the same subnet (not such a > > good idea...) > > This will not work right. One interface can be 10.0.0.1/24, but any > added interfaces would need to be /32 (10.0.0.2/32). I don't know which OS(es) you are using, but that's not true in Linux. I see this all the time at home; if I plug my notebook into the wired LAN and still have the wireless enabled, both will get an IP (in the same subnet) from DHCP. The wired link is the preferred default route by default, but you can easily set up routes for some networks via the wireless link. You can also set up multipath routing to send packets out both links. I think you can also use IP policy routing to control the choice of outbound interface by rule (e.g. based on source address). -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From patrick at ianai.net Mon May 11 22:01:01 2009 From: patrick at ianai.net (Patrick W. Gilmore) Date: Mon, 11 May 2009 23:01:01 -0400 Subject: two interfaces one subnet In-Reply-To: <59f980d60905111704x8b5610u35d790668cf68022@mail.gmail.com> References: <4B3726C0-20FE-4598-B4DA-44FA74FDFC71@sendmail.com> <59f980d60905111440i5b4894b6hfdfe8c3a6a5777d9@mail.gmail.com> <59f980d60905111704x8b5610u35d790668cf68022@mail.gmail.com> Message-ID: <016C2E0F-7069-466D-B28F-7E48BFD6DDE4@ianai.net> On May 11, 2009, at 8:04 PM, Ben Scott wrote: > On Mon, May 11, 2009 at 6:01 PM, Patrick W. Gilmore > wrote: >> It doesn't matter which physical interface transmits the packet. > > Well, in the general sense, I suppose not. The computer can put > whatever it wants in an Ethernet frame, and as long as it's valid for > the receiving system, it will work. The OP asked for an RFC showing why this is forbidden. It is not. It works fine. I stated many times that several implementations deny your ability to do this, but the "rules" permit it just fine. >> Another example: Imagine a web server with two uplinks in _different_ >> subnets running Quagga. > > That's a different scenario entirely. Diverse routes work fine > because all the intermediate routers work the same way I describe > above: They don't care where the packet came from, they don't know > about "connections", they just forward packets to the destination. Do you even read your own posts? Specifically: On May 11, 2009, at 5:40 PM, Ben Scott wrote: > Either way, if > the packet *from* X was addressed *to* B but the response comes back > from *A*, then host X is going to drop the packet as > invalid/irrelevant/etc. The receiving host X does not care (or even know) if A and B are in the same prefix. Intermediate systems have nothing to do with it as they do not touch the source IP address in the packet. (We are obviously ignoring NAT/PAT, etc.) So if it works with "diverse routes", it works without diverse routes. In other words, you contradicted yourself. Don't worry, you are in good company in this thread. The OP alone did that 4 times by my count, and I stopped reading his posts because he did it so often. To summarize: Two physical interfaces on one machine in the same prefix is allowed. There is no RFC against it - just the opposite. So quit arguing over "but my $THING doesn't support it properly" or "but it will break $SOMETHING" or whatever your favorite hang-up is. -- TTFN, patrick From rodunn at cisco.com Mon May 11 22:07:48 2009 From: rodunn at cisco.com (Rodney Dunn) Date: Mon, 11 May 2009 23:07:48 -0400 Subject: PPP multilink help In-Reply-To: <90ccfc90905111001rf941083tf69ba525f7ff805d@mail.gmail.com> References: <90ccfc90905110737h7b0c432nfa44ac0c2f113e63@mail.gmail.com> <20090511160602.GI127@rtp-cse-489.cisco.com> <483E6B0272B0284BA86D7596C40D29F9C3811FCE19@PUR-EXCH07.ox.com> <90ccfc90905111001rf941083tf69ba525f7ff805d@mail.gmail.com> Message-ID: <20090512030748.GA5578@rtp-cse-489.cisco.com> It could very well be microburst in the flow creating congestion as seen in the default class: > Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 252140 > 30 second output rate 1795000 bits/sec, 243 packets/sec > > Class-map: class-default (match-any) > 275000011 packets, 120951145536 bytes > 30 second offered rate 1494000 bps, drop rate 0 bps > Match: any > Queueing > queue limit 64 packets > (queue depth/total drops/no-buffer drops/flowdrops) 0/251092/0/251092 > (pkts output/bytes output) 276085337/122442704318 > Fair-queue: per-flow queue limit 16 Which matches mostly to the default class. I don't recall if the per flow queue limit kicks in without congestion or not. You could try a few things: a) remove WFQ in the default class b) add a BW statement to it to allocate a dedicated amount c) implement WRED in the class d) remove WFQ in the default class to see if one of those improves it. btw, the overhead I was referring to was the additional MLPPP overhead to each packet which reduces effective throughput. Rodney From akmal_shahbaz at yahoo.com Mon May 11 22:40:18 2009 From: akmal_shahbaz at yahoo.com (Akmal Shahbaz) Date: Mon, 11 May 2009 20:40:18 -0700 (PDT) Subject: Can Interdomain routing[BGP] self recover from prefix hijack? Message-ID: <446003.67836.qm@web56003.mail.re3.yahoo.com> HiSolutions like BGPmon.net,Cyclops,etc are doing a very good job of alerting ?about the prefix hijack/configuration erros/experiments gonig on/etc.But i would like to ask "Alerting the victim is the best we can do after detecting such incidents" or what else we can do?What do you think about "BGP ability to Self recover form prefix hijacks or anomalies?" Is it possible?How?What do you think about "Self healing as the property of Internet?"Thank you.Akmal KhanMS-PhD StudentMMLab at SNU.Kr --- On Tue, 5/12/09, nanog-request at nanog.org wrote: From: nanog-request at nanog.org Subject: NANOG Digest, Vol 16, Issue 43 To: nanog at nanog.org Date: Tuesday, May 12, 2009, 1:04 AM Send NANOG mailing list submissions to ??? nanog at nanog.org To subscribe or unsubscribe via the World Wide Web, visit ??? http://mailman.nanog.org/mailman/listinfo/nanog or, via email, send a message with subject or body 'help' to ??? nanog-request at nanog.org You can reach the person managing the list at ??? nanog-owner at nanog.org When replying, please edit your Subject line so it is more specific than "Re: Contents of NANOG digest..." Today's Topics: ???1. Re: two interfaces one subnet (David Devereaux-Weber) ???2. Re: two interfaces one subnet (Nathan Ward) ???3. Re: two interfaces one subnet (Arnold Nipper) ???4. Re: two interfaces one subnet (Patrick W. Gilmore) ???5. Re: two interfaces one subnet (Patrick W. Gilmore) ???6. RE: two interfaces one subnet (Holmes,David A) ???7. Re: two interfaces one subnet (Arnold Nipper) ???8. Re: two interfaces one subnet (Patrick W. Gilmore) ???9. Re: two interfaces one subnet (Chris Adams) ? 10. Re: two interfaces one subnet? (Kevin Oberman) ? 11. Re: two interfaces one subnet (Ben Scott) ---------------------------------------------------------------------- Message: 1 Date: Mon, 11 May 2009 17:08:45 -0500 From: David Devereaux-Weber Subject: Re: two interfaces one subnet To: Hector Herrera Cc: nanog at nanog.org Message-ID: ??? Content-Type: text/plain; charset=ISO-8859-1 In my case, each Ethernet interface has its own unique MAC address. Dave On Mon, May 11, 2009 at 4:28 PM, Hector Herrera wrote: > On Mon, May 11, 2009 at 2:22 PM, David Devereaux-Weber > wrote: > > Chris, > > > > I work with iHDTV , a project that sends uncompressed > high > > definition television (1.5 Gbps) as UDP over two 1 Gbps interfaces.? If > both > > interfaces are on the same subnet, the OS sees the same router (gateway) > > address on both interfaces, and the results are sub-optimal ... around > 50% > > packet loss. > > packet loss is probably due to the network switch having to re-learn > the location of the MAC address constantly as it sees packets on two > or more ports with the same MAC address (think STP loops). > > If your network stack and network device (switch) supports LACP, then > you can have multiple connections between a host and a network device. >? That is a very easy way to increase capacity and add redundancy. > > That is how all of our VMWare ESX 3.5i servers are connected. > > Hector > ------------------------------ Message: 2 Date: Tue, 12 May 2009 10:08:49 +1200 From: Nathan Ward Subject: Re: two interfaces one subnet To: nanog list Message-ID: <24F5463D-C5B0-46BD-AB6A-1C376BE742EF at daork.net> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes On 12/05/2009, at 9:00 AM, Charles Wyble wrote: > What does two interfaces in one subnet mean? > > Two NICs? Or virtual interfaces? Also, what does one subnet mean? A. Using the same IP prefix on two different networks (ie. ethernet? broadcast domains) with an interface in to each, or B. running two? interfaces in to the same network (ie. ethernet broadcast domain). In the case of A, are you re-using numbers on each side? In the case of B, are you wanting both interfaces to have the same? number(s)? -- Nathan Ward ------------------------------ Message: 3 Date: Tue, 12 May 2009 00:13:19 +0200 From: Arnold Nipper Subject: Re: two interfaces one subnet To: "Patrick W. Gilmore" Cc: NANOG list Message-ID: <4A08A2FF.4040306 at nipper.de> Content-Type: text/plain; charset="iso-8859-1" On 11.05.2009 23:47 Patrick W. Gilmore wrote > On May 11, 2009, at 5:19 PM, Alex H. Ryu wrote: > >> It may be allowed from host-level, but from router equipment, I don't >> think it was allowed at all. > > Ever used HSRP / VRRP?? Two interfaces in the same subnet.? Works? > fine.? In fact, most people think it works _better_ than one interface? > in the same subnet. > I guess you are mixing interfaces with IPs now. Don't you? Arnold -- Arnold Nipper / nIPper consulting, Sandhausen, Germany email: arnold at nipper.de? ? ???phone: +49 6224 9259 299 mobile: +49 172 2650958? ? ? ???fax: +49 6224 9259 333 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 250 bytes Desc: OpenPGP digital signature Url : http://mailman.nanog.org/mailman/nanog/attachments/20090512/572650ee/attachment-0001.pgp ------------------------------ Message: 4 Date: Mon, 11 May 2009 18:16:22 -0400 From: "Patrick W. Gilmore" Subject: Re: two interfaces one subnet To: North American Network Operators Group Message-ID: <1AE0407D-4A99-41B9-820D-11EF2A27A739 at ianai.net> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes On May 11, 2009, at 5:59 PM, Chris Meidinger wrote: > Just to restate here, for people who have been responding both? > publicly and privately: > > I know that *I* can make it work, and I know that *you* can make it? > work. But I also know that it's not likely to stay working. > > One day, down the road, something will break. Then, my poor support? > team will spend days trying to diagnose the problem. Could you show me a network configuration that does not qualify for? that last sentence? Or for that matter, _anything_ related to ... well, anything? -- TTFN, patrick ------------------------------ Message: 5 Date: Mon, 11 May 2009 18:25:02 -0400 From: "Patrick W. Gilmore" Subject: Re: two interfaces one subnet To: NANOG list Message-ID: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes On May 11, 2009, at 6:13 PM, Arnold Nipper wrote: > On 11.05.2009 23:47 Patrick W. Gilmore wrote >> On May 11, 2009, at 5:19 PM, Alex H. Ryu wrote: >> >>> It may be allowed from host-level, but from router equipment, I? >>> don't >>> think it was allowed at all. >> >> Ever used HSRP / VRRP?? Two interfaces in the same subnet.? Works >> fine.? In fact, most people think it works _better_ than one? >> interface >> in the same subnet. > > I guess you are mixing interfaces with IPs now. Don't you? Each interface has its own IP address.? The two Interfaces _also_? share a virtual IP address. IOW: No.? Are you? -- TTFN, patrick ------------------------------ Message: 6 Date: Mon, 11 May 2009 15:27:13 -0700 From: "Holmes,David A" Subject: RE: two interfaces one subnet To: "Chris Meidinger" Cc: nanog at nanog.org Message-ID: ??? <485ED9BA02629E4BBBA53AC892EDA50E08E2D64D at usmsxt104.mwd.h2o> Content-Type: text/plain;??? charset="us-ascii" I think the idea of one interface per subnet originates in the early RFCs, such as RFC 1009 "Requirements for Internet Gateways": "Section 1.1.2 Networks and Gateways ... A gateway is connected to two or more networks, appearing to ? ? ? ???each of these networks as a connected host.? Thus, it has a ? ? ? ???physical interface and an IP address on each of the connected ? ? ? ???networks ... " So by using singular terminology ( "a connected host", "a physical interface", "an IP address") instead of plural, a single interface per subnet for gateways (read routers) is implied. This is not to say that it will not work, at least on servers. Standards aside, a good reason why this is not a best practice is the concept of asynchronous routing where a packet arrives on one interface, and the reply leaves on the other interface with a different source IP on the reply. Most firewalls will reject packets such as this.? -----Original Message----- From: Chris Meidinger [mailto:cmeidinger at sendmail.com] Sent: Monday, May 11, 2009 1:29 PM To: nanog at nanog.org Subject: two interfaces one subnet Hi, This is a pretty moronic question, but I've been searching RFC's on- and-off for a couple of weeks and can't find an answer. So I'm hoping? someone here will know it offhand. I've been looking through RFC's trying to find a clear statement that? having two interfaces in the same subnet does not work, but can't find? it that statement anywhere. The OS in this case is Linux. I know it can be done with clever? routing and prioritization and such, but this has to do with vanilla? config, just setting up two interfaces in one network. I would be grateful for a pointer to such an RFC statement, assuming? it exists. Thanks! Chris ------------------------------ Message: 7 Date: Tue, 12 May 2009 00:35:20 +0200 From: Arnold Nipper Subject: Re: two interfaces one subnet To: NANOG list Message-ID: <4A08A828.4040104 at nipper.de> Content-Type: text/plain; charset="iso-8859-1" On 12.05.2009 00:25 Patrick W. Gilmore wrote > On May 11, 2009, at 6:13 PM, Arnold Nipper wrote: >> On 11.05.2009 23:47 Patrick W. Gilmore wrote >>> On May 11, 2009, at 5:19 PM, Alex H. Ryu wrote: >>> >>>> It may be allowed from host-level, but from router equipment, I? >>>> don't >>>> think it was allowed at all. >>> >>> Ever used HSRP / VRRP?? Two interfaces in the same subnet.? Works >>> fine.? In fact, most people think it works _better_ than one? >>> interface >>> in the same subnet. >> >> I guess you are mixing interfaces with IPs now. Don't you? > > Each interface has its own IP address.? The two Interfaces _also_? > share a virtual IP address. > > IOW: No.? Are you? > But still each device only has _one_ interface in the same subnet. Though with two IP addresses sometimes. Arnold -- Arnold Nipper / nIPper consulting, Sandhausen, Germany email: arnold at nipper.de? ? ???phone: +49 6224 9259 299 mobile: +49 172 2650958? ? ? ???fax: +49 6224 9259 333 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 250 bytes Desc: OpenPGP digital signature Url : http://mailman.nanog.org/mailman/nanog/attachments/20090512/676b9522/attachment-0001.pgp ------------------------------ Message: 8 Date: Mon, 11 May 2009 18:37:42 -0400 From: "Patrick W. Gilmore" Subject: Re: two interfaces one subnet To: Arnold Nipper Cc: NANOG list Message-ID: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes On May 11, 2009, at 6:35 PM, Arnold Nipper wrote: > On 12.05.2009 00:25 Patrick W. Gilmore wrote >> On May 11, 2009, at 6:13 PM, Arnold Nipper wrote: >>> On 11.05.2009 23:47 Patrick W. Gilmore wrote >>>> On May 11, 2009, at 5:19 PM, Alex H. Ryu wrote: >>>> >>>>> It may be allowed from host-level, but from router equipment, I >>>>> don't >>>>> think it was allowed at all. >>>> >>>> Ever used HSRP / VRRP?? Two interfaces in the same subnet.? Works >>>> fine.? In fact, most people think it works _better_ than one >>>> interface >>>> in the same subnet. >>> >>> I guess you are mixing interfaces with IPs now. Don't you? >> >> Each interface has its own IP address.? The two Interfaces _also_ >> share a virtual IP address. >> >> IOW: No.? Are you? >> > > But still each device only has _one_ interface in the same subnet. > Though with two IP addresses sometimes. Of course, was thinking about using it on the same router.? But I? guess that doesn't work so well, does it? :) -- TTFN, patrick ------------------------------ Message: 9 Date: Mon, 11 May 2009 18:29:08 -0500 From: Chris Adams Subject: Re: two interfaces one subnet To: nanog at nanog.org Message-ID: <20090511232908.GB622256 at hiwaay.net> Content-Type: text/plain; charset=us-ascii Once upon a time, Kevin Oberman said: > > From: Chris Meidinger > > For example, eth0 is 10.0.0.1/24 and eth1 is 10.0.0.2/24, nothing like? > > bonding going on. The customers usually have the idea of running one? > > interface for administration and another for production (which is a? > > _good_ idea) but they want to do it in the same subnet (not such a? > > good idea...) > > This will not work right. One interface can be 10.0.0.1/24, but any > added interfaces would need to be /32 (10.0.0.2/32). I don't know which OS(es) you are using, but that's not true in Linux. I see this all the time at home; if I plug my notebook into the wired LAN and still have the wireless enabled, both will get an IP (in the same subnet) from DHCP.? The wired link is the preferred default route by default, but you can easily set up routes for some networks via the wireless link. You can also set up multipath routing to send packets out both links.? I think you can also use IP policy routing to control the choice of outbound interface by rule (e.g. based on source address). -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. ------------------------------ Message: 10 Date: Mon, 11 May 2009 16:47:50 -0700 From: "Kevin Oberman" Subject: Re: two interfaces one subnet To: Chris Adams Cc: nanog at nanog.org Message-ID: <20090511234750.2804A1CC0B at ptavv.es.net> > Date: Mon, 11 May 2009 18:29:08 -0500 > From: Chris Adams > > Once upon a time, Kevin Oberman said: > > > From: Chris Meidinger > > > For example, eth0 is 10.0.0.1/24 and eth1 is 10.0.0.2/24, nothing like? > > > bonding going on. The customers usually have the idea of running one? > > > interface for administration and another for production (which is a? > > > _good_ idea) but they want to do it in the same subnet (not such a? > > > good idea...) > > > > This will not work right. One interface can be 10.0.0.1/24, but any > > added interfaces would need to be /32 (10.0.0.2/32). > > I don't know which OS(es) you are using, but that's not true in Linux. > I see this all the time at home; if I plug my notebook into the wired > LAN and still have the wireless enabled, both will get an IP (in the > same subnet) from DHCP.? The wired link is the preferred default route > by default, but you can easily set up routes for some networks via the > wireless link. > > You can also set up multipath routing to send packets out both links.? I > think you can also use IP policy routing to control the choice of > outbound interface by rule (e.g. based on source address). This is true if you are using the WPA supplicant. It does a bit of magic. (You can do the magic by hand without the supplicant, but it is a pain or was the last time I tried.) -- 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 ------------------------------ Message: 11 Date: Mon, 11 May 2009 20:04:27 -0400 From: Ben Scott Subject: Re: two interfaces one subnet To: NANOG list Message-ID: ??? <59f980d60905111704x8b5610u35d790668cf68022 at mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 On Mon, May 11, 2009 at 6:01 PM, Patrick W. Gilmore wrote: > You are assuming facts not in evidence. ? I *have* actually done this before, so I'd like to think, for my own purposes at least, my experiences are factual.? :) > It doesn't matter which physical interface transmits the packet. ? Well, in the general sense, I suppose not.? The computer can put whatever it wants in an Ethernet frame, and as long as it's valid for the receiving system, it will work. ? But in the Linux IP stack, at least, and by default, the physical interface used to send a datagram is determined by the route selected, and that also determines the source IP address put on the datagram. At the same time, the only thing which influences route selection is the destination IP address. ? In particular, there's no concept of "session" or "connection" in that.? So client X attempts to open a TCP connection to IP address B on my example server.? When the server sends its SYN-ACK response, it doesn't pay attention to the fact that the connection "came in on" B. It just looks at destination X.? If it decides A is the best route, then the SYN-ACK datagram will have source IP address A.? But X is looking for a datagram from A.? The datagram from B will get to X, but X will promptly drop it, as it's not expecting anything from B. ? Again, this is all by default.? If you configure policy routing properly, many things can be made to work. > Another example: Imagine a web server with two uplinks in _different_ > subnets running Quagga. ? That's a different scenario entirely.? Diverse routes work fine because all the intermediate routers work the same way I describe above: They don't care where the packet came from, they don't know about "connections", they just forward packets to the destination. ? If the actual interface went down, you can bet that the HTTP request in progress will be killed, because the TCP session is dependent on an IP address that just evaporated.? :) -- Ben ------------------------------ _______________________________________________ NANOG mailing list NANOG at nanog.org http://mailman.nanog.org/mailman/listinfo/nanog End of NANOG Digest, Vol 16, Issue 43 ************************************* From mailvortex at gmail.com Mon May 11 22:43:26 2009 From: mailvortex at gmail.com (Ben Scott) Date: Mon, 11 May 2009 23:43:26 -0400 Subject: two interfaces one subnet In-Reply-To: <016C2E0F-7069-466D-B28F-7E48BFD6DDE4@ianai.net> References: <4B3726C0-20FE-4598-B4DA-44FA74FDFC71@sendmail.com> <59f980d60905111440i5b4894b6hfdfe8c3a6a5777d9@mail.gmail.com> <59f980d60905111704x8b5610u35d790668cf68022@mail.gmail.com> <016C2E0F-7069-466D-B28F-7E48BFD6DDE4@ianai.net> Message-ID: <59f980d60905112043v6775a81n8498f3608666c0b2@mail.gmail.com> On Mon, May 11, 2009 at 11:01 PM, Patrick W. Gilmore wrote: >>> It doesn't matter which physical interface transmits the packet. >> >> ?Well, in the general sense, I suppose not. ?The computer can put >> whatever it wants in an Ethernet frame, and as long as it's valid for >> the receiving system, it will work. > > The OP asked for an RFC showing why this is forbidden. Um, yah, I know. You replied to me telling me I was "assuming facts not in evidence". So I was responding to that. Neither my message which you replied to, nor your reply, nor my reply to *your reply*, had anything to do with the OP's request for an RFC citation. Notice the distinct lack of the string "RFC" in my post, your reply, or my reply to your reply. To borrow your phrase, "Do you read your own posts?" > Do you even read your own posts? ?Specifically: > > On May 11, 2009, at 5:40 PM, Ben Scott wrote: > >> Either way, if >> the packet *from* X was addressed *to* B but the response comes back >> from *A*, then host X is going to drop the packet as >> invalid/irrelevant/etc. > > The receiving host X does not care (or even know) if A and B are in the same > prefix. Look again. A and B are *IP addresses*, not hosts. If I'm standing on my home PC and try to connect to Google at 64.233.161.104, my home PC is going to open a TCP connection to that IP address. If Google then tries to send me a response back from 64.233.161.105, then my PC is going to ignore that packet, because it's expecting a response from 64.233.161.104. They're both coming from Google, and maybe they're evening coming from the same node at Google, but since *my* computer doesn't get the response it expects, it doesn't work. Get it? Just to be clear, I'm not talking about what the RFC's say in the above three paragraphs. I'm talking about the specifics of a failure mode which occur under certain conditions in the implementation the OP is using. > So if it works with "diverse routes", it works without > diverse routes. Not when the problem is malfunction at one of the end points! > Two physical interfaces on one machine in the same prefix is > allowed. Indeed, and unlike yourself, I was offering practical, operational advice on how one might configure the given implementation to support just that. -- Ben From steve at ibctech.ca Fri May 8 01:35:51 2009 From: steve at ibctech.ca (Steve Bertrand) Date: Fri, 08 May 2009 02:35:51 -0400 Subject: Checking bogon status of new address space In-Reply-To: <20090508053336.GC7171@captain.bridge.anchor.net.au> References: <20090508053336.GC7171@captain.bridge.anchor.net.au> Message-ID: <4A03D2C7.8060003@ibctech.ca> Oliver Hookins wrote: > Hi, > > my company has just been allocated some new IPv4 address space, and I want > to do some sort of automated testing to find out any ASs out there that > haven't removed the /8 it's on from their bogon list (the allocation to our > local registry only occurred in November last year). IMHO, if a network doesn't either update filters based on IANA notifications or follow Cymru BOGON, then they don't deserve to receive traffic from your network ;) > Has anybody attempted to do this? It is worth bothering? Currently I'm > considering pulling out all the endpoint ASs out of the BGP table, finding > at least one subnet for each of them and attempting to ping or reach other > common ports on a single IP for each AS from our currently working > address space, and then the new address space and comparing results. Sounds like a major PITA. Why not tell us what the prefix is that you have, and we can ensure that our filters our clean? Probably easier asking a few 'NOGs than it is sweeping a few thousand prefixes. Steve From patrick at ianai.net Mon May 11 23:12:43 2009 From: patrick at ianai.net (Patrick W. Gilmore) Date: Tue, 12 May 2009 00:12:43 -0400 Subject: two interfaces one subnet In-Reply-To: <59f980d60905112043v6775a81n8498f3608666c0b2@mail.gmail.com> References: <4B3726C0-20FE-4598-B4DA-44FA74FDFC71@sendmail.com> <59f980d60905111440i5b4894b6hfdfe8c3a6a5777d9@mail.gmail.com> <59f980d60905111704x8b5610u35d790668cf68022@mail.gmail.com> <016C2E0F-7069-466D-B28F-7E48BFD6DDE4@ianai.net> <59f980d60905112043v6775a81n8498f3608666c0b2@mail.gmail.com> Message-ID: <3882E7EC-6E65-4753-8DD3-53C4A11EA54B@ianai.net> On May 11, 2009, at 11:43 PM, Ben Scott wrote: > On Mon, May 11, 2009 at 11:01 PM, Patrick W. Gilmore > wrote: >> Do you even read your own posts? Specifically: >> >> On May 11, 2009, at 5:40 PM, Ben Scott wrote: >> >>> Either way, if >>> the packet *from* X was addressed *to* B but the response comes back >>> from *A*, then host X is going to drop the packet as >>> invalid/irrelevant/etc. >> >> The receiving host X does not care (or even know) if A and B are in >> the same >> prefix. > > Look again. A and B are *IP addresses*, not hosts. Sometimes people agree with me, sometimes they don't, and sometimes I agree with them. But I've yet to have someone claim to be arguing against me while proving my point. Anyone else want to unconfused Ben? I obviously cannot. -- TTFN, patrick From jlewis at lewis.org Mon May 11 23:20:00 2009 From: jlewis at lewis.org (Jon Lewis) Date: Tue, 12 May 2009 00:20:00 -0400 (EDT) Subject: Checking bogon status of new address space In-Reply-To: <4A03D2C7.8060003@ibctech.ca> References: <20090508053336.GC7171@captain.bridge.anchor.net.au> <4A03D2C7.8060003@ibctech.ca> Message-ID: On Fri, 8 May 2009, Steve Bertrand wrote: > IMHO, if a network doesn't either update filters based on IANA > notifications or follow Cymru BOGON, then they don't deserve to receive > traffic from your network ;) See how far you get telling customers that after you've given them recently debogonized space. ---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From heldal at eml.cc Tue May 12 03:30:18 2009 From: heldal at eml.cc (Per Heldal) Date: Tue, 12 May 2009 10:30:18 +0200 Subject: two interfaces one subnet In-Reply-To: References: <4B3726C0-20FE-4598-B4DA-44FA74FDFC71@sendmail.com> Message-ID: <4A09339A.1070409@eml.cc> David Devereaux-Weber wrote: > > I work with iHDTV , a project that sends uncompressed high > definition television (1.5 Gbps) as UDP over two 1 Gbps interfaces. If both > interfaces are on the same subnet, the OS sees the same router (gateway) > address on both interfaces, and the results are sub-optimal ... around 50% > packet loss. > Check closes and you may discover that the loss isn't on the path host->router, but on the reverse. Some hosts/interfaces are optimised for L2 link-aggregation, in which case they by default present the same MAC (host MAC-address) on multiple interfaces. Those will fail when configured with separate IP-addresses on the same VLAN/subnet. L2 switches that support link-aggregation will try to spread the traffic across the available ports on one VLAN on which it sees the same MAC. 2 ports gives 50% loss, 3 ports 67% and so on. Most host interfaces will not pick up IP-packets which destination doesn't match it's assigned address. //per From livio.zanol.puppim at gmail.com Tue May 12 06:13:29 2009 From: livio.zanol.puppim at gmail.com (Livio Zanol Puppim) Date: Tue, 12 May 2009 08:13:29 -0300 Subject: 10-GigE for servers In-Reply-To: References: <81ecd7700905011055y3fd14276pbb78c2b80882da63@mail.gmail.com> Message-ID: Cisco is trying to push another kind of adapter called CNA, integrating Ethernet and FCoE for use in a "loss less" network. It uses several proprietary specifications. More information can be obtained here: http://www.qlogic.com/Products/Datanetworking_products_CNA_QLE8042.aspx http://www.qlogic.com/SiteCollectionDocuments/Products/Products_RightNAV_pdf%27s/Fibre%20Channel%20HBAs/SN0230938-00.pdf http://www.cisco.com/en/US/prod/collateral/ps10265/ps10280/data_sheet_c78-524774.html http://www.emulex.com/products/strategic-direction/oneconnect-universal-cna.html gg 2009/5/3 Rodrick Brown > 2009/5/1 Nathan Stratton : > > On Fri, 1 May 2009, Jason Shoemaker wrote: > > > >> My company is looking for ways to improve throughput for data transfers > >> between individual servers. We?re exploring the creation of > Etherchannels > >> using multiple server NICs, but Etherchannel seems to have the > limitation > >> of > >> not supporting per-packet load-balancing, therefore limiting traffic > >> between > >> two individual hosts to 1 Gig. > > > > Have you thought about Infiniband? Dual 10 gig cards cost about $50 and > 24 > > port switches about $1200 on ebay. Infiniband has just a fraction of the > > latency of ethernet (even 10 get eth). You get the lowest latency if your > > application supports Infiniband, but if not you can run IP over IB. > > > Infiniband is dying technology.. > > > >> <> > > > > Nathan Stratton CTO, BlinkMind, Inc. > > nathan at robotics.net nathan at blinkmind.com > > http://www.robotics.net http://www.blinkmind.com > > > > -- > [ Rodrick R. Brown ] > http://www.rodrickbrown.com http://www.linkedin.com/in/rodrickbrown > > -- []'s L?vio Zanol Puppim From rs at seastrom.com Tue May 12 06:54:49 2009 From: rs at seastrom.com (Robert E. Seastrom) Date: Tue, 12 May 2009 07:54:49 -0400 Subject: Checking bogon status of new address space In-Reply-To: <6eb799ab0905090710r1afc3ca5md61b76e884a4076d@mail.gmail.com> (James Hess's message of "Sat, 9 May 2009 09:10:49 -0500") References: <20090508053336.GC7171@captain.bridge.anchor.net.au> <4A046B81.9010500@cymru.com> <20090508173955.GA49860@ussenterprise.ufp.org> <6eb799ab0905090710r1afc3ca5md61b76e884a4076d@mail.gmail.com> Message-ID: James Hess writes: >> 29/256 = 11% of the available address space. ?My argument is, if >> someone is scanning you from random source addresses blocking 10% >> of the scan traffic is reaching a point of very little return for >> the effort of updating the address lists, and as we all know it is >> getting smaller and smaller. > > Granted, if the filters aren't updated very frequently, they're pretty bad. That's the usual state of affairs, unfortunately. > But.. I would suggest, basically, filtering bogons is still great and > pretty important, it serves as an ongoing deterrant against random > unruly networks trying to pick up the unassigned addresses, or > treating the space as "Up for grabs" just because some space happens > to be unannounced (and unassigned). Gotta agree with Leo here. We can't even get people to implement BCP-38, which is nine years old for crying out loud. The deployment level at which bogon filtering is a deterrent to squatting is quite a bit higher from the point at which it becomes an issue to legitimate users. I've considered static bogon filters to be a Worst Current Practice for years. If you feel you absolutely must engage in the practice use a dynamic feed like Cymru's, but honestly, just let it go. -r From daryl at introspect.net Tue May 12 09:51:56 2009 From: daryl at introspect.net (Daryl G. Jurbala) Date: Tue, 12 May 2009 10:51:56 -0400 Subject: two interfaces one subnet In-Reply-To: <80e7195b0905111348m6da9d190g1e81049960bc5d06@mail.gmail.com> References: <4B3726C0-20FE-4598-B4DA-44FA74FDFC71@sendmail.com> <80e7195b0905111348m6da9d190g1e81049960bc5d06@mail.gmail.com> Message-ID: On May 11, 2009, at 4:48 PM, Duane Waddle wrote: > On Mon, May 11, 2009 at 3:39 PM, Mikael Abrahamsson > wrote: >> > IIRC, you can turn the feature off WHEN it makes an issue. > Fixed that for you. S550 attached to a 6509, Dell blade in a blade chassis with Power connect switches cross-connected to the 6509 in trunking mode. Got nothing but errors, discards, and slow performance across the link (only to the NAS....everything else was fine). Changed the S550 into redundancy mode (one NIC in standby rather than active/active) and everything is just peachy. I don't have the time or inclination to figure out why.....I just expect these things to work when the manufacturer says they will. Of course, I already have a huge issue with NetApp considering the EOLed a 3 month old piece of gear two months after I bought it. From martin at theicelandguy.com Tue May 12 11:06:06 2009 From: martin at theicelandguy.com (Martin Hannigan) Date: Tue, 12 May 2009 12:06:06 -0400 Subject: two interfaces one subnet In-Reply-To: <3882E7EC-6E65-4753-8DD3-53C4A11EA54B@ianai.net> References: <4B3726C0-20FE-4598-B4DA-44FA74FDFC71@sendmail.com> <59f980d60905111440i5b4894b6hfdfe8c3a6a5777d9@mail.gmail.com> <59f980d60905111704x8b5610u35d790668cf68022@mail.gmail.com> <016C2E0F-7069-466D-B28F-7E48BFD6DDE4@ianai.net> <59f980d60905112043v6775a81n8498f3608666c0b2@mail.gmail.com> <3882E7EC-6E65-4753-8DD3-53C4A11EA54B@ianai.net> Message-ID: On Tue, May 12, 2009 at 12:12 AM, Patrick W. Gilmore wrote: > On May 11, 2009, at 11:43 PM, Ben Scott wrote: > >> On Mon, May 11, 2009 at 11:01 PM, Patrick W. Gilmore >> wrote: >> > > Do you even read your own posts? Specifically: >>> >>> On May 11, 2009, at 5:40 PM, Ben Scott wrote: >>> >>> Either way, if >>>> the packet *from* X was addressed *to* B but the response comes back >>>> from *A*, then host X is going to drop the packet as >>>> invalid/irrelevant/etc. >>>> >>> >>> The receiving host X does not care (or even know) if A and B are in the >>> same >>> prefix. >>> >> >> Look again. A and B are *IP addresses*, not hosts. >> > > Sometimes people agree with me, sometimes they don't, and sometimes I agree > with them. But I've yet to have someone claim to be arguing against me > while proving my point. > > Anyone else want to unconfused Ben? I obviously cannot. Really nothing clever about this at all in application or practicality. host> cat /etc/services | grep nntp nntp 119/tcp readnews untp # USENET News Transfer Protocol host1> cat /etc/hosts | grep news 127.0.0.1 localhost 192.168.0.100 clue-store 192.168.0.100 news-out 192.168.0.101 news-in If this didn't work, you'd suppose that virtual machines and IP aliasing wouldn't work either. Unless routes facing the world on the device are "tweaked", this should work fine and be reliable (if implemented cluefully). Am I not getting it? Best, -M< -- Martin Hannigan martin at theicelandguy.com p: +16178216079 Power, Network, and Costs Consulting for Iceland Datacenters and Occupants From cmaurand at xyonet.com Tue May 12 12:37:03 2009 From: cmaurand at xyonet.com (Curtis Maurand) Date: Tue, 12 May 2009 13:37:03 -0400 Subject: two interfaces one subnet In-Reply-To: References: <4B3726C0-20FE-4598-B4DA-44FA74FDFC71@sendmail.com> <59f980d60905111440i5b4894b6hfdfe8c3a6a5777d9@mail.gmail.com> Message-ID: <4A09B3BF.6050309@xyonet.com> Try this: http://www.linuxfoundation.org/en/Net:Bridge --Curtis Patrick W. Gilmore wrote: > On May 11, 2009, at 5:40 PM, Ben Scott wrote: >> On Mon, May 11, 2009 at 5:28 PM, Hector Herrera >> wrote: >>> On Mon, May 11, 2009 at 2:22 PM, David Devereaux-Weber >>> wrote: >>>> ... both> interfaces are on the same subnet, the OS sees the same >>>> router (gateway) >>>> address on both interfaces, and the results are sub-optimal ... >>>> around 50% >>>> packet loss. >>> >>> packet loss is probably due to the network switch having to re-learn >>> the location of the MAC address constantly as it sees packets on two >>> or more ports with the same MAC address (think STP loops). >> >> My understand of the scenario is: Two physical interfaces, each with >> a unique IP address, in the same Ethernet broadcast domain, on the >> same IP (sub)network. >> >> If that's the case, the MAC address won't change. The cards stay >> put. So a layer two switch will be none the wiser. >> >> The reason this doesn't work (for most implementations) is that most >> IP routers look only at the destination IP address, and keep no state. >> (Here, I'm using "router" to include the routing engine built-in to >> any full IP implementation, not just dedicated equipment from Cisco, >> et. al.) >> >> So we have a host with IP addresses A and B on the same subnet. A >> packet comes in from some other host X. The application software does >> whatever it does, and sends a response. The router looks at the >> destination IP address X, and sees that it has two routes, A and B. >> >> Depending on implementation, the router may send everything out the >> first interface it finds in the routing table (e.g., use A and ignore >> B), or round-robin between the two, or who-knows-what. Either way, if >> the packet *from* X was addressed *to* B but the response comes back >> from *A*, then host X is going to drop the packet as >> invalid/irrelevant/etc. > > You are assuming facts not in evidence. It doesn't matter which > physical interface transmits the packet. For instance, if I ping a > router's loopback interface, there is nothing stopping the router from > making the loopback the source IP address of the return packet even > though the (virtual) loopback interface _obviously_ did not physically > transmit the packet. > > Another example: Imagine a web server with two uplinks in _different_ > subnets running Quagga. Now assume the web server gets an HTTP > request and the route back to the requesting host changes before all > the packets are returned. Does the download break? Sure, if you use > an implementation too broken for words. If not, things work just fine. > > Could everyone please stop coming up with "if people are stupid and > break things, things don't work" examples. We all agree on that. > > Back in reality land, things that broken tend not to be used. (And > please no jokes about cisco or microsoft or whatever.) > From cmeidinger at sendmail.com Tue May 12 15:04:49 2009 From: cmeidinger at sendmail.com (Chris Meidinger) Date: Tue, 12 May 2009 22:04:49 +0200 Subject: two interfaces one subnet In-Reply-To: <4A09B3BF.6050309@xyonet.com> References: <4B3726C0-20FE-4598-B4DA-44FA74FDFC71@sendmail.com> <59f980d60905111440i5b4894b6hfdfe8c3a6a5777d9@mail.gmail.com> <4A09B3BF.6050309@xyonet.com> Message-ID: <4057E663-0743-4C63-A51D-BB3A99BF0796@sendmail.com> On 12.05.2009, at 19:37, Curtis Maurand wrote: > > Try this: > > http://www.linuxfoundation.org/en/Net:Bridge Wow. It's really hard to convince people that you're not trying to solve a problem today but to avoid one tomorrow. Stil, I want to thank everyone that responded - both publicly and privately - for the valuable input. (Even the posts that tore me up were useful.) I was surprised and pleased about both the quality of input that I received, and the speed with which that input came. Thanks NANOG! Chris From nenolod at systeminplace.net Tue May 12 16:06:57 2009 From: nenolod at systeminplace.net (William Pitcock) Date: Tue, 12 May 2009 21:06:57 +0000 Subject: two interfaces one subnet Message-ID: <467218079-1242162343-cardhu_decombobulator_blackberry.rim.net-802488309-@bxe1195.bisx.prod.on.blackberry> Completely off topic but, does this subject make anyone else immediately think of 2girls1cup? I blame the internets for my making this correlation... ------Original Message------ From: Martin Hannigan To: Patrick W. Gilmore Cc: NANOG list Subject: Re: two interfaces one subnet Sent: May 12, 2009 11:06 AM On Tue, May 12, 2009 at 12:12 AM, Patrick W. Gilmore wrote: > On May 11, 2009, at 11:43 PM, Ben Scott wrote: > >> On Mon, May 11, 2009 at 11:01 PM, Patrick W. Gilmore >> wrote: >> > > Do you even read your own posts? Specifically: >>> >>> On May 11, 2009, at 5:40 PM, Ben Scott wrote: >>> >>> Either way, if >>>> the packet *from* X was addressed *to* B but the response comes back >>>> from *A*, then host X is going to drop the packet as >>>> invalid/irrelevant/etc. >>>> >>> >>> The receiving host X does not care (or even know) if A and B are in the >>> same >>> prefix. >>> >> >> Look again. A and B are *IP addresses*, not hosts. >> > > Sometimes people agree with me, sometimes they don't, and sometimes I agree > with them. But I've yet to have someone claim to be arguing against me > while proving my point. > > Anyone else want to unconfused Ben? I obviously cannot. Really nothing clever about this at all in application or practicality. host> cat /etc/services | grep nntp nntp 119/tcp readnews untp # USENET News Transfer Protocol host1> cat /etc/hosts | grep news 127.0.0.1 localhost 192.168.0.100 clue-store 192.168.0.100 news-out 192.168.0.101 news-in If this didn't work, you'd suppose that virtual machines and IP aliasing wouldn't work either. Unless routes facing the world on the device are "tweaked", this should work fine and be reliable (if implemented cluefully). Am I not getting it? Best, -M< -- Martin Hannigan martin at theicelandguy.com p: +16178216079 Power, Network, and Costs Consulting for Iceland Datacenters and Occupants -- William Pitcock SystemInPlace - Simple Hosting Solutions 1-866-519-6149 From sar at knowledgecomputers.net Tue May 12 17:19:31 2009 From: sar at knowledgecomputers.net (Sarpreet) Date: Tue, 12 May 2009 15:19:31 -0700 Subject: Multilink PPPoE Scalability Issue Message-ID: <4A09F5F3.9030104@knowledgecomputers.net> Please help :) The network topology is: ADSL CPE (Cisco 2800) +===[PPPoE]===+ LAC (Telco's equipment) +===[L2TP]===+ LNS (Cisco 7513) The setup is for aggregating multiple PPPoE DSL lines with PPP. Using the Cisco 7513 as the LNS, the setup works up to 15 MLPPP bundles and with Cisco 7200-NPE400 only works up to 5 MLPPP bundles. After that, additional MLPPP bundle attempting to connect won't be able to complete IPCP phrase--the L2TP tunnels are created, each individual PPP link members are up, and the MLPPP bundle is created, just cannot finish the IP "handshake" part of the IPCP phrase. In fact, even a normal PPP (without Multilink) session won't be able to complete the IPCP phrase as long as there are 15 active working MLPPP bundle is on. I have search through Cisco's website to see if there is any documented limitation/restriction on the number of bundles the 7513 can support. The closest thing I can find is an reference to a 7500 w/ VIP4-80 can only support a limited number of T1 MLPPP bundles ( http://www.cisco.com/en/US/docs/ios/12_0t/12_0t3/feature/guide/multippp.html#wpxref1033494 ). Cisco 7513 spec: Cisco IOS Software, RSP Software (RSP-JSV-M), Version 12.4(21), RELEASE SOFTWARE (fc1) Cisco RSP8 (R7000) processor with 262144K/8216K bytes of memory. R7000 CPU at 250MHz, Implementation 39, Rev 2.1, 256KB L2, 2048KB L3 Cache Last reset from power-on Chassis Interface. 1 FEIP2 controller (2 FastEthernet). 2 FastEthernet interfaces 2043K bytes of NVRAM. 62720K bytes of ATA PCMCIA card at slot 0 (Sector size 512 bytes). 16384K bytes of Flash internal SIMM (Sector size 256K). Cisc 2800 spec: Cisco IOS Software, 2800 Software (C2800NM-ADVIPSERVICESK9-M), Version 12.4(15)T3, RELEASE SOFTWARE (fc1) Cisco 2811 (revision 53.51) with 247808K/14336K bytes of memory. Processor board ID FTX0945A4WJ 2 FastEthernet interfaces 3 ATM interfaces 1 Virtual Private Network (VPN) Module DRAM configuration is 64 bits wide with parity enabled. 239K bytes of non-volatile configuration memory. 62720K bytes of ATA CompactFlash (Read/Write) ----------- Relevant CPE config: ----------------- interface ATM0/0/0 no ip address no atm ilmi-keepalive dsl operating-mode auto pvc 0/33 tx-ring-limit 3 vc-hold-queue 80 pppoe-client dial-pool-number 1 ! ! interface ATM0/1/0 no ip address no atm ilmi-keepalive dsl operating-mode auto pvc 0/33 tx-ring-limit 3 vc-hold-queue 80 pppoe-client dial-pool-number 1 ! ! interface Dialer1 mtu 1486 ip address x.x.x.1 255.255.255.0 encapsulation ppp dialer pool 1 no keepalive no fair-queue no cdp enable ppp chap hostname abc at smarttadsl.com ppp chap password highlysecretive ppp pap sent-username vaamadsl at smarttadsl.com password highlysecretive ppp link reorders ppp multilink ppp multilink fragment disable ! ip route 0.0.0.0 0.0.0.0 Dialer1 ----------- Relevant LNS config: ----------------- aaa authentication ppp default group radius aaa accounting network default start-stop group radius vpdn enable ! vpdn-group 1 ! Default L2TP VPDN group accept-dialin protocol l2tp virtual-template 1 lcp renegotiation always l2tp tunnel password faketunnelpass ip mtu adjust interface FastEthernet8/1/0 description Facing-LAC ip address y.y.y.5 255.255.255.252 ip tcp adjust-mss 1446 full-duplex fair-queue ! interface Virtual-Template1 ip address x.x.x.254 255.255.255.0 no peer default ip address no keepalive ppp mtu adaptive ppp authentication pap ppp link reorders ppp multilink ppp multilink fragment disable ! Sarpreet Basi Knowledge Computers sar at knowledgecomputers.net From scott at doc.net.au Tue May 12 21:48:06 2009 From: scott at doc.net.au (Scott Howard) Date: Tue, 12 May 2009 19:48:06 -0700 Subject: two interfaces one subnet In-Reply-To: <79EB9847-01DA-47F3-921F-DFF996598188@sendmail.com> References: <4B3726C0-20FE-4598-B4DA-44FA74FDFC71@sendmail.com> <4A089933.1060705@olp.net> <5AF650D0-1378-494D-B4A6-09B099E64B84@sendmail.com> <59f980d60905111448u3c4a2ef7rbc9928d2ba1a3290@mail.gmail.com> <79EB9847-01DA-47F3-921F-DFF996598188@sendmail.com> Message-ID: On Mon, May 11, 2009 at 2:59 PM, Chris Meidinger wrote: > Just to restate here, for people who have been responding both publicly and > privately: > > I know that *I* can make it work, and I know that *you* can make it work. > But I also know that it's not likely to stay working. You might like to go and tell Sun, and most people who run Solaris. This is not only a valid configuration in Solaris, but it's Sun's recommended redundancy method, via Solaris "IP Multipathing" (IPMP) I have personally configured hundreds of Solaris systems with IPMP, and every single one of them has stayed working, for years in many cases. Yes, you will need a different MAC address for each interface (which isn't the default on many systems, especially Suns), and you won't necessarily be able to control which interface traffic will be sent over if both links are up - but if you're happy with those requirements it's it's a perfectly valid deployment. Scott. From randy at psg.com Wed May 13 02:22:08 2009 From: randy at psg.com (Randy Bush) Date: Wed, 13 May 2009 09:22:08 +0200 Subject: install in dallas Message-ID: we need a gsr and a few more reasonably sized devices racked and cabled in dallas and would appreciate private email recommending a local contractor. randy From drew.weaver at thenap.com Wed May 13 07:07:32 2009 From: drew.weaver at thenap.com (Drew Weaver) Date: Wed, 13 May 2009 05:07:32 -0700 Subject: Network Performance Monitoring/Route Optimization products Message-ID: Hi there, I am trying to get some opinions on what people are using these days for network performance monitoring software/(appliances?) which can give a sense of what performance is like for the folks actually using the network. Does anyone have any advice on this matter and have you found that these tools are really useful in pinpointing trouble spots before they become major issues? Also, does anyone know of any companies who have new and exciting products which compete with the Internap FCP/Routescience(Avaya) box in the Routing Optimization space? I haven't really been able to find anything except for those two, and Avaya is clearly moving in a more enterprise direction (rather than ISP/service provider) with the CNA. Off-list is fine if you like. Thanks, -Drew From sfischer1967 at gmail.com Wed May 13 09:10:11 2009 From: sfischer1967 at gmail.com (Steven Fischer) Date: Wed, 13 May 2009 10:10:11 -0400 Subject: Network Performance Monitoring/Route Optimization products In-Reply-To: References: Message-ID: <500ffb690905130710i7a71ee26s49d2e516e76af82b@mail.gmail.com> NetMRI http://www.netcordia.com/products/netmri-enterprise.asp I have used this product at my previous position, and am recommending it to my current employer as absolutely the single most effective product we could buy to ensure the stability and reliability of the network infrastructure. I'm not sure it will give you specific performance measurements you are looking for, but what it will do is identify pretty much any performance hinderance, and make recommendations on how that bottleneck can best be addressed. Steve On Wed, May 13, 2009 at 8:07 AM, Drew Weaver wrote: > Hi there, > > I am trying to get some opinions on what people are using these days for > network performance monitoring software/(appliances?) which can give a sense > of what performance is like for the folks actually using the network. > > Does anyone have any advice on this matter and have you found that these > tools are really useful in pinpointing trouble spots before they become > major issues? > > Also, does anyone know of any companies who have new and exciting products > which compete with the Internap FCP/Routescience(Avaya) box in the Routing > Optimization space? I haven't really been able to find anything except for > those two, and Avaya is clearly moving in a more enterprise direction > (rather than ISP/service provider) with the CNA. > > Off-list is fine if you like. > > Thanks, > -Drew > > > -- To him who is able to keep you from falling and to present you before his glorious presence without fault and with great joy From sfischer1967 at gmail.com Wed May 13 09:10:24 2009 From: sfischer1967 at gmail.com (Steven Fischer) Date: Wed, 13 May 2009 10:10:24 -0400 Subject: Network Performance Monitoring/Route Optimization products In-Reply-To: References: Message-ID: <500ffb690905130710j5b8b8223gab60ad23af752b1a@mail.gmail.com> NetMRI http://www.netcordia.com/products/netmri-enterprise.asp I have used this product at my previous position, and am recommending it to my current employer as absolutely the single most effective product we could buy to ensure the stability and reliability of the network infrastructure. I'm not sure it will give you specific performance measurements you are looking for, but what it will do is identify pretty much any performance hinderance, and make recommendations on how that bottleneck can best be addressed. Steve On Wed, May 13, 2009 at 8:07 AM, Drew Weaver wrote: > Hi there, > > I am trying to get some opinions on what people are using these days for > network performance monitoring software/(appliances?) which can give a sense > of what performance is like for the folks actually using the network. > > Does anyone have any advice on this matter and have you found that these > tools are really useful in pinpointing trouble spots before they become > major issues? > > Also, does anyone know of any companies who have new and exciting products > which compete with the Internap FCP/Routescience(Avaya) box in the Routing > Optimization space? I haven't really been able to find anything except for > those two, and Avaya is clearly moving in a more enterprise direction > (rather than ISP/service provider) with the CNA. > > Off-list is fine if you like. > > Thanks, > -Drew > > > -- To him who is able to keep you from falling and to present you before his glorious presence without fault and with great joy From irfan.zakiuddin at googlemail.com Wed May 13 10:53:11 2009 From: irfan.zakiuddin at googlemail.com (Irfan Zakiuddin) Date: Wed, 13 May 2009 16:53:11 +0100 Subject: how many BGP routers, how many ASes Message-ID: <9ba19d20905130853p30599f2euf8a32840da91207e@mail.gmail.com> Hi all, I have scouted around for this information, but not get very far. I'm hoping someone will have answers at hand. What I want to know is roughly how many : 1. ASes there are in the world today? 2. BGP routers there are, for intra-domain as well as inter-domain routing, in total in the world? 3. BGP routers do the largest ASes have? Really interesting would then be to say either how fast the above numbers are growing, or to give estimates for what the answers to 1-3 will be in 5 years time. An Internet source that provides the above information would be most useful - though I can't seem to find it with google. I'd be grateful for answer to be sent to me directly, whether you also post to NANOG is up to you. thanks in advance. irfan From jstuppi at cisco.com Wed May 13 10:56:54 2009 From: jstuppi at cisco.com (John Stuppi (jstuppi)) Date: Wed, 13 May 2009 11:56:54 -0400 Subject: how many BGP routers, how many ASes In-Reply-To: <9ba19d20905130853p30599f2euf8a32840da91207e@mail.gmail.com> References: <9ba19d20905130853p30599f2euf8a32840da91207e@mail.gmail.com> Message-ID: <15B718938C4EB84BAF41312951253BAB084AD0C1@xmb-rtp-20e.amer.cisco.com> Hi Irfan, Take a look at the Team Cymru page here: http://www.cymru.com/BGP/summary.html Thanks, John -----Original Message----- From: Irfan Zakiuddin [mailto:irfan.zakiuddin at googlemail.com] Sent: Wednesday, May 13, 2009 11:53 AM To: nanog at nanog.org Subject: how many BGP routers, how many ASes Hi all, I have scouted around for this information, but not get very far. I'm hoping someone will have answers at hand. What I want to know is roughly how many : 1. ASes there are in the world today? 2. BGP routers there are, for intra-domain as well as inter-domain routing, in total in the world? 3. BGP routers do the largest ASes have? Really interesting would then be to say either how fast the above numbers are growing, or to give estimates for what the answers to 1-3 will be in 5 years time. An Internet source that provides the above information would be most useful - though I can't seem to find it with google. I'd be grateful for answer to be sent to me directly, whether you also post to NANOG is up to you. thanks in advance. irfan From patrick at ianai.net Wed May 13 11:01:28 2009 From: patrick at ianai.net (Patrick W. Gilmore) Date: Wed, 13 May 2009 12:01:28 -0400 Subject: how many BGP routers, how many ASes In-Reply-To: <9ba19d20905130853p30599f2euf8a32840da91207e@mail.gmail.com> References: <9ba19d20905130853p30599f2euf8a32840da91207e@mail.gmail.com> Message-ID: On May 13, 2009, at 11:53 AM, Irfan Zakiuddin wrote: > I have scouted around for this information, but not get very far. I'm > hoping someone will have answers at hand. You obviously didn't look very hard. The answer to the first question is posted to this very list every Friday: The last two are probably not really knowable with any precision, but you might find some estimates. Although I'm not really sure what utility the number is. -- TTFN, patrick > What I want to know is roughly how many : > > 1. ASes there are in the world today? > 2. BGP routers there are, for intra-domain as well as inter-domain > routing, > in total in the world? > 3. BGP routers do the largest ASes have? > > > Really interesting would then be to say either how fast the above > numbers > are growing, or to give estimates for what the answers to 1-3 will > be in 5 > years time. > > An Internet source that provides the above information would be most > useful > - though I can't seem to find it with google. > > I'd be grateful for answer to be sent to me directly, whether you > also post > to NANOG is up to you. > > thanks in advance. > > irfan > From Ray.Sanders at VillageVoiceMedia.com Wed May 13 11:19:10 2009 From: Ray.Sanders at VillageVoiceMedia.com (Ray Sanders) Date: Wed, 13 May 2009 09:19:10 -0700 Subject: how many BGP routers, how many ASes In-Reply-To: <9ba19d20905130853p30599f2euf8a32840da91207e@mail.gmail.com> References: <9ba19d20905130853p30599f2euf8a32840da91207e@mail.gmail.com> Message-ID: <1242231550.21181.26.camel@artoo.vvmedia.com> Irfan, This is sent weekly to the list: Routing Table Report 04:00 +10GMT Sat 09 May, 2009 Report Website: http://thyme.apnic.net Detailed Analysis: http://thyme.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 288037 Prefixes after maximum aggregation: 136199 Deaggregation factor: 2.11 Unique aggregates announced to Internet: 140785 Total ASes present in the Internet Routing Table: 31199 Prefixes per ASN: 9.23 Origin-only ASes present in the Internet Routing Table: 27142 Origin ASes announcing only one prefix: 13239 Transit ASes present in the Internet Routing Table: 4057 Transit-only ASes present in the Internet Routing Table: 96 Average AS path length visible in the Internet Routing Table: 3.6 Max AS path length visible: 33 Max AS path prepend of ASN (43683) 31 Prefixes from unregistered ASNs in the Routing Table: 461 Unregistered ASNs in the Routing Table: 151 Number of 32-bit ASNs allocated by the RIRs: 142 Prefixes from 32-bit ASNs in the Routing Table: 30 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 194 Number of addresses announced to Internet: 2039977920 Equivalent to 121 /8s, 151 /16s and 151 /24s Percentage of available address space announced: 55.0 Percentage of allocated address space announced: 63.7 Percentage of available address space allocated: 86.4 Percentage of address space in use by end-sites: 76.9 Total number of prefixes smaller than registry allocations: 142407 On Wed, 2009-05-13 at 16:53 +0100, Irfan Zakiuddin wrote: > Hi all, > > I have scouted around for this information, but not get very far. I'm > hoping someone will have answers at hand. > > What I want to know is roughly how many : > > 1. ASes there are in the world today? > 2. BGP routers there are, for intra-domain as well as inter-domain routing, > in total in the world? > 3. BGP routers do the largest ASes have? > > > Really interesting would then be to say either how fast the above numbers > are growing, or to give estimates for what the answers to 1-3 will be in 5 > years time. > > An Internet source that provides the above information would be most useful > - though I can't seem to find it with google. > > I'd be grateful for answer to be sent to me directly, whether you also post > to NANOG is up to you. > > thanks in advance. > > irfan -- "Prediction is very difficult, especially about the future." Niels Bohr -- Ray Sanders Linux Administrator Village Voice Media Office: 602-744-6547 Cell: 602-300-4344 From Valdis.Kletnieks at vt.edu Wed May 13 11:43:33 2009 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Wed, 13 May 2009 12:43:33 -0400 Subject: how many BGP routers, how many ASes In-Reply-To: Your message of "Wed, 13 May 2009 16:53:11 BST." <9ba19d20905130853p30599f2euf8a32840da91207e@mail.gmail.com> References: <9ba19d20905130853p30599f2euf8a32840da91207e@mail.gmail.com> Message-ID: <22906.1242233013@turing-police.cc.vt.edu> On Wed, 13 May 2009 16:53:11 BST, Irfan Zakiuddin said: > 1. ASes there are in the world today? The weekly routing table summary posted here will give you a good approximation, but it does not include AS's that aren't announced on the public Internet. This may or may not be an issue, depending what you are doing with the numbers (for instance, allocated but not announced ASs may not matter if you're looking at BGP performance - but they *do* matter if you're trying to estimate a drop-dead date for 32-bit ASN deployment). -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 226 bytes Desc: not available URL: From mcmanus at ducksong.com Wed May 13 12:36:34 2009 From: mcmanus at ducksong.com (Patrick McManus) Date: Wed, 13 May 2009 13:36:34 -0400 Subject: two interfaces one subnet In-Reply-To: <79EB9847-01DA-47F3-921F-DFF996598188@sendmail.com> References: <4B3726C0-20FE-4598-B4DA-44FA74FDFC71@sendmail.com> <4A089933.1060705@olp.net> <5AF650D0-1378-494D-B4A6-09B099E64B84@sendmail.com> <59f980d60905111448u3c4a2ef7rbc9928d2ba1a3290@mail.gmail.com> <79EB9847-01DA-47F3-921F-DFF996598188@sendmail.com> Message-ID: <1242236194.26459.58.camel@tng> > use separate subnets for the different > interfaces. As someone said before, it's not rocket science. It can be a barrier to selling gear if you don't have multiple subnets easily available to you - which is a very big deal for vendors doing evals or for development teams doing staging. Almost never an issue in production, I agree. I worked on a product that had this "1 address for the service", "1 address for administration" concept as its recommended deployment. When the product was in testing or in pre-production the potential customer would sensibly want to set it up the same way it would be in production - with 2 interfaces, each with a different address. But then the prospect would tell our Sales Engineer that they had only one subnet available for testing and it would take weeks or months to remedy that. Half the time that subnet would be DHCP only. As a vendor, our motivation was to lubricate the eval and pre production stages so we could quickly move onto the next trial with a satisfied customer in our wake. We, eventually, supported it all quite smoothly taking into consideration the arp and src address interface selection methods noted elsewhere in this thread. It never posed complications interacting with anything external to our gear. As such, I don't think it is fair to characterize it as a square peg. related link how to configure Linux to do do src address based routing: http://www.linuxjournal.com/article/7291 .. though I agree bonding is a better answer to the motivation laid out in the article. final semi related thought - I have seen devices with an admin/production NIC split where the production (insecure) interface will packets accept all the way up the stack that are (IP.dst == adminIP) as long as you put the production mac as the destination on the packet. That kinda leads to a false sense of security just because they are on different subnets. Gear that doesn't have physically separate processors for control/admin and data/production has to work a lot harder to make sure those things stay separated. -- PenBay Networks VOIPRecorder - Record Calls Made with Vonage(tm) on Your Computer! www.penbaynetworks.com From herrin-nanog at dirtside.com Wed May 13 12:46:29 2009 From: herrin-nanog at dirtside.com (William Herrin) Date: Wed, 13 May 2009 13:46:29 -0400 Subject: how many BGP routers, how many ASes In-Reply-To: <9ba19d20905130853p30599f2euf8a32840da91207e@mail.gmail.com> References: <9ba19d20905130853p30599f2euf8a32840da91207e@mail.gmail.com> Message-ID: <3c3e3fca0905131046t2a80a8ele83695e1ff14bf3a@mail.gmail.com> On Wed, May 13, 2009 at 11:53 AM, Irfan Zakiuddin wrote: > What I want to know is roughly how many : > > 1. ?ASes there are in the world today? Hi Irfan, A little over 31,000. See http://www.cidr-report.org/as2.0/ > 2. ?BGP routers there are, for intra-domain as well as inter-domain routing, > in total in the world? I know of no authoritative source for this information. I used 150k for my estimate when I prepared http://bill.herrin.us/network/bgpcost.html last year; that fell more or less in the middle of the educated guesses I got here on nanog and in the other places I asked. Figure every AS must have at least one BGP router, the vast majority will have at least two, many will have more than two, and at least some will have more than 100. Figure also that there are fewer BGP routers in use than there are prefixes in the table. Gives you a lower bound of around 70k and an upper bound around 290k. > 3. ?BGP routers do the largest ASes have? Decide what you mean by largest, identify which AS that is on the CIDR report and then go ask them. > Really interesting would then be to say either how fast the above numbers > are growing, or to give estimates for what the answers to 1-3 will be in 5 > years time. http://www.potaroo.net/tools/asn32/ Figure 7 offers a handy graph from which you should be able to project a trend. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From rveloso at cs.ucla.edu Wed May 13 12:53:02 2009 From: rveloso at cs.ucla.edu (Ricardo Oliveira) Date: Wed, 13 May 2009 10:53:02 -0700 Subject: how many BGP routers, how many ASes In-Reply-To: <9ba19d20905130853p30599f2euf8a32840da91207e@mail.gmail.com> References: <9ba19d20905130853p30599f2euf8a32840da91207e@mail.gmail.com> Message-ID: <22ED66E4-06BD-4F38-9BEA-9B45343C20FE@cs.ucla.edu> you might want to have a look at: http://irl.cs.ucla.edu/topology --Ricardo On May 13, 2009, at 8:53 AM, Irfan Zakiuddin wrote: > Hi all, > > I have scouted around for this information, but not get very far. I'm > hoping someone will have answers at hand. > > What I want to know is roughly how many : > > 1. ASes there are in the world today? > 2. BGP routers there are, for intra-domain as well as inter-domain > routing, > in total in the world? > 3. BGP routers do the largest ASes have? > > > Really interesting would then be to say either how fast the above > numbers > are growing, or to give estimates for what the answers to 1-3 will > be in 5 > years time. > > An Internet source that provides the above information would be most > useful > - though I can't seem to find it with google. > > I'd be grateful for answer to be sent to me directly, whether you > also post > to NANOG is up to you. > > thanks in advance. > > irfan From kch670 at eecs.northwestern.edu Wed May 13 14:25:16 2009 From: kch670 at eecs.northwestern.edu (Kai Chen) Date: Wed, 13 May 2009 14:25:16 -0500 Subject: questions about DVFS in saving energy Message-ID: Hi, could anyone here have some idea of the following questions about Dynamic Voltage/Frequency Scaling techniques used for energy efficiency, or please give a pointer that I can trace, 1) how many servers in the market support this technique? 2) how many voltages/frequencies can the servers support? 3) What?s the transition time and cost (power) between these voltages/frequencies? Thanks, -Kai From tomb at byrneit.net Wed May 13 14:31:24 2009 From: tomb at byrneit.net (Tomas L. Byrnes) Date: Wed, 13 May 2009 12:31:24 -0700 Subject: questions about DVFS in saving energy In-Reply-To: References: Message-ID: <70D072392E56884193E3D2DE09C097A91F3E9B@pascal.zaphodb.org> -----Original Message----- From: Kai Chen [mailto:kch670 at eecs.northwestern.edu] Sent: Wednesday, May 13, 2009 12:25 PM To: nanog at merit.edu Subject: questions about DVFS in saving energy Hi, could anyone here have some idea of the following questions about Dynamic Voltage/Frequency Scaling techniques used for energy efficiency, or please give a pointer that I can trace, 1) how many servers in the market support this technique? 2) how many voltages/frequencies can the servers support? 3) What's the transition time and cost (power) between these voltages/frequencies? Thanks, -Kai ________________________________________________________________________ ____________________________________ My experience with the AMD HE CPUs has been that the scaling breaks Win2K3, and any virtualized environments. From nanog at daork.net Wed May 13 16:10:05 2009 From: nanog at daork.net (Nathan Ward) Date: Thu, 14 May 2009 09:10:05 +1200 Subject: how many BGP routers, how many ASes In-Reply-To: <3c3e3fca0905131046t2a80a8ele83695e1ff14bf3a@mail.gmail.com> References: <9ba19d20905130853p30599f2euf8a32840da91207e@mail.gmail.com> <3c3e3fca0905131046t2a80a8ele83695e1ff14bf3a@mail.gmail.com> Message-ID: <8C168894-9D20-4DF3-8529-0E8B05FCD70F@daork.net> On 14/05/2009, at 5:46 AM, William Herrin wrote: > Figure every AS must have at least one BGP router, the vast majority > will have at least two, many will have more than two, and at least > some will have more than 100. Figure also that there are fewer BGP > routers in use than there are prefixes in the table. Gives you a lower > bound of around 70k and an upper bound around 290k. How are you certain that there are fewer BGP routers than prefixes? At all my previous employers we have had more routers than prefixes we advertised to the global table (which is where you get your 290k number). -- Nathan Ward From j at arpa.com Wed May 13 16:54:49 2009 From: j at arpa.com (jamie rishaw) Date: Wed, 13 May 2009 16:54:49 -0500 Subject: how many BGP routers, how many ASes In-Reply-To: <9ba19d20905130853p30599f2euf8a32840da91207e@mail.gmail.com> References: <9ba19d20905130853p30599f2euf8a32840da91207e@mail.gmail.com> Message-ID: Wow, wish *I* had a group of people willing to do my thesis paper research for me .. From nenolod at systeminplace.net Wed May 13 17:19:40 2009 From: nenolod at systeminplace.net (William Pitcock) Date: Wed, 13 May 2009 22:19:40 +0000 Subject: questions about DVFS in saving energy Message-ID: <1580421295-1242253104-cardhu_decombobulator_blackberry.rim.net-1153018283-@bxe1195.bisx.prod.on.blackberry> Xen handles the AMD HE CPUs just fine here. What sort of breakage are you experiencing? William ------Original Message------ From: Tomas L. Byrnes To: Kai Chen To: nanog at merit.edu Subject: RE: questions about DVFS in saving energy Sent: May 13, 2009 2:31 PM -----Original Message----- From: Kai Chen [mailto:kch670 at eecs.northwestern.edu] Sent: Wednesday, May 13, 2009 12:25 PM To: nanog at merit.edu Subject: questions about DVFS in saving energy Hi, could anyone here have some idea of the following questions about Dynamic Voltage/Frequency Scaling techniques used for energy efficiency, or please give a pointer that I can trace, 1) how many servers in the market support this technique? 2) how many voltages/frequencies can the servers support? 3) What's the transition time and cost (power) between these voltages/frequencies? Thanks, -Kai ________________________________________________________________________ ____________________________________ My experience with the AMD HE CPUs has been that the scaling breaks Win2K3, and any virtualized environments. -- William Pitcock SystemInPlace - Simple Hosting Solutions 1-866-519-6149 From tomb at byrneit.net Wed May 13 22:22:36 2009 From: tomb at byrneit.net (Tomas L. Byrnes) Date: Wed, 13 May 2009 20:22:36 -0700 Subject: questions about DVFS in saving energy In-Reply-To: <1580421295-1242253104-cardhu_decombobulator_blackberry.rim.net-1153018283-@bxe1195.bisx.prod.on.blackberry> References: <1580421295-1242253104-cardhu_decombobulator_blackberry.rim.net-1153018283-@bxe1195.bisx.prod.on.blackberry> Message-ID: <70D072392E56884193E3D2DE09C097A91F3EAD@pascal.zaphodb.org> Top-post due to prior: VMWare Server 1.x/ Win2K3 server, standalone and as host for above. VMWare ESXi: Win2K3 and Win2K systems trash volumes. Basically the CPU scaling on the host makes the guest OS fall apart. >-----Original Message----- >From: William Pitcock [mailto:nenolod at systeminplace.net] >Sent: Wednesday, May 13, 2009 3:20 PM >To: Tomas L. Byrnes; Kai Chen; nanog at merit.edu >Subject: Re: questions about DVFS in saving energy > >Xen handles the AMD HE CPUs just fine here. What sort of breakage are >you experiencing? > >William >------Original Message------ >From: Tomas L. Byrnes >To: Kai Chen >To: nanog at merit.edu >Subject: RE: questions about DVFS in saving energy >Sent: May 13, 2009 2:31 PM > > >-----Original Message----- >From: Kai Chen [mailto:kch670 at eecs.northwestern.edu] >Sent: Wednesday, May 13, 2009 12:25 PM >To: nanog at merit.edu >Subject: questions about DVFS in saving energy > >Hi, could anyone here have some idea of the following questions about >Dynamic Voltage/Frequency Scaling techniques used for energy efficiency, >or please give a pointer that I can trace, >1) how many servers in the market support this technique? >2) how many voltages/frequencies can the servers support? >3) What's the transition time and cost (power) between these >voltages/frequencies? > >Thanks, >-Kai >_______________________________________________________________________ _ >____________________________________ > > >My experience with the AMD HE CPUs has been that the scaling breaks >Win2K3, and any virtualized environments. > > > >-- >William Pitcock >SystemInPlace - Simple Hosting Solutions >1-866-519-6149 From karl at theangryangel.co.uk Thu May 14 03:09:57 2009 From: karl at theangryangel.co.uk (Karl Southern) Date: Thu, 14 May 2009 09:09:57 +0100 Subject: questions about DVFS in saving energy In-Reply-To: <70D072392E56884193E3D2DE09C097A91F3EAD@pascal.zaphodb.org> References: <1580421295-1242253104-cardhu_decombobulator_blackberry.rim.net-1153018283-@bxe1195.bisx.prod.on.blackberry> <70D072392E56884193E3D2DE09C097A91F3EAD@pascal.zaphodb.org> Message-ID: <4A0BD1D5.60600@theangryangel.co.uk> Tomas L. Byrnes wrote: > Basically the CPU scaling on the host makes the guest OS fall apart. > Apologies for the general noise (and even more apologies for stepping outside of the nanog scope), but if it's timing related issues does /usepmtimer not resolve this issue for the VMs? It certainly does on other virtualisation solutions. From JMWheeler at dstsystems.com Thu May 14 07:04:20 2009 From: JMWheeler at dstsystems.com (JMWheeler at dstsystems.com) Date: Thu, 14 May 2009 07:04:20 -0500 Subject: Joel M. Wheeler is out of the office. Message-ID: I will be out of the office starting 05/14/2009 and will not return until 05/15/2009. I will be out of the office on Thursday 5/14. I will repsond to your e-mail when I return on Friday 5/15. ----------------------------------------- Please consider the environment before printing this email and any attachments. This e-mail and any attachments are intended only for the individual or company to which it is addressed and may contain information which is privileged, confidential and prohibited from disclosure or unauthorized use under applicable law. If you are not the intended recipient of this e-mail, you are hereby notified that any use, dissemination, or copying of this e-mail or the information contained in this e-mail is strictly prohibited by the sender. If you have received this transmission in error, please return the material received to the sender and delete all copies from your system. From williams at csr.utexas.edu Thu May 14 10:48:56 2009 From: williams at csr.utexas.edu (Steve Williams) Date: Thu, 14 May 2009 10:48:56 -0500 Subject: delays to google Message-ID: <4A0C3D68.7080905@csr.utexas.edu> am seeing significant delays in getting to google. anyone else seeing this? $ traceroute www.google.com traceroute: Warning: www.google.com has multiple addresses; using 74.125.53.147 traceroute to www.l.google.com (74.125.53.147), 30 hops max, 40 byte packets 1 cisco-190 (129.116.190.250) 0.430 ms 0.350 ms 0.353 ms 2 ser10-v758.gw.utexas.edu (128.83.10.29) 1.138 ms 1.099 ms 1.057 ms 3 ser2-gi1-9.gw.utexas.edu (128.83.10.2) 10.475 ms 1.174 ms 1.584 ms 4 aust-utnoc-core-ge-6-0-0-0.tx-bb.net (192.12.10.1) 1.215 ms 1.209 ms 1.134 ms 5 te2-1--570.tr01-lsanca01.transitrail.net (137.164.131.221) 40.649 ms 40.699 ms 40.678 ms 6 * * * 7 * * * 8 * * * 9 * * * 10 * * * 11 72.14.232.10 (72.14.232.10) 261.262 ms * * 12 * * pw-in-f147.google.com (74.125.53.147) 251.867 ms -- ''' (O O) ,-------------- oOO-(_)-OOo -------------, | Stephen Williams | | Manager of Computer Services | | Center for Space Research | | University of Texas at Austin | | 3925 W. Braker Ln., Suite 200 | | Austin, TX 78759-5321 | | 512.471.7235 512.471.3570 (fax) | | williams at csr.utexas.edu | |____________________ Oooo ______________| oooO ( ) ( ) ) / \ ( (_/ \_) From aduitsis at gmail.com Thu May 14 10:51:38 2009 From: aduitsis at gmail.com (Athanasios Douitsis) Date: Thu, 14 May 2009 18:51:38 +0300 Subject: delays to google In-Reply-To: <4A0C3D68.7080905@csr.utexas.edu> References: <4A0C3D68.7080905@csr.utexas.edu> Message-ID: <317578510905140851s46bbf3b7x85cd6eeb150b3a7e@mail.gmail.com> On Thu, May 14, 2009 at 6:48 PM, Steve Williams wrote: > am seeing significant delays in getting to google. anyone else seeing > this? > > $ traceroute www.google.com > traceroute: Warning: www.google.com has multiple addresses; using > 74.125.53.147 > traceroute to www.l.google.com (74.125.53.147), 30 hops max, 40 byte > packets > 1 cisco-190 (129.116.190.250) 0.430 ms 0.350 ms 0.353 ms > 2 ser10-v758.gw.utexas.edu (128.83.10.29) 1.138 ms 1.099 ms 1.057 ms > 3 ser2-gi1-9.gw.utexas.edu (128.83.10.2) 10.475 ms 1.174 ms 1.584 ms > 4 aust-utnoc-core-ge-6-0-0-0.tx-bb.net (192.12.10.1) 1.215 ms 1.209 ms > 1.134 ms > 5 te2-1--570.tr01-lsanca01.transitrail.net (137.164.131.221) 40.649 ms > 40.699 ms 40.678 ms > 6 * * * > 7 * * * > 8 * * * > 9 * * * > 10 * * * > 11 72.14.232.10 (72.14.232.10) 261.262 ms * * > 12 * * pw-in-f147.google.com (74.125.53.147) 251.867 ms > > -- > > > ''' > (O O) > ,-------------- oOO-(_)-OOo -------------, > | Stephen Williams | > | Manager of Computer Services | > | Center for Space Research | > | University of Texas at Austin | > | 3925 W. Braker Ln., Suite 200 | > | Austin, TX 78759-5321 | > | 512.471.7235 512.471.3570 (fax) | > | williams at csr.utexas.edu | > |____________________ Oooo ______________| > oooO ( ) > ( ) ) / > \ ( (_/ > \_) > > seeing this too. From mario at fernandez.ca Thu May 14 10:52:56 2009 From: mario at fernandez.ca (Mario Fernandez) Date: Thu, 14 May 2009 11:52:56 -0400 Subject: delays to google In-Reply-To: <317578510905140851s46bbf3b7x85cd6eeb150b3a7e@mail.gmail.com> References: <4A0C3D68.7080905@csr.utexas.edu> <317578510905140851s46bbf3b7x85cd6eeb150b3a7e@mail.gmail.com> Message-ID: <3523d8b70905140852j45baf069w92949c2c524d599a@mail.gmail.com> Seeing the same thing from NY using NTT, we routed via Cogent which does not seem to be having the problem. On Thu, May 14, 2009 at 11:51 AM, Athanasios Douitsis wrote: > On Thu, May 14, 2009 at 6:48 PM, Steve Williams >wrote: > > > am seeing significant delays in getting to google. anyone else seeing > > this? > > > > $ traceroute www.google.com > > traceroute: Warning: www.google.com has multiple addresses; using > > 74.125.53.147 > > traceroute to www.l.google.com (74.125.53.147), 30 hops max, 40 byte > > packets > > 1 cisco-190 (129.116.190.250) 0.430 ms 0.350 ms 0.353 ms > > 2 ser10-v758.gw.utexas.edu (128.83.10.29) 1.138 ms 1.099 ms 1.057 ms > > 3 ser2-gi1-9.gw.utexas.edu (128.83.10.2) 10.475 ms 1.174 ms 1.584 ms > > 4 aust-utnoc-core-ge-6-0-0-0.tx-bb.net (192.12.10.1) 1.215 ms 1.209 > ms > > 1.134 ms > > 5 te2-1--570.tr01-lsanca01.transitrail.net (137.164.131.221) 40.649 ms > > 40.699 ms 40.678 ms > > 6 * * * > > 7 * * * > > 8 * * * > > 9 * * * > > 10 * * * > > 11 72.14.232.10 (72.14.232.10) 261.262 ms * * > > 12 * * pw-in-f147.google.com (74.125.53.147) 251.867 ms > > > > -- > > > > > > ''' > > (O O) > > ,-------------- oOO-(_)-OOo -------------, > > | Stephen Williams | > > | Manager of Computer Services | > > | Center for Space Research | > > | University of Texas at Austin | > > | 3925 W. Braker Ln., Suite 200 | > > | Austin, TX 78759-5321 | > > | 512.471.7235 512.471.3570 (fax) | > > | williams at csr.utexas.edu | > > |____________________ Oooo ______________| > > oooO ( ) > > ( ) ) / > > \ ( (_/ > > \_) > > > > seeing this too. > -- Sent from Boston, Massachusetts, United States Yogi Berra - "If you ask me anything I don't know, I'm not going to answer." From beckman at angryox.com Thu May 14 10:55:37 2009 From: beckman at angryox.com (Peter Beckman) Date: Thu, 14 May 2009 11:55:37 -0400 Subject: Packet Loss to Google, others Message-ID: Anyone else getting reports of Google (and other destinations) slowness? >From Verizon FIOS Northern VA: HOST: xxx.angryox.com Loss% Snt Last Avg Best Wrst StDev 1. xxx2 0.0% 20 0.6 0.6 0.4 0.7 0.1 2. 10.1.41.89 0.0% 20 1.6 1.8 1.6 3.0 0.3 3. G2-0-3-891.WASHDC-LCR-08.ver 0.0% 20 1.6 1.7 1.6 2.0 0.1 4. so-1-1-0-0.RES-BB-RTR2.veriz 0.0% 20 2.2 2.7 2.1 7.5 1.4 5. 0.ge-5-2-0.BR2.IAD8.ALTER.NE 0.0% 20 2.9 2.9 2.7 3.1 0.1 6. 204.255.168.30 0.0% 20 6.2 9.4 6.1 70.6 14.4 7. cr2.wswdc.ip.att.net 0.0% 20 6.5 6.8 6.3 7.3 0.3 8. 12.122.134.157 0.0% 20 6.2 27.8 6.1 196.8 51.4 9. ??? 100.0 20 0.0 0.0 0.0 0.0 0.0 10. 216.239.48.108 55.0% 20 328.2 335.7 326.8 389.6 20.3 11. 64.233.175.109 50.0% 20 334.7 333.0 325.1 337.4 4.0 12. 72.14.236.74 30.0% 20 328.3 328.3 324.3 335.5 3.5 13. he-in-f147.google.com 40.0% 20 335.2 328.6 323.6 337.0 4.5 >From Cox Fiber in Northern VA / DC: HOST: xxx.angryox.com Loss% Snt Last Avg Best Wrst StDev 1. 70.164.19.3 0.0% 20 0.2 0.2 0.2 0.4 0.1 2. wsip-70-168-111-17.dc.dc.cox 0.0% 20 1.7 9.6 1.5 77.5 20.9 3. mrfddsrj01-ge706.rd.dc.cox.n 0.0% 20 13.2 3.9 1.4 18.7 5.2 4. ashbbbrj01-ae0.0.r2.as.cox.n 0.0% 20 2.5 2.7 2.3 6.4 0.9 5. 209.85.240.136 0.0% 20 39.5 10.5 3.7 63.0 15.3 6. 64.233.175.111 0.0% 20 4.9 4.7 4.1 5.9 0.4 7. 72.14.236.74 0.0% 20 6.0 6.9 6.0 8.5 0.7 8. he-in-f147.google.com 0.0% 20 4.4 4.6 4.1 7.1 0.8 >From Level3 in New York: HOST: xxx.angryox.com Loss% Snt Last Avg Best Wrst StDev 1. 208.72.185.177 0.0% 20 0.4 89.0 0.3 303.9 86.1 2. 208.72.184.245 0.0% 20 0.4 0.8 0.3 7.7 1.6 3. ge-6-7.car3.NewYork1.Level3. 0.0% 20 0.5 2.3 0.5 29.9 6.6 4. vlan69.csw1.NewYork1.Level3. 0.0% 20 4.5 6.1 0.6 14.0 4.7 5. ae-61-61.ebr1.NewYork1.Level 0.0% 20 1.6 1.0 0.7 1.6 0.2 6. ae-3-3.ebr4.Washington1.Leve 0.0% 20 11.3 10.9 5.4 19.1 4.3 7. ae-64-64.csw1.Washington1.Le 0.0% 20 14.0 10.9 5.8 18.5 4.8 8. ae-1-69.edge1.Washington1.Le 0.0% 20 6.2 9.2 5.8 60.1 12.0 9. ??? 100.0 20 0.0 0.0 0.0 0.0 0.0 10. 209.85.241.50 50.0% 20 330.9 330.3 329.1 331.6 0.9 11. 64.233.175.219 55.0% 20 316.6 314.4 311.7 317.3 2.3 12. 72.14.236.66 60.0% 20 317.4 319.6 314.1 328.0 4.5 13. he-in-f147.google.com 45.0% 20 323.9 321.5 312.1 332.9 6.9 --------------------------------------------------------------------------- Peter Beckman Internet Guy beckman at angryox.com http://www.angryox.com/ --------------------------------------------------------------------------- From akennedy at cyberlinktech.com Thu May 14 10:55:47 2009 From: akennedy at cyberlinktech.com (Adam Kennedy) Date: Thu, 14 May 2009 11:55:47 -0400 Subject: delays to google In-Reply-To: <4A0C3D68.7080905@csr.utexas.edu> Message-ID: Same here through AT&T (AS7018) and Level3 (AS7911). On 5/14/09 11:48 AM, "Steve Williams" wrote: > am seeing significant delays in getting to google. anyone else seeing this? > > $ traceroute www.google.com > traceroute: Warning: www.google.com has multiple addresses; using > 74.125.53.147 > traceroute to www.l.google.com (74.125.53.147), 30 hops max, 40 byte packets > 1 cisco-190 (129.116.190.250) 0.430 ms 0.350 ms 0.353 ms > 2 ser10-v758.gw.utexas.edu (128.83.10.29) 1.138 ms 1.099 ms 1.057 ms > 3 ser2-gi1-9.gw.utexas.edu (128.83.10.2) 10.475 ms 1.174 ms 1.584 ms > 4 aust-utnoc-core-ge-6-0-0-0.tx-bb.net (192.12.10.1) 1.215 ms 1.209 > ms 1.134 ms > 5 te2-1--570.tr01-lsanca01.transitrail.net (137.164.131.221) 40.649 > ms 40.699 ms 40.678 ms > 6 * * * > 7 * * * > 8 * * * > 9 * * * > 10 * * * > 11 72.14.232.10 (72.14.232.10) 261.262 ms * * > 12 * * pw-in-f147.google.com (74.125.53.147) 251.867 ms -- Adam Kennedy Senior Network Administrator Cyberlink Technologies, Inc. Phone: 888-293-3693 x4352 Fax: 574-855-5761 From brance at jhu.edu Thu May 14 10:56:33 2009 From: brance at jhu.edu (Brance Amussen) Date: Thu, 14 May 2009 11:56:33 -0400 Subject: delays to google In-Reply-To: <4A0C3D68.7080905@csr.utexas.edu> Message-ID: We are. As well too NYTimes, Gmail, etc... traceroute to www.nytimes.com (199.239.136.200), 64 hops max, 40 byte packets 1 128.220.29.1 (128.220.29.1) 1.222 ms 0.805 ms 1.170 ms 2 172.17.2.201 (172.17.2.201) 0.894 ms 0.666 ms 0.650 ms 3 10.160.0.226 (10.160.0.226) 1.311 ms 1.361 ms 1.120 ms 4 162.129.253.97 (162.129.253.97) 1.485 ms 1.303 ms 1.312 ms 5 206.196.178.142 (206.196.178.142) 11.428 ms 2.705 ms 2.576 ms 6 45.78.120.65.in-addr.arpa (65.120.78.45) 3.602 ms 3.796 ms 3.677 ms 7 nyc-core-01.inet.qwest.net (67.14.7.42) 8.801 ms 8.505 ms 8.304 ms 8 nyc-edge-03.inet.qwest.net (205.171.217.26) 8.609 ms 8.527 ms 12.914 ms 9 * * * 10 * * * 11 * * * 12 * * * 13 * * * 14 * * * 15 * * * 16 * * * traceroute to googlemail.l.google.com (209.85.133.19), 64 hops max, 40 byte packets 1 128.220.29.1 (128.220.29.1) 1.307 ms 0.855 ms 0.911 ms 2 172.17.2.201 (172.17.2.201) 0.785 ms 0.677 ms 0.623 ms 3 10.160.0.226 (10.160.0.226) 1.245 ms 1.181 ms 1.168 ms 4 162.129.253.97 (162.129.253.97) 1.386 ms 1.434 ms 1.475 ms 5 gi1-3.ccr01.bwi01.atlas.cogentco.com (38.104.12.5) 4.709 ms 4.506 ms 4.494 ms 6 te4-2.ccr01.phl01.atlas.cogentco.com (154.54.2.174) 7.189 ms 7.394 ms 7.414 ms 7 te8-2.mpd03.jfk02.atlas.cogentco.com (154.54.2.110) 9.701 ms 9.538 ms 9.690 ms 8 te7-4.mpd01.jfk05.atlas.cogentco.com (154.54.3.98) 9.456 ms te7-1.ccr04.jfk02.atlas.cogentco.com (154.54.24.134) 9.527 ms te7-4.mpd01.jfk05.atlas.cogentco.com (154.54.3.98) 9.685 ms 9 te8-4.ccr02.jfk05.atlas.cogentco.com (154.54.26.66) 9.731 ms te1-1.ccr02.jfk05.atlas.cogentco.com (154.54.3.161) 9.898 ms te2-1.ccr02.jfk05.atlas.cogentco.com (154.54.3.105) 9.844 ms 10 * * * 11 209.85.255.68 (209.85.255.68) 278.907 ms 276.794 ms * 12 209.85.251.9 (209.85.251.9) 298.127 ms * 297.635 ms 13 * * * 14 * * * 15 * 209.85.177.58 (209.85.177.58) 292.976 ms * On 5/14/09 11:48 AM, "Steve Williams" wrote: > am seeing significant delays in getting to google. anyone else seeing this? > > $ traceroute www.google.com > traceroute: Warning: www.google.com has multiple addresses; using > 74.125.53.147 > traceroute to www.l.google.com (74.125.53.147), 30 hops max, 40 byte packets > 1 cisco-190 (129.116.190.250) 0.430 ms 0.350 ms 0.353 ms > 2 ser10-v758.gw.utexas.edu (128.83.10.29) 1.138 ms 1.099 ms 1.057 ms > 3 ser2-gi1-9.gw.utexas.edu (128.83.10.2) 10.475 ms 1.174 ms 1.584 ms > 4 aust-utnoc-core-ge-6-0-0-0.tx-bb.net (192.12.10.1) 1.215 ms 1.209 > ms 1.134 ms > 5 te2-1--570.tr01-lsanca01.transitrail.net (137.164.131.221) 40.649 > ms 40.699 ms 40.678 ms > 6 * * * > 7 * * * > 8 * * * > 9 * * * > 10 * * * > 11 72.14.232.10 (72.14.232.10) 261.262 ms * * > 12 * * pw-in-f147.google.com (74.125.53.147) 251.867 ms From marcus.sachs at verizon.com Thu May 14 10:56:57 2009 From: marcus.sachs at verizon.com (Sachs, Marcus Hans (Marc)) Date: Thu, 14 May 2009 11:56:57 -0400 Subject: delays to google In-Reply-To: <4A0C3D68.7080905@csr.utexas.edu> References: <4A0C3D68.7080905@csr.utexas.edu> Message-ID: <81D582C724CA1046A279A7EE1299638B0120E3B3@FHDP1LUMXCV24.us.one.verizon.com> We are tracking it here: http://isc.sans.org/diary.html?storyid=6388 Marc Sachs Director, SANS Internet Storm Center -----Original Message----- From: Steve Williams [mailto:williams at csr.utexas.edu] Sent: Thursday, May 14, 2009 11:49 AM To: nanog at merit.edu Subject: delays to google am seeing significant delays in getting to google. anyone else seeing this? $ traceroute www.google.com traceroute: Warning: www.google.com has multiple addresses; using 74.125.53.147 traceroute to www.l.google.com (74.125.53.147), 30 hops max, 40 byte packets 1 cisco-190 (129.116.190.250) 0.430 ms 0.350 ms 0.353 ms 2 ser10-v758.gw.utexas.edu (128.83.10.29) 1.138 ms 1.099 ms 1.057 ms 3 ser2-gi1-9.gw.utexas.edu (128.83.10.2) 10.475 ms 1.174 ms 1.584 ms 4 aust-utnoc-core-ge-6-0-0-0.tx-bb.net (192.12.10.1) 1.215 ms 1.209 ms 1.134 ms 5 te2-1--570.tr01-lsanca01.transitrail.net (137.164.131.221) 40.649 ms 40.699 ms 40.678 ms 6 * * * 7 * * * 8 * * * 9 * * * 10 * * * 11 72.14.232.10 (72.14.232.10) 261.262 ms * * 12 * * pw-in-f147.google.com (74.125.53.147) 251.867 ms -- ''' (O O) ,-------------- oOO-(_)-OOo -------------, | Stephen Williams | | Manager of Computer Services | | Center for Space Research | | University of Texas at Austin | | 3925 W. Braker Ln., Suite 200 | | Austin, TX 78759-5321 | | 512.471.7235 512.471.3570 (fax) | | williams at csr.utexas.edu | |____________________ Oooo ______________| oooO ( ) ( ) ) / \ ( (_/ \_) From eduardo.silvestre at nfsi.pt Thu May 14 10:51:00 2009 From: eduardo.silvestre at nfsi.pt (Eduardo Silvestre) Date: Thu, 14 May 2009 16:51:00 +0100 (WEST) Subject: delays to google In-Reply-To: <317578510905140851s46bbf3b7x85cd6eeb150b3a7e@mail.gmail.com> Message-ID: <1043079530.8141242316260772.JavaMail.root@zimbra.nfsi.pt> Hello, Same issue in portugal and spain. pt:~# traceroute www.google.com traceroute: Warning: www.google.com has multiple addresses; using 209.85.227.147 traceroute to www.l.google.com (209.85.227.147), 30 hops max, 40 byte packets 1 ge130-1000m.cr2.lisboa.nfsi.pt (81.92.200.126) 0.203 ms 0.085 ms 0.108 ms 2 xe12-10GE.xmr1.Lisbon.as25137.net (81.92.201.10) 7.358 ms 0.349 ms 0.239 ms 3 if-3-2.core1.PV9-Lisbon.as6453.net (195.219.186.9) 0.235 ms 0.347 ms 0.239 ms 4 if-12-0-0.mcore3.L78-London.as6453.net (195.219.144.5) 26.974 ms 27.200 ms 26.847 ms 5 if-5-0-0.mcore3.LDN-London.as6453.net (195.219.195.9) 32.343 ms 32.452 ms 32.345 ms 6 Vlan62.icore1.LDN-London.as6453.net (195.219.83.1) 39.464 ms 29.329 ms 35.719 ms 7 xe-10-2-0-edge3.london1.level3.net (4.68.63.105) 27.469 ms 27.456 ms 27.474 ms 8 ae-11-51.car1.London1.Level3.net (4.69.139.66) 27.596 ms ae-21-52.car1.London1.Level3.net (4.69.139.98) 85.304 ms ae-11-51.car1.London1.Level3.net (4.69.139.66) 36.955 ms 9 * * * 10 * * * 11 * * * 12 * 72.14.236.191 (72.14.236.191) 389.644 ms * 13 * * 209.85.243.93 (209.85.243.93) 387.207 ms 14 * * wy-in-f147.google.com (209.85.227.147) 392.378 ms es:~# traceroute www.google.com traceroute to www.google.com (209.85.227.103), 30 hops max, 40 byte packets 1 94.46.247.33 (94.46.247.33) 0.401 ms 0.448 ms 0.515 ms 2 194.25.210.137 (194.25.210.137) 0.287 ms 0.297 ms 0.345 ms 3 194.25.6.66 (194.25.6.66) 41.014 ms 33.308 ms 41.071 ms 4 * * * 5 * * 209.85.255.170 (209.85.255.170) 390.129 ms 6 72.14.232.208 (72.14.232.208) 387.012 ms * * 7 * 72.14.232.130 (72.14.232.130) 387.439 ms 386.662 ms 8 * * 72.14.236.191 (72.14.236.191) 380.375 ms 9 * * * 10 * * * 11 wy-in-f103.google.com (209.85.227.103) 382.547 ms 403.198 ms * Regards, --- Eduardo Silvestre nfsi telecom, lda. eduardo.silvestre at nfsi.pt Tel. (+351) 21 949 2300 - Fax (+351) 21 949 2301 http://www.nfsi.pt/ ----- Original Message ----- From: "Athanasios Douitsis" To: "Steve Williams" Cc: nanog at merit.edu Sent: Thursday, May 14, 2009 4:51:38 PM GMT +00:00 GMT Britain, Ireland, Portugal Subject: Re: delays to google On Thu, May 14, 2009 at 6:48 PM, Steve Williams wrote: > am seeing significant delays in getting to google. anyone else seeing > this? > > $ traceroute www.google.com > traceroute: Warning: www.google.com has multiple addresses; using > 74.125.53.147 > traceroute to www.l.google.com (74.125.53.147), 30 hops max, 40 byte > packets > 1 cisco-190 (129.116.190.250) 0.430 ms 0.350 ms 0.353 ms > 2 ser10-v758.gw.utexas.edu (128.83.10.29) 1.138 ms 1.099 ms 1.057 ms > 3 ser2-gi1-9.gw.utexas.edu (128.83.10.2) 10.475 ms 1.174 ms 1.584 ms > 4 aust-utnoc-core-ge-6-0-0-0.tx-bb.net (192.12.10.1) 1.215 ms 1.209 ms > 1.134 ms > 5 te2-1--570.tr01-lsanca01.transitrail.net (137.164.131.221) 40.649 ms > 40.699 ms 40.678 ms > 6 * * * > 7 * * * > 8 * * * > 9 * * * > 10 * * * > 11 72.14.232.10 (72.14.232.10) 261.262 ms * * > 12 * * pw-in-f147.google.com (74.125.53.147) 251.867 ms > > -- > > > ''' > (O O) > ,-------------- oOO-(_)-OOo -------------, > | Stephen Williams | > | Manager of Computer Services | > | Center for Space Research | > | University of Texas at Austin | > | 3925 W. Braker Ln., Suite 200 | > | Austin, TX 78759-5321 | > | 512.471.7235 512.471.3570 (fax) | > | williams at csr.utexas.edu | > |____________________ Oooo ______________| > oooO ( ) > ( ) ) / > \ ( (_/ > \_) > > seeing this too. From Sam.Crooks at experian.com Thu May 14 10:57:35 2009 From: Sam.Crooks at experian.com (Crooks, Sam) Date: Thu, 14 May 2009 10:57:35 -0500 Subject: delays to google In-Reply-To: <3523d8b70905140852j45baf069w92949c2c524d599a@mail.gmail.com> Message-ID: Also seeing this in Dallas, TX area, from AT&T and Verizon > -----Original Message----- > From: Mario Fernandez [mailto:mario at fernandez.ca] > Sent: Thursday, May 14, 2009 10:53 AM > To: Athanasios Douitsis > Cc: nanog at merit.edu > Subject: Re: delays to google > > Seeing the same thing from NY using NTT, we routed via Cogent > which does not seem to be having the problem. > > On Thu, May 14, 2009 at 11:51 AM, Athanasios Douitsis > wrote: > > > On Thu, May 14, 2009 at 6:48 PM, Steve Williams > > > >wrote: > > > > > am seeing significant delays in getting to google. anyone else > > > seeing this? > > > > > > $ traceroute www.google.com > > > traceroute: Warning: www.google.com has multiple addresses; using > > > 74.125.53.147 > > > traceroute to www.l.google.com (74.125.53.147), 30 hops > max, 40 byte > > > packets > > > 1 cisco-190 (129.116.190.250) 0.430 ms 0.350 ms 0.353 ms > > > 2 ser10-v758.gw.utexas.edu (128.83.10.29) 1.138 ms 1.099 ms > > > 1.057 ms > > > 3 ser2-gi1-9.gw.utexas.edu (128.83.10.2) 10.475 ms 1.174 ms > > > 1.584 ms > > > 4 aust-utnoc-core-ge-6-0-0-0.tx-bb.net (192.12.10.1) 1.215 ms > > > 1.209 > > ms > > > 1.134 ms > > > 5 te2-1--570.tr01-lsanca01.transitrail.net (137.164.131.221) > > > 40.649 ms > > > 40.699 ms 40.678 ms > > > 6 * * * > > > 7 * * * > > > 8 * * * > > > 9 * * * > > > 10 * * * > > > 11 72.14.232.10 (72.14.232.10) 261.262 ms * * > > > 12 * * pw-in-f147.google.com (74.125.53.147) 251.867 ms > > > > > > -- > > > > > > > > > ''' > > > (O O) > > > ,-------------- oOO-(_)-OOo -------------, > > > | Stephen Williams | > > > | Manager of Computer Services | > > > | Center for Space Research | > > > | University of Texas at Austin | > > > | 3925 W. Braker Ln., Suite 200 | > > > | Austin, TX 78759-5321 | > > > | 512.471.7235 512.471.3570 (fax) | > > > | williams at csr.utexas.edu | > > > |____________________ Oooo ______________| > > > oooO ( ) > > > ( ) ) / > > > \ ( (_/ > > > \_) > > > > > > seeing this too. > > > > > > -- > > Sent from Boston, Massachusetts, United States Yogi Berra > > - "If you ask me anything I don't know, I'm not going to answer." > From william.mccall at gmail.com Thu May 14 10:58:09 2009 From: william.mccall at gmail.com (William McCall) Date: Thu, 14 May 2009 10:58:09 -0500 Subject: delays to google In-Reply-To: <4A0C3D68.7080905@csr.utexas.edu> References: <4A0C3D68.7080905@csr.utexas.edu> Message-ID: Seeing this on blackberry and Verizon business. On 5/14/09, Steve Williams wrote: > am seeing significant delays in getting to google. anyone else seeing this? > > $ traceroute www.google.com > traceroute: Warning: www.google.com has multiple addresses; using > 74.125.53.147 > traceroute to www.l.google.com (74.125.53.147), 30 hops max, 40 byte packets > 1 cisco-190 (129.116.190.250) 0.430 ms 0.350 ms 0.353 ms > 2 ser10-v758.gw.utexas.edu (128.83.10.29) 1.138 ms 1.099 ms 1.057 ms > 3 ser2-gi1-9.gw.utexas.edu (128.83.10.2) 10.475 ms 1.174 ms 1.584 ms > 4 aust-utnoc-core-ge-6-0-0-0.tx-bb.net (192.12.10.1) 1.215 ms 1.209 > ms 1.134 ms > 5 te2-1--570.tr01-lsanca01.transitrail.net (137.164.131.221) 40.649 > ms 40.699 ms 40.678 ms > 6 * * * > 7 * * * > 8 * * * > 9 * * * > 10 * * * > 11 72.14.232.10 (72.14.232.10) 261.262 ms * * > 12 * * pw-in-f147.google.com (74.125.53.147) 251.867 ms > > -- > > > ''' > (O O) > ,-------------- oOO-(_)-OOo -------------, > | Stephen Williams | > | Manager of Computer Services | > | Center for Space Research | > | University of Texas at Austin | > | 3925 W. Braker Ln., Suite 200 | > | Austin, TX 78759-5321 | > | 512.471.7235 512.471.3570 (fax) | > | williams at csr.utexas.edu | > |____________________ Oooo ______________| > oooO ( ) > ( ) ) / > \ ( (_/ > \_) > > > > > > > -- Sent from my mobile device From nevin at enginehosting.com Thu May 14 10:58:17 2009 From: nevin at enginehosting.com (nevin at enginehosting.com) Date: Thu, 14 May 2009 10:58:17 -0500 (CDT) Subject: delays to google In-Reply-To: <317578510905140851s46bbf3b7x85cd6eeb150b3a7e@mail.gmail.com> References: <4A0C3D68.7080905@csr.utexas.edu> <317578510905140851s46bbf3b7x85cd6eeb150b3a7e@mail.gmail.com> Message-ID: <1242316697.13818674@192.168.1.202> $ traceroute www.google.com traceroute to www.google.com (72.14.205.103), 30 hops max, 40 byte packets 1 ge4-1.core.mpls.gippy.net (216.243.170.254) 1.285 ms 1.500 ms 1.451 ms 2 209-240-78-33.static.iphouse.net (209.240.78.33) 1.418 ms 1.597 ms 1.887 ms 3 ge0-2-0.m20-2.mpls.iphouse.net (216.250.189.189) 0.879 ms 1.133 ms 1.125 ms 4 ge0-2-0.m20-1.mpls.iphouse.net (216.250.189.190) 1.076 ms 1.081 ms 1.079 ms 5 4.59.66.13 (4.59.66.13) 1.059 ms 1.251 ms 1.168 ms 6 ae-11-11.car1.Minneapolis1.Level3.net (4.69.136.101) 55.587 ms 55.156 ms 45.585 ms 7 ae-4-4.ebr1.Chicago1.Level3.net (4.69.136.106) 9.725 ms 22.425 ms 21.340 ms 8 ae-2-2.ebr2.NewYork2.Level3.net (4.69.132.66) 29.637 ms 30.114 ms 30.330 ms 9 ae-6-6.ebr4.NewYork1.Level3.net (4.69.141.21) 43.328 ms 43.298 ms 43.226 ms 10 ae-64-64.csw1.NewYork1.Level3.net (4.69.134.114) 30.466 ms ae-74-74.csw2.NewYork1.Level3.net (4.69.134.118) 32.182 ms ae-64-64.csw1.NewYork1.Level3.net (4.69.134.114) 30.421 ms 11 ae-3-89.edge1.NewYork1.Level3.net (4.68.16.142) 30.154 ms ae-2-79.edge1.NewYork1.Level3.net (4.68.16.78) 30.402 ms ae-3-89.edge1.NewYork1.Level3.net (4.68.16.142) 30.382 ms 12 * * * 13 * * 72.14.238.232 (72.14.238.232) 326.622 ms 14 72.14.233.113 (72.14.233.113) 329.033 ms 216.239.43.146 (216.239.43.146) 332.014 ms 332.005 ms 15 66.249.94.90 (66.249.94.90) 331.205 ms * 66.249.94.92 (66.249.94.92) 328.687 ms 16 * 72.14.236.138 (72.14.236.138) 333.385 ms 72.14.232.66 (72.14.232.66) 367.110 ms 17 qb-in-f103.google.com (72.14.205.103) 329.104 ms 332.490 ms 328.249 ms Same here. -- Nevin Lyne -- CTO -- EngineHosting.com From andrey.gordon at gmail.com Thu May 14 10:59:58 2009 From: andrey.gordon at gmail.com (Andrey Gordon) Date: Thu, 14 May 2009 11:59:58 -0400 Subject: delays to google In-Reply-To: <3523d8b70905140852j45baf069w92949c2c524d599a@mail.gmail.com> References: <4A0C3D68.7080905@csr.utexas.edu> <317578510905140851s46bbf3b7x85cd6eeb150b3a7e@mail.gmail.com> <3523d8b70905140852j45baf069w92949c2c524d599a@mail.gmail.com> Message-ID: <90ccfc90905140859k4976f983p95a40320c559fad9@mail.gmail.com> Fine on Cogent in Boston asa1-wcnt> traceroute www.google.com Type escape sequence to abort. Tracing the route to 64.233.161.147 1 fa0-1.na01.b006523-1.bos01.atlas.cogentco.com (38.99.223.37) 0 msec 0 msec 10 msec 2 gi1-36.3804.ccr02.bos01.atlas.cogentco.com (66.28.5.25) 0 msec 0 msec 0 msec 3 te3-1.ccr04.jfk02.atlas.cogentco.com (154.54.6.10) 10 msec 10 msec 10 msec 4 te7-4.ccr02.jfk05.atlas.cogentco.com (154.54.3.70) 0 msec 0 msec te4-4.ccr02.jfk05.atlas.cogentco.com (154.54.7.10) 10 msec 5 core1-0-0-8.lga.net.google.com (198.32.118.39) 10 msec 0 msec 10 msec 6 209.85.255.68 10 msec 10 msec 72.14.238.232 10 msec 7 209.85.249.11 20 msec 72.14.239.93 20 msec 209.85.249.11 10 msec 8 64.233.175.219 10 msec 20 msec 64.233.175.111 10 msec 9 216.239.49.214 30 msec 20 msec 216.239.48.190 20 msec 10 www.l.google.com (64.233.161.147) 10 msec 10 msec 20 msec asa1-wcnt> ----- Andrey Gordon [andrey.gordon at gmail.com] From andyring at inebraska.com Thu May 14 11:01:52 2009 From: andyring at inebraska.com (Andy Ringsmuth) Date: Thu, 14 May 2009 11:01:52 -0500 Subject: Packet Loss to Google, others In-Reply-To: References: Message-ID: <6C80610E-2073-49D6-B76D-0AE8B46F7572@inebraska.com> Yeah, definitely seeing it here. Gmail via POP has been dead for a while too. This is via Unite Private Networks (via Qwest ultimately) in Lincoln, Neb. Last login: Thu May 14 10:35:12 on ttys000 204-Andy:~ andyring$ ping google.com PING google.com (74.125.45.100): 56 data bytes 64 bytes from 74.125.45.100: icmp_seq=2 ttl=233 time=323.535 ms 64 bytes from 74.125.45.100: icmp_seq=3 ttl=233 time=339.249 ms 64 bytes from 74.125.45.100: icmp_seq=5 ttl=233 time=334.392 ms 64 bytes from 74.125.45.100: icmp_seq=6 ttl=233 time=320.491 ms 64 bytes from 74.125.45.100: icmp_seq=7 ttl=233 time=321.207 ms 64 bytes from 74.125.45.100: icmp_seq=10 ttl=233 time=320.925 ms 64 bytes from 74.125.45.100: icmp_seq=12 ttl=233 time=330.371 ms 64 bytes from 74.125.45.100: icmp_seq=16 ttl=233 time=321.174 ms 64 bytes from 74.125.45.100: icmp_seq=21 ttl=233 time=336.478 ms 64 bytes from 74.125.45.100: icmp_seq=24 ttl=233 time=326.038 ms 64 bytes from 74.125.45.100: icmp_seq=26 ttl=233 time=323.370 ms 64 bytes from 74.125.45.100: icmp_seq=27 ttl=233 time=330.263 ms 64 bytes from 74.125.45.100: icmp_seq=29 ttl=233 time=327.915 ms 64 bytes from 74.125.45.100: icmp_seq=30 ttl=233 time=333.887 ms 64 bytes from 74.125.45.100: icmp_seq=32 ttl=233 time=334.694 ms 64 bytes from 74.125.45.100: icmp_seq=33 ttl=233 time=330.924 ms 64 bytes from 74.125.45.100: icmp_seq=34 ttl=233 time=330.133 ms 64 bytes from 74.125.45.100: icmp_seq=35 ttl=233 time=333.507 ms ^C --- google.com ping statistics --- 37 packets transmitted, 18 packets received, 51% packet loss round-trip min/avg/max/stddev = 320.491/328.808/339.249/5.800 ms 204-Andy:~ andyring$ 204-Andy:~ andyring$ On May 14, 2009, at 10:55 AM, Peter Beckman wrote: > Anyone else getting reports of Google (and other destinations) > slowness? > >> From Verizon FIOS Northern VA: > > HOST: xxx.angryox.com Loss% Snt Last Avg Best > Wrst StDev > 1. xxx2 0.0% 20 0.6 0.6 0.4 > 0.7 0.1 > 2. 10.1.41.89 0.0% 20 1.6 1.8 1.6 > 3.0 0.3 > 3. G2-0-3-891.WASHDC-LCR-08.ver 0.0% 20 1.6 1.7 1.6 > 2.0 0.1 > 4. so-1-1-0-0.RES-BB-RTR2.veriz 0.0% 20 2.2 2.7 2.1 > 7.5 1.4 > 5. 0.ge-5-2-0.BR2.IAD8.ALTER.NE 0.0% 20 2.9 2.9 2.7 > 3.1 0.1 > 6. 204.255.168.30 0.0% 20 6.2 9.4 6.1 > 70.6 14.4 > 7. cr2.wswdc.ip.att.net 0.0% 20 6.5 6.8 6.3 > 7.3 0.3 > 8. 12.122.134.157 0.0% 20 6.2 27.8 6.1 > 196.8 51.4 > 9. ??? 100.0 20 0.0 0.0 0.0 > 0.0 0.0 > 10. 216.239.48.108 55.0% 20 328.2 335.7 326.8 > 389.6 20.3 > 11. 64.233.175.109 50.0% 20 334.7 333.0 325.1 > 337.4 4.0 > 12. 72.14.236.74 30.0% 20 328.3 328.3 324.3 > 335.5 3.5 > 13. he-in-f147.google.com 40.0% 20 335.2 328.6 323.6 > 337.0 4.5 > >> From Cox Fiber in Northern VA / DC: > > HOST: xxx.angryox.com Loss% Snt Last Avg Best > Wrst StDev > 1. 70.164.19.3 0.0% 20 0.2 0.2 0.2 > 0.4 0.1 > 2. wsip-70-168-111-17.dc.dc.cox 0.0% 20 1.7 9.6 1.5 > 77.5 20.9 > 3. mrfddsrj01-ge706.rd.dc.cox.n 0.0% 20 13.2 3.9 1.4 > 18.7 5.2 > 4. ashbbbrj01-ae0.0.r2.as.cox.n 0.0% 20 2.5 2.7 2.3 > 6.4 0.9 > 5. 209.85.240.136 0.0% 20 39.5 10.5 3.7 > 63.0 15.3 > 6. 64.233.175.111 0.0% 20 4.9 4.7 4.1 > 5.9 0.4 > 7. 72.14.236.74 0.0% 20 6.0 6.9 6.0 > 8.5 0.7 > 8. he-in-f147.google.com 0.0% 20 4.4 4.6 4.1 > 7.1 0.8 > >> From Level3 in New York: > > HOST: xxx.angryox.com Loss% Snt Last Avg Best > Wrst StDev > 1. 208.72.185.177 0.0% 20 0.4 89.0 0.3 > 303.9 86.1 > 2. 208.72.184.245 0.0% 20 0.4 0.8 0.3 > 7.7 1.6 > 3. ge-6-7.car3.NewYork1.Level3. 0.0% 20 0.5 2.3 0.5 > 29.9 6.6 > 4. vlan69.csw1.NewYork1.Level3. 0.0% 20 4.5 6.1 0.6 > 14.0 4.7 > 5. ae-61-61.ebr1.NewYork1.Level 0.0% 20 1.6 1.0 0.7 > 1.6 0.2 > 6. ae-3-3.ebr4.Washington1.Leve 0.0% 20 11.3 10.9 5.4 > 19.1 4.3 > 7. ae-64-64.csw1.Washington1.Le 0.0% 20 14.0 10.9 5.8 > 18.5 4.8 > 8. ae-1-69.edge1.Washington1.Le 0.0% 20 6.2 9.2 5.8 > 60.1 12.0 > 9. ??? 100.0 20 0.0 0.0 0.0 > 0.0 0.0 > 10. 209.85.241.50 50.0% 20 330.9 330.3 329.1 > 331.6 0.9 > 11. 64.233.175.219 55.0% 20 316.6 314.4 311.7 > 317.3 2.3 > 12. 72.14.236.66 60.0% 20 317.4 319.6 314.1 > 328.0 4.5 > 13. he-in-f147.google.com 45.0% 20 323.9 321.5 312.1 > 332.9 6.9 > > --------------------------------------------------------------------------- > Peter Beckman > Internet Guy > beckman at angryox.com http://www.angryox.com/ > --------------------------------------------------------------------------- > From andrew at arsenaleartisans.com Thu May 14 11:04:36 2009 From: andrew at arsenaleartisans.com (andrew at arsenaleartisans.com) Date: Thu, 14 May 2009 12:04:36 -0400 (EDT) Subject: delays to google Message-ID: <41185.209.183.32.50.1242317076.squirrel@webmail12.pair.com> Sessions time out or fail from AT&T Commercial, Verizon commercial, Verizon FiOS, and AT&T 3G GSM, all from the East Coast. However, routing from a shell at pair.com: %traceroute mail.google.com traceroute: Warning: mail.google.com has multiple addresses; using 74.125.53.17 traceroute to googlemail.l.google.com (74.125.53.17), 64 hops max, 40 byte packets 2 192.168.1.41 (192.168.1.41) 3.963 ms 1.456 ms 1.477 ms 3 TenGigabitEthernet7-2.ar5.CHI1.gblx.net (207.138.112.145) 15.972 ms 14.336 ms 14.268 ms 4 po1-20G.ar3.CHI2.gblx.net (67.16.132.241) 14.563 ms 13.708 ms 14.454 ms 5 72.14.197.69 (72.14.197.69) 53.439 ms 13.862 ms 13.986 ms 6 209.85.254.122 (209.85.254.122) 14.283 ms 14.322 ms 13.999 ms 7 72.14.233.116 (72.14.233.116) 65.376 ms 65.557 ms 65.849 ms 8 216.239.46.208 (216.239.46.208) 72.424 ms 72.163 ms 71.921 ms 9 64.233.174.131 (64.233.174.131) 72.007 ms 71.711 ms 64.233.174.129 (64.233.174.129) 71.916 ms 10 72.14.232.6 (72.14.232.6) 82.512 ms 82.767 ms 71.942 ms 11 pw-in-f17.google.com (74.125.53.17) 71.432 ms 71.686 ms 71.938 ms If I tunnel through, my connection behaves with reasonable crispness. Cheers, -Andrew From eduardo.silvestre at nfsi.pt Thu May 14 10:59:20 2009 From: eduardo.silvestre at nfsi.pt (Eduardo Silvestre) Date: Thu, 14 May 2009 16:59:20 +0100 (WEST) Subject: delays to google In-Reply-To: Message-ID: <1333345401.8201242316760387.JavaMail.root@zimbra.nfsi.pt> Hello, Same issue in portugal and spain. pt:~# traceroute www.google.com traceroute: Warning: www.google.com has multiple addresses; using 209.85.227.147 traceroute to www.l.google.com (209.85.227.147), 30 hops max, 40 byte packets 1 ge130-1000m.cr2.lisboa.nfsi.pt (81.92.200.126) 0.203 ms 0.085 ms 0.108 ms 2 xe12-10GE.xmr1.Lisbon.as25137.net (81.92.201.10) 7.358 ms 0.349 ms 0.239 ms 3 if-3-2.core1.PV9-Lisbon.as6453.net (195.219.186.9) 0.235 ms 0.347 ms 0.239 ms 4 if-12-0-0.mcore3.L78-London.as6453.net (195.219.144.5) 26.974 ms 27.200 ms 26.847 ms 5 if-5-0-0.mcore3.LDN-London.as6453.net (195.219.195.9) 32.343 ms 32.452 ms 32.345 ms 6 Vlan62.icore1.LDN-London.as6453.net (195.219.83.1) 39.464 ms 29.329 ms 35.719 ms 7 xe-10-2-0-edge3.london1.level3.net (4.68.63.105) 27.469 ms 27.456 ms 27.474 ms 8 ae-11-51.car1.London1.Level3.net (4.69.139.66) 27.596 ms ae-21-52.car1.London1.Level3.net (4.69.139.98) 85.304 ms ae-11-51.car1.London1.Level3.net (4.69.139.66) 36.955 ms 9 * * * 10 * * * 11 * * * 12 * 72.14.236.191 (72.14.236.191) 389.644 ms * 13 * * 209.85.243.93 (209.85.243.93) 387.207 ms 14 * * wy-in-f147.google.com (209.85.227.147) 392.378 ms es:~# traceroute www.google.com traceroute to www.google.com (209.85.227.103), 30 hops max, 40 byte packets 1 94.46.247.33 (94.46.247.33) 0.401 ms 0.448 ms 0.515 ms 2 194.25.210.137 (194.25.210.137) 0.287 ms 0.297 ms 0.345 ms 3 194.25.6.66 (194.25.6.66) 41.014 ms 33.308 ms 41.071 ms 4 * * * 5 * * 209.85.255.170 (209.85.255.170) 390.129 ms 6 72.14.232.208 (72.14.232.208) 387.012 ms * * 7 * 72.14.232.130 (72.14.232.130) 387.439 ms 386.662 ms 8 * * 72.14.236.191 (72.14.236.191) 380.375 ms 9 * * * 10 * * * 11 wy-in-f103.google.com (209.85.227.103) 382.547 ms 403.198 ms * Regards, --- Eduardo Silvestre nfsi telecom, lda. eduardo.silvestre at nfsi.pt Tel. (+351) 21 949 2300 - Fax (+351) 21 949 2301 http://www.nfsi.pt/ ----- Original Message ----- From: "Brance Amussen" To: nanog at merit.edu Sent: Thursday, May 14, 2009 4:56:33 PM GMT +00:00 GMT Britain, Ireland, Portugal Subject: Re: delays to google We are. As well too NYTimes, Gmail, etc... traceroute to www.nytimes.com (199.239.136.200), 64 hops max, 40 byte packets 1 128.220.29.1 (128.220.29.1) 1.222 ms 0.805 ms 1.170 ms 2 172.17.2.201 (172.17.2.201) 0.894 ms 0.666 ms 0.650 ms 3 10.160.0.226 (10.160.0.226) 1.311 ms 1.361 ms 1.120 ms 4 162.129.253.97 (162.129.253.97) 1.485 ms 1.303 ms 1.312 ms 5 206.196.178.142 (206.196.178.142) 11.428 ms 2.705 ms 2.576 ms 6 45.78.120.65.in-addr.arpa (65.120.78.45) 3.602 ms 3.796 ms 3.677 ms 7 nyc-core-01.inet.qwest.net (67.14.7.42) 8.801 ms 8.505 ms 8.304 ms 8 nyc-edge-03.inet.qwest.net (205.171.217.26) 8.609 ms 8.527 ms 12.914 ms 9 * * * 10 * * * 11 * * * 12 * * * 13 * * * 14 * * * 15 * * * 16 * * * traceroute to googlemail.l.google.com (209.85.133.19), 64 hops max, 40 byte packets 1 128.220.29.1 (128.220.29.1) 1.307 ms 0.855 ms 0.911 ms 2 172.17.2.201 (172.17.2.201) 0.785 ms 0.677 ms 0.623 ms 3 10.160.0.226 (10.160.0.226) 1.245 ms 1.181 ms 1.168 ms 4 162.129.253.97 (162.129.253.97) 1.386 ms 1.434 ms 1.475 ms 5 gi1-3.ccr01.bwi01.atlas.cogentco.com (38.104.12.5) 4.709 ms 4.506 ms 4.494 ms 6 te4-2.ccr01.phl01.atlas.cogentco.com (154.54.2.174) 7.189 ms 7.394 ms 7.414 ms 7 te8-2.mpd03.jfk02.atlas.cogentco.com (154.54.2.110) 9.701 ms 9.538 ms 9.690 ms 8 te7-4.mpd01.jfk05.atlas.cogentco.com (154.54.3.98) 9.456 ms te7-1.ccr04.jfk02.atlas.cogentco.com (154.54.24.134) 9.527 ms te7-4.mpd01.jfk05.atlas.cogentco.com (154.54.3.98) 9.685 ms 9 te8-4.ccr02.jfk05.atlas.cogentco.com (154.54.26.66) 9.731 ms te1-1.ccr02.jfk05.atlas.cogentco.com (154.54.3.161) 9.898 ms te2-1.ccr02.jfk05.atlas.cogentco.com (154.54.3.105) 9.844 ms 10 * * * 11 209.85.255.68 (209.85.255.68) 278.907 ms 276.794 ms * 12 209.85.251.9 (209.85.251.9) 298.127 ms * 297.635 ms 13 * * * 14 * * * 15 * 209.85.177.58 (209.85.177.58) 292.976 ms * On 5/14/09 11:48 AM, "Steve Williams" wrote: > am seeing significant delays in getting to google. anyone else seeing this? > > $ traceroute www.google.com > traceroute: Warning: www.google.com has multiple addresses; using > 74.125.53.147 > traceroute to www.l.google.com (74.125.53.147), 30 hops max, 40 byte packets > 1 cisco-190 (129.116.190.250) 0.430 ms 0.350 ms 0.353 ms > 2 ser10-v758.gw.utexas.edu (128.83.10.29) 1.138 ms 1.099 ms 1.057 ms > 3 ser2-gi1-9.gw.utexas.edu (128.83.10.2) 10.475 ms 1.174 ms 1.584 ms > 4 aust-utnoc-core-ge-6-0-0-0.tx-bb.net (192.12.10.1) 1.215 ms 1.209 > ms 1.134 ms > 5 te2-1--570.tr01-lsanca01.transitrail.net (137.164.131.221) 40.649 > ms 40.699 ms 40.678 ms > 6 * * * > 7 * * * > 8 * * * > 9 * * * > 10 * * * > 11 72.14.232.10 (72.14.232.10) 261.262 ms * * > 12 * * pw-in-f147.google.com (74.125.53.147) 251.867 ms From tme at americafree.tv Thu May 14 11:08:50 2009 From: tme at americafree.tv (Marshall Eubanks) Date: Thu, 14 May 2009 12:08:50 -0400 Subject: delays to google In-Reply-To: <3523d8b70905140852j45baf069w92949c2c524d599a@mail.gmail.com> References: <4A0C3D68.7080905@csr.utexas.edu> <317578510905140851s46bbf3b7x85cd6eeb150b3a7e@mail.gmail.com> <3523d8b70905140852j45baf069w92949c2c524d599a@mail.gmail.com> Message-ID: <723720EA-8DAC-40DA-A48C-AF38316B1D2D@americafree.tv> On May 14, 2009, at 11:52 AM, Mario Fernandez wrote: > Seeing the same thing from NY using NTT, we routed via Cogent which > does not > seem to be having the problem. > Neither does Cogent in Virginia. Regards Marshall > On Thu, May 14, 2009 at 11:51 AM, Athanasios Douitsis >wrote: > >> On Thu, May 14, 2009 at 6:48 PM, Steve Williams >> wrote: >> >>> am seeing significant delays in getting to google. anyone else >>> seeing >>> this? >>> >>> $ traceroute www.google.com >>> traceroute: Warning: www.google.com has multiple addresses; using >>> 74.125.53.147 >>> traceroute to www.l.google.com (74.125.53.147), 30 hops max, 40 byte >>> packets >>> 1 cisco-190 (129.116.190.250) 0.430 ms 0.350 ms 0.353 ms >>> 2 ser10-v758.gw.utexas.edu (128.83.10.29) 1.138 ms 1.099 ms >>> 1.057 ms >>> 3 ser2-gi1-9.gw.utexas.edu (128.83.10.2) 10.475 ms 1.174 ms >>> 1.584 ms >>> 4 aust-utnoc-core-ge-6-0-0-0.tx-bb.net (192.12.10.1) 1.215 ms >>> 1.209 >> ms >>> 1.134 ms >>> 5 te2-1--570.tr01-lsanca01.transitrail.net (137.164.131.221) >>> 40.649 ms >>> 40.699 ms 40.678 ms >>> 6 * * * >>> 7 * * * >>> 8 * * * >>> 9 * * * >>> 10 * * * >>> 11 72.14.232.10 (72.14.232.10) 261.262 ms * * >>> 12 * * pw-in-f147.google.com (74.125.53.147) 251.867 ms >>> >>> -- >>> >>> >>> ''' >>> (O O) >>> ,-------------- oOO-(_)-OOo -------------, >>> | Stephen Williams | >>> | Manager of Computer Services | >>> | Center for Space Research | >>> | University of Texas at Austin | >>> | 3925 W. Braker Ln., Suite 200 | >>> | Austin, TX 78759-5321 | >>> | 512.471.7235 512.471.3570 (fax) | >>> | williams at csr.utexas.edu | >>> |____________________ Oooo ______________| >>> oooO ( ) >>> ( ) ) / >>> \ ( (_/ >>> \_) >>> >>> seeing this too. >> > > > > -- > > Sent from Boston, Massachusetts, United States > Yogi Berra > - > "If you ask me anything I don't know, I'm not going to answer." > From john.bond at eduserv.org.uk Thu May 14 11:10:32 2009 From: john.bond at eduserv.org.uk (John Bond) Date: Thu, 14 May 2009 17:10:32 +0100 Subject: delays to google In-Reply-To: <81D582C724CA1046A279A7EE1299638B0120E3B3@FHDP1LUMXCV24.us.one.verizon.com> References: <4A0C3D68.7080905@csr.utexas.edu> <81D582C724CA1046A279A7EE1299638B0120E3B3@FHDP1LUMXCV24.us.one.verizon.com> Message-ID: <05CBF355F7317545AB0F8BF401F9605201A20783@edu-win-eml-l01.edu2000.com> Yes we saw the same thing here but only from certain sources; however it seems to be back now John Bond Network and security Analyst Eduserv innovative technology services john.bond at eduserv.org.uk tel: +44 (0)1225 474351 fax: +44 (0)1225 474301 http://www.eduserv.org.uk > -----Original Message----- > From: Sachs, Marcus Hans (Marc) [mailto:marcus.sachs at verizon.com] > Sent: 14 May 2009 16:57 > To: Steve Williams > Cc: nanog at merit.edu > Subject: RE: delays to google > > We are tracking it here: http://isc.sans.org/diary.html?storyid=6388 > > Marc Sachs > Director, SANS Internet Storm Center > > -----Original Message----- > From: Steve Williams [mailto:williams at csr.utexas.edu] > Sent: Thursday, May 14, 2009 11:49 AM > To: nanog at merit.edu > Subject: delays to google > > am seeing significant delays in getting to google. anyone else seeing > this? > > $ traceroute www.google.com > traceroute: Warning: www.google.com has multiple addresses; using > 74.125.53.147 > traceroute to www.l.google.com (74.125.53.147), 30 hops max, 40 byte > packets > 1 cisco-190 (129.116.190.250) 0.430 ms 0.350 ms 0.353 ms > 2 ser10-v758.gw.utexas.edu (128.83.10.29) 1.138 ms 1.099 ms 1.057 > ms > 3 ser2-gi1-9.gw.utexas.edu (128.83.10.2) 10.475 ms 1.174 ms 1.584 > ms > 4 aust-utnoc-core-ge-6-0-0-0.tx-bb.net (192.12.10.1) 1.215 ms 1.209 > ms 1.134 ms > 5 te2-1--570.tr01-lsanca01.transitrail.net (137.164.131.221) 40.649 > ms 40.699 ms 40.678 ms > 6 * * * > 7 * * * > 8 * * * > 9 * * * > 10 * * * > 11 72.14.232.10 (72.14.232.10) 261.262 ms * * > 12 * * pw-in-f147.google.com (74.125.53.147) 251.867 ms > > -- > > > ''' > (O O) > ,-------------- oOO-(_)-OOo -------------, > | Stephen Williams | > | Manager of Computer Services | > | Center for Space Research | > | University of Texas at Austin | > | 3925 W. Braker Ln., Suite 200 | > | Austin, TX 78759-5321 | > | 512.471.7235 512.471.3570 (fax) | > | williams at csr.utexas.edu | > |____________________ Oooo ______________| > oooO ( ) > ( ) ) / > \ ( (_/ > \_) > > > > > > From leland at taranta.discpro.org Thu May 14 11:11:34 2009 From: leland at taranta.discpro.org (Leland E. Vandervort) Date: Thu, 14 May 2009 16:11:34 +0000 (GMT) Subject: delays to google In-Reply-To: <1043079530.8141242316260772.JavaMail.root@zimbra.nfsi.pt> Message-ID: Works fine for me... all google services up and okay here (Paris). traceroute to googlemail.l.google.com (209.85.137.83), 30 hops max, 40 byte packets 1 fe0-0.gw1.discpro.org (217.70.182.177) 1.644 ms 1.518 ms 1.420 ms 2 gandi-discpro.gdist1-d.gandi.net (217.70.176.82) 0.887 ms 0.701 ms 0.606 ms 3 vl9.core3-d.gandi.net (217.70.176.101) 0.666 ms 0.632 ms 0.527 ms 4 vl9.core4-d.gandi.net (217.70.176.102) 0.592 ms 0.556 ms 0.526 ms 5 reserved.above.net.43.141.79.in-addr.arpa (79.141.43.5) 0.666 ms 0.827 ms 0.599 ms 6 xe-4-0-0.mpr1.lhr3.uk.above.net (64.125.31.249) 7.963 ms 7.907 ms 8.165 ms 7 so-1-0-0.mpr1.lhr2.uk.above.net (64.125.28.38) 7.878 ms 7.824 ms 8.161 ms 8 213-152-230-99.google.net (213.152.230.99) 8.905 ms 8.771 ms 8.751 ms 9 209.85.252.42 (209.85.252.42) 8.893 ms 209.85.252.40 (209.85.252.40) 8.228 ms 8.090 ms 10 72.14.233.63 (72.14.233.63) 12.992 ms 16.538 ms 209.85.248.80 (209.85.248.80) 21.237 ms 11 209.85.250.141 (209.85.250.141) 16.448 ms 19.357 ms 16.506 ms 12 72.14.238.128 (72.14.238.128) 23.823 ms 23.637 ms 209.85.248.248 (209.85.248.248) 22.558 ms 13 209.85.241.189 (209.85.241.189) 24.015 ms 23.872 ms 23.672 ms 14 216.239.43.26 (216.239.43.26) 26.986 ms 24.831 ms 216.239.43.98 (216.239.43.98) 24.033 ms 15 mg-in-f83.google.com (209.85.137.83) 24.097 ms 23.879 ms 23.818 ms traceroute to www.l.google.com (209.85.227.147), 30 hops max, 40 byte packets 1 fe0-0.gw1.discpro.org (217.70.182.177) 1.703 ms 2.808 ms 1.850 ms 2 gandi-discpro.gdist1-d.gandi.net (217.70.176.82) 2.301 ms 1.563 ms 2.236 ms 3 vl9.core3-d.gandi.net (217.70.176.101) 6.426 ms 2.403 ms 1.240 ms 4 vl9.core4-d.gandi.net (217.70.176.102) 1.253 ms 2.448 ms 1.267 ms 5 reserved.above.net.43.141.79.in-addr.arpa (79.141.43.5) 1.239 ms 1.806 ms 1.270 ms 6 xe-4-0-0.mpr1.lhr3.uk.above.net (64.125.31.249) 8.534 ms 9.148 ms 20.502 ms 7 so-1-0-0.mpr1.lhr2.uk.above.net (64.125.28.38) 10.123 ms 8.156 ms 101.081 ms 8 213-152-230-99.google.net (213.152.230.99) 10.094 ms 10.335 ms 8.779 ms 9 209.85.252.40 (209.85.252.40) 9.063 ms 8.662 ms 8.336 ms 10 66.249.95.170 (66.249.95.170) 11.511 ms 11.400 ms 72.14.232.134 (72.14.232.134) 10.318 ms 11 209.85.252.83 (209.85.252.83) 10.614 ms 10.413 ms 10.455 ms 12 209.85.243.93 (209.85.243.93) 23.418 ms 17.760 ms 17.950 ms 13 wy-in-f147.google.com (209.85.227.147) 11.635 ms 10.581 ms 10.587 ms Leland On Thu, 14 May 2009, Eduardo Silvestre wrote: > Hello, > > Same issue in portugal and spain. > > pt:~# traceroute www.google.com > traceroute: Warning: www.google.com has multiple addresses; using 209.85.227.147 > traceroute to www.l.google.com (209.85.227.147), 30 hops max, 40 byte packets > 1 ge130-1000m.cr2.lisboa.nfsi.pt (81.92.200.126) 0.203 ms 0.085 ms 0.108 ms > 2 xe12-10GE.xmr1.Lisbon.as25137.net (81.92.201.10) 7.358 ms 0.349 ms 0.239 ms > 3 if-3-2.core1.PV9-Lisbon.as6453.net (195.219.186.9) 0.235 ms 0.347 ms 0.239 ms > 4 if-12-0-0.mcore3.L78-London.as6453.net (195.219.144.5) 26.974 ms 27.200 ms 26.847 ms > 5 if-5-0-0.mcore3.LDN-London.as6453.net (195.219.195.9) 32.343 ms 32.452 ms 32.345 ms > 6 Vlan62.icore1.LDN-London.as6453.net (195.219.83.1) 39.464 ms 29.329 ms 35.719 ms > 7 xe-10-2-0-edge3.london1.level3.net (4.68.63.105) 27.469 ms 27.456 ms 27.474 ms > 8 ae-11-51.car1.London1.Level3.net (4.69.139.66) 27.596 ms ae-21-52.car1.London1.Level3.net (4.69.139.98) 85.304 ms ae-11-51.car1.London1.Level3.net (4.69.139.66) 36.955 ms > 9 * * * > 10 * * * > 11 * * * > 12 * 72.14.236.191 (72.14.236.191) 389.644 ms * > 13 * * 209.85.243.93 (209.85.243.93) 387.207 ms > 14 * * wy-in-f147.google.com (209.85.227.147) 392.378 ms > > es:~# traceroute www.google.com > traceroute to www.google.com (209.85.227.103), 30 hops max, 40 byte packets > 1 94.46.247.33 (94.46.247.33) 0.401 ms 0.448 ms 0.515 ms > 2 194.25.210.137 (194.25.210.137) 0.287 ms 0.297 ms 0.345 ms > 3 194.25.6.66 (194.25.6.66) 41.014 ms 33.308 ms 41.071 ms > 4 * * * > 5 * * 209.85.255.170 (209.85.255.170) 390.129 ms > 6 72.14.232.208 (72.14.232.208) 387.012 ms * * > 7 * 72.14.232.130 (72.14.232.130) 387.439 ms 386.662 ms > 8 * * 72.14.236.191 (72.14.236.191) 380.375 ms > 9 * * * > 10 * * * > 11 wy-in-f103.google.com (209.85.227.103) 382.547 ms 403.198 ms * > > Regards, > > --- > Eduardo Silvestre > nfsi telecom, lda. > > eduardo.silvestre at nfsi.pt > Tel. (+351) 21 949 2300 - Fax (+351) 21 949 2301 > http://www.nfsi.pt/ > > ----- Original Message ----- > From: "Athanasios Douitsis" > To: "Steve Williams" > Cc: nanog at merit.edu > Sent: Thursday, May 14, 2009 4:51:38 PM GMT +00:00 GMT Britain, Ireland, Portugal > Subject: Re: delays to google > > On Thu, May 14, 2009 at 6:48 PM, Steve Williams wrote: > > > am seeing significant delays in getting to google. anyone else seeing > > this? > > > > $ traceroute www.google.com > > traceroute: Warning: www.google.com has multiple addresses; using > > 74.125.53.147 > > traceroute to www.l.google.com (74.125.53.147), 30 hops max, 40 byte > > packets > > 1 cisco-190 (129.116.190.250) 0.430 ms 0.350 ms 0.353 ms > > 2 ser10-v758.gw.utexas.edu (128.83.10.29) 1.138 ms 1.099 ms 1.057 ms > > 3 ser2-gi1-9.gw.utexas.edu (128.83.10.2) 10.475 ms 1.174 ms 1.584 ms > > 4 aust-utnoc-core-ge-6-0-0-0.tx-bb.net (192.12.10.1) 1.215 ms 1.209 ms > > 1.134 ms > > 5 te2-1--570.tr01-lsanca01.transitrail.net (137.164.131.221) 40.649 ms > > 40.699 ms 40.678 ms > > 6 * * * > > 7 * * * > > 8 * * * > > 9 * * * > > 10 * * * > > 11 72.14.232.10 (72.14.232.10) 261.262 ms * * > > 12 * * pw-in-f147.google.com (74.125.53.147) 251.867 ms > > > > -- > > > > > > ''' > > (O O) > > ,-------------- oOO-(_)-OOo -------------, > > | Stephen Williams | > > | Manager of Computer Services | > > | Center for Space Research | > > | University of Texas at Austin | > > | 3925 W. Braker Ln., Suite 200 | > > | Austin, TX 78759-5321 | > > | 512.471.7235 512.471.3570 (fax) | > > | williams at csr.utexas.edu | > > |____________________ Oooo ______________| > > oooO ( ) > > ( ) ) / > > \ ( (_/ > > \_) > > > > seeing this too. > From darden at armc.org Thu May 14 11:12:52 2009 From: darden at armc.org (Patrick Darden) Date: Thu, 14 May 2009 12:12:52 -0400 Subject: delays to google In-Reply-To: References: Message-ID: <4A0C4304.3000401@armc.org> Fixed? 5 mins ago: 1 gw1.armc.org (68.153.29.1) 0.571 ms 0.705 ms 0.732 ms 2 65.14.131.185 (65.14.131.185) 2.330 ms 2.318 ms 2.308 ms 3 axr00mia-7-0-0-0.bellsouth.net (65.83.237.92) 3.009 ms 3.001 ms 3.080 ms 4 AXR00AEP-0-1-0.bellsouth.net (65.83.236.50) 2.384 ms 2.370 ms 2.499 ms 5 65.83.238.202 (65.83.238.202) 3.148 ms 3.136 ms * 6 cr1.attga.ip.att.net (12.122.141.22) 4.011 ms 3.769 ms 4.106 ms 7 12.123.22.5 (12.123.22.5) 3.735 ms 3.042 ms 3.033 ms 8 * * * 9 72.14.233.56 (72.14.233.56) 159.416 ms * * 10 72.14.232.213 (72.14.232.213) 163.622 ms 209.85.254.241 (209.85.254.241) 165.287 ms 209.85.254.243 (209.85.254.243) 219.136 ms 11 209.85.254.6 (209.85.254.6) 170.937 ms 171.154 ms 209.85.254.10 (209.85.254.10) 169.944 ms 12 * * * 13 * * * 14 * * * 15 * * * 16 * * * 17 * * * 18 * * * 19 * * * 20 * * * 21 * * * 22 * * * 23 * * * 24 * * * 25 * * * 26 * * * 27 * * * 28 * * * 29 * * * 30 * * * Now (12:11 eastern) [root at inetsec ~]# traceroute www.google.com traceroute to www.google.com (74.125.65.99), 30 hops max, 60 byte packets 1 gw1.armc.org (68.153.29.1) 0.760 ms 0.884 ms 0.908 ms 2 65.14.131.185 (65.14.131.185) 2.345 ms 2.342 ms 3.132 ms 3 axr01asm-7-1-0-1.bellsouth.net (65.83.237.90) 3.338 ms 3.331 ms 3.322 ms 4 axr00msy-0-3-1.bellsouth.net (65.83.236.46) 3.112 ms 3.105 ms 3.095 ms 5 65.83.238.202 (65.83.238.202) 3.503 ms 3.654 ms * 6 cr2.attga.ip.att.net (12.122.140.22) 4.489 ms 3.823 ms 3.795 ms 7 12.123.22.129 (12.123.22.129) 3.591 ms 3.094 ms 3.079 ms 8 12.88.97.6 (12.88.97.6) 3.197 ms 3.172 ms 3.160 ms 9 72.14.233.56 (72.14.233.56) 3.322 ms 3.490 ms 72.14.233.54 (72.14.233.54) 3.510 ms 10 209.85.254.249 (209.85.254.249) 16.887 ms 3.501 ms 72.14.239.127 (72.14.239.127) 4.261 ms 11 209.85.253.214 (209.85.253.214) 12.987 ms 12.979 ms 209.85.253.218 (209.85.253.218) 3.882 ms 12 gx-in-f99.google.com (74.125.65.99) 4.357 ms 4.740 ms 4.481 ms --Patrick Darden From william.mccall at gmail.com Thu May 14 11:13:01 2009 From: william.mccall at gmail.com (William McCall) Date: Thu, 14 May 2009 11:13:01 -0500 Subject: Packet Loss to Google, others In-Reply-To: References: Message-ID: Issue has cleared on VzB/UUnet From rar at syssrc.com Thu May 14 11:13:17 2009 From: rar at syssrc.com (rar) Date: Thu, 14 May 2009 12:13:17 -0400 Subject: Packet Loss to Google, others In-Reply-To: References: Message-ID: <15BDDC14871D2A49BFCEEEF409EB29830874B0DB@exchange.syssrcad.syssrc.com> We are seeing issues through our Verizon, and Level3 connections. Fine through Comcast. Our Comcast routing goes through Level 3. Bob Roswell System Source broswell at syssrc.com (410) 771-5544 ext 4336 -----Original Message----- From: Peter Beckman [mailto:beckman at angryox.com] Sent: Thursday, May 14, 2009 11:56 AM To: nanog at nanog.org Subject: Packet Loss to Google, others Anyone else getting reports of Google (and other destinations) slowness? >From Verizon FIOS Northern VA: HOST: xxx.angryox.com Loss% Snt Last Avg Best Wrst StDev 1. xxx2 0.0% 20 0.6 0.6 0.4 0.7 0.1 2. 10.1.41.89 0.0% 20 1.6 1.8 1.6 3.0 0.3 3. G2-0-3-891.WASHDC-LCR-08.ver 0.0% 20 1.6 1.7 1.6 2.0 0.1 4. so-1-1-0-0.RES-BB-RTR2.veriz 0.0% 20 2.2 2.7 2.1 7.5 1.4 5. 0.ge-5-2-0.BR2.IAD8.ALTER.NE 0.0% 20 2.9 2.9 2.7 3.1 0.1 6. 204.255.168.30 0.0% 20 6.2 9.4 6.1 70.6 14.4 7. cr2.wswdc.ip.att.net 0.0% 20 6.5 6.8 6.3 7.3 0.3 8. 12.122.134.157 0.0% 20 6.2 27.8 6.1 196.8 51.4 9. ??? 100.0 20 0.0 0.0 0.0 0.0 0.0 10. 216.239.48.108 55.0% 20 328.2 335.7 326.8 389.6 20.3 11. 64.233.175.109 50.0% 20 334.7 333.0 325.1 337.4 4.0 12. 72.14.236.74 30.0% 20 328.3 328.3 324.3 335.5 3.5 13. he-in-f147.google.com 40.0% 20 335.2 328.6 323.6 337.0 4.5 >From Cox Fiber in Northern VA / DC: HOST: xxx.angryox.com Loss% Snt Last Avg Best Wrst StDev 1. 70.164.19.3 0.0% 20 0.2 0.2 0.2 0.4 0.1 2. wsip-70-168-111-17.dc.dc.cox 0.0% 20 1.7 9.6 1.5 77.5 20.9 3. mrfddsrj01-ge706.rd.dc.cox.n 0.0% 20 13.2 3.9 1.4 18.7 5.2 4. ashbbbrj01-ae0.0.r2.as.cox.n 0.0% 20 2.5 2.7 2.3 6.4 0.9 5. 209.85.240.136 0.0% 20 39.5 10.5 3.7 63.0 15.3 6. 64.233.175.111 0.0% 20 4.9 4.7 4.1 5.9 0.4 7. 72.14.236.74 0.0% 20 6.0 6.9 6.0 8.5 0.7 8. he-in-f147.google.com 0.0% 20 4.4 4.6 4.1 7.1 0.8 >From Level3 in New York: HOST: xxx.angryox.com Loss% Snt Last Avg Best Wrst StDev 1. 208.72.185.177 0.0% 20 0.4 89.0 0.3 303.9 86.1 2. 208.72.184.245 0.0% 20 0.4 0.8 0.3 7.7 1.6 3. ge-6-7.car3.NewYork1.Level3. 0.0% 20 0.5 2.3 0.5 29.9 6.6 4. vlan69.csw1.NewYork1.Level3. 0.0% 20 4.5 6.1 0.6 14.0 4.7 5. ae-61-61.ebr1.NewYork1.Level 0.0% 20 1.6 1.0 0.7 1.6 0.2 6. ae-3-3.ebr4.Washington1.Leve 0.0% 20 11.3 10.9 5.4 19.1 4.3 7. ae-64-64.csw1.Washington1.Le 0.0% 20 14.0 10.9 5.8 18.5 4.8 8. ae-1-69.edge1.Washington1.Le 0.0% 20 6.2 9.2 5.8 60.1 12.0 9. ??? 100.0 20 0.0 0.0 0.0 0.0 0.0 10. 209.85.241.50 50.0% 20 330.9 330.3 329.1 331.6 0.9 11. 64.233.175.219 55.0% 20 316.6 314.4 311.7 317.3 2.3 12. 72.14.236.66 60.0% 20 317.4 319.6 314.1 328.0 4.5 13. he-in-f147.google.com 45.0% 20 323.9 321.5 312.1 332.9 6.9 ------------------------------------------------------------------------ --- Peter Beckman Internet Guy beckman at angryox.com http://www.angryox.com/ ------------------------------------------------------------------------ --- From frederic at placenet.org Thu May 14 11:12:56 2009 From: frederic at placenet.org (Frederic) Date: Thu, 14 May 2009 18:12:56 +0200 Subject: Packet Loss to Google, others In-Reply-To: References: Message-ID: <1242317576.3937.2.camel@kzinti.placenet.org> >From France. nothing traceroute www.google.com traceroute to www.l.google.com (74.125.39.104), 64 hops max, 40 byte packets 3 gi9-13.ccr01.par04.atlas.cogentco.com (149.6.164.177) 1 ms 1 ms 1 ms 4 te1-3.mpd02.par01.atlas.cogentco.com (130.117.2.94) 2 ms te3-3.mpd02.par01.atlas.cogentco.com (130.117.1.61) 2 ms te1-3.mpd02.par01.atlas.cogentco.com (130.117.2.94) 2 ms 5 te8-7.mpd02.lon01.atlas.cogentco.com (130.117.3.6) 10 ms te9-7.mpd02.lon01.atlas.cogentco.com (130.117.3.134) 10 ms te8-7.mpd02.lon01.atlas.cogentco.com (130.117.3.6) 10 ms 6 google.lon01.atlas.cogentco.com (130.117.14.90) 10 ms 10 ms 10 ms 7 64.233.175.27 (64.233.175.27) 10 ms (TOS=128!) 10 ms 10 ms 8 72.14.233.63 (72.14.233.63) [MPLS: Label 386194 Exp 4] 14 ms 209.85.248.80 (209.85.248.80) [MPLS: Label 605502 Exp 4] 15 ms 209.85.241.84 (209.85.241.84) [MPLS: Label 529410 Exp 4] 11 ms 9 209.85.250.141 (209.85.250.141) 17 ms 209.85.248.80 (209.85.248.80) [MPLS: Label 452895 Exp 4] 16 ms 209.85.250.141 (209.85.250.141) 19 ms 10 209.85.254.112 (209.85.254.112) 18 ms 209.85.248.44 (209.85.248.44) 16 ms 209.85.254.116 (209.85.254.116) 17 ms 11 209.85.254.126 (209.85.254.126) 18 ms 22 ms 18 ms 12 fx-in-f104.google.com (74.125.39.104) 19 ms (TOS=0!) 209.85.254.116 (209.85.254.116) 18 ms (TOS=128!) fx-in-f104.google.com (74.125.39.104) 18 ms (TOS=0!) 4 mai 2009 ? 11:55 -0400, Peter Beckman a ?crit : > Anyone else getting reports of Google (and other destinations) slowness? > > >From Verizon FIOS Northern VA: > > HOST: xxx.angryox.com Loss% Snt Last Avg Best Wrst StDev > 1. xxx2 0.0% 20 0.6 0.6 0.4 0.7 0.1 > 2. 10.1.41.89 0.0% 20 1.6 1.8 1.6 3.0 0.3 > 3. G2-0-3-891.WASHDC-LCR-08.ver 0.0% 20 1.6 1.7 1.6 2.0 0.1 > 4. so-1-1-0-0.RES-BB-RTR2.veriz 0.0% 20 2.2 2.7 2.1 7.5 1.4 > 5. 0.ge-5-2-0.BR2.IAD8.ALTER.NE 0.0% 20 2.9 2.9 2.7 3.1 0.1 > 6. 204.255.168.30 0.0% 20 6.2 9.4 6.1 70.6 14.4 > 7. cr2.wswdc.ip.att.net 0.0% 20 6.5 6.8 6.3 7.3 0.3 > 8. 12.122.134.157 0.0% 20 6.2 27.8 6.1 196.8 51.4 > 9. ??? 100.0 20 0.0 0.0 0.0 0.0 0.0 > 10. 216.239.48.108 55.0% 20 328.2 335.7 326.8 389.6 20.3 > 11. 64.233.175.109 50.0% 20 334.7 333.0 325.1 337.4 4.0 > 12. 72.14.236.74 30.0% 20 328.3 328.3 324.3 335.5 3.5 > 13. he-in-f147.google.com 40.0% 20 335.2 328.6 323.6 337.0 4.5 > > >From Cox Fiber in Northern VA / DC: > > HOST: xxx.angryox.com Loss% Snt Last Avg Best Wrst StDev > 1. 70.164.19.3 0.0% 20 0.2 0.2 0.2 0.4 0.1 > 2. wsip-70-168-111-17.dc.dc.cox 0.0% 20 1.7 9.6 1.5 77.5 20.9 > 3. mrfddsrj01-ge706.rd.dc.cox.n 0.0% 20 13.2 3.9 1.4 18.7 5.2 > 4. ashbbbrj01-ae0.0.r2.as.cox.n 0.0% 20 2.5 2.7 2.3 6.4 0.9 > 5. 209.85.240.136 0.0% 20 39.5 10.5 3.7 63.0 15.3 > 6. 64.233.175.111 0.0% 20 4.9 4.7 4.1 5.9 0.4 > 7. 72.14.236.74 0.0% 20 6.0 6.9 6.0 8.5 0.7 > 8. he-in-f147.google.com 0.0% 20 4.4 4.6 4.1 7.1 0.8 > > >From Level3 in New York: > > HOST: xxx.angryox.com Loss% Snt Last Avg Best Wrst StDev > 1. 208.72.185.177 0.0% 20 0.4 89.0 0.3 303.9 86.1 > 2. 208.72.184.245 0.0% 20 0.4 0.8 0.3 7.7 1.6 > 3. ge-6-7.car3.NewYork1.Level3. 0.0% 20 0.5 2.3 0.5 29.9 6.6 > 4. vlan69.csw1.NewYork1.Level3. 0.0% 20 4.5 6.1 0.6 14.0 4.7 > 5. ae-61-61.ebr1.NewYork1.Level 0.0% 20 1.6 1.0 0.7 1.6 0.2 > 6. ae-3-3.ebr4.Washington1.Leve 0.0% 20 11.3 10.9 5.4 19.1 4.3 > 7. ae-64-64.csw1.Washington1.Le 0.0% 20 14.0 10.9 5.8 18.5 4.8 > 8. ae-1-69.edge1.Washington1.Le 0.0% 20 6.2 9.2 5.8 60.1 12.0 > 9. ??? 100.0 20 0.0 0.0 0.0 0.0 0.0 > 10. 209.85.241.50 50.0% 20 330.9 330.3 329.1 331.6 0.9 > 11. 64.233.175.219 55.0% 20 316.6 314.4 311.7 317.3 2.3 > 12. 72.14.236.66 60.0% 20 317.4 319.6 314.1 328.0 4.5 > 13. he-in-f147.google.com 45.0% 20 323.9 321.5 312.1 332.9 6.9 > > --------------------------------------------------------------------------- > Peter Beckman Internet Guy > beckman at angryox.com http://www.angryox.com/ > --------------------------------------------------------------------------- > > From Ben.Matthew at timlradio.co.uk Thu May 14 11:14:03 2009 From: Ben.Matthew at timlradio.co.uk (Ben Matthew) Date: Thu, 14 May 2009 17:14:03 +0100 Subject: delays to google Message-ID: Yes me!! No other bugger seems to have noticed until now though. Getting similar traces to you; then it just sorts itself out after 5-10 minutes. I did think it was an issue with my LINX peering. Clearly not (from your trace). Queue the irritated: why don't you just email noc at google emails. Love & kisses, Ben Absolute Radio (AS34763) -----Original Message----- From: Steve Williams [mailto:williams at csr.utexas.edu] Sent: 14 May 2009 16:49 To: nanog at merit.edu Subject: delays to google am seeing significant delays in getting to google. anyone else seeing this? $ traceroute www.google.com traceroute: Warning: www.google.com has multiple addresses; using 74.125.53.147 traceroute to www.l.google.com (74.125.53.147), 30 hops max, 40 byte packets 1 cisco-190 (129.116.190.250) 0.430 ms 0.350 ms 0.353 ms 2 ser10-v758.gw.utexas.edu (128.83.10.29) 1.138 ms 1.099 ms 1.057 ms 3 ser2-gi1-9.gw.utexas.edu (128.83.10.2) 10.475 ms 1.174 ms 1.584 ms 4 aust-utnoc-core-ge-6-0-0-0.tx-bb.net (192.12.10.1) 1.215 ms 1.209 ms 1.134 ms 5 te2-1--570.tr01-lsanca01.transitrail.net (137.164.131.221) 40.649 ms 40.699 ms 40.678 ms 6 * * * 7 * * * 8 * * * 9 * * * 10 * * * 11 72.14.232.10 (72.14.232.10) 261.262 ms * * 12 * * pw-in-f147.google.com (74.125.53.147) 251.867 ms -- ''' (O O) ,-------------- oOO-(_)-OOo -------------, | Stephen Williams | | Manager of Computer Services | | Center for Space Research | | University of Texas at Austin | | 3925 W. Braker Ln., Suite 200 | | Austin, TX 78759-5321 | | 512.471.7235 512.471.3570 (fax) | | williams at csr.utexas.edu | |____________________ Oooo ______________| oooO ( ) ( ) ) / \ ( (_/ \_) ________________________________________________ DISCLAIMER This e-mail message, including any attachments, is intended solely for the use of the addressee and may contain confidential information. If it is not intended for you, please inform the sender and delete the e-mail and any attachments immediately. Any review, retransmission, disclosure, copying or modification of it is strictly forbidden. Please be advised that the views and opinions expressed in this e-mail may not reflect the views and opinions of TIML Radio Limited or any of its parent and subsidiary companies. Whilst we take reasonable precautions to ensure that our emails are free from viruses, we cannot be responsible for any viruses transmitted with this e-mail and recommend that you subject any incoming e-mail to your own virus checking procedures. Use of this or any other e-mail facility signifies consent to any interception we might lawfully carry out to prevent abuse of these facilities. ________________________________________________ TIML Radio Limited (trading as Absolute Radio) Registered office: One Golden Square, London. W1F 9DJ Registered in England No 02674136 VAT No 927 2572 11 From jgreco at ns.sol.net Thu May 14 11:18:09 2009 From: jgreco at ns.sol.net (Joe Greco) Date: Thu, 14 May 2009 11:18:09 -0500 (CDT) Subject: delays to google In-Reply-To: <81D582C724CA1046A279A7EE1299638B0120E3B3@FHDP1LUMXCV24.us.one.verizon.com> from "Sachs, Marcus Hans (Marc)" at May 14, 2009 11:56:57 AM Message-ID: <200905141618.n4EGI9io090681@aurora.sol.net> > We are tracking it here: http://isc.sans.org/diary.html?storyid=6388 Received some complaints about being unable to reach HP's download web site. Seems reachable but alternately nonresponsive, "Service unavailable," HP fail page, fail to resolve, etc. (h20000.www2.hp.com) Maybe related, maybe not. ... 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 felipe at cescage.edu.br Thu May 14 11:18:02 2009 From: felipe at cescage.edu.br (Felipe Costa) Date: Thu, 14 May 2009 13:18:02 -0300 Subject: RES: delays to google In-Reply-To: References: <3523d8b70905140852j45baf069w92949c2c524d599a@mail.gmail.com> Message-ID: <000001c9d4af$8ea36cd0$abea4670$@edu.br> In Brazil same thing. It's global. Felipe Costa Gestor de TI -----Mensagem original----- De: Crooks, Sam [mailto:Sam.Crooks at experian.com] Enviada em: quinta-feira, 14 de maio de 2009 12:58 Para: Mario Fernandez; Athanasios Douitsis Cc: nanog at merit.edu Assunto: RE: delays to google Also seeing this in Dallas, TX area, from AT&T and Verizon > -----Original Message----- > From: Mario Fernandez [mailto:mario at fernandez.ca] > Sent: Thursday, May 14, 2009 10:53 AM > To: Athanasios Douitsis > Cc: nanog at merit.edu > Subject: Re: delays to google > > Seeing the same thing from NY using NTT, we routed via Cogent > which does not seem to be having the problem. > > On Thu, May 14, 2009 at 11:51 AM, Athanasios Douitsis > wrote: > > > On Thu, May 14, 2009 at 6:48 PM, Steve Williams > > > >wrote: > > > > > am seeing significant delays in getting to google. anyone else > > > seeing this? > > > > > > $ traceroute www.google.com > > > traceroute: Warning: www.google.com has multiple addresses; using > > > 74.125.53.147 > > > traceroute to www.l.google.com (74.125.53.147), 30 hops > max, 40 byte > > > packets > > > 1 cisco-190 (129.116.190.250) 0.430 ms 0.350 ms 0.353 ms > > > 2 ser10-v758.gw.utexas.edu (128.83.10.29) 1.138 ms 1.099 ms > > > 1.057 ms > > > 3 ser2-gi1-9.gw.utexas.edu (128.83.10.2) 10.475 ms 1.174 ms > > > 1.584 ms > > > 4 aust-utnoc-core-ge-6-0-0-0.tx-bb.net (192.12.10.1) 1.215 ms > > > 1.209 > > ms > > > 1.134 ms > > > 5 te2-1--570.tr01-lsanca01.transitrail.net (137.164.131.221) > > > 40.649 ms > > > 40.699 ms 40.678 ms > > > 6 * * * > > > 7 * * * > > > 8 * * * > > > 9 * * * > > > 10 * * * > > > 11 72.14.232.10 (72.14.232.10) 261.262 ms * * > > > 12 * * pw-in-f147.google.com (74.125.53.147) 251.867 ms > > > > > > -- > > > > > > > > > ''' > > > (O O) > > > ,-------------- oOO-(_)-OOo -------------, > > > | Stephen Williams | > > > | Manager of Computer Services | > > > | Center for Space Research | > > > | University of Texas at Austin | > > > | 3925 W. Braker Ln., Suite 200 | > > > | Austin, TX 78759-5321 | > > > | 512.471.7235 512.471.3570 (fax) | > > > | williams at csr.utexas.edu | > > > |____________________ Oooo ______________| > > > oooO ( ) > > > ( ) ) / > > > \ ( (_/ > > > \_) > > > > > > seeing this too. > > > > > > -- > > Sent from Boston, Massachusetts, United States Yogi Berra > > - "If you ask me anything I don't know, I'm not going to answer." > __________ Information from ESET NOD32 Antivirus, version of virus signature database 4075 (20090514) __________ The message was checked by ESET NOD32 Antivirus. http://www.eset.com __________ Information from ESET NOD32 Antivirus, version of virus signature database 4075 (20090514) __________ The message was checked by ESET NOD32 Antivirus. http://www.eset.com __________ Information from ESET NOD32 Antivirus, version of virus signature database 4075 (20090514) __________ The message was checked by ESET NOD32 Antivirus. http://www.eset.com From tomb at byrneit.net Thu May 14 11:19:59 2009 From: tomb at byrneit.net (Tomas L. Byrnes) Date: Thu, 14 May 2009 09:19:59 -0700 Subject: questions about DVFS in saving energy In-Reply-To: <4A0BD1D5.60600@theangryangel.co.uk> References: <1580421295-1242253104-cardhu_decombobulator_blackberry.rim.net-1153018283-@bxe1195.bisx.prod.on.blackberry> <70D072392E56884193E3D2DE09C097A91F3EAD@pascal.zaphodb.org> <4A0BD1D5.60600@theangryangel.co.uk> Message-ID: <70D072392E56884193E3D2DE09C097A91F3EB4@pascal.zaphodb.org> Apologies for skirting close, but I think power consumption and heat dissipation are pretty big operator costs, and anything we can do to reduce those are beneficial to the bottom line; never mind the environment. More below: >-----Original Message----- >From: Karl Southern [mailto:karl at theangryangel.co.uk] >Sent: Thursday, May 14, 2009 1:10 AM >To: Tomas L. Byrnes >Cc: nanog at merit.edu >Subject: Re: questions about DVFS in saving energy > >Tomas L. Byrnes wrote: >> Basically the CPU scaling on the host makes the guest OS fall apart. >> >Apologies for the general noise (and even more apologies for stepping >outside of the nanog scope), but if it's timing related issues does >/usepmtimer not resolve this issue for the VMs? It certainly does on >other virtualisation solutions. [TLB:] We tried all the solutions we could Google, including /usepmtimer. A potential 50% reduction in power per system (which is what we were measuring in the tests) would be significant. Unfortunately, it was not stable. It appears to be a Win2K3 issue, although Red Hat Enterprise ran at the declock speed all the time, even under heavy loads (it didn't crash and corrupt volumes like Win2K3, however). From robertg at garlic.com Thu May 14 11:19:50 2009 From: robertg at garlic.com (Robert Glover) Date: Thu, 14 May 2009 09:19:50 -0700 Subject: delays to google References: <4A0C3D68.7080905@csr.utexas.edu> Message-ID: We are not experiencing any issues seeing google: [root at hermes ~]# traceroute www.google.com traceroute: Warning: www.google.com has multiple addresses; using 66.102.7.104 traceroute to www.l.google.com (66.102.7.104), 30 hops max, 38 byte packets 1 router (216.139.0.65) 0.271 ms 0.746 ms 0.986 ms 2 vl1192.na21.b003122-0.sfo01.atlas.cogentco.com (38.99.42.233) 3.142 ms 3.424 ms 4.115 ms 3 gi1-11.3503.mpd01.sfo01.atlas.cogentco.com (66.28.64.161) 4.051 ms 3.193 ms 3.374 ms 4 te9-4.mpd01.sjc01.atlas.cogentco.com (66.28.4.182) 5.106 ms 22.628 ms 4.882 ms 5 te7-2.mpd01.sjc03.atlas.cogentco.com (66.28.4.74) 5.026 ms 21.801 ms 10.957 ms 6 google.sjc03.atlas.cogentco.com (154.54.10.146) 5.204 ms 4.281 ms 4.724 ms 7 216.239.46.194 (216.239.46.194) 5.557 ms 5.157 ms 72.14.239.250 (72.14.239.250) 9.921 ms 8 72.14.238.131 (72.14.238.131) 16.955 ms 17.620 ms 216.239.43.145 (216.239.43.145) 17.566 ms 9 72.14.239.246 (72.14.239.246) 29.737 ms 29.334 ms 18.046 ms 10 mc-in-f104.google.com (66.102.7.104) 16.538 ms 17.477 ms 17.061 ms Sincerely, Bobby Glover Director of Information Services South Valley Internet (AS4307) ----- Original Message ----- From: "Steve Williams" To: Sent: Thursday, May 14, 2009 8:48 AM Subject: delays to google > am seeing significant delays in getting to google. anyone else seeing > this? > > $ traceroute www.google.com > traceroute: Warning: www.google.com has multiple addresses; using > 74.125.53.147 > traceroute to www.l.google.com (74.125.53.147), 30 hops max, 40 byte > packets > 1 cisco-190 (129.116.190.250) 0.430 ms 0.350 ms 0.353 ms > 2 ser10-v758.gw.utexas.edu (128.83.10.29) 1.138 ms 1.099 ms 1.057 ms > 3 ser2-gi1-9.gw.utexas.edu (128.83.10.2) 10.475 ms 1.174 ms 1.584 ms > 4 aust-utnoc-core-ge-6-0-0-0.tx-bb.net (192.12.10.1) 1.215 ms 1.209 ms > 1.134 ms > 5 te2-1--570.tr01-lsanca01.transitrail.net (137.164.131.221) 40.649 ms > 40.699 ms 40.678 ms > 6 * * * > 7 * * * > 8 * * * > 9 * * * > 10 * * * > 11 72.14.232.10 (72.14.232.10) 261.262 ms * * > 12 * * pw-in-f147.google.com (74.125.53.147) 251.867 ms > > -- > > > ''' > (O O) > ,-------------- oOO-(_)-OOo -------------, > | Stephen Williams | > | Manager of Computer Services | > | Center for Space Research | > | University of Texas at Austin | > | 3925 W. Braker Ln., Suite 200 | > | Austin, TX 78759-5321 | > | 512.471.7235 512.471.3570 (fax) | > | williams at csr.utexas.edu | > |____________________ Oooo ______________| > oooO ( ) > ( ) ) / > \ ( (_/ > \_) > > > > > > From llynch at civil-tongue.net Thu May 14 11:19:51 2009 From: llynch at civil-tongue.net (Lucy Lynch) Date: Thu, 14 May 2009 09:19:51 -0700 (PDT) Subject: delays to google In-Reply-To: References: <4A0C3D68.7080905@csr.utexas.edu> Message-ID: pac-nw going to Frankfurt to get to Mountain view: traceroute to 74.125.87.101 (74.125.87.101), 30 hops max, 60 byte packets 1 ext-gw.lan (192.168.11.1) 0.983 ms 1.550 ms 1.795 ms 2 73.90.28.1 (73.90.28.1) 21.859 ms 21.945 ms 22.126 ms 3 68.85.148.113 (68.85.148.113) 22.312 ms 22.767 ms 22.879 ms 4 te-9-1-ur02.eugene.or.bverton.comcast.net (68.87.216.66) 22.085 ms 22.219 ms 22.484 ms 5 te-7-3-ar01.troutdale.or.bverton.comcast.net (68.87.216.126) 23.039 ms 23.174 ms 23.435 ms 6 te-0-4-0-5-cr01.seattle.wa.ibone.comcast.net (68.86.90.237) 25.493 ms 15.267 ms 15.897 ms 7 te-3-3.car1.Seattle1.Level3.net (4.79.104.109) 25.407 ms 25.858 ms 26.565 ms 8 ae-31-51.ebr1.Seattle1.Level3.net (4.68.105.30) 29.238 ms 29.498 ms 29.620 ms 9 ae-1-100.ebr2.Seattle1.Level3.net (4.69.132.18) 27.449 ms 26.683 ms 26.826 ms 10 ae-2.ebr2.Denver1.Level3.net (4.69.132.54) 59.113 ms 58.653 ms 48.738 ms 11 ae-3.ebr1.Chicago2.Level3.net (4.69.132.62) 74.530 ms 75.094 ms 74.101 ms 12 ae-1-100.ebr2.Chicago2.Level3.net (4.69.132.114) 69.747 ms 66.950 ms 66.559 ms 13 ae-2-2.ebr2.Washington1.Level3.net (4.69.132.70) 99.648 ms 99.452 ms 98.975 ms 14 ae-44-44.ebr2.Frankfurt1.Level3.net (4.69.137.61) 190.130 ms ae-41-41.ebr2.Frankfurt1.Level3.net (4.69.137.49) 188.716 ms ae-42-42.ebr2.Frankfurt1.Level3.net (4.69.137.53) 187.548 ms 15 ae-62-62.csw1.Frankfurt1.Level3.net (4.69.140.18) 201.445 ms ae-92-92.csw4.Frankfurt1.Level3.net (4.69.140.30) 189.768 ms ae-82-82.csw3.Frankfurt1.Level3.net (4.69.140.26) 189.457 ms 16 ae-2-79.edge3.Frankfurt1.Level3.net (4.68.23.75) 189.786 ms ae-3-89.edge3.Frankfurt1.Level3.net (4.68.23.139) 188.161 ms 193.637 ms 17 212.162.24.18 (212.162.24.18) 201.646 ms 62.67.33.114 (62.67.33.114) 190.165 ms 212.162.24.14 (212.162.24.14) 188.573 ms 18 209.85.248.12 (209.85.248.12) 185.611 ms 209.85.254.108 (209.85.254.108) 189.279 ms 191.738 ms 19 72.14.236.250 (72.14.236.250) 202.201 ms 72.14.232.103 (72.14.232.103) 202.911 ms 72.14.236.250 (72.14.236.250) 202.550 ms 20 209.85.248.41 (209.85.248.41) 203.061 ms 209.85.248.39 (209.85.248.39) 200.960 ms 209.85.248.47 (209.85.248.47) 205.403 ms 21 72.14.238.105 (72.14.238.105) 207.646 ms 72.14.232.217 (72.14.232.217) 212.893 ms 72.14.238.105 (72.14.238.105) 216.114 ms 22 hb-in-f101.google.com (74.125.87.101) 207.553 ms 207.009 ms 207.673 ms - Lucy On Thu, 14 May 2009, William McCall wrote: From tomb at byrneit.net Thu May 14 11:24:32 2009 From: tomb at byrneit.net (Tomas L. Byrnes) Date: Thu, 14 May 2009 09:24:32 -0700 Subject: Packet Loss to Google, others In-Reply-To: <6C80610E-2073-49D6-B76D-0AE8B46F7572@inebraska.com> References: <6C80610E-2073-49D6-B76D-0AE8B46F7572@inebraska.com> Message-ID: <70D072392E56884193E3D2DE09C097A91F3EB5@pascal.zaphodb.org> All well from Cox in San Diego: PING googlemail.l.google.com (74.125.19.18) 56(84) bytes of data. 64 bytes from cf-in-f18.google.com (74.125.19.18): icmp_seq=0 ttl=246 time=32.9 ms 64 bytes from cf-in-f18.google.com (74.125.19.18): icmp_seq=1 ttl=246 time=33.7 ms 64 bytes from cf-in-f18.google.com (74.125.19.18): icmp_seq=2 ttl=246 time=35.7 ms 64 bytes from cf-in-f18.google.com (74.125.19.18): icmp_seq=3 ttl=246 time=36.0 ms 64 bytes from cf-in-f18.google.com (74.125.19.18): icmp_seq=4 ttl=246 time=34.8 ms 64 bytes from cf-in-f18.google.com (74.125.19.18): icmp_seq=5 ttl=246 time=31.7 ms >-----Original Message----- >From: Andy Ringsmuth [mailto:andyring at inebraska.com] >Sent: Thursday, May 14, 2009 9:02 AM >To: Peter Beckman >Cc: nanog at nanog.org >Subject: Re: Packet Loss to Google, others > >Yeah, definitely seeing it here. Gmail via POP has been dead for a >while too. This is via Unite Private Networks (via Qwest ultimately) >in Lincoln, Neb. > >Last login: Thu May 14 10:35:12 on ttys000 >204-Andy:~ andyring$ ping google.com >PING google.com (74.125.45.100): 56 data bytes >64 bytes from 74.125.45.100: icmp_seq=2 ttl=233 time=323.535 ms >64 bytes from 74.125.45.100: icmp_seq=3 ttl=233 time=339.249 ms >64 bytes from 74.125.45.100: icmp_seq=5 ttl=233 time=334.392 ms >64 bytes from 74.125.45.100: icmp_seq=6 ttl=233 time=320.491 ms >64 bytes from 74.125.45.100: icmp_seq=7 ttl=233 time=321.207 ms >64 bytes from 74.125.45.100: icmp_seq=10 ttl=233 time=320.925 ms >64 bytes from 74.125.45.100: icmp_seq=12 ttl=233 time=330.371 ms >64 bytes from 74.125.45.100: icmp_seq=16 ttl=233 time=321.174 ms >64 bytes from 74.125.45.100: icmp_seq=21 ttl=233 time=336.478 ms >64 bytes from 74.125.45.100: icmp_seq=24 ttl=233 time=326.038 ms >64 bytes from 74.125.45.100: icmp_seq=26 ttl=233 time=323.370 ms >64 bytes from 74.125.45.100: icmp_seq=27 ttl=233 time=330.263 ms >64 bytes from 74.125.45.100: icmp_seq=29 ttl=233 time=327.915 ms >64 bytes from 74.125.45.100: icmp_seq=30 ttl=233 time=333.887 ms >64 bytes from 74.125.45.100: icmp_seq=32 ttl=233 time=334.694 ms >64 bytes from 74.125.45.100: icmp_seq=33 ttl=233 time=330.924 ms >64 bytes from 74.125.45.100: icmp_seq=34 ttl=233 time=330.133 ms >64 bytes from 74.125.45.100: icmp_seq=35 ttl=233 time=333.507 ms >^C >--- google.com ping statistics --- >37 packets transmitted, 18 packets received, 51% packet loss >round-trip min/avg/max/stddev = 320.491/328.808/339.249/5.800 ms >204-Andy:~ andyring$ >204-Andy:~ andyring$ > > > >On May 14, 2009, at 10:55 AM, Peter Beckman wrote: > >> Anyone else getting reports of Google (and other destinations) >> slowness? >> >>> From Verizon FIOS Northern VA: >> >> HOST: xxx.angryox.com Loss% Snt Last Avg Best >> Wrst StDev >> 1. xxx2 0.0% 20 0.6 0.6 0.4 >> 0.7 0.1 >> 2. 10.1.41.89 0.0% 20 1.6 1.8 1.6 >> 3.0 0.3 >> 3. G2-0-3-891.WASHDC-LCR-08.ver 0.0% 20 1.6 1.7 1.6 >> 2.0 0.1 >> 4. so-1-1-0-0.RES-BB-RTR2.veriz 0.0% 20 2.2 2.7 2.1 >> 7.5 1.4 >> 5. 0.ge-5-2-0.BR2.IAD8.ALTER.NE 0.0% 20 2.9 2.9 2.7 >> 3.1 0.1 >> 6. 204.255.168.30 0.0% 20 6.2 9.4 6.1 >> 70.6 14.4 >> 7. cr2.wswdc.ip.att.net 0.0% 20 6.5 6.8 6.3 >> 7.3 0.3 >> 8. 12.122.134.157 0.0% 20 6.2 27.8 6.1 >> 196.8 51.4 >> 9. ??? 100.0 20 0.0 0.0 0.0 >> 0.0 0.0 >> 10. 216.239.48.108 55.0% 20 328.2 335.7 326.8 >> 389.6 20.3 >> 11. 64.233.175.109 50.0% 20 334.7 333.0 325.1 >> 337.4 4.0 >> 12. 72.14.236.74 30.0% 20 328.3 328.3 324.3 >> 335.5 3.5 >> 13. he-in-f147.google.com 40.0% 20 335.2 328.6 323.6 >> 337.0 4.5 >> >>> From Cox Fiber in Northern VA / DC: >> >> HOST: xxx.angryox.com Loss% Snt Last Avg Best >> Wrst StDev >> 1. 70.164.19.3 0.0% 20 0.2 0.2 0.2 >> 0.4 0.1 >> 2. wsip-70-168-111-17.dc.dc.cox 0.0% 20 1.7 9.6 1.5 >> 77.5 20.9 >> 3. mrfddsrj01-ge706.rd.dc.cox.n 0.0% 20 13.2 3.9 1.4 >> 18.7 5.2 >> 4. ashbbbrj01-ae0.0.r2.as.cox.n 0.0% 20 2.5 2.7 2.3 >> 6.4 0.9 >> 5. 209.85.240.136 0.0% 20 39.5 10.5 3.7 >> 63.0 15.3 >> 6. 64.233.175.111 0.0% 20 4.9 4.7 4.1 >> 5.9 0.4 >> 7. 72.14.236.74 0.0% 20 6.0 6.9 6.0 >> 8.5 0.7 >> 8. he-in-f147.google.com 0.0% 20 4.4 4.6 4.1 >> 7.1 0.8 >> >>> From Level3 in New York: >> >> HOST: xxx.angryox.com Loss% Snt Last Avg Best >> Wrst StDev >> 1. 208.72.185.177 0.0% 20 0.4 89.0 0.3 >> 303.9 86.1 >> 2. 208.72.184.245 0.0% 20 0.4 0.8 0.3 >> 7.7 1.6 >> 3. ge-6-7.car3.NewYork1.Level3. 0.0% 20 0.5 2.3 0.5 >> 29.9 6.6 >> 4. vlan69.csw1.NewYork1.Level3. 0.0% 20 4.5 6.1 0.6 >> 14.0 4.7 >> 5. ae-61-61.ebr1.NewYork1.Level 0.0% 20 1.6 1.0 0.7 >> 1.6 0.2 >> 6. ae-3-3.ebr4.Washington1.Leve 0.0% 20 11.3 10.9 5.4 >> 19.1 4.3 >> 7. ae-64-64.csw1.Washington1.Le 0.0% 20 14.0 10.9 5.8 >> 18.5 4.8 >> 8. ae-1-69.edge1.Washington1.Le 0.0% 20 6.2 9.2 5.8 >> 60.1 12.0 >> 9. ??? 100.0 20 0.0 0.0 0.0 >> 0.0 0.0 >> 10. 209.85.241.50 50.0% 20 330.9 330.3 329.1 >> 331.6 0.9 >> 11. 64.233.175.219 55.0% 20 316.6 314.4 311.7 >> 317.3 2.3 >> 12. 72.14.236.66 60.0% 20 317.4 319.6 314.1 >> 328.0 4.5 >> 13. he-in-f147.google.com 45.0% 20 323.9 321.5 312.1 >> 332.9 6.9 >> >> ---------------------------------------------------------------------- >----- >> Peter Beckman >> Internet Guy >> beckman at angryox.com >http://www.angryox.com/ >> ---------------------------------------------------------------------- >----- >> > From stephane.tsacas at gmail.com Thu May 14 11:27:04 2009 From: stephane.tsacas at gmail.com (Stephane Tsacas) Date: Thu, 14 May 2009 18:27:04 +0200 Subject: delays to google In-Reply-To: References: <3523d8b70905140852j45baf069w92949c2c524d599a@mail.gmail.com> Message-ID: NO problem from Iliad/Free French provider : traceroute to www.google.com (209.85.229.147), 30 hops max, 40 byte packets 1 ge-vl71.bzn-swr5.dedibox.fr (88.191.71.1) 0.426 ms 0.476 ms 0.526 ms 2 * * * 3 th2-crs16-1-be1503-p.intf.routers.proxad.net (212.27.58.45) 0.783 ms 0.774 ms 0.785 ms 4 cbv-6k-1-po21.intf.routers.proxad.net (212.27.58.2) 0.646 ms * * 5 74.125.50.117 (74.125.50.117) 0.629 ms 0.636 ms 0.654 ms 6 209.85.250.142 (209.85.250.142) 0.954 ms 0.842 ms 0.895 ms 7 216.239.43.233 (216.239.43.233) 5.950 ms 5.832 ms 5.845 ms 8 209.85.252.83 (209.85.252.83) 5.900 ms 5.915 ms 5.820 ms 9 209.85.243.73 (209.85.243.73) 13.795 ms 209.85.243.77 (209.85.243.77) 13.741 ms 209.85.243.85 (209.85.243.85) 6.123 ms 10 ww-in-f147.google.com (209.85.229.147) 6.106 ms 5.985 ms 5.982 ms St?phane From streiner at cluebyfour.org Thu May 14 11:34:03 2009 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Thu, 14 May 2009 12:34:03 -0400 (EDT) Subject: delays to google In-Reply-To: <41185.209.183.32.50.1242317076.squirrel@webmail12.pair.com> References: <41185.209.183.32.50.1242317076.squirrel@webmail12.pair.com> Message-ID: Google and gmail look fine from here (University of Pittsburgh)... no loss, ~30ms RTT, reachable through TransitRail. I'm guessing whatever the issue is has been resolved, or the storm has passed? jms On Thu, 14 May 2009, andrew at arsenaleartisans.com wrote: > Sessions time out or fail from AT&T Commercial, Verizon commercial, > Verizon FiOS, and AT&T 3G GSM, all from the East Coast. > > However, routing from a shell at pair.com: > > %traceroute mail.google.com > traceroute: Warning: mail.google.com has multiple addresses; using > 74.125.53.17 > traceroute to googlemail.l.google.com (74.125.53.17), 64 hops max, 40 byte > packets > 2 192.168.1.41 (192.168.1.41) 3.963 ms 1.456 ms 1.477 ms > 3 TenGigabitEthernet7-2.ar5.CHI1.gblx.net (207.138.112.145) 15.972 ms > 14.336 ms 14.268 ms > 4 po1-20G.ar3.CHI2.gblx.net (67.16.132.241) 14.563 ms 13.708 ms > 14.454 ms > 5 72.14.197.69 (72.14.197.69) 53.439 ms 13.862 ms 13.986 ms > 6 209.85.254.122 (209.85.254.122) 14.283 ms 14.322 ms 13.999 ms > 7 72.14.233.116 (72.14.233.116) 65.376 ms 65.557 ms 65.849 ms > 8 216.239.46.208 (216.239.46.208) 72.424 ms 72.163 ms 71.921 ms > 9 64.233.174.131 (64.233.174.131) 72.007 ms 71.711 ms > 64.233.174.129 (64.233.174.129) 71.916 ms > 10 72.14.232.6 (72.14.232.6) 82.512 ms 82.767 ms 71.942 ms > 11 pw-in-f17.google.com (74.125.53.17) 71.432 ms 71.686 ms 71.938 ms > > If I tunnel through, my connection behaves with reasonable crispness. > > Cheers, > > -Andrew > > From mikael at mtskonsult.se Thu May 14 11:35:12 2009 From: mikael at mtskonsult.se (mikael krantz) Date: Thu, 14 May 2009 18:35:12 +0200 Subject: delays to google In-Reply-To: <41185.209.183.32.50.1242317076.squirrel@webmail12.pair.com> References: <41185.209.183.32.50.1242317076.squirrel@webmail12.pair.com> Message-ID: <981075510905140935x54d26144xc636ebc08f4de786@mail.gmail.com> Works gr8 in europe from direct peers with Google: 6 72.14.198.177 (72.14.198.177) 45.648 ms 1.259 ms 1.069 ms 7 209.85.252.186 (209.85.252.186) 1.455 ms 1.350 ms 1.400 ms 8 209.85.254.153 (209.85.254.153) 20.040 ms 20.494 ms 20.226 ms 9 216.239.48.10 (216.239.48.10) 59.618 ms 35.241 ms 34.844 ms 10 72.14.232.165 (72.14.232.165) 35.193 ms 35.256 ms 72.14.232.167 (72.14.232.167) 35.508 ms 11 72.14.233.210 (72.14.233.210) 35.158 ms 39.258 ms 36.284 ms 12 fk-in-f147.google.com (209.85.129.147) 35.704 ms 35.817 ms 35.601 ms On Thu, May 14, 2009 at 6:04 PM, wrote: > Sessions time out or fail from AT&T Commercial, Verizon commercial, > Verizon FiOS, and AT&T 3G GSM, all from the East Coast. > > However, routing from a shell at pair.com: > > %traceroute mail.google.com > traceroute: Warning: mail.google.com has multiple addresses; using > 74.125.53.17 > traceroute to googlemail.l.google.com (74.125.53.17), 64 hops max, 40 byte > packets > ?2 ?192.168.1.41 (192.168.1.41) ?3.963 ms ?1.456 ms ?1.477 ms > ?3 ?TenGigabitEthernet7-2.ar5.CHI1.gblx.net (207.138.112.145) ?15.972 ms > 14.336 ms ?14.268 ms > ?4 ?po1-20G.ar3.CHI2.gblx.net (67.16.132.241) ?14.563 ms ?13.708 ms > 14.454 ms > ?5 ?72.14.197.69 (72.14.197.69) ?53.439 ms ?13.862 ms ?13.986 ms > ?6 ?209.85.254.122 (209.85.254.122) ?14.283 ms ?14.322 ms ?13.999 ms > ?7 ?72.14.233.116 (72.14.233.116) ?65.376 ms ?65.557 ms ?65.849 ms > ?8 ?216.239.46.208 (216.239.46.208) ?72.424 ms ?72.163 ms ?71.921 ms > ?9 ?64.233.174.131 (64.233.174.131) ?72.007 ms ?71.711 ms > ? ?64.233.174.129 (64.233.174.129) ?71.916 ms > 10 ?72.14.232.6 (72.14.232.6) ?82.512 ms ?82.767 ms ?71.942 ms > 11 ?pw-in-f17.google.com (74.125.53.17) ?71.432 ms ?71.686 ms ?71.938 ms > > If I tunnel through, my connection behaves with reasonable crispness. > > Cheers, > > -Andrew > > -- Mikael Krantz MTS Konsult AB Mobil: 0735-245880 From dmullins at Covad.COM Thu May 14 11:44:26 2009 From: dmullins at Covad.COM (Mullins, Douglas) Date: Thu, 14 May 2009 09:44:26 -0700 Subject: delays to google In-Reply-To: <4A0C4304.3000401@armc.org> References: <4A0C4304.3000401@armc.org> Message-ID: <3BC5D44AB71A754FAE3CA68A7597EABE15DD2330@ZANEVS03.cc-ntd1.covad.com> conficker? Doug -----Original Message----- From: Patrick Darden [mailto:darden at armc.org] Sent: Thursday, May 14, 2009 12:13 PM To: nanog at merit.edu Subject: Re: delays to google Fixed? 5 mins ago: 1 gw1.armc.org (68.153.29.1) 0.571 ms 0.705 ms 0.732 ms 2 65.14.131.185 (65.14.131.185) 2.330 ms 2.318 ms 2.308 ms 3 axr00mia-7-0-0-0.bellsouth.net (65.83.237.92) 3.009 ms 3.001 ms 3.080 ms 4 AXR00AEP-0-1-0.bellsouth.net (65.83.236.50) 2.384 ms 2.370 ms 2.499 ms 5 65.83.238.202 (65.83.238.202) 3.148 ms 3.136 ms * 6 cr1.attga.ip.att.net (12.122.141.22) 4.011 ms 3.769 ms 4.106 ms 7 12.123.22.5 (12.123.22.5) 3.735 ms 3.042 ms 3.033 ms 8 * * * 9 72.14.233.56 (72.14.233.56) 159.416 ms * * 10 72.14.232.213 (72.14.232.213) 163.622 ms 209.85.254.241 (209.85.254.241) 165.287 ms 209.85.254.243 (209.85.254.243) 219.136 ms 11 209.85.254.6 (209.85.254.6) 170.937 ms 171.154 ms 209.85.254.10 (209.85.254.10) 169.944 ms 12 * * * 13 * * * 14 * * * 15 * * * 16 * * * 17 * * * 18 * * * 19 * * * 20 * * * 21 * * * 22 * * * 23 * * * 24 * * * 25 * * * 26 * * * 27 * * * 28 * * * 29 * * * 30 * * * Now (12:11 eastern) [root at inetsec ~]# traceroute www.google.com traceroute to www.google.com (74.125.65.99), 30 hops max, 60 byte packets 1 gw1.armc.org (68.153.29.1) 0.760 ms 0.884 ms 0.908 ms 2 65.14.131.185 (65.14.131.185) 2.345 ms 2.342 ms 3.132 ms 3 axr01asm-7-1-0-1.bellsouth.net (65.83.237.90) 3.338 ms 3.331 ms 3.322 ms 4 axr00msy-0-3-1.bellsouth.net (65.83.236.46) 3.112 ms 3.105 ms 3.095 ms 5 65.83.238.202 (65.83.238.202) 3.503 ms 3.654 ms * 6 cr2.attga.ip.att.net (12.122.140.22) 4.489 ms 3.823 ms 3.795 ms 7 12.123.22.129 (12.123.22.129) 3.591 ms 3.094 ms 3.079 ms 8 12.88.97.6 (12.88.97.6) 3.197 ms 3.172 ms 3.160 ms 9 72.14.233.56 (72.14.233.56) 3.322 ms 3.490 ms 72.14.233.54 (72.14.233.54) 3.510 ms 10 209.85.254.249 (209.85.254.249) 16.887 ms 3.501 ms 72.14.239.127 (72.14.239.127) 4.261 ms 11 209.85.253.214 (209.85.253.214) 12.987 ms 12.979 ms 209.85.253.218 (209.85.253.218) 3.882 ms 12 gx-in-f99.google.com (74.125.65.99) 4.357 ms 4.740 ms 4.481 ms --Patrick Darden From eslerj at gmail.com Thu May 14 11:49:39 2009 From: eslerj at gmail.com (Joel Esler) Date: Thu, 14 May 2009 12:49:39 -0400 Subject: Packet Loss to Google, others In-Reply-To: <15BDDC14871D2A49BFCEEEF409EB29830874B0DB@exchange.syssrcad.syssrc.com> References: <15BDDC14871D2A49BFCEEEF409EB29830874B0DB@exchange.syssrcad.syssrc.com> Message-ID: <314cf0830905140949k76057c0dve1cfe5573cde4118@mail.gmail.com> We have been receiving reports for about the past hour and a half at http://isc.sans.org and via Twitter. The situation appears to be clearing up now. J On Thu, May 14, 2009 at 12:13 PM, rar wrote: > We are seeing issues through our Verizon, and Level3 connections. Fine > through Comcast. > Our Comcast routing goes through Level 3. > > Bob Roswell > System Source > broswell at syssrc.com > (410) 771-5544 ext 4336 > > > > -----Original Message----- > From: Peter Beckman [mailto:beckman at angryox.com] > Sent: Thursday, May 14, 2009 11:56 AM > To: nanog at nanog.org > Subject: Packet Loss to Google, others > > Anyone else getting reports of Google (and other destinations) slowness? > > >From Verizon FIOS Northern VA: > > HOST: xxx.angryox.com Loss% Snt Last Avg Best Wrst > StDev > 1. xxx2 0.0% 20 0.6 0.6 0.4 0.7 > 0.1 > 2. 10.1.41.89 0.0% 20 1.6 1.8 1.6 3.0 > 0.3 > 3. G2-0-3-891.WASHDC-LCR-08.ver 0.0% 20 1.6 1.7 1.6 2.0 > 0.1 > 4. so-1-1-0-0.RES-BB-RTR2.veriz 0.0% 20 2.2 2.7 2.1 7.5 > 1.4 > 5. 0.ge-5-2-0.BR2.IAD8.ALTER.NE 0.0% 20 2.9 2.9 2.7 3.1 > 0.1 > 6. 204.255.168.30 0.0% 20 6.2 9.4 6.1 70.6 > 14.4 > 7. cr2.wswdc.ip.att.net 0.0% 20 6.5 6.8 6.3 7.3 > 0.3 > 8. 12.122.134.157 0.0% 20 6.2 27.8 6.1 196.8 > 51.4 > 9. ??? 100.0 20 0.0 0.0 0.0 0.0 > 0.0 > 10. 216.239.48.108 55.0% 20 328.2 335.7 326.8 389.6 > 20.3 > 11. 64.233.175.109 50.0% 20 334.7 333.0 325.1 337.4 > 4.0 > 12. 72.14.236.74 30.0% 20 328.3 328.3 324.3 335.5 > 3.5 > 13. he-in-f147.google.com 40.0% 20 335.2 328.6 323.6 337.0 > 4.5 > > >From Cox Fiber in Northern VA / DC: > > HOST: xxx.angryox.com Loss% Snt Last Avg Best Wrst > StDev > 1. 70.164.19.3 0.0% 20 0.2 0.2 0.2 0.4 > 0.1 > 2. wsip-70-168-111-17.dc.dc.cox 0.0% 20 1.7 9.6 1.5 77.5 > 20.9 > 3. mrfddsrj01-ge706.rd.dc.cox.n 0.0% 20 13.2 3.9 1.4 18.7 > 5.2 > 4. ashbbbrj01-ae0.0.r2.as.cox.n 0.0% 20 2.5 2.7 2.3 6.4 > 0.9 > 5. 209.85.240.136 0.0% 20 39.5 10.5 3.7 63.0 > 15.3 > 6. 64.233.175.111 0.0% 20 4.9 4.7 4.1 5.9 > 0.4 > 7. 72.14.236.74 0.0% 20 6.0 6.9 6.0 8.5 > 0.7 > 8. he-in-f147.google.com 0.0% 20 4.4 4.6 4.1 7.1 > 0.8 > > >From Level3 in New York: > > HOST: xxx.angryox.com Loss% Snt Last Avg Best Wrst > StDev > 1. 208.72.185.177 0.0% 20 0.4 89.0 0.3 303.9 > 86.1 > 2. 208.72.184.245 0.0% 20 0.4 0.8 0.3 7.7 > 1.6 > 3. ge-6-7.car3.NewYork1.Level3. 0.0% 20 0.5 2.3 0.5 29.9 > 6.6 > 4. vlan69.csw1.NewYork1.Level3. 0.0% 20 4.5 6.1 0.6 14.0 > 4.7 > 5. ae-61-61.ebr1.NewYork1.Level 0.0% 20 1.6 1.0 0.7 1.6 > 0.2 > 6. ae-3-3.ebr4.Washington1.Leve 0.0% 20 11.3 10.9 5.4 19.1 > 4.3 > 7. ae-64-64.csw1.Washington1.Le 0.0% 20 14.0 10.9 5.8 18.5 > 4.8 > 8. ae-1-69.edge1.Washington1.Le 0.0% 20 6.2 9.2 5.8 60.1 > 12.0 > 9. ??? 100.0 20 0.0 0.0 0.0 0.0 > 0.0 > 10. 209.85.241.50 50.0% 20 330.9 330.3 329.1 331.6 > 0.9 > 11. 64.233.175.219 55.0% 20 316.6 314.4 311.7 317.3 > 2.3 > 12. 72.14.236.66 60.0% 20 317.4 319.6 314.1 328.0 > 4.5 > 13. he-in-f147.google.com 45.0% 20 323.9 321.5 312.1 332.9 > 6.9 > > ------------------------------------------------------------------------ > --- > Peter Beckman Internet > Guy > beckman at angryox.com > http://www.angryox.com/ > ------------------------------------------------------------------------ > --- > > > -- joel esler | Sourcefire | gtalk: jesler at sourcefire.com | 302-223-5974 | http://twitter.com/joelesler From graeme at graemef.net Thu May 14 12:16:27 2009 From: graeme at graemef.net (Graeme Fowler) Date: Thu, 14 May 2009 18:16:27 +0100 Subject: delays to google In-Reply-To: References: <41185.209.183.32.50.1242317076.squirrel@webmail12.pair.com> Message-ID: <1242321387.14125.0.camel@ernie.internal.graemef.net> On Thu, 2009-05-14 at 12:34 -0400, Justin M. Streiner wrote: > I'm guessing whatever the issue is has been resolved, or the storm has > passed? http://www.google.com/appsstatus#rm:1/di:1/do:1/ddo:0 Not that it would have been much use to you at the time. Graeme From nuno.vieira at nfsi.pt Thu May 14 12:12:33 2009 From: nuno.vieira at nfsi.pt (Nuno Vieira - nfsi telecom) Date: Thu, 14 May 2009 18:12:33 +0100 (WEST) Subject: delays to google In-Reply-To: Message-ID: <1896242051.8851242321153655.JavaMail.root@zimbra.nfsi.pt> maybe is a good time to enable IPv6 :-) We noticed issues on IPv4, but IPv6 was working perfectly (we are on Google IPv6 program)... I was able to access google all the times, as i was using IPv6 as preferred transport IPv4: traceroute to www.google.com (209.85.227.104), 30 hops max, 40 byte packets 1 ge130-1000m.cr2.lisboa.nfsi.pt (81.92.200.126) 0.159 ms 0.154 ms 0.148 ms 2 xe12-10GE.xmr1.Lisbon.as25137.net (81.92.201.10) 0.330 ms 0.408 ms 0.450 ms 3 if-3-1.core1.PV9-Lisbon.as6453.net (195.219.187.49) 0.238 ms 0.279 ms if-3-2.core1.PV9-Lisbon.as6453.net (195.219.186.9) 0.275 ms 4 if-12-0-0.mcore3.L78-London.as6453.net (195.219.144.5) 27.960 ms 27.993 ms 28.083 ms 5 if-1-0-0.mse1.LRT-London.as6453.net (195.219.144.2) 27.483 ms 27.225 ms 27.224 ms 6 if-13-0-0-3.mcore3.LDN-London.as6453.net (195.219.195.21) 34.298 ms 33.299 ms 33.242 ms 7 Vlan1254.icore1.LDN-London.as6453.net (195.219.195.90) 27.223 ms 27.219 ms 27.302 ms 8 xe-10-2-0-edge3.london1.level3.net (4.68.63.105) 27.444 ms 27.444 ms 27.437 ms 9 ae-11-51.car1.London1.Level3.net (4.69.139.66) 27.566 ms 27.673 ms ae-21-52.car1.London1.Level3.net (4.69.139.98) 27.656 ms 10 * * * 11 * * * 12 * 66.249.95.170 (66.249.95.170) 373.764 ms 72.14.232.134 (72.14.232.134) 387.434 ms 13 * * * 14 * (209.85.243.93) 403.618 ms * 15 wy-in-f104.google.com (209.85.227.104) 376.948 ms * * IPv6: traceroute to www.google.com (2001:4860:a004::68), 30 hops max, 40 byte packets 1 ge-1.Edge1.ip6.Lisbon.NFSi.pt (2001:b18::ffff) 8.656 ms 8.692 ms 8.736 ms 2 2001:5a0:1500::1 (2001:5a0:1500::1) 0.585 ms^C root at matrix:/var/log# traceroute6 www.google.com traceroute to www.google.com (2001:4860:a004::68), 30 hops max, 40 byte packets 1 ge-1.Edge1.ip6.Lisbon.NFSi.pt (2001:b18::ffff) 0.133 ms 0.212 ms 0.209 ms 2 2001:5a0:1500::1 (2001:5a0:1500::1) 0.198 ms 2001:5a0:1500::11 (2001:5a0:1500::11) 0.192 ms * 3 2001:5a0:1500::1a (2001:5a0:1500::1a) 26.925 ms * * 4 2001:5a0:c00:100::e (2001:5a0:c00:100::e) 36.672 ms * * 5 2001:5a0:200::5 (2001:5a0:200::5) 130.695 ms 130.838 ms 130.826 ms 6 pr61.ams04.net.google.com (2001:7f8:1::a501:5169:1) 42.306 ms 41.953 ms 42.176 ms 7 * * * 8 * * * 9 ww-in-x68.google.com (2001:4860:a004::68) 42.858 ms 45.349 ms 44.190 ms Those traceroutes have been taken 1 hour ago, orso, but now everything looks ok in both protocols. cheers, --- Nuno Vieira nfsi telecom, lda. nuno.vieira at nfsi.pt Tel. (+351) 21 949 2300 - Fax (+351) 21 949 2301 http://www.nfsi.pt/ From A2thaH at gmail.com Thu May 14 12:21:38 2009 From: A2thaH at gmail.com (A2thaH at gmail.com) Date: Thu, 14 May 2009 17:21:38 +0000 Subject: delays to google In-Reply-To: <3BC5D44AB71A754FAE3CA68A7597EABE15DD2330@ZANEVS03.cc-ntd1.covad.com> Message-ID: <00163641792b8a15320469e28fb9@google.com> Google ack'da maintenance on their core network did not go as planned-Forced traffic to one peer link that was unable to handle all the traffic. Maintenance has been rolled back. Issue has been restored, -Adam On May 14, 2009 12:44pm, "Mullins, Douglas" wrote: > conficker? > Doug > -----Original Message----- > From: Patrick Darden [mailto:darden at armc.org] > Sent: Thursday, May 14, 2009 12:13 PM > To: nanog at merit.edu > Subject: Re: delays to google > Fixed? > 5 mins ago: > 1 gw1.armc.org (68.153.29.1) 0.571 ms 0.705 ms 0.732 ms > 2 65.14.131.185 (65.14.131.185) 2.330 ms 2.318 ms 2.308 ms > 3 axr00mia-7-0-0-0.bellsouth.net (65.83.237.92) 3.009 ms 3.001 ms 3.080 > ms > 4 AXR00AEP-0-1-0.bellsouth.net (65.83.236.50) 2.384 ms 2.370 ms 2.499 ms > 5 65.83.238.202 (65.83.238.202) 3.148 ms 3.136 ms * > 6 cr1.attga.ip.att.net (12.122.141.22) 4.011 ms 3.769 ms 4.106 ms > 7 12.123.22.5 (12.123.22.5) 3.735 ms 3.042 ms 3.033 ms > 8 * * * > 9 72.14.233.56 (72.14.233.56) 159.416 ms * * > 10 72.14.232.213 (72.14.232.213) 163.622 ms 209.85.254.241 > (209.85.254.241) 165.287 ms 209.85.254.243 (209.85.254.243) 219.136 ms > 11 209.85.254.6 (209.85.254.6) 170.937 ms 171.154 ms 209.85.254.10 > (209.85.254.10) 169.944 ms > 12 * * * > 13 * * * > 14 * * * > 15 * * * > 16 * * * > 17 * * * > 18 * * * > 19 * * * > 20 * * * > 21 * * * > 22 * * * > 23 * * * > 24 * * * > 25 * * * > 26 * * * > 27 * * * > 28 * * * > 29 * * * > 30 * * * > Now (12:11 eastern) > [root at inetsec ~]# traceroute www.google.com > traceroute to www.google.com (74.125.65.99), 30 hops max, 60 byte > packets > 1 gw1.armc.org (68.153.29.1) 0.760 ms 0.884 ms 0.908 ms > 2 65.14.131.185 (65.14.131.185) 2.345 ms 2.342 ms 3.132 ms > 3 axr01asm-7-1-0-1.bellsouth.net (65.83.237.90) 3.338 ms 3.331 ms 3.322 > ms > 4 axr00msy-0-3-1.bellsouth.net (65.83.236.46) 3.112 ms 3.105 ms 3.095 ms > 5 65.83.238.202 (65.83.238.202) 3.503 ms 3.654 ms * > 6 cr2.attga.ip.att.net (12.122.140.22) 4.489 ms 3.823 ms 3.795 ms > 7 12.123.22.129 (12.123.22.129) 3.591 ms 3.094 ms 3.079 ms > 8 12.88.97.6 (12.88.97.6) 3.197 ms 3.172 ms 3.160 ms > 9 72.14.233.56 (72.14.233.56) 3.322 ms 3.490 ms 72.14.233.54 > (72.14.233.54) 3.510 ms > 10 209.85.254.249 (209.85.254.249) 16.887 ms 3.501 ms 72.14.239.127 > (72.14.239.127) 4.261 ms > 11 209.85.253.214 (209.85.253.214) 12.987 ms 12.979 ms 209.85.253.218 > (209.85.253.218) 3.882 ms > 12 gx-in-f99.google.com (74.125.65.99) 4.357 ms 4.740 ms 4.481 ms > --Patrick Darden From A2thaH at gmail.com Thu May 14 12:24:58 2009 From: A2thaH at gmail.com (A2thaH at gmail.com) Date: Thu, 14 May 2009 17:24:58 +0000 Subject: Packet Loss to Google, others In-Reply-To: <314cf0830905140949k76057c0dve1cfe5573cde4118@mail.gmail.com> Message-ID: <0016e64aeb4478cb7c0469e29b75@google.com> ah sent to wrong email: Resolution: Google ack'da maintenance on their core network did not go as planned-Forced traffic to one peer link that was unable to handle all the traffic. Maintenance has been rolled back. Issue has been restored AdamH On May 14, 2009 12:49pm, Joel Esler wrote: > We have been receiving reports for about the past hour and a half at > http://isc.sans.org and via Twitter. The situation appears to be clearing > up now. > J > On Thu, May 14, 2009 at 12:13 PM, rar rar at syssrc.com> wrote: > > We are seeing issues through our Verizon, and Level3 connections. Fine > > through Comcast. > > Our Comcast routing goes through Level 3. > > > > Bob Roswell > > System Source > > broswell at syssrc.com > > (410) 771-5544 ext 4336 > > > > > > > > -----Original Message----- > > From: Peter Beckman [mailto:beckman at angryox.com] > > Sent: Thursday, May 14, 2009 11:56 AM > > To: nanog at nanog.org > > Subject: Packet Loss to Google, others > > > > Anyone else getting reports of Google (and other destinations) slowness? > > > > >From Verizon FIOS Northern VA: > > > > HOST: xxx.angryox.com Loss% Snt Last Avg Best Wrst > > StDev > > 1. xxx2 0.0% 20 0.6 0.6 0.4 0.7 > > 0.1 > > 2. 10.1.41.89 0.0% 20 1.6 1.8 1.6 3.0 > > 0.3 > > 3. G2-0-3-891.WASHDC-LCR-08.ver 0.0% 20 1.6 1.7 1.6 2.0 > > 0.1 > > 4. so-1-1-0-0.RES-BB-RTR2.veriz 0.0% 20 2.2 2.7 2.1 7.5 > > 1.4 > > 5. 0.ge-5-2-0.BR2.IAD8.ALTER.NE 0.0% 20 2.9 2.9 2.7 3.1 > > 0.1 > > 6. 204.255.168.30 0.0% 20 6.2 9.4 6.1 70.6 > > 14.4 > > 7. cr2.wswdc.ip.att.net 0.0% 20 6.5 6.8 6.3 7.3 > > 0.3 > > 8. 12.122.134.157 0.0% 20 6.2 27.8 6.1 196.8 > > 51.4 > > 9. ??? 100.0 20 0.0 0.0 0.0 0.0 > > 0.0 > > 10. 216.239.48.108 55.0% 20 328.2 335.7 326.8 389.6 > > 20.3 > > 11. 64.233.175.109 50.0% 20 334.7 333.0 325.1 337.4 > > 4.0 > > 12. 72.14.236.74 30.0% 20 328.3 328.3 324.3 335.5 > > 3.5 > > 13. he-in-f147.google.com 40.0% 20 335.2 328.6 323.6 337.0 > > 4.5 > > > > >From Cox Fiber in Northern VA / DC: > > > > HOST: xxx.angryox.com Loss% Snt Last Avg Best Wrst > > StDev > > 1. 70.164.19.3 0.0% 20 0.2 0.2 0.2 0.4 > > 0.1 > > 2. wsip-70-168-111-17.dc.dc.cox 0.0% 20 1.7 9.6 1.5 77.5 > > 20.9 > > 3. mrfddsrj01-ge706.rd.dc.cox.n 0.0% 20 13.2 3.9 1.4 18.7 > > 5.2 > > 4. ashbbbrj01-ae0.0.r2.as.cox.n 0.0% 20 2.5 2.7 2.3 6.4 > > 0.9 > > 5. 209.85.240.136 0.0% 20 39.5 10.5 3.7 63.0 > > 15.3 > > 6. 64.233.175.111 0.0% 20 4.9 4.7 4.1 5.9 > > 0.4 > > 7. 72.14.236.74 0.0% 20 6.0 6.9 6.0 8.5 > > 0.7 > > 8. he-in-f147.google.com 0.0% 20 4.4 4.6 4.1 7.1 > > 0.8 > > > > >From Level3 in New York: > > > > HOST: xxx.angryox.com Loss% Snt Last Avg Best Wrst > > StDev > > 1. 208.72.185.177 0.0% 20 0.4 89.0 0.3 303.9 > > 86.1 > > 2. 208.72.184.245 0.0% 20 0.4 0.8 0.3 7.7 > > 1.6 > > 3. ge-6-7.car3.NewYork1.Level3. 0.0% 20 0.5 2.3 0.5 29.9 > > 6.6 > > 4. vlan69.csw1.NewYork1.Level3. 0.0% 20 4.5 6.1 0.6 14.0 > > 4.7 > > 5. ae-61-61.ebr1.NewYork1.Level 0.0% 20 1.6 1.0 0.7 1.6 > > 0.2 > > 6. ae-3-3.ebr4.Washington1.Leve 0.0% 20 11.3 10.9 5.4 19.1 > > 4.3 > > 7. ae-64-64.csw1.Washington1.Le 0.0% 20 14.0 10.9 5.8 18.5 > > 4.8 > > 8. ae-1-69.edge1.Washington1.Le 0.0% 20 6.2 9.2 5.8 60.1 > > 12.0 > > 9. ??? 100.0 20 0.0 0.0 0.0 0.0 > > 0.0 > > 10. 209.85.241.50 50.0% 20 330.9 330.3 329.1 331.6 > > 0.9 > > 11. 64.233.175.219 55.0% 20 316.6 314.4 311.7 317.3 > > 2.3 > > 12. 72.14.236.66 60.0% 20 317.4 319.6 314.1 328.0 > > 4.5 > > 13. he-in-f147.google.com 45.0% 20 323.9 321.5 312.1 332.9 > > 6.9 > > > > ------------------------------------------------------------------------ > > --- > > Peter Beckman Internet > > Guy > > beckman at angryox.com > > http://www.angryox.com/ > > ------------------------------------------------------------------------ > > --- > > > > > > > -- > joel esler | Sourcefire | gtalk: jesler at sourcefire.com | 302-223-5974 | > http://twitter.com/joelesler From ip at ioshints.info Thu May 14 12:29:25 2009 From: ip at ioshints.info (Ivan Pepelnjak) Date: Thu, 14 May 2009 19:29:25 +0200 Subject: Two interfaces one subnet (summary) In-Reply-To: References: <4B3726C0-20FE-4598-B4DA-44FA74FDFC71@sendmail.com><59f980d60905111440i5b4894b6hfdfe8c3a6a5777d9@mail.gmail.com><59f980d60905111704x8b5610u35d790668cf68022@mail.gmail.com><016C2E0F-7069-466D-B28F-7E48BFD6DDE4@ianai.net><59f980d60905112043v6775a81n8498f3608666c0b2@mail.gmail.com><3882E7EC-6E65-4753-8DD3-53C4A11EA54B@ianai.net> Message-ID: <002701c9d4b9$887a8960$0a00000a@nil.si> > > Anyone else want to unconfused Ben? I obviously cannot. The numerous misconceptions propagated in this thread prompted me to go through the relevant sections of RFC 1122 and write a short article on multihomed IP host issues. http://wiki.nil.com/Multihomed_IP_hosts Your contributions, either as an e-mail reply or direct wiki edit are most welcome. After the kinks have been ironed out, I'll add figures illustrating the points in the text. ** I would prefer wiki edits although I have to admit the registration is a bit of a pain and the anonymous edits are not allowed. Thanks in advance to anyone who decides to contribute :) Ivan http://www.ioshints.info/about http://blog.ioshints.info/ From eslerj at gmail.com Thu May 14 12:47:01 2009 From: eslerj at gmail.com (Joel Esler) Date: Thu, 14 May 2009 13:47:01 -0400 Subject: delays to google In-Reply-To: <00163641792b8a15320469e28fb9@google.com> References: <3BC5D44AB71A754FAE3CA68A7597EABE15DD2330@ZANEVS03.cc-ntd1.covad.com> <00163641792b8a15320469e28fb9@google.com> Message-ID: <314cf0830905141047h33165b67of177fe7129cf2a8d@mail.gmail.com> [Citation Needed] On Thu, May 14, 2009 at 1:21 PM, wrote: > Google ack'da maintenance on their core network did not go as > planned-Forced traffic to one peer link that was unable to handle all the > traffic. Maintenance has been rolled back. Issue has been restored, > > -Adam > > > On May 14, 2009 12:44pm, "Mullins, Douglas" wrote: > >> conficker? >> > > > > > > Doug >> > > > > > > > > > -----Original Message----- >> > > > From: Patrick Darden [mailto:darden at armc.org] >> > > > Sent: Thursday, May 14, 2009 12:13 PM >> > > > To: nanog at merit.edu >> > > > Subject: Re: delays to google >> > > > > > > > > > Fixed? >> > > > > > > 5 mins ago: >> > > > 1 gw1.armc.org (68.153.29.1) 0.571 ms 0.705 ms 0.732 ms >> > > > 2 65.14.131.185 (65.14.131.185) 2.330 ms 2.318 ms 2.308 ms >> > > > 3 axr00mia-7-0-0-0.bellsouth.net (65.83.237.92) 3.009 ms 3.001 ms 3.080 >> > > > ms >> > > > 4 AXR00AEP-0-1-0.bellsouth.net (65.83.236.50) 2.384 ms 2.370 ms 2.499 ms >> > > > 5 65.83.238.202 (65.83.238.202) 3.148 ms 3.136 ms * >> > > > 6 cr1.attga.ip.att.net (12.122.141.22) 4.011 ms 3.769 ms 4.106 ms >> > > > 7 12.123.22.5 (12.123.22.5) 3.735 ms 3.042 ms 3.033 ms >> > > > 8 * * * >> > > > 9 72.14.233.56 (72.14.233.56) 159.416 ms * * >> > > > 10 72.14.232.213 (72.14.232.213) 163.622 ms 209.85.254.241 >> > > > (209.85.254.241) 165.287 ms 209.85.254.243 (209.85.254.243) 219.136 ms >> > > > 11 209.85.254.6 (209.85.254.6) 170.937 ms 171.154 ms 209.85.254.10 >> > > > (209.85.254.10) 169.944 ms >> > > > 12 * * * >> > > > 13 * * * >> > > > 14 * * * >> > > > 15 * * * >> > > > 16 * * * >> > > > 17 * * * >> > > > 18 * * * >> > > > 19 * * * >> > > > 20 * * * >> > > > 21 * * * >> > > > 22 * * * >> > > > 23 * * * >> > > > 24 * * * >> > > > 25 * * * >> > > > 26 * * * >> > > > 27 * * * >> > > > 28 * * * >> > > > 29 * * * >> > > > 30 * * * >> > > > > > > > > > Now (12:11 eastern) >> > > > [root at inetsec ~]# traceroute www.google.com >> > > > traceroute to www.google.com (74.125.65.99), 30 hops max, 60 byte >> > > > packets >> > > > 1 gw1.armc.org (68.153.29.1) 0.760 ms 0.884 ms 0.908 ms >> > > > 2 65.14.131.185 (65.14.131.185) 2.345 ms 2.342 ms 3.132 ms >> > > > 3 axr01asm-7-1-0-1.bellsouth.net (65.83.237.90) 3.338 ms 3.331 ms 3.322 >> > > > ms >> > > > 4 axr00msy-0-3-1.bellsouth.net (65.83.236.46) 3.112 ms 3.105 ms 3.095 ms >> > > > 5 65.83.238.202 (65.83.238.202) 3.503 ms 3.654 ms * >> > > > 6 cr2.attga.ip.att.net (12.122.140.22) 4.489 ms 3.823 ms 3.795 ms >> > > > 7 12.123.22.129 (12.123.22.129) 3.591 ms 3.094 ms 3.079 ms >> > > > 8 12.88.97.6 (12.88.97.6) 3.197 ms 3.172 ms 3.160 ms >> > > > 9 72.14.233.56 (72.14.233.56) 3.322 ms 3.490 ms 72.14.233.54 >> > > > (72.14.233.54) 3.510 ms >> > > > 10 209.85.254.249 (209.85.254.249) 16.887 ms 3.501 ms 72.14.239.127 >> > > > (72.14.239.127) 4.261 ms >> > > > 11 209.85.253.214 (209.85.253.214) 12.987 ms 12.979 ms 209.85.253.218 >> > > > (209.85.253.218) 3.882 ms >> > > > 12 gx-in-f99.google.com (74.125.65.99) 4.357 ms 4.740 ms 4.481 ms >> > > > > > > > > > --Patrick Darden >> > > > > > > > > > > > > > -- joel esler | Sourcefire | gtalk: jesler at sourcefire.com | 302-223-5974 | http://twitter.com/joelesler From rs at seastrom.com Thu May 14 12:48:11 2009 From: rs at seastrom.com (Robert E. Seastrom) Date: Thu, 14 May 2009 13:48:11 -0400 Subject: another brick in the wall[ed garden] Message-ID: Dear Sprint EVDO people, Your man-in-the-middle hijacking of UDP/53 DNS queries against nameservers that I choose to query from my laptop on Sprint EVDO is not appreciated. Even less appreciated is your complete blocking of TCP/53 DNS queries. Queries from my lab: rs at click [14] % dig +short @192.148.252.10 version.bind. chaos txt "Just send your damn query already..." rs at click [15] % dig +tcp +short @192.148.252.10 version.bind. chaos txt "Just send your damn query already..." rs at click [16] % dig +tcp +short @192.148.252.10 hostname.bind. chaos txt "bifrost" rs at click [17] % Queries from my laptop: Superfly:~ rs$ dig +short @192.148.252.10 version.bind. chaos txt "9.6.0-P1" Superfly:~ rs$ dig +tcp +short @192.148.252.10 version.bind. chaos txt ;; connection timed out; no servers could be reached Superfly:~ rs$ dig +tcp +short @192.148.252.10 hostname.bind. chaos txt "ns1-kscymar06.spcsdns.net" Superfly:~ rs$ Guys, I send you money each month to deliver packets for me, not to invent new ways of being annoying (and breaking TSIG signed updates to dynamic DNS). Less is more. Please stop dinking with 10-minute-idle TCP sessions (which I complained about a year and a half ago) and knock it off with offering DNS service that I did not ask for. Sincerely, Your Disgruntled Customer, RS PS: No, I don't expect that this open letter will get you to fix the misbehavior, but if some Swedish guy comes along swinging a clue-bat at you guys I hope he whacks you a couple of times for me. From beckman at angryox.com Thu May 14 12:49:03 2009 From: beckman at angryox.com (Peter Beckman) Date: Thu, 14 May 2009 13:49:03 -0400 Subject: delays to google In-Reply-To: <1242321387.14125.0.camel@ernie.internal.graemef.net> References: <41185.209.183.32.50.1242317076.squirrel@webmail12.pair.com> <1242321387.14125.0.camel@ernie.internal.graemef.net> Message-ID: On Thu, 14 May 2009, Graeme Fowler wrote: > On Thu, 2009-05-14 at 12:34 -0400, Justin M. Streiner wrote: >> I'm guessing whatever the issue is has been resolved, or the storm has >> passed? > > http://www.google.com/appsstatus#rm:1/di:1/do:1/ddo:0 > > Not that it would have been much use to you at the time. It's clear the problem was not affecting a small subset of users: "We're aware of a problem with Google Mail affecting a small subset of users." If ISC has an issue open on it, and there is chatter on Nanog about it, unless they consider their userbase to be 6 billion potential users, the issue affected more than a "small subset." --------------------------------------------------------------------------- Peter Beckman Internet Guy beckman at angryox.com http://www.angryox.com/ --------------------------------------------------------------------------- From andyring at inebraska.com Thu May 14 13:18:30 2009 From: andyring at inebraska.com (Andy Ringsmuth) Date: Thu, 14 May 2009 13:18:30 -0500 Subject: delays to google In-Reply-To: <1896242051.8851242321153655.JavaMail.root@zimbra.nfsi.pt> References: <1896242051.8851242321153655.JavaMail.root@zimbra.nfsi.pt> Message-ID: <4DEA5025-A3E6-4B38-82AC-58B69E95BE25@inebraska.com> It's starting to show up in the news media as well: http://apnews.myway.com/article/20090514/D9864P900.html Google glitch disrupts search engine, e-mail -------------- next part -------------- A non-text attachment was scrubbed... Name: email_this_page_sm.gif Type: image/gif Size: 181 bytes Desc: not available URL: -------------- next part -------------- Email this Story May 14, 12:54 PM (ET) MOUNTAIN VIEW, Calif. (AP) - Technical problems at Google are preventing an unknown number of people from using its Internet search engine, e-mail and other services. In a Thursday post on its Web site, the Mountain View-based company reports that a "small subset of users" hasn't been able to get into their e-mail accounts. Without elaborating, Google says the e-mail trouble might be affecting other services as well. Multiple messages posted on Twitter, a popular information-sharing forum, indicate that people all over the world are having trouble with the Google search engine and e-mail. But other Twitter users say their Google services have been running smoothly. Google says the company is working to fix the problems. From sethm at rollernet.us Thu May 14 13:22:41 2009 From: sethm at rollernet.us (Seth Mattinen) Date: Thu, 14 May 2009 11:22:41 -0700 Subject: delays to google In-Reply-To: <4DEA5025-A3E6-4B38-82AC-58B69E95BE25@inebraska.com> References: <1896242051.8851242321153655.JavaMail.root@zimbra.nfsi.pt> <4DEA5025-A3E6-4B38-82AC-58B69E95BE25@inebraska.com> Message-ID: <4A0C6171.50503@rollernet.us> Andy Ringsmuth wrote: > It's starting to show up in the news media as well: > > http://apnews.myway.com/article/20090514/D9864P900.html > > > Google glitch disrupts search engine, e-mail > Because we let google control our fate far too much. Personally, I think this thread is more off topic than the ones that were moderated and should live on the outages mailing list. This is not operational, it's just google being broken, again. ~Seth From mpetach at netflight.com Thu May 14 13:47:46 2009 From: mpetach at netflight.com (Matthew Petach) Date: Thu, 14 May 2009 11:47:46 -0700 Subject: delays to google In-Reply-To: References: <41185.209.183.32.50.1242317076.squirrel@webmail12.pair.com> <1242321387.14125.0.camel@ernie.internal.graemef.net> Message-ID: <63ac96a50905141147w581d547cncdd47c96f226a7b@mail.gmail.com> On 5/14/09, Peter Beckman wrote: > On Thu, 14 May 2009, Graeme Fowler wrote: > > On Thu, 2009-05-14 at 12:34 -0400, Justin M. Streiner wrote: > > > I'm guessing whatever the issue is has been resolved, or the storm has > > > passed? > > > > http://www.google.com/appsstatus#rm:1/di:1/do:1/ddo:0 > > Not that it would have been much use to you at the time. > > It's clear the problem was not affecting a small subset of users: > > "We're aware of a problem with Google Mail affecting a small subset of > users." > > If ISC has an issue open on it, and there is chatter on Nanog about it, > unless they consider their userbase to be 6 billion potential users, the > issue affected more than a "small subset." Actually, only a small subset of users only know how to search on Google; everyone else realized they could use Yahoo search in the meantime. ;P *ducks and runs* From owen at delong.com Thu May 14 14:30:51 2009 From: owen at delong.com (Owen DeLong) Date: Thu, 14 May 2009 12:30:51 -0700 Subject: another brick in the wall[ed garden] In-Reply-To: References: Message-ID: <97B12E92-73F8-4347-A2B1-EBC937B5EFAF@delong.com> While you're at it, it would be nice if SPRINT also fixed the problems with ports TCP/25 and TCP/587. Another disgruntled SPRINT customer, Owen On May 14, 2009, at 10:48 AM, Robert E. Seastrom wrote: > > Dear Sprint EVDO people, > > Your man-in-the-middle hijacking of UDP/53 DNS queries against > nameservers that I choose to query from my laptop on Sprint EVDO is > not appreciated. Even less appreciated is your complete blocking of > TCP/53 DNS queries. > > Queries from my lab: > > rs at click [14] % dig +short @192.148.252.10 version.bind. chaos txt > "Just send your damn query already..." > rs at click [15] % dig +tcp +short @192.148.252.10 version.bind. > chaos txt > "Just send your damn query already..." > rs at click [16] % dig +tcp +short @192.148.252.10 hostname.bind. > chaos txt > "bifrost" > rs at click [17] % > > Queries from my laptop: > > Superfly:~ rs$ dig +short @192.148.252.10 version.bind. chaos txt > "9.6.0-P1" > Superfly:~ rs$ dig +tcp +short @192.148.252.10 version.bind. chaos > txt > ;; connection timed out; no servers could be reached > Superfly:~ rs$ dig +tcp +short @192.148.252.10 hostname.bind. > chaos txt > "ns1-kscymar06.spcsdns.net" > Superfly:~ rs$ > > Guys, I send you money each month to deliver packets for me, not to > invent new ways of being annoying (and breaking TSIG signed updates to > dynamic DNS). Less is more. Please stop dinking with 10-minute-idle > TCP sessions (which I complained about a year and a half ago) and > knock it off with offering DNS service that I did not ask for. > > Sincerely, > > Your Disgruntled Customer, RS > > PS: No, I don't expect that this open letter will get you to fix the > misbehavior, but if some Swedish guy comes along swinging a clue-bat > at you guys I hope he whacks you a couple of times for me. > From rs at seastrom.com Thu May 14 14:37:16 2009 From: rs at seastrom.com (Robert E. Seastrom) Date: Thu, 14 May 2009 15:37:16 -0400 Subject: another brick in the wall[ed garden] In-Reply-To: <97B12E92-73F8-4347-A2B1-EBC937B5EFAF@delong.com> (Owen DeLong's message of "Thu, 14 May 2009 12:30:51 -0700") References: <97B12E92-73F8-4347-A2B1-EBC937B5EFAF@delong.com> Message-ID: <86ljozh3wz.fsf@seastrom.com> Can you be more specific? My TCP/465 and TCP/587 mail submission works great over Sprint. I'm not even trying to do submission on port 25 (in fact, my mail servers send rude messages if you try AUTH to a port 25 listener) so I can't speak to that. -r Owen DeLong writes: > While you're at it, it would be nice if SPRINT also fixed the problems > with ports TCP/25 and TCP/587. > > Another disgruntled SPRINT customer, > > Owen > > On May 14, 2009, at 10:48 AM, Robert E. Seastrom wrote: > >> >> Dear Sprint EVDO people, >> >> Your man-in-the-middle hijacking of UDP/53 DNS queries against >> nameservers that I choose to query from my laptop on Sprint EVDO is >> not appreciated. Even less appreciated is your complete blocking of >> TCP/53 DNS queries. >> >> Queries from my lab: >> >> rs at click [14] % dig +short @192.148.252.10 version.bind. chaos txt >> "Just send your damn query already..." >> rs at click [15] % dig +tcp +short @192.148.252.10 version.bind. >> chaos txt >> "Just send your damn query already..." >> rs at click [16] % dig +tcp +short @192.148.252.10 hostname.bind. >> chaos txt >> "bifrost" >> rs at click [17] % >> >> Queries from my laptop: >> >> Superfly:~ rs$ dig +short @192.148.252.10 version.bind. chaos txt >> "9.6.0-P1" >> Superfly:~ rs$ dig +tcp +short @192.148.252.10 version.bind. chaos >> txt >> ;; connection timed out; no servers could be reached >> Superfly:~ rs$ dig +tcp +short @192.148.252.10 hostname.bind. >> chaos txt >> "ns1-kscymar06.spcsdns.net" >> Superfly:~ rs$ >> >> Guys, I send you money each month to deliver packets for me, not to >> invent new ways of being annoying (and breaking TSIG signed updates to >> dynamic DNS). Less is more. Please stop dinking with 10-minute-idle >> TCP sessions (which I complained about a year and a half ago) and >> knock it off with offering DNS service that I did not ask for. >> >> Sincerely, >> >> Your Disgruntled Customer, RS >> >> PS: No, I don't expect that this open letter will get you to fix the >> misbehavior, but if some Swedish guy comes along swinging a clue-bat >> at you guys I hope he whacks you a couple of times for me. >> From randy at psg.com Thu May 14 15:05:38 2009 From: randy at psg.com (Randy Bush) Date: Thu, 14 May 2009 22:05:38 +0200 Subject: delays to google In-Reply-To: References: <4A0C3D68.7080905@csr.utexas.edu> Message-ID: > going to Frankfurt to get to Mountain view: do not eat the wurst in the senator lounge randy From sethm at rollernet.us Thu May 14 15:18:30 2009 From: sethm at rollernet.us (Seth Mattinen) Date: Thu, 14 May 2009 13:18:30 -0700 Subject: another brick in the wall[ed garden] In-Reply-To: <97B12E92-73F8-4347-A2B1-EBC937B5EFAF@delong.com> References: <97B12E92-73F8-4347-A2B1-EBC937B5EFAF@delong.com> Message-ID: <4A0C7C96.104@rollernet.us> Owen DeLong wrote: > While you're at it, it would be nice if SPRINT also fixed the problems > with ports TCP/25 and TCP/587. > Never tried 25, but I know 587 is fine through a tethered handset my (extremely non-technical) significant other uses daily. Shouldn't we all be using the submission port anyway? ;) ~Seth From johnl at iecc.com Thu May 14 17:36:05 2009 From: johnl at iecc.com (John Levine) Date: 14 May 2009 22:36:05 -0000 Subject: you're not interesting, was Re: another brick in the wall[ed garden] In-Reply-To: Message-ID: <20090514223605.88104.qmail@simone.iecc.com> >Dear Sprint EVDO people, > >Your man-in-the-middle hijacking of UDP/53 DNS queries against >nameservers that I choose to query from my laptop on Sprint EVDO is >not appreciated. Even less appreciated is your complete blocking of >TCP/53 DNS queries. If I were an ISP, and I knew that approximately 99.9% of customer queries to random name servers was malware doing fake site phishing or misconfigured PCs that will work OK and avoid a support call if they answer the DNS query, with 0.1% being old weenies like us, I'd do what Sprint's doing, too. If you're aware of a mechanical way for them to tell the difference, we're all ears. Regards, John Levine, johnl at iecc.com, Primary Perpetrator of "The Internet for Dummies", Information Superhighwayman wanna-be, http://www.johnlevine.com, ex-Mayor "More Wiener schnitzel, please", said Tom, revealingly. From dave at stayonline.com Thu May 14 17:48:28 2009 From: dave at stayonline.com (Dave Larter) Date: Thu, 14 May 2009 18:48:28 -0400 Subject: you're not interesting, was Re: another brick in the wall[ed garden] In-Reply-To: <20090514223605.88104.qmail@simone.iecc.com> References: <20090514223605.88104.qmail@simone.iecc.com> Message-ID: <8B79B73777E7D544A24BEB8FC50D35DB5977BD@MERCURY.socrdu.com> I agree, running monitoring from my laptop at home at nights/weekends/vacations/holidays... I need to use most of those ports. My answer was VNP/tunnel everything. -----Original Message----- From: John Levine [mailto:johnl at iecc.com] Sent: Thursday, May 14, 2009 6:36 PM To: nanog at nanog.org Cc: rs at seastrom.com Subject: you're not interesting, was Re: another brick in the wall[ed garden] >Dear Sprint EVDO people, > >Your man-in-the-middle hijacking of UDP/53 DNS queries against >nameservers that I choose to query from my laptop on Sprint EVDO is >not appreciated. Even less appreciated is your complete blocking of >TCP/53 DNS queries. If I were an ISP, and I knew that approximately 99.9% of customer queries to random name servers was malware doing fake site phishing or misconfigured PCs that will work OK and avoid a support call if they answer the DNS query, with 0.1% being old weenies like us, I'd do what Sprint's doing, too. If you're aware of a mechanical way for them to tell the difference, we're all ears. Regards, John Levine, johnl at iecc.com, Primary Perpetrator of "The Internet for Dummies", Information Superhighwayman wanna-be, http://www.johnlevine.com, ex-Mayor "More Wiener schnitzel, please", said Tom, revealingly. From tme at americafree.tv Thu May 14 17:52:46 2009 From: tme at americafree.tv (Marshall Eubanks) Date: Thu, 14 May 2009 18:52:46 -0400 Subject: you're not interesting, was Re: another brick in the wall[ed garden] In-Reply-To: <8B79B73777E7D544A24BEB8FC50D35DB5977BD@MERCURY.socrdu.com> References: <20090514223605.88104.qmail@simone.iecc.com> <8B79B73777E7D544A24BEB8FC50D35DB5977BD@MERCURY.socrdu.com> Message-ID: <64A1B994-D08C-4DCC-BEE7-44B868819B99@americafree.tv> I use SSH tunnels for all mail, but I have had no problems with DNS over Sprint EVD0 (the OP's issue). Regards Marshall On May 14, 2009, at 6:48 PM, Dave Larter wrote: > I agree, running monitoring from my laptop at home at > nights/weekends/vacations/holidays... I need to use most of those > ports. > My answer was VNP/tunnel everything. > > -----Original Message----- > From: John Levine [mailto:johnl at iecc.com] > Sent: Thursday, May 14, 2009 6:36 PM > To: nanog at nanog.org > Cc: rs at seastrom.com > Subject: you're not interesting, was Re: another brick in the wall[ed > garden] > >> Dear Sprint EVDO people, >> >> Your man-in-the-middle hijacking of UDP/53 DNS queries against >> nameservers that I choose to query from my laptop on Sprint EVDO is >> not appreciated. Even less appreciated is your complete blocking of >> TCP/53 DNS queries. > > If I were an ISP, and I knew that approximately 99.9% of customer > queries to random name servers was malware doing fake site phishing or > misconfigured PCs that will work OK and avoid a support call if they > answer the DNS query, with 0.1% being old weenies like us, I'd do what > Sprint's doing, too. > > If you're aware of a mechanical way for them to tell the difference, > we're all ears. > > Regards, > John Levine, johnl at iecc.com, Primary Perpetrator of "The Internet for > Dummies", > Information Superhighwayman wanna-be, http://www.johnlevine.com, > ex-Mayor > "More Wiener schnitzel, please", said Tom, revealingly. > > > From Mark_Andrews at isc.org Thu May 14 18:58:32 2009 From: Mark_Andrews at isc.org (Mark Andrews) Date: Fri, 15 May 2009 09:58:32 +1000 Subject: you're not interesting, was Re: another brick in the wall[ed garden] In-Reply-To: Your message of "14 May 2009 22:36:05 GMT." <20090514223605.88104.qmail@simone.iecc.com> Message-ID: <200905142358.n4ENwWPM094667@drugs.dv.isc.org> In message <20090514223605.88104.qmail at simone.iecc.com>, John Levine writes: > >Dear Sprint EVDO people, > > > >Your man-in-the-middle hijacking of UDP/53 DNS queries against > >nameservers that I choose to query from my laptop on Sprint EVDO is > >not appreciated. Even less appreciated is your complete blocking of > >TCP/53 DNS queries. > > If I were an ISP, and I knew that approximately 99.9% of customer > queries to random name servers was malware doing fake site phishing or > misconfigured PCs that will work OK and avoid a support call if they > answer the DNS query, with 0.1% being old weenies like us, I'd do what > Sprint's doing, too. And what's the next protocol that is going to be stomped on? > If you're aware of a mechanical way for them to tell the difference, > we're all ears. Well you can't answer a TSIG message without knowing the shared secret so you might as well just let it go through and avoid some percentage of support calls. Intercepting TSIG messages is guaranteed to generate a support call. Similarly intercepting "rd=0" is also guaranteed to generate a support call. You almost certainly have a interative resolver making the query which will not handle the "aa=0" responses. Similarly there is no sane reason to block DNS/TCP other than they can do it. Mark > Regards, > John Levine, johnl at iecc.com, Primary Perpetrator of "The Internet for Dummies > ", > Information Superhighwayman wanna-be, http://www.johnlevine.com, ex-Mayor > "More Wiener schnitzel, please", said Tom, revealingly. > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews at isc.org From tomb at byrneit.net Thu May 14 19:24:26 2009 From: tomb at byrneit.net (Tomas L. Byrnes) Date: Thu, 14 May 2009 17:24:26 -0700 Subject: you're not interesting, was Re: another brick in the wall[ed garden] In-Reply-To: <200905142358.n4ENwWPM094667@drugs.dv.isc.org> References: Your message of "14 May 2009 22:36:05 GMT."<20090514223605.88104.qmail@simone.iecc.com> <200905142358.n4ENwWPM094667@drugs.dv.isc.org> Message-ID: <70D072392E56884193E3D2DE09C097A91F3EBE@pascal.zaphodb.org> Disclaimer: I have a dog in this fight, since ThreatSTOP is dependent on DNS/TCP. >-----Original Message----- >From: Mark Andrews [mailto:Mark_Andrews at isc.org] >Sent: Thursday, May 14, 2009 4:59 PM >To: John Levine >Cc: nanog at nanog.org; rs at seastrom.com >Subject: Re: you're not interesting,was Re: another brick in the wall[ed >garden] > > >In message <20090514223605.88104.qmail at simone.iecc.com>, John Levine >writes: >> >Dear Sprint EVDO people, >> > >> >Your man-in-the-middle hijacking of UDP/53 DNS queries against >> >nameservers that I choose to query from my laptop on Sprint EVDO is >> >not appreciated. Even less appreciated is your complete blocking of >> >TCP/53 DNS queries. >> >> If I were an ISP, and I knew that approximately 99.9% of customer >> queries to random name servers was malware doing fake site phishing or >> misconfigured PCs that will work OK and avoid a support call if they >> answer the DNS query, with 0.1% being old weenies like us, I'd do what >> Sprint's doing, too. > > And what's the next protocol that is going to be stomped on? > >> If you're aware of a mechanical way for them to tell the difference, >> we're all ears. > > Well you can't answer a TSIG message without knowing the > shared secret so you might as well just let it go through > and avoid some percentage of support calls. Intercepting > TSIG messages is guaranteed to generate a support call. > > Similarly intercepting "rd=0" is also guaranteed to generate > a support call. You almost certainly have a interative > resolver making the query which will not handle the "aa=0" > responses. > > Similarly there is no sane reason to block DNS/TCP other than > they can do it. > [TLB:] I can think of an argument they might make: that it is/could be used by bots as a fallback. However, redirecting DNS/UDP fits the model of "providing a better service for the average user"; blocking/redirecting TCP is more likely to break things a savvy user needs. Maybe someone with clue at Sprint can be persuaded that doing their own "OpenDNS" for UDP is probably a good thing for most uses, but doing it for TCP is a bad thing for those users who need TCP. From andre at operations.net Thu May 14 19:25:53 2009 From: andre at operations.net (Andre Gironda) Date: Thu, 14 May 2009 17:25:53 -0700 Subject: you're not interesting, was Re: another brick in the wall[ed garden] In-Reply-To: <200905142358.n4ENwWPM094667@drugs.dv.isc.org> References: <20090514223605.88104.qmail@simone.iecc.com> <200905142358.n4ENwWPM094667@drugs.dv.isc.org> Message-ID: <2fd9390e0905141725l205f81cs9c61bcaf367289a8@mail.gmail.com> On Thu, May 14, 2009 at 4:58 PM, Mark Andrews wrote: >> If I were an ISP, and I knew that approximately 99.9% of customer >> queries to random name servers was malware doing fake site phishing or >> misconfigured PCs that will work OK and avoid a support call if they >> answer the DNS query, with 0.1% being old weenies like us, I'd do what >> Sprint's doing, too. > > ? ? ? ?And what's the next protocol that is going to be stomped on? I was going to say, "will the ISP also remove the DNS MITM the day that 99.9% of malware moves its command-and-control to the HTTP or other layer?". I figured why bother - but your point drives it home even further. dre From Mark_Andrews at isc.org Thu May 14 19:37:41 2009 From: Mark_Andrews at isc.org (Mark Andrews) Date: Fri, 15 May 2009 10:37:41 +1000 Subject: you're not interesting, was Re: another brick in the wall[ed garden] In-Reply-To: Your message of "Thu, 14 May 2009 17:24:26 MST." <70D072392E56884193E3D2DE09C097A91F3EBE@pascal.zaphodb.org> Message-ID: <200905150037.n4F0bfjD095857@drugs.dv.isc.org> In message <70D072392E56884193E3D2DE09C097A91F3EBE at pascal.zaphodb.org>, "Tomas L. Byrnes" writes: > Disclaimer: I have a dog in this fight, since ThreatSTOP is dependent on > DNS/TCP. > > >-----Original Message----- > >From: Mark Andrews [mailto:Mark_Andrews at isc.org] > >Sent: Thursday, May 14, 2009 4:59 PM > >To: John Levine > >Cc: nanog at nanog.org; rs at seastrom.com > >Subject: Re: you're not interesting,was Re: another brick in the > wall[ed > >garden] > > > > > >In message <20090514223605.88104.qmail at simone.iecc.com>, John Levine > >writes: > >> >Dear Sprint EVDO people, > >> > > >> >Your man-in-the-middle hijacking of UDP/53 DNS queries against > >> >nameservers that I choose to query from my laptop on Sprint EVDO is > >> >not appreciated. Even less appreciated is your complete blocking of > >> >TCP/53 DNS queries. > >> > >> If I were an ISP, and I knew that approximately 99.9% of customer > >> queries to random name servers was malware doing fake site phishing > or > >> misconfigured PCs that will work OK and avoid a support call if they > >> answer the DNS query, with 0.1% being old weenies like us, I'd do > what > >> Sprint's doing, too. > > > > And what's the next protocol that is going to be stomped on? > > > >> If you're aware of a mechanical way for them to tell the difference, > >> we're all ears. > > > > Well you can't answer a TSIG message without knowing the > > shared secret so you might as well just let it go through > > and avoid some percentage of support calls. Intercepting > > TSIG messages is guaranteed to generate a support call. > > > > Similarly intercepting "rd=3D0" is also guaranteed to generate > > a support call. You almost certainly have a interative > > resolver making the query which will not handle the "aa=3D0" > > responses. > > > > Similarly there is no sane reason to block DNS/TCP other than > > they can do it. > > > [TLB:] I can think of an argument they might make: that it is/could be > used by bots as a fallback. However, redirecting DNS/UDP fits the model > of "providing a better service for the average user"; > blocking/redirecting TCP is more likely to break things a savvy user > needs. There is still no sane reason to block TCP. If they are intercepting DNS/UDP then they need to also intercept DNS/TCP as they will break all sites that cause "tc=1" to be set in the DNS/UDP reply. > Maybe someone with clue at Sprint can be persuaded that doing their own > "OpenDNS" for UDP is probably a good thing for most uses, but doing it > for TCP is a bad thing for those users who need TCP. You can also add to the list of queries that you need to provide a clean path for any with DO=1, CD=1 or AD=1. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews at isc.org From Skywing at valhallalegends.com Thu May 14 21:06:59 2009 From: Skywing at valhallalegends.com (Skywing) Date: Thu, 14 May 2009 21:06:59 -0500 Subject: another brick in the wall[ed garden] Message-ID: <982D8D05B6407A49AD506E6C3AC8E7D601303C4C7783@caralain.haven.nynaeve.net> You are brave indeed to trust your packets over the air without a VPN or tunnel of some sort. While it sounds like Sprint is doing something, for lack of a better word, lame, you would be well advised to not trust your packets to the built-in cell encryption (obfuscation). - S -----Original Message----- From: Robert E. Seastrom Sent: Thursday, May 14, 2009 10:50 To: nanog at nanog.org Subject: another brick in the wall[ed garden] Dear Sprint EVDO people, Your man-in-the-middle hijacking of UDP/53 DNS queries against nameservers that I choose to query from my laptop on Sprint EVDO is not appreciated. Even less appreciated is your complete blocking of TCP/53 DNS queries. Queries from my lab: rs at click [14] % dig +short @192.148.252.10 version.bind. chaos txt "Just send your damn query already..." rs at click [15] % dig +tcp +short @192.148.252.10 version.bind. chaos txt "Just send your damn query already..." rs at click [16] % dig +tcp +short @192.148.252.10 hostname.bind. chaos txt "bifrost" rs at click [17] % Queries from my laptop: Superfly:~ rs$ dig +short @192.148.252.10 version.bind. chaos txt "9.6.0-P1" Superfly:~ rs$ dig +tcp +short @192.148.252.10 version.bind. chaos txt ;; connection timed out; no servers could be reached Superfly:~ rs$ dig +tcp +short @192.148.252.10 hostname.bind. chaos txt "ns1-kscymar06.spcsdns.net" Superfly:~ rs$ Guys, I send you money each month to deliver packets for me, not to invent new ways of being annoying (and breaking TSIG signed updates to dynamic DNS). Less is more. Please stop dinking with 10-minute-idle TCP sessions (which I complained about a year and a half ago) and knock it off with offering DNS service that I did not ask for. Sincerely, Your Disgruntled Customer, RS PS: No, I don't expect that this open letter will get you to fix the misbehavior, but if some Swedish guy comes along swinging a clue-bat at you guys I hope he whacks you a couple of times for me. From morrowc.lists at gmail.com Thu May 14 21:19:37 2009 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Thu, 14 May 2009 22:19:37 -0400 Subject: install in dallas In-Reply-To: References: Message-ID: <75cb24520905141919k6212dd4h57b01556505c6203@mail.gmail.com> On Wed, May 13, 2009 at 3:22 AM, Randy Bush wrote: > we need a gsr and a few more reasonably sized devices racked and cabled > in dallas and would appreciate private email recommending a local > contractor. This is a little late, but...wkumari had setup (or started to) a while ago: that has a mailing list: Where this sort of thing might get worked out as well? -Chris From mehmet at akcin.net Thu May 14 21:29:52 2009 From: mehmet at akcin.net (Mehmet Akcin) Date: Thu, 14 May 2009 19:29:52 -0700 Subject: Managing your network devices via console Message-ID: <2909d6d90905141929n746c29c9v88b337ee4ce981c1@mail.gmail.com> Hello, It's always cool to have console access to routers/switches and nowadays they are going from RS-232 to RJ-45 as a standart. I have got Avocent DSR 2035 which is a KVM+Serial console (all in one).. but while I was able to have it work against servers via KVM or/and Serial , I was unable to make it work properly against any network device. I am wondering if anyone had experience on DSR or similar boxes to configure them against network devices console ports. Making suggestions for alternative ways of centralizing network device console management is also more than welcome, I guess the old fashioned server attached usb-serial console is one of the most preferred way, but feel free to provide if you have good ideas cheers -- Mehmet From tomb at byrneit.net Thu May 14 21:59:45 2009 From: tomb at byrneit.net (Tomas L. Byrnes) Date: Thu, 14 May 2009 19:59:45 -0700 Subject: Managing your network devices via console In-Reply-To: <2909d6d90905141929n746c29c9v88b337ee4ce981c1@mail.gmail.com> References: <2909d6d90905141929n746c29c9v88b337ee4ce981c1@mail.gmail.com> Message-ID: <70D072392E56884193E3D2DE09C097A91F3EC4@pascal.zaphodb.org> I've found Avocents to be a nightmare, and the company to be horrible to deal with. They work fine as a local console switch, but they are absurdly expensive for that use. The rest of their features are byzantine in implementation and usage, and their support and licensing policies exorbitant. Old school terminal servers and IPMI/DRAC cards work very well. >-----Original Message----- >From: Mehmet Akcin [mailto:mehmet at akcin.net] >Sent: Thursday, May 14, 2009 7:30 PM >To: nanog at nanog.org >Subject: Managing your network devices via console > >Hello, > >It's always cool to have console access to routers/switches and >nowadays they are going from RS-232 to RJ-45 as a standart. I have got >Avocent DSR 2035 which is a KVM+Serial console (all in one).. but >while I was able to have it work against servers via KVM or/and Serial >, I was unable to make it work properly against any network device. I >am wondering if anyone had experience on DSR or similar boxes to >configure them against network devices console ports. > >Making suggestions for alternative ways of centralizing network device >console management is also more than welcome, I guess the old >fashioned server attached usb-serial console is one of the most >preferred way, but feel free to provide if you have good ideas > >cheers > >-- >Mehmet From trelane at trelane.net Thu May 14 23:25:17 2009 From: trelane at trelane.net (Andrew D Kirch) Date: Fri, 15 May 2009 00:25:17 -0400 Subject: another brick in the wall[ed garden] In-Reply-To: <982D8D05B6407A49AD506E6C3AC8E7D601303C4C7783@caralain.haven.nynaeve.net> References: <982D8D05B6407A49AD506E6C3AC8E7D601303C4C7783@caralain.haven.nynaeve.net> Message-ID: <4A0CEEAD.2010407@trelane.net> Well said, if you can't build it, don't trust it. Andrew (top posted as per previous convention) Skywing wrote: > You are brave indeed to trust your packets over the air without a VPN or tunnel of some sort. > > While it sounds like Sprint is doing something, for lack of a better word, lame, you would be well advised to not trust your packets to the built-in cell encryption (obfuscation). > > - S > > -----Original Message----- > From: Robert E. Seastrom > Sent: Thursday, May 14, 2009 10:50 > To: nanog at nanog.org > Subject: another brick in the wall[ed garden] > > > Dear Sprint EVDO people, > > Your man-in-the-middle hijacking of UDP/53 DNS queries against > nameservers that I choose to query from my laptop on Sprint EVDO is > not appreciated. Even less appreciated is your complete blocking of > TCP/53 DNS queries. > > Queries from my lab: > > rs at click [14] % dig +short @192.148.252.10 version.bind. chaos txt > "Just send your damn query already..." > rs at click [15] % dig +tcp +short @192.148.252.10 version.bind. chaos txt > "Just send your damn query already..." > rs at click [16] % dig +tcp +short @192.148.252.10 hostname.bind. chaos txt > "bifrost" > rs at click [17] % > > Queries from my laptop: > > Superfly:~ rs$ dig +short @192.148.252.10 version.bind. chaos txt > "9.6.0-P1" > Superfly:~ rs$ dig +tcp +short @192.148.252.10 version.bind. chaos txt > ;; connection timed out; no servers could be reached > Superfly:~ rs$ dig +tcp +short @192.148.252.10 hostname.bind. chaos txt > "ns1-kscymar06.spcsdns.net" > Superfly:~ rs$ > > Guys, I send you money each month to deliver packets for me, not to > invent new ways of being annoying (and breaking TSIG signed updates to > dynamic DNS). Less is more. Please stop dinking with 10-minute-idle > TCP sessions (which I complained about a year and a half ago) and > knock it off with offering DNS service that I did not ask for. > > Sincerely, > > Your Disgruntled Customer, RS > > PS: No, I don't expect that this open letter will get you to fix the > misbehavior, but if some Swedish guy comes along swinging a clue-bat > at you guys I hope he whacks you a couple of times for me. > > > > From sethm at rollernet.us Fri May 15 00:02:06 2009 From: sethm at rollernet.us (Seth Mattinen) Date: Thu, 14 May 2009 22:02:06 -0700 Subject: Managing your network devices via console In-Reply-To: <70D072392E56884193E3D2DE09C097A91F3EC4@pascal.zaphodb.org> References: <2909d6d90905141929n746c29c9v88b337ee4ce981c1@mail.gmail.com> <70D072392E56884193E3D2DE09C097A91F3EC4@pascal.zaphodb.org> Message-ID: <4A0CF74E.5020204@rollernet.us> Tomas L. Byrnes wrote: > I've found Avocents to be a nightmare, and the company to be horrible to > deal with. > > They work fine as a local console switch, but they are absurdly > expensive for that use. The rest of their features are byzantine in > implementation and usage, and their support and licensing policies > exorbitant. > > Old school terminal servers and IPMI/DRAC cards work very well. > I have a PM25 that's an absolutely awesome console server. The only thing it can't do that would make it perfect is SSH. I've never been particularly impressed with the responsiveness of IPMI/SOL, but it's acceptable since it's typically only used in an emergency. ~Seth From mansaxel at besserwisser.org Fri May 15 00:07:30 2009 From: mansaxel at besserwisser.org (Mans Nilsson) Date: Fri, 15 May 2009 07:07:30 +0200 Subject: you're not interesting, was Re: another brick in the wall[ed garden] In-Reply-To: <200905142358.n4ENwWPM094667@drugs.dv.isc.org> References: <20090514223605.88104.qmail@simone.iecc.com> <200905142358.n4ENwWPM094667@drugs.dv.isc.org> Message-ID: <20090515050730.GA10725@besserwisser.org> Subject: Re: you're not interesting, was Re: another brick in the wall[ed garden] Date: Fri, May 15, 2009 at 09:58:32AM +1000 Quoting Mark Andrews (Mark_Andrews at isc.org): > And what's the next protocol that is going to be stomped on? Anything except http; at which point everything will move to http, and the firewalls are again useless. -- M?ns Nilsson From Sam.Crooks at experian.com Fri May 15 00:09:20 2009 From: Sam.Crooks at experian.com (Crooks, Sam) Date: Fri, 15 May 2009 00:09:20 -0500 Subject: Managing your network devices via console In-Reply-To: <70D072392E56884193E3D2DE09C097A91F3EC4@pascal.zaphodb.org> Message-ID: Cisco makes a 16 port Async card for ISR routers, they even bundle it with a 2811 router for fairly inexpensive $$$... Cisco2811-16TS is the partnum I think You can scale up very high or down very low for your console needs with cisco routers, and inexpensive used or obsolete routers are available for not much money. The octal cables are available with rj45's already on them, which is nice.... Email if you want a sample term server config for a 2800 router. If Cisco is not what you want... Consult the Zonker's Greater Scroll of Console Knowledge: http://www.conserver.com/consoles/ ... You may find what you are looking for there. > -----Original Message----- > From: Tomas L. Byrnes [mailto:tomb at byrneit.net] > Sent: Thursday, May 14, 2009 10:00 PM > To: Mehmet Akcin; nanog at nanog.org > Subject: RE: Managing your network devices via console > > I've found Avocents to be a nightmare, and the company to be > horrible to deal with. > > They work fine as a local console switch, but they are > absurdly expensive for that use. The rest of their features > are byzantine in implementation and usage, and their support > and licensing policies exorbitant. > > Old school terminal servers and IPMI/DRAC cards work very well. > > > >-----Original Message----- > >From: Mehmet Akcin [mailto:mehmet at akcin.net] > >Sent: Thursday, May 14, 2009 7:30 PM > >To: nanog at nanog.org > >Subject: Managing your network devices via console > > > >Hello, > > > >It's always cool to have console access to routers/switches and > >nowadays they are going from RS-232 to RJ-45 as a standart. > I have got > >Avocent DSR 2035 which is a KVM+Serial console (all in > one).. but while > >I was able to have it work against servers via KVM or/and Serial , I > >was unable to make it work properly against any network device. I am > >wondering if anyone had experience on DSR or similar boxes > to configure > >them against network devices console ports. > > > >Making suggestions for alternative ways of centralizing > network device > >console management is also more than welcome, I guess the > old fashioned > >server attached usb-serial console is one of the most preferred way, > >but feel free to provide if you have good ideas > > > >cheers > > > >-- > >Mehmet > > > From randy at psg.com Fri May 15 01:49:38 2009 From: randy at psg.com (Randy Bush) Date: Fri, 15 May 2009 08:49:38 +0200 Subject: Managing your network devices via console In-Reply-To: <2909d6d90905141929n746c29c9v88b337ee4ce981c1@mail.gmail.com> References: <2909d6d90905141929n746c29c9v88b337ee4ce981c1@mail.gmail.com> Message-ID: i'll 'fess up to still using 2511s with 3des image randy From randy at psg.com Fri May 15 01:55:35 2009 From: randy at psg.com (Randy Bush) Date: Fri, 15 May 2009 08:55:35 +0200 Subject: install in dallas In-Reply-To: <75cb24520905141919k6212dd4h57b01556505c6203@mail.gmail.com> References: <75cb24520905141919k6212dd4h57b01556505c6203@mail.gmail.com> Message-ID: > i did remember, though i have been neglectful in posting. a trusted friend recommended a really good person in the dallas area who is, thanks dick and george, underemployed. randy From bjorn at mork.no Fri May 15 03:04:37 2009 From: bjorn at mork.no (=?utf-8?Q?Bj=C3=B8rn_Mork?=) Date: Fri, 15 May 2009 10:04:37 +0200 Subject: Managing your network devices via console In-Reply-To: <2909d6d90905141929n746c29c9v88b337ee4ce981c1@mail.gmail.com> (Mehmet Akcin's message of "Thu, 14 May 2009 19:29:52 -0700") References: <2909d6d90905141929n746c29c9v88b337ee4ce981c1@mail.gmail.com> Message-ID: <87bppuyep6.fsf@nemi.mork.no> Mehmet Akcin writes: > It's always cool to have console access to routers/switches and > nowadays they are going from RS-232 to RJ-45 as a standart. I have got > Avocent DSR 2035 which is a KVM+Serial console (all in one).. but > while I was able to have it work against servers via KVM or/and Serial > , I was unable to make it work properly against any network device. I > am wondering if anyone had experience on DSR or similar boxes to > configure them against network devices console ports. I stumbled across these, which look like decent alternatives to getting a 2511 from eBay: http://www.perle.com/products/Terminal-Server.shtml The 48-port 1U terminal server with redundant power looks particularily nice. I've no experience with Perle, though. Anyone else? Bj?rn From jvargas at crypticstudios.com Fri May 15 03:25:17 2009 From: jvargas at crypticstudios.com (Jake Vargas) Date: Fri, 15 May 2009 01:25:17 -0700 Subject: Managing your network devices via console In-Reply-To: <87bppuyep6.fsf@nemi.mork.no> References: <2909d6d90905141929n746c29c9v88b337ee4ce981c1@mail.gmail.com> <87bppuyep6.fsf@nemi.mork.no> Message-ID: > I stumbled across these, which look like decent alternatives to getting > a 2511 from eBay: http://www.perle.com/products/Terminal-Server.shtml > > The 48-port 1U terminal server with redundant power looks particularily > nice. > > I've no experience with Perle, though. Anyone else? > I use them in my datacenter. SCS 32 with the IOLAN Modem card. I have some basic advice for using it as a dialup source. It also does IPSec via our DSL line which also happens to be our POTs line. All kinds of nice stuff but a bit of a pain to initially configure if you do not know what you are doing (slight learning curve). I'm happy with it. From elmi at 4ever.de Fri May 15 03:45:00 2009 From: elmi at 4ever.de (Elmar K. Bins) Date: Fri, 15 May 2009 10:45:00 +0200 Subject: Managing your network devices via console In-Reply-To: References: <2909d6d90905141929n746c29c9v88b337ee4ce981c1@mail.gmail.com> <87bppuyep6.fsf@nemi.mork.no> Message-ID: <20090515084459.GP29526@ronin.4ever.de> jvargas at crypticstudios.com (Jake Vargas) wrote: > > I stumbled across these, which look like decent alternatives to getting > > a 2511 from eBay: http://www.perle.com/products/Terminal-Server.shtml > > > > The 48-port 1U terminal server with redundant power looks particularily > > nice. > > > > I've no experience with Perle, though. Anyone else? > > > > I use them in my datacenter. SCS 32 with the IOLAN Modem card. I have some basic advice for using it as a dialup source. It also does IPSec via our DSL line which also happens to be our POTs line. All kinds of nice stuff but a bit of a pain to initially configure if you do not know what you are doing (slight learning curve). I'm happy with it. We are still using the "ancient" Cyclades/Avocent ACS'es with a matching modem card (getting rare, them). They work fine, a bit slow on sshV2, but no problems in all the remote locations. I had one (pretty old) fail in the lab, but this might have been due to it being quite warm there... I am concerned about remote power control, though. If you know your datacenter, you can get all kinds of remote-controlled power strips. With us, we don't always know beforehand what kind of power the DCs will have, and I'd like the exact same equipment everywhere (except the cables, of course). In order to achieve this, I used Cyclades (now Avocent) ATP3120-001 (20A at 100-240V input on IEC C320-20, 10A outputs on IEC C320-13). They have three shortcomings: - sometimes they forget their configuration (not critical) - they can only be accessed by serial console (no SNMP etc.) - consequently there's no power meter remote readout Is anyone here aware of such universally usable devices that can be accessed over IP and give power readouts remotely? Electrical specs are as above - 20 Amps input (for 120V countries), usable anywhere from 100-240 Volts and IEC input and output plugs... Any hints? (No, APC fails in the 100-240V part) (No, Perle fails in the 100-240V and the IEC part) (No, even Avocent's other strips fail there...) Yours, Elmi. -- "Hinken ist kein Mangel eines Vergleichs, sondern sollte als wesentliche Eigenschaft von Vergleichen angesehen werden." (Marius Fr?nzel in desd) --------------------------------------------------------------[ ELMI-RIPE ]--- From johnl at iecc.com Fri May 15 04:10:26 2009 From: johnl at iecc.com (John R. Levine) Date: Fri, 15 May 2009 10:10:26 +0100 (BST) Subject: you're not interesting, was Re: another brick in the wall[ed garden] In-Reply-To: <20090515050730.GA10725@besserwisser.org> References: <20090514223605.88104.qmail@simone.iecc.com> <200905142358.n4ENwWPM094667@drugs.dv.isc.org> <20090515050730.GA10725@besserwisser.org> Message-ID: >> And what's the next protocol that is going to be stomped on? > > Anything except http; at which point everything will move to http, and > the firewalls are again useless. Um, if you think that http on consumer networks is transparent, I have some really bad news for you. Regards, John Levine, johnl at iecc.com, Primary Perpetrator of "The Internet for Dummies", Information Superhighwayman wanna-be, http://www.johnlevine.com, ex-Mayor "More Wiener schnitzel, please", said Tom, revealingly. From mansaxel at besserwisser.org Fri May 15 04:28:01 2009 From: mansaxel at besserwisser.org (Mans Nilsson) Date: Fri, 15 May 2009 09:28:01 +0000 (UTC) Subject: you're not interesting, was Re: another brick in the wall[ed garden] In-Reply-To: <200905142358.n4ENwWPM094667@drugs.dv.isc.org> References: <20090514223605.88104.qmail@simone.iecc.com> <200905142358.n4ENwWPM094667@drugs.dv.isc.org> Message-ID: <20090515050730.GA10725@besserwisser.org> Subject: Re: you're not interesting, was Re: another brick in the wall[ed garden] Date: Fri, May 15, 2009 at 09:58:32AM +1000 Quoting Mark Andrews (Mark_Andrews at isc.org): > And what's the next protocol that is going to be stomped on? Anything except http; at which point everything will move to http, and the firewalls are again useless. -- M?ns Nilsson From martin at theicelandguy.com Fri May 15 04:28:01 2009 From: martin at theicelandguy.com (Martin Hannigan) Date: Fri, 15 May 2009 09:28:01 +0000 (UTC) Subject: you're not interesting, was Re: another brick in the wall[ed garden] In-Reply-To: <200905142358.n4ENwWPM094667@drugs.dv.isc.org> References: <20090514223605.88104.qmail@simone.iecc.com> <200905142358.n4ENwWPM094667@drugs.dv.isc.org> Message-ID: Anything traversing the edge. They are all revenue targets. Best, Martin On 5/14/09, Mark Andrews wrote: > > In message <20090514223605.88104.qmail at simone.iecc.com>, John Levine writes: >> >Dear Sprint EVDO people, >> > >> >Your man-in-the-middle hijacking of UDP/53 DNS queries against >> >nameservers that I choose to query from my laptop on Sprint EVDO is >> >not appreciated. Even less appreciated is your complete blocking of >> >TCP/53 DNS queries. >> >> If I were an ISP, and I knew that approximately 99.9% of customer >> queries to random name servers was malware doing fake site phishing or >> misconfigured PCs that will work OK and avoid a support call if they >> answer the DNS query, with 0.1% being old weenies like us, I'd do what >> Sprint's doing, too. > > And what's the next protocol that is going to be stomped on? > >> If you're aware of a mechanical way for them to tell the difference, >> we're all ears. > > Well you can't answer a TSIG message without knowing the > shared secret so you might as well just let it go through > and avoid some percentage of support calls. Intercepting > TSIG messages is guaranteed to generate a support call. > > Similarly intercepting "rd=0" is also guaranteed to generate > a support call. You almost certainly have a interative > resolver making the query which will not handle the "aa=0" > responses. > > Similarly there is no sane reason to block DNS/TCP other than > they can do it. > > Mark > >> Regards, >> John Levine, johnl at iecc.com, Primary Perpetrator of "The Internet for >> Dummies >> ", >> Information Superhighwayman wanna-be, http://www.johnlevine.com, ex-Mayor >> "More Wiener schnitzel, please", said Tom, revealingly. >> > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews at isc.org > > -- Martin Hannigan martin at theicelandguy.com p: +16178216079 Power, Network, and Costs Consulting for Iceland Datacenters and Occupants From cidr-report at potaroo.net Fri May 15 07:00:24 2009 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 15 May 2009 22:00:24 +1000 (EST) Subject: BGP Update Report Message-ID: <200905151200.n4FC0OTb007904@wattle.apnic.net> BGP Update Report Interval: 13-Apr-09 -to- 14-May-09 (32 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS3130 136562 2.3% 529.3 -- RGNET-3130 RGnet/PSGnet 2 - AS8452 69624 1.2% 51.7 -- TEDATA TEDATA 3 - AS21491 55630 0.9% 1794.5 -- UTL-ON-LINE UTL On-line is RF broadband ISP in Uganda - Africa 4 - AS6389 53858 0.9% 12.4 -- BELLSOUTH-NET-BLK - BellSouth.net Inc. 5 - AS35805 52417 0.9% 151.9 -- UTG-AS United Telecom AS 6 - AS4323 43501 0.7% 10.0 -- TWTC - tw telecom holdings, inc. 7 - AS29049 42441 0.7% 131.4 -- DELTA-TELECOM-AS Delta Telecom LTD. 8 - AS33776 42032 0.7% 359.2 -- STARCOMMS-ASN 9 - AS12978 34819 0.6% 179.5 -- DOGAN-ONLINE Dogan Iletisim Elektronik Servis Hizmetleri AS 10 - AS8151 34764 0.6% 23.8 -- Uninet S.A. de C.V. 11 - AS10834 34577 0.6% 13.7 -- Telefonica Data Argentina S.A. 12 - AS17488 31858 0.5% 20.0 -- HATHWAY-NET-AP Hathway IP Over Cable Internet 13 - AS17974 31205 0.5% 30.0 -- TELKOMNET-AS2-AP PT Telekomunikasi Indonesia 14 - AS5056 30480 0.5% 258.3 -- INS-NET-2 - Iowa Network Services 15 - AS22773 28935 0.5% 26.9 -- ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 16 - AS15045 28715 0.5% 7178.8 -- KITTELSON - KITTELSON AND ASSOCIATES, INC. 17 - AS8386 27730 0.5% 229.2 -- KOCNET KOCNET-AS 18 - AS20115 27684 0.5% 16.4 -- CHARTER-NET-HKY-NC - Charter Communications 19 - AS4249 26475 0.5% 146.3 -- LILLY-AS - Eli Lilly and Company 20 - AS2920 26420 0.5% 322.2 -- LACOE - Los Angeles County Office of Education TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS15045 28715 0.5% 7178.8 -- KITTELSON - KITTELSON AND ASSOCIATES, INC. 2 - AS40967 4218 0.1% 4218.0 -- CSF-AS CSF Computersoftware fuer Fachanwendungen GmbH 3 - AS32398 21155 0.4% 3525.8 -- REALNET-ASN-1 4 - AS13325 24488 0.4% 3061.0 -- STOMI - State of Michigan, DMB-CNOC 5 - AS46653 8276 0.1% 2758.7 -- FREDRIKSON---BYRON - Fredrikson & Byron, P.A. 6 - AS28256 2679 0.1% 2679.0 -- 7 - AS13153 2546 0.0% 2546.0 -- ONEWORLD OneWorld S.A. 8 - AS29229 2449 0.0% 2449.0 -- ASDA-AS Assotiation for the Development of West Athens 9 - AS8499 2167 0.0% 2167.0 -- Space Hellas Network Operation Center (NOC) 10 - AS30423 4070 0.1% 2035.0 -- AMEDI-3-ASN1 - Amedisys, Inc. 11 - AS47640 5763 0.1% 1921.0 -- TRICOMPAS Tricomp Sp. z. o. o. 12 - AS5050 25422 0.4% 1815.9 -- PSC-EXT - Pittsburgh Supercomputing Center 13 - AS21491 55630 0.9% 1794.5 -- UTL-ON-LINE UTL On-line is RF broadband ISP in Uganda - Africa 14 - AS46328 14241 0.2% 1582.3 -- PTCNEBRASKA - PIERCE TELEPHONE COMPANY, INCORPORATED 15 - AS39803 2818 0.1% 1409.0 -- UTI-AS SC UTI COMMUNICATIONS SYSTEMS SRL 16 - AS28953 2324 0.0% 1162.0 -- PIRAEUSBANK Greek banking institution 17 - AS16931 3354 0.1% 1118.0 -- GLOBAL-PAYMENTS-1 - Global Payments, Inc. 18 - AS24994 2216 0.0% 1108.0 -- GENESYS-AS GENESYS Informatica AS for announcing own prefixes 19 - AS47299 1077 0.0% 1077.0 -- DRSA-AS Dlugie Rozmowy S.A. 20 - AS35400 5382 0.1% 1076.4 -- MFIST Interregoinal Organization Network Technologies TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 72.23.246.0/24 24993 0.4% AS5050 -- PSC-EXT - Pittsburgh Supercomputing Center 2 - 41.204.2.0/24 21102 0.3% AS32398 -- REALNET-ASN-1 3 - 192.12.120.0/24 10327 0.2% AS5691 -- MITRE-AS-5 - The MITRE Corporation 4 - 63.103.104.0/22 9978 0.2% AS15045 -- KITTELSON - KITTELSON AND ASSOCIATES, INC. 5 - 63.103.108.0/23 9978 0.2% AS15045 -- KITTELSON - KITTELSON AND ASSOCIATES, INC. 6 - 63.103.110.0/24 8745 0.1% AS15045 -- KITTELSON - KITTELSON AND ASSOCIATES, INC. 7 - 199.45.13.0/24 8261 0.1% AS46653 -- FREDRIKSON---BYRON - Fredrikson & Byron, P.A. 8 - 123.49.152.0/24 7723 0.1% AS18118 -- CITICNET-AP CITIC Networks Management Co.,Ltd. 9 - 123.49.144.0/21 6918 0.1% AS18118 -- CITICNET-AP CITIC Networks Management Co.,Ltd. 10 - 195.96.69.0/24 6749 0.1% AS8225 -- ASTELIT-MSK-AS Astelit Autonomous System 11 - 81.199.18.0/24 5772 0.1% AS21491 -- UTL-ON-LINE UTL On-line is RF broadband ISP in Uganda - Africa 12 - 193.201.184.0/21 5769 0.1% AS25546 -- BROOKLANDCOMP-AS Brookland Computer Services 13 - 94.124.16.0/21 5697 0.1% AS47640 -- TRICOMPAS Tricomp Sp. z. o. o. 14 - 81.199.23.0/24 5429 0.1% AS21491 -- UTL-ON-LINE UTL On-line is RF broadband ISP in Uganda - Africa 15 - 81.199.16.0/22 5401 0.1% AS21491 -- UTL-ON-LINE UTL On-line is RF broadband ISP in Uganda - Africa 16 - 196.0.0.0/16 5400 0.1% AS21491 -- UTL-ON-LINE UTL On-line is RF broadband ISP in Uganda - Africa 17 - 81.199.22.0/24 5372 0.1% AS21491 -- UTL-ON-LINE UTL On-line is RF broadband ISP in Uganda - Africa 18 - 81.199.28.0/22 5344 0.1% AS21491 -- UTL-ON-LINE UTL On-line is RF broadband ISP in Uganda - Africa 19 - 81.199.21.0/24 5331 0.1% AS21491 -- UTL-ON-LINE UTL On-line is RF broadband ISP in Uganda - Africa 20 - 81.199.20.0/24 5229 0.1% AS21491 -- UTL-ON-LINE UTL On-line is RF broadband ISP in Uganda - Africa Details at http://bgpupdates.potaroo.net ------------------------------------ Copies of this report are mailed to: nanog at merit.edu eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From cidr-report at potaroo.net Fri May 15 07:00:03 2009 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 15 May 2009 22:00:03 +1000 (EST) Subject: The Cidr Report Message-ID: <200905151200.n4FC03a1007889@wattle.apnic.net> This report has been generated at Fri May 15 21:17:19 2009 AEST. The report analyses the BGP Routing Table of AS2.0 router and generates a report on aggregation potential within the table. Check http://www.cidr-report.org for a current version of this report. Recent Table History Date Prefixes CIDR Agg 08-05-09 294143 182447 09-05-09 293901 181869 10-05-09 294234 182075 11-05-09 294208 183286 12-05-09 294500 183655 13-05-09 294535 183928 14-05-09 294756 183893 15-05-09 294616 184092 AS Summary 31334 Number of ASes in routing system 13335 Number of ASes announcing only one prefix 4296 Largest number of prefixes announced by an AS AS6389 : BELLSOUTH-NET-BLK - BellSouth.net Inc. 89741824 Largest address span announced by an AS (/32s) AS27064: DDN-ASNBLK1 - DoD Network Information Center Aggregation Summary The algorithm used in this report proposes aggregation only when there is a precise match using the AS path, so as to preserve traffic transit policies. Aggregation is also proposed across non-advertised address space ('holes'). --- 15May09 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 294546 184073 110473 37.5% All ASes AS6389 4296 339 3957 92.1% BELLSOUTH-NET-BLK - BellSouth.net Inc. AS4323 4270 1765 2505 58.7% TWTC - tw telecom holdings, inc. AS209 2562 1150 1412 55.1% ASN-QWEST - Qwest Communications Corporation AS4766 1805 522 1283 71.1% KIXS-AS-KR Korea Telecom AS17488 1584 301 1283 81.0% HATHWAY-NET-AP Hathway IP Over Cable Internet AS4755 1247 150 1097 88.0% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP AS22773 1063 68 995 93.6% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. AS1785 1759 796 963 54.7% AS-PAETEC-NET - PaeTec Communications, Inc. AS8452 1200 303 897 74.8% TEDATA TEDATA AS8151 1449 598 851 58.7% Uninet S.A. de C.V. AS19262 996 236 760 76.3% VZGNI-TRANSIT - Verizon Internet Services Inc. AS18566 1062 424 638 60.1% COVAD - Covad Communications Co. AS6478 1404 811 593 42.2% ATT-INTERNET3 - AT&T WorldNet Services AS18101 754 169 585 77.6% RIL-IDC Reliance Infocom Ltd Internet Data Centre, AS11492 1099 549 550 50.0% CABLEONE - CABLE ONE, INC. AS855 621 101 520 83.7% CANET-ASN-4 - Bell Aliant Regional Communications, Inc. AS22047 610 98 512 83.9% VTR BANDA ANCHA S.A. AS2706 536 44 492 91.8% HKSUPER-HK-AP Pacific Internet (Hong Kong) Limited AS17676 565 81 484 85.7% GIGAINFRA BB TECHNOLOGY Corp. AS17908 616 141 475 77.1% TCISL Tata Communications AS4804 574 105 469 81.7% MPX-AS Microplex PTY LTD AS7018 1491 1026 465 31.2% ATT-INTERNET4 - AT&T WorldNet Services AS4808 629 168 461 73.3% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network AS24560 689 249 440 63.9% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services AS7545 787 363 424 53.9% TPG-INTERNET-AP TPG Internet Pty Ltd AS9443 527 103 424 80.5% INTERNETPRIMUS-AS-AP Primus Telecommunications AS6517 660 242 418 63.3% RELIANCEGLOBALCOM - Reliance Globalcom Services, Inc AS7011 963 553 410 42.6% FRONTIER-AND-CITIZENS - Frontier Communications of America, Inc. AS4668 688 282 406 59.0% LGNET-AS-KR LG CNS AS5668 772 376 396 51.3% AS-5668 - CenturyTel Internet Holdings, Inc. Total 37278 12113 25165 67.5% Top 30 total Possible Bogus Routes 24.245.128.0/17 AS11492 CABLEONE - CABLE ONE, INC. 24.246.0.0/17 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 24.246.128.0/18 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 41.223.112.0/22 AS5713 SAIX-NET 41.223.176.0/22 AS36981 41.223.188.0/24 AS22351 INTELSAT Intelsat Global BGP Routing Policy 41.223.189.0/24 AS26452 BRING-AS - BringCom, Inc. 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV - Wireless Broadband via Satellite 62.61.221.0/24 AS24974 TACHYON-EU Tachyon Europe BV - Wireless Broadband via Satellite 63.140.213.0/24 AS22555 UTC - Universal Talkware Corporation 63.143.251.0/24 AS22555 UTC - Universal Talkware Corporation 64.31.32.0/19 AS11955 SCRR-11955 - Road Runner HoldCo LLC 64.31.59.0/24 AS7017 SCRR-7015 - Road Runner HoldCo LLC 64.31.60.0/24 AS7017 SCRR-7015 - Road Runner HoldCo LLC 64.79.88.0/24 AS26096 LODDEN - Lodden Services 64.79.89.0/24 AS26096 LODDEN - Lodden Services 66.11.32.0/20 AS6261 VISINET - Visionary Systems, Inc. 66.11.40.0/21 AS6261 VISINET - Visionary Systems, Inc. 66.54.91.0/24 AS30506 BLACKSUN-1 - Blacksun Technologies LLC 66.55.160.0/19 AS29994 66.128.38.0/24 AS15246 Telecomunicaciones Satelitales TelesatS.A. 66.180.239.0/24 AS35888 VIGNETTE - VIGNETTE CORPORATION 66.206.32.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.33.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.34.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.35.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.40.0/22 AS174 COGENT Cogent/PSI 66.206.44.0/23 AS174 COGENT Cogent/PSI 66.206.47.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 66.207.32.0/20 AS23011 66.245.176.0/20 AS19318 NJIIX-AS-1 - NEW JERSEY INTERNATIONAL INTERNET EXCHANGE LLC 69.6.80.0/24 AS13442 69.6.81.0/24 AS13442 69.71.192.0/20 AS13818 PHX-INTL-TELEPORT - Phoenix International Teleport 80.88.0.0/21 AS33774 DJAWEB 80.88.8.0/22 AS33774 DJAWEB 80.88.10.0/24 AS33774 DJAWEB 80.88.12.0/24 AS33779 wataniya-telecom-as 91.214.36.0/22 AS13000 LEON-AS Leon sp. z o.o. 100.100.100.0/30 AS38676 AS33005-AS-KR wizsolution co.,Ltd 109.0.0.0/16 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 109.1.0.0/21 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 109.1.24.0/24 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 110.76.156.0/24 AS45062 CNNIC-FKT-AP FEIKE TECH LIMITED 110.76.157.0/24 AS45062 CNNIC-FKT-AP FEIKE TECH LIMITED 121.46.0.0/16 AS4134 CHINANET-BACKBONE No.31,Jin-rong Street 121.50.168.0/21 AS9931 CAT-AP The Communication Authoity of Thailand, CAT 122.128.120.0/22 AS38456 PACTEL-AS-AP Pacific Teleports. 137.0.0.0/13 AS27064 DDN-ASNBLK1 - DoD Network Information Center 158.222.5.0/24 AS21580 DIRCON - Direct Connect 158.222.70.0/23 AS6137 SISNA - SISNA, Inc. 158.222.72.0/23 AS6137 SISNA - SISNA, Inc. 158.222.224.0/20 AS19864 O1COMM - O1 COMMUNICATIONS 158.222.224.0/22 AS19864 O1COMM - O1 COMMUNICATIONS 158.222.229.0/24 AS19864 O1COMM - O1 COMMUNICATIONS 163.142.0.0/16 AS2500 WIDE-BB WIDE Project 168.253.0.0/16 AS13649 ASN-VINS - ViaWest 168.253.0.0/21 AS13649 ASN-VINS - ViaWest 172.7.0.0/24 AS28175 172.10.1.0/30 AS18305 POSNET POSDATA Co.,Ltd 178.0.0.0/16 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 178.1.0.0/21 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 178.1.24.0/24 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 192.9.0.0/16 AS11479 BRM-SUN-AS - Sun Microsystems, Inc 192.9.200.0/24 AS3602 AS3602-RTI - Rogers Telecom Inc. 192.64.85.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.69.107.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.69.108.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.69.177.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.70.164.0/24 AS25689 NRCNET-AS - National Research Council of Canada 192.96.37.0/24 AS10474 NETACTIVE 192.96.135.0/24 AS2018 TENET-1 192.96.136.0/23 AS2018 TENET-1 192.96.141.0/24 AS2018 TENET-1 192.96.143.0/24 AS2018 TENET-1 192.96.145.0/24 AS2018 TENET-1 192.96.177.0/24 AS6083 POSIX-AFRICA 192.101.45.0/24 AS2905 TICSA-ASN 192.101.46.0/24 AS6503 Avantel, S.A. 192.101.64.0/21 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 192.101.70.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 192.101.71.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 192.101.72.0/24 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 192.101.74.0/24 AS1239 SPRINTLINK - Sprint 192.124.248.0/23 AS680 DFN-IP service G-WiN 192.124.252.0/22 AS680 DFN-IP service G-WiN 192.131.233.0/24 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 192.132.58.0/24 AS20141 QUALITYTECH-SUW-300 - Quality Technology Services, LLC. 192.133.6.0/24 AS10282 ORANGE-BUSINESS-SERVICES-CEEUR Orange Business Services (formerly Equant) AS for CEEUR 192.153.144.0/21 AS27064 DDN-ASNBLK1 - DoD Network Information Center 192.154.32.0/19 AS81 NCREN - MCNC 192.188.208.0/20 AS27064 DDN-ASNBLK1 - DoD Network Information Center 193.33.148.0/23 AS30890 EVOLVA Evolva Telecom 193.169.18.0/23 AS13000 LEON-AS Leon sp. z o.o. 193.169.22.0/23 AS42690 SI-AS JSC "Svyazinvest" 196.6.108.0/24 AS5713 SAIX-NET 196.10.119.0/24 AS2018 TENET-1 196.10.122.0/23 AS2018 TENET-1 196.10.251.0/24 AS2018 TENET-1 196.10.252.0/23 AS2018 TENET-1 196.10.254.0/24 AS2018 TENET-1 196.13.101.0/24 AS2018 TENET-1 196.13.102.0/23 AS2018 TENET-1 196.13.104.0/24 AS2018 TENET-1 196.13.121.0/24 AS2018 TENET-1 196.13.125.0/24 AS2018 TENET-1 196.13.126.0/24 AS2018 TENET-1 196.13.169.0/24 AS2018 TENET-1 196.13.174.0/23 AS2018 TENET-1 196.13.176.0/21 AS2018 TENET-1 196.13.192.0/22 AS2018 TENET-1 196.13.196.0/24 AS2018 TENET-1 196.202.224.0/21 AS8818 TELE Greenland Autonomous System 198.1.2.0/24 AS4761 INDOSAT-INP-AP INDOSAT Internet Network Provider 198.23.26.0/24 AS4390 BELLATLANTIC-COM - Bell Atlantic, Inc. 198.54.82.0/24 AS2018 TENET-1 198.54.92.0/24 AS2018 TENET-1 198.54.222.0/24 AS2018 TENET-1 198.73.210.0/24 AS21570 ACI-1 - Accelerated Connections Inc. 198.97.72.0/21 AS27064 DDN-ASNBLK1 - DoD Network Information Center 198.97.96.0/19 AS27064 DDN-ASNBLK1 - DoD Network Information Center 198.97.240.0/20 AS27064 DDN-ASNBLK1 - DoD Network Information Center 198.135.236.0/24 AS4358 XNET - XNet Information Systems, Inc. 198.161.87.0/24 AS6539 GT-BELL - Bell Canada 198.161.92.0/24 AS6539 GT-BELL - Bell Canada 198.167.0.0/16 AS7456 INTERHOP - Interhop Network SERVICES Inc. 198.168.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 198.169.0.0/16 AS803 SASKTEL - Saskatchewan Telecommunications 198.180.198.0/24 AS23715 SEOUL-INTGW-GXS-AP Global Exchange Services 199.5.242.0/24 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 199.10.0.0/16 AS27064 DDN-ASNBLK1 - DoD Network Information Center 199.19.0.0/24 AS3848 WORLDLINX-2 - WorldLinx Telecommunications, Inc. 199.114.0.0/21 AS27064 DDN-ASNBLK1 - DoD Network Information Center 199.114.128.0/18 AS27064 DDN-ASNBLK1 - DoD Network Information Center 199.114.130.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.131.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.132.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.134.0/24 AS3541 ITSDN-U4 - DoD Network Information Center 199.114.136.0/24 AS27044 DDN-ASNBLK1 - DoD Network Information Center 199.114.138.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.140.0/24 AS3544 ITSDN-U7 - DoD Network Information Center 199.114.142.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.144.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.148.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.150.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.152.0/24 AS27033 DDN-ASNBLK1 - DoD Network Information Center 199.114.153.0/24 AS27034 DDN-ASNBLK1 - DoD Network Information Center 199.114.154.0/24 AS1733 CENTAF-SWA - 754th Electronic Systems Group 199.114.156.0/24 AS1733 CENTAF-SWA - 754th Electronic Systems Group 199.114.160.0/24 AS1733 CENTAF-SWA - 754th Electronic Systems Group 199.121.0.0/16 AS27064 DDN-ASNBLK1 - DoD Network Information Center 199.123.0.0/18 AS27064 DDN-ASNBLK1 - DoD Network Information Center 199.123.16.0/20 AS27064 DDN-ASNBLK1 - DoD Network Information Center 199.123.80.0/21 AS27064 DDN-ASNBLK1 - DoD Network Information Center 199.189.32.0/19 AS7332 IQUEST-AS - IQuest Internet 199.202.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 199.202.216.0/21 AS577 BACOM - Bell Canada 199.246.116.0/24 AS813 UUNET-CANADA - MCI Communications Services, Inc. d/b/a Verizon Business 202.6.176.0/20 AS24316 202.58.113.0/24 AS19161 INNOCOM-TELECOM - INNOCOM TELECOM 202.73.144.0/20 AS4788 TMNET-AS-AP TM Net, Internet Service Provider 202.80.192.0/20 AS2706 HKSUPER-HK-AP Pacific Internet (Hong Kong) Limited 202.86.252.0/22 AS4748 RESOLINK-AS-AP Resources Link Network Limited 202.86.252.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.253.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.254.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.255.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.94.70.0/24 AS2764 AAPT AAPT Limited 202.122.120.0/21 AS17494 BTTB-AS-AP Telecom Operator & Internet Service Provider as well 202.124.195.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.133.70.0/24 AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited 202.133.73.0/24 AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited 202.136.254.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.136.255.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.140.160.0/24 AS4841 202.140.161.0/24 AS4841 202.140.162.0/24 AS4841 202.140.163.0/24 AS4841 202.140.164.0/24 AS4841 202.140.165.0/24 AS4841 202.140.166.0/24 AS4841 202.140.167.0/24 AS4841 202.140.168.0/24 AS4841 202.140.169.0/24 AS4841 202.140.170.0/24 AS4841 202.140.171.0/24 AS4841 202.140.172.0/24 AS4841 202.140.173.0/24 AS4841 202.140.174.0/24 AS4841 202.140.175.0/24 AS4841 202.140.180.0/24 AS7540 HKCIX-AS-AP HongKong Commercial Internet Exchange 202.140.181.0/24 AS7540 HKCIX-AS-AP HongKong Commercial Internet Exchange 202.140.182.0/24 AS7540 HKCIX-AS-AP HongKong Commercial Internet Exchange 202.150.227.0/24 AS17727 NAPINFO-AS-AP PT. NAP Info Lintas Nusa 202.181.32.0/24 AS4645 ASN-HKNET-AP HKNet Co. Ltd 203.12.45.0/24 AS4854 NETSPACE-AS-AP Netspace Online Systems 203.62.0.0/17 AS7575 AARNET-AS-AP Australian Academic and Reasearch Network (AARNet) 203.78.48.0/20 AS9299 IPG-AS-AP Philippine Long Distance Telephone Company 203.89.139.0/24 AS17911 BRAINPK-AS-AP Brain Telecommunication Ltd. 203.112.111.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.113.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.114.0/24 AS4802 ASN-IINET iiNet Limited 203.112.116.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.117.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.118.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.119.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.120.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.121.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.127.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.128.128.0/19 AS4134 CHINANET-BACKBONE No.31,Jin-rong Street 203.128.128.0/24 AS23849 CNNIC-NET263-AP Beijing Capital-online science development Co.,Ltd. 203.152.154.0/23 AS9583 SIFY-AS-IN Sify Limited 203.189.96.0/20 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 204.9.216.0/23 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 204.9.218.0/23 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 204.13.140.0/22 AS7270 NET2PHONE - Net2Phone Corp. 204.13.141.0/24 AS7270 NET2PHONE - Net2Phone Corp. 204.13.142.0/24 AS7270 NET2PHONE - Net2Phone Corp. 204.13.143.0/24 AS7270 NET2PHONE - Net2Phone Corp. 204.13.184.0/23 AS35967 204.13.186.0/23 AS35967 204.13.186.0/24 AS35967 204.13.187.0/24 AS35967 204.19.14.0/23 AS577 BACOM - Bell Canada 204.89.214.0/24 AS4323 TWTC - tw telecom holdings, inc. 204.138.167.0/24 AS18990 AIRBAND-DALLAS - Airband Communications, Inc 205.150.0.0/15 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 205.189.134.0/24 AS11814 CYBERSURF - Cybersurf Inc. 205.210.145.0/24 AS11814 CYBERSURF - Cybersurf Inc. 206.180.240.0/20 AS12083 KNOLOGY-NET - Knology Holdings 207.174.0.0/16 AS13790 INTERNAP-BLK3 - Internap Network Services Corporation 207.174.131.0/24 AS30715 NETRACK - Netrack, Inc. 207.174.132.0/23 AS30715 NETRACK - Netrack, Inc. 207.174.151.0/24 AS11500 PEAKPEAK - Peak to Peak Internet 207.174.152.0/22 AS30715 NETRACK - Netrack, Inc. 207.174.158.0/24 AS11500 PEAKPEAK - Peak to Peak Internet 207.174.177.0/24 AS11500 PEAKPEAK - Peak to Peak Internet 207.174.178.0/24 AS11500 PEAKPEAK - Peak to Peak Internet 207.174.182.0/24 AS29831 FONENET - FONE NET, LLC 207.174.188.0/22 AS30715 NETRACK - Netrack, Inc. 207.174.192.0/24 AS29831 FONENET - FONE NET, LLC 207.174.200.0/24 AS22658 EARTHNET - Earthnet, Inc. 207.174.248.0/21 AS6653 PRIVATEI - privateI, LLC 207.231.96.0/19 AS11194 NUNETPA - NuNet Inc. 209.54.123.0/24 AS6062 NETPLEX - NETPLEX 209.54.240.0/21 AS10887 BPSI-AS - BPSI Internet Services 209.74.96.0/19 AS10912 INTERNAP-BLK - Internap Network Services Corporation 209.140.90.0/24 AS14461 NTSL - NET SOLUTIONS 209.141.48.0/22 AS14461 NTSL - NET SOLUTIONS 209.145.192.0/18 AS3043 AMPHIB-AS - Amphibian Media Corporation 209.177.93.0/24 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 209.222.5.0/24 AS26699 PSI-CT - Printing For Systems Inc 209.222.6.0/24 AS26699 PSI-CT - Printing For Systems Inc 210.5.128.0/20 AS4837 CHINA169-BACKBONE CNCGROUP China169 Backbone 213.181.70.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.80.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.81.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.82.0/23 AS17175 NSS-UK New Skies Satellites UK AS 213.181.82.0/24 AS17175 NSS-UK New Skies Satellites UK AS 213.181.83.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.84.0/22 AS17175 NSS-UK New Skies Satellites UK AS 213.181.84.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.85.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.86.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.87.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.88.0/21 AS17175 NSS-UK New Skies Satellites UK AS 213.181.88.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.89.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.90.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.91.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.92.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.93.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.94.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.95.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 216.37.114.0/23 AS3549 GBLX Global Crossing Ltd. 216.99.20.0/24 AS3356 LEVEL3 Level 3 Communications 216.172.198.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 216.172.199.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 216.240.240.0/24 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 216.240.241.0/24 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 216.240.242.0/24 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 216.251.207.0/24 AS1239 SPRINTLINK - Sprint 217.78.71.0/24 AS12491 IPPLANET-AS IPPlanet 217.78.72.0/24 AS12491 IPPLANET-AS IPPlanet 217.78.73.0/24 AS12491 IPPLANET-AS IPPlanet 217.170.160.0/20 AS44514 INOTEL-AS INOTEL S.A. 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 rs at seastrom.com Fri May 15 07:33:16 2009 From: rs at seastrom.com (Robert E. Seastrom) Date: Fri, 15 May 2009 08:33:16 -0400 Subject: another brick in the wall[ed garden] In-Reply-To: <982D8D05B6407A49AD506E6C3AC8E7D601303C4C7783@caralain.haven.nynaeve.net> (Skywing@valhallalegends.com's message of "Thu, 14 May 2009 21:06:59 -0500") References: <982D8D05B6407A49AD506E6C3AC8E7D601303C4C7783@caralain.haven.nynaeve.net> Message-ID: <86my9ek0kz.fsf@seastrom.com> Skywing writes: > You are brave indeed to trust your packets over the air without a VPN or tunnel of some sort. TSIG is like IPSEC's AH but for DNS. Being untrusting is how I managed to find out about these shenanigans in the first place. I don't care particularly about hiding the payload on a DNS query. -r From nitinics at gmail.com Fri May 15 08:31:22 2009 From: nitinics at gmail.com (Nitin Sharma) Date: Fri, 15 May 2009 09:31:22 -0400 Subject: Google News Down? Message-ID: <1422910c0905150631g5df7ce17qccbd7113bbe3ba97@mail.gmail.com> I can reach Google News through icmp traceroutes, but the HTTP response says "Server Error".Anyone seeing this too? From eslerj at gmail.com Fri May 15 08:37:07 2009 From: eslerj at gmail.com (Joel Esler) Date: Fri, 15 May 2009 09:37:07 -0400 Subject: Google News Down? In-Reply-To: <1422910c0905150631g5df7ce17qccbd7113bbe3ba97@mail.gmail.com> References: <1422910c0905150631g5df7ce17qccbd7113bbe3ba97@mail.gmail.com> Message-ID: <314cf0830905150637l63701a69p829e9e9b35614cdb@mail.gmail.com> On Fri, May 15, 2009 at 9:31 AM, Nitin Sharma wrote: > I can reach Google News through icmp traceroutes, but the HTTP response > says > "Server Error".Anyone seeing this too? > All fine here. -- joel esler | Sourcefire | gtalk: jesler at sourcefire.com | 302-223-5974 | http://twitter.com/joelesler From nitinics at gmail.com Fri May 15 08:41:22 2009 From: nitinics at gmail.com (Nitin Sharma) Date: Fri, 15 May 2009 09:41:22 -0400 Subject: Google News Down? In-Reply-To: <314cf0830905150637l63701a69p829e9e9b35614cdb@mail.gmail.com> References: <1422910c0905150631g5df7ce17qccbd7113bbe3ba97@mail.gmail.com> <314cf0830905150637l63701a69p829e9e9b35614cdb@mail.gmail.com> Message-ID: <1422910c0905150641p39c85a98lcbfab107b93bf098@mail.gmail.com> It is working fine now. Seems like a temporary failure from Google .. for 2 consecutive days? errmm! I can see many tweets to verify that it was indeed not working for many people too. On Fri, May 15, 2009 at 9:37 AM, Joel Esler wrote: > On Fri, May 15, 2009 at 9:31 AM, Nitin Sharma wrote: > >> I can reach Google News through icmp traceroutes, but the HTTP response >> says >> "Server Error".Anyone seeing this too? >> > > > All fine here. > > > -- > joel esler | Sourcefire | gtalk: jesler at sourcefire.com | 302-223-5974 | > http://twitter.com/joelesler > From dga at cs.cmu.edu Fri May 15 08:51:31 2009 From: dga at cs.cmu.edu (David Andersen) Date: Fri, 15 May 2009 09:51:31 -0400 Subject: Managing your network devices via console In-Reply-To: <20090515084459.GP29526@ronin.4ever.de> References: <2909d6d90905141929n746c29c9v88b337ee4ce981c1@mail.gmail.com> <87bppuyep6.fsf@nemi.mork.no> <20090515084459.GP29526@ronin.4ever.de> Message-ID: <736A914C-80AB-401A-8102-32D9150CC6E1@cs.cmu.edu> On May 15, 2009, at 4:45 AM, Elmar K. Bins wrote: > I am concerned about remote power control, though. If you know your > datacenter, you can get all kinds of remote-controlled power strips. > > With us, we don't always know beforehand what kind of power the DCs > will have, and I'd like the exact same equipment everywhere (except > the cables, of course). > > In order to achieve this, I used Cyclades (now Avocent) ATP3120-001 > (20A at 100-240V input on IEC C320-20, 10A outputs on IEC C320-13). > > They have three shortcomings: > - sometimes they forget their configuration (not critical) > - they can only be accessed by serial console (no SNMP etc.) > - consequently there's no power meter remote readout > > Is anyone here aware of such universally usable devices that can > be accessed over IP and give power readouts remotely? > > Electrical specs are as above - 20 Amps input (for 120V countries), > usable anywhere from 100-240 Volts and IEC input and output plugs... > > Any hints? > (No, APC fails in the 100-240V part) > (No, Perle fails in the 100-240V and the IEC part) > (No, even Avocent's other strips fail there...) Check out something like the BayTech RPC3 or RPC41 family? I don't know if it's exactly what you're looking for, but that's what I just picked to have per-outlet monitoring and control for a research datacenter we're building. -Dave -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: This is a digitally signed message part URL: From mansaxel at besserwisser.org Fri May 15 08:52:08 2009 From: mansaxel at besserwisser.org (Mans Nilsson) Date: Fri, 15 May 2009 15:52:08 +0200 Subject: you're not interesting, was Re: another brick in the wall[ed garden] In-Reply-To: References: <20090514223605.88104.qmail@simone.iecc.com> <200905142358.n4ENwWPM094667@drugs.dv.isc.org> <20090515050730.GA10725@besserwisser.org> Message-ID: <20090515135208.GA6272@besserwisser.org> Subject: Re: you're not interesting, was Re: another brick in the wall[ed garden] Date: Fri, May 15, 2009 at 10:10:26AM +0100 Quoting John R. Levine (johnl at iecc.com): >>> And what's the next protocol that is going to be stomped on? >> >> Anything except http; at which point everything will move to http, and >> the firewalls are again useless. > > Um, if you think that http on consumer networks is transparent, I have > some really bad news for you. If you change my sentence thusly: s/http/ what can be communicated over http/1;s/http/said channel/2; ..it all makes sense again, even "better" than before. -- M?ns Nilsson From chaynes at centracomm.net Fri May 15 09:08:45 2009 From: chaynes at centracomm.net (Clay Haynes) Date: Fri, 15 May 2009 10:08:45 -0400 Subject: Managing your network devices via console In-Reply-To: <20090515084459.GP29526@ronin.4ever.de> References: <2909d6d90905141929n746c29c9v88b337ee4ce981c1@mail.gmail.com><87bppuyep6.fsf@nemi.mork.no> <20090515084459.GP29526@ronin.4ever.de> Message-ID: Have you heard of or tried Cyberswitching for remote power management? The DualCom series provide remote SNMP and a WebUI control of all the outlets and you can also query them for how many amps each outlet is pulling. Their DualCom series does support 120-240 VAC as well as supporting IEC C13 and C19 outlets. I've used them for several installs and they work very well in that regard. Take a look at them here: http://www.cyberswitching.com/products-dualcom.html -Clay -----Original Message----- From: Elmar K. Bins [mailto:elmi at 4ever.de] Sent: Friday, May 15, 2009 4:45 AM To: Jake Vargas Cc: nanog at nanog.org Subject: Re: Managing your network devices via console jvargas at crypticstudios.com (Jake Vargas) wrote: > > I stumbled across these, which look like decent alternatives to getting > > a 2511 from eBay: http://www.perle.com/products/Terminal-Server.shtml > > > > The 48-port 1U terminal server with redundant power looks particularily > > nice. > > > > I've no experience with Perle, though. Anyone else? > > > > I use them in my datacenter. SCS 32 with the IOLAN Modem card. I have some basic advice for using it as a dialup source. It also does IPSec via our DSL line which also happens to be our POTs line. All kinds of nice stuff but a bit of a pain to initially configure if you do not know what you are doing (slight learning curve). I'm happy with it. We are still using the "ancient" Cyclades/Avocent ACS'es with a matching modem card (getting rare, them). They work fine, a bit slow on sshV2, but no problems in all the remote locations. I had one (pretty old) fail in the lab, but this might have been due to it being quite warm there... I am concerned about remote power control, though. If you know your datacenter, you can get all kinds of remote-controlled power strips. With us, we don't always know beforehand what kind of power the DCs will have, and I'd like the exact same equipment everywhere (except the cables, of course). In order to achieve this, I used Cyclades (now Avocent) ATP3120-001 (20A at 100-240V input on IEC C320-20, 10A outputs on IEC C320-13). They have three shortcomings: - sometimes they forget their configuration (not critical) - they can only be accessed by serial console (no SNMP etc.) - consequently there's no power meter remote readout Is anyone here aware of such universally usable devices that can be accessed over IP and give power readouts remotely? Electrical specs are as above - 20 Amps input (for 120V countries), usable anywhere from 100-240 Volts and IEC input and output plugs... Any hints? (No, APC fails in the 100-240V part) (No, Perle fails in the 100-240V and the IEC part) (No, even Avocent's other strips fail there...) Yours, Elmi. -- "Hinken ist kein Mangel eines Vergleichs, sondern sollte als wesentliche Eigenschaft von Vergleichen angesehen werden." (Marius Fr?nzel in desd) --------------------------------------------------------------[ ELMI-RIPE ]--- From invite+ohip1doe at facebookmail.com Fri May 15 09:39:30 2009 From: invite+ohip1doe at facebookmail.com (Martin Hepworth) Date: Fri, 15 May 2009 07:39:30 -0700 Subject: Check out my photos on Facebook Message-ID: <17dd4a6343966706ebbed006eb1cd00d@localhost.localdomain> Hi Nanog, I invited you to join Facebook a while back and wanted to remind you that once you join, we'll be able to connect online, share photos, organize groups and events, and more. Thanks, Martin To sign up for Facebook, follow the link below: http://www.facebook.com/p.php?i=681923447&k=RVMZQ2U532WMYKMCYFX5P&r nanog at nanog.org was invited to join Facebook by Martin Hepworth. If you do not wish to receive this type of email from Facebook in the future, please click on the link below to unsubscribe. http://www.facebook.com/o.php?k=464bf3&u=699384721&mid=777bd0G29afc391G0G8 Facebook's offices are located at 156 University Ave., Palo Alto, CA 94301. From jared at puck.nether.net Fri May 15 09:41:44 2009 From: jared at puck.nether.net (Jared Mauch) Date: Fri, 15 May 2009 10:41:44 -0400 Subject: Check out my photos on Facebook In-Reply-To: <17dd4a6343966706ebbed006eb1cd00d@localhost.localdomain> References: <17dd4a6343966706ebbed006eb1cd00d@localhost.localdomain> Message-ID: <20090515144144.GB90229@puck.nether.net> At least if facebook is going to reach the list, please RSVP here: http://www.facebook.com/home.php#/event.php?eid=86529812115&ref=ts -- Jared Mauch | pgp key available via finger from jared at puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine. From dstorandt at teljet.com Fri May 15 10:07:32 2009 From: dstorandt at teljet.com (David Storandt) Date: Fri, 15 May 2009 11:07:32 -0400 Subject: NPE-G2 vs. Sup720-3BXL Message-ID: We're stuck in an engineering pickle, so some experience from this crew would be useful in tie-breaking... We operate a business-grade FTTx ISP with ~75 customers and 800Mbps of Internet traffic, currently using 6509/Sup2s for core routing and port aggregation. The MSFC2s are under stress from 3x full route feeds, pared down to 85% to fit the TCAM tables. One system has a FlexWAN with an OC3 card and it's crushing the CPU on the MSFC2. System tuning (stable IOS and esp. disabling SPD) helped a lot but still doesn't have the power to pull through. Hardware upgrades are needed... We need true full routes and more CPU horsepower for crunching BGP (+12 smaller peers + ISIS). OC3 interfaces are going to be mandatory, one each at two locations. Oh yeah, we're still a larger startup without endless pockets. Power, rack space, and SmartNet are not concerns at any location (on-site cold spares). We may need an upstream OC12 in the future but that's a ways out and not a concern here. Our engineering team has settled on three $20k/node options: - Sup720-3BXLs with PS and fan upgrades - Sup2s as switches + ISIS + statics and no BGP, push BGP edge routing off to NPE-G2s across a 2-3Gbps port-channel - Sup2s as switches + ISIS + statics and no BGP, push BGP edge routing off to a 12008 with E3 engines across a 2-3Gbps port-channel. Ideas and constructive opinions welcome, especially software and stability-related. Many thanks, -Dave From elmi at 4ever.de Fri May 15 10:21:28 2009 From: elmi at 4ever.de (Elmar K. Bins) Date: Fri, 15 May 2009 17:21:28 +0200 Subject: NPE-G2 vs. Sup720-3BXL In-Reply-To: References: Message-ID: <20090515152128.GL29526@ronin.4ever.de> dstorandt at teljet.com (David Storandt) wrote: > Our engineering team has settled on three $20k/node options: > - Sup720-3BXLs with PS and fan upgrades Still quite slow CPU wise. RSP's are supposed to be a lot faster and actually usable. > - Sup2s as switches + ISIS + statics and no BGP, push BGP edge routing > off to NPE-G2s across a 2-3Gbps port-channel The NPE-G2 - even an NPE-G1 - will do all that BGP stuff easily; the CPU is fast enough. But...you might be in for a bad surprise concerning the Portchannel. Remember - it's done in software. So, depending on your packet sizes, you might experience a throughput _drop_ once you bundle. My experiments were done with very small packets though (DNS queries and responses, avg. packet size around 140 Byte). The devices I tested were the 1RU models (7301 for NPE-G1 and 7201 for NPE-G2). In "unbundled mode" they pushed around 940 kpps (G1) and 1320 kpps (G2) with CPU loads between 85% and 100%. Channel bundling took a lot out of the boxes. 7301 keeled over at 470, 7201 at 660 kpps. If you're only pushing big packets, though... Yours, Elmar. From pstewart at nexicomgroup.net Fri May 15 10:33:04 2009 From: pstewart at nexicomgroup.net (Paul Stewart) Date: Fri, 15 May 2009 11:33:04 -0400 Subject: NPE-G2 vs. Sup720-3BXL In-Reply-To: References: Message-ID: We've never pushed a NPE-G2 to 800Mb/s before but I would think they would topple over... hopefully someone on here could confirm my statement? Moving the BGP to the 12008's would be my choice with PRP-2 processors if the budget fits.... we're faced with a similar upgrade next year possibly moving BGP from a pair of 7606's (Sup720-3BXL) over to a pair of GSR's running PRP2 I think - the BGP processing etc. is pushing the CPU's too high on the 7600's.... Someone else might suggest the RSP720's but haven't had them in a production environment yet... we had PRP2's running on 12012 for a while and found them rock solid even with older line cards etc... Hope this helps a bit...;) Paul -----Original Message----- From: David Storandt [mailto:dstorandt at teljet.com] Sent: Friday, May 15, 2009 11:08 AM To: NANOG list Subject: NPE-G2 vs. Sup720-3BXL We're stuck in an engineering pickle, so some experience from this crew would be useful in tie-breaking... We operate a business-grade FTTx ISP with ~75 customers and 800Mbps of Internet traffic, currently using 6509/Sup2s for core routing and port aggregation. The MSFC2s are under stress from 3x full route feeds, pared down to 85% to fit the TCAM tables. One system has a FlexWAN with an OC3 card and it's crushing the CPU on the MSFC2. System tuning (stable IOS and esp. disabling SPD) helped a lot but still doesn't have the power to pull through. Hardware upgrades are needed... We need true full routes and more CPU horsepower for crunching BGP (+12 smaller peers + ISIS). OC3 interfaces are going to be mandatory, one each at two locations. Oh yeah, we're still a larger startup without endless pockets. Power, rack space, and SmartNet are not concerns at any location (on-site cold spares). We may need an upstream OC12 in the future but that's a ways out and not a concern here. Our engineering team has settled on three $20k/node options: - Sup720-3BXLs with PS and fan upgrades - Sup2s as switches + ISIS + statics and no BGP, push BGP edge routing off to NPE-G2s across a 2-3Gbps port-channel - Sup2s as switches + ISIS + statics and no BGP, push BGP edge routing off to a 12008 with E3 engines across a 2-3Gbps port-channel. Ideas and constructive opinions welcome, especially software and stability-related. Many thanks, -Dave ---------------------------------------------------------------------------- "The information transmitted is intended only for the person or entity to which it is addressed and contains confidential and/or privileged material. If you received this in error, please contact the sender immediately and then destroy this transmission, including all attachments, without copying, distributing or disclosing same. Thank you." From leland at taranta.discpro.org Fri May 15 11:21:23 2009 From: leland at taranta.discpro.org (Leland E. Vandervort) Date: Fri, 15 May 2009 16:21:23 +0000 (GMT) Subject: NPE-G2 vs. Sup720-3BXL In-Reply-To: Message-ID: We're running several six 65xx Sup720-3BXL with 3 full transit views and some 40-odd peers. We use two NPE-G1s for reflectors and some policy manipulation. Also running MPLS in the core to allow for traffic engineering and EoMPLS between certain services located in different locations. We're pushing up to between 800M and 1G at peak times (mostly outbound) with this setup and peak CPU on the 3BXLs is running maybe 30% -- average though of around 8 to 10%. Hope this helps.... side-note: I'm actually more worried about the distribution layer at the moment as it relies heavily on STP and HSRP/GLBP for the various vlans and access layer gunk. Currently these are 720-3B (non-XL), but looking eventually to build a business case to upgrade these to VSS1440 to simplify the architecture as well as providing better resilience and elimination of STP/HSRP/GLBP limitations between the dist and access layers. Problem is the budget side of that... blargh! Ideally I'd like to go more for the Nexus platform for this part of the network, given that we're doing a lot of virtualisation etc., but the downsides with that are primarily the COST of the bloody things, and secondly the fact that they don't currently support MPLS (planned for later this year, apparently). Leland On Fri, 15 May 2009, Paul Stewart wrote: > We've never pushed a NPE-G2 to 800Mb/s before but I would think they > would topple over... hopefully someone on here could confirm my > statement? > > Moving the BGP to the 12008's would be my choice with PRP-2 processors > if the budget fits.... we're faced with a similar upgrade next year > possibly moving BGP from a pair of 7606's (Sup720-3BXL) over to a pair > of GSR's running PRP2 I think - the BGP processing etc. is pushing the > CPU's too high on the 7600's.... > > Someone else might suggest the RSP720's but haven't had them in a > production environment yet... we had PRP2's running on 12012 for a > while and found them rock solid even with older line cards etc... > > Hope this helps a bit...;) > > Paul > > > -----Original Message----- > From: David Storandt [mailto:dstorandt at teljet.com] > Sent: Friday, May 15, 2009 11:08 AM > To: NANOG list > Subject: NPE-G2 vs. Sup720-3BXL > > We're stuck in an engineering pickle, so some experience from this > crew would be useful in tie-breaking... > > We operate a business-grade FTTx ISP with ~75 customers and 800Mbps of > Internet traffic, currently using 6509/Sup2s for core routing and port > aggregation. The MSFC2s are under stress from 3x full route feeds, > pared down to 85% to fit the TCAM tables. One system has a FlexWAN > with an OC3 card and it's crushing the CPU on the MSFC2. System tuning > (stable IOS and esp. disabling SPD) helped a lot but still doesn't > have the power to pull through. Hardware upgrades are needed... > > We need true full routes and more CPU horsepower for crunching BGP > (+12 smaller peers + ISIS). OC3 interfaces are going to be mandatory, > one each at two locations. Oh yeah, we're still a larger startup > without endless pockets. Power, rack space, and SmartNet are not > concerns at any location (on-site cold spares). We may need an > upstream OC12 in the future but that's a ways out and not a concern > here. > > Our engineering team has settled on three $20k/node options: > - Sup720-3BXLs with PS and fan upgrades > - Sup2s as switches + ISIS + statics and no BGP, push BGP edge routing > off to NPE-G2s across a 2-3Gbps port-channel > - Sup2s as switches + ISIS + statics and no BGP, push BGP edge routing > off to a 12008 with E3 engines across a 2-3Gbps port-channel. > > Ideas and constructive opinions welcome, especially software and > stability-related. > > Many thanks, > -Dave > > > > > > ---------------------------------------------------------------------------- > > "The information transmitted is intended only for the person or entity to which it is addressed and contains confidential and/or privileged material. If you received this in error, please contact the sender immediately and then destroy this transmission, including all attachments, without copying, distributing or disclosing same. Thank you." > > From aaron.millisor at bright.net Fri May 15 11:44:18 2009 From: aaron.millisor at bright.net (Aaron Millisor) Date: Fri, 15 May 2009 12:44:18 -0400 Subject: NPE-G2 vs. Sup720-3BXL In-Reply-To: References: Message-ID: <4A0D9BE2.4030701@bright.net> We ran into a similar quandary and have about the same amount of traffic as your network. When purchasing gear a year ago we decided against 7200's with an NPE-G2 as insufficient for the load. Have you looked at the 7304? The Cisco 7304 with an NSE-150 processing engine on it offloads a lot of the packet processing to dedicated hardware, and doesn't have TCAM limitations for routes. You can hold several full feeds and do the amount of traffic you're talking about without breaking a sweat. http://www.cisco.com/en/US/prod/collateral/routers/ps352/prod_bulletin0900aecd8060aac5.html It is capable of supporting both legacy port adapters (from your Flexwan or 7200 routers) and SPA cards with the right add-in modules, which IIRC is only a few hundred dollars. I'd be glad to answer any questions you have about our implementation. --am David Storandt wrote: > We're stuck in an engineering pickle, so some experience from this > crew would be useful in tie-breaking... > > We operate a business-grade FTTx ISP with ~75 customers and 800Mbps of > Internet traffic, currently using 6509/Sup2s for core routing and port > aggregation. The MSFC2s are under stress from 3x full route feeds, > pared down to 85% to fit the TCAM tables. One system has a FlexWAN > with an OC3 card and it's crushing the CPU on the MSFC2. System tuning > (stable IOS and esp. disabling SPD) helped a lot but still doesn't > have the power to pull through. Hardware upgrades are needed... > > We need true full routes and more CPU horsepower for crunching BGP > (+12 smaller peers + ISIS). OC3 interfaces are going to be mandatory, > one each at two locations. Oh yeah, we're still a larger startup > without endless pockets. Power, rack space, and SmartNet are not > concerns at any location (on-site cold spares). We may need an > upstream OC12 in the future but that's a ways out and not a concern > here. > > Our engineering team has settled on three $20k/node options: > - Sup720-3BXLs with PS and fan upgrades > - Sup2s as switches + ISIS + statics and no BGP, push BGP edge routing > off to NPE-G2s across a 2-3Gbps port-channel > - Sup2s as switches + ISIS + statics and no BGP, push BGP edge routing > off to a 12008 with E3 engines across a 2-3Gbps port-channel. > > Ideas and constructive opinions welcome, especially software and > stability-related. > > Many thanks, > -Dave From r.hyunseog at ieee.org Fri May 15 11:51:50 2009 From: r.hyunseog at ieee.org (Alex H. Ryu) Date: Fri, 15 May 2009 11:51:50 -0500 Subject: NPE-G2 vs. Sup720-3BXL In-Reply-To: <4A0D9BE2.4030701@bright.net> References: <4A0D9BE2.4030701@bright.net> Message-ID: <4A0D9DA6.9020604@ieee.org> Cisco 7304 may not adequate for service provider. It's CPU/IO-controller is tied together, and doesn't provide much of benefit. Cisco 7200/7300 is enterprise solution pretty much, and doesn't support distributed CEF. If you are considering SUP720-3BXL, why not considering RSP720-3CXL ? Alex Aaron Millisor wrote: > We ran into a similar quandary and have about the same amount of > traffic as your network. When purchasing gear a year ago we decided > against 7200's with an NPE-G2 as insufficient for the load. Have you > looked at the 7304? > > The Cisco 7304 with an NSE-150 processing engine on it offloads a lot > of the packet processing to dedicated hardware, and doesn't have TCAM > limitations for routes. You can hold several full feeds and do the > amount of traffic you're talking about without breaking a sweat. > > http://www.cisco.com/en/US/prod/collateral/routers/ps352/prod_bulletin0900aecd8060aac5.html > > > It is capable of supporting both legacy port adapters (from your > Flexwan or 7200 routers) and SPA cards with the right add-in modules, > which IIRC is only a few hundred dollars. > > I'd be glad to answer any questions you have about our implementation. > > --am > > David Storandt wrote: >> We're stuck in an engineering pickle, so some experience from this >> crew would be useful in tie-breaking... >> >> We operate a business-grade FTTx ISP with ~75 customers and 800Mbps of >> Internet traffic, currently using 6509/Sup2s for core routing and port >> aggregation. The MSFC2s are under stress from 3x full route feeds, >> pared down to 85% to fit the TCAM tables. One system has a FlexWAN >> with an OC3 card and it's crushing the CPU on the MSFC2. System tuning >> (stable IOS and esp. disabling SPD) helped a lot but still doesn't >> have the power to pull through. Hardware upgrades are needed... >> >> We need true full routes and more CPU horsepower for crunching BGP >> (+12 smaller peers + ISIS). OC3 interfaces are going to be mandatory, >> one each at two locations. Oh yeah, we're still a larger startup >> without endless pockets. Power, rack space, and SmartNet are not >> concerns at any location (on-site cold spares). We may need an >> upstream OC12 in the future but that's a ways out and not a concern >> here. >> >> Our engineering team has settled on three $20k/node options: >> - Sup720-3BXLs with PS and fan upgrades >> - Sup2s as switches + ISIS + statics and no BGP, push BGP edge routing >> off to NPE-G2s across a 2-3Gbps port-channel >> - Sup2s as switches + ISIS + statics and no BGP, push BGP edge routing >> off to a 12008 with E3 engines across a 2-3Gbps port-channel. >> >> Ideas and constructive opinions welcome, especially software and >> stability-related. >> >> Many thanks, >> -Dave > > > From dstorandt at teljet.com Fri May 15 12:23:08 2009 From: dstorandt at teljet.com (David Storandt) Date: Fri, 15 May 2009 13:23:08 -0400 Subject: NPE-G2 vs. Sup720-3BXL In-Reply-To: <4A0D9DA6.9020604@ieee.org> References: <4A0D9BE2.4030701@bright.net> <4A0D9DA6.9020604@ieee.org> Message-ID: I would love to use the RSP720-3CXL, but cost and the PA OC3 are the difficulties. If the RSP720s will run in a 6500 chassis, great! We wouldn't have to purchase new chassis and the increased downtime for the swap-out. RSP720 don't support the older bus-only FlexWAN either with the OC3 PA we're using, so we'd have to figure out a solution for that - SIPs, Enhanced FlexWAN, or external routers. Bah. ...the RSP720s + chassis + OC3 solution more than double our $20k/node budget, so that's a much tougher sell internally. -Dave 2009/5/15 Alex H. Ryu : > Cisco 7304 may not adequate for service provider. > It's CPU/IO-controller is tied together, and doesn't provide much of > benefit. > > Cisco 7200/7300 is enterprise solution pretty much, and doesn't support > distributed CEF. > > If you are considering SUP720-3BXL, why not considering RSP720-3CXL ? > > Alex > > > Aaron Millisor wrote: >> We ran into a similar quandary and have about the same amount of >> traffic as your network. When purchasing gear a year ago we decided >> against 7200's with an NPE-G2 as insufficient for the load. Have you >> looked at the 7304? >> >> The Cisco 7304 with an NSE-150 processing engine on it offloads a lot >> of the packet processing to dedicated hardware, and doesn't have TCAM >> limitations for routes. You can hold several full feeds and do the >> amount of traffic you're talking about without breaking a sweat. >> >> http://www.cisco.com/en/US/prod/collateral/routers/ps352/prod_bulletin0900aecd8060aac5.html >> >> >> It is capable of supporting both legacy port adapters (from your >> Flexwan or 7200 routers) and SPA cards with the right add-in modules, >> which IIRC is only a few hundred dollars. >> >> I'd be glad to answer any questions you have about our implementation. >> >> --am >> >> David Storandt wrote: >>> We're stuck in an engineering pickle, so some experience from this >>> crew would be useful in tie-breaking... >>> >>> We operate a business-grade FTTx ISP with ~75 customers and 800Mbps of >>> Internet traffic, currently using 6509/Sup2s for core routing and port >>> aggregation. The MSFC2s are under stress from 3x full route feeds, >>> pared down to 85% to fit the TCAM tables. One system has a FlexWAN >>> with an OC3 card and it's crushing the CPU on the MSFC2. System tuning >>> (stable IOS and esp. disabling SPD) helped a lot but still doesn't >>> have the power to pull through. Hardware upgrades are needed... >>> >>> We need true full routes and more CPU horsepower for crunching BGP >>> (+12 smaller peers + ISIS). OC3 interfaces are going to be mandatory, >>> one each at two locations. Oh yeah, we're still a larger startup >>> without endless pockets. Power, rack space, and SmartNet are not >>> concerns at any location (on-site cold spares). We may need an >>> upstream OC12 in the future but that's a ways out and not a concern >>> here. >>> >>> Our engineering team has settled on three $20k/node options: >>> - Sup720-3BXLs with PS and fan upgrades >>> - Sup2s as switches + ISIS + statics and no BGP, push BGP edge routing >>> off to NPE-G2s across a 2-3Gbps port-channel >>> - Sup2s as switches + ISIS + statics and no BGP, push BGP edge routing >>> off to a 12008 with E3 engines across a 2-3Gbps port-channel. >>> >>> Ideas and constructive opinions welcome, especially software and >>> stability-related. >>> >>> Many thanks, >>> -Dave >> >> >> > > From owen at delong.com Fri May 15 12:34:14 2009 From: owen at delong.com (Owen DeLong) Date: Fri, 15 May 2009 10:34:14 -0700 Subject: you're not interesting, was Re: another brick in the wall[ed garden] In-Reply-To: <20090515050730.GA10725@besserwisser.org> References: <20090514223605.88104.qmail@simone.iecc.com> <200905142358.n4ENwWPM094667@drugs.dv.isc.org> <20090515050730.GA10725@besserwisser.org> Message-ID: <9D559FD4-F4C4-48F8-9385-CAB92C0AD863@delong.com> On May 14, 2009, at 10:07 PM, Mans Nilsson wrote: > Subject: Re: you're not interesting, was Re: another brick in the > wall[ed garden] Date: Fri, May 15, 2009 at 09:58:32AM +1000 Quoting > Mark Andrews (Mark_Andrews at isc.org): >> And what's the next protocol that is going to be stomped on? > > Anything except http; at which point everything will move to http, and > the firewalls are again useless. > This is, indeed, already happening. In fact, I'm running an SMTP server with TLS on port 80 to get around SPRINT's existing braindamage. (or at least the braindamage they had at one point). Owen > -- > M?ns Nilsson > > From dylan.ebner at crlmed.com Fri May 15 13:04:47 2009 From: dylan.ebner at crlmed.com (Dylan Ebner) Date: Fri, 15 May 2009 12:04:47 -0600 Subject: Managing your network devices via console In-Reply-To: <2909d6d90905141929n746c29c9v88b337ee4ce981c1@mail.gmail.com> References: <2909d6d90905141929n746c29c9v88b337ee4ce981c1@mail.gmail.com> Message-ID: <6286FF05EBE33C4596F6C6C23762686701FCE20B@VS11.EXCHPROD.USA.NET> We use Cyclades (avocent) devices in our data center. They have worked great for us. Very reliable. Modem dial-in gives us great remote capabilities if we have a major outage. We had troubles initially getting them to work because the cable adapters were never pinned correctly for Cisco. We ended up making our own rolled rj45-rj45 cables. IIRC, this was a ton of work as you need to do some funky 2 wires in one position stuff. We also use Cisco 2500's with modem on the aux and an octo-cable for the devices. This works well too, but not as nice of an interface as the Cyclades. No special cables needed though. For power we have been using APC Managed PDU's. These have been fantastic. No compaints. -----Original Message----- From: Mehmet Akcin [mailto:mehmet at akcin.net] Sent: Thursday, May 14, 2009 9:30 PM To: nanog at nanog.org Subject: Managing your network devices via console Hello, It's always cool to have console access to routers/switches and nowadays they are going from RS-232 to RJ-45 as a standart. I have got Avocent DSR 2035 which is a KVM+Serial console (all in one).. but while I was able to have it work against servers via KVM or/and Serial , I was unable to make it work properly against any network device. I am wondering if anyone had experience on DSR or similar boxes to configure them against network devices console ports. Making suggestions for alternative ways of centralizing network device console management is also more than welcome, I guess the old fashioned server attached usb-serial console is one of the most preferred way, but feel free to provide if you have good ideas cheers -- Mehmet From cscora at apnic.net Fri May 15 13:15:49 2009 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 16 May 2009 04:15:49 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <200905151815.n4FIFnE5005086@thyme.apnic.net> This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. Daily listings are sent to bgp-stats at lists.apnic.net For historical data, please see http://thyme.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 16 May, 2009 Report Website: http://thyme.apnic.net Detailed Analysis: http://thyme.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 288509 Prefixes after maximum aggregation: 136412 Deaggregation factor: 2.11 Unique aggregates announced to Internet: 141329 Total ASes present in the Internet Routing Table: 31265 Prefixes per ASN: 9.23 Origin-only ASes present in the Internet Routing Table: 27181 Origin ASes announcing only one prefix: 13271 Transit ASes present in the Internet Routing Table: 4084 Transit-only ASes present in the Internet Routing Table: 93 Average AS path length visible in the Internet Routing Table: 3.6 Max AS path length visible: 33 Max AS path prepend of ASN (43683) 31 Prefixes from unregistered ASNs in the Routing Table: 464 Unregistered ASNs in the Routing Table: 151 Number of 32-bit ASNs allocated by the RIRs: 144 Prefixes from 32-bit ASNs in the Routing Table: 33 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 217 Number of addresses announced to Internet: 2045653328 Equivalent to 121 /8s, 238 /16s and 49 /24s Percentage of available address space announced: 55.2 Percentage of allocated address space announced: 63.9 Percentage of available address space allocated: 86.4 Percentage of address space in use by end-sites: 77.0 Total number of prefixes smaller than registry allocations: 142688 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 67654 Total APNIC prefixes after maximum aggregation: 24179 APNIC Deaggregation factor: 2.80 Prefixes being announced from the APNIC address blocks: 64332 Unique aggregates announced from the APNIC address blocks: 29021 APNIC Region origin ASes present in the Internet Routing Table: 3628 APNIC Prefixes per ASN: 17.73 APNIC Region origin ASes announcing only one prefix: 990 APNIC Region transit ASes present in the Internet Routing Table: 559 Average APNIC Region AS path length visible: 3.5 Max APNIC Region AS path length visible: 18 Number of APNIC addresses announced to Internet: 413775280 Equivalent to 24 /8s, 169 /16s and 181 /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 APNIC Address Blocks 58/8, 59/8, 60/8, 61/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 180/8, 183/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 125540 Total ARIN prefixes after maximum aggregation: 66187 ARIN Deaggregation factor: 1.90 Prefixes being announced from the ARIN address blocks: 94652 Unique aggregates announced from the ARIN address blocks: 36596 ARIN Region origin ASes present in the Internet Routing Table: 12997 ARIN Prefixes per ASN: 7.28 ARIN Region origin ASes announcing only one prefix: 5002 ARIN Region transit ASes present in the Internet Routing Table: 1272 Average ARIN Region AS path length visible: 3.3 Max ARIN Region AS path length visible: 24 Number of ARIN addresses announced to Internet: 428644608 Equivalent to 25 /8s, 140 /16s and 153 /24s Percentage of available ARIN address space announced: 82.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 ARIN Address Blocks 24/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8, 98/8, 99/8, 108/8, 173/8, 174/8, 184/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 66135 Total RIPE prefixes after maximum aggregation: 38352 RIPE Deaggregation factor: 1.72 Prefixes being announced from the RIPE address blocks: 60448 Unique aggregates announced from the RIPE address blocks: 40229 RIPE Region origin ASes present in the Internet Routing Table: 13009 RIPE Prefixes per ASN: 4.65 RIPE Region origin ASes announcing only one prefix: 6825 RIPE Region transit ASes present in the Internet Routing Table: 1961 Average RIPE Region AS path length visible: 4.0 Max RIPE Region AS path length visible: 33 Number of RIPE addresses announced to Internet: 393701408 Equivalent to 23 /8s, 119 /16s and 104 /24s Percentage of available RIPE address space announced: 83.8 RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-52223 RIPE Address Blocks 62/8, 77/8, 78/8, 79/8, 80/8, 81/8, 82/8, 83/8, 84/8, 85/8, 86/8, 87/8, 88/8, 89/8, 90/8, 91/8, 92/8, 93/8, 94/8, 95/8, 109/8, 178/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 23824 Total LACNIC prefixes after maximum aggregation: 5887 LACNIC Deaggregation factor: 4.05 Prefixes being announced from the LACNIC address blocks: 21985 Unique aggregates announced from the LACNIC address blocks: 12186 LACNIC Region origin ASes present in the Internet Routing Table: 1107 LACNIC Prefixes per ASN: 19.86 LACNIC Region origin ASes announcing only one prefix: 362 LACNIC Region transit ASes present in the Internet Routing Table: 187 Average LACNIC Region AS path length visible: 4.1 Max LACNIC Region AS path length visible: 19 Number of LACNIC addresses announced to Internet: 63251840 Equivalent to 3 /8s, 197 /16s and 37 /24s Percentage of available LACNIC address space announced: 62.8 LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247 plus ERX transfers LACNIC Address Blocks 186/8, 187/8, 189/8, 190/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 4925 Total AfriNIC prefixes after maximum aggregation: 1468 AfriNIC Deaggregation factor: 3.35 Prefixes being announced from the AfriNIC address blocks: 4540 Unique aggregates announced from the AfriNIC address blocks: 1384 AfriNIC Region origin ASes present in the Internet Routing Table: 299 AfriNIC Prefixes per ASN: 15.18 AfriNIC Region origin ASes announcing only one prefix: 92 AfriNIC Region transit ASes present in the Internet Routing Table: 60 Average AfriNIC Region AS path length visible: 3.9 Max AfriNIC Region AS path length visible: 18 Number of AfriNIC addresses announced to Internet: 11359232 Equivalent to 0 /8s, 173 /16s and 84 /24s Percentage of available AfriNIC address space announced: 33.9 AfriNIC AS Blocks 36864-37887 & ERX transfers AfriNIC Address Blocks 41/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4766 1698 6930 403 Korea Telecom (KIX) 17488 1584 128 104 Hathway IP Over Cable Interne 4755 1247 466 128 TATA Communications formerly 9583 1079 86 541 Sify Limited 4134 887 16660 372 CHINANET-BACKBONE 23577 780 34 662 Korea Telecom (ATM-MPLS) 7545 772 198 103 TPG Internet Pty Ltd 18101 754 217 32 Reliance Infocom Ltd Internet 24560 689 229 179 Bharti Airtel Ltd. 9829 670 561 14 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 4296 3647 324 bellsouth.net, inc. 209 2560 4149 607 Qwest 4323 1848 1035 373 Time Warner Telecom 1785 1759 717 139 PaeTec Communications, Inc. 20115 1627 1444 720 Charter Communications 7018 1490 5914 1024 AT&T WorldNet Services 6478 1404 310 400 AT&T Worldnet Services 2386 1262 697 915 AT&T Data Communications Serv 3356 1224 10981 461 Level 3 Communications, LLC 11492 1099 192 11 Cable One Complete listing at http://thyme.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 8452 1200 188 7 TEDATA 30890 542 88 201 Evolva Telecom 3292 455 1893 393 TDC Tele Danmark 12479 449 578 6 Uni2 Autonomous System 8866 382 110 24 Bulgarian Telecommunication C 3320 349 7082 300 Deutsche Telekom AG 3215 343 3041 108 France Telecom Transpac 3301 340 1668 304 TeliaNet Sweden 35805 328 24 4 United Telecom of Georgia 29049 316 26 3 AzerSat LLC. Complete listing at http://thyme.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 8151 1449 2862 231 UniNet S.A. de C.V. 10620 906 207 108 TVCABLE BOGOTA 22047 610 302 14 VTR PUNTO NET S.A. 7303 529 274 75 Telecom Argentina Stet-France 11830 516 294 34 Instituto Costarricense de El 28573 464 562 26 NET Servicos de Comunicao S.A 6471 443 96 32 ENTEL CHILE S.A. 11172 443 102 72 Servicios Alestra S.A de C.V 7738 397 794 28 Telecomunicacoes da Bahia S.A 3816 351 163 74 Empresa Nacional de Telecomun Complete listing at http://thyme.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 24863 860 79 37 LINKdotNET AS number 20858 308 34 5 This AS will be used to conne 3741 278 860 238 The Internet Solution 2018 243 215 143 Tertiary Education Network 6713 160 151 12 Itissalat Al-MAGHRIB 29571 139 15 9 Ci Telecom Autonomous system 5536 123 8 9 Internet Egypt Network 33776 116 6 7 Starcomms Nigeria Limited 5713 113 507 64 Telkom SA Ltd 24835 107 46 9 RAYA Telecom - Egypt 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 4296 3647 324 bellsouth.net, inc. 209 2560 4149 607 Qwest 4323 1848 1035 373 Time Warner Telecom 1785 1759 717 139 PaeTec Communications, Inc. 4766 1698 6930 403 Korea Telecom (KIX) 20115 1627 1444 720 Charter Communications 17488 1584 128 104 Hathway IP Over Cable Interne 7018 1490 5914 1024 AT&T WorldNet Services 8151 1449 2862 231 UniNet S.A. de C.V. 6478 1404 310 400 AT&T Worldnet Services Complete listing at http://thyme.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 209 2560 1953 Qwest 1785 1759 1620 PaeTec Communications, Inc. 17488 1584 1480 Hathway IP Over Cable Interne 4323 1848 1475 Time Warner Telecom 4766 1698 1295 Korea Telecom (KIX) 8151 1449 1218 UniNet S.A. de C.V. 8452 1200 1193 TEDATA 4755 1247 1119 TATA Communications formerly 11492 1099 1088 Cable One 18566 1062 1052 Covad Communications Complete listing at http://thyme.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 16927 UNALLOCATED 12.0.252.0/23 7018 AT&T WorldNet Servic 15132 UNALLOCATED 12.9.150.0/24 7018 AT&T WorldNet Servic 32567 UNALLOCATED 12.14.170.0/24 7018 AT&T WorldNet Servic 13746 UNALLOCATED 12.24.56.0/24 7018 AT&T WorldNet Servic 32567 UNALLOCATED 12.25.107.0/24 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.152.0/24 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.154.0/23 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.159.0/24 7018 AT&T WorldNet Servic 32326 UNALLOCATED 12.40.49.0/24 7018 AT&T WorldNet Servic 25639 UNALLOCATED 12.41.169.0/24 7018 AT&T WorldNet Servic Complete listing at http://thyme.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 24.246.0.0/17 7018 AT&T WorldNet Services 24.246.128.0/18 7018 AT&T WorldNet Services 41.223.112.0/22 5713 Telkom SA Ltd 41.223.176.0/22 36981 >>UNKNOWN<< 41.223.188.0/24 22351 Intelsat 41.223.189.0/24 26452 Local Communications Networks 62.61.220.0/24 24974 Tachyon Europe BV - Wireless 62.61.221.0/24 24974 Tachyon Europe BV - Wireless 63.140.213.0/24 22555 Universal Talkware Corporatio 63.143.251.0/24 22555 Universal Talkware Corporatio Complete listing at http://thyme.apnic.net/current/data-add-IANA Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:19 /9:10 /10:21 /11:58 /12:166 /13:339 /14:597 /15:1148 /16:10461 /17:4739 /18:8141 /19:17145 /20:20411 /21:20300 /22:25974 /23:25603 /24:150667 /25:901 /26:1046 /27:547 /28:161 /29:37 /30:10 /31:0 /32:8 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 6389 2802 4296 bellsouth.net, inc. 4766 1389 1698 Korea Telecom (KIX) 17488 1307 1584 Hathway IP Over Cable Interne 209 1297 2560 Qwest 8452 1170 1200 TEDATA 1785 1164 1759 PaeTec Communications, Inc. 18566 1043 1062 Covad Communications 11492 1035 1099 Cable One 2386 970 1262 AT&T Data Communications Serv 4323 951 1848 Time Warner Telecom Complete listing at http://thyme.apnic.net/current/data/sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 4:12 8:199 12:2227 13:10 15:19 16:3 17:4 20:35 24:1068 32:50 38:533 40:97 41:1952 43:1 44:2 47:22 52:4 55:2 56:3 57:25 58:581 59:642 60:459 61:1094 62:1097 63:2087 64:3690 65:2392 66:3595 67:1622 68:766 69:2605 70:532 71:146 72:1653 73:2 74:1527 75:172 76:310 77:841 78:562 79:329 80:977 81:804 82:526 83:430 84:615 85:1050 86:407 87:653 88:355 89:1440 90:57 91:2204 92:322 93:1011 94:1196 95:1217 96:124 97:208 98:218 99:22 109:1 110:119 112:120 113:104 114:256 115:288 116:1160 117:517 118:293 119:694 120:142 121:723 122:1019 123:674 124:955 125:1319 128:220 129:234 130:126 131:413 132:73 133:9 134:187 135:213 136:242 137:155 138:160 139:80 140:445 141:109 142:380 143:342 144:360 145:47 146:376 147:153 148:518 149:237 150:177 151:198 152:147 153:139 154:2 155:274 156:169 157:297 158:115 159:312 160:282 161:138 162:268 163:151 164:481 165:503 166:275 167:363 168:685 169:166 170:477 171:40 172:10 173:281 174:210 178:1 186:14 187:89 188:17 189:351 190:2631 192:5812 193:4218 194:3299 195:2698 196:1066 198:3662 199:3351 200:5305 201:1356 202:7838 203:8198 204:3815 205:2143 206:2458 207:2814 208:3913 209:3425 210:2659 211:1114 212:1521 213:1673 214:76 215:30 216:4651 217:1259 218:371 219:427 220:1214 221:472 222:295 End of report From smiley at zo.com Fri May 15 13:31:57 2009 From: smiley at zo.com (Michael Smiley) Date: Fri, 15 May 2009 11:31:57 -0700 Subject: Managing your network devices via console In-Reply-To: <6286FF05EBE33C4596F6C6C23762686701FCE20B@VS11.EXCHPROD.USA.NET> References: <2909d6d90905141929n746c29c9v88b337ee4ce981c1@mail.gmail.com> <6286FF05EBE33C4596F6C6C23762686701FCE20B@VS11.EXCHPROD.USA.NET> Message-ID: <54ea498f0905151131tda9e676h7b7532b9b0ada7dd@mail.gmail.com> I am yet another that uses and loves Cyclades in my data center. The new ACS 6000 series is what I have now, which is quite nice due to the software pin switching they have on that unit, this means no more special cisco dongles. Also part of the reason for my use of the ACS is for the integration of the Cyclades power strips, very seemless very nice. I have also used the Cisco terminal server mods in the past and they worked just fine as well, though I have no modern experience there. -smiley On Fri, May 15, 2009 at 11:04 AM, Dylan Ebner wrote: > We use Cyclades (avocent) devices in our data center. They have worked > great for us. Very reliable. Modem dial-in gives us great remote > capabilities if we have a major outage. We had troubles initially > getting them to work because the cable adapters were never pinned > correctly for Cisco. We ended up making our own rolled rj45-rj45 cables. > IIRC, this was a ton of work as you need to do some funky 2 wires in one > position stuff. > > We also use Cisco 2500's with modem on the aux and an octo-cable for the > devices. This works well too, but not as nice of an interface as the > Cyclades. No special cables needed though. > > For power we have been using APC Managed PDU's. These have been > fantastic. No compaints. > > > > > -----Original Message----- > From: Mehmet Akcin [mailto:mehmet at akcin.net] > Sent: Thursday, May 14, 2009 9:30 PM > To: nanog at nanog.org > Subject: Managing your network devices via console > > Hello, > > It's always cool to have console access to routers/switches and nowadays > they are going from RS-232 to RJ-45 as a standart. I have got Avocent > DSR 2035 which is a KVM+Serial console (all in one).. but while I was > able to have it work against servers via KVM or/and Serial , I was > unable to make it work properly against any network device. I am > wondering if anyone had experience on DSR or similar boxes to configure > them against network devices console ports. > > Making suggestions for alternative ways of centralizing network device > console management is also more than welcome, I guess the old fashioned > server attached usb-serial console is one of the most preferred way, but > feel free to provide if you have good ideas > > cheers > > -- > Mehmet > > > > From bfeeny at mac.com Fri May 15 13:33:27 2009 From: bfeeny at mac.com (Brian Feeny) Date: Fri, 15 May 2009 14:33:27 -0400 Subject: NPE-G2 vs. Sup720-3BXL In-Reply-To: <4A0D9BE2.4030701@bright.net> References: <4A0D9BE2.4030701@bright.net> Message-ID: I have used the 7304 in the past and was happy with it. In fact I still have a 6-port DS3 module for a 7304 which I need to find a home for if anyone has the need. The 7304 originally had its own specific modules that went into it. But they also sell carrier card for it so you can use standard PA's, as well as the SPA's which is nice. Overall footprint is rather nice, and I use to use those 6-port DS3 cards which allowed for hefty DS3 termination. Brian On May 15, 2009, at 12:44 PM, Aaron Millisor wrote: > We ran into a similar quandary and have about the same amount of > traffic as your network. When purchasing gear a year ago we decided > against 7200's with an NPE-G2 as insufficient for the load. Have > you looked at the 7304? > > The Cisco 7304 with an NSE-150 processing engine on it offloads a > lot of the packet processing to dedicated hardware, and doesn't have > TCAM limitations for routes. You can hold several full feeds and do > the amount of traffic you're talking about without breaking a sweat. > > http://www.cisco.com/en/US/prod/collateral/routers/ps352/prod_bulletin0900aecd8060aac5.html > > It is capable of supporting both legacy port adapters (from your > Flexwan or 7200 routers) and SPA cards with the right add-in > modules, which IIRC is only a few hundred dollars. > > I'd be glad to answer any questions you have about our implementation. > > --am > > David Storandt wrote: >> We're stuck in an engineering pickle, so some experience from this >> crew would be useful in tie-breaking... >> We operate a business-grade FTTx ISP with ~75 customers and 800Mbps >> of >> Internet traffic, currently using 6509/Sup2s for core routing and >> port >> aggregation. The MSFC2s are under stress from 3x full route feeds, >> pared down to 85% to fit the TCAM tables. One system has a FlexWAN >> with an OC3 card and it's crushing the CPU on the MSFC2. System >> tuning >> (stable IOS and esp. disabling SPD) helped a lot but still doesn't >> have the power to pull through. Hardware upgrades are needed... >> We need true full routes and more CPU horsepower for crunching BGP >> (+12 smaller peers + ISIS). OC3 interfaces are going to be mandatory, >> one each at two locations. Oh yeah, we're still a larger startup >> without endless pockets. Power, rack space, and SmartNet are not >> concerns at any location (on-site cold spares). We may need an >> upstream OC12 in the future but that's a ways out and not a concern >> here. >> Our engineering team has settled on three $20k/node options: >> - Sup720-3BXLs with PS and fan upgrades >> - Sup2s as switches + ISIS + statics and no BGP, push BGP edge >> routing >> off to NPE-G2s across a 2-3Gbps port-channel >> - Sup2s as switches + ISIS + statics and no BGP, push BGP edge >> routing >> off to a 12008 with E3 engines across a 2-3Gbps port-channel. >> Ideas and constructive opinions welcome, especially software and >> stability-related. >> Many thanks, >> -Dave > From arievayner at gmail.com Fri May 15 13:34:06 2009 From: arievayner at gmail.com (Arie Vayner) Date: Fri, 15 May 2009 21:34:06 +0300 Subject: NPE-G2 vs. Sup720-3BXL In-Reply-To: References: Message-ID: <20b13c6b0905151134y3e77ed6ele043dad1ae107079@mail.gmail.com> David, My 1st advice would be to look also at the other features/capabilities you require, and not just at "feeds and speeds". Some examples for functionality could be: - QOS - NetFlow - DDoS resistance In general the 6500 and the 12000 are hardware based platforms, with the 12000 being more distributed in nature, using linecard resources for data plane (6500 does it too if you have DFC installed). 7200 is a CPU/software based platform, so the same processor does packet forwarding and control plane processing. The 6500 (depends on specific module selection) is more restricted with QOS and NetFlow functionality as it is designed to do very fast forwarding at a relativly cheaper price. The 12000 has everything implemented in hardware, and depends on the engine types (don't use anything other than Eng 3 or 5) has all the support you may dream of for things like QOS and other features. The 7200 is a software based router, which means that it support any feature you may ever dream of, but the scalability decreases as you turn them on. Another option you should consider seriously should be the ASR1000 router, which is a newer platform and has a new architecture. All its features are based on hardware support, and it could actually prove the best choice for what you need. The ASR1002 comes with 4 integrated 1GE ports, which could be all that you would ever need (but it has quite a few extension slots left). Arie On Fri, May 15, 2009 at 6:07 PM, David Storandt wrote: > We're stuck in an engineering pickle, so some experience from this > crew would be useful in tie-breaking... > > We operate a business-grade FTTx ISP with ~75 customers and 800Mbps of > Internet traffic, currently using 6509/Sup2s for core routing and port > aggregation. The MSFC2s are under stress from 3x full route feeds, > pared down to 85% to fit the TCAM tables. One system has a FlexWAN > with an OC3 card and it's crushing the CPU on the MSFC2. System tuning > (stable IOS and esp. disabling SPD) helped a lot but still doesn't > have the power to pull through. Hardware upgrades are needed... > > We need true full routes and more CPU horsepower for crunching BGP > (+12 smaller peers + ISIS). OC3 interfaces are going to be mandatory, > one each at two locations. Oh yeah, we're still a larger startup > without endless pockets. Power, rack space, and SmartNet are not > concerns at any location (on-site cold spares). We may need an > upstream OC12 in the future but that's a ways out and not a concern > here. > > Our engineering team has settled on three $20k/node options: > - Sup720-3BXLs with PS and fan upgrades > - Sup2s as switches + ISIS + statics and no BGP, push BGP edge routing > off to NPE-G2s across a 2-3Gbps port-channel > - Sup2s as switches + ISIS + statics and no BGP, push BGP edge routing > off to a 12008 with E3 engines across a 2-3Gbps port-channel. > > Ideas and constructive opinions welcome, especially software and > stability-related. > > Many thanks, > -Dave > > From knaidoo at juniper.net Fri May 15 13:30:10 2009 From: knaidoo at juniper.net (Kesva Naidoo) Date: Fri, 15 May 2009 14:30:10 -0400 Subject: NANOG Digest, Vol 16, Issue 60 In-Reply-To: References: Message-ID: <77D2D9C3392DC14BB36CE911D5F44C7302B73984@emailwf2.jnpr.net> I would not like to punt another vendor's equipment but have you looked at the MX-480 or MX-960. You would not have to worry about CPU limitations and it is an Internet core box capable of handling all the protocols. Kesva -----Original Message----- From: nanog-request at nanog.org [mailto:nanog-request at nanog.org] Sent: Friday, May 15, 2009 2:16 PM To: nanog at nanog.org Subject: NANOG Digest, Vol 16, Issue 60 Send NANOG mailing list submissions to nanog at nanog.org To subscribe or unsubscribe via the World Wide Web, visit http://mailman.nanog.org/mailman/listinfo/nanog or, via email, send a message with subject or body 'help' to nanog-request at nanog.org You can reach the person managing the list at nanog-owner at nanog.org When replying, please edit your Subject line so it is more specific than "Re: Contents of NANOG digest..." Today's Topics: 1. RE: NPE-G2 vs. Sup720-3BXL (Leland E. Vandervort) 2. Re: NPE-G2 vs. Sup720-3BXL (Aaron Millisor) 3. Re: NPE-G2 vs. Sup720-3BXL (Alex H. Ryu) 4. Re: NPE-G2 vs. Sup720-3BXL (David Storandt) 5. Re: you're not interesting, was Re: another brick in the wall[ed garden] (Owen DeLong) 6. RE: Managing your network devices via console (Dylan Ebner) 7. Weekly Routing Table Report (Routing Analysis Role Account) ---------------------------------------------------------------------- Message: 1 Date: Fri, 15 May 2009 16:21:23 +0000 (GMT) From: "Leland E. Vandervort" Subject: RE: NPE-G2 vs. Sup720-3BXL To: Paul Stewart Cc: NANOG list Message-ID: Content-Type: TEXT/PLAIN; charset=US-ASCII We're running several six 65xx Sup720-3BXL with 3 full transit views and some 40-odd peers. We use two NPE-G1s for reflectors and some policy manipulation. Also running MPLS in the core to allow for traffic engineering and EoMPLS between certain services located in different locations. We're pushing up to between 800M and 1G at peak times (mostly outbound) with this setup and peak CPU on the 3BXLs is running maybe 30% -- average though of around 8 to 10%. Hope this helps.... side-note: I'm actually more worried about the distribution layer at the moment as it relies heavily on STP and HSRP/GLBP for the various vlans and access layer gunk. Currently these are 720-3B (non-XL), but looking eventually to build a business case to upgrade these to VSS1440 to simplify the architecture as well as providing better resilience and elimination of STP/HSRP/GLBP limitations between the dist and access layers. Problem is the budget side of that... blargh! Ideally I'd like to go more for the Nexus platform for this part of the network, given that we're doing a lot of virtualisation etc., but the downsides with that are primarily the COST of the bloody things, and secondly the fact that they don't currently support MPLS (planned for later this year, apparently). Leland On Fri, 15 May 2009, Paul Stewart wrote: > We've never pushed a NPE-G2 to 800Mb/s before but I would think they > would topple over... hopefully someone on here could confirm my > statement? > > Moving the BGP to the 12008's would be my choice with PRP-2 processors > if the budget fits.... we're faced with a similar upgrade next year > possibly moving BGP from a pair of 7606's (Sup720-3BXL) over to a pair > of GSR's running PRP2 I think - the BGP processing etc. is pushing the > CPU's too high on the 7600's.... > > Someone else might suggest the RSP720's but haven't had them in a > production environment yet... we had PRP2's running on 12012 for a > while and found them rock solid even with older line cards etc... > > Hope this helps a bit...;) > > Paul > > > -----Original Message----- > From: David Storandt [mailto:dstorandt at teljet.com] > Sent: Friday, May 15, 2009 11:08 AM > To: NANOG list > Subject: NPE-G2 vs. Sup720-3BXL > > We're stuck in an engineering pickle, so some experience from this > crew would be useful in tie-breaking... > > We operate a business-grade FTTx ISP with ~75 customers and 800Mbps of > Internet traffic, currently using 6509/Sup2s for core routing and port > aggregation. The MSFC2s are under stress from 3x full route feeds, > pared down to 85% to fit the TCAM tables. One system has a FlexWAN > with an OC3 card and it's crushing the CPU on the MSFC2. System tuning > (stable IOS and esp. disabling SPD) helped a lot but still doesn't > have the power to pull through. Hardware upgrades are needed... > > We need true full routes and more CPU horsepower for crunching BGP > (+12 smaller peers + ISIS). OC3 interfaces are going to be mandatory, > one each at two locations. Oh yeah, we're still a larger startup > without endless pockets. Power, rack space, and SmartNet are not > concerns at any location (on-site cold spares). We may need an > upstream OC12 in the future but that's a ways out and not a concern > here. > > Our engineering team has settled on three $20k/node options: > - Sup720-3BXLs with PS and fan upgrades > - Sup2s as switches + ISIS + statics and no BGP, push BGP edge routing > off to NPE-G2s across a 2-3Gbps port-channel > - Sup2s as switches + ISIS + statics and no BGP, push BGP edge routing > off to a 12008 with E3 engines across a 2-3Gbps port-channel. > > Ideas and constructive opinions welcome, especially software and > stability-related. > > Many thanks, > -Dave > > > > > > ------------------------------------------------------------------------ ---- > > "The information transmitted is intended only for the person or entity to which it is addressed and contains confidential and/or privileged material. If you received this in error, please contact the sender immediately and then destroy this transmission, including all attachments, without copying, distributing or disclosing same. Thank you." > > ------------------------------ Message: 2 Date: Fri, 15 May 2009 12:44:18 -0400 From: Aaron Millisor Subject: Re: NPE-G2 vs. Sup720-3BXL To: David Storandt Cc: NANOG list Message-ID: <4A0D9BE2.4030701 at bright.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed We ran into a similar quandary and have about the same amount of traffic as your network. When purchasing gear a year ago we decided against 7200's with an NPE-G2 as insufficient for the load. Have you looked at the 7304? The Cisco 7304 with an NSE-150 processing engine on it offloads a lot of the packet processing to dedicated hardware, and doesn't have TCAM limitations for routes. You can hold several full feeds and do the amount of traffic you're talking about without breaking a sweat. http://www.cisco.com/en/US/prod/collateral/routers/ps352/prod_bulletin09 00aecd8060aac5.html It is capable of supporting both legacy port adapters (from your Flexwan or 7200 routers) and SPA cards with the right add-in modules, which IIRC is only a few hundred dollars. I'd be glad to answer any questions you have about our implementation. --am David Storandt wrote: > We're stuck in an engineering pickle, so some experience from this > crew would be useful in tie-breaking... > > We operate a business-grade FTTx ISP with ~75 customers and 800Mbps of > Internet traffic, currently using 6509/Sup2s for core routing and port > aggregation. The MSFC2s are under stress from 3x full route feeds, > pared down to 85% to fit the TCAM tables. One system has a FlexWAN > with an OC3 card and it's crushing the CPU on the MSFC2. System tuning > (stable IOS and esp. disabling SPD) helped a lot but still doesn't > have the power to pull through. Hardware upgrades are needed... > > We need true full routes and more CPU horsepower for crunching BGP > (+12 smaller peers + ISIS). OC3 interfaces are going to be mandatory, > one each at two locations. Oh yeah, we're still a larger startup > without endless pockets. Power, rack space, and SmartNet are not > concerns at any location (on-site cold spares). We may need an > upstream OC12 in the future but that's a ways out and not a concern > here. > > Our engineering team has settled on three $20k/node options: > - Sup720-3BXLs with PS and fan upgrades > - Sup2s as switches + ISIS + statics and no BGP, push BGP edge routing > off to NPE-G2s across a 2-3Gbps port-channel > - Sup2s as switches + ISIS + statics and no BGP, push BGP edge routing > off to a 12008 with E3 engines across a 2-3Gbps port-channel. > > Ideas and constructive opinions welcome, especially software and > stability-related. > > Many thanks, > -Dave ------------------------------ Message: 3 Date: Fri, 15 May 2009 11:51:50 -0500 From: "Alex H. Ryu" Subject: Re: NPE-G2 vs. Sup720-3BXL To: Aaron Millisor Cc: NANOG list Message-ID: <4A0D9DA6.9020604 at ieee.org> Content-Type: text/plain; charset=EUC-KR Cisco 7304 may not adequate for service provider. It's CPU/IO-controller is tied together, and doesn't provide much of benefit. Cisco 7200/7300 is enterprise solution pretty much, and doesn't support distributed CEF. If you are considering SUP720-3BXL, why not considering RSP720-3CXL ? Alex Aaron Millisor wrote: > We ran into a similar quandary and have about the same amount of > traffic as your network. When purchasing gear a year ago we decided > against 7200's with an NPE-G2 as insufficient for the load. Have you > looked at the 7304? > > The Cisco 7304 with an NSE-150 processing engine on it offloads a lot > of the packet processing to dedicated hardware, and doesn't have TCAM > limitations for routes. You can hold several full feeds and do the > amount of traffic you're talking about without breaking a sweat. > > http://www.cisco.com/en/US/prod/collateral/routers/ps352/prod_bulletin09 00aecd8060aac5.html > > > It is capable of supporting both legacy port adapters (from your > Flexwan or 7200 routers) and SPA cards with the right add-in modules, > which IIRC is only a few hundred dollars. > > I'd be glad to answer any questions you have about our implementation. > > --am > > David Storandt wrote: >> We're stuck in an engineering pickle, so some experience from this >> crew would be useful in tie-breaking... >> >> We operate a business-grade FTTx ISP with ~75 customers and 800Mbps of >> Internet traffic, currently using 6509/Sup2s for core routing and port >> aggregation. The MSFC2s are under stress from 3x full route feeds, >> pared down to 85% to fit the TCAM tables. One system has a FlexWAN >> with an OC3 card and it's crushing the CPU on the MSFC2. System tuning >> (stable IOS and esp. disabling SPD) helped a lot but still doesn't >> have the power to pull through. Hardware upgrades are needed... >> >> We need true full routes and more CPU horsepower for crunching BGP >> (+12 smaller peers + ISIS). OC3 interfaces are going to be mandatory, >> one each at two locations. Oh yeah, we're still a larger startup >> without endless pockets. Power, rack space, and SmartNet are not >> concerns at any location (on-site cold spares). We may need an >> upstream OC12 in the future but that's a ways out and not a concern >> here. >> >> Our engineering team has settled on three $20k/node options: >> - Sup720-3BXLs with PS and fan upgrades >> - Sup2s as switches + ISIS + statics and no BGP, push BGP edge routing >> off to NPE-G2s across a 2-3Gbps port-channel >> - Sup2s as switches + ISIS + statics and no BGP, push BGP edge routing >> off to a 12008 with E3 engines across a 2-3Gbps port-channel. >> >> Ideas and constructive opinions welcome, especially software and >> stability-related. >> >> Many thanks, >> -Dave > > > ------------------------------ Message: 4 Date: Fri, 15 May 2009 13:23:08 -0400 From: David Storandt Subject: Re: NPE-G2 vs. Sup720-3BXL To: "Alex H. Ryu" Cc: NANOG list Message-ID: Content-Type: text/plain; charset=ISO-8859-1 I would love to use the RSP720-3CXL, but cost and the PA OC3 are the difficulties. If the RSP720s will run in a 6500 chassis, great! We wouldn't have to purchase new chassis and the increased downtime for the swap-out. RSP720 don't support the older bus-only FlexWAN either with the OC3 PA we're using, so we'd have to figure out a solution for that - SIPs, Enhanced FlexWAN, or external routers. Bah. ...the RSP720s + chassis + OC3 solution more than double our $20k/node budget, so that's a much tougher sell internally. -Dave 2009/5/15 Alex H. Ryu : > Cisco 7304 may not adequate for service provider. > It's CPU/IO-controller is tied together, and doesn't provide much of > benefit. > > Cisco 7200/7300 is enterprise solution pretty much, and doesn't support > distributed CEF. > > If you are considering SUP720-3BXL, why not considering RSP720-3CXL ? > > Alex > > > Aaron Millisor wrote: >> We ran into a similar quandary and have about the same amount of >> traffic as your network. When purchasing gear a year ago we decided >> against 7200's with an NPE-G2 as insufficient for the load. Have you >> looked at the 7304? >> >> The Cisco 7304 with an NSE-150 processing engine on it offloads a lot >> of the packet processing to dedicated hardware, and doesn't have TCAM >> limitations for routes. You can hold several full feeds and do the >> amount of traffic you're talking about without breaking a sweat. >> >> http://www.cisco.com/en/US/prod/collateral/routers/ps352/prod_bulletin09 00aecd8060aac5.html >> >> >> It is capable of supporting both legacy port adapters (from your >> Flexwan or 7200 routers) and SPA cards with the right add-in modules, >> which IIRC is only a few hundred dollars. >> >> I'd be glad to answer any questions you have about our implementation. >> >> --am >> >> David Storandt wrote: >>> We're stuck in an engineering pickle, so some experience from this >>> crew would be useful in tie-breaking... >>> >>> We operate a business-grade FTTx ISP with ~75 customers and 800Mbps of >>> Internet traffic, currently using 6509/Sup2s for core routing and port >>> aggregation. The MSFC2s are under stress from 3x full route feeds, >>> pared down to 85% to fit the TCAM tables. One system has a FlexWAN >>> with an OC3 card and it's crushing the CPU on the MSFC2. System tuning >>> (stable IOS and esp. disabling SPD) helped a lot but still doesn't >>> have the power to pull through. Hardware upgrades are needed... >>> >>> We need true full routes and more CPU horsepower for crunching BGP >>> (+12 smaller peers + ISIS). OC3 interfaces are going to be mandatory, >>> one each at two locations. Oh yeah, we're still a larger startup >>> without endless pockets. Power, rack space, and SmartNet are not >>> concerns at any location (on-site cold spares). We may need an >>> upstream OC12 in the future but that's a ways out and not a concern >>> here. >>> >>> Our engineering team has settled on three $20k/node options: >>> - Sup720-3BXLs with PS and fan upgrades >>> - Sup2s as switches + ISIS + statics and no BGP, push BGP edge routing >>> off to NPE-G2s across a 2-3Gbps port-channel >>> - Sup2s as switches + ISIS + statics and no BGP, push BGP edge routing >>> off to a 12008 with E3 engines across a 2-3Gbps port-channel. >>> >>> Ideas and constructive opinions welcome, especially software and >>> stability-related. >>> >>> Many thanks, >>> -Dave >> >> >> > > ------------------------------ Message: 5 Date: Fri, 15 May 2009 10:34:14 -0700 From: Owen DeLong Subject: Re: you're not interesting, was Re: another brick in the wall[ed garden] To: Mans Nilsson Cc: Mark Andrews , nanog at nanog.org, rs at seastrom.com Message-ID: <9D559FD4-F4C4-48F8-9385-CAB92C0AD863 at delong.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes On May 14, 2009, at 10:07 PM, Mans Nilsson wrote: > Subject: Re: you're not interesting, was Re: another brick in the > wall[ed garden] Date: Fri, May 15, 2009 at 09:58:32AM +1000 Quoting > Mark Andrews (Mark_Andrews at isc.org): >> And what's the next protocol that is going to be stomped on? > > Anything except http; at which point everything will move to http, and > the firewalls are again useless. > This is, indeed, already happening. In fact, I'm running an SMTP server with TLS on port 80 to get around SPRINT's existing braindamage. (or at least the braindamage they had at one point). Owen > -- > M?ns Nilsson > > ------------------------------ Message: 6 Date: Fri, 15 May 2009 12:04:47 -0600 From: "Dylan Ebner" Subject: RE: Managing your network devices via console To: "Mehmet Akcin" Cc: nanog at nanog.org Message-ID: <6286FF05EBE33C4596F6C6C23762686701FCE20B at VS11.EXCHPROD.USA.NET> Content-Type: text/plain; charset="us-ascii" We use Cyclades (avocent) devices in our data center. They have worked great for us. Very reliable. Modem dial-in gives us great remote capabilities if we have a major outage. We had troubles initially getting them to work because the cable adapters were never pinned correctly for Cisco. We ended up making our own rolled rj45-rj45 cables. IIRC, this was a ton of work as you need to do some funky 2 wires in one position stuff. We also use Cisco 2500's with modem on the aux and an octo-cable for the devices. This works well too, but not as nice of an interface as the Cyclades. No special cables needed though. For power we have been using APC Managed PDU's. These have been fantastic. No compaints. -----Original Message----- From: Mehmet Akcin [mailto:mehmet at akcin.net] Sent: Thursday, May 14, 2009 9:30 PM To: nanog at nanog.org Subject: Managing your network devices via console Hello, It's always cool to have console access to routers/switches and nowadays they are going from RS-232 to RJ-45 as a standart. I have got Avocent DSR 2035 which is a KVM+Serial console (all in one).. but while I was able to have it work against servers via KVM or/and Serial , I was unable to make it work properly against any network device. I am wondering if anyone had experience on DSR or similar boxes to configure them against network devices console ports. Making suggestions for alternative ways of centralizing network device console management is also more than welcome, I guess the old fashioned server attached usb-serial console is one of the most preferred way, but feel free to provide if you have good ideas cheers -- Mehmet ------------------------------ Message: 7 Date: Sat, 16 May 2009 04:15:49 +1000 (EST) From: Routing Analysis Role Account Subject: Weekly Routing Table Report To: apops at apops.net, nanog at nanog.org, routing-wg at ripe.net, afnog at afnog.org, ausnog at ausnog.net, sanog at sanog.org Message-ID: <200905151815.n4FIFnE5005086 at thyme.apnic.net> This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. Daily listings are sent to bgp-stats at lists.apnic.net For historical data, please see http://thyme.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 16 May, 2009 Report Website: http://thyme.apnic.net Detailed Analysis: http://thyme.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 288509 Prefixes after maximum aggregation: 136412 Deaggregation factor: 2.11 Unique aggregates announced to Internet: 141329 Total ASes present in the Internet Routing Table: 31265 Prefixes per ASN: 9.23 Origin-only ASes present in the Internet Routing Table: 27181 Origin ASes announcing only one prefix: 13271 Transit ASes present in the Internet Routing Table: 4084 Transit-only ASes present in the Internet Routing Table: 93 Average AS path length visible in the Internet Routing Table: 3.6 Max AS path length visible: 33 Max AS path prepend of ASN (43683) 31 Prefixes from unregistered ASNs in the Routing Table: 464 Unregistered ASNs in the Routing Table: 151 Number of 32-bit ASNs allocated by the RIRs: 144 Prefixes from 32-bit ASNs in the Routing Table: 33 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 217 Number of addresses announced to Internet: 2045653328 Equivalent to 121 /8s, 238 /16s and 49 /24s Percentage of available address space announced: 55.2 Percentage of allocated address space announced: 63.9 Percentage of available address space allocated: 86.4 Percentage of address space in use by end-sites: 77.0 Total number of prefixes smaller than registry allocations: 142688 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 67654 Total APNIC prefixes after maximum aggregation: 24179 APNIC Deaggregation factor: 2.80 Prefixes being announced from the APNIC address blocks: 64332 Unique aggregates announced from the APNIC address blocks: 29021 APNIC Region origin ASes present in the Internet Routing Table: 3628 APNIC Prefixes per ASN: 17.73 APNIC Region origin ASes announcing only one prefix: 990 APNIC Region transit ASes present in the Internet Routing Table: 559 Average APNIC Region AS path length visible: 3.5 Max APNIC Region AS path length visible: 18 Number of APNIC addresses announced to Internet: 413775280 Equivalent to 24 /8s, 169 /16s and 181 /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 APNIC Address Blocks 58/8, 59/8, 60/8, 61/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 180/8, 183/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 125540 Total ARIN prefixes after maximum aggregation: 66187 ARIN Deaggregation factor: 1.90 Prefixes being announced from the ARIN address blocks: 94652 Unique aggregates announced from the ARIN address blocks: 36596 ARIN Region origin ASes present in the Internet Routing Table: 12997 ARIN Prefixes per ASN: 7.28 ARIN Region origin ASes announcing only one prefix: 5002 ARIN Region transit ASes present in the Internet Routing Table: 1272 Average ARIN Region AS path length visible: 3.3 Max ARIN Region AS path length visible: 24 Number of ARIN addresses announced to Internet: 428644608 Equivalent to 25 /8s, 140 /16s and 153 /24s Percentage of available ARIN address space announced: 82.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 ARIN Address Blocks 24/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8, 98/8, 99/8, 108/8, 173/8, 174/8, 184/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 66135 Total RIPE prefixes after maximum aggregation: 38352 RIPE Deaggregation factor: 1.72 Prefixes being announced from the RIPE address blocks: 60448 Unique aggregates announced from the RIPE address blocks: 40229 RIPE Region origin ASes present in the Internet Routing Table: 13009 RIPE Prefixes per ASN: 4.65 RIPE Region origin ASes announcing only one prefix: 6825 RIPE Region transit ASes present in the Internet Routing Table: 1961 Average RIPE Region AS path length visible: 4.0 Max RIPE Region AS path length visible: 33 Number of RIPE addresses announced to Internet: 393701408 Equivalent to 23 /8s, 119 /16s and 104 /24s Percentage of available RIPE address space announced: 83.8 RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-52223 RIPE Address Blocks 62/8, 77/8, 78/8, 79/8, 80/8, 81/8, 82/8, 83/8, 84/8, 85/8, 86/8, 87/8, 88/8, 89/8, 90/8, 91/8, 92/8, 93/8, 94/8, 95/8, 109/8, 178/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 23824 Total LACNIC prefixes after maximum aggregation: 5887 LACNIC Deaggregation factor: 4.05 Prefixes being announced from the LACNIC address blocks: 21985 Unique aggregates announced from the LACNIC address blocks: 12186 LACNIC Region origin ASes present in the Internet Routing Table: 1107 LACNIC Prefixes per ASN: 19.86 LACNIC Region origin ASes announcing only one prefix: 362 LACNIC Region transit ASes present in the Internet Routing Table: 187 Average LACNIC Region AS path length visible: 4.1 Max LACNIC Region AS path length visible: 19 Number of LACNIC addresses announced to Internet: 63251840 Equivalent to 3 /8s, 197 /16s and 37 /24s Percentage of available LACNIC address space announced: 62.8 LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247 plus ERX transfers LACNIC Address Blocks 186/8, 187/8, 189/8, 190/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 4925 Total AfriNIC prefixes after maximum aggregation: 1468 AfriNIC Deaggregation factor: 3.35 Prefixes being announced from the AfriNIC address blocks: 4540 Unique aggregates announced from the AfriNIC address blocks: 1384 AfriNIC Region origin ASes present in the Internet Routing Table: 299 AfriNIC Prefixes per ASN: 15.18 AfriNIC Region origin ASes announcing only one prefix: 92 AfriNIC Region transit ASes present in the Internet Routing Table: 60 Average AfriNIC Region AS path length visible: 3.9 Max AfriNIC Region AS path length visible: 18 Number of AfriNIC addresses announced to Internet: 11359232 Equivalent to 0 /8s, 173 /16s and 84 /24s Percentage of available AfriNIC address space announced: 33.9 AfriNIC AS Blocks 36864-37887 & ERX transfers AfriNIC Address Blocks 41/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4766 1698 6930 403 Korea Telecom (KIX) 17488 1584 128 104 Hathway IP Over Cable Interne 4755 1247 466 128 TATA Communications formerly 9583 1079 86 541 Sify Limited 4134 887 16660 372 CHINANET-BACKBONE 23577 780 34 662 Korea Telecom (ATM-MPLS) 7545 772 198 103 TPG Internet Pty Ltd 18101 754 217 32 Reliance Infocom Ltd Internet 24560 689 229 179 Bharti Airtel Ltd. 9829 670 561 14 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 4296 3647 324 bellsouth.net, inc. 209 2560 4149 607 Qwest 4323 1848 1035 373 Time Warner Telecom 1785 1759 717 139 PaeTec Communications, Inc. 20115 1627 1444 720 Charter Communications 7018 1490 5914 1024 AT&T WorldNet Services 6478 1404 310 400 AT&T Worldnet Services 2386 1262 697 915 AT&T Data Communications Serv 3356 1224 10981 461 Level 3 Communications, LLC 11492 1099 192 11 Cable One Complete listing at http://thyme.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 8452 1200 188 7 TEDATA 30890 542 88 201 Evolva Telecom 3292 455 1893 393 TDC Tele Danmark 12479 449 578 6 Uni2 Autonomous System 8866 382 110 24 Bulgarian Telecommunication C 3320 349 7082 300 Deutsche Telekom AG 3215 343 3041 108 France Telecom Transpac 3301 340 1668 304 TeliaNet Sweden 35805 328 24 4 United Telecom of Georgia 29049 316 26 3 AzerSat LLC. Complete listing at http://thyme.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 8151 1449 2862 231 UniNet S.A. de C.V. 10620 906 207 108 TVCABLE BOGOTA 22047 610 302 14 VTR PUNTO NET S.A. 7303 529 274 75 Telecom Argentina Stet-France 11830 516 294 34 Instituto Costarricense de El 28573 464 562 26 NET Servicos de Comunicao S.A 6471 443 96 32 ENTEL CHILE S.A. 11172 443 102 72 Servicios Alestra S.A de C.V 7738 397 794 28 Telecomunicacoes da Bahia S.A 3816 351 163 74 Empresa Nacional de Telecomun Complete listing at http://thyme.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 24863 860 79 37 LINKdotNET AS number 20858 308 34 5 This AS will be used to conne 3741 278 860 238 The Internet Solution 2018 243 215 143 Tertiary Education Network 6713 160 151 12 Itissalat Al-MAGHRIB 29571 139 15 9 Ci Telecom Autonomous system 5536 123 8 9 Internet Egypt Network 33776 116 6 7 Starcomms Nigeria Limited 5713 113 507 64 Telkom SA Ltd 24835 107 46 9 RAYA Telecom - Egypt 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 4296 3647 324 bellsouth.net, inc. 209 2560 4149 607 Qwest 4323 1848 1035 373 Time Warner Telecom 1785 1759 717 139 PaeTec Communications, Inc. 4766 1698 6930 403 Korea Telecom (KIX) 20115 1627 1444 720 Charter Communications 17488 1584 128 104 Hathway IP Over Cable Interne 7018 1490 5914 1024 AT&T WorldNet Services 8151 1449 2862 231 UniNet S.A. de C.V. 6478 1404 310 400 AT&T Worldnet Services Complete listing at http://thyme.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 209 2560 1953 Qwest 1785 1759 1620 PaeTec Communications, Inc. 17488 1584 1480 Hathway IP Over Cable Interne 4323 1848 1475 Time Warner Telecom 4766 1698 1295 Korea Telecom (KIX) 8151 1449 1218 UniNet S.A. de C.V. 8452 1200 1193 TEDATA 4755 1247 1119 TATA Communications formerly 11492 1099 1088 Cable One 18566 1062 1052 Covad Communications Complete listing at http://thyme.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 16927 UNALLOCATED 12.0.252.0/23 7018 AT&T WorldNet Servic 15132 UNALLOCATED 12.9.150.0/24 7018 AT&T WorldNet Servic 32567 UNALLOCATED 12.14.170.0/24 7018 AT&T WorldNet Servic 13746 UNALLOCATED 12.24.56.0/24 7018 AT&T WorldNet Servic 32567 UNALLOCATED 12.25.107.0/24 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.152.0/24 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.154.0/23 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.159.0/24 7018 AT&T WorldNet Servic 32326 UNALLOCATED 12.40.49.0/24 7018 AT&T WorldNet Servic 25639 UNALLOCATED 12.41.169.0/24 7018 AT&T WorldNet Servic Complete listing at http://thyme.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 24.246.0.0/17 7018 AT&T WorldNet Services 24.246.128.0/18 7018 AT&T WorldNet Services 41.223.112.0/22 5713 Telkom SA Ltd 41.223.176.0/22 36981 >>UNKNOWN<< 41.223.188.0/24 22351 Intelsat 41.223.189.0/24 26452 Local Communications Networks 62.61.220.0/24 24974 Tachyon Europe BV - Wireless 62.61.221.0/24 24974 Tachyon Europe BV - Wireless 63.140.213.0/24 22555 Universal Talkware Corporatio 63.143.251.0/24 22555 Universal Talkware Corporatio Complete listing at http://thyme.apnic.net/current/data-add-IANA Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:19 /9:10 /10:21 /11:58 /12:166 /13:339 /14:597 /15:1148 /16:10461 /17:4739 /18:8141 /19:17145 /20:20411 /21:20300 /22:25974 /23:25603 /24:150667 /25:901 /26:1046 /27:547 /28:161 /29:37 /30:10 /31:0 /32:8 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 6389 2802 4296 bellsouth.net, inc. 4766 1389 1698 Korea Telecom (KIX) 17488 1307 1584 Hathway IP Over Cable Interne 209 1297 2560 Qwest 8452 1170 1200 TEDATA 1785 1164 1759 PaeTec Communications, Inc. 18566 1043 1062 Covad Communications 11492 1035 1099 Cable One 2386 970 1262 AT&T Data Communications Serv 4323 951 1848 Time Warner Telecom Complete listing at http://thyme.apnic.net/current/data/sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 4:12 8:199 12:2227 13:10 15:19 16:3 17:4 20:35 24:1068 32:50 38:533 40:97 41:1952 43:1 44:2 47:22 52:4 55:2 56:3 57:25 58:581 59:642 60:459 61:1094 62:1097 63:2087 64:3690 65:2392 66:3595 67:1622 68:766 69:2605 70:532 71:146 72:1653 73:2 74:1527 75:172 76:310 77:841 78:562 79:329 80:977 81:804 82:526 83:430 84:615 85:1050 86:407 87:653 88:355 89:1440 90:57 91:2204 92:322 93:1011 94:1196 95:1217 96:124 97:208 98:218 99:22 109:1 110:119 112:120 113:104 114:256 115:288 116:1160 117:517 118:293 119:694 120:142 121:723 122:1019 123:674 124:955 125:1319 128:220 129:234 130:126 131:413 132:73 133:9 134:187 135:213 136:242 137:155 138:160 139:80 140:445 141:109 142:380 143:342 144:360 145:47 146:376 147:153 148:518 149:237 150:177 151:198 152:147 153:139 154:2 155:274 156:169 157:297 158:115 159:312 160:282 161:138 162:268 163:151 164:481 165:503 166:275 167:363 168:685 169:166 170:477 171:40 172:10 173:281 174:210 178:1 186:14 187:89 188:17 189:351 190:2631 192:5812 193:4218 194:3299 195:2698 196:1066 198:3662 199:3351 200:5305 201:1356 202:7838 203:8198 204:3815 205:2143 206:2458 207:2814 208:3913 209:3425 210:2659 211:1114 212:1521 213:1673 214:76 215:30 216:4651 217:1259 218:371 219:427 220:1214 221:472 222:295 End of report ------------------------------ _______________________________________________ NANOG mailing list NANOG at nanog.org http://mailman.nanog.org/mailman/listinfo/nanog End of NANOG Digest, Vol 16, Issue 60 ************************************* From Sam.Crooks at experian.com Fri May 15 13:41:16 2009 From: Sam.Crooks at experian.com (Crooks, Sam) Date: Fri, 15 May 2009 13:41:16 -0500 Subject: NPE-G2 vs. Sup720-3BXL In-Reply-To: <20b13c6b0905151134y3e77ed6ele043dad1ae107079@mail.gmail.com> Message-ID: You may also take a look at the Cisco ASR1000 line... Supposedly a middle step between 7200 and 7600 router sizing.. > -----Original Message----- > From: Arie Vayner [mailto:arievayner at gmail.com] > Sent: Friday, May 15, 2009 1:34 PM > To: David Storandt > Cc: NANOG list > Subject: Re: NPE-G2 vs. Sup720-3BXL > > David, > > My 1st advice would be to look also at the other > features/capabilities you require, and not just at "feeds and speeds". > > Some examples for functionality could be: > - QOS > - NetFlow > - DDoS resistance > > In general the 6500 and the 12000 are hardware based > platforms, with the 12000 being more distributed in nature, > using linecard resources for data plane (6500 does it too if > you have DFC installed). 7200 is a CPU/software based > platform, so the same processor does packet forwarding and > control plane processing. > > The 6500 (depends on specific module selection) is more > restricted with QOS and NetFlow functionality as it is > designed to do very fast forwarding at a relativly cheaper price. > The 12000 has everything implemented in hardware, and depends > on the engine types (don't use anything other than Eng 3 or > 5) has all the support you may dream of for things like QOS > and other features. > The 7200 is a software based router, which means that it > support any feature you may ever dream of, but the > scalability decreases as you turn them on. > > Another option you should consider seriously should be the > ASR1000 router, which is a newer platform and has a new > architecture. All its features are based on hardware support, > and it could actually prove the best choice for what you need. > The ASR1002 comes with 4 integrated 1GE ports, which could be > all that you would ever need (but it has quite a few > extension slots left). > > Arie > > On Fri, May 15, 2009 at 6:07 PM, David Storandt > wrote: > > > We're stuck in an engineering pickle, so some experience from this > > crew would be useful in tie-breaking... > > > > We operate a business-grade FTTx ISP with ~75 customers and > 800Mbps of > > Internet traffic, currently using 6509/Sup2s for core > routing and port > > aggregation. The MSFC2s are under stress from 3x full route feeds, > > pared down to 85% to fit the TCAM tables. One system has a FlexWAN > > with an OC3 card and it's crushing the CPU on the MSFC2. > System tuning > > (stable IOS and esp. disabling SPD) helped a lot but still doesn't > > have the power to pull through. Hardware upgrades are needed... > > > > We need true full routes and more CPU horsepower for crunching BGP > > (+12 smaller peers + ISIS). OC3 interfaces are going to be > mandatory, > > one each at two locations. Oh yeah, we're still a larger startup > > without endless pockets. Power, rack space, and SmartNet are not > > concerns at any location (on-site cold spares). We may need an > > upstream OC12 in the future but that's a ways out and not a concern > > here. > > > > Our engineering team has settled on three $20k/node options: > > - Sup720-3BXLs with PS and fan upgrades > > - Sup2s as switches + ISIS + statics and no BGP, push BGP > edge routing > > off to NPE-G2s across a 2-3Gbps port-channel > > - Sup2s as switches + ISIS + statics and no BGP, push BGP > edge routing > > off to a 12008 with E3 engines across a 2-3Gbps port-channel. > > > > Ideas and constructive opinions welcome, especially software and > > stability-related. > > > > Many thanks, > > -Dave > > > > > From mehmet at akcin.net Fri May 15 14:30:54 2009 From: mehmet at akcin.net (Mehmet Akcin) Date: Fri, 15 May 2009 12:30:54 -0700 Subject: Managing your network devices via console In-Reply-To: <6286FF05EBE33C4596F6C6C23762686701FCE20B@VS11.EXCHPROD.USA.NET> References: <2909d6d90905141929n746c29c9v88b337ee4ce981c1@mail.gmail.com> <6286FF05EBE33C4596F6C6C23762686701FCE20B@VS11.EXCHPROD.USA.NET> Message-ID: <2909d6d90905151230k2d4e2630lb08a49f657164cd6@mail.gmail.com> Thanks everyone for the answers... It came down to a point where, just sticking a male-to-male null modem in between made this work at 9600 =) I guess sometimes solutions are way easier than we may think, heh. Mehmet On Fri, May 15, 2009 at 11:04 AM, Dylan Ebner wrote: > We use Cyclades (avocent) devices in our data center. They have worked > great for us. Very reliable. Modem dial-in gives us great remote > capabilities if we have a major outage. We had troubles initially > getting them to work because the cable adapters were never pinned > correctly for Cisco. We ended up making our own rolled rj45-rj45 cables. > IIRC, this was a ton of work as you need to do some funky 2 wires in one > position stuff. > > We also use Cisco 2500's with modem on the aux and an octo-cable for the > devices. This works well too, but not as nice of an interface as the > Cyclades. No special cables needed though. > > For power we have been using APC Managed PDU's. These have been > fantastic. No compaints. > > > > > -----Original Message----- > From: Mehmet Akcin [mailto:mehmet at akcin.net] > Sent: Thursday, May 14, 2009 9:30 PM > To: nanog at nanog.org > Subject: Managing your network devices via console > > Hello, > > It's always cool to have console access to routers/switches and nowadays > they are going from RS-232 to RJ-45 as a standart. I have got Avocent > DSR 2035 which is a KVM+Serial console (all in one).. but while I was > able to have it work against servers via KVM or/and Serial , I was > unable to make it work properly against any network device. I am > wondering if anyone had experience on DSR or similar boxes to configure > them against network devices console ports. > > Making suggestions for alternative ways of centralizing network device > console management is also more than welcome, I guess the old fashioned > server attached usb-serial console is one of the most preferred way, but > feel free to provide if ?you have good ideas > > cheers > > -- > Mehmet > > > -- Mehmet Akcin Blog: http:///akcin.net E-mail: mehmet at akcin.net From adam.lafountain at googlemail.com Fri May 15 14:56:57 2009 From: adam.lafountain at googlemail.com (Adam LaFountain) Date: Fri, 15 May 2009 12:56:57 -0700 Subject: NPE-G2 vs. Sup720-3BXL Message-ID: > We need true full routes and more CPU horsepower for crunching BGP > (+12 smaller peers + ISIS). OC3 interfaces are going to be mandatory, > one each at two locations. Oh yeah, we're still a larger startup > without endless pockets. Power, rack space, and SmartNet are not > concerns at any location (on-site cold spares). We may need an > upstream OC12 in the future but that's a ways out and not a concern > here. > > Our engineering team has settled on three $20k/node options: > - Sup720-3BXLs with PS and fan upgrades > - Sup2s as switches + ISIS + statics and no BGP, push BGP edge routing > off to NPE-G2s across a 2-3Gbps port-channel > - Sup2s as switches + ISIS + statics and no BGP, push BGP edge routing > off to a 12008 with E3 engines across a 2-3Gbps port-channel. > > Ideas and constructive opinions welcome, especially software and > stability-related. > For about $6k all in, you could pickup a monster dual Xeon server with a few 10GE PCI line cards and run a subscription service of the Vyatta open source router. With high end machine specs, we've been able to run 5 full tables and a solid amount of peers with about 6.5Gbps sustained to the net without any stress. For access, we just trunk one of the PCI cards down to a 6506 or a 3750 and it runs nice and clean. The only downside to this setup is the lack of cisco proprietary software features which it sounds like you might need. If anything you might be able to keep your existing setup and uplink everything to one of these routers as an edge device. Adam _______________ Adam LaFountain From aaron.millisor at bright.net Fri May 15 15:10:38 2009 From: aaron.millisor at bright.net (Aaron Millisor) Date: Fri, 15 May 2009 16:10:38 -0400 Subject: NPE-G2 vs. Sup720-3BXL In-Reply-To: References: <4A0D9BE2.4030701@bright.net> Message-ID: <4A0DCC3E.30306@bright.net> Yeah, as long as you're using the NSE-150 and are using features supported by the PXF such that it's not punting to the RP, the performance is really good. --am Brian Feeny wrote: > > I have used the 7304 in the past and was happy with it. In fact I still > have a 6-port DS3 module for a 7304 which I need to find a home for if > anyone has the need. > > The 7304 originally had its own specific modules that went into it. But > they also sell carrier card for it so you can use standard PA's, as well > as the SPA's which is nice. Overall footprint is rather nice, and I use > to use those 6-port DS3 cards which allowed for hefty DS3 termination. > > Brian > > On May 15, 2009, at 12:44 PM, Aaron Millisor wrote: > >> We ran into a similar quandary and have about the same amount of >> traffic as your network. When purchasing gear a year ago we decided >> against 7200's with an NPE-G2 as insufficient for the load. Have you >> looked at the 7304? >> >> The Cisco 7304 with an NSE-150 processing engine on it offloads a lot >> of the packet processing to dedicated hardware, and doesn't have TCAM >> limitations for routes. You can hold several full feeds and do the >> amount of traffic you're talking about without breaking a sweat. >> >> http://www.cisco.com/en/US/prod/collateral/routers/ps352/prod_bulletin0900aecd8060aac5.html >> >> >> It is capable of supporting both legacy port adapters (from your >> Flexwan or 7200 routers) and SPA cards with the right add-in modules, >> which IIRC is only a few hundred dollars. >> >> I'd be glad to answer any questions you have about our implementation. >> >> --am >> >> David Storandt wrote: >>> We're stuck in an engineering pickle, so some experience from this >>> crew would be useful in tie-breaking... >>> We operate a business-grade FTTx ISP with ~75 customers and 800Mbps of >>> Internet traffic, currently using 6509/Sup2s for core routing and port >>> aggregation. The MSFC2s are under stress from 3x full route feeds, >>> pared down to 85% to fit the TCAM tables. One system has a FlexWAN >>> with an OC3 card and it's crushing the CPU on the MSFC2. System tuning >>> (stable IOS and esp. disabling SPD) helped a lot but still doesn't >>> have the power to pull through. Hardware upgrades are needed... >>> We need true full routes and more CPU horsepower for crunching BGP >>> (+12 smaller peers + ISIS). OC3 interfaces are going to be mandatory, >>> one each at two locations. Oh yeah, we're still a larger startup >>> without endless pockets. Power, rack space, and SmartNet are not >>> concerns at any location (on-site cold spares). We may need an >>> upstream OC12 in the future but that's a ways out and not a concern >>> here. >>> Our engineering team has settled on three $20k/node options: >>> - Sup720-3BXLs with PS and fan upgrades >>> - Sup2s as switches + ISIS + statics and no BGP, push BGP edge routing >>> off to NPE-G2s across a 2-3Gbps port-channel >>> - Sup2s as switches + ISIS + statics and no BGP, push BGP edge routing >>> off to a 12008 with E3 engines across a 2-3Gbps port-channel. >>> Ideas and constructive opinions welcome, especially software and >>> stability-related. >>> Many thanks, >>> -Dave >> From simon at darkmere.gen.nz Fri May 15 21:14:01 2009 From: simon at darkmere.gen.nz (NANOG Mail List Committee) Date: Sat, 16 May 2009 14:14:01 +1200 Subject: ADMIN: List FAQ/Monthly Post. Message-ID: This 100-line document contains 62% of what you need to know to avoid annoying 10,000 people in your email to the NANOG list. It also contains pointers to another 23%. Please take 5 minutes to read it before you post [again]. General Information =================== About NANOG: http://www.nanog.org/about/ NANOG News: http://www.nanog.org/ NANOG lists and AUP: http://www.nanog.org/mailinglist/ NANOG List FAQ: http://www.nanog.org/mailinglist/listfaqs/ To Subscribe or Unsubscribe from the list: http://mailman.nanog.org/mailman/listinfo/nanog To contact the list's admins: admins at nanog.org Posting Policy ============== The NANOG list has over 10,000 subscribers so it is very easy for a thread to have scores of posts while being off-topic and only of interest to only a small proportion of subscribers. Please consider before each post if your email will be of interest to the majority of members or might alternatively be emailed directly the people of interest or posted to another forum. Please read the FAQ and AUP policy before posting for more details. Especially the following are discouraged: * Is a certain site down? Other Outages not affecting half the Internet. Please use http://downforeveryoneorjustme.com/ or a similar site. Please post to the Outages mailing list: http://wiki.outages.org * Spam Please use SPAM-L - http://www.claws-and-paws.com/spam-l * Contacting People * http://puck.nether.net/netops/ * http://www.peeringdb.com * Please try other methods of contacting sites before you post to NANOG. Saying something like "I tried calling 213-555-3333 but no answer" shows you _have_ tried alternative methods first. * Political Issues * Topics such as ICANN policy, Government Policy or Law changes that do not have short term Operational impact should be avoided. * Operation topics with more specific lists * DNS - http://lists.oarci.net/mailman/listinfo/dns-operations * Email - http://www.mailop.org/ * NANOG Mailing list policy Please use the nanog-futures list or contact admins at nanog.org Please also avoid ================= * Sending posts to the list relevant to only one or two people on this list, such as tests or traceroutes in response to another post for comparison to those originally posted. * Jokes, Puns, amusing observations, spelling corrections. Other NANOG related lists ========================= * NANOG-futures - for discussion of the evolution of NANOG, including organizational structure, policies and procedures, and agendas for NANOG meetings. Such topics aren't appropriate for the main NANOG mailing list. http://mailman.nanog.org/mailman/listinfo/nanog-futures * nanog-attendee - For discussion of venue-specific issues relevant to attendees of the current NANOG physical meeting. http://mailman.nanog.org/mailman/listinfo/nanog-attendee * nanog-announce - For announcements of NANOG meetings an other Important NANOG related announcements. Low traffic and all posts are also sent to main list. http://mailman.nanog.org/mailman/listinfo/nanog-announce Other Mailing Lists =================== Information about related lists: http://www.nanog.org/mailinglist/listfaqs/otherlists.php From dstorandt at teljet.com Fri May 15 21:20:28 2009 From: dstorandt at teljet.com (David Storandt) Date: Fri, 15 May 2009 22:20:28 -0400 Subject: NPE-G2 vs. Sup720-3BXL In-Reply-To: References: Message-ID: So I figure a summary is an order, with a whole array of choices pitched so far... - Sup720-3BXL works for light-duty premium ISP services, decent CPU for BGP and an Ethernet hardware throughput monster. Decent enough for our deployment scenario at least. No obvious solution for the FlexWAN/OC3 but could easily be re-integrated with a stronger MSFC CPU to back it up, assuming the IOS-of-the-week doesn't have issues. The pesky OC3 could be pawned off to a dedicated G1/G2 router too along with any oddball <=OC3 stuff our sales guys dream up. - RSP720-3CXL is the best of all worlds option, if we had double the budget to work with. Meh. - ASR1002 is a hardware-assisted overhaul to the 7200/G2. Telco interface options are much better than 7200s, good for OC12s and OC48s. Using GoogleFu product pricing... a ASR1002 router with a SPA OC3, 5Gbps ESP, and base software runs in the $28-30k range + SmartNet. Beware the modular licensing model in addition to IOS editions. Maybe a bit early yet as a core router as some of the software is still getting bugs ironed out. - Vyatta was proposed as an alternative system, probably best architected out of the mainstream traffic flows (no hardware forwarding), say a BGP route reflector or GBE edge router, similar argument to a 7200/G[1|2]. I can't say I'm familiar with the software, but the cost savings of premium x86/x64 hardware and 8x PCI-x serving a few 10GBE interfaces + built-in GBEs is intriguing, especially paired against our budget and relative Cisco costs. A spec'd out 1U Dell box with dual power, 8x cores, 4GB, RAID1 SATA, and 2x 10GBE XFP+2x GBE built-in came in under $7k with CPU headroom to burn. Vyatta doesn't support ISIS though, best I can tell, but may not have to... Maybe yet-another Linux router distro doomed to fail? Worth a lab test internally on some demo hardware. - Mixed thoughts about 7304 hardware. Hardware forwarding quality vs. software and interface selection. - Lots of fans for the 12000 series. Stick with the E3 (~2.5Gbps) and E5 (~10Gbps) line cards for compatibility with XR software and best line card performance. Our team liked the variety of SONET options available too for our central office deployments, even though the systems are power and space hungry. ...and if you can afford them (the 12008/GRP-B being the relative exception). - 7200/G2s are great for <1Gbps throughput. Premium services cut into the performance dramatically, being a fully software-based forwarding platform. Don't bond interfaces looking for more throughput, architecture limitations actually decrease throughput. - Juniper MX series? A budget wildcard but indeed a worthy platform engineering-wise. You could break this list into "routers" and "switches", which in itself spurs the philosophical/pragmatic architecture discussion that got us the impasse to start with. Many thanks to all who've responded with real-life successes, battle wounds, and horror stories. All very helpful. -Dave From Valdis.Kletnieks at vt.edu Fri May 15 21:25:12 2009 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Fri, 15 May 2009 22:25:12 -0400 Subject: NPE-G2 vs. Sup720-3BXL In-Reply-To: Your message of "Fri, 15 May 2009 22:20:28 EDT." References: Message-ID: <10898.1242440712@turing-police.cc.vt.edu> On Fri, 15 May 2009 22:20:28 EDT, David Storandt said: > - Vyatta was proposed as an alternative system, probably best > architected out of the mainstream traffic flows (no hardware > forwarding), say a BGP route reflector or GBE edge router, similar > argument to a 7200/G[1|2]. I can't say I'm familiar with the software, > but the cost savings of premium x86/x64 hardware and 8x PCI-x serving > a few 10GBE interfaces + built-in GBEs is intriguing, especially > paired against our budget and relative Cisco costs. A spec'd out 1U > Dell box with dual power, 8x cores, 4GB, RAID1 SATA, and 2x 10GBE > XFP+2x GBE built-in came in under $7k with CPU headroom to burn. Did you check PCI bus bandwidth? That's probably going to be the biggest constraint on "a few 10GBE interfaces" if they all get going full blast. Remember that each packet is going to burn bandwidth twice - once in and once out... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 226 bytes Desc: not available URL: From bicknell at ufp.org Fri May 15 21:41:55 2009 From: bicknell at ufp.org (Leo Bicknell) Date: Fri, 15 May 2009 22:41:55 -0400 Subject: NPE-G2 vs. Sup720-3BXL In-Reply-To: <10898.1242440712@turing-police.cc.vt.edu> References: <10898.1242440712@turing-police.cc.vt.edu> Message-ID: <20090516024155.GA37325@ussenterprise.ufp.org> In a message written on Fri, May 15, 2009 at 10:25:12PM -0400, Valdis.Kletnieks at vt.edu wrote: > Did you check PCI bus bandwidth? That's probably going to be the biggest > constraint on "a few 10GBE interfaces" if they all get going full blast. > Remember that each packet is going to burn bandwidth twice - once in and > once out... PCIe, x8 or x16, which is serial point to point. http://www.csc.kth.se/~olofh/10G_OSR/10Gbps.pdf 25 Gb/sec across 4x10G ports on higher end but far from topped out hardware. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 825 bytes Desc: not available URL: From azher at hep.caltech.edu Fri May 15 21:51:09 2009 From: azher at hep.caltech.edu (Azher Mughal) Date: Fri, 15 May 2009 19:51:09 -0700 Subject: NPE-G2 vs. Sup720-3BXL In-Reply-To: <20090516024155.GA37325@ussenterprise.ufp.org> References: <10898.1242440712@turing-police.cc.vt.edu> <20090516024155.GA37325@ussenterprise.ufp.org> Message-ID: <4A0E2A1D.9000506@hep.caltech.edu> New architectures might be helpful to achieve such throughput e.g. Myricom pci-e Gen2 10GE cards on new Intel Nehalem based servers. -Azher Leo Bicknell wrote: > In a message written on Fri, May 15, 2009 at 10:25:12PM -0400, Valdis.Kletnieks at vt.edu wrote: >> Did you check PCI bus bandwidth? That's probably going to be the biggest >> constraint on "a few 10GBE interfaces" if they all get going full blast. >> Remember that each packet is going to burn bandwidth twice - once in and >> once out... > > PCIe, x8 or x16, which is serial point to point. > > http://www.csc.kth.se/~olofh/10G_OSR/10Gbps.pdf > > 25 Gb/sec across 4x10G ports on higher end but far from topped out > hardware. > From r.hyunseog at ieee.org Fri May 15 22:25:05 2009 From: r.hyunseog at ieee.org (Alex H. Ryu) Date: Fri, 15 May 2009 22:25:05 -0500 Subject: NPE-G2 vs. Sup720-3BXL In-Reply-To: References: Message-ID: <4A0E3211.3030807@ieee.org> ASR is embedded linux solution with Quantum Processor architect if I remember correctly. So it uses IOS-XE, which is a little bit different from standard IOS. If you have some room for budget, you can check Foundry MLX/XMR series router. It is more geared toward Ethernet Service Router. But if you need OC3/12/48, you can have those with additional license fee. Foundry router price is a lot lower than Juniper MX series router. Alex David Storandt wrote: > So I figure a summary is an order, with a whole array of choices > pitched so far... > > - Sup720-3BXL works for light-duty premium ISP services, decent CPU > for BGP and an Ethernet hardware throughput monster. Decent enough for > our deployment scenario at least. No obvious solution for the > FlexWAN/OC3 but could easily be re-integrated with a stronger MSFC CPU > to back it up, assuming the IOS-of-the-week doesn't have issues. The > pesky OC3 could be pawned off to a dedicated G1/G2 router too along > with any oddball <=OC3 stuff our sales guys dream up. > - RSP720-3CXL is the best of all worlds option, if we had double the > budget to work with. Meh. > - ASR1002 is a hardware-assisted overhaul to the 7200/G2. Telco > interface options are much better than 7200s, good for OC12s and > OC48s. Using GoogleFu product pricing... a ASR1002 router with a SPA > OC3, 5Gbps ESP, and base software runs in the $28-30k range + > SmartNet. Beware the modular licensing model in addition to IOS > editions. Maybe a bit early yet as a core router as some of the > software is still getting bugs ironed out. > - Vyatta was proposed as an alternative system, probably best > architected out of the mainstream traffic flows (no hardware > forwarding), say a BGP route reflector or GBE edge router, similar > argument to a 7200/G[1|2]. I can't say I'm familiar with the software, > but the cost savings of premium x86/x64 hardware and 8x PCI-x serving > a few 10GBE interfaces + built-in GBEs is intriguing, especially > paired against our budget and relative Cisco costs. A spec'd out 1U > Dell box with dual power, 8x cores, 4GB, RAID1 SATA, and 2x 10GBE > XFP+2x GBE built-in came in under $7k with CPU headroom to burn. > Vyatta doesn't support ISIS though, best I can tell, but may not have > to... Maybe yet-another Linux router distro doomed to fail? Worth a > lab test internally on some demo hardware. > - Mixed thoughts about 7304 hardware. Hardware forwarding quality vs. > software and interface selection. > - Lots of fans for the 12000 series. Stick with the E3 (~2.5Gbps) and > E5 (~10Gbps) line cards for compatibility with XR software and best > line card performance. Our team liked the variety of SONET options > available too for our central office deployments, even though the > systems are power and space hungry. ...and if you can afford them (the > 12008/GRP-B being the relative exception). > - 7200/G2s are great for <1Gbps throughput. Premium services cut into > the performance dramatically, being a fully software-based forwarding > platform. Don't bond interfaces looking for more throughput, > architecture limitations actually decrease throughput. > - Juniper MX series? A budget wildcard but indeed a worthy platform > engineering-wise. > > You could break this list into "routers" and "switches", which in > itself spurs the philosophical/pragmatic architecture discussion that > got us the impasse to start with. Many thanks to all who've responded > with real-life successes, battle wounds, and horror stories. All very > helpful. > > -Dave > > > > From chanty_kh at yahoo.com Fri May 15 22:26:57 2009 From: chanty_kh at yahoo.com (ty chan) Date: Fri, 15 May 2009 20:26:57 -0700 (PDT) Subject: Implementing MPLS L2 VPN with Cisco C3750ME Message-ID: <331353.52767.qm@web52308.mail.re2.yahoo.com> Hi community, I am planning to implement MPLS with C3750ME. As i know C3750ME is full support MPLS viaES port, is it? the IOS is c3750me-i5k91-mz.122-40.SE.bin. The application will be AToM(L2 VPN). Prior to configure MPLS or OSPF, i need to make the link up first. My problem is IP point-to-point link between 2 C3750ME with ES port doesn't work at all while L2 Point-to-Point works well. I had performed all troubleshoot technique that i know but still not work. Does anyone used to have same problem as mine? How did you do to fix it? From patrick at ianai.net Sat May 16 04:37:15 2009 From: patrick at ianai.net (Patrick W. Gilmore) Date: Sat, 16 May 2009 05:37:15 -0400 Subject: you're not interesting, was Re: another brick in the wall[ed garden] In-Reply-To: <200905150037.n4F0bfjD095857@drugs.dv.isc.org> References: <200905150037.n4F0bfjD095857@drugs.dv.isc.org> Message-ID: On May 14, 2009, at 8:37 PM, Mark Andrews wrote: >> [TLB:] I can think of an argument they might make: that it is/could >> be >> used by bots as a fallback. However, redirecting DNS/UDP fits the >> model >> of "providing a better service for the average user"; >> blocking/redirecting TCP is more likely to break things a savvy user >> needs. > > There is still no sane reason to block TCP. If they are > intercepting DNS/UDP then they need to also intercept DNS/TCP > as they will break all sites that cause "tc=1" to be set > in the DNS/UDP reply. First, since when does it require a "sane" reason to do something? Second, and more importantly, John is right. Sprint is a for-profit business. If blocking UDP - or TCP or HTTP or whatever - makes them more money than not blocking it, they will do it. And rightly so. Of course, it is entirely possible management figured out blocking "DNS" was more profitable because the cost savings in lower call center volume more than offset the 4 people who dropped Sprint because of the block. So they told engineers to 'block DNS' and the engineers did that without knowing that blocking TCP port 53 was not more profitable, and perhaps was less profitable. Miscommunications abound between Engineering and Management. This should surprise few, and hopefully no one on NANOG. Assuming something like that happened, will a post to NANOG fix it? I don't know. Certainly has a non-zero chance. But trying to get Sprint, or any provider, to change because _you_ think what they are doing is not sane is, well, not sane. "Never appeal to a man's 'better nature,' he may not have one. Invoking his self-interest gives you more leverage." -- TTFN, patrick From jzp-sc at rsuc.gweep.net Sat May 16 10:51:12 2009 From: jzp-sc at rsuc.gweep.net (Joe Provo) Date: Sat, 16 May 2009 11:51:12 -0400 Subject: [NANOG-announce] NANOG46 Update Message-ID: <20090516155112.GA95998@gweep.net> Greetings! There are just four weeks left until NANOG46, and if you are planning to attend don't delay - register! While the Early-bird registration period has ended, if you don't register before June 8 you will face the on-site price of $600. The NANOG group hotel rate will expire May 29, within two weeks (http://nanog.org/meetings/nanog46/hotel.php). Registered NANOG46 attendees will get further updates sent to the attendee mailing list (), so please do subscribe if you had opted out at the time of registration. Either visit http://mailman.nanog.org/mailman/listinfo/nanog-attendee or send email to . The NANOG Program Committee has once again provided an excellent agenda (http://nanog.org/meetings/nanog46/agenda.php) for the conference. While we already have the support of several sponsors for both the conference and some socials (http://nanog.org/meetings/nanog46/sponsors.php), there are still opportunities for your organization to get exposure to the NANOG audience. See http://www.nanog.org/meetings/nanog46/sponsorships.php for more details. If you are entering the United States and have not yet determined if you need a visa, check the US Department of State site, notably http://travel.state.gov/visa/visa_1750.html and http://travel.state.gov/visa/temp/without/without_1990.html. Paper entrance forms can be bypassed for many countries; see details at http://cbp.gov/xp/cgov/travel/id_visa/esta/. Should you require a formal Letter of Invitation, please contact Merit staff by email to . As always, we encourage you to send any questions or concerns via email, or by voice at Merit (1.734.527.5700). Come join your colleagues in Philadelphia! Joe Provo, SC Chair -- RSUC / GweepNet / Spunk / FnB / Usenix / SAGE _______________________________________________ NANOG-announce mailing list NANOG-announce at nanog.org http://mailman.nanog.org/mailman/listinfo/nanog-announce From jba at analogue.net Sat May 16 14:47:38 2009 From: jba at analogue.net (jeffrey.arnold) Date: Sat, 16 May 2009 15:47:38 -0400 (EDT) Subject: NPE-G2 vs. Sup720-3BXL In-Reply-To: <20090516024155.GA37325@ussenterprise.ufp.org> References: <10898.1242440712@turing-police.cc.vt.edu> <20090516024155.GA37325@ussenterprise.ufp.org> Message-ID: On Fri, 15 May 2009, Leo Bicknell wrote: > PCIe, x8 or x16, which is serial point to point. > > http://www.csc.kth.se/~olofh/10G_OSR/10Gbps.pdf > > 25 Gb/sec across 4x10G ports on higher end but far from topped out > hardware. > further illustrating the point - 10gige ~linerate load balancing on a single core2 e8200 using haproxy + myricom 10gige cards: http://haproxy.1wt.eu/10g.html -jba From jvargas at crypticstudios.com Sat May 16 16:20:41 2009 From: jvargas at crypticstudios.com (Jake Vargas) Date: Sat, 16 May 2009 14:20:41 -0700 Subject: Managing your network devices via console In-Reply-To: <736A914C-80AB-401A-8102-32D9150CC6E1@cs.cmu.edu> References: <2909d6d90905141929n746c29c9v88b337ee4ce981c1@mail.gmail.com> <87bppuyep6.fsf@nemi.mork.no> <20090515084459.GP29526@ronin.4ever.de> <736A914C-80AB-401A-8102-32D9150CC6E1@cs.cmu.edu> Message-ID: > Check out something like the BayTech RPC3 or RPC41 family? I don't > know if it's exactly what you're looking for, but that's what I just > picked to have per-outlet monitoring and control for a research > datacenter we're building. > > -Dave > We use Servertech's Sentry Switched CDU's for ours. All kinds of fun stuff it can do besides ssh/telnet/http(s)/snmp. From apj at mutt.dk Sat May 16 18:19:20 2009 From: apj at mutt.dk (Andreas Plesner Jacobsen) Date: Sun, 17 May 2009 01:19:20 +0200 Subject: Broken RIPE-entry Message-ID: <20090516231920.GB2455@nerd.dk> I thought this may be of interest to anybody who uses the RIPE db for automated purposes. Somebody seems to have done a friday slip-up and entered this in the RIPE db: inetnum: 93.169.24.0 - 193.169.25.255 netname: CENTRSVYAZ-NET descr: Centrsvyaz CJSC country: RU -- Andreas From ryguillian at gmail.com Sat May 16 20:22:26 2009 From: ryguillian at gmail.com (Ryan Hayes) Date: Sat, 16 May 2009 20:22:26 -0500 Subject: Broken RIPE-entry In-Reply-To: <20090516231920.GB2455@nerd.dk> References: <20090516231920.GB2455@nerd.dk> Message-ID: <786ccf330905161822p1a617cc0k44dd276368fd640a@mail.gmail.com> That would indeed be a very large allocation. :) On Sat, May 16, 2009 at 6:19 PM, Andreas Plesner Jacobsen wrote: > I thought this may be of interest to anybody who uses the RIPE db for > automated purposes. Somebody seems to have done a friday slip-up and > entered this in the RIPE db: > > inetnum: 93.169.24.0 - 193.169.25.255 > netname: CENTRSVYAZ-NET > descr: Centrsvyaz CJSC > country: RU > > -- > Andreas > > -- Ryan Hayes | aim: ryguillian | http://anynoisry.blogspot.com Casey Stengel - "There comes a time in every man's life, and I've had plenty of them." From dave at stayonline.com Sat May 16 20:37:11 2009 From: dave at stayonline.com (Dave Larter) Date: Sat, 16 May 2009 21:37:11 -0400 Subject: Broken RIPE-entry In-Reply-To: <786ccf330905161822p1a617cc0k44dd276368fd640a@mail.gmail.com> References: <20090516231920.GB2455@nerd.dk> <786ccf330905161822p1a617cc0k44dd276368fd640a@mail.gmail.com> Message-ID: <8B79B73777E7D544A24BEB8FC50D35DB5978CC@MERCURY.socrdu.com> Yes, obviously it was meant to be 193.169.24.0 - 193.169.25.255 -----Original Message----- From: Ryan Hayes [mailto:ryguillian at gmail.com] Sent: Saturday, May 16, 2009 9:22 PM To: nanog at merit.edu; ncc at ripe.net Subject: Re: Broken RIPE-entry That would indeed be a very large allocation. :) On Sat, May 16, 2009 at 6:19 PM, Andreas Plesner Jacobsen wrote: > I thought this may be of interest to anybody who uses the RIPE db for > automated purposes. Somebody seems to have done a friday slip-up and > entered this in the RIPE db: > > inetnum: 93.169.24.0 - 193.169.25.255 > netname: CENTRSVYAZ-NET > descr: Centrsvyaz CJSC > country: RU > > -- > Andreas > > -- Ryan Hayes | aim: ryguillian | http://anynoisry.blogspot.com Casey Stengel - "There comes a time in every man's life, and I've had plenty of them." From nanog at armorfirewall.com Sun May 17 03:34:43 2009 From: nanog at armorfirewall.com (George Imburgia) Date: Sun, 17 May 2009 04:34:43 -0400 (EDT) Subject: you're not interesting, was Re: another brick in the wall[ed garden] In-Reply-To: References: <200905150037.n4F0bfjD095857@drugs.dv.isc.org> Message-ID: On Sat, 16 May 2009, Patrick W. Gilmore wrote: > Assuming something like that happened, will a post to NANOG fix it? I don't > know. Certainly has a non-zero chance. But trying to get Sprint, or any > provider, to change because _you_ think what they are doing is not sane is, > well, not sane. In '02, I had a similar issue with Comcast, when they silently fired up transparent proxy servers. It became apparent when, while working on a remote web server, I was served up cached copies of the pages I was editing. My approach was two-pronged. First, I bitched loud and long on some security lists about the MITM attack. Not only was it abusive as it was, the potential for further abuse (tracking, ad insertion, theft of sensitive data and intellectual property...) was significant. Eventually, Ted Bridis of Associated Press picked it up and ran a story. The next day, the issue was on the front page of nearly every newspaper in the english speaking world, and then some, as well as network TV news. Comcast has a large customer base, particularly in the DC area, and a lot of very influential people (like federal judges) were not fond of having their research and recreational web surfing intercepted. The proxies went away within a few days, and several jurisdictions passed laws prohibiting this. I'd suspect Sprint is violating some of these laws. The other approach was; I sent exploit code addressed to one of my machines. Comcast's servers stole this code and choked on it. It's probably not illegal to send malicious code to a machine you own. If they stole it and choked on it, it's their problem. But with the legal system the way it is, you'll just have to use your imagination until the statute of limitations expires. Cheers, George From patrick at ianai.net Sun May 17 04:38:49 2009 From: patrick at ianai.net (Patrick W. Gilmore) Date: Sun, 17 May 2009 05:38:49 -0400 Subject: you're not interesting, was Re: another brick in the wall[ed garden] In-Reply-To: References: <200905150037.n4F0bfjD095857@drugs.dv.isc.org> Message-ID: <15D1ABB6-C8CC-4BE2-8C38-BDBABAC34E38@ianai.net> On May 17, 2009, at 4:34 AM, George Imburgia wrote: > On Sat, 16 May 2009, Patrick W. Gilmore wrote: > >> Assuming something like that happened, will a post to NANOG fix >> it? I don't know. Certainly has a non-zero chance. But trying >> to get Sprint, or any provider, to change because _you_ think what >> they are doing is not sane is, well, not sane. > > In '02, I had a similar issue with Comcast, when they silently fired > up transparent proxy servers. It became apparent when, while working > on a remote web server, I was served up cached copies of the pages I > was editing. > > My approach was two-pronged. First, I bitched loud and long on some > security lists about the MITM attack. Not only was it abusive as it > was, the potential for further abuse (tracking, ad insertion, theft > of sensitive data and intellectual property...) was significant. > Eventually, Ted Bridis of Associated Press picked it up and ran a > story. The next day, the issue was on the front page of nearly every > newspaper in the english speaking world, and then some, as well as > network TV news. > > Comcast has a large customer base, particularly in the DC area, and > a lot of very influential people (like federal judges) were not fond > of having their research and recreational web surfing intercepted. Then they were silly to think turning off the transparent proxies somehow allowed them not to be tracked. But then, most "influential people" are, at the very least, ignorant of technology. > The proxies went away within a few days, and several jurisdictions > passed laws prohibiting this. I'd suspect Sprint is violating some > of these laws. You gave them a business reason (cost more to keep them then turn them off) to change their mind. Good for you. I doubt the same is true for Sprint modulo the laws you mention. And I'm wondering what laws these are, since intercepting port 43 is an extremely common practice. -- TTFN, patrick From nanog-announce at nanog.org Sun May 17 08:02:30 2009 From: nanog-announce at nanog.org (nanog-announce at nanog.org) Date: Sun, 17 May 2009 09:02:30 -0400 Subject: We will pricematch any watch that you find online Message-ID: <000d01c9d6ef$bc63e180$6400a8c0@boyfriendy89> The time is NOW to get YOUR rep1ica watches that are famous around the world. These affordable imitations make you look rich at a fraction of the cost. Choose from any of the following replica watches Eberhard & Co, Breitling, Bvlgari, Cartier, Chopard, IWC, Panerai, Patek Philippe, TAG Heuer and Vacheron. Visit us: http://mewaqimid.cn/ Best Regards Lucas Stanley www.mewaqimid.cn From lists at memetic.org Mon May 18 06:20:06 2009 From: lists at memetic.org (Adam Armstrong) Date: Mon, 18 May 2009 12:20:06 +0100 Subject: NPE-G2 vs. Sup720-3BXL In-Reply-To: References: Message-ID: <4A114466.1050208@memetic.org> David Storandt wrote: > We're stuck in an engineering pickle, so some experience from this > crew would be useful in tie-breaking... > > We operate a business-grade FTTx ISP with ~75 customers and 800Mbps of > Internet traffic, currently using 6509/Sup2s for core routing and port > aggregation. The MSFC2s are under stress from 3x full route feeds, > pared down to 85% to fit the TCAM tables. One system has a FlexWAN > with an OC3 card and it's crushing the CPU on the MSFC2. System tuning > (stable IOS and esp. disabling SPD) helped a lot but still doesn't > have the power to pull through. Hardware upgrades are needed... > > We need true full routes and more CPU horsepower for crunching BGP > (+12 smaller peers + ISIS). OC3 interfaces are going to be mandatory, > one each at two locations. Oh yeah, we're still a larger startup > without endless pockets. Power, rack space, and SmartNet are not > concerns at any location (on-site cold spares). We may need an > upstream OC12 in the future but that's a ways out and not a concern > here. > > Our engineering team has settled on three $20k/node options: > - Sup720-3BXLs with PS and fan upgrades > - Sup2s as switches + ISIS + statics and no BGP, push BGP edge routing > off to NPE-G2s across a 2-3Gbps port-channel > - Sup2s as switches + ISIS + statics and no BGP, push BGP edge routing > off to a 12008 with E3 engines across a 2-3Gbps port-channel. > Have a look at the ASR1002 + ESP5/10G Stable for BGP+ISIS as far as our experience goes. adam. From steve+nanog at sendithere.com Mon May 18 09:45:33 2009 From: steve+nanog at sendithere.com (Steve Dalberg) Date: Mon, 18 May 2009 07:45:33 -0700 Subject: NPE-G2 vs. Sup720-3BXL In-Reply-To: <4A114466.1050208@memetic.org> References: <4A114466.1050208@memetic.org> Message-ID: 2009/5/18 Adam Armstrong : > David Storandt wrote: >> >> We're stuck in an engineering pickle, so some experience from this >> crew would be useful in tie-breaking... >> >> We operate a business-grade FTTx ISP with ~75 customers and 800Mbps of >> Internet traffic, currently using 6509/Sup2s for core routing and port >> aggregation. The MSFC2s are under stress from 3x full route feeds, >> pared down to 85% to fit the TCAM tables. One system has a FlexWAN >> with an OC3 card and it's crushing the CPU on the MSFC2. System tuning >> (stable IOS and esp. disabling SPD) helped a lot but still doesn't >> have the power to pull through. Hardware upgrades are needed... >> >> We need true full routes and more CPU horsepower for crunching BGP >> (+12 smaller peers + ISIS). OC3 interfaces are going to be mandatory, >> one each at two locations. Oh yeah, we're still a larger startup >> without endless pockets. Power, rack space, and SmartNet are not >> concerns at any location (on-site cold spares). We may need an >> upstream OC12 in the future but that's a ways out and not a concern >> here. >> >> Our engineering team has settled on three $20k/node options: >> - Sup720-3BXLs with PS and fan upgrades >> - Sup2s as switches + ISIS + statics and no BGP, push BGP edge routing >> off to NPE-G2s across a 2-3Gbps port-channel >> - Sup2s as switches + ISIS + statics and no BGP, push BGP edge routing >> off to a 12008 with E3 engines across a 2-3Gbps port-channel. >> > > Have a look at the ASR1002 + ESP5/10G > > Stable for BGP+ISIS as far as our experience goes. > > adam. > > ASR1002 + ESP5 was great for OSPF + BGP. 450M+ of traffic for me at peek (proc at1-2%) -- Steve From jarruda-gter at jarruda.com Mon May 18 10:00:39 2009 From: jarruda-gter at jarruda.com (Julio Arruda) Date: Mon, 18 May 2009 11:00:39 -0400 Subject: NPE-G2 vs. Sup720-3BXL In-Reply-To: References: <4A114466.1050208@memetic.org> Message-ID: <4A117817.5020301@jarruda.com> Steve Dalberg wrote: > 2009/5/18 Adam Armstrong : >> David Storandt wrote: >>> We're stuck in an engineering pickle, so some experience from this >>> crew would be useful in tie-breaking... >>> >>> We operate a business-grade FTTx ISP with ~75 customers and 800Mbps of >>> Internet traffic, currently using 6509/Sup2s for core routing and port >>> aggregation. The MSFC2s are under stress from 3x full route feeds, >>> pared down to 85% to fit the TCAM tables. One system has a FlexWAN >>> with an OC3 card and it's crushing the CPU on the MSFC2. System tuning >>> (stable IOS and esp. disabling SPD) helped a lot but still doesn't >>> have the power to pull through. Hardware upgrades are needed... >>> >>> We need true full routes and more CPU horsepower for crunching BGP >>> (+12 smaller peers + ISIS). OC3 interfaces are going to be mandatory, >>> one each at two locations. Oh yeah, we're still a larger startup >>> without endless pockets. Power, rack space, and SmartNet are not >>> concerns at any location (on-site cold spares). We may need an >>> upstream OC12 in the future but that's a ways out and not a concern >>> here. >>> >>> Our engineering team has settled on three $20k/node options: >>> - Sup720-3BXLs with PS and fan upgrades >>> - Sup2s as switches + ISIS + statics and no BGP, push BGP edge routing >>> off to NPE-G2s across a 2-3Gbps port-channel >>> - Sup2s as switches + ISIS + statics and no BGP, push BGP edge routing >>> off to a 12008 with E3 engines across a 2-3Gbps port-channel. >>> >> Have a look at the ASR1002 + ESP5/10G >> >> Stable for BGP+ISIS as far as our experience goes. >> >> adam. >> >> > > ASR1002 + ESP5 was great for OSPF + BGP. 450M+ of traffic for me at > peek (proc at1-2%) > Any experience in how much more resilient is the ASR compared with 7600/6500, DDoS-wise :-) ? And compared with NPE-G2 ? And in terms of CoPP and etc ? From dholmes at mwdh2o.com Mon May 18 10:55:24 2009 From: dholmes at mwdh2o.com (Holmes,David A) Date: Mon, 18 May 2009 08:55:24 -0700 Subject: NPE-G2 vs. Sup720-3BXL In-Reply-To: <4A114466.1050208@memetic.org> References: <4A114466.1050208@memetic.org> Message-ID: <485ED9BA02629E4BBBA53AC892EDA50E08EE9515@usmsxt104.mwd.h2o> Some things to remember about the MSFC2s when designing a deterministic network: Without the switch fabric module, the 6509 only has a 32 Gbps contention-based BUS as a backplane. Also I believe only "classic" line cards work without the switch fabric module. "Classic" line cards share hardware port buffers between adjacent ports (groups of 8 ports for copper cards) such that it is possible when one port is run at sustained wire speed, the hardware port buffer capacity is exhausted, causing drops on the other ports. The sup720 has the 720 Gbps switch fabric module integrated on the supervisor engine freeing up slots 5/6 where the switch fabric line cards are inserted with an MFSC2. -----Original Message----- From: Adam Armstrong [mailto:lists at memetic.org] Sent: Monday, May 18, 2009 4:20 AM To: David Storandt; nanog at nanog.org Subject: Re: NPE-G2 vs. Sup720-3BXL David Storandt wrote: > We're stuck in an engineering pickle, so some experience from this > crew would be useful in tie-breaking... > > We operate a business-grade FTTx ISP with ~75 customers and 800Mbps of > Internet traffic, currently using 6509/Sup2s for core routing and port > aggregation. The MSFC2s are under stress from 3x full route feeds, > pared down to 85% to fit the TCAM tables. One system has a FlexWAN > with an OC3 card and it's crushing the CPU on the MSFC2. System tuning > (stable IOS and esp. disabling SPD) helped a lot but still doesn't > have the power to pull through. Hardware upgrades are needed... > > We need true full routes and more CPU horsepower for crunching BGP > (+12 smaller peers + ISIS). OC3 interfaces are going to be mandatory, > one each at two locations. Oh yeah, we're still a larger startup > without endless pockets. Power, rack space, and SmartNet are not > concerns at any location (on-site cold spares). We may need an > upstream OC12 in the future but that's a ways out and not a concern > here. > > Our engineering team has settled on three $20k/node options: > - Sup720-3BXLs with PS and fan upgrades > - Sup2s as switches + ISIS + statics and no BGP, push BGP edge routing > off to NPE-G2s across a 2-3Gbps port-channel > - Sup2s as switches + ISIS + statics and no BGP, push BGP edge routing > off to a 12008 with E3 engines across a 2-3Gbps port-channel. > Have a look at the ASR1002 + ESP5/10G Stable for BGP+ISIS as far as our experience goes. adam. From jgreco at ns.sol.net Mon May 18 22:06:09 2009 From: jgreco at ns.sol.net (Joe Greco) Date: Mon, 18 May 2009 22:06:09 -0500 (CDT) Subject: Fore ATM PCI cards Message-ID: <200905190306.n4J369Ix086989@aurora.sol.net> I've poked around trying to figure out how not to just dump these in the trash. isp-equipment seems to be dead, etc. They're obscure and NANOG's about the only group I would think of where ATM guys might still hang out. :-) Free to a good home: a small supply of Fore ATM OC3 fiber and copper cards, mostly PCA-200. Looks like about a dozen, more fiber than copper. Replies to me only. If you know of anyone who'd be interested, let me know. ... 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 Tue May 19 07:30:22 2009 From: jgreco at ns.sol.net (Joe Greco) Date: Tue, 19 May 2009 07:30:22 -0500 (CDT) Subject: Fore ATM PCI cards In-Reply-To: <200905190306.n4J369Ix086989@aurora.sol.net> from "Joe Greco" at May 18, 2009 10:06:09 PM Message-ID: <200905191230.n4JCUMvs045648@aurora.sol.net> > Free to a good home: a small supply of Fore ATM OC3 fiber and copper > cards, mostly PCA-200. Looks like about a dozen, more fiber than > copper. Ok, definitely several interested parties, no more please :-) ... 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 polar.humenn at gmail.com Tue May 19 17:44:26 2009 From: polar.humenn at gmail.com (Polar Humenn) Date: Tue, 19 May 2009 18:44:26 -0400 Subject: MX problems Message-ID: I'm in Syracuse NY, and I'm having problems getting sendmail to get to MX servers, with the errors of "No Route to Host" or "Connection timed Out". Apparently this is been happening for over 5 days. I can send mail within Syracuse University, but as soon as I venture out nothing. Traceroute seems to loose it after about the 9 or 10th hop. It seems that I can get to almost any website, but tracerouting or pinging these MX servers is not happening. Is there anything going on, or at least something that started 5-7 days ago? I find the same problem from within Syracuse Univeristy to my RoadRunner account at home (which does not pass through the university routers). I only noticed it from the university since thats where I usually send my email through. Like I would no have been able to post to this list >From my home machine: > traceroute s0.nanog.org traceroute to s0.nanog.org (198.108.95.20), 30 hops max, 60 byte packets 1 192.168.99.1 (192.168.99.1) 0.211 ms 0.257 ms 0.302 ms 2 10.217.224.1 (10.217.224.1) 13.754 ms 13.855 ms 14.291 ms 3 gig2-2.syrcnysyr-rtr01.nyroc.rr.com (24.92.231.138) 18.442 ms 22.701 ms 26.908 ms 4 gig1-1-0.syrcnyflk-rtr02.nyroc.rr.com (24.92.231.54) 31.279 ms 31.454 ms 31.591 ms 5 ge-4-3-0.albynywav-rtr03.nyroc.rr.com (24.24.7.53) 37.429 ms 37.604 ms 37.779 ms 6 ae-5-0.cr0.nyc30.tbone.rr.com (66.109.6.74) 41.329 ms 18.241 ms 22.192 ms 7 ae-1-0.pr0.nyc20.tbone.rr.com (66.109.6.163) 27.472 ms 19.542 ms 23.419 ms 8 te1-4.mpd01.jfk05.atlas.cogentco.com (154.54.13.185) 28.070 ms 32.824 ms 35.822 ms 9 te9-3.ccr01.jfk02.atlas.cogentco.com (154.54.3.165) 40.796 ms 40.549 ms te2-4.ccr01.jfk02.atlas.cogentco.com (154.54.6.49) 40.958 ms 10 te2-4.mpd01.bos01.atlas.cogentco.com (154.54.5.249) 48.704 ms 47.549 ms 48.468 ms 11 te2-2.ccr01.ord01.atlas.cogentco.com (154.54.6.154) 57.836 ms te8-8.mpd01.ord01.atlas.cogentco.com (154.54.24.54) 58.063 ms te2-2.mpd01.ord01.atlas.cogentco.com (154.54.6.18) 46.700 ms 12 vl3488.mpd01.ord03.atlas.cogentco.com (154.54.5.26) 56.905 ms te3-4.mpd01.ord03.atlas.cogentco.com (154.54.6.206) 56.144 ms vl3488.mpd01.ord03.atlas.cogentco.com (154.54.5.26) 45.245 ms 13 Merit.demarc.cogentco.com (38.112.7.10) 44.512 ms Merit.demarc.cogentco.com (66.28.21.234) 38.385 ms Merit.demarc.cogentco.com (38.112.7.10) 40.305 ms 14 tenge0-0-0-0x76.aa2.mich.net (198.108.23.10) 43.637 ms 42.601 ms 43.902 ms 15 198.108.22.186 (198.108.22.186) 48.455 ms 51.436 ms 44.070 ms 16 * * * 17 * * * 18 * * * 19 * * * 20 * * * 21 * * * 22 * * * 23 * * * 24 * * * 25 * * * 26 * * * 27 * * * 28 * * * 29 * * * 30 * * * Any ideas? Cheers, -Dr Polar From dave at stayonline.com Tue May 19 17:57:39 2009 From: dave at stayonline.com (Dave Larter) Date: Tue, 19 May 2009 18:57:39 -0400 Subject: MX problems In-Reply-To: References: Message-ID: <8B79B73777E7D544A24BEB8FC50D35DB597B5A@MERCURY.socrdu.com> Hi, I have no problem getting there, is that their mx's? Tracing route to s0.nanog.org [198.108.95.20] over a maximum of 30 hops: 1 117 ms 128 ms 115 ms argon.socrdu.net [64.132.109.136] 2 * 122 ms 126 ms 64.132.109.130 3 125 ms 106 ms 124 ms 64.132.109.129 4 130 ms 125 ms 113 ms 64-132-140-113.static.twtelecom.net [64.132.140.113] 5 129 ms 139 ms 139 ms scor-01-rif1.mtld.twtelecom.net [66.192.243.134] 6 129 ms 137 ms 148 ms te4-2.mpd02.dca01.atlas.cogentco.com [154.54.26.121] 7 152 ms 154 ms 240 ms te7-8.ccr01.jfk02.atlas.cogentco.com [154.54.5.49] 8 158 ms 153 ms 151 ms te9-8.mpd01.bos01.atlas.cogentco.com [154.54.25.242] 9 170 ms 172 ms 167 ms te7-8.ccr01.ord01.atlas.cogentco.com [154.54.7.81] 10 188 ms 172 ms 163 ms te8-2.mpd01.ord03.atlas.cogentco.com [154.54.25.66] 11 194 ms 170 ms 174 ms merit.demarc.cogentco.com [66.28.21.234] 12 164 ms 163 ms 166 ms tenge0-0-0-0x76.aa2.mich.net [198.108.23.10] 13 171 ms 164 ms 171 ms 198.108.22.186 14 171 ms 173 ms 171 ms s0.nanog.org [198.108.95.20] Trace complete. And yes, I only get that one mx/ip for nanog.org. -----Original Message----- From: Polar Humenn [mailto:polar.humenn at gmail.com] Sent: Tuesday, May 19, 2009 6:44 PM To: nanog at nanog.org Subject: MX problems I'm in Syracuse NY, and I'm having problems getting sendmail to get to MX servers, with the errors of "No Route to Host" or "Connection timed Out". Apparently this is been happening for over 5 days. I can send mail within Syracuse University, but as soon as I venture out nothing. Traceroute seems to loose it after about the 9 or 10th hop. It seems that I can get to almost any website, but tracerouting or pinging these MX servers is not happening. Is there anything going on, or at least something that started 5-7 days ago? I find the same problem from within Syracuse Univeristy to my RoadRunner account at home (which does not pass through the university routers). I only noticed it from the university since thats where I usually send my email through. Like I would no have been able to post to this list >From my home machine: > traceroute s0.nanog.org traceroute to s0.nanog.org (198.108.95.20), 30 hops max, 60 byte packets 1 192.168.99.1 (192.168.99.1) 0.211 ms 0.257 ms 0.302 ms 2 10.217.224.1 (10.217.224.1) 13.754 ms 13.855 ms 14.291 ms 3 gig2-2.syrcnysyr-rtr01.nyroc.rr.com (24.92.231.138) 18.442 ms 22.701 ms 26.908 ms 4 gig1-1-0.syrcnyflk-rtr02.nyroc.rr.com (24.92.231.54) 31.279 ms 31.454 ms 31.591 ms 5 ge-4-3-0.albynywav-rtr03.nyroc.rr.com (24.24.7.53) 37.429 ms 37.604 ms 37.779 ms 6 ae-5-0.cr0.nyc30.tbone.rr.com (66.109.6.74) 41.329 ms 18.241 ms 22.192 ms 7 ae-1-0.pr0.nyc20.tbone.rr.com (66.109.6.163) 27.472 ms 19.542 ms 23.419 ms 8 te1-4.mpd01.jfk05.atlas.cogentco.com (154.54.13.185) 28.070 ms 32.824 ms 35.822 ms 9 te9-3.ccr01.jfk02.atlas.cogentco.com (154.54.3.165) 40.796 ms 40.549 ms te2-4.ccr01.jfk02.atlas.cogentco.com (154.54.6.49) 40.958 ms 10 te2-4.mpd01.bos01.atlas.cogentco.com (154.54.5.249) 48.704 ms 47.549 ms 48.468 ms 11 te2-2.ccr01.ord01.atlas.cogentco.com (154.54.6.154) 57.836 ms te8-8.mpd01.ord01.atlas.cogentco.com (154.54.24.54) 58.063 ms te2-2.mpd01.ord01.atlas.cogentco.com (154.54.6.18) 46.700 ms 12 vl3488.mpd01.ord03.atlas.cogentco.com (154.54.5.26) 56.905 ms te3-4.mpd01.ord03.atlas.cogentco.com (154.54.6.206) 56.144 ms vl3488.mpd01.ord03.atlas.cogentco.com (154.54.5.26) 45.245 ms 13 Merit.demarc.cogentco.com (38.112.7.10) 44.512 ms Merit.demarc.cogentco.com (66.28.21.234) 38.385 ms Merit.demarc.cogentco.com (38.112.7.10) 40.305 ms 14 tenge0-0-0-0x76.aa2.mich.net (198.108.23.10) 43.637 ms 42.601 ms 43.902 ms 15 198.108.22.186 (198.108.22.186) 48.455 ms 51.436 ms 44.070 ms 16 * * * 17 * * * 18 * * * 19 * * * 20 * * * 21 * * * 22 * * * 23 * * * 24 * * * 25 * * * 26 * * * 27 * * * 28 * * * 29 * * * 30 * * * Any ideas? Cheers, -Dr Polar From polar.humenn at gmail.com Tue May 19 18:02:05 2009 From: polar.humenn at gmail.com (Polar Humenn) Date: Tue, 19 May 2009 19:02:05 -0400 Subject: MX problems In-Reply-To: <8B79B73777E7D544A24BEB8FC50D35DB597B5A@MERCURY.socrdu.com> References: <8B79B73777E7D544A24BEB8FC50D35DB597B5A@MERCURY.socrdu.com> Message-ID: >From my mail log. Geez, I can't even get to Cornell, which is just down the friggin road! (Yeah, I know, but really). What is going on? May 19 18:58:26 greene postfix/smtp[5895]: connect to mailin-01.mx.AOL.COM[205.188.159.57]: No route to host (port 25) May 19 18:58:27 greene postfix/smtp[5904]: connect to penguin.cs.cornell.edu[128.84.96.11]: No route to host (port 25) May 19 18:58:27 greene postfix/smtp[5899]: connect to mx.vgs.untd.com[64.136.52.37]: No route to host (port 25) May 19 18:58:27 greene postfix/smtp[5919]: connect to incoming3.american.edu[147.9.1.250]: No route to host (port 25) May 19 18:58:30 greene postfix/smtp[5904]: connect to iago.cs.cornell.edu[128.84.96.10]: No route to host (port 25) May 19 18:58:30 greene postfix/smtp[5904]: 0992D8DDE: to=< simeon at cs.cornell.edu>, relay=none, delay=371744, status=deferred (connect to iago.cs.cornell.edu[128.84.96.10]: No route to host) May 19 18:58:30 greene postfix/smtp[5919]: connect to incoming2.american.edu[147.9.1.249]: No route to host (port 25) May 19 18:58:30 greene postfix/smtp[5919]: 5F6AC8C0E: to=, relay=none, delay=116954, status=deferred (connect to incoming2.american.edu[147.9.1.249]: No route to host) May 19 18:58:33 greene postfix/smtp[5901]: connect to cisbec.net.s6a1.psmtp.com[64.18.5.10]: No route to host (port 25) May 19 18:58:33 greene postfix/smtp[5913]: connect to smtp-mx6.mac.com[17.148.20.69]: No route to host (port 25) May 19 18:58:35 greene postfix/smtp[5895]: connect to mailin-01.mx.AOL.COM[205.188.156.248]: No route to host (port 25) May 19 18:58:36 greene postfix/smtp[5899]: connect to mx.dca.untd.com[64.136.44.37]: No route to host (port 25) May 19 18:58:36 greene postfix/smtp[5899]: D3A158876: to=, relay=none, delay=183359, status=deferred (connect to mx.dca.untd.com[64.136.44.37]: No route to host) May 19 18:58:42 greene postfix/smtp[5901]: connect to cisbec.net.s6a2.psmtp.com[64.18.5.11]: No route to host (port 25) May 19 18:58:45 greene postfix/smtp[5901]: connect to cisbec.net.s6b1.psmtp.com[64.18.5.13]: No route to host (port 25) May 19 18:58:45 greene postfix/smtp[5910]: connect to hrndva-smtpin01.mail.rr.com[71.74.56.243]: No route to host (port 25) May 19 18:58:48 greene postfix/smtp[5901]: connect to cisbec.net.s6b2.psmtp.com[64.18.5.14]: No route to host (port 25) May 19 18:58:48 greene postfix/smtp[5901]: 0992D8DDE: to=< arahant1 at cisbec.net>, relay=none, delay=371762, status=deferred (connect to cisbec.net.s6b2.psmtp.com[64.18.5.14]: No route to host) On Tue, May 19, 2009 at 6:57 PM, Dave Larter wrote: > Hi, I have no problem getting there, is that their mx's? > > Tracing route to s0.nanog.org [198.108.95.20] > over a maximum of 30 hops: > > 1 117 ms 128 ms 115 ms argon.socrdu.net [64.132.109.136] > 2 * 122 ms 126 ms 64.132.109.130 > 3 125 ms 106 ms 124 ms 64.132.109.129 > 4 130 ms 125 ms 113 ms 64-132-140-113.static.twtelecom.net > [64.132.140.113] > 5 129 ms 139 ms 139 ms scor-01-rif1.mtld.twtelecom.net > [66.192.243.134] > 6 129 ms 137 ms 148 ms te4-2.mpd02.dca01.atlas.cogentco.com > [154.54.26.121] > 7 152 ms 154 ms 240 ms te7-8.ccr01.jfk02.atlas.cogentco.com > [154.54.5.49] > 8 158 ms 153 ms 151 ms te9-8.mpd01.bos01.atlas.cogentco.com > [154.54.25.242] > 9 170 ms 172 ms 167 ms te7-8.ccr01.ord01.atlas.cogentco.com > [154.54.7.81] > 10 188 ms 172 ms 163 ms te8-2.mpd01.ord03.atlas.cogentco.com > [154.54.25.66] > 11 194 ms 170 ms 174 ms merit.demarc.cogentco.com [66.28.21.234] > 12 164 ms 163 ms 166 ms tenge0-0-0-0x76.aa2.mich.net > [198.108.23.10] > 13 171 ms 164 ms 171 ms 198.108.22.186 > 14 171 ms 173 ms 171 ms s0.nanog.org [198.108.95.20] > > Trace complete. > > And yes, I only get that one mx/ip for nanog.org. > > -----Original Message----- > From: Polar Humenn [mailto:polar.humenn at gmail.com] > Sent: Tuesday, May 19, 2009 6:44 PM > To: nanog at nanog.org > Subject: MX problems > > I'm in Syracuse NY, and I'm having problems getting sendmail to get to > MX > servers, with the errors of "No Route to Host" or "Connection timed > Out". > Apparently this is been happening for over 5 days. I can send mail > within > Syracuse University, but as soon as I venture out nothing. Traceroute > seems > to loose it after about the 9 or 10th hop. > > It seems that I can get to almost any website, but tracerouting or > pinging > these MX servers is not happening. > > Is there anything going on, or at least something that started 5-7 days > ago? > > I find the same problem from within Syracuse Univeristy to my RoadRunner > account at home (which does not pass through the university routers). I > only > noticed it from the university since thats where I usually send my email > through. Like I would no have been able to post to this list > > >From my home machine: > > traceroute s0.nanog.org > traceroute to s0.nanog.org (198.108.95.20), 30 hops max, 60 byte packets > 1 192.168.99.1 (192.168.99.1) 0.211 ms 0.257 ms 0.302 ms > 2 10.217.224.1 (10.217.224.1) 13.754 ms 13.855 ms 14.291 ms > 3 gig2-2.syrcnysyr-rtr01.nyroc.rr.com (24.92.231.138) 18.442 ms > 22.701 > ms 26.908 ms > 4 gig1-1-0.syrcnyflk-rtr02.nyroc.rr.com (24.92.231.54) 31.279 ms > 31.454 > ms 31.591 ms > 5 ge-4-3-0.albynywav-rtr03.nyroc.rr.com (24.24.7.53) 37.429 ms > 37.604 > ms 37.779 ms > 6 ae-5-0.cr0.nyc30.tbone.rr.com (66.109.6.74) 41.329 ms 18.241 ms > 22.192 ms > 7 ae-1-0.pr0.nyc20.tbone.rr.com (66.109.6.163) 27.472 ms 19.542 ms > 23.419 ms > 8 te1-4.mpd01.jfk05.atlas.cogentco.com (154.54.13.185) 28.070 ms > 32.824 > ms 35.822 ms > 9 te9-3.ccr01.jfk02.atlas.cogentco.com (154.54.3.165) 40.796 ms > 40.549 > ms te2-4.ccr01.jfk02.atlas.cogentco.com (154.54.6.49) 40.958 ms > 10 te2-4.mpd01.bos01.atlas.cogentco.com (154.54.5.249) 48.704 ms > 47.549 > ms 48.468 ms > 11 te2-2.ccr01.ord01.atlas.cogentco.com (154.54.6.154) 57.836 ms > te8-8.mpd01.ord01.atlas.cogentco.com (154.54.24.54) 58.063 ms > te2-2.mpd01.ord01.atlas.cogentco.com (154.54.6.18) 46.700 ms > 12 vl3488.mpd01.ord03.atlas.cogentco.com (154.54.5.26) 56.905 ms > te3-4.mpd01.ord03.atlas.cogentco.com (154.54.6.206) 56.144 ms > vl3488.mpd01.ord03.atlas.cogentco.com (154.54.5.26) 45.245 ms > 13 Merit.demarc.cogentco.com (38.112.7.10) 44.512 ms > Merit.demarc.cogentco.com (66.28.21.234) 38.385 ms > Merit.demarc.cogentco.com (38.112.7.10) 40.305 ms > 14 tenge0-0-0-0x76.aa2.mich.net (198.108.23.10) 43.637 ms 42.601 ms > 43.902 ms > 15 198.108.22.186 (198.108.22.186) 48.455 ms 51.436 ms 44.070 ms > 16 * * * > 17 * * * > 18 * * * > 19 * * * > 20 * * * > 21 * * * > 22 * * * > 23 * * * > 24 * * * > 25 * * * > 26 * * * > 27 * * * > 28 * * * > 29 * * * > 30 * * * > > > Any ideas? > Cheers, > -Dr Polar > From cordmacleod at gmail.com Tue May 19 18:02:22 2009 From: cordmacleod at gmail.com (Cord MacLeod) Date: Tue, 19 May 2009 16:02:22 -0700 Subject: MX problems In-Reply-To: <8B79B73777E7D544A24BEB8FC50D35DB597B5A@MERCURY.socrdu.com> References: <8B79B73777E7D544A24BEB8FC50D35DB597B5A@MERCURY.socrdu.com> Message-ID: <12D2AC08-BDFA-42B6-A8AE-0FFD3E18E7A2@gmail.com> http://en.wikipedia.org/wiki/Traceroute You are looking for the difference between UDP and ICMP in that article. On May 19, 2009, at 3:57 PM, Dave Larter wrote: > Hi, I have no problem getting there, is that their mx's? > > Tracing route to s0.nanog.org [198.108.95.20] > over a maximum of 30 hops: > > 1 117 ms 128 ms 115 ms argon.socrdu.net [64.132.109.136] > 2 * 122 ms 126 ms 64.132.109.130 > 3 125 ms 106 ms 124 ms 64.132.109.129 > 4 130 ms 125 ms 113 ms 64-132-140-113.static.twtelecom.net > [64.132.140.113] > 5 129 ms 139 ms 139 ms scor-01-rif1.mtld.twtelecom.net > [66.192.243.134] > 6 129 ms 137 ms 148 ms te4-2.mpd02.dca01.atlas.cogentco.com > [154.54.26.121] > 7 152 ms 154 ms 240 ms te7-8.ccr01.jfk02.atlas.cogentco.com > [154.54.5.49] > 8 158 ms 153 ms 151 ms te9-8.mpd01.bos01.atlas.cogentco.com > [154.54.25.242] > 9 170 ms 172 ms 167 ms te7-8.ccr01.ord01.atlas.cogentco.com > [154.54.7.81] > 10 188 ms 172 ms 163 ms te8-2.mpd01.ord03.atlas.cogentco.com > [154.54.25.66] > 11 194 ms 170 ms 174 ms merit.demarc.cogentco.com > [66.28.21.234] > 12 164 ms 163 ms 166 ms tenge0-0-0-0x76.aa2.mich.net > [198.108.23.10] > 13 171 ms 164 ms 171 ms 198.108.22.186 > 14 171 ms 173 ms 171 ms s0.nanog.org [198.108.95.20] > > Trace complete. > > And yes, I only get that one mx/ip for nanog.org. > > -----Original Message----- > From: Polar Humenn [mailto:polar.humenn at gmail.com] > Sent: Tuesday, May 19, 2009 6:44 PM > To: nanog at nanog.org > Subject: MX problems > > I'm in Syracuse NY, and I'm having problems getting sendmail to get to > MX > servers, with the errors of "No Route to Host" or "Connection timed > Out". > Apparently this is been happening for over 5 days. I can send mail > within > Syracuse University, but as soon as I venture out nothing. Traceroute > seems > to loose it after about the 9 or 10th hop. > > It seems that I can get to almost any website, but tracerouting or > pinging > these MX servers is not happening. > > Is there anything going on, or at least something that started 5-7 > days > ago? > > I find the same problem from within Syracuse Univeristy to my > RoadRunner > account at home (which does not pass through the university > routers). I > only > noticed it from the university since thats where I usually send my > email > through. Like I would no have been able to post to this list > >> From my home machine: >> traceroute s0.nanog.org > traceroute to s0.nanog.org (198.108.95.20), 30 hops max, 60 byte > packets > 1 192.168.99.1 (192.168.99.1) 0.211 ms 0.257 ms 0.302 ms > 2 10.217.224.1 (10.217.224.1) 13.754 ms 13.855 ms 14.291 ms > 3 gig2-2.syrcnysyr-rtr01.nyroc.rr.com (24.92.231.138) 18.442 ms > 22.701 > ms 26.908 ms > 4 gig1-1-0.syrcnyflk-rtr02.nyroc.rr.com (24.92.231.54) 31.279 ms > 31.454 > ms 31.591 ms > 5 ge-4-3-0.albynywav-rtr03.nyroc.rr.com (24.24.7.53) 37.429 ms > 37.604 > ms 37.779 ms > 6 ae-5-0.cr0.nyc30.tbone.rr.com (66.109.6.74) 41.329 ms 18.241 ms > 22.192 ms > 7 ae-1-0.pr0.nyc20.tbone.rr.com (66.109.6.163) 27.472 ms 19.542 ms > 23.419 ms > 8 te1-4.mpd01.jfk05.atlas.cogentco.com (154.54.13.185) 28.070 ms > 32.824 > ms 35.822 ms > 9 te9-3.ccr01.jfk02.atlas.cogentco.com (154.54.3.165) 40.796 ms > 40.549 > ms te2-4.ccr01.jfk02.atlas.cogentco.com (154.54.6.49) 40.958 ms > 10 te2-4.mpd01.bos01.atlas.cogentco.com (154.54.5.249) 48.704 ms > 47.549 > ms 48.468 ms > 11 te2-2.ccr01.ord01.atlas.cogentco.com (154.54.6.154) 57.836 ms > te8-8.mpd01.ord01.atlas.cogentco.com (154.54.24.54) 58.063 ms > te2-2.mpd01.ord01.atlas.cogentco.com (154.54.6.18) 46.700 ms > 12 vl3488.mpd01.ord03.atlas.cogentco.com (154.54.5.26) 56.905 ms > te3-4.mpd01.ord03.atlas.cogentco.com (154.54.6.206) 56.144 ms > vl3488.mpd01.ord03.atlas.cogentco.com (154.54.5.26) 45.245 ms > 13 Merit.demarc.cogentco.com (38.112.7.10) 44.512 ms > Merit.demarc.cogentco.com (66.28.21.234) 38.385 ms > Merit.demarc.cogentco.com (38.112.7.10) 40.305 ms > 14 tenge0-0-0-0x76.aa2.mich.net (198.108.23.10) 43.637 ms 42.601 ms > 43.902 ms > 15 198.108.22.186 (198.108.22.186) 48.455 ms 51.436 ms 44.070 ms > 16 * * * > 17 * * * > 18 * * * > 19 * * * > 20 * * * > 21 * * * > 22 * * * > 23 * * * > 24 * * * > 25 * * * > 26 * * * > 27 * * * > 28 * * * > 29 * * * > 30 * * * > > > Any ideas? > Cheers, > -Dr Polar > From dave at stayonline.com Tue May 19 18:07:41 2009 From: dave at stayonline.com (Dave Larter) Date: Tue, 19 May 2009 19:07:41 -0400 Subject: MX problems In-Reply-To: References: <8B79B73777E7D544A24BEB8FC50D35DB597B5A@MERCURY.socrdu.com> Message-ID: <8B79B73777E7D544A24BEB8FC50D35DB597B5B@MERCURY.socrdu.com> Did you flush your dns cache? Its happened to me before, couldn't resolve our own domains, turned out to be a bad switch, for almost everything it worked fine but had intermittent problems with 53. I have seen it before with other prots too. From: Polar Humenn [mailto:polar.humenn at gmail.com] Sent: Tuesday, May 19, 2009 7:02 PM To: Dave Larter Cc: nanog at nanog.org Subject: Re: MX problems >From my mail log. Geez, I can't even get to Cornell, which is just down the friggin road! (Yeah, I know, but really). What is going on? May 19 18:58:26 greene postfix/smtp[5895]: connect to mailin-01.mx.AOL.COM[205.188.159.57]: No route to host (port 25) May 19 18:58:27 greene postfix/smtp[5904]: connect to penguin.cs.cornell.edu[128.84.96.11]: No route to host (port 25) May 19 18:58:27 greene postfix/smtp[5899]: connect to mx.vgs.untd.com[64.136.52.37]: No route to host (port 25) May 19 18:58:27 greene postfix/smtp[5919]: connect to incoming3.american.edu[147.9.1.250]: No route to host (port 25) May 19 18:58:30 greene postfix/smtp[5904]: connect to iago.cs.cornell.edu[128.84.96.10]: No route to host (port 25) May 19 18:58:30 greene postfix/smtp[5904]: 0992D8DDE: to=, relay=none, delay=371744, status=deferred (connect to iago.cs.cornell.edu[128.84.96.10]: No route to host) May 19 18:58:30 greene postfix/smtp[5919]: connect to incoming2.american.edu[147.9.1.249]: No route to host (port 25) May 19 18:58:30 greene postfix/smtp[5919]: 5F6AC8C0E: to=, relay=none, delay=116954, status=deferred (connect to incoming2.american.edu[147.9.1.249]: No route to host) May 19 18:58:33 greene postfix/smtp[5901]: connect to cisbec.net.s6a1.psmtp.com[64.18.5.10]: No route to host (port 25) May 19 18:58:33 greene postfix/smtp[5913]: connect to smtp-mx6.mac.com[17.148.20.69]: No route to host (port 25) May 19 18:58:35 greene postfix/smtp[5895]: connect to mailin-01.mx.AOL.COM[205.188.156.248]: No route to host (port 25) May 19 18:58:36 greene postfix/smtp[5899]: connect to mx.dca.untd.com[64.136.44.37]: No route to host (port 25) May 19 18:58:36 greene postfix/smtp[5899]: D3A158876: to=, relay=none, delay=183359, status=deferred (connect to mx.dca.untd.com[64.136.44.37]: No route to host) May 19 18:58:42 greene postfix/smtp[5901]: connect to cisbec.net.s6a2.psmtp.com[64.18.5.11]: No route to host (port 25) May 19 18:58:45 greene postfix/smtp[5901]: connect to cisbec.net.s6b1.psmtp.com[64.18.5.13]: No route to host (port 25) May 19 18:58:45 greene postfix/smtp[5910]: connect to hrndva-smtpin01.mail.rr.com[71.74.56.243]: No route to host (port 25) May 19 18:58:48 greene postfix/smtp[5901]: connect to cisbec.net.s6b2.psmtp.com[64.18.5.14]: No route to host (port 25) May 19 18:58:48 greene postfix/smtp[5901]: 0992D8DDE: to=, relay=none, delay=371762, status=deferred (connect to cisbec.net.s6b2.psmtp.com[64.18.5.14]: No route to host) On Tue, May 19, 2009 at 6:57 PM, Dave Larter wrote: Hi, I have no problem getting there, is that their mx's? Tracing route to s0.nanog.org [198.108.95.20] over a maximum of 30 hops: 1 117 ms 128 ms 115 ms argon.socrdu.net [64.132.109.136] 2 * 122 ms 126 ms 64.132.109.130 3 125 ms 106 ms 124 ms 64.132.109.129 4 130 ms 125 ms 113 ms 64-132-140-113.static.twtelecom.net [64.132.140.113] 5 129 ms 139 ms 139 ms scor-01-rif1.mtld.twtelecom.net [66.192.243.134] 6 129 ms 137 ms 148 ms te4-2.mpd02.dca01.atlas.cogentco.com [154.54.26.121] 7 152 ms 154 ms 240 ms te7-8.ccr01.jfk02.atlas.cogentco.com [154.54.5.49] 8 158 ms 153 ms 151 ms te9-8.mpd01.bos01.atlas.cogentco.com [154.54.25.242] 9 170 ms 172 ms 167 ms te7-8.ccr01.ord01.atlas.cogentco.com [154.54.7.81] 10 188 ms 172 ms 163 ms te8-2.mpd01.ord03.atlas.cogentco.com [154.54.25.66] 11 194 ms 170 ms 174 ms merit.demarc.cogentco.com [66.28.21.234] 12 164 ms 163 ms 166 ms tenge0-0-0-0x76.aa2.mich.net [198.108.23.10] 13 171 ms 164 ms 171 ms 198.108.22.186 14 171 ms 173 ms 171 ms s0.nanog.org [198.108.95.20] Trace complete. And yes, I only get that one mx/ip for nanog.org. -----Original Message----- From: Polar Humenn [mailto:polar.humenn at gmail.com] Sent: Tuesday, May 19, 2009 6:44 PM To: nanog at nanog.org Subject: MX problems I'm in Syracuse NY, and I'm having problems getting sendmail to get to MX servers, with the errors of "No Route to Host" or "Connection timed Out". Apparently this is been happening for over 5 days. I can send mail within Syracuse University, but as soon as I venture out nothing. Traceroute seems to loose it after about the 9 or 10th hop. It seems that I can get to almost any website, but tracerouting or pinging these MX servers is not happening. Is there anything going on, or at least something that started 5-7 days ago? I find the same problem from within Syracuse Univeristy to my RoadRunner account at home (which does not pass through the university routers). I only noticed it from the university since thats where I usually send my email through. Like I would no have been able to post to this list >From my home machine: > traceroute s0.nanog.org traceroute to s0.nanog.org (198.108.95.20), 30 hops max, 60 byte packets 1 192.168.99.1 (192.168.99.1) 0.211 ms 0.257 ms 0.302 ms 2 10.217.224.1 (10.217.224.1) 13.754 ms 13.855 ms 14.291 ms 3 gig2-2.syrcnysyr-rtr01.nyroc.rr.com (24.92.231.138) 18.442 ms 22.701 ms 26.908 ms 4 gig1-1-0.syrcnyflk-rtr02.nyroc.rr.com (24.92.231.54) 31.279 ms 31.454 ms 31.591 ms 5 ge-4-3-0.albynywav-rtr03.nyroc.rr.com (24.24.7.53) 37.429 ms 37.604 ms 37.779 ms 6 ae-5-0.cr0.nyc30.tbone.rr.com (66.109.6.74) 41.329 ms 18.241 ms 22.192 ms 7 ae-1-0.pr0.nyc20.tbone.rr.com (66.109.6.163) 27.472 ms 19.542 ms 23.419 ms 8 te1-4.mpd01.jfk05.atlas.cogentco.com (154.54.13.185) 28.070 ms 32.824 ms 35.822 ms 9 te9-3.ccr01.jfk02.atlas.cogentco.com (154.54.3.165) 40.796 ms 40.549 ms te2-4.ccr01.jfk02.atlas.cogentco.com (154.54.6.49) 40.958 ms 10 te2-4.mpd01.bos01.atlas.cogentco.com (154.54.5.249) 48.704 ms 47.549 ms 48.468 ms 11 te2-2.ccr01.ord01.atlas.cogentco.com (154.54.6.154) 57.836 ms te8-8.mpd01.ord01.atlas.cogentco.com (154.54.24.54) 58.063 ms te2-2.mpd01.ord01.atlas.cogentco.com (154.54.6.18) 46.700 ms 12 vl3488.mpd01.ord03.atlas.cogentco.com (154.54.5.26) 56.905 ms te3-4.mpd01.ord03.atlas.cogentco.com (154.54.6.206) 56.144 ms vl3488.mpd01.ord03.atlas.cogentco.com (154.54.5.26) 45.245 ms 13 Merit.demarc.cogentco.com (38.112.7.10) 44.512 ms Merit.demarc.cogentco.com (66.28.21.234) 38.385 ms Merit.demarc.cogentco.com (38.112.7.10) 40.305 ms 14 tenge0-0-0-0x76.aa2.mich.net (198.108.23.10) 43.637 ms 42.601 ms 43.902 ms 15 198.108.22.186 (198.108.22.186) 48.455 ms 51.436 ms 44.070 ms 16 * * * 17 * * * 18 * * * 19 * * * 20 * * * 21 * * * 22 * * * 23 * * * 24 * * * 25 * * * 26 * * * 27 * * * 28 * * * 29 * * * 30 * * * Any ideas? Cheers, -Dr Polar From andy at siliconlandmark.com Tue May 19 18:14:02 2009 From: andy at siliconlandmark.com (Andre Guibert de Bruet) Date: Tue, 19 May 2009 19:14:02 -0400 Subject: MX problems In-Reply-To: <8B79B73777E7D544A24BEB8FC50D35DB597B5B@MERCURY.socrdu.com> References: <8B79B73777E7D544A24BEB8FC50D35DB597B5A@MERCURY.socrdu.com> <8B79B73777E7D544A24BEB8FC50D35DB597B5B@MERCURY.socrdu.com> Message-ID: Hi, This doesn't appear to be DNS related. You can see from the trace that the forward resolution is in fact occurring just fine. It would appear that Comcast/RoadRunner filters SMTP in your market (A quick Google search indicates that this has been happening in various places since at least 2004). Do you still have issues if you try using their SMTP servers? Cheers, /* Andre Guibert de Bruet * 436f 6465 2070 6f65 742e 2042 6974 206a */ /* Managing Partner * 6f63 6b65 792e 2053 7973 4164 6d69 6e2e */ /* GSM: +1 734 846 8758 * 2055 4e49 5820 736c 6575 7468 2e00 0000 */ /* WWW: siliconlandmark.com * C/C++, Java, Perl, PHP, SQL, XHTML, XML */ On May 19, 2009, at 7:07 PM, Dave Larter wrote: > Did you flush your dns cache? Its happened to me before, couldn't > resolve our own domains, turned out to be a bad switch, for almost > everything it worked fine but had intermittent problems with 53. I > have > seen it before with other prots too. > > > > From: Polar Humenn [mailto:polar.humenn at gmail.com] > Sent: Tuesday, May 19, 2009 7:02 PM > To: Dave Larter > Cc: nanog at nanog.org > Subject: Re: MX problems > > > >> From my mail log. Geez, I can't even get to Cornell, which is just >> down > the friggin road! (Yeah, I know, but really). > What is going on? > > May 19 18:58:26 greene postfix/smtp[5895]: connect to > mailin-01.mx.AOL.COM[205.188.159.57]: No route to host (port 25) > May 19 18:58:27 greene postfix/smtp[5904]: connect to > penguin.cs.cornell.edu[128.84.96.11]: No route to host (port 25) > May 19 18:58:27 greene postfix/smtp[5899]: connect to > mx.vgs.untd.com[64.136.52.37]: No route to host (port 25) > May 19 18:58:27 greene postfix/smtp[5919]: connect to > incoming3.american.edu[147.9.1.250]: No route to host (port 25) > May 19 18:58:30 greene postfix/smtp[5904]: connect to > iago.cs.cornell.edu[128.84.96.10]: No route to host (port 25) > May 19 18:58:30 greene postfix/smtp[5904]: 0992D8DDE: > to=, relay=none, delay=371744, status=deferred > (connect to iago.cs.cornell.edu[128.84.96.10]: No route to host) > May 19 18:58:30 greene postfix/smtp[5919]: connect to > incoming2.american.edu[147.9.1.249]: No route to host (port 25) > May 19 18:58:30 greene postfix/smtp[5919]: 5F6AC8C0E: > to=, relay=none, delay=116954, status=deferred > (connect > to incoming2.american.edu[147.9.1.249]: No route to host) > May 19 18:58:33 greene postfix/smtp[5901]: connect to > cisbec.net.s6a1.psmtp.com[64.18.5.10]: No route to host (port 25) > May 19 18:58:33 greene postfix/smtp[5913]: connect to > smtp-mx6.mac.com[17.148.20.69]: No route to host (port 25) > May 19 18:58:35 greene postfix/smtp[5895]: connect to > mailin-01.mx.AOL.COM[205.188.156.248]: No route to host (port 25) > May 19 18:58:36 greene postfix/smtp[5899]: connect to > mx.dca.untd.com[64.136.44.37]: No route to host (port 25) > May 19 18:58:36 greene postfix/smtp[5899]: D3A158876: > to=, relay=none, delay=183359, status=deferred > (connect to mx.dca.untd.com[64.136.44.37]: No route to host) > May 19 18:58:42 greene postfix/smtp[5901]: connect to > cisbec.net.s6a2.psmtp.com[64.18.5.11]: No route to host (port 25) > May 19 18:58:45 greene postfix/smtp[5901]: connect to > cisbec.net.s6b1.psmtp.com[64.18.5.13]: No route to host (port 25) > May 19 18:58:45 greene postfix/smtp[5910]: connect to > hrndva-smtpin01.mail.rr.com[71.74.56.243]: No route to host (port 25) > May 19 18:58:48 greene postfix/smtp[5901]: connect to > cisbec.net.s6b2.psmtp.com[64.18.5.14]: No route to host (port 25) > May 19 18:58:48 greene postfix/smtp[5901]: 0992D8DDE: > to=, relay=none, delay=371762, status=deferred > (connect to cisbec.net.s6b2.psmtp.com[64.18.5.14]: No route to host) > > > > On Tue, May 19, 2009 at 6:57 PM, Dave Larter > wrote: > > Hi, I have no problem getting there, is that their mx's? > > Tracing route to s0.nanog.org [198.108.95.20] > over a maximum of 30 hops: > > 1 117 ms 128 ms 115 ms argon.socrdu.net [64.132.109.136] > 2 * 122 ms 126 ms 64.132.109.130 > 3 125 ms 106 ms 124 ms 64.132.109.129 > 4 130 ms 125 ms 113 ms 64-132-140-113.static.twtelecom.net > [64.132.140.113] > 5 129 ms 139 ms 139 ms scor-01-rif1.mtld.twtelecom.net > [66.192.243.134] > 6 129 ms 137 ms 148 ms te4-2.mpd02.dca01.atlas.cogentco.com > [154.54.26.121] > 7 152 ms 154 ms 240 ms te7-8.ccr01.jfk02.atlas.cogentco.com > [154.54.5.49] > 8 158 ms 153 ms 151 ms te9-8.mpd01.bos01.atlas.cogentco.com > [154.54.25.242] > 9 170 ms 172 ms 167 ms te7-8.ccr01.ord01.atlas.cogentco.com > [154.54.7.81] > 10 188 ms 172 ms 163 ms te8-2.mpd01.ord03.atlas.cogentco.com > [154.54.25.66] > 11 194 ms 170 ms 174 ms merit.demarc.cogentco.com > [66.28.21.234] > 12 164 ms 163 ms 166 ms tenge0-0-0-0x76.aa2.mich.net > [198.108.23.10] > 13 171 ms 164 ms 171 ms 198.108.22.186 > 14 171 ms 173 ms 171 ms s0.nanog.org [198.108.95.20] > > Trace complete. > > And yes, I only get that one mx/ip for nanog.org. > > > -----Original Message----- > From: Polar Humenn [mailto:polar.humenn at gmail.com] > Sent: Tuesday, May 19, 2009 6:44 PM > To: nanog at nanog.org > Subject: MX problems > > I'm in Syracuse NY, and I'm having problems getting sendmail to get to > MX > servers, with the errors of "No Route to Host" or "Connection timed > Out". > Apparently this is been happening for over 5 days. I can send mail > within > Syracuse University, but as soon as I venture out nothing. Traceroute > seems > to loose it after about the 9 or 10th hop. > > It seems that I can get to almost any website, but tracerouting or > pinging > these MX servers is not happening. > > Is there anything going on, or at least something that started 5-7 > days > ago? > > I find the same problem from within Syracuse Univeristy to my > RoadRunner > account at home (which does not pass through the university > routers). I > only > noticed it from the university since thats where I usually send my > email > through. Like I would no have been able to post to this list > >> From my home machine: >> traceroute s0.nanog.org > traceroute to s0.nanog.org (198.108.95.20), 30 hops max, 60 byte > packets > 1 192.168.99.1 (192.168.99.1) 0.211 ms 0.257 ms 0.302 ms > 2 10.217.224.1 (10.217.224.1) 13.754 ms 13.855 ms 14.291 ms > 3 gig2-2.syrcnysyr-rtr01.nyroc.rr.com (24.92.231.138) 18.442 ms > 22.701 > ms 26.908 ms > 4 gig1-1-0.syrcnyflk-rtr02.nyroc.rr.com (24.92.231.54) 31.279 ms > 31.454 > ms 31.591 ms > 5 ge-4-3-0.albynywav-rtr03.nyroc.rr.com (24.24.7.53) 37.429 ms > 37.604 > ms 37.779 ms > 6 ae-5-0.cr0.nyc30.tbone.rr.com (66.109.6.74) 41.329 ms 18.241 ms > 22.192 ms > 7 ae-1-0.pr0.nyc20.tbone.rr.com (66.109.6.163) 27.472 ms 19.542 ms > 23.419 ms > 8 te1-4.mpd01.jfk05.atlas.cogentco.com (154.54.13.185) 28.070 ms > 32.824 > ms 35.822 ms > 9 te9-3.ccr01.jfk02.atlas.cogentco.com (154.54.3.165) 40.796 ms > 40.549 > ms te2-4.ccr01.jfk02.atlas.cogentco.com (154.54.6.49) 40.958 ms > 10 te2-4.mpd01.bos01.atlas.cogentco.com (154.54.5.249) 48.704 ms > 47.549 > ms 48.468 ms > 11 te2-2.ccr01.ord01.atlas.cogentco.com (154.54.6.154) 57.836 ms > te8-8.mpd01.ord01.atlas.cogentco.com (154.54.24.54) 58.063 ms > te2-2.mpd01.ord01.atlas.cogentco.com (154.54.6.18) 46.700 ms > 12 vl3488.mpd01.ord03.atlas.cogentco.com (154.54.5.26) 56.905 ms > te3-4.mpd01.ord03.atlas.cogentco.com (154.54.6.206) 56.144 ms > vl3488.mpd01.ord03.atlas.cogentco.com (154.54.5.26) 45.245 ms > 13 Merit.demarc.cogentco.com (38.112.7.10) 44.512 ms > Merit.demarc.cogentco.com (66.28.21.234) 38.385 ms > Merit.demarc.cogentco.com (38.112.7.10) 40.305 ms > 14 tenge0-0-0-0x76.aa2.mich.net (198.108.23.10) 43.637 ms 42.601 ms > 43.902 ms > 15 198.108.22.186 (198.108.22.186) 48.455 ms 51.436 ms 44.070 ms > 16 * * * > 17 * * * > 18 * * * > 19 * * * > 20 * * * > 21 * * * > 22 * * * > 23 * * * > 24 * * * > 25 * * * > 26 * * * > 27 * * * > 28 * * * > 29 * * * > 30 * * * > > > Any ideas? > Cheers, > -Dr Polar > > From gmclean at xilogix.net Tue May 19 18:19:23 2009 From: gmclean at xilogix.net (Gregory McLean) Date: Tue, 19 May 2009 19:19:23 -0400 Subject: MX problems In-Reply-To: References: <8B79B73777E7D544A24BEB8FC50D35DB597B5A@MERCURY.socrdu.com> Message-ID: <1242775163.28540.4.camel@developer.gxsnmp.org> On Tue, 2009-05-19 at 19:02 -0400, Polar Humenn wrote: > >From my mail log. Geez, I can't even get to Cornell, which is just down the > friggin road! (Yeah, I know, but really). > What is going on? > > May 19 18:58:26 greene postfix/smtp[5895]: connect to > mailin-01.mx.AOL.COM[205.188.159.57]: > No route to host (port 25) > May 19 18:58:27 greene postfix/smtp[5904]: connect to > penguin.cs.cornell.edu[128.84.96.11]: > No route to host (port 25) > May 19 18:58:27 greene postfix/smtp[5899]: connect to > mx.vgs.untd.com[64.136.52.37]: > No route to host (port 25) > May 19 18:58:27 greene postfix/smtp[5919]: connect to > incoming3.american.edu[147.9.1.250]: > No route to host (port 25) > May 19 18:58:30 greene postfix/smtp[5904]: connect to > iago.cs.cornell.edu[128.84.96.10]: > No route to host (port 25) > May 19 18:58:30 greene postfix/smtp[5904]: 0992D8DDE: to=< > simeon at cs.cornell.edu>, relay=none, delay=371744, status=deferred (connect > to iago.cs.cornell.edu[128.84.96.10]: No route to host) > May 19 18:58:30 greene postfix/smtp[5919]: connect to > incoming2.american.edu[147.9.1.249]: > No route to host (port 25) > May 19 18:58:30 greene postfix/smtp[5919]: 5F6AC8C0E: to=, > relay=none, delay=116954, status=deferred (connect to > incoming2.american.edu[147.9.1.249]: > No route to host) > May 19 18:58:33 greene postfix/smtp[5901]: connect to > cisbec.net.s6a1.psmtp.com[64.18.5.10]: No route to host (port 25) > May 19 18:58:33 greene postfix/smtp[5913]: connect to > smtp-mx6.mac.com[17.148.20.69]: > No route to host (port 25) > May 19 18:58:35 greene postfix/smtp[5895]: connect to > mailin-01.mx.AOL.COM[205.188.156.248]: > No route to host (port 25) > May 19 18:58:36 greene postfix/smtp[5899]: connect to > mx.dca.untd.com[64.136.44.37]: > No route to host (port 25) > May 19 18:58:36 greene postfix/smtp[5899]: D3A158876: to=, > relay=none, delay=183359, status=deferred (connect to > mx.dca.untd.com[64.136.44.37]: > No route to host) > May 19 18:58:42 greene postfix/smtp[5901]: connect to > cisbec.net.s6a2.psmtp.com[64.18.5.11]: No route to host (port 25) > May 19 18:58:45 greene postfix/smtp[5901]: connect to > cisbec.net.s6b1.psmtp.com[64.18.5.13]: No route to host (port 25) > May 19 18:58:45 greene postfix/smtp[5910]: connect to > hrndva-smtpin01.mail.rr.com[71.74.56.243]: No route to host (port 25) > May 19 18:58:48 greene postfix/smtp[5901]: connect to > cisbec.net.s6b2.psmtp.com[64.18.5.14]: No route to host (port 25) > May 19 18:58:48 greene postfix/smtp[5901]: 0992D8DDE: to=< > arahant1 at cisbec.net>, relay=none, delay=371762, status=deferred (connect to > cisbec.net.s6b2.psmtp.com[64.18.5.14]: No route to host) > I smell a port blocking going on... Or a mis config on a firewall. (A firewall/router set to reject with icmp-host-prohibited) That would be my guess. From jay at west.net Tue May 19 18:19:48 2009 From: jay at west.net (Jay Hennigan) Date: Tue, 19 May 2009 16:19:48 -0700 Subject: MX problems In-Reply-To: References: Message-ID: <4A133E94.9060406@west.net> Polar Humenn wrote: > I'm in Syracuse NY, and I'm having problems getting sendmail to get to MX > servers, with the errors of "No Route to Host" or "Connection timed Out". > Apparently this is been happening for over 5 days. I can send mail within > Syracuse University, but as soon as I venture out nothing. Traceroute seems > to loose it after about the 9 or 10th hop. > > It seems that I can get to almost any website, but tracerouting or pinging > these MX servers is not happening. > > Is there anything going on, or at least something that started 5-7 days ago? > > I find the same problem from within Syracuse Univeristy to my RoadRunner > account at home (which does not pass through the university routers). I only > noticed it from the university since thats where I usually send my email > through. Like I would no have been able to post to this list Many ISPs, especially for residential and similar customers, filter TCP 25 outbound and provide a "smart host" MTA on net for their customers to use for sending outbound mail. This is an anti-abuse measure. If an offnet MX host returns pings but times out when you telnet to port 25, you're probably being filtered (somewhat) locally. -- Jay Hennigan - CCIE #7880 - Network Engineering - jay at impulse.net Impulse Internet Service - http://www.impulse.net/ Your local telephone and internet company - 805 884-6323 - WB6RDV From wbailey at gci.com Tue May 19 18:24:04 2009 From: wbailey at gci.com (Warren Bailey) Date: Tue, 19 May 2009 15:24:04 -0800 Subject: MX problems Message-ID: <5B3743FC2D0D8B41B27EE4F5EACA79D108970F4D@DTN1EX01.gci.com> Or... His provider is using dpi to drop packets destined for non provider mx servers. This would certainly reduce spam from compromised hosts. ----- Original Message ----- From: Gregory McLean To: Polar Humenn Cc: nanog at nanog.org Sent: Tue May 19 15:19:23 2009 Subject: Re: MX problems On Tue, 2009-05-19 at 19:02 -0400, Polar Humenn wrote: > >From my mail log. Geez, I can't even get to Cornell, which is just down the > friggin road! (Yeah, I know, but really). > What is going on? > > May 19 18:58:26 greene postfix/smtp[5895]: connect to > mailin-01.mx.AOL.COM[205.188.159.57]: > No route to host (port 25) > May 19 18:58:27 greene postfix/smtp[5904]: connect to > penguin.cs.cornell.edu[128.84.96.11]: > No route to host (port 25) > May 19 18:58:27 greene postfix/smtp[5899]: connect to > mx.vgs.untd.com[64.136.52.37]: > No route to host (port 25) > May 19 18:58:27 greene postfix/smtp[5919]: connect to > incoming3.american.edu[147.9.1.250]: > No route to host (port 25) > May 19 18:58:30 greene postfix/smtp[5904]: connect to > iago.cs.cornell.edu[128.84.96.10]: > No route to host (port 25) > May 19 18:58:30 greene postfix/smtp[5904]: 0992D8DDE: to=< > simeon at cs.cornell.edu>, relay=none, delay=371744, status=deferred (connect > to iago.cs.cornell.edu[128.84.96.10]: No route to host) > May 19 18:58:30 greene postfix/smtp[5919]: connect to > incoming2.american.edu[147.9.1.249]: > No route to host (port 25) > May 19 18:58:30 greene postfix/smtp[5919]: 5F6AC8C0E: to=, > relay=none, delay=116954, status=deferred (connect to > incoming2.american.edu[147.9.1.249]: > No route to host) > May 19 18:58:33 greene postfix/smtp[5901]: connect to > cisbec.net.s6a1.psmtp.com[64.18.5.10]: No route to host (port 25) > May 19 18:58:33 greene postfix/smtp[5913]: connect to > smtp-mx6.mac.com[17.148.20.69]: > No route to host (port 25) > May 19 18:58:35 greene postfix/smtp[5895]: connect to > mailin-01.mx.AOL.COM[205.188.156.248]: > No route to host (port 25) > May 19 18:58:36 greene postfix/smtp[5899]: connect to > mx.dca.untd.com[64.136.44.37]: > No route to host (port 25) > May 19 18:58:36 greene postfix/smtp[5899]: D3A158876: to=, > relay=none, delay=183359, status=deferred (connect to > mx.dca.untd.com[64.136.44.37]: > No route to host) > May 19 18:58:42 greene postfix/smtp[5901]: connect to > cisbec.net.s6a2.psmtp.com[64.18.5.11]: No route to host (port 25) > May 19 18:58:45 greene postfix/smtp[5901]: connect to > cisbec.net.s6b1.psmtp.com[64.18.5.13]: No route to host (port 25) > May 19 18:58:45 greene postfix/smtp[5910]: connect to > hrndva-smtpin01.mail.rr.com[71.74.56.243]: No route to host (port 25) > May 19 18:58:48 greene postfix/smtp[5901]: connect to > cisbec.net.s6b2.psmtp.com[64.18.5.14]: No route to host (port 25) > May 19 18:58:48 greene postfix/smtp[5901]: 0992D8DDE: to=< > arahant1 at cisbec.net>, relay=none, delay=371762, status=deferred (connect to > cisbec.net.s6b2.psmtp.com[64.18.5.14]: No route to host) > I smell a port blocking going on... Or a mis config on a firewall. (A firewall/router set to reject with icmp-host-prohibited) That would be my guess. From dave at stayonline.com Tue May 19 18:24:51 2009 From: dave at stayonline.com (Dave Larter) Date: Tue, 19 May 2009 19:24:51 -0400 Subject: MX problems In-Reply-To: References: <8B79B73777E7D544A24BEB8FC50D35DB597B5A@MERCURY.socrdu.com> <8B79B73777E7D544A24BEB8FC50D35DB597B5B@MERCURY.socrdu.com> Message-ID: <8B79B73777E7D544A24BEB8FC50D35DB597B5C@MERCURY.socrdu.com> Thanks, actually I wasn't addressing the rr connects, no telling what they are doing/not doing just from the .edu. -----Original Message----- From: Andre Guibert de Bruet [mailto:andy at siliconlandmark.com] Sent: Tuesday, May 19, 2009 7:14 PM To: Dave Larter Cc: Polar Humenn; nanog at nanog.org Subject: Re: MX problems Hi, This doesn't appear to be DNS related. You can see from the trace that the forward resolution is in fact occurring just fine. It would appear that Comcast/RoadRunner filters SMTP in your market (A quick Google search indicates that this has been happening in various places since at least 2004). Do you still have issues if you try using their SMTP servers? Cheers, /* Andre Guibert de Bruet * 436f 6465 2070 6f65 742e 2042 6974 206a */ /* Managing Partner * 6f63 6b65 792e 2053 7973 4164 6d69 6e2e */ /* GSM: +1 734 846 8758 * 2055 4e49 5820 736c 6575 7468 2e00 0000 */ /* WWW: siliconlandmark.com * C/C++, Java, Perl, PHP, SQL, XHTML, XML */ On May 19, 2009, at 7:07 PM, Dave Larter wrote: > Did you flush your dns cache? Its happened to me before, couldn't > resolve our own domains, turned out to be a bad switch, for almost > everything it worked fine but had intermittent problems with 53. I > have > seen it before with other prots too. > > > > From: Polar Humenn [mailto:polar.humenn at gmail.com] > Sent: Tuesday, May 19, 2009 7:02 PM > To: Dave Larter > Cc: nanog at nanog.org > Subject: Re: MX problems > > > >> From my mail log. Geez, I can't even get to Cornell, which is just >> down > the friggin road! (Yeah, I know, but really). > What is going on? > > May 19 18:58:26 greene postfix/smtp[5895]: connect to > mailin-01.mx.AOL.COM[205.188.159.57]: No route to host (port 25) > May 19 18:58:27 greene postfix/smtp[5904]: connect to > penguin.cs.cornell.edu[128.84.96.11]: No route to host (port 25) > May 19 18:58:27 greene postfix/smtp[5899]: connect to > mx.vgs.untd.com[64.136.52.37]: No route to host (port 25) > May 19 18:58:27 greene postfix/smtp[5919]: connect to > incoming3.american.edu[147.9.1.250]: No route to host (port 25) > May 19 18:58:30 greene postfix/smtp[5904]: connect to > iago.cs.cornell.edu[128.84.96.10]: No route to host (port 25) > May 19 18:58:30 greene postfix/smtp[5904]: 0992D8DDE: > to=, relay=none, delay=371744, status=deferred > (connect to iago.cs.cornell.edu[128.84.96.10]: No route to host) > May 19 18:58:30 greene postfix/smtp[5919]: connect to > incoming2.american.edu[147.9.1.249]: No route to host (port 25) > May 19 18:58:30 greene postfix/smtp[5919]: 5F6AC8C0E: > to=, relay=none, delay=116954, status=deferred > (connect > to incoming2.american.edu[147.9.1.249]: No route to host) > May 19 18:58:33 greene postfix/smtp[5901]: connect to > cisbec.net.s6a1.psmtp.com[64.18.5.10]: No route to host (port 25) > May 19 18:58:33 greene postfix/smtp[5913]: connect to > smtp-mx6.mac.com[17.148.20.69]: No route to host (port 25) > May 19 18:58:35 greene postfix/smtp[5895]: connect to > mailin-01.mx.AOL.COM[205.188.156.248]: No route to host (port 25) > May 19 18:58:36 greene postfix/smtp[5899]: connect to > mx.dca.untd.com[64.136.44.37]: No route to host (port 25) > May 19 18:58:36 greene postfix/smtp[5899]: D3A158876: > to=, relay=none, delay=183359, status=deferred > (connect to mx.dca.untd.com[64.136.44.37]: No route to host) > May 19 18:58:42 greene postfix/smtp[5901]: connect to > cisbec.net.s6a2.psmtp.com[64.18.5.11]: No route to host (port 25) > May 19 18:58:45 greene postfix/smtp[5901]: connect to > cisbec.net.s6b1.psmtp.com[64.18.5.13]: No route to host (port 25) > May 19 18:58:45 greene postfix/smtp[5910]: connect to > hrndva-smtpin01.mail.rr.com[71.74.56.243]: No route to host (port 25) > May 19 18:58:48 greene postfix/smtp[5901]: connect to > cisbec.net.s6b2.psmtp.com[64.18.5.14]: No route to host (port 25) > May 19 18:58:48 greene postfix/smtp[5901]: 0992D8DDE: > to=, relay=none, delay=371762, status=deferred > (connect to cisbec.net.s6b2.psmtp.com[64.18.5.14]: No route to host) > > > > On Tue, May 19, 2009 at 6:57 PM, Dave Larter > wrote: > > Hi, I have no problem getting there, is that their mx's? > > Tracing route to s0.nanog.org [198.108.95.20] > over a maximum of 30 hops: > > 1 117 ms 128 ms 115 ms argon.socrdu.net [64.132.109.136] > 2 * 122 ms 126 ms 64.132.109.130 > 3 125 ms 106 ms 124 ms 64.132.109.129 > 4 130 ms 125 ms 113 ms 64-132-140-113.static.twtelecom.net > [64.132.140.113] > 5 129 ms 139 ms 139 ms scor-01-rif1.mtld.twtelecom.net > [66.192.243.134] > 6 129 ms 137 ms 148 ms te4-2.mpd02.dca01.atlas.cogentco.com > [154.54.26.121] > 7 152 ms 154 ms 240 ms te7-8.ccr01.jfk02.atlas.cogentco.com > [154.54.5.49] > 8 158 ms 153 ms 151 ms te9-8.mpd01.bos01.atlas.cogentco.com > [154.54.25.242] > 9 170 ms 172 ms 167 ms te7-8.ccr01.ord01.atlas.cogentco.com > [154.54.7.81] > 10 188 ms 172 ms 163 ms te8-2.mpd01.ord03.atlas.cogentco.com > [154.54.25.66] > 11 194 ms 170 ms 174 ms merit.demarc.cogentco.com > [66.28.21.234] > 12 164 ms 163 ms 166 ms tenge0-0-0-0x76.aa2.mich.net > [198.108.23.10] > 13 171 ms 164 ms 171 ms 198.108.22.186 > 14 171 ms 173 ms 171 ms s0.nanog.org [198.108.95.20] > > Trace complete. > > And yes, I only get that one mx/ip for nanog.org. > > > -----Original Message----- > From: Polar Humenn [mailto:polar.humenn at gmail.com] > Sent: Tuesday, May 19, 2009 6:44 PM > To: nanog at nanog.org > Subject: MX problems > > I'm in Syracuse NY, and I'm having problems getting sendmail to get to > MX > servers, with the errors of "No Route to Host" or "Connection timed > Out". > Apparently this is been happening for over 5 days. I can send mail > within > Syracuse University, but as soon as I venture out nothing. Traceroute > seems > to loose it after about the 9 or 10th hop. > > It seems that I can get to almost any website, but tracerouting or > pinging > these MX servers is not happening. > > Is there anything going on, or at least something that started 5-7 > days > ago? > > I find the same problem from within Syracuse Univeristy to my > RoadRunner > account at home (which does not pass through the university > routers). I > only > noticed it from the university since thats where I usually send my > email > through. Like I would no have been able to post to this list > >> From my home machine: >> traceroute s0.nanog.org > traceroute to s0.nanog.org (198.108.95.20), 30 hops max, 60 byte > packets > 1 192.168.99.1 (192.168.99.1) 0.211 ms 0.257 ms 0.302 ms > 2 10.217.224.1 (10.217.224.1) 13.754 ms 13.855 ms 14.291 ms > 3 gig2-2.syrcnysyr-rtr01.nyroc.rr.com (24.92.231.138) 18.442 ms > 22.701 > ms 26.908 ms > 4 gig1-1-0.syrcnyflk-rtr02.nyroc.rr.com (24.92.231.54) 31.279 ms > 31.454 > ms 31.591 ms > 5 ge-4-3-0.albynywav-rtr03.nyroc.rr.com (24.24.7.53) 37.429 ms > 37.604 > ms 37.779 ms > 6 ae-5-0.cr0.nyc30.tbone.rr.com (66.109.6.74) 41.329 ms 18.241 ms > 22.192 ms > 7 ae-1-0.pr0.nyc20.tbone.rr.com (66.109.6.163) 27.472 ms 19.542 ms > 23.419 ms > 8 te1-4.mpd01.jfk05.atlas.cogentco.com (154.54.13.185) 28.070 ms > 32.824 > ms 35.822 ms > 9 te9-3.ccr01.jfk02.atlas.cogentco.com (154.54.3.165) 40.796 ms > 40.549 > ms te2-4.ccr01.jfk02.atlas.cogentco.com (154.54.6.49) 40.958 ms > 10 te2-4.mpd01.bos01.atlas.cogentco.com (154.54.5.249) 48.704 ms > 47.549 > ms 48.468 ms > 11 te2-2.ccr01.ord01.atlas.cogentco.com (154.54.6.154) 57.836 ms > te8-8.mpd01.ord01.atlas.cogentco.com (154.54.24.54) 58.063 ms > te2-2.mpd01.ord01.atlas.cogentco.com (154.54.6.18) 46.700 ms > 12 vl3488.mpd01.ord03.atlas.cogentco.com (154.54.5.26) 56.905 ms > te3-4.mpd01.ord03.atlas.cogentco.com (154.54.6.206) 56.144 ms > vl3488.mpd01.ord03.atlas.cogentco.com (154.54.5.26) 45.245 ms > 13 Merit.demarc.cogentco.com (38.112.7.10) 44.512 ms > Merit.demarc.cogentco.com (66.28.21.234) 38.385 ms > Merit.demarc.cogentco.com (38.112.7.10) 40.305 ms > 14 tenge0-0-0-0x76.aa2.mich.net (198.108.23.10) 43.637 ms 42.601 ms > 43.902 ms > 15 198.108.22.186 (198.108.22.186) 48.455 ms 51.436 ms 44.070 ms > 16 * * * > 17 * * * > 18 * * * > 19 * * * > 20 * * * > 21 * * * > 22 * * * > 23 * * * > 24 * * * > 25 * * * > 26 * * * > 27 * * * > 28 * * * > 29 * * * > 30 * * * > > > Any ideas? > Cheers, > -Dr Polar > > From fbulk at mypremieronline.com Tue May 19 18:49:54 2009 From: fbulk at mypremieronline.com (Frank Bulk) Date: Tue, 19 May 2009 18:49:54 -0500 Subject: MX problems In-Reply-To: References: Message-ID: I recall reading in Syracuse's minutes (I'm a former grad) that they were going to institute port 25 blocking on campus. http://sunews.syr.edu/campusannouncements_details.cfm?id=5395 Frank -----Original Message----- From: Polar Humenn [mailto:polar.humenn at gmail.com] Sent: Tuesday, May 19, 2009 5:44 PM To: nanog at nanog.org Subject: MX problems I'm in Syracuse NY, and I'm having problems getting sendmail to get to MX servers, with the errors of "No Route to Host" or "Connection timed Out". Apparently this is been happening for over 5 days. I can send mail within Syracuse University, but as soon as I venture out nothing. Traceroute seems to loose it after about the 9 or 10th hop. It seems that I can get to almost any website, but tracerouting or pinging these MX servers is not happening. Is there anything going on, or at least something that started 5-7 days ago? I find the same problem from within Syracuse Univeristy to my RoadRunner account at home (which does not pass through the university routers). I only noticed it from the university since thats where I usually send my email through. Like I would no have been able to post to this list >From my home machine: > traceroute s0.nanog.org traceroute to s0.nanog.org (198.108.95.20), 30 hops max, 60 byte packets 1 192.168.99.1 (192.168.99.1) 0.211 ms 0.257 ms 0.302 ms 2 10.217.224.1 (10.217.224.1) 13.754 ms 13.855 ms 14.291 ms 3 gig2-2.syrcnysyr-rtr01.nyroc.rr.com (24.92.231.138) 18.442 ms 22.701 ms 26.908 ms 4 gig1-1-0.syrcnyflk-rtr02.nyroc.rr.com (24.92.231.54) 31.279 ms 31.454 ms 31.591 ms 5 ge-4-3-0.albynywav-rtr03.nyroc.rr.com (24.24.7.53) 37.429 ms 37.604 ms 37.779 ms 6 ae-5-0.cr0.nyc30.tbone.rr.com (66.109.6.74) 41.329 ms 18.241 ms 22.192 ms 7 ae-1-0.pr0.nyc20.tbone.rr.com (66.109.6.163) 27.472 ms 19.542 ms 23.419 ms 8 te1-4.mpd01.jfk05.atlas.cogentco.com (154.54.13.185) 28.070 ms 32.824 ms 35.822 ms 9 te9-3.ccr01.jfk02.atlas.cogentco.com (154.54.3.165) 40.796 ms 40.549 ms te2-4.ccr01.jfk02.atlas.cogentco.com (154.54.6.49) 40.958 ms 10 te2-4.mpd01.bos01.atlas.cogentco.com (154.54.5.249) 48.704 ms 47.549 ms 48.468 ms 11 te2-2.ccr01.ord01.atlas.cogentco.com (154.54.6.154) 57.836 ms te8-8.mpd01.ord01.atlas.cogentco.com (154.54.24.54) 58.063 ms te2-2.mpd01.ord01.atlas.cogentco.com (154.54.6.18) 46.700 ms 12 vl3488.mpd01.ord03.atlas.cogentco.com (154.54.5.26) 56.905 ms te3-4.mpd01.ord03.atlas.cogentco.com (154.54.6.206) 56.144 ms vl3488.mpd01.ord03.atlas.cogentco.com (154.54.5.26) 45.245 ms 13 Merit.demarc.cogentco.com (38.112.7.10) 44.512 ms Merit.demarc.cogentco.com (66.28.21.234) 38.385 ms Merit.demarc.cogentco.com (38.112.7.10) 40.305 ms 14 tenge0-0-0-0x76.aa2.mich.net (198.108.23.10) 43.637 ms 42.601 ms 43.902 ms 15 198.108.22.186 (198.108.22.186) 48.455 ms 51.436 ms 44.070 ms 16 * * * 17 * * * 18 * * * 19 * * * 20 * * * 21 * * * 22 * * * 23 * * * 24 * * * 25 * * * 26 * * * 27 * * * 28 * * * 29 * * * 30 * * * Any ideas? Cheers, -Dr Polar From Skywing at valhallalegends.com Tue May 19 18:58:28 2009 From: Skywing at valhallalegends.com (Skywing) Date: Tue, 19 May 2009 18:58:28 -0500 Subject: MX problems Message-ID: <982D8D05B6407A49AD506E6C3AC8E7D601303C4C77A7@caralain.haven.nynaeve.net> Firewalling based on a static port number is now DPI? - S -----Original Message----- From: Warren Bailey Sent: Tuesday, May 19, 2009 16:25 To: gmclean at xilogix.net ; polar.humenn at gmail.com Cc: nanog at nanog.org Subject: Re: MX problems Or... His provider is using dpi to drop packets destined for non provider mx servers. This would certainly reduce spam from compromised hosts. ----- Original Message ----- From: Gregory McLean To: Polar Humenn Cc: nanog at nanog.org Sent: Tue May 19 15:19:23 2009 Subject: Re: MX problems On Tue, 2009-05-19 at 19:02 -0400, Polar Humenn wrote: > >From my mail log. Geez, I can't even get to Cornell, which is just down the > friggin road! (Yeah, I know, but really). > What is going on? > > May 19 18:58:26 greene postfix/smtp[5895]: connect to > mailin-01.mx.AOL.COM[205.188.159.57]: > No route to host (port 25) > May 19 18:58:27 greene postfix/smtp[5904]: connect to > penguin.cs.cornell.edu[128.84.96.11]: > No route to host (port 25) > May 19 18:58:27 greene postfix/smtp[5899]: connect to > mx.vgs.untd.com[64.136.52.37]: > No route to host (port 25) > May 19 18:58:27 greene postfix/smtp[5919]: connect to > incoming3.american.edu[147.9.1.250]: > No route to host (port 25) > May 19 18:58:30 greene postfix/smtp[5904]: connect to > iago.cs.cornell.edu[128.84.96.10]: > No route to host (port 25) > May 19 18:58:30 greene postfix/smtp[5904]: 0992D8DDE: to=< > simeon at cs.cornell.edu>, relay=none, delay=371744, status=deferred (connect > to iago.cs.cornell.edu[128.84.96.10]: No route to host) > May 19 18:58:30 greene postfix/smtp[5919]: connect to > incoming2.american.edu[147.9.1.249]: > No route to host (port 25) > May 19 18:58:30 greene postfix/smtp[5919]: 5F6AC8C0E: to=, > relay=none, delay=116954, status=deferred (connect to > incoming2.american.edu[147.9.1.249]: > No route to host) > May 19 18:58:33 greene postfix/smtp[5901]: connect to > cisbec.net.s6a1.psmtp.com[64.18.5.10]: No route to host (port 25) > May 19 18:58:33 greene postfix/smtp[5913]: connect to > smtp-mx6.mac.com[17.148.20.69]: > No route to host (port 25) > May 19 18:58:35 greene postfix/smtp[5895]: connect to > mailin-01.mx.AOL.COM[205.188.156.248]: > No route to host (port 25) > May 19 18:58:36 greene postfix/smtp[5899]: connect to > mx.dca.untd.com[64.136.44.37]: > No route to host (port 25) > May 19 18:58:36 greene postfix/smtp[5899]: D3A158876: to=, > relay=none, delay=183359, status=deferred (connect to > mx.dca.untd.com[64.136.44.37]: > No route to host) > May 19 18:58:42 greene postfix/smtp[5901]: connect to > cisbec.net.s6a2.psmtp.com[64.18.5.11]: No route to host (port 25) > May 19 18:58:45 greene postfix/smtp[5901]: connect to > cisbec.net.s6b1.psmtp.com[64.18.5.13]: No route to host (port 25) > May 19 18:58:45 greene postfix/smtp[5910]: connect to > hrndva-smtpin01.mail.rr.com[71.74.56.243]: No route to host (port 25) > May 19 18:58:48 greene postfix/smtp[5901]: connect to > cisbec.net.s6b2.psmtp.com[64.18.5.14]: No route to host (port 25) > May 19 18:58:48 greene postfix/smtp[5901]: 0992D8DDE: to=< > arahant1 at cisbec.net>, relay=none, delay=371762, status=deferred (connect to > cisbec.net.s6b2.psmtp.com[64.18.5.14]: No route to host) > I smell a port blocking going on... Or a mis config on a firewall. (A firewall/router set to reject with icmp-host-prohibited) That would be my guess. From simon at darkmere.gen.nz Tue May 19 19:26:56 2009 From: simon at darkmere.gen.nz (Simon Lyall) Date: Wed, 20 May 2009 12:26:56 +1200 (NZST) Subject: MX problems In-Reply-To: References: Message-ID: This thread has now been moderated. Cause of problem ( via Frank Bulk ): http://sunews.syr.edu/campusannouncements_details.cfm?id=5395 The following page may also be helpful: http://its.syr.edu/support/ for future reference. Simon NANOG MLC On Tue, 19 May 2009, Polar Humenn wrote: > I'm in Syracuse NY, and I'm having problems getting sendmail to get to MX > servers, with the errors of "No Route to Host" or "Connection timed Out". > Apparently this is been happening for over 5 days. I can send mail within > Syracuse University, but as soon as I venture out nothing. Traceroute seems > to loose it after about the 9 or 10th hop. > > It seems that I can get to almost any website, but tracerouting or pinging > these MX servers is not happening. > > Is there anything going on, or at least something that started 5-7 days ago? > > I find the same problem from within Syracuse Univeristy to my RoadRunner > account at home (which does not pass through the university routers). I only > noticed it from the university since thats where I usually send my email > through. Like I would no have been able to post to this list > >> From my home machine: >> traceroute s0.nanog.org > traceroute to s0.nanog.org (198.108.95.20), 30 hops max, 60 byte packets > 1 192.168.99.1 (192.168.99.1) 0.211 ms 0.257 ms 0.302 ms > 2 10.217.224.1 (10.217.224.1) 13.754 ms 13.855 ms 14.291 ms > 3 gig2-2.syrcnysyr-rtr01.nyroc.rr.com (24.92.231.138) 18.442 ms 22.701 > ms 26.908 ms > 4 gig1-1-0.syrcnyflk-rtr02.nyroc.rr.com (24.92.231.54) 31.279 ms 31.454 > ms 31.591 ms > 5 ge-4-3-0.albynywav-rtr03.nyroc.rr.com (24.24.7.53) 37.429 ms 37.604 > ms 37.779 ms > 6 ae-5-0.cr0.nyc30.tbone.rr.com (66.109.6.74) 41.329 ms 18.241 ms > 22.192 ms > 7 ae-1-0.pr0.nyc20.tbone.rr.com (66.109.6.163) 27.472 ms 19.542 ms > 23.419 ms > 8 te1-4.mpd01.jfk05.atlas.cogentco.com (154.54.13.185) 28.070 ms 32.824 > ms 35.822 ms > 9 te9-3.ccr01.jfk02.atlas.cogentco.com (154.54.3.165) 40.796 ms 40.549 > ms te2-4.ccr01.jfk02.atlas.cogentco.com (154.54.6.49) 40.958 ms > 10 te2-4.mpd01.bos01.atlas.cogentco.com (154.54.5.249) 48.704 ms 47.549 > ms 48.468 ms > 11 te2-2.ccr01.ord01.atlas.cogentco.com (154.54.6.154) 57.836 ms > te8-8.mpd01.ord01.atlas.cogentco.com (154.54.24.54) 58.063 ms > te2-2.mpd01.ord01.atlas.cogentco.com (154.54.6.18) 46.700 ms > 12 vl3488.mpd01.ord03.atlas.cogentco.com (154.54.5.26) 56.905 ms > te3-4.mpd01.ord03.atlas.cogentco.com (154.54.6.206) 56.144 ms > vl3488.mpd01.ord03.atlas.cogentco.com (154.54.5.26) 45.245 ms > 13 Merit.demarc.cogentco.com (38.112.7.10) 44.512 ms > Merit.demarc.cogentco.com (66.28.21.234) 38.385 ms > Merit.demarc.cogentco.com (38.112.7.10) 40.305 ms > 14 tenge0-0-0-0x76.aa2.mich.net (198.108.23.10) 43.637 ms 42.601 ms > 43.902 ms > 15 198.108.22.186 (198.108.22.186) 48.455 ms 51.436 ms 44.070 ms > 16 * * * > 17 * * * > 18 * * * > 19 * * * > 20 * * * > 21 * * * > 22 * * * > 23 * * * > 24 * * * > 25 * * * > 26 * * * > 27 * * * > 28 * * * > 29 * * * > 30 * * * > > > Any ideas? > Cheers, > -Dr Polar > -- Simon Lyall | Very Busy | Web: http://www.darkmere.gen.nz/ "To stay awake all night adds a day to your life" - Stilgar | eMT. From zaid at zaidali.com Wed May 20 01:27:21 2009 From: zaid at zaidali.com (Zaid Ali) Date: Tue, 19 May 2009 23:27:21 -0700 (PDT) Subject: partial routes for AS701 and AS3365 Message-ID: <4966434.741242800840879.JavaMail.zaid@turing-2.local> Anyone here doing partial routes with AS701 and AS3356? If so can you tell me how many routes you are receiving? Thanks, Zaid From mike.lyon at gmail.com Wed May 20 14:18:36 2009 From: mike.lyon at gmail.com (Mike Lyon) Date: Wed, 20 May 2009 12:18:36 -0700 Subject: Temporary mail queue services? Message-ID: <1b5c1c150905201218t351d4dd1g5f14191efd480050@mail.gmail.com> Hello All, Does anyone know of a service that you can sign up for to add as a secondary MX to act as a mail queue if your primary MX isn't available? I'm going to be doing a mail migration and I need a service to point my MX record to that isn't my mail provider. I'll spare the details as to why it needs to be different provider. Any insight would be greatly appreciated. Thank You, Mike From tonyb at go-concepts.com Wed May 20 14:30:21 2009 From: tonyb at go-concepts.com (Tony Bunce) Date: Wed, 20 May 2009 15:30:21 -0400 Subject: Temporary mail queue services? In-Reply-To: <1b5c1c150905201218t351d4dd1g5f14191efd480050@mail.gmail.com> References: <1b5c1c150905201218t351d4dd1g5f14191efd480050@mail.gmail.com> Message-ID: <00B32937856D5B4D8E54EBDB02D1F44904A55F4AC9@exch2.gont> > Does anyone know of a service that you can sign up for to add as a secondary > MX to act as a mail queue if your primary MX isn't available? Here is one that I have heard of in the past: http://www.junkemailfilter.com/spam/free_mx_backup_service.html I have never used it though. -Tony From bruns at 2mbit.com Wed May 20 14:58:41 2009 From: bruns at 2mbit.com (Brielle Bruns) Date: Wed, 20 May 2009 19:58:41 +0000 Subject: Temporary mail queue services? Message-ID: <380510955-1242849558-cardhu_decombobulator_blackberry.rim.net-432189152-@bxe1227.bisx.prod.on.blackberry> DNSPark does - they're one of my favorite companies and have an actual live support contact. (No, I don't work for them). I also personally do backup MX stuff, depending on if its personal or business, and how much email you need spooled. Brielle (On her crackberry) ------Original Message------ From: Mike Lyon To: NANOG Subject: Temporary mail queue services? Sent: May 20, 2009 1:18 PM Hello All, Does anyone know of a service that you can sign up for to add as a secondary MX to act as a mail queue if your primary MX isn't available? I'm going to be doing a mail migration and I need a service to point my MX record to that isn't my mail provider. I'll spare the details as to why it needs to be different provider. Any insight would be greatly appreciated. Thank You, Mike -- Brielle Bruns http://www.sosdg.org / http://www.ahbl.org From steve at ibctech.ca Wed May 20 19:24:15 2009 From: steve at ibctech.ca (Steve Bertrand) Date: Wed, 20 May 2009 20:24:15 -0400 Subject: IPv6 iperf testing Message-ID: <4A149F2F.5@ibctech.ca> Hi all, I have a very quick selfish question... Is there anyone here who can provide me with an IPv6-listening iperf for a short time, so I can do some testing through my infrastructure and over my transit links? Max bandwidth 60Mb for short bursts (if I'm lucky). Steve -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3233 bytes Desc: S/MIME Cryptographic Signature URL: From nanog304985 at aquick.org Wed May 20 19:41:56 2009 From: nanog304985 at aquick.org (Adam Fields) Date: Wed, 20 May 2009 20:41:56 -0400 Subject: Temporary mail queue services? In-Reply-To: <1b5c1c150905201218t351d4dd1g5f14191efd480050@mail.gmail.com> References: <1b5c1c150905201218t351d4dd1g5f14191efd480050@mail.gmail.com> Message-ID: <20090521004156.GE1273@lola.aquick.org> On Wed, May 20, 2009 at 12:18:36PM -0700, Mike Lyon wrote: > Hello All, > > Does anyone know of a service that you can sign up for to add as a secondary > MX to act as a mail queue if your primary MX isn't available? I'm going to > be doing a mail migration and I need a service to point my MX record to that > isn't my mail provider. I'll spare the details as to why it needs to be > different provider. dyndns does this: http://www.dyndns.com/services/mailhop/backupmx.html -- - Adam ** Expert Technical Project and Business Management **** System Performance Analysis and Architecture ****** [ http://www.adamfields.com ] [ http://workstuff.tumblr.com ] ........... Technology Blog [ http://www.aquick.org/blog ] ............ Personal Blog [ http://www.adamfields.com/resume.html ].. Experience [ http://www.flickr.com/photos/fields ] ... Photos [ http://www.twitter.com/fields ].......... Twitter [ http://www.morningside-analytics.com ] .. Latest Venture [ http://www.confabb.com ] ................ Founder From patrick at ianai.net Wed May 20 21:23:01 2009 From: patrick at ianai.net (Patrick W. Gilmore) Date: Wed, 20 May 2009 22:23:01 -0400 Subject: Temporary mail queue services? In-Reply-To: <1b5c1c150905201218t351d4dd1g5f14191efd480050@mail.gmail.com> References: <1b5c1c150905201218t351d4dd1g5f14191efd480050@mail.gmail.com> Message-ID: <5E106F76-9A4E-448B-9574-AE9A648D5D32@ianai.net> On May 20, 2009, at 3:18 PM, Mike Lyon wrote: > Does anyone know of a service that you can sign up for to add as a > secondary > MX to act as a mail queue if your primary MX isn't available? I'm > going to > be doing a mail migration and I need a service to point my MX record > to that > isn't my mail provider. I'll spare the details as to why it needs to > be > different provider. How long will your server be down? Backup MX without a user list is a Bad Thing because of blowback. And I'll stop there before someone tells me I'm off-topic. :) -- TTFN, patrick From steve at ibctech.ca Wed May 20 21:49:36 2009 From: steve at ibctech.ca (Steve Bertrand) Date: Wed, 20 May 2009 22:49:36 -0400 Subject: IPv6 iperf testing In-Reply-To: <4A149F2F.5@ibctech.ca> References: <4A149F2F.5@ibctech.ca> Message-ID: <4A14C140.7030704@ibctech.ca> Steve Bertrand wrote: > Is there anyone here who can provide me with an IPv6-listening iperf for > a short time, so I can do some testing through my infrastructure and > over my transit links? I want to thank everyone who responded to my request. The responses were/are overwhelming. I've found some essential design flaws in my network when dealing with BGP routing that is carried over proto41 tunnels. These flaws are most likely prevented within the normal vXiBGP-vXIGP-vXiBGP scope, but if anyone is interested in discussing it further, I'll gladly do so, and document my findings. Perhaps my small ISP test platform using tunnels isn't a great example, but I've found that balance is certainly important, and overlooking simple things is quite easy to do. On another topic regarding v6 that will eventually have to be discussed, who is filtering at what prefixlen? I'm doing /48. I'm deathly afraid of someone breaking up a bunch of /32s into /48s (or /64s if you don't filter) and overwhelming our routers. Is there a BCP list to follow regarding prefix filtering? Steve -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3233 bytes Desc: S/MIME Cryptographic Signature URL: From darcy at druid.net Thu May 21 00:50:24 2009 From: darcy at druid.net (D'Arcy J.M. Cain) Date: Thu, 21 May 2009 01:50:24 -0400 Subject: Temporary mail queue services? In-Reply-To: <5E106F76-9A4E-448B-9574-AE9A648D5D32@ianai.net> References: <1b5c1c150905201218t351d4dd1g5f14191efd480050@mail.gmail.com> <5E106F76-9A4E-448B-9574-AE9A648D5D32@ianai.net> Message-ID: <20090521015024.ff580fdf.darcy@druid.net> On Wed, 20 May 2009 22:23:01 -0400 "Patrick W. Gilmore" wrote: > Backup MX without a user list is a Bad Thing because of blowback. And are you sure that your users are comfortable with their email being held by a third party that they don't know? > And I'll stop there before someone tells me I'm off-topic. :) And we are. Inet Access or mailops would probably be better. -- D'Arcy J.M. Cain | Democracy is three wolves http://www.druid.net/darcy/ | and a sheep voting on +1 416 425 1212 (DoD#0082) (eNTP) | what's for dinner. From lists at memetic.org Thu May 21 03:55:45 2009 From: lists at memetic.org (Adam Armstrong) Date: Thu, 21 May 2009 09:55:45 +0100 Subject: NPE-G2 vs. Sup720-3BXL In-Reply-To: <4A117817.5020301@jarruda.com> References: <4A114466.1050208@memetic.org> <4A117817.5020301@jarruda.com> Message-ID: <4A151711.3070505@memetic.org> Julio Arruda wrote: > Steve Dalberg wrote: >> 2009/5/18 Adam Armstrong : >>> David Storandt wrote: >>>> We're stuck in an engineering pickle, so some experience from this >>>> crew would be useful in tie-breaking... >>>> >>>> We operate a business-grade FTTx ISP with ~75 customers and 800Mbps of >>>> Internet traffic, currently using 6509/Sup2s for core routing and port >>>> aggregation. The MSFC2s are under stress from 3x full route feeds, >>>> pared down to 85% to fit the TCAM tables. One system has a FlexWAN >>>> with an OC3 card and it's crushing the CPU on the MSFC2. System tuning >>>> (stable IOS and esp. disabling SPD) helped a lot but still doesn't >>>> have the power to pull through. Hardware upgrades are needed... >>>> >>>> We need true full routes and more CPU horsepower for crunching BGP >>>> (+12 smaller peers + ISIS). OC3 interfaces are going to be mandatory, >>>> one each at two locations. Oh yeah, we're still a larger startup >>>> without endless pockets. Power, rack space, and SmartNet are not >>>> concerns at any location (on-site cold spares). We may need an >>>> upstream OC12 in the future but that's a ways out and not a concern >>>> here. >>>> >>>> Our engineering team has settled on three $20k/node options: >>>> - Sup720-3BXLs with PS and fan upgrades >>>> - Sup2s as switches + ISIS + statics and no BGP, push BGP edge routing >>>> off to NPE-G2s across a 2-3Gbps port-channel >>>> - Sup2s as switches + ISIS + statics and no BGP, push BGP edge routing >>>> off to a 12008 with E3 engines across a 2-3Gbps port-channel. >>>> >>> Have a look at the ASR1002 + ESP5/10G >>> >>> Stable for BGP+ISIS as far as our experience goes. >>> >>> adam. >>> >>> >> >> ASR1002 + ESP5 was great for OSPF + BGP. 450M+ of traffic for me at >> peek (proc at1-2%) >> > > Any experience in how much more resilient is the ASR compared with > 7600/6500, DDoS-wise :-) ? > And compared with NPE-G2 ? > And in terms of CoPP and etc ? The ASR's Quantum Flow processors scale quite unpredictably depending upon features, apparently, so it's difficult to say. I'm expecting 5-7Gbps on the ESP10 with my usage (no complex features in use, just forwarding and Netflow), though I've little data to base that on. (ESP on one device currently reports 2-3% usage at ~200Mbit). It'll handle a DDoS much, much, much better than a 7201/NPE-G1, but much, much, much worse than a 65/7500 (even without DFCs). We use several ASRs with one at each entry point to the network (each transit provider / peering exchange) to spread potention DDoS across a lot of processors, that approach is working well for us at the moment. Our only real issue is that the Netflow implementation on the ASRs seems to be a little 'sensitive' to configuration changes and sometimes just stops exporting flows. adam. From source_route at yahoo.com Thu May 21 08:38:38 2009 From: source_route at yahoo.com (Philip Lavine) Date: Thu, 21 May 2009 06:38:38 -0700 (PDT) Subject: ISP best practices Message-ID: <408493.6724.qm@web30807.mail.mud.yahoo.com> To all, I am sure this has been asked 10 to the 1 millionth power times, however may be the rules have changed. I am looking to set up a really small ISP with a few /24's. I want to host DNS as well. Is there any whitepapers/howtos/best practices on setting up multihomed BGP and DNS with BIND so I don't blow up the Internet. Thx Philip From dwhite at olp.net Thu May 21 08:44:54 2009 From: dwhite at olp.net (Dan White) Date: Thu, 21 May 2009 08:44:54 -0500 Subject: ISP best practices In-Reply-To: <408493.6724.qm@web30807.mail.mud.yahoo.com> References: <408493.6724.qm@web30807.mail.mud.yahoo.com> Message-ID: <4A155AD6.7060909@olp.net> Philip Lavine wrote: > To all, > > I am sure this has been asked 10 to the 1 millionth power times, however may be the rules have changed. I am looking to set up a really small ISP with a few /24's. I want to host DNS as well. Is there any whitepapers/howtos/best practices on setting up multihomed BGP and DNS with BIND so I don't blow up the Internet. > > Thx > > Philip > Highering a consultant to do your initial configuration is highly recommended. We took this route when we originally configured BGP and it allowed me to learn from and study a known 'good' configuration. - Dan From steve at ibctech.ca Thu May 21 08:45:13 2009 From: steve at ibctech.ca (Steve Bertrand) Date: Thu, 21 May 2009 09:45:13 -0400 Subject: ISP best practices In-Reply-To: <408493.6724.qm@web30807.mail.mud.yahoo.com> References: <408493.6724.qm@web30807.mail.mud.yahoo.com> Message-ID: <4A155AE9.3040405@ibctech.ca> Philip Lavine wrote: > To all, > > I am sure this has been asked 10 to the 1 millionth power times, however may be the rules have changed. I am looking to set up a really small ISP with a few /24's. I want to host DNS as well. Is there any whitepapers/howtos/best practices on setting up multihomed BGP and DNS with BIND so I don't blow up the Internet. BCP 38: - http://www.ietf.org/rfc/rfc3704.txt ISP Essentials: - http://www.ciscopress.com/bookstore/product.asp?isbn=1587050412 Securing IP Network Traffic Planes: - http://www.ciscopress.com/bookstore/product.asp?isbn=1587053365 - anything and everything regarding IPv6. ...would be a VERY good start (I've read Securing IP Traffic Planes which is also great reference, and am just finishing up ISP Essentials, which is dated, but the principles still apply). Steve -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3233 bytes Desc: S/MIME Cryptographic Signature URL: From bradley.freeman at csirt.ja.net Thu May 21 08:48:51 2009 From: bradley.freeman at csirt.ja.net (Bradley Freeman) Date: Thu, 21 May 2009 14:48:51 +0100 Subject: ISP best practices In-Reply-To: <408493.6724.qm@web30807.mail.mud.yahoo.com> References: <408493.6724.qm@web30807.mail.mud.yahoo.com> Message-ID: <000001c9da1a$dfe3e870$9fabb950$@freeman@csirt.ja.net> In regards to DNS there is a great secure BIND template here http://www.cymru.com/Documents/secure-bind-template.html which will help stop your server from being an unneeded open resolver, or sending out root hints which are used all the time to amplify DDOS attacks often without you realising. Bradley -----Original Message----- From: Philip Lavine [mailto:source_route at yahoo.com] Sent: 21 May 2009 14:39 To: nanog at nanog.org Subject: ISP best practices To all, I am sure this has been asked 10 to the 1 millionth power times, however may be the rules have changed. I am looking to set up a really small ISP with a few /24's. I want to host DNS as well. Is there any whitepapers/howtos/best practices on setting up multihomed BGP and DNS with BIND so I don't blow up the Internet. Thx Philip From jlewis at lewis.org Thu May 21 09:00:09 2009 From: jlewis at lewis.org (Jon Lewis) Date: Thu, 21 May 2009 10:00:09 -0400 (EDT) Subject: ISP best practices In-Reply-To: <408493.6724.qm@web30807.mail.mud.yahoo.com> References: <408493.6724.qm@web30807.mail.mud.yahoo.com> Message-ID: On Thu, 21 May 2009, Philip Lavine wrote: > I am sure this has been asked 10 to the 1 millionth power times, however > may be the rules have changed. I am looking to set up a really small ISP > with a few /24's. I want to host DNS as well. Is there any > whitepapers/howtos/best practices on setting up multihomed BGP and DNS > with BIND so I don't blow up the Internet. A few minutes with google would probably find sample BGP multihoming configs. The big things to avoid are unnecessary deaggregation and announcing routes received from one provider to the other. i.e. If you have a /22 of IP space, you may use/see that as 4 /24's or a larger number of smaller subnets, but where eBGP is concerned, you should announce just the /22 route and keep your subnetting to yourself. If you have competent providers, they won't accept routes from you that they're not expecting, which will stop you from offering transit to them by announcing routes received from your other provider. Still, it's better to get your config done right than rely on your providers to ignore what you shouldn't be advertising. ---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From bbc at misn.com Thu May 21 09:10:56 2009 From: bbc at misn.com (Bryan Campbell) Date: Thu, 21 May 2009 09:10:56 -0500 Subject: ISP best practices In-Reply-To: <408493.6724.qm@web30807.mail.mud.yahoo.com> References: <408493.6724.qm@web30807.mail.mud.yahoo.com> Message-ID: <1242915056.10374.3.camel@home-desktop> This is the Nanog list . . . How about some Nanog resources . . . http://www.nanog.org/resources/tutorials/ And, yes, hiring a consultant is a good idea. But, being an informed consumer is also a good idea. Read lots! Ask lots of questions! Cheers! bbc On Thu, 2009-05-21 at 06:38 -0700, Philip Lavine wrote: > To all, > > I am sure this has been asked 10 to the 1 millionth power times, however may be the rules have changed. I am looking to set up a really small ISP with a few /24's. I want to host DNS as well. Is there any whitepapers/howtos/best practices on setting up multihomed BGP and DNS with BIND so I don't blow up the Internet. > > Thx > > Philip > > > > From rdobbins at arbor.net Thu May 21 09:14:00 2009 From: rdobbins at arbor.net (Roland Dobbins) Date: Thu, 21 May 2009 21:14:00 +0700 Subject: ISP best practices In-Reply-To: <4A155AE9.3040405@ibctech.ca> References: <408493.6724.qm@web30807.mail.mud.yahoo.com> <4A155AE9.3040405@ibctech.ca> Message-ID: <38C05B18-2ABA-42A5-9223-3762E10B6B33@arbor.net> On May 21, 2009, at 8:45 PM, Steve Bertrand wrote: > Securing IP Network Traffic Planes: > - http://www.ciscopress.com/bookstore/product.asp?isbn=1587053365 I can't recommend this book enough - it's the current canonical reference on opsec-related BCPs for network infrastructure, IMHO (full disclosure: I was fortunate enough to have the opportunity to provide some feedback to the authors as they worked on this tome, but have no financial interest whatsoever in its publication or sales thereof). ----------------------------------------------------------------------- Roland Dobbins // Unfortunately, inefficiency scales really well. -- Kevin Lawton From lists at mtin.net Thu May 21 09:19:24 2009 From: lists at mtin.net (Justin Wilson - MTIN) Date: Thu, 21 May 2009 10:19:24 -0400 Subject: ISP best practices In-Reply-To: <4A155AE9.3040405@ibctech.ca> Message-ID: The problem with ISP essentials is it was published in 2002. Same goes for some of the other good Cisco books. A lot has changed in the ISP world since. Sure it has good information but I wouldn?t spend the $ for a new copy. Find it on half.com or somewhere. Justin From: Steve Bertrand Date: Thu, 21 May 2009 09:45:13 -0400 To: Philip Lavine Cc: Subject: Re: ISP best practices Philip Lavine wrote: > To all, > > I am sure this has been asked 10 to the 1 millionth power times, however may be the rules have changed. I am looking to set up a really small ISP with a few /24's. I want to host DNS as well. Is there any whitepapers/howtos/best practices on setting up multihomed BGP and DNS with BIND so I don't blow up the Internet. BCP 38: - http://www.ietf.org/rfc/rfc3704.txt ISP Essentials: - http://www.ciscopress.com/bookstore/product.asp?isbn=1587050412 Securing IP Network Traffic Planes: - http://www.ciscopress.com/bookstore/product.asp?isbn=1587053365 - anything and everything regarding IPv6. ...would be a VERY good start (I've read Securing IP Traffic Planes which is also great reference, and am just finishing up ISP Essentials, which is dated, but the principles still apply). Steve From joelja at bogus.com Thu May 21 09:20:37 2009 From: joelja at bogus.com (Joel Jaeggli) Date: Thu, 21 May 2009 07:20:37 -0700 Subject: ISP best practices In-Reply-To: <1242915056.10374.3.camel@home-desktop> References: <408493.6724.qm@web30807.mail.mud.yahoo.com> <1242915056.10374.3.camel@home-desktop> Message-ID: <4A156335.4090502@bogus.com> The African Network Operators Group has quite a good set of workshop materials for both isp routing (including v6) and DNS (seperate workshops) weeklong course materials for the routing track are here: http://www.ws.afnog.org/afnog2009/sie/detail.html Bryan Campbell wrote: > This is the Nanog list . . . > > How about some Nanog resources . . . > > http://www.nanog.org/resources/tutorials/ > > And, yes, hiring a consultant is a good idea. But, being an informed > consumer is also a good idea. Read lots! Ask lots of questions! > > Cheers! > > bbc > > > On Thu, 2009-05-21 at 06:38 -0700, Philip Lavine wrote: >> To all, >> >> I am sure this has been asked 10 to the 1 millionth power times, however may be the rules have changed. I am looking to set up a really small ISP with a few /24's. I want to host DNS as well. Is there any whitepapers/howtos/best practices on setting up multihomed BGP and DNS with BIND so I don't blow up the Internet. >> >> Thx >> >> Philip >> >> >> >> > > From steve at ibctech.ca Thu May 21 09:30:06 2009 From: steve at ibctech.ca (Steve Bertrand) Date: Thu, 21 May 2009 10:30:06 -0400 Subject: ISP best practices In-Reply-To: References: <408493.6724.qm@web30807.mail.mud.yahoo.com> Message-ID: <4A15656E.7010706@ibctech.ca> Jon Lewis wrote: > Still, it's > better to get your config done right than rely on your providers to > ignore what you shouldn't be advertising. I have to agree completely with Jon here. As a small SP, it is prudent to do everything you can to be a good 'netizen. Apply your outbound prefix lists *before* you turn up your BGP session(s). You should also ensure that you have a good grasp on BCP 38 prior to connecting yourself. This should be done no matter who your upstreams are, large or small. There is nothing more frustrating than seeing RFC 1918, BOGON and/or your own IP space coming back at you eating your bandwidth from your upstreams, so ensure you are not responsible for doing it to them. Steve -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3233 bytes Desc: S/MIME Cryptographic Signature URL: From cmaurand at xyonet.com Thu May 21 10:06:17 2009 From: cmaurand at xyonet.com (Curtis Maurand) Date: Thu, 21 May 2009 11:06:17 -0400 Subject: ISP best practices In-Reply-To: <408493.6724.qm@web30807.mail.mud.yahoo.com> References: <408493.6724.qm@web30807.mail.mud.yahoo.com> Message-ID: <4A156DE9.90805@xyonet.com> Check out www.powerdns.com as an alternative to bind. Its faster, more secure, does IPV6 and easier to maintain. Curtis Philip Lavine wrote: > To all, > > I am sure this has been asked 10 to the 1 millionth power times, however may be the rules have changed. I am looking to set up a really small ISP with a few /24's. I want to host DNS as well. Is there any whitepapers/howtos/best practices on setting up multihomed BGP and DNS with BIND so I don't blow up the Internet. > > Thx > > Philip > > > > > > From bclark at spectraaccess.com Thu May 21 10:27:49 2009 From: bclark at spectraaccess.com (Bret Clark) Date: Thu, 21 May 2009 11:27:49 -0400 Subject: ISP best practices In-Reply-To: <408493.6724.qm@web30807.mail.mud.yahoo.com> References: <408493.6724.qm@web30807.mail.mud.yahoo.com> Message-ID: <1242919669.10585.11.camel@acer-laptop> While BGP can become a rather complex protocol to implement as a network grows, basic BGP peering between two providers isn't really that complex...probably talking 10 config lines at most (excluding bogon/filtering). The first thing you want to make sure is that you're upstream providers are implementing filtering, which most of the serious providers do. That way all you can do is hurt yourself while keeping the rest of us on the list here happy :). It's best to get your own IP address space from ARIN if possible, because if you use IP space from your upstream provider, it's becomes a nightmare to change over at a later date...IP renumbering is not fun! That was the one mistake we made when we first started. Personally I'm a fan of the "do it yourself" club...yeah you'll make mistakes, but the hands-on approach is by far the best way too learn. Bret On Thu, 2009-05-21 at 06:38 -0700, Philip Lavine wrote: > To all, > > I am sure this has been asked 10 to the 1 millionth power times, however may be the rules have changed. I am looking to set up a really small ISP with a few /24's. I want to host DNS as well. Is there any whitepapers/howtos/best practices on setting up multihomed BGP and DNS with BIND so I don't blow up the Internet. > > Thx > > Philip > > > > > From ben at hns.net Thu May 21 10:29:57 2009 From: ben at hns.net (Ben Cooper) Date: Thu, 21 May 2009 16:29:57 +0100 Subject: ISP best practices In-Reply-To: <4A156DE9.90805@xyonet.com> References: <408493.6724.qm@web30807.mail.mud.yahoo.com> <4A156DE9.90805@xyonet.com> Message-ID: <4A157375.2040007@hns.net> I've deployed PowerDNS before, along with PowerAdmin (https://www.poweradmin.org/trac/). Very easy to set up and manage. Ben For system or network support, please email support at hns.net Curtis Maurand wrote: > > Check out www.powerdns.com as an alternative to bind. Its faster, more > secure, does IPV6 and easier to maintain. > > Curtis > > Philip Lavine wrote: >> To all, >> >> I am sure this has been asked 10 to the 1 millionth power times, >> however may be the rules have changed. I am looking to set up a really >> small ISP with a few /24's. I want to host DNS as well. Is there any >> whitepapers/howtos/best practices on setting up multihomed BGP and DNS >> with BIND so I don't blow up the Internet. >> >> Thx >> >> Philip >> >> >> >> >> > > > > From kizmet at kizmet.id.au Thu May 21 10:42:22 2009 From: kizmet at kizmet.id.au (Cody Appleby) Date: Fri, 22 May 2009 01:42:22 +1000 Subject: ISP best practices In-Reply-To: <20090521153310.B43A6A40636@mx1.cbr.ideteron.net.au> References: <408493.6724.qm@web30807.mail.mud.yahoo.com> <4A156DE9.90805@xyonet.com> <20090521153310.B43A6A40636@mx1.cbr.ideteron.net.au> Message-ID: <20090521154222.472CDA40658@mx1.cbr.ideteron.net.au> Have to agree on PowerDNS and PowerAdmin. Very easy to setup, Pretty secure out of the box and management is a breeze! ./cwa On Thu, 21 May 2009 16:29:57 +0100, Ben Cooper wrote: > I've deployed PowerDNS before, along with PowerAdmin > (https://www.poweradmin.org/trac/). Very easy to set up and manage. > > Ben > > For system or network support, please email support at hns.net > > Curtis Maurand wrote: >> >> Check out www.powerdns.com as an alternative to bind. Its faster, more >> secure, does IPV6 and easier to maintain. >> >> Curtis >> >> Philip Lavine wrote: >>> To all, >>> >>> I am sure this has been asked 10 to the 1 millionth power times, >>> however may be the rules have changed. I am looking to set up a really >>> small ISP with a few /24's. I want to host DNS as well. Is there any >>> whitepapers/howtos/best practices on setting up multihomed BGP and DNS >>> with BIND so I don't blow up the Internet. >>> >>> Thx >>> >>> Philip >>> >>> >>> >>> >>> >> >> >> >> From list-nanog2 at dragon.net Thu May 21 10:47:51 2009 From: list-nanog2 at dragon.net (Paul E) Date: Thu, 21 May 2009 08:47:51 -0700 Subject: ISP best practices In-Reply-To: <4A156DE9.90805@xyonet.com> References: <408493.6724.qm@web30807.mail.mud.yahoo.com> <4A156DE9.90805@xyonet.com> Message-ID: <20090521154751.9B7CD4C102C@ptcruiser.dragon.net> cmaurand> Check out www.powerdns.com as an alternative to bind. Its cmaurand> faster, more secure, does IPV6 and easier to maintain. This is purely opinion. BIND has warts, just as any large piece of code in wide spread use and with lots of features will have. However, that's also one of its advantages. Lots of folks run it and know it and fix it when it breaks. Works for root & gtld servers, must not totally suck. BIND does ipV6, has since BIND8. It is also fully DNSSEC compliant. Is powerdns yet? Yes. Do check out all the alternatives for DNS. But if you're looking at ipV6 support because you want to be able to support upcoming protocols, make sure your DNS can do DNSSEC correctly too. From ben at hns.net Thu May 21 10:53:20 2009 From: ben at hns.net (Ben Cooper) Date: Thu, 21 May 2009 16:53:20 +0100 Subject: ISP best practices Message-ID: <4A1578F0.4070305@hns.net> Yeah, it was a while back, but as far as I can remember it's fairly straight forward. I think I just replaced the icons and altered the CSS or PHP. Ben Brandon Galbraith wrote: > Ben, > > Is poweradmin easy to skin? Happy with the interface? We currently have > several hundred domains and tens of thousands of records with dnsmadeeasy > and we're getting ready to bring it all in house, and powerdns/poweradmin > looks like the solution we've been looking for. > > -brandon > > On Thu, May 21, 2009 at 10:29 AM, Ben Cooper wrote: > >> I've deployed PowerDNS before, along with PowerAdmin >> (https://www.poweradmin.org/trac/). Very easy to set up and manage. >> >> Ben >> >> For system or network support, please email support at hns.net >> >> Curtis Maurand wrote: >>> Check out www.powerdns.com as an alternative to bind. Its faster, more >>> secure, does IPV6 and easier to maintain. >>> >>> Curtis >>> >>> Philip Lavine wrote: >>>> To all, >>>> >>>> I am sure this has been asked 10 to the 1 millionth power times, >>>> however may be the rules have changed. I am looking to set up a really >>>> small ISP with a few /24's. I want to host DNS as well. Is there any >>>> whitepapers/howtos/best practices on setting up multihomed BGP and DNS >>>> with BIND so I don't blow up the Internet. >>>> >>>> Thx >>>> >>>> Philip >>>> >>>> >>>> >>>> >>>> >>> >>> >>> >> > > From maria at iano.org Thu May 21 10:56:19 2009 From: maria at iano.org (Maria Iano) Date: Thu, 21 May 2009 11:56:19 -0400 Subject: facebook DNS Message-ID: <701FDB11-4139-44F2-9FA1-56849FB80C2E@iano.org> It looks like facebook is having DNS troubles. The www.facebook.com subdomain is delegated to some servers that are no longer answering. Also apps.facebook.com is a cname to www-college.facebook.com which gets no reply. Maria From darden at armc.org Thu May 21 10:59:53 2009 From: darden at armc.org (Darden, Patrick S.) Date: Thu, 21 May 2009 11:59:53 -0400 Subject: facebook DNS In-Reply-To: <701FDB11-4139-44F2-9FA1-56849FB80C2E@iano.org> Message-ID: I noticed this as well around 11:50 eastern. --Patrick Darden -----Original Message----- From: Maria Iano [mailto:maria at iano.org] Sent: Thursday, May 21, 2009 11:56 AM To: nanog at nanog.org Subject: facebook DNS It looks like facebook is having DNS troubles. The www.facebook.com subdomain is delegated to some servers that are no longer answering. Also apps.facebook.com is a cname to www-college.facebook.com which gets no reply. Maria From ben at hns.net Thu May 21 10:59:27 2009 From: ben at hns.net (Ben Cooper) Date: Thu, 21 May 2009 16:59:27 +0100 Subject: ISP best practices In-Reply-To: <20090521154751.9B7CD4C102C@ptcruiser.dragon.net> References: <408493.6724.qm@web30807.mail.mud.yahoo.com> <4A156DE9.90805@xyonet.com> <20090521154751.9B7CD4C102C@ptcruiser.dragon.net> Message-ID: <4A157A5F.9010707@hns.net> If you want to go down the BIND route, I'd recommend using xname as a frontend (http://source.xname.org/). Paul E wrote: > cmaurand> Check out www.powerdns.com as an alternative to bind. Its > cmaurand> faster, more secure, does IPV6 and easier to maintain. > > This is purely opinion. > > BIND has warts, just as any large piece of code in wide spread use and > with lots of features will have. However, that's also one of its > advantages. Lots of folks run it and know it and fix it when it breaks. > > Works for root & gtld servers, must not totally suck. > > BIND does ipV6, has since BIND8. > > It is also fully DNSSEC compliant. Is powerdns yet? > > Yes. Do check out all the alternatives for DNS. But if you're looking at > ipV6 support because you want to be able to support upcoming protocols, > make sure your DNS can do DNSSEC correctly too. > > > > From andyring at inebraska.com Thu May 21 11:00:36 2009 From: andyring at inebraska.com (Andy Ringsmuth) Date: Thu, 21 May 2009 11:00:36 -0500 Subject: facebook DNS In-Reply-To: <701FDB11-4139-44F2-9FA1-56849FB80C2E@iano.org> References: <701FDB11-4139-44F2-9FA1-56849FB80C2E@iano.org> Message-ID: On May 21, 2009, at 10:56 AM, Maria Iano wrote: > It looks like facebook is having DNS troubles. The www.facebook.com > subdomain is delegated to some servers that are no longer answering. > Also apps.facebook.com is a cname to www-college.facebook.com which > gets no reply. > > Maria I don't know that it's a DNS issue. I had trouble reaching facebook.com and www.spc.noaa.gov for a while, as well as a couple IPs in Chicago on residential Comcast. Had issues for about the last half hour but seemingly all is well now. I hope. -Andy Ringsmuth From chaynes at centracomm.net Thu May 21 11:00:37 2009 From: chaynes at centracomm.net (Clay Haynes) Date: Thu, 21 May 2009 12:00:37 -0400 Subject: facebook DNS In-Reply-To: <701FDB11-4139-44F2-9FA1-56849FB80C2E@iano.org> References: <701FDB11-4139-44F2-9FA1-56849FB80C2E@iano.org> Message-ID: Looks like someone is messing with the domain nameservers. Possibly a domain hijack? panzer:~ chaynes$ whois facebook.com Whois Server Version 2.0 Domain names in the .com and .net domains can now be registered with many different competing registrars. Go to http://www.internic.net for detailed information. FACEBOOK.COM.ZZZZZ.GET.LAID.AT.WWW.SWINGINGCOMMUNITY.COM FACEBOOK.COM.ZZZZZ.DOWNLOAD.MOVIE.ONLINE.ZML2.COM FACEBOOK.COM.MORE.INFO.AT.WWW.BEYONDWHOIS.COM FACEBOOK.COM To single out one record, look it up with "xxx", where xxx is one of the of the records displayed above. If the records are the same, look them up with "=xxx" to receive a full display for each record. - Clay -----Original Message----- From: Maria Iano [mailto:maria at iano.org] Sent: Thursday, May 21, 2009 11:56 AM To: nanog at nanog.org Subject: facebook DNS It looks like facebook is having DNS troubles. The www.facebook.com subdomain is delegated to some servers that are no longer answering. Also apps.facebook.com is a cname to www-college.facebook.com which gets no reply. Maria From jabley at hopcount.ca Thu May 21 11:00:58 2009 From: jabley at hopcount.ca (Joe Abley) Date: Thu, 21 May 2009 12:00:58 -0400 Subject: ISP best practices In-Reply-To: <4A156DE9.90805@xyonet.com> References: <408493.6724.qm@web30807.mail.mud.yahoo.com> <4A156DE9.90805@xyonet.com> Message-ID: <35BB447D-3CB9-4141-A5A7-01CB7AEB6DC3@hopcount.ca> On 21-May-2009, at 11:06, Curtis Maurand wrote: > Check out www.powerdns.com as an alternative to bind. Its faster, > more secure, does IPV6 and easier to maintain. I have heard lots of good things about PowerDNS, and I'm quite prepared to believe that it's a natural choice for a DNS hosting service where the database back-end makes for far simpler provisioning and control than managing a pile of config files. However, you're not necessarily doing anybody any favours in making statements like "faster", "more secure" and "does IPv6". DNS servers are complicated beasts, and simplistic comparisons are not useful for much (it'd be trivial to give you examples where PowerDNS is slower and less secure, for example, and BIND9 has done IPv6 for the better part of a decade). Joe From darden at armc.org Thu May 21 11:03:08 2009 From: darden at armc.org (Patrick Darden) Date: Thu, 21 May 2009 12:03:08 -0400 Subject: facebook DNS In-Reply-To: References: Message-ID: <4A157B3C.3060509@armc.org> Whois query gets us: NS2.FACEBOOK.COM 204.74.67.132 DNS05.SF2P.TFBNW.NET DNS04.SF2P.TFBNW.NET NS1.FACEBOOK.COM 204.74.66.132 both 204.74.67.132 and 204.74.66.132 are pingable, but DNS queries on them directly get various answers: nslookup www.facebook.com 204.74.66.132 *** Can't find www.facebook.com: No answer and nslookup www.harvard.edu 204.74.66.132 ** server can't find www.harvard.edu: SERVFAIL This tells me the DNS is set up and semi-working, but incorrectly. It answers correctly for a query for a domain outside its purview, but with a "No answer" for stuff it should know. --p Darden, Patrick S. wrote: > I noticed this as well around 11:50 eastern. > > --Patrick Darden > > > -----Original Message----- > From: Maria Iano [mailto:maria at iano.org] > Sent: Thursday, May 21, 2009 11:56 AM > To: nanog at nanog.org > Subject: facebook DNS > > It looks like facebook is having DNS troubles. The www.facebook.com > subdomain is delegated to some servers that are no longer answering. > Also apps.facebook.com is a cname to www-college.facebook.com which gets > no reply. > > Maria > > > From david at davidcoulson.net Thu May 21 11:07:25 2009 From: david at davidcoulson.net (David Coulson) Date: Thu, 21 May 2009 12:07:25 -0400 Subject: facebook DNS In-Reply-To: References: <701FDB11-4139-44F2-9FA1-56849FB80C2E@iano.org> Message-ID: <4A157C3D.30409@davidcoulson.net> No, when you do a whois for 'fakebook.com' it will pull any registered NS entries containing facebook.com anywhere in the whois db. Digging a.gtld-servers.net is the best way to find authoritative NS for facebook.com, not whois. Clay Haynes wrote: > Looks like someone is messing with the domain nameservers. Possibly a > domain hijack? > > panzer:~ chaynes$ whois facebook.com > > Whois Server Version 2.0 > > Domain names in the .com and .net domains can now be registered > with many different competing registrars. Go to http://www.internic.net > for detailed information. > > FACEBOOK.COM.ZZZZZ.GET.LAID.AT.WWW.SWINGINGCOMMUNITY.COM > FACEBOOK.COM.ZZZZZ.DOWNLOAD.MOVIE.ONLINE.ZML2.COM > FACEBOOK.COM.MORE.INFO.AT.WWW.BEYONDWHOIS.COM > FACEBOOK.COM > > To single out one record, look it up with "xxx", where xxx is one of the > of the records displayed above. If the records are the same, look them > up > with "=xxx" to receive a full display for each record. > > > > - Clay > > -----Original Message----- > From: Maria Iano [mailto:maria at iano.org] > Sent: Thursday, May 21, 2009 11:56 AM > To: nanog at nanog.org > Subject: facebook DNS > > It looks like facebook is having DNS troubles. The www.facebook.com > subdomain is delegated to some servers that are no longer answering. > Also apps.facebook.com is a cname to www-college.facebook.com which > gets no reply. > > Maria > > > From bmanning at vacation.karoshi.com Thu May 21 11:14:10 2009 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Thu, 21 May 2009 16:14:10 +0000 Subject: ISP best practices In-Reply-To: <35BB447D-3CB9-4141-A5A7-01CB7AEB6DC3@hopcount.ca> References: <408493.6724.qm@web30807.mail.mud.yahoo.com> <4A156DE9.90805@xyonet.com> <35BB447D-3CB9-4141-A5A7-01CB7AEB6DC3@hopcount.ca> Message-ID: <20090521161410.GB26917@vacation.karoshi.com.> On Thu, May 21, 2009 at 12:00:58PM -0400, Joe Abley wrote: > > However, you're not necessarily doing anybody any favours in making > statements like "faster", "more secure" and "does IPv6". DNS servers > are complicated beasts, and simplistic comparisons are not useful for > much (it'd be trivial to give you examples where PowerDNS is slower > and less secure, for example, and BIND9 has done IPv6 for the better > part of a decade). ...done IPv6 for the better part of a decade... well yeah, for some very loose definition of "doing IPv6".... > Joe From jabley at hopcount.ca Thu May 21 11:17:53 2009 From: jabley at hopcount.ca (Joe Abley) Date: Thu, 21 May 2009 12:17:53 -0400 Subject: ISP best practices In-Reply-To: <20090521161410.GB26917@vacation.karoshi.com.> References: <408493.6724.qm@web30807.mail.mud.yahoo.com> <4A156DE9.90805@xyonet.com> <35BB447D-3CB9-4141-A5A7-01CB7AEB6DC3@hopcount.ca> <20090521161410.GB26917@vacation.karoshi.com.> Message-ID: <33DCD432-4D53-4C95-A7DF-E3BDD10FACB9@hopcount.ca> On 21-May-2009, at 12:14, bmanning at vacation.karoshi.com wrote: > ...done IPv6 for the better part of a decade... > > well yeah, for some very loose definition of "doing IPv6".... You no doubt have greater expectations than I in that regard :-) Joe From xaerni at pop.ch Thu May 21 11:41:38 2009 From: xaerni at pop.ch (Xaver Aerni) Date: Thu, 21 May 2009 18:41:38 +0200 Subject: facebook DNS References: <701FDB11-4139-44F2-9FA1-56849FB80C2E@iano.org> <4A157C3D.30409@davidcoulson.net> Message-ID: <03A5D9FD7BEE472F845E0856FFF1CF57@telezueri.ch> >From Switzerland it is working fine... 1 <1 ms <1 ms <1 ms [10.0.0.1] 2 1 ms <1 ms <1 ms [10.0.0.2] 3 2 ms 1 ms 3 ms 62-2-78-.static.cablecom.ch [62.2.78.] 4 1 ms 1 ms 1 ms 62-2-66-233.static.cablecom.ch [62.2.66.233] 5 * * 1 ms ch-zrh01a-ra1-ge-1-1-0.aorta.net [213.46.171.49] 6 6 ms 6 ms 6 ms ch-gva01a-ra1-ge-0-1-0.aorta.net [213.46.171.9] 7 15 ms 15 ms 15 ms fr-par02a-rd1-ge-15-0-0.aorta.net [213.46.160.49 ] 8 96 ms 96 ms 97 ms us-was01a-rd1-pos-2-0.aorta.net [213.46.160.170] 9 97 ms 96 ms 99 ms us-was02a-ri1-ge-0-0-0-0.aorta.net [213.46.190.1 90] 10 99 ms 99 ms 99 ms xe-0.equinix.asbnva01.us.bb.gin.ntt.net [206.223 .115.12] 11 * * * Zeit?berschreitung der Anforderung. 12 97 ms 97 ms 97 ms te-7-4.r05.asbnva01.us.ce.gin.ntt.net [168.143.2 28.34] 13 100 ms 107 ms 108 ms te-10-0.csw06b.ash1.tfbnw.net [204.15.20.155] 14 100 ms 100 ms 100 ms www.11.06.ash1.facebook.com [69.63.186.12] Ablaufverfolgung beendet. I think is a Some DNS are false... Greetings Xaver ----- Original Message ----- From: "David Coulson" To: "Clay Haynes" Cc: Sent: Thursday, May 21, 2009 6:07 PM Subject: Re: facebook DNS > No, when you do a whois for 'fakebook.com' it will pull any registered NS > entries containing facebook.com anywhere in the whois db. > > Digging a.gtld-servers.net is the best way to find authoritative NS for > facebook.com, not whois. > > Clay Haynes wrote: >> Looks like someone is messing with the domain nameservers. Possibly a >> domain hijack? >> >> panzer:~ chaynes$ whois facebook.com >> >> Whois Server Version 2.0 >> >> Domain names in the .com and .net domains can now be registered >> with many different competing registrars. Go to http://www.internic.net >> for detailed information. >> >> FACEBOOK.COM.ZZZZZ.GET.LAID.AT.WWW.SWINGINGCOMMUNITY.COM >> FACEBOOK.COM.ZZZZZ.DOWNLOAD.MOVIE.ONLINE.ZML2.COM >> FACEBOOK.COM.MORE.INFO.AT.WWW.BEYONDWHOIS.COM >> FACEBOOK.COM >> >> To single out one record, look it up with "xxx", where xxx is one of the >> of the records displayed above. If the records are the same, look them >> up >> with "=xxx" to receive a full display for each record. >> >> >> >> - Clay >> >> -----Original Message----- >> From: Maria Iano [mailto:maria at iano.org] Sent: Thursday, May 21, 2009 >> 11:56 AM >> To: nanog at nanog.org >> Subject: facebook DNS >> >> It looks like facebook is having DNS troubles. The www.facebook.com >> subdomain is delegated to some servers that are no longer answering. >> Also apps.facebook.com is a cname to www-college.facebook.com which gets >> no reply. >> >> Maria >> >> >> > > From john at sackheads.org Thu May 21 11:56:11 2009 From: john at sackheads.org (John Payne) Date: Thu, 21 May 2009 12:56:11 -0400 Subject: facebook DNS In-Reply-To: <4A157B3C.3060509@armc.org> References: <4A157B3C.3060509@armc.org> Message-ID: <4E353898-FD99-4EE0-A2C2-74D69F727BAA@sackheads.org> On May 21, 2009, at 12:03 PM, Patrick Darden wrote: > Whois query gets us: > NS2.FACEBOOK.COM 204.74.67.132 > DNS05.SF2P.TFBNW.NET DNS04.SF2P.TFBNW.NET > NS1.FACEBOOK.COM 204.74.66.132 > > both 204.74.67.132 and 204.74.66.132 are pingable, but DNS queries > on them directly get various answers: > > nslookup www.facebook.com 204.74.66.132 > *** Can't find www.facebook.com: No answer > > and > nslookup www.harvard.edu 204.74.66.132 > ** server can't find www.harvard.edu: SERVFAIL > > This tells me the DNS is set up and semi-working, but incorrectly. > It answers correctly for a query for a domain outside its purview, > but with a "No answer" for stuff it should know. a) why are you relying on whois for stuff that's authoritative in DNS? b) isn't this what the outages list is for? > > > --p > > > > Darden, Patrick S. wrote: >> I noticed this as well around 11:50 eastern. >> >> --Patrick Darden >> >> >> -----Original Message----- >> From: Maria Iano [mailto:maria at iano.org] Sent: Thursday, May 21, >> 2009 11:56 AM >> To: nanog at nanog.org >> Subject: facebook DNS >> >> It looks like facebook is having DNS troubles. The www.facebook.com >> subdomain is delegated to some servers that are no longer >> answering. Also apps.facebook.com is a cname to www- >> college.facebook.com which gets >> no reply. >> >> Maria >> >> >> > From maria at iano.org Thu May 21 12:48:51 2009 From: maria at iano.org (Maria Iano) Date: Thu, 21 May 2009 13:48:51 -0400 Subject: facebook DNS In-Reply-To: <4E353898-FD99-4EE0-A2C2-74D69F727BAA@sackheads.org> References: <4A157B3C.3060509@armc.org> <4E353898-FD99-4EE0-A2C2-74D69F727BAA@sackheads.org> Message-ID: <9D2711A4-3C8C-49ED-9AC9-AB44E3B8DD53@iano.org> Sorry - my bad - I will post to outages in future. Digs to name servers were showing similar results to Patrick's below. However, it seems to be fixed now. Maria On May 21, 2009, at 12:56 PM, John Payne wrote: > > On May 21, 2009, at 12:03 PM, Patrick Darden wrote: > >> Whois query gets us: >> NS2.FACEBOOK.COM 204.74.67.132 >> DNS05.SF2P.TFBNW.NET DNS04.SF2P.TFBNW.NET >> NS1.FACEBOOK.COM 204.74.66.132 >> >> both 204.74.67.132 and 204.74.66.132 are pingable, but DNS queries >> on them directly get various answers: >> >> nslookup www.facebook.com 204.74.66.132 >> *** Can't find www.facebook.com: No answer >> >> and >> nslookup www.harvard.edu 204.74.66.132 >> ** server can't find www.harvard.edu: SERVFAIL >> >> This tells me the DNS is set up and semi-working, but incorrectly. >> It answers correctly for a query for a domain outside its purview, >> but with a "No answer" for stuff it should know. > > a) why are you relying on whois for stuff that's authoritative in DNS? > b) isn't this what the outages list is for? > > >> >> >> --p >> >> >> >> Darden, Patrick S. wrote: >>> I noticed this as well around 11:50 eastern. >>> >>> --Patrick Darden >>> >>> >>> -----Original Message----- >>> From: Maria Iano [mailto:maria at iano.org] Sent: Thursday, May 21, >>> 2009 11:56 AM >>> To: nanog at nanog.org >>> Subject: facebook DNS >>> >>> It looks like facebook is having DNS troubles. The www.facebook.com >>> subdomain is delegated to some servers that are no longer >>> answering. Also apps.facebook.com is a cname to www- >>> college.facebook.com which gets >>> no reply. >>> >>> Maria >>> >>> >>> >> > From cmaurand at xyonet.com Thu May 21 14:09:40 2009 From: cmaurand at xyonet.com (Curtis Maurand) Date: Thu, 21 May 2009 15:09:40 -0400 Subject: ISP best practices In-Reply-To: <35BB447D-3CB9-4141-A5A7-01CB7AEB6DC3@hopcount.ca> References: <408493.6724.qm@web30807.mail.mud.yahoo.com> <4A156DE9.90805@xyonet.com> <35BB447D-3CB9-4141-A5A7-01CB7AEB6DC3@hopcount.ca> Message-ID: <4A15A6F4.3070701@xyonet.com> You're correct on the blanket statement. apologies. --C Joe Abley wrote: > > On 21-May-2009, at 11:06, Curtis Maurand wrote: > >> Check out www.powerdns.com as an alternative to bind. Its faster, >> more secure, does IPV6 and easier to maintain. > > I have heard lots of good things about PowerDNS, and I'm quite > prepared to believe that it's a natural choice for a DNS hosting > service where the database back-end makes for far simpler provisioning > and control than managing a pile of config files. > > However, you're not necessarily doing anybody any favours in making > statements like "faster", "more secure" and "does IPv6". DNS servers > are complicated beasts, and simplistic comparisons are not useful for > much (it'd be trivial to give you examples where PowerDNS is slower > and less secure, for example, and BIND9 has done IPv6 for the better > part of a decade). > > > Joe From sronan at fattoc.com Thu May 21 15:38:40 2009 From: sronan at fattoc.com (Shane Ronan) Date: Thu, 21 May 2009 16:38:40 -0400 Subject: ISP best practices In-Reply-To: <408493.6724.qm@web30807.mail.mud.yahoo.com> References: <408493.6724.qm@web30807.mail.mud.yahoo.com> Message-ID: <5C97B732-CCB5-4A99-B2FE-69C2B56CA98C@fattoc.com> I learned DNS initially by reading some great documents by Avi Freedman, they are a little out dated, but still very relevant and posted on his website @ http://www.freedman.net/ On May 21, 2009, at 9:38 AM, Philip Lavine wrote: > > To all, > > I am sure this has been asked 10 to the 1 millionth power times, > however may be the rules have changed. I am looking to set up a > really small ISP with a few /24's. I want to host DNS as well. Is > there any whitepapers/howtos/best practices on setting up multihomed > BGP and DNS with BIND so I don't blow up the Internet. > > Thx > > Philip > > > > > From akennedy at cyberlinktech.com Thu May 21 15:40:31 2009 From: akennedy at cyberlinktech.com (Adam Kennedy) Date: Thu, 21 May 2009 16:40:31 -0400 Subject: ISP best practices In-Reply-To: <4A156DE9.90805@xyonet.com> Message-ID: Bind is fully capable of IPv6. When combined with Webmin (www.webmin.com), I'm not sure how much easier Bind can get. Webmin will also keep DNSSEC keys up to date with changes, so long as you make those changes from within Webmin. If you make changes in CLI, you can tell Webmin to rehash the keys manually. It's as simple as clicking a GUI button. On 5/21/09 11:06 AM, "Curtis Maurand" wrote: > > Check out www.powerdns.com as an alternative to bind. Its faster, more > secure, does IPV6 and easier to maintain. > > Curtis > > Philip Lavine wrote: >> To all, >> >> I am sure this has been asked 10 to the 1 millionth power times, however may >> be the rules have changed. I am looking to set up a really small ISP with a >> few /24's. I want to host DNS as well. Is there any whitepapers/howtos/best >> practices on setting up multihomed BGP and DNS with BIND so I don't blow up >> the Internet. >> >> Thx >> >> Philip >> >> >> >> >> >> > -- Adam Kennedy Senior Network Administrator Cyberlink Technologies, Inc. Phone: 888-293-3693 x4352 Fax: 574-855-5761 From sronan at fattoc.com Thu May 21 15:41:06 2009 From: sronan at fattoc.com (Shane Ronan) Date: Thu, 21 May 2009 16:41:06 -0400 Subject: ISP best practices In-Reply-To: <5C97B732-CCB5-4A99-B2FE-69C2B56CA98C@fattoc.com> References: <408493.6724.qm@web30807.mail.mud.yahoo.com> <5C97B732-CCB5-4A99-B2FE-69C2B56CA98C@fattoc.com> Message-ID: Apologies, this should have said I learned BGP initially not DNS. Sorry!! On May 21, 2009, at 4:38 PM, Shane Ronan wrote: > I learned DNS initially by reading some great documents by Avi > Freedman, they are a little out dated, but still very relevant and > posted on his website @ http://www.freedman.net/ > > > On May 21, 2009, at 9:38 AM, Philip Lavine wrote: > >> >> To all, >> >> I am sure this has been asked 10 to the 1 millionth power times, >> however may be the rules have changed. I am looking to set up a >> really small ISP with a few /24's. I want to host DNS as well. Is >> there any whitepapers/howtos/best practices on setting up >> multihomed BGP and DNS with BIND so I don't blow up the Internet. >> >> Thx >> >> Philip >> >> >> >> >> > > From jason at electronet.net Thu May 21 15:48:42 2009 From: jason at electronet.net (Jason Bertoch) Date: Thu, 21 May 2009 16:48:42 -0400 Subject: ISP best practices In-Reply-To: References: <4A156DE9.90805@xyonet.com> Message-ID: <009101c9da55$8707a3f0$9516ebd0$@net> > -----Original Message----- > From: Adam Kennedy [mailto:akennedy at cyberlinktech.com] > Sent: Thursday, May 21, 2009 4:41 PM > To: NANOG > Subject: Re: ISP best practices > > ...When combined with Webmin (www.webmin.com), Jason A. Bertoch Network Administrator jason at electronet.net Electronet Broadband Communications 3411 Capital Medical Blvd. Tallahassee, FL 32308 (V) 850.222.0229 (F) 850.222.8771 From lists at mtin.net Thu May 21 15:58:02 2009 From: lists at mtin.net (Justin Wilson - MTIN) Date: Thu, 21 May 2009 16:58:02 -0400 Subject: ISP best practices In-Reply-To: <009101c9da55$8707a3f0$9516ebd0$@net> Message-ID: We have several clients using Webmin. If you don?t know command line Webmin is another tool to help you learn. You can have webmin do it and then look at the config to learn. Justin From: Jason Bertoch Date: Thu, 21 May 2009 16:48:42 -0400 To: Subject: RE: ISP best practices > -----Original Message----- > From: Adam Kennedy [mailto:akennedy at cyberlinktech.com] > Sent: Thursday, May 21, 2009 4:41 PM > To: NANOG > Subject: Re: ISP best practices > > ...When combined with Webmin (www.webmin.com), Jason A. Bertoch Network Administrator jason at electronet.net Electronet Broadband Communications 3411 Capital Medical Blvd. Tallahassee, FL 32308 (V) 850.222.0229 (F) 850.222.8771 From sronan at fattoc.com Thu May 21 16:07:24 2009 From: sronan at fattoc.com (Shane Ronan) Date: Thu, 21 May 2009 17:07:24 -0400 Subject: ISP best practices In-Reply-To: References: Message-ID: <887C3C19-38E1-49B8-A88F-897883462B27@fattoc.com> I have to agree. I've been working with BIND for over 10 years, and still use webmin to help me keep things organized. On May 21, 2009, at 4:58 PM, Justin Wilson - MTIN wrote: > > We have several clients using Webmin. If you don?t know command > line > Webmin is another tool to help you learn. You can have webmin do it > and > then look at the config to learn. > > Justin > > > From: Jason Bertoch > Date: Thu, 21 May 2009 16:48:42 -0400 > To: > Subject: RE: ISP best practices > >> -----Original Message----- >> From: Adam Kennedy [mailto:akennedy at cyberlinktech.com] >> Sent: Thursday, May 21, 2009 4:41 PM >> To: NANOG >> Subject: Re: ISP best practices >> >> ...When combined with Webmin (www.webmin.com), > > > > > Jason A. Bertoch > Network Administrator > jason at electronet.net > Electronet Broadband Communications > 3411 Capital Medical Blvd. > Tallahassee, FL 32308 > (V) 850.222.0229 (F) 850.222.8771 > > From sethm at rollernet.us Thu May 21 16:25:46 2009 From: sethm at rollernet.us (Seth Mattinen) Date: Thu, 21 May 2009 14:25:46 -0700 Subject: ISP best practices In-Reply-To: References: Message-ID: <4A15C6DA.6010806@rollernet.us> Adam Kennedy wrote: > Bind is fully capable of IPv6. When combined with Webmin (www.webmin.com), > I'm not sure how much easier Bind can get. Webmin will also keep DNSSEC keys > up to date with changes, so long as you make those changes from within > Webmin. If you make changes in CLI, you can tell Webmin to rehash the keys > manually. It's as simple as clicking a GUI button. > Does anyone still use probind? As much as I am gung-ho command line, managing a huge amount of DNS can get ugly. ~Seth From lowen at pari.edu Thu May 21 16:44:23 2009 From: lowen at pari.edu (Lamar Owen) Date: Thu, 21 May 2009 17:44:23 -0400 Subject: ISP best practices In-Reply-To: <38C05B18-2ABA-42A5-9223-3762E10B6B33@arbor.net> References: <408493.6724.qm@web30807.mail.mud.yahoo.com> Message-ID: <200905211744.23442.lowen@pari.edu> On Thursday 21 May 2009 10:14:00 am Roland Dobbins wrote: > On May 21, 2009, at 8:45 PM, Steve Bertrand wrote: > > Securing IP Network Traffic Planes: > > - http://www.ciscopress.com/bookstore/product.asp?isbn=1587053365 > > I can't recommend this book enough - it's the current canonical > reference on opsec-related BCPs for network infrastructure, IMHO (full > disclosure: I was fortunate enough to have the opportunity to provide > some feedback to the authors as they worked on this tome, but have no > financial interest whatsoever in its publication or sales thereof). Ah, a good use for my Safari account. Hmm, there's you a resource; for ~$20 per month, get access to books to read online, download chapters in PDF format for later perusal. I can read this, and if it looks like something I want, I also get a discount ordering through informit. Safari: http://my.safaribooksonline.com/home You do need to read a lot to make it worthwhile; advantage is that you don't have to store or resell the book later. From mmaberry at gmail.com Thu May 21 21:36:36 2009 From: mmaberry at gmail.com (Mike Maberry) Date: Thu, 21 May 2009 19:36:36 -0700 Subject: Is Comcast on the east coast having trouble? Message-ID: Hi, Wondering if there is an issue with Comcast on east coast. My tracert are dying at mclean.va.ibone.comcast.net ... thanks for any information you can provide. Mike M From ABass at arise.com Thu May 21 21:38:41 2009 From: ABass at arise.com (Allen Bass) Date: Thu, 21 May 2009 22:38:41 -0400 Subject: Is Comcast on the east coast having trouble? In-Reply-To: References: Message-ID: I'm on Comcast on the east coast in Miami Florida and am not having any issues at the moment. * * * * * Allen Bass Manager, Technology Operations Arise Virtual Solutions Inc. Miramar, Florida 33027 www.arise.com -----Original Message----- From: Mike Maberry [mailto:mmaberry at gmail.com] Sent: Thursday, May 21, 2009 10:37 PM To: nanog at nanog.org Subject: Is Comcast on the east coast having trouble? Hi, Wondering if there is an issue with Comcast on east coast. My tracert are dying at mclean.va.ibone.comcast.net ... thanks for any information you can provide. Mike M From Courtney_Smith at Cable.Comcast.com Thu May 21 23:57:06 2009 From: Courtney_Smith at Cable.Comcast.com (Smith, Courtney) Date: Fri, 22 May 2009 00:57:06 -0400 Subject: Is Comcast on the east coast having trouble? In-Reply-To: References: Message-ID: <7372D9734C591745A4C1D81017D5ABF60DE086F7@NJCHLEXCMB01.cable.comcast.com> Are you still seeing the problem? We believe we have isolated the problem circuit. Courtney Smith Network Engineer Comcast, National Engineering & Technical Operations -----Original Message----- From: Mike Maberry [mailto:mmaberry at gmail.com] Sent: Thursday, May 21, 2009 10:37 PM To: nanog at nanog.org Subject: Is Comcast on the east coast having trouble? Hi, Wondering if there is an issue with Comcast on east coast. My tracert are dying at mclean.va.ibone.comcast.net ... thanks for any information you can provide. Mike M From chanty_kh at yahoo.com Fri May 22 00:23:21 2009 From: chanty_kh at yahoo.com (ty chan) Date: Thu, 21 May 2009 22:23:21 -0700 (PDT) Subject: Local Peering and Transit - BGP multihoming Message-ID: <737622.36174.qm@web52312.mail.re2.yahoo.com> Dear all, In my lab, i manage two ASN (100,200). ASN100 has one transit to ASN300 and local peering to ASN500. ASN200 has one transit to ASN400. ASN100 do private peering to ASN200. Some policies are required as below: 1. ASN100 customer can only use ASN300 for transit 2. ASN200 customer can only use ASN400 for transit. 3. Local traffic will stay local between ASN100,ASN200 and ASN500. 4. ASN100 and ASN200 are backup each other only if either upstreams is down. How to configure BGP to meet the above policies? I am using Cisco devise. best regards, chanty From sethm at rollernet.us Fri May 22 00:34:29 2009 From: sethm at rollernet.us (Seth Mattinen) Date: Thu, 21 May 2009 22:34:29 -0700 Subject: Local Peering and Transit - BGP multihoming In-Reply-To: <737622.36174.qm@web52312.mail.re2.yahoo.com> References: <737622.36174.qm@web52312.mail.re2.yahoo.com> Message-ID: <4A163965.4020500@rollernet.us> ty chan wrote: > Dear all, > > In my lab, i manage two ASN (100,200). ASN100 has one transit to ASN300 and local peering to ASN500. > ASN200 has one transit to ASN400. ASN100 do private peering to ASN200. Some policies are required as below: > 1. ASN100 customer can only use ASN300 for transit > 2. ASN200 customer can only use ASN400 for transit. > 3. Local traffic will stay local between ASN100,ASN200 and ASN500. > 4. ASN100 and ASN200 are backup each other only if either upstreams is down. > > How to configure BGP to meet the above policies? I am using Cisco devise. > Is there a reason you are just throwing specs out and expecting the list to do your job for you? I don't mean to be rude, but you should learn how to at least do some of it yourself so you can ask specific questions for the parts you have trouble getting it to work. ~Seth From deleskie at gmail.com Fri May 22 00:42:14 2009 From: deleskie at gmail.com (deleskie at gmail.com) Date: Fri, 22 May 2009 05:42:14 +0000 Subject: Local Peering and Transit - BGP multihoming Message-ID: <1184640185-1242970936-cardhu_decombobulator_blackberry.rim.net-1583315332-@bxe1087.bisx.prod.on.blackberry> Google BGP Cisco... Should give you 90% of this. ------Original Message------ From: ty chan To: nanog at nanog.org Subject: Local Peering and Transit - BGP multihoming Sent: May 22, 2009 2:23 AM Dear all, In my lab, i manage two ASN (100,200). ASN100 has one transit to ASN300 and local peering to ASN500. ASN200 has one transit to ASN400. ASN100 do private peering to ASN200. Some policies are required as below: 1. ASN100 customer can only use ASN300 for transit 2. ASN200 customer can only use ASN400 for transit. 3. Local traffic will stay local between ASN100,ASN200 and ASN500. 4. ASN100 and ASN200 are backup each other only if either upstreams is down. How to configure BGP to meet the above policies? I am using Cisco devise. best regards, chanty Sent from my BlackBerry device on the Rogers Wireless Network From chanty_kh at yahoo.com Fri May 22 01:14:24 2009 From: chanty_kh at yahoo.com (ty chan) Date: Thu, 21 May 2009 23:14:24 -0700 (PDT) Subject: Local Peering and Transit - BGP multihoming In-Reply-To: <1184640185-1242970936-cardhu_decombobulator_blackberry.rim.net-1583315332-@bxe1087.bisx.prod.on.blackberry> References: <1184640185-1242970936-cardhu_decombobulator_blackberry.rim.net-1583315332-@bxe1087.bisx.prod.on.blackberry> Message-ID: <537479.73764.qm@web52308.mail.re2.yahoo.com> Yes, i can get sample of configuration via Google search. but i am looking for best practices and from experience people. ________________________________ From: "deleskie at gmail.com" To: ty chan ; nanog at nanog.org Sent: Friday, May 22, 2009 12:42:14 PM Subject: Re: Local Peering and Transit - BGP multihoming Google BGP Cisco... Should give you 90% of this. ------Original Message------ From: ty chan To: nanog at nanog.org Subject: Local Peering and Transit - BGP multihoming Sent: May 22, 2009 2:23 AM Dear all, In my lab, i manage two ASN (100,200). ASN100 has one transit to ASN300 and local peering to ASN500. ASN200 has one transit to ASN400. ASN100 do private peering to ASN200. Some policies are required as below: 1. ASN100 customer can only use ASN300 for transit 2. ASN200 customer can only use ASN400 for transit. 3. Local traffic will stay local between ASN100,ASN200 and ASN500. 4. ASN100 and ASN200 are backup each other only if either upstreams is down. How to configure BGP to meet the above policies? I am using Cisco devise. best regards, chanty Sent from my BlackBerry device on the Rogers Wireless Network From raymond at prolocation.net Fri May 22 03:55:14 2009 From: raymond at prolocation.net (Raymond Dijkxhoorn) Date: Fri, 22 May 2009 10:55:14 +0200 (CEST) Subject: Local Peering and Transit - BGP multihoming In-Reply-To: <537479.73764.qm@web52308.mail.re2.yahoo.com> References: <1184640185-1242970936-cardhu_decombobulator_blackberry.rim.net-1583315332-@bxe1087.bisx.prod.on.blackberry> <537479.73764.qm@web52308.mail.re2.yahoo.com> Message-ID: Hi! > Yes, i can get sample of configuration via Google search. > but i am looking for best practices and from experience people. Then post your suggested config and ask for comments. Bye, Raymond. From mansaxel at besserwisser.org Fri May 22 04:00:34 2009 From: mansaxel at besserwisser.org (Mans Nilsson) Date: Fri, 22 May 2009 11:00:34 +0200 Subject: Local Peering and Transit - BGP multihoming In-Reply-To: References: <1184640185-1242970936-cardhu_decombobulator_blackberry.rim.net-1583315332-@bxe1087.bisx.prod.on.blackberry> <537479.73764.qm@web52308.mail.re2.yahoo.com> Message-ID: <20090522090033.GG25561@besserwisser.org> Subject: Re: Local Peering and Transit - BGP multihoming Date: Fri, May 22, 2009 at 10:55:14AM +0200 Quoting Raymond Dijkxhoorn (raymond at prolocation.net): > Hi! > >> Yes, i can get sample of configuration via Google search. >> but i am looking for best practices and from experience people. > > Then post your suggested config and ask for comments. ...on a suitable list, dedicated to Cisco gear.. -- M?ns Nilsson From raymond at prolocation.net Fri May 22 04:01:48 2009 From: raymond at prolocation.net (Raymond Dijkxhoorn) Date: Fri, 22 May 2009 11:01:48 +0200 (CEST) Subject: Local Peering and Transit - BGP multihoming In-Reply-To: <20090522090033.GG25561@besserwisser.org> References: <1184640185-1242970936-cardhu_decombobulator_blackberry.rim.net-1583315332-@bxe1087.bisx.prod.on.blackberry> <537479.73764.qm@web52308.mail.re2.yahoo.com> <20090522090033.GG25561@besserwisser.org> Message-ID: Hi! >>> Yes, i can get sample of configuration via Google search. >>> but i am looking for best practices and from experience people. >> Then post your suggested config and ask for comments. > ...on a suitable list, dedicated to Cisco gear.. Sorry, yes. :-) Plenty of Cisco lists there to answer 'questions' :-) Bye, Raymond. From j at arpa.com Fri May 22 04:29:06 2009 From: j at arpa.com (jamie rishaw) Date: Fri, 22 May 2009 04:29:06 -0500 Subject: Local Peering and Transit - BGP multihoming In-Reply-To: References: <1184640185-1242970936-cardhu_decombobulator_blackberry.rim.net-1583315332-@bxe1087.bisx.prod.on.blackberry> <537479.73764.qm@web52308.mail.re2.yahoo.com> <20090522090033.GG25561@besserwisser.org> Message-ID: on issues like this : [1] JFGI -> if fail : [2] man smartnet -> if fail : [3] go back to studying to get that A+ and consider perhaps a yob in redmond On Fri, May 22, 2009 at 4:01 AM, Raymond Dijkxhoorn wrote: > Hi! > > Yes, i can get sample of configuration via Google search. >>>> but i am looking for best practices and from experience people. >>>> >>> > Then post your suggested config and ask for comments. >>> >> > ...on a suitable list, dedicated to Cisco gear.. >> > > Sorry, yes. :-) Plenty of Cisco lists there to answer 'questions' :-) > > Bye, > Raymond. > > -- Jamie Rishaw // .com.arpa at j <- reverse it. ish. [Impressive C-level Title Here], arpa / arpa labs From cidr-report at potaroo.net Fri May 22 07:00:27 2009 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 22 May 2009 22:00:27 +1000 (EST) Subject: BGP Update Report Message-ID: <200905221200.n4MC0RuM049967@wattle.apnic.net> BGP Update Report Interval: 19-Apr-09 -to- 20-May-09 (32 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS3130 135278 2.3% 526.4 -- RGNET-3130 RGnet/PSGnet 2 - AS6389 54635 0.9% 12.6 -- BELLSOUTH-NET-BLK - BellSouth.net Inc. 3 - AS21491 54546 0.9% 1818.2 -- UTL-ON-LINE UTL On-line is RF broadband ISP in Uganda - Africa 4 - AS8452 46129 0.8% 35.6 -- TEDATA TEDATA 5 - AS35805 44098 0.8% 124.6 -- UTG-AS United Telecom AS 6 - AS4323 43945 0.8% 10.1 -- TWTC - tw telecom holdings, inc. 7 - AS17488 40990 0.7% 25.7 -- HATHWAY-NET-AP Hathway IP Over Cable Internet 8 - AS33776 39232 0.7% 335.3 -- STARCOMMS-ASN 9 - AS8151 37150 0.6% 25.3 -- Uninet S.A. de C.V. 10 - AS10834 35002 0.6% 13.8 -- Telefonica Data Argentina S.A. 11 - AS17974 32954 0.6% 30.3 -- TELKOMNET-AS2-AP PT Telekomunikasi Indonesia 12 - AS5056 31911 0.6% 270.4 -- INS-NET-2 - Iowa Network Services 13 - AS20115 30284 0.5% 17.9 -- CHARTER-NET-HKY-NC - Charter Communications 14 - AS22773 30145 0.5% 28.0 -- ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 15 - AS4249 26865 0.5% 148.4 -- LILLY-AS - Eli Lilly and Company 16 - AS2920 26393 0.5% 321.9 -- LACOE - Los Angeles County Office of Education 17 - AS18566 25689 0.4% 24.1 -- COVAD - Covad Communications Co. 18 - AS15045 25633 0.4% 6408.2 -- KITTELSON - KITTELSON AND ASSOCIATES, INC. 19 - AS5050 25385 0.4% 1813.2 -- PSC-EXT - Pittsburgh Supercomputing Center 20 - AS29049 25109 0.4% 77.7 -- DELTA-TELECOM-AS Delta Telecom LTD. TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS15045 25633 0.4% 6408.2 -- KITTELSON - KITTELSON AND ASSOCIATES, INC. 2 - AS40967 4159 0.1% 4159.0 -- CSF-AS CSF Computersoftware fuer Fachanwendungen GmbH 3 - AS16931 8223 0.1% 4111.5 -- GLOBAL-PAYMENTS-1 - Global Payments, Inc. 4 - AS32398 21297 0.4% 3549.5 -- REALNET-ASN-1 5 - AS13325 24488 0.4% 3061.0 -- STOMI - State of Michigan, DMB-CNOC 6 - AS13153 2546 0.0% 2546.0 -- ONEWORLD OneWorld S.A. 7 - AS29229 2447 0.0% 2447.0 -- ASDA-AS Assotiation for the Development of West Athens 8 - AS8499 2221 0.0% 2221.0 -- Space Hellas Network Operation Center (NOC) 9 - AS30423 4086 0.1% 2043.0 -- AMEDI-3-ASN1 - Amedisys, Inc. 10 - AS2 1901 0.0% 4.0 -- NAVITAIRE-AS-AU-AP Accenture - Navitaire, 11 - AS47640 5605 0.1% 1868.3 -- TRICOMPAS Tricomp Sp. z. o. o. 12 - AS21491 54546 0.9% 1818.2 -- UTL-ON-LINE UTL On-line is RF broadband ISP in Uganda - Africa 13 - AS39803 3635 0.1% 1817.5 -- UTI-AS SC UTI COMMUNICATIONS SYSTEMS SRL 14 - AS5050 25385 0.4% 1813.2 -- PSC-EXT - Pittsburgh Supercomputing Center 15 - AS46653 4901 0.1% 1633.7 -- FREDRIKSON---BYRON - Fredrikson & Byron, P.A. 16 - AS46328 10722 0.2% 1191.3 -- PTCNEBRASKA - PIERCE TELEPHONE COMPANY, INCORPORATED 17 - AS28953 2324 0.0% 1162.0 -- PIRAEUSBANK Greek banking institution 18 - AS47299 1084 0.0% 1084.0 -- DRSA-AS Dlugie Rozmowy S.A. 19 - AS28256 1075 0.0% 1075.0 -- 20 - AS24994 2143 0.0% 1071.5 -- GENESYS-AS GENESYS Informatica AS for announcing own prefixes TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 72.23.246.0/24 24946 0.4% AS5050 -- PSC-EXT - Pittsburgh Supercomputing Center 2 - 41.204.2.0/24 21249 0.3% AS32398 -- REALNET-ASN-1 3 - 192.12.120.0/24 10320 0.2% AS5691 -- MITRE-AS-5 - The MITRE Corporation 4 - 63.103.104.0/22 8912 0.1% AS15045 -- KITTELSON - KITTELSON AND ASSOCIATES, INC. 5 - 63.103.108.0/23 8912 0.1% AS15045 -- KITTELSON - KITTELSON AND ASSOCIATES, INC. 6 - 64.69.192.0/20 8217 0.1% AS16931 -- GLOBAL-PAYMENTS-1 - Global Payments, Inc. 7 - 63.103.110.0/24 7795 0.1% AS15045 -- KITTELSON - KITTELSON AND ASSOCIATES, INC. 8 - 123.49.152.0/24 7511 0.1% AS18118 -- CITICNET-AP CITIC Networks Management Co.,Ltd. 9 - 123.49.144.0/21 6866 0.1% AS18118 -- CITICNET-AP CITIC Networks Management Co.,Ltd. 10 - 195.96.69.0/24 6840 0.1% AS8225 -- ASTELIT-MSK-AS Astelit Autonomous System 11 - 90.150.0.0/24 6121 0.1% AS35400 -- MFIST Interregoinal Organization Network Technologies 12 - 193.201.184.0/21 5789 0.1% AS25546 -- BROOKLANDCOMP-AS Brookland Computer Services 13 - 81.199.18.0/24 5628 0.1% AS21491 -- UTL-ON-LINE UTL On-line is RF broadband ISP in Uganda - Africa 14 - 94.124.16.0/21 5540 0.1% AS47640 -- TRICOMPAS Tricomp Sp. z. o. o. 15 - 196.0.0.0/16 5374 0.1% AS21491 -- UTL-ON-LINE UTL On-line is RF broadband ISP in Uganda - Africa 16 - 81.199.23.0/24 5290 0.1% AS21491 -- UTL-ON-LINE UTL On-line is RF broadband ISP in Uganda - Africa 17 - 81.199.16.0/22 5283 0.1% AS21491 -- UTL-ON-LINE UTL On-line is RF broadband ISP in Uganda - Africa 18 - 81.199.22.0/24 5253 0.1% AS21491 -- UTL-ON-LINE UTL On-line is RF broadband ISP in Uganda - Africa 19 - 81.199.21.0/24 5214 0.1% AS21491 -- UTL-ON-LINE UTL On-line is RF broadband ISP in Uganda - Africa 20 - 81.199.28.0/22 5199 0.1% AS21491 -- UTL-ON-LINE UTL On-line is RF broadband ISP in Uganda - Africa Details at http://bgpupdates.potaroo.net ------------------------------------ Copies of this report are mailed to: nanog at merit.edu eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From cidr-report at potaroo.net Fri May 22 07:00:03 2009 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 22 May 2009 22:00:03 +1000 (EST) Subject: The Cidr Report Message-ID: <200905221200.n4MC03Qp049891@wattle.apnic.net> This report has been generated at Fri May 22 21:21:01 2009 AEST. The report analyses the BGP Routing Table of AS2.0 router and generates a report on aggregation potential within the table. Check http://www.cidr-report.org for a current version of this report. Recent Table History Date Prefixes CIDR Agg 15-05-09 294616 184074 16-05-09 294623 184165 17-05-09 294181 184536 18-05-09 294340 184423 19-05-09 294392 184113 20-05-09 294351 184487 21-05-09 294523 184151 22-05-09 294690 184776 AS Summary 31384 Number of ASes in routing system 13350 Number of ASes announcing only one prefix 4296 Largest number of prefixes announced by an AS AS6389 : BELLSOUTH-NET-BLK - BellSouth.net Inc. 89741568 Largest address span announced by an AS (/32s) AS27064: DNIC-ASBLK-27032-27159 - DoD Network Information Center Aggregation Summary The algorithm used in this report proposes aggregation only when there is a precise match using the AS path, so as to preserve traffic transit policies. Aggregation is also proposed across non-advertised address space ('holes'). --- 22May09 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 295607 184781 110826 37.5% All ASes AS6389 4296 338 3958 92.1% BELLSOUTH-NET-BLK - BellSouth.net Inc. AS4323 4272 1777 2495 58.4% TWTC - tw telecom holdings, inc. AS209 2537 1159 1378 54.3% ASN-QWEST - Qwest Communications Corporation AS4766 1811 520 1291 71.3% KIXS-AS-KR Korea Telecom AS17488 1586 302 1284 81.0% HATHWAY-NET-AP Hathway IP Over Cable Internet AS4755 1251 149 1102 88.1% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP AS22773 1065 84 981 92.1% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. AS1785 1766 835 931 52.7% AS-PAETEC-NET - PaeTec Communications, Inc. AS8452 1203 307 896 74.5% TEDATA TEDATA AS8151 1445 575 870 60.2% Uninet S.A. de C.V. AS19262 999 238 761 76.2% VZGNI-TRANSIT - Verizon Internet Services Inc. AS18566 1062 424 638 60.1% COVAD - Covad Communications Co. AS6478 1411 817 594 42.1% ATT-INTERNET3 - AT&T WorldNet Services AS18101 752 171 581 77.3% RIL-IDC Reliance Infocom Ltd Internet Data Centre, AS11492 1100 551 549 49.9% CABLEONE - CABLE ONE, INC. AS855 623 101 522 83.8% CANET-ASN-4 - Bell Aliant Regional Communications, Inc. AS22047 610 98 512 83.9% VTR BANDA ANCHA S.A. AS577 1226 724 502 40.9% BACOM - Bell Canada AS2706 536 44 492 91.8% HKSUPER-HK-AP Pacific Internet (Hong Kong) Limited AS17676 565 81 484 85.7% GIGAINFRA Softbank BB Corp. AS7018 1500 1035 465 31.0% ATT-INTERNET4 - AT&T WorldNet Services AS4808 629 169 460 73.1% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network AS24560 692 258 434 62.7% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services AS9443 526 102 424 80.6% INTERNETPRIMUS-AS-AP Primus Telecommunications AS6517 661 241 420 63.5% RELIANCEGLOBALCOM - Reliance Globalcom Services, Inc AS7011 968 556 412 42.6% FRONTIER-AND-CITIZENS - Frontier Communications of America, Inc. AS4668 691 283 408 59.0% LGNET-AS-KR LG CNS AS10620 914 514 400 43.8% TV Cable S.A. AS5668 775 377 398 51.4% AS-5668 - CenturyTel Internet Holdings, Inc. AS4780 525 130 395 75.2% SEEDNET Digital United Inc. Total 37997 12960 25037 65.9% Top 30 total Possible Bogus Routes 24.245.128.0/17 AS11492 CABLEONE - CABLE ONE, INC. 41.223.112.0/22 AS5713 SAIX-NET 41.223.176.0/22 AS36981 41.223.188.0/24 AS22351 INTELSAT Intelsat Global BGP Routing Policy 41.223.189.0/24 AS26452 BRING-AS - BringCom, Inc. 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV - Wireless Broadband via Satellite 62.61.221.0/24 AS24974 TACHYON-EU Tachyon Europe BV - Wireless Broadband via Satellite 63.140.213.0/24 AS22555 UTC - Universal Talkware Corporation 63.143.251.0/24 AS22555 UTC - Universal Talkware Corporation 64.31.32.0/19 AS11955 SCRR-11955 - Road Runner HoldCo LLC 64.31.59.0/24 AS7017 SCRR-7015 - Road Runner HoldCo LLC 64.31.60.0/24 AS7017 SCRR-7015 - Road Runner HoldCo LLC 64.79.88.0/24 AS26096 LODDEN - Lodden Services 64.79.89.0/24 AS26096 LODDEN - Lodden Services 66.54.91.0/24 AS30506 BLACKSUN-1 - Blacksun Technologies LLC 66.55.160.0/19 AS29994 66.128.38.0/24 AS15246 Telecomunicaciones Satelitales TelesatS.A. 66.180.239.0/24 AS35888 VIGNETTE - VIGNETTE CORPORATION 66.206.32.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.33.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.34.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.35.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.40.0/22 AS174 COGENT Cogent/PSI 66.206.44.0/23 AS174 COGENT Cogent/PSI 66.206.47.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 66.207.32.0/20 AS23011 66.245.176.0/20 AS19318 NJIIX-AS-1 - NEW JERSEY INTERNATIONAL INTERNET EXCHANGE LLC 69.6.80.0/24 AS13442 69.6.81.0/24 AS13442 69.71.192.0/20 AS13818 PHX-INTL-TELEPORT - Phoenix International Teleport 80.88.0.0/21 AS33774 DJAWEB 80.88.8.0/22 AS33774 DJAWEB 80.88.10.0/24 AS33774 DJAWEB 80.88.12.0/24 AS33779 wataniya-telecom-as 100.100.100.0/30 AS38676 AS33005-AS-KR wizsolution co.,Ltd 109.0.0.0/16 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 109.1.0.0/21 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 109.1.24.0/24 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 110.76.156.0/24 AS45062 CNNIC-FKT-AP FEIKE TECH LIMITED 110.76.157.0/24 AS45062 CNNIC-FKT-AP FEIKE TECH LIMITED 121.46.0.0/16 AS4134 CHINANET-BACKBONE No.31,Jin-rong Street 121.50.168.0/21 AS9931 CAT-AP The Communication Authoity of Thailand, CAT 122.128.120.0/22 AS38456 PACTEL-AS-AP Pacific Teleports. 137.0.0.0/13 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 158.222.5.0/24 AS21580 DIRCON - Direct Connect 158.222.70.0/23 AS6137 SISNA - SISNA, Inc. 158.222.72.0/23 AS6137 SISNA - SISNA, Inc. 158.222.224.0/20 AS19864 O1COMM - O1 COMMUNICATIONS 158.222.224.0/22 AS19864 O1COMM - O1 COMMUNICATIONS 158.222.229.0/24 AS19864 O1COMM - O1 COMMUNICATIONS 163.142.0.0/16 AS2500 WIDE-BB WIDE Project 168.253.0.0/16 AS13649 ASN-VINS - ViaWest 168.253.0.0/21 AS13649 ASN-VINS - ViaWest 172.7.0.0/24 AS28175 172.10.1.0/30 AS18305 POSNET POSDATA Co.,Ltd 178.0.0.0/16 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 178.1.0.0/21 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 178.1.24.0/24 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 192.9.0.0/16 AS11479 BRM-SUN-AS - Sun Microsystems, Inc 192.9.200.0/24 AS3602 AS3602-RTI - Rogers Telecom Inc. 192.64.85.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.69.107.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.69.108.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.69.177.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.70.164.0/24 AS25689 NRCNET-AS - National Research Council of Canada 192.96.37.0/24 AS10474 NETACTIVE 192.96.135.0/24 AS2018 TENET-1 192.96.136.0/23 AS2018 TENET-1 192.96.141.0/24 AS2018 TENET-1 192.96.143.0/24 AS2018 TENET-1 192.96.145.0/24 AS2018 TENET-1 192.96.177.0/24 AS6083 POSIX-AFRICA 192.101.45.0/24 AS2905 TICSA-ASN 192.101.46.0/24 AS6503 Avantel, S.A. 192.101.64.0/21 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 192.101.70.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 192.101.71.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 192.101.72.0/24 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 192.101.74.0/24 AS1239 SPRINTLINK - Sprint 192.124.248.0/23 AS680 DFN-IP service G-WiN 192.124.252.0/22 AS680 DFN-IP service G-WiN 192.131.233.0/24 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 192.132.58.0/24 AS20141 QUALITYTECH-SUW-300 - Quality Technology Services, LLC. 192.133.6.0/24 AS10282 ORANGE-BUSINESS-SERVICES-CEEUR Orange Business Services (formerly Equant) AS for CEEUR 192.153.144.0/21 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 192.154.32.0/19 AS81 NCREN - MCNC 192.188.208.0/20 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 193.33.148.0/23 AS30890 EVOLVA Evolva Telecom 196.6.108.0/24 AS5713 SAIX-NET 196.10.119.0/24 AS2018 TENET-1 196.10.122.0/23 AS2018 TENET-1 196.10.251.0/24 AS2018 TENET-1 196.10.252.0/23 AS2018 TENET-1 196.10.254.0/24 AS2018 TENET-1 196.13.101.0/24 AS2018 TENET-1 196.13.102.0/23 AS2018 TENET-1 196.13.104.0/24 AS2018 TENET-1 196.13.121.0/24 AS2018 TENET-1 196.13.125.0/24 AS2018 TENET-1 196.13.126.0/24 AS2018 TENET-1 196.13.169.0/24 AS2018 TENET-1 196.13.174.0/23 AS2018 TENET-1 196.13.176.0/21 AS2018 TENET-1 196.13.192.0/22 AS2018 TENET-1 196.13.196.0/24 AS2018 TENET-1 196.202.224.0/21 AS8818 TELE Greenland Autonomous System 198.1.2.0/24 AS4761 INDOSAT-INP-AP INDOSAT Internet Network Provider 198.23.26.0/24 AS33052 VZUNET - Verizon Data Services LLC 198.54.82.0/24 AS2018 TENET-1 198.54.92.0/24 AS2018 TENET-1 198.54.222.0/24 AS2018 TENET-1 198.73.210.0/24 AS21570 ACI-1 - Accelerated Connections Inc. 198.97.72.0/21 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 198.97.96.0/19 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 198.97.240.0/20 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 198.135.236.0/24 AS4358 XNET - XNet Information Systems, Inc. 198.161.87.0/24 AS6539 GT-BELL - Bell Canada 198.161.92.0/24 AS6539 GT-BELL - Bell Canada 198.167.0.0/16 AS7456 INTERHOP - Interhop Network SERVICES Inc. 198.168.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 198.169.0.0/16 AS803 SASKTEL - Saskatchewan Telecommunications 198.180.198.0/24 AS23715 SEOUL-INTGW-GXS-AP Global Exchange Services 199.5.242.0/24 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 199.10.0.0/16 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.19.0.0/24 AS3848 WORLDLINX-2 - WorldLinx Telecommunications, Inc. 199.114.0.0/21 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.114.128.0/18 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.114.130.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.131.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.132.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.134.0/24 AS3541 ITSDN-U4 - DoD Network Information Center 199.114.136.0/24 AS27044 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.114.138.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.140.0/24 AS3544 ITSDN-U7 - DoD Network Information Center 199.114.142.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.144.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.148.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.150.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.152.0/24 AS27033 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.114.153.0/24 AS27034 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.114.154.0/24 AS1733 CENTAF-SWA - 754th Electronic Systems Group 199.114.156.0/24 AS1733 CENTAF-SWA - 754th Electronic Systems Group 199.114.160.0/24 AS1733 CENTAF-SWA - 754th Electronic Systems Group 199.121.0.0/16 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.123.0.0/18 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.123.16.0/20 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.123.80.0/21 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.189.32.0/19 AS7332 IQUEST-AS - IQuest Internet 199.202.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 199.202.216.0/21 AS577 BACOM - Bell Canada 199.233.92.0/24 AS26896 ITCOMM - IT Communications 199.246.116.0/24 AS813 UUNET-CANADA - MCI Communications Services, Inc. d/b/a Verizon Business 202.6.176.0/20 AS24316 202.58.113.0/24 AS19161 INNOCOM-TELECOM - INNOCOM TELECOM 202.73.144.0/20 AS4788 TMNET-AS-AP TM Net, Internet Service Provider 202.80.192.0/20 AS2706 HKSUPER-HK-AP Pacific Internet (Hong Kong) Limited 202.86.252.0/22 AS4748 RESOLINK-AS-AP Resources Link Network Limited 202.86.252.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.253.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.254.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.255.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.92.48.0/20 AS23704 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.94.70.0/24 AS2764 AAPT AAPT Limited 202.124.195.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.133.70.0/24 AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited 202.133.73.0/24 AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited 202.136.254.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.136.255.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.140.160.0/24 AS4841 202.140.161.0/24 AS4841 202.140.162.0/24 AS4841 202.140.163.0/24 AS4841 202.140.164.0/24 AS4841 202.140.165.0/24 AS4841 202.140.166.0/24 AS4841 202.140.167.0/24 AS4841 202.140.168.0/24 AS4841 202.140.169.0/24 AS4841 202.140.170.0/24 AS4841 202.140.171.0/24 AS4841 202.140.172.0/24 AS4841 202.140.173.0/24 AS4841 202.140.174.0/24 AS4841 202.140.175.0/24 AS4841 202.140.180.0/24 AS7540 HKCIX-AS-AP HongKong Commercial Internet Exchange 202.140.181.0/24 AS7540 HKCIX-AS-AP HongKong Commercial Internet Exchange 202.140.182.0/24 AS7540 HKCIX-AS-AP HongKong Commercial Internet Exchange 202.150.227.0/24 AS17727 NAPINFO-AS-AP PT. NAP Info Lintas Nusa 202.181.32.0/24 AS4645 ASN-HKNET-AP HKNet Co. Ltd 203.12.45.0/24 AS4854 NETSPACE-AS-AP Netspace Online Systems 203.62.0.0/17 AS7575 AARNET-AS-AP Australian Academic and Reasearch Network (AARNet) 203.78.48.0/20 AS9299 IPG-AS-AP Philippine Long Distance Telephone Company 203.89.139.0/24 AS17911 BRAINPK-AS-AP Brain Telecommunication Ltd. 203.112.111.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.113.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.114.0/24 AS4802 ASN-IINET iiNet Limited 203.112.116.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.117.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.118.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.119.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.120.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.121.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.127.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.128.128.0/19 AS4134 CHINANET-BACKBONE No.31,Jin-rong Street 203.128.128.0/24 AS23849 CNNIC-NET263-AP Beijing Capital-online science development Co.,Ltd. 203.152.154.0/23 AS9583 SIFY-AS-IN Sify Limited 203.189.96.0/20 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 204.9.216.0/23 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 204.9.218.0/23 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 204.13.140.0/22 AS7270 NET2PHONE - Net2Phone Corp. 204.13.140.0/24 AS7270 NET2PHONE - Net2Phone Corp. 204.13.141.0/24 AS7270 NET2PHONE - Net2Phone Corp. 204.13.142.0/24 AS7270 NET2PHONE - Net2Phone Corp. 204.13.143.0/24 AS7270 NET2PHONE - Net2Phone Corp. 204.13.184.0/23 AS35967 204.13.186.0/23 AS35967 204.13.186.0/24 AS35967 204.13.187.0/24 AS35967 204.19.14.0/23 AS577 BACOM - Bell Canada 204.89.214.0/24 AS4323 TWTC - tw telecom holdings, inc. 204.138.167.0/24 AS18990 AIRBAND-DALLAS - Airband Communications, Inc 205.150.0.0/15 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 205.189.134.0/24 AS11814 CYBERSURF - Cybersurf Inc. 205.210.145.0/24 AS11814 CYBERSURF - Cybersurf Inc. 206.180.240.0/20 AS12083 KNOLOGY-NET - Knology Holdings 207.174.0.0/16 AS13790 INTERNAP-BLK3 - Internap Network Services Corporation 207.174.131.0/24 AS30715 NETRACK - Netrack, Inc. 207.174.132.0/23 AS30715 NETRACK - Netrack, Inc. 207.174.151.0/24 AS11500 PEAKPEAK - Peak to Peak Internet 207.174.152.0/22 AS30715 NETRACK - Netrack, Inc. 207.174.158.0/24 AS11500 PEAKPEAK - Peak to Peak Internet 207.174.177.0/24 AS11500 PEAKPEAK - Peak to Peak Internet 207.174.178.0/24 AS11500 PEAKPEAK - Peak to Peak Internet 207.174.182.0/24 AS29831 FONENET - FONE NET, LLC 207.174.188.0/22 AS30715 NETRACK - Netrack, Inc. 207.174.192.0/24 AS29831 FONENET - FONE NET, LLC 207.174.200.0/24 AS22658 EARTHNET - Earthnet, Inc. 207.174.248.0/21 AS6653 PRIVATEI - privateI, LLC 207.231.96.0/19 AS11194 NUNETPA - NuNet Inc. 209.54.123.0/24 AS6062 NETPLEX - NETPLEX 209.54.240.0/21 AS10887 BPSI-AS - BPSI Internet Services 209.74.96.0/19 AS10912 INTERNAP-BLK - Internap Network Services Corporation 209.140.90.0/24 AS14461 NTSL - NET SOLUTIONS 209.141.48.0/22 AS14461 NTSL - NET SOLUTIONS 209.145.192.0/18 AS3043 AMPHIB-AS - Amphibian Media Corporation 209.177.93.0/24 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 209.222.5.0/24 AS26699 PSI-CT - Printing For Systems Inc 209.222.6.0/24 AS26699 PSI-CT - Printing For Systems Inc 210.5.128.0/20 AS4837 CHINA169-BACKBONE CNCGROUP China169 Backbone 213.181.70.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.80.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.81.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.82.0/23 AS17175 NSS-UK New Skies Satellites UK AS 213.181.82.0/24 AS17175 NSS-UK New Skies Satellites UK AS 213.181.83.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.84.0/22 AS17175 NSS-UK New Skies Satellites UK AS 213.181.84.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.85.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.86.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.87.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.88.0/21 AS17175 NSS-UK New Skies Satellites UK AS 213.181.88.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.89.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.90.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.91.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.92.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.93.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.94.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.95.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 216.37.114.0/23 AS3549 GBLX Global Crossing Ltd. 216.99.20.0/24 AS3356 LEVEL3 Level 3 Communications 216.172.198.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 216.172.199.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 216.240.240.0/24 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 216.240.241.0/24 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 216.240.242.0/24 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 216.251.207.0/24 AS1239 SPRINTLINK - Sprint 217.78.71.0/24 AS12491 IPPLANET-AS IPPlanet 217.78.72.0/24 AS12491 IPPLANET-AS IPPlanet 217.78.73.0/24 AS12491 IPPLANET-AS IPPlanet Please see http://www.cidr-report.org for the full report ------------------------------------ Copies of this report are mailed to: nanog at merit.edu eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From shivlu.jain at gmail.com Fri May 22 07:20:59 2009 From: shivlu.jain at gmail.com (Shivlu Jain) Date: Fri, 22 May 2009 17:50:59 +0530 Subject: Pseudowire Problem Message-ID: I have seen a weird behaviour in case of pseudo wire termination, it keeps on polling the destination ip even if the interface mapped to pseudo wire is down. Is it the normal behaviour? -- Thanks & Regards shivlu jain http://shivlu.blogspot.com/ From adam at wispring.com Fri May 22 07:58:06 2009 From: adam at wispring.com (Adam Goodman) Date: Fri, 22 May 2009 08:58:06 -0400 Subject: in urgent need of router w/T3 interface Message-ID: <7c2653830905220558w7198022cjc12b14c006ef055e@mail.gmail.com> I have an urgent need for a router to replace the one that crocked last night. If you have a router to sell or lend please contact me off list It could be the following or equivalent of a Cisco 7000 with the following interfaces: 1x T3 clear channel (like a PA-T3) 1x FastEthernet (Alternatively I can also use a wanPMC-C1T3 card with a PCI adapter.) Thank you, -Adam Adam Goodman E: adam at wispring.com C: 801.971.1856 From bkuzma at electronerdz.com Fri May 22 09:22:52 2009 From: bkuzma at electronerdz.com (Bobby Kuzma) Date: Fri, 22 May 2009 10:22:52 -0400 Subject: QWEST outage in the Southeast Message-ID: <7474F92C63F5714BA8DF412B79E0733E790CE558CC@mb1.he.electronerdz.net> Does anybody have any information on this? I've had 4 customers on Qwest for Internet connectivity in Florida drop off the net within a few minutes of each other. Thanks, Bobby Kuzma, CISSP VP, Professional Services ElectroNerdz, Inc. Office: 863-709-0204x1911 Fax: 863-709-0506 From cmadams at hiwaay.net Fri May 22 10:58:18 2009 From: cmadams at hiwaay.net (Chris Adams) Date: Fri, 22 May 2009 10:58:18 -0500 Subject: QWEST outage in the Southeast In-Reply-To: <7474F92C63F5714BA8DF412B79E0733E790CE558CC@mb1.he.electronerdz.net> References: <7474F92C63F5714BA8DF412B79E0733E790CE558CC@mb1.he.electronerdz.net> Message-ID: <20090522155818.GC1190256@hiwaay.net> Once upon a time, Bobby Kuzma said: > Does anybody have any information on this? I've had 4 customers on Qwest for Internet connectivity in Florida drop off the net within a few minutes of each other. I'm have Qwest via Atlanta and I'm not seeing any issues. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From warren at kumari.net Fri May 22 11:57:37 2009 From: warren at kumari.net (Warren Kumari) Date: Fri, 22 May 2009 12:57:37 -0400 Subject: in urgent need of router w/T3 interface In-Reply-To: <7c2653830905220558w7198022cjc12b14c006ef055e@mail.gmail.com> References: <7c2653830905220558w7198022cjc12b14c006ef055e@mail.gmail.com> Message-ID: <586B3506-0626-4E93-BC5D-4C54DC1EB772@kumari.net> I suspect that you might have more luck if you mentioned where you are, how far you would be willing to drive to pick one up and how long you would need to use it for... For example, I could probably loan you an old 7200 that would fit the bill, but I'm in VA which probably wouldn't work out for you... Feel free to mail me privately if you don't have any luck elsewhere and I'll pull it out of storage, make sure it is still a happy camper, etc... W On May 22, 2009, at 8:58 AM, Adam Goodman wrote: > I have an urgent need for a router to replace the one that crocked > last > night. If you have a router to sell or lend please contact me off list > > It could be the following or equivalent of a Cisco 7000 with the > following > interfaces: > 1x T3 clear channel (like a PA-T3) > 1x FastEthernet > > (Alternatively I can also use a wanPMC-C1T3 card with a PCI adapter.) > > Thank you, > -Adam > > Adam Goodman > E: adam at wispring.com > C: 801.971.1856 From glen.kent at gmail.com Fri May 22 12:04:41 2009 From: glen.kent at gmail.com (Glen Kent) Date: Fri, 22 May 2009 22:34:41 +0530 Subject: AH or ESP Message-ID: <92c950310905221004v7e7d14a5v7c143141cd4604fb@mail.gmail.com> Hi, It is well known in the community that AH is NAT unfriendly while ESP cannot be filtered, and most firewalls would not let such packets pass. I am NOT interested in encrypting the data, but i do want origination authentication (Integrity Protection). Do folks in such cases use AH or ESP-NULL, given that both have some issues? Thanks, Glen From morrowc.lists at gmail.com Fri May 22 12:16:04 2009 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Fri, 22 May 2009 13:16:04 -0400 Subject: AH or ESP In-Reply-To: <92c950310905221004v7e7d14a5v7c143141cd4604fb@mail.gmail.com> References: <92c950310905221004v7e7d14a5v7c143141cd4604fb@mail.gmail.com> Message-ID: <75cb24520905221016p18636e18o9eb2834810b792ef@mail.gmail.com> On Fri, May 22, 2009 at 1:04 PM, Glen Kent wrote: > Hi, > > It is well known in the community that AH is NAT unfriendly while ESP cannot > be filtered, and most firewalls would not let such packets pass. I am NOT 'the content of the esp packet can't be filtered in transit' I think you mean... right? > interested in encrypting the data, but i do want origination authentication > (Integrity Protection). Do folks in such cases use AH or ESP-NULL, given > that both have some issues? > > Thanks, > Glen > From cscora at apnic.net Fri May 22 13:11:48 2009 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 23 May 2009 04:11:48 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <200905221811.n4MIBm1M005450@thyme.apnic.net> This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. Daily listings are sent to bgp-stats at lists.apnic.net For historical data, please see http://thyme.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 23 May, 2009 Report Website: http://thyme.apnic.net Detailed Analysis: http://thyme.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 288626 Prefixes after maximum aggregation: 136367 Deaggregation factor: 2.12 Unique aggregates announced to Internet: 141749 Total ASes present in the Internet Routing Table: 31322 Prefixes per ASN: 9.21 Origin-only ASes present in the Internet Routing Table: 27217 Origin ASes announcing only one prefix: 13291 Transit ASes present in the Internet Routing Table: 4105 Transit-only ASes present in the Internet Routing Table: 95 Average AS path length visible in the Internet Routing Table: 3.6 Max AS path length visible: 28 Max AS path prepend of ASN (12026) 22 Prefixes from unregistered ASNs in the Routing Table: 455 Unregistered ASNs in the Routing Table: 148 Number of 32-bit ASNs allocated by the RIRs: 158 Prefixes from 32-bit ASNs in the Routing Table: 33 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 829 Number of addresses announced to Internet: 2044649600 Equivalent to 121 /8s, 222 /16s and 224 /24s Percentage of available address space announced: 55.2 Percentage of allocated address space announced: 63.8 Percentage of available address space allocated: 86.4 Percentage of address space in use by end-sites: 77.1 Total number of prefixes smaller than registry allocations: 142558 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 67841 Total APNIC prefixes after maximum aggregation: 24339 APNIC Deaggregation factor: 2.79 Prefixes being announced from the APNIC address blocks: 67272 Unique aggregates announced from the APNIC address blocks: 30496 APNIC Region origin ASes present in the Internet Routing Table: 3637 APNIC Prefixes per ASN: 18.50 APNIC Region origin ASes announcing only one prefix: 991 APNIC Region transit ASes present in the Internet Routing Table: 561 Average APNIC Region AS path length visible: 3.5 Max APNIC Region AS path length visible: 18 Number of APNIC addresses announced to Internet: 450591072 Equivalent to 26 /8s, 219 /16s and 121 /24s Percentage of available APNIC address space announced: 83.9 APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079 APNIC Address Blocks 58/8, 59/8, 60/8, 61/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 180/8, 183/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 124887 Total ARIN prefixes after maximum aggregation: 65697 ARIN Deaggregation factor: 1.90 Prefixes being announced from the ARIN address blocks: 125608 Unique aggregates announced from the ARIN address blocks: 51567 ARIN Region origin ASes present in the Internet Routing Table: 13007 ARIN Prefixes per ASN: 9.66 ARIN Region origin ASes announcing only one prefix: 4999 ARIN Region transit ASes present in the Internet Routing Table: 1272 Average ARIN Region AS path length visible: 3.3 Max ARIN Region AS path length visible: 24 Number of ARIN addresses announced to Internet: 1008669056 Equivalent to 60 /8s, 31 /16s and 17 /24s Percentage of available ARIN address space announced: 193.9 ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 53248-55295 ARIN Address Blocks 24/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8, 98/8, 99/8, 108/8, 173/8, 174/8, 184/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 65362 Total RIPE prefixes after maximum aggregation: 38650 RIPE Deaggregation factor: 1.69 Prefixes being announced from the RIPE address blocks: 64628 Unique aggregates announced from the RIPE address blocks: 43515 RIPE Region origin ASes present in the Internet Routing Table: 13044 RIPE Prefixes per ASN: 4.95 RIPE Region origin ASes announcing only one prefix: 6845 RIPE Region transit ASes present in the Internet Routing Table: 1978 Average RIPE Region AS path length visible: 4.0 Max RIPE Region AS path length visible: 28 Number of RIPE addresses announced to Internet: 480372384 Equivalent to 28 /8s, 161 /16s and 230 /24s Percentage of available RIPE address space announced: 102.3 RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-52223 RIPE Address Blocks 62/8, 77/8, 78/8, 79/8, 80/8, 81/8, 82/8, 83/8, 84/8, 85/8, 86/8, 87/8, 88/8, 89/8, 90/8, 91/8, 92/8, 93/8, 94/8, 95/8, 109/8, 178/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 23903 Total LACNIC prefixes after maximum aggregation: 5894 LACNIC Deaggregation factor: 4.06 Prefixes being announced from the LACNIC address blocks: 23736 Unique aggregates announced from the LACNIC address blocks: 13078 LACNIC Region origin ASes present in the Internet Routing Table: 1110 LACNIC Prefixes per ASN: 21.38 LACNIC Region origin ASes announcing only one prefix: 363 LACNIC Region transit ASes present in the Internet Routing Table: 185 Average LACNIC Region AS path length visible: 4.1 Max LACNIC Region AS path length visible: 22 Number of LACNIC addresses announced to Internet: 71453056 Equivalent to 4 /8s, 66 /16s and 73 /24s Percentage of available LACNIC address space announced: 71.0 LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247 plus ERX transfers LACNIC Address Blocks 186/8, 187/8, 189/8, 190/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 6214 Total AfriNIC prefixes after maximum aggregation: 1451 AfriNIC Deaggregation factor: 4.28 Prefixes being announced from the AfriNIC address blocks: 6540 Unique aggregates announced from the AfriNIC address blocks: 2459 AfriNIC Region origin ASes present in the Internet Routing Table: 300 AfriNIC Prefixes per ASN: 21.80 AfriNIC Region origin ASes announcing only one prefix: 93 AfriNIC Region transit ASes present in the Internet Routing Table: 62 Average AfriNIC Region AS path length visible: 3.7 Max AfriNIC Region AS path length visible: 15 Number of AfriNIC addresses announced to Internet: 19268608 Equivalent to 1 /8s, 38 /16s and 4 /24s Percentage of available AfriNIC address space announced: 57.4 AfriNIC AS Blocks 36864-37887 & ERX transfers AfriNIC Address Blocks 41/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4766 1704 6930 401 Korea Telecom (KIX) 17488 1578 129 109 Hathway IP Over Cable Interne 4755 1251 466 127 TATA Communications formerly 9583 1074 86 539 Sify Limited 4134 890 16789 375 CHINANET-BACKBONE 23577 783 34 665 Korea Telecom (ATM-MPLS) 7545 777 198 102 TPG Internet Pty Ltd 18101 752 217 32 Reliance Infocom Ltd Internet 24560 693 230 175 Bharti Airtel Ltd. 9829 664 561 15 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 4296 3647 324 bellsouth.net, inc. 209 2540 4133 604 Qwest 4323 1850 1035 374 Time Warner Telecom 1785 1767 717 139 PaeTec Communications, Inc. 20115 1627 1443 719 Charter Communications 7018 1502 5903 1035 AT&T WorldNet Services 6478 1412 313 397 AT&T Worldnet Services 2386 1264 682 918 AT&T Data Communications Serv 3356 1221 10981 458 Level 3 Communications, LLC 11492 1102 193 12 Cable One Complete listing at http://thyme.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 30890 542 88 200 Evolva Telecom 3292 456 1893 394 TDC Tele Danmark 12479 447 578 6 Uni2 Autonomous System 702 430 1864 344 UUNET - Commercial IP service 8866 385 110 26 Bulgarian Telecommunication C 3320 344 7066 295 Deutsche Telekom AG 3215 343 3041 108 France Telecom Transpac 3301 340 1668 304 TeliaNet Sweden 35805 339 24 4 United Telecom of Georgia 29049 316 26 3 AzerSat LLC. Complete listing at http://thyme.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 8151 1446 2862 235 UniNet S.A. de C.V. 10620 914 208 105 TVCABLE BOGOTA 22047 610 302 14 VTR PUNTO NET S.A. 7303 531 275 77 Telecom Argentina Stet-France 11830 486 292 54 Instituto Costarricense de El 28573 480 562 35 NET Servicos de Comunicao S.A 6471 443 96 32 ENTEL CHILE S.A. 11172 441 102 70 Servicios Alestra S.A de C.V 7738 404 794 28 Telecomunicacoes da Bahia S.A 3816 352 164 75 Empresa Nacional de Telecomun Complete listing at http://thyme.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 8452 1205 188 7 TEDATA 24863 869 80 39 LINKdotNET AS number 20858 309 34 5 EgyNet 3741 278 860 238 The Internet Solution 2018 244 215 143 Tertiary Education Network 6713 160 151 12 Itissalat Al-MAGHRIB 33783 152 10 8 EEPAD TISP TELECOM & INTERNET 29571 139 15 8 Ci Telecom Autonomous system 5536 123 8 9 Internet Egypt Network 33776 116 6 7 Starcomms Nigeria Limited Complete listing at http://thyme.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 4296 3647 324 bellsouth.net, inc. 209 2540 4133 604 Qwest 4323 1850 1035 374 Time Warner Telecom 1785 1767 717 139 PaeTec Communications, Inc. 4766 1704 6930 401 Korea Telecom (KIX) 20115 1627 1443 719 Charter Communications 17488 1578 129 109 Hathway IP Over Cable Interne 7018 1502 5903 1035 AT&T WorldNet Services 8151 1446 2862 235 UniNet S.A. de C.V. 6478 1412 313 397 AT&T Worldnet Services Complete listing at http://thyme.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 209 2540 1936 Qwest 1785 1767 1628 PaeTec Communications, Inc. 4323 1850 1476 Time Warner Telecom 17488 1578 1469 Hathway IP Over Cable Interne 4766 1704 1303 Korea Telecom (KIX) 8151 1446 1211 UniNet S.A. de C.V. 8452 1205 1198 TEDATA 4755 1251 1124 TATA Communications formerly 11492 1102 1090 Cable One 18566 1062 1052 Covad Communications Complete listing at http://thyme.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 16927 UNALLOCATED 12.0.252.0/23 7018 AT&T WorldNet Servic 15132 UNALLOCATED 12.9.150.0/24 7018 AT&T WorldNet Servic 32567 UNALLOCATED 12.14.170.0/24 7018 AT&T WorldNet Servic 13746 UNALLOCATED 12.24.56.0/24 7018 AT&T WorldNet Servic 32567 UNALLOCATED 12.25.107.0/24 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.152.0/24 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.154.0/23 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.159.0/24 7018 AT&T WorldNet Servic 32326 UNALLOCATED 12.40.49.0/24 7018 AT&T WorldNet Servic 25639 UNALLOCATED 12.41.169.0/24 7018 AT&T WorldNet Servic Complete listing at http://thyme.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 41.223.112.0/22 5713 Telkom SA Ltd 41.223.176.0/22 36981 >>UNKNOWN<< 41.223.188.0/24 22351 Intelsat 41.223.189.0/24 26452 Local Communications Networks 62.61.220.0/24 24974 Tachyon Europe BV - Wireless 62.61.221.0/24 24974 Tachyon Europe BV - Wireless 63.140.213.0/24 22555 Universal Talkware Corporatio 63.143.251.0/24 22555 Universal Talkware Corporatio 64.31.32.0/19 11955 ServiceCo LLC - Road Runner 64.31.59.0/24 7017 ServiceCo LLC - Road Runner Complete listing at http://thyme.apnic.net/current/data-add-IANA Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:19 /9:10 /10:20 /11:58 /12:166 /13:340 /14:599 /15:1149 /16:10475 /17:4753 /18:8181 /19:17170 /20:20424 /21:20327 /22:25982 /23:25684 /24:150719 /25:846 /26:994 /27:545 /28:144 /29:8 /30:5 /31:0 /32:8 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 6389 2801 4296 bellsouth.net, inc. 4766 1397 1704 Korea Telecom (KIX) 17488 1299 1578 Hathway IP Over Cable Interne 209 1283 2540 Qwest 8452 1174 1205 TEDATA 1785 1170 1767 PaeTec Communications, Inc. 18566 1043 1062 Covad Communications 11492 1037 1102 Cable One 2386 974 1264 AT&T Data Communications Serv 4323 954 1850 Time Warner Telecom Complete listing at http://thyme.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 4:13 8:199 12:2229 13:10 15:19 16:3 17:4 20:35 24:1075 32:52 34:2 38:557 40:97 41:1984 43:1 44:2 47:22 52:4 55:2 56:3 57:25 58:588 59:642 60:456 61:1097 62:1094 63:2077 64:3693 65:2385 66:3602 67:1607 68:790 69:2618 70:526 71:146 72:1663 73:2 74:1533 75:171 76:308 77:848 78:563 79:338 80:958 81:816 82:551 83:428 84:617 85:1027 86:407 87:656 88:355 89:1440 90:62 91:2230 92:323 93:1025 94:1208 95:1166 96:129 97:209 98:225 99:19 109:1 110:124 112:125 113:104 114:266 115:288 116:1157 117:516 118:291 119:699 120:144 121:732 122:1024 123:675 124:969 125:1324 128:221 129:235 130:125 131:412 132:75 133:9 134:187 135:39 136:224 137:155 138:160 139:78 140:443 141:109 142:380 143:331 144:364 145:47 146:377 147:153 148:517 149:238 150:165 151:200 152:147 153:137 154:2 155:275 156:169 157:298 158:116 159:312 160:282 161:143 162:268 163:152 164:480 165:503 166:275 167:362 168:675 169:167 170:480 171:40 172:10 173:283 174:212 178:1 180:1 183:1 186:15 187:94 188:17 189:370 190:2662 192:5817 193:4223 194:3299 195:2718 196:1081 198:3634 199:3365 200:5307 201:1296 202:7869 203:8183 204:3819 205:2149 206:2453 207:2809 208:3914 209:3424 210:2669 211:1113 212:1522 213:1685 214:77 215:30 216:4655 217:1258 218:368 219:435 220:1216 221:470 222:293 End of report From adam at wispring.com Fri May 22 14:23:31 2009 From: adam at wispring.com (Adam Goodman) Date: Fri, 22 May 2009 15:23:31 -0400 Subject: in urgent need of router w/T3 interface In-Reply-To: <586B3506-0626-4E93-BC5D-4C54DC1EB772@kumari.net> References: <7c2653830905220558w7198022cjc12b14c006ef055e@mail.gmail.com> <586B3506-0626-4E93-BC5D-4C54DC1EB772@kumari.net> Message-ID: <7c2653830905221223rbc9f102qfc845456a373aed6@mail.gmail.com> I must have forgotten to not my location. I am in Western Massachusetts. On Fri, May 22, 2009 at 12:57 PM, Warren Kumari wrote: > I suspect that you might have more luck if you mentioned where you are, how > far you would be willing to drive to pick one up and how long you would need > to use it for... > > For example, I could probably loan you an old 7200 that would fit the bill, > but I'm in VA which probably wouldn't work out for you... > > Feel free to mail me privately if you don't have any luck elsewhere and > I'll pull it out of storage, make sure it is still a happy camper, etc... > > W > > On May 22, 2009, at 8:58 AM, Adam Goodman wrote: > > I have an urgent need for a router to replace the one that crocked last >> night. If you have a router to sell or lend please contact me off list >> >> It could be the following or equivalent of a Cisco 7000 with the >> following >> interfaces: >> 1x T3 clear channel (like a PA-T3) >> 1x FastEthernet >> >> (Alternatively I can also use a wanPMC-C1T3 card with a PCI adapter.) >> >> Thank you, >> -Adam >> >> Adam Goodman >> E: adam at wispring.com >> C: 801.971.1856 >> > > From martin at theicelandguy.com Fri May 22 14:41:17 2009 From: martin at theicelandguy.com (Martin Hannigan) Date: Fri, 22 May 2009 15:41:17 -0400 Subject: Global pricing disparity -> Somali piracy Message-ID: FYI, I thought this was interesting reading for the workaholics among us as we head into the holiday weekend in the United States. I'd also like to follow it with an (hopefully) interesting question. http://www.circleid.com/posts/20090520_bandwidth_buyers_price_differences_global_market/ The costs of wholesale bandwidth are significantly disparate by region, duh, but this article demonstrates how disparate. I was also recently discussing why some of these costs are disparate with a colleague in the African region and he had an interesting question that I thought would be operational enough to ask here. Are any African or Middle East costs being influenced by the Somali piracy problem? Is the deployment of Eassy being impacted by the piracy issue? The cable ships are sitting ducks for pirate attacks during lay and repair operations. There's one cable lay operation being guarded by the French Navy, likely an Alcatel operation. I'm interested to hear from anyone with direct knowledge (offline, I'll summarize back if it's worth it, maybe even a lightning talk for Philly?) on the impact. I suspect that it's possible that it could add cost to maintenance agreements with any security caveats, but since most cable operations taking place now were negotiated before the problem heightened, perhaps not. I'd like to know if you know. Best, Martin Hannigan -- Martin Hannigan martin at theicelandguy.com p: +16178216079 Power, Network, and Costs Consulting for Iceland Datacenters and Occupants From jeffrey.lyon at blacklotus.net Fri May 22 15:00:20 2009 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Fri, 22 May 2009 16:00:20 -0400 Subject: Global pricing disparity -> Somali piracy In-Reply-To: References: Message-ID: <16720fe00905221300k476870aerb995371e2a194a7e@mail.gmail.com> I can only imagine that costs are indeed affected. Companies requesting combatant ship escorts are required to reimburse the escorting nation. -- Jeffrey Lyon, Leadership Team jeffrey.lyon at blacklotus.net | http://www.blacklotus.net Black Lotus Communications of The IRC Company, Inc. Look for us at HostingCon 2009 in Washington, DC on August 10th - 12th at Booth #401. On Fri, May 22, 2009 at 3:41 PM, Martin Hannigan wrote: > FYI, I thought this was interesting reading for the workaholics among us as > we head into the holiday weekend in the United States. I'd also like to > follow it with an (hopefully) interesting question. > > > http://www.circleid.com/posts/20090520_bandwidth_buyers_price_differences_global_market/ > > The costs of wholesale bandwidth are significantly disparate by region, duh, > but this article demonstrates how disparate. > > I was also recently discussing why some of these costs are disparate with a > colleague in the African region and he had an interesting question that I > thought would be operational enough to ask here. > > Are any African or Middle East costs being influenced by the Somali piracy > problem? Is the deployment of Eassy being impacted by the piracy issue? The > cable ships are sitting ducks for pirate attacks during lay and repair > operations. There's one cable lay operation being guarded by the French > Navy, likely an Alcatel operation. > > I'm interested to hear from anyone with direct knowledge (offline, I'll > summarize back if it's worth it, maybe even a lightning talk for Philly?) on > the impact. I suspect that it's possible that it could add cost to > maintenance agreements with any security caveats, but since most cable > operations taking place now were negotiated before the problem heightened, > perhaps not. I'd like to know if you know. > > Best, > > Martin Hannigan > > > -- > Martin Hannigan ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? martin at theicelandguy.com > p: +16178216079 > Power, Network, and Costs Consulting for Iceland Datacenters and Occupants > From danny at tcb.net Fri May 22 15:37:26 2009 From: danny at tcb.net (Danny McPherson) Date: Fri, 22 May 2009 14:37:26 -0600 Subject: Pseudowire Problem In-Reply-To: References: Message-ID: <34DF2E58-5761-4E68-AFE6-912215BE4550@tcb.net> On May 22, 2009, at 6:20 AM, Shivlu Jain wrote: > I have seen a weird behaviour in case of pseudo wire termination, it > keeps > on polling the destination ip even if the interface mapped to pseudo > wire is > down. > Is it the normal behaviour? Shivula, You probably need to address your query to either your vendor-specific mailing list, e.g.: Or if you believe it's some protocol or specification issue, the IETF's PWE3 WG mailing list: HTH, -danny From steve at ibctech.ca Fri May 22 17:45:20 2009 From: steve at ibctech.ca (Steve Bertrand) Date: Fri, 22 May 2009 18:45:20 -0400 Subject: Multi-homed clients and BGP timers Message-ID: <4A172B00.9010106@ibctech.ca> Hi all, I've got numerous single-site 100Mb fibre clients who have backup SDSL links to my PoP. The two services terminate on separate distribution/access routers. The CPE that peers to my fibre router sets a community, and my end sets the pref to 150 based on it. The CPE also sets a higher pref for prefixes from the fibre router. The SDSL router to CPE leaves the default preference in place. Both of my PE gear sends default-originate to the CPE. There is (generally) no traffic that should ever be on the SDSL link while the fibre is up. Both of the PE routers then advertise the learnt client route up into the core: *>i208.70.107.128/28 172.16.104.22 0 150 0 64762 i * i 172.16.104.23 0 100 0 64762 i My problem is the noticeable delay for switchover when the fibre happens to go down (God forbid). I would like to know if BGP timer adjustment is the way to adjust this, or if there is a better/different way. It's fair to say that the fibre doesn't 'flap'. Based on operational experience, if there is a problem with the fibre network, it's down for the count. While I'm at it, I've got another couple of questions: - whatever technique you might recommend to reduce the convergence throughout the network, can the same principles be applied to iBGP as well? - if I need to down core2, what is the quickest and easiest way to ensure that all gear connected to the cores will *quickly* switch to preferring core1? Steve -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3233 bytes Desc: S/MIME Cryptographic Signature URL: From zaid at zaidali.com Fri May 22 17:58:40 2009 From: zaid at zaidali.com (Zaid Ali) Date: Fri, 22 May 2009 15:58:40 -0700 (PDT) Subject: Multi-homed clients and BGP timers In-Reply-To: <4A172B00.9010106@ibctech.ca> Message-ID: <2812431.3281243033120323.JavaMail.zaid@turing-2.local> >From experience I found that you need to keep all the timers in sync with all your peers. Something like this for every peer in your bgp config. neighbor xxx.xx.xx.x timers 30 60 Make sure that this is communicated to your peer as well so that their timer setting are reflected the same. Zaid ----- Original Message ----- From: "Steve Bertrand" To: "nanog list" Sent: Friday, May 22, 2009 3:45:20 PM GMT -08:00 US/Canada Pacific Subject: Multi-homed clients and BGP timers Hi all, I've got numerous single-site 100Mb fibre clients who have backup SDSL links to my PoP. The two services terminate on separate distribution/access routers. The CPE that peers to my fibre router sets a community, and my end sets the pref to 150 based on it. The CPE also sets a higher pref for prefixes from the fibre router. The SDSL router to CPE leaves the default preference in place. Both of my PE gear sends default-originate to the CPE. There is (generally) no traffic that should ever be on the SDSL link while the fibre is up. Both of the PE routers then advertise the learnt client route up into the core: *>i208.70.107.128/28 172.16.104.22 0 150 0 64762 i * i 172.16.104.23 0 100 0 64762 i My problem is the noticeable delay for switchover when the fibre happens to go down (God forbid). I would like to know if BGP timer adjustment is the way to adjust this, or if there is a better/different way. It's fair to say that the fibre doesn't 'flap'. Based on operational experience, if there is a problem with the fibre network, it's down for the count. While I'm at it, I've got another couple of questions: - whatever technique you might recommend to reduce the convergence throughout the network, can the same principles be applied to iBGP as well? - if I need to down core2, what is the quickest and easiest way to ensure that all gear connected to the cores will *quickly* switch to preferring core1? Steve From steve at ibctech.ca Fri May 22 18:15:00 2009 From: steve at ibctech.ca (Steve Bertrand) Date: Fri, 22 May 2009 19:15:00 -0400 Subject: Multi-homed clients and BGP timers In-Reply-To: <2812431.3281243033120323.JavaMail.zaid@turing-2.local> References: <2812431.3281243033120323.JavaMail.zaid@turing-2.local> Message-ID: <4A1731F4.3080305@ibctech.ca> Zaid Ali wrote: > From experience I found that you need to keep all the timers in sync with all your peers. Something like this for every peer in your bgp config. > > neighbor xxx.xx.xx.x timers 30 60 > > Make sure that this is communicated to your peer as well so that their timer setting are reflected the same. Thankfully at this point, we manage all CPE of any clients who peer with us, and so far, the clients advertise our own space back to us. I'll go back to looking at adequate timer settings for my environment. All it takes is a quick phone call to the client IT people to inform them that a change will be made, and when they prefer I do it (in the event something goes south). Also thankfully, I'm within a quick walk/drive to these sites, which I've found to be a comfort during the last year while I've walked the BGP learning curve (one of my clients in particular leaves me with quite a few resources (fibre connections, hardware) for me to *test* with between site-and-PoP ;) Cheers, and thanks! Steve -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3233 bytes Desc: S/MIME Cryptographic Signature URL: From glen.kent at gmail.com Fri May 22 18:36:43 2009 From: glen.kent at gmail.com (Glen Kent) Date: Sat, 23 May 2009 05:06:43 +0530 Subject: AH or ESP In-Reply-To: <75cb24520905221016p18636e18o9eb2834810b792ef@mail.gmail.com> References: <92c950310905221004v7e7d14a5v7c143141cd4604fb@mail.gmail.com> <75cb24520905221016p18636e18o9eb2834810b792ef@mail.gmail.com> Message-ID: <92c950310905221636w63e7484dy55459c07c983c910@mail.gmail.com> Yes, thats what i had meant ! On Fri, May 22, 2009 at 10:46 PM, Christopher Morrow < morrowc.lists at gmail.com> wrote: > On Fri, May 22, 2009 at 1:04 PM, Glen Kent wrote: > > Hi, > > > > It is well known in the community that AH is NAT unfriendly while ESP > cannot > > be filtered, and most firewalls would not let such packets pass. I am NOT > > 'the content of the esp packet can't be filtered in transit' I think > you mean... right? > > > interested in encrypting the data, but i do want origination > authentication > > (Integrity Protection). Do folks in such cases use AH or ESP-NULL, given > > that both have some issues? > > > > Thanks, > > Glen > > > From danny at tcb.net Fri May 22 18:37:39 2009 From: danny at tcb.net (Danny McPherson) Date: Fri, 22 May 2009 17:37:39 -0600 Subject: Multi-homed clients and BGP timers In-Reply-To: <4A1731F4.3080305@ibctech.ca> References: <2812431.3281243033120323.JavaMail.zaid@turing-2.local> <4A1731F4.3080305@ibctech.ca> Message-ID: On May 22, 2009, at 5:15 PM, Steve Bertrand wrote: >> >> neighbor xxx.xx.xx.x timers 30 60 >> >> Make sure that this is communicated to your peer as well so that >> their timer setting are reflected the same. > > Thankfully at this point, we manage all CPE of any clients who peer > with > us, and so far, the clients advertise our own space back to us. I'll > go > back to looking at adequate timer settings for my environment. > > All it takes is a quick phone call to the client IT people to inform > them that a change will be made, and when they prefer I do it (in the > event something goes south). Also thankfully, I'm within a quick > walk/drive to these sites, which I've found to be a comfort during the > last year while I've walked the BGP learning curve (one of my > clients in > particular leaves me with quite a few resources (fibre connections, > hardware) for me to *test* with between site-and-PoP ;) Of course, given that the lowest BGP holdtime is selected when the session is being established, you don't really need to change the CPE side, all you need to do is make the change on the network side and reset the session. And it's typically a good idea to set the keepalive interval to a higher frequency when employing lower holdtimes such that transient keepalive loss (or updates, which act as implicit keepalives) don't cause any unnecessary instability. Also, there are usually global values you can set for all BGP neighbors in most implementations, as well as the per-peer configuration illustrated above. The former requires less configuration bits if you're comfortable with setting the values globally. If you want to converge a little fast than BGP holdtimes here and the fiber link is directly between the routers, you might look at something akin to Cisco's "bgp fast-external-fallover", which immediately resets the session if the link layer is reset or lost. > While I'm at it, I've got another couple of questions: > > - whatever technique you might recommend to reduce the convergence > throughout the network, can the same principles be applied to iBGP > as well? Depending on your definition of convergence, yes. If you're referring to update advertisements as opposed to session or router failures, though, MRAI tweaks and/or less iBGP hierarchy might be the way to go. Then again, there are lots of side effects with these as well.. > - if I need to down core2, what is the quickest and easiest way to > ensure that all gear connected to the cores will *quickly* switch to > preferring core1? Use your IGP mechanisms akin to IS-IS overload bit or OSPF stub router (max metric) advertisement. -danny From deepak at ai.net Fri May 22 19:10:36 2009 From: deepak at ai.net (Deepak Jain) Date: Fri, 22 May 2009 20:10:36 -0400 Subject: Multi-homed clients and BGP timers In-Reply-To: References: <2812431.3281243033120323.JavaMail.zaid@turing-2.local> <4A1731F4.3080305@ibctech.ca> Message-ID: > If you want to converge a little fast than BGP holdtimes here > and the fiber link is directly between the routers, you might > look at something akin to Cisco's "bgp fast-external-fallover", > which immediately resets the session if the link layer is > reset or lost. > Also things to consider: BFD for BGP and UDLD will help identify link failures faster. (If all of your equipment supports it, YMMV, etc). Deepak From steve at ibctech.ca Fri May 22 19:26:09 2009 From: steve at ibctech.ca (Steve Bertrand) Date: Fri, 22 May 2009 20:26:09 -0400 Subject: Multi-homed clients and BGP timers In-Reply-To: References: <2812431.3281243033120323.JavaMail.zaid@turing-2.local> <4A1731F4.3080305@ibctech.ca> Message-ID: <4A1742A1.4080509@ibctech.ca> Danny McPherson wrote: > > On May 22, 2009, at 5:15 PM, Steve Bertrand wrote: >>> >>> neighbor xxx.xx.xx.x timers 30 60 >>> >>> Make sure that this is communicated to your peer as well so that >>> their timer setting are reflected the same. >> >> Thankfully at this point, we manage all CPE of any clients who peer with >> us, and so far, the clients advertise our own space back to us. I'll go >> back to looking at adequate timer settings for my environment. > Of course, given that the lowest BGP holdtime is selected > when the session is being established, you don't really need > to change the CPE side, all you need to do is make the > change on the network side and reset the session. And it's > typically a good idea to set the keepalive interval to a > higher frequency when employing lower holdtimes such that > transient keepalive loss (or updates, which act as implicit > keepalives) don't cause any unnecessary instability. > > Also, there are usually global values you can set for all > BGP neighbors in most implementations, as well as the per-peer > configuration illustrated above. The former requires less > configuration bits if you're comfortable with setting the > values globally. I remember reading that the lowest value is implemented, but thanks for the reminder. In this case, since I *can* change it at the CPE, I may as well. That way, in the event that I move on (or get hit by a bus) and the next person moves the connection to a new router, the CPE will win. Also... the global setting is a great idea. Unfortunately, connected to this router that handles these fibre connections are a couple of local peers that I don't want to change the 'defaults' for. I can't remember if timers can be set at a peer-group level, so I'll look that up and go from there. That will be my best option given what is connected to this router. > If you want to converge a little fast than BGP holdtimes here > and the fiber link is directly between the routers, you might > look at something akin to Cisco's "bgp fast-external-fallover", > which immediately resets the session if the link layer is > reset or lost. Well, unfortunately, the local PUC owns the fibre, and they have a switch aggregating all of their fibre in a star pattern. They then trunk the VLANs to me across two redundant pair. I'm in the process of persuading them to allow me to put my own gear in their location so I can manage it myself (no risk of port-monitor, no risk of their ops fscking up my clients etc). This way, they connect from their client-facing converter into whatever port in my switch I tell them. With that said, and as I said before, L3 and below rarely fails. I'll look into fast-external-fallover. It may be worth it here. > >> While I'm at it, I've got another couple of questions: >> >> - whatever technique you might recommend to reduce the convergence >> throughout the network, can the same principles be applied to iBGP as >> well? > > Depending on your definition of convergence, yes. If you're > referring to update advertisements as opposed to session or > router failures, though, MRAI tweaks and/or less iBGP hierarchy > might be the way to go. Then again, there are lots of side > effects with these as well.. I suppose I might not completely understand what I am asking. - pe1 has iBGP peering with p1 and p2, and pe1 has p2 as it's next hop in FIB for prefix X (both cores have prefix X in routing table through a different edge device) - p2 suddenly falls off the network Perhaps it's late enough on Friday night after a long day for me to not be thinking correctly, but I can't figure out exactly what the delay time would be for a client connected to pe1 to re-reach prefix X if p2 goes down hard. >> - if I need to down core2, what is the quickest and easiest way to >> ensure that all gear connected to the cores will *quickly* switch to >> preferring core1? > > Use your IGP mechanisms akin to IS-IS overload bit or OSPF > stub router (max metric) advertisement. I will certainly look into your suggestions. I have only a backbone area in OSPF carrying loopbacks and infrastructure, but don't quite understand the entire OSPF protocol yet. Thanks Danny, Steve -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3233 bytes Desc: S/MIME Cryptographic Signature URL: From jbates at brightok.net Fri May 22 19:59:56 2009 From: jbates at brightok.net (Jack Bates) Date: Fri, 22 May 2009 19:59:56 -0500 Subject: Multi-homed clients and BGP timers In-Reply-To: <4A1742A1.4080509@ibctech.ca> References: <2812431.3281243033120323.JavaMail.zaid@turing-2.local> <4A1731F4.3080305@ibctech.ca> <4A1742A1.4080509@ibctech.ca> Message-ID: <4A174A8C.8090608@brightok.net> Steve Bertrand wrote: > Well, unfortunately, the local PUC owns the fibre, and they have a > switch aggregating all of their fibre in a star pattern. They then trunk > the VLANs to me across two redundant pair. I'm in the process of > persuading them to allow me to put my own gear in their location so I > can manage it myself (no risk of port-monitor, no risk of their ops > fscking up my clients etc). This way, they connect from their > client-facing converter into whatever port in my switch I tell them. > Correct me if I'm wrong, but wasn't this exactly the type of situation that BFD was designed to detect and help with? Jack From steve at ibctech.ca Fri May 22 20:09:44 2009 From: steve at ibctech.ca (Steve Bertrand) Date: Fri, 22 May 2009 21:09:44 -0400 Subject: Multi-homed clients and BGP timers In-Reply-To: <4A174A8C.8090608@brightok.net> References: <2812431.3281243033120323.JavaMail.zaid@turing-2.local> <4A1731F4.3080305@ibctech.ca> <4A1742A1.4080509@ibctech.ca> <4A174A8C.8090608@brightok.net> Message-ID: <4A174CD8.90602@ibctech.ca> Jack Bates wrote: > Steve Bertrand wrote: >> Well, unfortunately, the local PUC owns the fibre, and they have a >> switch aggregating all of their fibre in a star pattern. They then trunk >> the VLANs to me across two redundant pair. I'm in the process of >> persuading them to allow me to put my own gear in their location so I >> can manage it myself (no risk of port-monitor, no risk of their ops >> fscking up my clients etc). This way, they connect from their >> client-facing converter into whatever port in my switch I tell them. >> > > Correct me if I'm wrong, but wasn't this exactly the type of situation > that BFD was designed to detect and help with? I don't know, but I'm printing it[1] anyway to take home and read. It's been mentioned a few times, and clearly worth learning about. Thanks, Steve [1] http://bgp.potaroo.net/ietf/all-ids/draft-ietf-bfd-v4v6-1hop-09.txt -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3233 bytes Desc: S/MIME Cryptographic Signature URL: From ip at ioshints.info Sat May 23 07:39:53 2009 From: ip at ioshints.info (Ivan Pepelnjak) Date: Sat, 23 May 2009 14:39:53 +0200 Subject: Multi-homed clients and BGP timers In-Reply-To: <4A174CD8.90602@ibctech.ca> References: <2812431.3281243033120323.JavaMail.zaid@turing-2.local> <4A1731F4.3080305@ibctech.ca> <4A1742A1.4080509@ibctech.ca> <4A174A8C.8090608@brightok.net> <4A174CD8.90602@ibctech.ca> Message-ID: <006d01c9dba3$936b3a40$0a00000a@nil.si> For BFD to work, you need: * ISR + 12.4(15)T (or later) * 7200 with 12.4T or 12.2SRx * 7600/6500/GSR + 12.2SRB (or later) * ASR A complete list is at the bottom of this document: http://www.cisco.com/en/US/docs/ios/12_0s/feature/guide/fs_bfd.html You'll find some more BFD details and usage guidelines here: http://www.nil.com/ipcorner/bfd/ Best regards Ivan http://www.ioshints.info/about http://blog.ioshints.info/ > > Correct me if I'm wrong, but wasn't this exactly the type > of situation > > that BFD was designed to detect and help with? > > I don't know, but I'm printing it[1] anyway to take home and > read. It's been mentioned a few times, and clearly worth > learning about. > > Thanks, > > Steve > > [1] > http://bgp.potaroo.net/ietf/all-ids/draft-ietf-bfd-v4v6-1hop-09.txt > From ivan.pepelnjak at zaplana.net Sat May 23 07:46:51 2009 From: ivan.pepelnjak at zaplana.net (Ivan Pepelnjak) Date: Sat, 23 May 2009 14:46:51 +0200 Subject: Multi-homed clients and BGP timers In-Reply-To: References: <2812431.3281243033120323.JavaMail.zaid@turing-2.local><4A1731F4.3080305@ibctech.ca> Message-ID: <008c01c9dba4$8c35def0$0a00000a@nil.si> > If you want to converge a little fast than BGP holdtimes here > and the fiber link is directly between the routers, you might > look at something akin to Cisco's "bgp > fast-external-fallover", which immediately resets the session > if the link layer is reset or lost. For fast external fallover, your physical interface has to go down. Inside your network you could use BGP fast fallover (which drops BGP session after the IGP route to the neighbor is lost), details are here: http://www.nil.com/ipcorner/DesigningBGPNetworks/ Fast fallover with EBGP multihop is described here: http://wiki.nil.com/EBGP_load_balancing_with_EBGP_session_between_loopback_i nterfaces Ivan http://www.ioshints.info/about http://blog.ioshints.info/ From iljitsch at muada.com Sat May 23 07:54:49 2009 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Sat, 23 May 2009 14:54:49 +0200 Subject: Multi-homed clients and BGP timers In-Reply-To: <2812431.3281243033120323.JavaMail.zaid@turing-2.local> References: <2812431.3281243033120323.JavaMail.zaid@turing-2.local> Message-ID: <31E19C60-CD1E-4023-ACC0-0748E1ECE5D5@muada.com> On 23 mei 2009, at 0:58, Zaid Ali wrote: >> From experience I found that you need to keep all the timers in >> sync with all your peers. Something like this for every peer in >> your bgp config. > neighbor xxx.xx.xx.x timers 30 60 30 60 isn't a good choice because that means that after 30.1 seconds a keepalive comes in and then after 60.0 seconds the session will expire while the second one would be there in 60.1 seconds. The other side will typically use hold timer / 3 for their keepalive interval. If you set it to something not divisible by 3 then you get all 3 of those within the hold timer. I often recommended 5 16 in the past but that's a bit on the short side, some less robust BGP implementations work single threaded and may not be able to send keepalives every 15 seconds when they're very busy. The minimum possible hold time is 3. If you only change the setting at your end you can change it to something higher when bad stuff happens, if the other end also sets it then you'll have to change it at both ends as the hold time is negotiated and the lowest is used. If you really want fast failover terminate the fiber in the BGP router and make sure fast-external-failover is on (I think it's the default). For manual failover, simply shut down the BGP sessions on the router that you don't want to handle traffic at that time. If you have peergroups you can do "neighbor peergroup shutdown" for the fastest results. Shutting down interfaces is not such a good idea, then the routing protocols have to time out. > > Make sure that this is communicated to your peer as well so that > their timer setting are reflected the same. > > Zaid > ----- Original Message ----- > From: "Steve Bertrand" > To: "nanog list" > Sent: Friday, May 22, 2009 3:45:20 PM GMT -08:00 US/Canada Pacific > Subject: Multi-homed clients and BGP timers > > Hi all, > > I've got numerous single-site 100Mb fibre clients who have backup SDSL > links to my PoP. The two services terminate on separate > distribution/access routers. > > The CPE that peers to my fibre router sets a community, and my end > sets > the pref to 150 based on it. The CPE also sets a higher pref for > prefixes from the fibre router. The SDSL router to CPE leaves the > default preference in place. Both of my PE gear sends default- > originate > to the CPE. There is (generally) no traffic that should ever be on the > SDSL link while the fibre is up. > > Both of the PE routers then advertise the learnt client route up into > the core: > > *>i208.70.107.128/28 > 172.16.104.22 0 150 0 64762 i > * i 172.16.104.23 0 100 0 64762 i > > My problem is the noticeable delay for switchover when the fibre > happens > to go down (God forbid). > > I would like to know if BGP timer adjustment is the way to adjust > this, > or if there is a better/different way. It's fair to say that the fibre > doesn't 'flap'. Based on operational experience, if there is a problem > with the fibre network, it's down for the count. > > While I'm at it, I've got another couple of questions: > > - whatever technique you might recommend to reduce the convergence > throughout the network, can the same principles be applied to iBGP > as well? > > - if I need to down core2, what is the quickest and easiest way to > ensure that all gear connected to the cores will *quickly* switch to > preferring core1? > > Steve > From ken.gilmour at gmail.com Sat May 23 17:23:08 2009 From: ken.gilmour at gmail.com (Ken Gilmour) Date: Sat, 23 May 2009 16:23:08 -0600 Subject: Global Crossing Contact Message-ID: <5b6f80200905231523l52bde4f3g4fcee1787b800db3@mail.gmail.com> Hi There, I have been trying to get in touch with someone at AS3549 for about an hour but I can't seem to get through using normal methods (e.g. calling numbers on the site, email to noc at globalcrossing.com doesn't work, etc). Can anyone who manages this AS please contact me off-list? Thanks very much! Regards, Ken From ken.gilmour at gmail.com Sat May 23 18:37:46 2009 From: ken.gilmour at gmail.com (Ken Gilmour) Date: Sat, 23 May 2009 17:37:46 -0600 Subject: Global Crossing Contact In-Reply-To: <5b6f80200905231523l52bde4f3g4fcee1787b800db3@mail.gmail.com> References: <5b6f80200905231523l52bde4f3g4fcee1787b800db3@mail.gmail.com> Message-ID: <5b6f80200905231637o53b4a652ha4cc0914b54d9d9b@mail.gmail.com> Problem has been resolved, I managed to get through a different way. Thanks! 2009/5/23 Ken Gilmour : > Hi There, > > I have been trying to get in touch with someone at AS3549 for about an > hour but I can't seem to get through using normal methods (e.g. > calling numbers on the site, email to noc at globalcrossing.com doesn't > work, etc). > > Can anyone who manages this AS please contact me off-list? > > Thanks very much! > > Regards, > > Ken > From frnkblk at iname.com Sun May 24 08:53:56 2009 From: frnkblk at iname.com (Frank Bulk) Date: Sun, 24 May 2009 08:53:56 -0500 Subject: Multi-homed clients and BGP timers In-Reply-To: <006d01c9dba3$936b3a40$0a00000a@nil.si> References: <2812431.3281243033120323.JavaMail.zaid@turing-2.local> <4A1731F4.3080305@ibctech.ca> <4A1742A1.4080509@ibctech.ca> <4A174A8C.8090608@brightok.net> <4A174CD8.90602@ibctech.ca> <006d01c9dba3$936b3a40$0a00000a@nil.si> Message-ID: I would agree, BFD is the ideal way to go. I've wanted our upstream provider to use BFD on our OSPF and iBGP links, but they said they're still testing it internally. They're quite gun-shy on implementing it because the existing configuration is stable -- they don't want a new protocol creating unnecessary failovers. I'm just looking to cut failovers from the existing 12 to 45 seconds (depending on the direction) to a second or two. Frank -----Original Message----- From: Ivan Pepelnjak [mailto:ip at ioshints.info] Sent: Saturday, May 23, 2009 7:40 AM To: 'Steve Bertrand'; 'Jack Bates' Cc: 'NANOG list' Subject: RE: Multi-homed clients and BGP timers For BFD to work, you need: * ISR + 12.4(15)T (or later) * 7200 with 12.4T or 12.2SRx * 7600/6500/GSR + 12.2SRB (or later) * ASR A complete list is at the bottom of this document: http://www.cisco.com/en/US/docs/ios/12_0s/feature/guide/fs_bfd.html You'll find some more BFD details and usage guidelines here: http://www.nil.com/ipcorner/bfd/ Best regards Ivan http://www.ioshints.info/about http://blog.ioshints.info/ > > Correct me if I'm wrong, but wasn't this exactly the type > of situation > > that BFD was designed to detect and help with? > > I don't know, but I'm printing it[1] anyway to take home and > read. It's been mentioned a few times, and clearly worth > learning about. > > Thanks, > > Steve > > [1] > http://bgp.potaroo.net/ietf/all-ids/draft-ietf-bfd-v4v6-1hop-09.txt > From olof.kasselstrand at gmail.com Mon May 25 03:38:09 2009 From: olof.kasselstrand at gmail.com (Olof Kasselstrand) Date: Mon, 25 May 2009 10:38:09 +0200 Subject: Multi-homed clients and BGP timers In-Reply-To: <4A172B00.9010106@ibctech.ca> References: <4A172B00.9010106@ibctech.ca> Message-ID: We have customers in the same way you do. We only use Cisco (both pop routers and managed cpe) and use neighbor xxx.xxx.xxx.xxx timers 5 15 on the pop routers with great success. We haven't found any drawback so far. // OK On Sat, May 23, 2009 at 12:45 AM, Steve Bertrand wrote: > Hi all, > > I've got numerous single-site 100Mb fibre clients who have backup SDSL > links to my PoP. The two services terminate on separate > distribution/access routers. > > The CPE that peers to my fibre router sets a community, and my end sets > the pref to 150 based on it. The CPE also sets a higher pref for > prefixes from the fibre router. The SDSL router to CPE leaves the > default preference in place. Both of my PE gear sends default-originate > to the CPE. There is (generally) no traffic that should ever be on the > SDSL link while the fibre is up. > > Both of the PE routers then advertise the learnt client route up into > the core: > > *>i208.70.107.128/28 > ? ? ? ? ? ? ? ? ? ?172.16.104.22 ? ? ? ? ? ? 0 ? ?150 ? ? ?0 64762 i > * i ? ? ? ? ? ? ? ? 172.16.104.23 ? ? ? ? ? ? 0 ? ?100 ? ? ?0 64762 i > > My problem is the noticeable delay for switchover when the fibre happens > to go down (God forbid). > > I would like to know if BGP timer adjustment is the way to adjust this, > or if there is a better/different way. It's fair to say that the fibre > doesn't 'flap'. Based on operational experience, if there is a problem > with the fibre network, it's down for the count. > > While I'm at it, I've got another couple of questions: > > - whatever technique you might recommend to reduce the convergence > throughout the network, can the same principles be applied to iBGP as well? > > - if I need to down core2, what is the quickest and easiest way to > ensure that all gear connected to the cores will *quickly* switch to > preferring core1? > > Steve > > From kohn.jack at gmail.com Mon May 25 08:24:13 2009 From: kohn.jack at gmail.com (Jack Kohn) Date: Mon, 25 May 2009 18:54:13 +0530 Subject: AH or ESP Message-ID: Glen, IPSECME WG at IETF is actually working on the exact issue that you have described (unable to deep inspect ESP-NULL packets). You can look at draft-ietf-ipsecme-traffic-visibility-02for more details. Jack On Sat, May 23, 2009 at 5:06 AM, Glen Kent wrote: > Yes, thats what i had meant ! > > On Fri, May 22, 2009 at 10:46 PM, Christopher Morrow > wrote: >> >> On Fri, May 22, 2009 at 1:04 PM, Glen Kent wrote: >> > Hi, >> > >> > It is well known in the community that AH is NAT unfriendly while ESP >> > cannot >> > be filtered, and most firewalls would not let such packets pass. I am >> > NOT >> >> 'the content of the esp packet can't be filtered in transit' I think >> you mean... right? >> >> > interested in encrypting the data, but i do want origination >> > authentication >> > (Integrity Protection). Do folks in such cases use AH or ESP-NULL, given >> > that both have some issues? >> > >> > Thanks, >> > Glen >> > > > From fw at deneb.enyo.de Mon May 25 12:33:26 2009 From: fw at deneb.enyo.de (Florian Weimer) Date: Mon, 25 May 2009 19:33:26 +0200 Subject: Multi-homed clients and BGP timers In-Reply-To: <31E19C60-CD1E-4023-ACC0-0748E1ECE5D5@muada.com> (Iljitsch van Beijnum's message of "Sat, 23 May 2009 14:54:49 +0200") References: <2812431.3281243033120323.JavaMail.zaid@turing-2.local> <31E19C60-CD1E-4023-ACC0-0748E1ECE5D5@muada.com> Message-ID: <87bpph6qah.fsf@mid.deneb.enyo.de> * Iljitsch van Beijnum: > 30 60 isn't a good choice because that means that after 30.1 seconds a > keepalive comes in and then after 60.0 seconds the session will expire > while the second one would be there in 60.1 seconds. Wouldn't the underlying TCP retry sooner than that? From ccaputo at alt.net Mon May 25 12:59:39 2009 From: ccaputo at alt.net (Chris Caputo) Date: Mon, 25 May 2009 17:59:39 +0000 (UTC) Subject: IXP BGP timers (was: Multi-homed clients and BGP timers) In-Reply-To: References: <4A172B00.9010106@ibctech.ca> Message-ID: What's the BCP for BGP timers at exchange points? I imagine if everyone did something low like 5-15 rather than the default 60-180, CPU usage increase could be significant given a high number peers. Keeping in mind that "bgp fast-external-failover" is of no use at an exchange since the fabric is likely to stay up when a peer has gone down, and BFD would need to be negotiated peer-by-peer, is there a recommendation other than the default 60-180? Would going below 60-180 without first discussing it with your peers, tend to piss them off? Chris From danny at tcb.net Mon May 25 13:18:47 2009 From: danny at tcb.net (Danny McPherson) Date: Mon, 25 May 2009 12:18:47 -0600 Subject: Multi-homed clients and BGP timers In-Reply-To: <87bpph6qah.fsf@mid.deneb.enyo.de> References: <2812431.3281243033120323.JavaMail.zaid@turing-2.local> <31E19C60-CD1E-4023-ACC0-0748E1ECE5D5@muada.com> <87bpph6qah.fsf@mid.deneb.enyo.de> Message-ID: <462B499D-B256-4AA5-A12B-FF35E111E29A@tcb.net> On May 25, 2009, at 11:33 AM, Florian Weimer wrote: > * Iljitsch van Beijnum: > >> 30 60 isn't a good choice because that means that after 30.1 >> seconds a >> keepalive comes in and then after 60.0 seconds the session will >> expire >> while the second one would be there in 60.1 seconds. > > Wouldn't the underlying TCP retry sooner than that? I suspect that given update messages serve as implicit keepalives, it's _extremely rare that an actual keepalive message is needed in global routing environments. -danny From andree+nanog at toonk.nl Mon May 25 13:33:52 2009 From: andree+nanog at toonk.nl (Andree Toonk) Date: Mon, 25 May 2009 20:33:52 +0200 Subject: IXP BGP timers (was: Multi-homed clients and BGP timers) In-Reply-To: References: <4A172B00.9010106@ibctech.ca> Message-ID: <20090525183352.GA25514@toonk.nl> Hi Chris, .-- My secret spy satellite informs me that at Mon, 25 May 2009, Chris Caputo wrote: > Would going below 60-180 without first discussing it with your peers, tend > to piss them off? 60-180 is fairly conservative. 60-180 is the Cisco default I believe, however Junipers defaults are 30-90. I never pissed anyone off with that ;) Cheers, Andree From John.Herbert at ins.com Mon May 25 14:42:12 2009 From: John.Herbert at ins.com (John.Herbert at ins.com) Date: Mon, 25 May 2009 14:42:12 -0500 Subject: IXP BGP timers (was: Multi-homed clients and BGP timers) In-Reply-To: <20090525183352.GA25514@toonk.nl> References: <4A172B00.9010106@ibctech.ca> , <20090525183352.GA25514@toonk.nl> Message-ID: For those in multivendor environments, it's worth also being aware that since 7.6R1 JunOS sets the minimum BGP hold timer to 20 seconds. If I were creating a standard timer config to deploy consistently on customer peers (and needed something on the fast side in timer terms) I would need to take that into account. (And yes, there is of course a way to override the 20s hold timer, but it's not a supported config last time I checked) j. ________________________________________ From: Andree Toonk [andree+nanog at toonk.nl] Sent: Monday, May 25, 2009 2:33 PM To: Chris Caputo Cc: nanog at nanog.org Subject: Re: IXP BGP timers (was: Multi-homed clients and BGP timers) Hi Chris, .-- My secret spy satellite informs me that at Mon, 25 May 2009, Chris Caputo wrote: > Would going below 60-180 without first discussing it with your peers, tend > to piss them off? 60-180 is fairly conservative. 60-180 is the Cisco default I believe, however Junipers defaults are 30-90. I never pissed anyone off with that ;) Cheers, Andree From fw at deneb.enyo.de Mon May 25 15:09:40 2009 From: fw at deneb.enyo.de (Florian Weimer) Date: Mon, 25 May 2009 22:09:40 +0200 Subject: Multi-homed clients and BGP timers In-Reply-To: <462B499D-B256-4AA5-A12B-FF35E111E29A@tcb.net> (Danny McPherson's message of "Mon, 25 May 2009 12:18:47 -0600") References: <2812431.3281243033120323.JavaMail.zaid@turing-2.local> <31E19C60-CD1E-4023-ACC0-0748E1ECE5D5@muada.com> <87bpph6qah.fsf@mid.deneb.enyo.de> <462B499D-B256-4AA5-A12B-FF35E111E29A@tcb.net> Message-ID: <87bpph2bcr.fsf@mid.deneb.enyo.de> * Danny McPherson: > On May 25, 2009, at 11:33 AM, Florian Weimer wrote: > >> * Iljitsch van Beijnum: >> >>> 30 60 isn't a good choice because that means that after 30.1 >>> seconds a >>> keepalive comes in and then after 60.0 seconds the session will >>> expire >>> while the second one would be there in 60.1 seconds. >> >> Wouldn't the underlying TCP retry sooner than that? > > I suspect that given update messages serve as implicit > keepalives, it's _extremely rare that an actual keepalive > message is needed in global routing environments. See the subject of this thread. 8-) I don't think we're talking about full tables here, so you actually have to rely on keepalives (plus TCP retransmits). From kaeo at merike.com Mon May 25 16:03:19 2009 From: kaeo at merike.com (Merike Kaeo) Date: Mon, 25 May 2009 14:03:19 -0700 Subject: AH or ESP In-Reply-To: References: Message-ID: <0B69B942-E2B7-45A1-94B3-C4D5F95EBD6E@merike.com> Yeah - the main issue with using ESP is that there's a trailer at end of packet that tells you more info to determine whether you can inspect the packet. So you have to look at the end of the packet to see whether ESP is using encryption or null-encryption (i.e. just integrity protection). Some vendors do have proprietary mechanisms in software for now which doesn't scale. The work below will hopefully lock into a solution where hw can be built to quickly determine if ESP is used for integrity only. AH is not really widely used (except for OSPFv3 since early implementations locked in on AH when the standard said to use IPsec for integrity protection). Note that a subsequent standard now exists which explicitly states that ESP-Null MUST be supported and AH MAY be supported. But how many folks are actually running OSPF for a v6 environment and using IPsec to protect the communicating peers? Some but not many (yet). Personally, I'd stick with ESP. AH complicates matters (configuration, nested environments when you do decide to also use ESP for encryption maybe later, NAT) and while is isn't officially deprecated vendors don't test it as much as ESP - at interoperability tests it's not stressed, at least the ones I've been to. Ask your vendor(s) what they think of the work below and see where they stand with implementing it. Be happy to answer any more questions offline. - merike On May 25, 2009, at 6:24 AM, Jack Kohn wrote: > Glen, > > IPSECME WG > at IETF > is actually working on the exact issue that you have described > (unable to > deep inspect ESP-NULL packets). > > You can look at > draft-ietf-ipsecme-traffic-visibility-02 draft-ietf-ipsecme-traffic-visibility-02>for > more details. > > Jack > > On Sat, May 23, 2009 at 5:06 AM, Glen Kent > wrote: >> Yes, thats what i had meant ! >> >> On Fri, May 22, 2009 at 10:46 PM, Christopher Morrow >> wrote: >>> >>> On Fri, May 22, 2009 at 1:04 PM, Glen Kent >>> wrote: >>>> Hi, >>>> >>>> It is well known in the community that AH is NAT unfriendly >>>> while ESP >>>> cannot >>>> be filtered, and most firewalls would not let such packets pass. >>>> I am >>>> NOT >>> >>> 'the content of the esp packet can't be filtered in transit' I think >>> you mean... right? >>> >>>> interested in encrypting the data, but i do want origination >>>> authentication >>>> (Integrity Protection). Do folks in such cases use AH or ESP-NULL, > given >>>> that both have some issues? >>>> >>>> Thanks, >>>> Glen >>>> >> >> From kohn.jack at gmail.com Mon May 25 19:14:40 2009 From: kohn.jack at gmail.com (Jack Kohn) Date: Tue, 26 May 2009 05:44:40 +0530 Subject: AH or ESP In-Reply-To: <0B69B942-E2B7-45A1-94B3-C4D5F95EBD6E@merike.com> References: <0B69B942-E2B7-45A1-94B3-C4D5F95EBD6E@merike.com> Message-ID: Not really. Currently, you cant even look at the ESP trailer to determine if its an encrypted or an integrity protected packet, because the trailer itself could be encrypted. A router, by reading the next-header field from the ESP trailer can never be sure that its an OSPFv3 packet inside since it wouldnt know whether the packet is encrypted or not. One could have an encrypted packet inside, for which the next-header field turns out to be 89, but that may not necessarily mean that its an OSPFv3 packet. It could be a VoIP packet that just happens to look like OSPFv3 once encrypted. There is no indication sent on the wire that says that the packet is encrypted. So, there is no way to identify/deep inspect/filter ESP packets unless you're the recipient, which imo is the root cause of all heart burn in the intermediate devices like firewalls, transit routers, etc. A couple of solutions were thrown at the WG and the current one (wesp) was selected as the best. I agree that we should just throw out AH and stick to one protocol which has been extensively tested. A quick scan through some of vendors data sheets quickly reveals that most of them dont even provide support for AH. Jack On Tue, May 26, 2009 at 2:33 AM, Merike Kaeo wrote: > Yeah - the main issue with using ESP is that there's a trailer at end of > packet that tells you more info to determine whether you can inspect the > packet. So you have to look at the end of the packet to see whether ESP is > using encryption or null-encryption (i.e. just integrity protection). Some > vendors do have proprietary mechanisms in software for now which doesn't > scale. The work below will hopefully lock into a solution where hw can be > built to quickly determine if ESP is used for integrity only. > > AH is not really widely used (except for OSPFv3 since early implementations > locked in on AH when the standard said to use IPsec for integrity > protection). Note that a subsequent standard now exists which explicitly > states that ESP-Null MUST be supported and AH MAY be supported. But how > many folks are actually running OSPF for a v6 environment and using IPsec to > protect the communicating peers? Some but not many (yet). > > Personally, I'd stick with ESP. AH complicates matters (configuration, > nested environments when you do decide to also use ESP for encryption maybe > later, NAT) and while is isn't officially deprecated vendors don't test it > as much as ESP - at interoperability tests it's not stressed, at least the > ones I've been to. Ask your vendor(s) what they think of the work below and > see where they stand with implementing it. > > Be happy to answer any more questions offline. > > - merike > > On May 25, 2009, at 6:24 AM, Jack Kohn wrote: > > Glen, >> >> IPSECME WG at >> IETF >> is actually working on the exact issue that you have described (unable to >> deep inspect ESP-NULL packets). >> >> You can look at >> draft-ietf-ipsecme-traffic-visibility-02> draft-ietf-ipsecme-traffic-visibility-02>for >> more details. >> >> Jack >> >> On Sat, May 23, 2009 at 5:06 AM, Glen Kent wrote: >> >>> Yes, thats what i had meant ! >>> >>> On Fri, May 22, 2009 at 10:46 PM, Christopher Morrow >>> wrote: >>> >>>> >>>> On Fri, May 22, 2009 at 1:04 PM, Glen Kent wrote: >>>> >>>>> Hi, >>>>> >>>>> It is well known in the community that AH is NAT unfriendly while ESP >>>>> cannot >>>>> be filtered, and most firewalls would not let such packets pass. I am >>>>> NOT >>>>> >>>> >>>> 'the content of the esp packet can't be filtered in transit' I think >>>> you mean... right? >>>> >>>> interested in encrypting the data, but i do want origination >>>>> authentication >>>>> (Integrity Protection). Do folks in such cases use AH or ESP-NULL, >>>>> >>>> given >> >>> that both have some issues? >>>>> >>>>> Thanks, >>>>> Glen >>>>> >>>>> >>> >>> > From glen.kent at gmail.com Mon May 25 19:23:27 2009 From: glen.kent at gmail.com (Glen Kent) Date: Tue, 26 May 2009 05:53:27 +0530 Subject: AH or ESP In-Reply-To: References: <0B69B942-E2B7-45A1-94B3-C4D5F95EBD6E@merike.com> Message-ID: <92c950310905251723o2efbdfdct5428556a8541daf7@mail.gmail.com> Just a quick question: Why do we need AH when we have ESP-NULL? Is AH now being supported only for legacy reasons? The only negative with ESP-NULL afaik was that it could not be filtered (since packets could not be inspected), however, this changes with the "wesp" proposal. Also, the fact that AH is NAT unfriendly should be the final nail in its coffin. Any reasons why we still see it around? Thanks, Glen On Tue, May 26, 2009 at 5:44 AM, Jack Kohn wrote: > Not really. > > Currently, you cant even look at the ESP trailer to determine if its an > encrypted or an integrity protected packet, because the trailer itself could > be encrypted. > > A router, by reading the next-header field from the ESP trailer can never be > sure that its an OSPFv3 packet inside since it wouldnt know whether the > packet is encrypted or not. One could have an encrypted packet inside, for > which the next-header field turns out to be 89, but that may not necessarily > mean that its an OSPFv3 packet. It could be a VoIP packet that just happens > to look like OSPFv3 once encrypted. There is no indication sent on the wire > that says that the packet is encrypted. > > So, there is no way to identify/deep inspect/filter ESP packets unless > you're the recipient, which imo is the root cause of all heart burn in the > intermediate devices like firewalls, transit routers, etc. > > A couple of solutions were thrown at the WG and the current one (wesp) was > selected as the best. > > I agree that we should just throw out AH and stick to one protocol which has > been extensively tested. A quick scan through some of vendors data sheets > quickly reveals that most of them dont even provide support for AH. > > Jack > > On Tue, May 26, 2009 at 2:33 AM, Merike Kaeo wrote: > >> Yeah - the main issue with using ESP is that there's a trailer at end of >> packet that tells you more info to determine whether you can inspect the >> packet. So you have to look at the end of the packet to see whether ESP is >> using encryption or null-encryption (i.e. just integrity protection). Some >> vendors do have proprietary mechanisms in software for now which doesn't >> scale. The work below will hopefully lock into a solution where hw can be >> built to quickly determine if ESP is used for integrity only. >> >> AH is not really widely used (except for OSPFv3 since early implementations >> locked in on AH when the standard said to use IPsec for integrity >> protection). Note that a subsequent standard now exists which explicitly >> states that ESP-Null MUST be supported and AH MAY be supported. But how >> many folks are actually running OSPF for a v6 environment and using IPsec to >> protect the communicating peers? Some but not many (yet). >> >> Personally, I'd stick with ESP. AH complicates matters (configuration, >> nested environments when you do decide to also use ESP for encryption maybe >> later, NAT) and while is isn't officially deprecated vendors don't test it >> as much as ESP - at interoperability tests it's not stressed, at least the >> ones I've been to. Ask your vendor(s) what they think of the work below and >> see where they stand with implementing it. >> >> Be happy to answer any more questions offline. >> >> - merike >> >> On May 25, 2009, at 6:24 AM, Jack Kohn wrote: >> >> Glen, >>> >>> IPSECME WG at >>> IETF >>> is actually working on the exact issue that you have described (unable to >>> deep inspect ESP-NULL packets). >>> >>> You can look at >>> draft-ietf-ipsecme-traffic-visibility-02>> draft-ietf-ipsecme-traffic-visibility-02>for >>> more details. >>> >>> Jack >>> >>> On Sat, May 23, 2009 at 5:06 AM, Glen Kent wrote: >>> >>>> Yes, thats what i had meant ! >>>> >>>> On Fri, May 22, 2009 at 10:46 PM, Christopher Morrow >>>> wrote: >>>> >>>>> >>>>> On Fri, May 22, 2009 at 1:04 PM, Glen Kent wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> It is well known in the community that AH is NAT unfriendly while ESP >>>>>> cannot >>>>>> be filtered, and most firewalls would not let such packets pass. I am >>>>>> NOT >>>>>> >>>>> >>>>> 'the content of the esp packet can't be filtered in transit' I think >>>>> you mean... right? >>>>> >>>>> interested in encrypting the data, but i do want origination >>>>>> authentication >>>>>> (Integrity Protection). Do folks in such cases use AH or ESP-NULL, >>>>>> >>>>> given >>> >>>> that both have some issues? >>>>>> >>>>>> Thanks, >>>>>> Glen >>>>>> >>>>>> >>>> >>>> >> > From kaeo at merike.com Mon May 25 21:51:11 2009 From: kaeo at merike.com (Merike Kaeo) Date: Mon, 25 May 2009 19:51:11 -0700 Subject: AH or ESP In-Reply-To: <92c950310905251723o2efbdfdct5428556a8541daf7@mail.gmail.com> References: <0B69B942-E2B7-45A1-94B3-C4D5F95EBD6E@merike.com> <92c950310905251723o2efbdfdct5428556a8541daf7@mail.gmail.com> Message-ID: Coming from someone who is somewhat jaded.....politics. Realistically there are some folks who believe that not having the IP header (and with v6 also the option headers) integrity protected is an issue. It's not. You have more risk of operation issues from adding complexity of AH.....note that the fields that are modified in transit in the headers are NOT included in the integrity protection. So it really becomes an issue of is the IP address protected and basically, yes that's done via IKE and the way security associations work anyhow. [if you change IP address of header you will not have appropriate security association match] Once the technology is there to quickly differentiate ESP-Null from ESP-encrypted packets the argument of "but you can inspect AH packets" becomes irrelevant. - merike On May 25, 2009, at 5:23 PM, Glen Kent wrote: > Just a quick question: Why do we need AH when we have ESP-NULL? Is AH > now being supported only for legacy reasons? The only negative with > ESP-NULL afaik was that it could not be filtered (since packets could > not be inspected), however, this changes with the "wesp" proposal. > Also, the fact that AH is NAT unfriendly should be the final nail in > its coffin. > > Any reasons why we still see it around? > > Thanks, > Glen > > On Tue, May 26, 2009 at 5:44 AM, Jack Kohn > wrote: >> Not really. >> >> Currently, you cant even look at the ESP trailer to determine if >> its an >> encrypted or an integrity protected packet, because the trailer >> itself could >> be encrypted. >> >> A router, by reading the next-header field from the ESP trailer >> can never be >> sure that its an OSPFv3 packet inside since it wouldnt know >> whether the >> packet is encrypted or not. One could have an encrypted packet >> inside, for >> which the next-header field turns out to be 89, but that may not >> necessarily >> mean that its an OSPFv3 packet. It could be a VoIP packet that >> just happens >> to look like OSPFv3 once encrypted. There is no indication sent on >> the wire >> that says that the packet is encrypted. >> >> So, there is no way to identify/deep inspect/filter ESP packets >> unless >> you're the recipient, which imo is the root cause of all heart >> burn in the >> intermediate devices like firewalls, transit routers, etc. >> >> A couple of solutions were thrown at the WG and the current one >> (wesp) was >> selected as the best. >> >> I agree that we should just throw out AH and stick to one protocol >> which has >> been extensively tested. A quick scan through some of vendors data >> sheets >> quickly reveals that most of them dont even provide support for AH. >> >> Jack >> >> On Tue, May 26, 2009 at 2:33 AM, Merike Kaeo wrote: >> >>> Yeah - the main issue with using ESP is that there's a trailer at >>> end of >>> packet that tells you more info to determine whether you can >>> inspect the >>> packet. So you have to look at the end of the packet to see >>> whether ESP is >>> using encryption or null-encryption (i.e. just integrity >>> protection). Some >>> vendors do have proprietary mechanisms in software for now which >>> doesn't >>> scale. The work below will hopefully lock into a solution where >>> hw can be >>> built to quickly determine if ESP is used for integrity only. >>> >>> AH is not really widely used (except for OSPFv3 since early >>> implementations >>> locked in on AH when the standard said to use IPsec for integrity >>> protection). Note that a subsequent standard now exists which >>> explicitly >>> states that ESP-Null MUST be supported and AH MAY be supported. >>> But how >>> many folks are actually running OSPF for a v6 environment and >>> using IPsec to >>> protect the communicating peers? Some but not many (yet). >>> >>> Personally, I'd stick with ESP. AH complicates matters >>> (configuration, >>> nested environments when you do decide to also use ESP for >>> encryption maybe >>> later, NAT) and while is isn't officially deprecated vendors >>> don't test it >>> as much as ESP - at interoperability tests it's not stressed, at >>> least the >>> ones I've been to. Ask your vendor(s) what they think of the >>> work below and >>> see where they stand with implementing it. >>> >>> Be happy to answer any more questions offline. >>> >>> - merike >>> >>> On May 25, 2009, at 6:24 AM, Jack Kohn wrote: >>> >>> Glen, >>>> >>>> IPSECME WG >>> charter.html> at >>>> IETF >>>> is actually working on the exact issue that you have described >>>> (unable to >>>> deep inspect ESP-NULL packets). >>>> >>>> You can look at >>>> draft-ietf-ipsecme-traffic-visibility-02>>> html/ >>>> draft-ietf-ipsecme-traffic-visibility-02>for >>>> more details. >>>> >>>> Jack >>>> >>>> On Sat, May 23, 2009 at 5:06 AM, Glen Kent >>>> wrote: >>>> >>>>> Yes, thats what i had meant ! >>>>> >>>>> On Fri, May 22, 2009 at 10:46 PM, Christopher Morrow >>>>> wrote: >>>>> >>>>>> >>>>>> On Fri, May 22, 2009 at 1:04 PM, Glen Kent >>>>>> wrote: >>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> It is well known in the community that AH is NAT unfriendly >>>>>>> while ESP >>>>>>> cannot >>>>>>> be filtered, and most firewalls would not let such packets >>>>>>> pass. I am >>>>>>> NOT >>>>>>> >>>>>> >>>>>> 'the content of the esp packet can't be filtered in transit' I >>>>>> think >>>>>> you mean... right? >>>>>> >>>>>> interested in encrypting the data, but i do want origination >>>>>>> authentication >>>>>>> (Integrity Protection). Do folks in such cases use AH or ESP- >>>>>>> NULL, >>>>>>> >>>>>> given >>>> >>>>> that both have some issues? >>>>>>> >>>>>>> Thanks, >>>>>>> Glen >>>>>>> >>>>>>> >>>>> >>>>> >>> >> From kohn.jack at gmail.com Mon May 25 22:26:41 2009 From: kohn.jack at gmail.com (Jack Kohn) Date: Tue, 26 May 2009 08:56:41 +0530 Subject: AH or ESP In-Reply-To: References: <0B69B942-E2B7-45A1-94B3-C4D5F95EBD6E@merike.com> <92c950310905251723o2efbdfdct5428556a8541daf7@mail.gmail.com> Message-ID: Hmm .. besides this, AH is *never* export restricted. Also, i could be mistaken, but isnt AH compliance mandatory in IPv6? Earlier there were some issues in using ESP with TCP performance enhancement proxies used in wireless networks, which couldnt deep inspect the ESP packets to extract TCP flow IDs and seq numbers, but that should all change with the new WESP proposal. Jack On Tue, May 26, 2009 at 8:21 AM, Merike Kaeo wrote: > Coming from someone who is somewhat jaded.....politics. > > Realistically there are some folks who believe that not having the IP > header (and with v6 also the option headers) integrity protected is an > issue. It's not. You have more risk of operation issues from adding > complexity of AH.....note that the fields that are modified in transit in > the headers are NOT included in the integrity protection. So it really > becomes an issue of is the IP address protected and basically, yes that's > done via IKE and the way security associations work anyhow. [if you change > IP address of header you will not have appropriate security association > match] > > Once the technology is there to quickly differentiate ESP-Null from > ESP-encrypted packets the argument of "but you can inspect AH packets" > becomes irrelevant. > > - merike > > > On May 25, 2009, at 5:23 PM, Glen Kent wrote: > > Just a quick question: Why do we need AH when we have ESP-NULL? Is AH >> now being supported only for legacy reasons? The only negative with >> ESP-NULL afaik was that it could not be filtered (since packets could >> not be inspected), however, this changes with the "wesp" proposal. >> Also, the fact that AH is NAT unfriendly should be the final nail in >> its coffin. >> >> Any reasons why we still see it around? >> >> Thanks, >> Glen >> >> On Tue, May 26, 2009 at 5:44 AM, Jack Kohn wrote: >> >>> Not really. >>> >>> Currently, you cant even look at the ESP trailer to determine if its an >>> encrypted or an integrity protected packet, because the trailer itself >>> could >>> be encrypted. >>> >>> A router, by reading the next-header field from the ESP trailer can never >>> be >>> sure that its an OSPFv3 packet inside since it wouldnt know whether the >>> packet is encrypted or not. One could have an encrypted packet inside, >>> for >>> which the next-header field turns out to be 89, but that may not >>> necessarily >>> mean that its an OSPFv3 packet. It could be a VoIP packet that just >>> happens >>> to look like OSPFv3 once encrypted. There is no indication sent on the >>> wire >>> that says that the packet is encrypted. >>> >>> So, there is no way to identify/deep inspect/filter ESP packets unless >>> you're the recipient, which imo is the root cause of all heart burn in >>> the >>> intermediate devices like firewalls, transit routers, etc. >>> >>> A couple of solutions were thrown at the WG and the current one (wesp) >>> was >>> selected as the best. >>> >>> I agree that we should just throw out AH and stick to one protocol which >>> has >>> been extensively tested. A quick scan through some of vendors data sheets >>> quickly reveals that most of them dont even provide support for AH. >>> >>> Jack >>> >>> On Tue, May 26, 2009 at 2:33 AM, Merike Kaeo wrote: >>> >>> Yeah - the main issue with using ESP is that there's a trailer at end of >>>> packet that tells you more info to determine whether you can inspect the >>>> packet. So you have to look at the end of the packet to see whether ESP >>>> is >>>> using encryption or null-encryption (i.e. just integrity protection). >>>> Some >>>> vendors do have proprietary mechanisms in software for now which doesn't >>>> scale. The work below will hopefully lock into a solution where hw can >>>> be >>>> built to quickly determine if ESP is used for integrity only. >>>> >>>> AH is not really widely used (except for OSPFv3 since early >>>> implementations >>>> locked in on AH when the standard said to use IPsec for integrity >>>> protection). Note that a subsequent standard now exists which >>>> explicitly >>>> states that ESP-Null MUST be supported and AH MAY be supported. But how >>>> many folks are actually running OSPF for a v6 environment and using >>>> IPsec to >>>> protect the communicating peers? Some but not many (yet). >>>> >>>> Personally, I'd stick with ESP. AH complicates matters (configuration, >>>> nested environments when you do decide to also use ESP for encryption >>>> maybe >>>> later, NAT) and while is isn't officially deprecated vendors don't test >>>> it >>>> as much as ESP - at interoperability tests it's not stressed, at least >>>> the >>>> ones I've been to. Ask your vendor(s) what they think of the work below >>>> and >>>> see where they stand with implementing it. >>>> >>>> Be happy to answer any more questions offline. >>>> >>>> - merike >>>> >>>> On May 25, 2009, at 6:24 AM, Jack Kohn wrote: >>>> >>>> Glen, >>>> >>>>> >>>>> IPSECME WG at >>>>> IETF >>>>> is actually working on the exact issue that you have described (unable >>>>> to >>>>> deep inspect ESP-NULL packets). >>>>> >>>>> You can look at >>>>> draft-ietf-ipsecme-traffic-visibility-02>>>> draft-ietf-ipsecme-traffic-visibility-02>for >>>>> more details. >>>>> >>>>> Jack >>>>> >>>>> On Sat, May 23, 2009 at 5:06 AM, Glen Kent >>>>> wrote: >>>>> >>>>> Yes, thats what i had meant ! >>>>>> >>>>>> On Fri, May 22, 2009 at 10:46 PM, Christopher Morrow >>>>>> wrote: >>>>>> >>>>>> >>>>>>> On Fri, May 22, 2009 at 1:04 PM, Glen Kent >>>>>>> wrote: >>>>>>> >>>>>>> Hi, >>>>>>>> >>>>>>>> It is well known in the community that AH is NAT unfriendly while >>>>>>>> ESP >>>>>>>> cannot >>>>>>>> be filtered, and most firewalls would not let such packets pass. I >>>>>>>> am >>>>>>>> NOT >>>>>>>> >>>>>>>> >>>>>>> 'the content of the esp packet can't be filtered in transit' I think >>>>>>> you mean... right? >>>>>>> >>>>>>> interested in encrypting the data, but i do want origination >>>>>>> >>>>>>>> authentication >>>>>>>> (Integrity Protection). Do folks in such cases use AH or ESP-NULL, >>>>>>>> >>>>>>>> given >>>>>>> >>>>>> >>>>> that both have some issues? >>>>>> >>>>>>> >>>>>>>> Thanks, >>>>>>>> Glen >>>>>>>> >>>>>>>> >>>>>>>> >>>>>> >>>>>> >>>> >>> > From kaeo at merike.com Mon May 25 23:03:55 2009 From: kaeo at merike.com (Merike Kaeo) Date: Mon, 25 May 2009 21:03:55 -0700 Subject: AH or ESP In-Reply-To: References: <0B69B942-E2B7-45A1-94B3-C4D5F95EBD6E@merike.com> <92c950310905251723o2efbdfdct5428556a8541daf7@mail.gmail.com> Message-ID: <7AF939ED-28E6-4814-A774-F75FED105888@merike.com> IPsec as a whole is compliance mandatory for IPv6 although for new version of IPv6 Node requirements that came out recently I think they changed that to a 'SHOULD'. Wireless devices (phones) have issues with battery life when IPsec implemented. Note that all standards say ESP-Null is 'MUST' (mandatory-to-implement ) algorithm and AH is a 'MAY' support. Yep.....integrity was specifically decoupled due to export restrictions on cryptography technologies used for encryption - the restrictions do not apply for just authentication/integrity cryptography. Hence AH and ESP. ESP-Null came about when folks realized AH could not traverse NATs. - merike On May 25, 2009, at 8:26 PM, Jack Kohn wrote: > Hmm .. besides this, AH is *never* export restricted. Also, i could > be mistaken, but isnt AH compliance mandatory in IPv6? > > Earlier there were some issues in using ESP with TCP performance > enhancement proxies used in wireless networks, which couldnt deep > inspect the ESP packets to extract TCP flow IDs and seq numbers, > but that should all change with the new WESP proposal. > > Jack > > On Tue, May 26, 2009 at 8:21 AM, Merike Kaeo wrote: > Coming from someone who is somewhat jaded.....politics. > > Realistically there are some folks who believe that not having the > IP header (and with v6 also the option headers) integrity protected > is an issue. It's not. You have more risk of operation issues > from adding complexity of AH.....note that the fields that are > modified in transit in the headers are NOT included in the > integrity protection. So it really becomes an issue of is the IP > address protected and basically, yes that's done via IKE and the > way security associations work anyhow. [if you change IP address of > header you will not have appropriate security association match] > > Once the technology is there to quickly differentiate ESP-Null from > ESP-encrypted packets the argument of "but you can inspect AH > packets" becomes irrelevant. > > - merike > > > On May 25, 2009, at 5:23 PM, Glen Kent wrote: > > Just a quick question: Why do we need AH when we have ESP-NULL? Is AH > now being supported only for legacy reasons? The only negative with > ESP-NULL afaik was that it could not be filtered (since packets could > not be inspected), however, this changes with the "wesp" proposal. > Also, the fact that AH is NAT unfriendly should be the final nail in > its coffin. > > Any reasons why we still see it around? > > Thanks, > Glen > > On Tue, May 26, 2009 at 5:44 AM, Jack Kohn > wrote: > Not really. > > Currently, you cant even look at the ESP trailer to determine if > its an > encrypted or an integrity protected packet, because the trailer > itself could > be encrypted. > > A router, by reading the next-header field from the ESP trailer can > never be > sure that its an OSPFv3 packet inside since it wouldnt know whether > the > packet is encrypted or not. One could have an encrypted packet > inside, for > which the next-header field turns out to be 89, but that may not > necessarily > mean that its an OSPFv3 packet. It could be a VoIP packet that just > happens > to look like OSPFv3 once encrypted. There is no indication sent on > the wire > that says that the packet is encrypted. > > So, there is no way to identify/deep inspect/filter ESP packets unless > you're the recipient, which imo is the root cause of all heart burn > in the > intermediate devices like firewalls, transit routers, etc. > > A couple of solutions were thrown at the WG and the current one > (wesp) was > selected as the best. > > I agree that we should just throw out AH and stick to one protocol > which has > been extensively tested. A quick scan through some of vendors data > sheets > quickly reveals that most of them dont even provide support for AH. > > Jack > > On Tue, May 26, 2009 at 2:33 AM, Merike Kaeo wrote: > > Yeah - the main issue with using ESP is that there's a trailer at > end of > packet that tells you more info to determine whether you can > inspect the > packet. So you have to look at the end of the packet to see > whether ESP is > using encryption or null-encryption (i.e. just integrity > protection). Some > vendors do have proprietary mechanisms in software for now which > doesn't > scale. The work below will hopefully lock into a solution where hw > can be > built to quickly determine if ESP is used for integrity only. > > AH is not really widely used (except for OSPFv3 since early > implementations > locked in on AH when the standard said to use IPsec for integrity > protection). Note that a subsequent standard now exists which > explicitly > states that ESP-Null MUST be supported and AH MAY be supported. > But how > many folks are actually running OSPF for a v6 environment and using > IPsec to > protect the communicating peers? Some but not many (yet). > > Personally, I'd stick with ESP. AH complicates matters > (configuration, > nested environments when you do decide to also use ESP for > encryption maybe > later, NAT) and while is isn't officially deprecated vendors don't > test it > as much as ESP - at interoperability tests it's not stressed, at > least the > ones I've been to. Ask your vendor(s) what they think of the work > below and > see where they stand with implementing it. > > Be happy to answer any more questions offline. > > - merike > > On May 25, 2009, at 6:24 AM, Jack Kohn wrote: > > Glen, > > IPSECME WG at > IETF > is actually working on the exact issue that you have described > (unable to > deep inspect ESP-NULL packets). > > You can look at > draft-ietf-ipsecme-traffic-visibility-02 draft-ietf-ipsecme-traffic-visibility-02>for > more details. > > Jack > > On Sat, May 23, 2009 at 5:06 AM, Glen Kent > wrote: > > Yes, thats what i had meant ! > > On Fri, May 22, 2009 at 10:46 PM, Christopher Morrow > wrote: > > > On Fri, May 22, 2009 at 1:04 PM, Glen Kent > wrote: > > Hi, > > It is well known in the community that AH is NAT unfriendly while ESP > cannot > be filtered, and most firewalls would not let such packets pass. I am > NOT > > > 'the content of the esp packet can't be filtered in transit' I think > you mean... right? > > interested in encrypting the data, but i do want origination > authentication > (Integrity Protection). Do folks in such cases use AH or ESP-NULL, > > given > > that both have some issues? > > Thanks, > Glen > > > > > > > > From randy at psg.com Tue May 26 02:47:04 2009 From: randy at psg.com (Randy Bush) Date: Tue, 26 May 2009 16:47:04 +0900 Subject: AH or ESP In-Reply-To: <7AF939ED-28E6-4814-A774-F75FED105888@merike.com> References: <0B69B942-E2B7-45A1-94B3-C4D5F95EBD6E@merike.com> <92c950310905251723o2efbdfdct5428556a8541daf7@mail.gmail.com> <7AF939ED-28E6-4814-A774-F75FED105888@merike.com> Message-ID: > IPsec as a whole is compliance mandatory for IPv6 although for new > version of IPv6 Node requirements that came out recently I think they > changed that to a 'SHOULD'. the reality is DON'T From steve at ibctech.ca Tue May 26 07:32:47 2009 From: steve at ibctech.ca (Steve Bertrand) Date: Tue, 26 May 2009 08:32:47 -0400 Subject: Multi-homed clients and BGP timers In-Reply-To: <4A172B00.9010106@ibctech.ca> References: <4A172B00.9010106@ibctech.ca> Message-ID: <4A1BE16F.7010007@ibctech.ca> Steve Bertrand wrote: > My problem is the noticeable delay for switchover when the fibre happens > to go down (God forbid). > > I would like to know if BGP timer adjustment is the way to adjust this, > or if there is a better/different way. It's fair to say that the fibre > doesn't 'flap'. Based on operational experience, if there is a problem > with the fibre network, it's down for the count. Thanks to all for the great feedback. In summary, I've learnt: - Even though BFD would be a fantastic solution and would require only minimal changes (to my strict uRPF setup), it's a non-starter, as I don't fit all of the requirements that Ivan pointed out - fast-external-fallover is already enabled by default, but in order for this to be effective, the interface has to physically go into down state. In my case, although not impossible, it is extremely unlikely - adjusting BGP timers is the best option given it's really the only one left. Although I generally try to keep consistency among all equipment (if I set the timers at one end, I would set them the same at the other). Iljitsch recommended to leave the CPE end alone, so if something bad happens, access to the CPE would not be necessary to revert the change - I'm going to set the timers to 5/16. I like the idea of the extra second on top of being divisible by three. That will ensure that at least three keepalives have a chance to make it before the session hold timer is reached Cheers! Steve -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3233 bytes Desc: S/MIME Cryptographic Signature URL: From bburke at merit.edu Tue May 26 09:39:11 2009 From: bburke at merit.edu (Betty Burke) Date: Tue, 26 May 2009 10:39:11 -0400 (EDT) Subject: [NANOG-announce] NANOG46 reminders In-Reply-To: <1099600918.1051391243348439289.JavaMail.root@crono> Message-ID: <1290391580.1052741243348751003.JavaMail.root@crono> Hi Folks: One Last set of meeting reminders!! If you have not yet made your hotel reservations, you might want to consider doing so as the NANOG hotel room rate ends on Friday, May 29. Make sure to complete your NANOG registration soon, you do not want to miss out on an excellent program and opportunity to catch up in person with members of the NANOG community. On Monday, June 8 the registration late fee goes into effect. Lastly, do not forget to get those lighting talk ideas submitted! Look forward to seeing everyone in sunny Philly. Sincerely, Merit, NANOG Support Team _______________________________________________ NANOG-announce mailing list NANOG-announce at nanog.org http://mailman.nanog.org/mailman/listinfo/nanog-announce From jeroen at unfix.org Tue May 26 10:14:12 2009 From: jeroen at unfix.org (Jeroen Massar) Date: Tue, 26 May 2009 17:14:12 +0200 Subject: The adventures of Team ARIN Message-ID: <4A1C0744.4010001@spaghetti.zurich.ibm.com> Semi-Off-Topic here, I know, but it might help Network Operators to explain certain misguided people and thus lower noise and raise signal in various places. https://www.arin.net/knowledge/comic.html Short short synopsis: comic about how ARIN handles certain things and what ARIN does etc. Greets, Jeroen -- Currently published issues: Issue 1 - The Beginning of Team ARIN ----------------------------------------- Synopsis: In issue 1, learn how Team ARIN was founded with the assistance of Jon Postel. See how active participation by the entire Internet community is key to Team ARIN's success as it endeavors to facilitate the open and transparent, bottom-up policy development processes. Issue 2 - "FUD for Thought" ----------------------------------------- Synopsis: In issue 2, Team ARIN embarks on a mission to raise awareness about the issue of depletion of the available pool of IPv4 addresses and encounters a new enemy -- Agent FUD. Working for the "Bad Idea Force," FUD is busy trying to spread fear, uncertainty, and doubt about IPv4 address depletion. Using newly acquired technology, Team ARIN combines forces to help combat this new enemy of the open and transparent principles the Internet is based on, and in doing so creates something more than even they expected! Issue 3 - "FUD 2.0 - Return of the FUD Factor!" ----------------------------------------- Synposis: Issue 3 begins with Team ARIN flying back from a conference when they are alerted to a new problem and an old enemy. Agent FUD has returned and this time he's seeking to undermine the Internet community's migration to IPv6. Read the issue to find out how Team ARIN saves the day and how you can help! (s/synposis/synopsis/ by me, that typo is still on the original site, rest of content all by ARIN, nothing I can do about, thus don't complain to me ;) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 187 bytes Desc: OpenPGP digital signature URL: From jcurran at istaff.org Tue May 26 11:26:16 2009 From: jcurran at istaff.org (John Curran) Date: Tue, 26 May 2009 12:26:16 -0400 Subject: OT: ARIN Information In-Reply-To: <4A1C0744.4010001@spaghetti.zurich.ibm.com> References: <4A1C0744.4010001@spaghetti.zurich.ibm.com> Message-ID: <2EFC4002-A2E0-4698-81D0-BC23D7E5C665@istaff.org> On May 26, 2009, at 11:14 AM, Jeroen Massar wrote: > > Semi-Off-Topic here, I know, but it might help Network Operators to > explain certain misguided people and thus lower noise and raise signal > in various places. Another resource is the recent slide deck released for community use: People who have further need for education or information materials for ARIN and IPv4/IPv6 address issues are encouraged to follow up on the mailing list. Thanks! /John John Curran Acting President and CEO ARIN From gb10hkzo-nanog at yahoo.co.uk Tue May 26 13:03:59 2009 From: gb10hkzo-nanog at yahoo.co.uk (gb10hkzo-nanog at yahoo.co.uk) Date: Tue, 26 May 2009 11:03:59 -0700 (PDT) Subject: MX Record Theories Message-ID: <189373.71102.qm@web24704.mail.ird.yahoo.com> Hello all, First, I hope this is not off-topic for NANOG, please be gentle with me as this is my first post. I would be most interested to hear NANOG theories on the variety of MX record practices out there, namely, how come there seem to be so many ways employed to achieve the same goal ? Do you have experience in more than one of these methods and which do you favour ? To illustrate my question : (1) If you query the MX records for, Hotmail or AOL you will receive 4 equal weight MX records, each of the MX records having a round-robin set of IPs. e.g. hotmail.com. 2706 IN MX 5 mx4.hotmail.com. hotmail.com. 2706 IN MX 5 mx1.hotmail.com. hotmail.com. 2706 IN MX 5 mx2.hotmail.com. hotmail.com. 2706 IN MX 5 mx3.hotmail.com. -and- mx3.hotmail.com. 1926 IN A 65.xxxxxxx mx3.hotmail.com. 1926 IN A 65.xxxxxxx mx3.hotmail.com. 1926 IN A 65.xxxxxxx etc.etc. (2) Alternatively, some people, particularly the ones that use hosted filtering, tend to have one MX record, which as multiple round robin IPs. e.g. microsoft.com. 780 IN MX 10 mail.global.frontbridge.com. -and- mail.global.frontbridge.com. 1728 IN A 65.xxxxxxx mail.global.frontbridge.com. 1728 IN A 207.xxxxxxx etc. etc. (3) And others simply have a more traditional setup using multiple MX records and only one IP per MX record with no round robin apple.com. 931 IN MX 10 mail-in14.apple.com. apple.com. 931 IN MX 20 mail-in3.apple.com. apple.com. 931 IN MX 20 eg-mail-in2.apple.com. etc.etc. So what's the big deal ? Please note I'm not asking which is "better" ... I am just curious and interested to hear your professional opinions and experiences. Personally, I favour the simple option 3, multiple MX records. Thanks y'all. From r.hyunseog at ieee.org Tue May 26 13:42:39 2009 From: r.hyunseog at ieee.org (Alex H. Ryu) Date: Tue, 26 May 2009 13:42:39 -0500 Subject: MX Record Theories In-Reply-To: <189373.71102.qm@web24704.mail.ird.yahoo.com> References: <189373.71102.qm@web24704.mail.ird.yahoo.com> Message-ID: <4A1C381F.6080409@ieee.org> I don't think there is no real answer for your question. It depends on each company's business objective, the cost, network topology, and their policy. MX record is the the mechanism for mail delivery procotol. It doesn't dictate how to implement. Depending on mail volume, and network policy, you can implement actual mail servers within DNS/SMTP protocol. There are multiple ways to get things done. Depending on budget, business objective, network resource/policy, you can choose the way that fits to your need. It is same as Microsoft Windows operating system. Microsoft release the Windows, but it doesn't say you have to run it as cluster or not. Depending on your need, and your own analysis/decision, you can run whatever you like. Alex gb10hkzo-nanog at yahoo.co.uk wrote: > Hello all, > > First, I hope this is not off-topic for NANOG, please be gentle with me as this is my first post. > > I > would be most interested to hear NANOG theories on the variety of MX > record practices out there, namely, how come there seem to be so many > ways employed to achieve the same goal ? Do you have experience in > more than one of these methods and which do you favour ? > > To illustrate my question : > > (1) > If you query the MX records for, Hotmail or AOL you will receive 4 > equal weight MX records, each of the MX records having a round-robin > set of IPs. > e.g. > hotmail.com. 2706 IN MX 5 mx4.hotmail.com. > hotmail.com. 2706 IN MX 5 mx1.hotmail.com. > hotmail.com. 2706 IN MX 5 mx2.hotmail.com. > hotmail.com. 2706 IN MX 5 mx3.hotmail.com. > -and- > mx3.hotmail.com. 1926 IN A 65.xxxxxxx > mx3.hotmail.com. 1926 IN A 65.xxxxxxx > mx3.hotmail.com. 1926 IN A 65.xxxxxxx > etc.etc. > > (2) > Alternatively, some people, particularly the ones that use hosted > filtering, tend to have one MX record, which as multiple round robin > IPs. > e.g. > microsoft.com. 780 IN MX 10 mail.global.frontbridge.com. > -and- > mail.global.frontbridge.com. 1728 IN A 65.xxxxxxx > mail.global.frontbridge.com. 1728 IN A 207.xxxxxxx > etc. etc. > > (3) And others simply have a more traditional setup using multiple MX records and only one IP per MX record with no round robin > apple.com. 931 IN MX 10 mail-in14.apple.com. > apple.com. 931 IN MX 20 mail-in3.apple.com. > apple.com. 931 IN MX 20 eg-mail-in2.apple.com. > etc.etc. > > > So > what's the big deal ? Please note I'm not asking which is "better" ... > I am just curious and interested to hear your professional opinions and > experiences. > > Personally, I favour the simple option 3, multiple MX records. > > Thanks y'all. > > > > > > > > From Valdis.Kletnieks at vt.edu Tue May 26 14:01:11 2009 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Tue, 26 May 2009 15:01:11 -0400 Subject: MX Record Theories In-Reply-To: Your message of "Tue, 26 May 2009 11:03:59 PDT." <189373.71102.qm@web24704.mail.ird.yahoo.com> References: <189373.71102.qm@web24704.mail.ird.yahoo.com> Message-ID: <163001.1243364471@turing-police.cc.vt.edu> On Tue, 26 May 2009 11:03:59 PDT, gb10hkzo-nanog at yahoo.co.uk said: > would be most interested to hear NANOG theories on the variety of MX > record practices out there, namely, how come there seem to be so many > ways employed to achieve the same goal ? The trick here is that it isn't always *exactly* "the same goal". There's multiple mail system architectures and design philosophies. One often overlooked but very important design point for the *large* providers: % dig aol.com mx ;; ANSWER SECTION: aol.com. 2805 IN MX 15 mailin-01.mx.aol.com. aol.com. 2805 IN MX 15 mailin-02.mx.aol.com. ... ;; WHEN: Tue May 26 14:40:41 2009 ;; MSG SIZE rcvd: 507 That 507 is critically important if you want to receive e-mail from sites with fascist firewalls that block EDNS0 and/or TCP/53. 5 bytes left. ;) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 226 bytes Desc: not available URL: From herrin-nanog at dirtside.com Tue May 26 14:12:34 2009 From: herrin-nanog at dirtside.com (William Herrin) Date: Tue, 26 May 2009 15:12:34 -0400 Subject: MX Record Theories In-Reply-To: <189373.71102.qm@web24704.mail.ird.yahoo.com> References: <189373.71102.qm@web24704.mail.ird.yahoo.com> Message-ID: <3c3e3fca0905261212r72b69d08mdae2f1dcf4494498@mail.gmail.com> On Tue, May 26, 2009 at 2:03 PM, wrote: > I would be most interested to hear NANOG theories on the variety of MX > record practices out there, namely, how come there seem to be so many > ways employed to achieve the same goal ? ?Do you have experience in > more than one of these methods and which do you favour ? > apple.com. 931 IN MX 10 mail-in14.apple.com. > apple.com. 931 IN MX 20 mail-in3.apple.com. > apple.com. 931 IN MX 20 eg-mail-in2.apple.com. > etc.etc. Use this when only the front server is fully capable of processing the mail into the domain. The other servers will have to hold some or all of the mail until the first server or its cold spare returns to service. Or perhaps the secondary servers are fully capable but undesirable for some other reason, such as slower hardware or older versions of the software. > microsoft.com. 780 IN MX 10 mail.global.frontbridge.com. > -and- > mail.global.frontbridge.com. 1728 IN A 65.xxxxxxx > mail.global.frontbridge.com. 1728 IN A 207.xxxxxxx Use this when you have multiple front-end servers any of which is fully capable of handling all messages entering the system. Free load balancer built into the protocol. > hotmail.com. ? ? ? ?2706 ? ?IN ? ?MX ? ?5 mx4.hotmail.com. > hotmail.com. ? ? ? ?2706 ? ?IN ? ?MX ? ?5 mx1.hotmail.com. > hotmail.com. ? ? ? ?2706 ? ?IN ? ?MX ? ?5 mx2.hotmail.com. > hotmail.com. ? ? ? ?2706 ? ?IN ? ?MX ? ?5 mx3.hotmail.com. > -and- > mx3.hotmail.com. ? ?1926 ? ?IN ? ?A ? ?65.xxxxxxx > mx3.hotmail.com. ? ?1926 ? ?IN ? ?A ? ?65.xxxxxxx > mx3.hotmail.com. ? ?1926 ? ?IN ? ?A ? ?65.xxxxxxx Use this when you have a large number of front-end servers fully capable of handling messages entering the system -and- you're somewhat clueful. The difference is that you want the IP addresses of the servers to be included as "additional" information in the DNS response. If you have a large number of addresses, they're all under the same name and including them all would make the DNS response packet larger than a few hundred bytes, the server will drop the additional information, requiring a second DNS lookup and possibly a third TCP-based DNS lookup in order to get it. By splitting them up, the DNS server will pack as many sets of addresses as it can into the original response packet. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From lukasz at bromirski.net Tue May 26 14:13:10 2009 From: lukasz at bromirski.net (Lukasz Bromirski) Date: Tue, 26 May 2009 21:13:10 +0200 Subject: PLNOG3 - 10-11.09.2009 - Call for Papers! Message-ID: <4A1C3F46.3020208@bromirski.net> Hello, Polish Network Operators Group (PLNOG)[1] will meet for the third time ever on 10th and 11th of September 2009 in Cracow, Poland. We would like to invite You all to submit your presentation proposal. The plan for PLNOG 3rd is to have three tracks: * Architectures and technologies - sessions covering networking solutions, future of standards and the standarization process for current technologies; * Real-life deployments and best practices - sessions covering first-hand experience with deployment of specific solutions, products and solutions * Content provider architecture and scalability - dedicated for people interested in building backends for all kinds of networking sites like portals, community sites and etc. Additionally, we would like to invite You to suggest subjects for the open discussion sessions that will take place before the main event and after the keynotes. Last subjects revolved around IPv6 deployment and lawful intercept issues from the government and practical point of view. The submissions will be discussed by the PLNOG board[2], so the dead line for them is 25th of June, 2009. The full agenda with all sessions will be published no later than to 10th of July, 2009. CfP proposals should be sent to following e-mail: andrzej.targosz {%} proidea.org.pl with the prefix 'PLNOG3' in subject. We would also like to invite all vendors to participate in presentations - however, bear in mind please no vendor-oriented sessions will be permitted, which means no sales, no marketing, only pure technical stuff. The pointers to some specific design issues, products or solutions are allowed if they follow approved presentation flow and are relevant to subject covered. Last but not least - if You want to sponsor PLNOG we'd be more than happy to discuss this with You. [1]. http://www.plnog.pl [2]. http://plnog.pl/komiter-i-rada-nog/lang-pref/en/ -- "Don't expect me to cry for all the | ?ukasz Bromirski reasons you had to die" -- Kurt Cobain | http://lukasz.bromirski.net From sethm at rollernet.us Tue May 26 14:39:10 2009 From: sethm at rollernet.us (Seth Mattinen) Date: Tue, 26 May 2009 12:39:10 -0700 Subject: Why choose 120 volts? Message-ID: <4A1C455E.5080103@rollernet.us> I have a pure curiosity question for the NANOG crowd here. If you run your facility/datacenter/cage/rack on 120 volts, why? I've been running my facility at 208 for years because I can get away with lower amperage circuits. I'm curious about the reasons for using high-amp 120 volt circuits to drive racks of equipment instead of low-amp 208 or 240 volt circuits. ~Seth From alex at corp.nac.net Tue May 26 14:43:20 2009 From: alex at corp.nac.net (Alex Rubenstein) Date: Tue, 26 May 2009 15:43:20 -0400 Subject: Why choose 120 volts? In-Reply-To: <4A1C455E.5080103@rollernet.us> References: <4A1C455E.5080103@rollernet.us> Message-ID: > I have a pure curiosity question for the NANOG crowd here. If you run > your facility/datacenter/cage/rack on 120 volts, why? Because we are stupid. > I've been running my facility at 208 for years because I can get away > with lower amperage circuits. I'm curious about the reasons for using > high-amp 120 volt circuits to drive racks of equipment instead of > low-amp 208 or 240 volt circuits. That makes you smarter than the average guy. But, if we were really smart, we'd run at least 277, or maybe 347. Countless amounts of money would be saved on losses (transformation), copper (smaller wire), and many other areas. Most of the stuff we all run is already insulated for these voltage levels. Even better would be all two pole 2 pole 480's or 2 pole 600's, then we wouldn't need neutrals. From alh-ietf at tndh.net Tue May 26 15:00:51 2009 From: alh-ietf at tndh.net (Tony Hain) Date: Tue, 26 May 2009 13:00:51 -0700 Subject: AH or ESP In-Reply-To: <7AF939ED-28E6-4814-A774-F75FED105888@merike.com> References: <0B69B942-E2B7-45A1-94B3-C4D5F95EBD6E@merike.com> <92c950310905251723o2efbdfdct5428556a8541daf7@mail.gmail.com> <7AF939ED-28E6-4814-A774-F75FED105888@merike.com> Message-ID: <06b201c9de3c$ac7fa3e0$057eeba0$@net> Merike Kaeo wrote: ... > ESP-Null came about when folks > realized AH could not traverse NATs. Thus the absolute reason why people should promote AH to kill off the 66nat nonsense. Just because you can't use it for IPv4 is no reason to avoid using it for IPv6 now and let its momentum suppress the 66CGN walled garden mindset. Tony From oberman at es.net Tue May 26 15:05:36 2009 From: oberman at es.net (Kevin Oberman) Date: Tue, 26 May 2009 13:05:36 -0700 Subject: Why choose 120 volts? In-Reply-To: Your message of "Tue, 26 May 2009 15:43:20 EDT." Message-ID: <20090526200539.7384E1CC0D@ptavv.es.net> > From: Alex Rubenstein > Date: Tue, 26 May 2009 15:43:20 -0400 > > > I have a pure curiosity question for the NANOG crowd here. If you run > > your facility/datacenter/cage/rack on 120 volts, why? > > Because we are stupid. > > > > I've been running my facility at 208 for years because I can get away > > with lower amperage circuits. I'm curious about the reasons for using > > high-amp 120 volt circuits to drive racks of equipment instead of > > low-amp 208 or 240 volt circuits. > > That makes you smarter than the average guy. > > But, if we were really smart, we'd run at least 277, or maybe > 347. Countless amounts of money would be saved on losses > (transformation), copper (smaller wire), and many other areas. Most of > the stuff we all run is already insulated for these voltage levels. > > Even better would be all two pole 2 pole 480's or 2 pole 600's, then > we wouldn't need neutrals. Oh, yeah! Nothing sounds like more fun than working in a room full of 480 or 600 delta. I LIKE neutrals. (Sort of like I like continuing to have a functioning heart.) -- 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 alex at corp.nac.net Tue May 26 15:08:41 2009 From: alex at corp.nac.net (Alex Rubenstein) Date: Tue, 26 May 2009 16:08:41 -0400 Subject: Why choose 120 volts? In-Reply-To: <20090526200539.7384E1CC0D@ptavv.es.net> References: Your message of "Tue, 26 May 2009 15:43:20 EDT." <20090526200539.7384E1CC0D@ptavv.es.net> Message-ID: > > Even better would be all two pole 2 pole 480's or 2 pole 600's, then > > we wouldn't need neutrals. > > Oh, yeah! Nothing sounds like more fun than working in a room full of > 480 or 600 delta. I LIKE neutrals. (Sort of like I like continuing to > have a functioning heart.) Nobody said delta. From rdobbins at arbor.net Tue May 26 15:11:30 2009 From: rdobbins at arbor.net (Roland Dobbins) Date: Wed, 27 May 2009 03:11:30 +0700 Subject: AH or ESP In-Reply-To: <06b201c9de3c$ac7fa3e0$057eeba0$@net> References: <0B69B942-E2B7-45A1-94B3-C4D5F95EBD6E@merike.com> <92c950310905251723o2efbdfdct5428556a8541daf7@mail.gmail.com> <7AF939ED-28E6-4814-A774-F75FED105888@merike.com> <06b201c9de3c$ac7fa3e0$057eeba0$@net> Message-ID: On May 27, 2009, at 3:00 AM, Tony Hain wrote: > Just because you can't use it for IPv4 is no reason to avoid using > it for IPv6 now and let its momentum suppress the 66CGN walled > garden mindset. I concur quite strongly with your views on this particular topic, but the CGN boat appears to've sailed, AFAICT. ----------------------------------------------------------------------- Roland Dobbins // Unfortunately, inefficiency scales really well. -- Kevin Lawton From telmnstr at 757.org Tue May 26 15:15:51 2009 From: telmnstr at 757.org (telmnstr at 757.org) Date: Tue, 26 May 2009 16:15:51 -0400 (EDT) Subject: Why choose 120 volts? In-Reply-To: References: Your message of "Tue, 26 May 2009 15:43:20 EDT." <20090526200539.7384E1CC0D@ptavv.es.net> Message-ID: >> Oh, yeah! Nothing sounds like more fun than working in a room full of >> 480 or 600 delta. I LIKE neutrals. (Sort of like I like continuing to >> have a functioning heart.) > Nobody said delta. If you just run 7200vac into your 1u chinese made peecee servers, then you can eliminate the space use of the step-down transformer in the mechanical room. From web at typo.org Tue May 26 15:19:29 2009 From: web at typo.org (Wayne E. Bouchard) Date: Tue, 26 May 2009 13:19:29 -0700 Subject: Why choose 120 volts? In-Reply-To: <4A1C455E.5080103@rollernet.us> References: <4A1C455E.5080103@rollernet.us> Message-ID: <20090526201929.GA41317@typo.org> 1) Equipment used to not be dual voltage 2) For smaller scale, 120V UPS and distribution equipment is usually cheaper 3) 120V embedded itself into operations as a result. 4) We're all lazy and hate change. On Tue, May 26, 2009 at 12:39:10PM -0700, Seth Mattinen wrote: > I have a pure curiosity question for the NANOG crowd here. If you run > your facility/datacenter/cage/rack on 120 volts, why? > > I've been running my facility at 208 for years because I can get away > with lower amperage circuits. I'm curious about the reasons for using > high-amp 120 volt circuits to drive racks of equipment instead of > low-amp 208 or 240 volt circuits. > > ~Seth --- Wayne Bouchard web at typo.org Network Dude http://www.typo.org/~web/ From kurt at honeycomb.net Tue May 26 15:23:46 2009 From: kurt at honeycomb.net (Kurt Anderson) Date: Tue, 26 May 2009 15:23:46 -0500 Subject: Why choose 120 volts? References: Your message of "Tue, 26 May 2009 15:43:20 EDT."<20090526200539.7384E1CC0D@ptavv.es.net> Message-ID: <64975B31C6249247A722D0610F4110F7ED92C8@hive.officespace.honeycomb.net> Why stop there? Grab a 20,000 volt feeder and create a Tesla datacenter. Think of all the copper you will save... -----Original Message----- From: telmnstr at 757.org [mailto:telmnstr at 757.org] Sent: Tuesday, May 26, 2009 3:16 PM Cc: nanog at nanog.org Subject: RE: Why choose 120 volts? >> Oh, yeah! Nothing sounds like more fun than working in a room full of >> 480 or 600 delta. I LIKE neutrals. (Sort of like I like continuing to >> have a functioning heart.) > Nobody said delta. If you just run 7200vac into your 1u chinese made peecee servers, then you can eliminate the space use of the step-down transformer in the mechanical room. From gb10hkzo-nanog at yahoo.co.uk Tue May 26 15:25:32 2009 From: gb10hkzo-nanog at yahoo.co.uk (gb10hkzo-nanog at yahoo.co.uk) Date: Tue, 26 May 2009 13:25:32 -0700 (PDT) Subject: MX Record Theories In-Reply-To: <5b6f80200905261129v17eddb27w52e1a0f2e5143e59@mail.gmail.com> References: <189373.71102.qm@web24704.mail.ird.yahoo.com> <5b6f80200905261129v17eddb27w52e1a0f2e5143e59@mail.gmail.com> Message-ID: <444215.95747.qm@web24701.mail.ird.yahoo.com> Hi, > I thought i'd give you a quick response (and welcome to NANOG) :). Thanks. I can't believe that I've already received three very interesting responses in just over an hour ! I've been quietly lurking on NANOG for a while, just plucked up the courage to post ..... and might now even find a bit more courage to attempt to contribute to some threads ! Glad to see the community spirit still exists ! Keep the replies coming if there are any still on their way ..... :) Tim P.S. Valdis Kletnieks ..... I've got the feeling that this .... > That 507 is critically important if it's true, might potentially explain a few intermittent unexplicable issues we've been seeing at some sites .... time for some research me thinks.... :) From barney at databus.com Tue May 26 15:29:12 2009 From: barney at databus.com (Barney Wolff) Date: Tue, 26 May 2009 16:29:12 -0400 Subject: Why choose 120 volts? In-Reply-To: <64975B31C6249247A722D0610F4110F7ED92C8@hive.officespace.honeycomb.net> References: <64975B31C6249247A722D0610F4110F7ED92C8@hive.officespace.honeycomb.net> Message-ID: <20090526202912.GA57626@pit.databus.com> Doesn't even need non-standard servers - just wire them all in series. On Tue, May 26, 2009 at 03:23:46PM -0500, Kurt Anderson wrote: > Why stop there? Grab a 20,000 volt feeder and create a Tesla datacenter. > Think of all the copper you will save... From andyring at inebraska.com Tue May 26 15:34:32 2009 From: andyring at inebraska.com (Andy Ringsmuth) Date: Tue, 26 May 2009 15:34:32 -0500 Subject: Why choose 120 volts? In-Reply-To: <20090526202912.GA57626@pit.databus.com> References: <64975B31C6249247A722D0610F4110F7ED92C8@hive.officespace.honeycomb.net> <20090526202912.GA57626@pit.databus.com> Message-ID: <72831E89-E244-4D7E-A7D2-D2DC83A909AA@inebraska.com> On May 26, 2009, at 3:29 PM, Barney Wolff wrote: > On Tue, May 26, 2009 at 03:23:46PM -0500, Kurt Anderson wrote: >> Why stop there? Grab a 20,000 volt feeder and create a Tesla >> datacenter. >> Think of all the copper you will save... Oh, c'mon people! We need to all think green here too. All you need is to locate it in the right spot on the planet and set up a big lightning rod. The first sustainable energy datacenter with no emissions! -Andy From Ray.Sanders at VillageVoiceMedia.com Tue May 26 15:34:41 2009 From: Ray.Sanders at VillageVoiceMedia.com (Ray Sanders) Date: Tue, 26 May 2009 13:34:41 -0700 Subject: Why choose 120 volts? In-Reply-To: <20090526202912.GA57626@pit.databus.com> References: <64975B31C6249247A722D0610F4110F7ED92C8@hive.officespace.honeycomb.net> <20090526202912.GA57626@pit.databus.com> Message-ID: <1243370081.13747.55.camel@artoo.vvmedia.com> So when one server fails, all the rest fail too? Sorting out holiday lighting is bad enough.... could you imagine having to go through rack after rack finding the one "burned out" server? On Tue, 2009-05-26 at 16:29 -0400, Barney Wolff wrote: > Doesn't even need non-standard servers - just wire them all in series. > > On Tue, May 26, 2009 at 03:23:46PM -0500, Kurt Anderson wrote: > > Why stop there? Grab a 20,000 volt feeder and create a Tesla datacenter. > > Think of all the copper you will save... > -- "Prediction is very difficult, especially about the future." Niels Bohr -- Ray Sanders Linux Administrator Village Voice Media Office: 602-744-6547 Cell: 602-300-4344 From dave at stayonline.com Tue May 26 15:36:00 2009 From: dave at stayonline.com (Dave Larter) Date: Tue, 26 May 2009 16:36:00 -0400 Subject: Why choose 120 volts? In-Reply-To: <20090526202912.GA57626@pit.databus.com> References: <64975B31C6249247A722D0610F4110F7ED92C8@hive.officespace.honeycomb.net> <20090526202912.GA57626@pit.databus.com> Message-ID: <8B79B73777E7D544A24BEB8FC50D35DB59802F@MERCURY.socrdu.com> It will be like at Christmas time, trying to find the bad bulb. -----Original Message----- From: Barney Wolff [mailto:barney at databus.com] Sent: Tuesday, May 26, 2009 4:29 PM To: nanog at nanog.org Subject: Re: Why choose 120 volts? Doesn't even need non-standard servers - just wire them all in series. On Tue, May 26, 2009 at 03:23:46PM -0500, Kurt Anderson wrote: > Why stop there? Grab a 20,000 volt feeder and create a Tesla datacenter. > Think of all the copper you will save... From jgreco at ns.sol.net Tue May 26 15:39:30 2009 From: jgreco at ns.sol.net (Joe Greco) Date: Tue, 26 May 2009 15:39:30 -0500 (CDT) Subject: Why choose 120 volts? In-Reply-To: <4A1C455E.5080103@rollernet.us> from "Seth Mattinen" at May 26, 2009 12:39:10 PM Message-ID: <200905262039.n4QKdU4g095452@aurora.sol.net> > I have a pure curiosity question for the NANOG crowd here. If you run > your facility/datacenter/cage/rack on 120 volts, why? > > I've been running my facility at 208 for years because I can get away > with lower amperage circuits. I'm curious about the reasons for using > high-amp 120 volt circuits to drive racks of equipment instead of > low-amp 208 or 240 volt circuits. 208 isn't all that great. On one hand, a 20A 208V circuit is vaguely more convenient than a 30A 120V circuit because it is delivering a bit more power to the rack (3328 vs 2880), and it's likely to work with a lot of modern equipment containing autoranging power supplies. On the flip side, with 120, you don't have to have "odd cords," and it is somewhat easier to "right-size" power for a rack (20A, 30A, 2x20A), so for an average rack that isn't crammed with high power webhosting 1U's (etc), a customer might actually find that the ability to right- size the power feed is more flexible with 120V. And I don't like not having anywhere to plug in my power screwdriver's recharger... I suppose I should see if I can find someplace that has a transformer of an appropriate size, or does anyone already have the part number for something that can provide a few hunderd milliamps of 120V from 208? :-) ... 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 Tue May 26 15:44:05 2009 From: jgreco at ns.sol.net (Joe Greco) Date: Tue, 26 May 2009 15:44:05 -0500 (CDT) Subject: Why choose 120 volts? In-Reply-To: <8B79B73777E7D544A24BEB8FC50D35DB59802F@MERCURY.socrdu.com> from "Dave Larter" at May 26, 2009 04:36:00 PM Message-ID: <200905262044.n4QKi5J0095600@aurora.sol.net> > It will be like at Christmas time, trying to find the bad bulb. This sounds like an opportunity for you guys to find "that special tool" everyone needs, and sell it to all of us. ;-) (Dave's with Stayonline, and if you haven't been to his company's web site, they're full of wonderful odds and ends ... at a bit of a mark- 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 owen at delong.com Tue May 26 15:45:33 2009 From: owen at delong.com (Owen DeLong) Date: Tue, 26 May 2009 13:45:33 -0700 Subject: Why choose 120 volts? In-Reply-To: <1243370081.13747.55.camel@artoo.vvmedia.com> References: <64975B31C6249247A722D0610F4110F7ED92C8@hive.officespace.honeycomb.net> <20090526202912.GA57626@pit.databus.com> <1243370081.13747.55.camel@artoo.vvmedia.com> Message-ID: On May 26, 2009, at 1:34 PM, Ray Sanders wrote: > So when one server fails, all the rest fail too? > > Sorting out holiday lighting is bad enough.... > > could you imagine having to go through rack after rack finding the one > "burned out" server? > Who has to imagine? Some of us remember thinnet (10base2). Owen From aaron at wholesaleinternet.net Tue May 26 15:46:59 2009 From: aaron at wholesaleinternet.net (Aaron Wendel) Date: Tue, 26 May 2009 15:46:59 -0500 Subject: Why choose 120 volts? In-Reply-To: <4A1C455E.5080103@rollernet.us> References: <4A1C455E.5080103@rollernet.us> Message-ID: <074b01c9de43$1dae5830$590b0890$@net> Our power is handed to us at 480v. We then deliver it to the customer at whatever they need. The nice thing about 120v is that everything uses it. No odd cords (as mentioned before) or expensive PDUs. I've had a lot of people suggest that running our servers at 240v would save us money because we'd use less amps. Last time I looked at my bill I was being billed by the kWh, not amp and 240v at half the amps is still the same wattage. I've been told this so many times though that I'm starting to doubt myself. If anyone can present a reason for me to switch to 240v I'd like to hear it. Aaron -----Original Message----- From: Seth Mattinen [mailto:sethm at rollernet.us] Sent: Tuesday, May 26, 2009 2:39 PM To: nanog at nanog.org Subject: Why choose 120 volts? I have a pure curiosity question for the NANOG crowd here. If you run your facility/datacenter/cage/rack on 120 volts, why? I've been running my facility at 208 for years because I can get away with lower amperage circuits. I'm curious about the reasons for using high-amp 120 volt circuits to drive racks of equipment instead of low-amp 208 or 240 volt circuits. ~Seth From r.hyunseog at ieee.org Tue May 26 15:48:17 2009 From: r.hyunseog at ieee.org (Alex H. Ryu) Date: Tue, 26 May 2009 15:48:17 -0500 Subject: Why choose 120 volts? In-Reply-To: <20090526201929.GA41317@typo.org> References: <4A1C455E.5080103@rollernet.us> <20090526201929.GA41317@typo.org> Message-ID: <4A1C5591.1080309@ieee.org> Also, adding followings. 5) availability from local power provider(s) 6) local regulation such as fire department safety rules... 7) for your own safety... (120V may not kill people, but 240V can do...) If you want better, why not just have everything to DC power ? Something like 48V... Alex Wayne E. Bouchard wrote: > 1) Equipment used to not be dual voltage > > 2) For smaller scale, 120V UPS and distribution equipment is usually > cheaper > > 3) 120V embedded itself into operations as a result. > > 4) We're all lazy and hate change. > > On Tue, May 26, 2009 at 12:39:10PM -0700, Seth Mattinen wrote: > >> I have a pure curiosity question for the NANOG crowd here. If you run >> your facility/datacenter/cage/rack on 120 volts, why? >> >> I've been running my facility at 208 for years because I can get away >> with lower amperage circuits. I'm curious about the reasons for using >> high-amp 120 volt circuits to drive racks of equipment instead of >> low-amp 208 or 240 volt circuits. >> >> ~Seth >> > > --- > Wayne Bouchard > web at typo.org > Network Dude > http://www.typo.org/~web/ > > > > From Ray.Sanders at VillageVoiceMedia.com Tue May 26 15:48:31 2009 From: Ray.Sanders at VillageVoiceMedia.com (Ray Sanders) Date: Tue, 26 May 2009 13:48:31 -0700 Subject: Why choose 120 volts? In-Reply-To: References: <64975B31C6249247A722D0610F4110F7ED92C8@hive.officespace.honeycomb.net> <20090526202912.GA57626@pit.databus.com> <1243370081.13747.55.camel@artoo.vvmedia.com> Message-ID: <1243370911.13747.59.camel@artoo.vvmedia.com> Ugh, please don't remind me of the hell that was coax. On Tue, 2009-05-26 at 13:45 -0700, Owen DeLong wrote: > On May 26, 2009, at 1:34 PM, Ray Sanders wrote: > > > So when one server fails, all the rest fail too? > > > > Sorting out holiday lighting is bad enough.... > > > > could you imagine having to go through rack after rack finding the one > > "burned out" server? > > > Who has to imagine? Some of us remember thinnet (10base2). > > Owen > -- "Prediction is very difficult, especially about the future." Niels Bohr -- Ray Sanders Linux Administrator Village Voice Media Office: 602-744-6547 Cell: 602-300-4344 From ghicks at hicks-net.net Tue May 26 15:54:22 2009 From: ghicks at hicks-net.net (Gregory Hicks) Date: Tue, 26 May 2009 13:54:22 -0700 (PDT) Subject: Why choose 120 volts? Message-ID: <200905262054.n4QKsM2V028592@metis.hicks-net.net> > Subject: RE: Why choose 120 volts? > Date: Tue, 26 May 2009 15:23:46 -0500 > From: "Kurt Anderson" > To: > > Why stop there? Grab a 20,000 volt feeder and create a Tesla > datacenter. Think of all the copper you will save... Boy! This thread went south in a hurry! I about died laughing. > > -----Original Message----- > From: telmnstr at 757.org [mailto:telmnstr at 757.org] > Sent: Tuesday, May 26, 2009 3:16 PM > Cc: nanog at nanog.org > Subject: RE: Why choose 120 volts? > > >> Oh, yeah! Nothing sounds like more fun than working in a room full of > >> 480 or 600 delta. I LIKE neutrals. (Sort of like I like continuing to > >> have a functioning heart.) > > Nobody said delta. > > If you just run 7200vac into your 1u chinese made peecee servers, then > you > can eliminate the space use of the step-down transformer in the > mechanical > room. > > > --------------------------------------------------------------------- Gregory Hicks | Principal Systems Engineer | Direct: 408.569.7928 People sleep peaceably in their beds at night only because rough men stand ready to do violence on their behalf -- George Orwell The price of freedom is eternal vigilance. -- Thomas Jefferson "The best we can hope for concerning the people at large is that they be properly armed." --Alexander Hamilton From davei at otd.com Tue May 26 15:54:37 2009 From: davei at otd.com (Dave Israel) Date: Tue, 26 May 2009 16:54:37 -0400 Subject: AH or ESP In-Reply-To: <06b201c9de3c$ac7fa3e0$057eeba0$@net> References: <0B69B942-E2B7-45A1-94B3-C4D5F95EBD6E@merike.com> <92c950310905251723o2efbdfdct5428556a8541daf7@mail.gmail.com> <7AF939ED-28E6-4814-A774-F75FED105888@merike.com> <06b201c9de3c$ac7fa3e0$057eeba0$@net> Message-ID: <4A1C570D.3060005@otd.com> Tony Hain wrote: > Merike Kaeo wrote: > ... > >> ESP-Null came about when folks >> realized AH could not traverse NATs. >> > > Thus the absolute reason why people should promote AH to kill off the 66nat > nonsense. Just because you can't use it for IPv4 is no reason to avoid using > it for IPv6 now and let its momentum suppress the 66CGN walled garden > mindset. > > That should make for a fascinating discussion. "You should use AH." "Why?" "So you can't use NAT." "Any other reason?" "... No." "Great. I'll get right on that." The delusion that network operators can successfully use unhelpful protocols and/or smoke and mirrors to force idealist network design on others needs to end. People use new protocols because they are better. If the benefit of moving to a new protocol does not outweigh the pain of moving to it, people don't use it. That's why the OSI protocols did not kill IP like they were supposed to in the 90s, it is why the largely forgotten mandated move from Windows to secure OSes (ie, Unix) for all government employees never happened, and it is why IPv6 is sputtering. If people want to use NAT, they are going to use NAT. They may stop using it if the widespread adoption of peer to peer protocols means they are missing out on things other people are doing. They are not going to stop using NAT to use a protocol maliciously designed to break it; they will just wait, patiently and nearly always successfully, for somebody to come out with a version that has no such malice. They are certainly not going to stop using NAT because somebody tells them they should use a security protocol that does not secure anything worth securing. BitTorrent is a better anti-NAT tool than AH ever will be. More carrot, less stick. -Dave From r.hyunseog at ieee.org Tue May 26 15:57:52 2009 From: r.hyunseog at ieee.org (Alex H. Ryu) Date: Tue, 26 May 2009 15:57:52 -0500 Subject: Why choose 120 volts? In-Reply-To: <1243370911.13747.59.camel@artoo.vvmedia.com> References: <64975B31C6249247A722D0610F4110F7ED92C8@hive.officespace.honeycomb.net> <20090526202912.GA57626@pit.databus.com> <1243370081.13747.55.camel@artoo.vvmedia.com> <1243370911.13747.59.camel@artoo.vvmedia.com> Message-ID: <4A1C57D0.8070903@ieee.org> I still have a couple of Ethernet cards for 10Base2, and cables. ^.^ Yes, if someone unplug or it is loosen in the middle/end, it will be fun. I guess it's going to be another bagel/coffee time except network support people. Alex Ray Sanders wrote: > Ugh, please don't remind me of the hell that was coax. > > On Tue, 2009-05-26 at 13:45 -0700, Owen DeLong wrote: > >> On May 26, 2009, at 1:34 PM, Ray Sanders wrote: >> >> >>> So when one server fails, all the rest fail too? >>> >>> Sorting out holiday lighting is bad enough.... >>> >>> could you imagine having to go through rack after rack finding the one >>> "burned out" server? >>> >>> >> Who has to imagine? Some of us remember thinnet (10base2). >> >> Owen >> >> From john at internetassociatesllc.com Tue May 26 15:56:42 2009 From: john at internetassociatesllc.com (John Lee) Date: Tue, 26 May 2009 15:56:42 -0500 Subject: Why choose 120 volts? When DC will do Message-ID: <53A6C7E936ED8544B1A2BC990D254F943C0BFB7AFD@MEMEXG1.HOST.local> What is all this talk about AC. Real data centers use DC. John (ISDN) Lee ________________________________________ From: Seth Mattinen [sethm at rollernet.us] Sent: Tuesday, May 26, 2009 3:39 PM To: nanog at nanog.org Subject: Why choose 120 volts? I have a pure curiosity question for the NANOG crowd here. If you run your facility/datacenter/cage/rack on 120 volts, why? I've been running my facility at 208 for years because I can get away with lower amperage circuits. I'm curious about the reasons for using high-amp 120 volt circuits to drive racks of equipment instead of low-amp 208 or 240 volt circuits. ~Seth From wbailey at gci.com Tue May 26 16:04:47 2009 From: wbailey at gci.com (Warren Bailey) Date: Tue, 26 May 2009 13:04:47 -0800 Subject: Why choose 120 volts? When DC will do Message-ID: <5B3743FC2D0D8B41B27EE4F5EACA79D108970F62@DTN1EX01.gci.com> I second that! ----- Original Message ----- From: John Lee To: Seth Mattinen ; nanog at nanog.org Sent: Tue May 26 12:56:42 2009 Subject: RE: Why choose 120 volts? When DC will do What is all this talk about AC. Real data centers use DC. John (ISDN) Lee ________________________________________ From: Seth Mattinen [sethm at rollernet.us] Sent: Tuesday, May 26, 2009 3:39 PM To: nanog at nanog.org Subject: Why choose 120 volts? I have a pure curiosity question for the NANOG crowd here. If you run your facility/datacenter/cage/rack on 120 volts, why? I've been running my facility at 208 for years because I can get away with lower amperage circuits. I'm curious about the reasons for using high-amp 120 volt circuits to drive racks of equipment instead of low-amp 208 or 240 volt circuits. ~Seth From jay at west.net Tue May 26 16:07:45 2009 From: jay at west.net (Jay Hennigan) Date: Tue, 26 May 2009 14:07:45 -0700 Subject: Why choose 120 volts? In-Reply-To: <074b01c9de43$1dae5830$590b0890$@net> References: <4A1C455E.5080103@rollernet.us> <074b01c9de43$1dae5830$590b0890$@net> Message-ID: <4A1C5A21.4020403@west.net> Aaron Wendel wrote: > Our power is handed to us at 480v. We then deliver it to the customer at whatever they need. The nice thing about 120v is that everything uses it. No odd cords (as mentioned before) or expensive PDUs. > > I've had a lot of people suggest that running our servers at 240v would save us money because we'd use less amps. Last time I looked at my bill I was being billed by the kWh, not amp and 240v at half the amps is still the same wattage. I've been told this so many times though that I'm starting to doubt myself. If anyone can present a reason for me to switch to 240v I'd like to hear it. Some servers (HP/Compaq comes to mind) and Cisco switches have limitations in terms of performance and/or capacity on 120v circuits. Yes, it all gets crunched down to 5VDC and similar low voltages in the power supply. The limitation is likely due to the gauge of wire used and copper losses in the input circuitry. Higher current connectors and switches, larger copper conductors, etc. are costly. If you have an application that needs that kind of power, higher voltages make sense. This is just as true if the application is a server as it is if it's an electric stove or clothes dryer. Most of the rest of the world has 240v as conventional domestic power, and most server rooms or datacenters supporting >2KVA single devices have 208 or 240v available, so it makes sense for manufacturers of high-power gear to save the money on copper and connectors and insist on higher input voltages for full spec output. Yes, it would be nice to be able to plug in your laptop charger, etc. And the voltage on that charger is likely compatible with anything from 100 to 240V. Wiring a NEMA 5-15 with 208V is just wrong, though. I have an IEC male to NEMA 5-15 female pigtail (old-school "monitor cord") with a big sticker saying "208V - Be very careful what you plug in here" for just that purpose. -- Jay Hennigan - CCIE #7880 - Network Engineering - jay at impulse.net Impulse Internet Service - http://www.impulse.net/ Your local telephone and internet company - 805 884-6323 - WB6RDV From owen at delong.com Tue May 26 16:06:57 2009 From: owen at delong.com (Owen DeLong) Date: Tue, 26 May 2009 14:06:57 -0700 Subject: Why choose 120 volts? In-Reply-To: <4A1C5591.1080309@ieee.org> References: <4A1C455E.5080103@rollernet.us> <20090526201929.GA41317@typo.org> <4A1C5591.1080309@ieee.org> Message-ID: <37DE8D33-0A17-43AA-A6AE-F796EDB1245C@delong.com> On May 26, 2009, at 1:48 PM, Alex H. Ryu wrote: > Also, adding followings. > > 5) availability from local power provider(s) I don't know of anywhere in the US/Canada where power comes into the building as strictly 110-120V. That is almost always delivered either as 1 leg of a 3-phase 208 service (most commercial/industrial deliveries) or as two hots (240V across the two hots) and a neutral (120V from either hot to neutral). Most datacenters are taking much higher voltage feeds from their utilities and most of the readily available step-down transformers and UPSs will produce 208 three-phase or 240V as described above. I am not an expert on power outside of the US, but, to the best of my knowledge, Japan's 100V/50Hz is one of the few other countries using less than 208V as their standard. > > > 6) local regulation such as fire department safety rules... > I seriously question this one. Can you point to any examples? > 7) for your own safety... (120V may not kill people, but 240V can > do...) > It's relatively easy to kill someone with 12V, so, I don't see how 10x that is significantly less dangerous than 20x. Sticking your fingers in a light socket is going to hurt regardless of the voltage. Yes, 240V can hurt more and faster, but, at the end of the day, it's not significantly more likely to kill you than 110. Fortunately, most servers don't have light sockets in the high voltage portion of the server. > > If you want better, why not just have everything to DC power ? > Something like 48V... > There's a whole host of reasons, but, the biggest one boils down to cost... Cost of the larger wires, cost of the increased line losses, etc. Owen > Alex > > > Wayne E. Bouchard wrote: >> 1) Equipment used to not be dual voltage >> >> 2) For smaller scale, 120V UPS and distribution equipment is usually >> cheaper >> >> 3) 120V embedded itself into operations as a result. >> >> 4) We're all lazy and hate change. >> >> On Tue, May 26, 2009 at 12:39:10PM -0700, Seth Mattinen wrote: >> >>> I have a pure curiosity question for the NANOG crowd here. If you >>> run >>> your facility/datacenter/cage/rack on 120 volts, why? >>> >>> I've been running my facility at 208 for years because I can get >>> away >>> with lower amperage circuits. I'm curious about the reasons for >>> using >>> high-amp 120 volt circuits to drive racks of equipment instead of >>> low-amp 208 or 240 volt circuits. >>> >>> ~Seth >>> >> >> --- >> Wayne Bouchard >> web at typo.org >> Network Dude >> http://www.typo.org/~web/ >> >> >> >> > From techgrrl at gmail.com Tue May 26 16:24:01 2009 From: techgrrl at gmail.com (Janet Plato) Date: Tue, 26 May 2009 16:24:01 -0500 Subject: Why choose 120 volts? In-Reply-To: <074b01c9de43$1dae5830$590b0890$@net> References: <4A1C455E.5080103@rollernet.us> <074b01c9de43$1dae5830$590b0890$@net> Message-ID: >?Last time I looked at my bill I was being billed by the kWh, not amp and 240v at half the amps is still the same wattage. Losses are I^2*R, so double the voltage, half the current and experience a quarter of the loss... Janet Plato From nanog at daork.net Tue May 26 16:29:44 2009 From: nanog at daork.net (Nathan Ward) Date: Wed, 27 May 2009 09:29:44 +1200 Subject: AH or ESP In-Reply-To: References: <0B69B942-E2B7-45A1-94B3-C4D5F95EBD6E@merike.com> <92c950310905251723o2efbdfdct5428556a8541daf7@mail.gmail.com> <7AF939ED-28E6-4814-A774-F75FED105888@merike.com> <06b201c9de3c$ac7fa3e0$057eeba0$@net> Message-ID: On 27/05/2009, at 8:11 AM, Roland Dobbins wrote: > > On May 27, 2009, at 3:00 AM, Tony Hain wrote: > >> Just because you can't use it for IPv4 is no reason to avoid using >> it for IPv6 now and let its momentum suppress the 66CGN walled >> garden mindset. > > I concur quite strongly with your views on this particular topic, > but the CGN boat appears to've sailed, AFAICT. Note that Tony is talking about 6-to-6 NAT, not 6-to-4 NAT or vice versa (not to be confused with 6to4 tunnelling). I'm not sure that boat has sailed yet. -- Nathan Ward From barney at databus.com Tue May 26 16:56:20 2009 From: barney at databus.com (Barney Wolff) Date: Tue, 26 May 2009 17:56:20 -0400 Subject: Why choose 120 volts? In-Reply-To: <1243370081.13747.55.camel@artoo.vvmedia.com> References: <64975B31C6249247A722D0610F4110F7ED92C8@hive.officespace.honeycomb.net> <20090526202912.GA57626@pit.databus.com> <1243370081.13747.55.camel@artoo.vvmedia.com> Message-ID: <20090526215620.GA61991@pit.databus.com> Yes - think of all the nasty partial failure cases that can be eliminated - each entire datacenter is either up or down. Much simpler! Getting back to reality, I've watched more than one electrician do a two-finger liveness test on a 120v circuit, and done it myself. 240v HURTS, and I've not seen a pro finger it deliberately. But I haven't actually asked. On Tue, May 26, 2009 at 01:34:41PM -0700, Ray Sanders wrote: > So when one server fails, all the rest fail too? > On Tue, 2009-05-26 at 16:29 -0400, Barney Wolff wrote: > > Doesn't even need non-standard servers - just wire them all in series. > > > > On Tue, May 26, 2009 at 03:23:46PM -0500, Kurt Anderson wrote: > > > Why stop there? Grab a 20,000 volt feeder and create a Tesla datacenter. -- Barney Wolff I never met a computer I didn't like. From bicknell at ufp.org Tue May 26 17:05:51 2009 From: bicknell at ufp.org (Leo Bicknell) Date: Tue, 26 May 2009 18:05:51 -0400 Subject: Why choose 120 volts? In-Reply-To: <4A1C455E.5080103@rollernet.us> References: <4A1C455E.5080103@rollernet.us> Message-ID: <20090526220551.GA60909@ussenterprise.ufp.org> In a message written on Tue, May 26, 2009 at 12:39:10PM -0700, Seth Mattinen wrote: > I have a pure curiosity question for the NANOG crowd here. If you run > your facility/datacenter/cage/rack on 120 volts, why? If folks are making their own choices, mainly for historical and convenience reasons. If folks are building data centers for others, it's that customers demand 120V power in many instances, for some good, and many bad reasons. However, for all the talk of power loss that's not the real issue. The loss due to wire or amperage is a very small part of the equation. While this paper is very much vendor produced, it's a good high level summary none the less: http://www.apcmedia.com/salestools/NRAN-6CN8PK_R0_EN.pdf Note that in a 600Kw installation power loss is reduced from 8,894 W to 845 W, a savings of 1.3%. Note that they have included the savings from additional cooling in that figure. Even at 1.3%, if you looked at the cost of rewiring an existing data center based on that figure you'd be nutty; return on investment would be forever. But what you'll find in the paper is that the change allows you to re-architect the power plant in a way that saves you money on PDU's, transformers, and other stuff. Thus this makes the most sense to consider in a green field deployment. Thus, to reframe your question, in your existing, already built out data center is it worth replacing 120V circuits with 208V/230V ones to save power? No. Savings is likely well under 1% in that situation, and time you add in the capital cost to do the work it makes no sense. In your green field, new data center, does it make sense to look at power from an entirely new point of view? Quite possibly. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 825 bytes Desc: not available URL: From sethm at rollernet.us Tue May 26 17:30:10 2009 From: sethm at rollernet.us (Seth Mattinen) Date: Tue, 26 May 2009 15:30:10 -0700 Subject: Why choose 120 volts? In-Reply-To: <200905262039.n4QKdU4g095452@aurora.sol.net> References: <200905262039.n4QKdU4g095452@aurora.sol.net> Message-ID: <4A1C6D72.2090101@rollernet.us> Joe Greco wrote: > 208 isn't all that great. On one hand, a 20A 208V circuit is vaguely > more convenient than a 30A 120V circuit because it is delivering a bit > more power to the rack (3328 vs 2880), and it's likely to work with a > lot of modern equipment containing autoranging power supplies. > > On the flip side, with 120, you don't have to have "odd cords," and it > is somewhat easier to "right-size" power for a rack (20A, 30A, 2x20A), > so for an average rack that isn't crammed with high power webhosting > 1U's (etc), a customer might actually find that the ability to right- > size the power feed is more flexible with 120V. I don't find it makes much difference, really. People are used to working with 120 only because that's how we roll in the USA; scary high voltage is for the oven and dryer. I like odd cords; it makes the protected power stuff blazingly obvious and slightly harder to plug dumb things into a UPS branch circuit because hey, a plug is a plug, right? > And I don't like not having anywhere to plug in my power screwdriver's > recharger... I suppose I should see if I can find someplace that has > a transformer of an appropriate size, or does anyone already have the > part number for something that can provide a few hunderd milliamps of > 120V from 208? :-) True, you do lose the convenience outlet factor. I made up for it by placing standard 120V outlets (utility/generator only) along the walls. It works out because I hate those stupid "wall warts" with a passion. I go out of my way to buy products that come with a corded transformer, especially if it has a C14 connector on it. If you're adept at electrical stuff you can always get a small transformer, put it in a box, stick a C14 on the high side and a 5-15 on the low side. Nothing fancy required. ~Seth From steve at ibctech.ca Tue May 26 17:43:36 2009 From: steve at ibctech.ca (Steve Bertrand) Date: Tue, 26 May 2009 18:43:36 -0400 Subject: Why choose 120 volts? In-Reply-To: <20090526215620.GA61991@pit.databus.com> References: <64975B31C6249247A722D0610F4110F7ED92C8@hive.officespace.honeycomb.net> <20090526202912.GA57626@pit.databus.com> <1243370081.13747.55.camel@artoo.vvmedia.com> <20090526215620.GA61991@pit.databus.com> Message-ID: <4A1C7098.2090106@ibctech.ca> Barney Wolff wrote: > Getting back to reality, I've watched more than one electrician do a > two-finger liveness test on a 120v circuit, and done it myself. 240v > HURTS, and I've not seen a pro finger it deliberately. But I haven't > actually asked. During my residential electrical apprenticeship, one of the tricks of the trade I learnt was a quick two finger test on 120, but never anything higher than that. That was years ago. I would never do anything of the sort intentionally ever again, even on low voltage systems (my girlfriend is an Occupational Health and Safety Officer, and she frowns on that sort of thing ;) It really depends on your conductivity to ground ie what you are standing on and the shoes you are wearing whether you will remain safe by 'testing' for hotness on a circuit by touching it. @120V, 1.2 mA is enough to tell you that the line is live. 15mA is the let-go threshold, and 100mA can kill within a second. 200mA will pretty much kill instantly. Even at 120V on non-conductive ground, if you ever accidentally touched the grounded box while touching the live wire, you will likely be dead before the breaker trips. Steve -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3233 bytes Desc: S/MIME Cryptographic Signature URL: From jared at puck.nether.net Tue May 26 17:56:12 2009 From: jared at puck.nether.net (Jared Mauch) Date: Tue, 26 May 2009 18:56:12 -0400 Subject: Why choose 120 volts? In-Reply-To: <64975B31C6249247A722D0610F4110F7ED92C8@hive.officespace.honeycomb.net> References: Your message of "Tue, 26 May 2009 15:43:20 EDT."<20090526200539.7384E1CC0D@ptavv.es.net> <64975B31C6249247A722D0610F4110F7ED92C8@hive.officespace.honeycomb.net> Message-ID: On May 26, 2009, at 4:23 PM, Kurt Anderson wrote: > Why stop there? Grab a 20,000 volt feeder and create a Tesla > datacenter. > Think of all the copper you will save... > http://video.google.com/videoplay?docid=4468957986746104671 - Jared From pshem.k at gmail.com Tue May 26 18:02:04 2009 From: pshem.k at gmail.com (Pshem Kowalczyk) Date: Wed, 27 May 2009 11:02:04 +1200 Subject: Colo on the West Coast Message-ID: <20fe625b0905261602x76a6c27dn377e9db3c6eada6e@mail.gmail.com> Hi, I'm looking for a colo provider somewhere on the west coast, preferably somewhere close to one of the peering exchanges. A virtual machine will do. I want to use it to run a small performance monitoring box (traceroutes, pings, etc). I also would like to get a full bgp feed into it so I can monitor bgp as well. Who do you think would be the best one to do it with? (answers can be off-list) kind regards Pshem From dave at stayonline.com Tue May 26 18:05:39 2009 From: dave at stayonline.com (Dave Larter) Date: Tue, 26 May 2009 19:05:39 -0400 Subject: Why choose 120 volts? In-Reply-To: References: Your message of "Tue, 26 May 2009 15:43:20EDT."<20090526200539.7384E1CC0D@ptavv.es.net><64975B31C6249247A722D0610F4110F7ED92C8@hive.officespace.honeycomb.net> Message-ID: <8B79B73777E7D544A24BEB8FC50D35DB598042@MERCURY.socrdu.com> I stop at licking the 9v batteries, intentionally, but I have been burned by 50KV before. Just imagine the copper you could save by just sending the energy thru the air, but then I guess the DC would sound and look more like the death star. -----Original Message----- From: Jared Mauch [mailto:jared at puck.nether.net] Sent: Tuesday, May 26, 2009 6:56 PM To: Kurt Anderson Cc: nanog at nanog.org Subject: Re: Why choose 120 volts? On May 26, 2009, at 4:23 PM, Kurt Anderson wrote: > Why stop there? Grab a 20,000 volt feeder and create a Tesla > datacenter. > Think of all the copper you will save... > http://video.google.com/videoplay?docid=4468957986746104671 - Jared From mmc at internode.com.au Tue May 26 18:13:55 2009 From: mmc at internode.com.au (Matthew Moyle-Croft) Date: Wed, 27 May 2009 08:43:55 +0930 Subject: Why choose 120 volts? In-Reply-To: <4A1C5A21.4020403@west.net> References: <4A1C455E.5080103@rollernet.us> <074b01c9de43$1dae5830$590b0890$@net> <4A1C5A21.4020403@west.net> Message-ID: <4A1C77B3.5070406@internode.com.au> Jay Hennigan wrote: > > Most of the rest of the world has 240v as conventional domestic power, > and most server rooms or datacenters supporting >2KVA single devices > have 208 or 240v available, so it makes sense for manufacturers of > high-power gear to save the money on copper and connectors and insist > on higher input voltages for full spec output. We're all 230vac here in Oz (it's a compromise between our old 240v standard and the Euro 220v one). In Oz we basically have a single style of outlet for AC for low amps and a couple of ones for higher amps. The higher powered PSUs are much easier to deal with on that - everytime we get ready to commission a new router etc for the US or Japan we look in amazement at the endless list of NEMA plugs and voltage options and different kinds of APC power gear we need to do everything. It kind of freaks me out - locking, not locking etc. Admittedly I find the standard 2 pin US style power connector somewhat wobbly and scary - ours seems to lock in much better. Since we get the same gear as North America mostly almost all of it copes with 90v to 240v AC 50/60hz. It's rare these days to find things without switching PSUs. It's worth noting that despite higher voltages here there aren't more deaths or injuries - but maybe it's because people take it more seriously. Admittedly no one I know is nuts enough to use body parts for "liveness testing". MMC > > Yes, it would be nice to be able to plug in your laptop charger, etc. > And the voltage on that charger is likely compatible with anything > from 100 to 240V. Wiring a NEMA 5-15 with 208V is just wrong, > though. I have an IEC male to NEMA 5-15 female pigtail (old-school > "monitor cord") with a big sticker saying "208V - Be very careful what > you plug in here" for just that purpose. > > -- > Jay Hennigan - CCIE #7880 - Network Engineering - jay at impulse.net > Impulse Internet Service - http://www.impulse.net/ > Your local telephone and internet company - 805 884-6323 - WB6RDV > From Ray.Sanders at VillageVoiceMedia.com Tue May 26 18:22:22 2009 From: Ray.Sanders at VillageVoiceMedia.com (Ray Sanders) Date: Tue, 26 May 2009 16:22:22 -0700 Subject: Colo on the West Coast Message-ID: <4A1C173E020000F200014AAE@newtimes.com> Pshem, Datapipe and hurricane electric come to mind. Mobile email powered by the force... ---- Original Message ---- From: "Pshem Kowalczyk" Date: 5/26/09 4:03 pm To: "nanog at nanog.org" Subj: Colo on the West Coast Hi, I'm looking for a colo provider somewhere on the west coast, preferably somewhere close to one of the peering exchanges. A virtual machine will do. I want to use it to run a small performance monitoring box (traceroutes, pings, etc). I also would like to get a full bgp feed into it so I can monitor bgp as well. Who do you think would be the best one to do it with? (answers can be off-list) kind regards Pshem From cra at WPI.EDU Tue May 26 18:30:27 2009 From: cra at WPI.EDU (Chuck Anderson) Date: Tue, 26 May 2009 19:30:27 -0400 Subject: Why choose 120 volts? In-Reply-To: <200905262039.n4QKdU4g095452@aurora.sol.net> References: <4A1C455E.5080103@rollernet.us> <200905262039.n4QKdU4g095452@aurora.sol.net> Message-ID: <20090526233027.GS30913@angus.ind.WPI.EDU> On Tue, May 26, 2009 at 03:39:30PM -0500, Joe Greco wrote: > And I don't like not having anywhere to plug in my power screwdriver's > recharger... I suppose I should see if I can find someplace that has > a transformer of an appropriate size, or does anyone already have the > part number for something that can provide a few hunderd milliamps of > 120V from 208? :-) We always seem to have an odd device or three that needs 120V, like a wallwart for an external modem or LCD KVM console, or some legacy specialized gear (CBORD comes to mind). For those we have been providing a single circuit/PDU in the room that runs at 120V and running extension cords as necessary. Everything else is 208V. From kohn.jack at gmail.com Tue May 26 18:35:47 2009 From: kohn.jack at gmail.com (Jack Kohn) Date: Wed, 27 May 2009 05:05:47 +0530 Subject: AH or ESP In-Reply-To: <4A1C570D.3060005@otd.com> References: <0B69B942-E2B7-45A1-94B3-C4D5F95EBD6E@merike.com> <92c950310905251723o2efbdfdct5428556a8541daf7@mail.gmail.com> <7AF939ED-28E6-4814-A774-F75FED105888@merike.com> <06b201c9de3c$ac7fa3e0$057eeba0$@net> <4A1C570D.3060005@otd.com> Message-ID: > > > The delusion that network operators can successfully use unhelpful > protocols and/or smoke and mirrors to force idealist network design on > others needs to end. People use new protocols because they are better. > If the benefit of moving to a new protocol does not outweigh the pain > of moving to it, people don't use it. That's why the OSI protocols did > not kill IP like they were supposed to in the 90s, it is why the largely > forgotten mandated move from Windows to secure OSes (ie, Unix) for all > government employees never happened, and it is why IPv6 is sputtering. > If people want to use NAT, they are going to use NAT. They may stop > using it if the widespread adoption of peer to peer protocols means they > are missing out on things other people are doing. They are not going to > stop using NAT to use a protocol maliciously designed to break it; they > will just wait, patiently and nearly always successfully, for somebody > to come out with a version that has no such malice. They are certainly > not going to stop using NAT because somebody tells them they should use > a security protocol that does not secure anything worth securing. > > BitTorrent is a better anti-NAT tool than AH ever will be. More carrot, > less stick. > I agree. Folks are going to use ESP-NULL if they really want Integrity Protection .. > -Dave > > From Mark_Andrews at isc.org Tue May 26 18:51:43 2009 From: Mark_Andrews at isc.org (Mark Andrews) Date: Wed, 27 May 2009 09:51:43 +1000 Subject: MX Record Theories In-Reply-To: Your message of "Tue, 26 May 2009 15:01:11 -0400." <163001.1243364471@turing-police.cc.vt.edu> Message-ID: <200905262351.n4QNph7h042537@drugs.dv.isc.org> In message <163001.1243364471 at turing-police.cc.vt.edu>, Valdis.Kletnieks at vt.edu writes: > --==_Exmh_1243364471_3846P > Content-Type: text/plain; charset=us-ascii > > On Tue, 26 May 2009 11:03:59 PDT, gb10hkzo-nanog at yahoo.co.uk said: > > would be most interested to hear NANOG theories on the variety of MX > > record practices out there, namely, how come there seem to be so many > > ways employed to achieve the same goal ? > > The trick here is that it isn't always *exactly* "the same goal". There's > multiple mail system architectures and design philosophies. > > One often overlooked but very important design point for the *large* provider > s: > > % dig aol.com mx > ;; ANSWER SECTION: > aol.com. 2805 IN MX 15 mailin-01.mx.aol.com. > aol.com. 2805 IN MX 15 mailin-02.mx.aol.com. > ... > ;; WHEN: Tue May 26 14:40:41 2009 > ;; MSG SIZE rcvd: 507 > > That 507 is critically important if you want to receive e-mail from sites > with fascist firewalls that block EDNS0 and/or TCP/53. 5 bytes left. ;) Actually TCP/53 out is almost always allowed. Too many things break if you block TCP/53 out. Similarly TCP to recursive servers is almost always allowed because blocking it breaks too many things. Recursive nameservers generally deal with stupid firewalls by adjusting how they make their queries. EDNS0 at 4096 -> EDNS0 at 512 -> plain DNS. Stub resolvers generally don't do EDNS so the are not impacted by stupid firewalls. This will changes as DNSSEC processing moves into the application. A EDNS referral from the root servers to the COM servers already exceeded 512 bytes. The world hasn't fallen over. That's dealt with that myth. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews at isc.org From cmadams at hiwaay.net Tue May 26 18:51:42 2009 From: cmadams at hiwaay.net (Chris Adams) Date: Tue, 26 May 2009 18:51:42 -0500 Subject: Why choose 120 volts? In-Reply-To: <200905262039.n4QKdU4g095452@aurora.sol.net> References: <4A1C455E.5080103@rollernet.us> <200905262039.n4QKdU4g095452@aurora.sol.net> Message-ID: <20090526235142.GB869478@hiwaay.net> Once upon a time, Joe Greco said: > And I don't like not having anywhere to plug in my power screwdriver's > recharger... I suppose I should see if I can find someplace that has > a transformer of an appropriate size, or does anyone already have the > part number for something that can provide a few hunderd milliamps of > 120V from 208? :-) Isn't 208V usually provided as a connection across two phases of a 3 phase circuit? In that case, you get 120V by going between one phase and neutral (no transformer required). You need a NEMA 14 (4 wire) connector to get two phases, neutral, and ground (provides 1 208V circuit and/or 2 120V circuits) or a NEMA L21 (5 wire) connector to get all three phases, neutral, and ground (provides 3 208V circuits and/or 3 120V circuits). -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From dave at stayonline.com Tue May 26 18:58:18 2009 From: dave at stayonline.com (Dave Larter) Date: Tue, 26 May 2009 19:58:18 -0400 Subject: Why choose 120 volts? In-Reply-To: <20090526235142.GB869478@hiwaay.net> References: <4A1C455E.5080103@rollernet.us><200905262039.n4QKdU4g095452@aurora.sol.net> <20090526235142.GB869478@hiwaay.net> Message-ID: <8B79B73777E7D544A24BEB8FC50D35DB598049@MERCURY.socrdu.com> Yes, you are correct Chris. The loss from getting 240 from two legs is due to the fact that it is at 120 instead of 180 deg's. -----Original Message----- From: Chris Adams [mailto:cmadams at hiwaay.net] Sent: Tuesday, May 26, 2009 7:52 PM To: Joe Greco Cc: nanog at nanog.org Subject: Re: Why choose 120 volts? Once upon a time, Joe Greco said: > And I don't like not having anywhere to plug in my power screwdriver's > recharger... I suppose I should see if I can find someplace that has > a transformer of an appropriate size, or does anyone already have the > part number for something that can provide a few hunderd milliamps of > 120V from 208? :-) Isn't 208V usually provided as a connection across two phases of a 3 phase circuit? In that case, you get 120V by going between one phase and neutral (no transformer required). You need a NEMA 14 (4 wire) connector to get two phases, neutral, and ground (provides 1 208V circuit and/or 2 120V circuits) or a NEMA L21 (5 wire) connector to get all three phases, neutral, and ground (provides 3 208V circuits and/or 3 120V circuits). -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From jgreco at ns.sol.net Tue May 26 19:19:46 2009 From: jgreco at ns.sol.net (Joe Greco) Date: Tue, 26 May 2009 19:19:46 -0500 (CDT) Subject: Why choose 120 volts? In-Reply-To: <20090526235142.GB869478@hiwaay.net> from "Chris Adams" at May 26, 2009 06:51:42 PM Message-ID: <200905270019.n4R0Jl0Z010462@aurora.sol.net> > Once upon a time, Joe Greco said: > > And I don't like not having anywhere to plug in my power screwdriver's > > recharger... I suppose I should see if I can find someplace that has > > a transformer of an appropriate size, or does anyone already have the > > part number for something that can provide a few hunderd milliamps of > > 120V from 208? :-) > > Isn't 208V usually provided as a connection across two phases of a 3 > phase circuit? In that case, you get 120V by going between one phase > and neutral (no transformer required). Yes, but this doesn't imply that you have access to those other phases. It is easy enough to be delivered 208V single phase service in a data center environment. ... 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 kaeo at merike.com Tue May 26 19:23:52 2009 From: kaeo at merike.com (Merike Kaeo) Date: Tue, 26 May 2009 17:23:52 -0700 Subject: AH or ESP In-Reply-To: References: <0B69B942-E2B7-45A1-94B3-C4D5F95EBD6E@merike.com> <92c950310905251723o2efbdfdct5428556a8541daf7@mail.gmail.com> <7AF939ED-28E6-4814-A774-F75FED105888@merike.com> <06b201c9de3c$ac7fa3e0$057eeba0$@net> <4A1C570D.3060005@otd.com> Message-ID: I agree as well that ESP-Null the way to go for integrity. From operational perspective if you are supporting both v4 and v6 (and you will) then having different protocols will be a nightmare. Common denominator is ESP-Null. Realistically for IPsec, unless you have the scalable credential issue resolved and easier configs from vendors, the operational time sync will have many looking elsewhere to accomplish what's needed in the name of security. (total bummer IMHO). - merike On May 26, 2009, at 4:35 PM, Jack Kohn wrote: >> >> >> The delusion that network operators can successfully use unhelpful >> protocols and/or smoke and mirrors to force idealist network >> design on >> others needs to end. People use new protocols because they are >> better. >> If the benefit of moving to a new protocol does not outweigh the >> pain >> of moving to it, people don't use it. That's why the OSI >> protocols did >> not kill IP like they were supposed to in the 90s, it is why the >> largely >> forgotten mandated move from Windows to secure OSes (ie, Unix) for >> all >> government employees never happened, and it is why IPv6 is >> sputtering. >> If people want to use NAT, they are going to use NAT. They may stop >> using it if the widespread adoption of peer to peer protocols >> means they >> are missing out on things other people are doing. They are not >> going to >> stop using NAT to use a protocol maliciously designed to break it; >> they >> will just wait, patiently and nearly always successfully, for >> somebody >> to come out with a version that has no such malice. They are >> certainly >> not going to stop using NAT because somebody tells them they >> should use >> a security protocol that does not secure anything worth securing. >> >> BitTorrent is a better anti-NAT tool than AH ever will be. More >> carrot, >> less stick. >> > > I agree. Folks are going to use ESP-NULL if they really want Integrity > Protection .. > > >> -Dave >> >> From dave at stayonline.com Tue May 26 19:23:42 2009 From: dave at stayonline.com (Dave Larter) Date: Tue, 26 May 2009 20:23:42 -0400 Subject: Why choose 120 volts? In-Reply-To: <200905270019.n4R0Jl0Z010462@aurora.sol.net> References: <20090526235142.GB869478@hiwaay.net> from "Chris Adams" at May 26, 2009 06:51:42 PM <200905270019.n4R0Jl0Z010462@aurora.sol.net> Message-ID: <8B79B73777E7D544A24BEB8FC50D35DB59804F@MERCURY.socrdu.com> See: http://www.3phasepower.org/3phasewiring.htm -----Original Message----- From: Joe Greco [mailto:jgreco at ns.sol.net] Sent: Tuesday, May 26, 2009 8:20 PM To: Chris Adams Cc: nanog at nanog.org Subject: Re: Why choose 120 volts? > Once upon a time, Joe Greco said: > > And I don't like not having anywhere to plug in my power screwdriver's > > recharger... I suppose I should see if I can find someplace that has > > a transformer of an appropriate size, or does anyone already have the > > part number for something that can provide a few hunderd milliamps of > > 120V from 208? :-) > > Isn't 208V usually provided as a connection across two phases of a 3 > phase circuit? In that case, you get 120V by going between one phase > and neutral (no transformer required). Yes, but this doesn't imply that you have access to those other phases. It is easy enough to be delivered 208V single phase service in a data center environment. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples. From vixie at isc.org Tue May 26 19:32:54 2009 From: vixie at isc.org (Paul Vixie) Date: Wed, 27 May 2009 00:32:54 +0000 Subject: Why choose 120 volts? In-Reply-To: <20090526220551.GA60909@ussenterprise.ufp.org> (Leo Bicknell's message of "Tue\, 26 May 2009 18\:05\:51 -0400") References: <4A1C455E.5080103@rollernet.us> <20090526220551.GA60909@ussenterprise.ufp.org> Message-ID: Leo Bicknell writes: >... > http://www.apcmedia.com/salestools/NRAN-6CN8PK_R0_EN.pdf >... > But what you'll find in the paper is that the change allows you to > re-architect the power plant in a way that saves you money on PDU's, > transformers, and other stuff. Thus this makes the most sense to > consider in a green field deployment. noting also that "architect" is a noun, i find that on large plants the cost of copper wire and circuit breakers add up, where sizes (and prices) are based on ampherage not wattage. in the old days when a rack needed 6kW, that was 208V 30A (10 gauge wire) or it was two of 120V 30A (also 10 gauge wire). somewhere near the first hundred or so racks, the price of the wire and breakers starts to seem high, and very much worth halving. once in a while some crashcart CRT monitor won't run on anything but 120V but for $50 NRC it can be replaced with an LCD. everything else that's still worth plugging in (that is, having a power/heat cost per performance better than that of a blow dryer) doesn't care what voltage it lives on. -- Paul Vixie KI6YSY From vixie at isc.org Tue May 26 19:34:06 2009 From: vixie at isc.org (Paul Vixie) Date: Wed, 27 May 2009 00:34:06 +0000 Subject: Colo on the West Coast In-Reply-To: <20fe625b0905261602x76a6c27dn377e9db3c6eada6e@mail.gmail.com> (Pshem Kowalczyk's message of "Wed\, 27 May 2009 11\:02\:04 +1200") References: <20fe625b0905261602x76a6c27dn377e9db3c6eada6e@mail.gmail.com> Message-ID: Pshem Kowalczyk writes: > (answers can be off-list) See . (updates still welcomed, btw.) -- Paul Vixie KI6YSY From jfbeam at gmail.com Tue May 26 19:50:39 2009 From: jfbeam at gmail.com (Ricky Beam) Date: Tue, 26 May 2009 20:50:39 -0400 Subject: Why choose 120 volts? In-Reply-To: <20090526235142.GB869478@hiwaay.net> References: <4A1C455E.5080103@rollernet.us> <200905262039.n4QKdU4g095452@aurora.sol.net> <20090526235142.GB869478@hiwaay.net> Message-ID: On Tue, 26 May 2009 19:51:42 -0400, Chris Adams wrote: > Isn't 208V usually provided as a connection across two phases of a 3 > phase circuit? In that case, you get 120V by going between one phase > and neutral (no transformer required). Indeed it is. If you want to see it yourself, measure the voltage between "hots" on different circuits. I see 208-212V depending on the legs (they aren't evenly loaded.) This is easier to do in a data center, but with a long extention cord it can be done with the office. :-) (of course, having the building wiring diagram(s) makes for a short hunt.) --Ricky From jfbeam at gmail.com Tue May 26 20:00:40 2009 From: jfbeam at gmail.com (Ricky Beam) Date: Tue, 26 May 2009 21:00:40 -0400 Subject: Why choose 120 volts? In-Reply-To: References: <4A1C455E.5080103@rollernet.us> <20090526220551.GA60909@ussenterprise.ufp.org> Message-ID: On Tue, 26 May 2009 20:32:54 -0400, Paul Vixie wrote: > once in a while some crashcart CRT monitor won't run on anything but 120V > but for $50 NRC it can be replaced with an LCD. everything else that's > still worth plugging in (that is, having a power/heat cost per > performance better than that of a blow dryer) doesn't care what voltage > it lives on. Or go to Radio Shack and get one of those "international traveler" power converter packs. I have a number of systems (ok, yes, they're old) that a) do not have autosensing power supplies (someone has to get a paperclip and flip a switch), and b) will not work on 208v -- 120 or 240, but not 208. --Ricky From ulf at Alameda.net Tue May 26 20:06:49 2009 From: ulf at Alameda.net (Ulf Zimmermann) Date: Tue, 26 May 2009 18:06:49 -0700 Subject: Why choose 120 volts? In-Reply-To: <4A1C455E.5080103@rollernet.us> References: <4A1C455E.5080103@rollernet.us> Message-ID: <20090527010649.GG51533@evil.alameda.net> On Tue, May 26, 2009 at 12:39:10PM -0700, Seth Mattinen wrote: > I have a pure curiosity question for the NANOG crowd here. If you run > your facility/datacenter/cage/rack on 120 volts, why? > > I've been running my facility at 208 for years because I can get away > with lower amperage circuits. I'm curious about the reasons for using > high-amp 120 volt circuits to drive racks of equipment instead of > low-amp 208 or 240 volt circuits. > > ~Seth I love 208V but I have to fight almost everytime with our datacenter provider. They got 50 or so "Colo's" which are all cookie cutter. Then there is our datacenter, the only facility where they can deliver 3-phase and monitor actual power usage. Everytime when we ask for 3-phase it is a fight now. Our latest circuits (50-amp although we won't use more than 16A under normal use (A+B load)), took me 9 months to get out of them. :-( -- Regards, Ulf. --------------------------------------------------------------------- Ulf Zimmermann, 1525 Pacific Ave., Alameda, CA-94501, #: 510-865-0204 You can find my resume at: http://www.Alameda.net/~ulf/resume.html From sethm at rollernet.us Tue May 26 20:24:20 2009 From: sethm at rollernet.us (Seth Mattinen) Date: Tue, 26 May 2009 18:24:20 -0700 Subject: Why choose 120 volts? In-Reply-To: <200905270019.n4R0Jl0Z010462@aurora.sol.net> References: <200905270019.n4R0Jl0Z010462@aurora.sol.net> Message-ID: <4A1C9644.6040408@rollernet.us> Joe Greco wrote: >> Once upon a time, Joe Greco said: >>> And I don't like not having anywhere to plug in my power screwdriver's >>> recharger... I suppose I should see if I can find someplace that has >>> a transformer of an appropriate size, or does anyone already have the >>> part number for something that can provide a few hunderd milliamps of >>> 120V from 208? :-) >> Isn't 208V usually provided as a connection across two phases of a 3 >> phase circuit? In that case, you get 120V by going between one phase >> and neutral (no transformer required). > > Yes, but this doesn't imply that you have access to those other phases. > It is easy enough to be delivered 208V single phase service in a data > center environment. > > ... JG Correct. I have a Smart-UPS RT connected across two legs of 3 phase for 208. The unit does not have a neutral, only ground, so it's 3 wires in and 3 out. The output is only 208 L-L with odd voltages on L-G. Since there's no neutral, it can only be used to drive 208 loads or a transformer for 120. ~Seth From jeffrey.lyon at blacklotus.net Tue May 26 22:12:54 2009 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Tue, 26 May 2009 23:12:54 -0400 Subject: The adventures of Team ARIN In-Reply-To: <4A1C0744.4010001@spaghetti.zurich.ibm.com> References: <4A1C0744.4010001@spaghetti.zurich.ibm.com> Message-ID: <16720fe00905262012o3d2ee4cn699a437d64bf3ca0@mail.gmail.com> At least now we know where all those fees end up. Jeff On Tue, May 26, 2009 at 11:14 AM, Jeroen Massar wrote: > Semi-Off-Topic here, I know, but it might help Network Operators to > explain certain misguided people and thus lower noise and raise signal > in various places. > > https://www.arin.net/knowledge/comic.html > > Short short synopsis: comic about how ARIN handles certain things and > what ARIN does etc. > > Greets, > ?Jeroen > > -- > Currently published issues: > > Issue 1 - The Beginning of Team ARIN > ----------------------------------------- > Synopsis: In issue 1, learn how Team ARIN was founded with the > assistance of Jon Postel. See how active participation by the entire > Internet community is key to Team ARIN's ?success as it endeavors to > facilitate the open and transparent, bottom-up policy development processes. > > Issue 2 - "FUD for Thought" > ----------------------------------------- > Synopsis: In issue 2, Team ARIN embarks on a mission to raise awareness > about the issue of depletion of the available pool of IPv4 addresses and > encounters a new enemy -- Agent FUD. Working for the "Bad Idea Force," > FUD is busy trying to spread fear, uncertainty, and doubt about IPv4 > address depletion. Using newly acquired technology, Team ARIN combines > forces to help combat this new enemy of the open and transparent > principles the Internet is based on, and in doing so creates something > more than even they expected! > > Issue 3 - "FUD 2.0 - Return of the FUD Factor!" > ----------------------------------------- > Synposis: Issue 3 begins with Team ARIN flying back from a conference > when they are alerted to a new problem and an old enemy. Agent FUD has > returned and this time he's seeking to undermine the Internet > community's migration to IPv6. Read the issue to find out how Team ARIN > saves the day and how you can help! > > > (s/synposis/synopsis/ by me, that typo is still on the original site, > rest of content all by ARIN, nothing I can do about, thus don't complain > to me ;) > > > -- Jeffrey Lyon, Leadership Team jeffrey.lyon at blacklotus.net | http://www.blacklotus.net Black Lotus Communications of The IRC Company, Inc. Look for us at HostingCon 2009 in Washington, DC on August 10th - 12th at Booth #401. From drais at icantclick.org Tue May 26 22:27:14 2009 From: drais at icantclick.org (david raistrick) Date: Tue, 26 May 2009 23:27:14 -0400 (EDT) Subject: Why choose 120 volts? In-Reply-To: <200905270019.n4R0Jl0Z010462@aurora.sol.net> References: <200905270019.n4R0Jl0Z010462@aurora.sol.net> Message-ID: On Tue, 26 May 2009, Joe Greco wrote: >> Once upon a time, Joe Greco said: >>> And I don't like not having anywhere to plug in my power screwdriver's >>> recharger... I suppose I should see if I can find someplace that has > Yes, but this doesn't imply that you have access to those other phases. > It is easy enough to be delivered 208V single phase service in a data > center environment. Uh. 208v single phase is functionally the same as 240v single phase. You grab 1 hot, neutral off the ground, and you have a common 110v circuit. Even if you're 3 phase to your PDU, it's still single phase to the servers. (specialty gear excluded, but those generally plug direct to the circuit, not to a PDU). This makes it very very easy to solve this problem, and I keep a few of these floating around at all of my datacenters, with big labels saying who they belong too. (ignoring the fact that for drill charging at least there's usually house power available, but crash carts need these...) C14 (M) to 5-15 (F) adaptor cable: http://www.cdw.com/shop/products/default.aspx?edc=1036852 I also use them to run wall warts, etc, as needed. --- david raistrick http://www.netmeister.org/news/learn2quote.html drais at icantclick.org http://www.expita.com/nomime.html From lsc at prgmr.com Tue May 26 23:02:46 2009 From: lsc at prgmr.com (Luke S Crawford) Date: 27 May 2009 00:02:46 -0400 Subject: Why choose 120 volts? In-Reply-To: <4A1C455E.5080103@rollernet.us> References: <4A1C455E.5080103@rollernet.us> Message-ID: Seth Mattinen writes: > I have a pure curiosity question for the NANOG crowd here. If you run > your facility/datacenter/cage/rack on 120 volts, why? I've spent the last several days going back and forth with salespeople, trying to find a rack with 208v power in the south bay, or a cheap 100M connection from market post tower to heraklesdata in Sacramento. (where I have cheap 208v power) From what I see, most places in the bay area just can't handle the kind of heat density that a 30a 208v circuit per rack would bring. (they won't sell me more than 2 20A 120v circuits, either, and many will only sell me a single 15a circuit per rack. I assume that's an effort to keep the heat output within cooling system capabilities.) But that still doesn't explain why they don't hand out 10a 208v circuits. I've also seen employers pick 208v over 120v even after I pointed out the cost per watt advantages of 208v, even without counting efficiency gains. In one case they provisioned one rack with 208v, because the vendor of some particularly expensive bit of equipment recommended it, then they left all the commodity servers on 120v. Why didn't they put everything on 208v? I pointed out that the cost per watt was lower. Maybe I blew my credibility by wanting to research 48v power supplies for our kit before that? (it was a telco facility, after all, and I was young.) 30a 208v is about perfect for a rack, if you ask me. (I imagine the guys who have to deal with cooling feel differently, but at my scale, that's all priced into the power.) -- Luke S. Crawford http://prgmr.com/xen/ - Hosting for the technically adept We don't assume you are stupid. From randy at psg.com Tue May 26 23:19:55 2009 From: randy at psg.com (Randy Bush) Date: Wed, 27 May 2009 13:19:55 +0900 Subject: The adventures of Team ARIN In-Reply-To: <4A1C0744.4010001@spaghetti.zurich.ibm.com> References: <4A1C0744.4010001@spaghetti.zurich.ibm.com> Message-ID: > https://www.arin.net/knowledge/comic.html > > Short short synopsis: comic about how ARIN handles certain things and > what ARIN does etc. imiho, an embarrassment to arin and to the internet randy From jgreco at ns.sol.net Tue May 26 23:30:59 2009 From: jgreco at ns.sol.net (Joe Greco) Date: Tue, 26 May 2009 23:30:59 -0500 (CDT) Subject: Why choose 120 volts? In-Reply-To: from "david raistrick" at May 26, 2009 11:27:14 PM Message-ID: <200905270430.n4R4UxCI022956@aurora.sol.net> > On Tue, 26 May 2009, Joe Greco wrote: > >> Once upon a time, Joe Greco said: > >>> And I don't like not having anywhere to plug in my power screwdriver's > >>> recharger... I suppose I should see if I can find someplace that has > > > Yes, but this doesn't imply that you have access to those other phases. > > It is easy enough to be delivered 208V single phase service in a data > > center environment. > > Uh. 208v single phase is functionally the same as 240v single phase. Yes, functionally, it is. > You grab 1 hot, neutral off the ground, and you have a common 110v > circuit. Even if you're 3 phase to your PDU, it's still single phase to > the servers. (specialty gear excluded, but those generally plug direct to > the circuit, not to a PDU). Go tell your electrical inspector that you're using the ground as a neutral. I'll make the popcorn ... put simply, that's not allowed, for Very Good Reasons. > This makes it very very easy to solve this problem, No it doesn't, and the following doesn't even seem to relate: > and I keep a few of > these floating around at all of my datacenters, with big labels saying who > they belong too. (ignoring the fact that for drill charging at least > there's usually house power available, but crash carts need these...) > > C14 (M) to 5-15 (F) adaptor cable: > > http://www.cdw.com/shop/products/default.aspx?edc=1036852 > > I also use them to run wall warts, etc, as needed. Great, you're the latest person to invent a way to present a 5-15R that offers something besides 120VAC. This is neither new nor novel, but it *is* dangerous and risky, and in no way "solves the problem." Plugging a device that is designed to run on 120V into 208V will probably result in (at least!) one of: 1) smoke 2) fire 3) burning components 4) dead device 5) burning batteries (in the case of the aforementioned charger) 6) general excitement and panic in the data center in the event that none of the above happen immediately, but rather some time after you leave. 7) etc. The basic problem here is that there are still many devices out there that do not have autoranging power supplies. As for "for drill charging at least there's usually house power available", well, that sucks. We're at Equinix. There are periods where no one uses the drill, or the power screwdriver, for months at a time. With 120V in the cage, I left the chargers hooked up and trickle charging. Neither the drill nor the power screwdriver have autoranging power supplies. So now with 208V, someone has to bring along batteries, because we can't leave them on-site, or they'll go stale. Bleh. ... 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 oliver.hookins at anchor.com.au Tue May 26 23:43:43 2009 From: oliver.hookins at anchor.com.au (Oliver Hookins) Date: Wed, 27 May 2009 14:43:43 +1000 Subject: Checking bogon status of new address space In-Reply-To: References: <20090508053336.GC7171@captain.bridge.anchor.net.au> Message-ID: <20090527044343.GA7202@captain.bridge.anchor.net.au> Thanks for all your suggestions on this topic. For what it's worth, I attempted a few of the suggestions as well as my own idea and documented the outcomes here: http://www.anchor.com.au/blog/2009/05/testing-your-connectivity/ In summary, there's no definitive method for testing your connectivity is perfect (obviously) but I was able to determine (hopefully with reasonable accuracy) that there are a significant amount of ASs out there not reachable from our new address space, at least by IPv4 ICMP. -- Regards, Oliver Hookins Anchor Systems From oliver.hookins at anchor.com.au Tue May 26 23:47:40 2009 From: oliver.hookins at anchor.com.au (Oliver Hookins) Date: Wed, 27 May 2009 14:47:40 +1000 Subject: Out of warranty APC PDU repair Message-ID: <20090527044740.GB7202@captain.bridge.anchor.net.au> Hi all, hopefully this isn't too off topic (since it's datacentre related). We have an APC AP7952 rack PDU which has stopped working. I believe the management module is faulty, and it is about 5 years old. APC don't service these outside of warranty at all so I'm trying to find a 3rd-party repairer. So far APC doesn't seem to understand this concept. Can anyone suggest a company that would work on these units in Sydney, Australia or nearby? -- Regards, Oliver Hookins Anchor Systems From oberman at es.net Wed May 27 00:09:26 2009 From: oberman at es.net (Kevin Oberman) Date: Tue, 26 May 2009 22:09:26 -0700 Subject: The adventures of Team ARIN In-Reply-To: Your message of "Wed, 27 May 2009 13:19:55 +0900." Message-ID: <20090527050926.318F51CC0D@ptavv.es.net> > Date: Wed, 27 May 2009 13:19:55 +0900 > From: Randy Bush > > > https://www.arin.net/knowledge/comic.html > > > > Short short synopsis: comic about how ARIN handles certain things and > > what ARIN does etc. > > imiho, an embarrassment to arin and to the internet Initially I thought the same thing, but the feedback from the large number of totally clueless ARIN "customers" has been overwhelmingly positive. Clearly, the comic book was never intended for the typical subscriber to this list. -- 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 barton at gnaps.com Wed May 27 01:14:36 2009 From: barton at gnaps.com (Barton F Bruce) Date: Wed, 27 May 2009 02:14:36 -0400 Subject: Why choose 120 volts? References: <4A1C455E.5080103@rollernet.us> Message-ID: <7146FDBEA553474AB208040423DAB619@bvsupport> Seth Mattinen wrote: I have a pure curiosity question for the NANOG crowd here. If you run your facility/datacenter/cage/rack on 120 volts, why? I've been running my facility at 208 for years because I can get away with lower amperage circuits. I'm curious about the reasons for using high-amp 120 volt circuits to drive racks of equipment instead of low-amp 208 or 240 volt circuits And you have been doing something that is a right step in the right direction, but may well not be the best ultimate solution. Lets half ignore codes. Not to be illegal, but they CAN be changed and you can often get specific exceptions if you are not just in the back room of an office but are in a clearly professionally managed facility with well trained staff plugging in equipment. Every time I look at a nameplate and I see 100-250VAC I get very frustrated. If only that had been perhaps 100-300VAC, I could then run it on 277VAC and that is especailly nice for many reasons. Most large USA buildings already have 277 and probably all their flourescent lighting is run off it (277VAC ballasts are readily available and what look like rats-ass wall switches but are higher rated ones are readily available - both even at home despot if you look hard enough), so nothing terribly new has to be learned by electricians, etc. 277 is the phase leg to NEUTRAL voltage of a 277/480 WYE system that most everything except small human plugged appliances use in any but the very largest USA office building. It is what typically comes in from the power company. 120/208 is the output of typically a delta/wye transformer that steps that down for the dumb humans to safely use and you are paying the penalty of the WHOLE LOAD having to go through a second less than 100% efficient transformer. The beauty of 277 is that on a single breaker pole (unlike 208 where you are most likely to have 2 HOT legs and need a 2 pole simultaneous trip breaker) on reasonable size branch circuits that you are still allowed to plug MULTIPLE loads into without individual fuses or breakers (that is "allowed to" - you may chose to protect each outlet in the rack, but that is not compulsory) you get 277/120=2.31 times as much power available. Sadly routers, servers, switches, etc. typically are rated to 250VAC, so using raw 277 won't work. But let us see how close HP/IBM/ACP and many many others are getting still using ONE breaker pole per much more efficient branch circuit. NB that as you go to larger branch circuits in AMPS, you MUST be supplying just ONE load or MUST have additioanl breakers or fuses as you split it up. We all know 120/208 and 277/480. What about another NEW pair of voltages in WYE connection! Lets use 240/415. It is exactly twice 120/208 (well it is not stated as 240/416 I'd guess since 240 x 1.73259 = 415.82 they just truncate rather than round - though 2400/4160 is a standard designation...) and is inside the 250V max rating of the switching power supplies. It still uses a single breaker pole. Your get EXACTLY twice as much power out of a 240/415 WYE branch circuit as you would out of a 120/208 at the same AMPs. But you may save a transformer and its continuous power waste or at least part of it in between. How do you get to 240/415 is the next issue. If you have 2400/4160 or 7,960/13,800 primary into your building, and you do all your own transformers, getting 240/415(6) can be a single transformer step for you, and you will probably have many transformers so can also create seperate 277/480 for modest size AC inits and lighting, While LARGE chillers can be ordered at the higher voltages, and for the relatively small amount of 120/208 you probably should come off 277/480 into standard 120/208 delta wye transformers because normal electricians can do that rather then the 13K gods($$$$). But if you are a smaller building the only voltage that makes sense that the utility is supporting is 277/480. Rather than take all your rack power through another transformer step with the losses and the extra heat to eject from the building, consider instead using buck (as in the classic BOOST/BUCK transformers) to knock that 277/480 down to 240/415. It can be packaged as a 3 phase unit for less than three singles, and will be smaller and less costly to have wired up, but the three singles may be available from stock. It is the same sort of device you must have in front of a load that needs 240 or 250 and can't handle 208, but in that case is wired BOOSTING rather than BUCKING. FWIW an electric range burner or a hot water heater element rated for 240 produces EXACTLY 75% of the heat if run on 208 (go do the math...), but you should NOT use boost bucks for such a simple situation because optional heating elements can be ordered originally OR bought as replacements for less than $10 each and easily replaced in the field to give the original 240 rated wattage on 208 supply. In any case the 3 phase buck transformer VA rating will just need to be 3 x (277-240) x per-phase-AMPs on the load side. Or look at it this way: 37/240 = 15.4% to just buck rather than the KVA of a transformer dropping the whole load. Remember the buck transformer's secondary in this case simply is 37 volts and is wired in series but 180 degrees out of phase so drops the 277 to 240VAC But maybe that isn't wizest in the big picture but may work for you. If you are into really big systems you really need folks that know what they are doing. Those that simply tell you to buy K rated transformers may be missing a slick opportunity to knock out power factor problems caused by triplen harmonics related to the multigrounded neutral system. So you may not want to BUCK, but instead use an exceptional transformer SYSTEM. Look at these folks (this is just one PDF, they have plenty more, and a few dollars more spent with them can bring a rapid ROI just on power factor savings alone on the utility bill let alone the dramatically lower transformer losses) : http://mirusinternational.com/downloads/CAT-EC01-08-F10a_w.pdf NB that one of their tricks is to have the load split to separate outputs with different phase shifts within these special transformers so the troublesome harmonics are canceled and not reflected back into the primary. Even though newer power supplies will be more efficient and better power factor corrected that years ago, this is still an issue to be very aware of. Anyway, GOOGLE for 415 volts or 240/415 and these days you will find many hits from big names you already know. Maybe any "issues" with local codes can be solved or already have been. Some folks have been bucking down from 277 to more like 250 for years (to neutral, so single breaker) with the local inspector staying totally clueless at to what was "accidentally" happening. He was probably aware of plugged in PDUs with integral 277/480 to 120/208 DeltaWye transformers in use so probably assumed a lot of the higher voltage breaker panels were feeding more of that. A 30 amp 3 phase feed at 240/415 to a big power strip with 15 or 20 amp breakers for smaller groups of single phase IEC outlets is a STANDARD product from multiple sources and at the 80% allowed loading provides 240 x 30 x 3 x .8 = 17,280 VA and just two of these feeds gets you to almost 35 KVA per cabinet that drives folks to liquid CO2 cooling systems that can easily function in a datacenter without a raised floor, and do it without CRAC created hurricanes or huge air ducts trying to cool the room and failing. NB that such a power strip using IEC outlets uses EXACTLY the same cords as you would use for 120VAC - nothing weird other than NOONE is using the "WEIRD" North American plugs and outlets Well, almost. The power strip could be built for BOTH 120/208 AND 240/415 and would require NO outlet changes. Breakers, shoild be picked for the higher voltage. IEC outlets in these voltages are THE SAME - they just change between 15 and 20 amps and there are specials for high temperature usage. The one thing that should be done is to be sure be to use S cord rather than SJ cord (600V class vs 300V class - well even better use the "O"il option too, simply because it lasts a lot longer - SO cord) - or use a plastic equivalent for any cords carring more than one HOT from 240/415. The old code allowed 42 poles per breaker panel. That would be 7 cabinets worth of just these handy size 30 amp 3 phase feeds for 241920 VA total - almost 1/4 of a megawatt. Bigger branch circuit amps can give you a lot more, obviously, but short of going to Square-D I Line panels, you probably don't want much more load than this in a typical breaker panel. It would be "nice" to have the two 30 amp 240/415 WYE feeds to any cabinet be fed from the SAME breaker numbers in two totally separate breaker panels, and each server's power supplies split between the two branch circuits. Just be VERY VERY certain you check each device as there are still some 120 volt ONLY devices some idiot will want to plug in. Three phase isn't all that weird.. Keeping it simple, if you have three separate coils on a generator that each produce AC 120 degrees out of phase with each other, and connect one end of each coil to a single grounded point called "neutral" , you WON'T have twice the single coil voltage between any two of the other ends of the coils (the HOT wires), but have the square root of 3 times it instead because they are not a full 180 degrees out of phase the way single phase house power is, or two flash cells that when you ground the center connection between the cells and call it neutral, you will find 3 volts between the ends of the two cell battery and 1.5 from that middle to either end BUT with opposite polarity.from the center. The sign waves coming out of that 3 phase generator peak in succession at each hot leg in turn, and a three phase motor will reverse direction if you swap any two of the three wires. Just as on a single phase neutral where you can reduce the neutral current to ZERO if you have two identical resistive loads (ie non reactive) from each hot leg to neutral, so can you if you have three identical resistive loads each on one of the three phase hot legs to neutral. If you put one of those resistive loads on just one phase leg, obviously the NEUTRAL has the same current as the one in use phase leg. The trick question is how much is on neutral if you had just two of the three resistors connected. Think of it this way. If all three are on, neutral has ZERO amps. cut ONE off, and you just CHANGED what is on neutrasl by one resistor's worth of current. When we remove that resistor from the common neutral wire that was reading ZERO amps, we will get a one amp reading on neutral. If we were to turn that resistor back on and shut OFF the other two, we would also get 1 amp on neutral, BUT there would be an exact 180 degree phase shift if we were watching the two currents on a scope. Together they cancel. But but but why 180 when 3 phases are all 120 degrees apart? Those two other legs ARE 120 degrees apart and each 120 apart from the third leg, but those two 120 degrees apart currents sum to being 180 degrees from the third leg (still assuming each resistor is indentical). Anything other than resistors and current may lead or lag voltage and harmonics may add in ugly ways so neutral current can easily exceed that on any phase leg and thus we have all the power factor issues and charges from utilities and mandates for better power factor corrected supplies and codes dictating over sized neutrals where switching power supplies abound. I was cheerily suggesting hot leg to neutral WYE (aka STAR) connections ( and I still do!). But actually those using two hot pole branch circuits ( or two hots of a three phase branch ciruuit broken into many smaller two wire 208 ones ) are NOT using the neutral at all in each of those SINGLE PHASE connections and avoid the triplen harmonic currents summing in the neutral, and can also still use the neutral for small random 120V loads but need not oversize the neutral. Actually any load including three phase DELTA stuck across there that avoids the neutral avoids the harmonics issues. I was just using the 208 single phase loads because they seemed to have been used more than I had suspected. Using a three phase branch circuit (say 30 amps as that would be a handys size, but DOES NOT MATTER here) at 120/208 - whether you are using it as 3 120 volt circuits or 3 208 volt circuits ( as EACH of those connection options gets EXACTLY the same max power out of the circuit!!!) gives you EXACTLY 1/2 the power you could get from the same ampere circuit running 240/415 (which would normally ONLY be running phase to neutral loads at 240V, but were 415 volt capable devices available you still get the same total out - EXACTLY twice what the 120/208 can deliver). NOTE that I carefully was refering to 4 wire 3 phase legs and a neutral for these example branch circuits. IF you are comparing two wire single phase circuits from the breaker panel to the cabinet (how silly! unless it is from a PDU in an adjacent cabinet), 208 volts gets you about 13% less power on your two wires than you could get at the same amperage on a 2 wire circuit at 240 volts. Whether those wires are both hots or a hot and a neutral makes no matter as it is simply the voltage between those two wires times max allowed amps (80% of branch ckt rating) that determines what you can get out. A switching supply simply sucks more amps at lower input voltage so gets the power it needs in either case, but you can inflict a larger load at the higher voltage. Thus 240/415 (240/416...) DELIVERS twice what 120/208 does amp for amp with full three phase wiring, and that is why it is so great. From joelja at bogus.com Wed May 27 01:19:59 2009 From: joelja at bogus.com (Joel Jaeggli) Date: Tue, 26 May 2009 23:19:59 -0700 Subject: Out of warranty APC PDU repair In-Reply-To: <20090527044740.GB7202@captain.bridge.anchor.net.au> References: <20090527044740.GB7202@captain.bridge.anchor.net.au> Message-ID: <4A1CDB8F.8030600@bogus.com> Oliver Hookins wrote: > Hi all, hopefully this isn't too off topic (since it's datacentre related). > > We have an APC AP7952 rack PDU which has stopped working. I believe the > management module is faulty, and it is about 5 years old. APC don't service > these outside of warranty at all so I'm trying to find a 3rd-party repairer. > So far APC doesn't seem to understand this concept. The mangement module is a tiny 486 equivalent embedded linux box, I'm not sure there's actually much to repair in there. > Can anyone suggest a company that would work on these units in Sydney, > Australia or nearby? > From barton at gnaps.com Wed May 27 02:23:44 2009 From: barton at gnaps.com (Barton F Bruce) Date: Wed, 27 May 2009 03:23:44 -0400 Subject: Out of warranty APC PDU repair References: <20090527044740.GB7202@captain.bridge.anchor.net.au> Message-ID: <188B6AD8C7954960BBBB24B5A18E1546@bvsupport> ----- Original Message ----- From: "Oliver Hookins" To: Sent: Wednesday, May 27, 2009 12:47 AM Subject: Out of warranty APC PDU repair > Hi all, hopefully this isn't too off topic (since it's datacentre > related). > > We have an APC AP7952 rack PDU which has stopped working. I believe the > management module is faulty, and it is about 5 years old. APC don't > service > these outside of warranty at all so I'm trying to find a 3rd-party > repairer. > So far APC doesn't seem to understand this concept. > > Can anyone suggest a company that would work on these units in Sydney, > Australia or nearby? One company here in the USA that might talk you through figuring out what is wrong and then can supply repair pars is Gruber Power Services in Phoenix. Google for GRUBER POWER as they have several domains , though www.gruber.com probably will work, too. They are one division of Gruber out there that also custom builds fiber jumpers and makes custom rack shelves and makes 1U 24 and 32 port RJ45 to variously wired 25 and 32 pair champ connectors. and a myriad of other things. They buy refurbish and sell LARGE UPSes and related gear of many brands. Also have good prices on UPS batteries for folks here in the USA in spite of UnitedParcelService shipping prices... If you are ordering pallet loads, truck becomes very attractive. Small quantities, use their EBAY store as it is very automated and they give you a slightly better price that way on small orders. Good folks! We did a site inspection of their facilities years ago right after a Nanog meeting that was in Scottsdale. By then they were already making several custom things for us and we were delighted to see where it all came from. They are flexible and versitile and like doing custom projects. They can easily do custom punched and bent, drilled, tapped, etc steel or aluminum "things" (typically RACK hardware) that can be left raw metal or powder coated. Best price is NOT at some 10/50/110 like step but is related to how many they can make of that item out of each standard sheet of incoming metal. For example, they custom made us dense 96 port OC-48 BNC panels in 19" and shorter in 23" sizes. D shaped holes and we let idle NOC fingers load bulk bought 75 ohm insulated BNC feed-throughs when and as needed. VASTLY less expensive than commercial offerings. Also got a lot of 1U 16 hole blanks as we just string 8 pack of 735 cable to a customer's racktop if they need T3s. That will take two such cables. Unless they have a lot of RAS boxes that need many T3s, most anyone else will prefer OC-x if they are getting much more capacity than that. Anyway, I hope they can help with your problem and it is INTERESTING to hear how long or how short APC chooses to support users... From oliver.hookins at anchor.com.au Wed May 27 02:27:47 2009 From: oliver.hookins at anchor.com.au (Oliver Hookins) Date: Wed, 27 May 2009 17:27:47 +1000 Subject: Out of warranty APC PDU repair In-Reply-To: <300110C5A06E4ACEAB11F9AE149E10DF@bvsupport> References: <20090527044740.GB7202@captain.bridge.anchor.net.au> <300110C5A06E4ACEAB11F9AE149E10DF@bvsupport> Message-ID: <20090527072747.GC7202@captain.bridge.anchor.net.au> On Wed May 27, 2009 at 03:17:24 -0400, Barton F Bruce wrote: > *This message was transferred with a trial version of CommuniGate(r) Pro* > > ----- Original Message ----- From: "Oliver Hookins" > > To: > Sent: Wednesday, May 27, 2009 12:47 AM > Subject: Out of warranty APC PDU repair > >> Hi all, hopefully this isn't too off topic (since it's datacentre >> related). >> >> We have an APC AP7952 rack PDU which has stopped working. I believe the >> management module is faulty, and it is about 5 years old. APC don't >> service >> these outside of warranty at all so I'm trying to find a 3rd-party >> repairer. >> So far APC doesn't seem to understand this concept. >> >> Can anyone suggest a company that would work on these units in Sydney, >> Australia or nearby? > > One company here in the USA that might talk you through figuring out what > is wrong and then can supply repair pars is Gruber Power Services in > Phoenix. > > Google for GRUBER POWER as they have several domains , though > www.gruber.com probably will work, too. > > They are one division of Gruber out there that also custom builds fiber > jumpers and makes custom rack shelves and makes 1U 24 and 32 port RJ45 to > variously wired 25 and 32 pair champ connectors. and a myriad of other > things. They buy refurbish and sell LARGE UPSes and related gear of many > brands. Also have good prices on UPS batteries for folks here in the USA > in spite of UnitedParcelService shipping prices... If you are ordering > pallet loads, truck becomes very attractive. Small quantities, use their > EBAY store as it is very automated and they give you a slightly better > price that way on small orders. > > Good folks! We did a site inspection of their facilities years ago right > after a Nanog meeting that was in Scottsdale. By then they were already > making several custom things for us and we were delighted to see where it > all came from. > > They can easily do custom punched and bent, drilled, tapped, etc steel or > aluminum "things" (typically RACK hardware) that can be left raw metal or > powder coated. Best price is NOT at some 10/50/110 like step but is > related to how many they can make of that item out of each standard sheet > of incoming metal. For example, they custom made us dense 96 port OC-48 > BNC panels in 19" and shorter in 23" sizes. D shaped holes and we let > idle NOC fingers load bulk bought 75 ohm insulated BNC feed-throughs when > and as needed. VASTLY less expensive than commercial offerings. Also got > a lot of 1U 16 hole blanks as we just string 8 pack of 735 cable to a > customer's racktop if they need T3s. That will take two such cables. > Unless they have a lot of RAS boxes that need many T3s, most anyone else > will prefer OC-x if they are getting much more capacity than that. > > Anyway, I hope they can help with your problem and it is INTERESTING to > hear how long or how short APC chooses to support users... Being as we are in Sydney, Australia and Gruber is in Phoenix, Arizona, USA, I don't think it'll be the most convenient arrangement. I just received a reply from APC saying even the warranty replacements don't get repaired. I guess there's a landfill somewhere full of faulty PDUs... -- Regards, Oliver Hookins Anchor Systems From karnaugh at karnaugh.za.net Wed May 27 02:44:13 2009 From: karnaugh at karnaugh.za.net (Colin Alston) Date: Wed, 27 May 2009 09:44:13 +0200 Subject: Why choose 120 volts? In-Reply-To: <074b01c9de43$1dae5830$590b0890$@net> References: <4A1C455E.5080103@rollernet.us> <074b01c9de43$1dae5830$590b0890$@net> Message-ID: <4A1CEF4D.7050200@karnaugh.za.net> On 2009/05/26 10:46 PM Aaron Wendel wrote: > Last time I looked at my bill I was being billed by the kWh P=V*I From braaen at zcorum.com Wed May 27 07:22:46 2009 From: braaen at zcorum.com (Brian Raaen) Date: Wed, 27 May 2009 08:22:46 -0400 Subject: Why choose 120 volts? In-Reply-To: <4A1C5591.1080309@ieee.org> References: <4A1C455E.5080103@rollernet.us> <20090526201929.GA41317@typo.org> <4A1C5591.1080309@ieee.org> Message-ID: <4A1D3096.4020805@zcorum.com> As a Holder of two different FCC licenses I can tell you voltage is not what kills, it is amps and location that kill. Actually in certain cases as long at you have good electrical isolation, high enough dielectric breakdown voltage, and good grounding higher voltages can be safer and more efficient. Also, Thomas Edison was the one that discovered that trying to deliver DC more than a few feet was not a good idea. -- ----------------- Brian Raaen Network Engineer email: /braaen at zcorum.com/ FCC GROL (General Radiotelephone Operators License) FCC Amateur Extra Class KG4CXN (Also certified volunteer examiner with CAVAC and ARRL) Alex H. Ryu wrote: > Also, adding followings. > > 5) availability from local power provider(s) > > 6) local regulation such as fire department safety rules... > > 7) for your own safety... (120V may not kill people, but 240V can do...) > > > If you want better, why not just have everything to DC power ? > Something like 48V... > > Alex > > > Wayne E. Bouchard wrote: > >> 1) Equipment used to not be dual voltage >> >> 2) For smaller scale, 120V UPS and distribution equipment is usually >> cheaper >> >> 3) 120V embedded itself into operations as a result. >> >> 4) We're all lazy and hate change. >> >> On Tue, May 26, 2009 at 12:39:10PM -0700, Seth Mattinen wrote: >> >> >>> I have a pure curiosity question for the NANOG crowd here. If you run >>> your facility/datacenter/cage/rack on 120 volts, why? >>> >>> I've been running my facility at 208 for years because I can get away >>> with lower amperage circuits. I'm curious about the reasons for using >>> high-amp 120 volt circuits to drive racks of equipment instead of >>> low-amp 208 or 240 volt circuits. >>> >>> ~Seth >>> >>> >> --- >> Wayne Bouchard >> web at typo.org >> Network Dude >> http://www.typo.org/~web/ >> >> >> >> >> > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: braaen.vcf Type: text/x-vcard Size: 217 bytes Desc: not available URL: From dhetzel at gmail.com Wed May 27 08:28:13 2009 From: dhetzel at gmail.com (Dorn Hetzel) Date: Wed, 27 May 2009 09:28:13 -0400 Subject: Why choose 120 volts? In-Reply-To: <4A1D3096.4020805@zcorum.com> References: <4A1C455E.5080103@rollernet.us> <20090526201929.GA41317@typo.org> <4A1C5591.1080309@ieee.org> <4A1D3096.4020805@zcorum.com> Message-ID: <7db2dcf90905270628v25522721ic4d3cdc54384c6dd@mail.gmail.com> The early problems with distance transmission of DC really didn't have anything to do with the inherent properties of DC current, but with the fact that, at the time, there was no good way to convert DC voltages up and down in a similar fashion to the function performed by transformers with AC. The inability to step DC up to high voltage for distant transmission was the real killer for early use of DC. Lately, very high voltage DC is actually a better performer than AC for some long distance transmission situations. In particular, DC can be used to move power between unsynchronized grids without the usual problems, and to transmit power through undersea cables, where AC capacitance losses would add up. See: http://en.wikipedia.org/wiki/High-voltage_direct_current#Advantages_of_HVDC_over_AC_transmission The main thing that has changed since the early days is that much better semiconductors are available to make the voltage conversion feasible... -Dorn 2009/5/27 Brian Raaen : > As a Holder of two different FCC licenses I can tell you voltage is not > what kills, it is amps and location that kill. Actually in certain cases > as long at you have good electrical isolation, high enough dielectric > breakdown voltage, and good grounding higher voltages can be safer and > more efficient. Also, Thomas Edison was the one that discovered that > trying to deliver DC more than a few feet was not a good idea. > > -- > ----------------- > Brian Raaen > Network Engineer > email: /braaen at zcorum.com/ > FCC GROL (General Radiotelephone Operators License) > FCC Amateur Extra Class KG4CXN (Also certified volunteer examiner with > CAVAC and ARRL) > > Alex H. Ryu wrote: >> Also, adding followings. >> >> 5) availability from local power provider(s) >> >> 6) local regulation such as fire department safety rules... >> >> 7) for your own safety... (120V may not kill people, but 240V can do...) >> >> >> If you want better, why not just have everything to DC power ? >> Something like 48V... >> >> Alex >> >> >> Wayne E. Bouchard wrote: >> >>> 1) Equipment used to not be dual voltage >>> >>> 2) For smaller scale, 120V UPS and distribution equipment is usually >>> cheaper >>> >>> 3) 120V embedded itself into operations as a result. >>> >>> 4) We're all lazy and hate change. >>> >>> On Tue, May 26, 2009 at 12:39:10PM -0700, Seth Mattinen wrote: >>> >>> >>>> I have a pure curiosity question for the NANOG crowd here. If you run >>>> your facility/datacenter/cage/rack on 120 volts, why? >>>> >>>> I've been running my facility at 208 for years because I can get away >>>> with lower amperage circuits. I'm curious about the reasons for using >>>> high-amp 120 volt circuits to drive racks of equipment instead of >>>> low-amp 208 or 240 volt circuits. >>>> >>>> ~Seth >>>> >>>> >>> --- >>> Wayne Bouchard >>> web at typo.org >>> Network Dude >>> http://www.typo.org/~web/ >>> >>> >>> >>> >>> >> >> >> > From gb10hkzo-nanog at yahoo.co.uk Wed May 27 08:48:39 2009 From: gb10hkzo-nanog at yahoo.co.uk (gb10hkzo-nanog at yahoo.co.uk) Date: Wed, 27 May 2009 06:48:39 -0700 (PDT) Subject: MX Record Theories Message-ID: <768499.91907.qm@web24713.mail.ird.yahoo.com> Mark, > A EDNS referral from the root servers to the COM servers > already exceeded 512 bytes. The world hasn't fallen over. Actually, I was thinking to myself yesterday that the email world is going to be awfully fun when IPv6 sets in and we're all running mail servers with nice long AAAA records such as fc00:836b:4917::a180:4179. :) From gb10hkzo-nanog at yahoo.co.uk Wed May 27 08:50:08 2009 From: gb10hkzo-nanog at yahoo.co.uk (gb10hkzo-nanog at yahoo.co.uk) Date: Wed, 27 May 2009 06:50:08 -0700 (PDT) Subject: No subject Message-ID: <748790.13847.qm@web24716.mail.ird.yahoo.com> > fc00:836b:4917::a180:4179 And yes, before anyone points out, I just realised I posted an abbreviated example. :) From peter at peter-dambier.de Wed May 27 09:20:06 2009 From: peter at peter-dambier.de (Peter Dambier) Date: Wed, 27 May 2009 16:20:06 +0200 Subject: Why choose 120 volts? In-Reply-To: <4A1D3096.4020805@zcorum.com> References: <4A1C455E.5080103@rollernet.us> <20090526201929.GA41317@typo.org> <4A1C5591.1080309@ieee.org> <4A1D3096.4020805@zcorum.com> Message-ID: <4A1D4C16.1000905@peter-dambier.de> Brian Raaen wrote: > As a Holder of two different FCC licenses I can tell you voltage is not > what kills, it is amps and location that kill. Actually in certain cases > as long at you have good electrical isolation, high enough dielectric > breakdown voltage, and good grounding higher voltages can be safer and > more efficient. Also, Thomas Edison was the one that discovered that > trying to deliver DC more than a few feet was not a good idea. > Hi Brian, as a Radio Amateur you should know AC radiates, DC not. We did have really big trouble when when an ocean liner had to pass under a cable bridge and for the passage, that cable bridge had to be grounded. Eddies running through the grid brought half of the grid down. The other half killed my computer with overvoltage. Hydro Que'bec is running DC from the northpole down to South Florida. http://www.abb.com/cawp/gad02181/c1256d71001e0037c12568340029b5c4.aspx?&opendatabase&v=17ea&e=us&m=100a& Apropos, I remember a frenchman who fed his personal computer 288 Volts DC. Theory says no matter whether the setting of the powersupply is 120 AC ord 240 AC it should work. Try at your own risk. I haven't :) Kind regards Peter DL2FBA -- Peter and Karin Dambier Cesidian Root - Radice Cesidiana Rimbacher Strasse 16 D-69509 Moerlenbach-Bonsweiher +49(6209)795-816 (Telekom) +49(6252)750-308 (VoIP: sipgate.de) mail: peter at peter-dambier.de http://www.peter-dambier.de/ http://iason.site.voila.fr/ https://sourceforge.net/projects/iason/ ULA= fd80:4ce1:c66a::/48 From mike at mtcc.com Wed May 27 09:35:15 2009 From: mike at mtcc.com (Michael Thomas) Date: Wed, 27 May 2009 07:35:15 -0700 Subject: Why choose 120 volts? In-Reply-To: <4A1D4C16.1000905@peter-dambier.de> References: <4A1C455E.5080103@rollernet.us> <20090526201929.GA41317@typo.org> <4A1C5591.1080309@ieee.org> <4A1D3096.4020805@zcorum.com> <4A1D4C16.1000905@peter-dambier.de> Message-ID: <4A1D4FA3.5030700@mtcc.com> Peter Dambier wrote:> > Apropos, I remember a frenchman who fed his personal computer 288 Volts DC. Gives a whole new meaning to "French Fries" :) Mike, sorry From beckman at angryox.com Wed May 27 11:03:54 2009 From: beckman at angryox.com (Peter Beckman) Date: Wed, 27 May 2009 12:03:54 -0400 Subject: Why choose 120 volts? In-Reply-To: <4A1D4C16.1000905@peter-dambier.de> References: <4A1C455E.5080103@rollernet.us> <20090526201929.GA41317@typo.org> <4A1C5591.1080309@ieee.org> <4A1D3096.4020805@zcorum.com> <4A1D4C16.1000905@peter-dambier.de> Message-ID: On Wed, 27 May 2009, Peter Dambier wrote: > Theory says no matter whether the setting of the powersupply is 120 AC ord 240 AC it > should work. Try at your own risk. I haven't :) I have. Was in the Netherlands last week, and plugged my laptop power supply into the 240v (or so) feed, without incident (after referring to the label). I haven't seen a PC power supply which is incapable of both 120v/60hz and 240v/50hz in a very long time. I think even my 486 from 1994 had a switch for 120/240 -- nowadays it auto-senses, no switch required. --------------------------------------------------------------------------- Peter Beckman Internet Guy beckman at angryox.com http://www.angryox.com/ --------------------------------------------------------------------------- From dhubbard at dino.hostasaurus.com Wed May 27 12:35:31 2009 From: dhubbard at dino.hostasaurus.com (David Hubbard) Date: Wed, 27 May 2009 13:35:31 -0400 Subject: Savvis quality? Message-ID: Just wondering if anyone can tell me their opinion on Savvis bandwidth/company preferably from a web host perspective. Considering a connection. Thanks, David From netfortius at gmail.com Wed May 27 12:50:15 2009 From: netfortius at gmail.com (Stefan) Date: Wed, 27 May 2009 12:50:15 -0500 Subject: Savvis quality? In-Reply-To: References: Message-ID: Have used them since the days of Cable & Wireless - almost flawless. -- ***Stefan http://twitter.com/netfortius On Wed, May 27, 2009 at 12:35 PM, David Hubbard wrote: > Just wondering if anyone can tell me their > opinion on Savvis bandwidth/company preferably > from a web host perspective. ?Considering a > connection. > > Thanks, > > David > > From sethm at rollernet.us Wed May 27 13:10:26 2009 From: sethm at rollernet.us (Seth Mattinen) Date: Wed, 27 May 2009 11:10:26 -0700 Subject: Savvis quality? In-Reply-To: References: Message-ID: <4A1D8212.80106@rollernet.us> David Hubbard wrote: > Just wondering if anyone can tell me their > opinion on Savvis bandwidth/company preferably > from a web host perspective. Considering a > connection. > I've only had them for three years and I've been extremely happy. They catch outages faster (if it's down for over a minute they've already opened a ticket and called me about it) than anyone else I've dealt with. I'm very much a self-service type of customer and I like their web account management thing, too. No performance issues I've ever noticed or heard about. Sadly, I'm going to disconnect it in a few months because I'm outside of their normal service area and it's cost prohibitive to upgrade. If you're in to IPv6 I had talked to them a few months back about it and I was told it can be done as a custom request. I never perused it though after the upgrade quotes came in. ~Seth From pauldotwall at gmail.com Wed May 27 13:53:03 2009 From: pauldotwall at gmail.com (Paul Wall) Date: Wed, 27 May 2009 14:53:03 -0400 Subject: Savvis quality? In-Reply-To: References: Message-ID: <620fd17c0905271153k2f924225yefbfae23f1826abb@mail.gmail.com> On Wed, May 27, 2009 at 1:35 PM, David Hubbard wrote: > Just wondering if anyone can tell me their > opinion on Savvis bandwidth/company preferably > from a web host perspective. ?Considering a > connection. They might be a good provider for reaching Comcast (when they're not advertising inconsistently), but so are Level3 and Global Crossing. I hear they've got some pretty serious peering problems in the US. Drive Slow, Paul Wall From sethm at rollernet.us Wed May 27 14:55:06 2009 From: sethm at rollernet.us (Seth Mattinen) Date: Wed, 27 May 2009 12:55:06 -0700 Subject: Savvis quality? In-Reply-To: <620fd17c0905271153k2f924225yefbfae23f1826abb@mail.gmail.com> References: <620fd17c0905271153k2f924225yefbfae23f1826abb@mail.gmail.com> Message-ID: <4A1D9A9A.4090704@rollernet.us> Paul Wall wrote: > On Wed, May 27, 2009 at 1:35 PM, David Hubbard > wrote: >> Just wondering if anyone can tell me their >> opinion on Savvis bandwidth/company preferably >> from a web host perspective. Considering a >> connection. > > They might be a good provider for reaching Comcast (when they're not > advertising inconsistently), but so are Level3 and Global Crossing. > > I hear they've got some pretty serious peering problems in the US. > I got an offlist to my response asking about their peering issues. I said I couldn't comment because I haven't personally experienced any problems. If anything, I rerouted traffic through SAVVIS heavily during the Sprint/Cogent peering thing since one of my upstreams is Sprint. ~Seth From drais at icantclick.org Wed May 27 16:37:15 2009 From: drais at icantclick.org (david raistrick) Date: Wed, 27 May 2009 17:37:15 -0400 (EDT) Subject: Why choose 120 volts? In-Reply-To: <200905270430.n4R4UxCI022956@aurora.sol.net> References: <200905270430.n4R4UxCI022956@aurora.sol.net> Message-ID: On Tue, 26 May 2009, Joe Greco wrote: >> http://www.cdw.com/shop/products/default.aspx?edc=1036852 > Great, you're the latest person to invent a way to present a 5-15R that > offers something besides 120VAC. This is neither new nor novel, but it > *is* dangerous and risky, and in no way "solves the problem." No, this does NOT present 208v at a 5-15R. Don't believe me, buy one and put a voltmeter across it. I'll leave the FUD to others. --- david raistrick http://www.netmeister.org/news/learn2quote.html drais at icantclick.org http://www.expita.com/nomime.html From dave at stayonline.com Wed May 27 17:01:16 2009 From: dave at stayonline.com (Dave Larter) Date: Wed, 27 May 2009 18:01:16 -0400 Subject: Why choose 120 volts? In-Reply-To: References: <200905270430.n4R4UxCI022956@aurora.sol.net> Message-ID: <8B79B73777E7D544A24BEB8FC50D35DB5981BD@MERCURY.socrdu.com> Seems like if the c14 was connected to a 240v PDU the 5-15 would deliver 240v to the equipment, arc/pop tripping the breaker on the PDU as soon as it is connected killing power to everything on that PDU. Or am I missing something, Also hard to believe it is UL since the c14 is rated 125/250v and well captain obvious says the 5-15 125v max. -----Original Message----- From: david raistrick [mailto:drais at icantclick.org] Sent: Wednesday, May 27, 2009 5:37 PM To: Joe Greco Cc: nanog at nanog.org Subject: Re: Why choose 120 volts? On Tue, 26 May 2009, Joe Greco wrote: >> http://www.cdw.com/shop/products/default.aspx?edc=1036852 > Great, you're the latest person to invent a way to present a 5-15R that > offers something besides 120VAC. This is neither new nor novel, but it > *is* dangerous and risky, and in no way "solves the problem." No, this does NOT present 208v at a 5-15R. Don't believe me, buy one and put a voltmeter across it. I'll leave the FUD to others. --- david raistrick http://www.netmeister.org/news/learn2quote.html drais at icantclick.org http://www.expita.com/nomime.html From jay at west.net Wed May 27 17:04:13 2009 From: jay at west.net (Jay Hennigan) Date: Wed, 27 May 2009 15:04:13 -0700 Subject: Why choose 120 volts? In-Reply-To: References: <200905270430.n4R4UxCI022956@aurora.sol.net> Message-ID: <4A1DB8DD.5030103@west.net> david raistrick wrote: > On Tue, 26 May 2009, Joe Greco wrote: > >>> http://www.cdw.com/shop/products/default.aspx?edc=1036852 > >> Great, you're the latest person to invent a way to present a 5-15R that >> offers something besides 120VAC. This is neither new nor novel, but it >> *is* dangerous and risky, and in no way "solves the problem." > > No, this does NOT present 208v at a 5-15R. Don't believe me, buy one > and put a voltmeter across it. It indeed can and does present 208V (or 240v in some cases) to a 5-15R. I use one of them for that purpose to power my laptop charger from the IEC power strips present in racks fed from 208v. That cord is just an adapter with three copper wires. Putting a voltmeter on its output will just measure what is present on its input. That cord mated to an IEC cord in Europe will put 240v 50 Hz on the receptacle. Mated to an IEC PDU on a 208v-wired rack, it will measure 208v. This is not necessarily dangerous, *IF* you are aware of it and don't leave it plugged in for someone unaware of the voltage present to use. Radio Shack sells an adapter from the Schucko round pin 240v receptacles to a 5-15R. It works just fine for my laptop because the laptop power supply is *designed* to operate on any voltage from 100 to 240 volts. It would NOT work just fine if someone plugged in a 120v-only appliance. If you leave that cord plugged in to a 208V-fed rack and walk away from it, there is a likelihood that someone else looking for a convenience outlet will discover it and plug something in. If that "something" isn't happy with the 208v it gets, the magic smoke that is contained in the device will escape. As we all know, once the smoke gets out, the device will stop functioning. -- Jay Hennigan - CCIE #7880 - Network Engineering - jay at impulse.net Impulse Internet Service - http://www.impulse.net/ Your local telephone and internet company - 805 884-6323 - WB6RDV From sethm at rollernet.us Wed May 27 17:08:55 2009 From: sethm at rollernet.us (Seth Mattinen) Date: Wed, 27 May 2009 15:08:55 -0700 Subject: Why choose 120 volts? In-Reply-To: References: <200905270430.n4R4UxCI022956@aurora.sol.net> Message-ID: <4A1DB9F7.7000001@rollernet.us> david raistrick wrote: > On Tue, 26 May 2009, Joe Greco wrote: > >>> http://www.cdw.com/shop/products/default.aspx?edc=1036852 > >> Great, you're the latest person to invent a way to present a 5-15R that >> offers something besides 120VAC. This is neither new nor novel, but it >> *is* dangerous and risky, and in no way "solves the problem." > > No, this does NOT present 208v at a 5-15R. Don't believe me, buy one > and put a voltmeter across it. > > I'll leave the FUD to others. > Here's the L-G voltage off the 208v taps from an isolation transformer in a system with no neutral: http://ninjamonkey.us/not_120_volts.jpg In other words, in a system with no neutral, it's not designed to do 120v loads. The L-L voltage on that same PDU is 211. Also, the device you linked will present high voltage because again, no neutral. ~Seth From drais at icantclick.org Wed May 27 17:30:20 2009 From: drais at icantclick.org (david raistrick) Date: Wed, 27 May 2009 18:30:20 -0400 (EDT) Subject: Why choose 120 volts? In-Reply-To: <4A1DB9F7.7000001@rollernet.us> References: <200905270430.n4R4UxCI022956@aurora.sol.net> <4A1DB9F7.7000001@rollernet.us> Message-ID: On Wed, 27 May 2009, Seth Mattinen wrote: > Here's the L-G voltage off the 208v taps from an isolation transformer in a > system with no neutral: http://ninjamonkey.us/not_120_volts.jpg Not 120, but 90 give or take. 90 is at the low end of the acceptable range for common household 110/120v service. Depending on how the phases are balanced in your facility, you may see that fluctuate up or down, of course. If you measure hot to hot on the same PDU, do you get anywhere close to 208? I'm going to suspect either your fairly out of balance, or you've got a good bit of voltage drop by the time it arrives.... But since the concensus from those who haven't used this is that the device will present 208/240 at the 5-15 plug, I withdraw my suggestion and leave you to your own methods. (for the rest, test it yourself) I also won't argue using ground for neutral, that's like arguing bonded vs unbonded panels. --- david raistrick http://www.netmeister.org/news/learn2quote.html drais at icantclick.org http://www.expita.com/nomime.html From dave at stayonline.com Wed May 27 17:39:37 2009 From: dave at stayonline.com (Dave Larter) Date: Wed, 27 May 2009 18:39:37 -0400 Subject: Why choose 120 volts? In-Reply-To: References: <200905270430.n4R4UxCI022956@aurora.sol.net><4A1DB9F7.7000001@rollernet.us> Message-ID: <8B79B73777E7D544A24BEB8FC50D35DB5981C3@MERCURY.socrdu.com> The ground is not supposed to carry any current where as the neutral is. If you tried to carry current on the ground of a CGFI protected circuit it would trip. -----Original Message----- From: david raistrick [mailto:drais at icantclick.org] Sent: Wednesday, May 27, 2009 6:30 PM To: Seth Mattinen Cc: nanog at nanog.org Subject: Re: Why choose 120 volts? On Wed, 27 May 2009, Seth Mattinen wrote: > Here's the L-G voltage off the 208v taps from an isolation transformer in a > system with no neutral: http://ninjamonkey.us/not_120_volts.jpg Not 120, but 90 give or take. 90 is at the low end of the acceptable range for common household 110/120v service. Depending on how the phases are balanced in your facility, you may see that fluctuate up or down, of course. If you measure hot to hot on the same PDU, do you get anywhere close to 208? I'm going to suspect either your fairly out of balance, or you've got a good bit of voltage drop by the time it arrives.... But since the concensus from those who haven't used this is that the device will present 208/240 at the 5-15 plug, I withdraw my suggestion and leave you to your own methods. (for the rest, test it yourself) I also won't argue using ground for neutral, that's like arguing bonded vs unbonded panels. --- david raistrick http://www.netmeister.org/news/learn2quote.html drais at icantclick.org http://www.expita.com/nomime.html From iljitsch at muada.com Wed May 27 18:11:41 2009 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Thu, 28 May 2009 01:11:41 +0200 Subject: Why choose 120 volts? In-Reply-To: References: <4A1C455E.5080103@rollernet.us> <20090526201929.GA41317@typo.org> <4A1C5591.1080309@ieee.org> <4A1D3096.4020805@zcorum.com> <4A1D4C16.1000905@peter-dambier.de> Message-ID: <299E2CB4-A43D-4C5D-A5EA-89B6C08A01F1@muada.com> On 27 mei 2009, at 18:03, Peter Beckman wrote: > I haven't seen a PC power supply which is incapable of both 120v/ > 60hz and > 240v/50hz in a very long time. After this nice voltage discussion, what about hertz? Would it be more efficient for us Europeans to run our stuff at 60 Hz rather than 50? I hear that a 50 Hz grid loses 15% more due to inefficiencies than a 60 Hz grid. Not sure if that also applies over short distances, though. And apparently you can run your Apple laptop's power supply on 80V DC... The switching power supply doesn't care as long as the voltage is low enough to not fry the half of the rectifier diodes in continuous use. (Try at your own risk, of course.) From jgreco at ns.sol.net Wed May 27 18:17:59 2009 From: jgreco at ns.sol.net (Joe Greco) Date: Wed, 27 May 2009 18:17:59 -0500 (CDT) Subject: Why choose 120 volts? In-Reply-To: from "david raistrick" at May 27, 2009 05:37:15 PM Message-ID: <200905272317.n4RNHxX2002240@aurora.sol.net> > On Tue, 26 May 2009, Joe Greco wrote: > >> http://www.cdw.com/shop/products/default.aspx?edc=1036852 > > > Great, you're the latest person to invent a way to present a 5-15R that > > offers something besides 120VAC. This is neither new nor novel, but it > > *is* dangerous and risky, and in no way "solves the problem." > > No, this does NOT present 208v at a 5-15R. Don't believe me, buy one and > put a voltmeter across it. I _don't_ believe you, because we've put a voltmeter across it. I know a number of cages where someone has extended a 208 or 240V service using a monitor power adapter, a 5-15 extension cord, and an ordinary 5-15 outlet strip; the smart people put a BIG WARNING STICKER on it because they know that the voltage present isn't 120. The dumb ones are unaware of what they've done and figure "my laptop works so all is good". > I'll leave the FUD to others. ... and move right on to outright misstatements? ... 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 drais at icantclick.org Wed May 27 18:25:50 2009 From: drais at icantclick.org (david raistrick) Date: Wed, 27 May 2009 19:25:50 -0400 (EDT) Subject: Why choose 120 volts? In-Reply-To: <200905272317.n4RNHxX2002240@aurora.sol.net> References: <200905272317.n4RNHxX2002240@aurora.sol.net> Message-ID: On Wed, 27 May 2009, Joe Greco wrote: > ... and move right on to outright misstatements? No, statements based on personal experience. I -fully- expected to get 208v out of them, but in testing didn't. Perhaps the ten I ordered were unique. Or perhaps I don't know how to operate a VOM, or perhaps I'm full of sh!t. I didn't expect this to generate such an uproar...but I forgot this is nanog. ;-) .d --- david raistrick http://www.netmeister.org/news/learn2quote.html drais at icantclick.org http://www.expita.com/nomime.html From jgreco at ns.sol.net Wed May 27 18:31:09 2009 From: jgreco at ns.sol.net (Joe Greco) Date: Wed, 27 May 2009 18:31:09 -0500 (CDT) Subject: Why choose 120 volts? In-Reply-To: <8B79B73777E7D544A24BEB8FC50D35DB5981BD@MERCURY.socrdu.com> from "Dave Larter" at May 27, 2009 06:01:16 PM Message-ID: <200905272331.n4RNV9Ec003246@aurora.sol.net> > Seems like if the c14 was connected to a 240v PDU the 5-15 would deliver > 240v to the equipment, arc/pop tripping the breaker on the PDU as soon > as it is connected killing power to everything on that PDU. Well, the latter half of that is making all sorts of assumptions. Your typical 208V 20A circuit is capable of delivering watts roughly equivalent to a 120V 30A circuit; if whatever is being destroyed is beefy enough to momentarily short out that much power, yes, the breaker should trip, but in many cases, a power supply might only be designed to handle a hundred watts or so, and who knows what component leads, PCB traces, components, etc., might burn out quickly before the PDU breaker really "notices." > Or am I missing something, Also hard to believe it is UL since the c14 > is rated 125/250v and well captain obvious says the 5-15 125v max. It is UL when used in the intended manner. Note that it is marketed as a monitor feedthrough power adapter (or something like that) - not a 208V-to-120V converter dongle. There are many examples of things you *can* do that are hazardous with UL listed devices. UL listing mainly means that something isn't all that dangerous (from an insurance perspective, at that). Consider, for example, that you can plug a household extension cord (UL listed, 14ga, ~13A @ 120V) into a 20 amp circuit, and then plug in 16 amps worth of stuff, and watch the cord heat. It isn't UL rated for such use. ... 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 Wed May 27 18:40:39 2009 From: jgreco at ns.sol.net (Joe Greco) Date: Wed, 27 May 2009 18:40:39 -0500 (CDT) Subject: Why choose 120 volts? In-Reply-To: from "david raistrick" at May 27, 2009 06:30:20 PM Message-ID: <200905272340.n4RNedLg003596@aurora.sol.net> > On Wed, 27 May 2009, Seth Mattinen wrote: > > > Here's the L-G voltage off the 208v taps from an isolation transformer in a > > system with no neutral: http://ninjamonkey.us/not_120_volts.jpg > > Not 120, but 90 give or take. 90 is at the low end of the acceptable > range for common household 110/120v service. Yeah, but that's L-G voltage (geez, did you even look at the picture?) And Seth just finished telling us that it was 211 L-L: Seth > "The L-L voltage on that same PDU is 211." What's going to be presented at the neutral and hot of the 5-15R of the monitor power adapter are the L and L. Think about it. Or get out a meter and test. > Depending on how the phases are balanced in your facility, you may see > that fluctuate up or down, of course. If you measure hot to hot on the > same PDU, do you get anywhere close to 208? Yes, Seth just finished telling us that in the portion of his message you conveniently snipped. > I'm going to suspect either > your fairly out of balance, or you've got a good bit of voltage drop by > the time it arrives.... > > But since the concensus from those who haven't used this is that the > device will present 208/240 at the 5-15 plug, I withdraw my suggestion and > leave you to your own methods. (for the rest, test it yourself) For those of us who *have* used this, we're telling you that it'll present 208/240 at the 5-15R. > I also won't argue using ground for neutral, that's like arguing bonded vs > unbonded panels. No it's not. Only idiots argue for using ground for neutral. In doubt? Ask your electrical inspector. ... 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 cra at WPI.EDU Wed May 27 19:31:42 2009 From: cra at WPI.EDU (Chuck Anderson) Date: Wed, 27 May 2009 20:31:42 -0400 Subject: Why choose 120 volts? In-Reply-To: References: <200905272317.n4RNHxX2002240@aurora.sol.net> Message-ID: <20090528003142.GA18361@angus.ind.WPI.EDU> On Wed, May 27, 2009 at 07:25:50PM -0400, david raistrick wrote: > On Wed, 27 May 2009, Joe Greco wrote: > >> ... and move right on to outright misstatements? > > No, statements based on personal experience. I -fully- expected to get > 208v out of them, but in testing didn't. Note that it is also perfectly possible and reasonable to use IEC 320 C13 PDUs for 120V service. You may have unknowingly used the monitor adapter on a 120V feed, having assumed that C13 == 208/240, when it doesn't necessarily mean that. From bonomi at mail.r-bonomi.com Wed May 27 20:30:49 2009 From: bonomi at mail.r-bonomi.com (Robert Bonomi) Date: Wed, 27 May 2009 20:30:49 -0500 (CDT) Subject: Why choose 120 volts? Message-ID: <200905280130.n4S1Un1O021402@mail.r-bonomi.com> > Subject: Re: Why choose 120 volts? > Date: Thu, 28 May 2009 01:11:41 +0200 > > On 27 mei 2009, at 18:03, Peter Beckman wrote: > > > I haven't seen a PC power supply which is incapable of both 120v/ > > 60hz and > > 240v/50hz in a very long time. > > After this nice voltage discussion, what about hertz? Would it be more > efficient for us Europeans to run our stuff at 60 Hz rather than 50? I > hear that a 50 Hz grid loses 15% more due to inefficiencies than a 60 > Hz grid. Not sure if that also applies over short distances, though. _Transformer_ losses are greater at lower frequencies. And the cores have to be bigger. That is the primary reason military avionics, and other onboard gear use 400Hz AC. Note: The U.S. as recently as immediate post WW-II had some areas of 25-Hz power. Transformer based equipment that was designed to be "just adequate" for 60Hz mains was known to 'let the smoke out' when plugged in in one of those 25Hz areas. From leen at consolejunkie.net Thu May 28 03:04:57 2009 From: leen at consolejunkie.net (Leen Besselink) Date: Thu, 28 May 2009 10:04:57 +0200 Subject: Why choose 120 volts? In-Reply-To: <4A1C77B3.5070406@internode.com.au> References: <4A1C455E.5080103@rollernet.us> <074b01c9de43$1dae5830$590b0890$@net> <4A1C5A21.4020403@west.net> <4A1C77B3.5070406@internode.com.au> Message-ID: <4A1E45A9.4000402@consolejunkie.net> > It's worth noting that despite higher voltages here there aren't more > deaths or injuries - but maybe it's because people take it more > seriously. Admittedly no one I know is nuts enough to use body parts > for "liveness testing". > (sorry for being kinda late in this discussion) I've never felt the urge to do so either, maybe I'm just a wimp. ;-) But here is a something I've heared from people who do/have or know people who do have. And usually they are people with a degree in the field of electronics: use the back of the hand don't grap wires, when current passes through your body, muscles contract and you don't want to hold on to it when those muscles make a fist or more that arm towards your body. You just want to touch it lightly. Just to make things clear, I am NOT going to suggest you should do so, just telling you what I think I heared. From wbailey at gci.com Thu May 28 03:07:53 2009 From: wbailey at gci.com (Warren Bailey) Date: Thu, 28 May 2009 00:07:53 -0800 Subject: Why choose 120 volts? In-Reply-To: <4A1E45A9.4000402@consolejunkie.net> References: <4A1C455E.5080103@rollernet.us> <074b01c9de43$1dae5830$590b0890$@net> <4A1C5A21.4020403@west.net><4A1C77B3.5070406@internode.com.au> <4A1E45A9.4000402@consolejunkie.net> Message-ID: <5B3743FC2D0D8B41B27EE4F5EACA79D10A3BBF80@DTN1EX01.gci.com> AC Grabs, DC Pushes. And for the record, I am confident this is the longest thread in the history of this list lol. Note to self, consult nanog on facility power when building next datacenter. *laugh* //warren Warren Bailey GCI Communication Corp. RF Network Engineering 907.868.5911 office 907.903.5410 mobile -----Original Message----- From: Leen Besselink [mailto:leen at consolejunkie.net] Sent: Thursday, May 28, 2009 12:05 AM Cc: nanog at nanog.org Subject: Re: Why choose 120 volts? > It's worth noting that despite higher voltages here there aren't more > deaths or injuries - but maybe it's because people take it more > seriously. Admittedly no one I know is nuts enough to use body parts > for "liveness testing". > (sorry for being kinda late in this discussion) I've never felt the urge to do so either, maybe I'm just a wimp. ;-) But here is a something I've heared from people who do/have or know people who do have. And usually they are people with a degree in the field of electronics: use the back of the hand don't grap wires, when current passes through your body, muscles contract and you don't want to hold on to it when those muscles make a fist or more that arm towards your body. You just want to touch it lightly. Just to make things clear, I am NOT going to suggest you should do so, just telling you what I think I heared. From gb10hkzo-nanog at yahoo.co.uk Thu May 28 03:40:29 2009 From: gb10hkzo-nanog at yahoo.co.uk (gb10hkzo-nanog at yahoo.co.uk) Date: Thu, 28 May 2009 01:40:29 -0700 (PDT) Subject: MX Record Theories In-Reply-To: References: <768499.91907.qm@web24713.mail.ird.yahoo.com> Message-ID: <507283.51379.qm@web24715.mail.ird.yahoo.com> On Wed, 27 May 2009 09:48:39 -0400, wrote: > Actually, I was thinking to myself yesterday that the email world is going to be awfully > fun when IPv6 sets in and we're all running mail servers with nice long AAAA records such as > fc00:836b:4917::a180:4179. > You do realize DNS queries aren't passing around addresses in ASCII? 3 additional bytes per address isn't going to break the bank. I think you might have missed the point of my post. It was a tounge in cheek reply to the poster who suggested bad things happen if the DNS message size exceeds 512 bytes. He was commenting about AOL's MX records which currently weigh in at 507 bytes. Therefore if we were to hypothesise that the world ends at 512 bytes, then companies doing things the way AOL does, but using IPv6 addresses rather than IPv4 addresses for their MX records could run into "problems". Hope that clarifies :) From sethm at rollernet.us Thu May 28 04:10:37 2009 From: sethm at rollernet.us (Seth Mattinen) Date: Thu, 28 May 2009 02:10:37 -0700 Subject: Why choose 120 volts? In-Reply-To: <5B3743FC2D0D8B41B27EE4F5EACA79D10A3BBF80@DTN1EX01.gci.com> References: <4A1C455E.5080103@rollernet.us> <074b01c9de43$1dae5830$590b0890$@net> <4A1C5A21.4020403@west.net><4A1C77B3.5070406@internode.com.au> <4A1E45A9.4000402@consolejunkie.net> <5B3743FC2D0D8B41B27EE4F5EACA79D10A3BBF80@DTN1EX01.gci.com> Message-ID: <4A1E550D.9020407@rollernet.us> Warren Bailey wrote: > AC Grabs, DC Pushes. > > And for the record, I am confident this is the longest thread in the > history of this list lol. Note to self, consult nanog on facility power > when building next datacenter. *laugh* > Yeah, my fault for starting it. ;) I was really just curious how many people in the US use high voltages or stick with low voltage (in the form of 120 AC or even lower DC). The feeling I'm getting is that some are comfortable with it and use high voltages, but there's enough confusion because unlike other countries, over 120 is relatively uncommon. ~Seth From sip.vsp.5060 at gmail.com Thu May 28 09:03:26 2009 From: sip.vsp.5060 at gmail.com (david hiers) Date: Thu, 28 May 2009 07:03:26 -0700 Subject: navog? Message-ID: <501309d50905280703p1b312594tc56fff5984fadbb6@mail.gmail.com> Hi, Is anyone aware of a voip-focused group similar to nanog? Us voip pukes have to deal with the issues of allocation, routing, and management of phone numbers as well as networks, and I have not found a voice operators' group similar to this network operators' group. Thanks, David From rdobbins at arbor.net Thu May 28 09:14:13 2009 From: rdobbins at arbor.net (Roland Dobbins) Date: Thu, 28 May 2009 21:14:13 +0700 Subject: navog? In-Reply-To: <501309d50905280703p1b312594tc56fff5984fadbb6@mail.gmail.com> References: <501309d50905280703p1b312594tc56fff5984fadbb6@mail.gmail.com> Message-ID: On May 28, 2009, at 9:03 PM, david hiers wrote: > Is anyone aware of a voip-focused group similar to nanog? VOIPSA are focused on VoIP, mainly around security: ----------------------------------------------------------------------- Roland Dobbins // Unfortunately, inefficiency scales really well. -- Kevin Lawton From sil at infiltrated.net Thu May 28 09:16:03 2009 From: sil at infiltrated.net (J. Oquendo) Date: Thu, 28 May 2009 10:16:03 -0400 Subject: navog? In-Reply-To: <501309d50905280703p1b312594tc56fff5984fadbb6@mail.gmail.com> References: <501309d50905280703p1b312594tc56fff5984fadbb6@mail.gmail.com> Message-ID: <4A1E9CA3.6020302@infiltrated.net> david hiers wrote: > Hi, > Is anyone aware of a voip-focused group similar to nanog? Us voip pukes > have to deal with the issues of allocation, routing, and management of phone > numbers as well as networks, and I have not found a voice operators' group > similar to this network operators' group. > > > Thanks, > > David > Would kind of be difficult to maintain such a group. Which level of VoIP are you talking about, the carrier end, the engineer end. Think about that for a moment. For the most part, for issues regarding connectivity, VoIP is no different than email is. Networks will be networks, VoIP will go down, life goes on. Resolution can be found either directly through your vendor/carrier or you can get a best guesstimate of an outage from the outages list or someone here shooting off a "Are Cogent and Level3 chest thumping again?" message. On the other hand, I don't know that I'd want to see a multitude of messages from someone saying "My trixbox dialplan doesn't work!" or, (broken english purposely inserted) "Why my Cisco Call Manager is tell me to partition! I does not want to format my disk! Please is you help!" There are lists out there but each has its pros and cons. VoIPSA (VoIP Security) Cisco VoIP - for Cisco related telephony, Digium mailing lists, etc. Something akin to NANOG for VoIP would quickly become filled with "WTH is he/she saying" like messages. Sadly, most of my cisco-voip and asterisk-users mail has been ending up in the trash via filter. I wonder if my email client knows something I don't. -- =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ J. Oquendo SGFA, SGFE, C|EH, CNDA, CHFI, OSCP "It takes 20 years to build a reputation and five minutes to ruin it. If you think about that, you'll do things differently." - Warren Buffett 227C 5D35 7DCB 0893 95AA 4771 1DCE 1FD1 5CCD 6B5E http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x5CCD6B5E From jared at puck.nether.net Thu May 28 09:24:13 2009 From: jared at puck.nether.net (Jared Mauch) Date: Thu, 28 May 2009 10:24:13 -0400 Subject: navog? In-Reply-To: <4A1E9CA3.6020302@infiltrated.net> References: <501309d50905280703p1b312594tc56fff5984fadbb6@mail.gmail.com> <4A1E9CA3.6020302@infiltrated.net> Message-ID: On May 28, 2009, at 10:16 AM, J. Oquendo wrote: > david hiers wrote: >> Hi, >> Is anyone aware of a voip-focused group similar to nanog? Us voip >> pukes >> have to deal with the issues of allocation, routing, and management >> of phone >> numbers as well as networks, and I have not found a voice >> operators' group >> similar to this network operators' group. >> >> >> Thanks, >> >> David >> > On the other hand, I don't know that I'd want to see a multitude of > messages > from someone saying "My trixbox dialplan doesn't work!" or, (broken > english > purposely inserted) "Why my Cisco Call Manager is tell me to > partition! Actually, there is a quite active cisco-voip list over on puck that discusses exactly the CM issues you refer to. (I diverted everyone to that list to keep it off c-nsp and it seems to have grown since). - Jared http://puck.nether.net/mailman/listinfo/cisco-voip From sil at infiltrated.net Thu May 28 09:33:49 2009 From: sil at infiltrated.net (J. Oquendo) Date: Thu, 28 May 2009 10:33:49 -0400 Subject: navog? In-Reply-To: References: <501309d50905280703p1b312594tc56fff5984fadbb6@mail.gmail.com> <4A1E9CA3.6020302@infiltrated.net> Message-ID: <4A1EA0CD.1000003@infiltrated.net> Jared Mauch wrote: > > On May 28, 2009, at 10:16 AM, J. Oquendo wrote: > >> david hiers wrote: >>> Hi, >>> Is anyone aware of a voip-focused group similar to nanog? Us voip >>> pukes >>> have to deal with the issues of allocation, routing, and management >>> of phone >>> numbers as well as networks, and I have not found a voice operators' >>> group >>> similar to this network operators' group. >>> >>> >>> Thanks, >>> >>> David >>> >> On the other hand, I don't know that I'd want to see a multitude of >> messages >> from someone saying "My trixbox dialplan doesn't work!" or, (broken >> english >> purposely inserted) "Why my Cisco Call Manager is tell me to partition! > > Actually, there is a quite active cisco-voip list over on puck > that discusses exactly the CM issues you refer to. (I diverted > everyone to that list to keep it off c-nsp and it seems to have grown > since). > > - Jared > > http://puck.nether.net/mailman/listinfo/cisco-voip > (removed cc's to avoid sending dupes) Agreed, I browse through some of the stuff there and indeed it works for cisco telephony matters. Cisco staff has provided some really good guidance on matters there, as have Digium staffers for Asterisk's mailing list. But I can't really envision an "all inclusive" VoIP list with regards to the carrier end, equipment end, programming end, etc. Heaven knows I would have like to discuss Nortel and Avaya matters countless times but then those conversations would have actually ended up shifting towards SIP in which to a degree, they wouldn't have even had anything to do with the vendors at all. So I view it as a tough call. Anyhow, perhaps links should be included: http://voipsa.org/VOIPSEC/ (VoIPSA - VoIP Security related) http://puck.nether.net/mailman/listinfo/cisco-voip (Cisco VoIP related) http://lists.digium.com/mailman/listinfo/asterisk-users (Asterisk Users) http://groups.yahoo.com/group/sip-config (SIP Config (mainly spam now)) http://sipforum.org/pipermail/discussion/index.html (SIP forum) -- =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ J. Oquendo SGFA, SGFE, C|EH, CNDA, CHFI, OSCP "It takes 20 years to build a reputation and five minutes to ruin it. If you think about that, you'll do things differently." - Warren Buffett 227C 5D35 7DCB 0893 95AA 4771 1DCE 1FD1 5CCD 6B5E http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x5CCD6B5E From petelists at templin.org Thu May 28 09:38:34 2009 From: petelists at templin.org (Pete Templin) Date: Thu, 28 May 2009 09:38:34 -0500 Subject: Why choose 120 volts? In-Reply-To: <8B79B73777E7D544A24BEB8FC50D35DB5981BD@MERCURY.socrdu.com> References: <200905270430.n4R4UxCI022956@aurora.sol.net> <8B79B73777E7D544A24BEB8FC50D35DB5981BD@MERCURY.socrdu.com> Message-ID: <4A1EA1EA.5030400@templin.org> Dave Larter wrote: > Seems like if the c14 was connected to a 240v PDU the 5-15 would > deliver 240v to the equipment, arc/pop tripping the breaker on the > PDU as soon as it is connected killing power to everything on that > PDU. Or am I missing something? If you plug a PDU into a service that's higher voltage than expected, why would the PDU circuit breaker trip? That breaker is measuring current, AFAICT, though in the end it might be measuring power. Regardless, it isn't measuring voltage, because that isn't constant (it's AC, after all) and is likely to drop under a short circuit, not skyrocket like the current will. pt From dave at stayonline.com Thu May 28 09:44:00 2009 From: dave at stayonline.com (Dave Larter) Date: Thu, 28 May 2009 10:44:00 -0400 Subject: Why choose 120 volts? In-Reply-To: <4A1EA1EA.5030400@templin.org> References: <200905270430.n4R4UxCI022956@aurora.sol.net> <8B79B73777E7D544A24BEB8FC50D35DB5981BD@MERCURY.socrdu.com> <4A1EA1EA.5030400@templin.org> Message-ID: <8B79B73777E7D544A24BEB8FC50D35DB598224@MERCURY.socrdu.com> I was referring to, when a 120v device is attached to the 5-15 end of the cord. On the inside of these grounded devices I often find that the neutral is tied to ground. So in the case of the c14 being connected to a 240v PDU when I 120v device is connected it will ground one of the load lines. And yes, voltage will drop while current spikes, thus tripping the breaker. -----Original Message----- From: Pete Templin [mailto:petelists at templin.org] Sent: Thursday, May 28, 2009 10:39 AM To: Dave Larter Cc: nanog at nanog.org Subject: Re: Why choose 120 volts? Dave Larter wrote: > Seems like if the c14 was connected to a 240v PDU the 5-15 would > deliver 240v to the equipment, arc/pop tripping the breaker on the > PDU as soon as it is connected killing power to everything on that > PDU. Or am I missing something? If you plug a PDU into a service that's higher voltage than expected, why would the PDU circuit breaker trip? That breaker is measuring current, AFAICT, though in the end it might be measuring power. Regardless, it isn't measuring voltage, because that isn't constant (it's AC, after all) and is likely to drop under a short circuit, not skyrocket like the current will. pt From jay at west.net Thu May 28 09:55:22 2009 From: jay at west.net (Jay Hennigan) Date: Thu, 28 May 2009 07:55:22 -0700 Subject: Why choose 120 volts? In-Reply-To: <8B79B73777E7D544A24BEB8FC50D35DB598224@MERCURY.socrdu.com> References: <200905270430.n4R4UxCI022956@aurora.sol.net> <8B79B73777E7D544A24BEB8FC50D35DB5981BD@MERCURY.socrdu.com> <4A1EA1EA.5030400@templin.org> <8B79B73777E7D544A24BEB8FC50D35DB598224@MERCURY.socrdu.com> Message-ID: <4A1EA5DA.1040809@west.net> Dave Larter wrote: > I was referring to, when a 120v device is attached to the 5-15 end of > the cord. On the inside of these grounded devices I often find that the > neutral is tied to ground. Often??? Name one device designed that way. And please tell us how well that device works when you plug it in to a GFCI-protected outlet in your kitchen. I believe that you are very mistaken. -- Jay Hennigan - CCIE #7880 - Network Engineering - jay at impulse.net Impulse Internet Service - http://www.impulse.net/ Your local telephone and internet company - 805 884-6323 - WB6RDV From bobbyjim at gmail.com Thu May 28 10:04:47 2009 From: bobbyjim at gmail.com (Bobby Mac) Date: Thu, 28 May 2009 10:04:47 -0500 Subject: MX Record Theories In-Reply-To: <163001.1243364471@turing-police.cc.vt.edu> References: <189373.71102.qm@web24704.mail.ird.yahoo.com> <163001.1243364471@turing-police.cc.vt.edu> Message-ID: Not entirely on subject but.... I thought that allowing DNS queries to occur via TCP is mission critical for simple mail routing. We ran across this back in the day at @Home Network. Firewall rules were changed to not allow port 53 TCP. This severely affected sending mail to large distribution lists. Here is what we found and forgive me if I don't go into too much detail as it was almost 10 years a go. If you add enough recipients to an email, each domain within the send line needs to have an associated MX record. DNS by default starts with UDP which has a limit to the datagram size (64bit). A flag is placed in the header which then requires the request to be sent via TCP (160bit V4). Now that single query can be split up into many different packets providing that the request is more than the 160 bit and obviously IPV6 offers even more information contained in a single packet. -BobbyJim On Tue, May 26, 2009 at 2:01 PM, wrote: > On Tue, 26 May 2009 11:03:59 PDT, gb10hkzo-nanog at yahoo.co.uk said: > > would be most interested to hear NANOG theories on the variety of MX > > record practices out there, namely, how come there seem to be so many > > ways employed to achieve the same goal ? > > The trick here is that it isn't always *exactly* "the same goal". There's > multiple mail system architectures and design philosophies. > > One often overlooked but very important design point for the *large* > providers: > > % dig aol.com mx > ;; ANSWER SECTION: > aol.com. 2805 IN MX 15 mailin-01.mx.aol.com. > aol.com. 2805 IN MX 15 mailin-02.mx.aol.com. > ... > ;; WHEN: Tue May 26 14:40:41 2009 > ;; MSG SIZE rcvd: 507 > > That 507 is critically important if you want to receive e-mail from sites > with fascist firewalls that block EDNS0 and/or TCP/53. 5 bytes left. ;) > > From joelja at bogus.com Thu May 28 10:20:36 2009 From: joelja at bogus.com (joel jaeggli) Date: Thu, 28 May 2009 08:20:36 -0700 Subject: Why choose 120 volts? Message-ID: If the pdu contains a surge suppressor and was designed for 120v, plugging in to 220 will cause the MOV that protects against transient over-voltage to emit smoke. The breaker or fuse is a current limiting device. Joel Pete Templin wrote: >Dave Larter wrote: >> Seems like if the c14 was connected to a 240v PDU the 5-15 would >> deliver 240v to the equipment, arc/pop tripping the breaker on the >> PDU as soon as it is connected killing power to everything on that >> PDU. Or am I missing something? > >If you plug a PDU into a service that's higher voltage than expected, >why would the PDU circuit breaker trip? That breaker is measuring >current, AFAICT, though in the end it might be measuring power. >Regardless, it isn't measuring voltage, because that isn't constant >(it's AC, after all) and is likely to drop under a short circuit, not >skyrocket like the current will. > >pt > From kohn.jack at gmail.com Thu May 28 10:33:21 2009 From: kohn.jack at gmail.com (Jack Kohn) Date: Thu, 28 May 2009 21:03:21 +0530 Subject: Huawei cx300 Message-ID: Guys, Anybody any experience with VPLS on Huawei cx300? Jack From kilroy at WasHere.COM Thu May 28 11:03:18 2009 From: kilroy at WasHere.COM (Ric Messier) Date: Thu, 28 May 2009 10:03:18 -0600 (MDT) Subject: Packet loss statistics Message-ID: Is anyone aware of useful resources for packet loss over large LANs and WANs? Google turned up a nice statistics page for Qwest's network but not much else that seems useful to me. Our testing teams are trying to simulate expected network conditions and rather than go overboard, having something close to real-world parameters would be nice. Thanks! Ric From chrobb at internet2.edu Thu May 28 11:17:46 2009 From: chrobb at internet2.edu (Chris Robb) Date: Thu, 28 May 2009 12:17:46 -0400 Subject: Packet loss statistics References: <045B2DE7-D8CB-4DC3-BF34-8CAD6C4AADBA@internet2.edu> Message-ID: The Internet2 network publishes 10-second data for all interfaces on both its backbone network and the individual racklans in each of its cities: Backbone: http://dc-snmp.grnoc.iu.edu/i2net/ Racklans: http://dc-snmp.grnoc.iu.edu/i2net-hp/ Default graphs don't show errors. You need to create a custom graph and click the appropriate checkbox. If you want to view a large number of interfaces with their errors on a single page, you can create a Custom View that includes errors for any number of selected interfaces. -Chris On May 28, 2009, at 12:03 PM, Ric Messier wrote: > > Is anyone aware of useful resources for packet loss over large LANs > and WANs? Google turned up a nice statistics page for Qwest's > network but not much else that seems useful to me. > > Our testing teams are trying to simulate expected network conditions > and rather than go overboard, having something close to real-world > parameters would be nice. > > Thanks! > Ric > Chris Robb, Internet2 Manager of Operations O: 812.855.8604 C: 812.345.3188 **************** ESCC/Internet2 Joint Techs July 19-23, 2009 - Indianapolis, Indiana http://jointtechs.es.net/indiana2009/ From nenolod at systeminplace.net Thu May 28 11:18:47 2009 From: nenolod at systeminplace.net (William Pitcock) Date: Thu, 28 May 2009 11:18:47 -0500 Subject: Why choose 120 volts? In-Reply-To: <4A1C455E.5080103@rollernet.us> References: <4A1C455E.5080103@rollernet.us> Message-ID: <1243527527.9604.142.camel@petrie> On Tue, 2009-05-26 at 12:39 -0700, Seth Mattinen wrote: > I have a pure curiosity question for the NANOG crowd here. If you run > your facility/datacenter/cage/rack on 120 volts, why? > We are using 120V in our colocation spaces. > I've been running my facility at 208 for years because I can get away > with lower amperage circuits. I'm curious about the reasons for using > high-amp 120 volt circuits to drive racks of equipment instead of > low-amp 208 or 240 volt circuits. The reason why we are using 120V is because we have pre-existing equipment (such as PDUs) that only support 120V operation. I believe our newer PDUs support 120/208/240, but do not have the time to investigate that, and we still have a couple of older APC units still in service. Our servers don't really care which voltage we provide, most of the PSUs can determine 120 vs 240 automatically, even. Also, at least at Equinix Chicago, 120V service was cheaper when we colocated there. I do not know if this is the same case at Steadfast in Chicago, and as far as I know, HE does not offer 208/240 service in their Fremont-2 facility. I could be misinformed on that, though. -- William Pitcock SystemInPlace - Simple Hosting Solutions 1-866-519-6149 From jared at puck.nether.net Thu May 28 11:20:02 2009 From: jared at puck.nether.net (Jared Mauch) Date: Thu, 28 May 2009 12:20:02 -0400 Subject: Packet loss statistics In-Reply-To: References: Message-ID: <4EA2196C-D6E1-45DD-A789-D5160067F15E@puck.nether.net> On May 28, 2009, at 12:03 PM, Ric Messier wrote: > > Is anyone aware of useful resources for packet loss over large LANs > and WANs? Google turned up a nice statistics page for Qwest's > network but not much else that seems useful to me. > > Our testing teams are trying to simulate expected network conditions > and rather than go overboard, having something close to real-world > parameters would be nice. Depending on what you want, you could use something like smokeping or owamp to measure your network. (Both can be easily found via the goog). There are also commercial packages (eg: firehunter) that can be utilized as well to measure your network. - jared From alexb at ripe.net Thu May 28 11:48:03 2009 From: alexb at ripe.net (Alex Band) Date: Thu, 28 May 2009 18:48:03 +0200 Subject: RIPE NCC does a series of interviews about IPv6 deployment Message-ID: <853AA034-4C0E-4244-B6B6-20AC3A26A7B7@ripe.net> As part of our IPv6 training project, that consists of face to face training and on-line learning modules and testimonials, I am proud to announce the first in a series of interviews. Andy Davidson of NetSumo ISP Consultancy discusses the IPv6 deployment they have done for their customers and themselves: http://www.youtube.com/watch?v=QCcigLJJbvU So far, we have interviewed 22 people from the community about their experiences and are very busy editing all the video material. In the coming months, you will be able to enjoy the rest of the interviews here: http://www.youtube.com/user/RIPENCC These interviews will also be published on our e-learning page and on our IPv6 Act Now website: http://ripe.net/training/e-learning/ http://www.ipv6actnow.org/ Cheers, Alex Band RIPE NCC From setient at gmail.com Thu May 28 11:49:27 2009 From: setient at gmail.com (Ronald Cotoni) Date: Thu, 28 May 2009 11:49:27 -0500 Subject: Why choose 120 volts? In-Reply-To: <1243527527.9604.142.camel@petrie> References: <4A1C455E.5080103@rollernet.us> <1243527527.9604.142.camel@petrie> Message-ID: <2f1d68350905280949w1ac1ae93kb159c6720032c61@mail.gmail.com> I have some similar input. At my company, we use both 120 and 208 volt depending on what servers we are putting in the racks. We can fill up every single rack to full capacity 100% of the time by using energy efficient servers. The fact that it is 120 volt or 208 volt hardly matters on most machines except Xeon/Opeteron class systems. We use a lot of Core 2 duo, Atom and Xeon Low Voltage processors. This allows us higher density on the same power and makes 208 volt mostly irrelevant. On Thu, May 28, 2009 at 11:18 AM, William Pitcock wrote: > On Tue, 2009-05-26 at 12:39 -0700, Seth Mattinen wrote: >> I have a pure curiosity question for the NANOG crowd here. If you run >> your facility/datacenter/cage/rack on 120 volts, why? >> > > We are using 120V in our colocation spaces. > >> I've been running my facility at 208 for years because I can get away >> with lower amperage circuits. I'm curious about the reasons for using >> high-amp 120 volt circuits to drive racks of equipment instead of >> low-amp 208 or 240 volt circuits. > > The reason why we are using 120V is because we have pre-existing > equipment (such as PDUs) that only support 120V operation. ?I believe > our newer PDUs support 120/208/240, but do not have the time to > investigate that, and we still have a couple of older APC units still in > service. ?Our servers don't really care which voltage we provide, most > of the PSUs can determine 120 vs 240 automatically, even. > > Also, at least at Equinix Chicago, 120V service was cheaper when we > colocated there. ?I do not know if this is the same case at Steadfast in > Chicago, and as far as I know, HE does not offer 208/240 service in > their Fremont-2 facility. ?I could be misinformed on that, though. > -- > William Pitcock > SystemInPlace - Simple Hosting Solutions > 1-866-519-6149 > > > From kilroy at WasHere.COM Thu May 28 11:55:48 2009 From: kilroy at WasHere.COM (Ric Messier) Date: Thu, 28 May 2009 10:55:48 -0600 (MDT) Subject: Packet loss statistics In-Reply-To: <4EA2196C-D6E1-45DD-A789-D5160067F15E@puck.nether.net> References: <4EA2196C-D6E1-45DD-A789-D5160067F15E@puck.nether.net> Message-ID: On Thu, 28 May 2009, Jared Mauch wrote: > > On May 28, 2009, at 12:03 PM, Ric Messier wrote: > >> >> Is anyone aware of useful resources for packet loss over large LANs and >> WANs? Google turned up a nice statistics page for Qwest's network but not >> much else that seems useful to me. >> >> Our testing teams are trying to simulate expected network conditions and >> rather than go overboard, having something close to real-world parameters >> would be nice. > > > Depending on what you want, you could use something like smokeping or > owamp to measure your network. (Both can be easily found via the goog). > Thanks, Jared. I'm not looking to quantify my network. I'm looking to introduce artificial errors into a test network to see the behavior against a product/system. I'd like to know if there is any data anywhere on what might be expected on an average network. I'm not sure there are such statistics, to be honest but thought I'd ask in the best place I knew to ask. Here is the Qwest link mentioned, by the way, in case anyone else is interested. http://stat.qwest.net/statqwest/perfRptIndex.jsp Ric From major at mhtx.net Thu May 28 12:35:24 2009 From: major at mhtx.net (Major Hayden) Date: Thu, 28 May 2009 12:35:24 -0500 Subject: XO fiber cut (unverified) in St. Louis, MO Message-ID: <67F5CD9D-8DD2-4322-AAC6-757C7A554C51@mhtx.net> I've heard an unverified report that XO may have a fiber cut somewhere in St. Louis. Has anyone heard something similar? -- Major Hayden major at mhtx.net From Peter.Charbonneau at williams.edu Thu May 28 14:47:15 2009 From: Peter.Charbonneau at williams.edu (Peter Charbonneau) Date: Thu, 28 May 2009 15:47:15 -0400 Subject: DNS ed.gov translations Message-ID: Greetings, Periodically, we loose the capability of translating .ed.gov names. Today, it seems that it is www.dl.ed.gov and www.fafsa.ed.gov that will not translate. If I use dig .... I get: porthos2:~ pcharbon2$ dig +trace www.fafsa.ed.gov ; <<>> DiG 9.4.3-P1 <<>> +trace www.fafsa.ed.gov ;; global options: printcmd . 499251 IN NS L.ROOT-SERVERS.NET. . 499251 IN NS M.ROOT-SERVERS.NET. . 499251 IN NS H.ROOT-SERVERS.NET. . 499251 IN NS D.ROOT-SERVERS.NET. . 499251 IN NS A.ROOT-SERVERS.NET. . 499251 IN NS K.ROOT-SERVERS.NET. . 499251 IN NS B.ROOT-SERVERS.NET. . 499251 IN NS G.ROOT-SERVERS.NET. . 499251 IN NS E.ROOT-SERVERS.NET. . 499251 IN NS I.ROOT-SERVERS.NET. . 499251 IN NS J.ROOT-SERVERS.NET. . 499251 IN NS C.ROOT-SERVERS.NET. . 499251 IN NS F.ROOT-SERVERS.NET. ;; Received 488 bytes from 137.165.4.21#53(137.165.4.21) in 2 ms gov. 172800 IN NS E.GOV.ZONEEDIT.COM. gov. 172800 IN NS G.GOV.ZONEEDIT.COM. gov. 172800 IN NS A.GOV.ZONEEDIT.COM. gov. 172800 IN NS B.GOV.ZONEEDIT.COM. gov. 172800 IN NS C.GOV.ZONEEDIT.COM. gov. 172800 IN NS D.GOV.ZONEEDIT.COM. gov. 172800 IN NS F.GOV.ZONEEDIT.COM. ;; Received 274 bytes from 192.203.230.10#53(E.ROOT-SERVERS.NET) in 82 ms ed.gov. 86400 IN NS eduptcdns02.ed.gov. ed.gov. 86400 IN NS eduftcdns01.ed.gov. ed.gov. 86400 IN NS eduftcdns02.ed.gov. ed.gov. 86400 IN NS eduptcdns01.ed.gov. ;; Received 202 bytes from 216.55.155.29#53(A.GOV.ZONEEDIT.COM) in 84 ms dig: couldn't get address for 'eduftcdns01.ed.gov': not found porthos2:~ pcharbon2$ It always seems to fail after the "third" lookup sequence. After about an hour (or two or eight) it starts working again for some period of time. I am out of troubleshooting tools and don't know where to go from here. Any help would be greatly appreciated. PeteC Peter Charbonneau Sr. Network and Systems Administrator Williams College (413) 597-3408 (office) (413) 822-2922 (cell) OIT will NEVER ask for your password! From brandon at rd.bbc.co.uk Thu May 28 14:54:00 2009 From: brandon at rd.bbc.co.uk (Brandon Butterworth) Date: Thu, 28 May 2009 20:54:00 +0100 (BST) Subject: Why choose 120 volts? Message-ID: <200905281954.UAA10143@sunf10.rd.bbc.co.uk> > > Admittedly no one I know is nuts enough to use body parts > > for "liveness testing". Depends whose parts they're using > Just to make things clear, I am NOT going to suggest you should do so, > just telling you what I think I heared. I'm waiting for Randy to suggest his competitors do so brandon From nonobvious at gmail.com Thu May 28 15:01:28 2009 From: nonobvious at gmail.com (Bill Stewart) Date: Thu, 28 May 2009 13:01:28 -0700 Subject: Packet loss statistics In-Reply-To: References: <4EA2196C-D6E1-45DD-A789-D5160067F15E@puck.nether.net> Message-ID: <18a5e7cb0905281301n5dddbc21p2ceca8884893d93d@mail.gmail.com> On Thu, May 28, 2009 at 9:55 AM, Ric Messier wrote: > Here is the Qwest link mentioned, by the way, in case anyone else is > interested. > > http://stat.qwest.net/statqwest/perfRptIndex.jsp The equivalent AT&T network performance portal page is http://www.att.com/ipnetwork and various pages linked to it. -- ---- 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 drc at virtualized.org Thu May 28 16:09:03 2009 From: drc at virtualized.org (David Conrad) Date: Thu, 28 May 2009 11:09:03 -1000 Subject: MX Record Theories In-Reply-To: References: <189373.71102.qm@web24704.mail.ird.yahoo.com> <163001.1243364471@turing-police.cc.vt.edu> Message-ID: <732246B8-7B31-43DA-A0E5-68271FCA623F@virtualized.org> On May 28, 2009, at 5:04 AM, Bobby Mac wrote: > If you add enough recipients to an email, each domain within the > send line > needs to have an associated MX record. Well, it needs to resolve to an A RR somehow, but for each domain name, you get a different query. > DNS by default starts with UDP which > has a limit to the datagram size (64bit). The UDP minimum datagram size that must be supported by DNS implementations is 512 bytes. The maximum is 64K bytes. Obviously if you try to send a 64K byte packet, it's going to fragment and as we all know, fragments are bad. > A flag is placed in the > header which then requires the request to be sent via TCP (160bit V4). If the response to a query won't fit in the UDP buffer (512 by default, although modern client implementations can advertise a larger buffer with EDNS0), the server will signal truncation in the response (with the TC bit), typically resulting in the client retransmitting the request via TCP. > Now > that single query can be split up into many different packets > providing that > the request is more than the 160 bit and obviously IPV6 offers even > more > information contained in a single packet. IPv6 packets are a bit larger, but not that much. DNSSEC is where the fun starts. Regards, -drc From adam at wispring.com Thu May 28 17:43:36 2009 From: adam at wispring.com (Adam Goodman) Date: Thu, 28 May 2009 18:43:36 -0400 Subject: problems with cisco 7200 and PA-T3 Message-ID: <7c2653830905281543k3fe3089cs64a8a73caff5aefe@mail.gmail.com> Just installed a cisco 7204vxr with a DS3 interface. we are not getting more than 5Mbits. show interface is not reporting any errors. the provider tech put a piece test equipment on the circuit and sees errors. Does anyone else use a cisco 7200 with a DS3 interface that we might be able to speak with? Please hit me off list Thank you, Adam 801.971.1856 From marka at isc.org Thu May 28 18:15:46 2009 From: marka at isc.org (Mark Andrews) Date: Fri, 29 May 2009 09:15:46 +1000 Subject: MX Record Theories In-Reply-To: Your message of "Thu, 28 May 2009 10:04:47 EST." Message-ID: <200905282315.n4SNFksV057801@drugs.dv.isc.org> In message , Bobby Mac writes: > Not entirely on subject but.... I thought that allowing DNS queries to > occur via TCP is mission critical for simple mail routing. We ran across > this back in the day at @Home Network. Firewall rules were changed to not > allow port 53 TCP. This severely affected sending mail to large > distribution lists. Here is what we found and forgive me if I don't go into > too much detail as it was almost 10 years a go. As I said, sites just don't do this as it causes serious problems. Sites that disable TCP/53 outbound just end up re-enabling it. Nameservers and stub resolvers automatically retry with TCP and the client applications just don't get answers returned when you start blocking TCP/53 outbound. It doesn't take long for said stupidity to be reversed. > If you add enough recipients to an email, each domain within the send line > needs to have an associated MX record. DNS by default starts with UDP which > has a limit to the datagram size (64bit). A flag is placed in the > header which then requires the request to be sent via TCP (160bit V4). Now > that single query can be split up into many different packets providing that > the request is more than the 160 bit and obviously IPV6 offers even more > information contained in a single packet. The number of recipients has no impact on the size of the DNS responses. It will have a impact on the number of DNS queries made iff the receipents are in multiple mail domains. Mark > -BobbyJim -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From marka at isc.org Thu May 28 19:37:35 2009 From: marka at isc.org (Mark Andrews) Date: Fri, 29 May 2009 10:37:35 +1000 Subject: DNS ed.gov translations In-Reply-To: Your message of "Thu, 28 May 2009 15:47:15 -0400." Message-ID: <200905290037.n4T0bZSd059553@drugs.dv.isc.org> In message , Peter Charbonneau writes: > Greetings, > > Periodically, we loose the capability of translating .ed.gov names. > > Today, it seems that it is www.dl.ed.gov and www.fafsa.ed.gov that > will not translate. > > If I use dig .... I get: > > porthos2:~ pcharbon2$ dig +trace www.fafsa.ed.gov > > ; <<>> DiG 9.4.3-P1 <<>> +trace www.fafsa.ed.gov > ;; global options: printcmd > . 499251 IN NS L.ROOT-SERVERS.NET. > . 499251 IN NS M.ROOT-SERVERS.NET. > . 499251 IN NS H.ROOT-SERVERS.NET. > . 499251 IN NS D.ROOT-SERVERS.NET. > . 499251 IN NS A.ROOT-SERVERS.NET. > . 499251 IN NS K.ROOT-SERVERS.NET. > . 499251 IN NS B.ROOT-SERVERS.NET. > . 499251 IN NS G.ROOT-SERVERS.NET. > . 499251 IN NS E.ROOT-SERVERS.NET. > . 499251 IN NS I.ROOT-SERVERS.NET. > . 499251 IN NS J.ROOT-SERVERS.NET. > . 499251 IN NS C.ROOT-SERVERS.NET. > . 499251 IN NS F.ROOT-SERVERS.NET. > ;; Received 488 bytes from 137.165.4.21#53(137.165.4.21) in 2 ms > > gov. 172800 IN NS E.GOV.ZONEEDIT.COM. > gov. 172800 IN NS G.GOV.ZONEEDIT.COM. > gov. 172800 IN NS A.GOV.ZONEEDIT.COM. > gov. 172800 IN NS B.GOV.ZONEEDIT.COM. > gov. 172800 IN NS C.GOV.ZONEEDIT.COM. > gov. 172800 IN NS D.GOV.ZONEEDIT.COM. > gov. 172800 IN NS F.GOV.ZONEEDIT.COM. > ;; Received 274 bytes from 192.203.230.10#53(E.ROOT-SERVERS.NET) in 82 > ms > > ed.gov. 86400 IN NS eduptcdns02.ed.gov. > ed.gov. 86400 IN NS eduftcdns01.ed.gov. > ed.gov. 86400 IN NS eduftcdns02.ed.gov. > ed.gov. 86400 IN NS eduptcdns01.ed.gov. > ;; Received 202 bytes from 216.55.155.29#53(A.GOV.ZONEEDIT.COM) in 84 ms > > dig: couldn't get address for 'eduftcdns01.ed.gov': not found > porthos2:~ pcharbon2$ > > > It always seems to fail after the "third" lookup sequence. > > After about an hour (or two or eight) it starts working again for some > period of time. > > I am out of troubleshooting tools and don't know where to go from > here. Any help would be greatly appreciated. > > > > PeteC > > > Peter Charbonneau > Sr. Network and Systems Administrator > Williams College > (413) 597-3408 (office) > (413) 822-2922 (cell) > OIT will NEVER ask for your password! What nameserver and version are you running? What options do you have turned on in the nameserver? What firewall settings do you have? Do you allow fragments through? Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From Peter.Charbonneau at williams.edu Thu May 28 20:06:55 2009 From: Peter.Charbonneau at williams.edu (Peter Charbonneau) Date: Thu, 28 May 2009 21:06:55 -0400 Subject: DNS ed.gov translations In-Reply-To: <200905290037.n4T0bZSd059553@drugs.dv.isc.org> References: <200905290037.n4T0bZSd059553@drugs.dv.isc.org> Message-ID: <3644FAC8-D61A-423A-8BB6-7C291F903B70@williams.edu> On May 28, 2009, at 8:37 PM, Mark Andrews wrote: > > In message , > Peter Charbonneau writes: >> Greetings, >> >> Periodically, we loose the capability of translating .ed.gov names. >> >> Today, it seems that it is www.dl.ed.gov and www.fafsa.ed.gov that >> will not translate. >> >> If I use dig .... I get: >> >> porthos2:~ pcharbon2$ dig +trace www.fafsa.ed.gov >> >> ; <<>> DiG 9.4.3-P1 <<>> +trace www.fafsa.ed.gov >> ;; global options: printcmd >> . 499251 IN NS L.ROOT-SERVERS.NET. >> . 499251 IN NS M.ROOT-SERVERS.NET. >> . 499251 IN NS H.ROOT-SERVERS.NET. >> . 499251 IN NS D.ROOT-SERVERS.NET. >> . 499251 IN NS A.ROOT-SERVERS.NET. >> . 499251 IN NS K.ROOT-SERVERS.NET. >> . 499251 IN NS B.ROOT-SERVERS.NET. >> . 499251 IN NS G.ROOT-SERVERS.NET. >> . 499251 IN NS E.ROOT-SERVERS.NET. >> . 499251 IN NS I.ROOT-SERVERS.NET. >> . 499251 IN NS J.ROOT-SERVERS.NET. >> . 499251 IN NS C.ROOT-SERVERS.NET. >> . 499251 IN NS F.ROOT-SERVERS.NET. >> ;; Received 488 bytes from 137.165.4.21#53(137.165.4.21) in 2 ms >> >> gov. 172800 IN NS E.GOV.ZONEEDIT.COM. >> gov. 172800 IN NS G.GOV.ZONEEDIT.COM. >> gov. 172800 IN NS A.GOV.ZONEEDIT.COM. >> gov. 172800 IN NS B.GOV.ZONEEDIT.COM. >> gov. 172800 IN NS C.GOV.ZONEEDIT.COM. >> gov. 172800 IN NS D.GOV.ZONEEDIT.COM. >> gov. 172800 IN NS F.GOV.ZONEEDIT.COM. >> ;; Received 274 bytes from 192.203.230.10#53(E.ROOT-SERVERS.NET) in >> 82 >> ms >> >> ed.gov. 86400 IN NS eduptcdns02.ed.gov. >> ed.gov. 86400 IN NS eduftcdns01.ed.gov. >> ed.gov. 86400 IN NS eduftcdns02.ed.gov. >> ed.gov. 86400 IN NS eduptcdns01.ed.gov. >> ;; Received 202 bytes from 216.55.155.29#53(A.GOV.ZONEEDIT.COM) in >> 84 ms >> >> dig: couldn't get address for 'eduftcdns01.ed.gov': not found >> porthos2:~ pcharbon2$ >> >> >> It always seems to fail after the "third" lookup sequence. >> >> After about an hour (or two or eight) it starts working again for >> some >> period of time. >> >> I am out of troubleshooting tools and don't know where to go from >> here. Any help would be greatly appreciated. >> >> >> >> PeteC >> >> >> Peter Charbonneau >> Sr. Network and Systems Administrator >> Williams College >> (413) 597-3408 (office) >> (413) 822-2922 (cell) >> OIT will NEVER ask for your password! > > What nameserver and version are you running? > What options do you have turned on in the nameserver? > What firewall settings do you have? Do you allow fragments > through? > > Mark > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka at isc.org Bind 9.4.2 -------------- named.conf options ----------------------------- options { directory "/var/named"; // sets root dir, use full path to escape statistics-file "/var/named/named.stats"; // stats are your friend dump-file "/var/named/named.dump"; zone-statistics yes; allow-recursion { 127.0.0.1; 137.165.0.0/16; }; // allow recursive lookups allow-transfer { none; }; // allow transfers to these IP's notify no; // dont notify the above IP's when a zone is updated, since we are a slave server pid-file "/var/run/named/named.pid"; transfer-format many-answers; // Generates more efficient zone transfers listen-on { any; }; }; // Include logging config file include "/var/named/conf/logging.conf"; // Include to ACLs include "/var/named/conf/acls.conf"; // Include TSIG Keys include "/etc/bind/keys.conf"; ------------------------------------------------------------------------ Firewalls are Cisco ASAs that pass all traffic to/from the nameservers. Fragments are allowed through. What dig (above) shows is typical of the problem we see. We get to that "tier" and one of the listed servers (in this case eduftcdns01.ed.gov) fails to respond. If I try to ping it or traceroute to it, I can't get to it. Shouldn't bind, then, try one of the other three servers listed? PeteC Peter Charbonneau Sr. Systems and Network Administrator Williams College (413) 597-3408 (D) (413) 822-2922 (C) From carlos at race.com Thu May 28 21:12:48 2009 From: carlos at race.com (Carlos Alcantar) Date: Thu, 28 May 2009 19:12:48 -0700 Subject: problems with cisco 7200 and PA-T3 Message-ID: <859604546CD1FF488BDB6EA94C896AFB776B29@racexchange.race.local> Adam you could be tx the errors so your interface won't see them. On the other side of the circuit are they seeing errors on the rx. -carlos -----Original Message----- From: Adam Goodman [mailto:adam at wispring.com] Sent: Thursday, May 28, 2009 3:44 PM To: nanog at nanog.org Subject: problems with cisco 7200 and PA-T3 Just installed a cisco 7204vxr with a DS3 interface. we are not getting more than 5Mbits. show interface is not reporting any errors. the provider tech put a piece test equipment on the circuit and sees errors. Does anyone else use a cisco 7200 with a DS3 interface that we might be able to speak with? Please hit me off list Thank you, Adam 801.971.1856 From wbailey at gci.com Thu May 28 21:41:16 2009 From: wbailey at gci.com (Warren Bailey) Date: Thu, 28 May 2009 18:41:16 -0800 Subject: problems with cisco 7200 and PA-T3 In-Reply-To: <7c2653830905281543k3fe3089cs64a8a73caff5aefe@mail.gmail.com> References: <7c2653830905281543k3fe3089cs64a8a73caff5aefe@mail.gmail.com> Message-ID: <5B3743FC2D0D8B41B27EE4F5EACA79D10A3BC2AB@DTN1EX01.gci.com> We have many 7200vxr's with DS3 interfaces. Though I am not sure this would be a interface problem. When you say that your provider sees errors on the circuit, where are they putting equipment? Is it an in-line test or an end to end test? Also, how is the DS3 being delivered? Be sure to check your coax and connectors. If you are only getting 5mbps on the line, I would ask your provider to come out and show you on a test set an end to end sweep from Point A to Point B. If you are getting data, and do not have AIS - I would assume somewhere something isn't up to spec physically. Feel free to ping me off list Adam. //warren Warren Bailey GCI Communication Corp. RF Network Engineering 907.868.5911 office 907.903.5410 mobile -----Original Message----- From: Adam Goodman [mailto:adam at wispring.com] Sent: Thursday, May 28, 2009 2:44 PM To: nanog at nanog.org Subject: problems with cisco 7200 and PA-T3 Just installed a cisco 7204vxr with a DS3 interface. we are not getting more than 5Mbits. show interface is not reporting any errors. the provider tech put a piece test equipment on the circuit and sees errors. Does anyone else use a cisco 7200 with a DS3 interface that we might be able to speak with? Please hit me off list Thank you, Adam 801.971.1856 From veerunanog at gmail.com Thu May 28 22:05:16 2009 From: veerunanog at gmail.com (Veerender Attri) Date: Thu, 28 May 2009 23:05:16 -0400 Subject: Issues through ATT core/backbone Message-ID: <1e8e00eb0905282005j7d16fa25j24e4370cd90488a8@mail.gmail.com> We have a few circuits with ATT and a few VZ. Since friday we have seen serveral intermittent issues throught ATT to reach various customers and our various remote offices. If we swing the traffic through VZ interfaces using static routes we can reach those locations fine. We were doing traceroutes during the issue and we saw the traceroutes dying inside ATT network. I was wondering if any one else saw similar issues ? On friday we saw issue between ATT and GBLX peering point. We saw similar issue on tuesday. And another one today. We sent to ATT various traceroutes and opened a few tickets but didnt really get any kind of confirmation. The problem seems to remedy itself on its own after 10-30 minutes. Please chime in if any one else saw similar issues transiting through AT&T or global crossing. From jay at west.net Thu May 28 22:22:22 2009 From: jay at west.net (Jay Hennigan) Date: Thu, 28 May 2009 20:22:22 -0700 Subject: problems with cisco 7200 and PA-T3 In-Reply-To: <7c2653830905281543k3fe3089cs64a8a73caff5aefe@mail.gmail.com> References: <7c2653830905281543k3fe3089cs64a8a73caff5aefe@mail.gmail.com> Message-ID: <4A1F54EE.5020603@west.net> Adam Goodman wrote: > Just installed a cisco 7204vxr with a DS3 interface. we are not getting more > than 5Mbits. > > show interface is not reporting any errors. the provider tech put a piece > test equipment on the circuit and sees errors. Do you have access to both ends of the circuit? No errors on either end? In which direction does the provider tech show errors and where in the circuit is the test set being placed? Does the test set show errors running to a hard (co-ax) loop? if so you have a problem with the span. Have you verified that there is exactly one clocking source on the circuit? > Does anyone else use a cisco 7200 with a DS3 interface that we might be able > to speak with? We have several. In some cases a 10dB attenuator is needed on the receive side if the carrier is too "hot" but this manifests as errors. -- Jay Hennigan - CCIE #7880 - Network Engineering - jay at impulse.net Impulse Internet Service - http://www.impulse.net/ Your local telephone and internet company - 805 884-6323 - WB6RDV From frnkblk at iname.com Thu May 28 23:59:48 2009 From: frnkblk at iname.com (Frank Bulk) Date: Thu, 28 May 2009 23:59:48 -0500 Subject: navog? In-Reply-To: <4A1EA0CD.1000003@infiltrated.net> References: <501309d50905280703p1b312594tc56fff5984fadbb6@mail.gmail.com> <4A1E9CA3.6020302@infiltrated.net> <4A1EA0CD.1000003@infiltrated.net> Message-ID: One more: isp-voiceoverip (http://isp-lists.isp-planet.com/isp-voiceoverip/resources/). Pretty quiet, though. Frank -----Original Message----- From: J. Oquendo [mailto:sil at infiltrated.net] Sent: Thursday, May 28, 2009 9:34 AM To: nanog at nanog.org Subject: Re: navog? Jared Mauch wrote: > > On May 28, 2009, at 10:16 AM, J. Oquendo wrote: > >> david hiers wrote: >>> Hi, >>> Is anyone aware of a voip-focused group similar to nanog? Us voip >>> pukes >>> have to deal with the issues of allocation, routing, and management >>> of phone >>> numbers as well as networks, and I have not found a voice operators' >>> group >>> similar to this network operators' group. >>> >>> >>> Thanks, >>> >>> David >>> >> On the other hand, I don't know that I'd want to see a multitude of >> messages >> from someone saying "My trixbox dialplan doesn't work!" or, (broken >> english >> purposely inserted) "Why my Cisco Call Manager is tell me to partition! > > Actually, there is a quite active cisco-voip list over on puck > that discusses exactly the CM issues you refer to. (I diverted > everyone to that list to keep it off c-nsp and it seems to have grown > since). > > - Jared > > http://puck.nether.net/mailman/listinfo/cisco-voip > (removed cc's to avoid sending dupes) Agreed, I browse through some of the stuff there and indeed it works for cisco telephony matters. Cisco staff has provided some really good guidance on matters there, as have Digium staffers for Asterisk's mailing list. But I can't really envision an "all inclusive" VoIP list with regards to the carrier end, equipment end, programming end, etc. Heaven knows I would have like to discuss Nortel and Avaya matters countless times but then those conversations would have actually ended up shifting towards SIP in which to a degree, they wouldn't have even had anything to do with the vendors at all. So I view it as a tough call. Anyhow, perhaps links should be included: http://voipsa.org/VOIPSEC/ (VoIPSA - VoIP Security related) http://puck.nether.net/mailman/listinfo/cisco-voip (Cisco VoIP related) http://lists.digium.com/mailman/listinfo/asterisk-users (Asterisk Users) http://groups.yahoo.com/group/sip-config (SIP Config (mainly spam now)) http://sipforum.org/pipermail/discussion/index.html (SIP forum) -- =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ J. Oquendo SGFA, SGFE, C|EH, CNDA, CHFI, OSCP "It takes 20 years to build a reputation and five minutes to ruin it. If you think about that, you'll do things differently." - Warren Buffett 227C 5D35 7DCB 0893 95AA 4771 1DCE 1FD1 5CCD 6B5E http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x5CCD6B5E From anton.zimm at gmail.com Fri May 29 01:06:51 2009 From: anton.zimm at gmail.com (Anton Zimm) Date: Fri, 29 May 2009 13:06:51 +0700 Subject: glue record Message-ID: <1e0e55280905282306v69cea6b7m22b7ea6e8dea6afe@mail.gmail.com> Hi, I'm looking for glue record for ns1.push.mobi?so I ask one of the root name server. It?gives me the list of dot mobi authorized name servers. I'm expecting it to be answered by one of the mobi tld authorized name servers, but it's telling me that it delegates the answer to ns1.push.mobi instead. It does not make sense for me because how can I ask ns1.push.mobi if I don't know its ip address yet... Clue please..? ----- az at hollywood:~$ dig @B2.MOBI.AFILIAS-NST.ORG. ns1.push.mobi .... ;; QUESTION SECTION: ;ns1.push.mobi.???????????????? IN????? A ;; AUTHORITY SECTION: push.mobi.????????????? 86400?? IN????? NS????? ns1.push.mobi. push.mobi.????????????? 86400?? IN????? NS????? ns2.push.mobi. ;; ADDITIONAL SECTION: ns1.push.mobi.????????? 86400?? IN????? A?????? 117.102.248.2 ns2.push.mobi.????????? 86400?? IN????? A?????? 117.102.248.3 ----- best, Anton. From scott at doc.net.au Fri May 29 01:12:15 2009 From: scott at doc.net.au (Scott Howard) Date: Thu, 28 May 2009 23:12:15 -0700 Subject: glue record In-Reply-To: <1e0e55280905282306v69cea6b7m22b7ea6e8dea6afe@mail.gmail.com> References: <1e0e55280905282306v69cea6b7m22b7ea6e8dea6afe@mail.gmail.com> Message-ID: Did you check the "ADDITIONAL SECTION" in what you've pasted below? Scott. On Thu, May 28, 2009 at 11:06 PM, Anton Zimm wrote: > Hi, > I'm looking for glue record for ns1.push.mobi so I ask one of the root > name server. > It gives me the list of dot mobi authorized name servers. > > I'm expecting it to be answered by one of the mobi tld authorized name > servers, but it's telling me that it delegates the answer to > ns1.push.mobi instead. It does not make sense for me because how can I > ask ns1.push.mobi if I don't know its ip address yet... > Clue please..? > > ----- > az at hollywood:~$ dig @B2.MOBI.AFILIAS-NST.ORG. ns1.push.mobi > .... > > ;; QUESTION SECTION: > ;ns1.push.mobi. IN A > > ;; AUTHORITY SECTION: > push.mobi. 86400 IN NS ns1.push.mobi. > push.mobi. 86400 IN NS ns2.push.mobi. > > ;; ADDITIONAL SECTION: > ns1.push.mobi. 86400 IN A 117.102.248.2 > ns2.push.mobi. 86400 IN A 117.102.248.3 > ----- > > best, > Anton. > > From john at vanoppen.com Fri May 29 01:13:22 2009 From: john at vanoppen.com (John van Oppen) Date: Thu, 28 May 2009 23:13:22 -0700 Subject: glue record References: <1e0e55280905282306v69cea6b7m22b7ea6e8dea6afe@mail.gmail.com> Message-ID: Because it gave you the IP of ns1 & ns2.push.mobi in the additional section? Looks like a pretty normal answer for a TLD server. John van Oppen Spectrum Networks LLC 206.973.8302 (Direct) 206.973.8300 (main office) -----Original Message----- From: Anton Zimm [mailto:anton.zimm at gmail.com] Sent: Thursday, May 28, 2009 11:07 PM To: nanog at nanog.org Subject: glue record Hi, I'm looking for glue record for ns1.push.mobi?so I ask one of the root name server. It?gives me the list of dot mobi authorized name servers. I'm expecting it to be answered by one of the mobi tld authorized name servers, but it's telling me that it delegates the answer to ns1.push.mobi instead. It does not make sense for me because how can I ask ns1.push.mobi if I don't know its ip address yet... Clue please..? ----- az at hollywood:~$ dig @B2.MOBI.AFILIAS-NST.ORG. ns1.push.mobi .... ;; QUESTION SECTION: ;ns1.push.mobi.???????????????? IN????? A ;; AUTHORITY SECTION: push.mobi.????????????? 86400?? IN????? NS????? ns1.push.mobi. push.mobi.????????????? 86400?? IN????? NS????? ns2.push.mobi. ;; ADDITIONAL SECTION: ns1.push.mobi.????????? 86400?? IN????? A?????? 117.102.248.2 ns2.push.mobi.????????? 86400?? IN????? A?????? 117.102.248.3 ----- best, Anton. From marka at isc.org Fri May 29 01:16:58 2009 From: marka at isc.org (Mark Andrews) Date: Fri, 29 May 2009 16:16:58 +1000 Subject: glue record In-Reply-To: Your message of "Fri, 29 May 2009 13:06:51 +0700." <1e0e55280905282306v69cea6b7m22b7ea6e8dea6afe@mail.gmail.com> Message-ID: <200905290616.n4T6GwBD087296@drugs.dv.isc.org> In message <1e0e55280905282306v69cea6b7m22b7ea6e8dea6afe at mail.gmail.com>, Anton Zimm writes: > Hi, > I'm looking for glue record for ns1.push.mobi so I ask one of the root > name server. > It gives me the list of dot mobi authorized name servers. > > I'm expecting it to be answered by one of the mobi tld authorized name > servers, but it's telling me that it delegates the answer to > ns1.push.mobi instead. It does not make sense for me because how can I > ask ns1.push.mobi if I don't know its ip address yet... > Clue please..? Did you bother to read the response? The glue records are in the *additional* section. Iterative resolvers know to look in the additional section to find glue records. Mark > ----- > az at hollywood:~$ dig @B2.MOBI.AFILIAS-NST.ORG. ns1.push.mobi > .... > > ;; QUESTION SECTION: > ;ns1.push.mobi. IN A > > ;; AUTHORITY SECTION: > push.mobi. 86400 IN NS ns1.push.mobi. > push.mobi. 86400 IN NS ns2.push.mobi. > > ;; ADDITIONAL SECTION: > ns1.push.mobi. 86400 IN A 117.102.248.2 > ns2.push.mobi. 86400 IN A 117.102.248.3 > ----- > > best, > Anton. > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From wbailey at gci.com Fri May 29 01:19:03 2009 From: wbailey at gci.com (Warren Bailey) Date: Thu, 28 May 2009 22:19:03 -0800 Subject: glue record In-Reply-To: References: <1e0e55280905282306v69cea6b7m22b7ea6e8dea6afe@mail.gmail.com> Message-ID: <5B3743FC2D0D8B41B27EE4F5EACA79D10A3BC2AF@DTN1EX01.gci.com> Beat me to it.. Bleh. Though I will admit, this reminds me of a very painful experience when I got my first dedicated server back in 1999. Death me to BIND. Glad I'm not a DNS admin :) //warren -----Original Message----- From: Scott Howard [mailto:scott at doc.net.au] Sent: Thursday, May 28, 2009 10:12 PM To: Anton Zimm Cc: nanog at nanog.org Subject: Re: glue record Did you check the "ADDITIONAL SECTION" in what you've pasted below? Scott. On Thu, May 28, 2009 at 11:06 PM, Anton Zimm wrote: > Hi, > I'm looking for glue record for ns1.push.mobi so I ask one of the root > name server. > It gives me the list of dot mobi authorized name servers. > > I'm expecting it to be answered by one of the mobi tld authorized name > servers, but it's telling me that it delegates the answer to > ns1.push.mobi instead. It does not make sense for me because how can I > ask ns1.push.mobi if I don't know its ip address yet... > Clue please..? > > ----- > az at hollywood:~$ dig @B2.MOBI.AFILIAS-NST.ORG. ns1.push.mobi .... > > ;; QUESTION SECTION: > ;ns1.push.mobi. IN A > > ;; AUTHORITY SECTION: > push.mobi. 86400 IN NS ns1.push.mobi. > push.mobi. 86400 IN NS ns2.push.mobi. > > ;; ADDITIONAL SECTION: > ns1.push.mobi. 86400 IN A 117.102.248.2 > ns2.push.mobi. 86400 IN A 117.102.248.3 > ----- > > best, > Anton. > > From rw at colt.net Fri May 29 01:47:19 2009 From: rw at colt.net (Ralf Weber) Date: Fri, 29 May 2009 08:47:19 +0200 Subject: DNS ed.gov translations In-Reply-To: <3644FAC8-D61A-423A-8BB6-7C291F903B70@williams.edu> References: <200905290037.n4T0bZSd059553@drugs.dv.isc.org> <3644FAC8-D61A-423A-8BB6-7C291F903B70@williams.edu> Message-ID: <1CD0D1FD-C4BF-4545-89CC-43667FC5C175@colt.net> Moin! On 29.05.2009, at 03:06, Peter Charbonneau wrote: > > Firewalls are Cisco ASAs that pass all traffic to/from the > nameservers. > Fragments are allowed through. Is this the firewall formerly known as PIX? If so we had problems with our DNS server until we put the following line in our configuration: fixup protocol dns maximum-length 4096 Maybe this helps. So long -Ralf --- Ralf Weber Platform Infrastructure Manager Colt Telecom GmbH Herriotstrasse 4 60528 Frankfurt Germany DDI: +49 (0)69 56606 2780 Internal OneDial: 8 491 2780 Fax: +49 (0)69 56606 6280 Email: rw at colt.net http://www.colt.net/ Data | Voice | Managed Services Sch?tze Deine Umwelt | Erst denken, dann drucken ***************************************** COLT Telecom GmbH, Herriotstra?e 4, 60528 Frankfurt/Main, Deutschland * Tel +49 (0)69 56606 0 * Fax +49 (0)69 56606 2222 * Gesch?ftsf?hrer: Dr. J?rgen Hernichel (Vors.), Rita Thies * Amtsgericht Frankfurt/Main HRB 46123 * USt.-IdNr. DE 197 498 400 From wbailey at gci.com Fri May 29 02:04:53 2009 From: wbailey at gci.com (Warren Bailey) Date: Thu, 28 May 2009 23:04:53 -0800 Subject: DNS ed.gov translations Message-ID: <5B3743FC2D0D8B41B27EE4F5EACA79D108970F65@DTN1EX01.gci.com> I elect Ralf as owner of the longest email signature in history.. ----- Original Message ----- From: Ralf Weber To: Peter Charbonneau Cc: nanog at nanog.org Sent: Thu May 28 22:47:19 2009 Subject: Re: DNS ed.gov translations Moin! On 29.05.2009, at 03:06, Peter Charbonneau wrote: > > Firewalls are Cisco ASAs that pass all traffic to/from the > nameservers. > Fragments are allowed through. Is this the firewall formerly known as PIX? If so we had problems with our DNS server until we put the following line in our configuration: fixup protocol dns maximum-length 4096 Maybe this helps. So long -Ralf --- Ralf Weber Platform Infrastructure Manager Colt Telecom GmbH Herriotstrasse 4 60528 Frankfurt Germany DDI: +49 (0)69 56606 2780 Internal OneDial: 8 491 2780 Fax: +49 (0)69 56606 6280 Email: rw at colt.net http://www.colt.net/ Data | Voice | Managed Services Sch?tze Deine Umwelt | Erst denken, dann drucken ***************************************** COLT Telecom GmbH, Herriotstra?e 4, 60528 Frankfurt/Main, Deutschland * Tel +49 (0)69 56606 0 * Fax +49 (0)69 56606 2222 * Gesch?ftsf?hrer: Dr. J?rgen Hernichel (Vors.), Rita Thies * Amtsgericht Frankfurt/Main HRB 46123 * USt.-IdNr. DE 197 498 400 From anton.zimm at gmail.com Fri May 29 02:09:41 2009 From: anton.zimm at gmail.com (Anton Zimm) Date: Fri, 29 May 2009 14:09:41 +0700 Subject: glue record In-Reply-To: References: <1e0e55280905282306v69cea6b7m22b7ea6e8dea6afe@mail.gmail.com> Message-ID: <1e0e55280905290009q3556779dy29b50b918890fb69@mail.gmail.com> I did see the info from additional section, but: Afaik the additional section is not an answer, they're just additional info, not an authorized answer from the queried name server. I'm expecting to get a reply for my 'A' query in the 'answer section'. Now, from the 'authority section' dig is telling me that I can get the authorize answer from ns1.push.mobi. But isn't that circular dependency? Anton. On Fri, May 29, 2009 at 1:12 PM, Scott Howard wrote: > Did you check the "ADDITIONAL SECTION" in what you've pasted below? > > ? Scott. > > > On Thu, May 28, 2009 at 11:06 PM, Anton Zimm wrote: >> >> Hi, >> I'm looking for glue record for ns1.push.mobi?so I ask one of the root >> name server. >> It?gives me the list of dot mobi authorized name servers. >> >> I'm expecting it to be answered by one of the mobi tld authorized name >> servers, but it's telling me that it delegates the answer to >> ns1.push.mobi instead. It does not make sense for me because how can I >> ask ns1.push.mobi if I don't know its ip address yet... >> Clue please..? >> >> ----- >> az at hollywood:~$ dig @B2.MOBI.AFILIAS-NST.ORG. ns1.push.mobi >> .... >> >> ;; QUESTION SECTION: >> ;ns1.push.mobi.???????????????? IN????? A >> >> ;; AUTHORITY SECTION: >> push.mobi.????????????? 86400?? IN????? NS????? ns1.push.mobi. >> push.mobi.????????????? 86400?? IN????? NS????? ns2.push.mobi. >> >> ;; ADDITIONAL SECTION: >> ns1.push.mobi.????????? 86400?? IN????? A?????? 117.102.248.2 >> ns2.push.mobi.????????? 86400?? IN????? A?????? 117.102.248.3 >> ----- >> >> best, >> Anton. >> From fweimer at bfk.de Fri May 29 02:13:13 2009 From: fweimer at bfk.de (Florian Weimer) Date: Fri, 29 May 2009 09:13:13 +0200 Subject: DNS ed.gov translations In-Reply-To: (Peter Charbonneau's message of "Thu\, 28 May 2009 15\:47\:15 -0400") References: Message-ID: <82prdsgz5i.fsf@mid.bfk.de> * Peter Charbonneau: > ed.gov. 86400 IN NS eduptcdns02.ed.gov. > ed.gov. 86400 IN NS eduftcdns01.ed.gov. > ed.gov. 86400 IN NS eduftcdns02.ed.gov. > ed.gov. 86400 IN NS eduptcdns01.ed.gov. > ;; Received 202 bytes from 216.55.155.29#53(A.GOV.ZONEEDIT.COM) in 84 ms > > dig: couldn't get address for 'eduftcdns01.ed.gov': not found This looks more like a "lack of glue" issue. The next time thiss happens, please use "dig www.fafsa.ed.gov +trace +all +norecurse" for diagnostics (one additional run with the "+dnssec" flag might be helpful, too). -- Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra?e 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From fweimer at bfk.de Fri May 29 02:16:08 2009 From: fweimer at bfk.de (Florian Weimer) Date: Fri, 29 May 2009 09:16:08 +0200 Subject: glue record In-Reply-To: <1e0e55280905290009q3556779dy29b50b918890fb69@mail.gmail.com> (Anton Zimm's message of "Fri\, 29 May 2009 14\:09\:41 +0700") References: <1e0e55280905282306v69cea6b7m22b7ea6e8dea6afe@mail.gmail.com> <1e0e55280905290009q3556779dy29b50b918890fb69@mail.gmail.com> Message-ID: <82ljoggz0n.fsf@mid.bfk.de> * Anton Zimm: > I did see the info from additional section, but: > > Afaik the additional section is not an answer, they're just additional > info, not an authorized answer from the queried name server. I'm > expecting to get a reply for my 'A' query in the 'answer section'. The MOBI. servers are not authoritative for PUSH.MOBI., so returning data from PUSH.MOBI. in the answer section would be wrong. (ATLAS does this, but this doesn't make it right.) > Now, from the 'authority section' dig is telling me that I can get the > authorize answer from ns1.push.mobi. But isn't that circular > dependency? That's why the address is in the additional section. -- 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 scott at doc.net.au Fri May 29 02:36:49 2009 From: scott at doc.net.au (Scott Howard) Date: Fri, 29 May 2009 00:36:49 -0700 Subject: glue record In-Reply-To: <1e0e55280905290009q3556779dy29b50b918890fb69@mail.gmail.com> References: <1e0e55280905282306v69cea6b7m22b7ea6e8dea6afe@mail.gmail.com> <1e0e55280905290009q3556779dy29b50b918890fb69@mail.gmail.com> Message-ID: On Fri, May 29, 2009 at 12:09 AM, Anton Zimm wrote: > Now, from the 'authority section' dig is telling me that I can get the > authorize answer from ns1.push.mobi. But isn't that circular > dependency? http://en.wikipedia.org/wiki/Domain_name_system#Circular_dependencies_and_glue_records No offense, but a few minutes on Google should be able to tell you far more than you will ever need to know about how glue works (The above URL is the #1 hit for "dns glue") Scott From anton.zimm at gmail.com Fri May 29 02:48:33 2009 From: anton.zimm at gmail.com (Anton Zimm) Date: Fri, 29 May 2009 14:48:33 +0700 Subject: glue record In-Reply-To: <82ljoggz0n.fsf@mid.bfk.de> References: <1e0e55280905282306v69cea6b7m22b7ea6e8dea6afe@mail.gmail.com> <1e0e55280905290009q3556779dy29b50b918890fb69@mail.gmail.com> <82ljoggz0n.fsf@mid.bfk.de> Message-ID: <1e0e55280905290048sf16089ehc94f585399206b42@mail.gmail.com> On Fri, May 29, 2009 at 2:16 PM, Florian Weimer wrote: > * Anton Zimm: > >> I did see the info from additional section, but: >> >> Afaik the additional section is not an answer, they're just additional >> info, not an authorized answer from the queried name server. I'm >> expecting to get a reply for my 'A' query in the 'answer section'. > > The MOBI. servers are not authoritative for PUSH.MOBI., so returning > data from PUSH.MOBI. in the answer section would be wrong. I get this: MOBI servers are not authoritative for push.mobi zone, ns1.push.mobi is authoritative for it. But since ns1.push.mobi is inside push.mobi zone, this create circular reference. Afaik to solve this circular dependency, there has to be a Glue record for ns1.push.mobi somewhere in root nameservers or mobi nameservers. I can not find the Glue Record. Where is the Glue Record? Anton. From karnaugh at karnaugh.za.net Fri May 29 02:52:29 2009 From: karnaugh at karnaugh.za.net (Colin Alston) Date: Fri, 29 May 2009 09:52:29 +0200 Subject: glue record In-Reply-To: <1e0e55280905290048sf16089ehc94f585399206b42@mail.gmail.com> References: <1e0e55280905282306v69cea6b7m22b7ea6e8dea6afe@mail.gmail.com> <1e0e55280905290009q3556779dy29b50b918890fb69@mail.gmail.com> <82ljoggz0n.fsf@mid.bfk.de> <1e0e55280905290048sf16089ehc94f585399206b42@mail.gmail.com> Message-ID: <4A1F943D.4000406@karnaugh.za.net> On 2009/05/29 09:48 AM Anton Zimm wrote: > On Fri, May 29, 2009 at 2:16 PM, Florian Weimer wrote: > > * Anton Zimm: > > > >> I did see the info from additional section, but: > >> > >> Afaik the additional section is not an answer, they're just additional > >> info, not an authorized answer from the queried name server. I'm > >> expecting to get a reply for my 'A' query in the 'answer section'. > > > > The MOBI. servers are not authoritative for PUSH.MOBI., so returning > > data from PUSH.MOBI. in the answer section would be wrong. > > I get this: MOBI servers are not authoritative for push.mobi zone, > ns1.push.mobi is authoritative for it. > > But since ns1.push.mobi is inside push.mobi zone, this create circular > reference. Afaik to solve this circular dependency, there has to be a > Glue record for ns1.push.mobi somewhere in root nameservers or mobi > nameservers. > > I can not find the Glue Record. Where is the Glue Record? > IN THE ADDITIONAL SECTION!!!! From fweimer at bfk.de Fri May 29 02:53:13 2009 From: fweimer at bfk.de (Florian Weimer) Date: Fri, 29 May 2009 09:53:13 +0200 Subject: glue record In-Reply-To: <1e0e55280905290048sf16089ehc94f585399206b42@mail.gmail.com> (Anton Zimm's message of "Fri\, 29 May 2009 14\:48\:33 +0700") References: <1e0e55280905282306v69cea6b7m22b7ea6e8dea6afe@mail.gmail.com> <1e0e55280905290009q3556779dy29b50b918890fb69@mail.gmail.com> <82ljoggz0n.fsf@mid.bfk.de> <1e0e55280905290048sf16089ehc94f585399206b42@mail.gmail.com> Message-ID: <82octcfiqe.fsf@mid.bfk.de> * Anton Zimm: > I can not find the Glue Record. Where is the Glue Record? It's in the additional section. -- 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 james at now.ie Fri May 29 04:53:42 2009 From: james at now.ie (James Raftery) Date: Fri, 29 May 2009 10:53:42 +0100 Subject: glue record In-Reply-To: <1e0e55280905290048sf16089ehc94f585399206b42@mail.gmail.com> References: <1e0e55280905282306v69cea6b7m22b7ea6e8dea6afe@mail.gmail.com> <1e0e55280905290009q3556779dy29b50b918890fb69@mail.gmail.com> <82ljoggz0n.fsf@mid.bfk.de> <1e0e55280905290048sf16089ehc94f585399206b42@mail.gmail.com> Message-ID: <20090529095342.GA88385@morbo.kerna.ie> On Fri, May 29, 2009 at 02:48:33PM +0700, Anton Zimm wrote: > I can not find the Glue Record. Where is the Glue Record? You've been told where it is. Stop repeating the question. Its answer won't change. james -- The probable future is that in time, the use of the apostrophe-s will become the default for all occurrences of the letter s at the end of a word. So we are soon likely to assume it's normal to see apostrophe's at the end of word's, even though reader's of mature year's might think it suck's. -- Dave Williams, comp.risks. From anton.zimm at gmail.com Fri May 29 05:19:59 2009 From: anton.zimm at gmail.com (Anton Zimm) Date: Fri, 29 May 2009 17:19:59 +0700 Subject: glue record In-Reply-To: References: <1e0e55280905282306v69cea6b7m22b7ea6e8dea6afe@mail.gmail.com> <1e0e55280905290009q3556779dy29b50b918890fb69@mail.gmail.com> Message-ID: <1e0e55280905290319r75533eb0k58b5196006e743b5@mail.gmail.com> On Fri, May 29, 2009 at 2:36 PM, Scott Howard wrote: > > On Fri, May 29, 2009 at 12:09 AM, Anton Zimm wrote: >> >> Now, from the 'authority section' dig is telling me that I can get the >> authorize answer from ns1.push.mobi. But isn't that circular >> dependency? > > http://en.wikipedia.org/wiki/Domain_name_system#Circular_dependencies_and_glue_records > > No offense, but a few minutes on Google should be able to tell you far more than you will ever need to know about how glue works (The above URL is the #1 hit for "dns glue") > Scott, I did google and check wikipedia and other sources before posting the initial question. I didn't understand it thoroughly before, I think I understand more now. thank's, Anton. From carl.ford at gmail.com Fri May 29 06:15:01 2009 From: carl.ford at gmail.com (Carl Ford) Date: Fri, 29 May 2009 07:15:01 -0400 Subject: navog? In-Reply-To: References: <501309d50905280703p1b312594tc56fff5984fadbb6@mail.gmail.com> <4A1E9CA3.6020302@infiltrated.net> <4A1EA0CD.1000003@infiltrated.net> Message-ID: VoIP related issues is one of the reason I lurk here. On carrier routing side voice (including VoIP) is still a closed network. The group has given references for vendor oriented the efforts of the i3forum http://www.i3forum.org/ John Todd has a list called freenum http://www.freenum.org/ which may proof useful. IPTELs http://www.iptel.org/ SER group is a good place for a lot of discussion and you should look at the diverging links at OpenSER. Everything else is someone closed. GSMA IPX, ENUM, etc. If you have specific groups you are looking to talk to I have some further references. And you can contact me directly. Kind Regards, carl On Fri, May 29, 2009 at 12:59 AM, Frank Bulk wrote: > One more: isp-voiceoverip > (http://isp-lists.isp-planet.com/isp-voiceoverip/resources/). Pretty > quiet, > though. > > Frank > > -----Original Message----- > From: J. Oquendo [mailto:sil at infiltrated.net] > Sent: Thursday, May 28, 2009 9:34 AM > To: nanog at nanog.org > Subject: Re: navog? > > Jared Mauch wrote: > > > > On May 28, 2009, at 10:16 AM, J. Oquendo wrote: > > > >> david hiers wrote: > >>> Hi, > >>> Is anyone aware of a voip-focused group similar to nanog? Us voip > >>> pukes > >>> have to deal with the issues of allocation, routing, and management > >>> of phone > >>> numbers as well as networks, and I have not found a voice operators' > >>> group > >>> similar to this network operators' group. > >>> > >>> > >>> Thanks, > >>> > >>> David > >>> > >> On the other hand, I don't know that I'd want to see a multitude of > >> messages > >> from someone saying "My trixbox dialplan doesn't work!" or, (broken > >> english > >> purposely inserted) "Why my Cisco Call Manager is tell me to partition! > > > > Actually, there is a quite active cisco-voip list over on puck > > that discusses exactly the CM issues you refer to. (I diverted > > everyone to that list to keep it off c-nsp and it seems to have grown > > since). > > > > - Jared > > > > http://puck.nether.net/mailman/listinfo/cisco-voip > > > (removed cc's to avoid sending dupes) > > Agreed, I browse through some of the stuff there and indeed it works > for cisco telephony matters. Cisco staff has provided some really > good guidance on matters there, as have Digium staffers for Asterisk's > mailing list. But I can't really envision an "all inclusive" VoIP list with > regards to the carrier end, equipment end, programming end, etc. > Heaven knows I would have like to discuss Nortel and Avaya matters > countless times but then those conversations would have actually > ended up shifting towards SIP in which to a degree, they wouldn't > have even had anything to do with the vendors at all. So I view it > as a tough call. > > Anyhow, perhaps links should be included: > > http://voipsa.org/VOIPSEC/ (VoIPSA - VoIP Security related) > http://puck.nether.net/mailman/listinfo/cisco-voip (Cisco VoIP related) > http://lists.digium.com/mailman/listinfo/asterisk-users (Asterisk Users) > http://groups.yahoo.com/group/sip-config (SIP Config (mainly spam now)) > http://sipforum.org/pipermail/discussion/index.html (SIP forum) > > -- > =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ > J. Oquendo > SGFA, SGFE, C|EH, CNDA, CHFI, OSCP > > "It takes 20 years to build a reputation and five minutes to > ruin it. If you think about that, you'll do things > differently." - Warren Buffett > > 227C 5D35 7DCB 0893 95AA 4771 1DCE 1FD1 5CCD 6B5E > http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x5CCD6B5E > > > > > -- Carl Ford 201-920-2773 From cidr-report at potaroo.net Fri May 29 07:00:15 2009 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 29 May 2009 22:00:15 +1000 (EST) Subject: BGP Update Report Message-ID: <200905291200.n4TC0Fkm055766@wattle.apnic.net> BGP Update Report Interval: 27-Apr-09 -to- 28-May-09 (32 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS6389 57046 1.0% 13.1 -- BELLSOUTH-NET-BLK - BellSouth.net Inc. 2 - AS3130 56336 1.0% 219.2 -- RGNET-3130 RGnet/PSGnet 3 - AS21491 54810 0.9% 1827.0 -- UTL-ON-LINE UTL On-line is RF broadband ISP in Uganda - Africa 4 - AS8452 52258 0.9% 40.8 -- TEDATA TEDATA 5 - AS9198 49179 0.8% 195.2 -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration 6 - AS8151 48481 0.8% 12.5 -- Uninet S.A. de C.V. 7 - AS35805 45909 0.8% 127.2 -- UTG-AS United Telecom AS 8 - AS10834 35770 0.6% 14.1 -- Telefonica Data Argentina S.A. 9 - AS5056 35066 0.6% 297.2 -- INS-NET-2 - Iowa Network Services 10 - AS17974 34031 0.6% 31.3 -- TELKOMNET-AS2-AP PT Telekomunikasi Indonesia 11 - AS20115 33737 0.6% 20.0 -- CHARTER-NET-HKY-NC - Charter Communications 12 - AS33776 32231 0.6% 277.9 -- STARCOMMS-ASN 13 - AS17488 31963 0.5% 18.9 -- HATHWAY-NET-AP Hathway IP Over Cable Internet 14 - AS4323 30316 0.5% 7.0 -- TWTC - tw telecom holdings, inc. 15 - AS4249 28270 0.5% 156.2 -- LILLY-AS - Eli Lilly and Company 16 - AS30890 26540 0.5% 48.8 -- EVOLVA Evolva Telecom 17 - AS2920 25925 0.4% 316.2 -- LACOE - Los Angeles County Office of Education 18 - AS29372 25184 0.4% 318.8 -- SFR-NETWORK SFR 19 - AS5050 25141 0.4% 1795.8 -- PSC-EXT - Pittsburgh Supercomputing Center 20 - AS10620 23454 0.4% 23.7 -- TV Cable S.A. TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS16931 17007 0.3% 8503.5 -- GLOBAL-PAYMENTS-1 - Global Payments, Inc. 2 - AS15045 16892 0.3% 4223.0 -- KITTELSON - KITTELSON AND ASSOCIATES, INC. 3 - AS2 3535 0.1% 4.0 -- NAVITAIRE-AS-AU-AP Accenture - Navitaire, 4 - AS32398 20671 0.3% 3445.2 -- REALNET-ASN-1 5 - AS13153 2542 0.0% 2542.0 -- ONEWORLD OneWorld S.A. 6 - AS29229 2444 0.0% 2444.0 -- ASDA-AS Assotiation for the Development of West Athens 7 - AS13325 18334 0.3% 2291.8 -- STOMI - State of Michigan, DMB-CNOC 8 - AS8499 2252 0.0% 2252.0 -- Space Hellas Network Operation Center (NOC) 9 - AS39803 4065 0.1% 2032.5 -- UTI-AS SC UTI COMMUNICATIONS SYSTEMS SRL 10 - AS39699 5751 0.1% 1917.0 -- SSPOY-AS Salon Seudun Puhelin Oy 11 - AS47640 5542 0.1% 1847.3 -- TRICOMPAS Tricomp Sp. z. o. o. 12 - AS21491 54810 0.9% 1827.0 -- UTL-ON-LINE UTL On-line is RF broadband ISP in Uganda - Africa 13 - AS5050 25141 0.4% 1795.8 -- PSC-EXT - Pittsburgh Supercomputing Center 14 - AS17236 1271 0.0% 1271.0 -- TULSAL-74103 - Tulsa City-County Library 15 - AS35400 7569 0.1% 1261.5 -- MFIST Interregoinal Organization Network Technologies 16 - AS28256 1241 0.0% 1241.0 -- 17 - AS40967 1237 0.0% 1237.0 -- CSF-AS CSF Computersoftware fuer Fachanwendungen GmbH 18 - AS28953 2317 0.0% 1158.5 -- PIRAEUSBANK Greek banking institution 19 - AS47299 1086 0.0% 1086.0 -- DRSA-AS Dlugie Rozmowy S.A. 20 - AS41492 1079 0.0% 1079.0 -- EXIMBANK-AS SC Eximbank SA TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 72.23.246.0/24 24675 0.4% AS5050 -- PSC-EXT - Pittsburgh Supercomputing Center 2 - 41.204.2.0/24 20577 0.3% AS32398 -- REALNET-ASN-1 3 - 64.69.192.0/20 16997 0.3% AS16931 -- GLOBAL-PAYMENTS-1 - Global Payments, Inc. 4 - 192.12.120.0/24 10455 0.2% AS5691 -- MITRE-AS-5 - The MITRE Corporation 5 - 123.49.152.0/24 7531 0.1% AS18118 -- CITICNET-AP CITIC Networks Management Co.,Ltd. 6 - 90.150.0.0/24 7241 0.1% AS35400 -- MFIST Interregoinal Organization Network Technologies 7 - 63.144.223.0/24 7006 0.1% AS30221 -- T3COM - T3 Communications, Inc. 8 - 123.49.144.0/21 6882 0.1% AS18118 -- CITICNET-AP CITIC Networks Management Co.,Ltd. 9 - 89.218.218.0/23 6785 0.1% AS9198 -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration 10 - 89.218.220.0/23 6781 0.1% AS9198 -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration 11 - 92.46.244.0/23 6777 0.1% AS9198 -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration 12 - 95.59.4.0/22 6772 0.1% AS9198 -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration 13 - 95.59.2.0/23 6769 0.1% AS9198 -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration 14 - 95.59.8.0/23 6766 0.1% AS9198 -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration 15 - 72.42.204.0/23 6711 0.1% AS40060 -- AAAWI - AAA Wireless, Inc. 16 - 195.96.69.0/24 6244 0.1% AS8225 -- ASTELIT-MSK-AS Astelit Autonomous System 17 - 63.103.104.0/22 5861 0.1% AS15045 -- KITTELSON - KITTELSON AND ASSOCIATES, INC. 18 - 63.103.108.0/23 5861 0.1% AS15045 -- KITTELSON - KITTELSON AND ASSOCIATES, INC. 19 - 193.201.184.0/21 5846 0.1% AS25546 -- BROOKLANDCOMP-AS Brookland Computer Services 20 - 81.199.18.0/24 5671 0.1% AS21491 -- UTL-ON-LINE UTL On-line is RF broadband ISP in Uganda - Africa Details at http://bgpupdates.potaroo.net ------------------------------------ Copies of this report are mailed to: nanog at merit.edu eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From cidr-report at potaroo.net Fri May 29 07:00:04 2009 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 29 May 2009 22:00:04 +1000 (EST) Subject: The Cidr Report Message-ID: <200905291200.n4TC04gj055731@wattle.apnic.net> This report has been generated at Fri May 29 21:18:11 2009 AEST. The report analyses the BGP Routing Table of AS2.0 router and generates a report on aggregation potential within the table. Check http://www.cidr-report.org for a current version of this report. Recent Table History Date Prefixes CIDR Agg 22-05-09 294690 184799 23-05-09 295551 184429 24-05-09 294596 184340 25-05-09 294770 184572 26-05-09 294994 184468 27-05-09 295000 184460 28-05-09 295111 184373 29-05-09 295132 184408 AS Summary 31436 Number of ASes in routing system 13388 Number of ASes announcing only one prefix 4292 Largest number of prefixes announced by an AS AS6389 : BELLSOUTH-NET-BLK - BellSouth.net Inc. 89742080 Largest address span announced by an AS (/32s) AS27064: DNIC-ASBLK-27032-27159 - DoD Network Information Center Aggregation Summary The algorithm used in this report proposes aggregation only when there is a precise match using the AS path, so as to preserve traffic transit policies. Aggregation is also proposed across non-advertised address space ('holes'). --- 29May09 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 295258 184521 110737 37.5% All ASes AS6389 4292 338 3954 92.1% BELLSOUTH-NET-BLK - BellSouth.net Inc. AS4323 4274 1782 2492 58.3% TWTC - tw telecom holdings, inc. AS209 2540 1160 1380 54.3% ASN-QWEST - Qwest Communications Corporation AS4766 1811 520 1291 71.3% KIXS-AS-KR Korea Telecom AS17488 1587 303 1284 80.9% HATHWAY-NET-AP Hathway IP Over Cable Internet AS4755 1250 147 1103 88.2% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP AS22773 1059 68 991 93.6% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. AS1785 1699 786 913 53.7% AS-PAETEC-NET - PaeTec Communications, Inc. AS8452 1202 318 884 73.5% TEDATA TEDATA AS8151 1451 581 870 60.0% Uninet S.A. de C.V. AS19262 998 238 760 76.2% VZGNI-TRANSIT - Verizon Internet Services Inc. AS18566 1062 424 638 60.1% COVAD - Covad Communications Co. AS18101 749 161 588 78.5% RIL-IDC Reliance Infocom Ltd Internet Data Centre, AS6478 1398 822 576 41.2% ATT-INTERNET3 - AT&T WorldNet Services AS11492 1102 549 553 50.2% CABLEONE - CABLE ONE, INC. AS855 623 102 521 83.6% CANET-ASN-4 - Bell Aliant Regional Communications, Inc. AS22047 580 83 497 85.7% VTR BANDA ANCHA S.A. AS2706 536 44 492 91.8% HKSUPER-HK-AP Pacific Internet (Hong Kong) Limited AS17676 564 80 484 85.8% GIGAINFRA Softbank BB Corp. AS4134 890 416 474 53.3% CHINANET-BACKBONE No.31,Jin-rong Street AS7018 1500 1034 466 31.1% ATT-INTERNET4 - AT&T WorldNet Services AS4808 637 171 466 73.2% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network AS9443 526 94 432 82.1% INTERNETPRIMUS-AS-AP Primus Telecommunications AS24560 693 270 423 61.0% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services AS7545 801 379 422 52.7% TPG-INTERNET-AP TPG Internet Pty Ltd AS4804 679 261 418 61.6% MPX-AS Microplex PTY LTD AS6517 652 239 413 63.3% RELIANCEGLOBALCOM - Reliance Globalcom Services, Inc AS7011 974 561 413 42.4% FRONTIER-AND-CITIZENS - Frontier Communications of America, Inc. AS4668 691 283 408 59.0% LGNET-AS-KR LG CNS AS4780 529 134 395 74.7% SEEDNET Digital United Inc. Total 37349 12348 25001 66.9% Top 30 total Possible Bogus Routes 24.245.128.0/17 AS11492 CABLEONE - CABLE ONE, INC. 41.223.112.0/22 AS5713 SAIX-NET 41.223.176.0/22 AS36981 41.223.188.0/24 AS22351 INTELSAT Intelsat Global BGP Routing Policy 41.223.189.0/24 AS26452 BRING-AS - BringCom, Inc. 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV - Wireless Broadband via Satellite 62.61.221.0/24 AS24974 TACHYON-EU Tachyon Europe BV - Wireless Broadband via Satellite 63.140.213.0/24 AS22555 UTC - Universal Talkware Corporation 63.143.251.0/24 AS22555 UTC - Universal Talkware Corporation 64.31.32.0/19 AS11955 SCRR-11955 - Road Runner HoldCo LLC 64.31.59.0/24 AS7017 SCRR-7015 - Road Runner HoldCo LLC 64.31.60.0/24 AS7017 SCRR-7015 - Road Runner HoldCo LLC 64.79.88.0/24 AS26096 LODDEN - Lodden Services 64.79.89.0/24 AS26096 LODDEN - Lodden Services 66.54.91.0/24 AS30506 BLACKSUN-1 - Blacksun Technologies LLC 66.55.160.0/19 AS29994 66.128.38.0/24 AS15246 Telecomunicaciones Satelitales TelesatS.A. 66.180.239.0/24 AS35888 VIGNETTE - VIGNETTE CORPORATION 66.206.32.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.33.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.34.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.35.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.40.0/22 AS174 COGENT Cogent/PSI 66.206.44.0/23 AS174 COGENT Cogent/PSI 66.206.47.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 66.207.32.0/20 AS23011 66.245.176.0/20 AS19318 NJIIX-AS-1 - NEW JERSEY INTERNATIONAL INTERNET EXCHANGE LLC 69.6.80.0/24 AS13442 69.6.81.0/24 AS13442 69.71.192.0/20 AS13818 PHX-INTL-TELEPORT - Phoenix International Teleport 80.88.0.0/21 AS33774 DJAWEB 80.88.8.0/22 AS33774 DJAWEB 80.88.10.0/24 AS33774 DJAWEB 80.88.12.0/24 AS33779 wataniya-telecom-as 100.100.100.0/30 AS38676 AS33005-AS-KR wizsolution co.,Ltd 109.0.0.0/16 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 109.1.0.0/21 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 109.1.24.0/24 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 110.76.156.0/24 AS9535 FKT-HK-AP Flat/Rm D Block 1, 8/F 110.76.157.0/24 AS9535 FKT-HK-AP Flat/Rm D Block 1, 8/F 121.46.0.0/16 AS4134 CHINANET-BACKBONE No.31,Jin-rong Street 121.50.168.0/21 AS9931 CAT-AP The Communication Authoity of Thailand, CAT 122.128.120.0/22 AS38456 PACTEL-AS-AP Pacific Teleports. 137.0.0.0/13 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 158.222.5.0/24 AS21580 DIRCON - Direct Connect 158.222.70.0/23 AS6137 SISNA - SISNA, Inc. 158.222.72.0/23 AS6137 SISNA - SISNA, Inc. 158.222.224.0/20 AS19864 O1COMM - O1 COMMUNICATIONS 158.222.224.0/22 AS19864 O1COMM - O1 COMMUNICATIONS 158.222.229.0/24 AS19864 O1COMM - O1 COMMUNICATIONS 163.142.0.0/16 AS2500 WIDE-BB WIDE Project 168.253.0.0/16 AS13649 ASN-VINS - ViaWest 168.253.0.0/21 AS13649 ASN-VINS - ViaWest 172.7.0.0/24 AS28175 172.10.1.0/30 AS18305 POSNET POSDATA Co.,Ltd 178.0.0.0/16 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 178.1.0.0/21 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 178.1.24.0/24 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 192.9.0.0/16 AS11479 BRM-SUN-AS - Sun Microsystems, Inc 192.9.200.0/24 AS3602 AS3602-RTI - Rogers Telecom Inc. 192.64.85.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.69.107.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.69.108.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.69.177.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.70.164.0/24 AS25689 NRCNET-AS - National Research Council of Canada 192.96.37.0/24 AS10474 NETACTIVE 192.96.135.0/24 AS2018 TENET-1 192.96.136.0/23 AS2018 TENET-1 192.96.141.0/24 AS2018 TENET-1 192.96.143.0/24 AS2018 TENET-1 192.96.145.0/24 AS2018 TENET-1 192.96.177.0/24 AS6083 POSIX-AFRICA 192.101.45.0/24 AS2905 TICSA-ASN 192.101.46.0/24 AS6503 Avantel, S.A. 192.101.64.0/21 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 192.101.70.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 192.101.71.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 192.101.72.0/24 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 192.101.74.0/24 AS1239 SPRINTLINK - Sprint 192.124.248.0/23 AS680 DFN-IP service G-WiN 192.124.252.0/22 AS680 DFN-IP service G-WiN 192.131.233.0/24 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 192.132.58.0/24 AS20141 QUALITYTECH-SUW-300 - Quality Technology Services, LLC. 192.133.6.0/24 AS10282 ORANGE-BUSINESS-SERVICES-CEEUR Orange Business Services (formerly Equant) AS for CEEUR 192.153.144.0/21 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 192.154.32.0/19 AS81 NCREN - MCNC 192.188.208.0/20 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 193.33.148.0/23 AS30890 EVOLVA Evolva Telecom 196.6.108.0/24 AS5713 SAIX-NET 196.10.119.0/24 AS2018 TENET-1 196.10.122.0/23 AS2018 TENET-1 196.10.251.0/24 AS2018 TENET-1 196.10.252.0/23 AS2018 TENET-1 196.10.254.0/24 AS2018 TENET-1 196.13.101.0/24 AS2018 TENET-1 196.13.102.0/23 AS2018 TENET-1 196.13.104.0/24 AS2018 TENET-1 196.13.121.0/24 AS2018 TENET-1 196.13.125.0/24 AS2018 TENET-1 196.13.126.0/24 AS2018 TENET-1 196.13.169.0/24 AS2018 TENET-1 196.13.174.0/23 AS2018 TENET-1 196.13.176.0/21 AS2018 TENET-1 196.13.192.0/22 AS2018 TENET-1 196.13.196.0/24 AS2018 TENET-1 196.202.224.0/21 AS8818 TELE Greenland Autonomous System 198.1.2.0/24 AS4761 INDOSAT-INP-AP INDOSAT Internet Network Provider 198.23.26.0/24 AS33052 VZUNET - Verizon Data Services LLC 198.54.82.0/24 AS2018 TENET-1 198.54.92.0/24 AS2018 TENET-1 198.54.222.0/24 AS2018 TENET-1 198.73.210.0/24 AS21570 ACI-1 - Accelerated Connections Inc. 198.97.72.0/21 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 198.97.96.0/19 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 198.97.240.0/20 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 198.135.236.0/24 AS4358 XNET - XNet Information Systems, Inc. 198.161.87.0/24 AS6539 GT-BELL - Bell Canada 198.161.92.0/24 AS6539 GT-BELL - Bell Canada 198.167.0.0/16 AS7456 INTERHOP - Interhop Network SERVICES Inc. 198.168.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 198.169.0.0/16 AS803 SASKTEL - Saskatchewan Telecommunications 198.180.198.0/24 AS23715 SEOUL-INTGW-GXS-AP Global Exchange Services 199.5.242.0/24 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 199.10.0.0/16 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.19.0.0/24 AS3848 WORLDLINX-2 - WorldLinx Telecommunications, Inc. 199.114.0.0/21 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.114.128.0/18 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.114.130.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.131.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.132.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.134.0/24 AS3541 ITSDN-U4 - DoD Network Information Center 199.114.136.0/24 AS27044 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.114.138.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.140.0/24 AS3544 ITSDN-U7 - DoD Network Information Center 199.114.142.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.144.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.148.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.150.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.152.0/24 AS27033 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.114.153.0/24 AS27034 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.114.154.0/24 AS1733 CENTAF-SWA - 754th Electronic Systems Group 199.114.156.0/24 AS1733 CENTAF-SWA - 754th Electronic Systems Group 199.114.160.0/24 AS1733 CENTAF-SWA - 754th Electronic Systems Group 199.121.0.0/16 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.123.0.0/18 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.123.16.0/20 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.123.80.0/21 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.189.32.0/19 AS7332 IQUEST-AS - IQuest Internet 199.202.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 199.202.216.0/21 AS577 BACOM - Bell Canada 199.233.92.0/24 AS26896 ITCOMM - IT Communications 199.246.116.0/24 AS813 UUNET-CANADA - MCI Communications Services, Inc. d/b/a Verizon Business 202.6.176.0/20 AS24316 202.58.113.0/24 AS19161 INNOCOM-TELECOM - INNOCOM TELECOM 202.73.144.0/20 AS4788 TMNET-AS-AP TM Net, Internet Service Provider 202.80.192.0/20 AS2706 HKSUPER-HK-AP Pacific Internet (Hong Kong) Limited 202.86.252.0/22 AS4748 RESOLINK-AS-AP Resources Link Network Limited 202.86.252.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.253.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.254.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.255.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.92.48.0/20 AS23704 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.94.70.0/24 AS2764 AAPT AAPT Limited 202.124.195.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.133.70.0/24 AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited 202.133.73.0/24 AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited 202.136.254.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.136.255.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.140.160.0/24 AS4841 202.140.161.0/24 AS4841 202.140.162.0/24 AS4841 202.140.163.0/24 AS4841 202.140.164.0/24 AS4841 202.140.165.0/24 AS4841 202.140.166.0/24 AS4841 202.140.167.0/24 AS4841 202.140.168.0/24 AS4841 202.140.169.0/24 AS4841 202.140.170.0/24 AS4841 202.140.171.0/24 AS4841 202.140.172.0/24 AS4841 202.140.173.0/24 AS4841 202.140.174.0/24 AS4841 202.140.175.0/24 AS4841 202.140.180.0/24 AS7540 HKCIX-AS-AP HongKong Commercial Internet Exchange 202.140.181.0/24 AS7540 HKCIX-AS-AP HongKong Commercial Internet Exchange 202.140.182.0/24 AS7540 HKCIX-AS-AP HongKong Commercial Internet Exchange 202.150.227.0/24 AS17727 NAPINFO-AS-AP PT. NAP Info Lintas Nusa 202.181.32.0/24 AS4645 ASN-HKNET-AP HKNet Co. Ltd 203.12.45.0/24 AS4854 NETSPACE-AS-AP Netspace Online Systems 203.62.0.0/17 AS7575 AARNET-AS-AP Australian Academic and Reasearch Network (AARNet) 203.78.48.0/20 AS9299 IPG-AS-AP Philippine Long Distance Telephone Company 203.89.139.0/24 AS17911 BRAINPK-AS-AP Brain Telecommunication Ltd. 203.112.111.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.113.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.114.0/24 AS4802 ASN-IINET iiNet Limited 203.112.116.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.117.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.118.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.119.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.120.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.121.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.127.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.128.128.0/19 AS4134 CHINANET-BACKBONE No.31,Jin-rong Street 203.128.128.0/24 AS23849 CNNIC-NET263-AP Beijing Capital-online science development Co.,Ltd. 203.152.154.0/23 AS9583 SIFY-AS-IN Sify Limited 203.189.96.0/20 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 204.9.216.0/23 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 204.9.218.0/23 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 204.13.140.0/22 AS7270 NET2PHONE - Net2Phone Corp. 204.13.140.0/24 AS7270 NET2PHONE - Net2Phone Corp. 204.13.141.0/24 AS7270 NET2PHONE - Net2Phone Corp. 204.13.142.0/24 AS7270 NET2PHONE - Net2Phone Corp. 204.13.143.0/24 AS7270 NET2PHONE - Net2Phone Corp. 204.13.184.0/23 AS35967 204.13.186.0/23 AS35967 204.13.186.0/24 AS35967 204.13.187.0/24 AS35967 204.19.14.0/23 AS577 BACOM - Bell Canada 204.89.214.0/24 AS4323 TWTC - tw telecom holdings, inc. 204.138.167.0/24 AS18990 AIRBAND-DALLAS - Airband Communications, Inc 205.150.0.0/15 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 205.189.134.0/24 AS11814 CYBERSURF - Cybersurf Inc. 205.210.145.0/24 AS11814 CYBERSURF - Cybersurf Inc. 206.180.240.0/20 AS12083 KNOLOGY-NET - Knology Holdings 207.174.0.0/16 AS13790 INTERNAP-BLK3 - Internap Network Services Corporation 207.174.131.0/24 AS30715 NETRACK - Netrack, Inc. 207.174.132.0/23 AS30715 NETRACK - Netrack, Inc. 207.174.151.0/24 AS11500 PEAKPEAK - Peak to Peak Internet 207.174.152.0/22 AS30715 NETRACK - Netrack, Inc. 207.174.158.0/24 AS11500 PEAKPEAK - Peak to Peak Internet 207.174.177.0/24 AS11500 PEAKPEAK - Peak to Peak Internet 207.174.178.0/24 AS11500 PEAKPEAK - Peak to Peak Internet 207.174.182.0/24 AS29831 FONENET - FONE NET, LLC 207.174.188.0/22 AS30715 NETRACK - Netrack, Inc. 207.174.192.0/24 AS29831 FONENET - FONE NET, LLC 207.174.200.0/24 AS22658 EARTHNET - Earthnet, Inc. 207.174.248.0/21 AS6653 PRIVATEI - privateI, LLC 207.231.96.0/19 AS11194 NUNETPA - NuNet Inc. 209.54.123.0/24 AS6062 NETPLEX - NETPLEX 209.54.240.0/21 AS10887 BPSI-AS - BPSI Internet Services 209.74.96.0/19 AS10912 INTERNAP-BLK - Internap Network Services Corporation 209.140.90.0/24 AS14461 NTSL - NET SOLUTIONS 209.141.48.0/22 AS14461 NTSL - NET SOLUTIONS 209.145.192.0/18 AS3043 AMPHIB-AS - Amphibian Media Corporation 209.177.93.0/24 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 209.222.5.0/24 AS26699 PSI-CT - Printing For Systems Inc 209.222.6.0/24 AS26699 PSI-CT - Printing For Systems Inc 210.5.128.0/20 AS4837 CHINA169-BACKBONE CNCGROUP China169 Backbone 213.181.70.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.80.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.81.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.82.0/23 AS17175 NSS-UK New Skies Satellites UK AS 213.181.82.0/24 AS17175 NSS-UK New Skies Satellites UK AS 213.181.83.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.84.0/22 AS17175 NSS-UK New Skies Satellites UK AS 213.181.84.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.85.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.86.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.87.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.88.0/21 AS17175 NSS-UK New Skies Satellites UK AS 213.181.88.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.89.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.90.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.91.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.92.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.93.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.94.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.95.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 216.37.114.0/23 AS3549 GBLX Global Crossing Ltd. 216.99.20.0/24 AS3356 LEVEL3 Level 3 Communications 216.172.198.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 216.172.199.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 216.240.240.0/24 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 216.240.241.0/24 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 216.240.242.0/24 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 216.251.207.0/24 AS1239 SPRINTLINK - Sprint 217.78.71.0/24 AS12491 IPPLANET-AS IPPlanet 217.78.72.0/24 AS12491 IPPLANET-AS IPPlanet 217.78.73.0/24 AS12491 IPPLANET-AS IPPlanet Please see http://www.cidr-report.org for the full report ------------------------------------ Copies of this report are mailed to: nanog at merit.edu eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From bmanning at vacation.karoshi.com Fri May 29 07:32:46 2009 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Fri, 29 May 2009 12:32:46 +0000 Subject: glue record In-Reply-To: <1e0e55280905290048sf16089ehc94f585399206b42@mail.gmail.com> References: <1e0e55280905282306v69cea6b7m22b7ea6e8dea6afe@mail.gmail.com> <1e0e55280905290009q3556779dy29b50b918890fb69@mail.gmail.com> <82ljoggz0n.fsf@mid.bfk.de> <1e0e55280905290048sf16089ehc94f585399206b42@mail.gmail.com> Message-ID: <20090529123246.GB8139@vacation.karoshi.com.> On Fri, May 29, 2009 at 02:48:33PM +0700, Anton Zimm wrote: > I get this: MOBI servers are not authoritative for push.mobi zone, > ns1.push.mobi is authoritative for it. > > But since ns1.push.mobi is inside push.mobi zone, this create circular > reference. Afaik to solve this circular dependency, there has to be a > Glue record for ns1.push.mobi somewhere in root nameservers or mobi > nameservers. > > I can not find the Glue Record. Where is the Glue Record? > > Anton. what you are looking for no longer exists. there is no "glue" record per se. As Florian pointed out, a couple of implementations do what you expect, but BIND 4.x varients, esp at the TLD level, are scarce. As has been explained to you several times, modern thinking has settled on one (not particularly obvious) way to deal w/ the circular dependence problem. It really is better to only have to think about this problem space in one way. --bill From cmaurand at xyonet.com Fri May 29 08:03:39 2009 From: cmaurand at xyonet.com (Curtis Maurand) Date: Fri, 29 May 2009 09:03:39 -0400 Subject: glue record In-Reply-To: <1e0e55280905290319r75533eb0k58b5196006e743b5@mail.gmail.com> References: <1e0e55280905282306v69cea6b7m22b7ea6e8dea6afe@mail.gmail.com> <1e0e55280905290009q3556779dy29b50b918890fb69@mail.gmail.com> <1e0e55280905290319r75533eb0k58b5196006e743b5@mail.gmail.com> Message-ID: <4A1FDD2B.3060605@xyonet.com> Google is your ... well ... anyway. http://www.zytrax.com/books/dns/ch8/ns.html Anton Zimm wrote: > On Fri, May 29, 2009 at 2:36 PM, Scott Howard wrote: > >> On Fri, May 29, 2009 at 12:09 AM, Anton Zimm wrote: >> >>> Now, from the 'authority section' dig is telling me that I can get the >>> authorize answer from ns1.push.mobi. But isn't that circular >>> dependency? >>> >> http://en.wikipedia.org/wiki/Domain_name_system#Circular_dependencies_and_glue_records >> >> No offense, but a few minutes on Google should be able to tell you far more than you will ever need to know about how glue works (The above URL is the #1 hit for "dns glue") >> >> > > Scott, > I did google and check wikipedia and other sources before posting the > initial question. I didn't understand it thoroughly before, I think I > understand more now. > > thank's, > Anton. > > From warren at kumari.net Fri May 29 08:31:11 2009 From: warren at kumari.net (Warren Kumari) Date: Fri, 29 May 2009 09:31:11 -0400 Subject: problems with cisco 7200 and PA-T3 In-Reply-To: <7c2653830905281543k3fe3089cs64a8a73caff5aefe@mail.gmail.com> References: <7c2653830905281543k3fe3089cs64a8a73caff5aefe@mail.gmail.com> Message-ID: <1E558370-71D4-4C13-812A-11F5D9CE03E4@kumari.net> On May 28, 2009, at 6:43 PM, Adam Goodman wrote: > Just installed a cisco 7204vxr with a DS3 interface. we are not > getting more > than 5Mbits. So, how are you testing? A single flow maybe? > > > show interface is not reporting any errors. the provider tech put a > piece > test equipment on the circuit and sees errors. > What errors are they seeing? How are they testing, etc? Anyway, cisco-nsp is thad away.... W > Does anyone else use a cisco 7200 with a DS3 interface that we might > be able > to speak with? > > Please hit me off list > > Thank you, > Adam > 801.971.1856 -- After you'd known Christine for any length of time, you found yourself fighting a desire to look into her ear to see if you could spot daylight coming the other way. -- (Terry Pratchett, Maskerade)t -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4760 bytes Desc: not available URL: From toddunder at gmail.com Fri May 29 09:34:18 2009 From: toddunder at gmail.com (Todd Underwood) Date: Fri, 29 May 2009 10:34:18 -0400 Subject: [NANOG-announce] lightning talks open and hotel rate expiring Message-ID: <65b1fd2e0905290734s687acd4ct1a6d2a23304c1c30@mail.gmail.com> two quick reminders: 1) the nanog discount rate on the hotel is mostly (but not completely) full and i believe it expires today. if you're planning on coming to nanog, please register for the conference and book a hotel room. or pay more for the privilege of both experiences. https://nanog.merit.edu/registration/ http://nanog.org/meetings/nanog46/hotel.php 2) lightning talk submissions are now open. lightning talks are short (10 minutes), topical and timely. and they are done at the last minute (a feature which endears them to many of us). lightning talks submitted by jun 8 will be voted on by the program committee on our jun 9 call just prior to the start of nanog 46. lightning talks will continue to be accepted through tuesday of the conference, although the sooner you get your abstract in, the more likely we will be to accept your talk. several talks have already been submitted so if you've got a good idea, now is the time to write it up and get it in. i'm very much looking forward to seeing all of you in philadelphia. todd underwood, chair nanog program committee _______________________________________________ NANOG-announce mailing list NANOG-announce at nanog.org http://mailman.nanog.org/mailman/listinfo/nanog-announce From j at arpa.com Fri May 29 11:37:58 2009 From: j at arpa.com (jamie rishaw) Date: Fri, 29 May 2009 11:37:58 -0500 Subject: White House net security paper Message-ID: The White House just put out a release on net security[1] - at first glance a mission/vision/values paper, the release page[2] also containing a short video[3]. At first glance, this looks promising - anyone else get a chance to read/review? Comments? -jamie [1] http://www.whitehouse.gov/asset.aspx?AssetId=1732 [2] http://www.whitehouse.gov/CyberReview/ (other links here as well) [3] http://www.whitehouse.gov/videos/2009/May/20090529_Cyber_Security.mp4 -- Jamie Rishaw // .com.arpa at j <- reverse it. ish. [Impressive C-level Title Here], arpa / arpa labs From bmanning at vacation.karoshi.com Fri May 29 11:41:22 2009 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Fri, 29 May 2009 16:41:22 +0000 Subject: White House net security paper In-Reply-To: References: Message-ID: <20090529164122.GB9629@vacation.karoshi.com.> fine piece of work. On Fri, May 29, 2009 at 11:37:58AM -0500, jamie rishaw wrote: > The White House just put out a release on net security[1] - at first glance > a mission/vision/values paper, the release page[2] also containing a short > video[3]. > > At first glance, this looks promising - anyone else get a chance to > read/review? Comments? > > > -jamie > > > > [1] http://www.whitehouse.gov/asset.aspx?AssetId=1732 > [2] http://www.whitehouse.gov/CyberReview/ (other links here as well) > [3] http://www.whitehouse.gov/videos/2009/May/20090529_Cyber_Security.mp4 > > -- > Jamie Rishaw // .com.arpa at j <- reverse it. ish. > [Impressive C-level Title Here], arpa / arpa labs From andyzweb at gmail.com Fri May 29 12:33:31 2009 From: andyzweb at gmail.com (Andrew Euell) Date: Fri, 29 May 2009 13:33:31 -0400 Subject: White House net security paper In-Reply-To: <20090529164122.GB9629@vacation.karoshi.com.> References: <20090529164122.GB9629@vacation.karoshi.com.> Message-ID: "The Nation?s approach to cybersecurity over the past 15 years has failed to keep pace with the threat." I think that they may be getting it... On Fri, May 29, 2009 at 12:41 PM, wrote: > fine piece of work. > > > > On Fri, May 29, 2009 at 11:37:58AM -0500, jamie rishaw wrote: > > The White House just put out a release on net security[1] - at first > glance > > a mission/vision/values paper, the release page[2] also containing a > short > > video[3]. > > > > At first glance, this looks promising - anyone else get a chance to > > read/review? Comments? > > > > > > -jamie > > > > > > > > [1] http://www.whitehouse.gov/asset.aspx?AssetId=1732 > > [2] http://www.whitehouse.gov/CyberReview/ (other links here as well) > > [3] > http://www.whitehouse.gov/videos/2009/May/20090529_Cyber_Security.mp4 > > > > -- > > Jamie Rishaw // .com.arpa at j <- reverse it. ish. > > [Impressive C-level Title Here], arpa / arpa labs > > -- Andrew Euell andyzweb [at] gmail [dot] com From cluestore at gmail.com Fri May 29 12:50:49 2009 From: cluestore at gmail.com (Clue Store) Date: Fri, 29 May 2009 12:50:49 -0500 Subject: Geo Location and DNS Message-ID: <580af3b90905291050s671a5de0k8db4c962d941eb0f@mail.gmail.com> Hi All, I am having a hell of a time trying to figure out who it is I need to contact to get this fixed. I just got a new /21 allocation from ARIN and am announcing it with no issues. I can ping anywhere and the planet can see me. The issue I am having is that when I surf out on this new allocation, it sends me to sites as if I were in Canada. A google search is all things canadian. Not that I have anything against canadians, but I also cannot surf to alot of sites using various DNS servers (my own, 4.2.2.2, etc). Anyone have any clue where I can get this fixed?? TIA, Max From KaeglerM at tessco.com Fri May 29 12:55:19 2009 From: KaeglerM at tessco.com (Kaegler, Mike) Date: Fri, 29 May 2009 13:55:19 -0400 Subject: Geo Location and DNS In-Reply-To: <580af3b90905291050s671a5de0k8db4c962d941eb0f@mail.gmail.com> Message-ID: We last went through this 30 days ago. http://www.merit.edu/mail.archives/nanog/msg17619.html -porkchop On 5/29/09 1:50 PM, "Clue Store" wrote: > Hi All, > I am having a hell of a time trying to figure out who it is I need to > contact to get this fixed. I just got a new /21 allocation from ARIN and am > announcing it with no issues. I can ping anywhere and the planet can see me. > The issue I am having is that when I surf out on this new allocation, it > sends me to sites as if I were in Canada. A google search is all things > canadian. Not that I have anything against canadians, but I also cannot surf > to alot of sites using various DNS servers (my own, 4.2.2.2, etc). Anyone > have any clue where I can get this fixed?? > > > TIA, > Max > -- Michael Kaegler, TESSCO Technologies: Engineering, 410 229 1295 Your wireless success, nothing less. http://www.tessco.com/ From cluestore at gmail.com Fri May 29 13:02:38 2009 From: cluestore at gmail.com (Clue Store) Date: Fri, 29 May 2009 13:02:38 -0500 Subject: Geo Location and DNS In-Reply-To: References: <580af3b90905291050s671a5de0k8db4c962d941eb0f@mail.gmail.com> Message-ID: <580af3b90905291102w5ccbc499q896451075dbdae18@mail.gmail.com> Thanks for the follow up. I admit I didn't search the archives ;) So this sux there's really no way to fix this but contact as many geo location folks as possible and have them update. I can't even get to alot of sites in the US because of this. UGH!!! Max On Fri, May 29, 2009 at 12:55 PM, Kaegler, Mike wrote: > We last went through this 30 days ago. > http://www.merit.edu/mail.archives/nanog/msg17619.html > -porkchop > > > On 5/29/09 1:50 PM, "Clue Store" wrote: > > > Hi All, > > I am having a hell of a time trying to figure out who it is I need to > > contact to get this fixed. I just got a new /21 allocation from ARIN and > am > > announcing it with no issues. I can ping anywhere and the planet can see > me. > > The issue I am having is that when I surf out on this new allocation, it > > sends me to sites as if I were in Canada. A google search is all things > > canadian. Not that I have anything against canadians, but I also cannot > surf > > to alot of sites using various DNS servers (my own, 4.2.2.2, etc). Anyone > > have any clue where I can get this fixed?? > > > > > > TIA, > > Max > > > > -- > Michael Kaegler, TESSCO Technologies: Engineering, 410 229 1295 > Your wireless success, nothing less. http://www.tessco.com/ > > From Crist.Clark at globalstar.com Fri May 29 13:03:50 2009 From: Crist.Clark at globalstar.com (Crist Clark) Date: Fri, 29 May 2009 11:03:50 -0700 Subject: DNS ed.gov translations In-Reply-To: <5B3743FC2D0D8B41B27EE4F5EACA79D108970F65@DTN1EX01.gci.com> References: <5B3743FC2D0D8B41B27EE4F5EACA79D108970F65@DTN1EX01.gci.com> Message-ID: <4A1FC10E.33E4.0097.0@globalstar.com> You just flashed me back to alt.fan.warlord. That .sig is nothing. No ASCII sword or any BUAG involved at all. On 5/29/2009 at 12:04 AM, "Warren Bailey" wrote: > I elect Ralf as owner of the longest email signature in history.. > > > > ----- Original Message ----- > From: Ralf Weber > To: Peter Charbonneau > Cc: nanog at nanog.org > Sent: Thu May 28 22:47:19 2009 > Subject: Re: DNS ed.gov translations > > Moin! > > On 29.05.2009, at 03:06, Peter Charbonneau wrote: >> >> Firewalls are Cisco ASAs that pass all traffic to/from the >> nameservers. >> Fragments are allowed through. > Is this the firewall formerly known as PIX? If so we had problems with > our DNS server until we put the following line in our configuration: > fixup protocol dns maximum-length 4096 > Maybe this helps. > > So long > -Ralf > --- > Ralf Weber > Platform Infrastructure Manager > Colt Telecom GmbH > Herriotstrasse 4 > 60528 Frankfurt > Germany > DDI: +49 (0)69 56606 2780 Internal OneDial: 8 491 2780 > Fax: +49 (0)69 56606 6280 > Email: rw at colt.net > http://www.colt.net/ > Data | Voice | Managed Services > > Sch?tze Deine Umwelt | Erst denken, dann drucken > > ***************************************** > COLT Telecom GmbH, Herriotstra?e 4, 60528 Frankfurt/Main, Deutschland > * Tel +49 (0)69 56606 0 * Fax +49 (0)69 56606 2222 * > > Gesch?ftsf?hrer: Dr. J?rgen Hernichel (Vors.), Rita Thies * > Amtsgericht Frankfurt/Main HRB 46123 * USt.-IdNr. DE 197 498 400 From charles at thewybles.com Fri May 29 13:13:36 2009 From: charles at thewybles.com (Charles Wyble) Date: Fri, 29 May 2009 11:13:36 -0700 Subject: Geo Location and DNS In-Reply-To: <580af3b90905291050s671a5de0k8db4c962d941eb0f@mail.gmail.com> References: <580af3b90905291050s671a5de0k8db4c962d941eb0f@mail.gmail.com> Message-ID: <4A2025D0.20707@thewybles.com> Check the archives. This gets discussed on a regular basis. Both google and akami have methods in place for this to be corrected. Clue Store wrote: > Hi All, > I am having a hell of a time trying to figure out who it is I need to > contact to get this fixed. I just got a new /21 allocation from ARIN and am > announcing it with no issues. I can ping anywhere and the planet can see me. > The issue I am having is that when I surf out on this new allocation, it > sends me to sites as if I were in Canada. A google search is all things > canadian. Not that I have anything against canadians, but I also cannot surf > to alot of sites using various DNS servers (my own, 4.2.2.2, etc). Anyone > have any clue where I can get this fixed?? > > > TIA, > Max > From cscora at apnic.net Fri May 29 13:12:59 2009 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 30 May 2009 04:12:59 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <200905291812.n4TICx33019236@thyme.apnic.net> This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. Daily listings are sent to bgp-stats at lists.apnic.net For historical data, please see http://thyme.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 30 May, 2009 Report Website: http://thyme.apnic.net Detailed Analysis: http://thyme.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 289077 Prefixes after maximum aggregation: 136617 Deaggregation factor: 2.12 Unique aggregates announced to Internet: 142075 Total ASes present in the Internet Routing Table: 31358 Prefixes per ASN: 9.22 Origin-only ASes present in the Internet Routing Table: 27249 Origin ASes announcing only one prefix: 13307 Transit ASes present in the Internet Routing Table: 4109 Transit-only ASes present in the Internet Routing Table: 95 Average AS path length visible in the Internet Routing Table: 3.6 Max AS path length visible: 28 Max AS path prepend of ASN (12026) 22 Prefixes from unregistered ASNs in the Routing Table: 517 Unregistered ASNs in the Routing Table: 148 Number of 32-bit ASNs allocated by the RIRs: 164 Prefixes from 32-bit ASNs in the Routing Table: 42 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 804 Number of addresses announced to Internet: 2055663936 Equivalent to 122 /8s, 134 /16s and 241 /24s Percentage of available address space announced: 55.5 Percentage of allocated address space announced: 64.2 Percentage of available address space allocated: 86.4 Percentage of address space in use by end-sites: 77.2 Total number of prefixes smaller than registry allocations: 143093 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 68122 Total APNIC prefixes after maximum aggregation: 24375 APNIC Deaggregation factor: 2.79 Prefixes being announced from the APNIC address blocks: 67545 Unique aggregates announced from the APNIC address blocks: 30656 APNIC Region origin ASes present in the Internet Routing Table: 3645 APNIC Prefixes per ASN: 18.53 APNIC Region origin ASes announcing only one prefix: 998 APNIC Region transit ASes present in the Internet Routing Table: 558 Average APNIC Region AS path length visible: 3.5 Max APNIC Region AS path length visible: 22 Number of APNIC addresses announced to Internet: 452378976 Equivalent to 26 /8s, 246 /16s and 193 /24s Percentage of available APNIC address space announced: 84.3 APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079 APNIC Address Blocks 58/8, 59/8, 60/8, 61/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 180/8, 183/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 124963 Total ARIN prefixes after maximum aggregation: 65735 ARIN Deaggregation factor: 1.90 Prefixes being announced from the ARIN address blocks: 125685 Unique aggregates announced from the ARIN address blocks: 51667 ARIN Region origin ASes present in the Internet Routing Table: 13003 ARIN Prefixes per ASN: 9.67 ARIN Region origin ASes announcing only one prefix: 4995 ARIN Region transit ASes present in the Internet Routing Table: 1272 Average ARIN Region AS path length visible: 3.3 Max ARIN Region AS path length visible: 24 Number of ARIN addresses announced to Internet: 1017392960 Equivalent to 60 /8s, 164 /16s and 47 /24s Percentage of available ARIN address space announced: 195.6 ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 53248-55295 ARIN Address Blocks 24/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8, 98/8, 99/8, 108/8, 173/8, 174/8, 184/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 65530 Total RIPE prefixes after maximum aggregation: 38773 RIPE Deaggregation factor: 1.69 Prefixes being announced from the RIPE address blocks: 64743 Unique aggregates announced from the RIPE address blocks: 43594 RIPE Region origin ASes present in the Internet Routing Table: 13072 RIPE Prefixes per ASN: 4.95 RIPE Region origin ASes announcing only one prefix: 6862 RIPE Region transit ASes present in the Internet Routing Table: 1983 Average RIPE Region AS path length visible: 4.0 Max RIPE Region AS path length visible: 28 Number of RIPE addresses announced to Internet: 480688032 Equivalent to 28 /8s, 166 /16s and 183 /24s Percentage of available RIPE address space announced: 102.3 RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-52223 RIPE Address Blocks 62/8, 77/8, 78/8, 79/8, 80/8, 81/8, 82/8, 83/8, 84/8, 85/8, 86/8, 87/8, 88/8, 89/8, 90/8, 91/8, 92/8, 93/8, 94/8, 95/8, 109/8, 178/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 23841 Total LACNIC prefixes after maximum aggregation: 5941 LACNIC Deaggregation factor: 4.01 Prefixes being announced from the LACNIC address blocks: 23727 Unique aggregates announced from the LACNIC address blocks: 13095 LACNIC Region origin ASes present in the Internet Routing Table: 1117 LACNIC Prefixes per ASN: 21.24 LACNIC Region origin ASes announcing only one prefix: 363 LACNIC Region transit ASes present in the Internet Routing Table: 185 Average LACNIC Region AS path length visible: 4.1 Max LACNIC Region AS path length visible: 19 Number of LACNIC addresses announced to Internet: 71561088 Equivalent to 4 /8s, 67 /16s and 239 /24s Percentage of available LACNIC address space announced: 71.1 LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247 plus ERX transfers LACNIC Address Blocks 186/8, 187/8, 189/8, 190/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 6192 Total AfriNIC prefixes after maximum aggregation: 1451 AfriNIC Deaggregation factor: 4.27 Prefixes being announced from the AfriNIC address blocks: 6560 Unique aggregates announced from the AfriNIC address blocks: 2430 AfriNIC Region origin ASes present in the Internet Routing Table: 297 AfriNIC Prefixes per ASN: 22.09 AfriNIC Region origin ASes announcing only one prefix: 89 AfriNIC Region transit ASes present in the Internet Routing Table: 62 Average AfriNIC Region AS path length visible: 3.8 Max AfriNIC Region AS path length visible: 15 Number of AfriNIC addresses announced to Internet: 19306496 Equivalent to 1 /8s, 38 /16s and 152 /24s Percentage of available AfriNIC address space announced: 57.5 AfriNIC AS Blocks 36864-37887 & ERX transfers AfriNIC Address Blocks 41/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4766 1705 6930 401 Korea Telecom (KIX) 17488 1588 130 99 Hathway IP Over Cable Interne 4755 1249 476 124 TATA Communications formerly 9583 1075 86 538 Sify Limited 4134 890 16789 375 CHINANET-BACKBONE 7545 787 198 101 TPG Internet Pty Ltd 23577 779 34 660 Korea Telecom (ATM-MPLS) 18101 748 216 29 Reliance Infocom Ltd Internet 24560 693 230 174 Bharti Airtel Ltd. 9829 669 561 15 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 4293 3647 324 bellsouth.net, inc. 209 2540 4137 604 Qwest 4323 1856 1035 374 Time Warner Telecom 1785 1699 717 139 PaeTec Communications, Inc. 20115 1626 1441 720 Charter Communications 7018 1500 5902 1033 AT&T WorldNet Services 6478 1398 310 442 AT&T Worldnet Services 2386 1269 683 922 AT&T Data Communications Serv 3356 1212 10981 456 Level 3 Communications, LLC 11492 1109 208 12 Cable One Complete listing at http://thyme.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 30890 526 87 196 Evolva Telecom 3292 456 1893 394 TDC Tele Danmark 12479 450 578 6 Uni2 Autonomous System 702 430 1864 344 UUNET - Commercial IP service 8866 386 110 26 Bulgarian Telecommunication C 35805 348 24 4 United Telecom of Georgia 3320 344 7066 295 Deutsche Telekom AG 3215 343 3041 108 France Telecom Transpac 3301 340 1668 304 TeliaNet Sweden 29049 317 26 3 AzerSat LLC. Complete listing at http://thyme.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 8151 1453 2863 234 UniNet S.A. de C.V. 10620 914 207 108 TVCABLE BOGOTA 22047 579 302 14 VTR PUNTO NET S.A. 7303 543 293 79 Telecom Argentina Stet-France 11830 486 292 54 Instituto Costarricense de El 28573 472 562 35 NET Servicos de Comunicao S.A 6471 443 96 32 ENTEL CHILE S.A. 11172 441 102 70 Servicios Alestra S.A de C.V 7738 404 794 28 Telecomunicacoes da Bahia S.A 3816 357 170 79 Empresa Nacional de Telecomun Complete listing at http://thyme.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 8452 1203 188 7 TEDATA 24863 880 81 41 LINKdotNET AS number 20858 326 34 5 EgyNet 3741 278 860 238 The Internet Solution 2018 245 215 143 Tertiary Education Network 6713 160 151 12 Itissalat Al-MAGHRIB 33783 152 10 8 EEPAD TISP TELECOM & INTERNET 29571 139 15 8 Ci Telecom Autonomous system 5536 123 8 9 Internet Egypt Network 33776 116 6 7 Starcomms Nigeria Limited Complete listing at http://thyme.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 4293 3647 324 bellsouth.net, inc. 209 2540 4137 604 Qwest 4323 1856 1035 374 Time Warner Telecom 4766 1705 6930 401 Korea Telecom (KIX) 1785 1699 717 139 PaeTec Communications, Inc. 20115 1626 1441 720 Charter Communications 17488 1588 130 99 Hathway IP Over Cable Interne 7018 1500 5902 1033 AT&T WorldNet Services 8151 1453 2863 234 UniNet S.A. de C.V. 6478 1398 310 442 AT&T Worldnet Services Complete listing at http://thyme.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 209 2540 1936 Qwest 1785 1699 1560 PaeTec Communications, Inc. 17488 1588 1489 Hathway IP Over Cable Interne 4323 1856 1482 Time Warner Telecom 4766 1705 1304 Korea Telecom (KIX) 8151 1453 1219 UniNet S.A. de C.V. 8452 1203 1196 TEDATA 4755 1249 1125 TATA Communications formerly 11492 1109 1097 Cable One 18566 1062 1052 Covad Communications Complete listing at http://thyme.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 16927 UNALLOCATED 12.0.252.0/23 7018 AT&T WorldNet Servic 15132 UNALLOCATED 12.9.150.0/24 7018 AT&T WorldNet Servic 32567 UNALLOCATED 12.14.170.0/24 7018 AT&T WorldNet Servic 13746 UNALLOCATED 12.24.56.0/24 7018 AT&T WorldNet Servic 32567 UNALLOCATED 12.25.107.0/24 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.152.0/24 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.154.0/23 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.159.0/24 7018 AT&T WorldNet Servic 32326 UNALLOCATED 12.40.49.0/24 7018 AT&T WorldNet Servic 25639 UNALLOCATED 12.41.169.0/24 7018 AT&T WorldNet Servic Complete listing at http://thyme.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 41.223.112.0/22 5713 Telkom SA Ltd 41.223.176.0/22 36981 >>UNKNOWN<< 41.223.188.0/24 22351 Intelsat 41.223.189.0/24 26452 Local Communications Networks 62.61.220.0/24 24974 Tachyon Europe BV - Wireless 62.61.221.0/24 24974 Tachyon Europe BV - Wireless 63.140.213.0/24 22555 Universal Talkware Corporatio 63.143.251.0/24 22555 Universal Talkware Corporatio 64.31.32.0/19 11955 ServiceCo LLC - Road Runner 64.31.59.0/24 7017 ServiceCo LLC - Road Runner Complete listing at http://thyme.apnic.net/current/data-add-IANA Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:19 /9:10 /10:22 /11:58 /12:166 /13:347 /14:602 /15:1151 /16:10486 /17:4764 /18:8174 /19:17108 /20:20443 /21:20381 /22:26048 /23:25758 /24:151008 /25:832 /26:991 /27:544 /28:144 /29:8 /30:5 /31:0 /32:8 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 6389 2800 4293 bellsouth.net, inc. 4766 1398 1705 Korea Telecom (KIX) 17488 1307 1588 Hathway IP Over Cable Interne 209 1283 2540 Qwest 1785 1175 1699 PaeTec Communications, Inc. 8452 1172 1203 TEDATA 11492 1043 1109 Cable One 18566 1043 1062 Covad Communications 2386 977 1269 AT&T Data Communications Serv 4323 955 1856 Time Warner Telecom Complete listing at http://thyme.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 4:13 8:203 12:2216 13:10 15:19 16:3 17:4 20:35 24:1075 32:52 34:2 38:561 40:97 41:1977 43:1 44:2 47:22 52:4 55:2 56:3 57:24 58:586 59:642 60:459 61:1092 62:1091 63:2083 64:3713 65:2381 66:3621 67:1606 68:822 69:2629 70:531 71:147 72:1665 73:2 74:1535 75:172 76:308 77:860 78:557 79:341 80:975 81:822 82:553 83:429 84:643 85:1037 86:401 87:655 88:354 89:1436 90:60 91:2253 92:339 93:1035 94:1226 95:1182 96:134 97:209 98:242 99:20 109:1 110:126 112:129 113:109 114:269 115:291 116:1162 117:529 118:298 119:702 120:145 121:746 122:1028 123:684 124:979 125:1323 128:222 129:236 130:125 131:412 132:75 133:9 134:186 135:39 136:224 137:155 138:160 139:78 140:447 141:114 142:381 143:347 144:365 145:47 146:375 147:160 148:518 149:229 150:177 151:198 152:146 153:140 154:2 155:275 156:170 157:296 158:114 159:312 160:283 161:143 162:267 163:151 164:480 165:499 166:274 167:361 168:680 169:164 170:467 171:40 172:10 173:288 174:217 178:1 180:1 183:1 186:17 187:105 188:20 189:418 190:2687 192:5782 193:4221 194:3299 195:2701 196:1067 198:3630 199:3366 200:5205 201:1273 202:7874 203:8188 204:3837 205:2139 206:2453 207:2778 208:3901 209:3437 210:2683 211:1118 212:1512 213:1664 214:76 215:31 216:4702 217:1277 218:367 219:430 220:1217 221:476 222:302 End of report From jared at puck.nether.net Fri May 29 13:13:55 2009 From: jared at puck.nether.net (Jared Mauch) Date: Fri, 29 May 2009 14:13:55 -0400 Subject: White House net security paper In-Reply-To: References: <20090529164122.GB9629@vacation.karoshi.com.> Message-ID: On May 29, 2009, at 1:33 PM, Andrew Euell wrote: > "The Nation?s approach to cybersecurity over the past 15 years has > failed to > keep pace with the threat." > > I think that they may be getting it... From my experience, people get it, but security is always a balance between making something usable and how-high to build the fence. I know how to keep important data secure, but making it accessible and secure always exposes it to some level of risk. The question is where does that risk meter get set. It's not obvious to me if this is a direct result of the 60-day cyber review (but I presume it is) that Melissa Hathaway completed. I need some more time to read this entire thing. The ISP community has provided input to this and various security efforts that the US Government has done. There is actually an entire (non-trade- association driven, non-lobbist, etc..) community that does get reached out to. http://www.commscc.org/ http://www.it-scc.org/ I know that membership is FREE for the IT-SCC. This means that *YOU* (yes, You!) can be at the table and provide this feedback. This is in addition to you reading the notices in the Federal Register too ;) There are good people involved in these activities, but always room for more. Take a look at the charters for the it-scc & commscc and see if one (or both) is a fit for your org. Worst case scenario you get a few more emails. (The volume is way lower than NANOG). - Jared From stefan at csudsu.com Fri May 29 13:31:18 2009 From: stefan at csudsu.com (Stefan Molnar) Date: Fri, 29 May 2009 18:31:18 +0000 Subject: Geo Location and DNS Message-ID: <811422358-1243621849-cardhu_decombobulator_blackberry.rim.net-1103237834-@bxe1037.bisx.prod.on.blackberry> It took us over 3 months with Google to update. They never once said the info was wrong, and it was not even a new ARIN allocation. ------Original Message------ From: Clue Store To: Kaegler, Mike Cc: nanog at nanog.org Subject: Re: Geo Location and DNS Sent: May 29, 2009 11:02 AM Thanks for the follow up. I admit I didn't search the archives ;) So this sux there's really no way to fix this but contact as many geo location folks as possible and have them update. I can't even get to alot of sites in the US because of this. UGH!!! Max On Fri, May 29, 2009 at 12:55 PM, Kaegler, Mike wrote: > We last went through this 30 days ago. > http://www.merit.edu/mail.archives/nanog/msg17619.html > -porkchop > > > On 5/29/09 1:50 PM, "Clue Store" wrote: > > > Hi All, > > I am having a hell of a time trying to figure out who it is I need to > > contact to get this fixed. I just got a new /21 allocation from ARIN and > am > > announcing it with no issues. I can ping anywhere and the planet can see > me. > > The issue I am having is that when I surf out on this new allocation, it > > sends me to sites as if I were in Canada. A google search is all things > > canadian. Not that I have anything against canadians, but I also cannot > surf > > to alot of sites using various DNS servers (my own, 4.2.2.2, etc). Anyone > > have any clue where I can get this fixed?? > > > > > > TIA, > > Max > > > > -- > Michael Kaegler, TESSCO Technologies: Engineering, 410 229 1295 > Your wireless success, nothing less. http://www.tessco.com/ > > From cmaurand at xyonet.com Fri May 29 14:08:28 2009 From: cmaurand at xyonet.com (Curtis Maurand) Date: Fri, 29 May 2009 15:08:28 -0400 Subject: Geo Location and DNS In-Reply-To: <811422358-1243621849-cardhu_decombobulator_blackberry.rim.net-1103237834-@bxe1037.bisx.prod.on.blackberry> References: <811422358-1243621849-cardhu_decombobulator_blackberry.rim.net-1103237834-@bxe1037.bisx.prod.on.blackberry> Message-ID: <4A2032AC.1080404@xyonet.com> You may have to contact maxmind, the keepers of the geoip database. correction at maxmind.com Curtis Stefan Molnar wrote: > It took us over 3 months with Google to update. They never once said the info was wrong, and it was not even a new ARIN allocation. > > ------Original Message------ > From: Clue Store > To: Kaegler, Mike > Cc: nanog at nanog.org > Subject: Re: Geo Location and DNS > Sent: May 29, 2009 11:02 AM > > Thanks for the follow up. I admit I didn't search the archives ;) > So this sux there's really no way to fix this but contact as many geo > location folks as possible and have them update. I can't even get to alot of > sites in the US because of this. UGH!!! > > Max > > On Fri, May 29, 2009 at 12:55 PM, Kaegler, Mike wrote: > > >> We last went through this 30 days ago. >> http://www.merit.edu/mail.archives/nanog/msg17619.html >> -porkchop >> >> >> On 5/29/09 1:50 PM, "Clue Store" wrote: >> >> >>> Hi All, >>> I am having a hell of a time trying to figure out who it is I need to >>> contact to get this fixed. I just got a new /21 allocation from ARIN and >>> >> am >> >>> announcing it with no issues. I can ping anywhere and the planet can see >>> >> me. >> >>> The issue I am having is that when I surf out on this new allocation, it >>> sends me to sites as if I were in Canada. A google search is all things >>> canadian. Not that I have anything against canadians, but I also cannot >>> >> surf >> >>> to alot of sites using various DNS servers (my own, 4.2.2.2, etc). Anyone >>> have any clue where I can get this fixed?? >>> >>> >>> TIA, >>> Max >>> >>> >> -- >> Michael Kaegler, TESSCO Technologies: Engineering, 410 229 1295 >> Your wireless success, nothing less. http://www.tessco.com/ >> >> >> > > > From marcina at gmail.com Fri May 29 16:46:40 2009 From: marcina at gmail.com (marcin) Date: Fri, 29 May 2009 16:46:40 -0500 Subject: White House net security paper In-Reply-To: References: Message-ID: <730404280905291446k5834e220m6a83c73625f12d91@mail.gmail.com> > At first glance, this looks promising - anyone else get a chance to > read/review? ?Comments? You might hate Marcus Ranum, or love him, but the presentation he did at the DojoSec in March is related to this subject, and it is well worth the hour: http://vimeo.com/3519680 -- Marcin Antkiewicz From ml at kenweb.org Fri May 29 18:04:48 2009 From: ml at kenweb.org (ML) Date: Fri, 29 May 2009 19:04:48 -0400 Subject: Geo Location and DNS In-Reply-To: <580af3b90905291050s671a5de0k8db4c962d941eb0f@mail.gmail.com> References: <580af3b90905291050s671a5de0k8db4c962d941eb0f@mail.gmail.com> Message-ID: <4A206A10.3030106@kenweb.org> Clue Store wrote: > Hi All, > I am having a hell of a time trying to figure out who it is I need to > contact to get this fixed. I just got a new /21 allocation from ARIN and am > announcing it with no issues. I can ping anywhere and the planet can see me. > The issue I am having is that when I surf out on this new allocation, it > sends me to sites as if I were in Canada. A google search is all things > canadian. Not that I have anything against canadians, but I also cannot surf > to alot of sites using various DNS servers (my own, 4.2.2.2, etc). Anyone > have any clue where I can get this fixed?? > > > TIA, > Max > Did you SWIP your block? https://www.arin.net/resources/request/reassignments.html From wbailey at gci.com Fri May 29 18:35:54 2009 From: wbailey at gci.com (Warren Bailey) Date: Fri, 29 May 2009 15:35:54 -0800 Subject: Cisco 6524 and MTU Message-ID: <5B3743FC2D0D8B41B27EE4F5EACA79D10A3BC54A@DTN1EX01.gci.com> Has anyone encountered a 6524 dropping packets larger than 1492? IOS 12.2(33)SXH2a Warren Bailey GCI Communication Corp. RF Network Engineering 907.868.5911 office 907.903.5410 mobile From marka at isc.org Fri May 29 18:51:36 2009 From: marka at isc.org (Mark Andrews) Date: Sat, 30 May 2009 09:51:36 +1000 Subject: glue record In-Reply-To: Your message of "Fri, 29 May 2009 12:32:46 GMT." <20090529123246.GB8139@vacation.karoshi.com.> Message-ID: <200905292351.n4TNpaTM099481@drugs.dv.isc.org> In message <20090529123246.GB8139 at vacation.karoshi.com.>, bmanning at vacation.kar oshi.com writes: > On Fri, May 29, 2009 at 02:48:33PM +0700, Anton Zimm wrote: > > I get this: MOBI servers are not authoritative for push.mobi zone, > > ns1.push.mobi is authoritative for it. > > > > But since ns1.push.mobi is inside push.mobi zone, this create circular > > reference. Afaik to solve this circular dependency, there has to be a > > Glue record for ns1.push.mobi somewhere in root nameservers or mobi > > nameservers. > > > > I can not find the Glue Record. Where is the Glue Record? > > > > Anton. > > > what you are looking for no longer exists. > there is no "glue" record per se. As Florian pointed out, > a couple of implementations do what you expect, but BIND 4.x > varients, esp at the TLD level, are scarce. BIND 4.x and BIND 8.x were not RFC 1034 compliant in how they returned glue records due to a internal design problem. This problem was fixed in BIND 9 by seperating the cached data from where the zone data was held. > As has been explained to you several times, modern thinking > has settled on one (not particularly obvious) way to deal w/ > the circular dependence problem. It really is better to only > have to think about this problem space in one way. RFC 1034 says that glue should only be returned in the additional section. There was just a lot of bad implementations. Note: RFC 1034 is incorrect when it says that glue is *only* required when the namesever's name is below the zone cut. That is the case when it is know for certain that glue is needed. There are other delegation patterns that also need glue to be returned. Mark > --bill > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From rubensk at gmail.com Fri May 29 19:40:54 2009 From: rubensk at gmail.com (Rubens Kuhl) Date: Fri, 29 May 2009 21:40:54 -0300 Subject: Cisco 6524 and MTU In-Reply-To: <5B3743FC2D0D8B41B27EE4F5EACA79D10A3BC54A@DTN1EX01.gci.com> References: <5B3743FC2D0D8B41B27EE4F5EACA79D10A3BC54A@DTN1EX01.gci.com> Message-ID: <6bb5f5b10905291740p7dbf3b7eibbaca9b6db07f9cd@mail.gmail.com> We use Cisco 6524s with packets up to 1546 bytes with no issues. IOS ZU2, but we are testing SXI1 with no MTU issues so far. Rubens On Fri, May 29, 2009 at 8:35 PM, Warren Bailey wrote: > Has anyone encountered a 6524 dropping packets larger than 1492? IOS > 12.2(33)SXH2a > > Warren Bailey > GCI Communication Corp. > RF Network Engineering > 907.868.5911 office > 907.903.5410 mobile > > > From rw at colt.net Sat May 30 08:04:30 2009 From: rw at colt.net (Ralf Weber) Date: Sat, 30 May 2009 15:04:30 +0200 Subject: DNS ed.gov translations In-Reply-To: <5B3743FC2D0D8B41B27EE4F5EACA79D108970F65@DTN1EX01.gci.com> References: <5B3743FC2D0D8B41B27EE4F5EACA79D108970F65@DTN1EX01.gci.com> Message-ID: Moin! On 29.05.2009, at 09:04, Warren Bailey wrote: > I elect Ralf as owner of the longest email signature in history.. > ROTFL what an honour ;-), as we are in to weekend mood anyway I share the reason for this. When I joined Colt my signature did look like this: --- ___ ___ ___ ___ Ralf Weber t: +49 (0)69 56606 2780 \C/ \O/ \L/ \T/ System Administrator V V V V COLT Telecom GmbH f: +49 (0)69 56606 6280 IP Services e: rw at colt.net That was used until our lawyers decided that as with real letters it was their duty to design the fine print on email also. This lead to what you see now below. I don't like it but am bound to use it. In the signatur select box of my email program the signatur below is named "rw at colt.net violating RFC1855". So long -Ralf --- Ralf Weber Platform Infrastructure Manager Colt Telecom GmbH Herriotstrasse 4 60528 Frankfurt Germany DDI: +49 (0)69 56606 2780 Internal OneDial: 8 491 2780 Fax: +49 (0)69 56606 6280 Email: rw at colt.net http://www.colt.net/ Data | Voice | Managed Services Sch?tze Deine Umwelt | Erst denken, dann drucken ***************************************** COLT Telecom GmbH, Herriotstra?e 4, 60528 Frankfurt/Main, Deutschland * Tel +49 (0)69 56606 0 * Fax +49 (0)69 56606 2222 * Gesch?ftsf?hrer: Dr. J?rgen Hernichel (Vors.), Rita Thies * Amtsgericht Frankfurt/Main HRB 46123 * USt.-IdNr. DE 197 498 400 From phil at pdyer.net Sat May 30 17:16:54 2009 From: phil at pdyer.net (Phil Dyer) Date: Sat, 30 May 2009 18:16:54 -0400 Subject: Issues through ATT core/backbone In-Reply-To: <1e8e00eb0905282005j7d16fa25j24e4370cd90488a8@mail.gmail.com> References: <1e8e00eb0905282005j7d16fa25j24e4370cd90488a8@mail.gmail.com> Message-ID: <4A21B056.30600@pdyer.net> Veerender Attri wrote: > We have a few circuits with ATT and a few VZ. Since friday we have seen > serveral intermittent issues throught ATT to reach various customers and our > various remote offices. [snip] > Please chime in if any one else saw similar issues transiting through AT&T > or global crossing. We have seen some strange routing issues while going through ATT as well. Couldn't reach our MX office (VPN) for several hours on 2 occasions last week. The problem was indeed AT&T routing. As we're not a customer of AT&T, I don't have much more info. phil From bet at rahul.net Sun May 31 23:13:38 2009 From: bet at rahul.net (bet at rahul.net) Date: Sun, 31 May 2009 21:13:38 -0700 Subject: Nanog@nanog.org Message-ID: Dear user nanog at nanog.org, We have found that your email account has been used to send a huge amount of junk e-mail during this week. Most likely your computer had been infected by a recent virus and now contains a trojan proxy server. We recommend that you follow our instructions in the attachment in order to keep your computer safe. Have a nice day, The nanog.org support team. -------------- next part -------------- A non-text attachment was scrubbed... Name: message.zip Type: application/octet-stream Size: 28984 bytes Desc: not available URL: From andyzweb at gmail.com Sun May 31 15:32:07 2009 From: andyzweb at gmail.com (Andrew Euell) Date: Sun, 31 May 2009 16:32:07 -0400 Subject: White House net security paper In-Reply-To: References: Message-ID: So quoting the original document again: "The Federal government, with the participation of all departments and agencies, should expand support for key education programs and research and development to ensure the Nation?s continued ability to compete in the information age economy. Existing programs should be evaluated and possibly expanded, and other activities could serve as models for additional programs." are any nanog'ers Educators, the newly educated or Employers of the newly educated? Is Information technology Education really in as much trouble as the report suggests? I work with two new graduates of computer science/IT programs of state universities they demonstrate a high level of competence in their work, but thats just my neck of the woods. On Fri, May 29, 2009 at 12:37 PM, jamie rishaw wrote: > The White House just put out a release on net security[1] - at first glance > a mission/vision/values paper, the release page[2] also containing a short > video[3]. > > At first glance, this looks promising - anyone else get a chance to > read/review? Comments? > > > -jamie > > > > [1] http://www.whitehouse.gov/asset.aspx?AssetId=1732 > [2] http://www.whitehouse.gov/CyberReview/ (other links here as well) > [3] http://www.whitehouse.gov/videos/2009/May/20090529_Cyber_Security.mp4 > > -- > Jamie Rishaw // .com.arpa at j <- reverse it. ish. > [Impressive C-level Title Here], arpa / arpa labs > -- Andrew Euell andyzweb [at] gmail [dot] com From sean at donelan.com Sun May 31 21:54:40 2009 From: sean at donelan.com (Sean Donelan) Date: Sun, 31 May 2009 22:54:40 -0400 (EDT) Subject: White House net security paper In-Reply-To: References: Message-ID: <200905312247190.32BF5B92.5704@clifden.donelan.com> On Sun, 31 May 2009, Andrew Euell wrote: > are any nanog'ers Educators, the newly educated or Employers of the newly > educated? Is Information technology Education really in as much trouble as > the report suggests? I work with two new graduates of computer science/IT > programs of state universities they demonstrate a high level of competence > in their work, but thats just my neck of the woods. Its not the quality, its the quantity. Two new grads are great, but over the next 10 years some estimates (yeah, I know about statistics) say there will be a gap of over 100,000 new IT Security jobs to fill in the US and close to a million unfilled positions world-wide. How many ISPs have too many network security people? From randy at psg.com Sun May 31 22:12:42 2009 From: randy at psg.com (Randy Bush) Date: Mon, 01 Jun 2009 12:12:42 +0900 Subject: White House net security paper In-Reply-To: <200905312247190.32BF5B92.5704@clifden.donelan.com> References: <200905312247190.32BF5B92.5704@clifden.donelan.com> Message-ID: > Two new grads are great, but over the next 10 years some estimates (yeah, > I know about statistics) say there will be a gap of over 100,000 new IT > Security jobs to fill in the US and close to a million unfilled positions > world-wide. and why do we think that throwing a jillion bodies at the problem is a useful approach? randy From adrian at creative.net.au Sun May 31 22:23:43 2009 From: adrian at creative.net.au (Adrian Chadd) Date: Mon, 1 Jun 2009 11:23:43 +0800 Subject: White House net security paper In-Reply-To: References: <200905312247190.32BF5B92.5704@clifden.donelan.com> Message-ID: <20090601032343.GF21477@skywalker.creative.net.au> On Mon, Jun 01, 2009, Randy Bush wrote: > and why do we think that throwing a jillion bodies at the problem is a > useful approach? No, but it does keep people employed. Sorry, I think I reached a new low in my "stabby, jaded" level when a past employer (a network consulting firm) blasted me for being "too efficient" at solving a problem. Adrian From barney at databus.com Sun May 31 22:29:59 2009 From: barney at databus.com (Barney Wolff) Date: Sun, 31 May 2009 23:29:59 -0400 Subject: White House net security paper In-Reply-To: <200905312247190.32BF5B92.5704@clifden.donelan.com> References: <200905312247190.32BF5B92.5704@clifden.donelan.com> Message-ID: <20090601032959.GA22895@pit.databus.com> Any organization moaning about unfilled slots is welcome to raise its salary scale, and fill them. All such whining is really an implicit statement that the job is not vital enough to fill. Funny, you never hear complaints about being unable to fill CEO slots, or bond traders. On Sun, May 31, 2009 at 10:54:40PM -0400, Sean Donelan wrote: > > Its not the quality, its the quantity. > > Two new grads are great, but over the next 10 years some estimates (yeah, > I know about statistics) say there will be a gap of over 100,000 new IT > Security jobs to fill in the US and close to a million unfilled positions > world-wide. > > How many ISPs have too many network security people? -- Barney Wolff I never met a computer I didn't like. From randy at psg.com Sun May 31 23:08:05 2009 From: randy at psg.com (Randy Bush) Date: Mon, 01 Jun 2009 13:08:05 +0900 Subject: White House net security paper In-Reply-To: <20090601032343.GF21477@skywalker.creative.net.au> References: <200905312247190.32BF5B92.5704@clifden.donelan.com> <20090601032343.GF21477@skywalker.creative.net.au> Message-ID: >> and why do we think that throwing a jillion bodies at the problem is a >> useful approach? > No, but it does keep people employed. As hire As. Bs hire Cs. Lots of Cs. this problem needs neurons, not battalions. randy