February 2017 - Test - lists.nanog.org

Looking for AS 263686 contact
by Alejandro Acosta 14 Feb '17

14 Feb '17

Hello, If anybody from AS 263686 please contact me off-list. Thanks, Alejandro,

1 0

Web/Streaming issues
by Art Stephens 14 Feb '17

14 Feb '17

Been getting complaints from customers about web services such Netflix, Youtube, Facebook and Snapchat either slow to load or not loading at all and yet speed tests seem to be ok. We keep checking our network equipment for issues and not able to identify any as of yet We have two 10gig connections to Wolfe and Zayo. Are others seeing similar issues? -- Arthur Stephens Senior Networking Technician Ptera Inc. PO Box 135 24001 E Mission Suite 50 Liberty Lake, WA 99019 509-927-7837 ptera.com | facebook.com/PteraInc | twitter.com/Ptera ----------------------------------------------------------------------------- "This message may contain confidential and/or propriety information, and is intended for the person/entity to whom it was originally addressed. Any use by others is strictly prohibited. Please note that any views or opinions presented in this email are solely those of the author and are not intended to represent those of the company."

2 1

Comcast issue in Massachusetts
by Jon Swanson 14 Feb '17

14 Feb '17

Does anyone have insight to the issue Comcast is having in Eastern Massachusetts? I am being told residents are experience Internet and TV outages. But cannot find anything on what the issue is. thank you in advance. email directly if appropriate. Thank you, -Jon

1 0

[NANOG-announce] 2017 Program Committee appointments
by Dave Temkin 13 Feb '17

13 Feb '17

Greetings NANOG Colleagues, The Board has completed the Program Committee selection process. This year, 27 members submitted their candidacies for 9 available positions. We want to thank each and every one of them for considering this important service to our community and encourage them to try for the next selection cycle. We are pleased to announce the two-year term appointment of the following to the Program Committee: L Sean Kennedy, Dani Roisman, Allison Feese-Strickland, Krassimir Tzvetanov, Ryan Woolley, Christina Chu, Brad Raymo, Greg Hankins, and Adam Davenport We also want to thank and recognize the contribution of Philippe Couture, Paul Ebersman, and John Van Oppen for their service on the Program Committee. The Board of Directors also created an Ad-Hoc Committee for NANOG On The Road meetings. We are pleased to announce the two-year term appointment of the following to the Ad-Hoc NANOG On The Road Committee: Chair: Steve Feldman Additional Members: Mohit Lad, Jeff Ringwelski, and Ryan Landry In the coming weeks, the new Program Committee will hold its first meeting and select a Chair and a Vice-Chair. Sincerely, Dave Temkin Chair, NANOG Board of Directors _______________________________________________ NANOG-announce mailing list NANOG-announce(a)mailman.nanog.org http://mailman.nanog.org/mailman/listinfo/nanog-announce

1 0

is something weird going on with cox, level3, and/or cogent
by Miles Fidelman 13 Feb '17

13 Feb '17

