- Test - lists.nanog.org

Re: NTP for ASBRs?
by Scott Weeks 14 May '19

14 May '19

--- bryan(a)shout.net wrote: From: Bryan Holloway <bryan(a)shout.net> On 5/8/19 4:00 PM, Scott Weeks wrote: > --- job(a)ntt.net wrote: > From: Job Snijders <job(a)ntt.net> > > on this topic, i strongly recommend to operate all > devices in the Etc/UTC timezone, this makes > coordination with external entities much easier. > ---------------------------------------- > > > Yes, this! Holy crap I come upon a lot of networks > that don't do this and it's always painful. Now if only we could get rid of Daylight Saving Time ... ------------------------------------------ Luckily, Hawaii doesn't have that problem... https://en.wikipedia.org/wiki/Daylight_saving_time_in_the_United_States#Haw… But, that's the thing. One time. No trying to figure out who does DST and who doesn't. >From the above: =========================================== Arizona has not observed DST since 1967 Calif - in 2018, voters ratified a legislative plan for year-round daylight saving time, subject to congressional approval. On March 6, 2018, the Florida Senate approved the "Sunshine Protection Act" which would put Florida on permanent Daylight Saving Time year round...Congress would need to amend the existing 1966 federal law to allow the change. Hawaii has never observed daylight saving time ============================================ etc... scott

9 12

USA to Mexico IXP Equipment Recommendations
by NJ 14 May '19

14 May '19

Advice and/or suggestions wanted. Any input greatly appreciated. *Scenario:* We have run fiber from the USA to Mexico and have an exchange point in place. Our fiber connections are dark and therefore we can use any configuration we want on as many pairs as we want. Currently we have decided to light two 100gig connections and they are piping across the border already. We have 200gig going to Los Angeles (Wilshire Adjacent) and are looking to the mexico interested community of network engineers to identify how our peering point in Tijuana can be made to best service the networks in the region (and abroad if they build in). Our IXP is good, but we want to update/upgrade and put in a future-compatible robust solution instead of what we have in there now. We are an open IXP and are wondering how you would prefer to peer and what your equipment recommendations are and why. We're not afraid to spend (some) money but we do want it to not be complete overkill however should last at least 5 to 10 years before any upgrade would be required. Also to note, we are running our own bandwidth over the pipes as well so we would like to keep them separated. *Norm* A.A.S. R.A. Lifetime Member *Archaeology, Astronautics and SETI Research Association* SETI Project Lifetime Contributor

1 0

Re: Ownership of Routers on Both Ends of Transnational Links
by Pengxiong Zhu 13 May '19

13 May '19

