December 2009 - Test - lists.nanog.org

IPv6 allocations, deaggregation, etc.
by George Bonser 24 Dec '09

24 Dec '09

We have decided to initiate the process of becoming IPv6 capable. We have requested and received a block of addresses which, after reading some of the discussion here, I fear may be too small to suit our needs (a /48). To better understand how to proceed and in an attempt to get it right (or close to right) the first time, I am soliciting opinions and comments from other network operators. It appears from earlier discussions on this list that while many networks will not filter a /48 announcement in their routing tables, others will. We have data centers and offices in three regions of the globe; North America, Europe, and Asia/Pacific. We are also multihomed as well as having some direct peering. I can break my /48 into /56 nets for each facility. My thought process here being that if I have the same transit providers at all sites, I can announce the /48 from my primary location and that would get announced by the transit provider. They would also accept my more specific routes but not announce them outside of their AS. So traffic originating outside of my transit provider would flow toward them following the /48 and they then move the traffic to the final destination based on the more specific and in the case the traffic has no more specific route, hand the traffic to my main location for me to sort out or just black hole it. There are two problems with this approach. 1: We are unreachable from anyone filtering a /48 and 2: I could see a situation where traffic crosses the Pacific, is handed to my transit provider, and then crosses the Pacific again to get to the destination resulting in poor performance. So it now seems to me that maybe a larger block might be the best answer but being an "end user" the policies seem pretty restrictive on getting a /32 though I might qualify for several /48 blocks (at least one in each registry region). So how does one reconcile having a diverse, multihomed organization on several continents while at the same time trying to do the right thing, not requesting more resources than we need, and trying to be friendly to the various networks' operations by advertizing only what we need to? Is it unreasonable to get separate /48 blocks for operations in Europe, North America, and Asia or possibly two for Asia (one in China and one for Asia outside of China)? While that still won't help us with connectivity from networks filtering /48's, it might relieve much of the back and forth transit across oceans to get traffic originating from and destined for the same continent to stay there. I don't have a problem with regional backhaul tying an office /56 to a data center announcing a /48 and using that data center as a communications hub for the region. It also assumes a transit provider I am paying to haul my traffic will take "more specifics" for internal use even if they aren't advertizing them. I am just trying to minimize the stupidity and barriers to scale on my side of the equation.

6 10

RE: IPv6 allocations, deaggregation, etc.
by George Bonser 24 Dec '09

24 Dec '09

Apologies in advance for the top post. My initial idea was to use a /48, divide it up into /56 nets for each facility with /64 subnets within each facility. We would announce a /48 to our transit providers that I would expect them to announce in turn to their peers and we would also announce the more specific /56 nets to the transit providers that I would expect them not to announce to their peers. My current vlan requirements per facility would support such an addressing plan. In order to make that work, we would need the same transit providers in each region as our locations are not meshed internally. We don’t have dedicated connectivity from the US to the UK or China, for example. Currently that is not a problem as far as connectivity is concerned as my US providers appear in Europe and my China provider appears in the US. BUT when I consider the possibilities of South America and Africa and finding a transit provider that has a robust presence everywhere, my choices are very limited. I need to be multihomed and I need to be provider agnostic in my addressing. Using that scheme above does create some potential performance issues. While my transit provider collects the traffic from a remote location and routes it to the more specific location in my network, If a provider in Europe, for example, sees only the /48 announced from the US, maybe they haul the traffic across an ocean to a point where they peer with my provider … who then must haul it back to Europe to the /56 corresponding to the destination because the original traffic source doesn’t see my /56 unless they are using the same transit provider I am. Then based on earlier discussion on the list a while back, I was concerned that a /48 wasn’t even enough to get me connected to some nets that were apparently filtering smaller than a /48 but my mind is somewhat eased in that respect and I believe that a /48 announced from space where /48s are issued will be accepted by most people. Then I was informed of ARIN 2009-5 which seems aimed at our situation; data centers widely separated by large geographical distances that are fairly autonomous and aren’t directly connected by dedicated links. It now seems that we (and the rest of the Internet) might be better served if we get a RIPE AS and net block for our Europe operations, and APNIC AS and net block for our APAC operations and get a regional /48 that I can split into /56 nets for the various satellite facilities within that region as those satellite offices CAN be directly connected to the regional data center which would act as the regional communications hub. There are probably 16 different ways to slice this but I would like to get it as close to “right” as possible to prevent us having to renumber later while at the same time not taking more space than we need. A /48 per region seems like the right way to go at the present time. So we would have a /48 for the US, a /48 for Asia (and possibly one /48 dedicated to China) and a /48 for Europe. Satellite facilities would collect a /56 (or two or three) out of that regional block for their local use. Then I am free from being nailed to the same providers globally and have less chance of traffic crossing an ocean twice. The probability of needing 200 /48s in the next several years is pretty slim and do not warrant our getting a /32 when currently three or four /48 nets will fill the requirements. Thanks again for the input, Mick. George From: Mick O'Rourke [mailto:mkorourke@gmail.com] Sent: Tuesday, December 22, 2009 10:43 PM To: Joel Jaeggli Cc: George Bonser; nanog(a)nanog.org Subject: Re: IPv6 allocations, deaggregation, etc. Is the idea behind the /48 being looked at (keeping in mind a mixed IPv4/IPv6 environment & http://www.ietf.org/rfc/rfc5375.txt <http://www.ietf.org/rfc/rfc5375.txt%20> page 8) to have a /64 per smaller branch or VLAN, larger campus /56, and advertise out the /48 for the region?; My previous thinking and biggest thinking point is enterprise level address allocation policy, impacts to device loopbacks, voice vlans, operational simplification requirements for management and security layers etc. The feel overall has been towards needing to have a /32, a /56 per site (campus to small branch) and internally within the site /64 per VLAN. A /48 becomes too small, a /32 very much borderline. Is this a similar scenario for you? How are you justifying a /48 vs a /32?

