Bugzilla says "Upstream commit 8f1b03a4c18e8f3f0801447b62330faa8ed3bb37 fixes this.". But perhaps that is only a portion of the fix? _______________________________________________ Please read the do
Hi, Hi, To follow up on this, I opened a Red Hat bugzilla ticket (#973190, sorry it's private) regarding the problems I was seeing with GRO and LVS NAT. After some debugging, they found the issue and
Hi, Did they mention if this patch will be propagated upstream? It's affecting at least the Debian 6 2.6.32 kernel, too. TIA, Thomas _______________________________________________ Please read the do
To follow up on this, I opened a Red Hat bugzilla ticket (#973190, sorry it's private) regarding the problems I was seeing with GRO and LVS NAT. After some debugging, they found the issue and the fix
Unfortunately, it would be difficult for me to test that as I need SNAT working for my various applications to keep working. I think my next step will be to try a different machine with a current Xeo
Have you tried running a test with no iptables rules at all? Even NOTRACK has to parse the packet headers before handing it to IPVS, so there's obviously a performance hit there. Graeme [sent from mo
Thanks for your help. Here's my current iptables setup, I thought I had enabled NOTRACK for http and https traffic to prevent this. 1.1.1.1 is my fake public IP for this email and 192.168.0.0 is the
No, it isn't. If you have rules in place and something making use of the conntrack modules (matching ESTABLISHED/RELATED for example) then you *could* - I'm not saying *will :) - see performance prob
Sorry, I was not very clear with my statement. I meant was that the old bug of very poor / terrible performance still existed when GRO was on. Turning if off leads to reasonable performance that I ca
Yep, that's it. Should be in the kernel you are running. Did it get worse, or just no better? Are you able to do iptables NAT instead to see if that makes a difference, or perhaps put a http proxy in
I seem to recall a nasty bug in the older broadcom driver that ignores the gro=off setting! I believe the latest driver should fix it. -- Regards, Malcolm Turnbull. Loadbalancer.org Ltd. Phone: +44 (
Thanks, it appears this is the relevant bug? https://bugzilla.redhat.com/show_bug.cgi?id=854066 I did a test of this: Features for eth1: rx-checksumming: on tx-checksumming: on scatter-gather: on tcp
Hello Daryl, Simply add second LVS cluster , split the traffik via dns RR . Hope this helps. -- Mit freundlichen Grüßen / Best Regards Horst Venzke ; PGP NET : 1024G/082F2E6D ; http://www.remsnet.de
I was told by RedHat the GRO issue is fixed in RHEL6.4 - Not had chance to test it yet. David _______________________________________________ Please read the documentation before posting - it's avail
Greetings, I have a LVS-NAT web cluster that seems to be nicely chugging along. My LVS director has the following specs: - Dell OptiPlex 745 - Intel(R) Pentium(R) D CPU 3.40GHz - 4 GB Memory - BCM575