Thanks again for your insightful responses! The case we discuss above is Chinese ISPs renting routers located outside China and the IPs belong to other ISPs. How about the case that the IP belongs to a Chinese ISP and is located in US(from RTT result), can we say it is very likely or definitely owned/operated by the Chinese ISP? Why would some ISP try to rent routers of Chinese ISP in US? For example, a traceroute from Ohio to an IP in China. Hop 17 and hop 18 should be located in US based on the RTT, and yet they belong to a Chinese AS(China Telecom). Does this mean that Chinese Telecom is managing these two hops? HOST: Loss% Snt Last Avg Best Wrst StDev 6. AS??? 100.65.11.97 0.0% 100 2.0 1.0 0.4 12.6 1.3 7. AS??? 52.93.15.238 0.0% 100 2.4 2.0 1.5 11.4 1.1 8. AS??? 52.93.14.134 0.0% 100 21.9 26.3 4.2 54.4 11.3 9. AS??? 52.93.14.119 0.0% 100 2.6 2.1 1.6 10.8 1.2 10. AS??? 100.91.27.86 0.0% 100 25.8 26.2 25.6 34.9 1.2 11. AS??? 54.239.42.197 0.0% 100 25.5 25.9 25.4 35.8 1.5 12. AS??? 100.91.4.218 0.0% 100 25.9 26.2 25.1 38.3 1.6 13. AS??? 100.91.4.217 0.0% 100 25.4 26.0 25.3 41.4 2.0 14. AS??? 100.91.5.85 0.0% 100 25.3 25.8 25.2 29.1 0.9 15. AS??? 54.239.103.86 0.0% 100 25.6 30.0 25.2 49.1 3.8 16. AS??? 54.239.103.77 0.0% 100 25.3 25.6 25.2 28.1 0.5 17. AS4134 218.30.53.1 0.0% 100 28.0 29.1 25.2 33.1 2.3 18. AS4134 202.97.50.21 0.0% 100 32.4 29.1 25.2 33.5 2.4 19. AS??? ??? 100.0 100 0.0 0.0 0.0 0.0 0.0 20. AS??? ??? 100.0 100 0.0 0.0 0.0 0.0 0.0 21. AS4134 202.97.94.121 0.0% 100 186.8 185.6 181.8 189.8 2.3 22. AS4816 119.147.222.6 0.0% 100 182.6 183.5 182.4 195.8 1.8 23. AS4816 183.2.182.130 0.0% 100 181.7 183.3 181.5 207.0 3.9 24. AS??? ??? 100.0 100 0.0 0.0 0.0 0.0 0.0 25. AS45102 116.251.113.158 0.0% 100 176.7 177.9 176.5 186.7 2.1 26. AS45102 116.251.115.141 0.0% 100 213.2 213.4 213.1 218.5 0.6 Best, Pengxiong Zhu Department of Computer Science and Engineering University of California, Riverside On Tue, Apr 16, 2019 at 7:37 PM Erik Sundberg <ESundberg(a)nitelusa.com> wrote: > May sure when you are dealing with transnational links to watch the > latency so you can tell when the link goes international. Just because you > are going from a US Network provider to China Telecom doesn't mean that > your not connecting to them in the united states. > > > > For example a traceroute from Denver to 27.29.128.1 which is an IP in > China Telecom's network. > > It's about 26ms between Denver and Los Angeles. Hop 5 to Hop 6 > > China Telecom connects to GTT in Los Angeles Hop7/8 > > On Hop 8 is in the United State and Hop 9 is across the pacific. Because > the latency goes from 31 ms to 183 ms. > > > Just something to keep in mind. > > > > Packets Pings > Host > Loss% Snt Last Avg Best Wrst StDev > 1. _gateway > 0.0% 14 1.0 1.2 1.0 2.8 0.5 > 2. te-0-0-26.ear2.den1.us.nitelusa.net > 0.0% 14 0.9 1.0 0.8 2.1 0.4 > 3. te-0-0-26.ear1.den1.us.nitelusa.net > 0.0% 14 1.1 1.6 1.1 2.9 0.7 > 4. te-0-0-1-0.cr1.den1.us.nitelusa.net > 0.0% 14 1.0 1.0 1.0 1.1 0.0 > 5. ae1-122.cr0-den2.ip4.gtt.net > 0.0% 14 0.5 1.2 0.3 6.9 2.0 > 6. et-0-0-47.cr3-lax2.ip4.gtt.net > 0.0% 14 26.5 26.4 26.2 26.7 0.2 > 7. as4134.lax20.ip4.gtt.net > 0.0% 14 27.7 28.7 26.8 30.1 1.1 > 8. 202.97.50.29 > 0.0% 14 31.4 30.6 26.8 34.1 2.4 > 9. 202.97.41.129 > 0.0% 14 183.3 187.1 183.3 190.8 2.4 > 10. 202.97.94.101 > 0.0% 14 187.9 188.6 186.1 211.2 6.8 > 11. 202.97.94.141 > 0.0% 13 177.8 180.7 177.2 184.2 2.3 > 12. 202.97.67.54 > 0.0% 13 199.5 201.2 197.4 205.1 2.6 > 13. 111.177.110.62 > 0.0% 13 205.9 206.3 205.9 208.2 0.7 > 14. 27.29.128.1 > 0.0% 13 202.6 202.8 202.5 203.9 0.4 > > > Erik Sundberg > > Sr. Network Engineer > > Nitel > > 350 N Orleans Street > > Suite 1300N > > Chicago, Il 60654 > > Desk: 773-661-5532 > > Cell: 708-710-7419 > > NOC: 866-892-0915 > > Email: esundberg(a)nitelusa.com > > web: www.nitelusa.com > > ------------------------------ > *From:* Zhiyun Qian <zhiyunq(a)cs.ucr.edu> > *Sent:* Tuesday, April 16, 2019 1:02:36 PM > *To:* Erik Sundberg > *Cc:* Pengxiong Zhu; Zhiyun Qian; Zhongjie Wang; Keyu Man > *Subject:* Re: Ownership of Routers on Both Ends of Transnational Links > > Erik, > > Thanks a lot for the information! This is extremely helpful. We are > conducting an analysis on performance/policy-related study on transnational > links. We are hoping to submit a paper soon. Will be glad to share all the > details once we have a draft! > > Best, > -Zhiyun > > > On Tue, Apr 16, 2019 at 10:35 AM Erik Sundberg <ESundberg(a)nitelusa.com> > wrote: > > CPE is usually ran by the customer. Some provider do offer managed routers > for a fee. Kinda like renting a cable modem from your provider. > > > What are your guys trying to accomplish or find out? > > Erik > > > > Erik Sundberg > Sr. Network Engineer > Nitel > 350 N Orleans Street > Suite 1300N > Chicago, Il 60654 > Desk: 773-661-5532 > Cell: 708-710-7419 > NOC: 866-892-0915 > Email: esundberg(a)nitelusa.com > web: www.nitelusa.com > > ------------------------------ > *From:* Pengxiong Zhu <pzhu011(a)ucr.edu> > *Sent:* Tuesday, April 16, 2019 12:32 PM > *To:* Erik Sundberg > *Cc:* Zhiyun Qian; Zhongjie Wang; Keyu Man > *Subject:* Re: Ownership of Routers on Both Ends of Transnational Links > > Thanks a lot! > > Are the Customer Devices managed by Telia or the customer? > > Best, > Pengxiong Zhu > Department of Computer Science and Engineering > University of California, Riverside > > > On Tue, Apr 16, 2019 at 7:43 AM Erik Sundberg <ESundberg(a)nitelusa.com> > wrote: > > I hope this helps with the breakdown for telia. > > > > > Telia i think is using /31's for there serial blocks now > > 62.115.170.56 (Telia Edge Rotuer) > > 62.115.170.57 (Customer Device) > > > > chinaunicom-ic-341501-sjo-b21.c.telia.net. > > > <Customername>-<CircuitID>-<POP>-<router>.c.telia.net > > > > Customer: ChinaUnicom > > Telia Circuit ID's are: ic-123456 > > POP: SJO (Airport code) > > Router: b21 > > Doamin: c.telia.net "Customer.telia.net" > > > > > Erik Sundberg > > Sr. Network Engineer > > Nitel > > 350 N Orleans Street > > Suite 1300N > > Chicago, Il 60654 > > Desk: 773-661-5532 > > Cell: 708-710-7419 > > NOC: 866-892-0915 > > Email: esundberg(a)nitelusa.com > > web: www.nitelusa.com > > ------------------------------ > *From:* NANOG <nanog-bounces(a)nanog.org> on behalf of Pengxiong Zhu < > pzhu011(a)ucr.edu> > *Sent:* Monday, April 15, 2019 11:36:45 PM > *To:* nanog(a)nanog.org > *Cc:* Keyu Man; Zhiyun Qian; Zhongjie Wang > *Subject:* Ownership of Routers on Both Ends of Transnational Links > > Howdy folks, > > We are a group of researchers at UC Riverside conducting some measurement > about transnational networks. In particular, we are interested in studying > the ownership of routers on the two sides of transnational links. > > We have some concrete questions which we hope someone can shed some light > on. Basically when we send packets from US/Canada to China, through > traceroute and the RTT of each hop, we can locate the last hop in the US > before the packets enter China (*there is a large jump of RTT of 100+ms > from this hop onwards*). Oftentimes the ownership of such routers is > ambiguous. > > These hops whose IPs seem to belong to US or European ISPs (*according to > BGP info*) but their reverse DNS names have *chinaunicom* in it, which is > a Chinese ISP. > AS1299 Telia Company AB > 62.115.170.57 name = chinaunicom-ic-341501-sjo-b21.c.telia.net. > 62.115.33.230 name = chinaunicom-ic-302366-las-bb1.c.telia.net. > 213.248.73.190 name = chinaunicom-ic-127288-sjo-b21.c.telia.net. > > AS701 Verizon Business > 152.179.103.254 name = chinaunicom-gw.customer.alter.net. > > While the following routers, they don't have a reverse DNS name at all, > which seem to be uncommon if they were managed by US or European ISPs but > quite common for Chinese ISPs. > AS6453 TATA COMMUNICATIONS (AMERICA) INC > 63.243.205.90 > 66.110.59.118 > > Can anyone confirm that these are indeed managed by the Chinese ISPs (even > though they are physically located in the US according to the traceroute > and RTT analysis)? > > > Best, > Pengxiong Zhu > Department of Computer Science and Engineering > University of California, Riverside > > ------------------------------ > > CONFIDENTIALITY NOTICE: This e-mail transmission, and any documents, files > or previous e-mail messages attached to it may contain confidential > information that is legally privileged. If you are not the intended > recipient, or a person responsible for delivering it to the intended > recipient, you are hereby notified that any disclosure, copying, > distribution or use of any of the information contained in or attached to > this transmission is STRICTLY PROHIBITED. If you have received this > transmission in error please notify the sender immediately by replying to > this e-mail. You must destroy the original transmission and its attachments > without reading or saving in any manner. Thank you. > > > ------------------------------ > > CONFIDENTIALITY NOTICE: This e-mail transmission, and any documents, files > or previous e-mail messages attached to it may contain confidential > information that is legally privileged. If you are not the intended > recipient, or a person responsible for delivering it to the intended > recipient, you are hereby notified that any disclosure, copying, > distribution or use of any of the information contained in or attached to > this transmission is STRICTLY PROHIBITED. If you have received this > transmission in error please notify the sender immediately by replying to > this e-mail. You must destroy the original transmission and its attachments > without reading or saving in any manner. Thank you. > > > ------------------------------ > > CONFIDENTIALITY NOTICE: This e-mail transmission, and any documents, files > or previous e-mail messages attached to it may contain confidential > information that is legally privileged. If you are not the intended > recipient, or a person responsible for delivering it to the intended > recipient, you are hereby notified that any disclosure, copying, > distribution or use of any of the information contained in or attached to > this transmission is STRICTLY PROHIBITED. If you have received this > transmission in error please notify the sender immediately by replying to > this e-mail. You must destroy the original transmission and its attachments > without reading or saving in any manner. Thank you. >

