- Test - lists.nanog.org

NANOG 79 Call For Presentations
by Vincent Celindro 03 Mar '20

03 Mar '20

Vincent Celindro <vcelindro(a)nanog.org> Thu, Nov 21, 2019, 5:57 PM to NANOG-announce, nanog Dear NANOG Community, In NANOG tradition - The NANOG Program Committee (PC) is excited to announce that we are accepting proposals for all sessions at NANOG 79 in Boston, Massachusetts, June 1st - 3rd, 2020. As mentioned during the community meeting at NANOG 78 in San Francisco, the Call For Presentations, CFP, is now open all year round, for current and future meetings. Below is a summary of key details and dates for the CFP, which can also be found at https://www.nanog.org/meetings/nanog-79/submit-presentation/ Given by many of the industry’s top minds, presentations at NANOG meetings are meant to spark the imagination, encourage dialog, and drive new solutions to our greatest networking challenges. The PC is currently seeking proposals, and also welcomes suggestions for speakers and topics. Presentations may cover current technologies, soon-to-be deployed technologies, and industry innovation. Vendors are welcome to submit talks which cover relevant technologies and capabilities, but presentations should not be promotional, or discuss proprietary solutions. We understand you may have concerns regarding the COVID 19 coronavirus. To date, the areas of the world most impacted by the virus are outside the North American region, which NANOG serves. The NANOG Board of Directors and executive team are closely watching the latest news reports as information about the virus rapidly changes, and how this may or may not impact the upcoming conference. There is no information at this time that suggests we should cancel NANOG 79, but we assure you we'll keep the entire NANOG community up to date as information changes, and we learn more. The primary speaker, moderator, or author should submit a presentation proposal and abstract via the Program Committee Tool at: https://www.nanog.org/meetings/submit-presentation/ - Sign in with your Profile Account - Select the type of talk you propose to present, and complete the title and abstract Timeline for submission and proposal review: - Submitter enters abstract (and draft slides if possible) in Program Committee Tool prior to the deadline for slide submission. - PC performs initial review and assigns a “shepherd” to help develop the submission — within 2 weeks. - Submitter develops draft slides of talk if not already submitted with the initial proposal. Please submit initial draft slides early — the PC does not evaluate submissions until draft slides are available for review. A NANOG slide template as well as presentation guidelines are available here. https://www.nanog.org/participate/presentation-guidelines/ - Panel and Track submissions should provide a topic list and intended/confirmed participants in the abstract. - PC reviews the slides and continues to work with Submitter as needed to develop the topic. - Draft presentation slides should be submitted prior to the published deadline for slides (April 13th, 2020). - PC evaluates submissions to determine presentations for the agenda (posted by May 18th, 2020). - Agenda assembled and posted. - Submitters notified. - Final presentation slides must be submitted prior to the published deadline for slides (May 25th, 2020). If you think you have an interesting topic but want feedback or suggestions for developing an idea into a presentation, please email the PC ( nanogpc(a)nanog.org) and a representative will respond to you in a timely manner. Otherwise, submit your talk, keynote, track, or panel proposal to the Program Committee Tool at your earliest convenience. We look forward to reviewing your submission! Key dates for NANOG 79: Date Event/Deadline March 2, 2020 CFP Opens March 30, 2020 Standard Registration Begins April 13, 2020 CFP Deadline: Presentation Slides Due May 4, 2020 CFP Topic List & NANOG Meeting HIghlights Page posted May 11, 2020 Late Registration Begins May 18, 2020 NANOG 78 Agenda Posted May 25, 2020 Speaker FINAL presentations DUE (NO CHANGES accepted after this date) May 31, 2020 Lightning Talk Submissions Open, Onsite Registration Begins Final slides must be submitted by Monday, May 25th, 2020, and no changes will be accepted between that date and the conference. Materials received after that date may be updated on the website after the completion of the conference. We look forward to seeing you in Boston in June! Sincerely, Vincent Celindro - PC Chair On behalf of the NANOG Program Committee

1 0

Equinix IX Dallas Legacy Route Servers Decommissioning - Subnet Expansion
by David Miller 03 Mar '20

03 Mar '20

