- Test - lists.nanog.org

Hacked DVRs again?! (Probably the wrong forum, but probably of interest nonetheless)
by Large Hadron Collider 12 Jul '17

12 Jul '17

So, I run a small chat service and it has attracted abuse from multiple kinds of open device. Most recently, I've found DVRs being spammed through. This is the kind of "default password"/"open Cisco" abuse that is very hard to detect with an open proxy scanner without, well, logging in and seeing if you get a shell. Has anyone ever seen this? What can I do to prevent it?

1 0

Some advice on IPv6 planning and ARIN request, please
by Oliver O'Boyle 12 Jul '17

12 Jul '17

Hello, If anyone out there could provide some input or advice on how to best handle our upcoming leap into IPv6, it would be much appreciated. I want to make sure we're playing nicely and not causing anyone any unnecessary grief before we deploy. We're currently in the planning stage and can make whatever changes we need to. Situation: We're an end-user org and qualify for a /40 assignment because we operate over 60 sites and some of those are/will be multihomed. We manage hotels in Canada only, but from coast to coast to coast and everywhere in between. Our corporate network and org structure is optimized for three regions. We also have, and continue to grow into, cloud infrastructure and foresee wanting to bring our own addresses (.e.g., to AWS VPC when that option becomes available). As such, an obvious design strategy would be to break the /40 into 4 x /42's. However, due to an imbalance in national site distribution, 50% of our sites are located in one region (Region A). Additionally, historical and forecasted growth indicates that it's perfectly reasonable for us to expect growth of an additional 16 sites in that same region over the next 3-5 years. We would prefer to summarize at the /42 level, announced from our last-mile providers. There are 3 primary last-mile providers so this strategy would help significantly reduce the number of global routes being injected. If we split regions evenly at /42 and if we follow the /48-per-site best practice (which I believe is justifiable in our situation - see below), Region A will be at 50% usage immediately. Adding 16 more sites brings it to 75% usage in only a few years. The other regions would be at ~33% usage (Region B) and 15% usage (Region C) and will see moderate growth in 3-5 years. Cloud will initially be at 2-4% usage (Region D) but will also grow quickly within 3-5 years. Ideal situation: ARIN assigns us a /36 and we don't need to worry about re-addressing. Even if they can offer us contiguous space with a second request to increase our assignment, we would likely need to re-address a significant portion of our sites which would be painful and time-consuming. Less ideal situation #1: Split the first level of subnets unevenly at 1 x /41 and 2 x /42 and hope we can carve out some of that space for use in our cloud infrastructure. This strategy would solve our Region A problem and would keep Regions B and C from going to 68% and 34% utilization immediately but it would mess up Region D and impact Regions B and C. Less ideal situation #2: Split the first level of subnets unevenly at 1 x /41, 1 x /42, and 2 x /43. This strategy would solve our Region A and Region B problems but would constrain Region C and Region D future growth options somewhat. Less ideal situation #3: Drop the /48 per site default to somewhere between a /49 and /53 and hope we don't bust out of those. This strategy would allow us to keep top-level aggregation at /42's but would move the site assignments off the nibble boundaries. Less ideal situation #4: Keep 4 x /42's and hope we don't expand out of them in Region A. This strategy would imply we don't wish for our business to grow and is pretty risky. I feel the /48 site default is justifiable because of the various applications and services that are currently, or could likely be offered at hotels. E.g., each room gets a /64 for all guest-internet devices registered to that room. + IoT could result in the same rule (each room gets a /64) or, perhaps a bit simpler, each class of IoT device is on a /64 or each IoT vendor is on a /64. There will also be new applications that come out with similar possible needs. With some of our hotels in the 500-1000 room range, we're looking at as many as 2000 /64's per site in the next 5 or so years. Plus backoffice/admin subnets. I think the ideal situation is out as ARIN policy wouldn't allow them to assign us a /36 at this time. Unless someone knows something that can help us here. Assuming we can't get a /36, my feeling is that less ideal situation #2 is better than #3 is better than #1 is better than #4, assuming we're following the following design best-practices: a) assign top-level aggregations evenly (which we'd be breaking a bit with option #2) b) reduce global routes as much as possible c) stay on the nibble boundary as much as possible d) default to /48 per site Any thoughts or advice would be much appreciated. Thanks in advance, Oliver

