- Test - lists.nanog.org

Credit to Digital Ocean for ipv6 offering
by Ca By 19 Jun '14

19 Jun '14

I have not tried it out, this makes it look like DO beat Azure to market on ipv6 http://venturebeat.com/2014/06/17/digitalocean-ipv6/ Speaking of Azure and ip adresses http://www.pcworld.com/article/2363580/need-to-move-to-ipv6-highlighted-as-…

31 58

Help with Confederation-RR-MPBGP
by Philip Lavine 18 Jun '14

18 Jun '14

To all, I am studying for a certain vendors test, and need some guidance on best practices. Lets say you have a MPLS VPN with 4 PE routers. Is it more efficient to use RR or Confederation? Thank you, Philip

5 6

Opinions on Fortinet vs Palo Alto for 20+ Gbit firewalls?
by David Hubbard 18 Jun '14

18 Jun '14

Just curious if anyone has working experience with Fortinet or Palo Alto in a layer 2 transparent bridging, asymmetric routing, dual stack, 20+ Gbit/sec, redundant firewall scenario? Would love opinions, pros/cons from real world experience, etc? Only thing I can really find is some criticism on Fortinet's IPS throughput figures that can be as much as half what they claim depending on the mix of signatures enabled. Thanks, David

1 0

Re: 012 Smile Telecom (AS9116) peering contact
by Hank Nussbacher 18 Jun '14

18 Jun '14

Try ISP_NITUR(a)012.net. They recently merged with another ISP and many addresses stopped working. This one still works and should hopefully lead to someone with a clue there. Hank On Jun 18, 2014 9:59 AM, Youssef Bengelloun-Zahr <youssef(a)720.fr> wrote: > > Dear All, > > I'm looking for a valid peering contact for 012 Smile Telecom AS9116 (aka > Golden-Lines/Internet-Gold/012 Smile Communications). Their public peering > contact isn't working. > > If one their peering admins is watching, please contact me privatly. > > Best regards. > > > > -- > Youssef BENGELLOUN-ZAHR

3 2

Client on OS X, Browsers ALL fail DNS Lookup off net Hosts, SMTP+shell OK
by Everett F Batey II Gi 18 Jun '14

18 Jun '14

Newly evolved problems (network has been good for years, no recent known upgrades, config changes): Clients on MAC OS X, Browsers ALL (FFox, Opera, Safari, Chrome) fail DNS Lookups for non-local web servers, BUT: SMTP mail, POP, IMAP and shell commands (ping, trace route) fully OK AND: www.google.com and a very few .orgs resolve on web browsers. Connected via TWBC: RCWE, 13820 Sunrise Valley Drive, Herndon, Allocations for this OrgID serve Road Runner commercial customers out of the Honolulu, HI, Kansas City, KS, Orange, CA and San Diego, CA RDCs. (Probably Orange Co, CA) No, MAC has no nsswitch.conf .. to there. MAC HACKED ( ) DNS HACKED ( ) ISP FAILED fwdg DNS ( ) OTHER IDEA, START POINT ____ Thnx — VR, Ev / efbatey(a)gmail.com / +1-805-616-2471

5 4

BITAG Announces Next Technical Review on Interconnection
by Livingood, Jason 18 Jun '14

18 Jun '14