PSA: For anyone on the Equinix IX in Dallas who may have missed the announcements - The subnet in Dallas was expanded to a /23 and there are new MLPE route servers. The old route servers will be decommissioned this week. >From Equinix: "IBX(s): DA1,DA10,DA2,DA3,DA4,DA6,DA7,DA9,DA99 DESCRIPTION:NOTICE: THE LEGACY MLPE AND ROUTE COLLECTOR SERVERS WILL BE DECOMMISSIONED 5-MAR-2020 Equinix expanded the DA IX subnet from a /24 to a /23 on 25-JUN-2019. Equinix engineers also updated the MLPE and Route Collector IPs and subnet mask from /24 to /23. Customers that have not already done so, will need to update their subnet mask and peering IP address for the MLPE/RC servers to reflect the newly expanded subnet of 206.223.118.NNN/23. BGP Sessions are preconfigured for all MLPE/RC participants on the new servers, but if you have issues bringing up your sessions please contact us. A Status page is published at the following link https://ix.equinix.com/home/ip-migration/da/ " -- ______________________ David Miller dmiller(a)tiggee.com

1 0

Take-Two Interactive Software NOC Contact
by Tim Nowaczyk 03 Mar '20

03 Mar '20

Network Engineer for a small ISP here. Our customers seem to be having connectivity issues with Take-Two Software, specifically NBA 2k20. Traceroute makes it to Akamai Prolexic before being dropped. Does anyone have contact info for someone at Take-Two? Thanks, Tim Nowaczyk -- Timothy Nowaczyk | Senior Network Manager office 703.554.6622 <tel:703.554.6622> | mobile 571.318.9434 <tel:571.318.9434> <http://www.allpointsbroadband.com/>

2 1

Legacy Concentric/XO Web Services Blocking?
by James Breeden 03 Mar '20

03 Mar '20

NANOG, Looking for anyone from XO or Legacy Concentric web hosting services (now VDMS). I have a mutual customer that is getting caught at some form of Web App firewall coming from a specific IP range. Thank you! James W. Breeden Managing Partner [logo_transparent_background] Arenal Group: Arenal Consulting Group | Atheral | Ceteris Coin | Acilis Telecom | Pines Events and Media | BlueNinja Corporate: PO Box 1063 | Smithville, TX 78957 Email: james(a)arenalgroup.co<mailto:james@arenalgroup.co> | office 512.360.0000 | www.arenalgroup.co<http://www.arenalgroup.co/>

1 0

Re: China’s Slow Transnational Network
by Scott Weeks 02 Mar '20

02 Mar '20

In fact, Great Canon (GC) [55] is such an in-path system. But it is known for intercepting a subset of traffic (based on protocol type) only. What’s more, GC has been activated only twice in history (the last one in 2015 [55]). ----------------------------------- AT&T security says otherwise: https://cybersecurity.att.com/blogs/labs-research/the-great-cannon-has-been… The Great Cannon is a distributed denial of service tool (“DDoS”) that operates by injecting malicious Javascript into pages served from behind the Great Firewall." "The Great Cannon was the subject of intense research after it was used to disrupt access to the website Github.com in 2015. Little has been seen of the Great Cannon since 2015. However, we’ve recently observed new attacks..." "On August 31, 2019, the Great Cannon initiated an attack against a website (lihkg.com) used by members of the Hong Kong democracy movement to plan protests." scott

1 0

Re: China’s Slow Transnational Network
by Pengxiong Zhu 02 Mar '20

02 Mar '20