14 21

Re: loc.gov
by Joly MacFie 10 Jul '17

10 Jul '17

I also noticed an outages-announce - is that for people who don't sub to the other two, or should one do all 3 to be fully notified? j On Sun, Jul 9, 2017 at 10:28 PM, Damian Menscher via NANOG <nanog(a)nanog.org> wrote: > There are two lists, depending on whether you're reporting an ongoing > outage, or just talking about one: > > https://puck.nether.net/mailman/listinfo/outages > https://puck.nether.net/mailman/listinfo/outages-discussion > > Damian > > On Sat, Jul 8, 2017 at 6:41 PM, Nicholas Oas <nicholas.oas(a)gmail.com> > wrote: > > > I'd be interested to know the answer to this one as well, as I've gone > > looking for the outages list in the past and found the same result. > > > > Have isitdownorjustme sites simply superceded the need for such lists? > > > > On Jul 8, 2017 6:59 PM, "Joly MacFie" <joly(a)punkcast.com> wrote: > > > > > Actually, now I go to https://www.nanog.org/list/faq/other > > > > > > I don't see any such thing, just http://www.outages.org/ where the > > latest > > > report is 2013. > > > > > > Also "See *http://www.isp-lists.com/* <http://www.isp-lists.com/> for > > many > > > other topic-specific lists." takes one somewhere else entirely! > > > > > > j > > > > > > > > > > > > On Sat, Jul 8, 2017 at 6:47 PM, Doug Barton <dougb(a)dougbarton.us> > wrote: > > > > > > > Isn't that a problem that suggests its own solution? > > > > > > > > > > > > > > > > On 7/8/2017 1:43 PM, Joly MacFie wrote: > > > > > > > >> (sorry I'm not on the outage list) > > > >> > > > >> -- > > > >> --------------------------------------------------------------- > > > >> Joly MacFie 218 565 9365 Skype:punkcast > > > >> -------------------------------------------------------------- > > > >> - > > > >> > > > > > > > > > > -- --------------------------------------------------------------- Joly MacFie 218 565 9365 Skype:punkcast -------------------------------------------------------------- -

2 1

loc.gov
by Joly MacFie 09 Jul '17

09 Jul '17

