December 2012 - Test - lists.nanog.org

China Telecom VPN problems (again)
by Thomas York 06 Dec '12

06 Dec '12

It looks like I'm having China Telecom issues yet again. They're batting down our SSL VPN tunnels. Switching ports doesn't help. Tunneling the SSL tunnel inside of another tunnel doesn't help. At this point I'm tired of listening to the screaming by the business users. Can someone contact me (here or off-list, I don't care) about circuits in China so that we don't have to use China Telecom? We'd only need 2-10 Mbit and Ethernet hand off. We don't need BGP or MPLS or anything remotely fancy. Our main concern is getting connectivity to the business district in Suzhou, but it'd be nice if we could also use the same carrier in Shenzhen. Thanks! -- Thomas York

7 10

Streaming video traffic increase from Level3?
by Frank Bulk 06 Dec '12

06 Dec '12

This evening I saw a quadruple increase in traffic volume from Level3 address space, a one-third increase in peak streaming video usage overall, and when I did a few checks with our netflow tool, it looks like customers that were streaming Netflix content just days before are now getting it out of Level3 space rather than our local cache or our upstream provider's Netflix cache. We also exceeded our previous peak usage by 12%. Did something change with Netflix that would have resulted in greater usage? Did Netflix defaults change so that customers are now using HD, or a higher-rate bitrate HD? Frank

1 1

Re: Cogent outage?
by Nick Olsen 06 Dec '12

06 Dec '12

No issues seen in Orlando either. Nick Olsen Network Operations (855) FLSPEED x106 ---------------------------------------- From: "Steven Saner" <ssaner(a)hubris.net> Sent: Thursday, December 06, 2012 12:17 PM To: nanog(a)nanog.org Subject: Re: Cogent outage? On 12/06/2012 11:11 AM, Matthew Huff wrote: > About 10 minutes ago we stopped being able to pass traffic through cogent. I de-peered us from Cogent, and everything appears > better. When I call cogent, all I get is a busy signal (must be a major outage). Anyone else seeing anything? > Passing normal traffic in Kansas City. Steve -- -------------------------------------------------------------------------- Steven Saner <ssaner(a)hubris.net> Voice: 316-858-3000 Director of Network Operations Fax: 316-858-3001 Hubris Communications http://www.hubris.net

2 1

Fwd: [Infowarrior] - Leaked: ITU's secret Internet surveillance standard discussion draft]
by Rich Kulawiec 06 Dec '12

06 Dec '12

----- Forwarded message from Richard Forno <rforno(a)infowarrior.org> ----- > From: Richard Forno <rforno(a)infowarrior.org> > Date: Thu, 6 Dec 2012 08:21:15 -0500 > To: Infowarrior List <infowarrior(a)attrition.org> > Subject: [Infowarrior] - Leaked: ITU's secret Internet surveillance standard > discussion draft > > > Leaked: ITU's secret Internet surveillance standard discussion draft > http://boingboing.net/2012/12/05/leaked-itus-secret-internet.html > > --- > Just because i'm near the punchbowl doesn't mean I'm also drinking from it. > > _______________________________________________ > Infowarrior mailing list > Infowarrior(a)attrition.org > https://attrition.org/mailman/listinfo/infowarrior ----- End forwarded message -----

1 0

TCP time_wait and port exhaustion for servers
by Ray Soucy 06 Dec '12

06 Dec '12

RFC 793 arbitrarily defines 2MSL (how long to hold a socket in TIME_WAIT state before cleaning up) as 4 min. Linux is a little more reasonable in this and has it baked into the source as 60 seconds in "/usr/src/linux/include/net/tcp.h": #define TCP_TIMEWAIT_LEN (60*HZ) Where there is no way to change this though /proc (probably a good idea to keep users from messing with it), I am considering re-building a kernel with a lower TCP_TIMEWAIT_LEN to deal with the following issue. With a 60 second timeout on TIME_WAIT, local port identifiers are tied up from being used for new outgoing connections (in this case a proxy server). The default local port range on Linux can easily be adjusted; but even when bumped up to a range of 32K ports, the 60 second timeout means you can only sustain about 500 new connections per second before you run out of ports. There are two options to try an deal with this, tcp_tw_reuse, and tcp_tw_recycle; but both seem to be less than ideal. With tcp_tw_reuse, it doesn't appear to be effective in situations where you're sustaining 500+ new connections per second rather than a small burst. With tcp_tw_recycle it seems like too big of a hammer and has been reported to cause problems with NATed connections. The best solution seems to be trying to keep TIME_WAIT in place, but being faster about it. 30 seconds would get you to 1000 connections a second; 15 to 2000, and 10 seconds to about 3000 a second. A few questions: Does anyone have any data on how typical it is for TIME_WAIT to be necessary beyond 10 seconds on a modern network? Has anyone done some research on how low you can make TIME_WAIT safely? Is this a terrible idea? What alternatives are there? Keep in mind this is a proxy server making outgoing connections as the source of the problem; so things like SO_REUSEADDR which work for reusing sockets for incoming connections don't seem to do much in this situation. Anyone running large proxies or load balancers have this situation? If so what is your solution? -- Ray Patrick Soucy Network Engineer University of Maine System T: 207-561-3526 F: 207-561-3531 MaineREN, Maine's Research and Education Network www.maineren.net

