- Test - lists.nanog.org

Linode and/or Google Fiber contacts?
by Chris Adams 02 Dec '21

02 Dec '21

Anybody here from Linode and/or Google Fiber that can help out with packet loss between these networks at NYIIX peering? It's been going on for almost a week... opened a Linode case and they looked at the VM host, also opened a Google Fiber case and got zero response (don't think front-line support on either side is really getting it). I can MTR in each direction and the path appears symmetric, through NYIIX peering IPs (on both v4 and v6), and each sees packet loss at the first hop into the other network. I'm guessing one side or the other is having errors or has a congested port, but the regular support channels aren't getting this to the right people. Off-list contact is fine. -- Chris Adams <cma(a)cmadams.net>

1 1

Upcoming Webinar + More - VIDEO | New Ep. of Internet Innovators
by Nanog News 02 Dec '21

02 Dec '21

*Upcoming Webinar: Mark the Date * *Register TODAY for Network Automation Panel Discussion! * *Date + Time: *December 10, 11am - 12pm PDT / 2pm - 3pm EDT *Agenda: * Purpose of Network Automation Panel Discussion: Advantages/Challenges of Network Automation How to Prepare for a Career in Network Automation *Moderator:* Kat Ronay, Network Acquisition Specialist, Microsoft *Panelists:* Michael Costello, Director of Engineering, Netflix Ying Zhang, Senior Engineering Manager, Facebook Matt Turner Network Manager, Qualcomm, Inc. Zoe Blevins, Senior Software Engineer, Netflix *REGISTER NOW <https://www.nanog.org/events/webinar-network-automation-panel-discussion/>* *Watch Ep.3 of "Internet Innovators" * *Internet Pioneer Scott Bradner joins NANOG for a candid conversation* Internet Pioneer Scott Bradner has been involved in the design, operation, and use of data networks at Harvard University since the early days of the ARPANET. He is additionally a senior figure in the area of Internet governance. Join us for an open conversation as NANOG producer Elizabeth Drolet talks to Bradner about his own historic evolution with the Internet, what he thinks "the real power of the Internet" is + why he thinks the Internet cannot continue to exist in it's current state. *WATCH NOW <https://www.nanog.org/news-stories/nanog-tv/internet-innovators/scott-bradn…>* *Ready for NANOG 84? * We can't be more excited about our next in-person + virtual meeting, NANOG 84! The meeting will take place February 14-16 in Austin, Texas. Mark your calendars now + stay tuned for details regarding registration and presentation submissions! *"Notes from NANOG 83" * *Internet Pioneer Geoff Huston Recaps our Last Meeting* Digital pioneer + chief scientist at APNIC Geoff Huston was a virtual attendee at our most recent hybrid NANOG 83 meeting. In typical Huston manner (and lucky for us) he had much to say about it. Here are notes from talks that sparked Huston’s interest, pulled from his blog post, “Notes from NANOG 83.” Feel free to compare your own notes or soak up some new perspective. *READ MORE * <https://www.nanog.org/stories/top-takeaways-from-nanog-83-by-geoff-huston/>

1 0

IMPORTANT - Fwd: [arin-announce] Retirement of ARIN Non-Authenticated IRR on 31 March 2022
by John Curran 01 Dec '21

01 Dec '21

