From jfmezei_nanog at vaxination.ca Fri Apr 1 06:38:03 2016 From: jfmezei_nanog at vaxination.ca (Jean-Francois Mezei) Date: Fri, 1 Apr 2016 02:38:03 -0400 Subject: Capacity planning , transit vs last mile In-Reply-To: References: <56FCC8D4.1040806@vaxination.ca> Message-ID: <56FE174B.3060405@vaxination.ca> On 2016-03-31 19:38, Baldur Norddahl wrote: > You will find that total data download per month is unrelated to service > speed except for very slow service. Yep. Netflix still takes 7mbps even if you are on a 1gbps service. However, with families, higher speed allow more family members to be active at same time and this could begin to have visible impact (if not already). Note that a rural coop deployed FTTP for their territory, but only offer 40mbps max subscription because they can't afford the transit from the single incumbent who offers transit in their region. So I assume that with under 1000, service speed starts to matter when sizing the transit capacity. > If you have too few users the pattern becomes chaotic. My question has to do with how does one determine that theshold where you start to get more chaotic patterns and need more capacity per customer than if you had over 1000 customers ? My goal is to suggest some standard to prevent gross underprovisioning by ISPs who win subsidies to deploy in a region. >From what I am reading, the old standard (contention ratio of 50:1 for residential service) is no longer valid as a single metric especially for smaller deployments with higher speeds. For the last mile, GPON is easy as it is essentually 32 homes per GPON link. For cable, the CRTC would have its own numbers for number of homes per node. (BTW, Australia's NBN V2.0 plans to have 600 homes per node since they don't have budget to split nodes). But for fixed wireless and satellite, there needs to be some standard to provent gross oversubscription. Say you have a fixed wirelss tower with enough spectrum to broadcast 40mbps. How do you calculate how many customers at average speed of 15mbps can comfortably fit on this antenna ? I realise existing ISPs use monthly statistics of 95th percentile to see how much capacity is used and whether the link has reached saturation and there should be s stop sell or get more spectrum. But from a regulatory point of view, in evaluating a bid to serve a region, the regulator would need rules to establish whether the bidder will be able to serve the population with whatever solution the bidder proposes. Does the FCC have any such rules in the USA, or are its broadband deployment subsidies only based on the ISP marketing speeds that meet the FCC's definition of "broadband" ? (and no concern about whether those will be delivered or not). From baldur.norddahl at gmail.com Fri Apr 1 08:07:00 2016 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Fri, 1 Apr 2016 10:07:00 +0200 Subject: Capacity planning , transit vs last mile In-Reply-To: <56FE174B.3060405@vaxination.ca> References: <56FCC8D4.1040806@vaxination.ca> <56FE174B.3060405@vaxination.ca> Message-ID: Hi 40 Mbps is plenty fast that even a family will not be using much more data with higher speed. So that transit argument is a poor excuse. A formula could be: [max speed sold to customers] * 2 + [number of customers] * [average peak number] The number 2 in the above is not well researched but I would expect it to be in that ballpark. The [average peak number] is 2 Mbps for our network. Others seem to claim they get away with only 1 Mbps, but our users are doing 2 Mbps for sure. I believe this is probably because we have many families. It does matter when each customer is really a family of 5 compared to one single person. The formula holds up for both few and large number of users. With few users the left side of the formula dominates and with many users it is the right side. Regards, Baldur On 1 April 2016 at 08:38, Jean-Francois Mezei wrote: > On 2016-03-31 19:38, Baldur Norddahl wrote: > > You will find that total data download per month is unrelated to service > > speed except for very slow service. > > Yep. Netflix still takes 7mbps even if you are on a 1gbps service. > However, with families, higher speed allow more family members to be > active at same time and this could begin to have visible impact (if not > already). > > > Note that a rural coop deployed FTTP for their territory, but only offer > 40mbps max subscription because they can't afford the transit from the > single incumbent who offers transit in their region. So I assume that > with under 1000, service speed starts to matter when sizing the transit > capacity. > > > > If you have too few users the pattern becomes chaotic. > > My question has to do with how does one determine that theshold where > you start to get more chaotic patterns and need more capacity per > customer than if you had over 1000 customers ? > > My goal is to suggest some standard to prevent gross underprovisioning > by ISPs who win subsidies to deploy in a region. > > From what I am reading, the old standard (contention ratio of 50:1 for > residential service) is no longer valid as a single metric especially > for smaller deployments with higher speeds. > > > > For the last mile, GPON is easy as it is essentually 32 homes per GPON > link. For cable, the CRTC would have its own numbers for number of homes > per node. (BTW, Australia's NBN V2.0 plans to have 600 homes per node > since they don't have budget to split nodes). > > But for fixed wireless and satellite, there needs to be some standard to > provent gross oversubscription. > > Say you have a fixed wirelss tower with enough spectrum to broadcast > 40mbps. How do you calculate how many customers at average speed of > 15mbps can comfortably fit on this antenna ? > > I realise existing ISPs use monthly statistics of 95th percentile to see > how much capacity is used and whether the link has reached saturation > and there should be s stop sell or get more spectrum. > > But from a regulatory point of view, in evaluating a bid to serve a > region, the regulator would need rules to establish whether the bidder > will be able to serve the population with whatever solution the bidder > proposes. > > Does the FCC have any such rules in the USA, or are its broadband > deployment subsidies only based on the ISP marketing speeds that meet > the FCC's definition of "broadband" ? (and no concern about whether > those will be delivered or not). > > > > From nanog at ics-il.net Fri Apr 1 11:29:39 2016 From: nanog at ics-il.net (Mike Hammett) Date: Fri, 1 Apr 2016 06:29:39 -0500 (CDT) Subject: Capacity planning , transit vs last mile In-Reply-To: <56FE174B.3060405@vaxination.ca> Message-ID: <503662586.6191.1459510178851.JavaMail.mhammett@ThunderFuck> "enough spectrum to broadcast 40mbps." I'd say you need better equipment. :-) ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Jean-Francois Mezei" Cc: Nanog at nanog.org Sent: Friday, April 1, 2016 1:38:03 AM Subject: Re: Capacity planning , transit vs last mile On 2016-03-31 19:38, Baldur Norddahl wrote: > You will find that total data download per month is unrelated to service > speed except for very slow service. Yep. Netflix still takes 7mbps even if you are on a 1gbps service. However, with families, higher speed allow more family members to be active at same time and this could begin to have visible impact (if not already). Note that a rural coop deployed FTTP for their territory, but only offer 40mbps max subscription because they can't afford the transit from the single incumbent who offers transit in their region. So I assume that with under 1000, service speed starts to matter when sizing the transit capacity. > If you have too few users the pattern becomes chaotic. My question has to do with how does one determine that theshold where you start to get more chaotic patterns and need more capacity per customer than if you had over 1000 customers ? My goal is to suggest some standard to prevent gross underprovisioning by ISPs who win subsidies to deploy in a region. >From what I am reading, the old standard (contention ratio of 50:1 for residential service) is no longer valid as a single metric especially for smaller deployments with higher speeds. For the last mile, GPON is easy as it is essentually 32 homes per GPON link. For cable, the CRTC would have its own numbers for number of homes per node. (BTW, Australia's NBN V2.0 plans to have 600 homes per node since they don't have budget to split nodes). But for fixed wireless and satellite, there needs to be some standard to provent gross oversubscription. Say you have a fixed wirelss tower with enough spectrum to broadcast 40mbps. How do you calculate how many customers at average speed of 15mbps can comfortably fit on this antenna ? I realise existing ISPs use monthly statistics of 95th percentile to see how much capacity is used and whether the link has reached saturation and there should be s stop sell or get more spectrum. But from a regulatory point of view, in evaluating a bid to serve a region, the regulator would need rules to establish whether the bidder will be able to serve the population with whatever solution the bidder proposes. Does the FCC have any such rules in the USA, or are its broadband deployment subsidies only based on the ISP marketing speeds that meet the FCC's definition of "broadband" ? (and no concern about whether those will be delivered or not). From blake at ispn.net Fri Apr 1 14:32:04 2016 From: blake at ispn.net (Blake Hudson) Date: Fri, 1 Apr 2016 09:32:04 -0500 Subject: Capacity planning , transit vs last mile In-Reply-To: <56FE174B.3060405@vaxination.ca> References: <56FCC8D4.1040806@vaxination.ca> <56FE174B.3060405@vaxination.ca> Message-ID: <56FE8664.4020000@ispn.net> Jean-Francois Mezei wrote on 4/1/2016 1:38 AM: > My question has to do with how does one determine that theshold where > you start to get more chaotic patterns and need more capacity per > customer than if you had over 1000 customers ? > > My goal is to suggest some standard to prevent gross underprovisioning > by ISPs who win subsidies to deploy in a region. > > From what I am reading, the old standard (contention ratio of 50:1 for > residential service) is no longer valid as a single metric especially > for smaller deployments with higher speeds. While the formula provided by Baldur may very well be accurate, it allows projections on several data points (advertised speed, average per customer speed, customer counts, customers online @ peak) which may or may not turn out to be accurate or could be fudged to create misleading estimates. I think a simpler projection, taking harder numbers into account may be easier to implement as a requirement and less likely to be gained by someone. I think it would be sufficient to simply specify a minimum Mbps bound per customer (aka a committed information rate) for a network build. As you and others have stated, typical current use is currently ~1-2Mbps per household/customer. If we forecast growth to be 30% per year, a 10 year build might anticipate using a last mile technology capable of providing ~13Mbps CIR [using the compound interest formula where A = 1Mbps * (1 + 0.3)^10years ] in 10 years time. This projection uses growth, which has historical precedent, and current usage, which you indicate is already being measured and reported. Something that is less static would be the technology improvements. An operator might be able to assume gpon now and 10G-pon in a few years (or DOCSIS 3.0 -> 3.1), to meet future requirements. Regarding your question about how such a formula might scale, especially on the small end. I think it's a valid concern. This could be measured in today's rural HFC networks or wireless network where it may be common to have fewer than 50 customers sharing a 40Mbps-100Mbps access media. I think you'll find that at this small a scale, the 1-2Mbps per customer number probably still holds true. You obviously won't be able to sell 1000Mbps service (or even 100Mbps) to these customers, given the access media limitations. This could be addressed elsewhere in your requirements. For example, if it were required that operators "...offer services capable of delivering 100Mbps service to each end user with a CIR derived from table A", the operator would be forced to provide a 100Mbps+ pipe even if it were only serving 10 customers on that pipe that see ~ 20Mbps aggregate peak period usage today. That 80Mbps of overhead is not wasted, it's intentionally there for your users' future needs and to provide burst capacity. A smart operator would probably avoid such cases and attempt to aggregate users in ways that minimize expense and make the most of the access technology. --Blake From cscora at apnic.net Fri Apr 1 18:10:27 2016 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 2 Apr 2016 04:10:27 +1000 (AEST) Subject: Weekly Routing Table Report Message-ID: <201604011810.u31IARjm003234@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, SAFNOG, PaNOG, SdNOG, BJNOG, CaribNOG and the RIPE Routing WG. 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 Apr, 2016 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 588557 Prefixes after maximum aggregation (per Origin AS): 216385 Deaggregation factor: 2.72 Unique aggregates announced (without unneeded subnets): 288091 Total ASes present in the Internet Routing Table: 53275 Prefixes per ASN: 11.05 Origin-only ASes present in the Internet Routing Table: 36612 Origin ASes announcing only one prefix: 15734 Transit ASes present in the Internet Routing Table: 6406 Transit-only ASes present in the Internet Routing Table: 178 Average AS path length visible in the Internet Routing Table: 4.3 Max AS path length visible: 37 Max AS path prepend of ASN ( 40285) 34 Prefixes from unregistered ASNs in the Routing Table: 966 Unregistered ASNs in the Routing Table: 358 Number of 32-bit ASNs allocated by the RIRs: 13295 Number of 32-bit ASNs visible in the Routing Table: 10257 Prefixes from 32-bit ASNs in the Routing Table: 40054 Number of bogon 32-bit ASNs visible in the Routing Table: 13 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 379 Number of addresses announced to Internet: 2806633732 Equivalent to 167 /8s, 73 /16s and 213 /24s Percentage of available address space announced: 75.8 Percentage of allocated address space announced: 75.8 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 98.1 Total number of prefixes smaller than registry allocations: 192525 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 150775 Total APNIC prefixes after maximum aggregation: 41981 APNIC Deaggregation factor: 3.59 Prefixes being announced from the APNIC address blocks: 160950 Unique aggregates announced from the APNIC address blocks: 65681 APNIC Region origin ASes present in the Internet Routing Table: 5146 APNIC Prefixes per ASN: 31.28 APNIC Region origin ASes announcing only one prefix: 1183 APNIC Region transit ASes present in the Internet Routing Table: 903 Average APNIC Region AS path length visible: 4.5 Max APNIC Region AS path length visible: 35 Number of APNIC region 32-bit ASNs visible in the Routing Table: 1966 Number of APNIC addresses announced to Internet: 751627332 Equivalent to 44 /8s, 204 /16s and 236 /24s Percentage of available APNIC address space announced: 87.8 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: 180018 Total ARIN prefixes after maximum aggregation: 89009 ARIN Deaggregation factor: 2.02 Prefixes being announced from the ARIN address blocks: 185195 Unique aggregates announced from the ARIN address blocks: 87864 ARIN Region origin ASes present in the Internet Routing Table: 16394 ARIN Prefixes per ASN: 11.30 ARIN Region origin ASes announcing only one prefix: 5882 ARIN Region transit ASes present in the Internet Routing Table: 1713 Average ARIN Region AS path length visible: 3.8 Max ARIN Region AS path length visible: 37 Number of ARIN region 32-bit ASNs visible in the Routing Table: 1099 Number of ARIN addresses announced to Internet: 1101578560 Equivalent to 65 /8s, 168 /16s and 193 /24s Percentage of available ARIN address space announced: 58.3 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: 141552 Total RIPE prefixes after maximum aggregation: 69988 RIPE Deaggregation factor: 2.02 Prefixes being announced from the RIPE address blocks: 150107 Unique aggregates announced from the RIPE address blocks: 92701 RIPE Region origin ASes present in the Internet Routing Table: 18072 RIPE Prefixes per ASN: 8.31 RIPE Region origin ASes announcing only one prefix: 7912 RIPE Region transit ASes present in the Internet Routing Table: 2997 Average RIPE Region AS path length visible: 4.3 Max RIPE Region AS path length visible: 26 Number of RIPE region 32-bit ASNs visible in the Routing Table: 4606 Number of RIPE addresses announced to Internet: 704360576 Equivalent to 41 /8s, 251 /16s and 176 /24s Percentage of available RIPE address space announced: 102.4 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-204287 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: 61798 Total LACNIC prefixes after maximum aggregation: 12183 LACNIC Deaggregation factor: 5.07 Prefixes being announced from the LACNIC address blocks: 75832 Unique aggregates announced from the LACNIC address blocks: 35811 LACNIC Region origin ASes present in the Internet Routing Table: 2470 LACNIC Prefixes per ASN: 30.70 LACNIC Region origin ASes announcing only one prefix: 578 LACNIC Region transit ASes present in the Internet Routing Table: 551 Average LACNIC Region AS path length visible: 4.7 Max LACNIC Region AS path length visible: 25 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 2386 Number of LACNIC addresses announced to Internet: 170590976 Equivalent to 10 /8s, 43 /16s and 3 /24s Percentage of available LACNIC address space announced: 101.7 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: 14280 Total AfriNIC prefixes after maximum aggregation: 3183 AfriNIC Deaggregation factor: 4.49 Prefixes being announced from the AfriNIC address blocks: 16094 Unique aggregates announced from the AfriNIC address blocks: 5693 AfriNIC Region origin ASes present in the Internet Routing Table: 732 AfriNIC Prefixes per ASN: 21.99 AfriNIC Region origin ASes announcing only one prefix: 179 AfriNIC Region transit ASes present in the Internet Routing Table: 167 Average AfriNIC Region AS path length visible: 4.6 Max AfriNIC Region AS path length visible: 25 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 200 Number of AfriNIC addresses announced to Internet: 78107392 Equivalent to 4 /8s, 167 /16s and 211 /24s Percentage of available AfriNIC address space announced: 77.6 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 4538 5594 4192 76 China Education and Research 7545 3275 352 190 TPG Telecom Limited 4766 3151 11142 1117 Korea Telecom 17974 2912 914 96 PT Telekomunikasi Indonesia 9829 2446 1457 446 National Internet Backbone 4755 2100 432 245 TATA Communications formerly 9808 1854 8717 30 Guangdong Mobile Communicatio 4808 1650 2290 531 CNCGROUP IP network China169 4788 1528 645 62 TM Net, Internet Service Prov 9583 1519 121 564 Sify Limited 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 3345 2948 148 Cox Communications Inc. 6389 2357 3687 42 BellSouth.net Inc. 18566 2209 394 276 MegaPath Corporation 20115 1920 1931 402 Charter Communications 30036 1737 344 237 Mediacom Communications Corp 6983 1691 849 231 EarthLink, Inc. 4323 1570 1004 386 tw telecom holdings, inc. 209 1553 4636 1235 Qwest Communications Company, 701 1382 11446 661 MCI Communications Services, 11492 1270 235 601 CABLE ONE, INC. 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 2708 143 10 SaudiNet, Saudi Telecom Compa 20940 2425 933 1761 Akamai International B.V. 34984 1962 323 415 TELLCOM ILETISIM HIZMETLERI A 8551 1259 376 54 Bezeq International-Ltd 6849 1158 355 21 JSC "Ukrtelecom" 12479 1140 980 86 France Telecom Espana SA 8402 1101 544 15 OJSC "Vimpelcom" 13188 1079 98 69 TOV "Bank-Inform" 31148 1035 47 41 Freenet Ltd. 6830 891 2712 464 Liberty Global Operations B.V 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 3448 542 134 Telmex Colombia S.A. 8151 2217 3310 542 Uninet S.A. de C.V. 7303 1521 940 245 Telecom Argentina S.A. 11830 1479 368 51 Instituto Costarricense de El 6503 1433 453 56 Axtel, S.A.B. de C.V. 6147 1050 377 27 Telefonica del Peru S.A.A. 3816 994 478 185 COLOMBIA TELECOMUNICACIONES S 26615 993 2325 34 Tim Celular S.A. 7738 990 1882 40 Telemar Norte Leste S.A. 28573 884 2172 160 NET Servi?os de Comunica??o S 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 1217 402 40 Link Egypt (Link.NET) 8452 679 1472 15 TE-AS 37611 643 48 2 Afrihost-Brevis Computer Serv 36903 584 294 104 Office National des Postes et 36992 506 1357 25 ETISALAT MISR 37492 382 233 65 Orange Tunisie 29571 295 37 12 Cote d'Ivoire Telecom 24835 290 146 12 Vodafone Data 2018 249 327 74 TENET (The UNINET Project) 36947 234 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 4538 5594 4192 76 China Education and Research 10620 3448 542 134 Telmex Colombia S.A. 22773 3345 2948 148 Cox Communications Inc. 7545 3275 352 190 TPG Telecom Limited 4766 3151 11142 1117 Korea Telecom 17974 2912 914 96 PT Telekomunikasi Indonesia 39891 2708 143 10 SaudiNet, Saudi Telecom Compa 9829 2446 1457 446 National Internet Backbone 20940 2425 933 1761 Akamai International B.V. 6389 2357 3687 42 BellSouth.net Inc. Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 10620 3448 3314 Telmex Colombia S.A. 22773 3345 3197 Cox Communications Inc. 7545 3275 3085 TPG Telecom Limited 17974 2912 2816 PT Telekomunikasi Indonesia 39891 2708 2698 SaudiNet, Saudi Telecom Compa 6389 2357 2315 BellSouth.net Inc. 4766 3151 2034 Korea Telecom 9829 2446 2000 National Internet Backbone 18566 2209 1933 MegaPath Corporation 4755 2100 1855 TATA Communications formerly 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 16589 UNALLOCATED 8.20.247.0/24 35838 CCANET Limited 16589 UNALLOCATED 8.26.56.0/24 35838 CCANET Limited 46473 UNALLOCATED 8.27.122.0/24 3356 Level 3 Communicatio 46473 UNALLOCATED 8.27.124.0/24 3356 Level 3 Communicatio 27205 UNALLOCATED 8.38.16.0/21 3356 Level 3 Communicatio 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<< 23.249.144.0/20 40430 colo4jax, LLC 27.100.7.0/24 56096 >>UNKNOWN<< 37.46.10.0/23 36351 SoftLayer Technologies Inc. 37.46.14.0/24 36351 SoftLayer Technologies Inc. 37.46.15.0/24 36351 SoftLayer Technologies Inc. 41.73.1.0/24 37004 >>UNKNOWN<< 41.73.2.0/24 37004 >>UNKNOWN<< 41.73.3.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:13 /10:36 /11:101 /12:267 /13:512 /14:1028 /15:1759 /16:12962 /17:7554 /18:12732 /19:25789 /20:38145 /21:40033 /22:65050 /23:56554 /24:324329 /25:552 /26:593 /27:410 /28:45 /29:32 /30:14 /31:1 /32:30 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 39891 2664 2708 SaudiNet, Saudi Telecom Compa 22773 2525 3345 Cox Communications Inc. 18566 2111 2209 MegaPath Corporation 30036 1551 1737 Mediacom Communications Corp 6389 1499 2357 BellSouth.net Inc. 6983 1340 1691 EarthLink, Inc. 10620 1333 3448 Telmex Colombia S.A. 34984 1247 1962 TELLCOM ILETISIM HIZMETLERI A 11492 1175 1270 CABLE ONE, INC. 6849 976 1158 JSC "Ukrtelecom" Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1650 2:740 4:20 5:2030 6:28 8:941 12:1781 13:38 14:1661 15:45 16:2 17:75 18:20 20:48 23:1443 24:1804 27:2256 31:1757 32:54 33:2 34:2 35:5 36:257 37:2258 38:1184 39:24 40:87 41:2811 42:387 43:1694 44:41 45:1775 46:2469 47:72 49:1132 50:841 51:8 52:143 54:198 55:3 56:6 57:45 58:1535 59:868 60:569 61:1821 62:1475 63:1915 64:4466 65:2164 66:4330 67:2163 68:1102 69:3272 70:1048 71:470 72:1982 74:2550 75:340 76:413 77:1329 78:1267 79:843 80:1333 81:1358 82:938 83:684 84:803 85:1593 86:469 87:1015 88:561 89:1947 90:168 91:6048 92:859 93:2315 94:2316 95:2311 96:465 97:357 98:955 99:45 100:70 101:1024 103:10210 104:2263 105:153 106:392 107:1085 108:668 109:2125 110:1248 111:1649 112:958 113:1138 114:1036 115:1697 116:1542 117:1420 118:2139 119:1576 120:518 121:1169 122:2221 123:2004 124:1616 125:1756 128:716 129:380 130:411 131:1306 132:625 133:174 134:448 135:123 136:370 137:332 138:1717 139:224 140:250 141:466 142:640 143:877 144:605 145:162 146:850 147:678 148:1461 149:494 150:654 151:766 152:606 153:275 154:587 155:947 156:491 157:473 158:345 159:1099 160:459 161:742 162:2304 163:547 164:750 165:1038 166:314 167:1104 168:1689 169:632 170:1581 171:265 172:530 173:1676 174:723 175:903 176:1672 177:4044 178:2239 179:1126 180:2063 181:1710 182:1924 183:677 184:790 185:6077 186:3051 187:2082 188:2149 189:1741 190:7655 191:1224 192:8935 193:5729 194:4363 195:3767 196:1704 197:1130 198:5517 199:5639 200:6961 201:3708 202:10113 203:9627 204:4643 205:2687 206:2986 207:3074 208:4064 209:3788 210:3948 211:2039 212:2636 213:2188 214:832 215:72 216:5746 217:1932 218:764 219:566 220:1681 221:857 222:663 223:961 End of report From jra at baylink.com Fri Apr 1 20:42:59 2016 From: jra at baylink.com (Jay R. Ashworth) Date: Fri, 1 Apr 2016 20:42:59 +0000 (UTC) Subject: Fri AM AT&T outage Message-ID: <1523766140.10033.1459543379974.JavaMail.zimbra@baylink.com> I heard speculation from many quarters that this may have been related to the Verizon splashcut to Frontier -- which, regardless of what Frontier was telling us, I was pretty sure would be more than just varying which light switch for a building sign was the one turned on. Has anyone heard anything they're allowed to repeat, yet, which confirms or denies? On a related[1] topic: I see on Craigs that Frontier is hiring through a sub for transport staff for their new NOC, which I think is going to be located in SPBGFLXA89H; that building has about 3 completely empty floors, and has for over 20 years. (OK, it did when I toured it in 91; dunno what's there now. :-) Cheers, -- jra [1]maybe -- 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 dhubbard at dino.hostasaurus.com Fri Apr 1 20:56:25 2016 From: dhubbard at dino.hostasaurus.com (David Hubbard) Date: Fri, 1 Apr 2016 20:56:25 +0000 Subject: Fri AM AT&T outage In-Reply-To: <1523766140.10033.1459543379974.JavaMail.zimbra@baylink.com> References: <1523766140.10033.1459543379974.JavaMail.zimbra@baylink.com> Message-ID: <28D6E1A2-201D-4132-83E3-C22C088D1F75@dino.hostasaurus.com> Hopefully the job posting includes replacing this guy: http://www.tampabay.com/news/business/frontier-communications-pledges-smooth-take-over-of-verizon-fios-and-land/2271256 ---- "I would never say we're 100 percent certain it will go perfectly," Mike Flynn, Frontier's regional president overseeing operations in Florida and the Carolinas. "But we're doing everything we can within our power ? from the experience we've gleaned from every conversion we have done to make the next one better. So I'd just say we're pretty experienced at it." He said customers may experience brief service interruptions in the early morning hours Friday, though the company is not expecting that to affect a significant numbers of customers. ---- Our Tampa office has been offline for nine hours and Frontier support is saying not to worry, it should be resolved in the next four days. David On 4/1/16, 4:42 PM, "NANOG on behalf of Jay R. Ashworth" wrote: >I heard speculation from many quarters that this may have been related to >the Verizon splashcut to Frontier -- which, regardless of what Frontier >was telling us, I was pretty sure would be more than just varying which light >switch for a building sign was the one turned on. > >Has anyone heard anything they're allowed to repeat, yet, which confirms >or denies? > >On a related[1] topic: I see on Craigs that Frontier is hiring through a sub >for transport staff for their new NOC, which I think is going to be located >in SPBGFLXA89H; that building has about 3 completely empty floors, and has >for over 20 years. (OK, it did when I toured it in 91; dunno what's there >now. :-) > >Cheers, >-- jra >[1]maybe > >-- >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 jamesl at mythostech.com Fri Apr 1 21:18:11 2016 From: jamesl at mythostech.com (James Laszko) Date: Fri, 1 Apr 2016 21:18:11 +0000 Subject: Fri AM AT&T outage In-Reply-To: <1523766140.10033.1459543379974.JavaMail.zimbra@baylink.com> References: <1523766140.10033.1459543379974.JavaMail.zimbra@baylink.com> Message-ID: <8078ED370ADA824281219A7B5BADC39B6DF70FE5@MBX023-W1-CA-4.exch023.domain.local> I just saw that some of our AT&T tickets were updated as "Frontier is experiencing an outage in Oxnard, CA" James -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Jay R. Ashworth Sent: Friday, April 01, 2016 13:43 To: North American Network Operators' Group Subject: Fri AM AT&T outage I heard speculation from many quarters that this may have been related to the Verizon splashcut to Frontier -- which, regardless of what Frontier was telling us, I was pretty sure would be more than just varying which light switch for a building sign was the one turned on. Has anyone heard anything they're allowed to repeat, yet, which confirms or denies? On a related[1] topic: I see on Craigs that Frontier is hiring through a sub for transport staff for their new NOC, which I think is going to be located in SPBGFLXA89H; that building has about 3 completely empty floors, and has for over 20 years. (OK, it did when I toured it in 91; dunno what's there now. :-) Cheers, -- jra [1]maybe -- 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 mel at beckman.org Fri Apr 1 21:25:03 2016 From: mel at beckman.org (Mel Beckman) Date: Fri, 1 Apr 2016 21:25:03 +0000 Subject: Fri AM AT&T outage In-Reply-To: <8078ED370ADA824281219A7B5BADC39B6DF70FE5@MBX023-W1-CA-4.exch023.domain.local> References: <1523766140.10033.1459543379974.JavaMail.zimbra@baylink.com> <8078ED370ADA824281219A7B5BADC39B6DF70FE5@MBX023-W1-CA-4.exch023.domain.local> Message-ID: <02731238-97F3-438D-B7FE-6AE12EEFF705@beckman.org> Was this in SoCal? I had 40% packet loss Friday midnight to 11am on my FIOS sites. -mel beckman > On Apr 1, 2016, at 2:18 PM, James Laszko wrote: > > I just saw that some of our AT&T tickets were updated as "Frontier is experiencing an outage in Oxnard, CA" > > > James > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Jay R. Ashworth > Sent: Friday, April 01, 2016 13:43 > To: North American Network Operators' Group > Subject: Fri AM AT&T outage > > I heard speculation from many quarters that this may have been related to the Verizon splashcut to Frontier -- which, regardless of what Frontier was telling us, I was pretty sure would be more than just varying which light switch for a building sign was the one turned on. > > Has anyone heard anything they're allowed to repeat, yet, which confirms or denies? > > On a related[1] topic: I see on Craigs that Frontier is hiring through a sub for transport staff for their new NOC, which I think is going to be located in SPBGFLXA89H; that building has about 3 completely empty floors, and has for over 20 years. (OK, it did when I toured it in 91; dunno what's there now. :-) > > Cheers, > -- jra > [1]maybe > > -- > 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 jamesl at mythostech.com Fri Apr 1 21:27:12 2016 From: jamesl at mythostech.com (James Laszko) Date: Fri, 1 Apr 2016 21:27:12 +0000 Subject: Fri AM AT&T outage In-Reply-To: <02731238-97F3-438D-B7FE-6AE12EEFF705@beckman.org> References: <1523766140.10033.1459543379974.JavaMail.zimbra@baylink.com> <8078ED370ADA824281219A7B5BADC39B6DF70FE5@MBX023-W1-CA-4.exch023.domain.local> <02731238-97F3-438D-B7FE-6AE12EEFF705@beckman.org> Message-ID: <8078ED370ADA824281219A7B5BADC39B6DF712A9@MBX023-W1-CA-4.exch023.domain.local> Yes, LAX south is where we were seeing problems. FIOS routing issues galore, even having issues getting some IPSEC tunnels to come to life after 4am. Biggest issues we had were the AT&T MIS and MIS PNT BGP sessions all went bye-bye for about 3 hours. James -----Original Message----- From: Mel Beckman [mailto:mel at beckman.org] Sent: Friday, April 01, 2016 14:25 To: James Laszko Cc: North American Network Operators' Group Subject: Re: Fri AM AT&T outage Was this in SoCal? I had 40% packet loss Friday midnight to 11am on my FIOS sites. -mel beckman From volists at staff.velocityonline.net Fri Apr 1 22:31:16 2016 From: volists at staff.velocityonline.net (Velocity Lists) Date: Fri, 1 Apr 2016 18:31:16 -0400 Subject: PlayStation Network blocking an IP Message-ID: Can someone form Sony's Playstation network give me call or contact me offlist. One of our apartment complexes has been reporting errors of PS4s not working for a few days then they start working again. PSN Support is telling the users to call us. We have diagnosed it and PSN is blocking the IP of the complex and it has nothing to do with us. Velocity Online Rodger Lewis rclewis at velocityonline.net 850-205-4638 x201 From tony at wicks.co.nz Fri Apr 1 23:01:08 2016 From: tony at wicks.co.nz (Tony Wicks) Date: Sat, 2 Apr 2016 12:01:08 +1300 Subject: PlayStation Network blocking an IP In-Reply-To: References: Message-ID: <003e01d18c6a$61873d10$2495b730$@wicks.co.nz> Good luck with that! Sorry, long experience with them tells me that you are unlikely to get any help on that one. -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Velocity Lists Sent: Saturday, 2 April 2016 11:31 AM To: NANOG list Subject: PlayStation Network blocking an IP Can someone form Sony's Playstation network give me call or contact me offlist. One of our apartment complexes has been reporting errors of PS4s not working for a few days then they start working again. PSN Support is telling the users to call us. We have diagnosed it and PSN is blocking the IP of the complex and it has nothing to do with us. Velocity Online Rodger Lewis rclewis at velocityonline.net 850-205-4638 x201 From math at sizone.org Fri Apr 1 23:12:21 2016 From: math at sizone.org (Ken Chase) Date: Fri, 1 Apr 2016 19:12:21 -0400 Subject: PlayStation Network blocking an IP In-Reply-To: <003e01d18c6a$61873d10$2495b730$@wicks.co.nz> References: <003e01d18c6a$61873d10$2495b730$@wicks.co.nz> Message-ID: <20160401231221.GO1466@sizone.org> No kidding, just like how every order on newegg of mine will always be cancelled after the order is placed because of "problems with your order" if I do it from my DSL provider's ip block. /kc -- Ken Chase - math at sizone.org On Sat, Apr 02, 2016 at 12:01:08PM +1300, Tony Wicks said: >Good luck with that! Sorry, long experience with them tells me that you are unlikely to get any help on that one. > >-----Original Message----- >From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Velocity Lists >Sent: Saturday, 2 April 2016 11:31 AM >To: NANOG list >Subject: PlayStation Network blocking an IP > >Can someone form Sony's Playstation network give me call or contact me offlist. > >One of our apartment complexes has been reporting errors of PS4s not working for a few days then they start working again. > >PSN Support is telling the users to call us. >We have diagnosed it and PSN is blocking the IP of the complex and it has nothing to do with us. > > >Velocity Online >Rodger Lewis rclewis at velocityonline.net >850-205-4638 x201 > From benno at NLnetLabs.nl Sat Apr 2 03:33:49 2016 From: benno at NLnetLabs.nl (Benno Overeinder) Date: Sat, 2 Apr 2016 00:33:49 -0300 Subject: Last call for presentations and Draft programme for RIPE 72 Message-ID: <72497a80-49a4-609e-9ee4-41d01bf631a2@NLnetLabs.nl> Colleagues, A list of currently accepted RIPE 72 presentations is now published at: https://ripe72.ripe.net/programme/meeting-plan/draft-programme/ There are still few slots remaining for a final RIPE 72 programme and RIPE Programme Committee will accept new proposals until 15 April 2016. This is our last call for you to submit your proposals. You can find the CFP for RIPE 72 below, or at https://ripe72.ripe.net/submit-topic/cfp/, for your proposals for plenary session presentations, tutorials, workshops, BoFs (Birds of a Feather sessions) and lightning talks. Please also note that speakers do not receive any extra reduction or funding towards the meeting fee at the RIPE Meetings. Kind regards, Benno Overeinder RIPE PC Chair https://www.ripe.net/participate/meetings/ripe-meetings/pc -------------------->>><<<-------------------- Call for Presentations A RIPE Meeting is an open event where Internet Service Providers, network operators and other interested parties get together. Although the meeting is mostly technical, it is also a chance for people to meet and network with others in their field. RIPE 72 will take place from 23-27 May 2016 in Copenhagen, Denmark. The RIPE Programme Committee (PC) is now seeking content proposals from the RIPE community for the plenary sessions, BoFs (Birds of a Feather sessions), panels, workshops, tutorials and lightning talks at RIPE 72. See the full descriptions of the different presentation formats, https://ripe72.ripe.net/submit-topic/presentation-formats/. Proposals for plenary sessions, BoFs, panels, workshops and tutorials must be submitted for full consideration no later than 15 April 2016. Proposals submitted after this date will be considered depending on the remaining available space in the programme. The PC is looking for presentations covering topics of network engineering and operations, including but not limited to: - IPv6 deployment - Managing IPv4 scarcity in operations - Commercial transactions of IPv4 addresses - Data centre technologies - Network and DNS operations - Internet governance and regulatory practices - Network and routing security - Content delivery - Internet peering and mobile data exchange Submissions RIPE Meeting attendees are quite sensitive to keeping presentations non-commercial, and product marketing talks are strongly discouraged. Repeated audience feedback shows that the most successful talks focus on operational experience, research results, or case studies. For example, presenters wishing to describe a commercial solution should focus on the underlying technology and not attempt a product demonstration. Presenters should indicate how much time they will require. In general, the time allocated for the different presentation formats is as follows: - Plenary presentations: 20-25 minutes presentation with 5-10 minutes discussion - Tutorials: up to two hours (Monday morning) - Workshops: one hour (during evening sessions) to two hours (Monday morning) - BoFs: approximately one hour - Lightning talks: 10 minutes The following general requirements apply: - Proposals must be submitted using the meeting submission system, https://ripe72.ripe.net/submit-topic/submission-form/. - Lightning talks should also be submitted using the meeting submission system (https://ripe72.ripe.net/submit-topic/submission-form/) and can be submitted any time up to and including the meeting week. The allocation of lightning talks will be announced on short notice---in some cases on the same day but often one day prior to the time slot allocated. - Presenters who propose a panel or BoF are encouraged to include speakers from several (perhaps even competing) companies and/or a neutral facilitator. - All presentation proposals will only be considered by the PC if they contain at least draft presentation slides (slides may be updated later on). For panels, proposals must contain a clear description, as well as the names of invited panellists, presenters and moderators. - Due to potential technical issues, presenters/panellists should be physically present at the RIPE Meeting. If you have any questions or requests concerning content submissions, please email pc [at] ripe [dot] net. -- Benno J. Overeinder NLnet Labs http://www.nlnetlabs.nl/ From ecrogers at precisionds.com Sat Apr 2 17:54:40 2016 From: ecrogers at precisionds.com (Eric Rogers) Date: Sat, 2 Apr 2016 13:54:40 -0400 Subject: Someone Please Help Me Understand Message-ID: Ok, I'm trying to learn, so bear with me. We are an ISP in Indianapolis that has full routes from 3 different providers HE.Net in Columbus OH being one. We also are peered with 2 peering exchanges, including EquinixIX in Chicago. The problem is Instagram and Facebook (same company, I know) for our customers seems very slow. This is where I need a way to troubleshoot/understand more. I did a traceroute to the IP that is serving the pictures, and it resolves to the FBCDN servers in Dallas, and is showing packet loss and pings once it hits Dallas, and are in the 1xxs of ms. Tracing route to instagram-p3-shv-01-dfw1.fbcdn.net [31.13.66.52] over a maximum of 30 hops: 1 4 ms 3 ms 4 ms 10.7.0.1 2 20 ms 43 ms 42 ms inmtvlobs-rtr-01.dynamic.pdsconnect.me [192.69.57.1] 3 25 ms 47 ms 29 ms inmtvlmwt-rtr-01.infrastructure.pdsconnect.me [192.69.48.162] 4 46 ms 32 ms 58 ms inindyhen-core1.infrastructure.pdsconnect.me [192.69.48.193] 5 36 ms 53 ms 51 ms ge2-4.core1.cmh1.he.net [184.105.32.1] 6 47 ms 41 ms 75 ms 10ge1-2.core1.chi1.he.net [184.105.222.165] 7 57 ms 57 ms 53 ms 100ge14-1.core2.chi1.he.net [184.105.81.97] 8 57 ms 73 ms 84 ms 100ge12-1.core1.mci3.he.net [184.105.81.209] 9 75 ms 73 ms 102 ms 10ge15-6.core1.dal1.he.net [184.105.222.10] 10 93 ms 103 ms 92 ms eqix-da1.facebook.com [206.223.118.176] 11 102 ms 101 ms * psw01c.dfw1.tfbnw.net [173.252.65.196] 12 92 ms 97 ms 105 ms msw1aq.01.dfw1.tfbnw.net [204.15.21.89] 13 110 ms * 98 ms instagram-p3-shv-01-dfw1.fbcdn.net [31.13.66.52] Since I am peered with the route servers in EquinixIX Chicago, shouldn't the data be coming from there, or at least hit their routers? In my trace, it shows HE to Chicago, then to Dallas. How does FB decide what IP the content gets displayed from, and is there anything I can do as a provider? If it is DNS, I can obviously clear the cache to see if it gets new IPs. If I'm not getting FB peering IPs in Chicago, do I need to peer directly? Should I get FaceBook involved? Eric Rogers PDS Connect (317) 831-3000 x200 From nanog at ics-il.net Sat Apr 2 18:01:04 2016 From: nanog at ics-il.net (Mike Hammett) Date: Sat, 2 Apr 2016 13:01:04 -0500 (CDT) Subject: Someone Please Help Me Understand In-Reply-To: Message-ID: <404758666.1088.1459620060866.JavaMail.mhammett@ThunderFuck> Are you using locally resolving DNS servers? I don't know how FB determines where your content comes from, but some CDNs test the performance to your resolving DNS server. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest Internet Exchange http://www.midwest-ix.com ----- Original Message ----- From: "Eric Rogers" To: nanog at nanog.org Sent: Saturday, April 2, 2016 12:54:40 PM Subject: Someone Please Help Me Understand Ok, I'm trying to learn, so bear with me. We are an ISP in Indianapolis that has full routes from 3 different providers HE.Net in Columbus OH being one. We also are peered with 2 peering exchanges, including EquinixIX in Chicago. The problem is Instagram and Facebook (same company, I know) for our customers seems very slow. This is where I need a way to troubleshoot/understand more. I did a traceroute to the IP that is serving the pictures, and it resolves to the FBCDN servers in Dallas, and is showing packet loss and pings once it hits Dallas, and are in the 1xxs of ms. Tracing route to instagram-p3-shv-01-dfw1.fbcdn.net [31.13.66.52] over a maximum of 30 hops: 1 4 ms 3 ms 4 ms 10.7.0.1 2 20 ms 43 ms 42 ms inmtvlobs-rtr-01.dynamic.pdsconnect.me [192.69.57.1] 3 25 ms 47 ms 29 ms inmtvlmwt-rtr-01.infrastructure.pdsconnect.me [192.69.48.162] 4 46 ms 32 ms 58 ms inindyhen-core1.infrastructure.pdsconnect.me [192.69.48.193] 5 36 ms 53 ms 51 ms ge2-4.core1.cmh1.he.net [184.105.32.1] 6 47 ms 41 ms 75 ms 10ge1-2.core1.chi1.he.net [184.105.222.165] 7 57 ms 57 ms 53 ms 100ge14-1.core2.chi1.he.net [184.105.81.97] 8 57 ms 73 ms 84 ms 100ge12-1.core1.mci3.he.net [184.105.81.209] 9 75 ms 73 ms 102 ms 10ge15-6.core1.dal1.he.net [184.105.222.10] 10 93 ms 103 ms 92 ms eqix-da1.facebook.com [206.223.118.176] 11 102 ms 101 ms * psw01c.dfw1.tfbnw.net [173.252.65.196] 12 92 ms 97 ms 105 ms msw1aq.01.dfw1.tfbnw.net [204.15.21.89] 13 110 ms * 98 ms instagram-p3-shv-01-dfw1.fbcdn.net [31.13.66.52] Since I am peered with the route servers in EquinixIX Chicago, shouldn't the data be coming from there, or at least hit their routers? In my trace, it shows HE to Chicago, then to Dallas. How does FB decide what IP the content gets displayed from, and is there anything I can do as a provider? If it is DNS, I can obviously clear the cache to see if it gets new IPs. If I'm not getting FB peering IPs in Chicago, do I need to peer directly? Should I get FaceBook involved? Eric Rogers PDS Connect (317) 831-3000 x200 From ecrogers at precisionds.com Sat Apr 2 18:52:22 2016 From: ecrogers at precisionds.com (Eric Rogers) Date: Sat, 2 Apr 2016 14:52:22 -0400 Subject: Someone Please Help Me Understand References: <404758666.1088.1459620060866.JavaMail.mhammett@ThunderFuck> Message-ID: Yes, we have our own Bind9 caching servers in different geographic locations, direct on fiber using SSD drives... Seem very quick when using GRC's DNS Benchmark tests. Eric Rogers PDS Connect (317) 831-3000 x200 -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Mike Hammett Sent: Saturday, April 2, 2016 2:01 PM Cc: nanog at nanog.org Subject: Re: Someone Please Help Me Understand Are you using locally resolving DNS servers? I don't know how FB determines where your content comes from, but some CDNs test the performance to your resolving DNS server. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest Internet Exchange http://www.midwest-ix.com ----- Original Message ----- From: "Eric Rogers" To: nanog at nanog.org Sent: Saturday, April 2, 2016 12:54:40 PM Subject: Someone Please Help Me Understand Ok, I'm trying to learn, so bear with me. We are an ISP in Indianapolis that has full routes from 3 different providers HE.Net in Columbus OH being one. We also are peered with 2 peering exchanges, including EquinixIX in Chicago. The problem is Instagram and Facebook (same company, I know) for our customers seems very slow. This is where I need a way to troubleshoot/understand more. I did a traceroute to the IP that is serving the pictures, and it resolves to the FBCDN servers in Dallas, and is showing packet loss and pings once it hits Dallas, and are in the 1xxs of ms. Tracing route to instagram-p3-shv-01-dfw1.fbcdn.net [31.13.66.52] over a maximum of 30 hops: 1 4 ms 3 ms 4 ms 10.7.0.1 2 20 ms 43 ms 42 ms inmtvlobs-rtr-01.dynamic.pdsconnect.me [192.69.57.1] 3 25 ms 47 ms 29 ms inmtvlmwt-rtr-01.infrastructure.pdsconnect.me [192.69.48.162] 4 46 ms 32 ms 58 ms inindyhen-core1.infrastructure.pdsconnect.me [192.69.48.193] 5 36 ms 53 ms 51 ms ge2-4.core1.cmh1.he.net [184.105.32.1] 6 47 ms 41 ms 75 ms 10ge1-2.core1.chi1.he.net [184.105.222.165] 7 57 ms 57 ms 53 ms 100ge14-1.core2.chi1.he.net [184.105.81.97] 8 57 ms 73 ms 84 ms 100ge12-1.core1.mci3.he.net [184.105.81.209] 9 75 ms 73 ms 102 ms 10ge15-6.core1.dal1.he.net [184.105.222.10] 10 93 ms 103 ms 92 ms eqix-da1.facebook.com [206.223.118.176] 11 102 ms 101 ms * psw01c.dfw1.tfbnw.net [173.252.65.196] 12 92 ms 97 ms 105 ms msw1aq.01.dfw1.tfbnw.net [204.15.21.89] 13 110 ms * 98 ms instagram-p3-shv-01-dfw1.fbcdn.net [31.13.66.52] Since I am peered with the route servers in EquinixIX Chicago, shouldn't the data be coming from there, or at least hit their routers? In my trace, it shows HE to Chicago, then to Dallas. How does FB decide what IP the content gets displayed from, and is there anything I can do as a provider? If it is DNS, I can obviously clear the cache to see if it gets new IPs. If I'm not getting FB peering IPs in Chicago, do I need to peer directly? Should I get FaceBook involved? Eric Rogers PDS Connect (317) 831-3000 x200 From nanog at ics-il.net Sat Apr 2 19:55:24 2016 From: nanog at ics-il.net (Mike Hammett) Date: Sat, 2 Apr 2016 14:55:24 -0500 (CDT) Subject: Someone Please Help Me Understand In-Reply-To: Message-ID: <1257425835.1214.1459626923934.JavaMail.mhammett@ThunderFuck> Well, what I meant by that (which wouldn't be the problem if you have them on-net), is that they'll do performance tests to your resolving DNS server to determine which node is the best node to serve you from. Well, they meaning other CDNs. I don't know how FB determines it. Are you seeing any routes to 32934 from your Chicago Equinix connection? ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest Internet Exchange http://www.midwest-ix.com ----- Original Message ----- From: "Eric Rogers" To: "Mike Hammett" Cc: nanog at nanog.org Sent: Saturday, April 2, 2016 1:52:22 PM Subject: RE: Someone Please Help Me Understand Yes, we have our own Bind9 caching servers in different geographic locations, direct on fiber using SSD drives... Seem very quick when using GRC's DNS Benchmark tests. Eric Rogers PDS Connect (317) 831-3000 x200 -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Mike Hammett Sent: Saturday, April 2, 2016 2:01 PM Cc: nanog at nanog.org Subject: Re: Someone Please Help Me Understand Are you using locally resolving DNS servers? I don't know how FB determines where your content comes from, but some CDNs test the performance to your resolving DNS server. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest Internet Exchange http://www.midwest-ix.com ----- Original Message ----- From: "Eric Rogers" To: nanog at nanog.org Sent: Saturday, April 2, 2016 12:54:40 PM Subject: Someone Please Help Me Understand Ok, I'm trying to learn, so bear with me. We are an ISP in Indianapolis that has full routes from 3 different providers HE.Net in Columbus OH being one. We also are peered with 2 peering exchanges, including EquinixIX in Chicago. The problem is Instagram and Facebook (same company, I know) for our customers seems very slow. This is where I need a way to troubleshoot/understand more. I did a traceroute to the IP that is serving the pictures, and it resolves to the FBCDN servers in Dallas, and is showing packet loss and pings once it hits Dallas, and are in the 1xxs of ms. Tracing route to instagram-p3-shv-01-dfw1.fbcdn.net [31.13.66.52] over a maximum of 30 hops: 1 4 ms 3 ms 4 ms 10.7.0.1 2 20 ms 43 ms 42 ms inmtvlobs-rtr-01.dynamic.pdsconnect.me [192.69.57.1] 3 25 ms 47 ms 29 ms inmtvlmwt-rtr-01.infrastructure.pdsconnect.me [192.69.48.162] 4 46 ms 32 ms 58 ms inindyhen-core1.infrastructure.pdsconnect.me [192.69.48.193] 5 36 ms 53 ms 51 ms ge2-4.core1.cmh1.he.net [184.105.32.1] 6 47 ms 41 ms 75 ms 10ge1-2.core1.chi1.he.net [184.105.222.165] 7 57 ms 57 ms 53 ms 100ge14-1.core2.chi1.he.net [184.105.81.97] 8 57 ms 73 ms 84 ms 100ge12-1.core1.mci3.he.net [184.105.81.209] 9 75 ms 73 ms 102 ms 10ge15-6.core1.dal1.he.net [184.105.222.10] 10 93 ms 103 ms 92 ms eqix-da1.facebook.com [206.223.118.176] 11 102 ms 101 ms * psw01c.dfw1.tfbnw.net [173.252.65.196] 12 92 ms 97 ms 105 ms msw1aq.01.dfw1.tfbnw.net [204.15.21.89] 13 110 ms * 98 ms instagram-p3-shv-01-dfw1.fbcdn.net [31.13.66.52] Since I am peered with the route servers in EquinixIX Chicago, shouldn't the data be coming from there, or at least hit their routers? In my trace, it shows HE to Chicago, then to Dallas. How does FB decide what IP the content gets displayed from, and is there anything I can do as a provider? If it is DNS, I can obviously clear the cache to see if it gets new IPs. If I'm not getting FB peering IPs in Chicago, do I need to peer directly? Should I get FaceBook involved? Eric Rogers PDS Connect (317) 831-3000 x200 From nanog at ics-il.net Sat Apr 2 20:12:35 2016 From: nanog at ics-il.net (Mike Hammett) Date: Sat, 2 Apr 2016 15:12:35 -0500 (CDT) Subject: Someone Please Help Me Understand In-Reply-To: <1257425835.1214.1459626923934.JavaMail.mhammett@ThunderFuck> Message-ID: <1710090099.1240.1459627953383.JavaMail.mhammett@ThunderFuck> By performance testing, it varies, but latency is a big one. Again, doesn't seem to be your problem in your case. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest Internet Exchange http://www.midwest-ix.com ----- Original Message ----- From: "Mike Hammett" Cc: nanog at nanog.org Sent: Saturday, April 2, 2016 2:55:24 PM Subject: Re: Someone Please Help Me Understand Well, what I meant by that (which wouldn't be the problem if you have them on-net), is that they'll do performance tests to your resolving DNS server to determine which node is the best node to serve you from. Well, they meaning other CDNs. I don't know how FB determines it. Are you seeing any routes to 32934 from your Chicago Equinix connection? ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest Internet Exchange http://www.midwest-ix.com ----- Original Message ----- From: "Eric Rogers" To: "Mike Hammett" Cc: nanog at nanog.org Sent: Saturday, April 2, 2016 1:52:22 PM Subject: RE: Someone Please Help Me Understand Yes, we have our own Bind9 caching servers in different geographic locations, direct on fiber using SSD drives... Seem very quick when using GRC's DNS Benchmark tests. Eric Rogers PDS Connect (317) 831-3000 x200 -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Mike Hammett Sent: Saturday, April 2, 2016 2:01 PM Cc: nanog at nanog.org Subject: Re: Someone Please Help Me Understand Are you using locally resolving DNS servers? I don't know how FB determines where your content comes from, but some CDNs test the performance to your resolving DNS server. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest Internet Exchange http://www.midwest-ix.com ----- Original Message ----- From: "Eric Rogers" To: nanog at nanog.org Sent: Saturday, April 2, 2016 12:54:40 PM Subject: Someone Please Help Me Understand Ok, I'm trying to learn, so bear with me. We are an ISP in Indianapolis that has full routes from 3 different providers HE.Net in Columbus OH being one. We also are peered with 2 peering exchanges, including EquinixIX in Chicago. The problem is Instagram and Facebook (same company, I know) for our customers seems very slow. This is where I need a way to troubleshoot/understand more. I did a traceroute to the IP that is serving the pictures, and it resolves to the FBCDN servers in Dallas, and is showing packet loss and pings once it hits Dallas, and are in the 1xxs of ms. Tracing route to instagram-p3-shv-01-dfw1.fbcdn.net [31.13.66.52] over a maximum of 30 hops: 1 4 ms 3 ms 4 ms 10.7.0.1 2 20 ms 43 ms 42 ms inmtvlobs-rtr-01.dynamic.pdsconnect.me [192.69.57.1] 3 25 ms 47 ms 29 ms inmtvlmwt-rtr-01.infrastructure.pdsconnect.me [192.69.48.162] 4 46 ms 32 ms 58 ms inindyhen-core1.infrastructure.pdsconnect.me [192.69.48.193] 5 36 ms 53 ms 51 ms ge2-4.core1.cmh1.he.net [184.105.32.1] 6 47 ms 41 ms 75 ms 10ge1-2.core1.chi1.he.net [184.105.222.165] 7 57 ms 57 ms 53 ms 100ge14-1.core2.chi1.he.net [184.105.81.97] 8 57 ms 73 ms 84 ms 100ge12-1.core1.mci3.he.net [184.105.81.209] 9 75 ms 73 ms 102 ms 10ge15-6.core1.dal1.he.net [184.105.222.10] 10 93 ms 103 ms 92 ms eqix-da1.facebook.com [206.223.118.176] 11 102 ms 101 ms * psw01c.dfw1.tfbnw.net [173.252.65.196] 12 92 ms 97 ms 105 ms msw1aq.01.dfw1.tfbnw.net [204.15.21.89] 13 110 ms * 98 ms instagram-p3-shv-01-dfw1.fbcdn.net [31.13.66.52] Since I am peered with the route servers in EquinixIX Chicago, shouldn't the data be coming from there, or at least hit their routers? In my trace, it shows HE to Chicago, then to Dallas. How does FB decide what IP the content gets displayed from, and is there anything I can do as a provider? If it is DNS, I can obviously clear the cache to see if it gets new IPs. If I'm not getting FB peering IPs in Chicago, do I need to peer directly? Should I get FaceBook involved? Eric Rogers PDS Connect (317) 831-3000 x200 From jfmezei_nanog at vaxination.ca Sat Apr 2 21:03:56 2016 From: jfmezei_nanog at vaxination.ca (Jean-Francois Mezei) Date: Sat, 2 Apr 2016 17:03:56 -0400 Subject: Someone Please Help Me Understand In-Reply-To: References: Message-ID: <570033BC.9080308@vaxination.ca> On 2016-04-02 13:54, Eric Rogers wrote: > providers HE.Net in Columbus OH being one. We also are peered with 2 > peering exchanges, including EquinixIX in Chicago. The problem is > Instagram and Facebook (same company, I know) for our customers seems > very slow. Facebook does not open peer. https://www.facebook.com/peering/ https://www.peeringdb.com/asn/32934 So you need to get in touch with them to peer with them, assuming you meet their standard (50mbps of exchanges between you and them). So you need to establish a peering relationship before you can use it. And even if you peer, there is no garantee you get your "big" data from the nearest. You may get the HTML from the nearest but their "logic" may decide that your images or videos will be served from some other site because of how the decide this (database of DNS servers etc). (when they generate the html for your customers, they would include URLs that point to distant servers at which point no amount of peering will change that. You need to find out why the content provider's logic doesn't feed your customers URLs to the nearest CDN. From elouie at yahoo.com Fri Apr 1 18:02:56 2016 From: elouie at yahoo.com (Eric A Louie) Date: Fri, 1 Apr 2016 18:02:56 +0000 (UTC) Subject: What services does Microsoft AS8075 provide when peering at IXPs? References: <1563679100.953334.1459533776157.JavaMail.yahoo.ref@mail.yahoo.com> Message-ID: <1563679100.953334.1459533776157.JavaMail.yahoo@mail.yahoo.com> I had this question posed by a marketing type in my office.? Does anyone know the answer? Is it microsoft.com, msdn, outllook365, msn.com, outlook.com, azure, windows updates, xbox?? what else is possibly covered or omitted in their peering service?? I suppose we have a customer who is an Azure customer that wants to know if their Azure traffic will stay in our network or still go through the Internet. I've tried asking peering at microsoft.com twice, but it looks like they have their ignore filter up. Thanks, -e- From clowe at vertafore.com Fri Apr 1 21:28:46 2016 From: clowe at vertafore.com (Lowe,Chris) Date: Fri, 1 Apr 2016 21:28:46 +0000 Subject: Fri AM AT&T outage In-Reply-To: <02731238-97F3-438D-B7FE-6AE12EEFF705@beckman.org> References: <1523766140.10033.1459543379974.JavaMail.zimbra@baylink.com> <8078ED370ADA824281219A7B5BADC39B6DF70FE5@MBX023-W1-CA-4.exch023.domain.local> <02731238-97F3-438D-B7FE-6AE12EEFF705@beckman.org> Message-ID: When I talked to Frontier about our Office in Tampa, I was told there was a fiber cut that was effecting SoCal and Florida. Not sure how the 2 were related but that is what I was told. Our Tampa office has been down as well since 7:00am local time. -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Mel Beckman Sent: Friday, April 01, 2016 2:25 PM To: James Laszko Cc: North American Network Operators' Group Subject: Re: Fri AM AT&T outage Was this in SoCal? I had 40% packet loss Friday midnight to 11am on my FIOS sites. -mel beckman > On Apr 1, 2016, at 2:18 PM, James Laszko wrote: > > I just saw that some of our AT&T tickets were updated as "Frontier is experiencing an outage in Oxnard, CA" > > > James > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Jay R. Ashworth > Sent: Friday, April 01, 2016 13:43 > To: North American Network Operators' Group > Subject: Fri AM AT&T outage > > I heard speculation from many quarters that this may have been related to the Verizon splashcut to Frontier -- which, regardless of what Frontier was telling us, I was pretty sure would be more than just varying which light switch for a building sign was the one turned on. > > Has anyone heard anything they're allowed to repeat, yet, which confirms or denies? > > On a related[1] topic: I see on Craigs that Frontier is hiring through a sub for transport staff for their new NOC, which I think is going to be located in SPBGFLXA89H; that building has about 3 completely empty floors, and has for over 20 years. (OK, it did when I toured it in 91; dunno what's there now. :-) > > Cheers, > -- jra > [1]maybe > > -- > 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 nanog at namor.ca Fri Apr 1 23:37:21 2016 From: nanog at namor.ca (J) Date: Fri, 01 Apr 2016 18:37:21 -0500 Subject: PlayStation Network blocking an IP In-Reply-To: References: Message-ID: <153d43031a8.bc8d8e1c417.864588544876767257@namor.ca> I've been seeing abuse reports from Sony lately, indicating IPs are blacklisted on the Playstation Network, mainly for attempted account compromise. Indicating to check for traffic towards some endpoints, resolve the complaint else blacklist again, etc, etc. The address they direct inquiries to is snei-noc-abuse at am.sony.com - perhaps this is a reason and vector for your issue as well? ---- On Fri, 01 Apr 2016 17:31:16 -0500 Velocity Lists <volists at staff.velocityonline.net> wrote ---- Can someone form Sony's Playstation network give me call or contact me offlist. One of our apartment complexes has been reporting errors of PS4s not working for a few days then they start working again. PSN Support is telling the users to call us. We have diagnosed it and PSN is blocking the IP of the complex and it has nothing to do with us. Velocity Online Rodger Lewis rclewis at velocityonline.net 850-205-4638 x201 From sam.oduor at gmail.com Sun Apr 3 22:13:40 2016 From: sam.oduor at gmail.com (Sam Oduor) Date: Mon, 4 Apr 2016 01:13:40 +0300 Subject: Colocation Server Lifts In-Reply-To: References: Message-ID: Yes, I would expect a lift at a colo but in terms of regulations (safety) I do not think it is a mandatory requirement for most colo's Allowing customers to use them can be a yes or no ; it requires some basic operational skills to operate - you just cant trust a client visiting to use it unless some vetting is in place for this. It should be free and a datacentre operator needs to assist or at-least supervise in usage. The weight depends on the model of the lift . Some helpful resources:- https://www.youtube.com/watch?v=5uLWVMOfY0U http://www.serverlift.com/ On Tue, Mar 29, 2016 at 3:23 PM, Jason Lee wrote: > Hi NANOG community, > > A few questions I have for the community regarding server lifts at colo > facilities. > > 1. Is a server lift something you would typically expect a colo facility to > provide? > > if yes, > > 2. Do colo facilities typically allow customers to just use them or provide > an operator? > 3. Is it a free offering or something they rent out? > 4. What would be the typical device weight you would lift? > 5. What would be the max device weight you would lift? > > Thanks, > > Jason > -- Samson Oduor From mark.tinka at seacom.mu Sun Apr 3 22:17:28 2016 From: mark.tinka at seacom.mu (Mark Tinka) Date: Mon, 4 Apr 2016 00:17:28 +0200 Subject: Some doubts on large scale BGP/AS design and black hole routing risk In-Reply-To: References: Message-ID: On 31/Mar/16 10:12, magicboiz at hotmail.com wrote: > > > My questions are: > > 1. What could happen in the case of total failure in the redundant > leased lines? Black hole routing between POPs? If you have redundant backhaul that completely fails, you've got real problems. However, if that does happen, any traffic coming into each individual PoP destined for users in the other PoP will fail. Only traffic terminating for customers at that PoP will succeed. > > 2. What are the best design methods to avoid this scenario? Work on your backhaul. Originate specific routes that cover customers present in each PoP, with the aggregate as a backup route. You can run a tunnel across the Internet to simulate a backbone between both PoP's, using your side of your upstream's IP addresses as the tunnel end-point. Not elegant, but keeps you up. > > 2.1: adding a third POP creating a triangle? What if a POP looses > connection with the other two POPs at the same time? Another black hole? Your fixation on a complete backhaul outage is interesting. Purchase backhaul from different service providers to increase your chances of uptime. > > 2.2: requesting another prefix and allocating 1:1 prefix:POP, so in > the scenario each POP only would announce its prefix to the upstreams? See above re: originating more specific routes based on the customers you have at each PoP. > > 2.3: other? Work harder on your backhaul. Yes, bad things can happen, and they do happen. But more than likely, if a 3-PoP network loses all connectivity from each other, I think routing will be a much smaller problem to solve in the grand scheme of things. Mark. From Valdis.Kletnieks at vt.edu Sun Apr 3 23:04:14 2016 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Sun, 03 Apr 2016 19:04:14 -0400 Subject: What services does Microsoft AS8075 provide when peering at IXPs? In-Reply-To: <1563679100.953334.1459533776157.JavaMail.yahoo@mail.yahoo.com> References: <1563679100.953334.1459533776157.JavaMail.yahoo.ref@mail.yahoo.com> <1563679100.953334.1459533776157.JavaMail.yahoo@mail.yahoo.com> Message-ID: <171099.1459724654@turing-police.cc.vt.edu> On Fri, 01 Apr 2016 18:02:56 -0000, Eric A Louie via NANOG said: > I suppose we have a customer who is an Azure customer that wants to know if > their Azure traffic will stay in our network or still go through the Internet. As a practical matter, if they're using the answer for a security baseline, they're doing it wrong - they should be planning that based on the assumption that their traffic *will* ride the rails of the commodity Internet (due to outages or whatever). Similarly, if they're looking at it for performance/latency, they need to fix their assumptions - your direct peering can be slow and congested, while there's actually a longer but faster path through someplace else.... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From nanog at ics-il.net Sun Apr 3 23:17:17 2016 From: nanog at ics-il.net (Mike Hammett) Date: Sun, 3 Apr 2016 18:17:17 -0500 (CDT) Subject: What services does Microsoft AS8075 provide when peering at IXPs? In-Reply-To: <171099.1459724654@turing-police.cc.vt.edu> Message-ID: <1926737988.2150.1459725435388.JavaMail.mhammett@ThunderFuck> "your direct peering can be slow and congested, while there's actually a longer but faster path through someplace else...." Possible, but unlikely for most networks. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest Internet Exchange http://www.midwest-ix.com ----- Original Message ----- From: "Valdis Kletnieks" To: "Eric A Louie" Cc: "NANOG List" Sent: Sunday, April 3, 2016 6:04:14 PM Subject: Re: What services does Microsoft AS8075 provide when peering at IXPs? On Fri, 01 Apr 2016 18:02:56 -0000, Eric A Louie via NANOG said: > I suppose we have a customer who is an Azure customer that wants to know if > their Azure traffic will stay in our network or still go through the Internet. As a practical matter, if they're using the answer for a security baseline, they're doing it wrong - they should be planning that based on the assumption that their traffic *will* ride the rails of the commodity Internet (due to outages or whatever). Similarly, if they're looking at it for performance/latency, they need to fix their assumptions - your direct peering can be slow and congested, while there's actually a longer but faster path through someplace else.... From elouie at yahoo.com Mon Apr 4 00:22:05 2016 From: elouie at yahoo.com (Eric A Louie) Date: Mon, 4 Apr 2016 00:22:05 +0000 (UTC) Subject: What services does Microsoft AS8075 provide when peering at IXPs? In-Reply-To: <171099.1459724654@turing-police.cc.vt.edu> References: <171099.1459724654@turing-police.cc.vt.edu> Message-ID: <1062014476.1743791.1459729325708.JavaMail.yahoo@mail.yahoo.com> My direct peering is within my control, the traffic has to follow basically the same path internally to Internet and IXP.? Internet path is definitely variable.? IXP path is definitely fixed.? It's already there, just needed to know what Microsoft provided (if anyone knew).? Actually, a MS peering engineer answered the question for me privately. My marketing people aren't terribly concerned with security, that wasn't the issue.? The issue was shorter path/better performance.? I'm still not clear if it's public or private Azure that the customer is trying to access. On Sunday, April 3, 2016 4:04 PM, "Valdis.Kletnieks at vt.edu" wrote: On Fri, 01 Apr 2016 18:02:56 -0000, Eric A Louie via NANOG said: > I suppose we have a customer who is an Azure customer that wants to know if > their Azure traffic will stay in our network or still go through the Internet. As a practical matter, if they're using the answer for a security baseline, they're doing it wrong - they should be planning that based on the assumption that their traffic *will* ride the rails of the commodity Internet (due to outages or whatever). Similarly, if they're looking at it for performance/latency, they need to fix their assumptions - your direct peering can be slow and congested, while there's actually a longer but faster path through someplace else.... From faisal at snappytelecom.net Mon Apr 4 00:26:37 2016 From: faisal at snappytelecom.net (Faisal Imtiaz) Date: Mon, 4 Apr 2016 00:26:37 +0000 (GMT) Subject: Someone Please Help Me Understand In-Reply-To: References: Message-ID: <1616470662.13133.1459729597539.JavaMail.zimbra@snappytelecom.net> Hi Eric, With this type of connectivity you have to pay attention to Traffic Engineering... And when I say, traffic engineering, I mean both ways.. how you are sending traffic to them along with how they are sending traffic to you... (sometimes a bit more challenging to do). I will give you two specific example, just to illustrate the point... We are located in the east coast, we have ip transit to Cogent network, via one intermediary ASN. We also have IP Transit with GTT and Hibernia networks. We also have direct peering on multiple Peering Fabrics. 1st cases... We have our outbound traffic engineered to prefer direct routes.. e.g. when sending traffic to Cogent, we send it out via the intermediary ASN to Cogent. However when traffic is coming back from Cogent.... they see our prefixes via intermediary ASN as well as Hibernia Networks, since Hibernia networks is a lower ASN, they prefer that route.... So, one can say, no big deal, except, Hibernia Networks connects to Cogent on the West Coast !... so our return traffic is going from the east coast to west coast and them back to east coast.... So one can easily say... Houston we have a problem !... 2nd Case.. We are peered with some networks at Telx TIE, via one of our (intermediary) ASN...So while we can send traffic over to that network via our ASN, however that networks sees our prefixes via our (intermediary) ASN as Hibernia as well.... Hibernia being a lower ASN, they send traffic back to us via them... In both cases we use communities to take corrective action.... Moral of the story is..... just because you have multiple peers, and peer with folks on the Peering Fabric, the default configuration of BGP will not AUTOMAGICALY optimize the paths in your favor.... And thus the condition you describe will be the result... 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: "Eric Rogers" > To: "nanog list" > Sent: Saturday, April 2, 2016 1:54:40 PM > Subject: Someone Please Help Me Understand > Ok, I'm trying to learn, so bear with me. > > > > We are an ISP in Indianapolis that has full routes from 3 different > providers HE.Net in Columbus OH being one. We also are peered with 2 > peering exchanges, including EquinixIX in Chicago. The problem is > Instagram and Facebook (same company, I know) for our customers seems > very slow. > > > > This is where I need a way to troubleshoot/understand more. I did a > traceroute to the IP that is serving the pictures, and it resolves to > the FBCDN servers in Dallas, and is showing packet loss and pings once > it hits Dallas, and are in the 1xxs of ms. > > > > Tracing route to instagram-p3-shv-01-dfw1.fbcdn.net [31.13.66.52] > > over a maximum of 30 hops: > > > > 1 4 ms 3 ms 4 ms 10.7.0.1 > > 2 20 ms 43 ms 42 ms inmtvlobs-rtr-01.dynamic.pdsconnect.me > [192.69.57.1] > > 3 25 ms 47 ms 29 ms > inmtvlmwt-rtr-01.infrastructure.pdsconnect.me [192.69.48.162] > > 4 46 ms 32 ms 58 ms > inindyhen-core1.infrastructure.pdsconnect.me [192.69.48.193] > > 5 36 ms 53 ms 51 ms ge2-4.core1.cmh1.he.net [184.105.32.1] > > 6 47 ms 41 ms 75 ms 10ge1-2.core1.chi1.he.net > [184.105.222.165] > > 7 57 ms 57 ms 53 ms 100ge14-1.core2.chi1.he.net > [184.105.81.97] > > 8 57 ms 73 ms 84 ms 100ge12-1.core1.mci3.he.net > [184.105.81.209] > > 9 75 ms 73 ms 102 ms 10ge15-6.core1.dal1.he.net > [184.105.222.10] > > 10 93 ms 103 ms 92 ms eqix-da1.facebook.com [206.223.118.176] > > 11 102 ms 101 ms * psw01c.dfw1.tfbnw.net [173.252.65.196] > > 12 92 ms 97 ms 105 ms msw1aq.01.dfw1.tfbnw.net [204.15.21.89] > > 13 110 ms * 98 ms instagram-p3-shv-01-dfw1.fbcdn.net > [31.13.66.52] > > > > Since I am peered with the route servers in EquinixIX Chicago, shouldn't > the data be coming from there, or at least hit their routers? In my > trace, it shows HE to Chicago, then to Dallas. How does FB decide what > IP the content gets displayed from, and is there anything I can do as a > provider? If it is DNS, I can obviously clear the cache to see if it > gets new IPs. If I'm not getting FB peering IPs in Chicago, do I need > to peer directly? Should I get FaceBook involved? > > > > Eric Rogers > > PDS Connect > > (317) 831-3000 x200 From woody at pch.net Mon Apr 4 03:28:50 2016 From: woody at pch.net (Bill Woodcock) Date: Sun, 3 Apr 2016 20:28:50 -0700 Subject: Some doubts on large scale BGP/AS design and black hole routing risk In-Reply-To: References: Message-ID: <0411835C-0650-41E5-A6DF-BC42CB25AE71@pch.net> Are respondents to suppose that the customer base and address space are evenly divided between the two cities, and that the ISP is too clueless to originate each /23 from the city that uses it, in iBGP? -Bill > On Apr 3, 2016, at 15:04, "magicboiz at hotmail.com" wrote: > > Hi everybody! > > > as part of laboratory work at the university, I'm working on a BGP design study, and I would like to post some questions regarding IP address space allocation and its impact on BGP which are breaking my mind :) > > Let's suppose we have an ISP/AS with two POPs: PARIS and LONDON. These two POPs are connected with redundant leased lines. Each POP has a BGP router speaking eBGP to different ISP providers/upstreams and also, each POP run its own OSPF area/ISIS area. Something like this: > > > ---eBGP---===redundant leased lines (ospf area0)===---eBGP--- > > Now, this AS/ISP gets one /22 prefix from it RIR (RIPE in this case), and starts to announce it to its upstreams in PARIS and LONDON at the same time. > > > My questions are: > > 1. What could happen in the case of total failure in the redundant leased lines? Black hole routing between POPs? > > 2. What are the best design methods to avoid this scenario? > > 2.1: adding a third POP creating a triangle? What if a POP looses connection with the other two POPs at the same time? Another black hole? > > 2.2: requesting another prefix and allocating 1:1 prefix:POP, so in the scenario each POP only would announce its prefix to the upstreams? > > 2.3: other? > > > > Thanks in advance! > J. > From mark.tinka at seacom.mu Mon Apr 4 09:33:37 2016 From: mark.tinka at seacom.mu (Mark Tinka) Date: Mon, 4 Apr 2016 11:33:37 +0200 Subject: SAFNOG-3 Meeting - Date Change Updates Message-ID: Hello all. Due to an unfortunate set of circumstances, the SAFNOG-3 meeting dates have changed. Please visit the SAFNOG web site for details on this, at the URL below: http://safnog.org/ The SAFNOG-3 meeting is still going ahead as described on the web site. Detailed planning for the meeting is ongoing, and further updates will be communicated to the community in the coming weeks. You may also subscribe to the SAFNOG mailing list for regular updates at the URL below: http://lists.safnog.org/listinfo/safnog We look forward to seeing you all in Windhoek, later this year. For any questions, please send e-mail to: secretariat safnog org Cheers, Mark Tinka On Behalf of the SAFNOG Management Committee From ecrogers at precisionds.com Mon Apr 4 12:46:41 2016 From: ecrogers at precisionds.com (Eric Rogers) Date: Mon, 4 Apr 2016 08:46:41 -0400 Subject: Someone Please Help Me Understand References: <1616470662.13133.1459729597539.JavaMail.zimbra@snappytelecom.net> Message-ID: Thanks Faisal, I appreciate the time you took and the detail you have placed. I did try prepending our HE connection thinking it was an issue via HE, and we started going out Level3, and it also went to Dallas with nearly the same packet loss. I don't know what the return path is/was, but through another provider, it also showed major packet loss. That leads me to believe that FB is/was having issues in Dallas. Maybe on their peering port? I have since found out they don't peer through the route servers, but only directly through the exchanges (direct peering relationship). I have since submitted a peering request to FB and also submitted a request to their NOC to look at the packet loss and why we are getting Dallas IPs. I have not received a response to either. I can use the community strings to manipulate our announcement of our routes, but won't DNS tell the browser what IP to ultimately get the data? I am not trying to publically shame or air dirty laundry, I am just trying to understand the situation more. CDNs bring a whole new level I have yet to comprehend with multicast DNS and GeoIP responses... Eric Rogers PDS Connect www.pdsconnect.me (317) 831-3000 x200 -----Original Message----- From: Faisal Imtiaz [mailto:faisal at snappytelecom.net] Sent: Sunday, April 3, 2016 8:27 PM To: Eric Rogers Cc: nanog list Subject: Re: Someone Please Help Me Understand Hi Eric, With this type of connectivity you have to pay attention to Traffic Engineering... And when I say, traffic engineering, I mean both ways.. how you are sending traffic to them along with how they are sending traffic to you... (sometimes a bit more challenging to do). I will give you two specific example, just to illustrate the point... We are located in the east coast, we have ip transit to Cogent network, via one intermediary ASN. We also have IP Transit with GTT and Hibernia networks. We also have direct peering on multiple Peering Fabrics. 1st cases... We have our outbound traffic engineered to prefer direct routes.. e.g. when sending traffic to Cogent, we send it out via the intermediary ASN to Cogent. However when traffic is coming back from Cogent.... they see our prefixes via intermediary ASN as well as Hibernia Networks, since Hibernia networks is a lower ASN, they prefer that route.... So, one can say, no big deal, except, Hibernia Networks connects to Cogent on the West Coast !... so our return traffic is going from the east coast to west coast and them back to east coast.... So one can easily say... Houston we have a problem !... 2nd Case.. We are peered with some networks at Telx TIE, via one of our (intermediary) ASN...So while we can send traffic over to that network via our ASN, however that networks sees our prefixes via our (intermediary) ASN as Hibernia as well.... Hibernia being a lower ASN, they send traffic back to us via them... In both cases we use communities to take corrective action.... Moral of the story is..... just because you have multiple peers, and peer with folks on the Peering Fabric, the default configuration of BGP will not AUTOMAGICALY optimize the paths in your favor.... And thus the condition you describe will be the result... 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: "Eric Rogers" > To: "nanog list" > Sent: Saturday, April 2, 2016 1:54:40 PM > Subject: Someone Please Help Me Understand > Ok, I'm trying to learn, so bear with me. > > > > We are an ISP in Indianapolis that has full routes from 3 different > providers HE.Net in Columbus OH being one. We also are peered with 2 > peering exchanges, including EquinixIX in Chicago. The problem is > Instagram and Facebook (same company, I know) for our customers seems > very slow. > > > > This is where I need a way to troubleshoot/understand more. I did a > traceroute to the IP that is serving the pictures, and it resolves to > the FBCDN servers in Dallas, and is showing packet loss and pings once > it hits Dallas, and are in the 1xxs of ms. > > > > Tracing route to instagram-p3-shv-01-dfw1.fbcdn.net [31.13.66.52] > > over a maximum of 30 hops: > > > > 1 4 ms 3 ms 4 ms 10.7.0.1 > > 2 20 ms 43 ms 42 ms inmtvlobs-rtr-01.dynamic.pdsconnect.me > [192.69.57.1] > > 3 25 ms 47 ms 29 ms > inmtvlmwt-rtr-01.infrastructure.pdsconnect.me [192.69.48.162] > > 4 46 ms 32 ms 58 ms > inindyhen-core1.infrastructure.pdsconnect.me [192.69.48.193] > > 5 36 ms 53 ms 51 ms ge2-4.core1.cmh1.he.net [184.105.32.1] > > 6 47 ms 41 ms 75 ms 10ge1-2.core1.chi1.he.net > [184.105.222.165] > > 7 57 ms 57 ms 53 ms 100ge14-1.core2.chi1.he.net > [184.105.81.97] > > 8 57 ms 73 ms 84 ms 100ge12-1.core1.mci3.he.net > [184.105.81.209] > > 9 75 ms 73 ms 102 ms 10ge15-6.core1.dal1.he.net > [184.105.222.10] > > 10 93 ms 103 ms 92 ms eqix-da1.facebook.com [206.223.118.176] > > 11 102 ms 101 ms * psw01c.dfw1.tfbnw.net [173.252.65.196] > > 12 92 ms 97 ms 105 ms msw1aq.01.dfw1.tfbnw.net [204.15.21.89] > > 13 110 ms * 98 ms instagram-p3-shv-01-dfw1.fbcdn.net > [31.13.66.52] > > > > Since I am peered with the route servers in EquinixIX Chicago, > shouldn't the data be coming from there, or at least hit their > routers? In my trace, it shows HE to Chicago, then to Dallas. How > does FB decide what IP the content gets displayed from, and is there > anything I can do as a provider? If it is DNS, I can obviously clear > the cache to see if it gets new IPs. If I'm not getting FB peering > IPs in Chicago, do I need to peer directly? Should I get FaceBook involved? > > > > Eric Rogers > > PDS Connect > > (317) 831-3000 x200 From morrowc.lists at gmail.com Mon Apr 4 12:58:20 2016 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Mon, 4 Apr 2016 08:58:20 -0400 Subject: Some doubts on large scale BGP/AS design and black hole routing risk In-Reply-To: References: Message-ID: On Sun, Apr 3, 2016 at 6:17 PM, Mark Tinka wrote: > > > On 31/Mar/16 10:12, magicboiz at hotmail.com wrote: > > > > > > > My questions are: > > > > 1. What could happen in the case of total failure in the redundant > > leased lines? Black hole routing between POPs? > > If you have redundant backhaul that completely fails, you've got real > problems. > > However, if that does happen, any traffic coming into each individual > PoP destined for users in the other PoP will fail. Only traffic > terminating for customers at that PoP will succeed. > > ?so (as bill points out) plan to localize subnets to each pop. (do not number customers in pop1 in the same /24 as customers in pop2)? > > > > > 2. What are the best design methods to avoid this scenario? > > Work on your backhaul. > > Originate specific routes that cover customers present in each PoP, with > the aggregate as a backup route. > > You can run a tunnel across the Internet to simulate a backbone between > both PoP's, using your side of your upstream's IP addresses as the > tunnel end-point. Not elegant, but keeps you up. > > ?be aware of gre / ip-in-ip forwarding limitations? > > > > 2.1: adding a third POP creating a triangle? What if a POP looses > > connection with the other two POPs at the same time? Another black hole? > > Your fixation on a complete backhaul outage is interesting. > > Purchase backhaul from different service providers to increase your > chances of uptime. > > > ?different providers, different entrance facilities in the building(s), different conduits out of the area... and hope that somewhere along the path providerA and B didn't share conduit or capacity-swap you to a single path :)? > > > > 2.2: requesting another prefix and allocating 1:1 prefix:POP, so in > > the scenario each POP only would announce its prefix to the upstreams? > > See above re: originating more specific routes based on the customers > you have at each PoP. > > > > > > 2.3: other? > > Work harder on your backhaul. > > Yes, bad things can happen, and they do happen. But more than likely, if > a 3-PoP network loses all connectivity from each other, I think routing > will be a much smaller problem to solve in the grand scheme of things. > > Mark. > > From alex at pssclabs.com Mon Apr 4 13:04:37 2016 From: alex at pssclabs.com (Alex Lesser) Date: Mon, 4 Apr 2016 13:04:37 +0000 Subject: Colocation Server Lifts In-Reply-To: References: Message-ID: Very good questions with not so clear cut answers. In line. > On Mar 29, 2016, at 8:23 AM, Jason Lee wrote: > > Hi NANOG community, > > A few questions I have for the community regarding server lifts at colo > facilities. > > 1. Is a server lift something you would typically expect a colo facility to > provide? I would say unfortunately no. Many facilities do have server lifts but many do not. Definitely ask before hand so you understand what you are getting into. Personally I believe every facility should offer these server lifts considering the weight people are racking today. > > if yes, > > 2. Do colo facilities typically allow customers to just use them or provide > an operator? The ones that do have server left usually let you just operate them. Pretty self explanatory devices. Up / down. Brake / move. > 3. Is it a free offering or something they rent out? I have never been asked to sign out a server lift which seems funny considering you have to sign out a crash cart. My guess is it facility dependent. > 4. What would be the typical device weight you would lift? The answer really depends on how much you want to lift manually. The guys I use are pretty comfortable racking 80 lb servers over and over and over again. But if you don?t feel comfortable then a server lift at any weight is a good idea. Save you back! > 5. What would be the max device weight you would lift? Not sure on that one. You should probably consult the manufacturer. I can tell you we typically use server lifts when things get over 100 lbs. I think the heaviest box we have installed using a server lift was over 200 lbs. My guess is that it would support a lot more weight. > > Thanks, > > Jason From mark.tinka at seacom.mu Mon Apr 4 13:07:57 2016 From: mark.tinka at seacom.mu (Mark Tinka) Date: Mon, 4 Apr 2016 15:07:57 +0200 Subject: Some doubts on large scale BGP/AS design and black hole routing risk In-Reply-To: References: Message-ID: On 4/Apr/16 14:58, Christopher Morrow wrote: > > ?so (as bill points out) plan to localize subnets to each pop. (do not > number customers in pop1 in the same /24 as customers in pop2)? Yes. May lead to some global de-aggregation, but can't really avoid that. > > ?be aware of gre / ip-in-ip forwarding limitations? I wouldn't touch it, myself. I'd rather devote the sleepless nights to fixing the backhaul. > > > ?different providers, different entrance facilities in the > building(s), different conduits out of the area... and hope that > somewhere along the path providerA and B didn't share conduit or > capacity-swap you to a single path :)? +1. Mark. From magicboiz at hotmail.com Mon Apr 4 13:29:15 2016 From: magicboiz at hotmail.com (magicboiz at hotmail.com) Date: Mon, 4 Apr 2016 15:29:15 +0200 Subject: Some doubts on large scale BGP/AS design and black hole routing risk In-Reply-To: References: Message-ID: Hi guys thanks everyone for your replies. I'd like to highlight this concept that Christopher gave before: ?"different providers, different entrance facilities in the building(s), different conduits out of the area... " How can we get this in this world where everyone is moving to big Data Center / Colo-Hosters.....In this kind of colo providers, you usually have a Meet-Me-Room or similar (which is a single point of failure) and no control on how you're actually connected with your peers.... Cheers. On 04/04/16 15:07, Mark Tinka wrote: > nights to fixing the backhaul. From faisal at snappytelecom.net Mon Apr 4 13:37:55 2016 From: faisal at snappytelecom.net (Faisal Imtiaz) Date: Mon, 4 Apr 2016 13:37:55 +0000 (GMT) Subject: Someone Please Help Me Understand In-Reply-To: References: <1616470662.13133.1459729597539.JavaMail.zimbra@snappytelecom.net> Message-ID: <1044373317.18808.1459777075344.JavaMail.zimbra@snappytelecom.net> Eric, There is no simple cut and dry way of troubleshooting such a situation, other than need to look at the problem in multiple different ways.. It also helps in being able to do some comparative test/results with another nearby network... It is also not un-common to have to shutdown a peer v.s prepend.. when troubleshooting. One has to keep in mind that many of the IP Transit networks use local pref for customer routes, thus nullifying (ignore) the AS prepends. Each provider is different, HE does not have a published set of communities, thus effectively do not allow their customers to do any significant traffic engineer.. (anyone from HE, if I am wrong, please feel free to correct me). Level3 by default overrides any AS prepends with local pref, but does allow it's customers to use communities to override those settings. >>. I am not trying to publically shame or air dirty laundry, I am just trying to > understand the situation more. CDNs bring a whole new level I have yet to > comprehend with multicast DNS and GeoIP responses... Understood, I have been there so I can relate. Nanog is a great place to learn, even when asking dumb questions, folks here have been very supportive in explaining, and every now and then one sees a sarcastic reply, but overall I cannot say I have ever had anyone treat me in a condescending manner. My humble suggestion is that you start with simple stuff first .. i.e. bgp traffic engineering before trying to wrap your head around multicast DNS and GeoIP response... I often find the answer to complex issues to be in the simple stuff, which often gets overlooked ! :) 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: "Eric Rogers" > To: "Faisal Imtiaz" > Cc: "nanog list" > Sent: Monday, April 4, 2016 8:46:41 AM > Subject: RE: Someone Please Help Me Understand > Thanks Faisal, > > I appreciate the time you took and the detail you have placed. I did try > prepending our HE connection thinking it was an issue via HE, and we started > going out Level3, and it also went to Dallas with nearly the same packet loss. > I don't know what the return path is/was, but through another provider, it > also showed major packet loss. That leads me to believe that FB is/was having > issues in Dallas. Maybe on their peering port? I have since found out they > don't peer through the route servers, but only directly through the exchanges > (direct peering relationship). I have since submitted a peering request to FB > and also submitted a request to their NOC to look at the packet loss and why we > are getting Dallas IPs. I have not received a response to either. > > I can use the community strings to manipulate our announcement of our routes, > but won't DNS tell the browser what IP to ultimately get the data? > > I am not trying to publically shame or air dirty laundry, I am just trying to > understand the situation more. CDNs bring a whole new level I have yet to > comprehend with multicast DNS and GeoIP responses... > > Eric Rogers > PDS Connect > www.pdsconnect.me > (317) 831-3000 x200 > > > -----Original Message----- > From: Faisal Imtiaz [mailto:faisal at snappytelecom.net] > Sent: Sunday, April 3, 2016 8:27 PM > To: Eric Rogers > Cc: nanog list > Subject: Re: Someone Please Help Me Understand > > Hi Eric, > > With this type of connectivity you have to pay attention to Traffic > Engineering... > > And when I say, traffic engineering, I mean both ways.. how you are sending > traffic to them along with how they are sending traffic to you... (sometimes a > bit more challenging to do). > > I will give you two specific example, just to illustrate the point... > > We are located in the east coast, we have ip transit to Cogent network, via one > intermediary ASN. > We also have IP Transit with GTT and Hibernia networks. > We also have direct peering on multiple Peering Fabrics. > > 1st cases... > We have our outbound traffic engineered to prefer direct routes.. e.g. when > sending traffic to Cogent, we send it out via the intermediary ASN to Cogent. > However when traffic is coming back from Cogent.... they see our prefixes via > intermediary ASN as well as Hibernia Networks, since Hibernia networks is a > lower ASN, they prefer that route.... > So, one can say, no big deal, except, Hibernia Networks connects to Cogent on > the West Coast !... so our return traffic is going from the east coast to west > coast and them back to east coast.... > So one can easily say... Houston we have a problem !... > > 2nd Case.. > We are peered with some networks at Telx TIE, via one of our (intermediary) > ASN...So while we can send traffic over to that network via our ASN, however > that networks sees our prefixes via our (intermediary) ASN as Hibernia as > well.... Hibernia being a lower ASN, they send traffic back to us via them... > > In both cases we use communities to take corrective action.... > > Moral of the story is..... just because you have multiple peers, and peer with > folks on the Peering Fabric, the default configuration of BGP will not > AUTOMAGICALY optimize the paths in your favor.... > > And thus the condition you describe will be the result... > > 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: "Eric Rogers" >> To: "nanog list" >> Sent: Saturday, April 2, 2016 1:54:40 PM >> Subject: Someone Please Help Me Understand > >> Ok, I'm trying to learn, so bear with me. >> >> >> >> We are an ISP in Indianapolis that has full routes from 3 different >> providers HE.Net in Columbus OH being one. We also are peered with 2 >> peering exchanges, including EquinixIX in Chicago. The problem is >> Instagram and Facebook (same company, I know) for our customers seems >> very slow. >> >> >> >> This is where I need a way to troubleshoot/understand more. I did a >> traceroute to the IP that is serving the pictures, and it resolves to >> the FBCDN servers in Dallas, and is showing packet loss and pings once >> it hits Dallas, and are in the 1xxs of ms. >> >> >> >> Tracing route to instagram-p3-shv-01-dfw1.fbcdn.net [31.13.66.52] >> >> over a maximum of 30 hops: >> >> >> >> 1 4 ms 3 ms 4 ms 10.7.0.1 >> >> 2 20 ms 43 ms 42 ms inmtvlobs-rtr-01.dynamic.pdsconnect.me >> [192.69.57.1] >> >> 3 25 ms 47 ms 29 ms >> inmtvlmwt-rtr-01.infrastructure.pdsconnect.me [192.69.48.162] >> >> 4 46 ms 32 ms 58 ms >> inindyhen-core1.infrastructure.pdsconnect.me [192.69.48.193] >> >> 5 36 ms 53 ms 51 ms ge2-4.core1.cmh1.he.net [184.105.32.1] >> >> 6 47 ms 41 ms 75 ms 10ge1-2.core1.chi1.he.net >> [184.105.222.165] >> >> 7 57 ms 57 ms 53 ms 100ge14-1.core2.chi1.he.net >> [184.105.81.97] >> >> 8 57 ms 73 ms 84 ms 100ge12-1.core1.mci3.he.net >> [184.105.81.209] >> >> 9 75 ms 73 ms 102 ms 10ge15-6.core1.dal1.he.net >> [184.105.222.10] >> >> 10 93 ms 103 ms 92 ms eqix-da1.facebook.com [206.223.118.176] >> >> 11 102 ms 101 ms * psw01c.dfw1.tfbnw.net [173.252.65.196] >> >> 12 92 ms 97 ms 105 ms msw1aq.01.dfw1.tfbnw.net [204.15.21.89] >> >> 13 110 ms * 98 ms instagram-p3-shv-01-dfw1.fbcdn.net >> [31.13.66.52] >> >> >> >> Since I am peered with the route servers in EquinixIX Chicago, >> shouldn't the data be coming from there, or at least hit their >> routers? In my trace, it shows HE to Chicago, then to Dallas. How >> does FB decide what IP the content gets displayed from, and is there >> anything I can do as a provider? If it is DNS, I can obviously clear >> the cache to see if it gets new IPs. If I'm not getting FB peering >> IPs in Chicago, do I need to peer directly? Should I get FaceBook involved? >> >> >> >> Eric Rogers >> >> PDS Connect >> > > (317) 831-3000 x200 From morrowc.lists at gmail.com Mon Apr 4 14:12:51 2016 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Mon, 4 Apr 2016 10:12:51 -0400 Subject: Some doubts on large scale BGP/AS design and black hole routing risk In-Reply-To: References: Message-ID: On Mon, Apr 4, 2016 at 9:29 AM, magicboiz at hotmail.com wrote: > Hi guys > > thanks everyone for your replies. > > I'd like to highlight this concept that Christopher gave before: > > ?"different providers, different entrance facilities in the building(s), > different conduits out of the area... " > > How can we get this in this world where everyone is moving to big Data > Center / Colo-Hosters.....In this kind of colo providers, you usually have > a Meet-Me-Room or similar (which is a single point of failure) and no > control on how you're actually connected with your peers.... > > ?you mean: "My pop1 is equinix ashburn DC2, my pop2 is equinix SVL1" ? I believe there are separate entrance facilities available at this sort of facility (or that'd certainly be on my RFP if I were looking) and you can sort out with the providers local fiber routing issues by asking for their maps. ? From mark.tinka at seacom.mu Mon Apr 4 14:18:38 2016 From: mark.tinka at seacom.mu (Mark Tinka) Date: Mon, 4 Apr 2016 16:18:38 +0200 Subject: Some doubts on large scale BGP/AS design and black hole routing risk In-Reply-To: References: Message-ID: <7cbecfe6-6a1e-6e70-475b-53115584d582@seacom.mu> On 4/Apr/16 15:29, magicboiz at hotmail.com wrote: > > > How can we get this in this world where everyone is moving to big Data > Center / Colo-Hosters.....In this kind of colo providers, you usually > have a Meet-Me-Room or similar (which is a single point of failure) > and no control on how you're actually connected with your peers.... Into the same data centre, the data centre operators would provide for two or more fibre entry points. Otherwise, you may look for providers that have presence in different facilities, if the city you are living in happens to have this luxury. Mark. From source_route at yahoo.com Mon Apr 4 16:09:12 2016 From: source_route at yahoo.com (Philip Lavine) Date: Mon, 4 Apr 2016 16:09:12 +0000 (UTC) Subject: Time Warner IPv6 - need answers References: <1732723776.2035641.1459786152819.JavaMail.yahoo.ref@mail.yahoo.com> Message-ID: <1732723776.2035641.1459786152819.JavaMail.yahoo@mail.yahoo.com> When is TW in Los Angeles going to support ipv6 prefix delegation? I received a /128 (even though the advanced tech support said they did not support it). From jfmezei_nanog at vaxination.ca Mon Apr 4 17:28:41 2016 From: jfmezei_nanog at vaxination.ca (Jean-Francois Mezei) Date: Mon, 4 Apr 2016 13:28:41 -0400 Subject: Microwave link capacity Message-ID: <5702A449.8080201@vaxination.ca> In a context of providing rural communities with modern broadband. Reading some tells me that Microwave links can be raised to 1gbps. How common is that ? I assume that cell phone towers have modern microwave links (when not directly on fibre). What sort of capacity would typically be provided ? And in the case of a remote village/town served by microwave originally designed to handle just phone calls, how difficult/expensive is it to upgrade to 1gbps or higher capacity ? Just a change of radio ? or radio and antenna, keeping only the tower ? (keeping spectrum acquisition out of discussion as that is a whole other ball game). From applebaumt at ochin.org Mon Apr 4 18:09:00 2016 From: applebaumt at ochin.org (Tyler Applebaum) Date: Mon, 4 Apr 2016 18:09:00 +0000 Subject: Microwave link capacity In-Reply-To: <5702A449.8080201@vaxination.ca> References: <5702A449.8080201@vaxination.ca> Message-ID: <25440C4BF31A8E44872003195DEB57BE0539253B@omail2.community-health.org> DragonWave is one of the bigger players in the game offering 1gbps+ throughput. http://www.dragonwaveinc.com/products/packet-microwave -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Jean-Francois Mezei Sent: Monday, April 4, 2016 10:29 AM To: Nanog at nanog.org Subject: Microwave link capacity In a context of providing rural communities with modern broadband. Reading some tells me that Microwave links can be raised to 1gbps. How common is that ? I assume that cell phone towers have modern microwave links (when not directly on fibre). What sort of capacity would typically be provided ? And in the case of a remote village/town served by microwave originally designed to handle just phone calls, how difficult/expensive is it to upgrade to 1gbps or higher capacity ? Just a change of radio ? or radio and antenna, keeping only the tower ? (keeping spectrum acquisition out of discussion as that is a whole other ball game). 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 with a copy to compliance at ochin.org, delete this email and destroy all copies. From joelja at bogus.com Mon Apr 4 18:18:37 2016 From: joelja at bogus.com (joel jaeggli) Date: Mon, 4 Apr 2016 15:18:37 -0300 Subject: Microwave link capacity In-Reply-To: <5702A449.8080201@vaxination.ca> References: <5702A449.8080201@vaxination.ca> Message-ID: On 4/4/16 2:28 PM, Jean-Francois Mezei wrote: > > In a context of providing rural communities with modern broadband. > > Reading some tells me that Microwave links can be raised to 1gbps. How > common is that ? for wireless backhaul of cell-towers, some wisp infrastructure and for this like inter-building point-to-point connectivity. pretty common. > I assume that cell phone towers have modern microwave links (when not > directly on fibre). What sort of capacity would typically be provided ? an example would be something like http://www.dragonwaveinc.com/solutions/mobile-backhaul > And in the case of a remote village/town served by microwave originally > designed to handle just phone calls, how difficult/expensive is it to > upgrade to 1gbps or higher capacity ? well if you're describing at&t longlines or bell canada C-band microwave relay networks those were built a time when cost was not the primary consideration, (e.g. there were not signficant alternatives in the 1950s to 1970s) > Just a change of radio ? or radio > and antenna, keeping only the tower ? modern radios are dramatically cheaper. use of unii bands or licensed spectrum are options, distance and spectrum choices tends to dominate the set of considerations that goes into selecting a system. examples of unlicensed being something like https://www.ubnt.com/airfiber/airfiber24-hd/ https://www.ubnt.com/airfiber/airfiber5/ > (keeping spectrum acquisition out of discussion as that is a whole other > ball game). > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 229 bytes Desc: OpenPGP digital signature URL: From cryptographrix at gmail.com Mon Apr 4 18:26:26 2016 From: cryptographrix at gmail.com (Cryptographrix) Date: Mon, 04 Apr 2016 18:26:26 +0000 Subject: Microwave link capacity In-Reply-To: <5702A449.8080201@vaxination.ca> References: <5702A449.8080201@vaxination.ca> Message-ID: I do not have direct experience with this, but Ubiquiti's AirFiber 5 seems like an applicable solution: https://www.ubnt.com/airfiber/airfiber5/ It runs around $1.000USD each On Mon, Apr 4, 2016 at 1:30 PM Jean-Francois Mezei < jfmezei_nanog at vaxination.ca> wrote: > > In a context of providing rural communities with modern broadband. > > Reading some tells me that Microwave links can be raised to 1gbps. How > common is that ? > > I assume that cell phone towers have modern microwave links (when not > directly on fibre). What sort of capacity would typically be provided ? > > And in the case of a remote village/town served by microwave originally > designed to handle just phone calls, how difficult/expensive is it to > upgrade to 1gbps or higher capacity ? Just a change of radio ? or radio > and antenna, keeping only the tower ? > > (keeping spectrum acquisition out of discussion as that is a whole other > ball game). > From surfer at mauigateway.com Mon Apr 4 18:27:39 2016 From: surfer at mauigateway.com (Scott Weeks) Date: Mon, 4 Apr 2016 11:27:39 -0700 Subject: Microwave link capacity Message-ID: <20160404112739.8BBAB8BF@m0087795.ppops.net> --- jfmezei_nanog at vaxination.ca wrote: From: Jean-Francois Mezei In a context of providing rural communities with modern broadband. Reading some tells me that Microwave links can be raised to 1gbps. How common is that ? I assume that cell phone towers have modern microwave links (when not directly on fibre). What sort of capacity would typically be provided ? And in the case of a remote village/town served by microwave originally designed to handle just phone calls, how difficult/expensive is it to upgrade to 1gbps or higher capacity ? Just a change of radio ? or radio and antenna, keeping only the tower ? ----------------------------------------------- It depends on the system installed. For example, with Aviat Eclipse ODU 600 you can start out small and grow. They have an "Eclipse Node" that supports throughput capacities to 366 Mbit/s Ethernet, 100xE1, 127xDS1, 4xDS3, STM1+1E1, or 2xSTM1/OC3. If you upgrade to their "Packet Node" it will support Gigabit bandwidth in addition to the above BWs. They have regular slots and you just change cards. scott From josh at imaginenetworksllc.com Mon Apr 4 18:31:19 2016 From: josh at imaginenetworksllc.com (Josh Luthman) Date: Mon, 4 Apr 2016 14:31:19 -0400 Subject: Microwave link capacity In-Reply-To: References: <5702A449.8080201@vaxination.ca> Message-ID: AF5 is not in the market for 1 gbps links FYI. The AF5x is a better product IMO and is $800 per link + dishes. Josh Luthman Office: 937-552-2340 Direct: 937-552-2343 1100 Wayne St Suite 1337 Troy, OH 45373 On Mon, Apr 4, 2016 at 2:26 PM, Cryptographrix wrote: > I do not have direct experience with this, but Ubiquiti's AirFiber 5 seems > like an applicable solution: https://www.ubnt.com/airfiber/airfiber5/ > > It runs around $1.000USD each > > On Mon, Apr 4, 2016 at 1:30 PM Jean-Francois Mezei < > jfmezei_nanog at vaxination.ca> wrote: > > > > > In a context of providing rural communities with modern broadband. > > > > Reading some tells me that Microwave links can be raised to 1gbps. How > > common is that ? > > > > I assume that cell phone towers have modern microwave links (when not > > directly on fibre). What sort of capacity would typically be provided ? > > > > And in the case of a remote village/town served by microwave originally > > designed to handle just phone calls, how difficult/expensive is it to > > upgrade to 1gbps or higher capacity ? Just a change of radio ? or radio > > and antenna, keeping only the tower ? > > > > (keeping spectrum acquisition out of discussion as that is a whole other > > ball game). > > > From hank at efes.iucc.ac.il Mon Apr 4 19:04:42 2016 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Mon, 4 Apr 2016 15:04:42 -0400 (EDT) Subject: Some doubts on large scale BGP/AS design and black hole routing risk In-Reply-To: References: Message-ID: On Mon, 4 Apr 2016, Christopher Morrow wrote: > ?different providers, different entrance facilities in the building(s), > different conduits out of the area... and hope that somewhere along the > path providerA and B didn't share conduit or capacity-swap you to a single > path :)? > I would suggest also different provider equipment. If one provider uses J find your second provider that uses C. Also don't be seduced by a provider that offers 2 disparate paths, using two totally different systems. I remember years ago AT&T's ATM and FR systems both died nationwide due to some equipment bug. Also providers lie either intentionally or by mistake. If they state a circuit is protected, it might be this month, but next month it may not be. You may only discover this 3 years from now when the circuit dies, and the provider is happy to pay the SLA penalty which is far less than the 3 year cost of a protected vs a non-protected circuit. -Hank From jfmezei_nanog at vaxination.ca Mon Apr 4 19:22:00 2016 From: jfmezei_nanog at vaxination.ca (Jean-Francois Mezei) Date: Mon, 4 Apr 2016 15:22:00 -0400 Subject: Microwave link capacity In-Reply-To: References: <5702A449.8080201@vaxination.ca> Message-ID: <5702BED8.6000409@vaxination.ca> Thanks everyone. I got the sanity check I needed. The telcos often have old microwave links to rural communities and in trying to outfit communities with modern broadband (which the telco hasn't done), there needs to be consideration for the link back to civilisation. Up existing microwave links can be upgraded to enough enough capacity for the community, then perhaps it is a acceptabvle solution at least in short/medium term. I know that Telus in the rockies has provided some communities with microwave links to get over mountains (new installs) in last couple of years. (but this has added costs since each tower needs to be powered, have access road or helicopter landing capability etc). From surfer at mauigateway.com Mon Apr 4 19:48:11 2016 From: surfer at mauigateway.com (Scott Weeks) Date: Mon, 4 Apr 2016 12:48:11 -0700 Subject: Some doubts on large scale BGP/AS design and black hole routing risk Message-ID: <20160404124811.8BBB4C88@m0087795.ppops.net> --- hank at efes.iucc.ac.il wrote: From: Hank Nussbacher Also providers lie either intentionally or by mistake. ---------------------------------------- s/ or by mistake// There fixed that. ;-) scott From jra at baylink.com Mon Apr 4 20:05:39 2016 From: jra at baylink.com (Jay R. Ashworth) Date: Mon, 4 Apr 2016 20:05:39 +0000 (UTC) Subject: Better Conversation following tools for Wireshark? Message-ID: <400259599.15312.1459800339808.JavaMail.zimbra@baylink.com> I have to do a little interactive monitoring this week, and while I want to run Wireshark to log the packets, I'd also like to be able to do some more hands on, flow-based monitoring, and the Conversations tool in WS2.x isn't up to the task; it won't let me roll up all traffic for a local IP into a single line, for example, as iftop will. I thought I'd be able to do this with ntop, but even though I can see that monitoring is enable to the switchport from WS, ntop only shows me the broadcast connections. Are there any better tools for this sort of work, that will cooperate with WS on a Win7Pro box? (Yeah, yeah; I know; it's all I have handy and I'm out of days; I had the flu last week like everyone else.) 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 mike.lyon at gmail.com Mon Apr 4 20:26:41 2016 From: mike.lyon at gmail.com (mike.lyon at gmail.com) Date: Mon, 4 Apr 2016 13:26:41 -0700 Subject: Microwave link capacity In-Reply-To: <5702BED8.6000409@vaxination.ca> References: <5702A449.8080201@vaxination.ca> <5702BED8.6000409@vaxination.ca> Message-ID: And some more options: Mimosa Netwtk 10 Ghz livensed solutuon, in excess of gigabit throughput. Licensed 10 ghz and 6 ghz can go pretty long distances (20+ miles) Also check out SAF Tehbika licensed radios, mkstly 366 Mbps throughput but they have a wider band radio now too. Cambium, Ceragon and Trango are also good platforms. For short hops (less than a mile or so), check out Siklu 60 Ghz, gigabit, solutions. If in the US, FCC licensing for PtP links is actually pretty affordable, couple or three grand. It's not like buying spectrum for cell phones. If you need more info, please feel free to hit me up offlist. -Mike > On Apr 4, 2016, at 12:22, Jean-Francois Mezei wrote: > > Thanks everyone. I got the sanity check I needed. > > The telcos often have old microwave links to rural communities and in > trying to outfit communities with modern broadband (which the telco > hasn't done), there needs to be consideration for the link back to > civilisation. > > Up existing microwave links can be upgraded to enough enough capacity > for the community, then perhaps it is a acceptabvle solution at least in > short/medium term. > > I know that Telus in the rockies has provided some communities with > microwave links to get over mountains (new installs) in last couple of > years. (but this has added costs since each tower needs to be powered, > have access road or helicopter landing capability etc). > > From web at typo.org Mon Apr 4 20:44:51 2016 From: web at typo.org (Wayne Bouchard) Date: Mon, 4 Apr 2016 13:44:51 -0700 Subject: Colocation Server Lifts In-Reply-To: References: Message-ID: <20160404204451.GA12583@spider.typo.org> In all my time dealing with various colos around the globe, I cannot say that I can ever recall hearing (or seeing) someone refer to using a lift to install or dismount a server. My inclination therefore is that it is not something likely to be common. That it may exist in locations I have had dealings with is possible, of course, but not something that I am expressly aware of at any particular facility. As to use, I believe these would be in the vein of dollys and ladders, available upon request. Except in the most restrictive colos, I would not expect any explicit conditions for operation except to perhaps be questioned whether you know how to use it before letting you wheel it away. One would hope it would be more or less self-explanatory and just a question of reading the labels by the controls. -Wayne On Tue, Mar 29, 2016 at 07:23:41AM -0500, Jason Lee wrote: > Hi NANOG community, > > A few questions I have for the community regarding server lifts at colo > facilities. > > 1. Is a server lift something you would typically expect a colo facility to > provide? > > if yes, > > 2. Do colo facilities typically allow customers to just use them or provide > an operator? > 3. Is it a free offering or something they rent out? > 4. What would be the typical device weight you would lift? > 5. What would be the max device weight you would lift? > > Thanks, > > Jason --- Wayne Bouchard web at typo.org Network Dude http://www.typo.org/~web/ From josh at kyneticwifi.com Mon Apr 4 20:48:54 2016 From: josh at kyneticwifi.com (Josh Reynolds) Date: Mon, 4 Apr 2016 15:48:54 -0500 Subject: Colocation Server Lifts In-Reply-To: <20160404204451.GA12583@spider.typo.org> References: <20160404204451.GA12583@spider.typo.org> Message-ID: They are much more likely to be used for things like Juniper MX960's (and larger), Brocade MLXe-32's (and larger), etc. Routers and switches that weigh hundreds or thousands of pounds ;) On Mon, Apr 4, 2016 at 3:44 PM, Wayne Bouchard wrote: > In all my time dealing with various colos around the globe, I cannot > say that I can ever recall hearing (or seeing) someone refer to using > a lift to install or dismount a server. My inclination therefore is > that it is not something likely to be common. That it may exist in > locations I have had dealings with is possible, of course, but not > something that I am expressly aware of at any particular facility. > > As to use, I believe these would be in the vein of dollys and ladders, > available upon request. Except in the most restrictive colos, I would > not expect any explicit conditions for operation except to perhaps be > questioned whether you know how to use it before letting you wheel it > away. One would hope it would be more or less self-explanatory and > just a question of reading the labels by the controls. > > -Wayne > > On Tue, Mar 29, 2016 at 07:23:41AM -0500, Jason Lee wrote: >> Hi NANOG community, >> >> A few questions I have for the community regarding server lifts at colo >> facilities. >> >> 1. Is a server lift something you would typically expect a colo facility to >> provide? >> >> if yes, >> >> 2. Do colo facilities typically allow customers to just use them or provide >> an operator? >> 3. Is it a free offering or something they rent out? >> 4. What would be the typical device weight you would lift? >> 5. What would be the max device weight you would lift? >> >> Thanks, >> >> Jason > > --- > Wayne Bouchard > web at typo.org > Network Dude > http://www.typo.org/~web/ From nanog at ics-il.net Tue Apr 5 02:15:50 2016 From: nanog at ics-il.net (Mike Hammett) Date: Mon, 4 Apr 2016 21:15:50 -0500 (CDT) Subject: Microwave link capacity In-Reply-To: <5702A449.8080201@vaxination.ca> Message-ID: <2050440010.3303.1459822545693.JavaMail.mhammett@ThunderFuck> You might be better served with the lists over at wispa.org. Not saying the people here don't have the answers, but that's what those guys do. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest Internet Exchange http://www.midwest-ix.com ----- Original Message ----- From: "Jean-Francois Mezei" To: Nanog at nanog.org Sent: Monday, April 4, 2016 12:28:41 PM Subject: Microwave link capacity In a context of providing rural communities with modern broadband. Reading some tells me that Microwave links can be raised to 1gbps. How common is that ? I assume that cell phone towers have modern microwave links (when not directly on fibre). What sort of capacity would typically be provided ? And in the case of a remote village/town served by microwave originally designed to handle just phone calls, how difficult/expensive is it to upgrade to 1gbps or higher capacity ? Just a change of radio ? or radio and antenna, keeping only the tower ? (keeping spectrum acquisition out of discussion as that is a whole other ball game). From nanog at ics-il.net Tue Apr 5 02:24:41 2016 From: nanog at ics-il.net (Mike Hammett) Date: Mon, 4 Apr 2016 21:24:41 -0500 (CDT) Subject: Microwave link capacity In-Reply-To: <5702A449.8080201@vaxination.ca> Message-ID: <691036334.3322.1459823078565.JavaMail.mhammett@ThunderFuck> A lot of new gear is gigabit. The current price\performance leader is SIAE's ALFOPlus2. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest Internet Exchange http://www.midwest-ix.com ----- Original Message ----- From: "Jean-Francois Mezei" To: Nanog at nanog.org Sent: Monday, April 4, 2016 12:28:41 PM Subject: Microwave link capacity In a context of providing rural communities with modern broadband. Reading some tells me that Microwave links can be raised to 1gbps. How common is that ? I assume that cell phone towers have modern microwave links (when not directly on fibre). What sort of capacity would typically be provided ? And in the case of a remote village/town served by microwave originally designed to handle just phone calls, how difficult/expensive is it to upgrade to 1gbps or higher capacity ? Just a change of radio ? or radio and antenna, keeping only the tower ? (keeping spectrum acquisition out of discussion as that is a whole other ball game). From tim at bobbroadband.com Tue Apr 5 14:08:15 2016 From: tim at bobbroadband.com (Huffman, Timothy) Date: Tue, 5 Apr 2016 14:08:15 +0000 Subject: Microwave link capacity In-Reply-To: <2050440010.3303.1459822545693.JavaMail.mhammett@ThunderFuck> References: <5702A449.8080201@vaxination.ca> <2050440010.3303.1459822545693.JavaMail.mhammett@ThunderFuck> Message-ID: <403E423F9B5CB4499965EDE05C50BF1DF9D93F@CWWAPP471.windstream.com> Agree with Mike that WISPA is probably the place to get real world experience from people who make a living with microwave links. We use primarily Dragonwave (in FCC part 101 frequencies: 11, 18, and 23GHz), which can get ~600-800Mbpas over the air, depending primarily on channel width and distance. For shorter links (~1 mile), we use Siklu 80GHz, which can do 1-2Gbps over the air. -- Tim Huffman Staff Manager ? Fixed Wireless Engineering | Windstream 999 Oak Creek Dr | Lombard, IL 60148 timothy.huffman at windstream.com | windstreambusiness.com o: 630.590.6012 | m: 630.340.1925 | f: 630.986.2496 -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Mike Hammett Sent: Monday, April 04, 2016 9:16 PM Cc: Nanog at nanog.org Subject: Re: Microwave link capacity You might be better served with the lists over at wispa.org. Not saying the people here don't have the answers, but that's what those guys do. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest Internet Exchange http://www.midwest-ix.com ----- Original Message ----- From: "Jean-Francois Mezei" To: Nanog at nanog.org Sent: Monday, April 4, 2016 12:28:41 PM Subject: Microwave link capacity In a context of providing rural communities with modern broadband. Reading some tells me that Microwave links can be raised to 1gbps. How common is that ? I assume that cell phone towers have modern microwave links (when not directly on fibre). What sort of capacity would typically be provided ? And in the case of a remote village/town served by microwave originally designed to handle just phone calls, how difficult/expensive is it to upgrade to 1gbps or higher capacity ? Just a change of radio ? or radio and antenna, keeping only the tower ? (keeping spectrum acquisition out of discussion as that is a whole other ball game). ---------------------------------------------------------------------- This email message and any attachments are for the sole use of the intended recipient(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message and any attachments. From joelja at bogus.com Tue Apr 5 15:25:00 2016 From: joelja at bogus.com (joel jaeggli) Date: Tue, 5 Apr 2016 12:25:00 -0300 Subject: Some doubts on large scale BGP/AS design and black hole routing risk In-Reply-To: References: Message-ID: <14267f62-e38e-f682-8816-394c598c429b@bogus.com> On 4/4/16 10:29 AM, magicboiz at hotmail.com wrote: > Hi guys > > thanks everyone for your replies. > > I'd like to highlight this concept that Christopher gave before: > > ?"different providers, different entrance facilities in the building(s), > different conduits out of the area... " > > How can we get this in this world where everyone is moving to big Data > Center / Colo-Hosters.....In this kind of colo providers, you usually > have a Meet-Me-Room or similar (which is a single point of failure) and > no control on how you're actually connected with your peers.... Sometimes you have two or more MMRs sometimes providers are only one one or another. The actual discipline here is delivering reliable cost-effective service with unreliable components... > Cheers. > > > On 04/04/16 15:07, Mark Tinka wrote: >> nights to fixing the backhaul. > > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 229 bytes Desc: OpenPGP digital signature URL: From robertg at garlic.com Tue Apr 5 15:45:42 2016 From: robertg at garlic.com (Robert Glover) Date: Tue, 5 Apr 2016 08:45:42 -0700 Subject: Microwave link capacity In-Reply-To: <403E423F9B5CB4499965EDE05C50BF1DF9D93F@CWWAPP471.windstream.com> References: <5702A449.8080201@vaxination.ca> <2050440010.3303.1459822545693.JavaMail.mhammett@ThunderFuck> <403E423F9B5CB4499965EDE05C50BF1DF9D93F@CWWAPP471.windstream.com> Message-ID: <5703DDA6.7020807@garlic.com> How well does Siklu handle rain at closer to 1mi. range? On 4/5/2016 7:08 AM, Huffman, Timothy wrote: > Agree with Mike that WISPA is probably the place to get real world experience from people who make a living with microwave links. > > We use primarily Dragonwave (in FCC part 101 frequencies: 11, 18, and 23GHz), which can get ~600-800Mbpas over the air, depending primarily on channel width and distance. For shorter links (~1 mile), we use Siklu 80GHz, which can do 1-2Gbps over the air. > > -- > Tim Huffman > Staff Manager ? Fixed Wireless Engineering | Windstream > 999 Oak Creek Dr | Lombard, IL 60148 > timothy.huffman at windstream.com | windstreambusiness.com > o: 630.590.6012 | m: 630.340.1925 | f: 630.986.2496 > > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Mike Hammett > Sent: Monday, April 04, 2016 9:16 PM > Cc: Nanog at nanog.org > Subject: Re: Microwave link capacity > > You might be better served with the lists over at wispa.org. Not saying the people here don't have the answers, but that's what those guys do. > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > > > Midwest Internet Exchange > http://www.midwest-ix.com > > > ----- Original Message ----- > > From: "Jean-Francois Mezei" > To: Nanog at nanog.org > Sent: Monday, April 4, 2016 12:28:41 PM > Subject: Microwave link capacity > > > In a context of providing rural communities with modern broadband. > > Reading some tells me that Microwave links can be raised to 1gbps. How > common is that ? > > I assume that cell phone towers have modern microwave links (when not > directly on fibre). What sort of capacity would typically be provided ? > > And in the case of a remote village/town served by microwave originally > designed to handle just phone calls, how difficult/expensive is it to > upgrade to 1gbps or higher capacity ? Just a change of radio ? or radio > and antenna, keeping only the tower ? > > (keeping spectrum acquisition out of discussion as that is a whole other > ball game). > > > ---------------------------------------------------------------------- > This email message and any attachments are for the sole use of the intended recipient(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message and any attachments. -- Sincerely, Bobby Glover Director of IS & Engineering SVI Incorporated From joly at punkcast.com Wed Apr 6 14:16:39 2016 From: joly at punkcast.com (Joly MacFie) Date: Wed, 6 Apr 2016 10:16:39 -0400 Subject: WEBCAST TODAY: NEDASNYC In-Building Wireless Summit Message-ID: This is the second year I've streamed the NEDAS NYC conference. It's a very high quality event that gets into nuts and bolts of bringing connectivity to mobile devices in dense environments. Last year one panel was a fascinating dialog on how best to bring wireless to NYC's subway. The first panel today, already underway, is about how to bring "carrier-grade" upload capability to stadiums. Speakers include engineers who have done the Superbowl and the Olympics. *Agenda: https://www.nedas.com/events/nedas-spring-in-building-wireless-summit-nyc Webcast: https://new.livestream.com/internetsociety/nedasnyc2016 * -- --------------------------------------------------------------- Joly MacFie 218 565 9365 Skype:punkcast -------------------------------------------------------------- - From joe at breathe-underwater.com Wed Apr 6 17:08:56 2016 From: joe at breathe-underwater.com (Joseph Jenkins) Date: Wed, 6 Apr 2016 10:08:56 -0700 Subject: gmail for business email contact - server blacklisted Message-ID: Anyone on here from gmail that can help with an issue. One of your email servers has been blacklisted by spam cop and is still in rotation. It's causing individual senders to be blocked on our side. If possible can you remove that server from rotation? IP is: 209.85.161.176 From faisal at snappytelecom.net Wed Apr 6 17:27:57 2016 From: faisal at snappytelecom.net (Faisal Imtiaz) Date: Wed, 6 Apr 2016 17:27:57 +0000 (GMT) Subject: GCN / DigiCell or Columbus Communications ? Message-ID: <441665527.40183.1459963677273.JavaMail.zimbra@snappytelecom.net> Hello, We are looking for 10g wave between Puerto Rico to Trinidad (Maparippe). Please contact me off list. Thanks. 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 From danm at prime.gushi.org Wed Apr 6 18:56:07 2016 From: danm at prime.gushi.org (Dan Mahoney, System Admin) Date: Wed, 6 Apr 2016 11:56:07 -0700 (PDT) Subject: Best practices for sending network maintenance notifications Message-ID: All, We recently, at $dayjob, had one of our peers (at Symantec) send out a network maint notification, putting 70 addresses in the "To:" field, rather than using BCC or the exchange's mailing list. Naturally, when you mail 30 addresses, of the forms peering@ and noc@ various organizations, you're likely to hit at least a few autoresponders and ticket systems... And at least one or two of those autoresponders are of course brainded and configured to reply-all. (In this case, Verizon's ServiceNow setup was such a stupid responder). And that made things fun in our own ticket system, as our RT setup happily created a bunch of tickets. My question for the group -- does anyone know if there's a "best practices" for sending maint notifications like this? An RFC sort of thing? While it would define a social protocol, rather than a truly technical one, if there's not such a document, it seems like it could useful. And once such a thing exists, exchanges could of course helpfully point their members AT it (for both their humans, and ticket systems, to follow). -Dan -- From hal at buzcom.net Wed Apr 6 19:05:14 2016 From: hal at buzcom.net (Hal Ponton) Date: Wed, 6 Apr 2016 20:05:14 +0100 Subject: Best practices for sending network maintenance notifications In-Reply-To: References: Message-ID: I think there was a BCP being worked on. I seem to recall it was being discussed as a Facebook group. But there's no RFC, at least that I know of. Regards, Hal Ponton Senior Network Engineer Buzcom / FibreWiFi Tel: 07429 979 217 Email: hal at buzcom.net > On 6 Apr 2016, at 19:56, Dan Mahoney, System Admin wrote: > > All, > > We recently, at $dayjob, had one of our peers (at Symantec) send out a network maint notification, putting 70 addresses in the "To:" field, rather than using BCC or the exchange's mailing list. > > Naturally, when you mail 30 addresses, of the forms peering@ and noc@ various organizations, you're likely to hit at least a few autoresponders and ticket systems... > > And at least one or two of those autoresponders are of course brainded and configured to reply-all. (In this case, Verizon's ServiceNow setup was such a stupid responder). And that made things fun in our own ticket system, as our RT setup happily created a bunch of tickets. > > My question for the group -- does anyone know if there's a "best practices" for sending maint notifications like this? An RFC sort of thing? > > While it would define a social protocol, rather than a truly technical one, if there's not such a document, it seems like it could useful. And once such a thing exists, exchanges could of course helpfully point their members AT it (for both their humans, and ticket systems, to follow). > > -Dan > > -- > From mjwise at kapu.net Wed Apr 6 19:15:17 2016 From: mjwise at kapu.net (Michael J Wise) Date: Wed, 6 Apr 2016 12:15:17 -0700 Subject: Best practices for sending network maintenance notifications In-Reply-To: References: Message-ID: > I think there was a BCP being worked on. I seem to recall it was being > discussed as a Facebook group. But there's no RFC, at least that I know > of. And additionally, putting the recipients in the To: line sounds like a really bad idea. Sharing PII without permission and stuff like that. Make absolutely certain that all the SPF, DKIM and DMARC stuff is perfect. Make sure that any links are to the corporate domain... always. You want a neutral, paranoid 3rd party who is receiving the notice to be absolutely convinced of its Bona Fides. Do not suppose that your abundance of Sincerity excuses sloppiness. It won't. :( > > Regards, > > Hal Ponton > > Senior Network Engineer > > Buzcom / FibreWiFi > > Tel: 07429 979 217 > Email: hal at buzcom.net > >> On 6 Apr 2016, at 19:56, Dan Mahoney, System Admin >> wrote: >> >> All, >> >> We recently, at $dayjob, had one of our peers (at Symantec) send out a >> network maint notification, putting 70 addresses in the "To:" field, >> rather than using BCC or the exchange's mailing list. >> >> Naturally, when you mail 30 addresses, of the forms peering@ and noc@ >> various organizations, you're likely to hit at least a few >> autoresponders and ticket systems... >> >> And at least one or two of those autoresponders are of course brainded >> and configured to reply-all. (In this case, Verizon's ServiceNow setup >> was such a stupid responder). And that made things fun in our own >> ticket system, as our RT setup happily created a bunch of tickets. >> >> My question for the group -- does anyone know if there's a "best >> practices" for sending maint notifications like this? An RFC sort of >> thing? >> >> While it would define a social protocol, rather than a truly technical >> one, if there's not such a document, it seems like it could useful. And >> once such a thing exists, exchanges could of course helpfully point >> their members AT it (for both their humans, and ticket systems, to >> follow). >> >> -Dan >> >> -- >> > > Aloha mai Nai`a. -- " So this is how Liberty dies ... http://kapu.net/~mjwise/ " To Thunderous Applause. From joelja at bogus.com Wed Apr 6 20:02:41 2016 From: joelja at bogus.com (joel jaeggli) Date: Wed, 6 Apr 2016 17:02:41 -0300 Subject: Best practices for sending network maintenance notifications In-Reply-To: References: Message-ID: On 4/6/16 3:56 PM, Dan Mahoney, System Admin wrote: > All, > > We recently, at $dayjob, had one of our peers (at Symantec) send out a > network maint notification, putting 70 addresses in the "To:" field, > rather than using BCC or the exchange's mailing list. > > Naturally, when you mail 30 addresses, of the forms peering@ and noc@ > various organizations, you're likely to hit at least a few > autoresponders and ticket systems... > > And at least one or two of those autoresponders are of course brainded > and configured to reply-all. (In this case, Verizon's ServiceNow setup > was such a stupid responder). And that made things fun in our own > ticket system, as our RT setup happily created a bunch of tickets. > > My question for the group -- does anyone know if there's a "best > practices" for sending maint notifications like this? An RFC sort of > thing? In general I'd push for a little automation for the sending of notifications as reducing the likelihood of mishap. Targeting bcc is nice, but so does simply generating a message for each peer precludes this. we store contact information which bgp neighbor parameters in our config generation. > While it would define a social protocol, rather than a truly technical > one, if there's not such a document, it seems like it could useful. And > once such a thing exists, exchanges could of course helpfully point > their members AT it (for both their humans, and ticket systems, to follow). > > -Dan > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 229 bytes Desc: OpenPGP digital signature URL: From sean at donelan.com Wed Apr 6 20:52:39 2016 From: sean at donelan.com (Sean Donelan) Date: Wed, 6 Apr 2016 16:52:39 -0400 (EDT) Subject: Best practices for sending network maintenance notifications In-Reply-To: References: Message-ID: On Wed, 6 Apr 2016, Dan Mahoney, System Admin wrote: > My question for the group -- does anyone know if there's a "best practices" > for sending maint notifications like this? An RFC sort of thing? It falls in the category of "Doctor, it hurts when I do this. Don't do that." Even the most dense CSR managers figure it out after a few attempts. The other "don't do that" is never configure Music on Hold for any NOC/SOC lines. Few things are more annoying than a eight hour trouble shooting conference bridge, and one of the dozen NOC/SOCs on the bridge hits the Hold button. From ray at orsiniit.com Wed Apr 6 20:56:14 2016 From: ray at orsiniit.com (Ray Orsini) Date: Wed, 6 Apr 2016 16:56:14 -0400 Subject: Best practices for sending network maintenance notifications In-Reply-To: References: Message-ID: <6f55ba3f4bed651796de80f49788ea2c@mail.gmail.com> "The other "don't do that" is never configure Music on Hold for any NOC/SOC lines. Few things are more annoying than a eight hour trouble shooting conference bridge, and one of the dozen NOC/SOCs on the bridge hits the Hold button." Now that you've said it it seems so obvious. But, honestly I'd never thought it until right now. Thanks! Regards, Ray Orsini ? CEO Orsini IT, LLC ? Technology Consultants VOICE ?DATA ? BANDWIDTH ? SECURITY ? SUPPORT P: 305.967.6756 x1009 E: ray at orsiniit.com TF: 844.OIT.VOIP 7900 NW 155th Street, Suite 103, Miami Lakes, FL 33016 http://www.orsiniit.com | View My Calendar | View/Pay Your Invoices | View Your Tickets -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Sean Donelan Sent: Wednesday, April 6, 2016 4:53 PM To: nanog at nanog.org Subject: Re: Best practices for sending network maintenance notifications On Wed, 6 Apr 2016, Dan Mahoney, System Admin wrote: > My question for the group -- does anyone know if there's a "best > practices" > for sending maint notifications like this? An RFC sort of thing? It falls in the category of "Doctor, it hurts when I do this. Don't do that." Even the most dense CSR managers figure it out after a few attempts. The other "don't do that" is never configure Music on Hold for any NOC/SOC lines. Few things are more annoying than a eight hour trouble shooting conference bridge, and one of the dozen NOC/SOCs on the bridge hits the Hold button. From surfer at mauigateway.com Wed Apr 6 21:11:14 2016 From: surfer at mauigateway.com (Scott Weeks) Date: Wed, 6 Apr 2016 14:11:14 -0700 Subject: Best practices for sending network maintenance notifications Message-ID: <20160406141114.E76DD58A@m0087795.ppops.net> --- ray at orsiniit.com wrote: From: Ray Orsini "The other "don't do that" is never configure Music on Hold for any NOC/SOC lines. Few things are more annoying than a eight hour trouble shooting conference bridge, and one of the dozen NOC/SOCs on the bridge hits the Hold button." Now that you've said it it seems so obvious. But, honestly I'd never thought it until right now. Thanks! ------------------------------- It only takes one time on a hectic multi-party call to learn this one. It's painful and at the worst possible time, especially if they left the room and no one can be contacted to get it turned off. scott From eric.kuhnke at gmail.com Wed Apr 6 21:52:24 2016 From: eric.kuhnke at gmail.com (Eric Kuhnke) Date: Wed, 6 Apr 2016 14:52:24 -0700 Subject: Best practices for sending network maintenance notifications In-Reply-To: <6f55ba3f4bed651796de80f49788ea2c@mail.gmail.com> References: <6f55ba3f4bed651796de80f49788ea2c@mail.gmail.com> Message-ID: And some genius at an ISP's NOC has put rick_asley_never_gonna_give_you_up.mp3 in the their hold queue music rotation list. On Wed, Apr 6, 2016 at 1:56 PM, Ray Orsini wrote: > "The other "don't do that" is never configure Music on Hold for any NOC/SOC > lines. Few things are more annoying than a eight hour trouble shooting > conference bridge, and one of the dozen NOC/SOCs on the bridge hits the > Hold > button." > > > Now that you've said it it seems so obvious. But, honestly I'd never > thought > it until right now. Thanks! > > Regards, > Ray Orsini ? CEO > Orsini IT, LLC ? Technology Consultants > VOICE ?DATA ? BANDWIDTH ? SECURITY ? SUPPORT > P: 305.967.6756 x1009 E: ray at orsiniit.com TF: 844.OIT.VOIP > 7900 NW 155th Street, Suite 103, Miami Lakes, FL 33016 > http://www.orsiniit.com | View My Calendar | View/Pay Your Invoices | View > Your Tickets > > > > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Sean Donelan > Sent: Wednesday, April 6, 2016 4:53 PM > To: nanog at nanog.org > Subject: Re: Best practices for sending network maintenance notifications > > On Wed, 6 Apr 2016, Dan Mahoney, System Admin wrote: > > My question for the group -- does anyone know if there's a "best > > practices" > > for sending maint notifications like this? An RFC sort of thing? > > It falls in the category of "Doctor, it hurts when I do this. Don't do > that." Even the most dense CSR managers figure it out after a few > attempts. > > The other "don't do that" is never configure Music on Hold for any NOC/SOC > lines. Few things are more annoying than a eight hour trouble shooting > conference bridge, and one of the dozen NOC/SOCs on the bridge hits the > Hold > button. > From rdrake at direcpath.com Wed Apr 6 22:52:54 2016 From: rdrake at direcpath.com (Robert Drake) Date: Wed, 6 Apr 2016 18:52:54 -0400 Subject: Best practices for sending network maintenance notifications In-Reply-To: <6f55ba3f4bed651796de80f49788ea2c@mail.gmail.com> References: <6f55ba3f4bed651796de80f49788ea2c@mail.gmail.com> Message-ID: <03c57007-4ab6-f6b9-25ce-93aa4a2ed57a@direcpath.com> I've been on hold a few times with some companies that had great 80's music. I almost asked them to put me back on hold when they finally took me off. Sometimes it's a party when one of the people on the call hits the hold button, it depends on how bad the outage is :) On 4/6/2016 4:56 PM, Ray Orsini wrote: > "The other "don't do that" is never configure Music on Hold for any NOC/SOC > lines. Few things are more annoying than a eight hour trouble shooting > conference bridge, and one of the dozen NOC/SOCs on the bridge hits the Hold > button." > > > Now that you've said it it seems so obvious. But, honestly I'd never thought > it until right now. Thanks! > > Regards, > Ray Orsini ? CEO > Orsini IT, LLC ? Technology Consultants > VOICE ?DATA ? BANDWIDTH ? SECURITY ? SUPPORT > P: 305.967.6756 x1009 E: ray at orsiniit.com TF: 844.OIT.VOIP > 7900 NW 155th Street, Suite 103, Miami Lakes, FL 33016 > http://www.orsiniit.com | View My Calendar | View/Pay Your Invoices | View > Your Tickets > > From mike-nanog at tiedyenetworks.com Thu Apr 7 00:02:52 2016 From: mike-nanog at tiedyenetworks.com (Mike) Date: Wed, 6 Apr 2016 17:02:52 -0700 Subject: mpls switches Message-ID: <5705A3AC.5020903@tiedyenetworks.com> Hi, Im looking to deploy more mpls in my network. I like the Cisco 3600X series but the low density of 10g ports has me wanting to consider perhaps others. I would love a minimum of 4 10g ports but of course more is better. Cost would also be a factor. What are people using these days? Thanks. Mike- From cgrundemann at gmail.com Thu Apr 7 00:29:57 2016 From: cgrundemann at gmail.com (Chris Grundemann) Date: Wed, 6 Apr 2016 20:29:57 -0400 Subject: Best practices for sending network maintenance notifications In-Reply-To: References: Message-ID: On Wed, Apr 6, 2016 at 3:05 PM, Hal Ponton wrote: > I think there was a BCP being worked on. I seem to recall it was being > discussed as a Facebook group. True. https://www.facebook.com/groups/maintnote/ Currently under development, but fairly far along... Cheers, ~Chris -- @ChrisGrundemann http://chrisgrundemann.com From todd.crane at n5tech.com Thu Apr 7 01:53:37 2016 From: todd.crane at n5tech.com (Todd Crane) Date: Wed, 6 Apr 2016 18:53:37 -0700 Subject: mpls switches In-Reply-To: <5705A3AC.5020903@tiedyenetworks.com> References: <5705A3AC.5020903@tiedyenetworks.com> Message-ID: Mike, Nor sure how much you know about SDN or if you are in anywhere near being able to make the transition, but white-label switches may be a deciding factor for you. In fact you may be able to do it without SDN, but I cannot say for sure as we have ours configured in SDN mode. We use Edge-Core 5712-54X switches for our 10G (48x 10G and 6x 40G) and I cannot recommend them enough. Combined with Picos from Pica8, we can do SDN/SD-WAN as well as MPLS at around 6,000 per switch plus maintenance. If you want more information or contacts, hit me up offline (or rather off the mailing list). -Todd > On Apr 6, 2016, at 5:02 PM, Mike wrote: > > Hi, > > Im looking to deploy more mpls in my network. I like the Cisco 3600X series but the low density of 10g ports has me wanting to consider perhaps others. I would love a minimum of 4 10g ports but of course more is better. Cost would also be a factor. What are people using these days? > > Thanks. > > Mike- -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: Message signed with OpenPGP using GPGMail URL: From davidbass570 at gmail.com Thu Apr 7 02:12:37 2016 From: davidbass570 at gmail.com (David Bass) Date: Wed, 6 Apr 2016 22:12:37 -0400 Subject: mpls switches In-Reply-To: References: <5705A3AC.5020903@tiedyenetworks.com> Message-ID: <1748F38B-CC2E-4E34-8978-0B2134D9F41F@gmail.com> Interesting. What SDN controller are you using? Seems like quite a few are moving to white box switches... > On Apr 6, 2016, at 9:53 PM, Todd Crane wrote: > > Edge-Core 5712-54X From baldur.norddahl at gmail.com Thu Apr 7 04:03:45 2016 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Thu, 7 Apr 2016 06:03:45 +0200 Subject: mpls switches In-Reply-To: <5705A3AC.5020903@tiedyenetworks.com> References: <5705A3AC.5020903@tiedyenetworks.com> Message-ID: ZTE 5950 serie MPLS routing switches are about 1500 to 3000 USD depending on configuration. They have a 4x 10G subcard. The CLI is very Cisco like. The ZTE 5960 has 32 or 64 x 10G but starts at 5k-6k. Regards Baldur Den 7. apr. 2016 02.05 skrev "Mike" : > Hi, > > Im looking to deploy more mpls in my network. I like the Cisco 3600X > series but the low density of 10g ports has me wanting to consider perhaps > others. I would love a minimum of 4 10g ports but of course more is better. > Cost would also be a factor. What are people using these days? > > Thanks. > > Mike- > From mark.tinka at seacom.mu Thu Apr 7 05:47:40 2016 From: mark.tinka at seacom.mu (Mark Tinka) Date: Thu, 7 Apr 2016 07:47:40 +0200 Subject: mpls switches In-Reply-To: <5705A3AC.5020903@tiedyenetworks.com> References: <5705A3AC.5020903@tiedyenetworks.com> Message-ID: On 7/Apr/16 02:02, Mike wrote: > Hi, > > Im looking to deploy more mpls in my network. I like the Cisco > 3600X series but the low density of 10g ports has me wanting to > consider perhaps others. I would love a minimum of 4 10g ports but of > course more is better. Cost would also be a factor. What are people > using these days? Cisco ASR920. 4x 10Gbps uplink ports + 24x customer-facing ports. All IP/MPLS capable. Mark. From mr.jonas.bjork at me.com Thu Apr 7 12:05:43 2016 From: mr.jonas.bjork at me.com (Jonas Bjork) Date: Thu, 07 Apr 2016 14:05:43 +0200 Subject: mpls switches In-Reply-To: <5705A3AC.5020903@tiedyenetworks.com> References: <5705A3AC.5020903@tiedyenetworks.com> Message-ID: <851B9B40-5F59-48F2-87B9-DECF88226A61@me.com> Dear Mr. Mike, I would recommend HP A5500-HI. It's a very capable L3 routing switch (12k FIB) aswell as MPLS forwarder - both P and PE. It has two 10 GbE SFP+ ports and is expandable to a total of six if you add two modules. The price is about 2000 dollars (new) and you can stack them aswell using regular M/SMF. It's also got 24 one gig SFP ports in addition to four one gig RJ45 copper ports. Best regards, Jonas Bjork Senior network engineer Sent from my iPhone > On 7 apr. 2016, at 02:02, Mike wrote: > > Hi, > > Im looking to deploy more mpls in my network. I like the Cisco 3600X series but the low density of 10g ports has me wanting to consider perhaps others. I would love a minimum of 4 10g ports but of course more is better. Cost would also be a factor. What are people using these days? > > Thanks. > > Mike- From Bryan at bryanfields.net Thu Apr 7 12:28:33 2016 From: Bryan at bryanfields.net (Bryan Fields) Date: Thu, 7 Apr 2016 08:28:33 -0400 Subject: Microwave link capacity In-Reply-To: <5703DDA6.7020807@garlic.com> References: <5702A449.8080201@vaxination.ca> <2050440010.3303.1459822545693.JavaMail.mhammett@ThunderFuck> <403E423F9B5CB4499965EDE05C50BF1DF9D93F@CWWAPP471.windstream.com> <5703DDA6.7020807@garlic.com> Message-ID: <57065271.1030808@bryanfields.net> On 4/5/16 11:45 AM, Robert Glover wrote: > How well does Siklu handle rain at closer to 1mi. range? This is not dependent on the radio, it's dependent on the frequency and rain zone. http://www.softwright.com/faq/support/Rain%20Rate%20Estimates589.gif If you're in E, it's going to be much more severe fading due to thunder storms vs. in the D or F region. There are calculations you can do to figure out your fading due to rain and how much link availability you need. The newer radios support adaptive modulation, and will downshift from 2048 >1024 >512 >128 > 64 >16 QAM > and some even go down to BPSK. Of course you lose bandwidth for each down shift, so if you need 800 Mbit 99.999% of the time, you need to evaluate it at the lowest modulation that will give that. Horizontal Polarity will be slightly more effected by this, so on any links you're running both polarities, you need to evaluate horizontal. The real problem is a radio from x vendor at a given modulation is about as good as any other vendor. (give or take 3db) Most vendors use a COTS chip-set for the modulation, and about the only difference is the packaging. A 2048 QAM radio will need -63 or better signal just to hit that modulation and in a 40 MHz channel at 18GHz you don't have much distance with out larger dishes or higher power. You in Crane rain zone E? Shit, better add in 35 dB for rain fade. You need a -28 or -30 signal! That's 2k (1.6 Mi) for that path. And you have to rent tower space, pay for engineering, pay for install, and pay for the gear. While it's still cheaper than fiber, and deploys faster, a mile of fiber is not that expensive depending on the area. Microwave has it's place, but the 20 mile, >1gb links are marketing more than anything. -- Bryan Fields 727-409-1194 - Voice 727-214-2508 - Fax http://bryanfields.net From Brandon.Vincent at asu.edu Mon Apr 4 03:54:01 2016 From: Brandon.Vincent at asu.edu (Brandon Vincent) Date: Sun, 3 Apr 2016 20:54:01 -0700 Subject: how to deal with port scan and brute force attack from AS 8075 ? In-Reply-To: References: <56FCD97D.8050201@yahoo.fr> <56FCF2F7.9060709@yahoo.fr> Message-ID: On Thu, Mar 31, 2016 at 4:41 AM, DV wrote: > I have noticed this and especially the strange format of the packets with a > SYN/ECE/CWR flag combination: http://pastebin.com/jFCDAmdr > > This may be $whoever trying to establish network performance/congestion via > ECN or it could be something else like a fast scan technique or OS > fingerprinting It's OS fingerprinting. Targeted attacks are far more productive. If I'm trying to get into an organization, I'd much rather be interested in Juniper ScreenOS than someone's personal *nix machine. Brandon Vincent From elouie at yahoo.com Sun Apr 3 23:33:06 2016 From: elouie at yahoo.com (Eric Louie) Date: Sun, 03 Apr 2016 16:33:06 -0700 Subject: What services does Microsoft AS8075 provide when peering at IXPs? Message-ID: Hi Todd I found an answer. It's everything public Microsoft. If it's private Office 365 or private Azure, it doesn't come through the peering fabric.? Best regards, Eric Sent from my Verizon Wireless 4G LTE smartphone -------- Original message -------- From: Todd Crane Date: 4/3/2016 16:06 (GMT-08:00) To: Eric A Louie Subject: Re: What services does Microsoft AS8075 provide when peering at IXPs? Eric, This may or may not be what your after, but these are the prefixes we receive from them in Phoenix on Phoenix-IX. Peering is requested via the form at http://www.microsoft.com/Peering/PeeringForm. The peering at microsoft.com may be setup to ignore everybody that is not an established peer. That is just a guess. We have had no need to contact them, so we haven?t tried. -Todd ? Prefix ? Nexthop ?????? MED???? Lclpref??? AS path * 13.64.0.0/11??????????? 206.41.105.44??????? 100??????????????? 8075 I * 13.104.0.0/14?????????? 206.41.105.44??????? 100??????????????? 8075 I * 13.107.3.0/24?????????? 206.41.105.44??????? 100??????????????? 8075 8068 I * 13.107.4.0/24?????????? 206.41.105.44??????? 100??????????????? 8075 8068 I * 13.107.5.0/24?????????? 206.41.105.44??????? 100??????????????? 8075 8068 I * 13.107.6.0/24?????????? 206.41.105.44??????? 100??????????????? 8075 8068 I * 13.107.7.0/24?????????? 206.41.105.44??????? 100??????????????? 8075 8068 I * 13.107.9.0/24?????????? 206.41.105.44??????? 100??????????????? 8075 8068 I * 13.107.12.0/24????????? 206.41.105.44??????? 100??????????????? 8075 8068 I * 13.107.13.0/24????????? 206.41.105.44??????? 100??????????????? 8075 8068 I * 13.107.15.0/24????????? 206.41.105.44??????? 100??????????????? 8075 8068 I * 13.107.16.0/24????????? 206.41.105.44??????? 100??????????????? 8075 8068 I * 13.107.18.0/24????????? 206.41.105.44??????? 100??????????????? 8075 8068 I * 13.107.24.0/24????????? 206.41.105.44??????? 100??????????????? 8075 8068 I * 13.107.44.0/24????????? 206.41.105.44??????? 100??????????????? 8075 8068 I * 13.107.58.0/24????????? 206.41.105.44??????? 100??????????????? 8075 8068 I * 13.107.160.0/24???????? 206.41.105.44??????? 100??????????????? 8075 8068 I * 13.107.240.0/24???????? 206.41.105.44??????? 100??????????????? 8075 8068 I * 23.96.0.0/14??????????? 206.41.105.44??????? 100??????????????? 8075 I * 23.100.0.0/15?????????? 206.41.105.44??????? 100??????????????? 8075 I * 23.102.0.0/16?????????? 206.41.105.44??????? 100??????????????? 8075 I * 23.103.64.0/18????????? 206.41.105.44??????? 100??????????????? 8075 I * 23.103.128.0/17???????? 206.41.105.44??????? 100??????????????? 8075 I * 40.64.0.0/10??????????? 206.41.105.44??????? 100??????????????? 8075 I * 40.90.4.0/24??????????? 206.41.105.44??????? 100??????????????? 8075 8068 I * 51.8.0.0/16???????????? 206.41.105.44??????? 100??????????????? 8075 I * 51.10.0.0/15??????????? 206.41.105.44??????? 100??????????????? 8075 I * 51.12.0.0/15??????????? 206.41.105.44??????? 100??????????????? 8075 I * 51.18.0.0/16??????????? 206.41.105.44??????? 100??????????????? 8075 I * 51.51.0.0/16??????????? 206.41.105.44??????? 100??????????????? 8075 I * 51.53.0.0/16??????????? 206.41.105.44??????? 100??????????????? 8075 I * 51.103.0.0/16?????????? 206.41.105.44??????? 100??????????????? 8075 I * 51.104.0.0/15?????????? 206.41.105.44??????? 100??????????????? 8075 I * 51.107.0.0/16?????????? 206.41.105.44??????? 100??????????????? 8075 I * 51.116.0.0/16?????????? 206.41.105.44??????? 100??????????????? 8075 I * 51.120.0.0/16?????????? 206.41.105.44??????? 100??????????????? 8075 I * 51.124.0.0/16?????????? 206.41.105.44??????? 100??????????????? 8075 I * 51.132.0.0/16?????????? 206.41.105.44??????? 100??????????????? 8075 I * 51.136.0.0/15?????????? 206.41.105.44??????? 100??????????????? 8075 I * 51.138.0.0/16?????????? 206.41.105.44??????? 100??????????????? 8075 I * 51.140.0.0/14?????????? 206.41.105.44??????? 100??????????????? 8075 I * 51.144.0.0/15?????????? 206.41.105.44??????? 100??????????????? 8075 I * 52.96.0.0/12??????????? 206.41.105.44??????? 100??????????????? 8075 I * 52.112.0.0/14?????????? 206.41.105.44??????? 100??????????????? 8075 I * 52.120.0.0/14?????????? 206.41.105.44??????? 100??????????????? 8075 I * 52.125.0.0/16?????????? 206.41.105.44??????? 100??????????????? 8075 I * 52.126.0.0/15?????????? 206.41.105.44??????? 100??????????????? 8075 I * 52.130.0.0/15?????????? 206.41.105.44??????? 100??????????????? 8075 I * 52.132.0.0/14?????????? 206.41.105.44??????? 100??????????????? 8075 I * 52.136.0.0/13?????????? 206.41.105.44??????? 100??????????????? 8075 I * 52.145.0.0/16?????????? 206.41.105.44??????? 100??????????????? 8075 I * 52.146.0.0/15?????????? 206.41.105.44??????? 100??????????????? 8075 I * 52.148.0.0/14?????????? 206.41.105.44??????? 100??????????????? 8075 I * 52.152.0.0/13?????????? 206.41.105.44??????? 100??????????????? 8075 I * 52.160.0.0/11?????????? 206.41.105.44??????? 100??????????????? 8075 I * 52.224.0.0/11?????????? 206.41.105.44??????? 100??????????????? 8075 I * 64.4.0.0/18???????????? 206.41.105.44??????? 100??????????????? 8075 I * 64.4.48.0/24??????????? 206.41.105.44??????? 100??????????????? 8075 8068 I * 64.41.193.0/24????????? 206.41.105.44??????? 100??????????????? 8075 20046 I * 65.52.0.0/14??????????? 206.41.105.44??????? 100??????????????? 8075 I * 65.54.0.0/24??????????? 206.41.105.44??????? 100??????????????? 8075 3598 I * 65.54.1.0/24??????????? 206.41.105.44??????? 100??????????????? 8075 3598 I * 65.54.2.0/24??????????? 206.41.105.44??????? 100??????????????? 8075 3598 I * 65.55.28.0/22?????????? 206.41.105.44??????? 100??????????????? 8075 3598 I * 65.55.28.0/23?????????? 206.41.105.44??????? 100??????????????? 8075 3598 ? * 65.55.44.0/24?????????? 206.41.105.44??????? 100??????????????? 8075 8075 I * 65.55.112.0/24????????? 206.41.105.44??????? 100??????????????? 8075 20046 I * 65.55.117.0/24????????? 206.41.105.44??????? 100??????????????? 8075 8075 I * 65.55.171.0/24????????? 206.41.105.44??????? 100??????????????? 8075 20046 I * 65.55.188.0/24????????? 206.41.105.44??????? 100??????????????? 8075 3598 I * 65.55.230.0/24????????? 206.41.105.44??????? 100??????????????? 8075 8075 I * 65.55.231.0/24????????? 206.41.105.44??????? 100??????????????? 8075 8075 I * 65.221.5.0/24?????????? 206.41.105.44??????? 100??????????????? 8075 20046 I * 66.119.144.0/20???????? 206.41.105.44??????? 100??????????????? 8075 I * 70.37.0.0/17??????????? 206.41.105.44??????? 100??????????????? 8075 I * 70.37.128.0/18????????? 206.41.105.44??????? 100??????????????? 8075 I * 91.190.216.0/23???????? 206.41.105.44??????? 100??????????????? 8075 198015 I * 91.190.218.0/23???????? 206.41.105.44??????? 100??????????????? 8075 198097 I * 91.190.220.0/24???????? 206.41.105.44??????? 100??????????????? 8075 198097 I * 94.245.64.0/18????????? 206.41.105.44??????? 100??????????????? 8075 I * 104.40.0.0/13?????????? 206.41.105.44??????? 100??????????????? 8075 I * 104.44.75.0/24????????? 206.41.105.44??????? 100??????????????? 8075 8068 I * 104.146.0.0/19????????? 206.41.105.44??????? 100??????????????? 8075 I * 104.146.128.0/17??????? 206.41.105.44??????? 100??????????????? 8075 I * 104.208.0.0/13????????? 206.41.105.44??????? 100??????????????? 8075 I * 111.221.16.0/20???????? 206.41.105.44??????? 100??????????????? 8075 I * 111.221.64.0/18???????? 206.41.105.44??????? 100??????????????? 8075 I * 131.107.0.0/16????????? 206.41.105.44??????? 100??????????????? 8075 3598 I * 131.107.0.0/20????????? 206.41.105.44??????? 100??????????????? 8075 3598 I * 131.107.217.0/24??????? 206.41.105.44??????? 100??????????????? 8075 3598 I * 131.253.1.0/24????????? 206.41.105.44??????? 100??????????????? 8075 I * 131.253.5.0/24????????? 206.41.105.44??????? 100??????????????? 8075 I * 131.253.6.0/24????????? 206.41.105.44??????? 100??????????????? 8075 I * 131.253.8.0/24????????? 206.41.105.44??????? 100??????????????? 8075 I * 131.253.12.0/22???????? 206.41.105.44??????? 100??????????????? 8075 8075 I * 131.253.16.0/23???????? 206.41.105.44??????? 100??????????????? 8075 23468 I * 131.253.18.0/24???????? 206.41.105.44??????? 100??????????????? 8075 I * 131.253.21.0/24???????? 206.41.105.44??????? 100??????????????? 8075 8068 I * 131.253.22.0/23???????? 206.41.105.44??????? 100??????????????? 8075 23468 I * 131.253.24.0/21???????? 206.41.105.44??????? 100??????????????? 8075 I * 131.253.32.0/20???????? 206.41.105.44??????? 100??????????????? 8075 I * 131.253.33.0/24???????? 206.41.105.44??????? 100??????????????? 8075 I * 131.253.61.0/24???????? 206.41.105.44??????? 100??????????????? 8075 I * 131.253.62.0/23???????? 206.41.105.44??????? 100??????????????? 8075 I * 131.253.72.0/22???????? 206.41.105.44??????? 100??????????????? 8075 8070 I * 131.253.80.0/20???????? 206.41.105.44??????? 100??????????????? 8075 8070 I * 131.253.112.0/21??????? 206.41.105.44??????? 100??????????????? 8075 8070 I * 131.253.120.0/22??????? 206.41.105.44??????? 100??????????????? 8075 8070 I * 131.253.128.0/17??????? 206.41.105.44??????? 100??????????????? 8075 I * 132.245.0.0/16????????? 206.41.105.44??????? 100??????????????? 8075 I * 134.170.0.0/16????????? 206.41.105.44??????? 100??????????????? 8075 I * 137.116.0.0/15????????? 206.41.105.44??????? 100??????????????? 8075 I * 137.135.0.0/16????????? 206.41.105.44??????? 100??????????????? 8075 I * 138.91.0.0/16?????????? 206.41.105.44??????? 100??????????????? 8075 I * 138.196.0.0/16????????? 206.41.105.44??????? 100??????????????? 8075 I * 146.147.0.0/16????????? 206.41.105.44??????? 100??????????????? 8075 I * 150.171.0.0/16????????? 206.41.105.44??????? 100??????????????? 8075 I * 157.55.0.0/16?????????? 206.41.105.44??????? 100??????????????? 8075 I * 157.56.0.0/16?????????? 206.41.105.44??????? 100??????????????? 8075 I * 157.58.0.0/16?????????? 206.41.105.44??????? 100??????????????? 8075 3598 I * 157.58.2.0/23?????????? 206.41.105.44??????? 100??????????????? 8075 23468 I * 157.58.192.0/19???????? 206.41.105.44??????? 100??????????????? 8075 3598 I * 157.58.248.0/23???????? 206.41.105.44??????? 100??????????????? 8075 3598 ? * 157.60.23.0/24????????? 206.41.105.44??????? 100??????????????? 8075 I * 157.60.31.0/24????????? 206.41.105.44??????? 100??????????????? 8075 I * 167.220.0.0/17????????? 206.41.105.44??????? 100??????????????? 8075 3598 I * 167.220.8.0/24????????? 206.41.105.44??????? 100??????????????? 8075 3598 I * 167.220.9.0/24????????? 206.41.105.44??????? 100??????????????? 8075 3598 I * 167.220.10.0/24???????? 206.41.105.44??????? 100??????????????? 8075 3598 I * 167.220.16.0/20???????? 206.41.105.44??????? 100??????????????? 8075 3598 I * 167.220.24.0/22???????? 206.41.105.44??????? 100??????????????? 8075 3598 I * 167.220.28.0/23???????? 206.41.105.44??????? 100??????????????? 8075 6584 8073 I * 167.220.40.0/21???????? 206.41.105.44??????? 100??????????????? 8075 3598 I * 167.220.48.0/21???????? 206.41.105.44??????? 100??????????????? 8075 3598 I * 167.220.64.0/19???????? 206.41.105.44??????? 100??????????????? 8075 3598 I * 167.220.148.0/22??????? 206.41.105.44??????? 100??????????????? 8075 3598 I * 167.220.152.0/24??????? 206.41.105.44??????? 100??????????????? 8075 3598 I * 167.220.192.0/22??????? 206.41.105.44??????? 100??????????????? 8075 6584 I * 167.220.196.0/22??????? 206.41.105.44??????? 100??????????????? 8075 6584 I * 167.220.200.0/24??????? 206.41.105.44??????? 100??????????????? 8075 6584 I * 167.220.201.0/24??????? 206.41.105.44??????? 100??????????????? 8075 6584 I * 167.220.232.0/22??????? 206.41.105.44??????? 100??????????????? 8075 8071 I * 167.220.236.0/22??????? 206.41.105.44??????? 100??????????????? 8075 3598 I * 167.220.240.0/22??????? 206.41.105.44??????? 100??????????????? 8075 I * 167.220.248.0/21??????? 206.41.105.44??????? 100??????????????? 8075 3598 I * 168.61.0.0/16?????????? 206.41.105.44??????? 100??????????????? 8075 I * 168.62.0.0/15?????????? 206.41.105.44??????? 100??????????????? 8075 I * 191.232.0.0/13????????? 206.41.105.44??????? 100??????????????? 8075 I * 192.48.225.0/24???????? 206.41.105.44??????? 100??????????????? 8075 I * 192.84.159.0/24???????? 206.41.105.44??????? 100??????????????? 8075 I * 192.84.160.0/23???????? 206.41.105.44??????? 100??????????????? 8075 I * 192.92.196.0/24???????? 206.41.105.44??????? 100??????????????? 8075 62540 I * 192.197.157.0/24??????? 206.41.105.44??????? 100??????????????? 8075 I * 193.149.64.0/19???????? 206.41.105.44??????? 100??????????????? 8075 I * 193.221.113.0/24??????? 206.41.105.44??????? 100??????????????? 8075 8075 I * 194.69.96.0/22????????? 206.41.105.44??????? 100??????????????? 8075 6584 I * 194.69.100.0/22???????? 206.41.105.44??????? 100??????????????? 8075 6584 I * 194.69.126.0/23???????? 206.41.105.44??????? 100??????????????? 8075 6584 I * 198.49.8.0/24?????????? 206.41.105.44??????? 100??????????????? 8075 8075 I * 198.105.232.0/22??????? 206.41.105.44??????? 100??????????????? 8075 3598 I * 198.180.95.0/24???????? 206.41.105.44??????? 100??????????????? 8075 3598 I * 198.200.130.0/24??????? 206.41.105.44??????? 100??????????????? 8075 I * 198.206.164.0/24??????? 206.41.105.44??????? 100??????????????? 8075 I * 199.2.137.0/24????????? 206.41.105.44??????? 100??????????????? 8075 3598 I * 199.30.16.0/20????????? 206.41.105.44??????? 100??????????????? 8075 I * 199.60.28.0/24????????? 206.41.105.44??????? 100??????????????? 8075 I * 199.74.210.0/24???????? 206.41.105.44??????? 100??????????????? 8075 I * 199.103.90.0/23???????? 206.41.105.44??????? 100??????????????? 8075 I * 199.103.122.0/24??????? 206.41.105.44??????? 100??????????????? 8075 I * 199.242.48.0/21???????? 206.41.105.44??????? 100??????????????? 8075 I * 202.89.224.0/21???????? 206.41.105.44??????? 100??????????????? 8075 I * 204.14.180.0/24???????? 206.41.105.44??????? 100??????????????? 8075 8068 I * 204.79.135.0/24???????? 206.41.105.44??????? 100??????????????? 8075 I * 204.79.179.0/24???????? 206.41.105.44??????? 100??????????????? 8075 I * 204.79.180.0/24???????? 206.41.105.44??????? 100??????????????? 8075 62540 I * 204.79.195.0/24???????? 206.41.105.44??????? 100??????????????? 8075 8075 I * 204.79.197.0/24???????? 206.41.105.44??????? 100??????????????? 8075 8068 I * 204.79.252.0/24???????? 206.41.105.44??????? 100??????????????? 8075 8075 I * 204.95.96.0/20????????? 206.41.105.44??????? 100??????????????? 8075 I * 204.152.140.0/23??????? 206.41.105.44??????? 100??????????????? 8075 I * 204.176.46.0/24???????? 206.41.105.44??????? 100??????????????? 8075 20046 I * 204.182.144.0/24??????? 206.41.105.44??????? 100??????????????? 8075 3598 I * 204.255.244.0/23??????? 206.41.105.44??????? 100??????????????? 8075 3598 I * 206.138.168.0/21??????? 206.41.105.44??????? 100??????????????? 8075 I * 206.191.224.0/19??????? 206.41.105.44??????? 100??????????????? 8075 I * 207.46.0.0/19?????????? 206.41.105.44??????? 100??????????????? 8075 I * 207.46.33.0/24????????? 206.41.105.44??????? 100??????????????? 8075 I * 207.46.34.0/23????????? 206.41.105.44??????? 100??????????????? 8075 I * 207.46.36.0/22????????? 206.41.105.44??????? 100??????????????? 8075 I * 207.46.40.0/21????????? 206.41.105.44??????? 100??????????????? 8075 I * 207.46.48.0/20????????? 206.41.105.44??????? 100??????????????? 8075 I * 207.46.64.0/18????????? 206.41.105.44??????? 100??????????????? 8075 I * 207.46.98.0/24????????? 206.41.105.44??????? 100??????????????? 8075 8075 I * 207.46.128.0/17???????? 206.41.105.44??????? 100??????????????? 8075 I * 207.68.128.0/18???????? 206.41.105.44??????? 100??????????????? 8075 I * 207.82.250.0/23???????? 206.41.105.44??????? 100??????????????? 8075 I * 208.68.136.0/21???????? 206.41.105.44??????? 100??????????????? 8075 I * 208.76.45.0/24????????? 206.41.105.44??????? 100??????????????? 8075 8075 I * 208.76.46.0/24????????? 206.41.105.44??????? 100??????????????? 8075 8075 I * 208.84.0.0/24?????????? 206.41.105.44??????? 100??????????????? 8075 8075 I * 208.84.1.0/24?????????? 206.41.105.44??????? 100??????????????? 8075 I * 208.84.2.0/24?????????? 206.41.105.44??????? 100??????????????? 8075 8075 I * 208.84.3.0/24?????????? 206.41.105.44??????? 100??????????????? 8075 I * 209.1.15.0/24?????????? 206.41.105.44??????? 100??????????????? 8075 20046 I * 209.1.112.0/23????????? 206.41.105.44??????? 100??????????????? 8075 I * 209.185.128.0/22??????? 206.41.105.44??????? 100??????????????? 8075 I * 209.185.240.0/22??????? 206.41.105.44??????? 100??????????????? 8075 I * 209.240.192.0/19??????? 206.41.105.44??????? 100??????????????? 8075 I * 213.199.128.0/18??????? 206.41.105.44??????? 100??????????????? 8075 I * 216.32.180.0/22???????? 206.41.105.44??????? 100??????????????? 8075 I * 216.32.180.0/24???????? 206.41.105.44??????? 100??????????????? 8075 20046 I * 216.32.240.0/22???????? 206.41.105.44??????? 100??????????????? 8075 I * 216.33.240.0/22???????? 206.41.105.44??????? 100??????????????? 8075 I * 216.34.51.0/24????????? 206.41.105.44??????? 100??????????????? 8075 20046 I * 2001:df0:7::/48???????? 2001:504:3b::44????? 100??????????????? 8075 I * 2001:df0:d7::/48??????? 2001:504:3b::44????? 100??????????????? 8075 I * 2001:4898::/32????????? 2001:504:3b::44????? 100??????????????? 8075 3598 I * 2001:4899::/32????????? 2001:504:3b::44????? 100??????????????? 8075 I * 2001:489a:2000::/35???? 2001:504:3b::44????? 100??????????????? 8075 8070 I * 2404:f800::/32????????? 2001:504:3b::44????? 100??????????????? 8075 I * 2404:f801::/32????????? 2001:504:3b::44????? 100??????????????? 8075 8071 I * 2404:f801:8028::/48???? 2001:504:3b::44????? 100??????????????? 8075 3598 I * 2404:f801:8030::/48???? 2001:504:3b::44????? 100??????????????? 8075 I * 2404:f801:8058::/48???? 2001:504:3b::44????? 100??????????????? 8075 3598 I * 2404:f801:9000::/48???? 2001:504:3b::44????? 100??????????????? 8075 3598 I * 2404:f801:a808::/48???? 2001:504:3b::44????? 100??????????????? 8075 8071 I * 2603:1000::/25????????? 2001:504:3b::44????? 100??????????????? 8075 I * 2620:0:30::/45????????? 2001:504:3b::44????? 100??????????????? 8075 I * 2620:1ec::/36?????????? 2001:504:3b::44????? 100??????????????? 8075 I * 2620:1ec:4::/48???????? 2001:504:3b::44????? 100??????????????? 8075 8068 I * 2620:1ec:5::/48???????? 2001:504:3b::44????? 100??????????????? 8075 8068 I * 2620:1ec:6::/48???????? 2001:504:3b::44????? 100??????????????? 8075 8068 I * 2620:1ec:7::/48???????? 2001:504:3b::44????? 100??????????????? 8075 8068 I * 2620:1ec:a::/48???????? 2001:504:3b::44????? 100??????????????? 8075 8068 I * 2620:1ec:b::/48???????? 2001:504:3b::44????? 100??????????????? 8075 8068 I * 2620:1ec:c::/48???????? 2001:504:3b::44????? 100??????????????? 8075 8068 I * 2620:1ec:34::/48??????? 2001:504:3b::44????? 100??????????????? 8075 8068 I * 2620:1ec:a92::/48?????? 2001:504:3b::44????? 100??????????????? 8075 8068 I * 2620:1ec:c11::/48?????? 2001:504:3b::44????? 100??????????????? 8075 8068 I * 2801:80:1d0::/48??????? 2001:504:3b::44????? 100??????????????? 8075 I * 2a01:110::/32?????????? 2001:504:3b::44????? 100??????????????? 8075 6584 I * 2a01:110:8008::/48????? 2001:504:3b::44????? 100??????????????? 8075 6584 I * 2a01:110:8012::/48????? 2001:504:3b::44????? 100??????????????? 8075 6584 I * 2a01:110:a008::/48????? 2001:504:3b::44????? 100??????????????? 8075 6584 I * 2a01:111::/32?????????? 2001:504:3b::44????? 100??????????????? 8075 I * 2a01:111:2003::/48????? 2001:504:3b::44????? 100??????????????? 8075 8068 I * 2a01:111:202c::/48????? 2001:504:3b::44????? 100??????????????? 8075 8068 I * 2a01:111:202e::/48????? 2001:504:3b::44????? 100??????????????? 8075 8068 I > On Apr 1, 2016, at 11:02 AM, Eric A Louie via NANOG wrote: > > I had this question posed by a marketing type in my office.? Does anyone know the answer? > Is it microsoft.com, msdn, outllook365, msn.com, outlook.com, azure, windows updates, xbox?? what else is possibly covered or omitted in their peering service?? I suppose we have a customer who is an Azure customer that wants to know if their Azure traffic will stay in our network or still go through the Internet. > I've tried asking peering at microsoft.com twice, but it looks like they have their ignore filter up. > > Thanks, -e- From eric at flanery.us Mon Apr 4 18:03:41 2016 From: eric at flanery.us (Eric Flanery (eric)) Date: Mon, 4 Apr 2016 11:03:41 -0700 Subject: Microwave link capacity In-Reply-To: <5702A449.8080201@vaxination.ca> References: <5702A449.8080201@vaxination.ca> Message-ID: There is no simple answer, as the characteristics of each link are unique, thus the requirements for each potential upgrade are also unique. Typically an engineering study will be done to determine what exactly is required, and what the cost will be. It could be as simple and cheap as a software license upgrade costing a few hundred dollars; to a complete tear-down and re-build of the towers (to support much larger antennas, for example), costing hundreds of thousands. It can even involve adding additional sites as relays, potentially pushing the cost into the millions. --Eric On Mon, Apr 4, 2016 at 10:28 AM, Jean-Francois Mezei < jfmezei_nanog at vaxination.ca> wrote: > > In a context of providing rural communities with modern broadband. > > Reading some tells me that Microwave links can be raised to 1gbps. How > common is that ? > > I assume that cell phone towers have modern microwave links (when not > directly on fibre). What sort of capacity would typically be provided ? > > And in the case of a remote village/town served by microwave originally > designed to handle just phone calls, how difficult/expensive is it to > upgrade to 1gbps or higher capacity ? Just a change of radio ? or radio > and antenna, keeping only the tower ? > > (keeping spectrum acquisition out of discussion as that is a whole other > ball game). > From coyo at darkdna.net Thu Apr 7 03:13:05 2016 From: coyo at darkdna.net (Coyo Stormcaller) Date: Wed, 6 Apr 2016 22:13:05 -0500 Subject: mpls switches In-Reply-To: <1748F38B-CC2E-4E34-8978-0B2134D9F41F@gmail.com> References: <5705A3AC.5020903@tiedyenetworks.com> <1748F38B-CC2E-4E34-8978-0B2134D9F41F@gmail.com> Message-ID: <20160406221305.4134ab18@coyo-Irresponsible> I just subscribed to NANOG and I already learned something new. I did not know about WhiteBox switches. I like how the price tag is plainly visible to all. This "contact a salesperson" requirement gets old very quickly. On Wed, 6 Apr 2016 22:12:37 -0400 David Bass wrote: > Interesting. What SDN controller are you using? > > Seems like quite a few are moving to white box switches... > > > On Apr 6, 2016, at 9:53 PM, Todd Crane > > wrote: > > > > Edge-Core 5712-54X From baconzombie at gmail.com Thu Apr 7 13:59:48 2016 From: baconzombie at gmail.com (Bacon Zombie) Date: Thu, 7 Apr 2016 15:59:48 +0200 Subject: how to deal with port scan and brute force attack from AS 8075 ? In-Reply-To: References: <56FCD97D.8050201@yahoo.fr> <56FCF2F7.9060709@yahoo.fr> Message-ID: They should always just use Shodan. https://www.shodan.io/explore On 4 April 2016 at 05:54, Brandon Vincent wrote: > On Thu, Mar 31, 2016 at 4:41 AM, DV wrote: >> I have noticed this and especially the strange format of the packets with a >> SYN/ECE/CWR flag combination: http://pastebin.com/jFCDAmdr >> >> This may be $whoever trying to establish network performance/congestion via >> ECN or it could be something else like a fast scan technique or OS >> fingerprinting > > It's OS fingerprinting. Targeted attacks are far more productive. If > I'm trying to get into an organization, I'd much rather be interested > in Juniper ScreenOS than someone's personal *nix machine. > > Brandon Vincent -- BaconZombie 55:55:44:44:4C:52:4C:52:42:41 LOAD "*",8,1 From bill at herrin.us Thu Apr 7 14:41:55 2016 From: bill at herrin.us (William Herrin) Date: Thu, 7 Apr 2016 10:41:55 -0400 Subject: how to deal with port scan and brute force attack from AS 8075 ? In-Reply-To: References: <56FCD97D.8050201@yahoo.fr> <3B53B9D6-BAA3-48C9-82A7-049CC9049269@n5tech.com> Message-ID: On Thu, Mar 31, 2016 at 5:36 AM, Bacon Zombie wrote: > I would ignore the portscans since there is nothing wrong with portscanning > the Internet. You might want to check with your lawyer on that. If you _intentionally_ port-scan a computer located in Virginia without the owner's permission (and do nothing else, just port-scan it) it's a class 3 misdemeanor under 18.2-152.1, et seq. That's up to a $500 fine for each computer you scan. By comparison, shoplifting is a class 1 misdemeanor while possession of a schedule V narcotic is another class 3. A key word here is "intentionally." Poking at it by mistake (e.g. you thought it was a different computer which you had the authority to scan) is not a crime. Nor, most likely, is less aggressive behavior which would not ordinarily be part of gaining unauthorized access, such as pinging or tracerouting. Not that I've ever heard of someone being fined but you're definitely in to "something wrong" territory. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: From jfmezei_nanog at vaxination.ca Thu Apr 7 17:52:47 2016 From: jfmezei_nanog at vaxination.ca (Jean-Francois Mezei) Date: Thu, 7 Apr 2016 13:52:47 -0400 Subject: Microwave link capacity In-Reply-To: <57065271.1030808@bryanfields.net> References: <5702A449.8080201@vaxination.ca> <2050440010.3303.1459822545693.JavaMail.mhammett@ThunderFuck> <403E423F9B5CB4499965EDE05C50BF1DF9D93F@CWWAPP471.windstream.com> <5703DDA6.7020807@garlic.com> <57065271.1030808@bryanfields.net> Message-ID: <57069E6F.9000406@vaxination.ca> On 2016-04-07 08:28, Bryan Fields wrote: > Microwave has it's place, but the 20 mile, >1gb links are marketing more than > anything. So existing long distance links to reach rural communities are not good candidates to upgrade from old microwave that handles just phone to something that can serve broadband for the town ? If existing towers are further apart than what is realistic for higher capacity links, then upgrading would involve new towers at which point, the economics might point to fibre. From faisal at snappytelecom.net Thu Apr 7 18:09:56 2016 From: faisal at snappytelecom.net (Faisal Imtiaz) Date: Thu, 7 Apr 2016 18:09:56 +0000 (GMT) Subject: Microwave link capacity In-Reply-To: <57069E6F.9000406@vaxination.ca> References: <5702A449.8080201@vaxination.ca> <2050440010.3303.1459822545693.JavaMail.mhammett@ThunderFuck> <403E423F9B5CB4499965EDE05C50BF1DF9D93F@CWWAPP471.windstream.com> <5703DDA6.7020807@garlic.com> <57065271.1030808@bryanfields.net> <57069E6F.9000406@vaxination.ca> Message-ID: <599829794.55258.1460052596988.JavaMail.zimbra@snappytelecom.net> There is no simple answer to your question.... Fixed Wireless technology has come a long way, and there maybe a lot of different variety of products available, however when you start your product selection for a particular project, it is not un-common to find one constrained in terms of resources. While one cane make a statement such as .. You can shoot 1gig, 20 miles however that comes with a lot of cavats... i.e. What mfg makes equipment that can do this ? Do you need one set of radios or are you stacking multiple radios ? Do you have the required Freq and Channel available ? and a few other things.. How big is the antenna required for this ? Is the Tower Strong Enough to withstand the wind loading ? What would it take to strengthen the tower ? All of these above details can send you down the path, into a rabbit hole which may or may not be constrained. Then there are different ways to mitigate these constraints .. (making the hop shorter.. ie. and intermediary repeater site.. etc etc etc ). Delivering 1gig + long distance is not an easy slam dunk task. While Fiber can be a lot of work to put in the ground for 20 miles, it is generally considered to be the better option, because there is a lot of headroom for expanding capacity. Fixed Wireless, can be deployed quickly, and may possibly be less expensive however there is no headroom for expanding capacity (if the link is designed as per specs of 1gig Capacity). Hope that makes sense. Regards. Faisal Imtiaz Snappy Internet & Telecom ----- Original Message ----- > From: "Jean-Francois Mezei" > To: "nanog list" > Sent: Thursday, April 7, 2016 1:52:47 PM > Subject: Re: Microwave link capacity > On 2016-04-07 08:28, Bryan Fields wrote: > >> Microwave has it's place, but the 20 mile, >1gb links are marketing more than >> anything. > > > So existing long distance links to reach rural communities are not good > candidates to upgrade from old microwave that handles just phone to > something that can serve broadband for the town ? > > > If existing towers are further apart than what is realistic for higher > capacity links, then upgrading would involve new towers at which point, > the economics might point to fibre. From Steve.Mikulasik at civeo.com Thu Apr 7 18:16:50 2016 From: Steve.Mikulasik at civeo.com (Steve Mikulasik) Date: Thu, 7 Apr 2016 18:16:50 +0000 Subject: Microwave link capacity In-Reply-To: <5702A449.8080201@vaxination.ca> References: <5702A449.8080201@vaxination.ca> Message-ID: Many companies have link planning software available that can help give you an idea as to speed for your particular scenario. Ex: https://airlink.ubnt.com/ From cscora at apnic.net Fri Apr 8 18:10:30 2016 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 9 Apr 2016 04:10:30 +1000 (AEST) Subject: Weekly Routing Table Report Message-ID: <201604081810.u38IAUh8002593@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, SAFNOG, PaNOG, SdNOG, BJNOG, CaribNOG and the RIPE Routing WG. 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 Apr, 2016 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 589751 Prefixes after maximum aggregation (per Origin AS): 216647 Deaggregation factor: 2.72 Unique aggregates announced (without unneeded subnets): 288363 Total ASes present in the Internet Routing Table: 53345 Prefixes per ASN: 11.06 Origin-only ASes present in the Internet Routing Table: 36594 Origin ASes announcing only one prefix: 15723 Transit ASes present in the Internet Routing Table: 6418 Transit-only ASes present in the Internet Routing Table: 174 Average AS path length visible in the Internet Routing Table: 4.3 Max AS path length visible: 39 Max AS path prepend of ASN ( 40285) 34 Prefixes from unregistered ASNs in the Routing Table: 960 Unregistered ASNs in the Routing Table: 357 Number of 32-bit ASNs allocated by the RIRs: 13382 Number of 32-bit ASNs visible in the Routing Table: 10333 Prefixes from 32-bit ASNs in the Routing Table: 40300 Number of bogon 32-bit ASNs visible in the Routing Table: 13 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 396 Number of addresses announced to Internet: 2806952004 Equivalent to 167 /8s, 78 /16s and 176 /24s Percentage of available address space announced: 75.8 Percentage of allocated address space announced: 75.8 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 98.1 Total number of prefixes smaller than registry allocations: 192907 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 151042 Total APNIC prefixes after maximum aggregation: 42035 APNIC Deaggregation factor: 3.59 Prefixes being announced from the APNIC address blocks: 161299 Unique aggregates announced from the APNIC address blocks: 65695 APNIC Region origin ASes present in the Internet Routing Table: 5147 APNIC Prefixes per ASN: 31.34 APNIC Region origin ASes announcing only one prefix: 1185 APNIC Region transit ASes present in the Internet Routing Table: 910 Average APNIC Region AS path length visible: 4.4 Max APNIC Region AS path length visible: 39 Number of APNIC region 32-bit ASNs visible in the Routing Table: 1975 Number of APNIC addresses announced to Internet: 751850820 Equivalent to 44 /8s, 208 /16s and 85 /24s Percentage of available APNIC address space announced: 87.9 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: 180298 Total ARIN prefixes after maximum aggregation: 89148 ARIN Deaggregation factor: 2.02 Prefixes being announced from the ARIN address blocks: 185444 Unique aggregates announced from the ARIN address blocks: 87967 ARIN Region origin ASes present in the Internet Routing Table: 16393 ARIN Prefixes per ASN: 11.31 ARIN Region origin ASes announcing only one prefix: 5871 ARIN Region transit ASes present in the Internet Routing Table: 1713 Average ARIN Region AS path length visible: 3.8 Max ARIN Region AS path length visible: 37 Number of ARIN region 32-bit ASNs visible in the Routing Table: 1120 Number of ARIN addresses announced to Internet: 1101672000 Equivalent to 65 /8s, 170 /16s and 46 /24s Percentage of available ARIN address space announced: 58.3 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: 141875 Total RIPE prefixes after maximum aggregation: 70011 RIPE Deaggregation factor: 2.03 Prefixes being announced from the RIPE address blocks: 150551 Unique aggregates announced from the RIPE address blocks: 92796 RIPE Region origin ASes present in the Internet Routing Table: 18062 RIPE Prefixes per ASN: 8.34 RIPE Region origin ASes announcing only one prefix: 7904 RIPE Region transit ASes present in the Internet Routing Table: 2997 Average RIPE Region AS path length visible: 4.3 Max RIPE Region AS path length visible: 29 Number of RIPE region 32-bit ASNs visible in the Routing Table: 4631 Number of RIPE addresses announced to Internet: 704286592 Equivalent to 41 /8s, 250 /16s and 143 /24s Percentage of available RIPE address space announced: 102.4 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-204287 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: 61962 Total LACNIC prefixes after maximum aggregation: 12210 LACNIC Deaggregation factor: 5.07 Prefixes being announced from the LACNIC address blocks: 76046 Unique aggregates announced from the LACNIC address blocks: 35816 LACNIC Region origin ASes present in the Internet Routing Table: 2470 LACNIC Prefixes per ASN: 30.79 LACNIC Region origin ASes announcing only one prefix: 577 LACNIC Region transit ASes present in the Internet Routing Table: 553 Average LACNIC Region AS path length visible: 4.7 Max LACNIC Region AS path length visible: 21 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 2407 Number of LACNIC addresses announced to Internet: 170680384 Equivalent to 10 /8s, 44 /16s and 96 /24s Percentage of available LACNIC address space announced: 101.7 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: 14193 Total AfriNIC prefixes after maximum aggregation: 3202 AfriNIC Deaggregation factor: 4.43 Prefixes being announced from the AfriNIC address blocks: 16015 Unique aggregates announced from the AfriNIC address blocks: 5732 AfriNIC Region origin ASes present in the Internet Routing Table: 740 AfriNIC Prefixes per ASN: 21.64 AfriNIC Region origin ASes announcing only one prefix: 186 AfriNIC Region transit ASes present in the Internet Routing Table: 170 Average AfriNIC Region AS path length visible: 4.6 Max AfriNIC Region AS path length visible: 18 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 200 Number of AfriNIC addresses announced to Internet: 78087168 Equivalent to 4 /8s, 167 /16s and 132 /24s Percentage of available AfriNIC address space announced: 77.6 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 4538 5594 4192 76 China Education and Research 7545 3299 353 199 TPG Telecom Limited 4766 3153 11142 1119 Korea Telecom 17974 2920 914 96 PT Telekomunikasi Indonesia 9829 2471 1456 445 National Internet Backbone 4755 2099 432 243 TATA Communications formerly 9808 1855 8717 30 Guangdong Mobile Communicatio 4808 1657 2299 539 CNCGROUP IP network China169 4788 1537 645 62 TM Net, Internet Service Prov 38197 1508 93 203 Sun Network (Hong Kong) Limit 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 3355 2948 148 Cox Communications Inc. 6389 2357 3687 42 BellSouth.net Inc. 18566 2209 394 276 MegaPath Corporation 20115 1922 1933 403 Charter Communications 30036 1753 345 215 Mediacom Communications Corp 6983 1691 849 231 EarthLink, Inc. 4323 1568 1004 386 tw telecom holdings, inc. 209 1543 4619 1225 Qwest Communications Company, 701 1399 11446 660 MCI Communications Services, 11492 1271 235 601 CABLE ONE, INC. 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 2708 143 10 SaudiNet, Saudi Telecom Compa 20940 2423 931 1761 Akamai International B.V. 34984 1960 323 413 TELLCOM ILETISIM HIZMETLERI A 8551 1412 376 56 Bezeq International-Ltd 6849 1152 355 21 JSC "Ukrtelecom" 12479 1150 981 86 France Telecom Espana SA 8402 1088 544 15 OJSC "Vimpelcom" 13188 1079 98 69 TOV "Bank-Inform" 31148 1035 47 41 Freenet Ltd. 6830 889 2711 463 Liberty Global Operations B.V 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 3439 539 176 Telmex Colombia S.A. 8151 2219 3312 543 Uninet S.A. de C.V. 7303 1510 939 240 Telecom Argentina S.A. 11830 1477 368 51 Instituto Costarricense de El 6503 1434 453 56 Axtel, S.A.B. de C.V. 6147 1055 377 27 Telefonica del Peru S.A.A. 3816 995 478 185 COLOMBIA TELECOMUNICACIONES S 26615 993 2325 34 Tim Celular S.A. 7738 987 1882 40 Telemar Norte Leste S.A. 28573 879 2175 156 NET Servi?os de Comunica??o S 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 1229 402 40 Link Egypt (Link.NET) 37611 643 48 2 Afrihost-Brevis Computer Serv 8452 619 1472 15 TE-AS 36903 585 294 107 Office National des Postes et 36992 509 1357 25 ETISALAT MISR 37492 370 225 65 Orange Tunisie 24835 297 210 13 Vodafone Data 29571 280 37 12 Cote d'Ivoire Telecom 2018 256 327 74 TENET (The UNINET Project) 36947 236 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 4538 5594 4192 76 China Education and Research 10620 3439 539 176 Telmex Colombia S.A. 22773 3355 2948 148 Cox Communications Inc. 7545 3299 353 199 TPG Telecom Limited 4766 3153 11142 1119 Korea Telecom 17974 2920 914 96 PT Telekomunikasi Indonesia 39891 2708 143 10 SaudiNet, Saudi Telecom Compa 9829 2471 1456 445 National Internet Backbone 20940 2423 931 1761 Akamai International B.V. 6389 2357 3687 42 BellSouth.net Inc. Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 10620 3439 3263 Telmex Colombia S.A. 22773 3355 3207 Cox Communications Inc. 7545 3299 3100 TPG Telecom Limited 17974 2920 2824 PT Telekomunikasi Indonesia 39891 2708 2698 SaudiNet, Saudi Telecom Compa 6389 2357 2315 BellSouth.net Inc. 4766 3153 2034 Korea Telecom 9829 2471 2026 National Internet Backbone 18566 2209 1933 MegaPath Corporation 4755 2099 1856 TATA Communications formerly 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 16589 UNALLOCATED 8.20.247.0/24 35838 CCANET Limited 16589 UNALLOCATED 8.26.56.0/24 35838 CCANET Limited 46473 UNALLOCATED 8.27.122.0/24 3356 Level 3 Communicatio 46473 UNALLOCATED 8.27.124.0/24 3356 Level 3 Communicatio 27205 UNALLOCATED 8.38.16.0/21 3356 Level 3 Communicatio 27205 UNALLOCATED 8.38.22.0/24 32787 Prolexic Technologie 15347 UNALLOCATED 8.224.147.0/24 12064 Cox Communications I 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.178.0.0/24 23456 32bit Transition AS 23.226.112.0/20 62788 >>UNKNOWN<< 23.249.144.0/20 40430 colo4jax, LLC 27.100.7.0/24 56096 >>UNKNOWN<< 37.46.10.0/23 36351 SoftLayer Technologies Inc. 37.46.14.0/24 36351 SoftLayer Technologies Inc. 37.46.15.0/24 36351 SoftLayer Technologies Inc. 41.73.1.0/24 37004 >>UNKNOWN<< 41.73.2.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:13 /10:36 /11:101 /12:267 /13:512 /14:1029 /15:1758 /16:12964 /17:7576 /18:12737 /19:25828 /20:38174 /21:40038 /22:65173 /23:56630 /24:325217 /25:552 /26:595 /27:412 /28:45 /29:31 /30:14 /31:1 /32:32 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 39891 2664 2708 SaudiNet, Saudi Telecom Compa 22773 2532 3355 Cox Communications Inc. 18566 2111 2209 MegaPath Corporation 30036 1567 1753 Mediacom Communications Corp 6389 1499 2357 BellSouth.net Inc. 6983 1340 1691 EarthLink, Inc. 10620 1340 3439 Telmex Colombia S.A. 34984 1245 1960 TELLCOM ILETISIM HIZMETLERI A 11492 1175 1271 CABLE ONE, INC. 6849 970 1152 JSC "Ukrtelecom" Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1661 2:735 4:20 5:2046 6:28 8:946 12:1778 13:39 14:1669 15:45 16:2 17:77 18:89 20:48 23:1445 24:1780 27:2281 31:1761 32:54 33:2 34:2 35:5 36:279 37:2263 38:1182 39:24 40:87 41:2781 42:393 43:1704 44:41 45:1783 46:2480 47:74 49:1140 50:844 51:8 52:143 54:220 55:4 56:6 57:45 58:1535 59:873 60:570 61:1814 62:1482 63:1920 64:4473 65:2149 66:4299 67:2170 68:1101 69:3279 70:1063 71:468 72:1984 74:2542 75:340 76:418 77:1340 78:1270 79:837 80:1329 81:1360 82:940 83:687 84:816 85:1580 86:472 87:1015 88:561 89:1947 90:168 91:6058 92:850 93:2319 94:2313 95:2306 96:475 97:358 98:956 99:45 100:71 101:1018 103:10298 104:2347 105:162 106:392 107:1081 108:676 109:2276 110:1259 111:1658 112:960 113:1140 114:1040 115:1699 116:1539 117:1426 118:2151 119:1580 120:521 121:1166 122:2212 123:2009 124:1620 125:1760 128:716 129:381 130:413 131:1316 132:628 133:174 134:451 135:123 136:372 137:349 138:1716 139:239 140:251 141:467 142:642 143:883 144:611 145:162 146:853 147:675 148:1456 149:496 150:653 151:765 152:608 153:277 154:573 155:950 156:491 157:473 158:342 159:1108 160:450 161:740 162:2294 163:547 164:753 165:1039 166:313 167:1103 168:1675 169:638 170:1583 171:271 172:527 173:1697 174:729 175:909 176:1678 177:4076 178:2241 179:1145 180:2064 181:1724 182:1907 183:681 184:788 185:6120 186:3127 187:2117 188:2154 189:1744 190:7700 191:1199 192:8932 193:5723 194:4367 195:3773 196:1713 197:1064 198:5541 199:5655 200:6942 201:3713 202:10112 203:9662 204:4656 205:2702 206:2982 207:3079 208:4060 209:3789 210:3937 211:2011 212:2633 213:2190 214:836 215:72 216:5738 217:1932 218:763 219:567 220:1678 221:858 222:663 223:970 End of report From trelane at trelane.net Sat Apr 9 03:19:00 2016 From: trelane at trelane.net (Andrew Kirch) Date: Fri, 8 Apr 2016 23:19:00 -0400 Subject: Would someone who works for Brighthouse please contact me offlist to resolve a connectivity issue? Message-ID: I can't access http://jimtest.delong.com via your Cable Modem network. Thanks! Andrew From stuarteclark at yahoo.com Fri Apr 8 05:50:58 2016 From: stuarteclark at yahoo.com (Stuart Clark) Date: Fri, 8 Apr 2016 06:50:58 +0100 Subject: Yahoo geo IP help Message-ID: <3A1536F6-0BB7-44CC-A744-8649221FDF4A@yahoo.com> Could someone reach out to me off list from Yahoo please. Cheers! Sent from my iPhone From shtsuchi at cisco.com Fri Apr 8 02:02:19 2016 From: shtsuchi at cisco.com (Shishio Tsuchiya) Date: Fri, 8 Apr 2016 11:02:19 +0900 Subject: Fwd: JANOG38 Meeting Call for Presentations In-Reply-To: References: Message-ID: <5707112B.1050805@cisco.com> This is CFP remind mail of JANOG38 CFP from JANOG38 Program Committee , CFP Deadline : 15 April 23:59 JST(UTC+9) CFP informations are https://www.janog.gr.jp/meeting/janog38/en/cfp General information of JANOG38 are https://www.janog.gr.jp/meeting/janog38/en See you at Okinawa;-) Regards, -Shishio -------- Forwarded Message -------- Subject: JANOG38 Meeting Call for Presentations Date: Mon, 7 Mar 2016 04:01:09 +0000 From: Hiroya Kaneko To: nanog at nanog.org Hello, JANOG38 Meeting will take place on 6-8 July 2016 in OKINAWA, Japan. JANOG is making a call for presentations until 15 April 2016. Our meetings are in Japanese, but we have had several non-Japanese speakers who made presentations in the past. We are looking forward to your proposals for presentations. Shishio Tsuchiya,Hiroya Kaneko JANOG38 Programme Committee Co-Chairs ---------------------------------------------------------------------- ** JANOG38 MEETING ---------------------------------------------------------------------- - Host : OKIT Corporation - Date : 6 July., 2016 - 8 July., 2016 - Venue : TBD (Naha, Okinawa) - Fees : Conference(6-8 July): Free Banquet(in the evening on 7th): TBD ---------------------------------------------------------------------- ** HOW TO SUBMIT PRESENTATIONS ---------------------------------------------------------------------- If you are interested to give a presentation, submissions are welcome via e-mail at:"meeting-38[at]janog.gr.jp" with the following information. 1. Speaker's name(s) 2. Speaker's organization(s) 3. Preferred contact email address 4. Submission category (General Session or Panel Session) * If your choice is panel, please tell us the number of speakers 5. Presentation title 6. Abstract 7. Desired presentation time and discussion time 8. Slides (attachment or URL), in PowerPoint or PDF format. Our Meetings are in Japanese, so non-Japanese speakers usually arrange an informal interpreter. If you are interested in making a presentation at JANOG but cannot arrange an interpreter by yourself, you could consult with us at: "meeting-38[at]janog.gr.jp". Although we cannot guarantee, we may be able to help you on volunteer basis. Let us know if you have any questions : meeting-38[at]janog.gr.jp ---------------------------------------------------------------------- ** THE KEY DATE FOR JANOG38 SUBMISSIONS ---------------------------------------------------------------------- CFP Deadline : 15 April 23:59 JST The Program Committee will notify you after 25th April about your submission. ---------------------------------------------------------------------- ** VISA ---------------------------------------------------------------------- Foreign visitor entering Japan must have a passport which has valid period during you stay in Japan. Passport holders from some countries are required to have a visa to visit Japan before they depart toward Japan. Many are exempt from this requirement and can get their visa on entry to Japan. Please determine whether you are exempt from the visa requirement. Please refer to the official website from Ministry of Foreign Affairs of Japan or any other appropriate website to get more information about Visa application. Ministry of Foreign Affairs of Japan - Guide to Japanese Visas http://www.mofa.go.jp/j_info/visit/visa/index.html List of Countries and Regions for Visa Exemptions http://www.mofa.go.jp/j_info/visit/visa/short/novisa.html Please note that JANOG can not assist you with your visa application. If you have any questions about the meeting, please feel free to contact meeting-38[at]janog.gr.jp. ---------------------------------------------------------------------- ** ABOUT JANOG ---------------------------------------------------------------------- JANOG webpage in English is available at: http://www.janog.gr.jp/en/ ---------------------------------------------------------------------- ******************************************************* Hiroya Kaneko NEC Cloud System Research Laboratories 1753, Shimonumabe, Nakahara-ku, Kawasaki Kanagawa 211-8666, Japan TEL +8150-3381-7597 Mail: h-kaneko at dr.jp.nec.com . From darin.steffl at mnwifi.com Fri Apr 8 23:35:45 2016 From: darin.steffl at mnwifi.com (Darin Steffl) Date: Fri, 8 Apr 2016 18:35:45 -0500 Subject: Apple blocking downloads to certain IP address Message-ID: Hello all, We seem to keep having problems with Apple blocking app downloads and software updates to one of our IP addresses we use to NAT some customers to. To fix it in the past, we've switched customers to a different IP and it works awhile then it stops again. Anyone have a contact for Apple so we can get our entire subnet whitelisted to not be blocked? Thanks -- Darin Steffl Minnesota WiFi www.mnwifi.com 507-634-WiFi Like us on Facebook From maxtul at netassist.ua Sun Apr 10 13:29:39 2016 From: maxtul at netassist.ua (Max Tulyev) Date: Sun, 10 Apr 2016 16:29:39 +0300 Subject: Stop IPv6 Google traffic Message-ID: <570A5543.1030009@netassist.ua> Hi All, I need to stop IPv6 web traffic going from our customers to Google without touching all other IPv6 and without blackhole IPv6 Google network (this case my customers are complaining on long timeouts). What can you advice for that? From Valdis.Kletnieks at vt.edu Sun Apr 10 13:50:13 2016 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Sun, 10 Apr 2016 09:50:13 -0400 Subject: Stop IPv6 Google traffic In-Reply-To: <570A5543.1030009@netassist.ua> References: <570A5543.1030009@netassist.ua> Message-ID: <60483.1460296213@turing-police.cc.vt.edu> On Sun, 10 Apr 2016 16:29:39 +0300, Max Tulyev said: > I need to stop IPv6 web traffic going from our customers to Google > without touching all other IPv6 and without blackhole IPv6 Google > network (this case my customers are complaining on long timeouts). > > What can you advice for that? Umm.. fix the reasons why they're seeing timeouts? :) Have you determined why the timeouts are happening? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From jared at puck.nether.net Sun Apr 10 13:56:49 2016 From: jared at puck.nether.net (Jared Mauch) Date: Sun, 10 Apr 2016 09:56:49 -0400 Subject: Stop IPv6 Google traffic In-Reply-To: <570A5543.1030009@netassist.ua> References: <570A5543.1030009@netassist.ua> Message-ID: I don't understand the motive here. You want to provide a partial view of the IPv6 table, but sans Google? Do you as a network do the same for v4? If not, you really need to consider having congruent implementations. - jared > On Apr 10, 2016, at 9:29 AM, Max Tulyev wrote: > > Hi All, > > I need to stop IPv6 web traffic going from our customers to Google > without touching all other IPv6 and without blackhole IPv6 Google > network (this case my customers are complaining on long timeouts). > > What can you advice for that? From maxtul at netassist.ua Sun Apr 10 14:07:47 2016 From: maxtul at netassist.ua (Max Tulyev) Date: Sun, 10 Apr 2016 17:07:47 +0300 Subject: Stop IPv6 Google traffic In-Reply-To: <60483.1460296213@turing-police.cc.vt.edu> References: <570A5543.1030009@netassist.ua> <60483.1460296213@turing-police.cc.vt.edu> Message-ID: <570A5E33.1010002@netassist.ua> Customers see timeouts if I blackhole Google network. I looking for alternatives (other than stop providing IPv6 to customers at all). On 10.04.16 16:50, Valdis.Kletnieks at vt.edu wrote: > On Sun, 10 Apr 2016 16:29:39 +0300, Max Tulyev said: > >> I need to stop IPv6 web traffic going from our customers to Google >> without touching all other IPv6 and without blackhole IPv6 Google >> network (this case my customers are complaining on long timeouts). >> >> What can you advice for that? > > Umm.. fix the reasons why they're seeing timeouts? :) > > Have you determined why the timeouts are happening? > From fhr at fhrnet.eu Sun Apr 10 14:11:04 2016 From: fhr at fhrnet.eu (Filip Hruska) Date: Sun, 10 Apr 2016 16:11:04 +0200 Subject: Stop IPv6 Google traffic In-Reply-To: <570A5E33.1010002@netassist.ua> References: <570A5543.1030009@netassist.ua> <60483.1460296213@turing-police.cc.vt.edu> <570A5E33.1010002@netassist.ua> Message-ID: <570A5EF8.2080209@fhrnet.eu> Why do you want to prevent IPv6 access to Google? What's the point? On 04/10/2016 04:07 PM, Max Tulyev wrote: > Customers see timeouts if I blackhole Google network. I looking for > alternatives (other than stop providing IPv6 to customers at all). > > On 10.04.16 16:50, Valdis.Kletnieks at vt.edu wrote: >> On Sun, 10 Apr 2016 16:29:39 +0300, Max Tulyev said: >> >>> I need to stop IPv6 web traffic going from our customers to Google >>> without touching all other IPv6 and without blackhole IPv6 Google >>> network (this case my customers are complaining on long timeouts). >>> >>> What can you advice for that? >> >> Umm.. fix the reasons why they're seeing timeouts? :) >> >> Have you determined why the timeouts are happening? >> > From Valdis.Kletnieks at vt.edu Sun Apr 10 14:14:23 2016 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Sun, 10 Apr 2016 10:14:23 -0400 Subject: Stop IPv6 Google traffic In-Reply-To: <570A5E33.1010002@netassist.ua> References: <570A5543.1030009@netassist.ua> <60483.1460296213@turing-police.cc.vt.edu> <570A5E33.1010002@netassist.ua> Message-ID: <62502.1460297663@turing-police.cc.vt.edu> On Sun, 10 Apr 2016 17:07:47 +0300, Max Tulyev said: > Customers see timeouts if I blackhole Google network. I looking for > alternatives (other than stop providing IPv6 to customers at all). "Doctor, it hurts when I do this.." "Then don't do that..." Why are you blackholing Google? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From nanog at ics-il.net Sun Apr 10 14:17:49 2016 From: nanog at ics-il.net (Mike Hammett) Date: Sun, 10 Apr 2016 09:17:49 -0500 (CDT) Subject: Stop IPv6 Google traffic In-Reply-To: <570A5E33.1010002@netassist.ua> Message-ID: <867546809.10981.1460297868707.JavaMail.mhammett@ThunderFuck> I think the group wants to know what problem you're trying to solve. Obviously if you block something, there will be a timeout in getting to it. What is broken that you're trying to fix by blackholing them? ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest Internet Exchange http://www.midwest-ix.com ----- Original Message ----- From: "Max Tulyev" To: nanog at nanog.org Sent: Sunday, April 10, 2016 9:07:47 AM Subject: Re: Stop IPv6 Google traffic Customers see timeouts if I blackhole Google network. I looking for alternatives (other than stop providing IPv6 to customers at all). On 10.04.16 16:50, Valdis.Kletnieks at vt.edu wrote: > On Sun, 10 Apr 2016 16:29:39 +0300, Max Tulyev said: > >> I need to stop IPv6 web traffic going from our customers to Google >> without touching all other IPv6 and without blackhole IPv6 Google >> network (this case my customers are complaining on long timeouts). >> >> What can you advice for that? > > Umm.. fix the reasons why they're seeing timeouts? :) > > Have you determined why the timeouts are happening? > From pavel.odintsov at gmail.com Sun Apr 10 14:18:56 2016 From: pavel.odintsov at gmail.com (Pavel Odintsov) Date: Sun, 10 Apr 2016 09:18:56 -0500 Subject: Stop IPv6 Google traffic In-Reply-To: <570A5EF8.2080209@fhrnet.eu> References: <570A5543.1030009@netassist.ua> <60483.1460296213@turing-police.cc.vt.edu> <570A5E33.1010002@netassist.ua> <570A5EF8.2080209@fhrnet.eu> Message-ID: Hello! Same question from my side. What's original issue with IPv6 and Google? On Sun, Apr 10, 2016 at 9:11 AM, Filip Hruska wrote: > Why do you want to prevent IPv6 access to Google? > What's the point? > > > On 04/10/2016 04:07 PM, Max Tulyev wrote: >> >> Customers see timeouts if I blackhole Google network. I looking for >> alternatives (other than stop providing IPv6 to customers at all). >> >> On 10.04.16 16:50, Valdis.Kletnieks at vt.edu wrote: >>> >>> On Sun, 10 Apr 2016 16:29:39 +0300, Max Tulyev said: >>> >>>> I need to stop IPv6 web traffic going from our customers to Google >>>> without touching all other IPv6 and without blackhole IPv6 Google >>>> network (this case my customers are complaining on long timeouts). >>>> >>>> What can you advice for that? >>> >>> >>> Umm.. fix the reasons why they're seeing timeouts? :) >>> >>> Have you determined why the timeouts are happening? >>> >> > -- Sincerely yours, Pavel Odintsov From maxtul at netassist.ua Sun Apr 10 14:27:53 2016 From: maxtul at netassist.ua (Max Tulyev) Date: Sun, 10 Apr 2016 17:27:53 +0300 Subject: Stop IPv6 Google traffic In-Reply-To: <867546809.10981.1460297868707.JavaMail.mhammett@ThunderFuck> References: <867546809.10981.1460297868707.JavaMail.mhammett@ThunderFuck> Message-ID: <570A62E9.9030802@netassist.ua> The problem is IPv6-enabled customers complaints see captcha, and Google NOC refuses to help solve it saying like find out some of your customer violating some of our policy. As you can imagine, this is not possible. So, the working solutions is either correctly cut IPv6 to Google, or cut all IPv6 (which I don't want to do). On 10.04.16 17:17, Mike Hammett wrote: > I think the group wants to know what problem you're trying to solve. Obviously if you block something, there will be a timeout in getting to it. > > What is broken that you're trying to fix by blackholing them? > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > > > Midwest Internet Exchange > http://www.midwest-ix.com > > > ----- Original Message ----- > > From: "Max Tulyev" > To: nanog at nanog.org > Sent: Sunday, April 10, 2016 9:07:47 AM > Subject: Re: Stop IPv6 Google traffic > > Customers see timeouts if I blackhole Google network. I looking for > alternatives (other than stop providing IPv6 to customers at all). > > On 10.04.16 16:50, Valdis.Kletnieks at vt.edu wrote: >> On Sun, 10 Apr 2016 16:29:39 +0300, Max Tulyev said: >> >>> I need to stop IPv6 web traffic going from our customers to Google >>> without touching all other IPv6 and without blackhole IPv6 Google >>> network (this case my customers are complaining on long timeouts). >>> >>> What can you advice for that? >> >> Umm.. fix the reasons why they're seeing timeouts? :) >> >> Have you determined why the timeouts are happening? >> > > > From dovid at telecurve.com Sun Apr 10 14:35:34 2016 From: dovid at telecurve.com (Dovid Bender) Date: Sun, 10 Apr 2016 14:35:34 +0000 Subject: Stop IPv6 Google traffic In-Reply-To: References: <570A5543.1030009@netassist.ua> <60483.1460296213@turing-police.cc.vt.edu> <570A5E33.1010002@netassist.ua> <570A5EF8.2080209@fhrnet.eu> Message-ID: <1356528668-1460298934-cardhu_decombobulator_blackberry.rim.net-1736632730-@b12.c1.bise6.blackberry> He works for cogent :p ? Regards, Dovid -----Original Message----- From: Pavel Odintsov Sender: "NANOG" Date: Sun, 10 Apr 2016 09:18:56 To: Filip Hruska Cc: nanog at nanog.org Subject: Re: Stop IPv6 Google traffic Hello! Same question from my side. What's original issue with IPv6 and Google? On Sun, Apr 10, 2016 at 9:11 AM, Filip Hruska wrote: > Why do you want to prevent IPv6 access to Google? > What's the point? > > > On 04/10/2016 04:07 PM, Max Tulyev wrote: >> >> Customers see timeouts if I blackhole Google network. I looking for >> alternatives (other than stop providing IPv6 to customers at all). >> >> On 10.04.16 16:50, Valdis.Kletnieks at vt.edu wrote: >>> >>> On Sun, 10 Apr 2016 16:29:39 +0300, Max Tulyev said: >>> >>>> I need to stop IPv6 web traffic going from our customers to Google >>>> without touching all other IPv6 and without blackhole IPv6 Google >>>> network (this case my customers are complaining on long timeouts). >>>> >>>> What can you advice for that? >>> >>> >>> Umm.. fix the reasons why they're seeing timeouts? :) >>> >>> Have you determined why the timeouts are happening? >>> >> > -- Sincerely yours, Pavel Odintsov From cra at WPI.EDU Sun Apr 10 14:35:43 2016 From: cra at WPI.EDU (Chuck Anderson) Date: Sun, 10 Apr 2016 10:35:43 -0400 Subject: Stop IPv6 Google traffic In-Reply-To: <570A62E9.9030802@netassist.ua> References: <867546809.10981.1460297868707.JavaMail.mhammett@ThunderFuck> <570A62E9.9030802@netassist.ua> Message-ID: <20160410143543.GA1949@angus.ind.wpi.edu> Assign your customers larger v6 prefixes so one customer's bad behavior doesn't affect the others? On Sun, Apr 10, 2016 at 05:27:53PM +0300, Max Tulyev wrote: > The problem is IPv6-enabled customers complaints see captcha, and Google > NOC refuses to help solve it saying like find out some of your customer > violating some of our policy. As you can imagine, this is not possible. > > So, the working solutions is either correctly cut IPv6 to Google, or cut > all IPv6 (which I don't want to do). > > On 10.04.16 17:17, Mike Hammett wrote: > > I think the group wants to know what problem you're trying to solve. Obviously if you block something, there will be a timeout in getting to it. > > > > What is broken that you're trying to fix by blackholing them? > > > > > > > > > > ----- > > Mike Hammett > > Intelligent Computing Solutions > > http://www.ics-il.com > > > > > > > > Midwest Internet Exchange > > http://www.midwest-ix.com > > > > > > ----- Original Message ----- > > > > From: "Max Tulyev" > > To: nanog at nanog.org > > Sent: Sunday, April 10, 2016 9:07:47 AM > > Subject: Re: Stop IPv6 Google traffic > > > > Customers see timeouts if I blackhole Google network. I looking for > > alternatives (other than stop providing IPv6 to customers at all). > > > > On 10.04.16 16:50, Valdis.Kletnieks at vt.edu wrote: > >> On Sun, 10 Apr 2016 16:29:39 +0300, Max Tulyev said: > >> > >>> I need to stop IPv6 web traffic going from our customers to Google > >>> without touching all other IPv6 and without blackhole IPv6 Google > >>> network (this case my customers are complaining on long timeouts). > >>> > >>> What can you advice for that? > >> > >> Umm.. fix the reasons why they're seeing timeouts? :) > >> > >> Have you determined why the timeouts are happening? From fhr at fhrnet.eu Sun Apr 10 14:36:22 2016 From: fhr at fhrnet.eu (Filip Hruska) Date: Sun, 10 Apr 2016 16:36:22 +0200 Subject: Stop IPv6 Google traffic In-Reply-To: <570A62E9.9030802@netassist.ua> References: <867546809.10981.1460297868707.JavaMail.mhammett@ThunderFuck> <570A62E9.9030802@netassist.ua> Message-ID: <570A64E6.9020005@fhrnet.eu> If I'm not mistaken, when there is some "abuse", Google typically shows captcha for the single IPs, not for whole provider, so only the customers who actually do something nefarious should get flagged. Also, if you see captcha while using IPv6, switching to IPv4-only won't solve the problem because if there really is abuse, Google will flag the IPs regardless of IP protocol version. On 04/10/2016 04:27 PM, Max Tulyev wrote: > The problem is IPv6-enabled customers complaints see captcha, and Google > NOC refuses to help solve it saying like find out some of your customer > violating some of our policy. As you can imagine, this is not possible. > > So, the working solutions is either correctly cut IPv6 to Google, or cut > all IPv6 (which I don't want to do). > > On 10.04.16 17:17, Mike Hammett wrote: >> I think the group wants to know what problem you're trying to solve. Obviously if you block something, there will be a timeout in getting to it. >> >> What is broken that you're trying to fix by blackholing them? >> >> >> >> >> ----- >> Mike Hammett >> Intelligent Computing Solutions >> http://www.ics-il.com >> >> >> >> Midwest Internet Exchange >> http://www.midwest-ix.com >> >> >> ----- Original Message ----- >> >> From: "Max Tulyev" >> To: nanog at nanog.org >> Sent: Sunday, April 10, 2016 9:07:47 AM >> Subject: Re: Stop IPv6 Google traffic >> >> Customers see timeouts if I blackhole Google network. I looking for >> alternatives (other than stop providing IPv6 to customers at all). >> >> On 10.04.16 16:50, Valdis.Kletnieks at vt.edu wrote: >>> On Sun, 10 Apr 2016 16:29:39 +0300, Max Tulyev said: >>> >>>> I need to stop IPv6 web traffic going from our customers to Google >>>> without touching all other IPv6 and without blackhole IPv6 Google >>>> network (this case my customers are complaining on long timeouts). >>>> >>>> What can you advice for that? >>> >>> Umm.. fix the reasons why they're seeing timeouts? :) >>> >>> Have you determined why the timeouts are happening? >>> >> >> >> > From maxtul at netassist.ua Sun Apr 10 14:46:34 2016 From: maxtul at netassist.ua (Max Tulyev) Date: Sun, 10 Apr 2016 17:46:34 +0300 Subject: Stop IPv6 Google traffic In-Reply-To: <20160410143543.GA1949@angus.ind.wpi.edu> References: <867546809.10981.1460297868707.JavaMail.mhammett@ThunderFuck> <570A62E9.9030802@netassist.ua> <20160410143543.GA1949@angus.ind.wpi.edu> Message-ID: <570A674A.8020609@netassist.ua> Every have /56 or /48, depending on type of service. All our /32 allocation is affacted. On 10.04.16 17:35, Chuck Anderson wrote: > Assign your customers larger v6 prefixes so one customer's bad > behavior doesn't affect the others? > > On Sun, Apr 10, 2016 at 05:27:53PM +0300, Max Tulyev wrote: >> The problem is IPv6-enabled customers complaints see captcha, and Google >> NOC refuses to help solve it saying like find out some of your customer >> violating some of our policy. As you can imagine, this is not possible. >> >> So, the working solutions is either correctly cut IPv6 to Google, or cut >> all IPv6 (which I don't want to do). >> >> On 10.04.16 17:17, Mike Hammett wrote: >>> I think the group wants to know what problem you're trying to solve. Obviously if you block something, there will be a timeout in getting to it. >>> >>> What is broken that you're trying to fix by blackholing them? >>> >>> >>> >>> >>> ----- >>> Mike Hammett >>> Intelligent Computing Solutions >>> http://www.ics-il.com >>> >>> >>> >>> Midwest Internet Exchange >>> http://www.midwest-ix.com >>> >>> >>> ----- Original Message ----- >>> >>> From: "Max Tulyev" >>> To: nanog at nanog.org >>> Sent: Sunday, April 10, 2016 9:07:47 AM >>> Subject: Re: Stop IPv6 Google traffic >>> >>> Customers see timeouts if I blackhole Google network. I looking for >>> alternatives (other than stop providing IPv6 to customers at all). >>> >>> On 10.04.16 16:50, Valdis.Kletnieks at vt.edu wrote: >>>> On Sun, 10 Apr 2016 16:29:39 +0300, Max Tulyev said: >>>> >>>>> I need to stop IPv6 web traffic going from our customers to Google >>>>> without touching all other IPv6 and without blackhole IPv6 Google >>>>> network (this case my customers are complaining on long timeouts). >>>>> >>>>> What can you advice for that? >>>> >>>> Umm.. fix the reasons why they're seeing timeouts? :) >>>> >>>> Have you determined why the timeouts are happening? > From niels=nanog at bakker.net Sun Apr 10 14:50:22 2016 From: niels=nanog at bakker.net (Niels Bakker) Date: Sun, 10 Apr 2016 16:50:22 +0200 Subject: Stop IPv6 Google traffic In-Reply-To: <570A5543.1030009@netassist.ua> References: <570A5543.1030009@netassist.ua> Message-ID: <20160410145022.GA4087@excession.tpb.net> * maxtul at netassist.ua (Max Tulyev) [Sun 10 Apr 2016, 15:30 CEST]: >I need to stop IPv6 web traffic going from our customers to Google >without touching all other IPv6 and without blackhole IPv6 Google >network (this case my customers are complaining on long timeouts). > >What can you advice for that? You can add a reject route at your borders rather than nullroute. That will cause ICMP Unreachables to be sent by your routers back to your customers so their applications will know immediately to retry using IPv4 rather than waiting for TCP timeouts. Alternatively, you could ask Google to exempt your nameservers from being responded to with AAAA records - something that may happen automatically if v6 connectivity is bad. -- Niels. From nanog at ics-il.net Sun Apr 10 14:51:34 2016 From: nanog at ics-il.net (Mike Hammett) Date: Sun, 10 Apr 2016 09:51:34 -0500 (CDT) Subject: Stop IPv6 Google traffic In-Reply-To: <570A62E9.9030802@netassist.ua> Message-ID: <584117085.11018.1460299891199.JavaMail.mhammett@ThunderFuck> That is the problem with some of these companies. They've gotten just as cocky and arrogant as the incumbent telco providers and won't actually tell you what you're doing wrong, but will punish you for doing wrong. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest Internet Exchange http://www.midwest-ix.com ----- Original Message ----- From: "Max Tulyev" To: nanog at nanog.org Sent: Sunday, April 10, 2016 9:27:53 AM Subject: Re: Stop IPv6 Google traffic The problem is IPv6-enabled customers complaints see captcha, and Google NOC refuses to help solve it saying like find out some of your customer violating some of our policy. As you can imagine, this is not possible. So, the working solutions is either correctly cut IPv6 to Google, or cut all IPv6 (which I don't want to do). On 10.04.16 17:17, Mike Hammett wrote: > I think the group wants to know what problem you're trying to solve. Obviously if you block something, there will be a timeout in getting to it. > > What is broken that you're trying to fix by blackholing them? > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > > > Midwest Internet Exchange > http://www.midwest-ix.com > > > ----- Original Message ----- > > From: "Max Tulyev" > To: nanog at nanog.org > Sent: Sunday, April 10, 2016 9:07:47 AM > Subject: Re: Stop IPv6 Google traffic > > Customers see timeouts if I blackhole Google network. I looking for > alternatives (other than stop providing IPv6 to customers at all). > > On 10.04.16 16:50, Valdis.Kletnieks at vt.edu wrote: >> On Sun, 10 Apr 2016 16:29:39 +0300, Max Tulyev said: >> >>> I need to stop IPv6 web traffic going from our customers to Google >>> without touching all other IPv6 and without blackhole IPv6 Google >>> network (this case my customers are complaining on long timeouts). >>> >>> What can you advice for that? >> >> Umm.. fix the reasons why they're seeing timeouts? :) >> >> Have you determined why the timeouts are happening? >> > > > From chk at pobox.com Sun Apr 10 14:53:34 2016 From: chk at pobox.com (Harald Koch) Date: Sun, 10 Apr 2016 10:53:34 -0400 Subject: Stop IPv6 Google traffic In-Reply-To: <570A64E6.9020005@fhrnet.eu> References: <867546809.10981.1460297868707.JavaMail.mhammett@ThunderFuck> <570A62E9.9030802@netassist.ua> <570A64E6.9020005@fhrnet.eu> Message-ID: On 10 April 2016 at 10:36, Filip Hruska wrote: > If I'm not mistaken, when there is some "abuse", > Google typically shows captcha for the single IPs, not for whole provider, > so only the customers who actually do something nefarious should get > flagged. > You are mistaken. Google flags entire netblocks, more so for IPv6 it seems. From niels=nanog at bakker.net Sun Apr 10 14:56:00 2016 From: niels=nanog at bakker.net (Niels Bakker) Date: Sun, 10 Apr 2016 16:56:00 +0200 Subject: Stop IPv6 Google traffic In-Reply-To: <584117085.11018.1460299891199.JavaMail.mhammett@ThunderFuck> References: <570A62E9.9030802@netassist.ua> <584117085.11018.1460299891199.JavaMail.mhammett@ThunderFuck> Message-ID: <20160410145600.GB4087@excession.tpb.net> * nanog at ics-il.net (Mike Hammett) [Sun 10 Apr 2016, 16:53 CEST]: >That is the problem with some of these companies. They've gotten >just as cocky and arrogant as the incumbent telco providers and >won't actually tell you what you're doing wrong, but will punish you >for doing wrong. I'm happy with them not sharing what exactly other people are doing online when quizzed. -- Niels. From maxtul at netassist.ua Sun Apr 10 15:26:36 2016 From: maxtul at netassist.ua (Max Tulyev) Date: Sun, 10 Apr 2016 18:26:36 +0300 Subject: Stop IPv6 Google traffic In-Reply-To: <20160410145022.GA4087@excession.tpb.net> References: <570A5543.1030009@netassist.ua> <20160410145022.GA4087@excession.tpb.net> Message-ID: <570A70AC.5090208@netassist.ua> Thank you! I think it is what I need now ;) On 10.04.16 17:50, Niels Bakker wrote: > You can add a reject route at your borders rather than nullroute. That > will cause ICMP Unreachables to be sent by your routers back to your > customers so their applications will know immediately to retry using > IPv4 rather than waiting for TCP timeouts. From maxtul at netassist.ua Sun Apr 10 15:29:20 2016 From: maxtul at netassist.ua (Max Tulyev) Date: Sun, 10 Apr 2016 18:29:20 +0300 Subject: Stop IPv6 Google traffic In-Reply-To: <570A64E6.9020005@fhrnet.eu> References: <867546809.10981.1460297868707.JavaMail.mhammett@ThunderFuck> <570A62E9.9030802@netassist.ua> <570A64E6.9020005@fhrnet.eu> Message-ID: <570A7150.9040603@netassist.ua> That was another Google reply, but all /32 still affected. IPv4 is not affected (at least no complaints), so... On 10.04.16 17:36, Filip Hruska wrote: > If I'm not mistaken, when there is some "abuse", > Google typically shows captcha for the single IPs, not for whole > provider, so only the customers who actually do something nefarious > should get flagged. > > Also, if you see captcha while using IPv6, switching to IPv4-only won't > solve the problem because if there really is abuse, Google will flag the > IPs regardless of IP protocol version. > > > > On 04/10/2016 04:27 PM, Max Tulyev wrote: >> The problem is IPv6-enabled customers complaints see captcha, and Google >> NOC refuses to help solve it saying like find out some of your customer >> violating some of our policy. As you can imagine, this is not possible. >> >> So, the working solutions is either correctly cut IPv6 to Google, or cut >> all IPv6 (which I don't want to do). >> >> On 10.04.16 17:17, Mike Hammett wrote: >>> I think the group wants to know what problem you're trying to solve. >>> Obviously if you block something, there will be a timeout in getting >>> to it. >>> >>> What is broken that you're trying to fix by blackholing them? >>> >>> >>> >>> >>> ----- >>> Mike Hammett >>> Intelligent Computing Solutions >>> http://www.ics-il.com >>> >>> >>> >>> Midwest Internet Exchange >>> http://www.midwest-ix.com >>> >>> >>> ----- Original Message ----- >>> >>> From: "Max Tulyev" >>> To: nanog at nanog.org >>> Sent: Sunday, April 10, 2016 9:07:47 AM >>> Subject: Re: Stop IPv6 Google traffic >>> >>> Customers see timeouts if I blackhole Google network. I looking for >>> alternatives (other than stop providing IPv6 to customers at all). >>> >>> On 10.04.16 16:50, Valdis.Kletnieks at vt.edu wrote: >>>> On Sun, 10 Apr 2016 16:29:39 +0300, Max Tulyev said: >>>> >>>>> I need to stop IPv6 web traffic going from our customers to Google >>>>> without touching all other IPv6 and without blackhole IPv6 Google >>>>> network (this case my customers are complaining on long timeouts). >>>>> >>>>> What can you advice for that? >>>> >>>> Umm.. fix the reasons why they're seeing timeouts? :) >>>> >>>> Have you determined why the timeouts are happening? >>>> >>> >>> >>> >> > From A.L.M.Buxey at lboro.ac.uk Sun Apr 10 15:31:00 2016 From: A.L.M.Buxey at lboro.ac.uk (A.L.M.Buxey at lboro.ac.uk) Date: Sun, 10 Apr 2016 15:31:00 +0000 Subject: Stop IPv6 Google traffic In-Reply-To: <570A62E9.9030802@netassist.ua> References: <867546809.10981.1460297868707.JavaMail.mhammett@ThunderFuck> <570A62E9.9030802@netassist.ua> Message-ID: <20160410153100.GA17394@lboro.ac.uk> Hi, > The problem is IPv6-enabled customers complaints see captcha, and Google > NOC refuses to help solve it saying like find out some of your customer > violating some of our policy. As you can imagine, this is not possible. your customers are getting AAAA addresses when looking up google addresses...so their clients are trying to use IPv6 to talk to google..... so doing anything to that traffic - blackholing or just denying it, WILL affect the clients. give clients their own bigger blocks - or identify the clients violating policy (what the policy they are violating?) - you'll probably find the ones getting the captchas are the ones violating! ;-) alan From maxtul at netassist.ua Sun Apr 10 15:37:54 2016 From: maxtul at netassist.ua (Max Tulyev) Date: Sun, 10 Apr 2016 18:37:54 +0300 Subject: Stop IPv6 Google traffic In-Reply-To: <20160410153100.GA17394@lboro.ac.uk> References: <867546809.10981.1460297868707.JavaMail.mhammett@ThunderFuck> <570A62E9.9030802@netassist.ua> <20160410153100.GA17394@lboro.ac.uk> Message-ID: <570A7352.3050309@netassist.ua> That's the problem. Nobody want to say which customer (IP) violates which policy. On 10.04.16 18:31, A.L.M.Buxey at lboro.ac.uk wrote: > give clients their own bigger blocks - or identify the clients violating policy (what the policy > they are violating?) - you'll probably find the ones getting the captchas are the ones violating! ;-) From bruns at 2mbit.com Sun Apr 10 15:50:58 2016 From: bruns at 2mbit.com (Brielle) Date: Sun, 10 Apr 2016 09:50:58 -0600 Subject: Stop IPv6 Google traffic In-Reply-To: <20160410153100.GA17394@lboro.ac.uk> References: <867546809.10981.1460297868707.JavaMail.mhammett@ThunderFuck> <570A62E9.9030802@netassist.ua> <20160410153100.GA17394@lboro.ac.uk> Message-ID: <0573CB0F-9AEB-4B33-B1AF-D1762C905889@2mbit.com> (Sorry about formatting - posting on my phone) Other things might need to make sure of is reverse DNS to differentiate between customers if at all possible, accurate Whois and separate Whois records for static assigned blocks, etc. No guarantees of a fix, but general good practices when this stuff comes up. Sent from my iPhone > On Apr 10, 2016, at 9:31 AM, A.L.M.Buxey at lboro.ac.uk wrote: > > Hi, >> The problem is IPv6-enabled customers complaints see captcha, and Google >> NOC refuses to help solve it saying like find out some of your customer >> violating some of our policy. As you can imagine, this is not possible. > > your customers are getting AAAA addresses when looking up google addresses...so their > clients are trying to use IPv6 to talk to google..... so doing anything to that traffic - blackholing > or just denying it, WILL affect the clients. > > give clients their own bigger blocks - or identify the clients violating policy (what the policy > they are violating?) - you'll probably find the ones getting the captchas are the ones violating! ;-) > > alan From damian at google.com Sun Apr 10 16:52:48 2016 From: damian at google.com (Damian Menscher) Date: Sun, 10 Apr 2016 09:52:48 -0700 Subject: Stop IPv6 Google traffic In-Reply-To: <570A674A.8020609@netassist.ua> References: <867546809.10981.1460297868707.JavaMail.mhammett@ThunderFuck> <570A62E9.9030802@netassist.ua> <20160410143543.GA1949@angus.ind.wpi.edu> <570A674A.8020609@netassist.ua> Message-ID: Sorry to hear your legitimate users are impacted by captchas when trying to use Google web search. This can happen when you have significant amounts of abuse coming from your network. If switching to IPv4 means having more users share IPs, it could make the problem worse. Instead, let's try to quickly address the IPv6 issue. Please send me your IP allocation policy (off-list is fine). For example (guessing from the list at http://bgp.he.net/search?search%5Bsearch%5D=netassist&commit=Search): - 2a01:d0::/32 is allocated by /48 - 2a01:d0:8000::/33 is allocated by /56 - 2001:67c:1874::/48 is allocated by /64 - ... etc (IPv4 allocation is appreciated as well, if you also provide customers with large ranges there) I can then give that hint to our automated abuse systems, which will both make it easier for us to catch your abusive customers, and also to avoid over-blocking of your AS. Damian -- Damian Menscher :: Security Reliability Engineer :: Google :: AS15169 On Sun, Apr 10, 2016 at 7:46 AM, Max Tulyev wrote: > Every have /56 or /48, depending on type of service. All our /32 > allocation is affacted. > > On 10.04.16 17:35, Chuck Anderson wrote: > > Assign your customers larger v6 prefixes so one customer's bad > > behavior doesn't affect the others? > > > > On Sun, Apr 10, 2016 at 05:27:53PM +0300, Max Tulyev wrote: > >> The problem is IPv6-enabled customers complaints see captcha, and Google > >> NOC refuses to help solve it saying like find out some of your customer > >> violating some of our policy. As you can imagine, this is not possible. > >> > >> So, the working solutions is either correctly cut IPv6 to Google, or cut > >> all IPv6 (which I don't want to do). > >> > >> On 10.04.16 17:17, Mike Hammett wrote: > >>> I think the group wants to know what problem you're trying to solve. > Obviously if you block something, there will be a timeout in getting to it. > >>> > >>> What is broken that you're trying to fix by blackholing them? > >>> > >>> > >>> > >>> > >>> ----- > >>> Mike Hammett > >>> Intelligent Computing Solutions > >>> http://www.ics-il.com > >>> > >>> > >>> > >>> Midwest Internet Exchange > >>> http://www.midwest-ix.com > >>> > >>> > >>> ----- Original Message ----- > >>> > >>> From: "Max Tulyev" > >>> To: nanog at nanog.org > >>> Sent: Sunday, April 10, 2016 9:07:47 AM > >>> Subject: Re: Stop IPv6 Google traffic > >>> > >>> Customers see timeouts if I blackhole Google network. I looking for > >>> alternatives (other than stop providing IPv6 to customers at all). > >>> > >>> On 10.04.16 16:50, Valdis.Kletnieks at vt.edu wrote: > >>>> On Sun, 10 Apr 2016 16:29:39 +0300, Max Tulyev said: > >>>> > >>>>> I need to stop IPv6 web traffic going from our customers to Google > >>>>> without touching all other IPv6 and without blackhole IPv6 Google > >>>>> network (this case my customers are complaining on long timeouts). > >>>>> > >>>>> What can you advice for that? > >>>> > >>>> Umm.. fix the reasons why they're seeing timeouts? :) > >>>> > >>>> Have you determined why the timeouts are happening? > > > > From bzs at theworld.com Sun Apr 10 19:33:43 2016 From: bzs at theworld.com (bzs at theworld.com) Date: Sun, 10 Apr 2016 15:33:43 -0400 Subject: Stop IPv6 Google traffic In-Reply-To: <60483.1460296213@turing-police.cc.vt.edu> References: <570A5543.1030009@netassist.ua> <60483.1460296213@turing-police.cc.vt.edu> Message-ID: <22282.43671.253407.6403@pcls8.std.com> Ya know, this is the problem with this kind of list groupthink. Who cares what his motivations are unless he asks for help with that underlying problem? Do you (plural, whoever is replying) know the answer to his question or where to find the answer or not? It seems like every technical list is over-run with meta-conversations, how do I (blah), WHY WOULD YOU WANT TO (blah)?!?! Often in a sort of accusatory tone, only someone dumb would want to (blah)! I think the answer is to disable IPv6 in the web server config or startup (see flags) but hey I just thought I would meta the meta. Sorry but I went through about an hour of looking for some way to trace systemd and all I found on various lists in answer to others asking the same thing was why would you want to trace systemd? Is this a standard package causing problems if not then use the standard package and if there is none then don't use that software (wow what a good answer...not), or a lot of "it must just be something simple you don't need to trace anything" (which was probably true but kind of useless.) -- -Barry Shein Software Tool & Die | bzs at TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: +1 617-STD-WRLD | 800-THE-WRLD The World: Since 1989 | A Public Information Utility | *oo* From josh at imaginenetworksllc.com Sun Apr 10 19:44:36 2016 From: josh at imaginenetworksllc.com (Josh Luthman) Date: Sun, 10 Apr 2016 15:44:36 -0400 Subject: Stop IPv6 Google traffic In-Reply-To: <22282.43671.253407.6403@pcls8.std.com> References: <570A5543.1030009@netassist.ua> <60483.1460296213@turing-police.cc.vt.edu> <22282.43671.253407.6403@pcls8.std.com> Message-ID: On the flip side of things instead of putting a bandaid on the burn it is better to stop putting your hand in the fire. Nothing wrong with some discussion. Josh Luthman Office: 937-552-2340 Direct: 937-552-2343 1100 Wayne St Suite 1337 Troy, OH 45373 On Sun, Apr 10, 2016 at 3:33 PM, wrote: > > > > Ya know, this is the problem with this kind of list groupthink. > > Who cares what his motivations are unless he asks for help with that > underlying problem? > > Do you (plural, whoever is replying) know the answer to his question > or where to find the answer or not? > > It seems like every technical list is over-run with > meta-conversations, how do I (blah), WHY WOULD YOU WANT TO (blah)?!?! > > Often in a sort of accusatory tone, only someone dumb would want to > (blah)! > > I think the answer is to disable IPv6 in the web server config or > startup (see flags) but hey I just thought I would meta the meta. > > Sorry but I went through about an hour of looking for some way to > trace systemd and all I found on various lists in answer to others > asking the same thing was why would you want to trace systemd? Is this > a standard package causing problems if not then use the standard > package and if there is none then don't use that software (wow what a > good answer...not), or a lot of "it must just be something simple you > don't need to trace anything" (which was probably true but kind of > useless.) > > > > -- > -Barry Shein > > Software Tool & Die | bzs at TheWorld.com | > http://www.TheWorld.com > Purveyors to the Trade | Voice: +1 617-STD-WRLD | 800-THE-WRLD > The World: Since 1989 | A Public Information Utility | *oo* > From baldur.norddahl at gmail.com Sun Apr 10 20:28:00 2016 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Sun, 10 Apr 2016 22:28:00 +0200 Subject: Stop IPv6 Google traffic In-Reply-To: <22282.43671.253407.6403@pcls8.std.com> References: <570A5543.1030009@netassist.ua> <60483.1460296213@turing-police.cc.vt.edu> <22282.43671.253407.6403@pcls8.std.com> Message-ID: On 10 April 2016 at 21:33, wrote: > > > > Ya know, this is the problem with this kind of list groupthink. > > Who cares what his motivations are unless he asks for help with that > underlying problem? > But you are clearly wrong. Because he got asked and then told us what the underlying problem was, he got in touch with the correct guy at Google that will now fix his problem the right way. Your way everyone would have ended up in a worse shape. Also we are not just here to show of our vast knowledge, but to learn. Some of us would want to know why one would want to disable IPv6 for Google. Maybe our own network has the same issues. And I for one would not want the "block Google" solution. We already registered our customer allocation size of /48 in the RIPE database, so I hope Google will pick that up automatically. Regards, Baldur From Valdis.Kletnieks at vt.edu Sun Apr 10 20:34:14 2016 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Sun, 10 Apr 2016 16:34:14 -0400 Subject: Stop IPv6 Google traffic In-Reply-To: <22282.43671.253407.6403@pcls8.std.com> References: <570A5543.1030009@netassist.ua> <60483.1460296213@turing-police.cc.vt.edu> <22282.43671.253407.6403@pcls8.std.com> Message-ID: <91912.1460320454@turing-police.cc.vt.edu> On Sun, 10 Apr 2016 15:33:43 -0400, bzs at theworld.com said: > > > > Ya know, this is the problem with this kind of list groupthink. > > Who cares what his motivations are unless he asks for help with that > underlying problem? Because when people apply band-aid solutions rather than fixing the *real* problem, it usually ends up making other people's phones ring. You've been around long enough to remember the hassles when ECN started showing up in gear. Who got the phone calls, the owner of the firewall that didn't know about ECN, or the provider where the ECN originated? Repeat the discussion for PMTU discovery. And for a *lot* of other instances. And then there's the other elephant in the room - if Google is throwing back captchas because it thinks there's a problem, the original poster's abuse desk may want to deal with the underlying issue. Maybe his network has real abuse problems they should deal with, maybe he's just got a wonky configuration that makes it *look* like he has a problem. I have no clue which - but it's a fair bet that if Google *thinks* there's an issue, the original poster needs to fix the *real* problem, or they will be stuck playing whack-a-mole with other sites that draw the same conclusions as Google did. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From alter3d at alter3d.ca Sun Apr 10 21:00:15 2016 From: alter3d at alter3d.ca (Peter Kristolaitis) Date: Sun, 10 Apr 2016 17:00:15 -0400 Subject: Stop IPv6 Google traffic In-Reply-To: <22282.43671.253407.6403@pcls8.std.com> References: <570A5543.1030009@netassist.ua> <60483.1460296213@turing-police.cc.vt.edu> <22282.43671.253407.6403@pcls8.std.com> Message-ID: <570ABEDF.3090800@alter3d.ca> I don't think it's "groupthink" so much as it is "the mark of experienced tech people who are good at their job". At $DAYJOB, a HUGE part of my time is spent as a "technical firewall" -- stopping the company from blindly implementing something based on incomplete information. When someone comes to me and says "I need to do $X in the dev/QA/prod environment", my first question is "What are you trying to accomplish?" A good percentage of the time, it turns out that Group A didn't talk to Group B, and the requirements were misunderstood -- after discussion, we end up NOT implenting their original request, and either implement it in a different way, implement a solution to a completely different problem, or do nothing at all. All of the really good technical people I know have learned to do this through experience, and the habit of asking "What are you REALLY trying to do here?" is ingrained in their response to any question. The only thing worse than a half-baked question is running full tilt into a wall with a half-baked solution to a half-baked question. - Peter On 4/10/2016 3:33 PM, bzs at theworld.com wrote: > > > Ya know, this is the problem with this kind of list groupthink. > > Who cares what his motivations are unless he asks for help with that > underlying problem? > > Do you (plural, whoever is replying) know the answer to his question > or where to find the answer or not? > > It seems like every technical list is over-run with > meta-conversations, how do I (blah), WHY WOULD YOU WANT TO (blah)?!?! > > Often in a sort of accusatory tone, only someone dumb would want to > (blah)! > > I think the answer is to disable IPv6 in the web server config or > startup (see flags) but hey I just thought I would meta the meta. > > Sorry but I went through about an hour of looking for some way to > trace systemd and all I found on various lists in answer to others > asking the same thing was why would you want to trace systemd? Is this > a standard package causing problems if not then use the standard > package and if there is none then don't use that software (wow what a > good answer...not), or a lot of "it must just be something simple you > don't need to trace anything" (which was probably true but kind of > useless.) > > > From jlewis at lewis.org Sun Apr 10 21:48:33 2016 From: jlewis at lewis.org (Jon Lewis) Date: Sun, 10 Apr 2016 17:48:33 -0400 (EDT) Subject: Stop IPv6 Google traffic In-Reply-To: <570A5543.1030009@netassist.ua> References: <570A5543.1030009@netassist.ua> Message-ID: On Sun, 10 Apr 2016, Max Tulyev wrote: > Hi All, > > I need to stop IPv6 web traffic going from our customers to Google > without touching all other IPv6 and without blackhole IPv6 Google > network (this case my customers are complaining on long timeouts). > > What can you advice for that? Just use Cogent transit for IPv6. Problem solved. :) ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route | therefore you are _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From rubensk at gmail.com Mon Apr 11 00:09:04 2016 From: rubensk at gmail.com (Rubens Kuhl) Date: Sun, 10 Apr 2016 21:09:04 -0300 Subject: Stop IPv6 Google traffic In-Reply-To: <570A5543.1030009@netassist.ua> References: <570A5543.1030009@netassist.ua> Message-ID: On Sun, Apr 10, 2016 at 10:29 AM, Max Tulyev wrote: > Hi All, > > I need to stop IPv6 web traffic going from our customers to Google > without touching all other IPv6 and without blackhole IPv6 Google > network (this case my customers are complaining on long timeouts). > > What can you advice for that? > If your users are seeing captchas, one or a few or them are likely to be infected to the point of generating too much requests to Google. Flow-based analysis might reveal who those users are. Rubens From bjorn at mork.no Mon Apr 11 10:05:11 2016 From: bjorn at mork.no (=?utf-8?Q?Bj=C3=B8rn_Mork?=) Date: Mon, 11 Apr 2016 12:05:11 +0200 Subject: Stop IPv6 Google traffic In-Reply-To: <22282.43671.253407.6403@pcls8.std.com> (bzs@theworld.com's message of "Sun, 10 Apr 2016 15:33:43 -0400") References: <570A5543.1030009@netassist.ua> <60483.1460296213@turing-police.cc.vt.edu> <22282.43671.253407.6403@pcls8.std.com> Message-ID: <87bn5gjwa0.fsf@nemi.mork.no> bzs at theworld.com writes: > It seems like every technical list is over-run with > meta-conversations, how do I (blah), WHY WOULD YOU WANT TO (blah)?!?! It is reasonable to expect anyone asking for help to describe the process leading up to the situation where they are stuck. I'd say it is rare that such an explanation can be given without describing the original problem. If you are worrying about these meta discussions, then I'd suggest killng them off in the first place by simply answering the questions before they are asked. Bj?rn From cboyd at gizmopartners.com Mon Apr 11 16:55:11 2016 From: cboyd at gizmopartners.com (Chris Boyd) Date: Mon, 11 Apr 2016 11:55:11 -0500 Subject: GeoIP database issues and the real world consequences Message-ID: <1460393711.14814.2.camel@beagle> Interesting article. http://fusion.net/story/287592/internet-mapping-glitch-kansas-farm/ An hour?s drive from Wichita, Kansas, in a little town called Potwin, there is a 360-acre piece of land with a very big problem. The plot has been owned by the Vogelman family for more than a hundred years, though the current owner, Joyce Taylor n?e Vogelman, 82, now rents it out. The acreage is quiet and remote: a farm, a pasture, an old orchard, two barns, some hog shacks and a two-story house. It?s the kind of place you move to if you want to get away from it all. The nearest neighbor is a mile away, and the closest big town has just 13,000 people. It is real, rural America; in fact, it?s a two-hour drive from the exact geographical center of the United States. But instead of being a place of respite, the people who live on Joyce Taylor?s land find themselves in a technological horror story. For the last decade, Taylor and her renters have been visited by all kinds of mysterious trouble. They?ve been accused of being identity thieves, spammers, scammers and fraudsters. They?ve gotten visited by FBI agents, federal marshals, IRS collectors, ambulances searching for suicidal veterans, and police officers searching for runaway children. They?ve found people scrounging around in their barn. The renters have been doxxed, their names and addresses posted on the internet by vigilantes. Once, someone left a broken toilet in the driveway as a strange, indefinite threat. --Chris From math at sizone.org Mon Apr 11 17:02:14 2016 From: math at sizone.org (Ken Chase) Date: Mon, 11 Apr 2016 13:02:14 -0400 Subject: GeoIP database issues and the real world consequences In-Reply-To: <1460393711.14814.2.camel@beagle> References: <1460393711.14814.2.camel@beagle> Message-ID: <20160411170214.GF26501@sizone.org> TL;DR: GeoIP put unknown IP location mappings to the 'center of the country' but then rounded off the lat long so it points at this farm. Cant believe law enforcement is using this kind of info to execute searches. Wouldnt that undermine the credibility of any evidence brought up in trials for any geoip locates? Seems to me locating unknowns somewhere in the middle of a big lake or park in the center of the country might be a better idea. /kc On Mon, Apr 11, 2016 at 11:55:11AM -0500, Chris Boyd said: > >Interesting article. > >http://fusion.net/story/287592/internet-mapping-glitch-kansas-farm/ > >An hour???s drive from Wichita, Kansas, in a little town called Potwin, >there is a 360-acre piece of land with a very big problem. > >The plot has been owned by the Vogelman family for more than a hundred >years, though the current owner, Joyce Taylor n??e Vogelman, 82, now >rents it out. The acreage is quiet and remote: a farm, a pasture, an old >orchard, two barns, some hog shacks and a two-story house. It???s the kind >of place you move to if you want to get away from it all. The nearest >neighbor is a mile away, and the closest big town has just 13,000 >people. It is real, rural America; in fact, it???s a two-hour drive from >the exact geographical center of the United States. > >But instead of being a place of respite, the people who live on Joyce >Taylor???s land find themselves in a technological horror story. > > >For the last decade, Taylor and her renters have been visited by all >kinds of mysterious trouble. They???ve been accused of being identity >thieves, spammers, scammers and fraudsters. They???ve gotten visited by >FBI agents, federal marshals, IRS collectors, ambulances searching for >suicidal veterans, and police officers searching for runaway children. >They???ve found people scrounging around in their barn. The renters have >been doxxed, their names and addresses posted on the internet by >vigilantes. Once, someone left a broken toilet in the driveway as a >strange, indefinite threat. > >--Chris > From hugo at slabnet.com Mon Apr 11 17:11:40 2016 From: hugo at slabnet.com (Hugo Slabbert) Date: Mon, 11 Apr 2016 10:11:40 -0700 Subject: GeoIP database issues and the real world consequences In-Reply-To: <20160411170214.GF26501@sizone.org> References: <1460393711.14814.2.camel@beagle> <20160411170214.GF26501@sizone.org> Message-ID: <20160411171140.GA9284@bamboo.slabnet.com> On Mon 2016-Apr-11 13:02:14 -0400, Ken Chase wrote: >TL;DR: GeoIP put unknown IP location mappings to the 'center of the country' >but then rounded off the lat long so it points at this farm. > >Cant believe law enforcement is using this kind of info to execute searches. >Wouldnt that undermine the credibility of any evidence brought up in trials >for any geoip locates? > >Seems to me locating unknowns somewhere in the middle of a big lake or park in >the center of the country might be a better idea. ...how about actually marking an unknown as...oh, I dunno: "unknown"? Is there no analogue in the GeoIP lookups for a 404? > >/kc -- Hugo Slabbert | email, xmpp/jabber: hugo at slabnet.com pgp key: B178313E | also on Signal > >On Mon, Apr 11, 2016 at 11:55:11AM -0500, Chris Boyd said: > > > >Interesting article. > > > >http://fusion.net/story/287592/internet-mapping-glitch-kansas-farm/ > > > >An hour???s drive from Wichita, Kansas, in a little town called Potwin, > >there is a 360-acre piece of land with a very big problem. > > > >The plot has been owned by the Vogelman family for more than a hundred > >years, though the current owner, Joyce Taylor n??e Vogelman, 82, now > >rents it out. The acreage is quiet and remote: a farm, a pasture, an old > >orchard, two barns, some hog shacks and a two-story house. It???s the kind > >of place you move to if you want to get away from it all. The nearest > >neighbor is a mile away, and the closest big town has just 13,000 > >people. It is real, rural America; in fact, it???s a two-hour drive from > >the exact geographical center of the United States. > > > >But instead of being a place of respite, the people who live on Joyce > >Taylor???s land find themselves in a technological horror story. > > > > > >For the last decade, Taylor and her renters have been visited by all > >kinds of mysterious trouble. They???ve been accused of being identity > >thieves, spammers, scammers and fraudsters. They???ve gotten visited by > >FBI agents, federal marshals, IRS collectors, ambulances searching for > >suicidal veterans, and police officers searching for runaway children. > >They???ve found people scrounging around in their barn. The renters have > >been doxxed, their names and addresses posted on the internet by > >vigilantes. Once, someone left a broken toilet in the driveway as a > >strange, indefinite threat. > > > >--Chris > > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: From josh at imaginenetworksllc.com Mon Apr 11 17:14:37 2016 From: josh at imaginenetworksllc.com (Josh Luthman) Date: Mon, 11 Apr 2016 13:14:37 -0400 Subject: GeoIP database issues and the real world consequences In-Reply-To: <20160411171140.GA9284@bamboo.slabnet.com> References: <1460393711.14814.2.camel@beagle> <20160411170214.GF26501@sizone.org> <20160411171140.GA9284@bamboo.slabnet.com> Message-ID: Or 0,0, send the FBI to Africa on a boating trip. that would probably be easier than "unknown" or "null". Josh Luthman Office: 937-552-2340 Direct: 937-552-2343 1100 Wayne St Suite 1337 Troy, OH 45373 On Mon, Apr 11, 2016 at 1:11 PM, Hugo Slabbert wrote: > > On Mon 2016-Apr-11 13:02:14 -0400, Ken Chase wrote: > > TL;DR: GeoIP put unknown IP location mappings to the 'center of the >> country' >> but then rounded off the lat long so it points at this farm. >> >> Cant believe law enforcement is using this kind of info to execute >> searches. >> Wouldnt that undermine the credibility of any evidence brought up in >> trials >> for any geoip locates? >> >> Seems to me locating unknowns somewhere in the middle of a big lake or >> park in >> the center of the country might be a better idea. >> > > ...how about actually marking an unknown as...oh, I dunno: "unknown"? Is > there no analogue in the GeoIP lookups for a 404? > > >> /kc >> > > -- > Hugo Slabbert | email, xmpp/jabber: hugo at slabnet.com > pgp key: B178313E | also on Signal > > > >> On Mon, Apr 11, 2016 at 11:55:11AM -0500, Chris Boyd said: >> > >> >Interesting article. >> > >> >http://fusion.net/story/287592/internet-mapping-glitch-kansas-farm/ >> > >> >An hour???s drive from Wichita, Kansas, in a little town called Potwin, >> >there is a 360-acre piece of land with a very big problem. >> > >> >The plot has been owned by the Vogelman family for more than a hundred >> >years, though the current owner, Joyce Taylor n??e Vogelman, 82, now >> >rents it out. The acreage is quiet and remote: a farm, a pasture, an old >> >orchard, two barns, some hog shacks and a two-story house. It???s the >> kind >> >of place you move to if you want to get away from it all. The nearest >> >neighbor is a mile away, and the closest big town has just 13,000 >> >people. It is real, rural America; in fact, it???s a two-hour drive from >> >the exact geographical center of the United States. >> > >> >But instead of being a place of respite, the people who live on Joyce >> >Taylor???s land find themselves in a technological horror story. >> > >> > >> >For the last decade, Taylor and her renters have been visited by all >> >kinds of mysterious trouble. They???ve been accused of being identity >> >thieves, spammers, scammers and fraudsters. They???ve gotten visited by >> >FBI agents, federal marshals, IRS collectors, ambulances searching for >> >suicidal veterans, and police officers searching for runaway children. >> >They???ve found people scrounging around in their barn. The renters have >> >been doxxed, their names and addresses posted on the internet by >> >vigilantes. Once, someone left a broken toilet in the driveway as a >> >strange, indefinite threat. >> > >> >--Chris >> > >> > From blair.trosper at gmail.com Mon Apr 11 17:16:02 2016 From: blair.trosper at gmail.com (Blair Trosper) Date: Mon, 11 Apr 2016 10:16:02 -0700 Subject: GeoIP database issues and the real world consequences In-Reply-To: <1460393711.14814.2.camel@beagle> References: <1460393711.14814.2.camel@beagle> Message-ID: Has happened in Atlanta, too, due to (what I think) was a lookup on the ASN's whois, which wasn't specific: http://fusion.net/story/214995/find-my-phone-apps-lead-to-wrong-home/ On Mon, Apr 11, 2016 at 9:55 AM, Chris Boyd wrote: > > Interesting article. > > http://fusion.net/story/287592/internet-mapping-glitch-kansas-farm/ > > An hour?s drive from Wichita, Kansas, in a little town called Potwin, > there is a 360-acre piece of land with a very big problem. > > The plot has been owned by the Vogelman family for more than a hundred > years, though the current owner, Joyce Taylor n?e Vogelman, 82, now > rents it out. The acreage is quiet and remote: a farm, a pasture, an old > orchard, two barns, some hog shacks and a two-story house. It?s the kind > of place you move to if you want to get away from it all. The nearest > neighbor is a mile away, and the closest big town has just 13,000 > people. It is real, rural America; in fact, it?s a two-hour drive from > the exact geographical center of the United States. > > But instead of being a place of respite, the people who live on Joyce > Taylor?s land find themselves in a technological horror story. > > > For the last decade, Taylor and her renters have been visited by all > kinds of mysterious trouble. They?ve been accused of being identity > thieves, spammers, scammers and fraudsters. They?ve gotten visited by > FBI agents, federal marshals, IRS collectors, ambulances searching for > suicidal veterans, and police officers searching for runaway children. > They?ve found people scrounging around in their barn. The renters have > been doxxed, their names and addresses posted on the internet by > vigilantes. Once, someone left a broken toilet in the driveway as a > strange, indefinite threat. > > --Chris > From math at sizone.org Mon Apr 11 17:22:43 2016 From: math at sizone.org (Ken Chase) Date: Mon, 11 Apr 2016 13:22:43 -0400 Subject: GeoIP database issues and the real world consequences In-Reply-To: References: <1460393711.14814.2.camel@beagle> <20160411170214.GF26501@sizone.org> <20160411171140.GA9284@bamboo.slabnet.com> Message-ID: <20160411172243.GG26501@sizone.org> Well they DO know the IP location is within the USA - many apps use the GeoIP API and require a lat/long returned, and some need one that lands within a country border (thus my suggestion of middle of a remote wilderness park - let the cops search some desolate remote desert in nevada amirite?) MaxMind might not want the quality hit for a 0,0 answer (as funny as that would be). (my 'middle of a lake in the middle of the country' retains some of that mischievous win however.) /kc On Mon, Apr 11, 2016 at 01:14:37PM -0400, Josh Luthman said: >Or 0,0, send the FBI to Africa on a boating trip. that would probably be >easier than "unknown" or "null". > > >Josh Luthman >Office: 937-552-2340 >Direct: 937-552-2343 >1100 Wayne St >Suite 1337 >Troy, OH 45373 > >On Mon, Apr 11, 2016 at 1:11 PM, Hugo Slabbert wrote: > >> >> On Mon 2016-Apr-11 13:02:14 -0400, Ken Chase wrote: >> >> TL;DR: GeoIP put unknown IP location mappings to the 'center of the >>> country' >>> but then rounded off the lat long so it points at this farm. >>> >>> Cant believe law enforcement is using this kind of info to execute >>> searches. >>> Wouldnt that undermine the credibility of any evidence brought up in >>> trials >>> for any geoip locates? >>> >>> Seems to me locating unknowns somewhere in the middle of a big lake or >>> park in >>> the center of the country might be a better idea. >>> >> >> ...how about actually marking an unknown as...oh, I dunno: "unknown"? Is >> there no analogue in the GeoIP lookups for a 404? >> >> >>> /kc >>> >> >> -- >> Hugo Slabbert | email, xmpp/jabber: hugo at slabnet.com >> pgp key: B178313E | also on Signal >> >> >> >>> On Mon, Apr 11, 2016 at 11:55:11AM -0500, Chris Boyd said: >>> > >>> >Interesting article. >>> > >>> >http://fusion.net/story/287592/internet-mapping-glitch-kansas-farm/ >>> > >>> >An hour???s drive from Wichita, Kansas, in a little town called Potwin, >>> >there is a 360-acre piece of land with a very big problem. >>> > >>> >The plot has been owned by the Vogelman family for more than a hundred >>> >years, though the current owner, Joyce Taylor n??e Vogelman, 82, now >>> >rents it out. The acreage is quiet and remote: a farm, a pasture, an old >>> >orchard, two barns, some hog shacks and a two-story house. It???s the >>> kind >>> >of place you move to if you want to get away from it all. The nearest >>> >neighbor is a mile away, and the closest big town has just 13,000 >>> >people. It is real, rural America; in fact, it???s a two-hour drive from >>> >the exact geographical center of the United States. >>> > >>> >But instead of being a place of respite, the people who live on Joyce >>> >Taylor???s land find themselves in a technological horror story. >>> > >>> > >>> >For the last decade, Taylor and her renters have been visited by all >>> >kinds of mysterious trouble. They???ve been accused of being identity >>> >thieves, spammers, scammers and fraudsters. They???ve gotten visited by >>> >FBI agents, federal marshals, IRS collectors, ambulances searching for >>> >suicidal veterans, and police officers searching for runaway children. >>> >They???ve found people scrounging around in their barn. The renters have >>> >been doxxed, their names and addresses posted on the internet by >>> >vigilantes. Once, someone left a broken toilet in the driveway as a >>> >strange, indefinite threat. >>> > >>> >--Chris >>> > >>> >> From steve at blighty.com Mon Apr 11 17:26:36 2016 From: steve at blighty.com (Steve Atkins) Date: Mon, 11 Apr 2016 10:26:36 -0700 Subject: GeoIP database issues and the real world consequences In-Reply-To: <20160411171140.GA9284@bamboo.slabnet.com> References: <1460393711.14814.2.camel@beagle> <20160411170214.GF26501@sizone.org> <20160411171140.GA9284@bamboo.slabnet.com> Message-ID: <59B0E3A0-DF5F-4C9E-8068-54A3B0800DFE@blighty.com> > On Apr 11, 2016, at 10:11 AM, Hugo Slabbert wrote: > > > On Mon 2016-Apr-11 13:02:14 -0400, Ken Chase wrote: > >> TL;DR: GeoIP put unknown IP location mappings to the 'center of the country' >> but then rounded off the lat long so it points at this farm. >> >> Cant believe law enforcement is using this kind of info to execute searches. >> Wouldnt that undermine the credibility of any evidence brought up in trials >> for any geoip locates? >> >> Seems to me locating unknowns somewhere in the middle of a big lake or park in >> the center of the country might be a better idea. > > ...how about actually marking an unknown as...oh, I dunno: "unknown"? Is there no analogue in the GeoIP lookups for a 404? It's not unknown - it's (according to the DB, anyway, which has a bunch of flaws) "in the US somewhere". The problem with MaxMind (and other geoip databases I've seen that do Lat/Long as well as Country / State / Town) is that the data doesn't include uncertainty, so it returns "38.0/-97.0" rather than "somewhere in a 3000 mile radius circle centered on 38.0/-97.0". Someone should show them RFC 1876 as an example of better practice. Cheers, Steve From Steve.Mikulasik at civeo.com Mon Apr 11 17:34:35 2016 From: Steve.Mikulasik at civeo.com (Steve Mikulasik) Date: Mon, 11 Apr 2016 17:34:35 +0000 Subject: GeoIP database issues and the real world consequences In-Reply-To: <1460393711.14814.2.camel@beagle> References: <1460393711.14814.2.camel@beagle> Message-ID: Just so everyone is clear, Maxmind is changing their default locations. " Now that I?ve made MaxMind aware of the consequences of the default locations it?s chosen, Mather says they?re going to change them. They are picking new default locations for the U.S. and Ashburn, Virginia that are in the middle of bodies of water, rather than people?s homes." From nanog at ics-il.net Mon Apr 11 17:38:31 2016 From: nanog at ics-il.net (Mike Hammett) Date: Mon, 11 Apr 2016 12:38:31 -0500 (CDT) Subject: GeoIP database issues and the real world consequences In-Reply-To: Message-ID: <90136824.12309.1460396310889.JavaMail.mhammett@ThunderFuck> So they launch exhaustive and expensive searches of lakes instead? :-) ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest Internet Exchange http://www.midwest-ix.com ----- Original Message ----- From: "Steve Mikulasik" To: nanog at nanog.org Sent: Monday, April 11, 2016 12:34:35 PM Subject: RE: GeoIP database issues and the real world consequences Just so everyone is clear, Maxmind is changing their default locations. " Now that I?ve made MaxMind aware of the consequences of the default locations it?s chosen, Mather says they?re going to change them. They are picking new default locations for the U.S. and Ashburn, Virginia that are in the middle of bodies of water, rather than people?s homes." From jared at puck.nether.net Mon Apr 11 17:38:54 2016 From: jared at puck.nether.net (Jared Mauch) Date: Mon, 11 Apr 2016 13:38:54 -0400 Subject: GeoIP database issues and the real world consequences In-Reply-To: References: <1460393711.14814.2.camel@beagle> Message-ID: <3E760951-D076-47F7-890B-31ECBEEB07E7@puck.nether.net> > On Apr 11, 2016, at 1:34 PM, Steve Mikulasik wrote: > > Just so everyone is clear, Maxmind is changing their default locations. > > " Now that I?ve made MaxMind aware of the consequences of the default locations it?s chosen, Mather says they?re going to change them. They are picking new default locations for the U.S. and Ashburn, Virginia that are in the middle of bodies of water, rather than people?s homes." The middle of lake superior and hudson bay would be good choices for the US and Canada. Quick, run a commercial diving team with on-call at the nearest ports. - Jared From Steve.Mikulasik at civeo.com Mon Apr 11 17:42:33 2016 From: Steve.Mikulasik at civeo.com (Steve Mikulasik) Date: Mon, 11 Apr 2016 17:42:33 +0000 Subject: GeoIP database issues and the real world consequences In-Reply-To: <90136824.12309.1460396310889.JavaMail.mhammett@ThunderFuck> References: <90136824.12309.1460396310889.JavaMail.mhammett@ThunderFuck> Message-ID: I imagine it might look something like this http://i.imgur.com/HlpOXP0.jpg -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Mike Hammett Sent: Monday, April 11, 2016 11:39 AM Cc: nanog at nanog.org Subject: Re: GeoIP database issues and the real world consequences So they launch exhaustive and expensive searches of lakes instead? :-) ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest Internet Exchange http://www.midwest-ix.com ----- Original Message ----- From: "Steve Mikulasik" To: nanog at nanog.org Sent: Monday, April 11, 2016 12:34:35 PM Subject: RE: GeoIP database issues and the real world consequences Just so everyone is clear, Maxmind is changing their default locations. " Now that I?ve made MaxMind aware of the consequences of the default locations it?s chosen, Mather says they?re going to change them. They are picking new default locations for the U.S. and Ashburn, Virginia that are in the middle of bodies of water, rather than people?s homes." From johnl at iecc.com Mon Apr 11 17:56:48 2016 From: johnl at iecc.com (John Levine) Date: 11 Apr 2016 17:56:48 -0000 Subject: GeoIP database issues and the real world consequences In-Reply-To: <90136824.12309.1460396310889.JavaMail.mhammett@ThunderFuck> Message-ID: <20160411175648.60253.qmail@ary.lan> In article <90136824.12309.1460396310889.JavaMail.mhammett at ThunderFuck> you write: >So they launch exhaustive and expensive searches of lakes instead? :-) I'm starting a new chain of kiosks that rent wet suits and snorkels. R's, John From johnl at iecc.com Mon Apr 11 18:15:08 2016 From: johnl at iecc.com (John Levine) Date: 11 Apr 2016 18:15:08 -0000 Subject: GeoIP database issues and the real world consequences In-Reply-To: <59B0E3A0-DF5F-4C9E-8068-54A3B0800DFE@blighty.com> Message-ID: <20160411181508.60367.qmail@ary.lan> >The problem with MaxMind (and other geoip databases I've seen that do Lat/Long as well as Country / State / Town) is that the >data doesn't include uncertainty, so it returns "38.0/-97.0" rather than "somewhere in a 3000 mile radius circle centered on >38.0/-97.0". > >Someone should show them RFC 1876 as an example of better practice. Oh, heck, you know better than that. You can put in all the flags and warnings you want, but if it returns an address, nitwits will show up at the address with guns. Bodies of water probably are the least bad alternative. I wonder if they're going to hydrolocate all of the unknown addresses, or only the ones where they get publically shamed. R's, John From owen at delong.com Mon Apr 11 18:18:43 2016 From: owen at delong.com (Owen DeLong) Date: Mon, 11 Apr 2016 11:18:43 -0700 Subject: how to deal with port scan and brute force attack from AS 8075 ? In-Reply-To: References: <56FCD97D.8050201@yahoo.fr> <3B53B9D6-BAA3-48C9-82A7-049CC9049269@n5tech.com> Message-ID: <35AD5EAD-F2B9-4F9D-8218-646258640320@delong.com> > On Apr 7, 2016, at 07:41 , William Herrin wrote: > > On Thu, Mar 31, 2016 at 5:36 AM, Bacon Zombie wrote: >> I would ignore the portscans since there is nothing wrong with portscanning >> the Internet. > > You might want to check with your lawyer on that. If you > _intentionally_ port-scan a computer located in Virginia without the > owner's permission (and do nothing else, just port-scan it) it's a > class 3 misdemeanor under 18.2-152.1, et seq. That's up to a $500 fine > for each computer you scan. By comparison, shoplifting is a class 1 > misdemeanor while possession of a schedule V narcotic is another class > 3. I think you?re on shaky ground here. 18.2-152.3 reads: Any person who uses a computer or computer network, without authority and: 1. Obtains property or services by false pretenses; 2. Embezzles or commits larceny; or 3. Converts the property of another; is guilty of the crime of computer fraud. If the value of the property or services obtained is $200 or more, the crime of computer fraud shall be punishable as a Class 5 felony. Where the value of the property or services obtained is less than $200, the crime of computer fraud shall be punishable as a Class 1 misdemeanor. The requirements here are to meet at least one of the 3 tests listed. I think it?s rather hard to claim that a portscan by itself ?obtained property or services by false pretenses?. I think it?s even harder to claim that it constitutes ?embezzling? or ?larceny?. I also think you?d have a tough time arguing that eliciting a response packet to one or more packets actually constitutes conversion of property. So I don?t see how you?d make much of a case for a port-scan being a violation of 18.2-152.1 et. seq. I think the argument, rather easily, could be made that a port-scan is the internet equivalent of a door-knock. By itself, it doesn?t constitute unlawful entry. Now, a persistent door-knock might constitute some form of harassment and frequent or continuous port-scans could be argued to be a form of denial of service (which would constitute conversion), but the odd port-scan is unlikely to meet the tests under the law you cited. > A key word here is "intentionally." Poking at it by mistake (e.g. you > thought it was a different computer which you had the authority to > scan) is not a crime. Nor, most likely, is less aggressive behavior > which would not ordinarily be part of gaining unauthorized access, > such as pinging or tracerouting. I could be wrong, IANAL, but I?d be surprised if a mere portscan would actually be treated as a violation for the reasons cited above. > Not that I've ever heard of someone being fined but you're definitely > in to "something wrong" territory. I don?t think you?ve made your case for ?definite? so far. I agree you might be at risk from an overzealous prosecutor and an activist judge that hates hackers for some reason, but short of that, I think you?re unlikely to run afoul of this statute just on a port scan. Owen From laszlo at heliacal.net Mon Apr 11 18:23:00 2016 From: laszlo at heliacal.net (Laszlo Hanyecz) Date: Mon, 11 Apr 2016 18:23:00 +0000 Subject: GeoIP database issues and the real world consequences In-Reply-To: References: <1460393711.14814.2.camel@beagle> Message-ID: <570BEB84.10905@heliacal.net> Why not use the locations of their own homes? They're indirectly sending mobs to randomly chosen locations. There's enough middle men involved so they can all say they're doing nothing wrong, but wrong is being done. -Laszlo On 2016-04-11 17:34, Steve Mikulasik wrote: > Just so everyone is clear, Maxmind is changing their default locations. > > " Now that I?ve made MaxMind aware of the consequences of the default locations it?s chosen, Mather says they?re going to change them. They are picking new default locations for the U.S. and Ashburn, Virginia that are in the middle of bodies of water, rather than people?s homes." > > From jared at puck.nether.net Mon Apr 11 18:31:15 2016 From: jared at puck.nether.net (Jared Mauch) Date: Mon, 11 Apr 2016 14:31:15 -0400 Subject: how to deal with port scan and brute force attack from AS 8075 ? In-Reply-To: <35AD5EAD-F2B9-4F9D-8218-646258640320@delong.com> References: <56FCD97D.8050201@yahoo.fr> <3B53B9D6-BAA3-48C9-82A7-049CC9049269@n5tech.com> <35AD5EAD-F2B9-4F9D-8218-646258640320@delong.com> Message-ID: <640F641C-AAD6-48FF-B216-C58760C18087@puck.nether.net> > On Apr 11, 2016, at 2:18 PM, Owen DeLong wrote: > > I could be wrong, IANAL, but I?d be surprised if a mere portscan would actually be treated as a violation for the reasons cited above. > >> Not that I've ever heard of someone being fined but you're definitely >> in to "something wrong" territory. > > I don?t think you?ve made your case for ?definite? so far. I agree you might be at risk from an overzealous prosecutor and an activist judge that hates hackers for some reason, but short of that, I think you?re unlikely to run afoul of this statute just on a port scan. > my experience in talking to the DoJ in the US is this is not going to illicit any sort of a response. I will say that the number of people who ?set up a tool? to watch for activity then claim things like a DNS packet or backscatter from DDoS represent a log-on attempt generates the most amusing email to read. - Jared From laszlo at heliacal.net Mon Apr 11 18:32:41 2016 From: laszlo at heliacal.net (Laszlo Hanyecz) Date: Mon, 11 Apr 2016 18:32:41 +0000 Subject: GeoIP database issues and the real world consequences In-Reply-To: <20160411181508.60367.qmail@ary.lan> References: <20160411181508.60367.qmail@ary.lan> Message-ID: <570BEDC9.50308@heliacal.net> On 2016-04-11 18:15, John Levine wrote: > > > Bodies of water probably are the least bad alternative. I wonder if > they're going to hydrolocate all of the unknown addresses, or only the > ones where they get publically shamed. > > R's, > John I imagine some consumers of the data will 'correct' the position to fall on the nearest road in front of the nearest house. -Laszlo From baldur.norddahl at gmail.com Mon Apr 11 19:01:29 2016 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Mon, 11 Apr 2016 21:01:29 +0200 Subject: GeoIP database issues and the real world consequences In-Reply-To: <20160411181508.60367.qmail@ary.lan> References: <59B0E3A0-DF5F-4C9E-8068-54A3B0800DFE@blighty.com> <20160411181508.60367.qmail@ary.lan> Message-ID: On 11 April 2016 at 20:15, John Levine wrote: > Oh, heck, you know better than that. You can put in all the flags and > warnings you want, but if it returns an address, nitwits will show up > at the address with guns. > > Bodies of water probably are the least bad alternative. I wonder if > they're going to hydrolocate all of the unknown addresses, or only the > ones where they get publically shamed. > They should stop giving out coordinates on houses period. Move the coordinate to the nearest street intersection if you need to be that precise (I would prefer nearest town square). Anything more than that should be illegal. Regards, Baldur From sean at donelan.com Mon Apr 11 19:10:44 2016 From: sean at donelan.com (Sean Donelan) Date: Mon, 11 Apr 2016 15:10:44 -0400 (EDT) Subject: GeoIP database issues and the real world consequences In-Reply-To: <570BEDC9.50308@heliacal.net> References: <20160411181508.60367.qmail@ary.lan> <570BEDC9.50308@heliacal.net> Message-ID: On Mon, 11 Apr 2016, Laszlo Hanyecz wrote: > I imagine some consumers of the data will 'correct' the position to fall on > the nearest road in front of the nearest house. If GeoIP insists on giving a specific lon/lat, instead of an uncertaintity how about using locations such as the followign as the "default I don't know where it is" United States: 38.8899 N, 77.0091 W (U.S. Capital Building) Missouri: 38.5792 N, 92.1729 W (Missouri State Capital Building) After the legislators get tired of the police raiding the capital buildings, they will probably do something to fix it. From bill at herrin.us Mon Apr 11 19:12:08 2016 From: bill at herrin.us (William Herrin) Date: Mon, 11 Apr 2016 15:12:08 -0400 Subject: how to deal with port scan and brute force attack from AS 8075 ? In-Reply-To: <35AD5EAD-F2B9-4F9D-8218-646258640320@delong.com> References: <56FCD97D.8050201@yahoo.fr> <3B53B9D6-BAA3-48C9-82A7-049CC9049269@n5tech.com> <35AD5EAD-F2B9-4F9D-8218-646258640320@delong.com> Message-ID: On Mon, Apr 11, 2016 at 2:18 PM, Owen DeLong wrote: > On Apr 7, 2016, at 07:41 , William Herrin wrote: > On Thu, Mar 31, 2016 at 5:36 AM, Bacon Zombie wrote: > > I would ignore the portscans since there is nothing wrong with portscanning > the Internet. > > You might want to check with your lawyer on that. If you > _intentionally_ port-scan a computer located in Virginia without the > owner's permission (and do nothing else, just port-scan it) it's a > class 3 misdemeanor under 18.2-152.1, et seq. That's up to a $500 fine > for each computer you scan. By comparison, shoplifting is a class 1 > misdemeanor while possession of a schedule V narcotic is another class > 3. > > I think you?re on shaky ground here. > > 18.2-152.3 reads: That's computer fraud. You want ? 18.2-152.4, computer trespass. -Bill -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: From niels=nanog at bakker.net Mon Apr 11 19:13:48 2016 From: niels=nanog at bakker.net (Niels Bakker) Date: Mon, 11 Apr 2016 21:13:48 +0200 Subject: GeoIP database issues and the real world consequences In-Reply-To: References: <59B0E3A0-DF5F-4C9E-8068-54A3B0800DFE@blighty.com> <20160411181508.60367.qmail@ary.lan> Message-ID: <20160411191347.GC4087@excession.tpb.net> * baldur.norddahl at gmail.com (Baldur Norddahl) [Mon 11 Apr 2016, 21:02 CEST]: >They should stop giving out coordinates on houses period. Move the >coordinate to the nearest street intersection if you need to be that >precise (I would prefer nearest town square). Anything more than that >should be illegal. That's going to make USPS's and FedEx's lives a lot harder. -- Niels. From Valdis.Kletnieks at vt.edu Mon Apr 11 19:27:39 2016 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Mon, 11 Apr 2016 15:27:39 -0400 Subject: GeoIP database issues and the real world consequences In-Reply-To: <20160411191347.GC4087@excession.tpb.net> References: <59B0E3A0-DF5F-4C9E-8068-54A3B0800DFE@blighty.com> <20160411181508.60367.qmail@ary.lan> <20160411191347.GC4087@excession.tpb.net> Message-ID: <22798.1460402859@turing-police.cc.vt.edu> On Mon, 11 Apr 2016 21:13:48 +0200, Niels Bakker said: > * baldur.norddahl at gmail.com (Baldur Norddahl) [Mon 11 Apr 2016, 21:02 CEST]: > >They should stop giving out coordinates on houses period. Move the > >coordinate to the nearest street intersection if you need to be that > >precise (I would prefer nearest town square). Anything more than that > >should be illegal. > > That's going to make USPS's and FedEx's lives a lot harder. Are they in the habit of delivering to a location identified by an IP address? I've never managed to get either one to deliver to anything other than a street address (and in fact, we recently had to assign street addresses to all the buildings on campus because too many GPS-based programs only work on street addresses, not building names). -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From jfbeam at gmail.com Mon Apr 11 20:56:21 2016 From: jfbeam at gmail.com (Ricky Beam) Date: Mon, 11 Apr 2016 16:56:21 -0400 Subject: Stop IPv6 Google traffic In-Reply-To: References: <570A5543.1030009@netassist.ua> Message-ID: On Sun, 10 Apr 2016 20:09:04 -0400, Rubens Kuhl wrote: > If your users are seeing captchas, one or a few or them are likely to be > infected to the point of generating too much requests to Google. If that were the case, they'd be seeing the same via IPv4. And apparently, they aren't. This also points out the problems with *ASSUMING* you know the size of someone's netblock. If you think "/64", then you'd be wrong. Just as wrong as assuming all IPv4 is "/24". And on the same side of that coin is the over-reaching "block all of Asia" blacklist. Sure, that'll kill a heap of nonsense, but if you actually have business in Asia... (Yes, *I* banish APNIC. "works for me", not recommended for others.) From rubensk at gmail.com Mon Apr 11 21:03:02 2016 From: rubensk at gmail.com (Rubens Kuhl) Date: Mon, 11 Apr 2016 18:03:02 -0300 Subject: Stop IPv6 Google traffic In-Reply-To: References: <570A5543.1030009@netassist.ua> Message-ID: On Mon, Apr 11, 2016 at 5:56 PM, Ricky Beam wrote: > On Sun, 10 Apr 2016 20:09:04 -0400, Rubens Kuhl wrote: > >> If your users are seeing captchas, one or a few or them are likely to be >> infected to the point of generating too much requests to Google. >> > > If that were the case, they'd be seeing the same via IPv4. And apparently, > they aren't. > Nope. If you have both A and AAAA IP addresses in DNS responses and have both IPv4 and IPv6 connectivity, IPv6 will be preferred, with even a bit of latency handicap favoring IPv6 in current Happy Eyeballs implementations. Remember that the symptom is not unresponsive website, but an answer with an inconvenience (the captcha), so the browser and the network stack won't deem it as IPv6 load failure. > This also points out the problems with *ASSUMING* you know the size of > someone's netblock. If you think "/64", then you'd be wrong. Just as > wrong as assuming all IPv4 is "/24". And on the same side of that coin > is the over-reaching "block all of Asia" blacklist. Sure, that'll kill > a heap of nonsense, but if you actually have business in Asia... > > (Yes, *I* banish APNIC. "works for me", not recommended for others.) > One known issue in both APNIC and LACNIC regions is that some addresses are indeed countries instead of single networks, due to NIRs (National Internet Registries). Rubens From owen at delong.com Mon Apr 11 21:05:18 2016 From: owen at delong.com (Owen DeLong) Date: Mon, 11 Apr 2016 14:05:18 -0700 Subject: how to deal with port scan and brute force attack from AS 8075 ? In-Reply-To: References: <56FCD97D.8050201@yahoo.fr> <3B53B9D6-BAA3-48C9-82A7-049CC9049269@n5tech.com> <35AD5EAD-F2B9-4F9D-8218-646258640320@delong.com> Message-ID: <86C3C5FB-B53B-498F-8A2B-DE9C8B0630DC@delong.com> > On Apr 11, 2016, at 12:12 , William Herrin wrote: > > On Mon, Apr 11, 2016 at 2:18 PM, Owen DeLong wrote: >> On Apr 7, 2016, at 07:41 , William Herrin wrote: >> On Thu, Mar 31, 2016 at 5:36 AM, Bacon Zombie wrote: >> >> I would ignore the portscans since there is nothing wrong with portscanning >> the Internet. >> >> You might want to check with your lawyer on that. If you >> _intentionally_ port-scan a computer located in Virginia without the >> owner's permission (and do nothing else, just port-scan it) it's a >> class 3 misdemeanor under 18.2-152.1, et seq. That's up to a $500 fine >> for each computer you scan. By comparison, shoplifting is a class 1 >> misdemeanor while possession of a schedule V narcotic is another class >> 3. >> >> I think you?re on shaky ground here. >> >> 18.2-152.3 reads: > > That's computer fraud. You want ? 18.2-152.4, computer trespass. I worked forward (et. seq.) from where you started? However? 18.2-152.4 . Computer trespass; penalty. A. It shall be unlawful for any person, with malicious intent, to: 1. Temporarily or permanently remove, halt, or otherwise disable any computerdata, computer programs or computer software from a computer or computernetwork; 2. Cause a computer to malfunction, regardless of how long the malfunctionpersists; 3. Alter, disable, or erase any computer data, computer programs or computersoftware; 4. Effect the creation or alteration of a financial instrument or of anelectronic transfer of funds; 5. Use a computer or computer network to cause physical injury to theproperty of another; or 6. Use a computer or computer network to make or cause to be made anunauthorized copy, in any form, including, but not limited to, any printed orelectronic form of computer data, computer programs or computer softwareresiding in, communicated by, or produced by a computer or computer network. 7. [Repealed.] B. Any person who violates this section shall be guilty of computer trespass,which offense shall be punishable as a Class 1 misdemeanor. If there isdamage to the property of another valued at $1,000 or more caused by suchperson's act in violation of this section, the offense shall be punishable asa Class 6 felony. C. Nothing in this section shall be construed to interfere with or prohibitterms or conditions in a contract or license related to computers, computerdata, computer networks, computer operations, computer programs, computerservices, or computer software or to create any liability by reason of termsor conditions adopted by, or technical measures implemented by, aVirginia-based electronic mail service provider to prevent the transmissionof unsolicited electronic mail in violation of this article. Nothing in thissection shall be construed to prohibit the monitoring of computer usage of,the otherwise lawful copying of data of, or the denial of computer orInternet access to a minor by a parent or legal guardian of the minor. Doesn?t really seem to fit the bill, either. First, I think you have a hard time proving ?malicious intent? from just a port scan without other activity. However, even if you do, it?s hard to imagine how a port scan would meet any of the 6 tests stated. Care to try again? Owen From owen at delong.com Mon Apr 11 21:09:56 2016 From: owen at delong.com (Owen DeLong) Date: Mon, 11 Apr 2016 14:09:56 -0700 Subject: GeoIP database issues and the real world consequences In-Reply-To: <59B0E3A0-DF5F-4C9E-8068-54A3B0800DFE@blighty.com> References: <1460393711.14814.2.camel@beagle> <20160411170214.GF26501@sizone.org> <20160411171140.GA9284@bamboo.slabnet.com> <59B0E3A0-DF5F-4C9E-8068-54A3B0800DFE@blighty.com> Message-ID: <6D9A23C7-77F6-4204-9338-20E9C51BABA5@delong.com> > On Apr 11, 2016, at 10:26 , Steve Atkins wrote: > >> >> On Apr 11, 2016, at 10:11 AM, Hugo Slabbert wrote: >> >> >> On Mon 2016-Apr-11 13:02:14 -0400, Ken Chase wrote: >> >>> TL;DR: GeoIP put unknown IP location mappings to the 'center of the country' >>> but then rounded off the lat long so it points at this farm. >>> >>> Cant believe law enforcement is using this kind of info to execute searches. >>> Wouldnt that undermine the credibility of any evidence brought up in trials >>> for any geoip locates? >>> >>> Seems to me locating unknowns somewhere in the middle of a big lake or park in >>> the center of the country might be a better idea. >> >> ...how about actually marking an unknown as...oh, I dunno: "unknown"? Is there no analogue in the GeoIP lookups for a 404? > > It's not unknown - it's (according to the DB, anyway, which has a bunch of flaws) "in the US somewhere". > > The problem with MaxMind (and other geoip databases I've seen that do Lat/Long as well as Country / State / Town) is that the data doesn't include uncertainty, so it returns "38.0/-97.0" rather than "somewhere in a 3000 mile radius circle centered on 38.0/-97.0". > > Someone should show them RFC 1876 as an example of better practice. > > Cheers, > Steve So really, what is needed is two additional fields for the lat/lon of laterr/lonerr so that, for example, instead of just 38.0/-97.0, you would get 38.0?2/-97.0?10 or something like that. This seems reasonable to me. Owen From jfbeam at gmail.com Mon Apr 11 21:26:20 2016 From: jfbeam at gmail.com (Ricky Beam) Date: Mon, 11 Apr 2016 17:26:20 -0400 Subject: Stop IPv6 Google traffic In-Reply-To: References: <570A5543.1030009@netassist.ua> Message-ID: On Mon, 11 Apr 2016 17:03:02 -0400, Rubens Kuhl wrote: >> If that were the case, they'd be seeing the same via IPv4. And >> apparently, >> they aren't. >> > > Nope. If you have both A and AAAA IP addresses in DNS responses and have > both IPv4 and IPv6 connectivity, IPv6 will be preferred, with even a bit You misunderstood. If they disable IPv6, then their "attacks" would continue via IPv4, thus getting IPv4 similarly blacklisted. This is not happening -- hence the plan of blocking IPv6. While it's possible there's some IPv6 specific "spambot" (adbot, whatever) running, I doubt it. From jfbeam at gmail.com Mon Apr 11 21:41:21 2016 From: jfbeam at gmail.com (Ricky Beam) Date: Mon, 11 Apr 2016 17:41:21 -0400 Subject: GeoIP database issues and the real world consequences In-Reply-To: <1460393711.14814.2.camel@beagle> References: <1460393711.14814.2.camel@beagle> Message-ID: On Mon, 11 Apr 2016 12:55:11 -0400, Chris Boyd wrote: > Interesting article. > > http://fusion.net/story/287592/internet-mapping-glitch-kansas-farm/ ... "Until you reached out to us, we were unaware that there were issues..." Bull! I can dig up dozens (if not hundreds) of emails from coworkers and customers who have complained to MaxMind about their asinine we-don't-have-a-frakin-clue results. They've known for years! They're paid for a definitive answer, not an "unknown", which is why the default answer is the same near-the-center-of-the-country lat/lon. He, personally, may have had no idea, but MaxMind The Company did/does. From owen at delong.com Mon Apr 11 21:44:50 2016 From: owen at delong.com (Owen DeLong) Date: Mon, 11 Apr 2016 14:44:50 -0700 Subject: Stop IPv6 Google traffic In-Reply-To: References: <570A5543.1030009@netassist.ua> Message-ID: > On Apr 11, 2016, at 14:03 , Rubens Kuhl wrote: > > On Mon, Apr 11, 2016 at 5:56 PM, Ricky Beam wrote: > >> On Sun, 10 Apr 2016 20:09:04 -0400, Rubens Kuhl wrote: >> >>> If your users are seeing captchas, one or a few or them are likely to be >>> infected to the point of generating too much requests to Google. >>> >> >> If that were the case, they'd be seeing the same via IPv4. And apparently, >> they aren't. >> > > Nope. If you have both A and AAAA IP addresses in DNS responses and have > both IPv4 and IPv6 connectivity, IPv6 will be preferred, with even a bit of > latency handicap favoring IPv6 in current Happy Eyeballs implementations. > Remember that the symptom is not unresponsive website, but an answer with > an inconvenience (the captcha), so the browser and the network stack won't > deem it as IPv6 load failure. Also, incorrect or non-existant PTR records are much more common in IPv6 than in IPv4, so that could also account for some difference in behavior. Most res.ISPs, for example, synthesize PTR responses for their IPv4 addresses such as: 240.59.103.76.in-addr.arpa. 7200 IN PTR c-76-103-59-240.hsd1.ca.comcast.net. vs. ; <<>> DiG 9.8.3-P1 <<>> -x 2601:1c1:1234:5678:b834:f36d:2bb9:285 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 48639 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION: ;5.8.2.0.9.b.b.2.d.6.3.f.4.3.8.b.8.7.6.5.4.3.2.1.1.c.1.0.1.0.6.2.ip6.arpa. IN PTR ;; AUTHORITY SECTION: 0.1.0.6.2.ip6.arpa. 3600 IN SOA dns101.comcast.net. dnsmaster.comcastonline.com. 2014093006 7200 300 604800 3600 ;; Query time: 128 msec ;; SERVER: 172.22.186.6#53(172.22.186.6) ;; WHEN: Mon Apr 11 14:43:53 2016 ;; MSG SIZE rcvd: 171 for example. Owen From owen at delong.com Mon Apr 11 21:59:01 2016 From: owen at delong.com (Owen DeLong) Date: Mon, 11 Apr 2016 14:59:01 -0700 Subject: GeoIP database issues and the real world consequences In-Reply-To: <20160411181508.60367.qmail@ary.lan> References: <20160411181508.60367.qmail@ary.lan> Message-ID: > On Apr 11, 2016, at 11:15 , John Levine wrote: > > >> The problem with MaxMind (and other geoip databases I've seen that do Lat/Long as well as Country / State / Town) is that the >> data doesn't include uncertainty, so it returns "38.0/-97.0" rather than "somewhere in a 3000 mile radius circle centered on >> 38.0/-97.0". >> >> Someone should show them RFC 1876 as an example of better practice. > > Oh, heck, you know better than that. You can put in all the flags and > warnings you want, but if it returns an address, nitwits will show up > at the address with guns. I hear this argument about various things over and over and over again. However, my home address has been published in multiple whois databases since I moved here in 1993. Not once has a nitwit with a gun shown up on my doorstep as a result. (I have had visits from nitwits with guns, but they were the results of various local oddities unrelated to the internet). Examples: 1. A neighbor managed to get the SJPD (most common example of nitwits with guns in this area) to darken my doorstep because he spotted (and complained about) a dog in my yard being out of control and not on a leash or supervised. (Not sure why they thought it was my dog, as I have never owned a dog at this address). 2. I opened my front door to be greeted by a nitwit with a gun (again, SJPD) telling me to go back inside while they completed an arrest nearby. So, apparently there still aren?t enough nitwits with guns operating enough typewriters to fulfill this bit of conventional wisdom as yet. Owen From owen at delong.com Mon Apr 11 22:02:07 2016 From: owen at delong.com (Owen DeLong) Date: Mon, 11 Apr 2016 15:02:07 -0700 Subject: GeoIP database issues and the real world consequences In-Reply-To: References: <59B0E3A0-DF5F-4C9E-8068-54A3B0800DFE@blighty.com> <20160411181508.60367.qmail@ary.lan> Message-ID: <8EA3ADD6-9533-42DA-8CFD-805D389A435A@delong.com> > On Apr 11, 2016, at 12:01 , Baldur Norddahl wrote: > > On 11 April 2016 at 20:15, John Levine wrote: > >> Oh, heck, you know better than that. You can put in all the flags and >> warnings you want, but if it returns an address, nitwits will show up >> at the address with guns. >> >> Bodies of water probably are the least bad alternative. I wonder if >> they're going to hydrolocate all of the unknown addresses, or only the >> ones where they get publically shamed. >> > > They should stop giving out coordinates on houses period. Move the > coordinate to the nearest street intersection if you need to be that > precise (I would prefer nearest town square). Anything more than that > should be illegal. > > Regards, > > Baldur The thing I find particularly amusing having just looked up my own IP addresses is the following: 1. My addresses are tied to my actual address in whois. 2. That is not the address linked to in any of the GeoIP databases I know how to check. 3. The address is only a few blocks away, but where an ambiguity is provided, it is sufficient to cover most of the city of San Jose, including my house of course. Needless to say, it?s not confidence inspiring. I might look to see whose house it does send me to later if I feel inclined, just for amusement. Owen From niels=nanog at bakker.net Mon Apr 11 22:23:09 2016 From: niels=nanog at bakker.net (Niels Bakker) Date: Tue, 12 Apr 2016 00:23:09 +0200 Subject: GeoIP database issues and the real world consequences In-Reply-To: References: <20160411181508.60367.qmail@ary.lan> Message-ID: <20160411222309.GD4087@excession.tpb.net> >>Oh, heck, you know better than that. You can put in all the flags >>and warnings you want, but if it returns an address, nitwits will >>show up at the address with guns. * owen at delong.com (Owen DeLong) [Tue 12 Apr 2016, 00:02 CEST]: >I hear this argument about various things over and over and over again. > >However, my home address has been published in multiple whois >databases since I moved here in 1993. > >Not once has a nitwit with a gun shown up on my doorstep as a result. I think you miss the point. Your geocoordinates were not mistakenly associated with nigh infinite amounts of internet abuse. This thread has (mostly) been about wrong information being published, not information being published at all. -- Niels. From mureninc at gmail.com Tue Apr 12 00:12:19 2016 From: mureninc at gmail.com (Constantine A. Murenin) Date: Mon, 11 Apr 2016 17:12:19 -0700 Subject: Stop IPv6 Google traffic In-Reply-To: References: <570A5543.1030009@netassist.ua> Message-ID: On 10 April 2016 at 14:48, Jon Lewis wrote: > On Sun, 10 Apr 2016, Max Tulyev wrote: > >> Hi All, >> >> I need to stop IPv6 web traffic going from our customers to Google >> without touching all other IPv6 and without blackhole IPv6 Google >> network (this case my customers are complaining on long timeouts). >> >> What can you advice for that? > > > Just use Cogent transit for IPv6. Problem solved. :) Unless Cogent is doing something different for Google than HE does for Cogent, using Cogent is unlikely to solve the timeout issues: % telnet -6 www.cogentco.com 80 Trying 2001:550:1::cc01... ^C % As has already been pointed out, the proper half-baked solution is to return a destination unreachable packet in these situations, instead of silently dropping the packets and forcing the clients to go through a timeout. Cheers, Constantine.SU. From owen at delong.com Tue Apr 12 00:11:58 2016 From: owen at delong.com (Owen DeLong) Date: Mon, 11 Apr 2016 17:11:58 -0700 Subject: GeoIP database issues and the real world consequences In-Reply-To: <20160411222309.GD4087@excession.tpb.net> References: <20160411181508.60367.qmail@ary.lan> <20160411222309.GD4087@excession.tpb.net> Message-ID: <4638EB20-BA90-419B-B2C5-D462238FE9EF@delong.com> > On Apr 11, 2016, at 15:23 , Niels Bakker wrote: > >>> Oh, heck, you know better than that. You can put in all the flags and warnings you want, but if it returns an address, nitwits will show up at the address with guns. > > * owen at delong.com (Owen DeLong) [Tue 12 Apr 2016, 00:02 CEST]: >> I hear this argument about various things over and over and over again. >> >> However, my home address has been published in multiple whois databases since I moved here in 1993. >> >> Not once has a nitwit with a gun shown up on my doorstep as a result. > > I think you miss the point. Your geocoordinates were not mistakenly associated with nigh infinite amounts of internet abuse. This thread has (mostly) been about wrong information being published, not information being published at all. I didn?t miss the point, but the specific statement quoted is patently false in both cases (the article itself admits that the vast majority of such ?victim? households contacted had not suffered any ill effects). Owen From larrysheldon at cox.net Tue Apr 12 00:59:47 2016 From: larrysheldon at cox.net (Larry Sheldon) Date: Mon, 11 Apr 2016 19:59:47 -0500 Subject: GeoIP database issues and the real world consequences In-Reply-To: <1460393711.14814.2.camel@beagle> References: <1460393711.14814.2.camel@beagle> Message-ID: <570C4883.1090909@cox.net> On 4/11/2016 11:55, Chris Boyd wrote: > > Interesting article. > > http://fusion.net/story/287592/internet-mapping-glitch-kansas-farm/ > > An hour?s drive from Wichita, Kansas, in a little town called Potwin, > there is a 360-acre piece of land with a very big problem. > > The plot has been owned by the Vogelman family for more than a hundred > years, though the current owner, Joyce Taylor n?e Vogelman, 82, now > rents it out. The acreage is quiet and remote: a farm, a pasture, an old > orchard, two barns, some hog shacks and a two-story house. It?s the kind > of place you move to if you want to get away from it all. The nearest > neighbor is a mile away, and the closest big town has just 13,000 > people. It is real, rural America; in fact, it?s a two-hour drive from > the exact geographical center of the United States. > > But instead of being a place of respite, the people who live on Joyce > Taylor?s land find themselves in a technological horror story. And not even slightly funny. What happened to Truth. If you do not know, say "I don't know." Or be silent. > > > For the last decade, Taylor and her renters have been visited by all > kinds of mysterious trouble. They?ve been accused of being identity > thieves, spammers, scammers and fraudsters. They?ve gotten visited by > FBI agents, federal marshals, IRS collectors, ambulances searching for > suicidal veterans, and police officers searching for runaway children. > They?ve found people scrounging around in their barn. The renters have > been doxxed, their names and addresses posted on the internet by > vigilantes. Once, someone left a broken toilet in the driveway as a > strange, indefinite threat. > > --Chris > > -- sed quis custodiet ipsos custodes? (Juvenal) From sfrost at snowman.net Tue Apr 12 01:23:21 2016 From: sfrost at snowman.net (Stephen Frost) Date: Mon, 11 Apr 2016 21:23:21 -0400 Subject: GeoIP database issues and the real world consequences In-Reply-To: References: <20160411181508.60367.qmail@ary.lan> Message-ID: <20160412012321.GG10850@tamriel.snowman.net> Owne, * Owen DeLong (owen at delong.com) wrote: > However, my home address has been published in multiple whois databases since I moved here in 1993. > > Not once has a nitwit with a gun shown up on my doorstep as a result. (I have had visits from nitwits with guns, > but they were the results of various local oddities unrelated to the internet). I'm glad to hear you've not had the joy of such an experience. I nearly had one, but I managed to convince the nitwit to not to show up, but it took a few hours on the phone. He had seen my email address fly across while Linux was booting (thanks to a Netfilter module I had written which had been included) on some device he had he wasn't technical, so it wasn't easy for me to work out what he was talking about, except that it was very clearly something he was trying to "fix" to get his internet working again. From that, he looked up my domain via whois and got my phone number and address and called me and accused me of being with various three-letter government organizations, said he had found proof that he was being spied on and a litany of similar concerns. Ultimately, I got him to believe (or at least, it seemed so) that I was just some technical guy that wrote some code for a company that built the device and got off the phone with him hours later. On the plus side of this particular story, a few Airbus planes were built with a version of Linux which displayed the boot messages during startup on the in-seat displays and my name and email have shown up for the reason on those devices, leading to emails from a few strangers around the world with pictures of the boot process showing my email. I'm not quite sure that the up-side out-weighs the down in this particular story, but there it is. Thanks! Stephen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From jmaslak at antelope.net Tue Apr 12 03:14:32 2016 From: jmaslak at antelope.net (Joel Maslak) Date: Mon, 11 Apr 2016 21:14:32 -0600 Subject: GeoIP database issues and the real world consequences In-Reply-To: <6D9A23C7-77F6-4204-9338-20E9C51BABA5@delong.com> References: <1460393711.14814.2.camel@beagle> <20160411170214.GF26501@sizone.org> <20160411171140.GA9284@bamboo.slabnet.com> <59B0E3A0-DF5F-4C9E-8068-54A3B0800DFE@blighty.com> <6D9A23C7-77F6-4204-9338-20E9C51BABA5@delong.com> Message-ID: On Mon, Apr 11, 2016 at 3:09 PM, Owen DeLong wrote: > So really, what is needed is two additional fields for the lat/lon of > laterr/lonerr so that, for example, instead of just 38.0/-97.0, you would > get 38.0?2/-97.0?10 or something like that. > It does seem needed to the geo location companies too, at least several of them provide this - and it's been this way for a long time. I didn't remember if Maxmind does or not, so I just checked. From some of their documentation, the field "accuracy_radius" is returned which is "The radius in kilometers around the specified location where the IP address is likely to be." See http://dev.maxmind.com/geoip/geoip2/web-services/#location . I don't think it's in their free stuff (you get what you pay for, it seems). It doesn't show up on their web interface to "try" the service nor does it give a warning that these things can be wrong, but IMHO probably wouldn't be a bad idea to say "Don't go show up at this address - it might not be right!" From hank at efes.iucc.ac.il Tue Apr 12 05:08:29 2016 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Tue, 12 Apr 2016 08:08:29 +0300 Subject: GeoIP database issues and the real world consequences In-Reply-To: References: <1460393711.14814.2.camel@beagle> Message-ID: <570C82CD.2070405@efes.iucc.ac.il> On 12/04/2016 00:41, Ricky Beam wrote: > On Mon, 11 Apr 2016 12:55:11 -0400, Chris Boyd > wrote: >> Interesting article. >> >> http://fusion.net/story/287592/internet-mapping-glitch-kansas-farm/ > ... > > "Until you reached out to us, we were unaware that there were issues..." > > Bull! I can dig up dozens (if not hundreds) of emails from coworkers > and customers who have complained to MaxMind about their asinine > we-don't-have-a-frakin-clue results. They've known for years! They're > paid for a definitive answer, not an "unknown", which is why the > default answer is the same near-the-center-of-the-country lat/lon. He, > personally, may have had no idea, but MaxMind The Company did/does. > Its called class action lawsuit. -Hank From lists at eitanadler.com Tue Apr 12 05:19:46 2016 From: lists at eitanadler.com (Eitan Adler) Date: Mon, 11 Apr 2016 22:19:46 -0700 Subject: Stop IPv6 Google traffic In-Reply-To: <22282.43671.253407.6403@pcls8.std.com> References: <570A5543.1030009@netassist.ua> <60483.1460296213@turing-police.cc.vt.edu> <22282.43671.253407.6403@pcls8.std.com> Message-ID: On 10 April 2016 at 12:33, wrote: > Who cares what his motivations are unless he asks for help with that > underlying problem? See Also: http://xyproblem.info/ -- Eitan Adler From web at typo.org Tue Apr 12 06:42:32 2016 From: web at typo.org (Wayne Bouchard) Date: Mon, 11 Apr 2016 23:42:32 -0700 Subject: GeoIP database issues and the real world consequences In-Reply-To: <20160411181508.60367.qmail@ary.lan> References: <59B0E3A0-DF5F-4C9E-8068-54A3B0800DFE@blighty.com> <20160411181508.60367.qmail@ary.lan> Message-ID: <20160412064232.GA46463@spider.typo.org> On Mon, Apr 11, 2016 at 06:15:08PM -0000, John Levine wrote: > > >The problem with MaxMind (and other geoip databases I've seen that do Lat/Long as well as Country / State / Town) is that the > >data doesn't include uncertainty, so it returns "38.0/-97.0" rather than "somewhere in a 3000 mile radius circle centered on > >38.0/-97.0". > > > >Someone should show them RFC 1876 as an example of better practice. > > Oh, heck, you know better than that. You can put in all the flags and > warnings you want, but if it returns an address, nitwits will show up > at the address with guns. > > Bodies of water probably are the least bad alternative. I wonder if > they're going to hydrolocate all of the unknown addresses, or only the > ones where they get publically shamed. I personal favor setting the generic location as a certain set of roundish holes in the ground up in the northern plains. Let the government raid itself for once. --- Wayne Bouchard web at typo.org Network Dude http://www.typo.org/~web/ From johnl at iecc.com Tue Apr 12 11:55:57 2016 From: johnl at iecc.com (John Levine) Date: 12 Apr 2016 11:55:57 -0000 Subject: GeoIP database issues and the real world consequences In-Reply-To: <20160411191347.GC4087@excession.tpb.net> Message-ID: <20160412115557.60578.qmail@ary.lan> In article <20160411191347.GC4087 at excession.tpb.net> you write: >* baldur.norddahl at gmail.com (Baldur Norddahl) [Mon 11 Apr 2016, 21:02 CEST]: >>They should stop giving out coordinates on houses period. Move the >>coordinate to the nearest street intersection if you need to be that >>precise (I would prefer nearest town square). Anything more than that >>should be illegal. > >That's going to make USPS's and FedEx's lives a lot harder. Please don't guess (like, you know, MaxMind does.) USPS has its own database of all of the deliverable addresses in the country. They have their problems, but give or take data staleness as buildings are built or demolished, that's not one of them. R's, John From colton.conor at gmail.com Tue Apr 12 13:04:40 2016 From: colton.conor at gmail.com (Colton Conor) Date: Tue, 12 Apr 2016 08:04:40 -0500 Subject: mpls switches In-Reply-To: <5705A3AC.5020903@tiedyenetworks.com> References: <5705A3AC.5020903@tiedyenetworks.com> Message-ID: Do the Juniper EX switches support MPLS? I know they have models with multiple 10G ports on them. There is also the QFX series. On Wed, Apr 6, 2016 at 7:02 PM, Mike wrote: > Hi, > > Im looking to deploy more mpls in my network. I like the Cisco 3600X > series but the low density of 10g ports has me wanting to consider perhaps > others. I would love a minimum of 4 10g ports but of course more is better. > Cost would also be a factor. What are people using these days? > > Thanks. > > Mike- > From colton.conor at gmail.com Tue Apr 12 13:07:44 2016 From: colton.conor at gmail.com (Colton Conor) Date: Tue, 12 Apr 2016 08:07:44 -0500 Subject: Telco Systems Message-ID: Does anyone use Telco Systems Carrier Ethernet & MPLS Aggregation Switches? I have heard good things about them. Overall, the saying is they price 10G ethernet switches at 1G ethernet pricing. It looks like they support MPLS. http://www.telco.com/index.php?page=product-category&category=ethernet-mpls-aggregation From josh at kyneticwifi.com Tue Apr 12 13:08:15 2016 From: josh at kyneticwifi.com (Josh Reynolds) Date: Tue, 12 Apr 2016 08:08:15 -0500 Subject: mpls switches In-Reply-To: References: <5705A3AC.5020903@tiedyenetworks.com> Message-ID: I know the 4500/4550 does but it requires a license. On Apr 12, 2016 8:07 AM, "Colton Conor" wrote: > Do the Juniper EX switches support MPLS? I know they have models with > multiple 10G ports on them. There is also the QFX series. > > On Wed, Apr 6, 2016 at 7:02 PM, Mike > wrote: > > > Hi, > > > > Im looking to deploy more mpls in my network. I like the Cisco 3600X > > series but the low density of 10g ports has me wanting to consider > perhaps > > others. I would love a minimum of 4 10g ports but of course more is > better. > > Cost would also be a factor. What are people using these days? > > > > Thanks. > > > > Mike- > > > From mark.tinka at seacom.mu Tue Apr 12 13:11:36 2016 From: mark.tinka at seacom.mu (Mark Tinka) Date: Tue, 12 Apr 2016 15:11:36 +0200 Subject: mpls switches In-Reply-To: References: <5705A3AC.5020903@tiedyenetworks.com> Message-ID: <4eec1f63-0e69-ac3f-78f9-b3fb5b3de0a6@seacom.mu> On 12/Apr/16 15:04, Colton Conor wrote: > Do the Juniper EX switches support MPLS? I know they have models with > multiple 10G ports on them. They do, but (deliberately) broken. I wouldn't try it. > There is also the QFX series. Not that I know of, but the ACX is a QFX-derivative (Broadcom chipset, approach with caution). Mark. From jackson.tim at gmail.com Tue Apr 12 13:22:44 2016 From: jackson.tim at gmail.com (Tim Jackson) Date: Tue, 12 Apr 2016 08:22:44 -0500 Subject: mpls switches In-Reply-To: <4eec1f63-0e69-ac3f-78f9-b3fb5b3de0a6@seacom.mu> References: <5705A3AC.5020903@tiedyenetworks.com> <4eec1f63-0e69-ac3f-78f9-b3fb5b3de0a6@seacom.mu> Message-ID: >> Do the Juniper EX switches support MPLS? I know they have models with >> multiple 10G ports on them. > > They do, but (deliberately) broken. I wouldn't try it. EX4600 does MPLS just fine, nothing else really does in the EX series.. EX4200 can do 1 label. The EX4600 featureset is pretty much the same as QFX5100 in addition to supporting MACSEC. >> There is also the QFX series. > > Not that I know of, but the ACX is a QFX-derivative (Broadcom chipset, > approach with caution). QFX5100 works fine for MPLS.. ACX5k is QFX5100 hardware, but a different train of software, and it's a bit different. QFX5100 is a great P and lightweight PE.. -- Tim From jeremyparr at gmail.com Tue Apr 12 13:31:51 2016 From: jeremyparr at gmail.com (Jeremy Parr) Date: Tue, 12 Apr 2016 09:31:51 -0400 Subject: Any ATT.net mail admins here? Message-ID: I have two spam filters that relay outbound mail for a few dozen companies, and as such generate a fair amount of traffic. We are fairly strict with the spam filtering on outbound mail, but somehow end up blacklisted by ATT/Prodigy/Bellsouth a few times a year. From bicknell at ufp.org Tue Apr 12 13:31:47 2016 From: bicknell at ufp.org (Leo Bicknell) Date: Tue, 12 Apr 2016 06:31:47 -0700 Subject: GeoIP database issues and the real world consequences In-Reply-To: References: <20160411181508.60367.qmail@ary.lan> <570BEDC9.50308@heliacal.net> Message-ID: <20160412133147.GA90286@ussenterprise.ufp.org> In a message written on Mon, Apr 11, 2016 at 03:10:44PM -0400, Sean Donelan wrote: > If GeoIP insists on giving a specific lon/lat, instead of an uncertaintity > how about using locations such as the followign as the "default I don't > know where it is" > > United States: 38.8899 N, 77.0091 W (U.S. Capital Building) > Missouri: 38.5792 N, 92.1729 W (Missouri State Capital Building) > > After the legislators get tired of the police raiding the capital > buildings, they will probably do something to fix it. Massachusetts: 42.376702 N, 71.239076 W (MaxMind Corporate HQ) Maybe after seeing what it's like to be on the receiving end of their own inaccuracy they will be a bit more motivated to fix it. -- Leo Bicknell - bicknell at ufp.org PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 811 bytes Desc: not available URL: From mark.tinka at seacom.mu Tue Apr 12 13:32:51 2016 From: mark.tinka at seacom.mu (Mark Tinka) Date: Tue, 12 Apr 2016 15:32:51 +0200 Subject: mpls switches In-Reply-To: References: <5705A3AC.5020903@tiedyenetworks.com> <4eec1f63-0e69-ac3f-78f9-b3fb5b3de0a6@seacom.mu> Message-ID: <3cc917e2-312f-ebb9-b1e9-884e0fdd40b8@seacom.mu> On 12/Apr/16 15:22, Tim Jackson wrote: > QFX5100 works fine for MPLS.. ACX5k is QFX5100 hardware, but a > different train of software, and it's a bit different. QFX5100 is a > great P and lightweight PE.. As a P, fine (except if you're doing NG-MVPN, of course, which would make it a poor branch router). The "lightweight PE" is where my concern comes in. And if the EX4600 is the same as the QFX in this regard, same problem, i.e., if the OP is expecting all PE functionality he'd get on an MX in this unit, he needs to reset his expectations. Mark. From jhaustin at gmail.com Tue Apr 12 13:54:36 2016 From: jhaustin at gmail.com (Jeremy Austin) Date: Tue, 12 Apr 2016 05:54:36 -0800 Subject: GeoIP database issues and the real world consequences In-Reply-To: <20160412115557.60578.qmail@ary.lan> References: <20160411191347.GC4087@excession.tpb.net> <20160412115557.60578.qmail@ary.lan> Message-ID: On Tue, Apr 12, 2016 at 3:55 AM, John Levine wrote: > > Please don't guess (like, you know, MaxMind does.) USPS has its own > database of all of the deliverable addresses in the country. They > have their problems, but give or take data staleness as buildings > are built or demolished, that's not one of them. A qualifier. USPS has a database of *most* of the deliverable addresses in the country. I'm in an unorganized borough. The USPS actually has no mandate, funding or lever that I can pull (that I can find) to keep their database up to date. Easily 30% of the legitimate addresses in my area are not geocodable nor in the USPS database. I suspect that there are areas of my state with an even worse percentage of unavailable data. UPS and FedEx rely on the USPS database, but will not lift a finger to fix this gap. Even as a municipal body there is no available federal mechanism for updating the database. I've tried multiple times over 15+ years. So yeah, USPS' database does have its problems. -- Jeremy Austin (907) 895-2311 (907) 803-5422 jhaustin at gmail.com Heritage NetWorks Whitestone Power & Communications Vertical Broadband, LLC Schedule a meeting: http://doodle.com/jermudgeon From nanog at ics-il.net Tue Apr 12 14:15:07 2016 From: nanog at ics-il.net (Mike Hammett) Date: Tue, 12 Apr 2016 09:15:07 -0500 (CDT) Subject: Telco Systems In-Reply-To: Message-ID: <776317513.13029.1460470506525.JavaMail.mhammett@ThunderFuck> I know of a WISP in Puerto Rico that loves them. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest Internet Exchange http://www.midwest-ix.com ----- Original Message ----- From: "Colton Conor" To: "NANOG" Sent: Tuesday, April 12, 2016 8:07:44 AM Subject: Telco Systems Does anyone use Telco Systems Carrier Ethernet & MPLS Aggregation Switches? I have heard good things about them. Overall, the saying is they price 10G ethernet switches at 1G ethernet pricing. It looks like they support MPLS. http://www.telco.com/index.php?page=product-category&category=ethernet-mpls-aggregation From tim at pelican.org Tue Apr 12 14:44:32 2016 From: tim at pelican.org (tim at pelican.org) Date: Tue, 12 Apr 2016 15:44:32 +0100 (BST) Subject: mpls switches In-Reply-To: References: <5705A3AC.5020903@tiedyenetworks.com> Message-ID: <1460472272.339723893@apps.rackspace.com> On Tuesday, 12 April, 2016 14:04, "Colton Conor" said: > Do the Juniper EX switches support MPLS? I know they have models with > multiple 10G ports on them. There is also the QFX series. The EXes can also run in a "fabric extender" mode to the MX (and others?). Depending on geographical footprint and requirements, this might be worth a look. Regards, Tim. From math at sizone.org Tue Apr 12 15:31:59 2016 From: math at sizone.org (Ken Chase) Date: Tue, 12 Apr 2016 11:31:59 -0400 Subject: Any ATT.net mail admins here? In-Reply-To: References: Message-ID: <20160412153159.GA31850@sizone.org> Got this a few months ago, posting publically so it makes it into the archives for the next guy. > Thank you for contacting the AT&T Postmaster. > > We need the IP address of the server sending mail from you to our customer/s. > This information is provided in the non-delivery report that would be returned > to you in the event that there was a problem with mail delivery. If your mail > server truncates that part of the error message, it may be necessary for you > to conduct a manual session with our mail server to capture the blocked IP > address. If you do not receive a rejection message then your messages are > potentially being filtered as bulk. If you believe that to be the case, email > mail-abuse-bulk at cc.yahoo-inc.com and request the Bulk Mail form to be > whitelisted. > > The more information you can provide about what you are trying to accomplish > and the specifics involved the easier it is for us to help you. Please reply > to this message with as much detail about your problem as possible, but > specifically the points touched on above. > > Regards, > > > Postmaster > AT&T Client Security Management > abuse_rbl at abuse-att.net > http://att.net/blocks On Tue, Apr 12, 2016 at 09:31:51AM -0400, Jeremy Parr said: >I have two spam filters that relay outbound mail for a few dozen companies, >and as such generate a fair amount of traffic. We are fairly strict with >the spam filtering on outbound mail, but somehow end up blacklisted by >ATT/Prodigy/Bellsouth a few times a year. -- Ken Chase - math at sizone.org From sean at donelan.com Tue Apr 12 20:06:24 2016 From: sean at donelan.com (Sean Donelan) Date: Tue, 12 Apr 2016 16:06:24 -0400 (EDT) Subject: Why the US Government has so many data centers In-Reply-To: References: Message-ID: Guess what, an IG decides to count "data centers" using OMB's definition of a data center. CIO points out those "data centers" won't save money. https://fcw.com/articles/2016/04/11/lyngaas-halvorsen-update.aspx The IG report knocked Halvorsen for not adjusting his strategy to account for a revised definition of data centers from the Office of Management and Budget. But Halvorsen defended that decision, saying the revised definition focused on special-purpose processing nodes, which are data centers that have no direct connection to the DOD Information Network. "Those nodes aren't where the money [is], and in most cases, there's no value in consolidating them," Halvorsen said. From wesley.george at twcable.com Tue Apr 12 21:13:20 2016 From: wesley.george at twcable.com (George, Wes) Date: Tue, 12 Apr 2016 21:13:20 +0000 Subject: mpls switches In-Reply-To: References: <5705A3AC.5020903@tiedyenetworks.com> <4eec1f63-0e69-ac3f-78f9-b3fb5b3de0a6@seacom.mu> Message-ID: On 4/12/16, 9:22 AM, "NANOG on behalf of Tim Jackson" wrote: >>> (Broadcom chipset, >> approach with caution). > >QFX5100 works fine for MPLS.. [snip] QFX5100 is a >great P and lightweight PE.. WG] For some values of "fine" and "great" perhaps, but emphasis on the "lightweight" is important, as its suitability is heavily dependent on your intended use case. Use it with a few thousand routes and nothing particularly exotic as far as features go and you should be fine. However, there are sometimes little gotchas where established features (esp in MPLS) either are missing or behave differently in subtle ways compared with more traditional JunOS routers like the MX. Some of these are limitations in the Broadcom chipset and some are driven by customer demand prioritizing feature completion. Test carefully, and regard the higher-end multidimensional/route scale numbers with healthy skepticism. Wes George Anything below this line has been added by my company?s mail server, I have no control over it. ----------- ________________________________ 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 surfer at mauigateway.com Tue Apr 12 21:19:45 2016 From: surfer at mauigateway.com (Scott Weeks) Date: Tue, 12 Apr 2016 14:19:45 -0700 Subject: Why the US Government has so many data centers Message-ID: <20160412141945.E76F8F76@m0087795.ppops.net> --- sean at donelan.com wrote: From: Sean Donelan https://fcw.com/articles/2016/04/11/lyngaas-halvorsen-update.aspx --------------------------------------------- Wow, this is big news in that article for the companies that deal with selling network devices and computers to the DoD: (Defense Department CIO is Terry Halvorsen) "Halvorsen also briefed reporters on updates to the department's cybersecurity scorecard and its certification process. He said he expects to announce revisions in the coming weeks to DOD's accreditation and certification process for commercial IT products and services. "I think we have reached a point where we no longer can do specific hardware or software accreditation," he said, meaning a piecemeal approach won't keep up with continual updates to, say, cloud offerings. "Our process wouldn't sustain that," he said of certifying cloud offerings that are always being updated. "We need to look at how we do certification and accreditation by process and at some point maybe even by vendor."" scott From larrysheldon at cox.net Tue Apr 12 22:41:39 2016 From: larrysheldon at cox.net (Larry Sheldon) Date: Tue, 12 Apr 2016 17:41:39 -0500 Subject: GeoIP database issues and the real world consequences In-Reply-To: <20160412133147.GA90286@ussenterprise.ufp.org> References: <20160411181508.60367.qmail@ary.lan> <570BEDC9.50308@heliacal.net> <20160412133147.GA90286@ussenterprise.ufp.org> Message-ID: <570D79A3.6080708@cox.net> On 4/12/2016 08:31, Leo Bicknell wrote: > In a message written on Mon, Apr 11, 2016 at 03:10:44PM -0400, Sean Donelan wrote: >> If GeoIP insists on giving a specific lon/lat, instead of an uncertaintity >> how about using locations such as the followign as the "default I don't >> know where it is" >> >> United States: 38.8899 N, 77.0091 W (U.S. Capital Building) >> Missouri: 38.5792 N, 92.1729 W (Missouri State Capital Building) >> >> After the legislators get tired of the police raiding the capital >> buildings, they will probably do something to fix it. > > Massachusetts: 42.376702 N, 71.239076 W (MaxMind Corporate HQ) > > Maybe after seeing what it's like to be on the receiving end of their > own inaccuracy they will be a bit more motivated to fix it. BINGO!!! -- sed quis custodiet ipsos custodes? (Juvenal) From jfmezei_nanog at vaxination.ca Wed Apr 13 00:10:00 2016 From: jfmezei_nanog at vaxination.ca (Jean-Francois Mezei) Date: Tue, 12 Apr 2016 20:10:00 -0400 Subject: GeoIP database issues and the real world consequences In-Reply-To: <20160411172243.GG26501@sizone.org> References: <1460393711.14814.2.camel@beagle> <20160411170214.GF26501@sizone.org> <20160411171140.GA9284@bamboo.slabnet.com> <20160411172243.GG26501@sizone.org> Message-ID: <570D8E58.2030303@vaxination.ca> On 2016-04-11 13:22, Ken Chase wrote: > Well they DO know the IP location is within the USA - A friend in Australia was with an ISP onwed by a US firm and his IP address often geolocated to the USA. From jfmezei_nanog at vaxination.ca Wed Apr 13 00:12:21 2016 From: jfmezei_nanog at vaxination.ca (Jean-Francois Mezei) Date: Tue, 12 Apr 2016 20:12:21 -0400 Subject: GeoIP database issues and the real world consequences In-Reply-To: References: <1460393711.14814.2.camel@beagle> Message-ID: <570D8EE5.2000304@vaxination.ca> On 2016-04-11 13:34, Steve Mikulasik wrote: > Mather says they?re going to change them. They are picking new default locations for the U.S. and Ashburn, Virginia that are in the middle of bodies of water, Why not the White House or Wahington Monument ? Or better yet, some large office complex in Fort Meade MD :-) From jfmezei_nanog at vaxination.ca Wed Apr 13 00:13:58 2016 From: jfmezei_nanog at vaxination.ca (Jean-Francois Mezei) Date: Tue, 12 Apr 2016 20:13:58 -0400 Subject: GeoIP database issues and the real world consequences In-Reply-To: <20160411181508.60367.qmail@ary.lan> References: <20160411181508.60367.qmail@ary.lan> Message-ID: <570D8F46.2000600@vaxination.ca> Re: Sending police to middle of a lake.. Puts new meaning to a fishing expedition for police :-) From theodore at ciscodude.net Wed Apr 13 00:14:15 2016 From: theodore at ciscodude.net (Theodore Baschak) Date: Tue, 12 Apr 2016 19:14:15 -0500 Subject: GeoIP database issues and the real world consequences In-Reply-To: <570D8E58.2030303@vaxination.ca> References: <1460393711.14814.2.camel@beagle> <20160411170214.GF26501@sizone.org> <20160411171140.GA9284@bamboo.slabnet.com> <20160411172243.GG26501@sizone.org> <570D8E58.2030303@vaxination.ca> Message-ID: > On Apr 12, 2016, at 7:10 PM, Jean-Francois Mezei wrote: > > On 2016-04-11 13:22, Ken Chase wrote: >> Well they DO know the IP location is within the USA - > > > A friend in Australia was with an ISP onwed by a US firm and his IP > address often geolocated to the USA. > Similarly, IPv6 space thats been originated by a Canadian org, in Canada for 4 or 5 years is still shown as in the USA. From jfmezei_nanog at vaxination.ca Wed Apr 13 00:17:03 2016 From: jfmezei_nanog at vaxination.ca (Jean-Francois Mezei) Date: Tue, 12 Apr 2016 20:17:03 -0400 Subject: GeoIP database issues and the real world consequences In-Reply-To: References: <20160411181508.60367.qmail@ary.lan> <570BEDC9.50308@heliacal.net> Message-ID: <570D8FFF.7040105@vaxination.ca> All GeoIP services would be forced to document their default lat/long values so that users know that when these values, they know it is a generic one for that country. (or supply +181.0000 +91.00000 which is an invalid value indicating that there is no lat/long, look at country code given). From colton.conor at gmail.com Wed Apr 13 00:29:54 2016 From: colton.conor at gmail.com (Colton Conor) Date: Tue, 12 Apr 2016 19:29:54 -0500 Subject: mpls switches In-Reply-To: References: <5705A3AC.5020903@tiedyenetworks.com> <4eec1f63-0e69-ac3f-78f9-b3fb5b3de0a6@seacom.mu> Message-ID: Someone told me to check out extreme networks, cisco or Ciena for the more cost effective mpls kit. Any advice on which of the three would have the most cost effective 10G MPLS switch? Cisco's MPLS switch is the ASR 920 right? On Tue, Apr 12, 2016 at 4:13 PM, George, Wes wrote: > > On 4/12/16, 9:22 AM, "NANOG on behalf of Tim Jackson" > wrote: > > > >>> (Broadcom chipset, > >> approach with caution). > > > >QFX5100 works fine for MPLS.. [snip] QFX5100 is a > >great P and lightweight PE.. > > WG] For some values of "fine" and "great" perhaps, but emphasis on the > "lightweight" is important, as its suitability is heavily dependent on > your intended use case. > Use it with a few thousand routes and nothing particularly exotic as far > as features go and you should be fine. However, there are sometimes little > gotchas where established features (esp in MPLS) either are missing or > behave differently in subtle ways compared with more traditional JunOS > routers like the MX. Some of these are limitations in the Broadcom chipset > and some are driven by customer demand prioritizing feature completion. > > Test carefully, and regard the higher-end multidimensional/route scale > numbers with healthy skepticism. > > > Wes George > > Anything below this line has been added by my company?s mail server, I > have no control over it. > ----------- > > > > ________________________________ > > 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 mark.tinka at seacom.mu Wed Apr 13 04:49:25 2016 From: mark.tinka at seacom.mu (Mark Tinka) Date: Wed, 13 Apr 2016 06:49:25 +0200 Subject: mpls switches In-Reply-To: References: <5705A3AC.5020903@tiedyenetworks.com> <4eec1f63-0e69-ac3f-78f9-b3fb5b3de0a6@seacom.mu> Message-ID: On 13/Apr/16 02:29, Colton Conor wrote: > Someone told me to check out extreme networks, cisco or Ciena for the > more cost effective mpls kit. Any advice on which of the three would > have the most cost effective 10G MPLS switch? > > Cisco's MPLS switch is the ASR 920 right? The useful ones are the ASR920 and ME3600X/3800X. The ASR920 is the way forward, and is generally half the price of the ME3600X. Mark. From jfmezei_nanog at vaxination.ca Wed Apr 13 04:51:38 2016 From: jfmezei_nanog at vaxination.ca (Jean-Francois Mezei) Date: Wed, 13 Apr 2016 00:51:38 -0400 Subject: Connecting rural providers: ethernet to large city or nearby transit Message-ID: <570DD05A.3060104@vaxination.ca> Generic question. Say you have a municipal provider in small town where the municipality won the subsidy over the incumbent to deploy broadband. The easiest is for the town's ISP to buy transit from the incumbent. But incumbent will not be interested in offering competitive pricing. As a sanity check, would a rural ISP come out ahead getting an ethernet link to large city where cheaper transit is available as well as peering to offload a lot of traffic, or would buying transit at higher price locally end up being better ? Is the difference between the two small, or orders of magnitudes cheaper to go one way or the other ? context: in order to provide affordable backhaul to towns, the CRTC *might consider regulation. The Chairman used a key word today "market failure" indicating they are ready to listen to arguments on this. From todd.crane at n5tech.com Wed Apr 13 05:57:42 2016 From: todd.crane at n5tech.com (Todd Crane) Date: Tue, 12 Apr 2016 22:57:42 -0700 Subject: GeoIP database issues and the real world consequences In-Reply-To: <570D8FFF.7040105@vaxination.ca> References: <20160411181508.60367.qmail@ary.lan> <570BEDC9.50308@heliacal.net> <570D8FFF.7040105@vaxination.ca> Message-ID: <569C966F-14EE-44C5-A26B-C8E5E8D9186A@n5tech.com> I like (sarcasm) how everybody here either wants to point fingers at MaxMind or offer up coordinates to random places knowing that it will never happen. What ever happened to holding people responsible for being stupid. When did it start becoming ((fill in the blank)) coffee shop?s for you burning your tongue on your coffee, etc. I?ve seen/used all sorts of geolocation solutions and never once thought to myself that when a map pin was in the middle of a political boundary, that the software was telling me anything other than the place was somewhere within the boundary. Furthermore, most geolocation services will also show a zoomed-out/in map based on certainty. So if you can see more than a few hundred miles in the map that only measures 200x200 pixels, then it probably isn?t that accurate. As to a solution, why don?t we just register the locations (more or less) with ARIN? Hell, with the amount of money we all pay them in annual fees, I can?t imagine it would be too hard for them to maintain. They could offer it as part of their public whois service or even just make raw data files public. Just a though ?Todd -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: Message signed with OpenPGP using GPGMail URL: From simon at slimey.org Wed Apr 13 06:22:48 2016 From: simon at slimey.org (Simon Lockhart) Date: Wed, 13 Apr 2016 07:22:48 +0100 Subject: mpls switches In-Reply-To: References: <5705A3AC.5020903@tiedyenetworks.com> <4eec1f63-0e69-ac3f-78f9-b3fb5b3de0a6@seacom.mu> Message-ID: <20160413062247.GJ24516@dilbert.slimey.org> On Tue Apr 12, 2016 at 07:29:54PM -0500, Colton Conor wrote: > Someone told me to check out extreme networks, cisco or Ciena for the more > cost effective mpls kit. Any advice on which of the three would have the > most cost effective 10G MPLS switch? I'm using Extreme switches for VPLS - the X460 will give you up to 6 x 10G ports, and the X670 will give you 48 x 10G ports (and 4 x 40G ports). I've not tried them as P nodes (we use Cisco for that), or for any other MPLS features (L3VPN), but for VPLS they're working well for us. When we started using them, they were significantly cheaper than Cisco alternatives. Simon From JJaritsch at anexia-it.com Wed Apr 13 06:25:47 2016 From: JJaritsch at anexia-it.com (=?iso-8859-1?Q?J=FCrgen_Jaritsch?=) Date: Wed, 13 Apr 2016 06:25:47 +0000 Subject: AW: mpls switches In-Reply-To: <20160413062247.GJ24516@dilbert.slimey.org> References: <5705A3AC.5020903@tiedyenetworks.com> <4eec1f63-0e69-ac3f-78f9-b3fb5b3de0a6@seacom.mu> <20160413062247.GJ24516@dilbert.slimey.org> Message-ID: <8bedcc1c8f8547d3866058332632e051@anx-i-dag02.anx.local> Hi, L2VPN works also pretty well with the Extremes (X670). Only one thing doesn't work: LACP BPDU forwarding for the customer. This is caused by the method how Extreme let you configure the L2VPN on those small boxes. best regards J?rgen Jaritsch Head of Network & Infrastructure ANEXIA Internetdienstleistungs GmbH Telefon: +43-5-0556-300 Telefax: +43-5-0556-500 E-Mail: JJaritsch at anexia-it.com Web: http://www.anexia-it.com Anschrift Hauptsitz Klagenfurt: Feldkirchnerstra?e 140, 9020 Klagenfurt Gesch?ftsf?hrer: Alexander Windbichler Firmenbuch: FN 289918a | Gerichtsstand: Klagenfurt | UID-Nummer: AT U63216601 -----Urspr?ngliche Nachricht----- Von: NANOG [mailto:nanog-bounces at nanog.org] Im Auftrag von Simon Lockhart Gesendet: Mittwoch, 13. April 2016 08:23 An: Colton Conor Cc: nanog at nanog.org Betreff: Re: mpls switches On Tue Apr 12, 2016 at 07:29:54PM -0500, Colton Conor wrote: > Someone told me to check out extreme networks, cisco or Ciena for the more > cost effective mpls kit. Any advice on which of the three would have the > most cost effective 10G MPLS switch? I'm using Extreme switches for VPLS - the X460 will give you up to 6 x 10G ports, and the X670 will give you 48 x 10G ports (and 4 x 40G ports). I've not tried them as P nodes (we use Cisco for that), or for any other MPLS features (L3VPN), but for VPLS they're working well for us. When we started using them, they were significantly cheaper than Cisco alternatives. Simon From swmike at swm.pp.se Wed Apr 13 06:27:13 2016 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Wed, 13 Apr 2016 08:27:13 +0200 (CEST) Subject: Stop IPv6 Google traffic In-Reply-To: References: <867546809.10981.1460297868707.JavaMail.mhammett@ThunderFuck> <570A62E9.9030802@netassist.ua> <20160410143543.GA1949@angus.ind.wpi.edu> <570A674A.8020609@netassist.ua> Message-ID: On Sun, 10 Apr 2016, Damian Menscher via NANOG wrote: > Sorry to hear your legitimate users are impacted by captchas when trying to > use Google web search. This can happen when you have significant amounts > of abuse coming from your network. If switching to IPv4 means having more > users share IPs, it could make the problem worse. Instead, let's try to > quickly address the IPv6 issue. > > Please send me your IP allocation policy (off-list is fine). For example > (guessing from the list at > http://bgp.he.net/search?search%5Bsearch%5D=netassist&commit=Search): > > - 2a01:d0::/32 is allocated by /48 > - 2a01:d0:8000::/33 is allocated by /56 > - 2001:67c:1874::/48 is allocated by /64 > - ... etc (IPv4 allocation is appreciated as well, if you also provide > customers with large ranges there) > > I can then give that hint to our automated abuse systems, which will both > make it easier for us to catch your abusive customers, and also to avoid > over-blocking of your AS. Hi, just curious. Do you support the RIPE object called "assignment-size" automatically? https://apps.db.ripe.net/search/lookup.html?source=ripe&key=2001%3A980%3A3000%3A%3A/36&type=inet6num for instance, indicates that each customer in this /36 is a /48. Do you pick this up automatically and hint your abuse system about this? Does it send automatically generated abuse reports to the abuse contact as well? -- Mikael Abrahamsson email: swmike at swm.pp.se From nathana at fsr.com Wed Apr 13 09:41:54 2016 From: nathana at fsr.com (Nathan Anderson) Date: Wed, 13 Apr 2016 02:41:54 -0700 Subject: GeoIP database issues and the real world consequences In-Reply-To: <569C966F-14EE-44C5-A26B-C8E5E8D9186A@n5tech.com> References: <20160411181508.60367.qmail@ary.lan> <570BEDC9.50308@heliacal.net> <570D8FFF.7040105@vaxination.ca> <569C966F-14EE-44C5-A26B-C8E5E8D9186A@n5tech.com> Message-ID: +1; had similar thoughts, even when reading the article. However, I don't really get especially angry/frustrated with the individual idiots who ignorantly used some sort of geolocation service to try to hunt down and exact revenge on somebody whom they *thought* they were being victimized by. I'm not saying what they did was acceptable, but I fully expect that kind of behavior from the average joe. What I do get upset hearing about, though, is law enforcement agencies using that kind of data in order to execute a warrant. There is nothing actionable there, and yet from the sounds of it, some LEAs are getting search warrants or conducting raids on houses where they believe they have a solid 1-to-1 mapping of IP address to physical address. Which is absolutely inexcusable. The one area where a company like MaxMind might have some potential blame to shoulder is their marketing. I know next-to-nothing about them and their product, having only heard about them for the first time in the context of this story, so I have no idea how they represent their solutions to prospective users. And maybe it wasn't even them exaggerating what is technically possible, but some other front-end service that uses their APIs and their data. But one has to wonder how someone in law enforcement might have gotten the idea that you can plug an IP address into a service like this and get back a lat/long that accurately represents to within a few meters where that traffic originated. -- Nathan -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Todd Crane Sent: Tuesday, April 12, 2016 10:58 PM To: Jean-Francois Mezei Cc: nanog at nanog.org Subject: Re: GeoIP database issues and the real world consequences I like (sarcasm) how everybody here either wants to point fingers at MaxMind or offer up coordinates to random places knowing that it will never happen. What ever happened to holding people responsible for being stupid. When did it start becoming ((fill in the blank)) coffee shop?s for you burning your tongue on your coffee, etc. I?ve seen/used all sorts of geolocation solutions and never once thought to myself that when a map pin was in the middle of a political boundary, that the software was telling me anything other than the place was somewhere within the boundary. Furthermore, most geolocation services will also show a zoomed-out/in map based on certainty. So if you can see more than a few hundred miles in the map that only measures 200x200 pixels, then it probably isn?t that accurate. As to a solution, why don?t we just register the locations (more or less) with ARIN? Hell, with the amount of money we all pay them in annual fees, I can?t imagine it would be too hard for them to maintain. They could offer it as part of their public whois service or even just make raw data files public. Just a though ?Todd From cdel at firsthand.net Wed Apr 13 09:50:38 2016 From: cdel at firsthand.net (Christian de Larrinaga) Date: Wed, 13 Apr 2016 10:50:38 +0100 Subject: GeoIP database issues and the real world consequences In-Reply-To: <569C966F-14EE-44C5-A26B-C8E5E8D9186A@n5tech.com> References: <20160411181508.60367.qmail@ary.lan> <570BEDC9.50308@heliacal.net> <570D8FFF.7040105@vaxination.ca> <569C966F-14EE-44C5-A26B-C8E5E8D9186A@n5tech.com> Message-ID: <570E166E.4030905@firsthand.net> Really? - You want RIRs to now perpetuate an application of IPs they are not designed for? The activities of MaxMind and similar need to be exposed so people understand the problem. No matter how Geo IP businesses might back peddle and say they never intended their services to be considered as authoritative etc the fact is people including law enforcement and presumably General Hayden and friends are buying into the fallacy that IP addresses are fit for the purpose of geo location. Let's put this another way. How many LIRs accounting systems use IPs as billing / account identifiers? No? I wonder why not..... C Todd Crane > 13 April 2016 at 06:57 > I like (sarcasm) how everybody here either wants to point fingers at > MaxMind or offer up coordinates to random places knowing that it will > never happen. What ever happened to holding people responsible for > being stupid. When did it start becoming ((fill in the blank)) coffee > shop?s for you burning your tongue on your coffee, etc. I?ve seen/used > all sorts of geolocation solutions and never once thought to myself > that when a map pin was in the middle of a political boundary, that > the software was telling me anything other than the place was > somewhere within the boundary. Furthermore, most geolocation services > will also show a zoomed-out/in map based on certainty. So if you can > see more than a few hundred miles in the map that only measures > 200x200 pixels, then it probably isn?t that accurate. > > As to a solution, why don?t we just register the locations (more or > less) with ARIN? Hell, with the amount of money we all pay them in > annual fees, I can?t imagine it would be too hard for them to > maintain. They could offer it as part of their public whois service or > even just make raw data files public. > > Just a though > > ?Todd > > > Jean-Francois Mezei > 13 April 2016 at 01:17 > All GeoIP services would be forced to document their default lat/long > values so that users know that when these values, they know it is a > generic one for that country. (or supply +181.0000 +91.00000 which is an > invalid value indicating that there is no lat/long, look at country code > given). -- Christian de Larrinaga FBCS, CITP, ------------------------- @ FirstHand ------------------------- +44 7989 386778 cdel at firsthand.net ------------------------- From david at cantrell.org.uk Wed Apr 13 10:35:57 2016 From: david at cantrell.org.uk (David Cantrell) Date: Wed, 13 Apr 2016 11:35:57 +0100 Subject: GeoIP database issues and the real world consequences In-Reply-To: References: <1460393711.14814.2.camel@beagle> <20160411170214.GF26501@sizone.org> <20160411171140.GA9284@bamboo.slabnet.com> <20160411172243.GG26501@sizone.org> <570D8E58.2030303@vaxination.ca> Message-ID: <20160413103557.GA28902@bytemark.barnyard.co.uk> On Tue, Apr 12, 2016 at 07:14:15PM -0500, Theodore Baschak wrote: > > On Apr 12, 2016, at 7:10 PM, Jean-Francois Mezei wrote: > > On 2016-04-11 13:22, Ken Chase wrote: > >> Well they DO know the IP location is within the USA - > > A friend in Australia was with an ISP onwed by a US firm and his IP > > address often geolocated to the USA. > Similarly, IPv6 space thats been originated by a Canadian org, in Canada for 4 or 5 years is still shown as in the USA. There are similar problems with phone numbers. Google's libphonenumber, for example, will tell you that +1 855 266 7269 is in the US. It's not, it's Canadian. It appears that for any NANP "area code" that isn't assigned to a particular place libphonenumber just says "it's in the US" instead of "it's in one of the NANP countries". They appear to have a similar bug with Russia/Kazakhstan. -- David Cantrell From haegar at sdinet.de Wed Apr 13 11:09:35 2016 From: haegar at sdinet.de (Sven-Haegar Koch) Date: Wed, 13 Apr 2016 13:09:35 +0200 (CEST) Subject: GeoIP database issues and the real world consequences In-Reply-To: References: <20160411181508.60367.qmail@ary.lan> <570BEDC9.50308@heliacal.net> <570D8FFF.7040105@vaxination.ca> <569C966F-14EE-44C5-A26B-C8E5E8D9186A@n5tech.com> Message-ID: On Wed, 13 Apr 2016, Nathan Anderson wrote: > What I do get upset hearing about, though, is law enforcement > agencies using that kind of data in order to execute a warrant. There > is nothing actionable there, and yet from the sounds of it, some LEAs > are getting search warrants or conducting raids on houses where they > believe they have a solid 1-to-1 mapping of IP address to physical > address. Which is absolutely inexcusable. Just watch any more or less recent CSI / crime TV show. They have "an IP", enter it into some gizmo, and it spits out the address, mostly shown on a nice sat image. That is so "normal" in TV that for Bully Policeman it just has to exist, and the reaction to a webform where you can enter an IP and get an address will just be "great, now I also have this" - no further thinking to be expected. And finding a Judge signing off nearly any warrant put in front of them is also not new. c'ya sven-haegar -- Three may keep a secret, if two of them are dead. - Ben F. From nanog at ics-il.net Wed Apr 13 11:33:56 2016 From: nanog at ics-il.net (Mike Hammett) Date: Wed, 13 Apr 2016 06:33:56 -0500 (CDT) Subject: Connecting rural providers: ethernet to large city or nearby transit In-Reply-To: <570DD05A.3060104@vaxination.ca> Message-ID: <650794434.58.1460547233800.JavaMail.mhammett@ThunderFuck> Get backhaul to somewhere useful. Do not buy from the incumbent. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Jean-Francois Mezei" To: Nanog at nanog.org Sent: Tuesday, April 12, 2016 11:51:38 PM Subject: Connecting rural providers: ethernet to large city or nearby transit Generic question. Say you have a municipal provider in small town where the municipality won the subsidy over the incumbent to deploy broadband. The easiest is for the town's ISP to buy transit from the incumbent. But incumbent will not be interested in offering competitive pricing. As a sanity check, would a rural ISP come out ahead getting an ethernet link to large city where cheaper transit is available as well as peering to offload a lot of traffic, or would buying transit at higher price locally end up being better ? Is the difference between the two small, or orders of magnitudes cheaper to go one way or the other ? context: in order to provide affordable backhaul to towns, the CRTC *might consider regulation. The Chairman used a key word today "market failure" indicating they are ready to listen to arguments on this. From laszlo at heliacal.net Wed Apr 13 12:40:19 2016 From: laszlo at heliacal.net (Laszlo Hanyecz) Date: Wed, 13 Apr 2016 12:40:19 +0000 Subject: GeoIP database issues and the real world consequences In-Reply-To: <569C966F-14EE-44C5-A26B-C8E5E8D9186A@n5tech.com> References: <20160411181508.60367.qmail@ary.lan> <570BEDC9.50308@heliacal.net> <570D8FFF.7040105@vaxination.ca> <569C966F-14EE-44C5-A26B-C8E5E8D9186A@n5tech.com> Message-ID: <570E3E33.8090303@heliacal.net> On 2016-04-13 05:57, Todd Crane wrote: > As to a solution, why don?t we just register the locations (more or less) with ARIN? Hell, with the amount of money we all pay them in annual fees, I can?t imagine it would be too hard for them to maintain. They could offer it as part of their public whois service or even just make raw data files public. > > Just a though > > ?Todd > > Ultimately these services want to locate users, not routers, servers, tablets and such. If you want to answer the question "where is the user?" then you have to ask them - only they know the answer - not their ISP, not ARIN, not DNS. If you really insist on using the IP address, then maybe you could connect to it and ask it, like an identd scheme. This could be built into a web browser and prompt the user asking permission. As long as we're using a static list of number -> location we will just be guessing and hoping they stay near the assumed location and we're not too wrong. This whole practice of trying to map network numbers is the problem. Also note that one of the things that wasn't explicitly mentioned in the original article but was hinted at was the use of something similar to Skyhook, another static list of address -> location. It sounded like the 'find my phone' services were leading people to an Atlanta home based on having a wireless access point that was recorded as being there. This is similarly wrong, but not the same as geolocating IP addresses. It geolocates wireless AP MAC addresses. You can really see this break down when the wireless AP is on a bus. -Laszlo From bhatton at htva.net Wed Apr 13 12:47:54 2016 From: bhatton at htva.net (Benjamin Hatton) Date: Wed, 13 Apr 2016 08:47:54 -0400 Subject: Connecting rural providers: ethernet to large city or nearby transit In-Reply-To: <650794434.58.1460547233800.JavaMail.mhammett@ThunderFuck> References: <570DD05A.3060104@vaxination.ca> <650794434.58.1460547233800.JavaMail.mhammett@ThunderFuck> Message-ID: We were in a similar situation, smaller rural (although in our case private) provider making the choice between continuing to buy transit from our neighbor (big ISP) whom we compete with in certain towns, or getting ~300 miles of backhaul to NYC and buying transit there. We came off significantly ahead (10g protected wave + 10g IP transit for about the same as 2g from the large ISP) going with backhaul. It all comes down to who you have going through the area that can give you backhaul. If the incumbent ISP is the only game in the area, then they would be your backhaul provider, as buildout to a rural area would be prohibitively expensive -- *Ben Hatton* Network Engineer Haefele TV Inc. bhatton at htva.net www.htva.net From Valdis.Kletnieks at vt.edu Wed Apr 13 13:11:11 2016 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Wed, 13 Apr 2016 09:11:11 -0400 Subject: GeoIP database issues and the real world consequences In-Reply-To: <570D8FFF.7040105@vaxination.ca> References: <20160411181508.60367.qmail@ary.lan> <570BEDC9.50308@heliacal.net> <570D8FFF.7040105@vaxination.ca> Message-ID: <59346.1460553071@turing-police.cc.vt.edu> On Tue, 12 Apr 2016 20:17:03 -0400, Jean-Francois Mezei said: > All GeoIP services would be forced to How? -------------- 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 Wed Apr 13 13:25:05 2016 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Wed, 13 Apr 2016 09:25:05 -0400 Subject: GeoIP database issues and the real world consequences In-Reply-To: <569C966F-14EE-44C5-A26B-C8E5E8D9186A@n5tech.com> References: <20160411181508.60367.qmail@ary.lan> <570BEDC9.50308@heliacal.net> <570D8FFF.7040105@vaxination.ca> <569C966F-14EE-44C5-A26B-C8E5E8D9186A@n5tech.com> Message-ID: <60434.1460553905@turing-police.cc.vt.edu> On Tue, 12 Apr 2016 22:57:42 -0700, Todd Crane said: >.What ever happened to holding people responsible for being > stupid. When did it start becoming ((fill in the blank)) coffee shop > for you burning your tongue on your coffee Whatever happened to holding people responsible for fact checking before they post? :) You *do* realize that the woman in the McDonald's case got *third degree* burns and required skin grafts, right? Water at 180F is hot enough to burn you - we even have a word for it: scalding. And unlike sipping too-hot coffee, where you can spit it out quickly, hot water spilled on clothing continues to burn until the clothing is removed or cooled off - neither of which is feasible when you're elderly and seated in a car. And that she originally only sued for the cost of her medical bills, and the jury increased it with punitive damages when presented evidence that over 700 other people had received burns? Now go and get informed, and commit this sin no more :) https://www.caoc.org/?pg=facts - how that lawsuit *actually* played out. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From johnl at iecc.com Wed Apr 13 15:31:47 2016 From: johnl at iecc.com (John Levine) Date: 13 Apr 2016 15:31:47 -0000 Subject: GeoIP database issues and the real world consequences In-Reply-To: <20160413103557.GA28902@bytemark.barnyard.co.uk> Message-ID: <20160413153147.14523.qmail@ary.lan> >There are similar problems with phone numbers. Google's libphonenumber, >for example, will tell you that +1 855 266 7269 is in the US. It's not, >it's Canadian. It appears that for any NANP "area code" that isn't >assigned to a particular place libphonenumber just says "it's in the US" >instead of "it's in one of the NANP countries". Actually, it's probably both US and Canadian. When you call an 8xx toll free number, the switch uses a database to route the call to whatever carrier handles it, who can then do whatever they want. The provider for that number, Callture, is in Ontario but they can terminate the calls anywhere, and send each call to a different lace. Also, in fairness, the US is about 90% of the NANP, so guessing that an 8XX number is in the US is usually correct. R's, John From jfmezei_nanog at vaxination.ca Wed Apr 13 15:42:36 2016 From: jfmezei_nanog at vaxination.ca (Jean-Francois Mezei) Date: Wed, 13 Apr 2016 11:42:36 -0400 Subject: GeoIP database issues and the real world consequences In-Reply-To: <59346.1460553071@turing-police.cc.vt.edu> References: <20160411181508.60367.qmail@ary.lan> <570BEDC9.50308@heliacal.net> <570D8FFF.7040105@vaxination.ca> <59346.1460553071@turing-police.cc.vt.edu> Message-ID: <570E68EC.2060102@vaxination.ca> On 2016-04-13 09:11, Valdis.Kletnieks at vt.edu wrote: > On Tue, 12 Apr 2016 20:17:03 -0400, Jean-Francois Mezei said: >> All GeoIP services would be forced to > > How? Fair point. However, considering more and more outfits block content based on IP geolocation, once has to wonder if an outfit such as the FTC could mandate certain standards and disclosure of inaccuracy of IP geolocation. Or the other way around (shudded) mandate that outfits such as ARIN ensure IP blocks are accurately configured/registered to provide accurate geolocation within state/province for instance. By documenting that IP blocks only resolve to state/province, this would set the implicit standard that any IP geolocation service that claims more precise gelocation is bogus. And mandating IP blocks be limited to state/province would be a big enough headache-causing undertaking as large number of ISPs and organisations span this and want to have abilityto move blocks around to cope with demand increasing more in one state than the other etc. So that leaves ARIN mandating and documenting that IP blocks be accurately registered on a country basis within its territory. This would allow proper geolocation/blocking for outfits like Netflix but be documented as being unusable to track an IP down to state, city, street/home. When ARIN makes IP block database available for download, it should have an "agree" button to terms and conditions that would prevent the user of the data from claiming accuracy greater than "countrty". Just an idea. From david at cantrell.org.uk Wed Apr 13 16:39:19 2016 From: david at cantrell.org.uk (David Cantrell) Date: Wed, 13 Apr 2016 17:39:19 +0100 Subject: GeoIP database issues and the real world consequences In-Reply-To: <20160413153147.14523.qmail@ary.lan> References: <20160413103557.GA28902@bytemark.barnyard.co.uk> <20160413153147.14523.qmail@ary.lan> Message-ID: <20160413163919.GA720@bytemark.barnyard.co.uk> On Wed, Apr 13, 2016 at 03:31:47PM -0000, John Levine wrote: > >There are similar problems with phone numbers. Google's libphonenumber, > >for example, will tell you that +1 855 266 7269 is in the US. It's not, > >it's Canadian ... > Actually, it's probably both US and Canadian. When you call an 8xx > toll free number, the switch uses a database to route the call to > whatever carrier handles it, who can then do whatever they want. The > provider for that number, Callture, is in Ontario but they can > terminate the calls anywhere, and send each call to a different lace. I was careful to pick a number on a Canadian company's website. > Also, in fairness, the US is about 90% of the NANP, so guessing that > an 8XX number is in the US is usually correct. That's another way of saying that it's deliberately wrong 10% of the time for pan-NANP prefixes. Better to say "I don't know" than to just guess. -- David Cantrell | Official London Perl Mongers Bad Influence From colton.conor at gmail.com Wed Apr 13 18:30:43 2016 From: colton.conor at gmail.com (Colton Conor) Date: Wed, 13 Apr 2016 13:30:43 -0500 Subject: mpls switches In-Reply-To: References: <5705A3AC.5020903@tiedyenetworks.com> <4eec1f63-0e69-ac3f-78f9-b3fb5b3de0a6@seacom.mu> Message-ID: How does the ASR 903 compare to the 920? When we got pricing for the ASR 903 it was more expensive than a real ASR 9k router. On Tue, Apr 12, 2016 at 11:49 PM, Mark Tinka wrote: > > > On 13/Apr/16 02:29, Colton Conor wrote: > > Someone told me to check out extreme networks, cisco or Ciena for the > more cost effective mpls kit. Any advice on which of the three would have > the most cost effective 10G MPLS switch? > > Cisco's MPLS switch is the ASR 920 right? > > > The useful ones are the ASR920 and ME3600X/3800X. > > The ASR920 is the way forward, and is generally half the price of the > ME3600X. > > Mark. > From johnl at iecc.com Wed Apr 13 19:15:50 2016 From: johnl at iecc.com (John Levine) Date: 13 Apr 2016 19:15:50 -0000 Subject: phone fun, was GeoIP database issues and the real world consequences In-Reply-To: <20160413163919.GA720@bytemark.barnyard.co.uk> Message-ID: <20160413191550.15049.qmail@ary.lan> >> Actually, it's probably both US and Canadian. When you call an 8xx >> toll free number, the switch uses a database to route the call to >> whatever carrier handles it, who can then do whatever they want. The >> provider for that number, Callture, is in Ontario but they can >> terminate the calls anywhere, and send each call to a different place. > >I was careful to pick a number on a Canadian company's website. Doesn't matter. In the NANP, toll free 8xx numbers are routed by carrier, not by geography, and it looks like this company handles traffic in the US, too. It's entirely possible that when you call that number during the day you get someone in Toronto, and when you call it at night, you get an answering service in the Phillipines. >> Also, in fairness, the US is about 90% of the NANP, so guessing that >> an 8XX number is in the US is usually correct. > >That's another way of saying that it's deliberately wrong 10% of the >time for pan-NANP prefixes. Better to say "I don't know" than to just >guess. Really, they're not assigned to locations, they're assigned to carriers. They can even be assigned to different carriers in different countries although that's not common. More to the point, saying "somewhere in the US", even if it's occasionally wrong, will not send nitwits with guns to a particular location. NANP geographical numbers can be located to a switch (give or take number portability within a LATA), but non-geographic numbers can really go anywhere. On the third hand, it's still true that the large majority of them are in the U.S. R's, John From mark.tinka at seacom.mu Wed Apr 13 19:17:45 2016 From: mark.tinka at seacom.mu (Mark Tinka) Date: Wed, 13 Apr 2016 21:17:45 +0200 Subject: mpls switches In-Reply-To: References: <5705A3AC.5020903@tiedyenetworks.com> <4eec1f63-0e69-ac3f-78f9-b3fb5b3de0a6@seacom.mu> Message-ID: <22e871d1-4209-d79c-f862-b1860bb03a8b@seacom.mu> On 13/Apr/16 20:30, Colton Conor wrote: > How does the ASR 903 compare to the 920? When we got pricing for the > ASR 903 it was more expensive than a real ASR 9k router. Feature-wise, it's more mature than the ASR920, as it came before. Personally, I find it more of a device where you need a mix-and-match, e.g., at a RAN site. Not my kind of thing; I focus purely on Ethernet in a small form factor, which the ASR920 does very well. But I'd move this query to c-nsp. There are a bunch of good folk there that use the ASR903 and can speak more authoritatively about it than I can. Mark. From owen at delong.com Wed Apr 13 19:25:23 2016 From: owen at delong.com (Owen DeLong) Date: Wed, 13 Apr 2016 12:25:23 -0700 Subject: phone fun, was GeoIP database issues and the real world consequences In-Reply-To: <20160413191550.15049.qmail@ary.lan> References: <20160413191550.15049.qmail@ary.lan> Message-ID: <78025EFB-3007-458B-9A55-1E5FD57F97FA@delong.com> > On Apr 13, 2016, at 12:15 , John Levine wrote: > >>> Actually, it's probably both US and Canadian. When you call an 8xx >>> toll free number, the switch uses a database to route the call to >>> whatever carrier handles it, who can then do whatever they want. The >>> provider for that number, Callture, is in Ontario but they can >>> terminate the calls anywhere, and send each call to a different place. >> >> I was careful to pick a number on a Canadian company's website. > > Doesn't matter. In the NANP, toll free 8xx numbers are routed by > carrier, not by geography, and it looks like this company handles > traffic in the US, too. It's entirely possible that when you call > that number during the day you get someone in Toronto, and when you > call it at night, you get an answering service in the Phillipines. > >>> Also, in fairness, the US is about 90% of the NANP, so guessing that >>> an 8XX number is in the US is usually correct. >> >> That's another way of saying that it's deliberately wrong 10% of the >> time for pan-NANP prefixes. Better to say "I don't know" than to just >> guess. > > Really, they're not assigned to locations, they're assigned to > carriers. They can even be assigned to different carriers in > different countries although that's not common. > > More to the point, saying "somewhere in the US", even if it's > occasionally wrong, will not send nitwits with guns to a particular > location. NANP geographical numbers can be located to a switch (give > or take number portability within a LATA), but non-geographic numbers > can really go anywhere. On the third hand, it's still true that the > large majority of them are in the U.S. Would you agree that 408-921 is a geographic number? I guarantee you that there are phones within that prefix within US/Calif/LATA-1 and also some well outside of that, probably not even in the same country. I will also guarantee you that those phones move locations quite frequently. Owen From johnl at iecc.com Wed Apr 13 19:45:04 2016 From: johnl at iecc.com (John R. Levine) Date: 13 Apr 2016 15:45:04 -0400 Subject: phone fun, was GeoIP database issues and the real world consequences In-Reply-To: <78025EFB-3007-458B-9A55-1E5FD57F97FA@delong.com> References: <20160413191550.15049.qmail@ary.lan> <78025EFB-3007-458B-9A55-1E5FD57F97FA@delong.com> Message-ID: >> NANP geographical numbers can be located to a switch (give >> or take number portability within a LATA), but non-geographic numbers >> can really go anywhere. On the third hand, it's still true that the >> large majority of them are in the U.S. > > Would you agree that 408-921 is a geographic number? No. It's a prefix, assigned to the at&t switch in west San Jose. > I guarantee you that there are phones within that prefix within > US/Calif/LATA-1 and also some well outside of that, probably not even in > the same country. Who said anything about phones? Could you describe what "geographic numbers can be located to a switch" means to you? Helpfully, John From owen at delong.com Wed Apr 13 20:12:46 2016 From: owen at delong.com (Owen DeLong) Date: Wed, 13 Apr 2016 13:12:46 -0700 Subject: phone fun, was GeoIP database issues and the real world consequences In-Reply-To: References: <20160413191550.15049.qmail@ary.lan> <78025EFB-3007-458B-9A55-1E5FD57F97FA@delong.com> Message-ID: <5B6E932D-7A22-45A4-B04C-787718150FF5@delong.com> > On Apr 13, 2016, at 12:45 , John R. Levine wrote: > >>> NANP geographical numbers can be located to a switch (give >>> or take number portability within a LATA), but non-geographic numbers >>> can really go anywhere. On the third hand, it's still true that the >>> large majority of them are in the U.S. >> >> Would you agree that 408-921 is a geographic number? > > No. It's a prefix, assigned to the at&t switch in west San Jose. > >> I guarantee you that there are phones within that prefix within US/Calif/LATA-1 and also some well outside of that, probably not even in the same country. > > Who said anything about phones? Could you describe what "geographic numbers can be located to a switch" means to you? I guarantee you that many, if not most at this point, of those numbers are no longer actually handled by that switch most of the time. I suspect that there are more SS7 exceptions than default within that particular prefix which is why I chose it. Owen From beckman at angryox.com Wed Apr 13 20:18:34 2016 From: beckman at angryox.com (Peter Beckman) Date: Wed, 13 Apr 2016 16:18:34 -0400 Subject: phone fun, was GeoIP database issues and the real world consequences In-Reply-To: References: <20160413191550.15049.qmail@ary.lan> <78025EFB-3007-458B-9A55-1E5FD57F97FA@delong.com> Message-ID: On Wed, 13 Apr 2016, John R. Levine wrote: >>> NANP geographical numbers can be located to a switch (give >>> or take number portability within a LATA), but non-geographic numbers >>> can really go anywhere. On the third hand, it's still true that the >>> large majority of them are in the U.S. >> >> Would you agree that 408-921 is a geographic number? > > No. It's a prefix, assigned to the at&t switch in west San Jose. And further to that, throw in Local Number Portability (LNP) and you really need to know the full number in order to know which switch the specific number is assigned to. Not all 408-921 prefixed numbers will go to that switch in West San Jose. >> I guarantee you that there are phones within that prefix within >> US/Calif/LATA-1 and also some well outside of that, probably not even in >> the same country. > > Who said anything about phones? Could you describe what "geographic numbers > can be located to a switch" means to you? In the same way that an IP address and it's "location" is amorphous, the physical location in which a phone call to a given phone number is answered could be anywhere. There could be a forward on it that sends a call made to US number +1 408-192-4135[1] to a phone in Latvia. Or it rings to a computer in London, which forwards it to Brussels. A phone number, like an IP address, can only imply a physical location. It is not a guarantee, and that hint can range from moderately accurate to wildly wrong. Beckman [1] Intentionally invalid NANPA, for example purposes only --------------------------------------------------------------------------- Peter Beckman Internet Guy beckman at angryox.com http://www.angryox.com/ --------------------------------------------------------------------------- From jfmezei_nanog at vaxination.ca Wed Apr 13 20:34:39 2016 From: jfmezei_nanog at vaxination.ca (Jean-Francois Mezei) Date: Wed, 13 Apr 2016 16:34:39 -0400 Subject: phone fun, was GeoIP database issues and the real world consequences In-Reply-To: References: <20160413191550.15049.qmail@ary.lan> <78025EFB-3007-458B-9A55-1E5FD57F97FA@delong.com> Message-ID: <570EAD5F.8010502@vaxination.ca> On 2016-04-13 16:18, Peter Beckman wrote: > And further to that, throw in Local Number Portability (LNP) and you > really need to know the full number in order to know which switch the > specific number is assigned to. Not all 408-921 prefixed numbers will go > to that switch in West San Jose. Is there the equivalent of BGP for number portability where every telco has the full table of who owns each prefix as well as individual routes for ported numbers ? Or is there a central database that is consulted before a dialed number starts to be connected so originating telco knows to send call ? Or does the originating telco route the call to the original onwer of the prefix and lets that original owner figure out how to terminate the call ? >From a long distance billing point of view, if Bell Canada connects to a number originally onwed by AT&T but ported to Verizon, with whom would Bell share long distance revenues ? From owen at delong.com Wed Apr 13 20:52:13 2016 From: owen at delong.com (Owen DeLong) Date: Wed, 13 Apr 2016 13:52:13 -0700 Subject: phone fun, was GeoIP database issues and the real world consequences In-Reply-To: <570EAD5F.8010502@vaxination.ca> References: <20160413191550.15049.qmail@ary.lan> <78025EFB-3007-458B-9A55-1E5FD57F97FA@delong.com> <570EAD5F.8010502@vaxination.ca> Message-ID: <51EF4557-555B-4D51-B8AE-731D29551A5A@delong.com> > On Apr 13, 2016, at 13:34 , Jean-Francois Mezei wrote: > > On 2016-04-13 16:18, Peter Beckman wrote: > >> And further to that, throw in Local Number Portability (LNP) and you >> really need to know the full number in order to know which switch the >> specific number is assigned to. Not all 408-921 prefixed numbers will go >> to that switch in West San Jose. > > > Is there the equivalent of BGP for number portability where every telco > has the full table of who owns each prefix as well as individual routes > for ported numbers ? Sort of, but it?s called SS7 and it?s really more like multiple layers of DNS than like BGP. > Or is there a central database that is consulted before a dialed number > starts to be connected so originating telco knows to send call ? Well, yes and no, but AIUI, the common SS7 database is a lot more like the DNS root zone. > Or does the originating telco route the call to the original onwer of > the prefix and lets that original owner figure out how to terminate the > call ? Generally within a country code (NANP is one country code even though it?s many countries (US, CA, much of the Caribbean), the central SS7 database will do a longest-match pointed to the correct Telco and possibly the correct switch at that telco. However, there are all kinds of different redirects possible within said telco as well, such as call forwarding (in multiple forms), cellular registration, VOIP gateways with portable SIP registrations, etc. >> From a long distance billing point of view, if Bell Canada connects to a > number originally onwed by AT&T but ported to Verizon, with whom would > Bell share long distance revenues ? Generally, Verizon. AT&T won?t usually participate in the call process at all. (see above). Owen From bms at fastmail.net Wed Apr 13 20:54:18 2016 From: bms at fastmail.net (Bruce Simpson) Date: Wed, 13 Apr 2016 21:54:18 +0100 Subject: Juniper vMX evaluation - how? Message-ID: <570EB1FA.5000509@fastmail.net> Pardon if this is off-topic -- but this is really beginning to wind me up. So, http://www.juniper.net/us/en/dm/free-vmx-trial/ shows that Juniper Networks vMX is available for a 60-day evaluation. This requires filling out a form to create an account on juniper.net. I don't currently have such a login. $CLIENT filled out such a form well over a month ago, and never heard anything back. Normally, I'd expect to be able to download as soon as an account is approved. Meanwhile, we get preoccupied with other tasks. Is some special magic required to acquire an evaluation copy? The 60 day trial license is directly downloadable from the above link, but the tarball is not. $CLIENT was just referred to it by $RESELLER. From tom.kac at gmail.com Wed Apr 13 20:58:55 2016 From: tom.kac at gmail.com (Tom Kacprzynski) Date: Wed, 13 Apr 2016 15:58:55 -0500 Subject: CHI-NOG 06 Conference Agenda Message-ID: We are pleased to announce that the Chicago Network Operators Group will host their 6th annual meeting (CHI-NOG 06) on May 12th, 2016 in Chicago, IL. Presentation | Speaker 1. CHI-NOG Welcome and Introduction | Tom Kacprzynski 2. BGP Security: An Overview | Russ White 3. IPv6: Passing on Lessons Learned from My Journey | Denise Fishburne 4. EVPN: Or How I Learned to Stop Worrying and Love the BGP | Tom Dwyer and Clay Haynes 5. InterTubes: A Study of the US Long-Haul Fiber-Optic Infrastructure | Rakrishnan Durairajan 6. VXLAN Deployment in IX Fabrics | Hemanth Maturi 7. Regional IXP Introductions and OPEN-IX Overview 8. Source Routing Re-Imagined | Nick Slabakov 9. Segment Routing ? Traffic Engineering | Diptanshu Singh 10. DDoS Threat Landscape | Ron Winward 11. Network Automation, A Practical Approach | Matt Griswold 12. Modern Tools for Visualizing Network Traffic | Jon Dugan 13. NetFlow, Flow-Like Data and Their Many Uses | Avi Freedman 14. The Real Metric in Evaluating CDN Performance | Matt Levine 15. Social Event Detailed agenda can be found at http://chinog.org/meetings/chi-nog-06/agenda/ Registration is still open, but ending soon. For more details please see http://chinog.org Thank you. From jhaustin at gmail.com Wed Apr 13 20:58:50 2016 From: jhaustin at gmail.com (Jeremy Austin) Date: Wed, 13 Apr 2016 12:58:50 -0800 Subject: Juniper vMX evaluation - how? In-Reply-To: <570EB1FA.5000509@fastmail.net> References: <570EB1FA.5000509@fastmail.net> Message-ID: On Wed, Apr 13, 2016 at 12:54 PM, Bruce Simpson wrote: > > Is some special magic required to acquire an evaluation copy? The 60 day > trial license is directly downloadable from the above link, but the tarball > is not. $CLIENT was just referred to it by $RESELLER. I'd be interested as well ? I submitted a form, nothing but crickets. -- Jeremy Austin (907) 895-2311 (907) 803-5422 jhaustin at gmail.com Heritage NetWorks Whitestone Power & Communications Vertical Broadband, LLC Schedule a meeting: http://doodle.com/jermudgeon From joshbaird at gmail.com Wed Apr 13 21:14:51 2016 From: joshbaird at gmail.com (Josh Baird) Date: Wed, 13 Apr 2016 17:14:51 -0400 Subject: Juniper vMX evaluation - how? In-Reply-To: References: <570EB1FA.5000509@fastmail.net> Message-ID: It was a struggle to get anywhere with vMX when we last tried ~8months ago. Nobody at Juniper seemed to know anything about it or who to talk to. In any event, you may be able to get more information by asking over at juniper-nsp at . Josh On Wed, Apr 13, 2016 at 4:58 PM, Jeremy Austin wrote: > On Wed, Apr 13, 2016 at 12:54 PM, Bruce Simpson wrote: > > > > > Is some special magic required to acquire an evaluation copy? The 60 day > > trial license is directly downloadable from the above link, but the > tarball > > is not. $CLIENT was just referred to it by $RESELLER. > > > I'd be interested as well ? I submitted a form, nothing but crickets. > > > -- > Jeremy Austin > > (907) 895-2311 > (907) 803-5422 > jhaustin at gmail.com > > Heritage NetWorks > Whitestone Power & Communications > Vertical Broadband, LLC > > Schedule a meeting: http://doodle.com/jermudgeon > From rcarpen at network1.net Wed Apr 13 21:23:51 2016 From: rcarpen at network1.net (Randy Carpenter) Date: Wed, 13 Apr 2016 17:23:51 -0400 (EDT) Subject: Juniper vMX evaluation - how? In-Reply-To: <570EB1FA.5000509@fastmail.net> References: <570EB1FA.5000509@fastmail.net> Message-ID: <57891327.924467.1460582631780.JavaMail.zimbra@network1.net> Creating the juniper.net account should be pretty straightforward. If there is an issue in getting the login to work, I would contact Juniper. If they are an authorized partner, then $RESELLER would surely have access to the download. thanks, -Randy ----- On Apr 13, 2016, at 4:54 PM, Bruce Simpson bms at fastmail.net wrote: > Pardon if this is off-topic -- but this is really beginning to wind me up. > > So, http://www.juniper.net/us/en/dm/free-vmx-trial/ shows that Juniper > Networks vMX is available for a 60-day evaluation. This requires filling > out a form to create an account on juniper.net. > > I don't currently have such a login. $CLIENT filled out such a form well > over a month ago, and never heard anything back. Normally, I'd expect to > be able to download as soon as an account is approved. Meanwhile, we get > preoccupied with other tasks. > > Is some special magic required to acquire an evaluation copy? The 60 day > trial license is directly downloadable from the above link, but the > tarball is not. $CLIENT was just referred to it by $RESELLER. From mcdermj at xenotropic.com Mon Apr 11 17:10:23 2016 From: mcdermj at xenotropic.com (Jeremy McDermond) Date: Mon, 11 Apr 2016 10:10:23 -0700 Subject: GeoIP database issues and the real world consequences In-Reply-To: <20160411170214.GF26501@sizone.org> References: <1460393711.14814.2.camel@beagle> <20160411170214.GF26501@sizone.org> Message-ID: > On Apr 11, 2016, at 10:02 AM, Ken Chase wrote: > > Cant believe law enforcement is using this kind of info to execute searches. > Wouldnt that undermine the credibility of any evidence brought up in trials > for any geoip locates? What overworked and underpaid public defender is going to know enough to challenge the ?evidence?? What judge is going to know enough to call BS on the search warrant affidavit? A good number of the judges in Oregon used to work for one of the DA?s offices, you think they question law enforcement affidavits very aggressively? > /kc -- Jeremy McDermond (NH6Z) Xenotropic Systems mcdermj at xenotropic.com From carlosm3011 at gmail.com Mon Apr 11 20:54:40 2016 From: carlosm3011 at gmail.com (Carlos M. Martinez) Date: Mon, 11 Apr 2016 17:54:40 -0300 Subject: GeoIP database issues and the real world consequences In-Reply-To: References: <1460393711.14814.2.camel@beagle> <20160411170214.GF26501@sizone.org> <20160411171140.GA9284@bamboo.slabnet.com> Message-ID: <570C0F10.5080206@gmail.com> Or (90S,0), so they get a bit of fresh air and have some time think during the voyage :-) On 4/11/16 2:14 PM, Josh Luthman wrote: > Or 0,0, send the FBI to Africa on a boating trip. that would probably be > easier than "unknown" or "null". > > > Josh Luthman > Office: 937-552-2340 > Direct: 937-552-2343 > 1100 Wayne St > Suite 1337 > Troy, OH 45373 > > On Mon, Apr 11, 2016 at 1:11 PM, Hugo Slabbert wrote: > >> >> On Mon 2016-Apr-11 13:02:14 -0400, Ken Chase wrote: >> >> TL;DR: GeoIP put unknown IP location mappings to the 'center of the >>> country' >>> but then rounded off the lat long so it points at this farm. >>> >>> Cant believe law enforcement is using this kind of info to execute >>> searches. >>> Wouldnt that undermine the credibility of any evidence brought up in >>> trials >>> for any geoip locates? >>> >>> Seems to me locating unknowns somewhere in the middle of a big lake or >>> park in >>> the center of the country might be a better idea. >>> >> >> ...how about actually marking an unknown as...oh, I dunno: "unknown"? Is >> there no analogue in the GeoIP lookups for a 404? >> >> >>> /kc >>> >> >> -- >> Hugo Slabbert | email, xmpp/jabber: hugo at slabnet.com >> pgp key: B178313E | also on Signal >> >> >> >>> On Mon, Apr 11, 2016 at 11:55:11AM -0500, Chris Boyd said: >>> > >>> >Interesting article. >>> > >>> >http://fusion.net/story/287592/internet-mapping-glitch-kansas-farm/ >>> > >>> >An hour???s drive from Wichita, Kansas, in a little town called Potwin, >>> >there is a 360-acre piece of land with a very big problem. >>> > >>> >The plot has been owned by the Vogelman family for more than a hundred >>> >years, though the current owner, Joyce Taylor n??e Vogelman, 82, now >>> >rents it out. The acreage is quiet and remote: a farm, a pasture, an old >>> >orchard, two barns, some hog shacks and a two-story house. It???s the >>> kind >>> >of place you move to if you want to get away from it all. The nearest >>> >neighbor is a mile away, and the closest big town has just 13,000 >>> >people. It is real, rural America; in fact, it???s a two-hour drive from >>> >the exact geographical center of the United States. >>> > >>> >But instead of being a place of respite, the people who live on Joyce >>> >Taylor???s land find themselves in a technological horror story. >>> > >>> > >>> >For the last decade, Taylor and her renters have been visited by all >>> >kinds of mysterious trouble. They???ve been accused of being identity >>> >thieves, spammers, scammers and fraudsters. They???ve gotten visited by >>> >FBI agents, federal marshals, IRS collectors, ambulances searching for >>> >suicidal veterans, and police officers searching for runaway children. >>> >They???ve found people scrounging around in their barn. The renters have >>> >been doxxed, their names and addresses posted on the internet by >>> >vigilantes. Once, someone left a broken toilet in the driveway as a >>> >strange, indefinite threat. >>> > >>> >--Chris >>> > >>> >> From mdehghani at hamyar.net Tue Apr 12 06:10:29 2016 From: mdehghani at hamyar.net (Mohsen Dehghani) Date: Tue, 12 Apr 2016 10:40:29 +0430 Subject: Problem with CoA on Cisco ASR 1000 Message-ID: <005701d19482$03baad00$0b300700$@hamyar.net> Hello Team, I have a problem in updating PPPoE session policy-map via RADIUS CoA packet. When the RADIUS sends CoA to the BRAS, the policy of PPPoE session would not update. My software is asr1000rp2-adventerprisek9.03.13.00.S.154-3.S-ext.bin and The result of "debug aaa coa" is as follows: *Apr 11 04:55:42.152: COA: 80.191.122.6 request queued *Apr 11 04:55:42.152: RADIUS: authenticator 2C D3 08 A2 34 72 FB F2 - 5C 3C A4 F9 81 09 4D 77 *Apr 11 04:55:42.152: RADIUS: Vendor, Cisco [26] 11 *Apr 11 04:55:42.152: RADIUS: Sub_Policy_In [37] 5 "256" *Apr 11 04:55:42.152: RADIUS: Vendor, Cisco [26] 11 *Apr 11 04:55:42.152: RADIUS: Sub_Policy_Out [38] 5 "256" *Apr 11 04:55:42.152: RADIUS: Acct-Session-Id [44] 10 "001195E5" *Apr 11 04:55:42.152: COA: Message Authenticator missing or failed decode *Apr 11 04:55:42.152: ++++++ CoA Attribute List ++++++ *Apr 11 04:55:42.152: 7F78B212D7A8 0 00000081 sub-policy-In(420) 3 256 *Apr 11 04:55:42.152: 7F78B211FCA0 0 00000081 sub-policy-Out(422) 3 256 *Apr 11 04:55:42.152: 7F78B211FCE0 0 00000001 session-id(408) 4 1152485(1195E5) *Apr 11 04:55:42.152: *Apr 11 04:55:42.153: ++++++ Received CoA response Attribute List ++++++ *Apr 11 04:55:42.153: 7F78C82755D0 0 00000081 ssg-command-code(490) 2 10 00 *Apr 11 04:55:42.153: 7F78C8275610 0 00000001 session-id(408) 4 1152485(1195E5) *Apr 11 04:55:42.153: 7F78C8275650 0 00000081 ssg-account-info(488) 22 $IVirtual-Access2.5184 Any Help would be really appreciated. From ben at adversary.org Tue Apr 12 07:54:55 2016 From: ben at adversary.org (Ben McGinnes) Date: Tue, 12 Apr 2016 17:54:55 +1000 Subject: GeoIP database issues and the real world consequences In-Reply-To: <570C82CD.2070405@efes.iucc.ac.il> References: <1460393711.14814.2.camel@beagle> <570C82CD.2070405@efes.iucc.ac.il> Message-ID: <20160412075455.GA38616@adversary.org> On Tue, Apr 12, 2016 at 08:08:29AM +0300, Hank Nussbacher wrote: > On 12/04/2016 00:41, Ricky Beam wrote: > > On Mon, 11 Apr 2016 12:55:11 -0400, Chris Boyd > > wrote: > >> Interesting article. > >> > >> http://fusion.net/story/287592/internet-mapping-glitch-kansas-farm/ > > ... > > > > "Until you reached out to us, we were unaware that there were issues..." > > > > Bull! I can dig up dozens (if not hundreds) of emails from coworkers > > and customers who have complained to MaxMind about their asinine > > we-don't-have-a-frakin-clue results. They've known for years! They're > > paid for a definitive answer, not an "unknown", which is why the > > default answer is the same near-the-center-of-the-country lat/lon. He, > > personally, may have had no idea, but MaxMind The Company did/does. > > > > Its called class action lawsuit. Yep. It's also effectively the inverse of the Streisand Effect since the news articles (and hopefully law suit) can only help people in that situation since it's the only way they'd get wide enough coverage of the issue to warn amateur sleuths that any trail that leads there is a dead end. It really says it all when the local sherriff says that his job now includes defending the house against all other law enforcement, state and federal. It's good that they're doing it, but ridiculous that they have to. Regards, Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 630 bytes Desc: not available URL: From rmacharia at gmail.com Tue Apr 12 19:00:38 2016 From: rmacharia at gmail.com (Raymond Macharia) Date: Tue, 12 Apr 2016 22:00:38 +0300 Subject: Telco Systems In-Reply-To: References: Message-ID: Hi, We have used them on our metro for some years now and they have performed well. They do support Mpls. Pricing is very good for what you get. I am currently using the 7124 and I know of another provide who are running exclusively on the telco devices. We have also managed to get them talking to our Cisco aggregation with no issues so far. Raymond Macharia Internet Solutions Kenya On 12 Apr 2016 16:09, "Colton Conor" wrote: Does anyone use Telco Systems Carrier Ethernet & MPLS Aggregation Switches? I have heard good things about them. Overall, the saying is they price 10G ethernet switches at 1G ethernet pricing. It looks like they support MPLS. http://www.telco.com/index.php?page=product-category&category=ethernet-mpls-aggregation From edwin.mallette at gmail.com Wed Apr 13 19:36:45 2016 From: edwin.mallette at gmail.com (Edwin Mallette) Date: Wed, 13 Apr 2016 16:36:45 -0300 Subject: Juniper vMX evaluation - how? In-Reply-To: <570EB1FA.5000509@fastmail.net> References: <570EB1FA.5000509@fastmail.net> Message-ID: I downloaded it in the past and can?t remember having any issues downloading it? Getting it to work in my environment was a bit more challenging, however. I do have a Juniper login which is required. I also just verified that I can download application package: vMX MD5 SHA1 15.1F4 tgz 1,561,459,359 28 Dec 2015 You need to be logged in to download the vMX archive as well as the eval license key. Both I was able to get once logged in. Cheers, Ed On 4/13/16, 5:54 PM, "NANOG on behalf of Bruce Simpson" wrote: >Pardon if this is off-topic -- but this is really beginning to wind me up. > >So, http://www.juniper.net/us/en/dm/free-vmx-trial/ shows that Juniper >Networks vMX is available for a 60-day evaluation. This requires filling >out a form to create an account on juniper.net. > >I don't currently have such a login. $CLIENT filled out such a form well >over a month ago, and never heard anything back. Normally, I'd expect to >be able to download as soon as an account is approved. Meanwhile, we get >preoccupied with other tasks. > >Is some special magic required to acquire an evaluation copy? The 60 day >trial license is directly downloadable from the above link, but the >tarball is not. $CLIENT was just referred to it by $RESELLER. From johnl at iecc.com Wed Apr 13 21:40:25 2016 From: johnl at iecc.com (John Levine) Date: 13 Apr 2016 21:40:25 -0000 Subject: phone fun, was GeoIP database issues and the real world consequences In-Reply-To: Message-ID: <20160413214025.15433.qmail@ary.lan> > And further to that, throw in Local Number Portability (LNP) and you > really need to know the full number in order to know which switch the > specific number is assigned to. Not all 408-921 prefixed numbers will go > to that switch in West San Jose. Right, like I said three messages ago but that some people seem to have missed: NANP geographical numbers can be located to a switch (give or take number portability within a LATA), > A phone number, like an IP address, can only imply a physical location. It > is not a guarantee, and that hint can range from moderately accurate to > wildly wrong. Quite right. US mobile carriers let you take your phone number anywhere in the country, so people do. There's also a fair amount of VoIP where again the phone need not be anywhere near the switch -- I have landline phone numbers in NYC, Santa Cruz, Monreal, and Cambridge UK, and don't live in any of those places. Bonus question: is there any way to find out whether and where a number's been ported without spending telco level amounts of money? Free would be nice. R's, John From D.Lasher at f5.com Wed Apr 13 21:44:18 2016 From: D.Lasher at f5.com (Donn Lasher) Date: Wed, 13 Apr 2016 21:44:18 +0000 Subject: Juniper vMX evaluation - how? In-Reply-To: References: <570EB1FA.5000509@fastmail.net> Message-ID: <2cents> Avoid vMX 14.x - go straight to 15.x, save yourself worlds of pain. 15.x runs well kvm/esxi/etc. On 4/13/16, 2:14 PM, "NANOG on behalf of Josh Baird" wrote: >It was a struggle to get anywhere with vMX when we last tried ~8months >ago. Nobody at Juniper seemed to know anything about it or who to talk >to. In any event, you may be able to get more information by asking over >at juniper-nsp at . > >Josh > >On Wed, Apr 13, 2016 at 4:58 PM, Jeremy Austin wrote: > >> On Wed, Apr 13, 2016 at 12:54 PM, Bruce Simpson wrote: >> >> > >> > Is some special magic required to acquire an evaluation copy? The 60 day >> > trial license is directly downloadable from the above link, but the >> tarball >> > is not. $CLIENT was just referred to it by $RESELLER. >> >> >> I'd be interested as well ? I submitted a form, nothing but crickets. >> >> >> -- >> Jeremy Austin >> >> (907) 895-2311 >> (907) 803-5422 >> jhaustin at gmail.com >> >> Heritage NetWorks >> Whitestone Power & Communications >> Vertical Broadband, LLC >> >> Schedule a meeting: http://doodle.com/jermudgeon >> From johnl at iecc.com Wed Apr 13 21:52:23 2016 From: johnl at iecc.com (John Levine) Date: 13 Apr 2016 21:52:23 -0000 Subject: phone fun, was GeoIP database issues and the real world consequences In-Reply-To: <570EAD5F.8010502@vaxination.ca> Message-ID: <20160413215223.15475.qmail@ary.lan> >Is there the equivalent of BGP for number portability where every telco >has the full table of who owns each prefix as well as individual routes >for ported numbers ? Not really. There's a switch database used for routing calls, but that's different from LNP which is a layer sort of above that. >Or is there a central database that is consulted before a dialed number >starts to be connected so originating telco knows to send call ? Often, if the switch can't tell that the number hasn't been ported. >Or does the originating telco route the call to the original onwer of >the prefix and lets that original owner figure out how to terminate the >call ? That's called Onward Routing. They do it some places but not in North America. See RFC 3482 for a well written overview of number portability. >From a long distance billing point of view, if Bell Canada connects to a >number originally onwed by AT&T but ported to Verizon, with whom would >Bell share long distance revenues ? They pay whatever long distance company they use, and that company pays the owner of the switch to which it's delivered. The long distance company also pays a very small amount to Telcordia which runs the LNP database to tell whether the number's been ported and if so to which switch. R's, John From larrysheldon at cox.net Wed Apr 13 23:06:47 2016 From: larrysheldon at cox.net (Larry Sheldon) Date: Wed, 13 Apr 2016 18:06:47 -0500 Subject: phone fun, was GeoIP database issues and the real world consequences In-Reply-To: References: <20160413191550.15049.qmail@ary.lan> <78025EFB-3007-458B-9A55-1E5FD57F97FA@delong.com> Message-ID: <570ED107.8090101@cox.net> On 4/13/2016 14:45, John R. Levine wrote: >>> NANP geographical numbers can be located to a switch (give >>> or take number portability within a LATA), but non-geographic numbers >>> can really go anywhere. On the third hand, it's still true that the >>> large majority of them are in the U.S. >> >> Would you agree that 408-921 is a geographic number? > > No. It's a prefix, assigned to the at&t switch in west San Jose. > >> I guarantee you that there are phones within that prefix within >> US/Calif/LATA-1 and also some well outside of that, probably not even >> in the same country. > > Who said anything about phones? Could you describe what "geographic > numbers can be located to a switch" means to you? Lemmee see, the issue is, whose barn do we burn down, based on the telephone number associated with it--the one the with the switch or the one with the telephone? There right answer is predicated on the the facts that the number (IP or telephone or serial number plate) is of NO use what ever in locating anything, certainly not as a cause for action. Anybody who acts different;y should have painful things done to them. I don't care what expert tells you different. A case in point--the other day I had need for the ZIP code for the house I lived in at age 10. So I Binged the address for a ZIP code and got one. Along with a Googlish picture that goes with the address. When I was 10, the address was for one of four tiny houses on a small city lot. (Which, I discovered in later years was in a barrio, and populated by people at of below the poverty line, if anybody had used that terminology then.) The picture was of a KITCHEN! that appeared to be bigger than the house I lived in--the Zillow entry for the property now was 3/4 of a million dollars. Knowing the address of a place is not definitive of the place. Period. -- sed quis custodiet ipsos custodes? (Juvenal) From larrysheldon at cox.net Wed Apr 13 23:28:07 2016 From: larrysheldon at cox.net (Larry Sheldon) Date: Wed, 13 Apr 2016 18:28:07 -0500 Subject: phone fun, was GeoIP database issues and the real world consequences In-Reply-To: <5B6E932D-7A22-45A4-B04C-787718150FF5@delong.com> References: <20160413191550.15049.qmail@ary.lan> <78025EFB-3007-458B-9A55-1E5FD57F97FA@delong.com> <5B6E932D-7A22-45A4-B04C-787718150FF5@delong.com> Message-ID: <570ED607.1070607@cox.net> On 4/13/2016 15:12, Owen DeLong wrote: > I guarantee you that many, if not most at this point, of those > numbers are no longer actually handled by that switch most of the > time. > > I suspect that there are more SS7 exceptions than default within that > particular prefix which is why I chose it. I question whether (on a global scale) the odds are above 50-50 that a number (other than a test line) is served by the switch NANPA associates with the number. I am in frequent contact by a person that has a 917 NNX-XXXX-numbered telephone who spends a lot of time with a person that has a 408 NNX-XXXX-numbered telephone, and they both live in Metropolitan Boston The number I offer as my "home" telephone number "belongs" to a CO in a town 11 miles south of here and is not switched by the company that "owns" it. Knowing a telephone number or an IP address means that on a good day, you know how to make a connection with an instrument associated with it. Which may well be in the possession of Mrs. Calabash. -- sed quis custodiet ipsos custodes? (Juvenal) From johnl at iecc.com Thu Apr 14 00:29:39 2016 From: johnl at iecc.com (John Levine) Date: 14 Apr 2016 00:29:39 -0000 Subject: phone fun, was GeoIP database issues and the real world consequences In-Reply-To: <570ED607.1070607@cox.net> Message-ID: <20160414002939.15867.qmail@ary.lan> >I question whether (on a global scale) the odds are above 50-50 that a >number (other than a test line) is served by the switch NANPA associates >with the number. The people on nanog are not typical. I looked around for statistics and didn't find much, but it looks like only a few percent of numbers are ported each month, and it's often the same numbers being ported repeatedly. I'd also expect to find a lot more porting in the highly competitive wireless industry than in the monopolistic wireline biz. R's, John From matthew at matthew.at Thu Apr 14 02:00:45 2016 From: matthew at matthew.at (Matthew Kaufman) Date: Thu, 14 Apr 2016 12:00:45 +1000 Subject: phone fun, was GeoIP database issues and the real world consequences In-Reply-To: <20160413214025.15433.qmail@ary.lan> References: <20160413214025.15433.qmail@ary.lan> Message-ID: <1F4EB9B7-78B7-4655-B601-D8024B4A1E85@matthew.at> John Levine: > > Bonus question: is there any way to find out whether and where a > number's been ported without spending telco level amounts of money? > Free would be nice. https://www.npac.com/the-npac/access/permitted-uses-of-user-data-contact-list Matthew Kaufman (Sent from my iPhone) From jay at west.net Thu Apr 14 02:42:53 2016 From: jay at west.net (Jay Hennigan) Date: Wed, 13 Apr 2016 19:42:53 -0700 Subject: phone fun, was GeoIP database issues and the real world consequences In-Reply-To: <570ED607.1070607@cox.net> References: <20160413191550.15049.qmail@ary.lan> <78025EFB-3007-458B-9A55-1E5FD57F97FA@delong.com> <5B6E932D-7A22-45A4-B04C-787718150FF5@delong.com> <570ED607.1070607@cox.net> Message-ID: <570F03AD.6090202@west.net> On 4/13/16 4:28 PM, Larry Sheldon wrote: > I am in frequent contact by a person that has a 917 NNX-XXXX-numbered > telephone who spends a lot of time with a person that has a 408 > NNX-XXXX-numbered telephone, and they both live in Metropolitan Boston When either of those people dial 9-1-1, where does the ambulance show up? -- 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 beckman at angryox.com Thu Apr 14 03:54:48 2016 From: beckman at angryox.com (Peter Beckman) Date: Wed, 13 Apr 2016 23:54:48 -0400 Subject: phone fun, was GeoIP database issues and the real world consequences In-Reply-To: <570F03AD.6090202@west.net> References: <20160413191550.15049.qmail@ary.lan> <78025EFB-3007-458B-9A55-1E5FD57F97FA@delong.com> <5B6E932D-7A22-45A4-B04C-787718150FF5@delong.com> <570ED607.1070607@cox.net> <570F03AD.6090202@west.net> Message-ID: On Wed, 13 Apr 2016, Jay Hennigan wrote: > On 4/13/16 4:28 PM, Larry Sheldon wrote: > >> I am in frequent contact by a person that has a 917 NNX-XXXX-numbered >> telephone who spends a lot of time with a person that has a 408 >> NNX-XXXX-numbered telephone, and they both live in Metropolitan Boston > > When either of those people dial 9-1-1, where does the ambulance show up? I suspect your response was sarcastic, but when you dig into what really happens, it's not nearly as sophisticated as one might hope. If the numbers are land or VoIP lines, and the address associated with the numbers are registered with the Automatic Location Information (ALI) database run by ILECs or 3rd parties to fetch the address keyed on the calling number, and the 911 PSAP is E911 capable, they operator will see the ALI address. If they are mobile devices, it depends. Basic gives you nothing (all phones since 2003 should have GPS, but people hang on to phones a long time..); Phase I Enhanced gives you the location of the cell site/tower, Phase II gives you lat/lon within 50 to 300 meters within 6 minutes of a request by the PSAP. Yep, the PSAP has to make a request for the phone location to the carrier, in which they have 6 minutes to reply. I assume this is or can be automated. After 6 minutes, you could be a long way away from where you started the call. If the phone numbers are not in the ALI, or are not wireless, or the PSAP (Public Safety Answering Point, the 911 office) is not set up for e911, they probably get nothing, relying solely on the caller to provide location information. Beckman --------------------------------------------------------------------------- Peter Beckman Internet Guy beckman at angryox.com http://www.angryox.com/ --------------------------------------------------------------------------- From jay at west.net Thu Apr 14 05:22:46 2016 From: jay at west.net (Jay Hennigan) Date: Wed, 13 Apr 2016 22:22:46 -0700 Subject: phone fun, was GeoIP database issues and the real world consequences In-Reply-To: References: <20160413191550.15049.qmail@ary.lan> <78025EFB-3007-458B-9A55-1E5FD57F97FA@delong.com> <5B6E932D-7A22-45A4-B04C-787718150FF5@delong.com> <570ED607.1070607@cox.net> <570F03AD.6090202@west.net> Message-ID: <570F2926.2020500@west.net> On 4/13/16 8:54 PM, Peter Beckman wrote: > On Wed, 13 Apr 2016, Jay Hennigan wrote: >> When either of those people dial 9-1-1, where does the ambulance show up? > > I suspect your response was sarcastic, but when you dig into what really > happens, it's not nearly as sophisticated as one might hope. > > If the numbers are land or VoIP lines, and the address associated with > the > numbers are registered with the Automatic Location Information (ALI) > database run by ILECs or 3rd parties to fetch the address keyed on the > calling number, and the 911 PSAP is E911 capable, they operator will see > the ALI address. If they're land lines, the NPA/NXX will be local to the CO so you won't have out-of-area numbers other than a rare corner case of a very expensive foreign exchange line. If they're VoIP lines, the address is *supposed* to be so registered, but softphones and even VoIP handsets tend to move around without the user considering 9-1-1. VoIP was the scenario to which I was referring. A VoIP phone native to 408-land that moves with a remote office worker to Boston without a conscious effort on his company and VoIP provider to track it down and update ALI will reach a PSAP in San Jose or thereabouts. The PSAPs have forwarding capability but generally only to neighboring PSAPs with a single button. How quickly will they be able to get the call routed to Boston, if at all? And as we saw at the beginning of the thread, forget geo-IP. The ambulance goes to the Vogelmans' farm. If a remote office worker, it could be VPN back to the VoIP PBX in 408-land anyway. So, it isn't just IP addresses that aren't easily geo-referenced. It's also phone numbers. The number may start as a well-referenced PRI going to an IP-PBX after which all bets are off. If the ANI is the company's HQ main number where the PRI and IP-PBX are located, then it's just about impossible to route 9-1-1 from a worker's IP phone in Boston to the right PSAP. > If they are mobile devices, it depends. Basic gives you nothing (all > phones > since 2003 should have GPS, but people hang on to phones a long time..); Mobile is a separate case where it's expected that the NPA-NXX isn't going to be tied to a location. In California, mobile 9-1-1 goes to the CHP and not the local PSAP based on the cell tower or GPS for that reason. If not a traffic incident, they forward to the appropriate PSAP based on the caller's info or perhaps whatever ALI (or estimate) they get from the cellular provider. -- 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 me at anuragbhatia.com Thu Apr 14 11:30:22 2016 From: me at anuragbhatia.com (Anurag Bhatia) Date: Thu, 14 Apr 2016 17:00:22 +0530 Subject: G root not responding on UDP? Message-ID: Hello everyone I wonder if it's just me or anyone else also finding issues in g root reachability? ICMP, trace, UDP DNS queries all timing out. Only TCP seem to work. Trace is timing out on 208.46.37.38. traceroute to 192.112.36.4 (192.112.36.4), 64 hops max, 52 byte packets 1 router01.home (172.16.0.1) 4.926 ms 1.863 ms 1.845 ms 2 103.60.176.101 (103.60.176.101) 24.007 ms 24.507 ms 22.330 ms 3 nsg-static-137.49.75.182-airtel.com (182.75.49.137) 64.435 ms 64.359 ms 66.108 ms 4 182.79.206.46 (182.79.206.46) 331.787 ms 182.79.206.53 (182.79.206.53) 228.497 ms 182.79.222.189 (182.79.222.189) 224.966 ms 5 ldn-brdr-01.qwest.net (195.66.225.34) 162.745 ms 162.139 ms 162.031 ms 6 lon-ddos-01.inet.qwest.net (67.14.63.58) 162.138 ms 162.125 ms 162.916 ms 7 * * * 8 chp-edge-01.inet.qwest.net (208.46.37.37) 242.819 ms 242.793 ms 242.575 ms 9 208.46.37.38 (208.46.37.38) 253.176 ms 253.066 ms 252.807 ms 10 * * * 11 * * * 12 * * * dig @192.112.36.4 . ns ; <<>> DiG 9.8.3-P1 <<>> @192.112.36.4 . ns ; (1 server found) ;; global options: +cmd ;; connection timed out; no servers could be reached dig @192.112.36.4 . ns +tcp +noauth ; <<>> DiG 9.8.3-P1 <<>> @192.112.36.4 . ns +tcp +noauth ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 29674 ;; flags: qr aa rd; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 24 ;; WARNING: recursion requested but not available ;; QUESTION SECTION: ;. IN NS ;; ANSWER SECTION: . 518400 IN NS g.root-servers.net. . 518400 IN NS l.root-servers.net. . 518400 IN NS f.root-servers.net. . 518400 IN NS h.root-servers.net. . 518400 IN NS k.root-servers.net. . 518400 IN NS b.root-servers.net. . 518400 IN NS c.root-servers.net. . 518400 IN NS e.root-servers.net. . 518400 IN NS j.root-servers.net. . 518400 IN NS i.root-servers.net. . 518400 IN NS m.root-servers.net. . 518400 IN NS a.root-servers.net. . 518400 IN NS d.root-servers.net. ;; ADDITIONAL SECTION: a.root-servers.net. 3600000 IN A 198.41.0.4 b.root-servers.net. 3600000 IN A 192.228.79.201 c.root-servers.net. 3600000 IN A 192.33.4.12 d.root-servers.net. 3600000 IN A 199.7.91.13 e.root-servers.net. 3600000 IN A 192.203.230.10 f.root-servers.net. 3600000 IN A 192.5.5.241 g.root-servers.net. 3600000 IN A 192.112.36.4 h.root-servers.net. 3600000 IN A 198.97.190.53 i.root-servers.net. 3600000 IN A 192.36.148.17 j.root-servers.net. 3600000 IN A 192.58.128.30 k.root-servers.net. 3600000 IN A 193.0.14.129 l.root-servers.net. 3600000 IN A 199.7.83.42 m.root-servers.net. 3600000 IN A 202.12.27.33 a.root-servers.net. 3600000 IN AAAA 2001:503:ba3e::2:30 b.root-servers.net. 3600000 IN AAAA 2001:500:84::b c.root-servers.net. 3600000 IN AAAA 2001:500:2::c d.root-servers.net. 3600000 IN AAAA 2001:500:2d::d f.root-servers.net. 3600000 IN AAAA 2001:500:2f::f h.root-servers.net. 3600000 IN AAAA 2001:500:1::53 i.root-servers.net. 3600000 IN AAAA 2001:7fe::53 j.root-servers.net. 3600000 IN AAAA 2001:503:c27::2:30 k.root-servers.net. 3600000 IN AAAA 2001:7fd::1 l.root-servers.net. 3600000 IN AAAA 2001:500:9f::42 m.root-servers.net. 3600000 IN AAAA 2001:dc3::35 ;; Query time: 259 msec ;; SERVER: 192.112.36.4#53(192.112.36.4) ;; WHEN: Thu Apr 14 16:59:09 2016 ;; MSG SIZE rcvd: 744 Is UDP blocked recently or it has been like this from long? -- Anurag Bhatia anuragbhatia.com From nsuan at nonexiste.net Thu Apr 14 11:36:55 2016 From: nsuan at nonexiste.net (Nicholas Suan) Date: Thu, 14 Apr 2016 07:36:55 -0400 Subject: G root not responding on UDP? In-Reply-To: References: Message-ID: I'm see the same thing from multiple networks. $ dig NS . @g.root-servers.net ; <<>> DiG 9.9.5 <<>> NS . @g.root-servers.net ;; global options: +cmd ;; connection timed out; no servers could be reached On Thu, Apr 14, 2016 at 7:30 AM, Anurag Bhatia wrote: > Hello everyone > > > I wonder if it's just me or anyone else also finding issues in g root > reachability? > > > ICMP, trace, UDP DNS queries all timing out. Only TCP seem to work. > > > Trace is timing out on 208.46.37.38. > > > > traceroute to 192.112.36.4 (192.112.36.4), 64 hops max, 52 byte packets > 1 router01.home (172.16.0.1) 4.926 ms 1.863 ms 1.845 ms > 2 103.60.176.101 (103.60.176.101) 24.007 ms 24.507 ms 22.330 ms > 3 nsg-static-137.49.75.182-airtel.com (182.75.49.137) 64.435 ms 64.359 > ms 66.108 ms > 4 182.79.206.46 (182.79.206.46) 331.787 ms > 182.79.206.53 (182.79.206.53) 228.497 ms > 182.79.222.189 (182.79.222.189) 224.966 ms > 5 ldn-brdr-01.qwest.net (195.66.225.34) 162.745 ms 162.139 ms 162.031 > ms > 6 lon-ddos-01.inet.qwest.net (67.14.63.58) 162.138 ms 162.125 ms > 162.916 ms > 7 * * * > 8 chp-edge-01.inet.qwest.net (208.46.37.37) 242.819 ms 242.793 ms > 242.575 ms > 9 208.46.37.38 (208.46.37.38) 253.176 ms 253.066 ms 252.807 ms > 10 * * * > 11 * * * > 12 * * * > > > > > dig @192.112.36.4 . ns > > ; <<>> DiG 9.8.3-P1 <<>> @192.112.36.4 . ns > ; (1 server found) > ;; global options: +cmd > ;; connection timed out; no servers could be reached > > > > > > dig @192.112.36.4 . ns +tcp +noauth > > ; <<>> DiG 9.8.3-P1 <<>> @192.112.36.4 . ns +tcp +noauth > ; (1 server found) > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 29674 > ;; flags: qr aa rd; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 24 > ;; WARNING: recursion requested but not available > > ;; QUESTION SECTION: > ;. IN NS > > ;; ANSWER SECTION: > . 518400 IN NS g.root-servers.net. > . 518400 IN NS l.root-servers.net. > . 518400 IN NS f.root-servers.net. > . 518400 IN NS h.root-servers.net. > . 518400 IN NS k.root-servers.net. > . 518400 IN NS b.root-servers.net. > . 518400 IN NS c.root-servers.net. > . 518400 IN NS e.root-servers.net. > . 518400 IN NS j.root-servers.net. > . 518400 IN NS i.root-servers.net. > . 518400 IN NS m.root-servers.net. > . 518400 IN NS a.root-servers.net. > . 518400 IN NS d.root-servers.net. > > ;; ADDITIONAL SECTION: > a.root-servers.net. 3600000 IN A 198.41.0.4 > b.root-servers.net. 3600000 IN A 192.228.79.201 > c.root-servers.net. 3600000 IN A 192.33.4.12 > d.root-servers.net. 3600000 IN A 199.7.91.13 > e.root-servers.net. 3600000 IN A 192.203.230.10 > f.root-servers.net. 3600000 IN A 192.5.5.241 > g.root-servers.net. 3600000 IN A 192.112.36.4 > h.root-servers.net. 3600000 IN A 198.97.190.53 > i.root-servers.net. 3600000 IN A 192.36.148.17 > j.root-servers.net. 3600000 IN A 192.58.128.30 > k.root-servers.net. 3600000 IN A 193.0.14.129 > l.root-servers.net. 3600000 IN A 199.7.83.42 > m.root-servers.net. 3600000 IN A 202.12.27.33 > a.root-servers.net. 3600000 IN AAAA 2001:503:ba3e::2:30 > b.root-servers.net. 3600000 IN AAAA 2001:500:84::b > c.root-servers.net. 3600000 IN AAAA 2001:500:2::c > d.root-servers.net. 3600000 IN AAAA 2001:500:2d::d > f.root-servers.net. 3600000 IN AAAA 2001:500:2f::f > h.root-servers.net. 3600000 IN AAAA 2001:500:1::53 > i.root-servers.net. 3600000 IN AAAA 2001:7fe::53 > j.root-servers.net. 3600000 IN AAAA 2001:503:c27::2:30 > k.root-servers.net. 3600000 IN AAAA 2001:7fd::1 > l.root-servers.net. 3600000 IN AAAA 2001:500:9f::42 > m.root-servers.net. 3600000 IN AAAA 2001:dc3::35 > > ;; Query time: 259 msec > ;; SERVER: 192.112.36.4#53(192.112.36.4) > ;; WHEN: Thu Apr 14 16:59:09 2016 > ;; MSG SIZE rcvd: 744 > > > > > > Is UDP blocked recently or it has been like this from long? > > > > -- > > > Anurag Bhatia > anuragbhatia.com From robert at ripe.net Thu Apr 14 12:29:15 2016 From: robert at ripe.net (Robert Kisteleki) Date: Thu, 14 Apr 2016 14:29:15 +0200 Subject: G root not responding on UDP? In-Reply-To: References: Message-ID: <570F8D1B.20909@ripe.net> On 2016-04-14 13:30, Anurag Bhatia wrote: > Hello everyone > > > I wonder if it's just me or anyone else also finding issues in g root > reachability? > > > ICMP, trace, UDP DNS queries all timing out. Only TCP seem to work. It's not only you: https://atlas.ripe.net/dnsmon/?dnsmon.session.color_range_pls=0-5-5-25-100&dnsmon.session.exclude-errors=true&dnsmon.type=server-probes&dnsmon.server=192.112.36.4&dnsmon.zone=root&dnsmon.startTime=1460574600&dnsmon.endTime=1460616600&dnsmon.ipVersion=both (shorter link: https://t.co/7lgnCFCEDZ) Cheers, Robert From bms at fastmail.net Thu Apr 14 12:39:41 2016 From: bms at fastmail.net (Bruce Simpson) Date: Thu, 14 Apr 2016 13:39:41 +0100 Subject: Juniper vMX evaluation - how? In-Reply-To: References: <570EB1FA.5000509@fastmail.net> Message-ID: <570F8F8D.8080503@fastmail.net> Thanks to all who responded (and thanks to the NANOGger who provided me with images). I am a bit disappointed that others have also had the silent treatment after signing up to download vMX. I am unsurprised that vMX 14.x has had teething troubles. I also hope JNPR listen to us that Intel are not the only SR-IOV game in town. Onward... From johnl at iecc.com Thu Apr 14 12:46:20 2016 From: johnl at iecc.com (John Levine) Date: 14 Apr 2016 12:46:20 -0000 Subject: phone fun, was GeoIP database issues and the real world consequences In-Reply-To: <570F2926.2020500@west.net> Message-ID: <20160414124620.18804.qmail@ary.lan> >If they're land lines, the NPA/NXX will be local to the CO so you won't >have out-of-area numbers other than a rare corner case of a very >expensive foreign exchange line. If they're VoIP lines, the address is >*supposed* to be so registered, but softphones and even VoIP handsets >tend to move around without the user considering 9-1-1. VoIP was dragged kicking and screaming into E911, so now they charge extra and are quite clear about it. My VoIP provider regularly reminds me to update my 9-1-1 address, but since I don't have to pay the 9-1-1 fee if I lie and say I'm outside North America, that's what I do. Since I also have a classic CO-powered copper landline (1/4 mile from the CO, no concentrators or repeaters) and a couple of cell phones, I think we're covered. R's, John From robert at ripe.net Thu Apr 14 12:57:17 2016 From: robert at ripe.net (Robert Kisteleki) Date: Thu, 14 Apr 2016 14:57:17 +0200 Subject: G root not responding on UDP? In-Reply-To: <570F8D1B.20909@ripe.net> References: <570F8D1B.20909@ripe.net> Message-ID: <570F93AD.4020002@ripe.net> On 2016-04-14 14:29, Robert Kisteleki wrote: > On 2016-04-14 13:30, Anurag Bhatia wrote: >> Hello everyone >> >> >> I wonder if it's just me or anyone else also finding issues in g root >> reachability? >> >> >> ICMP, trace, UDP DNS queries all timing out. Only TCP seem to work. > > > It's not only you: > > https://atlas.ripe.net/dnsmon/?dnsmon.session.color_range_pls=0-5-5-25-100&dnsmon.session.exclude-errors=true&dnsmon.type=server-probes&dnsmon.server=192.112.36.4&dnsmon.zone=root&dnsmon.startTime=1460574600&dnsmon.endTime=1460616600&dnsmon.ipVersion=both ... and it recovered already: https://atlas.ripe.net/dnsmon/?dnsmon.session.color_range_pls=0-5-5-25-100&dnsmon.session.exclude-errors=true&dnsmon.type=server-probes&dnsmon.server=192.112.36.4&dnsmon.zone=root&dnsmon.startTime=1460595996&dnsmon.endTime=1460637996&dnsmon.ipVersion=both&dnsmon.timeWindow=42000 Robert From beowulfdance at gmail.com Thu Apr 14 13:04:31 2016 From: beowulfdance at gmail.com (Jonathan Smith) Date: Thu, 14 Apr 2016 07:04:31 -0600 Subject: phone fun, was GeoIP database issues and the real world consequences In-Reply-To: References: <20160413191550.15049.qmail@ary.lan> <78025EFB-3007-458B-9A55-1E5FD57F97FA@delong.com> <5B6E932D-7A22-45A4-B04C-787718150FF5@delong.com> <570ED607.1070607@cox.net> <570F03AD.6090202@west.net> <570F2926.2020500@west.net> Message-ID: "If they're land lines, the NPA/NXX will be local to the CO so you won't have out-of-area numbers other than a rare corner case of a very expensive foreign exchange line." This hasn't been a true statement since Local Number Portability. NPA/NXX is nothing more than 'where the number originally was assigned from', and that only for the ones issued BEFORE LNP started; since is anyone's guess. They follow something similiar to what a routed phone call does, but ties into slightly different information that is 'supposed' to associate the end-client address with said LNI that is 'supposed' to be populated with accurate street address information. Similar to what VoIP has had to deal with since, most charge a fee, disclaim any responsibility as to the accuracy of the information that the end user provides. I am sure litigation on/around THAT particular issue is just around the corner. Regards, Jonathan Smith On Wed, Apr 13, 2016 at 11:22 PM, Jay Hennigan wrote: > On 4/13/16 8:54 PM, Peter Beckman wrote: > >> On Wed, 13 Apr 2016, Jay Hennigan wrote: >> > > When either of those people dial 9-1-1, where does the ambulance show up? >>> >> >> I suspect your response was sarcastic, but when you dig into what really >> happens, it's not nearly as sophisticated as one might hope. >> >> If the numbers are land or VoIP lines, and the address associated with >> the >> numbers are registered with the Automatic Location Information (ALI) >> database run by ILECs or 3rd parties to fetch the address keyed on the >> calling number, and the 911 PSAP is E911 capable, they operator will see >> the ALI address. >> > > If they're land lines, the NPA/NXX will be local to the CO so you won't > have out-of-area numbers other than a rare corner case of a very expensive > foreign exchange line. If they're VoIP lines, the address is *supposed* to > be so registered, but softphones and even VoIP handsets tend to move around > without the user considering 9-1-1. > > VoIP was the scenario to which I was referring. A VoIP phone native to > 408-land that moves with a remote office worker to Boston without a > conscious effort on his company and VoIP provider to track it down and > update ALI will reach a PSAP in San Jose or thereabouts. The PSAPs have > forwarding capability but generally only to neighboring PSAPs with a single > button. How quickly will they be able to get the call routed to Boston, if > at all? And as we saw at the beginning of the thread, forget geo-IP. The > ambulance goes to the Vogelmans' farm. If a remote office worker, it could > be VPN back to the VoIP PBX in 408-land anyway. > > So, it isn't just IP addresses that aren't easily geo-referenced. It's > also phone numbers. The number may start as a well-referenced PRI going to > an IP-PBX after which all bets are off. If the ANI is the company's HQ main > number where the PRI and IP-PBX are located, then it's just about > impossible to route 9-1-1 from a worker's IP phone in Boston to the right > PSAP. > > If they are mobile devices, it depends. Basic gives you nothing (all >> phones >> since 2003 should have GPS, but people hang on to phones a long time..); >> > > Mobile is a separate case where it's expected that the NPA-NXX isn't going > to be tied to a location. In California, mobile 9-1-1 goes to the CHP and > not the local PSAP based on the cell tower or GPS for that reason. If not a > traffic incident, they forward to the appropriate PSAP based on the > caller's info or perhaps whatever ALI (or estimate) they get from the > cellular provider. > > > -- > 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 Jason_Livingood at comcast.com Thu Apr 14 13:49:31 2016 From: Jason_Livingood at comcast.com (Livingood, Jason) Date: Thu, 14 Apr 2016 13:49:31 +0000 Subject: FCC Privacy NPRM [was Re: GeoIP database] Message-ID: I have not yet read all of the 147 pages of the FCC Privacy NPRM - https://www.fcc.gov/document/fcc-releases-proposed-rules-protect-broadband- consumer-privacy. But it may be worth noting, especially for this audience, that the FCC proposes considering things like IP addresses and geo-location information to be Customer Proprietary Information. While IANAL it seems that this could perhaps complicate efforts to make GeoIP services more accurate. But who knows. Jason P.S. While these proposed rules would only initially apply to ISPs, from what I understand following adoption there will be a move for so-called parity such that any app or edge provider in the US might have to meet the same standards. On 4/12/16, 8:17 PM, "NANOG on behalf of Jean-Francois Mezei" wrote: >All GeoIP services would be forced to document their default lat/long >values so that users know that when these values, they know it is a >generic one for that country. (or supply +181.0000 +91.00000 which is an >invalid value indicating that there is no lat/long, look at country code >given). > From bicknell at ufp.org Thu Apr 14 15:32:36 2016 From: bicknell at ufp.org (Leo Bicknell) Date: Thu, 14 Apr 2016 08:32:36 -0700 Subject: phone fun, was GeoIP database issues and the real world consequences In-Reply-To: <20160414002939.15867.qmail@ary.lan> References: <570ED607.1070607@cox.net> <20160414002939.15867.qmail@ary.lan> Message-ID: <20160414153236.GA88366@ussenterprise.ufp.org> In a message written on Thu, Apr 14, 2016 at 12:29:39AM -0000, John Levine wrote: > The people on nanog are not typical. I looked around for statistics > and didn't find much, but it looks like only a few percent of numbers > are ported each month, and it's often the same numbers being ported > repeatedly. It's a big issue for political pollers, and they have some data: http://www.pewresearch.org/fact-tank/2016/01/05/pew-research-center-will-call-75-cellphones-for-surveys-in-2016/ "roughly half (47%) of U.S. adults whose only phone is a cellphone." "in a recent national poll, 8% of people interviewed by cellphone in California had a phone number from a state other than California. Similarly, of the people called on a cellphone number associated with California, 10% were interviewed in a different state." So maybe 10% of all cell phones are primarly used in the "wrong" area? -- Leo Bicknell - bicknell at ufp.org PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 811 bytes Desc: not available URL: From gary.buhrmaster at gmail.com Thu Apr 14 15:45:21 2016 From: gary.buhrmaster at gmail.com (Gary Buhrmaster) Date: Thu, 14 Apr 2016 15:45:21 +0000 Subject: phone fun, was GeoIP database issues and the real world consequences In-Reply-To: <20160414153236.GA88366@ussenterprise.ufp.org> References: <570ED607.1070607@cox.net> <20160414002939.15867.qmail@ary.lan> <20160414153236.GA88366@ussenterprise.ufp.org> Message-ID: On Thu, Apr 14, 2016 at 3:32 PM, Leo Bicknell wrote: ..... > So maybe 10% of all cell phones are primarly used in the "wrong" area? Obligatory xkcd ref: https://xkcd.com/1129/ From josh at kyneticwifi.com Thu Apr 14 15:49:40 2016 From: josh at kyneticwifi.com (Josh Reynolds) Date: Thu, 14 Apr 2016 10:49:40 -0500 Subject: phone fun, was GeoIP database issues and the real world consequences In-Reply-To: References: <570ED607.1070607@cox.net> <20160414002939.15867.qmail@ary.lan> <20160414153236.GA88366@ussenterprise.ufp.org> Message-ID: All, Is NANOG really the best place for this discussion? On Thu, Apr 14, 2016 at 10:45 AM, Gary Buhrmaster wrote: > On Thu, Apr 14, 2016 at 3:32 PM, Leo Bicknell wrote: > ..... >> So maybe 10% of all cell phones are primarly used in the "wrong" area? > > Obligatory xkcd ref: https://xkcd.com/1129/ From owen at delong.com Thu Apr 14 17:09:56 2016 From: owen at delong.com (Owen DeLong) Date: Thu, 14 Apr 2016 10:09:56 -0700 Subject: phone fun, was GeoIP database issues and the real world consequences In-Reply-To: <20160414124620.18804.qmail@ary.lan> References: <20160414124620.18804.qmail@ary.lan> Message-ID: > On Apr 14, 2016, at 05:46 , John Levine wrote: > >> If they're land lines, the NPA/NXX will be local to the CO so you won't >> have out-of-area numbers other than a rare corner case of a very >> expensive foreign exchange line. If they're VoIP lines, the address is >> *supposed* to be so registered, but softphones and even VoIP handsets >> tend to move around without the user considering 9-1-1. > > VoIP was dragged kicking and screaming into E911, so now they charge > extra and are quite clear about it. My VoIP provider regularly > reminds me to update my 9-1-1 address, but since I don't have to pay > the 9-1-1 fee if I lie and say I'm outside North America, that's what > I do. Since I also have a classic CO-powered copper landline (1/4 > mile from the CO, no concentrators or repeaters) and a couple of cell > phones, I think we're covered. With my VOIP provider, I didn?t quite have to lie. I generally don?t need my VOIP number when I?m in the US (cell is free here), so I simply told them ?I do not intend to use this number or this service within the US?. The first time I sent them a marked-up contract, they contacted me with questions. The following year, the new version of the contract reflected my changes to their original wording. Since then, I?ve been pretty much satisfied with my service from callcentric and the price is right. Owen From johnl at iecc.com Thu Apr 14 17:12:17 2016 From: johnl at iecc.com (John R. Levine) Date: 14 Apr 2016 13:12:17 -0400 Subject: phone fun, was GeoIP database issues and the real world consequences In-Reply-To: References: <20160414124620.18804.qmail@ary.lan> Message-ID: > Since then, I?ve been pretty much satisfied with my service from callcentric > and the price is right. That's who I use. Now there's just a box on the web site to say not in the US. R's, John From sean at donelan.com Thu Apr 14 17:23:38 2016 From: sean at donelan.com (Sean Donelan) Date: Thu, 14 Apr 2016 13:23:38 -0400 (EDT) Subject: FCC Privacy NPRM In-Reply-To: References: Message-ID: On Thu, 14 Apr 2016, Livingood, Jason wrote: > I have not yet read all of the 147 pages of the FCC Privacy NPRM - > https://www.fcc.gov/document/fcc-releases-proposed-rules-protect-broadband- > consumer-privacy. But it may be worth noting, especially for this > audience, that the FCC proposes considering things like IP addresses and > geo-location information to be Customer Proprietary Information. Pretty much all ISPs should take a look at this NPRM. Although its advertised as a "privacy" rule-making, it has a several sections on ISP data security and data breach notification, including mandatory reporting to the FCC and FBI. From paras at protrafsolutions.com Thu Apr 14 17:27:11 2016 From: paras at protrafsolutions.com (Paras Jha) Date: Thu, 14 Apr 2016 13:27:11 -0400 Subject: FCC Privacy NPRM In-Reply-To: References: Message-ID: Page Not Found Link wasn't copied correctly, the "consumer-privacy" bit was cut off. Here's the working link: https://www.fcc.gov/document/fcc-releases-proposed-rules-protect-broadband-consumer-privacy On Thu, Apr 14, 2016 at 1:23 PM, Sean Donelan wrote: > On Thu, 14 Apr 2016, Livingood, Jason wrote: > >> I have not yet read all of the 147 pages of the FCC Privacy NPRM - >> >> https://www.fcc.gov/document/fcc-releases-proposed-rules-protect-broadband- >> consumer-privacy. But it may be worth noting, especially for this >> audience, that the FCC proposes considering things like IP addresses and >> geo-location information to be Customer Proprietary Information. >> > > Pretty much all ISPs should take a look at this NPRM. Although its > advertised as a "privacy" rule-making, it has a several sections on ISP > data security and data breach notification, including mandatory reporting > to the FCC and FBI. > > From larrysheldon at cox.net Thu Apr 14 19:57:33 2016 From: larrysheldon at cox.net (Larry Sheldon) Date: Thu, 14 Apr 2016 14:57:33 -0500 Subject: phone fun, was GeoIP database issues and the real world consequences In-Reply-To: <20160414153236.GA88366@ussenterprise.ufp.org> References: <570ED607.1070607@cox.net> <20160414002939.15867.qmail@ary.lan> <20160414153236.GA88366@ussenterprise.ufp.org> Message-ID: <570FF62D.9010707@cox.net> On 4/14/2016 10:32, Leo Bicknell wrote: > In a message written on Thu, Apr 14, 2016 at 12:29:39AM -0000, John Levine wrote: >> The people on nanog are not typical. I looked around for statistics >> and didn't find much, but it looks like only a few percent of numbers >> are ported each month, and it's often the same numbers being ported >> repeatedly. > > It's a big issue for political pollers, and they have some data: > > http://www.pewresearch.org/fact-tank/2016/01/05/pew-research-center-will-call-75-cellphones-for-surveys-in-2016/ > > "roughly half (47%) of U.S. adults whose only phone is a cellphone." > > "in a recent national poll, 8% of people interviewed by cellphone in > California had a phone number from a state other than California. > Similarly, of the people called on a cellphone number associated with > California, 10% were interviewed in a different state." > > So maybe 10% of all cell phones are primarly used in the "wrong" area? OK, let us suppose I want to be a law biding, up right American and use only a cellphone for the "right" area. I drive a big truck OTR. I usually know what part of which state I am in, but I frequently do not know which part of what state I will be in in 24 hours. What should I do? Suppose I was, instead, an aircrew member and the only truly stable datum is "Planet Earth"? -- sed quis custodiet ipsos custodes? (Juvenal) From larrysheldon at cox.net Thu Apr 14 20:10:21 2016 From: larrysheldon at cox.net (Larry Sheldon) Date: Thu, 14 Apr 2016 15:10:21 -0500 Subject: phone fun, was GeoIP database issues and the real world consequences In-Reply-To: References: <570ED607.1070607@cox.net> <20160414002939.15867.qmail@ary.lan> <20160414153236.GA88366@ussenterprise.ufp.org> Message-ID: <570FF92D.4090206@cox.net> On 4/14/2016 10:45, Gary Buhrmaster wrote: > On Thu, Apr 14, 2016 at 3:32 PM, Leo Bicknell wrote: > ..... >> So maybe 10% of all cell phones are primarly used in the "wrong" area? > > Obligatory xkcd ref: https://xkcd.com/1129/ I am reminded of incidents many years ago when I worked in a Revenue Accounting Office of a Bell System Operating Company. One of my duties involved dealing with the mostly-manually-processed toll calls originating or terminating at a Mobile Telephone System station in our area (whatever the word "area" turns out to mean). We wrote off a lot of revenue on calls that involved a company (if I remembered the name I still would not repeat it--ditto its location) which turn out to be pretty much one man who like to sell and install mobile radio telephone stations. And, it turns out, not even slightly interested in separations, bill an collecting, an other stuff that dominates an Operating Company's attentions. -- sed quis custodiet ipsos custodes? (Juvenal) From larrysheldon at cox.net Thu Apr 14 20:14:41 2016 From: larrysheldon at cox.net (Larry Sheldon) Date: Thu, 14 Apr 2016 15:14:41 -0500 Subject: phone fun, was GeoIP database issues and the real world consequences In-Reply-To: References: <20160414124620.18804.qmail@ary.lan> Message-ID: <570FFA31.3040708@cox.net> On 4/14/2016 12:09, Owen DeLong wrote: > >> On Apr 14, 2016, at 05:46 , John Levine wrote: >> >>> If they're land lines, the NPA/NXX will be local to the CO so you won't >>> have out-of-area numbers other than a rare corner case of a very >>> expensive foreign exchange line. If they're VoIP lines, the address is >>> *supposed* to be so registered, but softphones and even VoIP handsets >>> tend to move around without the user considering 9-1-1. >> >> VoIP was dragged kicking and screaming into E911, so now they charge >> extra and are quite clear about it. My VoIP provider regularly >> reminds me to update my 9-1-1 address, but since I don't have to pay >> the 9-1-1 fee if I lie and say I'm outside North America, that's what >> I do. Since I also have a classic CO-powered copper landline (1/4 >> mile from the CO, no concentrators or repeaters) and a couple of cell >> phones, I think we're covered. > > With my VOIP provider, I didn?t quite have to lie. > > I generally don?t need my VOIP number when I?m in the US (cell is free here), > so I simply told them ?I do not intend to use this number or this service > within the US?. > > The first time I sent them a marked-up contract, they contacted me with > questions. The following year, the new version of the contract reflected > my changes to their original wording. > > Since then, I?ve been pretty much satisfied with my service from callcentric > and the price is right. Quick question: What happens (in the purely hypothetical case, I sincerely hope) if the building is on fire and it turns out that the VOIP-phone is the only one that works? Do you leave it turned off? -- sed quis custodiet ipsos custodes? (Juvenal) From jfmezei_nanog at vaxination.ca Thu Apr 14 20:27:48 2016 From: jfmezei_nanog at vaxination.ca (Jean-Francois Mezei) Date: Thu, 14 Apr 2016 16:27:48 -0400 Subject: phone fun, was GeoIP database issues and the real world consequences In-Reply-To: <570FFA31.3040708@cox.net> References: <20160414124620.18804.qmail@ary.lan> <570FFA31.3040708@cox.net> Message-ID: <570FFD44.3090108@vaxination.ca> On 2016-04-14 16:14, Larry Sheldon wrote: > Quick question: What happens (in the purely hypothetical case, I > sincerely hope) if the building is on fire and it turns out that the > VOIP-phone is the only one that works? VOIP: Not purely theoretical situation. 911 where I live would take about 10 minutes of repeating my address and spelling it out to different people as I got passed around until I finally got to fire dept where I could finally and one last time spell out address. (I live on Fairwood, there is a street near here Sherwood). My ISP geolocates to a different down in south shore of montreal). What I do now: I have the actual telephone number for the fire station 3 blocks from where I live. When appt building alarm rings (we're not directly connected), I call the actual dept "have you received a call for
, we're on fire". They say "no, we haven't". I say "expect one in about 10 minutes once I get through the 911 bozos". When you call 911, you first have to select from a gazillion languages. Cell phone: Got hit by hit and run, but managed to stay on my bike. Arm hurt like hell. Was mad as hell. Made mistake of calling 911 who refused to pass me to Suret? du Qu?bec police (rural area). I was hoping they had a car that was in area and could intercept that white car as it intersected with main road a few km down the road. 911 insisted they send an ambulance, that I was in shock etc etc. They asked me to spell out the street I was on. Told them I had to get to the next intersection with a country rd to see the spelling. (meanwhile, they insist I don't move because they want to send ambulance, not believing I was still on my bike rolling at low speed). At no point did they give me ANY indication they had my location from towers or my iphone. When I finally go through to the SQ, we arranged to meet at intersection with main road. They saw my bruised arm, and saw I was quite mad/nervous/in shock. They told me to bypass 911 alltogether and call *4141 to get them right away and that they have the same tools to locate a call. ((in hindsight, drunk young guys accelerated to high speed and passed right next to me and threw something at me which it my arm at high speed. Initially though I had hit their mirror but mirror t low to have hit near shoulder). From larrysheldon at cox.net Thu Apr 14 20:57:35 2016 From: larrysheldon at cox.net (Larry Sheldon) Date: Thu, 14 Apr 2016 15:57:35 -0500 Subject: phone fun, was GeoIP database issues and the real world consequences In-Reply-To: <570FF92D.4090206@cox.net> References: <570ED607.1070607@cox.net> <20160414002939.15867.qmail@ary.lan> <20160414153236.GA88366@ussenterprise.ufp.org> <570FF92D.4090206@cox.net> Message-ID: <5710043F.3070607@cox.net> On 4/14/2016 15:10, Larry Sheldon wrote: > We wrote off a lot of revenue on calls that involved a company (if I > remembered the name I still would not repeat it--ditto its location) > which turn out to be pretty much one man who like to sell and install > mobile radio telephone stations. And, it turns out, not even slightly > interested in separations, bill and collecting, an other stuff that I think I meant "settlements", not "separations". But I'm not sure. > dominates an Operating Company's attentions. -- sed quis custodiet ipsos custodes? (Juvenal) From johnl at iecc.com Thu Apr 14 21:01:44 2016 From: johnl at iecc.com (John Levine) Date: 14 Apr 2016 21:01:44 -0000 Subject: phone fun, was GeoIP database issues and the real world consequences In-Reply-To: <570FF62D.9010707@cox.net> Message-ID: <20160414210144.1859.qmail@ary.lan> >OK, let us suppose I want to be a law biding, up right American and use >only a cellphone for the "right" area. > >I drive a big truck OTR. I usually know what part of which state I am >in, but I frequently do not know which part of what state I will be in >in 24 hours. > >What should I do? As previous messages have explained, mobile 9-1-1 uses a variety of GPS and tower info to determine where you are. Telcos, stupid though they may be, have figured out that people with mobile phones are likely to be, you know, mobile. If you drive a big truck, you're likely to spend a lot of time on major highways, and many of those highways have signs that tell you what to dial to contact the appropriate police for that road, e.g. *MSP on the Mass Pike. R's, John From jtk at cymru.com Thu Apr 14 21:19:58 2016 From: jtk at cymru.com (John Kristoff) Date: Thu, 14 Apr 2016 16:19:58 -0500 Subject: Security Track @ NANOG 67 Call for Participation Message-ID: <20160414161958.74f8c98b@localhost> [ Apologies if you saw this elsewhere already - jtk ] Friends, colleagues, fellow operators, The network security track, formerly known as the ISP security BoF, may be on the agenda at NANOG 67 in Chicago and if we can put together a reasonable agenda I may be your track facilitator. We not only seek your participation, but we are also interested you contributing to the track content. If you have an idea or if you know someone who might like to present, discuss or conduct a demonstration of something, we want to hear from you. Here is an incomplete list of relevant topics to stir your thoughts: * Privacy-related issues and topics * DDoS attacks and mitigation * Internet of Things and security * Government regulatory and compliance issues * IPv6 considerations * abuse@ management and war stories * 802.11 authentication, authorization and accounting * New security software projects and tools (non-commercial) * BGPSEC and RPKI * The latest in protocol abuse * John From owen at delong.com Thu Apr 14 21:33:30 2016 From: owen at delong.com (Owen DeLong) Date: Thu, 14 Apr 2016 14:33:30 -0700 Subject: phone fun, was GeoIP database issues and the real world consequences In-Reply-To: <570FFA31.3040708@cox.net> References: <20160414124620.18804.qmail@ary.lan> <570FFA31.3040708@cox.net> Message-ID: <796DE39A-0486-4AE5-BEA9-AEF7D2E28FD9@delong.com> > On Apr 14, 2016, at 13:14 , Larry Sheldon wrote: > > On 4/14/2016 12:09, Owen DeLong wrote: >> >>> On Apr 14, 2016, at 05:46 , John Levine wrote: >>> >>>> If they're land lines, the NPA/NXX will be local to the CO so you won't >>>> have out-of-area numbers other than a rare corner case of a very >>>> expensive foreign exchange line. If they're VoIP lines, the address is >>>> *supposed* to be so registered, but softphones and even VoIP handsets >>>> tend to move around without the user considering 9-1-1. >>> >>> VoIP was dragged kicking and screaming into E911, so now they charge >>> extra and are quite clear about it. My VoIP provider regularly >>> reminds me to update my 9-1-1 address, but since I don't have to pay >>> the 9-1-1 fee if I lie and say I'm outside North America, that's what >>> I do. Since I also have a classic CO-powered copper landline (1/4 >>> mile from the CO, no concentrators or repeaters) and a couple of cell >>> phones, I think we're covered. >> >> With my VOIP provider, I didn?t quite have to lie. >> >> I generally don?t need my VOIP number when I?m in the US (cell is free here), >> so I simply told them ?I do not intend to use this number or this service >> within the US?. >> >> The first time I sent them a marked-up contract, they contacted me with >> questions. The following year, the new version of the contract reflected >> my changes to their original wording. >> >> Since then, I?ve been pretty much satisfied with my service from callcentric >> and the price is right. > > Quick question: What happens (in the purely hypothetical case, I sincerely hope) if the building is on fire and it turns out that the VOIP-phone is the only one that works? That would be an interesting phenomenon since my VOIP clients are both dependent on data services working on one of laptop, iPad, iPhone. > Do you leave it turned off? Of course not, but since the building in question is very unlikely to have been any address I would have filed on said contract, it?s far better that the person at the other end is having to ask me for the address than to have emergency workers respond to some location that I?m not at. If, OTOH, the building in question is my home, I?m more likely to get a faster response by banging on a neighbors door than by struggling to get the VOIP phone up and running on some alternative connectivity. Owen From owen at delong.com Thu Apr 14 21:46:48 2016 From: owen at delong.com (Owen DeLong) Date: Thu, 14 Apr 2016 14:46:48 -0700 Subject: phone fun, was GeoIP database issues and the real world consequences In-Reply-To: <20160414210144.1859.qmail@ary.lan> References: <20160414210144.1859.qmail@ary.lan> Message-ID: > On Apr 14, 2016, at 14:01 , John Levine wrote: > >> OK, let us suppose I want to be a law biding, up right American and use >> only a cellphone for the "right" area. >> >> I drive a big truck OTR. I usually know what part of which state I am >> in, but I frequently do not know which part of what state I will be in >> in 24 hours. >> >> What should I do? > > As previous messages have explained, mobile 9-1-1 uses a variety of > GPS and tower info to determine where you are. Telcos, stupid though > they may be, have figured out that people with mobile phones are > likely to be, you know, mobile. Now if they could only figure this out for VOIP clients. I realize that there are fixed-location VOIP phones and they may be the majority, but I also know that there are quite a few of us with VOIP clients that are as mobile as our mobile phones, sometimes more so since my VOIP client doesn?t turn into $2/min. when I enter the wrong country. Amusingly, 128k free data from T-Mo as a mobile hot spot in many countries is quite adequate for a VOIP client while making a call on the phone would cost $$. > If you drive a big truck, you're likely to spend a lot of time on > major highways, and many of those highways have signs that tell you > what to dial to contact the appropriate police for that road, e.g. > *MSP on the Mass Pike. Depends on where you are. I?ve never seen such a sign anywhere on any major highway in California and mobile 911 calls in this state often get ?interesting? routing. Fortunately, I?ve never encountered a dispatcher that required answers to more than one additional question in order to comply with my request that they route to the correct agency (I usually start off with enough information to tell them I know why I want to speak to the agency I am specifying, such as ?I?m reporting an incident on {US/Interstate/State Hwy specification, e.g. US 101}, please transfer me to CHP? (CHP = California Highway Patrol, which has dispatch jurisdiction for all state and federal highways within California). OTOH, I?ve been in parts of Canada where the signs merely specify that there is no 911 service beyond that point without offering any alternative. Of course most of those signs were encountered well after my mobile stopped having any service whatsoever, so I always found them mildly amusing. Most of them are a giant picture of a motorola Brick phone from the late ?80s with the message ?Leaving 911 service area?. I can?t find an appropriate image to reference in a google search, but I assure you that they were common place, at least last time I was in the Yukon. Owen From surfer at mauigateway.com Thu Apr 14 22:05:13 2016 From: surfer at mauigateway.com (Scott Weeks) Date: Thu, 14 Apr 2016 15:05:13 -0700 Subject: phone fun, was GeoIP database issues and the real world consequences Message-ID: <20160414150513.E76E8CAE@m0087795.ppops.net> --- josh at kyneticwifi.com wrote: From: Josh Reynolds Is NANOG really the best place for this discussion? -------------------------------------- Filter it out. scott From todd.crane at n5tech.com Thu Apr 14 23:43:00 2016 From: todd.crane at n5tech.com (Todd Crane) Date: Thu, 14 Apr 2016 16:43:00 -0700 Subject: GeoIP database issues and the real world consequences In-Reply-To: <60434.1460553905@turing-police.cc.vt.edu> References: <20160411181508.60367.qmail@ary.lan> <570BEDC9.50308@heliacal.net> <570D8FFF.7040105@vaxination.ca> <569C966F-14EE-44C5-A26B-C8E5E8D9186A@n5tech.com> <60434.1460553905@turing-police.cc.vt.edu> Message-ID: <576FC021-D392-4216-AFBF-AE3E7DFCB293@n5tech.com> You do realize that this is the exact kind of thing that caused this discussion in the first place. I'm well familiar with that case. I was talking about my own experiences in the food service industry, but of course you barely read a sentence and set on a war path accusing me of not checking my facts, quite like somebody googling a geolocation for an ip and harnessing/threatening the other side. As to the case, it had its merits, but since then it has spawned a whole bunch of people trying to get rich quick. Now every company has to put these warning labels to appease their insurance companies. Now we have people that can't think for themselves that NEED labels. It's much like the debate about trying to legislate common sense. Todd Crane > On Apr 13, 2016, at 6:25 AM, Valdis.Kletnieks at vt.edu wrote: > > On Tue, 12 Apr 2016 22:57:42 -0700, Todd Crane said: >> .What ever happened to holding people responsible for being >> stupid. When did it start becoming ((fill in the blank)) coffee shop >> for you burning your tongue on your coffee > > Whatever happened to holding people responsible for fact checking before they > post? :) > > You *do* realize that the woman in the McDonald's case got *third degree* > burns and required skin grafts, right? Water at 180F is hot enough to > burn you - we even have a word for it: scalding. And unlike sipping too-hot > coffee, where you can spit it out quickly, hot water spilled on clothing > continues to burn until the clothing is removed or cooled off - neither of > which is feasible when you're elderly and seated in a car. > > And that she originally only sued for the cost of her medical bills, and the > jury increased it with punitive damages when presented evidence that over 700 > other people had received burns? > > Now go and get informed, and commit this sin no more :) > > https://www.caoc.org/?pg=facts - how that lawsuit *actually* played out. From jay at west.net Fri Apr 15 00:20:01 2016 From: jay at west.net (Jay Hennigan) Date: Thu, 14 Apr 2016 17:20:01 -0700 Subject: GeoIP database issues and the real world consequences In-Reply-To: <60434.1460553905@turing-police.cc.vt.edu> References: <20160411181508.60367.qmail@ary.lan> <570BEDC9.50308@heliacal.net> <570D8FFF.7040105@vaxination.ca> <569C966F-14EE-44C5-A26B-C8E5E8D9186A@n5tech.com> <60434.1460553905@turing-police.cc.vt.edu> Message-ID: <571033B1.6090908@west.net> On 4/13/16 6:25 AM, Valdis.Kletnieks at vt.edu wrote: > You *do* realize that the woman in the McDonald's case got *third degree* > burns and required skin grafts, right? Water at 180F is hot enough to > burn you - we even have a word for it: scalding. And unlike sipping too-hot > coffee, where you can spit it out quickly, hot water spilled on clothing > continues to burn until the clothing is removed or cooled off - neither of > which is feasible when you're elderly and seated in a car. > > And that she originally only sued for the cost of her medical bills, and the > jury increased it with punitive damages when presented evidence that over 700 > other people had received burns? > > Now go and get informed, and commit this sin no more :) > > https://www.caoc.org/?pg=facts - how that lawsuit *actually* played out. and http://www.stellaawards.com/ lists dozens of other lawsuits spawned by that result, as well as commentary on the McDonald's case. Last updated 2008 but I'm sure examples are still flooding in to a courtroom near you. -- 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 jfmezei_nanog at vaxination.ca Fri Apr 15 02:43:04 2016 From: jfmezei_nanog at vaxination.ca (Jean-Francois Mezei) Date: Thu, 14 Apr 2016 22:43:04 -0400 Subject: DOCSIS 3.1 upstream Message-ID: <57105538.4030105@vaxination.ca> Canadian cable carriers seem to have all told the CRTC they can only carry 42mhz in the upstream because their amplifiers and nodes only amplify that narrow band in the upstream direction. Is/was 42mhz common across north america ? In a typical installation, how much of the 42mhz is actually usable for upstream data ? (aka: how many 6mhz chunks are taken for TV STBs, Telephony and whatever other upstream channels. I think I heard that one 6mhz chunk is used for one the low numbered TV analogue channels. (although cablecos are slowly widthdrawing analogue TV now). Am trying to figure out realistic bandwidth that a cableco with 42mhz limits for upstream will get on 3.1. Also, have cablecos with such limits for upstream begun to upgrade the cable plant to increase the upstream bandwidth ? Canadian cablecos have told the regulator it would be prohibitively expensive to do so, but incumbents tend to exagerate these things when it is convenient. (they can then claim higher costs/congestion/need for node splits which increates regulated wholesale rates). And would it be correct that in RFoG deployment, the 42mhz limit disapears as the customer equipment talks directly tothe CMTS over fibre all the way ? From larrysheldon at cox.net Fri Apr 15 04:48:24 2016 From: larrysheldon at cox.net (Laurence F. Sheldon, Jr.) Date: Thu, 14 Apr 2016 23:48:24 -0500 Subject: phone fun, was GeoIP database issues and the real world consequences In-Reply-To: <20160414210144.1859.qmail@ary.lan> References: <20160414210144.1859.qmail@ary.lan> Message-ID: <57107298.9090604@cox.net> On 4/14/2016 16:01, John Levine wrote: >> OK, let us suppose I want to be a law biding, up right American and use >> only a cellphone for the "right" area. >> >> I drive a big truck OTR. I usually know what part of which state I am >> in, but I frequently do not know which part of what state I will be in >> in 24 hours. >> >> What should I do? > > As previous messages have explained, mobile 9-1-1 uses a variety of > GPS and tower info to determine where you are. Telcos, stupid though > they may be, have figured out that people with mobile phones are > likely to be, you know, mobile. > > If you drive a big truck, you're likely to spend a lot of time on > major highways, and many of those highways have signs that tell you > what to dial to contact the appropriate police for that road, e.g. > *MSP on the Mass Pike. I understand all that. I quoted somebody as saying that some percentage of people use a cellphone in the wrong area code. I want never be caught in the wrong area code in my nomadic life. I think my best shot is to convince people that telephone numbers are not addresses of people and like my SSAN is assigned by somebody, I don't care who. From tim at pelican.org Fri Apr 15 08:49:37 2016 From: tim at pelican.org (tim at pelican.org) Date: Fri, 15 Apr 2016 09:49:37 +0100 (BST) Subject: phone fun, was GeoIP database issues and the real world consequences In-Reply-To: <20160414153236.GA88366@ussenterprise.ufp.org> References: <570ED607.1070607@cox.net> <20160414002939.15867.qmail@ary.lan> <20160414153236.GA88366@ussenterprise.ufp.org> Message-ID: <1460710177.364730809@apps.rackspace.com> On Thursday, 14 April, 2016 16:32, "Leo Bicknell" said: > So maybe 10% of all cell phones are primarly used in the "wrong" area? Out of curiosity, does anyone have a good pointer to the history of how / why US mobile ended up in the same numbering plan as fixed-line? Over here in the UK we had a very different approach where mobile phones went into their own area codes from the start, hence no confusion as to what type of device you were calling, and it was trivial to put the increased cost of the call on the caller. (It's *incredibly* rare, if not non-existent, here for the mobile user to pay for incoming calls or SMS). Of course, we got our own set of problems once number portability kicked in - a lot of operators had set up "free / cheap on the same network" tarrifs, which was easy while you knew for sure that 07aaa nnnnnn was Orange but 07bbb nnnnnn was O2. Once you could take your number with you to another network, it became a lot more guesss-work as to how much you were going to be billed for any given call... Regards, Tim. From nick at foobar.org Fri Apr 15 10:07:55 2016 From: nick at foobar.org (Nick Hilliard) Date: Fri, 15 Apr 2016 11:07:55 +0100 Subject: DOCSIS 3.1 upstream In-Reply-To: <57105538.4030105@vaxination.ca> References: <57105538.4030105@vaxination.ca> Message-ID: <5710BD7B.2060502@foobar.org> Jean-Francois Mezei wrote: > Canadian cable carriers seem to have all told the CRTC they can only > carry 42mhz in the upstream because their amplifiers and nodes only > amplify that narrow band in the upstream direction. > > Is/was 42mhz common across north america ? 42MHz was the traditional upper limit for annex b docsis. That limit was extended up to 85MHz several years ago, but yeah there's probably a lot of plant out there which can't go above 42MHz for legacy reasons. > Am trying to figure out realistic bandwidth that a cableco with 42mhz > limits for upstream will get on 3.1. If the cableco is limited to 42MHz, there will be 37MHz of upstream bandwidth (5 to 42), which allows five 6.4MHz upstream channels of 5120ksym/sec. 3.1 improves the upstream modulation from 64qam to 4096qam, which ups the bit throughput rate from 6 bits per symbol to 12 bits. That gives 5120*5*12 = 307200 of physical layer bit throughput, and you should budget ~25-ish% for overhead to get usable customer bits per second. That's in lab conditions though. The reality is that you're not going to be able to use qam4096 unless your upstream path has ridiculously good SNR. If the cable network can't go above 42MHz, it's probably legacy plant which implies older deployments and there's a real likelihood that the improvements in DOCSIS 3.1 aren't going to make a blind bit of difference. It would be probably be easier and more reliable to do plant upgrades / service retirement to allow 85MHz (12 u/s channels) than clean up the plant so that you get the 30-35dB SNR required to run 4096QAM. You can't make extra bandwidth out of nothing. > Also, have cablecos with such limits for upstream begun to upgrade the > cable plant to increase the upstream bandwidth ? I would hope they have. If they don't, their businesses will be savaged in the longer term by the introduction of gpon and other fiber technologies. Nick From lorell at hathcock.org Fri Apr 15 11:52:50 2016 From: lorell at hathcock.org (Lorell Hathcock) Date: Fri, 15 Apr 2016 06:52:50 -0500 Subject: DOCSIS 3.1 upstream In-Reply-To: <5710BD7B.2060502@foobar.org> References: <57105538.4030105@vaxination.ca> <5710BD7B.2060502@foobar.org> Message-ID: <4D9A6F49-2154-4BF1-901B-DB010FD71E45@hathcock.org> In our small, aging plant very near the Mexican border in south Texas, the SNR for <~30MHz is ~20 dB so we can only use two upstream channels. It works okay for our 150 cable modem customers. They can get 40 Mbps upstream throughput. The downstream channels are around 300MHz with much better SNR so we can bond 8 channels. Depending on load, customers can get up to 80 Mbps downstream throughput. This is on a DOCSIS 3.0 Cisco CMTS network with a 10 year old cable plant. Lorell Sent from my iPhone > On Apr 15, 2016, at 5:07 AM, Nick Hilliard wrote: > > Jean-Francois Mezei wrote: >> Canadian cable carriers seem to have all told the CRTC they can only >> carry 42mhz in the upstream because their amplifiers and nodes only >> amplify that narrow band in the upstream direction. >> >> Is/was 42mhz common across north america ? > > 42MHz was the traditional upper limit for annex b docsis. That limit > was extended up to 85MHz several years ago, but yeah there's probably a > lot of plant out there which can't go above 42MHz for legacy reasons. > >> Am trying to figure out realistic bandwidth that a cableco with 42mhz >> limits for upstream will get on 3.1. > > If the cableco is limited to 42MHz, there will be 37MHz of upstream > bandwidth (5 to 42), which allows five 6.4MHz upstream channels of > 5120ksym/sec. 3.1 improves the upstream modulation from 64qam to > 4096qam, which ups the bit throughput rate from 6 bits per symbol to 12 > bits. That gives 5120*5*12 = 307200 of physical layer bit throughput, > and you should budget ~25-ish% for overhead to get usable customer bits > per second. > > That's in lab conditions though. The reality is that you're not going > to be able to use qam4096 unless your upstream path has ridiculously > good SNR. If the cable network can't go above 42MHz, it's probably > legacy plant which implies older deployments and there's a real > likelihood that the improvements in DOCSIS 3.1 aren't going to make a > blind bit of difference. It would be probably be easier and more > reliable to do plant upgrades / service retirement to allow 85MHz (12 > u/s channels) than clean up the plant so that you get the 30-35dB SNR > required to run 4096QAM. You can't make extra bandwidth out of nothing. > >> Also, have cablecos with such limits for upstream begun to upgrade the >> cable plant to increase the upstream bandwidth ? > > I would hope they have. If they don't, their businesses will be savaged > in the longer term by the introduction of gpon and other fiber technologies. > > Nick > From Valdis.Kletnieks at vt.edu Fri Apr 15 14:05:06 2016 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Fri, 15 Apr 2016 10:05:06 -0400 Subject: GeoIP database issues and the real world consequences In-Reply-To: <576FC021-D392-4216-AFBF-AE3E7DFCB293@n5tech.com> References: <20160411181508.60367.qmail@ary.lan> <570BEDC9.50308@heliacal.net> <570D8FFF.7040105@vaxination.ca> <569C966F-14EE-44C5-A26B-C8E5E8D9186A@n5tech.com> <60434.1460553905@turing-police.cc.vt.edu> <576FC021-D392-4216-AFBF-AE3E7DFCB293@n5tech.com> Message-ID: <57756.1460729106@turing-police.cc.vt.edu> On Thu, 14 Apr 2016 16:43:00 -0700, Todd Crane said: > You do realize that this is the exact kind of thing that caused this > discussion in the first place. I'm well familiar with that case. I was talking > about my own experiences in the food service industry, but of course you barely > read a sentence and set on a war path accusing me of not checking my facts Sorry. You are *literally* the first person I've seen who's put "hot coffee" and "responsible for being stupid" in a sentence who was actually familiar with the case in question, and thought that the case had merit, and was (apparently) actually talking about the follow-on cases rather than the original case that made the news. In addition, you didn't make it very clear that you weren't talking about the original case. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From jmglass at iup.edu Thu Apr 14 11:40:05 2016 From: jmglass at iup.edu (Jim Glassford) Date: Thu, 14 Apr 2016 07:40:05 -0400 Subject: [Ext] Re: G root not responding on UDP? In-Reply-To: References: Message-ID: <570F8195.7000404@iup.edu> fyi, some discussion and below link from the bind mailing list on this https://atlas.ripe.net/dnsmon/group/g-root On 4/14/2016 7:36 AM, Nicholas Suan wrote: > I'm see the same thing from multiple networks. > > $ dig NS . @g.root-servers.net > > ; <<>> DiG 9.9.5 <<>> NS . @g.root-servers.net > ;; global options: +cmd > ;; connection timed out; no servers could be reached > > On Thu, Apr 14, 2016 at 7:30 AM, Anurag Bhatia wrote: >> Hello everyone >> >> >> I wonder if it's just me or anyone else also finding issues in g root >> reachability? >> >> >> ICMP, trace, UDP DNS queries all timing out. Only TCP seem to work. >> >> >> Trace is timing out on 208.46.37.38. >> >> >> >> traceroute to 192.112.36.4 (192.112.36.4), 64 hops max, 52 byte packets >> 1 router01.home (172.16.0.1) 4.926 ms 1.863 ms 1.845 ms >> 2 103.60.176.101 (103.60.176.101) 24.007 ms 24.507 ms 22.330 ms >> 3 nsg-static-137.49.75.182-airtel.com (182.75.49.137) 64.435 ms 64.359 >> ms 66.108 ms >> 4 182.79.206.46 (182.79.206.46) 331.787 ms >> 182.79.206.53 (182.79.206.53) 228.497 ms >> 182.79.222.189 (182.79.222.189) 224.966 ms >> 5 ldn-brdr-01.qwest.net (195.66.225.34) 162.745 ms 162.139 ms 162.031 >> ms >> 6 lon-ddos-01.inet.qwest.net (67.14.63.58) 162.138 ms 162.125 ms >> 162.916 ms >> 7 * * * >> 8 chp-edge-01.inet.qwest.net (208.46.37.37) 242.819 ms 242.793 ms >> 242.575 ms >> 9 208.46.37.38 (208.46.37.38) 253.176 ms 253.066 ms 252.807 ms >> 10 * * * >> 11 * * * >> 12 * * * >> >> >> >> >> dig @192.112.36.4 . ns >> >> ; <<>> DiG 9.8.3-P1 <<>> @192.112.36.4 . ns >> ; (1 server found) >> ;; global options: +cmd >> ;; connection timed out; no servers could be reached >> >> >> >> >> >> dig @192.112.36.4 . ns +tcp +noauth >> >> ; <<>> DiG 9.8.3-P1 <<>> @192.112.36.4 . ns +tcp +noauth >> ; (1 server found) >> ;; global options: +cmd >> ;; Got answer: >> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 29674 >> ;; flags: qr aa rd; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 24 >> ;; WARNING: recursion requested but not available >> >> ;; QUESTION SECTION: >> ;. IN NS >> >> ;; ANSWER SECTION: >> . 518400 IN NS g.root-servers.net. >> . 518400 IN NS l.root-servers.net. >> . 518400 IN NS f.root-servers.net. >> . 518400 IN NS h.root-servers.net. >> . 518400 IN NS k.root-servers.net. >> . 518400 IN NS b.root-servers.net. >> . 518400 IN NS c.root-servers.net. >> . 518400 IN NS e.root-servers.net. >> . 518400 IN NS j.root-servers.net. >> . 518400 IN NS i.root-servers.net. >> . 518400 IN NS m.root-servers.net. >> . 518400 IN NS a.root-servers.net. >> . 518400 IN NS d.root-servers.net. >> >> ;; ADDITIONAL SECTION: >> a.root-servers.net. 3600000 IN A 198.41.0.4 >> b.root-servers.net. 3600000 IN A 192.228.79.201 >> c.root-servers.net. 3600000 IN A 192.33.4.12 >> d.root-servers.net. 3600000 IN A 199.7.91.13 >> e.root-servers.net. 3600000 IN A 192.203.230.10 >> f.root-servers.net. 3600000 IN A 192.5.5.241 >> g.root-servers.net. 3600000 IN A 192.112.36.4 >> h.root-servers.net. 3600000 IN A 198.97.190.53 >> i.root-servers.net. 3600000 IN A 192.36.148.17 >> j.root-servers.net. 3600000 IN A 192.58.128.30 >> k.root-servers.net. 3600000 IN A 193.0.14.129 >> l.root-servers.net. 3600000 IN A 199.7.83.42 >> m.root-servers.net. 3600000 IN A 202.12.27.33 >> a.root-servers.net. 3600000 IN AAAA 2001:503:ba3e::2:30 >> b.root-servers.net. 3600000 IN AAAA 2001:500:84::b >> c.root-servers.net. 3600000 IN AAAA 2001:500:2::c >> d.root-servers.net. 3600000 IN AAAA 2001:500:2d::d >> f.root-servers.net. 3600000 IN AAAA 2001:500:2f::f >> h.root-servers.net. 3600000 IN AAAA 2001:500:1::53 >> i.root-servers.net. 3600000 IN AAAA 2001:7fe::53 >> j.root-servers.net. 3600000 IN AAAA 2001:503:c27::2:30 >> k.root-servers.net. 3600000 IN AAAA 2001:7fd::1 >> l.root-servers.net. 3600000 IN AAAA 2001:500:9f::42 >> m.root-servers.net. 3600000 IN AAAA 2001:dc3::35 >> >> ;; Query time: 259 msec >> ;; SERVER: 192.112.36.4#53(192.112.36.4) >> ;; WHEN: Thu Apr 14 16:59:09 2016 >> ;; MSG SIZE rcvd: 744 >> >> >> >> >> >> Is UDP blocked recently or it has been like this from long? >> >> >> >> -- >> >> >> Anurag Bhatia >> anuragbhatia.com From johnl at iecc.com Fri Apr 15 14:51:45 2016 From: johnl at iecc.com (John R. Levine) Date: 15 Apr 2016 10:51:45 -0400 Subject: phone fun, was GeoIP database issues and the real world consequences In-Reply-To: <1460710177.364730809@apps.rackspace.com> References: <20160414153236.GA88366@ussenterprise.ufp.org> <570ED607.1070607@cox.net> <20160414002939.15867.qmail@ary.lan> <1460710177.364730809@apps.rackspace.com> Message-ID: > So maybe 10% of all cell phones are primarly used in the "wrong" area? > Out of curiosity, does anyone have a good pointer to the history of > how / why US mobile ended up in the same numbering plan as fixed-line? The US and most of the rest of North America have a fixed length numbering plan designed in the 1940s by the Bell System. They offered it to the CCITT which for political and technical reasons decided to do something else. (So when anyone complains that the NANP is "non-standard", you had your chance.) Fixed length numbers allowed much more sophisticated call routing with mechanical switches than variable length did. For reasons not worth rehashing, there was no possibility whatsoever of adding digits or otherwise changing the numbering plan. So if they were going to do caller pays mobile, they'd need to overlay mobile area codes on top of existing codes, and there weren't enough spare codes to do that. Putting mobiles into a handful of non-geographic codes as they do in Europe wouldn't work because the US is a very large country, long distance costs and charges were important, and they needed to be able to charge more for a mobile call across the country than across the street. (The distance from Seattle to Miami or Boston to San Francisco is greater than Lisbon to Moscow or Paris to Teheran.) In the US, mobile long distance charges have mostly gone away, but my Canadian mobile still charges more for a call to a different province than one to the same city. So rather than doing caller-pays as in Europe, North America does mobile-pays, with the mobile user charged for both incoming and outgoing calls. There turn out to be good economic reasons for that -- European mobile users imagine that incoming calls are "free", but in fact they are very expensive to the caller because the caller has no say in choosing the carrier or the price. For all its faults, the competition in US mobile service drove down prices much faster than in Europe, and US users use more minutes/month than Europeans do. If you want me to call you in the UK, I'm happy to call your landline for 1.3c/min, not so happy to call your mobile at 26c/min. ObNanog: E.164 and VoIP don't make this any easier. R's, John From tim at pelican.org Fri Apr 15 15:13:08 2016 From: tim at pelican.org (tim at pelican.org) Date: Fri, 15 Apr 2016 16:13:08 +0100 (BST) Subject: phone fun, was GeoIP database issues and the real world consequences In-Reply-To: References: <20160414153236.GA88366@ussenterprise.ufp.org> <570ED607.1070607@cox.net> <20160414002939.15867.qmail@ary.lan> <1460710177.364730809@apps.rackspace.com> Message-ID: <1460733188.1079216@apps.rackspace.com> On Friday, 15 April, 2016 15:51, "John R. Levine" said: > The US and most of the rest of North America have a fixed length > numbering plan designed in the 1940s by the Bell System. They offered > it to the CCITT which for political and technical reasons decided to > do something else. (So when anyone complains that the NANP is > "non-standard", you had your chance.) Fixed length numbers allowed > much more sophisticated call routing with mechanical switches than > variable length did. [and a bunch more stuff] Thanks John - no bashing was intended, genuinely interested in the different models / histories, and that helps. Regards, Tim. From shopik+lists at nvcube.net Fri Apr 15 15:15:50 2016 From: shopik+lists at nvcube.net (Nikolay Shopik) Date: Fri, 15 Apr 2016 18:15:50 +0300 Subject: phone fun, was GeoIP database issues and the real world consequences In-Reply-To: References: <20160414153236.GA88366@ussenterprise.ufp.org> <570ED607.1070607@cox.net> <20160414002939.15867.qmail@ary.lan> <1460710177.364730809@apps.rackspace.com> Message-ID: <571105A6.3040607@nvcube.net> On 15/04/16 17:51, John R. Levine wrote: > Putting mobiles into a handful of non-geographic codes as they do in > Europe wouldn't work because the US is a very large country, long > distance costs and charges were important, and they needed to be able > to charge more for a mobile call across the country than across the > street. I would like to add that Russian mobiles in non-geographic codes and have free incoming calls (it wasn't until 2006) and also very large territory. But that created internal roaming prices within country. So if you are making call not from your home region you'll pay more also you may pay for incoming call too (unless you pay for such option to make your abroad incoming calls free) From cscora at apnic.net Fri Apr 15 18:11:07 2016 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 16 Apr 2016 04:11:07 +1000 (AEST) Subject: Weekly Routing Table Report Message-ID: <201604151811.u3FIB7D0021502@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, SAFNOG, PaNOG, SdNOG, BJNOG, CaribNOG and the RIPE Routing WG. 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 Apr, 2016 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 590122 Prefixes after maximum aggregation (per Origin AS): 217231 Deaggregation factor: 2.72 Unique aggregates announced (without unneeded subnets): 288719 Total ASes present in the Internet Routing Table: 53427 Prefixes per ASN: 11.05 Origin-only ASes present in the Internet Routing Table: 36609 Origin ASes announcing only one prefix: 15715 Transit ASes present in the Internet Routing Table: 6422 Transit-only ASes present in the Internet Routing Table: 169 Average AS path length visible in the Internet Routing Table: 4.3 Max AS path length visible: 41 Max AS path prepend of ASN ( 55644) 36 Prefixes from unregistered ASNs in the Routing Table: 966 Unregistered ASNs in the Routing Table: 358 Number of 32-bit ASNs allocated by the RIRs: 13487 Number of 32-bit ASNs visible in the Routing Table: 10396 Prefixes from 32-bit ASNs in the Routing Table: 40624 Number of bogon 32-bit ASNs visible in the Routing Table: 13 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 388 Number of addresses announced to Internet: 2807919940 Equivalent to 167 /8s, 93 /16s and 117 /24s Percentage of available address space announced: 75.8 Percentage of allocated address space announced: 75.8 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 98.1 Total number of prefixes smaller than registry allocations: 193326 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 150247 Total APNIC prefixes after maximum aggregation: 42132 APNIC Deaggregation factor: 3.57 Prefixes being announced from the APNIC address blocks: 160679 Unique aggregates announced from the APNIC address blocks: 65668 APNIC Region origin ASes present in the Internet Routing Table: 5167 APNIC Prefixes per ASN: 31.10 APNIC Region origin ASes announcing only one prefix: 1184 APNIC Region transit ASes present in the Internet Routing Table: 912 Average APNIC Region AS path length visible: 4.4 Max APNIC Region AS path length visible: 41 Number of APNIC region 32-bit ASNs visible in the Routing Table: 2000 Number of APNIC addresses announced to Internet: 752212548 Equivalent to 44 /8s, 213 /16s and 218 /24s Percentage of available APNIC address space announced: 87.9 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: 180699 Total ARIN prefixes after maximum aggregation: 89549 ARIN Deaggregation factor: 2.02 Prefixes being announced from the ARIN address blocks: 185776 Unique aggregates announced from the ARIN address blocks: 88178 ARIN Region origin ASes present in the Internet Routing Table: 16390 ARIN Prefixes per ASN: 11.33 ARIN Region origin ASes announcing only one prefix: 5863 ARIN Region transit ASes present in the Internet Routing Table: 1716 Average ARIN Region AS path length visible: 3.8 Max ARIN Region AS path length visible: 37 Number of ARIN region 32-bit ASNs visible in the Routing Table: 1133 Number of ARIN addresses announced to Internet: 1101654336 Equivalent to 65 /8s, 169 /16s and 233 /24s Percentage of available ARIN address space announced: 58.3 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: 142165 Total RIPE prefixes after maximum aggregation: 70048 RIPE Deaggregation factor: 2.03 Prefixes being announced from the RIPE address blocks: 150969 Unique aggregates announced from the RIPE address blocks: 92852 RIPE Region origin ASes present in the Internet Routing Table: 18064 RIPE Prefixes per ASN: 8.36 RIPE Region origin ASes announcing only one prefix: 7900 RIPE Region transit ASes present in the Internet Routing Table: 3001 Average RIPE Region AS path length visible: 4.3 Max RIPE Region AS path length visible: 29 Number of RIPE region 32-bit ASNs visible in the Routing Table: 4649 Number of RIPE addresses announced to Internet: 704560256 Equivalent to 41 /8s, 254 /16s and 188 /24s Percentage of available RIPE address space announced: 102.4 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-204287 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: 62059 Total LACNIC prefixes after maximum aggregation: 12263 LACNIC Deaggregation factor: 5.06 Prefixes being announced from the LACNIC address blocks: 76192 Unique aggregates announced from the LACNIC address blocks: 35932 LACNIC Region origin ASes present in the Internet Routing Table: 2472 LACNIC Prefixes per ASN: 30.82 LACNIC Region origin ASes announcing only one prefix: 582 LACNIC Region transit ASes present in the Internet Routing Table: 557 Average LACNIC Region AS path length visible: 4.8 Max LACNIC Region AS path length visible: 22 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 2409 Number of LACNIC addresses announced to Internet: 170805824 Equivalent to 10 /8s, 46 /16s and 74 /24s Percentage of available LACNIC address space announced: 101.8 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: 14252 Total AfriNIC prefixes after maximum aggregation: 3198 AfriNIC Deaggregation factor: 4.46 Prefixes being announced from the AfriNIC address blocks: 16118 Unique aggregates announced from the AfriNIC address blocks: 5740 AfriNIC Region origin ASes present in the Internet Routing Table: 743 AfriNIC Prefixes per ASN: 21.69 AfriNIC Region origin ASes announcing only one prefix: 186 AfriNIC Region transit ASes present in the Internet Routing Table: 173 Average AfriNIC Region AS path length visible: 4.6 Max AfriNIC Region AS path length visible: 21 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 205 Number of AfriNIC addresses announced to Internet: 78315008 Equivalent to 4 /8s, 170 /16s and 254 /24s Percentage of available AfriNIC address space announced: 77.8 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 4538 5591 4192 76 China Education and Research 7545 3269 353 203 TPG Telecom Limited 4766 3159 11145 1119 Korea Telecom 17974 2919 914 96 PT Telekomunikasi Indonesia 9829 2481 1457 447 National Internet Backbone 4755 2096 432 241 TATA Communications formerly 9808 1843 8717 30 Guangdong Mobile Communicatio 4808 1658 2300 539 CNCGROUP IP network China169 9583 1507 121 563 Sify Limited 38197 1474 91 207 Sun Network (Hong Kong) Limit 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 3312 2948 143 Cox Communications Inc. 6389 2320 3687 42 BellSouth.net Inc. 18566 2209 394 276 MegaPath Corporation 20115 1924 1937 404 Charter Communications 30036 1747 343 279 Mediacom Communications Corp 6983 1690 849 231 EarthLink, Inc. 4323 1566 1004 384 tw telecom holdings, inc. 209 1549 4620 1232 Qwest Communications Company, 701 1294 10686 702 MCI Communications Services, 11492 1281 240 602 CABLE ONE, INC. 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 2708 143 10 SaudiNet, Saudi Telecom Compa 20940 2408 915 1751 Akamai International B.V. 34984 1964 323 414 TELLCOM ILETISIM HIZMETLERI A 8551 1606 376 55 Bezeq International-Ltd 6849 1152 355 21 JSC "Ukrtelecom" 12479 1151 981 86 France Telecom Espana SA 13188 1079 98 68 TOV "Bank-Inform" 8402 1051 544 15 OJSC "Vimpelcom" 31148 1035 47 41 Freenet Ltd. 9198 941 352 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 3441 538 188 Telmex Colombia S.A. 8151 2219 3318 543 Uninet S.A. de C.V. 7303 1512 940 241 Telecom Argentina S.A. 11830 1477 368 51 Instituto Costarricense de El 6503 1434 453 56 Axtel, S.A.B. de C.V. 6147 1057 377 27 Telefonica del Peru S.A.A. 3816 995 478 185 COLOMBIA TELECOMUNICACIONES S 26615 995 2325 34 Tim Celular S.A. 7738 987 1882 40 Telemar Norte Leste S.A. 28573 881 2177 159 NET Servi?os de Comunica??o S 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 1231 402 40 Link Egypt (Link.NET) 37611 646 48 2 Afrihost-Brevis Computer Serv 36903 587 295 101 Office National des Postes et 8452 559 1472 15 TE-AS 36992 509 1357 25 ETISALAT MISR 37492 394 234 67 Orange Tunisie 24835 329 210 13 Vodafone Data 29571 281 37 12 Cote d'Ivoire Telecom 2018 256 327 74 TENET (The UNINET Project) 36947 234 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 4538 5591 4192 76 China Education and Research 10620 3441 538 188 Telmex Colombia S.A. 22773 3312 2948 143 Cox Communications Inc. 7545 3269 353 203 TPG Telecom Limited 4766 3159 11145 1119 Korea Telecom 17974 2919 914 96 PT Telekomunikasi Indonesia 39891 2708 143 10 SaudiNet, Saudi Telecom Compa 9829 2481 1457 447 National Internet Backbone 20940 2408 915 1751 Akamai International B.V. 6389 2320 3687 42 BellSouth.net Inc. Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 10620 3441 3253 Telmex Colombia S.A. 22773 3312 3169 Cox Communications Inc. 7545 3269 3066 TPG Telecom Limited 17974 2919 2823 PT Telekomunikasi Indonesia 39891 2708 2698 SaudiNet, Saudi Telecom Compa 6389 2320 2278 BellSouth.net Inc. 4766 3159 2040 Korea Telecom 9829 2481 2034 National Internet Backbone 18566 2209 1933 MegaPath Corporation 4755 2096 1855 TATA Communications formerly 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 16589 UNALLOCATED 8.20.247.0/24 35838 CCANET Limited 16589 UNALLOCATED 8.26.56.0/24 35838 CCANET Limited 46473 UNALLOCATED 8.27.122.0/24 3356 Level 3 Communicatio 46473 UNALLOCATED 8.27.124.0/24 3356 Level 3 Communicatio 27205 UNALLOCATED 8.38.16.0/21 3356 Level 3 Communicatio 27205 UNALLOCATED 8.38.20.0/24 32787 Prolexic Technologie 27205 UNALLOCATED 8.38.22.0/24 32787 Prolexic Technologie Complete listing at http://thyme.rand.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 23.226.112.0/20 62788 >>UNKNOWN<< 23.249.144.0/20 40430 colo4jax, LLC 27.100.7.0/24 56096 >>UNKNOWN<< 41.73.1.0/24 37004 >>UNKNOWN<< 41.73.2.0/24 37004 >>UNKNOWN<< 41.73.3.0/24 37004 >>UNKNOWN<< 41.73.4.0/24 37004 >>UNKNOWN<< 41.73.5.0/24 37004 >>UNKNOWN<< 41.73.6.0/24 37004 >>UNKNOWN<< 41.73.7.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:13 /10:36 /11:101 /12:267 /13:512 /14:1030 /15:1758 /16:12968 /17:7585 /18:12769 /19:25869 /20:38183 /21:39943 /22:65247 /23:56880 /24:325249 /25:556 /26:598 /27:420 /28:43 /29:32 /30:14 /31:1 /32:32 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 39891 2664 2708 SaudiNet, Saudi Telecom Compa 22773 2495 3312 Cox Communications Inc. 18566 2111 2209 MegaPath Corporation 30036 1562 1747 Mediacom Communications Corp 6389 1485 2320 BellSouth.net Inc. 10620 1346 3441 Telmex Colombia S.A. 6983 1340 1690 EarthLink, Inc. 34984 1249 1964 TELLCOM ILETISIM HIZMETLERI A 11492 1183 1281 CABLE ONE, INC. 8551 1103 1606 Bezeq International-Ltd Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1585 2:730 4:21 5:2058 6:28 8:950 12:1775 13:39 14:1673 15:45 16:2 17:79 18:87 20:48 23:1462 24:1778 27:2268 31:1748 32:57 33:2 34:2 35:5 36:283 37:2258 38:1212 39:24 40:87 41:2768 42:395 43:1708 44:42 45:1799 46:2507 47:74 49:1140 50:840 51:14 52:144 54:221 55:3 56:6 57:45 58:1533 59:867 60:346 61:1810 62:1489 63:1917 64:4471 65:2144 66:4273 67:2155 68:1087 69:3249 70:1060 71:468 72:1984 74:2545 75:339 76:418 77:1371 78:1265 79:1029 80:1316 81:1350 82:931 83:688 84:820 85:1574 86:467 87:1037 88:560 89:1971 90:167 91:6040 92:867 93:2321 94:2315 95:2291 96:476 97:359 98:943 99:45 100:72 101:1026 103:10417 104:2371 105:149 106:397 107:1096 108:683 109:2291 110:1244 111:1655 112:958 113:1166 114:1045 115:1556 116:1609 117:1431 118:2025 119:1593 120:521 121:1163 122:2223 123:2011 124:1566 125:1753 128:702 129:377 130:411 131:1319 132:621 133:174 134:450 135:123 136:373 137:354 138:1712 139:248 140:374 141:464 142:655 143:893 144:628 145:162 146:856 147:688 148:1469 149:500 150:653 151:753 152:608 153:269 154:599 155:949 156:491 157:476 158:345 159:1104 160:459 161:744 162:2280 163:534 164:753 165:1044 166:312 167:1099 168:1730 169:638 170:1572 171:272 172:526 173:1697 174:731 175:722 176:1678 177:3984 178:2211 179:1151 180:2068 181:1743 182:1905 183:689 184:794 185:6207 186:3131 187:2108 188:2124 189:1754 190:7714 191:1218 192:8939 193:5726 194:4365 195:3767 196:1722 197:1089 198:5554 199:5661 200:6924 201:3724 202:10173 203:9618 204:4653 205:2714 206:3013 207:3101 208:4047 209:3791 210:3920 211:2012 212:2663 213:2189 214:843 215:72 216:5776 217:1924 218:765 219:562 220:1672 221:857 222:659 223:971 End of report From marka at isc.org Fri Apr 15 19:09:35 2016 From: marka at isc.org (Mark Andrews) Date: Sat, 16 Apr 2016 05:09:35 +1000 Subject: phone fun, was GeoIP database issues and the real world consequences In-Reply-To: Your message of "Fri, 15 Apr 2016 18:15:50 +0300." <571105A6.3040607@nvcube.net> References: <20160414153236.GA88366@ussenterprise.ufp.org> <570ED607.1070607@cox.net> <20160414002939.15867.qmail@ary.lan> <1460710177.364730809@apps.rackspace.com> <571105A6.3040607@nvcube.net> Message-ID: <20160415190936.043B346BE4B9@rock.dv.isc.org> In message <571105A6.3040607 at nvcube.net>, Nikolay Shopik writes: > On 15/04/16 17:51, John R. Levine wrote: > > Putting mobiles into a handful of non-geographic codes as they do in > > Europe wouldn't work because the US is a very large country, long > > distance costs and charges were important, and they needed to be able > > to charge more for a mobile call across the country than across the > > street. > > I would like to add that Russian mobiles in non-geographic codes and > have free incoming calls (it wasn't until 2006) and also very large > territory. But that created internal roaming prices within country. > > So if you are making call not from your home region you'll pay more also > you may pay for incoming call too (unless you pay for such option to > make your abroad incoming calls free) Australia is about the area as the US and has always had caller pays and seperate area codes for mobiles. Call costs are independent of the mobiles location unless you are OS where the callee picks up the OS component of the voice call (incoming SMS's are usually free even if you are OS, they slug you with replies however). I've also got a US SIM and had my credit run to zero dollars with the phone turned off due to the sillyness of the US system. No calls or SMS being delivered but I'm still getting charged. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From beckman at angryox.com Fri Apr 15 19:29:06 2016 From: beckman at angryox.com (Peter Beckman) Date: Fri, 15 Apr 2016 15:29:06 -0400 Subject: [lists] Re: phone fun, was GeoIP database issues and the real world consequences In-Reply-To: <20160415190936.043B346BE4B9@rock.dv.isc.org> References: <20160414153236.GA88366@ussenterprise.ufp.org> <570ED607.1070607@cox.net> <20160414002939.15867.qmail@ary.lan> <1460710177.364730809@apps.rackspace.com> <571105A6.3040607@nvcube.net> <20160415190936.043B346BE4B9@rock.dv.isc.org> Message-ID: I highly doubt that your SIM card is depleted due to the US mobile phone billing structure. Sounds like a bad contract with a carrier that is billing you for incoming calls even though you aren't on the network, or bills you a fee each month when your SIM is inactive. Don't blame a country's mobile telephone billing structure for a carrier's cell phone billing plan that seems confusing. That's like blaming the Department of Transportation for your faulty airbag. Beckman On Sat, 16 Apr 2016, Mark Andrews wrote: > I've also got a US SIM and had my credit run to zero dollars with > the phone turned off due to the sillyness of the US system. No > calls or SMS being delivered but I'm still getting charged. --------------------------------------------------------------------------- Peter Beckman Internet Guy beckman at angryox.com http://www.angryox.com/ --------------------------------------------------------------------------- From owen at delong.com Fri Apr 15 19:28:25 2016 From: owen at delong.com (Owen DeLong) Date: Fri, 15 Apr 2016 12:28:25 -0700 Subject: phone fun, was GeoIP database issues and the real world consequences In-Reply-To: <20160415190936.043B346BE4B9@rock.dv.isc.org> References: <20160414153236.GA88366@ussenterprise.ufp.org> <570ED607.1070607@cox.net> <20160414002939.15867.qmail@ary.lan> <1460710177.364730809@apps.rackspace.com> <571105A6.3040607@nvcube.net> <20160415190936.043B346BE4B9@rock.dv.isc.org> Message-ID: <3DE29471-A39E-48A7-97AC-07BD65522D00@delong.com> > On Apr 15, 2016, at 12:09, Mark Andrews wrote: > > > In message <571105A6.3040607 at nvcube.net>, Nikolay Shopik writes: >>> On 15/04/16 17:51, John R. Levine wrote: >>> Putting mobiles into a handful of non-geographic codes as they do in >>> Europe wouldn't work because the US is a very large country, long >>> distance costs and charges were important, and they needed to be able >>> to charge more for a mobile call across the country than across the >>> street. >> >> I would like to add that Russian mobiles in non-geographic codes and >> have free incoming calls (it wasn't until 2006) and also very large >> territory. But that created internal roaming prices within country. >> >> So if you are making call not from your home region you'll pay more also >> you may pay for incoming call too (unless you pay for such option to >> make your abroad incoming calls free) > > Australia is about the area as the US and has always had caller > pays and seperate area codes for mobiles. Call costs are independent > of the mobiles location unless you are OS where the callee picks > up the OS component of the voice call (incoming SMS's are usually > free even if you are OS, they slug you with replies however). AU has about the same area, but nowhere near the number/population density, so the comparison isn't particularly apt. > > I've also got a US SIM and had my credit run to zero dollars with > the phone turned off due to the sillyness of the US system. No > calls or SMS being delivered but I'm still getting charged. If you are going prepaid in the US, most likely you are transient (foreign traveler) or impoverished. As such, the companies want to collect something from you for the cost of keeping your account in the system. It's a way to avoid the costs associated with number abandonment. Usually within three months (or less) of your account going to $0, your number will be recycled and likely reissued to someone else within 60 days of being marked available. It's not so much silliness as a necessity in this market. Owen From sotnickd-nanog at ddv.com Fri Apr 15 20:18:10 2016 From: sotnickd-nanog at ddv.com (David Sotnick) Date: Fri, 15 Apr 2016 13:18:10 -0700 Subject: 10G-capable customer router recommendations? Message-ID: Hello masters of the Internet, I was recently asked to set up networking at a VIP's home where he has Comcast "Gigabit Pro" service, which is delivered on a 10G-SR MM port on a Comcast-supplied Juniper ACX-2100 router. Which customer router would you suggest for such a setup? It needs to do IPv4 NAT, DHCP, IPv4+IPv6 routing and have a decent L4 firewall (that also supports IPv6). The customer pays for "2Gb" service (Comcast caps this at 2G+10% = 2.2Gbps) and would like to get what he pays for (*cough*) by having the ability to stream two 1Gbps streams (or at least achieve > 1.0Gbps). I'm tempted to get another ACX-2100 and do a 4x1Gb LACP port-channel to the customer switch, or replace the AV-integrator-installed Cisco SG300-52P (Cisco switch with e.g. an EX-3300 with 10Gb uplinks). Thanks in advance for your suggestions. -Dave From thegameiam at yahoo.com Fri Apr 15 20:39:08 2016 From: thegameiam at yahoo.com (David Barak) Date: Fri, 15 Apr 2016 16:39:08 -0400 Subject: phone fun, was GeoIP database issues and the real world consequences In-Reply-To: <20160415190936.043B346BE4B9@rock.dv.isc.org> References: <20160414153236.GA88366@ussenterprise.ufp.org> <570ED607.1070607@cox.net> <20160414002939.15867.qmail@ary.lan> <1460710177.364730809@apps.rackspace.com> <571105A6.3040607@nvcube.net> <20160415190936.043B346BE4B9@rock.dv.isc.org> Message-ID: > On Apr 15, 2016, at 3:09 PM, Mark Andrews wrote: > > Australia is about the area as the US and has always had caller > pays and seperate area codes for mobiles. Australia has fewer people than Texas, and is more than an order of magnitude smaller than the US by population. Effects of scale apply here in terms of path dependence for solutions. David Barak Sent from mobile device, please excuse autocorrection artifacts From marka at isc.org Fri Apr 15 21:21:38 2016 From: marka at isc.org (Mark Andrews) Date: Sat, 16 Apr 2016 07:21:38 +1000 Subject: phone fun, was GeoIP database issues and the real world consequences In-Reply-To: Your message of "Fri, 15 Apr 2016 16:39:08 -0400." References: <20160414153236.GA88366@ussenterprise.ufp.org> <570ED607.1070607@cox.net> <20160414002939.15867.qmail@ary.lan> <1460710177.364730809@apps.rackspace.com> <571105A6.3040607@nvcube.net> <20160415190936.043B346BE4B9@rock.dv.isc.org> Message-ID: <20160415212138.29C9146BF6E3@rock.dv.isc.org> In message , David Barak writes : > > On Apr 15, 2016, at 3:09 PM, Mark Andrews wrote: > > > > Australia is about the area as the US and has always had caller > > pays and seperate area codes for mobiles. > > Australia has fewer people than Texas, and is more than an order of > magnitude smaller than the US by population. Effects of scale apply here > in terms of path dependence for solutions. > > David Barak > Sent from mobile device, please excuse autocorrection artifacts NA has a 10 digit scheme (3 area code - 7 local) though most of the time you end up dialing the 10 digits. Australia has a 9 digit scheme (1 area code - 8 local) Yes the area codes are huge (multi-state) and some "local" calls are sometimes long distance. In my lifetime local calls have gone from 6 digits to 7 and then 8 digits. The last change got rid of lots of area codes and expanded all the local numbers to 8 digits. This allows you to use what was a Canberra number in Sydney as they are now all in the same area code. Canberra and Sydney are a 3 hour drive apart. We are no longer in a age where we need to route calls on a digit by digit basis. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From jfmezei_nanog at vaxination.ca Fri Apr 15 21:30:08 2016 From: jfmezei_nanog at vaxination.ca (Jean-Francois Mezei) Date: Fri, 15 Apr 2016 17:30:08 -0400 Subject: phone fun, was GeoIP database issues and the real world consequences In-Reply-To: <20160415212138.29C9146BF6E3@rock.dv.isc.org> References: <20160414153236.GA88366@ussenterprise.ufp.org> <570ED607.1070607@cox.net> <20160414002939.15867.qmail@ary.lan> <1460710177.364730809@apps.rackspace.com> <571105A6.3040607@nvcube.net> <20160415190936.043B346BE4B9@rock.dv.isc.org> <20160415212138.29C9146BF6E3@rock.dv.isc.org> Message-ID: <57115D60.3060400@vaxination.ca> On 2016-04-15 17:21, Mark Andrews wrote: > Yes the area codes are huge (multi-state) and some "local" calls > are sometimes long distance. Until early 1990s, the 819 area code spanned from the US/canada Border in Qu?bec, around Montr?al (514), included the Laurentians and just about everything north all the way to Grise Fiord on Ellesmere Island north of the magnetic north pole. Some exchanges reacheable only via satellite (what is now Nunavut) and some are near urban centres. And I reemember when one could dial 4 digits to call anyone in the cottage village (omitting the 819-687 prefix). When bell Canada bought northwestel, it transfered what is now Nunavut territory to NWTel which moved the 819 telephone numbers to its 867 area code which now spans from the Yukon/Alaska border to the Canada/Greenland border. From johnl at iecc.com Fri Apr 15 21:48:18 2016 From: johnl at iecc.com (John Levine) Date: 15 Apr 2016 21:48:18 -0000 Subject: phone fun, was GeoIP database issues and the real world consequences In-Reply-To: <20160415212138.29C9146BF6E3@rock.dv.isc.org> Message-ID: <20160415214818.6677.qmail@ary.lan> >NA has a 10 digit scheme (3 area code - 7 local) though most of the >time you end up dialing the 10 digits. > >Australia has a 9 digit scheme (1 area code - 8 local) ... North America uses en bloc signalling, Australia uses CCITT style compelled signalling. That's why you have variable length numbers and the split between area code and local number can change. >We are no longer in a age where we need to route calls on a digit >by digit basis. Right. North America left that age in 1947, the rest of the world only caught up in the 2000s. R's, John From aaron at wholesaleinternet.net Fri Apr 15 21:52:21 2016 From: aaron at wholesaleinternet.net (Aaron) Date: Fri, 15 Apr 2016 16:52:21 -0500 Subject: 10G-capable customer router recommendations? In-Reply-To: References: Message-ID: <57116295.6080607@wholesaleinternet.net> Not a lot of 10G capable CPEs out there. For our 10G residential customers we install Brocade ICXs. Aaron On 4/15/2016 3:18 PM, David Sotnick wrote: > Hello masters of the Internet, > > I was recently asked to set up networking at a VIP's home where he has > Comcast "Gigabit Pro" service, which is delivered on a 10G-SR MM port on a > Comcast-supplied Juniper ACX-2100 router. > > Which customer router would you suggest for such a setup? It needs to do > IPv4 NAT, DHCP, IPv4+IPv6 routing and have a decent L4 firewall (that also > supports IPv6). > > The customer pays for "2Gb" service (Comcast caps this at 2G+10% = 2.2Gbps) > and would like to get what he pays for (*cough*) by having the ability to > stream two 1Gbps streams (or at least achieve > 1.0Gbps). > > I'm tempted to get another ACX-2100 and do a 4x1Gb LACP port-channel to the > customer switch, or replace the AV-integrator-installed Cisco SG300-52P > (Cisco switch with e.g. an EX-3300 with 10Gb uplinks). > > Thanks in advance for your suggestions. > > -Dave > -- ================================================================ Aaron Wendel Chief Technical Officer Wholesale Internet, Inc. (AS 32097) (816)550-9030 http://www.wholesaleinternet.com ================================================================ From mike.lyon at gmail.com Fri Apr 15 22:01:16 2016 From: mike.lyon at gmail.com (mike.lyon at gmail.com) Date: Fri, 15 Apr 2016 15:01:16 -0700 Subject: 10G-capable customer router recommendations? In-Reply-To: <57116295.6080607@wholesaleinternet.net> References: <57116295.6080607@wholesaleinternet.net> Message-ID: Check out the Mikrotik Cloud Core routers, they make them with SFP+ support now. I have one of them with 10g deployed right now. -Mike > On Apr 15, 2016, at 14:52, Aaron wrote: > > Not a lot of 10G capable CPEs out there. For our 10G residential customers we install Brocade ICXs. > > Aaron > > >> On 4/15/2016 3:18 PM, David Sotnick wrote: >> Hello masters of the Internet, >> >> I was recently asked to set up networking at a VIP's home where he has >> Comcast "Gigabit Pro" service, which is delivered on a 10G-SR MM port on a >> Comcast-supplied Juniper ACX-2100 router. >> >> Which customer router would you suggest for such a setup? It needs to do >> IPv4 NAT, DHCP, IPv4+IPv6 routing and have a decent L4 firewall (that also >> supports IPv6). >> >> The customer pays for "2Gb" service (Comcast caps this at 2G+10% = 2.2Gbps) >> and would like to get what he pays for (*cough*) by having the ability to >> stream two 1Gbps streams (or at least achieve > 1.0Gbps). >> >> I'm tempted to get another ACX-2100 and do a 4x1Gb LACP port-channel to the >> customer switch, or replace the AV-integrator-installed Cisco SG300-52P >> (Cisco switch with e.g. an EX-3300 with 10Gb uplinks). >> >> Thanks in advance for your suggestions. >> >> -Dave > > -- > ================================================================ > Aaron Wendel > Chief Technical Officer > Wholesale Internet, Inc. (AS 32097) > (816)550-9030 > http://www.wholesaleinternet.com > ================================================================ > From josh at kyneticwifi.com Fri Apr 15 22:04:03 2016 From: josh at kyneticwifi.com (Josh Reynolds) Date: Fri, 15 Apr 2016 17:04:03 -0500 Subject: 10G-capable customer router recommendations? In-Reply-To: References: <57116295.6080607@wholesaleinternet.net> Message-ID: Can't do more than 1Gbps per flow. Not suitable for this application. On Apr 15, 2016 5:03 PM, wrote: > Check out the Mikrotik Cloud Core routers, they make them with SFP+ > support now. I have one of them with 10g deployed right now. > > -Mike > > > On Apr 15, 2016, at 14:52, Aaron wrote: > > > > Not a lot of 10G capable CPEs out there. For our 10G residential > customers we install Brocade ICXs. > > > > Aaron > > > > > >> On 4/15/2016 3:18 PM, David Sotnick wrote: > >> Hello masters of the Internet, > >> > >> I was recently asked to set up networking at a VIP's home where he has > >> Comcast "Gigabit Pro" service, which is delivered on a 10G-SR MM port > on a > >> Comcast-supplied Juniper ACX-2100 router. > >> > >> Which customer router would you suggest for such a setup? It needs to do > >> IPv4 NAT, DHCP, IPv4+IPv6 routing and have a decent L4 firewall (that > also > >> supports IPv6). > >> > >> The customer pays for "2Gb" service (Comcast caps this at 2G+10% = > 2.2Gbps) > >> and would like to get what he pays for (*cough*) by having the ability > to > >> stream two 1Gbps streams (or at least achieve > 1.0Gbps). > >> > >> I'm tempted to get another ACX-2100 and do a 4x1Gb LACP port-channel to > the > >> customer switch, or replace the AV-integrator-installed Cisco SG300-52P > >> (Cisco switch with e.g. an EX-3300 with 10Gb uplinks). > >> > >> Thanks in advance for your suggestions. > >> > >> -Dave > > > > -- > > ================================================================ > > Aaron Wendel > > Chief Technical Officer > > Wholesale Internet, Inc. (AS 32097) > > (816)550-9030 > > http://www.wholesaleinternet.com > > ================================================================ > > > From fhr at fhrnet.eu Fri Apr 15 22:06:00 2016 From: fhr at fhrnet.eu (Filip Hruska) Date: Sat, 16 Apr 2016 00:06:00 +0200 Subject: 10G-capable customer router recommendations? In-Reply-To: References: <57116295.6080607@wholesaleinternet.net> Message-ID: <571165C8.7050000@fhrnet.eu> Hi, I would also vote for Mikrotik products; IMHO this looks perfect for this situation. http://routerboard.com/CCR1009-8G-1S-1SplusPC On 04/16/2016 12:01 AM, mike.lyon at gmail.com wrote: > Check out the Mikrotik Cloud Core routers, they make them with SFP+ support now. I have one of them with 10g deployed right now. > > -Mike > >> On Apr 15, 2016, at 14:52, Aaron wrote: >> >> Not a lot of 10G capable CPEs out there. For our 10G residential customers we install Brocade ICXs. >> >> Aaron >> >> >>> On 4/15/2016 3:18 PM, David Sotnick wrote: >>> Hello masters of the Internet, >>> >>> I was recently asked to set up networking at a VIP's home where he has >>> Comcast "Gigabit Pro" service, which is delivered on a 10G-SR MM port on a >>> Comcast-supplied Juniper ACX-2100 router. >>> >>> Which customer router would you suggest for such a setup? It needs to do >>> IPv4 NAT, DHCP, IPv4+IPv6 routing and have a decent L4 firewall (that also >>> supports IPv6). >>> >>> The customer pays for "2Gb" service (Comcast caps this at 2G+10% = 2.2Gbps) >>> and would like to get what he pays for (*cough*) by having the ability to >>> stream two 1Gbps streams (or at least achieve > 1.0Gbps). >>> >>> I'm tempted to get another ACX-2100 and do a 4x1Gb LACP port-channel to the >>> customer switch, or replace the AV-integrator-installed Cisco SG300-52P >>> (Cisco switch with e.g. an EX-3300 with 10Gb uplinks). >>> >>> Thanks in advance for your suggestions. >>> >>> -Dave >> >> -- >> ================================================================ >> Aaron Wendel >> Chief Technical Officer >> Wholesale Internet, Inc. (AS 32097) >> (816)550-9030 >> http://www.wholesaleinternet.com >> ================================================================ >> > From savage at savage.za.org Fri Apr 15 22:11:54 2016 From: savage at savage.za.org (Chris Knipe) Date: Sat, 16 Apr 2016 00:11:54 +0200 Subject: 10G-capable customer router recommendations? In-Reply-To: References: <57116295.6080607@wholesaleinternet.net> Message-ID: On Sat, Apr 16, 2016 at 12:04 AM, Josh Reynolds wrote: > Can't do more than 1Gbps per flow. Not suitable for this application. > On Apr 15, 2016 5:03 PM, wrote: > > > Check out the Mikrotik Cloud Core routers, they make them with SFP+ > > support now. I have one of them with 10g deployed right now. > > > > -Mike > Also it falls pretty much flat on it's face the moment you do anything useful in terms of firewalling / NATing. From josh at kyneticwifi.com Fri Apr 15 22:12:35 2016 From: josh at kyneticwifi.com (Josh Reynolds) Date: Fri, 15 Apr 2016 17:12:35 -0500 Subject: 10G-capable customer router recommendations? In-Reply-To: <571165C8.7050000@fhrnet.eu> References: <57116295.6080607@wholesaleinternet.net> <571165C8.7050000@fhrnet.eu> Message-ID: As much as I enjoy Mikrotik products and respect my friends and peers who use them, until ROS 7.x the CCR is a "gimped" product. On Apr 15, 2016 5:10 PM, "Filip Hruska" wrote: > Hi, > > I would also vote for Mikrotik products; IMHO this looks perfect for this > situation. > > http://routerboard.com/CCR1009-8G-1S-1SplusPC > > > > On 04/16/2016 12:01 AM, mike.lyon at gmail.com wrote: > >> Check out the Mikrotik Cloud Core routers, they make them with SFP+ >> support now. I have one of them with 10g deployed right now. >> >> -Mike >> >> On Apr 15, 2016, at 14:52, Aaron wrote: >>> >>> Not a lot of 10G capable CPEs out there. For our 10G residential >>> customers we install Brocade ICXs. >>> >>> Aaron >>> >>> >>> On 4/15/2016 3:18 PM, David Sotnick wrote: >>>> Hello masters of the Internet, >>>> >>>> I was recently asked to set up networking at a VIP's home where he has >>>> Comcast "Gigabit Pro" service, which is delivered on a 10G-SR MM port >>>> on a >>>> Comcast-supplied Juniper ACX-2100 router. >>>> >>>> Which customer router would you suggest for such a setup? It needs to do >>>> IPv4 NAT, DHCP, IPv4+IPv6 routing and have a decent L4 firewall (that >>>> also >>>> supports IPv6). >>>> >>>> The customer pays for "2Gb" service (Comcast caps this at 2G+10% = >>>> 2.2Gbps) >>>> and would like to get what he pays for (*cough*) by having the ability >>>> to >>>> stream two 1Gbps streams (or at least achieve > 1.0Gbps). >>>> >>>> I'm tempted to get another ACX-2100 and do a 4x1Gb LACP port-channel to >>>> the >>>> customer switch, or replace the AV-integrator-installed Cisco SG300-52P >>>> (Cisco switch with e.g. an EX-3300 with 10Gb uplinks). >>>> >>>> Thanks in advance for your suggestions. >>>> >>>> -Dave >>>> >>> >>> -- >>> ================================================================ >>> Aaron Wendel >>> Chief Technical Officer >>> Wholesale Internet, Inc. (AS 32097) >>> (816)550-9030 >>> http://www.wholesaleinternet.com >>> ================================================================ >>> >>> >> From mike.lyon at gmail.com Fri Apr 15 22:19:21 2016 From: mike.lyon at gmail.com (Mike Lyon) Date: Fri, 15 Apr 2016 15:19:21 -0700 Subject: 10G-capable customer router recommendations? In-Reply-To: References: <57116295.6080607@wholesaleinternet.net> Message-ID: Welp! Color me wrong... -Mike On Fri, Apr 15, 2016 at 3:04 PM, Josh Reynolds wrote: > Can't do more than 1Gbps per flow. Not suitable for this application. > On Apr 15, 2016 5:03 PM, wrote: > >> Check out the Mikrotik Cloud Core routers, they make them with SFP+ >> support now. I have one of them with 10g deployed right now. >> >> -Mike >> >> > On Apr 15, 2016, at 14:52, Aaron wrote: >> > >> > Not a lot of 10G capable CPEs out there. For our 10G residential >> customers we install Brocade ICXs. >> > >> > Aaron >> > >> > >> >> On 4/15/2016 3:18 PM, David Sotnick wrote: >> >> Hello masters of the Internet, >> >> >> >> I was recently asked to set up networking at a VIP's home where he has >> >> Comcast "Gigabit Pro" service, which is delivered on a 10G-SR MM port >> on a >> >> Comcast-supplied Juniper ACX-2100 router. >> >> >> >> Which customer router would you suggest for such a setup? It needs to >> do >> >> IPv4 NAT, DHCP, IPv4+IPv6 routing and have a decent L4 firewall (that >> also >> >> supports IPv6). >> >> >> >> The customer pays for "2Gb" service (Comcast caps this at 2G+10% = >> 2.2Gbps) >> >> and would like to get what he pays for (*cough*) by having the ability >> to >> >> stream two 1Gbps streams (or at least achieve > 1.0Gbps). >> >> >> >> I'm tempted to get another ACX-2100 and do a 4x1Gb LACP port-channel >> to the >> >> customer switch, or replace the AV-integrator-installed Cisco SG300-52P >> >> (Cisco switch with e.g. an EX-3300 with 10Gb uplinks). >> >> >> >> Thanks in advance for your suggestions. >> >> >> >> -Dave >> > >> > -- >> > ================================================================ >> > Aaron Wendel >> > Chief Technical Officer >> > Wholesale Internet, Inc. (AS 32097) >> > (816)550-9030 >> > http://www.wholesaleinternet.com >> > ================================================================ >> > >> > -- Mike Lyon 408-621-4826 mike.lyon at gmail.com http://www.linkedin.com/in/mlyon From sotnickd-nanog at ddv.com Fri Apr 15 22:59:29 2016 From: sotnickd-nanog at ddv.com (David Sotnick) Date: Fri, 15 Apr 2016 15:59:29 -0700 Subject: 10G-capable customer router recommendations? In-Reply-To: <57116295.6080607@wholesaleinternet.net> References: <57116295.6080607@wholesaleinternet.net> Message-ID: Thanks Aaron. Unless something has changed recently, I don't think the Brocade ICX series does NAT either. On Fri, Apr 15, 2016 at 2:52 PM, Aaron wrote: > Not a lot of 10G capable CPEs out there. For our 10G residential > customers we install Brocade ICXs. > > Aaron > > -- > ================================================================ > Aaron Wendel > Chief Technical Officer > Wholesale Internet, Inc. (AS 32097) > (816)550-9030 > http://www.wholesaleinternet.com > ================================================================ > > From tony at wicks.co.nz Fri Apr 15 23:21:25 2016 From: tony at wicks.co.nz (Tony Wicks) Date: Sat, 16 Apr 2016 11:21:25 +1200 Subject: 10G-capable customer router recommendations? In-Reply-To: References: <57116295.6080607@wholesaleinternet.net> Message-ID: <005b01d1976d$8885e200$9991a600$@wicks.co.nz> Hmm, the chances of getting a single flow of more than 1gig to/from the "internet" is close to zero in a CPE situation. If the Connection is a service provider or similar sure, this limitation may well apply, but a home user (however high end), nope I just can't see it. If you need something capable of a single stream over 1G with 10G interfaces then really cost is going to have to be no object. If this is the case then something like a 600D will do the job - http://www.fortinet.com/sites/default/files/productdatasheets/FortiGate-600D.pdf Add any 10G switch you like off the second SFP+ port if you need 10G CPE, it's not likely to need to be an expensive one (EX3300?) I've used the Mikrotik CCR's as high end CPE (with 10G uplink) very successfully as they offer excellent price/performance, but if that's no object then there are plenty of options. > Can't do more than 1Gbps per flow. Not suitable for this application. > On Apr 15, 2016 5:03 PM, wrote: From josh at kyneticwifi.com Fri Apr 15 23:27:56 2016 From: josh at kyneticwifi.com (Josh Reynolds) Date: Fri, 15 Apr 2016 18:27:56 -0500 Subject: 10G-capable customer router recommendations? In-Reply-To: <005b01d1976d$8885e200$9991a600$@wicks.co.nz> References: <57116295.6080607@wholesaleinternet.net> <005b01d1976d$8885e200$9991a600$@wicks.co.nz> Message-ID: Different philosophy - strings attached. When I sell a service, either residential or business or DIA, the terms are clearly stated. If I were selling a multi-hundred dollar a month service, the CPE cost is minimal. If I don't offer a service that is at least *capable* of providing what I'm selling, then my competition will. I prefer to not hand out competitive advantages. On Apr 15, 2016 6:24 PM, "Tony Wicks" wrote: > Hmm, the chances of getting a single flow of more than 1gig to/from the > "internet" is close to zero in a CPE situation. If the Connection is a > service provider or similar sure, this limitation may well apply, but a > home user (however high end), nope I just can't see it. If you need > something capable of a single stream over 1G with 10G interfaces then > really cost is going to have to be no object. If this is the case then > something like a 600D will do the job - > > > http://www.fortinet.com/sites/default/files/productdatasheets/FortiGate-600D.pdf > Add any 10G switch you like off the second SFP+ port if you need 10G CPE, > it's not likely to need to be an expensive one (EX3300?) > > I've used the Mikrotik CCR's as high end CPE (with 10G uplink) very > successfully as they offer excellent price/performance, but if that's no > object then there are plenty of options. > > > > > > > > Can't do more than 1Gbps per flow. Not suitable for this application. > > On Apr 15, 2016 5:03 PM, wrote: > > From michael at supermathie.net Fri Apr 15 23:45:39 2016 From: michael at supermathie.net (Michael Brown) Date: Fri, 15 Apr 2016 19:45:39 -0400 Subject: 10G-capable customer router recommendations? In-Reply-To: References: Message-ID: <20160415234539.7147590.32900.20859@supermathie.net> Not *exactly* what you're asking for, but a Lanner appliance (?http://www.lannerinc.com/products/network-appliances/x86-rackmount-network-appliances/nca-5210) might suit your needs. M. ? Original Message ? From: David Sotnick Sent: Friday, April 15, 2016 16:19 To: NANOG Subject: 10G-capable customer router recommendations? Hello masters of the Internet, I was recently asked to set up networking at a VIP's home where he has Comcast "Gigabit Pro" service, which is delivered on a 10G-SR MM port on a Comcast-supplied Juniper ACX-2100 router. Which customer router would you suggest for such a setup? It needs to do IPv4 NAT, DHCP, IPv4+IPv6 routing and have a decent L4 firewall (that also supports IPv6). The customer pays for "2Gb" service (Comcast caps this at 2G+10% = 2.2Gbps) and would like to get what he pays for (*cough*) by having the ability to stream two 1Gbps streams (or at least achieve > 1.0Gbps). I'm tempted to get another ACX-2100 and do a 4x1Gb LACP port-channel to the customer switch, or replace the AV-integrator-installed Cisco SG300-52P (Cisco switch with e.g. an EX-3300 with 10Gb uplinks). Thanks in advance for your suggestions. -Dave From josh at kyneticwifi.com Fri Apr 15 23:53:20 2016 From: josh at kyneticwifi.com (Josh Reynolds) Date: Fri, 15 Apr 2016 18:53:20 -0500 Subject: 10G-capable customer router recommendations? In-Reply-To: <20160415234539.7147590.32900.20859@supermathie.net> References: <20160415234539.7147590.32900.20859@supermathie.net> Message-ID: Would still need a Chelsio / Mellanox etc card, and even then you're not going to hit line rate if you have NAT or any traffic shaping enabled at all. Maybe with DPDK/netmap/pf_ring, but that would be some pretty custom work. On Apr 15, 2016 6:47 PM, "Michael Brown" wrote: > Not *exactly* what you're asking for, but a Lanner appliance (? > http://www.lannerinc.com/products/network-appliances/x86-rackmount-network-appliances/nca-5210) > might suit your needs. > > M. > > Original Message > From: David Sotnick > Sent: Friday, April 15, 2016 16:19 > To: NANOG > Subject: 10G-capable customer router recommendations? > > Hello masters of the Internet, > > I was recently asked to set up networking at a VIP's home where he has > Comcast "Gigabit Pro" service, which is delivered on a 10G-SR MM port on a > Comcast-supplied Juniper ACX-2100 router. > > Which customer router would you suggest for such a setup? It needs to do > IPv4 NAT, DHCP, IPv4+IPv6 routing and have a decent L4 firewall (that also > supports IPv6). > > The customer pays for "2Gb" service (Comcast caps this at 2G+10% = 2.2Gbps) > and would like to get what he pays for (*cough*) by having the ability to > stream two 1Gbps streams (or at least achieve > 1.0Gbps). > > I'm tempted to get another ACX-2100 and do a 4x1Gb LACP port-channel to the > customer switch, or replace the AV-integrator-installed Cisco SG300-52P > (Cisco switch with e.g. an EX-3300 with 10Gb uplinks). > > Thanks in advance for your suggestions. > > -Dave > From math at sizone.org Sat Apr 16 00:24:56 2016 From: math at sizone.org (Ken Chase) Date: Fri, 15 Apr 2016 20:24:56 -0400 Subject: 10G-capable customer router recommendations? In-Reply-To: <20160415234539.7147590.32900.20859@supermathie.net> References: <20160415234539.7147590.32900.20859@supermathie.net> Message-ID: <20160416002456.GA22567@sizone.org> Does that lanner even do SFP+? Dont see it listed in the specs. Looks like 4210 has 2x SFP+, though their 'performance' level products look more in line with 'useful'. http://www.lannerinc.com/products/x86-network-appliances/x86-rackmount-appliances/fw-8877 As for the microtics, wonky user interface, so very unciscolike (i guess thats my problem - but the GUI thing feels like a toy), but for their midrange models I found their bgp convergence times pretty poor on their low end cpus... What do you put on the lanner? OpenBGPd? Quagga? Also looking for a 10G solution here, low power (than a full ASR stack..) is my goal for 5-6 full bgp feeds. /kc On Fri, Apr 15, 2016 at 07:45:39PM -0400, Michael Brown said: >Not *exactly* what you're asking for, but a Lanner appliance (???http://www.lannerinc.com/products/network-appliances/x86-rackmount-network-appliances/nca-5210) might suit your needs. > >M. > >?? Original Message ?? >From: David Sotnick >Sent: Friday, April 15, 2016 16:19 >To: NANOG >Subject: 10G-capable customer router recommendations? > >Hello masters of the Internet, > >I was recently asked to set up networking at a VIP's home where he has >Comcast "Gigabit Pro" service, which is delivered on a 10G-SR MM port on a >Comcast-supplied Juniper ACX-2100 router. > >Which customer router would you suggest for such a setup? It needs to do >IPv4 NAT, DHCP, IPv4+IPv6 routing and have a decent L4 firewall (that also >supports IPv6). > >The customer pays for "2Gb" service (Comcast caps this at 2G+10% = 2.2Gbps) >and would like to get what he pays for (*cough*) by having the ability to >stream two 1Gbps streams (or at least achieve > 1.0Gbps). > >I'm tempted to get another ACX-2100 and do a 4x1Gb LACP port-channel to the >customer switch, or replace the AV-integrator-installed Cisco SG300-52P >(Cisco switch with e.g. an EX-3300 with 10Gb uplinks). > >Thanks in advance for your suggestions. > >-Dave Ken Chase - math at sizone.org From faisal at snappytelecom.net Sat Apr 16 01:10:33 2016 From: faisal at snappytelecom.net (Faisal Imtiaz) Date: Sat, 16 Apr 2016 01:10:33 +0000 (GMT) Subject: 10G-capable customer router recommendations? In-Reply-To: <20160416002456.GA22567@sizone.org> References: <20160415234539.7147590.32900.20859@supermathie.net> <20160416002456.GA22567@sizone.org> Message-ID: <1995748146.135226.1460769033787.JavaMail.zimbra@snappytelecom.net> Hope you all realize a few minor details:- Mikrotik is a ROS (Router Operating System), based on linux. Mikrotik also makes hardware called RouterBoards. Having said that... Mikrotik ROS runs on X86 platforms (such as Lanner or axiomtek) Similarly you can also run linux on the Routerboard platforms. Having said that... Lanner & Axiomtek etc x86 appliances have one pcie slot, where you can install the NIC of your choice. Dual 10g SFP+ Intel Card or 2/4/6 port Hotlava Card, or Chelsio etc. You can mix and match to suite your needs. Don't like RouterBoard or CCR's, no problem you can run MT ROS on an X86 Platform of your choice. These days you can even run it on a VM solution... Don't like MT ROS, no problem feel free to run your choice of OS, and routing daemons. Want a high performance x86 Firewall... inexpensive.. look at Server-U, ask them about their custom solution with Chelsio Cards. Don't like any of the above, feel free to by a Box with a Name on it (Brocade, Cisco, Juniper etc etc).. Yes, each platform has it's advantages, and it's short comings, and no one solution fits all needs. (Want to tow your boat, get a Hummer, want to go fast, get a ferrari.... don't try to tow you boat with a ferrari, or race in the streets with a hummer !) :) Regards Faisal Imtiaz Snappy Internet & Telecom ----- Original Message ----- > From: "Ken Chase" > To: "nanog list" > Sent: Friday, April 15, 2016 8:24:56 PM > Subject: Re: 10G-capable customer router recommendations? > Does that lanner even do SFP+? Dont see it listed in the specs. Looks like 4210 > has > 2x SFP+, though their 'performance' level products look more in line with > 'useful'. > > http://www.lannerinc.com/products/x86-network-appliances/x86-rackmount-appliances/fw-8877 > > As for the microtics, wonky user interface, so very unciscolike (i guess thats > my problem - but the GUI thing feels like a toy), but for their midrange models > I found > their bgp convergence times pretty poor on their low end cpus... > > What do you put on the lanner? OpenBGPd? Quagga? Also looking for a 10G solution > here, low power (than a full ASR stack..) is my goal for 5-6 full bgp feeds. > > /kc > > > On Fri, Apr 15, 2016 at 07:45:39PM -0400, Michael Brown said: > >Not *exactly* what you're asking for, but a Lanner appliance > >(???http://www.lannerinc.com/products/network-appliances/x86-rackmount-network-appliances/nca-5210) > >might suit your needs. > > > >M. > > > >?? Original Message ?? > >From: David Sotnick > >Sent: Friday, April 15, 2016 16:19 > >To: NANOG > >Subject: 10G-capable customer router recommendations? > > > >Hello masters of the Internet, > > > >I was recently asked to set up networking at a VIP's home where he has > >Comcast "Gigabit Pro" service, which is delivered on a 10G-SR MM port on a > >Comcast-supplied Juniper ACX-2100 router. > > > >Which customer router would you suggest for such a setup? It needs to do > >IPv4 NAT, DHCP, IPv4+IPv6 routing and have a decent L4 firewall (that also > >supports IPv6). > > > >The customer pays for "2Gb" service (Comcast caps this at 2G+10% = 2.2Gbps) > >and would like to get what he pays for (*cough*) by having the ability to > >stream two 1Gbps streams (or at least achieve > 1.0Gbps). > > > >I'm tempted to get another ACX-2100 and do a 4x1Gb LACP port-channel to the > >customer switch, or replace the AV-integrator-installed Cisco SG300-52P > >(Cisco switch with e.g. an EX-3300 with 10Gb uplinks). > > > >Thanks in advance for your suggestions. > > > >-Dave > > Ken Chase - math at sizone.org From nanog at ics-il.net Sat Apr 16 01:27:01 2016 From: nanog at ics-il.net (Mike Hammett) Date: Fri, 15 Apr 2016 20:27:01 -0500 (CDT) Subject: 10G-capable customer router recommendations? In-Reply-To: Message-ID: <1321559835.3368.1460770018325.JavaMail.mhammett@ThunderFuck> The CCRs' primary weaknesses are full tables and 1 gigabit cap per flow. Neither is likely to be an issue for this residential use case. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest Internet Exchange http://www.midwest-ix.com ----- Original Message ----- From: "Josh Reynolds" To: "Filip Hruska" Cc: "NANOG" Sent: Friday, April 15, 2016 5:12:35 PM Subject: Re: 10G-capable customer router recommendations? As much as I enjoy Mikrotik products and respect my friends and peers who use them, until ROS 7.x the CCR is a "gimped" product. On Apr 15, 2016 5:10 PM, "Filip Hruska" wrote: > Hi, > > I would also vote for Mikrotik products; IMHO this looks perfect for this > situation. > > http://routerboard.com/CCR1009-8G-1S-1SplusPC > > > > On 04/16/2016 12:01 AM, mike.lyon at gmail.com wrote: > >> Check out the Mikrotik Cloud Core routers, they make them with SFP+ >> support now. I have one of them with 10g deployed right now. >> >> -Mike >> >> On Apr 15, 2016, at 14:52, Aaron wrote: >>> >>> Not a lot of 10G capable CPEs out there. For our 10G residential >>> customers we install Brocade ICXs. >>> >>> Aaron >>> >>> >>> On 4/15/2016 3:18 PM, David Sotnick wrote: >>>> Hello masters of the Internet, >>>> >>>> I was recently asked to set up networking at a VIP's home where he has >>>> Comcast "Gigabit Pro" service, which is delivered on a 10G-SR MM port >>>> on a >>>> Comcast-supplied Juniper ACX-2100 router. >>>> >>>> Which customer router would you suggest for such a setup? It needs to do >>>> IPv4 NAT, DHCP, IPv4+IPv6 routing and have a decent L4 firewall (that >>>> also >>>> supports IPv6). >>>> >>>> The customer pays for "2Gb" service (Comcast caps this at 2G+10% = >>>> 2.2Gbps) >>>> and would like to get what he pays for (*cough*) by having the ability >>>> to >>>> stream two 1Gbps streams (or at least achieve > 1.0Gbps). >>>> >>>> I'm tempted to get another ACX-2100 and do a 4x1Gb LACP port-channel to >>>> the >>>> customer switch, or replace the AV-integrator-installed Cisco SG300-52P >>>> (Cisco switch with e.g. an EX-3300 with 10Gb uplinks). >>>> >>>> Thanks in advance for your suggestions. >>>> >>>> -Dave >>>> >>> >>> -- >>> ================================================================ >>> Aaron Wendel >>> Chief Technical Officer >>> Wholesale Internet, Inc. (AS 32097) >>> (816)550-9030 >>> http://www.wholesaleinternet.com >>> ================================================================ >>> >>> >> From josh at kyneticwifi.com Sat Apr 16 01:32:17 2016 From: josh at kyneticwifi.com (Josh Reynolds) Date: Fri, 15 Apr 2016 20:32:17 -0500 Subject: 10G-capable customer router recommendations? In-Reply-To: <1321559835.3368.1460770018325.JavaMail.mhammett@ThunderFuck> References: <1321559835.3368.1460770018325.JavaMail.mhammett@ThunderFuck> Message-ID: If I were sold a $400/mo+ service that had a limitation like that, I would be very unhappy. To each their own. On Apr 15, 2016 8:29 PM, "Mike Hammett" wrote: > The CCRs' primary weaknesses are full tables and 1 gigabit cap per flow. > Neither is likely to be an issue for this residential use case. > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > > > Midwest Internet Exchange > http://www.midwest-ix.com > > > ----- Original Message ----- > > From: "Josh Reynolds" > To: "Filip Hruska" > Cc: "NANOG" > Sent: Friday, April 15, 2016 5:12:35 PM > Subject: Re: 10G-capable customer router recommendations? > > As much as I enjoy Mikrotik products and respect my friends and peers who > use them, until ROS 7.x the CCR is a "gimped" product. > On Apr 15, 2016 5:10 PM, "Filip Hruska" wrote: > > > Hi, > > > > I would also vote for Mikrotik products; IMHO this looks perfect for this > > situation. > > > > http://routerboard.com/CCR1009-8G-1S-1SplusPC > > > > > > > > On 04/16/2016 12:01 AM, mike.lyon at gmail.com wrote: > > > >> Check out the Mikrotik Cloud Core routers, they make them with SFP+ > >> support now. I have one of them with 10g deployed right now. > >> > >> -Mike > >> > >> On Apr 15, 2016, at 14:52, Aaron wrote: > >>> > >>> Not a lot of 10G capable CPEs out there. For our 10G residential > >>> customers we install Brocade ICXs. > >>> > >>> Aaron > >>> > >>> > >>> On 4/15/2016 3:18 PM, David Sotnick wrote: > >>>> Hello masters of the Internet, > >>>> > >>>> I was recently asked to set up networking at a VIP's home where he has > >>>> Comcast "Gigabit Pro" service, which is delivered on a 10G-SR MM port > >>>> on a > >>>> Comcast-supplied Juniper ACX-2100 router. > >>>> > >>>> Which customer router would you suggest for such a setup? It needs to > do > >>>> IPv4 NAT, DHCP, IPv4+IPv6 routing and have a decent L4 firewall (that > >>>> also > >>>> supports IPv6). > >>>> > >>>> The customer pays for "2Gb" service (Comcast caps this at 2G+10% = > >>>> 2.2Gbps) > >>>> and would like to get what he pays for (*cough*) by having the ability > >>>> to > >>>> stream two 1Gbps streams (or at least achieve > 1.0Gbps). > >>>> > >>>> I'm tempted to get another ACX-2100 and do a 4x1Gb LACP port-channel > to > >>>> the > >>>> customer switch, or replace the AV-integrator-installed Cisco > SG300-52P > >>>> (Cisco switch with e.g. an EX-3300 with 10Gb uplinks). > >>>> > >>>> Thanks in advance for your suggestions. > >>>> > >>>> -Dave > >>>> > >>> > >>> -- > >>> ================================================================ > >>> Aaron Wendel > >>> Chief Technical Officer > >>> Wholesale Internet, Inc. (AS 32097) > >>> (816)550-9030 > >>> http://www.wholesaleinternet.com > >>> ================================================================ > >>> > >>> > >> > > From nanog at ics-il.net Sat Apr 16 01:33:26 2016 From: nanog at ics-il.net (Mike Hammett) Date: Fri, 15 Apr 2016 20:33:26 -0500 (CDT) Subject: 10G-capable customer router recommendations? In-Reply-To: <20160416002456.GA22567@sizone.org> Message-ID: <1620700980.3371.1460770403364.JavaMail.mhammett@ThunderFuck> Conversely, the UI is Mikrotik's big draw. :-) Being or not being like CIsco has zero bearing on me. Assuming the commands do what they say they'll do, any platform with tab complete is fine. :-) ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest Internet Exchange http://www.midwest-ix.com ----- Original Message ----- From: "Ken Chase" To: "NANOG" Sent: Friday, April 15, 2016 7:24:56 PM Subject: Re: 10G-capable customer router recommendations? Does that lanner even do SFP+? Dont see it listed in the specs. Looks like 4210 has 2x SFP+, though their 'performance' level products look more in line with 'useful'. http://www.lannerinc.com/products/x86-network-appliances/x86-rackmount-appliances/fw-8877 As for the microtics, wonky user interface, so very unciscolike (i guess thats my problem - but the GUI thing feels like a toy), but for their midrange models I found their bgp convergence times pretty poor on their low end cpus... What do you put on the lanner? OpenBGPd? Quagga? Also looking for a 10G solution here, low power (than a full ASR stack..) is my goal for 5-6 full bgp feeds. /kc On Fri, Apr 15, 2016 at 07:45:39PM -0400, Michael Brown said: >Not *exactly* what you're asking for, but a Lanner appliance (???http://www.lannerinc.com/products/network-appliances/x86-rackmount-network-appliances/nca-5210) might suit your needs. > >M. > >?? Original Message ?? >From: David Sotnick >Sent: Friday, April 15, 2016 16:19 >To: NANOG >Subject: 10G-capable customer router recommendations? > >Hello masters of the Internet, > >I was recently asked to set up networking at a VIP's home where he has >Comcast "Gigabit Pro" service, which is delivered on a 10G-SR MM port on a >Comcast-supplied Juniper ACX-2100 router. > >Which customer router would you suggest for such a setup? It needs to do >IPv4 NAT, DHCP, IPv4+IPv6 routing and have a decent L4 firewall (that also >supports IPv6). > >The customer pays for "2Gb" service (Comcast caps this at 2G+10% = 2.2Gbps) >and would like to get what he pays for (*cough*) by having the ability to >stream two 1Gbps streams (or at least achieve > 1.0Gbps). > >I'm tempted to get another ACX-2100 and do a 4x1Gb LACP port-channel to the >customer switch, or replace the AV-integrator-installed Cisco SG300-52P >(Cisco switch with e.g. an EX-3300 with 10Gb uplinks). > >Thanks in advance for your suggestions. > >-Dave Ken Chase - math at sizone.org From nanog at ics-il.net Sat Apr 16 01:43:22 2016 From: nanog at ics-il.net (Mike Hammett) Date: Fri, 15 Apr 2016 20:43:22 -0500 (CDT) Subject: 10G-capable customer router recommendations? In-Reply-To: Message-ID: <117724433.3481.1460770997811.JavaMail.mhammett@ThunderFuck> I'm glad you're in Missouri and not in my area. :-) ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest Internet Exchange http://www.midwest-ix.com ----- Original Message ----- From: "Josh Reynolds" To: "Mike Hammett" Cc: "NANOG" Sent: Friday, April 15, 2016 8:32:17 PM Subject: Re: 10G-capable customer router recommendations? If I were sold a $400/mo+ service that had a limitation like that, I would be very unhappy. To each their own. On Apr 15, 2016 8:29 PM, "Mike Hammett" < nanog at ics-il.net > wrote: The CCRs' primary weaknesses are full tables and 1 gigabit cap per flow. Neither is likely to be an issue for this residential use case. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest Internet Exchange http://www.midwest-ix.com ----- Original Message ----- From: "Josh Reynolds" < josh at kyneticwifi.com > To: "Filip Hruska" < fhr at fhrnet.eu > Cc: "NANOG" < nanog at nanog.org > Sent: Friday, April 15, 2016 5:12:35 PM Subject: Re: 10G-capable customer router recommendations? As much as I enjoy Mikrotik products and respect my friends and peers who use them, until ROS 7.x the CCR is a "gimped" product. On Apr 15, 2016 5:10 PM, "Filip Hruska" < fhr at fhrnet.eu > wrote: > Hi, > > I would also vote for Mikrotik products; IMHO this looks perfect for this > situation. > > http://routerboard.com/CCR1009-8G-1S-1SplusPC > > > > On 04/16/2016 12:01 AM, mike.lyon at gmail.com wrote: > >> Check out the Mikrotik Cloud Core routers, they make them with SFP+ >> support now. I have one of them with 10g deployed right now. >> >> -Mike >> >> On Apr 15, 2016, at 14:52, Aaron < aaron at wholesaleinternet.net > wrote: >>> >>> Not a lot of 10G capable CPEs out there. For our 10G residential >>> customers we install Brocade ICXs. >>> >>> Aaron >>> >>> >>> On 4/15/2016 3:18 PM, David Sotnick wrote: >>>> Hello masters of the Internet, >>>> >>>> I was recently asked to set up networking at a VIP's home where he has >>>> Comcast "Gigabit Pro" service, which is delivered on a 10G-SR MM port >>>> on a >>>> Comcast-supplied Juniper ACX-2100 router. >>>> >>>> Which customer router would you suggest for such a setup? It needs to do >>>> IPv4 NAT, DHCP, IPv4+IPv6 routing and have a decent L4 firewall (that >>>> also >>>> supports IPv6). >>>> >>>> The customer pays for "2Gb" service (Comcast caps this at 2G+10% = >>>> 2.2Gbps) >>>> and would like to get what he pays for (*cough*) by having the ability >>>> to >>>> stream two 1Gbps streams (or at least achieve > 1.0Gbps). >>>> >>>> I'm tempted to get another ACX-2100 and do a 4x1Gb LACP port-channel to >>>> the >>>> customer switch, or replace the AV-integrator-installed Cisco SG300-52P >>>> (Cisco switch with e.g. an EX-3300 with 10Gb uplinks). >>>> >>>> Thanks in advance for your suggestions. >>>> >>>> -Dave >>>> >>> >>> -- >>> ================================================================ >>> Aaron Wendel >>> Chief Technical Officer >>> Wholesale Internet, Inc. (AS 32097) >>> (816)550-9030 >>> http://www.wholesaleinternet.com >>> ================================================================ >>> >>> >> From josh at kyneticwifi.com Sat Apr 16 01:46:35 2016 From: josh at kyneticwifi.com (Josh Reynolds) Date: Fri, 15 Apr 2016 20:46:35 -0500 Subject: 10G-capable customer router recommendations? In-Reply-To: <117724433.3481.1460770997811.JavaMail.mhammett@ThunderFuck> References: <117724433.3481.1460770997811.JavaMail.mhammett@ThunderFuck> Message-ID: :) On Apr 15, 2016 8:45 PM, "Mike Hammett" wrote: > I'm glad you're in Missouri and not in my area. :-) > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > > > Midwest Internet Exchange > http://www.midwest-ix.com > > > ----- Original Message ----- > > From: "Josh Reynolds" > To: "Mike Hammett" > Cc: "NANOG" > Sent: Friday, April 15, 2016 8:32:17 PM > Subject: Re: 10G-capable customer router recommendations? > > > If I were sold a $400/mo+ service that had a limitation like that, I would > be very unhappy. > To each their own. > On Apr 15, 2016 8:29 PM, "Mike Hammett" < nanog at ics-il.net > wrote: > > > The CCRs' primary weaknesses are full tables and 1 gigabit cap per flow. > Neither is likely to be an issue for this residential use case. > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > > > Midwest Internet Exchange > http://www.midwest-ix.com > > > ----- Original Message ----- > > From: "Josh Reynolds" < josh at kyneticwifi.com > > To: "Filip Hruska" < fhr at fhrnet.eu > > Cc: "NANOG" < nanog at nanog.org > > Sent: Friday, April 15, 2016 5:12:35 PM > Subject: Re: 10G-capable customer router recommendations? > > As much as I enjoy Mikrotik products and respect my friends and peers who > use them, until ROS 7.x the CCR is a "gimped" product. > On Apr 15, 2016 5:10 PM, "Filip Hruska" < fhr at fhrnet.eu > wrote: > > > Hi, > > > > I would also vote for Mikrotik products; IMHO this looks perfect for this > > situation. > > > > http://routerboard.com/CCR1009-8G-1S-1SplusPC > > > > > > > > On 04/16/2016 12:01 AM, mike.lyon at gmail.com wrote: > > > >> Check out the Mikrotik Cloud Core routers, they make them with SFP+ > >> support now. I have one of them with 10g deployed right now. > >> > >> -Mike > >> > >> On Apr 15, 2016, at 14:52, Aaron < aaron at wholesaleinternet.net > wrote: > >>> > >>> Not a lot of 10G capable CPEs out there. For our 10G residential > >>> customers we install Brocade ICXs. > >>> > >>> Aaron > >>> > >>> > >>> On 4/15/2016 3:18 PM, David Sotnick wrote: > >>>> Hello masters of the Internet, > >>>> > >>>> I was recently asked to set up networking at a VIP's home where he has > >>>> Comcast "Gigabit Pro" service, which is delivered on a 10G-SR MM port > >>>> on a > >>>> Comcast-supplied Juniper ACX-2100 router. > >>>> > >>>> Which customer router would you suggest for such a setup? It needs to > do > >>>> IPv4 NAT, DHCP, IPv4+IPv6 routing and have a decent L4 firewall (that > >>>> also > >>>> supports IPv6). > >>>> > >>>> The customer pays for "2Gb" service (Comcast caps this at 2G+10% = > >>>> 2.2Gbps) > >>>> and would like to get what he pays for (*cough*) by having the ability > >>>> to > >>>> stream two 1Gbps streams (or at least achieve > 1.0Gbps). > >>>> > >>>> I'm tempted to get another ACX-2100 and do a 4x1Gb LACP port-channel > to > >>>> the > >>>> customer switch, or replace the AV-integrator-installed Cisco > SG300-52P > >>>> (Cisco switch with e.g. an EX-3300 with 10Gb uplinks). > >>>> > >>>> Thanks in advance for your suggestions. > >>>> > >>>> -Dave > >>>> > >>> > >>> -- > >>> ================================================================ > >>> Aaron Wendel > >>> Chief Technical Officer > >>> Wholesale Internet, Inc. (AS 32097) > >>> (816)550-9030 > >>> http://www.wholesaleinternet.com > >>> ================================================================ > >>> > >>> > >> > > > > > From nanog at ics-il.net Sat Apr 16 01:53:58 2016 From: nanog at ics-il.net (Mike Hammett) Date: Fri, 15 Apr 2016 20:53:58 -0500 (CDT) Subject: 10G-capable customer router recommendations? In-Reply-To: Message-ID: <1294636384.3542.1460771636722.JavaMail.mhammett@ThunderFuck> CCRs do firewalling and NAT just great. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest Internet Exchange http://www.midwest-ix.com ----- Original Message ----- From: "Chris Knipe" To: "Josh Reynolds" Cc: "NANOG" Sent: Friday, April 15, 2016 5:11:54 PM Subject: Re: 10G-capable customer router recommendations? On Sat, Apr 16, 2016 at 12:04 AM, Josh Reynolds wrote: > Can't do more than 1Gbps per flow. Not suitable for this application. > On Apr 15, 2016 5:03 PM, wrote: > > > Check out the Mikrotik Cloud Core routers, they make them with SFP+ > > support now. I have one of them with 10g deployed right now. > > > > -Mike > Also it falls pretty much flat on it's face the moment you do anything useful in terms of firewalling / NATing. From jjones at danrj.com Sat Apr 16 02:16:08 2016 From: jjones at danrj.com (Jerry Jones) Date: Fri, 15 Apr 2016 21:16:08 -0500 Subject: 10G-capable customer router recommendations? In-Reply-To: <20160415234539.7147590.32900.20859@supermathie.net> References: <20160415234539.7147590.32900.20859@supermathie.net> Message-ID: <73E5DB37-E70C-479F-81EE-FA9FE75BDEEA@danrj.com> SRX1500? From mdehghani at hamyar.net Sat Apr 16 04:09:24 2016 From: mdehghani at hamyar.net (Mohsen Dehghani) Date: Sat, 16 Apr 2016 08:39:24 +0430 Subject: Problem with policy-map update in Cisco ASR 1004 Message-ID: <009201d19795$c2b6dba0$482492e0$@hamyar.net> Hello everyone, I have a problem in updating PPPoE session policy-map via RADIUS CoA packet. When the RADIUS sends CoA to the BRAS, the policy of PPPoE session would not update. My software is asr1000rp2-adventerprisek9.03.13.00.S.154-3.S-ext.bin and The result of "debug aaa coa" is as follows: *Apr 11 04:55:42.152: COA: 80.191.122.6 request queued *Apr 11 04:55:42.152: RADIUS: authenticator 2C D3 08 A2 34 72 FB F2 - 5C 3C A4 F9 81 09 4D 77 *Apr 11 04:55:42.152: RADIUS: Vendor, Cisco [26] 11 *Apr 11 04:55:42.152: RADIUS: Sub_Policy_In [37] 5 "256" *Apr 11 04:55:42.152: RADIUS: Vendor, Cisco [26] 11 *Apr 11 04:55:42.152: RADIUS: Sub_Policy_Out [38] 5 "256" *Apr 11 04:55:42.152: RADIUS: Acct-Session-Id [44] 10 "001195E5" *Apr 11 04:55:42.152: COA: Message Authenticator missing or failed decode *Apr 11 04:55:42.152: ++++++ CoA Attribute List ++++++ *Apr 11 04:55:42.152: 7F78B212D7A8 0 00000081 sub-policy-In(420) 3 256 *Apr 11 04:55:42.152: 7F78B211FCA0 0 00000081 sub-policy-Out(422) 3 256 *Apr 11 04:55:42.152: 7F78B211FCE0 0 00000001 session-id(408) 4 1152485(1195E5) *Apr 11 04:55:42.152: *Apr 11 04:55:42.153: ++++++ Received CoA response Attribute List ++++++ *Apr 11 04:55:42.153: 7F78C82755D0 0 00000081 ssg-command-code(490) 2 10 00 *Apr 11 04:55:42.153: 7F78C8275610 0 00000001 session-id(408) 4 1152485(1195E5) *Apr 11 04:55:42.153: 7F78C8275650 0 00000081 ssg-account-info(488) 22 $IVirtual-Access2.5184 Any Help would be really appreciated. From listas at kurtkraut.net Sat Apr 16 12:57:00 2016 From: listas at kurtkraut.net (Kurt Kraut) Date: Sat, 16 Apr 2016 09:57:00 -0300 Subject: 10G-capable customer router recommendations? In-Reply-To: <571165C8.7050000@fhrnet.eu> References: <57116295.6080607@wholesaleinternet.net> <571165C8.7050000@fhrnet.eu> Message-ID: I highly doubt that. It is not easy to configure, certainty trial and error approaches will generate low performance. I have Mikrotik CCR in production and everything the manufacturer states it does, it does for me. Best regards, Kurt Kraut Em 15 de abr de 2016 19:08, "Filip Hruska" escreveu: > Hi, > > I would also vote for Mikrotik products; IMHO this looks perfect for this > situation. > > http://routerboard.com/CCR1009-8G-1S-1SplusPC > > > > On 04/16/2016 12:01 AM, mike.lyon at gmail.com wrote: > >> Check out the Mikrotik Cloud Core routers, they make them with SFP+ >> support now. I have one of them with 10g deployed right now. >> >> -Mike >> >> On Apr 15, 2016, at 14:52, Aaron wrote: >>> >>> Not a lot of 10G capable CPEs out there. For our 10G residential >>> customers we install Brocade ICXs. >>> >>> Aaron >>> >>> >>> On 4/15/2016 3:18 PM, David Sotnick wrote: >>>> Hello masters of the Internet, >>>> >>>> I was recently asked to set up networking at a VIP's home where he has >>>> Comcast "Gigabit Pro" service, which is delivered on a 10G-SR MM port >>>> on a >>>> Comcast-supplied Juniper ACX-2100 router. >>>> >>>> Which customer router would you suggest for such a setup? It needs to do >>>> IPv4 NAT, DHCP, IPv4+IPv6 routing and have a decent L4 firewall (that >>>> also >>>> supports IPv6). >>>> >>>> The customer pays for "2Gb" service (Comcast caps this at 2G+10% = >>>> 2.2Gbps) >>>> and would like to get what he pays for (*cough*) by having the ability >>>> to >>>> stream two 1Gbps streams (or at least achieve > 1.0Gbps). >>>> >>>> I'm tempted to get another ACX-2100 and do a 4x1Gb LACP port-channel to >>>> the >>>> customer switch, or replace the AV-integrator-installed Cisco SG300-52P >>>> (Cisco switch with e.g. an EX-3300 with 10Gb uplinks). >>>> >>>> Thanks in advance for your suggestions. >>>> >>>> -Dave >>>> >>> >>> -- >>> ================================================================ >>> Aaron Wendel >>> Chief Technical Officer >>> Wholesale Internet, Inc. (AS 32097) >>> (816)550-9030 >>> http://www.wholesaleinternet.com >>> ================================================================ >>> >>> >> From michael at supermathie.net Sat Apr 16 14:11:18 2016 From: michael at supermathie.net (Michael Brown) Date: Sat, 16 Apr 2016 10:11:18 -0400 Subject: 10G-capable customer router recommendations? In-Reply-To: <20160416002456.GA22567@sizone.org> References: <20160415234539.7147590.32900.20859@supermathie.net> <20160416002456.GA22567@sizone.org> Message-ID: <20160416141118.7147590.55484.20863@supermathie.net> "?2 NIC module slots supporting 1/10/40G/Fiber/Copper/Bypass" Get one of those with a server class processor and and it's a server that looks like a spiffy network appliance.? ? ?Very general purpose if general purpose is what you need, quagga / openbgpd on ?bsd, yes. And you can bake additional services onto it. M. ? Original Message ? From: Ken Chase Sent: Friday, April 15, 2016 20:26 To: NANOG Subject: Re: 10G-capable customer router recommendations? Does that lanner even do SFP+? Dont see it listed in the specs. Looks like 4210 has 2x SFP+, though their 'performance' level products look more in line with 'useful'. http://www.lannerinc.com/products/x86-network-appliances/x86-rackmount-appliances/fw-8877 As for the microtics, wonky user interface, so very unciscolike (i guess thats my problem - but the GUI thing feels like a toy), but for their midrange models I found their bgp convergence times pretty poor on their low end cpus... What do you put on the lanner? OpenBGPd? Quagga? Also looking for a 10G solution here, low power (than a full ASR stack..) is my goal for 5-6 full bgp feeds. /kc On Fri, Apr 15, 2016 at 07:45:39PM -0400, Michael Brown said: >Not *exactly* what you're asking for, but a Lanner appliance (???http://www.lannerinc.com/products/network-appliances/x86-rackmount-network-appliances/nca-5210) might suit your needs. > >M. > >?? Original Message ?? >From: David Sotnick >Sent: Friday, April 15, 2016 16:19 >To: NANOG >Subject: 10G-capable customer router recommendations? > >Hello masters of the Internet, > >I was recently asked to set up networking at a VIP's home where he has >Comcast "Gigabit Pro" service, which is delivered on a 10G-SR MM port on a >Comcast-supplied Juniper ACX-2100 router. > >Which customer router would you suggest for such a setup? It needs to do >IPv4 NAT, DHCP, IPv4+IPv6 routing and have a decent L4 firewall (that also >supports IPv6). > >The customer pays for "2Gb" service (Comcast caps this at 2G+10% = 2.2Gbps) >and would like to get what he pays for (*cough*) by having the ability to >stream two 1Gbps streams (or at least achieve > 1.0Gbps). > >I'm tempted to get another ACX-2100 and do a 4x1Gb LACP port-channel to the >customer switch, or replace the AV-integrator-installed Cisco SG300-52P >(Cisco switch with e.g. an EX-3300 with 10Gb uplinks). > >Thanks in advance for your suggestions. > >-Dave Ken Chase - math at sizone.org From josh at kyneticwifi.com Sat Apr 16 14:12:13 2016 From: josh at kyneticwifi.com (Josh Reynolds) Date: Sat, 16 Apr 2016 09:12:13 -0500 Subject: 10G-capable customer router recommendations? In-Reply-To: References: <57116295.6080607@wholesaleinternet.net> Message-ID: You might ask Normis about that :) It has nothing to do with fastpath, and isn't scheduled to be fixed until 7.x when many features are rewritten to take advantage of multiple tile cores. Currently each port is pinned to a single cpu (affinity) due to latency and performance reasons - but yes there are drawbacks when your per core clock is still in 1GHz territory. If you want to talk more about this, we can discuss.offlist or on the Mikrotik forum. On Apr 16, 2016 12:51 AM, "Andrew Thrift" wrote: > This has not been the case for at least a year now. > > Most Mikrotik routers now support FastPath/FastTrack. This is kind of > like CEF in Cisco land. > > http://wiki.mikrotik.com/wiki/Manual:Fast_Path > > http://wiki.mikrotik.com/wiki/Manual:Wiki/Fasttrack > On 16/04/2016 10:07 am, "Josh Reynolds" wrote: > >> Can't do more than 1Gbps per flow. Not suitable for this application. >> On Apr 15, 2016 5:03 PM, wrote: >> >> > Check out the Mikrotik Cloud Core routers, they make them with SFP+ >> > support now. I have one of them with 10g deployed right now. >> > >> > -Mike >> > >> > > On Apr 15, 2016, at 14:52, Aaron wrote: >> > > >> > > Not a lot of 10G capable CPEs out there. For our 10G residential >> > customers we install Brocade ICXs. >> > > >> > > Aaron >> > > >> > > >> > >> On 4/15/2016 3:18 PM, David Sotnick wrote: >> > >> Hello masters of the Internet, >> > >> >> > >> I was recently asked to set up networking at a VIP's home where he >> has >> > >> Comcast "Gigabit Pro" service, which is delivered on a 10G-SR MM port >> > on a >> > >> Comcast-supplied Juniper ACX-2100 router. >> > >> >> > >> Which customer router would you suggest for such a setup? It needs >> to do >> > >> IPv4 NAT, DHCP, IPv4+IPv6 routing and have a decent L4 firewall (that >> > also >> > >> supports IPv6). >> > >> >> > >> The customer pays for "2Gb" service (Comcast caps this at 2G+10% = >> > 2.2Gbps) >> > >> and would like to get what he pays for (*cough*) by having the >> ability >> > to >> > >> stream two 1Gbps streams (or at least achieve > 1.0Gbps). >> > >> >> > >> I'm tempted to get another ACX-2100 and do a 4x1Gb LACP port-channel >> to >> > the >> > >> customer switch, or replace the AV-integrator-installed Cisco >> SG300-52P >> > >> (Cisco switch with e.g. an EX-3300 with 10Gb uplinks). >> > >> >> > >> Thanks in advance for your suggestions. >> > >> >> > >> -Dave >> > > >> > > -- >> > > ================================================================ >> > > Aaron Wendel >> > > Chief Technical Officer >> > > Wholesale Internet, Inc. (AS 32097) >> > > (816)550-9030 >> > > http://www.wholesaleinternet.com >> > > ================================================================ >> > > >> > >> > From nanog at ics-il.net Sat Apr 16 14:18:22 2016 From: nanog at ics-il.net (Mike Hammett) Date: Sat, 16 Apr 2016 09:18:22 -0500 (CDT) Subject: 10G-capable customer router recommendations? In-Reply-To: Message-ID: <1050998126.3997.1460816296020.JavaMail.mhammett@ThunderFuck> If you were on FB, the TBW page would be a great venue. ;-) ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest Internet Exchange http://www.midwest-ix.com ----- Original Message ----- From: "Josh Reynolds" To: "Andrew Thrift" Cc: "NANOG" Sent: Saturday, April 16, 2016 9:12:13 AM Subject: Re: 10G-capable customer router recommendations? You might ask Normis about that :) It has nothing to do with fastpath, and isn't scheduled to be fixed until 7.x when many features are rewritten to take advantage of multiple tile cores. Currently each port is pinned to a single cpu (affinity) due to latency and performance reasons - but yes there are drawbacks when your per core clock is still in 1GHz territory. If you want to talk more about this, we can discuss.offlist or on the Mikrotik forum. On Apr 16, 2016 12:51 AM, "Andrew Thrift" wrote: > This has not been the case for at least a year now. > > Most Mikrotik routers now support FastPath/FastTrack. This is kind of > like CEF in Cisco land. > > http://wiki.mikrotik.com/wiki/Manual:Fast_Path > > http://wiki.mikrotik.com/wiki/Manual:Wiki/Fasttrack > On 16/04/2016 10:07 am, "Josh Reynolds" wrote: > >> Can't do more than 1Gbps per flow. Not suitable for this application. >> On Apr 15, 2016 5:03 PM, wrote: >> >> > Check out the Mikrotik Cloud Core routers, they make them with SFP+ >> > support now. I have one of them with 10g deployed right now. >> > >> > -Mike >> > >> > > On Apr 15, 2016, at 14:52, Aaron wrote: >> > > >> > > Not a lot of 10G capable CPEs out there. For our 10G residential >> > customers we install Brocade ICXs. >> > > >> > > Aaron >> > > >> > > >> > >> On 4/15/2016 3:18 PM, David Sotnick wrote: >> > >> Hello masters of the Internet, >> > >> >> > >> I was recently asked to set up networking at a VIP's home where he >> has >> > >> Comcast "Gigabit Pro" service, which is delivered on a 10G-SR MM port >> > on a >> > >> Comcast-supplied Juniper ACX-2100 router. >> > >> >> > >> Which customer router would you suggest for such a setup? It needs >> to do >> > >> IPv4 NAT, DHCP, IPv4+IPv6 routing and have a decent L4 firewall (that >> > also >> > >> supports IPv6). >> > >> >> > >> The customer pays for "2Gb" service (Comcast caps this at 2G+10% = >> > 2.2Gbps) >> > >> and would like to get what he pays for (*cough*) by having the >> ability >> > to >> > >> stream two 1Gbps streams (or at least achieve > 1.0Gbps). >> > >> >> > >> I'm tempted to get another ACX-2100 and do a 4x1Gb LACP port-channel >> to >> > the >> > >> customer switch, or replace the AV-integrator-installed Cisco >> SG300-52P >> > >> (Cisco switch with e.g. an EX-3300 with 10Gb uplinks). >> > >> >> > >> Thanks in advance for your suggestions. >> > >> >> > >> -Dave >> > > >> > > -- >> > > ================================================================ >> > > Aaron Wendel >> > > Chief Technical Officer >> > > Wholesale Internet, Inc. (AS 32097) >> > > (816)550-9030 >> > > http://www.wholesaleinternet.com >> > > ================================================================ >> > > >> > >> > From josh at kyneticwifi.com Sat Apr 16 14:22:07 2016 From: josh at kyneticwifi.com (Josh Reynolds) Date: Sat, 16 Apr 2016 09:22:07 -0500 Subject: 10G-capable customer router recommendations? In-Reply-To: <1050998126.3997.1460816296020.JavaMail.mhammett@ThunderFuck> References: <1050998126.3997.1460816296020.JavaMail.mhammett@ThunderFuck> Message-ID: Facebook is for losers. Forums are for closers. ;) On Apr 16, 2016 9:21 AM, "Mike Hammett" wrote: > If you were on FB, the TBW page would be a great venue. ;-) > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > > > Midwest Internet Exchange > http://www.midwest-ix.com > > > ----- Original Message ----- > > From: "Josh Reynolds" > To: "Andrew Thrift" > Cc: "NANOG" > Sent: Saturday, April 16, 2016 9:12:13 AM > Subject: Re: 10G-capable customer router recommendations? > > You might ask Normis about that :) It has nothing to do with fastpath, and > isn't scheduled to be fixed until 7.x when many features are rewritten to > take advantage of multiple tile cores. > > Currently each port is pinned to a single cpu (affinity) due to latency and > performance reasons - but yes there are drawbacks when your per core clock > is still in 1GHz territory. > > If you want to talk more about this, we can discuss.offlist or on the > Mikrotik forum. > On Apr 16, 2016 12:51 AM, "Andrew Thrift" > wrote: > > > This has not been the case for at least a year now. > > > > Most Mikrotik routers now support FastPath/FastTrack. This is kind of > > like CEF in Cisco land. > > > > http://wiki.mikrotik.com/wiki/Manual:Fast_Path > > > > http://wiki.mikrotik.com/wiki/Manual:Wiki/Fasttrack > > On 16/04/2016 10:07 am, "Josh Reynolds" wrote: > > > >> Can't do more than 1Gbps per flow. Not suitable for this application. > >> On Apr 15, 2016 5:03 PM, wrote: > >> > >> > Check out the Mikrotik Cloud Core routers, they make them with SFP+ > >> > support now. I have one of them with 10g deployed right now. > >> > > >> > -Mike > >> > > >> > > On Apr 15, 2016, at 14:52, Aaron > wrote: > >> > > > >> > > Not a lot of 10G capable CPEs out there. For our 10G residential > >> > customers we install Brocade ICXs. > >> > > > >> > > Aaron > >> > > > >> > > > >> > >> On 4/15/2016 3:18 PM, David Sotnick wrote: > >> > >> Hello masters of the Internet, > >> > >> > >> > >> I was recently asked to set up networking at a VIP's home where he > >> has > >> > >> Comcast "Gigabit Pro" service, which is delivered on a 10G-SR MM > port > >> > on a > >> > >> Comcast-supplied Juniper ACX-2100 router. > >> > >> > >> > >> Which customer router would you suggest for such a setup? It needs > >> to do > >> > >> IPv4 NAT, DHCP, IPv4+IPv6 routing and have a decent L4 firewall > (that > >> > also > >> > >> supports IPv6). > >> > >> > >> > >> The customer pays for "2Gb" service (Comcast caps this at 2G+10% = > >> > 2.2Gbps) > >> > >> and would like to get what he pays for (*cough*) by having the > >> ability > >> > to > >> > >> stream two 1Gbps streams (or at least achieve > 1.0Gbps). > >> > >> > >> > >> I'm tempted to get another ACX-2100 and do a 4x1Gb LACP > port-channel > >> to > >> > the > >> > >> customer switch, or replace the AV-integrator-installed Cisco > >> SG300-52P > >> > >> (Cisco switch with e.g. an EX-3300 with 10Gb uplinks). > >> > >> > >> > >> Thanks in advance for your suggestions. > >> > >> > >> > >> -Dave > >> > > > >> > > -- > >> > > ================================================================ > >> > > Aaron Wendel > >> > > Chief Technical Officer > >> > > Wholesale Internet, Inc. (AS 32097) > >> > > (816)550-9030 > >> > > http://www.wholesaleinternet.com > >> > > ================================================================ > >> > > > >> > > >> > > > > From josh at kyneticwifi.com Sat Apr 16 14:38:19 2016 From: josh at kyneticwifi.com (Josh Reynolds) Date: Sat, 16 Apr 2016 09:38:19 -0500 Subject: 10G-capable customer router recommendations? In-Reply-To: References: <57116295.6080607@wholesaleinternet.net> Message-ID: So after looking at the most recent testing I can find, it seems the that the 10Gbps CCR can indeed do more than 1Gbps per flow. It requires jumbo frames and fastpath compatible config to pull off. In short, you're still better off for the price using a L3 ASIC on a 10Gbps capable switch which can do full line rate at the smallest packet sizes with those limitations in mind. MikroTik is indeed a good general purpose platform for many things. Although the CLI IMO isn't as nice as JUNOS or Vyatta/EdgeOS (personal preference here), many should not be so quick to dismiss it. On Apr 16, 2016 12:51 AM, "Andrew Thrift" wrote: > This has not been the case for at least a year now. > > Most Mikrotik routers now support FastPath/FastTrack. This is kind of > like CEF in Cisco land. > > http://wiki.mikrotik.com/wiki/Manual:Fast_Path > > http://wiki.mikrotik.com/wiki/Manual:Wiki/Fasttrack > On 16/04/2016 10:07 am, "Josh Reynolds" wrote: > >> Can't do more than 1Gbps per flow. Not suitable for this application. >> On Apr 15, 2016 5:03 PM, wrote: >> >> > Check out the Mikrotik Cloud Core routers, they make them with SFP+ >> > support now. I have one of them with 10g deployed right now. >> > >> > -Mike >> > >> > > On Apr 15, 2016, at 14:52, Aaron wrote: >> > > >> > > Not a lot of 10G capable CPEs out there. For our 10G residential >> > customers we install Brocade ICXs. >> > > >> > > Aaron >> > > >> > > >> > >> On 4/15/2016 3:18 PM, David Sotnick wrote: >> > >> Hello masters of the Internet, >> > >> >> > >> I was recently asked to set up networking at a VIP's home where he >> has >> > >> Comcast "Gigabit Pro" service, which is delivered on a 10G-SR MM port >> > on a >> > >> Comcast-supplied Juniper ACX-2100 router. >> > >> >> > >> Which customer router would you suggest for such a setup? It needs >> to do >> > >> IPv4 NAT, DHCP, IPv4+IPv6 routing and have a decent L4 firewall (that >> > also >> > >> supports IPv6). >> > >> >> > >> The customer pays for "2Gb" service (Comcast caps this at 2G+10% = >> > 2.2Gbps) >> > >> and would like to get what he pays for (*cough*) by having the >> ability >> > to >> > >> stream two 1Gbps streams (or at least achieve > 1.0Gbps). >> > >> >> > >> I'm tempted to get another ACX-2100 and do a 4x1Gb LACP port-channel >> to >> > the >> > >> customer switch, or replace the AV-integrator-installed Cisco >> SG300-52P >> > >> (Cisco switch with e.g. an EX-3300 with 10Gb uplinks). >> > >> >> > >> Thanks in advance for your suggestions. >> > >> >> > >> -Dave >> > > >> > > -- >> > > ================================================================ >> > > Aaron Wendel >> > > Chief Technical Officer >> > > Wholesale Internet, Inc. (AS 32097) >> > > (816)550-9030 >> > > http://www.wholesaleinternet.com >> > > ================================================================ >> > > >> > >> > From merlyn at geeks.org Sat Apr 16 14:51:03 2016 From: merlyn at geeks.org (Doug McIntyre) Date: Sat, 16 Apr 2016 09:51:03 -0500 Subject: 10G-capable customer router recommendations? In-Reply-To: References: Message-ID: <20160416145103.GA5477@geeks.org> On Fri, Apr 15, 2016 at 01:18:10PM -0700, David Sotnick wrote: > I was recently asked to set up networking at a VIP's home where he has > Comcast "Gigabit Pro" service, which is delivered on a 10G-SR MM port on a > Comcast-supplied Juniper ACX-2100 router. > > Which customer router would you suggest for such a setup? It needs to do > IPv4 NAT, DHCP, IPv4+IPv6 routing and have a decent L4 firewall (that also > supports IPv6). FortiNet 600D? 36Gbps throughput with dual SFP+ port and several 1Gbps ports. Specs say full NGFW throughput is 2.4Gbps (ie. you turn on all the knobs). From frnkblk at iname.com Sat Apr 16 19:48:28 2016 From: frnkblk at iname.com (frnkblk at iname.com) Date: Sat, 16 Apr 2016 14:48:28 -0500 Subject: GeoIP database issues and the real world consequences In-Reply-To: References: <20160411191347.GC4087@excession.tpb.net> <20160412115557.60578.qmail@ary.lan> Message-ID: <003c01d19818$f3e9d500$dbbd7f00$@iname.com> Note that for E911 purposes we are required to use the MSAG (http://netorange.com/nena-reference/index.php?title=Master_Street_Address_Guide_(MSAG)) to verify street addresses. From what my co-workers at my $DAYJOB tell me, there are many new addresses that are not resolvable. Despite those shortcomings, E911 calls are responded to and US postal mail is delivered, specifically because a human remains involved in interpreting the information. The same needs to be done with GeoIP results. Frank -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Jeremy Austin Sent: Tuesday, April 12, 2016 8:55 AM To: John Levine Cc: niels=nanog at bakker.net; NANOG list Subject: Re: GeoIP database issues and the real world consequences On Tue, Apr 12, 2016 at 3:55 AM, John Levine wrote: > > Please don't guess (like, you know, MaxMind does.) USPS has its own > database of all of the deliverable addresses in the country. They > have their problems, but give or take data staleness as buildings > are built or demolished, that's not one of them. A qualifier. USPS has a database of *most* of the deliverable addresses in the country. I'm in an unorganized borough. The USPS actually has no mandate, funding or lever that I can pull (that I can find) to keep their database up to date. Easily 30% of the legitimate addresses in my area are not geocodable nor in the USPS database. I suspect that there are areas of my state with an even worse percentage of unavailable data. UPS and FedEx rely on the USPS database, but will not lift a finger to fix this gap. Even as a municipal body there is no available federal mechanism for updating the database. I've tried multiple times over 15+ years.
So yeah, USPS' database does have its problems. -- Jeremy Austin (907) 895-2311 (907) 803-5422 jhaustin at gmail.com Heritage NetWorks Whitestone Power & Communications Vertical Broadband, LLC Schedule a meeting: http://doodle.com/jermudgeon From baldur.norddahl at gmail.com Sun Apr 17 08:22:04 2016 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Sun, 17 Apr 2016 10:22:04 +0200 Subject: phone fun, was GeoIP database issues and the real world consequences In-Reply-To: <57115D60.3060400@vaxination.ca> References: <20160414153236.GA88366@ussenterprise.ufp.org> <570ED607.1070607@cox.net> <20160414002939.15867.qmail@ary.lan> <1460710177.364730809@apps.rackspace.com> <571105A6.3040607@nvcube.net> <20160415190936.043B346BE4B9@rock.dv.isc.org> <20160415212138.29C9146BF6E3@rock.dv.isc.org> <57115D60.3060400@vaxination.ca> Message-ID: Where I live (Europe) most plans include a ton of free minutes including free calls and data in many other countries. Therefore nobody cares who pays anymore. While this is not universal yet, it probably will be within a decade. Voice calls are simply silly small amount of data that it does not make sense to charge for it and at the same time have gigs of free data included. Technically it is the receiver that pays the cell tax when accepting SIP calls. But nobody cares unless roaming in countries where you still pay data roaming tax at a rate that ought to be illegal. Regards Baldur From sotnickd-nanog at ddv.com Mon Apr 18 02:18:15 2016 From: sotnickd-nanog at ddv.com (David Sotnick) Date: Sun, 17 Apr 2016 19:18:15 -0700 Subject: 10G-capable customer router recommendations? In-Reply-To: References: Message-ID: Thanks for the replies, everyone! Much appreciated. I'm going to check out the Mikrotik CCR series out. Cheers, Dave On Fri, Apr 15, 2016 at 1:18 PM, David Sotnick wrote: > Hello masters of the Internet, > > I was recently asked to set up networking at a VIP's home where he has > Comcast "Gigabit Pro" service, which is delivered on a 10G-SR MM port on a > Comcast-supplied Juniper ACX-2100 router. > > Which customer router would you suggest for such a setup? It needs to do > IPv4 NAT, DHCP, IPv4+IPv6 routing and have a decent L4 firewall (that also > supports IPv6). > > The customer pays for "2Gb" service (Comcast caps this at 2G+10% = > 2.2Gbps) and would like to get what he pays for (*cough*) by having the > ability to stream two 1Gbps streams (or at least achieve > 1.0Gbps). > > I'm tempted to get another ACX-2100 and do a 4x1Gb LACP port-channel to > the customer switch, or replace the AV-integrator-installed Cisco SG300-52P > (Cisco switch with e.g. an EX-3300 with 10Gb uplinks). > > Thanks in advance for your suggestions. > > -Dave > From jared at compuwizz.net Thu Apr 14 23:23:02 2016 From: jared at compuwizz.net (Jared Geiger) Date: Thu, 14 Apr 2016 16:23:02 -0700 Subject: Juniper vMX evaluation - how? In-Reply-To: <570F8F8D.8080503@fastmail.net> References: <570EB1FA.5000509@fastmail.net> <570F8F8D.8080503@fastmail.net> Message-ID: I too have been waiting a couple weeks for my login to Juniper to do a trial download of vMX. A sidenote - the new version of cloudrouter has DPDK support. But I couldn't get it to boot in my limited afternoon time with it. On Thu, Apr 14, 2016 at 5:39 AM, Bruce Simpson wrote: > Thanks to all who responded (and thanks to the NANOGger who provided me > with images). > > I am a bit disappointed that others have also had the silent treatment > after signing up to download vMX. > > I am unsurprised that vMX 14.x has had teething troubles. I also hope JNPR > listen to us that Intel are not the only SR-IOV game in town. Onward... > From andrew at networklabs.co.nz Sat Apr 16 05:51:22 2016 From: andrew at networklabs.co.nz (Andrew Thrift) Date: Sat, 16 Apr 2016 17:51:22 +1200 Subject: 10G-capable customer router recommendations? In-Reply-To: References: <57116295.6080607@wholesaleinternet.net> Message-ID: This has not been the case for at least a year now. Most Mikrotik routers now support FastPath/FastTrack. This is kind of like CEF in Cisco land. http://wiki.mikrotik.com/wiki/Manual:Fast_Path http://wiki.mikrotik.com/wiki/Manual:Wiki/Fasttrack On 16/04/2016 10:07 am, "Josh Reynolds" wrote: > Can't do more than 1Gbps per flow. Not suitable for this application. > On Apr 15, 2016 5:03 PM, wrote: > > > Check out the Mikrotik Cloud Core routers, they make them with SFP+ > > support now. I have one of them with 10g deployed right now. > > > > -Mike > > > > > On Apr 15, 2016, at 14:52, Aaron wrote: > > > > > > Not a lot of 10G capable CPEs out there. For our 10G residential > > customers we install Brocade ICXs. > > > > > > Aaron > > > > > > > > >> On 4/15/2016 3:18 PM, David Sotnick wrote: > > >> Hello masters of the Internet, > > >> > > >> I was recently asked to set up networking at a VIP's home where he has > > >> Comcast "Gigabit Pro" service, which is delivered on a 10G-SR MM port > > on a > > >> Comcast-supplied Juniper ACX-2100 router. > > >> > > >> Which customer router would you suggest for such a setup? It needs to > do > > >> IPv4 NAT, DHCP, IPv4+IPv6 routing and have a decent L4 firewall (that > > also > > >> supports IPv6). > > >> > > >> The customer pays for "2Gb" service (Comcast caps this at 2G+10% = > > 2.2Gbps) > > >> and would like to get what he pays for (*cough*) by having the ability > > to > > >> stream two 1Gbps streams (or at least achieve > 1.0Gbps). > > >> > > >> I'm tempted to get another ACX-2100 and do a 4x1Gb LACP port-channel > to > > the > > >> customer switch, or replace the AV-integrator-installed Cisco > SG300-52P > > >> (Cisco switch with e.g. an EX-3300 with 10Gb uplinks). > > >> > > >> Thanks in advance for your suggestions. > > >> > > >> -Dave > > > > > > -- > > > ================================================================ > > > Aaron Wendel > > > Chief Technical Officer > > > Wholesale Internet, Inc. (AS 32097) > > > (816)550-9030 > > > http://www.wholesaleinternet.com > > > ================================================================ > > > > > > From james.d.cassell4.civ at mail.mil Fri Apr 15 21:23:27 2016 From: james.d.cassell4.civ at mail.mil (Cassell, James D CIV DISA IE (US)) Date: Fri, 15 Apr 2016 21:23:27 +0000 Subject: [Non-DoD Source] Re: G root not responding on UDP? In-Reply-To: <570F93AD.4020002@ripe.net> References: <570F8D1B.20909@ripe.net>,<570F93AD.4020002@ripe.net> Message-ID: <927563B9E4EA4445B39113ADAED2B33C4133282C@ucolhpkr.easf.csd.disa.mil> Regarding yesterday's G-root outage: Like many outages, this one resulted from a series of unfortunate events. These unfortunate events were operational errors; steps have been taken to prevent any reoccurrence, and to provide better service in the future. Jim Cassell DoD NIC ________________________________ From: NANOG [nanog-bounces at nanog.org] on behalf of Robert Kisteleki [robert at ripe.net] Sent: Thursday, April 14, 2016 12:57 PM To: Anurag Bhatia; NANOG Mailing List Subject: [Non-DoD Source] Re: G root not responding on UDP? All active links contained in this email were disabled. Please verify the identity of the sender, and confirm the authenticity of all links contained within the message prior to copying and pasting the address to a Web browser. ---- On 2016-04-14 14:29, Robert Kisteleki wrote: > On 2016-04-14 13:30, Anurag Bhatia wrote: >> Hello everyone >> >> >> I wonder if it's just me or anyone else also finding issues in g root >> reachability? >> >> >> ICMP, trace, UDP DNS queries all timing out. Only TCP seem to work. > > > It's not only you: > > Caution-https://atlas.ripe.net/dnsmon/?dnsmon.session.color_range_pls=0-5-5-25-100&dnsmon.session.exclude-errors=true&dnsmon.type=server-probes&dnsmon.server=192.112.36.4&dnsmon.zone=root&dnsmon.startTime=1460574600&dnsmon.endTime=1460616600&dnsmon.ipVersion=both ... and it recovered already: Caution-https://atlas.ripe.net/dnsmon/?dnsmon.session.color_range_pls=0-5-5-25-100&dnsmon.session.exclude-errors=true&dnsmon.type=server-probes&dnsmon.server=192.112.36.4&dnsmon.zone=root&dnsmon.startTime=1460595996&dnsmon.endTime=1460637996&dnsmon.ipVersion=both&dnsmon.timeWindow=42000 Robert From micahcroff at gmail.com Sat Apr 16 20:13:39 2016 From: micahcroff at gmail.com (Micah Croff) Date: Sat, 16 Apr 2016 13:13:39 -0700 Subject: 10G-capable customer router recommendations? In-Reply-To: References: Message-ID: I haven't tried to do 10Gb with it but pfSense isn't a horrible option. I've done 1G with left over computer parts and for the most part it works well. https://www.pfsense.org/ For "free" software it is pretty feature rich. Micah On Fri, Apr 15, 2016 at 1:18 PM, David Sotnick wrote: > Hello masters of the Internet, > > I was recently asked to set up networking at a VIP's home where he has > Comcast "Gigabit Pro" service, which is delivered on a 10G-SR MM port on a > Comcast-supplied Juniper ACX-2100 router. > > Which customer router would you suggest for such a setup? It needs to do > IPv4 NAT, DHCP, IPv4+IPv6 routing and have a decent L4 firewall (that also > supports IPv6). > > The customer pays for "2Gb" service (Comcast caps this at 2G+10% = 2.2Gbps) > and would like to get what he pays for (*cough*) by having the ability to > stream two 1Gbps streams (or at least achieve > 1.0Gbps). > > I'm tempted to get another ACX-2100 and do a 4x1Gb LACP port-channel to the > customer switch, or replace the AV-integrator-installed Cisco SG300-52P > (Cisco switch with e.g. an EX-3300 with 10Gb uplinks). > > Thanks in advance for your suggestions. > > -Dave > From jared at compuwizz.net Mon Apr 18 01:20:25 2016 From: jared at compuwizz.net (Jared Geiger) Date: Sun, 17 Apr 2016 18:20:25 -0700 Subject: 10G-capable customer router recommendations? In-Reply-To: <20160416145103.GA5477@geeks.org> References: <20160416145103.GA5477@geeks.org> Message-ID: Maybe the EdgePoint EP-S16 device from Ubiquiti. It has 2 SFP+ ports on it. I don't know the status of hardware offload support though. https://dl.ubnt.com/datasheets/edgemax/EdgePoint_DS.pdf https://www.ubnt.com/edgemax/edgepoint/ On Sat, Apr 16, 2016 at 7:51 AM, Doug McIntyre wrote: > On Fri, Apr 15, 2016 at 01:18:10PM -0700, David Sotnick wrote: > > I was recently asked to set up networking at a VIP's home where he has > > Comcast "Gigabit Pro" service, which is delivered on a 10G-SR MM port on > a > > Comcast-supplied Juniper ACX-2100 router. > > > > Which customer router would you suggest for such a setup? It needs to do > > IPv4 NAT, DHCP, IPv4+IPv6 routing and have a decent L4 firewall (that > also > > supports IPv6). > > FortiNet 600D? > 36Gbps throughput with dual SFP+ port and several 1Gbps ports. > Specs say full NGFW throughput is 2.4Gbps (ie. you turn on all the knobs). > From regezos at gmail.com Fri Apr 15 05:38:20 2016 From: regezos at gmail.com (Rukka Pal) Date: Fri, 15 Apr 2016 07:38:20 +0200 Subject: ASR-9K CPU troubleshooting Message-ID: How do you guys troubleshoot high CPU utilization on the ASR-9K platform? Detailed guides are available for IOS platforms, but I can't seem to find anything useful for the ASR. The average line-card (0/0/CPU0: A9K-24x10GE-TR) CPU utilization of my routers is about 10%, however recently I have noticed that 3-5 times a day it increases to 40% and stays there for about an hour (20% spp + 10% netio + the rest). I know this is well withing the acceptable range, but I am the kind of person who likes to understand every change in his network and during the investigation I had to realize that I simply don't have the tools to troubleshoot the ASR CPU. Regards, Sandor From mttume at gmail.com Thu Apr 14 13:01:53 2016 From: mttume at gmail.com (Tum Eh) Date: Thu, 14 Apr 2016 16:01:53 +0300 Subject: Traffic forecasts Message-ID: <570F94C1.1000107@gmail.com> Dear All, Do you use any source other than Telegeography in order to get country's Internet bandwidth infos, or continent to continent capacities etc. BR, Tum From faisal at snappytelecom.net Mon Apr 18 13:23:32 2016 From: faisal at snappytelecom.net (Faisal Imtiaz) Date: Mon, 18 Apr 2016 13:23:32 +0000 (GMT) Subject: 10G-capable customer router recommendations? In-Reply-To: References: <20160416145103.GA5477@geeks.org> Message-ID: <2060720278.157050.1460985812002.JavaMail.zimbra@snappytelecom.net> double check the spec sheets, EP-s16 is a switch not a router.. the smaller units are switch + routers. 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: "Jared Geiger" > To: "nanog list" > Sent: Sunday, April 17, 2016 9:20:25 PM > Subject: Re: 10G-capable customer router recommendations? > Maybe the EdgePoint EP-S16 device from Ubiquiti. It has 2 SFP+ ports on it. > I don't know the status of hardware offload support though. > > https://dl.ubnt.com/datasheets/edgemax/EdgePoint_DS.pdf > https://www.ubnt.com/edgemax/edgepoint/ > > > On Sat, Apr 16, 2016 at 7:51 AM, Doug McIntyre wrote: > >> On Fri, Apr 15, 2016 at 01:18:10PM -0700, David Sotnick wrote: >> > I was recently asked to set up networking at a VIP's home where he has >> > Comcast "Gigabit Pro" service, which is delivered on a 10G-SR MM port on >> a >> > Comcast-supplied Juniper ACX-2100 router. >> > >> > Which customer router would you suggest for such a setup? It needs to do >> > IPv4 NAT, DHCP, IPv4+IPv6 routing and have a decent L4 firewall (that >> also >> > supports IPv6). >> >> FortiNet 600D? >> 36Gbps throughput with dual SFP+ port and several 1Gbps ports. >> Specs say full NGFW throughput is 2.4Gbps (ie. you turn on all the knobs). From morrowc.lists at gmail.com Mon Apr 18 13:26:08 2016 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Mon, 18 Apr 2016 09:26:08 -0400 Subject: Traffic forecasts In-Reply-To: <570F94C1.1000107@gmail.com> References: <570F94C1.1000107@gmail.com> Message-ID: doesn't dyn/renesys provide this as well? On Thu, Apr 14, 2016 at 9:01 AM, Tum Eh wrote: > Dear All, > > Do you use any source other than Telegeography in order to get country's > Internet bandwidth infos, or continent to continent capacities etc. > > BR, > Tum > From morrowc.lists at gmail.com Mon Apr 18 13:28:01 2016 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Mon, 18 Apr 2016 09:28:01 -0400 Subject: [Non-DoD Source] Re: G root not responding on UDP? In-Reply-To: <927563B9E4EA4445B39113ADAED2B33C4133282C@ucolhpkr.easf.csd.disa.mil> References: <570F8D1B.20909@ripe.net> <570F93AD.4020002@ripe.net> <927563B9E4EA4445B39113ADAED2B33C4133282C@ucolhpkr.easf.csd.disa.mil> Message-ID: On Fri, Apr 15, 2016 at 5:23 PM, Cassell, James D CIV DISA IE (US) < james.d.cassell4.civ at mail.mil> wrote: > Regarding yesterday's G-root outage: > > Like many outages, this one resulted from a series of unfortunate events. > These unfortunate events were operational errors; steps have been taken to > prevent any reoccurrence, and to provide better service in the future. > ? thanks for engaging, I wonder if there's a post-mortem coming for this? Folk that run significant infrastructure often run into problems before us normal folk do... so learning from your missteps is educational for the rest of us :) -chris (also, someone, me maybe? asked the same thing from ARIN's folk when they made a boo-boo with rdns records ~1 month or so ago... so fair's fair! :) )? From josh at kyneticwifi.com Mon Apr 18 13:37:35 2016 From: josh at kyneticwifi.com (Josh Reynolds) Date: Mon, 18 Apr 2016 08:37:35 -0500 Subject: 10G-capable customer router recommendations? In-Reply-To: <2060720278.157050.1460985812002.JavaMail.zimbra@snappytelecom.net> References: <20160416145103.GA5477@geeks.org> <2060720278.157050.1460985812002.JavaMail.zimbra@snappytelecom.net> Message-ID: It does have limited static routing capability built in to the hardware though, but no NAT. On Apr 18, 2016 8:25 AM, "Faisal Imtiaz" wrote: > double check the spec sheets, EP-s16 is a switch not a router.. > the smaller units are switch + routers. > > 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: "Jared Geiger" > > To: "nanog list" > > Sent: Sunday, April 17, 2016 9:20:25 PM > > Subject: Re: 10G-capable customer router recommendations? > > > Maybe the EdgePoint EP-S16 device from Ubiquiti. It has 2 SFP+ ports on > it. > > I don't know the status of hardware offload support though. > > > > https://dl.ubnt.com/datasheets/edgemax/EdgePoint_DS.pdf > > https://www.ubnt.com/edgemax/edgepoint/ > > > > > > On Sat, Apr 16, 2016 at 7:51 AM, Doug McIntyre wrote: > > > >> On Fri, Apr 15, 2016 at 01:18:10PM -0700, David Sotnick wrote: > >> > I was recently asked to set up networking at a VIP's home where he has > >> > Comcast "Gigabit Pro" service, which is delivered on a 10G-SR MM port > on > >> a > >> > Comcast-supplied Juniper ACX-2100 router. > >> > > >> > Which customer router would you suggest for such a setup? It needs to > do > >> > IPv4 NAT, DHCP, IPv4+IPv6 routing and have a decent L4 firewall (that > >> also > >> > supports IPv6). > >> > >> FortiNet 600D? > >> 36Gbps throughput with dual SFP+ port and several 1Gbps ports. > >> Specs say full NGFW throughput is 2.4Gbps (ie. you turn on all the > knobs). > From josh at kyneticwifi.com Mon Apr 18 13:39:10 2016 From: josh at kyneticwifi.com (Josh Reynolds) Date: Mon, 18 Apr 2016 08:39:10 -0500 Subject: 10G-capable customer router recommendations? In-Reply-To: References: Message-ID: With a Chelsio T5 you might get some decent pure routing / NAT performance with the right card mod, but as soon as it goes into firewall/ACL/QoS etc, performance will tank drastically. On Apr 18, 2016 7:49 AM, "Micah Croff" wrote: > I haven't tried to do 10Gb with it but pfSense isn't a horrible option. > I've done 1G with left over computer parts and for the most part it works > well. > > https://www.pfsense.org/ > > For "free" software it is pretty feature rich. > > Micah > > On Fri, Apr 15, 2016 at 1:18 PM, David Sotnick > wrote: > > > Hello masters of the Internet, > > > > I was recently asked to set up networking at a VIP's home where he has > > Comcast "Gigabit Pro" service, which is delivered on a 10G-SR MM port on > a > > Comcast-supplied Juniper ACX-2100 router. > > > > Which customer router would you suggest for such a setup? It needs to do > > IPv4 NAT, DHCP, IPv4+IPv6 routing and have a decent L4 firewall (that > also > > supports IPv6). > > > > The customer pays for "2Gb" service (Comcast caps this at 2G+10% = > 2.2Gbps) > > and would like to get what he pays for (*cough*) by having the ability to > > stream two 1Gbps streams (or at least achieve > 1.0Gbps). > > > > I'm tempted to get another ACX-2100 and do a 4x1Gb LACP port-channel to > the > > customer switch, or replace the AV-integrator-installed Cisco SG300-52P > > (Cisco switch with e.g. an EX-3300 with 10Gb uplinks). > > > > Thanks in advance for your suggestions. > > > > -Dave > > > From bicknell at ufp.org Mon Apr 18 14:06:52 2016 From: bicknell at ufp.org (Leo Bicknell) Date: Mon, 18 Apr 2016 07:06:52 -0700 Subject: phone fun, was GeoIP database issues and the real world consequences In-Reply-To: <1460710177.364730809@apps.rackspace.com> References: <570ED607.1070607@cox.net> <20160414002939.15867.qmail@ary.lan> <20160414153236.GA88366@ussenterprise.ufp.org> <1460710177.364730809@apps.rackspace.com> Message-ID: <20160418140652.GA73644@ussenterprise.ufp.org> In a message written on Fri, Apr 15, 2016 at 09:49:37AM +0100, tim at pelican.org wrote: > Out of curiosity, does anyone have a good pointer to the history of how / why US mobile ended up in the same numbering plan as fixed-line? The other answers address the history here better than I ever good, but I wanted to point out one example I hadn't seen mentioned. https://en.wikipedia.org/wiki/Area_code_917 917 was originally a mobile only area code overlay in New York City. For reasons that are unclear to me, after that experiement it was decided that the US would never do that again. -- Leo Bicknell - bicknell at ufp.org PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 811 bytes Desc: not available URL: From jcurran at arin.net Mon Apr 18 14:23:35 2016 From: jcurran at arin.net (John Curran) Date: Mon, 18 Apr 2016 14:23:35 +0000 Subject: ARIN 37 Opens Today! Message-ID: <2509AB5E-4580-4E4C-9E0B-BD373492A519@arin.net> NANOGers - ARIN 37 opens today. I would highly encourage folks to remotely participate if interested (particularly in any number policy discussions that you feel may be of importance...) Details (including a pointer to remote participation instructions) are attached. Thanks! /John John Curran President and CEO American Registry for Internet Numbers (ARIN) Begin forwarded message: From: ARIN > Subject: [arin-announce] ARIN 37 Opens Today! Date: April 18, 2016 at 7:33:26 AM EST To: > The ARIN 37 Public Policy and Members Meeting begins today in Montego Bay, Jamaica. We hope you can join us from 9:00 AM ? 4:00 PM EST on Monday and Tuesday to discuss five draft policies, policy simplification, registry data accuracy, ARIN software developments, and the latest news on the IANA Stewardship Transition. We will also feature an IPv6 panel discussion titled ?Operational Success Stories,? which will feature case studies and guidance from organizations that have successfully deployed IPv6. We will reconvene on Wednesday from 9:00 AM ? 12:00 PM EST for the Members Meeting to hear department updates, as well as reports from the Board, AC, and NRO NC. AGENDA & PRESENTATIONS Preview the agenda and check for updates at: https://www.arin.net/ARIN37_agenda As we receive presentations throughout the week, we will be posting them to: https://www.arin.net/ARIN37_materials FOR REMOTE PARTICIPANTS If you cannot join us in Montego Bay, you can still participate online via webcast, transcript, and YouTube stream. Please register to join the meeting chat room, vote in straw polls, and submit questions or comments. Remote participation info at: https://www.arin.net/ARIN37_remote MEETING RECAP A meeting recap will be posted at the close of today?s session at: http://www.teamarin.net SOCIAL MEDIA On Twitter? Use the hashtag #ARIN37 for all your tweets about the meeting. Join in the conversation at: https://twitter.com/hashtag/ARIN37 Happy Meeting! Regards, Communications and Member Services American Registry for Internet Numbers (ARIN) _______________________________________________ ARIN-Announce You are receiving this message because you are subscribed to the ARIN Announce Mailing List (ARIN-announce at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-announce Please contact info at arin.net if you experience any issues. From mmg at transtelco.net Mon Apr 18 15:33:44 2016 From: mmg at transtelco.net (=?UTF-8?Q?Manuel_Mar=C3=ADn?=) Date: Mon, 18 Apr 2016 09:33:44 -0600 Subject: Software for circuit documentation Message-ID: Dear Nanog community We are looking for a network inventory software to document logical circuits and fibers. We have been using Racktables for cross connects and racks documentation and works great, but we did find a way to document MPLS, Eline/ELAN, OTN, SONET, IP circuits, external plant (fibers), etc. I would appreciate if you can share what you use for documentation. Thank you and have a great day Regards From Chris at aperturefiber.com Mon Apr 18 15:49:51 2016 From: Chris at aperturefiber.com (Chris Garrett) Date: Mon, 18 Apr 2016 11:49:51 -0400 Subject: Software for circuit documentation In-Reply-To: References: Message-ID: Granite is expensive, but pretty much the standard for circuit/xconnect/CFA documentation in the telecom space. > On Apr 18, 2016, at 11:33 AM, Manuel Mar?n wrote: > > Dear Nanog community > > We are looking for a network inventory software to document logical > circuits and fibers. We have been using Racktables for cross connects and > racks documentation and works great, but we did find a way to document > MPLS, Eline/ELAN, OTN, SONET, IP circuits, external plant (fibers), etc. > > I would appreciate if you can share what you use for documentation. > > Thank you and have a great day > > Regards From paul at paulstewart.org Mon Apr 18 16:00:25 2016 From: paul at paulstewart.org (Paul Stewart) Date: Mon, 18 Apr 2016 12:00:25 -0400 Subject: Software for circuit documentation In-Reply-To: References: Message-ID: <00d801d1998b$6c6afdb0$4540f910$@paulstewart.org> It's now called "Ericsson Adaptive Inventory" if I'm not mistaken... Paul -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Chris Garrett Sent: Monday, April 18, 2016 11:50 AM To: Manuel Mar?n Cc: NANOG Subject: Re: Software for circuit documentation Granite is expensive, but pretty much the standard for circuit/xconnect/CFA documentation in the telecom space. > On Apr 18, 2016, at 11:33 AM, Manuel Mar?n wrote: > > Dear Nanog community > > We are looking for a network inventory software to document logical > circuits and fibers. We have been using Racktables for cross connects > and racks documentation and works great, but we did find a way to > document MPLS, Eline/ELAN, OTN, SONET, IP circuits, external plant (fibers), etc. > > I would appreciate if you can share what you use for documentation. > > Thank you and have a great day > > Regards From eric.kuhnke at gmail.com Mon Apr 18 17:09:32 2016 From: eric.kuhnke at gmail.com (Eric Kuhnke) Date: Mon, 18 Apr 2016 10:09:32 -0700 Subject: Software for circuit documentation In-Reply-To: References: Message-ID: mediawiki set up for individual user accounts, https only access, in internal tool IP space/ACL/firewalled. First develop a hierarcically organized 'blank' template you can copy and paste for each POP, and then fill it out. Works great for large scale fiber patch panel assignments/crossconnect tracking, listings of equipment in a POP, MPLS XCs, etc. It only works properly if the persons making each OSI layer 1 change edit the wiki after each change (or the NOC/neteng staff directing the field technicians edit it at the same time as updating a work ticket). One of the great advantages is that it's near infinitely flexible in how you can lay out and arrange the page, and tracks each and every change made by ever user. In case of a mistake it's easy to revert to an earlier version. I am not so sure about its use for OSP fiber tracking which gets into the territory of GIS software and customized vector based diagramming software. On Mon, Apr 18, 2016 at 8:33 AM, Manuel Mar?n wrote: > Dear Nanog community > > We are looking for a network inventory software to document logical > circuits and fibers. We have been using Racktables for cross connects and > racks documentation and works great, but we did find a way to document > MPLS, Eline/ELAN, OTN, SONET, IP circuits, external plant (fibers), etc. > > I would appreciate if you can share what you use for documentation. > > Thank you and have a great day > > Regards > From eric.kuhnke at gmail.com Mon Apr 18 17:11:57 2016 From: eric.kuhnke at gmail.com (Eric Kuhnke) Date: Mon, 18 Apr 2016 10:11:57 -0700 Subject: phone fun, was GeoIP database issues and the real world consequences In-Reply-To: <20160418140652.GA73644@ussenterprise.ufp.org> References: <570ED607.1070607@cox.net> <20160414002939.15867.qmail@ary.lan> <20160414153236.GA88366@ussenterprise.ufp.org> <1460710177.364730809@apps.rackspace.com> <20160418140652.GA73644@ussenterprise.ufp.org> Message-ID: This makes me wonder what the 'market value' of a 212 DID is. I have seen them anywhere from $55 to $600 from providers specifically saying "buy this DID and port it out to your carrier of choice". On Mon, Apr 18, 2016 at 7:06 AM, Leo Bicknell wrote: > In a message written on Fri, Apr 15, 2016 at 09:49:37AM +0100, > tim at pelican.org wrote: > > Out of curiosity, does anyone have a good pointer to the history of how > / why US mobile ended up in the same numbering plan as fixed-line? > > The other answers address the history here better than I ever good, but > I wanted to point out one example I hadn't seen mentioned. > > https://en.wikipedia.org/wiki/Area_code_917 > > 917 was originally a mobile only area code overlay in New York City. > For reasons that are unclear to me, after that experiement it was > decided that the US would never do that again. > > -- > Leo Bicknell - bicknell at ufp.org > PGP keys at http://www.ufp.org/~bicknell/ > From mel at beckman.org Mon Apr 18 17:41:00 2016 From: mel at beckman.org (Mel Beckman) Date: Mon, 18 Apr 2016 17:41:00 +0000 Subject: Software for circuit documentation In-Reply-To: References: Message-ID: <61C208E8-7775-4F32-8372-A1BA613E59AB@beckman.org> I?ve been meaning to get pricing for Ericsson?s Adaptive Inventory (formerly Granite) for a mid-sized ISP client. It?s world-class, but it may turn out to be insanely expensive. I?m also investigating cloud solutions. Most of the legacy commercial products are stuck in the LEC/CLEC inventory regime of T1s, T3s, and circuit grooming, with little support for MPLS, IPv6, or SLA management. Those are the big pain points today for most ISPs grappling with provisioning complexity. -mel > On Apr 18, 2016, at 10:09 AM, Eric Kuhnke wrote: > > mediawiki set up for individual user accounts, https only access, in > internal tool IP space/ACL/firewalled. > > First develop a hierarcically organized 'blank' template you can copy and > paste for each POP, and then fill it out. Works great for large scale fiber > patch panel assignments/crossconnect tracking, listings of equipment in a > POP, MPLS XCs, etc. It only works properly if the persons making each OSI > layer 1 change edit the wiki after each change (or the NOC/neteng staff > directing the field technicians edit it at the same time as updating a work > ticket). > > One of the great advantages is that it's near infinitely flexible in how > you can lay out and arrange the page, and tracks each and every change made > by ever user. In case of a mistake it's easy to revert to an earlier > version. > > I am not so sure about its use for OSP fiber tracking which gets into the > territory of GIS software and customized vector based diagramming software. > > On Mon, Apr 18, 2016 at 8:33 AM, Manuel Mar?n wrote: > >> Dear Nanog community >> >> We are looking for a network inventory software to document logical >> circuits and fibers. We have been using Racktables for cross connects and >> racks documentation and works great, but we did find a way to document >> MPLS, Eline/ELAN, OTN, SONET, IP circuits, external plant (fibers), etc. >> >> I would appreciate if you can share what you use for documentation. >> >> Thank you and have a great day >> >> Regards >> From colton.conor at gmail.com Mon Apr 18 18:01:52 2016 From: colton.conor at gmail.com (Colton Conor) Date: Mon, 18 Apr 2016 13:01:52 -0500 Subject: New Switches with Broadcom StrataDNX In-Reply-To: References: <21968C2D-DCEA-4010-9E2D-31C31294D68C@gmail.com> <1EF6F817-0959-4EAE-9AD9-26984D93C5FB@gmail.com> <569F24E2.8020101@seacom.mu> Message-ID: As a follow up to this post, it look like the Arista 7500R series has this new chip inside of it. On Wed, Jan 20, 2016 at 9:34 AM, Jeff Tantsura wrote: > That's right, logic is in programming chips, not their property. You just > need to know what to program ;-) > > Regards, > Jeff > > > On Jan 19, 2016, at 10:10 PM, Mark Tinka wrote: > > > > > > > >> On 20/Jan/16 00:17, Phil Bedard wrote: > >> > >> Good point, there are many people looking at what I call FIB > optimization right now. The key is having the programmability on the > device to make it happen. Juniper/Cisco support it using policies to > filter RIB->FIB and I believe both also do per-NPU/PFE localized FIBs now. > I am not sure if that?s something supported on this new Broadcom chipset. > Depends on your network of course and where you are looking to position the > router. > > > > I don't think the FIB needs to have specific support for selective > > programming. > > > > I think that comes in the code to instruct the control plane what it > > should download to the FIB. > > > > Cisco's and Juniper's support of this is on FIB that has been in > > production long before the feature became available. It was just added > > to code. > > > > Mark. > From hugge at nordu.net Mon Apr 18 18:07:55 2016 From: hugge at nordu.net (=?UTF-8?Q?Fredrik_Korsb=c3=a4ck?=) Date: Mon, 18 Apr 2016 20:07:55 +0200 Subject: New Switches with Broadcom StrataDNX In-Reply-To: References: <21968C2D-DCEA-4010-9E2D-31C31294D68C@gmail.com> <1EF6F817-0959-4EAE-9AD9-26984D93C5FB@gmail.com> <569F24E2.8020101@seacom.mu> Message-ID: <5715227B.40509@nordu.net> On 18/04/16 20:01, Colton Conor wrote: > As a follow up to this post, it look like the Arista 7500R series has this > new chip inside of it. > > On Wed, Jan 20, 2016 at 9:34 AM, Jeff Tantsura > wrote: > >> That's right, logic is in programming chips, not their property. You just >> need to know what to program ;-) >> >> Regards, >> Jeff Not only the big one, The new Arista 7280R is also the new BRCM DNX aka Jericho. Aswell as Cisco NCS550X series. -- hugge From surfer at mauigateway.com Mon Apr 18 18:14:49 2016 From: surfer at mauigateway.com (Scott Weeks) Date: Mon, 18 Apr 2016 11:14:49 -0700 Subject: ASR-9K CPU troubleshooting Message-ID: <20160418111449.E7751428@m0087798.ppops.net> --- regezos at gmail.com wrote: From: Rukka Pal How do you guys troubleshoot high CPU utilization on the ASR-9K platform? Detailed guides are available for IOS platforms, but I can't seem to find anything useful for the ASR. The average line-card (0/0/CPU0: A9K-24x10GE-TR) CPU utilization of my routers is about 10%, however recently I have noticed that 3-5 times a day it increases to 40% and stays there for about an hour (20% spp + 10% netio + the rest). I know this is well withing the acceptable range, but I am the kind of person who likes to understand every change in his network and during the investigation I had to realize that I simply don't have the tools to troubleshoot the ASR CPU. ----------------------------------- On cisco: sho proc cpu scott From johnl at iecc.com Mon Apr 18 18:31:21 2016 From: johnl at iecc.com (John Levine) Date: 18 Apr 2016 18:31:21 -0000 Subject: phone fun, was GeoIP database issues and the real world consequences In-Reply-To: <20160418140652.GA73644@ussenterprise.ufp.org> Message-ID: <20160418183121.9080.qmail@ary.lan> >The other answers address the history here better than I ever good, but >I wanted to point out one example I hadn't seen mentioned. > >https://en.wikipedia.org/wiki/Area_code_917 > >917 was originally a mobile only area code overlay in New York City. >For reasons that are unclear to me, after that experiment it was >decided that the US would never do that again. The FCC found in 1999 that service-specific overlays are "unreasonably discriminatory and anti-competitive." I gather the thinking at the time was that 917 was full of pagers, voice mail, and car phones, while "real" phones were in 212. Times have changed and they're now prepared to approve an overlay in Connecticut that would cover the whole state, both area codes 203 and 860, with the new area code used for services that are not location specific, for which they give mobile phones and Onstar as examples. R's, John From faisal at snappytelecom.net Mon Apr 18 18:36:31 2016 From: faisal at snappytelecom.net (Faisal Imtiaz) Date: Mon, 18 Apr 2016 18:36:31 +0000 (GMT) Subject: Software for circuit documentation In-Reply-To: <61C208E8-7775-4F32-8372-A1BA613E59AB@beckman.org> References: <61C208E8-7775-4F32-8372-A1BA613E59AB@beckman.org> Message-ID: <2043074905.160144.1461004591716.JavaMail.zimbra@snappytelecom.net> Anyone used these folks ? Any feedback ? http://www.i-doit.com/ 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: "Mel Beckman" > To: "Eric Kuhnke" > Cc: "nanog list" > Sent: Monday, April 18, 2016 1:41:00 PM > Subject: Re: Software for circuit documentation > I?ve been meaning to get pricing for Ericsson?s Adaptive Inventory (formerly > Granite) for a mid-sized ISP client. It?s world-class, but it may turn out to > be insanely expensive. I?m also investigating cloud solutions. Most of the > legacy commercial products are stuck in the LEC/CLEC inventory regime of T1s, > T3s, and circuit grooming, with little support for MPLS, IPv6, or SLA > management. Those are the big pain points today for most ISPs grappling with > provisioning complexity. > > -mel > > >> On Apr 18, 2016, at 10:09 AM, Eric Kuhnke wrote: >> >> mediawiki set up for individual user accounts, https only access, in >> internal tool IP space/ACL/firewalled. >> >> First develop a hierarcically organized 'blank' template you can copy and >> paste for each POP, and then fill it out. Works great for large scale fiber >> patch panel assignments/crossconnect tracking, listings of equipment in a >> POP, MPLS XCs, etc. It only works properly if the persons making each OSI >> layer 1 change edit the wiki after each change (or the NOC/neteng staff >> directing the field technicians edit it at the same time as updating a work >> ticket). >> >> One of the great advantages is that it's near infinitely flexible in how >> you can lay out and arrange the page, and tracks each and every change made >> by ever user. In case of a mistake it's easy to revert to an earlier >> version. >> >> I am not so sure about its use for OSP fiber tracking which gets into the >> territory of GIS software and customized vector based diagramming software. >> >> On Mon, Apr 18, 2016 at 8:33 AM, Manuel Mar?n wrote: >> >>> Dear Nanog community >>> >>> We are looking for a network inventory software to document logical >>> circuits and fibers. We have been using Racktables for cross connects and >>> racks documentation and works great, but we did find a way to document >>> MPLS, Eline/ELAN, OTN, SONET, IP circuits, external plant (fibers), etc. >>> >>> I would appreciate if you can share what you use for documentation. >>> >>> Thank you and have a great day >>> >>> Regards From colton.conor at gmail.com Mon Apr 18 18:44:46 2016 From: colton.conor at gmail.com (Colton Conor) Date: Mon, 18 Apr 2016 13:44:46 -0500 Subject: New Switches with Broadcom StrataDNX In-Reply-To: References: <21968C2D-DCEA-4010-9E2D-31C31294D68C@gmail.com> <1EF6F817-0959-4EAE-9AD9-26984D93C5FB@gmail.com> <569F24E2.8020101@seacom.mu> Message-ID: So can this compete routing wise against something like a Juniper MX104 or Cisco ASR 9001? On Mon, Apr 18, 2016 at 1:42 PM, lincoln dale wrote: > Yes. We also have 1M+ FIB support day one too - hence the letter 'R' > denoting the evolution with 3rd generation of its evolution to internet > edge/router use cases. > > Not sure what other vendors are doing but I doubt others are yet shipping > large table support. > (there's more to it than just the underlying native silicon) > > > cheers, > > lincoln. (ltd at arista.com) > > > On Mon, Apr 18, 2016 at 11:01 AM, Colton Conor > wrote: > >> As a follow up to this post, it look like the Arista 7500R series has this >> new chip inside of it. >> >> On Wed, Jan 20, 2016 at 9:34 AM, Jeff Tantsura < >> jeff.tantsura at ericsson.com> >> wrote: >> >> > That's right, logic is in programming chips, not their property. You >> just >> > need to know what to program ;-) >> > >> > Regards, >> > Jeff >> > >> > > On Jan 19, 2016, at 10:10 PM, Mark Tinka >> wrote: >> > > >> > > >> > > >> > >> On 20/Jan/16 00:17, Phil Bedard wrote: >> > >> >> > >> Good point, there are many people looking at what I call FIB >> > optimization right now. The key is having the programmability on the >> > device to make it happen. Juniper/Cisco support it using policies to >> > filter RIB->FIB and I believe both also do per-NPU/PFE localized FIBs >> now. >> > I am not sure if that?s something supported on this new Broadcom >> chipset. >> > Depends on your network of course and where you are looking to position >> the >> > router. >> > > >> > > I don't think the FIB needs to have specific support for selective >> > > programming. >> > > >> > > I think that comes in the code to instruct the control plane what it >> > > should download to the FIB. >> > > >> > > Cisco's and Juniper's support of this is on FIB that has been in >> > > production long before the feature became available. It was just added >> > > to code. >> > > >> > > Mark. >> > >> > > From jeff.tantsura at ericsson.com Mon Apr 18 18:54:24 2016 From: jeff.tantsura at ericsson.com (Jeff Tantsura) Date: Mon, 18 Apr 2016 18:54:24 +0000 Subject: New Switches with Broadcom StrataDNX In-Reply-To: References: <21968C2D-DCEA-4010-9E2D-31C31294D68C@gmail.com> <1EF6F817-0959-4EAE-9AD9-26984D93C5FB@gmail.com> <569F24E2.8020101@seacom.mu> Message-ID: Lincoln, Why wouldn?t they? What is it Arista did others didn?t? Cheers, Jeff From: lincoln dale > Date: Monday, April 18, 2016 at 11:42 AM To: Colton Conor > Cc: Jeff Tantsura >, "nanog at nanog.org" > Subject: Re: New Switches with Broadcom StrataDNX Yes. We also have 1M+ FIB support day one too - hence the letter 'R' denoting the evolution with 3rd generation of its evolution to internet edge/router use cases. Not sure what other vendors are doing but I doubt others are yet shipping large table support. (there's more to it than just the underlying native silicon) cheers, lincoln. (ltd at arista.com) On Mon, Apr 18, 2016 at 11:01 AM, Colton Conor > wrote: As a follow up to this post, it look like the Arista 7500R series has this new chip inside of it. On Wed, Jan 20, 2016 at 9:34 AM, Jeff Tantsura > wrote: > That's right, logic is in programming chips, not their property. You just > need to know what to program ;-) > > Regards, > Jeff > > > On Jan 19, 2016, at 10:10 PM, Mark Tinka > wrote: > > > > > > > >> On 20/Jan/16 00:17, Phil Bedard wrote: > >> > >> Good point, there are many people looking at what I call FIB > optimization right now. The key is having the programmability on the > device to make it happen. Juniper/Cisco support it using policies to > filter RIB->FIB and I believe both also do per-NPU/PFE localized FIBs now. > I am not sure if that?s something supported on this new Broadcom chipset. > Depends on your network of course and where you are looking to position the > router. > > > > I don't think the FIB needs to have specific support for selective > > programming. > > > > I think that comes in the code to instruct the control plane what it > > should download to the FIB. > > > > Cisco's and Juniper's support of this is on FIB that has been in > > production long before the feature became available. It was just added > > to code. > > > > Mark. > From mttume at gmail.com Mon Apr 18 15:35:49 2016 From: mttume at gmail.com (Tum Eh) Date: Mon, 18 Apr 2016 18:35:49 +0300 Subject: Traffic forecasts In-Reply-To: References: <570F94C1.1000107@gmail.com> Message-ID: <5714FED5.4040405@gmail.com> Dear Christopher, I can see actual IP Transit traffic from Dyn. I cannot find any forecasts. BR, Tum On 18-Apr-16 4:26 PM, Christopher Morrow wrote: > doesn't dyn/renesys provide this as well? > > On Thu, Apr 14, 2016 at 9:01 AM, Tum Eh > wrote: > > Dear All, > > Do you use any source other than Telegeography in order to get > country's Internet bandwidth infos, or continent to continent > capacities etc. > > BR, > Tum > > From ltd at interlink.com.au Mon Apr 18 18:42:51 2016 From: ltd at interlink.com.au (lincoln dale) Date: Mon, 18 Apr 2016 11:42:51 -0700 Subject: New Switches with Broadcom StrataDNX In-Reply-To: References: <21968C2D-DCEA-4010-9E2D-31C31294D68C@gmail.com> <1EF6F817-0959-4EAE-9AD9-26984D93C5FB@gmail.com> <569F24E2.8020101@seacom.mu> Message-ID: Yes. We also have 1M+ FIB support day one too - hence the letter 'R' denoting the evolution with 3rd generation of its evolution to internet edge/router use cases. Not sure what other vendors are doing but I doubt others are yet shipping large table support. (there's more to it than just the underlying native silicon) cheers, lincoln. (ltd at arista.com) On Mon, Apr 18, 2016 at 11:01 AM, Colton Conor wrote: > As a follow up to this post, it look like the Arista 7500R series has this > new chip inside of it. > > On Wed, Jan 20, 2016 at 9:34 AM, Jeff Tantsura > > wrote: > > > That's right, logic is in programming chips, not their property. You just > > need to know what to program ;-) > > > > Regards, > > Jeff > > > > > On Jan 19, 2016, at 10:10 PM, Mark Tinka wrote: > > > > > > > > > > > >> On 20/Jan/16 00:17, Phil Bedard wrote: > > >> > > >> Good point, there are many people looking at what I call FIB > > optimization right now. The key is having the programmability on the > > device to make it happen. Juniper/Cisco support it using policies to > > filter RIB->FIB and I believe both also do per-NPU/PFE localized FIBs > now. > > I am not sure if that?s something supported on this new Broadcom chipset. > > Depends on your network of course and where you are looking to position > the > > router. > > > > > > I don't think the FIB needs to have specific support for selective > > > programming. > > > > > > I think that comes in the code to instruct the control plane what it > > > should download to the FIB. > > > > > > Cisco's and Juniper's support of this is on FIB that has been in > > > production long before the feature became available. It was just added > > > to code. > > > > > > Mark. > > > From jefftant.ietf at gmail.com Mon Apr 18 19:00:13 2016 From: jefftant.ietf at gmail.com (Jeff Tantsura) Date: Mon, 18 Apr 2016 12:00:13 -0700 Subject: New Switches with Broadcom StrataDNX In-Reply-To: References: <21968C2D-DCEA-4010-9E2D-31C31294D68C@gmail.com> <1EF6F817-0959-4EAE-9AD9-26984D93C5FB@gmail.com> <569F24E2.8020101@seacom.mu> Message-ID: <26CE6198-D737-4F3E-B5C9-61CB36F87E56@ericsson.com> It depends? there?s a phenomenon called ?next-hop flattening? which has to do with lookup recursiveness within the silicon. Unless this is done (and this is big piece of work) not everything supported on Trio or Ezchip can be supported. In general ? Jericho (and its followers) is a great piece of silicon made by clueful folks? watch this space closely Jeff From: Colton Conor Date: Monday, April 18, 2016 at 11:44 AM To: lincoln dale Cc: Jeff Tantsura , "nanog at nanog.org" Subject: Re: New Switches with Broadcom StrataDNX So can this compete routing wise against something like a Juniper MX104 or Cisco ASR 9001? On Mon, Apr 18, 2016 at 1:42 PM, lincoln dale wrote: Yes. We also have 1M+ FIB support day one too - hence the letter 'R' denoting the evolution with 3rd generation of its evolution to internet edge/router use cases. Not sure what other vendors are doing but I doubt others are yet shipping large table support. (there's more to it than just the underlying native silicon) cheers, lincoln. (ltd at arista.com) On Mon, Apr 18, 2016 at 11:01 AM, Colton Conor wrote: As a follow up to this post, it look like the Arista 7500R series has this new chip inside of it. On Wed, Jan 20, 2016 at 9:34 AM, Jeff Tantsura wrote: > That's right, logic is in programming chips, not their property. You just > need to know what to program ;-) > > Regards, > Jeff > > > On Jan 19, 2016, at 10:10 PM, Mark Tinka wrote: > > > > > > > >> On 20/Jan/16 00:17, Phil Bedard wrote: > >> > >> Good point, there are many people looking at what I call FIB > optimization right now. The key is having the programmability on the > device to make it happen. Juniper/Cisco support it using policies to > filter RIB->FIB and I believe both also do per-NPU/PFE localized FIBs now. > I am not sure if that?s something supported on this new Broadcom chipset. > Depends on your network of course and where you are looking to position the > router. > > > > I don't think the FIB needs to have specific support for selective > > programming. > > > > I think that comes in the code to instruct the control plane what it > > should download to the FIB. > > > > Cisco's and Juniper's support of this is on FIB that has been in > > production long before the feature became available. It was just added > > to code. > > > > Mark. > From saku at ytti.fi Tue Apr 19 00:15:07 2016 From: saku at ytti.fi (Saku Ytti) Date: Tue, 19 Apr 2016 03:15:07 +0300 Subject: New Switches with Broadcom StrataDNX In-Reply-To: References: <21968C2D-DCEA-4010-9E2D-31C31294D68C@gmail.com> <1EF6F817-0959-4EAE-9AD9-26984D93C5FB@gmail.com> <569F24E2.8020101@seacom.mu> Message-ID: On 18 April 2016 at 21:44, Colton Conor wrote: Hey, > So can this compete routing wise against something like a Juniper MX104 or > Cisco ASR 9001? Super broad question. Generally they are not targeting same applications. MX104 (Trio) and ASR9001 (EZchip) are high-touch chips, where-as Jeiricho is low-touch chip. What it can do, it can do fast and economically. -- ++ytti From colton.conor at gmail.com Tue Apr 19 14:54:56 2016 From: colton.conor at gmail.com (Colton Conor) Date: Tue, 19 Apr 2016 09:54:56 -0500 Subject: Software for circuit documentation In-Reply-To: References: Message-ID: You might want to check out http://www.gokadence.com/products-services/circuits/ I have seen a demo of their software, and was impressed. Honestly I would want something with an integrated GIS component. 3-GIS seems to be the leading GIS for telecom. On Mon, Apr 18, 2016 at 10:33 AM, Manuel Mar?n wrote: > Dear Nanog community > > We are looking for a network inventory software to document logical > circuits and fibers. We have been using Racktables for cross connects and > racks documentation and works great, but we did find a way to document > MPLS, Eline/ELAN, OTN, SONET, IP circuits, external plant (fibers), etc. > > I would appreciate if you can share what you use for documentation. > > Thank you and have a great day > > Regards > From admin at coldnorthadmin.com Tue Apr 19 23:06:08 2016 From: admin at coldnorthadmin.com (Laurent Dumont) Date: Tue, 19 Apr 2016 19:06:08 -0400 Subject: ASR-9K CPU troubleshooting In-Reply-To: <20160418111449.E7751428@m0087798.ppops.net> References: <20160418111449.E7751428@m0087798.ppops.net> Message-ID: <5716B9E0.6080803@coldnorthadmin.com> It coincides with nothing else? More traffic? CPU increasing at regular intervals every day without any obvious reasons is probably something worth looking into! On 4/18/2016 2:14 PM, Scott Weeks wrote: > > --- regezos at gmail.com wrote: > From: Rukka Pal > > How do you guys troubleshoot high CPU utilization on the ASR-9K platform? > Detailed guides are available for IOS platforms, but I can't seem to find > anything useful for the ASR. > > The average line-card (0/0/CPU0: A9K-24x10GE-TR) CPU utilization of my > routers is about 10%, however recently I have noticed that 3-5 times a day > it increases to 40% and stays there for about an hour (20% spp + 10% netio > + the rest). > > I know this is well withing the acceptable range, but I am the kind of > person who likes to understand every change in his network and during the > investigation I had to realize that I simply don't have the tools to > troubleshoot the ASR CPU. > ----------------------------------- > > > On cisco: sho proc cpu > > scott From micahcroff at gmail.com Tue Apr 19 23:17:00 2016 From: micahcroff at gmail.com (Micah Croff) Date: Tue, 19 Apr 2016 16:17:00 -0700 Subject: ASR-9K CPU troubleshooting In-Reply-To: <5716B9E0.6080803@coldnorthadmin.com> References: <20160418111449.E7751428@m0087798.ppops.net> <5716B9E0.6080803@coldnorthadmin.com> Message-ID: I've experienced similar behavior on other platforms as well. Sometimes the output of the box is not correct. We were able to prove this to the vendor by conducting experiments and graphing the CPU. One of the protocols they said "couldn't possibly be causing this" turned out to be the root of the problem. I live by one rule when troubleshooting: The box is a lie. Micah On Tue, Apr 19, 2016 at 4:06 PM, Laurent Dumont wrote: > It coincides with nothing else? More traffic? CPU increasing at regular > intervals every day without any obvious reasons is probably something worth > looking into! > > On 4/18/2016 2:14 PM, Scott Weeks wrote: > >> >> --- regezos at gmail.com wrote: >> From: Rukka Pal >> >> How do you guys troubleshoot high CPU utilization on the ASR-9K platform? >> Detailed guides are available for IOS platforms, but I can't seem to find >> anything useful for the ASR. >> >> The average line-card (0/0/CPU0: A9K-24x10GE-TR) CPU utilization of my >> routers is about 10%, however recently I have noticed that 3-5 times a day >> it increases to 40% and stays there for about an hour (20% spp + 10% netio >> + the rest). >> >> I know this is well withing the acceptable range, but I am the kind of >> person who likes to understand every change in his network and during the >> investigation I had to realize that I simply don't have the tools to >> troubleshoot the ASR CPU. >> ----------------------------------- >> >> >> On cisco: sho proc cpu >> >> scott >> > > From jfmezei_nanog at vaxination.ca Wed Apr 20 01:29:12 2016 From: jfmezei_nanog at vaxination.ca (Jean-Francois Mezei) Date: Tue, 19 Apr 2016 21:29:12 -0400 Subject: Latency, TCP ACKs and upload needs Message-ID: <5716DB68.1080801@vaxination.ca> As part of the ongoing CRTC hearings, the incumbents' claim that continued implementation of the current 5/1 standard would make Canada a world leader for broadband in the future. A satellite company who currently can't even deliver its advertised 5/1 now brags its next satellite will deliver 25/1. So I have a few questions: Considering a single download TCP connection. I am aware that modern TCP stacks will rationalize ACKs and send 1 ACK for every x packets received, thus reducing upload bandwidth requirements. Is this basically widespread and assumed that everyone has that ? Also, as you split available bandwidth between multiple streams, won't ack upload requirements increase because ACK rationalisation happens far less often sicne each TCP connection has its own context for ACKs? When one considers the added latency of satellite links, does 25/1 make sense ? (I need a sanity check to distinguish between marketing spin presented to the regulator and real life) I noticed that in the USA, EXEDE Satellite advertises 12/3 plans and they are also on a VIA Sat satellite, presumably the same vehicle that Xplornet tries to deliver its measly 5/1 on. Would all beams be identical on a satellite or can they be configured differently with a ISP adjustable rate of upload/download inside the same spectrum ? Also, when you establish a TCP connection, do most stacks have a default window size that gives the sender enough "patience" to wait long enough for the ACK ? If sender sends packet 457, doesn't get ACK in time and resends 457, doesn't that also result in reduction in window size (the very opposite of what would be needed in high latency links) ? And when the first ACK finally arrives, won't the sender assume this ACK was for the resent 457 ? Or is satellite latency low enough that stacks all have enough default "patience" to wait for ACKs and this is a non issue ? (Note Xplornet refused to answer questions on whether they operate special proxies at their gound stations to manage TCP connections to appear "close"). What i am trying to get at here is whether 25/1 on satellite, in real life with a few apps exchanging data, would actually be able to make use of the 25 download speed or whether the limited 1mbps upload would choke the downloads ? From jared at puck.nether.net Wed Apr 20 01:44:23 2016 From: jared at puck.nether.net (Jared Mauch) Date: Tue, 19 Apr 2016 21:44:23 -0400 Subject: Latency, TCP ACKs and upload needs In-Reply-To: <5716DB68.1080801@vaxination.ca> References: <5716DB68.1080801@vaxination.ca> Message-ID: > On Apr 19, 2016, at 9:29 PM, Jean-Francois Mezei wrote: > > As part of the ongoing CRTC hearings, the incumbents' claim that > continued implementation of the current 5/1 standard would make Canada a > world leader for broadband in the future. > > A satellite company who currently can't even deliver its advertised 5/1 > now brags its next satellite will deliver 25/1. > > So I have a few questions: > > Considering a single download TCP connection. I am aware that modern TCP > stacks will rationalize ACKs and send 1 ACK for every x packets > received, thus reducing upload bandwidth requirements. Is this basically > widespread and assumed that everyone has that ? > > Also, as you split available bandwidth between multiple streams, won't > ack upload requirements increase because ACK rationalisation happens far > less often sicne each TCP connection has its own context for ACKs? There?s a lot of dynamics here, including how long lived the TCP session is, the windowing behavior of the host/servers and any acceleration done in the path. There is also TCP Selective ACK which means you don?t need to explicitly ACK each frame. I?m not specifically knowledgeable about how this performs with earth to orbit and back dynamics, and hope to never personally need to debug it :) I have used satellite based internet over the atlantic ocean before and it didn?t seem that bad aside from the pricing involved. I would expect that if all endpoints are doing the right TCP options you will see reasonable performance. Make sure nobody is masking the window scaling options and such. (I have heard some carriers do this to prevent the window from getting too large). - Jared From eric.kuhnke at gmail.com Wed Apr 20 02:01:10 2016 From: eric.kuhnke at gmail.com (Eric Kuhnke) Date: Tue, 19 Apr 2016 19:01:10 -0700 Subject: Latency, TCP ACKs and upload needs In-Reply-To: <5716DB68.1080801@vaxination.ca> References: <5716DB68.1080801@vaxination.ca> Message-ID: One of the things to consider is that geostationary satellite operators operate based entirely on the economics of oversubscription. If you were to purchase a full duplex 1 Mbps x 1 Mbps connection via VSAT terminal in North America (whether C, Ku or Ka-band) you'd be looking at $2000/month or more. You'd have a fixed FDD pipe at 495ms latency end to end. 32:1 oversubscription or more is normal. It costs close to $150 million to build and launch a 5000 kilogram satellite into geostationary orbit before you build any teleport infrastructure. The entire satellite has far less aggregate data throughput capacity than two strands of singlemode. Modern Ka-band satellites as used by consumer grade VSAT services in the United States use dozens of individual spot beams. The FDD capacity in each spot beam may be exhausted or significantly oversubscribed in one geographical region, yet relatively unused in others. Compare, for example, real world user reported speeds at 10pm on Exede service in western WA state vs. somewhere in a very rural part of Wyoming. Spot beam TDMA contention ratios are carefully managed by satellite operators - they're very much aware of the issue you describe, and do their best to mitigate it. Extensive massaging of TDMA parameters in spot beams is the only way that it's economical to offer service for between $75 to $150/month even with a 2 or 3 year contract. There are a number of physics, OSI layer 1 and 2 issues to consider with satellite before discussing anything TCP related. On Tue, Apr 19, 2016 at 6:29 PM, Jean-Francois Mezei < jfmezei_nanog at vaxination.ca> wrote: > As part of the ongoing CRTC hearings, the incumbents' claim that > continued implementation of the current 5/1 standard would make Canada a > world leader for broadband in the future. > > A satellite company who currently can't even deliver its advertised 5/1 > now brags its next satellite will deliver 25/1. > > So I have a few questions: > > Considering a single download TCP connection. I am aware that modern TCP > stacks will rationalize ACKs and send 1 ACK for every x packets > received, thus reducing upload bandwidth requirements. Is this basically > widespread and assumed that everyone has that ? > > Also, as you split available bandwidth between multiple streams, won't > ack upload requirements increase because ACK rationalisation happens far > less often sicne each TCP connection has its own context for ACKs? > > When one considers the added latency of satellite links, does 25/1 make > sense ? (I need a sanity check to distinguish between marketing spin > presented to the regulator and real life) > > I noticed that in the USA, EXEDE Satellite advertises 12/3 plans and > they are also on a VIA Sat satellite, presumably the same vehicle that > Xplornet tries to deliver its measly 5/1 on. Would all beams be > identical on a satellite or can they be configured differently with a > ISP adjustable rate of upload/download inside the same spectrum ? > > > > > Also, when you establish a TCP connection, do most stacks have a default > window size that gives the sender enough "patience" to wait long enough > for the ACK ? > > If sender sends packet 457, doesn't get ACK in time and resends 457, > doesn't that also result in reduction in window size (the very opposite > of what would be needed in high latency links) ? > > And when the first ACK finally arrives, won't the sender assume this ACK > was for the resent 457 ? Or is satellite latency low enough that > stacks all have enough default "patience" to wait for ACKs and this is a > non issue ? > > (Note Xplornet refused to answer questions on whether they operate > special proxies at their gound stations to manage TCP connections to > appear "close"). > > > > What i am trying to get at here is whether 25/1 on satellite, in real > life with a few apps exchanging data, would actually be able to make use > of the 25 download speed or whether the limited 1mbps upload would choke > the downloads ? > > From joelja at bogus.com Wed Apr 20 02:03:51 2016 From: joelja at bogus.com (joel jaeggli) Date: Tue, 19 Apr 2016 19:03:51 -0700 Subject: Latency, TCP ACKs and upload needs In-Reply-To: <5716DB68.1080801@vaxination.ca> References: <5716DB68.1080801@vaxination.ca> Message-ID: <23cd987c-7abb-b055-9453-cbe351c4279f@bogus.com> On 4/19/16 6:29 PM, Jean-Francois Mezei wrote: > As part of the ongoing CRTC hearings, the incumbents' claim that > continued implementation of the current 5/1 standard would make Canada a > world leader for broadband in the future. > > A satellite company who currently can't even deliver its advertised 5/1 > now brags its next satellite will deliver 25/1. > > So I have a few questions: > > Considering a single download TCP connection. I am aware that modern TCP > stacks will rationalize ACKs and send 1 ACK for every x packets > received, thus reducing upload bandwidth requirements. Is this basically > widespread and assumed that everyone has that ? with an mss of 1460 the inbound packets for reasonably well packed flow will be 36.5x larger than the acks which are 40 bytes. sack rfc 2018 means you don't have to acknowledge all of the inbound packets. > Also, as you split available bandwidth between multiple streams, won't > ack upload requirements increase because ACK rationalisation happens far > less often sicne each TCP connection has its own context for ACKs? > > When one considers the added latency of satellite links, does 25/1 make > sense ? (I need a sanity check to distinguish between marketing spin > presented to the regulator and real life) satellite vendors use various forms of tcp acceleration which may involve among other things having middle boxes that pre-emptively send the ack, play with the window size etc. > I noticed that in the USA, EXEDE Satellite advertises 12/3 plans and > they are also on a VIA Sat satellite, presumably the same vehicle that > Xplornet tries to deliver its measly 5/1 on. Would all beams be > identical on a satellite or can they be configured differently with a > ISP adjustable rate of upload/download inside the same spectrum ? > > > > > Also, when you establish a TCP connection, do most stacks have a default > window size that gives the sender enough "patience" to wait long enough > for the ACK ? retransmission timeouts are typically measure in seconds... https://tools.ietf.org/html/rfc6298 and geostationary orbits typically have RTTs under 800ms. > If sender sends packet 457, doesn't get ACK in time and resends 457, > doesn't that also result in reduction in window size (the very opposite > of what would be needed in high latency links) ? > > And when the first ACK finally arrives, won't the sender assume this ACK > was for the resent 457 ? Or is satellite latency low enough that > stacks all have enough default "patience" to wait for ACKs and this is a > non issue ? > > (Note Xplornet refused to answer questions on whether they operate > special proxies at their gound stations to manage TCP connections to > appear "close"). seems likely > > > What i am trying to get at here is whether 25/1 on satellite, in real > life with a few apps exchanging data, would actually be able to make use > of the 25 download speed or whether the limited 1mbps upload would choke > the downloads ? > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 229 bytes Desc: OpenPGP digital signature URL: From eric.kuhnke at gmail.com Wed Apr 20 02:11:09 2016 From: eric.kuhnke at gmail.com (Eric Kuhnke) Date: Tue, 19 Apr 2016 19:11:09 -0700 Subject: Latency, TCP ACKs and upload needs In-Reply-To: <23cd987c-7abb-b055-9453-cbe351c4279f@bogus.com> References: <5716DB68.1080801@vaxination.ca> <23cd987c-7abb-b055-9453-cbe351c4279f@bogus.com> Message-ID: a geostationary orbit based connection will have a minimum latency of 492-495ms in a dedicated-carrier configuration between two earth stations, varying very slightly with the modem overhead time for FEC. In a TDMA network all bets are off, if you're in wyoming on exede and everyone is asleep, you could see very close to 500ms, you could also see 1200ms during peak hours. Or worse. Consumer grade satellite operators have only the blunt force tool of GB quota/month to prevent the TDMA capacity in a particular spotbeam from becoming a complete wasteland of modems stepping on each other (effectively reducing everyone to 32kbps or worse, and 2000ms). Go over 8 or 10GB/month and you either need to pay a lot more money, or go in the TDMA penalty box for $TIME. As usage patterns tend to rise and fall in a sine wave pattern not very different than a 10GbE circuit feeding a huge number of downstream DSL customers, many operators offer 'free' late night/evening hours that don't count towards the quota. Example: http://www.exede.com/the-free-zone-internet-details/ On Tue, Apr 19, 2016 at 7:03 PM, joel jaeggli wrote: > On 4/19/16 6:29 PM, Jean-Francois Mezei wrote: > > As part of the ongoing CRTC hearings, the incumbents' claim that > > continued implementation of the current 5/1 standard would make Canada a > > world leader for broadband in the future. > > > > A satellite company who currently can't even deliver its advertised 5/1 > > now brags its next satellite will deliver 25/1. > > > > So I have a few questions: > > > > Considering a single download TCP connection. I am aware that modern TCP > > stacks will rationalize ACKs and send 1 ACK for every x packets > > received, thus reducing upload bandwidth requirements. Is this basically > > widespread and assumed that everyone has that ? > > with an mss of 1460 the inbound packets for reasonably well packed flow > will be 36.5x larger than the acks which are 40 bytes. > > sack rfc 2018 means you don't have to acknowledge all of the inbound > packets. > > > Also, as you split available bandwidth between multiple streams, won't > > ack upload requirements increase because ACK rationalisation happens far > > less often sicne each TCP connection has its own context for ACKs? > > > > When one considers the added latency of satellite links, does 25/1 make > > sense ? (I need a sanity check to distinguish between marketing spin > > presented to the regulator and real life) > > satellite vendors use various forms of tcp acceleration which may > involve among other things having middle boxes that pre-emptively send > the ack, play with the window size etc. > > > I noticed that in the USA, EXEDE Satellite advertises 12/3 plans and > > they are also on a VIA Sat satellite, presumably the same vehicle that > > Xplornet tries to deliver its measly 5/1 on. Would all beams be > > identical on a satellite or can they be configured differently with a > > ISP adjustable rate of upload/download inside the same spectrum ? > > > > > > > > > > Also, when you establish a TCP connection, do most stacks have a default > > window size that gives the sender enough "patience" to wait long enough > > for the ACK ? > > retransmission timeouts are typically measure in seconds... > > https://tools.ietf.org/html/rfc6298 > > and geostationary orbits typically have RTTs under 800ms. > > > If sender sends packet 457, doesn't get ACK in time and resends 457, > > doesn't that also result in reduction in window size (the very opposite > > of what would be needed in high latency links) ? > > > > And when the first ACK finally arrives, won't the sender assume this ACK > > was for the resent 457 ? Or is satellite latency low enough that > > stacks all have enough default "patience" to wait for ACKs and this is a > > non issue ? > > > > (Note Xplornet refused to answer questions on whether they operate > > special proxies at their gound stations to manage TCP connections to > > appear "close"). > > seems likely > > > > > > > What i am trying to get at here is whether 25/1 on satellite, in real > > life with a few apps exchanging data, would actually be able to make use > > of the 25 download speed or whether the limited 1mbps upload would choke > > the downloads ? > > > > > From regezos at gmail.com Wed Apr 20 13:02:01 2016 From: regezos at gmail.com (Rukka Pal) Date: Wed, 20 Apr 2016 15:02:01 +0200 Subject: ASR-9K CPU troubleshooting In-Reply-To: References: <20160418111449.E7751428@m0087798.ppops.net> <5716B9E0.6080803@coldnorthadmin.com> Message-ID: This document (BRKARC-2017) turned out to be very useful to determine the possible root-cause. The utilization of the spp and netio processes increase if the router/line-card is software switching traffic, in our case ICMP. We will test the policing feature and implement it. On Wed, Apr 20, 2016 at 1:17 AM, Micah Croff wrote: > I've experienced similar behavior on other platforms as well. Sometimes > the output of the box is not correct. We were able to prove this to the > vendor by conducting experiments and graphing the CPU. One of the > protocols they said "couldn't possibly be causing this" turned out to be > the root of the problem. > > I live by one rule when troubleshooting: > The box is a lie. > > Micah > > > On Tue, Apr 19, 2016 at 4:06 PM, Laurent Dumont > wrote: > > > It coincides with nothing else? More traffic? CPU increasing at regular > > intervals every day without any obvious reasons is probably something > worth > > looking into! > > > > On 4/18/2016 2:14 PM, Scott Weeks wrote: > > > >> > >> --- regezos at gmail.com wrote: > >> From: Rukka Pal > >> > >> How do you guys troubleshoot high CPU utilization on the ASR-9K > platform? > >> Detailed guides are available for IOS platforms, but I can't seem to > find > >> anything useful for the ASR. > >> > >> The average line-card (0/0/CPU0: A9K-24x10GE-TR) CPU utilization of my > >> routers is about 10%, however recently I have noticed that 3-5 times a > day > >> it increases to 40% and stays there for about an hour (20% spp + 10% > netio > >> + the rest). > >> > >> I know this is well withing the acceptable range, but I am the kind of > >> person who likes to understand every change in his network and during > the > >> investigation I had to realize that I simply don't have the tools to > >> troubleshoot the ASR CPU. > >> ----------------------------------- > >> > >> > >> On cisco: sho proc cpu > >> > >> scott > >> > > > > > From bicknell at ufp.org Wed Apr 20 14:27:53 2016 From: bicknell at ufp.org (Leo Bicknell) Date: Wed, 20 Apr 2016 07:27:53 -0700 Subject: Latency, TCP ACKs and upload needs In-Reply-To: <5716DB68.1080801@vaxination.ca> References: <5716DB68.1080801@vaxination.ca> Message-ID: <20160420142753.GA58668@ussenterprise.ufp.org> Others have already answered with the technical details. Let me take a stab at some more, uh, variable items. In a message written on Tue, Apr 19, 2016 at 09:29:12PM -0400, Jean-Francois Mezei wrote: > Also, when you establish a TCP connection, do most stacks have a default > window size that gives the sender enough "patience" to wait long enough > for the ACK ? Your question is phrased backwards. All will wait for the ACK, the timeouts are long (30-120 seconds). The issue is that you only get one window of data per RTT, so if the window is too small, it will choke the connection. 90%+ of the stacks deployed will be too small. Modern Unix generally has "autotuning" TCP stacks, but I don't think Windows or OS X has those features yet (but I'd be very happy to be wrong on that point). Regardless of satellite uplink/downlink speeds, boxes generally need to be tuned to get maximum performance on satellite. > What i am trying to get at here is whether 25/1 on satellite, in real > life with a few apps exchanging data, would actually be able to make use > of the 25 download speed or whether the limited 1mbps upload would choke > the downloads ? With a properly tuned stack what you're describing is not a problem. 1460 byte payloads down, maybe 64 byte acks on the return, and with SACK which is widely deployed an ACK every 2-4 packets. You would see about 2,140 packets/sec downstream (25Mbps/1460), and perhaps send 1070 ACKs back upstream, at 64 bytes each, or about 68Kbps. Well under the 1Mbps upstream bandwidth. -- Leo Bicknell - bicknell at ufp.org PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 811 bytes Desc: not available URL: From colton.conor at gmail.com Wed Apr 20 14:37:57 2016 From: colton.conor at gmail.com (Colton Conor) Date: Wed, 20 Apr 2016 09:37:57 -0500 Subject: Arista Routing Solutions Message-ID: NANOG, I know Arista is typically a switch manufacturer, but with their recently announced Arista 7500R Series and soon to be announced but already shipping 7280R Series Arista is officially getting into the routing game. The fixed 1U 7280R Series looks quite impressive. The 7500R series is your traditional chassis and line card based solution. Both of these products have the ability to hold the full internet routing table, and Arista is working on MPLS features. Both of these new products use the latest Broadcom Jerico chipsets. I would like to know how viable of a product NANOG thinks these Arista routers are compared to service provider grade routers from Cisco, Juniper, ALU, and Brocade? Cost wise, Arista seems to be much, much less per port. For example, the 1U Arista 7280R with 48x10GbE (SFP+) & 6x100GbE QSFP cost about the same as what Juniper sells a MX104 with only four 10G ports for (Under 20K). Can the Arista EOS software combine with their hardware based on the Broadcom Jericho chipset truly compete with the custom chipsets and accompanying software from the big guys? From owen at delong.com Wed Apr 20 14:52:29 2016 From: owen at delong.com (Owen DeLong) Date: Wed, 20 Apr 2016 07:52:29 -0700 Subject: phone fun, was GeoIP database issues and the real world consequences In-Reply-To: <20160415212138.29C9146BF6E3@rock.dv.isc.org> References: <20160414153236.GA88366@ussenterprise.ufp.org> <570ED607.1070607@cox.net> <20160414002939.15867.qmail@ary.lan> <1460710177.364730809@apps.rackspace.com> <571105A6.3040607@nvcube.net> <20160415190936.043B346BE4B9@rock.dv.isc.org> <20160415212138.29C9146BF6E3@rock.dv.isc.org> Message-ID: <2CA30D4F-24F0-4E92-A633-31BF20A78B17@delong.com> > On Apr 15, 2016, at 2:21 PM, Mark Andrews wrote: > > > In message , David Barak writes > : >>> On Apr 15, 2016, at 3:09 PM, Mark Andrews wrote: >>> >>> Australia is about the area as the US and has always had caller >>> pays and seperate area codes for mobiles. >> >> Australia has fewer people than Texas, and is more than an order of >> magnitude smaller than the US by population. Effects of scale apply here >> in terms of path dependence for solutions. >> >> David Barak >> Sent from mobile device, please excuse autocorrection artifacts > > NA has a 10 digit scheme (3 area code - 7 local) though most of the > time you end up dialing the 10 digits. Not an entirely accurate description. In fact, in the US, it?s more of a 3-tier mechanism? 3 area code, 3 prefix, 4 local. As a general rule, a prefix exists within a single CO (modulo cutouts for LNP, etc.). There are usually multiple prefixes per CO since most COs serve significantly more than 10,000 numbers. In the US, Area codes do not cross state lines and in most cases do not cross LATA boundaries, either. For the most part, ?long distance? calls within the US are a thing of the past and at least one mobile carrier now treats US/CA/MX as a single local calling area (calls to/from anywhere in those three countries are the same price (generally included/free) as calls between two phones standing next to each other. > > Australia has a 9 digit scheme (1 area code - 8 local) > > Yes the area codes are huge (multi-state) and some "local" calls > are sometimes long distance. In my lifetime local calls have gone > from 6 digits to 7 and then 8 digits. The last change got rid of > lots of area codes and expanded all the local numbers to 8 digits. > This allows you to use what was a Canberra number in Sydney as they > are now all in the same area code. Canberra and Sydney are a 3 > hour drive apart. > > We are no longer in a age where we need to route calls on a digit > by digit basis. While this is true, there are still significant differences in scale and cost structures between AU and US. Owen From jfmezei_nanog at vaxination.ca Wed Apr 20 14:59:30 2016 From: jfmezei_nanog at vaxination.ca (Jean-Francois Mezei) Date: Wed, 20 Apr 2016 10:59:30 -0400 Subject: phone fun, was GeoIP database issues and the real world consequences In-Reply-To: <2CA30D4F-24F0-4E92-A633-31BF20A78B17@delong.com> References: <20160414153236.GA88366@ussenterprise.ufp.org> <570ED607.1070607@cox.net> <20160414002939.15867.qmail@ary.lan> <1460710177.364730809@apps.rackspace.com> <571105A6.3040607@nvcube.net> <20160415190936.043B346BE4B9@rock.dv.isc.org> <20160415212138.29C9146BF6E3@rock.dv.isc.org> <2CA30D4F-24F0-4E92-A633-31BF20A78B17@delong.com> Message-ID: <57179952.8040706@vaxination.ca> On 2016-04-20 10:52, Owen DeLong wrote: > For the most part, ?long distance? calls within the US are a thing of the > past and at least one mobile carrier now treats US/CA/MX as a single > local calling area Is this a case of telcos having switched to IP trunks and can reach other carriers for "free" Or are wholesale long distance still billed between carriers but at prices so low that they can afford to offer "free" long distance at retail level ? From ler762 at gmail.com Wed Apr 20 15:08:59 2016 From: ler762 at gmail.com (Lee) Date: Wed, 20 Apr 2016 11:08:59 -0400 Subject: Latency, TCP ACKs and upload needs In-Reply-To: <5716DB68.1080801@vaxination.ca> References: <5716DB68.1080801@vaxination.ca> Message-ID: On 4/19/16, Jean-Francois Mezei wrote: > As part of the ongoing CRTC hearings, the incumbents' claim that > continued implementation of the current 5/1 standard would make Canada a > world leader for broadband in the future. > > A satellite company who currently can't even deliver its advertised 5/1 > now brags its next satellite will deliver 25/1. Take a look at https://www.rfc-editor.org/rfc/rfc3449.txt TCP Performance Implications of Network Path Asymmetry > So I have a few questions: > > Considering a single download TCP connection. I am aware that modern TCP > stacks will rationalize ACKs and send 1 ACK for every x packets > received, thus reducing upload bandwidth requirements. Is this basically > widespread and assumed that everyone has that ? The usual defaults are to ack every other packet & wait 200ms before acking a single packet. > Also, as you split available bandwidth between multiple streams, won't > ack upload requirements increase because ACK rationalisation happens far > less often sicne each TCP connection has its own context for ACKs? Yes. And multiple streams will interfere with each other. It used to be popular to split a download into multiple streams but I thought that went out of style now that tcp window scaling is generally enabled by default. > When one considers the added latency of satellite links, does 25/1 make > sense ? (I need a sanity check to distinguish between marketing spin > presented to the regulator and real life) > > I noticed that in the USA, EXEDE Satellite advertises 12/3 plans and > they are also on a VIA Sat satellite, presumably the same vehicle that > Xplornet tries to deliver its measly 5/1 on. Would all beams be > identical on a satellite or can they be configured differently with a > ISP adjustable rate of upload/download inside the same spectrum ? > > > > > Also, when you establish a TCP connection, do most stacks have a default > window size that gives the sender enough "patience" to wait long enough > for the ACK ? There's an initial timeout that's on the order of 3-5 seconds. Once the xfer starts ... I've forgotten the details, but the retransmission timer is based on the "smoothed round trip time" (srtt). > If sender sends packet 457, doesn't get ACK in time and resends 457, > doesn't that also result in reduction in window size (the very opposite > of what would be needed in high latency links) ? The window size is what the receiver advertises, the congestion window (cwnd) is what the sender computes based on the advertised window size & packet loss. cwnd is what gets reduced when there's packet loss. & yes, reducing cwnd is bad for thruput as is not having selective acks (sack) enabled on the receiver. > And when the first ACK finally arrives, won't the sender assume this ACK > was for the resent 457 ? The sender keeps track of the 'smoothed round trip time' (srtt). Since it can't tell if the ack is for the original or retransmitted pkt, it's not supposed to use that ack for updating the rtt > Or is satellite latency low enough that > stacks all have enough default "patience" to wait for ACKs and this is a > non issue ? should be a non-issue > (Note Xplornet refused to answer questions on whether they operate > special proxies at their gound stations to manage TCP connections to > appear "close"). > > > > What i am trying to get at here is whether 25/1 on satellite, in real > life with a few apps exchanging data, would actually be able to make use > of the 25 download speed or whether the limited 1mbps upload would choke > the downloads ? dunno. Assuming the bandwidth is available, I suspect you could get 25Mb/s doing something like downloading a movie from archive.org but for anything interactive like web surfing / gaming I'd bet no - but because of latency, not the 1Mb/s uplink speed. Regards, Lee From owen at delong.com Wed Apr 20 15:15:19 2016 From: owen at delong.com (Owen DeLong) Date: Wed, 20 Apr 2016 08:15:19 -0700 Subject: phone fun, was GeoIP database issues and the real world consequences In-Reply-To: <57179952.8040706@vaxination.ca> References: <20160414153236.GA88366@ussenterprise.ufp.org> <570ED607.1070607@cox.net> <20160414002939.15867.qmail@ary.lan> <1460710177.364730809@apps.rackspace.com> <571105A6.3040607@nvcube.net> <20160415190936.043B346BE4B9@rock.dv.isc.org> <20160415212138.29C9146BF6E3@rock.dv.isc.org> <2CA30D4F-24F0-4E92-A633-31BF20A78B17@delong.com> <57179952.8040706@vaxination.ca> Message-ID: > On Apr 20, 2016, at 7:59 AM, Jean-Francois Mezei wrote: > > On 2016-04-20 10:52, Owen DeLong wrote: > >> For the most part, ?long distance? calls within the US are a thing of the >> past and at least one mobile carrier now treats US/CA/MX as a single >> local calling area > > > Is this a case of telcos having switched to IP trunks and can reach > other carriers for "free" > > Or are wholesale long distance still billed between carriers but at > prices so low that they can afford to offer "free" long distance at > retail level ? I think it boiled down to a recognition that the costs of billing were beginning to account for something like $0.99 of every $1 billed. Owen From johnl at iecc.com Wed Apr 20 15:20:23 2016 From: johnl at iecc.com (John Levine) Date: 20 Apr 2016 15:20:23 -0000 Subject: phone fun, was GeoIP database issues and the real world consequences In-Reply-To: <57179952.8040706@vaxination.ca> Message-ID: <20160420152023.17423.qmail@ary.lan> >> For the most part, ?long distance? calls within the US are a thing of the >> past and at least one mobile carrier now treats US/CA/MX as a single >> local calling area > >Is this a case of telcos having switched to IP trunks and can reach >other carriers for "free" No, it's because fiber bandwidth is so cheap. It's equally cheap whether the framing is ATM or IP. >Or are wholesale long distance still billed between carriers but at >prices so low that they can afford to offer "free" long distance at >retail level ? Some of each. Some carriers do reciprocal compensation at very low rates, small fractions of a cent per minute, some do bill and keep with no settlements at all. The history of settlements is closely tied to the history of the Internet. Before the Bell breakup separations (within Bell) and settlements (between Bell and independents) were uncontentious, moving money around to make the rate of return on invested capital at each carrier come out right. Then when cell phones were new, the Bell companies observed that traffic was highly imbalanced, far more cell->landline than the other way, so they demanded high reciprocal compensation, and the cellcos were willing to pay since it gave the Bells the incentive to build the interconnecting trunks. One of Verizon's predecessors famously derided "bilk and keep." Then the dialup Internet became a big thing, the Bells ignored it as a passing fad (which it was, but not for the reasons they thought), and CLECs realized they could build modem banks and make a lot of money from the incoming calls from Bell customers to the modems. So the Bells did a pirouette and suddenly discovered that bill and keep was a law of nature and recip comp was a quaint artifact that needed to be snuffed out as fast as possible. These days the FCC likes to see cost justifications for settlements, and the actual per-minute cost of calls is tiny compared to the fixed costs of the links and equipment. The main place where you see settlements is to tiny local telcos with very high costs, with the per minute payments a deliberate subsidy to them. Then some greedy little telcos added conference call lines to pump up their incoming traffic ... R's, John From jfmezei_nanog at vaxination.ca Wed Apr 20 15:26:03 2016 From: jfmezei_nanog at vaxination.ca (Jean-Francois Mezei) Date: Wed, 20 Apr 2016 11:26:03 -0400 Subject: Latency, TCP ACKs and upload needs In-Reply-To: <20160420142753.GA58668@ussenterprise.ufp.org> References: <5716DB68.1080801@vaxination.ca> <20160420142753.GA58668@ussenterprise.ufp.org> Message-ID: <57179F8B.4060804@vaxination.ca> Thanks to all for the sanity check. Always depressing when you think you may have a good argument but after much reading, you find out you don't :-( BTW, in case someone knows. With the recent "beam" satellites having a lot of different focused antennas, how does the uplink work ? Does all traffic pass through a central "switch" which then directs packets to the approperiate antenna ? Would a each beam directed at a served area be paired with its own dedicated beam directed at ground station ? Or does the uplink from ground station carry traffic for multiple beams and thus becomes the bottleneck ? (Xplornet bragged about its next satellite having 20gbps capacity, but IF the uplink from ground station is also at 20gps and serves 5 beams aimed at Canada, then on average each beam only gets 4gbps ?) With regards to the "dream" of having 350 low orbit satellites covering the globe for Internet, does anyone know how the uplink will be done? Won't there be a bottleneck if in serving Canada's north, satellites currently speeding over the region have to use satellite-to-satellite links to carry information until it reaches a satellite that is over a ground station in the south ? or is it expected that ground stations will be built "near" each area to be served ? (Am trying to justify that satellite should be reserved for people truly isolated and that Nunavut communities should get undersea fibre and work need to start now because of long construction times during which satellites will fall further back in terms of capacity needs). From ler762 at gmail.com Wed Apr 20 15:37:03 2016 From: ler762 at gmail.com (Lee) Date: Wed, 20 Apr 2016 11:37:03 -0400 Subject: Latency, TCP ACKs and upload needs In-Reply-To: <20160420142753.GA58668@ussenterprise.ufp.org> References: <5716DB68.1080801@vaxination.ca> <20160420142753.GA58668@ussenterprise.ufp.org> Message-ID: On 4/20/16, Leo Bicknell wrote: > > Others have already answered with the technical details. Let me take a > stab at some more, uh, variable items. [.. snip lots ..] > 90%+ of the stacks deployed will be too small. Modern Unix generally > has "autotuning" TCP stacks, but I don't think Windows or OS X has > those features yet (but I'd be very happy to be wrong on that point). Windows has had an autotuning stack since at least Vista. Regards, Lee From swmike at swm.pp.se Wed Apr 20 15:51:44 2016 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Wed, 20 Apr 2016 17:51:44 +0200 (CEST) Subject: Latency, TCP ACKs and upload needs In-Reply-To: <5716DB68.1080801@vaxination.ca> References: <5716DB68.1080801@vaxination.ca> Message-ID: On Tue, 19 Apr 2016, Jean-Francois Mezei wrote: > Considering a single download TCP connection. I am aware that modern TCP > stacks will rationalize ACKs and send 1 ACK for every x packets > received, thus reducing upload bandwidth requirements. Is this basically > widespread and assumed that everyone has that ? Typically you'll see one ACK per 2 packets, so you need approximately 1:50 bytes up/down ratio for the ACKs. It's possible to have middle boxes suppress some ACKs, please see thread here: https://www.ietf.org/mail-archive/web/aqm/current/msg01482.html -- Mikael Abrahamsson email: swmike at swm.pp.se From dot at dotat.at Wed Apr 20 16:12:36 2016 From: dot at dotat.at (Tony Finch) Date: Wed, 20 Apr 2016 17:12:36 +0100 Subject: Latency, TCP ACKs and upload needs In-Reply-To: <20160420142753.GA58668@ussenterprise.ufp.org> References: <5716DB68.1080801@vaxination.ca> <20160420142753.GA58668@ussenterprise.ufp.org> Message-ID: Leo Bicknell wrote: > > 1460 byte payloads down, maybe 64 byte acks on the return, and with SACK > which is widely deployed an ACK every 2-4 packets. You would see about > 2,140 packets/sec downstream (25Mbps/1460), and perhaps send 1070 ACKs > back upstream, at 64 bytes each, or about 68Kbps. Well under the 1Mbps > upstream bandwidth. Note that with delayed ACKs (RFC 1122) there is an ACK for every other packet; SACK should do better than that. Tony. -- f.anthony.n.finch http://dotat.at/ - I xn--zr8h punycode Humber, Thames: Northwest, veering north or northeast, 4 or 5. Slight or moderate. Fair. Good. From daniel.p.lacey at gmail.com Wed Apr 20 17:02:13 2016 From: daniel.p.lacey at gmail.com (Dan Lacey) Date: Wed, 20 Apr 2016 11:02:13 -0600 Subject: phone fun, was GeoIP database issues and the real world consequences In-Reply-To: <20160420152023.17423.qmail@ary.lan> References: <20160420152023.17423.qmail@ary.lan> Message-ID: <5717B615.5090707@gmail.com> Great explanation! Remember that LECs (Local Exchange Carrier, CenturyLink, Verizon, etc.) typically get to decide how this all works... ATT is still an 800 pound gorilla and a couple years ago stopped ALL payments to CLECs (Competitive Local Exchange Carrier, buy wholesale from LECs), took them all to court (which for a CLEC, it is almost impossible to find a good lawyer not on retainer to a LEC) and basically just told everyone what they would pay... Since all the LECs started offering unlimited long distance, they could not afford the termination fees. So... They changed them!!! Telco is very different from data, not in the physical aspects, but in the business and political areas. On 4/20/16 9:20 AM, John Levine wrote: >>> For the most part, ?long distance? calls within the US are a thing of the >>> past and at least one mobile carrier now treats US/CA/MX as a single >>> local calling area >> Is this a case of telcos having switched to IP trunks and can reach >> other carriers for "free" > No, it's because fiber bandwidth is so cheap. It's equally cheap whether > the framing is ATM or IP. > >> Or are wholesale long distance still billed between carriers but at >> prices so low that they can afford to offer "free" long distance at >> retail level ? > Some of each. Some carriers do reciprocal compensation at very low > rates, small fractions of a cent per minute, some do bill and keep > with no settlements at all. > > The history of settlements is closely tied to the history of the > Internet. Before the Bell breakup separations (within Bell) and > settlements (between Bell and independents) were uncontentious, moving > money around to make the rate of return on invested capital at each > carrier come out right. > > Then when cell phones were new, the Bell companies observed that > traffic was highly imbalanced, far more cell->landline than the other > way, so they demanded high reciprocal compensation, and the cellcos > were willing to pay since it gave the Bells the incentive to build the > interconnecting trunks. One of Verizon's predecessors famously > derided "bilk and keep." > > Then the dialup Internet became a big thing, the Bells ignored it as a > passing fad (which it was, but not for the reasons they thought), and > CLECs realized they could build modem banks and make a lot of money > from the incoming calls from Bell customers to the modems. So the > Bells did a pirouette and suddenly discovered that bill and keep was a > law of nature and recip comp was a quaint artifact that needed to be > snuffed out as fast as possible. > > These days the FCC likes to see cost justifications for settlements, > and the actual per-minute cost of calls is tiny compared to the fixed > costs of the links and equipment. The main place where you see > settlements is to tiny local telcos with very high costs, with the per > minute payments a deliberate subsidy to them. Then some greedy little > telcos added conference call lines to pump up their incoming traffic ... > > R's, > John > From rs-lists at seastrom.com Wed Apr 20 17:09:35 2016 From: rs-lists at seastrom.com (Rob Seastrom) Date: Wed, 20 Apr 2016 13:09:35 -0400 Subject: DOCSIS 3.1 upstream In-Reply-To: <57105538.4030105@vaxination.ca> References: <57105538.4030105@vaxination.ca> Message-ID: <5ABF2A62-C2B8-48DC-A8A4-F93F81356B84@seastrom.com> > On Apr 14, 2016, at 10:43 PM, Jean-Francois Mezei wrote: > > Also, have cablecos with such limits for upstream begun to upgrade the > cable plant to increase the upstream bandwidth ? Canadian cablecos have > told the regulator it would be prohibitively expensive to do so, but > incumbents tend to exagerate these things when it is convenient. (they > can then claim higher costs/congestion/need for node splits which > increates regulated wholesale rates). Going to D3.1 in a meaningful way means migrating to either a mid-split at 85 MHz or a high split at 200 MHz (117 MHz is in the spec but I've never heard anyone talk about it). It is not uncommon to see space (both for the upstream and downstream) freed up by sunsetting analog video channels. Yes, one has to do a truck roll and swap out amplifiers etc. but that is relatively straightforward. The "guts" pop out of the enclosure that hangs from the messenger wire and are then replaced. You don't need to actually put a wrench on a coax connector in order to do this. There may need to be plant rebalancing (checking and possibly replacing tilt compensators) but that's something that should be happening on an annual basis or perhaps more often, depending on local practice. Fiber nodes are similar in terms of work to swap them out, though they may be more modular inside. Amplifier insides: https://www.arris.com/globalassets/resources/data-sheets/starline-series-ble100-1-ghz-line-extender-data-sheet.pdf Fiber node insides: https://www.arris.com/globalassets/resources/data-sheets/sg4000-modular-4x4-node-data-sheet.pdf Passives (splitters, directional taps, terminators, and the like) are bidirectional and typically do not need to be replaced. Possibly useful reading for folks who want an overview of how it all goes together: http://www.cablelabs.com/wp-content/uploads/2014/12/DOCSIS3-1_Pocket_Guide_2014.pdf Without having read the Canadian cable providers' representations to the CRTC I am ill-equipped to pass judgemenent on them, but in my personal opinion any discussion of "D3.1 deployment" that doesn't plan for a refactoring of splits is a bit dishonest. > And would it be correct that in RFoG deployment, the 42mhz limit > disapears as the customer equipment talks directly tothe CMTS over fibre > all the way ? RFoG is its own kettle of fish. Getting more than one channel on upstream for RFoG is hard. There's a scheduler for transmitting on individual RF channels, but not for the upstream laser, so you could have two lasers coming on at the same time when two cablemodems (assume legacy D3.0 for a moment) transmit simultaneously on 19.40 MHz and 30.60 MHz - in an HFC plant where the mixing happens between two different radio frequencies in a copper wire and then feeds an single upstream fiber node, one doesn't have this problem. -r From dovid at telecurve.com Wed Apr 20 18:16:56 2016 From: dovid at telecurve.com (Dovid Bender) Date: Wed, 20 Apr 2016 14:16:56 -0400 Subject: Mobile providers in the US for backup access Message-ID: A while ago some people mentioned that some US carriers have basic internet plans for backup access to their equipment. A few questions: 1) Do they give you a public IP per connection or do you tunnel back to a central location and then connect via the tunnel? 2) Which carriers offer this and what kind of devices do you use to connect? Is it simply a GSM card on a "MyFi" like device? We have lots of Pi's out there that we want backup access to. 3) Can you send off list contacts and pricing that you have gotten in the past? TIA. Dovid From nanog at ics-il.net Wed Apr 20 18:35:01 2016 From: nanog at ics-il.net (Mike Hammett) Date: Wed, 20 Apr 2016 13:35:01 -0500 (CDT) Subject: Mobile providers in the US for backup access In-Reply-To: Message-ID: <2025019619.2372.1461177300771.JavaMail.mhammett@ThunderFuck> I'd look at FreedomPOP's Netgear 341U. $20 - $50 NRC, single digit MRC for low usage. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest Internet Exchange http://www.midwest-ix.com ----- Original Message ----- From: "Dovid Bender" To: "NANOG" Sent: Wednesday, April 20, 2016 1:16:56 PM Subject: Mobile providers in the US for backup access A while ago some people mentioned that some US carriers have basic internet plans for backup access to their equipment. A few questions: 1) Do they give you a public IP per connection or do you tunnel back to a central location and then connect via the tunnel? 2) Which carriers offer this and what kind of devices do you use to connect? Is it simply a GSM card on a "MyFi" like device? We have lots of Pi's out there that we want backup access to. 3) Can you send off list contacts and pricing that you have gotten in the past? TIA. Dovid From eric.kuhnke at gmail.com Wed Apr 20 18:40:22 2016 From: eric.kuhnke at gmail.com (Eric Kuhnke) Date: Wed, 20 Apr 2016 11:40:22 -0700 Subject: Mobile providers in the US for backup access In-Reply-To: References: Message-ID: Look into Ting if all you want is a backup OOB path: https://ting.com/rates?ab=1 $6/month per active SIM card. Plus billing for actual data usage. Use it in your choice of HSPA+/LTE modem equipment. They're an MVNO using, if I remember right, a combination of T-Mobile and Sprint. On Wed, Apr 20, 2016 at 11:16 AM, Dovid Bender wrote: > A while ago some people mentioned that some US carriers have basic internet > plans for backup access to their equipment. A few questions: > 1) Do they give you a public IP per connection or do you tunnel back to a > central location and then connect via the tunnel? > 2) Which carriers offer this and what kind of devices do you use to > connect? Is it simply a GSM card on a "MyFi" like device? We have lots of > Pi's out there that we want backup access to. > 3) Can you send off list contacts and pricing that you have gotten in the > past? > > TIA. > > Dovid > From owen at delong.com Wed Apr 20 18:42:44 2016 From: owen at delong.com (Owen DeLong) Date: Wed, 20 Apr 2016 13:42:44 -0500 Subject: Mobile providers in the US for backup access In-Reply-To: <2025019619.2372.1461177300771.JavaMail.mhammett@ThunderFuck> References: <2025019619.2372.1461177300771.JavaMail.mhammett@ThunderFuck> Message-ID: <9275ED91-5508-4858-A278-3EA113DBDC5D@delong.com> I had horrible experience when I tried to use Freedom POP many years ago. Their customer service is awful and completely uncooperative. Their equipment did not work well in my environment at all. I would not wish them on my worst enemy. Owen > On Apr 20, 2016, at 1:35 PM, Mike Hammett wrote: > > I'd look at FreedomPOP's Netgear 341U. $20 - $50 NRC, single digit MRC for low usage. > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > > > Midwest Internet Exchange > http://www.midwest-ix.com > > > ----- Original Message ----- > > From: "Dovid Bender" > To: "NANOG" > Sent: Wednesday, April 20, 2016 1:16:56 PM > Subject: Mobile providers in the US for backup access > > A while ago some people mentioned that some US carriers have basic internet > plans for backup access to their equipment. A few questions: > 1) Do they give you a public IP per connection or do you tunnel back to a > central location and then connect via the tunnel? > 2) Which carriers offer this and what kind of devices do you use to > connect? Is it simply a GSM card on a "MyFi" like device? We have lots of > Pi's out there that we want backup access to. > 3) Can you send off list contacts and pricing that you have gotten in the > past? > > TIA. > > Dovid From dovid at telecurve.com Wed Apr 20 18:49:07 2016 From: dovid at telecurve.com (Dovid Bender) Date: Wed, 20 Apr 2016 14:49:07 -0400 Subject: Mobile providers in the US for backup access In-Reply-To: References: Message-ID: Thank you everyone for your feedback. I also wanted to know if any providers offered unlimited 2g since in some cases they want to stream back some audio as well. On Wed, Apr 20, 2016 at 2:16 PM, Dovid Bender wrote: > A while ago some people mentioned that some US carriers have basic > internet plans for backup access to their equipment. A few questions: > 1) Do they give you a public IP per connection or do you tunnel back to a > central location and then connect via the tunnel? > 2) Which carriers offer this and what kind of devices do you use to > connect? Is it simply a GSM card on a "MyFi" like device? We have lots of > Pi's out there that we want backup access to. > 3) Can you send off list contacts and pricing that you have gotten in the > past? > > TIA. > > Dovid > > From D.Lasher at f5.com Wed Apr 20 18:52:18 2016 From: D.Lasher at f5.com (Donn Lasher) Date: Wed, 20 Apr 2016 18:52:18 +0000 Subject: Mobile providers in the US for backup access In-Reply-To: <9275ED91-5508-4858-A278-3EA113DBDC5D@delong.com> References: <2025019619.2372.1461177300771.JavaMail.mhammett@ThunderFuck> <9275ED91-5508-4858-A278-3EA113DBDC5D@delong.com> Message-ID: As a 3+ year ?customer? of freedom-pop, I agree. Their IP service was a bargain until the WiMax->LTE migration. Now the service is useless. Their technical support continually redefines lack of effort. On 4/20/16, 11:42 AM, "NANOG on behalf of Owen DeLong" wrote: >I had horrible experience when I tried to use Freedom POP many years ago. > >Their customer service is awful and completely uncooperative. Their equipment did not work well >in my environment at all. > >I would not wish them on my worst enemy. > >Owen > >> On Apr 20, 2016, at 1:35 PM, Mike Hammett wrote: >> >> I'd look at FreedomPOP's Netgear 341U. $20 - $50 NRC, single digit MRC for low usage. >> >> >> >> >> ----- >> Mike Hammett >> Intelligent Computing Solutions >> http://www.ics-il.com >> >> >> >> Midwest Internet Exchange >> http://www.midwest-ix.com >> >> From yang.yu.list at gmail.com Wed Apr 20 20:02:35 2016 From: yang.yu.list at gmail.com (Yang Yu) Date: Wed, 20 Apr 2016 15:02:35 -0500 Subject: Mobile providers in the US for backup access In-Reply-To: References: Message-ID: On Wed, Apr 20, 2016 at 1:49 PM, Dovid Bender wrote: > Thank you everyone for your feedback. I also wanted to know if any > providers offered unlimited 2g since in some cases they want to stream back > some audio as well. 4gantennashop has T-Mobile business with LTE data and unlimited 2G afterwards From dovid at telecurve.com Wed Apr 20 20:09:35 2016 From: dovid at telecurve.com (Dovid Bender) Date: Wed, 20 Apr 2016 16:09:35 -0400 Subject: Mobile providers in the US for backup access In-Reply-To: References: Message-ID: Yang, Thanks. I will check them out. On Wed, Apr 20, 2016 at 4:02 PM, Yang Yu wrote: > On Wed, Apr 20, 2016 at 1:49 PM, Dovid Bender wrote: > > Thank you everyone for your feedback. I also wanted to know if any > > providers offered unlimited 2g since in some cases they want to stream > back > > some audio as well. > > 4gantennashop has T-Mobile business with LTE data and unlimited 2G > afterwards > From nanog at ics-il.net Wed Apr 20 20:59:44 2016 From: nanog at ics-il.net (Mike Hammett) Date: Wed, 20 Apr 2016 15:59:44 -0500 (CDT) Subject: Mobile providers in the US for backup access In-Reply-To: <9275ED91-5508-4858-A278-3EA113DBDC5D@delong.com> Message-ID: <501916236.2493.1461185981637.JavaMail.mhammett@ThunderFuck> *shrugs* Seems to work here, though if Ting uses T-Mo and Sprint, I suppose Ting's more likely to have a good signal. I don't expect much support on a $6 mobile wireless service. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest Internet Exchange http://www.midwest-ix.com ----- Original Message ----- From: "Owen DeLong" To: "Mike Hammett" Cc: "NANOG" Sent: Wednesday, April 20, 2016 1:42:44 PM Subject: Re: Mobile providers in the US for backup access I had horrible experience when I tried to use Freedom POP many years ago. Their customer service is awful and completely uncooperative. Their equipment did not work well in my environment at all. I would not wish them on my worst enemy. Owen > On Apr 20, 2016, at 1:35 PM, Mike Hammett wrote: > > I'd look at FreedomPOP's Netgear 341U. $20 - $50 NRC, single digit MRC for low usage. > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > > > Midwest Internet Exchange > http://www.midwest-ix.com > > > ----- Original Message ----- > > From: "Dovid Bender" > To: "NANOG" > Sent: Wednesday, April 20, 2016 1:16:56 PM > Subject: Mobile providers in the US for backup access > > A while ago some people mentioned that some US carriers have basic internet > plans for backup access to their equipment. A few questions: > 1) Do they give you a public IP per connection or do you tunnel back to a > central location and then connect via the tunnel? > 2) Which carriers offer this and what kind of devices do you use to > connect? Is it simply a GSM card on a "MyFi" like device? We have lots of > Pi's out there that we want backup access to. > 3) Can you send off list contacts and pricing that you have gotten in the > past? > > TIA. > > Dovid From josh at kyneticwifi.com Wed Apr 20 21:18:09 2016 From: josh at kyneticwifi.com (Josh Reynolds) Date: Wed, 20 Apr 2016 16:18:09 -0500 Subject: Mobile providers in the US for backup access In-Reply-To: <501916236.2493.1461185981637.JavaMail.mhammett@ThunderFuck> References: <9275ED91-5508-4858-A278-3EA113DBDC5D@delong.com> <501916236.2493.1461185981637.JavaMail.mhammett@ThunderFuck> Message-ID: Ting's support is the BEST support I've ever had in the IT industry. I event ended up in a long discussion with one of the reps about custom roms :P On Wed, Apr 20, 2016 at 3:59 PM, Mike Hammett wrote: > *shrugs* Seems to work here, though if Ting uses T-Mo and Sprint, I suppose Ting's more likely to have a good signal. > > I don't expect much support on a $6 mobile wireless service. > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > > > Midwest Internet Exchange > http://www.midwest-ix.com > > > ----- Original Message ----- > > From: "Owen DeLong" > To: "Mike Hammett" > Cc: "NANOG" > Sent: Wednesday, April 20, 2016 1:42:44 PM > Subject: Re: Mobile providers in the US for backup access > > I had horrible experience when I tried to use Freedom POP many years ago. > > Their customer service is awful and completely uncooperative. Their equipment did not work well > in my environment at all. > > I would not wish them on my worst enemy. > > Owen > >> On Apr 20, 2016, at 1:35 PM, Mike Hammett wrote: >> >> I'd look at FreedomPOP's Netgear 341U. $20 - $50 NRC, single digit MRC for low usage. >> >> >> >> >> ----- >> Mike Hammett >> Intelligent Computing Solutions >> http://www.ics-il.com >> >> >> >> Midwest Internet Exchange >> http://www.midwest-ix.com >> >> >> ----- Original Message ----- >> >> From: "Dovid Bender" >> To: "NANOG" >> Sent: Wednesday, April 20, 2016 1:16:56 PM >> Subject: Mobile providers in the US for backup access >> >> A while ago some people mentioned that some US carriers have basic internet >> plans for backup access to their equipment. A few questions: >> 1) Do they give you a public IP per connection or do you tunnel back to a >> central location and then connect via the tunnel? >> 2) Which carriers offer this and what kind of devices do you use to >> connect? Is it simply a GSM card on a "MyFi" like device? We have lots of >> Pi's out there that we want backup access to. >> 3) Can you send off list contacts and pricing that you have gotten in the >> past? >> >> TIA. >> >> Dovid > > From eric.kuhnke at gmail.com Wed Apr 20 21:22:01 2016 From: eric.kuhnke at gmail.com (Eric Kuhnke) Date: Wed, 20 Apr 2016 14:22:01 -0700 Subject: Mobile providers in the US for backup access In-Reply-To: References: <9275ED91-5508-4858-A278-3EA113DBDC5D@delong.com> <501916236.2493.1461185981637.JavaMail.mhammett@ThunderFuck> Message-ID: ting is owned/run by tucows, who are now also doing a 1Gb (GPON?) residential single home FTTH project... http://www.fiercetelecom.com/europe/tags/tucows On Wed, Apr 20, 2016 at 2:18 PM, Josh Reynolds wrote: > Ting's support is the BEST support I've ever had in the IT industry. I > event ended up in a long discussion with one of the reps about custom > roms :P > > On Wed, Apr 20, 2016 at 3:59 PM, Mike Hammett wrote: > > *shrugs* Seems to work here, though if Ting uses T-Mo and Sprint, I > suppose Ting's more likely to have a good signal. > > > > I don't expect much support on a $6 mobile wireless service. > > > > > > > > > > ----- > > Mike Hammett > > Intelligent Computing Solutions > > http://www.ics-il.com > > > > > > > > Midwest Internet Exchange > > http://www.midwest-ix.com > > > > > > ----- Original Message ----- > > > > From: "Owen DeLong" > > To: "Mike Hammett" > > Cc: "NANOG" > > Sent: Wednesday, April 20, 2016 1:42:44 PM > > Subject: Re: Mobile providers in the US for backup access > > > > I had horrible experience when I tried to use Freedom POP many years ago. > > > > Their customer service is awful and completely uncooperative. Their > equipment did not work well > > in my environment at all. > > > > I would not wish them on my worst enemy. > > > > Owen > > > >> On Apr 20, 2016, at 1:35 PM, Mike Hammett wrote: > >> > >> I'd look at FreedomPOP's Netgear 341U. $20 - $50 NRC, single digit MRC > for low usage. > >> > >> > >> > >> > >> ----- > >> Mike Hammett > >> Intelligent Computing Solutions > >> http://www.ics-il.com > >> > >> > >> > >> Midwest Internet Exchange > >> http://www.midwest-ix.com > >> > >> > >> ----- Original Message ----- > >> > >> From: "Dovid Bender" > >> To: "NANOG" > >> Sent: Wednesday, April 20, 2016 1:16:56 PM > >> Subject: Mobile providers in the US for backup access > >> > >> A while ago some people mentioned that some US carriers have basic > internet > >> plans for backup access to their equipment. A few questions: > >> 1) Do they give you a public IP per connection or do you tunnel back to > a > >> central location and then connect via the tunnel? > >> 2) Which carriers offer this and what kind of devices do you use to > >> connect? Is it simply a GSM card on a "MyFi" like device? We have lots > of > >> Pi's out there that we want backup access to. > >> 3) Can you send off list contacts and pricing that you have gotten in > the > >> past? > >> > >> TIA. > >> > >> Dovid > > > > > From jfmezei_nanog at vaxination.ca Wed Apr 20 22:12:14 2016 From: jfmezei_nanog at vaxination.ca (Jean-Francois Mezei) Date: Wed, 20 Apr 2016 18:12:14 -0400 Subject: DOCSIS 3.1 upstream In-Reply-To: <5ABF2A62-C2B8-48DC-A8A4-F93F81356B84@seastrom.com> References: <57105538.4030105@vaxination.ca> <5ABF2A62-C2B8-48DC-A8A4-F93F81356B84@seastrom.com> Message-ID: <5717FEBE.1050107@vaxination.ca> On 2016-04-20 13:09, Rob Seastrom wrote: > Going to D3.1 in a meaningful way means migrating to either a mid-split at 85 MHz or a high split at 200 MHz Thanks. This is what I expected. But in the past, the canadian cablecos had argued that removing the 42mhz upstream limitation was a huge endeavour (they have to convicne CRTC to keep wholesale rates up, so create artificial scarcity by claiming that replacing all those 42mhz repeaters would cost a fortune, so they have to do node splits instead. Arguing at CRTC is all about finding out what incumbent statements are just spin and which are true. Thanks for the links as well.? > RFoG is its own kettle of fish. Getting more than one channel on upstream for RFoG is hard. But they can allocate a single very big channel, right ? Or did you mean a single traditional NTSC 6mhz channel ? From admin at coldnorthadmin.com Thu Apr 21 02:27:41 2016 From: admin at coldnorthadmin.com (Laurent Dumont) Date: Wed, 20 Apr 2016 22:27:41 -0400 Subject: CDN, Steam, Origin and NAT. Message-ID: <57183A9D.5000004@coldnorthadmin.com> Hi, We are running a small-ish LAN event in Toronto where we have to use a single IP address to NAT between 250-350 players. I have been made aware of possible issues with different services like Steam, Origin and Twitch who can run into issues when a large number of connections seem to originate from a single IP address. I just wanted to poke the list to see if anyone can chime him on their experiences with NATing customers and the impact it might have on public services. I am usually using public IP address space for players when designing most large LAN events. Dealing with NAT for a medium-ish amount of customers is not something I am used to do. It feels silly to worry about that when you assume that WISP sometimes(mostly?) use CGN when providing internet to customers. The same could be said of most large office buildings around the world. I appreciate any input on the matter! Thanks Laurent From piotr.iwanejko at gmail.com Thu Apr 21 12:52:50 2016 From: piotr.iwanejko at gmail.com (Piotr Iwanejko) Date: Thu, 21 Apr 2016 14:52:50 +0200 Subject: Major IX bandwidth sharing Message-ID: <9D2E85B8-53F2-4EED-8632-6B97FD318A01@gmail.com> Hello Nanog-ers, We are looking for a company that has >=100G connectivity to major IX-es (AMS-IX, DE-CIX preferred) with traffic asymmetry/heavy outgoing traffic, willing to resell incoming fraction n*10G/1*100G IX-only IP transit. Our company develops custom Anti-DDoS solution on PC platform (http://www.slideshare.net/atendesoftware/100-mpps-on-pc) and we want to collocate 1U scrubbing node. Please contact me off list for more details. Thank you. -- Piotr Iwanejko From paras at protrafsolutions.com Thu Apr 21 15:16:37 2016 From: paras at protrafsolutions.com (Paras Jha) Date: Thu, 21 Apr 2016 11:16:37 -0400 Subject: Major IX bandwidth sharing In-Reply-To: <9D2E85B8-53F2-4EED-8632-6B97FD318A01@gmail.com> References: <9D2E85B8-53F2-4EED-8632-6B97FD318A01@gmail.com> Message-ID: Interesting to see how the idea is gaining traction On Thu, Apr 21, 2016 at 8:52 AM, Piotr Iwanejko wrote: > Hello Nanog-ers, > > We are looking for a company that has >=100G connectivity to major IX-es > (AMS-IX, DE-CIX preferred) with traffic asymmetry/heavy outgoing traffic, > willing to resell incoming fraction n*10G/1*100G IX-only IP transit. > Our company develops custom Anti-DDoS solution on PC platform ( > http://www.slideshare.net/atendesoftware/100-mpps-on-pc) and we want to > collocate 1U scrubbing node. > > Please contact me off list for more details. > > Thank you. > -- > Piotr Iwanejko -- Regards, Paras President ProTraf Solutions, LLC Enterprise DDoS Mitigation From Steve.Mikulasik at civeo.com Thu Apr 21 16:07:48 2016 From: Steve.Mikulasik at civeo.com (Steve Mikulasik) Date: Thu, 21 Apr 2016 16:07:48 +0000 Subject: CDN, Steam, Origin and NAT. In-Reply-To: <57183A9D.5000004@coldnorthadmin.com> References: <57183A9D.5000004@coldnorthadmin.com> Message-ID: I do the network for a few lan parties. Last year we had 400+ people on 3 IPs and didn't have any issues. I don't think those services are that picky anymore since the rise of CGN. Just a side thing, but my advice is to look into setting up a lancache server for Steam. -----Original Message----- From: NANOG [mailto:nanog-bounces+steve.mikulasik=civeo.com at nanog.org] On Behalf Of Laurent Dumont Sent: Wednesday, April 20, 2016 8:28 PM To: nanog at nanog.org Subject: CDN, Steam, Origin and NAT. Hi, We are running a small-ish LAN event in Toronto where we have to use a single IP address to NAT between 250-350 players. I have been made aware of possible issues with different services like Steam, Origin and Twitch who can run into issues when a large number of connections seem to originate from a single IP address. I just wanted to poke the list to see if anyone can chime him on their experiences with NATing customers and the impact it might have on public services. I am usually using public IP address space for players when designing most large LAN events. Dealing with NAT for a medium-ish amount of customers is not something I am used to do. It feels silly to worry about that when you assume that WISP sometimes(mostly?) use CGN when providing internet to customers. The same could be said of most large office buildings around the world. I appreciate any input on the matter! Thanks Laurent From ikiris at gmail.com Thu Apr 21 16:18:20 2016 From: ikiris at gmail.com (Blake Dunlap) Date: Thu, 21 Apr 2016 09:18:20 -0700 Subject: CDN, Steam, Origin and NAT. In-Reply-To: References: <57183A9D.5000004@coldnorthadmin.com> Message-ID: It really depends on how stupid the nat device is. If the mappings are global you're looking at about 200 per user, if they aren't you're no where near an issue. Either way you're likely fine unless everyone tries to torrent at once On Thu, Apr 21, 2016 at 9:07 AM, Steve Mikulasik wrote: > I do the network for a few lan parties. Last year we had 400+ people on 3 IPs and didn't have any issues. I don't think those services are that picky anymore since the rise of CGN. > > Just a side thing, but my advice is to look into setting up a lancache server for Steam. > > > -----Original Message----- > From: NANOG [mailto:nanog-bounces+steve.mikulasik=civeo.com at nanog.org] On Behalf Of Laurent Dumont > Sent: Wednesday, April 20, 2016 8:28 PM > To: nanog at nanog.org > Subject: CDN, Steam, Origin and NAT. > > Hi, > > We are running a small-ish LAN event in Toronto where we have to use a single IP address to NAT between 250-350 players. I have been made aware of possible issues with different services like Steam, Origin and Twitch who can run into issues when a large number of connections seem to originate from a single IP address. I just wanted to poke the list to see if anyone can chime him on their experiences with NATing customers and the impact it might have on public services. I am usually using public IP address space for players when designing most large LAN events. Dealing with NAT for a medium-ish amount of customers is not something I am used to do. > > It feels silly to worry about that when you assume that WISP > sometimes(mostly?) use CGN when providing internet to customers. The same could be said of most large office buildings around the world. > > I appreciate any input on the matter! > > Thanks > > Laurent > From pavel.odintsov at gmail.com Thu Apr 21 17:25:52 2016 From: pavel.odintsov at gmail.com (Pavel Odintsov) Date: Thu, 21 Apr 2016 20:25:52 +0300 Subject: Major IX bandwidth sharing In-Reply-To: References: <9D2E85B8-53F2-4EED-8632-6B97FD318A01@gmail.com> Message-ID: Hello! If you want cheaper price just ask any TIER-1 provider for link with commit 10ge and burst up to 100GE. It will be definitely cheaper and simpler than your "magic" with IX cost reduction. On Thursday, 21 April 2016, Paras Jha wrote: > Interesting to see how the idea is gaining traction > > On Thu, Apr 21, 2016 at 8:52 AM, Piotr Iwanejko > > wrote: > > > Hello Nanog-ers, > > > > We are looking for a company that has >=100G connectivity to major IX-es > > (AMS-IX, DE-CIX preferred) with traffic asymmetry/heavy outgoing traffic, > > willing to resell incoming fraction n*10G/1*100G IX-only IP transit. > > Our company develops custom Anti-DDoS solution on PC platform ( > > http://www.slideshare.net/atendesoftware/100-mpps-on-pc) and we want to > > collocate 1U scrubbing node. > > > > Please contact me off list for more details. > > > > Thank you. > > -- > > Piotr Iwanejko > > > > > -- > Regards, > Paras > > President > ProTraf Solutions, LLC > Enterprise DDoS Mitigation > -- Sincerely yours, Pavel Odintsov From rs-lists at seastrom.com Thu Apr 21 17:30:17 2016 From: rs-lists at seastrom.com (Rob Seastrom) Date: Thu, 21 Apr 2016 13:30:17 -0400 Subject: DOCSIS 3.1 upstream In-Reply-To: <5717FEBE.1050107@vaxination.ca> References: <57105538.4030105@vaxination.ca> <5ABF2A62-C2B8-48DC-A8A4-F93F81356B84@seastrom.com> <5717FEBE.1050107@vaxination.ca> Message-ID: <6DB62C97-5B03-43B6-B509-688A966260C5@seastrom.com> > On Apr 20, 2016, at 6:12 PM, Jean-Francois Mezei wrote: > > On 2016-04-20 13:09, Rob Seastrom wrote: > >> Going to D3.1 in a meaningful way means migrating to either a mid-split at 85 MHz or a high split at 200 MHz > > Thanks. This is what I expected. But in the past, the canadian cablecos > had argued that removing the 42mhz upstream limitation was a huge > endeavour (they have to convicne CRTC to keep wholesale rates up, so > create artificial scarcity by claiming that replacing all those 42mhz > repeaters would cost a fortune, so they have to do node splits instead. In my opinion, that fails the sniff test. I don't have any particular budgetary information but I have a really hard time believing that pervasive node splits are cheaper than fixing the plant's US/DS splits. By the way, just as one typically finds downstream DOCSIS channels in the 600-ish MHz range because that's the space that became freshly available when the plant got upgraded from 400 MHz to 800 MHz, one is likely to find that the 'fat' D3.1 OFDM upstream channels in the freshly-freed-up space that comes from doing the split realignment. Remember that you need to keep the old upstreams in order to support all the old crufty D2.0 and D3.0 (and, sadly, probably the odd D1.1) modems out there. > Arguing at CRTC is all about finding out what incumbent statements are > just spin and which are true. > > Thanks for the links as well.? > >> RFoG is its own kettle of fish. Getting more than one channel on upstream for RFoG is hard. > > But they can allocate a single very big channel, right ? Or did you > mean a single traditional NTSC 6mhz channel ? They can allocate a single very big channel, but unlike QAM modulation, with OFDM you can have multiple stations transmitting at the same time on the same channel. So if anything, the optical beat interference from having more than one laser on at once is likely to be worse (for some values of worse - I don't know of anyone labbing such a thing up and trying to characterize just how bad it gets how fast with multiple transmitters - it might become intolerable with 2 on and it might not). I ran this past a colleague and he said "ewwwww why would anyone do D3.1 over RFoG?". I think that pretty much sums it up. My personal opinion is that two-way RFoG is a super bad idea, but one-way RFoG on a WDM-separated channel to support legacy QAM (with PON for your high speed data) is OK, with the caveat that if you want two-way settop boxes, you're gonna have to figure out how to have your STBs speak Ethernet or MoCA or something to get out via your commodity high speed data connection. The latter is the way that FiOS does it. -r From maxtul at netassist.ua Thu Apr 21 18:25:38 2016 From: maxtul at netassist.ua (Max Tulyev) Date: Thu, 21 Apr 2016 21:25:38 +0300 Subject: Major IX bandwidth sharing In-Reply-To: References: <9D2E85B8-53F2-4EED-8632-6B97FD318A01@gmail.com> Message-ID: <57191B22.5080801@netassist.ua> Hello, I'm sure in this case they will pay for 100G every month, not for 10-20G ;) On 21.04.16 20:25, Pavel Odintsov wrote: > Hello! > > If you want cheaper price just ask any TIER-1 provider for link with commit > 10ge and burst up to 100GE. It will be definitely cheaper and simpler than > your "magic" with IX cost reduction. > > On Thursday, 21 April 2016, Paras Jha wrote: > >> Interesting to see how the idea is gaining traction >> >> On Thu, Apr 21, 2016 at 8:52 AM, Piotr Iwanejko > > >> wrote: >> >>> Hello Nanog-ers, >>> >>> We are looking for a company that has >=100G connectivity to major IX-es >>> (AMS-IX, DE-CIX preferred) with traffic asymmetry/heavy outgoing traffic, >>> willing to resell incoming fraction n*10G/1*100G IX-only IP transit. >>> Our company develops custom Anti-DDoS solution on PC platform ( >>> http://www.slideshare.net/atendesoftware/100-mpps-on-pc) and we want to >>> collocate 1U scrubbing node. >>> >>> Please contact me off list for more details. >>> >>> Thank you. >>> -- >>> Piotr Iwanejko >> >> >> >> >> -- >> Regards, >> Paras >> >> President >> ProTraf Solutions, LLC >> Enterprise DDoS Mitigation >> > > From pavel.odintsov at gmail.com Thu Apr 21 19:40:22 2016 From: pavel.odintsov at gmail.com (Pavel Odintsov) Date: Thu, 21 Apr 2016 22:40:22 +0300 Subject: Major IX bandwidth sharing In-Reply-To: <57191B22.5080801@netassist.ua> References: <9D2E85B8-53F2-4EED-8632-6B97FD318A01@gmail.com> <57191B22.5080801@netassist.ua> Message-ID: If they could offer 95th percentile usage no more than commit they should pay only for it. But actually it depends on certain carrier and certain agreement conditions. On Thursday, 21 April 2016, Max Tulyev wrote: > Hello, > > I'm sure in this case they will pay for 100G every month, not for 10-20G ;) > > On 21.04.16 20:25, Pavel Odintsov wrote: > > Hello! > > > > If you want cheaper price just ask any TIER-1 provider for link with > commit > > 10ge and burst up to 100GE. It will be definitely cheaper and simpler > than > > your "magic" with IX cost reduction. > > > > On Thursday, 21 April 2016, Paras Jha > wrote: > > > >> Interesting to see how the idea is gaining traction > >> > >> On Thu, Apr 21, 2016 at 8:52 AM, Piotr Iwanejko < > piotr.iwanejko at gmail.com > >> > > >> wrote: > >> > >>> Hello Nanog-ers, > >>> > >>> We are looking for a company that has >=100G connectivity to major > IX-es > >>> (AMS-IX, DE-CIX preferred) with traffic asymmetry/heavy outgoing > traffic, > >>> willing to resell incoming fraction n*10G/1*100G IX-only IP transit. > >>> Our company develops custom Anti-DDoS solution on PC platform ( > >>> http://www.slideshare.net/atendesoftware/100-mpps-on-pc) and we want > to > >>> collocate 1U scrubbing node. > >>> > >>> Please contact me off list for more details. > >>> > >>> Thank you. > >>> -- > >>> Piotr Iwanejko > >> > >> > >> > >> > >> -- > >> Regards, > >> Paras > >> > >> President > >> ProTraf Solutions, LLC > >> Enterprise DDoS Mitigation > >> > > > > > > -- Sincerely yours, Pavel Odintsov From paras at protrafsolutions.com Thu Apr 21 19:56:16 2016 From: paras at protrafsolutions.com (Paras Jha) Date: Thu, 21 Apr 2016 15:56:16 -0400 Subject: Major IX bandwidth sharing In-Reply-To: References: <9D2E85B8-53F2-4EED-8632-6B97FD318A01@gmail.com> <57191B22.5080801@netassist.ua> Message-ID: I'm sure you can get 1gb on 10gbit burst. 4gb on 40G burst is also pretty achievable in a single location. But there are very few places where you'll get a 10G on 100G burst line. Even if they are willing to give it to you, you'll probably have to commit to more than 10% of the port size On Thu, Apr 21, 2016 at 3:40 PM, Pavel Odintsov wrote: > If they could offer 95th percentile usage no more than commit they should > pay only for it. But actually it depends on certain carrier and certain > agreement conditions. > > On Thursday, 21 April 2016, Max Tulyev wrote: > > > Hello, > > > > I'm sure in this case they will pay for 100G every month, not for 10-20G > ;) > > > > On 21.04.16 20:25, Pavel Odintsov wrote: > > > Hello! > > > > > > If you want cheaper price just ask any TIER-1 provider for link with > > commit > > > 10ge and burst up to 100GE. It will be definitely cheaper and simpler > > than > > > your "magic" with IX cost reduction. > > > > > > On Thursday, 21 April 2016, Paras Jha > > wrote: > > > > > >> Interesting to see how the idea is gaining traction > > >> > > >> On Thu, Apr 21, 2016 at 8:52 AM, Piotr Iwanejko < > > piotr.iwanejko at gmail.com > > >> > > > >> wrote: > > >> > > >>> Hello Nanog-ers, > > >>> > > >>> We are looking for a company that has >=100G connectivity to major > > IX-es > > >>> (AMS-IX, DE-CIX preferred) with traffic asymmetry/heavy outgoing > > traffic, > > >>> willing to resell incoming fraction n*10G/1*100G IX-only IP transit. > > >>> Our company develops custom Anti-DDoS solution on PC platform ( > > >>> http://www.slideshare.net/atendesoftware/100-mpps-on-pc) and we want > > to > > >>> collocate 1U scrubbing node. > > >>> > > >>> Please contact me off list for more details. > > >>> > > >>> Thank you. > > >>> -- > > >>> Piotr Iwanejko > > >> > > >> > > >> > > >> > > >> -- > > >> Regards, > > >> Paras > > >> > > >> President > > >> ProTraf Solutions, LLC > > >> Enterprise DDoS Mitigation > > >> > > > > > > > > > > > > -- > Sincerely yours, Pavel Odintsov > -- Regards, Paras President ProTraf Solutions, LLC Enterprise DDoS Mitigation From maxtul at netassist.ua Thu Apr 21 20:43:58 2016 From: maxtul at netassist.ua (Max Tulyev) Date: Thu, 21 Apr 2016 23:43:58 +0300 Subject: Major IX bandwidth sharing In-Reply-To: References: <9D2E85B8-53F2-4EED-8632-6B97FD318A01@gmail.com> <57191B22.5080801@netassist.ua> Message-ID: <57193B8E.7070206@netassist.ua> They fight with DDoS, so it means every month 95% traffic will be full 100G. On 21.04.16 22:40, Pavel Odintsov wrote: > If they could offer 95th percentile usage no more than commit they > should pay only for it. But actually it depends on certain carrier and > certain agreement conditions. > > On Thursday, 21 April 2016, Max Tulyev > wrote: > > Hello, > > I'm sure in this case they will pay for 100G every month, not for > 10-20G ;) > > On 21.04.16 20:25, Pavel Odintsov wrote: > > Hello! > > > > If you want cheaper price just ask any TIER-1 provider for link > with commit > > 10ge and burst up to 100GE. It will be definitely cheaper and > simpler than > > your "magic" with IX cost reduction. > > > > On Thursday, 21 April 2016, Paras Jha > wrote: > > > >> Interesting to see how the idea is gaining traction > >> > >> On Thu, Apr 21, 2016 at 8:52 AM, Piotr Iwanejko > > >> > > >> wrote: > >> > >>> Hello Nanog-ers, > >>> > >>> We are looking for a company that has >=100G connectivity to > major IX-es > >>> (AMS-IX, DE-CIX preferred) with traffic asymmetry/heavy outgoing > traffic, > >>> willing to resell incoming fraction n*10G/1*100G IX-only IP transit. > >>> Our company develops custom Anti-DDoS solution on PC platform ( > >>> http://www.slideshare.net/atendesoftware/100-mpps-on-pc) and we > want to > >>> collocate 1U scrubbing node. > >>> > >>> Please contact me off list for more details. > >>> > >>> Thank you. > >>> -- > >>> Piotr Iwanejko > >> > >> > >> > >> > >> -- > >> Regards, > >> Paras > >> > >> President > >> ProTraf Solutions, LLC > >> Enterprise DDoS Mitigation > >> > > > > > > > > -- > Sincerely yours, Pavel Odintsov From ikiris at gmail.com Thu Apr 21 21:13:55 2016 From: ikiris at gmail.com (Blake Dunlap) Date: Thu, 21 Apr 2016 14:13:55 -0700 Subject: Major IX bandwidth sharing In-Reply-To: <57193B8E.7070206@netassist.ua> References: <9D2E85B8-53F2-4EED-8632-6B97FD318A01@gmail.com> <57191B22.5080801@netassist.ua> <57193B8E.7070206@netassist.ua> Message-ID: Not to mention the sharer's traffic will be impacted by said DoS... On Thu, Apr 21, 2016 at 1:43 PM, Max Tulyev wrote: > They fight with DDoS, so it means every month 95% traffic will be full 100G. > > On 21.04.16 22:40, Pavel Odintsov wrote: >> If they could offer 95th percentile usage no more than commit they >> should pay only for it. But actually it depends on certain carrier and >> certain agreement conditions. >> >> On Thursday, 21 April 2016, Max Tulyev > > wrote: >> >> Hello, >> >> I'm sure in this case they will pay for 100G every month, not for >> 10-20G ;) >> >> On 21.04.16 20:25, Pavel Odintsov wrote: >> > Hello! >> > >> > If you want cheaper price just ask any TIER-1 provider for link >> with commit >> > 10ge and burst up to 100GE. It will be definitely cheaper and >> simpler than >> > your "magic" with IX cost reduction. >> > >> > On Thursday, 21 April 2016, Paras Jha > > wrote: >> > >> >> Interesting to see how the idea is gaining traction >> >> >> >> On Thu, Apr 21, 2016 at 8:52 AM, Piotr Iwanejko >> >> >> > >> >> wrote: >> >> >> >>> Hello Nanog-ers, >> >>> >> >>> We are looking for a company that has >=100G connectivity to >> major IX-es >> >>> (AMS-IX, DE-CIX preferred) with traffic asymmetry/heavy outgoing >> traffic, >> >>> willing to resell incoming fraction n*10G/1*100G IX-only IP transit. >> >>> Our company develops custom Anti-DDoS solution on PC platform ( >> >>> http://www.slideshare.net/atendesoftware/100-mpps-on-pc) and we >> want to >> >>> collocate 1U scrubbing node. >> >>> >> >>> Please contact me off list for more details. >> >>> >> >>> Thank you. >> >>> -- >> >>> Piotr Iwanejko >> >> >> >> >> >> >> >> >> >> -- >> >> Regards, >> >> Paras >> >> >> >> President >> >> ProTraf Solutions, LLC >> >> Enterprise DDoS Mitigation >> >> >> > >> > >> >> >> >> -- >> Sincerely yours, Pavel Odintsov > From rea+nanog at grid.kiae.ru Fri Apr 22 06:17:54 2016 From: rea+nanog at grid.kiae.ru (Eygene Ryabinkin) Date: Fri, 22 Apr 2016 09:17:54 +0300 Subject: Latency, TCP ACKs and upload needs In-Reply-To: <20160420142753.GA58668@ussenterprise.ufp.org> References: <5716DB68.1080801@vaxination.ca> <20160420142753.GA58668@ussenterprise.ufp.org> Message-ID: <20160422061754.GU1159void.codelabs.ru@void.codelabs.ru> Wed, Apr 20, 2016 at 07:27:53AM -0700, Leo Bicknell wrote: > 90%+ of the stacks deployed will be too small. Modern Unix generally > has "autotuning" TCP stacks, but I don't think Windows or OS X has > those features yet OS X since ~10.5 has autotuning, here are some hints from ESnet https://fasterdata.es.net/host-tuning/osx/ Personally never tried this on the sat-type RTT. As explained, scaling factor of 3 is a limiting one for high-performance transfers. For sat links may limit the things too, since 64K * 2^3 / 0.9 ms RTT * 8 ~ 4.5 Mbit/sec, but one's mileage may vary. And, of course, packet loss can turn down this BDP-derived speed drastically. -- Eygene Ryabinkin, National Research Centre "Kurchatov Institute" Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 311 bytes Desc: not available URL: From pavel.odintsov at gmail.com Fri Apr 22 07:41:49 2016 From: pavel.odintsov at gmail.com (Pavel Odintsov) Date: Fri, 22 Apr 2016 10:41:49 +0300 Subject: Major IX bandwidth sharing In-Reply-To: References: <9D2E85B8-53F2-4EED-8632-6B97FD318A01@gmail.com> <57191B22.5080801@netassist.ua> <57193B8E.7070206@netassist.ua> Message-ID: Hello! Nice addition. That's additional risks for company which want to share capacity :) On Fri, Apr 22, 2016 at 12:13 AM, Blake Dunlap wrote: > Not to mention the sharer's traffic will be impacted by said DoS... > > On Thu, Apr 21, 2016 at 1:43 PM, Max Tulyev wrote: >> They fight with DDoS, so it means every month 95% traffic will be full 100G. >> >> On 21.04.16 22:40, Pavel Odintsov wrote: >>> If they could offer 95th percentile usage no more than commit they >>> should pay only for it. But actually it depends on certain carrier and >>> certain agreement conditions. >>> >>> On Thursday, 21 April 2016, Max Tulyev >> > wrote: >>> >>> Hello, >>> >>> I'm sure in this case they will pay for 100G every month, not for >>> 10-20G ;) >>> >>> On 21.04.16 20:25, Pavel Odintsov wrote: >>> > Hello! >>> > >>> > If you want cheaper price just ask any TIER-1 provider for link >>> with commit >>> > 10ge and burst up to 100GE. It will be definitely cheaper and >>> simpler than >>> > your "magic" with IX cost reduction. >>> > >>> > On Thursday, 21 April 2016, Paras Jha >> > wrote: >>> > >>> >> Interesting to see how the idea is gaining traction >>> >> >>> >> On Thu, Apr 21, 2016 at 8:52 AM, Piotr Iwanejko >>> >>> >> > >>> >> wrote: >>> >> >>> >>> Hello Nanog-ers, >>> >>> >>> >>> We are looking for a company that has >=100G connectivity to >>> major IX-es >>> >>> (AMS-IX, DE-CIX preferred) with traffic asymmetry/heavy outgoing >>> traffic, >>> >>> willing to resell incoming fraction n*10G/1*100G IX-only IP transit. >>> >>> Our company develops custom Anti-DDoS solution on PC platform ( >>> >>> http://www.slideshare.net/atendesoftware/100-mpps-on-pc) and we >>> want to >>> >>> collocate 1U scrubbing node. >>> >>> >>> >>> Please contact me off list for more details. >>> >>> >>> >>> Thank you. >>> >>> -- >>> >>> Piotr Iwanejko >>> >> >>> >> >>> >> >>> >> >>> >> -- >>> >> Regards, >>> >> Paras >>> >> >>> >> President >>> >> ProTraf Solutions, LLC >>> >> Enterprise DDoS Mitigation >>> >> >>> > >>> > >>> >>> >>> >>> -- >>> Sincerely yours, Pavel Odintsov >> -- Sincerely yours, Pavel Odintsov From dovid at telecurve.com Fri Apr 22 15:19:33 2016 From: dovid at telecurve.com (Dovid Bender) Date: Fri, 22 Apr 2016 11:19:33 -0400 Subject: Major IX bandwidth sharing In-Reply-To: References: <9D2E85B8-53F2-4EED-8632-6B97FD318A01@gmail.com> <57191B22.5080801@netassist.ua> <57193B8E.7070206@netassist.ua> Message-ID: I assume they are looking for some one that has a lot of upstream content. On Thu, Apr 21, 2016 at 5:13 PM, Blake Dunlap wrote: > Not to mention the sharer's traffic will be impacted by said DoS... > > On Thu, Apr 21, 2016 at 1:43 PM, Max Tulyev wrote: > > They fight with DDoS, so it means every month 95% traffic will be full > 100G. > > > > On 21.04.16 22:40, Pavel Odintsov wrote: > >> If they could offer 95th percentile usage no more than commit they > >> should pay only for it. But actually it depends on certain carrier and > >> certain agreement conditions. > >> > >> On Thursday, 21 April 2016, Max Tulyev >> > wrote: > >> > >> Hello, > >> > >> I'm sure in this case they will pay for 100G every month, not for > >> 10-20G ;) > >> > >> On 21.04.16 20:25, Pavel Odintsov wrote: > >> > Hello! > >> > > >> > If you want cheaper price just ask any TIER-1 provider for link > >> with commit > >> > 10ge and burst up to 100GE. It will be definitely cheaper and > >> simpler than > >> > your "magic" with IX cost reduction. > >> > > >> > On Thursday, 21 April 2016, Paras Jha >> > wrote: > >> > > >> >> Interesting to see how the idea is gaining traction > >> >> > >> >> On Thu, Apr 21, 2016 at 8:52 AM, Piotr Iwanejko > >> > >> >> > > >> >> wrote: > >> >> > >> >>> Hello Nanog-ers, > >> >>> > >> >>> We are looking for a company that has >=100G connectivity to > >> major IX-es > >> >>> (AMS-IX, DE-CIX preferred) with traffic asymmetry/heavy outgoing > >> traffic, > >> >>> willing to resell incoming fraction n*10G/1*100G IX-only IP > transit. > >> >>> Our company develops custom Anti-DDoS solution on PC platform ( > >> >>> http://www.slideshare.net/atendesoftware/100-mpps-on-pc) and we > >> want to > >> >>> collocate 1U scrubbing node. > >> >>> > >> >>> Please contact me off list for more details. > >> >>> > >> >>> Thank you. > >> >>> -- > >> >>> Piotr Iwanejko > >> >> > >> >> > >> >> > >> >> > >> >> -- > >> >> Regards, > >> >> Paras > >> >> > >> >> President > >> >> ProTraf Solutions, LLC > >> >> Enterprise DDoS Mitigation > >> >> > >> > > >> > > >> > >> > >> > >> -- > >> Sincerely yours, Pavel Odintsov > > > From math at sizone.org Fri Apr 22 17:21:47 2016 From: math at sizone.org (Ken Chase) Date: Fri, 22 Apr 2016 13:21:47 -0400 Subject: google and amazon wierdness via HE right now Message-ID: <20160422172147.GI10697@sizone.org> >From toronto - something odd - mtr to google.com (google.com (172.217.3.142)) 5. v638.core1.tor1.he.net 6. 100ge7-2.core1.nyc4.he.net 7. 100ge11-1.core1.par2.he.net 8. 10ge3-2.core1.zrh1.he.net 9. ??? par is paris, zrh is zurich? same base path for hitting my EC2 nodes... Cant imagine this is just affecting Toronto HE customers. EC2 node is in 107.20/14 /kc From math at sizone.org Fri Apr 22 17:22:27 2016 From: math at sizone.org (Ken Chase) Date: Fri, 22 Apr 2016 13:22:27 -0400 Subject: google and amazon wierdness via HE right now In-Reply-To: <20160422172147.GI10697@sizone.org> References: <20160422172147.GI10697@sizone.org> Message-ID: <20160422172227.GJ10697@sizone.org> and of course the second I post it all fixes itself. NANOG works! Thanks! (was going on for about 10-15 min) On Fri, Apr 22, 2016 at 01:21:47PM -0400, Ken Chase said: > >From toronto - something odd - mtr to google.com (google.com (172.217.3.142)) > > 5. v638.core1.tor1.he.net > 6. 100ge7-2.core1.nyc4.he.net > 7. 100ge11-1.core1.par2.he.net > 8. 10ge3-2.core1.zrh1.he.net > 9. ??? > >par is paris, zrh is zurich? > >same base path for hitting my EC2 nodes... Cant imagine this is just affecting Toronto >HE customers. > >EC2 node is in 107.20/14 > >/kc /kc From rvandolson at esri.com Fri Apr 22 17:28:25 2016 From: rvandolson at esri.com (Ray Van Dolson) Date: Fri, 22 Apr 2016 10:28:25 -0700 Subject: google and amazon wierdness via HE right now In-Reply-To: <20160422172227.GJ10697@sizone.org> References: <20160422172147.GI10697@sizone.org> <20160422172227.GJ10697@sizone.org> Message-ID: <20160422172825.GA3276@esri.com> On Fri, Apr 22, 2016 at 01:22:27PM -0400, Ken Chase wrote: > and of course the second I post it all fixes itself. NANOG works! Thanks! > > (was going on for about 10-15 min) > > On Fri, Apr 22, 2016 at 01:21:47PM -0400, Ken Chase said: > > > >From toronto - something odd - mtr to google.com (google.com (172.217.3.142)) > > > > 5. v638.core1.tor1.he.net > > 6. 100ge7-2.core1.nyc4.he.net > > 7. 100ge11-1.core1.par2.he.net > > 8. 10ge3-2.core1.zrh1.he.net > > 9. ??? > > > >par is paris, zrh is zurich? > > > >same base path for hitting my EC2 nodes... Cant imagine this is just affecting Toronto > >HE customers. > > > >EC2 node is in 107.20/14 > > > >/kc > > /kc There's some chatter about Amazon issues on the Outages mailing list as well. Definitely seems like something blipped. Ray From frnkblk at iname.com Fri Apr 22 17:31:26 2016 From: frnkblk at iname.com (Frank Bulk) Date: Fri, 22 Apr 2016 12:31:26 -0500 Subject: google and amazon wierdness via HE right now In-Reply-To: <20160422172147.GI10697@sizone.org> References: <20160422172147.GI10697@sizone.org> Message-ID: <006401d19cbc$cc3adf10$64b09d30$@iname.com> Being discussed on outages, too. Our monitoring system saw access to www.amazon.com and www.cablelabs.com (over v6) down via HE ... amazon came back up for me via Zayo, but when www.cablelabs.com came back up, it was on HE. So the same as you. So I suspect HE had a hiccup. Frank -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Ken Chase Sent: Friday, April 22, 2016 12:22 PM To: NANOG Subject: google and amazon wierdness via HE right now >From toronto - something odd - mtr to google.com (google.com (172.217.3.142)) 5. v638.core1.tor1.he.net 6. 100ge7-2.core1.nyc4.he.net 7. 100ge11-1.core1.par2.he.net 8. 10ge3-2.core1.zrh1.he.net 9. ??? par is paris, zrh is zurich? same base path for hitting my EC2 nodes... Cant imagine this is just affecting Toronto HE customers. EC2 node is in 107.20/14 /kc From cscora at apnic.net Fri Apr 22 18:11:53 2016 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 23 Apr 2016 04:11:53 +1000 (AEST) Subject: Weekly Routing Table Report Message-ID: <201604221811.u3MIBrwH006786@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, SAFNOG, PaNOG, SdNOG, BJNOG, CaribNOG and the RIPE Routing WG. 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 Apr, 2016 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 592244 Prefixes after maximum aggregation (per Origin AS): 217479 Deaggregation factor: 2.72 Unique aggregates announced (without unneeded subnets): 289716 Total ASes present in the Internet Routing Table: 53506 Prefixes per ASN: 11.07 Origin-only ASes present in the Internet Routing Table: 36591 Origin ASes announcing only one prefix: 15706 Transit ASes present in the Internet Routing Table: 6431 Transit-only ASes present in the Internet Routing Table: 167 Average AS path length visible in the Internet Routing Table: 4.3 Max AS path length visible: 39 Max AS path prepend of ASN ( 40285) 34 Prefixes from unregistered ASNs in the Routing Table: 1000 Unregistered ASNs in the Routing Table: 361 Number of 32-bit ASNs allocated by the RIRs: 13578 Number of 32-bit ASNs visible in the Routing Table: 10484 Prefixes from 32-bit ASNs in the Routing Table: 41067 Number of bogon 32-bit ASNs visible in the Routing Table: 18 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 387 Number of addresses announced to Internet: 2809388612 Equivalent to 167 /8s, 115 /16s and 222 /24s Percentage of available address space announced: 75.9 Percentage of allocated address space announced: 75.9 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 98.1 Total number of prefixes smaller than registry allocations: 193331 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 151863 Total APNIC prefixes after maximum aggregation: 42146 APNIC Deaggregation factor: 3.60 Prefixes being announced from the APNIC address blocks: 162423 Unique aggregates announced from the APNIC address blocks: 66131 APNIC Region origin ASes present in the Internet Routing Table: 5170 APNIC Prefixes per ASN: 31.42 APNIC Region origin ASes announcing only one prefix: 1185 APNIC Region transit ASes present in the Internet Routing Table: 914 Average APNIC Region AS path length visible: 4.4 Max APNIC Region AS path length visible: 39 Number of APNIC region 32-bit ASNs visible in the Routing Table: 2018 Number of APNIC addresses announced to Internet: 754038596 Equivalent to 44 /8s, 241 /16s and 183 /24s Percentage of available APNIC address space announced: 88.1 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: 180914 Total ARIN prefixes after maximum aggregation: 89696 ARIN Deaggregation factor: 2.02 Prefixes being announced from the ARIN address blocks: 185979 Unique aggregates announced from the ARIN address blocks: 88323 ARIN Region origin ASes present in the Internet Routing Table: 16385 ARIN Prefixes per ASN: 11.35 ARIN Region origin ASes announcing only one prefix: 5859 ARIN Region transit ASes present in the Internet Routing Table: 1711 Average ARIN Region AS path length visible: 3.8 Max ARIN Region AS path length visible: 37 Number of ARIN region 32-bit ASNs visible in the Routing Table: 1148 Number of ARIN addresses announced to Internet: 1101398848 Equivalent to 65 /8s, 166 /16s and 3 /24s Percentage of available ARIN address space announced: 58.3 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: 142056 Total RIPE prefixes after maximum aggregation: 70126 RIPE Deaggregation factor: 2.03 Prefixes being announced from the RIPE address blocks: 151030 Unique aggregates announced from the RIPE address blocks: 92997 RIPE Region origin ASes present in the Internet Routing Table: 18067 RIPE Prefixes per ASN: 8.36 RIPE Region origin ASes announcing only one prefix: 7906 RIPE Region transit ASes present in the Internet Routing Table: 3001 Average RIPE Region AS path length visible: 4.3 Max RIPE Region AS path length visible: 29 Number of RIPE region 32-bit ASNs visible in the Routing Table: 4676 Number of RIPE addresses announced to Internet: 704622720 Equivalent to 41 /8s, 255 /16s and 176 /24s Percentage of available RIPE address space announced: 102.4 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-204287 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: 61961 Total LACNIC prefixes after maximum aggregation: 12274 LACNIC Deaggregation factor: 5.05 Prefixes being announced from the LACNIC address blocks: 76230 Unique aggregates announced from the LACNIC address blocks: 36035 LACNIC Region origin ASes present in the Internet Routing Table: 2470 LACNIC Prefixes per ASN: 30.86 LACNIC Region origin ASes announcing only one prefix: 575 LACNIC Region transit ASes present in the Internet Routing Table: 566 Average LACNIC Region AS path length visible: 4.7 Max LACNIC Region AS path length visible: 24 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 2433 Number of LACNIC addresses announced to Internet: 170984768 Equivalent to 10 /8s, 49 /16s and 5 /24s Percentage of available LACNIC address space announced: 101.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: 14273 Total AfriNIC prefixes after maximum aggregation: 3196 AfriNIC Deaggregation factor: 4.47 Prefixes being announced from the AfriNIC address blocks: 16195 Unique aggregates announced from the AfriNIC address blocks: 5879 AfriNIC Region origin ASes present in the Internet Routing Table: 737 AfriNIC Prefixes per ASN: 21.97 AfriNIC Region origin ASes announcing only one prefix: 181 AfriNIC Region transit ASes present in the Internet Routing Table: 171 Average AfriNIC Region AS path length visible: 4.6 Max AfriNIC Region AS path length visible: 21 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 209 Number of AfriNIC addresses announced to Internet: 77973504 Equivalent to 4 /8s, 165 /16s and 200 /24s Percentage of available AfriNIC address space announced: 77.5 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 4538 5555 4192 76 China Education and Research 7545 3286 353 208 TPG Telecom Limited 4766 3164 11145 1121 Korea Telecom 17974 2921 914 96 PT Telekomunikasi Indonesia 9829 2494 1466 462 National Internet Backbone 4755 2090 432 241 TATA Communications formerly 9808 1883 8717 30 Guangdong Mobile Communicatio 4808 1659 2301 539 CNCGROUP IP network China169 9583 1508 121 564 Sify Limited 38197 1492 92 212 Sun Network (Hong Kong) Limit 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 3321 2948 145 Cox Communications Inc. 6389 2318 3671 41 BellSouth.net Inc. 18566 2207 394 277 MegaPath Corporation 20115 1923 1937 404 Charter Communications 30036 1728 340 317 Mediacom Communications Corp 6983 1694 849 232 EarthLink, Inc. 209 1567 4666 1236 Qwest Communications Company, 4323 1567 1004 386 tw telecom holdings, inc. 701 1296 10702 704 MCI Communications Services, 7018 1279 19906 975 AT&T Services, Inc. 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 2708 143 10 SaudiNet, Saudi Telecom Compa 20940 2442 924 1780 Akamai International B.V. 34984 1964 323 414 TELLCOM ILETISIM HIZMETLERI A 8551 1628 376 55 Bezeq International-Ltd 12479 1159 981 86 France Telecom Espana SA 13188 1079 98 69 TOV "Bank-Inform" 8402 1056 544 15 OJSC "Vimpelcom" 31148 1030 47 41 Freenet Ltd. 9198 938 352 25 JSC Kazakhtelecom 6830 893 2719 463 Liberty Global Operations B.V 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 3460 540 170 Telmex Colombia S.A. 8151 2220 3320 539 Uninet S.A. de C.V. 7303 1509 940 238 Telecom Argentina S.A. 11830 1484 368 53 Instituto Costarricense de El 6503 1435 437 56 Axtel, S.A.B. de C.V. 6147 1046 377 27 Telefonica del Peru S.A.A. 26615 1003 2325 34 Tim Celular S.A. 3816 996 478 186 COLOMBIA TELECOMUNICACIONES S 7738 987 1882 40 Telemar Norte Leste S.A. 11172 869 125 76 Alestra, S. de R.L. de C.V. 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 1223 402 40 Link Egypt (Link.NET) 37611 647 48 2 Afrihost-Brevis Computer Serv 36903 617 310 105 Office National des Postes et 8452 542 1472 15 TE-AS 36992 510 1357 26 ETISALAT MISR 37492 394 234 67 Orange Tunisie 24835 326 210 13 Vodafone Data 29571 301 37 13 Cote d'Ivoire Telecom 2018 256 327 74 TENET (The UNINET Project) 36947 238 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 4538 5555 4192 76 China Education and Research 10620 3460 540 170 Telmex Colombia S.A. 22773 3321 2948 145 Cox Communications Inc. 7545 3286 353 208 TPG Telecom Limited 4766 3164 11145 1121 Korea Telecom 17974 2921 914 96 PT Telekomunikasi Indonesia 39891 2708 143 10 SaudiNet, Saudi Telecom Compa 9829 2494 1466 462 National Internet Backbone 20940 2442 924 1780 Akamai International B.V. 6389 2318 3671 41 BellSouth.net Inc. Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 10620 3460 3290 Telmex Colombia S.A. 22773 3321 3176 Cox Communications Inc. 7545 3286 3078 TPG Telecom Limited 17974 2921 2825 PT Telekomunikasi Indonesia 39891 2708 2698 SaudiNet, Saudi Telecom Compa 6389 2318 2277 BellSouth.net Inc. 4766 3164 2043 Korea Telecom 9829 2494 2032 National Internet Backbone 18566 2207 1930 MegaPath Corporation 9808 1883 1853 Guangdong Mobile Communicatio Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 65001 PRIVATE 5.143.176.0/20 15468 OJSC Rostelecom 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 16589 UNALLOCATED 8.20.247.0/24 35838 CCANET Limited 16589 UNALLOCATED 8.26.56.0/24 35838 CCANET Limited 46473 UNALLOCATED 8.27.122.0/24 3356 Level 3 Communicatio 46473 UNALLOCATED 8.27.124.0/24 3356 Level 3 Communicatio 27205 UNALLOCATED 8.38.16.0/21 3356 Level 3 Communicatio 27205 UNALLOCATED 8.38.20.0/24 32787 Prolexic Technologie Complete listing at http://thyme.rand.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 23.226.112.0/20 62788 >>UNKNOWN<< 23.249.144.0/20 40430 colo4jax, LLC 27.100.7.0/24 56096 >>UNKNOWN<< 41.73.1.0/24 37004 >>UNKNOWN<< 41.73.2.0/24 37004 >>UNKNOWN<< 41.73.3.0/24 37004 >>UNKNOWN<< 41.73.4.0/24 37004 >>UNKNOWN<< 41.73.5.0/24 37004 >>UNKNOWN<< 41.73.6.0/24 37004 >>UNKNOWN<< 41.73.7.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:13 /10:36 /11:101 /12:267 /13:512 /14:1034 /15:1762 /16:12979 /17:7590 /18:12773 /19:25883 /20:38229 /21:39950 /22:65462 /23:56907 /24:327039 /25:556 /26:593 /27:420 /28:43 /29:32 /30:14 /31:1 /32:32 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 39891 2664 2708 SaudiNet, Saudi Telecom Compa 22773 2505 3321 Cox Communications Inc. 18566 2109 2207 MegaPath Corporation 30036 1544 1728 Mediacom Communications Corp 6389 1485 2318 BellSouth.net Inc. 10620 1358 3460 Telmex Colombia S.A. 6983 1342 1694 EarthLink, Inc. 34984 1249 1964 TELLCOM ILETISIM HIZMETLERI A 11492 1171 1265 CABLE ONE, INC. 8551 1124 1628 Bezeq International-Ltd Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1591 2:748 4:21 5:2065 6:28 8:949 12:1775 13:39 14:1674 15:45 16:2 17:80 18:89 20:48 23:1477 24:1768 27:2273 31:1750 32:57 33:2 34:2 35:5 36:286 37:2253 38:1212 39:27 40:89 41:2746 42:395 43:1728 44:42 45:1810 46:2512 47:75 49:1140 50:875 51:19 52:167 54:329 55:5 56:6 57:45 58:1551 59:861 60:347 61:1811 62:1497 63:1923 64:4469 65:2146 66:4246 67:2142 68:1088 69:3248 70:1071 71:468 72:1986 74:2544 75:343 76:424 77:1370 78:1259 79:1049 80:1322 81:1351 82:924 83:693 84:819 85:1573 86:466 87:1034 88:561 89:1970 90:170 91:6055 92:875 93:2331 94:2343 95:2295 96:478 97:357 98:945 99:45 100:72 101:1051 103:10462 104:2375 105:151 106:398 107:1100 108:672 109:2325 110:1244 111:1652 112:965 113:1161 114:1047 115:1566 116:1586 117:1444 118:2050 119:1598 120:924 121:1168 122:2226 123:2010 124:1568 125:1756 128:708 129:381 130:406 131:1336 132:626 133:174 134:448 135:125 136:374 137:344 138:1729 139:254 140:385 141:468 142:657 143:891 144:646 145:157 146:865 147:679 148:1466 149:500 150:652 151:755 152:607 153:270 154:614 155:958 156:493 157:480 158:341 159:1113 160:474 161:780 162:2291 163:535 164:752 165:1052 166:312 167:1131 168:1762 169:645 170:1571 171:267 172:532 173:1705 174:733 175:724 176:1710 177:3983 178:2192 179:1170 180:2065 181:1746 182:1899 183:926 184:802 185:6280 186:3130 187:2135 188:2109 189:1726 190:7722 191:1237 192:8923 193:5732 194:4365 195:3748 196:1714 197:1107 198:5528 199:5701 200:6926 201:3727 202:10126 203:9644 204:4653 205:2712 206:2984 207:3101 208:4059 209:3795 210:3922 211:2051 212:2663 213:2206 214:851 215:72 216:5786 217:1926 218:786 219:561 220:1672 221:874 222:661 223:1193 End of report From andree+nanog at toonk.nl Fri Apr 22 18:54:52 2016 From: andree+nanog at toonk.nl (Andree Toonk) Date: Fri, 22 Apr 2016 11:54:52 -0700 Subject: google and amazon wierdness via HE right now In-Reply-To: <006401d19cbc$cc3adf10$64b09d30$@iname.com> References: <20160422172147.GI10697@sizone.org> <006401d19cbc$cc3adf10$64b09d30$@iname.com> Message-ID: <571A737C.2050108@toonk.nl> It appears HE and others accepted 'hijacked' routes from AS200759. A quick initial investigation shows close to 2,000 prefixes were affected including prefixes normally announced by networks such as Facebook, Google, Amazon, Twitter, Apple, Akamai, Time Warner Cable and more. Also see more details on the bgpmon blog here: http://www.bgpmon.net/large-hijack-affects-reachability-of-high-traffic-destinations/ Cheers Andree My secret spy satellite informs me that Frank Bulk wrote On 2016-04-22, 10:31 AM: > Being discussed on outages, too. > > Our monitoring system saw access to www.amazon.com and www.cablelabs.com > (over v6) down via HE ... amazon came back up for me via Zayo, but when > www.cablelabs.com came back up, it was on HE. So the same as you. > > So I suspect HE had a hiccup. > > Frank > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Ken Chase > Sent: Friday, April 22, 2016 12:22 PM > To: NANOG > Subject: google and amazon wierdness via HE right now > > > From toronto - something odd - mtr to google.com (google.com > (172.217.3.142)) > > 5. v638.core1.tor1.he.net > 6. 100ge7-2.core1.nyc4.he.net > 7. 100ge11-1.core1.par2.he.net > 8. 10ge3-2.core1.zrh1.he.net > 9. ??? > > par is paris, zrh is zurich? > > same base path for hitting my EC2 nodes... Cant imagine this is just > affecting Toronto > HE customers. > > EC2 node is in 107.20/14 > > /kc > > From tom at ninjabadger.net Sat Apr 23 17:52:34 2016 From: tom at ninjabadger.net (Tom Hill) Date: Sat, 23 Apr 2016 18:52:34 +0100 Subject: Arista Routing Solutions In-Reply-To: References: Message-ID: <571BB662.8000804@ninjabadger.net> On 20/04/16 15:37, Colton Conor wrote: > Can the Arista EOS software combine with their hardware based on the > Broadcom Jericho chipset truly compete with the custom chipsets and > accompanying software from the big guys? In broad strokes: for your money you're either getting port density, or more features per port. The only difference here is that there's suddenly more TCAM on the device, and I still don't see the above changing too drastically. If it works* for you, use it. :) * Assuming that you've done your due diligence before purchasing, and not just skim-read the vendor PDF. -- Tom From saku at ytti.fi Sat Apr 23 18:20:49 2016 From: saku at ytti.fi (Saku Ytti) Date: Sat, 23 Apr 2016 11:20:49 -0700 Subject: Arista Routing Solutions In-Reply-To: <571BB662.8000804@ninjabadger.net> References: <571BB662.8000804@ninjabadger.net> Message-ID: On 23 April 2016 at 10:52, Tom Hill wrote: > In broad strokes: for your money you're either getting port density, or > more features per port. The only difference here is that there's > suddenly more TCAM on the device, and I still don't see the above > changing too drastically. Yeah OP is comparing high touch chip (MX104) to low touch chip (Jericho) that is not fair comparison. And cost is what customer is willing to pay, regardless of sticker on the box. No one will pay significant mark-up for another sticker, I've never seen in RFP significant differences in comparable products. Fairer comparison would be QFX10k, instead of MX104. QFX10k is AFAIK only product in this segment which is not using Jericho. If this is competitive advantage or risk, jury is still out, I lean towards competitive advantage, mainly due to its memory design. -- ++ytti From jefftant.ietf at gmail.com Sun Apr 24 03:19:48 2016 From: jefftant.ietf at gmail.com (Jeff Tantsura) Date: Sat, 23 Apr 2016 20:19:48 -0700 Subject: Arista Routing Solutions In-Reply-To: References: <571BB662.8000804@ninjabadger.net> Message-ID: Saku, Jericho is in no sense a low end chip, while there are some scale limitations (what can be done with SuperFEC, some bridging related stuff), from functionality prospective it is a very capable silicon. One has to: Understand how to program it properly (recursiveness, ECMP?s, etc) Know how to enhance SDK Have a rather rich control plane, which can be translated into rich forwarding functionality :-) I?m not familiar with Arista?s feature set NCS with XR would be a good proof Watch for Jericho updates from DNX Cheers, Jeff On 4/23/16, 11:20 AM, "NANOG on behalf of Saku Ytti" wrote: >On 23 April 2016 at 10:52, Tom Hill wrote: >> In broad strokes: for your money you're either getting port density, or >> more features per port. The only difference here is that there's >> suddenly more TCAM on the device, and I still don't see the above >> changing too drastically. > >Yeah OP is comparing high touch chip (MX104) to low touch chip >(Jericho) that is not fair comparison. And cost is what customer is >willing to pay, regardless of sticker on the box. No one will pay >significant mark-up for another sticker, I've never seen in RFP >significant differences in comparable products. > >Fairer comparison would be QFX10k, instead of MX104. QFX10k is AFAIK >only product in this segment which is not using Jericho. If this is >competitive advantage or risk, jury is still out, I lean towards >competitive advantage, mainly due to its memory design. > >-- > ++ytti From kmedcalf at dessus.com Sun Apr 24 12:14:40 2016 From: kmedcalf at dessus.com (Keith Medcalf) Date: Sun, 24 Apr 2016 08:14:40 -0400 Subject: Arista Routing Solutions In-Reply-To: Message-ID: High Touch / Low Touch Is this a measure of the amount of fiddle diddling required to get the chip to work as documented, or is it some other kind of code? For example a "High Touch" chip needs lots of fiddle farting because it was designed by a moron and every possible thing that can be programmed incorrectly is programmed incorrectly, whereas in a "Low Touch" chip all the defaults are already set to the most useful and rational setting so that it can be used without touching it to fix all the defects? Perhaps it is a measure of the babysitting required while the chip is running. "High Touch" chips require constant attention, nappy changes, positive re-inforcement of the settings, etc., while operating because they are inherently unreliable and badly designed whereas "Low Touch" chips once set up just work and require little ongoing supervision unless you want to change something? Or is it just a strange translation for functionality (as in High End / Low End)? > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Saku Ytti > Sent: Saturday, 23 April, 2016 14:21 > To: Tom Hill > Cc: nanog list > Subject: Re: Arista Routing Solutions > > On 23 April 2016 at 10:52, Tom Hill wrote: > > In broad strokes: for your money you're either getting port density, or > > more features per port. The only difference here is that there's > > suddenly more TCAM on the device, and I still don't see the above > > changing too drastically. > > Yeah OP is comparing high touch chip (MX104) to low touch chip > (Jericho) that is not fair comparison. And cost is what customer is > willing to pay, regardless of sticker on the box. No one will pay > significant mark-up for another sticker, I've never seen in RFP > significant differences in comparable products. > > Fairer comparison would be QFX10k, instead of MX104. QFX10k is AFAIK > only product in this segment which is not using Jericho. If this is > competitive advantage or risk, jury is still out, I lean towards > competitive advantage, mainly due to its memory design. > > -- > ++ytti From saku at ytti.fi Sun Apr 24 15:02:57 2016 From: saku at ytti.fi (Saku Ytti) Date: Sun, 24 Apr 2016 08:02:57 -0700 Subject: Arista Routing Solutions In-Reply-To: References: Message-ID: On 24 April 2016 at 05:14, Keith Medcalf wrote: > High Touch / Low Touch High touch means very general purpose NPU, with off-chip memory. Low touch means usually ASIC or otherwise simplified pipeline and on-chip memory. Granted Jericho can support off-chip memory too. L3 switches are canonical example of low touch. EZchip, Trio, Solar, FP3 etc are examples of canonical high touch NPUs. What low touch can do, it can do fast and economically. But like few terms, it's not exact, and borders are hazy and even subjective. -- ++ytti From kmedcalf at dessus.com Sun Apr 24 15:57:00 2016 From: kmedcalf at dessus.com (Keith Medcalf) Date: Sun, 24 Apr 2016 11:57:00 -0400 Subject: Arista Routing Solutions In-Reply-To: Message-ID: Got it, thanks for the explanation! > -----Original Message----- > From: Saku Ytti [mailto:saku at ytti.fi] > Sent: Sunday, 24 April, 2016 11:03 > To: Keith Medcalf > Cc: nanog list > Subject: Re: Arista Routing Solutions > > On 24 April 2016 at 05:14, Keith Medcalf wrote: > > > High Touch / Low Touch > > High touch means very general purpose NPU, with off-chip memory. Low > touch means usually ASIC or otherwise simplified pipeline and on-chip > memory. Granted Jericho can support off-chip memory too. > > L3 switches are canonical example of low touch. EZchip, Trio, Solar, > FP3 etc are examples of canonical high touch NPUs. What low touch can > do, it can do fast and economically. > > But like few terms, it's not exact, and borders are hazy and even > subjective. > > > > -- > ++ytti From colton.conor at gmail.com Sun Apr 24 16:08:47 2016 From: colton.conor at gmail.com (Colton Conor) Date: Sun, 24 Apr 2016 11:08:47 -0500 Subject: Arista Routing Solutions In-Reply-To: References: <571BB662.8000804@ninjabadger.net> Message-ID: Saku, I guess you are right the QFX10002-36Q is probably a better comparison. But let's be honest, Juniper is not going to sell a QFX10002-36Q for less than $20k like Arista will do for a semi- similar box. Even with a high discount (like 90 percent off list), the Juniper QFX10002-36Q at $360k list price comes nowhere close on the price point. Cisco, Juniper, ALU, etc are all not going to see a low cost high density fixed switch because that would cannibalize on their sales on the larger platforms. I really think Arista is kind of unique here as they don't have another routing platform to cannibalize, so they are competitively pricing their platform. So I guess the question becomes, what features are missing that Arista does not currently have? They seems to be adding more and more features, and taking more market share. Here is a list of features supported: https://www.arista.com/en/support/product-documentation/supported-features I have not personally used Arista myself, but I like what I am seeing as far as price point, company culture, and repruatation in the market place. I know their switching is solid, but I am not sure about their routing. Arista claims to have much, much faster BGP convergence time than all the other vendors. On Sat, Apr 23, 2016 at 1:20 PM, Saku Ytti wrote: > On 23 April 2016 at 10:52, Tom Hill wrote: > > In broad strokes: for your money you're either getting port density, or > > more features per port. The only difference here is that there's > > suddenly more TCAM on the device, and I still don't see the above > > changing too drastically. > > Yeah OP is comparing high touch chip (MX104) to low touch chip > (Jericho) that is not fair comparison. And cost is what customer is > willing to pay, regardless of sticker on the box. No one will pay > significant mark-up for another sticker, I've never seen in RFP > significant differences in comparable products. > > Fairer comparison would be QFX10k, instead of MX104. QFX10k is AFAIK > only product in this segment which is not using Jericho. If this is > competitive advantage or risk, jury is still out, I lean towards > competitive advantage, mainly due to its memory design. > > -- > ++ytti > From saku at ytti.fi Sun Apr 24 16:25:47 2016 From: saku at ytti.fi (Saku Ytti) Date: Sun, 24 Apr 2016 09:25:47 -0700 Subject: Arista Routing Solutions In-Reply-To: References: <571BB662.8000804@ninjabadger.net> Message-ID: On 24 April 2016 at 09:08, Colton Conor wrote: Hey, > I guess you are right the QFX10002-36Q is probably a better comparison. But > let's be honest, Juniper is not going to sell a QFX10002-36Q for less than > $20k like Arista will do for a semi- similar box. Even with a high discount > (like 90 percent off list), the Juniper QFX10002-36Q at $360k list price > comes nowhere close on the price point. Cisco, Juniper, ALU, etc are all not > going to see a low cost high density fixed switch because that would > cannibalize on their sales on the larger platforms. I really think Arista is > kind of unique here as they don't have another routing platform to > cannibalize, so they are competitively pricing their platform. 20k seems a stretch, that's like 94.5% discount, it's not unheard off. If you have volume, I would imagine it being doable. > So I guess the question becomes, what features are missing that Arista does > not currently have? They seems to be adding more and more features, and > taking more market share. Here is a list of features supported: > https://www.arista.com/en/support/product-documentation/supported-features I > have not personally used Arista myself, but I like what I am seeing as far > as price point, company culture, and repruatation in the market place. I > know their switching is solid, but I am not sure about their routing. Yeah they are ccertainly much behind in features, but if you don't need those features, it's probably actually an advantage. For my use-cases Arista's MPLS stack is not there. > Arista claims to have much, much faster BGP convergence time than all the > other vendors. I wouldn't be surprised, but honestly the competition does not set the bar high there. -- ++ytti From ltd at interlink.com.au Sun Apr 24 23:47:07 2016 From: ltd at interlink.com.au (lincoln dale) Date: Sun, 24 Apr 2016 16:47:07 -0700 Subject: Arista Routing Solutions In-Reply-To: References: Message-ID: > > > High Touch / Low Touch > > High touch means very general purpose NPU, with off-chip memory. Low > touch means usually ASIC or otherwise simplified pipeline and on-chip > memory. Granted Jericho can support off-chip memory too. > > L3 switches are canonical example of low touch. EZchip, Trio, Solar, > FP3 etc are examples of canonical high touch NPUs. What low touch can > do, it can do fast and economically. > Your analogy makes some sense, but what you classify as high-touch / low-touch is just one dimension and could do with a more modern update. I'd suggest a more modern analogy would be that historically the difference between a L3 switch and a router is the former has a fixed processing pipeline, limited buffering (most are just on-chip buffer) and limited table sizes. But more modern packet processors with fixed pipelines often have blocks or sections that are programmable or flexible. e.g. with a flexible packet parser, its possible to support new overlay or tunnel mechanisms, flexible key generation makes it possible to reuse different table resources in different ways, flexible rewrite engine means egress encap or tunnels or logic can be done. There's also often more capacity for recirc or additional stages as required. Specific to Jericho, the underlying silicon has all these characteristics. We [*] used the flexibility in all of the stages both now and in previous iterations (Arad) to add new features/functionality that wasn't natively there to start with. And it uses a combination of on-chip & off-chip buffering with VoQ Its also not only Arista that call it a router cisco do too (NCS5K5). Sure, using a NPU for packet processing essentially provided a 100% programmable packet forwarding pipeline, and maybe even a "run to completion" kind of packet pipeline where the pipeline could have a long tail of processing. However, engineering is a zero sum game, and to do that means you sacrifice power or density, or most often, both. I agree the lines have been blurred as to the characteristics, and we'd openly state that its not going to be useful in every use case of where a router is deployed, but for specific use cases, it fits the bill and has compelling density, performance and cost dynamics. To the OPs question, there are people running with this in EFT and others in production. My suggestion would be that if you think its of interest, reach out to your friendly Arista person [*] and try it out or talk through what it is you're after. We are generally a friendly bunch and often we can be quite creative in enabling things in different ways to old. > Yeah they are certainly much behind in features, but if you don't > need those features, it's probably actually an advantage. For my > use-cases Arista's MPLS stack is not there. We've historically had the data-plane but not the control-plane. Thats a work in progress. Again, often there are creative solutions to ways of doing things that aren't necessarily the same as old ways but achieve the same end result. cheers, lincoln. [*] disclosure: i work on said products described ltd at arista.com. From chris.welti at switch.ch Tue Apr 19 13:46:21 2016 From: chris.welti at switch.ch (Chris Welti) Date: Tue, 19 Apr 2016 15:46:21 +0200 Subject: NCS5K? Message-ID: <571636AD.3020603@switch.ch> According to some slides from a russian cisco connect event, the upcoming small-size NCS 5501 and NCS 5502 will support 1M+ FIB and 50ms per port buffers. Seem to be killer boxes. 48x100GE in 2RU with large FIB & buffers? Loving it already. I wonder what prices will look like for those. With Google Translate: NCS 5501 ? 800 Gbps @ 430 watts ? 40 x SFP + 1G / 10G + 4 x QSFP28 100G ? 1RU ? Intel Broadwell CPU 8Core @ 1.6GHz ? Dimensions WxDxH 444mm x551mm x 44mm ? External TCAM for more FIB, large buffers (~ 50 ms) ? 1-2M IPv4 FIB ? The same set of features as a modular ? FCS in IOS XR 6.1.1 NCS 5502 ? 4.8 Tbps 100G @ ~ 2200 W ? 48 x QSFP 28 or QSFP + optics ? 2RU ? Intel Broadwell CPU 12Core @ 1.6GHz ? 8 ASIC packet processing ? Integrated FIA ? External FIB TCAM for more ? Large buffers (~ 50 ms) ? 1-2M IPv4 FIB ? The same set of features as a modular ? FCS in IOS XR 6.1.1 On Mon Jan 25 18:01:41 EST 2016, Phil Bedard wrote: > My guess is you will see something from Cisco similar to the PTX1K in the > NCS 55XX series but it will be more expensive than the 500X series. These > boxes I believe use the Broadcom Tomahawk chipset and the NCS55XX uses the > Jericho. The Jericho can support an external TCAM with more routes but > with some speed limitations since the bus to the off-chip TCAM memory is > slower. Those boxes will also have more packet buffering than what you'll > find on the 500X. > > Either way the cost of 100G is rapidly dropping, crazy to think what we > paid for just a CFP transceiver a few years ago. From a.slastenov at gmail.com Wed Apr 20 07:00:32 2016 From: a.slastenov at gmail.com (Andrey Slastenov) Date: Wed, 20 Apr 2016 10:00:32 +0300 Subject: ASR-9K CPU troubleshooting In-Reply-To: References: <20160418111449.E7751428@m0087798.ppops.net> <5716B9E0.6080803@coldnorthadmin.com> Message-ID: <24B3086C-23B1-43ED-92DD-E739ECA1E089@gmail.com> You should check a log files during the time of high cpu load. ASR9K do most of the packet processing on NP. High CPU load may happen during some control plane processing, like bgp neighbor flapping. ?????????? ? iPhone > 20 ???. 2016 ?., ? 2:17, Micah Croff ???????(?): > > I've experienced similar behavior on other platforms as well. Sometimes > the output of the box is not correct. We were able to prove this to the > vendor by conducting experiments and graphing the CPU. One of the > protocols they said "couldn't possibly be causing this" turned out to be > the root of the problem. > > I live by one rule when troubleshooting: > The box is a lie. > > Micah > > > On Tue, Apr 19, 2016 at 4:06 PM, Laurent Dumont > wrote: > >> It coincides with nothing else? More traffic? CPU increasing at regular >> intervals every day without any obvious reasons is probably something worth >> looking into! >> >>> On 4/18/2016 2:14 PM, Scott Weeks wrote: >>> >>> >>> --- regezos at gmail.com wrote: >>> From: Rukka Pal >>> >>> How do you guys troubleshoot high CPU utilization on the ASR-9K platform? >>> Detailed guides are available for IOS platforms, but I can't seem to find >>> anything useful for the ASR. >>> >>> The average line-card (0/0/CPU0: A9K-24x10GE-TR) CPU utilization of my >>> routers is about 10%, however recently I have noticed that 3-5 times a day >>> it increases to 40% and stays there for about an hour (20% spp + 10% netio >>> + the rest). >>> >>> I know this is well withing the acceptable range, but I am the kind of >>> person who likes to understand every change in his network and during the >>> investigation I had to realize that I simply don't have the tools to >>> troubleshoot the ASR CPU. >>> ----------------------------------- >>> >>> >>> On cisco: sho proc cpu >>> >>> scott >> >> From rwoolleynanog at gmail.com Wed Apr 20 20:48:46 2016 From: rwoolleynanog at gmail.com (Ryan Woolley) Date: Wed, 20 Apr 2016 16:48:46 -0400 Subject: Arista Routing Solutions In-Reply-To: References: Message-ID: Colton Conor wrote: > I know Arista is typically a switch manufacturer, but with their recently > announced Arista 7500R Series and soon to be announced but already shipping > 7280R Series Arista is officially getting into the routing game. The fixed > 1U 7280R Series looks quite impressive. The 7500R series is your > traditional chassis and line card based solution. > > Both of these products have the ability to hold the full internet routing > table, and Arista is working on MPLS features. Both of these new products > use the latest Broadcom Jerico chipsets. We (Netflix) have been deploying the previous gen (7500E) as edge routers for about two years in high traffic, low route count applications in our CDN, and have been working with Arista for almost as long to improve route scale so that we could turn off all our traditional routers. The features that enable full routes on Jericho are running in our production network today and we also have the 7500R and 7280R working with full tables. I can't speak to MPLS, but for our use case (all L3, very high-density 10/40/100G, BGP, IS-IS and light QoS), it's working well. So, yes, I'd say those two products are quite viable and competitive options in the edge router space. From joe at nethead.com Thu Apr 21 02:51:13 2016 From: joe at nethead.com (Joe Hamelin) Date: Wed, 20 Apr 2016 19:51:13 -0700 Subject: CDN, Steam, Origin and NAT. In-Reply-To: <57183A9D.5000004@coldnorthadmin.com> References: <57183A9D.5000004@coldnorthadmin.com> Message-ID: You can always bring up an HE IPv6 tunnel and hand out public IPs that way. -- Joe Hamelin, W7COM, Tulalip, WA, +1 (360) 474-7474 On Wed, Apr 20, 2016 at 7:27 PM, Laurent Dumont wrote: > Hi, > > We are running a small-ish LAN event in Toronto where we have to use a > single IP address to NAT between 250-350 players. I have been made aware of > possible issues with different services like Steam, Origin and Twitch who > can run into issues when a large number of connections seem to originate > from a single IP address. I just wanted to poke the list to see if anyone > can chime him on their experiences with NATing customers and the impact it > might have on public services. I am usually using public IP address space > for players when designing most large LAN events. Dealing with NAT for a > medium-ish amount of customers is not something I am used to do. > > It feels silly to worry about that when you assume that WISP > sometimes(mostly?) use CGN when providing internet to customers. The same > could be said of most large office buildings around the world. > > I appreciate any input on the matter! > > Thanks > > Laurent > From me at tpenrose.co.uk Thu Apr 21 08:34:54 2016 From: me at tpenrose.co.uk (Thomas Penrose) Date: Thu, 21 Apr 2016 09:34:54 +0100 Subject: CDN, Steam, Origin and NAT. In-Reply-To: <57183A9D.5000004@coldnorthadmin.com> References: <57183A9D.5000004@coldnorthadmin.com> Message-ID: Hey Laurent, On Thu, Apr 21, 2016 at 3:27 AM, Laurent Dumont wrote: > Hi, > > We are running a small-ish LAN event in Toronto where we have to use a > single IP address to NAT between 250-350 players. I have been made aware of > possible issues with different services like Steam, Origin and Twitch who > can run into issues when a large number of connections seem to originate > from a single IP address. I just wanted to poke the list to see if anyone > can chime him on their experiences with NATing customers and the impact it > might have on public services. I am usually using public IP address space > for players when designing most large LAN events. Dealing with NAT for a > medium-ish amount of customers is not something I am used to do. > My $Dayjob run big LAN party events in the UK. We mostly run public v4/v6 to players for the issues you identified, however we have previously NATed our exhibitions and selected chunks of machines for various reasons and have never really come across any issues. I would say that the most I have NATed is around 50 machines, so I can't say for certain that 250-300 will be OK, but in my experience I've not seen any issues with Steam / Origin. Things I would watch out for are specific games, things like LOL and Runescape tend to have their own numbers of players per public v4. Is it only a single IP you have? If you could get any more you could NAT overload chunks of people to different IP addresses limiting your login pool size? The main issue we see with these big CDN services is bandwidth - lots of people getting to the LAN and updating all their games! Not sure how much you struggle with this, but if you do, check out - https://github.com/multiplay/lancache. Hope this helps! Tom From skennedy at office.vcn.com Tue Apr 19 04:07:10 2016 From: skennedy at office.vcn.com (Sean Kennedy) Date: Mon, 18 Apr 2016 22:07:10 -0600 Subject: As a SP, what is your standard CoS configuration on JunOS? Message-ID: NANOG, I realize that every SP handles marking and queueing/scheduling differently, but I am curious to see other provider's 'standard' config for QoS that is deployed on the JunOS platform. What config do apply to all your ingress interfaces for classification? How are your core link schedulers configured? What kind of remarking do you do (specifically on packets arriving on internet-facing interfaces)? If you have a converged network carrying both internet and carrier-eth/transport traffic, how do you handle guaranteeing bandwidth to the carrier eth services? Thank you, Sean From ti14m028 at technikum-wien.at Thu Apr 21 07:46:13 2016 From: ti14m028 at technikum-wien.at (Martin Bacher) Date: Thu, 21 Apr 2016 09:46:13 +0200 Subject: BGP FlowSpec Message-ID: Dear Nanog Members, My name is Martin Bacher. I am a Student at UAS Technikum-Wien and I am currently writing my master?s thesis with topic "Addressing DDoS Attacks with BGP FlowSpec?. It would be very helpful for me if some of you could share information about the following topics: - Intra-AS BGP FlowSpec deployment: Who is running it? For which kind of attacks are you using it? Are you only dropping or rate-limiting certain traffic or are you also using the redirect/remark capabilities? What are the limitations from your perspective? Are you facing any operational issues? How are you injecting the FlowSpec routes? - Inter-AS: Who is running Inter-AS FlowSpec deployments? What is your experience? Are there any concerns regarding Inter-AS deployments? Has anyone done interop tests? FlowSpec is usually only one part of the whole anti DDoS toolset. So I would also be interested in your answers to the following questions: - How are you detecting DDoS attacks (Netflow, in-line probes, ..?) and which applications are you using for the analysis (Peakflow, Open-Source tools, ..?) - Which countermeasures are you deploying in case of DDoS attacks? ACLs, FlowSpec, Blackhole routes, RTBH, scrubbing center, Cloud based DDoS services or anything else? - What is your operational experience? How fast are you in deploying countermeasures? Do you have any automation or is this always triggered by people? Last but not least: I am also looking for anonymized statistical data about DDoS attacks which I could use in the thesis. I am mainly interested in data about the type of attacks, attack time, sources, source and destination ports, and so on. I know this something which is generally not shared, so I would really appreciate it if someone would be able to share such data. Please send me your answers either via pn or directly to the list. Please also let me know if you think that there is something missing. Any comment or answer is highly appreciated. Looking forward to your replies. Many thanks. Greetings, Martin From me at tpenrose.co.uk Thu Apr 21 08:46:09 2016 From: me at tpenrose.co.uk (Thomas Penrose) Date: Thu, 21 Apr 2016 09:46:09 +0100 Subject: Arista Routing Solutions In-Reply-To: References: Message-ID: Hey Colton, Comments inline: On Wed, Apr 20, 2016 at 3:37 PM, Colton Conor wrote: > NANOG, > > I know Arista is typically a switch manufacturer, but with their recently > announced Arista 7500R Series and soon to be announced but already shipping > 7280R Series Arista is officially getting into the routing game. The fixed > 1U 7280R Series looks quite impressive. The 7500R series is your > traditional chassis and line card based solution. > I must admit, i'm not usually excited by new hardware, but this announcement did catch my eye! Both of these products have the ability to hold the full internet routing > table, and Arista is working on MPLS features. Both of these new products > use the latest Broadcom Jerico chipsets. > > I would like to know how viable of a product NANOG thinks these Arista > routers are compared to service provider grade routers from Cisco, Juniper, > ALU, and Brocade? > Honestly? I think you need to look at what you actually need out of a box. At the end of the day, its a 1U switch. If you want to terminate a GRT a the edge of your network and do some basic path selection then it sounds like it would be an amazing and cheap fit. On the other hand, I don't think we can start throwing away core routers yet ;) Cost wise, Arista seems to be much, much less per port. For example, the > 1U Arista 7280R with 48x10GbE (SFP+) & 6x100GbE QSFP cost about the same as > what Juniper sells a MX104 with only four 10G ports for (Under 20K). > I'm consistently amazed at the density they are achieving for the $$ and I think it all comes down to what the actual application is here. Most basic BGP networks do not need all the bells and whistles of the MX104 and will really benefit from the extra port density. That being said, I wouldn't be replacing core PoPs in large ISPs with 1U switches! > Can the Arista EOS software combine with their hardware based on the > Broadcom Jericho chipset truly compete with the custom chipsets and > accompanying software from the big guys? > I've used Arista for a while now (Moving from Cisco / Extreme) and I truly believe that their software is excellent. They just seem to be doing it 'the right way', If you've not watched it, this video is worth a bit of your time! https://www.youtube.com/watch?v=VdJZq4dRjf4 Thats my $0.02 anyway Tom From mlfreita at mtu.edu Thu Apr 21 13:48:48 2016 From: mlfreita at mtu.edu (Matt Freitag) Date: Thu, 21 Apr 2016 09:48:48 -0400 Subject: CDN, Steam, Origin and NAT. In-Reply-To: <57183A9D.5000004@coldnorthadmin.com> References: <57183A9D.5000004@coldnorthadmin.com> Message-ID: Hi Laurent, We regularly have people run 50-150 person events with everyone sharing a single external IP and have minimal issues. Our biggest events are League of Legends tournaments and I believe those are streamed on Twitch. I don't think you are going to have a problem, but feel free to hit me up for ideas if you do run into issues. Matt Freitag Network Engineer I Information Technology Michigan Technological University (906) 487-3696 http://www.mtu.edu/ http://www.it.mtu.edu/ -----Original Message----- From: NANOG [mailto:nanog-bounces+mlfreita=mtu.edu at nanog.org] On Behalf Of Laurent Dumont Sent: Wednesday, April 20, 2016 10:28 PM To: nanog at nanog.org Subject: CDN, Steam, Origin and NAT. Hi, We are running a small-ish LAN event in Toronto where we have to use a single IP address to NAT between 250-350 players. I have been made aware of possible issues with different services like Steam, Origin and Twitch who can run into issues when a large number of connections seem to originate from a single IP address. I just wanted to poke the list to see if anyone can chime him on their experiences with NATing customers and the impact it might have on public services. I am usually using public IP address space for players when designing most large LAN events. Dealing with NAT for a medium-ish amount of customers is not something I am used to do. It feels silly to worry about that when you assume that WISP sometimes(mostly?) use CGN when providing internet to customers. The same could be said of most large office buildings around the world. I appreciate any input on the matter! Thanks Laurent From chris.welti at switch.ch Fri Apr 22 08:26:18 2016 From: chris.welti at switch.ch (Chris Welti) Date: Fri, 22 Apr 2016 10:26:18 +0200 Subject: Latency, TCP ACKs and upload needs In-Reply-To: <20160420142753.GA58668@ussenterprise.ufp.org> References: <5716DB68.1080801@vaxination.ca> <20160420142753.GA58668@ussenterprise.ufp.org> Message-ID: <5719E02A.4030909@switch.ch> On 20/04/16 16:27, Leo Bicknell wrote: > 90%+ of the stacks deployed will be too small. Modern Unix generally > has "autotuning" TCP stacks, but I don't think Windows or OS X has > those features yet (but I'd be very happy to be wrong on that point). > Regardless of satellite uplink/downlink speeds, boxes generally need > to be tuned to get maximum performance on satellite. Windows also has TCP buffers auto-tuning since Windows 7/Vista up to 16MB, however only receiver-side tuning on their client versions, for sender-side tuning you will need a server version. That means uploading stuff from a regular windows "client" machine to a remote host with a large RTT will be very slow. -- Chris From ahm.joel at gmail.com Fri Apr 22 09:20:54 2016 From: ahm.joel at gmail.com (joel ahumuza) Date: Fri, 22 Apr 2016 12:20:54 +0300 Subject: LDP flaps specifically present on ACX Juniper routers (ACX4000 and ACX1100) Message-ID: Hi All, We are experiencing an issue with ACX routers running on 12.3X54-D20.7 where the LDP sessions are continuously flapping, the logs indicate the following; Apr 21 03:36:31 hostname rpd[2299]: RPD_LDP_SESSIONDOWN: LDP session x.x.x.x is down, reason: hold time expired Apr 21 03:36:34 hostname rpd[2299]: RPD_LDP_NBRDOWN: LDP neighbor x.x.x.x (lo0.0) is down Apr 21 03:36:38 hostname rpd[2299]: RPD_LDP_NBRDOWN: LDP neighbor x.x.x.x (lo0.0) is down Apr 21 03:36:38 hostname rpd[2299]: RPD_LDP_SESSIONDOWN: LDP session x.x.x.x is down, reason: all adjacencies down Apr 21 03:55:34 hostname rpd[2299]: RPD_LDP_SESSIONDOWN: LDP session x.x.x.x is down, reason: received notification from peer Apr 21 03:55:34 hostname rpd[2299]: RPD_LDP_SESSIONDOWN: LDP session x.x.x.x is down, reason: received notification from peer Apr 21 03:55:35 hostname rpd[2299]: RPD_LDP_SESSIONDOWN: LDP session x.x.x.x is down, reason: received notification from peer Apr 21 03:55:35 hostname rpd[2299]: RPD_LDP_SESSIONDOWN: LDP session x.x.x.x is down, reason: received notification from peer Actions taken from our team was; - Increase the hold time setting on the ldp enabled interfaces. - Increase the time interval on the same ldp enabled interfaces. - setting the ldp session protection setting on the ldp enabled loopback interface. Unfortunately the actions did not yield much since the flaps have been ongoing. Anyone have any Idea on what the problem / solution might be? -- Blessings, Joel Ahumuza SkypeID - jl.hmz + 256-75-1040411 | + 256-78-2040411 From tommyj27 at gmail.com Fri Apr 22 17:32:45 2016 From: tommyj27 at gmail.com (Thomas Johnson) Date: Fri, 22 Apr 2016 12:32:45 -0500 Subject: google and amazon wierdness via HE right now In-Reply-To: <20160422172227.GJ10697@sizone.org> References: <20160422172147.GI10697@sizone.org> <20160422172227.GJ10697@sizone.org> Message-ID: We saw disconnections to Comcast via HE, A subnet was announced with a bogus path. -- During the problem -- 98.224.0.0/11 via 162.11.22.209 on vlan500 [ibgp_border 12:09:48 from 162.11.22.212] * (100/15) [AS65021i] Type: BGP unicast univ BGP.origin: IGP BGP.as_path: 6939 200759 65021 BGP.next_hop: 184.5.5.69 BGP.local_pref: 100 -- Returned to normal -- 98.192.0.0/10 via 162.11.22.209 on vlan500 [ibgp_border 2016-03-17 from 162.11.22.212] (100/15) [AS7922i] Type: BGP unicast univ BGP.origin: IGP BGP.as_path: 6939 7922 BGP.next_hop: 184.5.5.69 BGP.local_pref: 100 On Fri, Apr 22, 2016 at 12:22 PM, Ken Chase wrote: > and of course the second I post it all fixes itself. NANOG works! Thanks! > > (was going on for about 10-15 min) > > On Fri, Apr 22, 2016 at 01:21:47PM -0400, Ken Chase said: > > > >From toronto - something odd - mtr to google.com (google.com (172.217.3.142)) > > > > 5. v638.core1.tor1.he.net > > 6. 100ge7-2.core1.nyc4.he.net > > 7. 100ge11-1.core1.par2.he.net > > 8. 10ge3-2.core1.zrh1.he.net > > 9. ??? > > > >par is paris, zrh is zurich? > > > >same base path for hitting my EC2 nodes... Cant imagine this is just affecting Toronto > >HE customers. > > > >EC2 node is in 107.20/14 > > > >/kc > > /kc From stahr at mailbag.com Fri Apr 22 18:19:12 2016 From: stahr at mailbag.com (James Stahr) Date: Fri, 22 Apr 2016 13:19:12 -0500 Subject: google and amazon wierdness via HE right now In-Reply-To: <006401d19cbc$cc3adf10$64b09d30$@iname.com> References: <20160422172147.GI10697@sizone.org> <006401d19cbc$cc3adf10$64b09d30$@iname.com> Message-ID: <571A6B20.8040504@mailbag.com> On 04/22/2016 12:31 PM, Frank Bulk wrote: > Being discussed on outages, too. > > Our monitoring system saw access to www.amazon.com and www.cablelabs.com > (over v6) down via HE ... amazon came back up for me via Zayo, but when > www.cablelabs.com came back up, it was on HE. So the same as you. > > So I suspect HE had a hiccup. > > Frank > > Hijack: https://twitter.com/bgpmon?ref_src=twsrc%5Etfw -James > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Ken Chase > Sent: Friday, April 22, 2016 12:22 PM > To: NANOG > Subject: google and amazon wierdness via HE right now > > > > From toronto - something odd - mtr to google.com (google.com > (172.217.3.142)) > > 5. v638.core1.tor1.he.net > 6. 100ge7-2.core1.nyc4.he.net > 7. 100ge11-1.core1.par2.he.net > 8. 10ge3-2.core1.zrh1.he.net > 9. ??? > > par is paris, zrh is zurich? > > same base path for hitting my EC2 nodes... Cant imagine this is just > affecting Toronto > HE customers. > > EC2 node is in 107.20/14 > > /kc > > > > From routetarget at gmail.com Sun Apr 24 01:33:17 2016 From: routetarget at gmail.com (RT Parrish) Date: Sat, 23 Apr 2016 20:33:17 -0500 Subject: phone fun, was GeoIP database issues and the real world consequences In-Reply-To: <5717B615.5090707@gmail.com> References: <20160420152023.17423.qmail@ary.lan> <5717B615.5090707@gmail.com> Message-ID: Dan, I think that you mean that AT&T is the 1-800 pound gorilla. I know engineers at AT&T that are bitter about that whole arrangement this many years on. I miss the glory days of everyone and their uncle spinning up a CLEC in the mid-90's. It made the ordering process complicated, especially if you were looking for local loop diversity and had to dig into which ILEC circuit things wee riding. Of course we were still doing lots of ISDN and the introduction of DSL was making life interesting for the smaller regional ISPs as well. Cheers, RT Sent from my PINE emulated client > On Apr 20, 2016, at 12:02 PM, Dan Lacey wrote: > > Great explanation! > > Remember that LECs (Local Exchange Carrier, CenturyLink, Verizon, etc.) typically get to decide how this all works... > ATT is still an 800 pound gorilla and a couple years ago stopped ALL payments to CLECs (Competitive Local Exchange Carrier, buy wholesale from LECs), took them all to court (which for a CLEC, it is almost impossible to find a good lawyer not on retainer to a LEC) and basically just told everyone what they would pay... > > Since all the LECs started offering unlimited long distance, they could not afford the termination fees. > So... They changed them!!! > > Telco is very different from data, not in the physical aspects, but in the business and political areas. > > On 4/20/16 9:20 AM, John Levine wrote: >>>> For the most part, ?long distance? calls within the US are a thing of the >>>> past and at least one mobile carrier now treats US/CA/MX as a single >>>> local calling area >>> Is this a case of telcos having switched to IP trunks and can reach >>> other carriers for "free" >> No, it's because fiber bandwidth is so cheap. It's equally cheap whether >> the framing is ATM or IP. >> >>> Or are wholesale long distance still billed between carriers but at >>> prices so low that they can afford to offer "free" long distance at >>> retail level ? >> Some of each. Some carriers do reciprocal compensation at very low >> rates, small fractions of a cent per minute, some do bill and keep >> with no settlements at all. >> >> The history of settlements is closely tied to the history of the >> Internet. Before the Bell breakup separations (within Bell) and >> settlements (between Bell and independents) were uncontentious, moving >> money around to make the rate of return on invested capital at each >> carrier come out right. >> >> Then when cell phones were new, the Bell companies observed that >> traffic was highly imbalanced, far more cell->landline than the other >> way, so they demanded high reciprocal compensation, and the cellcos >> were willing to pay since it gave the Bells the incentive to build the >> interconnecting trunks. One of Verizon's predecessors famously >> derided "bilk and keep." >> >> Then the dialup Internet became a big thing, the Bells ignored it as a >> passing fad (which it was, but not for the reasons they thought), and >> CLECs realized they could build modem banks and make a lot of money >> from the incoming calls from Bell customers to the modems. So the >> Bells did a pirouette and suddenly discovered that bill and keep was a >> law of nature and recip comp was a quaint artifact that needed to be >> snuffed out as fast as possible. >> >> These days the FCC likes to see cost justifications for settlements, >> and the actual per-minute cost of calls is tiny compared to the fixed >> costs of the links and equipment. The main place where you see >> settlements is to tiny local telcos with very high costs, with the per >> minute payments a deliberate subsidy to them. Then some greedy little >> telcos added conference call lines to pump up their incoming traffic ... >> >> R's, >> John > From freetexwatson at gmail.com Mon Apr 25 00:59:41 2016 From: freetexwatson at gmail.com (b f) Date: Sun, 24 Apr 2016 20:59:41 -0400 Subject: Firewall list recommendations (config conversion options) Message-ID: Hi list, Could any one recommend any firewall related mailing lists? Looking for options on converting a large amount of Fortinet rules to Checkpoint. Ultimately converting the entire configuration to Checkpoint would be nice. Thank you for any advice you can provide. Respectfully, Ed From mark.tinka at seacom.mu Mon Apr 25 05:03:25 2016 From: mark.tinka at seacom.mu (Mark Tinka) Date: Mon, 25 Apr 2016 07:03:25 +0200 Subject: As a SP, what is your standard CoS configuration on JunOS? In-Reply-To: References: Message-ID: <3c74917f-2b5e-f69e-88b2-865b4dc21fdc@seacom.mu> On 19/Apr/16 06:07, Sean Kennedy wrote: > NANOG, > > I realize that every SP handles marking and queueing/scheduling > differently, but I am curious to see other provider's 'standard' > config for QoS that is deployed on the JunOS platform. What config do > apply to all your ingress interfaces for classification? How are your > core link schedulers configured? What kind of remarking do you do > (specifically on packets arriving on internet-facing interfaces)? If > you have a converged network carrying both internet and > carrier-eth/transport traffic, how do you handle guaranteeing > bandwidth to the carrier eth services? Upstream and peering facing ports get re-marked to DSCP 0 on ingress. Outbound traffic toward customers from any sources, as well as traffic handed off to upstreams and peers is re-marked to DSCP 0 prior to be pushed out, as we've noticed "bad things" can happen when other networks do special things with non-DSCP 0 values they may receive. Mark. From xmin0s at gmail.com Mon Apr 25 05:06:32 2016 From: xmin0s at gmail.com (Tim Eberhard) Date: Sun, 24 Apr 2016 23:06:32 -0600 Subject: Firewall list recommendations (config conversion options) In-Reply-To: References: Message-ID: The firewall mailing lists tend to be pretty dead now a days. Your best bet is probably writing a python script to convert the rules/objects over. You may have some luck asking the vendors professional services group to do it. Depending on the size of the order perhaps you can toss it in or just add the hours to the PO. Most PS groups have scripts already written to convert from other vendors configs to their platform. Good luck, -Tim Eberhard On Sun, Apr 24, 2016 at 6:59 PM, b f wrote: > Hi list, > > Could any one recommend any firewall related mailing lists? > > Looking for options on converting a large amount of Fortinet rules to > Checkpoint. Ultimately converting the entire configuration to Checkpoint > would be nice. > > Thank you for any advice you can provide. > > Respectfully, > > Ed > From A.L.M.Buxey at lboro.ac.uk Mon Apr 25 08:31:25 2016 From: A.L.M.Buxey at lboro.ac.uk (A.L.M.Buxey at lboro.ac.uk) Date: Mon, 25 Apr 2016 08:31:25 +0000 Subject: Firewall list recommendations (config conversion options) In-Reply-To: References: Message-ID: <20160425083125.GA30464@lboro.ac.uk> Hi, > > Looking for options on converting a large amount of Fortinet rules to > > Checkpoint. Ultimately converting the entire configuration to Checkpoint > > would be nice. theres a post online asking the same question back in early 2010 with no responses... there are also a lost of tools that do Checkpoint TO Fortinet - says something? ;-) but actually, looking for firewall conversion tools does give you a picture of typical/common moves :) alan From randy at psg.com Mon Apr 25 12:03:11 2016 From: randy at psg.com (Randy Bush) Date: Mon, 25 Apr 2016 21:03:11 +0900 Subject: trout views Message-ID: nfs0.dfw.rg.net:/root# ping 128.223.51.20 PING 128.223.51.20 (128.223.51.20) 56(84) bytes of data. From 4.69.145.11 icmp_seq=1 Time to live exceeded From 4.69.145.11 icmp_seq=2 Time to live exceeded ^C --- 128.223.51.20 ping statistics --- 2 packets transmitted, 0 received, +2 errors, 100% packet loss, time 1001ms nfs0.dfw.rg.net:/root# traceroute 128.223.51.20 traceroute to 128.223.51.20 (128.223.51.20), 30 hops max, 60 byte packets 1 r0.dfw.rg.net (198.180.152.3) 1.571 ms 1.559 ms 1.597 ms 2 r1.dfw.rg.net (198.180.152.2) 0.558 ms 0.551 ms 0.640 ms 3 ge-102-0-0-29-53.r08.dllstx09.us.bb.gin.ntt.net (157.238.224.205) 1.562 ms 1.598 ms 1.716 ms 4 ae-12.r07.dllstx09.us.bb.gin.ntt.net (129.250.3.107) 0.488 ms 0.538 ms 0.582 ms 5 * * * 6 * * * 7 ae-65-65.csw1.Dallas1.Level3.net (4.69.206.133) 0.514 ms 0.555 ms ae-95-95.csw4.Dallas1.Level3.net (4.69.206.145) 0.525 ms 8 ae-3-80.edge2.Dallas1.Level3.net (4.69.145.139) 0.627 ms 0.769 ms ae-1-60.edge2.Dallas1.Level3.net (4.69.145.11) 0.633 ms 9 vlan90.csw4.Dallas1.Level3.net (4.69.145.254) 0.517 ms vlan80.csw3.Dallas1.Level3.net (4.69.145.190) 0.589 ms 0.676 ms 10 ae-1-60.edge2.Dallas1.Level3.net (4.69.145.11) 0.519 ms ae-3-80.edge2.Dallas1.Level3.net (4.69.145.139) 0.632 ms ae-4-90.edge2.Dallas1.Level3.net (4.69.145.203) 13.412 ms 11 vlan60.csw1.Dallas1.Level3.net (4.69.145.62) 13.264 ms 0.604 ms vlan80.csw3.Dallas1.Level3.net (4.69.145.190) 0.530 ms 12 ae-1-60.edge2.Dallas1.Level3.net (4.69.145.11) 0.633 ms 0.519 ms 0.513 ms 13 vlan80.csw3.Dallas1.Level3.net (4.69.145.190) 0.540 ms vlan60.csw1.Dallas1.Level3.net (4.69.145.62) 13.318 ms vlan90.csw4.Dallas1.Level3.net (4.69.145.254) 0.554 ms 14 ae-3-80.edge2.Dallas1.Level3.net (4.69.145.139) 0.723 ms ae-4-90.edge2.Dallas1.Level3.net (4.69.145.203) 12.793 ms ae-1-60.edge2.Dallas1.Level3.net (4.69.145.11) 0.494 ms 15 vlan80.csw3.Dallas1.Level3.net (4.69.145.190) 0.554 ms vlan90.csw4.Dallas1.Level3.net (4.69.145.254) 0.541 ms vlan80.csw3.Dallas1.Level3.net (4.69.145.190) 2.040 ms 16 ae-4-90.edge2.Dallas1.Level3.net (4.69.145.203) 12.294 ms ae-3-80.edge2.Dallas1.Level3.net (4.69.145.139) 0.896 ms 0.790 ms 17 vlan80.csw3.Dallas1.Level3.net (4.69.145.190) 0.590 ms vlan60.csw1.Dallas1.Level3.net (4.69.145.62) 0.610 ms vlan80.csw3.Dallas1.Level3.net (4.69.145.190) 0.932 ms 18 ae-1-60.edge2.Dallas1.Level3.net (4.69.145.11) 0.522 ms ae-4-90.edge2.Dallas1.Level3.net (4.69.145.203) 11.423 ms ae-3-80.edge2.Dallas1.Level3.net (4.69.145.139) 0.747 ms 19 vlan90.csw4.Dallas1.Level3.net (4.69.145.254) 0.673 ms vlan80.csw3.Dallas1.Level3.net (4.69.145.190) 0.803 ms vlan60.csw1.Dallas1.Level3.net (4.69.145.62) 0.638 ms 20 ae-1-60.edge2.Dallas1.Level3.net (4.69.145.11) 0.525 ms ae-3-80.edge2.Dallas1.Level3.net (4.69.145.139) 0.826 ms 0.876 ms 21 vlan60.csw1.Dallas1.Level3.net (4.69.145.62) 0.635 ms 9.840 ms 9.404 ms 22 ae-1-60.edge2.Dallas1.Level3.net (4.69.145.11) 0.622 ms 0.604 ms ae-4-90.edge2.Dallas1.Level3.net (4.69.145.203) 8.751 ms 23 vlan80.csw3.Dallas1.Level3.net (4.69.145.190) 0.671 ms 0.817 ms 0.687 ms 24 ae-3-80.edge2.Dallas1.Level3.net (4.69.145.139) 0.785 ms 0.754 ms ae-4-90.edge2.Dallas1.Level3.net (4.69.145.203) 4.774 ms 25 vlan90.csw4.Dallas1.Level3.net (4.69.145.254) 0.633 ms 0.683 ms 0.795 ms 26 ae-1-60.edge2.Dallas1.Level3.net (4.69.145.11) 0.659 ms ae-3-80.edge2.Dallas1.Level3.net (4.69.145.139) 0.758 ms 0.907 ms 27 vlan60.csw1.Dallas1.Level3.net (4.69.145.62) 0.776 ms vlan90.csw4.Dallas1.Level3.net (4.69.145.254) 0.721 ms vlan60.csw1.Dallas1.Level3.net (4.69.145.62) 0.705 ms 28 ae-4-90.edge2.Dallas1.Level3.net (4.69.145.203) 15.057 ms 14.660 ms ae-3-80.edge2.Dallas1.Level3.net (4.69.145.139) 0.871 ms 29 vlan80.csw3.Dallas1.Level3.net (4.69.145.190) 0.864 ms vlan60.csw1.Dallas1.Level3.net (4.69.145.62) 0.752 ms 0.747 ms 30 ae-3-80.edge2.Dallas1.Level3.net (4.69.145.139) 0.877 ms ae-1-60.edge2.Dallas1.Level3.net (4.69.145.11) 0.721 ms ae-4-90.edge2.Dallas1.Level3.net (4.69.145.203) 14.302 ms and, of course, email does not work From randy at psg.com Mon Apr 25 13:07:38 2016 From: randy at psg.com (Randy Bush) Date: Mon, 25 Apr 2016 22:07:38 +0900 Subject: trout views In-Reply-To: References: Message-ID: looks pretty much an L(3) issue, as i can get there from tokyo via iij to i2 traceroute 128.223.51.20 traceroute to 128.223.51.20 (128.223.51.20), 64 hops max, 52 byte packets 1 wrt-tokyo.rg.net (192.168.0.1) 1.943 ms 1.790 ms 1.151 ms 2 tokyo10-n427.flets.2iij.net (203.180.20.65) 5.825 ms 6.462 ms 6.560 ms 3 tokyo10-ntteast1.flets.2iij.net (203.180.20.245) 6.449 ms 6.446 ms 5.401 ms 4 tky001lip31.iij.net (203.180.20.101) 5.597 ms 5.449 ms 5.731 ms 5 tky001bb11.iij.net (210.138.115.213) 6.875 ms 5.986 ms 5.823 ms 6 lax002bb12.iij.net (58.138.88.150) 121.104 ms 117.711 ms 117.510 ms 7 lsan0.tr-cps.internet2.edu (206.223.123.199) 117.510 ms 132.285 ms 128.119 ms 8 * * * 9 vl-2.uonet2-gw.uoregon.edu (128.223.2.2) 146.497 ms 145.453 ms vl-2-gw.uoregon.edu (128.223.2.1) 145.187 ms 10 archive.routeviews.org (128.223.51.20) 144.701 ms 144.539 ms 145.096 ms but my smtp-out is trying to get there from ashburn to L(3). so someone else might tell john kemp to call L(3). randy From royce at techsolvency.com Mon Apr 25 14:35:50 2016 From: royce at techsolvency.com (Royce Williams) Date: Mon, 25 Apr 2016 06:35:50 -0800 Subject: Firewall list recommendations (config conversion options) In-Reply-To: <20160425083125.GA30464@lboro.ac.uk> References: <20160425083125.GA30464@lboro.ac.uk> Message-ID: It might also be interesting to post some redacted/simplified examples of both formats. If the conversion is "just" text manipulation and reworking of logic, it might not be hard to cobble something basic together quickly, and then crowdsource improvements quickly on Github. Royce On Mon, Apr 25, 2016 at 12:31 AM, wrote: > Hi, > > > > Looking for options on converting a large amount of Fortinet rules to > > > Checkpoint. Ultimately converting the entire configuration to > Checkpoint > > > would be nice. > > theres a post online asking the same question back in early 2010 with no > responses... > > there are also a lost of tools that do Checkpoint TO Fortinet - says > something? ;-) > > > but actually, looking for firewall conversion tools does give you a picture > of typical/common moves :) > > > > alan > From mike-nanog at tiedyenetworks.com Mon Apr 25 19:33:13 2016 From: mike-nanog at tiedyenetworks.com (Mike) Date: Mon, 25 Apr 2016 12:33:13 -0700 Subject: trout views In-Reply-To: References: Message-ID: <571E70F9.7000304@tiedyenetworks.com> On 04/25/2016 05:03 AM, Randy Bush wrote: > nfs0.dfw.rg.net:/root# ping 128.223.51.20 > PING 128.223.51.20 (128.223.51.20) 56(84) bytes of data. > From 4.69.145.11 icmp_seq=1 Time to live exceeded > From 4.69.145.11 icmp_seq=2 Time to live exceeded Somthing fishy there.... From colton.conor at gmail.com Mon Apr 25 22:41:07 2016 From: colton.conor at gmail.com (Colton Conor) Date: Mon, 25 Apr 2016 17:41:07 -0500 Subject: Arista Routing Solutions In-Reply-To: References: Message-ID: Ryan, What routing platform were you coming from before? What features does Arista not have that you find limiting that the old platform did have? How does Astira's Sflow only compare to having Cisco Netflow or Juniper JFlow for traffic monitoring which I assume Netflix does alot of? On Wed, Apr 20, 2016 at 3:48 PM, Ryan Woolley wrote: > Colton Conor wrote: > > I know Arista is typically a switch manufacturer, but with their recently > > announced Arista 7500R Series and soon to be announced but already > shipping > > 7280R Series Arista is officially getting into the routing game. The > fixed > > 1U 7280R Series looks quite impressive. The 7500R series is your > > traditional chassis and line card based solution. > > > > Both of these products have the ability to hold the full internet routing > > table, and Arista is working on MPLS features. Both of these new products > > use the latest Broadcom Jerico chipsets. > > We (Netflix) have been deploying the previous gen (7500E) as edge routers > for about two years in high traffic, low route count applications in our > CDN, and have been working with Arista for almost as long to improve route > scale so that we could turn off all our traditional routers. > > The features that enable full routes on Jericho are running in our > production network today and we also have the 7500R and 7280R working with > full tables. > > I can't speak to MPLS, but for our use case (all L3, very high-density > 10/40/100G, BGP, IS-IS and light QoS), it's working well. > > So, yes, I'd say those two products are quite viable and competitive > options in the edge router space. > From tom at ninjabadger.net Tue Apr 26 00:03:48 2016 From: tom at ninjabadger.net (Tom Hill) Date: Tue, 26 Apr 2016 01:03:48 +0100 Subject: NCS5K? In-Reply-To: <571636AD.3020603@switch.ch> References: <571636AD.3020603@switch.ch> Message-ID: <571EB064.2010606@ninjabadger.net> On 19/04/16 14:46, Chris Welti wrote: > According to some slides from a russian cisco connect event, the > upcoming small-size NCS 5501 and NCS 5502 will support 1M+ FIB and > 50ms per port buffers. Seem to be killer boxes. 48x100GE in 2RU with > large FIB & buffers? Loving it already. I wonder what prices will > look like for those. I'd heard rumours... But those are interesting specifications. The NCS5501 isn't too far away from the Arista 7280R, and is probably Jericho underneath, too. But with a good MPLS stack, as is the case for the other NCS devices. Some might be thinking "9001 upgrade!" but it's more likely direct competition to Arista's recent moves. That and I still hope there will be a MOD200-ish 9001 replacement to come at some point. Oh - and it's NCS 55k, not NCS 5k. The NCS 5508 is already a product, noted for its better buffers than the NCS 5001 & 5002 (which also already exist). -- Tom From chris.welti at switch.ch Tue Apr 26 13:27:58 2016 From: chris.welti at switch.ch (Chris Welti) Date: Tue, 26 Apr 2016 15:27:58 +0200 Subject: NCS5K? In-Reply-To: <571EB064.2010606@ninjabadger.net> References: <571636AD.3020603@switch.ch> <571EB064.2010606@ninjabadger.net> Message-ID: <571F6CDE.6020108@switch.ch> On 26/04/16 02:03, Tom Hill wrote: > On 19/04/16 14:46, Chris Welti wrote: >> According to some slides from a russian cisco connect event, the >> upcoming small-size NCS 5501 and NCS 5502 will support 1M+ FIB and >> 50ms per port buffers. Seem to be killer boxes. 48x100GE in 2RU with >> large FIB & buffers? Loving it already. I wonder what prices will >> look like for those. > > I'd heard rumours... But those are interesting specifications. The > NCS5501 isn't too far away from the Arista 7280R, and is probably > Jericho underneath, too. But with a good MPLS stack, as is the case for > the other NCS devices. Judging from the NCS 5001 configuration guides they (NCS5K) don't support any VPLS, is that correct? Just EoMPLS? > Some might be thinking "9001 upgrade!" but it's more likely direct > competition to Arista's recent moves. That and I still hope there will > be a MOD200-ish 9001 replacement to come at some point. I had hoped for MOD400-ish 9001 replacement for a while, however, I was told an ASR9001 successor is highly unlikely in the next few years unless a very large customer asks for it. > Oh - and it's NCS 55k, not NCS 5k. The NCS 5508 is already a product, > noted for its better buffers than the NCS 5001 & 5002 (which also > already exist). Does the NCS 5508 support VPLS? -- Chris From colton.conor at gmail.com Tue Apr 26 14:02:33 2016 From: colton.conor at gmail.com (Colton Conor) Date: Tue, 26 Apr 2016 09:02:33 -0500 Subject: NCS5K? In-Reply-To: <571EB064.2010606@ninjabadger.net> References: <571636AD.3020603@switch.ch> <571EB064.2010606@ninjabadger.net> Message-ID: Tom, Do you actually think that Cisco would sell at NCS 5501 at the price point that Arista is going to sell a 7280R for? Spec wise they are very similar (except Arista has 8 more SFP+ ports and two more 100G ports). Arista is pricing the 7280R inline with Ciscos ASR9001. I doubt Cisco will offer a NCS 5501 for the same price as an ASR9001. On Mon, Apr 25, 2016 at 7:03 PM, Tom Hill wrote: > On 19/04/16 14:46, Chris Welti wrote: > > According to some slides from a russian cisco connect event, the > > upcoming small-size NCS 5501 and NCS 5502 will support 1M+ FIB and > > 50ms per port buffers. Seem to be killer boxes. 48x100GE in 2RU with > > large FIB & buffers? Loving it already. I wonder what prices will > > look like for those. > > I'd heard rumours... But those are interesting specifications. The > NCS5501 isn't too far away from the Arista 7280R, and is probably > Jericho underneath, too. But with a good MPLS stack, as is the case for > the other NCS devices. > > Some might be thinking "9001 upgrade!" but it's more likely direct > competition to Arista's recent moves. That and I still hope there will > be a MOD200-ish 9001 replacement to come at some point. > > Oh - and it's NCS 55k, not NCS 5k. The NCS 5508 is already a product, > noted for its better buffers than the NCS 5001 & 5002 (which also > already exist). > > -- > Tom > From rwoolleynanog at gmail.com Tue Apr 26 16:32:29 2016 From: rwoolleynanog at gmail.com (Ryan Woolley) Date: Tue, 26 Apr 2016 12:32:29 -0400 Subject: Arista Routing Solutions In-Reply-To: References: Message-ID: IOS-XR on ASR 9k and Junos on MX. For our use case, there's no longer anything limiting as compared to those platforms. BGP policy is perhaps not as rich as you might be used to if your experience is with the sort of routers traditionally marketed to service providers, but I'm sure that will get better, and it's probably irrelevant if your policy is fairly static. You are correct that we do collect a lot of flow data, both via sflow and Netflow. We've been able to do everything we need with Arista's sflow implementation. On Mon, Apr 25, 2016 at 6:41 PM, Colton Conor wrote: > Ryan, > > What routing platform were you coming from before? What features does > Arista not have that you find limiting that the old platform did have? > > How does Astira's Sflow only compare to having Cisco Netflow or Juniper > JFlow for traffic monitoring which I assume Netflix does alot of? > > On Wed, Apr 20, 2016 at 3:48 PM, Ryan Woolley > wrote: > >> Colton Conor wrote: >> > I know Arista is typically a switch manufacturer, but with their >> recently >> > announced Arista 7500R Series and soon to be announced but already >> shipping >> > 7280R Series Arista is officially getting into the routing game. The >> fixed >> > 1U 7280R Series looks quite impressive. The 7500R series is your >> > traditional chassis and line card based solution. >> > >> > Both of these products have the ability to hold the full internet >> routing >> > table, and Arista is working on MPLS features. Both of these new >> products >> > use the latest Broadcom Jerico chipsets. >> >> We (Netflix) have been deploying the previous gen (7500E) as edge routers >> for about two years in high traffic, low route count applications in our >> CDN, and have been working with Arista for almost as long to improve route >> scale so that we could turn off all our traditional routers. >> >> The features that enable full routes on Jericho are running in our >> production network today and we also have the 7500R and 7280R working with >> full tables. >> >> I can't speak to MPLS, but for our use case (all L3, very high-density >> 10/40/100G, BGP, IS-IS and light QoS), it's working well. >> >> So, yes, I'd say those two products are quite viable and competitive >> options in the edge router space. >> > > From rwoolleynanog at gmail.com Tue Apr 26 16:46:25 2016 From: rwoolleynanog at gmail.com (Ryan Woolley) Date: Tue, 26 Apr 2016 12:46:25 -0400 Subject: Arista Routing Solutions In-Reply-To: References: <571BB662.8000804@ninjabadger.net> Message-ID: While the QFX in general is similar to Jericho-based platforms, I think the QFX10002 is perhaps not an ideal comparison. At 100G, there is a significant density penalty on that platform, as you can use all 36 ports at 40G, but only 12 ports at 100G. BGP convergence in the newer EOS releases is indeed very, very fast. On Sun, Apr 24, 2016 at 12:08 PM, Colton Conor wrote: > Saku, > > I guess you are right the QFX10002-36Q is probably a better comparison. But > let's be honest, Juniper is not going to sell a QFX10002-36Q for less than > $20k like Arista will do for a semi- similar box. Even with a high discount > (like 90 percent off list), the Juniper QFX10002-36Q at $360k list price > comes nowhere close on the price point. Cisco, Juniper, ALU, etc are all > not going to see a low cost high density fixed switch because that would > cannibalize on their sales on the larger platforms. I really think Arista > is kind of unique here as they don't have another routing platform to > cannibalize, so they are competitively pricing their platform. > > So I guess the question becomes, what features are missing that Arista does > not currently have? They seems to be adding more and more features, and > taking more market share. Here is a list of features supported: > https://www.arista.com/en/support/product-documentation/supported-features > I have not personally used Arista myself, but I like what I am seeing as > far as price point, company culture, and repruatation in the market place. > I know their switching is solid, but I am not sure about their routing. > > Arista claims to have much, much faster BGP convergence time than all the > other vendors. > > > > > > On Sat, Apr 23, 2016 at 1:20 PM, Saku Ytti wrote: > > > On 23 April 2016 at 10:52, Tom Hill wrote: > > > In broad strokes: for your money you're either getting port density, or > > > more features per port. The only difference here is that there's > > > suddenly more TCAM on the device, and I still don't see the above > > > changing too drastically. > > > > Yeah OP is comparing high touch chip (MX104) to low touch chip > > (Jericho) that is not fair comparison. And cost is what customer is > > willing to pay, regardless of sticker on the box. No one will pay > > significant mark-up for another sticker, I've never seen in RFP > > significant differences in comparable products. > > > > Fairer comparison would be QFX10k, instead of MX104. QFX10k is AFAIK > > only product in this segment which is not using Jericho. If this is > > competitive advantage or risk, jury is still out, I lean towards > > competitive advantage, mainly due to its memory design. > > > > -- > > ++ytti > > > From paras at protrafsolutions.com Tue Apr 26 17:04:31 2016 From: paras at protrafsolutions.com (Paras Jha) Date: Tue, 26 Apr 2016 13:04:31 -0400 Subject: Arista Routing Solutions In-Reply-To: References: <571BB662.8000804@ninjabadger.net> Message-ID: Just wanted to interject, the port density of the Arista switches is quite impressive, especially considering the price point they're at. On Tue, Apr 26, 2016 at 12:46 PM, Ryan Woolley wrote: > While the QFX in general is similar to Jericho-based platforms, I think the > QFX10002 is perhaps not an ideal comparison. At 100G, there is a > significant density penalty on that platform, as you can use all 36 ports > at 40G, but only 12 ports at 100G. > > BGP convergence in the newer EOS releases is indeed very, very fast. > > On Sun, Apr 24, 2016 at 12:08 PM, Colton Conor > wrote: > > > Saku, > > > > I guess you are right the QFX10002-36Q is probably a better comparison. > But > > let's be honest, Juniper is not going to sell a QFX10002-36Q for less > than > > $20k like Arista will do for a semi- similar box. Even with a high > discount > > (like 90 percent off list), the Juniper QFX10002-36Q at $360k list price > > comes nowhere close on the price point. Cisco, Juniper, ALU, etc are all > > not going to see a low cost high density fixed switch because that would > > cannibalize on their sales on the larger platforms. I really think Arista > > is kind of unique here as they don't have another routing platform to > > cannibalize, so they are competitively pricing their platform. > > > > So I guess the question becomes, what features are missing that Arista > does > > not currently have? They seems to be adding more and more features, and > > taking more market share. Here is a list of features supported: > > > https://www.arista.com/en/support/product-documentation/supported-features > > I have not personally used Arista myself, but I like what I am seeing as > > far as price point, company culture, and repruatation in the market > place. > > I know their switching is solid, but I am not sure about their routing. > > > > Arista claims to have much, much faster BGP convergence time than all the > > other vendors. > > > > > > > > > > > > On Sat, Apr 23, 2016 at 1:20 PM, Saku Ytti wrote: > > > > > On 23 April 2016 at 10:52, Tom Hill wrote: > > > > In broad strokes: for your money you're either getting port density, > or > > > > more features per port. The only difference here is that there's > > > > suddenly more TCAM on the device, and I still don't see the above > > > > changing too drastically. > > > > > > Yeah OP is comparing high touch chip (MX104) to low touch chip > > > (Jericho) that is not fair comparison. And cost is what customer is > > > willing to pay, regardless of sticker on the box. No one will pay > > > significant mark-up for another sticker, I've never seen in RFP > > > significant differences in comparable products. > > > > > > Fairer comparison would be QFX10k, instead of MX104. QFX10k is AFAIK > > > only product in this segment which is not using Jericho. If this is > > > competitive advantage or risk, jury is still out, I lean towards > > > competitive advantage, mainly due to its memory design. > > > > > > -- > > > ++ytti > > > > > > -- Regards, Paras President ProTraf Solutions, LLC Enterprise DDoS Mitigation From saku at ytti.fi Tue Apr 26 17:35:29 2016 From: saku at ytti.fi (Saku Ytti) Date: Tue, 26 Apr 2016 10:35:29 -0700 Subject: NCS5K? In-Reply-To: References: <571636AD.3020603@switch.ch> <571EB064.2010606@ninjabadger.net> Message-ID: On 26 April 2016 at 07:02, Colton Conor wrote: > Do you actually think that Cisco would sell at NCS 5501 at the price point > that Arista is going to sell a 7280R for? Spec wise they are very similar > (except Arista has 8 more SFP+ ports and two more 100G ports). Arista is > pricing the 7280R inline with Ciscos ASR9001. I doubt Cisco will offer a > NCS 5501 for the same price as an ASR9001. This seems more question to economists than network engineers. But the rudimentary understanding I have of free market it means that competitors cannot sell products competing for same customers at significantly different price point. On micro-level this may not be true, we can find anecdotal examples of vastly differences prices for similar products but on macro-level I'm sure Cisco, Arista, Alu, Huawei, Juniper etc are all competitive, I base this solely on the fact that they do exist (albeit Huawei may get unfair tax kick-backs to enhance its competitiveness). -- ++ytti From larrysheldon at cox.net Tue Apr 26 19:10:39 2016 From: larrysheldon at cox.net (Larry Sheldon) Date: Tue, 26 Apr 2016 14:10:39 -0500 Subject: phone fun, was GeoIP database issues and the real world consequences In-Reply-To: References: <20160414153236.GA88366@ussenterprise.ufp.org> <570ED607.1070607@cox.net> <20160414002939.15867.qmail@ary.lan> <1460710177.364730809@apps.rackspace.com> <571105A6.3040607@nvcube.net> <20160415190936.043B346BE4B9@rock.dv.isc.org> <20160415212138.29C9146BF6E3@rock.dv.isc.org> <2CA30D4F-24F0-4E92-A633-31BF20A78B17@delong.com> <57179952.8040706@vaxination.ca> Message-ID: <5d5d8f55-6718-1929-dd99-d8b458873fa5@cox.net> On 4/20/2016 10:15, Owen DeLong wrote: > >> On Apr 20, 2016, at 7:59 AM, Jean-Francois Mezei wrote: >> >> On 2016-04-20 10:52, Owen DeLong wrote: >> >>> For the most part, ?long distance? calls within the US are a thing of the >>> past and at least one mobile carrier now treats US/CA/MX as a single >>> local calling area >> >> >> Is this a case of telcos having switched to IP trunks and can reach >> other carriers for "free" >> >> Or are wholesale long distance still billed between carriers but at >> prices so low that they can afford to offer "free" long distance at >> retail level ? > > I think it boiled down to a recognition that the costs of billing were beginning to account for something like $0.99 of every $1 billed. I wonder if the costs of avoiding-preventing-investigating toll fraud final grow to consume the profit in the product. I know that long ago there were things that I thought were insanely silly. A few examples: As an ordinary citizen I was amused and annoyed, in the case where a toll charge had been contested (and perforce refunded) there would often be several non-revenue calls to the protesting number asking whoever answered if they knew anybody in the called city, or if they knew who the called number belonged to. (Proper answer in any case: Who or what I know is none of your business.) Often there would calls to the called number (super irritating because the error was in the recording--later learned to be poor handwriting) asking the reciprocal questions except that often they had no idea that a call had been made. I was a Toll Transmissionman for a number or years back in the last iceage and one of the onerous tasks the supervisor had was "verifying the phone bill" which might be a stack as much as six inches tall. The evening shift supervisor (or one of them in a large office, like Los Angeles 1 Telegraph, where I worked for a while) would go through the bill, line by line, page by page, looking at the called number an d if he recognized it and placing a check mark next to it, If he did not recognize it, he would search the many lists in the office to see it was shown, and adding a check mark if a list showed it for a likely sounding legal call. If that didn't work he would probably have to call the number to see who answered (adding a wasted revenue-call path to the wreckage). Most often it would turn out to be the home telephone number of a repair supervisor in West Sweatsock, Montana, who had been called because a somebody who protested the policy that the repairman going fishing meant some problem would not be addressed for several days. So he put a check mark next to the number and moved on. Which meant the number would show up on the next month's bill. And it would again not be recognized from memory. And so forth and so on. Until eventually, after several months, the number would be recognized, check-marked without drama, and disappear forever from the bill. Lastly, in later years I was assigned to the the Revenue Accounting organization (to write programs for printing telephone books) and came to realize that there were a LOT of people in RA working with a LOT of people in the Chief Special Agents organization using a LOT of computer time to analyze Toll records for fraud patterns. Oops, not quite lastly.... Looking back at my Toll Plant days in the heyday of Captain Crunch--there were a lot engineering hours redesigning Toll equipment, and plant hours modifying or replacing equipment do defeat the engineering efforts of the Blue Box Boys. -- "Everybody is a genius. But if you judge a fish by its ability to climb a tree, it will live its whole life believing that it is stupid." --Albert Einstein From owen at delong.com Tue Apr 26 23:16:16 2016 From: owen at delong.com (Owen DeLong) Date: Tue, 26 Apr 2016 16:16:16 -0700 Subject: phone fun, was GeoIP database issues and the real world consequences In-Reply-To: <5d5d8f55-6718-1929-dd99-d8b458873fa5@cox.net> References: <20160414153236.GA88366@ussenterprise.ufp.org> <570ED607.1070607@cox.net> <20160414002939.15867.qmail@ary.lan> <1460710177.364730809@apps.rackspace.com> <571105A6.3040607@nvcube.net> <20160415190936.043B346BE4B9@rock.dv.isc.org> <20160415212138.29C9146BF6E3@rock.dv.isc.org> <2CA30D4F-24F0-4E92-A633-31BF20A78B17@delong.com> <57179952.8040706@vaxination.ca> <5d5d8f55-6718-1929-dd99-d8b458873fa5@cox.net> Message-ID: <973BE688-B573-42F8-8A84-A8ACB2419350@delong.com> > On Apr 26, 2016, at 12:10 , Larry Sheldon wrote: > > > > On 4/20/2016 10:15, Owen DeLong wrote: >> >>> On Apr 20, 2016, at 7:59 AM, Jean-Francois Mezei wrote: >>> >>> On 2016-04-20 10:52, Owen DeLong wrote: >>> >>>> For the most part, ?long distance? calls within the US are a thing of the >>>> past and at least one mobile carrier now treats US/CA/MX as a single >>>> local calling area >>> >>> >>> Is this a case of telcos having switched to IP trunks and can reach >>> other carriers for "free" >>> >>> Or are wholesale long distance still billed between carriers but at >>> prices so low that they can afford to offer "free" long distance at >>> retail level ? >> >> I think it boiled down to a recognition that the costs of billing were beginning to account for something like $0.99 of every $1 billed. > > I wonder if the costs of avoiding-preventing-investigating toll fraud final grow to consume the profit in the product. IIRC, mostly it boiled down to the maintenance of the antiquated SMDR equipment and its interface to the even more antiquated billing systems was getting expensive to keep running and that there was no perceived potential whatsoever for ROI on building a new billing system or new SMDR capabilities. > I know that long ago there were things that I thought were insanely silly. A few examples: > > As an ordinary citizen I was amused and annoyed, in the case where a toll charge had been contested (and perforce refunded) there would often be several non-revenue calls to the protesting number asking whoever answered if they knew anybody in the called city, or if they knew who the called number belonged to. (Proper answer in any case: Who or what I know is none of your business.) Often there would calls to the called number (super irritating because the error was in the recording--later learned to be poor handwriting) asking the reciprocal questions except that often they had no idea that a call had been made. ROFLMAO? Yeah. Next time we?re in the same locale, ask me about my 2.5 year argument with Pacific Bell about direct dial calls to Vietnam and the Philippines from my apartment in Richmond. There should be alcohol involved. > I was a Toll Transmissionman for a number or years back in the last iceage and one of the onerous tasks the supervisor had was "verifying the phone bill" which might be a stack as much as six inches tall. The evening shift supervisor (or one of them in a large office, like Los Angeles 1 Telegraph, where I worked for a while) would go through the bill, line by line, page by page, looking at the called number an d if he recognized it and placing a check mark next to it, If he did not recognize it, he would search the many lists in the office to see it was shown, and adding a check mark if a list showed it for a likely sounding legal call. If that didn't work he would probably have to call the number to see who answered (adding a wasted revenue-call path to the wreckage). Most often it would turn out to be the home telephone number of a repair supervisor in West Sweatsock, Montana, who had been called because a somebody who protested the policy that the repairman going fishing meant some problem would not be addressed for several days. So he put a check mark next to the number and moved on. > > Which meant the number would show up on the next month's bill. And it would again not be recognized from memory. And so forth and so on. Until eventually, after several months, the number would be recognized, check-marked without drama, and disappear forever from the bill. > > Lastly, in later years I was assigned to the the Revenue Accounting organization (to write programs for printing telephone books) and came to realize that there were a LOT of people in RA working with a LOT of people in the Chief Special Agents organization using a LOT of computer time to analyze Toll records for fraud patterns. > > Oops, not quite lastly.... Looking back at my Toll Plant days in the heyday of Captain Crunch--there were a lot engineering hours redesigning Toll equipment, and plant hours modifying or replacing equipment do defeat the engineering efforts of the Blue Box Boys. I really liked it while my Blue Box still worked. lol For a while, SS7 was the bane of my existence. Fun times!! When a minute of long distance from California to New York was $0.35+, there was enough money in the billing process to cover the costs of tracking the minute. Once it got down to $0.03 and then $0.01, that really took a lot of the margin away. One thing I always found particularly amusing was that it used to be a toll call to call from San Jose East (408238) to Sunnyvale (I forget the NPA/NXX), but that there were several prefixes in San Jose West (e.g. 408360 IIRC) where it was free to call from San Jose East and could place a free call to Sunnyvale. I also discovered that a single line with call forwarding was relatively cheap per month and could forward many calls into a hunt group. So, we used to extend the toll-free reach of BBS systems by finding ?friends? with houses in strategic prefixes and having them install a single telephone line with call forwarding. Then, once the line was installed, we?d run over to the location, program the forwarder to go to the BBS hunt lead number and voila? Instant toll free unlimited BBS calling for another 20-30 prefixes for less than $15/month and completely legal. At first, we thought we had to hide what we were doing as we were sure that the phone company would object, but we later discovered that absent a PUC proceeding to change the tariff they really didn?t have anything they could say about it. We started showing up on the day of install to dial in the forwarding and confirm functionality while the tech was still on site. You should have seen some of the reactions when we showed up with a butt set, set up call forwarding, told someone to make a test call and waited for positive confirmation. Priceless. Owen From tom at ninjabadger.net Wed Apr 27 00:15:54 2016 From: tom at ninjabadger.net (Tom Hill) Date: Wed, 27 Apr 2016 01:15:54 +0100 Subject: NCS5K? In-Reply-To: References: <571636AD.3020603@switch.ch> <571EB064.2010606@ninjabadger.net> Message-ID: <572004BA.1040306@ninjabadger.net> On 26/04/16 15:02, Colton Conor wrote: > Do you actually think that Cisco would sell at NCS 5501 at the price > point that Arista is going to sell a 7280R for? Spec wise they are very > similar (except Arista has 8 more SFP+ ports and two more 100G ports). > Arista is pricing the 7280R inline with Ciscos ASR9001. I doubt Cisco > will offer a NCS 5501 for the same price as an ASR9001. In addition to Saku's comments - I've only really been hypothesising by looking at the features available on the platforms, and comparing it to the current list prices that we already have. I've no other insider knowledge. Take the line cards in ASR 9000 chassis, vs. NCS 5500 chassis: A9K-8X100GE-TR, 8x100G = $ 1,000,000 A9K-36X10GE-TR, 36x10G = $ 375,000 NC55-36X100G-BA, 36x100G = $ 360,000 The list price for a 36x10G line card for the ASR 9000 is *cheaper than* the 36x100G card for the NCS 5500. There are massive gains in Gbits/$ by having fewer features in your device. (And the SE scale A9k cards are priced even higher than these TR models...) More to the second half of your question though, and probably the most pertinent; the NCS 5001 & 5002 pricing is already out, and they are smack-back either side of the ASR 9001: NCS-5001, 40x10G + 4x100G = $ 40,000 ASR-9001, 4x10G + nothing = $ 53,600 NCS-5002, 80x10G + 4x100G = $ 60,000 So, personally, I'm not ruling out the NCS 5501 landing on or around the 9001's price point - particularly if that's Arista's game. The NCS 55k is obviously being targeted at dense MPLS P roles, and/or simple BGP edge routers, which may be of enough use to you, in your environment - it may not. -- Tom From tom at ninjabadger.net Wed Apr 27 00:25:33 2016 From: tom at ninjabadger.net (Tom Hill) Date: Wed, 27 Apr 2016 01:25:33 +0100 Subject: NCS5K? In-Reply-To: <571F6CDE.6020108@switch.ch> References: <571636AD.3020603@switch.ch> <571EB064.2010606@ninjabadger.net> <571F6CDE.6020108@switch.ch> Message-ID: <572006FD.2060309@ninjabadger.net> On 26/04/16 14:27, Chris Welti wrote: > Judging from the NCS 5001 configuration guides they (NCS5K) don't support > any VPLS, is that correct? Just EoMPLS? It's not targeted as a full-feature box AFAIK. You've got the ASR9k and ASR9xx series for this sort of thing. I do recall some mention of NCS5k supporting Segment Routing though - that seemed quite handy for future MPLS P requirements. >> Some might be thinking "9001 upgrade!" but it's more likely direct >> competition to Arista's recent moves. That and I still hope there will >> be a MOD200-ish 9001 replacement to come at some point. > > I had hoped for MOD400-ish 9001 replacement for a while, > however, I was told an ASR9001 successor is highly unlikely > in the next few years unless a very large customer asks for it. I've heard some rumours to the contrary - presumably it could still be canned. Tomahawk is still quite new, and the 9001 still sells well, so perhaps the market just isn't ready yet. I guarantee Cisco's sales of any given product proceed along these lines: 1. Product sales for flagship $model are good 2. Announce flagship $model+1 to public 3. Product sales for $model plummet, whilst everyone waits for $model+1 Sometimes that's good, sometimes that's really bad. :) >> Oh - and it's NCS 55k, not NCS 5k. The NCS 5508 is already a product, >> noted for its better buffers than the NCS 5001 & 5002 (which also >> already exist). > > Does the NCS 5508 support VPLS? I don't recall looking closely, but I very much doubt it due to the reasons mentioned above. -- Tom From ray at orsiniit.com Wed Apr 27 02:50:26 2016 From: ray at orsiniit.com (Ray Orsini) Date: Tue, 26 Apr 2016 22:50:26 -0400 Subject: phone fun, was GeoIP database issues and the real world consequences In-Reply-To: <5d5d8f55-6718-1929-dd99-d8b458873fa5@cox.net> References: <20160414153236.GA88366@ussenterprise.ufp.org> <570ED607.1070607@cox.net> <20160414002939.15867.qmail@ary.lan> <1460710177.364730809@apps.rackspace.com> <571105A6.3040607@nvcube.net> <20160415190936.043B346BE4B9@rock.dv.isc.org> <20160415212138.29C9146BF6E3@rock.dv.isc.org> <2CA30D4F-24F0-4E92-A633-31BF20A78B17@delong.com> <57179952.8040706@vaxination.ca> <5d5d8f55-6718-1929-dd99-d8b458873fa5@cox.net> Message-ID: On our VOIP service we include US, Canada and Puerto Rico as "local" calling. Regards, Ray Orsini ? CEO Orsini IT, LLC ? Technology Consultants VOICE ?DATA ? BANDWIDTH ? SECURITY ? SUPPORT P: 305.967.6756 x1009 E: ray at orsiniit.com TF: 844.OIT.VOIP 7900 NW 155th Street, Suite 103, Miami Lakes, FL 33016 http://www.orsiniit.com | View My Calendar | View/Pay Your Invoices | View Your Tickets -----Original Message----- From: NANOG [mailto:nanog-bounces+ray=orsiniit.com at nanog.org] On Behalf Of Larry Sheldon Sent: Tuesday, April 26, 2016 3:11 PM To: nanog at nanog.org Subject: Re: phone fun, was GeoIP database issues and the real world consequences On 4/20/2016 10:15, Owen DeLong wrote: > >> On Apr 20, 2016, at 7:59 AM, Jean-Francois Mezei >> wrote: >> >> On 2016-04-20 10:52, Owen DeLong wrote: >> >>> For the most part, ?long distance? calls within the US are a thing >>> of the past and at least one mobile carrier now treats US/CA/MX as a >>> single local calling area >> >> >> Is this a case of telcos having switched to IP trunks and can reach >> other carriers for "free" >> >> Or are wholesale long distance still billed between carriers but at >> prices so low that they can afford to offer "free" long distance at >> retail level ? > > I think it boiled down to a recognition that the costs of billing were > beginning to account for something like $0.99 of every $1 billed. I wonder if the costs of avoiding-preventing-investigating toll fraud final grow to consume the profit in the product. I know that long ago there were things that I thought were insanely silly. A few examples: As an ordinary citizen I was amused and annoyed, in the case where a toll charge had been contested (and perforce refunded) there would often be several non-revenue calls to the protesting number asking whoever answered if they knew anybody in the called city, or if they knew who the called number belonged to. (Proper answer in any case: Who or what I know is none of your business.) Often there would calls to the called number (super irritating because the error was in the recording--later learned to be poor handwriting) asking the reciprocal questions except that often they had no idea that a call had been made. I was a Toll Transmissionman for a number or years back in the last iceage and one of the onerous tasks the supervisor had was "verifying the phone bill" which might be a stack as much as six inches tall. The evening shift supervisor (or one of them in a large office, like Los Angeles 1 Telegraph, where I worked for a while) would go through the bill, line by line, page by page, looking at the called number an d if he recognized it and placing a check mark next to it, If he did not recognize it, he would search the many lists in the office to see it was shown, and adding a check mark if a list showed it for a likely sounding legal call. If that didn't work he would probably have to call the number to see who answered (adding a wasted revenue-call path to the wreckage). Most often it would turn out to be the home telephone number of a repair supervisor in West Sweatsock, Montana, who had been called because a somebody who protested the policy that the repairman going fishing meant some problem would not be addressed for several days. So he put a check mark next to the number and moved on. Which meant the number would show up on the next month's bill. And it would again not be recognized from memory. And so forth and so on. Until eventually, after several months, the number would be recognized, check-marked without drama, and disappear forever from the bill. Lastly, in later years I was assigned to the the Revenue Accounting organization (to write programs for printing telephone books) and came to realize that there were a LOT of people in RA working with a LOT of people in the Chief Special Agents organization using a LOT of computer time to analyze Toll records for fraud patterns. Oops, not quite lastly.... Looking back at my Toll Plant days in the heyday of Captain Crunch--there were a lot engineering hours redesigning Toll equipment, and plant hours modifying or replacing equipment do defeat the engineering efforts of the Blue Box Boys. -- "Everybody is a genius. But if you judge a fish by its ability to climb a tree, it will live its whole life believing that it is stupid." --Albert Einstein From blair.trosper at gmail.com Wed Apr 27 02:55:07 2016 From: blair.trosper at gmail.com (Blair Trosper) Date: Tue, 26 Apr 2016 19:55:07 -0700 Subject: phone fun, was GeoIP database issues and the real world consequences In-Reply-To: References: <20160414153236.GA88366@ussenterprise.ufp.org> <570ED607.1070607@cox.net> <20160414002939.15867.qmail@ary.lan> <1460710177.364730809@apps.rackspace.com> <571105A6.3040607@nvcube.net> <20160415190936.043B346BE4B9@rock.dv.isc.org> <20160415212138.29C9146BF6E3@rock.dv.isc.org> <2CA30D4F-24F0-4E92-A633-31BF20A78B17@delong.com> <57179952.8040706@vaxination.ca> <5d5d8f55-6718-1929-dd99-d8b458873fa5@cox.net> Message-ID: I would imagine for VOIP that's because all three are country code 1 :) On Tue, Apr 26, 2016 at 7:50 PM, Ray Orsini wrote: > On our VOIP service we include US, Canada and Puerto Rico as "local" > calling. > > Regards, > > Ray Orsini ? CEO > Orsini IT, LLC ? Technology Consultants > VOICE ?DATA ? BANDWIDTH ? SECURITY ? SUPPORT > P: 305.967.6756 x1009 E: ray at orsiniit.com TF: 844.OIT.VOIP > 7900 NW 155th Street, Suite 103, Miami Lakes, FL 33016 > http://www.orsiniit.com | View My Calendar | View/Pay Your Invoices | View > Your Tickets > > > > -----Original Message----- > From: NANOG [mailto:nanog-bounces+ray=orsiniit.com at nanog.org] On Behalf Of > Larry Sheldon > Sent: Tuesday, April 26, 2016 3:11 PM > To: nanog at nanog.org > Subject: Re: phone fun, was GeoIP database issues and the real world > consequences > > > > On 4/20/2016 10:15, Owen DeLong wrote: > > > >> On Apr 20, 2016, at 7:59 AM, Jean-Francois Mezei > >> wrote: > >> > >> On 2016-04-20 10:52, Owen DeLong wrote: > >> > >>> For the most part, ?long distance? calls within the US are a thing > >>> of the past and at least one mobile carrier now treats US/CA/MX as a > >>> single local calling area > >> > >> > >> Is this a case of telcos having switched to IP trunks and can reach > >> other carriers for "free" > >> > >> Or are wholesale long distance still billed between carriers but at > >> prices so low that they can afford to offer "free" long distance at > >> retail level ? > > > > I think it boiled down to a recognition that the costs of billing were > > beginning to account for something like $0.99 of every $1 billed. > > I wonder if the costs of avoiding-preventing-investigating toll fraud final > grow to consume the profit in the product. > > I know that long ago there were things that I thought were insanely silly. > A few examples: > > As an ordinary citizen I was amused and annoyed, in the case where a toll > charge had been contested (and perforce refunded) there would often be > several non-revenue calls to the protesting number asking whoever answered > if they knew anybody in the called city, or if they knew who > the called number belonged to. (Proper answer in any case: Who or > what I know is none of your business.) Often there would calls to the > called number (super irritating because the error was in the > recording--later learned to be poor handwriting) asking the reciprocal > questions except that often they had no idea that a call had been made. > > I was a Toll Transmissionman for a number or years back in the last iceage > and one of the onerous tasks the supervisor had was "verifying the phone > bill" which might be a stack as much as six inches tall. The evening shift > supervisor (or one of them in a large office, like Los Angeles 1 Telegraph, > where I worked for a while) would go through the bill, line by line, page > by > page, looking at the called number an d if he recognized it and placing a > check mark next to it, If he did not recognize it, he would search the > many > lists in the office to see it was shown, and adding a check mark if a list > showed it for a likely sounding legal call. If that didn't work he would > probably have to call the number to see who answered (adding a wasted > revenue-call path to the wreckage). Most often it would turn out to be the > home telephone number of a repair supervisor in West Sweatsock, Montana, > who > had been called because a somebody who protested the policy that the > repairman going fishing meant some problem would not be addressed for > several days. So he put a check mark next to the number and moved on. > > Which meant the number would show up on the next month's bill. And it > would > again not be recognized from memory. And so forth and so on. > Until eventually, after several months, the number would be recognized, > check-marked without drama, and disappear forever from the bill. > > Lastly, in later years I was assigned to the the Revenue Accounting > organization (to write programs for printing telephone books) and came to > realize that there were a LOT of people in RA working with a LOT of people > in the Chief Special Agents organization using a LOT of computer time to > analyze Toll records for fraud patterns. > > Oops, not quite lastly.... Looking back at my Toll Plant days in the > heyday > of Captain Crunch--there were a lot engineering hours redesigning Toll > equipment, and plant hours modifying or replacing equipment do defeat the > engineering efforts of the Blue Box Boys. > > -- > "Everybody is a genius. But if you judge a fish by its ability to climb a > tree, it will live its whole life believing that it is stupid." > > --Albert Einstein > From kemp at network-services.uoregon.edu Wed Apr 27 03:50:02 2016 From: kemp at network-services.uoregon.edu (John Kemp) Date: Tue, 26 Apr 2016 20:50:02 -0700 Subject: trout views In-Reply-To: References: Message-ID: <572036EA.1070600@network-services.uoregon.edu> That's the normal Monday morning maint window for UO, when they all too frequently make us disappear... :( /jgk On 4/25/16 5:03 AM, Randy Bush wrote: > nfs0.dfw.rg.net:/root# ping 128.223.51.20 > PING 128.223.51.20 (128.223.51.20) 56(84) bytes of data. > From 4.69.145.11 icmp_seq=1 Time to live exceeded > From 4.69.145.11 icmp_seq=2 Time to live exceeded > ^C > --- 128.223.51.20 ping statistics --- > 2 packets transmitted, 0 received, +2 errors, 100% packet loss, time 1001ms > > nfs0.dfw.rg.net:/root# traceroute 128.223.51.20 > traceroute to 128.223.51.20 (128.223.51.20), 30 hops max, 60 byte packets > 1 r0.dfw.rg.net (198.180.152.3) 1.571 ms 1.559 ms 1.597 ms > 2 r1.dfw.rg.net (198.180.152.2) 0.558 ms 0.551 ms 0.640 ms > 3 ge-102-0-0-29-53.r08.dllstx09.us.bb.gin.ntt.net (157.238.224.205) 1.562 ms 1.598 ms 1.716 ms > 4 ae-12.r07.dllstx09.us.bb.gin.ntt.net (129.250.3.107) 0.488 ms 0.538 ms 0.582 ms > 5 * * * > 6 * * * > 7 ae-65-65.csw1.Dallas1.Level3.net (4.69.206.133) 0.514 ms 0.555 ms ae-95-95.csw4.Dallas1.Level3.net (4.69.206.145) 0.525 ms > 8 ae-3-80.edge2.Dallas1.Level3.net (4.69.145.139) 0.627 ms 0.769 ms ae-1-60.edge2.Dallas1.Level3.net (4.69.145.11) 0.633 ms > 9 vlan90.csw4.Dallas1.Level3.net (4.69.145.254) 0.517 ms vlan80.csw3.Dallas1.Level3.net (4.69.145.190) 0.589 ms 0.676 ms > 10 ae-1-60.edge2.Dallas1.Level3.net (4.69.145.11) 0.519 ms ae-3-80.edge2.Dallas1.Level3.net (4.69.145.139) 0.632 ms ae-4-90.edge2.Dallas1.Level3.net (4.69.145.203) 13.412 ms > 11 vlan60.csw1.Dallas1.Level3.net (4.69.145.62) 13.264 ms 0.604 ms vlan80.csw3.Dallas1.Level3.net (4.69.145.190) 0.530 ms > 12 ae-1-60.edge2.Dallas1.Level3.net (4.69.145.11) 0.633 ms 0.519 ms 0.513 ms > 13 vlan80.csw3.Dallas1.Level3.net (4.69.145.190) 0.540 ms vlan60.csw1.Dallas1.Level3.net (4.69.145.62) 13.318 ms vlan90.csw4.Dallas1.Level3.net (4.69.145.254) 0.554 ms > 14 ae-3-80.edge2.Dallas1.Level3.net (4.69.145.139) 0.723 ms ae-4-90.edge2.Dallas1.Level3.net (4.69.145.203) 12.793 ms ae-1-60.edge2.Dallas1.Level3.net (4.69.145.11) 0.494 ms > 15 vlan80.csw3.Dallas1.Level3.net (4.69.145.190) 0.554 ms vlan90.csw4.Dallas1.Level3.net (4.69.145.254) 0.541 ms vlan80.csw3.Dallas1.Level3.net (4.69.145.190) 2.040 ms > 16 ae-4-90.edge2.Dallas1.Level3.net (4.69.145.203) 12.294 ms ae-3-80.edge2.Dallas1.Level3.net (4.69.145.139) 0.896 ms 0.790 ms > 17 vlan80.csw3.Dallas1.Level3.net (4.69.145.190) 0.590 ms vlan60.csw1.Dallas1.Level3.net (4.69.145.62) 0.610 ms vlan80.csw3.Dallas1.Level3.net (4.69.145.190) 0.932 ms > 18 ae-1-60.edge2.Dallas1.Level3.net (4.69.145.11) 0.522 ms ae-4-90.edge2.Dallas1.Level3.net (4.69.145.203) 11.423 ms ae-3-80.edge2.Dallas1.Level3.net (4.69.145.139) 0.747 ms > 19 vlan90.csw4.Dallas1.Level3.net (4.69.145.254) 0.673 ms vlan80.csw3.Dallas1.Level3.net (4.69.145.190) 0.803 ms vlan60.csw1.Dallas1.Level3.net (4.69.145.62) 0.638 ms > 20 ae-1-60.edge2.Dallas1.Level3.net (4.69.145.11) 0.525 ms ae-3-80.edge2.Dallas1.Level3.net (4.69.145.139) 0.826 ms 0.876 ms > 21 vlan60.csw1.Dallas1.Level3.net (4.69.145.62) 0.635 ms 9.840 ms 9.404 ms > 22 ae-1-60.edge2.Dallas1.Level3.net (4.69.145.11) 0.622 ms 0.604 ms ae-4-90.edge2.Dallas1.Level3.net (4.69.145.203) 8.751 ms > 23 vlan80.csw3.Dallas1.Level3.net (4.69.145.190) 0.671 ms 0.817 ms 0.687 ms > 24 ae-3-80.edge2.Dallas1.Level3.net (4.69.145.139) 0.785 ms 0.754 ms ae-4-90.edge2.Dallas1.Level3.net (4.69.145.203) 4.774 ms > 25 vlan90.csw4.Dallas1.Level3.net (4.69.145.254) 0.633 ms 0.683 ms 0.795 ms > 26 ae-1-60.edge2.Dallas1.Level3.net (4.69.145.11) 0.659 ms ae-3-80.edge2.Dallas1.Level3.net (4.69.145.139) 0.758 ms 0.907 ms > 27 vlan60.csw1.Dallas1.Level3.net (4.69.145.62) 0.776 ms vlan90.csw4.Dallas1.Level3.net (4.69.145.254) 0.721 ms vlan60.csw1.Dallas1.Level3.net (4.69.145.62) 0.705 ms > 28 ae-4-90.edge2.Dallas1.Level3.net (4.69.145.203) 15.057 ms 14.660 ms ae-3-80.edge2.Dallas1.Level3.net (4.69.145.139) 0.871 ms > 29 vlan80.csw3.Dallas1.Level3.net (4.69.145.190) 0.864 ms vlan60.csw1.Dallas1.Level3.net (4.69.145.62) 0.752 ms 0.747 ms > 30 ae-3-80.edge2.Dallas1.Level3.net (4.69.145.139) 0.877 ms ae-1-60.edge2.Dallas1.Level3.net (4.69.145.11) 0.721 ms ae-4-90.edge2.Dallas1.Level3.net (4.69.145.203) 14.302 ms > > and, of course, email does not work From nanog at studio442.com.au Wed Apr 27 06:57:54 2016 From: nanog at studio442.com.au (Julien Goodwin) Date: Wed, 27 Apr 2016 16:57:54 +1000 Subject: phone fun, was GeoIP database issues and the real world consequences In-Reply-To: <973BE688-B573-42F8-8A84-A8ACB2419350@delong.com> References: <20160414153236.GA88366@ussenterprise.ufp.org> <570ED607.1070607@cox.net> <20160414002939.15867.qmail@ary.lan> <1460710177.364730809@apps.rackspace.com> <571105A6.3040607@nvcube.net> <20160415190936.043B346BE4B9@rock.dv.isc.org> <20160415212138.29C9146BF6E3@rock.dv.isc.org> <2CA30D4F-24F0-4E92-A633-31BF20A78B17@delong.com> <57179952.8040706@vaxination.ca> <5d5d8f55-6718-1929-dd99-d8b458873fa5@cox.net> <973BE688-B573-42F8-8A84-A8ACB2419350@delong.com> Message-ID: <572062F2.9050500@studio442.com.au> On 27/04/16 09:16, Owen DeLong wrote: > One thing I always found particularly amusing was that it used to be a toll call to call from San Jose East (408238) to Sunnyvale (I forget the NPA/NXX), but that there were several prefixes in San Jose West (e.g. 408360 IIRC) where it was free to call from San Jose East and could place a free call to Sunnyvale. > > I also discovered that a single line with call forwarding was relatively cheap per month and could forward many calls into a hunt group. > > So, we used to extend the toll-free reach of BBS systems by finding ?friends? with houses in strategic prefixes and having them install a single telephone line with call forwarding. Then, once the line was installed, we?d run over to the location, program the forwarder to go to the BBS hunt lead number and voila? Instant toll free unlimited BBS calling for another 20-30 prefixes for less than $15/month and completely legal. > > At first, we thought we had to hide what we were doing as we were sure that the phone company would object, but we later discovered that absent a PUC proceeding to change the tariff they really didn?t have anything they could say about it. We started showing up on the day of install to dial in the forwarding and confirm functionality while the tech was still on site. You should have seen some of the reactions when we showed up with a butt set, set up call forwarding, told someone to make a test call and waited for positive confirmation. Priceless. Similar things happened in Australia, with more than one ISP using this to offer lower-toll dial-in numbers to their customers back in the day. From randy at psg.com Wed Apr 27 07:18:00 2016 From: randy at psg.com (Randy Bush) Date: Wed, 27 Apr 2016 16:18:00 +0900 Subject: trout views In-Reply-To: <572036EA.1070600@network-services.uoregon.edu> References: <572036EA.1070600@network-services.uoregon.edu> Message-ID: > That's the normal Monday morning maint window > for UO, when they all too frequently make us > disappear... :( as there, barbers here are also closed on mondays. thanks for clue From johnl at iecc.com Wed Apr 27 14:17:57 2016 From: johnl at iecc.com (John Levine) Date: 27 Apr 2016 14:17:57 -0000 Subject: phone fun, was GeoIP database issues and the real world consequences In-Reply-To: Message-ID: <20160427141757.51835.qmail@ary.lan> >> On our VOIP service we include US, Canada and Puerto Rico as "local" >> calling. >I would imagine for VOIP that's because all three are country code 1 :) If you know a VoIP carrier that offers flat rates to 1-473, 1-664, and 1-767, I know some people who'd like to talk to you. At great length. R's, John From jtk at cymru.com Wed Apr 27 15:58:23 2016 From: jtk at cymru.com (John Kristoff) Date: Wed, 27 Apr 2016 10:58:23 -0500 Subject: BGP FlowSpec In-Reply-To: References: Message-ID: <20160427105823.12639135@localhost> On Thu, 21 Apr 2016 09:46:13 +0200 Martin Bacher wrote: > - Intra-AS BGP FlowSpec deployment: Who is running it? For which kind > of attacks are you using it? Are you only dropping or rate-limiting > certain traffic or are you also using the redirect/remark > capabilities? What are the limitations from your perspective? Are you > facing any operational issues? How are you injecting the FlowSpec > routes? Unless you received a number of private responses, perhaps the lack of public responses is telling. I've heard of a few networks doing this and there is some public record of it being used, including one instance where a bad rule was behind a serious outage: > - Inter-AS: Who is running Inter-AS FlowSpec deployments? What is > your experience? Are there any concerns regarding Inter-AS > deployments? Has anyone done interop tests? You might mine public, archived BGP data and see if there are any traffic filtering rules present (they are encoded in extended communities, which are optional, transitive). We once tried to coordinate an Inter-AS flow-spec project, but it failed miserably due to lack of interest. For posterity, here is the project page: Literally the only people who were interested in it at the time was one of the spec's co-authors. :-) Since then, we have tried a more modest approach using the well known BGP RTBH technique: This has been much more successful and since we've started we've probably had about a dozen networks express interest in flow-spec rules. Verification of rules is potentially tricky, but widespread interest still lags in my estimation. > - How are you detecting DDoS attacks (Netflow, in-line probes, ..?) > and which applications are you using for the analysis (Peakflow, > Open-Source tools, ..?) Not speaking for anyone in particular, but don't forget about user complaints. In some cases a network may not notice (or care) if an attack is below a certain threshold for their network, but above a stress point downstream. John From hank at efes.iucc.ac.il Wed Apr 27 16:09:54 2016 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Wed, 27 Apr 2016 19:09:54 +0300 Subject: BGP FlowSpec In-Reply-To: <20160427105823.12639135@localhost> References: <20160427105823.12639135@localhost> Message-ID: <80e234dc-1b87-bb23-41a1-93c7401a9f32@efes.iucc.ac.il> On 27/04/2016 18:58, John Kristoff wrote: > On Thu, 21 Apr 2016 09:46:13 +0200 > Martin Bacher wrote: > >> - Intra-AS BGP FlowSpec deployment: Who is running it? For which kind >> of attacks are you using it? Are you only dropping or rate-limiting >> certain traffic or are you also using the redirect/remark >> capabilities? What are the limitations from your perspective? Are you >> facing any operational issues? How are you injecting the FlowSpec >> routes? > Unless you received a number of private responses, perhaps the lack of > public responses is telling. Geant runs a Firewall of Demand based on BGP Flowspec (Juniper routers). You can read more about it here: http://www.geant.org/Networks/Network_Operations/PublishingImages/Pages/Firewall-on-Demand/Firewall%20on%20Demand%20User%20Guide.pdf https://www.terena.org/activities/tf-csirt/meeting44/Firewall%20on%20Demand_Las_Palmas.pdf Regards, Hank > > I've heard of a few networks doing this and there is some public record > of it being used, including one instance where a bad rule was behind a > serious outage: > > > >> - Inter-AS: Who is running Inter-AS FlowSpec deployments? What is >> your experience? Are there any concerns regarding Inter-AS >> deployments? Has anyone done interop tests? > You might mine public, archived BGP data and see if there are any > traffic filtering rules present (they are encoded in extended > communities, which are optional, transitive). > > We once tried to coordinate an Inter-AS flow-spec project, but it > failed miserably due to lack of interest. For posterity, here is the > project page: > > > > Literally the only people who were interested in it at the time was one > of the spec's co-authors. :-) > > Since then, we have tried a more modest approach using the well known > BGP RTBH technique: > > > > This has been much more successful and since we've started we've > probably had about a dozen networks express interest in flow-spec > rules. Verification of rules is potentially tricky, but > widespread interest still lags in my estimation. > >> - How are you detecting DDoS attacks (Netflow, in-line probes, ..?) >> and which applications are you using for the analysis (Peakflow, >> Open-Source tools, ..?) > Not speaking for anyone in particular, but don't forget about user > complaints. In some cases a network may not notice (or care) if an > attack is below a certain threshold for their network, but above a > stress point downstream. > > John > From Matthew.Black at csulb.edu Wed Apr 27 16:46:04 2016 From: Matthew.Black at csulb.edu (Matthew Black) Date: Wed, 27 Apr 2016 16:46:04 +0000 Subject: phone fun, was GeoIP database issues and the real world consequences In-Reply-To: <5d5d8f55-6718-1929-dd99-d8b458873fa5@cox.net> References: <20160414153236.GA88366@ussenterprise.ufp.org> <570ED607.1070607@cox.net> <20160414002939.15867.qmail@ary.lan> <1460710177.364730809@apps.rackspace.com> <571105A6.3040607@nvcube.net> <20160415190936.043B346BE4B9@rock.dv.isc.org> <20160415212138.29C9146BF6E3@rock.dv.isc.org> <2CA30D4F-24F0-4E92-A633-31BF20A78B17@delong.com> <57179952.8040706@vaxination.ca> <5d5d8f55-6718-1929-dd99-d8b458873fa5@cox.net> Message-ID: One toll defeat trick that worked in GTE land in Southern California was to call the operator, then silently wait for them to hang up. Rattle the receiver hook several times for them to come back on the line and they would not know the caller's telephone number. -----Original Message----- From: NANOG [mailto:nanog-bounces+matthew.black=csulb.edu at nanog.org] On Behalf Of Larry Sheldon Sent: Tuesday, April 26, 2016 12:11 PM To: nanog at nanog.org Subject: Re: phone fun, was GeoIP database issues and the real world consequences On 4/20/2016 10:15, Owen DeLong wrote: > >> On Apr 20, 2016, at 7:59 AM, Jean-Francois Mezei wrote: >> >> On 2016-04-20 10:52, Owen DeLong wrote: >> >>> For the most part, ?long distance? calls within the US are a thing of the >>> past and at least one mobile carrier now treats US/CA/MX as a single >>> local calling area >> >> >> Is this a case of telcos having switched to IP trunks and can reach >> other carriers for "free" >> >> Or are wholesale long distance still billed between carriers but at >> prices so low that they can afford to offer "free" long distance at >> retail level ? > > I think it boiled down to a recognition that the costs of billing were beginning to account for something like $0.99 of every $1 billed. I wonder if the costs of avoiding-preventing-investigating toll fraud final grow to consume the profit in the product. I know that long ago there were things that I thought were insanely silly. A few examples: As an ordinary citizen I was amused and annoyed, in the case where a toll charge had been contested (and perforce refunded) there would often be several non-revenue calls to the protesting number asking whoever answered if they knew anybody in the called city, or if they knew who the called number belonged to. (Proper answer in any case: Who or what I know is none of your business.) Often there would calls to the called number (super irritating because the error was in the recording--later learned to be poor handwriting) asking the reciprocal questions except that often they had no idea that a call had been made. I was a Toll Transmissionman for a number or years back in the last iceage and one of the onerous tasks the supervisor had was "verifying the phone bill" which might be a stack as much as six inches tall. The evening shift supervisor (or one of them in a large office, like Los Angeles 1 Telegraph, where I worked for a while) would go through the bill, line by line, page by page, looking at the called number an d if he recognized it and placing a check mark next to it, If he did not recognize it, he would search the many lists in the office to see it was shown, and adding a check mark if a list showed it for a likely sounding legal call. If that didn't work he would probably have to call the number to see who answered (adding a wasted revenue-call path to the wreckage). Most often it would turn out to be the home telephone number of a repair supervisor in West Sweatsock, Montana, who had been called because a somebody who protested the policy that the repairman going fishing meant some problem would not be addressed for several days. So he put a check mark next to the number and moved on. Which meant the number would show up on the next month's bill. And it would again not be recognized from memory. And so forth and so on. Until eventually, after several months, the number would be recognized, check-marked without drama, and disappear forever from the bill. Lastly, in later years I was assigned to the the Revenue Accounting organization (to write programs for printing telephone books) and came to realize that there were a LOT of people in RA working with a LOT of people in the Chief Special Agents organization using a LOT of computer time to analyze Toll records for fraud patterns. Oops, not quite lastly.... Looking back at my Toll Plant days in the heyday of Captain Crunch--there were a lot engineering hours redesigning Toll equipment, and plant hours modifying or replacing equipment do defeat the engineering efforts of the Blue Box Boys. -- "Everybody is a genius. But if you judge a fish by its ability to climb a tree, it will live its whole life believing that it is stupid." --Albert Einstein From baptiste at bitsofnetworks.org Wed Apr 27 19:34:21 2016 From: baptiste at bitsofnetworks.org (Baptiste Jonglez) Date: Wed, 27 Apr 2016 21:34:21 +0200 Subject: IPv6 prefix from T-Mobile USA used but not announced in BGP (2607:7700::/32) Message-ID: <20160427193420.GA27020@lud.polynome.dn42> Hi, While doing statistics on the participants of a public DHT, I was surprised to see some IP addresses that are not present in the DFZ: 2607:7700:0:25::4e00:605b 2607:7700:0:25::4e25:8ce8 2607:7700:0:25::c808:db2c 2607:7700:0:4::3294:6683 2607:7700:0:4::4c09:4d39 2607:7700:0:4::5985:87d1 2607:7700:0:4::5d7d:3df8 All those IP are in 2607:7700::/32, allocated to T-Mobile USA but never announced: https://stat.ripe.net/2607%3A7700%3A%3A%2F32#tabId=at-a-glance What could explain their usage in an application? Some form of address translation? Maybe these addresses have been used as source address in outgoing packets, which would indicate IPv6 tests in T-Mobile? (but obviously, nobody is able to answer such packets). Baptiste -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From cb.list6 at gmail.com Wed Apr 27 20:04:37 2016 From: cb.list6 at gmail.com (Ca By) Date: Wed, 27 Apr 2016 13:04:37 -0700 Subject: IPv6 prefix from T-Mobile USA used but not announced in BGP (2607:7700::/32) In-Reply-To: <20160427193420.GA27020@lud.polynome.dn42> References: <20160427193420.GA27020@lud.polynome.dn42> Message-ID: On Wednesday, April 27, 2016, Baptiste Jonglez wrote: > Hi, > > While doing statistics on the participants of a public DHT, I was > surprised to see some IP addresses that are not present in the DFZ: > > 2607:7700:0:25::4e00:605b > 2607:7700:0:25::4e25:8ce8 > 2607:7700:0:25::c808:db2c > 2607:7700:0:4::3294:6683 > 2607:7700:0:4::4c09:4d39 > 2607:7700:0:4::5985:87d1 > 2607:7700:0:4::5d7d:3df8 > > All those IP are in 2607:7700::/32, allocated to T-Mobile USA but never > announced: > > https://stat.ripe.net/2607%3A7700%3A%3A%2F32#tabId=at-a-glance > > What could explain their usage in an application? Some form of address > translation? Maybe these addresses have been used as source address in > outgoing packets, which would indicate IPv6 tests in T-Mobile? (but > obviously, nobody is able to answer such packets). > > Baptiste > You see these addresses because your DHT is not supporting IP correctly. Enable ipv6 and your flaw will be resolved and you will no longer see these addresses. CB From lists at die.net Wed Apr 27 20:16:28 2016 From: lists at die.net (Aaron Hopkins) Date: Wed, 27 Apr 2016 13:16:28 -0700 (PDT) Subject: IPv6 prefix from T-Mobile USA used but not announced in BGP (2607:7700::/32) In-Reply-To: <20160427193420.GA27020@lud.polynome.dn42> References: <20160427193420.GA27020@lud.polynome.dn42> Message-ID: On Wed, 27 Apr 2016, Baptiste Jonglez wrote: > While doing statistics on the participants of a public DHT, I was > surprised to see some IP addresses that are not present in the DFZ: I believe those are used by T-mobile's 464XLAT (RFC 6877) implementation. Recent Android on T-mobile is IPv6-only and has no ability to connect to raw IPv4 addresses. T-mobile's DNS servers are only asked by these devices to translate hostnames to IPv6 addresses. If they can't find an IPv6 address, they will look up the IPv4 address for a hostname, and pack it into the bottom 32 bits of an IPv6 address that routes to a IPv6-to-IPv4 NAT device. > 2607:7700:0:25::4e00:605b 4e00:605b -> 78.0.96.91 -- Aaron From cb.list6 at gmail.com Wed Apr 27 20:58:39 2016 From: cb.list6 at gmail.com (Ca By) Date: Wed, 27 Apr 2016 13:58:39 -0700 Subject: IPv6 prefix from T-Mobile USA used but not announced in BGP (2607:7700::/32) In-Reply-To: References: <20160427193420.GA27020@lud.polynome.dn42> Message-ID: On Wednesday, April 27, 2016, Aaron Hopkins wrote: > On Wed, 27 Apr 2016, Baptiste Jonglez wrote: > > While doing statistics on the participants of a public DHT, I was >> surprised to see some IP addresses that are not present in the DFZ: >> > > I believe those are used by T-mobile's 464XLAT (RFC 6877) implementation. > > Recent Android on T-mobile is IPv6-only and has no ability to connect to > raw IPv4 addresses. T-mobile's DNS servers are only asked by these devices > to translate hostnames to IPv6 addresses. If they can't find an IPv6 > address, they will look up the IPv4 address for a hostname, and pack it > into > the bottom 32 bits of an IPv6 address that routes to a IPv6-to-IPv4 NAT > device. > > 2607:7700:0:25::4e00:605b >> > > 4e00:605b -> 78.0.96.91 > > -- Aaron > Apple has also required the ability for ipv6-only operations https://developer.apple.com/news/?id=08282015a From baptiste at bitsofnetworks.org Wed Apr 27 21:09:15 2016 From: baptiste at bitsofnetworks.org (Baptiste Jonglez) Date: Wed, 27 Apr 2016 23:09:15 +0200 Subject: IPv6 prefix from T-Mobile USA used but not announced in BGP (2607:7700::/32) In-Reply-To: References: <20160427193420.GA27020@lud.polynome.dn42> Message-ID: <20160427210915.GB27020@lud.polynome.dn42> On Wed, Apr 27, 2016 at 01:16:28PM -0700, Aaron Hopkins wrote: > On Wed, 27 Apr 2016, Baptiste Jonglez wrote: > > >While doing statistics on the participants of a public DHT, I was > >surprised to see some IP addresses that are not present in the DFZ: > > I believe those are used by T-mobile's 464XLAT (RFC 6877) implementation. > > Recent Android on T-mobile is IPv6-only and has no ability to connect to > raw IPv4 addresses. T-mobile's DNS servers are only asked by these devices > to translate hostnames to IPv6 addresses. If they can't find an IPv6 > address, they will look up the IPv4 address for a hostname, and pack it into > the bottom 32 bits of an IPv6 address that routes to a IPv6-to-IPv4 NAT > device. Thanks, I had forgotten that DNS64 is possible without using the well-known prefix. The encoded IPv4 addresses seem to belong to other peers of the DHT. So, if this is basically DNS64/NAT64, these IP addresses should not be seen as source or destination address outside of T-Mobile's network, and are not attached to the interface of any device. I can see two possible explanations: 1/ packets with src or dest IP in 2607:7700::/32 somehow escaped T-Mobile's network, without being translated back to IPv4. They caused other DHT nodes to believe they have incoming peers in 2607:7700::/32. 2/ there is an interesting bug in the DHT software when run behind 464XLAT (btw, the DHT is dual-stack and supports IPv6 just fine) I still wonder how this can happen, because the DHT does not use DNS at all... Baptiste -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From baptiste at bitsofnetworks.org Wed Apr 27 22:31:44 2016 From: baptiste at bitsofnetworks.org (Baptiste Jonglez) Date: Thu, 28 Apr 2016 00:31:44 +0200 Subject: IPv6 prefix from T-Mobile USA used but not announced in BGP (2607:7700::/32) In-Reply-To: References: <20160427193420.GA27020@lud.polynome.dn42> <20160427210915.GB27020@lud.polynome.dn42> Message-ID: <20160427223144.GC27020@lud.polynome.dn42> On Wed, Apr 27, 2016 at 02:38:41PM -0700, Ca By wrote: > What behavior do you expect when an ipv6only node connects to an ipv4only > node , which is the tmobile case? How is that address of the address > report? As far as I know, IPv4-only DHT nodes do not directly communicate with IPv6-only DHT nodes, I don't see how this would be possible in general. The code of the DHT client is here: https://github.com/savoirfairelinux/opendht > On Wednesday, April 27, 2016, Baptiste Jonglez > wrote: > > > On Wed, Apr 27, 2016 at 01:16:28PM -0700, Aaron Hopkins wrote: > > > On Wed, 27 Apr 2016, Baptiste Jonglez wrote: > > > > > > >While doing statistics on the participants of a public DHT, I was > > > >surprised to see some IP addresses that are not present in the DFZ: > > > > > > I believe those are used by T-mobile's 464XLAT (RFC 6877) implementation. > > > > > > Recent Android on T-mobile is IPv6-only and has no ability to connect to > > > raw IPv4 addresses. T-mobile's DNS servers are only asked by these > > devices > > > to translate hostnames to IPv6 addresses. If they can't find an IPv6 > > > address, they will look up the IPv4 address for a hostname, and pack it > > into > > > the bottom 32 bits of an IPv6 address that routes to a IPv6-to-IPv4 NAT > > > device. > > > > Thanks, I had forgotten that DNS64 is possible without using the > > well-known prefix. The encoded IPv4 addresses seem to belong to other > > peers of the DHT. > > > > So, if this is basically DNS64/NAT64, these IP addresses should not be > > seen as source or destination address outside of T-Mobile's network, and > > are not attached to the interface of any device. > > > > I can see two possible explanations: > > > > 1/ packets with src or dest IP in 2607:7700::/32 somehow escaped > > T-Mobile's network, without being translated back to IPv4. They caused > > other DHT nodes to believe they have incoming peers in 2607:7700::/32. > > > > 2/ there is an interesting bug in the DHT software when run behind 464XLAT > > (btw, the DHT is dual-stack and supports IPv6 just fine) > > > > I still wonder how this can happen, because the DHT does not use DNS at > > all... > > > > Baptiste > > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From lists at die.net Wed Apr 27 23:40:38 2016 From: lists at die.net (Aaron Hopkins) Date: Wed, 27 Apr 2016 16:40:38 -0700 (PDT) Subject: IPv6 prefix from T-Mobile USA used but not announced in BGP (2607:7700::/32) In-Reply-To: <20160427210915.GB27020@lud.polynome.dn42> References: <20160427193420.GA27020@lud.polynome.dn42> <20160427210915.GB27020@lud.polynome.dn42> Message-ID: On Wed, 27 Apr 2016, Baptiste Jonglez wrote: > So, if this is basically DNS64/NAT64, these IP addresses should not be > seen as source or destination address outside of T-Mobile's network, and > are not attached to the interface of any device. Based on http://dan.drown.org/android/clat/, it looks like it may be possible for an IPv4-only application to connect to raw IPv4 addresses through a IPv4-to-IPv6 NAT service on the Android device itself, which then is transported over IPv6 to T-mobile's IPv6-to-IPv4 NAT device. Skimming https://github.com/savoirfairelinux/opendht/blob/master/src/dht.cpp, my guess is that new peers find your IPv4 address:port (on T-mobile's IPv6-to-IPv4 NAT device) in the DHT and contact you, which somehow doesn't get correctly translated back to IPv4 before it makes it to your application, so you are seeing the untranslated IPv6 address. Replying to the new peer on the T-mobile-internal IPv6 address should still work as long as you stay on T-mobile's network but are of limited use otherwise. -- Aaron From pkranz at unwiredltd.com Wed Apr 27 23:41:16 2016 From: pkranz at unwiredltd.com (Peter Kranz) Date: Wed, 27 Apr 2016 16:41:16 -0700 Subject: Arista Routing Solutions In-Reply-To: References: Message-ID: <12cd01d1a0de$4b440d70$e1cc2850$@unwiredltd.com> Ryan, Curious if you have any thoughts on the longevity of the 7500R and 7280R survival's with IPv4 full tables? How full are you seeing the TCAM getting today (I'm assuming they are doing some form of selective download)? And if we are currently adding 100k/routes a year, how much longer will it last? -Peter From ryan at finnesey.com Thu Apr 28 04:30:23 2016 From: ryan at finnesey.com (Ryan Finnesey) Date: Thu, 28 Apr 2016 04:30:23 +0000 Subject: carrier grade fax boards? Message-ID: I was wondering if anyone had any recommendations on carrier grade fax boards that are SIP based? Cheers Ryan From ltd at interlink.com.au Thu Apr 28 05:33:18 2016 From: ltd at interlink.com.au (lincoln dale) Date: Wed, 27 Apr 2016 22:33:18 -0700 Subject: Arista Routing Solutions In-Reply-To: <12cd01d1a0de$4b440d70$e1cc2850$@unwiredltd.com> References: <12cd01d1a0de$4b440d70$e1cc2850$@unwiredltd.com> Message-ID: On Wed, Apr 27, 2016 at 4:41 PM, Peter Kranz wrote: > Curious if you have any thoughts on the longevity of the 7500R and > 7280R survival's with IPv4 full tables? How full are you seeing the TCAM > getting today (I'm assuming they are doing some form of selective > download)? And if we are currently adding 100k/routes a year, how much > longer will it last? > I can't speak for Ryan or Netflix, but we (Arista) are stating our technique is good for 1M+ prefixes of IPv4+v6 combined. Internet right now is at between 575K and 635K IPv4 and between 28K and 35K IPv6 right now and its taken many many many years to get there, its foreseeable there's many years of growth there. Note that we don't do static partitioning between IPv4 and IPv6 and our how we do it has more headroom in it than we state, so we're confident. We're also not doing "selective download", this is every prefix in current table. What I can share is two different scenarios today: 1. a traditional internet edge router with multiple transit/peer providers, Internet as of right now, and a cloud customer that also has hundreds of thousands of prefixes internally Ryan's case might be different to others, but here are three scenarios deployed today: 1. a large hosting provider with full tables and many internal prefixes, 2. a cloud deployment. The former is at 854K IPv4 and 35K IPv6 of 'internet' as of a few weeks ago: 7500R# show ip route summary | grep Total Total Routes 575127 7500R# show ipv6 route summary | grep Total Total Routes 35511 7500R# show hardware capacity | grep Routing Forwarding Resources Usage Table Feature Chip Used Used Free Committed Best Case High Entries (%) Entries Entries Max Watermark Entries -------- ---------- --------- -------- ------ --------- ----------- ----------- --------- Routing Resource1 815 39% 1233 0 2048 817 Routing Resource2 469 45% 555 0 1024 471 Routing Resource3 14074 42% 18694 0 32768 14098 Routing V4Routes 696364 88% 89753 0 786432 697110 Routing V6Routes 0 0% 89753 0 786432 0 The latter is at 854K IPv4 + 45K IPv6: 7500R# show ip route summary | grep Total Total Routes 854393 7500R# show ipv6 route summary | grep Total Total Routes 45678 7500R# show hardware capacity | grep Routing Forwarding Resources Usage Table Feature Chip Used Used Free Committed Best Case High Entries (%) Entries Entries Max Watermark Entries -------- ---------- --------- -------- ------ --------- ----------- ----------- --------- Routing Resource1 1319 64% 729 0 2048 1320 Routing Resource2 809 79% 215 0 1024 814 Routing Resource3 24102 73% 8666 0 32768 24104 Routing V4Routes 644336 83% 124302 0 786432 644364 Routing V6Routes 17792 12% 124302 0 786432 17795 One could ask Geoff Huston where he thinks combined IPv4+v6 will exceed 1M entries but I would expect it to be many years away based on http://bgp.potaroo.net/ and we'd welcome discussions about if it you want to know our opinion [*] on how we're doing it will scale. What we're doing doesn't explode at 1M, there's headroom in it hence why we say "1M+". Again we're happy to talk about it, just ask your friendly arista person and if you don't know who to ask, ask me and i'll put you in touch with the right folks. cheers, lincoln. [*] ltd at arista.com From ti14m028 at technikum-wien.at Thu Apr 28 06:31:57 2016 From: ti14m028 at technikum-wien.at (Martin Bacher) Date: Thu, 28 Apr 2016 08:31:57 +0200 Subject: BGP FlowSpec In-Reply-To: <20160427105823.12639135@localhost> References: <20160427105823.12639135@localhost> Message-ID: <747DAE80-0E1A-4E5D-AC25-2DC269CFD33B@technikum-wien.at> > Am 27.04.2016 um 17:58 schrieb John Kristoff : > > On Thu, 21 Apr 2016 09:46:13 +0200 > Martin Bacher wrote: > >> - Intra-AS BGP FlowSpec deployment: Who is running it? For which kind >> of attacks are you using it? Are you only dropping or rate-limiting >> certain traffic or are you also using the redirect/remark >> capabilities? What are the limitations from your perspective? Are you >> facing any operational issues? How are you injecting the FlowSpec >> routes? > > Unless you received a number of private responses, perhaps the lack of > public responses is telling. > > I've heard of a few networks doing this and there is some public record > of it being used, including one instance where a bad rule was behind a > serious outage: > > Thanks for that information. I didn?t know about that outage and this is definitely something which is very important and worth mentioning in the paper. But i would rather say that this is a general risk. A fat fingers issue can always disconnect you from the internet as well as a software bug in a homogenous environment. > >> - Inter-AS: Who is running Inter-AS FlowSpec deployments? What is >> your experience? Are there any concerns regarding Inter-AS >> deployments? Has anyone done interop tests? > > You might mine public, archived BGP data and see if there are any > traffic filtering rules present (they are encoded in extended > communities, which are optional, transitive). I don?t think that I will find anything there because it is a dedicated SAFI. Only traffic filtering actions are encoded as extended communities. > > We once tried to coordinate an Inter-AS flow-spec project, but it > failed miserably due to lack of interest. For posterity, here is the > project page: > > I already came across your project but didn?t recognize that there is/was also some FlowSpec initiative. > > Literally the only people who were interested in it at the time was one > of the spec's co-authors. :-) That?s how it usually starts. ;) > > Since then, we have tried a more modest approach using the well known > BGP RTBH technique: > > > > This has been much more successful and since we've started we've > probably had about a dozen networks express interest in flow-spec > rules. Verification of rules is potentially tricky, but > widespread interest still lags in my estimation. Yes, RTBH is quite common and really helpful in the inter AS world. But eBGP FlowSpec is just offered by very few ISPs. I think that intra AS deployments are more common, but one wouldn?t be able to detect that unless somebody tells you that they are using it. > >> - How are you detecting DDoS attacks (Netflow, in-line probes, ..?) >> and which applications are you using for the analysis (Peakflow, >> Open-Source tools, ..?) > > Not speaking for anyone in particular, but don't forget about user > complaints. In some cases a network may not notice (or care) if an > attack is below a certain threshold for their network, but above a > stress point downstream. That?s true. They are selling IP-Transit and more traffic means more money. Upstream providers may only care if other customers are also affected or unless you pay them for protection. Thanks for your comments! Cheers, Martin > > John From ti14m028 at technikum-wien.at Thu Apr 28 06:34:49 2016 From: ti14m028 at technikum-wien.at (Martin Bacher) Date: Thu, 28 Apr 2016 08:34:49 +0200 Subject: BGP FlowSpec In-Reply-To: <80e234dc-1b87-bb23-41a1-93c7401a9f32@efes.iucc.ac.il> References: <20160427105823.12639135@localhost> <80e234dc-1b87-bb23-41a1-93c7401a9f32@efes.iucc.ac.il> Message-ID: <74A6998A-1023-499C-8BE3-E2936405EACD@technikum-wien.at> > Am 27.04.2016 um 18:09 schrieb Hank Nussbacher : > > On 27/04/2016 18:58, John Kristoff wrote: >> On Thu, 21 Apr 2016 09:46:13 +0200 >> Martin Bacher wrote: >> >>> - Intra-AS BGP FlowSpec deployment: Who is running it? For which kind >>> of attacks are you using it? Are you only dropping or rate-limiting >>> certain traffic or are you also using the redirect/remark >>> capabilities? What are the limitations from your perspective? Are you >>> facing any operational issues? How are you injecting the FlowSpec >>> routes? >> Unless you received a number of private responses, perhaps the lack of >> public responses is telling. > Geant runs a Firewall of Demand based on BGP Flowspec (Juniper > routers). You can read more about it here: > http://www.geant.org/Networks/Network_Operations/PublishingImages/Pages/Firewall-on-Demand/Firewall%20on%20Demand%20User%20Guide.pdf > https://www.terena.org/activities/tf-csirt/meeting44/Firewall%20on%20Demand_Las_Palmas.pdf Thank you Hank. That?s a pretty nice intra AS implementation with a nice interface for customers. Cheers, Martin > > Regards, > Hank > >> >> I've heard of a few networks doing this and there is some public record >> of it being used, including one instance where a bad rule was behind a >> serious outage: >> >> >> >>> - Inter-AS: Who is running Inter-AS FlowSpec deployments? What is >>> your experience? Are there any concerns regarding Inter-AS >>> deployments? Has anyone done interop tests? >> You might mine public, archived BGP data and see if there are any >> traffic filtering rules present (they are encoded in extended >> communities, which are optional, transitive). >> >> We once tried to coordinate an Inter-AS flow-spec project, but it >> failed miserably due to lack of interest. For posterity, here is the >> project page: >> >> >> >> Literally the only people who were interested in it at the time was one >> of the spec's co-authors. :-) >> >> Since then, we have tried a more modest approach using the well known >> BGP RTBH technique: >> >> >> >> This has been much more successful and since we've started we've >> probably had about a dozen networks express interest in flow-spec >> rules. Verification of rules is potentially tricky, but >> widespread interest still lags in my estimation. >> >>> - How are you detecting DDoS attacks (Netflow, in-line probes, ..?) >>> and which applications are you using for the analysis (Peakflow, >>> Open-Source tools, ..?) >> Not speaking for anyone in particular, but don't forget about user >> complaints. In some cases a network may not notice (or care) if an >> attack is below a certain threshold for their network, but above a >> stress point downstream. >> >> John >> > From Valdis.Kletnieks at vt.edu Thu Apr 28 06:36:23 2016 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Thu, 28 Apr 2016 02:36:23 -0400 Subject: carrier grade fax boards? In-Reply-To: References: Message-ID: <134110.1461825383@turing-police.cc.vt.edu> On Thu, 28 Apr 2016 04:30:23 -0000, Ryan Finnesey said: > I was wondering if anyone had any recommendations on carrier grade fax boards > that are SIP based? What would "carrier grade" even *mean* for a fax board? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From ryan at finnesey.com Thu Apr 28 06:41:23 2016 From: ryan at finnesey.com (Ryan Finnesey) Date: Thu, 28 Apr 2016 06:41:23 +0000 Subject: carrier grade fax boards? In-Reply-To: <134110.1461825383@turing-police.cc.vt.edu> References: <134110.1461825383@turing-police.cc.vt.edu> Message-ID: Fax hardware/boards that other members have used within service provider environments to deliver services to their end users . -----Original Message----- From: Valdis.Kletnieks at vt.edu [mailto:Valdis.Kletnieks at vt.edu] Sent: Thursday, April 28, 2016 2:36 AM To: Ryan Finnesey Cc: nanog at nanog.org Subject: Re: carrier grade fax boards? On Thu, 28 Apr 2016 04:30:23 -0000, Ryan Finnesey said: > I was wondering if anyone had any recommendations on carrier grade fax > boards that are SIP based? What would "carrier grade" even *mean* for a fax board? From piotr.1234 at interia.pl Thu Apr 28 07:48:09 2016 From: piotr.1234 at interia.pl (Piotr) Date: Thu, 28 Apr 2016 09:48:09 +0200 Subject: contact with mail support for domain cisco.com Message-ID: <0539596b-7365-c0b4-34f4-8d2cf86a43ef@interia.pl> Hi, There is a problem with sending emails from employees in @cisco.com domain to some certain domain. Emails in opposite direction pass without problem. No errors, warnings or any other logs at cisco's employees desktop.. We checked popular rbls, spamhauses, senderbase etc. Other domains on the same MX cluster receive emails from @cisco.com.. I try to get help in many ways ( cisco tac, a few account managers, channel partners) but without success.. Big thanks for contact via email: peter.handke.1966 at gmail.com or any other advice best regards, Peter From faisal at snappytelecom.net Thu Apr 28 11:02:03 2016 From: faisal at snappytelecom.net (Faisal Imtiaz) Date: Thu, 28 Apr 2016 11:02:03 +0000 (GMT) Subject: carrier grade fax boards? In-Reply-To: References: <134110.1461825383@turing-police.cc.vt.edu> Message-ID: <1667020644.21208.1461841323336.JavaMail.zimbra@snappytelecom.net> When you use the terms 'SIP' and 'Fax/Board' in the same sentence, it sort of becomes an oxymoron. In the analog world, we used to use 'Carrier grade' Fax/boards made by BrookTrout which was then acquired by Dialogic. (Truefax line), and there were a couple of others.. mostly these were cards with large amount of DSP's used for fax processing multiple channels on digital links (BRI/PRI/T1's etc). Since SIP is a 'communication protocol' which works with IP, there is no need for 'Fax/Board', since all everything needed can be done via software. The only reason one may need Hardware is to convert SIP to traditional TDM (POTS line or PRI/T1/E1 etc). Most of us are used to referring to these devices as IAD's. Having said that, what are you looking to do ? Traditional TDM fax or SIP based FOIP ? :) Regards. Faisal Imtiaz Snappy Internet & Telecom ----- Original Message ----- > From: "Ryan Finnesey" > To: "Valdis Kletnieks" > Cc: "nanog list" > Sent: Thursday, April 28, 2016 2:41:23 AM > Subject: RE: carrier grade fax boards? > Fax hardware/boards that other members have used within service provider > environments to deliver services to their end users . > > -----Original Message----- > From: Valdis.Kletnieks at vt.edu [mailto:Valdis.Kletnieks at vt.edu] > Sent: Thursday, April 28, 2016 2:36 AM > To: Ryan Finnesey > Cc: nanog at nanog.org > Subject: Re: carrier grade fax boards? > > On Thu, 28 Apr 2016 04:30:23 -0000, Ryan Finnesey said: >> I was wondering if anyone had any recommendations on carrier grade fax >> boards that are SIP based? > > What would "carrier grade" even *mean* for a fax board? From ahebert at pubnix.net Thu Apr 28 11:06:15 2016 From: ahebert at pubnix.net (Alain Hebert) Date: Thu, 28 Apr 2016 07:06:15 -0400 Subject: Arista Routing Solutions In-Reply-To: References: <12cd01d1a0de$4b440d70$e1cc2850$@unwiredltd.com> Message-ID: <18ad6c39-5e8d-55ec-8c05-3e96ca29b918@pubnix.net> Well, Once you eliminate the ~160k superfluous prefixes (last time I checked)... This is a none issue. Some work on some sort summary function would keep those devices alive... but we all know there is more money to be made the faster the device become obsolete :( ----- 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 04/28/16 01:33, lincoln dale wrote: > On Wed, Apr 27, 2016 at 4:41 PM, Peter Kranz wrote: > >> Curious if you have any thoughts on the longevity of the 7500R and >> 7280R survival's with IPv4 full tables? How full are you seeing the TCAM >> getting today (I'm assuming they are doing some form of selective >> download)? And if we are currently adding 100k/routes a year, how much >> longer will it last? >> > I can't speak for Ryan or Netflix, but we (Arista) are stating our > technique is good for 1M+ prefixes of IPv4+v6 combined. Internet right now > is at between 575K and 635K IPv4 and between 28K and 35K IPv6 right now and > its taken many many many years to get there, its foreseeable there's many > years of growth there. > Note that we don't do static partitioning between IPv4 and IPv6 and our how > we do it has more headroom in it than we state, so we're confident. We're > also not doing "selective download", this is every prefix in current table. > > What I can share is two different scenarios today: > > 1. a traditional internet edge router with multiple transit/peer providers, > Internet as of right now, and a cloud customer that also has hundreds of > thousands of prefixes internally > Ryan's case might be different to others, but here are three scenarios > deployed today: 1. a large hosting provider with full tables and many > internal prefixes, 2. a cloud deployment. > > The former is at 854K IPv4 and 35K IPv6 of 'internet' as of a few weeks ago: > > 7500R# show ip route summary | grep Total > Total Routes 575127 > 7500R# show ipv6 route summary | grep Total > Total Routes 35511 > 7500R# show hardware capacity | grep Routing > Forwarding Resources Usage > > Table Feature Chip Used Used Free Committed Best > Case High > Entries (%) Entries Entries > Max Watermark > > Entries > -------- ---------- --------- -------- ------ --------- ----------- > ----------- --------- > Routing Resource1 815 39% 1233 0 > 2048 817 > Routing Resource2 469 45% 555 0 > 1024 471 > Routing Resource3 14074 42% 18694 0 > 32768 14098 > Routing V4Routes 696364 88% 89753 0 > 786432 697110 > Routing V6Routes 0 0% 89753 0 > 786432 0 > > > The latter is at 854K IPv4 + 45K IPv6: > > 7500R# show ip route summary | grep Total > Total Routes 854393 > 7500R# show ipv6 route summary | grep Total > Total Routes 45678 > 7500R# show hardware capacity | grep Routing > Forwarding Resources Usage > > Table Feature Chip Used Used Free Committed Best > Case High > Entries (%) Entries Entries > Max Watermark > > Entries > -------- ---------- --------- -------- ------ --------- ----------- > ----------- --------- > Routing Resource1 1319 64% 729 0 > 2048 1320 > Routing Resource2 809 79% 215 0 > 1024 814 > Routing Resource3 24102 73% 8666 0 > 32768 24104 > Routing V4Routes 644336 83% 124302 0 > 786432 644364 > Routing V6Routes 17792 12% 124302 0 > 786432 17795 > > > One could ask Geoff Huston where he thinks combined IPv4+v6 will exceed 1M > entries but I would expect it to be many years away based on > http://bgp.potaroo.net/ and we'd welcome discussions about if it you want > to know our opinion [*] on how we're doing it will scale. What we're doing > doesn't explode at 1M, there's headroom in it hence why we say "1M+". Again > we're happy to talk about it, just ask your friendly arista person and if > you don't know who to ask, ask me and i'll put you in touch with the right > folks. > > > cheers, > > lincoln. [*] ltd at arista.com > From laszlo at heliacal.net Thu Apr 28 12:47:45 2016 From: laszlo at heliacal.net (Laszlo Hanyecz) Date: Thu, 28 Apr 2016 12:47:45 +0000 Subject: Arista Routing Solutions In-Reply-To: <18ad6c39-5e8d-55ec-8c05-3e96ca29b918@pubnix.net> References: <12cd01d1a0de$4b440d70$e1cc2850$@unwiredltd.com> <18ad6c39-5e8d-55ec-8c05-3e96ca29b918@pubnix.net> Message-ID: <57220671.2000305@heliacal.net> On 2016-04-28 11:06, Alain Hebert wrote: > Well, > > Once you eliminate the ~160k superfluous prefixes (last time I > checked)... This is a none issue. > > Some work on some sort summary function would keep those devices > alive... but we all know there is more money to be made the faster the > device become obsolete :( > > Can you explain how this works? How can a router determine which prefix is superfluous? How does it cope when a suppressed prefix is withdrawn or a more specific prefix is added? Is this just one of those 'it works some of the time' solutions or is this something that can be done safely with an appropriate algorithm? Thanks, Laszlo From z at amused.net Thu Apr 28 13:13:13 2016 From: z at amused.net (Patrick Cole) Date: Thu, 28 Apr 2016 23:13:13 +1000 Subject: Arista Routing Solutions In-Reply-To: <57220671.2000305@heliacal.net> References: <12cd01d1a0de$4b440d70$e1cc2850$@unwiredltd.com> <18ad6c39-5e8d-55ec-8c05-3e96ca29b918@pubnix.net> <57220671.2000305@heliacal.net> Message-ID: <20160428131313.GA71046@amused.net> Laszln, Thu, Apr 28, 2016 at 12:47:45PM +0000, Laszlo Hanyecz wrote: > On 2016-04-28 11:06, Alain Hebert wrote: > > > > Well, > > > > Once you eliminate the ~160k superfluous prefixes (last time I > > checked)... This is a none issue. > > > > Some work on some sort summary function would keep those devices > > alive... but we all know there is more money to be made the faster the > > device become obsolete :( > > > > > > Can you explain how this works? How can a router determine which prefix > is superfluous? How does it cope when a suppressed prefix is withdrawn > or a more specific prefix is added? Is this just one of those 'it works > some of the time' solutions or is this something that can be done safely > with an appropriate algorithm? A fair chunk of the routing table is aggregable. If multiple aggregable prefixes share the same nexthop, the HW entries can be summarised accordingly, reducing the HW resource footprint. Should one of the smaller prefixes be withdrawn or best path change to another nexthop, the control plane needs to be smart enough to adapt and reprogram the HW accordingly. It is a fairly logical and reasonable algorithm to construct -- Patrick Cole Senior Network Specialist World Without Wires PO Box 869. Palm Beach, QLD, 4221 Ph: 0410 626 630 From dcorbe at hammerfiber.com Thu Apr 28 13:43:09 2016 From: dcorbe at hammerfiber.com (Daniel Corbe) Date: Thu, 28 Apr 2016 09:43:09 -0400 Subject: NYC & Philly Metro rack stack and config Message-ID: <27757EDE-CC59-4B86-B503-A459AB64AE17@hammerfiber.com> If anyone in the NYC and Philly metro areas want to make a few extra bucks, contact me off list. I need someone to drop an initial config on some brocade routers and run some cabling. Best, Daniel From rjacobs at pslightwave.com Thu Apr 28 15:06:24 2016 From: rjacobs at pslightwave.com (Robert Jacobs) Date: Thu, 28 Apr 2016 15:06:24 +0000 Subject: carrier grade fax boards? In-Reply-To: <134110.1461825383@turing-police.cc.vt.edu> References: <134110.1461825383@turing-police.cc.vt.edu> Message-ID: I would not consider any fax board "carrier grade" that uses sip .... sip to pots for faxes is still hit and miss. -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Valdis.Kletnieks at vt.edu Sent: Thursday, April 28, 2016 1:36 AM To: Ryan Finnesey Cc: nanog at nanog.org Subject: Re: carrier grade fax boards? On Thu, 28 Apr 2016 04:30:23 -0000, Ryan Finnesey said: > I was wondering if anyone had any recommendations on carrier grade fax > boards that are SIP based? What would "carrier grade" even *mean* for a fax board? From hugo at slabnet.com Thu Apr 28 15:37:04 2016 From: hugo at slabnet.com (Hugo Slabbert) Date: Thu, 28 Apr 2016 08:37:04 -0700 Subject: contact with mail support for domain cisco.com In-Reply-To: <0539596b-7365-c0b4-34f4-8d2cf86a43ef@interia.pl> References: <0539596b-7365-c0b4-34f4-8d2cf86a43ef@interia.pl> Message-ID: <20160428153704.GB12318@bamboo.slabnet.com> On Thu 2016-Apr-28 09:48:09 +0200, Piotr wrote: >Hi, > >There is a problem with sending emails from employees in @cisco.com >domain to some certain domain. Emails in opposite direction pass >without problem. No errors, warnings or any other logs at cisco's >employees desktop.. We checked popular rbls, spamhauses, senderbase >etc. Other domains on the same MX cluster receive emails from >@cisco.com.. > >I try to get help in many ways ( cisco tac, a few account managers, >channel partners) but without success.. > >Big thanks for contact via email: peter.handke.1966 at gmail.com >or any other advice You've given us damn near zero information to go on. Are you with Cisco? Or managing some of these "certain domains" to which cisco.com addresses cannot send? It sounds like the latter and that seems more plausible as I'd be pretty surprised to find a cisco.com postmaster sending a vague request like this to nanog. I don't really get how TAC would be involved; have you tried postmaster at cisco.com? Assuming that you *are* the receiving side, what logs do you have on this? What are the names of these "certain domains"? Are they all under the same administrative control / same MXs (I'm assuming yes)? This also seems like something for mailop[1] rather than nanog. Fair warning; they're using Let's Encrypt and are having trouble with the rollover, so the cert's expired again. >best regards, >Peter -- Hugo Slabbert | email, xmpp/jabber: hugo at slabnet.com pgp key: B178313E | also on Signal [1] https://chilli.nosignal.org/mailman/listinfo/mailop -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: From kraig at enguity.com Thu Apr 28 17:10:47 2016 From: kraig at enguity.com (Kraig Beahn) Date: Thu, 28 Apr 2016 13:10:47 -0400 Subject: carrier grade fax boards? In-Reply-To: References: Message-ID: 100% Dialogic, we are currently using both of their carrier-grade boards and IMG's to deliver fax services in various flavors of transport configurations to end-users and wholesale customers. Pricey, but well worth every penny... MSP/FSP - https://www.dialogic.com/en/products/fax-boards-and-software/foip/fsp.aspx IMG series w/SS7 support - https://www.dialogic.com/en/products/gateways.aspx On Thu, Apr 28, 2016 at 12:30 AM, Ryan Finnesey wrote: > I was wondering if anyone had any recommendations on carrier grade fax > boards that are SIP based? > > Cheers > Ryan > > From eyeronic.design at gmail.com Thu Apr 28 17:14:08 2016 From: eyeronic.design at gmail.com (Mike Hale) Date: Thu, 28 Apr 2016 10:14:08 -0700 Subject: carrier grade fax boards? In-Reply-To: References: <134110.1461825383@turing-police.cc.vt.edu> Message-ID: Not really fax board, but there are ATA (analog telephony (?) adapters) that handle fax very well (and others that just suck at it). Certain versions of the Cisco ATA 180 series worked really well even over satellite; others were terrible. It's somewhat of a hit or miss area. How many users are you supporting? If you're looking for a device to just put on-prem at a customer site to handle fax, those ATAs are pretty easy to find. On Thu, Apr 28, 2016 at 8:06 AM, Robert Jacobs wrote: > I would not consider any fax board "carrier grade" that uses sip .... sip to pots for faxes is still hit and miss. > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Valdis.Kletnieks at vt.edu > Sent: Thursday, April 28, 2016 1:36 AM > To: Ryan Finnesey > Cc: nanog at nanog.org > Subject: Re: carrier grade fax boards? > > On Thu, 28 Apr 2016 04:30:23 -0000, Ryan Finnesey said: >> I was wondering if anyone had any recommendations on carrier grade fax >> boards that are SIP based? > > What would "carrier grade" even *mean* for a fax board? -- 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0 From jwbensley at gmail.com Thu Apr 28 18:32:32 2016 From: jwbensley at gmail.com (James Bensley) Date: Thu, 28 Apr 2016 19:32:32 +0100 Subject: Network Weathermap In-Reply-To: References: Message-ID: Hi all, I know its been a while since I posted this thread, I've been swamped. Finally I'm getting time to look back at this. I think I had 0 on-list replies and about 10 off-list private replies, so clearly others are having the same problem but not speaking openly about it. There were two main themes in the off list replies; 1. Several people are drawing in a tool like Visio and then importing the picture as a background to the weathermap plugin and adding the links and nodes over the top. 2. A couple of people were drawing in something else other than Visio that would spit out files containing objects and coordinates and then had written scripts to convert those coordinates to Weathermap plugin file format. Method 1 is OK, I really want it to be less hassle than that so 2 seems like the best idea. Only one person would share their conversion script with me briefly on PasteBin then it expired and it wasn't for Visio format files, so I didn't save it. Having a quick play in Visio just now the files are saved as XML formatted X/Y axis values. Bit of a Python novice but I'm thinking I could basically ingest a Visio file and parse the the XML and then iterate over it converting each "object" into weathermap syntax. That isn't too difficult however for the maps to be any good I need to think about the "via" feature for links in Weathermap to map them more clearly if they cross over each other. There might still also be a lot of hackery when it comes to mapping the imported nodes and links to actual ones in Cacti. It might be that you have to match all the imported nodes and links to RRDs the first time you import the diagram then on all future imports just new links and nodes. Before I commit the time to this, has anyone done this already or is anyone a absolute Lord of Python who wants to do it quicker than I can do it? :) Cheers, James. From sakamura at gmail.com Thu Apr 28 18:41:39 2016 From: sakamura at gmail.com (Ishmael Rufus) Date: Thu, 28 Apr 2016 13:41:39 -0500 Subject: Network Weathermap In-Reply-To: References: Message-ID: You could probably build the converter in PHP and make it a plugin of weathermap. You kids and your Python :) On Thu, Apr 28, 2016 at 1:32 PM, James Bensley wrote: > Hi all, > > I know its been a while since I posted this thread, I've been swamped. > Finally I'm getting time to look back at this. I think I had 0 on-list > replies and about 10 off-list private replies, so clearly others are having > the same problem but not speaking openly about it. > > There were two main themes in the off list replies; > > 1. Several people are drawing in a tool like Visio and then importing the > picture as a background to the weathermap plugin and adding the links and > nodes over the top. > > 2. A couple of people were drawing in something else other than Visio that > would spit out files containing objects and coordinates and then had > written scripts to convert those coordinates to Weathermap plugin file > format. > > Method 1 is OK, I really want it to be less hassle than that so 2 seems > like the best idea. Only one person would share their conversion script > with me briefly on PasteBin then it expired and it wasn't for Visio format > files, so I didn't save it. > > Having a quick play in Visio just now the files are saved as XML formatted > X/Y axis values. Bit of a Python novice but I'm thinking I could basically > ingest a Visio file and parse the the XML and then iterate over it > converting each "object" into weathermap syntax. > > That isn't too difficult however for the maps to be any good I need to > think about the "via" feature for links in Weathermap to map them more > clearly if they cross over each other. There might still also be a lot of > hackery when it comes to mapping the imported nodes and links to actual > ones in Cacti. It might be that you have to match all the imported nodes > and links to RRDs the first time you import the diagram then on all future > imports just new links and nodes. > > Before I commit the time to this, has anyone done this already or is anyone > a absolute Lord of Python who wants to do it quicker than I can do it? :) > > Cheers, > James. > From Timothy.Creswick at vorboss.com Thu Apr 28 19:22:36 2016 From: Timothy.Creswick at vorboss.com (Timothy Creswick) Date: Thu, 28 Apr 2016 20:22:36 +0100 Subject: Arista Routing Solutions In-Reply-To: References: <571BB662.8000804@ninjabadger.net> Message-ID: <6D526C4EE4FA2745AD0D768DC25211F008FE543B6A95@MBOX-CLUSTER.hosted.vorboss.net> > Just wanted to interject, the port density of the Arista switches is quite > impressive, especially considering the price point they're at. Not in response to any point specifically, but the major issue which stopped us buying Arista a few months ago was the rather out-dated attitude to 3rd party transceiver support. I'm sure there are plenty of people running Arista on 3rd party optics, but all the noises that were being made by the sales and technical guys suggested that we could find ourselves abandoned by their support or a policy change in the future. I don't fundamentally have an issue with vendor optics, except when they are excessively priced. One or two vendors will actually sell their 10Gbps optics at a price that's pretty hard to refuse, given that it's all supported. The same couldn't be said in this case. Additionally, the insistence that we would have to buy a "small number" of Arista optics with each device for testing purposes gets old very quickly. Again, I could get on-board with this if it's just for troubleshooting, but not when these additional optics suddenly add 15% to the overall buy price of each switch. At that point, other vendors are firmly back on the table. YMMV of course, I suspect especially if you're buying 100s of boxes. T From peter.phaal at gmail.com Thu Apr 28 19:33:49 2016 From: peter.phaal at gmail.com (Peter Phaal) Date: Thu, 28 Apr 2016 12:33:49 -0700 Subject: Network Weathermap In-Reply-To: References: Message-ID: Many drawing tools support SVG as a file export format. Exporting or converting the map to SVG format allows the map attributes (link colors, widths, etc) to be modulated using JavaScript embedded in the web page. As an example, the following SC15 weathermap was created by converting a PDF diagram of the network into an SVG file: http://blog.sflow.com/2015/11/sc15-live-real-time-weathermap.html The code is on GitHub and it wouldn't be hard to re-purpose: https://github.com/pphaal/sc15-weather The ESnet weathermap is very cool and they have open sourced the code: https://my.es.net/ http://www.hpcwire.com/2015/10/05/esnet-releases-software-for-building-interactive-network-portals/ On Thu, Apr 28, 2016 at 11:32 AM, James Bensley wrote: > Hi all, > > I know its been a while since I posted this thread, I've been swamped. > Finally I'm getting time to look back at this. I think I had 0 on-list > replies and about 10 off-list private replies, so clearly others are having > the same problem but not speaking openly about it. > > There were two main themes in the off list replies; > > 1. Several people are drawing in a tool like Visio and then importing the > picture as a background to the weathermap plugin and adding the links and > nodes over the top. > > 2. A couple of people were drawing in something else other than Visio that > would spit out files containing objects and coordinates and then had > written scripts to convert those coordinates to Weathermap plugin file > format. > > Method 1 is OK, I really want it to be less hassle than that so 2 seems > like the best idea. Only one person would share their conversion script > with me briefly on PasteBin then it expired and it wasn't for Visio format > files, so I didn't save it. > > Having a quick play in Visio just now the files are saved as XML formatted > X/Y axis values. Bit of a Python novice but I'm thinking I could basically > ingest a Visio file and parse the the XML and then iterate over it > converting each "object" into weathermap syntax. > > That isn't too difficult however for the maps to be any good I need to > think about the "via" feature for links in Weathermap to map them more > clearly if they cross over each other. There might still also be a lot of > hackery when it comes to mapping the imported nodes and links to actual > ones in Cacti. It might be that you have to match all the imported nodes > and links to RRDs the first time you import the diagram then on all future > imports just new links and nodes. > > Before I commit the time to this, has anyone done this already or is anyone > a absolute Lord of Python who wants to do it quicker than I can do it? :) > > Cheers, > James. From jwbensley at gmail.com Thu Apr 28 19:43:18 2016 From: jwbensley at gmail.com (James Bensley) Date: Thu, 28 Apr 2016 20:43:18 +0100 Subject: Network Weathermap In-Reply-To: References: Message-ID: On 28 April 2016 at 19:41, Ishmael Rufus wrote: > You could probably build the converter in PHP and make it a plugin of > weathermap. > > You kids and your Python :) I would prefer it to be PHP actually, people keep moaning at me for using PHP, which I am much more fluent in. However if it were in PHP it comes with the advantage of being in the same language the the rest of Cacti (more or less). Cheers, James. From jwbensley at gmail.com Thu Apr 28 19:45:02 2016 From: jwbensley at gmail.com (James Bensley) Date: Thu, 28 Apr 2016 20:45:02 +0100 Subject: Network Weathermap In-Reply-To: References: Message-ID: On 28 April 2016 at 20:33, Peter Phaal wrote: > Many drawing tools support SVG as a file export format. Exporting or > converting the map to SVG format allows the map attributes (link > colors, widths, etc) to be modulated using JavaScript embedded in the > web page. > > As an example, the following SC15 weathermap was created by converting > a PDF diagram of the network into an SVG file: > > http://blog.sflow.com/2015/11/sc15-live-real-time-weathermap.html > > The code is on GitHub and it wouldn't be hard to re-purpose: > > https://github.com/pphaal/sc15-weather > > The ESnet weathermap is very cool and they have open sourced the code: > > https://my.es.net/ > http://www.hpcwire.com/2015/10/05/esnet-releases-software-for-building-interactive-network-portals/ https://github.com/esnet/react-timeseries-charts/ https://github.com/esnet/react-network-diagrams/ Fwoooooor!!!!! Sorry Weathermap, you've been usurped! I think I'll write a wrapper in PHP to pull the data from RRDs and feed into that. Cheers, James. From colin.bodor at imperium.ca Thu Apr 28 18:01:45 2016 From: colin.bodor at imperium.ca (Colin Bodor) Date: Thu, 28 Apr 2016 18:01:45 +0000 Subject: carrier grade fax boards? In-Reply-To: References: <134110.1461825383@turing-police.cc.vt.edu> Message-ID: If looking for old school industrial faxing capabilities then maybe something like: https://www.dialogic.com/en/products/fax-boards-and-software/fax-boards.aspx I have a client who used to us them with a custom inbound dictation application and multiple PRIs to feed them (not the fax board, but dialogic) worked well. Not cheap for licensing... -C -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Mike Hale Sent: Thursday, April 28, 2016 11:14 AM To: Robert Jacobs Cc: nanog at nanog.org Subject: Re: carrier grade fax boards? Not really fax board, but there are ATA (analog telephony (?) adapters) that handle fax very well (and others that just suck at it). Certain versions of the Cisco ATA 180 series worked really well even over satellite; others were terrible. It's somewhat of a hit or miss area. How many users are you supporting? If you're looking for a device to just put on-prem at a customer site to handle fax, those ATAs are pretty easy to find. On Thu, Apr 28, 2016 at 8:06 AM, Robert Jacobs wrote: > I would not consider any fax board "carrier grade" that uses sip .... sip to pots for faxes is still hit and miss. > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of > Valdis.Kletnieks at vt.edu > Sent: Thursday, April 28, 2016 1:36 AM > To: Ryan Finnesey > Cc: nanog at nanog.org > Subject: Re: carrier grade fax boards? > > On Thu, 28 Apr 2016 04:30:23 -0000, Ryan Finnesey said: >> I was wondering if anyone had any recommendations on carrier grade >> fax boards that are SIP based? > > What would "carrier grade" even *mean* for a fax board? -- 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0 From pete at fiberphone.co.nz Thu Apr 28 21:27:57 2016 From: pete at fiberphone.co.nz (Pete Mundy) Date: Fri, 29 Apr 2016 09:27:57 +1200 Subject: carrier grade fax boards? In-Reply-To: <134110.1461825383@turing-police.cc.vt.edu> References: <134110.1461825383@turing-police.cc.vt.edu> Message-ID: <1063CA59-4437-46C4-848C-62B301559532@fiberphone.co.nz> > On 28/04/2016, at 6:36 pm, Valdis.Kletnieks at vt.edu wrote: > > On Thu, 28 Apr 2016 04:30:23 -0000, Ryan Finnesey said: >> I was wondering if anyone had any recommendations on carrier grade fax boards >> that are SIP based? > > What would "carrier grade" even *mean* for a fax board? I took it to mean "expensive". :) -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4118 bytes Desc: not available URL: From crivenburg at gmail.com Thu Apr 28 05:22:26 2016 From: crivenburg at gmail.com (Craig Rivenburg) Date: Thu, 28 Apr 2016 05:22:26 +0000 Subject: Multiple VRFs from provider, IP addressing Message-ID: Hi Nanog...looking for some advice. I have a customer who has a large network...approximately 130 sites across the US. Each site is fed via two providers, via two Separate CE Routers. It's a L3-VPN service. Each provider currently provides connectivity for 6 VRFs, each over a single service multiplexed UNI. Ie...there are 6 dot1q interfaces facing each provider, each sub-interface is in its own VRF. The network is going through a redesign, and one of my tasks is to consolidate and "streamline" IP addressing. Looking for a sanity check...I have this idea to make every dot1q sub-interface facing the provider the same point-to-point subnet. Specifically, facing a single provider, I want to use the same /30 subnet for all 6 VRFs. I'd use a separate /30 for each of the CE routers per site, so I could go from 12 /30s to 2 per site. I should note, PE-CE protocol is BGP, and behind the CE routers is a small iBGP network. I know it's technically possible to configure the OPs this way and under normal circumstances its fine. But, in this case, there is a whole lot of route leaking / cross target exchanges happening between VRFs. I still think it's okay...but can anyone think of a a failure mode that I may not have? Is what I'm thinking common practice? Is there a best practice for this sort of thing? Thanks! From tyler.haske at gmail.com Thu Apr 28 15:37:22 2016 From: tyler.haske at gmail.com (Tyler Haske) Date: Thu, 28 Apr 2016 11:37:22 -0400 Subject: BGP FlowSpec In-Reply-To: <74A6998A-1023-499C-8BE3-E2936405EACD@technikum-wien.at> References: <20160427105823.12639135@localhost> <80e234dc-1b87-bb23-41a1-93c7401a9f32@efes.iucc.ac.il> <74A6998A-1023-499C-8BE3-E2936405EACD@technikum-wien.at> Message-ID: Martin, > Last but not least: I am also looking for anonymized statistical data about DDoS attacks which I could use in the thesis. I am mainly interested in data about the > type of attacks, attack time, sources, source and destination ports, and so on. I know this something which is generally not shared, so I would really appreciate it if > someone would be able to share such data. Many companies are extremely reluctant to share their attack data. But that's OK, because there are other ways to get it. Have you investigated backscatter analysis? It's used to see ongoing and current Internet scope DDoS attacks. Inferring Internet Denial of Service Activity https://cseweb.ucsd.edu/~savage/papers/UsenixSec01.pdf Analyzing Large DDoS Attacks Using Multiple Data Sources https://www.cs.utah.edu/~kobus/docs/ddos.lsad.pdf ISP Security - Real World Techniques https://www.nanog.org/meetings/nanog23/presentations/greene.ppt A Summary of DoS/DDoS Prevention, Monitoring and Mitigation Techniques in a Service Provider Environment https://www.sans.org/reading-room/whitepapers/intrusion/summary-dos-ddos-prevention-monitoring-mitigation-techniques-service-provider-enviro-1212 Maybe you have access to some public IPs, then you can do this data collection yourself. Regards, Tyler From rwoolleynanog at gmail.com Fri Apr 29 02:21:13 2016 From: rwoolleynanog at gmail.com (Ryan Woolley) Date: Thu, 28 Apr 2016 22:21:13 -0400 Subject: Arista Routing Solutions In-Reply-To: References: <12cd01d1a0de$4b440d70$e1cc2850$@unwiredltd.com> Message-ID: On Thu, Apr 28, 2016 at 1:33 AM, lincoln dale wrote: > On Wed, Apr 27, 2016 at 4:41 PM, Peter Kranz > wrote: > >> Curious if you have any thoughts on the longevity of the 7500R >> and 7280R survival's with IPv4 full tables? How full are you seeing the >> TCAM getting today (I'm assuming they are doing some form of selective >> download)? And if we are currently adding 100k/routes a year, how much >> longer will it last? > > [...] > > One could ask Geoff Huston where he thinks combined IPv4+v6 will exceed 1M > entries but I would expect it to be many years away based on > http://bgp.potaroo.net/ and we'd welcome discussions about if it you want > to know our opinion [*] on how we're doing it will scale. What we're doing > doesn't explode at 1M, there's headroom in it hence why we say "1M+". Again > we're happy to talk about it, just ask your friendly arista person and if > you don't know who to ask, ask me and i'll put you in touch with the right > folks. > Peter, I'd point you to https://labs.apnic.net/?p=767 for more historical detail and a table with some (recent) predictions. The summary is that the rate is mostly linear at around 10% per year and even 1MM routes lasts quite comfortably beyond 5 years at the current growth rate. I am not particularly worried about the table growth rate (or Moore's law) changing dramatically. With respect to the utilization of the hardware, our setup is basically the same as Lincoln's scenario #1 and so utilization looks about the same, on both platforms. From hugo at slabnet.com Fri Apr 29 03:28:04 2016 From: hugo at slabnet.com (Hugo Slabbert) Date: Thu, 28 Apr 2016 20:28:04 -0700 Subject: Multiple VRFs from provider, IP addressing In-Reply-To: References: Message-ID: <20160429032804.GB3926@slab-wks-04.int.slabnet.com> On Thu 2016-Apr-28 05:22:26 +0000, Craig Rivenburg wrote: >Hi Nanog...looking for some advice. I have a customer who has a large >network...approximately 130 sites across the US. Each site is fed via two >providers, via two Separate CE Routers. It's a L3-VPN service. Each >provider currently provides connectivity for 6 VRFs, each over a single >service multiplexed UNI. Ie...there are 6 dot1q interfaces facing each >provider, each sub-interface is in its own VRF. > >The network is going through a redesign, and one of my tasks is to >consolidate and "streamline" IP addressing. > >Looking for a sanity check...I have this idea to make every dot1q >sub-interface facing the provider the same point-to-point subnet. >Specifically, facing a single provider, I want to use the same /30 subnet >for all 6 VRFs. I'd use a separate /30 for each of the CE routers per >site, so I could go from 12 /30s to 2 per site. I should note, PE-CE >protocol is BGP, and behind the CE routers is a small iBGP network. > >I know it's technically possible to configure the OPs this way and under >normal circumstances its fine. But, in this case, there is a whole lot of >route leaking / cross target exchanges happening between VRFs. I still >think it's okay...but can anyone think of a a failure mode that I may not >have? Is what I'm thinking common practice? Is there a best practice for >this sort of thing? 6 VRFs per site, across the board, with extensive leaking between VRFs. At the risk of second-guessing a design with very little insight into whatever requirements are going on behind the curtain: what's the point of all of those VRFs, especially if you're leaking routes back and forth fairly frequently/commonly? Are you using routing policy to split security zones or something? For the IP addressing "streamlining": I fail to see the benefit of having the same /30 across each dot1q sub-interface. If anything, this seems to confuse things and complicate troubleshooting (`ping no-resolve routing-instance `). If you're dealing with apparently complex route leaking between VRFs, I could see the fun of fat fingering your exports/imports and having the shared touchdown /30 of the local or remote sites leak into the wrong VRF(s). What problem are you trying to solve? Are you short on IPs for these touchdowns? Are they at a position in the topology where you could just swing them over to RFC1918 space? Or drop them to /31s (since they are ptp on dot1q sub-interfaces anyway) and half your IP allocation requirement for the touchdowns if that's the issue? >Thanks! -- Hugo Slabbert | email, xmpp/jabber: hugo at slabnet.com pgp key: B178313E | also on Signal -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From mark.tinka at seacom.mu Fri Apr 29 08:52:28 2016 From: mark.tinka at seacom.mu (Mark Tinka) Date: Fri, 29 Apr 2016 10:52:28 +0200 Subject: SAFNOG-3: Registration Now Open! Message-ID: Hello all. Pleased to inform you that registration for the SAFNOG-3 meeting, to be held in Windhoek, Namibia, 8th - 10th August, 2016, is now open. To register your participation for SAFNOG-3, please visit the link below: http://www.safnog.org/ Please note that you will be able to view who else is attending SAFNOG-3 at the bottom of the registration web site. We look forward to seeing you all in Windhoek. Cheers, Mark Tinka On Behalf of the SAFNOG Management Committee From ti14m028 at technikum-wien.at Fri Apr 29 09:02:35 2016 From: ti14m028 at technikum-wien.at (Martin Bacher) Date: Fri, 29 Apr 2016 11:02:35 +0200 Subject: BGP FlowSpec In-Reply-To: References: <20160427105823.12639135@localhost> <80e234dc-1b87-bb23-41a1-93c7401a9f32@efes.iucc.ac.il> <74A6998A-1023-499C-8BE3-E2936405EACD@technikum-wien.at> Message-ID: <29684468-31E1-48F0-805C-F5B25DF31533@technikum-wien.at> Hello Tyler, thanks for your reply. > Am 28.04.2016 um 17:37 schrieb Tyler Haske : > > Martin, > > > > Last but not least: I am also looking for anonymized statistical data about DDoS attacks which I could use in the thesis. I am mainly interested in data about the > > type of attacks, attack time, sources, source and destination ports, and so on. I know this something which is generally not shared, so I would really appreciate it if > > someone would be able to share such data. > > Many companies are extremely reluctant to share their attack data. But that's OK, because there are other ways to get it. > > Have you investigated backscatter analysis? It's used to see ongoing and current Internet scope DDoS attacks. I just had a look on that and thought that its only be able to detect some of the attacks. You might not detect large state of the art reflection and amplification attacks with that method. But i think it is useful for some sort of attacks like SYN flood. Do you agree? > > Inferring Internet Denial of Service Activity > https://cseweb.ucsd.edu/~savage/papers/UsenixSec01.pdf > > Analyzing Large DDoS Attacks Using Multiple Data Sources > https://www.cs.utah.edu/~kobus/docs/ddos.lsad.pdf > > ISP Security - Real World Techniques > https://www.nanog.org/meetings/nanog23/presentations/greene.ppt > > A Summary of DoS/DDoS Prevention, Monitoring and Mitigation Techniques in a Service Provider Environment > https://www.sans.org/reading-room/whitepapers/intrusion/summary-dos-ddos-prevention-monitoring-mitigation-techniques-service-provider-enviro-1212 > > Maybe you have access to some public IPs, then you can do this data collection yourself. Sure, I will definitely think about hat. Thanks again for your reply and for providing the links. Greetings, Martin > > Regards, > > Tyler > From ahebert at pubnix.net Fri Apr 29 12:17:41 2016 From: ahebert at pubnix.net (Alain Hebert) Date: Fri, 29 Apr 2016 08:17:41 -0400 Subject: Friday's Random Comment - About: Arista and FIB/RIB's In-Reply-To: <22e871d1-4209-d79c-f862-b1860bb03a8b@seacom.mu> References: <5705A3AC.5020903@tiedyenetworks.com> <4eec1f63-0e69-ac3f-78f9-b3fb5b3de0a6@seacom.mu> <22e871d1-4209-d79c-f862-b1860bb03a8b@seacom.mu> Message-ID: <00ea292f-e779-25ad-ce89-eae897e9516d@pubnix.net> While following that Arista chat... That reminded me of that little afternoon project years ago. So I decided to find new hamsters, fire up that VM, refresh the DB's and from the view point of a tiny 7206VXR/G1 with 2 T3 peers... The amount of superfluous subnet advertisement drop to ~120k from ~166k from the previous snapshot. And this is the distribution by country. country | superfluous --------------------+------------- United States | 28254 Brazil | 10012 China | 7537 India | 6449 Russian Federation | 4524 Korea, Republic of | 4062 Saudi Arabia | 3297 Australia | 2989 Indonesia | 2878 Hong Kong | 2251 Thailand | 2093 Canada | 2019 Taiwan | 1955 Ukraine | 1877 Singapore | 1856 Bulgaria | 1488 Argentina | 1436 Japan | 1403 Mexico | 1351 Chile | 1271 (Damn Canada, can't break top 10 again). PS: "Superfluous" is a nice way to say that the best path of a subnet is the same as his supernet. And yes I'm aware of the Weekly Routing Report, I was just curious to see it by country =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 04/13/16 15:17, Mark Tinka wrote: > > On 13/Apr/16 20:30, Colton Conor wrote: > >> How does the ASR 903 compare to the 920? When we got pricing for the >> ASR 903 it was more expensive than a real ASR 9k router. > Feature-wise, it's more mature than the ASR920, as it came before. > > Personally, I find it more of a device where you need a mix-and-match, > e.g., at a RAN site. Not my kind of thing; I focus purely on Ethernet in > a small form factor, which the ASR920 does very well. > > But I'd move this query to c-nsp. There are a bunch of good folk there > that use the ASR903 and can speak more authoritatively about it than I can. > > Mark. > From nick at foobar.org Fri Apr 29 12:48:14 2016 From: nick at foobar.org (Nick Hilliard) Date: Fri, 29 Apr 2016 13:48:14 +0100 Subject: Friday's Random Comment - About: Arista and FIB/RIB's In-Reply-To: <00ea292f-e779-25ad-ce89-eae897e9516d@pubnix.net> References: <5705A3AC.5020903@tiedyenetworks.com> <4eec1f63-0e69-ac3f-78f9-b3fb5b3de0a6@seacom.mu> <22e871d1-4209-d79c-f862-b1860bb03a8b@seacom.mu> <00ea292f-e779-25ad-ce89-eae897e9516d@pubnix.net> Message-ID: <5723580E.9030200@foobar.org> Alain Hebert wrote: > PS: "Superfluous" is a nice way to say that the best path of a > subnet is the same as his supernet. ... from the point of view of the paths that you see, which is to say two egress paths. Someone else on the internet may have a different set of bgp views which will give a different set of results for the bgp decision process. The more paths you receive from different sources, the more likely it is that this list of 120k "superfluous" prefixes will converge towards zero. You're right that it's often not necessary to accept all paths, and your fib view can optimised in a way that your rib shouldn't be. All these things can be used to drop the forwarding lookup engine resource requirements, although it is important to understand that there is no such thing as a free lunch and if you do this, there might well be edge cases which could cause your optimisation to fail and things to blow up horribly in your face. Still, it's an interesting thing to examine. Nick From laszlo at heliacal.net Fri Apr 29 13:05:56 2016 From: laszlo at heliacal.net (Laszlo Hanyecz) Date: Fri, 29 Apr 2016 13:05:56 +0000 Subject: Friday's Random Comment - About: Arista and FIB/RIB's In-Reply-To: <5723580E.9030200@foobar.org> References: <5705A3AC.5020903@tiedyenetworks.com> <4eec1f63-0e69-ac3f-78f9-b3fb5b3de0a6@seacom.mu> <22e871d1-4209-d79c-f862-b1860bb03a8b@seacom.mu> <00ea292f-e779-25ad-ce89-eae897e9516d@pubnix.net> <5723580E.9030200@foobar.org> Message-ID: <57235C34.2030800@heliacal.net> On 2016-04-29 12:48, Nick Hilliard wrote: > Alain Hebert wrote: >> PS: "Superfluous" is a nice way to say that the best path of a >> subnet is the same as his supernet. > ... from the point of view of the paths that you see, which is to say > two egress paths. Someone else on the internet may have a different set > of bgp views which will give a different set of results for the bgp > decision process. The more paths you receive from different sources, > the more likely it is that this list of 120k "superfluous" prefixes will > converge towards zero. > > You're right that it's often not necessary to accept all paths, and your > fib view can optimised in a way that your rib shouldn't be. All these > things can be used to drop the forwarding lookup engine resource > requirements, although it is important to understand that there is no > such thing as a free lunch and if you do this, there might well be edge > cases which could cause your optimisation to fail and things to blow up > horribly in your face. Still, it's an interesting thing to examine. > > Nick What Nick said is basically what I was asking about in the Arista thread. Are there new edge cases and new failure modes that are introduced by this strategy? It seems like you'd have to recompute the minimal set of forwarding rules each time a prefix is added or removed, and a single update may cause you to have to do many adds/removes to bring your compressed rules into sync, like when a hole is punched in an aggregated prefix. I'm curious about specific failure modes that can result from this, if anyone can share examples/experience with it. Thanks, Laszlo From dennis at justipit.com Fri Apr 29 13:08:53 2016 From: dennis at justipit.com (dennis) Date: Fri, 29 Apr 2016 06:08:53 -0700 Subject: BGP FlowSpec Message-ID: Hi Amplification attacks and syn floods are just touching the surface of ddos attack vectors. ?You should look into some industry reports: Here are a couple examples to get you started. https://www.radware.com/ert-report-2015/ http://www.verizonenterprise.com/verizon-insights-lab/dbir/2016/ Sent via the Samsung GALAXY S? 5, an AT&T 4G LTE smartphone -------- Original message -------- From: Martin Bacher Date: 4/29/2016 2:02 AM (GMT-08:00) To: Tyler Haske Cc: NANOG list Subject: Re: BGP FlowSpec Hello Tyler, thanks for your reply. > Am 28.04.2016 um 17:37 schrieb Tyler Haske : > > Martin, > > > > Last but not least: I am also looking for anonymized statistical data about DDoS attacks which I could use in the thesis. I am mainly interested in data about the > > type of attacks, attack time, sources, source and destination ports, and so on. I know this something which is generally not shared, so I would really appreciate it if > > someone would be able to share such data. > > Many companies are extremely reluctant to share their attack data. But that's OK, because there are other ways to get it. > > Have you investigated backscatter analysis? It's used to see ongoing and current Internet scope DDoS attacks. I just had a look on that and thought that its only be able to detect some of the attacks. You might not detect large state of the art reflection and amplification attacks with that method. But i think it is useful for some sort of attacks like SYN flood. Do you agree? > > Inferring Internet Denial of Service Activity > https://cseweb.ucsd.edu/~savage/papers/UsenixSec01.pdf > > Analyzing Large DDoS Attacks Using Multiple Data Sources > https://www.cs.utah.edu/~kobus/docs/ddos.lsad.pdf > > ISP Security - Real World Techniques > https://www.nanog.org/meetings/nanog23/presentations/greene.ppt > > A Summary of DoS/DDoS Prevention, Monitoring and Mitigation Techniques in a Service Provider Environment > https://www.sans.org/reading-room/whitepapers/intrusion/summary-dos-ddos-prevention-monitoring-mitigation-techniques-service-provider-enviro-1212 > > Maybe you have access to some public IPs, then you can do this data collection yourself. Sure, I will definitely think about hat. Thanks again for your reply and for providing the links. Greetings, Martin > > Regards, > > Tyler > From nick at foobar.org Fri Apr 29 13:30:12 2016 From: nick at foobar.org (Nick Hilliard) Date: Fri, 29 Apr 2016 14:30:12 +0100 Subject: Friday's Random Comment - About: Arista and FIB/RIB's In-Reply-To: <57235C34.2030800@heliacal.net> References: <5705A3AC.5020903@tiedyenetworks.com> <4eec1f63-0e69-ac3f-78f9-b3fb5b3de0a6@seacom.mu> <22e871d1-4209-d79c-f862-b1860bb03a8b@seacom.mu> <00ea292f-e779-25ad-ce89-eae897e9516d@pubnix.net> <5723580E.9030200@foobar.org> <57235C34.2030800@heliacal.net> Message-ID: <572361E4.2060608@foobar.org> Laszlo Hanyecz wrote: > I'm curious about specific failure modes that can result from this, if > anyone can share examples/experience with it. The canonical pathological case is where the deaggregated prefixes are affected by upstream topology changes and suddenly your optimisations which saved you N% of forwarding lookup table capacity are wiped out to zero and you end up with no ability to look up next-hops. Nick From rwoolleynanog at gmail.com Fri Apr 29 16:00:02 2016 From: rwoolleynanog at gmail.com (Ryan Woolley) Date: Fri, 29 Apr 2016 12:00:02 -0400 Subject: Friday's Random Comment - About: Arista and FIB/RIB's In-Reply-To: <572361E4.2060608@foobar.org> References: <5705A3AC.5020903@tiedyenetworks.com> <4eec1f63-0e69-ac3f-78f9-b3fb5b3de0a6@seacom.mu> <22e871d1-4209-d79c-f862-b1860bb03a8b@seacom.mu> <00ea292f-e779-25ad-ce89-eae897e9516d@pubnix.net> <5723580E.9030200@foobar.org> <57235C34.2030800@heliacal.net> <572361E4.2060608@foobar.org> Message-ID: Just to be clear, this isn't (to my knowledge) something that Arista is doing and so the risk described doesn't affect the products that were discussed on that thread. On Fri, Apr 29, 2016 at 9:30 AM, Nick Hilliard wrote: > Laszlo Hanyecz wrote: > > I'm curious about specific failure modes that can result from this, if > > anyone can share examples/experience with it. > > The canonical pathological case is where the deaggregated prefixes are > affected by upstream topology changes and suddenly your optimisations > which saved you N% of forwarding lookup table capacity are wiped out to > zero and you end up with no ability to look up next-hops. > > Nick > From cscora at apnic.net Fri Apr 29 18:11:19 2016 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 30 Apr 2016 04:11:19 +1000 (AEST) Subject: Weekly Routing Table Report Message-ID: <201604291811.u3TIBJuP018287@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, SAFNOG, PaNOG, SdNOG, BJNOG, CaribNOG and the RIPE Routing WG. 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 Apr, 2016 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 593320 Prefixes after maximum aggregation (per Origin AS): 217357 Deaggregation factor: 2.73 Unique aggregates announced (without unneeded subnets): 290159 Total ASes present in the Internet Routing Table: 53574 Prefixes per ASN: 11.07 Origin-only ASes present in the Internet Routing Table: 36587 Origin ASes announcing only one prefix: 15699 Transit ASes present in the Internet Routing Table: 6432 Transit-only ASes present in the Internet Routing Table: 172 Average AS path length visible in the Internet Routing Table: 4.3 Max AS path length visible: 45 Max AS path prepend of ASN ( 40285) 42 Prefixes from unregistered ASNs in the Routing Table: 1012 Unregistered ASNs in the Routing Table: 366 Number of 32-bit ASNs allocated by the RIRs: 13668 Number of 32-bit ASNs visible in the Routing Table: 10555 Prefixes from 32-bit ASNs in the Routing Table: 41431 Number of bogon 32-bit ASNs visible in the Routing Table: 13 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 389 Number of addresses announced to Internet: 2810793284 Equivalent to 167 /8s, 137 /16s and 77 /24s Percentage of available address space announced: 75.9 Percentage of allocated address space announced: 75.9 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 98.1 Total number of prefixes smaller than registry allocations: 193746 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 151960 Total APNIC prefixes after maximum aggregation: 42211 APNIC Deaggregation factor: 3.60 Prefixes being announced from the APNIC address blocks: 162661 Unique aggregates announced from the APNIC address blocks: 66214 APNIC Region origin ASes present in the Internet Routing Table: 5164 APNIC Prefixes per ASN: 31.50 APNIC Region origin ASes announcing only one prefix: 1184 APNIC Region transit ASes present in the Internet Routing Table: 913 Average APNIC Region AS path length visible: 4.4 Max APNIC Region AS path length visible: 39 Number of APNIC region 32-bit ASNs visible in the Routing Table: 2033 Number of APNIC addresses announced to Internet: 754267460 Equivalent to 44 /8s, 245 /16s and 53 /24s Percentage of available APNIC address space announced: 88.2 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: 180907 Total ARIN prefixes after maximum aggregation: 89400 ARIN Deaggregation factor: 2.02 Prefixes being announced from the ARIN address blocks: 186041 Unique aggregates announced from the ARIN address blocks: 88502 ARIN Region origin ASes present in the Internet Routing Table: 16367 ARIN Prefixes per ASN: 11.37 ARIN Region origin ASes announcing only one prefix: 5842 ARIN Region transit ASes present in the Internet Routing Table: 1713 Average ARIN Region AS path length visible: 3.8 Max ARIN Region AS path length visible: 45 Number of ARIN region 32-bit ASNs visible in the Routing Table: 1161 Number of ARIN addresses announced to Internet: 1101677376 Equivalent to 65 /8s, 170 /16s and 67 /24s Percentage of available ARIN address space announced: 58.3 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: 143000 Total RIPE prefixes after maximum aggregation: 70238 RIPE Deaggregation factor: 2.04 Prefixes being announced from the RIPE address blocks: 152054 Unique aggregates announced from the RIPE address blocks: 93146 RIPE Region origin ASes present in the Internet Routing Table: 18078 RIPE Prefixes per ASN: 8.41 RIPE Region origin ASes announcing only one prefix: 7914 RIPE Region transit ASes present in the Internet Routing Table: 3001 Average RIPE Region AS path length visible: 4.3 Max RIPE Region AS path length visible: 29 Number of RIPE region 32-bit ASNs visible in the Routing Table: 4709 Number of RIPE addresses announced to Internet: 704653696 Equivalent to 42 /8s, 0 /16s and 41 /24s Percentage of available RIPE address space announced: 102.4 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-204287 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: 61721 Total LACNIC prefixes after maximum aggregation: 12271 LACNIC Deaggregation factor: 5.03 Prefixes being announced from the LACNIC address blocks: 76026 Unique aggregates announced from the LACNIC address blocks: 36089 LACNIC Region origin ASes present in the Internet Routing Table: 2474 LACNIC Prefixes per ASN: 30.73 LACNIC Region origin ASes announcing only one prefix: 578 LACNIC Region transit ASes present in the Internet Routing Table: 562 Average LACNIC Region AS path length visible: 4.7 Max LACNIC Region AS path length visible: 24 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 2442 Number of LACNIC addresses announced to Internet: 171320128 Equivalent to 10 /8s, 54 /16s and 35 /24s Percentage of available LACNIC address space announced: 102.1 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: 14187 Total AfriNIC prefixes after maximum aggregation: 3196 AfriNIC Deaggregation factor: 4.44 Prefixes being announced from the AfriNIC address blocks: 16149 Unique aggregates announced from the AfriNIC address blocks: 5855 AfriNIC Region origin ASes present in the Internet Routing Table: 738 AfriNIC Prefixes per ASN: 21.88 AfriNIC Region origin ASes announcing only one prefix: 181 AfriNIC Region transit ASes present in the Internet Routing Table: 170 Average AfriNIC Region AS path length visible: 4.6 Max AfriNIC Region AS path length visible: 22 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 210 Number of AfriNIC addresses announced to Internet: 78506240 Equivalent to 4 /8s, 173 /16s and 233 /24s Percentage of available AfriNIC address space announced: 78.0 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 4538 5560 4192 76 China Education and Research 7545 3297 354 214 TPG Telecom Limited 4766 3168 11160 1126 Korea Telecom 17974 2924 914 96 PT Telekomunikasi Indonesia 9829 2497 1467 462 National Internet Backbone 4755 2089 432 240 TATA Communications formerly 9808 1883 8717 30 Guangdong Mobile Communicatio 4808 1656 2299 541 CNCGROUP IP network China169 9583 1510 121 564 Sify Limited 38197 1487 92 212 Sun Network (Hong Kong) Limit 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 3309 2948 145 Cox Communications Inc. 6389 2322 3671 41 BellSouth.net Inc. 18566 2204 394 275 MegaPath Corporation 20115 1923 1937 404 Charter Communications 30036 1779 350 179 Mediacom Communications Corp 6983 1690 849 232 EarthLink, Inc. 209 1572 4666 1241 Qwest Communications Company, 4323 1567 1004 386 tw telecom holdings, inc. 701 1296 10702 704 MCI Communications Services, 7018 1278 19906 974 AT&T Services, Inc. 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 2901 151 11 SaudiNet, Saudi Telecom Compa 20940 2453 928 1789 Akamai International B.V. 34984 1968 323 417 TELLCOM ILETISIM HIZMETLERI A 8551 1630 376 55 Bezeq International-Ltd 12479 1173 979 92 France Telecom Espana SA 6849 1152 355 21 JSC "Ukrtelecom" 13188 1079 98 66 TOV "Bank-Inform" 8402 1046 544 15 OJSC "Vimpelcom" 31148 1027 47 41 Freenet Ltd. 9198 957 352 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 3469 542 147 Telmex Colombia S.A. 8151 2248 3401 577 Uninet S.A. de C.V. 7303 1515 940 237 Telecom Argentina S.A. 11830 1483 368 53 Instituto Costarricense de El 6503 1434 437 57 Axtel, S.A.B. de C.V. 3816 997 478 187 COLOMBIA TELECOMUNICACIONES S 26615 989 2325 34 Tim Celular S.A. 7738 987 1882 40 Telemar Norte Leste S.A. 11172 869 125 76 Alestra, S. de R.L. de C.V. 18881 867 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 1227 402 40 Link Egypt (Link.NET) 37611 641 48 2 Afrihost-Brevis Computer Serv 36903 616 310 110 Office National des Postes et 8452 538 1472 15 TE-AS 36992 511 1357 26 ETISALAT MISR 37492 395 234 68 Orange Tunisie 24835 328 338 15 Vodafone Data 29571 301 37 13 Cote d'Ivoire Telecom 2018 256 327 74 TENET (The UNINET Project) 36947 237 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 4538 5560 4192 76 China Education and Research 10620 3469 542 147 Telmex Colombia S.A. 22773 3309 2948 145 Cox Communications Inc. 7545 3297 354 214 TPG Telecom Limited 4766 3168 11160 1126 Korea Telecom 17974 2924 914 96 PT Telekomunikasi Indonesia 39891 2901 151 11 SaudiNet, Saudi Telecom Compa 9829 2497 1467 462 National Internet Backbone 20940 2453 928 1789 Akamai International B.V. 6389 2322 3671 41 BellSouth.net Inc. Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 10620 3469 3322 Telmex Colombia S.A. 22773 3309 3164 Cox Communications Inc. 7545 3297 3083 TPG Telecom Limited 39891 2901 2890 SaudiNet, Saudi Telecom Compa 17974 2924 2828 PT Telekomunikasi Indonesia 6389 2322 2281 BellSouth.net Inc. 4766 3168 2042 Korea Telecom 9829 2497 2035 National Internet Backbone 18566 2204 1929 MegaPath Corporation 9808 1883 1853 Guangdong Mobile Communicatio Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 65001 PRIVATE 5.143.176.0/20 15468 OJSC Rostelecom 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 16589 UNALLOCATED 8.20.247.0/24 35838 CCANET Limited 16589 UNALLOCATED 8.26.56.0/24 35838 CCANET Limited 46473 UNALLOCATED 8.27.122.0/24 3356 Level 3 Communicatio 46473 UNALLOCATED 8.27.124.0/24 3356 Level 3 Communicatio 27205 UNALLOCATED 8.38.16.0/21 3356 Level 3 Communicatio 27205 UNALLOCATED 8.38.20.0/24 32787 Prolexic Technologie Complete listing at http://thyme.rand.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 23.226.112.0/20 62788 >>UNKNOWN<< 23.249.144.0/20 40430 colo4jax, LLC 27.100.7.0/24 56096 >>UNKNOWN<< 41.73.1.0/24 37004 >>UNKNOWN<< 41.73.2.0/24 37004 >>UNKNOWN<< 41.73.3.0/24 37004 >>UNKNOWN<< 41.73.4.0/24 37004 >>UNKNOWN<< 41.73.5.0/24 37004 >>UNKNOWN<< 41.73.6.0/24 37004 >>UNKNOWN<< 41.73.7.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:13 /10:36 /11:101 /12:267 /13:509 /14:1036 /15:1767 /16:13000 /17:7613 /18:12769 /19:25947 /20:38243 /21:39996 /22:65749 /23:57212 /24:327351 /25:561 /26:593 /27:418 /28:44 /29:32 /30:14 /31:1 /32:32 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 39891 2664 2901 SaudiNet, Saudi Telecom Compa 22773 2506 3309 Cox Communications Inc. 18566 2106 2204 MegaPath Corporation 30036 1593 1779 Mediacom Communications Corp 6389 1487 2322 BellSouth.net Inc. 10620 1361 3469 Telmex Colombia S.A. 6983 1339 1690 EarthLink, Inc. 34984 1252 1968 TELLCOM ILETISIM HIZMETLERI A 11492 1172 1266 CABLE ONE, INC. 8551 1126 1630 Bezeq International-Ltd Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1575 2:747 4:21 5:2061 6:28 8:952 12:1773 13:39 14:1683 15:45 16:2 17:84 18:89 20:48 23:1521 24:1768 27:2277 31:1766 32:59 33:2 34:2 35:5 36:292 37:2262 38:1211 39:27 40:89 41:2759 42:396 43:1737 44:42 45:1807 46:2509 47:78 49:1130 50:881 51:24 52:173 54:328 55:5 56:6 57:42 58:1550 59:862 60:350 61:1811 62:1487 63:1924 64:4486 65:2146 66:4242 67:2151 68:1087 69:3249 70:1071 71:466 72:1992 74:2543 75:343 76:356 77:1377 78:1253 79:1069 80:1319 81:1371 82:929 83:695 84:820 85:1577 86:476 87:1047 88:562 89:1997 90:168 91:6100 92:887 93:2334 94:2339 95:2311 96:484 97:358 98:943 99:46 100:74 101:1051 103:10514 104:2391 105:123 106:401 107:1133 108:666 109:2325 110:1248 111:1645 112:958 113:1165 114:1047 115:1552 116:1588 117:1454 118:2058 119:1613 120:925 121:1168 122:2209 123:2012 124:1568 125:1752 128:692 129:407 130:404 131:1339 132:631 133:174 134:447 135:125 136:374 137:351 138:1718 139:259 140:540 141:471 142:642 143:911 144:665 145:156 146:857 147:686 148:1466 149:499 150:651 151:882 152:607 153:271 154:618 155:948 156:494 157:486 158:348 159:1110 160:476 161:747 162:2311 163:559 164:751 165:1048 166:312 167:1133 168:1763 169:651 170:1575 171:264 172:540 173:1709 174:734 175:730 176:1728 177:3950 178:2205 179:1143 180:2056 181:1698 182:1886 183:934 184:800 185:6331 186:3135 187:2090 188:2138 189:1741 190:7623 191:1232 192:8920 193:5724 194:4367 195:3758 196:1722 197:1057 198:5546 199:5702 200:6921 201:3679 202:10086 203:9636 204:4493 205:2708 206:2976 207:3104 208:4055 209:3812 210:3923 211:2045 212:2682 213:2221 214:852 215:71 216:5781 217:1934 218:791 219:577 220:1675 221:871 222:664 223:1213 End of report From baldur.norddahl at gmail.com Fri Apr 29 19:19:20 2016 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Fri, 29 Apr 2016 21:19:20 +0200 Subject: Friday's Random Comment - About: Arista and FIB/RIB's In-Reply-To: <572361E4.2060608@foobar.org> References: <5705A3AC.5020903@tiedyenetworks.com> <4eec1f63-0e69-ac3f-78f9-b3fb5b3de0a6@seacom.mu> <22e871d1-4209-d79c-f862-b1860bb03a8b@seacom.mu> <00ea292f-e779-25ad-ce89-eae897e9516d@pubnix.net> <5723580E.9030200@foobar.org> <57235C34.2030800@heliacal.net> <572361E4.2060608@foobar.org> Message-ID: Den 29. apr. 2016 15.31 skrev "Nick Hilliard" : > > Laszlo Hanyecz wrote: > > I'm curious about specific failure modes that can result from this, if > > anyone can share examples/experience with it. > > The canonical pathological case is where the deaggregated prefixes are > affected by upstream topology changes and suddenly your optimisations > which saved you N% of forwarding lookup table capacity are wiped out to > zero and you end up with no ability to look up next-hops. With two uplinks that is highly unlikely to the point of being impossible. There is no topology change upstream that can cause a situation where it is not possible to do a high degree of aggregation of the full default free routing table before loading it in the FIB. Regards Baldur From nick at foobar.org Fri Apr 29 20:25:14 2016 From: nick at foobar.org (Nick Hilliard) Date: Fri, 29 Apr 2016 21:25:14 +0100 Subject: Friday's Random Comment - About: Arista and FIB/RIB's In-Reply-To: References: <5705A3AC.5020903@tiedyenetworks.com> <4eec1f63-0e69-ac3f-78f9-b3fb5b3de0a6@seacom.mu> <22e871d1-4209-d79c-f862-b1860bb03a8b@seacom.mu> <00ea292f-e779-25ad-ce89-eae897e9516d@pubnix.net> <5723580E.9030200@foobar.org> <57235C34.2030800@heliacal.net> <572361E4.2060608@foobar.org> Message-ID: <5723C32A.1010008@foobar.org> Baldur Norddahl wrote: > With two uplinks that is highly unlikely to the point of being impossible. > There is no topology change upstream that can cause a situation where it is > not possible to do a high degree of aggregation of the full default free > routing table before loading it in the FIB. which is why I qualified this in a previous posting: > The more paths you receive from different sources, the more likely it > is that this list of 120k "superfluous" prefixes will converge > towards zero. Agreed that small numbers of paths are most unlikely to create the conditions for this problem to occur. Nick From saku at ytti.fi Sat Apr 30 15:12:26 2016 From: saku at ytti.fi (Saku Ytti) Date: Sat, 30 Apr 2016 08:12:26 -0700 Subject: Friday's Random Comment - About: Arista and FIB/RIB's In-Reply-To: <5723C32A.1010008@foobar.org> References: <5705A3AC.5020903@tiedyenetworks.com> <4eec1f63-0e69-ac3f-78f9-b3fb5b3de0a6@seacom.mu> <22e871d1-4209-d79c-f862-b1860bb03a8b@seacom.mu> <00ea292f-e779-25ad-ce89-eae897e9516d@pubnix.net> <5723580E.9030200@foobar.org> <57235C34.2030800@heliacal.net> <572361E4.2060608@foobar.org> <5723C32A.1010008@foobar.org> Message-ID: On 29 April 2016 at 13:25, Nick Hilliard wrote: >> The more paths you receive from different sources, the more likely it >> is that this list of 120k "superfluous" prefixes will converge >> towards zero. > > Agreed that small numbers of paths are most unlikely to create the > conditions for this problem to occur. If these compression schemes are implemented, and our compressed count is near the limit of hardware, it creates interesting new attack vector for attackers. Pump carefully crafted updated to global table and watch networks melt. I think compression makes more sense in controlled environments, but controlled environments with large scale are likely to be exact matches (i.e. bunch of host routes) not LPM anyhow. I'm not optimistic about the technology. -- ++ytti From jfmezei_nanog at vaxination.ca Sat Apr 30 16:25:52 2016 From: jfmezei_nanog at vaxination.ca (Jean-Francois Mezei) Date: Sat, 30 Apr 2016 12:25:52 -0400 Subject: Standards for last mile performance Message-ID: <5724DC90.3000109@vaxination.ca> The CRTC hearing went well (thanks for all your help). One of the unanswered questions was how to set performance standards for the last mile to ensure people get advertised speeds (within reason). I had asked the question about contention ratio and it appears there is no proper way to set such a moving target as a regulatory standard. During the hearing, someone suggested that advertised speeds be achievable 80% of the time. (chairman then asked if "time" was 24 hours, or just the time you needed to use the internet (aka: peak). Out of curiosity, could such a thing be measured by the last mile operator ? There is the easy answer of synch. For DSL, non delivery of advertised speed is easy since that metric is on the modem statistics. However, for fixed wireless, would a customer too far from tower see a lower synch rate or would he just see poor performance due to lots of retransmits ? So some generic questions: What are the different ways used to determine if the last mile is congested and needs to be upgraded ? >From the network operator's point of view, would it not be looking at 5 minute throughput samples and trigger upgrades when it sees throughput reaching x% of last mile segment capacity for more than X minutes per day ? What other means do network admins use to monitor when it is time to upgrade shared last mile segments such as coax or fixed wireless ? from a policy point of view, is it possible to set the same standard for different technologies or should each (dsl, coax, fixed wireless and satellite) have they own standards and methods of measurements before of intrinsic differences in how they work ? In the case of Rogers (canadian cableco), the CRTC record shows that they trigger node split process when capacity reaches 60%. This is because it takes them so long to do all the paperwork, committees etc that by the time the node split is done, that segment has grown to about 75% utilisation. Would that be a sound basis to set a policy ? For shared last mile, would different technologies have similar thresholds that trigger the need for upgrades or would coax start to degrade at 75% whereas fixed wireless or satellite start to degrade at lower/higher number ? For FTTP, while likely not a big problem yet, would similar number apply when the ~2gbps download and ~1gbps upload start to get filled by the 32 homes served ? From josh at kyneticwifi.com Sat Apr 30 18:36:45 2016 From: josh at kyneticwifi.com (Josh Reynolds) Date: Sat, 30 Apr 2016 13:36:45 -0500 Subject: Standards for last mile performance In-Reply-To: <5724DC90.3000109@vaxination.ca> References: <5724DC90.3000109@vaxination.ca> Message-ID: For us (FTTH) we had/have enough aggressive foresight to do smaller splits.. 1x16. Some are doing 1x2's or 1x4's at the corner somewhere into 1x16's or 1x8's, so at the point where you start to hit decent saturation you can just shrink the upstream split and fuse onto a new upstream strand / optic. Once that gets overused, thankfully you can overlay NG-PON2. As far as measuring, in our case just having your NMS of choice just monitoring the OLT via SNMP. For fixed wireless, monitoring and management are the easy part. The hard stuff is detecting what amounts to "dark matter", or the things you're not normally looking for. Channel utilization (completely variable from moment to moment), over all AP capacity, CPU usage, retransmissions, keeping per client modulation rates very high to limit tdma timeslot utilization, etc. The fixed wireless side ends up requiring a LOT of experience, monitoring, and guesswork. On Apr 30, 2016 11:28 AM, "Jean-Francois Mezei" wrote: > > The CRTC hearing went well (thanks for all your help). > > One of the unanswered questions was how to set performance standards for > the last mile to ensure people get advertised speeds (within reason). > > I had asked the question about contention ratio and it appears there is > no proper way to set such a moving target as a regulatory standard. > > During the hearing, someone suggested that advertised speeds be > achievable 80% of the time. (chairman then asked if "time" was 24 hours, > or just the time you needed to use the internet (aka: peak). > > Out of curiosity, could such a thing be measured by the last mile operator > ? > > > There is the easy answer of synch. For DSL, non delivery of advertised > speed is easy since that metric is on the modem statistics. However, for > fixed wireless, would a customer too far from tower see a lower synch > rate or would he just see poor performance due to lots of retransmits ? > > > So some generic questions: > > What are the different ways used to determine if the last mile is > congested and needs to be upgraded ? > > From the network operator's point of view, would it not be looking at 5 > minute throughput samples and trigger upgrades when it sees throughput > reaching x% of last mile segment capacity for more than X minutes per > day ? > > What other means do network admins use to monitor when it is time to > upgrade shared last mile segments such as coax or fixed wireless ? > > from a policy point of view, is it possible to set the same standard for > different technologies or should each (dsl, coax, fixed wireless and > satellite) have they own standards and methods of measurements before of > intrinsic differences in how they work ? > > > In the case of Rogers (canadian cableco), the CRTC record shows that > they trigger node split process when capacity reaches 60%. This is > because it takes them so long to do all the paperwork, committees etc > that by the time the node split is done, that segment has grown to about > 75% utilisation. > > Would that be a sound basis to set a policy ? > > For shared last mile, would different technologies have similar > thresholds that trigger the need for upgrades or would coax start to > degrade at 75% whereas fixed wireless or satellite start to degrade at > lower/higher number ? > > For FTTP, while likely not a big problem yet, would similar number apply > when the ~2gbps download and ~1gbps upload start to get filled by the 32 > homes served ? > From jheitz at cisco.com Sat Apr 30 19:10:44 2016 From: jheitz at cisco.com (Jakob Heitz (jheitz)) Date: Sat, 30 Apr 2016 19:10:44 +0000 Subject: Superfluous advertisement (was: Friday's Random Comment) Message-ID: A use case for a longer prefix with the same nexthop: F / \ D E | | B C \ / A Suppose A is a customer of B and C. B has a large address space: 10.1.0.0/16. B allocates a subset to A: 10.1.1.0/24. B advertises the longer prefix to its backup provider C. C propagates it to E and then to F. B MUST advertise both 10.1.0.0/16 and 10.1.1.0/24 to D. D MUST propagate both of them to F. Otherwise, if F only receives 10.1.0.0/16 from D, then F will have the longer match 10.1.1.0/24 to E, but E is only the backup route. Thanks, Jakob. > -----Original Message----- > Date: Fri, 29 Apr 2016 08:17:41 -0400 > From: Alain Hebert > To: "'NANOG list'" > Subject: Friday's Random Comment - About: Arista and FIB/RIB's > Message-ID: <00ea292f-e779-25ad-ce89-eae897e9516d at pubnix.net> > Content-Type: text/plain; charset=utf-8 > > While following that Arista chat... That reminded me of that little > afternoon project years ago. > > So I decided to find new hamsters, fire up that VM, refresh the DB's and > from the view point of a tiny 7206VXR/G1 with 2 T3 peers... > > The amount of superfluous subnet advertisement drop to ~120k from > ~166k from the previous snapshot. > > And this is the distribution by country. > > country | superfluous > --------------------+------------- > United States | 28254 > Brazil | 10012 > China | 7537 > India | 6449 > Russian Federation | 4524 > Korea, Republic of | 4062 > Saudi Arabia | 3297 > Australia | 2989 > Indonesia | 2878 > Hong Kong | 2251 > Thailand | 2093 > Canada | 2019 > Taiwan | 1955 > Ukraine | 1877 > Singapore | 1856 > Bulgaria | 1488 > Argentina | 1436 > Japan | 1403 > Mexico | 1351 > Chile | 1271 > > (Damn Canada, can't break top 10 again). > > PS: "Superfluous" is a nice way to say that the best path of a > subnet is the same as his supernet. And yes I'm aware of the Weekly > Routing Report, I was just curious to see it by country =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 From jheitz at cisco.com Sat Apr 30 20:05:11 2016 From: jheitz at cisco.com (Jakob Heitz (jheitz)) Date: Sat, 30 Apr 2016 20:05:11 +0000 Subject: Superfluous advertisement (was: Friday's Random Comment) In-Reply-To: <008a01d1a317$56e33080$04a99180$@gmail.com> References: <008a01d1a317$56e33080$04a99180$@gmail.com> Message-ID: <7ed30fbc28fb4c34be602e197a37c48f@XCH-ALN-014.cisco.com> Simpler, with B and C peered: F / \ B---C \ / A If B does not send the /24 to F, then F will send all the traffic to C, even if A wanted a load balance. Maybe I could ask the community: Why do you advertise longer prefixes with the same nexthop as the shoter prefix? Is it this use case, or something else? Thanks, Jakob. > -----Original Message----- > From: Russ White [mailto:7riw77 at gmail.com] > Sent: Saturday, April 30, 2016 12:35 PM > To: Jakob Heitz (jheitz) ; nanog at nanog.org > Subject: RE: Superfluous advertisement (was: Friday's Random Comment) > > > > A use case for a longer prefix with the same nexthop: > > > > F > > / \ > > D E > > | | > > B C > > \ / > > A > > > > Suppose A is a customer of B and C. > > This is possible, but only remotely probable. In the real world, D and E are > likely peered, as are B and C. Further, it's quite possible for F to choose > the path through E anyway, regardless of A's wishes, or even to load share > over to the two paths. If it's really a backup path, and you don't want > traffic on it unless the primary is completely down, then you need to not > advertise it until you actually need it. One of the various principles of > packet based routing is that if you advertise reachability, it means > someone, someplace, might just choose the path you've advertised. You can't > control what other people choose. > > :-) > > Russ From daveb at dslprime.com Fri Apr 29 02:25:45 2016 From: daveb at dslprime.com (Dave Burstein) Date: Thu, 28 Apr 2016 22:25:45 -0400 Subject: Reporter's questions Message-ID: Folks I've long lurked here and thought to ask about the story below and related. The news here is that Hurricane Electric is opening Africa pops and likely bringing down prices significantly. I made some (semi-informed) guesses about the relation of backhaul/transit to ISP costs. Anyone with date, I'd welcome it on or off list. Also, pointers to other sources of attractive pricing in the Global South welcome. I've been to several international meetings where I hear that's a huge problem. Improvements welcome. I'm always looking for news about broadband and related policy. I've just been to a major 5G conference and have been learing a great deal. Quick takeaways: Field trials coming next year at both Verizon & AT&T. Test data so far is very positive. MU MIMO should be ready for market this decade, with 10x improvement in the right places. Millimeter wave is also looking good but few expect volume before 2020-2023. Very expensive because short range of high frequencies means many, many cell sites. Short range means that those with fiber in place for backhaul have an enormous advantage. That's mostly the incumbents. I believe this will be a huge problem for competition but DC hasn't caught on yet. If any of this isn't appropriate for the list, let me know. Dave Burstein http://fastnet.news/index.php/97-fnn/368-hurricane-s-incredible-backhaul-prices-to-joburg-nairobi-could-kickstart-africa-s-internet Hurricane's Expected Incredible Backhaul Prices to Joburg & Nairobi could kickstart Africa's Internet [image: Hurricane Africa 250]Not quite as low as the $0.27/megabit price in Riga. Hurricane Electric, a major Internet backbone, is coming to Africa. Although they aren't announcing prices, I predict they will offer much less expensive backhaul/transit. Most of the continent suffers from brutally high, cartel-like prices for wholesale connections. If HE prices as I expect they will, that could easily reduce consumer Internet prices by 15% to 35%. In turn, that will allow tens of millions more to connect. In 2012 at the WCIT, a dozen Africans told me the high the cost of transit/backhaul was by far the most important international obstacle to bringing the Internet to more Africans. A friend of mine was quoted $70/megabit for a Gig-E in Lagos last year. The cost in most European or American cities would be between $0.50 and perhaps $4.00. The current high price of backhaul raises the cost of a robust broadband connection probably $10-20 over what it could be. Even a second-rate service with a low cap is probably $5 more expensive than necessary. There is a real cost involved carrying data 6,000 miles undersea but that explains only a small part of the 50-1 difference in the price between London and most of Africa. Most coastal countries are now served by more than one undersea cable. South Africa has five and Kenya three, Take a look at Steve Song's remarkable map. The Africans have been chomping at the bit to reduce the impact of the cartel, but the U.S. has been blocking that at the ITU. Hurricane offers a $2,700/month price for a 10 gigabit pipe in several dozen cities in Europe and North America, including Riga, Latvia and Rochester, Minnesota. That's on a five year contract. Three years would be somewhat higher. The Africa price will be higher but I believe will create a new market level. The cable middleman must be paid. A Gig-E can serve a thousand robust connections and easily five thousand with low caps. 10 gigs is enough for ten thousand good connections. HE keeps prices down by doing little advertising and less pr and run lean in all ways. They;ve been around since 1994, were early to IPv6 and other technical advances, and service many world-class clients. The ISP needs to carry the data from the Hurricane POP to their local networks. Fortunately, land-based fiber nets are growing rapidly. With 700M mobile subs in Africa, the market is booming. Afterfibre has a map worth looking at. Africa will have more than 315M broadband users, the population of the United States, within the next 18 months. Ericsson expects a total of 500M new broadband users in Africa between 2015 & 2020. A bit further - All cost figures here other than actual price quotes are my somewhat informed estimates based on scattered details of actual ISP internal costs I've accumulated over the years. They aren't precise. Cost accounting in a high fixed cost/low marginal cost industry is highly subjective. That's especially true here because the decision how to allocate backhaul costs between voice and data varies. Also, expect a lag between the wholesale and retail price changes. In developed countries with typically robust regional fiber, a large carrier's network cost from the peering point to the local exchange was similar to transit costs. Both seem to typically equate to 3-5 hops worth of switches/routers. So if I double transit costs, which have a competitive market, I get a usable estimate of the marginal cost of the bandwidth delivered to the local exchange. If transit costs $0.27/megabit in the local market, I believe the marginal cost of bandwidth will be well under $1. That's confirmed off the record numerous times by the carriers but very rarely discussed in public. (Because bandwidth is such a small part of broadband costs, any policy discussion that focuses on how much bandwidth a consumer takes is unsound.) However, as I testified to the U.S. Broadband Commission, rural areas and small companies often have much higher costs. ISPs and telcos under ~ 20,000 customers cannot efficiently buy backhaul in many locations. (That's when I developed some rules of thumb between transit costs and the delivered cost of broadband,) I suspect the effect is even more extreme in African rural areas or where customers are relatively few. I'd welcome any data people might have. -- Editor, Fast Net News, Net Policy News and DSL Prime Author with Jennie Bourne DSL (Wiley) and Web Video: Making It Great, Getting It Noticed (Peachpit) From pierre at userid.org Sat Apr 30 12:56:04 2016 From: pierre at userid.org (Pierre Lamy) Date: Sat, 30 Apr 2016 08:56:04 -0400 Subject: BGP FlowSpec In-Reply-To: References: Message-ID: <5724AB64.5050109@userid.org> I was looking into using this mechanism for blocking DDoS on Juniper devices, but at the time, they only supported 8k flowspec entries/routes and this was not sufficient to deal with the problem. My fallback was to poison the routing table with null routes, but the problem with this was that it didn't address inbound traffic, only the replies. We ended up ditching all of this in favor of a third party external scubbing vendor. They tend to prefer big honking boxes running signatures whereever possible to drop identified malicious traffic. When you get right down to it, the vendors have a lot of experience day-to-day performing mitigations, and flowspec (or other BGP mitigations) are more useful to carriers and ISPs to null out the destination rather than the source. Pierre On 29/04/2016 9:08 AM, dennis wrote: > > > Hi > Amplification attacks and syn floods are just touching the surface of ddos attack vectors. You should look into some industry reports: > Here are a couple examples to get you started. > https://www.radware.com/ert-report-2015/ > http://www.verizonenterprise.com/verizon-insights-lab/dbir/2016/ > > Sent via the Samsung GALAXY S? 5, an AT&T 4G LTE smartphone > > -------- Original message -------- > From: Martin Bacher > Date: 4/29/2016 2:02 AM (GMT-08:00) > To: Tyler Haske > Cc: NANOG list > Subject: Re: BGP FlowSpec > > Hello Tyler, > > thanks for your reply. > >> Am 28.04.2016 um 17:37 schrieb Tyler Haske : >> >> Martin, >> >> >>> Last but not least: I am also looking for anonymized statistical data about DDoS attacks which I could use in the thesis. I am mainly interested in data about the >>> type of attacks, attack time, sources, source and destination ports, and so on. I know this something which is generally not shared, so I would really appreciate it if >>> someone would be able to share such data. >> >> Many companies are extremely reluctant to share their attack data. But that's OK, because there are other ways to get it. >> >> Have you investigated backscatter analysis? It's used to see ongoing and current Internet scope DDoS attacks. > I just had a look on that and thought that its only be able to detect some of the attacks. You might not detect large state of the art reflection and amplification attacks with that method. But i think it is useful for some sort of attacks like SYN flood. Do you agree? > >> >> Inferring Internet Denial of Service Activity >> https://cseweb.ucsd.edu/~savage/papers/UsenixSec01.pdf >> >> Analyzing Large DDoS Attacks Using Multiple Data Sources >> https://www.cs.utah.edu/~kobus/docs/ddos.lsad.pdf >> >> ISP Security - Real World Techniques >> https://www.nanog.org/meetings/nanog23/presentations/greene.ppt >> >> A Summary of DoS/DDoS Prevention, Monitoring and Mitigation Techniques in a Service Provider Environment >> https://www.sans.org/reading-room/whitepapers/intrusion/summary-dos-ddos-prevention-monitoring-mitigation-techniques-service-provider-enviro-1212 >> >> Maybe you have access to some public IPs, then you can do this data collection yourself. > Sure, I will definitely think about hat. > > Thanks again for your reply and for providing the links. > > Greetings, > Martin > >> >> Regards, >> >> Tyler >> > > From 7riw77 at gmail.com Sat Apr 30 19:34:39 2016 From: 7riw77 at gmail.com (Russ White) Date: Sat, 30 Apr 2016 15:34:39 -0400 Subject: Superfluous advertisement (was: Friday's Random Comment) In-Reply-To: References: Message-ID: <008a01d1a317$56e33080$04a99180$@gmail.com> > A use case for a longer prefix with the same nexthop: > > F > / \ > D E > | | > B C > \ / > A > > Suppose A is a customer of B and C. This is possible, but only remotely probable. In the real world, D and E are likely peered, as are B and C. Further, it's quite possible for F to choose the path through E anyway, regardless of A's wishes, or even to load share over to the two paths. If it's really a backup path, and you don't want traffic on it unless the primary is completely down, then you need to not advertise it until you actually need it. One of the various principles of packet based routing is that if you advertise reachability, it means someone, someplace, might just choose the path you've advertised. You can't control what other people choose. :-) Russ