October 2009 - Test - lists.nanog.org

Need a clueful Telia AS1299 engineer
by Jeffrey Lyon 22 Oct '09

22 Oct '09

Could a clueful AS1299 engineer please drop me a line? Dealing with the Level 0 technicians that are offered to IC clients is completely useless in diagnosing a rather serious issue. -- Jeffrey Lyon, Leadership Team jeffrey.lyon(a)blacklotus.net | http://www.blacklotus.net Black Lotus Communications of The IRC Company, Inc. Platinum sponsor of HostingCon 2010. Come to Austin, TX on July 19 - 21 to find out how to "protect your booty."

2 1

IPv6 internet broken, cogent/telia/hurricane not peering
by Igor Ybema 22 Oct '09

22 Oct '09

Hi, I recently noticed that there seems a peering issue on the ipv6 internet. As we all know hurricane is currently the largest ipv6 carrier. Other large carriers are now implementing ipv6 on their networks, like Cogent and Telia. However, due to some politics it seems that they are not peering with each other resulting in a broken ipv6 internet currently. I noticed this by using the looking glasses from telia and hurricane. This is only a real problem if you use hurricane as the only transit. However, hurricane also announces 6to4 relays. When you happen to use the hurricane relay server (due to the shortest path), cogent and telia (and maybe more) are not reachable. I already asked hurricane about their point of view. They simply just ignore it because they 'are the biggest one'. I'm currious about you point of view. regards, Igor Ybema Senior network Administrator Oxilion

28 64

Fwd: [IP] [warning: layer 8/9] "Strange bedfellows, " aka a joint statement from Verizon Wireless and Google
by tvest＠eyeconomics.com 22 Oct '09

22 Oct '09