Network Operators - Please read and take note that ARIN’s Non-Authenticated IRR service will be retired on 31 March 2022. FYI, /John John Curran President and CEO American Registry for Internet Numbers Begin forwarded message: From: ARIN <info(a)arin.net<mailto:info@arin.net>> Subject: [arin-announce] Retirement of ARIN Non-Authenticated IRR on 31 March 2022 Date: 1 December 2021 at 8:32:30 AM EST To: arin-announce <arin-announce(a)arin.net<mailto:arin-announce@arin.net>> ARIN has been engaged in a multi-year project to create and deploy a new and improved Internet Routing Registry (IRR). As a result of these efforts, ARIN now provides users with the ability to create, update, and delete objects in ARIN’s authenticated IRR database using ARIN Online or ARIN’s RESTful API. Unfortunately, use of ARIN’s previous non-authenticated email-based IRR service actually increased after ARIN released its authenticated IRR, in opposition to the outcome ARIN anticipated when improving its IRR. On 8 February 2021, ARIN held a consultation to solicit input on the retirement of ARIN’s non-authenticated email-based IRR service. This retirement was originally scheduled for 30 September 2021. Based on community input, the proposed date for the ARIN-NONAUTH retirement was delayed to 31 March 2022 to allow more transition time for users. We also notified by email Points of Contact (POCs) of organizations who have objects in the ARIN-NONAUTH database of the retirement date and offered them our assistance with the transition. This announcement serves as a reminder that ARIN will retire its ARIN-NONAUTH IRR database on 31 March 2022. After this date, users will no longer be able to create, update, or delete records in the ARIN-NONAUTH database, and the ARIN-NONAUTH data stream will no longer be available in Near Real Time Mirroring (NRTM) or via FTP or Whois Port 43. If you have questions about this transition or need assistance, you can contact us by: - submitting an Ask ARIN ticket or chat with us using your ARIN Online account - emailing the Routing Security Team at mailto:routing.security@arin.net - contacting the Registration Services Help Desk by phone Monday through Friday, 7:00 AM to 7:00 PM ET at +1.703.227.0660 Regards, Brad Gorman Senior Product Owner, Routing Security 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(a)arin.net<mailto:ARIN-announce@arin.net>). Unsubscribe or manage your mailing list subscription at: https://lists.arin.net/mailman/listinfo/arin-announce Please contact info(a)arin.net if you experience any issues.

1 0

Theorical question about cyclic dependency in IRR filtering
by Anurag Bhatia 30 Nov '21

30 Nov '21

Hello everyone, While discussing IRR on some groups recently, I was thinking if there can be (and if there is) cycling dependency in filtering where IRR (run by whoever APNIC, RIPE, RADB etc) uses some upstream and accepts only routes with existing & valid route object. So hypothetical case (can apply to any IRR): 1. APNIC registry source is whois.apnic.net and points to 202.12.28.136 / 2001:dc0:1:0:4777::136. The aggregate of both these has a valid route object at the APNIC registry itself. 2. Their upstreams say AS X, Y and Z have tooling in place to generate and push filters by checking all popular IRRs. All is well till this point. 3. Say APNIC has some server/service issue for a few mins and X Y and Z are updating their filters at the same time. They cannot contact whois.apnic.net and hence miss generating filters for all APNIC IRR hosted prefixes. 4. X, Y and Z drop APNIC prefixes including those of IRR & the loop goes on from this point onwards. So my question is: Can that actually happen? If not, do X, Y and Z and possible all upstreams till default-free zone treat these prefixes in a special manner to avoid such loop in resolution? Thanks! -- Anurag Bhatia anuragbhatia.com

5 5

Redploying most of 127/8 as unicast public
by Jay R. Ashworth 29 Nov '21

29 Nov '21

This seems like a really bad idea to me; am I really the only one who noticed? https://www.ietf.org/id/draft-schoen-intarea-unicast-127-00.html That's over a week old and I don't see 3000 comments on it, so maybe it's just me. So many things are just me. [ Hat tip to Lauren Weinstein, whom I stole it from ] Cheers, -- jra -- Jay R. Ashworth Baylink jra(a)baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274

48 145

IPv6 and CDN's
by Marco Davids 29 Nov '21

29 Nov '21

Hi! We currently live in times where is actually fun to go IPv6-only. In my case, as in: running a FreeBSD kernel compiled without the IPv4-stack. A few years back doing such thing was mostly disappointing, but nowadays is actually quite doable and entertaining. So, the other day I decided to take this experiment to the next level by disconnecting my local resolver from IPv4 as well. Then things started to break. LinkedIn, Bing, Openstreetmap... Although they all work great on IPv6-only, now they no longer did. It turns out that there underlying CDN's with domain names such as ‘l-msedge.net’ and ‘trafficmanager.net’ (Microsoft) or 'fastly.net', that reside on authoritative name servers that *only* have an IPv4 address. I guess my question is simple: Why? Are there good architectural reason for this? Or is it just something that is overlooked and forgotten about? I would love to find out! Thank you. -- Marco This is also fun by the way. Look at that nice banner on https://clintonwhitehouse2.archives.gov/ :-)

