- Test - lists.nanog.org

Apple Contact
by Ryan Gard 11 May '18

11 May '18

Hello, If someone from Apple could contact me off list. Need to resolve some Geo-location issues. Thanks! -- Ryan Gard

1 0

Unusually High traffic from Akamai/Oracle - public-yum.oracle.com
by James Stahr 10 May '18

10 May '18

Hi, Since I'm not a customer of either organization, I'm reaching out to NANOG for a contact and perhaps others may also be experiencing similar symptoms over the past 3-4 weeks. The situation appears to be that customers of ours have Oracle Linux and when they attempt to download updates, their traffic goes through the roof for hours on end. While researching this phenomenon, I found this discussion which coincides with the traffic I've seen, however there is no mention of excessive traffic resulting from this "corruption" nor have their been any additional reports: https://community.oracle.com/thread/4138810 Currently, I have two customer environments which are hitting about ~2Gb/s when normally their traffic levels are nearly zero. At first I thought it was an isolated incident but then we observed the same issue with another customer. All of this traffic is coming from 23.35.204.188:80, which belongs to Akamai. Since that's somewhat of a dead end, we examined the hosts which are requesting the data from Akamai and found that they are all Oracle Linux boxes and it's a yum process on Oracle Linux which appears to be repeatedly downloading the same content for hours on end: [root@xyzzy noc]# netstat -plutan | grep :80 tcp 0 0 172.16.122.112:14272 23.35.204.188:80 ESTABLISHED 58880/python [root@xyzzy noc]# ps auxww | grep python root 41015 0.0 0.3 401940 52044 ? S Apr30 0:02 /usr/bin/python2 /usr/share/system-config-lvm/system-config-lvm.py root 58880 59.7 1.0 479680 164140 ? R 18:24 27:18 /usr/bin/python /usr/share/PackageKit/helpers/yum/yumBackend.py get-updates none I can only assume that the data being downloaded is corrupt as this multiple hour download does not consume any disk space and because the file(s) are repeatedly downloaded, the logic behind the yum routines are also at fault for 1TB of I don't expect anyone at Akamai to reach out to me since they are simply the middle man here, but I'm hoping that someone at Oracle will because the cost to Oracle for Akamai to deliver this junk traffic is not zero and I have a hard time seeing how this issue is isolated to our network. I'd also be interested to hear from anyone else who has been seeing traffic spikes from public-yum.oracle.com. -James Stahr

3 2

Wave service providers in Hong Kong metro area
by cgreco＠mbay.net 10 May '18

10 May '18

Hi Folks, Can anyone recommend wave providers on the Hong Kong area? I need to reach between two colo facilities there. Feel free to ping me off-list. Best, -Chuck

3 2

Contact Phase Layer AS51852
by Marco Paesani 10 May '18

10 May '18

Hi, I need contact with AS51852 about peering session at DE-CIX and AMS-IX. Thanks ! Kind regards, Marco Paesani Skype: mpaesani Mobile: +39 348 6019349 Success depends on the right choice ! Email: marco(a)paesani.it

1 0

Intuit - IP Block - Connection Timed Out
by Ryan Hamel 09 May '18

09 May '18

Greetings, If someone from Intuit can contact me off list, I would highly appreciate it. We have a client that is not able to access QuickBooks Online from one of our specific IP blocks. The IP for https://qbo.intuit.com/ responds to ping, but any web request results in a connection timed out. Thanks! -- Ryan Hamel ryan.hamel(a)quadranet.com | +1 (888) 578-2372 QuadraNet, Inc. | Dedicated Servers, Colocation, Cloud

1 0

Catalyst 4500 listening on TCP 6154 on all interfaces
by frederic.jutzet＠sig-telecom.net 09 May '18

09 May '18