3 4

Mostly name and shame...
by bzs＠theworld.com 13 May '19

13 May '19

Why has OUTLOOK.COM allowed daily dictionary spammers to operate from their net, FOR YEARS? It can't be that hard to detect and block. 2019-05-13T17:00:18.194103-04:00 pcls6 sendmail[14128]: NOUSER: proctor5 relay=mail-eopbgr740053.outbound.protection.outlook.com [40.107.74.53] 2019-05-13T17:00:18.444848-04:00 pcls6 sendmail[14128]: NOUSER: proctor4 relay=mail-eopbgr740053.outbound.protection.outlook.com [40.107.74.53] 2019-05-13T17:00:18.698977-04:00 pcls6 sendmail[14128]: NOUSER: proctor2 relay=mail-eopbgr740053.outbound.protection.outlook.com [40.107.74.53] 2019-05-13T17:00:18.952548-04:00 pcls6 sendmail[14128]: NOUSER: proctor10 relay=mail-eopbgr740053.outbound.protection.outlook.com [40.107.74.53] 2019-05-13T17:10:27.523597-04:00 pcls6 sendmail[19471]: NOUSER: proctor6 relay=mail-eopbgr810043.outbound.protection.outlook.com [40.107.81.43] 2019-05-13T17:10:27.775984-04:00 pcls6 sendmail[19471]: NOUSER: proctor5 relay=mail-eopbgr810043.outbound.protection.outlook.com [40.107.81.43] 2019-05-13T17:10:28.029744-04:00 pcls6 sendmail[19471]: NOUSER: proctor4 relay=mail-eopbgr810043.outbound.protection.outlook.com [40.107.81.43] 2019-05-13T17:10:28.283016-04:00 pcls6 sendmail[19471]: NOUSER: proctor2 relay=mail-eopbgr810043.outbound.protection.outlook.com [40.107.81.43] 2019-05-13T17:10:28.537106-04:00 pcls6 sendmail[19471]: NOUSER: proctor10 relay=mail-eopbgr810043.outbound.protection.outlook.com [40.107.81.43] 2019-05-13T17:30:47.045677-04:00 pcls6 sendmail[31621]: NOUSER: proctor6 relay=mail-eopbgr810072.outbound.protection.outlook.com [40.107.81.72] 2019-05-13T17:30:47.299131-04:00 pcls6 sendmail[31621]: NOUSER: proctor5 relay=mail-eopbgr810072.outbound.protection.outlook.com [40.107.81.72] 2019-05-13T17:30:47.552492-04:00 pcls6 sendmail[31621]: NOUSER: proctor4 relay=mail-eopbgr810072.outbound.protection.outlook.com [40.107.81.72] 2019-05-13T17:30:47.804233-04:00 pcls6 sendmail[31621]: NOUSER: proctor2 relay=mail-eopbgr810072.outbound.protection.outlook.com [40.107.81.72] 2019-05-13T17:30:48.056635-04:00 pcls6 sendmail[31621]: NOUSER: proctor10 relay=mail-eopbgr810072.outbound.protection.outlook.com [40.107.81.72] 2019-05-13T17:35:05.867715-04:00 pcls6 sendmail[1352]: NOUSER: proctor9 relay=mail-eopbgr50127.outbound.protection.outlook.com [40.107.5.127] 2019-05-13T17:35:06.120021-04:00 pcls6 sendmail[1352]: NOUSER: proctor7 relay=mail-eopbgr50127.outbound.protection.outlook.com [40.107.5.127] 2019-05-13T17:35:06.372603-04:00 pcls6 sendmail[1352]: NOUSER: proctor6 relay=mail-eopbgr50127.outbound.protection.outlook.com [40.107.5.127] 2019-05-13T17:35:06.627583-04:00 pcls6 sendmail[1352]: NOUSER: proctor5 relay=mail-eopbgr50127.outbound.protection.outlook.com [40.107.5.127] 2019-05-13T17:35:06.885218-04:00 pcls6 sendmail[1352]: NOUSER: proctor relay=mail-eopbgr50127.outbound.protection.outlook.com [40.107.5.127] etc etc etc etc. -- -Barry Shein Software Tool & Die | bzs(a)TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: +1 617-STD-WRLD | 800-THE-WRLD The World: Since 1989 | A Public Information Utility | *oo*