(sorry I'm not on the outage list) Any clues as to what the problem is at the Library of Congress? Appears to be DNS. Is it a DDOS? http://www.loc.gov/ -- --------------------------------------------------------------- Joly MacFie 218 565 9365 Skype:punkcast -------------------------------------------------------------- -

12 14

Weekly Routing Table Report
by cscora＠apnic.net 07 Jul '17

07 Jul '17

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, MENOG, SAFNOG, SdNOG, BJNOG, CaribNOG and the RIPE Routing WG. Daily listings are sent to bgp-stats(a)lists.apnic.net For historical data, please see http://thyme.rand.apnic.net. If you have any comments please contact Philip Smith <pfsinoz(a)gmail.com>. Routing Table Report 04:00 +10GMT Sat 08 Jul, 2017 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 653872 Prefixes after maximum aggregation (per Origin AS): 254333 Deaggregation factor: 2.57 Unique aggregates announced (without unneeded subnets): 315298 Total ASes present in the Internet Routing Table: 57740 Prefixes per ASN: 11.32 Origin-only ASes present in the Internet Routing Table: 49962 Origin ASes announcing only one prefix: 22072 Transit ASes present in the Internet Routing Table: 7778 Transit-only ASes present in the Internet Routing Table: 223 Average AS path length visible in the Internet Routing Table: 4.3 Max AS path length visible: 54 Max AS path prepend of ASN ( 55644) 51 Prefixes from unregistered ASNs in the Routing Table: 60 Numnber of instances of unregistered ASNs: 64 Number of 32-bit ASNs allocated by the RIRs: 19359 Number of 32-bit ASNs visible in the Routing Table: 15061 Prefixes from 32-bit ASNs in the Routing Table: 61319 Number of bogon 32-bit ASNs visible in the Routing Table: 64 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 349 Number of addresses announced to Internet: 2848140388 Equivalent to 169 /8s, 195 /16s and 44 /24s Percentage of available address space announced: 76.9 Percentage of allocated address space announced: 76.9 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 98.7 Total number of prefixes smaller than registry allocations: 217691 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 179377 Total APNIC prefixes after maximum aggregation: 51366 APNIC Deaggregation factor: 3.49 Prefixes being announced from the APNIC address blocks: 178434 Unique aggregates announced from the APNIC address blocks: 73877 APNIC Region origin ASes present in the Internet Routing Table: 8227 APNIC Prefixes per ASN: 21.69 APNIC Region origin ASes announcing only one prefix: 2309 APNIC Region transit ASes present in the Internet Routing Table: 1163 Average APNIC Region AS path length visible: 4.4 Max APNIC Region AS path length visible: 54 Number of APNIC region 32-bit ASNs visible in the Routing Table: 3071 Number of APNIC addresses announced to Internet: 763514212 Equivalent to 45 /8s, 130 /16s and 77 /24s 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, 64297-64395, 131072-137529 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: 199057 Total ARIN prefixes after maximum aggregation: 94804 ARIN Deaggregation factor: 2.10 Prefixes being announced from the ARIN address blocks: 201014 Unique aggregates announced from the ARIN address blocks: 92372 ARIN Region origin ASes present in the Internet Routing Table: 17915 ARIN Prefixes per ASN: 11.22 ARIN Region origin ASes announcing only one prefix: 6631 ARIN Region transit ASes present in the Internet Routing Table: 1765 Average ARIN Region AS path length visible: 3.8 Max ARIN Region AS path length visible: 23 Number of ARIN region 32-bit ASNs visible in the Routing Table: 2073 Number of ARIN addresses announced to Internet: 1108484768 Equivalent to 66 /8s, 18 /16s and 34 /24s 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-397212 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: 175353 Total RIPE prefixes after maximum aggregation: 85837 RIPE Deaggregation factor: 2.04 Prefixes being announced from the RIPE address blocks: 171163 Unique aggregates announced from the RIPE address blocks: 102995 RIPE Region origin ASes present in the Internet Routing Table: 24179 RIPE Prefixes per ASN: 7.08 RIPE Region origin ASes announcing only one prefix: 11138 RIPE Region transit ASes present in the Internet Routing Table: 3406 Average RIPE Region AS path length visible: 4.3 Max RIPE Region AS path length visible: 33 Number of RIPE region 32-bit ASNs visible in the Routing Table: 5978 Number of RIPE addresses announced to Internet: 712318592 Equivalent to 42 /8s, 117 /16s and 30 /24s 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, 64396-64495 196608-207259 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: 83011 Total LACNIC prefixes after maximum aggregation: 18472 LACNIC Deaggregation factor: 4.49 Prefixes being announced from the LACNIC address blocks: 84275 Unique aggregates announced from the LACNIC address blocks: 38801 LACNIC Region origin ASes present in the Internet Routing Table: 6112 LACNIC Prefixes per ASN: 13.79 LACNIC Region origin ASes announcing only one prefix: 1664 LACNIC Region transit ASes present in the Internet Routing Table: 1140 Average LACNIC Region AS path length visible: 5.4 Max LACNIC Region AS path length visible: 27 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 3620 Number of LACNIC addresses announced to Internet: 170696160 Equivalent to 10 /8s, 44 /16s and 157 /24s LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 61440-61951, 64099-64197, 262144-266652 + 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: 16966 Total AfriNIC prefixes after maximum aggregation: 3800 AfriNIC Deaggregation factor: 4.46 Prefixes being announced from the AfriNIC address blocks: 18637 Unique aggregates announced from the AfriNIC address blocks: 6939 AfriNIC Region origin ASes present in the Internet Routing Table: 1052 AfriNIC Prefixes per ASN: 17.72 AfriNIC Region origin ASes announcing only one prefix: 329 AfriNIC Region transit ASes present in the Internet Routing Table: 208 Average AfriNIC Region AS path length visible: 4.9 Max AfriNIC Region AS path length visible: 28 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 319 Number of AfriNIC addresses announced to Internet: 92717568 Equivalent to 5 /8s, 134 /16s and 194 /24s 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 5550 4190 74 ERX-CERNET-BKB China Education and Rese 7545 3982 406 383 TPG-INTERNET-AP TPG Telecom Limited, AU 17974 2976 902 73 TELKOMNET-AS2-AP PT Telekomunikasi Indo 4766 2809 11134 754 KIXS-AS-KR Korea Telecom, KR 9829 2744 1499 540 BSNL-NIB National Internet Backbone, IN 9808 2167 8699 32 CMNET-GD Guangdong Mobile Communication 4755 2089 422 222 TATACOMM-AS TATA Communications formerl 45899 2053 1424 111 VNPT-AS-VN VNPT Corp, VN 7552 1639 1104 73 VIETEL-AS-AP Viettel Corporation, VN 9498 1598 361 141 BBIL-AP BHARTI Airtel Ltd., IN 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 3817 2953 160 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 6327 3423 1333 83 SHAW - Shaw Communications Inc., CA 18566 2179 405 109 MEGAPATH5-US - MegaPath Corporation, US 6389 2064 3671 39 BELLSOUTH-NET-BLK - BellSouth.net Inc., 20115 2011 2172 418 CHARTER-NET-HKY-NC - Charter Communicat 209 1825 5067 640 CENTURYLINK-US-LEGACY-QWEST - Qwest Com 16509 1823 3697 591 AMAZON-02 - Amazon.com, Inc., US 30036 1805 326 297 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom 6983 1695 854 231 ITCDELTA - Earthlink, Inc., US 701 1561 10559 630 UUNET - MCI Communications Services, In 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 3388 190 24 ALJAWWALSTC-AS, SA 8551 2974 377 40 BEZEQ-INTERNATIONAL-AS Bezeqint Interne 20940 2908 962 2093 AKAMAI-ASN1, US 34984 2015 329 410 TELLCOM-AS, TR 9121 1930 1691 17 TTNET, TR 12479 1605 1044 53 UNI2-AS, ES 13188 1603 100 55 TRIOLAN, UA 12389 1521 1408 626 ROSTELECOM-AS, RU 6849 1225 355 21 UKRTELNET, UA 8402 1093 544 15 CORBINA-AS OJSC "Vimpelcom", RU 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 3532 543 205 Telmex Colombia S.A., CO 8151 2472 3404 572 Uninet S.A. de C.V., MX 11830 2090 369 57 Instituto Costarricense de Electricidad 7303 1552 1012 243 Telecom Argentina S.A., AR 6503 1538 437 53 Axtel, S.A.B. de C.V., MX 6147 1296 377 27 Telefonica del Peru S.A.A., PE 3816 1026 501 94 COLOMBIA TELECOMUNICACIONES S.A. ESP, C 28573 968 2301 177 CLARO S.A., BR 11172 915 126 82 Alestra, S. de R.L. de C.V., MX 18881 896 1052 23 TELEFÔNICA BRASIL S.A, BR 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 1237 398 51 LINKdotNET-AS, EG 37611 724 91 8 Afrihost, ZA 36903 711 357 129 MT-MPLS, MA 36992 644 1375 26 ETISALAT-MISR, EG 24835 478 786 17 RAYA-AS, EG 37492 407 320 75 ORANGE-, TN 29571 401 36 10 CITelecom-AS, CI 15399 348 35 7 WANANCHI-, KE 8452 327 1730 17 TE-AS TE-AS, EG 2018 304 327 74 TENET-1, ZA 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 5550 4190 74 ERX-CERNET-BKB China Education and Rese 7545 3982 406 383 TPG-INTERNET-AP TPG Telecom Limited, AU 22773 3817 2953 160 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 10620 3532 543 205 Telmex Colombia S.A., CO 6327 3423 1333 83 SHAW - Shaw Communications Inc., CA 39891 3388 190 24 ALJAWWALSTC-AS, SA 17974 2976 902 73 TELKOMNET-AS2-AP PT Telekomunikasi Indo 8551 2974 377 40 BEZEQ-INTERNATIONAL-AS Bezeqint Interne 20940 2908 962 2093 AKAMAI-ASN1, US 4766 2809 11134 754 KIXS-AS-KR Korea Telecom, KR Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 22773 3817 3657 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 7545 3982 3599 TPG-INTERNET-AP TPG Telecom Limited, AU 39891 3388 3364 ALJAWWALSTC-AS, SA 6327 3423 3340 SHAW - Shaw Communications Inc., CA 10620 3532 3327 Telmex Colombia S.A., CO 8551 2974 2934 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo 17974 2976 2903 TELKOMNET-AS2-AP PT Telekomunikasi Indonesia, I 9829 2744 2204 BSNL-NIB National Internet Backbone, IN 9808 2167 2135 CMNET-GD Guangdong Mobile Communication Co.Ltd. 18566 2179 2070 MEGAPATH5-US - MegaPath Corporation, US Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 65602 UNALLOCATED 8.225.192.0/24 30372 SUNESYS2 - Sunesys, LLC, US 64525 PRIVATE 45.119.143.0/24 133275 GIGANTIC-AS Gigantic Infotel P 64525 PRIVATE 45.125.62.0/24 133275 GIGANTIC-AS Gigantic Infotel P 65001 PRIVATE 46.237.40.0/21 13118 ASN-YARTELECOM PJSC Rostelecom 65534 PRIVATE 58.68.109.0/24 10201 DWL-AS-IN Dishnet Wireless Lim 64513 PRIVATE 62.150.101.0/24 9155 QNET Kuwait, KW 65538 DOCUMENT 64.27.253.0/24 1273 CW Vodafone Group PLC, GB 65346 PRIVATE 94.50.36.0/22 31094 TTKNET Tyumen, Russia, RU 64111 UNALLOCATED 98.159.5.0/24 19555 KMI-NETWORK - Kinder Morgan, I 64111 UNALLOCATED 98.159.7.0/24 19555 KMI-NETWORK - Kinder Morgan, I Complete listing at http://thyme.rand.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 14.192.48.0/24 134833 LIHGL-HK LANLIAN INTERNATIONAL HOLDING GROUP LIMITE 14.192.49.0/24 134833 LIHGL-HK LANLIAN INTERNATIONAL HOLDING GROUP LIMITE 14.192.50.0/24 134833 LIHGL-HK LANLIAN INTERNATIONAL HOLDING GROUP LIMITE 14.192.51.0/24 134833 LIHGL-HK LANLIAN INTERNATIONAL HOLDING GROUP LIMITE 27.100.7.0/24 56096 UNKNOWN 36.255.250.0/24 64091 UNKNOWN 41.76.232.0/21 62878 XLITT - Xlitt, US 41.77.248.0/21 62878 XLITT - Xlitt, US 41.78.12.0/23 62878 XLITT - Xlitt, US 41.78.180.0/23 37265 -Reserved AS-, ZZ 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:15 /9:13 /10:36 /11:104 /12:280 /13:545 /14:1047 /15:1847 /16:13467 /17:7640 /18:13422 /19:24664 /20:38616 /21:41255 /22:77663 /23:64411 /24:366633 /25:864 /26:607 /27:642 /28:34 /29:22 /30:17 /31:2 /32:26 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 6327 3224 3423 SHAW - Shaw Communications Inc., CA 22773 2979 3817 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 39891 2946 3388 ALJAWWALSTC-AS, SA 8551 2439 2974 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo 18566 2072 2179 MEGAPATH5-US - MegaPath Corporation, US 30036 1595 1805 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom Communi 11830 1480 2090 Instituto Costarricense de Electricidad y Telec 10620 1469 3532 Telmex Colombia S.A., CO 11492 1390 1541 CABLEONE - CABLE ONE, INC., US 6389 1371 2064 BELLSOUTH-NET-BLK - BellSouth.net Inc., US Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1603 2:803 4:18 5:2435 6:34 8:1045 12:1833 13:123 14:1737 15:28 16:2 17:159 18:90 20:61 23:2395 24:1881 25:2 27:2459 31:1928 32:84 33:13 35:21 36:386 37:2349 38:1313 39:64 40:98 41:2947 42:472 43:1943 44:73 45:2892 46:2802 47:157 49:1239 50:987 51:19 52:833 54:364 55:6 56:4 57:42 58:1573 59:1053 60:388 61:1959 62:1601 63:1914 64:4602 65:2223 66:4547 67:2262 68:1238 69:3373 70:1150 71:586 72:2224 74:2684 75:388 76:426 77:1536 78:1436 79:2387 80:1401 81:1385 82:1002 83:723 84:932 85:1745 86:482 87:1165 88:754 89:2114 90:175 91:6199 92:977 93:2368 94:2383 95:2699 96:625 97:353 98:1062 99:86 100:154 101:1193 103:15324 104:2983 105:178 106:510 107:1719 108:823 109:2874 110:1453 111:1730 112:1198 113:1254 114:1036 115:1723 116:1792 117:1710 118:2198 119:1611 120:1055 121:1113 122:2259 123:1815 124:1482 125:1902 128:782 129:662 130:434 131:1428 132:526 133:199 134:659 135:223 136:448 137:435 138:1953 139:490 140:398 141:606 142:767 143:900 144:792 145:179 146:1046 147:694 148:1459 149:583 150:711 151:973 152:695 153:304 154:767 155:759 156:613 157:655 158:462 159:1522 160:694 161:740 162:2520 163:530 164:806 165:1396 166:380 167:1253 168:2988 169:821 170:3419 171:319 172:1022 173:1951 174:811 175:748 176:1870 177:4135 178:2529 179:1162 180:2203 181:1903 182:2361 183:996 184:862 185:10052 186:3254 187:2195 188:2602 189:1794 190:8296 191:1365 192:9506 193:5772 194:4684 195:3923 196:2081 197:1267 198:5503 199:5897 200:7430 201:4335 202:10333 203:9996 204:4479 205:2807 206:3014 207:3136 208:3972 209:3989 210:4015 211:2145 212:2844 213:2512 214:869 215:66 216:5800 217:2113 218:864 219:599 220:1694 221:932 222:762 223:1180 End of report

1 0

Heads-up: RFC 8212 on default EBGP route handling behavior
by Job Snijders 06 Jul '17

06 Jul '17

Dear NANOG, After a bit of tug-of-war common sense prevailed and RFC 8212 "External BGP (EBGP) Route Propagation Behavior without Policies" was published: https://tools.ietf.org/html/rfc8212 This industry has a long history of improving default behavior: DEC MOP is no longer enabled by default, telnet was swapped out in favor of SSH, and SHA-1 is now deprecated, so I'm confident we can manage this one too. TL;DR This mail offers advice on test scenarios to add to your evaluation checklist and a call to action to ask your vendor to implement RFC 8212. Please share this message with other communities. Background ---------- Prior to RFC 8212, the default behavior of BGP implementations (when no policy is configured on an EBGP session) was undefined, this resulted in a myriad of vendor defaults: some implementations not accepting routes and not advertising anything; some would accept anything, but announce nothing; some would announce only internal routes and accept anything; and some would indiscriminately accept everything and announce everything. The latter mode of operation is of course the most harmful one. An example minimal configuration: ! router bgp 15562 neighbor 192.0.2.1 remote-as 174 neighbor 192.0.2.5 remote-as 2914 ! Most of us have learned (the hard way) that on many platforms the above configuration will not only bring up two BGP sessions, but also immediately result in a "Lateral ISP-ISP-ISP Leak" [2], simply because no routing policy was associated with these EBGP sessions and an implicit 'permit-any' is assumed. The above configuration is of course an oversimplification of what happens in real life: operators may attempt to change a BGP peer to a peer-group which has missing configuration, or a copy+paste of a snippet of configuration only partially succeeds, or in an attempt to debug a BGP session some configuration is removed without realizing the full ramifications of doing so (until you see smoke coming off the circuit ;-). RFC 8212 updates the core BGP specification (RFC 4271) to specify that the above behavior is _incorrect_, and an implicit deny-all must be associated with the EBGP session. In other words: "fail closed" rather then "fail open and oops you tripped max-prefix all over the place (or worse [3])". The document purposefully does not cover IBGP, nor does it proscribe what the contents of configured policy on EBGP sessions should be. If an operator explicitly configures a 'permit-any' style policy, that is perfectly fine, it was a conscious choice to do so. Evaluation checklist -------------------- Going forward when you evaluate a BGP implementation or a new software release, it is advisable to take note of the default behavior of that specific release. As vendors come into compliance with RFC 8212 it may be beneficial to track this. I also strongly recommend to audit your network configurations for instances which depend on implicit 'permit-any' behavior and reconfigure those instances to be an explicit 'permit-any'. This way software upgrades are less likely to cause surprises, and as a bonus the readability of the device's configuration is improved! Call to action -------------- Some vendors will need encouragement to take their implementation from EBGP "fail open" to "fail closed", we are keeping track of the industry's current state of affairs here: https://github.com/bgp/RFC8212 Please contact your account management team and express your interest in them supporting RFC 8212. Also, make sure to include RFC 8212 in your next round of "Request for Proposals" (RFPs) as a 'must have'. Purchasing usually is an excellent opportunity to have meaningful dialogue with the vendor. Some vendors may argue "but our customers depend on our unsafe behavior!", but this only holds true if we don't speak up collectively and show them otherwise. EBGP is an internet-wide shared resource, we all benefit from sane defaults. Hat tip to Jared Mauch for initiating this project and to Greg Hankins for demonstrating change is possible [4]. Kind regards, Job [1]: https://mailarchive.ietf.org/arch/msg/idr/mqPltvvgEhpxBgAXET1y1Xow6t8 [2]: https://tools.ietf.org/html/rfc7908#section-3.2 [3]: https://bgpmon.net/massive-route-leak-cause-internet-slowdown/ [4]: https://mailarchive.ietf.org/arch/msg/idr/kgl6etbjUuR3jLHVeDSi4LLIs50

1 0

Re: EdgeRouter Infinity as medium-sized "IXP Peering Router"?
by Josh Reynolds 06 Jul '17

06 Jul '17

- Josh On Jul 3, 2017 7:23 PM, "Josh Reynolds" <josh(a)kyneticwifi.com> wrote: > Specs... > > > - MIPS64 16 Core 1.8 GHz > - 16 GB DDR4 RAM > - 8 MB NOR Flash 4 GB eMMC NAND Flash > - Data Ports: (1) RJ45 Serial Port, (8) SFP+ Ports (1) RJ45 Gigabit > Ethernet Port > - 2 hotswap power supplies > > > No LACP. ECMP is currently broken. MPLS/VPLS is currently broken and not > done in hardware - this may eventually change. As far as the other stuff, > "telemetry" etc - no. > > As far as BGP crunching, plenty of routes, etc - it would easily and > happily be fine with that. > > As far as automation, it's a JunOS-like CLI originally based on vyatta, > which AT&T now owns - and one of the main reasons is it's scriptability, > use of Ansible and other tools right on the device, python, etc. > > - Josh > > On Jul 3, 2017 2:09 PM, "Job Snijders" <job(a)instituut.net> wrote: > >> Dear NANOG, >> >> Some friends of mine are operating a nonprofit (on shoe string) and >> looking >> to connect some CDN caches to an IX fabric. A BGP speaking device is >> needed >> between the caches and the BGP peers connected to the fabric. The BGP >> speaker is needed to present the peers on the IX with a unified view of >> the >> assemblage of CDN nodes. >> >> I was wondering whether anyone was experience with the "EdgeRouter >> Infinity >> XG" device, specifically in the role of a simple peering router for a >> couple of tens of thousands of routes. (I'd point default to the left and >> take just the on-net routes on the right to reduce the table size >> requirement). >> >> I hope the device can do at least 2xLACP trunks, has a sizable FIB, is >> automatable (supports idempotency), can forward IMIX at line-rate, *flow, >> and exposes some telemetry via SNMP. >> >> Any note sharing would be appreciated! >> >> Kind regards, >> >> Job >> >

4 5

Sign onto EFF's comment to the FCC on their net neutrality proposal
by Erica Portnoy 05 Jul '17

05 Jul '17

Dear colleagues, As many of you know, the FCC is currently engaging in the process of repealing its network neutrality rules and eliminating its Title II authority over broadband providers. I'm writing you today to ask you to sign on to a letter that EFF has prepared for filing, which explains several key engineering concepts that are vital to understanding how the Internet actually operates given that the FCC's own findings misinterpret how the Internet works. The letter stays away from legal arguments, and instead focuses on technical statements on the design and operation of the Internet. It is meant to establish a factual record for the FCC about the Internet and it is necessary because its initial findings in its Notice of Proposed Rulemaking <https://apps.fcc.gov/edocs_public/attachmatch/DOC-344614A1.pdf> are just wrong. For one, the FCC thinks that broadband Internet providers are the ones providing end users with the services of the entire Internet, from search engines to online newspapers to language translation tools. /*If you're willing to sign on and help, please email engineers-nn-comments(a)eff.org (off-list) by Friday, July 14 */and I will be happy to share a copy of the letter for you to review before you agree to sign on. The more signatures we can get, the more likely the FCC is to take notice as well as the courts should they move forward. All it takes is an email. Please help us make sure the FCC gets the facts from an engineer's standpoint. Thank you for your support, Erica Portnoy Staff Technologist Electronic Frontier Foundation

1 0

Armstrong Cable Services/AS27364 networking contact needed
by Darrin Veit 05 Jul '17

05 Jul '17

I'm hoping to find a networking contact at Armstrong that can ping me off list. We're investigating connectivity issues for some Armstrong customers when they are trying to connect to servers in AS8075. Thanks! -Darrin Veit, Xbox Platform Networking dveit(a)microsoft.com

1 0

Big Spam Burst
by Jay R. Ashworth 05 Jul '17

05 Jul '17

Am I the only person who got a big burst of spam -- 30 or 40 in about 5 minutes -- on Sunday night, from France? All forged with NANOG participant From names? I'm pretty sure Steve Bellovin and Rob Seastrom aren't sending me spam. :-) Cheers, -- jra -- Jay R. Ashworth Baylink jra(a)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

1 0