- NANOG - lists.nanog.org

.io registrar
by Jeremy Kister 11 May '11

11 May '11

Does anyone know of a competent .io registrar who charges in the <= $75/yr area ? I've been using tierra.net (domaindiscover.com) but they continually break my domains. this year, although their website says my domain expires 4/2012, my domain stopped working today. the .io servers aren't serving records, and nic.io says the domain expired 4/8/2011. i got a hold of them this morning got a ticket -- but after 4 hours still no response. also, although nic.io lists a bunch of .io registrars, when I called them they almost all say "we don't register .io" :D -- Jeremy Kister http://jeremy.kister.net./

4 3

Fwd: 23,000 IP addresses
by Luis Marta 11 May '11

11 May '11

On Tue, May 10, 2011 at 3:38 PM, Michael Holstein < michael.holstein(a)csuohio.edu> wrote: > > > > http://www.wired.com/images_blogs/threatlevel/2011/05/expendibleipaddresses… > > > > The dates in the timestamps are back in February. We deleted those logs > "..in the regular course of business.." > a LONG TIME AGO. > > If you didn't do that, you really ought to ask yourself why. > > Regards, > > Michael Holstein > Information Security Administrator > Cleveland State University > In the EU you have Directive 2006/24/EC: http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=OJ:L:2006:105:0054:00… Article 6 - Periods of retention Member States shall ensure that the categories of data specified in Article 5 are retained for periods of not less than six months and not more than two years from the date of the communication. Article 5 - Categories of data to be retained 1. Member States shall ensure that the following categories of data are retained under this Directive: (a) data necessary to trace and identify the source of a communication: (...) the name and address of the subscriber or registered user to whom an Internet Protocol (IP) address, user ID or telephone number was allocated at the time of the communication; Each member state creates its own law, according to the directive. In Portugal, you have to retain the data for one year. Best Regards, Luís Marta.

10 12

Global Crossing Contact
by Righa Shake 11 May '11

11 May '11

Kindly would any contact from Global Crossing Please contact me offlist. Thanks. Regards, Righa Shake

1 0

Re: Downstream Usage-BGP Communites
by Nick Olsen 10 May '11

10 May '11

Ah, Sorry for the confusion. We have a mutual agreement with AS100 (call it transit or peering) we send them full routes, They send us full routes. AS100 is a transit customer of AS4323. I understand I would be at the mercy of how people have things setup. I do know for a fact I'm not filtered by AS100 as I've already tested it. Thanks to everyone for the info so far. Nick Olsen Network Operations (855) FLSPEED x106 ---------------------------------------- From: "Richard A Steenbergen" <ras(a)e-gerbil.net> Sent: Tuesday, May 10, 2011 6:27 PM To: "Nick Olsen" <nick(a)flhsi.com> Subject: Re: Downstream Usage-BGP Communites On Tue, May 10, 2011 at 05:52:39PM -0400, Nick Olsen wrote: > Greetings NANOG, > Was hoping to gain some insight into common practice with using BGP > Communities downstream. > > For instance: > We peer with AS100 (example) > AS100 peers with TW Telecom (AS4323). > Since I happen to know that AS100 doesn't sanitize the communities I send > with my routes. I can take advantage of TW Telecom's BGP communities for > traffic engineering. Such as 4323:666 (Keep in TWTC Backbone). Would this > be something that is generally frowned upon? Still under the assumption > that the communities aren't scrubbed off my routes. Could I do this with > other AS's beyond TW Telecom? Such as TW's peering with Global Crossing > (AS3549)? Well first off, if you're using the words "peers with" in the normal sense, your routes would never propagate to AS4323 in the first place. Assuming what you actually mean is that at least one of those sessions is a transit feed, essentially all (non-stupid) networks will filter their own TE communities from their transits/peers, so the odds of this working are almost non-existant. You also have about a 50/50 shot of AS100 stripping your communities before they even make it to AS4323 (or any other network). Personally my belief is that this is a bad thing, and you should only filter communities in your own name-space (i.e. $YOURASN:*), but this doesn't stop a large number of obnoxious networks from doing it anyways. :) -- 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)

2 1

Removal from mailing list
by Mitchell Manning 10 May '11

10 May '11

Can I please get taken off all nanog mailing list. Thanks, Mitch

4 4

Downstream Usage-BGP Communites
by Nick Olsen 10 May '11

10 May '11

Greetings NANOG, Was hoping to gain some insight into common practice with using BGP Communities downstream. For instance: We peer with AS100 (example) AS100 peers with TW Telecom (AS4323). Since I happen to know that AS100 doesn't sanitize the communities I send with my routes. I can take advantage of TW Telecom's BGP communities for traffic engineering. Such as 4323:666 (Keep in TWTC Backbone). Would this be something that is generally frowned upon? Still under the assumption that the communities aren't scrubbed off my routes. Could I do this with other AS's beyond TW Telecom? Such as TW's peering with Global Crossing (AS3549)? Nick Olsen Network Operations (855) FLSPEED x106

4 3

Gas Company?
by Santino Codispoti 10 May '11

10 May '11

I know this is a bit of an odd request but does anyone on the list work at a Gas company such has BP or Mobile?

1 0

Re: VPN tunnels between US and China dropping/slow
by Thomas York 10 May '11

10 May '11

Yes. Every day at roughly 2AM EDT the latency climbs to 700ms+ with about 25% packet loss and fluctuates until about 6-7AM. -- Thomas York Joel Jaeggli <joelja(a)bogus.com> wrote: >On 5/10/11 10:10 AM, Adam Rothschild wrote: >> Realize also that China Telecom is congested both internally and on >> certain peering interfaces. >> >> While DPI is a likely culprit, be sure to not overlook a good >> old-fashioned inability to manage capacity, combined with certain >> hashing algorithms... > >if you're measuring the end-to-end path you'll likely see evidenced of >the latency climbing on a near daily cycle. > >my median rtt from the us east coast is 268ms sometimes it's north of >370 with essentially the same loss properties. > >> -a >> >

1 0

Re: VPN tunnels between US and China dropping/slow
by Thomas York 10 May '11

10 May '11

I tried to tell my bosses that and I got a blank stare. -- Thomas York Adam Rothschild <asr(a)latency.net> wrote: >Realize also that China Telecom is congested both internally and on >certain peering interfaces. > >While DPI is a likely culprit, be sure to not overlook a good >old-fashioned inability to manage capacity, combined with certain >hashing algorithms... > >-a

1 0

VPN tunnels between US and China dropping/slow
by Thomas York 10 May '11

10 May '11

At my current place of business, we have several manufacturing plants in China as well as the United States. All of the plants have an OVPN tunnel to a datacenter here in Indianapolis which connect all of the plants. Our China plants pay for the basic 3mbit/3mbit fiber internet connections. I've had a hell of a time keeping their tunnels up. They're running on port 443 over TCP now, but every month or so the tunnel degrades so badly I have to switch the port. I've recently tried tunneling OVPN (UDP) over a GRE tunnel and that has worked for a few months..but even now is degrading. The interesting thing is that ONLY the tunnel traffic gets degraded. I've replaced all of the equipment on both ends of all of the VPN tunnels, which changed nothing. Currently, we're talking to Time Warner and some of our customers who have plants in China to see what solutions they're using to get around this kind of issue. One thing we are hearing quite often is that they're using a MPLS based connection to Hong Kong, then going to the USA from there. We're happy to try this, but due to cost issues we're (management mostly) considering this a last resort option. Are there any other options maybe some of you have to fixing this issue? Thanks Thomas York

6 5