1 0

Seeking Feedback on Mitigation of New BGP-driven Attack
by Jared Smith 11 May '19

11 May '19

Hello, Our research lab at the University of Tennessee (volsec.org) has recently completed a study on channeling link-flooding attack (transit link DDoS) flows via BGP poisoning: the Maestro attack. We are seeking feedback on mitigation (see below). A brief summary from the abstract: "Executed from a compromised or malicious Autonomous System (AS), Maestro advertises specific-prefix routes poisoned for selected ASes to collapse inbound traffic paths onto a single target link. A greedy heuristic fed by publicly available AS relationship data iteratively builds the set of ASes to poison. Given a compromised BGP speaker with advantageous positioning relative to the target link in the Internet topology, an adversary can expect to enhance flow density by more than 30%. For a large botnet (e.g., Mirai), the bottom line result is augmenting a DDoS by more than a million additional infected hosts. Interestingly, the size of the adversary-controlled AS plays little role in this amplification effect. Devastating attacks on core links can be executed by small, resource-limited ASes." We are seeking feedback from operators on the attack and the proposed mitigations we have identified. While we have worked with our campus BGP operators, we are reaching out to the broader community for additional insights. Other than general notes/comments, we have two specific questions that we would like to include feedback for in the final paper soon to be submitted: 1) Do you already filter poisoned/path prepend advertisements? This would mitigate the attack. 2) After seeing this attack, would you consider adding poison filtering or some other Day mitigation? The preprint is available at: tiny.utk.edu/maestro. See Section 7 on defenses. Please reply with any thoughts. Thank you in advance for comments, insight, and general feedback. Best, Tyler McDaniel, Jared Smith, and Max Schuchard UT Computer Security Lab volsec.org

