- Test - lists.nanog.org

Re: Linux Router: TCP slow, UDP fast
by Chris 14 Feb '09

14 Feb '09

Thanks for all the answers. I'm currently going down the path of looking at IPtables' conntrack slowing the forwarding rate. If I can't find any more docs then I'll boot the router with a kernel without any IPtables built-in and see if that's it. As Lee said "rollback" ! That's the last change to the box. If I can rule out the logging of traffic from conntrack is slowing down the forwarding then I can look into hardware further ;-) Chris

2 2

Linux Router: TCP slow, UDP fast
by Chris 14 Feb '09

14 Feb '09

Hi All, I'm losing the will to live with this networking headache ! Please feel free to point me at a Linux list if NANOG isn't suitable. I'm at a loss where else to ask. I've diagnosed some traffic oddities and after lots of head-scratching, reading and trial and error I can say with certainty that: With and without shaping and over different bandwidth providers using the e1000 driver for an Intel PRO/1000 MT Dual Port Gbps NIC (82546EB) I can replicate full, expected throughput with UDP but consistently only get 300kbps - 600kbps throughput _per connection_ for outbound TCP (I couldn't find a tool I trusted to replicate ICMP traffic). Multiple connections are cumulative and increase incrementally at roughly 300kbps - 600kbps. Inbound seems slightly erratic in holding a consistent speed but manages 15Mbps as expected, a far cry from 300kbps to 600kbps. The router is Quad Core sitting at no load and there's very little traffic being forwarded back and forth. The NIC's kernel parameters are set at default as 'built-in'. NAPI is not enabled though (enabling it requires a reboot which is a problem as this box is in production). The only other change to the box is that over Christmas IPtables (ip_conntrack and its associated modules mainly) was loaded into the kernel as 'built-in'. There's no sign of packet loss on any tests and I upped the conntrack max_connections size suitably for the amount of RAM. Has anyone come across IPtables without any rules loaded causing throughput issues ? I've also changed the following kernel parameters with no luck: net.core.rmem_max = 16777216 net.core.wmem_max = 16777216 net.ipv4.tcp_rmem = 4096 87380 16777216 net.ipv4.tcp_wmem = 4096 65536 16777216 net.ipv4.tcp_no_metrics_save = 1 net.core.netdev_max_backlog = 2500 echo 0 > /proc/sys/net/ipv4/tcp_window_scaling It feels to me like a buffer limit is being reached 'per connection'. The throughput spikes at around 1.54Mbps and TCP backs off to about 300kbps - 600kbps or so. What am I missing ? Is NAPI that essential for such low traffic ? A very similar build moved far higher throughput on cheap NICs. MTU is at 1500, txqueuelen is 1000. Any help would be massively appreciated ! Chris

5 13

Re: One /22 Two ISP no BGP
by Charles Regan 14 Feb '09

14 Feb '09

The problem we have now is that we got our /22 from arin to do multihoming. If we dump tlb, no more multihoming? No /22. Is that correct? We also have a contract with tlb. $$$ 1.5yrs left... 2009/2/13, Seth Mattinen <sethm(a)rollernet.us>: > Charles Regan wrote: >> Isp2 is vtl not bell >> >> 2009/2/13, Seth Mattinen <sethm(a)rollernet.us>: >>> Charles Regan wrote: >>>> Just got final confirmation from ISP1 that they will not do BGP with us. >>>> >>>> ISP1 is Telebec. >>>> http://www.iptools.com/dnstools.php?tool=ipwhois&user_data=142.217.0.0&subm… >>>> >>>> My subnet >>>> http://www.iptools.com/dnstools.php?tool=ipwhois&user_data=204.144.60.0&sub… >>>> >>>> What can we do now ? Any suggestions ? >>>> >>> Do you know who is upstream of ISP2? We've established that Telebec is >>> only connected to Bell Canada. If ISP2 also has a connection to Bell >>> then you don't gain anything with Telebec except this huge mess and >>> horrible hacks to work around their lack of BGP. >>> >>> ~Seth >>> >> > > > Also, VTL peers with Sprint and SAVVIS. Based on this information I'd > just drop Telebec completely. They only have one upstream. You won't get > any redundancy with them since they're just giving you a connection to > Bell, which VTL already gives you. Here's the view from my SAVVIS router > with Sprint as the preferred path: > > routy-border0>show ip bgp 216.113.0.0/17 > BGP routing table entry for 216.113.0.0/17, version 78286019 > Paths: (3 available, best #1, table Default-IP-Routing-Table) > Not advertised to any peer > 1239 5769, (received & used) > 208.79.242.129 (metric 3) from 208.79.242.129 (208.79.242.129) > Origin IGP, metric 439, localpref 100, valid, internal, best > Community: 11170:1239 > 3561 5769 > 216.88.158.93 from 216.88.158.93 (206.24.210.102) > Origin IGP, localpref 90, valid, external > Community: 3561:11840 11170:3561 > 3561 5769, (received-only) > 216.88.158.93 from 216.88.158.93 (206.24.210.102) > Origin IGP, localpref 90, valid, external > Community: 3561:11840 > > > -- > Seth Mattinen sethm(a)rollernet.us > Roller Network LLC > -- Envoyé avec mon mobile

4 3

Re: One /22 Two ISP no BGP
by Michael Smith 14 Feb '09

14 Feb '09

And/or see if bell canada can sell you something diverse. ----- Original Message ----- From: Seth Mattinen <sethm(a)rollernet.us> To: Charles Regan <charles.regan(a)gmail.com> Cc: nanog(a)nanog.org <nanog(a)nanog.org> Sent: Fri Feb 13 18:58:54 2009 Subject: Re: One /22 Two ISP no BGP Charles Regan wrote: > The problem we have now is that we got our /22 from arin to do multihoming. > If we dump tlb, no more multihoming? No /22. Is that correct? > > We also have a contract with tlb. > $$$ 1.5yrs left... > > There's something in there about non-multihomed sites, but I'm not familiar with it. Telebec doesn't appear to be multihomed, though. The only other thing I can think of to avoid horrible hackery is to convince them to colo a router for you to do eBGP to. Honestly, I wouldn't recommend multihoming *without* BGP. One day you'll end up with some really ugly failure mode. ~Seth

3 2

Happy 1234567890 everyone!
by Steve Church 14 Feb '09

14 Feb '09

Just in case you missed it. date -d "Fri Feb 13 23:31:30 UTC 2009" +%s It's like a really geeky y2k without the potential cataclysm. :) Steve

11 12

Chicago Sprint convulsions?
by neal rauhauser 13 Feb '09

13 Feb '09

Is anyone else seeing convulsions via Sprint Chicago? Lightly loaded OC3 and we've got stuff all over the net seeing crazy latency. -- mailto:Neal@layer3arts.com // GoogleTalk: nrauhauser(a)gmail.com IM: nealrauhauser

1 0

Security Assessment of the Transmission Control Protocol (TCP)
by Fernando Gont 13 Feb '09

13 Feb '09

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hello, folks, The United Kingdom's Centre for the Protection of National Infrastructure has just released the document "Security Assessment of the Transmission Control Protocol (TCP)", on which I have had the pleasure to work during the last few years. The motivation to produce this document is explained in the Preface of the document as follows: - ---- cut here ---- The TCP/IP protocol suite was conceived in an environment that was quite different from the hostile environment they currently operate in. However, the effectiveness of the protocols led to their early adoption in production environments, to the point that to some extent, the current world?s economy depends on them. While many textbooks and articles have created the myth that the Internet protocols were designed for warfare environments, the top level goal for the DARPA Internet Program was the sharing of large service machines on the ARPANET. As a result, many protocol specifications focus only on the operational aspects of the protocols they specify, and overlook their security implications. While the Internet technology evolved since it early inception, the Internet?s building blocks are basically the same core protocols adopted by the ARPANET more than two decades ago. During the last twenty years, many vulnerabilities have been identified in the TCP/IP stacks of a number of systems. Some of them were based on flaws in some protocol implementations, affecting only a reduced number of systems, while others were based in flaws in the protocols themselves, affecting virtually every existing implementation. Even in the last couple of years, researchers were still working on security problems in the core protocols. The discovery of vulnerabilities in the TCP/IP protocol suite usually led to reports being published by a number of CSIRTs (Computer Security Incident Response Teams) and vendors, which helped to raise awareness about the threats and the best mitigations known at the time the reports were published. Unfortunately, this also led to the documentation of the discovered protocol vulnerabilities being spread among a large number of documents, which are sometimes difficult to identify. For some reason, much of the effort of the security community on the Internet protocols did not result in official documents (RFCs) being issued by the IETF (Internet Engineering Task Force). This basically led to a situation in which ?known? security problems have not always been addressed by all vendors. In addition, in many cases vendors have implemented quick ?fixes? to the identified vulnerabilities without a careful analysis of their effectiveness and their impact on interoperability. Producing a secure TCP/IP implementation nowadays is a very difficult task, in part because of the lack of a single document that serves as a security roadmap for the protocols. Implementers are faced with the hard task of identifying relevant documentation and differentiating between that which provides correct advice, and that which provides misleading advice based on inaccurate or wrong assumptions. There is a clear need for a companion document to the IETF specifications that discusses the security aspects and implications of the protocols, identifies the existing vulnerabilities, discusses the possible countermeasures, and analyses their respective effectiveness. This document is the result of a security assessment of the IETF specifications of the Transmission Control Protocol (TCP), from a security point of view. Possible threats are identified and, where possible, countermeasures are proposed. Additionally, many implementation flaws that have led to security vulnerabilities have been referenced in the hope that future implementations will not incur the same problems. This document does not aim to be the final word on the security aspects of TCP. On the contrary, it aims to raise awareness about a number of TCP vulnerabilities that have been faced in the past, those that are currently being faced, and some of those that we may still have to deal with in the future. Feedback from the community is more than encouraged to help this document be as accurate as possible and to keep it updated as new vulnerabilities are discovered. - ---- cut here ---- The document is available at CPNI's web site: http://www.cpni.gov.uk/Products/technicalnotes/Feb-09-security-assessment-T… Additionally, I have posted a copy of the document on my personal web site: http://www.gont.com.ar Any comments will be more than welcome. Kind regards, - -- Fernando Gont e-mail: fernando(a)gont.com.ar || fgont(a)acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iQEcBAEBCAAGBQJJlLWeAAoJEJbuqe/Qdv/xRBMIANfq3pfTFauzFacTyjzzdu7+ g0XP76J6qThEjUZzzjEtSAS0hi9u+rODEp5Cujk0y/QK0Wnyoc6ZHOn91q0cuOtA UC+YqfTrW72bJL0+JEHxYSRkASEwtfULyfnyzx3ZMoiN/gMTG/PAQ4WDvNu5ORhf nmbTiRkpdc3S6FmsMnxzwbNJrklAwGuJKIIOmGTGwrI4D1G9lOc0A6xqArIvkwma L6a2YIGOZBePpI8yj4baKk1qvXH9gk+oH5bjJDXyXZNWOIFeM5lDeJaiEQHWCbF+ k+P/plO5TImzQtmKqGGVNoRJa4scw9ZLxYz2zLkJ6dZtUzGriyi0RwvPj1ZKQR4= =sV1Y -----END PGP SIGNATURE-----

2 2

anyone knows about extreme switch
by ann kok 13 Feb '09

13 Feb '09

Hi I have old model extreme switch Anyone knows about hyperterminal setting. ls null modem cable same as HP serial cables? I try both cables in this switch and can see the boot information but keyboard is not responsing ! Thank you __________________________________________________________________ Looking for the perfect gift? Give the gift of Flickr! http://www.flickr.com/gift/

2 3

Re: One /22 Two ISP no BGP
by Charles Regan 13 Feb '09

13 Feb '09

Just got final confirmation from ISP1 that they will not do BGP with us. ISP1 is Telebec. http://www.iptools.com/dnstools.php?tool=ipwhois&user_data=142.217.0.0&subm… My subnet http://www.iptools.com/dnstools.php?tool=ipwhois&user_data=204.144.60.0&sub… What can we do now ? Any suggestions ? Charles

4 5

TeliaSonera AS1299
by German Martinez 13 Feb '09

13 Feb '09

Hello, If anyone from TeliaSonera is around please contact me off-list Thanks German

1 0