Hi, We have Cat 4500 series on SUP7L-E with IOS/XE 03.06.02.E/152(2).E2 which have TCP port 6154 listening on all interfaces. Any idea what it could be ? #show tcp brief all TCB Local Address Foreign Address (state) ... 5A529430 0.0.0.0.6154 <<<<<<<<<<<<<<<< #show tcp tcb 5A529430 Connection state is LISTEN, I/O status: 1, unread input bytes: 0 Connection is ECN Disabled, Mininum incoming TTL 0, Outgoing TTL 255 Local host: 0.0.0.0, Local port: 6154 Foreign host: UNKNOWN, Foreign port: 0 Connection tableid (VRF): 1 Maximum output segment queue size: 50 Enqueued packets for retransmit: 0, input: 0 mis-ordered: 0 (0 bytes) Event Timers (current time is 0xF58354): Timer Starts Wakeups Next Retrans 0 0 0x0 TimeWait 0 0 0x0 AckHold 0 0 0x0 SendWnd 0 0 0x0 KeepAlive 0 0 0x0 GiveUp 0 0 0x0 PmtuAger 0 0 0x0 DeadWait 0 0 0x0 Linger 0 0 0x0 ProcessQ 0 0 0x0 iss: 0 snduna: 0 sndnxt: 0 irs: 0 rcvnxt: 0 sndwnd: 0 scale: 0 maxrcvwnd: 4128 rcvwnd: 4128 scale: 0 delrcvwnd: 0 SRTT: 0 ms, RTTO: 2000 ms, RTV: 2000 ms, KRTT: 0 ms minRTT: 60000 ms, maxRTT: 0 ms, ACK hold: 200 ms uptime: 0 ms, Sent idletime: 0 ms, Receive idletime: 0 ms Status Flags: gen tcbs Option Flags: VRF id set, keepalive running, nagle, Reuse local address Retrans timeout IP Precedence value : 0 Datagrams (max data segment is 516 bytes): Rcvd: 0 (out of order: 0), with data: 0, total data bytes: 0 Sent: 0 (retransmit: 0, fastretransmit: 0, partialack: 0, Second Congestion: 0), with data: 0, total data bytes: 0 Packets received in fast path: 0, fast processed: 0, slow path: 0 fast lock acquisition failures: 0, slow path: 0 TCP Semaphore 0x5BEB9B10 FREE (The command "show control-plane host open-ports" is not available on this platform/code) I also think that if it would be a local socket for internal process communication, it would be 127.0.0.1:6154 instead of 0.0.0.0:6154. So this is listening on all interfaces, virtuals and physicals and seam not to be for internal internal process communication. Fred

9 11

REMINDER: Call for Participation -- ICANN DNSSEC Workshop at ICANN62 Panama City, Panama - June 25, 2018
by Jacques Latour 09 May '18

09 May '18

Hi All! ****Apologies there was some earlier problems with the mailing list so if you have submitted prior to today we may have not received the request. Would you please resubmit to the list and we will be sure to get a response to you as soon as possible? Thank you. **** The next ICANN DNSSEC Workshop will be on Monday, June 25, 2018 in Panama City, Panama. If you are interested in participating, please send a brief (1-2 sentence) description of your proposed presentation to dnssec-panamacity(a)isoc.org<mailto:dnssec-panamacity@isoc.org> by **18 May 2018** The committee is also thinking of having a panel on the Post-KSK-Rollover. We’d like to see if anyone from the DNSSEC community can identify ways that can help end users have a better idea of what they should look for and how they might be able to know if the KSK rollover has or has not effected them & their use of DNS (i.e. 1 second after the change). Thanks, Jack REMINDER: Call for Participation -- ICANN DNSSEC Workshop at ICANN62, Panama City, Panama. June 25, 2018 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 ICANN62 meeting held from 25-28 June 2018 in Panama City, Panama. 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 San Juan, Puerto Rico on 14 March 2018. The presentations and transcripts are available at: https://61.schedule.icann.org/meetings/647563[61.schedule.icann.org]<https://urldefense.proofpoint.com/v2/url?u=https-3A__61.schedule.icann.org_…>,https://61.schedule.icann.org/meetings/647564[61.schedule.icann.org]<https://urldefense.proofpoint.com/v2/url?u=https-3A__61.schedule.icann.org_…>, and https://61.schedule.icann.org/meetings/647565[61.schedule.icann.org]<https://urldefense.proofpoint.com/v2/url?u=https-3A__61.schedule.icann.org_…>. 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 ICANN62 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-panamacity(a)isoc.org<mailto:dnssec-panamacity@isoc.org> by **Friday, 18 May 2018** Thank you, Kathy and Julie 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

DSL Operators Mailing List?
by Mike Hammett 08 May '18

08 May '18

Is there a good mailing list for DSL operators? A cursory search really only came up with DSL Reports, which is far from what I'm looking for. ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP

5 8

Spoofer Report for NANOG for Apr 2018
by CAIDA Spoofer Project 08 May '18

08 May '18