3 2

Call for Participation -- ICANN DNSSEC Workshop at ICANN65, Marrakech, Morocco.
by Jacques Latour 11 May '19

11 May '19

Call for Participation -- ICANN DNSSEC Workshop at ICANN65, Marrakech, Morocco. The DNSSEC Deployment Initiative and the Internet Society Deploy360 Programme, in cooperation with the ICANN Security and Stability Advisory Committee (SSAC), are planning a DNSSEC Workshop during the ICANN65 meeting held from 24-27 June 2019 in Marrakech, Morocco. The DNSSEC Workshop has been a part of ICANN meetings for several years and has provided a forum for both experienced and new people to meet, present and discuss current and future DNSSEC deployments. For reference, the most recent session was held at the ICANN Community Forum in Kobe, Japan on 13 March 2019. The presentations and transcripts are available at: https://64.schedule.icann.org/meetings/961937, https://64.schedule.icann.org/meetings/961938, and https://64.schedule.icann.org/meetings/961939. The DNSSEC Workshop Program Committee is developing a 3-hour program. Proposals will be considered for the following topic areas and included if space permits. In addition, we welcome suggestions for additional topics either for inclusion in the ICANN65 workshop, or for consideration for future workshops. 1. DNSSEC Activities Panel (Regional and global) For this panel, we are seeking participation from those who have been involved in DNSSEC deployment in the region and also from those who have not deployed DNSSEC but who have a keen interest in the challenges and benefits of deployment, including Root Key Signing Key (KSK) Rollover activities. Now that DNSSEC has become an operational norm for many registries, registrars, and ISPs, what have we learned about how we manage DNSSEC? What is the best practice around key rollovers? How often do you review your disaster recovery procedures? Is there operational familiarity within your customer support teams? What operational statistics have we gathered about DNSSEC? Are there experiences being documented in the form of best practices, or something similar, for transfer of signed zones? If you have a specific concern about the Root Key Rollover, or believe you have a method or solution to help address impacts, we would like to hear from you. 2. DNSSEC Deployment Challenges The program committee is seeking input from those that are interested in implementation of DNSSEC but have general or particular concerns with DNSSEC. In particular, we are seeking input from individuals that would be willing to participate in a panel that would discuss questions of the nature: - Are there any policies directly or indirectly impeding your DNSSEC deployment? (RRR model, CDS/CDNSKEY automation) - What are your most significant concerns with DNSSEC, e.g., complexity, training, implementation, operation or something else? - What do you expect DNSSEC to do for you and what doesn't it do? - What do you see as the most important trade-offs with respect to doing or not doing DNSSEC? We are interested in presentations related to any aspect of DNSSEC such as zone signing, DNS response validation, applications use of DNSSEC, registry/registrar DNSSEC activities, etc. In addition, we welcome suggestions for additional topics. If you are interested in participating, please send a brief (1-2 sentence) description of your proposed presentation to dnssec-marrakech(a)isoc.org<mailto:dnssec-marrakech@isoc.org> by **Friday, 17 May 2019** Thank you, Jacques On behalf of the DNSSEC Workshop Program Committee: Mark Elkins, DNS/ZACR Jean Robert Hountomey, AfricaCERT Jacques Latour, .CA Xiaodong Lee, Chinese Academy of Sciences (CAS) Russ Mundy, Parsons Ondrej Filip, CZ.NIC Yoshiro Yoneya, JPRS Dan York, Internet Society

1 0

Weekly Routing Table Report
by cscora＠apnic.net 10 May '19