In fact, the three large carriers provide 98.5% of China’s total transnational bandwidth. We observe this across all the three large carriers, as well as one smaller carrier, CERNET(China Education and Research Network). Best, Pengxiong Zhu Department of Computer Science and Engineering University of California, Riverside On Mon, Mar 2, 2020 at 12:12 PM Ben Cannon <ben(a)6by7.net> wrote: > > On Mar 2, 2020, at 11:38 AM, Pengxiong Zhu <pzhu011(a)ucr.edu> wrote: > > Those are good insights. Our first guess is censorship too, and we > discussed the possibilities of censorship side effects in Section 5.1 > *Censorship*. > > It’s the Government doing mandatory content filtering at the border. >> Their hardware is either deliberately or accidentally poor-performing. >> > > However, GFW operates as an on-path system [72], which only processes > copies of existing packets without the ability to discard existing packets. > Evidently, prior work has shown that GFW fails to inject RST packets during > busy hours while the packets containing sensitive keywords are still > delivered successfully [34]. However, we are unable to rule out the > possibility that GFW has evolved to acquire the capability to discard > packets. > > Maybe... I dunno.... get rid of the Great Firewall of China? > > > We designed a small experiment to locate the hops with GFW presence, and > then try to match them with the bottleneck hops. We found only in 34.45% of > the cases, the GFW hops match the bottleneck hops. > > My guess is that it’s all the DDoS traffic coming from China saturating >> the links. >> > > In fact, Great Canon (GC) [55] is such an in-path system. But it is known > for intercepting a subset of traffic (based on protocol type) only. What’s > more, GC has been activated only twice in history (the last one in 2015 > [55]). However, it might be the case that the in-path capability is > re-purposed to perform general traffic throttling. If that is the case, > they have done a good job because the throttling resembles natural > congestion from the loss rate and latency point of view. > > > I believe this is what’s happening, and I believe they are rate-limiting > and causing actual congestion, as opposed to simulating it. The losses > would be real, actual saturation, on simply rate-limited flows. Unclear if > this is being done on a per-flow basis or per-source or what. You might be > able to find out. I’m curious if you see this across all carriers or only > the larger ones? > > -Ben. > > The asymmetric performance between downstream and upstream traffic can be > explained by the natural imbalance of transnational traffic (where the > upstream traffic from China to outside is not significant enough to > throttle). > > > Best, > Pengxiong Zhu > Department of Computer Science and Engineering > University of California, Riverside > > > On Mon, Mar 2, 2020 at 8:11 AM Compton, Rich A <Rich.Compton(a)charter.com> > wrote: > >> My guess is that it’s all the DDoS traffic coming from China saturating >> the links. >> >> >> >> *From: *NANOG Email List <nanog-bounces(a)nanog.org> on behalf of >> Pengxiong Zhu <pzhu011(a)ucr.edu> >> *Date: *Monday, March 2, 2020 at 8:58 AM >> *To: *NANOG list <nanog(a)nanog.org> >> *Cc: *Zhiyun Qian <zhiyunq(a)cs.ucr.edu> >> *Subject: *China’s Slow Transnational Network >> >> >> >> Hi all, >> >> >> >> We are a group of researchers at University of California, Riverside who >> have been working on measuring the transnational network performance (and >> have previously asked questions on the mailing list). Our work has now led >> to a publication in Sigmetrics 2020 and we are eager to share some >> >> interesting findings. >> >> >> >> We find China's transnational networks have extremely poor performance >> when accessing foreign sites, where the throughput is often persistently >> >> low (e.g., for the majority of the daytime). Compared to other countries >> we measured including both developed and developing, China's transnational >> network performance is among the worst (comparable and even worse than some >> African countries). >> >> >> >> Measuring from more than 400 pairs of mainland China and foreign nodes >> over more than 53 days, our result shows when data transferring from >> foreign nodes to China, 79% of measured connections has throughput lower >> than the 1Mbps, sometimes it is even much lower. The slow speed occurs only >> during certain times and forms a diurnal pattern that resembles congestion >> (irrespective of network protocol and content), please see the following >> figure. The diurnal pattern is fairly stable, 80% to 95% of the >> transnational connections have a less than 3 hours standard deviation of >> the slowdown hours each day over the entire duration. However, the speed >> rises up from 1Mbps to 4Mbps in about half an hour. >> >> >> >> [image: blob:null/71cf5a6a-3841-41ce-a1d4-207b59182189] >> >> >> >> We are able to confirm that high packet loss rates and delays are >> incurred in the foreign-to-China direction only. Moreover, the end-to-end >> loss rate could rise up to 40% during the slow period, with ~15% on average. >> >> >> >> There are a few things noteworthy regarding the phenomenon. First of all, >> all traffic types are treated equally, HTTP(S), VPN, etc., which means it >> is discriminating or differentiating any specific kinds of traffic. Second, >> we found for 71% of connections, the bottleneck is located inside China >> (the second hop after entering China or further), which means that it is >> mostly unrelated to the transnational link itself (e.g., submarine cable). >> Yet we never observed any such domestic traffic slowdowns within China. >> >> Assuming this is due to congestion, it is unclear why the infrastructures >> within China that handles transnational traffic is not even capable to >> handle the capacity of transnational links, e.g., submarine cable, which >> maybe the most expensive investment themselves. >> >> >> >> Here is the link to our paper: >> >> https://www.cs.ucr.edu/~zhiyunq/pub/sigmetrics20_slowdown.pdf >> >> >> We appreciate any comments or feedback. >> >> -- >> >> >> Best, >> Pengxiong Zhu >> Department of Computer Science and Engineering >> University of California, Riverside >> The contents of this e-mail message and >> any attachments are intended solely for the >> addressee(s) and may contain confidential >> and/or legally privileged information. If you >> are not the intended recipient of this message >> or if this message has been addressed to you >> in error, please immediately alert the sender >> by reply e-mail and then delete this message >> and any attachments. If you are not the >> intended recipient, you are notified that >> any use, dissemination, distribution, copying, >> or storage of this message or any attachment >> is strictly prohibited. >> > >

1 0

Re: China’s Slow Transnational Network
by Pengxiong Zhu 02 Mar '20