In response to feedback from operational security communities, CAIDA's source address validation measurement project (https://spoofer.caida.org) is automatically generating monthly reports of ASes originating prefixes in BGP for systems from which we received packets with a spoofed source address. We are publishing these reports to network and security operations lists in order to ensure this information reaches operational contacts in these ASes. This report summarises tests conducted within usa, can. Inferred improvements during Apr 2018: ASN Name First-Fixed 11796 AIRSTREAMCOMM-NET 2018-04-12 7922 COMCAST-7922 2018-04-15 7018 ATT-INTERNET4 2018-04-30 Further information for the inferred remediation is available at: https://spoofer.caida.org/remedy.php Source Address Validation issues inferred during Apr 2018: ASN Name First-Spoofed Last-Spoofed 577 BACOM 2016-03-09 2018-04-29 4323 TWTC 2016-04-22 2018-04-17 1280 ISC-AS-1280 2016-05-27 2018-04-18 7029 WINDSTREAM 2016-06-21 2018-04-24 2828 XO-AS15 2016-07-27 2018-04-20 209 CENTURYLINK-US-LEGACY-QWEST 2016-08-16 2018-04-29 6128 CABLE-NET-1 2016-09-03 2018-04-26 19165 WEBPASS 2016-09-19 2018-04-19 11232 MIDCO-NET 2016-09-22 2018-04-18 20412 CLARITY-TELECOM 2016-09-30 2018-04-30 20001 ROADRUNNER-WEST 2016-10-08 2018-04-19 6181 FUSE-NET 2016-10-10 2018-04-30 15305 SYRINGANETWORKS 2016-10-21 2018-04-25 25787 ROWE-NETWORKS 2016-10-21 2018-04-27 174 COGENT-174 2016-10-21 2018-04-27 271 BCNET-AS 2016-10-24 2018-04-30 32440 LONI 2016-11-03 2018-04-28 33182 DimeNOC 2016-11-08 2018-04-25 12083 WOW-INTERNET 2016-11-09 2018-04-29 5056 AUREON-5056 2016-11-10 2018-04-30 39939 RISE-CO-AS39939 2016-11-11 2018-04-15 11404 AS-VOBIZ 2016-11-11 2018-04-09 1403 EBOX 2016-11-12 2018-04-30 20105 URICHMOND 2016-11-15 2018-04-24 3549 LVLT-3549 2016-11-16 2018-04-30 54858 AS-SBI 2016-12-25 2018-04-27 2152 CSUNET-NW 2017-02-02 2018-04-21 21832 KELLINCOM-1 2017-02-03 2018-04-25 62593 SILOWIRELESS 2017-06-09 2018-04-28 6461 ZAYO-6461 2017-06-21 2018-04-30 26793 ICS-LLC 2017-08-16 2018-04-24 63296 AMARILLO-WIRELESS 2017-09-01 2018-04-25 7233 YAHOO-US 2017-09-07 2018-04-26 33523 ROWANUNIVERSITY 2017-10-29 2018-04-25 1680 NV-ASN 2017-11-14 2018-04-17 11796 AIRSTREAMCOMM-NET 2017-11-30 2018-04-02 12222 AKAMAI 2018-02-14 2018-04-25 55236 CBC 2018-03-03 2018-04-21 3257 GTT-BACKBONE 2018-03-06 2018-04-27 29384 Qatar-Foundation 2018-03-08 2018-04-29 23148 TERRENAP 2018-03-15 2018-04-25 226 LOS-NETTOS-AS 2018-03-26 2018-04-26 54417 STIMULUS-TECHNOLOGIES 2018-03-29 2018-04-24 8100 ASN-QUADRANET-GLOBAL 2018-04-06 2018-04-29 15176 AS-INOC 2018-04-09 2018-04-12 20009 WADSNET 2018-04-13 2018-04-29 4201 ORST-AS 2018-04-19 2018-04-26 11827 WSU-AS 2018-04-19 2018-04-26 31863 DACEN-2 2018-04-26 2018-04-26 11427 SCRR-11427 2018-04-28 2018-04-28 14615 ROCK-HILL-TELEPHONE 2018-04-30 2018-04-30 Further information for these tests where we received spoofed packets is available at: https://spoofer.caida.org/recent_tests.php?country_include=usa,can&no_block… Please send any feedback or suggestions to spoofer-info(a)caida.org

1 0

Re: Catalyst 4500 listening on TCP 6154 on all interfaces
by Jay Farrell 07 May '18

07 May '18

I saw that list, but understood the numbers there to be IDS signature numbers, rather than port numbers. Am I misreading something? On Mon, May 7, 2018 at 12:24 PM, Curtis, Bruce <bruce.curtis(a)ndsu.edu> wrote: > Some Cisco devices use 6154 for ypxfrd. > > > 6154 ypxfrd Portmap Request (Info, Atomic*) > > Triggers when a request is made to the portmapper for the YP transfer > daemon (ypxfrd) port. > > https://www.cisco.com/c/en/us/td/docs/ios/12_2/security/ > configuration/guide/fsecur_c/scfids.html > > https://www.cisco.com/c/en/us/td/docs/security/asa/asa84/ > configuration/guide/asa_84_cli_config/protect_tools.html > >

2 1