10 May '19

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 11 May, 2019 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 753151 Prefixes after maximum aggregation (per Origin AS): 288263 Deaggregation factor: 2.61 Unique aggregates announced (without unneeded subnets): 360475 Total ASes present in the Internet Routing Table: 64188 Prefixes per ASN: 11.73 Origin-only ASes present in the Internet Routing Table: 55224 Origin ASes announcing only one prefix: 23795 Transit ASes present in the Internet Routing Table: 8964 Transit-only ASes present in the Internet Routing Table: 270 Average AS path length visible in the Internet Routing Table: 4.4 Max AS path length visible: 34 Max AS path prepend of ASN ( 8697) 27 Prefixes from unregistered ASNs in the Routing Table: 24 Number of instances of unregistered ASNs: 28 Number of 32-bit ASNs allocated by the RIRs: 26896 Number of 32-bit ASNs visible in the Routing Table: 22003 Prefixes from 32-bit ASNs in the Routing Table: 97673 Number of bogon 32-bit ASNs visible in the Routing Table: 21 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 259 Number of addresses announced to Internet: 2850178944 Equivalent to 169 /8s, 226 /16s and 71 /24s Percentage of available address space announced: 77.0 Percentage of allocated address space announced: 77.0 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 99.2 Total number of prefixes smaller than registry allocations: 252122 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 203409 Total APNIC prefixes after maximum aggregation: 59122 APNIC Deaggregation factor: 3.44 Prefixes being announced from the APNIC address blocks: 199716 Unique aggregates announced from the APNIC address blocks: 82255 APNIC Region origin ASes present in the Internet Routing Table: 9722 APNIC Prefixes per ASN: 20.54 APNIC Region origin ASes announcing only one prefix: 2722 APNIC Region transit ASes present in the Internet Routing Table: 1448 Average APNIC Region AS path length visible: 4.5 Max APNIC Region AS path length visible: 26 Number of APNIC region 32-bit ASNs visible in the Routing Table: 4726 Number of APNIC addresses announced to Internet: 773680000 Equivalent to 46 /8s, 29 /16s and 107 /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-139577 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: 224174 Total ARIN prefixes after maximum aggregation: 104803 ARIN Deaggregation factor: 2.14 Prefixes being announced from the ARIN address blocks: 223364 Unique aggregates announced from the ARIN address blocks: 105536 ARIN Region origin ASes present in the Internet Routing Table: 18471 ARIN Prefixes per ASN: 12.09 ARIN Region origin ASes announcing only one prefix: 6857 ARIN Region transit ASes present in the Internet Routing Table: 1899 Average ARIN Region AS path length visible: 3.9 Max ARIN Region AS path length visible: 24 Number of ARIN region 32-bit ASNs visible in the Routing Table: 2701 Number of ARIN addresses announced to Internet: 1077912448 Equivalent to 64 /8s, 63 /16s and 163 /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, 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: 207169 Total RIPE prefixes after maximum aggregation: 98242 RIPE Deaggregation factor: 2.11 Prefixes being announced from the RIPE address blocks: 203505 Unique aggregates announced from the RIPE address blocks: 120752 RIPE Region origin ASes present in the Internet Routing Table: 26052 RIPE Prefixes per ASN: 7.81 RIPE Region origin ASes announcing only one prefix: 11566 RIPE Region transit ASes present in the Internet Routing Table: 3718 Average RIPE Region AS path length visible: 4.6 Max RIPE Region AS path length visible: 34 Number of RIPE region 32-bit ASNs visible in the Routing Table: 8100 Number of RIPE addresses announced to Internet: 719259008 Equivalent to 42 /8s, 223 /16s and 5 /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: 96963 Total LACNIC prefixes after maximum aggregation: 21780 LACNIC Deaggregation factor: 4.45 Prefixes being announced from the LACNIC address blocks: 98376 Unique aggregates announced from the LACNIC address blocks: 42592 LACNIC Region origin ASes present in the Internet Routing Table: 8385 LACNIC Prefixes per ASN: 11.73 LACNIC Region origin ASes announcing only one prefix: 2216 LACNIC Region transit ASes present in the Internet Routing Table: 1540 Average LACNIC Region AS path length visible: 5.1 Max LACNIC Region AS path length visible: 31 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 5924 Number of LACNIC addresses announced to Internet: 173985536 Equivalent to 10 /8s, 94 /16s and 207 /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: 21411 Total AfriNIC prefixes after maximum aggregation: 4297 AfriNIC Deaggregation factor: 4.98 Prefixes being announced from the AfriNIC address blocks: 27931 Unique aggregates announced from the AfriNIC address blocks: 9104 AfriNIC Region origin ASes present in the Internet Routing Table: 1272 AfriNIC Prefixes per ASN: 21.96 AfriNIC Region origin ASes announcing only one prefix: 434 AfriNIC Region transit ASes present in the Internet Routing Table: 244 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: 552 Number of AfriNIC addresses announced to Internet: 104790272 Equivalent to 6 /8s, 62 /16s and 249 /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 7545 4740 546 553 TPG-INTERNET-AP TPG Telecom Limited, AU 4538 3197 4192 74 ERX-CERNET-BKB China Education and Rese 7552 3159 1443 27 VIETEL-AS-AP Viettel Group, VN 45899 3032 1741 111 VNPT-AS-VN VNPT Corp, VN 9808 2938 9043 62 CMNET-GD Guangdong Mobile Communication 9829 2734 1496 551 BSNL-NIB National Internet Backbone, IN 4766 2543 11120 760 KIXS-AS-KR Korea Telecom, KR 9394 2155 4882 26 CTTNET China TieTong Telecommunications 4755 2138 429 184 TATACOMM-AS TATA Communications formerl 9498 2052 427 170 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 6327 3656 1325 93 SHAW - Shaw Communications Inc., CA 11492 3651 238 584 CABLEONE - CABLE ONE, INC., US 7155 3566 280 25 VIASAT-SP-BACKBONE - ViaSat,Inc., US 22773 3399 2974 157 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 16509 2606 5529 1153 AMAZON-02 - Amazon.com, Inc., US 16625 2432 1330 1843 AKAMAI-AS - Akamai Technologies, Inc., 30036 2160 350 176 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom 20115 2146 2747 527 CHARTER-20115 - Charter Communications, 18566 2101 405 108 MEGAPATH5-US - MegaPath Corporation, US 5650 2086 3074 1462 FRONTIER-FRTR - Frontier Communications 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 5430 1629 140 UNI2-AS, ES 39891 3778 203 20 ALJAWWALSTC-AS, SA 8551 3219 378 45 BEZEQ-INTERNATIONAL-AS Bezeqint Interne 20940 2670 530 1926 AKAMAI-ASN1, US 12389 2243 2222 642 ROSTELECOM-AS, RU 34984 2078 343 541 TELLCOM-AS, TR 9121 1668 1692 18 TTNET, TR 13188 1601 100 47 TRIOLAN, UA 9009 1451 151 787 M247, GB 8402 1230 545 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 8151 5754 3359 592 Uninet S.A. de C.V., MX 10620 3424 534 418 Telmex Colombia S.A., CO 11830 2708 384 34 Instituto Costarricense de Electricidad 7303 1474 1015 248 Telecom Argentina S.A., AR 28573 1358 2238 198 CLARO S.A., BR 6503 1263 433 53 Axtel, S.A.B. de C.V., MX 6147 1200 377 30 Telefonica del Peru S.A.A., PE 3816 1086 523 143 COLOMBIA TELECOMUNICACIONES S.A. ESP, C 13999 968 512 241 Mega Cable, S.A. de C.V., MX 11172 938 144 62 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 1175 393 21 LINKdotNET-AS, EG 37611 906 107 9 Afrihost, ZA 24835 888 648 21 RAYA-AS, EG 36992 836 1536 69 ETISALAT-MISR, EG 36903 827 416 126 MT-MPLS, MA 8452 684 1731 19 TE-AS TE-AS, EG 29571 511 68 11 ORANGE-COTE-IVOIRE, CI 37492 470 470 57 ORANGE-, TN 15706 421 32 6 Sudatel, SD 37342 420 32 1 MOVITEL, MZ 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 5754 3359 592 Uninet S.A. de C.V., MX 12479 5430 1629 140 UNI2-AS, ES 7545 4740 546 553 TPG-INTERNET-AP TPG Telecom Limited, AU 39891 3778 203 20 ALJAWWALSTC-AS, SA 6327 3656 1325 93 SHAW - Shaw Communications Inc., CA 11492 3651 238 584 CABLEONE - CABLE ONE, INC., US 7155 3566 280 25 VIASAT-SP-BACKBONE - ViaSat,Inc., US 10620 3424 534 418 Telmex Colombia S.A., CO 22773 3399 2974 157 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 8551 3219 378 45 BEZEQ-INTERNATIONAL-AS Bezeqint Interne Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 12479 5430 5290 UNI2-AS, ES 7545 4740 4187 TPG-INTERNET-AP TPG Telecom Limited, AU 39891 3778 3758 ALJAWWALSTC-AS, SA 6327 3656 3563 SHAW - Shaw Communications Inc., CA 7155 3566 3541 VIASAT-SP-BACKBONE - ViaSat,Inc., US 22773 3399 3242 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 8551 3219 3174 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo 7552 3159 3132 VIETEL-AS-AP Viettel Group, VN 4538 3197 3123 ERX-CERNET-BKB China Education and Research Net 11492 3651 3067 CABLEONE - CABLE ONE, INC., 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 230105 UNALLOCATED 38.110.79.0/24 23015 CMC180-TOR-AS - Cambridge Merc 266842 UNALLOCATED 45.238.156.0/22 265680 HNTELCO S.A, HN 65550 DOCUMENT 81.8.34.0/24 15924 BORUSANTELEKOM-AS, TR 65550 DOCUMENT 81.8.35.0/24 15924 BORUSANTELEKOM-AS, TR 65549 DOCUMENT 117.239.163.0/24 65544 UNKNOWN 64339 UNALLOCATED 143.0.108.0/22 18747 IFX18747 - IFX Corporation, US 65551 DOCUMENT 149.165.246.0/24 19782 INDIANAGIGAPOP - Indiana Unive 64355 UNALLOCATED 156.40.196.0/24 30387 NIH-NET-NCCS - National Instit 64011 UNALLOCATED 166.133.128.0/18 20057 ATT-MOBILITY-LLC-AS20057 - AT& 64011 UNALLOCATED 166.133.192.0/18 20057 ATT-MOBILITY-LLC-AS20057 - AT& Complete listing at http://thyme.rand.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 23.247.128.0/17 53889 MICFO - Micfo, LLC., US 23.247.197.0/24 53889 MICFO - Micfo, LLC., US 27.100.7.0/24 56096 UNKNOWN 27.126.156.0/22 55827 UNKNOWN 27.126.156.0/23 55827 UNKNOWN 27.126.158.0/23 55827 UNKNOWN 41.76.136.0/22 37500 -Reserved AS-, ZZ 41.76.140.0/22 37500 -Reserved AS-, ZZ 41.78.92.0/22 14988 BTC-GATE1, BW 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:12 /9:10 /10:37 /11:100 /12:295 /13:571 /14:1131 /15:1911 /16:13328 /17:8004 /18:13977 /19:25784 /20:40294 /21:46929 /22:93824 /23:76497 /24:429533 /25:914 /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 4362 5430 UNI2-AS, ES 6327 3431 3656 SHAW - Shaw Communications Inc., CA 39891 2946 3778 ALJAWWALSTC-AS, SA 7155 2930 3566 VIASAT-SP-BACKBONE - ViaSat,Inc., US 11492 2858 3651 CABLEONE - CABLE ONE, INC., US 8551 2673 3219 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo 22773 2638 3399 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 11830 2053 2708 Instituto Costarricense de Electricidad y Telec 18566 1996 2101 MEGAPATH5-US - MegaPath Corporation, US 30036 1910 2160 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom Communi Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1599 2:1018 3:6 4:21 5:3161 6:47 7:1 8:1303 9:1 12:1802 13:340 14:1996 15:37 16:4 17:262 18:58 20:52 23:2696 24:2501 25:2 27:2454 31:1974 32:100 35:36 36:858 37:3025 38:1738 39:293 40:122 41:3286 42:780 43:2038 44:149 45:7712 46:3284 47:257 49:1364 50:1106 51:322 52:1012 54:282 55:704 56:6 57:44 58:1734 59:1060 60:502 61:2177 62:2188 63:1827 64:4966 65:2202 66:4827 67:2775 68:1161 69:3536 70:1360 71:625 72:2623 74:2746 75:1257 76:556 77:1781 78:1817 79:2281 80:1809 81:1504 82:1126 83:953 84:1132 85:2288 86:524 87:1550 88:1051 89:2650 90:217 91:6565 92:1395 93:2493 94:2513 95:3264 96:944 97:344 98:958 99:751 100:87 101:1159 102:567 103:21154 104:3561 105:257 106:782 107:1786 108:695 109:3747 110:1661 111:2055 112:1503 113:1405 114:1233 115:1712 116:1748 117:1909 118:2102 119:1627 120:1025 121:1043 122:2360 123:1710 124:1495 125:1949 128:1253 129:831 130:538 131:1822 132:787 133:222 134:1094 135:241 136:571 137:761 138:2060 139:877 140:645 141:882 142:795 143:1055 144:891 145:496 146:1266 147:838 148:1705 149:912 150:791 151:1020 152:1063 153:333 154:3012 155:919 156:1638 157:989 158:658 159:1951 160:1605 161:924 162:2756 163:814 164:1201 165:1590 166:431 167:1415 168:3334 169:874 170:4124 171:577 172:1575 173:2203 174:1044 175:927 176:2320 177:4224 178:2535 179:1395 180:2093 181:2421 182:2689 183:1113 184:2054 185:15139 186:3705 187:2487 188:2918 189:1973 190:8229 191:1599 192:10062 193:6663 194:5449 195:4119 196:3099 197:1791 198:5920 199:5987 200:7149 201:5123 202:10449 203:10089 204:4551 205:3037 206:3240 207:3240 208:3946 209:4239 210:3931 211:2020 212:3103 213:2950 214:1085 215:55 216:5926 217:2220 218:877 219:596 220:1862 221:968 222:989 223:1377 End of report

