From rafael at gav.ufsc.br Fri May 1 02:32:02 2015 From: rafael at gav.ufsc.br (Rafael Possamai) Date: Thu, 30 Apr 2015 21:32:02 -0500 Subject: ADSL Line Extenders In-Reply-To: References: <553FFA97.8030405@vaxination.ca> Message-ID: Yes, you are correct, P2MP is what I meant to say. I'd also suggest Ubiquiti radios, some of their models being capable of doing 1gbps+. On Thu, Apr 30, 2015 at 7:59 AM, Shimon Hochbaum < shimon.hochbaum at teliswitch.com> wrote: > I second wholeheartedly the idea of wireless for this application, except > that Rafael probably meant point to multipoint solutions: Trango > https://www.trangosys.com/altum-ac or Waveip > http://www.waveip.com/products/overview/ are 2 good options. > > Line extenders supporting ADSL2+ won't do much good: the 2 and the + > denote improvements in the short range, less than 5000', probably not > relevant in your case. If wired is your preferred option, you might want to > consider HDSL based products, which are meant to drive 1.5M symmetric over > long distances, power fed from the 2 sides for simplicity, with ability to > go higher when pairs are bundled. Adtran should be the 1st place to look at. > > Good luck, Shimon > > > -----Original Message----- > > From: Rafael Possamai [mailto:rafael at gav.ufsc.br] > > Sent: Wednesday, April 29, 2015 17:37 > > To: Jean-Francois Mezei > > Cc: nanog at nanog.org > > Subject: Re: ADSL Line Extenders > > > > Semi-related question: in instances like this, wouldn't a point-to-point > link > > provide larger throughput and be less expensive? Unless you are talking > about > > several subscribers that are already installed and operating. > > Depending on the situation, it might make sense to set a few sectorial > > antennas at a high-point and link everyone with small inexpensive CPE > > antennas. Just a quick thought. > > > > Good luck, > > Rafael > > > > > > On Tue, Apr 28, 2015 at 4:24 PM, Jean-Francois Mezei < > > jfmezei_nanog at vaxination.ca> wrote: > > > > > > > > A friend on a rural DSl association asked about ADSL line extenders. > > > > > > A search on Google yields many products dating back to the days of > > > ADSL-1 advertising 1mbps profiles, but a few seem more recent and > > > support ADSL2+ (not sure if any support VDSL2). > > > > > > Are these thing out of date and no longer deployed ? Were they ever > > > effective, or just vapourware that didn't really improve things ? > > > > > > > > > Do any Telcos still deploy them ? Anyone know of deployments in > Canada ? > > > > > > I just need a reality check on those devices. > > > > > > jf > > > > > > From josh at spitwspots.com Fri May 1 02:41:04 2015 From: josh at spitwspots.com (Josh Reynolds) Date: Thu, 30 Apr 2015 18:41:04 -0800 Subject: ADSL Line Extenders In-Reply-To: References: <553FFA97.8030405@vaxination.ca> Message-ID: <5542E7C0.2070500@spitwspots.com> 1Gbps Aggregate. AF24/AF24HD are ~ 750Mbps/750Mbps at max modulation. That is a PtP system though, not PtMP. If you need to carry ADSL traffic, you most likely need a "timing-enabled" (can't remember the RFC) radio. RadWin and Trango should fit the bill, likely others. Honestly though, I'd ditch the ADSL if possible. Depending on the terrain, wireless may work. It's not magic, and won't shoot through acres and acres of trees, but if you have a good line-of-site (60% clear 1st Fresnel zone), those are prime subscribers for 5GHz Ubiquiti Rockets + Sectors and ~$100 CPE devices. Don't put more than 25 or 30 subscribers per sector, and you can easily hit 10Mbps per sub with a modest oversubscription ratio. If you went for the RM5-AC line in PtMP, you might be able to do 40Mbps per sub. Josh Reynolds CIO, SPITwSPOTS www.spitwspots.com On 04/30/2015 06:32 PM, Rafael Possamai wrote: > Yes, you are correct, P2MP is what I meant to say. I'd also suggest > Ubiquiti radios, some of their models being capable of doing 1gbps+. > > On Thu, Apr 30, 2015 at 7:59 AM, Shimon Hochbaum < > shimon.hochbaum at teliswitch.com> wrote: > >> I second wholeheartedly the idea of wireless for this application, except >> that Rafael probably meant point to multipoint solutions: Trango >> https://www.trangosys.com/altum-ac or Waveip >> http://www.waveip.com/products/overview/ are 2 good options. >> >> Line extenders supporting ADSL2+ won't do much good: the 2 and the + >> denote improvements in the short range, less than 5000', probably not >> relevant in your case. If wired is your preferred option, you might want to >> consider HDSL based products, which are meant to drive 1.5M symmetric over >> long distances, power fed from the 2 sides for simplicity, with ability to >> go higher when pairs are bundled. Adtran should be the 1st place to look at. >> >> Good luck, Shimon >> >>> -----Original Message----- >>> From: Rafael Possamai [mailto:rafael at gav.ufsc.br] >>> Sent: Wednesday, April 29, 2015 17:37 >>> To: Jean-Francois Mezei >>> Cc: nanog at nanog.org >>> Subject: Re: ADSL Line Extenders >>> >>> Semi-related question: in instances like this, wouldn't a point-to-point >> link >>> provide larger throughput and be less expensive? Unless you are talking >> about >>> several subscribers that are already installed and operating. >>> Depending on the situation, it might make sense to set a few sectorial >>> antennas at a high-point and link everyone with small inexpensive CPE >>> antennas. Just a quick thought. >>> >>> Good luck, >>> Rafael >>> >>> >>> On Tue, Apr 28, 2015 at 4:24 PM, Jean-Francois Mezei < >>> jfmezei_nanog at vaxination.ca> wrote: >>> >>>> A friend on a rural DSl association asked about ADSL line extenders. >>>> >>>> A search on Google yields many products dating back to the days of >>>> ADSL-1 advertising 1mbps profiles, but a few seem more recent and >>>> support ADSL2+ (not sure if any support VDSL2). >>>> >>>> Are these thing out of date and no longer deployed ? Were they ever >>>> effective, or just vapourware that didn't really improve things ? >>>> >>>> >>>> Do any Telcos still deploy them ? Anyone know of deployments in >> Canada ? >>>> I just need a reality check on those devices. >>>> >>>> jf >>>> >> >> From mleber at he.net Fri May 1 14:28:47 2015 From: mleber at he.net (Mike Leber) Date: Fri, 01 May 2015 07:28:47 -0700 Subject: IPTV providers in IN/Chicago In-Reply-To: <8474125.1516.1430222741898.JavaMail.mhammett@ThunderFuck> References: <8474125.1516.1430222741898.JavaMail.mhammett@ThunderFuck> Message-ID: <55438D9F.4060406@he.net> Because selling transport is really good revenue for facilities based carriers everywhere and the revenue per deal is higher than selling the same amount of Internet access (even if the bits are going to the other side of the planet). Consider that 1 Gbps metro ethernet layer 2 transport circuit might be between $1500 and $3500 per month (wild guess) and the commodity residential gige Internet access is is starting look like it's going to be between $70 and $350 per month. A transport sale is good money they can pick up off the ground just by saying yes. I'm sure if you were a sales rep you'd like selling metro ethernet loops for the larger commissions and the larger customers that it got you involved with. If you were a regional sales director for a carrier you'd especially like how these help your sales group more quickly make your numbers. These deals are priced to pay for extending the physical plant as well. Any carrier that doesn't help a customer with a transport request ends up effectively sending that customer to a competitor, with the result the customer then pays the competitor to extend their physical plant to the customer's location in the original carriers territory. Mike. On 4/28/15 5:05 AM, Mike Hammett wrote: > I'm not sure why or that Comcast would enable competition. Maybe I'm wrong. Then again, maybe Brandon isn't in a Comcast served area. > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > > > Midwest Internet Exchange > http://www.midwest-ix.com > > > ----- Original Message ----- > > From: "Frank Bulk" > To: "Brandon Martin" , nanog at nanog.org > Sent: Tuesday, April 28, 2015 12:35:43 AM > Subject: RE: IPTV providers in IN/Chicago > > I believe Vubiquity (http://www.vubiquity.com/product-portfolio/livevu/) does, as well as Comcast HITS (http://www.comcastwholesale.com/products-services/mpeg-2-content-delivery/mpeg-2-delivery-content-providers). > > Frank > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Brandon Martin > Sent: Monday, April 27, 2015 7:17 PM > To: nanog at nanog.org > Subject: IPTV providers in IN/Chicago > > Anyone know of an IPTV provider/wholesaler who I could meet in > Indianapolis (Henry St/Lifeline) or Chicago (Cermak/Equinix)? > > Direct solicitations are OK out-of-band. From cscora at apnic.net Fri May 1 18:12:31 2015 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 2 May 2015 04:12:31 +1000 (AEST) Subject: Weekly Routing Table Report Message-ID: <201505011812.t41ICVYC026759@thyme.rand.apnic.net> This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. The posting is sent to APOPS, NANOG, AfNOG, AusNOG, SANOG, PacNOG, CaribNOG and the RIPE Routing Working Group. Daily listings are sent to bgp-stats at lists.apnic.net For historical data, please see http://thyme.rand.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 02 May, 2015 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 542615 Prefixes after maximum aggregation (per Origin AS): 206677 Deaggregation factor: 2.63 Unique aggregates announced (without unneeded subnets): 264045 Total ASes present in the Internet Routing Table: 50153 Prefixes per ASN: 10.82 Origin-only ASes present in the Internet Routing Table: 36593 Origin ASes announcing only one prefix: 16304 Transit ASes present in the Internet Routing Table: 6326 Transit-only ASes present in the Internet Routing Table: 175 Average AS path length visible in the Internet Routing Table: 4.4 Max AS path length visible: 123 Max AS path prepend of ASN ( 18596) 121 Prefixes from unregistered ASNs in the Routing Table: 1094 Unregistered ASNs in the Routing Table: 393 Number of 32-bit ASNs allocated by the RIRs: 9336 Number of 32-bit ASNs visible in the Routing Table: 7234 Prefixes from 32-bit ASNs in the Routing Table: 26398 Number of bogon 32-bit ASNs visible in the Routing Table: 2 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 357 Number of addresses announced to Internet: 2741034756 Equivalent to 163 /8s, 96 /16s and 223 /24s Percentage of available address space announced: 74.0 Percentage of allocated address space announced: 74.0 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 97.3 Total number of prefixes smaller than registry allocations: 182211 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 133995 Total APNIC prefixes after maximum aggregation: 38939 APNIC Deaggregation factor: 3.44 Prefixes being announced from the APNIC address blocks: 140133 Unique aggregates announced from the APNIC address blocks: 56870 APNIC Region origin ASes present in the Internet Routing Table: 5031 APNIC Prefixes per ASN: 27.85 APNIC Region origin ASes announcing only one prefix: 1203 APNIC Region transit ASes present in the Internet Routing Table: 883 Average APNIC Region AS path length visible: 4.4 Max APNIC Region AS path length visible: 44 Number of APNIC region 32-bit ASNs visible in the Routing Table: 1412 Number of APNIC addresses announced to Internet: 748015104 Equivalent to 44 /8s, 149 /16s and 206 /24s Percentage of available APNIC address space announced: 87.4 APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079, 55296-56319, 58368-59391, 63488-64098, 131072-135580 APNIC Address Blocks 1/8, 14/8, 27/8, 36/8, 39/8, 42/8, 43/8, 49/8, 58/8, 59/8, 60/8, 61/8, 101/8, 103/8, 106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 133/8, 150/8, 153/8, 163/8, 171/8, 175/8, 180/8, 182/8, 183/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, 223/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 178441 Total ARIN prefixes after maximum aggregation: 87808 ARIN Deaggregation factor: 2.03 Prefixes being announced from the ARIN address blocks: 180863 Unique aggregates announced from the ARIN address blocks: 84299 ARIN Region origin ASes present in the Internet Routing Table: 16578 ARIN Prefixes per ASN: 10.91 ARIN Region origin ASes announcing only one prefix: 6113 ARIN Region transit ASes present in the Internet Routing Table: 1732 Average ARIN Region AS path length visible: 3.8 Max ARIN Region AS path length visible: 123 Number of ARIN region 32-bit ASNs visible in the Routing Table: 416 Number of ARIN addresses announced to Internet: 1065268096 Equivalent to 63 /8s, 126 /16s and 179 /24s Percentage of available ARIN address space announced: 56.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, 62464-63487, 64198-64296, 393216-395164 ARIN Address Blocks 3/8, 4/8, 6/8, 7/8, 8/8, 9/8, 11/8, 12/8, 13/8, 15/8, 16/8, 17/8, 18/8, 19/8, 20/8, 21/8, 22/8, 23/8, 24/8, 26/8, 28/8, 29/8, 30/8, 32/8, 33/8, 34/8, 35/8, 38/8, 40/8, 44/8, 45/8, 47/8, 48/8, 50/8, 52/8, 53/8, 54/8, 55/8, 56/8, 57/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, 100/8, 104/8, 107/8, 108/8, 128/8, 129/8, 130/8, 131/8, 132/8, 134/8, 135/8, 136/8, 137/8, 138/8, 139/8, 140/8, 142/8, 143/8, 144/8, 146/8, 147/8, 148/8, 149/8, 152/8, 155/8, 156/8, 157/8, 158/8, 159/8, 160/8, 161/8, 162/8, 164/8, 165/8, 166/8, 167/8, 168/8, 169/8, 170/8, 172/8, 173/8, 174/8, 184/8, 192/8, 198/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 214/8, 215/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 131501 Total RIPE prefixes after maximum aggregation: 65670 RIPE Deaggregation factor: 2.00 Prefixes being announced from the RIPE address blocks: 137869 Unique aggregates announced from the RIPE address blocks: 85064 RIPE Region origin ASes present in the Internet Routing Table: 17948 RIPE Prefixes per ASN: 7.68 RIPE Region origin ASes announcing only one prefix: 8161 RIPE Region transit ASes present in the Internet Routing Table: 2971 Average RIPE Region AS path length visible: 4.9 Max RIPE Region AS path length visible: 34 Number of RIPE region 32-bit ASNs visible in the Routing Table: 3651 Number of RIPE addresses announced to Internet: 694791300 Equivalent to 41 /8s, 105 /16s and 172 /24s Percentage of available RIPE address space announced: 101.0 RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-52223, 56320-58367 59392-61439, 61952-62463, 196608-202239 RIPE Address Blocks 2/8, 5/8, 25/8, 31/8, 37/8, 46/8, 51/8, 62/8, 77/8, 78/8, 79/8, 80/8, 81/8, 82/8, 83/8, 84/8, 85/8, 86/8, 87/8, 88/8, 89/8, 90/8, 91/8, 92/8, 93/8, 94/8, 95/8, 109/8, 141/8, 145/8, 151/8, 176/8, 178/8, 185/8, 188/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 59301 Total LACNIC prefixes after maximum aggregation: 11195 LACNIC Deaggregation factor: 5.30 Prefixes being announced from the LACNIC address blocks: 69379 Unique aggregates announced from the LACNIC address blocks: 32345 LACNIC Region origin ASes present in the Internet Routing Table: 2420 LACNIC Prefixes per ASN: 28.67 LACNIC Region origin ASes announcing only one prefix: 625 LACNIC Region transit ASes present in the Internet Routing Table: 497 Average LACNIC Region AS path length visible: 4.9 Max LACNIC Region AS path length visible: 22 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 1644 Number of LACNIC addresses announced to Internet: 167524096 Equivalent to 9 /8s, 252 /16s and 55 /24s Percentage of available LACNIC address space announced: 99.9 LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 61440-61951, 64099-64197, 262144-265628 + ERX transfers LACNIC Address Blocks 177/8, 179/8, 181/8, 186/8, 187/8, 189/8, 190/8, 191/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 12814 Total AfriNIC prefixes after maximum aggregation: 3021 AfriNIC Deaggregation factor: 4.24 Prefixes being announced from the AfriNIC address blocks: 14014 Unique aggregates announced from the AfriNIC address blocks: 5143 AfriNIC Region origin ASes present in the Internet Routing Table: 737 AfriNIC Prefixes per ASN: 19.01 AfriNIC Region origin ASes announcing only one prefix: 202 AfriNIC Region transit ASes present in the Internet Routing Table: 160 Average AfriNIC Region AS path length visible: 4.5 Max AfriNIC Region AS path length visible: 24 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 111 Number of AfriNIC addresses announced to Internet: 65126912 Equivalent to 3 /8s, 225 /16s and 194 /24s Percentage of available AfriNIC address space announced: 64.7 AfriNIC AS Blocks 36864-37887, 327680-328703 & ERX transfers AfriNIC Address Blocks 41/8, 102/8, 105/8, 154/8, 196/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4766 2929 11557 913 Korea Telecom 17974 2761 904 78 PT Telekomunikasi Indonesia 7545 2577 336 129 TPG Telecom Limited 4755 2013 422 214 TATA Communications formerly 4538 1912 4190 72 China Education and Research 9829 1656 1326 39 National Internet Backbone 9808 1572 8717 28 Guangdong Mobile Communicatio 4808 1429 2241 452 CNCGROUP IP network China169 9583 1416 117 577 Sify Limited 9498 1325 334 95 BHARTI Airtel Ltd. Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 22773 3013 2955 142 Cox Communications Inc. 6389 2832 3688 51 BellSouth.net Inc. 3356 2551 10684 479 Level 3 Communications, Inc. 18566 2039 379 182 MegaPath Corporation 20115 1879 1844 432 Charter Communications 6983 1754 866 245 EarthLink, Inc. 4323 1616 1021 409 tw telecom holdings, inc. 30036 1527 310 490 Mediacom Communications Corp 701 1404 11276 687 MCI Communications Services, 22561 1353 413 248 CenturyTel Internet Holdings, Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 39891 2472 128 6 SaudiNet, Saudi Telecom Compa 34984 1970 303 368 TELLCOM ILETISIM HIZMETLERI A 20940 1816 703 1341 Akamai International B.V. 6849 1214 356 24 JSC "Ukrtelecom" 31148 1049 45 23 Freenet Ltd. 13188 1035 96 68 TOV "Bank-Inform" 8402 1027 544 15 OJSC "Vimpelcom" 12479 920 867 80 France Telecom Espana SA 8551 886 373 48 Bezeq International-Ltd 9198 854 349 25 JSC Kazakhtelecom Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 10620 3211 523 211 Telmex Colombia S.A. 28573 2315 2169 117 NET Servi?os de Comunica??o S 7303 1657 1043 242 Telecom Argentina S.A. 6147 1615 374 30 Telefonica del Peru S.A.A. 8151 1592 3193 452 Uninet S.A. de C.V. 6503 1247 421 53 Axtel, S.A.B. de C.V. 7738 999 1882 41 Telemar Norte Leste S.A. 26615 978 2325 35 Tim Celular S.A. 3816 924 418 155 COLOMBIA TELECOMUNICACIONES S 18881 864 1036 22 Global Village Telecom Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 8452 1707 958 13 TE-AS 24863 971 284 27 Link Egypt (Link.NET) 36903 495 249 88 Office National des Postes et 36992 419 1229 32 ETISALAT MISR 37492 303 155 72 Orange Tunisie 24835 300 144 9 Vodafone Data 3741 250 857 208 Internet Solutions 29571 231 21 12 Cote d'Ivoire Telecom 36947 201 807 13 Telecom Algeria 37054 181 19 6 Data Telecom Service Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 10620 3211 523 211 Telmex Colombia S.A. 22773 3013 2955 142 Cox Communications Inc. 4766 2929 11557 913 Korea Telecom 6389 2832 3688 51 BellSouth.net Inc. 17974 2761 904 78 PT Telekomunikasi Indonesia 7545 2577 336 129 TPG Telecom Limited 3356 2551 10684 479 Level 3 Communications, Inc. 39891 2472 128 6 SaudiNet, Saudi Telecom Compa 28573 2315 2169 117 NET Servi?os de Comunica??o S 18566 2039 379 182 MegaPath Corporation Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 22773 3013 2871 Cox Communications Inc. 6389 2832 2781 BellSouth.net Inc. 17974 2761 2683 PT Telekomunikasi Indonesia 39891 2472 2466 SaudiNet, Saudi Telecom Compa 7545 2577 2448 TPG Telecom Limited 28573 2315 2198 NET Servi?os de Comunica??o S 3356 2551 2072 Level 3 Communications, Inc. 4766 2929 2016 Korea Telecom 18566 2039 1857 MegaPath Corporation 4538 1912 1840 China Education and Research Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 30662 UNALLOCATED 8.2.129.0/24 3356 Level 3 Communicatio 53506 UNALLOCATED 8.17.102.0/23 3356 Level 3 Communicatio 46467 UNALLOCATED 8.19.192.0/24 46887 Lightower Fiber Netw 18985 UNALLOCATED 8.21.68.0/22 3356 Level 3 Communicatio 46473 UNALLOCATED 8.27.122.0/24 12180 Internap Network Ser 46473 UNALLOCATED 8.27.124.0/24 12180 Internap Network Ser 27205 UNALLOCATED 8.38.16.0/21 6461 Abovenet Communicati 15347 UNALLOCATED 8.224.147.0/24 12064 Cox Communications I 33628 UNALLOCATED 12.0.239.0/24 1239 Sprint 32805 UNALLOCATED 12.1.225.0/24 7018 AT&T Services, Inc. Complete listing at http://thyme.rand.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 5.100.241.0/24 23456 32bit Transition AS 23.226.112.0/20 62788 >>UNKNOWN<< 27.100.7.0/24 56096 >>UNKNOWN<< 31.217.248.0/21 44902 COVAGE NETWORKS SASU 41.73.1.0/24 37004 >>UNKNOWN<< 41.73.10.0/24 37004 >>UNKNOWN<< 41.73.11.0/24 37004 >>UNKNOWN<< 41.73.12.0/24 37004 >>UNKNOWN<< 41.73.13.0/24 37004 >>UNKNOWN<< 41.73.15.0/24 37004 >>UNKNOWN<< Complete listing at http://thyme.rand.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:16 /9:12 /10:34 /11:94 /12:264 /13:505 /14:1005 /15:1717 /16:12958 /17:7210 /18:12230 /19:25341 /20:35907 /21:38604 /22:59228 /23:51517 /24:292935 /25:1135 /26:1142 /27:717 /28:12 /29:11 /30:8 /31:0 /32:13 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 39891 2432 2472 SaudiNet, Saudi Telecom Compa 22773 2222 3013 Cox Communications Inc. 18566 1995 2039 MegaPath Corporation 6389 1654 2832 BellSouth.net Inc. 6983 1401 1754 EarthLink, Inc. 30036 1370 1527 Mediacom Communications Corp 34984 1289 1970 TELLCOM ILETISIM HIZMETLERI A 6147 1167 1615 Telefonica del Peru S.A.A. 10620 1135 3211 Telmex Colombia S.A. 11492 1111 1186 CABLE ONE, INC. Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1482 2:678 4:94 5:1767 6:23 8:1420 12:1822 13:10 14:1329 15:17 16:2 17:44 18:21 20:48 23:1226 24:1707 27:1890 31:1569 32:38 33:2 34:5 35:3 36:118 37:1903 38:1019 39:7 40:250 41:3009 42:323 43:1252 44:26 45:487 46:2155 47:40 49:902 50:800 52:12 54:73 55:5 56:8 57:37 58:1278 59:711 60:472 61:1742 62:1332 63:1915 64:4403 65:2252 66:4055 67:2048 68:1049 69:3253 70:959 71:449 72:1953 74:2653 75:334 76:414 77:1434 78:1185 79:794 80:1327 81:1348 82:808 83:692 84:708 85:1348 86:389 87:1075 88:509 89:1812 90:151 91:5965 92:831 93:2196 94:2035 95:2125 96:432 97:354 98:1054 99:49 100:69 101:828 103:7285 104:1656 105:61 106:246 107:943 108:620 109:2041 110:1094 111:1477 112:779 113:1116 114:821 115:1257 116:1355 117:1051 118:1793 119:1452 120:446 121:1077 122:2206 123:1796 124:1498 125:1581 128:627 129:380 130:393 131:1166 132:482 133:174 134:425 135:107 136:326 137:314 138:663 139:148 140:225 141:423 142:661 143:503 144:568 145:114 146:696 147:590 148:1134 149:432 150:571 151:614 152:494 153:243 154:455 155:842 156:407 157:463 158:320 159:1000 160:379 161:652 162:1955 163:424 164:671 165:691 166:304 167:819 168:1289 169:167 170:1468 171:241 172:43 173:1510 174:701 175:676 176:1233 177:3785 178:2143 179:872 180:1934 181:1681 182:1741 183:619 184:740 185:3398 186:2635 187:1739 188:2002 189:1569 190:7672 191:952 192:8296 193:5579 194:4124 195:3612 196:1700 197:1072 198:5504 199:5536 200:6654 201:3067 202:9463 203:9110 204:4674 205:2822 206:3086 207:2978 208:3938 209:3956 210:3527 211:1861 212:2497 213:2310 214:857 215:71 216:5568 217:1813 218:691 219:454 220:1444 221:788 222:478 223:676 End of report From cidr-report at potaroo.net Fri May 1 22:00:00 2015 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 1 May 2015 22:00:00 GMT Subject: The Cidr Report Message-ID: <201505012200.t41M00c5046454@wattle.apnic.net> This report has been generated at Fri May 1 21:14:34 2015 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/2.0 for a current version of this report. Recent Table History Date Prefixes CIDR Agg 24-04-15 548904 301379 25-04-15 548726 301532 26-04-15 548766 301739 27-04-15 549010 301780 28-04-15 549276 301397 29-04-15 549242 301582 30-04-15 549333 302227 01-05-15 549780 302349 AS Summary 50420 Number of ASes in routing system 20115 Number of ASes announcing only one prefix 3211 Largest number of prefixes announced by an AS AS10620: Telmex Colombia S.A.,CO 120958464 Largest address span announced by an AS (/32s) AS4134 : CHINANET-BACKBONE No.31,Jin-rong Street,CN 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'). --- 01May15 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 550083 302368 247715 45.0% All ASes AS22773 3015 171 2844 94.3% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc.,US AS6389 2831 72 2759 97.5% BELLSOUTH-NET-BLK - BellSouth.net Inc.,US AS17974 2761 78 2683 97.2% TELKOMNET-AS2-AP PT Telekomunikasi Indonesia,ID AS39891 2473 21 2452 99.2% ALJAWWALSTC-AS Saudi Telecom Company JSC,SA AS28573 2316 300 2016 87.0% NET Servi?os de Comunica??o S.A.,BR AS3356 2555 821 1734 67.9% LEVEL3 - Level 3 Communications, Inc.,US AS4766 2929 1339 1590 54.3% KIXS-AS-KR Korea Telecom,KR AS6983 1753 248 1505 85.9% ITCDELTA - Earthlink, Inc.,US AS9808 1572 67 1505 95.7% CMNET-GD Guangdong Mobile Communication Co.Ltd.,CN AS20115 1879 496 1383 73.6% CHARTER-NET-HKY-NC - Charter Communications,US AS10620 3211 1843 1368 42.6% Telmex Colombia S.A.,CO AS7303 1657 292 1365 82.4% Telecom Argentina S.A.,AR AS7545 2624 1264 1360 51.8% TPG-INTERNET-AP TPG Telecom Limited,AU AS6147 1615 281 1334 82.6% Telefonica del Peru S.A.A.,PE AS4755 2011 708 1303 64.8% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP,IN AS9498 1325 110 1215 91.7% BBIL-AP BHARTI Airtel Ltd.,IN AS4323 1624 411 1213 74.7% TWTC - tw telecom holdings, inc.,US AS18566 2038 868 1170 57.4% MEGAPATH5-US - MegaPath Corporation,US AS8452 1910 809 1101 57.6% TE-AS TE-AS,EG AS7552 1155 55 1100 95.2% VIETEL-AS-AP Viettel Corporation,VN AS22561 1354 265 1089 80.4% CENTURYLINK-LEGACY-LIGHTCORE - CenturyTel Internet Holdings, Inc.,US AS8402 1024 24 1000 97.7% CORBINA-AS OJSC "Vimpelcom",RU AS8151 1595 631 964 60.4% Uninet S.A. de C.V.,MX AS6849 1211 249 962 79.4% UKRTELNET JSC UKRTELECOM,UA AS7738 999 83 916 91.7% Telemar Norte Leste S.A.,BR AS38285 982 119 863 87.9% M2TELECOMMUNICATIONS-AU M2 Telecommunications Group Ltd,AU AS4538 1930 1076 854 44.2% ERX-CERNET-BKB China Education and Research Network Center,CN AS18881 864 33 831 96.2% Global Village Telecom,BR AS26615 978 161 817 83.5% Tim Celular S.A.,BR AS855 828 54 774 93.5% CANET-ASN-4 - Bell Aliant Regional Communications, Inc.,CA Total 55019 12949 42070 76.5% Top 30 total Possible Bogus Routes 5.100.241.0/24 AS19957 -Reserved AS-,ZZ 23.226.112.0/20 AS62788 -Reserved AS-,ZZ 27.100.7.0/24 AS56096 31.217.248.0/21 AS44902 COV-ASN COVAGE NETWORKS SASU,FR 41.73.1.0/24 AS37004 -Reserved AS-,ZZ 41.73.10.0/24 AS37004 -Reserved AS-,ZZ 41.73.11.0/24 AS37004 -Reserved AS-,ZZ 41.73.12.0/24 AS37004 -Reserved AS-,ZZ 41.73.13.0/24 AS37004 -Reserved AS-,ZZ 41.73.15.0/24 AS37004 -Reserved AS-,ZZ 41.73.16.0/24 AS37004 -Reserved AS-,ZZ 41.73.18.0/24 AS37004 -Reserved AS-,ZZ 41.73.20.0/24 AS37004 -Reserved AS-,ZZ 41.73.21.0/24 AS37004 -Reserved AS-,ZZ 41.76.48.0/21 AS36969 MTL-AS,MW 41.78.180.0/23 AS37265 -Reserved AS-,ZZ 41.189.96.0/20 AS37000 -Reserved AS-,ZZ 41.189.127.0/24 AS37000 -Reserved AS-,ZZ 41.189.128.0/24 AS37000 -Reserved AS-,ZZ 41.191.108.0/22 AS37004 -Reserved AS-,ZZ 41.191.108.0/24 AS37004 -Reserved AS-,ZZ 41.191.109.0/24 AS37004 -Reserved AS-,ZZ 41.191.110.0/24 AS37004 -Reserved AS-,ZZ 41.191.111.0/24 AS37004 -Reserved AS-,ZZ 41.223.208.0/22 AS37000 -Reserved AS-,ZZ 41.242.152.0/22 AS37558 LITC,LY 41.242.156.0/22 AS37558 LITC,LY 45.67.78.0/24 AS38040 GLOBAL-TRANSIT-TOT-IIG-TH TOT Public Company Limited,TH 65.75.216.0/23 AS10494 AAI - Accurate Automation, Inc.,US 65.75.217.0/24 AS10494 AAI - Accurate Automation, Inc.,US 65.111.1.0/24 AS32258 SDNGLOBAL - SDN Global,US 66.78.66.0/23 AS10835 VISIONARY - Visionary Communications, Inc.,US 66.78.68.0/22 AS10835 VISIONARY - Visionary Communications, Inc.,US 66.78.76.0/23 AS10835 VISIONARY - Visionary Communications, Inc.,US 66.78.80.0/21 AS10835 VISIONARY - Visionary Communications, Inc.,US 66.78.91.0/24 AS10835 VISIONARY - Visionary Communications, Inc.,US 66.180.64.0/21 AS32558 ZEUTER - Zeuter Development Corporation,CA 66.187.240.0/20 AS14552 ACS-SOUTHEASTDATACENTER - Affiliated Computer Services, Inc.,US 66.205.224.0/19 AS16526 BIRCH-TELECOM - Birch Telecom, Inc.,US 66.251.128.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.133.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.134.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.136.0/21 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.140.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.141.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.142.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 72.19.0.0/19 AS16526 BIRCH-TELECOM - Birch Telecom, Inc.,US 74.113.200.0/23 AS46939 -Reserved AS-,ZZ 74.114.52.0/22 AS40818 -Reserved AS-,ZZ 74.114.52.0/23 AS40818 -Reserved AS-,ZZ 74.114.52.0/24 AS40818 -Reserved AS-,ZZ 74.114.53.0/24 AS40818 -Reserved AS-,ZZ 74.114.54.0/23 AS40818 -Reserved AS-,ZZ 74.114.54.0/24 AS40818 -Reserved AS-,ZZ 74.114.55.0/24 AS40818 -Reserved AS-,ZZ 74.114.184.0/22 AS19888 -Reserved AS-,ZZ 74.121.24.0/22 AS36263 FORONA - Forona Technologies, Inc.,US 74.123.136.0/21 AS53358 -Reserved AS-,ZZ 77.243.91.0/24 AS42597 -Reserved AS-,ZZ 80.78.133.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US 80.78.134.0/23 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US 80.78.134.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US 80.78.135.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US 80.250.32.0/22 AS37106 ODUA-AS,NG 83.142.48.0/24 AS13213 UK2NET-AS UK2 - Ltd,GB 83.142.49.0/24 AS13213 UK2NET-AS UK2 - Ltd,GB 91.103.8.0/24 AS42551 -Reserved AS-,ZZ 91.103.9.0/24 AS42551 -Reserved AS-,ZZ 91.103.10.0/24 AS42551 -Reserved AS-,ZZ 91.103.11.0/24 AS42551 -Reserved AS-,ZZ 91.193.60.0/22 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 91.195.66.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 91.197.36.0/22 AS43359 -Reserved AS-,ZZ 91.230.27.0/24 AS57022 -Reserved AS-,ZZ 98.143.160.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.161.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.162.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.163.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.164.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.165.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.166.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.167.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.168.0/22 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.172.0/22 AS26566 -Reserved AS-,ZZ 98.143.172.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.173.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.174.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.175.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 103.10.222.0/24 AS13189 103.15.92.0/22 AS23818 JETINTERNET JETINTERNET Corporation,JP 103.20.100.0/24 AS45334 AIRCEL-AS-AP Dishnet Wireless Limited,IN 103.20.101.0/24 AS45334 AIRCEL-AS-AP Dishnet Wireless Limited,IN 103.20.219.0/24 AS55795 VERBDC1-AS-AP Verb Data Centre Pty Ltd,AU 103.23.148.0/23 AS13209 103.23.148.0/24 AS13209 103.23.149.0/24 AS13209 103.26.116.0/22 AS17676 GIGAINFRA Softbank BB Corp.,JP 103.28.184.0/22 AS4686 BEKKOAME BEKKOAME INTERNET INC.,JP 103.224.0.0/22 AS18097 DCN D.C.N. Corporation,JP 103.225.116.0/22 AS23818 JETINTERNET JETINTERNET Corporation,JP 103.232.142.0/23 AS17828 TIARE-AS-PG Tiare, a business unit of Pacific Mobile Communications.,PG 103.244.112.0/22 AS23818 JETINTERNET JETINTERNET Corporation,JP 103.248.88.0/22 AS23818 JETINTERNET JETINTERNET Corporation,JP 103.248.220.0/22 AS17676 GIGAINFRA Softbank BB Corp.,JP 103.250.0.0/22 AS17676 GIGAINFRA Softbank BB Corp.,JP 103.253.164.0/23 AS13317 103.255.56.0/22 AS18097 DCN D.C.N. Corporation,JP 103.255.132.0/22 AS18097 DCN D.C.N. Corporation,JP 111.92.184.0/22 AS9797 NEXONASIAPACIFIC-AS-AP Nexon Asia Pacific P/L,AU 116.206.72.0/24 AS6461 ABOVENET - Abovenet Communications, Inc,US 116.206.85.0/24 AS6461 ABOVENET - Abovenet Communications, Inc,US 116.206.103.0/24 AS6461 ABOVENET - Abovenet Communications, Inc,US 117.120.56.0/21 AS4755 TATACOMM-AS TATA Communications formerly VSNL is Leading ISP,IN 121.54.184.0/21 AS59092 KRONOS kronos.Co.,Ltd.,JP 142.147.62.0/24 AS3958 AIRCANADA - Air Canada,CA 154.168.28.0/23 AS29571 CITelecom-AS,CI 162.216.176.0/22 AS36114 VERSAWEB-ASN - Versaweb, LLC,US 162.222.128.0/21 AS36114 VERSAWEB-ASN - Versaweb, LLC,US 162.223.116.0/22 AS54632 -Reserved AS-,ZZ 162.245.64.0/21 AS62788 -Reserved AS-,ZZ 162.248.224.0/21 AS62788 -Reserved AS-,ZZ 166.93.0.0/16 AS23537 CRITIGEN - Micro Source, Inc.,US 167.146.16.0/21 AS22527 -Reserved AS-,ZZ 167.146.26.0/23 AS22527 -Reserved AS-,ZZ 167.146.28.0/23 AS22527 -Reserved AS-,ZZ 167.146.32.0/20 AS22527 -Reserved AS-,ZZ 167.146.44.0/24 AS22527 -Reserved AS-,ZZ 167.146.48.0/22 AS22527 -Reserved AS-,ZZ 167.146.90.0/24 AS22527 -Reserved AS-,ZZ 167.146.93.0/24 AS22527 -Reserved AS-,ZZ 167.146.94.0/24 AS22527 -Reserved AS-,ZZ 167.146.100.0/24 AS22527 -Reserved AS-,ZZ 167.146.104.0/24 AS22527 -Reserved AS-,ZZ 167.146.105.0/24 AS22527 -Reserved AS-,ZZ 167.146.128.0/20 AS22527 -Reserved AS-,ZZ 167.146.137.0/24 AS22527 -Reserved AS-,ZZ 167.146.144.0/20 AS22527 -Reserved AS-,ZZ 167.146.160.0/20 AS22527 -Reserved AS-,ZZ 167.146.200.0/22 AS22527 -Reserved AS-,ZZ 167.146.204.0/24 AS22527 -Reserved AS-,ZZ 167.146.205.0/24 AS22527 -Reserved AS-,ZZ 172.102.0.0/22 AS4812 CHINANET-SH-AP China Telecom (Group),CN 173.45.192.0/20 AS62722 -Reserved AS-,ZZ 173.45.208.0/20 AS62722 -Reserved AS-,ZZ 185.17.98.0/23 AS19798 HILF-AS Hilf Telecom B.V.,NL 185.98.192.0/22 AS30880 SPACEDUMP-AS SpaceDump IT AB,SE 192.9.0.0/16 AS11479 BRM-SUN-AS - Sun Microsystems, Inc,US 192.25.10.0/24 AS5714 HPES - Hewlett-Packard Company,US 192.25.11.0/24 AS5714 HPES - Hewlett-Packard Company,US 192.25.13.0/24 AS5714 HPES - Hewlett-Packard Company,US 192.25.14.0/24 AS5714 HPES - Hewlett-Packard Company,US 192.34.96.0/21 AS54632 -Reserved AS-,ZZ 192.34.152.0/21 AS10835 VISIONARY - Visionary Communications, Inc.,US 192.75.23.0/24 AS2579 AS2579 - Alcatel-Lucent,FR 192.75.239.0/24 AS23498 CDSI - COGECODATA,CA 192.84.24.0/24 AS4323 TWTC - tw telecom holdings, inc.,US 192.101.70.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 192.101.71.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 192.101.72.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 192.124.252.0/22 AS680 DFN Verein zur Foerderung eines Deutschen Forschungsnetzes e.V.,DE 192.131.233.0/24 AS7018 ATT-INTERNET4 - AT&T Services, Inc.,US 192.149.81.0/24 AS14454 PERIMETER-ESECURITY - Perimeter eSecurity,US 192.154.32.0/19 AS81 NCREN - MCNC,US 192.154.64.0/19 AS81 NCREN - MCNC,US 192.166.32.0/20 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 192.188.208.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 192.228.94.0/23 AS27446 ERCWC-ASN - ERC Broadband,US 192.245.195.0/24 AS7381 SUNGARDRS - SunGard Availability Services LP,US 193.9.59.0/24 AS1257 TELE2,SE 193.16.106.0/24 AS31539 -Reserved AS-,ZZ 193.16.145.0/24 AS31392 -Reserved AS-,ZZ 193.22.86.0/24 AS24751 MULTIFI-AS Jakobstadsnejdens Telefon Ab,FI 193.26.213.0/24 AS31641 BYTEL-AS Bytel Ltd,GB 193.28.14.0/24 AS34309 LINK11 Link11 GmbH,DE 193.32.23.0/24 AS2856 BT-UK-AS BT Public Internet Service,GB 193.33.6.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.33.252.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.35.101.0/24 AS57302 -Reserved AS-,ZZ 193.46.200.0/24 AS34243 WEBAGE Web Age Ltd,GB 193.111.229.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.149.2.0/23 AS15919 INTERHOST Servicios de Hosting en Internet S.A.,ES 193.164.152.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.176.147.0/24 AS49951 -Reserved AS-,ZZ 193.178.196.0/22 AS15657 SPEEDBONE-AS Speedbone Internet & Connectivity GmbH,DE 193.188.252.0/24 AS38968 TAGORG Abu-Ghazaleh Intellectual Property,JO 193.200.96.0/23 AS2828 XO-AS15 - XO Communications,US 193.200.244.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.201.244.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 193.201.245.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 193.201.246.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 193.202.9.0/24 AS6824 HERMES-NETWORK Hermes Telecom International Ltd,GB 193.223.103.0/24 AS8437 UTA-AS Tele2 Telecommunication GmbH,AT 193.227.109.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.227.236.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 194.6.252.0/24 AS21202 DCSNET-AS Bredband2 AB,SE 194.9.8.0/23 AS2863 SPRITELINK Centor AB,SE 194.9.8.0/24 AS2863 SPRITELINK Centor AB,SE 194.39.78.0/23 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 194.49.17.0/24 AS13135 CREW-AS Wieske's Crew GmbH,DE 194.50.8.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 194.60.88.0/21 AS5089 NTL Virgin Media Limited,GB 194.61.147.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 194.61.150.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 194.61.151.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 194.63.152.0/22 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 194.76.224.0/24 AS34701 WITZENMANN-AS Witzenmann GmbH, Pforzheim,DE 194.76.225.0/24 AS34701 WITZENMANN-AS Witzenmann GmbH, Pforzheim,DE 194.88.6.0/24 AS35093 RO-HTPASSPORT High Tech Passport Ltd SUA California San Jose SUCURSALA BUCURESTI ROMANIA,RO 194.88.226.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 194.99.67.0/24 AS9083 CARPENET carpeNet Information Technologies GmbH,DE 194.114.136.0/22 AS33866 -Reserved AS-,ZZ 194.126.152.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 194.126.219.0/24 AS34545 -Reserved AS-,ZZ 194.126.233.0/24 AS31235 SKIWEBCENTER-AS SKIWEBCENTER SARL,FR 194.180.25.0/24 AS21358 ATOS-ORIGIN-DE-AS Atos Information Technology GmbH,DE 194.187.24.0/22 AS8856 UKRNET UkrNet Ltd,UA 195.8.48.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.8.48.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.42.232.0/22 AS15657 SPEEDBONE-AS Speedbone Internet & Connectivity GmbH,DE 195.85.194.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.85.201.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.110.0.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.128.240.0/23 AS21202 DCSNET-AS Bredband2 AB,SE 195.149.119.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.189.174.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.216.234.0/24 AS31309 NMV-AS New Media Ventures BVBA,BE 195.234.156.0/24 AS25028 -Reserved AS-,ZZ 195.242.182.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.244.18.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 196.3.182.0/24 AS37004 -Reserved AS-,ZZ 196.3.183.0/24 AS37004 -Reserved AS-,ZZ 196.22.8.0/24 AS27822 Emerging Markets Communications de Argentina S.R.L,AR 196.22.11.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US 198.22.195.0/24 AS54583 -Reserved AS-,ZZ 198.23.26.0/24 AS33052 VZUNET - Verizon Data Services LLC,US 198.73.226.0/23 AS62839 -Reserved AS-,ZZ 198.74.11.0/24 AS14573 KEYSPANENERGY-NE1 - Keyspan Energy,US 198.74.13.0/24 AS14573 KEYSPANENERGY-NE1 - Keyspan Energy,US 198.74.38.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services,US 198.74.39.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services,US 198.74.40.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services,US 198.97.72.0/21 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 198.97.96.0/19 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 198.97.240.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 198.163.214.0/24 AS21804 ACCESS-SK - Access Communications Co-operative Limited,CA 198.168.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 199.30.132.0/22 AS26003 -Reserved AS-,ZZ 199.38.248.0/24 AS13951 CENTER-SEVEN - C7 Data Centers, Inc.,US 199.38.249.0/24 AS13951 CENTER-SEVEN - C7 Data Centers, Inc.,US 199.38.250.0/24 AS13951 CENTER-SEVEN - C7 Data Centers, Inc.,US 199.38.251.0/24 AS13951 CENTER-SEVEN - C7 Data Centers, Inc.,US 199.38.252.0/22 AS13951 CENTER-SEVEN - C7 Data Centers, Inc.,US 199.66.15.0/24 AS30169 -Reserved AS-,ZZ 199.85.9.0/24 AS852 ASN852 - TELUS Communications Inc.,CA 199.88.52.0/22 AS17018 QTS-SACRAMENTO-1 - Quality Investment Properties Sacramento, LLC,US 199.102.240.0/24 AS18508 -Reserved AS-,ZZ 199.116.200.0/21 AS22830 -Reserved AS-,ZZ 199.121.0.0/16 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 199.123.16.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 199.233.87.0/24 AS33058 PEGASYSTEMS - Pegasystems Inc.,US 200.1.112.0/24 AS29754 GO2TEL - GO2TEL.COM INC.,US 200.6.87.0/24 AS27947 Telconet S.A,EC 200.58.248.0/21 AS27849 200.81.48.0/24 AS11664 Techtel LMDS Comunicaciones Interactivas S.A.,AR 200.81.49.0/24 AS11664 Techtel LMDS Comunicaciones Interactivas S.A.,AR 202.3.75.0/24 AS18172 202.3.76.0/24 AS18172 202.8.106.0/24 AS9530 SHINSEGAE-AS SHINSEGAE I&C Co., Ltd.,KR 202.45.10.0/23 AS24327 202.45.10.0/24 AS24327 202.45.11.0/24 AS24327 202.53.138.0/24 AS4058 CITICTEL-CPC-AS4058 CITIC Telecom International CPC Limited,HK 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network,CN 202.122.134.0/24 AS38615 202.140.147.0/24 AS9583 SIFY-AS-IN Sify Limited,IN 202.158.251.0/24 AS9255 CONNECTPLUS-AS Singapore Telecom,SG 202.165.124.0/24 AS23749 GLOBAL-TRANSIT-AS-HKCOLO-AP HKCOLO ltd. Internet Service Provider,HK 202.179.134.0/24 AS23966 LDN-AS-PK LINKdotNET Telecom Limited,PK 203.142.219.0/24 AS45149 203.175.11.0/24 AS9229 SPEEDCAST-AP SPEEDCAST Limited,HK 203.189.116.0/22 AS45606 203.189.116.0/24 AS45606 203.189.117.0/24 AS45606 203.189.118.0/24 AS45606 203.189.119.0/24 AS45606 204.10.88.0/21 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 204.15.208.0/22 AS13706 COMPLETEWEBNET - CompleteWeb.Net LLC,US 204.16.96.0/24 AS19972 -Reserved AS-,ZZ 204.16.97.0/24 AS19972 -Reserved AS-,ZZ 204.16.98.0/24 AS19972 -Reserved AS-,ZZ 204.16.99.0/24 AS19972 -Reserved AS-,ZZ 204.69.139.0/24 AS40250 -Reserved AS-,ZZ 204.69.144.0/24 AS27283 RJF-INTERNET - Raymond James Financial, Inc.,US 204.86.196.0/23 AS14372 -Reserved AS-,ZZ 204.86.198.0/23 AS33058 PEGASYSTEMS - Pegasystems Inc.,US 204.87.251.0/24 AS22217 -Reserved AS-,ZZ 204.106.16.0/24 AS4323 TWTC - tw telecom holdings, inc.,US 204.187.11.0/24 AS51113 ELEKTA-AS Elekta,GB 204.235.245.0/24 AS22613 -Reserved AS-,ZZ 205.137.240.0/20 AS11686 ENA - Education Networks of America,US 205.159.44.0/24 AS40157 ADESA-CORP-AS - ADESA Corp,US 205.166.231.0/24 AS7029 WINDSTREAM - Windstream Communications Inc,US 205.211.160.0/24 AS30045 UHN-ASN - University Health Network,CA 206.197.184.0/24 AS23304 DATOTEL-STL-AS - Datotel LLC, a NetLabs LLC Company,US 207.2.120.0/21 AS6221 USCYBERSITES - US Cybersites, Inc,US 207.174.131.0/24 AS26116 INDRA - Indra's Net Inc,US 207.174.132.0/23 AS26116 INDRA - Indra's Net Inc,US 207.174.152.0/23 AS26116 INDRA - Indra's Net Inc,US 207.174.154.0/24 AS26116 INDRA - Indra's Net Inc,US 207.174.155.0/24 AS26116 INDRA - Indra's Net Inc,US 207.174.200.0/24 AS22658 EARTHNET - Earthnet, Inc.,US 207.231.96.0/19 AS11194 NUNETPA - NuNet Inc.,US 207.254.128.0/21 AS30689 FLOW-NET - FLOW,JM 207.254.136.0/21 AS30689 FLOW-NET - FLOW,JM 208.66.64.0/24 AS16936 -Reserved AS-,ZZ 208.66.65.0/24 AS16936 -Reserved AS-,ZZ 208.66.66.0/24 AS16936 -Reserved AS-,ZZ 208.66.67.0/24 AS16936 -Reserved AS-,ZZ 208.67.132.0/22 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 208.73.40.0/22 AS19901 -Reserved AS-,ZZ 208.73.41.0/24 AS19901 -Reserved AS-,ZZ 208.75.152.0/21 AS32146 -Reserved AS-,ZZ 208.76.20.0/24 AS31812 -Reserved AS-,ZZ 208.76.21.0/24 AS31812 -Reserved AS-,ZZ 208.77.164.0/24 AS22659 -Reserved AS-,ZZ 208.77.166.0/24 AS4323 TWTC - tw telecom holdings, inc.,US 208.83.53.0/24 AS40569 YGOMI-AS - Ygomi LLC,US 208.84.232.0/24 AS33131 -Reserved AS-,ZZ 208.84.233.0/24 AS33131 -Reserved AS-,ZZ 208.84.234.0/24 AS33131 -Reserved AS-,ZZ 208.84.237.0/24 AS33131 -Reserved AS-,ZZ 208.93.216.0/22 AS209 CENTURYLINK-US-LEGACY-QWEST - Qwest Communications Company, LLC,US 208.94.216.0/23 AS13629 -Reserved AS-,ZZ 208.94.219.0/24 AS13629 -Reserved AS-,ZZ 208.94.221.0/24 AS13629 -Reserved AS-,ZZ 208.94.223.0/24 AS13629 -Reserved AS-,ZZ 209.135.171.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 209.135.175.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 209.177.64.0/20 AS6461 ABOVENET - Abovenet Communications, Inc,US 209.193.112.0/20 AS209 CENTURYLINK-US-LEGACY-QWEST - Qwest Communications Company, LLC,US 209.209.51.0/24 AS18687 MPOWER-2 - MPOWER COMMUNICATIONS CORP.,US 209.234.112.0/23 AS32252 -Reserved AS-,ZZ 209.234.114.0/23 AS32252 -Reserved AS-,ZZ 209.234.116.0/24 AS32252 -Reserved AS-,ZZ 209.234.117.0/24 AS32252 -Reserved AS-,ZZ 209.234.118.0/24 AS32252 -Reserved AS-,ZZ 209.234.119.0/24 AS32252 -Reserved AS-,ZZ 209.234.120.0/24 AS32252 -Reserved AS-,ZZ 209.234.121.0/24 AS32252 -Reserved AS-,ZZ 209.234.122.0/24 AS32252 -Reserved AS-,ZZ 213.255.128.0/20 AS24863 LINKdotNET-AS,EG 213.255.144.0/20 AS24863 LINKdotNET-AS,EG 216.73.81.0/24 AS6432 DOUBLECLICK - Double Click, Inc.,US 216.73.82.0/24 AS6432 DOUBLECLICK - Double Click, Inc.,US 216.73.85.0/24 AS6432 DOUBLECLICK - Double Click, Inc.,US 216.73.88.0/24 AS6432 DOUBLECLICK - Double Click, Inc.,US 216.73.89.0/24 AS6432 DOUBLECLICK - Double Click, Inc.,US 216.73.94.0/24 AS6432 DOUBLECLICK - Double Click, Inc.,US 216.73.95.0/24 AS6432 DOUBLECLICK - Double Click, Inc.,US 216.146.0.0/19 AS11915 US-TELEPACIFIC - TelePacific Communications,US 216.152.24.0/22 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc.,US 216.170.96.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc.,US 216.170.101.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc.,US 216.170.104.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc.,US 216.170.105.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc.,US 216.234.132.0/24 AS14545 ADR-DRIVING-RECORDS - AMERICAN DRIVING RECORDS, INC.,US 216.238.192.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 216.238.193.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 216.238.194.0/24 AS26566 -Reserved AS-,ZZ 216.238.196.0/22 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 216.251.50.0/24 AS38191 INFOSYS-AS Infosys Technologies Ltd,IN 216.251.53.0/24 AS38191 INFOSYS-AS Infosys Technologies Ltd,IN 216.251.62.0/24 AS38191 INFOSYS-AS Infosys Technologies Ltd,IN 216.252.208.0/22 AS7057 MANAGEDNETWORK - Managed Network Systems Inc.,CA Please see http://www.cidr-report.org for the full report ------------------------------------ Copies of this report are mailed to: nanog at nanog.org 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 22:00:03 2015 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 1 May 2015 22:00:03 GMT Subject: BGP Update Report Message-ID: <201505012200.t41M0340046475@wattle.apnic.net> BGP Update Report Interval: 23-Apr-15 -to- 30-Apr-15 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS15296 298218 5.0% 10650.6 -- CYBERA - Cybera Inc,CA 2 - AS23752 267528 4.5% 2286.6 -- NPTELECOM-NP-AS Nepal Telecommunications Corporation, Internet Services,NP 3 - AS9829 267188 4.5% 146.7 -- BSNL-NIB National Internet Backbone,IN 4 - AS29520 102942 1.7% 3431.4 -- ROSINTEL-AS Locked Joint Stock Company OGANER-SERVICE,RU 5 - AS7713 97306 1.6% 4633.6 -- TELKOMNET-AS-AP PT Telekomunikasi Indonesia,ID 6 - AS22059 96800 1.6% 16133.3 -- APVIO-1 - Apvio, Inc.,US 7 - AS45899 84083 1.4% 118.6 -- VNPT-AS-VN VNPT Corp,VN 8 - AS36947 84044 1.4% 1334.0 -- ALGTEL-AS,DZ 9 - AS26615 74789 1.3% 64.6 -- Tim Celular S.A.,BR 10 - AS3709 69923 1.2% 2589.7 -- NET-CITY-SA - City of San Antonio,US 11 - AS9583 63495 1.1% 43.3 -- SIFY-AS-IN Sify Limited,IN 12 - AS28024 53276 0.9% 34.9 -- Nuevatel PCS de Bolivia S.A.,BO 13 - AS13188 53154 0.9% 67.0 -- BANKINFORM-AS CONTENT DELIVERY NETWORK LTD,UA 14 - AS26821 49821 0.8% 6227.6 -- REVNET - Revelation Networks, Inc.,US 15 - AS4538 48193 0.8% 8.7 -- ERX-CERNET-BKB China Education and Research Network Center,CN 16 - AS18566 35188 0.6% 32.7 -- MEGAPATH5-US - MegaPath Corporation,US 17 - AS38197 34646 0.6% 28.9 -- SUNHK-DATA-AS-AP Sun Network (Hong Kong) Limited,HK 18 - AS7602 33811 0.6% 238.1 -- SPT-AS-VN Saigon Postel Corporation,VN 19 - AS8402 31129 0.5% 53.3 -- CORBINA-AS OJSC "Vimpelcom",RU 20 - AS42337 29492 0.5% 164.8 -- RESPINA-AS Respina Networks & Beyond PJSC,IR TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS22059 96800 1.6% 16133.3 -- APVIO-1 - Apvio, Inc.,US 2 - AS47680 12509 0.2% 12509.0 -- NHCS EOBO Limited,IE 3 - AS15296 298218 5.0% 10650.6 -- CYBERA - Cybera Inc,CA 4 - AS393588 9590 0.2% 9590.0 -- MUBEA-FLO - Mubea,US 5 - AS46336 8662 0.1% 8662.0 -- GOODVILLE - Goodville Mutual Casualty Company,US 6 - AS25563 27355 0.5% 6838.8 -- WEBLAND-AS Webland AG, Autonomous System,CH 7 - AS26821 49821 0.8% 6227.6 -- REVNET - Revelation Networks, Inc.,US 8 - AS52233 19415 0.3% 4853.8 -- Columbus Communications Curacao NV,CW 9 - AS7713 97306 1.6% 4633.6 -- TELKOMNET-AS-AP PT Telekomunikasi Indonesia,ID 10 - AS13483 12265 0.2% 4088.3 -- INFOR-AS13483 - INFOR GLOBAL SOLUTIONS (MICHIGAN), INC.,US 11 - AS197914 4054 0.1% 4054.0 -- STOCKHO-AS Stockho Hosting SARL,FR 12 - AS1757 3517 0.1% 3517.0 -- LEXIS-AS - LexisNexis,US 13 - AS29520 102942 1.7% 3431.4 -- ROSINTEL-AS Locked Joint Stock Company OGANER-SERVICE,RU 14 - AS45726 10783 0.2% 2695.8 -- LIONAIR-AS-ID Lion Mentari Airlines, PT,ID 15 - AS3709 69923 1.2% 2589.7 -- NET-CITY-SA - City of San Antonio,US 16 - AS58904 4595 0.1% 2297.5 -- KOONK-AS-IN KOONK TECHNOLOGIES PRIVATE LIMITED,IN 17 - AS23752 267528 4.5% 2286.6 -- NPTELECOM-NP-AS Nepal Telecommunications Corporation, Internet Services,NP 18 - AS52925 8827 0.1% 2206.8 -- Ascenty DataCenters Locacao e Servicos LTDA,BR 19 - AS202195 1886 0.0% 1886.0 -- ASTEKOSTMN West Siberian Regional Center of Telecommunications Tekos-Tyumen Ltd.,RU 20 - AS57120 1878 0.0% 1878.0 -- TMK-AS JSC "TMK",RU TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 202.70.64.0/21 133695 2.2% AS23752 -- NPTELECOM-NP-AS Nepal Telecommunications Corporation, Internet Services,NP 2 - 202.70.88.0/21 133138 2.2% AS23752 -- NPTELECOM-NP-AS Nepal Telecommunications Corporation, Internet Services,NP 3 - 118.98.88.0/24 97523 1.6% AS64567 -- -Private Use AS-,ZZ AS7713 -- TELKOMNET-AS-AP PT Telekomunikasi Indonesia,ID 4 - 105.96.0.0/22 82851 1.3% AS36947 -- ALGTEL-AS,DZ 5 - 64.34.125.0/24 48453 0.8% AS22059 -- APVIO-1 - Apvio, Inc.,US 6 - 76.191.107.0/24 48333 0.8% AS22059 -- APVIO-1 - Apvio, Inc.,US 7 - 95.138.224.0/20 33905 0.6% AS29520 -- ROSINTEL-AS Locked Joint Stock Company OGANER-SERVICE,RU 8 - 95.138.240.0/20 33785 0.6% AS29520 -- ROSINTEL-AS Locked Joint Stock Company OGANER-SERVICE,RU 9 - 95.138.234.0/24 33721 0.6% AS29520 -- ROSINTEL-AS Locked Joint Stock Company OGANER-SERVICE,RU 10 - 109.87.158.0/24 22157 0.4% AS13188 -- BANKINFORM-AS CONTENT DELIVERY NETWORK LTD,UA 11 - 109.87.159.0/24 21969 0.4% AS13188 -- BANKINFORM-AS CONTENT DELIVERY NETWORK LTD,UA 12 - 88.87.160.0/19 12509 0.2% AS47680 -- NHCS EOBO Limited,IE 13 - 199.216.158.0/24 11785 0.2% AS15296 -- CYBERA - Cybera Inc,CA 14 - 199.216.200.0/22 11768 0.2% AS15296 -- CYBERA - Cybera Inc,CA 15 - 199.216.188.0/24 11763 0.2% AS15296 -- CYBERA - Cybera Inc,CA 16 - 199.216.126.0/24 11756 0.2% AS15296 -- CYBERA - Cybera Inc,CA 17 - 204.209.93.0/24 11751 0.2% AS15296 -- CYBERA - Cybera Inc,CA 18 - 199.216.62.0/23 11740 0.2% AS15296 -- CYBERA - Cybera Inc,CA 19 - 199.216.196.0/23 11731 0.2% AS15296 -- CYBERA - Cybera Inc,CA 20 - 204.209.91.0/24 11723 0.2% AS15296 -- CYBERA - Cybera Inc,CA Details at http://bgpupdates.potaroo.net ------------------------------------ Copies of this report are mailed to: nanog at nanog.org eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From Jac.Kloots at surfnet.nl Fri May 1 22:41:47 2015 From: Jac.Kloots at surfnet.nl (Jac Kloots) Date: Fri, 1 May 2015 18:41:47 -0400 (EDT) Subject: Trusted Networks Initiative: DDoS fallback set of AS'es In-Reply-To: References: <78C35D6C1A82D243B830523B4193CF5F9F3651C3E0@SBS1.blinker.local> <18012.1429214983@turing-police.cc.vt.edu> <20150416201356.GN67158@Vurt.local> <19328.1429216247@turing-police.cc.vt.edu> <55301E9B.4010601@bogus.com> <55380E9B.7080908@ripe.net> Message-ID: Randy, On Thu, 30 Apr 2015, Randy Bush wrote: >>>> in any case the idea still seems silly. >>> not if you need to appear to be DOING SOMETHING!!! >> Of course there is that. But in order to be appear to be doing something >> one has to pledge to do BCP38 and various other things I would consider >> BCP. All little bits help. > > except the big logo marketing has the implication that all the rest of > us unwashed networks are untrustable. this is not the cooperative > internet. You can apply to become a member in the initiative. Jac -- Jac Kloots Network Services SURFnet bv From jfmezei_nanog at vaxination.ca Sat May 2 05:47:32 2015 From: jfmezei_nanog at vaxination.ca (Jean-Francois Mezei) Date: Sat, 02 May 2015 01:47:32 -0400 Subject: ADSL Line Extenders In-Reply-To: <5542E7C0.2070500@spitwspots.com> References: <553FFA97.8030405@vaxination.ca> <5542E7C0.2070500@spitwspots.com> Message-ID: <554464F4.1090504@vaxination.ca> I want to thnk those who answered in this thread. It has provided me with some insight. There is an upcoming review in Canada of the "basic service objectives" with questions on how best to deply in rural areas. (My own opinion is that in 2015, if you're going to deploy something, it might as well be FTTH) but gives me enough info to ask questions about DSL extenders and of the incumbents would/could of have considered using those. > From josh at spitwspots.com Sat May 2 07:30:21 2015 From: josh at spitwspots.com (Josh Reynolds) Date: Fri, 01 May 2015 23:30:21 -0800 Subject: ADSL Line Extenders In-Reply-To: <554464F4.1090504@vaxination.ca> References: <553FFA97.8030405@vaxination.ca> <5542E7C0.2070500@spitwspots.com> <554464F4.1090504@vaxination.ca> Message-ID: <6D47A67A-E2B2-49D1-A98C-D5885E3B1E6F@spitwspots.com> Can't run fiber everywhere. (I am the CIO of a W/ISP in Alaska) On May 1, 2015 9:47:32 PM AKDT, Jean-Francois Mezei wrote: >I want to thnk those who answered in this thread. It has provided me >with some insight. > >There is an upcoming review in Canada of the "basic service objectives" >with questions on how best to deply in rural areas. (My own opinion is >that in 2015, if you're going to deploy something, it might as well be >FTTH) but gives me enough info to ask questions about DSL extenders and >of the incumbents would/could of have considered using those. > > >> -- Sent from my Android device with K-9 Mail. Please excuse my brevity. From hannigan at gmail.com Sat May 2 20:37:04 2015 From: hannigan at gmail.com (Martin Hannigan) Date: Sat, 2 May 2015 16:37:04 -0400 Subject: Looking for a provider in Ecuador In-Reply-To: References: Message-ID: Eric, These look like the top three to me: AS 14420 CNT AS 14552 Satnet Ecuador AS 19169 Telconet SA My favorite search engine says that CNT is the incumbent. Best, -M< On Mon, Apr 27, 2015 at 8:15 PM, Eric C. Miller wrote: > Hello, > > Does anyone have a recommendation for a provider who can service the west > coast of Ecuador at speeds 100Mbps - 1Gbps? > > Thanks! > > > > Eric Miller, CCNP > Network Engineering Consultant > (407) 257-5115 > > > > From rudi.daniel at gmail.com Mon May 4 00:16:10 2015 From: rudi.daniel at gmail.com (Rudolph Daniel) Date: Sun, 3 May 2015 20:16:10 -0400 Subject: Gov.vc...alert!! Message-ID: Hi Guys Take a look at gov.vc please. Idil hack. RD From s+Mailinglisten.nanog at sloc.de Mon May 4 10:50:09 2015 From: s+Mailinglisten.nanog at sloc.de (Sebastian Spies) Date: Mon, 04 May 2015 12:50:09 +0200 Subject: yarr - Yet Another Route Server Implementation [WAS: Euro-IX quagga stable download and implementation] In-Reply-To: <002201d07f93$478fc970$d6af5c50$@rs> References: <7b5c414d74bd558bbb473086d422c099@sox.rs> <13A7BFA0-E258-4A85-9879-95E0CD3FD786@nosignal.org> <002101d07f8c$67f67b20$37e37160$@rs> <54BC7947-5766-447F-B1A2-7BB137411F98@nosignal.org> <002201d07f93$478fc970$d6af5c50$@rs> Message-ID: <55474EE1.2090402@sloc.de> Hey there, considering the state of this discussion, BIRD seems to be the only scalable solution to be used as a route server at IXPs. I have built a large code base around BGP for the hoofprints project [1] and BRITE [2] and would enjoy building another state-of-the-art open-source route-server implementation for IXPs. Would you be so kind to send me your feedback on this idea? Do you think, it makes sense to pursue such a project or is it not relevant enough for you? Best regards, Sebastian 1: https://github.com/sspies8684/hoofprints/ 2: https://brite.antd.nist.gov/statics/about Am 25.04.2015 um 22:06 schrieb Goran Slavi?: > Andy, > > Believe me when I say: I would never have the idea to think about > attempting to try to test my ability to generate configurations for this "2 > route servers/ 2 different programs that run them" solution without the IXP > Manager :-) > > I am familiar with the work INEX has been doing with IXP Manager and > have for some time attempted to find time from regular SOX operation to > implement it in our IX. This migration gives me the excellent opportunity > and arguments to finally allocate time, resources and manpower for > installation and implementation of IXP Manager as the route server > configuration generator at SOX. > > Regards > G.Slavic > > > -----Original Message----- > From: Andy Davidson [mailto:andy at nosignal.org] > Sent: Saturday, 25 April 2015 21:34 > To: Goran Slavi? > Cc: nanog at nanog.org > Subject: Re: Euro-IX quagga stable download and implementation > > > On 25 Apr 2015, at 15:16, Goran Slavi? wrote: > >> Considering what I have learned in your posts (and on other places >> that I have informed myself) I will definitely suggest to SOX management > to >> go the way similar to what LINX did (1 Bird + 1 Quagga as route servers) > for >> the simple reason that 2 different solution provides more security in >> context of "new program update->new bugs" problems and incidents and >> prevents other potential problems. > Goran - glad to have helped. > > One last piece of advice which might be useful - to help to guarantee > consistency of performance between the two route-servers, you should > consider a configuration generator so that your route-server configs are in > sync. The best way to implement this at your exchange is to use IXP > Manager, maintained by the awesome folks at the Irish exchange point, INEX. > https://github.com/inex/IXP-Manager > > IXP Manager will get you lots of other features as well as good route-server > hygiene. > > There's also a historic perl-script that does this on my personal github. > Both of these solutions allow you to filter route-server participants based > on IRR data, which has proved to be a life-saver at all of the exchanges I > help to operate. Having my horrible historic thing is maybe better than no > thing at all, but I deliberately won't link to it as you should really use > IXP Manager. :-) > > Andy= > > From s+Mailinglisten.nanog at sloc.de Mon May 4 14:05:37 2015 From: s+Mailinglisten.nanog at sloc.de (Sebastian Spies) Date: Mon, 04 May 2015 16:05:37 +0200 Subject: yarr - Yet Another Route Server Implementation [WAS: Euro-IX quagga stable download and implementation] In-Reply-To: <002201d07f93$478fc970$d6af5c50$@rs> References: <7b5c414d74bd558bbb473086d422c099@sox.rs> <13A7BFA0-E258-4A85-9879-95E0CD3FD786@nosignal.org> <002101d07f8c$67f67b20$37e37160$@rs> <54BC7947-5766-447F-B1A2-7BB137411F98@nosignal.org> <002201d07f93$478fc970$d6af5c50$@rs> Message-ID: <55477CB1.4060201@sloc.de> sorry, for the double post. dmarc fuckup... Hey there, considering the state of this discussion, BIRD seems to be the only scalable solution to be used as a route server at IXPs. I have built a large code base around BGP for the hoofprints project [1] and BRITE [2] and would enjoy building another state-of-the-art open-source route-server implementation for IXPs. Would you be so kind to send me your feedback on this idea? Do you think, it makes sense to pursue such a project or is it not relevant enough for you? Best regards, Sebastian 1: https://github.com/sspies8684/hoofprints/ 2: https://brite.antd.nist.gov/statics/about Am 25.04.2015 um 22:06 schrieb Goran Slavi?: > Andy, > > Believe me when I say: I would never have the idea to think about > attempting to try to test my ability to generate configurations for this "2 > route servers/ 2 different programs that run them" solution without the IXP > Manager :-) > > I am familiar with the work INEX has been doing with IXP Manager and > have for some time attempted to find time from regular SOX operation to > implement it in our IX. This migration gives me the excellent opportunity > and arguments to finally allocate time, resources and manpower for > installation and implementation of IXP Manager as the route server > configuration generator at SOX. > > Regards > G.Slavic > > > -----Original Message----- > From: Andy Davidson [mailto:andy at nosignal.org] > Sent: Saturday, 25 April 2015 21:34 > To: Goran Slavi? > Cc: nanog at nanog.org > Subject: Re: Euro-IX quagga stable download and implementation > > > On 25 Apr 2015, at 15:16, Goran Slavi? wrote: > >> Considering what I have learned in your posts (and on other places >> that I have informed myself) I will definitely suggest to SOX management > to >> go the way similar to what LINX did (1 Bird + 1 Quagga as route servers) > for >> the simple reason that 2 different solution provides more security in >> context of "new program update->new bugs" problems and incidents and >> prevents other potential problems. > Goran - glad to have helped. > > One last piece of advice which might be useful - to help to guarantee > consistency of performance between the two route-servers, you should > consider a configuration generator so that your route-server configs are in > sync. The best way to implement this at your exchange is to use IXP > Manager, maintained by the awesome folks at the Irish exchange point, INEX. > https://github.com/inex/IXP-Manager > > IXP Manager will get you lots of other features as well as good route-server > hygiene. > > There's also a historic perl-script that does this on my personal github. > Both of these solutions allow you to filter route-server participants based > on IRR data, which has proved to be a life-saver at all of the exchanges I > help to operate. Having my horrible historic thing is maybe better than no > thing at all, but I deliberately won't link to it as you should really use > IXP Manager. :-) > > Andy= > > From rdrake at direcpath.com Mon May 4 20:16:11 2015 From: rdrake at direcpath.com (rdrake) Date: Mon, 4 May 2015 16:16:11 -0400 Subject: symmetric vs. asymmetric [was: Verizon Policy Statement on Net Neutrality] In-Reply-To: References: <17150973.878.1425142741140.JavaMail.mhammett@ThunderFuck> <54F1F97A.2030000@mtcc.com> <00a601d053a4$2445a3b0$6cd0eb10$@gwsystems.co.il> <20150228224632.CB39B2A930D4@rock.dv.isc.org> <54F48F98.9060906@pari.edu> <6D91D962-9FE6-41CC-AC36-8446E435A3FC@delong.com> <54F4F500.8090303@pari.edu> <0EBB3295-1C3C-44C9-9F15-8235372AA57F@delong.com> <000101d05567$74b58530$5e208f90$@gmail.com> <20150303051439.B14E72ABEB33@rock.dv.isc.org> <54F57656.2010804@satchell.net> <20150303122840.428C22AC5068@rock.dv.isc.org> Message-ID: <5547D38B.1020300@direcpath.com> On 03/03/2015 08:07 AM, Scott Helms wrote: > I'm not done collecting all of our data yet, but just looking at what we > have right now (~17,000 APs) over half of the clients connected have an > upload rate of 5mbps or less. A just over 20% have an average upload rate > of 1mbps. > > BTW, the reason we're working on the WiFi data is that we think this is a > huge problem, because consumers don't separate the performance of the in > home WiFi from their overall broadband experience and we need to > dramatically improve the in home WiFi experience to increase customer > satisfaction. "The Cloud" solved most peoples issues with NAT. Rather than having IPv6 to a fileserver at my house, I've got the option of IPv4 to dropbox "anywhere". Most people store all their data on remote servers now. That means unless they're uploading a new picture to facebook or a new video to youtube, 90% of their at home usage of their wireless will be downloads (looking at existing content). Given that some people are getting Active Ethernet to the home, with IPv6, we might see an eventual new killer app that changes the way bandwidth is used, but I think right now the reason we're not seeing a killer app is because of two things: 1. Users don't have the bandwidth. Most people really are on constrained pipes that can't tolerate heavy uploads 2. NAT still breaks things for everyone so people can't do it. From nanog1 at roadrunner.com Tue May 5 02:55:43 2015 From: nanog1 at roadrunner.com (nanog1 at roadrunner.com) Date: Mon, 4 May 2015 19:55:43 -0700 Subject: Network Segmentation Approaches Message-ID: <20150505025540.GA19516@bludgeon.org> Possibly a bit off-topic, but curious how all of you out there segment your networks. Corporate/business users, dependent services, etc. from critical data and/or processes with remote locations thrown in the mix which could be mini-versions of your primary network. There's quite a bit of literature out there on this, so have been considering an approach with zones based on the types of data or processes within them. General thoughts: - "Business Zone" - This would be where workstations live, web browsing occurs, VoIP and authentication services live too. Probably consider this a somewhat "dirty" zone, but I should generally be OK letting anything in this zone talk fairly unfettered to anything else in this zone (for example a business network at my HQ location should be able to talk unfettered to an equivalent network at a remote site). I'd probably have VoIP media servers in this zone, AD, DNS, etc. - Some sort of management zone(z) - Maybe accessible only via jump host -- this zone gives "control" access into key resources (most likely IT resouces like network devices, storage devices, etc.). Should have sound logging/auditing here to establish access patterns outsid the norm and perhaps multi-factor authentication (and of course FW's). - Secure Zone(s) - Important data sets or services can be isolated from untrusted zones here. May need separate services (DNS, AD, etc.) - I should think carefully about where I stick stateful FW's -- especially on my internal networks. Risk of DoS'ing myself is high. Presumably I should never allow *outbound* connectivity from a more secure zone to a less secure zone, and inbound connectivity should be carefully monitored for unusual access patterns. Perhaps some of you have some fairly simple rules of thumb that could be built off of? I'm especially interested to hear how VoIP/RTP traffic is handled between subnets/remote sites within a "Business Zone". I'm loathe to put a FW between these segments as it will put VoIP performance at risk (maybe QoS on FW's can be pretty good), but maybe some sort of passive monitoring would make sense. (Yes, I've also read the famous thread on stateful firewalls[1]). Thanks! [1] http://markmail.org/thread/fvordsbnuc74fuu2#query:+page:1+mid:fvordsbnuc74fuu2+state:results From mwinter at noaccess.com Tue May 5 08:12:26 2015 From: mwinter at noaccess.com (Martin Winter) Date: Tue, 5 May 2015 01:12:26 -0700 (PDT) Subject: yarr - Yet Another Route Server Implementation [WAS: Euro-IX quagga stable download and implementation] In-Reply-To: <55477CB1.4060201@sloc.de> References: <7b5c414d74bd558bbb473086d422c099@sox.rs> <13A7BFA0-E258-4A85-9879-95E0CD3FD786@nosignal.org> <002101d07f8c$67f67b20$37e37160$@rs> <54BC7947-5766-447F-B1A2-7BB137411F98@nosignal.org> <002201d07f93$478fc970$d6af5c50$@rs> <55477CB1.4060201@sloc.de> Message-ID: On Mon, 4 May 2015, Sebastian Spies wrote: > sorry, for the double post. dmarc fuckup... > > Hey there, > > considering the state of this discussion, BIRD seems to be the only > scalable solution to be used as a route server at IXPs. I have built a > large code base around BGP for the hoofprints project [1] and BRITE [2] > and would enjoy building another state-of-the-art open-source > route-server implementation for IXPs. Would you be so kind to send me > your feedback on this idea? Do you think, it makes sense to pursue such > a project or is it not relevant enough for you? How about (instead of another implementation) helping one of the existing projects? Writing another implementation is easy. Keeping it up to date, testing it and supporting it over multiple years is what I would worry about. I would *strongly* suggest to solve that issue first before starting on another implementation. - Martin From rsk at gsp.org Tue May 5 11:34:45 2015 From: rsk at gsp.org (Rich Kulawiec) Date: Tue, 5 May 2015 07:34:45 -0400 Subject: Network Segmentation Approaches In-Reply-To: <20150505025540.GA19516@bludgeon.org> References: <20150505025540.GA19516@bludgeon.org> Message-ID: <20150505113445.GB24399@gsp.org> On Mon, May 04, 2015 at 07:55:43PM -0700, nanog1 at roadrunner.com wrote: > Possibly a bit off-topic, but curious how all of you out there segment > your networks. [snip] I break them up by function and (when necessary) by the topology enforced by geography. The first rule in every firewall is of course "deny all" and subsequent rulesets permit only the traffic that is necessary. Determing what's necessary is done via a number of tools: tcpdump, ntop, argus, nmap, etc. When possible, rate-limiting is imposed based on a multiplier of observed maxima. Performance tuning is done after functionality and is usually pretty limited: modern efficient firewalls (e.g., pf/OpenBSD) can shovel a lot of traffic even on modest hardware. ---rsk From frederik at kriewitz.eu Tue May 5 12:32:17 2015 From: frederik at kriewitz.eu (Frederik Kriewitz) Date: Tue, 5 May 2015 14:32:17 +0200 Subject: Google IPv6 geo location problem Message-ID: Hello, At the beginning of this year we started to roll out IPv6 for a large part of our customer base. Everything was working perfectly fine until mid February when google decided to geo locate our entire 2a00:e60::/32 IPv6 net to Iran. We expected that it would be done for /48 to /64 blocks (On IPv4 it's done for each IP). Being a ISP with mostly satellite internet customers from all over the world we're used to problems caused by IP based geo locating. Usual the complains are "Please change the language of google.com to English, I don't understand the currently configured language" (happens if the previous user of the IP address trained google to some other language). Most of our customers (Mostly military, oil & gas, government and international companies) are expecting an English internet. Usually we can fix their problems by changing their IP address. But with our entire /32 being handled as Iran by Google this is a problem. The problem is that google apparently blocks Iran from using any remotely commercial service (I assume due to the sanctions against Iran). We got a lot of customers complaining about not being able to login into Google Apps ("Unable to sign in from this country - You appear to be signing in from a country where Google Apps accounts are not supported."). But plenty of other purely informational Google websites (e.g. http://www.html5rocks.com/) returned a "403 - We're sorry, but this service is not available in your country." forbidden error too. We had to revert our IPv6 roll out again due to this problem. We tried submitting a correction request via https://support.google.com/websearch/contact/ip back in February but that apparently wasn't processed. Is there anyone from Google around who can help with this? This is currently blocking our IPv6 deployment. Best Regards, Freddy AS62023 / NYNEX satellite OHG From mysidia at gmail.com Tue May 5 12:52:43 2015 From: mysidia at gmail.com (Jimmy Hess) Date: Tue, 5 May 2015 07:52:43 -0500 Subject: Network Segmentation Approaches In-Reply-To: <20150505025540.GA19516@bludgeon.org> References: <20150505025540.GA19516@bludgeon.org> Message-ID: On Mon, May 4, 2015 at 9:55 PM, wrote: > There's quite a bit of literature out there on this, so have been > considering an approach with zones based on the types of data or > processes within them. General thoughts: It depends on the users and tasks on the network.. Different segmentation strategies / tradeoffs get selected by people dependent upon what there is to be protected, Or where needed to control broadcast domain size, and value tradeoffs. Segmenting certain systems, or segmenting certain data, Or more likely both are called for to mitigate selected risks: both security risks, as well as network risks, Or to facilitate certain networks being moved independently to maintain continuity after DR. > - "Business Zone" - This would be where workstations live, > but I should [....] > generally be OK letting anything in this zone talk fairly unfettered > to anything else in this zone Since you imply all workstations would live on the same zone as each other, instead of being isolated or placed into job-role-specific access segments, then what you have here is a non-segmented network; that is: It sounds like this begins to look like your generic "non-segmented" zone "with small numbers of exceptions" strategy; you wind up with a few huge business zones which tend to become larger and larger over time -- are really still at highest risk, then a small number of tiny exception zones such as 'PCI Card Environment' zone, which are okay, until some users inevitably develop a requirement to connect workstations from the massive insecure zone to the tiny zone. Workstations talking to other workstations directly is an example of one of the higher risk things, that is probably not necessary, but remains unrestricted by having one single large 'Business' segment. A stronger segmentation model would be that workstations don't get to talk to other workstations directly; only to remote devices servicing data that the user of a given workstation is authorized to be using, with every flow being validated by a security device. > I'd probably have VoIP media servers in this zone, AD, DNS, etc. AD + DNS are definitely applications that should be at a high integrity protection level compared to generic segment from security standpoint; Especially if higher-security zones are dependent on those services. An AD group policy configuration change can cause arbitrary code execution on a domain-joined server in any segment attached to a domain using that AD server. > Presumably I should never allow *outbound* connectivity from a more > secure zone to a less secure zone, and inbound connectivity should be > carefully monitored for unusual access patterns. Never? No internet access? Never say never, but there should be policies established based on needs / requirements and dependent on the characteristics of a zone and the assumed risk level of other zones. An example for some high risk zone might be that outbound connections to A, B, and C only through a designated application-layer proxy itself residing in a security service zone. > be built off of? I'm especially interested to hear how VoIP/RTP > traffic is handled between subnets/remote sites within a "Business > Zone". I'm loathe to put a FW between these segments as it will > put VoIP performance at risk (maybe QoS on FW's can be pretty good), The ideal scenario is to have segments dedicated to primary VoIP use, so VoIP traffic should stay in-segment, except if interconnecting to a provider, and the firewalls do not necessarily have to be stateful firewalls; if VoIP traffic leaves a segment, some may use a simple packet filter or application-aware proxy designed to maintain the performance. If the security requirements of the org implementing the network are met, then very specific firewall devices can be used for certain zones that are the most suitable for that zone's traffic. > but maybe some sort of passive monitoring would make sense. -- -JH From list at satchell.net Tue May 5 12:53:24 2015 From: list at satchell.net (Stephen Satchell) Date: Tue, 05 May 2015 05:53:24 -0700 Subject: Network Segmentation Approaches In-Reply-To: <20150505025540.GA19516@bludgeon.org> References: <20150505025540.GA19516@bludgeon.org> Message-ID: <5548BD44.10509@satchell.net> On 05/04/2015 07:55 PM, nanog1 at roadrunner.com wrote: > Possibly a bit off-topic, but curious how all of you out there segment > your networks. Corporate/business users, dependent services, etc. from > critical data and/or processes with remote locations thrown in the mix > which could be mini-versions of your primary network. Add "management zone" or "infrastructure zone": Consider setting up a separate zone or zones (via VLAN) for devices with embedded TCP/IP stacks. I have worked in several shops using switched power units from APC, SynAccess, and TrippLite, and find that the TCP/IP stacks in those units are a bit fragile when confronted with a lot of traffic, even when the traffic is not addressed to the embedded devices. Separately, an ISP discovered that a consumer-grade NAS has the same problem. These should be on a separate subnet anyway, with unfettered access from the outside disallowed at the edge. To access the infrastructure equipment, you would use VPN to bypass your edge router access lists. If you have a lot of inside equipment not under your direct control, consider locking them out of the infrastructure subnet, too. Needless to day, watch the load you direct at these embedded devices. My current day job installed Solar Winds to monitor everything. The probes from the software knocked out the SNMP access to all too many of the PDU devices on the network. From kmedcalf at dessus.com Tue May 5 13:01:11 2015 From: kmedcalf at dessus.com (Keith Medcalf) Date: Tue, 05 May 2015 07:01:11 -0600 Subject: Network Segmentation Approaches In-Reply-To: <20150505025540.GA19516@bludgeon.org> Message-ID: <37159874eb548f45ba646b2576ecc85e@mail.dessus.com> It is called the Purdue Enterprise Reference Architecture ... > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of > nanog1 at roadrunner.com > Sent: Monday, 4 May, 2015 20:56 > To: nanog at nanog.org > Subject: Network Segmentation Approaches > > Possibly a bit off-topic, but curious how all of you out there segment > your networks. Corporate/business users, dependent services, etc. from > critical data and/or processes with remote locations thrown in the mix > which could be mini-versions of your primary network. > > There's quite a bit of literature out there on this, so have been > considering an approach with zones based on the types of data or > processes within them. General thoughts: > > - "Business Zone" - This would be where workstations live, > web browsing occurs, VoIP and authentication services live too. > Probably consider this a somewhat "dirty" zone, but I should > generally be OK letting anything in this zone talk fairly unfettered > to anything else in this zone (for example a business network at my > HQ location should be able to talk unfettered to an equivalent > network at a remote site). > > I'd probably have VoIP media servers in this zone, AD, DNS, etc. > > - Some sort of management zone(z) - Maybe accessible only via jump host > -- this zone gives "control" access into key resources (most likely > IT resouces like network devices, storage devices, etc.). Should > have sound logging/auditing here to establish access patterns outsid > the norm and perhaps multi-factor authentication (and of course > FW's). > > - Secure Zone(s) - Important data sets or services can be isolated from > untrusted zones here. May need separate services (DNS, AD, etc.) > > - I should think carefully about where I stick stateful FW's -- > especially on my internal networks. Risk of DoS'ing myself is high. > > Presumably I should never allow *outbound* connectivity from a more > secure zone to a less secure zone, and inbound connectivity should be > carefully monitored for unusual access patterns. > > Perhaps some of you have some fairly simple rules of thumb that could > be built off of? I'm especially interested to hear how VoIP/RTP > traffic is handled between subnets/remote sites within a "Business > Zone". I'm loathe to put a FW between these segments as it will > put VoIP performance at risk (maybe QoS on FW's can be pretty good), > but maybe some sort of passive monitoring would make sense. > > (Yes, I've also read the famous thread on stateful firewalls[1]). > > Thanks! > > [1] > http://markmail.org/thread/fvordsbnuc74fuu2#query:+page:1+mid:fvordsbnuc74 > fuu2+state:results From jmaslak at antelope.net Tue May 5 13:58:04 2015 From: jmaslak at antelope.net (Joel Maslak) Date: Tue, 5 May 2015 07:58:04 -0600 Subject: Network Segmentation Approaches In-Reply-To: <37159874eb548f45ba646b2576ecc85e@mail.dessus.com> References: <20150505025540.GA19516@bludgeon.org> <37159874eb548f45ba646b2576ecc85e@mail.dessus.com> Message-ID: I'd certainly forget anything with "service provider" in the name. Different problem, different architecture. Last time I built this, I built a core network (WAN links, routers, etc) that enforced anti-spoofing rules, so I knew if I saw an "internal" IP address (either public assigned to me or RFC1918) on a given device inside this "core", it came from the network segment it claimed to have come from. Then I built building-specific firewalls using proper firewalls. These might have anywhere from two interfaces (branch office) to thousands of interfaces (datacenters) with lots of VLANs. Checkpoint is a good product for this. The firewalls' job was to protect the building/segments behind it, not to protect things "upstream" (towards the core) of it. There was obviously an edge firewall. Users were segmented by job role. Workstations were typically considered to be *MORE* secure from a network perspective. AD servers need to be contacted by everything in your Windows domain. Most workstations don't. And your Windows domain, nowadays, probably includes cloud services over the internet. So it's hard to say AD servers are "secure" from a purely "how many open network ports are there?" standpoint. Servers were likewise segmented. I'd consider putting department file servers on the same LAN as the users, but only if performance required it - otherwise I'd put them on their own segments too. The benefit of this in a large organization is that a subdivision could put a firewall behind one of my anti-spoofing interfaces (so I validate packets come from them) and run it themselves without ruining everyone else's security. I second the thoughts about embedded management stacks. As for management, I put workstations used by IT management on their own segment (and give them a "Stand up the infected workstation you're working on" LAN separate from that segment). I put servers used for management on yet another segment. I've never had a problem with giving those workstations and servers access to management segments in the wild, but I trusted my skilled admins I worked with. Think mesh of connections, not "tiers" or levels or DMZs. Because you'll find that super-secure accounting server needs access from some random vendor across the internet, and stuff like that, such that everything eventually ends up in the DMZ anyhow (except MAYBE workstations). You can use separate firewalls for particularly sensitive segments - for instance, your management stuff might not be behind your main firewall - that way when Joe User gets a virus and fills the connection table on his firewall(s), you can still manage things. One more thing: Guest network access. When it was needed, I built a virtual network on top of the "real" Corporate LAN that tunneled this around. I terminated it on a DSL modem (which was sufficient for my needs). Just about every building with a conference room these days will need a guest network. It also helps if your employees can use their cell phones for checking work email and such - do you really want them on your main LAN? On Tue, May 5, 2015 at 7:01 AM, Keith Medcalf wrote: > > It is called the Purdue Enterprise Reference Architecture ... > > > -----Original Message----- > > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of > > nanog1 at roadrunner.com > > Sent: Monday, 4 May, 2015 20:56 > > To: nanog at nanog.org > > Subject: Network Segmentation Approaches > > > > Possibly a bit off-topic, but curious how all of you out there segment > > your networks. Corporate/business users, dependent services, etc. from > > critical data and/or processes with remote locations thrown in the mix > > which could be mini-versions of your primary network. > > > > There's quite a bit of literature out there on this, so have been > > considering an approach with zones based on the types of data or > > processes within them. General thoughts: > > > > - "Business Zone" - This would be where workstations live, > > web browsing occurs, VoIP and authentication services live too. > > Probably consider this a somewhat "dirty" zone, but I should > > generally be OK letting anything in this zone talk fairly unfettered > > to anything else in this zone (for example a business network at my > > HQ location should be able to talk unfettered to an equivalent > > network at a remote site). > > > > I'd probably have VoIP media servers in this zone, AD, DNS, etc. > > > > - Some sort of management zone(z) - Maybe accessible only via jump host > > -- this zone gives "control" access into key resources (most likely > > IT resouces like network devices, storage devices, etc.). Should > > have sound logging/auditing here to establish access patterns outsid > > the norm and perhaps multi-factor authentication (and of course > > FW's). > > > > - Secure Zone(s) - Important data sets or services can be isolated from > > untrusted zones here. May need separate services (DNS, AD, etc.) > > > > - I should think carefully about where I stick stateful FW's -- > > especially on my internal networks. Risk of DoS'ing myself is high. > > > > Presumably I should never allow *outbound* connectivity from a more > > secure zone to a less secure zone, and inbound connectivity should be > > carefully monitored for unusual access patterns. > > > > Perhaps some of you have some fairly simple rules of thumb that could > > be built off of? I'm especially interested to hear how VoIP/RTP > > traffic is handled between subnets/remote sites within a "Business > > Zone". I'm loathe to put a FW between these segments as it will > > put VoIP performance at risk (maybe QoS on FW's can be pretty good), > > but maybe some sort of passive monitoring would make sense. > > > > (Yes, I've also read the famous thread on stateful firewalls[1]). > > > > Thanks! > > > > [1] > > > http://markmail.org/thread/fvordsbnuc74fuu2#query:+page:1+mid:fvordsbnuc74 > > fuu2+state:results > > > > From bob at FiberInternetCenter.com Tue May 5 14:25:57 2015 From: bob at FiberInternetCenter.com (Bob Evans) Date: Tue, 5 May 2015 07:25:57 -0700 Subject: yarr - Yet Another Route Server Implementation [WAS: Euro-IX quagga stable download and implementation] In-Reply-To: References: <7b5c414d74bd558bbb473086d422c099@sox.rs> <13A7BFA0-E258-4A85-9879-95E0CD3FD786@nosignal.org> <002101d07f8c$67f67b20$37e37160$@rs> <54BC7947-5766-447F-B1A2-7BB137411F98@nosignal.org> <002201d07f93$478fc970$d6af5c50$@rs> <55477CB1.4060201@sloc.de> Message-ID: My experience tells me Martins direction is a good one. You would be surprised to learn how much time already went into whats out there that people trust now. Besides - it has very limited marketing appeal. The IXs number is small. The big ones already have something working well. I wouldn't implement something new. When I chose, I went for something a big network ran for years. As a result it was reliable and easy to maintain. Had few and simple problems. Simply ran 2 and had people get a session with both. No one ever lost routes when I took one down to upgrade - or when we had a hardware failure. Thank You Bob Evans CTO > On Mon, 4 May 2015, Sebastian Spies wrote: >> sorry, for the double post. dmarc fuckup... >> >> Hey there, >> >> considering the state of this discussion, BIRD seems to be the only >> scalable solution to be used as a route server at IXPs. I have built a >> large code base around BGP for the hoofprints project [1] and BRITE [2] >> and would enjoy building another state-of-the-art open-source >> route-server implementation for IXPs. Would you be so kind to send me >> your feedback on this idea? Do you think, it makes sense to pursue such >> a project or is it not relevant enough for you? > > How about (instead of another implementation) helping one of the existing > projects? > Writing another implementation is easy. Keeping it up to date, testing > it and supporting it over multiple years is what I would worry about. > > I would *strongly* suggest to solve that issue first before starting > on another implementation. > > - Martin > From Matthew.Black at csulb.edu Tue May 5 15:22:05 2015 From: Matthew.Black at csulb.edu (Matthew Black) Date: Tue, 5 May 2015 15:22:05 +0000 Subject: Fixing Google geolocation screwups In-Reply-To: References: Message-ID: Pedro Cavaca suggests: > https://support.google.com/websearch/answer/873?hl=en Correct me if I'm wrong, that looks like Google simply saves location data in a browser cookie. "A location helps Google find more relevant information when you use Search, Maps, and other Google products. Learn how Google saves location information on this computer." matthew black california state university, long beach -----Original Message----- From: NANOG [mailto:nanog-bounces+matthew.black=csulb.edu at nanog.org] On Behalf Of Pedro Cavaca Sent: Tuesday, April 07, 2015 3:41 PM To: John Levine Cc: NANOG Mailing List Subject: Re: Fixing Google geolocation screwups https://support.google.com/websearch/answer/873?hl=en On 7 April 2015 at 23:26, John Levine wrote: > A friend of mine lives in Alabama and has business service from at&t. > But Google thinks he's in France. We've checked for various > possibilities of VPNs and proxies and such, and it's pretty clear that > the Goog's geolocation for addresses around 99.106.185.0/24 is screwed > up. Bing and other services correctly find him in Alabama. > > Poking around I see lots of advice about how to use Google's > geolocation data, but nothing on how to update it. Anyone know the > secret? TIA > > Regards, > John Levine, johnl at iecc.com, Primary Perpetrator of "The Internet for > Dummies", Please consider the environment before reading this e-mail. > http://jl.ly > > > From pmsac.nanog at gmail.com Tue May 5 16:02:34 2015 From: pmsac.nanog at gmail.com (Pedro Cavaca) Date: Tue, 5 May 2015 17:02:34 +0100 Subject: Fixing Google geolocation screwups In-Reply-To: References: Message-ID: On 5 May 2015 at 16:22, Matthew Black wrote: > Pedro Cavaca suggests: > > https://support.google.com/websearch/answer/873?hl=en > > Correct me if I'm wrong, that looks like Google simply saves location data > in a browser cookie. > > "A location helps Google find more relevant information when you use > Search, Maps, and other Google products. Learn how Google saves location > information on this computer." > I don't see the text you quoted on the URL I provided. I do see a "report the problem" clickable, which was the point I was trying to make on my original answer. > > matthew black > california state university, long beach > > > -----Original Message----- > From: NANOG [mailto:nanog-bounces+matthew.black=csulb.edu at nanog.org] On > Behalf Of Pedro Cavaca > Sent: Tuesday, April 07, 2015 3:41 PM > To: John Levine > Cc: NANOG Mailing List > Subject: Re: Fixing Google geolocation screwups > > https://support.google.com/websearch/answer/873?hl=en > > > On 7 April 2015 at 23:26, John Levine wrote: > > > A friend of mine lives in Alabama and has business service from at&t. > > But Google thinks he's in France. We've checked for various > > possibilities of VPNs and proxies and such, and it's pretty clear that > > the Goog's geolocation for addresses around 99.106.185.0/24 is screwed > > up. Bing and other services correctly find him in Alabama. > > > > Poking around I see lots of advice about how to use Google's > > geolocation data, but nothing on how to update it. Anyone know the > > secret? TIA > > > > Regards, > > John Levine, johnl at iecc.com, Primary Perpetrator of "The Internet for > > Dummies", Please consider the environment before reading this e-mail. > > http://jl.ly > > > > > > > From lnguyen at opsource.net Tue May 5 16:03:23 2015 From: lnguyen at opsource.net (Luan Nguyen) Date: Tue, 5 May 2015 12:03:23 -0400 Subject: Fixing Google geolocation screwups In-Reply-To: References: Message-ID: There's a form here - https://support.google.com/websearch/contact/ip But google is pretty smart, its systems will learn the correct geolocation over time... On Tue, May 5, 2015 at 11:22 AM, Matthew Black wrote: > Pedro Cavaca suggests: > > https://support.google.com/websearch/answer/873?hl=en > > Correct me if I'm wrong, that looks like Google simply saves location data > in a browser cookie. > > "A location helps Google find more relevant information when you use > Search, Maps, and other Google products. Learn how Google saves location > information on this computer." > > > matthew black > california state university, long beach > > > -----Original Message----- > From: NANOG [mailto:nanog-bounces+matthew.black=csulb.edu at nanog.org] On > Behalf Of Pedro Cavaca > Sent: Tuesday, April 07, 2015 3:41 PM > To: John Levine > Cc: NANOG Mailing List > Subject: Re: Fixing Google geolocation screwups > > https://support.google.com/websearch/answer/873?hl=en > > > On 7 April 2015 at 23:26, John Levine wrote: > > > A friend of mine lives in Alabama and has business service from at&t. > > But Google thinks he's in France. We've checked for various > > possibilities of VPNs and proxies and such, and it's pretty clear that > > the Goog's geolocation for addresses around 99.106.185.0/24 is screwed > > up. Bing and other services correctly find him in Alabama. > > > > Poking around I see lots of advice about how to use Google's > > geolocation data, but nothing on how to update it. Anyone know the > > secret? TIA > > > > Regards, > > John Levine, johnl at iecc.com, Primary Perpetrator of "The Internet for > > Dummies", Please consider the environment before reading this e-mail. > > http://jl.ly > > > > > > > From ikiris at gmail.com Tue May 5 20:57:25 2015 From: ikiris at gmail.com (Blake Dunlap) Date: Tue, 5 May 2015 13:57:25 -0700 Subject: yarr - Yet Another Route Server Implementation [WAS: Euro-IX quagga stable download and implementation] In-Reply-To: <55477CB1.4060201@sloc.de> References: <7b5c414d74bd558bbb473086d422c099@sox.rs> <13A7BFA0-E258-4A85-9879-95E0CD3FD786@nosignal.org> <002101d07f8c$67f67b20$37e37160$@rs> <54BC7947-5766-447F-B1A2-7BB137411F98@nosignal.org> <002201d07f93$478fc970$d6af5c50$@rs> <55477CB1.4060201@sloc.de> Message-ID: http://xkcd.com/927/ On Mon, May 4, 2015 at 7:05 AM, Sebastian Spies wrote: > sorry, for the double post. dmarc fuckup... > > Hey there, > > considering the state of this discussion, BIRD seems to be the only > scalable solution to be used as a route server at IXPs. I have built a > large code base around BGP for the hoofprints project [1] and BRITE [2] > and would enjoy building another state-of-the-art open-source > route-server implementation for IXPs. Would you be so kind to send me > your feedback on this idea? Do you think, it makes sense to pursue such > a project or is it not relevant enough for you? > > Best regards, > Sebastian > > 1: https://github.com/sspies8684/hoofprints/ > 2: https://brite.antd.nist.gov/statics/about > > Am 25.04.2015 um 22:06 schrieb Goran Slavi?: >> Andy, >> >> Believe me when I say: I would never have the idea to think about >> attempting to try to test my ability to generate configurations for this "2 >> route servers/ 2 different programs that run them" solution without the IXP >> Manager :-) >> >> I am familiar with the work INEX has been doing with IXP Manager and >> have for some time attempted to find time from regular SOX operation to >> implement it in our IX. This migration gives me the excellent opportunity >> and arguments to finally allocate time, resources and manpower for >> installation and implementation of IXP Manager as the route server >> configuration generator at SOX. >> >> Regards >> G.Slavic >> >> >> -----Original Message----- >> From: Andy Davidson [mailto:andy at nosignal.org] >> Sent: Saturday, 25 April 2015 21:34 >> To: Goran Slavi? >> Cc: nanog at nanog.org >> Subject: Re: Euro-IX quagga stable download and implementation >> >> >> On 25 Apr 2015, at 15:16, Goran Slavi? wrote: >> >>> Considering what I have learned in your posts (and on other places >>> that I have informed myself) I will definitely suggest to SOX management >> to >>> go the way similar to what LINX did (1 Bird + 1 Quagga as route servers) >> for >>> the simple reason that 2 different solution provides more security in >>> context of "new program update->new bugs" problems and incidents and >>> prevents other potential problems. >> Goran - glad to have helped. >> >> One last piece of advice which might be useful - to help to guarantee >> consistency of performance between the two route-servers, you should >> consider a configuration generator so that your route-server configs are in >> sync. The best way to implement this at your exchange is to use IXP >> Manager, maintained by the awesome folks at the Irish exchange point, INEX. >> https://github.com/inex/IXP-Manager >> >> IXP Manager will get you lots of other features as well as good route-server >> hygiene. >> >> There's also a historic perl-script that does this on my personal github. >> Both of these solutions allow you to filter route-server participants based >> on IRR data, which has proved to be a life-saver at all of the exchanges I >> help to operate. Having my horrible historic thing is maybe better than no >> thing at all, but I deliberately won't link to it as you should really use >> IXP Manager. :-) >> >> Andy= >> >> From mpalmer at hezmatt.org Tue May 5 21:07:46 2015 From: mpalmer at hezmatt.org (Matt Palmer) Date: Wed, 6 May 2015 07:07:46 +1000 Subject: Fixing Google geolocation screwups In-Reply-To: References: Message-ID: <20150505210746.GH22158@hezmatt.org> On Tue, May 05, 2015 at 12:03:23PM -0400, Luan Nguyen wrote: > There's a form here - https://support.google.com/websearch/contact/ip > But google is pretty smart, its systems will learn the correct geolocation > over time... That'd be quite a trick, given that the netblock practically can't be used at all with Google services. - Matt From thomas.m.king at gmail.com Tue May 5 21:43:49 2015 From: thomas.m.king at gmail.com (Thomas King) Date: Tue, 5 May 2015 23:43:49 +0200 Subject: yarr - Yet Another Route Server Implementation [WAS: Euro-IX quagga stable download and implementation] In-Reply-To: <55477CB1.4060201@sloc.de> References: <7b5c414d74bd558bbb473086d422c099@sox.rs> <13A7BFA0-E258-4A85-9879-95E0CD3FD786@nosignal.org> <002101d07f8c$67f67b20$37e37160$@rs> <54BC7947-5766-447F-B1A2-7BB137411F98@nosignal.org> <002201d07f93$478fc970$d6af5c50$@rs> <55477CB1.4060201@sloc.de> Message-ID: Hi Sebastian, I highly support your idea! Almost all large IXPs switched to bird. As we know from different route server studies almost 1/3 of the traffic handled by IXPs is managed by route servers. This shows that route servers play an important role in the IXP ecosystem. So, depending on only one implementation comes with a lot of operational risks at least. The beauty of your suggestion is that a route server that is just that (and not a routing daemon with many unneeded features as bird or quagga). This could limit the complexity of the source code which means the effort needed to maintain the code should be a lot smaller compared to bird/quagga. I see no reason why there is not enough room for at least one or two more route server implementations besides bird. Best regards, Thomas (with no hat on -> my personal opinion) From marka at isc.org Tue May 5 23:34:45 2015 From: marka at isc.org (Mark Andrews) Date: Wed, 06 May 2015 09:34:45 +1000 Subject: Network Segmentation Approaches In-Reply-To: Your message of "Tue, 05 May 2015 07:34:45 -0400." <20150505113445.GB24399@gsp.org> References: <20150505025540.GA19516@bludgeon.org> <20150505113445.GB24399@gsp.org> Message-ID: <20150505233447.0AF4E2DCCA80@rock.dv.isc.org> In message <20150505113445.GB24399 at gsp.org>, Rich Kulawiec writes: > On Mon, May 04, 2015 at 07:55:43PM -0700, nanog1 at roadrunner.com wrote: > > Possibly a bit off-topic, but curious how all of you out there segment > > your networks. [snip] > > I break them up by function and (when necessary) by the topology > enforced by geography. The first rule in every firewall is of > course "deny all" and subsequent rulesets permit only the traffic > that is necessary. The first rule of every firewall should be to enforce BCP 38 out bound. Deny all really isn't needed with modern machines but that is a matter of policy. > Determing what's necessary is done via a number > of tools: tcpdump, ntop, argus, nmap, etc. When possible, rate-limiting > is imposed based on a multiplier of observed maxima. Performance > tuning is done after functionality and is usually pretty limited: > modern efficient firewalls (e.g., pf/OpenBSD) can shovel a lot of > traffic even on modest hardware. > > ---rsk > -- 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 Tue May 5 23:54:07 2015 From: marka at isc.org (Mark Andrews) Date: Wed, 06 May 2015 09:54:07 +1000 Subject: Google IPv6 geo location problem In-Reply-To: Your message of "Tue, 05 May 2015 14:32:17 +0200." References: Message-ID: <20150505235409.0BE3A2DCCF75@rock.dv.isc.org> I would first fix the RIPE whois data. s/UNITED STATES/GERMANY/ All the contacts are wrong. GI-GO e.g. person: Andreas Buxbaum address: NYNEX satellite OHG address: Robert-Bosch-Str. 20 address: 64293 Darmstadt address: UNITED STATES phone: +49 6151 50074-0 nic-hdl: NX911 mnt-by: MNT-NY source: RIPE # Filtered Mark In message , Frederik Kriewitz writes: > Hello, > > At the beginning of this year we started to roll out IPv6 for a large > part of our customer base. > Everything was working perfectly fine until mid February when google > decided to geo locate our entire 2a00:e60::/32 IPv6 net to Iran. > We expected that it would be done for /48 to /64 blocks (On IPv4 it's > done for each IP). > Being a ISP with mostly satellite internet customers from all over the > world we're used to problems caused by IP based geo locating. > Usual the complains are "Please change the language of google.com to > English, I don't understand the currently configured language" > (happens if the previous user of the IP address trained google to some > other language). > Most of our customers (Mostly military, oil & gas, government and > international companies) are expecting an English internet. > Usually we can fix their problems by changing their IP address. But > with our entire /32 being handled as Iran by Google this is a problem. > The problem is that google apparently blocks Iran from using any > remotely commercial service (I assume due to the sanctions against > Iran). > We got a lot of customers complaining about not being able to login > into Google Apps ("Unable to sign in from this country - You appear to > be signing in from a country where Google Apps accounts are not > supported."). > But plenty of other purely informational Google websites (e.g. > http://www.html5rocks.com/) returned a "403 - We're sorry, but this > service is not available in your country." forbidden error too. > We had to revert our IPv6 roll out again due to this problem. > > We tried submitting a correction request via > https://support.google.com/websearch/contact/ip back in February but > that apparently wasn't processed. > Is there anyone from Google around who can help with this? > This is currently blocking our IPv6 deployment. > > Best Regards, > Freddy > AS62023 / NYNEX satellite OHG -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From ramy.ihashish at gmail.com Tue May 5 10:27:56 2015 From: ramy.ihashish at gmail.com (Ramy Hashish) Date: Tue, 5 May 2015 12:27:56 +0200 Subject: IP DSCP across the Internet Message-ID: Good day all, A simple question, does Internet trust IP DSCP marking? Assume two ASs connected through two tier 1 networks, will the tier one networks trust any DSCP markings done from an AS to the other? Thanks, Ramy From gleduc at mail.sdsu.edu Tue May 5 23:58:19 2015 From: gleduc at mail.sdsu.edu (Gene LeDuc) Date: Tue, 05 May 2015 16:58:19 -0700 Subject: Network Segmentation Approaches In-Reply-To: <20150505233447.0AF4E2DCCA80@rock.dv.isc.org> References: <20150505025540.GA19516@bludgeon.org> <20150505113445.GB24399@gsp.org> <20150505233447.0AF4E2DCCA80@rock.dv.isc.org> Message-ID: <5549591B.4090009@mail.sdsu.edu> On 5/5/2015 4:34 PM, Mark Andrews wrote: > In message <20150505113445.GB24399 at gsp.org>, Rich Kulawiec writes: >> I break them up by function and (when necessary) by the topology >> enforced by geography. The first rule in every firewall is of >> course "deny all" and subsequent rulesets permit only the traffic >> that is necessary. > > Deny all really isn't needed with modern machines but that is a matter of > policy. The firewalls I've worked with don't log denies if they are due to an implicit deny-all at the end of the policy. I always put one in at the end to make sure that the attempt is logged. Gene From rdobbins at arbor.net Wed May 6 00:30:17 2015 From: rdobbins at arbor.net (Roland Dobbins) Date: Wed, 06 May 2015 07:30:17 +0700 Subject: IP DSCP across the Internet In-Reply-To: References: Message-ID: <210B93D2-0387-4ECE-A325-4A23A13E9923@arbor.net> On 5 May 2015, at 17:27, Ramy Hashish wrote: > Assume two ASs connected through two tier 1 networks, will the tier > one networks trust any DSCP markings done from an AS to the other? The BCP is to re-color on ingress. ----------------------------------- Roland Dobbins From marka at isc.org Wed May 6 00:56:22 2015 From: marka at isc.org (Mark Andrews) Date: Wed, 06 May 2015 10:56:22 +1000 Subject: Fixing Google geolocation screwups In-Reply-To: Your message of "Wed, 06 May 2015 07:07:46 +1000." <20150505210746.GH22158@hezmatt.org> References: <20150505210746.GH22158@hezmatt.org> Message-ID: <20150506005623.72EF02DCDC31@rock.dv.isc.org> In message <20150505210746.GH22158 at hezmatt.org>, Matt Palmer writes: > On Tue, May 05, 2015 at 12:03:23PM -0400, Luan Nguyen wrote: > > There's a form here - https://support.google.com/websearch/contact/ip > > But google is pretty smart, its systems will learn the correct geolocation > > over time... > > That'd be quite a trick, given that the netblock practically can't be used > at all with Google services. > > - Matt One would expect support.google.com to not be geo blocked just like postmaster@ should not be filtered. That said they can always disable IPv6 temporarially (or just firewall off the IPv6 instance of support.google.com and have the browser fallback to IPv4) and reach support.google.com over IPv4 to lodge the complaint. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From jackson.tim at gmail.com Wed May 6 01:35:03 2015 From: jackson.tim at gmail.com (Tim Jackson) Date: Tue, 5 May 2015 18:35:03 -0700 Subject: IP DSCP across the Internet In-Reply-To: References: Message-ID: In general there are very few bad actors here in regards to trusting/accepting/using DSCP across the internet. Apple has a tendency to mark some traffic with EF that shouldn't be EF on PNIs, and Cogent leaks a lot of their internal markings into customers, but it's generally unmarked traffic from certain customers/peers. Other than that IMHO it's totally valid to accept, and nobody abuses it (other than those 2). We accept DSCP from the internet and do queue a few things higher towards customers for things like OTT VoIP etc. Remarking DSCP is bad IMHO, trusting it is another thing. You just have to be careful, and I suggest good netflow tools to keep an eye on it. On May 5, 2015 5:30 PM, "Ramy Hashish" wrote: > Good day all, > > A simple question, does Internet trust IP DSCP marking? Assume two ASs > connected through two tier 1 networks, will the tier one networks trust any > DSCP markings done from an AS to the other? > > Thanks, > > Ramy > From mpalmer at hezmatt.org Wed May 6 01:36:34 2015 From: mpalmer at hezmatt.org (Matt Palmer) Date: Wed, 6 May 2015 11:36:34 +1000 Subject: Fixing Google geolocation screwups In-Reply-To: <20150506005623.72EF02DCDC31@rock.dv.isc.org> References: <20150505210746.GH22158@hezmatt.org> <20150506005623.72EF02DCDC31@rock.dv.isc.org> Message-ID: <20150506013634.GV22158@hezmatt.org> On Wed, May 06, 2015 at 10:56:22AM +1000, Mark Andrews wrote: > In message <20150505210746.GH22158 at hezmatt.org>, Matt Palmer writes: > > On Tue, May 05, 2015 at 12:03:23PM -0400, Luan Nguyen wrote: > > > There's a form here - https://support.google.com/websearch/contact/ip > > > But google is pretty smart, its systems will learn the correct geolocation > > > over time... > > > > That'd be quite a trick, given that the netblock practically can't be used > > at all with Google services. > > One would expect support.google.com to not be geo blocked just like > postmaster@ should not be filtered. That said they can always > disable IPv6 temporarially (or just firewall off the IPv6 instance > of support.google.com and have the browser fallback to IPv4) and > reach support.google.com over IPv4 to lodge the complaint. I was specifically responding to the suggestion that Google would automagically "learn" the correct location of the netblock, presumably based on the characteristics of requests coming from the range. Being explicitly told that a given netblock is in a given location (as effective, or otherwise, as that may be) doesn't really fit the description of "systems [learning] the correct geolocation over time". - Matt -- Skippy was a wallaby. ... Wallabies are dumb and not very trainable... The *good* thing...is that one Skippy looks very much like all the rest, hence..."one-shot Skippy" and "plug-compatible Skippy". I don't think they ever had to go as far as "belt-fed Skippy" -- Robert Sneddon, ASR From ikiris at gmail.com Wed May 6 02:27:53 2015 From: ikiris at gmail.com (Blake Dunlap) Date: Tue, 5 May 2015 19:27:53 -0700 Subject: IP DSCP across the Internet In-Reply-To: References: Message-ID: If there isn't a specific peering agreement which sets up DSCP marks with your Z side, you're going to have a bad time doing anything other than remarking to 0. -Blake On Tue, May 5, 2015 at 6:35 PM, Tim Jackson wrote: > In general there are very few bad actors here in regards to > trusting/accepting/using DSCP across the internet. > > Apple has a tendency to mark some traffic with EF that shouldn't be EF on > PNIs, and Cogent leaks a lot of their internal markings into customers, but > it's generally unmarked traffic from certain customers/peers. Other than > that IMHO it's totally valid to accept, and nobody abuses it (other than > those 2). > > We accept DSCP from the internet and do queue a few things higher towards > customers for things like OTT VoIP etc. > > Remarking DSCP is bad IMHO, trusting it is another thing. You just have to > be careful, and I suggest good netflow tools to keep an eye on it. > On May 5, 2015 5:30 PM, "Ramy Hashish" wrote: > >> Good day all, >> >> A simple question, does Internet trust IP DSCP marking? Assume two ASs >> connected through two tier 1 networks, will the tier one networks trust any >> DSCP markings done from an AS to the other? >> >> Thanks, >> >> Ramy >> From mark.tinka at seacom.mu Wed May 6 05:38:26 2015 From: mark.tinka at seacom.mu (Mark Tinka) Date: Wed, 6 May 2015 07:38:26 +0200 Subject: IP DSCP across the Internet In-Reply-To: References: Message-ID: <5549A8D2.9010702@seacom.mu> On 5/May/15 12:27, Ramy Hashish wrote: > Good day all, > > A simple question, does Internet trust IP DSCP marking? Assume two ASs > connected through two tier 1 networks, will the tier one networks trust any > DSCP markings done from an AS to the other? I wouldn't bet on it. Some providers honor, most remark. We remark. We can only honor DSCP values on private circuits (l2vpn, l3vpn, that sort o' thing). Mark. From mark.tinka at seacom.mu Wed May 6 05:43:10 2015 From: mark.tinka at seacom.mu (Mark Tinka) Date: Wed, 6 May 2015 07:43:10 +0200 Subject: IP DSCP across the Internet In-Reply-To: References: Message-ID: <5549A9EE.8040805@seacom.mu> On 6/May/15 03:35, Tim Jackson wrote: > In general there are very few bad actors here in regards to > trusting/accepting/using DSCP across the internet. > > Apple has a tendency to mark some traffic with EF that shouldn't be EF on > PNIs, and Cogent leaks a lot of their internal markings into customers, but > it's generally unmarked traffic from certain customers/peers. Other than > that IMHO it's totally valid to accept, and nobody abuses it (other than > those 2). > > We accept DSCP from the internet and do queue a few things higher towards > customers for things like OTT VoIP etc. > > Remarking DSCP is bad IMHO, trusting it is another thing. You just have to > be careful, and I suggest good netflow tools to keep an eye on it. We had an odd experience, once, where - due to old hardware - we could not remark traffic we were picking up from a peer in South Africa. With color-aware policing toward a customer in Uganda, any traffic coming from that peer in South Africa was getting dropped toward that customer in Uganda. After a very odd sequence of troubleshooting events, we found that the AF DSCP alues being set by the peer in South Africa (and us passing them due to the old kit not being able to remark on ingress) was causing the color-aware policer in Uganda to drop traffic toward the customer there. Re-configuring the policer to be color-blind fixed the issue, but you can imagine how such a corner case this was. Naturally, with new kit in now, our global QoS policy is in effect. We don't honor DSCP values that comes in via best-effort circuits (i.e., the Internet). Although not a very strong reason, this particular experience is one reason why. Mark. From randy at psg.com Wed May 6 05:48:40 2015 From: randy at psg.com (Randy Bush) Date: Wed, 06 May 2015 14:48:40 +0900 Subject: IP DSCP across the Internet In-Reply-To: <5549A9EE.8040805@seacom.mu> References: <5549A9EE.8040805@seacom.mu> Message-ID: > We don't honor DSCP values that comes in via best-effort circuits > (i.e., the Internet). Although not a very strong reason, this > particular experience is one reason why. trusting markings of any sort which you do not need is an increase in attack, game playing, and/or bug surface. the only thing i would pass is ecn. randy From fred at web2objects.com Wed May 6 07:19:00 2015 From: fred at web2objects.com (Fred Hollis) Date: Wed, 06 May 2015 09:19:00 +0200 Subject: Fixing Google geolocation screwups In-Reply-To: <20150506013634.GV22158@hezmatt.org> References: <20150505210746.GH22158@hezmatt.org> <20150506005623.72EF02DCDC31@rock.dv.isc.org> <20150506013634.GV22158@hezmatt.org> Message-ID: <5549C064.4010904@web2objects.com> Honestly, I lost patience "the system learning the proper location of the IPv6 block". I have a very similar problem to the OP since 4-5 months, submitted this IP correction form multiple times... nothing changed. This is *very* annoying. Yes, my whois/SWIP is perfectly fine, every other geo ip database is showing correct location. On 06.05.2015 at 03:36 Matt Palmer wrote: > On Wed, May 06, 2015 at 10:56:22AM +1000, Mark Andrews wrote: >> In message <20150505210746.GH22158 at hezmatt.org>, Matt Palmer writes: >>> On Tue, May 05, 2015 at 12:03:23PM -0400, Luan Nguyen wrote: >>>> There's a form here - https://support.google.com/websearch/contact/ip >>>> But google is pretty smart, its systems will learn the correct geolocation >>>> over time... >>> >>> That'd be quite a trick, given that the netblock practically can't be used >>> at all with Google services. >> >> One would expect support.google.com to not be geo blocked just like >> postmaster@ should not be filtered. That said they can always >> disable IPv6 temporarially (or just firewall off the IPv6 instance >> of support.google.com and have the browser fallback to IPv4) and >> reach support.google.com over IPv4 to lodge the complaint. > > I was specifically responding to the suggestion that Google would > automagically "learn" the correct location of the netblock, presumably based > on the characteristics of requests coming from the range. Being explicitly > told that a given netblock is in a given location (as effective, or > otherwise, as that may be) doesn't really fit the description of "systems > [learning] the correct geolocation over time". > > - Matt > From m4rtntns at gmail.com Wed May 6 09:20:45 2015 From: m4rtntns at gmail.com (Martin T) Date: Wed, 6 May 2015 12:20:45 +0300 Subject: disadvantages of peering with own IP transit customers Message-ID: Hi, what are the disadvantages of peering(announcing own and all customers prefixes) with own IP transit customers? One disadvantage is obviously that amount of traffic on IP transit link is lower and thus customer pays for smaller amount of Mbps. On the other hand, this can be somewhat compensated with higher price per Mbps if the amount of traffic on the IP transit connection is lower. However, are there any other disadvantages/concerns when peering with own IP transit customers? regards, Martin From mark.tinka at seacom.mu Wed May 6 09:32:13 2015 From: mark.tinka at seacom.mu (Mark Tinka) Date: Wed, 6 May 2015 11:32:13 +0200 Subject: disadvantages of peering with own IP transit customers In-Reply-To: References: Message-ID: <5549DF9D.8040109@seacom.mu> On 6/May/15 11:20, Martin T wrote: > Hi, > > what are the disadvantages of peering(announcing own and all customers > prefixes) with own IP transit customers? One disadvantage is obviously > that amount of traffic on IP transit link is lower and thus customer > pays for smaller amount of Mbps. On the other hand, this can be > somewhat compensated with higher price per Mbps if the amount of > traffic on the IP transit connection is lower. However, are there any > other disadvantages/concerns when peering with own IP transit > customers? - Potentially odd routing if customers are unfamiliar with how BGP really works, i.e., upload from customer hits the commercial link, but return traffic to customer follows the peering link since peering links generally have a higher LOCAL_PREF than commercial links. - Since more traffic is return to (eyeball-heavy) customers, you increase investment on your peering side with no corresponding gain in revenue, as peering is, well, free. - Any special policies you accord to peers will now be enjoyed by this customer also, since they also are a peer. - Issues that could be caused by deliberate inconsistent routing from the customer's part in an effort to direct more traffic into the peering link. - Complicated controls you may put in place to ensure the customer does not abuse your network from a peering standpoint (or vice versa), e.g., Internet in VRF's, peering in VRF's, e.t.c., and the issues that come with all that complexity. - Complications with the commercial contract - a growth in your customer's traffic out of balance with how much money you're earning from them. - Confusion between your customer, their account manager, the engineering team and the operations teams on how the service is meant to be delivered, operated, billed for, e.t.c. - A host of other things I haven't thought about. All in all, don't peer with customers if you don't have to. That should be your #1 and #2 peering policy rules. Too much commercial and technical confusion will surely ensue. Mark. From joelm at bigleaf.net Wed May 6 01:22:21 2015 From: joelm at bigleaf.net (Joel Mulkey) Date: Wed, 6 May 2015 01:22:21 +0000 Subject: IP DSCP across the Internet In-Reply-To: <210B93D2-0387-4ECE-A325-4A23A13E9923@arbor.net> References: <210B93D2-0387-4ECE-A325-4A23A13E9923@arbor.net> Message-ID: But don't trust that's going to be the rule. I recently had a situation where traffic across a congested public peering link between 2 large "tier-2" carriers was honoring DSCP, resulting in some unexpected inconsistent behavior. Joel Mulkey Founder and CEO Bigleaf Networks Direct: +1 (503) 985-6964 | Support: +1 (503) 985-8298 | www.bigleaf.net > On May 5, 2015, at 5:30 PM, Roland Dobbins wrote: > > > On 5 May 2015, at 17:27, Ramy Hashish wrote: > >> Assume two ASs connected through two tier 1 networks, will the tier one networks trust any DSCP markings done from an AS to the other? > > The BCP is to re-color on ingress. > > ----------------------------------- > Roland Dobbins From lists at silverlakeinternet.com Wed May 6 02:38:38 2015 From: lists at silverlakeinternet.com (Brett A Mansfield) Date: Tue, 5 May 2015 20:38:38 -0600 Subject: Hulu, ABC, Disney have blocked my entire subnet! Message-ID: Anyone know any good contacts with any of these companies so I can get this resolved? As an ISP, having my entire subnet blocked prevents my customers from being able to use these services they pay for. We are getting the outside of the U.S. or going through hosted proxy issue. I have never used proxies, but even if one of my customers did shouldn't it block just the one IP address? Thank you, Brett A Mansfield From nanog at ics-il.net Wed May 6 12:44:53 2015 From: nanog at ics-il.net (Mike Hammett) Date: Wed, 6 May 2015 07:44:53 -0500 (CDT) Subject: Hulu, ABC, Disney have blocked my entire subnet! In-Reply-To: Message-ID: <23786405.6614.1430916289949.JavaMail.mhammett@ThunderFuck> I don't think you mentioned the out of country error on the other list. ;-) Have you verified with any and all IP geolcoation services that you can find that your network is properly located? Maybe they think you're in Iran? ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com ----- Original Message ----- From: "Brett A Mansfield" To: nanog at nanog.org Sent: Tuesday, May 5, 2015 9:38:38 PM Subject: Hulu, ABC, Disney have blocked my entire subnet! Anyone know any good contacts with any of these companies so I can get this resolved? As an ISP, having my entire subnet blocked prevents my customers from being able to use these services they pay for. We are getting the outside of the U.S. or going through hosted proxy issue. I have never used proxies, but even if one of my customers did shouldn't it block just the one IP address? Thank you, Brett A Mansfield From rdobbins at arbor.net Wed May 6 12:47:00 2015 From: rdobbins at arbor.net (Roland Dobbins) Date: Wed, 06 May 2015 19:47:00 +0700 Subject: IP DSCP across the Internet In-Reply-To: References: <210B93D2-0387-4ECE-A325-4A23A13E9923@arbor.net> Message-ID: On 6 May 2015, at 8:22, Joel Mulkey wrote: > But don't trust that's going to be the rule. Yes, that's always the caveat. Just do what you can within your own span of administrative control. ----------------------------------- Roland Dobbins From bz_siege_01 at hotmail.com Wed May 6 16:28:28 2015 From: bz_siege_01 at hotmail.com (c b) Date: Wed, 6 May 2015 09:28:28 -0700 Subject: Question about co-lo in APAC region Message-ID: This is a pre-project discovery question... any help would be greatly appreciated. We have upcoming partnerships (opportunities) in APAC. The original plan was to place the hub in Singapore. Just weeks before everyone was ready to begin the RFP, it turns out that one of our partner businesses owns a Co-Lo in India. Not sure what the name or the size of this business is yet. While it would be nice to take advantage of this, we have potential partnerships in China and other areas of APAC in development... we are hesitating to put our APAC hub in India just based on latency and where the undersea cables run. So, I'm reaching out to NANOG... some of you guys have either worked with businesses (or work in provider space) in both India and Singapore (and elsewhere, such as Japan). Is there a clear reason to use/not-use India as a hub? What would the pros/cons be? Is there a clear advantage to using Singapore as we originally planned? Again, we appreciate the feedback. LFoD From frnkblk at iname.com Wed May 6 18:46:37 2015 From: frnkblk at iname.com (Frank Bulk) Date: Wed, 6 May 2015 13:46:37 -0500 Subject: Hulu, ABC, Disney have blocked my entire subnet! In-Reply-To: <23786405.6614.1430916289949.JavaMail.mhammett@ThunderFuck> References: <23786405.6614.1430916289949.JavaMail.mhammett@ThunderFuck> Message-ID: <008601d0882c$fb98fb70$f2caf250$@iname.com> Brett, Please share the subnet with us. Have you followed through the list here, specifically checking Akamai, and seeing what it lists? http://nanog.cluepon.net/index.php/GeoIP Frank -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Mike Hammett Sent: Wednesday, May 06, 2015 7:45 AM To: nanog at nanog.org Subject: Re: Hulu, ABC, Disney have blocked my entire subnet! I don't think you mentioned the out of country error on the other list. ;-) Have you verified with any and all IP geolcoation services that you can find that your network is properly located? Maybe they think you're in Iran? ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com ----- Original Message ----- From: "Brett A Mansfield" To: nanog at nanog.org Sent: Tuesday, May 5, 2015 9:38:38 PM Subject: Hulu, ABC, Disney have blocked my entire subnet! Anyone know any good contacts with any of these companies so I can get this resolved? As an ISP, having my entire subnet blocked prevents my customers from being able to use these services they pay for. We are getting the outside of the U.S. or going through hosted proxy issue. I have never used proxies, but even if one of my customers did shouldn't it block just the one IP address? Thank you, Brett A Mansfield From David.Siegel at Level3.com Wed May 6 19:36:52 2015 From: David.Siegel at Level3.com (Siegel, David) Date: Wed, 6 May 2015 19:36:52 +0000 Subject: Question about co-lo in APAC region In-Reply-To: References: Message-ID: <970945E55BFD8C4EA4CAD74B647A9DC0A62C99E4@USIDCWVEMBX10.corp.global.level3.com> Technical feasibility aside, you should consult with an attorney that specializes in International business and tax law. India is similar to China in that there are material challenges to doing business in those countries. For example, you can't get a license to operate as a foreign entity (although you can operate under someone else's license), you generally have to form a JV that is majority owned by a domestically owned company. By comparison, Singapore is a relatively easy country to get a license to operate a telecommunications business. Dave -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of c b Sent: Wednesday, May 06, 2015 10:28 AM To: nanog at nanog.org Subject: Question about co-lo in APAC region This is a pre-project discovery question... any help would be greatly appreciated. We have upcoming partnerships (opportunities) in APAC. The original plan was to place the hub in Singapore. Just weeks before everyone was ready to begin the RFP, it turns out that one of our partner businesses owns a Co-Lo in India. Not sure what the name or the size of this business is yet. While it would be nice to take advantage of this, we have potential partnerships in China and other areas of APAC in development... we are hesitating to put our APAC hub in India just based on latency and where the undersea cables run. So, I'm reaching out to NANOG... some of you guys have either worked with businesses (or work in provider space) in both India and Singapore (and elsewhere, such as Japan). Is there a clear reason to use/not-use India as a hub? What would the pros/cons be? Is there a clear advantage to using Singapore as we originally planned? Again, we appreciate the feedback. LFoD From rafael at gav.ufsc.br Wed May 6 19:39:54 2015 From: rafael at gav.ufsc.br (Rafael Possamai) Date: Wed, 6 May 2015 14:39:54 -0500 Subject: Question about co-lo in APAC region In-Reply-To: References: Message-ID: Personal opinion: developing countries tend to have unstable utility service (power is what matters here), so your DC of choice in India should be Tier 4 preferably, which are hard to find and really expensive. Budget allowing, I'd stick to Hong Kong, Shangai or Singapore as you mentioned initially. These cities have pretty large financial services industries (which rely heavily on IT & telco in general) and large companies like Equinix/Digital Realty have already done the heavy lifting for you in terms of scoping a good location for an APAC datacenter. On Wed, May 6, 2015 at 11:28 AM, c b wrote: > This is a pre-project discovery question... any help would be greatly > appreciated. > We have upcoming partnerships (opportunities) in APAC. The original plan > was to place the hub in Singapore. Just weeks before everyone was ready to > begin the RFP, it turns out that one of our partner businesses owns a Co-Lo > in India. Not sure what the name or the size of this business is yet. While > it would be nice to take advantage of this, we have potential partnerships > in China and other areas of APAC in development... we are hesitating to put > our APAC hub in India just based on latency and where the undersea cables > run. > So, I'm reaching out to NANOG... some of you guys have either worked with > businesses (or work in provider space) in both India and Singapore (and > elsewhere, such as Japan). Is there a clear reason to use/not-use India as > a hub? What would the pros/cons be? Is there a clear advantage to using > Singapore as we originally planned? > Again, we appreciate the feedback. > LFoD From charles at thefnf.org Wed May 6 19:59:53 2015 From: charles at thefnf.org (charles at thefnf.org) Date: Wed, 06 May 2015 14:59:53 -0500 Subject: Network Segmentation Approaches In-Reply-To: <5548BD44.10509@satchell.net> References: <20150505025540.GA19516@bludgeon.org> <5548BD44.10509@satchell.net> Message-ID: > Consider setting up a separate zone or zones (via VLAN) for devices > with embedded TCP/IP stacks. I have worked in several shops using > switched power units from APC, SynAccess, and TrippLite, and find that > the TCP/IP stacks in those units are a bit fragile when confronted > with a lot of traffic, even when the traffic is not addressed to the > embedded devices. Yes! This. I used to have my PDUs/term serves/switches all on one VLAN. As growth occurred, they get broken out to dedicated VLANs. With that, the amount of false positives from Zenoss went way down (frequently port 80 would report down, then clear). I still get some alerts, but far less frequently. From morrowc.lists at gmail.com Wed May 6 21:25:23 2015 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Wed, 6 May 2015 17:25:23 -0400 Subject: Network Segmentation Approaches In-Reply-To: References: <20150505025540.GA19516@bludgeon.org> <5548BD44.10509@satchell.net> Message-ID: this is really a form of: "A subnet should contain all things of a like purpose/use." that way you don't have to compromise and say: "Well... tcp/443 is OK for ABC units but deadly for XYZ ones! block to the 6 of 12 XYZ and permit to all ABC... wait, can you bounce off an ABC and still kill an XYZ? crap... pwned." segregation by function/purpose... best bet you can get. On Wed, May 6, 2015 at 3:59 PM, wrote: > >> Consider setting up a separate zone or zones (via VLAN) for devices >> with embedded TCP/IP stacks. I have worked in several shops using >> switched power units from APC, SynAccess, and TrippLite, and find that >> the TCP/IP stacks in those units are a bit fragile when confronted >> with a lot of traffic, even when the traffic is not addressed to the >> embedded devices. > > > Yes! This. > > I used to have my PDUs/term serves/switches all on one VLAN. As growth > occurred, they get broken out to dedicated VLANs. With that, the amount of > false positives from Zenoss went way down (frequently port 80 would report > down, then clear). I still get some alerts, but far less frequently. From colton.conor at gmail.com Wed May 6 21:48:38 2015 From: colton.conor at gmail.com (Colton Conor) Date: Wed, 6 May 2015 16:48:38 -0500 Subject: Alcatel-Lucent 7750 Service Router (SR) Message-ID: I was wondering if anyone was using a Alcatel-Lucent 7750 Service Router (SR) in their network? How does this platform compare the the Cisco ASR, Brocade MLXe, and Juniper MX line? From sliplever at gmail.com Wed May 6 21:58:07 2015 From: sliplever at gmail.com (Dan Snyder) Date: Wed, 6 May 2015 17:58:07 -0400 Subject: Alcatel-Lucent 7750 Service Router (SR) In-Reply-To: References: Message-ID: <3BB50C80-3ED0-44D7-AFD9-484D7C03833B@gmail.com> We have been using them for almost 8 years now and have been pretty happy. What are you looking to use them for? Sent from my iPhone > On May 6, 2015, at 5:48 PM, Colton Conor wrote: > > I was wondering if anyone was using a Alcatel-Lucent 7750 Service Router > (SR) in their network? How does this platform compare the the Cisco ASR, > Brocade MLXe, and Juniper MX line? From colton.conor at gmail.com Wed May 6 22:00:44 2015 From: colton.conor at gmail.com (Colton Conor) Date: Wed, 6 May 2015 17:00:44 -0500 Subject: Alcatel-Lucent 7750 Service Router (SR) In-Reply-To: <3BB50C80-3ED0-44D7-AFD9-484D7C03833B@gmail.com> References: <3BB50C80-3ED0-44D7-AFD9-484D7C03833B@gmail.com> Message-ID: Taking full BGP routes from 4+ carriers on 10G connections. Why is ALU never mentioned, but Juniper MX and Cisco are all day long? The new 7750 SR-a4 looks like a Juniper MX80 or MX104 killer. On Wed, May 6, 2015 at 4:58 PM, Dan Snyder wrote: > We have been using them for almost 8 years now and have been pretty happy. > What are you looking to use them for? > > Sent from my iPhone > > > On May 6, 2015, at 5:48 PM, Colton Conor wrote: > > > > I was wondering if anyone was using a Alcatel-Lucent 7750 Service Router > > (SR) in their network? How does this platform compare the the Cisco ASR, > > Brocade MLXe, and Juniper MX line? > From surfer at mauigateway.com Wed May 6 22:14:38 2015 From: surfer at mauigateway.com (Scott Weeks) Date: Wed, 6 May 2015 15:14:38 -0700 Subject: Alcatel-Lucent 7750 Service Router (SR) Message-ID: <20150506151438.C491D8C6@m0048141.ppops.net> > On May 6, 2015, at 5:48 PM, Colton Conor wrote: > > I was wondering if anyone was using a > Alcatel-Lucent 7750 Service Router> (SR) > in their network? How does this platform > compare the the Cisco ASR, Brocade MLXe, > and Juniper MX line? --------------------------------- I haven't used them for nearly 5 years now, but at the time they were really good. Likely, they're still the same. Search the NANOG archives, there have been discussions before. Pay attention to the after the sale service stuff in the archives. Also Jared Mauch has a ML for them at puck.nether.net, but it's a really low volume list. ALU engineers hang out there. scott From surfer at mauigateway.com Wed May 6 22:16:42 2015 From: surfer at mauigateway.com (Scott Weeks) Date: Wed, 6 May 2015 15:16:42 -0700 Subject: Alcatel-Lucent 7750 Service Router (SR) Message-ID: <20150506151642.C491D8ED@m0048141.ppops.net> --- colton.conor at gmail.com wrote: From: Colton Conor Why is ALU never mentioned, but Juniper MX and Cisco are all day long? ----------------------------------------- Because they're really expensive, mostly bell head networks use them and we're mostly bell head free on NANOG... >;-) scott From sliplever at gmail.com Wed May 6 22:22:31 2015 From: sliplever at gmail.com (Dan Snyder) Date: Wed, 6 May 2015 18:22:31 -0400 Subject: Alcatel-Lucent 7750 Service Router (SR) In-Reply-To: References: <3BB50C80-3ED0-44D7-AFD9-484D7C03833B@gmail.com> Message-ID: <62174369-9641-45C8-BE0D-CF8955C9AF03@gmail.com> They are definitely good for that. We use them in part of our network for something very similar. I am not sure why they aren't mentioned that much. I know that they have been pretty popular in the past couple years. We are planning on using 7750 SR-a4's in the future but right now we mainly have 7750SR7/12s. Sent from my iPhone > On May 6, 2015, at 6:00 PM, Colton Conor wrote: > > Taking full BGP routes from 4+ carriers on 10G connections. Why is ALU never mentioned, but Juniper MX and Cisco are all day long? > > The new 7750 SR-a4 looks like a Juniper MX80 or MX104 killer. > >> On Wed, May 6, 2015 at 4:58 PM, Dan Snyder wrote: >> We have been using them for almost 8 years now and have been pretty happy. What are you looking to use them for? >> >> Sent from my iPhone >> >> > On May 6, 2015, at 5:48 PM, Colton Conor wrote: >> > >> > I was wondering if anyone was using a Alcatel-Lucent 7750 Service Router >> > (SR) in their network? How does this platform compare the the Cisco ASR, >> > Brocade MLXe, and Juniper MX line? > From colton.conor at gmail.com Wed May 6 22:24:03 2015 From: colton.conor at gmail.com (Colton Conor) Date: Wed, 6 May 2015 17:24:03 -0500 Subject: Alcatel-Lucent 7750 Service Router (SR) In-Reply-To: <62174369-9641-45C8-BE0D-CF8955C9AF03@gmail.com> References: <3BB50C80-3ED0-44D7-AFD9-484D7C03833B@gmail.com> <62174369-9641-45C8-BE0D-CF8955C9AF03@gmail.com> Message-ID: I am worried as most tech's know Cisco and Juniper, so going to ALU would be a learning curve based on replies I am getting off list. On Wed, May 6, 2015 at 5:22 PM, Dan Snyder wrote: > > They are definitely good for that. We use them in part of our network for > something very similar. > > I am not sure why they aren't mentioned that much. I know that they have > been pretty popular in the past couple years. > > We are planning on using 7750 SR-a4's in the future but right now we > mainly have 7750SR7/12s. > > Sent from my iPhone > > On May 6, 2015, at 6:00 PM, Colton Conor wrote: > > Taking full BGP routes from 4+ carriers on 10G connections. Why is ALU > never mentioned, but Juniper MX and Cisco are all day long? > > The new 7750 SR-a4 looks like a Juniper MX80 or MX104 killer. > > On Wed, May 6, 2015 at 4:58 PM, Dan Snyder wrote: > >> We have been using them for almost 8 years now and have been pretty >> happy. What are you looking to use them for? >> >> Sent from my iPhone >> >> > On May 6, 2015, at 5:48 PM, Colton Conor >> wrote: >> > >> > I was wondering if anyone was using a Alcatel-Lucent 7750 Service >> Router >> > (SR) in their network? How does this platform compare the the Cisco ASR, >> > Brocade MLXe, and Juniper MX line? >> > > From surfer at mauigateway.com Wed May 6 22:30:01 2015 From: surfer at mauigateway.com (Scott Weeks) Date: Wed, 6 May 2015 15:30:01 -0700 Subject: Network Segmentation Approaches Message-ID: <20150506153001.C491D9D8@m0048141.ppops.net> --- rsk at gsp.org wrote: From: Rich Kulawiec The first rule in every firewall is of course "deny all" and subsequent rulesets permit only the traffic that is necessary. ------------------------------------ I think you got this backward? That way all traffic is blocked, so none is allowed through. Also, deny by default at the end of the rule set is not the best thing for every network that needs a firewall. Some just want to block bad stuff they see and allow everything else. (And some have stated here that they will block entire countries until their culture changes!) scott From blakjak at blakjak.net Wed May 6 22:35:05 2015 From: blakjak at blakjak.net (Mark Foster) Date: Thu, 07 May 2015 10:35:05 +1200 Subject: Question about co-lo in APAC region In-Reply-To: References: Message-ID: <554A9719.2070000@blakjak.net> I would support this. I've had a hand in supporting infrastructure located in India and even with a relatively competent partner, some challenges in timely issue resolution. My current employer operate facilities in Singapore, Malaysia and China with a lot more success (comparitively speaking). Singapore and Malaysia are heavily favoured due to their large ICT and financial service industries as noted, also their english tends to be excellent and from a telecommunications perspective, they are reasonably well-served. If you want a reference to someone who can help you in SG, MY or CN, you're welcome to contact me off-list. I've also in a past-life worked with a partner in Japan, their service was excellent but there were more language challenges there for us poor sods limited to English. Cheers, Mark. On 7/05/2015 7:39 a.m., Rafael Possamai wrote: > Personal opinion: developing countries tend to have unstable utility > service (power is what matters here), so your DC of choice in India should > be Tier 4 preferably, which are hard to find and really expensive. Budget > allowing, I'd stick to Hong Kong, Shangai or Singapore as you mentioned > initially. These cities have pretty large financial services industries > (which rely heavily on IT & telco in general) and large companies like > Equinix/Digital Realty have already done the heavy lifting for you in terms > of scoping a good location for an APAC datacenter. > > > On Wed, May 6, 2015 at 11:28 AM, c b wrote: > >> This is a pre-project discovery question... any help would be greatly >> appreciated. >> We have upcoming partnerships (opportunities) in APAC. The original plan >> was to place the hub in Singapore. Just weeks before everyone was ready to >> begin the RFP, it turns out that one of our partner businesses owns a Co-Lo >> in India. Not sure what the name or the size of this business is yet. While >> it would be nice to take advantage of this, we have potential partnerships >> in China and other areas of APAC in development... we are hesitating to put >> our APAC hub in India just based on latency and where the undersea cables >> run. >> So, I'm reaching out to NANOG... some of you guys have either worked with >> businesses (or work in provider space) in both India and Singapore (and >> elsewhere, such as Japan). Is there a clear reason to use/not-use India as >> a hub? What would the pros/cons be? Is there a clear advantage to using >> Singapore as we originally planned? >> Again, we appreciate the feedback. >> LFoD From randy at psg.com Wed May 6 22:56:25 2015 From: randy at psg.com (Randy Bush) Date: Thu, 07 May 2015 07:56:25 +0900 Subject: link avoidance Message-ID: a fellow researcher wants > to make the case that in some scenarios it is very important for a > network operator to be able to specify that traffic should *not* > traverse a certain switch/link/group of switches/group of links > (that's true right?). Could you give some examples? Perhaps point > me to relevant references? if so, why? security? congestion? other? but is it common? and, if so, how do you do it? randy From rsk at gsp.org Wed May 6 23:05:59 2015 From: rsk at gsp.org (Rich Kulawiec) Date: Wed, 6 May 2015 19:05:59 -0400 Subject: Network Segmentation Approaches In-Reply-To: <20150506153001.C491D9D8@m0048141.ppops.net> References: <20150506153001.C491D9D8@m0048141.ppops.net> Message-ID: <20150506230558.GA11042@gsp.org> On Wed, May 06, 2015 at 03:30:01PM -0700, Scott Weeks wrote: > --- rsk at gsp.org wrote: > From: Rich Kulawiec > > The first rule in every firewall is of course > "deny all" and subsequent rulesets permit only > the traffic that is necessary. > ------------------------------------ > > I think you got this backward? That way all > traffic is blocked, so none is allowed through. Nope, I said exactly what I intended (and what I do, in practice). Doing so forces one to understand in detail what traffic actually needs to pass in/out and to craft specific rules for it. This in turn helps avoid making mistake #1: The Six Dumbest Ideas in Computer Security http://www.ranum.com/security/computer_security/editorials/dumb/ ---rsk From aj at jonesy.com.au Wed May 6 23:08:38 2015 From: aj at jonesy.com.au (Andrew Jones) Date: Thu, 07 May 2015 09:08:38 +1000 Subject: Network Segmentation Approaches In-Reply-To: <20150506153001.C491D9D8@m0048141.ppops.net> References: <20150506153001.C491D9D8@m0048141.ppops.net> Message-ID: <2eaed6030555b449206bc604b704b5c1@jonesy.com.au> It depends on the software used and implementation. Many rulesets for pf on BSD start with 'block in on interfaceX' for instance, because it uses a "last match wins" system, unless you use the 'quick' keyword to make rule processing stop if that rule matches. Andrew On 07.05.2015 08:30, Scott Weeks wrote: > --- rsk at gsp.org wrote: > From: Rich Kulawiec > > The first rule in every firewall is of course > "deny all" and subsequent rulesets permit only > the traffic that is necessary. > ------------------------------------ > > > I think you got this backward? That way all > traffic is blocked, so none is allowed through. > Also, deny by default at the end of the rule > set is not the best thing for every network > that needs a firewall. Some just want to block > bad stuff they see and allow everything else. > (And some have stated here that they will block > entire countries until their culture changes!) > > scott From cvuljanic at gmail.com Wed May 6 23:13:45 2015 From: cvuljanic at gmail.com (Craig) Date: Wed, 6 May 2015 19:13:45 -0400 Subject: Alcatel-Lucent 7750 Service Router (SR) In-Reply-To: References: <3BB50C80-3ED0-44D7-AFD9-484D7C03833B@gmail.com> <62174369-9641-45C8-BE0D-CF8955C9AF03@gmail.com> Message-ID: If you know Juniper and Cisco, the learning curve isn't so bad to pick up the ALU CLI, after working with it for a brief time, you catch on quickly. Their products are quite impressive, and a # of the carriers, are moving to them and some have already moved to them and are quite happy with their decision. On Wed, May 6, 2015 at 6:24 PM, Colton Conor wrote: > I am worried as most tech's know Cisco and Juniper, so going to ALU would > be a learning curve based on replies I am getting off list. > > On Wed, May 6, 2015 at 5:22 PM, Dan Snyder wrote: > > > > > They are definitely good for that. We use them in part of our network for > > something very similar. > > > > I am not sure why they aren't mentioned that much. I know that they have > > been pretty popular in the past couple years. > > > > We are planning on using 7750 SR-a4's in the future but right now we > > mainly have 7750SR7/12s. > > > > Sent from my iPhone > > > > On May 6, 2015, at 6:00 PM, Colton Conor wrote: > > > > Taking full BGP routes from 4+ carriers on 10G connections. Why is ALU > > never mentioned, but Juniper MX and Cisco are all day long? > > > > The new 7750 SR-a4 looks like a Juniper MX80 or MX104 killer. > > > > On Wed, May 6, 2015 at 4:58 PM, Dan Snyder wrote: > > > >> We have been using them for almost 8 years now and have been pretty > >> happy. What are you looking to use them for? > >> > >> Sent from my iPhone > >> > >> > On May 6, 2015, at 5:48 PM, Colton Conor > >> wrote: > >> > > >> > I was wondering if anyone was using a Alcatel-Lucent 7750 Service > >> Router > >> > (SR) in their network? How does this platform compare the the Cisco > ASR, > >> > Brocade MLXe, and Juniper MX line? > >> > > > > > From sf at lists.esoteric.ca Wed May 6 23:22:15 2015 From: sf at lists.esoteric.ca (Stephen Fulton) Date: Wed, 06 May 2015 19:22:15 -0400 Subject: Alcatel-Lucent 7750 Service Router (SR) In-Reply-To: References: <3BB50C80-3ED0-44D7-AFD9-484D7C03833B@gmail.com> <62174369-9641-45C8-BE0D-CF8955C9AF03@gmail.com> Message-ID: <554AA227.2030908@lists.esoteric.ca> What's the price point of an SR-A4? Comparable to the MX104 or ASR9001? -- Stephen On 2015-05-06 7:13 PM, Craig wrote: > If you know Juniper and Cisco, the learning curve isn't so bad to pick up > the ALU CLI, after working with it for a brief time, you catch on quickly. > Their products are quite impressive, and a # of the carriers, are moving to > them and some have already moved to them and are quite happy with their > decision. > > > On Wed, May 6, 2015 at 6:24 PM, Colton Conor wrote: > >> I am worried as most tech's know Cisco and Juniper, so going to ALU would >> be a learning curve based on replies I am getting off list. >> >> On Wed, May 6, 2015 at 5:22 PM, Dan Snyder wrote: >> >>> >>> They are definitely good for that. We use them in part of our network for >>> something very similar. >>> >>> I am not sure why they aren't mentioned that much. I know that they have >>> been pretty popular in the past couple years. >>> >>> We are planning on using 7750 SR-a4's in the future but right now we >>> mainly have 7750SR7/12s. >>> >>> Sent from my iPhone >>> >>> On May 6, 2015, at 6:00 PM, Colton Conor wrote: >>> >>> Taking full BGP routes from 4+ carriers on 10G connections. Why is ALU >>> never mentioned, but Juniper MX and Cisco are all day long? >>> >>> The new 7750 SR-a4 looks like a Juniper MX80 or MX104 killer. >>> >>> On Wed, May 6, 2015 at 4:58 PM, Dan Snyder wrote: >>> >>>> We have been using them for almost 8 years now and have been pretty >>>> happy. What are you looking to use them for? >>>> >>>> Sent from my iPhone >>>> >>>>> On May 6, 2015, at 5:48 PM, Colton Conor >>>> wrote: >>>>> >>>>> I was wondering if anyone was using a Alcatel-Lucent 7750 Service >>>> Router >>>>> (SR) in their network? How does this platform compare the the Cisco >> ASR, >>>>> Brocade MLXe, and Juniper MX line? >>>> >>> >>> >> From bill at herrin.us Wed May 6 23:36:50 2015 From: bill at herrin.us (William Herrin) Date: Wed, 6 May 2015 19:36:50 -0400 Subject: link avoidance In-Reply-To: References: Message-ID: On Wed, May 6, 2015 at 6:56 PM, Randy Bush wrote: > a fellow researcher wants > > > to make the case that in some scenarios it is very important for a > > network operator to be able to specify that traffic should *not* > > traverse a certain switch/link/group of switches/group of links > > (that's true right?). Could you give some examples? Perhaps point > > me to relevant references? > > if so, why? security? congestion? other? but is it common? and, if > so, how do you do it? Hi Randy, Depends on the context of the question. There's a simple concept a surprising number of routing researchers don't fully grasp: we like to be paid. Scenario: a free peer and a paying customer can swap packets via my links but two free peers may not. A free peer definitely should not have access to the upstream transit links I have to buy. If nobody is paying me for that packet, I'd like it to take the long way around. Any way but through my network. And yes, as you know it is very common for ISPs to strenuously disapprove of unpaid transit. And we mainly do it by limiting the propagation of free peer routes we received via BGP. Seems like this should be so obvious as to need no mention. It's not. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: From matthew at matthew.at Wed May 6 23:41:01 2015 From: matthew at matthew.at (Matthew Kaufman) Date: Wed, 06 May 2015 16:41:01 -0700 Subject: link avoidance In-Reply-To: References: Message-ID: <554AA68D.9060909@matthew.at> On 5/6/2015 3:56 PM, Randy Bush wrote: > a fellow researcher wants > > > to make the case that in some scenarios it is very important for a > > network operator to be able to specify that traffic should *not* > > traverse a certain switch/link/group of switches/group of links > > (that's true right?). Could you give some examples? Perhaps point > > me to relevant references? > > if so, why? security? congestion? other? but is it common? and, if > so, how do you do it? > > randy I don't think it is common, but I have a microwave network made up of a combination of license-free links and amateur radio band links (where no commercial traffic is permitted). For now the ham-band links are stubs, so that's easy. But we're looking at using MPLS with link coloring so that as we do start to get redundant paths available, we can ensure that non-ham-radio traffic stays off the ham-band links. Matthew Kaufman From owen at delong.com Wed May 6 23:42:28 2015 From: owen at delong.com (Owen DeLong) Date: Wed, 6 May 2015 16:42:28 -0700 Subject: link avoidance In-Reply-To: References: Message-ID: The most common place where I have encountered that would involve differing AUPs on different links. For example, if one has a link which is built on an amateur radio layer 1, one cannot carry commercial, pornographic, encrypted, or certain other kinds of traffic on that link. I believe Internet2 vs. public transit may also pose some such requirements. Other situations I?ve seen involve data privacy concerns and/or security zone issues. Common? Not in my experience. Usually done with a combination of ACLs, Routing Policy, etc. Owen > On May 6, 2015, at 3:56 PM, Randy Bush wrote: > > a fellow researcher wants > >> to make the case that in some scenarios it is very important for a >> network operator to be able to specify that traffic should *not* >> traverse a certain switch/link/group of switches/group of links >> (that's true right?). Could you give some examples? Perhaps point >> me to relevant references? > > if so, why? security? congestion? other? but is it common? and, if > so, how do you do it? > > randy From mysidia at gmail.com Thu May 7 00:28:43 2015 From: mysidia at gmail.com (Jimmy Hess) Date: Wed, 6 May 2015 19:28:43 -0500 Subject: link avoidance In-Reply-To: <554AA68D.9060909@matthew.at> References: <554AA68D.9060909@matthew.at> Message-ID: On Wed, May 6, 2015 at 6:41 PM, Matthew Kaufman wrote: > On 5/6/2015 3:56 PM, Randy Bush wrote: > I don't think it is common, but I have a microwave network made up of a > combination of license-free links and amateur radio band links (where no > commercial traffic is permitted). For now the ham-band links are stubs, so Are such Ham links actually of any real use, since encoded traffic such as SSH/SSL would be verboten, due to Part97 rules against transmitting any message encoded in order to obscure the message? Also, with general network traffic.. If someone wants to request a Google search. There is no way of a router knowing if the requestor is sending the packet for a commercial purpose or for a non-pecuniary allowed usage, until TCP gets some new packet fields... You can be visiting somepizzaplace.example.com, And it's non-commercial allowed use, if you're ordering a pizza for personal consumption, But those same packets are prohibited pecuniary use, if sending those packets to order a pizza to share with a business client. > that's easy. But we're looking at using MPLS with link coloring so that as Perhaps a browser plugin to add a 'Selection' dropdown for each Web Browser Tab and have a RESTful API to send connection information from the client to an Openflow controller for deciding which forwarding label to push at ingress. > Matthew Kaufman -- -JH From morrowc.lists at gmail.com Thu May 7 00:35:46 2015 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Wed, 6 May 2015 20:35:46 -0400 Subject: link avoidance In-Reply-To: References: Message-ID: On Wed, May 6, 2015 at 6:56 PM, Randy Bush wrote: > a fellow researcher wants > > > to make the case that in some scenarios it is very important for a > > network operator to be able to specify that traffic should *not* > > traverse a certain switch/link/group of switches/group of links > > (that's true right?). Could you give some examples? Perhaps point > > me to relevant references? > > if so, why? security? congestion? other? but is it common? and, if 'Level3 Maintenance for Fiber path X on date Y' where 'fiber path x' is one of your paths from A to B. Gracefully move traffic (isis/ospf/rip/etc metric jackery), return traffic when the crisis is past. > so, how do you do it? > > randy From surfer at mauigateway.com Thu May 7 00:58:31 2015 From: surfer at mauigateway.com (Scott Weeks) Date: Wed, 6 May 2015 17:58:31 -0700 Subject: Network Segmentation Approaches Message-ID: <20150506175831.C4959377@m0005311.ppops.net> From: Rich Kulawiec On Wed, May 06, 2015 at 03:30:01PM -0700, Scott Weeks wrote: > From: Rich Kulawiec > > The first rule in every firewall is of course > "deny all" and subsequent rulesets permit only > the traffic that is necessary. > ------------------------------------ > > I think you got this backward? That way all > traffic is blocked, so none is allowed through. Nope, I said exactly what I intended (and what I do, in practice). Doing so forces one to understand in detail what traffic actually needs to pass in/out and to craft specific rules for it. This in turn helps avoid making mistake #1: The Six Dumbest Ideas in Computer Security http://www.ranum.com/security/computer_security/editorials/dumb/ ----------------------------------------------------- After reading your emails all these years, I figured you meant it the way you wrote it. When you wrote "...subsequent rulesets permit only the traffic that is necessary" I misunderstood and thought you meant rules put in after the default deny, which are useless. But by subsequent rulesets you meant rule sets put in later in time and above the deny all not after the deny all. Small confusion over wording... :-) scott From rdobbins at arbor.net Thu May 7 01:00:11 2015 From: rdobbins at arbor.net (Roland Dobbins) Date: Thu, 07 May 2015 08:00:11 +0700 Subject: Question about co-lo in APAC region In-Reply-To: <970945E55BFD8C4EA4CAD74B647A9DC0A62C99E4@USIDCWVEMBX10.corp.global.level3.com> References: <970945E55BFD8C4EA4CAD74B647A9DC0A62C99E4@USIDCWVEMBX10.corp.global.level3.com> Message-ID: On 7 May 2015, at 2:36, Siegel, David wrote: > By comparison, Singapore is a relatively easy country to get a license > to operate a telecommunications business. +1 From an overall connectivity, stability, and technical collaboration standpoint, Singapore is generally a better choice, as well. ----------------------------------- Roland Dobbins From surfer at mauigateway.com Thu May 7 01:02:49 2015 From: surfer at mauigateway.com (Scott Weeks) Date: Wed, 6 May 2015 18:02:49 -0700 Subject: Network Segmentation Approaches Message-ID: <20150506180249.C495935F@m0005311.ppops.net> On 07.05.2015 08:30, Scott Weeks wrote: > --- rsk at gsp.org wrote: > From: Rich Kulawiec > > The first rule in every firewall is of course > "deny all" and subsequent rulesets permit only > the traffic that is necessary. > ------------------------------------ > > > I think you got this backward? That way all > traffic is blocked, so none is allowed through. > Also, deny by default at the end of the rule > set is not the best thing for every network > that needs a firewall. Some just want to block > bad stuff they see and allow everything else. > (And some have stated here that they will block > entire countries until their culture changes!) --------------------------------------- --- aj at jonesy.com.au wrote: From: Andrew Jones It depends on the software used and implementation. Many rulesets for pf on BSD start with 'block in on interfaceX' for instance, because it uses a "last match wins" system, unless you use the 'quick' keyword to make rule processing stop if that rule matches. ----------------------------------------- I was assuming stop looking on first match. So, "deny ip any any" blocks everything at the very beginning. scott From swhyte at gmail.com Thu May 7 01:05:06 2015 From: swhyte at gmail.com (Scott Whyte) Date: Wed, 06 May 2015 18:05:06 -0700 Subject: link avoidance In-Reply-To: References: Message-ID: <554ABA42.50905@gmail.com> On 5/6/15 15:56, Randy Bush wrote: > a fellow researcher wants > > > to make the case that in some scenarios it is very important for a > > network operator to be able to specify that traffic should *not* > > traverse a certain switch/link/group of switches/group of links > > (that's true right?). Could you give some examples? Perhaps point > > me to relevant references? > > if so, why? security? congestion? other? but is it common? and, if > so, how do you do it? My experience has been with MPLS overlays. Availability: During maintenance windows, moving high-value traffic away from potential outages while keeping the tunnels full of BE; manually manipulating MPLS tunnel affinities (though this could be automated fairly easily). Congestion: Whenever traffic load spikes past a threshold; diffserv-aware TE to prevent certain classes of traffic from routing over links with limited bandwidth, handled automatically via auto-bw. Preventing non-optimal tunnel paths. No transoceanic trombones, please; MPLS link affinities designed into the network. -Scott From morrowc.lists at gmail.com Thu May 7 02:52:28 2015 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Wed, 6 May 2015 22:52:28 -0400 Subject: Fixing Google geolocation screwups In-Reply-To: <5549C064.4010904@web2objects.com> References: <20150505210746.GH22158@hezmatt.org> <20150506005623.72EF02DCDC31@rock.dv.isc.org> <20150506013634.GV22158@hezmatt.org> <5549C064.4010904@web2objects.com> Message-ID: On Wed, May 6, 2015 at 3:19 AM, Fred Hollis wrote: > Honestly, I lost patience "the system learning the proper location of the > IPv6 block". I have a very similar problem to the OP since 4-5 months, > submitted this IP correction form multiple times... nothing changed. > This is *very* annoying. > > Yes, my whois/SWIP is perfectly fine, every other geo ip database is showing > correct location. > which block fred? > > On 06.05.2015 at 03:36 Matt Palmer wrote: >> >> On Wed, May 06, 2015 at 10:56:22AM +1000, Mark Andrews wrote: >>> >>> In message <20150505210746.GH22158 at hezmatt.org>, Matt Palmer writes: >>>> >>>> On Tue, May 05, 2015 at 12:03:23PM -0400, Luan Nguyen wrote: >>>>> >>>>> There's a form here - https://support.google.com/websearch/contact/ip >>>>> But google is pretty smart, its systems will learn the correct >>>>> geolocation >>>>> over time... >>>> >>>> >>>> That'd be quite a trick, given that the netblock practically can't be >>>> used >>>> at all with Google services. >>> >>> >>> One would expect support.google.com to not be geo blocked just like >>> postmaster@ should not be filtered. That said they can always >>> disable IPv6 temporarially (or just firewall off the IPv6 instance >>> of support.google.com and have the browser fallback to IPv4) and >>> reach support.google.com over IPv4 to lodge the complaint. >> >> >> I was specifically responding to the suggestion that Google would >> automagically "learn" the correct location of the netblock, presumably >> based >> on the characteristics of requests coming from the range. Being >> explicitly >> told that a given netblock is in a given location (as effective, or >> otherwise, as that may be) doesn't really fit the description of "systems >> [learning] the correct geolocation over time". >> >> - Matt >> > From charles at thefnf.org Thu May 7 03:14:39 2015 From: charles at thefnf.org (Charles Wyble) Date: Wed, 6 May 2015 22:14:39 -0500 Subject: IP DSCP across the Internet In-Reply-To: <5549A8D2.9010702@seacom.mu> References: <5549A8D2.9010702@seacom.mu> Message-ID: I presume nothing is honored. I just encapsulate everything if I'm crossing networks outside my corporate WAN. Amazing how handy openvpn with no crypto is. :) -----Original Message----- From: "Mark Tinka" Sent: ?5/?6/?2015 12:39 AM To: "Ramy Hashish" ; "nanog at nanog.org" Subject: Re: IP DSCP across the Internet On 5/May/15 12:27, Ramy Hashish wrote: > Good day all, > > A simple question, does Internet trust IP DSCP marking? Assume two ASs > connected through two tier 1 networks, will the tier one networks trust any > DSCP markings done from an AS to the other? I wouldn't bet on it. Some providers honor, most remark. We remark. We can only honor DSCP values on private circuits (l2vpn, l3vpn, that sort o' thing). Mark. !DSPAM:5549a92270553521610807! From bob at FiberInternetCenter.com Thu May 7 03:53:38 2015 From: bob at FiberInternetCenter.com (Bob Evans) Date: Wed, 6 May 2015 20:53:38 -0700 Subject: Alcatel-Lucent 7750 Service Router (SR) In-Reply-To: <554AA227.2030908@lists.esoteric.ca> References: <3BB50C80-3ED0-44D7-AFD9-484D7C03833B@gmail.com> <62174369-9641-45C8-BE0D-CF8955C9AF03@gmail.com> <554AA227.2030908@lists.esoteric.ca> Message-ID: <9652844c20749360e01dd56ec4d6ff8c.squirrel@66.201.44.180> I will be getting one to try. I am pretty sure it will support the ol' "show ? , config ?" If not that might be a problem :-) Thank You Bob Evans CTO > What's the price point of an SR-A4? Comparable to the MX104 or ASR9001? > > -- Stephen > > On 2015-05-06 7:13 PM, Craig wrote: >> If you know Juniper and Cisco, the learning curve isn't so bad to pick >> up >> the ALU CLI, after working with it for a brief time, you catch on >> quickly. >> Their products are quite impressive, and a # of the carriers, are moving >> to >> them and some have already moved to them and are quite happy with their >> decision. >> >> >> On Wed, May 6, 2015 at 6:24 PM, Colton Conor >> wrote: >> >>> I am worried as most tech's know Cisco and Juniper, so going to ALU >>> would >>> be a learning curve based on replies I am getting off list. >>> >>> On Wed, May 6, 2015 at 5:22 PM, Dan Snyder wrote: >>> >>>> >>>> They are definitely good for that. We use them in part of our network >>>> for >>>> something very similar. >>>> >>>> I am not sure why they aren't mentioned that much. I know that they >>>> have >>>> been pretty popular in the past couple years. >>>> >>>> We are planning on using 7750 SR-a4's in the future but right now we >>>> mainly have 7750SR7/12s. >>>> >>>> Sent from my iPhone >>>> >>>> On May 6, 2015, at 6:00 PM, Colton Conor >>>> wrote: >>>> >>>> Taking full BGP routes from 4+ carriers on 10G connections. Why is ALU >>>> never mentioned, but Juniper MX and Cisco are all day long? >>>> >>>> The new 7750 SR-a4 looks like a Juniper MX80 or MX104 killer. >>>> >>>> On Wed, May 6, 2015 at 4:58 PM, Dan Snyder >>>> wrote: >>>> >>>>> We have been using them for almost 8 years now and have been pretty >>>>> happy. What are you looking to use them for? >>>>> >>>>> Sent from my iPhone >>>>> >>>>>> On May 6, 2015, at 5:48 PM, Colton Conor >>>>> wrote: >>>>>> >>>>>> I was wondering if anyone was using a Alcatel-Lucent 7750 Service >>>>> Router >>>>>> (SR) in their network? How does this platform compare the the Cisco >>> ASR, >>>>>> Brocade MLXe, and Juniper MX line? >>>>> >>>> >>>> >>> > From ultimatebruce at gmail.com Thu May 7 04:08:06 2015 From: ultimatebruce at gmail.com (Bruce) Date: Thu, 7 May 2015 14:08:06 +1000 Subject: Alcatel-Lucent 7750 Service Router (SR) In-Reply-To: <9652844c20749360e01dd56ec4d6ff8c.squirrel@66.201.44.180> References: <3BB50C80-3ED0-44D7-AFD9-484D7C03833B@gmail.com> <62174369-9641-45C8-BE0D-CF8955C9AF03@gmail.com> <554AA227.2030908@lists.esoteric.ca> <9652844c20749360e01dd56ec4d6ff8c.squirrel@66.201.44.180> Message-ID: that second command is "admin display-config" or "admin display-config | match xxxx" cheers On Thu, May 7, 2015 at 1:53 PM, Bob Evans wrote: > > I will be getting one to try. I am pretty sure it will support the ol' > "show ? , config ?" If not that might be a problem :-) > > Thank You > Bob Evans > CTO > > > > > > What's the price point of an SR-A4? Comparable to the MX104 or ASR9001? > > > > -- Stephen > > > > On 2015-05-06 7:13 PM, Craig wrote: > >> If you know Juniper and Cisco, the learning curve isn't so bad to pick > >> up > >> the ALU CLI, after working with it for a brief time, you catch on > >> quickly. > >> Their products are quite impressive, and a # of the carriers, are moving > >> to > >> them and some have already moved to them and are quite happy with their > >> decision. > >> > >> > >> On Wed, May 6, 2015 at 6:24 PM, Colton Conor > >> wrote: > >> > >>> I am worried as most tech's know Cisco and Juniper, so going to ALU > >>> would > >>> be a learning curve based on replies I am getting off list. > >>> > >>> On Wed, May 6, 2015 at 5:22 PM, Dan Snyder > wrote: > >>> > >>>> > >>>> They are definitely good for that. We use them in part of our network > >>>> for > >>>> something very similar. > >>>> > >>>> I am not sure why they aren't mentioned that much. I know that they > >>>> have > >>>> been pretty popular in the past couple years. > >>>> > >>>> We are planning on using 7750 SR-a4's in the future but right now we > >>>> mainly have 7750SR7/12s. > >>>> > >>>> Sent from my iPhone > >>>> > >>>> On May 6, 2015, at 6:00 PM, Colton Conor > >>>> wrote: > >>>> > >>>> Taking full BGP routes from 4+ carriers on 10G connections. Why is ALU > >>>> never mentioned, but Juniper MX and Cisco are all day long? > >>>> > >>>> The new 7750 SR-a4 looks like a Juniper MX80 or MX104 killer. > >>>> > >>>> On Wed, May 6, 2015 at 4:58 PM, Dan Snyder > >>>> wrote: > >>>> > >>>>> We have been using them for almost 8 years now and have been pretty > >>>>> happy. What are you looking to use them for? > >>>>> > >>>>> Sent from my iPhone > >>>>> > >>>>>> On May 6, 2015, at 5:48 PM, Colton Conor > >>>>> wrote: > >>>>>> > >>>>>> I was wondering if anyone was using a Alcatel-Lucent 7750 Service > >>>>> Router > >>>>>> (SR) in their network? How does this platform compare the the Cisco > >>> ASR, > >>>>>> Brocade MLXe, and Juniper MX line? > >>>>> > >>>> > >>>> > >>> > > > > > From bedard.phil at gmail.com Thu May 7 04:29:28 2015 From: bedard.phil at gmail.com (Phil Bedard) Date: Thu, 7 May 2015 00:29:28 -0400 Subject: Alcatel-Lucent 7750 Service Router (SR) In-Reply-To: <9652844c20749360e01dd56ec4d6ff8c.squirrel@66.201.44.180> References: <3BB50C80-3ED0-44D7-AFD9-484D7C03833B@gmail.com> <62174369-9641-45C8-BE0D-CF8955C9AF03@gmail.com> <554AA227.2030908@lists.esoteric.ca> <9652844c20749360e01dd56ec4d6ff8c.squirrel@66.201.44.180> Message-ID: <554aea4a.762a8c0a.7549.3975@mx.google.com> The show stuff is certainly there but the config is a bit different. You may have to get used to using the "info" command. :) They also use logical IP interfaces which are then tied to physical, you don't directly configure L3 on a physical interface. You also have designations between service and network physical interfaces, although nowadays they can be set as "hybrid.". It's really pretty simple if you are used to a Cisco or Juniper. They have tab and ? completion now for both commands as well as elements similar to Junos which is helpful. Phil -----Original Message----- From: "Bob Evans" Sent: ?5/?6/?2015 11:55 PM To: "nanog at nanog.org" Subject: Re: Alcatel-Lucent 7750 Service Router (SR) I will be getting one to try. I am pretty sure it will support the ol' "show ? , config ?" If not that might be a problem :-) Thank You Bob Evans CTO > What's the price point of an SR-A4? Comparable to the MX104 or ASR9001? > > -- Stephen > > On 2015-05-06 7:13 PM, Craig wrote: >> If you know Juniper and Cisco, the learning curve isn't so bad to pick >> up >> the ALU CLI, after working with it for a brief time, you catch on >> quickly. >> Their products are quite impressive, and a # of the carriers, are moving >> to >> them and some have already moved to them and are quite happy with their >> decision. >> >> >> On Wed, May 6, 2015 at 6:24 PM, Colton Conor >> wrote: >> >>> I am worried as most tech's know Cisco and Juniper, so going to ALU >>> would >>> be a learning curve based on replies I am getting off list. >>> >>> On Wed, May 6, 2015 at 5:22 PM, Dan Snyder wrote: >>> >>>> >>>> They are definitely good for that. We use them in part of our network >>>> for >>>> something very similar. >>>> >>>> I am not sure why they aren't mentioned that much. I know that they >>>> have >>>> been pretty popular in the past couple years. >>>> >>>> We are planning on using 7750 SR-a4's in the future but right now we >>>> mainly have 7750SR7/12s. >>>> >>>> Sent from my iPhone >>>> >>>> On May 6, 2015, at 6:00 PM, Colton Conor >>>> wrote: >>>> >>>> Taking full BGP routes from 4+ carriers on 10G connections. Why is ALU >>>> never mentioned, but Juniper MX and Cisco are all day long? >>>> >>>> The new 7750 SR-a4 looks like a Juniper MX80 or MX104 killer. >>>> >>>> On Wed, May 6, 2015 at 4:58 PM, Dan Snyder >>>> wrote: >>>> >>>>> We have been using them for almost 8 years now and have been pretty >>>>> happy. What are you looking to use them for? >>>>> >>>>> Sent from my iPhone >>>>> >>>>>> On May 6, 2015, at 5:48 PM, Colton Conor >>>>> wrote: >>>>>> >>>>>> I was wondering if anyone was using a Alcatel-Lucent 7750 Service >>>>> Router >>>>>> (SR) in their network? How does this platform compare the the Cisco >>> ASR, >>>>>> Brocade MLXe, and Juniper MX line? >>>>> >>>> >>>> >>> > From tim at pelican.org Thu May 7 09:12:11 2015 From: tim at pelican.org (Tim Franklin) Date: Thu, 7 May 2015 10:12:11 +0100 (BST) Subject: Alcatel-Lucent 7750 Service Router (SR) In-Reply-To: References: <3BB50C80-3ED0-44D7-AFD9-484D7C03833B@gmail.com> <62174369-9641-45C8-BE0D-CF8955C9AF03@gmail.com> Message-ID: <205396510.16732.1430989931013.JavaMail.zimbra@pelican.org> > I am worried as most tech's know Cisco and Juniper, so going to ALU would > be a learning curve based on replies I am getting off list. It's definitely quite different from the CLI. I'm still dabbling, but the guys here who have been through the training and are immersed in it really like it. We're using a couple for feature-rich BNG - lots of MLPPP at high bandwidths (for broadband), heavyweight QoS, BGP to the CE, etc. It's very controllable by RADIUS - template configs that you can fill in the values for, rather than the Cisco approach of AVPs with pages of config in. ALU have an e-learning "SR-OS introduction" course, which is going down pretty well for jump-starting our Ops people. Regards, Tim. From jwbensley at gmail.com Thu May 7 09:12:33 2015 From: jwbensley at gmail.com (James Bensley) Date: Thu, 7 May 2015 10:12:33 +0100 Subject: IP DSCP across the Internet In-Reply-To: References: Message-ID: On 6 May 2015 at 03:27, Blake Dunlap wrote: > If there isn't a specific peering agreement which sets up DSCP marks > with your Z side, you're going to have a bad time doing anything other > than remarking to 0. > > -Blake This. You can't really put SLAs on traffic that has to egress/ingress the Internet, if you try to you're asking for trouble, so we simply remark to 0 on all inbound traffic. Jamas. From swmike at swm.pp.se Thu May 7 09:32:52 2015 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Thu, 7 May 2015 11:32:52 +0200 (CEST) Subject: IP DSCP across the Internet In-Reply-To: <5549A9EE.8040805@seacom.mu> References: <5549A9EE.8040805@seacom.mu> Message-ID: On Wed, 6 May 2015, Mark Tinka wrote: > With color-aware policing toward a customer in Uganda, any traffic > coming from that peer in South Africa was getting dropped toward that > customer in Uganda. After a very odd sequence of troubleshooting events, > we found that the AF DSCP alues being set by the peer in South Africa > (and us passing them due to the old kit not being able to remark on > ingress) was causing the color-aware policer in Uganda to drop traffic > toward the customer there. I have heard similar stories where game traffic ended up in a 100 kilobit/s VoIP queue which worked fine until there were a lot of nearby players in the game, then things started working very badly. Also nice corner case :P So yes, setting all external Internet traffic to DSCP=BE (0) is something one wants to do. -- Mikael Abrahamsson email: swmike at swm.pp.se From mark.tinka at seacom.mu Thu May 7 10:05:42 2015 From: mark.tinka at seacom.mu (Mark Tinka) Date: Thu, 7 May 2015 12:05:42 +0200 Subject: IP DSCP across the Internet In-Reply-To: References: Message-ID: <554B38F6.7020400@seacom.mu> On 7/May/15 11:12, James Bensley wrote: > > > This. > > You can't really put SLAs on traffic that has to egress/ingress the > Internet, if you try to you're asking for trouble, so we simply remark > to 0 on all inbound traffic. And this is what sales and marketing droids don't get - so-called "Premium Internet" products abound that don't really mean anything. The competition that offer these products are basically hoping nothing happens, and that when it does, it seems as palatable as flying First Class in a plane that's going down. Focus energies on other things, I say... the customers that buy such services should know better, but alas... Mark. From nanog at ics-il.net Thu May 7 11:46:00 2015 From: nanog at ics-il.net (Mike Hammett) Date: Thu, 7 May 2015 06:46:00 -0500 (CDT) Subject: IP DSCP across the Internet In-Reply-To: Message-ID: <11937411.8601.1430999138395.JavaMail.mhammett@ThunderFuck> That sounds like a rather poor implementation. What if they had more than one VoIP call? Seems like this thread has more FUD than real examples. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com ----- Original Message ----- From: "Mikael Abrahamsson" To: "Mark Tinka" Cc: "nanog list" Sent: Thursday, May 7, 2015 4:32:52 AM Subject: Re: IP DSCP across the Internet On Wed, 6 May 2015, Mark Tinka wrote: > With color-aware policing toward a customer in Uganda, any traffic > coming from that peer in South Africa was getting dropped toward that > customer in Uganda. After a very odd sequence of troubleshooting events, > we found that the AF DSCP alues being set by the peer in South Africa > (and us passing them due to the old kit not being able to remark on > ingress) was causing the color-aware policer in Uganda to drop traffic > toward the customer there. I have heard similar stories where game traffic ended up in a 100 kilobit/s VoIP queue which worked fine until there were a lot of nearby players in the game, then things started working very badly. Also nice corner case :P So yes, setting all external Internet traffic to DSCP=BE (0) is something one wants to do. -- Mikael Abrahamsson email: swmike at swm.pp.se From rsk at gsp.org Thu May 7 12:12:54 2015 From: rsk at gsp.org (Rich Kulawiec) Date: Thu, 7 May 2015 08:12:54 -0400 Subject: Network Segmentation Approaches In-Reply-To: <20150506175831.C4959377@m0005311.ppops.net> References: <20150506175831.C4959377@m0005311.ppops.net> Message-ID: <20150507121254.GA26854@gsp.org> Ah...got it, this was sloppy phrasing on my part. I meant "first" in the sense of "first rule that one should write". Depending on the firewall type/implementation, that might be the rule that's lexically first or last (or maybe somewhere else). ---rsk From bedard.phil at gmail.com Thu May 7 13:16:48 2015 From: bedard.phil at gmail.com (Phil Bedard) Date: Thu, 07 May 2015 09:16:48 -0400 Subject: Alcatel-Lucent 7750 Service Router (SR) In-Reply-To: References: Message-ID: Forgot to send this yesterday? We use them in our networks along with ASR9Ks and MXs. There are a lot of them deployed around the world doing very similar things as ASRs and MXs. The config is more like Juniper than Cisco IMHO. Being kind of the ?3rd? vendor they have a tendency to implement features proposed by both Cisco and Juniper faster than Cisco and Juniper when proposed by the other vendor. For instance Segment Routing is a Cisco thing, but ALU has already implemented it in their latest 13.0 software, Juniper is sort of dragging their feet on it because it?s a Cisco thing. Same goes for NG-MVPN (BGP signaled multicast VPN). Cisco dragged their feet on it because it was a Juniper thing, ALU had no issues implementing it much sooner. Most of ALUs innovation is on the MPLS services side. We use them for business VPN (L2 and L3) but the underlying protocols are all standard stuff and interoperate with everything else. Phil -----Original Message----- From: Colton Conor Date: Wednesday, May 6, 2015 at 17:48 To: NANOG Subject: Alcatel-Lucent 7750 Service Router (SR) >I was wondering if anyone was using a Alcatel-Lucent 7750 Service Router >(SR) in their network? How does this platform compare the the Cisco ASR, >Brocade MLXe, and Juniper MX line? From modonovan at carra.btireland.net Thu May 7 08:50:24 2015 From: modonovan at carra.btireland.net (Mick O'Donovan) Date: Thu, 07 May 2015 09:50:24 +0100 Subject: Alcatel-Lucent 7750 Service Router (SR) In-Reply-To: <554aea4a.762a8c0a.7549.3975@mx.google.com> References: <3BB50C80-3ED0-44D7-AFD9-484D7C03833B@gmail.com> <62174369-9641-45C8-BE0D-CF8955C9AF03@gmail.com> <554AA227.2030908@lists.esoteric.ca> <9652844c20749360e01dd56ec4d6ff8c.squirrel@66.201.44.180> <554aea4a.762a8c0a.7549.3975@mx.google.com> Message-ID: <554B2750.1030009@carra.btireland.net> +1 for the command structure and configuration being pretty simple to follow if you're used to a Cisco or Juniper. In the main they are pretty good at what they do I guess but I'm not sure whether or not we're having seriously bad luck or there's something else a miss but sadly we've had a near 50% hardware failure rate on some of the cards we have deployed in our 7750 SR12 infrastructure. Reply off list if you need any more information. Mick -- Mick O'Donovan | Network Engineer | BT Ireland | Website: http://www.btireland.net Looking Glass: http://lg.as2110.net Peering Record: http://as2110.peeringdb.com AS-SET Macro: AS-BTIRE | ASN: 2110 On 07/05/15 05:29, Phil Bedard wrote: > The show stuff is certainly there but the config is a bit different. You may have to get used to using the "info" command. :) > > They also use logical IP interfaces which are then tied to physical, you don't directly configure L3 on a physical interface. You also have designations between service and network physical interfaces, although nowadays they can be set as "hybrid.". > > It's really pretty simple if you are used to a Cisco or Juniper. They have tab and ? completion now for both commands as well as elements similar to Junos which is helpful. > > Phil > > -----Original Message----- > From: "Bob Evans" > Sent: ?5/?6/?2015 11:55 PM > To: "nanog at nanog.org" > Subject: Re: Alcatel-Lucent 7750 Service Router (SR) > > > I will be getting one to try. I am pretty sure it will support the ol' > "show ? , config ?" If not that might be a problem :-) > > Thank You > Bob Evans > CTO > > > > >> What's the price point of an SR-A4? Comparable to the MX104 or ASR9001? >> >> -- Stephen >> >> On 2015-05-06 7:13 PM, Craig wrote: >>> If you know Juniper and Cisco, the learning curve isn't so bad to pick >>> up >>> the ALU CLI, after working with it for a brief time, you catch on >>> quickly. >>> Their products are quite impressive, and a # of the carriers, are moving >>> to >>> them and some have already moved to them and are quite happy with their >>> decision. >>> >>> >>> On Wed, May 6, 2015 at 6:24 PM, Colton Conor >>> wrote: >>> >>>> I am worried as most tech's know Cisco and Juniper, so going to ALU >>>> would >>>> be a learning curve based on replies I am getting off list. >>>> >>>> On Wed, May 6, 2015 at 5:22 PM, Dan Snyder wrote: >>>> >>>>> >>>>> They are definitely good for that. We use them in part of our network >>>>> for >>>>> something very similar. >>>>> >>>>> I am not sure why they aren't mentioned that much. I know that they >>>>> have >>>>> been pretty popular in the past couple years. >>>>> >>>>> We are planning on using 7750 SR-a4's in the future but right now we >>>>> mainly have 7750SR7/12s. >>>>> >>>>> Sent from my iPhone >>>>> >>>>> On May 6, 2015, at 6:00 PM, Colton Conor >>>>> wrote: >>>>> >>>>> Taking full BGP routes from 4+ carriers on 10G connections. Why is ALU >>>>> never mentioned, but Juniper MX and Cisco are all day long? >>>>> >>>>> The new 7750 SR-a4 looks like a Juniper MX80 or MX104 killer. >>>>> >>>>> On Wed, May 6, 2015 at 4:58 PM, Dan Snyder >>>>> wrote: >>>>> >>>>>> We have been using them for almost 8 years now and have been pretty >>>>>> happy. What are you looking to use them for? >>>>>> >>>>>> Sent from my iPhone >>>>>> >>>>>>> On May 6, 2015, at 5:48 PM, Colton Conor >>>>>> wrote: >>>>>>> >>>>>>> I was wondering if anyone was using a Alcatel-Lucent 7750 Service >>>>>> Router >>>>>>> (SR) in their network? How does this platform compare the the Cisco >>>> ASR, >>>>>>> Brocade MLXe, and Juniper MX line? >>>>>> >>>>> >>>>> >>>> >> > > From cboyd at gizmopartners.com Thu May 7 16:08:15 2015 From: cboyd at gizmopartners.com (Chris Boyd) Date: Thu, 7 May 2015 11:08:15 -0500 Subject: Alcatel-Lucent 7750 Service Router (SR) In-Reply-To: References: <3BB50C80-3ED0-44D7-AFD9-484D7C03833B@gmail.com> <62174369-9641-45C8-BE0D-CF8955C9AF03@gmail.com> Message-ID: > On May 6, 2015, at 5:24 PM, Colton Conor wrote: > > I am worried as most tech's know Cisco and Juniper, so going to ALU would > be a learning curve based on replies I am getting off list. It?s not that hard to learn if you know the basics of IP routing. I just did an implementation of A-L 7705 SAR 8s and 18s. Now I really wish that Cisco supported the ?info? command. ?Chris From cvuljanic at gmail.com Thu May 7 16:16:14 2015 From: cvuljanic at gmail.com (Craig) Date: Thu, 7 May 2015 12:16:14 -0400 Subject: Alcatel-Lucent 7750 Service Router (SR) In-Reply-To: References: <3BB50C80-3ED0-44D7-AFD9-484D7C03833B@gmail.com> <62174369-9641-45C8-BE0D-CF8955C9AF03@gmail.com> Message-ID: yep.. its way easier and faster to take a look at what is configured: A:R01>config>service>vprn# interface "to-what-ever-eBGP" A:R01>config>service>vprn>if# info ---------------------------------------------- description "L3 Ckt ID: 555555555555" enable-ingress-stats cpu-protection 231 address 299.299.299.299/30 cflowd interface ipv6 address 2001:xxxx:xxxxx::xxxxx/126 exit sap 1/1/2 create cpu-protection 231 ingress filter ip 3356 filter ipv6 3356 flowspec exit exit ---------------------------------------------- On Thu, May 7, 2015 at 12:08 PM, Chris Boyd wrote: > > > On May 6, 2015, at 5:24 PM, Colton Conor wrote: > > > > I am worried as most tech's know Cisco and Juniper, so going to ALU would > > be a learning curve based on replies I am getting off list. > > It?s not that hard to learn if you know the basics of IP routing. I just > did an implementation of A-L 7705 SAR 8s and 18s. Now I really wish that > Cisco supported the ?info? command. > > ?Chris > > From tfarrell at riotgames.com Thu May 7 16:35:35 2015 From: tfarrell at riotgames.com (Trent Farrell) Date: Thu, 7 May 2015 09:35:35 -0700 Subject: Alcatel-Lucent 7750 Service Router (SR) In-Reply-To: References: <3BB50C80-3ED0-44D7-AFD9-484D7C03833B@gmail.com> <62174369-9641-45C8-BE0D-CF8955C9AF03@gmail.com> Message-ID: And if you ever need to find out what can commands exist for a certain string "xxx" tree flat detail | match xxx is a huge helper when learning. e.g. A:router# tree flat detail | match aspath-regex show router bgp routes [ [type ]] aspath-regex show router bgp routes [ []] aspath-regex On Thu, May 7, 2015 at 9:16 AM, Craig wrote: > yep.. its way easier and faster to take a look at what is configured: > > A:R01>config>service>vprn# interface "to-what-ever-eBGP" > A:R01>config>service>vprn>if# info > ---------------------------------------------- > description "L3 Ckt ID: 555555555555" > enable-ingress-stats > cpu-protection 231 > address 299.299.299.299/30 > cflowd interface > ipv6 > address 2001:xxxx:xxxxx::xxxxx/126 > exit > sap 1/1/2 create > cpu-protection 231 > ingress > filter ip 3356 > filter ipv6 3356 > flowspec > exit > exit > ---------------------------------------------- > > > > > > > > On Thu, May 7, 2015 at 12:08 PM, Chris Boyd > wrote: > > > > > > On May 6, 2015, at 5:24 PM, Colton Conor > wrote: > > > > > > I am worried as most tech's know Cisco and Juniper, so going to ALU > would > > > be a learning curve based on replies I am getting off list. > > > > It?s not that hard to learn if you know the basics of IP routing. I just > > did an implementation of A-L 7705 SAR 8s and 18s. Now I really wish that > > Cisco supported the ?info? command. > > > > ?Chris > > > > > -- *Trent Farrell* *Riot Games* *IP Network Engineer* E: tfarrell at riotgames.com | IE: +353 83 446 6809 | US: +1 424 285 9825 Summoner name: Foro From josh at spitwspots.com Thu May 7 16:40:20 2015 From: josh at spitwspots.com (Josh Reynolds) Date: Thu, 07 May 2015 08:40:20 -0800 Subject: Alcatel-Lucent 7750 Service Router (SR) In-Reply-To: <205396510.16732.1430989931013.JavaMail.zimbra@pelican.org> References: <3BB50C80-3ED0-44D7-AFD9-484D7C03833B@gmail.com> <62174369-9641-45C8-BE0D-CF8955C9AF03@gmail.com> <205396510.16732.1430989931013.JavaMail.zimbra@pelican.org> Message-ID: <249EFAC3-8955-42E6-8DDD-8AEB1D3C2B86@spitwspots.com> It really bothers me to see that people in this industry are so worried about a change of syntax or terminology. If there's one thing about the big vendors that bothers me, it's that these batteries of vendor specific tests have allowed many "techs" to get lazy. They simply can't seem to operate well, if at all, in a non-Cisco (primarily) environment. On May 7, 2015 1:12:11 AM AKDT, Tim Franklin wrote: >> I am worried as most tech's know Cisco and Juniper, so going to ALU >would >> be a learning curve based on replies I am getting off list. > >It's definitely quite different from the CLI. I'm still dabbling, but >the guys here who have been through the training and are immersed in it >really like it. We're using a couple for feature-rich BNG - lots of >MLPPP at high bandwidths (for broadband), heavyweight QoS, BGP to the >CE, etc. It's very controllable by RADIUS - template configs that you >can fill in the values for, rather than the Cisco approach of AVPs with >pages of config in. > >ALU have an e-learning "SR-OS introduction" course, which is going down >pretty well for jump-starting our Ops people. > >Regards, >Tim. -- Sent from my Android device with K-9 Mail. Please excuse my brevity. From rs at seastrom.com Thu May 7 16:49:43 2015 From: rs at seastrom.com (Rob Seastrom) Date: Thu, 07 May 2015 12:49:43 -0400 Subject: Alcatel-Lucent 7750 Service Router (SR) In-Reply-To: <249EFAC3-8955-42E6-8DDD-8AEB1D3C2B86@spitwspots.com> (Josh Reynolds's message of "Thu, 07 May 2015 08:40:20 -0800") References: <3BB50C80-3ED0-44D7-AFD9-484D7C03833B@gmail.com> <62174369-9641-45C8-BE0D-CF8955C9AF03@gmail.com> <205396510.16732.1430989931013.JavaMail.zimbra@pelican.org> <249EFAC3-8955-42E6-8DDD-8AEB1D3C2B86@spitwspots.com> Message-ID: <86ioc4xrh4.fsf@valhalla.seastrom.com> Josh Reynolds writes: > It really bothers me to see that people in this industry are so > worried about a change of syntax or terminology. If there's one > thing about the big vendors that bothers me, it's that these > batteries of vendor specific tests have allowed many "techs" to get > lazy. They simply can't seem to operate well, if at all, in a > non-Cisco (primarily) environment. If that bothers you, I recommend you not look at what passes for a "system administrator" these days. It will make you cry. -r From tim at pelican.org Thu May 7 17:02:02 2015 From: tim at pelican.org (Tim Franklin) Date: Thu, 7 May 2015 18:02:02 +0100 (BST) Subject: Alcatel-Lucent 7750 Service Router (SR) In-Reply-To: <249EFAC3-8955-42E6-8DDD-8AEB1D3C2B86@spitwspots.com> References: <3BB50C80-3ED0-44D7-AFD9-484D7C03833B@gmail.com> <62174369-9641-45C8-BE0D-CF8955C9AF03@gmail.com> <205396510.16732.1430989931013.JavaMail.zimbra@pelican.org> <249EFAC3-8955-42E6-8DDD-8AEB1D3C2B86@spitwspots.com> Message-ID: <1209747036.18164.1431018122274.JavaMail.zimbra@pelican.org> > It really bothers me to see that people in this industry are so worried about > a change of syntax or terminology. If there's one thing about the big > vendors that bothers me, it's that these batteries of vendor specific tests > have allowed many "techs" to get lazy. They simply can't seem to operate > well, if at all, in a non-Cisco (primarily) environment. I'd half-agree :) Making "it's different" in and of itself a reason not to use a particular vendor does seem to head towards laziness. But with the best will in the world, your good engineers *will* be slower until they familiarise with the new mind-maps (particularly things like the logical/physical split, SAPs, etc on the ALU) and the new magic words - although hopefully they'll be excited to learn something new too. Your weaker engineers are going to need more of a push and/or some help, and the further towards helpdesk and scripts you get, the more you're going to need to provide training - be that internal, external, new scripts and cribs sheets or whatever. That's an impact and cost it's unwise to ignore. Regards, Tim. From josh at spitwspots.com Thu May 7 17:04:41 2015 From: josh at spitwspots.com (Josh Reynolds) Date: Thu, 07 May 2015 09:04:41 -0800 Subject: Alcatel-Lucent 7750 Service Router (SR) In-Reply-To: <86ioc4xrh4.fsf@valhalla.seastrom.com> References: <3BB50C80-3ED0-44D7-AFD9-484D7C03833B@gmail.com> <62174369-9641-45C8-BE0D-CF8955C9AF03@gmail.com> <205396510.16732.1430989931013.JavaMail.zimbra@pelican.org> <249EFAC3-8955-42E6-8DDD-8AEB1D3C2B86@spitwspots.com> <86ioc4xrh4.fsf@valhalla.seastrom.com> Message-ID: <0B4D4B3F-6CCD-40C2-8998-E6F7C84A6D3D@spitwspots.com> *grumble, grumble, grumble* "Get off my lawn!" :) On May 7, 2015 8:49:43 AM AKDT, Rob Seastrom wrote: > >Josh Reynolds writes: > >> It really bothers me to see that people in this industry are so >> worried about a change of syntax or terminology. If there's one >> thing about the big vendors that bothers me, it's that these >> batteries of vendor specific tests have allowed many "techs" to get >> lazy. They simply can't seem to operate well, if at all, in a >> non-Cisco (primarily) environment. > >If that bothers you, I recommend you not look at what passes for a >"system administrator" these days. It will make you cry. > >-r -- Sent from my Android device with K-9 Mail. Please excuse my brevity. From cvuljanic at gmail.com Thu May 7 17:07:35 2015 From: cvuljanic at gmail.com (Craig) Date: Thu, 7 May 2015 13:07:35 -0400 Subject: Alcatel-Lucent 7750 Service Router (SR) In-Reply-To: <86ioc4xrh4.fsf@valhalla.seastrom.com> References: <3BB50C80-3ED0-44D7-AFD9-484D7C03833B@gmail.com> <62174369-9641-45C8-BE0D-CF8955C9AF03@gmail.com> <205396510.16732.1430989931013.JavaMail.zimbra@pelican.org> <249EFAC3-8955-42E6-8DDD-8AEB1D3C2B86@spitwspots.com> <86ioc4xrh4.fsf@valhalla.seastrom.com> Message-ID: we do "cry" when we interview people that claim to have "advanced knowledge" of BGP and we ask them some very basic BGP questions, and we get a blank stare..... On Thu, May 7, 2015 at 12:49 PM, Rob Seastrom wrote: > > Josh Reynolds writes: > > > It really bothers me to see that people in this industry are so > > worried about a change of syntax or terminology. If there's one > > thing about the big vendors that bothers me, it's that these > > batteries of vendor specific tests have allowed many "techs" to get > > lazy. They simply can't seem to operate well, if at all, in a > > non-Cisco (primarily) environment. > > If that bothers you, I recommend you not look at what passes for a > "system administrator" these days. It will make you cry. > > -r > > > From josh at spitwspots.com Thu May 7 17:10:43 2015 From: josh at spitwspots.com (Josh Reynolds) Date: Thu, 07 May 2015 09:10:43 -0800 Subject: Alcatel-Lucent 7750 Service Router (SR) In-Reply-To: References: <3BB50C80-3ED0-44D7-AFD9-484D7C03833B@gmail.com> <62174369-9641-45C8-BE0D-CF8955C9AF03@gmail.com> <205396510.16732.1430989931013.JavaMail.zimbra@pelican.org> <249EFAC3-8955-42E6-8DDD-8AEB1D3C2B86@spitwspots.com> <86ioc4xrh4.fsf@valhalla.seastrom.com> Message-ID: <5490A8D4-7B1B-4AFF-BA55-FF594982A1D3@spitwspots.com> You know where these people wouldn't fit? W/ISPs. Every three years or so you are forklifting the majority of your wireless PtMP for either a new series or a totally different vendor. New backhaul vendors often. You're building AC and DC power plants. You likely touch Cisco, juniper, HP, mikrotik, ubiquiti, Linux, windows, *BSD/pfsense, lucent, accedian/ciena, etc due to various client and network requirements all in the same week, AND you have to make them work together nicely :) It's not the environment for somebody like that, and I truly don't understand how people of that.. "caliber" end up working on large scale WANs and global transit networks. Frankly, it scares me a bit. On May 7, 2015 9:07:35 AM AKDT, Craig wrote: >we do "cry" when we interview people that claim to have "advanced >knowledge" of BGP and we ask them some very basic BGP questions, and we >get >a blank stare..... > >On Thu, May 7, 2015 at 12:49 PM, Rob Seastrom wrote: > >> >> Josh Reynolds writes: >> >> > It really bothers me to see that people in this industry are so >> > worried about a change of syntax or terminology. If there's one >> > thing about the big vendors that bothers me, it's that these >> > batteries of vendor specific tests have allowed many "techs" to get >> > lazy. They simply can't seem to operate well, if at all, in a >> > non-Cisco (primarily) environment. >> >> If that bothers you, I recommend you not look at what passes for a >> "system administrator" these days. It will make you cry. >> >> -r >> >> >> -- Sent from my Android device with K-9 Mail. Please excuse my brevity. From rs at seastrom.com Thu May 7 17:38:15 2015 From: rs at seastrom.com (Rob Seastrom) Date: Thu, 07 May 2015 13:38:15 -0400 Subject: Alcatel-Lucent 7750 Service Router (SR) In-Reply-To: <0B4D4B3F-6CCD-40C2-8998-E6F7C84A6D3D@spitwspots.com> (Josh Reynolds's message of "Thu, 07 May 2015 09:04:41 -0800") References: <3BB50C80-3ED0-44D7-AFD9-484D7C03833B@gmail.com> <62174369-9641-45C8-BE0D-CF8955C9AF03@gmail.com> <205396510.16732.1430989931013.JavaMail.zimbra@pelican.org> <249EFAC3-8955-42E6-8DDD-8AEB1D3C2B86@spitwspots.com> <86ioc4xrh4.fsf@valhalla.seastrom.com> <0B4D4B3F-6CCD-40C2-8998-E6F7C84A6D3D@spitwspots.com> Message-ID: <86pp6cwans.fsf@valhalla.seastrom.com> More like "at least be willing to man up and learn your way around some platform other than RHEL without whining if there is a business need for it". -r Josh Reynolds writes: > *grumble, grumble, grumble* > "Get off my lawn!" > :) > > > On May 7, 2015 8:49:43 AM AKDT, Rob Seastrom wrote: > > > >>Josh Reynolds writes: > >> > >> > > It really bothers me to see that people in this > industry are so > > worried about a change of syntax or terminology. If > there's one > > thing about the big vendors that bothers me, it's that > these > > batteries of vendor specific tests have allowed many > "techs" to get > > lazy. They simply can't seem to operate well, if at all, > in a > > non-Cisco (primarily) environment. > > > > >If that bothers you, I recommend you not look at what passes > for a > >"system administrator" these days. It will make you cry. > > > >-r > > > > > > > > > -- > Sent from my Android device with K-9 Mail. Please excuse my brevity. From josh at spitwspots.com Thu May 7 17:50:50 2015 From: josh at spitwspots.com (Josh Reynolds) Date: Thu, 07 May 2015 09:50:50 -0800 Subject: Alcatel-Lucent 7750 Service Router (SR) In-Reply-To: <86pp6cwans.fsf@valhalla.seastrom.com> References: <3BB50C80-3ED0-44D7-AFD9-484D7C03833B@gmail.com> <62174369-9641-45C8-BE0D-CF8955C9AF03@gmail.com> <205396510.16732.1430989931013.JavaMail.zimbra@pelican.org> <249EFAC3-8955-42E6-8DDD-8AEB1D3C2B86@spitwspots.com> <86ioc4xrh4.fsf@valhalla.seastrom.com> <0B4D4B3F-6CCD-40C2-8998-E6F7C84A6D3D@spitwspots.com> <86pp6cwans.fsf@valhalla.seastrom.com> Message-ID: <8066FC27-444B-4BED-95A2-CF6667F43EA3@spitwspots.com> LOL :) On May 7, 2015 9:38:15 AM AKDT, Rob Seastrom wrote: > >More like "at least be willing to man up and learn your way around >some platform other than RHEL without whining if there is a business >need for it". > >-r > >Josh Reynolds writes: > >> *grumble, grumble, grumble* >> "Get off my lawn!" >> :) >> >> >> On May 7, 2015 8:49:43 AM AKDT, Rob Seastrom wrote: >> >> >> >>>Josh Reynolds writes: >> >>> >> >>> >> >> It really bothers me to see that people in this >> industry are so >> > worried about a change of syntax or terminology. If >> there's one >> > thing about the big vendors that bothers me, it's that >> these >> > batteries of vendor specific tests have allowed many >> "techs" to get >> > lazy. They simply can't seem to operate well, if at all, >> in a >> > non-Cisco (primarily) environment. >> > >> >> >If that bothers you, I recommend you not look at what >passes >> for a >> >"system administrator" these days. It will make you cry. >> > >> >-r >> > >> > >> > >> >> >> -- >> Sent from my Android device with K-9 Mail. Please excuse my brevity. -- Sent from my Android device with K-9 Mail. Please excuse my brevity. From colton.conor at gmail.com Thu May 7 17:55:17 2015 From: colton.conor at gmail.com (Colton Conor) Date: Thu, 7 May 2015 12:55:17 -0500 Subject: Huawei and ZTE Routers Message-ID: The other thread about the Alcatel-Lucent routers has been pleasantly delightful. Our organization used to believe that Juniper, Cisco, and Brocade were the only true vendors for carrier grade routing, but now we are going to throw Alcatel-Lucent into the mix. ZTE and Huawei, the big chinese vendors, have also been mentioned to us. I know there are large national security issues with using these vendors in the US, but I know Level3 and other large American vendors use Huawei and ZTE in their networks. How do their products perform? How are they compared to Cisco and Juniper on the performance side of the house? Is their pricing really half or less of that of Cisco and Juniper? Is it worth using these vendors or not worth the hassle? From corbe at corbe.net Thu May 7 18:25:26 2015 From: corbe at corbe.net (Daniel Corbe) Date: Thu, 07 May 2015 14:25:26 -0400 Subject: Huawei and ZTE Routers In-Reply-To: (Colton Conor's message of "Thu, 7 May 2015 12:55:17 -0500") References: Message-ID: <87y4l0p7mx.fsf@corbe.net> Colton Conor writes: > The other thread about the Alcatel-Lucent routers has been pleasantly > delightful. Our organization used to believe that Juniper, Cisco, and > Brocade were the only true vendors for carrier grade routing, but now we > are going to throw Alcatel-Lucent into the mix. > > ZTE and Huawei, the big chinese vendors, have also been mentioned to us. I > know there are large national security issues with using these vendors in > the US, but I know Level3 and other large American vendors use Huawei and > ZTE in their networks. > > How do their products perform? How are they compared to Cisco and Juniper > on the performance side of the house? Is their pricing really half or less > of that of Cisco and Juniper? Is it worth using these vendors or not worth > the hassle? I don't know much about Huawei but be wary of ZTE's claims. They love their vendor lock-in. They have a bad habit of giving away hardware for next to nothing and then ratcheting up support costs. Opex needs to be a consideration when selecting an equipment vendor as well as capex. From ml at kenweb.org Thu May 7 19:17:04 2015 From: ml at kenweb.org (ML) Date: Thu, 07 May 2015 15:17:04 -0400 Subject: Huawei and ZTE Routers In-Reply-To: <87y4l0p7mx.fsf@corbe.net> References: <87y4l0p7mx.fsf@corbe.net> Message-ID: <554BBA30.2050103@kenweb.org> On 5/7/2015 2:25 PM, Daniel Corbe wrote: > Colton Conor writes: > >> The other thread about the Alcatel-Lucent routers has been pleasantly >> delightful. Our organization used to believe that Juniper, Cisco, and >> Brocade were the only true vendors for carrier grade routing, but now we >> are going to throw Alcatel-Lucent into the mix. >> >> ZTE and Huawei, the big chinese vendors, have also been mentioned to us. I >> know there are large national security issues with using these vendors in >> the US, but I know Level3 and other large American vendors use Huawei and >> ZTE in their networks. >> >> How do their products perform? How are they compared to Cisco and Juniper >> on the performance side of the house? Is their pricing really half or less >> of that of Cisco and Juniper? Is it worth using these vendors or not worth >> the hassle? > I don't know much about Huawei but be wary of ZTE's claims. They love > their vendor lock-in. They have a bad habit of giving away hardware for > next to nothing and then ratcheting up support costs. > > Opex needs to be a consideration when selecting an equipment vendor as > well as capex. > 2nd hand information: Apparently the NMS for ZTE's GPON gear is an ugly contraption. When upgrades are needed: "we have to deploy a series of convuluted batch files" "and it has to be installed in the directory that whatever they installed it to in China" "paths are hardcoded in the app" Hopefully there is no crossover into ZTE's other products. From jvanoppen at spectrumnet.us Thu May 7 20:02:04 2015 From: jvanoppen at spectrumnet.us (John van Oppen) Date: Thu, 7 May 2015 20:02:04 +0000 Subject: IP DSCP across the Internet In-Reply-To: <11937411.8601.1430999138395.JavaMail.mhammett@ThunderFuck> References: , <11937411.8601.1430999138395.JavaMail.mhammett@ThunderFuck> Message-ID: seems pretty real to me, I know we (AS11404) mark to zero on ingress... I think that is the typical case otherwise people would just tag their flood style ddos traffic as max and try to take out everything. John ________________________________________ From: NANOG [nanog-bounces at nanog.org] on behalf of Mike Hammett [nanog at ics-il.net] Sent: Thursday, May 07, 2015 4:46 AM To: nanog list Subject: Re: IP DSCP across the Internet That sounds like a rather poor implementation. What if they had more than one VoIP call? Seems like this thread has more FUD than real examples. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com ----- Original Message ----- From: "Mikael Abrahamsson" To: "Mark Tinka" Cc: "nanog list" Sent: Thursday, May 7, 2015 4:32:52 AM Subject: Re: IP DSCP across the Internet On Wed, 6 May 2015, Mark Tinka wrote: > With color-aware policing toward a customer in Uganda, any traffic > coming from that peer in South Africa was getting dropped toward that > customer in Uganda. After a very odd sequence of troubleshooting events, > we found that the AF DSCP alues being set by the peer in South Africa > (and us passing them due to the old kit not being able to remark on > ingress) was causing the color-aware policer in Uganda to drop traffic > toward the customer there. I have heard similar stories where game traffic ended up in a 100 kilobit/s VoIP queue which worked fine until there were a lot of nearby players in the game, then things started working very badly. Also nice corner case :P So yes, setting all external Internet traffic to DSCP=BE (0) is something one wants to do. -- Mikael Abrahamsson email: swmike at swm.pp.se From mark.tinka at seacom.mu Thu May 7 21:08:33 2015 From: mark.tinka at seacom.mu (Mark Tinka) Date: Thu, 7 May 2015 23:08:33 +0200 Subject: Alcatel-Lucent 7750 Service Router (SR) In-Reply-To: References: Message-ID: <554BD451.1000903@seacom.mu> On 7/May/15 15:16, Phil Bedard wrote: > Forgot to send this yesterday? > > We use them in our networks along with ASR9Ks and MXs. There are a lot of them deployed around the world doing very similar things as ASRs and MXs. The config is more like Juniper than Cisco IMHO. Being kind of the ?3rd? vendor they have a tendency to implement features proposed by both Cisco and Juniper faster than Cisco and Juniper when proposed by the other vendor. For instance Segment Routing is a Cisco thing, but ALU has already implemented it in their latest 13.0 software, Juniper is sort of dragging their feet on it because it?s a Cisco thing. Same goes for NG-MVPN (BGP signaled multicast VPN). Cisco dragged their feet on it because it was a Juniper thing, ALU had no issues implementing it much sooner. Most of ALUs innovation is on the MPLS services side. We use them for business VPN (L2 and L3) but the underlying protocols are all standard stuff and interoperate with everything else. I went to an ALU lab last year to look at some of their kit. Very impressive in the BNG space, and they've had a good reputation for that even before I laid hands on one. The CLI is pretty neat, and easy to learn. You're right about ALU not being fussy (but being faster) on implementing features that Cisco and Juniper squabble over. We have just received a test router we have for the next couple of months, and may consider them for some roles in the network if we are happy. My only gripe with ALU is their Metro-E offering is currently not where I'd like it to be. Mark. From steve.dodd at sungardas.com Thu May 7 15:02:16 2015 From: steve.dodd at sungardas.com (Steve Dodd) Date: Thu, 07 May 2015 09:02:16 -0600 Subject: link avoidance In-Reply-To: References: Message-ID: On 5/6/15, 4:56 PM, "Randy Bush" wrote: >a fellow researcher wants > > > to make the case that in some scenarios it is very important for a > > network operator to be able to specify that traffic should *not* > > traverse a certain switch/link/group of switches/group of links > > (that's true right?). Could you give some examples? Perhaps point > > me to relevant references? > >if so, why? security? congestion? other? but is it common? and, if >so, how do you do it? > >randy In the wireless backhaul space I?ve seen carriers that would prefer a circuit to go down rather than take the long path on a ring between tower and switching center. I assume they are concerned with some sort of latency requirement. We used RSVP-TE with link coloring as the solution. -Steve > From paul at paulstewart.org Thu May 7 22:22:02 2015 From: paul at paulstewart.org (Paul Stewart) Date: Thu, 7 May 2015 18:22:02 -0400 Subject: disadvantages of peering with own IP transit customers In-Reply-To: <5549DF9D.8040109@seacom.mu> References: <5549DF9D.8040109@seacom.mu> Message-ID: <00ca01d08914$3ea3d560$bbeb8020$@paulstewart.org> Well said Mark ... There's a certain large transit provider that this all the time and I never understood why ... Paul -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Mark Tinka Sent: Wednesday, May 6, 2015 5:32 AM To: Martin T; nanog at nanog.org Subject: Re: disadvantages of peering with own IP transit customers On 6/May/15 11:20, Martin T wrote: > Hi, > > what are the disadvantages of peering(announcing own and all customers > prefixes) with own IP transit customers? One disadvantage is obviously > that amount of traffic on IP transit link is lower and thus customer > pays for smaller amount of Mbps. On the other hand, this can be > somewhat compensated with higher price per Mbps if the amount of > traffic on the IP transit connection is lower. However, are there any > other disadvantages/concerns when peering with own IP transit > customers? - Potentially odd routing if customers are unfamiliar with how BGP really works, i.e., upload from customer hits the commercial link, but return traffic to customer follows the peering link since peering links generally have a higher LOCAL_PREF than commercial links. - Since more traffic is return to (eyeball-heavy) customers, you increase investment on your peering side with no corresponding gain in revenue, as peering is, well, free. - Any special policies you accord to peers will now be enjoyed by this customer also, since they also are a peer. - Issues that could be caused by deliberate inconsistent routing from the customer's part in an effort to direct more traffic into the peering link. - Complicated controls you may put in place to ensure the customer does not abuse your network from a peering standpoint (or vice versa), e.g., Internet in VRF's, peering in VRF's, e.t.c., and the issues that come with all that complexity. - Complications with the commercial contract - a growth in your customer's traffic out of balance with how much money you're earning from them. - Confusion between your customer, their account manager, the engineering team and the operations teams on how the service is meant to be delivered, operated, billed for, e.t.c. - A host of other things I haven't thought about. All in all, don't peer with customers if you don't have to. That should be your #1 and #2 peering policy rules. Too much commercial and technical confusion will surely ensue. Mark. From randy at psg.com Thu May 7 22:32:41 2015 From: randy at psg.com (Randy Bush) Date: Fri, 08 May 2015 07:32:41 +0900 Subject: Huawei and ZTE Routers In-Reply-To: References: Message-ID: > ZTE and Huawei, the big chinese vendors, have also been mentioned to > us. I know there are large national security issues with using these > vendors in the US uh, you have not seen the lovely picture of the nsa implanting a cisco? randy From mysidia at gmail.com Thu May 7 23:39:09 2015 From: mysidia at gmail.com (Jimmy Hess) Date: Thu, 7 May 2015 18:39:09 -0500 Subject: Network Segmentation Approaches In-Reply-To: <20150507121254.GA26854@gsp.org> References: <20150506175831.C4959377@m0005311.ppops.net> <20150507121254.GA26854@gsp.org> Message-ID: On Thu, May 7, 2015 at 7:12 AM, Rich Kulawiec wrote: > Ah...got it, this was sloppy phrasing on my part. I meant "first" > in the sense of "first rule that one should write". Depending on Security best practice to always have an active "cleanup" rule for every traffic direction applicable to every pair of zones (or interfaces) with a default DROP, to catch traffic matching no accept rule. In practice... however.... in the real world, many firewalls get configured with this only in the INBOUND direction (Default deny Write packet to Higher integrity level zone from lower level security zone), and Default Accept for packet from more secure zone to less secure zone, Since this has superior usability and is lower maintenance. And for client devices, in a low security environment: with just a simple Layer4 stateful inspection firewall, this is probably the right solution. "Permit only traffic that is necessary" Only works out if you are able to rigidly define what exactly that traffic is in advance. Which is feasible to do for servers and other single-purpose devices, but very expensive to do for clients, at least without a firewall aware of the communications at the application layer that can look at those UDP connections and say "OKAY, This is skype... allow it", Or... "This connection going out on port 80.. it's not a valid HTTP request, Drop the connection now and cache a rule to Deny further connections to that IP:Port number pair.". > the firewall type/implementation, that might be the rule that's > lexically first or last (or maybe somewhere else). > ---rsk -- -JH From Bob.Watson at wwt.com Fri May 8 01:36:39 2015 From: Bob.Watson at wwt.com (Watson, Bob) Date: Fri, 8 May 2015 01:36:39 +0000 Subject: Alcatel-Lucent 7750 Service Router (SR) In-Reply-To: <5490A8D4-7B1B-4AFF-BA55-FF594982A1D3@spitwspots.com> References: <3BB50C80-3ED0-44D7-AFD9-484D7C03833B@gmail.com> <62174369-9641-45C8-BE0D-CF8955C9AF03@gmail.com> <205396510.16732.1430989931013.JavaMail.zimbra@pelican.org> <249EFAC3-8955-42E6-8DDD-8AEB1D3C2B86@spitwspots.com> <86ioc4xrh4.fsf@valhalla.seastrom.com> , <5490A8D4-7B1B-4AFF-BA55-FF594982A1D3@spitwspots.com> Message-ID: Many of these churn rates result from problems self inflicted hence all the dramatic sdn promises, popularity in abstractions, Api all the things, let's go yang/netconf and retrofit every ietf standard. There's benefits but gotta rant a little. What's better than correct? Well over correct of course. > On May 7, 2015, at 12:17 PM, Josh Reynolds wrote: > > You know where these people wouldn't fit? W/ISPs. > > Every three years or so you are forklifting the majority of your wireless PtMP for either a new series or a totally different vendor. New backhaul vendors often. You're building AC and DC power plants. You likely touch Cisco, juniper, HP, mikrotik, ubiquiti, Linux, windows, *BSD/pfsense, lucent, accedian/ciena, etc due to various client and network requirements all in the same week, AND you have to make them work together nicely :) > > It's not the environment for somebody like that, and I truly don't understand how people of that.. "caliber" end up working on large scale WANs and global transit networks. > > Frankly, it scares me a bit. > >> On May 7, 2015 9:07:35 AM AKDT, Craig wrote: >> we do "cry" when we interview people that claim to have "advanced >> knowledge" of BGP and we ask them some very basic BGP questions, and we >> get >> a blank stare..... >> >> On Thu, May 7, 2015 at 12:49 PM, Rob Seastrom wrote: >> >>> >>> Josh Reynolds writes: >>> >>>> It really bothers me to see that people in this industry are so >>>> worried about a change of syntax or terminology. If there's one >>>> thing about the big vendors that bothers me, it's that these >>>> batteries of vendor specific tests have allowed many "techs" to get >>>> lazy. They simply can't seem to operate well, if at all, in a >>>> non-Cisco (primarily) environment. >>> >>> If that bothers you, I recommend you not look at what passes for a >>> "system administrator" these days. It will make you cry. >>> >>> -r > > -- > Sent from my Android device with K-9 Mail. Please excuse my brevity. From josh at spitwspots.com Fri May 8 01:40:41 2015 From: josh at spitwspots.com (Josh Reynolds) Date: Thu, 07 May 2015 17:40:41 -0800 Subject: Alcatel-Lucent 7750 Service Router (SR) In-Reply-To: References: <3BB50C80-3ED0-44D7-AFD9-484D7C03833B@gmail.com> <62174369-9641-45C8-BE0D-CF8955C9AF03@gmail.com> <205396510.16732.1430989931013.JavaMail.zimbra@pelican.org> <249EFAC3-8955-42E6-8DDD-8AEB1D3C2B86@spitwspots.com> <86ioc4xrh4.fsf@valhalla.seastrom.com> , <5490A8D4-7B1B-4AFF-BA55-FF594982A1D3@spitwspots.com> Message-ID: <554C1419.8060006@spitwspots.com> What churn rates are you talking about? Josh Reynolds CIO, SPITwSPOTS www.spitwspots.com On 05/07/2015 05:36 PM, Watson, Bob wrote: > Many of these churn rates result from problems self inflicted hence all the dramatic sdn promises, popularity in abstractions, Api all the things, let's go yang/netconf and retrofit every ietf standard. There's benefits but gotta rant a little. What's better than correct? Well over correct of course. > > > > >> On May 7, 2015, at 12:17 PM, Josh Reynolds wrote: >> >> You know where these people wouldn't fit? W/ISPs. >> >> Every three years or so you are forklifting the majority of your wireless PtMP for either a new series or a totally different vendor. New backhaul vendors often. You're building AC and DC power plants. You likely touch Cisco, juniper, HP, mikrotik, ubiquiti, Linux, windows, *BSD/pfsense, lucent, accedian/ciena, etc due to various client and network requirements all in the same week, AND you have to make them work together nicely :) >> >> It's not the environment for somebody like that, and I truly don't understand how people of that.. "caliber" end up working on large scale WANs and global transit networks. >> >> Frankly, it scares me a bit. >> >>> On May 7, 2015 9:07:35 AM AKDT, Craig wrote: >>> we do "cry" when we interview people that claim to have "advanced >>> knowledge" of BGP and we ask them some very basic BGP questions, and we >>> get >>> a blank stare..... >>> >>> On Thu, May 7, 2015 at 12:49 PM, Rob Seastrom wrote: >>> >>>> Josh Reynolds writes: >>>> >>>>> It really bothers me to see that people in this industry are so >>>>> worried about a change of syntax or terminology. If there's one >>>>> thing about the big vendors that bothers me, it's that these >>>>> batteries of vendor specific tests have allowed many "techs" to get >>>>> lazy. They simply can't seem to operate well, if at all, in a >>>>> non-Cisco (primarily) environment. >>>> If that bothers you, I recommend you not look at what passes for a >>>> "system administrator" these days. It will make you cry. >>>> >>>> -r >> -- >> Sent from my Android device with K-9 Mail. Please excuse my brevity. From fergdawgster at mykolab.com Fri May 8 01:56:34 2015 From: fergdawgster at mykolab.com (Paul Ferguson) Date: Thu, 07 May 2015 18:56:34 -0700 Subject: List hiccups? Message-ID: <554C17D2.9010301@mykolab.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Does anyone any else find it weird that the last dozen or so messages from the list have been .eml attachments? Or is it just me? - - ferg - -- Paul Ferguson PGP Public Key ID: 0x54DC85B2 Key fingerprint: 19EC 2945 FEE8 D6C8 58A1 CE53 2896 AC75 54DC 85B2 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iF4EAREIAAYFAlVMF9IACgkQKJasdVTchbIvAQEA02tfEq/u6ytdP1i10DmpUmN3 mz+ntVUnbHhwqjL1AmMBALp/7M3kQ9oP2gH9Nc36IrLG7cM5cyG6nF4cebCgZnaT =8S9U -----END PGP SIGNATURE----- From nanog at ics-il.net Fri May 8 01:58:15 2015 From: nanog at ics-il.net (Mike Hammett) Date: Thu, 7 May 2015 20:58:15 -0500 (CDT) Subject: No subject In-Reply-To: Message-ID: <8229750.1452.1431050310305.JavaMail.mhammett@ThunderFuck> I've seen the same over here and also considered it weird. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com ----- Original Message ----- From: "Paul Ferguson via NANOG" To: "NANOG" Sent: Thursday, May 7, 2015 8:56:44 PM From nangel at tetrasec.net Fri May 8 02:02:44 2015 From: nangel at tetrasec.net (Nathan Angelacos) Date: Thu, 07 May 2015 22:02:44 -0400 Subject: Missing Subjects In-Reply-To: References: Message-ID: <554C1944.3060802@tetrasec.net> Looks like there's an extra line break after: From nangel at tetrasec.net Fri May 8 02:04:05 2015 From: nangel at tetrasec.net (Nathan Angelacos) Date: Thu, 07 May 2015 22:04:05 -0400 Subject: Missing Subjects In-Reply-To: References: Message-ID: <554C1995.5020006@tetrasec.net> Looks like there's an extra line break after this header line: X-Virus-Scanned: ClamAV using ClamSMTP So the SMTP headers are getting partitioned. From jesler at cisco.com Fri May 8 02:05:36 2015 From: jesler at cisco.com (Joel Esler (jesler)) Date: Fri, 8 May 2015 02:05:36 +0000 Subject: No subject In-Reply-To: References: Message-ID: <739AE35E-C1A3-492F-86AD-F546CA2E2EF0@cisco.com> Seeing them here too. -- Joel Esler Sent from my iPhone On May 7, 2015, at 9:58 PM, Paul Ferguson via NANOG > wrote: From morrowc.lists at gmail.com Fri May 8 02:10:06 2015 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Thu, 7 May 2015 22:10:06 -0400 Subject: No subject In-Reply-To: References: Message-ID: List-Post: From: Nathan Angelacos via NANOG you are seeing the effect of whatever that new 'we will stop spam with dns records' process (not spf, not dkim ... the other one) On Thu, May 7, 2015 at 10:04 PM, Nathan Angelacos via NANOG wrote: > > > ---------- Forwarded message ---------- > From: Nathan Angelacos > To: nanog at nanog.org > Cc: > Date: Thu, 07 May 2015 22:04:05 -0400 > Subject: Re: Missing Subjects > Looks like there's an extra line break after this header line: > > X-Virus-Scanned: ClamAV using ClamSMTP > > So the SMTP headers are getting partitioned. > > From ml-nanog090304q at elcsplace.com Fri May 8 02:11:49 2015 From: ml-nanog090304q at elcsplace.com (Ted Cooper) Date: Fri, 08 May 2015 12:11:49 +1000 Subject: No subject In-Reply-To: References: Message-ID: <554C1B65.70105@elcsplace.com> On 08/05/15 11:58, Mike Hammett via NANOG wrote: > I've seen the same over here and also considered it weird. It looks exactly like the the DMARC senders treatment - I think there's something wiggy and everyone is being treated as a DMARC encumbered sender. From ak47 at gawul.net Fri May 8 02:21:01 2015 From: ak47 at gawul.net (Andrew Koch) Date: Thu, 7 May 2015 21:21:01 -0500 Subject: Mailing list posts wrapped Message-ID: There was an inadvertent DMARC handling setting applied to all posts. This has been corrected. Sorry for the disruption. Andrew Koch From fergdawgster at mykolab.com Fri May 8 02:23:18 2015 From: fergdawgster at mykolab.com (Paul Ferguson) Date: Thu, 07 May 2015 19:23:18 -0700 Subject: No subject In-Reply-To: <554C1B65.70105@elcsplace.com> References: <554C1B65.70105@elcsplace.com> Message-ID: <554C1E16.70006@mykolab.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 5/7/2015 7:11 PM, Ted Cooper wrote: > On 08/05/15 11:58, Mike Hammett via NANOG wrote: >> I've seen the same over here and also considered it weird. > > It looks exactly like the the DMARC senders treatment - I think > there's something wiggy and everyone is being treated as a DMARC > encumbered sender. > > I'm on a gazillion lists, and this is the only one which seems to have this particularly annoying problem. - - ferg - -- Paul Ferguson PGP Public Key ID: 0x54DC85B2 Key fingerprint: 19EC 2945 FEE8 D6C8 58A1 CE53 2896 AC75 54DC 85B2 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iF4EAREIAAYFAlVMHhYACgkQKJasdVTchbIy+wEAzjAATu8LDTLVTBKPDIY/joKi 4/UXTi0ZS2cnlnp1SWQA/A4ZpErA6z05UiaQ6/J+Hyaw07tcY+PNowhIjKEJP6Fc =IFIY -----END PGP SIGNATURE----- From fergdawgster at mykolab.com Fri May 8 02:27:44 2015 From: fergdawgster at mykolab.com (Paul Ferguson) Date: Thu, 07 May 2015 19:27:44 -0700 Subject: No subject In-Reply-To: <554C1E16.70006@mykolab.com> References: <554C1B65.70105@elcsplace.com> <554C1E16.70006@mykolab.com> Message-ID: <554C1F20.6080604@mykolab.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 5/7/2015 7:23 PM, Paul Ferguson wrote: > I'm on a gazillion lists, and this is the only one which seems to > have this particularly annoying problem. And fixed! Apologies for the noise. - - ferg - -- Paul Ferguson PGP Public Key ID: 0x54DC85B2 Key fingerprint: 19EC 2945 FEE8 D6C8 58A1 CE53 2896 AC75 54DC 85B2 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iF4EAREIAAYFAlVMHyAACgkQKJasdVTchbJlEAD9G6j3FfrDWMYgcniFCFu+z5cs B5UlX7U5vhzfKQYIv0kBAKi4mq5LTC5ESuN7dUKuILvNKiicu69DqMgH6wmCftuF =shQ2 -----END PGP SIGNATURE----- From Bob.Watson at wwt.com Fri May 8 06:03:13 2015 From: Bob.Watson at wwt.com (Watson, Bob) Date: Fri, 8 May 2015 06:03:13 +0000 Subject: Alcatel-Lucent 7750 Service Router (SR) In-Reply-To: <554C1419.8060006@spitwspots.com> References: <3BB50C80-3ED0-44D7-AFD9-484D7C03833B@gmail.com> <62174369-9641-45C8-BE0D-CF8955C9AF03@gmail.com> <205396510.16732.1430989931013.JavaMail.zimbra@pelican.org> <249EFAC3-8955-42E6-8DDD-8AEB1D3C2B86@spitwspots.com> <86ioc4xrh4.fsf@valhalla.seastrom.com> , <5490A8D4-7B1B-4AFF-BA55-FF594982A1D3@spitwspots.com> , <554C1419.8060006@spitwspots.com> Message-ID: <5DF72804-80A9-4BEF-B1CA-46724261720A@wwt.com> Carrier oem churn (turnover /agitation cycles) First mover for features happen and leapfrog but the ones that matter get adopted across the line in time. > On May 7, 2015, at 8:40 PM, Josh Reynolds wrote: > > What churn rates are you talking about? > > Josh Reynolds > CIO, SPITwSPOTS > www.spitwspots.com > >> On 05/07/2015 05:36 PM, Watson, Bob wrote: >> Many of these churn rates result from problems self inflicted hence all the dramatic sdn promises, popularity in abstractions, Api all the things, let's go yang/netconf and retrofit every ietf standard. There's benefits but gotta rant a little. What's better than correct? Well over correct of course. >> >> >> >> >>> On May 7, 2015, at 12:17 PM, Josh Reynolds wrote: >>> >>> You know where these people wouldn't fit? W/ISPs. >>> >>> Every three years or so you are forklifting the majority of your wireless PtMP for either a new series or a totally different vendor. New backhaul vendors often. You're building AC and DC power plants. You likely touch Cisco, juniper, HP, mikrotik, ubiquiti, Linux, windows, *BSD/pfsense, lucent, accedian/ciena, etc due to various client and network requirements all in the same week, AND you have to make them work together nicely :) >>> >>> It's not the environment for somebody like that, and I truly don't understand how people of that.. "caliber" end up working on large scale WANs and global transit networks. >>> >>> Frankly, it scares me a bit. >>> >>>> On May 7, 2015 9:07:35 AM AKDT, Craig wrote: >>>> we do "cry" when we interview people that claim to have "advanced >>>> knowledge" of BGP and we ask them some very basic BGP questions, and we >>>> get >>>> a blank stare..... >>>> >>>> On Thu, May 7, 2015 at 12:49 PM, Rob Seastrom wrote: >>>> >>>>> Josh Reynolds writes: >>>>> >>>>>> It really bothers me to see that people in this industry are so >>>>>> worried about a change of syntax or terminology. If there's one >>>>>> thing about the big vendors that bothers me, it's that these >>>>>> batteries of vendor specific tests have allowed many "techs" to get >>>>>> lazy. They simply can't seem to operate well, if at all, in a >>>>>> non-Cisco (primarily) environment. >>>>> If that bothers you, I recommend you not look at what passes for a >>>>> "system administrator" these days. It will make you cry. >>>>> >>>>> -r >>> -- >>> Sent from my Android device with K-9 Mail. Please excuse my brevity. > From marka at isc.org Fri May 8 06:39:21 2015 From: marka at isc.org (Mark Andrews) Date: Fri, 08 May 2015 16:39:21 +1000 Subject: No subject In-Reply-To: Your message of "Fri, 08 May 2015 01:56:44 +0000." References: Message-ID: <20150508063922.47C152DF2D66@rock.dv.isc.org> In message , Paul Ferguson via N ANOG writes: > > Does anyone any else find it weird that the last dozen or so messages > from the list have been .eml attachments? Nanog is encapsulating messages that are DKIM signed. Your mailer may not be properly handling Content-Type: message/rfc822 Content-Disposition: inline Mark -- 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 Fri May 8 06:44:48 2015 From: marka at isc.org (Mark Andrews) Date: Fri, 08 May 2015 16:44:48 +1000 Subject: Mailing list posts wrapped In-Reply-To: Your message of "Thu, 07 May 2015 21:21:01 -0500." References: Message-ID: <20150508064449.F27F82DF2FB1@rock.dv.isc.org> In message , Andrew Koch writes : > There was an inadvertent DMARC handling setting applied to all posts. This h= > as been corrected. Sorry for the disruption.=20 > > Andrew Koch= It was also not copying the Subject: to the outer SMTP envelope. It would pay to check that this is being done to any message getting encapsulated. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From baconzombie at gmail.com Fri May 8 11:11:07 2015 From: baconzombie at gmail.com (Bacon Zombie) Date: Fri, 8 May 2015 13:11:07 +0200 Subject: Huawei and ZTE Routers In-Reply-To: <554BBA30.2050103@kenweb.org> References: <87y4l0p7mx.fsf@corbe.net> <554BBA30.2050103@kenweb.org> Message-ID: You could try cross posting to UKNOG since BT use Huawei in their DSLAMs. http://lists.uknof.org.uk/cgi-bin/mailman/listinfo/uknof/ On 7 May 2015 21:18, "ML" wrote: > On 5/7/2015 2:25 PM, Daniel Corbe wrote: > >> Colton Conor writes: >> >> The other thread about the Alcatel-Lucent routers has been pleasantly >>> delightful. Our organization used to believe that Juniper, Cisco, and >>> Brocade were the only true vendors for carrier grade routing, but now we >>> are going to throw Alcatel-Lucent into the mix. >>> >>> ZTE and Huawei, the big chinese vendors, have also been mentioned to us. >>> I >>> know there are large national security issues with using these vendors in >>> the US, but I know Level3 and other large American vendors use Huawei and >>> ZTE in their networks. >>> >>> How do their products perform? How are they compared to Cisco and Juniper >>> on the performance side of the house? Is their pricing really half or >>> less >>> of that of Cisco and Juniper? Is it worth using these vendors or not >>> worth >>> the hassle? >>> >> I don't know much about Huawei but be wary of ZTE's claims. They love >> their vendor lock-in. They have a bad habit of giving away hardware for >> next to nothing and then ratcheting up support costs. >> >> Opex needs to be a consideration when selecting an equipment vendor as >> well as capex. >> >> > 2nd hand information: > > Apparently the NMS for ZTE's GPON gear is an ugly contraption. > When upgrades are needed: > "we have to deploy a series of convuluted batch files" > "and it has to be installed in the directory that whatever they installed > it to in China" > "paths are hardcoded in the app" > > > Hopefully there is no crossover into ZTE's other products. > > From davea at staff.gwi.net Fri May 8 16:57:34 2015 From: davea at staff.gwi.net (Dave Allen) Date: Fri, 8 May 2015 12:57:34 -0400 Subject: OSP list? Message-ID: Does anyone know of a mailing list or group devoted to the topic of outside plant fiber network design and construction? From tknchris at gmail.com Fri May 8 17:02:39 2015 From: tknchris at gmail.com (chris) Date: Fri, 8 May 2015 13:02:39 -0400 Subject: OSP list? In-Reply-To: References: Message-ID: I would also be interested On May 8, 2015 12:59 PM, "Dave Allen" wrote: > Does anyone know of a mailing list or group devoted to the topic of outside > plant fiber network design and construction? > From nicholas.schmidt at controlgroup.com Fri May 8 17:09:09 2015 From: nicholas.schmidt at controlgroup.com (Nicholas Schmidt) Date: Fri, 8 May 2015 13:09:09 -0400 Subject: OSP list? In-Reply-To: References: Message-ID: +1 On Fri, May 8, 2015 at 1:02 PM, chris wrote: > I would also be interested > On May 8, 2015 12:59 PM, "Dave Allen" wrote: > > > Does anyone know of a mailing list or group devoted to the topic of > outside > > plant fiber network design and construction? > > > From josh at spitwspots.com Fri May 8 17:18:46 2015 From: josh at spitwspots.com (Josh Reynolds) Date: Fri, 08 May 2015 09:18:46 -0800 Subject: OSP list? In-Reply-To: References: Message-ID: <554CEFF6.5080407@spitwspots.com> WISPA has a fiber list for FTTx and hybrid deployments. It's not the most active thing in the world, but there can still be good stuff on there. Josh Reynolds CIO, SPITwSPOTS www.spitwspots.com On 05/08/2015 08:57 AM, Dave Allen wrote: > Does anyone know of a mailing list or group devoted to the topic of outside > plant fiber network design and construction? From jay at west.net Fri May 8 17:27:47 2015 From: jay at west.net (Jay Hennigan) Date: Fri, 08 May 2015 10:27:47 -0700 Subject: IP DSCP across the Internet In-Reply-To: <554B38F6.7020400@seacom.mu> References: <554B38F6.7020400@seacom.mu> Message-ID: <554CF213.8030703@west.net> On 5/7/15 3:05 AM, Mark Tinka wrote: > And this is what sales and marketing droids don't get - so-called > "Premium Internet" products abound that don't really mean anything. > > The competition that offer these products are basically hoping nothing > happens, and that when it does, it seems as palatable as flying First > Class in a plane that's going down. Which is usually a bad thing. I've never heard of an airplane backing into a mountain. -- 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 ilissa at imillerpr.com Fri May 8 17:34:57 2015 From: ilissa at imillerpr.com (Ilissa Miller) Date: Fri, 8 May 2015 13:34:57 -0400 Subject: OSP list? In-Reply-To: <554CEFF6.5080407@spitwspots.com> References: <554CEFF6.5080407@spitwspots.com> Message-ID: <9607FC10-B17B-40F8-9375-2FC97292C958@imillerpr.com> This could be a good resource - may have to dig a little: http://www.ospmag.com/ On May 8, 2015, at 1:18 PM, Josh Reynolds wrote: > WISPA has a fiber list for FTTx and hybrid deployments. It's not the most active thing in the world, but there can still be good stuff on there. > > Josh Reynolds > CIO, SPITwSPOTS > www.spitwspots.com > > On 05/08/2015 08:57 AM, Dave Allen wrote: >> Does anyone know of a mailing list or group devoted to the topic of outside >> plant fiber network design and construction? > Ilissa Miller CEO, iMiller Public Relations President, Northeast DAS + Small Cell Association Sponsorship Sales Director, NANOG Tel: 914.315.6424 Cel: 917.743.0931 eMail: ilissa at imillerpr.com eMail: imiller at nanog.org www.imillerpr.com www.northeastdas.com www.nanog.org From cscora at apnic.net Fri May 8 18:12:03 2015 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 9 May 2015 04:12:03 +1000 (AEST) Subject: Weekly Routing Table Report Message-ID: <201505081812.t48IC3Le013565@thyme.rand.apnic.net> This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. The posting is sent to APOPS, NANOG, AfNOG, AusNOG, SANOG, PacNOG, CaribNOG and the RIPE Routing Working Group. Daily listings are sent to bgp-stats at lists.apnic.net For historical data, please see http://thyme.rand.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 09 May, 2015 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 543336 Prefixes after maximum aggregation (per Origin AS): 207090 Deaggregation factor: 2.62 Unique aggregates announced (without unneeded subnets): 264470 Total ASes present in the Internet Routing Table: 50256 Prefixes per ASN: 10.81 Origin-only ASes present in the Internet Routing Table: 36631 Origin ASes announcing only one prefix: 16305 Transit ASes present in the Internet Routing Table: 6324 Transit-only ASes present in the Internet Routing Table: 178 Average AS path length visible in the Internet Routing Table: 4.5 Max AS path length visible: 44 Max AS path prepend of ASN ( 55944) 41 Prefixes from unregistered ASNs in the Routing Table: 1204 Unregistered ASNs in the Routing Table: 416 Number of 32-bit ASNs allocated by the RIRs: 9411 Number of 32-bit ASNs visible in the Routing Table: 7301 Prefixes from 32-bit ASNs in the Routing Table: 26590 Number of bogon 32-bit ASNs visible in the Routing Table: 4 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 387 Number of addresses announced to Internet: 2741486624 Equivalent to 163 /8s, 103 /16s and 196 /24s Percentage of available address space announced: 74.0 Percentage of allocated address space announced: 74.0 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 97.3 Total number of prefixes smaller than registry allocations: 182274 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 134135 Total APNIC prefixes after maximum aggregation: 39069 APNIC Deaggregation factor: 3.43 Prefixes being announced from the APNIC address blocks: 140281 Unique aggregates announced from the APNIC address blocks: 56940 APNIC Region origin ASes present in the Internet Routing Table: 5035 APNIC Prefixes per ASN: 27.86 APNIC Region origin ASes announcing only one prefix: 1207 APNIC Region transit ASes present in the Internet Routing Table: 879 Average APNIC Region AS path length visible: 4.4 Max APNIC Region AS path length visible: 44 Number of APNIC region 32-bit ASNs visible in the Routing Table: 1422 Number of APNIC addresses announced to Internet: 747744256 Equivalent to 44 /8s, 145 /16s and 172 /24s Percentage of available APNIC address space announced: 87.4 APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079, 55296-56319, 58368-59391, 63488-64098, 131072-135580 APNIC Address Blocks 1/8, 14/8, 27/8, 36/8, 39/8, 42/8, 43/8, 49/8, 58/8, 59/8, 60/8, 61/8, 101/8, 103/8, 106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 133/8, 150/8, 153/8, 163/8, 171/8, 175/8, 180/8, 182/8, 183/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, 223/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 178748 Total ARIN prefixes after maximum aggregation: 87933 ARIN Deaggregation factor: 2.03 Prefixes being announced from the ARIN address blocks: 181253 Unique aggregates announced from the ARIN address blocks: 84396 ARIN Region origin ASes present in the Internet Routing Table: 16587 ARIN Prefixes per ASN: 10.93 ARIN Region origin ASes announcing only one prefix: 6111 ARIN Region transit ASes present in the Internet Routing Table: 1732 Average ARIN Region AS path length visible: 3.8 Max ARIN Region AS path length visible: 24 Number of ARIN region 32-bit ASNs visible in the Routing Table: 428 Number of ARIN addresses announced to Internet: 1065588512 Equivalent to 63 /8s, 131 /16s and 151 /24s Percentage of available ARIN address space announced: 56.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, 62464-63487, 64198-64296, 393216-395164 ARIN Address Blocks 3/8, 4/8, 6/8, 7/8, 8/8, 9/8, 11/8, 12/8, 13/8, 15/8, 16/8, 17/8, 18/8, 19/8, 20/8, 21/8, 22/8, 23/8, 24/8, 26/8, 28/8, 29/8, 30/8, 32/8, 33/8, 34/8, 35/8, 38/8, 40/8, 44/8, 45/8, 47/8, 48/8, 50/8, 52/8, 53/8, 54/8, 55/8, 56/8, 57/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, 100/8, 104/8, 107/8, 108/8, 128/8, 129/8, 130/8, 131/8, 132/8, 134/8, 135/8, 136/8, 137/8, 138/8, 139/8, 140/8, 142/8, 143/8, 144/8, 146/8, 147/8, 148/8, 149/8, 152/8, 155/8, 156/8, 157/8, 158/8, 159/8, 160/8, 161/8, 162/8, 164/8, 165/8, 166/8, 167/8, 168/8, 169/8, 170/8, 172/8, 173/8, 174/8, 184/8, 192/8, 198/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 214/8, 215/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 131752 Total RIPE prefixes after maximum aggregation: 65746 RIPE Deaggregation factor: 2.00 Prefixes being announced from the RIPE address blocks: 138163 Unique aggregates announced from the RIPE address blocks: 85193 RIPE Region origin ASes present in the Internet Routing Table: 17949 RIPE Prefixes per ASN: 7.70 RIPE Region origin ASes announcing only one prefix: 8153 RIPE Region transit ASes present in the Internet Routing Table: 2966 Average RIPE Region AS path length visible: 4.9 Max RIPE Region AS path length visible: 34 Number of RIPE region 32-bit ASNs visible in the Routing Table: 3677 Number of RIPE addresses announced to Internet: 694977792 Equivalent to 41 /8s, 108 /16s and 133 /24s Percentage of available RIPE address space announced: 101.0 RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-52223, 56320-58367 59392-61439, 61952-62463, 196608-202239 RIPE Address Blocks 2/8, 5/8, 25/8, 31/8, 37/8, 46/8, 51/8, 62/8, 77/8, 78/8, 79/8, 80/8, 81/8, 82/8, 83/8, 84/8, 85/8, 86/8, 87/8, 88/8, 89/8, 90/8, 91/8, 92/8, 93/8, 94/8, 95/8, 109/8, 141/8, 145/8, 151/8, 176/8, 178/8, 185/8, 188/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 59063 Total LACNIC prefixes after maximum aggregation: 11226 LACNIC Deaggregation factor: 5.26 Prefixes being announced from the LACNIC address blocks: 69131 Unique aggregates announced from the LACNIC address blocks: 32433 LACNIC Region origin ASes present in the Internet Routing Table: 2436 LACNIC Prefixes per ASN: 28.38 LACNIC Region origin ASes announcing only one prefix: 631 LACNIC Region transit ASes present in the Internet Routing Table: 502 Average LACNIC Region AS path length visible: 4.9 Max LACNIC Region AS path length visible: 25 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 1663 Number of LACNIC addresses announced to Internet: 167684864 Equivalent to 9 /8s, 254 /16s and 171 /24s Percentage of available LACNIC address space announced: 99.9 LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 61440-61951, 64099-64197, 262144-265628 + ERX transfers LACNIC Address Blocks 177/8, 179/8, 181/8, 186/8, 187/8, 189/8, 190/8, 191/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 12878 Total AfriNIC prefixes after maximum aggregation: 3071 AfriNIC Deaggregation factor: 4.19 Prefixes being announced from the AfriNIC address blocks: 14121 Unique aggregates announced from the AfriNIC address blocks: 5174 AfriNIC Region origin ASes present in the Internet Routing Table: 739 AfriNIC Prefixes per ASN: 19.11 AfriNIC Region origin ASes announcing only one prefix: 203 AfriNIC Region transit ASes present in the Internet Routing Table: 161 Average AfriNIC Region AS path length visible: 4.5 Max AfriNIC Region AS path length visible: 24 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 111 Number of AfriNIC addresses announced to Internet: 65175552 Equivalent to 3 /8s, 226 /16s and 128 /24s Percentage of available AfriNIC address space announced: 64.7 AfriNIC AS Blocks 36864-37887, 327680-328703 & ERX transfers AfriNIC Address Blocks 41/8, 102/8, 105/8, 154/8, 196/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4766 2927 11557 912 Korea Telecom 17974 2766 904 81 PT Telekomunikasi Indonesia 7545 2578 336 129 TPG Telecom Limited 4755 2014 422 215 TATA Communications formerly 4538 1908 4190 72 China Education and Research 9829 1637 1322 58 National Internet Backbone 9808 1574 8717 28 Guangdong Mobile Communicatio 4808 1428 2241 455 CNCGROUP IP network China169 9583 1416 117 577 Sify Limited 9498 1332 334 97 BHARTI Airtel Ltd. Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 22773 3031 2955 140 Cox Communications Inc. 6389 2801 3688 51 BellSouth.net Inc. 3356 2553 10684 479 Level 3 Communications, Inc. 18566 2036 378 181 MegaPath Corporation 20115 1879 1846 429 Charter Communications 6983 1752 866 246 EarthLink, Inc. 4323 1615 1022 410 tw telecom holdings, inc. 30036 1531 311 493 Mediacom Communications Corp 701 1390 11290 679 MCI Communications Services, 22561 1355 413 248 CenturyTel Internet Holdings, Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 39891 2472 128 6 SaudiNet, Saudi Telecom Compa 34984 1967 304 367 TELLCOM ILETISIM HIZMETLERI A 20940 1826 708 1338 Akamai International B.V. 6849 1213 356 24 JSC "Ukrtelecom" 31148 1049 45 23 Freenet Ltd. 13188 1035 96 68 TOV "Bank-Inform" 8402 1032 544 15 OJSC "Vimpelcom" 12479 925 867 80 France Telecom Espana SA 8551 885 373 48 Bezeq International-Ltd 9198 857 346 30 JSC Kazakhtelecom Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 10620 3226 527 184 Telmex Colombia S.A. 28573 2319 2169 117 NET Servi?os de Comunica??o S 7303 1660 1044 242 Telecom Argentina S.A. 8151 1602 3206 454 Uninet S.A. de C.V. 6503 1250 421 54 Axtel, S.A.B. de C.V. 6147 1222 374 30 Telefonica del Peru S.A.A. 7738 999 1882 41 Telemar Norte Leste S.A. 26615 964 2325 35 Tim Celular S.A. 3816 920 418 155 COLOMBIA TELECOMUNICACIONES S 18881 868 1036 22 Global Village Telecom Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 8452 1805 958 13 TE-AS 24863 960 284 27 Link Egypt (Link.NET) 36903 466 235 119 Office National des Postes et 36992 419 1229 32 ETISALAT MISR 37492 302 155 72 Orange Tunisie 24835 300 144 9 Vodafone Data 3741 250 857 208 Internet Solutions 29571 235 21 12 Cote d'Ivoire Telecom 36947 202 807 13 Telecom Algeria 37054 181 19 6 Data Telecom Service Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 10620 3226 527 184 Telmex Colombia S.A. 22773 3031 2955 140 Cox Communications Inc. 4766 2927 11557 912 Korea Telecom 6389 2801 3688 51 BellSouth.net Inc. 17974 2766 904 81 PT Telekomunikasi Indonesia 7545 2578 336 129 TPG Telecom Limited 3356 2553 10684 479 Level 3 Communications, Inc. 39891 2472 128 6 SaudiNet, Saudi Telecom Compa 28573 2319 2169 117 NET Servi?os de Comunica??o S 18566 2036 378 181 MegaPath Corporation Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 22773 3031 2891 Cox Communications Inc. 6389 2801 2750 BellSouth.net Inc. 17974 2766 2685 PT Telekomunikasi Indonesia 39891 2472 2466 SaudiNet, Saudi Telecom Compa 7545 2578 2449 TPG Telecom Limited 28573 2319 2202 NET Servi?os de Comunica??o S 3356 2553 2074 Level 3 Communications, Inc. 4766 2927 2015 Korea Telecom 18566 2036 1855 MegaPath Corporation 4538 1908 1836 China Education and Research Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 30662 UNALLOCATED 8.2.129.0/24 3356 Level 3 Communicatio 53506 UNALLOCATED 8.17.102.0/23 3356 Level 3 Communicatio 46467 UNALLOCATED 8.19.192.0/24 46887 Lightower Fiber Netw 18985 UNALLOCATED 8.21.68.0/22 3356 Level 3 Communicatio 46473 UNALLOCATED 8.27.122.0/24 12180 Internap Network Ser 46473 UNALLOCATED 8.27.124.0/24 12180 Internap Network Ser 27205 UNALLOCATED 8.38.16.0/21 6461 Abovenet Communicati 15347 UNALLOCATED 8.224.147.0/24 12064 Cox Communications I 33628 UNALLOCATED 12.0.239.0/24 1239 Sprint 32805 UNALLOCATED 12.1.225.0/24 7018 AT&T Services, Inc. Complete listing at http://thyme.rand.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 5.100.241.0/24 23456 32bit Transition AS 23.226.112.0/20 62788 >>UNKNOWN<< 27.100.7.0/24 56096 >>UNKNOWN<< 31.217.248.0/21 44902 COVAGE NETWORKS SASU 41.73.1.0/24 37004 >>UNKNOWN<< 41.73.10.0/24 37004 >>UNKNOWN<< 41.73.11.0/24 37004 >>UNKNOWN<< 41.73.12.0/24 37004 >>UNKNOWN<< 41.73.13.0/24 37004 >>UNKNOWN<< 41.73.15.0/24 37004 >>UNKNOWN<< Complete listing at http://thyme.rand.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:16 /9:12 /10:34 /11:94 /12:264 /13:505 /14:1006 /15:1713 /16:12969 /17:7208 /18:12292 /19:25282 /20:35936 /21:38557 /22:59396 /23:51660 /24:293364 /25:1134 /26:1132 /27:716 /28:14 /29:12 /30:7 /31:0 /32:13 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 39891 2432 2472 SaudiNet, Saudi Telecom Compa 22773 2243 3031 Cox Communications Inc. 18566 1992 2036 MegaPath Corporation 6389 1644 2801 BellSouth.net Inc. 6983 1398 1752 EarthLink, Inc. 30036 1371 1531 Mediacom Communications Corp 34984 1287 1967 TELLCOM ILETISIM HIZMETLERI A 10620 1138 3226 Telmex Colombia S.A. 11492 1113 1189 CABLE ONE, INC. 8452 1106 1805 TE-AS Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1483 2:675 4:94 5:1793 6:24 8:1418 11:1 12:1822 13:10 14:1331 15:17 16:2 17:43 18:21 20:48 23:1217 24:1705 27:1891 31:1562 32:38 33:2 34:5 35:3 36:118 37:1908 38:1027 39:5 40:251 41:3075 42:322 43:1261 44:26 45:504 46:2161 47:40 49:902 50:802 52:12 54:73 55:6 56:8 57:36 58:1276 59:717 60:473 61:1750 62:1332 63:1914 64:4406 65:2253 66:4043 67:2072 68:1052 69:3257 70:981 71:448 72:1954 74:2649 75:335 76:423 77:1413 78:1182 79:796 80:1334 81:1349 82:810 83:691 84:716 85:1347 86:392 87:1027 88:516 89:1826 90:151 91:5980 92:829 93:2226 94:2044 95:2114 96:429 97:353 98:1055 99:49 100:68 101:822 103:7361 104:1682 105:65 106:244 107:952 108:623 109:2046 110:1095 111:1488 112:794 113:1149 114:817 115:1264 116:1355 117:1055 118:1806 119:1450 120:448 121:1076 122:2141 123:1809 124:1507 125:1579 128:637 129:384 130:398 131:1189 132:488 133:174 134:425 135:107 136:327 137:315 138:687 139:149 140:239 141:442 142:670 143:501 144:565 145:115 146:699 147:590 148:1151 149:432 150:564 151:610 152:494 153:243 154:463 155:848 156:406 157:463 158:320 159:996 160:379 161:652 162:1923 163:419 164:670 165:690 166:304 167:821 168:1293 169:168 170:1471 171:261 172:45 173:1502 174:708 175:680 176:1247 177:3780 178:2155 179:877 180:1930 181:1596 182:1757 183:617 184:734 185:3429 186:2635 187:1742 188:2016 189:1586 190:7486 191:961 192:8315 193:5590 194:4126 195:3621 196:1706 197:1072 198:5549 199:5547 200:6635 201:3018 202:9444 203:9120 204:4678 205:2839 206:3090 207:2973 208:3942 209:3966 210:3536 211:1863 212:2509 213:2323 214:865 215:71 216:5582 217:1820 218:691 219:459 220:1445 221:787 222:478 223:677 End of report From larrysheldon at cox.net Fri May 8 18:39:45 2015 From: larrysheldon at cox.net (Larry Sheldon) Date: Fri, 08 May 2015 13:39:45 -0500 Subject: No subject In-Reply-To: References: <3BB50C80-3ED0-44D7-AFD9-484D7C03833B@gmail.com> <62174369-9641-45C8-BE0D-CF8955C9AF03@gmail.com> <205396510.16732.1430989931013.JavaMail.zimbra@pelican.org> <249EFAC3-8955-42E6-8DDD-8AEB1D3C2B86@spitwspots.com> <86ioc4xrh4.fsf@valhalla.seastrom.com> , <5490A8D4-7B1B-4AFF-BA55-FF594982A1D3@spitwspots.com> Message-ID: <554D02F1.40706@cox.net> Be advised that I have made changes to my personal spam traps to bin mailing list messages with attachments. -- sed quis custodiet ipsos custodes? (Juvenal) From larrysheldon at cox.net Fri May 8 18:40:46 2015 From: larrysheldon at cox.net (Larry Sheldon) Date: Fri, 08 May 2015 13:40:46 -0500 Subject: Mailing list messages with attachments (was Re:) In-Reply-To: References: <3BB50C80-3ED0-44D7-AFD9-484D7C03833B@gmail.com> <62174369-9641-45C8-BE0D-CF8955C9AF03@gmail.com> <205396510.16732.1430989931013.JavaMail.zimbra@pelican.org> <249EFAC3-8955-42E6-8DDD-8AEB1D3C2B86@spitwspots.com> <86ioc4xrh4.fsf@valhalla.seastrom.com> , <5490A8D4-7B1B-4AFF-BA55-FF594982A1D3@spitwspots.com> Message-ID: <554D032E.4030004@cox.net> Be advised that I have made changes to my personal spam traps to bin mailing list messages with attachments. -- sed quis custodiet ipsos custodes? (Juvenal) From tknchris at gmail.com Fri May 8 18:51:39 2015 From: tknchris at gmail.com (chris) Date: Fri, 8 May 2015 14:51:39 -0400 Subject: OSP list? In-Reply-To: <9607FC10-B17B-40F8-9375-2FC97292C958@imillerpr.com> References: <554CEFF6.5080407@spitwspots.com> <9607FC10-B17B-40F8-9375-2FC97292C958@imillerpr.com> Message-ID: I am getting site offline... Did we kill it? Lol On Fri, May 8, 2015 at 1:34 PM, Ilissa Miller wrote: > This could be a good resource - may have to dig a little: > http://www.ospmag.com/ > > > On May 8, 2015, at 1:18 PM, Josh Reynolds wrote: > > > WISPA has a fiber list for FTTx and hybrid deployments. It's not the > most active thing in the world, but there can still be good stuff on there. > > > > Josh Reynolds > > CIO, SPITwSPOTS > > www.spitwspots.com > > > > On 05/08/2015 08:57 AM, Dave Allen wrote: > >> Does anyone know of a mailing list or group devoted to the topic of > outside > >> plant fiber network design and construction? > > > > > Ilissa Miller > CEO, iMiller Public Relations > President, Northeast DAS + Small Cell Association > Sponsorship Sales Director, NANOG > Tel: 914.315.6424 > Cel: 917.743.0931 > eMail: ilissa at imillerpr.com > eMail: imiller at nanog.org > > www.imillerpr.com > www.northeastdas.com > www.nanog.org > > > > > > > > From johnl at iecc.com Fri May 8 18:53:03 2015 From: johnl at iecc.com (John Levine) Date: 8 May 2015 18:53:03 -0000 Subject: Thousands of hosts on a gigabit LAN, maybe not Message-ID: <20150508185303.55159.qmail@ary.lan> Some people I know (yes really) are building a system that will have several thousand little computers in some racks. Each of the computers runs Linux and has a gigabit ethernet interface. It occurs to me that it is unlikely that I can buy an ethernet switch with thousands of ports, and even if I could, would I want a Linux system to have 10,000 entries or more in its ARP table. Most of the traffic will be from one node to another, with considerably less to the outside. Physical distance shouldn't be a problem since everything's in the same room, maybe the same rack. What's the rule of thumb for number of hosts per switch, cascaded switches vs. routers, and whatever else one needs to design a dense network like this? TIA R's, John From ilissa at imillerpr.com Fri May 8 18:54:38 2015 From: ilissa at imillerpr.com (Ilissa Miller) Date: Fri, 8 May 2015 14:54:38 -0400 Subject: OSP list? In-Reply-To: References: <554CEFF6.5080407@spitwspots.com> <9607FC10-B17B-40F8-9375-2FC97292C958@imillerpr.com> Message-ID: I think you did! It was online earlier - their magazine is online too: http://digital.ospmag.com/#&pageSet=0&contentItem=0 They do have a directory issue for their magazine ... On May 8, 2015, at 2:51 PM, chris wrote: > I am getting site offline... Did we kill it? Lol > > On Fri, May 8, 2015 at 1:34 PM, Ilissa Miller wrote: > This could be a good resource - may have to dig a little: http://www.ospmag.com/ > > > On May 8, 2015, at 1:18 PM, Josh Reynolds wrote: > > > WISPA has a fiber list for FTTx and hybrid deployments. It's not the most active thing in the world, but there can still be good stuff on there. > > > > Josh Reynolds > > CIO, SPITwSPOTS > > www.spitwspots.com > > > > On 05/08/2015 08:57 AM, Dave Allen wrote: > >> Does anyone know of a mailing list or group devoted to the topic of outside > >> plant fiber network design and construction? > > > > > Ilissa Miller > CEO, iMiller Public Relations > President, Northeast DAS + Small Cell Association > Sponsorship Sales Director, NANOG > Tel: 914.315.6424 > Cel: 917.743.0931 > eMail: ilissa at imillerpr.com > eMail: imiller at nanog.org > > www.imillerpr.com > www.northeastdas.com > www.nanog.org > > > > > > > > Ilissa Miller CEO, iMiller Public Relations President, Northeast DAS + Small Cell Association Sponsorship Sales Director, NANOG Tel: 914.315.6424 Cel: 917.743.0931 eMail: ilissa at imillerpr.com eMail: imiller at nanog.org www.imillerpr.com www.northeastdas.com www.nanog.org From chuckchurch at gmail.com Fri May 8 19:18:32 2015 From: chuckchurch at gmail.com (Chuck Church) Date: Fri, 8 May 2015 15:18:32 -0400 Subject: Thousands of hosts on a gigabit LAN, maybe not In-Reply-To: <20150508185303.55159.qmail@ary.lan> References: <20150508185303.55159.qmail@ary.lan> Message-ID: <018401d089c3$c7bcc690$573653b0$@gmail.com> Sounds interesting. I wouldn't do more than a /23 (assuming IPv4) per subnet. Join them all together with a fast L3 switch. I'm still trying to visualize what several thousand tiny computers in a single rack might look like. Other than a cabling nightmare. 1000 RJ-45 switch ports is a good chuck of a rack itself. Chuck -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of John Levine Sent: Friday, May 08, 2015 2:53 PM To: nanog at nanog.org Subject: Thousands of hosts on a gigabit LAN, maybe not Some people I know (yes really) are building a system that will have several thousand little computers in some racks. Each of the computers runs Linux and has a gigabit ethernet interface. It occurs to me that it is unlikely that I can buy an ethernet switch with thousands of ports, and even if I could, would I want a Linux system to have 10,000 entries or more in its ARP table. Most of the traffic will be from one node to another, with considerably less to the outside. Physical distance shouldn't be a problem since everything's in the same room, maybe the same rack. What's the rule of thumb for number of hosts per switch, cascaded switches vs. routers, and whatever else one needs to design a dense network like this? TIA R's, John From morrowc.lists at gmail.com Fri May 8 19:19:43 2015 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Fri, 8 May 2015 15:19:43 -0400 Subject: Thousands of hosts on a gigabit LAN, maybe not In-Reply-To: <20150508185303.55159.qmail@ary.lan> References: <20150508185303.55159.qmail@ary.lan> Message-ID: On Fri, May 8, 2015 at 2:53 PM, John Levine wrote: > Some people I know (yes really) are building a system that will have > several thousand little computers in some racks. Each of the > computers runs Linux and has a gigabit ethernet interface. It occurs > to me that it is unlikely that I can buy an ethernet switch with > thousands of ports, and even if I could, would I want a Linux system > to have 10,000 entries or more in its ARP table. > > Most of the traffic will be from one node to another, with > considerably less to the outside. Physical distance shouldn't be a > problem since everything's in the same room, maybe the same rack. > > What's the rule of thumb for number of hosts per switch, cascaded > switches vs. routers, and whatever else one needs to design a dense > network like this? TIA consider the pain of also ipv6's link-local gamery. look at the nvo3 WG and it's predecessor (which shouldn't have really existed anyway, but whatever, and apparently my mind helped me forget about the pain involved with this wg) I think 'why one lan' ? why not just small (/26 or /24 max?) subnet sizes... or do it all in v6 on /64's with 1/rack or 1/~200 hosts. From dave.taht at gmail.com Fri May 8 19:26:16 2015 From: dave.taht at gmail.com (Dave Taht) Date: Fri, 8 May 2015 12:26:16 -0700 Subject: Thousands of hosts on a gigabit LAN, maybe not In-Reply-To: <20150508185303.55159.qmail@ary.lan> References: <20150508185303.55159.qmail@ary.lan> Message-ID: On Fri, May 8, 2015 at 11:53 AM, John Levine wrote: > Some people I know (yes really) are building a system that will have > several thousand little computers in some racks. Very cool-ly crazy. > Each of the > computers runs Linux and has a gigabit ethernet interface. It occurs > to me that it is unlikely that I can buy an ethernet switch with > thousands of ports, and even if I could, would I want a Linux system > to have 10,000 entries or more in its ARP table. Agreed. :) You don't really want 10,000 entries in a routing FIB table either, but I was seriously encouraged by the work going on in linux 4.0 and 4.1 to improve those lookups. https://netdev01.org/docs/duyck-fib-trie.pdf I'd love to know the actual scalability of some modern routing protocols (isis, babel, ospfv3, olsrv2, rpl) with that many nodes too.... > Most of the traffic will be from one node to another, with > considerably less to the outside. Physical distance shouldn't be a > problem since everything's in the same room, maybe the same rack. That is an awful lot of ports to fit in a rack (48 ports, 36 2U slots in the rack (and is that too high?) = 1728 ports) A thought is you could make it meshier using multiple interfaces per tiny linux box? Put, say 3-6 interfaces and have a very few switches interconnecting given clusters (and multiple paths to each switch). That would reduce your arp table (and fib table) by a lot at the cost of adding hops... > What's the rule of thumb for number of hosts per switch, cascaded > switches vs. routers, and whatever else one needs to design a dense > network like this? TIA max per vlan 4096. Still a lot. Another approach might be max density on a switch (48?) per cluster, routed (not switched) 10GigE to another 10GigE+ switch. I'd love to know the rule of thumbs here also, I imagine some rules must exist for those in the VM or VXLAN worlds. > R's, > John -- Dave T?ht Open Networking needs **Open Source Hardware** https://plus.google.com/u/0/+EricRaymond/posts/JqxCe2pFr67 From rafael at gav.ufsc.br Fri May 8 19:26:54 2015 From: rafael at gav.ufsc.br (Rafael Possamai) Date: Fri, 8 May 2015 14:26:54 -0500 Subject: Thousands of hosts on a gigabit LAN, maybe not In-Reply-To: <20150508185303.55159.qmail@ary.lan> References: <20150508185303.55159.qmail@ary.lan> Message-ID: - The more switches a packet has to go through, the higher the latency, so your response times may deteriorate if you cascade too many switches. Legend says up to 4 is a good number, any further you risk creating a big mess. - The more switches you add, the higher your bandwidth utilized by broadcasts in the same subnet. http://en.wikipedia.org/wiki/Broadcast_radiation - If you have only one connection between each switch, each switch is going to be limited to that rate (1gbps in this case), possibly creating a bottleneck depending on your application and how exactly it behaves. Consider aggregating uplinks. - Bundling too many Ethernet cables will cause interference (cross-talk), so keep that in mind. I'd purchase F/S/FTP cables and the like. Here I am going off on a tangent: if your friends want to build a "super computer" then there's a way to calculate the most "efficient" number of nodes given your constraints (e.g. linear optimization). This could save you time, money and headaches. An example: maximize the number of TFLOPS while minimizing number of nodes (i.e. number of switch ports). Just a quick thought. On Fri, May 8, 2015 at 1:53 PM, John Levine wrote: > Some people I know (yes really) are building a system that will have > several thousand little computers in some racks. Each of the > computers runs Linux and has a gigabit ethernet interface. It occurs > to me that it is unlikely that I can buy an ethernet switch with > thousands of ports, and even if I could, would I want a Linux system > to have 10,000 entries or more in its ARP table. > > Most of the traffic will be from one node to another, with > considerably less to the outside. Physical distance shouldn't be a > problem since everything's in the same room, maybe the same rack. > > What's the rule of thumb for number of hosts per switch, cascaded > switches vs. routers, and whatever else one needs to design a dense > network like this? TIA > > R's, > John > From lists.nanog at monmotha.net Fri May 8 19:41:31 2015 From: lists.nanog at monmotha.net (Brandon Martin) Date: Fri, 08 May 2015 15:41:31 -0400 Subject: Thousands of hosts on a gigabit LAN, maybe not In-Reply-To: <20150508185303.55159.qmail@ary.lan> References: <20150508185303.55159.qmail@ary.lan> Message-ID: <554D116B.4000102@monmotha.net> On 05/08/2015 02:53 PM, John Levine wrote: > Some people I know (yes really) are building a system that will have > several thousand little computers in some racks. Each of the > computers runs Linux and has a gigabit ethernet interface. It occurs > to me that it is unlikely that I can buy an ethernet switch with > thousands of ports, and even if I could, would I want a Linux system > to have 10,000 entries or more in its ARP table. > > Most of the traffic will be from one node to another, with > considerably less to the outside. Physical distance shouldn't be a > problem since everything's in the same room, maybe the same rack. > > What's the rule of thumb for number of hosts per switch, cascaded > switches vs. routers, and whatever else one needs to design a dense > network like this? TIA Unless you have some dire need to get these all on the same broadcast domain, those kind of numbers on a single L2 would send me running for the hills for lots of reasons, some of which you've identified. I'd find a good L3 switch and put no more ~200-500 IPs on each L2 and let the switch handle gluing it together at L3. With the proper hardware, this is a fully line-rate operation and should have no real downsides aside from splitting up the broadcast domains (if you do need multicast, make sure your gear can do it). With a divide-and-conquer approach, you shouldn't have problems fitting the L2+L3 tables into even a pretty modest L3 switch. Densest chassis switches I know of are going to be gets about 96 ports per RU (48 ports each on a half-width blade, but you need breakout panels to get standard RJ45 8P8C connectors as the blades have MRJ21s) less rack overhead for power supplies, management, etc.. That should get you ~2000 ports per rack [1]. Such switches can be quite expensive. The trend seems to be toward stacking pizza boxes these days, though. Get the number of ports you need per rack (you're presumably not putting all 10,000 nodes in a single rack) and aggregate up one or two layers. This gives you a pretty good candidate for your L2/L3 split. [1] Purely as an example, you can cram 3x Brocade MLX-16 chassis into a 42U rack (with 0RU to spare). That gives you 48 slots for line cards. Leaving at least one slot in each chassis for 10Gb or 100Gb uplinks to something else, 45x48 = 2160 1000BASE-T ports (electrically) in a 42U rack, and you'll need 45 more RU somewhere for breakout patch panels! -- Brandon Martin From mfidelman at meetinghouse.net Fri May 8 19:53:28 2015 From: mfidelman at meetinghouse.net (Miles Fidelman) Date: Fri, 08 May 2015 15:53:28 -0400 Subject: Thousands of hosts on a gigabit LAN, maybe not In-Reply-To: <20150508185303.55159.qmail@ary.lan> References: <20150508185303.55159.qmail@ary.lan> Message-ID: <554D1438.8020808@meetinghouse.net> John Levine wrote: > Some people I know (yes really) are building a system that will have > several thousand little computers in some racks. Each of the > computers runs Linux and has a gigabit ethernet interface. It occurs > to me that it is unlikely that I can buy an ethernet switch with > thousands of ports, and even if I could, would I want a Linux system > to have 10,000 entries or more in its ARP table. > > Most of the traffic will be from one node to another, with > considerably less to the outside. Physical distance shouldn't be a > problem since everything's in the same room, maybe the same rack. > > What's the rule of thumb for number of hosts per switch, cascaded > switches vs. routers, and whatever else one needs to design a dense > network like this? TIA > > It's become fairly commonplace to build supercomputers out of clusters of 100s, or 1000s of commodity PCs, see, for example: www.rocksclusters.org http://www.rocksclusters.org/presentations/tutorial/tutorial-1.pdf or http://www.dodlive.mil/files/2010/12/CondorSupercomputerbrochure_101117_kb-3.pdf (a cluster of 1760 playstations at AFRL Rome Labs) Interestingly, all the documentation I can find is heavy on the software layers used to cluster resources - but there's little about hardware configuration other than pretty pictures of racks with lots of CPUs and lots of wires. If the people you know are trying to do something similar - it might be worth some nosing around the Rocks community, or some phone calls. I expect that interconnect architecture and latency might be a bit of an issue for this sort of application. Miles Fidelman -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From blake at ispn.net Fri May 8 19:54:16 2015 From: blake at ispn.net (Blake Hudson) Date: Fri, 08 May 2015 14:54:16 -0500 Subject: Thousands of hosts on a gigabit LAN, maybe not In-Reply-To: <20150508185303.55159.qmail@ary.lan> References: <20150508185303.55159.qmail@ary.lan> Message-ID: <554D1468.7010004@ispn.net> Linux has a (configurable) limit on the neighbor table. I know in RHEL variants, the default has been 1024 neighbors for a while. net.ipv4.neigh.default.gc_thresh3 net.ipv4.neigh.default.gc_thresh2 net.ipv4.neigh.default.gc_thresh1 net.ipv6.neigh.default.gc_thresh3 net.ipv6.neigh.default.gc_thresh2 net.ipv6.neigh.default.gc_thresh1 These may be rough guidelines for performance or arbitrary limits someone thought would be a good idea. Either way, you'll need to increase the number if you're using IP on Linux. Although not explicitly stated, I would assume that these computers may be virtualized or inside some sort of blade chassis (which reduces the number of physical cables to a switch). Strictly speaking, I see no hardware limitation in your way, as most top of rack switches will easily do a few thousand or 10's of thousands of MAC entries and a few thousand hosts can fit inside a single IP4 or IP6 subnet. There are some pretty dense switches if you actually do need 1000 ports, but as others have stated, you'll utilize a good portion of the rack in cable and connectors. --Blake From skhosla at neutraldata.com Fri May 8 19:55:25 2015 From: skhosla at neutraldata.com (Sameer Khosla) Date: Fri, 8 May 2015 19:55:25 +0000 Subject: Thousands of hosts on a gigabit LAN, maybe not In-Reply-To: <20150508185303.55159.qmail@ary.lan> References: <20150508185303.55159.qmail@ary.lan> Message-ID: <49A81EB09F493442B6D259E36251192C01719B65D8@ndcc-exch1.neutraldata.com> You may want to look at CLOS / leaf/spine architecture. This design tends to be optimized for east-west traffic, scales easily as bandwidth needs grow, and keeps thing simple, l2/l3 boundry on the ToR switch, L3 ECMP from leaf to spine. Not a lot of complexity and scale fairly high on both leafs and spines. Sk. -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of John Levine Sent: Friday, May 08, 2015 2:53 PM To: nanog at nanog.org Subject: Thousands of hosts on a gigabit LAN, maybe not Some people I know (yes really) are building a system that will have several thousand little computers in some racks. Each of the computers runs Linux and has a gigabit ethernet interface. It occurs to me that it is unlikely that I can buy an ethernet switch with thousands of ports, and even if I could, would I want a Linux system to have 10,000 entries or more in its ARP table. Most of the traffic will be from one node to another, with considerably less to the outside. Physical distance shouldn't be a problem since everything's in the same room, maybe the same rack. What's the rule of thumb for number of hosts per switch, cascaded switches vs. routers, and whatever else one needs to design a dense network like this? TIA R's, John From mfidelman at meetinghouse.net Fri May 8 20:02:13 2015 From: mfidelman at meetinghouse.net (Miles Fidelman) Date: Fri, 08 May 2015 16:02:13 -0400 Subject: Thousands of hosts on a gigabit LAN, maybe not In-Reply-To: <554D1438.8020808@meetinghouse.net> References: <20150508185303.55159.qmail@ary.lan> <554D1438.8020808@meetinghouse.net> Message-ID: <554D1645.8090303@meetinghouse.net> Forgot to mention - you might also want to check out Beowulf clusters - there's an email list at http://www.beowulf.org/ - probably some useful info in the list archives, maybe a good place to post your query. Miles Miles Fidelman wrote: > John Levine wrote: >> Some people I know (yes really) are building a system that will have >> several thousand little computers in some racks. Each of the >> computers runs Linux and has a gigabit ethernet interface. It occurs >> to me that it is unlikely that I can buy an ethernet switch with >> thousands of ports, and even if I could, would I want a Linux system >> to have 10,000 entries or more in its ARP table. >> >> Most of the traffic will be from one node to another, with >> considerably less to the outside. Physical distance shouldn't be a >> problem since everything's in the same room, maybe the same rack. >> >> What's the rule of thumb for number of hosts per switch, cascaded >> switches vs. routers, and whatever else one needs to design a dense >> network like this? TIA >> >> > > It's become fairly commonplace to build supercomputers out of clusters > of 100s, or 1000s of commodity PCs, see, for example: > www.rocksclusters.org > http://www.rocksclusters.org/presentations/tutorial/tutorial-1.pdf > or > http://www.dodlive.mil/files/2010/12/CondorSupercomputerbrochure_101117_kb-3.pdf > (a cluster of 1760 playstations at AFRL Rome Labs) > > Interestingly, all the documentation I can find is heavy on the > software layers used to cluster resources - but there's little about > hardware configuration other than pretty pictures of racks with lots > of CPUs and lots of wires. > > If the people you know are trying to do something similar - it might > be worth some nosing around the Rocks community, or some phone calls. > I expect that interconnect architecture and latency might be a bit of > an issue for this sort of application. > > Miles Fidelman > > > > -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From johnl at iecc.com Fri May 8 20:05:52 2015 From: johnl at iecc.com (John Levine) Date: 8 May 2015 20:05:52 -0000 Subject: Thousands of hosts on a gigabit LAN, maybe not In-Reply-To: Message-ID: <20150508200552.55426.qmail@ary.lan> >> to have 10,000 entries or more in its ARP table. > >Agreed. :) You don't really want 10,000 entries in a routing FIB >table either, but I was seriously encouraged by the work going >on in linux 4.0 and 4.1 to improve those lookups. One obvious way to deal with that is to put some manageable number of hosts on a subnet and route traffic between the subnets. I think we can assume they'll all have 10/8 addresses, and I'm not too worried about performance to the outside world, just within the network. R's, John From briansupport at hotmail.com Fri May 8 20:16:03 2015 From: briansupport at hotmail.com (Brian R) Date: Fri, 8 May 2015 13:16:03 -0700 Subject: Thousands of hosts on a gigabit LAN, maybe not In-Reply-To: <20150508185303.55159.qmail@ary.lan> References: <20150508185303.55159.qmail@ary.lan> Message-ID: Agree with many of the other comments. Smaller subnets (the /23 suggestion sounds good) with L3 between the subnets. The first thing that came to mind was "Bitcoin farm!" then "Ask Bitmaintech" and then "I'd be more worried about the number of fans and A/C units". Brian > Date: Fri, 8 May 2015 18:53:03 +0000 > From: johnl at iecc.com > To: nanog at nanog.org > Subject: Thousands of hosts on a gigabit LAN, maybe not > > Some people I know (yes really) are building a system that will have > several thousand little computers in some racks. Each of the > computers runs Linux and has a gigabit ethernet interface. It occurs > to me that it is unlikely that I can buy an ethernet switch with > thousands of ports, and even if I could, would I want a Linux system > to have 10,000 entries or more in its ARP table. > > Most of the traffic will be from one node to another, with > considerably less to the outside. Physical distance shouldn't be a > problem since everything's in the same room, maybe the same rack. > > What's the rule of thumb for number of hosts per switch, cascaded > switches vs. routers, and whatever else one needs to design a dense > network like this? TIA > > R's, > John From niels=nanog at bakker.net Fri May 8 20:17:14 2015 From: niels=nanog at bakker.net (Niels Bakker) Date: Fri, 8 May 2015 22:17:14 +0200 Subject: Thousands of hosts on a gigabit LAN, maybe not In-Reply-To: <554D116B.4000102@monmotha.net> References: <20150508185303.55159.qmail@ary.lan> <554D116B.4000102@monmotha.net> Message-ID: <20150508201714.GB3166@excession.tpb.net> * lists.nanog at monmotha.net (Brandon Martin) [Fri 08 May 2015, 21:42 CEST]: >[1] Purely as an example, you can cram 3x Brocade MLX-16 chassis into >a 42U rack (with 0RU to spare). That gives you 48 slots for line cards. You really can't. Cables need to come from the top, not from the sides, or they'll block the path of other linecards. -- Niels. From johnl at iecc.com Fri May 8 20:19:41 2015 From: johnl at iecc.com (John R. Levine) Date: 8 May 2015 16:19:41 -0400 Subject: Thousands of hosts on a gigabit LAN, maybe not In-Reply-To: References: <20150508185303.55159.qmail@ary.lan> Message-ID: > > The first thing that came to mind was "Bitcoin farm!" then "Ask Bitmaintech" and then "I'd be more worried about the number of fans and A/C units". > I promise, no bitcoins involved. R's, John From bensons at queuefull.net Fri May 8 20:25:32 2015 From: bensons at queuefull.net (Benson Schliesser) Date: Fri, 08 May 2015 13:25:32 -0700 Subject: Thousands of hosts on a gigabit LAN, maybe not In-Reply-To: References: <20150508185303.55159.qmail@ary.lan> Message-ID: <554D1BBC.5040006@queuefull.net> Morrow's comment about the ARMD WG notwithstanding, there might be some useful context in https://tools.ietf.org/html/draft-karir-armd-statistics-01 Cheers, -Benson > Christopher Morrow > May 8, 2015 at 12:19 PM > > consider the pain of also ipv6's link-local gamery. > look at the nvo3 WG and it's predecessor (which shouldn't have really > existed anyway, but whatever, and apparently my mind helped me forget > about the pain involved with this wg) > > I think 'why one lan' ? why not just small (/26 or /24 max?) subnet > sizes... or do it all in v6 on /64's with 1/rack or 1/~200 hosts. > John Levine > May 8, 2015 at 11:53 AM > Some people I know (yes really) are building a system that will have > several thousand little computers in some racks. Each of the > computers runs Linux and has a gigabit ethernet interface. It occurs > to me that it is unlikely that I can buy an ethernet switch with > thousands of ports, and even if I could, would I want a Linux system > to have 10,000 entries or more in its ARP table. > > Most of the traffic will be from one node to another, with > considerably less to the outside. Physical distance shouldn't be a > problem since everything's in the same room, maybe the same rack. > > What's the rule of thumb for number of hosts per switch, cascaded > switches vs. routers, and whatever else one needs to design a dense > network like this? TIA > > R's, > John From lists.nanog at monmotha.net Fri May 8 20:28:06 2015 From: lists.nanog at monmotha.net (Brandon Martin) Date: Fri, 08 May 2015 16:28:06 -0400 Subject: Thousands of hosts on a gigabit LAN, maybe not In-Reply-To: <20150508201714.GB3166@excession.tpb.net> References: <20150508185303.55159.qmail@ary.lan> <554D116B.4000102@monmotha.net> <20150508201714.GB3166@excession.tpb.net> Message-ID: <554D1C56.1020902@monmotha.net> On 05/08/2015 04:17 PM, Niels Bakker wrote: > * lists.nanog at monmotha.net (Brandon Martin) [Fri 08 May 2015, 21:42 CEST]: >> [1] Purely as an example, you can cram 3x Brocade MLX-16 chassis into >> a 42U rack (with 0RU to spare). That gives you 48 slots for line cards. > > You really can't. Cables need to come from the top, not from the sides, > or they'll block the path of other linecards. Hum, good point. "Cram" may not be a strong enough term :) It'd work on the horizontal slot chassis types (4/8 slot), but not the vertical (16/32 slot). You might be able to make it fit if you didn't care about maintainability, I guess. There's some room to maneuver if you don't care about being able to get the power supplies out, too. I don't recommend this approach... Those MRJ21 cables are not easy to work with as it is. -- Brandon Martin From charles at thefnf.org Fri May 8 20:40:28 2015 From: charles at thefnf.org (charles at thefnf.org) Date: Fri, 08 May 2015 15:40:28 -0500 Subject: Thousands of hosts on a gigabit LAN, maybe not In-Reply-To: <20150508185303.55159.qmail@ary.lan> References: <20150508185303.55159.qmail@ary.lan> Message-ID: On 2015-05-08 13:53, John Levine wrote: > Some people I know (yes really) are building a system that will have > several thousand little computers in some racks. How many racks? How many computers per rack unit? How many computers per rack? (How are you handling power?) How big is each computer? Do you want network cabling to be contained to each rack? Or do you want to run the cable to a central networking/switching rack? Hmmmm even a 6513 fully populated with POE 48 port line cards (which could let you do power and network in the same cable (I think? Does POE work on gigabit these days)? would get you (12*48 = 576) ports. So.... 48U rack - 15U (I think the 6513 is 15U total) leaves you 33U. Can you fit 576 systems in 33U? Each of the > computers runs Linux and has a gigabit ethernet interface. Copper? It occurs > to me that it is unlikely that I can buy an ethernet switch with > thousands of ports 6515? , and even if I could, would I want a Linux system > to have 10,000 entries or more in its ARP table. > Add more ram. That's always the answer. LOL. > Most of the traffic will be from one node to another, with > considerably less to the outside. Physical distance shouldn't be a > problem since everything's in the same room, maybe the same rack. > > What's the rule of thumb for number of hosts per switch, cascaded > switches vs. routers, and whatever else one needs to design a dense > network like this? TIA We need more data. From betty at nanog.org Fri May 8 21:52:16 2015 From: betty at nanog.org (Betty Burke ) Date: Fri, 8 May 2015 17:52:16 -0400 Subject: [NANOG-announce] NANOG 64 Reminders Message-ID: NANOGers, As we continue our final preparations in support of NANOG 64, June 1-3, 2015 in San Francisco, let me share the following highlights and reminders: - The NANOG 64 Agenda is posted, and updates will continue to be provided. - Be sure to note the Registration Fee Schedule - Standard Registration starting April 1, 2015 - (non-member $525, member $500, student $100) - Late Registration starting May 23, 2015 - (non-member $600, member $575, student $100) - On-Site Registration starting May 31, 2015 - (non-member $675, member $650, student $100) - Cancellation Fee: $50.00, 2 weeks before meeting cancellation fee is $100.00 - May 18, 2015 - *No refund will be offered after May 31, 2015. - Also, take a moment to join NANOG, or be sure to renew your existing Membership . - The hotel room blocks are becoming stressed. Do make your hotel room reservation quickly. - We welcome those 503 attendees and conference sponsors already planning to join us for NANOG 64. - You will find a new Peering Personals activity on Monday, and will be treated to Sponsor Socials on Sunday, Monday, and Tuesday evenings. The ever famous, must attend event, BnG will be on Tuesday at the close of NANOG programming. We encourage those not yet registered to do so, and join us for what will be another large and exciting June NANOG meeting! Should you have any questions, contact us at nanog-support at nanog.org. See you soon! Sincerely, Betty -------------- next part -------------- _______________________________________________ NANOG-announce mailing list NANOG-announce at mailman.nanog.org http://mailman.nanog.org/mailman/listinfo/nanog-announce From cidr-report at potaroo.net Fri May 8 22:00:01 2015 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 8 May 2015 22:00:01 GMT Subject: The Cidr Report Message-ID: <201505082200.t48M01Ln061159@wattle.apnic.net> This report has been generated at Fri May 8 21:14:42 2015 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/2.0 for a current version of this report. Recent Table History Date Prefixes CIDR Agg 01-05-15 549780 302345 02-05-15 549975 302322 03-05-15 549810 302602 04-05-15 550100 302954 05-05-15 549974 302765 06-05-15 549964 302600 07-05-15 550322 303393 08-05-15 550752 303572 AS Summary 50526 Number of ASes in routing system 20158 Number of ASes announcing only one prefix 3226 Largest number of prefixes announced by an AS AS10620: Telmex Colombia S.A.,CO 120959488 Largest address span announced by an AS (/32s) AS4134 : CHINANET-BACKBONE No.31,Jin-rong Street,CN 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'). --- 08May15 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 550224 303500 246724 44.8% All ASes AS22773 3033 169 2864 94.4% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc.,US AS17974 2766 81 2685 97.1% TELKOMNET-AS2-AP PT Telekomunikasi Indonesia,ID AS6389 2801 182 2619 93.5% BELLSOUTH-NET-BLK - BellSouth.net Inc.,US AS39891 2473 29 2444 98.8% ALJAWWALSTC-AS Saudi Telecom Company JSC,SA AS28573 2319 310 2009 86.6% NET Servi?os de Comunica??o S.A.,BR AS3356 2557 682 1875 73.3% LEVEL3 - Level 3 Communications, Inc.,US AS4766 2927 1337 1590 54.3% KIXS-AS-KR Korea Telecom,KR AS9808 1574 67 1507 95.7% CMNET-GD Guangdong Mobile Communication Co.Ltd.,CN AS6983 1751 249 1502 85.8% ITCDELTA - Earthlink, Inc.,US AS7545 2624 1160 1464 55.8% TPG-INTERNET-AP TPG Telecom Limited,AU AS20115 1879 493 1386 73.8% CHARTER-NET-HKY-NC - Charter Communications,US AS10620 3226 1851 1375 42.6% Telmex Colombia S.A.,CO AS7303 1660 292 1368 82.4% Telecom Argentina S.A.,AR AS4755 2012 713 1299 64.6% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP,IN AS9498 1332 112 1220 91.6% BBIL-AP BHARTI Airtel Ltd.,IN AS4323 1622 412 1210 74.6% TWTC - tw telecom holdings, inc.,US AS18566 2036 869 1167 57.3% MEGAPATH5-US - MegaPath Corporation,US AS7552 1157 58 1099 95.0% VIETEL-AS-AP Viettel Corporation,VN AS22561 1357 286 1071 78.9% CENTURYLINK-LEGACY-LIGHTCORE - CenturyTel Internet Holdings, Inc.,US AS6147 1222 202 1020 83.5% Telefonica del Peru S.A.A.,PE AS8402 1026 24 1002 97.7% CORBINA-AS OJSC "Vimpelcom",RU AS6849 1210 240 970 80.2% UKRTELNET JSC UKRTELECOM,UA AS8151 1606 667 939 58.5% Uninet S.A. de C.V.,MX AS7738 999 83 916 91.7% Telemar Norte Leste S.A.,BR AS38285 982 119 863 87.9% M2TELECOMMUNICATIONS-AU M2 Telecommunications Group Ltd,AU AS4538 1926 1075 851 44.2% ERX-CERNET-BKB China Education and Research Network Center,CN AS18881 868 39 829 95.5% Global Village Telecom,BR AS26615 963 166 797 82.8% Tim Celular S.A.,BR AS24560 1237 462 775 62.7% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services,IN AS18101 964 195 769 79.8% RELIANCE-COMMUNICATIONS-IN Reliance Communications Ltd.DAKC MUMBAI,IN Total 54109 12624 41485 76.7% Top 30 total Possible Bogus Routes 5.100.241.0/24 AS19957 -Reserved AS-,ZZ 23.226.112.0/20 AS62788 -Reserved AS-,ZZ 27.100.7.0/24 AS56096 31.217.248.0/21 AS44902 COV-ASN COVAGE NETWORKS SASU,FR 41.73.1.0/24 AS37004 -Reserved AS-,ZZ 41.73.10.0/24 AS37004 -Reserved AS-,ZZ 41.73.11.0/24 AS37004 -Reserved AS-,ZZ 41.73.12.0/24 AS37004 -Reserved AS-,ZZ 41.73.13.0/24 AS37004 -Reserved AS-,ZZ 41.73.15.0/24 AS37004 -Reserved AS-,ZZ 41.73.16.0/24 AS37004 -Reserved AS-,ZZ 41.73.18.0/24 AS37004 -Reserved AS-,ZZ 41.73.20.0/24 AS37004 -Reserved AS-,ZZ 41.73.21.0/24 AS37004 -Reserved AS-,ZZ 41.76.48.0/21 AS36969 MTL-AS,MW 41.78.180.0/23 AS37265 -Reserved AS-,ZZ 41.189.96.0/20 AS37000 -Reserved AS-,ZZ 41.189.127.0/24 AS37000 -Reserved AS-,ZZ 41.189.128.0/24 AS37000 -Reserved AS-,ZZ 41.191.108.0/22 AS37004 -Reserved AS-,ZZ 41.191.108.0/24 AS37004 -Reserved AS-,ZZ 41.191.109.0/24 AS37004 -Reserved AS-,ZZ 41.191.110.0/24 AS37004 -Reserved AS-,ZZ 41.191.111.0/24 AS37004 -Reserved AS-,ZZ 41.223.208.0/22 AS37000 -Reserved AS-,ZZ 41.242.152.0/22 AS37558 LITC,LY 41.242.156.0/22 AS37558 LITC,LY 45.67.78.0/24 AS38040 GLOBAL-TRANSIT-TOT-IIG-TH TOT Public Company Limited,TH 65.75.216.0/23 AS10494 AAI - Accurate Automation, Inc.,US 65.75.217.0/24 AS10494 AAI - Accurate Automation, Inc.,US 65.111.1.0/24 AS32258 SDNGLOBAL - SDN Global,US 66.78.66.0/23 AS10835 VISIONARY - Visionary Communications, Inc.,US 66.78.68.0/22 AS10835 VISIONARY - Visionary Communications, Inc.,US 66.78.76.0/23 AS10835 VISIONARY - Visionary Communications, Inc.,US 66.78.80.0/21 AS10835 VISIONARY - Visionary Communications, Inc.,US 66.78.91.0/24 AS10835 VISIONARY - Visionary Communications, Inc.,US 66.180.64.0/21 AS32558 ZEUTER - Zeuter Development Corporation,CA 66.187.240.0/20 AS14552 ACS-SOUTHEASTDATACENTER - Affiliated Computer Services, Inc.,US 66.205.224.0/19 AS16526 BIRCH-TELECOM - Birch Telecom, Inc.,US 66.251.128.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.133.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.134.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.136.0/21 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.140.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.141.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.142.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 72.19.0.0/19 AS16526 BIRCH-TELECOM - Birch Telecom, Inc.,US 74.113.200.0/23 AS46939 -Reserved AS-,ZZ 74.114.52.0/22 AS40818 -Reserved AS-,ZZ 74.114.52.0/23 AS40818 -Reserved AS-,ZZ 74.114.52.0/24 AS40818 -Reserved AS-,ZZ 74.114.53.0/24 AS40818 -Reserved AS-,ZZ 74.114.54.0/23 AS40818 -Reserved AS-,ZZ 74.114.54.0/24 AS40818 -Reserved AS-,ZZ 74.114.55.0/24 AS40818 -Reserved AS-,ZZ 74.114.184.0/22 AS19888 -Reserved AS-,ZZ 74.121.24.0/22 AS36263 FORONA - Forona Technologies, Inc.,US 74.123.136.0/21 AS53358 -Reserved AS-,ZZ 77.243.91.0/24 AS42597 -Reserved AS-,ZZ 80.78.133.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US 80.78.134.0/23 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US 80.78.134.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US 80.78.135.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US 80.250.32.0/22 AS37106 ODUA-AS,NG 83.142.48.0/24 AS13213 UK2NET-AS UK2 - Ltd,GB 83.142.49.0/24 AS13213 UK2NET-AS UK2 - Ltd,GB 91.103.8.0/24 AS42551 -Reserved AS-,ZZ 91.103.9.0/24 AS42551 -Reserved AS-,ZZ 91.103.10.0/24 AS42551 -Reserved AS-,ZZ 91.103.11.0/24 AS42551 -Reserved AS-,ZZ 91.193.60.0/22 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 91.195.66.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 91.197.36.0/22 AS43359 -Reserved AS-,ZZ 91.230.27.0/24 AS57022 -Reserved AS-,ZZ 98.143.160.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.161.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.162.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.163.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.164.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.165.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.166.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.167.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.168.0/22 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.172.0/22 AS26566 -Reserved AS-,ZZ 98.143.172.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.173.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.174.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.175.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 102.69.1.0/24 AS59749 CLEANMAT CLEANMAT EOOD,BG 103.6.248.0/22 AS13220 103.6.248.0/24 AS13220 103.6.249.0/24 AS13220 103.6.250.0/24 AS13220 103.6.251.0/24 AS13220 103.7.120.0/22 AS4725 ODN SOFTBANK TELECOM Corp.,JP 103.10.222.0/24 AS13189 103.15.92.0/22 AS23818 JETINTERNET JETINTERNET Corporation,JP 103.20.100.0/24 AS45334 AIRCEL-AS-AP Dishnet Wireless Limited,IN 103.20.101.0/24 AS45334 AIRCEL-AS-AP Dishnet Wireless Limited,IN 103.20.219.0/24 AS55795 VERBDC1-AS-AP Verb Data Centre Pty Ltd,AU 103.23.96.0/22 AS13220 103.23.96.0/24 AS13220 103.23.97.0/24 AS13220 103.23.98.0/24 AS13220 103.23.99.0/24 AS13220 103.23.148.0/23 AS13209 103.23.148.0/24 AS13209 103.23.149.0/24 AS13209 103.26.116.0/22 AS17676 GIGAINFRA Softbank BB Corp.,JP 103.28.184.0/22 AS4686 BEKKOAME BEKKOAME INTERNET INC.,JP 103.224.0.0/22 AS18097 DCN D.C.N. Corporation,JP 103.225.116.0/22 AS23818 JETINTERNET JETINTERNET Corporation,JP 103.232.142.0/23 AS17828 TIARE-AS-PG Tiare, a business unit of Pacific Mobile Communications.,PG 103.244.112.0/22 AS23818 JETINTERNET JETINTERNET Corporation,JP 103.248.88.0/22 AS23818 JETINTERNET JETINTERNET Corporation,JP 103.248.220.0/22 AS17676 GIGAINFRA Softbank BB Corp.,JP 103.250.0.0/22 AS17676 GIGAINFRA Softbank BB Corp.,JP 103.253.100.0/24 AS63975 SZWSNT-AS Long Live Network Technology,CN 103.253.101.0/24 AS63975 SZWSNT-AS Long Live Network Technology,CN 103.253.102.0/24 AS63975 SZWSNT-AS Long Live Network Technology,CN 103.253.103.0/24 AS63975 SZWSNT-AS Long Live Network Technology,CN 103.253.164.0/23 AS13317 103.254.248.0/24 AS63975 SZWSNT-AS Long Live Network Technology,CN 103.254.249.0/24 AS63975 SZWSNT-AS Long Live Network Technology,CN 103.254.250.0/24 AS63975 SZWSNT-AS Long Live Network Technology,CN 103.254.251.0/24 AS63975 SZWSNT-AS Long Live Network Technology,CN 103.255.56.0/22 AS18097 DCN D.C.N. Corporation,JP 103.255.132.0/22 AS18097 DCN D.C.N. Corporation,JP 111.92.184.0/22 AS9797 NEXONASIAPACIFIC-AS-AP Nexon Asia Pacific P/L,AU 116.206.72.0/24 AS6461 ABOVENET - Abovenet Communications, Inc,US 116.206.85.0/24 AS6461 ABOVENET - Abovenet Communications, Inc,US 116.206.103.0/24 AS6461 ABOVENET - Abovenet Communications, Inc,US 117.120.56.0/21 AS4755 TATACOMM-AS TATA Communications formerly VSNL is Leading ISP,IN 121.54.184.0/21 AS59092 KRONOS kronos.Co.,Ltd.,JP 142.147.62.0/24 AS3958 AIRCANADA - Air Canada,CA 154.168.28.0/23 AS29571 CITelecom-AS,CI 158.222.104.0/21 AS11290 RAPIDUS - COGECO Cable Canada Inc.,CA 162.216.176.0/22 AS36114 VERSAWEB-ASN - Versaweb, LLC,US 162.222.128.0/21 AS36114 VERSAWEB-ASN - Versaweb, LLC,US 162.245.64.0/21 AS62788 -Reserved AS-,ZZ 162.248.224.0/21 AS62788 -Reserved AS-,ZZ 166.93.0.0/16 AS23537 CRITIGEN - Micro Source, Inc.,US 167.146.16.0/21 AS22527 -Reserved AS-,ZZ 167.146.26.0/23 AS22527 -Reserved AS-,ZZ 167.146.28.0/23 AS22527 -Reserved AS-,ZZ 167.146.32.0/20 AS22527 -Reserved AS-,ZZ 167.146.44.0/24 AS22527 -Reserved AS-,ZZ 167.146.48.0/22 AS22527 -Reserved AS-,ZZ 167.146.90.0/24 AS22527 -Reserved AS-,ZZ 167.146.93.0/24 AS22527 -Reserved AS-,ZZ 167.146.94.0/24 AS22527 -Reserved AS-,ZZ 167.146.100.0/24 AS22527 -Reserved AS-,ZZ 167.146.104.0/24 AS22527 -Reserved AS-,ZZ 167.146.105.0/24 AS22527 -Reserved AS-,ZZ 167.146.128.0/20 AS22527 -Reserved AS-,ZZ 167.146.137.0/24 AS22527 -Reserved AS-,ZZ 167.146.144.0/20 AS22527 -Reserved AS-,ZZ 167.146.160.0/20 AS22527 -Reserved AS-,ZZ 167.146.200.0/22 AS22527 -Reserved AS-,ZZ 167.146.204.0/24 AS22527 -Reserved AS-,ZZ 167.146.205.0/24 AS22527 -Reserved AS-,ZZ 172.102.0.0/22 AS4812 CHINANET-SH-AP China Telecom (Group),CN 173.45.192.0/20 AS62722 -Reserved AS-,ZZ 173.45.208.0/20 AS62722 -Reserved AS-,ZZ 185.17.98.0/23 AS19798 HILF-AS Hilf Telecom B.V.,NL 185.99.164.0/22 AS60257 ORIGIN Origin Broadband Limited,GB 192.9.0.0/16 AS11479 BRM-SUN-AS - Sun Microsystems, Inc,US 192.25.10.0/24 AS5714 HPES - Hewlett-Packard Company,US 192.25.11.0/24 AS5714 HPES - Hewlett-Packard Company,US 192.25.13.0/24 AS5714 HPES - Hewlett-Packard Company,US 192.25.14.0/24 AS5714 HPES - Hewlett-Packard Company,US 192.34.152.0/21 AS10835 VISIONARY - Visionary Communications, Inc.,US 192.75.23.0/24 AS2579 AS2579 - Alcatel-Lucent,FR 192.75.239.0/24 AS23498 CDSI - COGECODATA,CA 192.84.24.0/24 AS4323 TWTC - tw telecom holdings, inc.,US 192.101.70.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 192.101.71.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 192.101.72.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 192.124.252.0/22 AS680 DFN Verein zur Foerderung eines Deutschen Forschungsnetzes e.V.,DE 192.131.233.0/24 AS7018 ATT-INTERNET4 - AT&T Services, Inc.,US 192.149.81.0/24 AS14454 PERIMETER-ESECURITY - Perimeter eSecurity,US 192.154.32.0/19 AS81 NCREN - MCNC,US 192.154.64.0/19 AS81 NCREN - MCNC,US 192.166.32.0/20 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 192.188.208.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 192.245.195.0/24 AS7381 SUNGARDRS - SunGard Availability Services LP,US 193.9.59.0/24 AS1257 TELE2,SE 193.16.106.0/24 AS31539 -Reserved AS-,ZZ 193.16.145.0/24 AS31392 -Reserved AS-,ZZ 193.22.86.0/24 AS24751 MULTIFI-AS Jakobstadsnejdens Telefon Ab,FI 193.26.213.0/24 AS31641 BYTEL-AS Bytel Ltd,GB 193.28.14.0/24 AS34309 LINK11 Link11 GmbH,DE 193.32.23.0/24 AS2856 BT-UK-AS BT Public Internet Service,GB 193.33.6.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.33.252.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.35.101.0/24 AS57302 -Reserved AS-,ZZ 193.46.200.0/24 AS34243 WEBAGE Web Age Ltd,GB 193.56.203.0/24 AS51110 IDOMTECHNOLOGIES-AS IDOM TECHNOLOGIES,FR 193.111.229.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.149.2.0/23 AS15919 INTERHOST Servicios de Hosting en Internet S.A.,ES 193.164.152.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.176.147.0/24 AS49951 -Reserved AS-,ZZ 193.178.196.0/22 AS15657 SPEEDBONE-AS Speedbone Internet & Connectivity GmbH,DE 193.188.252.0/24 AS38968 TAGORG Abu-Ghazaleh Intellectual Property,JO 193.200.96.0/23 AS2828 XO-AS15 - XO Communications,US 193.200.244.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.201.244.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 193.201.245.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 193.201.246.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 193.202.9.0/24 AS6824 HERMES-NETWORK Hermes Telecom International Ltd,GB 193.223.103.0/24 AS8437 UTA-AS Tele2 Telecommunication GmbH,AT 193.227.109.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.227.236.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 194.6.252.0/24 AS21202 DCSNET-AS Bredband2 AB,SE 194.9.8.0/23 AS2863 SPRITELINK Centor AB,SE 194.9.8.0/24 AS2863 SPRITELINK Centor AB,SE 194.39.78.0/23 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 194.49.17.0/24 AS13135 CREW-AS Wieske's Crew GmbH,DE 194.50.8.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 194.60.88.0/21 AS5089 NTL Virgin Media Limited,GB 194.61.147.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 194.61.150.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 194.61.151.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 194.63.152.0/22 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 194.76.224.0/24 AS34701 WITZENMANN-AS Witzenmann GmbH, Pforzheim,DE 194.76.225.0/24 AS34701 WITZENMANN-AS Witzenmann GmbH, Pforzheim,DE 194.88.6.0/24 AS35093 RO-HTPASSPORT High Tech Passport Ltd SUA California San Jose SUCURSALA BUCURESTI ROMANIA,RO 194.88.226.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 194.99.67.0/24 AS9083 CARPENET carpeNet Information Technologies GmbH,DE 194.114.136.0/22 AS33866 -Reserved AS-,ZZ 194.126.152.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 194.126.219.0/24 AS34545 -Reserved AS-,ZZ 194.126.233.0/24 AS31235 SKIWEBCENTER-AS SKIWEBCENTER SARL,FR 194.180.25.0/24 AS21358 ATOS-ORIGIN-DE-AS Atos Information Technology GmbH,DE 194.187.24.0/22 AS8856 UKRNET UkrNet Ltd,UA 195.8.48.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.8.48.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.42.232.0/22 AS15657 SPEEDBONE-AS Speedbone Internet & Connectivity GmbH,DE 195.85.194.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.85.201.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.110.0.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.128.240.0/23 AS21202 DCSNET-AS Bredband2 AB,SE 195.149.119.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.189.174.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.216.234.0/24 AS31309 NMV-AS New Media Ventures BVBA,BE 195.234.156.0/24 AS25028 -Reserved AS-,ZZ 195.242.182.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.244.18.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 196.3.182.0/24 AS37004 -Reserved AS-,ZZ 196.3.183.0/24 AS37004 -Reserved AS-,ZZ 196.22.8.0/24 AS27822 Emerging Markets Communications de Argentina S.R.L,AR 196.22.11.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US 198.22.195.0/24 AS54583 -Reserved AS-,ZZ 198.23.26.0/24 AS33052 VZUNET - Verizon Data Services LLC,US 198.73.226.0/23 AS62839 -Reserved AS-,ZZ 198.74.11.0/24 AS14573 KEYSPANENERGY-NE1 - Keyspan Energy,US 198.74.13.0/24 AS14573 KEYSPANENERGY-NE1 - Keyspan Energy,US 198.74.38.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services,US 198.74.39.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services,US 198.74.40.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services,US 198.97.72.0/21 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 198.97.96.0/19 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 198.97.240.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 198.163.214.0/24 AS21804 ACCESS-SK - Access Communications Co-operative Limited,CA 198.168.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 199.30.132.0/22 AS26003 -Reserved AS-,ZZ 199.38.248.0/24 AS13951 CENTER-SEVEN - C7 Data Centers, Inc.,US 199.38.249.0/24 AS13951 CENTER-SEVEN - C7 Data Centers, Inc.,US 199.38.250.0/24 AS13951 CENTER-SEVEN - C7 Data Centers, Inc.,US 199.38.251.0/24 AS13951 CENTER-SEVEN - C7 Data Centers, Inc.,US 199.38.252.0/22 AS13951 CENTER-SEVEN - C7 Data Centers, Inc.,US 199.66.15.0/24 AS30169 -Reserved AS-,ZZ 199.85.9.0/24 AS852 ASN852 - TELUS Communications Inc.,CA 199.88.52.0/22 AS17018 QTS-SACRAMENTO-1 - Quality Investment Properties Sacramento, LLC,US 199.102.240.0/24 AS18508 -Reserved AS-,ZZ 199.116.200.0/21 AS22830 -Reserved AS-,ZZ 199.121.0.0/16 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 199.123.16.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 199.233.87.0/24 AS33058 PEGASYSTEMS - Pegasystems Inc.,US 200.1.112.0/24 AS29754 GO2TEL - GO2TEL.COM INC.,US 200.6.87.0/24 AS27947 Telconet S.A,EC 200.58.248.0/21 AS27849 200.81.48.0/24 AS11664 Techtel LMDS Comunicaciones Interactivas S.A.,AR 200.81.49.0/24 AS11664 Techtel LMDS Comunicaciones Interactivas S.A.,AR 202.3.75.0/24 AS18172 202.3.76.0/24 AS18172 202.8.106.0/24 AS9530 SHINSEGAE-AS SHINSEGAE I&C Co., Ltd.,KR 202.45.10.0/23 AS24327 202.45.10.0/24 AS24327 202.45.11.0/24 AS24327 202.53.138.0/24 AS4058 CITICTEL-CPC-AS4058 CITIC Telecom International CPC Limited,HK 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network,CN 202.122.134.0/24 AS38615 202.140.147.0/24 AS9583 SIFY-AS-IN Sify Limited,IN 202.158.251.0/24 AS9255 CONNECTPLUS-AS Singapore Telecom,SG 202.165.124.0/24 AS23749 GLOBAL-TRANSIT-AS-HKCOLO-AP HKCOLO ltd. Internet Service Provider,HK 202.179.134.0/24 AS23966 LDN-AS-PK LINKdotNET Telecom Limited,PK 203.142.219.0/24 AS45149 203.175.11.0/24 AS9229 SPEEDCAST-AP SPEEDCAST Limited,HK 203.189.116.0/22 AS45606 203.189.116.0/24 AS45606 203.189.117.0/24 AS45606 203.189.118.0/24 AS45606 203.189.119.0/24 AS45606 203.208.22.0/24 AS13220 204.10.88.0/21 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 204.15.208.0/22 AS13706 COMPLETEWEBNET - CompleteWeb.Net LLC,US 204.16.96.0/24 AS19972 -Reserved AS-,ZZ 204.16.97.0/24 AS19972 -Reserved AS-,ZZ 204.16.98.0/24 AS19972 -Reserved AS-,ZZ 204.16.99.0/24 AS19972 -Reserved AS-,ZZ 204.69.139.0/24 AS40250 -Reserved AS-,ZZ 204.69.144.0/24 AS27283 RJF-INTERNET - Raymond James Financial, Inc.,US 204.86.196.0/23 AS14372 -Reserved AS-,ZZ 204.86.198.0/23 AS33058 PEGASYSTEMS - Pegasystems Inc.,US 204.87.251.0/24 AS22217 -Reserved AS-,ZZ 204.106.16.0/24 AS4323 TWTC - tw telecom holdings, inc.,US 204.187.11.0/24 AS51113 ELEKTA-AS Elekta,GB 204.235.245.0/24 AS22613 -Reserved AS-,ZZ 205.137.240.0/20 AS11686 ENA - Education Networks of America,US 205.159.44.0/24 AS40157 ADESA-CORP-AS - ADESA Corp,US 205.166.231.0/24 AS7029 WINDSTREAM - Windstream Communications Inc,US 205.211.160.0/24 AS30045 UHN-ASN - University Health Network,CA 206.131.192.0/20 AS13220 206.131.192.0/24 AS13220 206.131.193.0/24 AS13220 206.131.194.0/24 AS13220 206.131.195.0/24 AS13220 206.131.197.0/24 AS13220 206.131.200.0/24 AS13220 206.131.201.0/24 AS13220 206.131.202.0/24 AS13220 206.131.203.0/24 AS13220 206.131.204.0/24 AS13220 206.131.205.0/24 AS13220 206.131.206.0/24 AS13220 206.197.184.0/24 AS23304 DATOTEL-STL-AS - Datotel LLC, a NetLabs LLC Company,US 207.2.120.0/21 AS6221 USCYBERSITES - US Cybersites, Inc,US 207.174.131.0/24 AS26116 INDRA - Indra's Net Inc,US 207.174.132.0/23 AS26116 INDRA - Indra's Net Inc,US 207.174.152.0/23 AS26116 INDRA - Indra's Net Inc,US 207.174.154.0/24 AS26116 INDRA - Indra's Net Inc,US 207.174.155.0/24 AS26116 INDRA - Indra's Net Inc,US 207.174.200.0/24 AS22658 EARTHNET - Earthnet, Inc.,US 207.231.96.0/19 AS11194 NUNETPA - NuNet Inc.,US 207.254.128.0/21 AS30689 FLOW-NET - FLOW,JM 207.254.136.0/21 AS30689 FLOW-NET - FLOW,JM 208.66.64.0/24 AS16936 -Reserved AS-,ZZ 208.66.65.0/24 AS16936 -Reserved AS-,ZZ 208.66.66.0/24 AS16936 -Reserved AS-,ZZ 208.66.67.0/24 AS16936 -Reserved AS-,ZZ 208.67.132.0/22 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 208.73.40.0/22 AS19901 -Reserved AS-,ZZ 208.73.41.0/24 AS19901 -Reserved AS-,ZZ 208.75.152.0/21 AS32146 -Reserved AS-,ZZ 208.76.20.0/24 AS31812 -Reserved AS-,ZZ 208.76.21.0/24 AS31812 -Reserved AS-,ZZ 208.77.164.0/24 AS22659 -Reserved AS-,ZZ 208.77.166.0/24 AS4323 TWTC - tw telecom holdings, inc.,US 208.83.53.0/24 AS40569 YGOMI-AS - Ygomi LLC,US 208.84.232.0/24 AS33131 -Reserved AS-,ZZ 208.84.233.0/24 AS33131 -Reserved AS-,ZZ 208.84.234.0/24 AS33131 -Reserved AS-,ZZ 208.84.237.0/24 AS33131 -Reserved AS-,ZZ 208.93.216.0/22 AS209 CENTURYLINK-US-LEGACY-QWEST - Qwest Communications Company, LLC,US 208.94.216.0/23 AS13629 -Reserved AS-,ZZ 208.94.219.0/24 AS13629 -Reserved AS-,ZZ 208.94.221.0/24 AS13629 -Reserved AS-,ZZ 208.94.223.0/24 AS13629 -Reserved AS-,ZZ 209.135.171.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 209.135.175.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 209.177.64.0/20 AS6461 ABOVENET - Abovenet Communications, Inc,US 209.193.112.0/20 AS209 CENTURYLINK-US-LEGACY-QWEST - Qwest Communications Company, LLC,US 209.209.51.0/24 AS18687 MPOWER-2 - MPOWER COMMUNICATIONS CORP.,US 209.234.112.0/23 AS32252 -Reserved AS-,ZZ 209.234.114.0/23 AS32252 -Reserved AS-,ZZ 209.234.116.0/24 AS32252 -Reserved AS-,ZZ 209.234.117.0/24 AS32252 -Reserved AS-,ZZ 209.234.118.0/24 AS32252 -Reserved AS-,ZZ 209.234.119.0/24 AS32252 -Reserved AS-,ZZ 209.234.120.0/24 AS32252 -Reserved AS-,ZZ 209.234.121.0/24 AS32252 -Reserved AS-,ZZ 209.234.122.0/24 AS32252 -Reserved AS-,ZZ 213.255.128.0/20 AS24863 LINKdotNET-AS,EG 213.255.144.0/20 AS24863 LINKdotNET-AS,EG 216.73.81.0/24 AS6432 DOUBLECLICK - Double Click, Inc.,US 216.73.82.0/24 AS6432 DOUBLECLICK - Double Click, Inc.,US 216.73.85.0/24 AS6432 DOUBLECLICK - Double Click, Inc.,US 216.73.88.0/24 AS6432 DOUBLECLICK - Double Click, Inc.,US 216.73.89.0/24 AS6432 DOUBLECLICK - Double Click, Inc.,US 216.73.94.0/24 AS6432 DOUBLECLICK - Double Click, Inc.,US 216.73.95.0/24 AS6432 DOUBLECLICK - Double Click, Inc.,US 216.146.0.0/19 AS11915 US-TELEPACIFIC - TelePacific Communications,US 216.152.24.0/22 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc.,US 216.170.96.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc.,US 216.170.101.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc.,US 216.170.104.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc.,US 216.170.105.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc.,US 216.234.132.0/24 AS14545 ADR-DRIVING-RECORDS - AMERICAN DRIVING RECORDS, INC.,US 216.238.192.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 216.238.193.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 216.238.194.0/24 AS26566 -Reserved AS-,ZZ 216.238.196.0/22 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 216.251.50.0/24 AS38191 INFOSYS-AS Infosys Technologies Ltd,IN 216.251.53.0/24 AS38191 INFOSYS-AS Infosys Technologies Ltd,IN 216.251.62.0/24 AS38191 INFOSYS-AS Infosys Technologies Ltd,IN Please see http://www.cidr-report.org for the full report ------------------------------------ Copies of this report are mailed to: nanog at nanog.org 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 22:00:01 2015 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 8 May 2015 22:00:01 GMT Subject: BGP Update Report Message-ID: <201505082200.t48M019o061194@wattle.apnic.net> BGP Update Report Interval: 30-Apr-15 -to- 07-May-15 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS23752 272041 5.6% 2267.0 -- NPTELECOM-NP-AS Nepal Telecommunications Corporation, Internet Services,NP 2 - AS9829 266241 5.5% 190.4 -- BSNL-NIB National Internet Backbone,IN 3 - AS22059 101494 2.1% 16915.7 -- APVIO-1 - Apvio, Inc.,US 4 - AS7713 93947 1.9% 18789.4 -- TELKOMNET-AS-AP PT Telekomunikasi Indonesia,ID 5 - AS36947 82403 1.7% 1248.5 -- ALGTEL-AS,DZ 6 - AS26615 74092 1.5% 59.3 -- Tim Celular S.A.,BR 7 - AS3709 71276 1.5% 2639.9 -- NET-CITY-SA - City of San Antonio,US 8 - AS45899 69419 1.4% 96.8 -- VNPT-AS-VN VNPT Corp,VN 9 - AS26821 56095 1.2% 8013.6 -- REVNET - Revelation Networks, Inc.,US 10 - AS18566 39338 0.8% 21.3 -- MEGAPATH5-US - MegaPath Corporation,US 11 - AS54169 35125 0.7% 11708.3 -- MGH-ION-1 - Marin General Hospital,US 12 - AS28573 34329 0.7% 14.6 -- NET Servi?os de Comunica??o S.A.,BR 13 - AS25563 32631 0.7% 10877.0 -- WEBLAND-AS Webland AG, Autonomous System,CH 14 - AS18403 32623 0.7% 45.4 -- FPT-AS-AP The Corporation for Financing & Promoting Technology,VN 15 - AS20248 25818 0.5% 1358.8 -- TAKE2 - Take 2 Hosting, Inc.,US 16 - AS33667 25338 0.5% 649.7 -- CMCS - Comcast Cable Communications, Inc.,US 17 - AS8402 25290 0.5% 172.0 -- CORBINA-AS OJSC "Vimpelcom",RU 18 - AS33651 25254 0.5% 647.5 -- CMCS - Comcast Cable Communications, Inc.,US 19 - AS17451 22968 0.5% 247.0 -- BIZNET-AS-AP BIZNET NETWORKS,ID 20 - AS48309 21934 0.5% 430.1 -- AGS-AS Ariana Gostar Spadana (PJSC),IR TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS7713 93947 1.9% 18789.4 -- TELKOMNET-AS-AP PT Telekomunikasi Indonesia,ID 2 - AS22059 101494 2.1% 16915.7 -- APVIO-1 - Apvio, Inc.,US 3 - AS54169 35125 0.7% 11708.3 -- MGH-ION-1 - Marin General Hospital,US 4 - AS25563 32631 0.7% 10877.0 -- WEBLAND-AS Webland AG, Autonomous System,CH 5 - AS393588 9608 0.2% 9608.0 -- MUBEA-FLO - Mubea,US 6 - AS18135 8109 0.2% 8109.0 -- BTV BTV Cable television,JP 7 - AS26821 56095 1.2% 8013.6 -- REVNET - Revelation Networks, Inc.,US 8 - AS202195 7426 0.1% 7426.0 -- ASTEKOSTMN West Siberian Regional Center of Telecommunications Tekos-Tyumen Ltd.,RU 9 - AS46336 7426 0.1% 7426.0 -- GOODVILLE - Goodville Mutual Casualty Company,US 10 - AS57120 7422 0.1% 7422.0 -- TMK-AS JSC "TMK",RU 11 - AS1757 11319 0.2% 5659.5 -- LEXIS-AS - LexisNexis,US 12 - AS197914 4994 0.1% 4994.0 -- STOCKHO-AS Stockho Hosting SARL,FR 13 - AS45726 17105 0.3% 4276.2 -- LIONAIR-AS-ID Lion Mentari Airlines, PT,ID 14 - AS52233 20915 0.4% 3485.8 -- Columbus Communications Curacao NV,CW 15 - AS13483 12603 0.3% 3150.8 -- INFOR-AS13483 - INFOR GLOBAL SOLUTIONS (MICHIGAN), INC.,US 16 - AS46358 6195 0.1% 3097.5 -- UAT - University of Advancing Technology,US 17 - AS199121 2925 0.1% 2925.0 -- FLEXOPTIX Flexoptix GmbH,DE 18 - AS2167 13748 0.3% 2749.6 -- HPES - Hewlett-Packard Company,US 19 - AS3709 71276 1.5% 2639.9 -- NET-CITY-SA - City of San Antonio,US 20 - AS55741 2593 0.1% 2593.0 -- WBSDC-NET-IN West Bengal Electronics Industry Development,IN TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 202.70.64.0/21 137183 2.7% AS23752 -- NPTELECOM-NP-AS Nepal Telecommunications Corporation, Internet Services,NP 2 - 202.70.88.0/21 133506 2.7% AS23752 -- NPTELECOM-NP-AS Nepal Telecommunications Corporation, Internet Services,NP 3 - 118.98.88.0/24 94467 1.9% AS64567 -- -Private Use AS-,ZZ AS7713 -- TELKOMNET-AS-AP PT Telekomunikasi Indonesia,ID 4 - 105.96.0.0/22 81587 1.6% AS36947 -- ALGTEL-AS,DZ 5 - 64.34.125.0/24 50755 1.0% AS22059 -- APVIO-1 - Apvio, Inc.,US 6 - 76.191.107.0/24 50731 1.0% AS22059 -- APVIO-1 - Apvio, Inc.,US 7 - 204.80.242.0/24 35118 0.7% AS54169 -- MGH-ION-1 - Marin General Hospital,US 8 - 107.0.152.0/24 26172 0.5% AS33651 -- CMCS - Comcast Cable Communications, Inc.,US AS33667 -- CMCS - Comcast Cable Communications, Inc.,US 9 - 162.208.96.0/24 24251 0.5% AS33651 -- CMCS - Comcast Cable Communications, Inc.,US AS33667 -- CMCS - Comcast Cable Communications, Inc.,US 10 - 91.210.121.0/24 16161 0.3% AS42896 -- ACS-AS TOV "Research and Production Company "ACS-Group",CZ 11 - 198.185.16.0/24 11317 0.2% AS1757 -- LEXIS-AS - LexisNexis,US 12 - 92.43.216.0/21 11168 0.2% AS25563 -- WEBLAND-AS Webland AG, Autonomous System,CH 13 - 185.84.192.0/22 10745 0.2% AS25563 -- WEBLAND-AS Webland AG, Autonomous System,CH 14 - 178.174.96.0/19 10718 0.2% AS25563 -- WEBLAND-AS Webland AG, Autonomous System,CH 15 - 192.58.232.0/24 10595 0.2% AS6629 -- NOAA-AS - NOAA,US 16 - 192.58.137.0/24 9608 0.2% AS393588 -- MUBEA-FLO - Mubea,US 17 - 103.52.7.0/24 8610 0.2% AS45726 -- LIONAIR-AS-ID Lion Mentari Airlines, PT,ID 18 - 202.4.170.0/23 8491 0.2% AS45726 -- LIONAIR-AS-ID Lion Mentari Airlines, PT,ID 19 - 42.83.48.0/20 8109 0.2% AS18135 -- BTV BTV Cable television,JP 20 - 207.246.202.0/24 8035 0.2% AS26821 -- REVNET - Revelation Networks, Inc.,US Details at http://bgpupdates.potaroo.net ------------------------------------ Copies of this report are mailed to: nanog at nanog.org eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From chaim.rieger at gmail.com Fri May 8 22:41:34 2015 From: chaim.rieger at gmail.com (Chaim Rieger) Date: Fri, 8 May 2015 15:41:34 -0700 Subject: Updated prefix filtering Message-ID: Best example I?ve found is located at http://jonsblog.lewis.org/ I too ran out of space, Brocade, not Cisco though, and am looking to filter prefixes. did anybody do a more recent or updated filter list since 2008 ? Offlist is fine. Oh and happy friday to all. From bedard.phil at gmail.com Fri May 8 23:20:51 2015 From: bedard.phil at gmail.com (Phil Bedard) Date: Fri, 8 May 2015 19:20:51 -0400 Subject: Thousands of hosts on a gigabit LAN, maybe not In-Reply-To: <20150508185303.55159.qmail@ary.lan> References: <20150508185303.55159.qmail@ary.lan> Message-ID: <554d44da.4d808c0a.5d93.ffffb706@mx.google.com> The real answer to this is being able to cram them into a single chassis which can multiplex the network through a backplane. Something like the HP Moonshot ARM system or the way others like Google build high density compute with integrated Ethernet switching. Phil -----Original Message----- From: "John Levine" Sent: ?5/?8/?2015 2:59 PM To: "nanog at nanog.org" Subject: Thousands of hosts on a gigabit LAN, maybe not Some people I know (yes really) are building a system that will have several thousand little computers in some racks. Each of the computers runs Linux and has a gigabit ethernet interface. It occurs to me that it is unlikely that I can buy an ethernet switch with thousands of ports, and even if I could, would I want a Linux system to have 10,000 entries or more in its ARP table. Most of the traffic will be from one node to another, with considerably less to the outside. Physical distance shouldn't be a problem since everything's in the same room, maybe the same rack. What's the rule of thumb for number of hosts per switch, cascaded switches vs. routers, and whatever else one needs to design a dense network like this? TIA R's, John From joe at nethead.com Fri May 8 23:50:17 2015 From: joe at nethead.com (Joe Hamelin) Date: Fri, 8 May 2015 16:50:17 -0700 Subject: Thousands of hosts on a gigabit LAN, maybe not In-Reply-To: <20150508185303.55159.qmail@ary.lan> References: <20150508185303.55159.qmail@ary.lan> Message-ID: On Fri, May 8, 2015 at 11:53 AM, John Levine wrote: > Some people I know (yes really) are building a system that will have > several thousand little computers in some racks. Each of the > computers runs Linux and has a gigabit ethernet interface. Though a bit off-topic I ran in to this project at the CascadeIT conference. I'm currently in corp IT that is Notes/Windows based so I haven't had a good place to test it but the concept is very interesting. They distributed way they monitor would greatly reduce bandwidth overhead. http://assimproj.org The Assimilation Project is designed to discover and monitor infrastructure, services, and dependencies on a network of potentially unlimited size, without significant growth in centralized resources. The work of discovery and monitoring is delegated uniformly in tiny pieces to the various machines in a network-aware topology - minimizing network overhead and being naturally geographically sensitive. The two main ideas are: - distribute discovery throughout the network, doing most discovery locally - distribute the monitoring as broadly as possible in a network-aware fashion. - use autoconfiguration and zero-network-footprint discovery techniques to monitor most resources automatically. during the initial installation and during ongoing system addition and maintenance. -- Joe Hamelin, W7COM, Tulalip, WA, 360-474-7474 From nanog at jima.us Sat May 9 00:19:04 2015 From: nanog at jima.us (Jima) Date: Fri, 08 May 2015 18:19:04 -0600 Subject: Thousands of hosts on a gigabit LAN, maybe not In-Reply-To: <20150508185303.55159.qmail@ary.lan> References: <20150508185303.55159.qmail@ary.lan> Message-ID: <554D5278.5010408@jima.us> On 2015-05-08 12:53, John Levine wrote: > What's the rule of thumb for number of hosts per switch, cascaded > switches vs. routers, and whatever else one needs to design a dense > network like this? TIA I won't pretend to know best practices, but my inclination would be to connect the devices to 48-port L2 ToR switches with 2-4 SFP+ uplink ports (a number of vendors have options for this), with the 10gbit ports aggregated to a 10gbit core L2/L3 switch stack (ditto). I'm not sure I'd attempt this without 10gbit to the edge switches, due to Rafael's aforementioned point of the bottleneck/loss of multiple ports for trunking. Not knowing the architectural constraints, I'd probably go with others' advice of limiting L2 zones to 200-500 hosts, which would probably amount to 4-10 edge switches per VLAN. Dang. The more I think about this project, the more expensive it sounds. Jima From faisal at snappytelecom.net Sat May 9 00:22:12 2015 From: faisal at snappytelecom.net (Faisal Imtiaz) Date: Sat, 9 May 2015 00:22:12 +0000 (GMT) Subject: Updated prefix filtering In-Reply-To: References: Message-ID: <547921609.183773.1431130932055.JavaMail.zimbra@snappytelecom.net> Not sure if you missed it.. there was a discussion on this topic in the recent past... I am taking the liberty of re-posting below.. you may find it useful. ---------------------- Hi Freddy, As Paul has mentioned, you could check the David's project - SIR, look at his presentation: https://www.youtube.com/watch?v=o1njanXhQqM We've also developed a platform for the BGP monitoring and routing optimization which could solve your problem. It would inject to the border routers only TOP X prefixes with which you exchange most of the traffic. The added value would be that route orders point to best performing transit (low latency, 0 packet loss) per distant prefix. If you are interested to know more about our software please contact me off-list. -- Regards, Pawel Rybczyk Regional Manager BORDER 6 sp. z o.o. pawel.rybczyk at border6.com office: +48 22 242 89 51 (ext.103) mobile: +48 664 300 375 ====================================================== Faisal Imtiaz Snappy Internet & Telecom 7266 SW 48 Street Miami, FL 33155 Tel: 305 663 5518 x 232 Help-desk: (305)663-5518 Option 2 or Email: Support at Snappytelecom.net ----- Original Message ----- > From: "Chaim Rieger" > To: "NANOG list" > Sent: Friday, May 8, 2015 6:41:34 PM > Subject: Updated prefix filtering > > > Best example I?ve found is located at http://jonsblog.lewis.org/ > > > I too ran out of space, Brocade, not Cisco though, and am looking to filter > prefixes. did anybody do a more recent or updated filter list since 2008 ? > > Offlist is fine. > > Oh and happy friday to all. From joe at nethead.com Sat May 9 00:48:53 2015 From: joe at nethead.com (Joe Hamelin) Date: Fri, 8 May 2015 17:48:53 -0700 Subject: Thousands of hosts on a gigabit LAN, maybe not In-Reply-To: <554D5278.5010408@jima.us> References: <20150508185303.55159.qmail@ary.lan> <554D5278.5010408@jima.us> Message-ID: On Fri, May 8, 2015 at 5:19 PM, Jima wrote: Dang. The more I think about this project, the more expensive it sounds. Naw, just use WiFi. ;) -- Joe Hamelin, W7COM, Tulalip, WA, 360-474-7474 From mike.lyon at gmail.com Sat May 9 01:05:32 2015 From: mike.lyon at gmail.com (Mike Lyon) Date: Fri, 8 May 2015 18:05:32 -0700 Subject: Any AWS folk on the list? Message-ID: Trying get a cross-connect up with you in SV5 and your customer support folk are unable to call Equinix to trounleshoot. If you could ping me offlist, it would be greatly appreciated. Thank You, Mike From rdobbins at arbor.net Sat May 9 01:55:16 2015 From: rdobbins at arbor.net (Roland Dobbins) Date: Sat, 09 May 2015 08:55:16 +0700 Subject: Thousands of hosts on a gigabit LAN, maybe not In-Reply-To: <20150508185303.55159.qmail@ary.lan> References: <20150508185303.55159.qmail@ary.lan> Message-ID: On 9 May 2015, at 1:53, John Levine wrote: > What's the rule of thumb for number of hosts per switch, cascaded > switches vs. routers, and whatever else one needs to design a dense > network like this? Most of the major switch vendors have design guides and other examples like this available (this one is Cisco-specific): Some organizations like Facebook have also taken the time to write up their approaches and make them publicly available: ----------------------------------- Roland Dobbins From charles at thefnf.org Sat May 9 04:29:35 2015 From: charles at thefnf.org (charles at thefnf.org) Date: Fri, 08 May 2015 23:29:35 -0500 Subject: Thousands of hosts on a gigabit LAN, maybe not In-Reply-To: <554d44da.4d808c0a.5d93.ffffb706@mx.google.com> References: <20150508185303.55159.qmail@ary.lan> <554d44da.4d808c0a.5d93.ffffb706@mx.google.com> Message-ID: On 2015-05-08 18:20, Phil Bedard wrote: > The real answer to this is being able to cram them into a single > chassis which can multiplex the network through a backplane. > Something like the HP Moonshot ARM system or the way others like > Google build high density compute with integrated Ethernet switching. > I was going to suggest moonshot myself (I walk by a number of moonshot units daily). However it seemed like the systems were already selected and then someone was like "oh yeah, better ask netops how to hook these things we bought and didn't tell anyone about to the interwebz". (I mean that's not a 100% accurate description of my $DAYJOB at all). In which case, the standard response is "well gee whizz buddy, ya should of bought moonshot jigs. But now you have to buy pallet loads of chassis switches". Hope you have some money left over in your budget. From charles at thefnf.org Sat May 9 05:24:14 2015 From: charles at thefnf.org (charles at thefnf.org) Date: Sat, 09 May 2015 00:24:14 -0500 Subject: Rasberry pi - high density Message-ID: <3add94118911fb463b174ab24631657b@thefnf.org> So I just crunched the numbers. How many pies could I cram in a rack? Check my numbers? 48U rack budget 6513 15U (48-15) = 33U remaining for pie 6513 max of 576 copper ports Pi dimensions: 3.37 l (5 front to back) 2.21 w (6 wide) 0.83 h 25 per U (rounding down for Ethernet cable space etc) = 825 pi Cable management and heat would probably kill this before it ever reached completion, but lol... From raphael.timothy at gmail.com Sat May 9 05:48:49 2015 From: raphael.timothy at gmail.com (Tim Raphael) Date: Sat, 9 May 2015 13:48:49 +0800 Subject: Rasberry pi - high density In-Reply-To: <3add94118911fb463b174ab24631657b@thefnf.org> References: <3add94118911fb463b174ab24631657b@thefnf.org> Message-ID: The problem is, I can get more processing power and RAM out of two 10RU blade chassis and only needing 64 10G ports... 32 x 256GB RAM per blade = 8.1TB 32 x 16 cores x 2.4GHz = 1,228GHz (not based on current highest possible, just using reasonable specs) Needing only 4 QFX5100s which will cost less than a populated 6513 and give lower latency. Power, cooling and cost would be lower too. RPi = 900MHz and 1GB RAM. So to equal the two chassis, you'll need: 1228 / 0.9 = 1364 Pis for compute (main performance aspect of a super computer) meaning double the physical space required compared to the chassis option. So yes, infeasible indeed. Regards, Tim Raphael > On 9 May 2015, at 1:24 pm, charles at thefnf.org wrote: > > > > So I just crunched the numbers. How many pies could I cram in a rack? > > Check my numbers? > > 48U rack budget > 6513 15U (48-15) = 33U remaining for pie > 6513 max of 576 copper ports > > Pi dimensions: > > 3.37 l (5 front to back) > 2.21 w (6 wide) > 0.83 h > 25 per U (rounding down for Ethernet cable space etc) = 825 pi > > Cable management and heat would probably kill this before it ever reached completion, but lol... > > > From frederik at kriewitz.eu Sat May 9 11:58:18 2015 From: frederik at kriewitz.eu (Frederik Kriewitz) Date: Sat, 9 May 2015 13:58:18 +0200 Subject: Updated prefix filtering In-Reply-To: <547921609.183773.1431130932055.JavaMail.zimbra@snappytelecom.net> References: <547921609.183773.1431130932055.JavaMail.zimbra@snappytelecom.net> Message-ID: On Sat, May 9, 2015 at 2:22 AM, Faisal Imtiaz wrote: > Not sure if you missed it.. there was a discussion on this topic in the recent past... > I am taking the liberty of re-posting below.. you may find it useful. You can find the complete thread here: http://mailman.nanog.org/pipermail/nanog/2015-April/074425.html Depending on whether you're RIB and/or FIB limited there are a couple of options. Regards, Frederik Kriewitz From rafael at gav.ufsc.br Sat May 9 13:29:25 2015 From: rafael at gav.ufsc.br (Rafael Possamai) Date: Sat, 9 May 2015 08:29:25 -0500 Subject: Rasberry pi - high density In-Reply-To: References: <3add94118911fb463b174ab24631657b@thefnf.org> Message-ID: >From the work that I've done in the past with clusters, your need for bandwidth is usually not the biggest issue. When you work with "big data", let's say 500 million data points, most mathematicians would condense it all down into averages, standard deviations, probabilities, etc, which then become much smaller to save in your hard disks and also to perform data analysis with, as well as transfer these stats from master to nodes and vice-versa. So for one project at a time, your biggest concern is cpu clock, ram, interrupts, etc. If you want to run all of the BIG 10s academic projects into one big cluster for example, then networking might become an issue solely due to volume. The more data you transfer, the longer it would take to perform any meaningful analysis on it, so really your bottleneck is TFLOPS rather than packets per second. With Facebook it's the opposite, it's mostly pictures and videos of cats coming in and out of the server with lots of reads and writes on their storage. In that case, switching tbps of traffic is how they make money. A good example is creating a dockr container with your application and deploying a cluster with CoreOS. You save all that capex and spend by the hour. I believe Azure and EC2 already have support for CoreOS. On Sat, May 9, 2015 at 12:48 AM, Tim Raphael wrote: > The problem is, I can get more processing power and RAM out of two 10RU > blade chassis and only needing 64 10G ports... > > 32 x 256GB RAM per blade = 8.1TB > 32 x 16 cores x 2.4GHz = 1,228GHz > (not based on current highest possible, just using reasonable specs) > > Needing only 4 QFX5100s which will cost less than a populated 6513 and > give lower latency. Power, cooling and cost would be lower too. > > RPi = 900MHz and 1GB RAM. So to equal the two chassis, you'll need: > > 1228 / 0.9 = 1364 Pis for compute (main performance aspect of a super > computer) meaning double the physical space required compared to the > chassis option. > > So yes, infeasible indeed. > > Regards, > > Tim Raphael > > > On 9 May 2015, at 1:24 pm, charles at thefnf.org wrote: > > > > > > > > So I just crunched the numbers. How many pies could I cram in a rack? > > > > Check my numbers? > > > > 48U rack budget > > 6513 15U (48-15) = 33U remaining for pie > > 6513 max of 576 copper ports > > > > Pi dimensions: > > > > 3.37 l (5 front to back) > > 2.21 w (6 wide) > > 0.83 h > > 25 per U (rounding down for Ethernet cable space etc) = 825 pi > > > > Cable management and heat would probably kill this before it ever > reached completion, but lol... > > > > > > > From kmedcalf at dessus.com Sat May 9 15:05:48 2015 From: kmedcalf at dessus.com (Keith Medcalf) Date: Sat, 09 May 2015 09:05:48 -0600 Subject: No subject In-Reply-To: <20150508063922.47C152DF2D66@rock.dv.isc.org> Message-ID: <8475756ad8f0bd4f81e2878c889de45f@mail.dessus.com> Ah. Security hole as designed. inline dispositions should be ignored unless the recipient specifically "requests" to see them after viewing the text/plain part. In fact, I would vote for ignoring *everything* except the text/plain part unless the recipient specifically requests it after viewing the text/plain part. No test/plain? Delete without further ado. > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Mark Andrews > Sent: Friday, 8 May, 2015 00:39 > To: Paul Ferguson > Cc: NANOG > Subject: > > > In message , Paul Ferguson > via N > ANOG writes: > > > > Does anyone any else find it weird that the last dozen or so messages > > from the list have been .eml attachments? > > Nanog is encapsulating messages that are DKIM signed. Your mailer may > not be properly handling > > Content-Type: message/rfc822 > Content-Disposition: inline > > Mark > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From jimpop at gmail.com Sat May 9 15:17:20 2015 From: jimpop at gmail.com (Jim Popovitch) Date: Sat, 9 May 2015 11:17:20 -0400 Subject: No subject In-Reply-To: <8475756ad8f0bd4f81e2878c889de45f@mail.dessus.com> References: <20150508063922.47C152DF2D66@rock.dv.isc.org> <8475756ad8f0bd4f81e2878c889de45f@mail.dessus.com> Message-ID: On Sat, May 9, 2015 at 11:05 AM, Keith Medcalf wrote: > > No test/plain? Delete without further ado. In the past year or so it seems that all RAA Verification emails, or at least the ones I see, contain no plain text. :-( -Jim P. From list at satchell.net Sat May 9 16:01:25 2015 From: list at satchell.net (Stephen Satchell) Date: Sat, 09 May 2015 09:01:25 -0700 Subject: No subject In-Reply-To: References: <20150508063922.47C152DF2D66@rock.dv.isc.org> <8475756ad8f0bd4f81e2878c889de45f@mail.dessus.com> Message-ID: <554E2F55.8050500@satchell.net> On 05/09/2015 08:17 AM, Jim Popovitch wrote: > On Sat, May 9, 2015 at 11:05 AM, Keith Medcalf wrote: >> >> No test/plain? Delete without further ado. > > > In the past year or so it seems that all RAA Verification emails, or > at least the ones I see, contain no plain text. :-( > > -Jim P. > I'm surprised. I have set Thunderbird to view messages in plain text only. I get a number of messages that have only one line: "Please view this email in your browser." Right. (My brother doesn't like this. He's a process chemist, so he needs to use HTML mail to send most business traffic so that formulas and equations are sent properly. I had to remove my HTML-only filter in order to receive his e-mails. Then he set up a GMail account because others were also filtering on HTML-only. Go figure. Before you ask, I have not put that filter back...) From baldur.norddahl at gmail.com Sat May 9 16:57:26 2015 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Sat, 9 May 2015 18:57:26 +0200 Subject: Thousands of hosts on a gigabit LAN, maybe not In-Reply-To: References: <20150508185303.55159.qmail@ary.lan> <554d44da.4d808c0a.5d93.ffffb706@mx.google.com> Message-ID: The standard 48 port with 2 port uplink 1U switch is far from full depth. You put them in the back of the rack and have the small computers in the front. You might even turn the switches around, so the ports face inwards into the rack. The network cables would be very short and go directly from the mini computers (Raspberry Pi?) to the switch, all within the one unit shelf. Assuming a max sized rack with depth of 90 cm and the switches might be 30 cm. That leaves 60 cm to mount mini computers. That is approximately 12000 cubic cm of space per rack unit. A Raspberry PI is approximately 120 cubic cm. So you might be able to fit 48 of them in that space. It would be a very tight fit indeed but maybe not impossible. As to the original question, I would have 48 computers in a subnet. This is the correct number because you would connect each shelf switch to a top of rack switch, and spend a few extra bucks on the ToR so that it can do layer 3 routing between shelfs. Regards, Baldur From johnl at iecc.com Sat May 9 16:59:21 2015 From: johnl at iecc.com (John Levine) Date: 9 May 2015 16:59:21 -0000 Subject: [probably spam, from "NANOG" ] In-Reply-To: <554E2F55.8050500@satchell.net> Message-ID: <20150509165921.63724.qmail@ary.lan> >> No test/plain? Delete without further ado. Sadly, it is no longer 1998. R's, John From bzs at world.std.com Sat May 9 18:55:51 2015 From: bzs at world.std.com (Barry Shein) Date: Sat, 9 May 2015 14:55:51 -0400 Subject: Rasberry pi - high density In-Reply-To: <3add94118911fb463b174ab24631657b@thefnf.org> References: <3add94118911fb463b174ab24631657b@thefnf.org> Message-ID: <21838.22583.909425.654573@world.std.com> On May 9, 2015 at 00:24 charles at thefnf.org (charles at thefnf.org) wrote: > > > So I just crunched the numbers. How many pies could I cram in a rack? For another list I just estimated how many M.2 SSD modules one could cram into a 3.5" disk case. Around 40 w/ some room to spare (assuming heat and connection routing aren't problems), at 500GB/each that's 20TB in a standard 3.5" case. It's getting weird out there. -- -Barry Shein The World | bzs at TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: 800-THE-WRLD | Dial-Up: US, PR, Canada Software Tool & Die | Public Access Internet | SINCE 1989 *oo* From eugen at imacandi.net Sat May 9 19:26:37 2015 From: eugen at imacandi.net (Eugeniu Patrascu) Date: Sat, 9 May 2015 22:26:37 +0300 Subject: Rasberry pi - high density In-Reply-To: <21838.22583.909425.654573@world.std.com> References: <3add94118911fb463b174ab24631657b@thefnf.org> <21838.22583.909425.654573@world.std.com> Message-ID: On Sat, May 9, 2015 at 9:55 PM, Barry Shein wrote: > > On May 9, 2015 at 00:24 charles at thefnf.org (charles at thefnf.org) wrote: > > > > > > So I just crunched the numbers. How many pies could I cram in a rack? > > For another list I just estimated how many M.2 SSD modules one could > cram into a 3.5" disk case. Around 40 w/ some room to spare (assuming > heat and connection routing aren't problems), at 500GB/each that's > 20TB in a standard 3.5" case. > > It's getting weird out there. > > I think the next logical step in servers would be to remove the traditional hard drive cages and put SSD module slots that can be hot swapped. Imagine inserting small SSD modules on the front side of the servers and directly connect them via PCIe to the motherboard. No more bottlenecks and a software RAID of some sorts would actually make a lot more sense than the current controller based solutions. From lowen at pari.edu Sat May 9 21:06:22 2015 From: lowen at pari.edu (Lamar Owen) Date: Sat, 9 May 2015 17:06:22 -0400 Subject: Thousands of hosts on a gigabit LAN, maybe not In-Reply-To: <20150508185303.55159.qmail@ary.lan> References: <20150508185303.55159.qmail@ary.lan> Message-ID: <554E76CE.9090000@pari.edu> On 05/08/2015 02:53 PM, John Levine wrote: > ... > Most of the traffic will be from one node to another, with > considerably less to the outside. Physical distance shouldn't be a > problem since everything's in the same room, maybe the same rack. > > What's the rule of thumb for number of hosts per switch, cascaded > switches vs. routers, and whatever else one needs to design a dense > network like this? TIA > You know, I read this post and immediately thought 'SGI Altix'........ scalable to 512 CPU's per "system image" and 20 images per cluster (NASA's Columbia supercomputer had 10,240 CPUs in that configuration.....twelve years ago, using 1.5GHz 64-bit RISC CPUs running Linux.... my, how we've come full circle.... (today's equivalent has less power consumption, at least....)). The NUMA technology in those Altix CPU's is a de-facto 'memory-area network' and thus can have some interesting topologies. Clusters can be made using nodes with at least two NICs in them, and no switching. With four or eight ports you can do some nice mesh topologies. This wouldn't be L2 bridging, either, but a L3 mesh could be made that could be rather efficient, with no switches, as long as you have at least three ports per node, and you can do something reasonably efficient with a switch or two and some chains of nodes, with two NICs per node. L3 keeps the broadcast domain size small, and broadcast overhead becomes small. If you only have one NIC per node, well, time to get some seriously high-density switches..... but even then how many nodes are going to be per 42U rack? A top-of-rack switch may only need 192 ports, and that's only 4U, with 1U 48 port switches. 8U you can do 384 ports, and three racks will do a bit over 1,000. Octopus cables going from an RJ21 to 8P8C modular are available, so you could use high-density blades; Cisco claims you could do 576 10/100/1000 ports in a 13-slot 6500. That's half the rack space for the switching. If 10/100 is enough, you could do 12 of the WS-X6196-21AF cards (or the RJ-45 'two-ports-per-plug' WS-X6148X2-45AF) and get in theory 1,152 ports in a 6513 (one SUP; drop 96 ports from that to get a redundant SUP). Looking at another post in the thread, these moonshot rigs sound interesting.... 45 server blades in 4.3U. 4.3U?!?!? Heh, some custom rails, I guess, to get ten in 47U. They claim a quad-server blade, so 1,800 servers (with networking) in a 47U rack. Yow. Cost of several hundred thousand dollars for that setup. The effective limit on subnet size would be of course broadcast overhead; 1,000 nodes on a /22 would likely be painfully slow due to broadcast overhead alone. From kauer at biplane.com.au Sat May 9 22:33:54 2015 From: kauer at biplane.com.au (Karl Auer) Date: Sun, 10 May 2015 08:33:54 +1000 Subject: Thousands of hosts on a gigabit LAN, maybe not In-Reply-To: <554E76CE.9090000@pari.edu> References: <20150508185303.55159.qmail@ary.lan> <554E76CE.9090000@pari.edu> Message-ID: <1431210834.6801.48.camel@karl> On Sat, 2015-05-09 at 17:06 -0400, Lamar Owen wrote: > The effective limit on subnet size would be of course broadcast > overhead; 1,000 nodes on a /22 would likely be painfully slow due to > broadcast overhead alone. Would be interesting to see how IPv6 performed, since is one of the things it was supposed to be able to deliver - massively scalable links (equivalent to an IPv4 broadcast domain) via massively reduced protocol chatter (IPv6 multicast groups vs IPv4 broadcast), plus fully automated L3 address assignment. IPv4 ARP, for example, hits every on-subnet neighbour; the IPv6 equivalent uses multicast to hit only those neighbours that happen to share the same 24 low-end L3 address bits as the desired target - a statistically much smaller subset of on-link neighbours, and in "normal" subnets typically only one host. Only chatter that really should go to all hosts does so - such as router advertisements. Regards, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer at biplane.com.au) http://www.biplane.com.au/kauer http://twitter.com/kauer389 GPG fingerprint: 3C41 82BE A9E7 99A1 B931 5AE7 7638 0147 2C3C 2AC4 Old fingerprint: EC67 61E2 C2F6 EB55 884B E129 072B 0AF0 72AA 9882 From kmedcalf at dessus.com Sat May 9 23:10:05 2015 From: kmedcalf at dessus.com (Keith Medcalf) Date: Sat, 09 May 2015 17:10:05 -0600 Subject: [probably spam, from "NANOG" ] In-Reply-To: <20150509165921.63724.qmail@ary.lan> Message-ID: <1faf932382f9cc4082e2148e82a7c973@mail.dessus.com> > On Saturday, 9 May, 2015, at 10:59 John Levine said: > >> No test/plain? Delete without further ado. > Sadly, it is no longer 1998. No kidding. Web-Page e-mail. Lots of proprietary executable-embedded-in-data file formats used for e-mail, and worst, gratuitous JavaScript everywhere making the Web unuseable unless you disable all security (or just refuse to deal with the schmucks that do that). > R's, > John From dave.taht at gmail.com Sat May 9 23:15:51 2015 From: dave.taht at gmail.com (Dave Taht) Date: Sat, 9 May 2015 16:15:51 -0700 Subject: Rasberry pi - high density In-Reply-To: <21838.22583.909425.654573@world.std.com> References: <3add94118911fb463b174ab24631657b@thefnf.org> <21838.22583.909425.654573@world.std.com> Message-ID: On Sat, May 9, 2015 at 11:55 AM, Barry Shein wrote: > > On May 9, 2015 at 00:24 charles at thefnf.org (charles at thefnf.org) wrote: > > > > > > So I just crunched the numbers. How many pies could I cram in a rack? > > For another list I just estimated how many M.2 SSD modules one could > cram into a 3.5" disk case. Around 40 w/ some room to spare (assuming > heat and connection routing aren't problems), at 500GB/each that's > 20TB in a standard 3.5" case. I could see liquid cooling such a device. insert the whole thing into oil. how many pcie slots are allowed in the standards? > It's getting weird out there. Try to project your mind forward another decade with capability/cost like this: http://www.digitaltrends.com/computing/nine-dollar-computer-kickstarter/ I hope humanity?s last act will be to educate the spambots past their current puerile contemplation of adolescent fantasies and into contemplating faust. > -- > -Barry Shein > > The World | bzs at TheWorld.com | http://www.TheWorld.com > Purveyors to the Trade | Voice: 800-THE-WRLD | Dial-Up: US, PR, Canada > Software Tool & Die | Public Access Internet | SINCE 1989 *oo* -- Dave T?ht Open Networking needs **Open Source Hardware** https://plus.google.com/u/0/+EricRaymond/posts/JqxCe2pFr67 From dave.taht at gmail.com Sat May 9 23:49:50 2015 From: dave.taht at gmail.com (Dave Taht) Date: Sat, 9 May 2015 16:49:50 -0700 Subject: Updated prefix filtering In-Reply-To: References: Message-ID: On Fri, May 8, 2015 at 3:41 PM, Chaim Rieger wrote: > > Best example I?ve found is located at http://jonsblog.lewis.org/ > > I too ran out of space, Brocade, not Cisco though, and am looking to filter prefixes. did anybody do a more recent or updated filter list since 2008 ? > > Offlist is fine. > > Oh and happy friday to all. I have had a piece long on the spike on how we implemented bcp38 for linux (openwrt) devices using the ipset facility. We had a different use case (preventing all possible internal rfc1918 network addresses from escaping, while still allowing punching through one layer of nat ), but the underlying ipset facility was easily extendible to actually do bcp38 and fast to use, so that is what we ended up calling the openwrt package. Please contact me offlist if you would like a peek at that piece, because the article had some structural problems and we never got around to finishing/publishing it, and I would like to.... has there been a bcp38 equivalent published for ipv6? Along the way source specific routing showed up for ipv6 and we ended up obsoleting the concept of an ipv6 global default route entirely on a linux based CPE router. see: http://arxiv.org/pdf/1403.0445.pdf and some relevant homenet wg stuff. d at nuc-client:~/babeld-1.6.0 $ ip -6 route default from 2001:558:6045:e9:251a:738a:ac86:eaf6 via fe80::28c6:8eff:febb:9ff0 dev eth0 proto babel metric 1024 default from 2601:9:4e00:4cb0::/60 via fe80::28c6:8eff:febb:9ff0 dev eth0 proto babel metric 1024 default from fde5:dfb9:df90:fff0::/60 via fe80::225:90ff:fef4:a5c5 dev eth0 proto babel metric 1024 So this box will not forward any ipv6 not in the from(src) table. -- Dave T?ht https://plus.google.com/u/0/explore/makewififast From nick at pelagiris.org Sun May 10 00:35:54 2015 From: nick at pelagiris.org (Nick B) Date: Sat, 9 May 2015 20:35:54 -0400 Subject: Rasberry pi - high density In-Reply-To: References: <3add94118911fb463b174ab24631657b@thefnf.org> <21838.22583.909425.654573@world.std.com> Message-ID: At least some vendors are already doing that. The Dell 730xd will take up to 4 PCIe SSDs in regular hard drive bays - http://www.dell.com/us/business/p/poweredge-r730xd/pd Nick On Sat, May 9, 2015 at 3:26 PM, Eugeniu Patrascu wrote: > On Sat, May 9, 2015 at 9:55 PM, Barry Shein wrote: > > > > > On May 9, 2015 at 00:24 charles at thefnf.org (charles at thefnf.org) wrote: > > > > > > > > > So I just crunched the numbers. How many pies could I cram in a rack? > > > > For another list I just estimated how many M.2 SSD modules one could > > cram into a 3.5" disk case. Around 40 w/ some room to spare (assuming > > heat and connection routing aren't problems), at 500GB/each that's > > 20TB in a standard 3.5" case. > > > > It's getting weird out there. > > > > > I think the next logical step in servers would be to remove the traditional > hard drive cages and put SSD module slots that can be hot swapped. Imagine > inserting small SSD modules on the front side of the servers and directly > connect them via PCIe to the motherboard. No more bottlenecks and a > software RAID of some sorts would actually make a lot more sense than the > current controller based solutions. > From listas at esds.com.br Sun May 10 00:46:41 2015 From: listas at esds.com.br (Eduardo Schoedler) Date: Sat, 9 May 2015 21:46:41 -0300 Subject: Thousands of hosts on a gigabit LAN, maybe not In-Reply-To: <554E76CE.9090000@pari.edu> References: <20150508185303.55159.qmail@ary.lan> <554E76CE.9090000@pari.edu> Message-ID: Juniper OCX1100 have 72 ports in 1U. And you can tune Linux IPv4 neighbor: https://ams-ix.net/technical/specifications-descriptions/config-guide#11 -- Eduardo Schoedler Em s?bado, 9 de maio de 2015, Lamar Owen escreveu: > On 05/08/2015 02:53 PM, John Levine wrote: > >> ... >> Most of the traffic will be from one node to another, with >> considerably less to the outside. Physical distance shouldn't be a >> problem since everything's in the same room, maybe the same rack. >> >> What's the rule of thumb for number of hosts per switch, cascaded >> switches vs. routers, and whatever else one needs to design a dense >> network like this? TIA >> >> You know, I read this post and immediately thought 'SGI Altix'........ > scalable to 512 CPU's per "system image" and 20 images per cluster (NASA's > Columbia supercomputer had 10,240 CPUs in that configuration.....twelve > years ago, using 1.5GHz 64-bit RISC CPUs running Linux.... my, how we've > come full circle.... (today's equivalent has less power consumption, at > least....)). The NUMA technology in those Altix CPU's is a de-facto > 'memory-area network' and thus can have some interesting topologies. > > Clusters can be made using nodes with at least two NICs in them, and no > switching. With four or eight ports you can do some nice mesh topologies. > This wouldn't be L2 bridging, either, but a L3 mesh could be made that > could be rather efficient, with no switches, as long as you have at least > three ports per node, and you can do something reasonably efficient with a > switch or two and some chains of nodes, with two NICs per node. L3 keeps > the broadcast domain size small, and broadcast overhead becomes small. > > If you only have one NIC per node, well, time to get some seriously > high-density switches..... but even then how many nodes are going to be per > 42U rack? A top-of-rack switch may only need 192 ports, and that's only > 4U, with 1U 48 port switches. 8U you can do 384 ports, and three racks will > do a bit over 1,000. Octopus cables going from an RJ21 to 8P8C modular are > available, so you could use high-density blades; Cisco claims you could do > 576 10/100/1000 ports in a 13-slot 6500. That's half the rack space for > the switching. If 10/100 is enough, you could do 12 of the WS-X6196-21AF > cards (or the RJ-45 'two-ports-per-plug' WS-X6148X2-45AF) and get in theory > 1,152 ports in a 6513 (one SUP; drop 96 ports from that to get a redundant > SUP). > > Looking at another post in the thread, these moonshot rigs sound > interesting.... 45 server blades in 4.3U. 4.3U?!?!? Heh, some custom > rails, I guess, to get ten in 47U. They claim a quad-server blade, so > 1,800 servers (with networking) in a 47U rack. Yow. Cost of several > hundred thousand dollars for that setup. > > The effective limit on subnet size would be of course broadcast overhead; > 1,000 nodes on a /22 would likely be painfully slow due to broadcast > overhead alone. > > -- Eduardo Schoedler From johnl at iecc.com Sun May 10 01:17:07 2015 From: johnl at iecc.com (John Levine) Date: 10 May 2015 01:17:07 -0000 Subject: Thousands of hosts on a gigabit LAN, maybe not In-Reply-To: Message-ID: <20150510011707.64948.qmail@ary.lan> In article you write: >Juniper OCX1100 have 72 ports in 1U. Yeah, too bad it costs $32,000. Other than that it'd be perfect. R's, John From listas at esds.com.br Sun May 10 01:31:40 2015 From: listas at esds.com.br (Eduardo Schoedler) Date: Sat, 9 May 2015 22:31:40 -0300 Subject: Thousands of hosts on a gigabit LAN, maybe not In-Reply-To: <20150510011707.64948.qmail@ary.lan> References: <20150510011707.64948.qmail@ary.lan> Message-ID: You do not mention low cost before ;) Em s?bado, 9 de maio de 2015, John Levine escreveu: > In article < > CAHf3uWyPQn1NS_umjZ-zNuk3i5uFcZBu9L39b-crovG6yUm2qA at mail.gmail.com > > you write: > >Juniper OCX1100 have 72 ports in 1U. > > Yeah, too bad it costs $32,000. Other than that it'd be perfect. > > R's, > John > -- Eduardo Schoedler From charles at thefnf.org Sun May 10 03:04:55 2015 From: charles at thefnf.org (charles at thefnf.org) Date: Sat, 09 May 2015 22:04:55 -0500 Subject: Thousands of hosts on a gigabit LAN, maybe not In-Reply-To: References: <20150508185303.55159.qmail@ary.lan> <554d44da.4d808c0a.5d93.ffffb706@mx.google.com> Message-ID: On 2015-05-09 11:57, Baldur Norddahl wrote: > The standard 48 port with 2 port uplink 1U switch is far from full > depth. > You put them in the back of the rack and have the small computers in > the > front. You might even turn the switches around, so the ports face > inwards > into the rack. The network cables would be very short and go directly > from > the mini computers (Raspberry Pi?) to the switch, all within the one > unit > shelf. Yes this. I presumed ras pi, but those don't have gigabit Ethernet. Then I realized: http://www.parallella.org/ (I've got one of these sitting on my standby shelf to be racked, which is what made me think of it). To the OP please do tell us more about what you are doing, it sounds very interesting. From johnl at iecc.com Sun May 10 03:10:23 2015 From: johnl at iecc.com (John Levine) Date: 10 May 2015 03:10:23 -0000 Subject: Thousands of hosts on a gigabit LAN, maybe not In-Reply-To: Message-ID: <20150510031023.65201.qmail@ary.lan> >To the OP please do tell us more about what you are doing, it sounds >very interesting. There's a conference paper in preparation. I'll send a pointer when I can. R's, John From larrysheldon at cox.net Sun May 10 03:25:21 2015 From: larrysheldon at cox.net (Larry Sheldon) Date: Sat, 09 May 2015 22:25:21 -0500 Subject: [probably spam, from "NANOG" ] In-Reply-To: References: Message-ID: <554ECFA1.2000605@cox.net> On 5/9/2015 18:10, Keith Medcalf wrote: > ...making the Web unusable unless you disable all security (or just > refuse to deal with the schmucks that do that). The only reasonable path for people who do not want to be invaded. It really is easier in the long run--and I find that it is the only the medical community who refuses to be sensible--so they spend the money to US-Mail the attachments to me. -- sed quis custodiet ipsos custodes? (Juvenal) From egypcio at googlemail.com Sat May 9 12:13:25 2015 From: egypcio at googlemail.com (=?UTF-8?Q?Vin=C3=ADcius_Zavam?=) Date: Sat, 9 May 2015 09:13:25 -0300 Subject: Fwd: BSDCon Brazil 2015 - Call for Papers Message-ID: ---------- Forwarded message ---------- From: BSDCon Brasil 2015 Date: 2015-05-08 12:52 GMT-03:00 Subject: BSDCon Brazil 2015 - Call for Papers To: INTRODUCTION BSDCon Brazil (http://www.bsdcon.com.br) is the brazilian BSD powered and flavored conference. The first edition was in 2005 and it brought together a great mix of *BSD developers and users for a nice blend of both developer-centric and user-centric presentations, and activities. This year BSDCon Brazil will be held from 9-10th October 2015, in Fortaleza (CE). OFFICIAL CALL We are proudly requesting proposals for presentations. We do not require academic or formal papers. If you wish to submit a formal paper, you are welcome to, but it is not required. Presentations are expected to be 45~60 minutes and are to be delivered in Portuguese (prefered), Spanish or English. The proposals presentation should be written with a very strong technical content bias. Proposals of a business development or marketing nature are not appropriate for this venue and will be rejected! Topics of interest to the conference include, but are not limited to: [*] Automation & Embedded Systems [*] Best Current Practices [*] Continuous Integration [*] Database Management Systems [*] Device Drivers [*] Documentation & Translation [*] Filesystems [*] Firewall & Routing [*] Getting Started to *BSD Systems [*] High Availability [*] Internet of Things (IoT) [*] IPv6 [*] Kernel Internals [*] Logging & Monitoring [*] Network Applications [*] Orchestration [*] Performance [*] Privacy & Security [*] Third-Party Applications Management [*] Virtualization [*] Wireless Transmissions We are waiting to read what you got! Please send all proposals to: submissions (@) bsdcon.com.br The proposals should contain a short and concise text description. The submission should also include a short CV of the speaker and an estimate of the expected travel expenses. SCHEDULE Proposals Acceptance May 8th 2015 ----- BEGINS June 14th 2015 --- ENDS Contact to Accepted Proposals Authors July 13th 2015 NOTES * If your talk is accepted, you are expected to present your talk in person; * Speakers do not register or pay conference fees; * We can pay for speakers flight and accommodation; * You pay for your own food and drink; * There will be a digital projector available in each lecture room. -- BSDCon Brazil 2015 http://www.bsdcon.com.br From jerry.anderson at wiline.com Sat May 9 21:14:17 2015 From: jerry.anderson at wiline.com (Jerry J. Anderson, CCIE #5000) Date: Sat, 9 May 2015 15:14:17 -0600 Subject: Thousands of hosts on a gigabit LAN, maybe not References: Message-ID: <107701d08a9d$1c880840$559818c0$@anderson@wiline.com> > Some people I know (yes really) are building a system that will have > several thousand little computers in some racks. Each of the > computers runs Linux and has a gigabit ethernet interface. It occurs > to me that it is unlikely that I can buy an ethernet switch with > thousands of ports, and even if I could, would I want a Linux system > to have 10,000 entries or more in its ARP table. > > Most of the traffic will be from one node to another, with > considerably less to the outside. Physical distance shouldn't be a > problem since everything's in the same room, maybe the same rack. > > What's the rule of thumb for number of hosts per switch, cascaded > switches vs. routers, and whatever else one needs to design a dense > network like this? TIA Brocade's Virtual Cluster Switching (VCS) fabric on their VDX switches is a good solution for large, flat data center networks like this. It's based on TRILL, so no STP or tree structure are required. All ports are live, as is all inter-switch bandwidth. Cisco has a similar solution, as do other vendors. Thank you, Jerry -- Jerry J. Anderson, CCIE #5000 Member, Anderson Consulting, LLC 800 Ridgeview Ave, Broomfield, CO? 80020-6618 Office: 650-523-2132???? Mobile: 773-793-7717 www.linkedin.com/in/AndersonConsultingLLC From bms at fastmail.net Sun May 10 04:01:42 2015 From: bms at fastmail.net (Bruce Simpson) Date: Sun, 10 May 2015 05:01:42 +0100 Subject: Thousands of hosts on a gigabit LAN, maybe not In-Reply-To: <1431210834.6801.48.camel@karl> References: <20150508185303.55159.qmail@ary.lan> <554E76CE.9090000@pari.edu> <1431210834.6801.48.camel@karl> Message-ID: <554ED826.7030404@fastmail.net> On 09/05/2015 23:33, Karl Auer wrote: > IPv4 ARP, for example, hits every on-subnet neighbour; the IPv6 > equivalent uses multicast to hit only those neighbours that happen to > share the same 24 low-end L3 address bits as the desired target - a > statistically much smaller subset of on-link neighbours, and in "normal" > subnets typically only one host. Only chatter that really should go to > all hosts does so - such as router advertisements. > Except when the IPv6 solicited-node multicast groups cause $VENDOR switch meltdown: http://blog.bimajority.org/2014/09/05/the-network-nightmare-that-ate-my-week/ From bz_siege_01 at hotmail.com Sun May 10 08:15:05 2015 From: bz_siege_01 at hotmail.com (c b) Date: Sun, 10 May 2015 01:15:05 -0700 Subject: Thousands of hosts on a gigabit LAN, maybe not In-Reply-To: <20150510011707.64948.qmail@ary.lan> References: , <20150510011707.64948.qmail@ary.lan> Message-ID: If you need that kind of density, I recommend a Clos fabric. Arista, Juniper, Brocade, Big Switch BCF and Cisco all have solutions that would allow you to build a high-density leaf/spine. You can build the Cisco solution with NXOS or ACI, depending which models you choose. The prices on these solutions are all somewhat in the same ballpark based on list pricing I've seen... even Cisco (the Nexus 9k is surprisingly in the same range as branded whitebox). There is also Pluribus which offers a fabric, but their niche is having server procs on board the switches and it seems like your project involves physical rather than virtual servers. Still, the Pluribus could be used without taking advantage of the on board server compute I suppose. I also recommend looking into a solution that supports VXLAN (or GENEVE, or whatever overlay works for your needs) simply because MAC is carried in Layer-3 so you won't have to deal with spanning tree or monstrous mac tables. But you don't need to do an overlay if you just segment with traditional VLANs. I'm guessing you don't need HA (A/B uplinks utilizing LACP) for these servers? Also, do you need line rate forwarding? Having 1,000 devices with 1Gb uplinks doesn't necessarily mean that full throughput is required... the clustering and the applications may be sporadic and bursty? I have seen load-testing clusters, hadoop and data warehousing pushing high volumes but the individual NICs in the clusters never actually hit capacity... If you need line-rate, then you need to do a deep dive with several of the vendors because there are significant differences in buffers on some models. And... what support do you need? Just one spare on the shelf or full vendor support on every switch? That will impact which vendor you choose. I'd like to hear more about this effort once you get it going. Which vendor you went with, how you tuned it, and why you selected who you did. Also, how it works. LFoD > Date: Sun, 10 May 2015 01:17:07 +0000 > From: johnl at iecc.com > To: nanog at nanog.org > Subject: Re: Thousands of hosts on a gigabit LAN, maybe not > > In article you write: > >Juniper OCX1100 have 72 ports in 1U. > > Yeah, too bad it costs $32,000. Other than that it'd be perfect. > > R's, > John From johnl at iecc.com Sun May 10 15:23:29 2015 From: johnl at iecc.com (John R. Levine) Date: 10 May 2015 11:23:29 -0400 Subject: Thousands of hosts on a gigabit LAN, maybe not In-Reply-To: References: , <20150510011707.64948.qmail@ary.lan> Message-ID: > Also, do you need line rate forwarding? Having 1,000 devices with 1Gb > uplinks doesn't necessarily mean that full throughput is required... the > clustering and the applications may be sporadic and bursty? It's definitely sporadic and bursty. There's another network for high speed traffic among the nodes. The Ethernet is for stuff like program loading from NFS servers.. > And... what support do you need? Just one spare on the shelf or full > vendor support on every switch? Spare on the shelf, definitely. R's, John From nick at foobar.org Sun May 10 16:16:42 2015 From: nick at foobar.org (Nick Hilliard) Date: Sun, 10 May 2015 18:16:42 +0200 Subject: Thousands of hosts on a gigabit LAN, maybe not In-Reply-To: <1431210834.6801.48.camel@karl> References: <20150508185303.55159.qmail@ary.lan> <554E76CE.9090000@pari.edu> <1431210834.6801.48.camel@karl> Message-ID: <554F846A.90900@foobar.org> On 10/05/2015 00:33, Karl Auer wrote: > Would be interesting to see how IPv6 performed, since is one of the > things it was supposed to be able to deliver - massively scalable links > (equivalent to an IPv4 broadcast domain) via massively reduced protocol > chatter (IPv6 multicast groups vs IPv4 broadcast), plus fully automated > L3 address assignment. It will perform badly because putting large numbers of hosts in a single broadcast domain is a bad idea, no matter what the protocol. If you have a very large L2 domain and if you use router advertisements to handle your default gateway announcement, you'll probably end up trashing your routers due to periodic neighbor solicitation messages. If you don't use tight timers, your failover convergence time will be trash. On the other hand, the tighter the timers, the more you'll trash your routers, particularly if there is a failover event - in other words, exactly when you don't want to stress the network. In the best case, the gateway unavailability mttr will be around 5-10 seconds and it will be non-deterministic. This means that if you want router failover which actually works, you will need to use a first-hop routing protocol like vrrp or similar. You will probably want to disable all multicast snooping on your network because of ipv6 chatter. Pushing state requirements into the L2 forwarding mechanism turns out not to be a good idea especially at scale - see the bimajority.org url that someone else posted on this thread, which is as much about poor switch implementation as it is about poor protocol design and solving problems that are a lot less relevant on today's networks. This will mean that you will also need to manually prune the scope of your dot1q network domain because otherwise the multicast chatter will be spammed network-wide across all vlans on which it's defined. RA gives the operator no way of controlling which IP address is assigned to which hosts, which means that the operator of the large l2 domain is likely to want to disable SLAAC if they plan to have any input on what IP address is assigned to what host. This may or may not be important to the operator. If it's hosts on a hot-seated corporate lan, probably it doesn't matter too much. If it's a service provider selling ipv6 services, it matters a lot. Regardless of whether this is the case, RA guard on each end-point is a necessity and if you don't have it, your control plane will be compromised. RA guard is more complicated than ARP / DHCP guard and is not well supported on a lot of hardware. Finally, if you have a connectivity problem with your large l2 domain, your problem surface area is much greater than if you segment your network into smaller chunks, which allows the scope of your outage to be a lot larger. Nick From frederik at kriewitz.eu Sun May 10 16:55:07 2015 From: frederik at kriewitz.eu (Frederik Kriewitz) Date: Sun, 10 May 2015 18:55:07 +0200 Subject: Updated prefix filtering In-Reply-To: References: Message-ID: Hello Dave, On Sun, May 10, 2015 at 1:49 AM, Dave Taht wrote: > I have had a piece long on the spike on how we implemented bcp38 for > linux (openwrt) devices using the ipset facility. > > We had a different use case (preventing all possible internal rfc1918 > network addresses from escaping, while still allowing punching through > one layer of nat ), but the underlying ipset facility was easily > extendible to actually do bcp38 and fast to use, so that is what we > ended up calling the openwrt package. Please contact me offlist if you > would like a peek at that piece, because the article had some > structural problems and we never got around to finishing/publishing > it, and I would like to.... > > has there been a bcp38 equivalent published for ipv6? I don't see how this is related to the OPs problem. But there's the rpfilter iptables module which can be used for BCP38 IPv4 and IPv6 implementations on linux routers. From marka at isc.org Sun May 10 23:17:05 2015 From: marka at isc.org (Mark Andrews) Date: Mon, 11 May 2015 09:17:05 +1000 Subject: Updated prefix filtering In-Reply-To: Your message of "Sat, 09 May 2015 16:49:50 -0700." References: Message-ID: <20150510231707.012E52DFBCC3@rock.dv.isc.org> In message , Dave Taht writes: > On Fri, May 8, 2015 at 3:41 PM, Chaim Rieger wrote= > : > > > > Best example I=E2=80=99ve found is located at http://jonsblog.lewis.org/= > > > > > I too ran out of space, Brocade, not Cisco though, and am looking to filt= > er prefixes. did anybody do a more recent or updated filter list since 200= > 8 ? > > > > Offlist is fine. > > > > Oh and happy friday to all. > > I have had a piece long on the spike on how we implemented bcp38 for > linux (openwrt) devices using the ipset facility. > > We had a different use case (preventing all possible internal rfc1918 > network addresses from escaping, while still allowing punching through > one layer of nat ), but the underlying ipset facility was easily > extendible to actually do bcp38 and fast to use, so that is what we > ended up calling the openwrt package. Please contact me offlist if you > would like a peek at that piece, because the article had some > structural problems and we never got around to finishing/publishing > it, and I would like to.... > > has there been a bcp38 equivalent published for ipv6? Yes, BCP 38. BCP 38 is address family agnostic. Just because the examples use IPv4 addresses doesn't mean that the concepts don't just map straight over onto IPv6. Source based routing is really only needed because BCP 38 filtering is being poorly implemented. Rather than collecting the full set of legitimate source addresses ISP's are only accepting the set of source addresses that they have allocated to the customer. With SIDR it should be possible to pass certs to the other ISP's that say "I am a legitimate source of these addresses" and do this all automatically. > Along the way source specific routing showed up for ipv6 and we ended > up obsoleting the concept of an ipv6 global default route entirely on > a linux based CPE router. > > see: http://arxiv.org/pdf/1403.0445.pdf and some relevant homenet wg stuff. > > d at nuc-client:~/babeld-1.6.0 $ ip -6 route > > default from 2001:558:6045:e9:251a:738a:ac86:eaf6 via > fe80::28c6:8eff:febb:9ff0 dev eth0 proto babel metric 1024 > default from 2601:9:4e00:4cb0::/60 via fe80::28c6:8eff:febb:9ff0 dev > eth0 proto babel metric 1024 > default from fde5:dfb9:df90:fff0::/60 via fe80::225:90ff:fef4:a5c5 dev > eth0 proto babel metric 1024 > > So this box will not forward any ipv6 not in the from(src) table. > > --=20 > Dave T=C3=A4ht > https://plus.google.com/u/0/explore/makewififast -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From chaim.rieger at gmail.com Mon May 11 18:38:08 2015 From: chaim.rieger at gmail.com (Chaim Rieger) Date: Mon, 11 May 2015 11:38:08 -0700 Subject: BGP offloading (fixing legacy router BGP scalability issues) In-Reply-To: References: Message-ID: <99E1AA1A-E047-4B88-A449-0BA7304C93D8@gmail.com> Freddy, did you get your test up ? I too am facing the same BGP scalability constraints as you are, and the only real viable solution seems to be filtering. I'll probably will setup a small test environment to see if this actually works as expected. Best Regards, Freddy From math at sizone.org Mon May 11 19:13:21 2015 From: math at sizone.org (Ken Chase) Date: Mon, 11 May 2015 15:13:21 -0400 Subject: yahoo email contact offlist please Message-ID: <20150511191321.GR3289@sizone.org> Client seeing repeated yahoo DNS resolve failures against multiple domains for email, despite all other recursive resolvers having no issue. Please contact me off list. /kc -- Ken Chase - ken at heavycomputing.ca Toronto Canada Heavy Computing - Clued bandwidth, colocation and managed linux VPS @151 Front St. W. From clay at bloomcounty.org Mon May 11 20:37:45 2015 From: clay at bloomcounty.org (Clay Fiske) Date: Mon, 11 May 2015 13:37:45 -0700 Subject: Rasberry pi - high density In-Reply-To: <3add94118911fb463b174ab24631657b@thefnf.org> References: <3add94118911fb463b174ab24631657b@thefnf.org> Message-ID: > On May 8, 2015, at 10:24 PM, charles at thefnf.org wrote: > > Pi dimensions: > > 3.37 l (5 front to back) > 2.21 w (6 wide) > 0.83 h > 25 per U (rounding down for Ethernet cable space etc) = 825 pi > > Cable management and heat would probably kill this before it ever reached completion, but lol? This feels like it should be a Friday thread. :) If you?re really going for density: - At 0.83 inches high you could go 2x per U (depends on your mounting system and how much space it burns) - I?d expect you could get at least 7 wide if not 8 with the right micro-USB power connector - In most datacenter racks I?ve seen you could get at least 8 deep even with cable breathing room So somewhere between 7x8x2 = 112 and 8x8x2 = 128 per U. And if you get truly creative about how you stack them you could probably beat that without too much effort. This doesn?t solve for cooling, but I think even at these numbers you could probably make it work with nice, tight cabling. -c From dave.taht at gmail.com Mon May 11 20:52:32 2015 From: dave.taht at gmail.com (Dave Taht) Date: Mon, 11 May 2015 13:52:32 -0700 Subject: Rasberry pi - high density In-Reply-To: References: <3add94118911fb463b174ab24631657b@thefnf.org> Message-ID: On Mon, May 11, 2015 at 1:37 PM, Clay Fiske wrote: > >> On May 8, 2015, at 10:24 PM, charles at thefnf.org wrote: >> >> Pi dimensions: >> >> 3.37 l (5 front to back) >> 2.21 w (6 wide) >> 0.83 h >> 25 per U (rounding down for Ethernet cable space etc) = 825 pi The parallella board is about the same size and has interesting properties all by itself. In addition to ethernet it also brings out a lot of pins. http://www.adapteva.com/parallella-board/ there are also various and sundry quad core arm boards in the same form factor. >> Cable management and heat would probably kill this before it ever reached completion, but lol? > > > This feels like it should be a Friday thread. :) > > If you?re really going for density: > > - At 0.83 inches high you could go 2x per U (depends on your mounting system and how much space it burns) > - I?d expect you could get at least 7 wide if not 8 with the right micro-USB power connector > - In most datacenter racks I?ve seen you could get at least 8 deep even with cable breathing room > > So somewhere between 7x8x2 = 112 and 8x8x2 = 128 per U. And if you get truly creative about how you stack them you could probably beat that without too much effort. > > This doesn?t solve for cooling, but I think even at these numbers you could probably make it work with nice, tight cabling. Dip them all in a vat of oil. -- Dave T?ht Open Networking needs **Open Hardware** https://plus.google.com/u/0/+EricRaymond/posts/JqxCe2pFr67 From petebaldridge at gmail.com Mon May 11 21:36:11 2015 From: petebaldridge at gmail.com (Peter Baldridge) Date: Mon, 11 May 2015 14:36:11 -0700 Subject: Rasberry pi - high density In-Reply-To: References: <3add94118911fb463b174ab24631657b@thefnf.org> Message-ID: >>> Pi dimensions: >>> >>> 3.37 l (5 front to back) >>> 2.21 w (6 wide) >>> 0.83 h >>> 25 per U (rounding down for Ethernet cable space etc) = 825 pi You butt up against major power/heat issues here in a single rack, not that it's impossible. From what I could find the rPi2 requires .5A min. The few SSD specs that I could find required something like .8 - 1.6A. Assuming that part of .5A is for driving a SSD, 1A/pi would be an optimistic requirement. So 825-1600 amp in a single rack. It's not crazy to throw 120AMP in a rack for higher density but you would need room to put a PDU ever 2 u or so if you were running a 30amp circus. That's before switching infrastructure. You'll also need airflow since that's not built into the pi. I've seen guys do this with mac minis and they end up needing to push everything back in the rack 4 inches to put 3 or 4 fans with 19in blades on the front door to make the airflow data center ready. So to start, you'd probably need to take a row out of the front of the rack for fans and a row out of the back for power. Cooling isn't really an issue since you can cool anything that you can blow air on[1]. At 825 rpi @ 1Amp each, you'd get about 3000 btu/h (double for the higher power estimate). You'd need need 3-6 tons of avalible cooling capacity without redundancy. I don't know how to do the math for the 'vat of oil scenario'. It's not something I've ever wanted to work with. In the end, I think you end up putting way too much money (power/cooling) into the redundant green board around the CPU. >> This feels like it should be a Friday thread. :) Maybe I'm having a read only may 10-17. 1. Please don't list the things that can't be cooled by blowing air. -- Pete From mike at mtcc.com Mon May 11 21:40:15 2015 From: mike at mtcc.com (Michael Thomas) Date: Mon, 11 May 2015 14:40:15 -0700 Subject: Rasberry pi - high density In-Reply-To: References: <3add94118911fb463b174ab24631657b@thefnf.org> Message-ID: <555121BF.4040708@mtcc.com> As it turns out, I've been playing around benchmarking things lately using the tried and true UnixBench suite and here are a few numbers that might put this in some perspective: 1) My new Rapsberry pi (4 cores, arm): 406 2) My home i5-like thing (asus 4 cores, 16gb's from last year): 3857 3) AWS c4.xlarge (4 cores, ~8gb's): 3666 So you'd need to, uh, wedge about 10 pi's to get one half way modern x86. Mike On 5/11/15 1:37 PM, Clay Fiske wrote: >> On May 8, 2015, at 10:24 PM, charles at thefnf.org wrote: >> >> Pi dimensions: >> >> 3.37 l (5 front to back) >> 2.21 w (6 wide) >> 0.83 h >> 25 per U (rounding down for Ethernet cable space etc) = 825 pi >> >> Cable management and heat would probably kill this before it ever reached completion, but lol? > > This feels like it should be a Friday thread. :) > > If you?re really going for density: > > - At 0.83 inches high you could go 2x per U (depends on your mounting system and how much space it burns) > - I?d expect you could get at least 7 wide if not 8 with the right micro-USB power connector > - In most datacenter racks I?ve seen you could get at least 8 deep even with cable breathing room > > So somewhere between 7x8x2 = 112 and 8x8x2 = 128 per U. And if you get truly creative about how you stack them you could probably beat that without too much effort. > > This doesn?t solve for cooling, but I think even at these numbers you could probably make it work with nice, tight cabling. > > > -c > > From rafael at gav.ufsc.br Mon May 11 22:08:43 2015 From: rafael at gav.ufsc.br (Rafael Possamai) Date: Mon, 11 May 2015 17:08:43 -0500 Subject: Rasberry pi - high density In-Reply-To: <555121BF.4040708@mtcc.com> References: <3add94118911fb463b174ab24631657b@thefnf.org> <555121BF.4040708@mtcc.com> Message-ID: Interesting! Knowing a pi costs approximately $35, then you need approximately $350 to get near an i5.. The smallest and cheapest desktop you can get that would have similar power is the Intel NUC with an i5 that goes for approximately $350. Power consumption of a NUC is about 5x that of the raspberry pi, but the number of ethernet ports required is 10x less. Usually in a datacenter you care much more about power than switch ports, so in this case if the overhead of controlling 10x the number of nodes is worth it, I'd still consider the raspberry pi. Did I miss anything? Just a quick comparison. On Mon, May 11, 2015 at 4:40 PM, Michael Thomas wrote: > As it turns out, I've been playing around benchmarking things lately using > the tried and true > UnixBench suite and here are a few numbers that might put this in some > perspective: > > 1) My new Rapsberry pi (4 cores, arm): 406 > 2) My home i5-like thing (asus 4 cores, 16gb's from last year): 3857 > 3) AWS c4.xlarge (4 cores, ~8gb's): 3666 > > So you'd need to, uh, wedge about 10 pi's to get one half way modern x86. > > Mike > > > On 5/11/15 1:37 PM, Clay Fiske wrote: > >> On May 8, 2015, at 10:24 PM, charles at thefnf.org wrote: >>> >>> Pi dimensions: >>> >>> 3.37 l (5 front to back) >>> 2.21 w (6 wide) >>> 0.83 h >>> 25 per U (rounding down for Ethernet cable space etc) = 825 pi >>> >>> Cable management and heat would probably kill this before it ever >>> reached completion, but lol? >>> >> >> This feels like it should be a Friday thread. :) >> >> If you?re really going for density: >> >> - At 0.83 inches high you could go 2x per U (depends on your mounting >> system and how much space it burns) >> - I?d expect you could get at least 7 wide if not 8 with the right >> micro-USB power connector >> - In most datacenter racks I?ve seen you could get at least 8 deep even >> with cable breathing room >> >> So somewhere between 7x8x2 = 112 and 8x8x2 = 128 per U. And if you get >> truly creative about how you stack them you could probably beat that >> without too much effort. >> >> This doesn?t solve for cooling, but I think even at these numbers you >> could probably make it work with nice, tight cabling. >> >> >> -c >> >> >> > From rcarpen at network1.net Mon May 11 22:21:32 2015 From: rcarpen at network1.net (Randy Carpenter) Date: Mon, 11 May 2015 18:21:32 -0400 (EDT) Subject: Rasberry pi - high density In-Reply-To: References: <3add94118911fb463b174ab24631657b@thefnf.org> Message-ID: <861301006.1104175.1431382892145.JavaMail.zimbra@network1.net> ----- On May 11, 2015, at 5:36 PM, Peter Baldridge petebaldridge at gmail.com wrote: >>>> Pi dimensions: >>>> >>>> 3.37 l (5 front to back) >>>> 2.21 w (6 wide) >>>> 0.83 h >>>> 25 per U (rounding down for Ethernet cable space etc) = 825 pi > > You butt up against major power/heat issues here in a single rack, not > that it's impossible. From what I could find the rPi2 requires .5A > min. The few SSD specs that I could find required something like .8 - > 1.6A. Assuming that part of .5A is for driving a SSD, 1A/pi would be > an optimistic requirement. So 825-1600 amp in a single rack. It's > not crazy to throw 120AMP in a rack for higher density but you would > need room to put a PDU ever 2 u or so if you were running a 30amp > circus. > That is .8-1.6A at 5v DC. A far cry from 120V AC. We're talking ~5W versus ~120W each. Granted there is some conversion overhead, but worst case you are probably talking about 1/20th the power you describe. -Randy From hugo at slabnet.com Mon May 11 22:24:19 2015 From: hugo at slabnet.com (Hugo Slabbert) Date: Mon, 11 May 2015 15:24:19 -0700 Subject: Rasberry pi - high density In-Reply-To: References: <3add94118911fb463b174ab24631657b@thefnf.org> <555121BF.4040708@mtcc.com> Message-ID: <20150511222419.GC26580@bamboo.slabnet.com> >Did I miss anything? Just a quick comparison. If those numbers are accurate, then it leans towards the NUC rather than the Pi, no? Perf: 1x i5 NUC = 10x Pi $$: 1x i5 NUC = 10x Pi Power: 1x i5 NUC = 5x Pi So...if a single NUC gives you the performance of 10x Pis at the capital cost of 10x Pis but uses half the power of 10x Pis and only a single Ethernet port, how does the Pi win? -- Hugo On Mon 2015-May-11 17:08:43 -0500, Rafael Possamai wrote: >Interesting! Knowing a pi costs approximately $35, then you need >approximately $350 to get near an i5.. The smallest and cheapest desktop >you can get that would have similar power is the Intel NUC with an i5 that >goes for approximately $350. Power consumption of a NUC is about 5x that of >the raspberry pi, but the number of ethernet ports required is 10x less. >Usually in a datacenter you care much more about power than switch ports, >so in this case if the overhead of controlling 10x the number of nodes is >worth it, I'd still consider the raspberry pi. Did I miss anything? Just a >quick comparison. > > > >On Mon, May 11, 2015 at 4:40 PM, Michael Thomas wrote: > >> As it turns out, I've been playing around benchmarking things lately using >> the tried and true >> UnixBench suite and here are a few numbers that might put this in some >> perspective: >> >> 1) My new Rapsberry pi (4 cores, arm): 406 >> 2) My home i5-like thing (asus 4 cores, 16gb's from last year): 3857 >> 3) AWS c4.xlarge (4 cores, ~8gb's): 3666 >> >> So you'd need to, uh, wedge about 10 pi's to get one half way modern x86. >> >> Mike >> >> >> On 5/11/15 1:37 PM, Clay Fiske wrote: >> >>> On May 8, 2015, at 10:24 PM, charles at thefnf.org wrote: >>>> >>>> Pi dimensions: >>>> >>>> 3.37 l (5 front to back) >>>> 2.21 w (6 wide) >>>> 0.83 h >>>> 25 per U (rounding down for Ethernet cable space etc) = 825 pi >>>> >>>> Cable management and heat would probably kill this before it ever >>>> reached completion, but lol? >>>> >>> >>> This feels like it should be a Friday thread. :) >>> >>> If you?re really going for density: >>> >>> - At 0.83 inches high you could go 2x per U (depends on your mounting >>> system and how much space it burns) >>> - I?d expect you could get at least 7 wide if not 8 with the right >>> micro-USB power connector >>> - In most datacenter racks I?ve seen you could get at least 8 deep even >>> with cable breathing room >>> >>> So somewhere between 7x8x2 = 112 and 8x8x2 = 128 per U. And if you get >>> truly creative about how you stack them you could probably beat that >>> without too much effort. >>> >>> This doesn?t solve for cooling, but I think even at these numbers you >>> could probably make it work with nice, tight cabling. >>> >>> >>> -c >>> >>> >>> >> -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From petebaldridge at gmail.com Mon May 11 22:30:55 2015 From: petebaldridge at gmail.com (Peter Baldridge) Date: Mon, 11 May 2015 15:30:55 -0700 Subject: Rasberry pi - high density In-Reply-To: <861301006.1104175.1431382892145.JavaMail.zimbra@network1.net> References: <3add94118911fb463b174ab24631657b@thefnf.org> <861301006.1104175.1431382892145.JavaMail.zimbra@network1.net> Message-ID: On Mon, May 11, 2015 at 3:21 PM, Randy Carpenter wrote: > > That is .8-1.6A at 5v DC. A far cry from 120V AC. We're talking ~5W versus ~120W each. > > Granted there is some conversion overhead, but worst case you are probably talking about 1/20th the power you describe. Yeah, missed that. You'd still need fans probably for air flow but the power would be a non issue. -- Pete From cboyd at gizmopartners.com Mon May 11 22:33:53 2015 From: cboyd at gizmopartners.com (Chris Boyd) Date: Mon, 11 May 2015 17:33:53 -0500 Subject: Rasberry pi - high density In-Reply-To: References: <3add94118911fb463b174ab24631657b@thefnf.org> Message-ID: <1431383633.8613.15.camel@beagle> On Mon, 2015-05-11 at 14:36 -0700, Peter Baldridge wrote: > I don't know how to do the math for the 'vat of oil scenario'. It's > not something I've ever wanted to work with. It's pretty interesting what you can do with immersion cooling. I work with it at $DAYJOB. Similar to air cooling, but your coolant flow rates are much lower than air, and you don't need any fans in the systems--The pumps take the place of those. We save a lot of money on the cooling side, since we don't need to compress and expand gases/liquids. We can run with warmish (25-30C) water from cooling towers, and still keep the systems at a target temperature of 35C. --Chris From lists.nanog at monmotha.net Mon May 11 22:50:59 2015 From: lists.nanog at monmotha.net (Brandon Martin) Date: Mon, 11 May 2015 18:50:59 -0400 Subject: Rasberry pi - high density In-Reply-To: <861301006.1104175.1431382892145.JavaMail.zimbra@network1.net> References: <3add94118911fb463b174ab24631657b@thefnf.org> <861301006.1104175.1431382892145.JavaMail.zimbra@network1.net> Message-ID: <55513253.1030401@monmotha.net> On 05/11/2015 06:21 PM, Randy Carpenter wrote: > That is .8-1.6A at 5v DC. A far cry from 120V AC. We're talking ~5W versus ~120W each. > > Granted there is some conversion overhead, but worst case you are probably talking about 1/20th the power you describe. His estimates seem to consider that it's only 5V, though. He has 825 Pis per rack at ~5-10W each is call it ~8kW on the high end. 8kW is 2.25 tons of refrigeration at first cut, plus any power conversion losses, losses in ducting/chilled water distribution, etc. Calling for at least 3 tons of raw cooling capacity for this rack seems reasonable. 8kW/rack is something it seems many a typical computing oriented datacenter would be used to dealing with, no? Formfactor within the rack is just a little different which may complicate how you can deliver the cooling - might need unusually forceful forced air or a water/oil type heat exchanger for the oil immersion method being discussed elsewhere in the thread. You still need giant wires and busses to move 800A worth of current. It almost seems like you'd have to rig up some sort of 5VDC bus bar system along the sides of the cabinet and tap into it for each shelf or (probably the approach I'd look at first, instead) give up some space on each shelf or so for point-of-load power conversion (120 or 240VAC to 5VDC using industrial "brick" style supplies or similar) and conventional AC or "high voltage" (in this context, 48 or 380V is "high") DC distribution to each shelf. Getting 800A at 5V to the rack with reasonable losses is going to need humongous wires, too. Looks like NEC calls for something on the order of 800kcmil under rosy circumstances just to move it "safely" (which, at only 5V, is not necessarily "effectively") - yikes that's a big wire. -- Brandon Martin From rafael at gav.ufsc.br Mon May 11 23:16:27 2015 From: rafael at gav.ufsc.br (Rafael Possamai) Date: Mon, 11 May 2015 18:16:27 -0500 Subject: Rasberry pi - high density In-Reply-To: <20150511222419.GC26580@bamboo.slabnet.com> References: <3add94118911fb463b174ab24631657b@thefnf.org> <555121BF.4040708@mtcc.com> <20150511222419.GC26580@bamboo.slabnet.com> Message-ID: Maybe I messed up the math in my head, my line of thought was one pi is estimated to use 1.2 watts, whereas the nuc is at around 65 watts. 10 pi's = 12 watts. My comparison was 65watts/12watts = 5.4 times more power than 10 pi's put together. This is really a rough estimate because I got the NUC's power consumption from the AC/DC converter that comes with it, which has a maximum output of 65 watts. I could be wrong (up to 5 times) and still the pi would use less power. Now that I think about it, the best way to simplify this is to calculate benchmark points per watt, so rasp pi is at around 406/1.2 which equals 338. The NUC, roughly estimated to be at 3857/65 which equals 60. Let's be very skeptical and say that at maximum consumption the pi is using 5 watts, then 406/5 is around 81. At this point the rasp pi still scores better. Only problem we are comparing ARM to x86 which isn't necessarily fair (i am not an expert in computer architectures) On Mon, May 11, 2015 at 5:24 PM, Hugo Slabbert wrote: > Did I miss anything? Just a quick comparison. >> > > If those numbers are accurate, then it leans towards the NUC rather than > the Pi, no? > > Perf: 1x i5 NUC = 10x Pi > $$: 1x i5 NUC = 10x Pi > Power: 1x i5 NUC = 5x Pi > > So...if a single NUC gives you the performance of 10x Pis at the capital > cost of 10x Pis but uses half the power of 10x Pis and only a single > Ethernet port, how does the Pi win? > > -- > Hugo > > > On Mon 2015-May-11 17:08:43 -0500, Rafael Possamai > wrote: > > Interesting! Knowing a pi costs approximately $35, then you need >> approximately $350 to get near an i5.. The smallest and cheapest desktop >> you can get that would have similar power is the Intel NUC with an i5 that >> goes for approximately $350. Power consumption of a NUC is about 5x that >> of >> the raspberry pi, but the number of ethernet ports required is 10x less. >> Usually in a datacenter you care much more about power than switch ports, >> so in this case if the overhead of controlling 10x the number of nodes is >> worth it, I'd still consider the raspberry pi. Did I miss anything? Just a >> quick comparison. >> >> >> >> On Mon, May 11, 2015 at 4:40 PM, Michael Thomas wrote: >> >> As it turns out, I've been playing around benchmarking things lately >>> using >>> the tried and true >>> UnixBench suite and here are a few numbers that might put this in some >>> perspective: >>> >>> 1) My new Rapsberry pi (4 cores, arm): 406 >>> 2) My home i5-like thing (asus 4 cores, 16gb's from last year): 3857 >>> 3) AWS c4.xlarge (4 cores, ~8gb's): 3666 >>> >>> So you'd need to, uh, wedge about 10 pi's to get one half way modern x86. >>> >>> Mike >>> >>> >>> On 5/11/15 1:37 PM, Clay Fiske wrote: >>> >>> On May 8, 2015, at 10:24 PM, charles at thefnf.org wrote: >>>> >>>>> >>>>> Pi dimensions: >>>>> >>>>> 3.37 l (5 front to back) >>>>> 2.21 w (6 wide) >>>>> 0.83 h >>>>> 25 per U (rounding down for Ethernet cable space etc) = 825 pi >>>>> >>>>> Cable management and heat would probably kill this before it ever >>>>> reached completion, but lol? >>>>> >>>>> >>>> This feels like it should be a Friday thread. :) >>>> >>>> If you?re really going for density: >>>> >>>> - At 0.83 inches high you could go 2x per U (depends on your mounting >>>> system and how much space it burns) >>>> - I?d expect you could get at least 7 wide if not 8 with the right >>>> micro-USB power connector >>>> - In most datacenter racks I?ve seen you could get at least 8 deep even >>>> with cable breathing room >>>> >>>> So somewhere between 7x8x2 = 112 and 8x8x2 = 128 per U. And if you get >>>> truly creative about how you stack them you could probably beat that >>>> without too much effort. >>>> >>>> This doesn?t solve for cooling, but I think even at these numbers you >>>> could probably make it work with nice, tight cabling. >>>> >>>> >>>> -c >>>> >>>> >>>> >>>> >>> From jmaslak at antelope.net Tue May 12 03:25:10 2015 From: jmaslak at antelope.net (Joel Maslak) Date: Mon, 11 May 2015 21:25:10 -0600 Subject: Rasberry pi - high density In-Reply-To: References: <3add94118911fb463b174ab24631657b@thefnf.org> <555121BF.4040708@mtcc.com> <20150511222419.GC26580@bamboo.slabnet.com> Message-ID: Rather then guessing on power consumption, I measured it. I took a Pi (Model B - but I suspect B+ and the new version is relatively similar in power draw with the same peripherials), hooked it up to a lab power supply, and took a current measurement. My pi has a Sandisk SD card and a Sandisk USB stick plugged into it, so, if anything, it will be a bit high in power draw. I then fired off a tight code loop and a ping -f from another host towards it, to busy up the processor and the network/USB on the Pi. I don't have a way of making the video do anything, so if you were using that, your draw would be up. I also measured idle usage (sitting at a command prompt). Power draw was 2.3W under load, 2.0W at idle. If it was my project, I'd build a backplane board with USB-to-ethernet and ethernet switch chips, along with sockets for Pi compute modules (or something similar). I'd want one power cable and one network cable per backplane board if my requirements allowed it. Stick it all in a nice card cage and you're done. As for performance per watt, I'd be surprised if this beat a modern video processor for the right workload. On Mon, May 11, 2015 at 5:16 PM, Rafael Possamai wrote: > Maybe I messed up the math in my head, my line of thought was one pi is > estimated to use 1.2 watts, whereas the nuc is at around 65 watts. 10 pi's > = 12 watts. My comparison was 65watts/12watts = 5.4 times more power than > 10 pi's put together. This is really a rough estimate because I got the > NUC's power consumption from the AC/DC converter that comes with it, which > has a maximum output of 65 watts. I could be wrong (up to 5 times) and > still the pi would use less power. > > Now that I think about it, the best way to simplify this is to calculate > benchmark points per watt, so rasp pi is at around 406/1.2 which equals > 338. The NUC, roughly estimated to be at 3857/65 which equals 60. Let's be > very skeptical and say that at maximum consumption the pi is using 5 watts, > then 406/5 is around 81. At this point the rasp pi still scores better. > > Only problem we are comparing ARM to x86 which isn't necessarily fair (i am > not an expert in computer architectures) > > > > > > On Mon, May 11, 2015 at 5:24 PM, Hugo Slabbert wrote: > > > Did I miss anything? Just a quick comparison. > >> > > > > If those numbers are accurate, then it leans towards the NUC rather than > > the Pi, no? > > > > Perf: 1x i5 NUC = 10x Pi > > $$: 1x i5 NUC = 10x Pi > > Power: 1x i5 NUC = 5x Pi > > > > So...if a single NUC gives you the performance of 10x Pis at the capital > > cost of 10x Pis but uses half the power of 10x Pis and only a single > > Ethernet port, how does the Pi win? > > > > -- > > Hugo > > > > > > On Mon 2015-May-11 17:08:43 -0500, Rafael Possamai > > wrote: > > > > Interesting! Knowing a pi costs approximately $35, then you need > >> approximately $350 to get near an i5.. The smallest and cheapest desktop > >> you can get that would have similar power is the Intel NUC with an i5 > that > >> goes for approximately $350. Power consumption of a NUC is about 5x that > >> of > >> the raspberry pi, but the number of ethernet ports required is 10x less. > >> Usually in a datacenter you care much more about power than switch > ports, > >> so in this case if the overhead of controlling 10x the number of nodes > is > >> worth it, I'd still consider the raspberry pi. Did I miss anything? > Just a > >> quick comparison. > >> > >> > >> > >> On Mon, May 11, 2015 at 4:40 PM, Michael Thomas wrote: > >> > >> As it turns out, I've been playing around benchmarking things lately > >>> using > >>> the tried and true > >>> UnixBench suite and here are a few numbers that might put this in some > >>> perspective: > >>> > >>> 1) My new Rapsberry pi (4 cores, arm): 406 > >>> 2) My home i5-like thing (asus 4 cores, 16gb's from last year): 3857 > >>> 3) AWS c4.xlarge (4 cores, ~8gb's): 3666 > >>> > >>> So you'd need to, uh, wedge about 10 pi's to get one half way modern > x86. > >>> > >>> Mike > >>> > >>> > >>> On 5/11/15 1:37 PM, Clay Fiske wrote: > >>> > >>> On May 8, 2015, at 10:24 PM, charles at thefnf.org wrote: > >>>> > >>>>> > >>>>> Pi dimensions: > >>>>> > >>>>> 3.37 l (5 front to back) > >>>>> 2.21 w (6 wide) > >>>>> 0.83 h > >>>>> 25 per U (rounding down for Ethernet cable space etc) = 825 pi > >>>>> > >>>>> Cable management and heat would probably kill this before it ever > >>>>> reached completion, but lol? > >>>>> > >>>>> > >>>> This feels like it should be a Friday thread. :) > >>>> > >>>> If you?re really going for density: > >>>> > >>>> - At 0.83 inches high you could go 2x per U (depends on your mounting > >>>> system and how much space it burns) > >>>> - I?d expect you could get at least 7 wide if not 8 with the right > >>>> micro-USB power connector > >>>> - In most datacenter racks I?ve seen you could get at least 8 deep > even > >>>> with cable breathing room > >>>> > >>>> So somewhere between 7x8x2 = 112 and 8x8x2 = 128 per U. And if you get > >>>> truly creative about how you stack them you could probably beat that > >>>> without too much effort. > >>>> > >>>> This doesn?t solve for cooling, but I think even at these numbers you > >>>> could probably make it work with nice, tight cabling. > >>>> > >>>> > >>>> -c > >>>> > >>>> > >>>> > >>>> > >>> > From contact at winterei.se Tue May 12 13:36:11 2015 From: contact at winterei.se (Paul S.) Date: Tue, 12 May 2015 22:36:11 +0900 Subject: Recommended 10GE ISCSI SAN switch Message-ID: <555201CB.7060900@winterei.se> Hi guys, We're shortly going to be getting some 10G SANs, and I was wondering what people were using as SAN switches for 10G SANs. It is my understanding that low buffer sizes make most 'normal' 10G ethernet switches unsuitable for the job. We're pretty much an exclusive Juniper shop, but are not biased in any way -- best tool for the job is what I've been tasked with to find. Keeping that in mind, how would something like a EX4550 fare in the role? Are there better devices in the same price range? Thanks! From alexb at ripe.net Tue May 12 13:59:56 2015 From: alexb at ripe.net (Alex Band) Date: Tue, 12 May 2015 15:59:56 +0200 Subject: RPKI Validator 2.19; export ROAs as RPSL route: objects Message-ID: <0AEB6C4C-9DEC-43BB-BACA-AB6E6D1EAE41@ripe.net> Hello, We've been getting a lot of requests to make processed RPKI data easily available in existing (RPSL based) workflows. This is why we added the ability to export all ROAs as route: objects in the latest release, version 2.19. Practically, this means that running an RPSL export will give you almost 450,000 highly reliable, cryptographically validated route: objects. This functionality should be considered beta for now, because we would like to get your feedback on the notation and the way we de-aggregate ROAs into route: objects based on the specified maximum prefix length. The format looks like this: route: 193.0.12.0/23 origin: AS3333 descr: exported from ripe ncc validator mnt-by: NA created: 2015-05-07T10:01:56Z last-modified: 2015-05-07T10:01:56Z source: ROA-RIPE-NCC-RPKI-ROOT For details on the implementation, please refer to the README: https://github.com/RIPE-NCC/rpki-validator/blob/master/rpki-validator-app/README.txt#L185 Here's a link to a snapshot I just made: https://alexband.nl/temp/export-20150512.rpsl.zip You can download the RPKI Validator here: https://ripe.net/certification/tools-and-resources We look forward to your feedback. Pull requests are welcome too. :) Cheers, Alex Band Product Manager RIPE NCC From stephen.carter at gltgc.org Tue May 12 14:52:10 2015 From: stephen.carter at gltgc.org (Stephen R. Carter) Date: Tue, 12 May 2015 14:52:10 +0000 Subject: Recommended 10GE ISCSI SAN switch In-Reply-To: <555201CB.7060900@winterei.se> References: <555201CB.7060900@winterei.se> Message-ID: I use a ex4550 VC as our TOR for our ESXi / EQL array in one spot, and a pair of QFX5100-48S in another. No issues here with either of them. The 5100?s have a possibility of being comparable in price once you add in the VC cards and so forth for a pair of 4550?s. I would get a quote for them both to see, hard to guess without knowing what kind of deals your VAR can do. Stephen Carter On 5/12/15, 9:36 AM, "Paul S." wrote: >Hi guys, > >We're shortly going to be getting some 10G SANs, and I was wondering >what people were using as SAN switches for 10G SANs. > >It is my understanding that low buffer sizes make most 'normal' 10G >ethernet switches unsuitable for the job. > >We're pretty much an exclusive Juniper shop, but are not biased in any >way -- best tool for the job is what I've been tasked with to find. > >Keeping that in mind, how would something like a EX4550 fare in the >role? Are there better devices in the same price range? > >Thanks!
The information contained in this electronic transmission (email) is confidential information and may be subject to attorney/client privilege. It is intended only for the use of the individual or entity named above. ANY DISTRIBUTION OR COPYING OF THIS MESSAGE IS PROHIBITED, except by the intended recipient. Attempts to intercept this message are in violation of 18 U.S.C. 2511(1) of the Electronic Communications Privacy Act (ECPA), which subjects the interceptor to fines, imprisonment and/or civil damages. From seth.mos at dds.nl Tue May 12 15:05:06 2015 From: seth.mos at dds.nl (Seth Mos) Date: Tue, 12 May 2015 17:05:06 +0200 Subject: Recommended 10GE ISCSI SAN switch In-Reply-To: <555201CB.7060900@winterei.se> References: <555201CB.7060900@winterei.se> Message-ID: <555216A2.6070508@dds.nl> Paul S. schreef op 12-5-2015 om 15:36: > Hi guys, > > We're shortly going to be getting some 10G SANs, and I was wondering > what people were using as SAN switches for 10G SANs. In one location a HP Procurve 8212zl with 8 SFP+ module, and a 8Gbe module. Here i'm using a Dell EQL PS6210 SSD cabinet and 24 SATA disk EQL cabinet on 10G. In another location on a budget a Netgear M7100 24X with a Dell EQL PS6010 with Intel S3500 800GB SSDs. In both locations the switches appear to be doing fine in combination with VMware ESXi 5.5 and Intel X540-2 cards. > It is my understanding that low buffer sizes make most 'normal' 10G > ethernet switches unsuitable for the job. Not so sure on that, opinions vary a lot here. Similar to the stance on Flow Control where one vendor will advocate using it and another advocates against it. If you only have a single link, then Flow control will sleep the connection which can impact your performance with a higher Queue depth. For multiple 1G links the impact is ofcourse a lot less overall. If you are going to invest in a new SAN make sure to ditch spinning rust, it's the biggest breakthrough in storage since a while and it's a factor of a *lot*. The price doesn't break the bank either, the Dell EQL 6110 was out of warranty, retail value around $3500 us. The 18 Intel S3500 SSDs were about 11k euro (16 + 2 spare). In raid 6 that's a good 10TB of storage. It's a shame that SAN HQ keeps emailing us once a day that the drives are not original ;) With that sheer amount of space it's going to take a while before it ever breaks (wears out). It'll be out of service long before then. Also, you can max out a single 10G link with about 4-6 recent SSDs, so smaller cabinets with more uplinks make all the sense. In that respect the newer cabinets (Dell EQL PS6210) with 24 drives and just 2 10Ge uplinks are a bit odd. Still, it's nice to do 300-400MB/s in a VM on a 5 year old ESX on a dime. :) > We're pretty much an exclusive Juniper shop, but are not biased in any > way -- best tool for the job is what I've been tasked with to find. > > Keeping that in mind, how would something like a EX4550 fare in the > role? Are there better devices in the same price range? If the switches work for you and you are comfortable with them I'd count that as a better argument. Only budget switches are likely to cause you real grief here. Kind regards, Seth From rafael at gav.ufsc.br Tue May 12 15:05:24 2015 From: rafael at gav.ufsc.br (Rafael Possamai) Date: Tue, 12 May 2015 10:05:24 -0500 Subject: Rasberry pi - high density In-Reply-To: References: <3add94118911fb463b174ab24631657b@thefnf.org> <555121BF.4040708@mtcc.com> <20150511222419.GC26580@bamboo.slabnet.com> Message-ID: Here's someone's comparison between the B and B+ in terms of power: http://raspi.tv/2014/how-much-less-power-does-the-raspberry-pi-b-use-than-the-old-model-b On Mon, May 11, 2015 at 10:25 PM, Joel Maslak wrote: > Rather then guessing on power consumption, I measured it. > > I took a Pi (Model B - but I suspect B+ and the new version is relatively > similar in power draw with the same peripherials), hooked it up to a lab > power supply, and took a current measurement. My pi has a Sandisk SD card > and a Sandisk USB stick plugged into it, so, if anything, it will be a bit > high in power draw. I then fired off a tight code loop and a ping -f from > another host towards it, to busy up the processor and the network/USB on > the Pi. I don't have a way of making the video do anything, so if you were > using that, your draw would be up. I also measured idle usage (sitting at > a command prompt). > > Power draw was 2.3W under load, 2.0W at idle. > > If it was my project, I'd build a backplane board with USB-to-ethernet and > ethernet switch chips, along with sockets for Pi compute modules (or > something similar). I'd want one power cable and one network cable per > backplane board if my requirements allowed it. Stick it all in a nice card > cage and you're done. > > As for performance per watt, I'd be surprised if this beat a modern video > processor for the right workload. > > > On Mon, May 11, 2015 at 5:16 PM, Rafael Possamai > wrote: > > > Maybe I messed up the math in my head, my line of thought was one pi is > > estimated to use 1.2 watts, whereas the nuc is at around 65 watts. 10 > pi's > > = 12 watts. My comparison was 65watts/12watts = 5.4 times more power than > > 10 pi's put together. This is really a rough estimate because I got the > > NUC's power consumption from the AC/DC converter that comes with it, > which > > has a maximum output of 65 watts. I could be wrong (up to 5 times) and > > still the pi would use less power. > > > > Now that I think about it, the best way to simplify this is to calculate > > benchmark points per watt, so rasp pi is at around 406/1.2 which equals > > 338. The NUC, roughly estimated to be at 3857/65 which equals 60. Let's > be > > very skeptical and say that at maximum consumption the pi is using 5 > watts, > > then 406/5 is around 81. At this point the rasp pi still scores better. > > > > Only problem we are comparing ARM to x86 which isn't necessarily fair (i > am > > not an expert in computer architectures) > > > > > > > > > > > > On Mon, May 11, 2015 at 5:24 PM, Hugo Slabbert wrote: > > > > > Did I miss anything? Just a quick comparison. > > >> > > > > > > If those numbers are accurate, then it leans towards the NUC rather > than > > > the Pi, no? > > > > > > Perf: 1x i5 NUC = 10x Pi > > > $$: 1x i5 NUC = 10x Pi > > > Power: 1x i5 NUC = 5x Pi > > > > > > So...if a single NUC gives you the performance of 10x Pis at the > capital > > > cost of 10x Pis but uses half the power of 10x Pis and only a single > > > Ethernet port, how does the Pi win? > > > > > > -- > > > Hugo > > > > > > > > > On Mon 2015-May-11 17:08:43 -0500, Rafael Possamai > > > > wrote: > > > > > > Interesting! Knowing a pi costs approximately $35, then you need > > >> approximately $350 to get near an i5.. The smallest and cheapest > desktop > > >> you can get that would have similar power is the Intel NUC with an i5 > > that > > >> goes for approximately $350. Power consumption of a NUC is about 5x > that > > >> of > > >> the raspberry pi, but the number of ethernet ports required is 10x > less. > > >> Usually in a datacenter you care much more about power than switch > > ports, > > >> so in this case if the overhead of controlling 10x the number of nodes > > is > > >> worth it, I'd still consider the raspberry pi. Did I miss anything? > > Just a > > >> quick comparison. > > >> > > >> > > >> > > >> On Mon, May 11, 2015 at 4:40 PM, Michael Thomas > wrote: > > >> > > >> As it turns out, I've been playing around benchmarking things lately > > >>> using > > >>> the tried and true > > >>> UnixBench suite and here are a few numbers that might put this in > some > > >>> perspective: > > >>> > > >>> 1) My new Rapsberry pi (4 cores, arm): 406 > > >>> 2) My home i5-like thing (asus 4 cores, 16gb's from last year): 3857 > > >>> 3) AWS c4.xlarge (4 cores, ~8gb's): 3666 > > >>> > > >>> So you'd need to, uh, wedge about 10 pi's to get one half way modern > > x86. > > >>> > > >>> Mike > > >>> > > >>> > > >>> On 5/11/15 1:37 PM, Clay Fiske wrote: > > >>> > > >>> On May 8, 2015, at 10:24 PM, charles at thefnf.org wrote: > > >>>> > > >>>>> > > >>>>> Pi dimensions: > > >>>>> > > >>>>> 3.37 l (5 front to back) > > >>>>> 2.21 w (6 wide) > > >>>>> 0.83 h > > >>>>> 25 per U (rounding down for Ethernet cable space etc) = 825 pi > > >>>>> > > >>>>> Cable management and heat would probably kill this before it ever > > >>>>> reached completion, but lol? > > >>>>> > > >>>>> > > >>>> This feels like it should be a Friday thread. :) > > >>>> > > >>>> If you?re really going for density: > > >>>> > > >>>> - At 0.83 inches high you could go 2x per U (depends on your > mounting > > >>>> system and how much space it burns) > > >>>> - I?d expect you could get at least 7 wide if not 8 with the right > > >>>> micro-USB power connector > > >>>> - In most datacenter racks I?ve seen you could get at least 8 deep > > even > > >>>> with cable breathing room > > >>>> > > >>>> So somewhere between 7x8x2 = 112 and 8x8x2 = 128 per U. And if you > get > > >>>> truly creative about how you stack them you could probably beat that > > >>>> without too much effort. > > >>>> > > >>>> This doesn?t solve for cooling, but I think even at these numbers > you > > >>>> could probably make it work with nice, tight cabling. > > >>>> > > >>>> > > >>>> -c > > >>>> > > >>>> > > >>>> > > >>>> > > >>> > > > From jordan-medlen at bisk.com Tue May 12 15:07:55 2015 From: jordan-medlen at bisk.com (Jordan Medlen) Date: Tue, 12 May 2015 15:07:55 +0000 Subject: Recommended 10GE ISCSI SAN switch In-Reply-To: <555201CB.7060900@winterei.se> References: <555201CB.7060900@winterei.se> Message-ID: <4861E1CF94656C46BBE7DD50DA619F8C3AACDB@TPA-MBX-001.qwest.corp.bisk.com> I am using Brocade VDX 6740 switches that support dcbx. They work very well and have had no issues in nearly two years with them. Thank you, Jordan Medlen Network Engineer Bisk Education, Inc. -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Paul S. Sent: Tuesday, May 12, 2015 9:36 AM To: nanog at nanog.org Subject: Recommended 10GE ISCSI SAN switch Hi guys, We're shortly going to be getting some 10G SANs, and I was wondering what people were using as SAN switches for 10G SANs. It is my understanding that low buffer sizes make most 'normal' 10G ethernet switches unsuitable for the job. We're pretty much an exclusive Juniper shop, but are not biased in any way -- best tool for the job is what I've been tasked with to find. Keeping that in mind, how would something like a EX4550 fare in the role? Are there better devices in the same price range? Thanks! From srchlm at its.cz Tue May 12 15:25:52 2015 From: srchlm at its.cz (Lumir Srchlm) Date: Tue, 12 May 2015 17:25:52 +0200 Subject: Recommended 10GE ISCSI SAN switch In-Reply-To: <555201CB.7060900@winterei.se> References: <555201CB.7060900@winterei.se> Message-ID: We use IBM / Lenovo switches for such traffic. Very low latency, rear to front or front to rear airflow models, large buffers, FCoE, OpenFlow support, great price-performance... G8124E or G8272 may be the right models, use DAC cables instead of SFP+ if possible. Lumir From: "Paul S." To: "nanog at nanog.org" Date: 12.05.2015 15:39 Subject: Recommended 10GE ISCSI SAN switch Sent by: "NANOG" Hi guys, We're shortly going to be getting some 10G SANs, and I was wondering what people were using as SAN switches for 10G SANs. It is my understanding that low buffer sizes make most 'normal' 10G ethernet switches unsuitable for the job. We're pretty much an exclusive Juniper shop, but are not biased in any way -- best tool for the job is what I've been tasked with to find. Keeping that in mind, how would something like a EX4550 fare in the role? Are there better devices in the same price range? Thanks! Obsah t?to zpr?vy, stejn? jako obsah souvisej?c? osobn? a telefonick? komunikace z?stupc? a zam?stnanc? spole?nosti ITS slou?? v?lu?n? jako prost?edek k v?m?n? informac? a, nen?-li to v nich v?slovn? uvedeno, nejsou pr?vn?m jedn?n?m zakl?daj?c?m z?vaznou nab?dku, vznik, zm?nu nebo z?nik pr?v ?i pr?vn?ch n?sledk? anebo jedn?n?m sm??uj?c?m bezprost?edn? k uzav?en? smlouvy a spole?nost ITS nenese jakoukoliv odpov?dnost za d?sledky ?i ?jmu vzniklou neuzav?en?m smlouvy. From rcarpen at network1.net Tue May 12 15:42:26 2015 From: rcarpen at network1.net (Randy Carpenter) Date: Tue, 12 May 2015 11:42:26 -0400 (EDT) Subject: Recommended 10GE ISCSI SAN switch In-Reply-To: <555201CB.7060900@winterei.se> References: <555201CB.7060900@winterei.se> Message-ID: <1151480196.1110114.1431445346788.JavaMail.zimbra@network1.net> ----- On May 12, 2015, at 9:36 AM, Paul S. contact at winterei.se wrote: > Hi guys, > > We're shortly going to be getting some 10G SANs, and I was wondering > what people were using as SAN switches for 10G SANs. > > It is my understanding that low buffer sizes make most 'normal' 10G > ethernet switches unsuitable for the job. > > We're pretty much an exclusive Juniper shop, but are not biased in any > way -- best tool for the job is what I've been tasked with to find. > > Keeping that in mind, how would something like a EX4550 fare in the > role? Are there better devices in the same price range? > > Thanks! Unless you need the old VC connections, you might consider the newer EX4600, which is 40x10GbE and 4x40GbE (versus 32x10GbE), at around the same price point. The 40GbE ports are used for stacking, so you don't have to add a VC card. The newer platforms are going to get better long term software support, as well. -Randy From bzs at world.std.com Tue May 12 16:44:57 2015 From: bzs at world.std.com (Barry Shein) Date: Tue, 12 May 2015 12:44:57 -0400 Subject: Rasberry pi - high density In-Reply-To: <20150511222419.GC26580@bamboo.slabnet.com> References: <3add94118911fb463b174ab24631657b@thefnf.org> <555121BF.4040708@mtcc.com> <20150511222419.GC26580@bamboo.slabnet.com> Message-ID: <21842.11785.596624.80051@world.std.com> To some extent people are comparing apples (not TM) and oranges. Are you trying to maximize the number of total cores or the number of total computes? They're not the same. It depends on the job mix you expect. For example a map-reduce kind of problem, search of a massive database, probably is improved with lots of cores even if each core isn't that fast. You partition a database across thousands of cores and broadcast "who has XYZ?" and wait for an answer, in short. There are a lot of problems like that, and a lot of problems which cannot be improved by lots of cores. For example if you have to wait for one answer before you can compute the next (matrix inversion is notorious for this property and very important.) You just can't keep the "pipeline" filled. And then there are the relatively inexpensive GPUs which can do many floating point ops in parallel and are good at certain jobs like, um, graphics! rendering, ray-tracing, etc. But they're not very good at general purpose integer ops like string searching, as a general rule, or problems which can't be decomposed to take advantage of the parallelism. You've got your work cut out for you analyzing these things! -- -Barry Shein The World | bzs at TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: 800-THE-WRLD | Dial-Up: US, PR, Canada Software Tool & Die | Public Access Internet | SINCE 1989 *oo* From plam at fuelyouth.com Tue May 12 16:07:07 2015 From: plam at fuelyouth.com (Paul Lam) Date: Tue, 12 May 2015 16:07:07 +0000 Subject: Seeing odd behaviour loading site over AT&T Message-ID: Hello all, Wondering if anyone has encountered an issue where a website will load over https, but will only partially load over http using the same WAN connection. We are currently experiencing this behavior loading up a website hosted in AWS over an AT&T Flex reach service in So Cal. fuel YOUTH ENGAGEMENT Paul Lam | Network Administrator T: +1(613) 224-6738 x257 | M: www.fuelyouth.com From michael at supermathie.net Wed May 13 00:09:23 2015 From: michael at supermathie.net (Michael Brown) Date: Tue, 12 May 2015 20:09:23 -0400 Subject: Seeing odd behaviour loading site over AT&T In-Reply-To: References: Message-ID: <20150513000923.6131797.60074.5604@supermathie.net> Yes - is this "flex reach" wireless/4G? I've observed past behaviour of image and page content "optimization" ?(i.e. minifying, recompression) that causes problems for a site over this type of connection when using plaintext. M. ? Original Message ? From: Paul Lam Sent: Tuesday, May 12, 2015 19:44 To: nanog at nanog.org Subject: Seeing odd behaviour loading site over AT&T Hello all, Wondering if anyone has encountered an issue where a website will load over https, but will only partially load over http using the same WAN connection. We are currently experiencing this behavior loading up a website hosted in AWS over an AT&T Flex reach service in So Cal. fuel YOUTH ENGAGEMENT Paul Lam | Network Administrator T: +1(613) 224-6738 x257 | M: www.fuelyouth.com From plam at fuelyouth.com Wed May 13 00:18:31 2015 From: plam at fuelyouth.com (Paul Lam) Date: Wed, 13 May 2015 00:18:31 +0000 Subject: Seeing odd behaviour loading site over AT&T In-Reply-To: <20150513000923.6131797.60074.5604@supermathie.net> References: , <20150513000923.6131797.60074.5604@supermathie.net> Message-ID: <8167E4EA-92CC-4873-B734-F244B2A4FF43@fuelyouth.com> Sorry I must have mixed up AT&T terms. We have a 20Mbit symmetric circuit that's also serves up VoIP. Not sure what AT&T calls it. Sent from my iPhone > On May 12, 2015, at 8:09 PM, Michael Brown wrote: > > Yes - is this "flex reach" wireless/4G? > > I've observed past behaviour of image and page content "optimization" ?(i.e. minifying, recompression) that causes problems for a site over this type of connection when using plaintext. > > M. > > Original Message > From: Paul Lam > Sent: Tuesday, May 12, 2015 19:44 > To: nanog at nanog.org > Subject: Seeing odd behaviour loading site over AT&T > > Hello all, > > Wondering if anyone has encountered an issue where a website will load over https, but will only partially load over http using the same WAN connection. We are currently experiencing this behavior loading up a website hosted in AWS over an AT&T Flex reach service in So Cal. > > fuel > YOUTH ENGAGEMENT > > Paul Lam | Network Administrator > T: +1(613) 224-6738 x257 | M: > www.fuelyouth.com From jared at puck.Nether.net Wed May 13 01:17:00 2015 From: jared at puck.Nether.net (Jared Mauch) Date: Tue, 12 May 2015 21:17:00 -0400 Subject: Seeing odd behaviour loading site over AT&T In-Reply-To: <20150513000923.6131797.60074.5604@supermathie.net> References: <20150513000923.6131797.60074.5604@supermathie.net> Message-ID: <20150513011700.GA11752@puck.nether.net> On Tue, May 12, 2015 at 08:09:23PM -0400, Michael Brown wrote: > Yes - is this "flex reach" wireless/4G? > > I've observed past behaviour of image and page content "optimization" ?(i.e. minifying, recompression) that causes problems for a site over this type of connection when using plaintext. I've seen similar issues with the AT&T wireless network assuming a web service on port 8080 is the same as the service on port 80. That issue seems to be regional in nature as when I left northern california it stopped happening. This was 2 weeks ago. - Jared > > M. > > ? Original Message ? > From: Paul Lam > Sent: Tuesday, May 12, 2015 19:44 > To: nanog at nanog.org > Subject: Seeing odd behaviour loading site over AT&T > > Hello all, > > Wondering if anyone has encountered an issue where a website will load over https, but will only partially load over http using the same WAN connection. We are currently experiencing this behavior loading up a website hosted in AWS over an AT&T Flex reach service in So Cal. > > fuel > YOUTH ENGAGEMENT > > Paul Lam | Network Administrator > T: +1(613) 224-6738 x257 | M: > www.fuelyouth.com -- 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 mtaylor at mty.net.au Wed May 13 01:35:54 2015 From: mtaylor at mty.net.au (Matt Taylor) Date: Wed, 13 May 2015 11:35:54 +1000 Subject: Recommended 10GE ISCSI SAN switch In-Reply-To: <555201CB.7060900@winterei.se> References: <555201CB.7060900@winterei.se> Message-ID: <5552AA7A.2070902@mty.net.au> We've been using Dell 8024F's for over 2 years now. No problems at all. On 12/05/2015 23:36, Paul S. wrote: > Hi guys, > > We're shortly going to be getting some 10G SANs, and I was wondering > what people were using as SAN switches for 10G SANs. > > It is my understanding that low buffer sizes make most 'normal' 10G > ethernet switches unsuitable for the job. > > We're pretty much an exclusive Juniper shop, but are not biased in any > way -- best tool for the job is what I've been tasked with to find. > > Keeping that in mind, how would something like a EX4550 fare in the > role? Are there better devices in the same price range? > > Thanks! From skhosla at neutraldata.com Wed May 13 14:27:11 2015 From: skhosla at neutraldata.com (Sameer Khosla) Date: Wed, 13 May 2015 14:27:11 +0000 Subject: Recommended 10GE ISCSI SAN switch In-Reply-To: <5552AA7A.2070902@mty.net.au> References: <555201CB.7060900@winterei.se> <5552AA7A.2070902@mty.net.au> Message-ID: <49A81EB09F493442B6D259E36251192C01719BC6F2@ndcc-exch1.neutraldata.com> If price is a major concern, take a look at the Force10 S2410. They tend to go for under $2k on ebay. Very basic L2 cut-through low-latency switch. Only drawback is your choice is XFP or CX4 for ports, but if you have server nics with CX4 then you are off the races for very little money. Whatever switch you use, don't forget to adjust MTU to 9k+. +1 for SSD based storage, if you are using a vmware environment the newer versions of vsan support all-flash-arrays, worth taking a look at. Sk. -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Matt Taylor Sent: Tuesday, May 12, 2015 9:36 PM To: nanog at nanog.org Subject: Re: Recommended 10GE ISCSI SAN switch We've been using Dell 8024F's for over 2 years now. No problems at all. On 12/05/2015 23:36, Paul S. wrote: > Hi guys, > > We're shortly going to be getting some 10G SANs, and I was wondering > what people were using as SAN switches for 10G SANs. > > It is my understanding that low buffer sizes make most 'normal' 10G > ethernet switches unsuitable for the job. > > We're pretty much an exclusive Juniper shop, but are not biased in any > way -- best tool for the job is what I've been tasked with to find. > > Keeping that in mind, how would something like a EX4550 fare in the > role? Are there better devices in the same price range? > > Thanks! From chris at aperturefiber.com Wed May 13 18:10:30 2015 From: chris at aperturefiber.com (Chris Garrett) Date: Wed, 13 May 2015 14:10:30 -0400 Subject: Network Solutions blacklisted mail Message-ID: Has anyone had any luck in getting a clued individual from NS to contact them concerning blacklist removal? I am going on four days and still spinning my wheels despite multiple contacts claiming it would be handled. From chuckchurch at gmail.com Wed May 13 19:33:17 2015 From: chuckchurch at gmail.com (Chuck Church) Date: Wed, 13 May 2015 15:33:17 -0400 Subject: Akamai minimum prefix length issue Message-ID: <015701d08db3$ab4fcae0$01ef60a0$@gmail.com> Anyone from Akamai (or who might know), Having an issue with AS 20940 either not seeing or ignoring a /23 we're announcing, and following a /22 to another path. Other ISPs our upstream peers with see the /23. I didn't see a looking glass for Akamai to verify. Anyone from Akamai able to help? Prefix in question is 162.220.232.0/23. Thanks, Chuck From patrick at ianai.net Wed May 13 19:37:08 2015 From: patrick at ianai.net (Patrick W. Gilmore) Date: Wed, 13 May 2015 15:37:08 -0400 Subject: Akamai minimum prefix length issue In-Reply-To: <015701d08db3$ab4fcae0$01ef60a0$@gmail.com> References: <015701d08db3$ab4fcae0$01ef60a0$@gmail.com> Message-ID: <7948BDB7-C04C-4D3B-A7E5-B59EDCC9F391@ianai.net> Akamai does not follow BGP perfectly, for many reasons, including BGP preferring crappy paths much of the time. ISPs should email NetSupport-tix at akamai.com to get help with traffic engineering, performance, and other questions. (Or at least that used to be the case a year ago.) -- TTFN, patrick > On May 13, 2015, at 15:33 , Chuck Church wrote: > > Anyone from Akamai (or who might know), > > Having an issue with AS 20940 either not seeing or ignoring a /23 > we're announcing, and following a /22 to another path. Other ISPs our > upstream peers with see the /23. I didn't see a looking glass for Akamai to > verify. Anyone from Akamai able to help? Prefix in question is > 162.220.232.0/23. > > Thanks, > > Chuck > > > From jake at nobistech.net Wed May 13 19:42:22 2015 From: jake at nobistech.net (Jake Mertel) Date: Wed, 13 May 2015 12:42:22 -0700 Subject: Akamai minimum prefix length issue In-Reply-To: <015701d08db3$ab4fcae0$01ef60a0$@gmail.com> References: <015701d08db3$ab4fcae0$01ef60a0$@gmail.com> Message-ID: Chuck, Just throwing this out there as a possibility, I've seen similar issues with other ISPs wherein the root cause was their BGP speaking routers using a filter set published by (I'm almost certain) Cisco that, among other things, blocks announcements of any prefix that is smaller then the minimum prefix size allocated from an RIR for the prefix in question. If you look at https://www.arin.net/knowledge/ip_blocks.html you will see that they now say "All prefixes have the potential to have a /24 minimum size allocation issued from them.", but this was not always the case. For example, looking at the archive.org copy of that page from https://web.archive.org/web/20140107021136/https://www.arin.net/knowledge/ip_blocks.html on January 7, 2014, the smallest prefix they allocated from 162/8 was a /22. I did some quick google'ing but was unable to find a copy of the filter set in question. I poked a few of my colleagues and will let you know if I'm able to find a copy for reference. --Jake On Wed, May 13, 2015 at 12:33 PM, Chuck Church wrote: > Anyone from Akamai (or who might know), > > Having an issue with AS 20940 either not seeing or ignoring a /23 > we're announcing, and following a /22 to another path. Other ISPs our > upstream peers with see the /23. I didn't see a looking glass for Akamai > to > verify. Anyone from Akamai able to help? Prefix in question is > 162.220.232.0/23. > > Thanks, > > Chuck > > > > > From patrick at ianai.net Wed May 13 19:43:32 2015 From: patrick at ianai.net (Patrick W. Gilmore) Date: Wed, 13 May 2015 15:43:32 -0400 Subject: Akamai minimum prefix length issue In-Reply-To: References: <015701d08db3$ab4fcae0$01ef60a0$@gmail.com> Message-ID: Akamai does not do this. -- TTFN, patrick > On May 13, 2015, at 15:42 , Jake Mertel wrote: > > Chuck, > > Just throwing this out there as a possibility, I've seen similar issues > with other ISPs wherein the root cause was their BGP speaking routers using > a filter set published by (I'm almost certain) Cisco that, among other > things, blocks announcements of any prefix that is smaller then the minimum > prefix size allocated from an RIR for the prefix in question. If you look > at https://www.arin.net/knowledge/ip_blocks.html you will see that they now > say "All prefixes have the potential to have a /24 minimum size allocation > issued from them.", but this was not always the case. For example, looking > at the archive.org copy of that page from > https://web.archive.org/web/20140107021136/https://www.arin.net/knowledge/ip_blocks.html > on January 7, 2014, the smallest prefix they allocated from 162/8 was a > /22. I did some quick google'ing but was unable to find a copy of the > filter set in question. I poked a few of my colleagues and will let you > know if I'm able to find a copy for reference. > > --Jake > > On Wed, May 13, 2015 at 12:33 PM, Chuck Church > wrote: > >> Anyone from Akamai (or who might know), >> >> Having an issue with AS 20940 either not seeing or ignoring a /23 >> we're announcing, and following a /22 to another path. Other ISPs our >> upstream peers with see the /23. I didn't see a looking glass for Akamai >> to >> verify. Anyone from Akamai able to help? Prefix in question is >> 162.220.232.0/23. >> >> Thanks, >> >> Chuck >> >> >> >> >> From lowen at pari.edu Wed May 13 20:59:37 2015 From: lowen at pari.edu (Lamar Owen) Date: Wed, 13 May 2015 16:59:37 -0400 Subject: Rasberry pi - high density In-Reply-To: <55513253.1030401@monmotha.net> References: <3add94118911fb463b174ab24631657b@thefnf.org> Message-ID: <5553BB39.9050306@pari.edu> On 05/11/2015 06:50 PM, Brandon Martin wrote: > > 8kW/rack is something it seems many a typical computing oriented > datacenter would be used to dealing with, no? Formfactor within the > rack is just a little different which may complicate how you can > deliver the cooling - might need unusually forceful forced air or a > water/oil type heat exchanger for the oil immersion method being > discussed elsewhere in the thread. > > You still need giant wires and busses to move 800A worth of current. ... This thread brings me back to 1985, what with talk of full immersion cooling (Fluorinert, anyone?) and hundreds of amps at 5VDC.... reminds me of the Cray-2, which dropped 150-200KW in 6 rack location units of space; 2 for the CPU itself, 2 for space, and 2 for the cooling waterfall [ https://en.wikipedia.org/wiki/File:Cray2.jpeg by referencing floor tile space occupied and taking 16 sq ft (four tiles) as one RLU ]. Each 'stack' of the CPU pulled 2,200A at 5V [source: https://en.wikipedia.org/wiki/Cray-2#History ]. At those currents you use busbar, not wire. Our low-voltage (120/208V three-phase) switchgear here uses 6,000A rated busbar, so it's readily available, if expensive. From hannigan at gmail.com Wed May 13 22:32:49 2015 From: hannigan at gmail.com (Martin Hannigan) Date: Wed, 13 May 2015 18:32:49 -0400 Subject: Akamai minimum prefix length issue In-Reply-To: <7948BDB7-C04C-4D3B-A7E5-B59EDCC9F391@ianai.net> References: <015701d08db3$ab4fcae0$01ef60a0$@gmail.com> <7948BDB7-C04C-4D3B-A7E5-B59EDCC9F391@ianai.net> Message-ID: Hi Patrick, Correct answer. No surprise. And yes, netsupport-tix at akamai.com is still the way to go for these types of issues. Thanks for the help! Best, -M< // AS 20940 On Wed, May 13, 2015 at 3:37 PM, Patrick W. Gilmore wrote: > Akamai does not follow BGP perfectly, for many reasons, including BGP > preferring crappy paths much of the time. > > ISPs should email NetSupport-tix at akamai.com to get help with traffic > engineering, performance, and other questions. (Or at least that used to be > the case a year ago.) > > -- > TTFN, > patrick > > > On May 13, 2015, at 15:33 , Chuck Church wrote: > > > > Anyone from Akamai (or who might know), > > > > Having an issue with AS 20940 either not seeing or ignoring a /23 > > we're announcing, and following a /22 to another path. Other ISPs our > > upstream peers with see the /23. I didn't see a looking glass for > Akamai to > > verify. Anyone from Akamai able to help? Prefix in question is > > 162.220.232.0/23. > > > > Thanks, > > > > Chuck > > > > > > > > From rdrake at direcpath.com Tue May 12 15:19:06 2015 From: rdrake at direcpath.com (Robert Drake) Date: Tue, 12 May 2015 11:19:06 -0400 Subject: Is anyone working on an RFC for standardized maintenance notifications Message-ID: <555219EA.1080004@direcpath.com> Like the "Automated Copyright Notice System" (http://www.acns.net/spec.html) except I don't think they went through any official standards body besides their own MPAA, or whatever. I get circuits from several vendors and get maintenance notifications from them all the time. Each has a different format and each supplies different details for their maintenance. Most of the time there are core things that everyone wants and it would be nice if it were automatically readable so automation could be performed (i.e., our NOC gets the email into our ticketing system. It is recognized as being part of an existing maintenance due to maintenance id# (or new, whatever) and fields are automatically populated or updated accordingly. If you're uncomfortable with the phrase "automatically populated accordingly" for security reasons then you can replace that with "NOC technician verifies all fields are correct and hits update ticket." or whatever. The main fields I think you would need: 1. Company Name 2. Maintenance ID 3. Start Date 4. Expected length 5. Circuits impacted (if known or applicable) 6. Description/Scope of Work (free form) 7. Ticket Number 8. Contact From erik.klavon at gmail.com Thu May 14 05:23:10 2015 From: erik.klavon at gmail.com (Erik Klavon) Date: Wed, 13 May 2015 22:23:10 -0700 Subject: Is anyone working on an RFC for standardized maintenance notifications In-Reply-To: <555219EA.1080004@direcpath.com> References: <555219EA.1080004@direcpath.com> Message-ID: Hi Robert, I'm not aware of an RFC for standardized maintenance notifications. A group of people are currently working on a NANOG BCOP for maintenance notifications. Many of the fields you list match those we've identified as critical for inclusion in any maintenance notification. Most of the discussion takes place via a group on Facebook: https://www.facebook.com/groups/855738444449323/ We also have bi-weekly conference calls. If you (or anyone else) are interested in participating, contact me off list and I'll get you caught up on our work so far. Erik On Tue, May 12, 2015 at 8:19 AM, Robert Drake wrote: > Like the "Automated Copyright Notice System" (http://www.acns.net/spec.html) > except I don't think they went through any official standards body besides > their own MPAA, or whatever. > > I get circuits from several vendors and get maintenance notifications from > them all the time. Each has a different format and each supplies different > details for their maintenance. Most of the time there are core things that > everyone wants and it would be nice if it were automatically readable so > automation could be performed (i.e., our NOC gets the email into our > ticketing system. It is recognized as being part of an existing maintenance > due to maintenance id# (or new, whatever) and fields are automatically > populated or updated accordingly. > > If you're uncomfortable with the phrase "automatically populated > accordingly" for security reasons then you can replace that with "NOC > technician verifies all fields are correct and hits update ticket." or > whatever. > > The main fields I think you would need: > > 1. Company Name > 2. Maintenance ID > 3. Start Date > 4. Expected length > 5. Circuits impacted (if known or applicable) > 6. Description/Scope of Work (free form) > 7. Ticket Number > 8. Contact > From woody at pch.net Thu May 14 11:53:40 2015 From: woody at pch.net (Bill Woodcock) Date: Thu, 14 May 2015 13:53:40 +0200 Subject: Is anyone working on an RFC for standardized maintenance notifications In-Reply-To: <555219EA.1080004@direcpath.com> References: <555219EA.1080004@direcpath.com> Message-ID: <0313728D-24A5-4AA0-A353-4F776A731990@pch.net> Whoo... Yeah, we had a WG on that, back around 2000 or so... The determination was, as I recall, that it didn't need to be part of SNMP, but it kind of went off the rails in an all-things-to-all-people sort of way. But my memory is vague. Erik Guttman might remember more clearly. Anyway, the idea is a good one, and if you can keep it constrained to a reasonable scope, I think you should find good support. -Bill > On May 14, 2015, at 06:10, Robert Drake wrote: > > Like the "Automated Copyright Notice System" (http://www.acns.net/spec.html) except I don't think they went through any official standards body besides their own MPAA, or whatever. > > I get circuits from several vendors and get maintenance notifications from them all the time. Each has a different format and each supplies different details for their maintenance. Most of the time there are core things that everyone wants and it would be nice if it were automatically readable so automation could be performed (i.e., our NOC gets the email into our ticketing system. It is recognized as being part of an existing maintenance due to maintenance id# (or new, whatever) and fields are automatically populated or updated accordingly. > > If you're uncomfortable with the phrase "automatically populated accordingly" for security reasons then you can replace that with "NOC technician verifies all fields are correct and hits update ticket." or whatever. > > The main fields I think you would need: > > 1. Company Name > 2. Maintenance ID > 3. Start Date > 4. Expected length > 5. Circuits impacted (if known or applicable) > 6. Description/Scope of Work (free form) > 7. Ticket Number > 8. Contact > From nanog at cdl.asgaard.org Thu May 14 00:42:06 2015 From: nanog at cdl.asgaard.org (nanog at cdl.asgaard.org) Date: Wed, 13 May 2015 17:42:06 -0700 Subject: [eX-bulk] : Re: Rasberry pi - high density In-Reply-To: References: <3add94118911fb463b174ab24631657b@thefnf.org> <21838.22583.909425.654573@world.std.com> Message-ID: <08E3425E-C495-43BA-A3FA-52A6CECBF76C@cdl.asgaard.org> Greetings, Do we really need them to be swappable at that point? The reason we swap HDD's (if we do) is because they are rotational, and mechanical things break. Do we swap CPUs and memory hot? Do we even replace memory on a server that's gone bad, or just pull the whole thing during the periodic "dead body collection" and replace it? Might it not be more efficient (and space saving) to just add 20% more storage to a server than the design goal, and let the software use the extra space to keep running when an SSD fails? When the overall storage falls below tolerance, the unit is dead. I think we will soon need to (if we aren't already) stop thinking about individual components as FRUs. The server (or rack, or container) is the FRU. Christopher On 9 May 2015, at 12:26, Eugeniu Patrascu wrote: > On Sat, May 9, 2015 at 9:55 PM, Barry Shein wrote: > >> >> On May 9, 2015 at 00:24 charles at thefnf.org (charles at thefnf.org) >> wrote: >>> >>> >>> So I just crunched the numbers. How many pies could I cram in a >>> rack? >> >> For another list I just estimated how many M.2 SSD modules one could >> cram into a 3.5" disk case. Around 40 w/ some room to spare (assuming >> heat and connection routing aren't problems), at 500GB/each that's >> 20TB in a standard 3.5" case. >> >> It's getting weird out there. >> >> > I think the next logical step in servers would be to remove the > traditional > hard drive cages and put SSD module slots that can be hot swapped. > Imagine > inserting small SSD modules on the front side of the servers and > directly > connect them via PCIe to the motherboard. No more bottlenecks and a > software RAID of some sorts would actually make a lot more sense than > the > current controller based solutions. -- ??? Avt tace, avt loqvere meliora silentio Check my PGP key here: http://www.asgaard.org/cdl/cdl.asc Current vCard here: http://www.asgaard.org/cdl/cdl.vcf keybase: https://keybase.io/liljenstolpe From charles at thefnf.org Thu May 14 18:28:41 2015 From: charles at thefnf.org (charles at thefnf.org) Date: Thu, 14 May 2015 13:28:41 -0500 Subject: [eX-bulk] : Re: Rasberry pi - high density In-Reply-To: <08E3425E-C495-43BA-A3FA-52A6CECBF76C@cdl.asgaard.org> References: <3add94118911fb463b174ab24631657b@thefnf.org> <21838.22583.909425.654573@world.std.com> <08E3425E-C495-43BA-A3FA-52A6CECBF76C@cdl.asgaard.org> Message-ID: <4ac92d6d2a1329e4ad30179aa68c089d@thefnf.org> On 2015-05-13 19:42, nanog at cdl.asgaard.org wrote: > Greetings, > > Do we really need them to be swappable at that point? The reason we > swap HDD's (if we do) is because they are rotational, and mechanical > things break. Right. > Do we swap CPUs and memory hot? Nope. Usually just toss the whole thing. Well I keep spare ram around cause it's so cheap. But if CPU goes, chuck it in the ewaste pile in the back. Do we even replace > memory on a server that's gone bad, or just pull the whole thing > during the periodic "dead body collection" and replace it? Usually swap memory. But yeah, often times the hardware ops folks just cull old boxes on a quarterly basis and backfill with the latest batch of inbound kit. At large scale (which many on this list operate at), you have pallets of gear sitting in the to deploy queue, and another couple pallets worth racked up but not even imaged yet. (This is all supposition of course. I'm used to working with $HUNDREDS of racks worth of gear). Containers, moonshot type things etc are certainly on the radar. Might it > not be more efficient (and space saving) to just add 20% more storage > to a server than the design goal, and let the software use the extra > space to keep running when an SSD fails? Yes. Also a few months ago I read an article about several SSD brands having $MANY terabytes written to them. Can't find it just now. But they seem to take quite a long time (data wise/number of write wise) to fail. When the overall storage > falls below tolerance, the unit is dead. I think we will soon need to > (if we aren't already) stop thinking about individual components as > FRUs. The server (or rack, or container) is the FRU. > > Christopher Yes. Agree. Most of the very large scale shops (the ones I've worked at) are massively horizontal scaled, cookie cutter. Many boxes replicating/extending/expanding a set of well defined workloads. From nanog at ics-il.net Fri May 15 15:19:56 2015 From: nanog at ics-il.net (Mike Hammett) Date: Fri, 15 May 2015 10:19:56 -0500 (CDT) Subject: Route Optimization Products Message-ID: <281829361.425437.1431703196407.JavaMail.root@mailbox1.ics-il.net> What is out there for route optimization products? I can think of Noction (no inbound) or Internap FCP (old). ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest Internet Exchange http://www.midwest-ix.com From youssef at 720.fr Fri May 15 15:25:45 2015 From: youssef at 720.fr (Youssef Bengelloun-Zahr) Date: Fri, 15 May 2015 17:25:45 +0200 Subject: Route Optimization Products In-Reply-To: <281829361.425437.1431703196407.JavaMail.root@mailbox1.ics-il.net> References: <281829361.425437.1431703196407.JavaMail.root@mailbox1.ics-il.net> Message-ID: Border6 NSI. Best regards. > Le 15 mai 2015 ? 17:19, Mike Hammett a ?crit : > > What is out there for route optimization products? I can think of Noction (no inbound) or Internap FCP (old). > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > > > Midwest Internet Exchange > http://www.midwest-ix.com > From rafael at gav.ufsc.br Fri May 15 15:27:27 2015 From: rafael at gav.ufsc.br (Rafael Possamai) Date: Fri, 15 May 2015 10:27:27 -0500 Subject: Route Optimization Products In-Reply-To: <281829361.425437.1431703196407.JavaMail.root@mailbox1.ics-il.net> References: <281829361.425437.1431703196407.JavaMail.root@mailbox1.ics-il.net> Message-ID: Internap also has a product called MIRO, although I am not sure how it differs from FCP. On Fri, May 15, 2015 at 10:19 AM, Mike Hammett wrote: > What is out there for route optimization products? I can think of Noction > (no inbound) or Internap FCP (old). > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > > > Midwest Internet Exchange > http://www.midwest-ix.com > > From pavel.odintsov at gmail.com Fri May 15 15:34:48 2015 From: pavel.odintsov at gmail.com (Pavel Odintsov) Date: Fri, 15 May 2015 18:34:48 +0300 Subject: Route Optimization Products In-Reply-To: References: <281829361.425437.1431703196407.JavaMail.root@mailbox1.ics-il.net> Message-ID: Hello! Traffic optimization is a really nice place for open source project! :) On Fri, May 15, 2015 at 6:27 PM, Rafael Possamai wrote: > Internap also has a product called MIRO, although I am not sure how it > differs from FCP. > > On Fri, May 15, 2015 at 10:19 AM, Mike Hammett wrote: > >> What is out there for route optimization products? I can think of Noction >> (no inbound) or Internap FCP (old). >> >> >> >> ----- >> Mike Hammett >> Intelligent Computing Solutions >> http://www.ics-il.com >> >> >> >> Midwest Internet Exchange >> http://www.midwest-ix.com >> >> -- Sincerely yours, Pavel Odintsov From contact at winterei.se Fri May 15 16:26:17 2015 From: contact at winterei.se (Paul S.) Date: Sat, 16 May 2015 01:26:17 +0900 Subject: Route Optimization Products In-Reply-To: References: <281829361.425437.1431703196407.JavaMail.root@mailbox1.ics-il.net> Message-ID: <55561E29.1030506@winterei.se> Problem in this space is, none of the products offered are genuinely affordable. When your route optimization software costs more monthly than yet another link to yet another tier one provider... `-` On 5/16/2015 ?? 12:27, Rafael Possamai wrote: > Internap also has a product called MIRO, although I am not sure how it > differs from FCP. > > On Fri, May 15, 2015 at 10:19 AM, Mike Hammett wrote: > >> What is out there for route optimization products? I can think of Noction >> (no inbound) or Internap FCP (old). >> >> >> >> ----- >> Mike Hammett >> Intelligent Computing Solutions >> http://www.ics-il.com >> >> >> >> Midwest Internet Exchange >> http://www.midwest-ix.com >> >> From magicsata at gmail.com Fri May 15 17:25:55 2015 From: magicsata at gmail.com (Alistair Mackenzie) Date: Fri, 15 May 2015 18:25:55 +0100 Subject: Route Optimization Products In-Reply-To: <55561E29.1030506@winterei.se> References: <281829361.425437.1431703196407.JavaMail.root@mailbox1.ics-il.net> <55561E29.1030506@winterei.se> Message-ID: There is this but its old and not been updated in quote some time. Never got around to playing with it. https://github.com/kvogt/kyro On 15 May 2015 at 17:26, Paul S. wrote: > Problem in this space is, none of the products offered are genuinely > affordable. > > When your route optimization software costs more monthly than yet another > link to yet another tier one provider... `-` > > > On 5/16/2015 ?? 12:27, Rafael Possamai wrote: > >> Internap also has a product called MIRO, although I am not sure how it >> differs from FCP. >> >> On Fri, May 15, 2015 at 10:19 AM, Mike Hammett wrote: >> >> What is out there for route optimization products? I can think of Noction >>> (no inbound) or Internap FCP (old). >>> >>> >>> >>> ----- >>> Mike Hammett >>> Intelligent Computing Solutions >>> http://www.ics-il.com >>> >>> >>> >>> Midwest Internet Exchange >>> http://www.midwest-ix.com >>> >>> >>> > From job at instituut.net Fri May 15 17:31:59 2015 From: job at instituut.net (Job Snijders) Date: Fri, 15 May 2015 19:31:59 +0200 Subject: Route Optimization Products In-Reply-To: <281829361.425437.1431703196407.JavaMail.root@mailbox1.ics-il.net> References: <281829361.425437.1431703196407.JavaMail.root@mailbox1.ics-il.net> Message-ID: <20150515173159.GF58899@Vurt.local> On Fri, May 15, 2015 at 10:19:56AM -0500, Mike Hammett wrote: > What is out there for route optimization products? I can think of > Noction (no inbound) or Internap FCP (old). Are you sure that an 'optimizer' is the right solution for you, or for those surrounding you (peers, upstreams)? http://www.bgpmon.net/bgp-optimizer-causes-thousands-of-fake-routes/ From nanog at ics-il.net Fri May 15 17:38:32 2015 From: nanog at ics-il.net (Mike Hammett) Date: Fri, 15 May 2015 12:38:32 -0500 (CDT) Subject: Route Optimization Products In-Reply-To: <20150515173159.GF58899@Vurt.local> Message-ID: <209094.279.1431711512513.JavaMail.mhammett@ThunderFuck> Sounds like multiple parties having improper route filters. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest Internet Exchange http://www.midwest-ix.com ----- Original Message ----- From: "Job Snijders" To: "Mike Hammett" Cc: "NANOG" Sent: Friday, May 15, 2015 12:31:59 PM Subject: Re: Route Optimization Products On Fri, May 15, 2015 at 10:19:56AM -0500, Mike Hammett wrote: > What is out there for route optimization products? I can think of > Noction (no inbound) or Internap FCP (old). Are you sure that an 'optimizer' is the right solution for you, or for those surrounding you (peers, upstreams)? http://www.bgpmon.net/bgp-optimizer-causes-thousands-of-fake-routes/ From rafael at gav.ufsc.br Fri May 15 18:09:24 2015 From: rafael at gav.ufsc.br (Rafael Possamai) Date: Fri, 15 May 2015 13:09:24 -0500 Subject: Route Optimization Products In-Reply-To: <281829361.425437.1431703196407.JavaMail.root@mailbox1.ics-il.net> References: <281829361.425437.1431703196407.JavaMail.root@mailbox1.ics-il.net> Message-ID: I've been a customer before of a datacenter in Chicago that uses/used Internap's optimized routes and latency was always better than in comparison to other locations I tested against. That was around 2011 or 2012. On Fri, May 15, 2015 at 10:19 AM, Mike Hammett wrote: > What is out there for route optimization products? I can think of Noction > (no inbound) or Internap FCP (old). > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > > > Midwest Internet Exchange > http://www.midwest-ix.com > > From randy at psg.com Fri May 15 18:10:25 2015 From: randy at psg.com (Randy Bush) Date: Fri, 15 May 2015 08:10:25 -1000 Subject: Route Optimization Products In-Reply-To: <209094.279.1431711512513.JavaMail.mhammett@ThunderFuck> References: <20150515173159.GF58899@Vurt.local> <209094.279.1431711512513.JavaMail.mhammett@ThunderFuck> Message-ID: >> http://www.bgpmon.net/bgp-optimizer-causes-thousands-of-fake-routes/ > Sounds like multiple parties having improper route filters. on the internet? never! randy From cscora at apnic.net Fri May 15 18:12:06 2015 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 16 May 2015 04:12:06 +1000 (AEST) Subject: Weekly Routing Table Report Message-ID: <201505151812.t4FIC60l015044@thyme.rand.apnic.net> This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. The posting is sent to APOPS, NANOG, AfNOG, AusNOG, SANOG, PacNOG, CaribNOG and the RIPE Routing Working Group. Daily listings are sent to bgp-stats at lists.apnic.net For historical data, please see http://thyme.rand.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 16 May, 2015 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 544597 Prefixes after maximum aggregation (per Origin AS): 207309 Deaggregation factor: 2.63 Unique aggregates announced (without unneeded subnets): 265266 Total ASes present in the Internet Routing Table: 50345 Prefixes per ASN: 10.82 Origin-only ASes present in the Internet Routing Table: 36669 Origin ASes announcing only one prefix: 16315 Transit ASes present in the Internet Routing Table: 6314 Transit-only ASes present in the Internet Routing Table: 171 Average AS path length visible in the Internet Routing Table: 4.4 Max AS path length visible: 44 Max AS path prepend of ASN ( 55944) 41 Prefixes from unregistered ASNs in the Routing Table: 1137 Unregistered ASNs in the Routing Table: 404 Number of 32-bit ASNs allocated by the RIRs: 9483 Number of 32-bit ASNs visible in the Routing Table: 7362 Prefixes from 32-bit ASNs in the Routing Table: 26788 Number of bogon 32-bit ASNs visible in the Routing Table: 8 Special use prefixes present in the Routing Table: 1 Prefixes being announced from unallocated address space: 381 Number of addresses announced to Internet: 2756729056 Equivalent to 164 /8s, 80 /16s and 88 /24s Percentage of available address space announced: 74.5 Percentage of allocated address space announced: 74.5 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 97.3 Total number of prefixes smaller than registry allocations: 183001 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 134278 Total APNIC prefixes after maximum aggregation: 39134 APNIC Deaggregation factor: 3.43 Prefixes being announced from the APNIC address blocks: 140442 Unique aggregates announced from the APNIC address blocks: 57068 APNIC Region origin ASes present in the Internet Routing Table: 5046 APNIC Prefixes per ASN: 27.83 APNIC Region origin ASes announcing only one prefix: 1213 APNIC Region transit ASes present in the Internet Routing Table: 881 Average APNIC Region AS path length visible: 4.4 Max APNIC Region AS path length visible: 44 Number of APNIC region 32-bit ASNs visible in the Routing Table: 1436 Number of APNIC addresses announced to Internet: 748187328 Equivalent to 44 /8s, 152 /16s and 110 /24s Percentage of available APNIC address space announced: 87.4 APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079, 55296-56319, 58368-59391, 63488-64098, 131072-135580 APNIC Address Blocks 1/8, 14/8, 27/8, 36/8, 39/8, 42/8, 43/8, 49/8, 58/8, 59/8, 60/8, 61/8, 101/8, 103/8, 106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 133/8, 150/8, 153/8, 163/8, 171/8, 175/8, 180/8, 182/8, 183/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, 223/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 178798 Total ARIN prefixes after maximum aggregation: 87957 ARIN Deaggregation factor: 2.03 Prefixes being announced from the ARIN address blocks: 181364 Unique aggregates announced from the ARIN address blocks: 84503 ARIN Region origin ASes present in the Internet Routing Table: 16600 ARIN Prefixes per ASN: 10.93 ARIN Region origin ASes announcing only one prefix: 6118 ARIN Region transit ASes present in the Internet Routing Table: 1726 Average ARIN Region AS path length visible: 3.8 Max ARIN Region AS path length visible: 24 Number of ARIN region 32-bit ASNs visible in the Routing Table: 441 Number of ARIN addresses announced to Internet: 1080161056 Equivalent to 64 /8s, 97 /16s and 243 /24s Percentage of available ARIN address space announced: 57.1 ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 53248-55295, 62464-63487, 64198-64296, 393216-395164 ARIN Address Blocks 3/8, 4/8, 6/8, 7/8, 8/8, 9/8, 11/8, 12/8, 13/8, 15/8, 16/8, 17/8, 18/8, 19/8, 20/8, 21/8, 22/8, 23/8, 24/8, 26/8, 28/8, 29/8, 30/8, 32/8, 33/8, 34/8, 35/8, 38/8, 40/8, 44/8, 45/8, 47/8, 48/8, 50/8, 52/8, 53/8, 54/8, 55/8, 56/8, 57/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, 100/8, 104/8, 107/8, 108/8, 128/8, 129/8, 130/8, 131/8, 132/8, 134/8, 135/8, 136/8, 137/8, 138/8, 139/8, 140/8, 142/8, 143/8, 144/8, 146/8, 147/8, 148/8, 149/8, 152/8, 155/8, 156/8, 157/8, 158/8, 159/8, 160/8, 161/8, 162/8, 164/8, 165/8, 166/8, 167/8, 168/8, 169/8, 170/8, 172/8, 173/8, 174/8, 184/8, 192/8, 198/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 214/8, 215/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 132181 Total RIPE prefixes after maximum aggregation: 65857 RIPE Deaggregation factor: 2.01 Prefixes being announced from the RIPE address blocks: 138555 Unique aggregates announced from the RIPE address blocks: 85570 RIPE Region origin ASes present in the Internet Routing Table: 17964 RIPE Prefixes per ASN: 7.71 RIPE Region origin ASes announcing only one prefix: 8157 RIPE Region transit ASes present in the Internet Routing Table: 2964 Average RIPE Region AS path length visible: 4.9 Max RIPE Region AS path length visible: 34 Number of RIPE region 32-bit ASNs visible in the Routing Table: 3695 Number of RIPE addresses announced to Internet: 694796544 Equivalent to 41 /8s, 105 /16s and 193 /24s Percentage of available RIPE address space announced: 101.0 RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-52223, 56320-58367 59392-61439, 61952-62463, 196608-202239 RIPE Address Blocks 2/8, 5/8, 25/8, 31/8, 37/8, 46/8, 51/8, 62/8, 77/8, 78/8, 79/8, 80/8, 81/8, 82/8, 83/8, 84/8, 85/8, 86/8, 87/8, 88/8, 89/8, 90/8, 91/8, 92/8, 93/8, 94/8, 95/8, 109/8, 141/8, 145/8, 151/8, 176/8, 178/8, 185/8, 188/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 59651 Total LACNIC prefixes after maximum aggregation: 11273 LACNIC Deaggregation factor: 5.29 Prefixes being announced from the LACNIC address blocks: 69921 Unique aggregates announced from the LACNIC address blocks: 32620 LACNIC Region origin ASes present in the Internet Routing Table: 2438 LACNIC Prefixes per ASN: 28.68 LACNIC Region origin ASes announcing only one prefix: 628 LACNIC Region transit ASes present in the Internet Routing Table: 500 Average LACNIC Region AS path length visible: 4.9 Max LACNIC Region AS path length visible: 25 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 1677 Number of LACNIC addresses announced to Internet: 168058368 Equivalent to 10 /8s, 4 /16s and 94 /24s Percentage of available LACNIC address space announced: 100.2 LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 61440-61951, 64099-64197, 262144-265628 + ERX transfers LACNIC Address Blocks 177/8, 179/8, 181/8, 186/8, 187/8, 189/8, 190/8, 191/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 12727 Total AfriNIC prefixes after maximum aggregation: 3044 AfriNIC Deaggregation factor: 4.18 Prefixes being announced from the AfriNIC address blocks: 13934 Unique aggregates announced from the AfriNIC address blocks: 5177 AfriNIC Region origin ASes present in the Internet Routing Table: 734 AfriNIC Prefixes per ASN: 18.98 AfriNIC Region origin ASes announcing only one prefix: 199 AfriNIC Region transit ASes present in the Internet Routing Table: 162 Average AfriNIC Region AS path length visible: 4.5 Max AfriNIC Region AS path length visible: 24 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 113 Number of AfriNIC addresses announced to Internet: 65147392 Equivalent to 3 /8s, 226 /16s and 18 /24s Percentage of available AfriNIC address space announced: 64.7 AfriNIC AS Blocks 36864-37887, 327680-328703 & ERX transfers AfriNIC Address Blocks 41/8, 102/8, 105/8, 154/8, 196/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4766 2928 11557 913 Korea Telecom 17974 2770 904 81 PT Telekomunikasi Indonesia 7545 2588 336 130 TPG Telecom Limited 4755 2019 423 218 TATA Communications formerly 4538 1935 4190 72 China Education and Research 9829 1656 1326 39 National Internet Backbone 9808 1574 8717 28 Guangdong Mobile Communicatio 4808 1427 2241 453 CNCGROUP IP network China169 9583 1417 118 578 Sify Limited 9498 1337 335 100 BHARTI Airtel Ltd. Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 22773 3031 2955 140 Cox Communications Inc. 6389 2798 3688 51 BellSouth.net Inc. 3356 2568 10686 493 Level 3 Communications, Inc. 18566 2042 379 185 MegaPath Corporation 20115 1880 1850 430 Charter Communications 6983 1750 866 246 EarthLink, Inc. 4323 1610 1022 410 tw telecom holdings, inc. 30036 1536 314 486 Mediacom Communications Corp 701 1391 11290 680 MCI Communications Services, 22561 1358 413 248 CenturyTel Internet Holdings, Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 39891 2473 132 7 SaudiNet, Saudi Telecom Compa 34984 1987 304 353 TELLCOM ILETISIM HIZMETLERI A 20940 1859 726 1364 Akamai International B.V. 6849 1213 356 24 JSC "Ukrtelecom" 8402 1051 544 15 OJSC "Vimpelcom" 31148 1047 45 27 Freenet Ltd. 13188 1040 97 70 TOV "Bank-Inform" 12479 927 867 76 France Telecom Espana SA 6830 907 2693 466 Liberty Global Operations B.V 8551 885 373 48 Bezeq International-Ltd Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 10620 3222 526 191 Telmex Colombia S.A. 28573 2302 2169 117 NET Servi?os de Comunica??o S 7303 1662 1045 243 Telecom Argentina S.A. 6147 1632 374 30 Telefonica del Peru S.A.A. 8151 1629 3235 465 Uninet S.A. de C.V. 6503 1250 421 54 Axtel, S.A.B. de C.V. 26615 1052 2325 35 Tim Celular S.A. 7738 999 1882 41 Telemar Norte Leste S.A. 3816 921 422 155 COLOMBIA TELECOMUNICACIONES S 18881 869 1036 22 Global Village Telecom Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 8452 1632 958 13 TE-AS 24863 900 280 26 Link Egypt (Link.NET) 36903 504 254 98 Office National des Postes et 36992 419 1229 32 ETISALAT MISR 37492 303 171 72 Orange Tunisie 24835 301 146 13 Vodafone Data 3741 250 857 208 Internet Solutions 29571 241 21 12 Cote d'Ivoire Telecom 36947 202 807 13 Telecom Algeria 37054 200 19 6 Data Telecom Service Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 10620 3222 526 191 Telmex Colombia S.A. 22773 3031 2955 140 Cox Communications Inc. 4766 2928 11557 913 Korea Telecom 6389 2798 3688 51 BellSouth.net Inc. 17974 2770 904 81 PT Telekomunikasi Indonesia 7545 2588 336 130 TPG Telecom Limited 3356 2568 10686 493 Level 3 Communications, Inc. 39891 2473 132 7 SaudiNet, Saudi Telecom Compa 28573 2302 2169 117 NET Servi?os de Comunica??o S 18566 2042 379 185 MegaPath Corporation Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 22773 3031 2891 Cox Communications Inc. 6389 2798 2747 BellSouth.net Inc. 17974 2770 2689 PT Telekomunikasi Indonesia 39891 2473 2466 SaudiNet, Saudi Telecom Compa 7545 2588 2458 TPG Telecom Limited 28573 2302 2185 NET Servi?os de Comunica??o S 3356 2568 2075 Level 3 Communications, Inc. 4766 2928 2015 Korea Telecom 4538 1935 1863 China Education and Research 18566 2042 1857 MegaPath Corporation Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 30662 UNALLOCATED 8.2.129.0/24 3356 Level 3 Communicatio 53506 UNALLOCATED 8.17.102.0/23 3356 Level 3 Communicatio 46467 UNALLOCATED 8.19.192.0/24 46887 Lightower Fiber Netw 18985 UNALLOCATED 8.21.68.0/22 3356 Level 3 Communicatio 46473 UNALLOCATED 8.27.122.0/24 12180 Internap Network Ser 46473 UNALLOCATED 8.27.124.0/24 12180 Internap Network Ser 27205 UNALLOCATED 8.38.16.0/21 6461 Abovenet Communicati 15347 UNALLOCATED 8.224.147.0/24 12064 Cox Communications I 33628 UNALLOCATED 12.0.239.0/24 1239 Sprint 32805 UNALLOCATED 12.1.225.0/24 7018 AT&T Services, Inc. Complete listing at http://thyme.rand.apnic.net/current/data-badAS Prefixes from private and non-routed address space (Global) ----------------------------------------------------------- Prefix Origin AS Description 100.100.100.0/24 48159 Telecommunication Infrastruct Complete listing at http://thyme.rand.apnic.net/current/data-dsua Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 5.100.241.0/24 23456 32bit Transition AS 23.226.112.0/20 62788 >>UNKNOWN<< 27.100.7.0/24 56096 >>UNKNOWN<< 31.217.248.0/21 44902 COVAGE NETWORKS SASU 41.73.1.0/24 37004 >>UNKNOWN<< 41.73.10.0/24 37004 >>UNKNOWN<< 41.73.11.0/24 37004 >>UNKNOWN<< 41.73.12.0/24 37004 >>UNKNOWN<< 41.73.13.0/24 37004 >>UNKNOWN<< 41.73.15.0/24 37004 >>UNKNOWN<< Complete listing at http://thyme.rand.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:17 /9:12 /10:34 /11:94 /12:264 /13:504 /14:1005 /15:1714 /16:12936 /17:7221 /18:12313 /19:25437 /20:35970 /21:38561 /22:59301 /23:51903 /24:294315 /25:1100 /26:1132 /27:718 /28:14 /29:12 /30:7 /31:0 /32:13 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 39891 2432 2473 SaudiNet, Saudi Telecom Compa 22773 2243 3031 Cox Communications Inc. 18566 1996 2042 MegaPath Corporation 6389 1641 2798 BellSouth.net Inc. 6983 1396 1750 EarthLink, Inc. 30036 1374 1536 Mediacom Communications Corp 34984 1305 1987 TELLCOM ILETISIM HIZMETLERI A 6147 1183 1632 Telefonica del Peru S.A.A. 10620 1135 3222 Telmex Colombia S.A. 11492 1109 1185 CABLE ONE, INC. Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1478 2:680 4:93 5:1798 6:24 8:1418 11:1 12:1822 13:10 14:1324 15:17 16:2 17:43 18:22 20:48 23:1225 24:1696 27:1867 31:1589 32:38 33:2 34:4 35:3 36:117 37:1908 38:1018 39:6 40:251 41:3007 42:284 43:1274 44:26 45:572 46:2191 47:40 49:855 50:805 52:12 54:73 55:7 56:8 57:39 58:1286 59:714 60:475 61:1752 62:1326 63:1915 64:4409 65:2250 66:4070 67:2066 68:1055 69:3265 70:980 71:448 72:1961 74:2655 75:337 76:422 77:1452 78:1186 79:803 80:1335 81:1338 82:812 83:696 84:717 85:1372 86:393 87:1044 88:514 89:1831 90:151 91:5977 92:837 93:2220 94:2016 95:2134 96:428 97:354 98:1053 99:49 100:70 101:830 103:7392 104:1778 105:63 106:244 107:953 108:627 109:2044 110:1102 111:1487 112:800 113:1077 114:821 115:1281 116:1359 117:1057 118:1804 119:1452 120:448 121:1080 122:2138 123:1809 124:1511 125:1583 128:647 129:386 130:396 131:1182 132:490 133:174 134:414 135:107 136:325 137:309 138:717 139:147 140:236 141:444 142:671 143:504 144:569 145:115 146:702 147:585 148:1131 149:402 150:562 151:597 152:494 153:243 154:487 155:859 156:406 157:463 158:319 159:1005 160:379 161:659 162:1927 163:423 164:669 165:691 166:307 167:828 168:1294 169:169 170:1462 171:245 172:45 173:1518 174:710 175:689 176:1308 177:3766 178:2161 179:960 180:1963 181:1689 182:1769 183:616 184:740 185:3481 186:2654 187:1739 188:2040 189:1575 190:7707 191:974 192:8332 193:5601 194:4136 195:3641 196:1641 197:1030 198:5536 199:5544 200:6661 201:3092 202:9437 203:9130 204:4668 205:2829 206:3086 207:2951 208:3966 209:3963 210:3526 211:1849 212:2526 213:2337 214:869 215:72 216:5662 217:1821 218:697 219:463 220:1452 221:785 222:476 223:686 End of report From job at instituut.net Fri May 15 18:27:16 2015 From: job at instituut.net (Job Snijders) Date: Fri, 15 May 2015 20:27:16 +0200 Subject: Route Optimization Products In-Reply-To: <209094.279.1431711512513.JavaMail.mhammett@ThunderFuck> References: <20150515173159.GF58899@Vurt.local> <209094.279.1431711512513.JavaMail.mhammett@ThunderFuck> Message-ID: <20150515182716.GG58899@Vurt.local> On Fri, May 15, 2015 at 12:38:32PM -0500, Mike Hammett wrote: > Sounds like multiple parties having improper route filters. Filtering is a must. But even when doing the right thing, there could be adverse side-effects when using an appliance which inserts fake, more-specific paths into your network's iBGP mesh. Earlier this year there was discussion about the subject, I'd like to refer you to this: http://seclists.org/nanog/2015/Mar/485 Kind regards, Job From nanog at ics-il.net Fri May 15 20:19:18 2015 From: nanog at ics-il.net (Mike Hammett) Date: Fri, 15 May 2015 15:19:18 -0500 (CDT) Subject: Route Optimization Products In-Reply-To: <55561E29.1030506@winterei.se> Message-ID: <16424077.1028.1431721145197.JavaMail.mhammett@ThunderFuck> Perhaps, but that wouldn't solve the problem of automatically moving traffic when a provider has an issue on their own network. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest Internet Exchange http://www.midwest-ix.com ----- Original Message ----- From: "Paul S." To: nanog at nanog.org Sent: Friday, May 15, 2015 11:26:17 AM Subject: Re: Route Optimization Products Problem in this space is, none of the products offered are genuinely affordable. When your route optimization software costs more monthly than yet another link to yet another tier one provider... `-` On 5/16/2015 ?? 12:27, Rafael Possamai wrote: > Internap also has a product called MIRO, although I am not sure how it > differs from FCP. > > On Fri, May 15, 2015 at 10:19 AM, Mike Hammett wrote: > >> What is out there for route optimization products? I can think of Noction >> (no inbound) or Internap FCP (old). >> >> >> >> ----- >> Mike Hammett >> Intelligent Computing Solutions >> http://www.ics-il.com >> >> >> >> Midwest Internet Exchange >> http://www.midwest-ix.com >> >> From cidr-report at potaroo.net Fri May 15 22:00:00 2015 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 15 May 2015 22:00:00 GMT Subject: The Cidr Report Message-ID: <201505152200.t4FM008I012182@wattle.apnic.net> This report has been generated at Fri May 15 21:14:39 2015 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/2.0 for a current version of this report. Recent Table History Date Prefixes CIDR Agg 08-05-15 550752 303458 09-05-15 550295 303313 10-05-15 550707 303328 11-05-15 550808 303487 12-05-15 550732 303681 13-05-15 551148 304119 14-05-15 551560 303696 15-05-15 551181 304047 AS Summary 50609 Number of ASes in routing system 20188 Number of ASes announcing only one prefix 3222 Largest number of prefixes announced by an AS AS10620: Telmex Colombia S.A.,CO 120960512 Largest address span announced by an AS (/32s) AS4134 : CHINANET-BACKBONE No.31,Jin-rong Street,CN 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'). --- 15May15 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 551910 304343 247567 44.9% All ASes AS22773 3033 169 2864 94.4% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc.,US AS17974 2770 81 2689 97.1% TELKOMNET-AS2-AP PT Telekomunikasi Indonesia,ID AS6389 2798 182 2616 93.5% BELLSOUTH-NET-BLK - BellSouth.net Inc.,US AS39891 2472 27 2445 98.9% ALJAWWALSTC-AS Saudi Telecom Company JSC,SA AS28573 2303 311 1992 86.5% NET Servi?os de Comunica??o S.A.,BR AS3356 2571 703 1868 72.7% LEVEL3 - Level 3 Communications, Inc.,US AS4766 2928 1337 1591 54.3% KIXS-AS-KR Korea Telecom,KR AS9808 1574 67 1507 95.7% CMNET-GD Guangdong Mobile Communication Co.Ltd.,CN AS6983 1749 249 1500 85.8% ITCDELTA - Earthlink, Inc.,US AS7545 2635 1160 1475 56.0% TPG-INTERNET-AP TPG Telecom Limited,AU AS20115 1880 494 1386 73.7% CHARTER-NET-HKY-NC - Charter Communications,US AS7303 1660 291 1369 82.5% Telecom Argentina S.A.,AR AS6147 1632 285 1347 82.5% Telefonica del Peru S.A.A.,PE AS4755 2017 732 1285 63.7% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP,IN AS10620 3222 1941 1281 39.8% Telmex Colombia S.A.,CO AS9498 1337 115 1222 91.4% BBIL-AP BHARTI Airtel Ltd.,IN AS4323 1620 412 1208 74.6% TWTC - tw telecom holdings, inc.,US AS18566 2042 874 1168 57.2% MEGAPATH5-US - MegaPath Corporation,US AS7552 1169 56 1113 95.2% VIETEL-AS-AP Viettel Corporation,VN AS22561 1358 281 1077 79.3% CENTURYLINK-LEGACY-LIGHTCORE - CenturyTel Internet Holdings, Inc.,US AS8402 1029 24 1005 97.7% CORBINA-AS OJSC "Vimpelcom",RU AS6849 1210 219 991 81.9% UKRTELNET JSC UKRTELECOM,UA AS8151 1635 682 953 58.3% Uninet S.A. de C.V.,MX AS7738 999 83 916 91.7% Telemar Norte Leste S.A.,BR AS26615 1052 164 888 84.4% Tim Celular S.A.,BR AS4538 1955 1074 881 45.1% ERX-CERNET-BKB China Education and Research Network Center,CN AS38285 982 119 863 87.9% M2TELECOMMUNICATIONS-AU M2 Telecommunications Group Ltd,AU AS18881 869 39 830 95.5% Global Village Telecom,BR AS4780 1074 263 811 75.5% SEEDNET Digital United Inc.,TW AS24560 1237 462 775 62.7% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services,IN Total 54812 12896 41916 76.5% Top 30 total Possible Bogus Routes 5.100.241.0/24 AS19957 -Reserved AS-,ZZ 23.226.112.0/20 AS62788 -Reserved AS-,ZZ 27.100.7.0/24 AS56096 31.217.248.0/21 AS44902 COV-ASN COVAGE NETWORKS SASU,FR 41.73.1.0/24 AS37004 -Reserved AS-,ZZ 41.73.10.0/24 AS37004 -Reserved AS-,ZZ 41.73.11.0/24 AS37004 -Reserved AS-,ZZ 41.73.12.0/24 AS37004 -Reserved AS-,ZZ 41.73.13.0/24 AS37004 -Reserved AS-,ZZ 41.73.15.0/24 AS37004 -Reserved AS-,ZZ 41.73.16.0/24 AS37004 -Reserved AS-,ZZ 41.73.18.0/24 AS37004 -Reserved AS-,ZZ 41.73.20.0/24 AS37004 -Reserved AS-,ZZ 41.73.21.0/24 AS37004 -Reserved AS-,ZZ 41.76.48.0/21 AS36969 MTL-AS,MW 41.78.180.0/23 AS37265 -Reserved AS-,ZZ 41.189.127.0/24 AS37000 -Reserved AS-,ZZ 41.189.128.0/24 AS37000 -Reserved AS-,ZZ 41.191.108.0/22 AS37004 -Reserved AS-,ZZ 41.191.108.0/24 AS37004 -Reserved AS-,ZZ 41.191.109.0/24 AS37004 -Reserved AS-,ZZ 41.191.110.0/24 AS37004 -Reserved AS-,ZZ 41.191.111.0/24 AS37004 -Reserved AS-,ZZ 41.242.152.0/22 AS37558 LITC,LY 41.242.156.0/22 AS37558 LITC,LY 45.67.78.0/24 AS38040 GLOBAL-TRANSIT-TOT-IIG-TH TOT Public Company Limited,TH 65.75.216.0/23 AS10494 AAI - Accurate Automation, Inc.,US 65.75.217.0/24 AS10494 AAI - Accurate Automation, Inc.,US 65.111.1.0/24 AS32258 SDNGLOBAL - SDN Global,US 66.78.66.0/23 AS10835 VISIONARY - Visionary Communications, Inc.,US 66.78.68.0/22 AS10835 VISIONARY - Visionary Communications, Inc.,US 66.78.76.0/23 AS10835 VISIONARY - Visionary Communications, Inc.,US 66.78.80.0/21 AS10835 VISIONARY - Visionary Communications, Inc.,US 66.78.91.0/24 AS10835 VISIONARY - Visionary Communications, Inc.,US 66.180.64.0/21 AS32558 ZEUTER - Zeuter Development Corporation,CA 66.187.240.0/20 AS14552 ACS-SOUTHEASTDATACENTER - Affiliated Computer Services, Inc.,US 66.205.224.0/19 AS16526 BIRCH-TELECOM - Birch Telecom, Inc.,US 66.251.128.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.133.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.134.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.136.0/21 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.140.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.141.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.142.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 72.19.0.0/19 AS16526 BIRCH-TELECOM - Birch Telecom, Inc.,US 74.113.200.0/23 AS46939 -Reserved AS-,ZZ 74.114.52.0/22 AS40818 -Reserved AS-,ZZ 74.114.52.0/23 AS40818 -Reserved AS-,ZZ 74.114.52.0/24 AS40818 -Reserved AS-,ZZ 74.114.53.0/24 AS40818 -Reserved AS-,ZZ 74.114.54.0/23 AS40818 -Reserved AS-,ZZ 74.114.54.0/24 AS40818 -Reserved AS-,ZZ 74.114.55.0/24 AS40818 -Reserved AS-,ZZ 74.114.184.0/22 AS19888 -Reserved AS-,ZZ 74.121.24.0/22 AS36263 FORONA - Forona Technologies, Inc.,US 74.123.136.0/21 AS53358 -Reserved AS-,ZZ 77.243.91.0/24 AS42597 -Reserved AS-,ZZ 80.78.133.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US 80.78.134.0/23 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US 80.78.134.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US 80.78.135.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US 80.250.32.0/22 AS37106 ODUA-AS,NG 83.142.48.0/24 AS13213 UK2NET-AS UK2 - Ltd,GB 83.142.49.0/24 AS13213 UK2NET-AS UK2 - Ltd,GB 91.103.8.0/24 AS42551 -Reserved AS-,ZZ 91.103.9.0/24 AS42551 -Reserved AS-,ZZ 91.103.10.0/24 AS42551 -Reserved AS-,ZZ 91.103.11.0/24 AS42551 -Reserved AS-,ZZ 91.193.60.0/22 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 91.195.66.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 91.197.36.0/22 AS43359 -Reserved AS-,ZZ 91.230.27.0/24 AS57022 -Reserved AS-,ZZ 98.143.160.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.161.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.162.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.163.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.164.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.165.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.166.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.167.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.168.0/22 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.172.0/22 AS26566 -Reserved AS-,ZZ 98.143.172.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.173.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.174.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.175.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 100.100.100.0/24 AS48159 TIC-AS Telecommunication Infrastructure Company,IR 102.69.1.0/24 AS59749 CLEANMAT CLEANMAT EOOD,BG 103.6.248.0/22 AS13220 103.6.248.0/24 AS13220 103.6.249.0/24 AS13220 103.6.250.0/24 AS13220 103.6.251.0/24 AS13220 103.7.120.0/22 AS4725 ODN SOFTBANK TELECOM Corp.,JP 103.10.222.0/24 AS13189 103.15.92.0/22 AS23818 JETINTERNET JETINTERNET Corporation,JP 103.20.100.0/24 AS45334 AIRCEL-AS-AP Dishnet Wireless Limited,IN 103.20.101.0/24 AS45334 AIRCEL-AS-AP Dishnet Wireless Limited,IN 103.20.219.0/24 AS55795 VERBDC1-AS-AP Verb Data Centre Pty Ltd,AU 103.23.96.0/22 AS13220 103.23.96.0/24 AS13220 103.23.97.0/24 AS13220 103.23.98.0/24 AS13220 103.23.99.0/24 AS13220 103.23.148.0/23 AS13209 103.23.148.0/24 AS13209 103.23.149.0/24 AS13209 103.26.116.0/22 AS17676 GIGAINFRA Softbank BB Corp.,JP 103.28.184.0/22 AS4686 BEKKOAME BEKKOAME INTERNET INC.,JP 103.224.0.0/22 AS18097 DCN D.C.N. Corporation,JP 103.225.116.0/22 AS23818 JETINTERNET JETINTERNET Corporation,JP 103.232.142.0/23 AS17828 TIARE-AS-PG Tiare, a business unit of Pacific Mobile Communications.,PG 103.244.112.0/22 AS23818 JETINTERNET JETINTERNET Corporation,JP 103.248.88.0/22 AS23818 JETINTERNET JETINTERNET Corporation,JP 103.248.220.0/22 AS17676 GIGAINFRA Softbank BB Corp.,JP 103.250.0.0/22 AS17676 GIGAINFRA Softbank BB Corp.,JP 103.253.164.0/23 AS13317 103.255.56.0/22 AS18097 DCN D.C.N. Corporation,JP 103.255.132.0/22 AS18097 DCN D.C.N. Corporation,JP 111.92.184.0/22 AS9797 NEXONASIAPACIFIC-AS-AP Nexon Asia Pacific P/L,AU 116.206.72.0/24 AS6461 ABOVENET - Abovenet Communications, Inc,US 116.206.85.0/24 AS6461 ABOVENET - Abovenet Communications, Inc,US 116.206.103.0/24 AS6461 ABOVENET - Abovenet Communications, Inc,US 117.120.56.0/21 AS4755 TATACOMM-AS TATA Communications formerly VSNL is Leading ISP,IN 142.147.62.0/24 AS3958 AIRCANADA - Air Canada,CA 154.168.28.0/23 AS29571 CITelecom-AS,CI 162.216.176.0/22 AS36114 VERSAWEB-ASN - Versaweb, LLC,US 162.222.128.0/21 AS36114 VERSAWEB-ASN - Versaweb, LLC,US 162.245.64.0/21 AS62788 -Reserved AS-,ZZ 162.248.224.0/21 AS62788 -Reserved AS-,ZZ 166.93.0.0/16 AS23537 CRITIGEN - Micro Source, Inc.,US 167.146.16.0/21 AS22527 -Reserved AS-,ZZ 167.146.26.0/23 AS22527 -Reserved AS-,ZZ 167.146.28.0/23 AS22527 -Reserved AS-,ZZ 167.146.32.0/20 AS22527 -Reserved AS-,ZZ 167.146.44.0/24 AS22527 -Reserved AS-,ZZ 167.146.48.0/22 AS22527 -Reserved AS-,ZZ 167.146.90.0/24 AS22527 -Reserved AS-,ZZ 167.146.93.0/24 AS22527 -Reserved AS-,ZZ 167.146.94.0/24 AS22527 -Reserved AS-,ZZ 167.146.100.0/24 AS22527 -Reserved AS-,ZZ 167.146.104.0/24 AS22527 -Reserved AS-,ZZ 167.146.105.0/24 AS22527 -Reserved AS-,ZZ 167.146.128.0/20 AS22527 -Reserved AS-,ZZ 167.146.137.0/24 AS22527 -Reserved AS-,ZZ 167.146.144.0/20 AS22527 -Reserved AS-,ZZ 167.146.160.0/20 AS22527 -Reserved AS-,ZZ 167.146.200.0/22 AS22527 -Reserved AS-,ZZ 167.146.204.0/24 AS22527 -Reserved AS-,ZZ 167.146.205.0/24 AS22527 -Reserved AS-,ZZ 172.81.120.0/21 AS36351 SOFTLAYER - SoftLayer Technologies Inc.,US 172.81.156.0/22 AS14265 US-TELEPACIFIC - Telepacific Communications,US 172.81.160.0/20 AS14265 US-TELEPACIFIC - Telepacific Communications,US 172.81.176.0/21 AS174 COGENT-174 - Cogent Communications,US 172.81.192.0/18 AS20360 OPPOBOX - OppoBox,US 172.82.0.0/17 AS63008 CONTINA - Contina,US 172.82.128.0/18 AS46261 QUICKPACKET - QuickPacket, LLC,US 172.102.0.0/22 AS4812 CHINANET-SH-AP China Telecom (Group),CN 173.45.192.0/20 AS62722 -Reserved AS-,ZZ 173.45.208.0/20 AS62722 -Reserved AS-,ZZ 185.17.98.0/23 AS19798 HILF-AS Hilf Telecom B.V.,NL 185.100.92.0/22 AS19817 HOSTING90 HOSTING90 systems s.r.o.,CZ 192.9.0.0/16 AS11479 BRM-SUN-AS - Sun Microsystems, Inc,US 192.25.10.0/24 AS5714 HPES - Hewlett-Packard Company,US 192.25.11.0/24 AS5714 HPES - Hewlett-Packard Company,US 192.25.13.0/24 AS5714 HPES - Hewlett-Packard Company,US 192.25.14.0/24 AS5714 HPES - Hewlett-Packard Company,US 192.34.152.0/21 AS10835 VISIONARY - Visionary Communications, Inc.,US 192.75.239.0/24 AS23498 CDSI - COGECODATA,CA 192.84.24.0/24 AS4323 TWTC - tw telecom holdings, inc.,US 192.101.70.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 192.101.71.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 192.101.72.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 192.124.252.0/22 AS680 DFN Verein zur Foerderung eines Deutschen Forschungsnetzes e.V.,DE 192.131.233.0/24 AS7018 ATT-INTERNET4 - AT&T Services, Inc.,US 192.149.81.0/24 AS14454 PERIMETER-ESECURITY - Perimeter eSecurity,US 192.154.32.0/19 AS81 NCREN - MCNC,US 192.154.64.0/19 AS81 NCREN - MCNC,US 192.166.32.0/20 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 192.188.208.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 192.245.195.0/24 AS7381 SUNGARDRS - SunGard Availability Services LP,US 193.9.59.0/24 AS1257 TELE2,SE 193.16.106.0/24 AS31539 -Reserved AS-,ZZ 193.16.145.0/24 AS31392 -Reserved AS-,ZZ 193.22.86.0/24 AS24751 MULTIFI-AS Jakobstadsnejdens Telefon Ab,FI 193.26.213.0/24 AS31641 BYTEL-AS Bytel Ltd,GB 193.28.14.0/24 AS34309 LINK11 Link11 GmbH,DE 193.32.23.0/24 AS2856 BT-UK-AS BT Public Internet Service,GB 193.33.6.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.33.252.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.35.101.0/24 AS57302 -Reserved AS-,ZZ 193.46.200.0/24 AS34243 WEBAGE Web Age Ltd,GB 193.56.203.0/24 AS51110 IDOMTECHNOLOGIES-AS IDOM TECHNOLOGIES,FR 193.111.229.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.149.2.0/23 AS15919 INTERHOST Servicios de Hosting en Internet S.A.,ES 193.164.152.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.176.147.0/24 AS49951 -Reserved AS-,ZZ 193.178.196.0/22 AS15657 SPEEDBONE-AS Speedbone Internet & Connectivity GmbH,DE 193.188.252.0/24 AS38968 TAGORG Abu-Ghazaleh Intellectual Property,JO 193.200.96.0/23 AS2828 XO-AS15 - XO Communications,US 193.200.244.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.201.244.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 193.201.245.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 193.201.246.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 193.202.9.0/24 AS6824 HERMES-NETWORK Hermes Telecom International Ltd,GB 193.223.103.0/24 AS8437 UTA-AS Tele2 Telecommunication GmbH,AT 193.227.109.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.227.236.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 194.6.252.0/24 AS21202 DCSNET-AS Bredband2 AB,SE 194.9.8.0/23 AS2863 SPRITELINK Centor AB,SE 194.9.8.0/24 AS2863 SPRITELINK Centor AB,SE 194.39.78.0/23 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 194.49.17.0/24 AS13135 CREW-AS Wieske's Crew GmbH,DE 194.50.8.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 194.60.88.0/21 AS5089 NTL Virgin Media Limited,GB 194.61.147.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 194.61.150.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 194.61.151.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 194.63.152.0/22 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 194.76.224.0/24 AS34701 WITZENMANN-AS Witzenmann GmbH, Pforzheim,DE 194.76.225.0/24 AS34701 WITZENMANN-AS Witzenmann GmbH, Pforzheim,DE 194.88.6.0/24 AS35093 RO-HTPASSPORT High Tech Passport Ltd SUA California San Jose SUCURSALA BUCURESTI ROMANIA,RO 194.88.226.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 194.99.67.0/24 AS9083 CARPENET carpeNet Information Technologies GmbH,DE 194.114.136.0/22 AS33866 -Reserved AS-,ZZ 194.126.152.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 194.126.219.0/24 AS34545 -Reserved AS-,ZZ 194.126.233.0/24 AS31235 SKIWEBCENTER-AS SKIWEBCENTER SARL,FR 194.180.25.0/24 AS21358 ATOS-ORIGIN-DE-AS Atos Information Technology GmbH,DE 194.187.24.0/22 AS8856 UKRNET UkrNet Ltd,UA 195.8.48.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.8.48.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.42.232.0/22 AS15657 SPEEDBONE-AS Speedbone Internet & Connectivity GmbH,DE 195.85.194.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.85.201.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.110.0.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.128.240.0/23 AS21202 DCSNET-AS Bredband2 AB,SE 195.149.119.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.189.174.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.216.234.0/24 AS31309 NMV-AS New Media Ventures BVBA,BE 195.234.156.0/24 AS25028 -Reserved AS-,ZZ 195.242.182.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.244.18.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 196.3.182.0/24 AS37004 -Reserved AS-,ZZ 196.3.183.0/24 AS37004 -Reserved AS-,ZZ 196.22.8.0/24 AS27822 Emerging Markets Communications de Argentina S.R.L,AR 196.22.11.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US 198.22.195.0/24 AS54583 -Reserved AS-,ZZ 198.23.26.0/24 AS33052 VZUNET - Verizon Data Services LLC,US 198.73.226.0/23 AS62839 -Reserved AS-,ZZ 198.74.11.0/24 AS14573 KEYSPANENERGY-NE1 - Keyspan Energy,US 198.74.13.0/24 AS14573 KEYSPANENERGY-NE1 - Keyspan Energy,US 198.74.38.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services,US 198.74.39.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services,US 198.74.40.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services,US 198.97.72.0/21 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 198.97.96.0/19 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 198.97.240.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 198.163.214.0/24 AS21804 ACCESS-SK - Access Communications Co-operative Limited,CA 198.168.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 199.30.132.0/22 AS26003 -Reserved AS-,ZZ 199.38.248.0/24 AS13951 CENTER-SEVEN - C7 Data Centers, Inc.,US 199.38.249.0/24 AS13951 CENTER-SEVEN - C7 Data Centers, Inc.,US 199.38.250.0/24 AS13951 CENTER-SEVEN - C7 Data Centers, Inc.,US 199.38.251.0/24 AS13951 CENTER-SEVEN - C7 Data Centers, Inc.,US 199.38.252.0/22 AS13951 CENTER-SEVEN - C7 Data Centers, Inc.,US 199.66.15.0/24 AS30169 -Reserved AS-,ZZ 199.85.9.0/24 AS852 ASN852 - TELUS Communications Inc.,CA 199.88.52.0/22 AS17018 QTS-SACRAMENTO-1 - Quality Investment Properties Sacramento, LLC,US 199.102.240.0/24 AS18508 -Reserved AS-,ZZ 199.116.200.0/21 AS22830 -Reserved AS-,ZZ 199.121.0.0/16 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 199.123.16.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 199.233.87.0/24 AS33058 PEGASYSTEMS - Pegasystems Inc.,US 200.6.87.0/24 AS27947 Telconet S.A,EC 200.58.248.0/21 AS27849 200.81.48.0/24 AS11664 Techtel LMDS Comunicaciones Interactivas S.A.,AR 200.81.49.0/24 AS11664 Techtel LMDS Comunicaciones Interactivas S.A.,AR 202.3.75.0/24 AS18172 202.3.76.0/24 AS18172 202.8.106.0/24 AS9530 SHINSEGAE-AS SHINSEGAE I&C Co., Ltd.,KR 202.45.10.0/23 AS24327 202.45.10.0/24 AS24327 202.45.11.0/24 AS24327 202.53.138.0/24 AS4058 CITICTEL-CPC-AS4058 CITIC Telecom International CPC Limited,HK 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network,CN 202.122.134.0/24 AS38615 202.140.147.0/24 AS9583 SIFY-AS-IN Sify Limited,IN 202.158.251.0/24 AS9255 CONNECTPLUS-AS Singapore Telecom,SG 202.165.124.0/24 AS23749 GLOBAL-TRANSIT-AS-HKCOLO-AP HKCOLO ltd. Internet Service Provider,HK 202.179.134.0/24 AS23966 LDN-AS-PK LINKdotNET Telecom Limited,PK 203.142.219.0/24 AS45149 203.175.11.0/24 AS9229 SPEEDCAST-AP SPEEDCAST Limited,HK 203.189.116.0/22 AS45606 203.189.116.0/24 AS45606 203.189.117.0/24 AS45606 203.189.118.0/24 AS45606 203.189.119.0/24 AS45606 203.208.22.0/24 AS13220 204.10.88.0/21 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 204.15.208.0/22 AS13706 COMPLETEWEBNET - CompleteWeb.Net LLC,US 204.16.96.0/24 AS19972 -Reserved AS-,ZZ 204.16.97.0/24 AS19972 -Reserved AS-,ZZ 204.16.98.0/24 AS19972 -Reserved AS-,ZZ 204.16.99.0/24 AS19972 -Reserved AS-,ZZ 204.69.139.0/24 AS40250 -Reserved AS-,ZZ 204.69.144.0/24 AS27283 RJF-INTERNET - Raymond James Financial, Inc.,US 204.86.196.0/23 AS14372 -Reserved AS-,ZZ 204.86.198.0/23 AS33058 PEGASYSTEMS - Pegasystems Inc.,US 204.87.251.0/24 AS22217 -Reserved AS-,ZZ 204.106.16.0/24 AS4323 TWTC - tw telecom holdings, inc.,US 204.187.11.0/24 AS51113 ELEKTA-AS Elekta,GB 204.235.245.0/24 AS22613 -Reserved AS-,ZZ 205.137.240.0/20 AS11686 ENA - Education Networks of America,US 205.159.44.0/24 AS40157 ADESA-CORP-AS - ADESA Corp,US 205.166.231.0/24 AS7029 WINDSTREAM - Windstream Communications Inc,US 205.211.160.0/24 AS30045 UHN-ASN - University Health Network,CA 206.131.192.0/20 AS13220 206.131.192.0/24 AS13220 206.131.193.0/24 AS13220 206.131.194.0/24 AS13220 206.131.195.0/24 AS13220 206.131.197.0/24 AS13220 206.131.200.0/24 AS13220 206.131.201.0/24 AS13220 206.131.202.0/24 AS13220 206.131.203.0/24 AS13220 206.131.204.0/24 AS13220 206.131.205.0/24 AS13220 206.131.206.0/24 AS13220 206.197.184.0/24 AS23304 DATOTEL-STL-AS - Datotel LLC, a NetLabs LLC Company,US 207.2.120.0/21 AS6221 USCYBERSITES - US Cybersites, Inc,US 207.174.131.0/24 AS26116 INDRA - Indra's Net Inc,US 207.174.132.0/23 AS26116 INDRA - Indra's Net Inc,US 207.174.152.0/23 AS26116 INDRA - Indra's Net Inc,US 207.174.154.0/24 AS26116 INDRA - Indra's Net Inc,US 207.174.155.0/24 AS26116 INDRA - Indra's Net Inc,US 207.174.200.0/24 AS22658 EARTHNET - Earthnet, Inc.,US 207.231.96.0/19 AS11194 NUNETPA - NuNet Inc.,US 207.254.128.0/21 AS30689 FLOW-NET - FLOW,JM 207.254.136.0/21 AS30689 FLOW-NET - FLOW,JM 208.66.64.0/24 AS16936 -Reserved AS-,ZZ 208.66.65.0/24 AS16936 -Reserved AS-,ZZ 208.66.66.0/24 AS16936 -Reserved AS-,ZZ 208.66.67.0/24 AS16936 -Reserved AS-,ZZ 208.67.132.0/22 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 208.73.40.0/22 AS19901 -Reserved AS-,ZZ 208.73.41.0/24 AS19901 -Reserved AS-,ZZ 208.75.152.0/21 AS32146 -Reserved AS-,ZZ 208.76.20.0/24 AS31812 -Reserved AS-,ZZ 208.76.21.0/24 AS31812 -Reserved AS-,ZZ 208.77.164.0/24 AS22659 -Reserved AS-,ZZ 208.77.166.0/24 AS4323 TWTC - tw telecom holdings, inc.,US 208.83.53.0/24 AS40569 YGOMI-AS - Ygomi LLC,US 208.84.232.0/24 AS33131 -Reserved AS-,ZZ 208.84.233.0/24 AS33131 -Reserved AS-,ZZ 208.84.234.0/24 AS33131 -Reserved AS-,ZZ 208.84.237.0/24 AS33131 -Reserved AS-,ZZ 208.93.216.0/22 AS209 CENTURYLINK-US-LEGACY-QWEST - Qwest Communications Company, LLC,US 208.94.216.0/23 AS13629 -Reserved AS-,ZZ 208.94.219.0/24 AS13629 -Reserved AS-,ZZ 208.94.221.0/24 AS13629 -Reserved AS-,ZZ 208.94.223.0/24 AS13629 -Reserved AS-,ZZ 209.135.171.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 209.135.175.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 209.177.64.0/20 AS6461 ABOVENET - Abovenet Communications, Inc,US 209.193.112.0/20 AS209 CENTURYLINK-US-LEGACY-QWEST - Qwest Communications Company, LLC,US 209.209.51.0/24 AS18687 MPOWER-2 - MPOWER COMMUNICATIONS CORP.,US 209.234.112.0/23 AS32252 -Reserved AS-,ZZ 209.234.114.0/23 AS32252 -Reserved AS-,ZZ 209.234.116.0/24 AS32252 -Reserved AS-,ZZ 209.234.117.0/24 AS32252 -Reserved AS-,ZZ 209.234.118.0/24 AS32252 -Reserved AS-,ZZ 209.234.119.0/24 AS32252 -Reserved AS-,ZZ 209.234.120.0/24 AS32252 -Reserved AS-,ZZ 209.234.121.0/24 AS32252 -Reserved AS-,ZZ 209.234.122.0/24 AS32252 -Reserved AS-,ZZ 213.255.128.0/20 AS24863 LINKdotNET-AS,EG 213.255.144.0/20 AS24863 LINKdotNET-AS,EG 216.73.81.0/24 AS6432 DOUBLECLICK - Double Click, Inc.,US 216.73.82.0/24 AS6432 DOUBLECLICK - Double Click, Inc.,US 216.73.85.0/24 AS6432 DOUBLECLICK - Double Click, Inc.,US 216.73.88.0/24 AS6432 DOUBLECLICK - Double Click, Inc.,US 216.73.89.0/24 AS6432 DOUBLECLICK - Double Click, Inc.,US 216.73.94.0/24 AS6432 DOUBLECLICK - Double Click, Inc.,US 216.73.95.0/24 AS6432 DOUBLECLICK - Double Click, Inc.,US 216.146.0.0/19 AS11915 US-TELEPACIFIC - TelePacific Communications,US 216.152.24.0/22 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc.,US 216.170.96.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc.,US 216.170.101.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc.,US 216.170.104.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc.,US 216.170.105.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc.,US 216.234.132.0/24 AS14545 ADR-DRIVING-RECORDS - AMERICAN DRIVING RECORDS, INC.,US 216.238.192.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 216.238.193.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 216.238.194.0/24 AS26566 -Reserved AS-,ZZ 216.238.196.0/22 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 216.251.50.0/24 AS38191 INFOSYS-AS Infosys Technologies Ltd,IN 216.251.53.0/24 AS38191 INFOSYS-AS Infosys Technologies Ltd,IN 216.251.62.0/24 AS38191 INFOSYS-AS Infosys Technologies Ltd,IN Please see http://www.cidr-report.org for the full report ------------------------------------ Copies of this report are mailed to: nanog at nanog.org 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 22:00:01 2015 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 15 May 2015 22:00:01 GMT Subject: BGP Update Report Message-ID: <201505152200.t4FM01K8012197@wattle.apnic.net> BGP Update Report Interval: 07-May-15 -to- 14-May-15 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS23752 298407 4.4% 3014.2 -- NPTELECOM-NP-AS Nepal Telecommunications Corporation, Internet Services,NP 2 - AS9829 209003 3.1% 167.3 -- BSNL-NIB National Internet Backbone,IN 3 - AS19361 187594 2.8% 5517.5 -- A.Telecom S.A.,BR 4 - AS22059 130260 1.9% 21710.0 -- APVIO-1 - Apvio, Inc.,US 5 - AS54169 95960 1.4% 47980.0 -- MGH-ION-1 - Marin General Hospital,US 6 - AS36947 83322 1.2% 1096.3 -- ALGTEL-AS,DZ 7 - AS24560 75398 1.1% 61.2 -- AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services,IN 8 - AS45899 74074 1.1% 97.9 -- VNPT-AS-VN VNPT Corp,VN 9 - AS3709 72128 1.1% 2671.4 -- NET-CITY-SA - City of San Antonio,US 10 - AS7713 65973 1.0% 21991.0 -- TELKOMNET-AS-AP PT Telekomunikasi Indonesia,ID 11 - AS9498 62340 0.9% 46.9 -- BBIL-AP BHARTI Airtel Ltd.,IN 12 - AS26821 58631 0.9% 8375.9 -- REVNET - Revelation Networks, Inc.,US 13 - AS7552 43148 0.6% 49.2 -- VIETEL-AS-AP Viettel Corporation,VN 14 - AS46844 40795 0.6% 114.6 -- ST-BGP - Sharktech,US 15 - AS327687 39924 0.6% 1597.0 -- RENU,UG 16 - AS25563 37913 0.6% 9478.2 -- WEBLAND-AS Webland AG, Autonomous System,CH 17 - AS33667 33346 0.5% 1667.3 -- CMCS - Comcast Cable Communications, Inc.,US 18 - AS33651 33229 0.5% 1661.5 -- CMCS - Comcast Cable Communications, Inc.,US 19 - AS6517 32047 0.5% 281.1 -- RELIANCEGLOBALCOM - Reliance Globalcom Services, Inc,US 20 - AS3633 30893 0.5% 523.6 -- PROVINCE-OF-BRITISH-COLUMBIA - Province of British Columbia,CA TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS54169 95960 1.4% 47980.0 -- MGH-ION-1 - Marin General Hospital,US 2 - AS7713 65973 1.0% 21991.0 -- TELKOMNET-AS-AP PT Telekomunikasi Indonesia,ID 3 - AS22059 130260 1.9% 21710.0 -- APVIO-1 - Apvio, Inc.,US 4 - AS197914 16797 0.2% 16797.0 -- STOCKHO-AS Stockho Hosting SARL,FR 5 - AS18135 10624 0.2% 10624.0 -- BTV BTV Cable television,JP 6 - AS393588 9740 0.1% 9740.0 -- MUBEA-FLO - Mubea,US 7 - AS25563 37913 0.6% 9478.2 -- WEBLAND-AS Webland AG, Autonomous System,CH 8 - AS26821 58631 0.9% 8375.9 -- REVNET - Revelation Networks, Inc.,US 9 - AS25553 23131 0.3% 7710.3 -- GLUHOV-TRK TRK Gluhov Ltd.,CZ 10 - AS47680 7644 0.1% 7644.0 -- NHCS EOBO Limited,IE 11 - AS202195 7547 0.1% 7547.0 -- ASTEKOSTMN West Siberian Regional Center of Telecommunications Tekos-Tyumen Ltd.,RU 12 - AS57120 7489 0.1% 7489.0 -- TMK-AS JSC "TMK",RU 13 - AS32005 21466 0.3% 7155.3 -- THE-CHURCH-PENSION-GROUP - CHURCH PENSION GROUP SERVICES CORPORATION,US 14 - AS1757 11096 0.2% 5548.0 -- LEXIS-AS - LexisNexis,US 15 - AS19361 187594 2.8% 5517.5 -- A.Telecom S.A.,BR 16 - AS6629 10764 0.2% 5382.0 -- NOAA-AS - NOAA,US 17 - AS56636 4299 0.1% 4299.0 -- ASVEDARU VEDA Ltd.,RU 18 - AS2167 21171 0.3% 4234.2 -- HPES - Hewlett-Packard Company,US 19 - AS39789 4161 0.1% 4161.0 -- RU-ACTIVE Limited Liability Company Active,RU 20 - AS13483 11197 0.2% 3732.3 -- INFOR-AS13483 - INFOR GLOBAL SOLUTIONS (MICHIGAN), INC.,US TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 202.70.64.0/21 148942 2.1% AS23752 -- NPTELECOM-NP-AS Nepal Telecommunications Corporation, Internet Services,NP 2 - 202.70.88.0/21 148635 2.1% AS23752 -- NPTELECOM-NP-AS Nepal Telecommunications Corporation, Internet Services,NP 3 - 204.80.242.0/24 95888 1.4% AS54169 -- MGH-ION-1 - Marin General Hospital,US 4 - 105.96.0.0/22 82710 1.2% AS36947 -- ALGTEL-AS,DZ 5 - 118.98.88.0/24 66174 0.9% AS64567 -- -Private Use AS-,ZZ AS7713 -- TELKOMNET-AS-AP PT Telekomunikasi Indonesia,ID 6 - 76.191.107.0/24 65027 0.9% AS22059 -- APVIO-1 - Apvio, Inc.,US 7 - 64.34.125.0/24 64975 0.9% AS22059 -- APVIO-1 - Apvio, Inc.,US 8 - 107.0.152.0/24 57680 0.8% AS33651 -- CMCS - Comcast Cable Communications, Inc.,US AS33667 -- CMCS - Comcast Cable Communications, Inc.,US 9 - 196.43.128.0/24 38124 0.6% AS327687 -- RENU,UG 10 - 130.0.192.0/21 16797 0.2% AS197914 -- STOCKHO-AS Stockho Hosting SARL,FR 11 - 66.7.138.0/24 16095 0.2% AS6517 -- RELIANCEGLOBALCOM - Reliance Globalcom Services, Inc,US 12 - 66.7.156.0/24 15646 0.2% AS6517 -- RELIANCEGLOBALCOM - Reliance Globalcom Services, Inc,US 13 - 92.43.216.0/21 12870 0.2% AS25563 -- WEBLAND-AS Webland AG, Autonomous System,CH 14 - 185.84.192.0/22 12655 0.2% AS25563 -- WEBLAND-AS Webland AG, Autonomous System,CH 15 - 178.174.96.0/19 12387 0.2% AS25563 -- WEBLAND-AS Webland AG, Autonomous System,CH 16 - 193.169.125.0/24 11794 0.2% AS25553 -- GLUHOV-TRK TRK Gluhov Ltd.,CZ 17 - 193.169.124.0/23 11308 0.2% AS25553 -- GLUHOV-TRK TRK Gluhov Ltd.,CZ 18 - 198.185.16.0/24 11094 0.2% AS1757 -- LEXIS-AS - LexisNexis,US 19 - 192.58.232.0/24 10762 0.2% AS6629 -- NOAA-AS - NOAA,US 20 - 42.83.48.0/20 10624 0.1% AS18135 -- BTV BTV Cable television,JP Details at http://bgpupdates.potaroo.net ------------------------------------ Copies of this report are mailed to: nanog at nanog.org eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From nanog at ics-il.net Sat May 16 12:04:01 2015 From: nanog at ics-il.net (Mike Hammett) Date: Sat, 16 May 2015 07:04:01 -0500 (CDT) Subject: CenturyLink In-Reply-To: <28147986.2574.1431777666169.JavaMail.mhammett@ThunderFuck> Message-ID: <26745997.2582.1431777796326.JavaMail.mhammett@ThunderFuck> Could someone familiar with CenturyLink's Indianapolis network hit me up offlist? As I don't have a sales opportunity, I didn't engage those channels. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest Internet Exchange http://www.midwest-ix.com From fred at web2objects.com Sat May 16 12:16:16 2015 From: fred at web2objects.com (Fred Hollis) Date: Sat, 16 May 2015 14:16:16 +0200 Subject: Looking for IPv6 /48 from allocation that exists 2-3+ yrs Message-ID: <55573510.3060805@web2objects.com> Hello NANOG, Due to problems with some geo ip databases, we are looking for a /48 from an /32 or /36 allocation that exists for a few years already. East-coast preferred, but open to others in north america as well. Please contact me offlist Thank you, Fred From bryan at digitalocean.com Sat May 16 19:22:59 2015 From: bryan at digitalocean.com (Bryan Socha) Date: Sat, 16 May 2015 15:22:59 -0400 Subject: Fixing Google geolocation screwups In-Reply-To: References: <20150505210746.GH22158@hezmatt.org> <20150506005623.72EF02DCDC31@rock.dv.isc.org> <20150506013634.GV22158@hezmatt.org> <5549C064.4010904@web2objects.com> Message-ID: The best way as a isp/provider to keep google updated on your geo is: 1: support their self published geo feed: http://tools.ietf.org/id/draft-google-self-published-geofeeds-02.html 2: If you qualify get setup on their peering portal http://peering.google com and you'll be able to provide them with your feed and see it's processing status/errors/etc 3: wait a few weeks, it'll take awhile after first process to get all around google. 4: keep your geofeed data accurate keeping it mind it can take a few weeks for new blocks to populate around google. Alternatively, you can try to support their feed and ask the noc to forward a request to the geo team to pull it, it'll help but don't expect it perm fixed. This is only for the services where they might block based on location or default to a specific language. You're not going to alter things like where on google maps you appear. Bryan Socha Network Engineer DigitalOcean From mike.lyon at gmail.com Sun May 17 05:50:04 2015 From: mike.lyon at gmail.com (Mike Lyon) Date: Sat, 16 May 2015 22:50:04 -0700 Subject: Spamhaus BGP feed experiences? Message-ID: Howdy! Any ISPs out there (big or small) ever used the Spamhaus BGP feed to prevent against botnet, spam, etc? If so, how has your experience been? Is it worthwhile? Has it helped? On / off list responses are appreciated in advance. Thank You, Mike -- Mike Lyon 408-621-4826 mike.lyon at gmail.com http://www.linkedin.com/in/mlyon From Durga.Dash at infor.com Fri May 15 15:31:42 2015 From: Durga.Dash at infor.com (Durga Dash) Date: Fri, 15 May 2015 15:31:42 +0000 Subject: Visualware/Speedtest self-hosting alternatives Message-ID: Hi, Are there any turn key solutions out there like Visualware's MCS which you can install in a datacenter and let customers check overall throughput/latency and other metrics from their locations to the datacenter? Thanks Durga. From mfidelman at meetinghouse.net Sun May 17 12:33:28 2015 From: mfidelman at meetinghouse.net (Miles Fidelman) Date: Sun, 17 May 2015 08:33:28 -0400 Subject: Visualware/Speedtest self-hosting alternatives In-Reply-To: References: Message-ID: <55588A98.2@meetinghouse.net> Durga Dash wrote: > Hi, > Are there any turn key solutions out there like Visualware's MCS which you can install in a datacenter and let customers check overall throughput/latency and other metrics from their locations to the datacenter? > Didn't you just answer your own question? (Visualware MCS). Of course if all you're interested in is throughput and latency, there's ping, traceroute, mtr, iperf, etc. - all of which let customers check performance without needing anything special at the datacenter, other than a host to ping against. Miles Fidelman -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From karsten_thomann at linfre.de Sun May 17 15:39:56 2015 From: karsten_thomann at linfre.de (Karsten Thomann) Date: Sun, 17 May 2015 15:39:56 +0000 Subject: Visualware/Speedtest self-hosting alternatives In-Reply-To: <55588A98.2@meetinghouse.net> References: <55588A98.2@meetinghouse.net> Message-ID: <5468724.hL1GFEGn8d@linne> Hi Am Sonntag, 17. Mai 2015, 08:33:28 schrieb Miles Fidelman: > Durga Dash wrote: > > Hi, > > Are there any turn key solutions out there like Visualware's MCS which you > > can install in a datacenter and let customers check overall > > throughput/latency and other metrics from their locations to the > > datacenter? > Didn't you just answer your own question? (Visualware MCS). > > Of course if all you're interested in is throughput and latency, there's > ping, traceroute, mtr, iperf, etc. - all of which let customers check > performance without needing anything special at the datacenter, other > than a host to ping against. > > Miles Fidelman I've not compared the features of the products, but a possible alternative should be http://www.ookla.com/netgauge Karsten From xionox at gmail.com Sun May 17 21:06:31 2015 From: xionox at gmail.com (Arzhel Younsi) Date: Mon, 18 May 2015 09:06:31 +1200 Subject: Visualware/Speedtest self-hosting alternatives In-Reply-To: <5468724.hL1GFEGn8d@linne> References: <55588A98.2@meetinghouse.net> <5468724.hL1GFEGn8d@linne> Message-ID: <1431896791.1029839.271051697.5CFE4F9F@webmail.messagingengine.com> I think http://www.perfsonar.net/ does what you're looking for and more. -- Arzhel On Mon, May 18, 2015, at 03:39, Karsten Thomann wrote: > Hi > > Am Sonntag, 17. Mai 2015, 08:33:28 schrieb Miles Fidelman: > > Durga Dash wrote: > > > Hi, > > > Are there any turn key solutions out there like Visualware's MCS which you > > > can install in a datacenter and let customers check overall > > > throughput/latency and other metrics from their locations to the > > > datacenter? > > Didn't you just answer your own question? (Visualware MCS). > > > > Of course if all you're interested in is throughput and latency, there's > > ping, traceroute, mtr, iperf, etc. - all of which let customers check > > performance without needing anything special at the datacenter, other > > than a host to ping against. > > > > Miles Fidelman > > I've not compared the features of the products, but a possible > alternative should be > http://www.ookla.com/netgauge > > Karsten From nanog at ics-il.net Sun May 17 22:04:18 2015 From: nanog at ics-il.net (Mike Hammett) Date: Sun, 17 May 2015 17:04:18 -0500 (CDT) Subject: Hulu and HBO Message-ID: <31235299.4930.1431900277060.JavaMail.mhammett@ThunderFuck> When I fire up their streams, they come from Level3 IPs. Can anyone confirm that Hulu and HBO come from Level 3 and not just someone that has the box I was talking to on Level3's network? ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest Internet Exchange http://www.midwest-ix.com From magicsata at gmail.com Sun May 17 22:07:58 2015 From: magicsata at gmail.com (Alistair Mackenzie) Date: Sun, 17 May 2015 23:07:58 +0100 Subject: Hulu and HBO In-Reply-To: <31235299.4930.1431900277060.JavaMail.mhammett@ThunderFuck> References: <31235299.4930.1431900277060.JavaMail.mhammett@ThunderFuck> Message-ID: I know Netflix has caching boxes that the ISP can install. Perhaps Hulu and HBO have or do the same thing? On 17 May 2015 23:06, "Mike Hammett" wrote: > When I fire up their streams, they come from Level3 IPs. Can anyone > confirm that Hulu and HBO come from Level 3 and not just someone that has > the box I was talking to on Level3's network? > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > > > Midwest Internet Exchange > http://www.midwest-ix.com > > > From josh at spitwspots.com Sun May 17 22:33:30 2015 From: josh at spitwspots.com (Josh Reynolds) Date: Sun, 17 May 2015 14:33:30 -0800 Subject: Hulu and HBO In-Reply-To: References: <31235299.4930.1431900277060.JavaMail.mhammett@ThunderFuck> Message-ID: <7499FBD5-1ABE-4AB7-AD2E-1129B4C4225D@spitwspots.com> They do not. On May 17, 2015 2:07:58 PM AKDT, Alistair Mackenzie wrote: >I know Netflix has caching boxes that the ISP can install. Perhaps Hulu >and >HBO have or do the same thing? >On 17 May 2015 23:06, "Mike Hammett" wrote: > >> When I fire up their streams, they come from Level3 IPs. Can anyone >> confirm that Hulu and HBO come from Level 3 and not just someone that >has >> the box I was talking to on Level3's network? >> >> >> >> >> ----- >> Mike Hammett >> Intelligent Computing Solutions >> http://www.ics-il.com >> >> >> >> Midwest Internet Exchange >> http://www.midwest-ix.com >> >> >> -- Sent from my Android device with K-9 Mail. Please excuse my brevity. From josh at spitwspots.com Sun May 17 22:33:48 2015 From: josh at spitwspots.com (Josh Reynolds) Date: Sun, 17 May 2015 14:33:48 -0800 Subject: Hulu and HBO In-Reply-To: <31235299.4930.1431900277060.JavaMail.mhammett@ThunderFuck> References: <31235299.4930.1431900277060.JavaMail.mhammett@ThunderFuck> Message-ID: Mike, to test, change DNS. On May 17, 2015 2:04:18 PM AKDT, Mike Hammett wrote: >When I fire up their streams, they come from Level3 IPs. Can anyone >confirm that Hulu and HBO come from Level 3 and not just someone that >has the box I was talking to on Level3's network? > > > > >----- >Mike Hammett >Intelligent Computing Solutions >http://www.ics-il.com > > > >Midwest Internet Exchange >http://www.midwest-ix.com -- Sent from my Android device with K-9 Mail. Please excuse my brevity. From jesler at cisco.com Mon May 18 01:18:38 2015 From: jesler at cisco.com (Joel Esler (jesler)) Date: Mon, 18 May 2015 01:18:38 +0000 Subject: Hulu and HBO In-Reply-To: References: <31235299.4930.1431900277060.JavaMail.mhammett@ThunderFuck>, Message-ID: <88971206-9094-48DD-B9CA-863ED34500CD@cisco.com> I believe HBO is using MLB's network. -- Joel Esler Sent from my iPhone On May 17, 2015, at 6:38 PM, Josh Reynolds > wrote: Mike, to test, change DNS. On May 17, 2015 2:04:18 PM AKDT, Mike Hammett > wrote: When I fire up their streams, they come from Level3 IPs. Can anyone confirm that Hulu and HBO come from Level 3 and not just someone that has the box I was talking to on Level3's network? ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest Internet Exchange http://www.midwest-ix.com -- Sent from my Android device with K-9 Mail. Please excuse my brevity. From v.bajpai at jacobs-university.de Mon May 18 13:22:14 2015 From: v.bajpai at jacobs-university.de (Bajpai, Vaibhav) Date: Mon, 18 May 2015 13:22:14 +0000 Subject: survey on performance measurement platforms and related standards Message-ID: Dear NANOG, I would like to share something with you today. As you know, IETF LMAP [1] is making efforts to standardize large-scale measurements to allow divergent measurement platforms to converge towards interoperability. Early discussions within this group often lead to folks asking for feature sets and possibilities of each contemporary performance measurement platform. So we started digging literature work in this space and found that although there were surveys on topology-based measurement platforms (such CAIDA Ark et al.); literature work on performance measurement platforms (such as RIPE Atlas, SamKnows et al.) was missing. Therefore, we started writing such a survey in 2013 to plug this gap and also complement this with current state of IETF standardization efforts happening within the LMAP and IPPM working groups. This work got published and came online recently. I thought would share this with you: ----------------8<-----------------8<-----------------8<-----------------8< A Survey on Internet Performance Measurement Platforms and Related Standardization Efforts Vaibhav Bajpai, J?rgen Sch?nw?lder IEEE Communications Surveys & Tutorials April, 2015 A number of Internet measurement platforms have emerged in the last few years. These platforms have deployed thousands of probes at strategic locations within access and backbone networks and behind residential gateways. In this paper we provide a taxonomy of these measurement platforms on the basis of their deployment use-case. We describe these platforms in detail by exploring their coverage, scale, lifetime, deployed metrics and measurement tools, architecture and overall research impact. We conclude the survey by describing current standardization efforts to make large-scale performance measurement platforms interoperable. Author Copy: http://vaibhavbajpai.com/documents/papers/proceedings/lsmp-comst-2015.pdf DOI: http://dx.doi.org/10.1109/COMST.2015.2418435 ----------------8<-----------------8<-----------------8<-----------------8< Thanks! [1] https://datatracker.ietf.org/wg/lmap Best, Vaibhav ===================================================== Vaibhav Bajpai Research I, Room 91 Computer Networks and Distributed Systems (CNDS) Lab School of Engineering and Sciences Jacobs University Bremen, Germany www.vaibhavbajpai.com ===================================================== -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 496 bytes Desc: Message signed with OpenPGP using GPGMail URL: From ben.perkins at essensys.co.uk Mon May 18 09:58:28 2015 From: ben.perkins at essensys.co.uk (Ben Perkins) Date: Mon, 18 May 2015 09:58:28 +0000 Subject: IP Geolocation Message-ID: Hi, Last year we purchased a /22 IPv4 block through RIPE. Although most sites (including RIPE https://stat.ripe.net/185.57.92.0%2F22#tabId=at-a-glance) have updated the IP Geolocation for them to London, a few sites have yet to change and are blocking access to their sites based on this. The 2 main sites that we are having issues with are Amex and Paypal. We have opened tickets with them but are just being passed around and not really getting anywhere. Has anyone had experience of this before or know of a good contact at either to help get this resolved? Thanks in advance, Ben From gerardo.perales at axtel.com.mx Mon May 18 13:29:15 2015 From: gerardo.perales at axtel.com.mx (Jose Gerardo Perales Soto) Date: Mon, 18 May 2015 13:29:15 +0000 Subject: Visualware/Speedtest self-hosting alternatives In-Reply-To: References: Message-ID: Hi, we have used Visualware MCS for in-depth analysis of network impairments, and Ookla's NetGauge for customer facing speed tests up to Gigabit speeds. Gerardo -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Durga Dash Sent: viernes, 15 de mayo de 2015 10:32 a.m. To: nanog at nanog.org Subject: Visualware/Speedtest self-hosting alternatives Hi, Are there any turn key solutions out there like Visualware's MCS which you can install in a datacenter and let customers check overall throughput/latency and other metrics from their locations to the datacenter? Thanks Durga. ________________________________ El contenido del presente correo electr?nico es de car?cter confidencial, privado y propiedad de AXTEL, S.A.B. de C.V., por lo que en caso de haber recibido el presente por error, o de no ser el destinatario del mismo, por favor h?galo saber al remitente, e igualmente elimine y no almacene en forma alguna la informaci?n aqu? contenida. As? mismo, el contenido del presente correo no genera obligaci?n alguna a cargo de AXTEL, S.A.B. de C.V., de cualquiera de sus subsidiarias o del remitente. From richb.hanover at gmail.com Mon May 18 13:59:51 2015 From: richb.hanover at gmail.com (Rich Brown) Date: Mon, 18 May 2015 09:59:51 -0400 Subject: Visualware/Speedtest self-hosting alternatives In-Reply-To: References: Message-ID: > Hi, > Are there any turn key solutions out there like Visualware's MCS which you can install in a datacenter and let customers check overall throughput/latency and other metrics from their locations to the datacenter? I think someone also mentioned M-LAB but I didn't see the URL. They're at: http://www.measurementlab.net/tests This one isn't self-hosted, but I like it a lot: DSL Reports Speed Test http://dslreports.com/speedtest Rich From nicholas.schmidt at controlgroup.com Mon May 18 16:30:04 2015 From: nicholas.schmidt at controlgroup.com (Nicholas Schmidt) Date: Mon, 18 May 2015 12:30:04 -0400 Subject: ARO Security Message-ID: I cant find a way to reach out to whoever manages ARO directly so I figure it would be best to publish this to the list. We are a group of network operators who are failing at enforcing extremely basic security in our own applications. 1.) Retrieving an ARO password sends a plain text email of your current password. Im sure this is minor as its just ARO and none of us would ever re-use a password in more critical systems. 2.) The SSL cert for secretariat.nanog.org is invalid. It looks to be trying to use the wildcard for amsl.com $ openssl s_client -showcerts -connect secretariat.nanog.org:443 CONNECTED(00000003) depth=0 /OU=Domain Control Validated/CN=*.amsl.com verify error:num=20:unable to get local issuer certificate verify return:1 depth=0 /OU=Domain Control Validated/CN=*.amsl.com verify error:num=27:certificate not trusted verify return:1 depth=0 /OU=Domain Control Validated/CN=*.amsl.com verify error:num=21:unable to verify the first certificate verify return:1 --- Certificate chain 0 s:/OU=Domain Control Validated/CN=*.amsl.com i:/C=US/ST=Arizona/L=Scottsdale/O=Starfield Technologies, Inc./OU= http://certs.starfieldtech.com/repository//CN=Starfield Secure Certificate Authority - G2 From dveit at microsoft.com Mon May 18 16:57:59 2015 From: dveit at microsoft.com (Darrin Veit) Date: Mon, 18 May 2015 16:57:59 +0000 Subject: Usage of Teredo and IPv6 for P2P on Windows 10 and Xbox One Message-ID: Hi Everyone - We've had very fruitful discussions with members of this community on Xbox One networking behavior, in particular concerning P2P multiplayer gaming activity. In an effort to continue that useful dialogue, we wanted to provide an informational update for Xbox One, but also share relevant details on upcoming Windows functionality in terms of Teredo and IPv6 usage. We also include some observations about IPv4 and IPv6 health that may be broadly interesting, especially as it pertains to network readiness for Xbox multiplayer via IPv6. New Xbox experiences launching on Windows 10 will use Teredo for P2P communications -------------------- Earlier this year we announced some Xbox functionality coming to Windows 10. One key feature of Windows 10 is enabling multiplayer gaming and chat functionality between Xbox One consoles and Windows 10 devices. This functionality on Windows 10 will behave similarly to how multiplayer works today on Xbox One, using Teredo for NAT traversal and IPsec for security. When used for Xbox Live enabled experiences, the Windows 10 Teredo client will prefer originating traffic from the IANA-registered port, 3074, when available. More detailed guidance on Xbox One behavior is linked at the bottom of this email. It also should be noted that Windows supports a broad range of applications and a huge portfolio of great games outside of the Xbox Live ecosystem. In general, Microsoft encourages broad adoption of the recommendations in RFC 4787, RFC 6092, and RFC 6888 to maximize the viability of P2P technologies for all. IPv4's P2P health is degrading -------------------- Qualitative and quantitative evidence available to us indicates that overall availability of functioning P2P connectivity on the IPv4 Internet is decreasing over time. In particular we are concerned that IPv4 address scarcity is forcing many small and medium market network operators to deploy carrier-grade NAT functionality. This often results in end-users being intractably stuck behind "strict" networks with degraded multiplayer experiences as a result. Healthy, standards-compliant IPv6 access is broadly needed, sooner rather than later. However, we have identified a few areas of concern in regard to IPv6 support that will hinder the efficacy of enabling multiplayer on IPv6. IPv6 is being deployed, but not perfectly, jeopardizing IPv6 P2P --------------------- Across the Xbox One customer base, in particular for customers who play multiplayer games, we observe that a substantial minority (around 20%) of devices have native IPv6 configured. This represents a much higher IPv6 penetration rate than Microsoft's other products and services report, as well as public data from other sources. However we have numerous concerns about IPv6's growth. We are often finding that retail customer premise equipment is configured with IPv6 disabled by default, requiring user action to enable. We've also encountered a very small set of reports where IPv6 latency and bandwidth performance are suboptimal compared to IPv4. Reports of this nature have usually focused on streaming media experiences and user concern that IPv6 is slower than IPv4 (i.e. "I get 1080P resolution with IPv4, and 720P with IPv6"). In the rare cases where these reports have been substantiated, the primary culprit has been differences in deployed CDN support. Also, some networking hardware and operators apply firewall policy to the IPv6 path contrary to RFC 6092 recommendations. Of particular concern are configurations where unsolicited inbound IKE/IPsec traffic is not permitted in the default operating mode. Growth of these non-conformant configurations puts the P2P benefit of the next generation Internet in jeopardy. It would be incredibly regrettable if IPv6 necessitated the high level of configuration and inefficiency currently required for IPv4. Deprecating public Teredo servers for Windows Vista and Windows 7 -------------------- On May 4th, 2015, we began deactivating Microsoft's publicly available Teredo servers currently configured as the default servers for Windows Vista and Windows 7 clients. This is a result of limited usage on those platforms and our desire to focus our operations on Xbox One and Windows 10. If you read this far, you are awesome. We will likely request a NANOG presentation slot later in the year to discuss these points, but we want to make sure we have sufficiently interesting and new things to discuss before swallowing up people's time. Network operators and CPE manufactures are encouraged to reach out to our team at xboxteredo at microsoft.com with operational questions. Please note that our most common reply will be "better documentation is coming later in the year," but we will try our best to respond to questions quickly. Thanks for your time, Darrin Veit & Christopher Palmer Xbox Platform Networking Operating System Group Current Xbox One Multiplayer Networking Guidance ------------------------- http://download.microsoft.com/download/A/C/4/AC4484B8-AA16-446F-86F8-BDFC498F8732/Xbox%20One%20Technical%20Details.docx From md at Linux.IT Mon May 18 18:04:14 2015 From: md at Linux.IT (Marco d'Itri) Date: Mon, 18 May 2015 20:04:14 +0200 Subject: Spamhaus BGP feed experiences? In-Reply-To: References: Message-ID: <20150518180414.GC13453@bongo.bofh.it> On May 17, Mike Lyon wrote: > Any ISPs out there (big or small) ever used the Spamhaus BGP feed to > prevent against botnet, spam, etc? If so, how has your experience been? Is > it worthwhile? Has it helped? On / off list responses are appreciated in > advance. We use Spamhaus DROP (not the BGP version: our software asks a human to review each change). The benefits are not obvious since we do not have access customers, but it will blackhole some networks you obviously do not want to talk to, and it has not caused any troubles either. -- ciao, Marco -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 648 bytes Desc: not available URL: From jared at puck.Nether.net Mon May 18 18:04:45 2015 From: jared at puck.Nether.net (Jared Mauch) Date: Mon, 18 May 2015 14:04:45 -0400 Subject: Usage of Teredo and IPv6 for P2P on Windows 10 and Xbox One In-Reply-To: References: Message-ID: <20150518180445.GB15755@puck.nether.net> On Mon, May 18, 2015 at 04:57:59PM +0000, Darrin Veit wrote: > > IPv6 is being deployed, but not perfectly, jeopardizing IPv6 P2P > --------------------- > Across the Xbox One customer base, in particular for customers who play multiplayer games, we observe that a substantial minority (around 20%) of devices have native IPv6 configured. This represents a much higher IPv6 penetration rate than Microsoft's other products and services report, as well as public data from other sources. > > However we have numerous concerns about IPv6's growth. We are often finding that retail customer premise equipment is configured with IPv6 disabled by default, requiring user action to enable. I'm curious how this compares with how the xbox live breaks with "xbox strict nat" which has been quite catastrophic for users in IPv4 land that may sit behind one or more cascaded NATs where UPnP is not available or may trigger the wrong tier. (This is more common in areas where access is via WISP). That seems to be a long unaddressed or rejected problem from the customer perspective. > We've also encountered a very small set of reports where IPv6 latency and bandwidth performance are suboptimal compared to IPv4. Reports of this nature have usually focused on streaming media experiences and user concern that IPv6 is slower than IPv4 (i.e. "I get 1080P resolution with IPv4, and 720P with IPv6"). In the rare cases where these reports have been substantiated, the primary culprit has been differences in deployed CDN support. This is not Microsofts problem unless you are contracting with the CDN. The CDN should address this gap by placing devices on network that can properly dual-stack only. IPv6 for those last-mile-networks has been a solved problem for quite some time. > Also, some networking hardware and operators apply firewall policy to the IPv6 path contrary to RFC 6092 recommendations. Of particular concern are configurations where unsolicited inbound IKE/IPsec traffic is not permitted in the default operating mode. Growth of these non-conformant configurations puts the P2P benefit of the next generation Internet in jeopardy. It would be incredibly regrettable if IPv6 necessitated the high level of configuration and inefficiency currently required for IPv4. Many self-appointed IT experts have shot themselves in the foot in this regard. After 5+ years of trying to get sensible pMTU working inside an organization, or get IPv6 there people need to undertake other methods to address these shortcomings. Stateful inspection devices (or packet eaters as I call them) improperly generate spurious warnings when they are presented with data they don't understand or expect. Take a look at what happened when the Linux kernel made TCP-ECN the default, many firewalls blocked a perfectly valid TCP option and broke large number of mail servers. 20 years ago it would be feasible to shame these people into upgrading or standards compliance, but the race to be the worst continues. > Deprecating public Teredo servers for Windows Vista and Windows 7 > -------------------- > On May 4th, 2015, we began deactivating Microsoft's publicly available Teredo servers currently configured as the default servers for Windows Vista and Windows 7 clients. This is a result of limited usage on those platforms and our desire to focus our operations on Xbox One and Windows 10. > > If you read this far, you are awesome. > > We will likely request a NANOG presentation slot later in the year to discuss these points, but we want to make sure we have sufficiently interesting and new things to discuss before swallowing up people's time. If you can keep the content in ~10 minutes, a lightning talk may still fit for the upcoming NANOG. > Network operators and CPE manufactures are encouraged to reach out to our team at xboxteredo at microsoft.com with operational questions. Please note that our most common reply will be "better documentation is coming later in the year," but we will try our best to respond to questions quickly. Is there a good way to contact CPE vendors about issues? I have a large dataset showing how bad they are at various things, including responding with REFUSED for valid rfc1035 complaint DNS packets breaking customer experiences in nasty ways. I have large datasets I'm willing to share showing the information discloure your home CPE performs due to poorly coded dnsmasq, iptables and other defaults on these devices which are never updated/maintained. I've been looking for a research team that has the time to undertake this effort of documenting things and pushing for broad scale recommendations and fixes. With the desires of the homenet WG at IETF to make the complex layers of networks even harder to address, we need to fix the vendors sooner vs later otherwise the pollution will get worse. - Jared -- Jared Mauch | pgp key available via finger from jared at puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine. From eric.oosting at gmail.com Mon May 18 19:59:49 2015 From: eric.oosting at gmail.com (Eric Oosting) Date: Mon, 18 May 2015 15:59:49 -0400 Subject: ARO Security In-Reply-To: References: Message-ID: On Mon, May 18, 2015 at 12:30 PM, Nicholas Schmidt < nicholas.schmidt at controlgroup.com> wrote: > I cant find a way to reach out to whoever manages ARO directly so I figure > it would be best to publish this to the list. > Nicholas, It's normally a good idea to email any questions you have to nanog-support at nanog.org. They should always get you an answer or point you in the correct direction. We are a group of network operators who are failing at enforcing extremely > basic security in our own applications. > > 1.) Retrieving an ARO password sends a plain text email of your current > password. Im sure this is minor as its just ARO and none of us would ever > re-use a password in more critical systems. > This is a known problem and I assure you NANOG is working with their vendor to address it. > > 2.) The SSL cert for secretariat.nanog.org is invalid. It looks to be > trying to use the wildcard for amsl.com I'm curious what is going on, but I wonder if it doesn't have something to do with the openssl command you've entered below. When using firefox, chrome, or safari from my laptop and internet explorer from within a VM, I'm being offered the *.nanog.org wildcard cert, not an amsl.com cert. I checked a popular online ssl certificate checker and similarly received the proper certificate. Are you receiving a certificate error of some type in your browser? If so, let's take the conversation off of nanog to spare the list. -e > > $ openssl s_client -showcerts -connect secretariat.nanog.org:443 > > CONNECTED(00000003) > > depth=0 /OU=Domain Control Validated/CN=*.amsl.com > > verify error:num=20:unable to get local issuer certificate > > verify return:1 > > depth=0 /OU=Domain Control Validated/CN=*.amsl.com > > verify error:num=27:certificate not trusted > > verify return:1 > > depth=0 /OU=Domain Control Validated/CN=*.amsl.com > > verify error:num=21:unable to verify the first certificate > > verify return:1 > > --- > > Certificate chain > > 0 s:/OU=Domain Control Validated/CN=*.amsl.com > > i:/C=US/ST=Arizona/L=Scottsdale/O=Starfield Technologies, Inc./OU= > http://certs.starfieldtech.com/repository//CN=Starfield Secure Certificate > Authority - G2 > From randy at psg.com Mon May 18 20:40:45 2015 From: randy at psg.com (Randy Bush) Date: Mon, 18 May 2015 10:40:45 -1000 Subject: ARO Security In-Reply-To: References: Message-ID: i too get the amsl cert in response to an opelssl cert query with a bog standard starfield class 2 chain % openssl s_client -connect secretariat.nanog.org:443 CONNECTED(00000003) depth=0 /OU=Domain Control Validated/CN=*.amsl.com verify error:num=20:unable to get local issuer certificate verify return:1 depth=0 /OU=Domain Control Validated/CN=*.amsl.com verify error:num=27:certificate not trusted verify return:1 depth=0 /OU=Domain Control Validated/CN=*.amsl.com verify error:num=21:unable to verify the first certificate verify return:1 --- Certificate chain 0 s:/OU=Domain Control Validated/CN=*.amsl.com i:/C=US/ST=Arizona/L=Scottsdale/O=Starfield Technologies, Inc./OU=http://certs.starfieldtech.com/repository//CN=Starfield Secure Certificate Authority - G2 1 s:/C=US/ST=Arizona/L=Scottsdale/O=Starfield Technologies, Inc./OU=http://certificates.starfieldtech.com/repository/CN=Starfield Secure Certification Authority/serialNumber=10688435 i:/C=US/O=Starfield Technologies, Inc./OU=Starfield Class 2 Certification Authority 2 s:/C=US/O=Starfield Technologies, Inc./OU=Starfield Class 2 Certification Authority i:/C=US/O=Starfield Technologies, Inc./OU=Starfield Class 2 Certification Authority --- Server certificate -----BEGIN CERTIFICATE----- MIIGRDCCBSygAwIBAgIJAInJ3xG7x0IgMA0GCSqGSIb3DQEBCwUAMIHGMQswCQYD with chrome, https://secretariat.nanog.org gets me a redirect to the insecure http://www.nanog.org/ (note lack of 's') via the tls-failing cert, see above > let's take the conversation off of nanog to spare the list. one of the purposes of this list is for us to learn from eachother. in this case, techniques for diagnosing tls & cert issues are worth sharing. [ sadly, folk with bugs love to redirect discussion off public media ] randy From christopher.morrow at gmail.com Mon May 18 20:48:32 2015 From: christopher.morrow at gmail.com (Christopher Morrow) Date: Mon, 18 May 2015 16:48:32 -0400 Subject: A Canonical answer requested (AS41231) Message-ID: if there's a canonical neteng/ops person around it'd be handy to get a contact off-list :) I have a question to ask... about bgp and paths and fun stuff such as that! (probably a traceroute or 'show ip bgp' would suffice from their perspective) -chris From bill at herrin.us Mon May 18 20:49:11 2015 From: bill at herrin.us (William Herrin) Date: Mon, 18 May 2015 16:49:11 -0400 Subject: ARO Security In-Reply-To: References: Message-ID: On Mon, May 18, 2015 at 3:59 PM, Eric Oosting wrote: > On Mon, May 18, 2015 at 12:30 PM, Nicholas Schmidt < > nicholas.schmidt at controlgroup.com> wrote: >> 2.) The SSL cert for secretariat.nanog.org is invalid. It looks to be >> trying to use the wildcard for amsl.com > > > I'm curious what is going on, but I wonder if it doesn't have something to > do with the openssl command you've entered below. > >> $ openssl s_client -showcerts -connect secretariat.nanog.org:443 Hi Eric, It does and it doesn't. The following openssl command gets the correct cert: openssl s_client -servername secretariat.nanog.org -showcerts -connect secretariat.nanog.org:443 The -servername parameter tells openssl to use the SSL Server Name Indication extension. This allows multiple HTTPS web sites to live on the same IP address much as the HTTP 1.1 Host header allowed multiple regular HTTP web sites to live on the same IP address. All "modern" web browsers support SNI. "Modern" doesn't go back terribly far. "Older" implementations of HTTPS will get the wrong certificate as shown. So, if you want to maximize compatibility, have a talk with your vendor about a dedicated IP address for your HTTPS server. Otherwise, make a note in your documentation that SSL clients must support the SNI extension to use the web site. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: From morrowc.lists at gmail.com Mon May 18 20:50:33 2015 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Mon, 18 May 2015 16:50:33 -0400 Subject: ARO Security In-Reply-To: References: Message-ID: On Mon, May 18, 2015 at 4:40 PM, Randy Bush wrote: >> let's take the conversation off of nanog to spare the list. > > one of the purposes of this list is for us to learn from eachother. in > this case, techniques for diagnosing tls & cert issues are worth > sharing. [ sadly, folk with bugs love to redirect discussion off public > media ] $ openssl s_client -servername www.nanog.org -connect www.nanog.org:443 CONNECTED(00000003) depth=3 C = US, O = "The Go Daddy Group, Inc.", OU = Go Daddy Class 2 Certification Authority .... stuff.... subject=/OU=Domain Control Validated/CN=*.nanog.org issuer=/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc./OU=http://certs.godaddy.com/repository//CN=Go Daddy Secure Certificate Authority - G2 .... stuff ..... (I think you need to send along: -servername) From randy at psg.com Mon May 18 20:54:10 2015 From: randy at psg.com (Randy Bush) Date: Mon, 18 May 2015 10:54:10 -1000 Subject: ARO Security In-Reply-To: References: Message-ID: of course, this begs the question of why one would try to go to https://secretariat.nanog.org/. it is published as a supported web site? randy From randy at psg.com Mon May 18 21:05:55 2015 From: randy at psg.com (Randy Bush) Date: Mon, 18 May 2015 11:05:55 -1000 Subject: ARO Security In-Reply-To: References: Message-ID: > (I think you need to send along: -servername) point % openssl s_client -servername secretariat.nanog.org -connect secretariat.nanog.org:443 CONNECTED(00000003) depth=3 /C=US/O=The Go Daddy Group, Inc./OU=Go Daddy Class 2 Certification Authority verify error:num=19:self signed certificate in certificate chain verify return:0 --- Certificate chain 0 s:/OU=Domain Control Validated/CN=*.nanog.org i:/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc./OU=http://certs.godaddy.com/repository//CN=Go Daddy Secure Certificate Authority - G2 1 s:/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc./OU=http://certs.godaddy.com/repository//CN=Go Daddy Secure Certificate Authority - G2 i:/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc./CN=Go Daddy Root Certificate Authority - G2 2 s:/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc./CN=Go Daddy Root Certificate Authority - G2 i:/C=US/O=The Go Daddy Group, Inc./OU=Go Daddy Class 2 Certification Authority 3 s:/C=US/O=The Go Daddy Group, Inc./OU=Go Daddy Class 2 Certification Authority i:/C=US/O=The Go Daddy Group, Inc./OU=Go Daddy Class 2 Certification Authority --- Server certificate -----BEGIN CERTIFICATE----- mehr be?er From marka at isc.org Mon May 18 22:25:53 2015 From: marka at isc.org (Mark Andrews) Date: Tue, 19 May 2015 08:25:53 +1000 Subject: Usage of Teredo and IPv6 for P2P on Windows 10 and Xbox One In-Reply-To: Your message of "Mon, 18 May 2015 14:04:45 -0400." <20150518180445.GB15755@puck.nether.net> References: <20150518180445.GB15755@puck.nether.net> Message-ID: <20150518222554.1DE0C2E84F68@rock.dv.isc.org> In message <20150518180445.GB15755 at puck.nether.net>, Jared Mauch writes: > On Mon, May 18, 2015 at 04:57:59PM +0000, Darrin Veit wrote: > > > Also, some networking hardware and operators apply firewall policy to > > the IPv6 path contrary to RFC 6092 recommendations. Of particular concern > > are configurations where unsolicited inbound IKE/IPsec traffic is not > > permitted in the default operating mode. Growth of these non-conformant > > configurations puts the P2P benefit of the next generation Internet in > > jeopardy. It would be incredibly regrettable if IPv6 necessitated the > > high level of configuration and inefficiency currently required for IPv4. > > Many self-appointed IT experts have shot themselves in the foot > in this regard. After 5+ years of trying to get sensible pMTU working > inside an organization, or get IPv6 there people need to undertake other > methods to address these shortcomings. Stateful inspection devices > (or packet eaters as I call them) improperly generate spurious warnings > when they are presented with data they don't understand or expect. And they also eat DNS packets with "unexpected" DNS opcodes. They eat DNS packets with EDNS version != 0. They eat DNS packets with a EDNS flag set that is not DO. They eat DNS packets with EDNS options (less so than EDNS version != 0 or EDNS flag). Different != bad. Different != malformed. Different should not equal drop. Nameservers return NOTIMP (RFC 103[45]), BADVER or ignore and ignore (RFC 6891) respectively. There are no valid reasons to stop any of these extensions getting through to the nameserver as they handle them. 25 years ago blocking these may have been "reasonable" as some implementations were not up to scratch but we are not in the 1990's anymore. Nameservers have been attacked to 25 years. They have been hardened over that period. All dropping a so called "bad" DNS packets does is make it harder to deploy extensions. It doesn't save the nameserver. It doesn't "protect" the nameserver. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From christopher.morrow at gmail.com Tue May 19 02:59:19 2015 From: christopher.morrow at gmail.com (Christopher Morrow) Date: Mon, 18 May 2015 22:59:19 -0400 Subject: A Canonical answer requested (AS41231) In-Reply-To: References: Message-ID: oh hai! someone found me :) and he's been super helpful... so, in the future I hope other folk that might have (or think they have) issues to pipe up :) -chris On Mon, May 18, 2015 at 4:48 PM, Christopher Morrow wrote: > if there's a canonical neteng/ops person around it'd be handy to get a > contact off-list :) I have a question to ask... about bgp and paths > and fun stuff such as that! > > (probably a traceroute or 'show ip bgp' would suffice from their perspective) > > -chris From swhyte at gmail.com Tue May 19 04:42:08 2015 From: swhyte at gmail.com (Scott Whyte) Date: Mon, 18 May 2015 21:42:08 -0700 Subject: A Canonical answer requested (AS41231) In-Reply-To: References: Message-ID: <555ABF20.8070902@gmail.com> Would a prototypical neteng suffice? On 5/18/15 13:48, Christopher Morrow wrote: > if there's a canonical neteng/ops person around it'd be handy to get a > contact off-list :) I have a question to ask... about bgp and paths > and fun stuff such as that! > > (probably a traceroute or 'show ip bgp' would suffice from their perspective) > > -chris > From christopher.morrow at gmail.com Tue May 19 04:56:09 2015 From: christopher.morrow at gmail.com (Christopher Morrow) Date: Tue, 19 May 2015 00:56:09 -0400 Subject: A Canonical answer requested (AS41231) In-Reply-To: <555ABF20.8070902@gmail.com> References: <555ABF20.8070902@gmail.com> Message-ID: On Tue, May 19, 2015 at 12:42 AM, Scott Whyte wrote: > Would a prototypical neteng suffice? > found one! :) (james from canonical found me earlier, he was great) > > On 5/18/15 13:48, Christopher Morrow wrote: >> >> if there's a canonical neteng/ops person around it'd be handy to get a >> contact off-list :) I have a question to ask... about bgp and paths >> and fun stuff such as that! >> >> (probably a traceroute or 'show ip bgp' would suffice from their >> perspective) >> >> -chris >> > From frederik at kriewitz.eu Tue May 19 10:48:28 2015 From: frederik at kriewitz.eu (Frederik Kriewitz) Date: Tue, 19 May 2015 12:48:28 +0200 Subject: Spamhaus BGP feed experiences? In-Reply-To: References: Message-ID: On Sun, May 17, 2015 at 7:50 AM, Mike Lyon wrote: > Any ISPs out there (big or small) ever used the Spamhaus BGP feed to > prevent against botnet, spam, etc? If so, how has your experience been? Is > it worthwhile? Has it helped? On / off list responses are appreciated in > advance. We've been using the BGP feed for a little over a year now. We had some problems with malware infected end user PCs causing upstream congestion resulting in "slow internet" complains. The spamhouse feed definitely helped a little with our problem but it's not the magic super tool to completely stop malware in your network. On the other hand there was no complain due to a false positive (a couple of years ago we had one complain due to a false positive on the EDROP list). Best Regards, Frederik Kriewitz From ryanshea at google.com Tue May 19 15:53:15 2015 From: ryanshea at google.com (Ryan Shea) Date: Tue, 19 May 2015 15:53:15 +0000 Subject: Unified Security Vulnerability Management Message-ID: Manually setting up and parsing email notifications for security vulnerabilities for all vendors is mighty annoying. It looks like the ICASI CVRF Working Group thought the same thing back in 2011 when they came up with this handy XML schema. I had not known of this until yesterday and noticed that Cisco does a good job posting their vulnerabilities in CVRF. Word on the streets is that Juniper was at least partially involved in CVRF as well. Brocade may have looked into it as well. This does not seem like a difficult thing for vendors to do, but the missing piece may be customer interest. I am hoping to drum up some interest here -- maybe a few support requests would entice them to hand this off to an intern and we could collectively do better at managing vendor notifications. A tool to parse CVRF is already floating about as well (mschiffm). From colton.conor at gmail.com Tue May 19 17:22:45 2015 From: colton.conor at gmail.com (Colton Conor) Date: Tue, 19 May 2015 12:22:45 -0500 Subject: Low Cost 10G Router Message-ID: What options are available for a small, low cost router that has at least four 10G ports, and can handle full BGP routes? All that I know of are the Juniper MX80, and the Brocade CER line. What does Cisco and others have that compete with these two? Any other vendors besides Juniper, Brocade, and Cisco to look at? From mehmet at akcin.net Tue May 19 17:24:16 2015 From: mehmet at akcin.net (Mehmet Akcin) Date: Tue, 19 May 2015 10:24:16 -0700 Subject: Low Cost 10G Router In-Reply-To: References: Message-ID: <5D499B18-1134-43CD-8B09-9118E3CACAEA@akcin.net> How much is "low cost"? Mehmet > On May 19, 2015, at 10:22, Colton Conor wrote: > > What options are available for a small, low cost router that has at least > four 10G ports, and can handle full BGP routes? All that I know of are the > Juniper MX80, and the Brocade CER line. What does Cisco and others have > that compete with these two? Any other vendors besides Juniper, Brocade, > and Cisco to look at? From rcarpen at network1.net Tue May 19 17:31:10 2015 From: rcarpen at network1.net (Randy Carpenter) Date: Tue, 19 May 2015 13:31:10 -0400 (EDT) Subject: Low Cost 10G Router In-Reply-To: References: Message-ID: <668594132.54443.1432056670987.JavaMail.zimbra@network1.net> If you are considering Juniper, check out the MX104. There are bundles currently that give you similar capacity to an MX80 at a significantly lower price. thanks, -Randy ----- On May 19, 2015, at 1:22 PM, Colton Conor colton.conor at gmail.com wrote: > What options are available for a small, low cost router that has at least > four 10G ports, and can handle full BGP routes? All that I know of are the > Juniper MX80, and the Brocade CER line. What does Cisco and others have > that compete with these two? Any other vendors besides Juniper, Brocade, > and Cisco to look at? From rafael at gav.ufsc.br Tue May 19 17:32:08 2015 From: rafael at gav.ufsc.br (Rafael Possamai) Date: Tue, 19 May 2015 12:32:08 -0500 Subject: Low Cost 10G Router In-Reply-To: References: Message-ID: Here is what I found on Google about Cisco's options: http://www.cisco.com/c/en/us/products/routers/asr-1000-series-aggregation-services-routers/models-comparison.html And when it comes to Juniper, you might be able to get it done with MX40 (look at their options, there are different combinations of chassis and cards), and you can always upgrade to a MX80 later. Just not sure you can find anything low cost when you need to route 10gbps. On Tue, May 19, 2015 at 12:22 PM, Colton Conor wrote: > What options are available for a small, low cost router that has at least > four 10G ports, and can handle full BGP routes? All that I know of are the > Juniper MX80, and the Brocade CER line. What does Cisco and others have > that compete with these two? Any other vendors besides Juniper, Brocade, > and Cisco to look at? > From rafael at gav.ufsc.br Tue May 19 17:34:24 2015 From: rafael at gav.ufsc.br (Rafael Possamai) Date: Tue, 19 May 2015 12:34:24 -0500 Subject: Low Cost 10G Router In-Reply-To: References: Message-ID: Oops, Cisco ASR 1k series might not cut it, you can take a look at their 9k seriers: http://www.cisco.com/c/en/us/products/routers/asr-9000-series-aggregation-services-routers/models-comparison.html On Tue, May 19, 2015 at 12:22 PM, Colton Conor wrote: > What options are available for a small, low cost router that has at least > four 10G ports, and can handle full BGP routes? All that I know of are the > Juniper MX80, and the Brocade CER line. What does Cisco and others have > that compete with these two? Any other vendors besides Juniper, Brocade, > and Cisco to look at? > From colton.conor at gmail.com Tue May 19 17:35:12 2015 From: colton.conor at gmail.com (Colton Conor) Date: Tue, 19 May 2015 12:35:12 -0500 Subject: Low Cost 10G Router In-Reply-To: <5D499B18-1134-43CD-8B09-9118E3CACAEA@akcin.net> References: <5D499B18-1134-43CD-8B09-9118E3CACAEA@akcin.net> Message-ID: As low as possible, though I am not sure how low that can be. For example, I can get a MX480 used with a 4 10G card for $16K. That would easily handle my needs, but it's overkill for what we need to do. I would love a solution under 10K, but not sure if one exists. On Tue, May 19, 2015 at 12:24 PM, Mehmet Akcin wrote: > How much is "low cost"? > > Mehmet > > > On May 19, 2015, at 10:22, Colton Conor wrote: > > > > What options are available for a small, low cost router that has at least > > four 10G ports, and can handle full BGP routes? All that I know of are > the > > Juniper MX80, and the Brocade CER line. What does Cisco and others have > > that compete with these two? Any other vendors besides Juniper, Brocade, > > and Cisco to look at? > From snoble at sonn.com Tue May 19 17:40:18 2015 From: snoble at sonn.com (Steve Noble) Date: Tue, 19 May 2015 10:40:18 -0700 Subject: Low Cost 10G Router In-Reply-To: References: Message-ID: <555B7582.80305@sonn.com> You could potentially do it with a Vyatta 5600 or a 6Wind Turbo router running on a generic server, but I am not sure where the cost crossover is with physical hardware especially if you go with used hardware. > Colton Conor > May 19, 2015 at 10:22 AM > What options are available for a small, low cost router that has at least > four 10G ports, and can handle full BGP routes? All that I know of are the > Juniper MX80, and the Brocade CER line. What does Cisco and others have > that compete with these two? Any other vendors besides Juniper, Brocade, > and Cisco to look at? From colinj at gt86car.org.uk Tue May 19 17:48:43 2015 From: colinj at gt86car.org.uk (Colin Johnston) Date: Tue, 19 May 2015 18:48:43 +0100 Subject: Low Cost 10G Router In-Reply-To: <555B7582.80305@sonn.com> References: <555B7582.80305@sonn.com> Message-ID: <94096B8D-9C8D-4BD7-8A39-372544FABCA9@gt86car.org.uk> If you want virtual 10gb ports go vmware with a cisco routing vm or juniper routing vm Colin > On 19 May 2015, at 18:40, Steve Noble wrote: > > You could potentially do it with a Vyatta 5600 or a 6Wind Turbo router > running on a generic server, but I am not sure where the cost crossover > is with physical hardware especially if you go with used hardware. > >> Colton Conor >> May 19, 2015 at 10:22 AM >> What options are available for a small, low cost router that has at least >> four 10G ports, and can handle full BGP routes? All that I know of are the >> Juniper MX80, and the Brocade CER line. What does Cisco and others have >> that compete with these two? Any other vendors besides Juniper, Brocade, >> and Cisco to look at? From maxtul at netassist.ua Tue May 19 17:58:24 2015 From: maxtul at netassist.ua (Max Tulyev) Date: Tue, 19 May 2015 20:58:24 +0300 Subject: Low Cost 10G Router In-Reply-To: References: Message-ID: <555B79C0.5080207@netassist.ua> We are using softrouters based on Supermicro chassis, E5v3 cpu, Linux/BIRD and Intel 10G NICs. And VERY happy. On 19.05.15 20:22, Colton Conor wrote: > What options are available for a small, low cost router that has at least > four 10G ports, and can handle full BGP routes? All that I know of are the > Juniper MX80, and the Brocade CER line. What does Cisco and others have > that compete with these two? Any other vendors besides Juniper, Brocade, > and Cisco to look at? > From ahebert at pubnix.net Tue May 19 18:02:12 2015 From: ahebert at pubnix.net (Alain Hebert) Date: Tue, 19 May 2015 14:02:12 -0400 Subject: Low Cost 10G Router In-Reply-To: <668594132.54443.1432056670987.JavaMail.zimbra@network1.net> References: <668594132.54443.1432056670987.JavaMail.zimbra@network1.net> Message-ID: <555B7AA4.5010808@pubnix.net> Well, Hardly low cost =D ----- Alain Hebert ahebert at pubnix.net PubNIX Inc. 50 boul. St-Charles P.O. Box 26770 Beaconsfield, Quebec H9W 6G7 Tel: 514-990-5911 http://www.pubnix.net Fax: 514-990-9443 On 05/19/15 13:31, Randy Carpenter wrote: > If you are considering Juniper, check out the MX104. There are bundles currently that give you similar capacity to an MX80 at a significantly lower price. > > thanks, > -Randy > > > ----- On May 19, 2015, at 1:22 PM, Colton Conor colton.conor at gmail.com wrote: > >> What options are available for a small, low cost router that has at least >> four 10G ports, and can handle full BGP routes? All that I know of are the >> Juniper MX80, and the Brocade CER line. What does Cisco and others have >> that compete with these two? Any other vendors besides Juniper, Brocade, >> and Cisco to look at? > From Daniel.Jameson at tdstelecom.com Tue May 19 18:08:11 2015 From: Daniel.Jameson at tdstelecom.com (Jameson, Daniel) Date: Tue, 19 May 2015 18:08:11 +0000 Subject: Low Cost 10G Router In-Reply-To: References: Message-ID: What's the application, and what traffic levels do you anticipate. Any special features like MPLS or MPLS-TE? -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Colton Conor Sent: Tuesday, May 19, 2015 12:23 PM To: NANOG Subject: Low Cost 10G Router What options are available for a small, low cost router that has at least four 10G ports, and can handle full BGP routes? All that I know of are the Juniper MX80, and the Brocade CER line. What does Cisco and others have that compete with these two? Any other vendors besides Juniper, Brocade, and Cisco to look at? From holbor at sonss.net Tue May 19 18:09:25 2015 From: holbor at sonss.net (Richard Holbo) Date: Tue, 19 May 2015 11:09:25 -0700 Subject: Low Cost 10G Router In-Reply-To: References: Message-ID: Huawei NE40E-X1-M4 I've two of these with full routes and so far (4months) they've functioned perfectly, and the price point is... inexpensive. /rh On Tue, May 19, 2015 at 10:22 AM, Colton Conor wrote: > What options are available for a small, low cost router that has at least > four 10G ports, and can handle full BGP routes? All that I know of are the > Juniper MX80, and the Brocade CER line. What does Cisco and others have > that compete with these two? Any other vendors besides Juniper, Brocade, > and Cisco to look at? > From maxtul at netassist.ua Tue May 19 18:23:45 2015 From: maxtul at netassist.ua (Max Tulyev) Date: Tue, 19 May 2015 21:23:45 +0300 Subject: Low Cost 10G Router In-Reply-To: References: <555B79C0.5080207@netassist.ua> Message-ID: <555B7FB1.9050600@netassist.ua> Last config I touched: 2xIntel(R) Xeon(R) CPU E5-2650 0 @ 2.00GHz, 12 Gbit summary, <5% each core load. On 19.05.15 21:06, Piotr Iwanejko wrote: > Wiadomo?? napisana przez Max Tulyev w dniu 19 maj 2015, o godz. 19:58: >> We are using softrouters based on Supermicro chassis, E5v3 cpu, >> Linux/BIRD and Intel 10G NICs. And VERY happy. > > Out of curiosity, how much traffic you pass over those softrouters? > > Piotr > From sysoleg at yandex.ru Tue May 19 18:32:59 2015 From: sysoleg at yandex.ru (Oleg A. Arkhangelsky) Date: Tue, 19 May 2015 21:32:59 +0300 Subject: Low Cost 10G Router In-Reply-To: <555B7FB1.9050600@netassist.ua> References: <555B79C0.5080207@netassist.ua> <555B7FB1.9050600@netassist.ua> Message-ID: <2101331432060379@web8j.yandex.ru> 19.05.2015, 21:26, "Max Tulyev" : > Last config I touched: 2xIntel(R) Xeon(R) CPU E5-2650 0 @ 2.00GHz, 12 > Gbit summary, <5% each core load. And what PPS rate (in+out)? -- wbr, Oleg. "Anarchy is about taking complete responsibility for yourself." ????? Alan Moore. From colinj at gt86car.org.uk Tue May 19 18:37:07 2015 From: colinj at gt86car.org.uk (Colin Johnston) Date: Tue, 19 May 2015 19:37:07 +0100 Subject: Low Cost 10G Router In-Reply-To: <2101331432060379@web8j.yandex.ru> References: <555B79C0.5080207@netassist.ua> <555B7FB1.9050600@netassist.ua> <2101331432060379@web8j.yandex.ru> Message-ID: <83149C1D-F520-4B56-95FE-451A8D3590E1@gt86car.org.uk> How much of that traffic is valid legit traffic as well :( Colin > On 19 May 2015, at 19:32, Oleg A. Arkhangelsky wrote: > > > > 19.05.2015, 21:26, "Max Tulyev" : >> Last config I touched: 2xIntel(R) Xeon(R) CPU E5-2650 0 @ 2.00GHz, 12 >> Gbit summary, <5% each core load. > > And what PPS rate (in+out)? > > -- > wbr, Oleg. > > "Anarchy is about taking complete responsibility for yourself." > Alan Moore. From maxtul at netassist.ua Tue May 19 18:38:11 2015 From: maxtul at netassist.ua (Max Tulyev) Date: Tue, 19 May 2015 21:38:11 +0300 Subject: Spamhaus BGP feed experiences? In-Reply-To: <20150518180414.GC13453@bongo.bofh.it> References: <20150518180414.GC13453@bongo.bofh.it> Message-ID: <555B8313.5080400@netassist.ua> How much false positives (i.e. blackholing traffic users want to reach)? On 18.05.15 21:04, Marco d'Itri wrote: > On May 17, Mike Lyon wrote: > >> Any ISPs out there (big or small) ever used the Spamhaus BGP feed to >> prevent against botnet, spam, etc? If so, how has your experience been? Is >> it worthwhile? Has it helped? On / off list responses are appreciated in >> advance. > We use Spamhaus DROP (not the BGP version: our software asks a human to > review each change). > The benefits are not obvious since we do not have access customers, but > it will blackhole some networks you obviously do not want to talk to, > and it has not caused any troubles either. > From maxtul at netassist.ua Tue May 19 18:44:31 2015 From: maxtul at netassist.ua (Max Tulyev) Date: Tue, 19 May 2015 21:44:31 +0300 Subject: Low Cost 10G Router In-Reply-To: <2101331432060379@web8j.yandex.ru> References: <555B79C0.5080207@netassist.ua> <555B7FB1.9050600@netassist.ua> <2101331432060379@web8j.yandex.ru> Message-ID: <555B848F.1050605@netassist.ua> 1.4Mpps now. On 19.05.15 21:32, Oleg A. Arkhangelsky wrote: > > > 19.05.2015, 21:26, "Max Tulyev" : >> Last config I touched: 2xIntel(R) Xeon(R) CPU E5-2650 0 @ 2.00GHz, 12 >> Gbit summary, <5% each core load. > > And what PPS rate (in+out)? > > -- > wbr, Oleg. > > "Anarchy is about taking complete responsibility for yourself." > Alan Moore. > From rps at maine.edu Tue May 19 18:46:36 2015 From: rps at maine.edu (Ray Soucy) Date: Tue, 19 May 2015 14:46:36 -0400 Subject: Low Cost 10G Router In-Reply-To: References: Message-ID: How cheap is cheap and what performance numbers are you looking for? About as cheap as you can get: For about $3,000 you can build a Supermicro OEM system with an 8-core Xeon E5 V3 and 4-port 10G Intel SFP+ NIC with 8G of RAM running VyOS. The pro is that BGP convergence time will be good (better than a 7200 VXR), and number of tables likely won't be a concern since RAM is cheap. The con is that you're not doing things in hardware, so you'll have higher latency, and your PPS will be lower. I haven't tried this configuration as a full router in production, but have been using them in a few places as a firewall solution and they've handled everything I've thrown their way so far. Initially, I had these in place as "low-capital" solutions that were going to be temporary so we could start building out a new environment and collect usage data to have real world sizing data for something like an ASA cluster, but they've worked so well that we've held off on that purchase for now (given challenging budget times in higher-education). The stability of VyOS has been good, and the image-based upgrade system has worked every time without issues for the past year or two (starting from 1.0.1 to the current 1.1.5). That said documentation for VyOS is poor, so you should be ready to dig into some source code or hit the IRC channel to get things running. Having a foundation with general Linux knowledge is helpful here too. If you just need a 10G link but only commit to 2-3G then this solution might be able to work well for you. If you need closer to line-rate 10G at small packet sizes then you might start running into performance limitations due to latency. If this is the case there is the Vyatta vRouter 5600 (VyOS is based on the GPL portions of the 5400), which claims to have Intel DPDK support and can handle multi-10G at line rate; but last time I checked it was really expensive ($10,000 per core or something ridiculous like that). In terms of commercial solutions, I think 10G and BGP are two things that don't combine well for "cheap". An ASR1K might do the trick, but more likely than not you're looking at an ASR9K if you want full tables; I don't have any experience with the 1K personally so I can't speak to that. The ASR 9K is a really great platform and is what we use for BGP here, but it's pretty much the opposite of cheap. As far as the firewall stuff goes, I have a draft of VyOS as a firewall that I've been wanting to put together (still needs work): http://soucy.org/vyos/UsingVyOSasaFirewall.pdf P.S. Sorry the documentation for VyOS is so bad, what's there so far in the User Guide is basically me trying to do a first pass in hopes that others would help out and there haven't been many updates. On Tue, May 19, 2015 at 1:22 PM, Colton Conor wrote: > What options are available for a small, low cost router that has at least > four 10G ports, and can handle full BGP routes? All that I know of are the > Juniper MX80, and the Brocade CER line. What does Cisco and others have > that compete with these two? Any other vendors besides Juniper, Brocade, > and Cisco to look at? > -- Ray Patrick Soucy Network Engineer University of Maine System T: 207-561-3526 F: 207-561-3531 MaineREN, Maine's Research and Education Network www.maineren.net From johnl at iecc.com Tue May 19 19:01:55 2015 From: johnl at iecc.com (John Levine) Date: 19 May 2015 19:01:55 -0000 Subject: Spamhaus BGP feed experiences? In-Reply-To: <555B8313.5080400@netassist.ua> Message-ID: <20150519190155.61849.qmail@ary.lan> In article <555B8313.5080400 at netassist.ua> you write: >How much false positives (i.e. blackholing traffic users want to reach)? Very little. The DROP list, which is what's in the BGP feed, is a small subset of the SBL, and only includes blocks that send no legitimate traffic at all. > >On 18.05.15 21:04, Marco d'Itri wrote: >> On May 17, Mike Lyon wrote: >> >>> Any ISPs out there (big or small) ever used the Spamhaus BGP feed to >>> prevent against botnet, spam, etc? If so, how has your experience been? Is >>> it worthwhile? Has it helped? On / off list responses are appreciated in >>> advance. >> We use Spamhaus DROP (not the BGP version: our software asks a human to >> review each change). >> The benefits are not obvious since we do not have access customers, but >> it will blackhole some networks you obviously do not want to talk to, >> and it has not caused any troubles either. >> > From jgreco at ns.sol.net Tue May 19 20:46:16 2015 From: jgreco at ns.sol.net (Joe Greco) Date: Tue, 19 May 2015 15:46:16 -0500 (CDT) Subject: Low Cost 10G Router In-Reply-To: Message-ID: <201505192046.t4JKkG90057624@aurora.sol.net> > How cheap is cheap and what performance numbers are you looking for? > > About as cheap as you can get: > > For about $3,000 you can build a Supermicro OEM system with an 8-core Xeon > E5 V3 and 4-port 10G Intel SFP+ NIC with 8G of RAM running VyOS. The pro > is that BGP convergence time will be good (better than a 7200 VXR), and > number of tables likely won't be a concern since RAM is cheap. The con is > that you're not doing things in hardware, so you'll have higher latency, > and your PPS will be lower. What 8 core Xeon E5 v3 would that be? The 26xx's are hideously pricey, and for a router, you're probably better off with something like a Supermicro X10SRn fsvo "n" with a Xeon E5-1650v3. Board is typically around $300, 1650 is around $550, so total cost I'm guessing closer to $1500-$2000 that route. The edge you get there is the higher clock on the CPU. Only six cores and only 15M cache, but 3.5GHz. The E5-2643v3 is three times the cost for very similar performance specs. Costwise, E5 single socket is the way to go unless you *need* more. ... 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 math at sizone.org Tue May 19 19:11:20 2015 From: math at sizone.org (Ken Chase) Date: Tue, 19 May 2015 15:11:20 -0400 Subject: Low Cost 10G Router In-Reply-To: <201505192046.t4JKkG90057624@aurora.sol.net> References: <201505192046.t4JKkG90057624@aurora.sol.net> Message-ID: <20150519191120.GA15859@sizone.org> Chat in my nerds irc channel about 10G routers paralleling this 14:21 the Xeon D-1540 has 8 cores / 16 threads, 2GHz base clock with 2.6GHz turbo, and dual 10G nics on chip 14:21 45W TDP 14:31 supposedly an asrock board is coming that can be 10Gbase-T or SFP+ 14:58 supermicro are shipping some SFP+ 10G E5 boards 15:00 but the xeon E5 doesn't have the on die 10G nic 15:07 X9DRW-7TPF+ http://www.supermicro.com/products/motherboard/xeon/c600/x9drw-7tpf_.cfm Also: 1.4Mpps per 10G link doesnt seem like the minimum packetsize one wants for handling DOS attacks, but I might be bad at math. /kc On Tue, May 19, 2015 at 03:46:16PM -0500, Joe Greco said: >> How cheap is cheap and what performance numbers are you looking for? >> >> About as cheap as you can get: >> >> For about $3,000 you can build a Supermicro OEM system with an 8-core Xeon >> E5 V3 and 4-port 10G Intel SFP+ NIC with 8G of RAM running VyOS. The pro >> is that BGP convergence time will be good (better than a 7200 VXR), and >> number of tables likely won't be a concern since RAM is cheap. The con is >> that you're not doing things in hardware, so you'll have higher latency, >> and your PPS will be lower. > >What 8 core Xeon E5 v3 would that be? The 26xx's are hideously pricey, >and for a router, you're probably better off with something like a >Supermicro X10SRn fsvo "n" with a Xeon E5-1650v3. Board is typically >around $300, 1650 is around $550, so total cost I'm guessing closer to >$1500-$2000 that route. > >The edge you get there is the higher clock on the CPU. Only six cores >and only 15M cache, but 3.5GHz. The E5-2643v3 is three times the cost >for very similar performance specs. Costwise, E5 single socket is the >way to go unless you *need* more. > >... 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. -- Ken Chase - Toronto Canada From morrowc.lists at gmail.com Tue May 19 19:11:50 2015 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Tue, 19 May 2015 15:11:50 -0400 Subject: No subject In-Reply-To: References: Message-ID: (-direct-ryan) yikes formatting for this got wonky... On Tue, May 19, 2015 at 11:53 AM, Ryan Shea via NANOG > ---------- Forwarded message ---------- > From: Ryan Shea > To: nanog list > Cc: > Date: Tue, 19 May 2015 15:53:15 +0000 > Subject: Unified Security Vulnerability Management > > Manually setting up and parsing email notifications for security > vulnerabilities for all vendors is mighty annoying. It looks like the ICASI > CVRF Working Group thought the same thing back > in 2011 when they came up with this handy XML schema. I had not known of > this until yesterday and noticed that Cisco does a good job > posting their > vulnerabilities in CVRF. Word on the streets is that Juniper > was at least > partially involved in CVRF as well. Brocade may have looked into it as well. > > This does not seem like a difficult thing for vendors to do, but the > missing piece may be customer interest. I am hoping to drum up some > interest here -- maybe a few support requests would entice them to hand > this off to an intern and we could collectively do better at managing > vendor notifications. A tool to > parse CVRF is already floating about as well (mschiffm). I bet if we can get FR/PR numbers for some vendors we might be able to get a bunch of people to add support through a central set of points per vendor. Can we put the PR for juniper here? (and if other folk have a PR/FR for their pet vendor(s) add those to the list?) From keefe-af at ethoplex.com Tue May 19 19:16:50 2015 From: keefe-af at ethoplex.com (Keefe John) Date: Tue, 19 May 2015 14:16:50 -0500 Subject: Low Cost 10G Router In-Reply-To: <201505192046.t4JKkG90057624@aurora.sol.net> References: <201505192046.t4JKkG90057624@aurora.sol.net> Message-ID: <555B8C22.8030203@ethoplex.com> For about $1000 you could get a Mikrotik CCR1036-8G-2S+EM but it only has 2 SFP+ ports. http://routerboard.com/CCR1036-8G-2SplusEM Keefe On 5/19/2015 3:46 PM, Joe Greco wrote: >> How cheap is cheap and what performance numbers are you looking for? >> >> About as cheap as you can get: >> >> For about $3,000 you can build a Supermicro OEM system with an 8-core Xeon >> E5 V3 and 4-port 10G Intel SFP+ NIC with 8G of RAM running VyOS. The pro >> is that BGP convergence time will be good (better than a 7200 VXR), and >> number of tables likely won't be a concern since RAM is cheap. The con is >> that you're not doing things in hardware, so you'll have higher latency, >> and your PPS will be lower. > What 8 core Xeon E5 v3 would that be? The 26xx's are hideously pricey, > and for a router, you're probably better off with something like a > Supermicro X10SRn fsvo "n" with a Xeon E5-1650v3. Board is typically > around $300, 1650 is around $550, so total cost I'm guessing closer to > $1500-$2000 that route. > > The edge you get there is the higher clock on the CPU. Only six cores > and only 15M cache, but 3.5GHz. The E5-2643v3 is three times the cost > for very similar performance specs. Costwise, E5 single socket is the > way to go unless you *need* more. > > ... JG From jgreco at ns.sol.net Tue May 19 21:04:47 2015 From: jgreco at ns.sol.net (Joe Greco) Date: Tue, 19 May 2015 16:04:47 -0500 (CDT) Subject: Low Cost 10G Router In-Reply-To: <20150519191120.GA15859@sizone.org> Message-ID: <201505192104.t4JL4ljd057928@aurora.sol.net> > Chat in my nerds irc channel about 10G routers paralleling this > > 14:21 the Xeon D-1540 has 8 cores / 16 threads, 2GHz base clock with > 2.6GHz turbo, and dual 10G nics on chip > 14:21 45W TDP Right, but that's a pretty lame clock. > 14:31 supposedly an asrock board is coming that can be 10Gbase-T or SFP+ Also the only one so far I've seen able to support multiple PCIe. The Supermicro is mini-ITX. But the AsRock has some weird power arrangement too. > 14:58 supermicro are shipping some SFP+ 10G E5 boards > 15:00 but the xeon E5 doesn't have the on die 10G nic > 15:07 X9DRW-7TPF+ > > http://www.supermicro.com/products/motherboard/xeon/c600/x9drw-7tpf_.cfm Yes, but that's a big wattsy thing. The X10SRW comes in some 1U variants that can handle two PCIe so it'd be an interesting router platform that does not eat lots of space. > Also: 1.4Mpps per 10G link doesnt seem like the minimum packetsize one wants for > handling DOS attacks, but I might be bad at math. Always an issue. ... 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 pavel.odintsov at gmail.com Tue May 19 19:23:11 2015 From: pavel.odintsov at gmail.com (Pavel Odintsov) Date: Tue, 19 May 2015 22:23:11 +0300 Subject: Low Cost 10G Router In-Reply-To: <20150519191120.GA15859@sizone.org> References: <201505192046.t4JKkG90057624@aurora.sol.net> <20150519191120.GA15859@sizone.org> Message-ID: Hello! Somebody definitely should build full feature router with DPDK/netmap/pf_ring :) I have finished detailed performance tests for all of them and could achieve wire speed forwarding (with simple packet rewrite and checksum calculation) with all of they. I.e. I could process 10GE and 14.6 mpps (64byte packets) on very cheap i7 3820 with single intel X540 NIC (total cost about $ 800) with CPU 70% load. But full BGP routing is a challenge but could be implemented with existing approaches like DXR: http://info.iet.unipi.it/~luigi/papers/20120601-dxr.pdf Cheers! On Tue, May 19, 2015 at 10:11 PM, Ken Chase wrote: > Chat in my nerds irc channel about 10G routers paralleling this > > 14:21 the Xeon D-1540 has 8 cores / 16 threads, 2GHz base clock with > 2.6GHz turbo, and dual 10G nics on chip > 14:21 45W TDP > 14:31 supposedly an asrock board is coming that can be 10Gbase-T or SFP+ > 14:58 supermicro are shipping some SFP+ 10G E5 boards > 15:00 but the xeon E5 doesn't have the on die 10G nic > 15:07 X9DRW-7TPF+ > > http://www.supermicro.com/products/motherboard/xeon/c600/x9drw-7tpf_.cfm > > Also: 1.4Mpps per 10G link doesnt seem like the minimum packetsize one wants for > handling DOS attacks, but I might be bad at math. > > /kc > > > On Tue, May 19, 2015 at 03:46:16PM -0500, Joe Greco said: > >> How cheap is cheap and what performance numbers are you looking for? > >> > >> About as cheap as you can get: > >> > >> For about $3,000 you can build a Supermicro OEM system with an 8-core Xeon > >> E5 V3 and 4-port 10G Intel SFP+ NIC with 8G of RAM running VyOS. The pro > >> is that BGP convergence time will be good (better than a 7200 VXR), and > >> number of tables likely won't be a concern since RAM is cheap. The con is > >> that you're not doing things in hardware, so you'll have higher latency, > >> and your PPS will be lower. > > > >What 8 core Xeon E5 v3 would that be? The 26xx's are hideously pricey, > >and for a router, you're probably better off with something like a > >Supermicro X10SRn fsvo "n" with a Xeon E5-1650v3. Board is typically > >around $300, 1650 is around $550, so total cost I'm guessing closer to > >$1500-$2000 that route. > > > >The edge you get there is the higher clock on the CPU. Only six cores > >and only 15M cache, but 3.5GHz. The E5-2643v3 is three times the cost > >for very similar performance specs. Costwise, E5 single socket is the > >way to go unless you *need* more. > > > >... 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. > > -- > Ken Chase - Toronto Canada -- Sincerely yours, Pavel Odintsov From lists at mtin.net Tue May 19 19:27:28 2015 From: lists at mtin.net (Justin Wilson - MTIN) Date: Tue, 19 May 2015 15:27:28 -0400 Subject: Low Cost 10G Router In-Reply-To: <555B8C22.8030203@ethoplex.com> References: <201505192046.t4JKkG90057624@aurora.sol.net> <555B8C22.8030203@ethoplex.com> Message-ID: <7ACEC6BE-527E-4EFE-AE62-06701C9C9496@mtin.net> I second the Mikrotik recommendation. You don?t get support like you would with Cisco but it?s a solid product. Justin Justin Wilson j2sw at mtin.net http://www.mtin.net Managed Services ? xISP Solutions ? Data Centers http://www.thebrotherswisp.com Podcast about xISP topics http://www.midwest-ix.com Peering ? Transit ? Internet Exchange > On May 19, 2015, at 3:16 PM, Keefe John wrote: > > For about $1000 you could get a Mikrotik CCR1036-8G-2S+EM but it only has 2 SFP+ ports. > > http://routerboard.com/CCR1036-8G-2SplusEM > > Keefe > > On 5/19/2015 3:46 PM, Joe Greco wrote: >>> How cheap is cheap and what performance numbers are you looking for? >>> >>> About as cheap as you can get: >>> >>> For about $3,000 you can build a Supermicro OEM system with an 8-core Xeon >>> E5 V3 and 4-port 10G Intel SFP+ NIC with 8G of RAM running VyOS. The pro >>> is that BGP convergence time will be good (better than a 7200 VXR), and >>> number of tables likely won't be a concern since RAM is cheap. The con is >>> that you're not doing things in hardware, so you'll have higher latency, >>> and your PPS will be lower. >> What 8 core Xeon E5 v3 would that be? The 26xx's are hideously pricey, >> and for a router, you're probably better off with something like a >> Supermicro X10SRn fsvo "n" with a Xeon E5-1650v3. Board is typically >> around $300, 1650 is around $550, so total cost I'm guessing closer to >> $1500-$2000 that route. >> >> The edge you get there is the higher clock on the CPU. Only six cores >> and only 15M cache, but 3.5GHz. The E5-2643v3 is three times the cost >> for very similar performance specs. Costwise, E5 single socket is the >> way to go unless you *need* more. >> >> ... JG > From colton.conor at gmail.com Tue May 19 19:33:52 2015 From: colton.conor at gmail.com (Colton Conor) Date: Tue, 19 May 2015 14:33:52 -0500 Subject: Low Cost 10G Router In-Reply-To: References: Message-ID: How much does a Huawei NE40E-X1-M4 cost Richard? On Tue, May 19, 2015 at 1:09 PM, Richard Holbo wrote: > Huawei NE40E-X1-M4 > > I've two of these with full routes and so far (4months) they've functioned > perfectly, and the price point is... inexpensive. > > /rh > > On Tue, May 19, 2015 at 10:22 AM, Colton Conor > wrote: > >> What options are available for a small, low cost router that has at least >> four 10G ports, and can handle full BGP routes? All that I know of are the >> Juniper MX80, and the Brocade CER line. What does Cisco and others have >> that compete with these two? Any other vendors besides Juniper, Brocade, >> and Cisco to look at? >> > > From listas at esds.com.br Tue May 19 19:37:19 2015 From: listas at esds.com.br (Eduardo Schoedler) Date: Tue, 19 May 2015 16:37:19 -0300 Subject: Low Cost 10G Router In-Reply-To: <555B8C22.8030203@ethoplex.com> References: <201505192046.t4JKkG90057624@aurora.sol.net> <555B8C22.8030203@ethoplex.com> Message-ID: 2015-05-19 16:16 GMT-03:00 Keefe John : > For about $1000 you could get a Mikrotik CCR1036-8G-2S+EM but it only has 2 > SFP+ ports. > > http://routerboard.com/CCR1036-8G-2SplusEM Run away from Mikrotik, especially if you want to run BGP. -- Eduardo Schoedler From pavel.odintsov at gmail.com Tue May 19 19:40:29 2015 From: pavel.odintsov at gmail.com (Pavel Odintsov) Date: Tue, 19 May 2015 22:40:29 +0300 Subject: Low Cost 10G Router In-Reply-To: References: <201505192046.t4JKkG90057624@aurora.sol.net> <555B8C22.8030203@ethoplex.com> Message-ID: Microtik CCR have a huge issues in case of DDOS: http://forum.mikrotik.com/viewtopic.php?t=92728 On Tue, May 19, 2015 at 10:37 PM, Eduardo Schoedler wrote: > 2015-05-19 16:16 GMT-03:00 Keefe John : >> For about $1000 you could get a Mikrotik CCR1036-8G-2S+EM but it only has 2 >> SFP+ ports. >> >> http://routerboard.com/CCR1036-8G-2SplusEM > > Run away from Mikrotik, especially if you want to run BGP. > > -- > Eduardo Schoedler -- Sincerely yours, Pavel Odintsov From mel at beckman.org Tue May 19 19:44:53 2015 From: mel at beckman.org (Mel Beckman) Date: Tue, 19 May 2015 19:44:53 +0000 Subject: Low Cost 10G Router In-Reply-To: <7ACEC6BE-527E-4EFE-AE62-06701C9C9496@mtin.net> References: <201505192046.t4JKkG90057624@aurora.sol.net> <555B8C22.8030203@ethoplex.com>, <7ACEC6BE-527E-4EFE-AE62-06701C9C9496@mtin.net> Message-ID: I've seen serious, unusual performance bottlenecks in Mikrotik CCR, in some cases not even achieving a gigabit speeds on 10G interfaces. Performance drops more rapidly then Cisco with smaller packet sizes. -mel beckman > On May 19, 2015, at 12:28 PM, Justin Wilson - MTIN wrote: > > I second the Mikrotik recommendation. You don?t get support like you would with Cisco but it?s a solid product. > > Justin > > > > Justin Wilson j2sw at mtin.net > http://www.mtin.net Managed Services ? xISP Solutions ? Data Centers > http://www.thebrotherswisp.com Podcast about xISP topics > http://www.midwest-ix.com Peering ? Transit ? Internet Exchange > >> On May 19, 2015, at 3:16 PM, Keefe John wrote: >> >> For about $1000 you could get a Mikrotik CCR1036-8G-2S+EM but it only has 2 SFP+ ports. >> >> http://routerboard.com/CCR1036-8G-2SplusEM >> >> Keefe >> >> On 5/19/2015 3:46 PM, Joe Greco wrote: >>>> How cheap is cheap and what performance numbers are you looking for? >>>> >>>> About as cheap as you can get: >>>> >>>> For about $3,000 you can build a Supermicro OEM system with an 8-core Xeon >>>> E5 V3 and 4-port 10G Intel SFP+ NIC with 8G of RAM running VyOS. The pro >>>> is that BGP convergence time will be good (better than a 7200 VXR), and >>>> number of tables likely won't be a concern since RAM is cheap. The con is >>>> that you're not doing things in hardware, so you'll have higher latency, >>>> and your PPS will be lower. >>> What 8 core Xeon E5 v3 would that be? The 26xx's are hideously pricey, >>> and for a router, you're probably better off with something like a >>> Supermicro X10SRn fsvo "n" with a Xeon E5-1650v3. Board is typically >>> around $300, 1650 is around $550, so total cost I'm guessing closer to >>> $1500-$2000 that route. >>> >>> The edge you get there is the higher clock on the CPU. Only six cores >>> and only 15M cache, but 3.5GHz. The E5-2643v3 is three times the cost >>> for very similar performance specs. Costwise, E5 single socket is the >>> way to go unless you *need* more. >>> >>> ... JG > From Daniel.Jameson at tdstelecom.com Tue May 19 19:53:58 2015 From: Daniel.Jameson at tdstelecom.com (Jameson, Daniel) Date: Tue, 19 May 2015 19:53:58 +0000 Subject: Low Cost 10G Router In-Reply-To: <555B7FB1.9050600@netassist.ua> References: <555B79C0.5080207@netassist.ua> <555B7FB1.9050600@netassist.ua> Message-ID: The running estimate is about 3 cores per 10GIf to maintain Line-Rate forwarding. The Enterprise version of Vyatte runs around 1.5-2 cores per 10Gif (Depends on how the forwarding plane is treating traffic, if you're remarking or heavy firewall rules the interrupt forwarding cost starts to impede. -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Max Tulyev Sent: Tuesday, May 19, 2015 1:24 PM To: nanog at nanog.org Subject: Re: Low Cost 10G Router Last config I touched: 2xIntel(R) Xeon(R) CPU E5-2650 0 @ 2.00GHz, 12 Gbit summary, <5% each core load. On 19.05.15 21:06, Piotr Iwanejko wrote: > Wiadomo?? napisana przez Max Tulyev w dniu 19 maj 2015, o godz. 19:58: >> We are using softrouters based on Supermicro chassis, E5v3 cpu, >> Linux/BIRD and Intel 10G NICs. And VERY happy. > > Out of curiosity, how much traffic you pass over those softrouters? > > Piotr > From pavel.odintsov at gmail.com Tue May 19 19:54:58 2015 From: pavel.odintsov at gmail.com (Pavel Odintsov) Date: Tue, 19 May 2015 22:54:58 +0300 Subject: Low Cost 10G Router In-Reply-To: References: <201505192046.t4JKkG90057624@aurora.sol.net> <555B8C22.8030203@ethoplex.com> <7ACEC6BE-527E-4EFE-AE62-06701C9C9496@mtin.net> Message-ID: What about L3 switches? You could receive full BGP table with Linux BOX with ExaBGP, parse it and feed to L3 switch. On Tue, May 19, 2015 at 10:44 PM, Mel Beckman wrote: > I've seen serious, unusual performance bottlenecks in Mikrotik CCR, in some cases not even achieving a gigabit speeds on 10G interfaces. Performance drops more rapidly then Cisco with smaller packet sizes. > > -mel beckman > >> On May 19, 2015, at 12:28 PM, Justin Wilson - MTIN wrote: >> >> I second the Mikrotik recommendation. You don?t get support like you would with Cisco but it?s a solid product. >> >> Justin >> >> >> >> Justin Wilson j2sw at mtin.net >> http://www.mtin.net Managed Services ? xISP Solutions ? Data Centers >> http://www.thebrotherswisp.com Podcast about xISP topics >> http://www.midwest-ix.com Peering ? Transit ? Internet Exchange >> >>> On May 19, 2015, at 3:16 PM, Keefe John wrote: >>> >>> For about $1000 you could get a Mikrotik CCR1036-8G-2S+EM but it only has 2 SFP+ ports. >>> >>> http://routerboard.com/CCR1036-8G-2SplusEM >>> >>> Keefe >>> >>> On 5/19/2015 3:46 PM, Joe Greco wrote: >>>>> How cheap is cheap and what performance numbers are you looking for? >>>>> >>>>> About as cheap as you can get: >>>>> >>>>> For about $3,000 you can build a Supermicro OEM system with an 8-core Xeon >>>>> E5 V3 and 4-port 10G Intel SFP+ NIC with 8G of RAM running VyOS. The pro >>>>> is that BGP convergence time will be good (better than a 7200 VXR), and >>>>> number of tables likely won't be a concern since RAM is cheap. The con is >>>>> that you're not doing things in hardware, so you'll have higher latency, >>>>> and your PPS will be lower. >>>> What 8 core Xeon E5 v3 would that be? The 26xx's are hideously pricey, >>>> and for a router, you're probably better off with something like a >>>> Supermicro X10SRn fsvo "n" with a Xeon E5-1650v3. Board is typically >>>> around $300, 1650 is around $550, so total cost I'm guessing closer to >>>> $1500-$2000 that route. >>>> >>>> The edge you get there is the higher clock on the CPU. Only six cores >>>> and only 15M cache, but 3.5GHz. The E5-2643v3 is three times the cost >>>> for very similar performance specs. Costwise, E5 single socket is the >>>> way to go unless you *need* more. >>>> >>>> ... JG >> -- Sincerely yours, Pavel Odintsov From mel at beckman.org Tue May 19 20:25:42 2015 From: mel at beckman.org (Mel Beckman) Date: Tue, 19 May 2015 20:25:42 +0000 Subject: Low Cost 10G Router In-Reply-To: References: <201505192046.t4JKkG90057624@aurora.sol.net> <555B8C22.8030203@ethoplex.com> <7ACEC6BE-527E-4EFE-AE62-06701C9C9496@mtin.net> , Message-ID: I do use L3 switches for BGP at some locations (Cisco 3750) and they perform great. The problem is no instrumentation (e.g. Sflow, netflow). -mel via cell > On May 19, 2015, at 12:55 PM, Pavel Odintsov wrote: > > What about L3 switches? You could receive full BGP table with Linux > BOX with ExaBGP, parse it and feed to L3 switch. > >> On Tue, May 19, 2015 at 10:44 PM, Mel Beckman wrote: >> I've seen serious, unusual performance bottlenecks in Mikrotik CCR, in some cases not even achieving a gigabit speeds on 10G interfaces. Performance drops more rapidly then Cisco with smaller packet sizes. >> >> -mel beckman >> >>> On May 19, 2015, at 12:28 PM, Justin Wilson - MTIN wrote: >>> >>> I second the Mikrotik recommendation. You don?t get support like you would with Cisco but it?s a solid product. >>> >>> Justin >>> >>> >>> >>> Justin Wilson j2sw at mtin.net >>> http://www.mtin.net Managed Services ? xISP Solutions ? Data Centers >>> http://www.thebrotherswisp.com Podcast about xISP topics >>> http://www.midwest-ix.com Peering ? Transit ? Internet Exchange >>> >>>> On May 19, 2015, at 3:16 PM, Keefe John wrote: >>>> >>>> For about $1000 you could get a Mikrotik CCR1036-8G-2S+EM but it only has 2 SFP+ ports. >>>> >>>> http://routerboard.com/CCR1036-8G-2SplusEM >>>> >>>> Keefe >>>> >>>> On 5/19/2015 3:46 PM, Joe Greco wrote: >>>>>> How cheap is cheap and what performance numbers are you looking for? >>>>>> >>>>>> About as cheap as you can get: >>>>>> >>>>>> For about $3,000 you can build a Supermicro OEM system with an 8-core Xeon >>>>>> E5 V3 and 4-port 10G Intel SFP+ NIC with 8G of RAM running VyOS. The pro >>>>>> is that BGP convergence time will be good (better than a 7200 VXR), and >>>>>> number of tables likely won't be a concern since RAM is cheap. The con is >>>>>> that you're not doing things in hardware, so you'll have higher latency, >>>>>> and your PPS will be lower. >>>>> What 8 core Xeon E5 v3 would that be? The 26xx's are hideously pricey, >>>>> and for a router, you're probably better off with something like a >>>>> Supermicro X10SRn fsvo "n" with a Xeon E5-1650v3. Board is typically >>>>> around $300, 1650 is around $550, so total cost I'm guessing closer to >>>>> $1500-$2000 that route. >>>>> >>>>> The edge you get there is the higher clock on the CPU. Only six cores >>>>> and only 15M cache, but 3.5GHz. The E5-2643v3 is three times the cost >>>>> for very similar performance specs. Costwise, E5 single socket is the >>>>> way to go unless you *need* more. >>>>> >>>>> ... JG > > > > -- > Sincerely yours, Pavel Odintsov From jared at puck.Nether.net Tue May 19 20:37:26 2015 From: jared at puck.Nether.net (Jared Mauch) Date: Tue, 19 May 2015 16:37:26 -0400 Subject: your mail In-Reply-To: References: Message-ID: <20150519203726.GA25200@puck.nether.net> On Tue, May 19, 2015 at 03:53:19PM +0000, Ryan Shea via NANOG wrote: > This post was from a subscriber whose From: address domain has a DMARC > policy of reject or quarantine. The NANOG mailing list has > automatically wrapped this message to prevent other subscribers mail > systems from rejecting it. Can someone fix the DMARC settings to something more sensible? I've had to deal with this on the outages list already and it's simple to have it work in a more predictable way for users than injecting this text. The best settings are Munge From, (dmarc_moderation_action) as it will preserve the thread in a sensible way. I feel it's quite damaging to keep injecting this into the thread. One should also clear the dmarc_wrapped_message_text setting. - Jared -- Jared Mauch | pgp key available via finger from jared at puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine. From charles at thefnf.org Tue May 19 20:46:57 2015 From: charles at thefnf.org (charles at thefnf.org) Date: Tue, 19 May 2015 15:46:57 -0500 Subject: Low Cost 10G Router In-Reply-To: References: <201505192046.t4JKkG90057624@aurora.sol.net> <20150519191120.GA15859@sizone.org> Message-ID: <1fe23c98430bcdbccd21c93de7bbee75@thefnf.org> On 2015-05-19 14:23, Pavel Odintsov wrote: > Hello! > > Somebody definitely should build full feature router with > DPDK/netmap/pf_ring :) Netmap yes. The rest no. Why? Because netmap supports libpcap, which means everything just works. Other solutions need porting. You are going along, someone mentions a neat new libpcap based tool on NANOG and you want to try it out. If you've got DPDK/pf_ring, that means you are now having to port it. That's a fair amount of effort to just eval $COOL_NEW_TOOL. > > I have finished detailed performance tests for all of them and could > achieve wire speed forwarding (with simple packet rewrite and checksum > calculation) with all of they. With what features applied? DPDK with a fairly full feature set (firewall rules/dynamic routing/across a vpn tunnel/doing full l7 deep packet inspection) on straight commodity (something relatively recent gen xeon something many cores) hardware on $CERTAIN_POPULAR_RTOS seems to max out ~5gbps from what my local neighborhood network testing nerds tell me. As always, your mileage will most certainly vary of course. The nice thing about commodity boxes is that you can just deploy the same "core kit" and scale it up/down (ram/cpu/redundant psu) at your favorite vendors procurement portal (oh hey $systems_purchaser , can you order a couple extra boxes with that next set of a dozen boxes your buying with this SKU and take it out of my budget? Thx). You are still going to pay a pretty decent list price for boxes that can reasonably forward AND inspect/block/modify at anything approaching line rate over say 5gbps. Then you have things like the parallela board of course with it's FPGA. And you have CUDA cards. But staffing costs for someone who has FPGA(parallel in general)/sysadmin/netadmin skills.... well that's pricy (and you'll want a couple of those in house if you do this at any kind of scale). Or you could just contract them I suppose (say at like $700.00 per hour or so?, which is what I'd charge to be a one man FPGA coding SDN slinging band since it's sort of like catching unicorns) Course you could just have your jack of all trades in house sys/net ops person and contract coding skills as needed. Don't think this will really save you money. It won't. Buy a Juniper. Seriously. (I have a 6509 in my house along with various switches/routers/wifi/voip phones (all cisco). I'm not anti cisco by any means). But they are expensive from what I hear. You get what you pay for though. What it will get you, is a very powerful and flexible solution that lets you manage at hyperscale with a unified command/control plane. It's DEVOPS 2.0 (oooo I can fire my netadmins now like I fired my sysadmins after I gave dev full prod access? COOL!) (Yes I'm being incredibly sarcastic and don't actually believe that). :) Also look at onepk from cisco. It's kinda cool if you want SDN without having to fully build your own kit. From pavel.odintsov at gmail.com Tue May 19 20:59:29 2015 From: pavel.odintsov at gmail.com (Pavel Odintsov) Date: Tue, 19 May 2015 23:59:29 +0300 Subject: Low Cost 10G Router In-Reply-To: <1fe23c98430bcdbccd21c93de7bbee75@thefnf.org> References: <201505192046.t4JKkG90057624@aurora.sol.net> <20150519191120.GA15859@sizone.org> <1fe23c98430bcdbccd21c93de7bbee75@thefnf.org> Message-ID: Hello! Yep, there are no existent open source routers yet exists. But there are a lot of capabilities for this. We could just wait some time. But DPDK _definitely_ could process 64mpps and 40GE with deep inspection and processing on enough cheap E5 2670v3 chips. Yes, definitely it's ideas about good future. They can't be used now but they have really awesome outlook. On Tue, May 19, 2015 at 11:46 PM, wrote: > On 2015-05-19 14:23, Pavel Odintsov wrote: >> >> Hello! >> >> Somebody definitely should build full feature router with >> DPDK/netmap/pf_ring :) > > > Netmap yes. The rest no. Why? Because netmap supports libpcap, which means > everything just works. Other solutions need porting. > You are going along, someone mentions a neat new libpcap based tool on NANOG > and you want to try it out. If you've got DPDK/pf_ring, that means you are > now having to port it. That's a fair amount of effort to just eval > $COOL_NEW_TOOL. > > > >> >> I have finished detailed performance tests for all of them and could >> achieve wire speed forwarding (with simple packet rewrite and checksum >> calculation) with all of they. > > > With what features applied? DPDK with a fairly full feature set (firewall > rules/dynamic routing/across a vpn tunnel/doing full l7 deep packet > inspection) on straight commodity (something relatively recent gen xeon > something many cores) hardware on $CERTAIN_POPULAR_RTOS seems to max out > ~5gbps from what my local neighborhood network testing nerds tell me. > > As always, your mileage will most certainly vary of course. The nice thing > about commodity boxes is that you can just deploy the same "core kit" and > scale it up/down (ram/cpu/redundant psu) at your favorite vendors > procurement portal (oh hey $systems_purchaser , can you order a couple extra > boxes with that next set of a dozen boxes your buying with this SKU and take > it out of my budget? Thx). > > You are still going to pay a pretty decent list price for boxes that can > reasonably forward AND inspect/block/modify at anything approaching line > rate over say 5gbps. Then you have things like the parallela board of course > with it's FPGA. And you have CUDA cards. But staffing costs for someone who > has FPGA(parallel in general)/sysadmin/netadmin skills.... well that's pricy > (and you'll want a couple of those in house if you do this at any kind of > scale). Or you could just contract them I suppose (say at like $700.00 per > hour or so?, which is what I'd charge to be a one man FPGA coding SDN > slinging band since it's sort of like catching unicorns) Course you could > just have your jack of all trades in house sys/net ops person and contract > coding skills as needed. > > Don't think this will really save you money. It won't. > > Buy a Juniper. Seriously. > > (I have a 6509 in my house along with various switches/routers/wifi/voip > phones (all cisco). I'm not anti cisco by any means). But they are expensive > from what I hear. You get what you pay for though. > > What it will get you, is a very powerful and flexible solution that lets you > manage at hyperscale with a unified command/control plane. It's DEVOPS 2.0 > (oooo I can fire my netadmins now like I fired my sysadmins after I gave dev > full prod access? COOL!) (Yes I'm being incredibly sarcastic and don't > actually believe that). :) > > Also look at onepk from cisco. It's kinda cool if you want SDN without > having to fully build your own kit. > -- Sincerely yours, Pavel Odintsov From rodrigo at 1telecom.com.br Tue May 19 21:59:46 2015 From: rodrigo at 1telecom.com.br (Rodrigo 1telecom) Date: Tue, 19 May 2015 18:59:46 -0300 Subject: Low Cost 10G Router In-Reply-To: References: <201505192046.t4JKkG90057624@aurora.sol.net> <20150519191120.GA15859@sizone.org> <1fe23c98430bcdbccd21c93de7bbee75@thefnf.org> Message-ID: <6632909F-4742-4C7C-A3DD-A73972DDCBA0@1telecom.com.br> I know if is not possible to have a full routing on ex3300(low memory for it) , but i never tried to do a default router on it( with EFL licence and software above version 12) I have many bgp session with cisco 3750 switchs.. Traffic about 2gb on it... Have a peer( ebgp customer) with a acx2000( i know it have 10gb port) we send to this router a default route only... And it have 1.5gb with us and more 1gb with other link provider... Enviado via iPhone ? Grupo Connectoway > Em 19/05/2015, ?s 17:59, Pavel Odintsov escreveu: > > Hello! > > Yep, there are no existent open source routers yet exists. But there > are a lot of capabilities for this. We could just wait some time. > > But DPDK _definitely_ could process 64mpps and 40GE with deep > inspection and processing on enough cheap E5 2670v3 chips. > > Yes, definitely it's ideas about good future. They can't be used now > but they have really awesome outlook. > > > >> On Tue, May 19, 2015 at 11:46 PM, wrote: >>> On 2015-05-19 14:23, Pavel Odintsov wrote: >>> >>> Hello! >>> >>> Somebody definitely should build full feature router with >>> DPDK/netmap/pf_ring :) >> >> >> Netmap yes. The rest no. Why? Because netmap supports libpcap, which means >> everything just works. Other solutions need porting. >> You are going along, someone mentions a neat new libpcap based tool on NANOG >> and you want to try it out. If you've got DPDK/pf_ring, that means you are >> now having to port it. That's a fair amount of effort to just eval >> $COOL_NEW_TOOL. >> >> >> >>> >>> I have finished detailed performance tests for all of them and could >>> achieve wire speed forwarding (with simple packet rewrite and checksum >>> calculation) with all of they. >> >> >> With what features applied? DPDK with a fairly full feature set (firewall >> rules/dynamic routing/across a vpn tunnel/doing full l7 deep packet >> inspection) on straight commodity (something relatively recent gen xeon >> something many cores) hardware on $CERTAIN_POPULAR_RTOS seems to max out >> ~5gbps from what my local neighborhood network testing nerds tell me. >> >> As always, your mileage will most certainly vary of course. The nice thing >> about commodity boxes is that you can just deploy the same "core kit" and >> scale it up/down (ram/cpu/redundant psu) at your favorite vendors >> procurement portal (oh hey $systems_purchaser , can you order a couple extra >> boxes with that next set of a dozen boxes your buying with this SKU and take >> it out of my budget? Thx). >> >> You are still going to pay a pretty decent list price for boxes that can >> reasonably forward AND inspect/block/modify at anything approaching line >> rate over say 5gbps. Then you have things like the parallela board of course >> with it's FPGA. And you have CUDA cards. But staffing costs for someone who >> has FPGA(parallel in general)/sysadmin/netadmin skills.... well that's pricy >> (and you'll want a couple of those in house if you do this at any kind of >> scale). Or you could just contract them I suppose (say at like $700.00 per >> hour or so?, which is what I'd charge to be a one man FPGA coding SDN >> slinging band since it's sort of like catching unicorns) Course you could >> just have your jack of all trades in house sys/net ops person and contract >> coding skills as needed. >> >> Don't think this will really save you money. It won't. >> >> Buy a Juniper. Seriously. >> >> (I have a 6509 in my house along with various switches/routers/wifi/voip >> phones (all cisco). I'm not anti cisco by any means). But they are expensive >> from what I hear. You get what you pay for though. >> >> What it will get you, is a very powerful and flexible solution that lets you >> manage at hyperscale with a unified command/control plane. It's DEVOPS 2.0 >> (oooo I can fire my netadmins now like I fired my sysadmins after I gave dev >> full prod access? COOL!) (Yes I'm being incredibly sarcastic and don't >> actually believe that). :) >> >> Also look at onepk from cisco. It's kinda cool if you want SDN without >> having to fully build your own kit. > > > > -- > Sincerely yours, Pavel Odintsov From rodrigo at 1telecom.com.br Tue May 19 22:08:05 2015 From: rodrigo at 1telecom.com.br (Rodrigo 1telecom) Date: Tue, 19 May 2015 19:08:05 -0300 Subject: Low Cost 10G Router In-Reply-To: <6632909F-4742-4C7C-A3DD-A73972DDCBA0@1telecom.com.br> References: <201505192046.t4JKkG90057624@aurora.sol.net> <20150519191120.GA15859@sizone.org> <1fe23c98430bcdbccd21c93de7bbee75@thefnf.org> <6632909F-4742-4C7C-A3DD-A73972DDCBA0@1telecom.com.br> Message-ID: ... This customer had a asr1002 , but have a crash on asr router and only have this acx to up your link... Its a good test... Enviado via iPhone ? Grupo Connectoway > Em 19/05/2015, ?s 18:59, Rodrigo 1telecom escreveu: > > I know if is not possible to have a full routing on ex3300(low memory for it) , but i never tried to do a default router on it( with EFL licence and software above version 12) > I have many bgp session with cisco 3750 switchs.. Traffic about 2gb on it... Have a peer( ebgp customer) with a acx2000( i know it have 10gb port) we send to this router a default route only... And it have 1.5gb with us and more 1gb with other link provider... > Enviado via iPhone ? > Grupo Connectoway > >> Em 19/05/2015, ?s 17:59, Pavel Odintsov escreveu: >> >> Hello! >> >> Yep, there are no existent open source routers yet exists. But there >> are a lot of capabilities for this. We could just wait some time. >> >> But DPDK _definitely_ could process 64mpps and 40GE with deep >> inspection and processing on enough cheap E5 2670v3 chips. >> >> Yes, definitely it's ideas about good future. They can't be used now >> but they have really awesome outlook. >> >> >> >>>> On Tue, May 19, 2015 at 11:46 PM, wrote: >>>> On 2015-05-19 14:23, Pavel Odintsov wrote: >>>> >>>> Hello! >>>> >>>> Somebody definitely should build full feature router with >>>> DPDK/netmap/pf_ring :) >>> >>> >>> Netmap yes. The rest no. Why? Because netmap supports libpcap, which means >>> everything just works. Other solutions need porting. >>> You are going along, someone mentions a neat new libpcap based tool on NANOG >>> and you want to try it out. If you've got DPDK/pf_ring, that means you are >>> now having to port it. That's a fair amount of effort to just eval >>> $COOL_NEW_TOOL. >>> >>> >>> >>>> >>>> I have finished detailed performance tests for all of them and could >>>> achieve wire speed forwarding (with simple packet rewrite and checksum >>>> calculation) with all of they. >>> >>> >>> With what features applied? DPDK with a fairly full feature set (firewall >>> rules/dynamic routing/across a vpn tunnel/doing full l7 deep packet >>> inspection) on straight commodity (something relatively recent gen xeon >>> something many cores) hardware on $CERTAIN_POPULAR_RTOS seems to max out >>> ~5gbps from what my local neighborhood network testing nerds tell me. >>> >>> As always, your mileage will most certainly vary of course. The nice thing >>> about commodity boxes is that you can just deploy the same "core kit" and >>> scale it up/down (ram/cpu/redundant psu) at your favorite vendors >>> procurement portal (oh hey $systems_purchaser , can you order a couple extra >>> boxes with that next set of a dozen boxes your buying with this SKU and take >>> it out of my budget? Thx). >>> >>> You are still going to pay a pretty decent list price for boxes that can >>> reasonably forward AND inspect/block/modify at anything approaching line >>> rate over say 5gbps. Then you have things like the parallela board of course >>> with it's FPGA. And you have CUDA cards. But staffing costs for someone who >>> has FPGA(parallel in general)/sysadmin/netadmin skills.... well that's pricy >>> (and you'll want a couple of those in house if you do this at any kind of >>> scale). Or you could just contract them I suppose (say at like $700.00 per >>> hour or so?, which is what I'd charge to be a one man FPGA coding SDN >>> slinging band since it's sort of like catching unicorns) Course you could >>> just have your jack of all trades in house sys/net ops person and contract >>> coding skills as needed. >>> >>> Don't think this will really save you money. It won't. >>> >>> Buy a Juniper. Seriously. >>> >>> (I have a 6509 in my house along with various switches/routers/wifi/voip >>> phones (all cisco). I'm not anti cisco by any means). But they are expensive >>> from what I hear. You get what you pay for though. >>> >>> What it will get you, is a very powerful and flexible solution that lets you >>> manage at hyperscale with a unified command/control plane. It's DEVOPS 2.0 >>> (oooo I can fire my netadmins now like I fired my sysadmins after I gave dev >>> full prod access? COOL!) (Yes I'm being incredibly sarcastic and don't >>> actually believe that). :) >>> >>> Also look at onepk from cisco. It's kinda cool if you want SDN without >>> having to fully build your own kit. >> >> >> >> -- >> Sincerely yours, Pavel Odintsov From faisal at snappytelecom.net Tue May 19 23:03:20 2015 From: faisal at snappytelecom.net (Faisal Imtiaz) Date: Tue, 19 May 2015 23:03:20 +0000 (GMT) Subject: Low Cost 10G Router In-Reply-To: References: <201505192046.t4JKkG90057624@aurora.sol.net> <555B8C22.8030203@ethoplex.com> <7ACEC6BE-527E-4EFE-AE62-06701C9C9496@mtin.net> Message-ID: <1137657451.322777.1432076600090.JavaMail.zimbra@snappytelecom.net> > I've seen serious, unusual performance bottlenecks in Mikrotik CCR, in some > cases not even achieving a gigabit speeds on 10G interfaces. Performance > drops more rapidly then Cisco with smaller packet sizes. > > -mel beckman Folks often forget that Mikrotik ROS can also run on x86 machines..... Size your favorite hardware (server) or network appliance with appropriate ports, add MT ROS on a CF card, and you are good to go. We use i7 based network appliance with dual 10g cards (you can use a quad 10g card, such as those made by hotlav). with a 2gig of ram, you can easily do multiple (4-5 or more full bgp peers), and i7 are good for approx 1.2mill pps. Best of luck. Faisal Imtiaz Snappy Internet & Telecom From gaswarsaw-latam at outlook.com Tue May 19 23:25:56 2015 From: gaswarsaw-latam at outlook.com (Warsaw LATAM Operations Group) Date: Tue, 19 May 2015 19:25:56 -0400 Subject: Low Cost 10G Router In-Reply-To: <5D499B18-1134-43CD-8B09-9118E3CACAEA@akcin.net> References: , <5D499B18-1134-43CD-8B09-9118E3CACAEA@akcin.net> Message-ID: > > On May 19, 2015, at 10:22, Colton Conor wrote: > > > > What options are available for a small, low cost router that has at least > > four 10G ports, and can handle full BGP routes? All that I know of are the > > Juniper MX80, and the Brocade CER line. What does Cisco and others have > > that compete with these two? Any other vendors besides Juniper, Brocade, > > and Cisco to look at? I have two ServerU L-800 boxes routing BGP and OSPF, one of those has 4x10G SFP+ port and the other box, the more interesting experience I had, has a 2x40G Chelsio expansion board. Both run FreeBSD, one of the boxes run a thing called ProApps which is a FreeBSD based system ServerU people offer to their customers, with a nice and easy GUI, but essentially FreeBSD. My experience with ServerU boxes started from security needs, for high performance firewall and IDP, and recently I started to try it as router. So far, so good. The later box I started with BSDRP and later went for a default FreeBSD system. In this system I mostly run OSPF + BFD and stateles firewall, for a very critical customer site we have at Diebold. What we do in this ServerU L-800 + Chelsio card box is: - We have BIRD doing the dirty work for OSPF + BFD- We have a trigger in BIRD wich updates Chelsio T5's Forwarding Table- We have stateless firewalling handled with cxgbetool on Chelsio directly In this particular setup, with FreeBSD+BIRD+ServerUL800+Chelsio we handle every day, 4.2Mpps on 2x40G ports mostly on Chelsio ASICS, leaving most of ServerU CPU for BIRD and other FreeBSD features such as vlan, lagg, etc. Interrupt CPU usage is very low, since it's mostly handled on Chelsio board. So far I haven't tried adding a full BGP routing table to Chelsio, but the couple dozen routes we have demand this pps rate, gracefully handled by the box. It's a 1,200 USD starting cost for a very decent router which promisses to delivery a good pps and bps rate specially when compared to Mikrotik's CCR and other Cisco/Brocade routers on this same grade. Add to it a couple hundred extra bucks to have a very decent Chelsio T5 ASICS expansion to L800 chassis and you pretty much have a system that, according to Chelsion data sheet, promisses to delivery 27 milion packets per second filtered and forwarded. Pretty much Line Rate for 10G ports. I don't know about the expected 27Mpps per port, but I can confirm 4.8Mpps peaking / 4.2Mpps avging on my rack everyday, and for the price I pay on this ServerU + FreeBSD setup I can't avoid to suggest it worths pretty much a try! http://www.serveru.us/en/netmapl800 If you buy a Chelsio card or already have it, or have it at a better price (sometimes we find very good 300.00 USD deals on chelsio T5, while their list price is ~900.00 USD) talk to 'em first, they have Chelsio front expansions by default but if you buy a Chelsio x8 PCIe card your own they need to arrange ServerU L-800 to have it perfectly fitted in their L-800 chassis, and usually it requires rear raiser replacement in their router, so talk to them first... I learned it the bad way ;] bought the chelsio card myself and found out I could not use it, since this L-800 router comes with raisers for front expansions. They were gentle enough to upgrade the raiser for free but I had to ship the box back to Florida. So talk to them... From baldur.norddahl at gmail.com Tue May 19 23:30:51 2015 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Wed, 20 May 2015 01:30:51 +0200 Subject: Low Cost 10G Router In-Reply-To: References: Message-ID: You can save a ton if you drop the requirement for full routes. Ask for a simple default route and then calculate your most used routes offline and upload that daily to the switch. I believe if you have just a few thousand routes, your outbound will be nearly the same as with full routes. Your inbound will be exactly the same, as even the smallest device can announce your prefixes. PS. ZTE has a ZXR 8900e switch with 8x 10g with 1 million routes for less than 10k USD. A ZTE 59e switch with 4x 10g with 30k routes is about 3k USD. Regards, Baldur From larrysheldon at cox.net Tue May 19 23:54:26 2015 From: larrysheldon at cox.net (Larry Sheldon) Date: Tue, 19 May 2015 18:54:26 -0500 Subject: your mail In-Reply-To: References: Message-ID: <555BCD32.6070105@cox.net> On 5/19/2015 15:37, Jared Mauch wrote: > Can someone fix the DMARC settings to something > more sensible? I've had to deal with this on the outages list > already and it's simple to have it work in a more predictable way for > users than injecting this text. > > > The best settings are Munge From, (dmarc_moderation_action) > as it will preserve the thread in a sensible way. I feel it's quite > damaging to keep injecting this into the thread. One should also clear > the dmarc_wrapped_message_text setting. Blank subject lines get routed to the spam sump here. As a matter of policy, I do not open unexpected attachments, and strong suggest that opening an unexpected attachment may be the most dangerous thing you can do with an email reader is some environments. -- sed quis custodiet ipsos custodes? (Juvenal) From zayed.mahmud at gmail.com Tue May 19 17:34:39 2015 From: zayed.mahmud at gmail.com (Zayed Mahmud) Date: Tue, 19 May 2015 23:34:39 +0600 Subject: Measuring DNS Performance & Graphing Logs Message-ID: Hello! This is my first message to NANOG's mailing list. I hope someone can help me. I was wondering which tool(s) can I use to measure the performance of my 3 DNS servers (1 primary, 1 secondary, 1 solely cacheDNS)? From the stats I would like to know if my DNS server is serving as it should be or if any of it's options are set inappropriately and others alike. I looked for a while but could not find any. Any help would be highly appreciated. I am running bind9 on UNIX platform. Question 2) I would also like to know how can I graph my DNS logs? And how can I integrate it to my CACTI server as well? I couldn't find any suitable plugin. Any suggestion? -- -- Best Regards, *Zayed Mahmud* *Senior Core & IP Network Team,* *Banglalion Communications Limited, Bangladesh.* From piotr.iwanejko at gmail.com Tue May 19 18:06:01 2015 From: piotr.iwanejko at gmail.com (Piotr Iwanejko) Date: Tue, 19 May 2015 20:06:01 +0200 Subject: Low Cost 10G Router In-Reply-To: <555B79C0.5080207@netassist.ua> References: <555B79C0.5080207@netassist.ua> Message-ID: Wiadomo?? napisana przez Max Tulyev w dniu 19 maj 2015, o godz. 19:58: > We are using softrouters based on Supermicro chassis, E5v3 cpu, > Linux/BIRD and Intel 10G NICs. And VERY happy. Out of curiosity, how much traffic you pass over those softrouters? Piotr From applebaumt at ochin.org Tue May 19 23:20:18 2015 From: applebaumt at ochin.org (Tyler Applebaum) Date: Tue, 19 May 2015 23:20:18 +0000 Subject: AT&T/Telia issue Message-ID: <25440C4BF31A8E44872003195DEB57BE954B52@omail1.community-health.org> Seeing this on AS7018 to AS1299. Anyone out there at either provider know anything about this? HOST: PC-002 Loss% Snt Last Avg Best Wrst StDev 1.|-- 172.31.255.1 0.0% 10 1 0.7 0 3 0.9 2.|-- 10.98.0.3 0.0% 10 1 1.0 1 1 0.0 3.|-- 67.51.253.17 0.0% 10 2 2.5 2 4 0.7 4.|-- 67.51.253.3 0.0% 10 1 1.2 1 2 0.4 5.|-- v202.core1.pdx1.he.net 0.0% 10 7 10.5 7 12 1.9 6.|-- 10ge12-4.core1.sea1.he.net 0.0% 10 5 5.0 5 5 0.0 7.|-- sea-b1-link.telia.net 0.0% 10 5 5.8 5 12 2.2 8.|-- den-b1-link.telia.net 0.0% 10 108 107.3 106 108 0.7 9.|-- sjo-b21-link.telia.net 20.0% 10 137 134.9 134 137 1.0 10.|-- 192.205.33.45 40.0% 10 136 136.2 135 138 1.2 11.|-- cr1.sffca.ip.att.net 10.0% 10 141 141.9 139 145 1.9 12.|-- 12.122.2.77 20.0% 10 140 140.1 137 142 2.0 13.|-- 12.122.160.149 10.0% 10 138 141.1 137 164 8.6 14.|-- 12.117.131.214 30.0% 10 139 141.0 139 145 1.9 15.|-- 199.103.47.2 30.0% 10 51 128.0 51 142 34.0 HOST: PC-002 Loss% Snt Last Avg Best Wrst StDev 1.|-- 172.31.255.1 0.0% 20 1 1.1 0 3 0.6 2.|-- 10.98.0.4 0.0% 20 1 1.3 1 4 0.7 3.|-- 67.51.253.17 0.0% 20 3 4.9 2 48 10.2 4.|-- 67.51.253.1 0.0% 20 2 1.1 1 2 0.3 5.|-- 67.51.253.11 0.0% 20 1 1.4 1 2 0.5 6.|-- v202.core1.pdx1.he.net 0.0% 20 6 9.1 1 12 3.2 7.|-- 10ge12-4.core1.sea1.he.net 0.0% 20 5 6.5 5 11 1.7 8.|-- sea-b1-link.telia.net 0.0% 20 5 5.1 5 6 0.3 9.|-- att-ic-153030-sea-b1.c.telia.net 0.0% 20 9 7.7 6 9 1.2 10.|-- cr83.st0wa.ip.att.net 5.0% 20 118 119.7 117 123 1.5 11.|-- cr2.ptdor.ip.att.net 0.0% 20 119 120.1 118 122 1.4 12.|-- cr2.sffca.ip.att.net 0.0% 20 120 119.2 117 121 1.4 13.|-- cr2.sc1ca.ip.att.net 0.0% 20 119 121.1 118 149 6.6 14.|-- 12.122.151.129 0.0% 20 118 119.8 117 122 1.5 15.|-- ??? 100.0% 20 0 0.0 0 0 0.0 16.|-- 71.157.120.39 75.0% 20 119 118.6 118 119 0.5 17.|-- 108-248-29-59.lightspeed.renonv.sbcglobal.net 5.0% 20 139 137.1 135 146 2.5 18.|-- 108-241-228-42.lightspeed.renonv.sbcglobal.net 5.0% 20 143 139.2 135 152 4.9 Attention: Information contained in this message and or attachments is intended only for the recipient(s) named above and may contain confidential and or privileged material that is protected under State or Federal law. If you are not the intended recipient, any disclosure, copying, distribution or action taken on it is prohibited. If you believe you have received this email in error, please contact the sender, delete this email and destroy all copies. From colton.conor at gmail.com Wed May 20 02:06:26 2015 From: colton.conor at gmail.com (Colton Conor) Date: Tue, 19 May 2015 21:06:26 -0500 Subject: Low Cost 10G Router In-Reply-To: <1137657451.322777.1432076600090.JavaMail.zimbra@snappytelecom.net> References: <201505192046.t4JKkG90057624@aurora.sol.net> <555B8C22.8030203@ethoplex.com> <7ACEC6BE-527E-4EFE-AE62-06701C9C9496@mtin.net> <1137657451.322777.1432076600090.JavaMail.zimbra@snappytelecom.net> Message-ID: So this new $1295 Mikrotik CCR1036-8G-2S+EM has a 36 core Tilera CPU with 16GB of ram. Each core is running at 1.2Ghz? I assume that Mikrotik is multicore in software, so why does this box not outperform these intel boxes that everyone is recommending? Is it just a limitation of ports? On Tue, May 19, 2015 at 6:03 PM, Faisal Imtiaz wrote: > > > > > I've seen serious, unusual performance bottlenecks in Mikrotik CCR, in > some > > cases not even achieving a gigabit speeds on 10G interfaces. Performance > > drops more rapidly then Cisco with smaller packet sizes. > > > > -mel beckman > > > Folks often forget that Mikrotik ROS can also run on x86 machines..... > > Size your favorite hardware (server) or network appliance with appropriate > ports, add MT ROS on a CF card, and you are good to go. > > We use i7 based network appliance with dual 10g cards (you can use a quad > 10g card, such as those made by hotlav). > > with a 2gig of ram, you can easily do multiple (4-5 or more full bgp > peers), and i7 are good for approx 1.2mill pps. > > > Best of luck. > > > Faisal Imtiaz > Snappy Internet & Telecom > From morrowc.lists at gmail.com Wed May 20 02:32:50 2015 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Tue, 19 May 2015 22:32:50 -0400 Subject: Measuring DNS Performance & Graphing Logs In-Reply-To: References: Message-ID: http://docs.cacti.net/usertemplate%3ahost%3abind9.7 http://forums.cacti.net/about6332.html those are like result 1 and 5 of "cacti graph dns server" in the googles... (the second is even the 1st result in a bingz search) On Tue, May 19, 2015 at 1:34 PM, Zayed Mahmud wrote: > Hello! > This is my first message to NANOG's mailing list. I hope someone can help > me. > > I was wondering which tool(s) can I use to measure the performance of my 3 > DNS servers (1 primary, 1 secondary, 1 solely cacheDNS)? From the stats I > would like to know if my DNS server is serving as it should be or if any of > it's options are set inappropriately and others alike. > > I looked for a while but could not find any. Any help would be highly > appreciated. I am running bind9 on UNIX platform. > > Question 2) I would also like to know how can I graph my DNS logs? And how > can I integrate it to my CACTI server as well? I couldn't find any suitable > plugin. Any suggestion? > > -- > > -- > Best Regards, > > *Zayed Mahmud* > > *Senior Core & IP Network Team,* > > *Banglalion Communications Limited, Bangladesh.* From joshbaird at gmail.com Wed May 20 02:49:17 2015 From: joshbaird at gmail.com (Josh Baird) Date: Tue, 19 May 2015 22:49:17 -0400 Subject: Low Cost 10G Router In-Reply-To: References: <201505192046.t4JKkG90057624@aurora.sol.net> <555B8C22.8030203@ethoplex.com> <7ACEC6BE-527E-4EFE-AE62-06701C9C9496@mtin.net> <1137657451.322777.1432076600090.JavaMail.zimbra@snappytelecom.net> Message-ID: The BGP daemon on the CCR routers is not multi-threaded; it only will use one core. Josh On Tue, May 19, 2015 at 10:06 PM, Colton Conor wrote: > So this new $1295 Mikrotik CCR1036-8G-2S+EM has a 36 core Tilera CPU with > 16GB of ram. Each core is running at 1.2Ghz? I assume that Mikrotik is > multicore in software, so why does this box not outperform these intel > boxes that everyone is recommending? Is it just a limitation of ports? > > > > On Tue, May 19, 2015 at 6:03 PM, Faisal Imtiaz > wrote: > > > > > > > > > > I've seen serious, unusual performance bottlenecks in Mikrotik CCR, in > > some > > > cases not even achieving a gigabit speeds on 10G interfaces. > Performance > > > drops more rapidly then Cisco with smaller packet sizes. > > > > > > -mel beckman > > > > > > Folks often forget that Mikrotik ROS can also run on x86 machines..... > > > > Size your favorite hardware (server) or network appliance with > appropriate > > ports, add MT ROS on a CF card, and you are good to go. > > > > We use i7 based network appliance with dual 10g cards (you can use a quad > > 10g card, such as those made by hotlav). > > > > with a 2gig of ram, you can easily do multiple (4-5 or more full bgp > > peers), and i7 are good for approx 1.2mill pps. > > > > > > Best of luck. > > > > > > Faisal Imtiaz > > Snappy Internet & Telecom > > > From mark.tinka at seacom.mu Wed May 20 05:55:07 2015 From: mark.tinka at seacom.mu (Mark Tinka) Date: Wed, 20 May 2015 07:55:07 +0200 Subject: Low Cost 10G Router In-Reply-To: References: <5D499B18-1134-43CD-8B09-9118E3CACAEA@akcin.net> Message-ID: <555C21BB.7090002@seacom.mu> On 19/May/15 19:35, Colton Conor wrote: > As low as possible, though I am not sure how low that can be. > > For example, I can get a MX480 used with a 4 10G card for $16K. That would > easily handle my needs, but it's overkill for what we need to do. > > I would love a solution under 10K, but not sure if one exists. If you can get an MX480 with 4x 10Gbps ports at that price, I'd take it. Might seem like too much now, but when you need to grow, having that chassis will come in very handy. The problem with boxes like the MX80, MX104 and ASR9001 is while they meet what you want now, they'll struggle because expansion is fixed (how's that for an oxymoron). That US$6,000 you'll save now will be more costly when you plan the upgrades in the future. Mark. From mark.tinka at seacom.mu Wed May 20 05:59:04 2015 From: mark.tinka at seacom.mu (Mark Tinka) Date: Wed, 20 May 2015 07:59:04 +0200 Subject: Low Cost 10G Router In-Reply-To: References: Message-ID: <555C22A8.9030905@seacom.mu> On 19/May/15 20:46, Ray Soucy wrote: > > An ASR1K might do the trick, but more likely than not you're looking at an > ASR9K if you want full tables; I don't have any experience with the 1K > personally so I can't speak to that. The ASR 9K is a really great platform > and is what we use for BGP here, but it's pretty much the opposite of cheap. The ASR1000 is a very good box, but I tend to prefer them for low-speed services, which are generally non-Ethernet in nature, e.g., downstream customers coming in via SDH. They do support 10Gbps ports, but that is a 1-port SPA; and the most you can have in today's SIP's (carrier cards) would be 4x 1-port SPA's. So not very dense. Their forwarding planes start at 2.5Gbps (fixed) all the way to 200Gbps (13-slot chassis). But you're more likely to run out of high-speed ports before you stress a 200Gbps forwarding plane on that chassis. So if the applications are purely Ethernet, I'd not consider the ASR1000. But if there is a mix-and-match for Ethernet and non-Ethernet ports, it's the perfect box. That and the MX104. Mark. From mark.tinka at seacom.mu Wed May 20 06:01:41 2015 From: mark.tinka at seacom.mu (Mark Tinka) Date: Wed, 20 May 2015 08:01:41 +0200 Subject: Low Cost 10G Router In-Reply-To: <6632909F-4742-4C7C-A3DD-A73972DDCBA0@1telecom.com.br> References: <201505192046.t4JKkG90057624@aurora.sol.net> <20150519191120.GA15859@sizone.org> <1fe23c98430bcdbccd21c93de7bbee75@thefnf.org> <6632909F-4742-4C7C-A3DD-A73972DDCBA0@1telecom.com.br> Message-ID: <555C2345.5030108@seacom.mu> On 19/May/15 23:59, Rodrigo 1telecom wrote: > I know if is not possible to have a full routing on ex3300(low memory for it) , but i never tried to do a default router on it( with EFL licence and software above version 12) > I have many bgp session with cisco 3750 switchs.. Traffic about 2gb on it... Have a peer( ebgp customer) with a acx2000( i know it have 10gb port) we send to this router a default route only... And it have 1.5gb with us and more 1gb with other link provider... If you need a full table in FIB, then you're stuffed with any switch vendor out there. But if your switch vendor is able to hold the full table in RIB, and allow you to selectively hold chosen routes in FIB, then you could get away with lots of 10Gbps-capable switches at a reasonable price. Mark. From marktees at gmail.com Wed May 20 06:32:55 2015 From: marktees at gmail.com (Mark Tees) Date: Wed, 20 May 2015 16:32:55 +1000 Subject: Low Cost 10G Router In-Reply-To: <555C22A8.9030905@seacom.mu> References: <555C22A8.9030905@seacom.mu> Message-ID: For the lists benefit, there is a 6 X 10GBE option for the ASR1000 series it seems. No idea on pricing though. http://www.cisco.com/c/en/us/products/collateral/application-networking-services/wide-area-application-services-waas-software/data-sheet-c78-729778.pdf Cheers, Mark On Wed, May 20, 2015 at 3:59 PM, Mark Tinka wrote: > > > On 19/May/15 20:46, Ray Soucy wrote: >> >> An ASR1K might do the trick, but more likely than not you're looking at an >> ASR9K if you want full tables; I don't have any experience with the 1K >> personally so I can't speak to that. The ASR 9K is a really great platform >> and is what we use for BGP here, but it's pretty much the opposite of cheap. > > The ASR1000 is a very good box, but I tend to prefer them for low-speed > services, which are generally non-Ethernet in nature, e.g., downstream > customers coming in via SDH. > > They do support 10Gbps ports, but that is a 1-port SPA; and the most you > can have in today's SIP's (carrier cards) would be 4x 1-port SPA's. So > not very dense. > > Their forwarding planes start at 2.5Gbps (fixed) all the way to 200Gbps > (13-slot chassis). But you're more likely to run out of high-speed ports > before you stress a 200Gbps forwarding plane on that chassis. > > So if the applications are purely Ethernet, I'd not consider the > ASR1000. But if there is a mix-and-match for Ethernet and non-Ethernet > ports, it's the perfect box. That and the MX104. > > Mark. -- Regards, Mark L. Tees From jeff.tantsura at ericsson.com Wed May 20 06:54:07 2015 From: jeff.tantsura at ericsson.com (Jeff Tantsura) Date: Wed, 20 May 2015 06:54:07 +0000 Subject: Low Cost 10G Router In-Reply-To: References: <555C22A8.9030905@seacom.mu>, Message-ID: <37ACD365-4833-4254-867B-2B21CAE2E0D6@ericsson.com> ASR1K (XE) has great BGP implementation, go for it if you are OK with density/throughput. Regards, Jeff > On May 19, 2015, at 11:35 PM, Mark Tees wrote: > > For the lists benefit, there is a 6 X 10GBE option for the ASR1000 > series it seems. No idea on pricing though. > > http://www.cisco.com/c/en/us/products/collateral/application-networking-services/wide-area-application-services-waas-software/data-sheet-c78-729778.pdf > > Cheers, > > Mark > > >> On Wed, May 20, 2015 at 3:59 PM, Mark Tinka wrote: >> >> >>> On 19/May/15 20:46, Ray Soucy wrote: >>> >>> An ASR1K might do the trick, but more likely than not you're looking at an >>> ASR9K if you want full tables; I don't have any experience with the 1K >>> personally so I can't speak to that. The ASR 9K is a really great platform >>> and is what we use for BGP here, but it's pretty much the opposite of cheap. >> >> The ASR1000 is a very good box, but I tend to prefer them for low-speed >> services, which are generally non-Ethernet in nature, e.g., downstream >> customers coming in via SDH. >> >> They do support 10Gbps ports, but that is a 1-port SPA; and the most you >> can have in today's SIP's (carrier cards) would be 4x 1-port SPA's. So >> not very dense. >> >> Their forwarding planes start at 2.5Gbps (fixed) all the way to 200Gbps >> (13-slot chassis). But you're more likely to run out of high-speed ports >> before you stress a 200Gbps forwarding plane on that chassis. >> >> So if the applications are purely Ethernet, I'd not consider the >> ASR1000. But if there is a mix-and-match for Ethernet and non-Ethernet >> ports, it's the perfect box. That and the MX104. >> >> Mark. > > > > -- > Regards, > > Mark L. Tees From mark.tinka at seacom.mu Wed May 20 06:56:49 2015 From: mark.tinka at seacom.mu (Mark Tinka) Date: Wed, 20 May 2015 08:56:49 +0200 Subject: Low Cost 10G Router In-Reply-To: <37ACD365-4833-4254-867B-2B21CAE2E0D6@ericsson.com> References: <555C22A8.9030905@seacom.mu>, <37ACD365-4833-4254-867B-2B21CAE2E0D6@ericsson.com> Message-ID: <555C3031.2010707@seacom.mu> On 20/May/15 08:54, Jeff Tantsura wrote: > ASR1K (XE) has great BGP implementation, go for it if you are OK with density/throughput. I second that. BGP for IOS XE is very mature (except RPKI, which has just got a fix). Mark. From andrew.william.smith at gmail.com Wed May 20 07:47:33 2015 From: andrew.william.smith at gmail.com (Andrew Smith) Date: Wed, 20 May 2015 02:47:33 -0500 Subject: Measuring DNS Performance & Graphing Logs In-Reply-To: References: Message-ID: Smokeping (http://oss.oetiker.ch/smokeping/) can graph DNS response latency via dig. ThousandEyes (https://www.thousandeyes.com/) has some commercial options for monitoring DNS server responsiveness, and zone performance from different vantage points throughout the globe. On Tue, May 19, 2015 at 12:34 PM, Zayed Mahmud wrote: > Hello! > This is my first message to NANOG's mailing list. I hope someone can help > me. > > I was wondering which tool(s) can I use to measure the performance of my 3 > DNS servers (1 primary, 1 secondary, 1 solely cacheDNS)? From the stats I > would like to know if my DNS server is serving as it should be or if any of > it's options are set inappropriately and others alike. > > I looked for a while but could not find any. Any help would be highly > appreciated. I am running bind9 on UNIX platform. > > Question 2) I would also like to know how can I graph my DNS logs? And how > can I integrate it to my CACTI server as well? I couldn't find any suitable > plugin. Any suggestion? > > -- > > -- > Best Regards, > > *Zayed Mahmud* > > *Senior Core & IP Network Team,* > > *Banglalion Communications Limited, Bangladesh.* > From xxnog at ledeuns.net Wed May 20 08:22:57 2015 From: xxnog at ledeuns.net (Denis Fondras) Date: Wed, 20 May 2015 10:22:57 +0200 Subject: Measuring DNS Performance & Graphing Logs In-Reply-To: References: Message-ID: <20150520082256.GB4181@belenos> > I was wondering which tool(s) can I use to measure the performance of my 3 > DNS servers (1 primary, 1 secondary, 1 solely cacheDNS)? From the stats I > would like to know if my DNS server is serving as it should be or if any of > it's options are set inappropriately and others alike. Perhaps http://dns.measurement-factory.com/tools/dsc/ (used by AS112) can help. Denis From dudu.meyer at gmail.com Wed May 20 12:41:02 2015 From: dudu.meyer at gmail.com (Eduardo Meyer) Date: Wed, 20 May 2015 09:41:02 -0300 Subject: Low Cost 10G Router In-Reply-To: References: <5D499B18-1134-43CD-8B09-9118E3CACAEA@akcin.net> Message-ID: On Tuesday, May 19, 2015, Warsaw wrote: > > > On May 19, 2015, at 10:22, Colton Conor > wrote: > > > > > > What options are available for a small, low cost router that has at > least > > > four 10G ports, and can handle full BGP routes? All that I know of are > the > > > Juniper MX80, and the Brocade CER line. What does Cisco and others have > > > that compete with these two? Any other vendors besides Juniper, > Brocade, > > > and Cisco to look at? > > I have two ServerU L-800 boxes routing BGP and OSPF, one of those has > 4x10G SFP+ port and the I'm good w/ ServerU L-800 as well running BGP with FreeBSD in a location and VyOS in a couple other. I still dont know how much traffic Mr Conor needs to forward, if it's a 10G base or just needs 10G ports. Without Chelsio ASICS I route 4Gb/s on this router and I second the suggestion for L-800 if the desired forwarding rate is around 4Gbit. I didnt know Chelsio expansions could do forwarding directly on the card. just heard about its low rate of interruption requests. Sounds like it worths further investigation thanks on that.. As for L-800 I run it for over one year now doing BGP and firewalling. Great value for a twelve hundred bucks purchase. > It's a 1,200 USD starting cost for a very decent router which promisses to > delivery a good pps and bps rate specially when compared to Mikrotik's CCR > and other Cisco/Brocade routers on this same grade. Add to it a couple > hundred extra bucks to have a very decent Chelsio T5 ASICS expansion to > L800 chassis and you pretty much have a system that, according to Chelsion > data sheet, promisses to delivery 27 milion packets per second filtered and > forwarded. Pretty much Line Rate for 10G ports. > > I don't know about the expected 27Mpps per port, but I can confirm 4.8Mpps > peaking / 4.2Mpps avging on my rack everyday, and for the price I pay on > this ServerU + FreeBSD setup I can't avoid to suggest it worths pretty much > a try! > > http://www.serveru.us/en/netmapl800 > > If you buy a Chelsio card or already have it, or have it at a better price > (sometimes we find very good 300.00 USD deals on chelsio T5, while their > list price is ~900.00 USD) talk to 'em first, they have Chelsio front > expansions by default but if you buy a Chelsio x8 PCIe card your own they > need to arrange ServerU L-800 to have it perfectly fitted in their L-800 > chassis, and usually it requires rear raiser replacement in their router, > so talk to them first... I learned it the bad way ;] bought the chelsio > card myself and found out I could not use it, since this L-800 router comes > with raisers for front expansions. They were gentle enough to upgrade the > raiser for free but I had to ship the box back to Florida. So talk to > them... > > > > > > > > > > > > > > > > -- =========== Eduardo Meyer pessoal: dudu.meyer at gmail.com profissional: ddm.farmaciap at saude.gov.br From rps at maine.edu Wed May 20 13:08:01 2015 From: rps at maine.edu (Ray Soucy) Date: Wed, 20 May 2015 09:08:01 -0400 Subject: Low Cost 10G Router In-Reply-To: <201505192046.t4JKkG90057624@aurora.sol.net> References: <201505192046.t4JKkG90057624@aurora.sol.net> Message-ID: You're right I dropped down to the v2 for pricing reasons: - Supermicro SuperServer 5017R-MTRF - 4x SATA - 8x DDR3 - 400W Redundant - Eight-Core Intel Xeon Processor E5-2640 v2 2.00GHz 20MB Cache (95W) - 4 x SAMSUNG 2GB PC3-12800 DDR3-160 - 2 x 500GB SATA 6.0Gb/s 7200RPM - 3.5" - Western Digital RE4 WD5003ABYZ - Supermicro System Cabinet Front Bezel CSE-PTFB-813B with Lock and Filter (Black) - No Windows Operating System (Hardware Warranty Only, No Software Support) - Three Year Warranty with Advanced Parts Replacement FWIW I used Sourcecode as the system builder. They've been great to work with. On Tue, May 19, 2015 at 4:46 PM, Joe Greco wrote: > > How cheap is cheap and what performance numbers are you looking for? > > > > About as cheap as you can get: > > > > For about $3,000 you can build a Supermicro OEM system with an 8-core > Xeon > > E5 V3 and 4-port 10G Intel SFP+ NIC with 8G of RAM running VyOS. The pro > > is that BGP convergence time will be good (better than a 7200 VXR), and > > number of tables likely won't be a concern since RAM is cheap. The con > is > > that you're not doing things in hardware, so you'll have higher latency, > > and your PPS will be lower. > > What 8 core Xeon E5 v3 would that be? The 26xx's are hideously pricey, > and for a router, you're probably better off with something like a > Supermicro X10SRn fsvo "n" with a Xeon E5-1650v3. Board is typically > around $300, 1650 is around $550, so total cost I'm guessing closer to > $1500-$2000 that route. > > The edge you get there is the higher clock on the CPU. Only six cores > and only 15M cache, but 3.5GHz. The E5-2643v3 is three times the cost > for very similar performance specs. Costwise, E5 single socket is the > way to go unless you *need* more. > > ... 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. > -- Ray Patrick Soucy Network Engineer University of Maine System T: 207-561-3526 F: 207-561-3531 MaineREN, Maine's Research and Education Network www.maineren.net From rps at maine.edu Wed May 20 13:13:53 2015 From: rps at maine.edu (Ray Soucy) Date: Wed, 20 May 2015 09:13:53 -0400 Subject: Low Cost 10G Router In-Reply-To: References: <201505192046.t4JKkG90057624@aurora.sol.net> Message-ID: P.S I went through HotLava Systems for the Intel-based SFP+ NICs to add to those, http://hotlavasystems.com/ (not trying to plug; these are just hard to find) On Wed, May 20, 2015 at 9:08 AM, Ray Soucy wrote: > You're right I dropped down to the v2 for pricing reasons: > > - Supermicro SuperServer 5017R-MTRF > - 4x SATA > - 8x DDR3 > - 400W Redundant > - Eight-Core Intel Xeon Processor E5-2640 v2 2.00GHz 20MB Cache (95W) > - 4 x SAMSUNG 2GB PC3-12800 DDR3-160 > - 2 x 500GB SATA 6.0Gb/s 7200RPM - 3.5" - Western Digital RE4 WD5003ABYZ > - Supermicro System Cabinet Front Bezel CSE-PTFB-813B with Lock and Filter > (Black) > - No Windows Operating System (Hardware Warranty Only, No Software Support) > - Three Year Warranty with Advanced Parts Replacement > > FWIW I used Sourcecode as the system builder. They've been great to work > with. > > On Tue, May 19, 2015 at 4:46 PM, Joe Greco wrote: > >> > How cheap is cheap and what performance numbers are you looking for? >> > >> > About as cheap as you can get: >> > >> > For about $3,000 you can build a Supermicro OEM system with an 8-core >> Xeon >> > E5 V3 and 4-port 10G Intel SFP+ NIC with 8G of RAM running VyOS. The >> pro >> > is that BGP convergence time will be good (better than a 7200 VXR), and >> > number of tables likely won't be a concern since RAM is cheap. The con >> is >> > that you're not doing things in hardware, so you'll have higher latency, >> > and your PPS will be lower. >> >> What 8 core Xeon E5 v3 would that be? The 26xx's are hideously pricey, >> and for a router, you're probably better off with something like a >> Supermicro X10SRn fsvo "n" with a Xeon E5-1650v3. Board is typically >> around $300, 1650 is around $550, so total cost I'm guessing closer to >> $1500-$2000 that route. >> >> The edge you get there is the higher clock on the CPU. Only six cores >> and only 15M cache, but 3.5GHz. The E5-2643v3 is three times the cost >> for very similar performance specs. Costwise, E5 single socket is the >> way to go unless you *need* more. >> >> ... 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. >> > > > > -- > Ray Patrick Soucy > Network Engineer > University of Maine System > > T: 207-561-3526 > F: 207-561-3531 > > MaineREN, Maine's Research and Education Network > www.maineren.net > -- Ray Patrick Soucy Network Engineer University of Maine System T: 207-561-3526 F: 207-561-3531 MaineREN, Maine's Research and Education Network www.maineren.net From pavel.odintsov at gmail.com Wed May 20 13:17:16 2015 From: pavel.odintsov at gmail.com (Pavel Odintsov) Date: Wed, 20 May 2015 16:17:16 +0300 Subject: Low Cost 10G Router In-Reply-To: References: <201505192046.t4JKkG90057624@aurora.sol.net> Message-ID: Hello! Ray, I could suggest switch from multi physical CPU configuration to single. Like Intel Xeon E5-1650/1660/1680 or even Xeon E3 platforms. Because multi processor systems need really huge amount of knowledge for NUMA configuration and PCI-E devices assignment for each NUMA. Secondly, I could vote many times for Supermicro! :) Dell or HP are really ugly systems for soft routers. CPU frequency tuning, PCM debugging are real nightmare on this systems. Please beware of they! Supermicro is very clear and do not block useful functions of platform. On Wed, May 20, 2015 at 4:08 PM, Ray Soucy wrote: > You're right I dropped down to the v2 for pricing reasons: > > - Supermicro SuperServer 5017R-MTRF > - 4x SATA > - 8x DDR3 > - 400W Redundant > - Eight-Core Intel Xeon Processor E5-2640 v2 2.00GHz 20MB Cache (95W) > - 4 x SAMSUNG 2GB PC3-12800 DDR3-160 > - 2 x 500GB SATA 6.0Gb/s 7200RPM - 3.5" - Western Digital RE4 WD5003ABYZ > - Supermicro System Cabinet Front Bezel CSE-PTFB-813B with Lock and Filter > (Black) > - No Windows Operating System (Hardware Warranty Only, No Software Support) > - Three Year Warranty with Advanced Parts Replacement > > FWIW I used Sourcecode as the system builder. They've been great to work > with. > > On Tue, May 19, 2015 at 4:46 PM, Joe Greco wrote: > >> > How cheap is cheap and what performance numbers are you looking for? >> > >> > About as cheap as you can get: >> > >> > For about $3,000 you can build a Supermicro OEM system with an 8-core >> Xeon >> > E5 V3 and 4-port 10G Intel SFP+ NIC with 8G of RAM running VyOS. The pro >> > is that BGP convergence time will be good (better than a 7200 VXR), and >> > number of tables likely won't be a concern since RAM is cheap. The con >> is >> > that you're not doing things in hardware, so you'll have higher latency, >> > and your PPS will be lower. >> >> What 8 core Xeon E5 v3 would that be? The 26xx's are hideously pricey, >> and for a router, you're probably better off with something like a >> Supermicro X10SRn fsvo "n" with a Xeon E5-1650v3. Board is typically >> around $300, 1650 is around $550, so total cost I'm guessing closer to >> $1500-$2000 that route. >> >> The edge you get there is the higher clock on the CPU. Only six cores >> and only 15M cache, but 3.5GHz. The E5-2643v3 is three times the cost >> for very similar performance specs. Costwise, E5 single socket is the >> way to go unless you *need* more. >> >> ... 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. >> > > > > -- > Ray Patrick Soucy > Network Engineer > University of Maine System > > T: 207-561-3526 > F: 207-561-3531 > > MaineREN, Maine's Research and Education Network > www.maineren.net -- Sincerely yours, Pavel Odintsov From codygrosskopf at gmail.com Wed May 20 13:32:31 2015 From: codygrosskopf at gmail.com (Cody Grosskopf) Date: Wed, 20 May 2015 13:32:31 +0000 Subject: Low Cost 10G Router In-Reply-To: References: Message-ID: I haven't tried myself but some of the stuff Cumulus Linux is doing is pretty amazing, not certain quagga can or should handle full bgp table but you could probably get a Penguin 10gbe for less than 8k. On Tue, May 19, 2015, 10:25 AM Colton Conor wrote: > What options are available for a small, low cost router that has at least > four 10G ports, and can handle full BGP routes? All that I know of are the > Juniper MX80, and the Brocade CER line. What does Cisco and others have > that compete with these two? Any other vendors besides Juniper, Brocade, > and Cisco to look at? > From nick at foobar.org Wed May 20 13:41:04 2015 From: nick at foobar.org (Nick Hilliard) Date: Wed, 20 May 2015 14:41:04 +0100 Subject: Low Cost 10G Router In-Reply-To: References: Message-ID: <555C8EF0.5020205@foobar.org> On 20/05/2015 14:32, Cody Grosskopf wrote: > I haven't tried myself but some of the stuff Cumulus Linux is doing is > pretty amazing, not certain quagga can or should handle full bgp table but > you could probably get a Penguin 10gbe for less than 8k. quagga (or whatever RIB manager you want, e.g. bird) isn't the issue. The issue is that these switches have limited hardware FIB capacity and if you attempt to put a full table on them, they won't accept it. Nick From pavel.odintsov at gmail.com Wed May 20 13:42:28 2015 From: pavel.odintsov at gmail.com (Pavel Odintsov) Date: Wed, 20 May 2015 16:42:28 +0300 Subject: Low Cost 10G Router In-Reply-To: References: Message-ID: I have tried Cumulus. It's awesome! :) You definitely could run Quagga, Bird or even ExaBGP https://github.com/Exa-Networks/exabgp and build full feature router from 10GE switch. On Wed, May 20, 2015 at 4:32 PM, Cody Grosskopf wrote: > I haven't tried myself but some of the stuff Cumulus Linux is doing is > pretty amazing, not certain quagga can or should handle full bgp table but > you could probably get a Penguin 10gbe for less than 8k. > > On Tue, May 19, 2015, 10:25 AM Colton Conor wrote: > >> What options are available for a small, low cost router that has at least >> four 10G ports, and can handle full BGP routes? All that I know of are the >> Juniper MX80, and the Brocade CER line. What does Cisco and others have >> that compete with these two? Any other vendors besides Juniper, Brocade, >> and Cisco to look at? >> -- Sincerely yours, Pavel Odintsov From pavel.odintsov at gmail.com Wed May 20 13:46:12 2015 From: pavel.odintsov at gmail.com (Pavel Odintsov) Date: Wed, 20 May 2015 16:46:12 +0300 Subject: Low Cost 10G Router In-Reply-To: <555C8EF0.5020205@foobar.org> References: <555C8EF0.5020205@foobar.org> Message-ID: We could cut full BGP and select only important prefixes with ExaBGP. On Wed, May 20, 2015 at 4:41 PM, Nick Hilliard wrote: > On 20/05/2015 14:32, Cody Grosskopf wrote: >> I haven't tried myself but some of the stuff Cumulus Linux is doing is >> pretty amazing, not certain quagga can or should handle full bgp table but >> you could probably get a Penguin 10gbe for less than 8k. > > quagga (or whatever RIB manager you want, e.g. bird) isn't the issue. The > issue is that these switches have limited hardware FIB capacity and if you > attempt to put a full table on them, they won't accept it. > > Nick > > -- Sincerely yours, Pavel Odintsov From nick at foobar.org Wed May 20 13:53:44 2015 From: nick at foobar.org (Nick Hilliard) Date: Wed, 20 May 2015 14:53:44 +0100 Subject: Low Cost 10G Router In-Reply-To: References: <555C8EF0.5020205@foobar.org> Message-ID: <555C91E8.6050904@foobar.org> On 20/05/2015 14:46, Pavel Odintsov wrote: > We could cut full BGP and select only important prefixes with ExaBGP. exabgp is rib mgmt only and doesn't program the fib. you will need quagga / bird / etc for this. Nick From pavel.odintsov at gmail.com Wed May 20 13:56:01 2015 From: pavel.odintsov at gmail.com (Pavel Odintsov) Date: Wed, 20 May 2015 16:56:01 +0300 Subject: Low Cost 10G Router In-Reply-To: <555C91E8.6050904@foobar.org> References: <555C8EF0.5020205@foobar.org> <555C91E8.6050904@foobar.org> Message-ID: Yes, right! But ExaBGP could receive full BGP table, drop some rules and reflect they to Quagga which could load FIB on the Cumulus. On Wed, May 20, 2015 at 4:53 PM, Nick Hilliard wrote: > On 20/05/2015 14:46, Pavel Odintsov wrote: >> We could cut full BGP and select only important prefixes with ExaBGP. > > exabgp is rib mgmt only and doesn't program the fib. you will need quagga > / bird / etc for this. > > Nick > -- Sincerely yours, Pavel Odintsov From nick at foobar.org Wed May 20 13:57:59 2015 From: nick at foobar.org (Nick Hilliard) Date: Wed, 20 May 2015 14:57:59 +0100 Subject: Low Cost 10G Router In-Reply-To: References: <555C8EF0.5020205@foobar.org> <555C91E8.6050904@foobar.org> Message-ID: <555C92E7.1070600@foobar.org> On 20/05/2015 14:56, Pavel Odintsov wrote: > Yes, right! But ExaBGP could receive full BGP table, drop some rules > and reflect they to Quagga which could load FIB on the Cumulus. or you could not bother with exabgp and do your route filtering on quagga. Nothing wrong with exabgp, btw. Great product. It's just the wrong tool for the job here. Nick From pavel.odintsov at gmail.com Wed May 20 14:00:59 2015 From: pavel.odintsov at gmail.com (Pavel Odintsov) Date: Wed, 20 May 2015 17:00:59 +0300 Subject: Low Cost 10G Router In-Reply-To: <555C92E7.1070600@foobar.org> References: <555C8EF0.5020205@foobar.org> <555C91E8.6050904@foobar.org> <555C92E7.1070600@foobar.org> Message-ID: Yes, you could do filtering with Quagga. But Quagga is pretty old tool without multiple dynamic features. But with ExaBGP you could do really any significant route table transformations with Python in few lines of code. But it's definitely add additional point of failure/bug. On Wed, May 20, 2015 at 4:57 PM, Nick Hilliard wrote: > On 20/05/2015 14:56, Pavel Odintsov wrote: >> Yes, right! But ExaBGP could receive full BGP table, drop some rules >> and reflect they to Quagga which could load FIB on the Cumulus. > > or you could not bother with exabgp and do your route filtering on quagga. > > Nothing wrong with exabgp, btw. Great product. It's just the wrong tool > for the job here. > > Nick > > -- Sincerely yours, Pavel Odintsov From aledm at qix.co.uk Wed May 20 14:25:24 2015 From: aledm at qix.co.uk (Aled Morris) Date: Wed, 20 May 2015 15:25:24 +0100 Subject: Low Cost 10G Router In-Reply-To: References: <555C8EF0.5020205@foobar.org> <555C91E8.6050904@foobar.org> <555C92E7.1070600@foobar.org> Message-ID: On 20 May 2015 at 15:00, Pavel Odintsov wrote: > Yes, you could do filtering with Quagga. But Quagga is pretty old tool > without multiple dynamic features. But with ExaBGP you could do really > any significant route table transformations with Python in few lines > of code. But it's definitely add additional point of failure/bug. > Couldn't your back-end scripts running under ExaBGP also manage the FIB, using standard Unix tools/APIs? Managing the FIB is basically just "route add" and "route delete" right? Aled From charles at thefnf.org Wed May 20 14:26:28 2015 From: charles at thefnf.org (charles at thefnf.org) Date: Wed, 20 May 2015 09:26:28 -0500 Subject: Low Cost 10G Router In-Reply-To: References: <201505192046.t4JKkG90057624@aurora.sol.net> Message-ID: <6c00cbc40fba3310d3e34e199bd52a93@thefnf.org> On 2015-05-20 08:17, Pavel Odintsov wrote: > Hello! > > Ray, I could suggest switch from multi physical CPU configuration to > single. Like Intel Xeon E5-1650/1660/1680 or even Xeon E3 platforms. > Because multi processor systems need really huge amount of knowledge > for NUMA configuration and PCI-E devices assignment for each NUMA. Not really. Well that's opinion I suppose. It didn't seem like that steep of a learning curve. Just need to play with taskset and do some reading. If you are just starting out and experimenting, then sure a single CPU system would probably be the way to go. > > Secondly, I could vote many times for Supermicro! :) Dell or HP are > really ugly systems for soft routers. CPU frequency tuning, PCM > debugging are real nightmare on this systems. And why is that any different on a supermicro system? Isn't it all the same hardware? I personally would recommend buying from Dell or HP, as they things like 4hr turn around times (at least in the major urban centers, usually it's about an hour). I don't know how good Supermicro purchase/procurement system is. Dell has some neat things for asset management, support etc. HP probably has the same. Please beware of they! > > Supermicro is very clear and do not block useful functions of platform. > What don't they "block"? What vendors block things, and what things do they block? From applebaumt at ochin.org Wed May 20 14:41:46 2015 From: applebaumt at ochin.org (Tyler Applebaum) Date: Wed, 20 May 2015 14:41:46 +0000 Subject: AT&T/Telia issue In-Reply-To: <25440C4BF31A8E44872003195DEB57BE954B52@omail1.community-health.org> References: <25440C4BF31A8E44872003195DEB57BE954B52@omail1.community-health.org> Message-ID: <25440C4BF31A8E44872003195DEB57BE9596A9@omail1.community-health.org> Still seeing this as of 7:40AM PST. Looks isolated to AT&T and Telia in Seattle. HOST: PC-002 Loss% Snt Last Avg Best Wrst StDev 1.|-- 172.31.255.1 0.0% 10 0 0.8 0 3 0.9 2.|-- 10.98.0.4 0.0% 10 1 1.5 1 4 1.1 3.|-- 67.51.253.17 0.0% 10 6 2.8 2 6 1.2 4.|-- 67.51.253.1 0.0% 10 2 1.4 1 2 0.5 5.|-- 67.51.253.3 0.0% 10 2 1.3 1 2 0.5 6.|-- v202.core1.pdx1.he.net 0.0% 10 1 2.0 1 4 1.2 7.|-- 10ge12-4.core1.sea1.he.net 0.0% 10 9 10.9 9 13 1.0 8.|-- sea-b1-link.telia.net 50.0% 10 42 42.0 42 42 0.0 9.|-- att-ic-153030-sea-b1.c.telia.net 50.0% 10 46 44.8 43 46 1.3 10.|-- cr84.st0wa.ip.att.net 40.0% 10 71 73.8 71 76 1.8 11.|-- cr2.st6wa.ip.att.net 40.0% 10 74 73.7 72 75 1.2 12.|-- 12.122.158.146 70.0% 10 74 73.7 73 74 0.6 13.|-- 12.122.158.157 50.0% 10 71 71.0 71 71 0.0 14.|-- 12.248.207.6 20.0% 10 71 71.0 71 71 0.0 15.|-- ancr-5-1-12-12.attalascom.net 30.0% 10 71 71.0 71 71 0.0 16.|-- 66-2-12-12.attalascom.net 30.0% 10 85 85.3 85 86 0.5 17.|-- KCHC-42-7-12-12.attalascom.net 30.0% 10 95 95.6 95 96 0.5 -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Tyler Applebaum Sent: Tuesday, May 19, 2015 4:20 PM To: nanog at nanog.org Subject: AT&T/Telia issue Seeing this on AS7018 to AS1299. Anyone out there at either provider know anything about this? HOST: PC-002 Loss% Snt Last Avg Best Wrst StDev 1.|-- 172.31.255.1 0.0% 10 1 0.7 0 3 0.9 2.|-- 10.98.0.3 0.0% 10 1 1.0 1 1 0.0 3.|-- 67.51.253.17 0.0% 10 2 2.5 2 4 0.7 4.|-- 67.51.253.3 0.0% 10 1 1.2 1 2 0.4 5.|-- v202.core1.pdx1.he.net 0.0% 10 7 10.5 7 12 1.9 6.|-- 10ge12-4.core1.sea1.he.net 0.0% 10 5 5.0 5 5 0.0 7.|-- sea-b1-link.telia.net 0.0% 10 5 5.8 5 12 2.2 8.|-- den-b1-link.telia.net 0.0% 10 108 107.3 106 108 0.7 9.|-- sjo-b21-link.telia.net 20.0% 10 137 134.9 134 137 1.0 10.|-- 192.205.33.45 40.0% 10 136 136.2 135 138 1.2 11.|-- cr1.sffca.ip.att.net 10.0% 10 141 141.9 139 145 1.9 12.|-- 12.122.2.77 20.0% 10 140 140.1 137 142 2.0 13.|-- 12.122.160.149 10.0% 10 138 141.1 137 164 8.6 14.|-- 12.117.131.214 30.0% 10 139 141.0 139 145 1.9 15.|-- 199.103.47.2 30.0% 10 51 128.0 51 142 34.0 HOST: PC-002 Loss% Snt Last Avg Best Wrst StDev 1.|-- 172.31.255.1 0.0% 20 1 1.1 0 3 0.6 2.|-- 10.98.0.4 0.0% 20 1 1.3 1 4 0.7 3.|-- 67.51.253.17 0.0% 20 3 4.9 2 48 10.2 4.|-- 67.51.253.1 0.0% 20 2 1.1 1 2 0.3 5.|-- 67.51.253.11 0.0% 20 1 1.4 1 2 0.5 6.|-- v202.core1.pdx1.he.net 0.0% 20 6 9.1 1 12 3.2 7.|-- 10ge12-4.core1.sea1.he.net 0.0% 20 5 6.5 5 11 1.7 8.|-- sea-b1-link.telia.net 0.0% 20 5 5.1 5 6 0.3 9.|-- att-ic-153030-sea-b1.c.telia.net 0.0% 20 9 7.7 6 9 1.2 10.|-- cr83.st0wa.ip.att.net 5.0% 20 118 119.7 117 123 1.5 11.|-- cr2.ptdor.ip.att.net 0.0% 20 119 120.1 118 122 1.4 12.|-- cr2.sffca.ip.att.net 0.0% 20 120 119.2 117 121 1.4 13.|-- cr2.sc1ca.ip.att.net 0.0% 20 119 121.1 118 149 6.6 14.|-- 12.122.151.129 0.0% 20 118 119.8 117 122 1.5 15.|-- ??? 100.0% 20 0 0.0 0 0 0.0 16.|-- 71.157.120.39 75.0% 20 119 118.6 118 119 0.5 17.|-- 108-248-29-59.lightspeed.renonv.sbcglobal.net 5.0% 20 139 137.1 135 146 2.5 18.|-- 108-241-228-42.lightspeed.renonv.sbcglobal.net 5.0% 20 143 139.2 135 152 4.9 Attention: Information contained in this message and or attachments is intended only for the recipient(s) named above and may contain confidential and or privileged material that is protected under State or Federal law. If you are not the intended recipient, any disclosure, copying, distribution or action taken on it is prohibited. If you believe you have received this email in error, please contact the sender, delete this email and destroy all copies. Attention: Information contained in this message and or attachments is intended only for the recipient(s) named above and may contain confidential and or privileged material that is protected under State or Federal law. If you are not the intended recipient, any disclosure, copying, distribution or action taken on it is prohibited. If you believe you have received this email in error, please contact the sender, delete this email and destroy all copies. From nick at foobar.org Wed May 20 14:50:16 2015 From: nick at foobar.org (Nick Hilliard) Date: Wed, 20 May 2015 15:50:16 +0100 Subject: Low Cost 10G Router In-Reply-To: References: <555C8EF0.5020205@foobar.org> <555C91E8.6050904@foobar.org> <555C92E7.1070600@foobar.org> Message-ID: <555C9F28.9080906@foobar.org> On 20/05/2015 15:25, Aled Morris wrote: > Couldn't your back-end scripts running under ExaBGP also manage the FIB, > using standard Unix tools/APIs? > > Managing the FIB is basically just "route add" and "route delete" right? Yes, you could probably do this. No, you probably wouldn't want to do this. Pls see the netlink interface modules in bird and quagga to understand why. Nick From pavel.odintsov at gmail.com Wed May 20 14:54:39 2015 From: pavel.odintsov at gmail.com (Pavel Odintsov) Date: Wed, 20 May 2015 17:54:39 +0300 Subject: Low Cost 10G Router In-Reply-To: References: <555C8EF0.5020205@foobar.org> <555C91E8.6050904@foobar.org> <555C92E7.1070600@foobar.org> Message-ID: Hello! Yes, we could run route add / route del when we got any announce from external world with ExaBGP directly. I have implemented custom custom Firewall (netmap-ipfw) management tool which implement in similar manner. But I'm working with BGP flow spec. It's so complex, standard BGP is much times simpler. And I could share my ExaBGP configuration and hook scripts. ExaBGP config: https://github.com/FastVPSEestiOu/fastnetmon/blob/master/src/scripts/exabgp_firewall.conf Hook script which put all announces to Redis Queue: https://github.com/FastVPSEestiOu/fastnetmon/blob/master/src/scripts/exabgp_queue_writer.py But full BGP route table is enough big and need external processing. But yes, with some Python code is possible to implement route server with ExaBGP. On Wed, May 20, 2015 at 5:25 PM, Aled Morris wrote: > On 20 May 2015 at 15:00, Pavel Odintsov wrote: >> >> Yes, you could do filtering with Quagga. But Quagga is pretty old tool >> without multiple dynamic features. But with ExaBGP you could do really >> any significant route table transformations with Python in few lines >> of code. But it's definitely add additional point of failure/bug. > > > Couldn't your back-end scripts running under ExaBGP also manage the FIB, > using standard Unix tools/APIs? > > Managing the FIB is basically just "route add" and "route delete" right? > > Aled > -- Sincerely yours, Pavel Odintsov From colton.conor at gmail.com Wed May 20 16:42:18 2015 From: colton.conor at gmail.com (Colton Conor) Date: Wed, 20 May 2015 11:42:18 -0500 Subject: Low Cost 10G Router In-Reply-To: References: <555C8EF0.5020205@foobar.org> <555C91E8.6050904@foobar.org> <555C92E7.1070600@foobar.org> Message-ID: So, from the sounds of it most are saying for low cost, the way to go would be a software router, which I was trying to avoid. To answer the bandwidth question, we would have three 10G ports with three different carriers and at max push 10Gbps of total traffic to start. I think this leaves me with hardware routers that can support full BGP tables. So, who actually sells full bgp routers. So far on my list I have: Juniper MX Series Brocade MLXe or CER Cisco ASR 9K Huawei NE40E-X1-M4 ZTE, not sure which model? ALU 7750 Besides the above, am I missing anyone else that makes a true carrier grade hardware router? On Wed, May 20, 2015 at 9:54 AM, Pavel Odintsov wrote: > Hello! > > Yes, we could run route add / route del when we got any announce from > external world with ExaBGP directly. I have implemented custom custom > Firewall (netmap-ipfw) management tool which implement in similar > manner. But I'm working with BGP flow spec. It's so complex, standard > BGP is much times simpler. > > And I could share my ExaBGP configuration and hook scripts. > > ExaBGP config: > https://github.com/FastVPSEestiOu/fastnetmon/blob/master/src/scripts/exabgp_firewall.conf > > Hook script which put all announces to Redis Queue: > > https://github.com/FastVPSEestiOu/fastnetmon/blob/master/src/scripts/exabgp_queue_writer.py > > But full BGP route table is enough big and need external processing. > > But yes, with some Python code is possible to implement route server > with ExaBGP. > > On Wed, May 20, 2015 at 5:25 PM, Aled Morris wrote: > > On 20 May 2015 at 15:00, Pavel Odintsov > wrote: > >> > >> Yes, you could do filtering with Quagga. But Quagga is pretty old tool > >> without multiple dynamic features. But with ExaBGP you could do really > >> any significant route table transformations with Python in few lines > >> of code. But it's definitely add additional point of failure/bug. > > > > > > Couldn't your back-end scripts running under ExaBGP also manage the FIB, > > using standard Unix tools/APIs? > > > > Managing the FIB is basically just "route add" and "route delete" right? > > > > Aled > > > > > > -- > Sincerely yours, Pavel Odintsov > From colton.conor at gmail.com Wed May 20 16:44:59 2015 From: colton.conor at gmail.com (Colton Conor) Date: Wed, 20 May 2015 11:44:59 -0500 Subject: Low Cost 10G Router In-Reply-To: References: <201505192046.t4JKkG90057624@aurora.sol.net> <555B8C22.8030203@ethoplex.com> <7ACEC6BE-527E-4EFE-AE62-06701C9C9496@mtin.net> <1137657451.322777.1432076600090.JavaMail.zimbra@snappytelecom.net> Message-ID: So are the rest of the processes in Mikrotik OS multi threaded? I would hope so to take advantage of 36 cores! What is up with all of these network vendors not supporting more than one core in their OS? I just don't get it. On Tue, May 19, 2015 at 9:49 PM, Josh Baird wrote: > The BGP daemon on the CCR routers is not multi-threaded; it only will use > one core. > > Josh > > On Tue, May 19, 2015 at 10:06 PM, Colton Conor > wrote: > >> So this new $1295 Mikrotik CCR1036-8G-2S+EM has a 36 core Tilera CPU >> with >> 16GB of ram. Each core is running at 1.2Ghz? I assume that Mikrotik is >> multicore in software, so why does this box not outperform these intel >> boxes that everyone is recommending? Is it just a limitation of ports? >> >> >> >> On Tue, May 19, 2015 at 6:03 PM, Faisal Imtiaz >> wrote: >> >> > >> > >> > >> > > I've seen serious, unusual performance bottlenecks in Mikrotik CCR, in >> > some >> > > cases not even achieving a gigabit speeds on 10G interfaces. >> Performance >> > > drops more rapidly then Cisco with smaller packet sizes. >> > > >> > > -mel beckman >> > >> > >> > Folks often forget that Mikrotik ROS can also run on x86 machines..... >> > >> > Size your favorite hardware (server) or network appliance with >> appropriate >> > ports, add MT ROS on a CF card, and you are good to go. >> > >> > We use i7 based network appliance with dual 10g cards (you can use a >> quad >> > 10g card, such as those made by hotlav). >> > >> > with a 2gig of ram, you can easily do multiple (4-5 or more full bgp >> > peers), and i7 are good for approx 1.2mill pps. >> > >> > >> > Best of luck. >> > >> > >> > Faisal Imtiaz >> > Snappy Internet & Telecom >> > >> > > From thomas.mangin at exa-networks.co.uk Wed May 20 16:47:12 2015 From: thomas.mangin at exa-networks.co.uk (Thomas Mangin) Date: Wed, 20 May 2015 17:47:12 +0100 Subject: Low Cost 10G Router In-Reply-To: References: <555C8EF0.5020205@foobar.org> <555C91E8.6050904@foobar.org> <555C92E7.1070600@foobar.org> Message-ID: <07A718B0-B0D4-4655-B0A9-265910CCA6A1@exa-networks.co.uk> Hello Pavel, Using ExaBGP as an SDN already has been done (and in a very large scale). But I would agree with Nick; It is not something I would recommend to everyone. Once more to echo Nick, to add/remove route/fw entries on Linux please do use netlink. The lastest ExaBGP master has some start of code to implement NetLink in python but I recently found a python module for it: https://github.com/svinota/pyroute2 Before ExaBGP can become a route server, I must complete a number of pieces (like the CLI which I am currently coding). I have spoken with the IX community about making ExaBGP a RR/RS and the idea was not badly received, but no one offered to help so it is on the back burner. Thomas On 20 May 2015, at 15:54, Pavel Odintsov wrote: > Hello! > > Yes, we could run route add / route del when we got any announce from > external world with ExaBGP directly. I have implemented custom custom > Firewall (netmap-ipfw) management tool which implement in similar > manner. But I'm working with BGP flow spec. It's so complex, standard > BGP is much times simpler. > > And I could share my ExaBGP configuration and hook scripts. > > ExaBGP config: > https://github.com/FastVPSEestiOu/fastnetmon/blob/master/src/scripts/exabgp_firewall.conf > > Hook script which put all announces to Redis Queue: > https://github.com/FastVPSEestiOu/fastnetmon/blob/master/src/scripts/exabgp_queue_writer.py > > But full BGP route table is enough big and need external processing. > > But yes, with some Python code is possible to implement route server > with ExaBGP. > > On Wed, May 20, 2015 at 5:25 PM, Aled Morris wrote: >> On 20 May 2015 at 15:00, Pavel Odintsov >> wrote: >>> >>> Yes, you could do filtering with Quagga. But Quagga is pretty old >>> tool >>> without multiple dynamic features. But with ExaBGP you could do >>> really >>> any significant route table transformations with Python in few lines >>> of code. But it's definitely add additional point of failure/bug. >> >> >> Couldn't your back-end scripts running under ExaBGP also manage the >> FIB, >> using standard Unix tools/APIs? >> >> Managing the FIB is basically just "route add" and "route delete" >> right? >> >> Aled >> > > > > -- > Sincerely yours, Pavel Odintsov From ikiris at gmail.com Wed May 20 16:47:30 2015 From: ikiris at gmail.com (Blake Dunlap) Date: Wed, 20 May 2015 09:47:30 -0700 Subject: Low Cost 10G Router In-Reply-To: References: <555C8EF0.5020205@foobar.org> <555C91E8.6050904@foobar.org> <555C92E7.1070600@foobar.org> Message-ID: good, cheap, built by someone else.... pick 2 On Wed, May 20, 2015 at 9:42 AM, Colton Conor wrote: > So, from the sounds of it most are saying for low cost, the way to go would > be a software router, which I was trying to avoid. To answer the bandwidth > question, we would have three 10G ports with three different carriers and > at max push 10Gbps of total traffic to start. > > I think this leaves me with hardware routers that can support full BGP > tables. So, who actually sells full bgp routers. So far on my list I have: > Juniper MX Series > Brocade MLXe or CER > Cisco ASR 9K > Huawei NE40E-X1-M4 > ZTE, not sure which model? > ALU 7750 > > Besides the above, am I missing anyone else that makes a true carrier grade > hardware router? > > On Wed, May 20, 2015 at 9:54 AM, Pavel Odintsov > wrote: > >> Hello! >> >> Yes, we could run route add / route del when we got any announce from >> external world with ExaBGP directly. I have implemented custom custom >> Firewall (netmap-ipfw) management tool which implement in similar >> manner. But I'm working with BGP flow spec. It's so complex, standard >> BGP is much times simpler. >> >> And I could share my ExaBGP configuration and hook scripts. >> >> ExaBGP config: >> https://github.com/FastVPSEestiOu/fastnetmon/blob/master/src/scripts/exabgp_firewall.conf >> >> Hook script which put all announces to Redis Queue: >> >> https://github.com/FastVPSEestiOu/fastnetmon/blob/master/src/scripts/exabgp_queue_writer.py >> >> But full BGP route table is enough big and need external processing. >> >> But yes, with some Python code is possible to implement route server >> with ExaBGP. >> >> On Wed, May 20, 2015 at 5:25 PM, Aled Morris wrote: >> > On 20 May 2015 at 15:00, Pavel Odintsov >> wrote: >> >> >> >> Yes, you could do filtering with Quagga. But Quagga is pretty old tool >> >> without multiple dynamic features. But with ExaBGP you could do really >> >> any significant route table transformations with Python in few lines >> >> of code. But it's definitely add additional point of failure/bug. >> > >> > >> > Couldn't your back-end scripts running under ExaBGP also manage the FIB, >> > using standard Unix tools/APIs? >> > >> > Managing the FIB is basically just "route add" and "route delete" right? >> > >> > Aled >> > >> >> >> >> -- >> Sincerely yours, Pavel Odintsov >> From rafael at gav.ufsc.br Wed May 20 16:53:27 2015 From: rafael at gav.ufsc.br (Rafael Possamai) Date: Wed, 20 May 2015 11:53:27 -0500 Subject: Low Cost 10G Router In-Reply-To: References: <201505192046.t4JKkG90057624@aurora.sol.net> <555B8C22.8030203@ethoplex.com> <7ACEC6BE-527E-4EFE-AE62-06701C9C9496@mtin.net> <1137657451.322777.1432076600090.JavaMail.zimbra@snappytelecom.net> Message-ID: Since you are considering multiple options, I'd build a decision matrix. You can put down all the requirements, score each option, and then normalize it to give each a final score. After that you can calculate some other things such as throughput per dollar, etc. http://asq.org/learn-about-quality/decision-making-tools/overview/decision-matrix.html Regarding the Mikrotik, there's a difference between Multithreading and Multiprocessing. On Wed, May 20, 2015 at 11:44 AM, Colton Conor wrote: > So are the rest of the processes in Mikrotik OS multi threaded? I would > hope so to take advantage of 36 cores! > > What is up with all of these network vendors not supporting more than one > core in their OS? I just don't get it. > > > > On Tue, May 19, 2015 at 9:49 PM, Josh Baird wrote: > > > The BGP daemon on the CCR routers is not multi-threaded; it only will use > > one core. > > > > Josh > > > > On Tue, May 19, 2015 at 10:06 PM, Colton Conor > > wrote: > > > >> So this new $1295 Mikrotik CCR1036-8G-2S+EM has a 36 core Tilera CPU > >> with > >> 16GB of ram. Each core is running at 1.2Ghz? I assume that Mikrotik is > >> multicore in software, so why does this box not outperform these intel > >> boxes that everyone is recommending? Is it just a limitation of ports? > >> > >> > >> > >> On Tue, May 19, 2015 at 6:03 PM, Faisal Imtiaz < > faisal at snappytelecom.net> > >> wrote: > >> > >> > > >> > > >> > > >> > > I've seen serious, unusual performance bottlenecks in Mikrotik CCR, > in > >> > some > >> > > cases not even achieving a gigabit speeds on 10G interfaces. > >> Performance > >> > > drops more rapidly then Cisco with smaller packet sizes. > >> > > > >> > > -mel beckman > >> > > >> > > >> > Folks often forget that Mikrotik ROS can also run on x86 machines..... > >> > > >> > Size your favorite hardware (server) or network appliance with > >> appropriate > >> > ports, add MT ROS on a CF card, and you are good to go. > >> > > >> > We use i7 based network appliance with dual 10g cards (you can use a > >> quad > >> > 10g card, such as those made by hotlav). > >> > > >> > with a 2gig of ram, you can easily do multiple (4-5 or more full bgp > >> > peers), and i7 are good for approx 1.2mill pps. > >> > > >> > > >> > Best of luck. > >> > > >> > > >> > Faisal Imtiaz > >> > Snappy Internet & Telecom > >> > > >> > > > > > From aledm at qix.co.uk Wed May 20 16:59:04 2015 From: aledm at qix.co.uk (Aled Morris) Date: Wed, 20 May 2015 17:59:04 +0100 Subject: Low Cost 10G Router In-Reply-To: References: <201505192046.t4JKkG90057624@aurora.sol.net> <555B8C22.8030203@ethoplex.com> <7ACEC6BE-527E-4EFE-AE62-06701C9C9496@mtin.net> <1137657451.322777.1432076600090.JavaMail.zimbra@snappytelecom.net> Message-ID: On 20 May 2015 at 17:44, Colton Conor wrote: > So are the rest of the processes in Mikrotik OS multi threaded? I would > hope so to take advantage of 36 cores! > The forthcoming new major software release from Mikrotik apparently will have multi-threaded BGP - it is targetted at their (also forthcoming) 72 core 8x10GE router, the CCR1072 I would treat this as speculation until you can order it though - it's been "promised" for 18 months now. Aled From blake at ispn.net Wed May 20 16:59:19 2015 From: blake at ispn.net (Blake Hudson) Date: Wed, 20 May 2015 11:59:19 -0500 Subject: Low Cost 10G Router In-Reply-To: References: <555C8EF0.5020205@foobar.org> <555C91E8.6050904@foobar.org> <555C92E7.1070600@foobar.org> Message-ID: <555CBD67.90905@ispn.net> As mentioned by others on the list, a properly configured ASR1004 and up can do this. --Blake Colton Conor wrote on 5/20/2015 11:42 AM: > So, from the sounds of it most are saying for low cost, the way to go would > be a software router, which I was trying to avoid. To answer the bandwidth > question, we would have three 10G ports with three different carriers and > at max push 10Gbps of total traffic to start. > > I think this leaves me with hardware routers that can support full BGP > tables. So, who actually sells full bgp routers. So far on my list I have: > Juniper MX Series > Brocade MLXe or CER > Cisco ASR 9K > Huawei NE40E-X1-M4 > ZTE, not sure which model? > ALU 7750 > > Besides the above, am I missing anyone else that makes a true carrier grade > hardware router? > > On Wed, May 20, 2015 at 9:54 AM, Pavel Odintsov > wrote: > >> Hello! >> >> Yes, we could run route add / route del when we got any announce from >> external world with ExaBGP directly. I have implemented custom custom >> Firewall (netmap-ipfw) management tool which implement in similar >> manner. But I'm working with BGP flow spec. It's so complex, standard >> BGP is much times simpler. >> >> And I could share my ExaBGP configuration and hook scripts. >> >> ExaBGP config: >> https://github.com/FastVPSEestiOu/fastnetmon/blob/master/src/scripts/exabgp_firewall.conf >> >> Hook script which put all announces to Redis Queue: >> >> https://github.com/FastVPSEestiOu/fastnetmon/blob/master/src/scripts/exabgp_queue_writer.py >> >> But full BGP route table is enough big and need external processing. >> >> But yes, with some Python code is possible to implement route server >> with ExaBGP. >> >> On Wed, May 20, 2015 at 5:25 PM, Aled Morris wrote: >>> On 20 May 2015 at 15:00, Pavel Odintsov >> wrote: >>>> Yes, you could do filtering with Quagga. But Quagga is pretty old tool >>>> without multiple dynamic features. But with ExaBGP you could do really >>>> any significant route table transformations with Python in few lines >>>> of code. But it's definitely add additional point of failure/bug. >>> >>> Couldn't your back-end scripts running under ExaBGP also manage the FIB, >>> using standard Unix tools/APIs? >>> >>> Managing the FIB is basically just "route add" and "route delete" right? >>> >>> Aled >>> >> >> >> -- >> Sincerely yours, Pavel Odintsov >> From nanog at ics-il.net Wed May 20 17:07:55 2015 From: nanog at ics-il.net (Mike Hammett) Date: Wed, 20 May 2015 12:07:55 -0500 (CDT) Subject: Low Cost 10G Router In-Reply-To: Message-ID: <32226940.868.1432141668998.JavaMail.mhammett@ThunderFuck> Well, the cores on a many-core CPU aren't going to have the "torque" that a Xeon would. They're also still working on the software. It has gotten a ton better over the life of the CCRs thus far. BGP is still atrocious on the CCRs, but that's because the route update process isn't multithreaded. It won't be multithreaded in the next major version either, but they will have done some programming voodoo (all programming is voodoo to me) to reign in the poor performance issues with full tables. https://youtu.be/ihZiAC-Rox8?t=37m8s ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest Internet Exchange http://www.midwest-ix.com ----- Original Message ----- From: "Colton Conor" To: "Faisal Imtiaz" Cc: "North American Network Operators Group" Sent: Tuesday, May 19, 2015 9:06:26 PM Subject: Re: Low Cost 10G Router So this new $1295 Mikrotik CCR1036-8G-2S+EM has a 36 core Tilera CPU with 16GB of ram. Each core is running at 1.2Ghz? I assume that Mikrotik is multicore in software, so why does this box not outperform these intel boxes that everyone is recommending? Is it just a limitation of ports? On Tue, May 19, 2015 at 6:03 PM, Faisal Imtiaz wrote: > > > > > I've seen serious, unusual performance bottlenecks in Mikrotik CCR, in > some > > cases not even achieving a gigabit speeds on 10G interfaces. Performance > > drops more rapidly then Cisco with smaller packet sizes. > > > > -mel beckman > > > Folks often forget that Mikrotik ROS can also run on x86 machines..... > > Size your favorite hardware (server) or network appliance with appropriate > ports, add MT ROS on a CF card, and you are good to go. > > We use i7 based network appliance with dual 10g cards (you can use a quad > 10g card, such as those made by hotlav). > > with a 2gig of ram, you can easily do multiple (4-5 or more full bgp > peers), and i7 are good for approx 1.2mill pps. > > > Best of luck. > > > Faisal Imtiaz > Snappy Internet & Telecom > From nanog at ics-il.net Wed May 20 17:09:20 2015 From: nanog at ics-il.net (Mike Hammett) Date: Wed, 20 May 2015 12:09:20 -0500 (CDT) Subject: Low Cost 10G Router In-Reply-To: Message-ID: <22142318.873.1432141754813.JavaMail.mhammett@ThunderFuck> There will *not* be multi-threaded BGP in RouterOS. I was going to refer you to the post I made last night, but due to the unique way the e-mail list is setup, I replied directly to Colton instead of the list. I resent it again to the list. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest Internet Exchange http://www.midwest-ix.com ----- Original Message ----- From: "Aled Morris" To: "Colton Conor" Cc: "North American Network Operators Group" Sent: Wednesday, May 20, 2015 11:59:04 AM Subject: Re: Low Cost 10G Router On 20 May 2015 at 17:44, Colton Conor wrote: > So are the rest of the processes in Mikrotik OS multi threaded? I would > hope so to take advantage of 36 cores! > The forthcoming new major software release from Mikrotik apparently will have multi-threaded BGP - it is targetted at their (also forthcoming) 72 core 8x10GE router, the CCR1072 I would treat this as speculation until you can order it though - it's been "promised" for 18 months now. Aled From codygrosskopf at gmail.com Wed May 20 17:17:52 2015 From: codygrosskopf at gmail.com (Cody Grosskopf) Date: Wed, 20 May 2015 10:17:52 -0700 Subject: Low Cost 10G Router In-Reply-To: References: <555C8EF0.5020205@foobar.org> <555C91E8.6050904@foobar.org> <555C92E7.1070600@foobar.org> Message-ID: Add Alcatel-Lucent 7750? I have no experience but this list seems to love them. On Wed, May 20, 2015, 9:44 AM Colton Conor wrote: > So, from the sounds of it most are saying for low cost, the way to go would > be a software router, which I was trying to avoid. To answer the bandwidth > question, we would have three 10G ports with three different carriers and > at max push 10Gbps of total traffic to start. > > I think this leaves me with hardware routers that can support full BGP > tables. So, who actually sells full bgp routers. So far on my list I have: > Juniper MX Series > Brocade MLXe or CER > Cisco ASR 9K > Huawei NE40E-X1-M4 > ZTE, not sure which model? > ALU 7750 > > Besides the above, am I missing anyone else that makes a true carrier grade > hardware router? > > On Wed, May 20, 2015 at 9:54 AM, Pavel Odintsov > wrote: > > > Hello! > > > > Yes, we could run route add / route del when we got any announce from > > external world with ExaBGP directly. I have implemented custom custom > > Firewall (netmap-ipfw) management tool which implement in similar > > manner. But I'm working with BGP flow spec. It's so complex, standard > > BGP is much times simpler. > > > > And I could share my ExaBGP configuration and hook scripts. > > > > ExaBGP config: > > > https://github.com/FastVPSEestiOu/fastnetmon/blob/master/src/scripts/exabgp_firewall.conf > > > > Hook script which put all announces to Redis Queue: > > > > > https://github.com/FastVPSEestiOu/fastnetmon/blob/master/src/scripts/exabgp_queue_writer.py > > > > But full BGP route table is enough big and need external processing. > > > > But yes, with some Python code is possible to implement route server > > with ExaBGP. > > > > On Wed, May 20, 2015 at 5:25 PM, Aled Morris wrote: > > > On 20 May 2015 at 15:00, Pavel Odintsov > > wrote: > > >> > > >> Yes, you could do filtering with Quagga. But Quagga is pretty old tool > > >> without multiple dynamic features. But with ExaBGP you could do really > > >> any significant route table transformations with Python in few lines > > >> of code. But it's definitely add additional point of failure/bug. > > > > > > > > > Couldn't your back-end scripts running under ExaBGP also manage the > FIB, > > > using standard Unix tools/APIs? > > > > > > Managing the FIB is basically just "route add" and "route delete" > right? > > > > > > Aled > > > > > > > > > > > -- > > Sincerely yours, Pavel Odintsov > > > From baldur.norddahl at gmail.com Wed May 20 17:28:39 2015 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Wed, 20 May 2015 19:28:39 +0200 Subject: Low Cost 10G Router In-Reply-To: References: <555C8EF0.5020205@foobar.org> <555C91E8.6050904@foobar.org> <555C92E7.1070600@foobar.org> Message-ID: ZTE M6000-3S. It is what we use. Works well for us. Just remember to get a memory upgrade to 8 GB memory or you will run out of RIB space. Regards Baldur Den 20/05/2015 18.43 skrev "Colton Conor" : > So, from the sounds of it most are saying for low cost, the way to go would > be a software router, which I was trying to avoid. To answer the bandwidth > question, we would have three 10G ports with three different carriers and > at max push 10Gbps of total traffic to start. > > I think this leaves me with hardware routers that can support full BGP > tables. So, who actually sells full bgp routers. So far on my list I have: > Juniper MX Series > Brocade MLXe or CER > Cisco ASR 9K > Huawei NE40E-X1-M4 > ZTE, not sure which model? > ALU 7750 > > Besides the above, am I missing anyone else that makes a true carrier grade > hardware router? > > On Wed, May 20, 2015 at 9:54 AM, Pavel Odintsov > wrote: > > > Hello! > > > > Yes, we could run route add / route del when we got any announce from > > external world with ExaBGP directly. I have implemented custom custom > > Firewall (netmap-ipfw) management tool which implement in similar > > manner. But I'm working with BGP flow spec. It's so complex, standard > > BGP is much times simpler. > > > > And I could share my ExaBGP configuration and hook scripts. > > > > ExaBGP config: > > > https://github.com/FastVPSEestiOu/fastnetmon/blob/master/src/scripts/exabgp_firewall.conf > > > > Hook script which put all announces to Redis Queue: > > > > > https://github.com/FastVPSEestiOu/fastnetmon/blob/master/src/scripts/exabgp_queue_writer.py > > > > But full BGP route table is enough big and need external processing. > > > > But yes, with some Python code is possible to implement route server > > with ExaBGP. > > > > On Wed, May 20, 2015 at 5:25 PM, Aled Morris wrote: > > > On 20 May 2015 at 15:00, Pavel Odintsov > > wrote: > > >> > > >> Yes, you could do filtering with Quagga. But Quagga is pretty old tool > > >> without multiple dynamic features. But with ExaBGP you could do really > > >> any significant route table transformations with Python in few lines > > >> of code. But it's definitely add additional point of failure/bug. > > > > > > > > > Couldn't your back-end scripts running under ExaBGP also manage the > FIB, > > > using standard Unix tools/APIs? > > > > > > Managing the FIB is basically just "route add" and "route delete" > right? > > > > > > Aled > > > > > > > > > > > -- > > Sincerely yours, Pavel Odintsov > > > From colton.conor at gmail.com Wed May 20 17:41:43 2015 From: colton.conor at gmail.com (Colton Conor) Date: Wed, 20 May 2015 12:41:43 -0500 Subject: Low Cost 10G Router In-Reply-To: References: <555C8EF0.5020205@foobar.org> <555C91E8.6050904@foobar.org> <555C92E7.1070600@foobar.org> Message-ID: Yep, thats what I meant be ALU 7750 :) On Wed, May 20, 2015 at 12:17 PM, Cody Grosskopf wrote: > Add Alcatel-Lucent 7750? I have no experience but this list seems to love > them. > > On Wed, May 20, 2015, 9:44 AM Colton Conor wrote: > >> So, from the sounds of it most are saying for low cost, the way to go >> would >> be a software router, which I was trying to avoid. To answer the bandwidth >> question, we would have three 10G ports with three different carriers and >> at max push 10Gbps of total traffic to start. >> >> I think this leaves me with hardware routers that can support full BGP >> tables. So, who actually sells full bgp routers. So far on my list I have: >> Juniper MX Series >> Brocade MLXe or CER >> Cisco ASR 9K >> Huawei NE40E-X1-M4 >> ZTE, not sure which model? >> ALU 7750 >> >> Besides the above, am I missing anyone else that makes a true carrier >> grade >> hardware router? >> >> On Wed, May 20, 2015 at 9:54 AM, Pavel Odintsov > > >> wrote: >> >> > Hello! >> > >> > Yes, we could run route add / route del when we got any announce from >> > external world with ExaBGP directly. I have implemented custom custom >> > Firewall (netmap-ipfw) management tool which implement in similar >> > manner. But I'm working with BGP flow spec. It's so complex, standard >> > BGP is much times simpler. >> > >> > And I could share my ExaBGP configuration and hook scripts. >> > >> > ExaBGP config: >> > >> https://github.com/FastVPSEestiOu/fastnetmon/blob/master/src/scripts/exabgp_firewall.conf >> > >> > Hook script which put all announces to Redis Queue: >> > >> > >> https://github.com/FastVPSEestiOu/fastnetmon/blob/master/src/scripts/exabgp_queue_writer.py >> > >> > But full BGP route table is enough big and need external processing. >> > >> > But yes, with some Python code is possible to implement route server >> > with ExaBGP. >> > >> > On Wed, May 20, 2015 at 5:25 PM, Aled Morris wrote: >> > > On 20 May 2015 at 15:00, Pavel Odintsov >> > wrote: >> > >> >> > >> Yes, you could do filtering with Quagga. But Quagga is pretty old >> tool >> > >> without multiple dynamic features. But with ExaBGP you could do >> really >> > >> any significant route table transformations with Python in few lines >> > >> of code. But it's definitely add additional point of failure/bug. >> > > >> > > >> > > Couldn't your back-end scripts running under ExaBGP also manage the >> FIB, >> > > using standard Unix tools/APIs? >> > > >> > > Managing the FIB is basically just "route add" and "route delete" >> right? >> > > >> > > Aled >> > > >> > >> > >> > >> > -- >> > Sincerely yours, Pavel Odintsov >> > >> > From ahebert at pubnix.net Wed May 20 17:44:01 2015 From: ahebert at pubnix.net (Alain Hebert) Date: Wed, 20 May 2015 13:44:01 -0400 Subject: Low Cost 10G Router In-Reply-To: References: <555C8EF0.5020205@foobar.org> <555C91E8.6050904@foobar.org> <555C92E7.1070600@foobar.org> Message-ID: <555CC7E1.9040603@pubnix.net> Well, in my experience, which is limited to small iron mostly. Juniper MX104 Do not forget to get a second RE (Routine Engine) for software upgrade, and be prepare to accept to pay a "license" to use the 10Gbps ports on top of buying the IO cards. (1 license per 2 ports). Don't forget to set aside some times to port your configuration into it, if you are used to Cisco/Brocade style config. And that I'm too stupid to figure out a way to make 'test policy' do the same thing as "show ip bgp route-map XYZ" CER2K (latest revision) Has plenty of RAM for 6 full routing table (and maybe more) and 1.5M RIB compared to the ~524k from the first gen. ( Got burned on those ) MLX Juniper MX104 where cheaper for about the same platform using MLX products. Cisco I don't know about the licensing for the ASR but I mostly deal with second hand devices. They are not flashy but do the job. Huawei, ZTE I didn't touch those and mostly won't beside looking into some security concern some people are having. PS: With almost 130k prefixes polluting the routing table you could use a software route server and feed an auto-summary of the full route into a router/switch that can handle the RIB/FIB. I have yet to test Bird but I heard good things about using it for that function. ( By pollution, I mean, it was a test made on 6 peers where I found ~130k prefixes where using the same path as their larger subnet, I have to put up more time on that bench thou ) ----- Alain Hebert ahebert at pubnix.net PubNIX Inc. 50 boul. St-Charles P.O. Box 26770 Beaconsfield, Quebec H9W 6G7 Tel: 514-990-5911 http://www.pubnix.net Fax: 514-990-9443 On 05/20/15 12:42, Colton Conor wrote: > So, from the sounds of it most are saying for low cost, the way to go would > be a software router, which I was trying to avoid. To answer the bandwidth > question, we would have three 10G ports with three different carriers and > at max push 10Gbps of total traffic to start. > > I think this leaves me with hardware routers that can support full BGP > tables. So, who actually sells full bgp routers. So far on my list I have: > Juniper MX Series > Brocade MLXe or CER > Cisco ASR 9K > Huawei NE40E-X1-M4 > ZTE, not sure which model? > ALU 7750 > > Besides the above, am I missing anyone else that makes a true carrier grade > hardware router? > > On Wed, May 20, 2015 at 9:54 AM, Pavel Odintsov > wrote: > >> Hello! >> >> Yes, we could run route add / route del when we got any announce from >> external world with ExaBGP directly. I have implemented custom custom >> Firewall (netmap-ipfw) management tool which implement in similar >> manner. But I'm working with BGP flow spec. It's so complex, standard >> BGP is much times simpler. >> >> And I could share my ExaBGP configuration and hook scripts. >> >> ExaBGP config: >> https://github.com/FastVPSEestiOu/fastnetmon/blob/master/src/scripts/exabgp_firewall.conf >> >> Hook script which put all announces to Redis Queue: >> >> https://github.com/FastVPSEestiOu/fastnetmon/blob/master/src/scripts/exabgp_queue_writer.py >> >> But full BGP route table is enough big and need external processing. >> >> But yes, with some Python code is possible to implement route server >> with ExaBGP. >> >> On Wed, May 20, 2015 at 5:25 PM, Aled Morris wrote: >>> On 20 May 2015 at 15:00, Pavel Odintsov >> wrote: >>>> Yes, you could do filtering with Quagga. But Quagga is pretty old tool >>>> without multiple dynamic features. But with ExaBGP you could do really >>>> any significant route table transformations with Python in few lines >>>> of code. But it's definitely add additional point of failure/bug. >>> >>> Couldn't your back-end scripts running under ExaBGP also manage the FIB, >>> using standard Unix tools/APIs? >>> >>> Managing the FIB is basically just "route add" and "route delete" right? >>> >>> Aled >>> >> >> >> -- >> Sincerely yours, Pavel Odintsov >> > From mel at beckman.org Wed May 20 18:00:12 2015 From: mel at beckman.org (Mel Beckman) Date: Wed, 20 May 2015 18:00:12 +0000 Subject: AT&T/Telia issue In-Reply-To: <25440C4BF31A8E44872003195DEB57BE9596A9@omail1.community-health.org> References: <25440C4BF31A8E44872003195DEB57BE954B52@omail1.community-health.org>, <25440C4BF31A8E44872003195DEB57BE9596A9@omail1.community-health.org> Message-ID: <9762B4C1-E2F6-42CE-9466-7AA4F9F0322D@beckman.org> There is a massive fiber cut in Santa Barbara affecting coastal paths for some carriers. That might be a factor. -mel beckman > On May 20, 2015, at 7:42 AM, Tyler Applebaum wrote: > > Still seeing this as of 7:40AM PST. Looks isolated to AT&T and Telia in Seattle. > > HOST: PC-002 Loss% Snt Last Avg Best Wrst StDev > 1.|-- 172.31.255.1 0.0% 10 0 0.8 0 3 0.9 > 2.|-- 10.98.0.4 0.0% 10 1 1.5 1 4 1.1 > 3.|-- 67.51.253.17 0.0% 10 6 2.8 2 6 1.2 > 4.|-- 67.51.253.1 0.0% 10 2 1.4 1 2 0.5 > 5.|-- 67.51.253.3 0.0% 10 2 1.3 1 2 0.5 > 6.|-- v202.core1.pdx1.he.net 0.0% 10 1 2.0 1 4 1.2 > 7.|-- 10ge12-4.core1.sea1.he.net 0.0% 10 9 10.9 9 13 1.0 > 8.|-- sea-b1-link.telia.net 50.0% 10 42 42.0 42 42 0.0 > 9.|-- att-ic-153030-sea-b1.c.telia.net 50.0% 10 46 44.8 43 46 1.3 > 10.|-- cr84.st0wa.ip.att.net 40.0% 10 71 73.8 71 76 1.8 > 11.|-- cr2.st6wa.ip.att.net 40.0% 10 74 73.7 72 75 1.2 > 12.|-- 12.122.158.146 70.0% 10 74 73.7 73 74 0.6 > 13.|-- 12.122.158.157 50.0% 10 71 71.0 71 71 0.0 > 14.|-- 12.248.207.6 20.0% 10 71 71.0 71 71 0.0 > 15.|-- ancr-5-1-12-12.attalascom.net 30.0% 10 71 71.0 71 71 0.0 > 16.|-- 66-2-12-12.attalascom.net 30.0% 10 85 85.3 85 86 0.5 > 17.|-- KCHC-42-7-12-12.attalascom.net 30.0% 10 95 95.6 95 96 0.5 > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Tyler Applebaum > Sent: Tuesday, May 19, 2015 4:20 PM > To: nanog at nanog.org > Subject: AT&T/Telia issue > > Seeing this on AS7018 to AS1299. Anyone out there at either provider know anything about this? > > HOST: PC-002 Loss% Snt Last Avg Best Wrst StDev > 1.|-- 172.31.255.1 0.0% 10 1 0.7 0 3 0.9 > 2.|-- 10.98.0.3 0.0% 10 1 1.0 1 1 0.0 > 3.|-- 67.51.253.17 0.0% 10 2 2.5 2 4 0.7 > 4.|-- 67.51.253.3 0.0% 10 1 1.2 1 2 0.4 > 5.|-- v202.core1.pdx1.he.net 0.0% 10 7 10.5 7 12 1.9 > 6.|-- 10ge12-4.core1.sea1.he.net 0.0% 10 5 5.0 5 5 0.0 > 7.|-- sea-b1-link.telia.net 0.0% 10 5 5.8 5 12 2.2 > 8.|-- den-b1-link.telia.net 0.0% 10 108 107.3 106 108 0.7 > 9.|-- sjo-b21-link.telia.net 20.0% 10 137 134.9 134 137 1.0 > 10.|-- 192.205.33.45 40.0% 10 136 136.2 135 138 1.2 > 11.|-- cr1.sffca.ip.att.net 10.0% 10 141 141.9 139 145 1.9 > 12.|-- 12.122.2.77 20.0% 10 140 140.1 137 142 2.0 > 13.|-- 12.122.160.149 10.0% 10 138 141.1 137 164 8.6 > 14.|-- 12.117.131.214 30.0% 10 139 141.0 139 145 1.9 > 15.|-- 199.103.47.2 30.0% 10 51 128.0 51 142 34.0 > > HOST: PC-002 Loss% Snt Last Avg Best Wrst StDev > 1.|-- 172.31.255.1 0.0% 20 1 1.1 0 3 0.6 > 2.|-- 10.98.0.4 0.0% 20 1 1.3 1 4 0.7 > 3.|-- 67.51.253.17 0.0% 20 3 4.9 2 48 10.2 > 4.|-- 67.51.253.1 0.0% 20 2 1.1 1 2 0.3 > 5.|-- 67.51.253.11 0.0% 20 1 1.4 1 2 0.5 > 6.|-- v202.core1.pdx1.he.net 0.0% 20 6 9.1 1 12 3.2 > 7.|-- 10ge12-4.core1.sea1.he.net 0.0% 20 5 6.5 5 11 1.7 > 8.|-- sea-b1-link.telia.net 0.0% 20 5 5.1 5 6 0.3 > 9.|-- att-ic-153030-sea-b1.c.telia.net 0.0% 20 9 7.7 6 9 1.2 > 10.|-- cr83.st0wa.ip.att.net 5.0% 20 118 119.7 117 123 1.5 > 11.|-- cr2.ptdor.ip.att.net 0.0% 20 119 120.1 118 122 1.4 > 12.|-- cr2.sffca.ip.att.net 0.0% 20 120 119.2 117 121 1.4 > 13.|-- cr2.sc1ca.ip.att.net 0.0% 20 119 121.1 118 149 6.6 > 14.|-- 12.122.151.129 0.0% 20 118 119.8 117 122 1.5 > 15.|-- ??? 100.0% 20 0 0.0 0 0 0.0 > 16.|-- 71.157.120.39 75.0% 20 119 118.6 118 119 0.5 > 17.|-- 108-248-29-59.lightspeed.renonv.sbcglobal.net 5.0% 20 139 137.1 135 146 2.5 > 18.|-- 108-241-228-42.lightspeed.renonv.sbcglobal.net 5.0% 20 143 139.2 135 152 4.9 > Attention: Information contained in this message and or attachments is intended only for the recipient(s) named above and may contain confidential and or privileged material that is protected under State or Federal law. If you are not the intended recipient, any disclosure, copying, distribution or action taken on it is prohibited. If you believe you have received this email in error, please contact the sender, delete this email and destroy all copies. > Attention: Information contained in this message and or attachments is intended only for the recipient(s) named above and may contain confidential and or privileged material that is protected under State or Federal law. If you are not the intended recipient, any disclosure, copying, distribution or action taken on it is prohibited. If you believe you have received this email in error, please contact the sender, delete this email and destroy all copies. From matthias at leisi.net Wed May 20 20:37:29 2015 From: matthias at leisi.net (Matthias Leisi) Date: Wed, 20 May 2015 22:37:29 +0200 Subject: Spamhaus BGP feed experiences? In-Reply-To: <555B8313.5080400@netassist.ua> References: <20150518180414.GC13453@bongo.bofh.it> <555B8313.5080400@netassist.ua> Message-ID: <9F5701CC-CB6C-493B-8BF2-2E3955EAFA08@leisi.net> At dnswl.org we check our data against the DROP list every once in a while. The overlap of DROP with legitimate sources of SMTP traffic is very, very small: a low single-digit number, and most of them are crappy to start with (so we don?t publish them, but only keep them in our database for reference purposes). ? Matthias > Am 19.05.2015 um 20:38 schrieb Max Tulyev : > > How much false positives (i.e. blackholing traffic users want to reach)? > > On 18.05.15 21:04, Marco d'Itri wrote: >> On May 17, Mike Lyon wrote: >> >>> Any ISPs out there (big or small) ever used the Spamhaus BGP feed to >>> prevent against botnet, spam, etc? If so, how has your experience been? Is >>> it worthwhile? Has it helped? On / off list responses are appreciated in >>> advance. >> We use Spamhaus DROP (not the BGP version: our software asks a human to >> review each change). >> The benefits are not obvious since we do not have access customers, but >> it will blackhole some networks you obviously do not want to talk to, >> and it has not caused any troubles either. >> > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4109 bytes Desc: not available URL: From marty at cloudflare.com Wed May 20 20:43:32 2015 From: marty at cloudflare.com (Marty Strong) Date: Wed, 20 May 2015 21:43:32 +0100 Subject: AT&T/Telia issue In-Reply-To: <9762B4C1-E2F6-42CE-9466-7AA4F9F0322D@beckman.org> References: <25440C4BF31A8E44872003195DEB57BE954B52@omail1.community-health.org> <25440C4BF31A8E44872003195DEB57BE9596A9@omail1.community-health.org> <9762B4C1-E2F6-42CE-9466-7AA4F9F0322D@beckman.org> Message-ID: <78801E8B-7D84-42FE-BA98-8174E888D8C4@cloudflare.com> It was resolved at around 2015-05-20 17:18 UTC Regards, Marty Strong -------------------------------------- CloudFlare - AS13335 Network Engineer marty at cloudflare.com +44 20 3514 6970 UK (Office) +44 7584 906 055 UK (Mobile) +1 888 993 5273 US (Office) smartflare (Skype) http://www.peeringdb.com/view.php?asn=13335 > On 20 May 2015, at 19:00, Mel Beckman wrote: > > There is a massive fiber cut in Santa Barbara affecting coastal paths for some carriers. That might be a factor. > > -mel beckman > >> On May 20, 2015, at 7:42 AM, Tyler Applebaum wrote: >> >> Still seeing this as of 7:40AM PST. Looks isolated to AT&T and Telia in Seattle. >> >> HOST: PC-002 Loss% Snt Last Avg Best Wrst StDev >> 1.|-- 172.31.255.1 0.0% 10 0 0.8 0 3 0.9 >> 2.|-- 10.98.0.4 0.0% 10 1 1.5 1 4 1.1 >> 3.|-- 67.51.253.17 0.0% 10 6 2.8 2 6 1.2 >> 4.|-- 67.51.253.1 0.0% 10 2 1.4 1 2 0.5 >> 5.|-- 67.51.253.3 0.0% 10 2 1.3 1 2 0.5 >> 6.|-- v202.core1.pdx1.he.net 0.0% 10 1 2.0 1 4 1.2 >> 7.|-- 10ge12-4.core1.sea1.he.net 0.0% 10 9 10.9 9 13 1.0 >> 8.|-- sea-b1-link.telia.net 50.0% 10 42 42.0 42 42 0.0 >> 9.|-- att-ic-153030-sea-b1.c.telia.net 50.0% 10 46 44.8 43 46 1.3 >> 10.|-- cr84.st0wa.ip.att.net 40.0% 10 71 73.8 71 76 1.8 >> 11.|-- cr2.st6wa.ip.att.net 40.0% 10 74 73.7 72 75 1.2 >> 12.|-- 12.122.158.146 70.0% 10 74 73.7 73 74 0.6 >> 13.|-- 12.122.158.157 50.0% 10 71 71.0 71 71 0.0 >> 14.|-- 12.248.207.6 20.0% 10 71 71.0 71 71 0.0 >> 15.|-- ancr-5-1-12-12.attalascom.net 30.0% 10 71 71.0 71 71 0.0 >> 16.|-- 66-2-12-12.attalascom.net 30.0% 10 85 85.3 85 86 0.5 >> 17.|-- KCHC-42-7-12-12.attalascom.net 30.0% 10 95 95.6 95 96 0.5 >> >> -----Original Message----- >> From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Tyler Applebaum >> Sent: Tuesday, May 19, 2015 4:20 PM >> To: nanog at nanog.org >> Subject: AT&T/Telia issue >> >> Seeing this on AS7018 to AS1299. Anyone out there at either provider know anything about this? >> >> HOST: PC-002 Loss% Snt Last Avg Best Wrst StDev >> 1.|-- 172.31.255.1 0.0% 10 1 0.7 0 3 0.9 >> 2.|-- 10.98.0.3 0.0% 10 1 1.0 1 1 0.0 >> 3.|-- 67.51.253.17 0.0% 10 2 2.5 2 4 0.7 >> 4.|-- 67.51.253.3 0.0% 10 1 1.2 1 2 0.4 >> 5.|-- v202.core1.pdx1.he.net 0.0% 10 7 10.5 7 12 1.9 >> 6.|-- 10ge12-4.core1.sea1.he.net 0.0% 10 5 5.0 5 5 0.0 >> 7.|-- sea-b1-link.telia.net 0.0% 10 5 5.8 5 12 2.2 >> 8.|-- den-b1-link.telia.net 0.0% 10 108 107.3 106 108 0.7 >> 9.|-- sjo-b21-link.telia.net 20.0% 10 137 134.9 134 137 1.0 >> 10.|-- 192.205.33.45 40.0% 10 136 136.2 135 138 1.2 >> 11.|-- cr1.sffca.ip.att.net 10.0% 10 141 141.9 139 145 1.9 >> 12.|-- 12.122.2.77 20.0% 10 140 140.1 137 142 2.0 >> 13.|-- 12.122.160.149 10.0% 10 138 141.1 137 164 8.6 >> 14.|-- 12.117.131.214 30.0% 10 139 141.0 139 145 1.9 >> 15.|-- 199.103.47.2 30.0% 10 51 128.0 51 142 34.0 >> >> HOST: PC-002 Loss% Snt Last Avg Best Wrst StDev >> 1.|-- 172.31.255.1 0.0% 20 1 1.1 0 3 0.6 >> 2.|-- 10.98.0.4 0.0% 20 1 1.3 1 4 0.7 >> 3.|-- 67.51.253.17 0.0% 20 3 4.9 2 48 10.2 >> 4.|-- 67.51.253.1 0.0% 20 2 1.1 1 2 0.3 >> 5.|-- 67.51.253.11 0.0% 20 1 1.4 1 2 0.5 >> 6.|-- v202.core1.pdx1.he.net 0.0% 20 6 9.1 1 12 3.2 >> 7.|-- 10ge12-4.core1.sea1.he.net 0.0% 20 5 6.5 5 11 1.7 >> 8.|-- sea-b1-link.telia.net 0.0% 20 5 5.1 5 6 0.3 >> 9.|-- att-ic-153030-sea-b1.c.telia.net 0.0% 20 9 7.7 6 9 1.2 >> 10.|-- cr83.st0wa.ip.att.net 5.0% 20 118 119.7 117 123 1.5 >> 11.|-- cr2.ptdor.ip.att.net 0.0% 20 119 120.1 118 122 1.4 >> 12.|-- cr2.sffca.ip.att.net 0.0% 20 120 119.2 117 121 1.4 >> 13.|-- cr2.sc1ca.ip.att.net 0.0% 20 119 121.1 118 149 6.6 >> 14.|-- 12.122.151.129 0.0% 20 118 119.8 117 122 1.5 >> 15.|-- ??? 100.0% 20 0 0.0 0 0 0.0 >> 16.|-- 71.157.120.39 75.0% 20 119 118.6 118 119 0.5 >> 17.|-- 108-248-29-59.lightspeed.renonv.sbcglobal.net 5.0% 20 139 137.1 135 146 2.5 >> 18.|-- 108-241-228-42.lightspeed.renonv.sbcglobal.net 5.0% 20 143 139.2 135 152 4.9 >> Attention: Information contained in this message and or attachments is intended only for the recipient(s) named above and may contain confidential and or privileged material that is protected under State or Federal law. If you are not the intended recipient, any disclosure, copying, distribution or action taken on it is prohibited. If you believe you have received this email in error, please contact the sender, delete this email and destroy all copies. >> Attention: Information contained in this message and or attachments is intended only for the recipient(s) named above and may contain confidential and or privileged material that is protected under State or Federal law. If you are not the intended recipient, any disclosure, copying, distribution or action taken on it is prohibited. If you believe you have received this email in error, please contact the sender, delete this email and destroy all copies. From edtardist at gmail.com Wed May 20 22:34:11 2015 From: edtardist at gmail.com (Eddie Tardist) Date: Wed, 20 May 2015 19:34:11 -0300 Subject: Low Cost 10G Router In-Reply-To: <32226940.868.1432141668998.JavaMail.mhammett@ThunderFuck> References: <32226940.868.1432141668998.JavaMail.mhammett@ThunderFuck> Message-ID: On Wed, May 20, 2015 at 2:07 PM, Mike Hammett wrote: > Well, the cores on a many-core CPU aren't going to have the "torque" that > a Xeon would. They're also still working on the software. It has gotten a > ton better over the life of the CCRs thus far. BGP is still atrocious on > the CCRs, but that's because the route update process isn't multithreaded. > It won't be multithreaded in the next major version either, but they will > have done some programming voodoo (all programming is voodoo to me) to > reign in the poor performance issues with full tables. > > https://youtu.be/ihZiAC-Rox8?t=37m8s > I honestly don't know why most people gets impressed by the number of Tylera cores on CCR and think it's a good thing. Your "torque" point makes much sense to me. A few cores with decent clock and Xeon or Rangeley "torque" is just better. Adding that much weak tylera cores with low clock only results in much more context switching, much more CPU Affinity needs. Multithreading the relevant grained bit of code will also lead to more context switching, but for threads now instead of processes. As I understand the architecture of those solutions, I don't see why a bgp daemon mono threaded is a problem. Ok, multithreaded would give a better full routing convergence. But once the routing table is loaded it does not matter how many threads the bgp process will use. The dirty work on Linux (RouterOS kernel for that matter) will be done on the forward information table, on the packet forwarding code and specially on softirq (interrupt requests). This is where the bottleneck seems to be, IMHO. Linux is not good at multithreaded packet forwarding and not good specially at handling interrupt requests on multi-queue NICs. So, RouterOS is not good as well. Therefore that "several dozens" cheap and weak tylera cores powering CCR boxes is absolutely not friendly for Linux core and RouterOS itself. I'm better served off with a smaller amount of cores with better clock and better "torque" as Mr Hammett mentioned (I liked the expression usage yes) and that's why a Linux or a BSD box with a couple Xeon CPUs will perform better than CCR. Sometimes as someone mentioned a couple i7 cores will outperform a CCR box as well. More torque, yeah. Less context switching and time sharing wasted. However this horizontal scalar number of tylera cores on the CCR is good for marketing. After all "you are buying a 36 CPU box" paying "a couple hundred bucks". Impressive, hum? Well not for me. > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > > > Midwest Internet Exchange > http://www.midwest-ix.com > > > ----- Original Message ----- > > From: "Colton Conor" > To: "Faisal Imtiaz" > Cc: "North American Network Operators Group" > Sent: Tuesday, May 19, 2015 9:06:26 PM > Subject: Re: Low Cost 10G Router > > So this new $1295 Mikrotik CCR1036-8G-2S+EM has a 36 core Tilera CPU with > 16GB of ram. Each core is running at 1.2Ghz? I assume that Mikrotik is > multicore in software, so why does this box not outperform these intel > boxes that everyone is recommending? Is it just a limitation of ports? > > > > On Tue, May 19, 2015 at 6:03 PM, Faisal Imtiaz > wrote: > > > > > > > > > > I've seen serious, unusual performance bottlenecks in Mikrotik CCR, in > > some > > > cases not even achieving a gigabit speeds on 10G interfaces. > Performance > > > drops more rapidly then Cisco with smaller packet sizes. > > > > > > -mel beckman > > > > > > Folks often forget that Mikrotik ROS can also run on x86 machines..... > > > > Size your favorite hardware (server) or network appliance with > appropriate > > ports, add MT ROS on a CF card, and you are good to go. > > > > We use i7 based network appliance with dual 10g cards (you can use a quad > > 10g card, such as those made by hotlav). > > > > with a 2gig of ram, you can easily do multiple (4-5 or more full bgp > > peers), and i7 are good for approx 1.2mill pps. > > > > > > Best of luck. > > > > > > Faisal Imtiaz > > Snappy Internet & Telecom > > > > From faisal at snappytelecom.net Wed May 20 23:00:13 2015 From: faisal at snappytelecom.net (Faisal Imtiaz) Date: Wed, 20 May 2015 23:00:13 +0000 (GMT) Subject: Low Cost 10G Router In-Reply-To: References: <32226940.868.1432141668998.JavaMail.mhammett@ThunderFuck> Message-ID: <1736530094.332850.1432162813597.JavaMail.zimbra@snappytelecom.net> Well said Eddie, It would be worth pointing out that on CCR's each port also has a core dedicated to it, a benefit of such a design is that each port is able to handle a much higher PPS rate, and if there is a DDOS attack on one port, it will not bring down the rest of the ports / router etc. (disclaimer, if the router is setup properly, without all traffic going thru the CPU etc etc). Faisal Imtiaz Snappy Internet & Telecom ----- Original Message ----- > From: "Eddie Tardist" > To: "North American Network Operators Group" > Sent: Wednesday, May 20, 2015 6:34:11 PM > Subject: Re: Low Cost 10G Router > > On Wed, May 20, 2015 at 2:07 PM, Mike Hammett wrote: > > > Well, the cores on a many-core CPU aren't going to have the "torque" that > > a Xeon would. They're also still working on the software. It has gotten a > > ton better over the life of the CCRs thus far. BGP is still atrocious on > > the CCRs, but that's because the route update process isn't multithreaded. > > It won't be multithreaded in the next major version either, but they will > > have done some programming voodoo (all programming is voodoo to me) to > > reign in the poor performance issues with full tables. > > > > https://youtu.be/ihZiAC-Rox8?t=37m8s > > > > I honestly don't know why most people gets impressed by the number of > Tylera cores on CCR and think it's a good thing. > Your "torque" point makes much sense to me. A few cores with decent clock > and Xeon or Rangeley "torque" is just better. Adding that much weak tylera > cores with low clock only results in much more context switching, much more > CPU Affinity needs. > > Multithreading the relevant grained bit of code will also lead to more > context switching, but for threads now instead of processes. > > As I understand the architecture of those solutions, I don't see why a bgp > daemon mono threaded is a problem. Ok, multithreaded would give a better > full routing convergence. But once the routing table is loaded it does not > matter how many threads the bgp process will use. The dirty work on Linux > (RouterOS kernel for that matter) will be done on the forward information > table, on the packet forwarding code and specially on softirq (interrupt > requests). This is where the bottleneck seems to be, IMHO. Linux is not > good at multithreaded packet forwarding and not good specially at handling > interrupt requests on multi-queue NICs. So, RouterOS is not good as well. > > Therefore that "several dozens" cheap and weak tylera cores powering CCR > boxes is absolutely not friendly for Linux core and RouterOS itself. > > I'm better served off with a smaller amount of cores with better clock and > better "torque" as Mr Hammett mentioned (I liked the expression usage yes) > and that's why a Linux or a BSD box with a couple Xeon CPUs will perform > better than CCR. Sometimes as someone mentioned a couple i7 cores will > outperform a CCR box as well. More torque, yeah. Less context switching and > time sharing wasted. > > However this horizontal scalar number of tylera cores on the CCR is good > for marketing. After all "you are buying a 36 CPU box" paying "a couple > hundred bucks". Impressive, hum? Well not for me. > > > > > > > > > > > > ----- > > Mike Hammett > > Intelligent Computing Solutions > > http://www.ics-il.com > > > > > > > > Midwest Internet Exchange > > http://www.midwest-ix.com > > > > > > ----- Original Message ----- > > > > From: "Colton Conor" > > To: "Faisal Imtiaz" > > Cc: "North American Network Operators Group" > > Sent: Tuesday, May 19, 2015 9:06:26 PM > > Subject: Re: Low Cost 10G Router > > > > So this new $1295 Mikrotik CCR1036-8G-2S+EM has a 36 core Tilera CPU with > > 16GB of ram. Each core is running at 1.2Ghz? I assume that Mikrotik is > > multicore in software, so why does this box not outperform these intel > > boxes that everyone is recommending? Is it just a limitation of ports? > > > > > > > > On Tue, May 19, 2015 at 6:03 PM, Faisal Imtiaz > > wrote: > > > > > > > > > > > > > > > I've seen serious, unusual performance bottlenecks in Mikrotik CCR, in > > > some > > > > cases not even achieving a gigabit speeds on 10G interfaces. > > Performance > > > > drops more rapidly then Cisco with smaller packet sizes. > > > > > > > > -mel beckman > > > > > > > > > Folks often forget that Mikrotik ROS can also run on x86 machines..... > > > > > > Size your favorite hardware (server) or network appliance with > > appropriate > > > ports, add MT ROS on a CF card, and you are good to go. > > > > > > We use i7 based network appliance with dual 10g cards (you can use a quad > > > 10g card, such as those made by hotlav). > > > > > > with a 2gig of ram, you can easily do multiple (4-5 or more full bgp > > > peers), and i7 are good for approx 1.2mill pps. > > > > > > > > > Best of luck. > > > > > > > > > Faisal Imtiaz > > > Snappy Internet & Telecom > > > > > > > > From bpnoc.lists at gmail.com Wed May 20 23:54:07 2015 From: bpnoc.lists at gmail.com (BPNoC Group) Date: Wed, 20 May 2015 20:54:07 -0300 Subject: Low Cost 10G Router In-Reply-To: References: <555C8EF0.5020205@foobar.org> <555C91E8.6050904@foobar.org> <555C92E7.1070600@foobar.org> Message-ID: On Wed, May 20, 2015 at 1:42 PM, Colton Conor wrote: > So, from the sounds of it most are saying for low cost, the way to go would > be a software router, which I was trying to avoid. To answer the bandwidth > question, we would have three 10G ports with three different carriers and > at max push 10Gbps of total traffic to start. > > I think this leaves me with hardware routers that can support full BGP > tables. So, who actually sells full bgp routers. So far on my list I have: > Juniper MX Series > Brocade MLXe or CER > Cisco ASR 9K > Huawei NE40E-X1-M4 > ZTE, not sure which model? > ALU 7750 > > Besides the above, am I missing anyone else that makes a true carrier grade > hardware router? > right now I'm pushing 11G/s 1.2Mpps, ServerU L-800 + Chelsio T580-CR, see below although you can ssh in, it's definitely not a software router since it's essentially T5 ASICS hardware pushing the packets % sudo rate -i cxgbe0 -R -b => Currently 11.08 Gbps/1199.50 kpps, Average: 11.08 Gbps/1199.50 kpps => Currently 11.13 Gbps/1206.68 kpps, Average: 11.10 Gbps/1203.08 kpps => Currently 11.11 Gbps/1202.70 kpps, Average: 11.10 Gbps/1202.95 kpps => Currently 11.13 Gbps/1206.54 kpps, Average: 11.11 Gbps/1203.85 kpps => Currently 11.24 Gbps/1207.24 kpps, Average: 11.12 Gbps/1204.53 kpps => Currently 11.12 Gbps/1208.79 kpps, Average: 11.12 Gbps/1205.24 kpps => Currently 11.22 Gbps/1208.03 kpps, Average: 11.12 Gbps/1205.63 kpps => Currently 11.12 Gbps/1207.79 kpps, Average: 11.12 Gbps/1205.90 kpps => Currently 11.23 Gbps/1207.76 kpps, Average: 11.12 Gbps/1206.11 kpps => Currently 11.24 Gbps/1207.46 kpps, Average: 11.12 Gbps/1206.24 kpps => Currently 11.32 Gbps/1207.82 kpps, Average: 11.12 Gbps/1206.39 kpps => Currently 11.03 Gbps/1207.04 kpps, Average: 11.12 Gbps/1206.44 kpps btw this is a 40G QSFP SR4 port it's a thousand dollar card on top of a thousand dollar router + a penny for their x8 raiser card you won't find anything like that below 3k USD for your 10G routing low cost needs, I'm guessing From Bryan at bryanfields.net Thu May 21 00:03:01 2015 From: Bryan at bryanfields.net (Bryan Fields) Date: Wed, 20 May 2015 20:03:01 -0400 Subject: Low Cost 10G Router In-Reply-To: References: Message-ID: <555D20B5.5040509@bryanfields.net> On 5/19/15 1:22 PM, Colton Conor wrote: > What options are available for a small, low cost router that has at least > four 10G ports, and can handle full BGP routes? All that I know of are the > Juniper MX80, and the Brocade CER line. What does Cisco and others have > that compete with these two? Any other vendors besides Juniper, Brocade, > and Cisco to look at? In the same price range as the MX80 there is the Alcatel SRa-4/8 router. These will do 100g in and out, and handle full tables. You get redundant control modules vs. a single on the juniper. BGP is multi-threaded on the box, does RPKI for route verification, and it's got extensive HQoS functionality amongst other features. -- Bryan Fields 727-409-1194 - Voice 727-214-2508 - Fax http://bryanfields.net From listas at esds.com.br Thu May 21 00:16:00 2015 From: listas at esds.com.br (Eduardo Schoedler) Date: Wed, 20 May 2015 21:16:00 -0300 Subject: Low Cost 10G Router In-Reply-To: References: <555C8EF0.5020205@foobar.org> <555C91E8.6050904@foobar.org> <555C92E7.1070600@foobar.org> Message-ID: 2015-05-20 20:54 GMT-03:00 BPNoC Group : > right now I'm pushing 11G/s 1.2Mpps, ServerU L-800 + Chelsio T580-CR, see > below > although you can ssh in, it's definitely not a software router since it's > essentially T5 ASICS hardware pushing the packets > > % sudo rate -i cxgbe0 -R -b > => Currently 11.08 Gbps/1199.50 kpps, Average: 11.08 Gbps/1199.50 kpps > => Currently 11.13 Gbps/1206.68 kpps, Average: 11.10 Gbps/1203.08 kpps > => Currently 11.11 Gbps/1202.70 kpps, Average: 11.10 Gbps/1202.95 kpps > => Currently 11.13 Gbps/1206.54 kpps, Average: 11.11 Gbps/1203.85 kpps > => Currently 11.24 Gbps/1207.24 kpps, Average: 11.12 Gbps/1204.53 kpps > => Currently 11.12 Gbps/1208.79 kpps, Average: 11.12 Gbps/1205.24 kpps > => Currently 11.22 Gbps/1208.03 kpps, Average: 11.12 Gbps/1205.63 kpps > => Currently 11.12 Gbps/1207.79 kpps, Average: 11.12 Gbps/1205.90 kpps > => Currently 11.23 Gbps/1207.76 kpps, Average: 11.12 Gbps/1206.11 kpps > => Currently 11.24 Gbps/1207.46 kpps, Average: 11.12 Gbps/1206.24 kpps > => Currently 11.32 Gbps/1207.82 kpps, Average: 11.12 Gbps/1206.39 kpps > => Currently 11.03 Gbps/1207.04 kpps, Average: 11.12 Gbps/1206.44 kpps How much routes in the FIB? Thanks. -- Eduardo Schoedler From colton.conor at gmail.com Thu May 21 02:01:40 2015 From: colton.conor at gmail.com (Colton Conor) Date: Wed, 20 May 2015 21:01:40 -0500 Subject: Low Cost 10G Router In-Reply-To: <555D20B5.5040509@bryanfields.net> References: <555D20B5.5040509@bryanfields.net> Message-ID: Bryan, Very interesting. Doesn't ALU mainly compare the new Alcatel SRa-4/8 router vs a MX104 though? Besides no redundancy, what limitations does the MX80 and MX104 have? I am assume the Juniper does not have "BGP is multi-threaded on the box, does RPKI for route verification, and it's got extensive HQoS functionality"? I heard the MX80 was limited on QoS, but never looked into it. On Wed, May 20, 2015 at 7:03 PM, Bryan Fields wrote: > On 5/19/15 1:22 PM, Colton Conor wrote: > > What options are available for a small, low cost router that has at least > > four 10G ports, and can handle full BGP routes? All that I know of are > the > > Juniper MX80, and the Brocade CER line. What does Cisco and others have > > that compete with these two? Any other vendors besides Juniper, Brocade, > > and Cisco to look at? > > In the same price range as the MX80 there is the Alcatel SRa-4/8 router. > These will do 100g in and out, and handle full tables. You get redundant > control modules vs. a single on the juniper. > > BGP is multi-threaded on the box, does RPKI for route verification, and > it's > got extensive HQoS functionality amongst other features. > > -- > Bryan Fields > > 727-409-1194 - Voice > 727-214-2508 - Fax > http://bryanfields.net > From bpnoc.lists at gmail.com Thu May 21 02:57:35 2015 From: bpnoc.lists at gmail.com (BPNoC Group) Date: Wed, 20 May 2015 23:57:35 -0300 Subject: Low Cost 10G Router In-Reply-To: References: <555C8EF0.5020205@foobar.org> <555C91E8.6050904@foobar.org> <555C92E7.1070600@foobar.org> Message-ID: On Wed, May 20, 2015 at 9:16 PM, Eduardo Schoedler wrote: > 2015-05-20 20:54 GMT-03:00 BPNoC Group : > > right now I'm pushing 11G/s 1.2Mpps, ServerU L-800 + Chelsio T580-CR, see > > below > > although you can ssh in, it's definitely not a software router since it's > > essentially T5 ASICS hardware pushing the packets > > > > % sudo rate -i cxgbe0 -R -b > > => Currently 11.08 Gbps/1199.50 kpps, Average: 11.08 Gbps/1199.50 kpps > > => Currently 11.13 Gbps/1206.68 kpps, Average: 11.10 Gbps/1203.08 kpps > > => Currently 11.11 Gbps/1202.70 kpps, Average: 11.10 Gbps/1202.95 kpps > > => Currently 11.13 Gbps/1206.54 kpps, Average: 11.11 Gbps/1203.85 kpps > > => Currently 11.24 Gbps/1207.24 kpps, Average: 11.12 Gbps/1204.53 kpps > > => Currently 11.12 Gbps/1208.79 kpps, Average: 11.12 Gbps/1205.24 kpps > > => Currently 11.22 Gbps/1208.03 kpps, Average: 11.12 Gbps/1205.63 kpps > > => Currently 11.12 Gbps/1207.79 kpps, Average: 11.12 Gbps/1205.90 kpps > > => Currently 11.23 Gbps/1207.76 kpps, Average: 11.12 Gbps/1206.11 kpps > > => Currently 11.24 Gbps/1207.46 kpps, Average: 11.12 Gbps/1206.24 kpps > > => Currently 11.32 Gbps/1207.82 kpps, Average: 11.12 Gbps/1206.39 kpps > > => Currently 11.03 Gbps/1207.04 kpps, Average: 11.12 Gbps/1206.44 kpps > > How much routes in the FIB? > > Thanks. > actually it makes no difference, the relevant route entries are stored in the T5 chip cxgbetool tells me I have 532447 entries right now for fib 0 anyway, I have a similar number of entries (a couple more due to pinned ipv6 not triggered to the card), but other than management port for ssh, snmp, webgui and netflow, only 180kpps for a trunked copper dmz segment is actually forwarded at fib. everything else is done on the card > > -- > Eduardo Schoedler > From wwaites at tardis.ed.ac.uk Thu May 21 08:22:48 2015 From: wwaites at tardis.ed.ac.uk (William Waites) Date: Thu, 21 May 2015 09:22:48 +0100 (BST) Subject: Low Cost 10G Router In-Reply-To: References: <32226940.868.1432141668998.JavaMail.mhammett@ThunderFuck> Message-ID: <20150521.092248.324000070090535921.wwaites@tardis.ed.ac.uk> > BGP is still atrocious on the CCRs, but that's because the route > update process isn't multithreaded. I recently took a close look at this, and that the update process is single-threaded is not the major problem so long as churn is not too great. The problem is that due to a deeper problem the entire forwarding table needs to be recalculated for *each* update. This means that even with the usual background noise in the DFZ the daemon is constantly updating everything. There are other bugs as well such as not supporting recursive next hop (e.g. via OSPF) lookup for IPv6 which means that if you have any iBGP sessions and more than one internal path you're out of luck with no obvious workaround. The stock answer from Mikrotik is that "everything will be fixed in the next major release of the OS". When that happens, and how long it takes to shake out the inevitable new bugs is an open question. Personally I give it at least a year before we would even try to use these seriously for BGP. Until then, it's FreeBSD and BIRD. Best, -w -- William Waites | School of Informatics http://tardis.ed.ac.uk/~wwaites/ | University of Edinburgh https://hubs.net.uk/ | HUBS AS60241 The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 801 bytes Desc: not available URL: From mark.tinka at seacom.mu Thu May 21 08:39:53 2015 From: mark.tinka at seacom.mu (Mark Tinka) Date: Thu, 21 May 2015 10:39:53 +0200 Subject: Low Cost 10G Router In-Reply-To: <555CC7E1.9040603@pubnix.net> References: <555C8EF0.5020205@foobar.org> <555C91E8.6050904@foobar.org> <555C92E7.1070600@foobar.org> <555CC7E1.9040603@pubnix.net> Message-ID: <555D99D9.3030601@seacom.mu> On 20/May/15 19:44, Alain Hebert wrote: > > Cisco > > I don't know about the licensing for the ASR but I mostly deal > with second hand devices. > > They are not flashy but do the job. If you are not trying to enable any IOS XR PIE's that need licenses (like video monitoring or optical monitoring), the only license worries you'll have on the ASR9001 is the ASR9001-S. The ASR9001-S is a 60Gbps version of the ASR9001 (50% capacity). You can upgrade the ASR9001-S to the ASR9001 with a software license. Mark. From jwbensley at gmail.com Thu May 21 09:52:50 2015 From: jwbensley at gmail.com (James Bensley) Date: Thu, 21 May 2015 10:52:50 +0100 Subject: Peering and Network Cost In-Reply-To: <9EBC7271-76AA-4771-936D-E0794A7E9920@mtin.net> References: <1429104508516.63849@hibernianetworks.com> <20150416072545.578b757f@echo.ms.redpill-linpro.com> <552F5374.5080202@seacom.mu> <20150416090053.4c01330c@echo.ms.redpill-linpro.com> <8E740079-528D-4C55-9BD0-8884A9EDC139@freethought-internet.co.uk> <9EBC7271-76AA-4771-936D-E0794A7E9920@mtin.net> Message-ID: On 17 April 2015 at 16:53, Justin Wilson - MTIN wrote: > Peering and peering on an exchange are two different things. Peering at an exchange has several benefits other than the simple cost of transit. If you are in a large data center which charges fees for cross connects a single cross connect to an exchange can save you money. > > Peering can also be a sales tool. If you buy from a VOIP provider and are peered with them your latency and such will go down. You also have more control over the QOS over that peer. This can be spun into marketing. > > Not to toot our own horn but we put together a list of benefits for our IX customers: > http://www.midwest-ix.com/blog/?p=15 > > > Also, a good article at: > http://blog.webserver.com.my/index.php/the-benefits-of-hosting-at-internet-exchange-point/ I also have a similar working document that I'd welcome feedback on to improve; https://docs.google.com/document/d/1i2bPZDt75hAwcR4iKMqaNSGIeM-nJSWLZ6SLTTnuXNs/edit?usp=sharing I've used it once to help an ISP evalutate peering and started them in the world of public peering. I'm now going through that proces again with another ISP and again they will start public peering soon, having used this doc in both cases as an intro/FAQ for them. Cheers, James. From zayed.mahmud at gmail.com Thu May 21 11:15:41 2015 From: zayed.mahmud at gmail.com (Zayed Mahmud) Date: Thu, 21 May 2015 17:15:41 +0600 Subject: Measuring DNS Performance & Graphing Logs In-Reply-To: References: Message-ID: Thanks a lot to Denis Fondras, Zachary, Andrew Smith, Christopher Morrow for your valuable advice. I've tried cacti but failed to get desired logs. i've also tried bind graph...but it consumes too much memory in the long run. can u suggest some suitable tools that i can measure the performance of the dns servers? like what shud b active and what shud not be in general safe dns server practice and check against my own settings or whatever the tool can query, something like nmap. this would be really helpful. i just need to make a report about my dns servers for my boss...and i'm clueless what to point out and what not to or how to evaluate it's performance. i'm running bind9 under unix environment. thanks in advance. On Tue, May 19, 2015 at 11:34 PM, Zayed Mahmud wrote: > Hello! > This is my first message to NANOG's mailing list. I hope someone can help > me. > > I was wondering which tool(s) can I use to measure the performance of my 3 > DNS servers (1 primary, 1 secondary, 1 solely cacheDNS)? From the stats I > would like to know if my DNS server is serving as it should be or if any of > it's options are set inappropriately and others alike. > > I looked for a while but could not find any. Any help would be highly > appreciated. I am running bind9 on UNIX platform. > > Question 2) I would also like to know how can I graph my DNS logs? And how > can I integrate it to my CACTI server as well? I couldn't find any suitable > plugin. Any suggestion? > > -- > > -- > Best Regards, > > *Zayed Mahmud* > > *Senior Core & IP Network Team,* > > *Banglalion Communications Limited, Bangladesh.* > -- -- Best Regards, *Zayed Mahmud.* From jabley at hopcount.ca Thu May 21 12:13:28 2015 From: jabley at hopcount.ca (Joe Abley) Date: Thu, 21 May 2015 08:13:28 -0400 Subject: Measuring DNS Performance & Graphing Logs In-Reply-To: References: Message-ID: <24B66829-0F9E-4D1D-9899-E84E7D999754@hopcount.ca> Hi Zayed, I think you're more likely to get good answers to your BIND-specific questions on the bind-users mailing list. See: https://lists.isc.org/mailman/listinfo/bind-users BIND9 has the capability to produce a vast variety and volume of logs, and dealing with logs in general is something that there are solutions for. Maybe look at logstash/elasticsearch as a starting point. Other BIND9 users on the bind-users list will no doubt have advice about what types logs they think are important. Recent releases of BIND9 can export a variety of statistics in XML and JSON formats using HTTP. Pulling those out and sending them to cacti/graphite/whatever is also a fairly non-DNS-specific problem to have. Advice for tuning a BIND9 recursive resolver's cache can be found in a tech note published by ISC; if that's not especially relevant to modern releases (I seem to think it was published some time ago) you could again look to the bind-users list for advice. For authority-only servers, your main concern is whether you have enough RAM to hold all your zone data. If you do, and if your server was built this decade and has no hardware faults, chances are you're good. Deciding whether your servers struggling to keep up with the load of the software you're running on it is another problem that is not specific to the DNS. Check with whoever provides your operating system for advice; look in to system statistics collection using things like collectd and publish somewhere you can record data and identify long-term trends so you know what looks normal (since until you know what normal looks like, you can't tell what a problem looks like). You can use commercial services like catchpoint and thousandeyes to check that your authoritative nameservers are suitably responsive. You can use non-commercial services like Atlas to do the same thing. If you've connected your nameservers to the network in such a way that there's a stateful firewall between the server and its clients, the report to your boss could be very brief and accurate; something like "service expected to fail at any time; explosion imminent" would do it. Joe On 21 May 2015, at 7:15, Zayed Mahmud wrote: > Thanks a lot to Denis Fondras, Zachary, Andrew Smith, Christopher > Morrow > for your valuable advice. > > I've tried cacti but failed to get desired logs. i've also tried bind > graph...but it consumes too much memory in the long run. > > can u suggest some suitable tools that i can measure the performance > of the > dns servers? like what shud b active and what shud not be in general > safe > dns server practice and check against my own settings or whatever the > tool > can query, something like nmap. this would be really helpful. i just > need > to make a report about my dns servers for my boss...and i'm clueless > what > to point out and what not to or how to evaluate it's performance. i'm > running bind9 under unix environment. > > thanks in advance. > > On Tue, May 19, 2015 at 11:34 PM, Zayed Mahmud > > wrote: > >> Hello! >> This is my first message to NANOG's mailing list. I hope someone can >> help >> me. >> >> I was wondering which tool(s) can I use to measure the performance of >> my 3 >> DNS servers (1 primary, 1 secondary, 1 solely cacheDNS)? From the >> stats I >> would like to know if my DNS server is serving as it should be or if >> any of >> it's options are set inappropriately and others alike. >> >> I looked for a while but could not find any. Any help would be highly >> appreciated. I am running bind9 on UNIX platform. >> >> Question 2) I would also like to know how can I graph my DNS logs? >> And how >> can I integrate it to my CACTI server as well? I couldn't find any >> suitable >> plugin. Any suggestion? >> >> -- >> >> -- >> Best Regards, >> >> *Zayed Mahmud* >> >> *Senior Core & IP Network Team,* >> >> *Banglalion Communications Limited, Bangladesh.* >> > > > > -- > > -- > Best Regards, > *Zayed Mahmud.* From rafael at gav.ufsc.br Thu May 21 12:40:23 2015 From: rafael at gav.ufsc.br (Rafael Possamai) Date: Thu, 21 May 2015 07:40:23 -0500 Subject: Peering and Network Cost In-Reply-To: References: <1429104508516.63849@hibernianetworks.com> <20150416072545.578b757f@echo.ms.redpill-linpro.com> <552F5374.5080202@seacom.mu> <20150416090053.4c01330c@echo.ms.redpill-linpro.com> <8E740079-528D-4C55-9BD0-8884A9EDC139@freethought-internet.co.uk> <9EBC7271-76AA-4771-936D-E0794A7E9920@mtin.net> Message-ID: James, curious to know... what size ISPs are they? In the last few years with the larger ones it has always been about lowering cost and increasing revenue, which throws the original idea of peering out the window (unless you are willing to pay). On Thu, May 21, 2015 at 4:52 AM, James Bensley wrote: > On 17 April 2015 at 16:53, Justin Wilson - MTIN wrote: > > Peering and peering on an exchange are two different things. Peering at > an exchange has several benefits other than the simple cost of transit. If > you are in a large data center which charges fees for cross connects a > single cross connect to an exchange can save you money. > > > > Peering can also be a sales tool. If you buy from a VOIP provider and > are peered with them your latency and such will go down. You also have > more control over the QOS over that peer. This can be spun into marketing. > > > > Not to toot our own horn but we put together a list of benefits for our > IX customers: > > http://www.midwest-ix.com/blog/?p=15 > > > > > > Also, a good article at: > > > http://blog.webserver.com.my/index.php/the-benefits-of-hosting-at-internet-exchange-point/ > > > I also have a similar working document that I'd welcome feedback on to > improve; > > > https://docs.google.com/document/d/1i2bPZDt75hAwcR4iKMqaNSGIeM-nJSWLZ6SLTTnuXNs/edit?usp=sharing > > I've used it once to help an ISP evalutate peering and started them in > the world of public peering. I'm now going through that proces again > with another ISP and again they will start public peering soon, having > used this doc in both cases as an intro/FAQ for them. > > Cheers, > James. > From faisal at snappytelecom.net Thu May 21 12:50:08 2015 From: faisal at snappytelecom.net (Faisal Imtiaz) Date: Thu, 21 May 2015 12:50:08 +0000 (GMT) Subject: Measuring DNS Performance & Graphing Logs In-Reply-To: References: Message-ID: <1779245858.340125.1432212608138.JavaMail.zimbra@snappytelecom.net> Zayed, What issues did you run into when trying to monitor Bind with Cacti ? here is a nice write up on this: http://gregsowell.com/?p=4763 If you don't find yourself getting far with this, then you can always use the Captain James T. Kirk's way of solving "Kobayashi Maru" ........ (Use powerdns instead of bind, powerdns has stats built in). Regards. Faisal Imtiaz Snappy Internet & Telecom ----- Original Message ----- > From: "Zayed Mahmud" > To: nanog at nanog.org > Sent: Thursday, May 21, 2015 7:15:41 AM > Subject: Re: Measuring DNS Performance & Graphing Logs > > Thanks a lot to Denis Fondras, Zachary, Andrew Smith, Christopher Morrow > for your valuable advice. > > I've tried cacti but failed to get desired logs. i've also tried bind > graph...but it consumes too much memory in the long run. > > can u suggest some suitable tools that i can measure the performance of the > dns servers? like what shud b active and what shud not be in general safe > dns server practice and check against my own settings or whatever the tool > can query, something like nmap. this would be really helpful. i just need > to make a report about my dns servers for my boss...and i'm clueless what > to point out and what not to or how to evaluate it's performance. i'm > running bind9 under unix environment. > > thanks in advance. > > On Tue, May 19, 2015 at 11:34 PM, Zayed Mahmud > wrote: > > > Hello! > > This is my first message to NANOG's mailing list. I hope someone can help > > me. > > > > I was wondering which tool(s) can I use to measure the performance of my 3 > > DNS servers (1 primary, 1 secondary, 1 solely cacheDNS)? From the stats I > > would like to know if my DNS server is serving as it should be or if any of > > it's options are set inappropriately and others alike. > > > > I looked for a while but could not find any. Any help would be highly > > appreciated. I am running bind9 on UNIX platform. > > > > Question 2) I would also like to know how can I graph my DNS logs? And how > > can I integrate it to my CACTI server as well? I couldn't find any suitable > > plugin. Any suggestion? > > > > -- > > > > -- > > Best Regards, > > > > *Zayed Mahmud* > > > > *Senior Core & IP Network Team,* > > > > *Banglalion Communications Limited, Bangladesh.* > > > > > > -- > > -- > Best Regards, > *Zayed Mahmud.* > From nanog at ics-il.net Thu May 21 12:50:29 2015 From: nanog at ics-il.net (Mike Hammett) Date: Thu, 21 May 2015 07:50:29 -0500 (CDT) Subject: Peering and Network Cost In-Reply-To: Message-ID: <18246469.3832.1432212621029.JavaMail.mhammett@ThunderFuck> As a small ISP, I'll peer with everybody possible. ;-) It's mostly about cost, but the quality goes up as well. Some of the people we're working with saw an increase in consumption the moment they joined IXes. The quality of the connections improved, so the streaming video (assumed) was able to flow at a higher bit-rate. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest Internet Exchange http://www.midwest-ix.com ----- Original Message ----- From: "Rafael Possamai" To: "James Bensley" Cc: nanog at nanog.org Sent: Thursday, May 21, 2015 7:40:23 AM Subject: Re: Peering and Network Cost James, curious to know... what size ISPs are they? In the last few years with the larger ones it has always been about lowering cost and increasing revenue, which throws the original idea of peering out the window (unless you are willing to pay). On Thu, May 21, 2015 at 4:52 AM, James Bensley wrote: > On 17 April 2015 at 16:53, Justin Wilson - MTIN wrote: > > Peering and peering on an exchange are two different things. Peering at > an exchange has several benefits other than the simple cost of transit. If > you are in a large data center which charges fees for cross connects a > single cross connect to an exchange can save you money. > > > > Peering can also be a sales tool. If you buy from a VOIP provider and > are peered with them your latency and such will go down. You also have > more control over the QOS over that peer. This can be spun into marketing. > > > > Not to toot our own horn but we put together a list of benefits for our > IX customers: > > http://www.midwest-ix.com/blog/?p=15 > > > > > > Also, a good article at: > > > http://blog.webserver.com.my/index.php/the-benefits-of-hosting-at-internet-exchange-point/ > > > I also have a similar working document that I'd welcome feedback on to > improve; > > > https://docs.google.com/document/d/1i2bPZDt75hAwcR4iKMqaNSGIeM-nJSWLZ6SLTTnuXNs/edit?usp=sharing > > I've used it once to help an ISP evalutate peering and started them in > the world of public peering. I'm now going through that proces again > with another ISP and again they will start public peering soon, having > used this doc in both cases as an intro/FAQ for them. > > Cheers, > James. > From sathish.kumar.ippani at gmail.com Thu May 21 10:09:22 2015 From: sathish.kumar.ippani at gmail.com (sathish kumar Ippani) Date: Thu, 21 May 2015 15:39:22 +0530 Subject: Cisco NX 5548UP Monitoring Message-ID: Hi All, Thanks for reviewing my query. I am very new to NX OS, and I would like to know, what are the entities that we can monitor. Currently we are doing basic monitoring like interface, bandwidth usage -- With Regards, Sathish Kumar Ippani 9177166040 From EDugas at zerofail.com Thu May 21 14:05:32 2015 From: EDugas at zerofail.com (Eric Dugas) Date: Thu, 21 May 2015 14:05:32 +0000 Subject: Peering and Network Cost In-Reply-To: <18246469.3832.1432212621029.JavaMail.mhammett@ThunderFuck> References: <18246469.3832.1432212621029.JavaMail.mhammett@ThunderFuck> Message-ID: We went that way too about 2 years ago. We usually pass around 25 to 40% of our North American traffic to the 4 IXes we're connected at a very low cost in Toronto and Montreal. One of the biggest IX we're connected to in New York is almost the same price per Mbps as some cheap transit providers but we're keeping our port for the connectivity improvement. Eric -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Mike Hammett Sent: May 21, 2015 8:50 AM To: nanog at nanog.org Subject: Re: Peering and Network Cost As a small ISP, I'll peer with everybody possible. ;-) It's mostly about cost, but the quality goes up as well. Some of the people we're working with saw an increase in consumption the moment they joined IXes. The quality of the connections improved, so the streaming video (assumed) was able to flow at a higher bit-rate. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest Internet Exchange http://www.midwest-ix.com ----- Original Message ----- From: "Rafael Possamai" To: "James Bensley" Cc: nanog at nanog.org Sent: Thursday, May 21, 2015 7:40:23 AM Subject: Re: Peering and Network Cost James, curious to know... what size ISPs are they? In the last few years with the larger ones it has always been about lowering cost and increasing revenue, which throws the original idea of peering out the window (unless you are willing to pay). On Thu, May 21, 2015 at 4:52 AM, James Bensley wrote: > On 17 April 2015 at 16:53, Justin Wilson - MTIN wrote: > > Peering and peering on an exchange are two different things. Peering at > an exchange has several benefits other than the simple cost of transit. If > you are in a large data center which charges fees for cross connects a > single cross connect to an exchange can save you money. > > > > Peering can also be a sales tool. If you buy from a VOIP provider and > are peered with them your latency and such will go down. You also have > more control over the QOS over that peer. This can be spun into marketing. > > > > Not to toot our own horn but we put together a list of benefits for our > IX customers: > > http://www.midwest-ix.com/blog/?p=15 > > > > > > Also, a good article at: > > > http://blog.webserver.com.my/index.php/the-benefits-of-hosting-at-internet-exchange-point/ > > > I also have a similar working document that I'd welcome feedback on to > improve; > > > https://docs.google.com/document/d/1i2bPZDt75hAwcR4iKMqaNSGIeM-nJSWLZ6SLTTnuXNs/edit?usp=sharing > > I've used it once to help an ISP evalutate peering and started them in > the world of public peering. I'm now going through that proces again > with another ISP and again they will start public peering soon, having > used this doc in both cases as an intro/FAQ for them. > > Cheers, > James. > From charles at thefnf.org Thu May 21 16:00:00 2015 From: charles at thefnf.org (charles at thefnf.org) Date: Thu, 21 May 2015 11:00:00 -0500 Subject: Measuring DNS Performance & Graphing Logs In-Reply-To: References: Message-ID: <94430b5d403e21318566598e6a2c7a79@thefnf.org> On 2015-05-21 06:15, Zayed Mahmud wrote: > > I've tried cacti but failed to get desired logs. i've also tried bind > graph...but it consumes too much memory in the long run. How constrained are your servers? What is "too much memory"? What logs are you looking for? Have you tried looking at the syslog? What is your level of experience with system/network administration? (Not trying to be insulting, genuinely curious). > > can u suggest some suitable tools that i can measure the performance of > the > dns servers? What sort of performance? What metrics are you trying to track? Please provide more details about exactly what you want. That will help us give you very specific suggestions. (We provide advice for free, have very busy schedules, the more specific you are the better). Deploy smokeping as has already been referenced in this thread. Zenoss also has graphing/monitoring of DNS. (I stay away from cacti/nagios personally for small deployments). Cati/Nagios are PHENOMANAL tools if you have a fully programmatic/automated deployment process that can populate cacti/nagios automatically. like what shud b active and what shud not be in general safe > dns server practice As with the vast majority of widely deployed software packages (Microsoft,debian,cisco etc), the vendor provides support/documentation right on their website: https://www.isc.org/support/ I always recommend to people that they spend about 70% of implementation time on reading the docs/understanding/researching terms/concepts they don't know for the system they are deploying, 20% on testing, 10% on actual go live. I've seen way too many operators rush to deploy something and thoroughly break a production network. and check against my own settings or whatever the tool > can query, something like nmap. I recommend openvas.org if you want a tool for internal use (it's free, very comparable to Nessus). Not that Nessus isn't a good product, it's just a pain to deal with the licensing system etc (requires too much sysadmin time to maintain at least in my deployment). this would be really helpful. i just need > to make a report about my dns servers for my boss...and i'm clueless > what > to point out and what not to or how to evaluate it's performance. i'm > running bind9 under unix environment. > What are the requirements of the report? > thanks in advance. > From jwbensley at gmail.com Thu May 21 16:02:12 2015 From: jwbensley at gmail.com (James Bensley) Date: Thu, 21 May 2015 17:02:12 +0100 Subject: Peering and Network Cost In-Reply-To: References: <1429104508516.63849@hibernianetworks.com> <20150416072545.578b757f@echo.ms.redpill-linpro.com> <552F5374.5080202@seacom.mu> <20150416090053.4c01330c@echo.ms.redpill-linpro.com> <8E740079-528D-4C55-9BD0-8884A9EDC139@freethought-internet.co.uk> <9EBC7271-76AA-4771-936D-E0794A7E9920@mtin.net> Message-ID: On 21 May 2015 at 13:40, Rafael Possamai wrote: > James, curious to know... what size ISPs are they? In the last few years > with the larger ones it has always been about lowering cost and increasing > revenue, which throws the original idea of peering out the window (unless > you are willing to pay). Yes agreed, I have seen the same behaviour too with larger companies although peering can lower costs as I will show below in the 2nd example. Typically though I hear what you are saying, if you are a larger transit consumer with larger commits you really have the weight to stand on your transit provider?s neck until they give you the price you want (which is pretty effective, transit really is dirt cheap these days if you have the traffic levels to back it up). With regards to your question I can't say too much as I'm not sure what I can and can't disclose. The first ISP was a small one with circa 1Gbps of total transit volume (at the time I carried them through the peering process, could be different now). They managed to peer off a third of their transit traffic requirement, so dropping a third of their transit made them a small but acceptable cost saving (since at the time they only had circa 1Gbps of total ingress/egress traffic). For them the marketing aspect of being at a big well know IX was/is very important. So from that rather small cost saving gained from reducing their transit commit with the overhead of peering, the value add for them was greatly boosted by being able to market their IX presence. In the period that followed joining their first IXP that ISP then gained further from a technical perspective as we managed to take direct peering?s across that IXP LAN to some VoIP upstreams and downstreams of theirs and a hosted service provider that ISP works with, and in all those cases that has reduced latency and packet loss which customers have directly noted on having a positive impact. The second ISP I'm now running this exercise for is a medium size ISP, they have about 5Gbps of transit requirements at present and are hoping to peer off half of that. They also intent to increase the transit requirements to circa 10G within the next couple of years, so if they peer off 50% ingress/egress traffic they stand to save quite a bit of money. A 10G peering port is usually a fixed priced so they will just see the ROI on that port grow over time hopefully. One important reason they will make a significant cost saving is due to legacy contracts such as some old PA space they can drop off which is very costly and old transit contracts still on high cost-per-Mbps tariffs My colleague on this expects to cut the transit bill literally in half by the end of the first year. Cheers, James. From jared at puck.nether.net Thu May 21 16:17:27 2015 From: jared at puck.nether.net (Jared Mauch) Date: Thu, 21 May 2015 12:17:27 -0400 Subject: Measuring DNS Performance & Graphing Logs In-Reply-To: <94430b5d403e21318566598e6a2c7a79@thefnf.org> References: <94430b5d403e21318566598e6a2c7a79@thefnf.org> Message-ID: > On May 21, 2015, at 12:00 PM, charles at thefnf.org wrote: > >> can u suggest some suitable tools that i can measure the performance of the >> dns servers? > > What sort of performance? What metrics are you trying to track? Please provide more details about exactly what you want. > That will help us give you very specific suggestions. (We provide advice for free, have very busy schedules, the more specific > you are the better). At the recent DNS-OARC meeting there was an interesting discussion about a new tool called DNSDIST. It?s part of PowerDNS and there is also a independent tar one can fetch. What is interesting about it is it can report on a lot of data about the performance of your DNS servers. Some people use a load balancer, and this will do that but be application aware and can easily route certain types of queries to another server. (e.g.: arpa requests to dedicated servers, same as domains that may be used/abused). It provides realtime graphs of CPU usage and query rates as well as average response times. You can set query rate limits and it will balance as you specify. This is useful as many people who know/use Linux have seen the issues with UDP kernel performance. If you?re not aware, do this: UDP: iperf -s -u iperf -u -c localhost -b 25000m eg: [ 3] 0.0-10.0 sec 4.50 GBytes 3.87 Gbits/sec 0.000 ms 84054/3374408 (2.5%) vs TCP: iperf -s iperf -c localhost [ 3] 0.0-10.0 sec 56.1 GBytes 48.2 Gbits/sec - Jared From dave.taht at gmail.com Thu May 21 16:59:09 2015 From: dave.taht at gmail.com (Dave Taht) Date: Thu, 21 May 2015 09:59:09 -0700 Subject: Peering and Network Cost In-Reply-To: <552EA4F1.5010700@netassist.ua> References: <1429104508516.63849@hibernianetworks.com> <552EA4F1.5010700@netassist.ua> Message-ID: On Wed, Apr 15, 2015 at 10:50 AM, Max Tulyev wrote: > Hi Roderick, > > transit cost is lowering close to peering cost, so it is doubghtful > economy on small channels. If you don't live in > Amsterdam/Frankfurt/London - add the DWDM cost from you to one of major > IX. That's the magic. > > In large scale peering is still efficient. It is efficient on local > traffic which is often huge. Two things I am curious about are 1) What is the measured benefit of moving a netflix server into your local ISP network and 2) does anyone measure "cross town latency". If we lived in a world where skype/voip/etc transited the local town only, what sort of latencies would be see within an ISP and within a cross-connect from, say a gfiber to a comcast? Once upon a time I'd heard that most phone calls were within 6 miles of the person's home, but I don't remember the breakdown of those call percentages (?), and certainly the old-style phone system was achieving very low latencies for those kinds of traffic. > On 04/15/15 17:28, Rod Beck wrote: >> Hi, >> >> >> As you all know, transit costs in the wholesale market today a few percent of what it did in 2000. I assume that most of that decline is due to a modified version of Moore's Law (I don't believe optics costs decline 50% every 18 months) and the advent of maverick players like Cogent that broker cozy oligopoly pricing. >> >> >> But I also wondering whether the advent of widespread peering (promiscuous?) among the Tier 2 players (buy transit and peer) has played a role. In 2000 peering was still an exclusive club and in contrast today Tier 2 players often have hundreds of peers. Peering should reduce costs and also demand in the wholesale IP market. Supply increases and demand falls. >> >> >> I thank you in advance for any insights. >> >> >> Regards, >> >> >> - R. >> >> >> Roderick Beck >> Sales Director/Europe and the Americas >> Hibernia Networks >> >> This e-mail and any attachments thereto is intended only for use by the addressee(s) named herein and may be proprietary and/or legally privileged. If you are not the intended recipient of this e-mail, you are hereby notified that any dissemination, distribution or copying of this email, and any attachments thereto, without the prior written permission of the sender is strictly prohibited. If you receive this e-mail in error, please immediately telephone or e-mail the sender and permanently delete the original copy and any copy of this e-mail, and any printout thereof. All documents, contracts or agreements referred or attached to this e-mail are SUBJECT TO CONTRACT. The contents of an attachment to this e-mail may contain software viruses that could damage your own computer system. While Hibernia Networks has taken every reasonable precaution to minimize this risk, we cannot accept liability for any damage that you sustain as a result of software viruses. You should carry out your > > own virus checks before opening any attachment. >> > -- Dave T?ht Open Networking needs **Open Source Hardware** https://plus.google.com/u/0/+EricRaymond/posts/JqxCe2pFr67 From v.bajpai at jacobs-university.de Thu May 21 19:34:58 2015 From: v.bajpai at jacobs-university.de (Bajpai, Vaibhav) Date: Thu, 21 May 2015 19:34:58 +0000 Subject: bing on v6 Message-ID: <0C722D1B-4870-47CC-ABDF-FF1449CA6E01@jacobs-university.de> Dear NANOG, We do not see AAAA entries for www.bing.com since Sep 2013 anymore [1]. For sure this is only from our measurement vantage points, so may not be true globally. Does anybody know the backstory of what happened? [1] http://goo.gl/K1Zx4u (see: slide 23/32) Thanks! Best, Vaibhav ===================================================== Vaibhav Bajpai Research I, Room 91 Computer Networks and Distributed Systems (CNDS) Lab School of Engineering and Sciences Jacobs University Bremen, Germany www.vaibhavbajpai.com ===================================================== -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 496 bytes Desc: Message signed with OpenPGP using GPGMail URL: From jared at puck.nether.net Thu May 21 19:47:51 2015 From: jared at puck.nether.net (Jared Mauch) Date: Thu, 21 May 2015 15:47:51 -0400 Subject: bing on v6 In-Reply-To: <0C722D1B-4870-47CC-ABDF-FF1449CA6E01@jacobs-university.de> References: <0C722D1B-4870-47CC-ABDF-FF1449CA6E01@jacobs-university.de> Message-ID: <7668676C-053D-497E-AB5C-9D06A7227BFE@puck.nether.net> > On May 21, 2015, at 3:34 PM, Bajpai, Vaibhav wrote: > > Dear NANOG, > > We do not see AAAA entries for www.bing.com since Sep 2013 anymore [1]. > For sure this is only from our measurement vantage points, so may not > be true globally. Does anybody know the backstory of what happened? > > [1] http://goo.gl/K1Zx4u (see: slide 23/32) There are a few others that turned it off after IPv6 day and/or launch such as bit.ly. I have heard that some of the outstanding top 25 properties are going to launch IPv6 ?soon?, where that may be some point in 2015. I know many people have been hesitant as they don?t have the same resolver -> ip mapping data for IPv6 yet. - jared From frnkblk at iname.com Thu May 21 20:14:48 2015 From: frnkblk at iname.com (Frank Bulk) Date: Thu, 21 May 2015 15:14:48 -0500 Subject: bing on v6 In-Reply-To: <7668676C-053D-497E-AB5C-9D06A7227BFE@puck.nether.net> References: <0C722D1B-4870-47CC-ABDF-FF1449CA6E01@jacobs-university.de> <7668676C-053D-497E-AB5C-9D06A7227BFE@puck.nether.net> Message-ID: <002501d09402$c968abf0$5c3a03d0$@iname.com> There are several properties that used to work and do not anymore: wireless.att.com www.att.net www.charter.com www.globalcrossing.com John B. told me a couple of days ago to "stand by" for dns.comcast.net and www.dnsec.comcast.net, so I'm doing that. =) And www.frontier.com has been broken for 6 days. Frank -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Jared Mauch Sent: Thursday, May 21, 2015 2:48 PM To: Bajpai, Vaibhav Cc: nanog at nanog.org Subject: Re: bing on v6 > On May 21, 2015, at 3:34 PM, Bajpai, Vaibhav wrote: > > Dear NANOG, > > We do not see AAAA entries for www.bing.com since Sep 2013 anymore [1]. > For sure this is only from our measurement vantage points, so may not > be true globally. Does anybody know the backstory of what happened? > > [1] http://goo.gl/K1Zx4u (see: slide 23/32) There are a few others that turned it off after IPv6 day and/or launch such as bit.ly. I have heard that some of the outstanding top 25 properties are going to launch IPv6 ?soon?, where that may be some point in 2015. I know many people have been hesitant as they don?t have the same resolver -> ip mapping data for IPv6 yet. - jared From johnl at iecc.com Thu May 21 21:14:18 2015 From: johnl at iecc.com (John Levine) Date: 21 May 2015 21:14:18 -0000 Subject: bing on v6 In-Reply-To: <002501d09402$c968abf0$5c3a03d0$@iname.com> Message-ID: <20150521211418.71475.qmail@ary.lan> >And www.frontier.com has been broken for 6 days. Works fine for me over v6 although the chain of TLS certificates looks kind of funky. R's, John From mark.tinka at seacom.mu Fri May 22 03:03:07 2015 From: mark.tinka at seacom.mu (Mark Tinka) Date: Fri, 22 May 2015 05:03:07 +0200 Subject: Peering and Network Cost In-Reply-To: References: <1429104508516.63849@hibernianetworks.com> <552EA4F1.5010700@netassist.ua> Message-ID: <555E9C6B.2010607@seacom.mu> On 21/May/15 18:59, Dave Taht wrote: > Two things I am curious about are 1) What is the measured benefit of > moving a netflix server into your local ISP network > > and 2) does anyone measure "cross town latency". If we lived in a > world where skype/voip/etc transited the local town only, > what sort of latencies would be see within an ISP and within a > cross-connect from, say a gfiber to a comcast? On average, 1ms for every 100km. We've seen this in practice - consistently - for any fibre deployed within the same town/city. Unless someone does something very wrong with the fibre, suffers terrible hardware issues, deliberately implements debilitating bandwidth management or does a piss-poor job of network design, it would be reasonably hard to go above +/- 1ms for traffic that originates and terminates within the same town, let alone 6 miles of speaking parties. Mark. From anthony.kosednar at gmail.com Fri May 22 03:07:01 2015 From: anthony.kosednar at gmail.com (Anthony Kosednar) Date: Thu, 21 May 2015 20:07:01 -0700 Subject: Peering and Network Cost In-Reply-To: <555E9C6B.2010607@seacom.mu> References: <1429104508516.63849@hibernianetworks.com> <552EA4F1.5010700@netassist.ua> <555E9C6B.2010607@seacom.mu> Message-ID: On Thursday, May 21, 2015, Mark Tinka wrote: > > > On 21/May/15 18:59, Dave Taht wrote: > > > Two things I am curious about are 1) What is the measured benefit of > > moving a netflix server into your local ISP network > > > > and 2) does anyone measure "cross town latency". If we lived in a > > world where skype/voip/etc transited the local town only, > > what sort of latencies would be see within an ISP and within a > > cross-connect from, say a gfiber to a comcast? > > On average, 1ms for every 100km. > > We've seen this in practice - consistently - for any fibre deployed > within the same town/city. > > Unless someone does something very wrong with the fibre, suffers > terrible hardware issues, deliberately implements debilitating bandwidth > management or does a piss-poor job of network design, it would be > reasonably hard to go above +/- 1ms for traffic that originates and > terminates within the same town, let alone 6 miles of speaking parties. > > Mark. > -- Sent from Gmail Mobile From frnkblk at iname.com Fri May 22 03:33:01 2015 From: frnkblk at iname.com (Frank Bulk) Date: Thu, 21 May 2015 22:33:01 -0500 Subject: bing on v6 In-Reply-To: <20150521211418.71475.qmail@ary.lan> References: <002501d09402$c968abf0$5c3a03d0$@iname.com> <20150521211418.71475.qmail@ary.lan> Message-ID: <003101d09440$018278d0$04876a70$@iname.com> It literally came up within minutes of my posting. =) I know there are Frontier staff lurking on NANOG and I had already engaged a senior Frontier person on this last week, but he was dependent on their IT department to resolve this. Frank -----Original Message----- From: John Levine [mailto:johnl at iecc.com] Sent: Thursday, May 21, 2015 4:14 PM To: nanog at nanog.org Cc: frnkblk at iname.com Subject: Re: bing on v6 >And www.frontier.com has been broken for 6 days. Works fine for me over v6 although the chain of TLS certificates looks kind of funky. R's, John From jwbensley at gmail.com Fri May 22 12:29:46 2015 From: jwbensley at gmail.com (James Bensley) Date: Fri, 22 May 2015 13:29:46 +0100 Subject: Is anyone working on an RFC for standardized maintenance notifications In-Reply-To: <555219EA.1080004@direcpath.com> References: <555219EA.1080004@direcpath.com> Message-ID: On 12 May 2015 at 16:19, Robert Drake wrote: > Like the "Automated Copyright Notice System" (http://www.acns.net/spec.html) > except I don't think they went through any official standards body besides > their own MPAA, or whatever. > > I get circuits from several vendors and get maintenance notifications from > them all the time. Each has a different format and each supplies different > details for their maintenance. Most of the time there are core things that > everyone wants and it would be nice if it were automatically readable so > automation could be performed (i.e., our NOC gets the email into our > ticketing system. It is recognized as being part of an existing maintenance > due to maintenance id# (or new, whatever) and fields are automatically > populated or updated accordingly. > > If you're uncomfortable with the phrase "automatically populated > accordingly" for security reasons then you can replace that with "NOC > technician verifies all fields are correct and hits update ticket." or > whatever. > > The main fields I think you would need: > > 1. Company Name > 2. Maintenance ID > 3. Start Date > 4. Expected length > 5. Circuits impacted (if known or applicable) > 6. Description/Scope of Work (free form) > 7. Ticket Number > 8. Contact > I'm behind you although this would be a BCOP and not an RFC really. Check out: http://bcop.nanog.org/index.php/Main_Page and http://www.internetsociety.org/deploy360/projects/bcop/ Cheers, James. From mis at seiden.com Fri May 22 13:43:07 2015 From: mis at seiden.com (Mark Seiden) Date: Fri, 22 May 2015 09:43:07 -0400 Subject: need help in london for approx a day of unracking and packing equipment to be shipped Message-ID: <181869A8-FC08-4022-9DA6-95FBD2B3A1B9@seiden.com> looking for a helper in London: a US-based client of mine is turning off a small London data center presence ASAP. they want to hire someone trustworthy to unrack, properly pack up and ship to the US a small number of 1u and 2u sized devices and hard drives. the person has to be capable of removing hard drives from two servers, and responsible enough to work in a data center without issues. the company will pay for their time on an hourly basis and reimburse the packing materials and shipping expense. at least two servers are a few year old but perfectly usable dell servers and are not worth shipping, so can (should) be donated to a worthy cause of the helper's choice, or kept by the helper as a bonus. if you know of a person or company who can do this, point me at them, please. and thanks for your attention. From cscora at apnic.net Fri May 22 18:11:41 2015 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 23 May 2015 04:11:41 +1000 (AEST) Subject: Weekly Routing Table Report Message-ID: <201505221811.t4MIBfTc028063@thyme.rand.apnic.net> This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. The posting is sent to APOPS, NANOG, AfNOG, AusNOG, SANOG, PacNOG, CaribNOG and the RIPE Routing Working Group. Daily listings are sent to bgp-stats at lists.apnic.net For historical data, please see http://thyme.rand.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 23 May, 2015 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 545745 Prefixes after maximum aggregation (per Origin AS): 207464 Deaggregation factor: 2.63 Unique aggregates announced (without unneeded subnets): 265833 Total ASes present in the Internet Routing Table: 50422 Prefixes per ASN: 10.82 Origin-only ASes present in the Internet Routing Table: 36678 Origin ASes announcing only one prefix: 16311 Transit ASes present in the Internet Routing Table: 6326 Transit-only ASes present in the Internet Routing Table: 169 Average AS path length visible in the Internet Routing Table: 4.4 Max AS path length visible: 44 Max AS path prepend of ASN ( 55944) 41 Prefixes from unregistered ASNs in the Routing Table: 1167 Unregistered ASNs in the Routing Table: 430 Number of 32-bit ASNs allocated by the RIRs: 9576 Number of 32-bit ASNs visible in the Routing Table: 7418 Prefixes from 32-bit ASNs in the Routing Table: 27111 Number of bogon 32-bit ASNs visible in the Routing Table: 5 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 360 Number of addresses announced to Internet: 2758760032 Equivalent to 164 /8s, 111 /16s and 86 /24s Percentage of available address space announced: 74.5 Percentage of allocated address space announced: 74.5 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 97.4 Total number of prefixes smaller than registry allocations: 183202 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 134788 Total APNIC prefixes after maximum aggregation: 39117 APNIC Deaggregation factor: 3.45 Prefixes being announced from the APNIC address blocks: 141106 Unique aggregates announced from the APNIC address blocks: 57125 APNIC Region origin ASes present in the Internet Routing Table: 5051 APNIC Prefixes per ASN: 27.94 APNIC Region origin ASes announcing only one prefix: 1215 APNIC Region transit ASes present in the Internet Routing Table: 883 Average APNIC Region AS path length visible: 4.3 Max APNIC Region AS path length visible: 44 Number of APNIC region 32-bit ASNs visible in the Routing Table: 1447 Number of APNIC addresses announced to Internet: 749167808 Equivalent to 44 /8s, 167 /16s and 100 /24s Percentage of available APNIC address space announced: 87.6 APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079, 55296-56319, 58368-59391, 63488-64098, 131072-135580 APNIC Address Blocks 1/8, 14/8, 27/8, 36/8, 39/8, 42/8, 43/8, 49/8, 58/8, 59/8, 60/8, 61/8, 101/8, 103/8, 106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 133/8, 150/8, 153/8, 163/8, 171/8, 175/8, 180/8, 182/8, 183/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, 223/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 178915 Total ARIN prefixes after maximum aggregation: 88005 ARIN Deaggregation factor: 2.03 Prefixes being announced from the ARIN address blocks: 181537 Unique aggregates announced from the ARIN address blocks: 84594 ARIN Region origin ASes present in the Internet Routing Table: 16615 ARIN Prefixes per ASN: 10.93 ARIN Region origin ASes announcing only one prefix: 6120 ARIN Region transit ASes present in the Internet Routing Table: 1726 Average ARIN Region AS path length visible: 3.8 Max ARIN Region AS path length visible: 24 Number of ARIN region 32-bit ASNs visible in the Routing Table: 449 Number of ARIN addresses announced to Internet: 1080959776 Equivalent to 64 /8s, 110 /16s and 35 /24s Percentage of available ARIN address space announced: 57.2 ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 53248-55295, 62464-63487, 64198-64296, 393216-395164 ARIN Address Blocks 3/8, 4/8, 6/8, 7/8, 8/8, 9/8, 11/8, 12/8, 13/8, 15/8, 16/8, 17/8, 18/8, 19/8, 20/8, 21/8, 22/8, 23/8, 24/8, 26/8, 28/8, 29/8, 30/8, 32/8, 33/8, 34/8, 35/8, 38/8, 40/8, 44/8, 45/8, 47/8, 48/8, 50/8, 52/8, 53/8, 54/8, 55/8, 56/8, 57/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, 100/8, 104/8, 107/8, 108/8, 128/8, 129/8, 130/8, 131/8, 132/8, 134/8, 135/8, 136/8, 137/8, 138/8, 139/8, 140/8, 142/8, 143/8, 144/8, 146/8, 147/8, 148/8, 149/8, 152/8, 155/8, 156/8, 157/8, 158/8, 159/8, 160/8, 161/8, 162/8, 164/8, 165/8, 166/8, 167/8, 168/8, 169/8, 170/8, 172/8, 173/8, 174/8, 184/8, 192/8, 198/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 214/8, 215/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 131982 Total RIPE prefixes after maximum aggregation: 65942 RIPE Deaggregation factor: 2.00 Prefixes being announced from the RIPE address blocks: 138374 Unique aggregates announced from the RIPE address blocks: 85912 RIPE Region origin ASes present in the Internet Routing Table: 17965 RIPE Prefixes per ASN: 7.70 RIPE Region origin ASes announcing only one prefix: 8156 RIPE Region transit ASes present in the Internet Routing Table: 2974 Average RIPE Region AS path length visible: 4.9 Max RIPE Region AS path length visible: 34 Number of RIPE region 32-bit ASNs visible in the Routing Table: 3719 Number of RIPE addresses announced to Internet: 695003136 Equivalent to 41 /8s, 108 /16s and 232 /24s Percentage of available RIPE address space announced: 101.0 RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-52223, 56320-58367 59392-61439, 61952-62463, 196608-202239 RIPE Address Blocks 2/8, 5/8, 25/8, 31/8, 37/8, 46/8, 51/8, 62/8, 77/8, 78/8, 79/8, 80/8, 81/8, 82/8, 83/8, 84/8, 85/8, 86/8, 87/8, 88/8, 89/8, 90/8, 91/8, 92/8, 93/8, 94/8, 95/8, 109/8, 141/8, 145/8, 151/8, 176/8, 178/8, 185/8, 188/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 59849 Total LACNIC prefixes after maximum aggregation: 11318 LACNIC Deaggregation factor: 5.29 Prefixes being announced from the LACNIC address blocks: 70228 Unique aggregates announced from the LACNIC address blocks: 32685 LACNIC Region origin ASes present in the Internet Routing Table: 2439 LACNIC Prefixes per ASN: 28.79 LACNIC Region origin ASes announcing only one prefix: 625 LACNIC Region transit ASes present in the Internet Routing Table: 501 Average LACNIC Region AS path length visible: 4.9 Max LACNIC Region AS path length visible: 25 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 1691 Number of LACNIC addresses announced to Internet: 168155264 Equivalent to 10 /8s, 5 /16s and 216 /24s Percentage of available LACNIC address space announced: 100.2 LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 61440-61951, 64099-64197, 262144-265628 + ERX transfers LACNIC Address Blocks 177/8, 179/8, 181/8, 186/8, 187/8, 189/8, 190/8, 191/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 12925 Total AfriNIC prefixes after maximum aggregation: 3037 AfriNIC Deaggregation factor: 4.26 Prefixes being announced from the AfriNIC address blocks: 14140 Unique aggregates announced from the AfriNIC address blocks: 5190 AfriNIC Region origin ASes present in the Internet Routing Table: 734 AfriNIC Prefixes per ASN: 19.26 AfriNIC Region origin ASes announcing only one prefix: 195 AfriNIC Region transit ASes present in the Internet Routing Table: 159 Average AfriNIC Region AS path length visible: 4.5 Max AfriNIC Region AS path length visible: 25 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 112 Number of AfriNIC addresses announced to Internet: 65171456 Equivalent to 3 /8s, 226 /16s and 112 /24s Percentage of available AfriNIC address space announced: 64.7 AfriNIC AS Blocks 36864-37887, 327680-328703 & ERX transfers AfriNIC Address Blocks 41/8, 102/8, 105/8, 154/8, 196/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4766 2926 11557 913 Korea Telecom 17974 2770 904 81 PT Telekomunikasi Indonesia 7545 2424 336 130 TPG Telecom Limited 4755 2022 423 219 TATA Communications formerly 4538 1937 4190 72 China Education and Research 9829 1636 1326 39 National Internet Backbone 9808 1572 8717 28 Guangdong Mobile Communicatio 4808 1470 2250 468 CNCGROUP IP network China169 9583 1449 120 588 Sify Limited 9498 1329 335 100 BHARTI Airtel Ltd. Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 22773 3038 2958 141 Cox Communications Inc. 6389 2797 3688 51 BellSouth.net Inc. 3356 2569 10686 492 Level 3 Communications, Inc. 18566 2042 379 185 MegaPath Corporation 20115 1881 1851 422 Charter Communications 6983 1749 866 245 EarthLink, Inc. 4323 1607 1022 410 tw telecom holdings, inc. 30036 1528 311 487 Mediacom Communications Corp 701 1391 11322 680 MCI Communications Services, 22561 1359 413 249 CenturyTel Internet Holdings, Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 39891 2473 132 7 SaudiNet, Saudi Telecom Compa 34984 2019 305 356 TELLCOM ILETISIM HIZMETLERI A 20940 1888 738 1380 Akamai International B.V. 6849 1053 356 24 JSC "Ukrtelecom" 8402 1050 544 15 OJSC "Vimpelcom" 31148 1049 45 23 Freenet Ltd. 13188 1041 97 70 TOV "Bank-Inform" 12479 938 868 72 France Telecom Espana SA 6830 908 2693 467 Liberty Global Operations B.V 8551 886 373 48 Bezeq International-Ltd Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 10620 3232 529 188 Telmex Colombia S.A. 28573 2300 2168 130 NET Servi?os de Comunica??o S 7303 1662 1045 243 Telecom Argentina S.A. 8151 1649 3253 470 Uninet S.A. de C.V. 6147 1639 374 30 Telefonica del Peru S.A.A. 6503 1250 421 54 Axtel, S.A.B. de C.V. 26615 1073 2325 35 Tim Celular S.A. 7738 999 1882 41 Telemar Norte Leste S.A. 3816 923 423 157 COLOMBIA TELECOMUNICACIONES S 18881 868 1036 22 Global Village Telecom Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 8452 1699 958 13 TE-AS 24863 899 280 26 Link Egypt (Link.NET) 36903 504 254 98 Office National des Postes et 36992 423 1229 32 ETISALAT MISR 24835 304 146 13 Vodafone Data 37492 303 171 72 Orange Tunisie 3741 250 857 208 Internet Solutions 29571 242 21 12 Cote d'Ivoire Telecom 37054 211 19 6 Data Telecom Service 36947 192 807 13 Telecom Algeria Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 10620 3232 529 188 Telmex Colombia S.A. 22773 3038 2958 141 Cox Communications Inc. 4766 2926 11557 913 Korea Telecom 6389 2797 3688 51 BellSouth.net Inc. 17974 2770 904 81 PT Telekomunikasi Indonesia 3356 2569 10686 492 Level 3 Communications, Inc. 39891 2473 132 7 SaudiNet, Saudi Telecom Compa 7545 2424 336 130 TPG Telecom Limited 28573 2300 2168 130 NET Servi?os de Comunica??o S 18566 2042 379 185 MegaPath Corporation Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 22773 3038 2897 Cox Communications Inc. 6389 2797 2746 BellSouth.net Inc. 17974 2770 2689 PT Telekomunikasi Indonesia 39891 2473 2466 SaudiNet, Saudi Telecom Compa 7545 2424 2294 TPG Telecom Limited 28573 2300 2170 NET Servi?os de Comunica??o S 3356 2569 2077 Level 3 Communications, Inc. 4766 2926 2013 Korea Telecom 4538 1937 1865 China Education and Research 18566 2042 1857 MegaPath Corporation Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 30662 UNALLOCATED 8.2.129.0/24 3356 Level 3 Communicatio 53506 UNALLOCATED 8.17.102.0/23 3356 Level 3 Communicatio 46467 UNALLOCATED 8.19.192.0/24 46887 Lightower Fiber Netw 18985 UNALLOCATED 8.21.68.0/22 3356 Level 3 Communicatio 46473 UNALLOCATED 8.27.122.0/24 12180 Internap Network Ser 46473 UNALLOCATED 8.27.124.0/24 12180 Internap Network Ser 6919 UNALLOCATED 8.29.165.0/24 3356 Level 3 Communicatio 27205 UNALLOCATED 8.38.16.0/21 6461 Abovenet Communicati 15347 UNALLOCATED 8.224.147.0/24 12064 Cox Communications I 33628 UNALLOCATED 12.0.239.0/24 1239 Sprint Complete listing at http://thyme.rand.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 5.100.241.0/24 23456 32bit Transition AS 23.226.112.0/20 62788 >>UNKNOWN<< 27.100.7.0/24 56096 >>UNKNOWN<< 31.217.248.0/21 44902 COVAGE NETWORKS SASU 41.73.1.0/24 37004 >>UNKNOWN<< 41.73.10.0/24 37004 >>UNKNOWN<< 41.73.11.0/24 37004 >>UNKNOWN<< 41.73.12.0/24 37004 >>UNKNOWN<< 41.73.13.0/24 37004 >>UNKNOWN<< 41.73.15.0/24 37004 >>UNKNOWN<< Complete listing at http://thyme.rand.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:17 /9:12 /10:34 /11:94 /12:264 /13:504 /14:1007 /15:1717 /16:12934 /17:7264 /18:12390 /19:25575 /20:36070 /21:38780 /22:59524 /23:51748 /24:294809 /25:1102 /26:1137 /27:717 /28:14 /29:12 /30:7 /31:0 /32:13 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 39891 2432 2473 SaudiNet, Saudi Telecom Compa 22773 2247 3038 Cox Communications Inc. 18566 1996 2042 MegaPath Corporation 6389 1640 2797 BellSouth.net Inc. 6983 1396 1749 EarthLink, Inc. 30036 1366 1528 Mediacom Communications Corp 34984 1317 2019 TELLCOM ILETISIM HIZMETLERI A 6147 1190 1639 Telefonica del Peru S.A.A. 10620 1136 3232 Telmex Colombia S.A. 11492 1107 1188 CABLE ONE, INC. Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1487 2:681 4:93 5:1814 6:24 8:1415 11:1 12:1828 13:10 14:1262 15:17 16:2 17:43 18:22 20:48 23:1228 24:1704 27:1882 31:1585 32:38 33:2 34:4 35:3 36:117 37:1916 38:1031 39:6 40:252 41:3047 42:286 43:1279 44:25 45:636 46:2190 47:42 49:826 50:806 52:12 54:73 55:7 56:8 57:39 58:1285 59:713 60:477 61:1744 62:1328 63:1915 64:4408 65:2251 66:4064 67:2063 68:1057 69:3268 70:979 71:448 72:1975 74:2651 75:333 76:424 77:1415 78:1180 79:803 80:1340 81:1337 82:814 83:693 84:718 85:1386 86:393 87:1043 88:515 89:1834 90:151 91:5963 92:851 93:2224 94:2007 95:2140 96:430 97:353 98:1051 99:49 100:69 101:822 103:7414 104:1781 105:62 106:225 107:968 108:628 109:2053 110:1100 111:1490 112:794 113:1081 114:818 115:1263 116:1344 117:1064 118:1816 119:1438 120:439 121:1086 122:2146 123:1821 124:1507 125:1586 128:648 129:384 130:401 131:1178 132:498 133:179 134:413 135:108 136:323 137:309 138:748 139:152 140:238 141:444 142:672 143:502 144:569 145:115 146:712 147:582 148:1120 149:403 150:564 151:603 152:487 153:244 154:478 155:858 156:408 157:463 158:317 159:1006 160:380 161:660 162:1938 163:424 164:674 165:692 166:300 167:834 168:1290 169:169 170:1461 171:246 172:49 173:1538 174:714 175:695 176:1312 177:3723 178:2157 179:976 180:1950 181:1691 182:1775 183:618 184:757 185:3529 186:2679 187:1769 188:2049 189:1591 190:7724 191:998 192:8347 193:5606 194:4138 195:3647 196:1670 197:1153 198:5538 199:5516 200:6646 201:3094 202:9459 203:9126 204:4673 205:2832 206:3084 207:2944 208:3965 209:3963 210:3520 211:1849 212:2565 213:2340 214:862 215:73 216:5668 217:1825 218:697 219:461 220:1428 221:785 222:476 223:692 End of report From bz_siege_01 at hotmail.com Fri May 22 20:34:35 2015 From: bz_siege_01 at hotmail.com (c b) Date: Fri, 22 May 2015 13:34:35 -0700 Subject: looking for feedback from someone who has worked with SiFY in India Message-ID: All, looking for feedback from someone who has worked with SiFY in India as a customer, as a carrier providing services, or just someone who has personal knowledge about them in general. Probably better if we kept this off the board, so please respond directly. Thanks! From cidr-report at potaroo.net Fri May 22 22:00:00 2015 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 22 May 2015 22:00:00 GMT Subject: The Cidr Report Message-ID: <201505222200.t4MM00O5065229@wattle.apnic.net> This report has been generated at Fri May 22 21:14:36 2015 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/2.0 for a current version of this report. Recent Table History Date Prefixes CIDR Agg 15-05-15 551181 304068 16-05-15 551739 303879 17-05-15 551760 304013 18-05-15 551574 304522 19-05-15 554843 304322 20-05-15 554856 304927 21-05-15 554582 306010 22-05-15 554435 306370 AS Summary 50689 Number of ASes in routing system 20209 Number of ASes announcing only one prefix 3232 Largest number of prefixes announced by an AS AS10620: Telmex Colombia S.A.,CO 120829440 Largest address span announced by an AS (/32s) AS4134 : CHINANET-BACKBONE No.31,Jin-rong Street,CN 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'). --- 22May15 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 554719 306449 248270 44.8% All ASes AS22773 3039 170 2869 94.4% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc.,US AS17974 2770 81 2689 97.1% TELKOMNET-AS2-AP PT Telekomunikasi Indonesia,ID AS9394 2991 324 2667 89.2% CTTNET China TieTong Telecommunications Corporation,CN AS39891 2472 27 2445 98.9% ALJAWWALSTC-AS Saudi Telecom Company JSC,SA AS6389 2797 525 2272 81.2% BELLSOUTH-NET-BLK - BellSouth.net Inc.,US AS28573 2266 296 1970 86.9% NET Servi?os de Comunica??o S.A.,BR AS3356 2574 684 1890 73.4% LEVEL3 - Level 3 Communications, Inc.,US AS4766 2926 1337 1589 54.3% KIXS-AS-KR Korea Telecom,KR AS9808 1572 67 1505 95.7% CMNET-GD Guangdong Mobile Communication Co.Ltd.,CN AS6983 1748 248 1500 85.8% ITCDELTA - Earthlink, Inc.,US AS7545 2645 1172 1473 55.7% TPG-INTERNET-AP TPG Telecom Limited,AU AS20115 1881 486 1395 74.2% CHARTER-NET-HKY-NC - Charter Communications,US AS10620 3232 1855 1377 42.6% Telmex Colombia S.A.,CO AS7303 1662 293 1369 82.4% Telecom Argentina S.A.,AR AS6147 1639 283 1356 82.7% Telefonica del Peru S.A.A.,PE AS4755 2019 694 1325 65.6% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP,IN AS9498 1329 115 1214 91.3% BBIL-AP BHARTI Airtel Ltd.,IN AS4323 1618 412 1206 74.5% TWTC - tw telecom holdings, inc.,US AS18566 2042 891 1151 56.4% MEGAPATH5-US - MegaPath Corporation,US AS7552 1163 57 1106 95.1% VIETEL-AS-AP Viettel Corporation,VN AS8402 1030 26 1004 97.5% CORBINA-AS OJSC "Vimpelcom",RU AS6849 1210 234 976 80.7% UKRTELNET JSC UKRTELECOM,UA AS8151 1669 693 976 58.5% Uninet S.A. de C.V.,MX AS7738 999 83 916 91.7% Telemar Norte Leste S.A.,BR AS4538 1955 1073 882 45.1% ERX-CERNET-BKB China Education and Research Network Center,CN AS26615 1059 181 878 82.9% Tim Celular S.A.,BR AS38285 979 123 856 87.4% M2TELECOMMUNICATIONS-AU M2 Telecommunications Group Ltd,AU AS18881 868 40 828 95.4% Global Village Telecom,BR AS4780 1078 267 811 75.2% SEEDNET Digital United Inc.,TW AS24560 1240 462 778 62.7% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services,IN Total 56472 13199 43273 76.6% Top 30 total Possible Bogus Routes 5.100.241.0/24 AS19957 -Reserved AS-,ZZ 23.226.112.0/20 AS62788 -Reserved AS-,ZZ 27.100.7.0/24 AS56096 31.217.248.0/21 AS44902 COV-ASN COVAGE NETWORKS SASU,FR 41.73.1.0/24 AS37004 -Reserved AS-,ZZ 41.73.10.0/24 AS37004 -Reserved AS-,ZZ 41.73.11.0/24 AS37004 -Reserved AS-,ZZ 41.73.12.0/24 AS37004 -Reserved AS-,ZZ 41.73.13.0/24 AS37004 -Reserved AS-,ZZ 41.73.15.0/24 AS37004 -Reserved AS-,ZZ 41.73.16.0/24 AS37004 -Reserved AS-,ZZ 41.73.18.0/24 AS37004 -Reserved AS-,ZZ 41.73.20.0/24 AS37004 -Reserved AS-,ZZ 41.73.21.0/24 AS37004 -Reserved AS-,ZZ 41.76.48.0/21 AS36969 MTL-AS,MW 41.78.180.0/23 AS37265 -Reserved AS-,ZZ 41.189.96.0/20 AS37000 -Reserved AS-,ZZ 41.189.127.0/24 AS37000 -Reserved AS-,ZZ 41.189.128.0/24 AS37000 -Reserved AS-,ZZ 41.191.108.0/22 AS37004 -Reserved AS-,ZZ 41.191.108.0/24 AS37004 -Reserved AS-,ZZ 41.191.109.0/24 AS37004 -Reserved AS-,ZZ 41.191.110.0/24 AS37004 -Reserved AS-,ZZ 41.191.111.0/24 AS37004 -Reserved AS-,ZZ 41.223.208.0/22 AS37000 -Reserved AS-,ZZ 41.242.152.0/22 AS37558 LITC,LY 41.242.156.0/22 AS37558 LITC,LY 45.67.78.0/24 AS38040 GLOBAL-TRANSIT-TOT-IIG-TH TOT Public Company Limited,TH 64.5.81.0/24 AS33680 -Reserved AS-,ZZ 64.5.91.0/24 AS33680 -Reserved AS-,ZZ 64.5.93.0/24 AS33680 -Reserved AS-,ZZ 64.5.94.0/24 AS33680 -Reserved AS-,ZZ 64.5.95.0/24 AS33680 -Reserved AS-,ZZ 65.75.216.0/23 AS10494 AAI - Accurate Automation, Inc.,US 65.75.217.0/24 AS10494 AAI - Accurate Automation, Inc.,US 66.78.66.0/23 AS10835 VISIONARY - Visionary Communications, Inc.,US 66.78.68.0/22 AS10835 VISIONARY - Visionary Communications, Inc.,US 66.78.76.0/23 AS10835 VISIONARY - Visionary Communications, Inc.,US 66.78.80.0/21 AS10835 VISIONARY - Visionary Communications, Inc.,US 66.78.91.0/24 AS10835 VISIONARY - Visionary Communications, Inc.,US 66.180.64.0/21 AS32558 ZEUTER - Zeuter Development Corporation,CA 66.187.240.0/20 AS14552 ACS-SOUTHEASTDATACENTER - Affiliated Computer Services, Inc.,US 66.205.224.0/19 AS16526 BIRCH-TELECOM - Birch Telecom, Inc.,US 66.251.128.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.133.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.134.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.136.0/21 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.140.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.141.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.142.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 72.19.0.0/19 AS16526 BIRCH-TELECOM - Birch Telecom, Inc.,US 74.113.200.0/23 AS46939 -Reserved AS-,ZZ 74.114.52.0/22 AS40818 -Reserved AS-,ZZ 74.114.52.0/23 AS40818 -Reserved AS-,ZZ 74.114.52.0/24 AS40818 -Reserved AS-,ZZ 74.114.53.0/24 AS40818 -Reserved AS-,ZZ 74.114.54.0/23 AS40818 -Reserved AS-,ZZ 74.114.54.0/24 AS40818 -Reserved AS-,ZZ 74.114.55.0/24 AS40818 -Reserved AS-,ZZ 74.114.184.0/22 AS19888 -Reserved AS-,ZZ 74.121.24.0/22 AS36263 FORONA - Forona Technologies, Inc.,US 74.123.136.0/21 AS53358 -Reserved AS-,ZZ 77.243.91.0/24 AS42597 -Reserved AS-,ZZ 80.78.133.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US 80.78.134.0/23 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US 80.78.134.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US 80.78.135.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US 80.250.32.0/22 AS37106 ODUA-AS,NG 83.142.48.0/24 AS13213 UK2NET-AS UK2 - Ltd,GB 83.142.49.0/24 AS13213 UK2NET-AS UK2 - Ltd,GB 91.103.8.0/24 AS42551 -Reserved AS-,ZZ 91.103.9.0/24 AS42551 -Reserved AS-,ZZ 91.103.10.0/24 AS42551 -Reserved AS-,ZZ 91.103.11.0/24 AS42551 -Reserved AS-,ZZ 91.193.60.0/22 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 91.195.66.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 91.197.36.0/22 AS43359 -Reserved AS-,ZZ 91.230.27.0/24 AS57022 -Reserved AS-,ZZ 98.143.160.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.161.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.162.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.163.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.164.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.165.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.166.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.167.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.168.0/22 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.172.0/22 AS26566 -Reserved AS-,ZZ 98.143.172.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.173.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.174.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.175.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 102.69.1.0/24 AS59749 CLEANMAT CLEANMAT EOOD,BG 103.7.120.0/22 AS4725 ODN SOFTBANK TELECOM Corp.,JP 103.10.222.0/24 AS13189 103.15.92.0/22 AS23818 JETINTERNET JETINTERNET Corporation,JP 103.19.219.0/24 AS58887 103.20.100.0/24 AS45334 AIRCEL-AS-AP Dishnet Wireless Limited,IN 103.20.101.0/24 AS45334 AIRCEL-AS-AP Dishnet Wireless Limited,IN 103.20.219.0/24 AS55795 VERBDC1-AS-AP Verb Data Centre Pty Ltd,AU 103.23.148.0/23 AS13209 103.23.148.0/24 AS13209 103.23.149.0/24 AS13209 103.26.116.0/22 AS17676 GIGAINFRA Softbank BB Corp.,JP 103.28.184.0/22 AS4686 BEKKOAME BEKKOAME INTERNET INC.,JP 103.225.116.0/22 AS23818 JETINTERNET JETINTERNET Corporation,JP 103.232.142.0/23 AS17828 TIARE-AS-PG Tiare, a business unit of Pacific Mobile Communications.,PG 103.244.112.0/22 AS23818 JETINTERNET JETINTERNET Corporation,JP 103.248.88.0/22 AS23818 JETINTERNET JETINTERNET Corporation,JP 103.248.220.0/22 AS17676 GIGAINFRA Softbank BB Corp.,JP 103.250.0.0/22 AS17676 GIGAINFRA Softbank BB Corp.,JP 103.253.164.0/23 AS13317 111.92.184.0/22 AS9797 NEXONASIAPACIFIC-AS-AP Nexon Asia Pacific P/L,AU 111.223.244.0/23 AS45572 ABS-SEASIA-TRANSIT-AS-AP Asia Broadcast Satellite Ltd.,HK 116.206.72.0/24 AS6461 ABOVENET - Abovenet Communications, Inc,US 116.206.85.0/24 AS6461 ABOVENET - Abovenet Communications, Inc,US 116.206.103.0/24 AS6461 ABOVENET - Abovenet Communications, Inc,US 117.120.56.0/21 AS4755 TATACOMM-AS TATA Communications formerly VSNL is Leading ISP,IN 142.147.62.0/24 AS3958 AIRCANADA - Air Canada,CA 154.168.28.0/23 AS29571 CITelecom-AS,CI 162.216.176.0/22 AS36114 VERSAWEB-ASN - Versaweb, LLC,US 162.222.128.0/21 AS36114 VERSAWEB-ASN - Versaweb, LLC,US 162.245.64.0/21 AS62788 -Reserved AS-,ZZ 162.248.224.0/21 AS62788 -Reserved AS-,ZZ 166.93.0.0/16 AS23537 CRITIGEN - Micro Source, Inc.,US 167.146.16.0/21 AS22527 -Reserved AS-,ZZ 167.146.26.0/23 AS22527 -Reserved AS-,ZZ 167.146.28.0/23 AS22527 -Reserved AS-,ZZ 167.146.32.0/20 AS22527 -Reserved AS-,ZZ 167.146.44.0/24 AS22527 -Reserved AS-,ZZ 167.146.48.0/22 AS22527 -Reserved AS-,ZZ 167.146.90.0/24 AS22527 -Reserved AS-,ZZ 167.146.93.0/24 AS22527 -Reserved AS-,ZZ 167.146.94.0/24 AS22527 -Reserved AS-,ZZ 167.146.100.0/24 AS22527 -Reserved AS-,ZZ 167.146.104.0/24 AS22527 -Reserved AS-,ZZ 167.146.105.0/24 AS22527 -Reserved AS-,ZZ 167.146.128.0/20 AS22527 -Reserved AS-,ZZ 167.146.137.0/24 AS22527 -Reserved AS-,ZZ 167.146.144.0/20 AS22527 -Reserved AS-,ZZ 167.146.160.0/20 AS22527 -Reserved AS-,ZZ 167.146.200.0/22 AS22527 -Reserved AS-,ZZ 167.146.204.0/24 AS22527 -Reserved AS-,ZZ 167.146.205.0/24 AS22527 -Reserved AS-,ZZ 172.85.88.0/21 AS53847 CEDEXIS - Cedexis Inc,US 172.85.96.0/24 AS46261 QUICKPACKET - QuickPacket, LLC,US 172.85.111.0/24 AS46261 QUICKPACKET - QuickPacket, LLC,US 172.102.0.0/22 AS4812 CHINANET-SH-AP China Telecom (Group),CN 173.45.192.0/20 AS62722 -Reserved AS-,ZZ 173.45.208.0/20 AS62722 -Reserved AS-,ZZ 185.17.98.0/23 AS19798 HILF-AS Hilf Telecom B.V.,NL 192.9.0.0/16 AS11479 BRM-SUN-AS - Sun Microsystems, Inc,US 192.25.10.0/24 AS5714 HPES - Hewlett-Packard Company,US 192.25.11.0/24 AS5714 HPES - Hewlett-Packard Company,US 192.25.13.0/24 AS5714 HPES - Hewlett-Packard Company,US 192.25.14.0/24 AS5714 HPES - Hewlett-Packard Company,US 192.34.152.0/21 AS10835 VISIONARY - Visionary Communications, Inc.,US 192.75.239.0/24 AS23498 CDSI - COGECODATA,CA 192.84.24.0/24 AS4323 TWTC - tw telecom holdings, inc.,US 192.101.70.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 192.101.71.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 192.101.72.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 192.124.252.0/22 AS680 DFN Verein zur Foerderung eines Deutschen Forschungsnetzes e.V.,DE 192.131.233.0/24 AS7018 ATT-INTERNET4 - AT&T Services, Inc.,US 192.149.81.0/24 AS14454 PERIMETER-ESECURITY - Perimeter eSecurity,US 192.154.32.0/19 AS81 NCREN - MCNC,US 192.154.64.0/19 AS81 NCREN - MCNC,US 192.166.32.0/20 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 192.188.208.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 192.245.195.0/24 AS7381 SUNGARDRS - SunGard Availability Services LP,US 193.9.59.0/24 AS1257 TELE2,SE 193.16.106.0/24 AS31539 -Reserved AS-,ZZ 193.16.145.0/24 AS31392 -Reserved AS-,ZZ 193.22.86.0/24 AS24751 MULTIFI-AS Jakobstadsnejdens Telefon Ab,FI 193.26.213.0/24 AS31641 BYTEL-AS Bytel Ltd,GB 193.28.14.0/24 AS34309 LINK11 Link11 GmbH,DE 193.32.23.0/24 AS2856 BT-UK-AS BT Public Internet Service,GB 193.33.6.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.33.252.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.35.101.0/24 AS57302 -Reserved AS-,ZZ 193.46.200.0/24 AS34243 WEBAGE Web Age Ltd,GB 193.56.203.0/24 AS51110 IDOMTECHNOLOGIES-AS IDOM TECHNOLOGIES,FR 193.111.229.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.149.2.0/23 AS15919 INTERHOST Servicios de Hosting en Internet S.A.,ES 193.164.152.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.176.147.0/24 AS49951 -Reserved AS-,ZZ 193.178.196.0/22 AS15657 SPEEDBONE-AS Speedbone Internet & Connectivity GmbH,DE 193.188.252.0/24 AS38968 TAGORG Abu-Ghazaleh Intellectual Property,JO 193.200.96.0/23 AS2828 XO-AS15 - XO Communications,US 193.200.244.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.201.244.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 193.201.245.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 193.201.246.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 193.202.9.0/24 AS6824 HERMES-NETWORK Hermes Telecom International Ltd,GB 193.223.103.0/24 AS8437 UTA-AS Tele2 Telecommunication GmbH,AT 193.227.109.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.227.236.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 194.6.252.0/24 AS21202 DCSNET-AS Bredband2 AB,SE 194.9.8.0/23 AS2863 SPRITELINK Centor AB,SE 194.9.8.0/24 AS2863 SPRITELINK Centor AB,SE 194.39.78.0/23 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 194.49.17.0/24 AS13135 CREW-AS Wieske's Crew GmbH,DE 194.50.8.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 194.60.88.0/21 AS5089 NTL Virgin Media Limited,GB 194.61.147.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 194.61.150.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 194.61.151.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 194.63.152.0/22 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 194.76.224.0/24 AS34701 WITZENMANN-AS Witzenmann GmbH, Pforzheim,DE 194.76.225.0/24 AS34701 WITZENMANN-AS Witzenmann GmbH, Pforzheim,DE 194.88.6.0/24 AS35093 RO-HTPASSPORT High Tech Passport Ltd SUA California San Jose SUCURSALA BUCURESTI ROMANIA,RO 194.88.226.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 194.99.67.0/24 AS9083 CARPENET carpeNet Information Technologies GmbH,DE 194.126.152.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 194.126.219.0/24 AS34545 -Reserved AS-,ZZ 194.126.233.0/24 AS31235 SKIWEBCENTER-AS SKIWEBCENTER SARL,FR 194.180.25.0/24 AS21358 ATOS-ORIGIN-DE-AS Atos Information Technology GmbH,DE 194.187.24.0/22 AS8856 UKRNET UkrNet Ltd,UA 195.8.48.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.8.48.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.42.232.0/22 AS15657 SPEEDBONE-AS Speedbone Internet & Connectivity GmbH,DE 195.85.194.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.85.201.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.110.0.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.128.240.0/23 AS21202 DCSNET-AS Bredband2 AB,SE 195.149.119.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.189.174.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.216.234.0/24 AS31309 NMV-AS New Media Ventures BVBA,BE 195.234.156.0/24 AS25028 -Reserved AS-,ZZ 195.242.182.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.244.18.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 196.3.182.0/24 AS37004 -Reserved AS-,ZZ 196.3.183.0/24 AS37004 -Reserved AS-,ZZ 196.22.8.0/24 AS27822 Emerging Markets Communications de Argentina S.R.L,AR 196.22.11.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US 198.22.195.0/24 AS54583 -Reserved AS-,ZZ 198.23.26.0/24 AS33052 VZUNET - Verizon Data Services LLC,US 198.73.226.0/23 AS62839 -Reserved AS-,ZZ 198.74.11.0/24 AS14573 KEYSPANENERGY-NE1 - Keyspan Energy,US 198.74.13.0/24 AS14573 KEYSPANENERGY-NE1 - Keyspan Energy,US 198.74.38.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services,US 198.74.39.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services,US 198.74.40.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services,US 198.97.72.0/21 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 198.97.96.0/19 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 198.97.240.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 198.163.214.0/24 AS21804 ACCESS-SK - Access Communications Co-operative Limited,CA 198.168.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 199.30.132.0/22 AS26003 -Reserved AS-,ZZ 199.38.248.0/24 AS13951 CENTER-SEVEN - C7 Data Centers, Inc.,US 199.38.249.0/24 AS13951 CENTER-SEVEN - C7 Data Centers, Inc.,US 199.38.250.0/24 AS13951 CENTER-SEVEN - C7 Data Centers, Inc.,US 199.38.251.0/24 AS13951 CENTER-SEVEN - C7 Data Centers, Inc.,US 199.38.252.0/22 AS13951 CENTER-SEVEN - C7 Data Centers, Inc.,US 199.66.15.0/24 AS30169 -Reserved AS-,ZZ 199.85.9.0/24 AS852 ASN852 - TELUS Communications Inc.,CA 199.88.52.0/22 AS17018 QTS-SACRAMENTO-1 - Quality Investment Properties Sacramento, LLC,US 199.102.240.0/24 AS18508 -Reserved AS-,ZZ 199.116.200.0/21 AS22830 -Reserved AS-,ZZ 199.121.0.0/16 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 199.123.16.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 199.233.87.0/24 AS33058 PEGASYSTEMS - Pegasystems Inc.,US 200.6.87.0/24 AS27947 Telconet S.A,EC 200.58.248.0/21 AS27849 200.81.48.0/24 AS11664 Techtel LMDS Comunicaciones Interactivas S.A.,AR 200.81.49.0/24 AS11664 Techtel LMDS Comunicaciones Interactivas S.A.,AR 202.3.75.0/24 AS18172 202.3.76.0/24 AS18172 202.8.106.0/24 AS9530 SHINSEGAE-AS SHINSEGAE I&C Co., Ltd.,KR 202.45.10.0/23 AS24327 202.45.10.0/24 AS24327 202.45.11.0/24 AS24327 202.53.138.0/24 AS4058 CITICTEL-CPC-AS4058 CITIC Telecom International CPC Limited,HK 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network,CN 202.122.134.0/24 AS38615 202.140.147.0/24 AS9583 SIFY-AS-IN Sify Limited,IN 202.158.251.0/24 AS9255 CONNECTPLUS-AS Singapore Telecom,SG 202.165.124.0/24 AS23749 GLOBAL-TRANSIT-AS-HKCOLO-AP HKCOLO ltd. Internet Service Provider,HK 202.179.134.0/24 AS23966 LDN-AS-PK LINKdotNET Telecom Limited,PK 203.142.219.0/24 AS45149 203.175.11.0/24 AS9229 SPEEDCAST-AP SPEEDCAST Limited,HK 203.189.116.0/22 AS45606 203.189.116.0/24 AS45606 203.189.117.0/24 AS45606 203.189.118.0/24 AS45606 203.189.119.0/24 AS45606 204.10.88.0/21 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 204.15.208.0/22 AS13706 COMPLETEWEBNET - CompleteWeb.Net LLC,US 204.16.96.0/24 AS19972 -Reserved AS-,ZZ 204.16.97.0/24 AS19972 -Reserved AS-,ZZ 204.16.98.0/24 AS19972 -Reserved AS-,ZZ 204.16.99.0/24 AS19972 -Reserved AS-,ZZ 204.69.139.0/24 AS40250 -Reserved AS-,ZZ 204.69.144.0/24 AS27283 RJF-INTERNET - Raymond James Financial, Inc.,US 204.86.196.0/23 AS14372 -Reserved AS-,ZZ 204.86.198.0/23 AS33058 PEGASYSTEMS - Pegasystems Inc.,US 204.87.251.0/24 AS22217 -Reserved AS-,ZZ 204.106.16.0/24 AS4323 TWTC - tw telecom holdings, inc.,US 204.187.11.0/24 AS51113 ELEKTA-AS Elekta,GB 204.235.245.0/24 AS22613 -Reserved AS-,ZZ 205.137.240.0/20 AS11686 ENA - Education Networks of America,US 205.159.44.0/24 AS40157 ADESA-CORP-AS - ADESA Corp,US 205.166.231.0/24 AS7029 WINDSTREAM - Windstream Communications Inc,US 205.211.160.0/24 AS30045 UHN-ASN - University Health Network,CA 206.197.184.0/24 AS23304 DATOTEL-STL-AS - Datotel LLC, a NetLabs LLC Company,US 207.2.120.0/21 AS6221 USCYBERSITES - US Cybersites, Inc,US 207.174.131.0/24 AS26116 INDRA - Indra's Net Inc,US 207.174.132.0/23 AS26116 INDRA - Indra's Net Inc,US 207.174.152.0/23 AS26116 INDRA - Indra's Net Inc,US 207.174.154.0/24 AS26116 INDRA - Indra's Net Inc,US 207.174.155.0/24 AS26116 INDRA - Indra's Net Inc,US 207.174.200.0/24 AS22658 EARTHNET - Earthnet, Inc.,US 207.231.96.0/19 AS11194 NUNETPA - NuNet Inc.,US 207.254.128.0/21 AS30689 FLOW-NET - FLOW,JM 207.254.136.0/21 AS30689 FLOW-NET - FLOW,JM 208.66.64.0/24 AS16936 -Reserved AS-,ZZ 208.66.65.0/24 AS16936 -Reserved AS-,ZZ 208.66.66.0/24 AS16936 -Reserved AS-,ZZ 208.66.67.0/24 AS16936 -Reserved AS-,ZZ 208.67.132.0/22 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 208.73.40.0/22 AS19901 -Reserved AS-,ZZ 208.73.41.0/24 AS19901 -Reserved AS-,ZZ 208.75.152.0/21 AS32146 -Reserved AS-,ZZ 208.76.20.0/24 AS31812 -Reserved AS-,ZZ 208.76.21.0/24 AS31812 -Reserved AS-,ZZ 208.77.164.0/24 AS22659 -Reserved AS-,ZZ 208.77.166.0/24 AS4323 TWTC - tw telecom holdings, inc.,US 208.80.224.0/24 AS33680 -Reserved AS-,ZZ 208.80.228.0/24 AS33680 -Reserved AS-,ZZ 208.83.53.0/24 AS40569 YGOMI-AS - Ygomi LLC,US 208.84.232.0/24 AS33131 -Reserved AS-,ZZ 208.84.233.0/24 AS33131 -Reserved AS-,ZZ 208.84.234.0/24 AS33131 -Reserved AS-,ZZ 208.84.237.0/24 AS33131 -Reserved AS-,ZZ 208.85.137.0/24 AS33680 -Reserved AS-,ZZ 208.85.139.0/24 AS33680 -Reserved AS-,ZZ 208.93.216.0/22 AS209 CENTURYLINK-US-LEGACY-QWEST - Qwest Communications Company, LLC,US 208.94.216.0/23 AS13629 -Reserved AS-,ZZ 208.94.219.0/24 AS13629 -Reserved AS-,ZZ 208.94.221.0/24 AS13629 -Reserved AS-,ZZ 208.94.223.0/24 AS13629 -Reserved AS-,ZZ 209.135.171.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 209.135.175.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 209.177.64.0/20 AS6461 ABOVENET - Abovenet Communications, Inc,US 209.193.112.0/20 AS209 CENTURYLINK-US-LEGACY-QWEST - Qwest Communications Company, LLC,US 209.209.51.0/24 AS18687 MPOWER-2 - MPOWER COMMUNICATIONS CORP.,US 209.234.112.0/23 AS32252 -Reserved AS-,ZZ 209.234.114.0/23 AS32252 -Reserved AS-,ZZ 209.234.116.0/24 AS32252 -Reserved AS-,ZZ 209.234.117.0/24 AS32252 -Reserved AS-,ZZ 209.234.118.0/24 AS32252 -Reserved AS-,ZZ 209.234.119.0/24 AS32252 -Reserved AS-,ZZ 209.234.120.0/24 AS32252 -Reserved AS-,ZZ 209.234.121.0/24 AS32252 -Reserved AS-,ZZ 209.234.122.0/24 AS32252 -Reserved AS-,ZZ 213.255.128.0/20 AS24863 LINKdotNET-AS,EG 213.255.144.0/20 AS24863 LINKdotNET-AS,EG 216.73.81.0/24 AS6432 DOUBLECLICK - Double Click, Inc.,US 216.73.82.0/24 AS6432 DOUBLECLICK - Double Click, Inc.,US 216.73.85.0/24 AS6432 DOUBLECLICK - Double Click, Inc.,US 216.73.88.0/24 AS6432 DOUBLECLICK - Double Click, Inc.,US 216.73.89.0/24 AS6432 DOUBLECLICK - Double Click, Inc.,US 216.73.94.0/24 AS6432 DOUBLECLICK - Double Click, Inc.,US 216.73.95.0/24 AS6432 DOUBLECLICK - Double Click, Inc.,US 216.146.0.0/19 AS11915 US-TELEPACIFIC - TelePacific Communications,US 216.152.24.0/22 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc.,US 216.152.208.0/22 AS33680 -Reserved AS-,ZZ 216.152.213.0/24 AS33680 -Reserved AS-,ZZ 216.152.216.0/24 AS33680 -Reserved AS-,ZZ 216.152.222.0/23 AS33680 -Reserved AS-,ZZ 216.170.96.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc.,US 216.170.101.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc.,US 216.170.104.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc.,US 216.170.105.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc.,US 216.234.132.0/24 AS14545 ADR-DRIVING-RECORDS - AMERICAN DRIVING RECORDS, INC.,US 216.238.192.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 216.238.193.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 216.238.194.0/24 AS26566 -Reserved AS-,ZZ 216.238.196.0/22 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 216.251.50.0/24 AS38191 INFOSYS-AS Infosys Technologies Ltd,IN 216.251.53.0/24 AS38191 INFOSYS-AS Infosys Technologies Ltd,IN 216.251.62.0/24 AS38191 INFOSYS-AS Infosys Technologies Ltd,IN Please see http://www.cidr-report.org for the full report ------------------------------------ Copies of this report are mailed to: nanog at nanog.org 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 22:00:01 2015 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 22 May 2015 22:00:01 GMT Subject: BGP Update Report Message-ID: <201505222200.t4MM01Lu065246@wattle.apnic.net> BGP Update Report Interval: 14-May-15 -to- 21-May-15 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS23752 264617 4.9% 2281.2 -- NPTELECOM-NP-AS Nepal Telecommunications Corporation, Internet Services,NP 2 - AS9829 249115 4.6% 161.7 -- BSNL-NIB National Internet Backbone,IN 3 - AS22059 127476 2.3% 21246.0 -- APVIO-1 - Apvio, Inc.,US 4 - AS7552 108170 2.0% 128.5 -- VIETEL-AS-AP Viettel Corporation,VN 5 - AS36947 82409 1.5% 832.4 -- ALGTEL-AS,DZ 6 - AS54169 68971 1.3% 22990.3 -- MGH-ION-1 - Marin General Hospital,US 7 - AS3709 67062 1.2% 2483.8 -- NET-CITY-SA - City of San Antonio,US 8 - AS1502 66840 1.2% 420.4 -- DNIC-ASBLK-01500-01502 - Headquarters, USAISC,US 9 - AS26821 62691 1.1% 6269.1 -- REVNET - Revelation Networks, Inc.,US 10 - AS3816 62162 1.1% 74.5 -- COLOMBIA TELECOMUNICACIONES S.A. ESP,CO 11 - AS9198 39098 0.7% 48.6 -- KAZTELECOM-AS JSC Kazakhtelecom,KZ 12 - AS45899 38271 0.7% 53.1 -- VNPT-AS-VN VNPT Corp,VN 13 - AS46844 31884 0.6% 91.4 -- ST-BGP - Sharktech,US 14 - AS25563 29254 0.5% 7313.5 -- WEBLAND-AS Webland AG, Autonomous System,CH 15 - AS8402 28592 0.5% 72.4 -- CORBINA-AS OJSC "Vimpelcom",RU 16 - AS29049 26094 0.5% 103.5 -- DELTA-TELECOM-AS Delta Telecom Ltd,AZ 17 - AS33363 25522 0.5% 139.5 -- BHN-TAMPA - BRIGHT HOUSE NETWORKS, LLC,US 18 - AS23693 25341 0.5% 324.9 -- TELKOMSEL-ASN-ID PT. Telekomunikasi Selular,ID 19 - AS31148 23225 0.4% 25.2 -- FREENET-AS Freenet Ltd.,UA 20 - AS14709 22803 0.4% 1425.2 -- Telefonica Moviles Panama S.A.,PA TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS54169 68971 1.3% 22990.3 -- MGH-ION-1 - Marin General Hospital,US 2 - AS22059 127476 2.3% 21246.0 -- APVIO-1 - Apvio, Inc.,US 3 - AS197914 16417 0.3% 16417.0 -- STOCKHO-AS Stockho Hosting SARL,FR 4 - AS18135 12750 0.2% 12750.0 -- BTV BTV Cable television,JP 5 - AS393588 9725 0.2% 9725.0 -- MUBEA-FLO - Mubea,US 6 - AS200830 9475 0.2% 9475.0 -- HMM-DC-AS LLC Home Me MC,RU 7 - AS47680 8652 0.2% 8652.0 -- NHCS EOBO Limited,IE 8 - AS25563 29254 0.5% 7313.5 -- WEBLAND-AS Webland AG, Autonomous System,CH 9 - AS26821 62691 1.1% 6269.1 -- REVNET - Revelation Networks, Inc.,US 10 - AS1757 11133 0.2% 5566.5 -- LEXIS-AS - LexisNexis,US 11 - AS31357 10255 0.2% 5127.5 -- TOMICA-AS Tomsk Information and Consulting Agency,RU 12 - AS57120 4562 0.1% 4562.0 -- TMK-AS JSC "TMK",RU 13 - AS202195 4547 0.1% 4547.0 -- ASTEKOSTMN West Siberian Regional Center of Telecommunications Tekos-Tyumen Ltd.,RU 14 - AS48195 3312 0.1% 3312.0 -- BRIZ-AS Blokhin Evgeniy Aleksandrovich,UA 15 - AS33440 13059 0.2% 3264.8 -- WEBRULON-NETWORK - webRulon, LLC,US 16 - AS36913 14868 0.3% 2973.6 -- BROADBAND-MALAWI,MW 17 - AS13483 10813 0.2% 2703.2 -- INFOR-AS13483 - INFOR GLOBAL SOLUTIONS (MICHIGAN), INC.,US 18 - AS2109 8085 0.1% 2695.0 -- TDC TDC A/S,DK 19 - AS317 18235 0.3% 2605.0 -- DNIC-ASBLK-00306-00371 - DoD Network Information Center,US 20 - AS3709 67062 1.2% 2483.8 -- NET-CITY-SA - City of San Antonio,US TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 202.70.88.0/21 131561 2.3% AS23752 -- NPTELECOM-NP-AS Nepal Telecommunications Corporation, Internet Services,NP 2 - 202.70.64.0/21 131192 2.3% AS23752 -- NPTELECOM-NP-AS Nepal Telecommunications Corporation, Internet Services,NP 3 - 105.96.0.0/22 78915 1.4% AS36947 -- ALGTEL-AS,DZ 4 - 204.80.242.0/24 68956 1.2% AS54169 -- MGH-ION-1 - Marin General Hospital,US 5 - 76.191.107.0/24 63767 1.1% AS22059 -- APVIO-1 - Apvio, Inc.,US 6 - 64.34.125.0/24 63689 1.1% AS22059 -- APVIO-1 - Apvio, Inc.,US 7 - 130.0.192.0/21 16417 0.3% AS197914 -- STOCKHO-AS Stockho Hosting SARL,FR 8 - 42.83.48.0/20 12750 0.2% AS18135 -- BTV BTV Cable television,JP 9 - 198.185.16.0/24 11131 0.2% AS1757 -- LEXIS-AS - LexisNexis,US 10 - 78.140.0.0/18 10177 0.2% AS31357 -- TOMICA-AS Tomsk Information and Consulting Agency,RU 11 - 92.43.216.0/21 9961 0.2% AS25563 -- WEBLAND-AS Webland AG, Autonomous System,CH 12 - 192.58.232.0/24 9854 0.2% AS6629 -- NOAA-AS - NOAA,US 13 - 192.58.137.0/24 9725 0.2% AS393588 -- MUBEA-FLO - Mubea,US 14 - 185.84.192.0/22 9703 0.2% AS25563 -- WEBLAND-AS Webland AG, Autonomous System,CH 15 - 178.174.96.0/19 9589 0.2% AS25563 -- WEBLAND-AS Webland AG, Autonomous System,CH 16 - 195.151.230.0/24 9475 0.2% AS200830 -- HMM-DC-AS LLC Home Me MC,RU 17 - 207.246.202.0/24 8986 0.2% AS26821 -- REVNET - Revelation Networks, Inc.,US 18 - 207.246.193.0/24 8970 0.2% AS26821 -- REVNET - Revelation Networks, Inc.,US 19 - 207.246.194.0/24 8969 0.2% AS26821 -- REVNET - Revelation Networks, Inc.,US 20 - 207.246.203.0/24 8962 0.2% AS26821 -- REVNET - Revelation Networks, Inc.,US Details at http://bgpupdates.potaroo.net ------------------------------------ Copies of this report are mailed to: nanog at nanog.org eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From notify.sina at gmail.com Sat May 23 02:48:45 2015 From: notify.sina at gmail.com (Sina Owolabi) Date: Sat, 23 May 2015 03:48:45 +0100 Subject: Help Needed Segmenting Existing Network with Sophos UTM Cisco Catalyst switches and RHEL6 Hypervisors Message-ID: Hi! I am in a bit of a planning and implementation quandary and I'm hoping to solicit implementation assistance on an already existing network which needs to have segmentation and security. I have only remote access to the network which comprises a number of Red Hat Linux 6-based hypervisor servers (hosting a multiplicity of virtual machines in different networks), a Sophos UTM gateway device (specifically ASG220) serving as a router, and two Cisco Catalyst 2960 switches (one on the internet side of the UTM gateway, and the other allowing access to the UTM from the RHEL6 hypervisors). There are a number of subnets defined on both the hypervisors and the virtual machines, all using the Sophos UTM as their gateway to each other, and to the internet. My task is to properly segregate access and traffic between the devices, which do not have VLANs defined on them. Remotely. My question is, can I create VLANs, and their trunk ports on the 2960 switches (especially on the LAN switch) that will segregate traffic between the networks defined on the UTM, the hypervisors and their guest machines, without causing network downtime? Is it best to attack the switches first, creating the VLANs there, before implementing VLANs on the UTM and the hypervisors? I would be grateful for any planning assistance. The data center is a long way away, and any downtime will be catastrophic. Thanks in advance! From olushile at gmail.com Sat May 23 05:57:36 2015 From: olushile at gmail.com (olushile akintade) Date: Sat, 23 May 2015 05:57:36 +0000 Subject: Help Needed Segmenting Existing Network with Sophos UTM Cisco Catalyst switches and RHEL6 Hypervisors In-Reply-To: References: Message-ID: Can you provide a quick diagram with the current subnet and traffic path? On Fri, May 22, 2015 at 7:51 PM Sina Owolabi wrote: > Hi! > > > I am in a bit of a planning and implementation quandary and I'm hoping > to solicit implementation assistance on an already existing network > which needs to have segmentation and security. > > I have only remote access to the network which comprises a number of > Red Hat Linux 6-based hypervisor servers (hosting a multiplicity of > virtual machines in different networks), a Sophos UTM gateway device > (specifically ASG220) serving as a router, and two Cisco Catalyst 2960 > switches (one on the internet side of the UTM gateway, and the other > allowing access to the UTM from the RHEL6 hypervisors). > > > There are a number of subnets defined on both the hypervisors and the > virtual machines, all using the Sophos UTM as their gateway to each > other, and to the internet. My task is to properly segregate access > and traffic between the devices, which do not have VLANs defined on > them. Remotely. > > My question is, can I create VLANs, and their trunk ports on the 2960 > switches (especially on the LAN switch) that will segregate traffic > between the networks defined on the UTM, the hypervisors and their > guest machines, without causing network downtime? > > Is it best to attack the switches first, creating the VLANs there, > before implementing VLANs on the UTM and the hypervisors? > > I would be grateful for any planning assistance. The data center is a > long way away, and any downtime will be catastrophic. > > > Thanks in advance! > From ramy.ihashish at gmail.com Sat May 23 12:56:08 2015 From: ramy.ihashish at gmail.com (Ramy Hashish) Date: Sat, 23 May 2015 14:56:08 +0200 Subject: [SECURITY] Application layer attacks/DDoS attacks Message-ID: Hello there, As a reaction to the increasing demand -from enterprises- over the DDoS protection services, a fierce competition between vendors is about to start in this playground, big upfront investments started to happen in the tier one, tier two and tier three ISPs, IMHO this will have its aggressive effect on the volume of the DDoS attacks, and will eventually steer the mindset of the enterprises towards hosting the most critical applications/services in a well geographically-dispersed cloud and increasing the surface area using anycast then relatively decreasing the attack volume. Back to the DDoS protection, most anti-DDoS vendors are marketing their products as application layer attack DDoS defense, I am little bit confused; aren't the application firewalls" -either integrated in a "NGFW or a UTM"- the responsible for mitigating application layer attacks? Thanks, Ramy From deleskie at gmail.com Sat May 23 14:32:55 2015 From: deleskie at gmail.com (jim deleskie) Date: Sat, 23 May 2015 11:32:55 -0300 Subject: [SECURITY] Application layer attacks/DDoS attacks In-Reply-To: References: Message-ID: To many pieces to answer on a weekend on NANOG, but those of us that work in the DDoS space the last number of years have seen huge growth in the application layer attacks. This does not mean a decrease in volumetric attack, just that now you have to worry about both and lots of each. FW's while they have got better are still not the solution for many reasons. Moving things to the "cloud" helps in come cases but not all. This is an arms race, the better we protecting the better the "bad guys" get at attacking. -jim On Sat, May 23, 2015 at 9:56 AM, Ramy Hashish wrote: > Hello there, > > As a reaction to the increasing demand -from enterprises- over the DDoS > protection services, a fierce competition between vendors is about to start > in this playground, big upfront investments started to happen in the tier > one, tier two and tier three ISPs, IMHO this will have its aggressive > effect on the volume of the DDoS attacks, and will eventually steer the > mindset of the enterprises towards hosting the most critical > applications/services in a well geographically-dispersed cloud and > increasing the surface area using anycast then relatively decreasing the > attack volume. > > Back to the DDoS protection, most anti-DDoS vendors are marketing their > products as application layer attack DDoS defense, I am little bit > confused; aren't the application firewalls" -either integrated in a "NGFW > or a UTM"- the responsible for mitigating application layer attacks? > > Thanks, > > Ramy > From rdobbins at arbor.net Sat May 23 16:08:27 2015 From: rdobbins at arbor.net (Roland Dobbins) Date: Sat, 23 May 2015 23:08:27 +0700 Subject: [SECURITY] Application layer attacks/DDoS attacks In-Reply-To: References: Message-ID: <8D47AB27-71D6-4AA4-AA8D-34D3F66DCE9B@arbor.net> On 23 May 2015, at 19:56, Ramy Hashish wrote: > I am little bit confused; aren't the application firewalls" -either > integrated in a "NGFW or a UTM"- the responsible for mitigating > application layer attacks? ----------------------------------- Roland Dobbins From jra at baylink.com Sat May 23 17:23:29 2015 From: jra at baylink.com (Jay Ashworth) Date: Sat, 23 May 2015 13:23:29 -0400 (EDT) Subject: Peering and Network Cost In-Reply-To: Message-ID: <29167805.16.1432401809635.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Dave Taht" > Two things I am curious about are 1) What is the measured benefit of > moving a netflix server into your local ISP network > > and 2) does anyone measure "cross town latency". If we lived in a > world where skype/voip/etc transited the local town only, > what sort of latencies would be see within an ISP and within a > cross-connect from, say a gfiber to a comcast? > > Once upon a time I'd heard that most phone calls were within 6 miles > of the person's home, but I don't remember the breakdown of those call > percentages (?), and certainly the old-style phone system was > achieving very low latencies for those kinds of traffic. The lack of decent geographic locality of reference on the Internet has bothered me for some time; it's often presented as an *effect* of the eyeballs/servers nature of the net, but I'm not at all sure it's not more a cause of it -- at least at this late date. The problem, of course, is that carriers make money off transit; it's not in their commercial best interest to unload those links; it's very similar to the reason my best friend's second semester pre-law textbooks cost her nearly $1000; the people selecting them have no interest in the price, since they don't pay it. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274 From notify.sina at gmail.com Sat May 23 17:36:18 2015 From: notify.sina at gmail.com (Sina Owolabi) Date: Sat, 23 May 2015 17:36:18 +0000 Subject: Help Needed Segmenting Existing Network with Sophos UTM Cisco Catalyst switches and RHEL6 Hypervisors In-Reply-To: References: Message-ID: Diagramming is a little difficult right now, but think of the current state as router-on-a-stick without VLANs, that needs to have VLANs setup. On Sat, May 23, 2015, 6:57 AM olushile akintade wrote: > Can you provide a quick diagram with the current subnet and traffic path? > On Fri, May 22, 2015 at 7:51 PM Sina Owolabi > wrote: > >> Hi! >> >> >> I am in a bit of a planning and implementation quandary and I'm hoping >> to solicit implementation assistance on an already existing network >> which needs to have segmentation and security. >> >> I have only remote access to the network which comprises a number of >> Red Hat Linux 6-based hypervisor servers (hosting a multiplicity of >> virtual machines in different networks), a Sophos UTM gateway device >> (specifically ASG220) serving as a router, and two Cisco Catalyst 2960 >> switches (one on the internet side of the UTM gateway, and the other >> allowing access to the UTM from the RHEL6 hypervisors). >> >> >> There are a number of subnets defined on both the hypervisors and the >> virtual machines, all using the Sophos UTM as their gateway to each >> other, and to the internet. My task is to properly segregate access >> and traffic between the devices, which do not have VLANs defined on >> them. Remotely. >> >> My question is, can I create VLANs, and their trunk ports on the 2960 >> switches (especially on the LAN switch) that will segregate traffic >> between the networks defined on the UTM, the hypervisors and their >> guest machines, without causing network downtime? >> >> Is it best to attack the switches first, creating the VLANs there, >> before implementing VLANs on the UTM and the hypervisors? >> >> I would be grateful for any planning assistance. The data center is a >> long way away, and any downtime will be catastrophic. >> >> >> Thanks in advance! >> > From baldur.norddahl at gmail.com Sat May 23 19:05:23 2015 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Sat, 23 May 2015 21:05:23 +0200 Subject: Help Needed Segmenting Existing Network with Sophos UTM Cisco Catalyst switches and RHEL6 Hypervisors In-Reply-To: References: Message-ID: The answer to this one is easy. Yes, there is very likely a series of steps, that will achieve what you want remotely. But... "The data center is a long way away, and any downtime will be catastrophic". The slightest misstep and you will be down until you arrive at the site. So do not even think about trying this. You go there and you do it at night, when the impact of a mistake is less. Regards, Baldur From stenn at ntp.org Sat May 23 19:47:42 2015 From: stenn at ntp.org (Harlan Stenn) Date: Sat, 23 May 2015 19:47:42 +0000 Subject: [SECURITY] Application layer attacks/DDoS attacks In-Reply-To: References: Message-ID: Just to ask, what is the expected effect on DDoS attacks if folks implemented BCP38? How does the cost of implementing BCP38 compare to the cost of other solution attempts? H From surfer at mauigateway.com Sat May 23 20:14:57 2015 From: surfer at mauigateway.com (Scott Weeks) Date: Sat, 23 May 2015 13:14:57 -0700 Subject: [SECURITY] Application layer attacks/DDoS attacks Message-ID: <20150523131457.7CE781DC@m0005297.ppops.net> --- stenn at ntp.org wrote: From: Harlan Stenn Just to ask, what is the expected effect on DDoS attacks if folks implemented BCP38? --------------------------------------- A moot point these days. After all the years it has been out (15 years: https://tools.ietf.org/html/bcp38) it can be seen that many are not implementing it. Those that care (NANOG type folks) already have deployed it and those that don't care have not and will not. I have met a lot of the latter in recent years. Maybe I'm getting cynical? scott What's going on? Isn't everybody headed to the beach or the mountains for Memorial Day weekend? ;-) From ramy.ihashish at gmail.com Sat May 23 21:33:42 2015 From: ramy.ihashish at gmail.com (Ramy Hashish) Date: Sat, 23 May 2015 23:33:42 +0200 Subject: [SECURITY] Application layer attacks/DDoS attacks In-Reply-To: References: Message-ID: Yes Harlan, you are absolutely right, even if this won't stop the botnet-based DDoS attacks, but at least will significantly decrease the volume/frequency of the volume based attacks. On the other side, the DDoS protection now become a business where all-tiers ISPs make money of, and those ISPs is the exact place where the implementation of anti-spoofing make the best sense, conflict of interests now... However, the trusted network initiative might be a good approach to start influencing operators to apply anti-spoofing mechanisms. Salam, Ramy On 23 May 2015 10:48 pm, "Harlan Stenn" wrote: Just to ask, what is the expected effect on DDoS attacks if folks implemented BCP38? How does the cost of implementing BCP38 compare to the cost of other solution attempts? H From rdobbins at arbor.net Sat May 23 23:08:30 2015 From: rdobbins at arbor.net (Roland Dobbins) Date: Sun, 24 May 2015 06:08:30 +0700 Subject: [SECURITY] Application layer attacks/DDoS attacks In-Reply-To: <20150523131457.7CE781DC@m0005297.ppops.net> References: <20150523131457.7CE781DC@m0005297.ppops.net> Message-ID: <48F06CB8-616B-4AAD-934B-5B173B759F36@arbor.net> On 24 May 2015, at 3:14, Scott Weeks wrote: > Those that care (NANOG type folks) already have deployed it and those > that don't care have not and will not. Concur 100%. ----------------------------------- Roland Dobbins From notify.sina at gmail.com Sun May 24 00:49:56 2015 From: notify.sina at gmail.com (Sina Owolabi) Date: Sun, 24 May 2015 01:49:56 +0100 Subject: Help Needed Segmenting Existing Network with Sophos UTM Cisco Catalyst switches and RHEL6 Hypervisors In-Reply-To: References: Message-ID: Thanks Baldur. I am definitely planning on doing that. Eric, no the VMs are not all segregated, they are all blended together. You can find a 192.168 sharing the same physical host as a 10.10. I've never played with OpenVSwitch before, though. Would introducing it here lead to any further complexities? On Sat, May 23, 2015 at 8:05 PM, Baldur Norddahl wrote: > The answer to this one is easy. Yes, there is very likely a series of > steps, that will achieve what you want remotely. But... > > "The data center is a long way away, and any downtime will be catastrophic". > > The slightest misstep and you will be down until you arrive at the site. So > do not even think about trying this. You go there and you do it at night, > when the impact of a mistake is less. > > Regards, > > Baldur From deleskie at gmail.com Sun May 24 01:12:35 2015 From: deleskie at gmail.com (jim deleskie) Date: Sat, 23 May 2015 22:12:35 -0300 Subject: [SECURITY] Application layer attacks/DDoS attacks In-Reply-To: References: Message-ID: While I don't think any ISP "wants DDoS" to make $$, I do based on experience believe that business cases have to be made for everything. With the prices pay for BW in most of the world now, ( or the last number of years) its going to be VERY hard to get anyone to allocated time/$$ or energy to do anything they don't need to, to get the bit to you. -jim On Sat, May 23, 2015 at 6:33 PM, Ramy Hashish wrote: > Yes Harlan, you are absolutely right, even if this won't stop the > botnet-based DDoS attacks, but at least will significantly decrease the > volume/frequency of the volume based attacks. > > On the other side, the DDoS protection now become a business where > all-tiers ISPs make money of, and those ISPs is the exact place where the > implementation of anti-spoofing make the best sense, conflict of interests > now... > > However, the trusted network initiative might be a good approach to start > influencing operators to apply anti-spoofing mechanisms. > > Salam, > > Ramy > On 23 May 2015 10:48 pm, "Harlan Stenn" wrote: > > Just to ask, what is the expected effect on DDoS attacks if folks > implemented BCP38? > > How does the cost of implementing BCP38 compare to the cost of other > solution attempts? > > H > > From morrowc.lists at gmail.com Mon May 25 03:01:50 2015 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Sun, 24 May 2015 23:01:50 -0400 Subject: [SECURITY] Application layer attacks/DDoS attacks In-Reply-To: References: Message-ID: On Sat, May 23, 2015 at 9:12 PM, jim deleskie wrote: >> However, the trusted network initiative might be a good approach to start >> influencing operators to apply anti-spoofing mechanisms. >> explain how you think the 'trusted network initiative' matters in the slightest? -chris From ramy.ihashish at gmail.com Mon May 25 04:48:41 2015 From: ramy.ihashish at gmail.com (Ramy Hashish) Date: Mon, 25 May 2015 06:48:41 +0200 Subject: [SECURITY] Application layer attacks/DDoS attacks In-Reply-To: References: Message-ID: The idea of restricting access to a certain content during an attack on the "trusted networks" only will make all interested ISPs be more "trusted" Ramy On Mon, May 25, 2015 at 5:01 AM, Christopher Morrow wrote: > On Sat, May 23, 2015 at 9:12 PM, jim deleskie wrote: > >> However, the trusted network initiative might be a good approach to > start > >> influencing operators to apply anti-spoofing mechanisms. > >> > > explain how you think the 'trusted network initiative' matters in the > slightest? > > -chris > From randy at psg.com Mon May 25 06:18:43 2015 From: randy at psg.com (Randy Bush) Date: Mon, 25 May 2015 15:18:43 +0900 Subject: [SECURITY] Application layer attacks/DDoS attacks In-Reply-To: References: Message-ID: > The idea of restricting access to a certain content during an attack > on the "trusted networks" only will make all interested ISPs be more > "trusted" don't the lawyers already have enough money? From kmedcalf at dessus.com Mon May 25 12:44:10 2015 From: kmedcalf at dessus.com (Keith Medcalf) Date: Mon, 25 May 2015 06:44:10 -0600 Subject: [SECURITY] Application layer attacks/DDoS attacks In-Reply-To: Message-ID: <457388feacb4414eb2d3bcd25ace27b5@mail.dessus.com> Without a concomitant increase in "trustworthy", assigning greater levels of trust is fools endeavour. Whatever this trusted network initiative is, I take that it was designed by fools or government (the two are usually indistinguishable) for the purpose of creating utterly untrustworthy networks. > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Ramy Hashish > Sent: Sunday, 24 May, 2015 22:49 > To: morrowc.lists at gmail.com; nanog at nanog.org > Subject: Re: [SECURITY] Application layer attacks/DDoS attacks > > The idea of restricting access to a certain content during an attack on > the > "trusted networks" only will make all interested ISPs be more "trusted" > > Ramy > > On Mon, May 25, 2015 at 5:01 AM, Christopher Morrow > > wrote: > > > On Sat, May 23, 2015 at 9:12 PM, jim deleskie > wrote: > > >> However, the trusted network initiative might be a good approach to > > start > > >> influencing operators to apply anti-spoofing mechanisms. > > >> > > > > explain how you think the 'trusted network initiative' matters in the > > slightest? > > > > -chris > > From deleskie at gmail.com Mon May 25 12:49:07 2015 From: deleskie at gmail.com (jim deleskie) Date: Mon, 25 May 2015 09:49:07 -0300 Subject: [SECURITY] Application layer attacks/DDoS attacks In-Reply-To: <457388feacb4414eb2d3bcd25ace27b5@mail.dessus.com> References: <457388feacb4414eb2d3bcd25ace27b5@mail.dessus.com> Message-ID: Keith, I agree, we can't even get everyone including some LARGE ( I'll avoid Tier's because people get stupid around that too) networks to filter customers based on assigned netblocks. -jim On Mon, May 25, 2015 at 9:44 AM, Keith Medcalf wrote: > > Without a concomitant increase in "trustworthy", assigning greater levels > of trust is fools endeavour. Whatever this trusted network initiative is, > I take that it was designed by fools or government (the two are usually > indistinguishable) for the purpose of creating utterly untrustworthy > networks. > > > -----Original Message----- > > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Ramy Hashish > > Sent: Sunday, 24 May, 2015 22:49 > > To: morrowc.lists at gmail.com; nanog at nanog.org > > Subject: Re: [SECURITY] Application layer attacks/DDoS attacks > > > > The idea of restricting access to a certain content during an attack on > > the > > "trusted networks" only will make all interested ISPs be more "trusted" > > > > Ramy > > > > On Mon, May 25, 2015 at 5:01 AM, Christopher Morrow > > > > wrote: > > > > > On Sat, May 23, 2015 at 9:12 PM, jim deleskie > > wrote: > > > >> However, the trusted network initiative might be a good approach to > > > start > > > >> influencing operators to apply anti-spoofing mechanisms. > > > >> > > > > > > explain how you think the 'trusted network initiative' matters in the > > > slightest? > > > > > > -chris > > > > > > > From rdobbins at arbor.net Mon May 25 12:53:34 2015 From: rdobbins at arbor.net (Roland Dobbins) Date: Mon, 25 May 2015 19:53:34 +0700 Subject: [SECURITY] Application layer attacks/DDoS attacks In-Reply-To: <457388feacb4414eb2d3bcd25ace27b5@mail.dessus.com> References: <457388feacb4414eb2d3bcd25ace27b5@mail.dessus.com> Message-ID: On 25 May 2015, at 19:44, Keith Medcalf wrote: > Whatever this trusted network initiative is, I take that it was > designed by fools or government (the two are usually > indistinguishable) for the purpose of creating utterly untrustworthy > networks. AFAICT, the 'Trusted Network Initiative' largely consists of 'all the cool kids should do multilateral peering at AMS-IX and NL-ix across vl112': ----------------------------------- Roland Dobbins From rdobbins at arbor.net Mon May 25 12:56:28 2015 From: rdobbins at arbor.net (Roland Dobbins) Date: Mon, 25 May 2015 19:56:28 +0700 Subject: [SECURITY] Application layer attacks/DDoS attacks In-Reply-To: References: <457388feacb4414eb2d3bcd25ace27b5@mail.dessus.com> Message-ID: <695DC4CB-C2CE-4457-BF28-A00BA37821F3@arbor.net> On 25 May 2015, at 19:49, jim deleskie wrote: > I agree, we can't even get everyone including some LARGE ( I'll avoid > Tier's because people get stupid around that too) networks to filter > customers based on assigned netblocks. Customer of my customer [of my customer, of my customer . . . ]. It's customers all the way down. ;> ----------------------------------- Roland Dobbins From angst1974 at yahoo.com Mon May 25 13:31:18 2015 From: angst1974 at yahoo.com (Steve) Date: Mon, 25 May 2015 09:31:18 -0400 Subject: [SECURITY] Application layer attacks/DDoS attacks In-Reply-To: References: Message-ID: <1A2D1AC4-A63C-4B47-AFF7-5B60D785D33A@yahoo.com> Application layer DDoS attacks , in most (all?) cases require a valid TCP/IP connection, therefore are not spoofed and BCP38 is irrelevant Sent from Steve's iPhone > On May 25, 2015, at 8:00 AM, nanog-request at nanog.org wrote: > > 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: [SECURITY] Application layer attacks/DDoS attacks > (Christopher Morrow) > 2. Re: [SECURITY] Application layer attacks/DDoS attacks > (Ramy Hashish) > 3. Re: [SECURITY] Application layer attacks/DDoS attacks (Randy Bush) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 24 May 2015 23:01:50 -0400 > From: Christopher Morrow > To: jim deleskie > Cc: Ramy Hashish , NANOG list > > Subject: Re: [SECURITY] Application layer attacks/DDoS attacks > Message-ID: > > Content-Type: text/plain; charset=UTF-8 > > On Sat, May 23, 2015 at 9:12 PM, jim deleskie wrote: >>> However, the trusted network initiative might be a good approach to start >>> influencing operators to apply anti-spoofing mechanisms. > > explain how you think the 'trusted network initiative' matters in the slightest? > > -chris > > > ------------------------------ > > Message: 2 > Date: Mon, 25 May 2015 06:48:41 +0200 > From: Ramy Hashish > To: morrowc.lists at gmail.com, nanog at nanog.org > Subject: Re: [SECURITY] Application layer attacks/DDoS attacks > Message-ID: > > Content-Type: text/plain; charset=UTF-8 > > The idea of restricting access to a certain content during an attack on the > "trusted networks" only will make all interested ISPs be more "trusted" > > Ramy > > On Mon, May 25, 2015 at 5:01 AM, Christopher Morrow > wrote: > >> On Sat, May 23, 2015 at 9:12 PM, jim deleskie wrote: >>>> However, the trusted network initiative might be a good approach to >> start >>>> influencing operators to apply anti-spoofing mechanisms. >> >> explain how you think the 'trusted network initiative' matters in the >> slightest? >> >> -chris > > > ------------------------------ > > Message: 3 > Date: Mon, 25 May 2015 15:18:43 +0900 > From: Randy Bush > To: Ramy Hashish > Cc: North American Network Operators' Group > Subject: Re: [SECURITY] Application layer attacks/DDoS attacks > Message-ID: > Content-Type: text/plain; charset=US-ASCII > >> The idea of restricting access to a certain content during an attack >> on the "trusted networks" only will make all interested ISPs be more >> "trusted" > > don't the lawyers already have enough money? > > > End of NANOG Digest, Vol 88, Issue 25 > ************************************* From rdobbins at arbor.net Mon May 25 13:34:03 2015 From: rdobbins at arbor.net (Roland Dobbins) Date: Mon, 25 May 2015 20:34:03 +0700 Subject: [SECURITY] Application layer attacks/DDoS attacks In-Reply-To: <1A2D1AC4-A63C-4B47-AFF7-5B60D785D33A@yahoo.com> References: <1A2D1AC4-A63C-4B47-AFF7-5B60D785D33A@yahoo.com> Message-ID: <01DEFCAE-BBA0-4785-AED6-A2647B55EAA3@arbor.net> On 25 May 2015, at 20:31, Steve via NANOG wrote: > Application layer DDoS attacks , in most (all?) cases require a valid > TCP/IP connection DNS query-floods are a notable exception. ----------------------------------- Roland Dobbins From joelja at bogus.com Mon May 25 16:40:30 2015 From: joelja at bogus.com (joel jaeggli) Date: Mon, 25 May 2015 09:40:30 -0700 Subject: Peering and Network Cost In-Reply-To: <29167805.16.1432401809635.JavaMail.root@benjamin.baylink.com> References: <29167805.16.1432401809635.JavaMail.root@benjamin.baylink.com> Message-ID: <5563507E.5010607@bogus.com> On 5/23/15 10:23 AM, Jay Ashworth wrote: > ----- Original Message ----- >> From: "Dave Taht" > >> Two things I am curious about are 1) What is the measured benefit of >> moving a netflix server into your local ISP network >> >> and 2) does anyone measure "cross town latency". If we lived in a >> world where skype/voip/etc transited the local town only, >> what sort of latencies would be see within an ISP and within a >> cross-connect from, say a gfiber to a comcast? >> >> Once upon a time I'd heard that most phone calls were within 6 miles >> of the person's home, but I don't remember the breakdown of those call >> percentages (?), and certainly the old-style phone system was >> achieving very low latencies for those kinds of traffic. > > The lack of decent geographic locality of reference on the Internet has > bothered me for some time; it's often presented as an *effect* of the > eyeballs/servers nature of the net, but I'm not at all sure it's not more > a cause of it -- at least at this late date. if you're using DNS based GTM to localize access to an application service or CDN it's going to be localized to the resolver being employed. short of something like: https://tools.ietf.org/html/draft-ietf-dnsop-edns-client-subnet-00 > The problem, of course, is that carriers make money off transit; it's not in > their commercial best interest to unload those links; it's very similar to > the reason my best friend's second semester pre-law textbooks cost her nearly > $1000; the people selecting them have no interest in the price, since they > don't pay it. > > Cheers, > -- jra > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 243 bytes Desc: OpenPGP digital signature URL: From randy at psg.com Mon May 25 21:27:32 2015 From: randy at psg.com (Randy Bush) Date: Tue, 26 May 2015 06:27:32 +0900 Subject: [SECURITY] Application layer attacks/DDoS attacks In-Reply-To: <01DEFCAE-BBA0-4785-AED6-A2647B55EAA3@arbor.net> References: <1A2D1AC4-A63C-4B47-AFF7-5B60D785D33A@yahoo.com> <01DEFCAE-BBA0-4785-AED6-A2647B55EAA3@arbor.net> Message-ID: >> Application layer DDoS attacks , in most (all?) cases require a valid >> TCP/IP connection > DNS query-floods are a notable exception. may i remind you of the dns query flood i had which you helped research? udp and tcp, from the same sources. randy From rdobbins at arbor.net Tue May 26 05:19:58 2015 From: rdobbins at arbor.net (Roland Dobbins) Date: Tue, 26 May 2015 12:19:58 +0700 Subject: [SECURITY] Application layer attacks/DDoS attacks In-Reply-To: References: <1A2D1AC4-A63C-4B47-AFF7-5B60D785D33A@yahoo.com> <01DEFCAE-BBA0-4785-AED6-A2647B55EAA3@arbor.net> Message-ID: <455766EE-D784-4697-A788-0C91E07BBD01@arbor.net> On 26 May 2015, at 4:27, Randy Bush wrote: > may i remind you of the dns query flood i had which you helped > research? > udp and tcp, from the same sources. Yes - we determined that the TCP-based queries were a result of RRL, which is optimized to help with spoofed reflection/amplification attacks, but isn't intended to handle non-spoofed query-floods (hence S/RTBH, flowspec, IDMS, et. al.) like the particular ANY query-flood directed at your auths. ----------------------------------- Roland Dobbins From universe at truemetal.org Tue May 26 14:26:38 2015 From: universe at truemetal.org (Markus) Date: Tue, 26 May 2015 16:26:38 +0200 Subject: gmail security is a joke Message-ID: <5564829E.1000006@truemetal.org> Did you know that anyone, anywhere in the world can get into a gmail account merely by knowing its creation date (month and year is sufficient) and the last login date (try "today")? What a joke. Try it by yourself, its "fun". Even worse, once the attacker had control of your account once, and you reset the PW and then enable 2-factor-authentication, he will always come back because it is sufficient for him to know one of the last passwords to reset it again. This will totally work around 2-factor-authentication and allows him to remove/change recovery E-Mail + phone + turn off 2FA. There's no way to get rid of him. What a mess! I have a gmail account that mostly sends mail and barely receives any. This is probably why it works so damn easy. Otherwise the PW recovery process will ask you for the E-Mail addresses of people that you have received mail from in the past. But even this can get easily guessed/researched. From saku at ytti.fi Tue May 26 15:22:46 2015 From: saku at ytti.fi (Saku Ytti) Date: Tue, 26 May 2015 18:22:46 +0300 Subject: gmail security is a joke In-Reply-To: <5564829E.1000006@truemetal.org> References: <5564829E.1000006@truemetal.org> Message-ID: <20150526152246.GA12876@pob.ytti.fi> On (2015-05-26 16:26 +0200), Markus wrote: Hey, > Did you know that anyone, anywhere in the world can get into a gmail account > merely by knowing its creation date (month and year is sufficient) and the Without any comment on what gmail is or is not doing, the topic interests me. How should recovery be done in scalable manner? Almost invariably when the accounts were initially created there is no strong authentication used, how would, even in theory, it be possible to reauthenticate strongly after password was lost? One solution is, that you can opt-out from any password recovery process, which also would mean opt-in for deletion of dormant accounts (no login for 2 years, candidate for deletion?). I personally would opt-in for this in every service I have. I recall gandi allows you to disable password recovery. Perhaps some people would trust, if they could opt-in for reauthentication via some legal entity procuring such services. Then during account creation, you'd need to go through same authentication phase, perhaps tied to nationalID or comparable. This might be reasonable, most people probably already trust one of these for much more important authentication than email, but supporting all of them globally seems like very expensive proposal. -- ++ytti From askoorb+nanog at gmail.com Tue May 26 15:32:01 2015 From: askoorb+nanog at gmail.com (Alex Brooks) Date: Tue, 26 May 2015 16:32:01 +0100 Subject: gmail security is a joke In-Reply-To: <5564829E.1000006@truemetal.org> References: <5564829E.1000006@truemetal.org> Message-ID: Hi, On Tue, May 26, 2015 at 3:26 PM, Markus wrote: > Did you know that anyone, anywhere in the world can get into a gmail account > merely by knowing its creation date (month and year is sufficient) and the > last login date (try "today")? What a joke. Can you not set account recory options which change the way password reset requests are handled. https://support.google.com/accounts/answer/183723 Gives some guidance? Alex From Thijs.Stuurman at is.nl Tue May 26 15:42:23 2015 From: Thijs.Stuurman at is.nl (Thijs Stuurman) Date: Tue, 26 May 2015 15:42:23 +0000 Subject: gmail security is a joke In-Reply-To: References: <5564829E.1000006@truemetal.org> Message-ID: Perhaps this is still a void in the market? A business which operates small officers at which you can real-world verify your personal being using the most solid evidence available (perhaps in cooperation with governments) for that location/country which works together with the sorts of big- at random-webservice to help recover information? That would remove the need for weak idea's. Either you setup and use a very solid recovery method or you present yourself (or perhaps a family member in case of (emergency/deceased/etc')). With kind regards, Thijs Stuurman Infrastructure & Solutions IS (internedservices) Group Wielingenstraat 8 | 1441 ZR Purmerend | The Netherlands T: +31(0)299476185 | M: +31(0)624366778 W: http://www.is.nl | L: http://nl.linkedin.com/in/thijsstuurman -----Oorspronkelijk bericht----- Van: NANOG [mailto:nanog-bounces at nanog.org] Namens Alex Brooks Verzonden: Tuesday, May 26, 2015 5:32 PM Aan: Markus; nanog Onderwerp: Re: gmail security is a joke Hi, On Tue, May 26, 2015 at 3:26 PM, Markus wrote: > Did you know that anyone, anywhere in the world can get into a gmail account > merely by knowing its creation date (month and year is sufficient) and the > last login date (try "today")? What a joke. Can you not set account recory options which change the way password reset requests are handled. https://support.google.com/accounts/answer/183723 Gives some guidance? Alex From owen at delong.com Tue May 26 15:44:32 2015 From: owen at delong.com (Owen DeLong) Date: Tue, 26 May 2015 17:44:32 +0200 Subject: gmail security is a joke In-Reply-To: <20150526152246.GA12876@pob.ytti.fi> References: <5564829E.1000006@truemetal.org> <20150526152246.GA12876@pob.ytti.fi> Message-ID: <312D54C4-EC72-4A3F-87FC-357AFA61D04A@delong.com> > On May 26, 2015, at 5:22 PM, Saku Ytti wrote: > > On (2015-05-26 16:26 +0200), Markus wrote: > > Hey, > >> Did you know that anyone, anywhere in the world can get into a gmail account >> merely by knowing its creation date (month and year is sufficient) and the > > Without any comment on what gmail is or is not doing, the topic interests me. > > How should recovery be done in scalable manner? Almost invariably when the > accounts were initially created there is no strong authentication used, how > would, even in theory, it be possible to reauthenticate strongly after > password was lost? I think opt-out of password recovery choices on a line-item basis is not a bad concept. For example, I?d want to opt out of recovery with account creation date. If anyone knows the date my gmail account was created, they most certainly aren?t me. OTOH, recovery by receiving a token at a previously registered alternate email address seems relatively secure to me and I wouldn?t want to opt out of that. Recovery by SMS to a previously registered phone likewise seems reasonably secure and I wouldn?t want to opt out of that, either. Recovery by SMS to a phone number provided with the recovery request I would most certainly want to disable. (yes, some sites do this). Recovery by having my password plain-text emailed to me at my alternate address (or worse, an address I supply at the time of recovery request), not so much. (yes, many sites actually do this) Really, you don?t need to strongly authenticate a particular person for these accounts. You need, instead, to authenticate that the person attempting recovery is reasonably likely to be the person who set up the account originally, whether or not they are who they claimed to be at that time. > Perhaps some people would trust, if they could opt-in for reauthentication via > some legal entity procuring such services. Then during account creation, you'd > need to go through same authentication phase, perhaps tied to nationalID or > comparable. This might be reasonable, most people probably already trust one > of these for much more important authentication than email, but supporting all > of them globally seems like very expensive proposal. This also would take away from the benefits of having some level of anonymity in the account creation process, so I think this isn?t such a great idea on multiple levels. YMMV. Owen From tknchris at gmail.com Tue May 26 15:54:12 2015 From: tknchris at gmail.com (chris) Date: Tue, 26 May 2015 11:54:12 -0400 Subject: gmail security is a joke In-Reply-To: <312D54C4-EC72-4A3F-87FC-357AFA61D04A@delong.com> References: <5564829E.1000006@truemetal.org> <20150526152246.GA12876@pob.ytti.fi> <312D54C4-EC72-4A3F-87FC-357AFA61D04A@delong.com> Message-ID: Haha I cringe when I do a password recovery at a site and they either email the current pw to me in plain text or just as bad reset it then email it in plain text. Its really sad that stuff this bad is still so common. On Tue, May 26, 2015 at 11:44 AM, Owen DeLong wrote: > > > On May 26, 2015, at 5:22 PM, Saku Ytti wrote: > > > > On (2015-05-26 16:26 +0200), Markus wrote: > > > > Hey, > > > >> Did you know that anyone, anywhere in the world can get into a gmail > account > >> merely by knowing its creation date (month and year is sufficient) and > the > > > > Without any comment on what gmail is or is not doing, the topic > interests me. > > > > How should recovery be done in scalable manner? Almost invariably when > the > > accounts were initially created there is no strong authentication used, > how > > would, even in theory, it be possible to reauthenticate strongly after > > password was lost? > > I think opt-out of password recovery choices on a line-item basis is not a > bad concept. > > For example, I?d want to opt out of recovery with account creation date. > If anyone knows > the date my gmail account was created, they most certainly aren?t me. > > OTOH, recovery by receiving a token at a previously registered alternate > email address > seems relatively secure to me and I wouldn?t want to opt out of that. > > Recovery by SMS to a previously registered phone likewise seems reasonably > secure > and I wouldn?t want to opt out of that, either. > > Recovery by SMS to a phone number provided with the recovery request I > would > most certainly want to disable. (yes, some sites do this). > > Recovery by having my password plain-text emailed to me at my alternate > address > (or worse, an address I supply at the time of recovery request), not so > much. > (yes, many sites actually do this) > > Really, you don?t need to strongly authenticate a particular person for > these accounts. > You need, instead, to authenticate that the person attempting recovery is > reasonably > likely to be the person who set up the account originally, whether or not > they are who > they claimed to be at that time. > > > Perhaps some people would trust, if they could opt-in for > reauthentication via > > some legal entity procuring such services. Then during account creation, > you'd > > need to go through same authentication phase, perhaps tied to nationalID > or > > comparable. This might be reasonable, most people probably already trust > one > > of these for much more important authentication than email, but > supporting all > > of them globally seems like very expensive proposal. > > This also would take away from the benefits of having some level of > anonymity > in the account creation process, so I think this isn?t such a great idea > on multiple > levels. > > YMMV. > > Owen > > From johnl at iecc.com Tue May 26 16:06:38 2015 From: johnl at iecc.com (John Levine) Date: 26 May 2015 16:06:38 -0000 Subject: gmail security is a joke In-Reply-To: Message-ID: <20150526160638.14758.qmail@ary.lan> In article you write: >Haha I cringe when I do a password recovery at a site and they either email >the current pw to me in plain text or just as bad reset it then email it in >plain text. Its really sad that stuff this bad is still so common. If they do a reset, what difference does it make whether they send the password in plain text or as a one-time link? Either way, if a bad guy can read the mail, he can steal the account. Given the enormous scale of Gmail, I think they do a reasonable job of account security. If you want to make your account secure with an external account or an external token (a physical one like a yubikey or a software one like the authenticator app), you can. Or if you consider your account to be low value, you can treat it that way, too. R's, John From tknchris at gmail.com Tue May 26 16:10:57 2015 From: tknchris at gmail.com (chris) Date: Tue, 26 May 2015 12:10:57 -0400 Subject: gmail security is a joke In-Reply-To: <20150526160638.14758.qmail@ary.lan> References: <20150526160638.14758.qmail@ary.lan> Message-ID: I get what you are saying but my point was more about lack of crypto or reversible crypto than stealing the account. I like what Owen is describing, they should present all account recovery options and let the user toggle on/off which ones they want to be usable this way the user can make their own decisions and live with their own choices. On Tue, May 26, 2015 at 12:06 PM, John Levine wrote: > In article < > CAKnNFz_apy8KHBXj0umGoq6UfCD640Jtxe9A+2TqU-d761-eug at mail.gmail.com> you > write: > >Haha I cringe when I do a password recovery at a site and they either > email > >the current pw to me in plain text or just as bad reset it then email it > in > >plain text. Its really sad that stuff this bad is still so common. > > If they do a reset, what difference does it make whether they send the > password in plain text or as a one-time link? Either way, if a bad > guy can read the mail, he can steal the account. > > Given the enormous scale of Gmail, I think they do a reasonable job of > account security. If you want to make your account secure with an > external account or an external token (a physical one like a yubikey > or a software one like the authenticator app), you can. > > Or if you consider your account to be low value, you can treat it that > way, too. > > R's, > John > From saku at ytti.fi Tue May 26 16:11:51 2015 From: saku at ytti.fi (Saku Ytti) Date: Tue, 26 May 2015 19:11:51 +0300 Subject: gmail security is a joke In-Reply-To: <312D54C4-EC72-4A3F-87FC-357AFA61D04A@delong.com> References: <5564829E.1000006@truemetal.org> <20150526152246.GA12876@pob.ytti.fi> <312D54C4-EC72-4A3F-87FC-357AFA61D04A@delong.com> Message-ID: <20150526161151.GA14841@pob.ytti.fi> On (2015-05-26 17:44 +0200), Owen DeLong wrote: Hey, > I think opt-out of password recovery choices on a line-item basis is not a bad concept. This sounds reasonable. At least then you could decide which balance of risk/convenience fits their use-case for given service. > OTOH, recovery by receiving a token at a previously registered alternate email address > seems relatively secure to me and I wouldn???t want to opt out of that. It's probably machine sent in seconds or minute after request, so doing short-lived BGP hijack of MX might be reasonably easy way to get the email. > Recovery by SMS to a previously registered phone likewise seems reasonably secure > and I wouldn???t want to opt out of that, either. I have tens of coworkers who could read my SMS. > Really, you don???t need to strongly authenticate a particular person for these accounts. > You need, instead, to authenticate that the person attempting recovery is reasonably > likely to be the person who set up the account originally, whether or not they are who > they claimed to be at that time. As long as user has the power to choose which risks are worth carrying, I think it's fine. For my examples, I wouldn't care about email/SMS risk if it's linkedin/twitter/facebook account. But if it's my domain hoster, I probably wouldn't want to carry either risk, as the whole deck of cards collapses if you control my domains (all email recoveries compromised) -- ++ytti From johnl at iecc.com Tue May 26 16:16:33 2015 From: johnl at iecc.com (John R. Levine) Date: 26 May 2015 12:16:33 -0400 Subject: gmail security is a joke In-Reply-To: References: <20150526160638.14758.qmail@ary.lan> Message-ID: > I get what you are saying but my point was more about lack of crypto or > reversible crypto than stealing the account. I am all in favor of using crypto when it improves security. But I am also in favor of not obsessing about it in places where it makes no difference. > I like what Owen is describing, they should present all account recovery > options and let the user toggle on/off which ones they want to be usable > this way the user can make their own decisions and live with their own > choices. Unfortunately, we have learned over and over again that the nerd instinct to push the security policy decisions onto civilians never ends well. Some people will check every box because more security is better, right? And then they're locked out and make expensive phone calls to your support desk. Others will uncheck every box because they just want to be able to log into the fripping account and it's your fault when their account is stolen. R's, John From jimpop at gmail.com Tue May 26 16:56:40 2015 From: jimpop at gmail.com (Jim Popovitch) Date: Tue, 26 May 2015 12:56:40 -0400 Subject: gmail security is a joke In-Reply-To: <5564829E.1000006@truemetal.org> References: <5564829E.1000006@truemetal.org> Message-ID: On Tue, May 26, 2015 at 10:26 AM, Markus wrote: > Did you know that anyone, anywhere in the world can get into a gmail account > merely by knowing its creation date (month and year is sufficient) and the > last login date (try "today")? What a joke. We don't even know if this email originated by Markus himself. :-) As for security, the default access for mobile devices (which require no further credentials for Mail, Web, SMS) is a swipe. I too wish the world was bulletproof from birth, but it's not. -Jim P. From Valdis.Kletnieks at vt.edu Tue May 26 18:15:07 2015 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Tue, 26 May 2015 14:15:07 -0400 Subject: gmail security is a joke In-Reply-To: Your message of "Tue, 26 May 2015 19:11:51 +0300." <20150526161151.GA14841@pob.ytti.fi> References: <5564829E.1000006@truemetal.org> <20150526152246.GA12876@pob.ytti.fi> <312D54C4-EC72-4A3F-87FC-357AFA61D04A@delong.com> <20150526161151.GA14841@pob.ytti.fi> Message-ID: <21076.1432664107@turing-police.cc.vt.edu> On Tue, 26 May 2015 19:11:51 +0300, Saku Ytti said: > > OTOH, recovery by receiving a token at a previously registered alternate email address > > seems relatively secure to me and I wouldn???t want to opt out of that. > > It's probably machine sent in seconds or minute after request, so doing > short-lived BGP hijack of MX might be reasonably easy way to get the email. To be fair, if your e-mail address is high enough value that somebody is willing to risk getting caught doing a BGP hijack, maybe you have bigger problems to worry about. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From morrowc.lists at gmail.com Tue May 26 18:23:05 2015 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Tue, 26 May 2015 14:23:05 -0400 Subject: gmail security is a joke In-Reply-To: <21076.1432664107@turing-police.cc.vt.edu> References: <5564829E.1000006@truemetal.org> <20150526152246.GA12876@pob.ytti.fi> <312D54C4-EC72-4A3F-87FC-357AFA61D04A@delong.com> <20150526161151.GA14841@pob.ytti.fi> <21076.1432664107@turing-police.cc.vt.edu> Message-ID: On Tue, May 26, 2015 at 2:15 PM, wrote: > On Tue, 26 May 2015 19:11:51 +0300, Saku Ytti said: > >> > OTOH, recovery by receiving a token at a previously registered alternate email address >> > seems relatively secure to me and I wouldn???t want to opt out of that. >> >> It's probably machine sent in seconds or minute after request, so doing >> short-lived BGP hijack of MX might be reasonably easy way to get the email. > > To be fair, if your e-mail address is high enough value that somebody is > willing to risk getting caught doing a BGP hijack, maybe you have bigger > problems to worry about. I suppose the meta of this whole conversation is for the OP: "Sure, there are issues with just about every account-recovery setup out there. Where you have X-hundreds of millions of 'not nanog' level users interacting and needing passwd recovery to work reliably and somewhat securely, how would you accomplish this?" Tossing grenades in the crowded room is cool and all, but ... you clearly have some thoughts about options/improvements/etc you might get more useful traction by proposing them. From drohan at gmail.com Tue May 26 18:40:34 2015 From: drohan at gmail.com (Daniel Rohan) Date: Tue, 26 May 2015 11:40:34 -0700 Subject: 10Gb CPE Message-ID: With the deluge of 10Gb X device recommendations, I thought I'd hit the list with one more. Does anyone out there running 10Gb managed CPE feel like sharing their experiences? Our use case would be a managed endpoint that would allow for testing and circuit verification while providing a layer 2 extension to our edge gear at the PoPs. We're hoping to find a cheap vendor-supplied solution- not homebrew. If so, which features have been important to you? Which vendors have good products? What price point? Thanks, Dan From clane1875 at gmail.com Tue May 26 19:02:19 2015 From: clane1875 at gmail.com (Chris Lane) Date: Tue, 26 May 2015 15:02:19 -0400 Subject: 10Gb CPE In-Reply-To: References: Message-ID: We use Brocade ICX 6450s for this. -Chris On Tue, May 26, 2015 at 2:40 PM, Daniel Rohan wrote: > With the deluge of 10Gb X device recommendations, I thought I'd hit the > list with one more. Does anyone out there running 10Gb managed CPE feel > like sharing their experiences? > > Our use case would be a managed endpoint that would allow for testing and > circuit verification while providing a layer 2 extension to our edge gear > at the PoPs. > > We're hoping to find a cheap vendor-supplied solution- not homebrew. > > If so, which features have been important to you? > > Which vendors have good products? > > What price point? > > > Thanks, > > Dan > -- - Chris From tony at wicks.co.nz Tue May 26 19:08:42 2015 From: tony at wicks.co.nz (Tony Wicks) Date: Wed, 27 May 2015 07:08:42 +1200 Subject: 10Gb CPE In-Reply-To: References: Message-ID: <005701d097e7$61974ed0$24c5ec70$@wicks.co.nz> I would say these are what you are after, last time I tested these I seem to remember Accedian coming out on top, but they are all good. http://www.rad.com/10/Carrier-Ethernet-Demarcation/27932/ http://accedian.com/ http://www.mrv.com/products/carrier-ethernet -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Daniel Rohan Sent: Wednesday, 27 May 2015 6:41 a.m. To: NANOG Subject: 10Gb CPE With the deluge of 10Gb X device recommendations, I thought I'd hit the list with one more. Does anyone out there running 10Gb managed CPE feel like sharing their experiences? Our use case would be a managed endpoint that would allow for testing and circuit verification while providing a layer 2 extension to our edge gear at the PoPs. We're hoping to find a cheap vendor-supplied solution- not homebrew. If so, which features have been important to you? Which vendors have good products? What price point? Thanks, Dan From johnstong at westmancom.com Tue May 26 19:19:59 2015 From: johnstong at westmancom.com (Graham Johnston) Date: Tue, 26 May 2015 19:19:59 +0000 Subject: SAS Drive Enclosure Message-ID: <49EE1A35457387418410F97564A3752B01367C8A6E@MSG6.westman.int> I am looking for information about SAS drive enclosures, is there a list like NANOG that covers that area of IT? I am specifically looking for an enclosure that can handle 12 or more drives, I am looking to create a clustered file system between multiple servers and would like to avoid a drive enclosure that only works with a very small number of approved drives. I am looking to support traditional HDDs as well as SSDs. Thanks, Graham Johnston Network Planner Westman Communications Group 204.717.2829 johnstong at westmancom.com P think green; don't print this email. From aaron at heyaaron.com Tue May 26 19:28:26 2015 From: aaron at heyaaron.com (Aaron C. de Bruyn) Date: Tue, 26 May 2015 12:28:26 -0700 Subject: gmail security is a joke In-Reply-To: <20150526160638.14758.qmail@ary.lan> References: <20150526160638.14758.qmail@ary.lan> Message-ID: On Tue, May 26, 2015 at 9:06 AM, John Levine wrote: > If they do a reset, what difference does it make whether they send the > password in plain text or as a one-time link? Either way, if a bad > guy can read the mail, he can steal the account. If they can e-mail you your existing password (*cough*Netgear*cough*), it means they are storing your credentials in the database un-encrypted. -A From johnl at iecc.com Tue May 26 19:39:22 2015 From: johnl at iecc.com (John R. Levine) Date: 26 May 2015 15:39:22 -0400 Subject: gmail security is a joke In-Reply-To: References: <20150526160638.14758.qmail@ary.lan> Message-ID: > If they can e-mail you your existing password (*cough*Netgear*cough*), > it means they are storing your credentials in the database > un-encrypted. What I had in mind was creating a new password and mailing you that. R's, John From aaron at heyaaron.com Tue May 26 19:44:28 2015 From: aaron at heyaaron.com (Aaron C. de Bruyn) Date: Tue, 26 May 2015 12:44:28 -0700 Subject: gmail security is a joke In-Reply-To: References: <20150526160638.14758.qmail@ary.lan> Message-ID: *facepalm* Right. Sorry. Forgot which group I was addressing. ;) I swear half of the United States forgot their passwords over the three-day weekend. -A On Tue, May 26, 2015 at 12:39 PM, John R. Levine wrote: >> If they can e-mail you your existing password (*cough*Netgear*cough*), >> it means they are storing your credentials in the database >> un-encrypted. > > > What I had in mind was creating a new password and mailing you that. > > R's, > John From rvandolson at esri.com Tue May 26 19:52:55 2015 From: rvandolson at esri.com (Ray Van Dolson) Date: Tue, 26 May 2015 12:52:55 -0700 Subject: SAS Drive Enclosure In-Reply-To: <49EE1A35457387418410F97564A3752B01367C8A6E@MSG6.westman.int> References: <49EE1A35457387418410F97564A3752B01367C8A6E@MSG6.westman.int> Message-ID: <20150526195255.GA14394@esri.com> On Tue, May 26, 2015 at 07:19:59PM +0000, Graham Johnston wrote: > I am looking for information about SAS drive enclosures, is there a > list like NANOG that covers that area of IT? > > I am specifically looking for an enclosure that can handle 12 or more > drives, I am looking to create a clustered file system between > multiple servers and would like to avoid a drive enclosure that only > works with a very small number of approved drives. I am looking to > support traditional HDDs as well as SSDs. There were discussions at some point about setting up a storage-centric list via SNIA or something else fairly 'neutral'. Never really materialized, however. Lists like lopsa-tech and the LISA/USENIX SAGE list are general enough you might get some good responses. WRT your question, we've had good luck with the Dell MD1200 line of JBODs. Ray From scott at doc.net.au Tue May 26 20:10:08 2015 From: scott at doc.net.au (Scott Howard) Date: Tue, 26 May 2015 13:10:08 -0700 Subject: gmail security is a joke In-Reply-To: References: <20150526160638.14758.qmail@ary.lan> Message-ID: On Tue, May 26, 2015 at 12:28 PM, Aaron C. de Bruyn wrote: > > If they can e-mail you your existing password (*cough*Netgear*cough*), > it means they are storing your credentials in the database > un-encrypted. > No, it doesn't mean that at all. It means they are storing it unhashed which is probably what you mean. It may well be that they are storing it unencrypted, but you can't outright say that without extra knowledge. Scott From Daniel.Jameson at tdstelecom.com Tue May 26 20:11:20 2015 From: Daniel.Jameson at tdstelecom.com (Jameson, Daniel) Date: Tue, 26 May 2015 20:11:20 +0000 Subject: SAS Drive Enclosure In-Reply-To: <20150526195255.GA14394@esri.com> References: <49EE1A35457387418410F97564A3752B01367C8A6E@MSG6.westman.int> <20150526195255.GA14394@esri.com> Message-ID: What are you thinking for connectivity, Ethernet, FiberChannel, Infiniband ... Building *Storage Nodes* or in need of just drive connectivity? -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Ray Van Dolson Sent: Tuesday, May 26, 2015 2:53 PM To: Graham Johnston Cc: 'nanog at nanog.org' Subject: Re: SAS Drive Enclosure On Tue, May 26, 2015 at 07:19:59PM +0000, Graham Johnston wrote: > I am looking for information about SAS drive enclosures, is there a > list like NANOG that covers that area of IT? > > I am specifically looking for an enclosure that can handle 12 or more > drives, I am looking to create a clustered file system between > multiple servers and would like to avoid a drive enclosure that only > works with a very small number of approved drives. I am looking to > support traditional HDDs as well as SSDs. There were discussions at some point about setting up a storage-centric list via SNIA or something else fairly 'neutral'. Never really materialized, however. Lists like lopsa-tech and the LISA/USENIX SAGE list are general enough you might get some good responses. WRT your question, we've had good luck with the Dell MD1200 line of JBODs. Ray From sotnickd-nanog at ddv.com Tue May 26 23:19:25 2015 From: sotnickd-nanog at ddv.com (David Sotnick) Date: Tue, 26 May 2015 16:19:25 -0700 Subject: Multiple vendors' IPv6 issues Message-ID: Hi NANOG, The company I work for has no business case for being on the IPv6-Internet. However, I am an inquisitive person and I am always looking to learn new things, so about 3 years ago I started down the IPv6 path. This was early 2012. Fast forward to today. We have a /44 presence for our company's multiple sites; All our desktop computers have been on the IPv6 Internet since June, 2012 and we have a few AAAAs in our external DNS for some key services ? and, there have been bugs. *Lots* of bugs. Now, maybe (_maybe_) I can have some sympathy for smaller network companies (like Arista Networks at the time) to not quite have their act together as far as IPv6 goes, but for larger, well-established companies to still have critical IPv6 bugs is just inexcusable! This month has just been the most disheartening time working with IPv6. Vendor 1: Aruba Networks. Upon adding an IPv6 address to start managing our WiFi controller over IPv6, I receive a call from our Telecom Lead saying that or WiFi VoIP phones have just gone offline. WHAT? All I did was add an IPv6 address to a management interface which has *nothing* to do with our VoIP system or SSID, ACLs, policies, roles, etc. Vendor 2: Palo Alto Networks: After upgrading our firewalls from a version which has a nasty bug where the IPv6 neighbor table wasn't being cleaned up properly (which would overflow the table and break IPv6), we now have a *new* IPv6 neighbor discovery bug where one of our V6-enabled DMZ hosts just falls of the IPv6 network. The only solution: clear the neighbor table on the Palo Alto or the client (linux) host. Vendor 3: Arista Networks: We are seeing a very similar ND bug with Arista. This one is slightly more interesting because it only started after upgrading our Arista EOS code ? and it only appears to affect Virtual Machines which are behind our RedHat Enterprise Virtualization cluster. None of the hundreds of VMware-connected hosts are affected. The symptom is basically the same as the Palo Alto bug. Neighbor table gets in some weird state where ND breaks and the host is unreachable until the neighbor table is cleared. Oh, and the final straw today, which is *almost* leading me to throw in the IPv6 towel completely (for now): On certain hosts (VMs), scp'ing a file over the [Arista] LAN (10 gigabit LAN) takes 5 minutes over IPv6 and <1 second over IPv4. What happened? It really saddens me that it is still not receiving anywhere near the kind of QA (partly as a result of lack of adoption) that IPv4 has. Oh, and let's not forget everybody's "favorite" vendor, Cisco. Why is it, Cisco, that I have to restart my IPv6 OSPF3 process on my ASA every time my Palo Alto firewall crashes and fails over, otherwise none of my VPN clients can connect via IPv6? Why do you hurt me so, IPv6? I just wanted to be friends, and now I just want to break up with you. Maybe we can try to be friends again when your vendors get their shit together. -David From cb.list6 at gmail.com Tue May 26 23:27:53 2015 From: cb.list6 at gmail.com (Ca By) Date: Tue, 26 May 2015 16:27:53 -0700 Subject: Multiple vendors' IPv6 issues In-Reply-To: References: Message-ID: On Tuesday, May 26, 2015, David Sotnick wrote: > Hi NANOG, > > The company I work for has no business case for being on the IPv6-Internet. > However, I am an inquisitive person and I am always looking to learn new > things, so about 3 years ago I started down the IPv6 path. This was early > 2012. > > Fast forward to today. We have a /44 presence for our company's multiple > sites; All our desktop computers have been on the IPv6 Internet since June, > 2012 and we have a few AAAAs in our external DNS for some key services ? > and, there have been bugs. *Lots* of bugs. > > Now, maybe (_maybe_) I can have some sympathy for smaller network companies > (like Arista Networks at the time) to not quite have their act together as > far as IPv6 goes, but for larger, well-established companies to still have > critical IPv6 bugs is just inexcusable! > > This month has just been the most disheartening time working with IPv6. > > Vendor 1: > > Aruba Networks. Upon adding an IPv6 address to start managing our WiFi > controller over IPv6, I receive a call from our Telecom Lead saying that or > WiFi VoIP phones have just gone offline. WHAT? All I did was add an IPv6 > address to a management interface which has *nothing* to do with our VoIP > system or SSID, ACLs, policies, roles, etc. > > Vendor 2: > > Palo Alto Networks: After upgrading our firewalls from a version which has > a nasty bug where the IPv6 neighbor table wasn't being cleaned up properly > (which would overflow the table and break IPv6), we now have a *new* IPv6 > neighbor discovery bug where one of our V6-enabled DMZ hosts just falls of > the IPv6 network. The only solution: clear the neighbor table on the Palo > Alto or the client (linux) host. > > Vendor 3: > > Arista Networks: We are seeing a very similar ND bug with Arista. This one > is slightly more interesting because it only started after upgrading our > Arista EOS code ? and it only appears to affect Virtual Machines which are > behind our RedHat Enterprise Virtualization cluster. None of the hundreds > of VMware-connected hosts are affected. The symptom is basically the same > as the Palo Alto bug. Neighbor table gets in some weird state where ND > breaks and the host is unreachable until the neighbor table is cleared. > > Oh, and the final straw today, which is *almost* leading me to throw in the > IPv6 towel completely (for now): On certain hosts (VMs), scp'ing a file > over the [Arista] LAN (10 gigabit LAN) takes 5 minutes over IPv6 and <1 > second over IPv4. What happened? > > It really saddens me that it is still not receiving anywhere near the kind > of QA (partly as a result of lack of adoption) that IPv4 has. > > Oh, and let's not forget everybody's "favorite" vendor, Cisco. Why is it, > Cisco, that I have to restart my IPv6 OSPF3 process on my ASA every time my > Palo Alto firewall crashes and fails over, otherwise none of my VPN clients > can connect via IPv6? > > Why do you hurt me so, IPv6? I just wanted to be friends, and now I just > want to break up with you. Maybe we can try to be friends again when your > vendors get their shit together. > > -David > Had ipv4 ever hurt you ? Me too. CB From marka at isc.org Wed May 27 00:36:34 2015 From: marka at isc.org (Mark Andrews) Date: Wed, 27 May 2015 10:36:34 +1000 Subject: gmail security is a joke In-Reply-To: Your message of "Tue, 26 May 2015 19:11:51 +0300." <20150526161151.GA14841@pob.ytti.fi> References: <5564829E.1000006@truemetal.org> <20150526152246.GA12876@pob.ytti.fi> <312D54C4-EC72-4A3F-87FC-357AFA61D04A@delong.com> <20150526161151.GA14841@pob.ytti.fi> Message-ID: <20150527003635.8F0E12F588AD@rock.dv.isc.org> In message <20150526161151.GA14841 at pob.ytti.fi>, Saku Ytti writes: > On (2015-05-26 17:44 +0200), Owen DeLong wrote: > > Hey, > > > I think opt-out of password recovery choices on a line-item basis is not a > bad concept. > > This sounds reasonable. At least then you could decide which balance of > risk/convenience fits their use-case for given service. > > > OTOH, recovery by receiving a token at a previously registered alternate e > > mail address > > seems relatively secure to me and I wouldn???t want to opt out of that. > > It's probably machine sent in seconds or minute after request, so doing > short-lived BGP hijack of MX might be reasonably easy way to get the email. Which is easily prevented by authenticating the MX when connecting. Something which as been recommended practice for as long as SMTP has existed. HELO provided weak authentication. We now know and documented how to do this securely on a global scale, we just need to do it. See draft-ietf-dane-smtp-with-dane. You have added the TLSA records for you MTA and signed your zones? You have updated your MTA to support DANE? [ Need to nag ops to add TLSA records for the MX's. We have them for www.isc.org. ] Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From amps at djlab.com Wed May 27 01:43:28 2015 From: amps at djlab.com (Randy) Date: Tue, 26 May 2015 18:43:28 -0700 Subject: More specifics from AS18978 [was: Prefix hijack by INDOSAT AS4795 / AS4761] In-Reply-To: <5514CDCF.2040602@kenweb.org> References: <44c3b7398b0c46b8a842c44da3f379be@APP02.start.local> <55142B81.9000305@toonk.nl> <5514CDCF.2040602@kenweb.org> Message-ID: I guess AS18978 didn't learn from their mistake. Got a slew of identical bgpmon alerts for withdrawals and more specifics within the last 30 minutes. Worse than last time. Some still active, like: update time (UTC) Update Type Probe ASn Probe Location Prefix AS path Cleared Duration 2015-03-26 12:18:41 Update AS4795 ID 198.98.180.0/23 4795 4795 4761 9304 40633 18978 4436 29889 Active On 03/26/2015 8:26 pm, ML wrote: > Wouldn't it be a BCP to set no-export from the Noction device too? > > > On 3/26/2015 6:20 PM, Nick Rose wrote: >> Several people asked me off list for more details, here is what I have >> regarding it. >> >> This morning a tier2 isp that connects to our network made an error in >> their router configuration causing the route leakage. The issue has >> been addressed and we will be performing a full post mortem to ensure >> this does not happen again. >> While investigating the issue we did find that the noction appliance >> stopped advertising the no export community string with its >> advertisements which is why certain prefixes were also seen. >> >> Regards, >> Nick Rose >> CTO @ Enzu Inc. >> >> -----Original Message----- >> From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Nick Rose >> Sent: Thursday, March 26, 2015 3:49 PM >> To: amps at djlab.com; Peter Rocca >> Cc: nanog at nanog.org >> Subject: RE: More specifics from AS18978 [was: Prefix hijack by >> INDOSAT AS4795 / AS4761] >> >> This should be resolved from AS18978. If you experience anything else >> please let me know and I will get it addressed immediately. >> >> Regards, >> Nick Rose >> CTO @ Enzu Inc. >> >> -----Original Message----- >> From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Randy >> Sent: Thursday, March 26, 2015 12:14 PM >> To: Peter Rocca >> Cc: nanog at nanog.org >> Subject: RE: More specifics from AS18978 [was: Prefix hijack by >> INDOSAT AS4795 / AS4761] >> >> On 03/26/2015 9:00 am, Peter Rocca wrote: >>> +1 >>> >>> The summary below aligns with our analysis as well. >>> >>> We've reached out to AS18978 to determine the status of the leak but >>> at this time we're not seeing any operational impact. >> +2, after the morning coffee sunk in and helpful off list replies I >> can >> finally see it's probably not INDOSAT involved at all. >> >> FYI, the more specifics are still active: >> >> 2015-03-26 13:56:11 Update AS4795 ID 198.98.180.0/23 4795 4795 4761 >> 9304 40633 18978 6939 29889 Active >> 2015-03-26 13:56:11 Update AS4795 ID 198.98.182.0/23 4795 4795 4761 >> 9304 40633 18978 6939 29889 Active >> >> -- >> ~Randy From amps at djlab.com Wed May 27 01:49:14 2015 From: amps at djlab.com (Randy) Date: Tue, 26 May 2015 18:49:14 -0700 Subject: More specifics from AS18978 [was: Prefix hijack by INDOSAT AS4795 / AS4761] In-Reply-To: <5514CDCF.2040602@kenweb.org> References: <44c3b7398b0c46b8a842c44da3f379be@APP02.start.local> <55142B81.9000305@toonk.nl> <5514CDCF.2040602@kenweb.org> Message-ID: <942c0549eff2a5cdc3fc918affb43cd9@mailbox.fastserv.com> Ignore my noise, I don't think there was new activity today (although something weird def. happened). BGPmon list was sorted by wrong column and I mixed the dates up. Although it's still showing as active since march which I thought said provider resolved... On 03/26/2015 8:26 pm, ML wrote: > Wouldn't it be a BCP to set no-export from the Noction device too? > > > On 3/26/2015 6:20 PM, Nick Rose wrote: >> Several people asked me off list for more details, here is what I have >> regarding it. >> >> This morning a tier2 isp that connects to our network made an error in >> their router configuration causing the route leakage. The issue has >> been addressed and we will be performing a full post mortem to ensure >> this does not happen again. >> While investigating the issue we did find that the noction appliance >> stopped advertising the no export community string with its >> advertisements which is why certain prefixes were also seen. >> >> Regards, >> Nick Rose >> CTO @ Enzu Inc. >> >> -----Original Message----- >> From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Nick Rose >> Sent: Thursday, March 26, 2015 3:49 PM >> To: amps at djlab.com; Peter Rocca >> Cc: nanog at nanog.org >> Subject: RE: More specifics from AS18978 [was: Prefix hijack by >> INDOSAT AS4795 / AS4761] >> >> This should be resolved from AS18978. If you experience anything else >> please let me know and I will get it addressed immediately. >> >> Regards, >> Nick Rose >> CTO @ Enzu Inc. >> >> -----Original Message----- >> From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Randy >> Sent: Thursday, March 26, 2015 12:14 PM >> To: Peter Rocca >> Cc: nanog at nanog.org >> Subject: RE: More specifics from AS18978 [was: Prefix hijack by >> INDOSAT AS4795 / AS4761] >> >> On 03/26/2015 9:00 am, Peter Rocca wrote: >>> +1 >>> >>> The summary below aligns with our analysis as well. >>> >>> We've reached out to AS18978 to determine the status of the leak but >>> at this time we're not seeing any operational impact. >> +2, after the morning coffee sunk in and helpful off list replies I >> can >> finally see it's probably not INDOSAT involved at all. >> >> FYI, the more specifics are still active: >> >> 2015-03-26 13:56:11 Update AS4795 ID 198.98.180.0/23 4795 4795 4761 >> 9304 40633 18978 6939 29889 Active >> 2015-03-26 13:56:11 Update AS4795 ID 198.98.182.0/23 4795 4795 4761 >> 9304 40633 18978 6939 29889 Active >> >> -- >> ~Randy From chk at pobox.com Wed May 27 02:39:11 2015 From: chk at pobox.com (Harald Koch) Date: Tue, 26 May 2015 22:39:11 -0400 Subject: gmail security is a joke In-Reply-To: References: <5564829E.1000006@truemetal.org> Message-ID: On 26 May 2015 at 11:32, Alex Brooks wrote: > > Can you not set account recory options which change the way password > reset requests are handled. > https://support.google.com/accounts/answer/183723 Gives some guidance? > > Alex > Unfortunately, setting these options does not disable the separate "account recovery form" listed at the bottom of the page, and it is this form that allows you to login with any previous password and to bypass 2-factor auth. I must admit I was surprised by this when I tried it just now. I guess it's time to rethink using Google as a primary account... From branto at argentiumsolutions.com Wed May 27 03:07:48 2015 From: branto at argentiumsolutions.com (Brant Ian Stevens) Date: Tue, 26 May 2015 23:07:48 -0400 Subject: 10Gb CPE In-Reply-To: References: Message-ID: <5015108B-5998-4771-84E9-D9698884E66D@argentiumsolutions.com> Any feedback on the new 7250?s yet? On 5/26/15, 3:02 PM, "NANOG on behalf of Chris Lane" wrote: >We use Brocade ICX 6450s for this. > >-Chris > >On Tue, May 26, 2015 at 2:40 PM, Daniel Rohan wrote: > >> With the deluge of 10Gb X device recommendations, I thought I'd hit the >> list with one more. Does anyone out there running 10Gb managed CPE feel >> like sharing their experiences? >> >> Our use case would be a managed endpoint that would allow for testing and >> circuit verification while providing a layer 2 extension to our edge gear >> at the PoPs. >> >> We're hoping to find a cheap vendor-supplied solution- not homebrew. >> >> If so, which features have been important to you? >> >> Which vendors have good products? >> >> What price point? >> >> >> Thanks, >> >> Dan >> > > > >-- >- Chris From shoshon at shoshon.ro Wed May 27 04:52:07 2015 From: shoshon at shoshon.ro (Bogdan) Date: Wed, 27 May 2015 07:52:07 +0300 Subject: looking glass software Message-ID: <55654D77.9070803@shoshon.ro> hello what software do you use for looking glass. for cisco ios and ios-xr? i use the old cougar/version6.net for ios, but ios-xr is not supported. i came across https://github.com/tmshlvck/ulg/ but did't installed yet. are there any other interesting lg's out there? thanks. -- Bogdan From akumar at anilkumar.com Wed May 27 03:43:47 2015 From: akumar at anilkumar.com (Anil Kumar) Date: Wed, 27 May 2015 09:13:47 +0530 Subject: gmail security is a joke In-Reply-To: References: <5564829E.1000006@truemetal.org> Message-ID: <70986901-348F-415A-92B9-40997F4F8E26@anilkumar.com> > On May 27, 2015, at 8:09 AM, Harald Koch wrote: > > On 26 May 2015 at 11:32, Alex Brooks wrote: > >> >> Can you not set account recory options which change the way password >> reset requests are handled. >> https://support.google.com/accounts/answer/183723 Gives some guidance? >> >> Alex >> > > Unfortunately, setting these options does not disable the separate "account > recovery form" listed at the bottom of the page, and it is this form that > allows you to login with any previous password and to bypass 2-factor auth. > > I must admit I was surprised by this when I tried it just now. I guess it's > time to rethink using Google as a primary account... According to this page, the 2-factor authentication does kick in when you finally try to reset the password. http://webapps.stackexchange.com/questions/27258/is-there-a-way-of-disabling-googles-password-recovery-feature ?? I was presented with an emailed link to a reset page. When I clicked that link, since I have two-step verification set up, I was presented with a demand for a number provided by the Google Authenticator app on my phone. I provided that number and only then was I allowed to reset the password.? AK -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3575 bytes Desc: not available URL: From alh-ietf at tndh.net Wed May 27 06:59:49 2015 From: alh-ietf at tndh.net (Tony Hain) Date: Tue, 26 May 2015 23:59:49 -0700 Subject: Multiple vendors' IPv6 issues In-Reply-To: References: Message-ID: <051201d0984a$b8f61040$2ae230c0$@tndh.net> David, While I agree with you that there is no excuse for the general IPv6 brokenness across all vendors, they are just doing what participants on lists like this one tell them. Name&Shame may help a little, but until a large number of people get serious and stop prioritizing IPv4 in their purchasing demands, the vendors are not going to prioritize IPv6. Until the vendors clearly hear a collective "we are not buying this product because IPv6 is broken", everyone will get exactly the behavior you are witnessing. While I appreciate the challenges you are facing, it is likely that you will be helped by documenting the percentage of IPv6 traffic you see when things do work. While it may not be much now, that can change quickly and will provide internal ammunition when you try to take a stand about refusing to use a product. If your IPv6 percentage grows anywhere near the 2x/yr rate that Google has been seeing it won't take long before IPv6 is the driving protocol. For fun, project this http://www.google.com/intl/en/ipv6/statistics.html forward 4 years and hand it to the vendors that can't get their IPv6 act together. Then ask them how they plan to still be in business at that point ...... Tony > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of David > Sotnick > Sent: Tuesday, May 26, 2015 4:19 PM > To: NANOG > Subject: Multiple vendors' IPv6 issues > > Hi NANOG, > > The company I work for has no business case for being on the IPv6-Internet. > However, I am an inquisitive person and I am always looking to learn new > things, so about 3 years ago I started down the IPv6 path. This was early > 2012. > > Fast forward to today. We have a /44 presence for our company's multiple > sites; All our desktop computers have been on the IPv6 Internet since June, > 2012 and we have a few AAAAs in our external DNS for some key services ? > and, there have been bugs. *Lots* of bugs. > > Now, maybe (_maybe_) I can have some sympathy for smaller network > companies (like Arista Networks at the time) to not quite have their act > together as far as IPv6 goes, but for larger, well-established companies to > still have critical IPv6 bugs is just inexcusable! > > This month has just been the most disheartening time working with IPv6. > > Vendor 1: > > Aruba Networks. Upon adding an IPv6 address to start managing our WiFi > controller over IPv6, I receive a call from our Telecom Lead saying that or > WiFi VoIP phones have just gone offline. WHAT? All I did was add an IPv6 > address to a management interface which has *nothing* to do with our VoIP > system or SSID, ACLs, policies, roles, etc. > > Vendor 2: > > Palo Alto Networks: After upgrading our firewalls from a version which has a > nasty bug where the IPv6 neighbor table wasn't being cleaned up properly > (which would overflow the table and break IPv6), we now have a *new* > IPv6 neighbor discovery bug where one of our V6-enabled DMZ hosts just > falls of the IPv6 network. The only solution: clear the neighbor table on the > Palo Alto or the client (linux) host. > > Vendor 3: > > Arista Networks: We are seeing a very similar ND bug with Arista. This one is > slightly more interesting because it only started after upgrading our Arista > EOS code ? and it only appears to affect Virtual Machines which are behind > our RedHat Enterprise Virtualization cluster. None of the hundreds of > VMware-connected hosts are affected. The symptom is basically the same > as the Palo Alto bug. Neighbor table gets in some weird state where ND > breaks and the host is unreachable until the neighbor table is cleared. > > Oh, and the final straw today, which is *almost* leading me to throw in the > IPv6 towel completely (for now): On certain hosts (VMs), scp'ing a file over > the [Arista] LAN (10 gigabit LAN) takes 5 minutes over IPv6 and <1 second > over IPv4. What happened? > > It really saddens me that it is still not receiving anywhere near the kind of > QA (partly as a result of lack of adoption) that IPv4 has. > > Oh, and let's not forget everybody's "favorite" vendor, Cisco. Why is it, > Cisco, that I have to restart my IPv6 OSPF3 process on my ASA every time my > Palo Alto firewall crashes and fails over, otherwise none of my VPN clients > can connect via IPv6? > > Why do you hurt me so, IPv6? I just wanted to be friends, and now I just > want to break up with you. Maybe we can try to be friends again when your > vendors get their shit together. > > -David From Valdis.Kletnieks at vt.edu Wed May 27 08:17:34 2015 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Wed, 27 May 2015 04:17:34 -0400 Subject: gmail security is a joke In-Reply-To: Your message of "Wed, 27 May 2015 09:13:47 +0530." <70986901-348F-415A-92B9-40997F4F8E26@anilkumar.com> References: <5564829E.1000006@truemetal.org> <70986901-348F-415A-92B9-40997F4F8E26@anilkumar.com> Message-ID: <44473.1432714654@turing-police.cc.vt.edu> On Wed, 27 May 2015 09:13:47 +0530, Anil Kumar said: > that link, since I have two-step verification set up, I was presented > with a demand for a number provided by the Google Authenticator > app on my phone. I provided that number and only then was I allowed > to reset the password. And you have to pre-register the phone number. Sounds about as secure as you're going to get when trying to scale to 10 digits of users.... And as I said earlier - if your threat model involves needing more security than that, you have bigger problems.. :) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From larrysheldon at cox.net Wed May 27 08:39:33 2015 From: larrysheldon at cox.net (Larry Sheldon) Date: Wed, 27 May 2015 03:39:33 -0500 Subject: gmail security is a joke In-Reply-To: References: <5564829E.1000006@truemetal.org> <70986901-348F-415A-92B9-40997F4F8E26@anilkumar.com> Message-ID: <556582C5.1070000@cox.net> On 5/27/2015 03:17, Valdis.Kletnieks at vt.edu wrote: > On Wed, 27 May 2015 09:13:47 +0530, Anil Kumar said: >> that link, since I have two-step verification set up, I was presented >> with a demand for a number provided by the Google Authenticator >> app on my phone. I provided that number and only then was I allowed >> to reset the password. > > And you have to pre-register the phone number. > > Sounds about as secure as you're going to get when trying to scale to 10 > digits of users.... > > And as I said earlier - if your threat model involves needing more security > than that, you have bigger problems.. :) As they say, I no longer have a dog in this fight beyond myself and to an extent (advisory capacity) my wife, but I have been having trouble understanding the concept of organizations ("network operators") with large and legitimate concerns for security issues, using gmail. -- sed quis custodiet ipsos custodes? (Juvenal) From mark.tinka at seacom.mu Wed May 27 09:55:32 2015 From: mark.tinka at seacom.mu (Mark Tinka) Date: Wed, 27 May 2015 11:55:32 +0200 Subject: Multiple vendors' IPv6 issues In-Reply-To: References: Message-ID: <55659494.5040304@seacom.mu> On 27/May/15 01:27, Ca By wrote: > Had ipv4 ever hurt you ? > > Me too. IPv4 still hurts me (in some ways, worse than IPv6), and it's 2015. Figures... You just need to open cases with your vendors and help them fix these issues. Sadly, no way around this. Software is not perfect. The humans that write it, even less so. Mark. From mark.tinka at seacom.mu Wed May 27 10:00:00 2015 From: mark.tinka at seacom.mu (Mark Tinka) Date: Wed, 27 May 2015 12:00:00 +0200 Subject: looking glass software In-Reply-To: <55654D77.9070803@shoshon.ro> References: <55654D77.9070803@shoshon.ro> Message-ID: <556595A0.8030806@seacom.mu> On 27/May/15 06:52, Bogdan wrote: > hello > > what software do you use for looking glass. for cisco ios and ios-xr? > i use the old cougar/version6.net for ios, but ios-xr is not supported. > i came across https://github.com/tmshlvck/ulg/ but did't installed yet. > are there any other interesting lg's out there? That's the one we use, but we run it against IOS. Should also work for IOS XE. I think I've seen some folk use it for Junos as well. Mark. From saper at saper.info Wed May 27 11:04:45 2015 From: saper at saper.info (Marcin Cieslak) Date: Wed, 27 May 2015 11:04:45 +0000 Subject: Multiple vendors' IPv6 issues In-Reply-To: References: Message-ID: On Tue, 26 May 2015, David Sotnick wrote: > Arista EOS code ? and it only appears to affect Virtual Machines which are > behind our RedHat Enterprise Virtualization cluster. None of the hundreds > of VMware-connected hosts are affected. The symptom is basically the same > as the Palo Alto bug. Neighbor table gets in some weird state where ND Is VMWare contributing somehow to the problem? Marcin From nanog at ics-il.net Wed May 27 12:13:01 2015 From: nanog at ics-il.net (Mike Hammett) Date: Wed, 27 May 2015 07:13:01 -0500 (CDT) Subject: Indy Telcom Center In-Reply-To: <32846681.268.1432727408903.JavaMail.mhammett@ThunderFuck> Message-ID: <24616037.318.1432728766345.JavaMail.mhammett@ThunderFuck> Can anyone here tell a bit of a history on the Indy Telcom Center? What operators (network and datacenter) have occupied what properties over the years? There's about a dozen buildings that were all railroad related in the past. You can see abandoned tracks running through the property at different places. http://www.indytelcom.com/IndyTelcom%20Property%20Map.pdf For instance, At one point Avaya's name was attached to 740 W. Henry. I think it was through an acquisition that they did. The last name attached to that property appears to have been Zenality, but they appear dead. There didn't appear to be any activity (air conditioners, etc.) from the building the last time I was there. 730 W. Henry shows up in Google as SP Telcom. I think I saw a Verizon logo on the door when I was last there, but I didn't document it to be sure. 701 W. Henry is now 365 Datacenters, but was Equinix. Being Equinix and not in a major market, I assume it was a Switch and Data property. Not sure what else has or does operate out of there. 733 W. Henry is LifeLine DataCenter and seems to have been for quite some time. We've got a presence there. 731 W. Henry is Lightbound datacenter. I think they have another one as well on the NE side of the campus. Are 650 W. Henry and 550 S. Kentucky the same building? 710 S. Kentucky seems to now be an AT&T MSC, but not sure whose it was originally. 720 S. Kentucky, WilTel POP? 800 Oliver seems to be under a few hats including Paragon and GAP. Not sure what's going on there. Some of the remaining buildings are other datacenters or carrier POPs, but I have less on them. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest Internet Exchange http://www.midwest-ix.com From owen at delong.com Wed May 27 12:19:13 2015 From: owen at delong.com (Owen DeLong) Date: Wed, 27 May 2015 14:19:13 +0200 Subject: gmail security is a joke In-Reply-To: <20150526161151.GA14841@pob.ytti.fi> References: <5564829E.1000006@truemetal.org> <20150526152246.GA12876@pob.ytti.fi> <312D54C4-EC72-4A3F-87FC-357AFA61D04A@delong.com> <20150526161151.GA14841@pob.ytti.fi> Message-ID: > On May 26, 2015, at 6:11 PM, Saku Ytti wrote: > > On (2015-05-26 17:44 +0200), Owen DeLong wrote: > > Hey, > >> I think opt-out of password recovery choices on a line-item basis is not a bad concept. > > This sounds reasonable. At least then you could decide which balance of > risk/convenience fits their use-case for given service. > >> OTOH, recovery by receiving a token at a previously registered alternate email address >> seems relatively secure to me and I wouldn???t want to opt out of that. > > It's probably machine sent in seconds or minute after request, so doing > short-lived BGP hijack of MX might be reasonably easy way to get the email. If someone has the ability to hijack your BGP, then you?ve got bigger problems than having them take over your Gmail account. > >> Recovery by SMS to a previously registered phone likewise seems reasonably secure >> and I wouldn???t want to opt out of that, either. > > I have tens of coworkers who could read my SMS. That?s interesting? Why do you choose to give access to your personal SMS messages to so many of your coworkers? > >> Really, you don???t need to strongly authenticate a particular person for these accounts. >> You need, instead, to authenticate that the person attempting recovery is reasonably >> likely to be the person who set up the account originally, whether or not they are who >> they claimed to be at that time. > > As long as user has the power to choose which risks are worth carrying, I > think it's fine. > For my examples, I wouldn't care about email/SMS risk if it's > linkedin/twitter/facebook account. But if it's my domain hoster, I probably > wouldn't want to carry either risk, as the whole deck of cards collapses if > you control my domains (all email recoveries compromised) We agree that different risks are appropriate for different levels of sensitivity. Owen From jabley at hopcount.ca Wed May 27 13:01:04 2015 From: jabley at hopcount.ca (Joe Abley) Date: Wed, 27 May 2015 14:01:04 +0100 Subject: gmail security is a joke In-Reply-To: References: <5564829E.1000006@truemetal.org> <20150526152246.GA12876@pob.ytti.fi> <312D54C4-EC72-4A3F-87FC-357AFA61D04A@delong.com> <20150526161151.GA14841@pob.ytti.fi> Message-ID: <16A4B421-C496-4537-B548-28666197B758@hopcount.ca> On 27 May 2015, at 13:19, Owen DeLong wrote: > If someone has the ability to hijack your BGP, then you?ve got > bigger problems than > having them take over your Gmail account. Could we perhaps summarise this entire thread with "if you have tighter security requirements for your e-mail than a particular e-mail provider can give you, host your e-mail somewhere else"? Also, if you get a stabbing pain in your eye every time you drink tea, take the spoon out of the cup. Joe From johnstong at westmancom.com Wed May 27 13:06:09 2015 From: johnstong at westmancom.com (Graham Johnston) Date: Wed, 27 May 2015 13:06:09 +0000 Subject: SAS Drive Enclosure In-Reply-To: References: <49EE1A35457387418410F97564A3752B01367C8A6E@MSG6.westman.int> <20150526195255.GA14394@esri.com> Message-ID: <49EE1A35457387418410F97564A3752B01367C911C@MSG6.westman.int> I am primarily wanting something that will act like a DELL MD1200, SAS connected to a server, then run a clustered filesystem on the server(s) which will serve up NFS or iSCSI to client devices. Graham Johnston Network Planner Westman Communications Group 204.717.2829 johnstong at westmancom.com ??think green; don't print this email. -----Original Message----- From: Jameson, Daniel [mailto:Daniel.Jameson at tdstelecom.com] Sent: Tuesday, May 26, 2015 3:11 PM To: Ray Van Dolson; Graham Johnston Cc: 'nanog at nanog.org' Subject: RE: SAS Drive Enclosure What are you thinking for connectivity, Ethernet, FiberChannel, Infiniband ... Building *Storage Nodes* or in need of just drive connectivity? -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Ray Van Dolson Sent: Tuesday, May 26, 2015 2:53 PM To: Graham Johnston Cc: 'nanog at nanog.org' Subject: Re: SAS Drive Enclosure On Tue, May 26, 2015 at 07:19:59PM +0000, Graham Johnston wrote: > I am looking for information about SAS drive enclosures, is there a > list like NANOG that covers that area of IT? > > I am specifically looking for an enclosure that can handle 12 or more > drives, I am looking to create a clustered file system between > multiple servers and would like to avoid a drive enclosure that only > works with a very small number of approved drives. I am looking to > support traditional HDDs as well as SSDs. There were discussions at some point about setting up a storage-centric list via SNIA or something else fairly 'neutral'. Never really materialized, however. Lists like lopsa-tech and the LISA/USENIX SAGE list are general enough you might get some good responses. WRT your question, we've had good luck with the Dell MD1200 line of JBODs. Ray From saku at ytti.fi Wed May 27 13:11:19 2015 From: saku at ytti.fi (Saku Ytti) Date: Wed, 27 May 2015 16:11:19 +0300 Subject: gmail security is a joke In-Reply-To: References: <5564829E.1000006@truemetal.org> <20150526152246.GA12876@pob.ytti.fi> <312D54C4-EC72-4A3F-87FC-357AFA61D04A@delong.com> <20150526161151.GA14841@pob.ytti.fi> Message-ID: <20150527131119.GA12103@pob.ytti.fi> On (2015-05-27 14:19 +0200), Owen DeLong wrote: Hey, > If someone has the ability to hijack your BGP, then you???ve got bigger problems than > having them take over your Gmail account. This is second reply to this notion. I don't understand what is attempted to communicate. I'm sure no one on nanog thinks BGP hijacks are rare, difficult or yield to consequences when called out. > That???s interesting??? Why do you choose to give access to your personal SMS messages > to so many of your coworkers? I don't, but they can provision my number to any SIM they want to. -- ++ytti From rafael at gav.ufsc.br Wed May 27 13:27:18 2015 From: rafael at gav.ufsc.br (Rafael Possamai) Date: Wed, 27 May 2015 08:27:18 -0500 Subject: gmail security is a joke In-Reply-To: <44473.1432714654@turing-police.cc.vt.edu> References: <5564829E.1000006@truemetal.org> <70986901-348F-415A-92B9-40997F4F8E26@anilkumar.com> <44473.1432714654@turing-police.cc.vt.edu> Message-ID: You can also register a U2F key. On Wed, May 27, 2015 at 3:17 AM, wrote: > On Wed, 27 May 2015 09:13:47 +0530, Anil Kumar said: > > that link, since I have two-step verification set up, I was presented > > with a demand for a number provided by the Google Authenticator > > app on my phone. I provided that number and only then was I allowed > > to reset the password. > > And you have to pre-register the phone number. > > Sounds about as secure as you're going to get when trying to scale to 10 > digits of users.... > > And as I said earlier - if your threat model involves needing more security > than that, you have bigger problems.. :) > From jmaslak at antelope.net Wed May 27 13:42:19 2015 From: jmaslak at antelope.net (Joel Maslak) Date: Wed, 27 May 2015 07:42:19 -0600 Subject: gmail security is a joke In-Reply-To: <20150527131119.GA12103@pob.ytti.fi> References: <5564829E.1000006@truemetal.org> <20150526152246.GA12876@pob.ytti.fi> <312D54C4-EC72-4A3F-87FC-357AFA61D04A@delong.com> <20150526161151.GA14841@pob.ytti.fi> <20150527131119.GA12103@pob.ytti.fi> Message-ID: I also suspect not every telco validates number porting requests against social engineering properly. A telephone number isn't something you have, it is something your provider has. On Wednesday, May 27, 2015, Saku Ytti wrote: > On (2015-05-27 14:19 +0200), Owen DeLong wrote: > > Hey, > > > If someone has the ability to hijack your BGP, then you???ve got bigger > problems than > > having them take over your Gmail account. > > This is second reply to this notion. I don't understand what is attempted > to > communicate. I'm sure no one on nanog thinks BGP hijacks are rare, > difficult > or yield to consequences when called out. > > > That???s interesting??? Why do you choose to give access to your > personal SMS messages > > to so many of your coworkers? > > I don't, but they can provision my number to any SIM they want to. > > -- > ++ytti > From rafael at gav.ufsc.br Wed May 27 13:51:28 2015 From: rafael at gav.ufsc.br (Rafael Possamai) Date: Wed, 27 May 2015 08:51:28 -0500 Subject: gmail security is a joke In-Reply-To: References: <5564829E.1000006@truemetal.org> <20150526152246.GA12876@pob.ytti.fi> <312D54C4-EC72-4A3F-87FC-357AFA61D04A@delong.com> <20150526161151.GA14841@pob.ytti.fi> <20150527131119.GA12103@pob.ytti.fi> Message-ID: "Security is an illusion" - Confucius probably On Wed, May 27, 2015 at 8:42 AM, Joel Maslak wrote: > I also suspect not every telco validates number porting requests against > social engineering properly. > > A telephone number isn't something you have, it is something your provider > has. > > On Wednesday, May 27, 2015, Saku Ytti wrote: > > > On (2015-05-27 14:19 +0200), Owen DeLong wrote: > > > > Hey, > > > > > If someone has the ability to hijack your BGP, then you???ve got bigger > > problems than > > > having them take over your Gmail account. > > > > This is second reply to this notion. I don't understand what is attempted > > to > > communicate. I'm sure no one on nanog thinks BGP hijacks are rare, > > difficult > > or yield to consequences when called out. > > > > > That???s interesting??? Why do you choose to give access to your > > personal SMS messages > > > to so many of your coworkers? > > > > I don't, but they can provision my number to any SIM they want to. > > > > -- > > ++ytti > > > From rvandolson at esri.com Wed May 27 13:19:35 2015 From: rvandolson at esri.com (Ray Van Dolson) Date: Wed, 27 May 2015 06:19:35 -0700 Subject: SAS Drive Enclosure In-Reply-To: <49EE1A35457387418410F97564A3752B01367C911C@MSG6.westman.int> References: <49EE1A35457387418410F97564A3752B01367C8A6E@MSG6.westman.int> <20150526195255.GA14394@esri.com> <49EE1A35457387418410F97564A3752B01367C911C@MSG6.westman.int> Message-ID: <20150527131935.GA9511@esri.com> MD1200 is a great bet then. Other options -- SuperMicro has lots: http://www.supermicro.com/products/chassis/2U/?chs=216 Quanta: http://www.quantaqct.com/Product/Rack-Systems/Rackgo-X/JBODs/JBR-p247c77c86c88c92 On Wed, May 27, 2015 at 01:06:09PM +0000, Graham Johnston wrote: > I am primarily wanting something that will act like a DELL MD1200, > SAS connected to a server, then run a clustered filesystem on the > server(s) which will serve up NFS or iSCSI to client devices. > > Graham Johnston > Network Planner > Westman Communications Group > 204.717.2829 > johnstong at westmancom.com > ??think green; don't print this email. > > -----Original Message----- > From: Jameson, Daniel [mailto:Daniel.Jameson at tdstelecom.com] > Sent: Tuesday, May 26, 2015 3:11 PM > To: Ray Van Dolson; Graham Johnston > Cc: 'nanog at nanog.org' > Subject: RE: SAS Drive Enclosure > > What are you thinking for connectivity, Ethernet, FiberChannel, > Infiniband ... Building *Storage Nodes* or in need of just drive > connectivity? > > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Ray Van Dolson > Sent: Tuesday, May 26, 2015 2:53 PM > To: Graham Johnston > Cc: 'nanog at nanog.org' > Subject: Re: SAS Drive Enclosure > > On Tue, May 26, 2015 at 07:19:59PM +0000, Graham Johnston wrote: > > I am looking for information about SAS drive enclosures, is there a > > list like NANOG that covers that area of IT? > > > > I am specifically looking for an enclosure that can handle 12 or more > > drives, I am looking to create a clustered file system between > > multiple servers and would like to avoid a drive enclosure that only > > works with a very small number of approved drives. I am looking to > > support traditional HDDs as well as SSDs. > > There were discussions at some point about setting up a > storage-centric list via SNIA or something else fairly 'neutral'. > Never really materialized, however. > > Lists like lopsa-tech and the LISA/USENIX SAGE list are general > enough you might get some good responses. > > WRT your question, we've had good luck with the Dell MD1200 line of > JBODs. > > Ray From bill at herrin.us Wed May 27 14:28:12 2015 From: bill at herrin.us (William Herrin) Date: Wed, 27 May 2015 10:28:12 -0400 Subject: gmail security is a joke In-Reply-To: References: <20150526160638.14758.qmail@ary.lan> Message-ID: On Tue, May 26, 2015 at 4:10 PM, Scott Howard wrote: > On Tue, May 26, 2015 at 12:28 PM, Aaron C. de Bruyn > wrote: >> If they can e-mail you your existing password (*cough*Netgear*cough*), >> it means they are storing your credentials in the database >> un-encrypted. > > No, it doesn't mean that at all. It means they are storing it unhashed > which is probably what you mean. Hi Scott, It means they're storing it in a form that reduces to plain text without human intervention. Same difference. Encrypted at rest matters not, if all the likely attack vectors go after the data in transit. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: From colton.conor at gmail.com Wed May 27 16:52:55 2015 From: colton.conor at gmail.com (Colton Conor) Date: Wed, 27 May 2015 11:52:55 -0500 Subject: 10Gb CPE In-Reply-To: <5015108B-5998-4771-84E9-D9698884E66D@argentiumsolutions.com> References: <5015108B-5998-4771-84E9-D9698884E66D@argentiumsolutions.com> Message-ID: Who makes the 7250? On Tue, May 26, 2015 at 10:07 PM, Brant Ian Stevens < branto at argentiumsolutions.com> wrote: > Any feedback on the new 7250?s yet? > > > > > On 5/26/15, 3:02 PM, "NANOG on behalf of Chris Lane" < > nanog-bounces at nanog.org on behalf of clane1875 at gmail.com> wrote: > > >We use Brocade ICX 6450s for this. > > > >-Chris > > > >On Tue, May 26, 2015 at 2:40 PM, Daniel Rohan wrote: > > > >> With the deluge of 10Gb X device recommendations, I thought I'd hit the > >> list with one more. Does anyone out there running 10Gb managed CPE feel > >> like sharing their experiences? > >> > >> Our use case would be a managed endpoint that would allow for testing > and > >> circuit verification while providing a layer 2 extension to our edge > gear > >> at the PoPs. > >> > >> We're hoping to find a cheap vendor-supplied solution- not homebrew. > >> > >> If so, which features have been important to you? > >> > >> Which vendors have good products? > >> > >> What price point? > >> > >> > >> Thanks, > >> > >> Dan > >> > > > > > > > >-- > >- Chris > > From branto at argentiumsolutions.com Wed May 27 17:03:35 2015 From: branto at argentiumsolutions.com (Brant Ian Stevens) Date: Wed, 27 May 2015 13:03:35 -0400 Subject: 10Gb CPE In-Reply-To: References: <5015108B-5998-4771-84E9-D9698884E66D@argentiumsolutions.com> Message-ID: <21DE50AE-28B8-4345-9EE7-509648266FBF@argentiumsolutions.com> Brocade. From: Colton Conor Date: Wednesday, May 27, 2015 at 12:52 PM To: branto Cc: Chris Lane, Daniel Rohan, NANOG Subject: Re: 10Gb CPE Who makes the 7250? On Tue, May 26, 2015 at 10:07 PM, Brant Ian Stevens wrote: Any feedback on the new 7250?s yet? On 5/26/15, 3:02 PM, "NANOG on behalf of Chris Lane" wrote: >We use Brocade ICX 6450s for this. > >-Chris > >On Tue, May 26, 2015 at 2:40 PM, Daniel Rohan wrote: > >> With the deluge of 10Gb X device recommendations, I thought I'd hit the >> list with one more. Does anyone out there running 10Gb managed CPE feel >> like sharing their experiences? >> >> Our use case would be a managed endpoint that would allow for testing and >> circuit verification while providing a layer 2 extension to our edge gear >> at the PoPs. >> >> We're hoping to find a cheap vendor-supplied solution- not homebrew. >> >> If so, which features have been important to you? >> >> Which vendors have good products? >> >> What price point? >> >> >> Thanks, >> >> Dan >> > > > >-- >- Chris From Valdis.Kletnieks at vt.edu Wed May 27 17:41:01 2015 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Wed, 27 May 2015 13:41:01 -0400 Subject: gmail security is a joke In-Reply-To: Your message of "Wed, 27 May 2015 16:11:19 +0300." <20150527131119.GA12103@pob.ytti.fi> References: <5564829E.1000006@truemetal.org> <20150526152246.GA12876@pob.ytti.fi> <312D54C4-EC72-4A3F-87FC-357AFA61D04A@delong.com> <20150526161151.GA14841@pob.ytti.fi> <20150527131119.GA12103@pob.ytti.fi> Message-ID: <19290.1432748461@turing-police.cc.vt.edu> On Wed, 27 May 2015 16:11:19 +0300, Saku Ytti said: > This is second reply to this notion. I don't understand what is attempted to > communicate. I'm sure no one on nanog thinks BGP hijacks are rare, difficult > or yield to consequences when called out. What *is* rare is a BGP hijack done solely to intercept a confirmation e-mail sent to Joe Sixpack when he's trying to get his Gmail account back. Can anybody provide a *single* example of that being done? Now, if it's Joe CEO or Joe Prime Minister, the calculus changes a bit. But as I said - at that point, you have bigger things to worry about. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From bzs at world.std.com Wed May 27 17:51:35 2015 From: bzs at world.std.com (Barry Shein) Date: Wed, 27 May 2015 13:51:35 -0400 Subject: gmail security is a joke In-Reply-To: References: <20150526160638.14758.qmail@ary.lan> Message-ID: <21862.1063.465196.824619@world.std.com> On May 27, 2015 at 10:28 bill at herrin.us (William Herrin) wrote: > On Tue, May 26, 2015 at 4:10 PM, Scott Howard wrote: > > On Tue, May 26, 2015 at 12:28 PM, Aaron C. de Bruyn > > wrote: > >> If they can e-mail you your existing password (*cough*Netgear*cough*), > >> it means they are storing your credentials in the database > >> un-encrypted. > > > > No, it doesn't mean that at all. It means they are storing it unhashed > > which is probably what you mean. > > Hi Scott, > > It means they're storing it in a form that reduces to plain text > without human intervention. Same difference. Encrypted at rest matters > not, if all the likely attack vectors go after the data in transit. It matters a lot. It means their entire username/password collection can be compromised by various means including by an insider. The usual practice is to store a hash which cannot be reversed (at least not without astronomical computation.) Then when a password is presented (e.g., for login) the hash is computed on that cleartext password and the hashes are compared. Getting a copy of the database of hashes and login names is basically useless to an attacker. It's not encrypted in this case, it's hashed and only the hash is stored. The hash cannot be reversed, only compared to a re-hash of the cleartext password when entered. The OP was correct, if they can send you your cleartext password then their security practices are inadequate, period. Unless I misunderstand what you're saying (I sort of hope I do) this is Security 101. -- -Barry Shein The World | bzs at TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: 800-THE-WRLD | Dial-Up: US, PR, Canada Software Tool & Die | Public Access Internet | SINCE 1989 *oo* From johnl at iecc.com Wed May 27 18:22:04 2015 From: johnl at iecc.com (John R. Levine) Date: 27 May 2015 14:22:04 -0400 Subject: gmail security is a joke In-Reply-To: <21862.1063.465196.824619@world.std.com> References: <20150526160638.14758.qmail@ary.lan> <21862.1063.465196.824619@world.std.com> Message-ID: > The OP was correct, if they can send you your cleartext password then > their security practices are inadequate, period. > > Unless I misunderstand what you're saying (I sort of hope I do) this > is Security 101. As I've said a couple of times already, but perhaps without the capital letters, from a security point of view, generating a NEW PASSWORD and sending it in cleartext is no worse than sending you a one time reset link. Either way, if a bad guy can intercept your mail, you lose. A few moments' thought will confirm this has nothing to do with the way passwords are stored within the mail system's database. R's, John From egon at egon.cc Wed May 27 18:33:29 2015 From: egon at egon.cc (James Downs) Date: Wed, 27 May 2015 11:33:29 -0700 Subject: gmail security is a joke In-Reply-To: References: <20150526160638.14758.qmail@ary.lan> <21862.1063.465196.824619@world.std.com> Message-ID: > On May 27, 2015, at 11:22, John R. Levine wrote: > As I've said a couple of times already, but perhaps without the capital letters, from a security point of view, generating a NEW PASSWORD and sending it in cleartext is no worse than sending you a one time reset link. Either way, if a bad guy can intercept your mail, you lose. Well, no? a one time reset link is infinitely better than sending a cleartext password, assuming you don?t have to immediately change the password. A reset link, being usable once, means that you can detect if an attacker has already used it. If you use it first, the attacker has a useless link. If an attacker gets a cleartext password, you probably can?t detect interception. Cheers, -j From bzs at world.std.com Wed May 27 18:42:59 2015 From: bzs at world.std.com (Barry Shein) Date: Wed, 27 May 2015 14:42:59 -0400 Subject: gmail security is a joke In-Reply-To: References: <20150526160638.14758.qmail@ary.lan> <21862.1063.465196.824619@world.std.com> Message-ID: <21862.4147.622154.857787@world.std.com> On May 27, 2015 at 14:22 johnl at iecc.com (John R. Levine) wrote: > > The OP was correct, if they can send you your cleartext password then > > their security practices are inadequate, period. > > > > Unless I misunderstand what you're saying (I sort of hope I do) this > > is Security 101. > > As I've said a couple of times already, but perhaps without the capital > letters, from a security point of view, generating a NEW PASSWORD and > sending it in cleartext is no worse than sending you a one time reset > link. Either way, if a bad guy can intercept your mail, you lose. > > A few moments' thought will confirm this has nothing to do with the way > passwords are stored within the mail system's database. Sure, I agree, but that's not what the post I was responding to was discussing so caps wouldn't make much difference. But only the link can be secured by asking a security question before first use. For the cleartext password an attacker only has to wait for you to answer the question and hope you don't immediately change the password. I suppose asking a question on first use of a new cleartext password AND forcing you to change that password immediately is about the same as the link, particularly if it doesn't let you use that same password. But storing cleartext passwords, encrypted or not, is a bad and indefensible practice. I remember a common dial-up login protocol which required the server to encrypt initial interaction with the customer's password so you absolutely had to have their cleartext password if they were ever to log in again. What was it, PAP or CHAP or something like that. Ugh, we resisted that. -- -Barry Shein The World | bzs at TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: 800-THE-WRLD | Dial-Up: US, PR, Canada Software Tool & Die | Public Access Internet | SINCE 1989 *oo* From bzs at world.std.com Wed May 27 19:07:22 2015 From: bzs at world.std.com (Barry Shein) Date: Wed, 27 May 2015 15:07:22 -0400 Subject: gmail security is a joke In-Reply-To: References: <20150526160638.14758.qmail@ary.lan> <21862.1063.465196.824619@world.std.com> Message-ID: <21862.5610.944147.234204@world.std.com> One weakness with sending a new cleartext password rather than a link is that a cleartext password (probably) has to be engineered to be easy to type in and maybe even remembered. Typically one uses some concatenation of CVC (consonant-vowel-consonant) with common punctuations and/or digits otherwise chosen randomly so something like pom%mur or kiv_ler for 7 chars anyhow, maybe add a digit or two, pom%mur87. A link can be much more random, just some long (64 char or more) string of hexified nonsense for example since the user presumably just clicks it and doesn't have to read it or type it in or worse remember it. SOOOOOO...an attacker could study your cleartext password generation algorithm which for a shorter, simpler, already structured cleartext password will be more likely to be predictable all else being equal. Perhaps the algorithm itself is is even available if you use some identifiable software package such as an e-commerce suite, I can't imagine every person selling paisley socks writes their own password generation algorithm. Or by studying the passwords it generates (create an acct, send yourself a few hundred or thousand.) I'm not just a-whistlin' dixie (I never a-whistle dixie! :-), I'd consider that a serious potential weakness adding more concern to choice of algorithms. -- -Barry Shein The World | bzs at TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: 800-THE-WRLD | Dial-Up: US, PR, Canada Software Tool & Die | Public Access Internet | SINCE 1989 *oo* From codygrosskopf at gmail.com Wed May 27 19:12:45 2015 From: codygrosskopf at gmail.com (Cody Grosskopf) Date: Wed, 27 May 2015 19:12:45 +0000 Subject: 10Gb CPE In-Reply-To: References: Message-ID: I also used brocade icx series for this. Depending on feature requirements the juniper ex3300 might be cheaper. On Tue, May 26, 2015, 12:04 PM Chris Lane wrote: > We use Brocade ICX 6450s for this. > > -Chris > > On Tue, May 26, 2015 at 2:40 PM, Daniel Rohan wrote: > > > With the deluge of 10Gb X device recommendations, I thought I'd hit the > > list with one more. Does anyone out there running 10Gb managed CPE feel > > like sharing their experiences? > > > > Our use case would be a managed endpoint that would allow for testing > and > > circuit verification while providing a layer 2 extension to our edge gear > > at the PoPs. > > > > We're hoping to find a cheap vendor-supplied solution- not homebrew. > > > > If so, which features have been important to you? > > > > Which vendors have good products? > > > > What price point? > > > > > > Thanks, > > > > Dan > > > > > > -- > - Chris > From jared at puck.Nether.net Wed May 27 19:20:55 2015 From: jared at puck.Nether.net (Jared Mauch) Date: Wed, 27 May 2015 15:20:55 -0400 Subject: Multiple vendors' IPv6 issues In-Reply-To: References: Message-ID: <20150527192055.GA26964@puck.nether.net> On Tue, May 26, 2015 at 04:19:25PM -0700, David Sotnick wrote: > Hi NANOG, > > The company I work for has no business case for being on the IPv6-Internet. > However, I am an inquisitive person and I am always looking to learn new > things, so about 3 years ago I started down the IPv6 path. This was early > 2012. > > Fast forward to today. We have a /44 presence for our company's multiple > sites; All our desktop computers have been on the IPv6 Internet since June, > 2012 and we have a few AAAAs in our external DNS for some key services ? > and, there have been bugs. *Lots* of bugs. > > Now, maybe (_maybe_) I can have some sympathy for smaller network companies > (like Arista Networks at the time) to not quite have their act together as > far as IPv6 goes, but for larger, well-established companies to still have > critical IPv6 bugs is just inexcusable! My current favorites are: https://tools.cisco.com/bugsearch/bug/CSCut62344 Which doesn't allow you to see the neighbors on an interface. this is fun when diagnosing qemu/kvm issues with the macvtap and hosts with ipv6. turns out you to 'fix it' you need to make the macvtap interface promisc as the icmpv6 messages don't make it through the macvtap driver to the VM breaking neighbor discovery. You can guess how we saw the first bug with the second one. This isn't as bad as a colleague who told me he is taking classes at a university whose professor said that a /20 is neither a class A or class B allocation but in the middle, not knowing that CIDR has existed for the past 20 years. Turns out we need a few more SMEs to teach people about CIDR and IPv6 addressing to prevent univeristy professors from teaching the next generation something that doesn't apply anymore. - Jared -- Jared Mauch | pgp key available via finger from jared at puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine. From brak at gameservers.com Wed May 27 19:35:15 2015 From: brak at gameservers.com (Brian Rak) Date: Wed, 27 May 2015 15:35:15 -0400 Subject: Multiple vendors' IPv6 issues In-Reply-To: <20150527192055.GA26964@puck.nether.net> References: <20150527192055.GA26964@puck.nether.net> Message-ID: <55661C73.2000504@gameservers.com> On 5/27/2015 3:20 PM, Jared Mauch wrote: > On Tue, May 26, 2015 at 04:19:25PM -0700, David Sotnick wrote: >> Hi NANOG, >> >> The company I work for has no business case for being on the IPv6-Internet. >> However, I am an inquisitive person and I am always looking to learn new >> things, so about 3 years ago I started down the IPv6 path. This was early >> 2012. >> >> Fast forward to today. We have a /44 presence for our company's multiple >> sites; All our desktop computers have been on the IPv6 Internet since June, >> 2012 and we have a few AAAAs in our external DNS for some key services ? >> and, there have been bugs. *Lots* of bugs. >> >> Now, maybe (_maybe_) I can have some sympathy for smaller network companies >> (like Arista Networks at the time) to not quite have their act together as >> far as IPv6 goes, but for larger, well-established companies to still have >> critical IPv6 bugs is just inexcusable! > My current favorites are: > > https://tools.cisco.com/bugsearch/bug/CSCut62344 > > Which doesn't allow you to see the neighbors on an interface. this is fun > when diagnosing qemu/kvm issues with the macvtap and hosts with ipv6. > turns out you to 'fix it' you need to make the macvtap interface promisc > as the icmpv6 messages don't make it through the macvtap driver to the VM > breaking neighbor discovery. You don't need full promisc mode, just the (poorly documented) allmulticast option (ip link set dev $macvtap allmulticast on) From bill at herrin.us Wed May 27 20:05:12 2015 From: bill at herrin.us (William Herrin) Date: Wed, 27 May 2015 16:05:12 -0400 Subject: gmail security is a joke In-Reply-To: <21862.1063.465196.824619@world.std.com> References: <20150526160638.14758.qmail@ary.lan> <21862.1063.465196.824619@world.std.com> Message-ID: On Wed, May 27, 2015 at 1:51 PM, Barry Shein wrote: > On May 27, 2015 at 10:28 bill at herrin.us (William Herrin) wrote: > > On Tue, May 26, 2015 at 4:10 PM, Scott Howard wrote: > > > It means they are storing it unhashed > > > which is probably what you mean. > > > > It means they're storing it in a form that reduces to plain text > > without human intervention. Same difference. Encrypted at rest matters > > not, if all the likely attack vectors go after the data in transit. > > It matters a lot. [...] > The OP was correct, if they can send you your cleartext password then > their security practices are inadequate, period. Am I speaking English? I thought I was speaking English. > Unless I misunderstand what you're saying (I sort of hope I do) Yeah, I think you probably did since I was largely agreeing with you. What I was trying to say was that there wasn't a heck of a lot of difference between storing a user's password with reversible encryption and storing it in plain text. Both are supremely unsatisfactory. Reasonable security starts by not retaining the user's password at all. Keep only the non-reversible hash. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: From rsk at gsp.org Wed May 27 20:20:33 2015 From: rsk at gsp.org (Rich Kulawiec) Date: Wed, 27 May 2015 16:20:33 -0400 Subject: gmail security is a joke In-Reply-To: <21862.1063.465196.824619@world.std.com> References: <20150526160638.14758.qmail@ary.lan> <21862.1063.465196.824619@world.std.com> Message-ID: <20150527202033.GA26696@gsp.org> On Wed, May 27, 2015 at 01:51:35PM -0400, Barry Shein wrote: > Getting a copy of the database of hashes and login names is basically > useless to an attacker. Not any more, if the hash algorithm isn't sufficiently strong: 25-GPU cluster cracks every standard Windows password in <6 hours http://arstechnica.com/security/2012/12/25-gpu-cluster-cracks-every-standard-windows-password-in-6-hours/ Quoting: "Gosney used the machine to crack 90 percent of the 6.5 million password hashes belonging to users of LinkedIn." Consider as well that not all attackers are interested in all accounts: imagine what this system (or a newer one, this is 2.5 years old) could do if focused on only one account. And of course epidemic password reuse means that cracked passwords are reasonably likely to work at multiple sites. And even if passwords aren't reused, there have now been so many breaches at so many places resulting in so many disclosed passwords that a discerning attacker could likely glean useful intelligence by studying multiple password choices made by a target. (We're all creatures of habit.) ---rsk From chk at pobox.com Wed May 27 20:52:19 2015 From: chk at pobox.com (Harald Koch) Date: Wed, 27 May 2015 16:52:19 -0400 Subject: gmail security is a joke In-Reply-To: <70986901-348F-415A-92B9-40997F4F8E26@anilkumar.com> References: <5564829E.1000006@truemetal.org> <70986901-348F-415A-92B9-40997F4F8E26@anilkumar.com> Message-ID: On 26 May 2015 at 23:43, Anil Kumar wrote: > > According to this page, the 2-factor authentication does kick in when you > finally try to reset the password. > > > http://webapps.stackexchange.com/questions/27258/is-there-a-way-of-disabling-googles-password-recovery-feature > > ?? I was presented with an emailed link to a reset page. When I clicked > that link, since I have two-step verification set up, I was presented > with a demand for a number provided by the Google Authenticator > app on my phone. I provided that number and only then was I allowed > to reset the password.? > Y'all are way too trusting ;) If I recall from a brief experiment yesterday, three of the four options on that page are variations on "I'd like to bypass 2-factor authentication". There is really no point in any of Google's fancy account security if I can bypass all of it using Google's Identity Verification process, especially if that process is based on PII that isn't terribly difficult to obtain. This is just a variation on Apple's "give us the last four digits of your credit card to reset your password" gigantic security failure, and frankly I expected better from Google. Silly me. -- Harald (who once upon a time worked in the IAM space ;) From jimpop at gmail.com Wed May 27 21:06:17 2015 From: jimpop at gmail.com (Jim Popovitch) Date: Wed, 27 May 2015 17:06:17 -0400 Subject: gmail security is a joke In-Reply-To: References: <5564829E.1000006@truemetal.org> <70986901-348F-415A-92B9-40997F4F8E26@anilkumar.com> Message-ID: On Wed, May 27, 2015 at 4:52 PM, Harald Koch wrote: > > Y'all are way too trusting ;) Or we are much more comfortable with our knowledge. Six in one,.... > If I recall from a brief experiment yesterday, three of the four options on > that page are variations on "I'd like to bypass 2-factor authentication". > There is really no point in any of Google's fancy account security if I can > bypass all of it using Google's Identity Verification process, especially > if that process is based on PII that isn't terribly difficult to obtain. I think you are overly simplifying a piece of a very large, very complicated, highly dynamic, and daily reviewed, security pipeline. Google's Account security is not a 1 man in the basement operation. You tell me the Sender, time, last Received line, and byte size, of all the emails I received on 1-Jan-2015 and I will give you $100 per email.... or this thread can just die a miserable hypothetical death that it deserves. -Jim P. From jfmezei_nanog at vaxination.ca Wed May 27 21:36:23 2015 From: jfmezei_nanog at vaxination.ca (Jean-Francois Mezei) Date: Wed, 27 May 2015 17:36:23 -0400 Subject: Capacity/transit costs vs growth Message-ID: <556638D7.9020305@vaxination.ca> I am looking for some rough estimates of the ratio of capacity (equipment) pricing declines versus average increase in end user capacity. For instance, say end user average capcity usage increases 50% over 3 years, would the ISP's costs also increase by 50% ? Or would increased efficency of equipment result in a 50% decrease in capacity costs yielding roughly the same total cost to the service provider ? So I am looking are some sort of ratio of gross costs increases/decreases relative to end user usage increase in usage over time. Context: Wholesale services in Canada are priced linearly and there is a process trying to convince the CRTC to review them ASAP. So if average use grows from 1mbps during peak to 1.2mbps, we are looking at 20% increase in costs in a linear pricing scheme. But if this happens over a period where there have been improvements in equipment/efficiency, then one would think the increase in costs would be less than 20%. So I am looking for any and all information that can help convince the regulator that current linear increase is not right and needs a review. any help appreciated. From bzs at world.std.com Wed May 27 21:50:36 2015 From: bzs at world.std.com (Barry Shein) Date: Wed, 27 May 2015 17:50:36 -0400 Subject: gmail security is a joke In-Reply-To: References: <20150526160638.14758.qmail@ary.lan> <21862.1063.465196.824619@world.std.com> Message-ID: <21862.15404.387676.217627@world.std.com> I am truly relieved that this was just a misunderstanding! -b On May 27, 2015 at 16:05 bill at herrin.us (William Herrin) wrote: > On Wed, May 27, 2015 at 1:51 PM, Barry Shein wrote: > > On May 27, 2015 at 10:28 bill at herrin.us (William Herrin) wrote: > > > On Tue, May 26, 2015 at 4:10 PM, Scott Howard wrote: > > > > It means they are storing it unhashed > > > > which is probably what you mean. > > > > > > It means they're storing it in a form that reduces to plain text > > > without human intervention. Same difference. Encrypted at rest matters > > > not, if all the likely attack vectors go after the data in transit. > > > > It matters a lot. [...] > > The OP was correct, if they can send you your cleartext password then > > their security practices are inadequate, period. > > Am I speaking English? I thought I was speaking English. > > > > Unless I misunderstand what you're saying (I sort of hope I do) > > Yeah, I think you probably did since I was largely agreeing with you. > What I was trying to say was that there wasn't a heck of a lot of > difference between storing a user's password with reversible > encryption and storing it in plain text. Both are supremely > unsatisfactory. Reasonable security starts by not retaining the user's > password at all. Keep only the non-reversible hash. > > Regards, > Bill Herrin > > -- > William Herrin ................ herrin at dirtside.com bill at herrin.us > Owner, Dirtside Systems ......... Web: From bzs at world.std.com Wed May 27 21:54:05 2015 From: bzs at world.std.com (Barry Shein) Date: Wed, 27 May 2015 17:54:05 -0400 Subject: gmail security is a joke In-Reply-To: <20150527202033.GA26696@gsp.org> References: <20150526160638.14758.qmail@ary.lan> <21862.1063.465196.824619@world.std.com> <20150527202033.GA26696@gsp.org> Message-ID: <21862.15613.892662.393532@world.std.com> Good name in man and woman, dear my lord, Is the immediate jewel of their souls. Who steals my purse steals trash; 'tis something, nothing; 'Twas mine, 'tis his, and has been slave to thousands; But he that filches from me my good name Robs me of that which not enriches him, And makes me poor indeed. --Othello Act 3, Scene 3 -- -Barry Shein The World | bzs at TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: 800-THE-WRLD | Dial-Up: US, PR, Canada Software Tool & Die | Public Access Internet | SINCE 1989 *oo* From mark.tinka at seacom.mu Wed May 27 22:53:50 2015 From: mark.tinka at seacom.mu (Mark Tinka) Date: Thu, 28 May 2015 00:53:50 +0200 Subject: Capacity/transit costs vs growth In-Reply-To: <556638D7.9020305@vaxination.ca> References: <556638D7.9020305@vaxination.ca> Message-ID: <55664AFE.70308@seacom.mu> On 27/May/15 23:36, Jean-Francois Mezei wrote: > I am looking for some rough estimates of the ratio of capacity > (equipment) pricing declines versus average increase in end user capacity. > > For instance, say end user average capcity usage increases 50% over 3 > years, would the ISP's costs also increase by 50% ? Or would increased > efficency of equipment result in a 50% decrease in capacity costs > yielding roughly the same total cost to the service provider ? > > So I am looking are some sort of ratio of gross costs > increases/decreases relative to end user usage increase in usage over time. To be more accurate with this, you might want to consider what portion of every part of the overall network is attributed to the costs your customer burdens you with. This isn't necessarily easy to do, but is more accurate than thinking of only the box the customer physically connects to. You will spend differently in different parts of the network, e.g., peering, core, edge, services, e.t.c. How much of that goes back to (or is caused by) your customers? Mark. From beckman at angryox.com Wed May 27 23:04:12 2015 From: beckman at angryox.com (Peter Beckman) Date: Wed, 27 May 2015 19:04:12 -0400 Subject: gmail security is a joke In-Reply-To: <20150527202033.GA26696@gsp.org> References: <20150526160638.14758.qmail@ary.lan> <21862.1063.465196.824619@world.std.com> <20150527202033.GA26696@gsp.org> Message-ID: LinkedIn used SHA-1, a fast algorithm. At 350-billion guesses per second on the mentioned rig for fast algorithms, yeah, you can get through a lot of passwords quickly. Hopefully LinkedIn has changed their ways. In that same article: "...functions such as Bcrypt, PBKDF2, and SHA512crypt are designed to expend considerably more time and computing resources to convert plaintext input into cryptographic hashes. As a result, the new cluster, even with its four-fold increase in speed, can make only 71,000 guesses against Bcrypt..." And if you use a different salt for each password stored with Bcrypt, the hacker must test each password separately -- no rainbow tables here. Unfortunately they don't say how many iterations of Bcrypt equals 71,000, since you can add more iterations of the algorithm. An example cipher text from bcrypt: $2a$13$Ejtc1pVjyLkZn4eU9FGCg.gOQ3QtbWOsUOvSUKbU2anywhoO04ESy $2a$ indicates the blowfish algorithm, $13$ is the cost factor (number of iterations), the first 22 chars after are the salt and the rest is the cipher text. The higher the number of iterations, the harder computationally it is to go from a password to the cipher text. As hardware improves, the iterations should increase. I was thinking about using the last 2 digits of the year as the cost factor, but that might not scale with hardware linearly. Bcrypt or PBKDF2 with random salts per password is really what anyone storing passwords should be using today. Beckman On Wed, 27 May 2015, Rich Kulawiec wrote: > On Wed, May 27, 2015 at 01:51:35PM -0400, Barry Shein wrote: >> Getting a copy of the database of hashes and login names is basically >> useless to an attacker. > > Not any more, if the hash algorithm isn't sufficiently strong: > > 25-GPU cluster cracks every standard Windows password in <6 hours > http://arstechnica.com/security/2012/12/25-gpu-cluster-cracks-every-standard-windows-password-in-6-hours/ > > Quoting: > > "Gosney used the machine to crack 90 percent of the 6.5 million > password hashes belonging to users of LinkedIn." > > Consider as well that not all attackers are interested in all accounts: > imagine what this system (or a newer one, this is 2.5 years old) could > do if focused on only one account. > > And of course epidemic password reuse means that cracked passwords > are reasonably likely to work at multiple sites. > > And even if passwords aren't reused, there have now been so many > breaches at so many places resulting in so many disclosed passwords > that a discerning attacker could likely glean useful intelligence > by studying multiple password choices made by a target. (We're all > creatures of habit.) > > ---rsk > --------------------------------------------------------------------------- Peter Beckman Internet Guy beckman at angryox.com http://www.angryox.com/ --------------------------------------------------------------------------- From johns at sstar.com Wed May 27 23:18:17 2015 From: johns at sstar.com (John Souvestre) Date: Wed, 27 May 2015 18:18:17 -0500 Subject: gmail security is a joke In-Reply-To: References: <20150526160638.14758.qmail@ary.lan> <21862.1063.465196.824619@world.std.com> <20150527202033.GA26696@gsp.org> Message-ID: <015901d098d3$6b6c85a0$424590e0$@sstar.com> > I was thinking about using the last 2 digits of the year as the > cost factor, but that might not scale with hardware linearly. How about: 2 ^ (last 2 digits of year / 2) This would track per Moore's Law. John John Souvestre - New Orleans LA From faisal at snappytelecom.net Wed May 27 23:20:20 2015 From: faisal at snappytelecom.net (Faisal Imtiaz) Date: Wed, 27 May 2015 23:20:20 +0000 (GMT) Subject: Capacity/transit costs vs growth In-Reply-To: <556638D7.9020305@vaxination.ca> References: <556638D7.9020305@vaxination.ca> Message-ID: <547763742.414850.1432768820433.JavaMail.zimbra@snappytelecom.net> >>>>But if this happens over a period where there have been improvements in equipment/efficiency, then one would think the increase in costs would be less than 20%. The above hypothesis why imply that the 20% linear increase is not fair, vs directly making the case that the base rate, set in some point in the past is not fair/appropriate anymore ? Faisal Imtiaz Snappy Internet & Telecom ----- Original Message ----- > From: "Jean-Francois Mezei" > To: Nanog at nanog.org > Sent: Wednesday, May 27, 2015 5:36:23 PM > Subject: Capacity/transit costs vs growth > > > I am looking for some rough estimates of the ratio of capacity > (equipment) pricing declines versus average increase in end user capacity. > > For instance, say end user average capcity usage increases 50% over 3 > years, would the ISP's costs also increase by 50% ? Or would increased > efficency of equipment result in a 50% decrease in capacity costs > yielding roughly the same total cost to the service provider ? > > So I am looking are some sort of ratio of gross costs > increases/decreases relative to end user usage increase in usage over time. > > > > > Context: > > Wholesale services in Canada are priced linearly and there is a process > trying to convince the CRTC to review them ASAP. So if average use > grows from 1mbps during peak to 1.2mbps, we are looking at 20% increase > in costs in a linear pricing scheme. But if this happens over a period > where there have been improvements in equipment/efficiency, then one > would think the increase in costs would be less than 20%. > > So I am looking for any and all information that can help convince the > regulator that current linear increase is not right and needs a review. > > any help appreciated. > From jfmezei_nanog at vaxination.ca Wed May 27 23:54:57 2015 From: jfmezei_nanog at vaxination.ca (Jean-Francois Mezei) Date: Wed, 27 May 2015 19:54:57 -0400 Subject: Capacity/transit costs vs growth In-Reply-To: <547763742.414850.1432768820433.JavaMail.zimbra@snappytelecom.net> References: <556638D7.9020305@vaxination.ca> <547763742.414850.1432768820433.JavaMail.zimbra@snappytelecom.net> Message-ID: <55665951.7070206@vaxination.ca> On 15-05-27 19:20, Faisal Imtiaz wrote: > The above hypothesis why imply that the 20% linear increase is not fair, vs directly making the case that the base rate, set in some point in the past is not fair/appropriate anymore ? These rates cover aggregation between an end user's CO and a central CO where an ISP connects. For instance, a Toronto based ISP can serve all of Bell Canada's DSL footprint by connecting to the Adelaide Street CO in Toronto. BUT, Bell charges $1016 per 100mbps to carry traffic between that point and the CO serving an end user. (for Cable, I am not 100% sure if it include the fibre to the node, or just aggregation to the CMTS). there is a separate fixed fee for the "last mile" infrastructure. The point i am trying to make that that during the period where usage increase, the cost per gbps decreases, so it shgould not be a 1:1 relationship over time. Currently, the CRTC sets 1:1 relationship over 10 years. So having *rough* idea of decreases in per gbps of capacity over the years would help me make the point that the current rate structure is flawed. (I don't need precise at this point, just rough ideas). Different slant to question: when you move from 1gbps to 10gbps to 40gbps links, what sort of price/gnps reduction do you get ? 20% ? 30% ? From don at bowenvale.co.nz Thu May 28 00:09:22 2015 From: don at bowenvale.co.nz (Don Gould) Date: Thu, 28 May 2015 12:09:22 +1200 Subject: Atlanta Remote Hands needed for Server Move. Message-ID: <55665CB2.3000700@bowenvale.co.nz> I have half a dozen servers in the Netstream DC that I need moved to the Cyberwurx DC in Atlanta. I'm looking for some remote hands to assist with moving these machines. Cheers Don http://www.netstreamcom.net/ 200 Sandy Springs Place Atlanta, GA 30328 Cyberwurxhttps://cyberwurx.com/datacenter/ 55 Marietta Street -- Don Gould 31 Acheson Ave Mairehau Christchurch, New Zealand Ph: + 64 3 348 7235 Mobile: + 64 21 114 0699 Ph: +61 3 9111 1821 (Melb) From mysidia at gmail.com Thu May 28 00:07:30 2015 From: mysidia at gmail.com (Jimmy Hess) Date: Wed, 27 May 2015 19:07:30 -0500 Subject: gmail security is a joke In-Reply-To: References: <20150526160638.14758.qmail@ary.lan> <21862.1063.465196.824619@world.std.com> <20150527202033.GA26696@gsp.org> Message-ID: On Wed, May 27, 2015 at 6:04 PM, Peter Beckman wrote: [snip] > I was thinking about using the last 2 digits of the year as the cost > factor, but that might not scale with hardware linearly. It is strongly recommended that when used for password storage, the work factor for BCRYPT, SCRYPT, or PBKDF2 be hand-tuned based on the current best available consumer desktop computing hardware. Whenever it is manually adjusted; it should be tuned so that 1 password hash generation on a newly generated hash takes a minimum 500 milliseconds average at full throughput on the best current generally available consumer hardware. Or for an application where performance is more critical than security.... no less than 100ms on the server hardware. Today; I believe the baseline would be a workstation with 4 5th generation Intel i7 3.1GHz Quad-Core procs. And I would suggest SCrypt() with a hefty selection for required amount of RAM to compute the hash; in order to help foil attempts to accelerate a hash-breaking process using GPU or FPGA technology. > Bcrypt or PBKDF2 with random salts per password is really what anyone > storing passwords should be using today. > > Beckman -- -JH From rafael at gav.ufsc.br Thu May 28 00:10:03 2015 From: rafael at gav.ufsc.br (Rafael Possamai) Date: Wed, 27 May 2015 19:10:03 -0500 Subject: Capacity/transit costs vs growth In-Reply-To: <55665951.7070206@vaxination.ca> References: <556638D7.9020305@vaxination.ca> <547763742.414850.1432768820433.JavaMail.zimbra@snappytelecom.net> <55665951.7070206@vaxination.ca> Message-ID: If I understand your question correctly, the answer is: it depends. You can model the cost of delivering your service and keep track of three types of cost: fixed, variable and marginal. Here is a really good video that explains these: https://youtu.be/bBQVaRnHqLs You might find an industry average for certain economies of scale, but each system is so unique in it's cost structure that you have to model it from scratch. Just keep in mind that every model works with TRASH IN => TRASH OUT, so if you make the wrong assumptions, your answers won't be realistic. On Wed, May 27, 2015 at 6:54 PM, Jean-Francois Mezei < jfmezei_nanog at vaxination.ca> wrote: > On 15-05-27 19:20, Faisal Imtiaz wrote: > > > The above hypothesis why imply that the 20% linear increase is not fair, > vs directly making the case that the base rate, set in some point in the > past is not fair/appropriate anymore ? > > These rates cover aggregation between an end user's CO and a central CO > where an ISP connects. For instance, a Toronto based ISP can serve all > of Bell Canada's DSL footprint by connecting to the Adelaide Street CO > in Toronto. BUT, Bell charges $1016 per 100mbps to carry traffic > between that point and the CO serving an end user. (for Cable, I am not > 100% sure if it include the fibre to the node, or just aggregation to > the CMTS). > > there is a separate fixed fee for the "last mile" infrastructure. > > The point i am trying to make that that during the period where usage > increase, the cost per gbps decreases, so it shgould not be a 1:1 > relationship over time. Currently, the CRTC sets 1:1 relationship over > 10 years. > > So having *rough* idea of decreases in per gbps of capacity over the > years would help me make the point that the current rate structure is > flawed. (I don't need precise at this point, just rough ideas). > > > Different slant to question: > > when you move from 1gbps to 10gbps to 40gbps links, what sort of > price/gnps reduction do you get ? 20% ? 30% ? > > > > From don at bowenvale.co.nz Thu May 28 00:30:59 2015 From: don at bowenvale.co.nz (Don Gould) Date: Thu, 28 May 2015 12:30:59 +1200 Subject: Colo Capacity quote in Renton, WA 98057, USA needed Message-ID: <556661C3.2000403@bowenvale.co.nz> Hi, I have half a dozen servers in a DC in Renton, WA 98057, USA. I'm looking for quotes 7 RU with 100mbit PIR. I do need A and B side power. The pricing from my current provider has got out of hand and they have burnt the relationship. As a result I am interested in hearing from others who might be interested in servicing this small requirement. Cheers Don -- Don Gould 31 Acheson Ave Mairehau Christchurch, New Zealand Ph: + 64 3 348 7235 Mobile: + 64 21 114 0699 Ph: +61 3 9111 1821 (Melb) From glen.kent at gmail.com Thu May 28 01:15:44 2015 From: glen.kent at gmail.com (Glen Kent) Date: Thu, 28 May 2015 06:45:44 +0530 Subject: Predicting TCP throughput Message-ID: Hi, I am looking at deterministic ways (perhaps employing data science) to predict TCP throughput that i can expect between two end points. I am using the latency (RTT) and the packet loss as the parameters. Is there anything else that i can use to predict the throughput? A related question to this is; If i see an RTT of 150ms and packet loss of 0.01% between points A and B and the maximum throughput then between these as, say 250Mbps. Then can i say that i will *always* get the same (or in a close ballpark) throughput not matter what time of the day i run these tests. My points A and B can be virtual machines spawned on two different data centers, say Amazon Virgina and Amazon Tokyo? So we're talking about long distances here. What else besides the RTT and packet loss can affect my TCP throughput between two end points. I am assuming that the effects of a virtual machine overload would have direct bearing on the RTT and packet loss, and hence should cancel out. What i mean by this is that even if a VM is busy, then that might induce larger losses and increased RTT, and that would affect my TCP throughput. But then i already know what TCP throughput i get when i have a given RTT and loss, and hence should be able to predict it. Is there something that i am missing here? Thanks, Glen From faisal at snappytelecom.net Thu May 28 03:07:45 2015 From: faisal at snappytelecom.net (Faisal Imtiaz) Date: Thu, 28 May 2015 03:07:45 +0000 (GMT) Subject: Capacity/transit costs vs growth In-Reply-To: <55665951.7070206@vaxination.ca> References: <556638D7.9020305@vaxination.ca> <547763742.414850.1432768820433.JavaMail.zimbra@snappytelecom.net> <55665951.7070206@vaxination.ca> Message-ID: <723976488.416529.1432782465734.JavaMail.zimbra@snappytelecom.net> Telco's cost structure model is very different from Cable Co's. Additionally the way they are regulated is also very different. Based on the additional details you have shared, you are saying that Bell charges $1016/100meg of Colo to Colo Transport ? Now you also need to add a bit more info, like. What type of transport is this ? (Layer 1).. TDM (OC3/OCX) ? SONET ? or Ethernet ? Is this connectivity flat rate ? or distance sensitive ? Keep in mind that the Cost Efficiency in conjunction with Increase in Traffic is/has been only for Ethernet Transport.... not in the TDM or SONET.... >>> when you move from 1gbps to 10gbps to 40gbps links, what sort of price/gnps reduction do you get ? 20% ? 30% ? While the question may be simple, the answer is more of a What if type.... When you move from 1gbps Ethernet Switches, to 10gbps Ethernet Switches you can easily spend between $5,000 to $25,000 for each Ethernet Switch. So, if you have only 2gbps of traffic, i.e. 1gpbs infrastructure is out of capacity, you have the spend the money for 10gpbs switches, and the cost of the upgrade has to be justified via the increase in traffic of only 1gbs. I think you should be making the case of total Revenues generated due to increase in traffic to the same location, thus the justification of the need to reduce the per 100meg rate. I highly doubt if anyone here can give you any reasonable number on what is the cost of per 1G connection when using 10G infrastructure..simply because "10G infrastructure" has different meaning (cost wise) to different folks. I don't doubt for a moment that you can get consensus that 10gb infrastructure can move 10gbs of traffic at a lower per unit cost, but how much lower will be a very subjective number. Regards. Faisal Imtiaz Snappy Internet & Telecom 7266 SW 48 Street Miami, FL 33155 Tel: 305 663 5518 x 232 Help-desk: (305)663-5518 Option 2 or Email: Support at Snappytelecom.net ----- Original Message ----- > From: "Jean-Francois Mezei" > To: Nanog at nanog.org > Sent: Wednesday, May 27, 2015 7:54:57 PM > Subject: Re: Capacity/transit costs vs growth > > On 15-05-27 19:20, Faisal Imtiaz wrote: > > > The above hypothesis why imply that the 20% linear increase is not fair, vs > > directly making the case that the base rate, set in some point in the past > > is not fair/appropriate anymore ? > > These rates cover aggregation between an end user's CO and a central CO > where an ISP connects. For instance, a Toronto based ISP can serve all > of Bell Canada's DSL footprint by connecting to the Adelaide Street CO > in Toronto. BUT, Bell charges $1016 per 100mbps to carry traffic > between that point and the CO serving an end user. (for Cable, I am not > 100% sure if it include the fibre to the node, or just aggregation to > the CMTS). > > there is a separate fixed fee for the "last mile" infrastructure. > > The point i am trying to make that that during the period where usage > increase, the cost per gbps decreases, so it shgould not be a 1:1 > relationship over time. Currently, the CRTC sets 1:1 relationship over > 10 years. > > So having *rough* idea of decreases in per gbps of capacity over the > years would help me make the point that the current rate structure is > flawed. (I don't need precise at this point, just rough ideas). > > > Different slant to question: > > when you move from 1gbps to 10gbps to 40gbps links, what sort of > price/gnps reduction do you get ? 20% ? 30% ? > > > > From jared at puck.Nether.net Thu May 28 03:32:49 2015 From: jared at puck.Nether.net (Jared Mauch) Date: Wed, 27 May 2015 23:32:49 -0400 Subject: Capacity/transit costs vs growth In-Reply-To: <723976488.416529.1432782465734.JavaMail.zimbra@snappytelecom.net> References: <556638D7.9020305@vaxination.ca> <547763742.414850.1432768820433.JavaMail.zimbra@snappytelecom.net> <55665951.7070206@vaxination.ca> <723976488.416529.1432782465734.JavaMail.zimbra@snappytelecom.net> Message-ID: <20150528033249.GA10598@puck.nether.net> On Thu, May 28, 2015 at 03:07:45AM +0000, Faisal Imtiaz wrote: > Telco's cost structure model is very different from Cable Co's. Additionally the way they are regulated is also very different. > > Based on the additional details you have shared, you are saying that Bell charges $1016/100meg of Colo to Colo Transport ? > Now you also need to add a bit more info, like. > What type of transport is this ? (Layer 1).. TDM (OC3/OCX) ? SONET ? or Ethernet ? > Is this connectivity flat rate ? or distance sensitive ? > > Keep in mind that the Cost Efficiency in conjunction with Increase in Traffic is/has been only for Ethernet Transport.... > not in the TDM or SONET.... I would add here, some people face no incentive to modernize this equipment, and in fact they may lack an incentive at all due to the fact they are only 3 years into a 15 year capital plan, despite the fact that we're not still using a 7500 with your vip2-40 to operate a backbone these days, or even a GSR. There may be some accountant though who sees that unused asset and gives you a run for your money though. > >>> when you move from 1gbps to 10gbps to 40gbps links, what sort of price/gnps reduction do you get ? 20% ? 30% ? > > While the question may be simple, the answer is more of a What if type.... > > When you move from 1gbps Ethernet Switches, to 10gbps Ethernet Switches you can easily spend between $5,000 to $25,000 for each Ethernet Switch. > So, if you have only 2gbps of traffic, i.e. 1gpbs infrastructure is out of capacity, you have the spend the money for 10gpbs switches, and the cost of the upgrade has to be justified via the increase in traffic of only 1gbs. As mentioned above, there are some points where the scale and per unit costs make more sense. I'm not familar with the model in Canada but cost models SHOULD be revisited less than 10 years apart from each other. Most people are not going to sign a 10 year deal for IP transit, and if you still want to pay 1000/Mbit please contact me, I'll setup a LLC and resell you something quickly in the US. Most 1G hardware is inexpensive these days and you can find 'cheap' 10G hardware out there as well depending on what your use case is. Real routers tend to cost real money and can even cost more to power over the lifecycle than to purchase (depending on how long you are looking at). If everyone is picking up service from Bell at Front st in Toronto, you may be able to make the case that going from Windsor to Toronto doesn't make a lot of sense and you should be able to purchase/lease your own 10 or 100G backhaul between those areas to offset cost, either with a bell provided service or by rolling your own. > I highly doubt if anyone here can give you any reasonable number on what is the cost of per 1G connection when using 10G infrastructure..simply because "10G infrastructure" has different meaning (cost wise) to different folks. These usually take off when the 10G costs less than 10*1G. There should be some regular open bidding that occurs as part of the CRTC model allowing for resetting the regulated rate. It's way cheaper to reach the stadium from Front st than reaching Alert, NU. > I don't doubt for a moment that you can get consensus that 10gb infrastructure can move 10gbs of traffic at a lower per unit cost, but how much lower will be a very subjective number. This is important, unless there is an incentive for people to compete in the market, you see odd things occur. I live in an AT&T territory and their fiber goes within 1200 feet of my house but there are no services available. I could pay a local provider $50k to build fiber to me, but it's much cheaper to do something else (yay WISP). Unless there is some risk of business loss due to having a rate, there is no incentive for change. I await someone willing to issue a press release so Comcast or AT&T will take these territories without basic broadband and announce fiber services in Michigan. - jared -- Jared Mauch | pgp key available via finger from jared at puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine. From jfmezei_nanog at vaxination.ca Thu May 28 04:19:42 2015 From: jfmezei_nanog at vaxination.ca (Jean-Francois Mezei) Date: Thu, 28 May 2015 00:19:42 -0400 Subject: Capacity/transit costs vs growth In-Reply-To: <20150528033249.GA10598@puck.nether.net> References: <556638D7.9020305@vaxination.ca> <547763742.414850.1432768820433.JavaMail.zimbra@snappytelecom.net> <55665951.7070206@vaxination.ca> <723976488.416529.1432782465734.JavaMail.zimbra@snappytelecom.net> <20150528033249.GA10598@puck.nether.net> Message-ID: <5566975E.5010601@vaxination.ca> What I am looking for is the networking equivalent to Moore's law: "on average, every year, cost of 1gbps capacity goes down by x%" The immediate goal is to show that rates that are fixed for 10 years are not "just and reasonable" (text from the canadian Telecom Act) and need a review. In the case of Bell Canada, it carries PPPoE traffic from CO to the BRAS location on ethernet, and from the BRAS to the aggregation point for each ISP over L2TP (aka: IP based intranet). So the core is assume to be modern ethernet traveling on fibre. bell recently upgraded its BRAS from ERX 310s to ERX 320s (but claimed to the CRTC the 320s were only capable of 1gbps capacity, on which they were challenged as this inflated cost per gbps by a factor of roughly 80). For cablecos, it is MPLS from the CMTS to an aggregation point. Another aspect to demostrate is that with growing capacity purchases, the cost per gbps should go down. From andrew.william.smith at gmail.com Thu May 28 05:56:29 2015 From: andrew.william.smith at gmail.com (Andrew Smith) Date: Thu, 28 May 2015 00:56:29 -0500 Subject: Predicting TCP throughput In-Reply-To: References: Message-ID: You need to account for window size as well. You should also account for the details of the specific implementation of the TCP stack you are dealing with if you truly need a deterministic result. On Wed, May 27, 2015 at 8:15 PM, Glen Kent wrote: > Hi, > > I am looking at deterministic ways (perhaps employing data science) to > predict TCP throughput that i can expect between two end points. I am using > the latency (RTT) and the packet loss as the parameters. Is there anything > else that i can use to predict the throughput? > > A related question to this is; > > If i see an RTT of 150ms and packet loss of 0.01% between points A and B > and the maximum throughput then between these as, say 250Mbps. Then can i > say that i will *always* get the same (or in a close ballpark) throughput > not matter what time of the day i run these tests. > > My points A and B can be virtual machines spawned on two different data > centers, say Amazon Virgina and Amazon Tokyo? So we're talking about long > distances here. > > What else besides the RTT and packet loss can affect my TCP throughput > between two end points. I am assuming that the effects of a virtual machine > overload would have direct bearing on the RTT and packet loss, and hence > should cancel out. What i mean by this is that even if a VM is busy, then > that might induce larger losses and increased RTT, and that would affect my > TCP throughput. But then i already know what TCP throughput i get when i > have a given RTT and loss, and hence should be able to predict it. > > Is there something that i am missing here? > > Thanks, Glen > From Valdis.Kletnieks at vt.edu Thu May 28 06:34:01 2015 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Thu, 28 May 2015 02:34:01 -0400 Subject: Capacity/transit costs vs growth In-Reply-To: Your message of "Wed, 27 May 2015 17:36:23 -0400." <556638D7.9020305@vaxination.ca> References: <556638D7.9020305@vaxination.ca> Message-ID: <11338.1432794841@turing-police.cc.vt.edu> On Wed, 27 May 2015 17:36:23 -0400, Jean-Francois Mezei said: > For instance, say end user average capcity usage increases 50% over 3 > years, would the ISP's costs also increase by 50% ? Depends. If the current gear had enough capacity to absorb the additional 50%, the ISP's costs didn't change. You were blowing 6Gbits/sec down a 10G pipe, and now you're pushing 9, you don't care. On the other hand, if you were pushing 8 and now need to push 12, you may have just bought a very expensive forklift upgrade to 40G. Drastically oversimplified, of course. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From Valdis.Kletnieks at vt.edu Thu May 28 07:18:10 2015 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Thu, 28 May 2015 03:18:10 -0400 Subject: Predicting TCP throughput In-Reply-To: Your message of "Thu, 28 May 2015 06:45:44 +0530." References: Message-ID: <14269.1432797490@turing-police.cc.vt.edu> On Thu, 28 May 2015 06:45:44 +0530, Glen Kent said: > If i see an RTT of 150ms and packet loss of 0.01% between points A and B > and the maximum throughput then between these as, say 250Mbps. Then can i > say that i will *always* get the same (or in a close ballpark) throughput > not matter what time of the day i run these tests. Only if you control the network load across the entire path. As a simplified example, assume you did your test at 2AM and there's no other activity, there's a bottleneck 1Gbps link in the path, and you get 250Mbps. (yes, that result indicates probable misconfig, but bear with me.. :) You test again at 11AM, and now there's 7 other streams trying to pump 250Mbps across that link. All 8 should probably drop back to 125Mbps. For extra credit, factor in bufferbloat pushing your RTT through the roof under congestion, and similar misbehaviors.... Oh, and that 0.01% packet loss is going to play heck with tcp slow-start and opening the window - to quote RFC3649: This document proposes HighSpeed TCP, a modification to TCP's congestion control mechanism for use with TCP connections with large congestion windows. In a steady-state environment, with a packet loss rate p, the current Standard TCP's average congestion window is roughly 1.2/sqrt(p) segments. This places a serious constraint on the congestion windows that can be achieved by TCP in realistic environments. For example, for a Standard TCP connection with 1500- byte packets and a 100 ms round-trip time, achieving a steady-state throughput of 10 Gbps would require an average congestion window of 83,333 segments, and a packet drop rate of at most one congestion event every 5,000,000,000 packets (or equivalently, at most one congestion event every 1 2/3 hours). The average packet drop rate of at most 2*10^(-10) needed for full link utilization in this environment corresponds to a bit error rate of at most 2*10^(-14), and this is an unrealistic requirement for current networks. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From sam.oduor at gmail.com Thu May 28 08:31:48 2015 From: sam.oduor at gmail.com (Sam Oduor) Date: Thu, 28 May 2015 11:31:48 +0300 Subject: Colo Capacity quote in Renton, WA 98057, USA needed In-Reply-To: <556661C3.2000403@bowenvale.co.nz> References: <556661C3.2000403@bowenvale.co.nz> Message-ID: Hi Don Check out http://www.quotecolo.com/colocation/ ; you will enter the requirements inclusive the area you prefer. They will send you referrals and you can choose who to pick. Regards On Thu, May 28, 2015 at 3:30 AM, Don Gould wrote: > Hi, > > I have half a dozen servers in a DC in Renton, WA 98057, USA. > > I'm looking for quotes 7 RU with 100mbit PIR. I do need A and B side > power. > > The pricing from my current provider has got out of hand and they have > burnt the relationship. As a result I am interested in hearing from others > who might be interested in servicing this small requirement. > > Cheers Don > > > -- > Don Gould > 31 Acheson Ave > Mairehau > Christchurch, New Zealand > Ph: + 64 3 348 7235 > Mobile: + 64 21 114 0699 > Ph: +61 3 9111 1821 (Melb) > > > -- Samson Oduor From robert at ripe.net Thu May 28 09:29:31 2015 From: robert at ripe.net (Robert Kisteleki) Date: Thu, 28 May 2015 11:29:31 +0200 Subject: Password storage (was Re: gmail security is a joke) In-Reply-To: References: <20150526160638.14758.qmail@ary.lan> <21862.1063.465196.824619@world.std.com> <20150527202033.GA26696@gsp.org> Message-ID: <5566DFFB.9050109@ripe.net> > Bcrypt or PBKDF2 with random salts per password is really what anyone > storing passwords should be using today. Indeed. A while ago I had a brainfart and presented it in a draft: https://tools.ietf.org/html/draft-kistel-encrypted-password-storage-00 It seemed like a good idea at the time :-) It didn't gain much traction though. Robert From colton.conor at gmail.com Thu May 28 13:22:40 2015 From: colton.conor at gmail.com (Colton Conor) Date: Thu, 28 May 2015 08:22:40 -0500 Subject: 10Gb CPE In-Reply-To: References: Message-ID: Aren't these Brocade and Juniper solutions just switches? I thought the original poster was asking for a 10G CPE device? On Wed, May 27, 2015 at 2:12 PM, Cody Grosskopf wrote: > I also used brocade icx series for this. Depending on feature requirements > the juniper ex3300 might be cheaper. > > On Tue, May 26, 2015, 12:04 PM Chris Lane wrote: > > > We use Brocade ICX 6450s for this. > > > > -Chris > > > > On Tue, May 26, 2015 at 2:40 PM, Daniel Rohan wrote: > > > > > With the deluge of 10Gb X device recommendations, I thought I'd hit the > > > list with one more. Does anyone out there running 10Gb managed CPE > feel > > > like sharing their experiences? > > > > > > Our use case would be a managed endpoint that would allow for testing > > and > > > circuit verification while providing a layer 2 extension to our edge > gear > > > at the PoPs. > > > > > > We're hoping to find a cheap vendor-supplied solution- not homebrew. > > > > > > If so, which features have been important to you? > > > > > > Which vendors have good products? > > > > > > What price point? > > > > > > > > > Thanks, > > > > > > Dan > > > > > > > > > > > -- > > - Chris > > > From bross at pobox.com Thu May 28 13:58:06 2015 From: bross at pobox.com (Brandon Ross) Date: Thu, 28 May 2015 09:58:06 -0400 (EDT) Subject: Extra rooms Message-ID: I have 2 extra rooms up for grabs at the St. Francis, checking in on Saturday and out on Thursday under the NANOG rate/room block. First come, first served if you want them, send me the full name of the person(s) that the room should go under and contact info. -- Brandon Ross Yahoo & AIM: BrandonNRoss +1-404-635-6667 ICQ: 2269442 Skype: brandonross Schedule a meeting: http://www.doodle.com/bross From morrowc.lists at gmail.com Thu May 28 14:08:44 2015 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Thu, 28 May 2015 10:08:44 -0400 Subject: Password storage (was Re: gmail security is a joke) In-Reply-To: <5566DFFB.9050109@ripe.net> References: <20150526160638.14758.qmail@ary.lan> <21862.1063.465196.824619@world.std.com> <20150527202033.GA26696@gsp.org> <5566DFFB.9050109@ripe.net> Message-ID: On Thu, May 28, 2015 at 5:29 AM, Robert Kisteleki wrote: > >> Bcrypt or PBKDF2 with random salts per password is really what anyone >> storing passwords should be using today. > > Indeed. A while ago I had a brainfart and presented it in a draft: > https://tools.ietf.org/html/draft-kistel-encrypted-password-storage-00 > > It seemed like a good idea at the time :-) It didn't gain much traction though. I get the feeling that, along with things like 'email address verification' in javascript form things, passwd storage and management is something done via a few (or a bunch of crappy home-grown) code bases. Seems like 'find the common/most-used' ones and fix them would get some mileage? I don't imagine that 'dlink' (for example) is big on following rfc stuff for their web-interface programming? (well, at least for things like 'how should we store passwds?') From lnguyen at opsource.net Thu May 28 14:34:44 2015 From: lnguyen at opsource.net (Luan Nguyen) Date: Thu, 28 May 2015 10:34:44 -0400 Subject: AWS Elastic IP architecture Message-ID: Hi folks, Anyone knows what is used for the AWS Elastic IP? is it LISP? Thanks. Regards, -lmn From mike at mtcc.com Thu May 28 14:41:46 2015 From: mike at mtcc.com (Michael Thomas) Date: Thu, 28 May 2015 07:41:46 -0700 Subject: Password storage (was Re: gmail security is a joke) In-Reply-To: <5566DFFB.9050109@ripe.net> References: <20150526160638.14758.qmail@ary.lan> <21862.1063.465196.824619@world.std.com> <20150527202033.GA26696@gsp.org> <5566DFFB.9050109@ripe.net> Message-ID: <5567292A.1080105@mtcc.com> On 05/28/2015 02:29 AM, Robert Kisteleki wrote: >> Bcrypt or PBKDF2 with random salts per password is really what anyone >> storing passwords should be using today. > Indeed. A while ago I had a brainfart and presented it in a draft: > https://tools.ietf.org/html/draft-kistel-encrypted-password-storage-00 > > It seemed like a good idea at the time :-) It didn't gain much traction though. > > Or you could choose to not store any form of password at all on the server: https://datatracker.ietf.org/doc/rfc7486/ Mike From cb.list6 at gmail.com Thu May 28 15:00:11 2015 From: cb.list6 at gmail.com (Ca By) Date: Thu, 28 May 2015 08:00:11 -0700 Subject: AWS Elastic IP architecture In-Reply-To: References: Message-ID: On Thu, May 28, 2015 at 7:34 AM, Luan Nguyen wrote: > Hi folks, > Anyone knows what is used for the AWS Elastic IP? is it LISP? > > AWS does not really talk about things like this, but i highly doubt it is LISP. > Thanks. > Regards, > -lmn > From morrowc.lists at gmail.com Thu May 28 15:30:15 2015 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Thu, 28 May 2015 11:30:15 -0400 Subject: AWS Elastic IP architecture In-Reply-To: References: Message-ID: On Thu, May 28, 2015 at 11:00 AM, Ca By wrote: > On Thu, May 28, 2015 at 7:34 AM, Luan Nguyen wrote: > >> Hi folks, >> Anyone knows what is used for the AWS Elastic IP? is it LISP? >> >> > AWS does not really talk about things like this, but i highly doubt it is > LISP. i sort of doesn't matter right? it is PROBABLY some form of encapsulation (like gre, ip-in-ip, lisp, mpls, vpls, etc) ... something to remove the 'internal ip network' from what is routed in a datacenter and what is routed externally on the tubes. Maybe a better question: "Why would lisp matter here?" (what makes lisp the thing you grabbed at as opposed to any of the other possible encap options?) From elf at ubertel.net Thu May 28 15:59:57 2015 From: elf at ubertel.net (Michael Helmeste) Date: Thu, 28 May 2015 15:59:57 +0000 Subject: AWS Elastic IP architecture In-Reply-To: References: Message-ID: > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Christopher > Morrow > Subject: Re: AWS Elastic IP architecture > [...] > i sort of doesn't matter right? it is PROBABLY some form of encapsulation > (like gre, ip-in-ip, lisp, mpls, vpls, etc) ... > [...] I don't know how the public blocks get to the datacenter (e.g. whether they are using MPLS) but after that I think it is pretty straightforward. All of the VMs have only one IPv4 address assigned out of 10/8. This doesn't change when you attach an Elastic IP to them. All that is happening is that they have some NAT device somewhere (maybe even just a redundant pair of VMs?) that has a block of public IPs assigned to it and they are static NAT'ing the Elastic IP to the VM. They control the allocation of the Elastic IPs, so they just pick one that is routed out of that datacenter already. They probably don't need to do anything out of the ordinary to get it there. (See: http://aws.amazon.com/articles/1346 ) From morrowc.lists at gmail.com Thu May 28 17:03:30 2015 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Thu, 28 May 2015 13:03:30 -0400 Subject: AWS Elastic IP architecture In-Reply-To: References: Message-ID: On Thu, May 28, 2015 at 11:59 AM, Michael Helmeste wrote: >> -----Original Message----- >> From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Christopher >> Morrow >> Subject: Re: AWS Elastic IP architecture >> [...] >> i sort of doesn't matter right? it is PROBABLY some form of encapsulation >> (like gre, ip-in-ip, lisp, mpls, vpls, etc) ... >> [...] > > I don't know how the public blocks get to the datacenter (e.g. whether they are using MPLS) but after that I think it is pretty straightforward. All of the VMs have only one IPv4 address assigned out of 10/8. This doesn't change when you attach an Elastic IP to them. > right, so they encap somwhere after between 'tubez' and 'vm'. and likely have a simple 'swap the ip header' function somewhere before the vm as well. > All that is happening is that they have some NAT device somewhere (maybe even just a redundant pair of VMs?) that has a block of public IPs assigned to it and they i'd question scalability of that sort of thing... but sure, sounds like a reasonable model to think about. From morrowc.lists at gmail.com Thu May 28 17:08:32 2015 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Thu, 28 May 2015 13:08:32 -0400 Subject: AWS Elastic IP architecture In-Reply-To: References: Message-ID: On Thu, May 28, 2015 at 11:44 AM, Luan Nguyen (CBU) wrote: > What I am trying to get at is yeah, you still need the l2 extension > encapsulation, but on top you need something for disaster recovery, machines > mobility between data centers, sort of like Vshield Edge using NAT ? you can probably what the vm mobilty looks like is a change in the L2 path, right? why make it anymore complicated than that? inside a single availability domain I would expect the L2 domain a vm sees doesn't change, even if the VM itself is moved from physical machine to physical machine. making it more complex at the vm level is probably a bunch of work that doesn't have to happen. > change the NAT pool and update the DNS record, but the internal would remain that sounds like a bunch of work though, which I don't think is really necessary. I'm just a plumber, though so I don't actually know what anyone does with this stuff. > the same no matter where you move it to. LISP seems like a simple > solution?so as specific host route injection, which for enterprise shouldn?t lisp wasn't really finalized (still sort of isn't) when aws/ec2 started going like gang busters. They might have changed technology under the hood, but it doesn't seem like they would have had to (not in a drastic 'change encap type' sort of way at least). > be much of a problem, but DRaaS cloud provider, this could ballooning the > routing table pretty quickly. how so? does the external and internal view from the vm have to be the same? do the public /32's have to be individually routed ? inside what scope at the datacenter? > What does Google use? :) no idea, probably rabbits with different colored carrots? From blair.trosper at gmail.com Thu May 28 17:14:12 2015 From: blair.trosper at gmail.com (Blair Trosper) Date: Thu, 28 May 2015 12:14:12 -0500 Subject: AWS Elastic IP architecture In-Reply-To: References: Message-ID: I can tell you that EC2 Classic and VPC EIPs come from separate netblocks...if that gives you any hints whatsoever. There's no crossover between the two platforms in IP space. On Thu, May 28, 2015 at 12:08 PM, Christopher Morrow < morrowc.lists at gmail.com> wrote: > On Thu, May 28, 2015 at 11:44 AM, Luan Nguyen (CBU) > wrote: > > What I am trying to get at is yeah, you still need the l2 extension > > encapsulation, but on top you need something for disaster recovery, > machines > > mobility between data centers, sort of like Vshield Edge using NAT ? you > can > > probably what the vm mobilty looks like is a change in the L2 path, > right? why make it anymore complicated than that? inside a single > availability domain I would expect the L2 domain a vm sees doesn't > change, even if the VM itself is moved from physical machine to > physical machine. > > making it more complex at the vm level is probably a bunch of work > that doesn't have to happen. > > > change the NAT pool and update the DNS record, but the internal would > remain > > that sounds like a bunch of work though, which I don't think is really > necessary. I'm just a plumber, though so I don't actually know what > anyone does with this stuff. > > > the same no matter where you move it to. LISP seems like a simple > > solution?so as specific host route injection, which for enterprise > shouldn?t > > lisp wasn't really finalized (still sort of isn't) when aws/ec2 > started going like gang busters. They might have changed technology > under the hood, but it doesn't seem like they would have had to (not > in a drastic 'change encap type' sort of way at least). > > > be much of a problem, but DRaaS cloud provider, this could ballooning the > > routing table pretty quickly. > > how so? does the external and internal view from the vm have to be the > same? do the public /32's have to be individually routed ? inside what > scope at the datacenter? > > > What does Google use? :) > > no idea, probably rabbits with different colored carrots? > From elf at ubertel.net Thu May 28 18:39:59 2015 From: elf at ubertel.net (Michael Helmeste) Date: Thu, 28 May 2015 18:39:59 +0000 Subject: AWS Elastic IP architecture In-Reply-To: References: Message-ID: > -----Original Message----- > From: christopher.morrow at gmail.com > Subject: Re: AWS Elastic IP architecture > > [...] > > All that is happening is that they have some NAT device somewhere > > (maybe even just a redundant pair of VMs?) that has a block of public > > IPs assigned to it and they > > i'd question scalability of that sort of thing... but sure, sounds like a > reasonable model to think about. I agree it appears ugly from a traditional network service provider perspective, but to my understanding much of the large scale cloud stuff is built using the cheapest, dumbest switching you can find and as little rich L3 routing gear (e.g. ASR/MX) as you can get away with. The more functionality you can pack into software (with the universal building block being a VM), the less you have to worry about buying network hardware to any particular requirement other than "forwards Ethernet most of the time." It gives more control and agility to the developers of the platform, and spending a few gigabytes of RAM for every /23 and adding a little more latency and jitter ultimately becomes an economical trade off. You can also move the network stuff up to the hypervisor layer (which I am sure they have done for things like Security Groups), but it makes rolling out updates harder and increases the general hack-level. From morrowc.lists at gmail.com Thu May 28 18:54:08 2015 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Thu, 28 May 2015 14:54:08 -0400 Subject: AWS Elastic IP architecture In-Reply-To: References: Message-ID: On Thu, May 28, 2015 at 2:39 PM, Michael Helmeste wrote: > and spending a few gigabytes of RAM for every /23 it's not clear to me that you need ram at all for this... there are multiple dimensions to the scaling problem I was aiming at, this is but one of them. anyway, unless an EC2/aws/etc person speaks up I bet we can 'conjecturebate'(tm) forever without success. From octalnanog at alvarezp.org Wed May 27 05:16:01 2015 From: octalnanog at alvarezp.org (Octavio Alvarez) Date: Tue, 26 May 2015 22:16:01 -0700 Subject: gmail security is a joke In-Reply-To: <312D54C4-EC72-4A3F-87FC-357AFA61D04A@delong.com> References: <5564829E.1000006@truemetal.org> <20150526152246.GA12876@pob.ytti.fi> <312D54C4-EC72-4A3F-87FC-357AFA61D04A@delong.com> Message-ID: <55655311.3020403@alvarezp.org> On 05/26/2015 08:44 AM, Owen DeLong wrote: > I think opt-out of password recovery choices on a line-item basis is > not a bad concept. > > For example, I?d want to opt out of recovery with account creation > date. If anyone knows the date my gmail account was created, they > most certainly aren?t me. > > OTOH, recovery by receiving a token at a previously registered > alternate email address seems relatively secure to me and I wouldn?t > want to opt out of that. > > (( many more snipped )) I would definitely opt-out from any kind of "secret questions" that I couldn't type by myself. Many many sites still think this is a good idea. Best regards. From farhan at cyber.net.pk Wed May 27 18:48:19 2015 From: farhan at cyber.net.pk (Farhan Ali Khan) Date: Wed, 27 May 2015 23:48:19 +0500 Subject: looking glass software In-Reply-To: <556595A0.8030806@seacom.mu> Message-ID: Hello Bogdan, ?have a look?http://freecode.com/projects/lg/ ?it supports IOS, Junos but doesnt support IOS XR if you are comfortable with this one let me know ill try to assist you ?to modify the code. i never tried but i do believe with some modification same tool can also work with huawei , nortel any other CLIs as well Good Day? Farhan Khan On 27/May/15 06:52, Bogdan wrote: > hello > > what software do you use for looking glass. for cisco ios and ios-xr? > i use the old cougar/version6.net for ios, but ios-xr is not supported. > i came across https://github.com/tmshlvck/ulg/ but did't installed yet. > are there any other interesting lg's out there? That's the one we use, but we run it against IOS. Should also work for IOS XE. I think I've seen some folk use it for Junos as well. Mark. From blair.trosper at gmail.com Thu May 28 19:09:39 2015 From: blair.trosper at gmail.com (Blair Trosper) Date: Thu, 28 May 2015 14:09:39 -0500 Subject: gmail security is a joke In-Reply-To: <55655311.3020403@alvarezp.org> References: <5564829E.1000006@truemetal.org> <20150526152246.GA12876@pob.ytti.fi> <312D54C4-EC72-4A3F-87FC-357AFA61D04A@delong.com> <55655311.3020403@alvarezp.org> Message-ID: Somewhat in the weeds here, but I still find it odd/curious that Google is still using SHA-1 fingerprinted SSL certificates. Weren't they making a big deal of pushing SHA-2 fingerprinted SSL certs a while back? On Wed, May 27, 2015 at 12:16 AM, Octavio Alvarez wrote: > On 05/26/2015 08:44 AM, Owen DeLong wrote: > >> I think opt-out of password recovery choices on a line-item basis is >> not a bad concept. >> >> For example, I?d want to opt out of recovery with account creation >> date. If anyone knows the date my gmail account was created, they >> most certainly aren?t me. >> >> OTOH, recovery by receiving a token at a previously registered >> alternate email address seems relatively secure to me and I wouldn?t >> want to opt out of that. >> >> (( many more snipped )) >> > > I would definitely opt-out from any kind of "secret questions" that I > couldn't type by myself. > > Many many sites still think this is a good idea. > > Best regards. > -- Blair Trosper p.g.a. S2 Entertainment Partners Desk: 469-333-8008 Cell: 512-619-8133 Agent/Rep: WME (Los Angeles, CA) - 310-248-2000 PR/Manager: BORG (Dallas, TX) - 844-THE-BORG From bill at herrin.us Thu May 28 19:13:37 2015 From: bill at herrin.us (William Herrin) Date: Thu, 28 May 2015 15:13:37 -0400 Subject: gmail security is a joke In-Reply-To: <55655311.3020403@alvarezp.org> References: <5564829E.1000006@truemetal.org> <20150526152246.GA12876@pob.ytti.fi> <312D54C4-EC72-4A3F-87FC-357AFA61D04A@delong.com> <55655311.3020403@alvarezp.org> Message-ID: On Wed, May 27, 2015 at 1:16 AM, Octavio Alvarez wrote: > I would definitely opt-out from any kind of "secret questions" that I > couldn't type by myself. > > Many many sites still think this is a good idea. My first dog's name was a random and unpronounceable 30-character string. -Bill -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: From youssef at 720.fr Thu May 28 19:24:36 2015 From: youssef at 720.fr (Youssef Bengelloun-Zahr) Date: Thu, 28 May 2015 21:24:36 +0200 Subject: looking glass software In-Reply-To: References: Message-ID: <797634D3-0832-4320-B169-250B3FE419FC@720.fr> Hello, Anyone that would know of an LG that would work with recent Brocade gear ? Best regards. > Le 27 mai 2015 ? 20:48, "Farhan Ali Khan" a ?crit : > > Hello Bogdan, > have a look http://freecode.com/projects/lg/ it supports IOS, > Junos but doesnt support IOS XR if you are comfortable with this one > let me know ill try to assist you to modify the code. > i never tried but i do believe with some modification same tool can > also work with huawei , nortel any other CLIs as well > > Good Day > Farhan Khan > >> On 27/May/15 06:52, Bogdan wrote: >> hello >> >> what software do you use for looking glass. for cisco ios and > ios-xr? >> i use the old cougar/version6.net for ios, but ios-xr is not > supported. >> i came across https://github.com/tmshlvck/ulg/ but did't installed > yet. >> are there any other interesting lg's out there? > > That's the one we use, but we run it against IOS. Should also work > for > IOS XE. > > I think I've seen some folk use it for Junos as well. > > Mark. > From blair.trosper at gmail.com Thu May 28 19:42:33 2015 From: blair.trosper at gmail.com (Blair Trosper) Date: Thu, 28 May 2015 14:42:33 -0500 Subject: looking glass software In-Reply-To: <797634D3-0832-4320-B169-250B3FE419FC@720.fr> References: <797634D3-0832-4320-B169-250B3FE419FC@720.fr> Message-ID: You can alway try Hurricane's: http://lg.he.net On Thu, May 28, 2015 at 2:24 PM, Youssef Bengelloun-Zahr wrote: > Hello, > > Anyone that would know of an LG that would work with recent Brocade gear ? > > Best regards. > > > > > Le 27 mai 2015 ? 20:48, "Farhan Ali Khan" a ?crit > : > > > > Hello Bogdan, > > have a look http://freecode.com/projects/lg/ it supports IOS, > > Junos but doesnt support IOS XR if you are comfortable with this one > > let me know ill try to assist you to modify the code. > > i never tried but i do believe with some modification same tool can > > also work with huawei , nortel any other CLIs as well > > > > Good Day > > Farhan Khan > > > >> On 27/May/15 06:52, Bogdan wrote: > >> hello > >> > >> what software do you use for looking glass. for cisco ios and > > ios-xr? > >> i use the old cougar/version6.net for ios, but ios-xr is not > > supported. > >> i came across https://github.com/tmshlvck/ulg/ but did't installed > > yet. > >> are there any other interesting lg's out there? > > > > That's the one we use, but we run it against IOS. Should also work > > for > > IOS XE. > > > > I think I've seen some folk use it for Junos as well. > > > > Mark. > > > -- Blair Trosper p.g.a. S2 Entertainment Partners Desk: 469-333-8008 Cell: 512-619-8133 Agent/Rep: WME (Los Angeles, CA) - 310-248-2000 PR/Manager: BORG (Dallas, TX) - 844-THE-BORG From jwbensley at gmail.com Thu May 28 20:02:10 2015 From: jwbensley at gmail.com (James Bensley) Date: Thu, 28 May 2015 21:02:10 +0100 Subject: Capacity/transit costs vs growth In-Reply-To: <5566975E.5010601@vaxination.ca> References: <556638D7.9020305@vaxination.ca> <547763742.414850.1432768820433.JavaMail.zimbra@snappytelecom.net> <55665951.7070206@vaxination.ca> <723976488.416529.1432782465734.JavaMail.zimbra@snappytelecom.net> <20150528033249.GA10598@puck.nether.net> <5566975E.5010601@vaxination.ca> Message-ID: On 28 May 2015 at 05:19, Jean-Francois Mezei wrote: > What I am looking for is the networking equivalent to Moore's law: > > "on average, every year, cost of 1gbps capacity goes down by x%" This sort of information is out there for things like transit prices, since they are more common shared in public... http://drpeering.net/white-papers/Internet-Transit-Pricing-Historical-And-Projected.php If you can just aggregate some historical pricing data for private interconnects and wholesale services you should be easily able to show this (famous last words!). James. From gmazoyer at gravitons.in Thu May 28 20:24:36 2015 From: gmazoyer at gravitons.in (Guillaume Mazoyer) Date: Thu, 28 May 2015 22:24:36 +0200 Subject: looking glass software In-Reply-To: <55654D77.9070803@shoshon.ro> References: <55654D77.9070803@shoshon.ro> Message-ID: Hello, I have developed this looking glass software for me (at home and at work) [1]. It has been tested with Juniper JunOS, Cisco IOS, BIRD and Quagga. And I'm always looking for feedback to improve it. Hope it can be of use. [1] https://github.com/respawner/looking-glass On Wed, May 27, 2015 at 6:52 AM, Bogdan wrote: > hello > > what software do you use for looking glass. for cisco ios and ios-xr? > i use the old cougar/version6.net for ios, but ios-xr is not supported. > i came across https://github.com/tmshlvck/ulg/ but did't installed yet. > are there any other interesting lg's out there? > thanks. > -- > Bogdan -- Guillaume Mazoyer - https://respawner.fr/ From ag4ve.us at gmail.com Thu May 28 20:36:45 2015 From: ag4ve.us at gmail.com (shawn wilson) Date: Thu, 28 May 2015 16:36:45 -0400 Subject: Password storage (was Re: gmail security is a joke) In-Reply-To: References: <20150526160638.14758.qmail@ary.lan> <21862.1063.465196.824619@world.std.com> <20150527202033.GA26696@gsp.org> <5566DFFB.9050109@ripe.net> Message-ID: On May 28, 2015 10:11 AM, "Christopher Morrow" wrote: > > On Thu, May 28, 2015 at 5:29 AM, Robert Kisteleki wrote: > > > >> Bcrypt or PBKDF2 with random salts per password is really what anyone > >> storing passwords should be using today. > > One thing to remember is the hardware determines number of rounds. So while my LUKS (PBKDF2) pass on my laptop or servers have a few 10k rounds, that same pass on a Pi or so would only have 1k rounds (minimum rec). > > I get the feeling that, along with things like 'email address > verification' in javascript form things, passwd storage and management > is something done via a few (or a bunch of crappy home-grown) code > bases. Not generally passwords per se but session tokens and the like, sure (almost as bad). > > Seems like 'find the common/most-used' ones and fix them would get > some mileage? I don't imagine that 'dlink' (for example) is big on > following rfc stuff for their web-interface programming? (well, at > least for things like 'how should we store passwds?') Heh, I started on a fuzzer that'd take a few strings and run them through recipes (base 32/64, rot, xor 1 or 0, etc) and try to find human strings along the way. If multiple strings match a recipe, you can generate your own sessions. From SNaslund at medline.com Thu May 28 21:18:02 2015 From: SNaslund at medline.com (Naslund, Steve) Date: Thu, 28 May 2015 21:18:02 +0000 Subject: International MPLS VPN recommendation Message-ID: <9578293AE169674F9A048B2BC9A081B401C04F8CD4@MUNPRDMBXA1.medline.com> Hi, I am looking for some recommendations of carriers to talk to for MPLS VPN connections in the 1 - 10 mbps range between the following areas. Germany, France, United States, China, Japan, Australia, and India. For now I am just looking for carriers known to be good in terms of price/performance and ability to execute. Please feel free to contact me off list or on the list if you think that would be useful to anyone else here. Who's your favorite? Steven Naslund Senior Network Engineer Medline Industries Inc. snaslund at medline.com From rsk at gsp.org Thu May 28 21:18:55 2015 From: rsk at gsp.org (Rich Kulawiec) Date: Thu, 28 May 2015 17:18:55 -0400 Subject: gmail security is a joke In-Reply-To: References: <5564829E.1000006@truemetal.org> <20150526152246.GA12876@pob.ytti.fi> <312D54C4-EC72-4A3F-87FC-357AFA61D04A@delong.com> <55655311.3020403@alvarezp.org> Message-ID: <20150528211855.GA21216@gsp.org> On Thu, May 28, 2015 at 03:13:37PM -0400, William Herrin wrote: > On Wed, May 27, 2015 at 1:16 AM, Octavio Alvarez > wrote: > > I would definitely opt-out from any kind of "secret questions" that I > > couldn't type by myself. > > > > Many many sites still think this is a good idea. > > My first dog's name was a random and unpronounceable 30-character string. I think this (Bill's) is a very good practice. It's not that difficult to enumerate the name of every pro sports team in the US, the 100 most popular dog names, the 200 most common street names, etc. This attack can be mitigated by limiting attempts...but of course if that's done, then it's possible for an attacker to lock out the real owner by just hammering away constantly using assorted botnet hosts. ---rsk From jamesl at mythostech.com Fri May 29 00:11:10 2015 From: jamesl at mythostech.com (James Laszko) Date: Fri, 29 May 2015 00:11:10 +0000 Subject: West Coast FIOS disconnect Message-ID: <8BAE0A66-1350-4FBE-9C82-A06274C368D3@mythostech.com> Is anyone else seeing wide spread Verizon FIOS disconnections from the world? Started about an hour ago and extremely spotty. Seeing hundreds of customers with impacted connections that die at the LAX Verizon-GNI hub. James Laszko Mythos Technology Inc Sent from my iPhone From billpatterson84 at gmail.com Fri May 29 00:40:16 2015 From: billpatterson84 at gmail.com (Bill Patterson) Date: Thu, 28 May 2015 20:40:16 -0400 Subject: West Coast FIOS disconnect In-Reply-To: <8BAE0A66-1350-4FBE-9C82-A06274C368D3@mythostech.com> References: <8BAE0A66-1350-4FBE-9C82-A06274C368D3@mythostech.com> Message-ID: Seems to be a pretty widespread Verizon issue along the west coast and majority of the eastern US, at least according to down detector. On May 28, 2015 8:12 PM, "James Laszko" wrote: > Is anyone else seeing wide spread Verizon FIOS disconnections from the > world? Started about an hour ago and extremely spotty. Seeing hundreds of > customers with impacted connections that die at the LAX Verizon-GNI hub. > > > James Laszko > Mythos Technology Inc > > Sent from my iPhone From rvandolson at esri.com Fri May 29 00:45:46 2015 From: rvandolson at esri.com (Ray Van Dolson) Date: Thu, 28 May 2015 17:45:46 -0700 Subject: West Coast FIOS disconnect In-Reply-To: References: <8BAE0A66-1350-4FBE-9C82-A06274C368D3@mythostech.com> Message-ID: <20150529004546.GA1843@esri.com> Had a BGP blip with our Verizon circuit around 1620 PDT. On Thu, May 28, 2015 at 08:40:16PM -0400, Bill Patterson wrote: > Seems to be a pretty widespread Verizon issue along the west coast and > majority of the eastern US, at least according to down detector. > On May 28, 2015 8:12 PM, "James Laszko" wrote: > > > Is anyone else seeing wide spread Verizon FIOS disconnections from the > > world? Started about an hour ago and extremely spotty. Seeing hundreds of > > customers with impacted connections that die at the LAX Verizon-GNI hub. > > > > > > James Laszko > > Mythos Technology Inc > > > > Sent from my iPhone From jamesl at mythostech.com Fri May 29 00:51:51 2015 From: jamesl at mythostech.com (James Laszko) Date: Fri, 29 May 2015 00:51:51 +0000 Subject: West Coast FIOS disconnect In-Reply-To: <20150529004546.GA1843@esri.com> References: <8BAE0A66-1350-4FBE-9C82-A06274C368D3@mythostech.com> <20150529004546.GA1843@esri.com> Message-ID: <8078ED370ADA824281219A7B5BADC39B6C684A6F@MBX023-W1-CA-4.exch023.domain.local> It's really odd - we seem to have a decent amount of connectivity restored with customers however traceroutes and pings are all failing to sites that are accessible via HTTP/HTTPS...... James -----Original Message----- From: Ray Van Dolson [mailto:rvandolson at esri.com] Sent: Thursday, May 28, 2015 5:46 PM To: Bill Patterson Cc: James Laszko; nanog Subject: Re: West Coast FIOS disconnect Had a BGP blip with our Verizon circuit around 1620 PDT. On Thu, May 28, 2015 at 08:40:16PM -0400, Bill Patterson wrote: > Seems to be a pretty widespread Verizon issue along the west coast and > majority of the eastern US, at least according to down detector. > On May 28, 2015 8:12 PM, "James Laszko" wrote: > > > Is anyone else seeing wide spread Verizon FIOS disconnections from > > the world? Started about an hour ago and extremely spotty. Seeing > > hundreds of customers with impacted connections that die at the LAX Verizon-GNI hub. > > > > > > James Laszko > > Mythos Technology Inc > > > > Sent from my iPhone From mike at mtcc.com Fri May 29 02:01:54 2015 From: mike at mtcc.com (Michael Thomas) Date: Thu, 28 May 2015 19:01:54 -0700 Subject: West Coast FIOS disconnect In-Reply-To: <8078ED370ADA824281219A7B5BADC39B6C684A6F@MBX023-W1-CA-4.exch023.domain.local> References: <8BAE0A66-1350-4FBE-9C82-A06274C368D3@mythostech.com> <20150529004546.GA1843@esri.com> <8078ED370ADA824281219A7B5BADC39B6C684A6F@MBX023-W1-CA-4.exch023.domain.local> Message-ID: <5567C892.5010106@mtcc.com> It's still down here in SF. Mike On 05/28/2015 05:51 PM, James Laszko wrote: > It's really odd - we seem to have a decent amount of connectivity restored with customers however traceroutes and pings are all failing to sites that are accessible via HTTP/HTTPS...... > > > James > > > -----Original Message----- > From: Ray Van Dolson [mailto:rvandolson at esri.com] > Sent: Thursday, May 28, 2015 5:46 PM > To: Bill Patterson > Cc: James Laszko; nanog > Subject: Re: West Coast FIOS disconnect > > Had a BGP blip with our Verizon circuit around 1620 PDT. > > On Thu, May 28, 2015 at 08:40:16PM -0400, Bill Patterson wrote: >> Seems to be a pretty widespread Verizon issue along the west coast and >> majority of the eastern US, at least according to down detector. >> On May 28, 2015 8:12 PM, "James Laszko" wrote: >> >>> Is anyone else seeing wide spread Verizon FIOS disconnections from >>> the world? Started about an hour ago and extremely spotty. Seeing >>> hundreds of customers with impacted connections that die at the LAX Verizon-GNI hub. >>> >>> >>> James Laszko >>> Mythos Technology Inc >>> >>> Sent from my iPhone From jmooney.lists+nanog at gmail.com Fri May 29 04:08:27 2015 From: jmooney.lists+nanog at gmail.com (Jeremy Mooney) Date: Thu, 28 May 2015 23:08:27 -0500 Subject: AWS Elastic IP architecture In-Reply-To: References: Message-ID: At re:Invent they started releasing a surprising amount of detail on how they designed the VPC networking (both layering/encapsulation itself and distributing routing data). Like Michael mentioned, they really stuff as much as possible into software on the VM hosts. That presentation is https://www.youtube.com/watch?v=Zd5hsL-JNY4 While looking for that video I stumbled on a couple others that look along those same lines: https://www.youtube.com/watch?v=HexrVfuIY1k (all the connectivity options) https://www.youtube.com/watch?v=YoX_frLHbEs (talks about public IP options) On Thu, May 28, 2015 at 9:34 AM, Luan Nguyen wrote: > Hi folks, > Anyone knows what is used for the AWS Elastic IP? is it LISP? > > Thanks. > Regards, > -lmn > From jabley at hopcount.ca Fri May 29 06:42:45 2015 From: jabley at hopcount.ca (Joe Abley) Date: Fri, 29 May 2015 07:42:45 +0100 Subject: gmail security is a joke In-Reply-To: <20150528211855.GA21216@gsp.org> References: <5564829E.1000006@truemetal.org> <20150526152246.GA12876@pob.ytti.fi> <312D54C4-EC72-4A3F-87FC-357AFA61D04A@delong.com> <55655311.3020403@alvarezp.org> <20150528211855.GA21216@gsp.org> Message-ID: On 28 May 2015, at 22:18, Rich Kulawiec wrote: > On Thu, May 28, 2015 at 03:13:37PM -0400, William Herrin wrote: > >> My first dog's name was a random and unpronounceable 30-character >> string. > > I think this (Bill's) is a very good practice. That's what I should do. Instead, I pull down the list of candidate questions and think to myself... - I didn't go to a high school - I don't understand this other high school reference - I don't watch sports - I don't have a favourite sports team - I wonder vaguely whether that question actually had anything to do with sports - I don't have a favourite pet - I don't know my grandmother's middle name, and never did - I don't have a favourite colour - I've never owned a dog - Are pets ever really owned? - Doesn't that speak to the denegration of others based on species? - Aren't we against that? and around this point, I start to think - I've had enough of this - this is too hard - I don't even remember what I am signing up for at this point - I am going to look for amusing cats on youtube Joe From owen at delong.com Fri May 29 07:45:14 2015 From: owen at delong.com (Owen DeLong) Date: Fri, 29 May 2015 00:45:14 -0700 Subject: AWS Elastic IP architecture In-Reply-To: References: Message-ID: > On May 28, 2015, at 8:00 AM, Ca By wrote: > > On Thu, May 28, 2015 at 7:34 AM, Luan Nguyen wrote: > >> Hi folks, >> Anyone knows what is used for the AWS Elastic IP? is it LISP? >> >> > AWS does not really talk about things like this, but i highly doubt it is > LISP. Yeah, if it were LISP, they could probably handle IPv6. Owen From owen at delong.com Fri May 29 08:22:12 2015 From: owen at delong.com (Owen DeLong) Date: Fri, 29 May 2015 01:22:12 -0700 Subject: AWS Elastic IP architecture In-Reply-To: References: Message-ID: <6C73DCAB-235C-4070-BE5F-729E9D78B56F@delong.com> > On May 28, 2015, at 10:03 AM, Christopher Morrow wrote: > > On Thu, May 28, 2015 at 11:59 AM, Michael Helmeste wrote: >>> -----Original Message----- >>> From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Christopher >>> Morrow >>> Subject: Re: AWS Elastic IP architecture >>> [...] >>> i sort of doesn't matter right? it is PROBABLY some form of encapsulation >>> (like gre, ip-in-ip, lisp, mpls, vpls, etc) ... >>> [...] >> >> I don't know how the public blocks get to the datacenter (e.g. whether they are using MPLS) but after that I think it is pretty straightforward. All of the VMs have only one IPv4 address assigned out of 10/8. This doesn't change when you attach an Elastic IP to them. >> > > right, so they encap somwhere after between 'tubez' and 'vm'. and > likely have a simple 'swap the ip header' function somewhere before > the vm as well. It doesn?t sound like they have to encap/decap anything. Sounds like the packet comes in, gets NAT?d and then gets routed to the 10/8 address by normal means. Why do you assume some encap/decap process somewhere in this process? > >> All that is happening is that they have some NAT device somewhere (maybe even just a redundant pair of VMs?) that has a block of public IPs assigned to it and they > > i'd question scalability of that sort of thing... but sure, sounds > like a reasonable model to think about. They are known to be running multiple copies of RFC-1918 in disparate localities already. In terms of scale, modulo the nightmare that must make of their management network and the fragility of what happens when company A in datacenter A wants to talk to company A in datacenter B and they both have the same 10-NET addresses, the variety of things that are inherently broken by NAT or multi-layer NAT, and a few other relatively well-known problems, the biggest scalability problem I see in such a solution is the lack of available public IPv4 addresses to give to elastic IP utilization. However, this is a scale problem shared by the entire IPv4 internet. The solution is to add IPv6 capabilities to your hosts/software/etc. Unfortunately, if you build your stuff on AWS, said solution is not possible and Amazon, despite repeated public prodding, has not announced any plans, intention, or date for making IPv6 available in a meaningful way to things hosted on their infrastructure. Suggestion: If you care about scale or about your application being able to function in the future (say more than the next couple of years), don?t build it on AWS? Build it somewhere that has IPv6 capabilities such as (in no particular order): Linode, Host Virtual[1], SoftLayer, etc. Owen [1] Full disclosure: I have no affiliation with any of the companies listed except Host Virtual (vr.org ). I have done some IPv4 and IPv6 consulting for them. I have no skin in the game promoting any of the above organizations, including Host Virtual. To the best of my knowledge, all of the organizations have ethical business practices and offer excellent customer service. From mysidia at gmail.com Fri May 29 11:17:43 2015 From: mysidia at gmail.com (Jimmy Hess) Date: Fri, 29 May 2015 06:17:43 -0500 Subject: gmail security is a joke In-Reply-To: References: <5564829E.1000006@truemetal.org> <20150526152246.GA12876@pob.ytti.fi> <312D54C4-EC72-4A3F-87FC-357AFA61D04A@delong.com> <20150526161151.GA14841@pob.ytti.fi> <20150527131119.GA12103@pob.ytti.fi> Message-ID: On Wed, May 27, 2015 at 8:42 AM, Joel Maslak wrote: > I also suspect not every telco validates number porting requests against > social engineering properly. What national wireless provider _does_ validate porting requests against social engineering? As far as I knew, as soon as the gaining provider receives the filled out online form or written form, with the billing address, Or copy of a bill from the old provider printed off from the losing provider's web portal signed off with a forged signature from the scammer (All information that can be derived through pre-texting or social engineering), The gaining wireless carrier can proceed, and will proceed with a simple port without having to call the number for approval. The sufficiently evil scammer will have the wireless number ported to their pre-paid cell phone within 48 hours, and be ready to receive insecure SMS message from the target's online banking service to confirm the second factor for login. -- -JH From beckman at angryox.com Fri May 29 14:35:17 2015 From: beckman at angryox.com (Peter Beckman) Date: Fri, 29 May 2015 10:35:17 -0400 Subject: gmail security is a joke In-Reply-To: References: <5564829E.1000006@truemetal.org> <20150526152246.GA12876@pob.ytti.fi> <312D54C4-EC72-4A3F-87FC-357AFA61D04A@delong.com> <55655311.3020403@alvarezp.org> <20150528211855.GA21216@gsp.org> Message-ID: I use completely random strings for security questions. The company doesn't care what my answer is, so instead of knowing that my favorite sports team is [REDACTED] they can see that it is "WheF7?ydk/cBG8MgZf7w" Go WheF7?ydk/cBG8MgZf7w! I store all of the security questions in my password manager (1Password), and though annoying if prompted for them often, my account is more secure as a result. It's also a lot of fun when you call in and they ask you the answer to your security question. Just because someone asks you a question it does not require you to give an answer they expect. (Or any answer) Beckman On Fri, 29 May 2015, Joe Abley wrote: >> On Thu, May 28, 2015 at 03:13:37PM -0400, William Herrin wrote: >> >>> My first dog's name was a random and unpronounceable 30-character string. >> > That's what I should do. Instead, I pull down the list of candidate questions > and think to myself... > > - I didn't go to a high school > - I don't understand this other high school reference > - I don't watch sports > - I don't have a favourite sports team > - I wonder vaguely whether that question actually had anything to do with > sports > - I don't have a favourite pet > - I don't know my grandmother's middle name, and never did > - I don't have a favourite colour > - I've never owned a dog > - Are pets ever really owned? > - Doesn't that speak to the denegration of others based on species? > - Aren't we against that? > > and around this point, I start to think > > - I've had enough of this > - this is too hard > - I don't even remember what I am signing up for at this point > - I am going to look for amusing cats on youtube --------------------------------------------------------------------------- Peter Beckman Internet Guy beckman at angryox.com http://www.angryox.com/ --------------------------------------------------------------------------- From nwolff at oar.net Fri May 29 14:48:37 2015 From: nwolff at oar.net (Wolff, Nicholas (Nick)) Date: Fri, 29 May 2015 14:48:37 +0000 Subject: 10Gb CPE In-Reply-To: References: Message-ID: We have around 1000 or so ex3300?s deployed as cpe gear for sites with circuits anywhere from 5m to 10g. It both will do everything you need and allow the flexibility for lots of options if necessary. Not saying it?s the best option for everyone but should fit all requirements. ? Nick On 5/28/15, 9:22 AM, "Colton Conor" wrote: >Aren't these Brocade and Juniper solutions just switches? I thought the >original poster was asking for a 10G CPE device? > >On Wed, May 27, 2015 at 2:12 PM, Cody Grosskopf >wrote: > >> I also used brocade icx series for this. Depending on feature >>requirements >> the juniper ex3300 might be cheaper. >> >> On Tue, May 26, 2015, 12:04 PM Chris Lane wrote: >> >> > We use Brocade ICX 6450s for this. >> > >> > -Chris >> > >> > On Tue, May 26, 2015 at 2:40 PM, Daniel Rohan >>wrote: >> > >> > > With the deluge of 10Gb X device recommendations, I thought I'd hit >>the >> > > list with one more. Does anyone out there running 10Gb managed CPE >> feel >> > > like sharing their experiences? >> > > >> > > Our use case would be a managed endpoint that would allow for >>testing >> > and >> > > circuit verification while providing a layer 2 extension to our edge >> gear >> > > at the PoPs. >> > > >> > > We're hoping to find a cheap vendor-supplied solution- not homebrew. >> > > >> > > If so, which features have been important to you? >> > > >> > > Which vendors have good products? >> > > >> > > What price point? >> > > >> > > >> > > Thanks, >> > > >> > > Dan >> > > >> > >> > >> > >> > -- >> > - Chris >> > >> From sander at steffann.nl Fri May 29 12:13:38 2015 From: sander at steffann.nl (Sander Steffann) Date: Fri, 29 May 2015 14:13:38 +0200 Subject: gmail security is a joke In-Reply-To: References: <5564829E.1000006@truemetal.org> <20150526152246.GA12876@pob.ytti.fi> <312D54C4-EC72-4A3F-87FC-357AFA61D04A@delong.com> <55655311.3020403@alvarezp.org> <20150528211855.GA21216@gsp.org> Message-ID: <34E6A2AB-533C-4D2B-9492-0942190A2D9D@steffann.nl> > Op 29 mei 2015, om 08:42 heeft Joe Abley het volgende geschreven: > > [...] > and around this point, I start to think > > - I've had enough of this > - this is too hard > - I don't even remember what I am signing up for at this point > - I am going to look for amusing cats on youtube Good plan, Sander From morrowc.lists at gmail.com Fri May 29 15:23:50 2015 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Fri, 29 May 2015 11:23:50 -0400 Subject: AWS Elastic IP architecture In-Reply-To: References: Message-ID: On Fri, May 29, 2015 at 3:45 AM, Owen DeLong wrote: > Yeah, if it were LISP, they could probably handle IPv6. why can't they do v6 with any other encap? the encap really doesn't matter at all to the underlying ip protocol used, or shouldn't... you decide at the entrance to the 'virtual network' that 'thingy is in virtual-network-5 and encap the packet... regardless of ip version of the thing you are encapsulating. From morrowc.lists at gmail.com Fri May 29 15:27:09 2015 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Fri, 29 May 2015 11:27:09 -0400 Subject: AWS Elastic IP architecture In-Reply-To: <6C73DCAB-235C-4070-BE5F-729E9D78B56F@delong.com> References: <6C73DCAB-235C-4070-BE5F-729E9D78B56F@delong.com> Message-ID: On Fri, May 29, 2015 at 4:22 AM, Owen DeLong wrote: > Why do you assume some encap/decap process somewhere in this process? why do you think they have a single 10/8 deployment per location and not per customer? if it' sper customer, they have to provide some encap (I'd think) to avoid lots and lots of headaches. I don't imagine that if aws/ec2 is 'millions of customers' running on 'cheapest ethernet reference platform possible' they can do much fancy stuff with respect to virtual networking. I'd expect almost all of that to have to happen at the vm-host (not the guest), and that there's just some very simple encapsulation of traffic from the 'edge' to the vm-host and then 'native' (for some sense of that word) up to the 'vm'. From richo at psych0tik.net Fri May 29 15:42:10 2015 From: richo at psych0tik.net (Richo Healey) Date: Fri, 29 May 2015 08:42:10 -0700 Subject: gmail security is a joke In-Reply-To: References: <5564829E.1000006@truemetal.org> <20150526152246.GA12876@pob.ytti.fi> <312D54C4-EC72-4A3F-87FC-357AFA61D04A@delong.com> <55655311.3020403@alvarezp.org> <20150528211855.GA21216@gsp.org> Message-ID: <20150529154210.GA45824@xenia> On 29/05/15 10:35 -0400, Peter Beckman wrote: >I use completely random strings for security questions. The company doesn't >care what my answer is, so instead of knowing that my favorite sports team >is [REDACTED] they can see that it is "WheF7?ydk/cBG8MgZf7w" > >Go WheF7?ydk/cBG8MgZf7w! > >I store all of the security questions in my password manager (1Password), >and though annoying if prompted for them often, my account is more secure >as a result. It's also a lot of fun when you call in and they ask you the >answer to your security question. > >Just because someone asks you a question it does not require you to give an >answer they expect. (Or any answer) > >Beckman Good in principle, however I'll bet you 20$ that with this state, if I get on the phone with support, and they ask for the answer to the security question, simply replying "Is it a bunch of gharbled chracters, about 20 of em?" Will be more than enough to get me in. Use 3-4 dictionary words. From streiner at cluebyfour.org Fri May 29 16:32:34 2015 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Fri, 29 May 2015 12:32:34 -0400 (EDT) Subject: gmail security is a joke In-Reply-To: <20150528211855.GA21216@gsp.org> References: <5564829E.1000006@truemetal.org> <20150526152246.GA12876@pob.ytti.fi> <312D54C4-EC72-4A3F-87FC-357AFA61D04A@delong.com> <55655311.3020403@alvarezp.org> <20150528211855.GA21216@gsp.org> Message-ID: On Thu, 28 May 2015, Rich Kulawiec wrote: > I think this (Bill's) is a very good practice. It's not that difficult > to enumerate the name of every pro sports team in the US, the 100 most > popular dog names, the 200 most common street names, etc. This attack > can be mitigated by limiting attempts...but of course if that's done, > then it's possible for an attacker to lock out the real owner by just > hammering away constantly using assorted botnet hosts. There are providers (banks, etc) who will disable an online account that has had X failed login attempts. While that's good for preventing $bad_guy from continuing to try to brute-force-guess the password, it creates a nominal DoS condition for the legitimate owner who then has to contact the provider and go through their password reset procedure. In most of the cases I've seen, the provider is not well equipped to block login attempts for $legit_user from whatever address range is doing the brute-forcing (possibly spoofed / botted anyway). jms From bzs at world.std.com Fri May 29 17:42:55 2015 From: bzs at world.std.com (Barry Shein) Date: Fri, 29 May 2015 13:42:55 -0400 Subject: gmail security is a joke In-Reply-To: References: <5564829E.1000006@truemetal.org> <20150526152246.GA12876@pob.ytti.fi> <312D54C4-EC72-4A3F-87FC-357AFA61D04A@delong.com> <55655311.3020403@alvarezp.org> <20150528211855.GA21216@gsp.org> Message-ID: <21864.42271.96532.454022@world.std.com> I can't write my autobiography because it'd contain the answers to too many security questions! -- -Barry Shein The World | bzs at TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: 800-THE-WRLD | Dial-Up: US, PR, Canada Software Tool & Die | Public Access Internet | SINCE 1989 *oo* From cscora at apnic.net Fri May 29 18:13:04 2015 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 30 May 2015 04:13:04 +1000 (AEST) Subject: Weekly Routing Table Report Message-ID: <201505291813.t4TID4kB023920@thyme.rand.apnic.net> This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. The posting is sent to APOPS, NANOG, AfNOG, AusNOG, SANOG, PacNOG, CaribNOG and the RIPE Routing Working Group. Daily listings are sent to bgp-stats at lists.apnic.net For historical data, please see http://thyme.rand.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 30 May, 2015 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 546078 Prefixes after maximum aggregation (per Origin AS): 207732 Deaggregation factor: 2.63 Unique aggregates announced (without unneeded subnets): 266391 Total ASes present in the Internet Routing Table: 50461 Prefixes per ASN: 10.82 Origin-only ASes present in the Internet Routing Table: 36679 Origin ASes announcing only one prefix: 16300 Transit ASes present in the Internet Routing Table: 6313 Transit-only ASes present in the Internet Routing Table: 165 Average AS path length visible in the Internet Routing Table: 4.4 Max AS path length visible: 41 Max AS path prepend of ASN ( 12486) 32 Prefixes from unregistered ASNs in the Routing Table: 1137 Unregistered ASNs in the Routing Table: 421 Number of 32-bit ASNs allocated by the RIRs: 9645 Number of 32-bit ASNs visible in the Routing Table: 7469 Prefixes from 32-bit ASNs in the Routing Table: 27217 Number of bogon 32-bit ASNs visible in the Routing Table: 6 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 352 Number of addresses announced to Internet: 2759984352 Equivalent to 164 /8s, 130 /16s and 4 /24s Percentage of available address space announced: 74.5 Percentage of allocated address space announced: 74.5 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 97.4 Total number of prefixes smaller than registry allocations: 182950 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 135191 Total APNIC prefixes after maximum aggregation: 39171 APNIC Deaggregation factor: 3.45 Prefixes being announced from the APNIC address blocks: 141541 Unique aggregates announced from the APNIC address blocks: 57260 APNIC Region origin ASes present in the Internet Routing Table: 5059 APNIC Prefixes per ASN: 27.98 APNIC Region origin ASes announcing only one prefix: 1212 APNIC Region transit ASes present in the Internet Routing Table: 884 Average APNIC Region AS path length visible: 4.3 Max APNIC Region AS path length visible: 32 Number of APNIC region 32-bit ASNs visible in the Routing Table: 1459 Number of APNIC addresses announced to Internet: 749217216 Equivalent to 44 /8s, 168 /16s and 37 /24s Percentage of available APNIC address space announced: 87.6 APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079, 55296-56319, 58368-59391, 63488-64098, 131072-135580 APNIC Address Blocks 1/8, 14/8, 27/8, 36/8, 39/8, 42/8, 43/8, 49/8, 58/8, 59/8, 60/8, 61/8, 101/8, 103/8, 106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 133/8, 150/8, 153/8, 163/8, 171/8, 175/8, 180/8, 182/8, 183/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, 223/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 179304 Total ARIN prefixes after maximum aggregation: 88173 ARIN Deaggregation factor: 2.03 Prefixes being announced from the ARIN address blocks: 181952 Unique aggregates announced from the ARIN address blocks: 84936 ARIN Region origin ASes present in the Internet Routing Table: 16622 ARIN Prefixes per ASN: 10.95 ARIN Region origin ASes announcing only one prefix: 6124 ARIN Region transit ASes present in the Internet Routing Table: 1732 Average ARIN Region AS path length visible: 3.8 Max ARIN Region AS path length visible: 23 Number of ARIN region 32-bit ASNs visible in the Routing Table: 460 Number of ARIN addresses announced to Internet: 1081496864 Equivalent to 64 /8s, 118 /16s and 85 /24s Percentage of available ARIN address space announced: 57.2 ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 53248-55295, 62464-63487, 64198-64296, 393216-395164 ARIN Address Blocks 3/8, 4/8, 6/8, 7/8, 8/8, 9/8, 11/8, 12/8, 13/8, 15/8, 16/8, 17/8, 18/8, 19/8, 20/8, 21/8, 22/8, 23/8, 24/8, 26/8, 28/8, 29/8, 30/8, 32/8, 33/8, 34/8, 35/8, 38/8, 40/8, 44/8, 45/8, 47/8, 48/8, 50/8, 52/8, 53/8, 54/8, 55/8, 56/8, 57/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, 100/8, 104/8, 107/8, 108/8, 128/8, 129/8, 130/8, 131/8, 132/8, 134/8, 135/8, 136/8, 137/8, 138/8, 139/8, 140/8, 142/8, 143/8, 144/8, 146/8, 147/8, 148/8, 149/8, 152/8, 155/8, 156/8, 157/8, 158/8, 159/8, 160/8, 161/8, 162/8, 164/8, 165/8, 166/8, 167/8, 168/8, 169/8, 170/8, 172/8, 173/8, 174/8, 184/8, 192/8, 198/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 214/8, 215/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 132389 Total RIPE prefixes after maximum aggregation: 65992 RIPE Deaggregation factor: 2.01 Prefixes being announced from the RIPE address blocks: 138863 Unique aggregates announced from the RIPE address blocks: 86068 RIPE Region origin ASes present in the Internet Routing Table: 17948 RIPE Prefixes per ASN: 7.74 RIPE Region origin ASes announcing only one prefix: 8141 RIPE Region transit ASes present in the Internet Routing Table: 2958 Average RIPE Region AS path length visible: 4.9 Max RIPE Region AS path length visible: 34 Number of RIPE region 32-bit ASNs visible in the Routing Table: 3739 Number of RIPE addresses announced to Internet: 694821120 Equivalent to 41 /8s, 106 /16s and 33 /24s Percentage of available RIPE address space announced: 101.0 RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-52223, 56320-58367 59392-61439, 61952-62463, 196608-202239 RIPE Address Blocks 2/8, 5/8, 25/8, 31/8, 37/8, 46/8, 51/8, 62/8, 77/8, 78/8, 79/8, 80/8, 81/8, 82/8, 83/8, 84/8, 85/8, 86/8, 87/8, 88/8, 89/8, 90/8, 91/8, 92/8, 93/8, 94/8, 95/8, 109/8, 141/8, 145/8, 151/8, 176/8, 178/8, 185/8, 188/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 59819 Total LACNIC prefixes after maximum aggregation: 11304 LACNIC Deaggregation factor: 5.29 Prefixes being announced from the LACNIC address blocks: 70075 Unique aggregates announced from the LACNIC address blocks: 32630 LACNIC Region origin ASes present in the Internet Routing Table: 2439 LACNIC Prefixes per ASN: 28.73 LACNIC Region origin ASes announcing only one prefix: 626 LACNIC Region transit ASes present in the Internet Routing Table: 504 Average LACNIC Region AS path length visible: 4.9 Max LACNIC Region AS path length visible: 25 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 1696 Number of LACNIC addresses announced to Internet: 168456448 Equivalent to 10 /8s, 10 /16s and 113 /24s Percentage of available LACNIC address space announced: 100.4 LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 61440-61951, 64099-64197, 262144-265628 + ERX transfers LACNIC Address Blocks 177/8, 179/8, 181/8, 186/8, 187/8, 189/8, 190/8, 191/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 11982 Total AfriNIC prefixes after maximum aggregation: 3048 AfriNIC Deaggregation factor: 3.93 Prefixes being announced from the AfriNIC address blocks: 13295 Unique aggregates announced from the AfriNIC address blocks: 5178 AfriNIC Region origin ASes present in the Internet Routing Table: 729 AfriNIC Prefixes per ASN: 18.24 AfriNIC Region origin ASes announcing only one prefix: 197 AfriNIC Region transit ASes present in the Internet Routing Table: 157 Average AfriNIC Region AS path length visible: 4.6 Max AfriNIC Region AS path length visible: 24 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 115 Number of AfriNIC addresses announced to Internet: 65687040 Equivalent to 3 /8s, 234 /16s and 78 /24s Percentage of available AfriNIC address space announced: 65.3 AfriNIC AS Blocks 36864-37887, 327680-328703 & ERX transfers AfriNIC Address Blocks 41/8, 102/8, 105/8, 154/8, 196/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4766 2928 11557 914 Korea Telecom 17974 2689 904 81 PT Telekomunikasi Indonesia 7545 2431 336 131 TPG Telecom Limited 4755 2026 423 219 TATA Communications formerly 4538 1937 4190 72 China Education and Research 9808 1686 8717 28 Guangdong Mobile Communicatio 9829 1669 1332 62 National Internet Backbone 4808 1469 2249 467 CNCGROUP IP network China169 9583 1449 120 588 Sify Limited 9498 1330 335 101 BHARTI Airtel Ltd. Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 22773 3045 2958 141 Cox Communications Inc. 6389 2796 3688 51 BellSouth.net Inc. 3356 2569 10687 495 Level 3 Communications, Inc. 18566 2047 379 189 MegaPath Corporation 20115 1878 1849 423 Charter Communications 6983 1749 866 245 EarthLink, Inc. 4323 1606 1022 410 tw telecom holdings, inc. 30036 1543 314 474 Mediacom Communications Corp 701 1390 11322 679 MCI Communications Services, 22561 1361 414 250 CenturyTel Internet Holdings, Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 39891 2473 132 7 SaudiNet, Saudi Telecom Compa 34984 2028 305 356 TELLCOM ILETISIM HIZMETLERI A 20940 1920 753 1407 Akamai International B.V. 6849 1213 356 24 JSC "Ukrtelecom" 8402 1095 544 15 OJSC "Vimpelcom" 31148 1049 45 23 Freenet Ltd. 13188 1040 97 70 TOV "Bank-Inform" 12479 944 868 72 France Telecom Espana SA 6830 906 2693 466 Liberty Global Operations B.V 8551 873 376 52 Bezeq International-Ltd Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 10620 3237 530 203 Telmex Colombia S.A. 28573 2287 2181 117 NET Servi?os de Comunica??o S 8151 1670 3255 468 Uninet S.A. de C.V. 7303 1667 1046 239 Telecom Argentina S.A. 6147 1632 374 30 Telefonica del Peru S.A.A. 6503 1248 421 55 Axtel, S.A.B. de C.V. 26615 1074 2325 35 Tim Celular S.A. 7738 999 1882 41 Telemar Norte Leste S.A. 3816 928 424 158 COLOMBIA TELECOMUNICACIONES S 18881 869 1036 22 Global Village Telecom Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 24863 895 280 37 Link Egypt (Link.NET) 8452 840 958 13 TE-AS 36903 504 254 98 Office National des Postes et 36992 423 1229 32 ETISALAT MISR 37492 312 175 71 Orange Tunisie 24835 304 146 13 Vodafone Data 3741 250 857 208 Internet Solutions 29571 242 21 12 Cote d'Ivoire Telecom 37054 199 19 6 Data Telecom Service 36947 190 807 13 Telecom Algeria Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 10620 3237 530 203 Telmex Colombia S.A. 22773 3045 2958 141 Cox Communications Inc. 4766 2928 11557 914 Korea Telecom 6389 2796 3688 51 BellSouth.net Inc. 17974 2689 904 81 PT Telekomunikasi Indonesia 3356 2569 10687 495 Level 3 Communications, Inc. 39891 2473 132 7 SaudiNet, Saudi Telecom Compa 7545 2431 336 131 TPG Telecom Limited 28573 2287 2181 117 NET Servi?os de Comunica??o S 18566 2047 379 189 MegaPath Corporation Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 22773 3045 2904 Cox Communications Inc. 6389 2796 2745 BellSouth.net Inc. 17974 2689 2608 PT Telekomunikasi Indonesia 39891 2473 2466 SaudiNet, Saudi Telecom Compa 7545 2431 2300 TPG Telecom Limited 28573 2287 2170 NET Servi?os de Comunica??o S 3356 2569 2074 Level 3 Communications, Inc. 4766 2928 2014 Korea Telecom 4538 1937 1865 China Education and Research 18566 2047 1858 MegaPath Corporation Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 30662 UNALLOCATED 8.2.129.0/24 3356 Level 3 Communicatio 53506 UNALLOCATED 8.17.102.0/23 3356 Level 3 Communicatio 46467 UNALLOCATED 8.19.192.0/24 46887 Lightower Fiber Netw 18985 UNALLOCATED 8.21.68.0/22 3356 Level 3 Communicatio 46473 UNALLOCATED 8.27.122.0/24 12180 Internap Network Ser 46473 UNALLOCATED 8.27.124.0/24 12180 Internap Network Ser 27205 UNALLOCATED 8.38.16.0/21 6461 Abovenet Communicati 15347 UNALLOCATED 8.224.147.0/24 12064 Cox Communications I 33628 UNALLOCATED 12.0.239.0/24 1239 Sprint 32805 UNALLOCATED 12.1.225.0/24 7018 AT&T Services, Inc. Complete listing at http://thyme.rand.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 5.100.241.0/24 23456 32bit Transition AS 23.226.112.0/20 62788 >>UNKNOWN<< 27.100.7.0/24 56096 >>UNKNOWN<< 31.217.248.0/21 44902 COVAGE NETWORKS SASU 41.73.1.0/24 37004 >>UNKNOWN<< 41.73.10.0/24 37004 >>UNKNOWN<< 41.73.11.0/24 37004 >>UNKNOWN<< 41.73.12.0/24 37004 >>UNKNOWN<< 41.73.13.0/24 37004 >>UNKNOWN<< 41.73.15.0/24 37004 >>UNKNOWN<< Complete listing at http://thyme.rand.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:17 /9:12 /10:34 /11:94 /12:264 /13:505 /14:1004 /15:1723 /16:12946 /17:7273 /18:12308 /19:25529 /20:36115 /21:38831 /22:59781 /23:51923 /24:294708 /25:1104 /26:1140 /27:721 /28:14 /29:12 /30:7 /31:0 /32:13 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 39891 2432 2473 SaudiNet, Saudi Telecom Compa 22773 2252 3045 Cox Communications Inc. 18566 1999 2047 MegaPath Corporation 6389 1639 2796 BellSouth.net Inc. 6983 1396 1749 EarthLink, Inc. 30036 1379 1543 Mediacom Communications Corp 34984 1322 2028 TELLCOM ILETISIM HIZMETLERI A 6147 1183 1632 Telefonica del Peru S.A.A. 10620 1136 3237 Telmex Colombia S.A. 11492 1111 1192 CABLE ONE, INC. Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1486 2:680 4:93 5:1813 6:25 8:1416 11:1 12:1832 13:10 14:1261 15:17 16:2 17:43 18:22 20:48 23:1233 24:1706 27:1908 31:1598 32:38 33:2 34:4 35:3 36:115 37:1921 38:1032 39:6 40:251 41:2666 42:278 43:1296 44:25 45:654 46:2194 47:42 49:877 50:809 52:12 54:73 55:5 56:8 57:40 58:1290 59:714 60:477 61:1751 62:1329 63:1917 64:4421 65:2274 66:4083 67:2059 68:1061 69:3272 70:980 71:446 72:1980 74:2647 75:335 76:422 77:1392 78:1241 79:805 80:1339 81:1302 82:812 83:699 84:723 85:1404 86:392 87:1040 88:520 89:1840 90:151 91:5966 92:847 93:2212 94:2075 95:2181 96:430 97:354 98:1051 99:49 100:69 101:831 103:7463 104:1779 105:61 106:225 107:978 108:626 109:2054 110:1103 111:1480 112:814 113:1082 114:827 115:1286 116:1374 117:1066 118:1795 119:1434 120:442 121:1086 122:2144 123:1828 124:1506 125:1592 128:648 129:383 130:402 131:1183 132:498 133:178 134:411 135:108 136:329 137:309 138:776 139:151 140:237 141:447 142:661 143:508 144:571 145:116 146:728 147:592 148:1130 149:406 150:561 151:606 152:486 153:244 154:488 155:864 156:408 157:463 158:339 159:1011 160:381 161:660 162:1948 163:426 164:675 165:691 166:307 167:836 168:1294 169:172 170:1464 171:244 172:67 173:1545 174:715 175:695 176:1312 177:3706 178:2143 179:919 180:1936 181:1687 182:1784 183:655 184:755 185:3572 186:2660 187:1746 188:2044 189:1577 190:7691 191:1015 192:8369 193:5599 194:4148 195:3654 196:1471 197:962 198:5530 199:5520 200:6646 201:3106 202:9490 203:9140 204:4677 205:2823 206:3081 207:2946 208:3961 209:3964 210:3512 211:1852 212:2552 213:2334 214:863 215:73 216:5730 217:1820 218:695 219:460 220:1433 221:785 222:468 223:707 End of report From Valdis.Kletnieks at vt.edu Fri May 29 20:16:57 2015 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Fri, 29 May 2015 16:16:57 -0400 Subject: gmail security is a joke In-Reply-To: Your message of "Fri, 29 May 2015 13:42:55 -0400." <21864.42271.96532.454022@world.std.com> References: <5564829E.1000006@truemetal.org> <20150526152246.GA12876@pob.ytti.fi> <312D54C4-EC72-4A3F-87FC-357AFA61D04A@delong.com> <55655311.3020403@alvarezp.org> <20150528211855.GA21216@gsp.org> <21864.42271.96532.454022@world.std.com> Message-ID: <79803.1432930617@turing-police.cc.vt.edu> On Fri, 29 May 2015 13:42:55 -0400, Barry Shein said: > > I can't write my autobiography because it'd contain the answers to too > many security questions! > > -- > -Barry Shein Congrats. The best .sig fodder I've seen in quite some time. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From ag4ve.us at gmail.com Fri May 29 20:32:36 2015 From: ag4ve.us at gmail.com (shawn wilson) Date: Fri, 29 May 2015 16:32:36 -0400 Subject: stacking pdu Message-ID: Is there a way to stack PDUs? like, with 30A 220, we need more plugs than power but I'd like them to communicate to make sure we don't over power the circuit. Do any APC or Triplite systems support this? From jason at biel-tech.com Fri May 29 20:51:10 2015 From: jason at biel-tech.com (Jason Biel) Date: Fri, 29 May 2015 22:51:10 +0200 Subject: stacking pdu In-Reply-To: References: Message-ID: <8563728435275370015@unknownmsgid> How many plugs and what style do you need? What is the facility providing receptacle wise? L15-30A three-phase ? > On May 29, 2015, at 10:34 PM, shawn wilson wrote: > > Is there a way to stack PDUs? like, with 30A 220, we need more plugs > than power but I'd like them to communicate to make sure we don't over > power the circuit. Do any APC or Triplite systems support this? From COLIN at COLINBAKER.ORG Fri May 29 21:15:47 2015 From: COLIN at COLINBAKER.ORG (Colin Baker) Date: Fri, 29 May 2015 16:15:47 -0500 Subject: Any 4181/TDS folks on here? Message-ID: <06c92866ea82d32b0c4532ee8ffa7c6f@mail.derivataters.com> Looking for a bit of help with ticket we have open, not getting very far through normal support channels. Please contact me offlist. Thanks! -- Colin Baker AS4150 From bill at herrin.us Fri May 29 21:29:47 2015 From: bill at herrin.us (William Herrin) Date: Fri, 29 May 2015 17:29:47 -0400 Subject: stacking pdu In-Reply-To: References: Message-ID: On Fri, May 29, 2015 at 4:32 PM, shawn wilson wrote: > Is there a way to stack PDUs? like, with 30A 220, we need more plugs > than power but I'd like them to communicate to make sure we don't over > power the circuit. Do any APC or Triplite systems support this? Isn't it against the NEC and the fire code to stack power strips? We all do it, but isn't it against code? Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: From lists.nanog at monmotha.net Fri May 29 21:48:16 2015 From: lists.nanog at monmotha.net (Brandon Martin) Date: Fri, 29 May 2015 17:48:16 -0400 Subject: stacking pdu In-Reply-To: References: Message-ID: <5568DEA0.6010802@monmotha.net> On 05/29/2015 05:29 PM, William Herrin wrote: > On Fri, May 29, 2015 at 4:32 PM, shawn wilson wrote: >> Is there a way to stack PDUs? like, with 30A 220, we need more plugs >> than power but I'd like them to communicate to make sure we don't over >> power the circuit. Do any APC or Triplite systems support this? > > Isn't it against the NEC and the fire code to stack power strips? We > all do it, but isn't it against code? It sounds like he's asking for a PDU specifically intended to be used with managed expansion/stacking type modules. That would be permissible per NEC and most local fire codes as the device would be specifically listed for such usage. I've seen something like this inside blade/modular racks like IBM Flex systems, but unfortunately I don't know of any such off-the-shelf parts. It would seem entirely reasonable to take a 30A/240V feed on a 6-30 or 14-30 type connection and break it out to numerous either C13 or 6-15/5-15 style sockets, possibly on a modular basis using some sort of proprietary power+data connections for the breakout. E.g. if you needed to mix 120V and 240V devices in a rack, you could get 5-15 and 6-15 breakouts with each individual outlet switched and maintain whole-rack metering. Sounds like a really handy device, if one exists COTS. -- Brandon Martin From rafael at gav.ufsc.br Fri May 29 21:53:17 2015 From: rafael at gav.ufsc.br (Rafael Possamai) Date: Fri, 29 May 2015 16:53:17 -0500 Subject: stacking pdu In-Reply-To: References: Message-ID: You could run a PDU in paralallel so that you don't use more current than the wires are rated for (although the PDU should trip the circuti anyways in case you overload it). Only problem is matching the receptacles. You probably don't want to half-ass it, so I'd just add an extra PDU and run an extra ethernet cable so you can monitor it. On Fri, May 29, 2015 at 4:29 PM, William Herrin wrote: > On Fri, May 29, 2015 at 4:32 PM, shawn wilson wrote: > > Is there a way to stack PDUs? like, with 30A 220, we need more plugs > > than power but I'd like them to communicate to make sure we don't over > > power the circuit. Do any APC or Triplite systems support this? > > Isn't it against the NEC and the fire code to stack power strips? We > all do it, but isn't it against code? > > Regards, > Bill Herrin > > -- > William Herrin ................ herrin at dirtside.com bill at herrin.us > Owner, Dirtside Systems ......... Web: > From cidr-report at potaroo.net Fri May 29 22:00:00 2015 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 29 May 2015 22:00:00 GMT Subject: The Cidr Report Message-ID: <201505292200.t4TM00Xe025411@wattle.apnic.net> This report has been generated at Fri May 29 21:14:38 2015 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/2.0 for a current version of this report. Recent Table History Date Prefixes CIDR Agg 22-05-15 554435 306326 23-05-15 554588 306499 24-05-15 554796 306541 25-05-15 554840 305980 26-05-15 554088 305859 27-05-15 554575 305415 28-05-15 554683 305507 29-05-15 554940 306151 AS Summary 50728 Number of ASes in routing system 20224 Number of ASes announcing only one prefix 3237 Largest number of prefixes announced by an AS AS10620: Telmex Colombia S.A.,CO 120825344 Largest address span announced by an AS (/32s) AS4134 : CHINANET-BACKBONE No.31,Jin-rong Street,CN 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'). --- 29May15 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 555234 306138 249096 44.9% All ASes AS22773 3048 171 2877 94.4% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc.,US AS6389 2796 99 2697 96.5% BELLSOUTH-NET-BLK - BellSouth.net Inc.,US AS9394 3001 324 2677 89.2% CTTNET China TieTong Telecommunications Corporation,CN AS17974 2690 81 2609 97.0% TELKOMNET-AS2-AP PT Telekomunikasi Indonesia,ID AS39891 2472 35 2437 98.6% ALJAWWALSTC-AS Saudi Telecom Company JSC,SA AS28573 2287 295 1992 87.1% NET Servi?os de Comunica??o S.A.,BR AS3356 2575 696 1879 73.0% LEVEL3 - Level 3 Communications, Inc.,US AS9808 1686 67 1619 96.0% CMNET-GD Guangdong Mobile Communication Co.Ltd.,CN AS4766 2928 1338 1590 54.3% KIXS-AS-KR Korea Telecom,KR AS6983 1748 248 1500 85.8% ITCDELTA - Earthlink, Inc.,US AS7545 2649 1180 1469 55.5% TPG-INTERNET-AP TPG Telecom Limited,AU AS10620 3237 1840 1397 43.2% Telmex Colombia S.A.,CO AS20115 1878 485 1393 74.2% CHARTER-NET-HKY-NC - Charter Communications,US AS7303 1667 288 1379 82.7% Telecom Argentina S.A.,AR AS6147 1632 281 1351 82.8% Telefonica del Peru S.A.A.,PE AS4755 2022 695 1327 65.6% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP,IN AS9498 1330 116 1214 91.3% BBIL-AP BHARTI Airtel Ltd.,IN AS4323 1616 412 1204 74.5% TWTC - tw telecom holdings, inc.,US AS7552 1161 58 1103 95.0% VIETEL-AS-AP Viettel Corporation,VN AS8402 1081 25 1056 97.7% CORBINA-AS OJSC "Vimpelcom",RU AS18566 2047 1008 1039 50.8% MEGAPATH5-US - MegaPath Corporation,US AS6849 1210 234 976 80.7% UKRTELNET JSC UKRTELECOM,UA AS8151 1672 714 958 57.3% Uninet S.A. de C.V.,MX AS7738 999 83 916 91.7% Telemar Norte Leste S.A.,BR AS26615 1074 181 893 83.1% Tim Celular S.A.,BR AS4538 1955 1074 881 45.1% ERX-CERNET-BKB China Education and Research Network Center,CN AS38285 979 126 853 87.1% M2TELECOMMUNICATIONS-AU M2 Telecommunications Group Ltd,AU AS18881 869 40 829 95.4% Global Village Telecom,BR AS4780 1091 280 811 74.3% SEEDNET Digital United Inc.,TW AS24560 1239 461 778 62.8% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services,IN Total 56639 12935 43704 77.2% Top 30 total Possible Bogus Routes 5.100.241.0/24 AS19957 -Reserved AS-,ZZ 23.226.112.0/20 AS62788 -Reserved AS-,ZZ 27.100.7.0/24 AS56096 31.217.248.0/21 AS44902 COV-ASN COVAGE NETWORKS SASU,FR 41.73.1.0/24 AS37004 -Reserved AS-,ZZ 41.73.10.0/24 AS37004 -Reserved AS-,ZZ 41.73.11.0/24 AS37004 -Reserved AS-,ZZ 41.73.12.0/24 AS37004 -Reserved AS-,ZZ 41.73.13.0/24 AS37004 -Reserved AS-,ZZ 41.73.15.0/24 AS37004 -Reserved AS-,ZZ 41.73.16.0/24 AS37004 -Reserved AS-,ZZ 41.73.18.0/24 AS37004 -Reserved AS-,ZZ 41.73.20.0/24 AS37004 -Reserved AS-,ZZ 41.73.21.0/24 AS37004 -Reserved AS-,ZZ 41.76.48.0/21 AS36969 MTL-AS,MW 41.78.180.0/23 AS37265 -Reserved AS-,ZZ 41.189.96.0/20 AS37000 -Reserved AS-,ZZ 41.189.127.0/24 AS37000 -Reserved AS-,ZZ 41.189.128.0/24 AS37000 -Reserved AS-,ZZ 41.191.108.0/22 AS37004 -Reserved AS-,ZZ 41.191.108.0/24 AS37004 -Reserved AS-,ZZ 41.191.109.0/24 AS37004 -Reserved AS-,ZZ 41.191.110.0/24 AS37004 -Reserved AS-,ZZ 41.191.111.0/24 AS37004 -Reserved AS-,ZZ 41.223.208.0/22 AS37000 -Reserved AS-,ZZ 41.242.152.0/22 AS37558 LITC,LY 41.242.156.0/22 AS37558 LITC,LY 45.67.78.0/24 AS38040 GLOBAL-TRANSIT-TOT-IIG-TH TOT Public Company Limited,TH 65.75.216.0/23 AS10494 AAI - Accurate Automation, Inc.,US 65.75.217.0/24 AS10494 AAI - Accurate Automation, Inc.,US 66.78.66.0/23 AS10835 VISIONARY - Visionary Communications, Inc.,US 66.78.68.0/22 AS10835 VISIONARY - Visionary Communications, Inc.,US 66.78.76.0/23 AS10835 VISIONARY - Visionary Communications, Inc.,US 66.78.80.0/21 AS10835 VISIONARY - Visionary Communications, Inc.,US 66.78.91.0/24 AS10835 VISIONARY - Visionary Communications, Inc.,US 66.180.64.0/21 AS32558 ZEUTER - Zeuter Development Corporation,CA 66.187.240.0/20 AS14552 ACS-SOUTHEASTDATACENTER - Affiliated Computer Services, Inc.,US 66.205.224.0/19 AS16526 BIRCH-TELECOM - Birch Telecom, Inc.,US 66.251.128.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.133.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.134.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.136.0/21 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.140.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.141.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.142.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 72.19.0.0/19 AS16526 BIRCH-TELECOM - Birch Telecom, Inc.,US 74.113.200.0/23 AS46939 -Reserved AS-,ZZ 74.114.52.0/22 AS40818 -Reserved AS-,ZZ 74.114.52.0/23 AS40818 -Reserved AS-,ZZ 74.114.52.0/24 AS40818 -Reserved AS-,ZZ 74.114.53.0/24 AS40818 -Reserved AS-,ZZ 74.114.54.0/23 AS40818 -Reserved AS-,ZZ 74.114.54.0/24 AS40818 -Reserved AS-,ZZ 74.114.55.0/24 AS40818 -Reserved AS-,ZZ 74.114.184.0/22 AS19888 -Reserved AS-,ZZ 74.121.24.0/22 AS36263 FORONA - Forona Technologies, Inc.,US 74.123.136.0/21 AS53358 -Reserved AS-,ZZ 77.243.91.0/24 AS42597 -Reserved AS-,ZZ 80.78.133.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US 80.78.134.0/23 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US 80.78.134.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US 80.78.135.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US 80.250.32.0/22 AS37106 ODUA-AS,NG 83.142.48.0/24 AS13213 UK2NET-AS UK2 - Ltd,GB 83.142.49.0/24 AS13213 UK2NET-AS UK2 - Ltd,GB 91.103.8.0/24 AS42551 -Reserved AS-,ZZ 91.103.9.0/24 AS42551 -Reserved AS-,ZZ 91.103.10.0/24 AS42551 -Reserved AS-,ZZ 91.103.11.0/24 AS42551 -Reserved AS-,ZZ 91.193.60.0/22 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 91.195.66.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 91.197.36.0/22 AS43359 -Reserved AS-,ZZ 91.230.27.0/24 AS57022 -Reserved AS-,ZZ 98.143.160.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.161.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.162.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.163.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.164.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.165.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.166.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.167.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.168.0/22 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.172.0/22 AS26566 -Reserved AS-,ZZ 98.143.172.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.173.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.174.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.175.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 102.69.1.0/24 AS59749 CLEANMAT CLEANMAT EOOD,BG 103.7.120.0/22 AS4725 ODN SOFTBANK TELECOM Corp.,JP 103.10.222.0/24 AS13189 103.11.16.0/22 AS23818 JETINTERNET JETINTERNET Corporation,JP 103.15.92.0/22 AS23818 JETINTERNET JETINTERNET Corporation,JP 103.19.219.0/24 AS58887 103.20.100.0/24 AS10201 DWL-AS-IN Dishnet Wireless Limited. Broadband Wireless,IN 103.20.101.0/24 AS10201 DWL-AS-IN Dishnet Wireless Limited. Broadband Wireless,IN 103.20.219.0/24 AS55795 VERBDC1-AS-AP Verb Data Centre Pty Ltd,AU 103.23.148.0/23 AS13209 103.23.148.0/24 AS13209 103.23.149.0/24 AS13209 103.26.116.0/22 AS17676 GIGAINFRA Softbank BB Corp.,JP 103.28.184.0/22 AS4686 BEKKOAME BEKKOAME INTERNET INC.,JP 103.225.116.0/22 AS23818 JETINTERNET JETINTERNET Corporation,JP 103.232.142.0/23 AS17828 TIARE-AS-PG Tiare, a business unit of Pacific Mobile Communications.,PG 103.244.112.0/22 AS23818 JETINTERNET JETINTERNET Corporation,JP 103.248.88.0/22 AS23818 JETINTERNET JETINTERNET Corporation,JP 103.248.220.0/22 AS17676 GIGAINFRA Softbank BB Corp.,JP 103.250.0.0/22 AS17676 GIGAINFRA Softbank BB Corp.,JP 103.253.164.0/23 AS13317 111.92.184.0/22 AS9797 NEXONASIAPACIFIC-AS-AP Nexon Asia Pacific P/L,AU 116.206.72.0/24 AS6461 ABOVENET - Abovenet Communications, Inc,US 116.206.85.0/24 AS6461 ABOVENET - Abovenet Communications, Inc,US 116.206.103.0/24 AS6461 ABOVENET - Abovenet Communications, Inc,US 117.120.56.0/21 AS4755 TATACOMM-AS TATA Communications formerly VSNL is Leading ISP,IN 142.147.62.0/24 AS3958 AIRCANADA - Air Canada,CA 154.168.28.0/23 AS29571 CITelecom-AS,CI 162.216.176.0/22 AS36114 VERSAWEB-ASN - Versaweb, LLC,US 162.222.128.0/21 AS36114 VERSAWEB-ASN - Versaweb, LLC,US 162.245.64.0/21 AS62788 -Reserved AS-,ZZ 162.248.224.0/21 AS62788 -Reserved AS-,ZZ 166.93.0.0/16 AS23537 CRITIGEN - Micro Source, Inc.,US 167.146.16.0/21 AS22527 -Reserved AS-,ZZ 167.146.26.0/23 AS22527 -Reserved AS-,ZZ 167.146.28.0/23 AS22527 -Reserved AS-,ZZ 167.146.32.0/20 AS22527 -Reserved AS-,ZZ 167.146.44.0/24 AS22527 -Reserved AS-,ZZ 167.146.48.0/22 AS22527 -Reserved AS-,ZZ 167.146.90.0/24 AS22527 -Reserved AS-,ZZ 167.146.93.0/24 AS22527 -Reserved AS-,ZZ 167.146.94.0/24 AS22527 -Reserved AS-,ZZ 167.146.100.0/24 AS22527 -Reserved AS-,ZZ 167.146.104.0/24 AS22527 -Reserved AS-,ZZ 167.146.105.0/24 AS22527 -Reserved AS-,ZZ 167.146.128.0/20 AS22527 -Reserved AS-,ZZ 167.146.137.0/24 AS22527 -Reserved AS-,ZZ 167.146.144.0/20 AS22527 -Reserved AS-,ZZ 167.146.160.0/20 AS22527 -Reserved AS-,ZZ 167.146.200.0/22 AS22527 -Reserved AS-,ZZ 167.146.204.0/24 AS22527 -Reserved AS-,ZZ 167.146.205.0/24 AS22527 -Reserved AS-,ZZ 172.85.76.0/24 AS39396 GOLDKEY-CORPORATION - GoldKey Corporation,US 172.102.0.0/22 AS4812 CHINANET-SH-AP China Telecom (Group),CN 173.45.192.0/20 AS62722 -Reserved AS-,ZZ 173.45.208.0/20 AS62722 -Reserved AS-,ZZ 180.222.120.0/21 AS23818 JETINTERNET JETINTERNET Corporation,JP 185.17.98.0/23 AS19798 HILF-AS Hilf Telecom B.V.,NL 192.9.0.0/16 AS11479 BRM-SUN-AS - Sun Microsystems, Inc,US 192.25.10.0/24 AS5714 HPES - Hewlett-Packard Company,US 192.25.11.0/24 AS5714 HPES - Hewlett-Packard Company,US 192.25.13.0/24 AS5714 HPES - Hewlett-Packard Company,US 192.25.14.0/24 AS5714 HPES - Hewlett-Packard Company,US 192.34.152.0/21 AS10835 VISIONARY - Visionary Communications, Inc.,US 192.75.239.0/24 AS23498 CDSI - COGECODATA,CA 192.84.24.0/24 AS4323 TWTC - tw telecom holdings, inc.,US 192.101.70.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 192.101.71.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 192.101.72.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 192.124.252.0/22 AS680 DFN Verein zur Foerderung eines Deutschen Forschungsnetzes e.V.,DE 192.131.233.0/24 AS7018 ATT-INTERNET4 - AT&T Services, Inc.,US 192.149.81.0/24 AS14454 PERIMETER-ESECURITY - Perimeter eSecurity,US 192.154.32.0/19 AS81 NCREN - MCNC,US 192.154.64.0/19 AS81 NCREN - MCNC,US 192.166.32.0/20 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 192.188.208.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 192.245.195.0/24 AS7381 SUNGARDRS - SunGard Availability Services LP,US 193.9.59.0/24 AS1257 TELE2,SE 193.16.106.0/24 AS31539 -Reserved AS-,ZZ 193.16.145.0/24 AS31392 -Reserved AS-,ZZ 193.22.86.0/24 AS24751 MULTIFI-AS Jakobstadsnejdens Telefon Ab,FI 193.22.224.0/20 AS6824 HERMES-NETWORK Hermes Telecom International Ltd,GB 193.26.213.0/24 AS31641 BYTEL-AS Bytel Ltd,GB 193.28.14.0/24 AS34309 LINK11 Link11 GmbH,DE 193.32.23.0/24 AS2856 BT-UK-AS BT Public Internet Service,GB 193.33.6.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.33.252.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.35.101.0/24 AS57302 -Reserved AS-,ZZ 193.46.200.0/24 AS34243 WEBAGE Web Age Ltd,GB 193.56.203.0/24 AS51110 IDOMTECHNOLOGIES-AS IDOM TECHNOLOGIES,FR 193.111.229.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.149.2.0/23 AS15919 INTERHOST Servicios de Hosting en Internet S.A.,ES 193.164.152.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.176.147.0/24 AS49951 -Reserved AS-,ZZ 193.178.196.0/22 AS15657 SPEEDBONE-AS Speedbone Internet & Connectivity GmbH,DE 193.188.252.0/24 AS38968 TAGORG Abu-Ghazaleh Intellectual Property,JO 193.200.96.0/23 AS2828 XO-AS15 - XO Communications,US 193.200.244.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.201.244.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 193.201.245.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 193.201.246.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 193.202.8.0/21 AS6824 HERMES-NETWORK Hermes Telecom International Ltd,GB 193.223.103.0/24 AS8437 UTA-AS Tele2 Telecommunication GmbH,AT 193.227.109.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.227.236.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 194.6.252.0/24 AS21202 DCSNET-AS Bredband2 AB,SE 194.9.8.0/23 AS2863 SPRITELINK Centor AB,SE 194.9.8.0/24 AS2863 SPRITELINK Centor AB,SE 194.39.78.0/23 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 194.49.17.0/24 AS13135 CREW-AS Wieske's Crew GmbH,DE 194.50.8.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 194.60.88.0/21 AS5089 NTL Virgin Media Limited,GB 194.61.147.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 194.61.150.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 194.61.151.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 194.63.152.0/22 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 194.76.224.0/24 AS34701 WITZENMANN-AS Witzenmann GmbH, Pforzheim,DE 194.76.225.0/24 AS34701 WITZENMANN-AS Witzenmann GmbH, Pforzheim,DE 194.88.6.0/24 AS35093 RO-HTPASSPORT High Tech Passport Ltd SUA California San Jose SUCURSALA BUCURESTI ROMANIA,RO 194.88.226.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 194.99.67.0/24 AS9083 CARPENET carpeNet Information Technologies GmbH,DE 194.126.152.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 194.126.219.0/24 AS34545 -Reserved AS-,ZZ 194.126.233.0/24 AS31235 SKIWEBCENTER-AS SKIWEBCENTER SARL,FR 194.180.25.0/24 AS21358 ATOS-ORIGIN-DE-AS Atos Information Technology GmbH,DE 194.187.24.0/22 AS8856 UKRNET UkrNet Ltd,UA 195.8.48.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.8.48.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.42.232.0/22 AS15657 SPEEDBONE-AS Speedbone Internet & Connectivity GmbH,DE 195.85.194.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.85.201.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.110.0.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.128.240.0/23 AS21202 DCSNET-AS Bredband2 AB,SE 195.149.119.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.189.174.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.216.234.0/24 AS31309 NMV-AS New Media Ventures BVBA,BE 195.234.156.0/24 AS25028 -Reserved AS-,ZZ 195.242.182.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.244.18.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 196.3.182.0/24 AS37004 -Reserved AS-,ZZ 196.3.183.0/24 AS37004 -Reserved AS-,ZZ 196.22.8.0/24 AS27822 Emerging Markets Communications de Argentina S.R.L,AR 196.22.11.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US 198.22.195.0/24 AS54583 -Reserved AS-,ZZ 198.23.26.0/24 AS33052 VZUNET - Verizon Data Services LLC,US 198.73.226.0/23 AS62839 -Reserved AS-,ZZ 198.74.11.0/24 AS14573 KEYSPANENERGY-NE1 - Keyspan Energy,US 198.74.13.0/24 AS14573 KEYSPANENERGY-NE1 - Keyspan Energy,US 198.74.38.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services,US 198.74.39.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services,US 198.74.40.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services,US 198.97.72.0/21 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 198.97.96.0/19 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 198.97.240.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 198.163.214.0/24 AS21804 ACCESS-SK - Access Communications Co-operative Limited,CA 198.168.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 199.30.132.0/22 AS26003 -Reserved AS-,ZZ 199.38.248.0/24 AS13951 CENTER-SEVEN - C7 Data Centers, Inc.,US 199.38.249.0/24 AS13951 CENTER-SEVEN - C7 Data Centers, Inc.,US 199.38.250.0/24 AS13951 CENTER-SEVEN - C7 Data Centers, Inc.,US 199.38.251.0/24 AS13951 CENTER-SEVEN - C7 Data Centers, Inc.,US 199.38.252.0/22 AS13951 CENTER-SEVEN - C7 Data Centers, Inc.,US 199.66.15.0/24 AS30169 -Reserved AS-,ZZ 199.85.9.0/24 AS852 ASN852 - TELUS Communications Inc.,CA 199.88.52.0/22 AS17018 QTS-SACRAMENTO-1 - Quality Investment Properties Sacramento, LLC,US 199.102.240.0/24 AS18508 -Reserved AS-,ZZ 199.116.200.0/21 AS22830 -Reserved AS-,ZZ 199.121.0.0/16 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 199.123.16.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 199.233.87.0/24 AS33058 PEGASYSTEMS - Pegasystems Inc.,US 200.6.87.0/24 AS27947 Telconet S.A,EC 200.58.248.0/21 AS27849 200.81.48.0/24 AS11664 Techtel LMDS Comunicaciones Interactivas S.A.,AR 200.81.49.0/24 AS11664 Techtel LMDS Comunicaciones Interactivas S.A.,AR 202.3.75.0/24 AS18172 202.3.76.0/24 AS18172 202.8.106.0/24 AS9530 SHINSEGAE-AS SHINSEGAE I&C Co., Ltd.,KR 202.45.10.0/23 AS24327 202.45.10.0/24 AS24327 202.45.11.0/24 AS24327 202.53.138.0/24 AS4058 CITICTEL-CPC-AS4058 CITIC Telecom International CPC Limited,HK 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network,CN 202.122.134.0/24 AS38615 202.140.147.0/24 AS9583 SIFY-AS-IN Sify Limited,IN 202.158.251.0/24 AS9255 CONNECTPLUS-AS Singapore Telecom,SG 202.165.124.0/24 AS23749 GLOBAL-TRANSIT-AS-HKCOLO-AP HKCOLO ltd. Internet Service Provider,HK 202.179.134.0/24 AS23966 LDN-AS-PK LINKdotNET Telecom Limited,PK 203.142.219.0/24 AS45149 203.175.11.0/24 AS9229 SPEEDCAST-AP SPEEDCAST Limited,HK 203.189.116.0/22 AS45606 203.189.116.0/24 AS45606 203.189.117.0/24 AS45606 203.189.118.0/24 AS45606 203.189.119.0/24 AS45606 204.10.88.0/21 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 204.15.208.0/22 AS13706 COMPLETEWEBNET - CompleteWeb.Net LLC,US 204.16.96.0/24 AS19972 -Reserved AS-,ZZ 204.16.97.0/24 AS19972 -Reserved AS-,ZZ 204.16.98.0/24 AS19972 -Reserved AS-,ZZ 204.16.99.0/24 AS19972 -Reserved AS-,ZZ 204.69.139.0/24 AS40250 -Reserved AS-,ZZ 204.69.144.0/24 AS27283 RJF-INTERNET - Raymond James Financial, Inc.,US 204.86.196.0/23 AS14372 -Reserved AS-,ZZ 204.86.198.0/23 AS33058 PEGASYSTEMS - Pegasystems Inc.,US 204.87.251.0/24 AS22217 -Reserved AS-,ZZ 204.106.16.0/24 AS4323 TWTC - tw telecom holdings, inc.,US 204.187.11.0/24 AS51113 ELEKTA-AS Elekta,GB 204.235.245.0/24 AS22613 -Reserved AS-,ZZ 205.137.240.0/20 AS11686 ENA - Education Networks of America,US 205.159.44.0/24 AS40157 ADESA-CORP-AS - ADESA Corp,US 205.166.231.0/24 AS7029 WINDSTREAM - Windstream Communications Inc,US 205.211.160.0/24 AS30045 UHN-ASN - University Health Network,CA 206.197.184.0/24 AS23304 DATOTEL-STL-AS - Datotel LLC, a NetLabs LLC Company,US 207.2.120.0/21 AS6221 USCYBERSITES - US Cybersites, Inc,US 207.174.131.0/24 AS26116 INDRA - Indra's Net Inc,US 207.174.132.0/23 AS26116 INDRA - Indra's Net Inc,US 207.174.152.0/23 AS26116 INDRA - Indra's Net Inc,US 207.174.154.0/24 AS26116 INDRA - Indra's Net Inc,US 207.174.155.0/24 AS26116 INDRA - Indra's Net Inc,US 207.174.200.0/24 AS22658 EARTHNET - Earthnet, Inc.,US 207.231.96.0/19 AS11194 NUNETPA - NuNet Inc.,US 207.254.128.0/21 AS30689 FLOW-NET - FLOW,JM 207.254.136.0/21 AS30689 FLOW-NET - FLOW,JM 208.66.64.0/24 AS16936 -Reserved AS-,ZZ 208.66.65.0/24 AS16936 -Reserved AS-,ZZ 208.66.66.0/24 AS16936 -Reserved AS-,ZZ 208.66.67.0/24 AS16936 -Reserved AS-,ZZ 208.67.132.0/22 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 208.73.40.0/22 AS19901 -Reserved AS-,ZZ 208.73.41.0/24 AS19901 -Reserved AS-,ZZ 208.75.152.0/21 AS32146 -Reserved AS-,ZZ 208.76.20.0/24 AS31812 -Reserved AS-,ZZ 208.76.21.0/24 AS31812 -Reserved AS-,ZZ 208.77.164.0/24 AS22659 -Reserved AS-,ZZ 208.77.166.0/24 AS4323 TWTC - tw telecom holdings, inc.,US 208.83.53.0/24 AS40569 YGOMI-AS - Ygomi LLC,US 208.84.232.0/24 AS33131 -Reserved AS-,ZZ 208.84.233.0/24 AS33131 -Reserved AS-,ZZ 208.84.234.0/24 AS33131 -Reserved AS-,ZZ 208.84.237.0/24 AS33131 -Reserved AS-,ZZ 208.93.216.0/22 AS209 CENTURYLINK-US-LEGACY-QWEST - Qwest Communications Company, LLC,US 208.94.216.0/23 AS13629 -Reserved AS-,ZZ 208.94.219.0/24 AS13629 -Reserved AS-,ZZ 208.94.221.0/24 AS13629 -Reserved AS-,ZZ 208.94.223.0/24 AS13629 -Reserved AS-,ZZ 209.135.171.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 209.135.175.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 209.177.64.0/20 AS6461 ABOVENET - Abovenet Communications, Inc,US 209.193.112.0/20 AS209 CENTURYLINK-US-LEGACY-QWEST - Qwest Communications Company, LLC,US 209.209.51.0/24 AS18687 MPOWER-2 - MPOWER COMMUNICATIONS CORP.,US 209.234.112.0/23 AS32252 -Reserved AS-,ZZ 209.234.114.0/23 AS32252 -Reserved AS-,ZZ 209.234.116.0/24 AS32252 -Reserved AS-,ZZ 209.234.117.0/24 AS32252 -Reserved AS-,ZZ 209.234.118.0/24 AS32252 -Reserved AS-,ZZ 209.234.119.0/24 AS32252 -Reserved AS-,ZZ 209.234.120.0/24 AS32252 -Reserved AS-,ZZ 209.234.121.0/24 AS32252 -Reserved AS-,ZZ 209.234.122.0/24 AS32252 -Reserved AS-,ZZ 213.255.128.0/20 AS24863 LINKdotNET-AS,EG 213.255.144.0/20 AS24863 LINKdotNET-AS,EG 216.73.81.0/24 AS6432 DOUBLECLICK - Double Click, Inc.,US 216.73.82.0/24 AS6432 DOUBLECLICK - Double Click, Inc.,US 216.73.85.0/24 AS6432 DOUBLECLICK - Double Click, Inc.,US 216.73.88.0/24 AS6432 DOUBLECLICK - Double Click, Inc.,US 216.73.89.0/24 AS6432 DOUBLECLICK - Double Click, Inc.,US 216.73.94.0/24 AS6432 DOUBLECLICK - Double Click, Inc.,US 216.73.95.0/24 AS6432 DOUBLECLICK - Double Click, Inc.,US 216.146.0.0/19 AS11915 US-TELEPACIFIC - TelePacific Communications,US 216.152.24.0/22 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc.,US 216.170.96.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc.,US 216.170.101.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc.,US 216.170.104.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc.,US 216.170.105.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc.,US 216.234.132.0/24 AS14545 ADR-DRIVING-RECORDS - AMERICAN DRIVING RECORDS, INC.,US 216.238.192.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 216.238.193.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 216.238.194.0/24 AS26566 -Reserved AS-,ZZ 216.238.196.0/22 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 216.251.50.0/24 AS38191 INFOSYS-AS Infosys Technologies Ltd,IN 216.251.53.0/24 AS38191 INFOSYS-AS Infosys Technologies Ltd,IN 216.251.62.0/24 AS38191 INFOSYS-AS Infosys Technologies Ltd,IN Please see http://www.cidr-report.org for the full report ------------------------------------ Copies of this report are mailed to: nanog at nanog.org 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 22:00:01 2015 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 29 May 2015 22:00:01 GMT Subject: BGP Update Report Message-ID: <201505292200.t4TM01b8025425@wattle.apnic.net> BGP Update Report Interval: 21-May-15 -to- 28-May-15 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS23752 275716 5.3% 1955.4 -- NPTELECOM-NP-AS Nepal Telecommunications Corporation, Internet Services,NP 2 - AS9829 221337 4.3% 151.1 -- BSNL-NIB National Internet Backbone,IN 3 - AS45609 138146 2.7% 218.9 -- BHARTI-MOBILITY-AS-AP Bharti Airtel Ltd. AS for GPRS Service,IN 4 - AS22059 114111 2.2% 16301.6 -- APVIO-1 - Apvio, Inc.,US 5 - AS7552 94697 1.8% 144.8 -- VIETEL-AS-AP Viettel Corporation,VN 6 - AS35819 82526 1.6% 221.2 -- MOBILY-AS Etihad Etisalat Company (Mobily),SA 7 - AS36947 82208 1.6% 544.4 -- ALGTEL-AS,DZ 8 - AS48159 79680 1.5% 237.1 -- TIC-AS Telecommunication Infrastructure Company,IR 9 - AS45899 68492 1.3% 100.9 -- VNPT-AS-VN VNPT Corp,VN 10 - AS3709 58923 1.1% 2182.3 -- NET-CITY-SA - City of San Antonio,US 11 - AS54169 56589 1.1% 18863.0 -- MGH-ION-1 - Marin General Hospital,US 12 - AS376 52734 1.0% 206.8 -- RISQ-AS - Reseau d'informations scientifiques du Quebec (RISQ),CA 13 - AS6057 37545 0.7% 180.5 -- Administracion Nacional de Telecomunicaciones,UY 14 - AS10620 37013 0.7% 11.6 -- Telmex Colombia S.A.,CO 15 - AS8402 32344 0.6% 89.1 -- CORBINA-AS OJSC "Vimpelcom",RU 16 - AS50710 32007 0.6% 174.0 -- EARTHLINK-AS EarthLink Ltd. Communications&Internet Services,IQ 17 - AS9021 29997 0.6% 357.1 -- ISNET Is Net Elektonik Bilgi Uretim Dagitim Ticaret ve Iletisim Hizmetleri A.S.,TR 18 - AS7643 28565 0.6% 114.7 -- VNPT-AS-VN Vietnam Posts and Telecommunications (VNPT),VN 19 - AS26821 25549 0.5% 2838.8 -- REVNET - Revelation Networks, Inc.,US 20 - AS3816 24693 0.5% 47.1 -- COLOMBIA TELECOMUNICACIONES S.A. ESP,CO TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS54169 56589 1.1% 18863.0 -- MGH-ION-1 - Marin General Hospital,US 2 - AS22059 114111 2.2% 16301.6 -- APVIO-1 - Apvio, Inc.,US 3 - AS197914 15608 0.3% 15608.0 -- STOCKHO-AS Stockho Hosting SARL,FR 4 - AS393588 9659 0.2% 9659.0 -- MUBEA-FLO - Mubea,US 5 - AS1757 8092 0.2% 8092.0 -- LEXIS-AS - LexisNexis,US 6 - AS47680 7700 0.1% 7700.0 -- NHCS EOBO Limited,IE 7 - AS61039 7137 0.1% 7137.0 -- ZMZ OAO ZMZ,RU 8 - AS1466 5793 0.1% 5793.0 -- DNIC-AS-01466 - Headquarters, USAISC,US 9 - AS13483 11227 0.2% 5613.5 -- INFOR-AS13483 - INFOR GLOBAL SOLUTIONS (MICHIGAN), INC.,US 10 - AS31357 10834 0.2% 3611.3 -- TOMICA-AS Tomsk Information and Consulting Agency,RU 11 - AS23342 3407 0.1% 3407.0 -- UNITEDLAYER - Unitedlayer, Inc.,US 12 - AS18135 10219 0.2% 3406.3 -- BTV BTV Cable television,JP 13 - AS25563 9792 0.2% 3264.0 -- WEBLAND-AS Webland AG,CH 14 - AS33440 12840 0.2% 3210.0 -- WEBRULON-NETWORK - webRulon, LLC,US 15 - AS63502 3055 0.1% 3055.0 -- DHECYBER-NET PT. Dhecyber Flow Indonesia,ID 16 - AS26821 25549 0.5% 2838.8 -- REVNET - Revelation Networks, Inc.,US 17 - AS2109 8166 0.2% 2722.0 -- TDC TDC A/S,DK 18 - AS39920 2716 0.1% 2716.0 -- RUTDN-AS CJSC "Digital Transport Networks",RU 19 - AS3709 58923 1.1% 2182.3 -- NET-CITY-SA - City of San Antonio,US 20 - AS23752 275716 5.3% 1955.4 -- NPTELECOM-NP-AS Nepal Telecommunications Corporation, Internet Services,NP TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 202.70.88.0/21 136253 2.5% AS23752 -- NPTELECOM-NP-AS Nepal Telecommunications Corporation, Internet Services,NP 2 - 202.70.64.0/21 135072 2.5% AS23752 -- NPTELECOM-NP-AS Nepal Telecommunications Corporation, Internet Services,NP 3 - 105.96.0.0/22 80705 1.5% AS36947 -- ALGTEL-AS,DZ 4 - 76.191.107.0/24 57050 1.1% AS22059 -- APVIO-1 - Apvio, Inc.,US 5 - 64.34.125.0/24 57014 1.1% AS22059 -- APVIO-1 - Apvio, Inc.,US 6 - 204.80.242.0/24 56586 1.1% AS54169 -- MGH-ION-1 - Marin General Hospital,US 7 - 130.0.192.0/21 15608 0.3% AS197914 -- STOCKHO-AS Stockho Hosting SARL,FR 8 - 78.140.0.0/18 10811 0.2% AS31357 -- TOMICA-AS Tomsk Information and Consulting Agency,RU 9 - 42.83.48.0/20 10215 0.2% AS18135 -- BTV BTV Cable television,JP 10 - 192.58.137.0/24 9659 0.2% AS393588 -- MUBEA-FLO - Mubea,US 11 - 192.58.232.0/24 8837 0.2% AS6629 -- NOAA-AS - NOAA,US 12 - 198.185.16.0/24 8092 0.1% AS1757 -- LEXIS-AS - LexisNexis,US 13 - 88.87.160.0/19 7700 0.1% AS47680 -- NHCS EOBO Limited,IE 14 - 202.53.67.0/24 7476 0.1% AS10225 -- NETTLINX-IN-AP Nettlinx Limited,IN 15 - 94.73.56.0/21 7318 0.1% AS42081 -- SPEEDY-NET-AS Speedy net EAD,BG 16 - 91.235.169.0/24 7137 0.1% AS61039 -- ZMZ OAO ZMZ,RU 17 - 203.175.5.0/24 6543 0.1% AS38000 -- CRISIL-AS [CRISIL Limited.Autonomous System],IN 18 - 159.172.39.0/24 6485 0.1% AS13483 -- INFOR-AS13483 - INFOR GLOBAL SOLUTIONS (MICHIGAN), INC.,US 19 - 106.222.144.0/20 6316 0.1% AS45609 -- BHARTI-MOBILITY-AS-AP Bharti Airtel Ltd. AS for GPRS Service,IN 20 - 106.222.48.0/20 6308 0.1% AS45609 -- BHARTI-MOBILITY-AS-AP Bharti Airtel Ltd. AS for GPRS Service,IN Details at http://bgpupdates.potaroo.net ------------------------------------ Copies of this report are mailed to: nanog at nanog.org eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From owen at delong.com Sat May 30 01:04:25 2015 From: owen at delong.com (Owen DeLong) Date: Fri, 29 May 2015 18:04:25 -0700 Subject: AWS Elastic IP architecture In-Reply-To: References: Message-ID: <0FBA59E3-5EA1-4605-8418-EAC5D2564DB6@delong.com> > On May 29, 2015, at 8:23 AM, Christopher Morrow wrote: > > On Fri, May 29, 2015 at 3:45 AM, Owen DeLong wrote: >> Yeah, if it were LISP, they could probably handle IPv6. > > why can't they do v6 with any other encap? That?s not my point. > the encap really doesn't matter at all to the underlying ip protocol > used, or shouldn't... you decide at the entrance to the 'virtual > network' that 'thingy is in virtual-network-5 and encap the packet... > regardless of ip version of the thing you are encapsulating. Whatever encapsulation or other system they are using, clearly they can?t do IPv6 for some reason because they outright refuse to even offer so much as a verification that IPv6 is on any sort of roadmap or is at all likely to be considered for deployment any time in the foreseeable future. So, my point wasn?t that LISP is the only encapsulation that supports IPv6. Indeed, I didn?t even say that. What I said was that their apparent complete inability to do IPv6 makes it unlikely that they are using an IPv6-capable encapsulation system. Thus, it is unlikely they are using LISP. I only referenced LISP because it was specifically mentioned by the poster to whom I was responding. Please try to avoid putting words in my mouth in the future. Owen From morrowc.lists at gmail.com Sat May 30 01:14:28 2015 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Fri, 29 May 2015 21:14:28 -0400 Subject: AWS Elastic IP architecture In-Reply-To: <0FBA59E3-5EA1-4605-8418-EAC5D2564DB6@delong.com> References: <0FBA59E3-5EA1-4605-8418-EAC5D2564DB6@delong.com> Message-ID: i love that you are always combative, it makes for great tv. On Fri, May 29, 2015 at 9:04 PM, Owen DeLong wrote: > >> On May 29, 2015, at 8:23 AM, Christopher Morrow wrote: >> >> On Fri, May 29, 2015 at 3:45 AM, Owen DeLong wrote: >>> Yeah, if it were LISP, they could probably handle IPv6. >> >> why can't they do v6 with any other encap? > > That?s not my point. > sort of seemed like part of your point. >> the encap really doesn't matter at all to the underlying ip protocol >> used, or shouldn't... you decide at the entrance to the 'virtual >> network' that 'thingy is in virtual-network-5 and encap the packet... >> regardless of ip version of the thing you are encapsulating. > > Whatever encapsulation or other system they are using, clearly they can?t do IPv6 for some reason because they outright refuse to even offer so much as a verification that IPv6 is on any sort of roadmap or is at all likely to be considered for deployment any time in the foreseeable future. > it's totally possible that they DO LISP and simply disable ipv6 for some other unspecified reason too, right? Maybe they are just on a jihad against larger ip numbers? or their keyboards have no colons? > So, my point wasn?t that LISP is the only encapsulation that supports IPv6. Indeed, I didn?t even say that. What I said was that their apparent complete inability to do IPv6 makes it unlikely that they are using an IPv6-capable encapsulation system. Thus, it is unlikely they are using LISP. I only referenced LISP because it was specifically mentioned by the poster to whom I was responding. > > Please try to avoid putting words in my mouth in the future. > you have so many words there already it's going to be fun fitting more in if I did try. have a swell weekend! > From owen at delong.com Sat May 30 01:11:37 2015 From: owen at delong.com (Owen DeLong) Date: Fri, 29 May 2015 18:11:37 -0700 Subject: gmail security is a joke In-Reply-To: <21864.42271.96532.454022@world.std.com> References: <5564829E.1000006@truemetal.org> <20150526152246.GA12876@pob.ytti.fi> <312D54C4-EC72-4A3F-87FC-357AFA61D04A@delong.com> <55655311.3020403@alvarezp.org> <20150528211855.GA21216@gsp.org> <21864.42271.96532.454022@world.std.com> Message-ID: <8A814D11-C84C-485F-A019-78972DEF5746@delong.com> Use a ghost writer. ;-) Owen > On May 29, 2015, at 10:42 AM, Barry Shein wrote: > > > I can't write my autobiography because it'd contain the answers to too > many security questions! > > -- > -Barry Shein > > The World | bzs at TheWorld.com | http://www.TheWorld.com > Purveyors to the Trade | Voice: 800-THE-WRLD | Dial-Up: US, PR, Canada > Software Tool & Die | Public Access Internet | SINCE 1989 *oo* From rsk at gsp.org Sat May 30 01:31:02 2015 From: rsk at gsp.org (Rich Kulawiec) Date: Fri, 29 May 2015 21:31:02 -0400 Subject: gmail security is a joke In-Reply-To: References: <5564829E.1000006@truemetal.org> <20150526152246.GA12876@pob.ytti.fi> <312D54C4-EC72-4A3F-87FC-357AFA61D04A@delong.com> <55655311.3020403@alvarezp.org> <20150528211855.GA21216@gsp.org> Message-ID: <20150530013101.GA25108@gsp.org> On Fri, May 29, 2015 at 12:32:34PM -0400, Justin M. Streiner wrote: > There are providers (banks, etc) who will disable an online account that > has had X failed login attempts. While that's good for preventing > $bad_guy from continuing to try to brute-force-guess the password, > it creates a nominal DoS condition for the legitimate owner who then > has to contact the provider and go through their password reset > procedure. This is why automatic lockout procedures are a problem for some operations, particularly those which are known to create user account names based on algorithms like "first initial + last name, truncated to 8 characters". It's not at all difficult to construct a list of valid (or probably-valid) usernames at such sites, hit them all repeatedly from distributed botnets (N-1 times from any one address, where N times would trigger IP-based blocking methods) and thus effectively DoS a decent fraction of the users. ---rsk From owen at delong.com Sat May 30 01:27:48 2015 From: owen at delong.com (Owen DeLong) Date: Fri, 29 May 2015 18:27:48 -0700 Subject: AWS Elastic IP architecture In-Reply-To: References: <6C73DCAB-235C-4070-BE5F-729E9D78B56F@delong.com> Message-ID: <4B6D09B7-5EF0-46C0-951C-117212DD3B5E@delong.com> > On May 29, 2015, at 8:27 AM, Christopher Morrow wrote: > > On Fri, May 29, 2015 at 4:22 AM, Owen DeLong wrote: >> Why do you assume some encap/decap process somewhere in this process? > > why do you think they have a single 10/8 deployment per location and > not per customer? if it' sper customer, they have to provide some > encap (I'd think) to avoid lots and lots of headaches. I don't imagine > that if aws/ec2 is 'millions of customers' running on 'cheapest > ethernet reference platform possible' they can do much fancy stuff > with respect to virtual networking. I'd expect almost all of that to > have to happen at the vm-host (not the guest), and that there's just > some very simple encapsulation of traffic from the 'edge' to the > vm-host and then 'native' (for some sense of that word) up to the > 'vm'. Because that?s what one of their engineers told me at one point in the past. Admittedly, it may have changed. My understanding was along the lines of a very large flat L2 space among the VM Hosts with minimal routing on the hosts and a whole lot of /32 routes. Again, my information may be incomplete, obsolete, or incorrect. Memories of bar conversations get fuzzy after 12+ months. Owen From owen at delong.com Sat May 30 01:34:06 2015 From: owen at delong.com (Owen DeLong) Date: Fri, 29 May 2015 18:34:06 -0700 Subject: stacking pdu In-Reply-To: <5568DEA0.6010802@monmotha.net> References: <5568DEA0.6010802@monmotha.net> Message-ID: <67A7A59F-23A5-4870-A0FE-FB61212DBE8E@delong.com> > On May 29, 2015, at 2:48 PM, Brandon Martin wrote: > > On 05/29/2015 05:29 PM, William Herrin wrote: >> On Fri, May 29, 2015 at 4:32 PM, shawn wilson wrote: >>> Is there a way to stack PDUs? like, with 30A 220, we need more plugs >>> than power but I'd like them to communicate to make sure we don't over >>> power the circuit. Do any APC or Triplite systems support this? >> >> Isn't it against the NEC and the fire code to stack power strips? We >> all do it, but isn't it against code? > > It sounds like he's asking for a PDU specifically intended to be used with managed expansion/stacking type modules. That would be permissible per NEC and most local fire codes as the device would be specifically listed for such usage. I've seen something like this inside blade/modular racks like IBM Flex systems, but unfortunately I don't know of any such off-the-shelf parts. > > It would seem entirely reasonable to take a 30A/240V feed on a 6-30 or 14-30 type connection and break it out to numerous either C13 or 6-15/5-15 style sockets, possibly on a modular basis using some sort of proprietary power+data connections for the breakout. E.g. if you needed to mix 120V and 240V devices in a rack, you could get 5-15 and 6-15 breakouts with each individual outlet switched and maintain whole-rack metering. > > Sounds like a really handy device, if one exists COTS. > -- > Brandon Martin If I read it correctly, stacking PDUs is perfectly acceptable so long as the breaker feeding each subordinate PDU is sized no larger than the maximum current that can be safely delivered to that PDU. However, adding extension cords or other ?temporary power extenders? on a permanent basis is also unacceptable and most PDU stacking of the type being contemplated here involves deploying the subordinate PDU in a way that ends up being essentially an ?extension cord? for this purpose. Owen From owen at delong.com Sat May 30 01:45:01 2015 From: owen at delong.com (Owen DeLong) Date: Fri, 29 May 2015 18:45:01 -0700 Subject: AWS Elastic IP architecture In-Reply-To: References: <0FBA59E3-5EA1-4605-8418-EAC5D2564DB6@delong.com> Message-ID: <93B91051-04B2-4251-A06F-AC5F4609E8F2@delong.com> > On May 29, 2015, at 6:14 PM, Christopher Morrow wrote: > > i love that you are always combative, it makes for great tv. > > On Fri, May 29, 2015 at 9:04 PM, Owen DeLong wrote: >> >>> On May 29, 2015, at 8:23 AM, Christopher Morrow wrote: >>> >>> On Fri, May 29, 2015 at 3:45 AM, Owen DeLong wrote: >>>> Yeah, if it were LISP, they could probably handle IPv6. >>> >>> why can't they do v6 with any other encap? >> >> That?s not my point. >> > > sort of seemed like part of your point. > I swear, it really wasn?t. >>> the encap really doesn't matter at all to the underlying ip protocol >>> used, or shouldn't... you decide at the entrance to the 'virtual >>> network' that 'thingy is in virtual-network-5 and encap the packet... >>> regardless of ip version of the thing you are encapsulating. >> >> Whatever encapsulation or other system they are using, clearly they can?t do IPv6 for some reason because they outright refuse to even offer so much as a verification that IPv6 is on any sort of roadmap or is at all likely to be considered for deployment any time in the foreseeable future. >> > > it's totally possible that they DO LISP and simply disable ipv6 for > some other unspecified reason too, right? Maybe they are just on a > jihad against larger ip numbers? or their keyboards have no colons? I suppose, but according to statements made by their engineers, it has to do with the ?way that they have structured their backend networks to the virtual hosts?. I?m pretty sure that I?ve ruled the last two out based on discussions I?ve had with their engineers, but you?re right, I was probably a little more glib about it than was 100% accurate. Bottom line, however, is it doesn?t matter what the reason, they are utterly incapable of doing IPv6 and utterly and completely unrepentant about it. > >> So, my point wasn?t that LISP is the only encapsulation that supports IPv6. Indeed, I didn?t even say that. What I said was that their apparent complete inability to do IPv6 makes it unlikely that they are using an IPv6-capable encapsulation system. Thus, it is unlikely they are using LISP. I only referenced LISP because it was specifically mentioned by the poster to whom I was responding. >> >> Please try to avoid putting words in my mouth in the future. >> > > you have so many words there already it's going to be fun fitting more > in if I did try. LoL > > have a swell weekend! You too. Owen From mysidia at gmail.com Sat May 30 02:30:34 2015 From: mysidia at gmail.com (Jimmy Hess) Date: Fri, 29 May 2015 21:30:34 -0500 Subject: gmail security is a joke In-Reply-To: References: <5564829E.1000006@truemetal.org> <20150526152246.GA12876@pob.ytti.fi> <312D54C4-EC72-4A3F-87FC-357AFA61D04A@delong.com> <55655311.3020403@alvarezp.org> <20150528211855.GA21216@gsp.org> Message-ID: On Fri, May 29, 2015 at 1:42 AM, Joe Abley wrote: > That's what I should do. Instead, I pull down the list of candidate > questions and think to myself... ... > - I don't have a favourite colour My favourite color is Red, but the answer is rejected because it's less than 6 characters long; it turns out your favorite color can be Yellow, Orange, or Purple, but not Blue, Green, Gray, or Pink. > and around this point, I start to think > - I am going to look for amusing cats on youtube After finding one, now you have a favorite pet.... I suggest generating a random string for secret answer questions, just as if it was another password. Write down the answers; stick them in a lockbox. Some websites will prompt for the answers during normal login later as if answering personal questions was some legitimate way to confirm a login from an "untrusted" computer....... in that case, save a copy as secure notes in the password vault, Or put the answers to a .txt file encrypt - using GPG. It is a bit bogus: the whole notion of asking in a format where the response can easily be automatically entered, for authentication purposes, the sort of questions about you that would be easily looked up using public records, or that distant acquaintenances and former schoolmates would know the answers to... There is an improvement in use cases where the traditional response is just to accept the request and e-mail a new temporary password. In cases where "the answer" is used as if it was a second factor, that's fairly obnoxious and generating a false sense of security in the process. In cases where it can be used to reset password directly or call in over the phone and reset a password or change the account --- the strength of the password is weakened to the strength of the weakest security answer. > Joe -- -JH From randy at psg.com Sat May 30 02:49:25 2015 From: randy at psg.com (Randy Bush) Date: Sat, 30 May 2015 04:49:25 +0200 Subject: westin hotel network Message-ID: ryuu.psg.com:/Users/randy> ping rsync.tools.ietf.org PING zinfandel.tools.ietf.org (64.170.98.42): 56 data bytes 64 bytes from 64.170.98.42: icmp_seq=0 ttl=53 time=11.751 ms 64 bytes from 64.170.98.42: icmp_seq=1 ttl=53 time=12.207 ms 64 bytes from 64.170.98.42: icmp_seq=2 ttl=53 time=11.444 ms 64 bytes from 64.170.98.42: icmp_seq=3 ttl=53 time=12.963 ms ^C --- zinfandel.tools.ietf.org ping statistics --- 4 packets transmitted, 4 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 11.444/12.091/12.963/0.572 ms ryuu.psg.com:/Users/randy> rsync -vaHx --delete rsync.tools.ietf.org::xml2rfc.bibxml/bibxml3 $HOME/refs/id rsync: failed to connect to rsync.tools.ietf.org: Host is down (64) rsync error: error in socket IO (code 10) at /SourceCache/rsync/rsync-45/rsync/clientserver.c(105) [receiver=2.6.9] sheesh! From baldur.norddahl at gmail.com Sat May 30 07:07:47 2015 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Sat, 30 May 2015 09:07:47 +0200 Subject: AWS Elastic IP architecture In-Reply-To: <93B91051-04B2-4251-A06F-AC5F4609E8F2@delong.com> References: <0FBA59E3-5EA1-4605-8418-EAC5D2564DB6@delong.com> <93B91051-04B2-4251-A06F-AC5F4609E8F2@delong.com> Message-ID: They could do 6rd by just flipping a switch on one of their routers. Granted it is not native IPv6 but maybe better than nothing. Regards Baldur From bmanning at karoshi.com Sat May 30 11:21:53 2015 From: bmanning at karoshi.com (manning) Date: Sat, 30 May 2015 04:21:53 -0700 Subject: westin hotel network In-Reply-To: References: Message-ID: <535F314F-C0D6-4B1D-8243-7381D7E143BE@karoshi.com> so? bring your own avian carriers? manning bmanning at karoshi.com PO Box 12317 Marina del Rey, CA 90295 310.322.8102 On 29May2015Friday, at 19:49, Randy Bush wrote: > ryuu.psg.com:/Users/randy> ping rsync.tools.ietf.org > PING zinfandel.tools.ietf.org (64.170.98.42): 56 data bytes > 64 bytes from 64.170.98.42: icmp_seq=0 ttl=53 time=11.751 ms > 64 bytes from 64.170.98.42: icmp_seq=1 ttl=53 time=12.207 ms > 64 bytes from 64.170.98.42: icmp_seq=2 ttl=53 time=11.444 ms > 64 bytes from 64.170.98.42: icmp_seq=3 ttl=53 time=12.963 ms > ^C > --- zinfandel.tools.ietf.org ping statistics --- > 4 packets transmitted, 4 packets received, 0.0% packet loss > round-trip min/avg/max/stddev = 11.444/12.091/12.963/0.572 ms > > ryuu.psg.com:/Users/randy> rsync -vaHx --delete rsync.tools.ietf.org::xml2rfc.bibxml/bibxml3 $HOME/refs/id > rsync: failed to connect to rsync.tools.ietf.org: Host is down (64) > rsync error: error in socket IO (code 10) at /SourceCache/rsync/rsync-45/rsync/clientserver.c(105) [receiver=2.6.9] > > sheesh! From bruce.curtis at ndsu.edu Sat May 30 12:06:26 2015 From: bruce.curtis at ndsu.edu (Bruce Curtis) Date: Sat, 30 May 2015 12:06:26 +0000 Subject: Multiple vendors' IPv6 issues In-Reply-To: <051201d0984a$b8f61040$2ae230c0$@tndh.net> References: <051201d0984a$b8f61040$2ae230c0$@tndh.net> Message-ID: On May 27, 2015, at 1:59 AM, Tony Hain wrote: > David, > > While I agree with you that there is no excuse for the general IPv6 brokenness across all vendors, they are just doing what participants on lists like this one tell them. Name&Shame may help a little, but until a large number of people get serious and stop prioritizing IPv4 in their purchasing demands, the vendors are not going to prioritize IPv6. Until the vendors clearly hear a collective "we are not buying this product because IPv6 is broken", everyone will get exactly the behavior you are witnessing. > > While I appreciate the challenges you are facing, it is likely that you will be helped by documenting the percentage of IPv6 traffic you see when things do work. While it may not be much now, that can change quickly and will provide internal ammunition when you try to take a stand about refusing to use a product. If your IPv6 percentage grows anywhere near the 2x/yr rate that Google has been seeing it won't take long before IPv6 is the driving protocol. For fun, project this > http://www.google.com/intl/en/ipv6/statistics.html forward 4 years and hand it to the vendors that can't get their IPv6 act together. Then ask them how they plan to still be in business at that point ...... > > Tony I like this page even better for that purpose. It does the forward projecting for you and projects 33% in one year and above 90% in 4 years. https://www.vyncke.org/ipv6status/project.php?metric=q&country=us This says that 45% of web pages viewed by people worldwide are available via IPv6 (It does not say that 45% of web pages are available via IPv6, it says that since Facebook and others, which are IPv6 enabled, have more page views than some less popular sites that are IPv4 only and that results in 45% of web pages viewed being available via IPv6.) http://6lab.cisco.com/stats/ http://6lab.cisco.com/stats/information.php#content It is also interesting to sort this page by IPv6 percent. http://www.stateoftheinternet.com/trends-visualizations-ipv6-adoption-ipv4-exhaustion-global-heat-map-network-country-growth-data.html#networks > -----Original Message----- >> From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of David >> Sotnick >> Sent: Tuesday, May 26, 2015 4:19 PM >> To: NANOG >> Subject: Multiple vendors' IPv6 issues >> >> Hi NANOG, >> >> The company I work for has no business case for being on the IPv6-Internet. >> However, I am an inquisitive person and I am always looking to learn new >> things, so about 3 years ago I started down the IPv6 path. This was early >> 2012. >> >> Fast forward to today. We have a /44 presence for our company's multiple >> sites; All our desktop computers have been on the IPv6 Internet since June, >> 2012 and we have a few AAAAs in our external DNS for some key services ? >> and, there have been bugs. *Lots* of bugs. >> >> Now, maybe (_maybe_) I can have some sympathy for smaller network >> companies (like Arista Networks at the time) to not quite have their act >> together as far as IPv6 goes, but for larger, well-established companies to >> still have critical IPv6 bugs is just inexcusable! >> >> This month has just been the most disheartening time working with IPv6. >> >> Vendor 1: >> >> Aruba Networks. Upon adding an IPv6 address to start managing our WiFi >> controller over IPv6, I receive a call from our Telecom Lead saying that or >> WiFi VoIP phones have just gone offline. WHAT? All I did was add an IPv6 >> address to a management interface which has *nothing* to do with our VoIP >> system or SSID, ACLs, policies, roles, etc. >> >> Vendor 2: >> >> Palo Alto Networks: After upgrading our firewalls from a version which has a >> nasty bug where the IPv6 neighbor table wasn't being cleaned up properly >> (which would overflow the table and break IPv6), we now have a *new* >> IPv6 neighbor discovery bug where one of our V6-enabled DMZ hosts just >> falls of the IPv6 network. The only solution: clear the neighbor table on the >> Palo Alto or the client (linux) host. >> >> Vendor 3: >> >> Arista Networks: We are seeing a very similar ND bug with Arista. This one is >> slightly more interesting because it only started after upgrading our Arista >> EOS code ? and it only appears to affect Virtual Machines which are behind >> our RedHat Enterprise Virtualization cluster. None of the hundreds of >> VMware-connected hosts are affected. The symptom is basically the same >> as the Palo Alto bug. Neighbor table gets in some weird state where ND >> breaks and the host is unreachable until the neighbor table is cleared. >> >> Oh, and the final straw today, which is *almost* leading me to throw in the >> IPv6 towel completely (for now): On certain hosts (VMs), scp'ing a file over >> the [Arista] LAN (10 gigabit LAN) takes 5 minutes over IPv6 and <1 second >> over IPv4. What happened? >> >> It really saddens me that it is still not receiving anywhere near the kind of >> QA (partly as a result of lack of adoption) that IPv4 has. >> >> Oh, and let's not forget everybody's "favorite" vendor, Cisco. Why is it, >> Cisco, that I have to restart my IPv6 OSPF3 process on my ASA every time my >> Palo Alto firewall crashes and fails over, otherwise none of my VPN clients >> can connect via IPv6? >> >> Why do you hurt me so, IPv6? I just wanted to be friends, and now I just >> want to break up with you. Maybe we can try to be friends again when your >> vendors get their shit together. >> >> -David > --- Bruce Curtis bruce.curtis at ndsu.edu Certified NetAnalyst II 701-231-8527 North Dakota State University From laurent at guerby.net Sat May 30 16:09:14 2015 From: laurent at guerby.net (Laurent GUERBY) Date: Sat, 30 May 2015 18:09:14 +0200 Subject: Multiple vendors' IPv6 issues (ping google flash use) In-Reply-To: <051201d0984a$b8f61040$2ae230c0$@tndh.net> References: <051201d0984a$b8f61040$2ae230c0$@tndh.net> Message-ID: <1433002154.28737.343.camel@pc2> On Tue, 2015-05-26 at 23:59 -0700, Tony Hain wrote: > (...) For fun, project this > http://www.google.com/intl/en/ipv6/statistics.html > (...) Hi, If someone from google is listening it would be really nice to spend a few minutes t oavoid flash for displaying this graph, it doesn't work on my Google Nexus 4 and my flash-less chrome/chromium desktops :). Sincerely, Laurent From morrowc.lists at gmail.com Sat May 30 16:28:21 2015 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Sat, 30 May 2015 12:28:21 -0400 Subject: AWS Elastic IP architecture In-Reply-To: <93B91051-04B2-4251-A06F-AC5F4609E8F2@delong.com> References: <0FBA59E3-5EA1-4605-8418-EAC5D2564DB6@delong.com> <93B91051-04B2-4251-A06F-AC5F4609E8F2@delong.com> Message-ID: On Fri, May 29, 2015 at 9:45 PM, Owen DeLong wrote: > >> On May 29, 2015, at 6:14 PM, Christopher Morrow wrote: >> >> i love that you are always combative, it makes for great tv. >> >> On Fri, May 29, 2015 at 9:04 PM, Owen DeLong wrote: >>> >>>> On May 29, 2015, at 8:23 AM, Christopher Morrow wrote: >>>> >>>> On Fri, May 29, 2015 at 3:45 AM, Owen DeLong wrote: >>>>> Yeah, if it were LISP, they could probably handle IPv6. >>>> >>>> why can't they do v6 with any other encap? >>> >>> That?s not my point. >>> >> >> sort of seemed like part of your point. >> > > I swear, it really wasn?t. sweet! :) >>>> the encap really doesn't matter at all to the underlying ip protocol >>>> used, or shouldn't... you decide at the entrance to the 'virtual >>>> network' that 'thingy is in virtual-network-5 and encap the packet... >>>> regardless of ip version of the thing you are encapsulating. >>> >>> Whatever encapsulation or other system they are using, clearly they can?t do IPv6 for some reason because they outright refuse to even offer so much as a verification that IPv6 is on any sort of roadmap or is at all likely to be considered for deployment any time in the foreseeable future. >>> >> >> it's totally possible that they DO LISP and simply disable ipv6 for >> some other unspecified reason too, right? Maybe they are just on a >> jihad against larger ip numbers? or their keyboards have no colons? > > I suppose, but according to statements made by their engineers, it has to do with the ?way that they have structured their backend networks to the virtual hosts?. > > I?m pretty sure that I?ve ruled the last two out based on discussions I?ve had with their engineers, but you?re right, I was probably a little more glib about it than was 100% accurate. > > Bottom line, however, is it doesn?t matter what the reason, they are utterly incapable of doing IPv6 and utterly and completely unrepentant about it. > it is sort of a bummer, they WILL have to do it eventually though (you'd think)... and 'sooner rather than later' makes a lot of sense to work out the bugs and problems and 'we should have thoughta that!'s...not to mention as they sit and grow it becomes more painful everyday to make the move :( Amazon doesn't even offer a v4/v6 LoadBalancer service right? (I had thought they did, but I guess I'm mis-remembering) >>> So, my point wasn?t that LISP is the only encapsulation that supports IPv6. Indeed, I didn?t even say that. What I said was that their apparent complete inability to do IPv6 makes it unlikely that they are using an IPv6-capable encapsulation system. Thus, it is unlikely they are using LISP. I only referenced LISP because it was specifically mentioned by the poster to whom I was responding. >>> >>> Please try to avoid putting words in my mouth in the future. >>> >> >> you have so many words there already it's going to be fun fitting more >> in if I did try. > > LoL > >> >> have a swell weekend! > > You too. so far so good! (hoping for a little rain to cool/clean things) From morrowc.lists at gmail.com Sat May 30 16:29:17 2015 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Sat, 30 May 2015 12:29:17 -0400 Subject: AWS Elastic IP architecture In-Reply-To: References: <0FBA59E3-5EA1-4605-8418-EAC5D2564DB6@delong.com> Message-ID: On Sat, May 30, 2015 at 11:38 AM, Andras Toth wrote: > Perhaps if that energy which was spent on raging, instead was spent on > a Google search, then all those words would've been unnecessary. > > As it turns out that IPv6 is already available on ELBs since 2011: > https://aws.amazon.com/blogs/aws/elastic-load-balancing-ipv6-zone-apex-support-additional-security/ > ah! I thought I'd remembered this for ~v6day or something similar. cool! so at least for some LB services you can get v6 entrance services. > Official documentation: > http://docs.aws.amazon.com/ElasticLoadBalancing/latest/DeveloperGuide/elb-internet-facing-load-balancers.html#internet-facing-ip-addresses > > Netflix is using it already as per their techblog since 2012: > http://techblog.netflix.com/2012/07/enabling-support-for-ipv6.html > neat! > Regards, > Andras > > > On Sat, May 30, 2015 at 11:04 AM, Owen DeLong wrote: >> >>> On May 29, 2015, at 8:23 AM, Christopher Morrow wrote: >>> >>> On Fri, May 29, 2015 at 3:45 AM, Owen DeLong wrote: >>>> Yeah, if it were LISP, they could probably handle IPv6. >>> >>> why can't they do v6 with any other encap? >> >> That?s not my point. >> >>> the encap really doesn't matter at all to the underlying ip protocol >>> used, or shouldn't... you decide at the entrance to the 'virtual >>> network' that 'thingy is in virtual-network-5 and encap the packet... >>> regardless of ip version of the thing you are encapsulating. >> >> Whatever encapsulation or other system they are using, clearly they can?t do IPv6 for some reason because they outright refuse to even offer so much as a verification that IPv6 is on any sort of roadmap or is at all likely to be considered for deployment any time in the foreseeable future. >> >> So, my point wasn?t that LISP is the only encapsulation that supports IPv6. Indeed, I didn?t even say that. What I said was that their apparent complete inability to do IPv6 makes it unlikely that they are using an IPv6-capable encapsulation system. Thus, it is unlikely they are using LISP. I only referenced LISP because it was specifically mentioned by the poster to whom I was responding. >> >> Please try to avoid putting words in my mouth in the future. >> >> Owen >> From morrowc.lists at gmail.com Sat May 30 16:31:15 2015 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Sat, 30 May 2015 12:31:15 -0400 Subject: westin hotel network In-Reply-To: <535F314F-C0D6-4B1D-8243-7381D7E143BE@karoshi.com> References: <535F314F-C0D6-4B1D-8243-7381D7E143BE@karoshi.com> Message-ID: while /bin/true; do rsync-vaHx --delete rsync.tools.ietf.org::xml2rfc .; done go to sleep, most likely it'll be done in the morning? On Sat, May 30, 2015 at 7:21 AM, manning wrote: > so? bring your own avian carriers? > > > manning > bmanning at karoshi.com > PO Box 12317 > Marina del Rey, CA 90295 > 310.322.8102 > > > > On 29May2015Friday, at 19:49, Randy Bush wrote: > >> ryuu.psg.com:/Users/randy> ping rsync.tools.ietf.org >> PING zinfandel.tools.ietf.org (64.170.98.42): 56 data bytes >> 64 bytes from 64.170.98.42: icmp_seq=0 ttl=53 time=11.751 ms >> 64 bytes from 64.170.98.42: icmp_seq=1 ttl=53 time=12.207 ms >> 64 bytes from 64.170.98.42: icmp_seq=2 ttl=53 time=11.444 ms >> 64 bytes from 64.170.98.42: icmp_seq=3 ttl=53 time=12.963 ms >> ^C >> --- zinfandel.tools.ietf.org ping statistics --- >> 4 packets transmitted, 4 packets received, 0.0% packet loss >> round-trip min/avg/max/stddev = 11.444/12.091/12.963/0.572 ms >> >> ryuu.psg.com:/Users/randy> rsync -vaHx --delete rsync.tools.ietf.org::xml2rfc.bibxml/bibxml3 $HOME/refs/id >> rsync: failed to connect to rsync.tools.ietf.org: Host is down (64) >> rsync error: error in socket IO (code 10) at /SourceCache/rsync/rsync-45/rsync/clientserver.c(105) [receiver=2.6.9] >> >> sheesh! > From dave.taht at gmail.com Sat May 30 17:50:28 2015 From: dave.taht at gmail.com (Dave Taht) Date: Sat, 30 May 2015 10:50:28 -0700 Subject: 300+ms of hotel wifi bufferbloat - peaking at 1.5 sec! Message-ID: http://www.dslreports.com/speedtest/578850 I would get a kick out of it if folk here tried this new speedtest periodically (on the "cable" setting) during the nanog conference. ;) There is a hires option for more detail on the resulting charts... (or fiddled with "flent" (flent.org)) -- Dave T?ht What will it take to vastly improve wifi for everyone? https://plus.google.com/u/0/explore/makewififast From randy at psg.com Sat May 30 20:31:29 2015 From: randy at psg.com (Randy Bush) Date: Sat, 30 May 2015 13:31:29 -0700 Subject: westin hotel network In-Reply-To: References: Message-ID: > only a 1.5 seconds of bufferbloat. Mind If I repost that result? > (would prefer you did to this list) http://www.dslreports.com/speedtest/578850 From owen at delong.com Sat May 30 20:49:18 2015 From: owen at delong.com (Owen DeLong) Date: Sat, 30 May 2015 13:49:18 -0700 Subject: AWS Elastic IP architecture In-Reply-To: References: <0FBA59E3-5EA1-4605-8418-EAC5D2564DB6@delong.com> <93B91051-04B2-4251-A06F-AC5F4609E8F2@delong.com> Message-ID: <3CADD57E-6E0B-4978-AD6F-F0653980A4AF@delong.com> > > > Amazon doesn't even offer a v4/v6 LoadBalancer service right? (I had > thought they did, but I guess I'm mis-remembering) They sort of do, but it?s utterly incompatible with all of their modern capabilities. You have to use some pretty antiquated VM provisioning and such to use it if I understood people correctly. Owen From blair.trosper at gmail.com Sat May 30 21:20:57 2015 From: blair.trosper at gmail.com (Blair Trosper) Date: Sat, 30 May 2015 16:20:57 -0500 Subject: AWS Elastic IP architecture In-Reply-To: <3CADD57E-6E0B-4978-AD6F-F0653980A4AF@delong.com> References: <0FBA59E3-5EA1-4605-8418-EAC5D2564DB6@delong.com> <93B91051-04B2-4251-A06F-AC5F4609E8F2@delong.com> <3CADD57E-6E0B-4978-AD6F-F0653980A4AF@delong.com> Message-ID: Only EC2 classic has dual stack anything. VPC load balancers (and, indeed, everything about VPC) is IPv4 only. And EC2 classic is being phased out, so dualstack is sort of dying on AWS. However, I do have some solid information that they're scrambling to retrofit, but seeing as how we know AWS operates internally (compartmentalizing information to the point of paranoia), I reckon it will be another year or two before we even see IPv6 support extend to CloudFront (their CDN) endpoints. Don't hold your breath on seeing v6 inside VPC/EC2 anytime soon...is what I was told. On Sat, May 30, 2015 at 3:49 PM, Owen DeLong wrote: > > > > > > Amazon doesn't even offer a v4/v6 LoadBalancer service right? (I had > > thought they did, but I guess I'm mis-remembering) > > They sort of do, but it?s utterly incompatible with all of their modern > capabilities. You have to use some pretty antiquated VM provisioning and > such to use it if I understood people correctly. > > > Owen > > -- Blair Trosper p.g.a. S2 Entertainment Partners Desk: 469-333-8008 Cell: 512-619-8133 Agent/Rep: WME (Los Angeles, CA) - 310-248-2000 PR/Manager: BORG (Dallas, TX) - 844-THE-BORG From blair.trosper at gmail.com Sat May 30 21:23:57 2015 From: blair.trosper at gmail.com (Blair Trosper) Date: Sat, 30 May 2015 16:23:57 -0500 Subject: AWS Elastic IP architecture In-Reply-To: References: <0FBA59E3-5EA1-4605-8418-EAC5D2564DB6@delong.com> <93B91051-04B2-4251-A06F-AC5F4609E8F2@delong.com> <3CADD57E-6E0B-4978-AD6F-F0653980A4AF@delong.com> Message-ID: Oh, and the only thing dual stack about EC2 Classic was ELBs (elastic load balancers). Instances had no means of IPv6 communication except via an ELB. That is the FULL extent of IPv6 implementation on AWS at present...and most people do not have EC2 classic. On Sat, May 30, 2015 at 4:20 PM, Blair Trosper wrote: > Only EC2 classic has dual stack anything. VPC load balancers (and, > indeed, everything about VPC) is IPv4 only. > > And EC2 classic is being phased out, so dualstack is sort of dying on > AWS. However, I do have some solid information that they're scrambling to > retrofit, but seeing > as how we know AWS operates internally (compartmentalizing information to > the point of paranoia), I reckon it will be another year or two before we > even see IPv6 > support extend to CloudFront (their CDN) endpoints. > > Don't hold your breath on seeing v6 inside VPC/EC2 anytime soon...is what > I was told. > > On Sat, May 30, 2015 at 3:49 PM, Owen DeLong wrote: > >> > >> > >> > Amazon doesn't even offer a v4/v6 LoadBalancer service right? (I had >> > thought they did, but I guess I'm mis-remembering) >> >> They sort of do, but it?s utterly incompatible with all of their modern >> capabilities. You have to use some pretty antiquated VM provisioning and >> such to use it if I understood people correctly. >> >> >> Owen >> >> > From owen at delong.com Sun May 31 00:35:24 2015 From: owen at delong.com (Owen DeLong) Date: Sat, 30 May 2015 17:35:24 -0700 Subject: AWS Elastic IP architecture In-Reply-To: References: <0FBA59E3-5EA1-4605-8418-EAC5D2564DB6@delong.com> Message-ID: <74137258-DB16-4DE1-A0B2-E98E8971619D@delong.com> > On May 30, 2015, at 8:38 AM, Andras Toth wrote: > > Perhaps if that energy which was spent on raging, instead was spent on > a Google search, then all those words would've been unnecessary. > > As it turns out that IPv6 is already available on ELBs since 2011: > https://aws.amazon.com/blogs/aws/elastic-load-balancing-ipv6-zone-apex-support-additional-security/ See other posts? ELB is being phased out and works only with EC2 and classic. As I said, it does not work with modern Amazon VPC. > Official documentation: > http://docs.aws.amazon.com/ElasticLoadBalancing/latest/DeveloperGuide/elb-internet-facing-load-balancers.html#internet-facing-ip-addresses All well and good and equally irrelevant. > Netflix is using it already as per their techblog since 2012: > http://techblog.netflix.com/2012/07/enabling-support-for-ipv6.html Yes? This token checkbox effort which doesn?t work unless you are running on old hosts without access to any current storage technologies and face other limitations is available. My statements stand, as far as I am concerned. Owen > > Regards, > Andras > > > On Sat, May 30, 2015 at 11:04 AM, Owen DeLong wrote: >> >>> On May 29, 2015, at 8:23 AM, Christopher Morrow wrote: >>> >>> On Fri, May 29, 2015 at 3:45 AM, Owen DeLong wrote: >>>> Yeah, if it were LISP, they could probably handle IPv6. >>> >>> why can't they do v6 with any other encap? >> >> That?s not my point. >> >>> the encap really doesn't matter at all to the underlying ip protocol >>> used, or shouldn't... you decide at the entrance to the 'virtual >>> network' that 'thingy is in virtual-network-5 and encap the packet... >>> regardless of ip version of the thing you are encapsulating. >> >> Whatever encapsulation or other system they are using, clearly they can?t do IPv6 for some reason because they outright refuse to even offer so much as a verification that IPv6 is on any sort of roadmap or is at all likely to be considered for deployment any time in the foreseeable future. >> >> So, my point wasn?t that LISP is the only encapsulation that supports IPv6. Indeed, I didn?t even say that. What I said was that their apparent complete inability to do IPv6 makes it unlikely that they are using an IPv6-capable encapsulation system. Thus, it is unlikely they are using LISP. I only referenced LISP because it was specifically mentioned by the poster to whom I was responding. >> >> Please try to avoid putting words in my mouth in the future. >> >> Owen >> From sjt5atra at gmail.com Sun May 31 01:25:33 2015 From: sjt5atra at gmail.com (Steven Tardy) Date: Sat, 30 May 2015 21:25:33 -0400 Subject: 300+ms of hotel wifi bufferbloat - peaking at 1.5 sec! In-Reply-To: References: Message-ID: <6D5BCABB-AD36-415F-8B8E-D0287F5B0785@gmail.com> There's a corollary of the bufferbloat phenomenon: buffer drain time. It's not the size of the buffer, but how long it takes to empty. And US ISPs continue to say "customers don't want upload speed". If the ISP upload speed was symmetric you'd likely never notice the 1-2MB of buffers. I guess what I'm getting at is why do you continue to say buffers are too big instead of saying ISP upload is too slow? > On May 30, 2015, at 1:50 PM, Dave Taht wrote: > > http://www.dslreports.com/speedtest/578850 > > I would get a kick out of it if folk here tried this new speedtest > periodically (on the "cable" setting) during the nanog conference. ;) > There is a hires option for more detail on the resulting charts... > > (or fiddled with "flent" (flent.org)) > > -- > Dave T?ht > What will it take to vastly improve wifi for everyone? > https://plus.google.com/u/0/explore/makewififast From srikanth at gatech.edu Sun May 31 01:59:53 2015 From: srikanth at gatech.edu (Srikanth Sundaresan) Date: Sat, 30 May 2015 18:59:53 -0700 Subject: 300+ms of hotel wifi bufferbloat - peaking at 1.5 sec! In-Reply-To: <6D5BCABB-AD36-415F-8B8E-D0287F5B0785@gmail.com> References: <6D5BCABB-AD36-415F-8B8E-D0287F5B0785@gmail.com> Message-ID: <556A6B19.8090309@gatech.edu> While I agree that upload speeds aren't great, it doesn't mean that the buffers aren't big. Buffer sizes of the order of MB's are uncalled for at the edge, unless we're talking really high speeds. The miniscule performance increase for single TCP flows doesn't really justify the potential increase in latency for everyone else. On 5/30/15 6:25 PM, Steven Tardy wrote: > There's a corollary of the bufferbloat phenomenon: buffer drain time. It's not the size of the buffer, but how long it takes to empty. And US ISPs continue to say "customers don't want upload speed". > If the ISP upload speed was symmetric you'd likely never notice the 1-2MB of buffers. > > I guess what I'm getting at is why do you continue to say buffers are too big instead of saying ISP upload is too slow? > > >> On May 30, 2015, at 1:50 PM, Dave Taht wrote: >> >> http://www.dslreports.com/speedtest/578850 >> >> I would get a kick out of it if folk here tried this new speedtest >> periodically (on the "cable" setting) during the nanog conference. ;) >> There is a hires option for more detail on the resulting charts... >> >> (or fiddled with "flent" (flent.org)) >> >> -- >> Dave T?ht >> What will it take to vastly improve wifi for everyone? >> https://plus.google.com/u/0/explore/makewififast From maqbool at madbull.info Fri May 29 08:36:34 2015 From: maqbool at madbull.info (Maqbool Hashim) Date: Fri, 29 May 2015 08:36:34 +0000 Subject: BGP Multihoming 2 providers full or partial? Message-ID: Hi, We are an enterprise that are eBGP multihoming to two ISPs. We wish to load balance in inbound and outbound traffic thereby using our capacity as efficiently as possible. My current feeling is that it would be crazy for us to take a full Internet routing table from either ISP. I have read this document from NANOG presentations: https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&uact=8&ved=0CCoQFjAA&url=https%3A%2F%2Fwww.nanog.org%2Fmeetings%2Fnanog41%2Fpresentations%2FBGPMultihoming.pdf&ei=cyRnVb--FeWY7gbq4oHoAQ&usg=AFQjCNFsMx3NZ0Vn4bJ5zJpzFz3senbaqg&bvm=bv.93990622,d.ZGU The above document reenforces my opinion that we do not need full routing tables. However I was seeking some clarity as there are other documents which suggest taking a full routing table would be optimal. I "guess" it depends on our criteria and requirements for load balancing: - Just care about roughly balancing link utilisation - Be nice to make some cost savings We have PI space and two Internet routers one for each ISP. Either of our links is sufficient to carry all our traffic, but we want to try and balance utilisation to remain within our commits if possible. I am thinking a "rough" approach for us would be: - Take partial (customer) routes from both providers - Take defaults from both and pref one Maybe we can refine the above a bit more, any suggestions would be most welcome! Many Thanks From diosbejgli at gmail.com Sat May 30 15:38:05 2015 From: diosbejgli at gmail.com (Andras Toth) Date: Sun, 31 May 2015 01:38:05 +1000 Subject: AWS Elastic IP architecture In-Reply-To: <0FBA59E3-5EA1-4605-8418-EAC5D2564DB6@delong.com> References: <0FBA59E3-5EA1-4605-8418-EAC5D2564DB6@delong.com> Message-ID: Perhaps if that energy which was spent on raging, instead was spent on a Google search, then all those words would've been unnecessary. As it turns out that IPv6 is already available on ELBs since 2011: https://aws.amazon.com/blogs/aws/elastic-load-balancing-ipv6-zone-apex-support-additional-security/ Official documentation: http://docs.aws.amazon.com/ElasticLoadBalancing/latest/DeveloperGuide/elb-internet-facing-load-balancers.html#internet-facing-ip-addresses Netflix is using it already as per their techblog since 2012: http://techblog.netflix.com/2012/07/enabling-support-for-ipv6.html Regards, Andras On Sat, May 30, 2015 at 11:04 AM, Owen DeLong wrote: > >> On May 29, 2015, at 8:23 AM, Christopher Morrow wrote: >> >> On Fri, May 29, 2015 at 3:45 AM, Owen DeLong wrote: >>> Yeah, if it were LISP, they could probably handle IPv6. >> >> why can't they do v6 with any other encap? > > That?s not my point. > >> the encap really doesn't matter at all to the underlying ip protocol >> used, or shouldn't... you decide at the entrance to the 'virtual >> network' that 'thingy is in virtual-network-5 and encap the packet... >> regardless of ip version of the thing you are encapsulating. > > Whatever encapsulation or other system they are using, clearly they can?t do IPv6 for some reason because they outright refuse to even offer so much as a verification that IPv6 is on any sort of roadmap or is at all likely to be considered for deployment any time in the foreseeable future. > > So, my point wasn?t that LISP is the only encapsulation that supports IPv6. Indeed, I didn?t even say that. What I said was that their apparent complete inability to do IPv6 makes it unlikely that they are using an IPv6-capable encapsulation system. Thus, it is unlikely they are using LISP. I only referenced LISP because it was specifically mentioned by the poster to whom I was responding. > > Please try to avoid putting words in my mouth in the future. > > Owen > From mpalmer at hezmatt.org Sun May 31 09:18:20 2015 From: mpalmer at hezmatt.org (Matt Palmer) Date: Sun, 31 May 2015 19:18:20 +1000 Subject: AWS Elastic IP architecture In-Reply-To: References: <0FBA59E3-5EA1-4605-8418-EAC5D2564DB6@delong.com> Message-ID: <20150531091820.GQ724@hezmatt.org> On Sun, May 31, 2015 at 01:38:05AM +1000, Andras Toth wrote: > Perhaps if that energy which was spent on raging, instead was spent on > a Google search, then all those words would've been unnecessary. > > Official documentation: > http://docs.aws.amazon.com/ElasticLoadBalancing/latest/DeveloperGuide/elb-internet-facing-load-balancers.html#internet-facing-ip-addresses Congratulations, you've managed to find exactly the same info as Owen already covered: "Load balancers in a VPC support IPv4 addresses only." and "Load balancers in EC2-Classic support both IPv4 and IPv6 addresses." - Matt From diosbejgli at gmail.com Sun May 31 11:23:37 2015 From: diosbejgli at gmail.com (Andras Toth) Date: Sun, 31 May 2015 21:23:37 +1000 Subject: AWS Elastic IP architecture In-Reply-To: <20150531091820.GQ724@hezmatt.org> References: <0FBA59E3-5EA1-4605-8418-EAC5D2564DB6@delong.com> <20150531091820.GQ724@hezmatt.org> Message-ID: Congratulations for missing the point Matt, when I sent my email (which by the way went for moderation) there wasn't a discussion about Classic vs VPC yet. The discussion was "no ipv6 in AWS" which is not true as I mentioned in my previous email. I did not state it works everywhere, but it does work. In fact as Owen mentioned the following, I assumed he is talking about Classic because this statement is only true there. In VPC you can define your own IP subnets and it can overlap with other customers, so basically everyone can have their own 10.0.0.0/24 for example. "They are known to be running multiple copies of RFC-1918 in disparate localities already. In terms of scale, modulo the nightmare that must make of their management network and the fragility of what happens when company A in datacenter A wants to talk to company A in datacenter B and they both have the same 10-NET addresses" Andras On Sun, May 31, 2015 at 7:18 PM, Matt Palmer wrote: > On Sun, May 31, 2015 at 01:38:05AM +1000, Andras Toth wrote: >> Perhaps if that energy which was spent on raging, instead was spent on >> a Google search, then all those words would've been unnecessary. >> >> Official documentation: >> http://docs.aws.amazon.com/ElasticLoadBalancing/latest/DeveloperGuide/elb-internet-facing-load-balancers.html#internet-facing-ip-addresses > > Congratulations, you've managed to find exactly the same info as Owen > already covered: > > "Load balancers in a VPC support IPv4 addresses only." > > and > > "Load balancers in EC2-Classic support both IPv4 and IPv6 addresses." > > - Matt > From jjackson at aninetworks.net Sun May 31 11:41:18 2015 From: jjackson at aninetworks.net (Joseph Jackson) Date: Sun, 31 May 2015 11:41:18 +0000 Subject: BGP Multihoming 2 providers full or partial? In-Reply-To: References: Message-ID: <88d8b6ead0414162aa5c947a3062a6f1@mbx080-w4-co-1.exch080.serverpod.net> Can your devices support a full table? You can load balance outbound traffic easily with out doing a full table. THo that won't be the shortest AS path. In regards to cost savings how were you thinking of doing so? Does one provider charge more? Just use the cheaper provider. -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Maqbool Hashim Sent: Friday, May 29, 2015 3:37 AM To: nanog at nanog.org Subject: BGP Multihoming 2 providers full or partial? Hi, We are an enterprise that are eBGP multihoming to two ISPs. We wish to load balance in inbound and outbound traffic thereby using our capacity as efficiently as possible. My current feeling is that it would be crazy for us to take a full Internet routing table from either ISP. I have read this document from NANOG presentations: https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&uact=8&ved=0CCoQFjAA&url=https%3A%2F%2Fwww.nanog.org%2Fmeetings%2Fnanog41%2Fpresentations%2FBGPMultihoming.pdf&ei=cyRnVb--FeWY7gbq4oHoAQ&usg=AFQjCNFsMx3NZ0Vn4bJ5zJpzFz3senbaqg&bvm=bv.93990622,d.ZGU The above document reenforces my opinion that we do not need full routing tables. However I was seeking some clarity as there are other documents which suggest taking a full routing table would be optimal. I "guess" it depends on our criteria and requirements for load balancing: - Just care about roughly balancing link utilisation - Be nice to make some cost savings We have PI space and two Internet routers one for each ISP. Either of our links is sufficient to carry all our traffic, but we want to try and balance utilisation to remain within our commits if possible. I am thinking a "rough" approach for us would be: - Take partial (customer) routes from both providers - Take defaults from both and pref one Maybe we can refine the above a bit more, any suggestions would be most welcome! Many Thanks From faisal at snappytelecom.net Sun May 31 12:06:01 2015 From: faisal at snappytelecom.net (Faisal Imtiaz) Date: Sun, 31 May 2015 12:06:01 +0000 (GMT) Subject: BGP Multihoming 2 providers full or partial? In-Reply-To: References: Message-ID: <2039437016.455402.1433073961911.JavaMail.zimbra@snappytelecom.net> If you wish to do outbound traffic engineering, and want to take advantage of best paths to different networks (outbound), then you have to take full routes. Or putting it another way.... Taking full routes offers the most flexibility, anything else would be a compromise (an acceptable compromise) to overcome some existing resource limitations... Regards. Faisal Imtiaz Snappy Internet & Telecom 7266 SW 48 Street Miami, FL 33155 Tel: 305 663 5518 x 232 Help-desk: (305)663-5518 Option 2 or Email: Support at Snappytelecom.net ----- Original Message ----- > From: "Maqbool Hashim" > To: nanog at nanog.org > Sent: Friday, May 29, 2015 4:36:34 AM > Subject: BGP Multihoming 2 providers full or partial? > > Hi, > > > We are an enterprise that are eBGP multihoming to two ISPs. We wish to load > balance in inbound and outbound traffic thereby using our capacity as > efficiently as possible. My current feeling is that it would be crazy for us > to take a full Internet routing table from either ISP. I have read this > document from NANOG presentations: > > > https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&uact=8&ved=0CCoQFjAA&url=https%3A%2F%2Fwww.nanog.org%2Fmeetings%2Fnanog41%2Fpresentations%2FBGPMultihoming.pdf&ei=cyRnVb--FeWY7gbq4oHoAQ&usg=AFQjCNFsMx3NZ0Vn4bJ5zJpzFz3senbaqg&bvm=bv.93990622,d.ZGU > > > The above document reenforces my opinion that we do not need full routing > tables. However I was seeking some clarity as there are other documents > which suggest taking a full routing table would be optimal. I "guess" it > depends on our criteria and requirements for load balancing: > > > - Just care about roughly balancing link utilisation > > - Be nice to make some cost savings > > > We have PI space and two Internet routers one for each ISP. Either of our > links is sufficient to carry all our traffic, but we want to try and balance > utilisation to remain within our commits if possible. I am thinking a > "rough" approach for us would be: > > > - Take partial (customer) routes from both providers > > - Take defaults from both and pref one > > > Maybe we can refine the above a bit more, any suggestions would be most > welcome! > > > Many Thanks > > From maqbool at madbull.info Sun May 31 12:09:02 2015 From: maqbool at madbull.info (Maqbool Hashim) Date: Sun, 31 May 2015 12:09:02 +0000 Subject: BGP Multihoming 2 providers full or partial? In-Reply-To: <88d8b6ead0414162aa5c947a3062a6f1@mbx080-w4-co-1.exch080.serverpod.net> References: <88d8b6ead0414162aa5c947a3062a6f1@mbx080-w4-co-1.exch080.serverpod.net> Message-ID: Hi, No the current devices can't support full table (well not from both providers) we would need to upgrade. Really in terms of cost saving just want to make sure to not get charged overages because we utilise too much of one link and not enough of another. I don't think the shortest AS path will be of that much concern or noticeable for most destinations. We do however have a set of remote sites which communicate over the Internet to our central sites where the transit providers are. Just general Internet at the remote sites- but traffic from remote sites to central sites would be the most important. I am just not sure of exactly how to define the "partial" routing table criteria to our two providers. Should we just take routes for each provider and their peers and a default from both? The main reason for not taking a full routing table is the cost/inconvenience of upgrading existing hardware. Thanks -----Original Message----- From: Joseph Jackson [mailto:jjackson at aninetworks.net] Sent: 31 May 2015 12:41 To: Maqbool Hashim; nanog at nanog.org Subject: RE: BGP Multihoming 2 providers full or partial? Can your devices support a full table? You can load balance outbound traffic easily with out doing a full table. THo that won't be the shortest AS path. In regards to cost savings how were you thinking of doing so? Does one provider charge more? Just use the cheaper provider. -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Maqbool Hashim Sent: Friday, May 29, 2015 3:37 AM To: nanog at nanog.org Subject: BGP Multihoming 2 providers full or partial? Hi, We are an enterprise that are eBGP multihoming to two ISPs. We wish to load balance in inbound and outbound traffic thereby using our capacity as efficiently as possible. My current feeling is that it would be crazy for us to take a full Internet routing table from either ISP. I have read this document from NANOG presentations: https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&uact=8&ved=0CCoQFjAA&url=https%3A%2F%2Fwww.nanog.org%2Fmeetings%2Fnanog41%2Fpresentations%2FBGPMultihoming.pdf&ei=cyRnVb--FeWY7gbq4oHoAQ&usg=AFQjCNFsMx3NZ0Vn4bJ5zJpzFz3senbaqg&bvm=bv.93990622,d.ZGU The above document reenforces my opinion that we do not need full routing tables. However I was seeking some clarity as there are other documents which suggest taking a full routing table would be optimal. I "guess" it depends on our criteria and requirements for load balancing: - Just care about roughly balancing link utilisation - Be nice to make some cost savings We have PI space and two Internet routers one for each ISP. Either of our links is sufficient to carry all our traffic, but we want to try and balance utilisation to remain within our commits if possible. I am thinking a "rough" approach for us would be: - Take partial (customer) routes from both providers - Take defaults from both and pref one Maybe we can refine the above a bit more, any suggestions would be most welcome! Many Thanks From maqbool at madbull.info Sun May 31 12:10:51 2015 From: maqbool at madbull.info (Maqbool Hashim) Date: Sun, 31 May 2015 12:10:51 +0000 Subject: BGP Multihoming 2 providers full or partial? In-Reply-To: <2039437016.455402.1433073961911.JavaMail.zimbra@snappytelecom.net> References: <2039437016.455402.1433073961911.JavaMail.zimbra@snappytelecom.net> Message-ID: Thanks, So we just need to take a decision on whether we want to pay the price for a full routing table, whether it gives us enough value for the expenditure. -----Original Message----- From: Faisal Imtiaz [mailto:faisal at snappytelecom.net] Sent: 31 May 2015 13:06 To: Maqbool Hashim Cc: nanog at nanog.org Subject: Re: BGP Multihoming 2 providers full or partial? If you wish to do outbound traffic engineering, and want to take advantage of best paths to different networks (outbound), then you have to take full routes. Or putting it another way.... Taking full routes offers the most flexibility, anything else would be a compromise (an acceptable compromise) to overcome some existing resource limitations... Regards. Faisal Imtiaz Snappy Internet & Telecom 7266 SW 48 Street Miami, FL 33155 Tel: 305 663 5518 x 232 Help-desk: (305)663-5518 Option 2 or Email: Support at Snappytelecom.net ----- Original Message ----- > From: "Maqbool Hashim" > To: nanog at nanog.org > Sent: Friday, May 29, 2015 4:36:34 AM > Subject: BGP Multihoming 2 providers full or partial? > > Hi, > > > We are an enterprise that are eBGP multihoming to two ISPs. We wish to > load balance in inbound and outbound traffic thereby using our > capacity as efficiently as possible. My current feeling is that it > would be crazy for us to take a full Internet routing table from > either ISP. I have read this document from NANOG presentations: > > > https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rj > a&uact=8&ved=0CCoQFjAA&url=https%3A%2F%2Fwww.nanog.org%2Fmeetings%2Fna > nog41%2Fpresentations%2FBGPMultihoming.pdf&ei=cyRnVb--FeWY7gbq4oHoAQ&u > sg=AFQjCNFsMx3NZ0Vn4bJ5zJpzFz3senbaqg&bvm=bv.93990622,d.ZGU > > > The above document reenforces my opinion that we do not need full > routing tables. However I was seeking some clarity as there are other > documents which suggest taking a full routing table would be optimal. > I "guess" it depends on our criteria and requirements for load balancing: > > > - Just care about roughly balancing link utilisation > > - Be nice to make some cost savings > > > We have PI space and two Internet routers one for each ISP. Either of > our links is sufficient to carry all our traffic, but we want to try > and balance utilisation to remain within our commits if possible. I am > thinking a "rough" approach for us would be: > > > - Take partial (customer) routes from both providers > > - Take defaults from both and pref one > > > Maybe we can refine the above a bit more, any suggestions would be > most welcome! > > > Many Thanks > > From tvest at eyeconomics.com Sun May 31 12:26:57 2015 From: tvest at eyeconomics.com (tvest) Date: Sun, 31 May 2015 08:26:57 -0400 Subject: AWS Elastic IP architecture In-Reply-To: References: <0FBA59E3-5EA1-4605-8418-EAC5D2564DB6@delong.com> <20150531091820.GQ724@hezmatt.org> Message-ID: <6C26491A-CB81-42BA-BBB1-BD28D3BE32DB@eyeconomics.com> Point of clarification: AWS customer IP subnets can overlap, but customer VPCs that encompass overlapping subnets cannot peer with each other. In other words, the standard arguments in favor of address uniqueness still apply. TV On May 31, 2015 7:23:37 AM EDT, Andras Toth wrote: >Congratulations for missing the point Matt, when I sent my email >(which by the way went for moderation) there wasn't a discussion about >Classic vs VPC yet. The discussion was "no ipv6 in AWS" which is not >true as I mentioned in my previous email. I did not state it works >everywhere, but it does work. > >In fact as Owen mentioned the following, I assumed he is talking about >Classic because this statement is only true there. In VPC you can >define your own IP subnets and it can overlap with other customers, so >basically everyone can have their own 10.0.0.0/24 for example. >"They are known to be running multiple copies of RFC-1918 in disparate >localities already. In terms of scale, modulo the nightmare that must >make of their management network and the fragility of what happens >when company A in datacenter A wants to talk to company A in >datacenter B and they both have the same 10-NET addresses" > >Andras > > >On Sun, May 31, 2015 at 7:18 PM, Matt Palmer >wrote: >> On Sun, May 31, 2015 at 01:38:05AM +1000, Andras Toth wrote: >>> Perhaps if that energy which was spent on raging, instead was spent >on >>> a Google search, then all those words would've been unnecessary. >>> >>> Official documentation: >>> >http://docs.aws.amazon.com/ElasticLoadBalancing/latest/DeveloperGuide/elb-internet-facing-load-balancers.html#internet-facing-ip-addresses >> >> Congratulations, you've managed to find exactly the same info as Owen >> already covered: >> >> "Load balancers in a VPC support IPv4 addresses only." >> >> and >> >> "Load balancers in EC2-Classic support both IPv4 and IPv6 addresses." >> >> - Matt >> -- Sent from my Android device with K-9 Mail. Please excuse my brevity. From faisal at snappytelecom.net Sun May 31 13:01:20 2015 From: faisal at snappytelecom.net (Faisal Imtiaz) Date: Sun, 31 May 2015 13:01:20 +0000 (GMT) Subject: BGP Multihoming 2 providers full or partial? In-Reply-To: References: <2039437016.455402.1433073961911.JavaMail.zimbra@snappytelecom.net> Message-ID: <933759929.455692.1433077280575.JavaMail.zimbra@snappytelecom.net> Interesting... is the cost associated with full tables just for the Hardware or is the service provider charging extra for the full table. Faisal Imtiaz Snappy Internet & Telecom 7266 SW 48 Street Miami, FL 33155 Tel: 305 663 5518 x 232 Help-desk: (305)663-5518 Option 2 or Email: Support at Snappytelecom.net ----- Original Message ----- > From: "Maqbool Hashim" > To: "Faisal Imtiaz" > Cc: nanog at nanog.org > Sent: Sunday, May 31, 2015 8:10:51 AM > Subject: RE: BGP Multihoming 2 providers full or partial? > > Thanks, > > So we just need to take a decision on whether we want to pay the price for a > full routing table, whether it gives us enough value for the expenditure. > > -----Original Message----- > From: Faisal Imtiaz [mailto:faisal at snappytelecom.net] > Sent: 31 May 2015 13:06 > To: Maqbool Hashim > Cc: nanog at nanog.org > Subject: Re: BGP Multihoming 2 providers full or partial? > > If you wish to do outbound traffic engineering, and want to take advantage of > best paths to different networks (outbound), then you have to take full > routes. > > Or putting it another way.... Taking full routes offers the most > flexibility, anything else would be a compromise (an acceptable compromise) > to overcome some existing resource limitations... > > Regards. > > Faisal Imtiaz > Snappy Internet & Telecom > 7266 SW 48 Street > Miami, FL 33155 > Tel: 305 663 5518 x 232 > > Help-desk: (305)663-5518 Option 2 or Email: Support at Snappytelecom.net > > ----- Original Message ----- > > From: "Maqbool Hashim" > > To: nanog at nanog.org > > Sent: Friday, May 29, 2015 4:36:34 AM > > Subject: BGP Multihoming 2 providers full or partial? > > > > Hi, > > > > > > We are an enterprise that are eBGP multihoming to two ISPs. We wish to > > load balance in inbound and outbound traffic thereby using our > > capacity as efficiently as possible. My current feeling is that it > > would be crazy for us to take a full Internet routing table from > > either ISP. I have read this document from NANOG presentations: > > > > > > https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rj > > a&uact=8&ved=0CCoQFjAA&url=https%3A%2F%2Fwww.nanog.org%2Fmeetings%2Fna > > nog41%2Fpresentations%2FBGPMultihoming.pdf&ei=cyRnVb--FeWY7gbq4oHoAQ&u > > sg=AFQjCNFsMx3NZ0Vn4bJ5zJpzFz3senbaqg&bvm=bv.93990622,d.ZGU > > > > > > The above document reenforces my opinion that we do not need full > > routing tables. However I was seeking some clarity as there are other > > documents which suggest taking a full routing table would be optimal. > > I "guess" it depends on our criteria and requirements for load balancing: > > > > > > - Just care about roughly balancing link utilisation > > > > - Be nice to make some cost savings > > > > > > We have PI space and two Internet routers one for each ISP. Either of > > our links is sufficient to carry all our traffic, but we want to try > > and balance utilisation to remain within our commits if possible. I am > > thinking a "rough" approach for us would be: > > > > > > - Take partial (customer) routes from both providers > > > > - Take defaults from both and pref one > > > > > > Maybe we can refine the above a bit more, any suggestions would be > > most welcome! > > > > > > Many Thanks > > > > > From maqbool at madbull.info Sun May 31 13:02:24 2015 From: maqbool at madbull.info (Maqbool Hashim) Date: Sun, 31 May 2015 13:02:24 +0000 Subject: BGP Multihoming 2 providers full or partial? In-Reply-To: <933759929.455692.1433077280575.JavaMail.zimbra@snappytelecom.net> References: <2039437016.455402.1433073961911.JavaMail.zimbra@snappytelecom.net> <933759929.455692.1433077280575.JavaMail.zimbra@snappytelecom.net> Message-ID: Just for the hardware and the planning required for migrating to new hardware human resource etc. -----Original Message----- From: Faisal Imtiaz [mailto:faisal at snappytelecom.net] Sent: 31 May 2015 14:01 To: Maqbool Hashim Cc: nanog at nanog.org Subject: Re: BGP Multihoming 2 providers full or partial? Interesting... is the cost associated with full tables just for the Hardware or is the service provider charging extra for the full table. Faisal Imtiaz Snappy Internet & Telecom 7266 SW 48 Street Miami, FL 33155 Tel: 305 663 5518 x 232 Help-desk: (305)663-5518 Option 2 or Email: Support at Snappytelecom.net ----- Original Message ----- > From: "Maqbool Hashim" > To: "Faisal Imtiaz" > Cc: nanog at nanog.org > Sent: Sunday, May 31, 2015 8:10:51 AM > Subject: RE: BGP Multihoming 2 providers full or partial? > > Thanks, > > So we just need to take a decision on whether we want to pay the price > for a full routing table, whether it gives us enough value for the expenditure. > > -----Original Message----- > From: Faisal Imtiaz [mailto:faisal at snappytelecom.net] > Sent: 31 May 2015 13:06 > To: Maqbool Hashim > Cc: nanog at nanog.org > Subject: Re: BGP Multihoming 2 providers full or partial? > > If you wish to do outbound traffic engineering, and want to take > advantage of best paths to different networks (outbound), then you > have to take full routes. > > Or putting it another way.... Taking full routes offers the most > flexibility, anything else would be a compromise (an acceptable > compromise) to overcome some existing resource limitations... > > Regards. > > Faisal Imtiaz > Snappy Internet & Telecom > 7266 SW 48 Street > Miami, FL 33155 > Tel: 305 663 5518 x 232 > > Help-desk: (305)663-5518 Option 2 or Email: Support at Snappytelecom.net > > ----- Original Message ----- > > From: "Maqbool Hashim" > > To: nanog at nanog.org > > Sent: Friday, May 29, 2015 4:36:34 AM > > Subject: BGP Multihoming 2 providers full or partial? > > > > Hi, > > > > > > We are an enterprise that are eBGP multihoming to two ISPs. We wish > > to load balance in inbound and outbound traffic thereby using our > > capacity as efficiently as possible. My current feeling is that it > > would be crazy for us to take a full Internet routing table from > > either ISP. I have read this document from NANOG presentations: > > > > > > https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad= > > rj > > a&uact=8&ved=0CCoQFjAA&url=https%3A%2F%2Fwww.nanog.org%2Fmeetings%2F > > na > > nog41%2Fpresentations%2FBGPMultihoming.pdf&ei=cyRnVb--FeWY7gbq4oHoAQ > > &u sg=AFQjCNFsMx3NZ0Vn4bJ5zJpzFz3senbaqg&bvm=bv.93990622,d.ZGU > > > > > > The above document reenforces my opinion that we do not need full > > routing tables. However I was seeking some clarity as there are > > other documents which suggest taking a full routing table would be optimal. > > I "guess" it depends on our criteria and requirements for load balancing: > > > > > > - Just care about roughly balancing link utilisation > > > > - Be nice to make some cost savings > > > > > > We have PI space and two Internet routers one for each ISP. Either > > of our links is sufficient to carry all our traffic, but we want to > > try and balance utilisation to remain within our commits if > > possible. I am thinking a "rough" approach for us would be: > > > > > > - Take partial (customer) routes from both providers > > > > - Take defaults from both and pref one > > > > > > Maybe we can refine the above a bit more, any suggestions would be > > most welcome! > > > > > > Many Thanks > > > > > From faisal at snappytelecom.net Sun May 31 13:12:44 2015 From: faisal at snappytelecom.net (Faisal Imtiaz) Date: Sun, 31 May 2015 13:12:44 +0000 (GMT) Subject: BGP Multihoming 2 providers full or partial? In-Reply-To: References: <88d8b6ead0414162aa5c947a3062a6f1@mbx080-w4-co-1.exch080.serverpod.net> Message-ID: <394402126.455825.1433077964755.JavaMail.zimbra@snappytelecom.net> BGP traffic engineering is kind of like Soda Prefer. that folks have.... Some like Pepsi, some Like Coke, some don't care as long as it is Cold and fizzy. Depending on who your two providers are, you may be happy with just taking full routes, and doing some creative routing (i.e. setting up static routes for outbound for specific prefixes, not the most elegant solution). Remember, BGP allows for Asymmetric routing, as such with default routes, you will have traffic coming in from both providers (by default) and traffic going out via one of them (by default). At the end of the day you are most likely to make a decision based on what is your cost for having a more powerful router, and how much 'creative routing' you want to / need to do. (My Personal opinion, is that it is a 50/50 decision to upgrade hardware just to take full routing tables.. however if there are other reasons or needs, that can sway the decision in one direction or the other). :) Faisal Imtiaz Snappy Internet & Telecom ----- Original Message ----- > From: "Maqbool Hashim" > To: "Joseph Jackson" , nanog at nanog.org > Sent: Sunday, May 31, 2015 8:09:02 AM > Subject: RE: BGP Multihoming 2 providers full or partial? > > Hi, > > No the current devices can't support full table (well not from both > providers) we would need to upgrade. Really in terms of cost saving just > want to make sure to not get charged overages because we utilise too much of > one link and not enough of another. I don't think the shortest AS path will > be of that much concern or noticeable for most destinations. > > We do however have a set of remote sites which communicate over the Internet > to our central sites where the transit providers are. Just general Internet > at the remote sites- but traffic from remote sites to central sites would be > the most important. > > I am just not sure of exactly how to define the "partial" routing table > criteria to our two providers. Should we just take routes for each provider > and their peers and a default from both? > > The main reason for not taking a full routing table is the cost/inconvenience > of upgrading existing hardware. > > Thanks > > -----Original Message----- > From: Joseph Jackson [mailto:jjackson at aninetworks.net] > Sent: 31 May 2015 12:41 > To: Maqbool Hashim; nanog at nanog.org > Subject: RE: BGP Multihoming 2 providers full or partial? > > Can your devices support a full table? > > You can load balance outbound traffic easily with out doing a full table. > THo that won't be the shortest AS path. In regards to cost savings how > were you thinking of doing so? Does one provider charge more? Just use the > cheaper provider. > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Maqbool Hashim > Sent: Friday, May 29, 2015 3:37 AM > To: nanog at nanog.org > Subject: BGP Multihoming 2 providers full or partial? > > Hi, > > > We are an enterprise that are eBGP multihoming to two ISPs. We wish to load > balance in inbound and outbound traffic thereby using our capacity as > efficiently as possible. My current feeling is that it would be crazy for us > to take a full Internet routing table from either ISP. I have read this > document from NANOG presentations: > > > https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&uact=8&ved=0CCoQFjAA&url=https%3A%2F%2Fwww.nanog.org%2Fmeetings%2Fnanog41%2Fpresentations%2FBGPMultihoming.pdf&ei=cyRnVb--FeWY7gbq4oHoAQ&usg=AFQjCNFsMx3NZ0Vn4bJ5zJpzFz3senbaqg&bvm=bv.93990622,d.ZGU > > > The above document reenforces my opinion that we do not need full routing > tables. However I was seeking some clarity as there are other documents > which suggest taking a full routing table would be optimal. I "guess" it > depends on our criteria and requirements for load balancing: > > > - Just care about roughly balancing link utilisation > > - Be nice to make some cost savings > > > We have PI space and two Internet routers one for each ISP. Either of our > links is sufficient to carry all our traffic, but we want to try and balance > utilisation to remain within our commits if possible. I am thinking a > "rough" approach for us would be: > > > - Take partial (customer) routes from both providers > > - Take defaults from both and pref one > > > Maybe we can refine the above a bit more, any suggestions would be most > welcome! > > > Many Thanks > > From owen at delong.com Sun May 31 13:40:10 2015 From: owen at delong.com (Owen DeLong) Date: Sun, 31 May 2015 06:40:10 -0700 Subject: AWS Elastic IP architecture In-Reply-To: References: <0FBA59E3-5EA1-4605-8418-EAC5D2564DB6@delong.com> <20150531091820.GQ724@hezmatt.org> Message-ID: I wasn?t being specific about VPC vs. Classic. The support for IPv6 in Classic is extremely limited and basically useless for 99+% of applications. I would argue that there is, therefore, effectively no meaningful support for IPv6 in AWS, period. What you describe below seems to me that it would only make the situation I described worse, not better in the VPC world. Owen > On May 31, 2015, at 4:23 AM, Andras Toth wrote: > > Congratulations for missing the point Matt, when I sent my email > (which by the way went for moderation) there wasn't a discussion about > Classic vs VPC yet. The discussion was "no ipv6 in AWS" which is not > true as I mentioned in my previous email. I did not state it works > everywhere, but it does work. > > In fact as Owen mentioned the following, I assumed he is talking about > Classic because this statement is only true there. In VPC you can > define your own IP subnets and it can overlap with other customers, so > basically everyone can have their own 10.0.0.0/24 for example. > "They are known to be running multiple copies of RFC-1918 in disparate > localities already. In terms of scale, modulo the nightmare that must > make of their management network and the fragility of what happens > when company A in datacenter A wants to talk to company A in > datacenter B and they both have the same 10-NET addresses" > > Andras > > > On Sun, May 31, 2015 at 7:18 PM, Matt Palmer wrote: >> On Sun, May 31, 2015 at 01:38:05AM +1000, Andras Toth wrote: >>> Perhaps if that energy which was spent on raging, instead was spent on >>> a Google search, then all those words would've been unnecessary. >>> >>> Official documentation: >>> http://docs.aws.amazon.com/ElasticLoadBalancing/latest/DeveloperGuide/elb-internet-facing-load-balancers.html#internet-facing-ip-addresses >> >> Congratulations, you've managed to find exactly the same info as Owen >> already covered: >> >> "Load balancers in a VPC support IPv4 addresses only." >> >> and >> >> "Load balancers in EC2-Classic support both IPv4 and IPv6 addresses." >> >> - Matt >> From mark.tinka at seacom.mu Sun May 31 14:13:36 2015 From: mark.tinka at seacom.mu (Mark Tinka) Date: Sun, 31 May 2015 16:13:36 +0200 Subject: BGP Multihoming 2 providers full or partial? In-Reply-To: References: <88d8b6ead0414162aa5c947a3062a6f1@mbx080-w4-co-1.exch080.serverpod.net> Message-ID: <556B1710.6040303@seacom.mu> On 31/May/15 14:09, Maqbool Hashim wrote: > > I am just not sure of exactly how to define the "partial" routing table criteria to our two providers. Should we just take routes for each provider and their peers and a default from both? Since you can't take a full feed from either upstream, partial routes will mean taking your upstream's own routes + their directly-connected customers + default. You may make it more flexible by asking for their peering routes also, but if these are large global transit providers, that could be the full BGP table anyway (or 90% of it). Mark. From bill at herrin.us Sun May 31 14:23:58 2015 From: bill at herrin.us (William Herrin) Date: Sun, 31 May 2015 10:23:58 -0400 Subject: BGP Multihoming 2 providers full or partial? In-Reply-To: References: Message-ID: On Fri, May 29, 2015 at 4:36 AM, Maqbool Hashim wrote: > We are an enterprise that are eBGP multihoming to two ISPs. We wish to load balance in inbound and outbound traffic thereby using our capacity as efficiently as possible. My current feeling is that it would be crazy for us to take a full Internet routing table from either ISP. I have read this document from NANOG presentations: Hello, Without a full table you are not protected from partitions. Partitions are when a particular destination is reachable via one of your ISPs but not via the other. Without receiving the route, you have no idea which ISP can reach it. Partitions happen fairly often but rarely last long (on the order of minutes). The worst cases tend to be when two backbones get into a peering dispute. Those have been known to last a week or more. See: Cogent v. everybody else. Think of it this way: a partial table is like an unsigned SSL certificate. Better than static routes but not fully protected. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: From blair.trosper at gmail.com Sun May 31 16:01:34 2015 From: blair.trosper at gmail.com (Blair Trosper) Date: Sun, 31 May 2015 11:01:34 -0500 Subject: AWS Elastic IP architecture In-Reply-To: References: <0FBA59E3-5EA1-4605-8418-EAC5D2564DB6@delong.com> <20150531091820.GQ724@hezmatt.org> Message-ID: Disagree, and so does AWS. IPv6 has a huge utility: being a universal, inter-region management network (a network that unites traffic between regions on public and private netblocks). Plus, at least the CDN and ELBs should be dual-stack, since more and more ISPs are turning on IPv6. On Sun, May 31, 2015 at 8:40 AM, Owen DeLong wrote: > I wasn?t being specific about VPC vs. Classic. > > The support for IPv6 in Classic is extremely limited and basically useless > for 99+% of applications. > > I would argue that there is, therefore, effectively no meaningful support > for IPv6 in AWS, period. > > What you describe below seems to me that it would only make the situation > I described worse, not better in the VPC world. > > Owen > > > On May 31, 2015, at 4:23 AM, Andras Toth wrote: > > > > Congratulations for missing the point Matt, when I sent my email > > (which by the way went for moderation) there wasn't a discussion about > > Classic vs VPC yet. The discussion was "no ipv6 in AWS" which is not > > true as I mentioned in my previous email. I did not state it works > > everywhere, but it does work. > > > > In fact as Owen mentioned the following, I assumed he is talking about > > Classic because this statement is only true there. In VPC you can > > define your own IP subnets and it can overlap with other customers, so > > basically everyone can have their own 10.0.0.0/24 for example. > > "They are known to be running multiple copies of RFC-1918 in disparate > > localities already. In terms of scale, modulo the nightmare that must > > make of their management network and the fragility of what happens > > when company A in datacenter A wants to talk to company A in > > datacenter B and they both have the same 10-NET addresses" > > > > Andras > > > > > > On Sun, May 31, 2015 at 7:18 PM, Matt Palmer > wrote: > >> On Sun, May 31, 2015 at 01:38:05AM +1000, Andras Toth wrote: > >>> Perhaps if that energy which was spent on raging, instead was spent on > >>> a Google search, then all those words would've been unnecessary. > >>> > >>> Official documentation: > >>> > http://docs.aws.amazon.com/ElasticLoadBalancing/latest/DeveloperGuide/elb-internet-facing-load-balancers.html#internet-facing-ip-addresses > >> > >> Congratulations, you've managed to find exactly the same info as Owen > >> already covered: > >> > >> "Load balancers in a VPC support IPv4 addresses only." > >> > >> and > >> > >> "Load balancers in EC2-Classic support both IPv4 and IPv6 addresses." > >> > >> - Matt > >> > > From bms at fastmail.net Sun May 31 16:22:15 2015 From: bms at fastmail.net (Bruce Simpson) Date: Sun, 31 May 2015 17:22:15 +0100 Subject: Multiple vendors' IPv6 issues In-Reply-To: <55661C73.2000504@gameservers.com> References: <20150527192055.GA26964@puck.nether.net> <55661C73.2000504@gameservers.com> Message-ID: <556B3537.50105@fastmail.net> On 27/05/2015 20:35, Brian Rak wrote: > > You don't need full promisc mode, just the (poorly documented) > allmulticast option (ip link set dev $macvtap allmulticast on) ...And poorly supported on some real hardware (notably Wi-Fi adapters), where the hash filter on each NIC's MAC is not guaranteed to support "ALLMULTI". It's a prerequisite for software multicast forwarding, and, it might be argued, a good litmus test for IPv6 readiness. From excelsio at gmx.com Sun May 31 17:46:56 2015 From: excelsio at gmx.com (Michael) Date: Sun, 31 May 2015 19:46:56 +0200 Subject: BGP Multihoming 2 providers full or partial? In-Reply-To: References: Message-ID: <556B4910.1000306@gmx.com> Well, we?re using 2x Cisco 3560X switches for simple inbound/outbound load sharing with our provider for years (http://wiki.nil.com/EBGP_load_sharing). There?s no need for us going full routes... Regards, Michael From owen at delong.com Sun May 31 17:57:41 2015 From: owen at delong.com (Owen DeLong) Date: Sun, 31 May 2015 10:57:41 -0700 Subject: AWS Elastic IP architecture In-Reply-To: References: <0FBA59E3-5EA1-4605-8418-EAC5D2564DB6@delong.com> <20150531091820.GQ724@hezmatt.org> Message-ID: Sigh? IPv6 has huge utility. AWS? implementation of IPv6 is brain-dead and mostly useless for most applications. I think if you will review my track record over the last 5+ years, you will plainly see that I am fully aware of the utility and need for IPv6. http://lmgtfy.com?q=owen+delong+ipv6 My network (AS1734) is fully dual-stacked, unlike AWS. If AWS is so convinced of the utility of IPv6, why do they continue to refuse to do a real implementation that provides IPv6 capabilities to users of their current architecture. Currently, on AWS, the only IPv6 is via ELB for classic EC2 hosts. You cannot put a native IPv6 address on an AWS virtual server at all (EC2 or VPC). Unless your application is satisfied by running an IPv4-only web server which has an IPv6 VIP proxy in front of it with some extra headers added by the proxy to help you parse out the actual source address of the connection, then your application cannot use IPv6 on AWS. As such, I stand by my statement that there is effectively no meaningful support for IPv6 in AWS, period. AWS may disagree and think that ELB for classic EC2 is somehow meaningful, but their lack of other support for any of their modern architectures and the fact that they are in the process of phasing out classic EC2 makes me think that?s a pretty hard case to make. Owen > On May 31, 2015, at 9:01 AM, Blair Trosper wrote: > > Disagree, and so does AWS. IPv6 has a huge utility: being a universal, inter-region management network (a network that unites traffic between regions on public and private netblocks). Plus, at least the CDN and ELBs should be dual-stack, since more and more ISPs are turning on IPv6. > > On Sun, May 31, 2015 at 8:40 AM, Owen DeLong > wrote: > I wasn?t being specific about VPC vs. Classic. > > The support for IPv6 in Classic is extremely limited and basically useless for 99+% of applications. > > I would argue that there is, therefore, effectively no meaningful support for IPv6 in AWS, period. > > What you describe below seems to me that it would only make the situation I described worse, not better in the VPC world. > > Owen > > > On May 31, 2015, at 4:23 AM, Andras Toth > wrote: > > > > Congratulations for missing the point Matt, when I sent my email > > (which by the way went for moderation) there wasn't a discussion about > > Classic vs VPC yet. The discussion was "no ipv6 in AWS" which is not > > true as I mentioned in my previous email. I did not state it works > > everywhere, but it does work. > > > > In fact as Owen mentioned the following, I assumed he is talking about > > Classic because this statement is only true there. In VPC you can > > define your own IP subnets and it can overlap with other customers, so > > basically everyone can have their own 10.0.0.0/24 for example. > > "They are known to be running multiple copies of RFC-1918 in disparate > > localities already. In terms of scale, modulo the nightmare that must > > make of their management network and the fragility of what happens > > when company A in datacenter A wants to talk to company A in > > datacenter B and they both have the same 10-NET addresses" > > > > Andras > > > > > > On Sun, May 31, 2015 at 7:18 PM, Matt Palmer > wrote: > >> On Sun, May 31, 2015 at 01:38:05AM +1000, Andras Toth wrote: > >>> Perhaps if that energy which was spent on raging, instead was spent on > >>> a Google search, then all those words would've been unnecessary. > >>> > >>> Official documentation: > >>> http://docs.aws.amazon.com/ElasticLoadBalancing/latest/DeveloperGuide/elb-internet-facing-load-balancers.html#internet-facing-ip-addresses > >> > >> Congratulations, you've managed to find exactly the same info as Owen > >> already covered: > >> > >> "Load balancers in a VPC support IPv4 addresses only." > >> > >> and > >> > >> "Load balancers in EC2-Classic support both IPv4 and IPv6 addresses." > >> > >> - Matt > >> > > From baldur.norddahl at gmail.com Sun May 31 18:13:56 2015 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Sun, 31 May 2015 20:13:56 +0200 Subject: BGP Multihoming 2 providers full or partial? In-Reply-To: References: Message-ID: Remember this: 1) for inbound traffic there will be no difference at all. 2) routers will ignore a static route if the link is down. If you can get BFD from the providers then even better. So you can emulate 99% of what you get with full routes by loading in static routes. A simple example would be adding a 0.0.0.0/1 route to one provider and 128.0.0.0/1 route to the other and get approximately 50% load sharing. You will still get redundancy as the route will ignored if the link is down and traffic will follow the default route to the other transit provider. If you find an offline source for IP ranges originated by each provider and their peers, you can add routes for that to improve routing. Taking in partial routes is also good if this provides you with a route count that your routers can handle. BGP shortest AS length routing is really not very good to begin with. If you want the best routes, you need to analyse your traffic, sort by volume or other metric and figure out which way is best for your top x AS destinations. It may be more work, but you will get better routing compared to investing in expensive routers to take in full routes and then hope BGP magic takes cares for the rest automatically. Regards, Baldur From matthew at matthew.at Sun May 31 18:29:44 2015 From: matthew at matthew.at (Matthew Kaufman) Date: Sun, 31 May 2015 11:29:44 -0700 Subject: AWS Elastic IP architecture In-Reply-To: References: <0FBA59E3-5EA1-4605-8418-EAC5D2564DB6@delong.com> <20150531091820.GQ724@hezmatt.org> Message-ID: Since your network has IPv6, I fail to see the issue. Nobody is anywhere near being able to go single-stack on IPv6, so AWS is just another network your customers will continue to reach over v4. So what? Heck, if v6 support from a cloud hosting company is so important, I see a great business opportunity in your future. Matthew Kaufman (Sent from my iPhone) > On May 31, 2015, at 10:57 AM, Owen DeLong wrote: > > Sigh? > > IPv6 has huge utility. > > AWS? implementation of IPv6 is brain-dead and mostly useless for most applications. > > I think if you will review my track record over the last 5+ years, you will plainly see that I am fully aware of the utility and need for IPv6. > > http://lmgtfy.com?q=owen+delong+ipv6 > > My network (AS1734) is fully dual-stacked, unlike AWS. > > If AWS is so convinced of the utility of IPv6, why do they continue to refuse to do a real implementation that provides IPv6 capabilities to users of their current architecture. > > Currently, on AWS, the only IPv6 is via ELB for classic EC2 hosts. You cannot put a native IPv6 address on an AWS virtual server at all (EC2 or VPC). Unless your application is satisfied by running an IPv4-only web server which has an IPv6 VIP proxy in front of it with some extra headers added by the proxy to help you parse out the actual source address of the connection, then your application cannot use IPv6 on AWS. > > As such, I stand by my statement that there is effectively no meaningful support for IPv6 in AWS, period. > > AWS may disagree and think that ELB for classic EC2 is somehow meaningful, but their lack of other support for any of their modern architectures and the fact that they are in the process of phasing out classic EC2 makes me think that?s a pretty hard case to make. > > Owen > >> On May 31, 2015, at 9:01 AM, Blair Trosper wrote: >> >> Disagree, and so does AWS. IPv6 has a huge utility: being a universal, inter-region management network (a network that unites traffic between regions on public and private netblocks). Plus, at least the CDN and ELBs should be dual-stack, since more and more ISPs are turning on IPv6. >> >> On Sun, May 31, 2015 at 8:40 AM, Owen DeLong > wrote: >> I wasn?t being specific about VPC vs. Classic. >> >> The support for IPv6 in Classic is extremely limited and basically useless for 99+% of applications. >> >> I would argue that there is, therefore, effectively no meaningful support for IPv6 in AWS, period. >> >> What you describe below seems to me that it would only make the situation I described worse, not better in the VPC world. >> >> Owen >> >>> On May 31, 2015, at 4:23 AM, Andras Toth > wrote: >>> >>> Congratulations for missing the point Matt, when I sent my email >>> (which by the way went for moderation) there wasn't a discussion about >>> Classic vs VPC yet. The discussion was "no ipv6 in AWS" which is not >>> true as I mentioned in my previous email. I did not state it works >>> everywhere, but it does work. >>> >>> In fact as Owen mentioned the following, I assumed he is talking about >>> Classic because this statement is only true there. In VPC you can >>> define your own IP subnets and it can overlap with other customers, so >>> basically everyone can have their own 10.0.0.0/24 for example. >>> "They are known to be running multiple copies of RFC-1918 in disparate >>> localities already. In terms of scale, modulo the nightmare that must >>> make of their management network and the fragility of what happens >>> when company A in datacenter A wants to talk to company A in >>> datacenter B and they both have the same 10-NET addresses" >>> >>> Andras >>> >>> >>>> On Sun, May 31, 2015 at 7:18 PM, Matt Palmer > wrote: >>>>> On Sun, May 31, 2015 at 01:38:05AM +1000, Andras Toth wrote: >>>>> Perhaps if that energy which was spent on raging, instead was spent on >>>>> a Google search, then all those words would've been unnecessary. >>>>> >>>>> Official documentation: >>>>> http://docs.aws.amazon.com/ElasticLoadBalancing/latest/DeveloperGuide/elb-internet-facing-load-balancers.html#internet-facing-ip-addresses >>>> >>>> Congratulations, you've managed to find exactly the same info as Owen >>>> already covered: >>>> >>>> "Load balancers in a VPC support IPv4 addresses only." >>>> >>>> and >>>> >>>> "Load balancers in EC2-Classic support both IPv4 and IPv6 addresses." >>>> >>>> - Matt > From blair.trosper at gmail.com Sun May 31 18:36:17 2015 From: blair.trosper at gmail.com (Blair Trosper) Date: Sun, 31 May 2015 13:36:17 -0500 Subject: AWS Elastic IP architecture In-Reply-To: References: <0FBA59E3-5EA1-4605-8418-EAC5D2564DB6@delong.com> <20150531091820.GQ724@hezmatt.org> Message-ID: AWS built their network first...before IPv6 "popped", so you can appreciate the huge task they have of retrofitting all their products to support it. I don't envy the task, but they have said publicly and privately that it's a priority. But it's also a massive undertaking, and you can't expect them to snap their fingers and turn it out over a weekend, man... The prize of being first cuts both ways when newer technologies at lower network levels start taking off and you don't have support built in to something proprietary. Would it be great if they had it faster? Obviously yes. Are they working on it as a priority? Yes. Can they go any faster? Probably. Are there other choices for cloud providers that are full dual stack if this really is a live or die issue for you? Yes. Access to dual-stack isn't a fundamental human right. If you don't like what AWS is doing, then use someone else who has dualstack. I don't get the outrage...and it's so irrational, that you've caused me to actually *defend* AWS. bt On Sun, May 31, 2015 at 1:29 PM, Matthew Kaufman wrote: > Since your network has IPv6, I fail to see the issue. > > Nobody is anywhere near being able to go single-stack on IPv6, so AWS is > just another network your customers will continue to reach over v4. So what? > > Heck, if v6 support from a cloud hosting company is so important, I see a > great business opportunity in your future. > > Matthew Kaufman > > (Sent from my iPhone) > > > On May 31, 2015, at 10:57 AM, Owen DeLong wrote: > > > > Sigh? > > > > IPv6 has huge utility. > > > > AWS? implementation of IPv6 is brain-dead and mostly useless for most > applications. > > > > I think if you will review my track record over the last 5+ years, you > will plainly see that I am fully aware of the utility and need for IPv6. > > > > http://lmgtfy.com?q=owen+delong+ipv6 < > http://lmgtfy.com/?q=owen+delong+ipv6> > > > > My network (AS1734) is fully dual-stacked, unlike AWS. > > > > If AWS is so convinced of the utility of IPv6, why do they continue to > refuse to do a real implementation that provides IPv6 capabilities to users > of their current architecture. > > > > Currently, on AWS, the only IPv6 is via ELB for classic EC2 hosts. You > cannot put a native IPv6 address on an AWS virtual server at all (EC2 or > VPC). Unless your application is satisfied by running an IPv4-only web > server which has an IPv6 VIP proxy in front of it with some extra headers > added by the proxy to help you parse out the actual source address of the > connection, then your application cannot use IPv6 on AWS. > > > > As such, I stand by my statement that there is effectively no meaningful > support for IPv6 in AWS, period. > > > > AWS may disagree and think that ELB for classic EC2 is somehow > meaningful, but their lack of other support for any of their modern > architectures and the fact that they are in the process of phasing out > classic EC2 makes me think that?s a pretty hard case to make. > > > > Owen > > > >> On May 31, 2015, at 9:01 AM, Blair Trosper > wrote: > >> > >> Disagree, and so does AWS. IPv6 has a huge utility: being a > universal, inter-region management network (a network that unites traffic > between regions on public and private netblocks). Plus, at least the CDN > and ELBs should be dual-stack, since more and more ISPs are turning on IPv6. > >> > >> On Sun, May 31, 2015 at 8:40 AM, Owen DeLong owen at delong.com>> wrote: > >> I wasn?t being specific about VPC vs. Classic. > >> > >> The support for IPv6 in Classic is extremely limited and basically > useless for 99+% of applications. > >> > >> I would argue that there is, therefore, effectively no meaningful > support for IPv6 in AWS, period. > >> > >> What you describe below seems to me that it would only make the > situation I described worse, not better in the VPC world. > >> > >> Owen > >> > >>> On May 31, 2015, at 4:23 AM, Andras Toth > wrote: > >>> > >>> Congratulations for missing the point Matt, when I sent my email > >>> (which by the way went for moderation) there wasn't a discussion about > >>> Classic vs VPC yet. The discussion was "no ipv6 in AWS" which is not > >>> true as I mentioned in my previous email. I did not state it works > >>> everywhere, but it does work. > >>> > >>> In fact as Owen mentioned the following, I assumed he is talking about > >>> Classic because this statement is only true there. In VPC you can > >>> define your own IP subnets and it can overlap with other customers, so > >>> basically everyone can have their own 10.0.0.0/24 > for example. > >>> "They are known to be running multiple copies of RFC-1918 in disparate > >>> localities already. In terms of scale, modulo the nightmare that must > >>> make of their management network and the fragility of what happens > >>> when company A in datacenter A wants to talk to company A in > >>> datacenter B and they both have the same 10-NET addresses" > >>> > >>> Andras > >>> > >>> > >>>> On Sun, May 31, 2015 at 7:18 PM, Matt Palmer > wrote: > >>>>> On Sun, May 31, 2015 at 01:38:05AM +1000, Andras Toth wrote: > >>>>> Perhaps if that energy which was spent on raging, instead was spent > on > >>>>> a Google search, then all those words would've been unnecessary. > >>>>> > >>>>> Official documentation: > >>>>> > http://docs.aws.amazon.com/ElasticLoadBalancing/latest/DeveloperGuide/elb-internet-facing-load-balancers.html#internet-facing-ip-addresses > < > http://docs.aws.amazon.com/ElasticLoadBalancing/latest/DeveloperGuide/elb-internet-facing-load-balancers.html#internet-facing-ip-addresses > > > >>>> > >>>> Congratulations, you've managed to find exactly the same info as Owen > >>>> already covered: > >>>> > >>>> "Load balancers in a VPC support IPv4 addresses only." > >>>> > >>>> and > >>>> > >>>> "Load balancers in EC2-Classic support both IPv4 and IPv6 addresses." > >>>> > >>>> - Matt > > > From owen at delong.com Sun May 31 18:57:16 2015 From: owen at delong.com (Owen DeLong) Date: Sun, 31 May 2015 11:57:16 -0700 Subject: AWS Elastic IP architecture In-Reply-To: References: <0FBA59E3-5EA1-4605-8418-EAC5D2564DB6@delong.com> <20150531091820.GQ724@hezmatt.org> Message-ID: > On May 31, 2015, at 11:29 AM, Matthew Kaufman wrote: > > Since your network has IPv6, I fail to see the issue. > > Nobody is anywhere near being able to go single-stack on IPv6, so AWS is just another network your customers will continue to reach over v4. So what? Sigh? The point is that all of the services and applications being built on and delivered over AWS are stuck in the IPv4 mud until such time as they can get IPv6 from AWS or move to a different cloud provider. > Heck, if v6 support from a cloud hosting company is so important, I see a great business opportunity in your future. There are already several cloud hosting companies that provide full dual-stack support. I already mentioned several of them earlier in the thread, so this is a rather silly conclusion to draw from the thread as a whole. Remember where this all started? Someone asked if the internal Amazon structure was using LISP for encapsulation. I made the semi-sarcastic comment that if they were using LISP, they probably wouldn?t have so much difficulty supporting IPv6, therefore they probably aren?t using LISP. My statement was taken all sorts of other ways by various people. Nonetheless, the bottom line remains the same: AWS can?t do IPv6 outside of a very tiny limited space which provides a solution only for one particular application (pretending to provide IPv6 web services from an IPv4-only web server through a proxy). People who are building applications and considering hosting their applications in the cloud should seriously consider whether this limitation in AWS matters to them. IMHO, forward-thinking application developers will eschew AWS in favor of clouds that have dual-stack support and build dual-stack capable applications. YMMV. Owen > > Matthew Kaufman > > (Sent from my iPhone) > >> On May 31, 2015, at 10:57 AM, Owen DeLong wrote: >> >> Sigh? >> >> IPv6 has huge utility. >> >> AWS? implementation of IPv6 is brain-dead and mostly useless for most applications. >> >> I think if you will review my track record over the last 5+ years, you will plainly see that I am fully aware of the utility and need for IPv6. >> >> http://lmgtfy.com?q=owen+delong+ipv6 >> >> My network (AS1734) is fully dual-stacked, unlike AWS. >> >> If AWS is so convinced of the utility of IPv6, why do they continue to refuse to do a real implementation that provides IPv6 capabilities to users of their current architecture. >> >> Currently, on AWS, the only IPv6 is via ELB for classic EC2 hosts. You cannot put a native IPv6 address on an AWS virtual server at all (EC2 or VPC). Unless your application is satisfied by running an IPv4-only web server which has an IPv6 VIP proxy in front of it with some extra headers added by the proxy to help you parse out the actual source address of the connection, then your application cannot use IPv6 on AWS. >> >> As such, I stand by my statement that there is effectively no meaningful support for IPv6 in AWS, period. >> >> AWS may disagree and think that ELB for classic EC2 is somehow meaningful, but their lack of other support for any of their modern architectures and the fact that they are in the process of phasing out classic EC2 makes me think that?s a pretty hard case to make. >> >> Owen >> >>> On May 31, 2015, at 9:01 AM, Blair Trosper wrote: >>> >>> Disagree, and so does AWS. IPv6 has a huge utility: being a universal, inter-region management network (a network that unites traffic between regions on public and private netblocks). Plus, at least the CDN and ELBs should be dual-stack, since more and more ISPs are turning on IPv6. >>> >>> On Sun, May 31, 2015 at 8:40 AM, Owen DeLong > wrote: >>> I wasn?t being specific about VPC vs. Classic. >>> >>> The support for IPv6 in Classic is extremely limited and basically useless for 99+% of applications. >>> >>> I would argue that there is, therefore, effectively no meaningful support for IPv6 in AWS, period. >>> >>> What you describe below seems to me that it would only make the situation I described worse, not better in the VPC world. >>> >>> Owen >>> >>>> On May 31, 2015, at 4:23 AM, Andras Toth > wrote: >>>> >>>> Congratulations for missing the point Matt, when I sent my email >>>> (which by the way went for moderation) there wasn't a discussion about >>>> Classic vs VPC yet. The discussion was "no ipv6 in AWS" which is not >>>> true as I mentioned in my previous email. I did not state it works >>>> everywhere, but it does work. >>>> >>>> In fact as Owen mentioned the following, I assumed he is talking about >>>> Classic because this statement is only true there. In VPC you can >>>> define your own IP subnets and it can overlap with other customers, so >>>> basically everyone can have their own 10.0.0.0/24 for example. >>>> "They are known to be running multiple copies of RFC-1918 in disparate >>>> localities already. In terms of scale, modulo the nightmare that must >>>> make of their management network and the fragility of what happens >>>> when company A in datacenter A wants to talk to company A in >>>> datacenter B and they both have the same 10-NET addresses" >>>> >>>> Andras >>>> >>>> >>>>> On Sun, May 31, 2015 at 7:18 PM, Matt Palmer > wrote: >>>>>> On Sun, May 31, 2015 at 01:38:05AM +1000, Andras Toth wrote: >>>>>> Perhaps if that energy which was spent on raging, instead was spent on >>>>>> a Google search, then all those words would've been unnecessary. >>>>>> >>>>>> Official documentation: >>>>>> http://docs.aws.amazon.com/ElasticLoadBalancing/latest/DeveloperGuide/elb-internet-facing-load-balancers.html#internet-facing-ip-addresses >>>>> >>>>> Congratulations, you've managed to find exactly the same info as Owen >>>>> already covered: >>>>> >>>>> "Load balancers in a VPC support IPv4 addresses only." >>>>> >>>>> and >>>>> >>>>> "Load balancers in EC2-Classic support both IPv4 and IPv6 addresses." >>>>> >>>>> - Matt >> From owen at delong.com Sun May 31 19:11:43 2015 From: owen at delong.com (Owen DeLong) Date: Sun, 31 May 2015 12:11:43 -0700 Subject: AWS Elastic IP architecture In-Reply-To: References: <0FBA59E3-5EA1-4605-8418-EAC5D2564DB6@delong.com> <20150531091820.GQ724@hezmatt.org> Message-ID: > On May 31, 2015, at 11:36 AM, Blair Trosper wrote: > > AWS built their network first...before IPv6 "popped", so you can appreciate the huge task > they have of retrofitting all their products to support it. Sure, and if they said ?We have a plan, and it will take X amount of time?, I would respect that. If they said ?We have a plan and we?re not sure how long it will take?, I would continue to poke them about sooner is better than later and having a target date helps people to plan. ?We don?t think IPv6 matters and we aren?t announcing any plans to get it implemented or any date by which it will be available?, on the other hand, being what they have actually repeatedly said to me until very recently, not so much. Now, they?re saying (essentially) ?We think IPv6 might matter, but we aren?t announcing any plans to get it implemented or any date by which it will be available? . To me, this is still a problematic situation for their customers. Especially when you look at the impact it has on the rest of the internet. Review Lee Howard?s Denver ION presentation about per-user-per-year costs of delivering IPv4 over the next several years and it rapidly becomes clear that the failure of Amazon to make dual stack available is actually one of the major factors preventing eyeball carriers from being able to make plans for IPv6 monastic on any reasonable timeframe and a major factor in their CGN costs. > I don't envy the task, but they have said publicly and privately that it's a priority. But it's > also a massive undertaking, and you can't expect them to snap their fingers and turn it > out over a weekend, man? They haven?t, really, exactly said that. They?ve sort of hinted that they might be working on it in some places. They?ve sort-a-kind-a paid it some lip service. They haven?t announced plans, dates, or any firm commitment in any form. > The prize of being first cuts both ways when newer technologies at lower network levels > start taking off and you don't have support built in to something proprietary. I started talking to folks at Amazon about this issue more than 5 years ago. At the time, they told me flat out that it was not a priority. I gave them half a decade to figure out it was a priority and do something about it while remaining relatively quite about it publicly. At this point, things have reached a point where the damage that occurs as a result of applications being deployed on such a dead-end service and the limitations that service imposes on those applications can no longer be tolerated. > Would it be great if they had it faster? Obviously yes. Agreed. > Are they working on it as a priority? Yes. Do you have any evidence to support this claim? > Can they go any faster? Probably. Isn?t that answer alone a sign that perhaps it isn?t so much of a priority to them? > Are there other choices for cloud providers that are full dual stack if this really is a > live or die issue for you? Yes. This represents one of the most common fallacies in people?s thinking about IPv6. Your failure to implement IPv6 doesn?t just impact you and your customers. Especially when you?re something like AWS. It impacts the customers of your customers and their service providers, too. If Amazon and Skype were IPv6 capable, you would actually find a relatively significant fraction of traffic that is likely to get CGN?d today would be delivered over IPv6 instead. That?s a HUGE win and a HUGE cost savings to lots of eyeball ISPs out there. None of them are likely AWS customers. None of them are likely to be perceived by AWS as ?demand? for IPv6, yet, they are in fact the source of the majority of the demand. > Access to dual-stack isn't a fundamental human right. If you don't like what AWS is doing, > then use someone else who has dualstack. Again, you are ignoring the larger consequences of their failure. You can rest assured that I am not purchasing service from AWS due to their failed policies toward IPv6. However, that doesn?t fully mitigate the impact to me from those bad decisions. So, in an effort to both further mitigate those impacts and to help others avoid them, I have started vocally encouraging people to take a serious look at AWS? lack of IPv6 and consider alternatives when selecting a cloud hosting provider. > I don't get the outrage...and it's so irrational, that you've caused me to actually *defend* AWS. I hope I have explained the reasons for my position a bit better so that you no longer feel the need to do so. I am not outraged by AWS? actions. They are free to do what they wish. However, I want to make sure that application developers are aware of the impact this has on their application, should they choose to deploy it in AWS and I want to encourage current users of AWS to consider IPv6-capable alternatives for the good of the internet. Owen > > bt > > > On Sun, May 31, 2015 at 1:29 PM, Matthew Kaufman > wrote: > Since your network has IPv6, I fail to see the issue. > > Nobody is anywhere near being able to go single-stack on IPv6, so AWS is just another network your customers will continue to reach over v4. So what? > > Heck, if v6 support from a cloud hosting company is so important, I see a great business opportunity in your future. > > Matthew Kaufman > > (Sent from my iPhone) > > > On May 31, 2015, at 10:57 AM, Owen DeLong > wrote: > > > > Sigh? > > > > IPv6 has huge utility. > > > > AWS? implementation of IPv6 is brain-dead and mostly useless for most applications. > > > > I think if you will review my track record over the last 5+ years, you will plainly see that I am fully aware of the utility and need for IPv6. > > > > http://lmgtfy.com?q=owen+delong+ipv6 > > > > > My network (AS1734) is fully dual-stacked, unlike AWS. > > > > If AWS is so convinced of the utility of IPv6, why do they continue to refuse to do a real implementation that provides IPv6 capabilities to users of their current architecture. > > > > Currently, on AWS, the only IPv6 is via ELB for classic EC2 hosts. You cannot put a native IPv6 address on an AWS virtual server at all (EC2 or VPC). Unless your application is satisfied by running an IPv4-only web server which has an IPv6 VIP proxy in front of it with some extra headers added by the proxy to help you parse out the actual source address of the connection, then your application cannot use IPv6 on AWS. > > > > As such, I stand by my statement that there is effectively no meaningful support for IPv6 in AWS, period. > > > > AWS may disagree and think that ELB for classic EC2 is somehow meaningful, but their lack of other support for any of their modern architectures and the fact that they are in the process of phasing out classic EC2 makes me think that?s a pretty hard case to make. > > > > Owen > > > >> On May 31, 2015, at 9:01 AM, Blair Trosper > wrote: > >> > >> Disagree, and so does AWS. IPv6 has a huge utility: being a universal, inter-region management network (a network that unites traffic between regions on public and private netblocks). Plus, at least the CDN and ELBs should be dual-stack, since more and more ISPs are turning on IPv6. > >> > >> On Sun, May 31, 2015 at 8:40 AM, Owen DeLong >> wrote: > >> I wasn?t being specific about VPC vs. Classic. > >> > >> The support for IPv6 in Classic is extremely limited and basically useless for 99+% of applications. > >> > >> I would argue that there is, therefore, effectively no meaningful support for IPv6 in AWS, period. > >> > >> What you describe below seems to me that it would only make the situation I described worse, not better in the VPC world. > >> > >> Owen > >> > >>> On May 31, 2015, at 4:23 AM, Andras Toth >> wrote: > >>> > >>> Congratulations for missing the point Matt, when I sent my email > >>> (which by the way went for moderation) there wasn't a discussion about > >>> Classic vs VPC yet. The discussion was "no ipv6 in AWS" which is not > >>> true as I mentioned in my previous email. I did not state it works > >>> everywhere, but it does work. > >>> > >>> In fact as Owen mentioned the following, I assumed he is talking about > >>> Classic because this statement is only true there. In VPC you can > >>> define your own IP subnets and it can overlap with other customers, so > >>> basically everyone can have their own 10.0.0.0/24 > for example. > >>> "They are known to be running multiple copies of RFC-1918 in disparate > >>> localities already. In terms of scale, modulo the nightmare that must > >>> make of their management network and the fragility of what happens > >>> when company A in datacenter A wants to talk to company A in > >>> datacenter B and they both have the same 10-NET addresses" > >>> > >>> Andras > >>> > >>> > >>>> On Sun, May 31, 2015 at 7:18 PM, Matt Palmer >> wrote: > >>>>> On Sun, May 31, 2015 at 01:38:05AM +1000, Andras Toth wrote: > >>>>> Perhaps if that energy which was spent on raging, instead was spent on > >>>>> a Google search, then all those words would've been unnecessary. > >>>>> > >>>>> Official documentation: > >>>>> http://docs.aws.amazon.com/ElasticLoadBalancing/latest/DeveloperGuide/elb-internet-facing-load-balancers.html#internet-facing-ip-addresses > > >>>> > >>>> Congratulations, you've managed to find exactly the same info as Owen > >>>> already covered: > >>>> > >>>> "Load balancers in a VPC support IPv4 addresses only." > >>>> > >>>> and > >>>> > >>>> "Load balancers in EC2-Classic support both IPv4 and IPv6 addresses." > >>>> > >>>> - Matt > > > > From jason at unlimitednet.us Sun May 31 20:46:51 2015 From: jason at unlimitednet.us (Jason Canady) Date: Sun, 31 May 2015 16:46:51 -0400 Subject: BGP Multihoming 2 providers full or partial? In-Reply-To: References: Message-ID: <556B733B.2040008@unlimitednet.us> If your traffic is small, you could setup a VyOS box. You can still get redundancy by having two switches, each one connected to an upstream provider receiving a default route. Then hookup your VyOS router to each switch and receive full routes to that. You will need a /29 subnet from your providers to pull this off. If your VyOS box goes down for whatever reason, you will failover to using one or the other switch. Announce your prefixes using the BGP session on each switch so that your inbound traffic doesn't hit the VyOS box. -- Jason Canady Unlimited Net, LLC Responsive, Reliable, Secure www.unlimitednet.us jason at unlimitednet.us twitter: @unlimitednet On 5/29/15 4:36 AM, Maqbool Hashim wrote: > Hi, > > > We are an enterprise that are eBGP multihoming to two ISPs. We wish to load balance in inbound and outbound traffic thereby using our capacity as efficiently as possible. My current feeling is that it would be crazy for us to take a full Internet routing table from either ISP. I have read this document from NANOG presentations: > > > https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&uact=8&ved=0CCoQFjAA&url=https%3A%2F%2Fwww.nanog.org%2Fmeetings%2Fnanog41%2Fpresentations%2FBGPMultihoming.pdf&ei=cyRnVb--FeWY7gbq4oHoAQ&usg=AFQjCNFsMx3NZ0Vn4bJ5zJpzFz3senbaqg&bvm=bv.93990622,d.ZGU > > > The above document reenforces my opinion that we do not need full routing tables. However I was seeking some clarity as there are other documents which suggest taking a full routing table would be optimal. I "guess" it depends on our criteria and requirements for load balancing: > > > - Just care about roughly balancing link utilisation > > - Be nice to make some cost savings > > > We have PI space and two Internet routers one for each ISP. Either of our links is sufficient to carry all our traffic, but we want to try and balance utilisation to remain within our commits if possible. I am thinking a "rough" approach for us would be: > > > - Take partial (customer) routes from both providers > > - Take defaults from both and pref one > > > Maybe we can refine the above a bit more, any suggestions would be most welcome! > > > Many Thanks > From wesley.george at twcable.com Sun May 31 21:49:16 2015 From: wesley.george at twcable.com (George, Wes) Date: Sun, 31 May 2015 17:49:16 -0400 Subject: AWS Elastic IP architecture In-Reply-To: References: <0FBA59E3-5EA1-4605-8418-EAC5D2564DB6@delong.com> <20150531091820.GQ724@hezmatt.org> Message-ID: On 5/31/15, 3:11 PM, "Owen DeLong" wrote: >if they said ?We have a plan, and it will take X amount of time?, I would >respect that. > >If they said ?We have a plan and we?re not sure how long it will take?, I >would continue to poke >them about sooner is better than later and having a target date helps >people to plan. > >?We don?t think IPv6 matters and we aren?t announcing any plans to get it >implemented or any >date by which it will be available?, on the other hand, being what they >have actually repeatedly >said to me until very recently, not so much. > >Now, they?re saying (essentially) ?We think IPv6 might matter, but we >aren?t announcing >any plans to get it implemented or any date by which it will be >available? . To me, this >is still a problematic situation for their customers. At the risk of feeding the troll... This isn't just an AWS problem. "All Compute Engine networks use the IPv4 protocol. Compute Engine currently does not support IPv6. However, Google is a major advocate of IPv6 and it is an important future direction." https://cloud.google.com/compute/docs/networking "The foundational work to enable IPv6 in the Azure environment is well underway. However, we are unable to share a date when IPv6 support will be generally available at this time." http://azure.microsoft.com/en-us/pricing/faq/ This is only marginally better, as it acknowledges that it's important, but still has no actual committed timeline and doesn't even reference any available ELB hacks. Anyone else want to either name and shame, or highlight cloud providers that actually *support* IPv6 as an alternative to these so that one might be able to vote with one's wallet? This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout. From matthew at matthew.at Sun May 31 22:11:22 2015 From: matthew at matthew.at (Matthew Kaufman) Date: Sun, 31 May 2015 15:11:22 -0700 Subject: AWS Elastic IP architecture In-Reply-To: References: <0FBA59E3-5EA1-4605-8418-EAC5D2564DB6@delong.com> <20150531091820.GQ724@hezmatt.org> Message-ID: <556B870A.9080306@matthew.at> On 5/31/2015 11:57 AM, Owen DeLong wrote: > People who are building applications and considering hosting their > applications in the cloud should seriously consider whether this > limitation in AWS matters to them. It doesn't, because everyone "on the Internet" can reach IPv4-hosted services. > IMHO, forward-thinking application developers will eschew AWS in favor > of clouds that have dual-stack support and build dual-stack capable > applications. Forward-thinking developers are using big clouds that have the resources to enable IPv6 long before having IPv6 actually matters. Matthew Kaufman From abdullah.medhat.salah at gmail.com Sun May 31 10:07:00 2015 From: abdullah.medhat.salah at gmail.com (Abdullah Medhat) Date: Sun, 31 May 2015 12:07:00 +0200 Subject: WiFi courses/vendors recommendation Message-ID: Good day all, We are looking forward to establish MetroWifi network as a new business line in our company, in addition to small/medium events Wifi coverage. I have two questions: 1. What are the required resources/material/training curriculum to let our engineers start educating in this? We are looking for the vendor-agnostic materials that will give our engineers the WiFi essentials/fundamentals to start building a good foundation before evolving to the professional level. 2. What vendors do you recommend? We need to find a cost-effective yet competent option with good pre/post sales service. Thanks, -- Abdullah Medhat From jamesl at mythostech.com Sun May 31 22:28:49 2015 From: jamesl at mythostech.com (James Laszko) Date: Sun, 31 May 2015 22:28:49 +0000 Subject: WiFi courses/vendors recommendation In-Reply-To: References: Message-ID: <8078ED370ADA824281219A7B5BADC39B6C6A70E7@MBX023-W1-CA-4.exch023.domain.local> I don't have a vendor-agnostic answer for you on #1, but as far as a vendor - Ruckus Wireless. We are a partner who sells and deploys and the stuff is quite awesome for what you're looking for. I'd be happy to introduce you to relevant people over there for guidance. Regards, James Laszko Mythos Technology Inc jamesl at mythostech.com -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Abdullah Medhat Sent: Sunday, May 31, 2015 3:07 AM To: nanog at nanog.org Subject: WiFi courses/vendors recommendation Good day all, We are looking forward to establish MetroWifi network as a new business line in our company, in addition to small/medium events Wifi coverage. I have two questions: 1. What are the required resources/material/training curriculum to let our engineers start educating in this? We are looking for the vendor-agnostic materials that will give our engineers the WiFi essentials/fundamentals to start building a good foundation before evolving to the professional level. 2. What vendors do you recommend? We need to find a cost-effective yet competent option with good pre/post sales service. Thanks, -- Abdullah Medhat From dave.taht at gmail.com Sun May 31 22:39:20 2015 From: dave.taht at gmail.com (Dave Taht) Date: Sun, 31 May 2015 15:39:20 -0700 Subject: WiFi courses/vendors recommendation In-Reply-To: <8078ED370ADA824281219A7B5BADC39B6C6A70E7@MBX023-W1-CA-4.exch023.domain.local> References: <8078ED370ADA824281219A7B5BADC39B6C6A70E7@MBX023-W1-CA-4.exch023.domain.local> Message-ID: On Sun, May 31, 2015 at 3:28 PM, James Laszko wrote: > I don't have a vendor-agnostic answer for you on #1, but as far as a vendor - Ruckus Wireless. We are a partner who sells and deploys and the stuff is quite awesome for what you're looking for. I'd be happy to introduce you to relevant people over there for guidance. > 1) I have long thought about developing such course materials or working with the author (dave lang) of the wonderful scale2012 report to do so. If you find any good materials pre-existing please let me know also. I once gave a good intro talk on wifi subjects... ( https://www.youtube.com/watch?v=Wksh2DPHCDI ) As for 2) There are many vendors in the enterprise wifi space - cisco, ubnt, aruba, and meraki, to name a few more. Of these the only ones publicly acknowledging doing something about their wifi bufferbloat are cisco and meraki. (I realize you have plenty of other issues/features to look for, it's fixing that one happens to be my number #1 requirement these days) > > Regards, > > > James Laszko > Mythos Technology Inc > jamesl at mythostech.com > > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Abdullah Medhat > Sent: Sunday, May 31, 2015 3:07 AM > To: nanog at nanog.org > Subject: WiFi courses/vendors recommendation > > Good day all, > > We are looking forward to establish MetroWifi network as a new business line in our company, in addition to small/medium events Wifi coverage. > > I have two questions: > 1. What are the required resources/material/training curriculum to let our engineers start educating in this? We are looking for the vendor-agnostic materials that will give our engineers the WiFi essentials/fundamentals to start building a good foundation before evolving to the professional level. > > 2. What vendors do you recommend? We need to find a cost-effective yet competent option with good pre/post sales service. > > Thanks, > > -- > > Abdullah Medhat -- Dave T?ht What will it take to vastly improve wifi for everyone? https://plus.google.com/u/0/explore/makewififast From ilissa at imillerpr.com Sun May 31 22:40:09 2015 From: ilissa at imillerpr.com (Ilissa Miller) Date: Sun, 31 May 2015 15:40:09 -0700 Subject: WiFi courses/vendors recommendation In-Reply-To: References: Message-ID: <2323611238166620553@unknownmsgid> You may want to check out iBwave. They do training as well. Ilissa Miller > On May 31, 2015, at 3:27 PM, Abdullah Medhat wrote: > > Good day all, > > We are looking forward to establish MetroWifi network as a new business > line in our company, in addition to small/medium events Wifi coverage. > > I have two questions: > 1. What are the required resources/material/training curriculum to let our > engineers start educating in this? We are looking for the vendor-agnostic > materials that will give our engineers the WiFi essentials/fundamentals to > start building a good foundation before evolving to the professional level. > > 2. What vendors do you recommend? We need to find a cost-effective yet > competent option with good pre/post sales service. > > Thanks, > > -- > > Abdullah Medhat From mike.lyon at gmail.com Sun May 31 22:43:42 2015 From: mike.lyon at gmail.com (Mike Lyon) Date: Sun, 31 May 2015 15:43:42 -0700 Subject: WiFi courses/vendors recommendation In-Reply-To: <8078ED370ADA824281219A7B5BADC39B6C6A70E7@MBX023-W1-CA-4.exch023.domain.local> References: <8078ED370ADA824281219A7B5BADC39B6C6A70E7@MBX023-W1-CA-4.exch023.domain.local> Message-ID: Ubiquiti Networks. Its cheap and it works great. Support sucks though. I use Ubuquiti gear for my wireless ISP and i use their UniFi APs for when i do events. If you need high density wireless, check out Xirrus Wireless access points, they are awesome. -Mike On May 31, 2015 3:30 PM, "James Laszko" wrote: > I don't have a vendor-agnostic answer for you on #1, but as far as a > vendor - Ruckus Wireless. We are a partner who sells and deploys and the > stuff is quite awesome for what you're looking for. I'd be happy to > introduce you to relevant people over there for guidance. > > > Regards, > > > James Laszko > Mythos Technology Inc > jamesl at mythostech.com > > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Abdullah Medhat > Sent: Sunday, May 31, 2015 3:07 AM > To: nanog at nanog.org > Subject: WiFi courses/vendors recommendation > > Good day all, > > We are looking forward to establish MetroWifi network as a new business > line in our company, in addition to small/medium events Wifi coverage. > > I have two questions: > 1. What are the required resources/material/training curriculum to let our > engineers start educating in this? We are looking for the vendor-agnostic > materials that will give our engineers the WiFi essentials/fundamentals to > start building a good foundation before evolving to the professional level. > > 2. What vendors do you recommend? We need to find a cost-effective yet > competent option with good pre/post sales service. > > Thanks, > > -- > > Abdullah Medhat >