40 129

Re: Redeploying most of 127/8, 0/8, 240/4 and *.0 as unicast
by John Gilmore 27 Nov '21

27 Nov '21

Steven Bakker <steven.bakker(a)ams-ix.net> wrote: > The ask is to update every ip stack in the world (including validation, > equipment retirement, reconfiguration, etc)... This raises a great question. Is it even *doable*? What's the *risk*? What will it *cost* to upgrade every node on the Internet? And *how long* might it take? We succeeded in upgrading every end-node and every router in the Internet in the late '90s and early 2000's, when we deployed CIDR. It was doable. We know that because we did it! (And if we hadn't done it, the Internet would not have scaled to world scale.) So today if we decide that unicast use of the 268 million addresses in 240/4 is worth doing, we can upgrade every node. If we do, we might as well support unicast on the other 16 million addresses in 0/8, and the 16 million in 127/8, and the other about 16 million reserved for 4.2BSD's pre-standardized subnet broadcast address that nobody has used since 1985. And take a hard look at another hundred million addresses in the vast empty multicast space, that have never been assigned by IANA for anybody or anything. Adding the address blocks around the edges makes sense; you only have to upgrade everything once, but the 268 million addresses becomes closer to 400 million formerly wasted addresses. That would be worth half again as much to end users, compared to just doing 240/4! That may not be worth it to you. Or to your friends. But it would be useful to a lot of people -- hundreds of millions of people who you may never know. People who didn't get IP addresses when they were free, people outside the US and Europe, who will be able to buy and use them in 5 or 10 years, rather than leaving them unused and rotting on the vine. We already know that making these one-line patches is almost risk-free. 240/4 unicast support is in billions of nodes already, without trouble. Linux, Android, MacOS, iOS, and Solaris all started supporting unicast use of 240/4 in 2008! Most people -- even most people in NANOG -- didn't even notice. 0/8 unicast has been in Linux and Android kernels for multiple years, again with no problems. Unicast use of the lowest address in each subnet is now in Linux and NetBSD, recently (see the drafts for specifics). If anyone knows of security issues that we haven't addressed in the drafts, please tell us the details! There has been some arm-waving about a need to update firewalls, but most of these addresses have been usable as unicast on LANs and private networks for more than a decade, and nobody's reported any firewall vulnerabilities to CERT. Given the low risk, the natural way for these unicast extensions to roll out is to simply include them in new releases of the various operating systems and router OS's that implement the Internet protocols. It is already happening, we're just asking that the process be adopted universally, which is why we wrote Internet-Drafts for IETF. Microsoft Windows is the biggest laggard; they drop any packet whose destination OR SOURCE address is in 240/4. When standards said 240/4 was reserved for what might become future arcane (variable-length, anycast, 6to4, etc) addressing modes, that made sense. It doesn't make sense in 2021. IPv4 is stable and won't be inventing any new addressing modes. The future is here, and all it wants out of 240/4 is more unicast addresses. By following the normal OS upgrade path, the cost of upgrading is almost zero. People naturally upgrade their OS's every few years. They replace their server or laptop with a more capable one that has the latest OS. Laggards might take 5 or 10 years. Peoples' home WiFi routers break, or are upgraded to faster models, or they change ISPs and throw the old one out, every 3 to 5 years. A huge proportion of end-users get automatic over-the-net upgrades, via an infrastructure that had not yet been built for consumers during the CIDR transition. "Patch Tuesday" could put some or all of these extensions into billions of systems at scale, for a one-time fixed engineering and testing cost. We have tested major routers, and none so far require software updates to enable most of these addresses (except on the lowest address per subnet). At worst, the ISP would have to turn off or reconfigure a bogon filter with a config setting. Also, many "Martian address" bogon lists are centrally maintained (e.g. https://team-cymru.com/community-services/bogon-reference/ ) and can easily be updated. We have found no ASIC IP implementations that hardwire in assumptions about specific IP address ranges. If you know of any, please let us know, otherwise, let's let that strawman rest. Our drafts don't propose to choose between public and private use of the newly usable unicast addresses (so the prior subject line that said "unicast public" was incorrect). Since the kernel and router implementation is the same in either case, we're trying to get those fixed first. There will be plenty of years and plenty of forums (NANOG, IETF, ICANN, IANA, and the RIRs) in which to wrestle the public-vs-private questions to the ground and make community decisions on actual allocations. But if we don't fix the kernels and routers first, none of those decisions would be implementable. Finally, as suggested by David Conrad, there is a well understood process for "de-bogonizing" an address range on the global Internet, once support for it exists in OS's. Cloudflare used it on 1.1.1.1; RIPE used it on 128.0/16 and on 2a10::/12. You introduce a global BGP route for some part of the range, stand up a server on it, and use various distributed measurement testbeds to see who can reach that server. When chunks of the Internet can't, an engineer figures out where the blockage is, and communicates with that ISP or vendor to resolve the issue. Lather, rinse and repeat for a year or more, until reachability is "high enough". Addresses that later end up allocated to private address blocks would never need 100% global reachability, but global testing would still help to locate low-volume OS implementations that might need to be updated. Addresses bought to number retail cellphones need not be as reachable as ones used on public-facing servers, etc. The beauty of a market for IP addresses, rather than one-size-fits-all allocation models, is that ones with different reachability can sell for different prices, at different times, into different niches where they can be put to use. John