May be of interest to folks here Begin forwarded message: From: "Kaleb A. Sieh" <ksieh(a)bitag.org<mailto:ksieh@bitag.org>> Subject: BITAG Announces Next Technical Review on Interconnection Date: June 18, 2014 at 8:44:24 AM EDT Today, the Broadband Internet Technical Advisory Group (BITAG) announced its next technical review focused on the topic of Internet Network Interconnection. This topic was submitted jointly by two of BITAG’s members, CenturyLink and the Center for Democracy & Technology, and the review will result in a report with an anticipated publication date in November 2014. The Internet is a complex “network of networks” linked together in a variety of ways and by a variety of technologies. In order for end users connected to one network to access data and services connected to another network, these networks must “interconnect” with each other, either directly or indirectly. Internet network interconnection, also often referred to as “peering” or “transit”, is an increasingly important topic as the Internet ecosystem faces a dynamic growth period characterized by rapidly increasing demand, changing technologies and product offerings, and significant shifts in data traffic patterns. But there is little public information about Internet interconnection available to those not intimately involved with operating networks – including consumers, journalists and regulators. With this report, BITAG’s Technical Working Group (TWG) aims to provide an informative contribution to the ongoing discussion surrounding Internet network interconnection. Some topics likely to be covered in the report include: (1) the history of Internet network interconnection, along with a brief historical review of network interconnection in other industries and contexts; (2) how Internet traffic is managed between networks; and (3) the evolving nature of Internet data traffic patterns. Jason Weil, Principal Engineer at Time Warner Cable, and Joseph Lorenzo Hall, Chief Technologist at the Center for Democracy & Technology, will be the lead editors of the report on this topic. Douglas Sicker, Executive Director of BITAG, Chair of BITAG’s Technical Working Group, Department Head of Engineering and Public Policy and a professor of Computer Science at Carnegie Mellon University, and on leave from the University of Colorado Boulder, where he is an Endowed Professor of Computer Science and Telecommunications, will chair the review itself. For more information on the topic, please see the attached press release – which is also available on the BITAG website at www.bitag.org<http://www.bitag.org/>. Below is more info on BITAG and its structure/processes. Feel free to contact me with any questions, comments, or other needs. Kind regards, Kaleb Kaleb A. Sieh Deputy Director House Counsel Broadband Internet Technical Advisory Group (BITAG) ksieh(a)bitag.org<mailto:ksieh@bitag.org> ________________________________ About BITAG. BITAG is a non-profit, multi-stakeholder organization focused on bringing together engineers and technical experts in a Technical Working Group (TWG) to develop consensus on broadband network management practices and other related technical issues that can affect users' Internet experience, including the impact to and from applications, content and devices that utilize the Internet. * Mission. BITAG's mission includes: (a) educating policymakers on such technical issues; (b) addressing specific technical matters in an effort to minimize related policy disputes; and (c) serving as a sounding board for new ideas and network management practices. Specific TWG functions can include: (i) identifying "best practices" by broadband providers and other entities; (ii) providing technical guidance to industry and to the public; and /or (iii) issuing advisory opinions on the technical issues that may underlie disputes concerning broadband network management practices. * BITAG Reports. BITAG TWG reports focus primarily on technical issues, especially those with the potential to be construed as anti-competitive, discriminatory, or otherwise motivated by non-technical factors. While the reports may touch on a broad range of questions associated with a particular network management practice, the reports are not intended to address or analyze in a comprehensive fashion the economic, legal, regulatory or public policy issues that the practice may raise. About BITAG's Technical Review Process. BITAG's core substantive work is performed through its Technical Working Group (TWG), which was formed with the core principles of being: technically driven, balanced, open, efficient, independent, and flexible. The TWG reviews technical issues brought to it through Review Requests submitted by both Members and non-Members, or through a majority vote of the TWG engineers themselves. * Committees. Each individual technical review is taken up by a committee of the TWG that is composed of engineers and other technical experts representing a broad cross section of the Internet ecosystem. * Consensus-based. TWG committees operate on a consensus-basis, with balanced backstop voting procedures so that when consensus cannot be achieved, each Member category has an equal say in the work product regardless of the composition of the committee. * Expeditious — 120-day "shot clock". BITAG was structured to work as expeditiously as possible, with each technical committee operating under a 120-day "shot clock" during which the respective technical review and report must be completed.

1 0

012 Smile Telecom (AS9116) peering contact
by Youssef Bengelloun-Zahr 18 Jun '14

18 Jun '14

Dear All, I'm looking for a valid peering contact for 012 Smile Telecom AS9116 (aka Golden-Lines/Internet-Gold/012 Smile Communications). Their public peering contact isn't working. If one their peering admins is watching, please contact me privatly. Best regards. -- Youssef BENGELLOUN-ZAHR

1 0

Can anyone check this routing against Charter in WI?
by Mikeal Clark 16 Jun '14

16 Jun '14