2 2

The cost of nines
by Eric Brunner-Williams 24 Dec '09

24 Dec '09

Hi all, On the 7th of next month I'll be participating in an ICANN consultation on the proposed draft registry agreement, and the number of "nines" that have crept into it, relative to what was expected of new registry operators a decade ago, is one of the hidden cost increases I will discuss with ICANN's lawyers, who are responsible for the extra nines. I'm looking for sources of cost-per-nine, network provisioning, and host provisioning, where "host" is usually a bunch of boxen, not just a pizza box. The way the requirements are now, a startup of another .museum, say for libraries or archives, or a new .coop, or a new linguistic and cultural say a .scot, has to provide a higher level of performance than Verisign currently does for com/net/name, which is slightly absurd, if not worse. I can cite sources, or not, as preferred, and while CORE is comfortable at any number ICANN's lawyers can come up with under the theory that "more nines is what security and stability mean", my goal is to allow real startups, like .museum and .coop were in 2001, not be forced to outsource registry operations to an already highly capitalized registry service provider, for competition policy reasons. I'm also "in the market" for recent failure data, such as Ultra's yesterday, and Verisign's v6, not for competitive reasons, but to show that the SLA expectation of ICANN's lawyers may need modification if placed proximal to actual operational failure data. Off-list or on, and thanks in advance, from my Yule tree to your own. Cheers, Eric

1 0

Re: Revisiting the Aviation Safety vs. Networking discussion
by Scott Weeks 24 Dec '09

24 Dec '09

<flameproof panties == ON> :-) :mops work. It depends on who wrote it and the experience the person has (on the particular network) who generated it.. scott

1 0

Re: Revisiting the Aviation Safety vs. Networking discussion
by Scott Weeks 24 Dec '09

24 Dec '09

: this works in a tech culture where folk follow mops obsessively. my : experience is that most north americam engineers are too smart to do : that, and take shoprtcuts > and _do_ slap down any attempt to deviate : imagine a network engineering culture where the concept of 'attempt to : deviate' just does not occur > the network group is under control Hopefully, at least some of that was tongue-in-cheek. For managers: saved LOTS of dollars when deviating from MoPs by fixing AFU things not thought of in the MoP. For fellow netgeeks: no one woke you up because the AFU things were fixed while you slept. scott

1 0

Ipsec/VRF Mpls ?
by Stephane MAGAND 24 Dec '09

24 Dec '09

