Re: Global Blackhole Service
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, Paul Vixie schrieb: > a minor editorial comment: > > Jens Ott - PlusServer AG writes: > >> Jack Bates schrieb: >>> Paul Vixie wrote: >>> >>> Do you have a miraculous way to stop DDOS? Is there now a way to quickly >>> and efficiently track down forged packets? Is there a remedy to shutting >>> down the *known* botnets, not to mention the unknown ones? > > the quoted text was written by jack bates, not paul vixie. Sorry ... must have deleted a little to much from context Didn'r want to move someones word into the otherones mouth ... Have a nice sunday - -- === Jens Ott Leiter Network Management Tel: +49 22 33 - 612 - 3501 Fax: +49 22 33 - 612 - 53501 E-Mail: j@plusserver.de GPG-Fingerprint: 808A EADF C476 FABE 2366 8402 31FD 328C C2CA 7D7A PlusServer AG Daimlerstraße 9-11 50354 Hürth Germany HRB 58428 / Amtsgericht Köln, USt-ID DE216 740 823 Vorstand: Jochen Berger, Frank Gross, Jan Osthues, Thomas Strohe Aufsichtsratsvorsitz: Claudius Schmalschläger === -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkmXz+UACgkQMf0yjMLKfXqC+ACfbj1PcMQknt6R3G5or5iqHD5f 5awAniuOjy+Eoxq4TLd0x7ekQqaeIX9r =oNog -END PGP SIGNATURE-
Re: Linux Router: TCP slow, UDP fast
Thanks, Karl, Allen and Nickola. I failed-over to another router last night and briefly had full expected throughput but this morning despite dropping providers and moving between routers again for trial and error I still see _outbound_ TCP at about the same 300 - 600kbps per session. I eliminated conntract modules firstly, then iptables as a whole. I've eliminated TSO and checksumming (which caused very sticky connections) on the e1000 NIC. The failover router has a slightly older kernel and was working before Christmas so it's not most likely not kernel versions. I've also tried removing FIB_TRIE as a stab in the dark with no success. And the failover router connects using FE not GE so I've eliminated NICs and connection speeds to a front-facing switch. The only constant is the front-facing switch (it's negotiating perfectly at FD though) so all I can think of is removing that from the equation. It's definitely only _outbound_ TCP getting buffered though ! I've pushed 92Mbps on a FE link with UDP and uploaded at 16Mbps on a 16Mbps link. Any last ideas appreciated before causing headaches removing switches would be appreciated. Thanks, Chris
Re: Linux Router: TCP slow, UDP fast
I would turn off ethernet flow control. Maybe you already have. It can be really mean on tcp's own flow control if the switch has an issue of some kind (load). /Tias 15 feb 2009 kl. 10.24 skrev Chris : Thanks, Karl, Allen and Nickola. I failed-over to another router last night and briefly had full expected throughput but this morning despite dropping providers and moving between routers again for trial and error I still see _outbound_ TCP at about the same 300 - 600kbps per session. I eliminated conntract modules firstly, then iptables as a whole. I've eliminated TSO and checksumming (which caused very sticky connections) on the e1000 NIC. The failover router has a slightly older kernel and was working before Christmas so it's not most likely not kernel versions. I've also tried removing FIB_TRIE as a stab in the dark with no success. And the failover router connects using FE not GE so I've eliminated NICs and connection speeds to a front-facing switch. The only constant is the front-facing switch (it's negotiating perfectly at FD though) so all I can think of is removing that from the equation. It's definitely only _outbound_ TCP getting buffered though ! I've pushed 92Mbps on a FE link with UDP and uploaded at 16Mbps on a 16Mbps link. Any last ideas appreciated before causing headaches removing switches would be appreciated. Thanks, Chris
Re: Linux Router: TCP slow, UDP fast
Thanks for the suggestions everyone. I've got to the bottom of the problem now (I'm sure there will be a collective sigh of relief from the list because of the noise this thread generated :-)). I installed two brand new, low spec, 3Com switches one at the 'front' of the network and one 'behind' the routers. They are the same model, same latest firmware, same config (saved to and then copied off disk) and only their IPs were different. The front switch was the problem. As two final tests before removing it we switched off unicast/multicast broadcast control and flow control (and simultaneously on the same port on the switch behind the routers) because there were pause frames showing but not a massive amount in terms of percentage. The switch behind the routers however is serving the same bandwidth equally well ! We've put an ancient switch in place of the front switch and its been working perfectly so far. My lesson learned is too change as little as possible at once ! That said, recent network changes were spread about a month apart and this very odd issue was far easier to dismiss than believe due to its bizarre nature. Especially when providers have changes in their network conditions as testing is done. I really appreciate all the input and have learnt loads, possibly just not in the way I would have liked to :-) Doubles all round, Chris
Re: Linux Router: TCP slow, UDP fast
On Feb 15, 2009, at 04:24, Chris wrote: Any last ideas appreciated before causing headaches removing switches would be appreciated. The TCP offloading should be suspect. Any current PC hardware should be able to deal with huge amounts of traffic without any offloading. Start with turning that off, so everything will be handled by Linux directly. Even if you still would have a problem, it's easier to trouble shoot without magic black boxes (TOE) in between. -Geert
Re: Global Blackhole Service
Paul Vixie wrote: > the quoted text was written by jack bates, not paul vixie. the problem of misattributed quotations is greatly exacerbated by those who do not clearly attribute the text(s) they are quoting. randy
Re: Global Blackhole Service
[] I keep reading this subject as "Global Backhoe Service", ie, the sworn enemy of NANOG :) Mike
Re: Global Blackhole Service
On Feb 15, 2009, at 1:46 PM, Michael Thomas wrote: [] I keep reading this subject as "Global Backhoe Service", ie, the sworn enemy of NANOG :) Why ? At the Global Backhoe Service your dues will go to our initiative to place an iPhone running Google latitude on every backhoe on the planet. The GBS will then track their positions and place a call whenever anyone raises their hoes over any cable belonging to a GBS member. Non members will get a call inviting them to subscribe... quickly. What could possibly go wrong ? Regards Marshall Mike
cogent issues
Has anyone opened a ticket with Cogent? Their packet loss is reaching ~10%. http://www.internetpulse.net
Capture problems with Intel quad cards?
Has anyone had problems with using current Intel quad ethernet cards for packet capture? As a proof-of-concept test we bought an Intel PWLA8494GT and hooked it up to some Network Critical taps. There was a very strange issue with corruption of the captured packets. The *only* issue (but it's a big one) is that the source IP on some captured packets is munged. As far as I can tell that's the *only* issue with the packet captures - no other data is corrupted. Oh, and to rule out other issues: 1. Corruption seen both when using network taps and when using a port span/mirror (so it's not the taps). 2. Corruption *not* seen using the on-board broadcom nics of the test host (so it's not the box). So I'm pretty sure we narrowed it down to the card. We tried the card in an indentical host and saw the same problems. I thought it might be a driver issue - I tried both gentoo and FreeBSD (not sure how different the drivers are) just to see if it mattered at all and it didn't. Much googling didn't show this to be a known issue - just wondering if anyone else has seen it? Other recommendations welcome - the next step is, I suppose, a broadcom-based PCI-X card. (I've got some old pizza boxes I'm trying to repurpose as network probes.) Thanks, John -- John A. Kilpatrick j...@hypergeek.netEmail| http://www.hypergeek.net/ john-p...@hypergeek.net Text pages| ICQ: 19147504 remember: no obstacles/only challenges