Hoping someone auditing the list can provide some insight or a back channel support option. I started having some good latency spikes last night, which have continued this morning, so I finally took a look at things and I am seeing a lot more routing than I expected. Support is telling me this is normal but I don't remember this many replies on traceroute. My speeds are about 1/5 the normal as well this morning and seeing some dropped packets even using a test sight inside Charter's network. This is just business cable so my support options are pretty limited. 4 10 ms 14 ms 13 ms dtr01shbywi-tge-0-3-0-23.shby.wi.charter.com [96.34.24.178] 5 18 ms 11 ms 17 ms dtr01wbndwi-bue-2.wbnd.wi.charter.com [96.34.30.17] 6 12 ms 11 ms 11 ms dtr02wbndwi-bue-1.wbnd.wi.charter.com [96.34.24.56] 7 17 ms 11 ms 11 ms dtr02fdulwi-bue-3.fdul.wi.charter.com [96.34.30.19] 8 13 ms 18 ms 18 ms dtr01fdulwi-bue-1.fdul.wi.charter.com [96.34.19.144] 9 19 ms 14 ms 15 ms crr03fdulwi-bue-2.fdul.wi.charter.com [96.34.20.8] 10 30 ms 22 ms 35 ms crr02euclwi-bue-6.eucl.wi.charter.com [96.34.22.240] 11 23 ms 22 ms 43 ms bbr02euclwi-bue-4.eucl.wi.charter.com [96.34.2.6] 12 22 ms 34 ms 19 ms bbr01euclwi-bue-5.eucl.wi.charter.com [96.34.0.6] 13 34 ms 30 ms 38 ms bbr01stcdmn-tge-0-0-0-3.stcd.mn.charter.com [96.34.0.115] 14 42 ms 43 ms 52 ms 65.46.47.77 15 78 ms 78 ms 92 ms ae1d0.mcr2.minneapolis-mn.us.xo.net [216.156.1.86] 16 93 ms 82 ms 82 ms vb1711.rar3.denver-co.us.xo.net [216.156.0.173] 17 81 ms 95 ms 82 ms te-3-0-0.rar3.sanjose-ca.us.xo.net [207.88.12.58] 18 83 ms 82 ms 98 ms 207.88.14.226.ptr.us.xo.net [207.88.14.226] 19 81 ms 78 ms 78 ms 216.156.84.6.ptr.us.xo.net [216.156.84.6] 20 77 ms 78 ms 88 ms xe-2-2-0-955.jnrt-edge02.prod1.netflix.com [69.53.225.30] 21 86 ms 78 ms 78 ms te1-8.csrt-agg02.prod1.netflix.com [69.53.225.10] 22 79 ms 78 ms 82 ms www.trynetflix.com [69.53.236.17] 4 12 ms 11 ms 8 ms dtr01shbywi-tge-0-3-0-23.shby.wi.charter.com [96.34.24.178] 5 17 ms 10 ms 12 ms dtr01wbndwi-bue-2.wbnd.wi.charter.com [96.34.30.17] 6 11 ms 9 ms 15 ms dtr02wbndwi-bue-1.wbnd.wi.charter.com [96.34.24.56] 7 15 ms 18 ms 18 ms dtr02fdulwi-bue-3.fdul.wi.charter.com [96.34.30.19] 8 16 ms 14 ms 11 ms dtr01fdulwi-bue-1.fdul.wi.charter.com [96.34.19.144] 9 20 ms 14 ms 15 ms crr03fdulwi-bue-2.fdul.wi.charter.com [96.34.20.8] 10 22 ms 22 ms 18 ms crr02euclwi-bue-6.eucl.wi.charter.com [96.34.22.240] 11 18 ms 22 ms 22 ms bbr02euclwi-bue-4.eucl.wi.charter.com [96.34.2.6] 12 35 ms 30 ms 31 ms bbr01chcgil-bue-1.chcg.il.charter.com [96.34.0.9] 13 27 ms 27 ms 27 ms prr01chcgil-bue-2.chcg.il.charter.com [96.34.3.9] 14 27 ms 27 ms 27 ms 96-34-152-30.static.unas.mo.charter.com [96.34.152.30] 15 29 ms 32 ms 27 ms 209.85.244.1 16 27 ms 27 ms 28 ms 209.85.254.238 17 54 ms 40 ms 40 ms 209.85.248.214 18 38 ms 40 ms 38 ms 216.239.43.217 19 * * * Request timed out. 20 44 ms 40 ms 40 ms google-public-dns-a.google.com [8.8.8.8]

5 5

IPV6 and Charter Cable
by Roy 14 Jun '14

14 Jun '14

Does Charter Cable have IPV6 for businesses yet? If so can someone point me in the right direction. Their NOC seems to be clueless on their IPV6 plans

5 5

routing issues to AWS via 2914(NTT)
by Christopher Rogers 14 Jun '14

14 Jun '14

Could an IP engineer from AWS (16509/14618) and one from NTT (2914) kindly contact me off-list? AS18888 is having some major reachability issues to you via 2914. Several of our applications and users are reporting problems trying to reach various aws hosted services such as netflix and twilio. I'm seeing almost 50% packet loss when transiting to you via 2914. Forcing traffic onto 3356 clears the issue right up. I've had to effectively shift all my ingress traffic off 2914 and de-pref aws as-path to force egress to other transit. We're a customer of 2914, but not AWS. I've got a ticket open with 2914, and they've reached out to AWS, but it's been two days now and we haven't been getting any traction on this. thanks! -chris

5 5