Interesting, curious... but meaningful? To my mind Google's language seems to be focused on wireline issues, which I guess are probably quite a bit easier for Verizon Wireless to accommodate. Conversely, VW's emphasis on continuing self-regulation of wireless access would seem to be of secondary importance, at best, to Google. Does this mean that a future of combat over "my (TCP) ports" is somewhat less likely? Does this mean that Google won't be offering me FTTH within the next 2-3 years? Inquiring minds take note! TV Begin forwarded message: > From: David Farber <dave(a)farber.net> > Date: October 22, 2009 7:27:48 AM EDT > To: "ip" <ip(a)v2.listbox.com> > Subject: [IP] Finding Common Ground on an Open Internet - a joint > statement from Lowell McAdam, CEO Verizon Wireless and Eric Schmidt, > CEO Google. > Reply-To: dave(a)farber.net > > A Technology and Telecommunications Policy Blog > Thursday, October 22, 2009 > > Finding Common Ground on an Open Internet > > The following is a joint statement from Lowell McAdam, CEO Verizon > Wireless and Eric Schmidt, CEO Google. > > > Verizon and Google might seem unlikely bedfellows in the current > debate > around network neutrality, or an open Internet. And while it's true we > do disagree quite strongly about certain aspects of government > policy in > this area--such as whether mobile networks should even be part of the > discussion--there are many issues on which we agree. For starters we > both think it's essential that the Internet remains an unrestricted > and > open platform--where people can access any content (so long as it's > legal), as well as the services and applications of their choice. > > > > There are two key factors driving innovation on the web today. First > is > the programming language of the Internet, which was designed over > forty > years ago by engineers who wanted the freedom to communicate from any > computer, anywhere in the world. It enables Macs to talk to PCs, > Blackberry Storms to iPhones, the newest computers to the oldest > hardware on the planet across any kind of network--cable, DSL, fiber, > mobile, WiFi or even dial up. > > > > Second, private investment is dramatically increasing broadband > capacity > and the intelligence of networks, creating the infrastructure to > support > ever more sophisticated applications. > > > > As a result, however or wherever you access the Internet the people > you > want to connect with can receive your message. There is no central > authority that can step in and prevent you from talking to someone > else, > or that imposes rules prescribing what services should be available. > > > > Transformative is an over-used word, especially in the tech sector. > But > the Internet has genuinely changed the world. Consumers of all stripes > can decide which services they want to use and the companies they > trust > to provide them. In addition, if you're an entrepreneur with a big > idea, > you can launch your service online and instantly connect to an > audience > of billions. You don't need advance permission to use the network. At > the same time, network providers are free to develop new applications, > either on their own or in collaboration with others. > > > > This kind of "innovation without permission" has changed the way we do > business forever, fueling unprecedented collaboration, creativity and > opportunity. And because America has been at the forefront of most of > these changes, we have disproportionately benefited in terms of > economic > growth and job creation. > > > > So, in conjunction with the Federal Communications Commission's > national > plan to bring broadband to all Americans, we understand its decision > to > start a debate about how best to protect and promote the openness of > the > Internet. FCC Chairman Julius Genachowski has promised a thoughtful, > transparent decision-making process, and we look forward to taking > part > in the analysis and discussion that is to follow. We believe this kind > of process can work, because as the two of us have debated these > issues > we have found a number of basic concepts to agree on. > > > > First, it's obvious that users should continue to have the final say > about their web experience, from the networks and software they use, > to > the hardware they plug in to the Internet and the services they access > online. The Internet revolution has been people powered from the very > beginning, and should remain so. The minute that anyone, whether from > government or the private sector, starts to control how people use the > Internet, it is the beginning of the end of the Net as we know it. > > > > Second, advanced and open networks are essential to the future > development of the Web. Policies that continue to provide incentives > for > investment and innovation are a vital part of the debate we are now > beginning. > > > > Third, the FCC's existing wireline broadband principles make clear > that > users are in charge of all aspects of their Internet experience--from > access to apps and content. So we think it makes sense for the > Commission to establish that these existing principles are > enforceable, > and implement them on a case-by-case basis. > > > > Fourth, we're in wild agreement that in this rapidly changing Internet > ecosystem, flexibility in government policy is key. Policymakers > sometimes fall prey to the temptation to write overly detailed rules, > attempting to predict every possible scenario and address every > possible > concern. This can have unintended consequences. > > > > Fifth, broadband network providers should have the flexibility to > manage > their networks to deal with issues like traffic congestion, spam, > "malware" and denial of service attacks, as well as other threats that > may emerge in the future--so long as they do it reasonably, consistent > with their customers' preferences, and don't unreasonably discriminate > in ways that either harm users or are anti-competitive. They should > also > be free to offer managed network services, such as IP television. > > > > Finally, transparency is a must. Chairman Genachowski has proposed > adding this principle to the FCC's guidelines, and we both support > this > step. All providers of broadband access, services and applications > should provide their customers with clear information about their > offerings. > > > > Doubtless, there will be disagreements along the way. While Verizon > supports openness across its networks, it believes that there is no > evidence of a problem today -- especially for wireless -- and no basis > for new rules and that regulation in the US could have a detrimental > effect globally. While Google supports light touch regulation, it > believes that safeguards are needed to combat the incentives for > carriers to pick winners and losers online. > > > > Both of our businesses rely on each other. So we believe it's > appropriate to discuss how we ensure that consumers can get the > information, products, and services they want online, encourage > investment in advanced networks and ensure the openness of the web > around the world. We're ready to engage in this important policy > discussion.

1 0

Re: Consistent asymetric latency on monitoring?
by Rick Ernst 22 Oct '09

22 Oct '09