02 Mar '20

Those are good insights. Our first guess is censorship too, and we discussed the possibilities of censorship side effects in Section 5.1 *Censorship*. My guess is that it’s all the DDoS traffic coming from China saturating the > links. > In fact, Great Canon (GC) [55] is such an in-path system. But it is known for intercepting a subset of traffic (based on protocol type) only. What’s more, GC has been activated only twice in history (the last one in 2015 [55]). However, it might be the case that the in-path capability is re-purposed to perform general traffic throttling. If that is the case, they have done a good job because the throttling resembles natural congestion from the loss rate and latency point of view. The asymmetric performance between downstream and upstream traffic can be explained by the natural imbalance of transnational traffic (where the upstream traffic from China to outside is not significant enough to throttle). Maybe... I dunno.... get rid of the Great Firewall of China? > What do you mean? Do you mean the slow traffic is to bypass the GFW or the slow traffic is caused by GFW? Best, Pengxiong Zhu Department of Computer Science and Engineering University of California, Riverside On Mon, Mar 2, 2020 at 11:38 AM Pengxiong Zhu <pzhu011(a)ucr.edu> wrote: > Those are good insights. Our first guess is censorship too, and we > discussed the possibilities of censorship side effects in Section 5.1 > *Censorship*. > > It’s the Government doing mandatory content filtering at the border. >> Their hardware is either deliberately or accidentally poor-performing. >> > > However, GFW operates as an on-path system [72], which only processes > copies of existing packets without the ability to discard existing packets. > Evidently, prior work has shown that GFW fails to inject RST packets during > busy hours while the packets containing sensitive keywords are still > delivered successfully [34]. However, we are unable to rule out the > possibility that GFW has evolved to acquire the capability to discard > packets. > > Maybe... I dunno.... get rid of the Great Firewall of China? > > > We designed a small experiment to locate the hops with GFW presence, and > then try to match them with the bottleneck hops. We found only in 34.45% of > the cases, the GFW hops match the bottleneck hops. > > My guess is that it’s all the DDoS traffic coming from China saturating >> the links. >> > > In fact, Great Canon (GC) [55] is such an in-path system. But it is known > for intercepting a subset of traffic (based on protocol type) only. What’s > more, GC has been activated only twice in history (the last one in 2015 > [55]). However, it might be the case that the in-path capability is > re-purposed to perform general traffic throttling. If that is the case, > they have done a good job because the throttling resembles natural > congestion from the loss rate and latency point of view. The asymmetric > performance between downstream and upstream traffic can be explained by the > natural imbalance of transnational traffic (where the upstream traffic from > China to outside is not significant enough to throttle). > > > Best, > Pengxiong Zhu > Department of Computer Science and Engineering > University of California, Riverside > > > On Mon, Mar 2, 2020 at 8:11 AM Compton, Rich A <Rich.Compton(a)charter.com> > wrote: > >> My guess is that it’s all the DDoS traffic coming from China saturating >> the links. >> >> >> >> *From: *NANOG Email List <nanog-bounces(a)nanog.org> on behalf of >> Pengxiong Zhu <pzhu011(a)ucr.edu> >> *Date: *Monday, March 2, 2020 at 8:58 AM >> *To: *NANOG list <nanog(a)nanog.org> >> *Cc: *Zhiyun Qian <zhiyunq(a)cs.ucr.edu> >> *Subject: *China’s Slow Transnational Network >> >> >> >> Hi all, >> >> >> >> We are a group of researchers at University of California, Riverside who >> have been working on measuring the transnational network performance (and >> have previously asked questions on the mailing list). Our work has now led >> to a publication in Sigmetrics 2020 and we are eager to share some >> >> interesting findings. >> >> >> >> We find China's transnational networks have extremely poor performance >> when accessing foreign sites, where the throughput is often persistently >> >> low (e.g., for the majority of the daytime). Compared to other countries >> we measured including both developed and developing, China's transnational >> network performance is among the worst (comparable and even worse than some >> African countries). >> >> >> >> Measuring from more than 400 pairs of mainland China and foreign nodes >> over more than 53 days, our result shows when data transferring from >> foreign nodes to China, 79% of measured connections has throughput lower >> than the 1Mbps, sometimes it is even much lower. The slow speed occurs only >> during certain times and forms a diurnal pattern that resembles congestion >> (irrespective of network protocol and content), please see the following >> figure. The diurnal pattern is fairly stable, 80% to 95% of the >> transnational connections have a less than 3 hours standard deviation of >> the slowdown hours each day over the entire duration. However, the speed >> rises up from 1Mbps to 4Mbps in about half an hour. >> >> >> >> [image: blob:null/71cf5a6a-3841-41ce-a1d4-207b59182189] >> >> >> >> We are able to confirm that high packet loss rates and delays are >> incurred in the foreign-to-China direction only. Moreover, the end-to-end >> loss rate could rise up to 40% during the slow period, with ~15% on average. >> >> >> >> There are a few things noteworthy regarding the phenomenon. First of all, >> all traffic types are treated equally, HTTP(S), VPN, etc., which means it >> is discriminating or differentiating any specific kinds of traffic. Second, >> we found for 71% of connections, the bottleneck is located inside China >> (the second hop after entering China or further), which means that it is >> mostly unrelated to the transnational link itself (e.g., submarine cable). >> Yet we never observed any such domestic traffic slowdowns within China. >> >> Assuming this is due to congestion, it is unclear why the infrastructures >> within China that handles transnational traffic is not even capable to >> handle the capacity of transnational links, e.g., submarine cable, which >> maybe the most expensive investment themselves. >> >> >> >> Here is the link to our paper: >> >> https://www.cs.ucr.edu/~zhiyunq/pub/sigmetrics20_slowdown.pdf >> >> >> We appreciate any comments or feedback. >> >> -- >> >> >> Best, >> Pengxiong Zhu >> Department of Computer Science and Engineering >> University of California, Riverside >> The contents of this e-mail message and >> any attachments are intended solely for the >> addressee(s) and may contain confidential >> and/or legally privileged information. If you >> are not the intended recipient of this message >> or if this message has been addressed to you >> in error, please immediately alert the sender >> by reply e-mail and then delete this message >> and any attachments. If you are not the >> intended recipient, you are notified that >> any use, dissemination, distribution, copying, >> or storage of this message or any attachment >> is strictly prohibited. >> >

