August 2014 - Test - lists.nanog.org

GoDaddy Contact
by D'Alleva, Ron 29 Aug '14

29 Aug '14

Greetings, Can someone from GoDaddy please contact me off list? Two of our name servers have been block from making DNS lookups against your hosted domains. Many Thanks, -- Ronald D'Alleva Email: rdalleva(a)constantcontact.com<mailto:rdalleva@constantcontact.com>

1 0

Re: Prefix hijacking, how to prevent and fix currently
by Brandon Butterworth 29 Aug '14

29 Aug '14

> From: Saku Ytti <saku(a)ytti.fi> > I feel RPKI would be much more marketable if vendors would implement 'loose' > mode. > Loose mode would drop failing routes, iff there is covering (i.e. less > specific is ok) route already in RIB. +10 > And it would completely remove false-positive blackholing. This is why I don't want strict. That and true-positives, I don't think having a switch that allows courts/rir finger trouble etc to take out global routing is sensible. Too many others would start using it. However loose mode could be abused in the same way, they just invalidate your key and advertise a covering route to give themselves effective strict over you. Admittedly there is collateral damage to adjacent address space incurred in doing this but we know there are hijack techniques they could use to mitigate that brandon

1 0

JANOG 34 Meeting Report
by MAWATARI Masataka 29 Aug '14

29 Aug '14

Dear Colleagues, We'd like to share some of the discussions from JANOG 34 held in Takamatsu-city, from 17-18 July with over 500 participants. While our discussions are in Japanese, we believe there are issues in common with operators outside Japan. An english version of the Summary Report and a report on anti-spam measures session is be made available this time, below. JANOG 34 Summary Report and "Let's talk about IP anycast" : http://goo.gl/IbKzkQ Pick up Session: "Measures against Spam after OP25B" : http://goo.gl/uY4lxk The topics discussed are not limited to these two topics of course. Please see the translated overview of the program and the presentation slides (in Japanese but some have visual images and data). Program Overview (English): http://goo.gl/KhrpRZ Program and Slides (Japanese): http://goo.gl/Q61oeh Here are some examples of the topics covered: * Use of technologies - Visualising network events - Advantages and disadvantages of "white box networking" * Operational issues - Blind spots of IPv6 PMTU Blackhole Discovery - NTP attacks: "NTP Talk WG": http://goo.gl/5RL50v - OpenSSL heartbleed bug - Stopping full table routing changed my life @ AS55394 * Social aspects - Seeking change in the cost structure of content delivery - Balance of outreach on security issues - What is good higher education for future engineers - Cultural differences in software and network engineers At the meeting, we ran the JANOG 34 network with IPv6 ULA-only and ULA + GUA SSIDs, which was presented at the IPv6 Operations session @ IETF90 in Toronto. ULA Experience at JANOG 34 http://tools.ietf.org/agenda/90/slides/slides-90-v6ops-1.pdf Positive findings - GUA + IPv4 (Private) and ULA is harmless (at least for MAC OS) - SLAAC/ULA and DHCPv6/ULA works well - ULA operation/configuration is not hard Challenges - Android devices did not come up without IPv4 - IPv4 only applications still exist (Skype/dropbox) - NAT66 on ULA only network should not be recommended , but it worked If you have any feedback, we welcome comments or questions on JANOG mailing list "janog(a)janog.gr.jp": https://www.janog.gr.jp/mailman/listinfo/janog/ * Subscription page first appears in Japanese but it's possible to switch to English from pull-down menu options on the top right The coming meeting, JANOG 35 will be from 14-16 Jan 2015 in Shizuoka Prefecture. We'll update you with more details through our SNS accounts as the date gets closer. Masataka Mawatari, Izumi Okutani JANOG Internationalization(i18n) team http://www.janog.gr.jp/en/index.php?i18n-team Facebook: https://www.facebook.com/janogmeetingi18n Twitter : https://twitter.com/janog_i18n ------------------------------------------------------------------- -- Japan Internet Exchange MAWATARI Masataka <mawatari(a)jpix.ad.jp>

1 0

Broken IPv6 firmware on U-Verse 3801HGV
by Ivan Kozik 28 Aug '14

28 Aug '14

I noticed that AT&T released some firmware with IPv6 support back in May for their 3801HGV (and related) gateways. To try this out, I factory-reset my 3801HGV (still on version 6.9) and it installed the 6.11 firmware about 10 minutes later. I then used the obscure page at https://esupport.att3.2wire.com/online-tool/compat-index.jsp to request an IPv6 address ("wait 48 hours" it said) and got a routable IPv6 address in just a few minutes. All for naught, though. With IPv6 enabled, the 3801HGV crashed and rebooted about once an hour. After unchecking "IPv6 LAN Enabled" in http://192.168.1.254/xslt?PAGE=C_2_6 everything went back to normal. If anyone from AT&T is listening, I'm happy to help diagnose your firmware problems. Ivan

3 2

Verizon connectivity issues
by Ryan Ruuska 28 Aug '14

28 Aug '14