Hi Folks, I'm visiting AZ, and seeing some really really poor performance accessing some of our servers via Cox broadband. The folks at Cox technical support are useless - all they say is "well you're on a DOCSIS 2 modem." Meanwhile, everything I'm seeing is several hops upstream of the local segment - and all that Cox level2 tech support will say is "if there was a backbone problem, our backbone people would have dealt with it." I'm having problems reaching both our own server, and sites like google, facebook, windows update. Traceroutes to and from our server are illustrative - note that for most of the past week, the average ping time was 85msec. Now we're seeing this: From 98.177.135.186 - the public IP address on Cox's local broadband service. To 107.154.13.58 (ntcorp.server - one of our servers, sitting in a Tierpoint data center, near Boston) traceroute to ntcorp.com (207.154.13.58), 64 hops max, 52 byte packets 1 10.128.128.1 (10.128.128.1) 199.893 ms 75.319 ms 27.295 ms 2 100.127.69.178 (100.127.69.178) 38.710 ms 40.075 ms 43.598 ms 3 72.215.229.22 (72.215.229.22) 39.674 ms 201.368 ms * 4 lag-157.bear2.phoenix1.level3.net (4.28.82.53) 686.499 ms 1837.141 ms 16.273 ms 5 ae-1-60.edge1.losangeles6.level3.net (4.69.144.16) 35.498 ms 964.377 ms * 6 ae-3-80.edge1.losangeles6.level3.net (4.69.144.144) 551.760 ms 525.014 ms ae-1-60.edge1.losangeles6.level3.net (4.69.144.16) 2061.191 ms 7 be3036.ccr41.lax04.atlas.cogentco.com (154.54.14.129) 847.778 ms 87.601 ms 71.504 ms 8 be2965.ccr22.lax01.atlas.cogentco.com (154.54.45.1) 79.060 ms 225.647 ms be2964.ccr21.lax01.atlas.cogentco.com (154.54.44.77) 60.306 ms 9 * be2931.ccr21.phx02.atlas.cogentco.com (154.54.44.85) 2264.071 ms 185.180 ms 10 be2929.ccr21.elp01.atlas.cogentco.com (154.54.42.66) 61.208 ms be2930.ccr21.elp01.atlas.cogentco.com (154.54.42.78) 386.149 ms 1278.868 ms 11 be2928.ccr22.iah01.atlas.cogentco.com (154.54.30.161) 384.136 ms be2927.ccr41.iah01.atlas.cogentco.com (154.54.29.221) 2339.833 ms 615.415 ms 12 be2690.ccr42.atl01.atlas.cogentco.com (154.54.28.129) 233.061 ms be2687.ccr41.atl01.atlas.cogentco.com (154.54.28.69) 87.902 ms be2690.ccr42.atl01.atlas.cogentco.com (154.54.28.129) 861.159 ms 13 be2113.ccr42.dca01.atlas.cogentco.com (154.54.24.221) 998.858 ms be2112.ccr41.dca01.atlas.cogentco.com (154.54.7.157) 249.930 ms * 14 be2807.ccr42.jfk02.atlas.cogentco.com (154.54.40.109) 768.461 ms be2806.ccr41.jfk02.atlas.cogentco.com (154.54.40.105) 136.772 ms be2807.ccr42.jfk02.atlas.cogentco.com (154.54.40.109) 288.225 ms 15 be2094.ccr21.bos01.atlas.cogentco.com (154.54.30.14) 271.736 ms 166.224 ms be2096.ccr22.bos01.atlas.cogentco.com (154.54.30.42) 565.015 ms 16 te0-4-1-7.agr22.bos01.atlas.cogentco.com (154.54.80.34) 1944.479 ms te0-4-1-6.agr22.bos01.atlas.cogentco.com (154.54.80.10) 149.803 ms te0-4-1-6.agr21.bos01.atlas.cogentco.com (154.54.47.230) 897.115 ms 17 te0-0-2-0.nr11.b000254-0.bos01.atlas.cogentco.com (154.24.9.82) 107.207 ms te0-0-2-1.nr11.b000254-0.bos01.atlas.cogentco.com (154.24.9.78) 295.881 ms 185.453 ms 18 38.122.127.18 (38.122.127.18) 115.652 ms 461.168 ms 615.526 ms 19 207.154.0.57 (207.154.0.57) 1871.023 ms 1987.832 ms 2165.248 ms 20 server1.ntcorp.com (207.154.13.58) 587.560 ms 263.328 ms 333.542 ms Traceroute in the reverse direction: 1 207.154.13.47 (207.154.13.47) 0.000 ms 0.000 ms 0.000 ms 2 * * * 3 h130.207.190.173.static.ip.windstream.net (173.190.207.130) 0.000 ms 0.000 ms 0.000 ms 4 xe1-2-0-0.cr01.cley01-oh.us.windstream.net (40.128.250.166) 12.000 ms 12.000 ms 12.000 ms 5 et11-0-0-0.cr01.chcg01-il.us.windstream.net (40.128.248.71) 20.000 ms 20.000 ms 20.000 ms 6 10gigabitethernet4-1.core1.chi1.he.NET (206.223.119.37) 72.001 ms 20.000 ms 16.000 ms 7 chgobbrj01pos010100.r2.ch.cox.net (68.105.30.193) 20.000 ms 20.000 ms 20.000 ms 8 chnddsrj01-ae1.0.rd.ph.cox.net (68.1.5.211) 72.001 ms 72.001 ms 72.001 ms 9 * * * 10 * * * 11 * * * <snip> 30 * * * <looks like a lot of the later hops don't respond to pings> Two things jump out at me: 1. The rather large number of hops from cox to ntcorp - with high delays from several nodes in both the level3 and cogent networks. 2. That there's a rather more direct path from the datacenter to cox, that shows up in the reverse direction. Some kind of routing or peering issue, perhaps? (And I also note the earlier string of messages regarding youtube streaming problems - that also seemed to involve cox and level3. Thanks for any insight (and better, for any fixes!). Miles Fidelman -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra

2 4

Small-mid scale vDPI
by Ramy Hashish 13 Feb '17

13 Feb '17

Good day community, Any experience based recommendations about cost effective vDPIs in small-mid scale? Thanks, Ramy