Resent, since I responded from the wrong address: --- The basic operation of IP SLA is as surmised; payload with timestamps and other telemetry data is sent to a 'responder' which manipulates the payload, including adding its own timestamps, and returns the altered payload. I had to do a mental walk-through, but I think I see how drift can cause this. I'm going to generate some artificial data, graph it, and see if it matches the general waveshape I'm seeing. I purposefully have the traffic generators ntp syncing against the responders. I thought that would keep the clocks more closely in sync. I don't necessarily care if the time is 'right', just that it's the same. What kind of difference should I expect if I sync both generators and responders against the same source, or not sync the responder? I'm thinking that having one source with constant drift may be better than both devices trying to walk/correct the time. Thanks for the input! On Wed, Oct 21, 2009 at 8:01 PM, Rick Ernst <ernst(a)shreddedmail.com> wrote: > Resent, since I responded from the wrong address: > --- > The basic operation of IP SLA is as surmised; payload with timestamps > and other telemetry data is sent to a 'responder' which manipulates > the payload, including adding its own timestamps, and returns the > altered payload. > > I had to do a mental walk-through, but I think I see how drift can > cause this. I'm going to generate some artificial data, graph it, and > see if it matches the general waveshape I'm seeing. > > I purposefully have the traffic generators ntp syncing against the > responders. I thought that would keep the clocks more closely in sync. > I don't necessarily care if the time is 'right', just that it's the > same. What kind of difference should I expect if I sync both > generators and responders against the same source, or not sync the > responder? I'm thinking that having one source with constant drift may > be better than both devices trying to walk/correct the time. > > Thanks for the input! > > > On Wed, Oct 21, 2009 at 7:55 PM, Rick Ernst <ernst(a)shreddedmail.com>wrote: > >> The basic operation of IP SLA is as surmised; payload with timestamps >> and other telemetry data is sent to a 'responder' which manipulates >> the payload, including adding its own timestamps, and returns the >> altered payload. >> >> I had to do a mental walk-through, but I think I see how drift can >> cause this. I'm going to generate some artificial data, graph it, and >> see if it matches the general waveshape I'm seeing. >> >> I purposefully have the traffic generators ntp syncing against the >> responders. I thought that would keep the clocks more closely in sync. >> I don't necessarily care if the time is 'right', just that it's the >> same. What kind of difference should I expect if I sync both >> generators and responders against the same source, or not sync the >> responder? I'm thinking that having one source with constant drift may >> be better than both devices trying to walk/correct the time. >> >> Thanks for the input! >> >> >> On Wednesday, October 21, 2009, Nathan Ward <nanog(a)daork.net> wrote: >> > On 22/10/2009, at 2:31 PM, Perry Lorier wrote: >> > >> > >> > I assume this product works by having a packet with a timestamp sent >> from the source to the destination where it is timestamped again and either >> sent back, or another packet is sent in the other direction. The difference >> between the two timestamps gives you the latency in that direction. >> > >> > >> > I believe a packet is sent, and the target router responds with a >> timestamp. >> > >> > But yeah, timestamps are being compared. >> > >> > I'm with Perry though - sounds like your clocks are drifting. >> > >> > -- >> > Nathan Ward >> > >> > >> > >

3 3

Consistent asymetric latency on monitoring?
by Rick Ernst 22 Oct '09

22 Oct '09

Although the implementation is Cisco-specific, this feels more appropriate for NANOG. We've started rolling out a state-wide monitoring system based on Cisco's "IP SLA" feature set. Out of 5 sites deployed so far (different locations, different providers), we are consistently seeing one-way latency mirror the opposite direction. As source-destination latency goes up, destination-source latency goes down and vice versa. Myself and the monitoring team have ripped apart the OIDs, IP SLA configuration, and monitoring system. We've also built an ad-hoc system to compare the results. It's still consistent behavior. It's not a true mirror; there is definitely variation between the data collection, but at the 10,000 foot level, there is an obvious and consistent mirror to the data. The network topology is independant service providers all providing backhaul to a local ethernet exchange. Has anybody seen this type of behavior? We are solidly convinced that we are using the proper OIDs and making the proper transformations of the data. The two remaining causes appear to be either "natural behavior of the links" and/or "artifact in the IP SLA mechanism". Any ideas? Thanks!

4 3

Re: NetFlow analyzer software
by Michael J McCafferty 22 Oct '09

22 Oct '09

ManageEngine's product is the one that kills browsers because you can tell it to list the top X ASNs. ------Original Message------ From: Brian R. Watters To: nanog(a)nanog.org Cc: nanog(a)nanog.org ReplyTo: Brian R. Watters Subject: RE: NetFlow analyzer software Sent: Oct 19, 2009 10:45 AM We have used this product with great success and its reasonable in pricing and well supported. http://www.manageengine.com/products/netflow/index.html BRW -----Original Message----- From: mark jackson [mailto:markcciejackson@gmail.com] Sent: Monday, October 19, 2009 10:47 AM To: mike(a)m5computersecurity.com Cc: nanog(a)nanog.org Subject: Re: NetFlow analyzer software What's up gold Mrtpg Scrtinizer Nagios Riverbed Cascade Solarwinds Sent from my iPhone Please excuse spelling errors On Oct 19, 2009, at 10:43 AM, "Michael J McCafferty" <mike(a)m5computersecurity.com > wrote: > All, > I am looking for decent netflow analyzer and reporting software > with good support for AS data. > ManagEngine's product crashes or locks up my browser when I try to > list/sort the AS info because it's too large of a list and there is > no way to tell it to show just the top x results. > Plixer's Scrutenizer, while it seems like it's a pretty decent > product, is no longer supporting Linux... We are a Linux shop > (servers, desktops, laptops). > What else is there that I might want to look at? > > Thanks! > Mike > M5Hosting.com > Sent from my Verizon Wireless BlackBerry > Sent from my Verizon Wireless BlackBerry

