May 2014 - Test - lists.nanog.org

[nanog] GoDaddy
by takashi tome 16 May '14

16 May '14

Hi all. Does anyone know whether GoDaddy is alive/down? thanks Takashi

2 2

Re: Observations of an Internet Middleman (Level3) (was: RIP Network Neutrality
by Larry Sheldon 15 May '14

15 May '14

On 5/14/2014 4:27 AM, Roland Dobbins wrote: > > On May 14, 2014, at 3:11 PM, Matthew Petach <mpetach(a)netflight.com> > wrote: > >> I'm constantly amazed at how access networks think they can charge >> 2/3 the price of full transit for just their routes when they >> represent less than 1/10th of the overall traffic volume. > > My guess is that from the perspective of the access providers, they > aren't selling traffic volume or routes, per se - their view is that > they're selling privileged engagement with large numbers of > potentially monetizable individual prospects. In a world ruled by by the dreaded principles of completion, that would be described as the price where buyer and seller agreed on the value of the product. > Note that I'm neither endorsing nor disputing this perspective, just > mooting it as a possible explanation.| I do endorse a free market as providing the best value to all. > Are there any real-world models out there for revenue-sharing between > app/content providers and access networks which would eliminate or > reduce 'paid peering' (an alternate way to think of it is as > 'delimited transit', another oxymoron like 'paid peering', but with a > slightly different emphasis) monetary exchanges? Maybe it is time to try a free market. -- Requiescas in pace o email Two identifying characteristics of System Administrators: Ex turpi causa non oritur actio Infallibility, and the ability to learn from their mistakes. (Adapted from Stephen Pinker)

3 3

Observations of an Internet Middleman / RIP Network Neutrality
by Owen DeLong 15 May '14

15 May '14

> Yes, you've got "some of the largest Internet companies as customers². > Because you told them "if you don't pay us, we'll throttle you". Then > you throttled them. I'm sorry, not a winning argument. > Nick Claims by some large ISPs that this is “untrue” rest on the claim that they don’t do traffic discrimination. While they may not be (and, indeed, are not allowed to) do traffic discrimination, what is ignored is that refusing to add sufficient peering capacity is, to the consumer’s perspective (and to the content provider’s perspective as well) effectively the same thing as throttling. I will note that as yet, not one of these providers has claimed that they did not refuse to increase peering capacity in order to leverage payment, and, indeed, payment does appear to have been leveraged. Owen

2 1

Re: Observations of an Internet Middleman (Level3)
by Scott Weeks 15 May '14

15 May '14

From: Paul Ferguson <fergdawgster(a)mykolab.com> On 5/15/2014 10:06 AM, Ryan Brooks wrote: > It's a shame the use of 'fast lane' is ubiquitous in this argument. > If the local distribution networks would like to actually build > something fast, then this would be a different story. Okay, then call it the "faster lane" or the "uncongested lane" or something that actually reflects bias and preferential treatment. It's a done deal now: http://www.washingtonpost.com/blogs/the-switch/wp/2014/05/15/fcc-approves-p… -------------------------------------------- According to the doc it's not a done deal: "The proposal is not a final rule, but the vote on Thursday is a significant step forward" "Agencies almost always change their rules from the initial proposal" "The next phase will be four months of public comments, after which the commissioners will vote again on redrafted rules that are meant to take into account public opinion." But, yeah. I don't believe for a minute that all/any this is above board when it's coming from a lobbyist. scott

1 0

Possible Comcast Load Balancing issues in Chicago?
by Metro-Inet Netops 15 May '14

15 May '14

It’s possible I’m missing something, but it looks like traffic from Comcast business customers in the Minneapolis/St. Paul area is not all making it through Chicago to my VPN endpoints. Testing to some of my address space from one of the Comcast remote VPN sites, I can get to some numbers and not others (odds/evens switch roles depending on the block I trace) fall apart hopping though Chicago. Testing to the same addresses from the HE looking glass, everything seems fine. Any input or even knowledge that it’s being worked on would be appreciated. Traceroutes below: Fails: HUGO-CH-2921#trace 199.249.109.13 Type escape sequence to abort. Tracing the route to vpn.metro-inet.us (199.249.109.13) VRF info: (vrf in name/id, vrf out name/id) 1 75-149-158-38-minnesota.hfc.comcastbusiness.net (75.149.158.38) 0 msec 0 msec 0 msec 2 73.237.168.1 12 msec 12 msec 16 msec 3 te-4-2-ur02.whitebear.mn.minn.comcast.net (68.85.167.37) 16 msec 16 msec 16 msec 4 te-2-1-ur02.oakdale.mn.minn.comcast.net (68.87.174.138) 16 msec 16 msec 16 msec 5 te-8-3-ur01.oakdale.mn.minn.comcast.net (68.87.174.109) 20 msec 12 msec 16 msec 6 te-0-3-0-5-ar01.crosstown.mn.minn.comcast.net (69.139.176.61) 16 msec 16 msec 20 msec 7 pos-0-0-0-0-ar01.roseville.mn.minn.comcast.net (68.87.174.194) 16 msec 16 msec 12 msec 8 he-1-12-0-0-cr01.350ecermak.il.ibone.comcast.net (68.86.94.77) 24 msec 24 msec 28 msec 9 * * * 10 * Gets Through: HUGO-CH-2921#trace 199.249.109.14 Type escape sequence to abort. Tracing the route to 199.249.109.14 VRF info: (vrf in name/id, vrf out name/id) 1 75-149-158-38-minnesota.hfc.comcastbusiness.net (75.149.158.38) 4 msec 0 msec 0 msec 2 73.237.168.1 8 msec 12 msec 8 msec 3 te-4-2-ur01.whitebear.mn.minn.comcast.net (68.85.167.33) 12 msec 12 msec 12 msec 4 te-2-1-ur02.shoreview.mn.minn.comcast.net (68.87.174.129) 8 msec 12 msec 12 msec 5 te-8-3-ur01.shoreview.mn.minn.comcast.net (68.87.174.125) 12 msec 8 msec 8 msec 6 te-0-3-0-6-ar01.roseville.mn.minn.comcast.net (68.87.174.178) 12 msec 12 msec 12 msec 7 he-1-11-0-0-cr01.350ecermak.il.ibone.comcast.net (68.86.94.73) 28 msec 20 msec 24 msec 8 ix-7-0-3-0.tcore1.CT8-Chicago.as6453.net (64.86.137.33) 16 msec 16 msec 20 msec 9 206.82.141.90 20 msec 20 msec 20 msec 10 hurricane-ic-124397-chi-bb1.c.telia.net (213.248.104.214) 24 msec 24 msec 28 msec 11 100ge13-1.core1.msp1.he.net (184.105.223.178) 36 msec 24 msec 28 msec 12 city-of-roseville.gigabitethernet3-8.core1.msp1.he.net (184.105.249.218) 28 msec 28 msec 24 msec 13 199.249.109.227 28 msec 24 msec 28 msec Gets Through: HUGO-CH-2921#trace 67.88.181.25 Type escape sequence to abort. Tracing the route to ip67-88-181-25.z181-88-67.customer.algx.net(67.88.181.25) VRF info: (vrf in name/id, vrf out name/id) 1 pubwp.comcast.net (75.149.158.38) 0 msec 0 msec 0 msec 2 73.237.168.1 8 msec 8 msec 8 msec 3 te-4-2-ur01.whitebear.mn.minn.comcast.net (68.85.167.33) 12 msec 12 msec 8 msec 4 te-2-1-ur02.shoreview.mn.minn.comcast.net (68.87.174.129) 8 msec 8 msec 12 msec 5 te-8-3-ur01.shoreview.mn.minn.comcast.net (68.87.174.125) 12 msec 12 msec 8 msec 6 te-0-3-0-6-ar01.roseville.mn.minn.comcast.net (68.87.174.178) 8 msec 12 msec 12 msec 7 he-1-12-0-0-cr01.350ecermak.il.ibone.comcast.net (68.86.94.77) 24 msec 20 msec 16 msec 8 ix-2-3-0-0.tcore1.CT8-Chicago.as6453.net (64.86.137.41) 24 msec 16 msec 40 msec 9 p5-1.ir1.chicago2-il.us.xo.net (206.111.2.33) 68 msec 20 msec 80 msec 10 207.88.14.193.ptr.us.xo.net (207.88.14.193) 32 msec 32 msec 36 msec 11 ae0d0.mcr1.minneapolis-mn.us.xo.net (216.156.0.170) 28 msec 28 msec 28 msec Fails: HUGO-CH-2921#trace 67.88.181.26 Type escape sequence to abort. Tracing the route to webvpn.metro-inet.us (67.88.181.26) VRF info: (vrf in name/id, vrf out name/id) 1 pubwp.comcast.net (75.149.158.38) 0 msec 0 msec 0 msec 2 73.237.168.1 8 msec 8 msec 8 msec 3 te-4-2-ur02.whitebear.mn.minn.comcast.net (68.85.167.37) 8 msec 12 msec 8 msec 4 te-2-1-ur02.oakdale.mn.minn.comcast.net (68.87.174.138) 8 msec 12 msec 20 msec 5 te-8-3-ur01.oakdale.mn.minn.comcast.net (68.87.174.109) 8 msec 8 msec 12 msec 6 te-0-3-0-5-ar01.crosstown.mn.minn.comcast.net (69.139.176.61) 12 msec 12 msec 12 msec 7 pos-0-1-0-0-ar01.roseville.mn.minn.comcast.net (68.87.174.2) 8 msec 8 msec 12 msec 8 he-1-13-0-0-cr01.350ecermak.il.ibone.comcast.net (68.86.94.81) 24 msec 24 msec 20 msec 9 * * * 10 * * * 11 * * * 12 * * * Gets Through: HUGO-CH-2921#trace 67.88.181.27 Type escape sequence to abort. Tracing the route to ip67-88-181-27.z181-88-67.customer.algx.net(67.88.181.27) VRF info: (vrf in name/id, vrf out name/id) 1 pubwp.comcast.net (75.149.158.38) 4 msec 0 msec 4 msec 2 73.237.168.1 8 msec 12 msec 8 msec 3 te-4-2-ur02.whitebear.mn.minn.comcast.net (68.85.167.37) 12 msec 12 msec 8 msec 4 te-8-3-ur01.whitebear.mn.minn.comcast.net (68.87.174.133) 12 msec 12 msec 4 msec 5 te-2-1-ur02.shoreview.mn.minn.comcast.net (68.87.174.129) 8 msec 12 msec 8 msec 6 te-8-3-ur01.shoreview.mn.minn.comcast.net (68.87.174.125) 16 msec 8 msec 8 msec 7 te-0-3-0-6-ar01.roseville.mn.minn.comcast.net (68.87.174.178) 12 msec 12 msec 16 msec 8 he-1-13-0-0-cr01.350ecermak.il.ibone.comcast.net (68.86.94.81) 20 msec 20 msec 20 msec 9 ix-2-2-1-0.tcore1.CT8-Chicago.as6453.net (64.86.137.37) 16 msec 16 msec 16 msec 10 p5-1.ir1.chicago2-il.us.xo.net (206.111.2.33) 32 msec 72 msec 96 msec 11 207.88.14.193.ptr.us.xo.net (207.88.14.193) 36 msec 32 msec 32 msec 12 ae0d0.mcr1.minneapolis-mn.us.xo.net (216.156.0.170) 28 msec 28 msec 32 msec 13 * * * Fails: HUGO-CH-2921#trace 67.88.181.28 Type escape sequence to abort. Tracing the route to ip67-88-181-28.z181-88-67.customer.algx.net(67.88.181.28) VRF info: (vrf in name/id, vrf out name/id) 1 pubwp.comcast.net (75.149.158.38) 0 msec 0 msec 0 msec 2 73.237.168.1 12 msec 8 msec 12 msec 3 te-4-2-ur01.whitebear.mn.minn.comcast.net (68.85.167.33) 8 msec 8 msec 8 msec 4 te-2-1-ur02.shoreview.mn.minn.comcast.net (68.87.174.129) 8 msec 8 msec 12 msec 5 te-8-3-ur01.shoreview.mn.minn.comcast.net (68.87.174.125) 12 msec 8 msec 8 msec 6 te-0-3-0-6-ar01.roseville.mn.minn.comcast.net (68.87.174.178) 12 msec 12 msec 12 msec 7 he-1-11-0-0-cr01.350ecermak.il.ibone.comcast.net (68.86.94.73) 20 msec 20 msec 20 msec 8 * * * 9 * * * 10 * Mark Mayfield City of Roseville – AS 54371 Network Systems Engineer 2660 Civic Center Drive Roseville, MN 55113 651-792-7098 Office

3 3

NANOG 61 hotel
by Jon Lewis 15 May '14

15 May '14

The Hyatt appears to have filled up. :( Anyone have alternate hotel recommendations? ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route | therefore you are _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________

3 2

IPAM DDI Software, Subscriber Management, CMDB and Per Customer VLANs
by Kyle Leissner 15 May '14

15 May '14

I would like recommendations on the following software/hardware elements required to run an access network. Assume you are building a greenfield network using a combination of access technologies such as DSL, GPON, AE, and WiFi. IPAM / DDI Solution: Needs full support for IPv6, Customer VLANs, RFC 1918, VRF, Overlapping Address Space, integration with DNS, DNSSEC, Integration with DHCP, and integration with ARIN. Looks like there are both open source and commercial solutions available according to old NANOG posts. Which cater to service providers? Who are the leaders in this space? Does anyone have experience with dealing with multiple vendors? Subscriber Management/BRAS/BNG: Redback was the big player back in the day, but I believe they are no longer. Juniper has their Subscriber Management feature pack on their MX routers, and Cisco has their Broadband Network Gateway on their ASR routers. Besides these two vendors I am not sure what other solutions are out there. I believe both of these solutions communicate upstream to external radius servers and DHCP servers. Is anyone using Subscriber Management, or is there another way of doing it? CMDB: A centralized database to keep track of all assets within the network would be nice. I would assume this would need to tie in with the IPAM solution and billing systems. I would also like to hear thoughts on the per customer VLAN model. Most of the whitepapers recommend a per customer VLAN for greenfield networks, but that seems like a management and documentation nightmare. The systems described above must be able to manage and maintain per customer VLANs in an automated fashion for this approach to work and scale. If you had your choice starting from the ground up how would you deploy an access network today?

6 6

FYI: Unbreakable VPN using Vyatta/VyOS -HOW TO-
by Naoto MATSUMOTO 14 May '14

14 May '14

Hi all! We wrote TIPS memo about the Basic Idea for inter-cloud networking using Virtual Router (a.k.a Brocade Vyatta vRotuer and VyOS) with High Availability Concept. Please enjoy it if you interest in ;-) Unbreakable VPN using Vyatta/VyOS -HOW TO- http://slidesha.re/1lryGVU Best Regards, -- SAKURA Internet Inc. / Senior Researcher Naoto MATSUMOTO <n-matsumoto(a)sakura.ad.jp> SAKURA Internet Research Center <http://research.sakura.ad.jp/>

2 2

BGP route flapping
by Gus Crichton 14 May '14

14 May '14

Hi there, Hope you networking experts can shed some light on a concern I have please. I am multihoming using 2 ISPs to the internet, due to reasons outside my control, my primary preferred link keeps dropping a number of times a day forcing traffic to my backup and vice-versa when the primary comes back up. The route calculations by the upstream tier 1s and 2s handle the route calculations but if I do this too many times consuming their resources, is there a penalty/blackmark on my AS? Is this monitored even by the tier1s and 2s? Thanks. Regards, Gus C. ________________________________ Notice of Confidentiality: The information contained in this communication is intended solely for the use of the individual or entity to whom it is addressed and others authorized to receive it. It may contain confidential or legally privileged information. If you are not the intended recipient you are hereby notified that any disclosure, copying, distribution or taking any action in reliance on the contents of this information is strictly prohibited and may be unlawful. If you have received this communication in error, please notify us immediately by responding to this email and then delete it from your system.

3 2

New Zealand Spy Agency To Vet Network Builds, Provider Staff
by Paul Ferguson 14 May '14

14 May '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 I realize that New Zealand is *not* in North America (hence NANOG), but I figure that some global providers might be interested here. This sounds rather... dire (probably not the right word). "The new Telecommunications (Interception Capability and Security) Act of 2013 is in effect in New Zealand and brings in several drastic changes for ISPs, telcos and service providers. One of the country's spy agencies, the GCSB, gets to decide on network equipment procurement and design decisions (PDF), plus operators have to register with the police and obtain security clearance for some staff. Somewhat illogically, the NZ government pushed through the law combining mandated communications interception capabilities for law enforcement, with undefined network security requirements as decided by the GCSB. All network operators are subject to the new law, including local providers as well as the likes of Facebook, Google, Microsoft, who have opposed it, saying the new statutes clash with overseas privacy legislation." http://yro.slashdot.org/story/14/05/13/005259/new-zealand-spy-agency-to-vet… FYI, - - ferg - -- Paul Ferguson VP Threat Intelligence, IID PGP Public Key ID: 0x54DC85B2 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlNyHw4ACgkQKJasdVTchbLwDgD/WVHo2iTapJ90l8MRcwUZ5OQ7 QfJ5cI1v4t2bUXZp1hQBAKHCP0hyxg6naGOzRLt/vHjgxXnl3+yiWoj0ENxQyIr9 =0yLu -----END PGP SIGNATURE-----

14 22