1 0

YouTube streaming failures
by Mel Beckman 13 Feb '17

13 Feb '17

We are getting many customer reports of YouTube streaming failures. The content directory and search work, but attempts to view videos results in "something went wrong, click to try again" error messages. We've reproduced the problem on AT&T, Level3, Frontier, Cox and Comast networks. We are also seeing it on cellular data connections, which tends to rule out geo-IP errors. Is anyone else seeing this? -mel beckman

5 5

Call for presentations - FIR 2017
by Fabián Mejía 11 Feb '17

11 Feb '17

*********************************************************************** CALL FOR PRESENTATIONS *********************************************************************** REGIONAL INTERCONNECTION FORUM 2017 May 22-26, 2017 – Foz do Iguazu, Brasil More information: http://interconexion.lacnic.net LACNIC (http://www.lacnic.net) is an international organization based in Montevideo, Uruguay, responsible for administrating IP address space, Reverse Resolution, Autonomous System Numbers and other resources for the region of Latin America and the Caribbean on behalf of the Internet community. The Regional Interconnection Forum (formerly known as NAPLA), is a discussion forum that includes an annual meeting held within the framework of LACNIC's main annual event. The LACNIC 27 event (http://www.lacnic.net/web/eventos/lacnic27) will be held in Foz do Iguazu (Brasil) on 22-26 May, 2017, so we are calling the Internet community to submit proposals for presentations that could be included on the 2017 Regional Interconnection Forum's program. The topics of interest for the event include, but are not limited to, the following: * Internet Exchange Points (IXPs): current status, future projects, new services, public policies, multimedia peering,. * Regional Connectivity: the role of governments, submarine and terrestrial cables, traffic measurements, current and future needs. * Content Delivery Networks (CDNs): strategies of deployment and presence within the region, peering policies, impact on local and regional traffic, * Cloud services: impact on local and regional traffic, availability, growth, future projects in the LAC region. * Other critical infrastructure: DNS root servers, ccTLDs and gTLDs. * Technical topics: best BGP routing practices, analysis of faults and attacks having major impacts on traffic. * Current issues: impact on local or regional traffic of high-interest events (e.g., availability / unavailability of services, natural disasters, sports events of high interest, etc). GUIDELINES FOR THE SUBMISSION OF PROPOSALS: Those interested in presenting a proposal should send an email to comite.fir@ lacnic.net containing the following information in the text of the message: * Presentation title. * General summary. * An attachment with a draft of the slides or an extended abstract of the article / work submitted. This text should not exceed one thousand (1000) words. * Estimated time of the presentation. * Authors' details (full name, email address and company/organization they represent) * Specify whether at least one of the authors can guarantee their attendance at the event, or whether this depends on the possibility of obtaining financial assistance from the event's organizers (see "Speaker Benefits"). In addition, the following considerations should be taken into account: * Proposals may be submitted in English, Portuguese or Spanish. * Proposals must be submitted in Portable Document Format (PDF). * Scanned documents will not be accepted. * Presentations may not be longer than 20 minutes. The time allocated may be different than requested. * The Evaluation Committee may, at its sole discretion, request additional information, which must be sent promptly. PROPOSAL EVALUATION: The Evaluation Committee created for this purpose shall evaluate proposals based on the following basic criteria: * Originality * Value of sharing the experience * Technical quality * Relevance * Possibility of generalized application * Presentation * Applicability * Importance of the development THE EVALUATION COMMITTEE IS MADE UP AS FOLLOWS: * Roque Gagliano (UY) * Milton Kashiwakura (BR) * Hernan Arcidiacono (AR) * Mauricio Oviedo (CR) * Gabriel Adonaylo (AR) * Christian O'Flaherty (AR) * Carlos Martínez (UY) * Fabián Mejía (EC) SPEAKER BENEFITS: The registration fee will be waived for those authors whose proposals are accepted and included in the program. However, speaker travel and accommodation expenses will not be covered. Those requiring financial assistance to attend the event may apply for such assistance when LACNIC opens the corresponding application period. Please note that acceptance of a proposal does NOT imply that the author(s) will be granted financial assistance, although the submission of a proposal may be considered a plus during the recipient selection process. For more information, please check out the Financial Assistance section on the event's website: (http://www.lacnic.net/web/eventos/lacnic27) or check with LACNIC staff at becas(a)lacnic.net IMPORTANT DATES: * Deadline for proposal reception: Sunday, 12 March 2017 * Notification of acceptance: Week of March 13, 2017 * Deadline for submitting the final version of the presentation: Friday, 12 May, 2017 Kind regards, Fabian Mejia Chair Regional Interconnection Forum