3 2

Weekly Routing Table Report
by cscora＠apnic.net 28 Feb '20

28 Feb '20

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, 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 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 29 Feb, 2020 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 797725 Prefixes after maximum aggregation (per Origin AS): 303605 Deaggregation factor: 2.63 Unique aggregates announced (without unneeded subnets): 389949 Total ASes present in the Internet Routing Table: 67220 Prefixes per ASN: 11.87 Origin-only ASes present in the Internet Routing Table: 57747 Origin ASes announcing only one prefix: 24242 Transit ASes present in the Internet Routing Table: 9473 Transit-only ASes present in the Internet Routing Table: 285 Average AS path length visible in the Internet Routing Table: 4.4 Max AS path length visible: 34 Max AS path prepend of ASN (206156) 26 Prefixes from unregistered ASNs in the Routing Table: 1179 Number of instances of unregistered ASNs: 1179 Number of 32-bit ASNs allocated by the RIRs: 30732 Number of 32-bit ASNs visible in the Routing Table: 25319 Prefixes from 32-bit ASNs in the Routing Table: 116316 Number of bogon 32-bit ASNs visible in the Routing Table: 16 Special use prefixes present in the Routing Table: 1 Prefixes being announced from unallocated address space: 1110 Number of addresses announced to Internet: 2854110848 Equivalent to 170 /8s, 30 /16s and 70 /24s Percentage of available address space announced: 77.1 Percentage of allocated address space announced: 77.1 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 99.4 Total number of prefixes smaller than registry allocations: 268248 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 210878 Total APNIC prefixes after maximum aggregation: 61543 APNIC Deaggregation factor: 3.43 Prefixes being announced from the APNIC address blocks: 204131 Unique aggregates announced from the APNIC address blocks: 85102 APNIC Region origin ASes present in the Internet Routing Table: 10367 APNIC Prefixes per ASN: 19.69 APNIC Region origin ASes announcing only one prefix: 2848 APNIC Region transit ASes present in the Internet Routing Table: 1547 Average APNIC Region AS path length visible: 4.6 Max APNIC Region AS path length visible: 26 Number of APNIC region 32-bit ASNs visible in the Routing Table: 5434 Number of APNIC addresses announced to Internet: 768208896 Equivalent to 45 /8s, 201 /16s and 240 /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-141625 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: 234135 Total ARIN prefixes after maximum aggregation: 107778 ARIN Deaggregation factor: 2.17 Prefixes being announced from the ARIN address blocks: 231796 Unique aggregates announced from the ARIN address blocks: 117534 ARIN Region origin ASes present in the Internet Routing Table: 18411 ARIN Prefixes per ASN: 12.59 ARIN Region origin ASes announcing only one prefix: 6757 ARIN Region transit ASes present in the Internet Routing Table: 1907 Average ARIN Region AS path length visible: 3.9 Max ARIN Region AS path length visible: 23 Number of ARIN region 32-bit ASNs visible in the Routing Table: 3175 Number of ARIN addresses announced to Internet: 1079092736 Equivalent to 64 /8s, 81 /16s and 166 /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-399260 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: 226124 Total RIPE prefixes after maximum aggregation: 104938 RIPE Deaggregation factor: 2.15 Prefixes being announced from the RIPE address blocks: 222843 Unique aggregates announced from the RIPE address blocks: 130746 RIPE Region origin ASes present in the Internet Routing Table: 26900 RIPE Prefixes per ASN: 8.28 RIPE Region origin ASes announcing only one prefix: 11720 RIPE Region transit ASes present in the Internet Routing Table: 3821 Average RIPE Region AS path length visible: 4.5 Max RIPE Region AS path length visible: 34 Number of RIPE region 32-bit ASNs visible in the Routing Table: 8962 Number of RIPE addresses announced to Internet: 724185472 Equivalent to 43 /8s, 42 /16s and 49 /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-210331 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: 103621 Total LACNIC prefixes after maximum aggregation: 24117 LACNIC Deaggregation factor: 4.30 Prefixes being announced from the LACNIC address blocks: 104886 Unique aggregates announced from the LACNIC address blocks: 45624 LACNIC Region origin ASes present in the Internet Routing Table: 9509 LACNIC Prefixes per ASN: 11.03 LACNIC Region origin ASes announcing only one prefix: 2433 LACNIC Region transit ASes present in the Internet Routing Table: 1785 Average LACNIC Region AS path length visible: 5.2 Max LACNIC Region AS path length visible: 31 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 7081 Number of LACNIC addresses announced to Internet: 174283776 Equivalent to 10 /8s, 99 /16s and 92 /24s LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 61440-61951, 64099-64197, 262144-270748 + 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: 21787 Total AfriNIC prefixes after maximum aggregation: 4495 AfriNIC Deaggregation factor: 4.85 Prefixes being announced from the AfriNIC address blocks: 32959 Unique aggregates announced from the AfriNIC address blocks: 9958 AfriNIC Region origin ASes present in the Internet Routing Table: 1376 AfriNIC Prefixes per ASN: 23.95 AfriNIC Region origin ASes announcing only one prefix: 484 AfriNIC Region transit ASes present in the Internet Routing Table: 271 Average AfriNIC Region AS path length visible: 5.0 Max AfriNIC Region AS path length visible: 22 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 667 Number of AfriNIC addresses announced to Internet: 107771904 Equivalent to 6 /8s, 108 /16s and 120 /24s AfriNIC AS Blocks 36864-37887, 327680-328703 & 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 7545 5305 666 617 TPG-INTERNET-AP TPG Telecom Limited, AU 4538 4623 4192 73 ERX-CERNET-BKB China Education and Rese 7552 3332 1331 24 VIETEL-AS-AP Viettel Group, VN 45899 3135 1797 104 VNPT-AS-VN VNPT Corp, VN 7713 2701 831 493 TELKOMNET-AS-AP PT Telekomunikasi Indon 9808 2624 9043 62 CMNET-GD Guangdong Mobile Communication 4766 2288 11102 561 KIXS-AS-KR Korea Telecom, KR 9498 2244 434 220 BBIL-AP BHARTI Airtel Ltd., IN 4755 2140 441 193 TATACOMM-AS TATA Communications formerl 9394 2077 4898 24 CTTNET China TieTong Telecommunications 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 7155 4034 280 28 VIASAT-SP-BACKBONE, US 11492 3998 266 665 CABLEONE, US 16509 3868 7816 1701 AMAZON-02, US 22773 3533 2971 151 ASN-CXA-ALL-CCI-22773-RDC, US 6327 3376 1324 92 SHAW, CA 16625 2991 1570 2140 AKAMAI-AS, US 209 2372 5075 531 CENTURYLINK-US-LEGACY-QWEST, US 30036 2311 360 114 MEDIACOM-ENTERPRISE-BUSINESS, US 5650 2290 2941 1631 FRONTIER-FRTR, US 20115 2141 2795 519 CHARTER-20115, US 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 12479 5925 1599 131 UNI2-AS, ES 31334 4040 484 13 KABELDEUTSCHLAND-AS, DE 39891 3776 203 20 ALJAWWALSTC-AS, SA 8551 3292 379 45 BEZEQ-INTERNATIONAL-AS Bezeqint Interne 20940 2907 465 1995 AKAMAI-ASN1, US 12389 2480 2248 731 ROSTELECOM-AS, RU 34984 2092 350 560 TELLCOM-AS, TR 9009 2060 217 1097 M247, GB 9121 1922 1691 18 TTNET, TR 13188 1604 100 47 TRIOLAN, UA 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 8151 6266 3291 596 Uninet S.A. de C.V., MX 10620 3361 534 446 Telmex Colombia S.A., CO 11830 2672 369 63 Instituto Costarricense de Electricidad 6503 1673 327 388 Axtel, S.A.B. de C.V., MX 7303 1557 1030 265 Telecom Argentina S.A., AR 28573 1329 2236 189 CLARO S.A., BR 13999 1231 502 288 Mega Cable, S.A. de C.V., MX 6147 1126 379 39 Telefonica del Peru S.A.A., PE 3816 1086 563 137 COLOMBIA TELECOMUNICACIONES S.A. ESP, C 11172 955 112 69 Alestra, S. de R.L. de C.V., MX 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 1499 393 22 LINKdotNET-AS, EG 24835 1099 566 24 RAYA-AS, EG 36992 1057 1535 74 ETISALAT-MISR, EG 36903 875 452 97 MT-MPLS, MA 6713 599 1863 34 IAM-AS, MA 29571 557 68 11 ORANGE-COTE-IVOIRE, CI 37342 482 32 1 MOVITEL, MZ 36935 387 522 40 Vodafone-, EG 15399 374 45 10 WANANCHI-, KE 23889 373 231 15 MauritiusTelecom, MU 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 8151 6266 3291 596 Uninet S.A. de C.V., MX 12479 5925 1599 131 UNI2-AS, ES 7545 5305 666 617 TPG-INTERNET-AP TPG Telecom Limited, AU 4538 4623 4192 73 ERX-CERNET-BKB China Education and Rese 31334 4040 484 13 KABELDEUTSCHLAND-AS, DE 7155 4034 280 28 VIASAT-SP-BACKBONE, US 11492 3998 266 665 CABLEONE, US 16509 3868 7816 1701 AMAZON-02, US 39891 3776 203 20 ALJAWWALSTC-AS, SA 22773 3533 2971 151 ASN-CXA-ALL-CCI-22773-RDC, US Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggregation summary ----------------------------------------- ASN No of nets Net Savings Description 12479 5925 5794 UNI2-AS, ES 7545 5305 4688 TPG-INTERNET-AP TPG Telecom Limited, AU 4538 4623 4550 ERX-CERNET-BKB China Education and Research Net 31334 4040 4027 KABELDEUTSCHLAND-AS, DE 7155 4034 4006 VIASAT-SP-BACKBONE, US 39891 3776 3756 ALJAWWALSTC-AS, SA 22773 3533 3382 ASN-CXA-ALL-CCI-22773-RDC, US 11492 3998 3333 CABLEONE, US 7552 3332 3308 VIETEL-AS-AP Viettel Group, VN 6327 3376 3284 SHAW, CA Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Net Originated Transit AS Transit AS Name 62828 UNALLOCATED 8.21.130.0/24 3356 LEVEL3, US 393266 UNALLOCATED 8.23.52.0/24 174 COGENT-174, US 62485 UNALLOCATED 8.23.229.0/24 3356 LEVEL3, US 32985 UNALLOCATED 8.28.31.0/24 3356 LEVEL3, US 394936 UNALLOCATED 8.33.224.0/24 174 COGENT-174, US 27205 UNALLOCATED 8.38.16.0/21 6461 ZAYO-6461, US 27205 UNALLOCATED 8.38.16.0/22 32787 PROLEXIC-TECHNOLOGIES-DDOS-M 27205 UNALLOCATED 8.38.20.0/22 32787 PROLEXIC-TECHNOLOGIES-DDOS-M 14109 UNALLOCATED 8.38.252.0/24 3356 LEVEL3, US 23061 UNALLOCATED 8.39.119.0/24 3356 LEVEL3, US Complete listing at http://thyme.rand.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 http://thyme.rand.apnic.net/current/data-dsua Advertised Unallocated Addresses -------------------------------- Unassigned Network ASN Information AS Name 23.136.224.0/24 Origin: 15206 UNASSIGNED Transit: 174 COGENT-174, US 23.137.192.0/24 Origin: 31798 CANAD-86-31798, CA Transit: 174 COGENT-174, US 27.100.7.0/24 Origin: 56096 UNASSIGNED Transit: 45455 TH-2S1N-AP Two S One N Co Ltd, Internet 27.126.156.0/22 Origin: 55827 UNASSIGNED Transit: 9930 TTNET-MY TIME dotCom Berhad, MY 27.126.156.0/23 Origin: 55827 UNASSIGNED Transit: 9930 TTNET-MY TIME dotCom Berhad, MY 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:10 /9:11 /10:38 /11:98 /12:285 /13:579 /14:1158 /15:1914 /16:13390 /17:8149 /18:13860 /19:25771 /20:40400 /21:47521 /22:98553 /23:81432 /24:463267 /25:1289 /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 4908 5925 UNI2-AS, ES 31334 3885 4040 KABELDEUTSCHLAND-AS, DE 6327 3165 3376 SHAW, CA 11492 3128 3998 CABLEONE, US 7155 3125 4034 VIASAT-SP-BACKBONE, US 39891 2946 3776 ALJAWWALSTC-AS, SA 8551 2752 3292 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo 22773 2747 3533 ASN-CXA-ALL-CCI-22773-RDC, US 8151 2080 6266 Uninet S.A. de C.V., MX 30036 2059 2311 MEDIACOM-ENTERPRISE-BUSINESS, US Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1543 2:1157 3:30 4:19 5:3314 6:48 8:1379 9:1 12:1787 13:495 14:2242 15:74 16:9 17:285 18:79 20:58 23:3363 24:2646 25:4 27:2497 31:2986 32:103 35:40 36:933 37:3267 38:1913 39:323 40:132 41:3400 42:879 43:2100 44:196 45:13613 46:3671 47:276 49:1424 50:1219 51:87 52:1132 54:271 55:694 56:6 57:48 58:1882 59:1125 60:691 61:2200 62:2198 63:1947 64:5069 65:2315 66:4866 67:2832 68:1208 69:3798 70:1426 71:669 72:2774 74:2634 75:1436 76:667 77:2575 78:1951 79:2428 80:1857 81:1572 82:1244 83:1116 84:1220 85:2498 86:562 87:1729 88:1086 89:2694 90:314 91:7553 92:1484 93:2452 94:2606 95:3728 96:1016 97:337 98:966 99:962 100:85 101:1085 102:795 103:23249 104:3567 105:392 106:836 107:1964 108:704 109:3782 110:1780 111:1994 112:1572 113:1392 114:1517 115:1835 116:1788 117:2050 118:2102 119:1700 120:851 121:1040 122:2365 123:1887 124:1558 125:2034 128:1364 129:916 130:621 131:1825 132:761 133:299 134:1235 135:275 136:603 137:843 138:2184 139:987 140:596 141:887 142:878 143:1179 144:949 145:325 146:1478 147:1013 148:2064 149:1129 150:812 151:1280 152:1471 153:370 154:4671 155:892 156:3325 157:1084 158:765 159:1937 160:1763 161:1018 162:3034 163:781 164:1436 165:1247 166:544 167:1504 168:3691 169:495 170:4230 171:757 172:1883 173:2379 174:1036 175:1013 176:2643 177:4156 178:3015 179:1478 180:2193 181:2454 182:2845 183:1117 184:2400 185:16160 186:3752 187:2583 188:4059 189:2122 190:8302 191:1522 192:10243 193:7387 194:6031 195:4310 196:3416 197:1895 198:6126 199:5924 200:7171 201:5145 202:10422 203:10125 204:4549 205:3064 206:3256 207:3290 208:4010 209:4377 210:3999 211:1989 212:3199 213:3008 214:1171 215:54 216:5925 217:2355 218:874 219:604 220:1981 221:915 222:1002 223:1466 End of report

1 0

Contact at Disney+
by Romeo Czumbil 27 Feb '20

27 Feb '20

Can somebody contact me off-list from Disney+ please Thank you

2 1

idiot reponse
by Randy Bush 27 Feb '20

27 Feb '20

action(a)nanog.org seems to no longer exist. how should i be whining about the following? From: Electric Forest Festival <info(a)electricforestfestival.com> Subject: Forest HQ Has Received Your Message: Re: Hi-Rise Building Fiber Suggestions To: randy(a)psg.com Date: Wed, 26 Feb 2020 16:15:25 +0000 Electric Forest 2020 will take place on June 25-28, 2020. Forest HQ has received your email. Help save precious resources by reviewing the information below and looking up common questions in The Forest Frequently Asked Questions: Experience.ElectricForestFestival.com Please contact Festival Ticketing Support at 855-279-6941 for all issue regarding your purchase or for account troubleshooting. Electric Forest is sold out. Lyte is the only HQ endorsed way to get passes now that it’s sold out. To know when all things Electric Forest 2020 are happening sign up to the EF Newsletter. Happy Forest!

9 9