1 0

Re: NTP for ASBRs?
by Scott Weeks 10 May '19

10 May '19

--- job(a)ntt.net wrote: From: Job Snijders <job(a)ntt.net> on this topic, i strongly recommend to operate all devices in the Etc/UTC timezone, this makes coordination with external entities much easier. ---------------------------------------- Yes, this! Holy crap I come upon a lot of networks that don't do this and it's always painful. scott

7 8

Routing issues to AWS environment.
by Curt Rice 09 May '19

09 May '19

Hi are there any AWS engineers out there? We are seeing routing problems between NTT and AWS in Ashburn, Va and would like to find out which side is having the problem. Thanks, Curt

6 6

FW: Sprint Operations
by Stockdale, Tom D [CTO] 09 May '19

09 May '19

James, Can you send me some specifics so I can try and figure out how to help with your concerns? V/r, Tom From: Fiumano, Michael F [CTO] Subject: FW: Sprint Operations Tom, Stephanie, Is this something you could help with? Or fwd in the right direction? Thanks, Michael Fiumano Manager, Sprint Internet & WAN Engineering From: NANOG [mailto:nanog-bounces@nanog.org] On Behalf Of James Breeden Sent: Thursday, May 9, 2019 11:05 AM To: nanog(a)nanog.org<mailto:nanog@nanog.org> Subject: Sprint Operations CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. Hello, If anyone from Sprint Mobile operations is on list, could you reach out to me off list? Having issues with some ip ranges properly communicating with your WiFi Calling and SMS over IP hosts. James Sent via the Samsung Galaxy Note9, an AT&T 5G Evolution capable smartphone

1 0