1 0

Dev. Mfg & ISP Filtering Requirements as set forth in Florida HB337/SB0870, and under similar bills in about 30 other states...
by Kraig Beahn 11 Feb '17

11 Feb '17

There's a bill being widely circulated and passing thru various chambers of at least 30 states right now, commonly being referred to as the HUMAN TRAFFICKING AND CHILD EXPLOITATION PREVENTION ACT, or in Florida's case, we're apparently calling this the "HB 337:Internet Access" bill. Jokes, moral considerations and politics aside - Does anyone have any further information on potentially related bills passing thru states beyond Florida, and has anyone seriously considered the infrastructure changes/impairments necessary to comply, in the unusual event that HB337 or any of the many other bills in various other states passes? Edited HB Brief: An act relating to Internet access; prohibiting covered businesses from manufacturing, distributing, or selling certain devices unless the device contains an active and operating filter that blocks Internet access to specified types of sexually oriented material, prostitution, assignation, lewdness, and human trafficking; providing for injunctive relief for violations; providing requirements for a consumer to have such filter deactivated; requiring a filter deactivation fee and providing for the collection and distribution thereof; prohibiting the distribution or sale of certain devices without filters to minors and adults; providing criminal penalties; providing for jurisdiction to prosecute violations; providing for continuing duties of covered businesses; requiring covered businesses to respond to reports of obscene material that has breached the filter; providing for civil penalties for violations; requiring covered businesses to unblock non obscene material; exempting certain websites from filtering; amending s. 16.56, F.S.; authorizing the Office of Statewide Prosecution to prosecute violations; providing an effective date. The Full Text can be found here: FL/HB 337 <http://www.flsenate.gov/Session/Bill/2017/0337/BillText/__/PDF> On the technical side, you'd probably find yourself chuckling through this reading exercise. However, our regulatory attorney was assured this bill for which is currently under consideration is no laughing matter and is being seriously considered in a multitude of state venues, while others have been dismissive. We've initiated several calls with aide's for Rep. Spanos, the Florida House sponsor, and from what we can tell, the bill is far from the chopping block. Considering the technical impacts not only to internet access device manufacturers, and the implied impacts on service providers like ourselves, i'm surprised it hasn't garnered more attention, nationally. >From a curiosity perspective: The source of this bill appears to be an individual by the name Mark "Chris" Sevier, the same individual whom has virtually sued most of Silicon Valley, and I'll leave it at that in hopes of being able to keep this thread on a technical/legislative tone. NANOG note: Our objective in starting this tread is not to question the intent, moral purpose or potential political agendas surrounding Florida House Bill 337 or bills of similar nature, only it's technical impact on device manufacturers, internet access providers and other alike legislatively covered businesses, assuming passage, as currently written. --

2 1

IoT security
by William Herrin 10 Feb '17

10 Feb '17

This afternoon's panel about IoT's lack of security got me thinking... On the issue of ISPs unable to act on insecure devices because they can't detect the devices until they're compromised and then only have the largest hammer (full account ban) to act... What about some kind of requirement or convention that upon boot and successful attachment to the network (and maybe once a month thereafter), any IoT device must _by default_ emit a UDP packet to an anycast address reserved for the purpose which identifies the device model and software build. The ISP can capture traffic to that anycast address, compare the data against a list of devices known to be defective and, if desired, respond with a fail message. If the IoT device receives the fail message, it must try to report the problem to its owner and remove its default route so that it can only communicate on the local lan. The user can override the fail and if desired configure the device not to emit the init messages at all. But by default the ISP is allowed to disable the device by responding to the init message. Would have to cryptographically sign the fail message and let the device query the signer's reputation or something like that to avoid the obvious security issue. Obvious privacy issues to consider. Anyway, throwing it out there as a potential discussion starting point. The presentation on bandwidth policers... Seems like we could use some form of ICMP message similar to destination unreachable that provides some kind of arbitrary string plus the initial part of the dropped packet. One of the potential strings would be an explicit notice to the sender that packets were dropped and the bandwidth available. Yes, we already have ECN, but ECN tells the receiver about congestion, not the sender. More to the point, ECN can only be flagged on packets that are passed, not the packets that are dropped, so the policer would have to be complicated enough to note on the next packet that the prior packet was dropped. Also, ECN only advises that you're close to the limit not any information about the policer's target limit. This thought is not fully baked. Throwing it out for conversation purposes. Regards, Bill Herrin -- William Herrin ................ herrin(a)dirtside.com bill(a)herrin.us Owner, Dirtside Systems ......... Web: <http://www.dirtside.com/>

16 33