23 40

Weekly Global IPv4 Routing Table Report
by Routing Table Analysis Role Account 26 Nov '21

26 Nov '21

This is an automated weekly mailing describing the state of the Gobal IPv4 Routing Table as seen from APNIC's router in Japan. The posting is sent to APOPS, NANOG, AfNOG, SANOG, PacNOG, SAFNOG TZNOG, MENOG, BJNOG, SDNOG, CMNOG, LACNOG and the RIPE Routing WG. Daily listings are sent to bgp-stats(a)lists.apnic.net For historical data, please see https://thyme.apnic.net. If you have any comments please contact Philip Smith <pfsinoz(a)gmail.com>. Global IPv4 Routing Table Report 04:00 +10GMT Sat 27 Nov, 2021 BGP Table as seen in Japan. Report Website: https://thyme.apnic.net Detailed Analysis: https://thyme.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 872472 Prefixes after maximum aggregation (per Origin AS): 330087 Deaggregation factor: 2.64 Unique aggregates announced (without unneeded subnets): 421607 Number of IPv4 prefixes with ROAs (including AS0): 247772 Total ASes present in the Internet Routing Table: 72382 Prefixes per ASN: 12.05 Origin-only ASes present in the Internet Routing Table: 62143 Origin ASes announcing only one prefix: 25685 Transit ASes present in the Internet Routing Table: 10239 Transit-only ASes present in the Internet Routing Table: 357 Average AS path length visible in the Internet Routing Table: 4.3 Max AS path length visible: 53 Max AS path prepend of ASN (265020) 50 Prefixes from unregistered ASNs in the Routing Table: 893 Number of instances of unregistered ASNs: 897 Number of 32-bit ASNs allocated by the RIRs: 37925 Number of 32-bit ASNs visible in the Routing Table: 31495 Prefixes from 32-bit ASNs in the Routing Table: 145183 Number of bogon 32-bit ASNs visible in the Routing Table: 24 Special use prefixes present in the Routing Table: 1 Prefixes being announced from unallocated address space: 862 Number of addresses announced to Internet: 3071623936 Equivalent to 183 /8s, 21 /16s and 67 /24s Percentage of available address space announced: 83.0 Percentage of allocated address space announced: 83.0 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 99.5 Total number of prefixes smaller than registry allocations: 290843 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 231533 Total APNIC prefixes after maximum aggregation: 64938 APNIC Deaggregation factor: 3.57 Prefixes being announced from the APNIC address blocks: 226709 Unique aggregates announced from the APNIC address blocks: 93050 APNIC Region origin ASes present in the Internet Routing Table: 12153 APNIC Prefixes per ASN: 18.65 APNIC Region origin ASes announcing only one prefix: 3493 APNIC Region transit ASes present in the Internet Routing Table: 1710 Average APNIC Region AS path length visible: 4.5 Max APNIC Region AS path length visible: 37 Number of APNIC region 32-bit ASNs visible in the Routing Table: 7333 Number of APNIC addresses announced to Internet: 773087360 Equivalent to 46 /8s, 20 /16s and 96 /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-151865 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: 256209 Total ARIN prefixes after maximum aggregation: 118264 ARIN Deaggregation factor: 2.17 Prefixes being announced from the ARIN address blocks: 255844 Unique aggregates announced from the ARIN address blocks: 122186 ARIN Region origin ASes present in the Internet Routing Table: 18952 ARIN Prefixes per ASN: 13.50 ARIN Region origin ASes announcing only one prefix: 6862 ARIN Region transit ASes present in the Internet Routing Table: 1967 Average ARIN Region AS path length visible: 3.8 Max ARIN Region AS path length visible: 35 Number of ARIN region 32-bit ASNs visible in the Routing Table: 4229 Number of ARIN addresses announced to Internet: 1301302016 Equivalent to 77 /8s, 144 /16s and 75 /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-401308 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, 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: 243696 Total RIPE prefixes after maximum aggregation: 113966 RIPE Deaggregation factor: 2.14 Prefixes being announced from the RIPE address blocks: 239822 Unique aggregates announced from the RIPE address blocks: 146828 RIPE Region origin ASes present in the Internet Routing Table: 28162 RIPE Prefixes per ASN: 8.52 RIPE Region origin ASes announcing only one prefix: 12153 RIPE Region transit ASes present in the Internet Routing Table: 3938 Average RIPE Region AS path length visible: 4.3 Max RIPE Region AS path length visible: 31 Number of RIPE region 32-bit ASNs visible in the Routing Table: 10550 Number of RIPE addresses announced to Internet: 712438400 Equivalent to 42 /8s, 118 /16s and 242 /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-213403 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: 113030 Total LACNIC prefixes after maximum aggregation: 27001 LACNIC Deaggregation factor: 4.19 Prefixes being announced from the LACNIC address blocks: 113942 Unique aggregates announced from the LACNIC address blocks: 47540 LACNIC Region origin ASes present in the Internet Routing Table: 10805 LACNIC Prefixes per ASN: 10.55 LACNIC Region origin ASes announcing only one prefix: 2627 LACNIC Region transit ASes present in the Internet Routing Table: 2145 Average LACNIC Region AS path length visible: 5.0 Max LACNIC Region AS path length visible: 53 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 8482 Number of LACNIC addresses announced to Internet: 176399872 Equivalent to 10 /8s, 131 /16s and 166 /24s LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 61440-61951, 64099-64197, 262144-272796 + 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: 27111 Total AfriNIC prefixes after maximum aggregation: 5239 AfriNIC Deaggregation factor: 5.17 Prefixes being announced from the AfriNIC address blocks: 35293 Unique aggregates announced from the AfriNIC address blocks: 11220 AfriNIC Region origin ASes present in the Internet Routing Table: 1571 AfriNIC Prefixes per ASN: 22.47 AfriNIC Region origin ASes announcing only one prefix: 550 AfriNIC Region transit ASes present in the Internet Routing Table: 304 Average AfriNIC Region AS path length visible: 5.1 Max AfriNIC Region AS path length visible: 42 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 901 Number of AfriNIC addresses announced to Internet: 107848192 Equivalent to 6 /8s, 109 /16s and 162 /24s AfriNIC AS Blocks 36864-37887, 327680-329727 & ERX transfers AfriNIC Address Blocks 41/8, 45/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 9808 8744 9000 57 CHINAMOBILE-CN China Mobile Communicati 7545 5861 787 684 TPG-INTERNET-AP TPG Telecom Limited, AU 4538 4665 4192 74 ERX-CERNET-BKB China Education and Rese 7552 3593 1330 20 VIETEL-AS-AP Viettel Group, VN 7713 3495 1023 57 TELKOMNET-AS-AP PT Telekomunikasi Indon 45899 3233 1896 54 VNPT-AS-VN VNPT Corp, VN 4766 2503 11119 579 KIXS-AS-KR Korea Telecom, KR 9498 2182 475 237 BBIL-AP BHARTI Airtel Ltd., IN 45090 2135 1198 75 TENCENT-NET-AP Shenzhen Tencent Compute 4755 2121 429 202 TATACOMM-AS TATA Communications formerl Complete listing at https://thyme.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 16509 6016 10015 2587 AMAZON-02, US 11492 4593 304 821 CABLEONE, US 22773 4017 3047 372 ASN-CXA-ALL-CCI-22773-RDC, US 7155 3950 264 30 VIASAT-SP-BACKBONE, US 16625 3679 1896 2559 AKAMAI-AS, US 6327 3389 1318 65 SHAW, CA 749 2890 50784 2146 DNIC-AS-00749, US 30036 2599 373 153 MEDIACOM-ENTERPRISE-BUSINESS, US 209 2522 5043 434 CENTURYLINK-US-LEGACY-QWEST, US 20115 2243 3033 502 CHARTER-20115, US Complete listing at https://thyme.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 12479 6863 1731 149 UNI2-AS, ES 20940 3922 3348 218 AKAMAI-ASN1, NL 8551 3448 378 39 BEZEQ-INTERNATIONAL-AS Bezeqint Interne 39891 3271 187 23 ALJAWWALSTC-AS, SA 12389 2932 2279 898 ROSTELECOM-AS, RU 9009 2559 263 1348 M247, GB 34984 2204 355 601 TELLCOM-AS, TR 58224 1759 918 579 TCI, IR 61317 1653 214 927 ASDETUK www.heficed.com, GB 13188 1610 100 27 TRIOLAN, UA Complete listing at https://thyme.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 8151 10647 3450 577 Uninet S.A. de C.V., MX 10620 3251 491 826 Telmex Colombia S.A., CO 11830 2467 369 62 Instituto Costarricense de Electricidad 13999 1612 285 457 Mega Cable, S.A. de C.V., MX 6503 1488 357 499 Axtel, S.A.B. de C.V., MX 28573 1395 2317 257 CLARO S.A., BR 3816 1240 651 153 COLOMBIA TELECOMUNICACIONES S.A. ESP, C 26615 1139 2351 139 TIM SA, BR 6147 1087 369 21 Telefonica del Peru S.A.A., PE 11664 980 189 441 Techtel LMDS Comunicaciones Interactiva Complete listing at https://thyme.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 24863 1632 393 21 LINKdotNET-AS, EG 24835 1553 507 33 RAYA-AS, EG 36992 1286 1430 268 ETISALAT-MISR, EG 36903 1183 537 110 MT-MPLS, MA 29571 825 68 11 ORANGE-COTE-IVOIRE, CI 36935 703 523 44 Vodafone-, EG 6713 612 1863 34 IAM-AS, MA 15399 516 50 31 WANANCHI-, KE 37342 470 32 1 MOVITEL, MZ 23889 428 232 16 MauritiusTelecom, MU Complete listing at https://thyme.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 8151 10647 3450 577 Uninet S.A. de C.V., MX 9808 8744 9000 57 CHINAMOBILE-CN China Mobile Communicati 12479 6863 1731 149 UNI2-AS, ES 16509 6016 10015 2587 AMAZON-02, US 7545 5861 787 684 TPG-INTERNET-AP TPG Telecom Limited, AU 4538 4665 4192 74 ERX-CERNET-BKB China Education and Rese 11492 4593 304 821 CABLEONE, US 22773 4017 3047 372 ASN-CXA-ALL-CCI-22773-RDC, US 7155 3950 264 30 VIASAT-SP-BACKBONE, US 20940 3922 3348 218 AKAMAI-ASN1, NL Complete listing at https://thyme.apnic.net/current/data-ASnet Global Per AS Maximum Aggregation summary ----------------------------------------- ASN No of nets Net Savings Description 9808 8744 8687 CHINAMOBILE-CN China Mobile Communications Grou 12479 6863 6714 UNI2-AS, ES 7545 5861 5177 TPG-INTERNET-AP TPG Telecom Limited, AU 4538 4665 4591 ERX-CERNET-BKB China Education and Research Net 7155 3950 3920 VIASAT-SP-BACKBONE, US 11492 4593 3772 CABLEONE, US 20940 3922 3704 AKAMAI-ASN1, NL 22773 4017 3645 ASN-CXA-ALL-CCI-22773-RDC, US 7552 3593 3573 VIETEL-AS-AP Viettel Group, VN 7713 3495 3438 TELKOMNET-AS-AP PT Telekomunikasi Indonesia, ID Complete listing at https://thyme.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Net Originated Transit AS Transit AS Name 46990 UNALLOCATED 8.5.242.0/23 3356 LEVEL3, US 62828 UNALLOCATED 8.21.130.0/24 3356 LEVEL3, US 393266 UNALLOCATED 8.23.52.0/24 46887 LIGHTOWER, US 18604 UNALLOCATED 8.25.204.0/24 3356 LEVEL3, US 394936 UNALLOCATED 8.33.224.0/24 174 COGENT-174, US 54338 UNALLOCATED 8.33.241.0/24 6461 ZAYO-6461, US 1782 UNALLOCATED 8.42.19.0/24 46887 LIGHTOWER, US 395438 UNALLOCATED 8.42.206.0/24 3356 LEVEL3, US 395056 UNALLOCATED 8.45.133.0/24 3356 LEVEL3, US 32306 UNALLOCATED 8.46.80.0/24 33652 CMCS, US Complete listing at https://thyme.apnic.net/current/data-badAS Prefixes from private and non-routed address space (Global) ----------------------------------------------------------- Prefix Origin AS Description 192.88.99.0/24 6939 HURRICANE, US Complete listing at https://thyme.apnic.net/current/data-dsua Advertised Unallocated Addresses -------------------------------- Unassigned Network ASN Information AS Name 23.141.0.0/24 Origin: 395350 UNASSIGNED 23.141.0.0/24 Transit: 11426 TWC-11426-CAROLINAS, US 23.252.160.0/24 Origin: 398968 GROUP-IID-01, US 23.252.160.0/24 Transit: 1299 TWELVE99 Twelve99, Telia Carrier, SE 23.252.161.0/24 Origin: 398968 GROUP-IID-01, US 23.252.161.0/24 Transit: 1299 TWELVE99 Twelve99, Telia Carrier, SE 23.252.162.0/24 Origin: 398968 GROUP-IID-01, US 23.252.162.0/24 Transit: 1299 TWELVE99 Twelve99, Telia Carrier, SE 23.252.163.0/24 Origin: 398968 GROUP-IID-01, US 23.252.163.0/24 Transit: 1299 TWELVE99 Twelve99, Telia Carrier, SE Complete listing at https://thyme.apnic.net/current/data-add-IANA Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:16 /9:13 /10:41 /11:101 /12:304 /13:597 /14:1216 /15:2046 /16:13550 /17:8270 /18:13913 /19:25222 /20:43098 /21:50983 /22:107611 /23:93957 /24:510735 /25:799 /26:0 /27:0 /28:0 /29:0 /30:0 /31:0 /32:0 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 12479 5810 6863 UNI2-AS, ES 8151 4446 10647 Uninet S.A. de C.V., MX 11492 3546 4593 CABLEONE, US 6327 3197 3389 SHAW, CA 7155 3040 3950 VIASAT-SP-BACKBONE, US 22773 2994 4017 ASN-CXA-ALL-CCI-22773-RDC, US 8551 2913 3448 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo 39891 2807 3271 ALJAWWALSTC-AS, SA 30036 2254 2599 MEDIACOM-ENTERPRISE-BUSINESS, US 11830 1921 2467 Instituto Costarricense de Electricidad y Telec Complete listing at https://thyme.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1912 2:1036 3:146 4:18 5:3721 6:100 7:5 8:1556 9:1 11:172 12:1707 13:411 14:2281 15:132 16:32 17:374 18:130 20:142 21:4 22:188 23:5325 24:2371 25:4 27:2565 29:19 31:2372 32:106 34:1 35:48 36:1736 37:3911 38:2372 39:651 40:149 41:3903 42:1023 43:2095 44:294 45:15638 46:3795 47:322 49:1688 50:1881 51:104 52:1345 54:288 55:647 56:4 57:55 58:1745 59:1128 60:940 61:2246 62:2408 63:1951 64:5410 65:2350 66:4944 67:2899 68:1174 69:4148 70:1344 71:678 72:3093 74:2615 75:1502 76:710 77:2133 78:1748 79:2702 80:1875 81:1497 82:1415 83:1174 84:1300 85:2827 86:700 87:1884 88:978 89:3144 90:488 91:7501 92:1891 93:2573 94:3227 95:3588 96:1299 97:347 98:983 99:911 100:76 101:1057 102:1792 103:27563 104:4103 105:424 106:842 107:2391 108:753 109:3989 110:2066 111:3148 112:1960 113:1519 114:1541 115:1937 116:1892 117:2480 118:2306 119:1850 120:1619 121:1042 122:2547 123:2133 124:1598 125:2043 128:1408 129:1102 130:914 131:2068 132:748 133:366 134:1918 135:285 136:785 137:859 138:2432 139:1204 140:842 141:1313 142:1225 143:1351 144:1251 145:330 146:1685 147:1461 148:2229 149:1586 150:852 151:1088 152:1651 153:442 154:3310 155:1363 156:1832 157:1201 158:988 159:2017 160:2329 161:1272 162:3409 163:1174 164:1648 165:1502 166:603 167:1668 168:3633 169:682 170:4301 171:807 172:2849 173:3044 174:1005 175:1134 176:3419 177:4466 178:3004 179:1943 180:2266 181:2621 182:3168 183:1924 184:2410 185:19053 186:4237 187:3532 188:3632 189:3107 190:8747 191:1336 192:11008 193:8430 194:6892 195:4931 196:2901 197:2316 198:6016 199:6010 200:7432 201:5675 202:10519 203:10058 204:4501 205:3386 206:3848 207:3381 208:4010 209:4611 210:4232 211:2435 212:3835 213:3384 214:1162 215:64 216:6392 217:2609 218:1213 219:620 220:1965 221:989 222:852 223:2106 End of report