Hello all, We have heard from many of our customers in the Northeast region, specifically PA, MD, and VA who have difficulty connecting to our website (very slow loading times). We have noticed that if our data center provider specifically routes our outbound traffic over Hurricane Electric rather than XO Communications, that connectivity is restored to normal for our customers. The HE path goes from Salt Lake City to Denver where it is handed off to TeliaSonera, and they send it to Chicago where it gets handed off to Verizon. This works great and generally has a ping response of 20-25ms less than the bad route as posted below from one of our servers: Tracing route to pool-108-52-xxx-xxx.phlapa.fios.verizon.net [108.52.xxx.xxx] over a maximum of 30 hops: 1 <1 ms <1 ms <1 ms 172.xxx.xxx.xxx (Internal IP) 2 <1 ms 10 ms <1 ms 209-41-xxx-xxx.c7dc.com [209.41.xxx.xxx] 3 <1 ms <1 ms <1 ms e1-5.rt08.gp1.c7dc.com [192.41.0.97] 4 2 ms 1 ms 1 ms ip65-46-51-113.z51-46-65.customer.algx.net [65.46.51.113] 5 19 ms 18 ms 19 ms vb1611.rar3.sanjose-ca.us.xo.net [216.156.0.5] 6 21 ms 18 ms 18 ms 207.88.14.226.ptr.us.xo.net [207.88.14.226] 7 18 ms 18 ms 18 ms 206.111.6.122.ptr.us.xo.net [206.111.6.122] >>>> Verizon owned device with an XO IP address 8 87 ms 86 ms 87 ms b100.phlapa-lcr-22.verizon-gni.net [130.81.209.187] >>>> Next hop goes from CA to PA, probably just hidden routing info 9 * * * Request timed out. 10 88 ms 89 ms 90 ms pool-108-52-xxx-xxx.phlapa.fios.verizon.net [108.52.xxx.xxx] As you can see, XO sends this traffic from Salt Lake City to San Jose where it is handed off to Verizon. We've worked with XO and determined that there are no connectivity issues along their path, which seems to point to an issue within Verizon's network. I have a couple of tickets open with Verizon at the moment on behalf of some of our customers, but we have had trouble breaking through Tier 1. Our first thought was saturation of the peering point, but XO states that the link between hops 6 and 7 is using 5Gbps out of 20Gbps capacity, and the latency on hop 7 (the Verizon owned device with an XO IP) seems normal whenever we test. Any Verizon engineers out there willing to take a quick peek at this route for any obvious issues? It would be a lot easier for us if Verizon provided Looking Glass servers, but alas... Thank you, Ryan

3 3

Request for Verizon Engineer regarding 206.111.6.122 (San Jose)
by Ryan Ruuska 27 Aug '14

27 Aug '14

Can someone contact me regarding an issue with connectivity from this hop in San Jose to customers in Maryland, Virginia, and Pennsylvania? The DNS says it is an XO IP but it is actually a Verizon owned device. Thank you, Ryan

1 0

Ebay/Paypal blocking HTTP access based on SORBS DUHL / Spamhaus PBL
by Tarko Tikan 27 Aug '14

27 Aug '14

hey, For a while now, we have been getting complains from our broadband customers about not being able to reach ebay.com/paypal.com We have nailed it down to some small prefixes and they are all listed in SORBS DUHL / Spamhaus PBL and have been listed for ages. These are indeed dynamic IP pools and should not send any email (not that SMTP has anything to do with HTTP). For some reason, it looks like ebay/paypal is now blocking HTTP access based on these blacklists. Does anyone have working contact in their NOC or with security people? All emails to public contacts have not been answered to. -- tarko

4 6

centurylink chi2 and level3 -- network issues
by Nick 27 Aug '14

27 Aug '14

Is anyone else having network issue over the past week with centurylink and their peer level3? I spoke with centurylinks noc team. They are not being helpful and blame level3. I'm seeing period of high packet loss and poor throughput speeds. From what I can tell. Its a problem between qwest and level3 border routers. Host Loss% Snt Last Avg Best Wrst StDev .... 2. cer-core-02.inet.qwest.net 0.0% 663 0.5 0.8 0.4 35.0 2.9 3. vlan52.ebr2.Chicago2.Level3.net 2.7% 662 196.0 196.5 192.2 209.2 1.5 4. ??? 5. ae-46-46.ebr2.Washington1.Level3 1.8% 662 196.8 196.0 191.2 201.1 1.1 .... [not the complete traceroute] At the moment, I moved most of my traffic from centurylink. The remaining services are being greatly impacted by the poor network performance. What do you think my next steps should be? Any advice would be greatly appreciated. - Nick

2 1

RPKI
by Pelsser Cristel 27 Aug '14

27 Aug '14

Hi, With Daniele Iamartino, we are validating BGP routes with the objects stored in the RPKI. On 2014/07/26, for the routes at the LINX RouteViews monitor, we observe the following set of prefixes that are announced both with the correct origin AS and a wrong origin AS. There are very few of them. We believe they could be anycast where there is no ROA for some origin ASs or they could be misconfiguration/attacks. RIB Dump time: 2014/08/26 08:00 UTC prefix,valid AS,invalid AS 5.128.0.0/14,31200,50923 37.19.8.0/21,49964,198585 94.199.232.0/21,49413,5089 179.61.194.0/23,61440,37692 190.94.182.0/24,262195,18678 193.42.215.0/24,30880,50827 193.227.174.0/24,9051,24634 195.69.144.0/22,1200,41313 200.35.183.0/24,26617,27742 213.192.242.0/23,8903,12541 217.113.242.0/24,197860,20721 217.113.244.0/24,197860,20721 217.113.245.0/24,20721,197860 2a02:2928::/32,39288,197530 Prefixes containing private AS numbers prefix,valid AS,invalid AS 176.56.192.0/19,8426,65489 185.36.76.0/22,8426,65489 194.45.46.0/24,286,64951 2a00:fd00::/32,29695,65026 Any feedback is welcome, Cristel

1 0

Cisco Tech needed in San Franscisco
by JoeSox 27 Aug '14

27 Aug '14

Hi Everyone, Took over a new network and they have no onsite Cisco tech help for one of my remote locations. Can someone email me directly a company I can contract with to get help this Wed night in downtown San Francisco (we can push maintenance to Friday night as well but shooting for tomorrow)? -- Thank You, Joe

1 1