4 3

Re: ISP customer assignments
by Robert.E.VanOrmer＠frb.gov 22 Oct '09

22 Oct '09

The address space is daunting in scale as you have noted, but I don't see any lessons learned in address allocation between IPv6 and IPv4. Consider as a residential customer, I will be provided a /64, which means each individual on Earth will have roughly 1 billion addresses each. Organizations will be provided /48s or smaller, but given the current issues with routing /48's globally, I think you will find more organizations fighting for /32s or smaller... so what once was a astonomical number of addresses that one cannot concieve numerically, soon becomes much smaller. I can see an IPv7 in the future, and doing it all over again... I just hope I retire before it comes... The only difference I can see between IPv4 and IPv6 is how much of a pain it is to type a 128 bit address... Just like back in the day when Class B networks were handed out like candy, one day we will be figuring out how to put in emergency allocations on the ARIN listserv for IPv6 because of address exhaustion and waste. Food for thought... >Message: 3 >Date: Mon, 5 Oct 2009 17:47:12 -0400 >From: Dorn Hetzel <dhetzel(a)gmail.com> >Subject: Re: ISP customer assignments >To: bmanning(a)vacation.karoshi.com >Cc: NANOG list <nanog(a)nanog.org> >Message-ID: > <7db2dcf90910051447r5bd7e42fja0b750dceb8d764(a)mail.gmail.com> >Content-Type: text/plain; charset=ISO-8859-1 > >The estimated mass of our galaxy is around 6x10^42Kg. The mass of earth is a >little less than 6x10^24Kg. > > 2^128 is around 3.4x10^38. >So in a flat address space we have about one IPV6 address for every 20,000Kg >in the galaxy or for every 20 picograms in the earth... > >One would hope it would last for a while :) > >On Mon, Oct 5, 2009 at 5:32 PM, <bmanning(a)vacation.karoshi.com> wrote: > >> >> considered top posting to irritate a few folks, decided not to. >> >> >> On Mon, Oct 05, 2009 at 04:20:44PM -0500, Chris Owen wrote: >> > On Oct 5, 2009, at 1:43 PM, Wayne E. Bouchard wrote: >> > >> > >Whenever you declare something to be "inexhasutable" all you do is >> > >increase demand. Eventually you reach a point where you realize that >> > >there is, in fact, a limit to the inexhaustable resource. >> > >> > This is where I think there is a major disconnect on IPv6. The size >> > of the pool is just so large that people just can't wrap their heads >> > around it. >> > >> > 2^128 is enough space for every man, woman and child on the planet to >> > have around 4 billion /64s to themselves. Even if we assume everyone >> > might possibly need say 10 /64s per person that still means we are >> > covered until the population hits around 2,600,000,000,000,000,000. >> > >> > Chris >> > >> >> here, you expose a hidebound bias to 20th century networking. >> please remember that - with few exceptions - people network >> at a very different level than machines. people don't need >> IP addresses - computing nodes that want to communicate do. >> >> Just for grins, put a unique IPv6 address in every active RFID >> tag. ... and remember that there are RFID printers that can >> put 18 tags on a single A4 sheet. Numbers will become disposible, >> like starbucks coffee cups and MCD's bigmac containers. >> >> --bill >> >>

56 117

equinix is acquiring switch & data
by Cord MacLeod 21 Oct '09

21 Oct '09

http://www.equinix.com/news/press/na/2009/news-5109/ Thought this was relevant.

3 2

Re: IPv6 Deployment for the LAN
by Karl Auer 21 Oct '09

21 Oct '09