Hi after a first post with 0 answer (very thanks ..) i test a second post for get a small help. I am search a simple sample of configuration for a cisco 2821 for connect a Ipsec routers ton a MPLS IP VPN Backbone My cisco 2821 have two interface, one connected at my MPLS network and the second at the Internet. I create two vrf, one for a site to site and the second for a Remote User Access anyone have this into a config ? because i never have used Ipsec actually on cisco. The site-to-site router are a C1721, and remote user use cisco IPSEC client and i want a radius authentification (and it's the radius that sent the vrf) thanks for your help Stephane

2 1

re: used hardware
by Bill Lewis 23 Dec '09

23 Dec '09

http://www.networkhardware.com/ContactNHR/ Mostly Cisco, but I think they'll do Juniper. Bill ---------------------------------------------------------------------- -Date: Fri, 18 Dec 2009 04:34:05 -0800 -From: Mehmet Akcin <mehmet(a)akcin.net> -Subject: used hardware.. -To: "nanog(a)nanog.org list" <nanog(a)nanog.org> -Message-ID: <16E6D13C-AB9C-4EA5-8E73-59172DD2866B(a)akcin.net> -Content-Type: text/plain; charset=us-ascii -Hello there.. -I am looking to sell and buy some used hardware, where is the best place for this, other than ebay ? -Mostly juniper stuff -thanks in advance. -Mehmet

3 2

Re: [NANOG] Roport on internet business
by Scott Weeks 23 Dec '09

23 Dec '09

--- takashi(a)cpqd.com.br wrote: From: "Takashi Tome" <takashi(a)cpqd.com.br> Morgan Stanley has released a very interesting report on internet business with some tips to net operators: http://www.morganstanley.com/institutional/techresearch/mobile_internet_rep… ------------------------------------------------------- It must be purchased: ---------------------- The Mobile Internet Report To receive a printed copy of The Mobile Internet Report, please contact your Morgan Stanley Representative. To purchase a copy, please click here. ---------------------- scott

5 5

UltraDNS Failure?
by Mark Pace 23 Dec '09

23 Dec '09

Anyone else having problems resolving DNS from UltraDNS? I'm seeing this: $ dig www.ultradns.com @8.8.8.8 ; <<>> DiG 9.6.0-P1 <<>> www.ultradns.com @8.8.8.8 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 26650 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;www.ultradns.com. IN A ;; Query time: 38 msec ;; SERVER: 8.8.8.8#53(8.8.8.8) ;; WHEN: Wed Dec 23 16:59:39 2009 ;; MSG SIZE rcvd: 34 $ dig www.ultradns.com +trace ;; Truncated, retrying in TCP mode. ; <<>> DiG 9.6.0-P1 <<>> www.ultradns.com +trace ;; global options: +cmd . 490316 IN NS d.root-servers.net. . 490316 IN NS k.root-servers.net. . 490316 IN NS j.root-servers.net. . 490316 IN NS h.root-servers.net. . 490316 IN NS g.root-servers.net. . 490316 IN NS m.root-servers.net. . 490316 IN NS c.root-servers.net. . 490316 IN NS i.root-servers.net. . 490316 IN NS b.root-servers.net. . 490316 IN NS e.root-servers.net. . 490316 IN NS a.root-servers.net. . 490316 IN NS l.root-servers.net. . 490316 IN NS f.root-servers.net. . 490316 IN NS d.root-servers.net. . 490316 IN NS k.root-servers.net. . 490316 IN NS j.root-servers.net. . 490316 IN NS h.root-servers.net. . 490316 IN NS g.root-servers.net. . 490316 IN NS m.root-servers.net. . 490316 IN NS c.root-servers.net. . 490316 IN NS i.root-servers.net. . 490316 IN NS b.root-servers.net. . 490316 IN NS e.root-servers.net. . 490316 IN NS a.root-servers.net. . 490316 IN NS l.root-servers.net. . 490316 IN NS f.root-servers.net. ;; Received 717 bytes from 10.23.69.254#53(10.23.69.254) in 52 ms com. 172800 IN NS C.GTLD-SERVERS.NET. com. 172800 IN NS A.GTLD-SERVERS.NET. com. 172800 IN NS G.GTLD-SERVERS.NET. com. 172800 IN NS I.GTLD-SERVERS.NET. com. 172800 IN NS D.GTLD-SERVERS.NET. com. 172800 IN NS E.GTLD-SERVERS.NET. com. 172800 IN NS B.GTLD-SERVERS.NET. com. 172800 IN NS J.GTLD-SERVERS.NET. com. 172800 IN NS K.GTLD-SERVERS.NET. com. 172800 IN NS H.GTLD-SERVERS.NET. com. 172800 IN NS F.GTLD-SERVERS.NET. com. 172800 IN NS L.GTLD-SERVERS.NET. com. 172800 IN NS M.GTLD-SERVERS.NET. ;; Received 522 bytes from 192.228.79.201#53(b.root-servers.net) in 70 ms ultradns.com. 172800 IN NS pdns1.ultradns.net. ultradns.com. 172800 IN NS pdns2.ultradns.net. ultradns.com. 172800 IN NS pdns3.ultradns.org. ultradns.com. 172800 IN NS pdns4.ultradns.org. ultradns.com. 172800 IN NS pdns5.ultradns.info. ultradns.com. 172800 IN NS pdns6.ultradns.co.uk. ;; Received 237 bytes from 192.52.178.30#53(K.GTLD-SERVERS.NET) in 374 ms ;; connection timed out; no servers could be reached

4 8

Re: UltraDNS Failure?
by Stefan Fouant 23 Dec '09

23 Dec '09

There have been several DNS based DDoS observed throughout the day targetting Ultra as well as a few other companies. They were first observed earlier in the morning on the East coast. ------Original Message------ From: Richard A Steenbergen To: Shrdlu Cc: Nanog Subject: Re: UltraDNS Failure? Sent: Dec 23, 2009 8:42 PM On Wed, Dec 23, 2009 at 05:38:21PM -0800, Shrdlu wrote: > I'm still seeing the DNS servers at udns down, hard. Amazon's cloud will > need a reboot when this is over. Dang, what the heck happened to all > that anycast stuff? We have some DNS providing type customers (not UltraDNS) receiving a few million packets/sec of UDP/53 DoS traffic, starting at about the same time as the UltraDNS problems. No clue if it's related, but it certainly sounds suspicious. :) -- Richard A Steenbergen <ras(a)e-gerbil.net> http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) Sent from my Verizon Wireless BlackBerry

1 0