1 0

problem with cloud services at Lightshot / app.prntscr.com.
by Jacques G. Busnardo 26 Nov '21

26 Nov '21

Hello, I have a problem with cloud services at Lightshot / app.prntscr.com. Always return the CAPTCHA(Cloudflare - One more step) when I try to open the app.prntscr.com. Does anyone have any technical contact? best regards, Jacques G. Busnardo

1 0

Validating multi-path in production?
by Adam Thompson 26 Nov '21

26 Nov '21

Hello all. Over time, we've run into occurrences of both bugs and human error, both in our own gear and in our partner networks' gear, specifically affecting multi-path forwarding, at pretty much all layers: Multi-chassis LAG, ECMP, and BGP MP. (Yes, I am a corner-case magnet. Lucky me.) Some of these issues were fairly obvious when they happened, but some were really hard to pin down. We've found that typical network monitoring tools (Observium & Smokeping, not to mention plain old ping and traceroute) can't really detect a hashing-related or multi-path-related problem: either the packets get through or they don't. Can anyone recommend either tools or techniques to validate that multi-path forwarding either is, or isn't, working correctly in a production network? I'm looking to add something to our test suite for when we make changes to critical network gear. Almost all the scenarios I want to test only involve two paths, if that helps. The best I've come up with so far is to have two test systems (typically VMs) that use adjacent IP addresses and adjacent MAC addresses, and test both inbound and outbound to/from those, blindly trusting/hoping that hashing algorithms will probably exercise both paths. Some of the problems we've seen show that merely looking at interface counters is insufficient, so I'm trying to find an explicit proof, not implicit. Any suggestions? Surely other vendors and/or admins have screwed this up in subtle ways enough times that this knowledge exists? (My Google-fu is usually pretty good, but I'm striking out - maybe I'm using the wrong terms.) -Adam Adam Thompson Consultant, Infrastructure Services [1593169877849] 100 - 135 Innovation Drive Winnipeg, MB, R3T 6A8 (204) 977-6824 or 1-800-430-6404 (MB only) athompson(a)merlin.mb.ca<mailto:athompson@merlin.mb.ca> www.merlin.mb.ca<http://www.merlin.mb.ca/>

7 7