12 24

/. ITU Approves Deep Packet Inspection
by Eugen Leitl 06 Dec '12

06 Dec '12

http://yro.slashdot.org/story/12/12/05/0115214/itu-approves-deep-packet-ins… ITU Approves Deep Packet Inspection Posted by Soulskill on Tuesday December 04, @08:19PM from the inspect-my-encryption-all-you'd-like dept. dsinc sends this quote from Techdirt about the International Telecommunications Union's ongoing conference in Dubai that will have an effect on the internet everywhere: "One of the concerns is that decisions taken there may make the Internet less a medium that can be used to enhance personal freedom than a tool for state surveillance and oppression. The new Y.2770 standard is entitled 'Requirements for deep packet inspection in Next Generation Networks', and seeks to define an international standard for deep packet inspection (DPI). As the Center for Democracy & Technology points out, it is thoroughgoing in its desire to specify technologies that can be used to spy on people. One of the big issues surrounding WCIT and the ITU has been the lack of transparency — or even understanding what real transparency might be. So it will comes as no surprise that the new DPI standard was negotiated behind closed doors, with no drafts being made available."

6 5

Any enterprise operators very happy with their MPLS providers?
by McCall, Gabriel 06 Dec '12

06 Dec '12

I'm getting ready to prepare an RFP for our next generation WAN, and would like feedback from anyone else who has 100+ MPLS nodes on their quality of account service and technical performance. My current landscape includes AT&T, Sprint, and Verizon. I'm almost completely happy with Sprint- they're about in the A- range. AT&T is muddling along at about a C, and Verizon is a solid F. I've heard very good things from some CenturyLink customers and will definitely include them in the bidder list- is anyone else doing a very good job for you? -Gabriel

3 2

Re: /. ITU Approves Deep Packet Inspection
by Tom Taylor 05 Dec '12

05 Dec '12

On 05/12/2012 2:11 PM, Jeroen Massar wrote: > On 2012-12-05 14:01, Tom Taylor wrote: >> I'm seriously not clear why Y.2770 is characterized as "negotiated >> behind closed doors". Any drafts were available to all participants in >> the ITU-T, on exactly the same terms as drafts of other Recommendations. >> As an example, the draft coming out of the October, 2011 meeting can be >> seen at http://www.itu.int/md/T09-SG13-111010-TD-WP4-0201/en. (I have >> access delegated by a vendor to whom I have been consulting, by virtue >> of their membership in the ITU-T.) > > So, how exactly can most people on for instance this list access that > URL? You yourself would not be able to access it where it not that you > found some loophole setup. > ... Agreed that the ITU-T is a membership organization, but the Questions and Study Group work programs are open to view (Q. 17/13 specifically covers DPI, and has more documents coming down the pipe). If you want to follow some Question you can probably get access through your government (State Dept. in the US, Dept. of Communications in Canada). The membership rules don't apply so stringently to Rapporteurs' meetings, so you can get in touch with the Rapporteur of a Question you are interested in and find out where to get copies of documents contributed into those meetings. All this is by the by -- you are more likely to be affected by the IETF than by anything coming out of the ITU-T.

3 2

75 Broad NYC explosion
by Brent Jones 05 Dec '12

05 Dec '12

I heard through the grapevine that there was an explosion in the basement of 75 Broad St in NYC. Provider isn't able to provide any details at this time, but would anyone local have additional information on what is happening there? -- Brent Jones brent(a)brentrjones.com

2 1

Re: TCP time_wait and port exhaustion for servers
by Mark Andrews 05 Dec '12

05 Dec '12

Mark Andrews writes: > > In message <CAP-guGVSMXgt-xhnqC191-Mfh2-W38Gg5mZf1MegCgwObVKK-Q(a)mail.gmail.com > >, > William Herrin writes: > > On Wed, Dec 5, 2012 at 5:01 PM, Mark Andrews <marka(a)isc.org> wrote: > > > In message <CAP-guGW6oXo=UfTfg+SDiFjB4=qxPShO+YfK6vxnLkCC58PvgQ(a)mail.gmail > .c > > om>, > > > William Herrin writes: > > >> The thing is, Linux doesn't behave quite that way. > > >> > > >> If you do an anonymous connect(), that is you socket() and then > > >> connect() without a bind() in the middle, then the limit applies *per > > >> destination IP:port pair*. So, you should be able to do 30,000 > > >> connections to 192.168.1.1 port 80, another 30,000 connections to > > >> 192.168.1.2 port 80, and so on. > > > > > > The socket api is missing a bind + connect call which restricts the > > > source address when making the connect. This is needed when you > > > are required to use a fixed source address. > > > > Hi Mark, > > > > There are ways around this problem in Linux. For example you can mark > > a packet with iptables based on the uid of the process which created > > it and then you can NAT the source address based on the mark. Little > > messy but the tools are there. > > And not available to the ordinary user. Nameservers potentially run > into this limit. This is something The OpenGroup need to address when > updating the next revision of the socket api in POSIX. Even a "LATEBINDPORT" setsockopt call would do so that bind() on ties down the source address not the source address and port. > > Anyway, Ray didn't indicate that he needed a fixed source address > > other than the one the machine would ordinarily choose for itself. > > But he didn't say it wasn't required either. > > Mark > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka(a)isc.org -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka(a)isc.org

1 0