Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Verhalten einer Firewall bei Überlast in einer Session
27 views
Skip to first unread message
Gerald Vogt
Jan 16, 2012, 3:33:59 AM1/16/12
to
Mal eine grundlegende Frage zum Verhalten einer $$$$ Firewall, wenn
eine einzelne Session überlastet wird. Wir haben eine Juniper
Firewall. Möglicher Gesamtdurchsatz 30 Gbps. Maximaler
unidirectionaler Durchsatz eines ASICs 2 Gbps bei TCP. Anschlüsse ans
Netz über mehrere 10 GE Interfaces.
So weit so schön. Solange die Server nur 1 GE Interfaces hatten, war
die Welt in Ordnung. Sessions durch die Firewall mit dem erwarteten
Durchsatz von fast 1 Gbps.
Inzwischen haben die neuen Server 10 GE Interfaces und die schaffen
auch wunderbar fast 10 Gbps, solange wir nicht durch die Firewall
gehen.
Wenn es aber durch die Firewall geht, sieht es aber ganz anders aus.
Ein paar exemplarische Zahlen mit einem iperf TCP Stream von einem
Server durch die Firewall zu einem anderen Server, alle Strecken 10
GE, und sonst wenig Verkehr auf der Firewall:
1. Beide Server mit MTU 1500 und ohne jegliches Offloading: 2 Gbps.
Das ist in Ordnung.
2. Sender mit Offloading, Empfänger ohne: 1 Gbps.
3. Beide mit Offloading: 80 Mbps (!)
4. Ohne Offloading, aber MTU 9000 auf beiden Seiten: 600 Mbps.
Diverse andere Kombinationen sind nicht berauschender. MTU 1500 und
ohne Offloading gibt das beste Ergebnis durch die Firewall, allerdings
auf Kosten des internen LAN Durchsatzes. Und wir können nicht alle
Servern außerhalb vorschreiben, dass sie nur MTU 1500 und kein
Offloading verwenden.
Vor allem die Nr. 3 ist ziemlich "schockierend". Bislang dachte ich
immer, dass TCP sich eigentlich gut an die Verhältnisse auf der
Strecke anpasst und so in allen Fällen den möglichen Maximaldurchsatz
von 2 Gbps erreichen sollte.
Tatsächlich aber bremst die Firewall komplett aus. Ein Dump zeigt z.B.
für Nr. 3 einen schönen Sägezahn: Der Durchsatz steigt erst sehr
schnell an bis wohl der ASIC überlastet ist, und dann bricht es
komplett ein auf 0, worauf es kurz darauf wieder von vorne losgeht.
Das Linux auf den Servern scheint es ja selbst ganz ordentlich
hinzukriegen, da in Fall 1 der maximale Datendurchsatz von 2 Gbps
durch die Firewall erreicht wird.
Mir ist nicht ganz klar, welche Komponente (vom Linux zur Karte,
dämliches Offloading auf der Karte, Firewall) hier letztendlich den
Durchsatz so einbrechen lässt, und vor allem, ob und wie man das
Problem mit dieser Firewall lösen könnte.
Oder anders gefragt: muss ich zwangsläufig mit solchen Probleme
rechnen, wenn der ASIC überlastet wird?
Danke.
Gerald
eine einzelne Session überlastet wird. Wir haben eine Juniper
Firewall. Möglicher Gesamtdurchsatz 30 Gbps. Maximaler
unidirectionaler Durchsatz eines ASICs 2 Gbps bei TCP. Anschlüsse ans
Netz über mehrere 10 GE Interfaces.
So weit so schön. Solange die Server nur 1 GE Interfaces hatten, war
die Welt in Ordnung. Sessions durch die Firewall mit dem erwarteten
Durchsatz von fast 1 Gbps.
Inzwischen haben die neuen Server 10 GE Interfaces und die schaffen
auch wunderbar fast 10 Gbps, solange wir nicht durch die Firewall
gehen.
Wenn es aber durch die Firewall geht, sieht es aber ganz anders aus.
Ein paar exemplarische Zahlen mit einem iperf TCP Stream von einem
Server durch die Firewall zu einem anderen Server, alle Strecken 10
GE, und sonst wenig Verkehr auf der Firewall:
1. Beide Server mit MTU 1500 und ohne jegliches Offloading: 2 Gbps.
Das ist in Ordnung.
2. Sender mit Offloading, Empfänger ohne: 1 Gbps.
3. Beide mit Offloading: 80 Mbps (!)
4. Ohne Offloading, aber MTU 9000 auf beiden Seiten: 600 Mbps.
Diverse andere Kombinationen sind nicht berauschender. MTU 1500 und
ohne Offloading gibt das beste Ergebnis durch die Firewall, allerdings
auf Kosten des internen LAN Durchsatzes. Und wir können nicht alle
Servern außerhalb vorschreiben, dass sie nur MTU 1500 und kein
Offloading verwenden.
Vor allem die Nr. 3 ist ziemlich "schockierend". Bislang dachte ich
immer, dass TCP sich eigentlich gut an die Verhältnisse auf der
Strecke anpasst und so in allen Fällen den möglichen Maximaldurchsatz
von 2 Gbps erreichen sollte.
Tatsächlich aber bremst die Firewall komplett aus. Ein Dump zeigt z.B.
für Nr. 3 einen schönen Sägezahn: Der Durchsatz steigt erst sehr
schnell an bis wohl der ASIC überlastet ist, und dann bricht es
komplett ein auf 0, worauf es kurz darauf wieder von vorne losgeht.
Das Linux auf den Servern scheint es ja selbst ganz ordentlich
hinzukriegen, da in Fall 1 der maximale Datendurchsatz von 2 Gbps
durch die Firewall erreicht wird.
Mir ist nicht ganz klar, welche Komponente (vom Linux zur Karte,
dämliches Offloading auf der Karte, Firewall) hier letztendlich den
Durchsatz so einbrechen lässt, und vor allem, ob und wie man das
Problem mit dieser Firewall lösen könnte.
Oder anders gefragt: muss ich zwangsläufig mit solchen Probleme
rechnen, wenn der ASIC überlastet wird?
Danke.
Gerald
Roland Ertelt
Jan 16, 2012, 3:36:17 AM1/16/12
to
Und so sprach Gerald Vogt:
> Mal eine grundlegende Frage zum Verhalten einer $$$$ Firewall, wenn
> eine einzelne Session überlastet wird. ...
Das kann dir nur der Hersteller beantworten.
Roland
> Mal eine grundlegende Frage zum Verhalten einer $$$$ Firewall, wenn
Das kann dir nur der Hersteller beantworten.
Roland
Gerald Vogt
Jan 16, 2012, 3:54:16 AM1/16/12
to
Und es ging mir auch um die grundlegende Problematik und ob diese
Probleme zwangsläufig bei jeder Firewall zu erwarten wären oder ob es
sich nur um ein Problem dieser Firewall handelt.
Gerald
Roland Ertelt
Jan 16, 2012, 4:24:45 AM1/16/12
to
Und so sprach Gerald Vogt:
> On 16 Jan., 09:36, Roland Ertelt <rert...@yahoo.de> wrote:
>> Und so sprach Gerald Vogt:
>>
>>> Mal eine grundlegende Frage zum Verhalten einer $$$$ Firewall, wenn
>>> eine einzelne Session überlastet wird. ...
>>
>> Das kann dir nur der Hersteller beantworten.
>
> Der Hersteller grübelt selbst seit Monaten darüber.
>
> Und es ging mir auch um die grundlegende Problematik und ob diese
> Probleme zwangsläufig bei jeder Firewall zu erwarten wären oder ob es
> sich nur um ein Problem dieser Firewall handelt.
>
>
Jeder Paketfilter/NAT/Router kann in eine "Überlastsituation" gebracht
> On 16 Jan., 09:36, Roland Ertelt <rert...@yahoo.de> wrote:
>> Und so sprach Gerald Vogt:
>>
>>> Mal eine grundlegende Frage zum Verhalten einer $$$$ Firewall, wenn
>>> eine einzelne Session überlastet wird. ...
>>
>> Das kann dir nur der Hersteller beantworten.
>
> Der Hersteller grübelt selbst seit Monaten darüber.
>
> Und es ging mir auch um die grundlegende Problematik und ob diese
> Probleme zwangsläufig bei jeder Firewall zu erwarten wären oder ob es
> sich nur um ein Problem dieser Firewall handelt.
>
>
werden.
Roland
Gerald Vogt
Jan 16, 2012, 4:27:56 AM1/16/12
to
komplett ein und geht quasi gegen Null? Ist das normal?
Gerald
Gerald Vogt
Jan 16, 2012, 3:38:06 AM1/16/12
to
On 16 Jan., 09:36, Roland Ertelt <rert...@yahoo.de> wrote:
> Und so sprach Gerald Vogt:
>
> > Mal eine grundlegende Frage zum Verhalten einer $$$$ Firewall, wenn
> > eine einzelne Session berlastet wird. ...
>
> > Mal eine grundlegende Frage zum Verhalten einer $$$$ Firewall, wenn
>
> Das kann dir nur der Hersteller beantworten.
>
> Roland
Der Hersteller scheint es selbst nicht zu wissen. Zumindest grübelt er
> Das kann dir nur der Hersteller beantworten.
>
> Roland
seit Monaten über diese Probleme.
Gerald
Roland Ertelt
Jan 16, 2012, 8:31:55 AM1/16/12
to
erneutes Senden.
*Was* genau dann passiert, ist mbMn abhängig vom gefahrenen höheren
Protokoll. Kann es Paket-Loss oder Timeouts ab, wirds nur langsam. Kann
die Verbindung keinen Paket-Loss oder Timeouts ab, kann die Verbindung
komplett abbrechen, und muss neu aufgebaut werden.
Roland
Gerald Vogt
Jan 16, 2012, 9:37:27 AM1/16/12
to
On 16 Jan., 14:31, Roland Ertelt <rert...@yahoo.de> wrote:
> Überlast ist bei TCP fast immer gleichbedeutend mit Paketverlust bzw
> erneutes Senden.
>
> *Was* genau dann passiert, ist mbMn abhängig vom gefahrenen höheren
> Protokoll. Kann es Paket-Loss oder Timeouts ab, wirds nur langsam. Kann
> die Verbindung keinen Paket-Loss oder Timeouts ab, kann die Verbindung
> komplett abbrechen, und muss neu aufgebaut werden.
Du verwechselst da was.
> Überlast ist bei TCP fast immer gleichbedeutend mit Paketverlust bzw
> erneutes Senden.
>
> *Was* genau dann passiert, ist mbMn abhängig vom gefahrenen höheren
> Protokoll. Kann es Paket-Loss oder Timeouts ab, wirds nur langsam. Kann
> die Verbindung keinen Paket-Loss oder Timeouts ab, kann die Verbindung
> komplett abbrechen, und muss neu aufgebaut werden.
1. TCP wickelt Paketverluste und Retransmissions ab. Das
Anwendungsprotokoll merkt davon nichts.
2. Zumindest iperf sind Verzögerungen wegen Timeouts völlig egal. Der
Client sendet, wenn er senden kann, und der Server empfänger, wenn was
zum Empfangen da ist. So schnell es eben geht...
3. Ich habe nirgends was von Verbindungsabbrüchen geschrieben. Die
Verbindung bleibt bestehen, nur der Durchsatz geht in den Keller. Da
werden keine neuen Verbindungen aufgebaut.
Gerald
Carsten Krueger
Jan 16, 2012, 10:23:58 AM1/16/12
to
Am Mon, 16 Jan 2012 00:33:59 -0800 (PST) schrieb Gerald Vogt:
> Bislang dachte ich
> immer, dass TCP sich eigentlich gut an die Verhältnisse auf der
> Strecke anpasst und so in allen Fällen den möglichen Maximaldurchsatz
> von 2 Gbps erreichen sollte.
Mit plötzlichen Paketverlusten kommt TCP garnicht gut klar.
> Bislang dachte ich
> immer, dass TCP sich eigentlich gut an die Verhältnisse auf der
> Strecke anpasst und so in allen Fällen den möglichen Maximaldurchsatz
> von 2 Gbps erreichen sollte.
Google mal: TCP Congestion Control
> Mir ist nicht ganz klar, welche Komponente (vom Linux zur Karte,
> dämliches Offloading auf der Karte, Firewall) hier letztendlich den
> Durchsatz so einbrechen lässt, und vor allem, ob und wie man das
> Problem mit dieser Firewall lösen könnte.
anderer Congestion-Algorithmus der schlechter funktioniert als die
Softwarevariante.
Schau dir doch mal mit Wireshark an ob du erkennen kannst, dass die
Fenstergrößen unterschiedlich nach einem Paketverlust wachsen.
> Oder anders gefragt: muss ich zwangsläufig mit solchen Probleme
> rechnen, wenn der ASIC überlastet wird?
Gruß Carsten
--
ID = 0x2BFBF5D8 FP = 53CA 1609 B00A D2DB A066 314C 6493 69AB 2BFB F5D8
http://www.realname-diskussion.info - Realnames sind keine Pflicht
http://www.spamgourmet.com/ + http://mailcatch.com/ - Antispam
cakruege (at) gmail (dot) com
Roland Ertelt
Jan 16, 2012, 10:35:39 AM1/16/12
to
Und so sprach Gerald Vogt:
> On 16 Jan., 14:31, Roland Ertelt <rert...@yahoo.de> wrote:
>> Überlast ist bei TCP fast immer gleichbedeutend mit Paketverlust bzw
>> erneutes Senden.
>>
>> *Was* genau dann passiert, ist mbMn abhängig vom gefahrenen höheren
>> Protokoll. Kann es Paket-Loss oder Timeouts ab, wirds nur langsam. Kann
>> die Verbindung keinen Paket-Loss oder Timeouts ab, kann die Verbindung
>> komplett abbrechen, und muss neu aufgebaut werden.
>
> Du verwechselst da was.
>
> 1. TCP wickelt Paketverluste und Retransmissions ab. Das
> Anwendungsprotokoll merkt davon nichts.
>
Wenn der Datenrahmen auf Anwendungsebene (HTTP/FTP/SSMTP/whatever) nicht
>> Überlast ist bei TCP fast immer gleichbedeutend mit Paketverlust bzw
>> erneutes Senden.
>>
>> *Was* genau dann passiert, ist mbMn abhängig vom gefahrenen höheren
>> Protokoll. Kann es Paket-Loss oder Timeouts ab, wirds nur langsam. Kann
>> die Verbindung keinen Paket-Loss oder Timeouts ab, kann die Verbindung
>> komplett abbrechen, und muss neu aufgebaut werden.
>
> Du verwechselst da was.
>
> 1. TCP wickelt Paketverluste und Retransmissions ab. Das
> Anwendungsprotokoll merkt davon nichts.
>
korrekt rekonstruiert werden kann, weil der Paketfilter eine Ebene
tiefer nicht nachkommt (weil nach Murphy immer das letzte benötigte
Stück TCP-Rahmen wegen vollem Puffer in den Retry geht, oder im Puffer
vergammelt) ist das ein Verlust/Timeout. *Das* wird von der Anwendung
sehr wohl bemerkt.
Je nach Robustheit der Anwendung wird das mit Abwarten oder einer
erneuten Anfrage behandelt. Wobei im Fall "Paketfilter dicht" die
erneute Nachfrage nicht förderlich ist...
>
> 3. Ich habe nirgends was von Verbindungsabbrüchen geschrieben. Die
> Verbindung bleibt bestehen, nur der Durchsatz geht in den Keller. Da
> werden keine neuen Verbindungen aufgebaut.
>
Wenn deine Anwednung (aus den o.g. Gründen) keine/falsche Bestätigungen
rausschickt, dass der Datenrahmen X des Protokoll Y ordentlich erhalten
ist, beginnt der Sender seinen Timout zu zählen. Ist der Timout
erreicht, gilt das als Verbindungsabbruch.
Dass in diesem Fall (unbemerkt automatisch) eine neue Verbindung
ausgehandelt wird, ändert nichts an der Tatsache.
Als Nutzer sieht man erst mal nur die Datenrate massiv einbrechen.
Roland
Juergen P. Meier
Jan 16, 2012, 10:34:32 AM1/16/12
to
Gerald Vogt <vo...@spamcop.net>:
Algorithmen unterstuetzen denn deine NICs bei Offloading?
> 4. Ohne Offloading, aber MTU 9000 auf beiden Seiten: 600 Mbps.
Welch Wunder. Der Bullshit der durch die Welt geistert, dass
Jumboframes eine Tolle Idee[tm] seien verdraengt auch regelmaessig
Sinn und klaren Verstand.
Hier limitiert wohl der naechste Hop der fragmentieren muss mit seiner
CPU-Leistung deinen Durchsatz auf diese 600Mbps. Wenn du die
CPU-Auslastung deiner router ueberwachst wird dir sicher auffallen, wo
gerade der Chip glueht.
> Diverse andere Kombinationen sind nicht berauschender. MTU 1500 und
> ohne Offloading gibt das beste Ergebnis durch die Firewall, allerdings
Die TCP Implementierung der beteiligten Betriebsysteme scheint wohl
noch am besten zu sein.
> auf Kosten des internen LAN Durchsatzes. Und wir können nicht alle
Ach. In Software TCP mit 10Gbps NICs zu machen ist auch keine
besonders gute Idee.
> Servern außerhalb vorschreiben, dass sie nur MTU 1500 und kein
> Offloading verwenden.
Ach.
> Vor allem die Nr. 3 ist ziemlich "schockierend". Bislang dachte ich
Nicht wirklich. Die NICs werden halt zwei unterschiedliche und denkbar
unguenstig zueinander arbeitende TCP Algorithmen und Parameter waehlen,
der vermutlich auch die TCP Stateengine der Juniper aus dem Tritt
bringt.
> immer, dass TCP sich eigentlich gut an die Verhältnisse auf der
> Strecke anpasst und so in allen Fällen den möglichen Maximaldurchsatz
> von 2 Gbps erreichen sollte.
TCP ist vorallem immer eines: wesentlich komplizierter als sich das der
Laie so vereinfacht vorstellt.
> Tatsächlich aber bremst die Firewall komplett aus. Ein Dump zeigt z.B.
> für Nr. 3 einen schönen Sägezahn: Der Durchsatz steigt erst sehr
> schnell an bis wohl der ASIC überlastet ist, und dann bricht es
> komplett ein auf 0, worauf es kurz darauf wieder von vorne losgeht.
Kann sein, dass beide Seiten klassisches NAGLE machen ohne fast
recovery.
> Das Linux auf den Servern scheint es ja selbst ganz ordentlich
> hinzukriegen, da in Fall 1 der maximale Datendurchsatz von 2 Gbps
> durch die Firewall erreicht wird.
Linux kann unterschiedliche Algorithmen (wenn der Kernel entsprechend
uebersetzt wurde), du kannst diese mal ausprobieren um die beste
Kombination zu finden.
Das hilft dir bezueglich Offloading halt nichts, wenn die NIC dir da
zu viel Arbeit abnimmt.
> Mir ist nicht ganz klar, welche Komponente (vom Linux zur Karte,
> dämliches Offloading auf der Karte, Firewall) hier letztendlich den
> Durchsatz so einbrechen lässt, und vor allem, ob und wie man das
> Problem mit dieser Firewall lösen könnte.
>
> Oder anders gefragt: muss ich zwangsläufig mit solchen Probleme
> rechnen, wenn der ASIC überlastet wird?
Ja.
Wie hoch ist denn die Latenz (RTT)? Und wie gross ist das
ausgehandelte TCP-Fenster? (2^window-scaling * windowsize)
Juergen
--
Juergen P. Meier - "This World is about to be Destroyed!"
end
If you think technology can solve your problems you don't understand
technology and you don't understand your problems. (Bruce Schneier)
> Wenn es aber durch die Firewall geht, sieht es aber ganz anders aus.
> Ein paar exemplarische Zahlen mit einem iperf TCP Stream von einem
> Server durch die Firewall zu einem anderen Server, alle Strecken 10
> GE, und sonst wenig Verkehr auf der Firewall:
>
> 1. Beide Server mit MTU 1500 und ohne jegliches Offloading: 2 Gbps.
> Das ist in Ordnung.
> 2. Sender mit Offloading, Empfänger ohne: 1 Gbps.
> 3. Beide mit Offloading: 80 Mbps (!)
Da wird wohl mehr als nur Checksumming im NIC gemcht. Welche TCP
> Ein paar exemplarische Zahlen mit einem iperf TCP Stream von einem
> Server durch die Firewall zu einem anderen Server, alle Strecken 10
> GE, und sonst wenig Verkehr auf der Firewall:
>
> 1. Beide Server mit MTU 1500 und ohne jegliches Offloading: 2 Gbps.
> Das ist in Ordnung.
> 2. Sender mit Offloading, Empfänger ohne: 1 Gbps.
> 3. Beide mit Offloading: 80 Mbps (!)
Algorithmen unterstuetzen denn deine NICs bei Offloading?
> 4. Ohne Offloading, aber MTU 9000 auf beiden Seiten: 600 Mbps.
Jumboframes eine Tolle Idee[tm] seien verdraengt auch regelmaessig
Sinn und klaren Verstand.
Hier limitiert wohl der naechste Hop der fragmentieren muss mit seiner
CPU-Leistung deinen Durchsatz auf diese 600Mbps. Wenn du die
CPU-Auslastung deiner router ueberwachst wird dir sicher auffallen, wo
gerade der Chip glueht.
> Diverse andere Kombinationen sind nicht berauschender. MTU 1500 und
> ohne Offloading gibt das beste Ergebnis durch die Firewall, allerdings
noch am besten zu sein.
> auf Kosten des internen LAN Durchsatzes. Und wir können nicht alle
besonders gute Idee.
> Servern außerhalb vorschreiben, dass sie nur MTU 1500 und kein
> Offloading verwenden.
> Vor allem die Nr. 3 ist ziemlich "schockierend". Bislang dachte ich
unguenstig zueinander arbeitende TCP Algorithmen und Parameter waehlen,
der vermutlich auch die TCP Stateengine der Juniper aus dem Tritt
bringt.
> immer, dass TCP sich eigentlich gut an die Verhältnisse auf der
> Strecke anpasst und so in allen Fällen den möglichen Maximaldurchsatz
> von 2 Gbps erreichen sollte.
Laie so vereinfacht vorstellt.
> Tatsächlich aber bremst die Firewall komplett aus. Ein Dump zeigt z.B.
> für Nr. 3 einen schönen Sägezahn: Der Durchsatz steigt erst sehr
> schnell an bis wohl der ASIC überlastet ist, und dann bricht es
> komplett ein auf 0, worauf es kurz darauf wieder von vorne losgeht.
recovery.
> Das Linux auf den Servern scheint es ja selbst ganz ordentlich
> hinzukriegen, da in Fall 1 der maximale Datendurchsatz von 2 Gbps
> durch die Firewall erreicht wird.
uebersetzt wurde), du kannst diese mal ausprobieren um die beste
Kombination zu finden.
Das hilft dir bezueglich Offloading halt nichts, wenn die NIC dir da
zu viel Arbeit abnimmt.
> Mir ist nicht ganz klar, welche Komponente (vom Linux zur Karte,
> dämliches Offloading auf der Karte, Firewall) hier letztendlich den
> Durchsatz so einbrechen lässt, und vor allem, ob und wie man das
> Problem mit dieser Firewall lösen könnte.
>
> Oder anders gefragt: muss ich zwangsläufig mit solchen Probleme
> rechnen, wenn der ASIC überlastet wird?
Wie hoch ist denn die Latenz (RTT)? Und wie gross ist das
ausgehandelte TCP-Fenster? (2^window-scaling * windowsize)
Juergen
--
Juergen P. Meier - "This World is about to be Destroyed!"
end
If you think technology can solve your problems you don't understand
technology and you don't understand your problems. (Bruce Schneier)
Juergen P. Meier
Jan 16, 2012, 10:46:49 AM1/16/12
to
Gerald Vogt <vo...@spamcop.net>:
alternativ mal mit der zweiten, da gruebeln dann keine Inder.
>>
>> Das kann dir nur der Hersteller beantworten.
>
>> Das kann dir nur der Hersteller beantworten.
>
> Der Hersteller scheint es selbst nicht zu wissen. Zumindest grübelt er
> seit Monaten über diese Probleme.
Vendor J hat zwei Support-Klassen: Billig und Teuer. Versuchs
> seit Monaten über diese Probleme.
alternativ mal mit der zweiten, da gruebeln dann keine Inder.
Bernd Eckenfels
Jan 16, 2012, 11:18:04 AM1/16/12
to
Roland Ertelt <rer...@yahoo.de> wrote:
> Überlast ist bei TCP fast immer gleichbedeutend mit Paketverlust bzw
> erneutes Senden.
>
> *Was* genau dann passiert, ist mbMn abhängig vom gefahrenen höheren
> Protokoll.
TCP ist allerdings das höhere Protokoll, und das macht halt die Windows zu.
> Überlast ist bei TCP fast immer gleichbedeutend mit Paketverlust bzw
> erneutes Senden.
>
> *Was* genau dann passiert, ist mbMn abhängig vom gefahrenen höheren
> Protokoll.
Ggf kann man da auch auf den Host Endpunkten noch ein wenig nachhelfen.
Ich vermute aber mal, dass die Einbruchsituation durch Überlast nicht nur
bei einzelnen schnellen Flows sondern vor allem auch bei verteilter Hochlast
auftritt (und dann noch wesentlich unbequemer ist).
Welche Zahlen hast du denn ohne Firewall? Nicht dass einfach nur das
Offloading kaputt ist (wäre nicht die erste Karte).
Gruss
Bernd
Gerald Vogt
Jan 16, 2012, 11:30:25 AM1/16/12
to
On 16 Jan., 16:35, Roland Ertelt <rert...@yahoo.de> wrote:
> Und so sprach Gerald Vogt:
>
> > On 16 Jan., 14:31, Roland Ertelt <rert...@yahoo.de> wrote:
> >> Überlast ist bei TCP fast immer gleichbedeutend mit Paketverlust bzw
> >> erneutes Senden.
>
> >> *Was* genau dann passiert, ist mbMn abhängig vom gefahrenen höheren
> >> Protokoll. Kann es Paket-Loss oder Timeouts ab, wirds nur langsam. Kann
> >> die Verbindung keinen Paket-Loss oder Timeouts ab, kann die Verbindung
> >> komplett abbrechen, und muss neu aufgebaut werden.
>
> > Du verwechselst da was.
>
> > 1. TCP wickelt Paketverluste und Retransmissions ab. Das
> > Anwendungsprotokoll merkt davon nichts.
>
> Wenn der Datenrahmen auf Anwendungsebene (HTTP/FTP/SSMTP/whatever) nicht
> korrekt rekonstruiert werden kann, weil der Paketfilter eine Ebene
> tiefer nicht nachkommt (weil nach Murphy immer das letzte benötigte
> Stück TCP-Rahmen wegen vollem Puffer in den Retry geht, oder im Puffer
> vergammelt) ist das ein Verlust/Timeout. *Das* wird von der Anwendung
> sehr wohl bemerkt.
Dann bricht aber die TCP Verbindung ab. Dann kommt ein Reset und die
> Und so sprach Gerald Vogt:
>
> > On 16 Jan., 14:31, Roland Ertelt <rert...@yahoo.de> wrote:
> >> Überlast ist bei TCP fast immer gleichbedeutend mit Paketverlust bzw
> >> erneutes Senden.
>
> >> *Was* genau dann passiert, ist mbMn abhängig vom gefahrenen höheren
> >> Protokoll. Kann es Paket-Loss oder Timeouts ab, wirds nur langsam. Kann
> >> die Verbindung keinen Paket-Loss oder Timeouts ab, kann die Verbindung
> >> komplett abbrechen, und muss neu aufgebaut werden.
>
> > Du verwechselst da was.
>
> > 1. TCP wickelt Paketverluste und Retransmissions ab. Das
> > Anwendungsprotokoll merkt davon nichts.
>
> Wenn der Datenrahmen auf Anwendungsebene (HTTP/FTP/SSMTP/whatever) nicht
> korrekt rekonstruiert werden kann, weil der Paketfilter eine Ebene
> tiefer nicht nachkommt (weil nach Murphy immer das letzte benötigte
> Stück TCP-Rahmen wegen vollem Puffer in den Retry geht, oder im Puffer
> vergammelt) ist das ein Verlust/Timeout. *Das* wird von der Anwendung
> sehr wohl bemerkt.
Anwendung kann mit einem neuen SYN eine neue Verbindung aufbauen. Aber
das passiert nicht. Es ist immer dieselbe Verbindung und dieselbe
Session.
> Je nach Robustheit der Anwendung wird das mit Abwarten oder einer
> erneuten Anfrage behandelt. Wobei im Fall "Paketfilter dicht" die
> erneute Nachfrage nicht förderlich ist...
Verbindung.
> > 3. Ich habe nirgends was von Verbindungsabbrüchen geschrieben. Die
> > Verbindung bleibt bestehen, nur der Durchsatz geht in den Keller. Da
> > werden keine neuen Verbindungen aufgebaut.
>
> Ein zugestopfter Router/Paketfilter ist kein regulärer Anwendungsfall mehr.
> Wenn deine Anwednung (aus den o.g. Gründen) keine/falsche Bestätigungen
> rausschickt, dass der Datenrahmen X des Protokoll Y ordentlich erhalten
> ist, beginnt der Sender seinen Timout zu zählen. Ist der Timout
> erreicht, gilt das als Verbindungsabbruch.
folgenden neuen SYN und 3 way handshake.
Das passiert nicht. Dazu müsste die Verbindung ja viele Sekunden
hängen.
> Dass in diesem Fall (unbemerkt automatisch) eine neue Verbindung
> ausgehandelt wird, ändert nichts an der Tatsache.
Gerald
Gerald Vogt
Jan 16, 2012, 11:47:00 AM1/16/12
to
On 16 Jan., 17:18, Bernd Eckenfels <bernd-2...@eckenfels.net> wrote:
Ohne Firewall mit MTU 9000 und Offloading kriege ich einen Durchsatz
von 9,8 Gbps. Selbst mit Offloading aber MTU 1500 gehen 9,3 Gbps
durch. Das sieht mir nicht kaputt aus...
Gerald
von 9,8 Gbps. Selbst mit Offloading aber MTU 1500 gehen 9,3 Gbps
durch. Das sieht mir nicht kaputt aus...
Gerald
Gerald Vogt
Jan 16, 2012, 2:53:31 PM1/16/12
to
On Jan 16, 4:34 pm, "Juergen P. Meier" <nospam-1...@jors.net> wrote:
> Gerald Vogt <v...@spamcop.net>:
tx-checksumming: on
scatter-gather: on
tcp-segmentation-offload: on
udp-fragmentation-offload: off
generic-segmentation-offload: on
generic-receive-offload: on
large-receive-offload: on
> > 4. Ohne Offloading, aber MTU 9000 auf beiden Seiten: 600 Mbps.
>
> Welch Wunder. Der Bullshit der durch die Welt geistert, dass
> Jumboframes eine Tolle Idee[tm] seien verdraengt auch regelmaessig
> Sinn und klaren Verstand.
>
> Hier limitiert wohl der naechste Hop der fragmentieren muss mit seiner
> CPU-Leistung deinen Durchsatz auf diese 600Mbps. Wenn du die
> CPU-Auslastung deiner router ueberwachst wird dir sicher auffallen, wo
> gerade der Chip glueht.
Das gesamte Netz, auf dem der Test läuft, ist auf MTU 9000 ausgelegt.
Da gibt es keine Fragmentierung.
> > Diverse andere Kombinationen sind nicht berauschender. MTU 1500 und
> > ohne Offloading gibt das beste Ergebnis durch die Firewall, allerdings
>
> Die TCP Implementierung der beteiligten Betriebsysteme scheint wohl
> noch am besten zu sein.
Das sieht so aus.
> > auf Kosten des internen LAN Durchsatzes. Und wir können nicht alle
>
> Ach. In Software TCP mit 10Gbps NICs zu machen ist auch keine
> besonders gute Idee.
Deswegen sollte ja auch Offloading und MTU 9000 verwendet werden.
> > Vor allem die Nr. 3 ist ziemlich "schockierend". Bislang dachte ich
>
> Nicht wirklich. Die NICs werden halt zwei unterschiedliche und denkbar
> unguenstig zueinander arbeitende TCP Algorithmen und Parameter waehlen,
> der vermutlich auch die TCP Stateengine der Juniper aus dem Tritt
> bringt.
Die beiden Blades für die Tests sind quasi eineiige Zwillinge. Ich
bezweifle irgendwie, dass zwei identische Intel Karten mit identischem
Kernel Modul, identischen Einstellungen auf identischer Hardware so
leicht aus dem Tritt zu bringen sind.
> > Mir ist nicht ganz klar, welche Komponente (vom Linux zur Karte,
> > dämliches Offloading auf der Karte, Firewall) hier letztendlich den
> > Durchsatz so einbrechen lässt, und vor allem, ob und wie man das
> > Problem mit dieser Firewall lösen könnte.
>
> > Oder anders gefragt: muss ich zwangsläufig mit solchen Probleme
> > rechnen, wenn der ASIC überlastet wird?
>
> Ja.
>
> Wie hoch ist denn die Latenz (RTT)? Und wie gross ist das
> ausgehandelte TCP-Fenster? (2^window-scaling * windowsize)
RTT 0.3-0.4ms
TCP window scale 9
TCP window size 3055
Fenstergröße 1564160
Und außer am Anfang sinkt die Fenstergröße auch nie unter 1490000...
Gerald
> Gerald Vogt <v...@spamcop.net>:
>
> > Wenn es aber durch die Firewall geht, sieht es aber ganz anders aus.
> > Ein paar exemplarische Zahlen mit einem iperf TCP Stream von einem
> > Server durch die Firewall zu einem anderen Server, alle Strecken 10
> > GE, und sonst wenig Verkehr auf der Firewall:
>
> > 1. Beide Server mit MTU 1500 und ohne jegliches Offloading: 2 Gbps.
> > Das ist in Ordnung.
> > 2. Sender mit Offloading, Empfänger ohne: 1 Gbps.
> > 3. Beide mit Offloading: 80 Mbps (!)
>
> Da wird wohl mehr als nur Checksumming im NIC gemcht. Welche TCP
> Algorithmen unterstuetzen denn deine NICs bei Offloading?
rx-checksumming: on
> > Wenn es aber durch die Firewall geht, sieht es aber ganz anders aus.
> > Ein paar exemplarische Zahlen mit einem iperf TCP Stream von einem
> > Server durch die Firewall zu einem anderen Server, alle Strecken 10
> > GE, und sonst wenig Verkehr auf der Firewall:
>
> > 1. Beide Server mit MTU 1500 und ohne jegliches Offloading: 2 Gbps.
> > Das ist in Ordnung.
> > 2. Sender mit Offloading, Empfänger ohne: 1 Gbps.
> > 3. Beide mit Offloading: 80 Mbps (!)
>
> Da wird wohl mehr als nur Checksumming im NIC gemcht. Welche TCP
> Algorithmen unterstuetzen denn deine NICs bei Offloading?
tx-checksumming: on
scatter-gather: on
tcp-segmentation-offload: on
udp-fragmentation-offload: off
generic-segmentation-offload: on
generic-receive-offload: on
large-receive-offload: on
> > 4. Ohne Offloading, aber MTU 9000 auf beiden Seiten: 600 Mbps.
>
> Welch Wunder. Der Bullshit der durch die Welt geistert, dass
> Jumboframes eine Tolle Idee[tm] seien verdraengt auch regelmaessig
> Sinn und klaren Verstand.
>
> Hier limitiert wohl der naechste Hop der fragmentieren muss mit seiner
> CPU-Leistung deinen Durchsatz auf diese 600Mbps. Wenn du die
> CPU-Auslastung deiner router ueberwachst wird dir sicher auffallen, wo
> gerade der Chip glueht.
Da gibt es keine Fragmentierung.
> > Diverse andere Kombinationen sind nicht berauschender. MTU 1500 und
> > ohne Offloading gibt das beste Ergebnis durch die Firewall, allerdings
>
> Die TCP Implementierung der beteiligten Betriebsysteme scheint wohl
> noch am besten zu sein.
> > auf Kosten des internen LAN Durchsatzes. Und wir können nicht alle
>
> Ach. In Software TCP mit 10Gbps NICs zu machen ist auch keine
> besonders gute Idee.
> > Vor allem die Nr. 3 ist ziemlich "schockierend". Bislang dachte ich
>
> Nicht wirklich. Die NICs werden halt zwei unterschiedliche und denkbar
> unguenstig zueinander arbeitende TCP Algorithmen und Parameter waehlen,
> der vermutlich auch die TCP Stateengine der Juniper aus dem Tritt
> bringt.
bezweifle irgendwie, dass zwei identische Intel Karten mit identischem
Kernel Modul, identischen Einstellungen auf identischer Hardware so
leicht aus dem Tritt zu bringen sind.
> > Mir ist nicht ganz klar, welche Komponente (vom Linux zur Karte,
> > dämliches Offloading auf der Karte, Firewall) hier letztendlich den
> > Durchsatz so einbrechen lässt, und vor allem, ob und wie man das
> > Problem mit dieser Firewall lösen könnte.
>
> > Oder anders gefragt: muss ich zwangsläufig mit solchen Probleme
> > rechnen, wenn der ASIC überlastet wird?
>
> Ja.
>
> Wie hoch ist denn die Latenz (RTT)? Und wie gross ist das
> ausgehandelte TCP-Fenster? (2^window-scaling * windowsize)
TCP window scale 9
TCP window size 3055
Fenstergröße 1564160
Und außer am Anfang sinkt die Fenstergröße auch nie unter 1490000...
Gerald
Juergen Ilse
Jan 16, 2012, 9:47:14 PM1/16/12
to
Hallo,
Gerald Vogt <vo...@spamcop.net> wrote:
> Wenn es aber durch die Firewall geht, sieht es aber ganz anders aus.
> Ein paar exemplarische Zahlen mit einem iperf TCP Stream von einem
> Server durch die Firewall zu einem anderen Server, alle Strecken 10
> GE, und sonst wenig Verkehr auf der Firewall:
>
> 1. Beide Server mit MTU 1500 und ohne jegliches Offloading: 2 Gbps.
> Das ist in Ordnung.
> 2. Sender mit Offloading, Empfänger ohne: 1 Gbps.
> 3. Beide mit Offloading: 80 Mbps (!)
> 4. Ohne Offloading, aber MTU 9000 auf beiden Seiten: 600 Mbps.
>
> Diverse andere Kombinationen sind nicht berauschender. MTU 1500 und
> ohne Offloading gibt das beste Ergebnis durch die Firewall, allerdings
> auf Kosten des internen LAN Durchsatzes. Und wir können nicht alle
> Servern außerhalb vorschreiben, dass sie nur MTU 1500 und kein
> Offloading verwenden.
>
> Vor allem die Nr. 3 ist ziemlich "schockierend". Bislang dachte ich
> immer, dass TCP sich eigentlich gut an die Verhältnisse auf der
> Strecke anpasst und so in allen Fällen den möglichen Maximaldurchsatz
> von 2 Gbps erreichen sollte.
Die "Offload-Engines" vieler Netzwerkkarten haben anscheinend Probleme
sich halbwegs optimal auf (fuer die zur Verfuegung stehende Bandbreite)
hohe Delays oder auch nur schwankende Delays optimal einzustellen.
In dem Fall hilft es dann u.U. tatsaechlich nur, auf die Offload Engine
der Netzwerkarte zu verzichten ... In einem mir bekannten Szenario gab
es mal mit "UMTS-Zugriffen" auf einen Server Performance-Einbussen,
solange beim Netzwerkartentreiber die "Offload Engine" aktiviert war.
Bei Zugriffen aus dem LAN (mit erheblich geringeren Delays) gab es
dagegen keine solchen Probleme.
> Tatsächlich aber bremst die Firewall komplett aus.
Vermutlich sorgt die Firewall nur fuer hoehere Delays, mit denen dann
die Offload Engine der Netzwerkkarte nicht mehr optimal umgehen kann.
Bei Jumbo-Frames wird die Firewall evt. noch ein etwas groesseres Delay
erzeugen, was dann das Problem mit der Offload Engine der Netzwerkkarte
weiter verschaerft und damit den Durchsatz weiter einbrechen laesst.
Das ist jetzt zwar nur Spekulation, aber es wuerde alle von dir beob-
achteten Effekte plausibel erklaeren ... Die Schuld laege dann nicht
in erster Linie an der Firewall ...
> Mir ist nicht ganz klar, welche Komponente (vom Linux zur Karte,
> dämliches Offloading auf der Karte, Firewall) hier letztendlich den
> Durchsatz so einbrechen lässt, und vor allem, ob und wie man das
> Problem mit dieser Firewall lösen könnte.
Siehe oben. Evt. liegt es gar nicht primaer an der Firewall ...
Tschuess,
Juergen Ilse (jue...@usenet-verwaltung.de)
--
Ein Domainname ist nur ein Name, nicht mehr und nicht weniger.
Wer mehr hineininterpretiert, hat das Domain-Name-System nicht
verstanden.
Gerald Vogt <vo...@spamcop.net> wrote:
> Wenn es aber durch die Firewall geht, sieht es aber ganz anders aus.
> Ein paar exemplarische Zahlen mit einem iperf TCP Stream von einem
> Server durch die Firewall zu einem anderen Server, alle Strecken 10
> GE, und sonst wenig Verkehr auf der Firewall:
>
> 1. Beide Server mit MTU 1500 und ohne jegliches Offloading: 2 Gbps.
> Das ist in Ordnung.
> 2. Sender mit Offloading, Empfänger ohne: 1 Gbps.
> 3. Beide mit Offloading: 80 Mbps (!)
> 4. Ohne Offloading, aber MTU 9000 auf beiden Seiten: 600 Mbps.
>
> Diverse andere Kombinationen sind nicht berauschender. MTU 1500 und
> ohne Offloading gibt das beste Ergebnis durch die Firewall, allerdings
> auf Kosten des internen LAN Durchsatzes. Und wir können nicht alle
> Servern außerhalb vorschreiben, dass sie nur MTU 1500 und kein
> Offloading verwenden.
>
> Vor allem die Nr. 3 ist ziemlich "schockierend". Bislang dachte ich
> immer, dass TCP sich eigentlich gut an die Verhältnisse auf der
> Strecke anpasst und so in allen Fällen den möglichen Maximaldurchsatz
> von 2 Gbps erreichen sollte.
sich halbwegs optimal auf (fuer die zur Verfuegung stehende Bandbreite)
hohe Delays oder auch nur schwankende Delays optimal einzustellen.
In dem Fall hilft es dann u.U. tatsaechlich nur, auf die Offload Engine
der Netzwerkarte zu verzichten ... In einem mir bekannten Szenario gab
es mal mit "UMTS-Zugriffen" auf einen Server Performance-Einbussen,
solange beim Netzwerkartentreiber die "Offload Engine" aktiviert war.
Bei Zugriffen aus dem LAN (mit erheblich geringeren Delays) gab es
dagegen keine solchen Probleme.
> Tatsächlich aber bremst die Firewall komplett aus.
die Offload Engine der Netzwerkkarte nicht mehr optimal umgehen kann.
Bei Jumbo-Frames wird die Firewall evt. noch ein etwas groesseres Delay
erzeugen, was dann das Problem mit der Offload Engine der Netzwerkkarte
weiter verschaerft und damit den Durchsatz weiter einbrechen laesst.
Das ist jetzt zwar nur Spekulation, aber es wuerde alle von dir beob-
achteten Effekte plausibel erklaeren ... Die Schuld laege dann nicht
in erster Linie an der Firewall ...
> Mir ist nicht ganz klar, welche Komponente (vom Linux zur Karte,
> dämliches Offloading auf der Karte, Firewall) hier letztendlich den
> Durchsatz so einbrechen lässt, und vor allem, ob und wie man das
> Problem mit dieser Firewall lösen könnte.
Tschuess,
Juergen Ilse (jue...@usenet-verwaltung.de)
--
Ein Domainname ist nur ein Name, nicht mehr und nicht weniger.
Wer mehr hineininterpretiert, hat das Domain-Name-System nicht
verstanden.
Juergen P. Meier
Jan 17, 2012, 12:39:42 AM1/17/12
to
Gerald Vogt <vo...@spamcop.net>:
Fluss- und Verstopfungssteuerung (Congestion Control Algorithm)
komplett selbst machen.
Unterscheiden sich denn die Options im TCP-Header von SYN Paketen wenn
du all diese Offloading-Optionen ab bzw. eingeschaltet hast?
>> Hier limitiert wohl der naechste Hop der fragmentieren muss mit seiner
>> CPU-Leistung deinen Durchsatz auf diese 600Mbps. Wenn du die
>> CPU-Auslastung deiner router ueberwachst wird dir sicher auffallen, wo
>> gerade der Chip glueht.
>
> Das gesamte Netz, auf dem der Test läuft, ist auf MTU 9000 ausgelegt.
> Da gibt es keine Fragmentierung.
Du wirst irgendwo eine Stelle haben, wo die Pakete zerlegt werden.
Evtl auch nur virtuell um dann gleich wieder zusammengesetzt zu
werden (VM switche mit virtueller MTU < PMTU, Defragmentierung in der
Firewall etc.pp)
>> Die TCP Implementierung der beteiligten Betriebsysteme scheint wohl
>> noch am besten zu sein.
>
> Das sieht so aus.
Ist auch kein grosses Wunder. Die Qualitaet der Chipdesigner bei den
Handelsueblichen NICs ist schlimmer als die italienischer Autobauer.
>> Ach. In Software TCP mit 10Gbps NICs zu machen ist auch keine
>> besonders gute Idee.
>
> Deswegen sollte ja auch Offloading und MTU 9000 verwendet werden.
"Pest, Aids, Cholera - Chose any combination of two"
>> Nicht wirklich. Die NICs werden halt zwei unterschiedliche und denkbar
>> unguenstig zueinander arbeitende TCP Algorithmen und Parameter waehlen,
>> der vermutlich auch die TCP Stateengine der Juniper aus dem Tritt
>> bringt.
>
> Die beiden Blades für die Tests sind quasi eineiige Zwillinge. Ich
> bezweifle irgendwie, dass zwei identische Intel Karten mit identischem
> Kernel Modul, identischen Einstellungen auf identischer Hardware so
> leicht aus dem Tritt zu bringen sind.
Das kann durchaus passieren. TCP Congestion Control Algorithmen und
Windowing restart Methoden reagieren durchaus sehr unterschiedlich
in Sende vs. Empfangsrichtung. Es ist durchaus plausibel, wenn die
Implemntierung auf den Intel-Karten mit einer Gegenstelle, die einen
anderen Algorithmus implementiert deutlich besser funktioniert,
waehrend sie mit einer identisch arbeitenden Gegenstelle voll auf die
Fresse knallt.
Und bei Offloading sind dann nicht mal mehr die Treiber schuld, das
ist dann die Karte selbst. Bei neueren Treibern kann es lediglich
passieren, dass bestimmte Offloading-Features bei erkanntem Chiptyp
deaktiviert ewrden und garnicht mehr einschaltbar sind, um allzu
eklatante Fehler im Chipdesign zu umgehen.
>> Wie hoch ist denn die Latenz (RTT)? Und wie gross ist das
>> ausgehandelte TCP-Fenster? (2^window-scaling * windowsize)
>
> RTT 0.3-0.4ms
> TCP window scale 9
> TCP window size 3055
> Fenstergröße 1564160
D.h. du koenntest theoretisch bis knapp 30 Gbit/s in einem Flow
ueber diesen Pfad uebertragen. Das ist also kein limitierender Faktor.
> Und außer am Anfang sinkt die Fenstergröße auch nie unter 1490000...
Slow-Start halt.
Auch bei einem Frame-Loss durch die ueberlastete Juniper nicht?
Sowol mit als auch ohne Offloading?
>> Da wird wohl mehr als nur Checksumming im NIC gemcht. Welche TCP
>> Algorithmen unterstuetzen denn deine NICs bei Offloading?
> tcp-segmentation-offload: on
>> Algorithmen unterstuetzen denn deine NICs bei Offloading?
> generic-segmentation-offload: on
> generic-receive-offload: on
> large-receive-offload: on
D.h. der NIC macht alle Segementierung, muss also auch die
> generic-receive-offload: on
> large-receive-offload: on
Fluss- und Verstopfungssteuerung (Congestion Control Algorithm)
komplett selbst machen.
Unterscheiden sich denn die Options im TCP-Header von SYN Paketen wenn
du all diese Offloading-Optionen ab bzw. eingeschaltet hast?
>> Hier limitiert wohl der naechste Hop der fragmentieren muss mit seiner
>> CPU-Leistung deinen Durchsatz auf diese 600Mbps. Wenn du die
>> CPU-Auslastung deiner router ueberwachst wird dir sicher auffallen, wo
>> gerade der Chip glueht.
>
> Das gesamte Netz, auf dem der Test läuft, ist auf MTU 9000 ausgelegt.
> Da gibt es keine Fragmentierung.
Evtl auch nur virtuell um dann gleich wieder zusammengesetzt zu
werden (VM switche mit virtueller MTU < PMTU, Defragmentierung in der
Firewall etc.pp)
>> Die TCP Implementierung der beteiligten Betriebsysteme scheint wohl
>> noch am besten zu sein.
>
> Das sieht so aus.
Handelsueblichen NICs ist schlimmer als die italienischer Autobauer.
>> Ach. In Software TCP mit 10Gbps NICs zu machen ist auch keine
>> besonders gute Idee.
>
> Deswegen sollte ja auch Offloading und MTU 9000 verwendet werden.
>> Nicht wirklich. Die NICs werden halt zwei unterschiedliche und denkbar
>> unguenstig zueinander arbeitende TCP Algorithmen und Parameter waehlen,
>> der vermutlich auch die TCP Stateengine der Juniper aus dem Tritt
>> bringt.
>
> Die beiden Blades für die Tests sind quasi eineiige Zwillinge. Ich
> bezweifle irgendwie, dass zwei identische Intel Karten mit identischem
> Kernel Modul, identischen Einstellungen auf identischer Hardware so
> leicht aus dem Tritt zu bringen sind.
Windowing restart Methoden reagieren durchaus sehr unterschiedlich
in Sende vs. Empfangsrichtung. Es ist durchaus plausibel, wenn die
Implemntierung auf den Intel-Karten mit einer Gegenstelle, die einen
anderen Algorithmus implementiert deutlich besser funktioniert,
waehrend sie mit einer identisch arbeitenden Gegenstelle voll auf die
Fresse knallt.
Und bei Offloading sind dann nicht mal mehr die Treiber schuld, das
ist dann die Karte selbst. Bei neueren Treibern kann es lediglich
passieren, dass bestimmte Offloading-Features bei erkanntem Chiptyp
deaktiviert ewrden und garnicht mehr einschaltbar sind, um allzu
eklatante Fehler im Chipdesign zu umgehen.
>> Wie hoch ist denn die Latenz (RTT)? Und wie gross ist das
>> ausgehandelte TCP-Fenster? (2^window-scaling * windowsize)
>
> RTT 0.3-0.4ms
> TCP window scale 9
> TCP window size 3055
> Fenstergröße 1564160
ueber diesen Pfad uebertragen. Das ist also kein limitierender Faktor.
> Und außer am Anfang sinkt die Fenstergröße auch nie unter 1490000...
Auch bei einem Frame-Loss durch die ueberlastete Juniper nicht?
Sowol mit als auch ohne Offloading?
Juergen P. Meier
Jan 17, 2012, 12:59:30 AM1/17/12
to
Gerald Vogt <vo...@spamcop.net>:
Eine alte Netscreen (also das, was es bei J nicht mehr gibt) wirft den
Ueberlast Traffic als Packetloss weg.
Eine kleine/mittlere SRX crasht einfach und macht dabei das Filesystem
kaputt (bootet also auch nicht mehr).
Eine Cisco ASA faengt kurz vorher damit an graduell Packetloss zu
erzeugen, bei annaehrend 99% Last steigt der PAcketloss stark an und
es werden neue Flows ganz ignoriert. (ueberproportional viel
Packetloss, aber nicht so krass wie bei Checkpoint)
Eine CheckPoint INSPECT[tm] Engine (Firewall-1) faengt bei <90% mit
stetig steigendem Packetloss an, der bis 99% Last gegen 100% geht
(d.h. der Durchsatz sinkt auf 0).
>>
>> Jeder Paketfilter/NAT/Router kann in eine "Überlastsituation" gebracht
>> werden.
>
> Und was passiert dann normalerweise genau? Bricht der Durchsatz
> komplett ein und geht quasi gegen Null? Ist das normal?
Das ist sehr unterschiedlich. Ein paar Erfahrungswerte:
>> Jeder Paketfilter/NAT/Router kann in eine "Überlastsituation" gebracht
>> werden.
>
> Und was passiert dann normalerweise genau? Bricht der Durchsatz
> komplett ein und geht quasi gegen Null? Ist das normal?
Eine alte Netscreen (also das, was es bei J nicht mehr gibt) wirft den
Ueberlast Traffic als Packetloss weg.
Eine kleine/mittlere SRX crasht einfach und macht dabei das Filesystem
kaputt (bootet also auch nicht mehr).
Eine Cisco ASA faengt kurz vorher damit an graduell Packetloss zu
erzeugen, bei annaehrend 99% Last steigt der PAcketloss stark an und
es werden neue Flows ganz ignoriert. (ueberproportional viel
Packetloss, aber nicht so krass wie bei Checkpoint)
Eine CheckPoint INSPECT[tm] Engine (Firewall-1) faengt bei <90% mit
stetig steigendem Packetloss an, der bis 99% Last gegen 100% geht
(d.h. der Durchsatz sinkt auf 0).
Juergen P. Meier
Jan 17, 2012, 1:07:42 AM1/17/12
to
Gerald Vogt <vo...@spamcop.net>:
implementiert wird - und zwar auf *beiden* Seiten und wie diese
miteinander Harmonieren. Es gibt z.B. ganz unguenstige kombinationen wo
nur drei kurz hintereinander verlorene Pakete bei hoher RTT ausreichen um
einen Deadlock zu erzeugen der eine der beisen Seiten in Timeouts laufen
laesst und die Verbindung abbrechen laesst - BTST.
> 2. Zumindest iperf sind Verzögerungen wegen Timeouts völlig egal. Der
> Client sendet, wenn er senden kann, und der Server empfänger, wenn was
> zum Empfangen da ist. So schnell es eben geht...
Auch bei TCP? Da wird dir dir Offload-Engine der NIC einen Strich
durch die Rechnung machen, sofern sie Flow- und Congestion-controll
offloaded. Oder iperf macht tcp selbst bzw. klebt an seine raw IP
frames lediglich einen TCP-Header - das muesste ich jetzt nachlesen.
> 3. Ich habe nirgends was von Verbindungsabbrüchen geschrieben. Die
> Verbindung bleibt bestehen, nur der Durchsatz geht in den Keller. Da
Ja. Das ist TCP. Works As Designed.
> werden keine neuen Verbindungen aufgebaut.
Wenn ein Packetloss im LAN ausreichen wuerde, um Abbrueche zu
erzeugen, waere das ja auch voellig unbrauchbar.
> 1. TCP wickelt Paketverluste und Retransmissions ab. Das
> Anwendungsprotokoll merkt davon nichts.
Das "wie" ist dabei ausschlaggebend: Welche Strategie als Algorithmus
> Anwendungsprotokoll merkt davon nichts.
implementiert wird - und zwar auf *beiden* Seiten und wie diese
miteinander Harmonieren. Es gibt z.B. ganz unguenstige kombinationen wo
nur drei kurz hintereinander verlorene Pakete bei hoher RTT ausreichen um
einen Deadlock zu erzeugen der eine der beisen Seiten in Timeouts laufen
laesst und die Verbindung abbrechen laesst - BTST.
> 2. Zumindest iperf sind Verzögerungen wegen Timeouts völlig egal. Der
> Client sendet, wenn er senden kann, und der Server empfänger, wenn was
> zum Empfangen da ist. So schnell es eben geht...
durch die Rechnung machen, sofern sie Flow- und Congestion-controll
offloaded. Oder iperf macht tcp selbst bzw. klebt an seine raw IP
frames lediglich einen TCP-Header - das muesste ich jetzt nachlesen.
> 3. Ich habe nirgends was von Verbindungsabbrüchen geschrieben. Die
> Verbindung bleibt bestehen, nur der Durchsatz geht in den Keller. Da
> werden keine neuen Verbindungen aufgebaut.
erzeugen, waere das ja auch voellig unbrauchbar.
Juergen P. Meier
Jan 17, 2012, 1:14:35 AM1/17/12
to
Gerald Vogt <vo...@spamcop.net>:
provoziertem Frame-Loss: Sende von zwei verschiedenen Servern auf
einen Dritten (das ueberlastet den Port am Switch und fuehrt zu
Frame-loss).
Bei Idealer Kombination der congestion-Steuerung in allen beteiligten
NICs bzw. Kernels sollte die Transferrate in Summe nicht niedriger
sein. (jeweils also um die 5 Gbps)
Wenn die Ursache fuer die Firewall-Probleme das unguenstige Verhalten
der NICs bei Paketloss ist, solltest du deutlich sichtbare Einbrueche
haben (die von dir erwaehnte Reduzierung auf unter 4 Gbps in Summe z.B.)
Dann ist die Firewall zwar der Ausloeser deiner Probleme, aber nicht
deren Verursacher, und statt an Juniper solltest du dich an Intel wenden.
HTH,
> Ohne Firewall mit MTU 9000 und Offloading kriege ich einen Durchsatz
> von 9,8 Gbps. Selbst mit Offloading aber MTU 1500 gehen 9,3 Gbps
> durch. Das sieht mir nicht kaputt aus...
Mach diesen Test (also Server + Switch ohne Firewall) mal mit
> von 9,8 Gbps. Selbst mit Offloading aber MTU 1500 gehen 9,3 Gbps
> durch. Das sieht mir nicht kaputt aus...
provoziertem Frame-Loss: Sende von zwei verschiedenen Servern auf
einen Dritten (das ueberlastet den Port am Switch und fuehrt zu
Frame-loss).
Bei Idealer Kombination der congestion-Steuerung in allen beteiligten
NICs bzw. Kernels sollte die Transferrate in Summe nicht niedriger
sein. (jeweils also um die 5 Gbps)
Wenn die Ursache fuer die Firewall-Probleme das unguenstige Verhalten
der NICs bei Paketloss ist, solltest du deutlich sichtbare Einbrueche
haben (die von dir erwaehnte Reduzierung auf unter 4 Gbps in Summe z.B.)
Dann ist die Firewall zwar der Ausloeser deiner Probleme, aber nicht
deren Verursacher, und statt an Juniper solltest du dich an Intel wenden.
HTH,
Gerald Vogt
Jan 18, 2012, 8:20:51 AM1/18/12
to
Hallo,
On 17 Jan., 03:47, Juergen Ilse <juer...@usenet-verwaltung.de> wrote:
> Die "Offload-Engines" vieler Netzwerkkarten haben anscheinend Probleme
> sich halbwegs optimal auf (fuer die zur Verfuegung stehende Bandbreite)
> hohe Delays oder auch nur schwankende Delays optimal einzustellen.
> In dem Fall hilft es dann u.U. tatsaechlich nur, auf die Offload Engine
> der Netzwerkarte zu verzichten ... In einem mir bekannten Szenario gab
> es mal mit "UMTS-Zugriffen" auf einen Server Performance-Einbussen,
> solange beim Netzwerkartentreiber die "Offload Engine" aktiviert war.
> Bei Zugriffen aus dem LAN (mit erheblich geringeren Delays) gab es
> dagegen keine solchen Probleme.
O.K. Wenn ich aber Offloading (außer rx & tx checksumming) abstelle
und nur eine MTU 1500 verwende, dann kriege ich zum Beispiel bei
diesem Test: http://195.37.209.102:7123/ immer noch recht
"merkwürdige" Ergebnisse:
1. Wenn die Netzwerkkarte auf 1 GE konfiguriere, dann kriege ich einen
Durchsatz von ca. 850-925 Mbit/s ausgehend (C2S) und ca. 200-300 Mbit/
s eingehend (S2C).
2. Wenn ich die Netzwerkkarte auf 10 GE konfiguriere, dann sind es
plötzlich nur noch ca. 100-200 Mbit/s ausgehend (C2S) bei immer noch
ca. 150-300 Mbit/s eingehend (S2C).
Wie gesagt, ohne Offloading und nur mit MTU 1500, dafür aber mit einem
RTT von ca. 17 ms.
Gerald
On 17 Jan., 03:47, Juergen Ilse <juer...@usenet-verwaltung.de> wrote:
> Die "Offload-Engines" vieler Netzwerkkarten haben anscheinend Probleme
> sich halbwegs optimal auf (fuer die zur Verfuegung stehende Bandbreite)
> hohe Delays oder auch nur schwankende Delays optimal einzustellen.
> In dem Fall hilft es dann u.U. tatsaechlich nur, auf die Offload Engine
> der Netzwerkarte zu verzichten ... In einem mir bekannten Szenario gab
> es mal mit "UMTS-Zugriffen" auf einen Server Performance-Einbussen,
> solange beim Netzwerkartentreiber die "Offload Engine" aktiviert war.
> Bei Zugriffen aus dem LAN (mit erheblich geringeren Delays) gab es
> dagegen keine solchen Probleme.
und nur eine MTU 1500 verwende, dann kriege ich zum Beispiel bei
diesem Test: http://195.37.209.102:7123/ immer noch recht
"merkwürdige" Ergebnisse:
1. Wenn die Netzwerkkarte auf 1 GE konfiguriere, dann kriege ich einen
Durchsatz von ca. 850-925 Mbit/s ausgehend (C2S) und ca. 200-300 Mbit/
s eingehend (S2C).
2. Wenn ich die Netzwerkkarte auf 10 GE konfiguriere, dann sind es
plötzlich nur noch ca. 100-200 Mbit/s ausgehend (C2S) bei immer noch
ca. 150-300 Mbit/s eingehend (S2C).
Wie gesagt, ohne Offloading und nur mit MTU 1500, dafür aber mit einem
RTT von ca. 17 ms.
Gerald
Juergen Ilse
Jan 18, 2012, 10:40:48 AM1/18/12
to
> Wie gesagt, ohne Offloading und nur mit MTU 1500, dafür aber mit einem
> RTT von ca. 17 ms.
Wenn du im LAN 17 ms RTT hast, hast du noch irgendwo anders ein
> RTT von ca. 17 ms.
gewaltiges Problem ...
Gerald Vogt
Jan 18, 2012, 10:48:26 AM1/18/12
to
On 18 Jan., 16:40, Juergen Ilse <juer...@usenet-verwaltung.de> wrote:
> Hallo,
Gerald
> Hallo,
>
> Gerald Vogt <v...@spamcop.net> wrote:
> > Wie gesagt, ohne Offloading und nur mit MTU 1500, dafür aber mit einem
> > RTT von ca. 17 ms.
>
> Wenn du im LAN 17 ms RTT hast, hast du noch irgendwo anders ein
> gewaltiges Problem ...
Nicht im LAN. Sondern zu 195.37.209.102.
> Gerald Vogt <v...@spamcop.net> wrote:
> > Wie gesagt, ohne Offloading und nur mit MTU 1500, dafür aber mit einem
> > RTT von ca. 17 ms.
>
> Wenn du im LAN 17 ms RTT hast, hast du noch irgendwo anders ein
> gewaltiges Problem ...
Gerald
Jens Hektor
Jan 19, 2012, 4:21:18 AM1/19/12
to
Am 18.01.2012 14:20, schrieb Gerald Vogt:
> 1. Wenn die Netzwerkkarte auf 1 GE konfiguriere, dann kriege ich einen
> Durchsatz von ca. 850-925 Mbit/s ausgehend (C2S) und ca. 200-300 Mbit/
> s eingehend (S2C).
>
> 2. Wenn ich die Netzwerkkarte auf 10 GE konfiguriere, dann sind es
> plötzlich nur noch ca. 100-200 Mbit/s ausgehend (C2S) bei immer noch
> ca. 150-300 Mbit/s eingehend (S2C).
Was ist das denn für eine Netzwerkkarte (Chipsatz, Bus, Lanes)?
> 1. Wenn die Netzwerkkarte auf 1 GE konfiguriere, dann kriege ich einen
> Durchsatz von ca. 850-925 Mbit/s ausgehend (C2S) und ca. 200-300 Mbit/
> s eingehend (S2C).
>
> 2. Wenn ich die Netzwerkkarte auf 10 GE konfiguriere, dann sind es
> plötzlich nur noch ca. 100-200 Mbit/s ausgehend (C2S) bei immer noch
> ca. 150-300 Mbit/s eingehend (S2C).
Steckt Sie im passenden PCI-Slot?
Wie lang ist das Kupferkabel zum Switch? Welche Qualität hat es?
Carsten Krueger
Jan 19, 2012, 9:50:03 AM1/19/12
to
Am Wed, 18 Jan 2012 07:48:26 -0800 (PST) schrieb Gerald Vogt:
> Nicht im LAN. Sondern zu 195.37.209.102.
Und wieso solltest du eine 10 Gigabitverbindung durch das halbe DFN haben?
> Nicht im LAN. Sondern zu 195.37.209.102.
1 Gigabit ist nicht unüblich.
Jens Hektor
Jan 20, 2012, 2:41:43 AM1/20/12
to
Am 19.01.2012 15:50, schrieb Carsten Krueger:
> Und wieso solltest du eine 10 Gigabitverbindung durch das halbe DFN haben?
man whois ;-)
> Und wieso solltest du eine 10 Gigabitverbindung durch das halbe DFN haben?
Claus-Dieter Schulmann
Jan 22, 2012, 5:26:42 AM1/22/12
to
Juergen P. Meier wrote:
> Gerald Vogt <vo...@spamcop.net>:
>>>
>>> Jeder Paketfilter/NAT/Router kann in eine "Überlastsituation" gebracht
>>> werden.
>>
>> Und was passiert dann normalerweise genau? Bricht der Durchsatz
>> komplett ein und geht quasi gegen Null? Ist das normal?
>
> Das ist sehr unterschiedlich. Ein paar Erfahrungswerte:
Das sollte doch der klassische Fall für Source Quench sein.
> Gerald Vogt <vo...@spamcop.net>:
>>>
>>> Jeder Paketfilter/NAT/Router kann in eine "Überlastsituation" gebracht
>>> werden.
>>
>> Und was passiert dann normalerweise genau? Bricht der Durchsatz
>> komplett ein und geht quasi gegen Null? Ist das normal?
>
> Das ist sehr unterschiedlich. Ein paar Erfahrungswerte:
Claus-Dieter
Ansgar -59cobalt- Wiechers
Jan 22, 2012, 6:55:21 AM1/22/12
to
der Unsichtb^WSicherheit und so. Wissenschon.
cu
59cobalt
--
"All vulnerabilities deserve a public fear period prior to patches
becoming available."
--Jason Coombs on Bugtraq
Manfred Fiebig
Jan 23, 2012, 4:13:48 AM1/23/12
to
Nationen IQ-Unterschiede gibt?
--
der hinterwäldler
Juergen P. Meier
Jan 23, 2012, 9:04:50 AM1/23/12
to
Manfred Fiebig <manfred...@arcor.de>:
Das halte ich fuer unwahrscheinlich. Im Fall J ist es hingegen ein
(deutlicher) Unterschied der technischen Qualifikation.
Auch in Indien sind billige Arbeitskraefte idR. von geringerer
Qualifikation als teuere.
(deutlicher) Unterschied der technischen Qualifikation.
Auch in Indien sind billige Arbeitskraefte idR. von geringerer
Qualifikation als teuere.
Gerald Vogt
Jan 25, 2012, 5:58:56 AM1/25/12
to
On 22 Jan., 12:55, Ansgar -59cobalt- Wiechers
<usenet-2...@planetcobalt.net> wrote:
> >> Gerald Vogt <v...@spamcop.net>:
Testsetup überhaupt nichts gefiltert.
Und selbst im normalen aktiven Regelsatz wird Source Quench nicht
gefiltert noch irgendwas sonst "unsichtbar" gemacht.
Gerald
<usenet-2...@planetcobalt.net> wrote:
> >> Gerald Vogt <v...@spamcop.net>:
> >>>> Jeder Paketfilter/NAT/Router kann in eine "Überlastsituation" gebracht
> >>>> werden.
>
> >>> Und was passiert dann normalerweise genau? Bricht der Durchsatz
> >>> komplett ein und geht quasi gegen Null? Ist das normal?
>
> >> Das ist sehr unterschiedlich. Ein paar Erfahrungswerte:
>
> > Das sollte doch der klassische Fall für Source Quench sein.
>
> Was funktionieren würde, wenn man nicht ICMP kaputt gemacht hätte. Wegen
> der Unsichtb^WSicherheit und so. Wissenschon.
Sofern Juniper nicht immer ICMP kaputt macht, wird bei meinem internen
> >>>> werden.
>
> >>> Und was passiert dann normalerweise genau? Bricht der Durchsatz
> >>> komplett ein und geht quasi gegen Null? Ist das normal?
>
> >> Das ist sehr unterschiedlich. Ein paar Erfahrungswerte:
>
> > Das sollte doch der klassische Fall für Source Quench sein.
>
> Was funktionieren würde, wenn man nicht ICMP kaputt gemacht hätte. Wegen
> der Unsichtb^WSicherheit und so. Wissenschon.
Testsetup überhaupt nichts gefiltert.
Und selbst im normalen aktiven Regelsatz wird Source Quench nicht
gefiltert noch irgendwas sonst "unsichtbar" gemacht.
Gerald
Gerald Vogt
Jan 25, 2012, 6:01:16 AM1/25/12
to
On 19 Jan., 15:50, Carsten Krueger <cakru...@gmail.com> wrote:
> Am Wed, 18 Jan 2012 07:48:26 -0800 (PST) schrieb Gerald Vogt:
>
> > Nicht im LAN. Sondern zu 195.37.209.102.
>
> Und wieso solltest du eine 10 Gigabitverbindung durch das halbe DFN haben?
> 1 Gigabit ist nicht unüblich.
Mein Server ist 10 GE. Mein LAN ist 10 GE. Meine Anbindung ist 10 GE.
> Am Wed, 18 Jan 2012 07:48:26 -0800 (PST) schrieb Gerald Vogt:
>
> > Nicht im LAN. Sondern zu 195.37.209.102.
>
> Und wieso solltest du eine 10 Gigabitverbindung durch das halbe DFN haben?
> 1 Gigabit ist nicht unüblich.
Das DFN Backbone ist 10 GE...
Gerald
Juergen P. Meier
Jan 25, 2012, 6:11:50 AM1/25/12
to
Gerald Vogt <vo...@spamcop.net>:
Hast du das WAF/IPS auch /komplett/ abgeschaltet?
> Sofern Juniper nicht immer ICMP kaputt macht, wird bei meinem internen
> Testsetup überhaupt nichts gefiltert.
Apropos J...
> Testsetup überhaupt nichts gefiltert.
Hast du das WAF/IPS auch /komplett/ abgeschaltet?
Gerald Vogt
Jan 25, 2012, 6:05:12 AM1/25/12
to
On 19 Jan., 10:21, Jens Hektor <hek...@rz.rwth-aachen.de> wrote:
> Am 18.01.2012 14:20, schrieb Gerald Vogt:
>
> > 1. Wenn die Netzwerkkarte auf 1 GE konfiguriere, dann kriege ich einen
> > Durchsatz von ca. 850-925 Mbit/s ausgehend (C2S) und ca. 200-300 Mbit/
> > s eingehend (S2C).
>
> > 2. Wenn ich die Netzwerkkarte auf 10 GE konfiguriere, dann sind es
> > plötzlich nur noch ca. 100-200 Mbit/s ausgehend (C2S) bei immer noch
> > ca. 150-300 Mbit/s eingehend (S2C).
>
> Was ist das denn für eine Netzwerkkarte (Chipsatz, Bus, Lanes)?
Ethernet controller: Intel Corporation 82599EB 10 Gigabit Dual Port
> Am 18.01.2012 14:20, schrieb Gerald Vogt:
>
> > 1. Wenn die Netzwerkkarte auf 1 GE konfiguriere, dann kriege ich einen
> > Durchsatz von ca. 850-925 Mbit/s ausgehend (C2S) und ca. 200-300 Mbit/
> > s eingehend (S2C).
>
> > 2. Wenn ich die Netzwerkkarte auf 10 GE konfiguriere, dann sind es
> > plötzlich nur noch ca. 100-200 Mbit/s ausgehend (C2S) bei immer noch
> > ca. 150-300 Mbit/s eingehend (S2C).
>
> Was ist das denn für eine Netzwerkkarte (Chipsatz, Bus, Lanes)?
Backplane Connection (rev 01)
Subsystem: Intel Corporation Ethernet X520 10GbE Dual Port KX4-KR Mezz
> Steckt Sie im passenden PCI-Slot?
gehört.
> Wie lang ist das Kupferkabel zum Switch? Welche Qualität hat es?
Gerald
Bernd Eckenfels
Jan 25, 2012, 6:32:32 PM1/25/12
to
Gerald Vogt <vo...@spamcop.net> wrote:
> Und selbst im normalen aktiven Regelsatz wird Source Quench nicht
> gefiltert noch irgendwas sonst "unsichtbar" gemacht.
Wichtig ist halt dass der Router der die ICMP Nachricht erzeugt das mit ner
> Und selbst im normalen aktiven Regelsatz wird Source Quench nicht
> gefiltert noch irgendwas sonst "unsichtbar" gemacht.
"routbaren" IP Addresse macht.
Gruss
Bernd
0 new messages