On Sat, 2009-10-17 at 20:55 -0400, Ray Soucy wrote: > making use of SLAAC. The concern here is that older hosts with less > than OK implementations will still enable IPv6 without regard for the > stability and security concerns associated with IPv6. Some hosts - very dumb ones or very old ones, probably embedded stacks - may do SLAAC even with a prefix other than 64 bits! Once a stack is broken,, anything is possible, so I'm not sure you win much here. Zig to avoid one dud, you'll have to zag to avoid thenext, and before you know it your life is nothing but dodging. Take the high ground instead. Better to find and cure/replace/isolate broken hosts than break your entire network just to accommodate them. If you start doing the "wrong thing" to accommodate broken hosts, you will never find peace. Zig to avoid one dud; you'll have to zag to avoid the next and before you know it your life is nothing but dodging. Take the high ground instead. Do the advertisements "right", advise sysadmins that hosts should not do SLAAC, and (if you are really concerned about broken hosts) collect MAC address information from your switches and do an automated test of reachability on all SLAAC addresses. You can generate the addresses yourself easily enough from the prefix and the MAC. None should be reachable, and any that are - well, you now know where they are and can take appropriate action. And then block all SLAAC addresses at your routers or firewalls, that'll larn 'em :-) Regards, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer(a)biplane.com.au) +61-2-64957160 (h) http://www.biplane.com.au/~kauer/ +61-428-957160 (mob) GPG fingerprint: 07F3 1DF9 9D45 8BCD 7DD5 00CE 4A44 6A03 F43A 7DEF

4 4

[DHCPv6] was Re: IPv6 Deployment for the LAN
by James R. Cutler 21 Oct '09

21 Oct '09

We have networks and businesses to run. Why are we rehashing this yet again? For example, in December 200l http://www.merit.edu/mail.archives/nanog/2007-12/msg00280.html shows messages regarding exactly this issue. for emphasis I redundantly requote, "You have seen this before from me: Consider the Customer/Business Management viewpoint, not just that of routing packets around between boxes. Pull your head out of your patch panel and look at all the business requirements. If you can show me a more cost effective way to distribute all the parameters mentioned here to all end systems, I'll support it. In the meantime, don't use religious arguments to prevent me from using whatever is appropriate to manage my business. I'll even use NAT boxes, if there is no equivalently affordable stateful firewall box!" Just in case the URL is faulty, here is the primary content of the referenced page of NANOG list history: And, besides the list forwarded below, Designated printers, Preferred DNS Servers, and, maybe, more. Even in a large enterprise, the ratio of "routers" to DHCP servers makes control of many end system parameters via DHCP a management win compared to configuration of "routers" with this "non-network core" data. (In case I was to abstruse, It is cheaper to maintain end system parameters in a smaller number of DHCP servers than in a larger number of "routers".) This is completely separate from the fact that many experienced router engineers are smart enough configure routers with NTP server addresses in preference to DNS names, and likewise for many other parameters. The end system population has requirements which respond much more dynamically to business requirements than do router configurations, which respond mostly to wiring configurations which are, by comparison, static. The statement that DHCP is not needed for IPv6 packet routing may well be exactly accurate. The absence of good DHCP support in IPv6 has costly consequences for enterprise management, of which IP routing is a small part. You have seen this before from me: Consider the Customer/Business Management viewpoint, not just that of routing packets around between boxes. Pull your head out of your patch panel and look at all the business requirements. If you can show me a more cost effective way to distribute all the parameters mentioned here to all end systems, I'll support it. In the meantime, don't use religious arguments to prevent me from using whatever is appropriate to manage my business. I'll even use NAT boxes, if there is no equivalently affordable stateful firewall box! Cutler Begin forwarded message: From: Leo Bicknell <bicknell@xxxxxxx> Date: December 27, 2007 7:33:08 PM EST To: North American Network Operators Group <nanog@xxxxxxxxx> Subject: Re: v6 subnet size for DSL & leased line customers In a message written on Thu, Dec 27, 2007 at 10:57:59PM +0100, Iljitsch van Beijnum wrote: It is wih IPv6: you just connect the ethernet cable and the RAs take care of the rest. _You_ _really_ _don't_ _need_ _DHCP_ _for_ _IPv6_. If you need extreme control then manual configuration will give you that, which may be appropriate in some cases, such as servers. Really. I didn't know RA's could: - Configure NTP servers for me. - Tell me where to netboot from. - Enter dynamic DNS entries in the DNS tree for me. - Tell me my domain name. - Tell me the VLAN to use for IP Telephony. Those are things I use on a regular basis I'd really rather not manually configure. -- Leo Bicknell - bicknell@xxxxxxx - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - tmbg-list-request@xxxxxxxx, www.tmbg.org James R. Cutler james.cutler(a)consultant.com

1 0