Netwerklastgenerator
Nico Sachs
Habe schon öfters von Netzwerklastgeneratoren gelesen, aber immer nur
als Hardware. Gibt es da auch Software-Lösungen?
bis dann,
Nico
Michael Kamper
Ist das jetzt die 'höfliche' Bezeichnung für ein DOS-Attackenprogramm ;)
*SCNR*
Gruß
Michael
Michael Kopp
Ist auch ne nette Idee, aber ist doch viel besser im Einsatz um mal zu
testen wie gut deine QoS Parameter im Netz funktionieren oder ob deine
gemietete Strecke auch das hergibt was der Provider verspricht !!!
schau mal bei
http://dast.nlanr.net/
die haben da ein paar nette Tools auch um Multicast und so zu testen
-> iperf und netperf werden wohl deine Freunde sein
dann gibt`s da noch mgen usw ...
hoffe da ist was nettes für dich dabei
Michael
PS : Wenn wir schon beim Thema sind, ich suche ein Tool (also am besten
Freeware und für *nix ) mit dem ich mehrere TCP Streams aufmachen kann und
mit diesen die Leitung vollmachen kann. Am Besten mit ner Auswertung des
Verhaltens der Window Size, Einstellmöglichkeiten der TOS Bits, usw ...
träum ;-)
Nico Sachs
"Michael Kamper" <Michael...@gmx.de> schrieb im Newsbeitrag
news:abacbq$ms8$04$1...@news.t-online.com...
> Nico Sachs <Nico...@t-online.de> schrieb
> Ist das jetzt die 'höfliche' Bezeichnung für ein
DOS-Attackenprogramm ;)
Nein, ernsthaft: ich habe ein Buch über Fehlersuche im LAN gelesen,
und da stand öfters von einem Gerät, was eine Last im Netzwerk
generiert.
Und eigentlich ist ja so was auch durch Software möglich, z.B.
DoS-Attack :-) Aber erreicht man damit Last von 60-80% ?
bis dann,
Nico
Rainer Nagel
On Wed, 8 May 2002 16:16:35 +0200,
Nico Sachs <Nico...@t-online.de> wrote:
> Nein, ernsthaft: ich habe ein Buch über Fehlersuche im LAN gelesen,
> und da stand öfters von einem Gerät, was eine Last im Netzwerk
> generiert.
>
> Und eigentlich ist ja so was auch durch Software möglich, z.B.
> DoS-Attack :-) Aber erreicht man damit Last von 60-80% ?
Kommt drauf an, wovon 60-80% erreicht werden sollen.
Einen FE-Link vollzumachen ist heute keine Kunst mehr, bei GE ist das
etwas schwieriger, aber auch ohne große Verrenkungen machbar.
Nimm dir zwei Rechner (für FE fast egal, für GE sollten sie performant
sein) und nutze Tools wie netpipe oder netperf.
Für GE mußt du bei TCP mehrere Streams parallel fahren, mit UDP kommst
du mit einem einzelnen Stream auf gute Datenraten.
Wenn du nicht nur Last in Form von beliebigen Paketen haben möchtest,
sondern einen Mix von großen und kleinen TCP- und UDP-Paketen zuzüglich
einiger Broadcasts (arp, smb), dann wird es deutlich komplizierter.
Ciao
--
Rainer Nagel
Rainer...@tashrah.com
Duesseldorfer Linux User Group - http://www.dlug.de
Felix von Leitner
> Für GE mußt du bei TCP mehrere Streams parallel fahren,
Soso.
> mit UDP kommst du mit einem einzelnen Stream auf gute Datenraten.
Aha. UDP-Stream.
> Wenn du nicht nur Last in Form von beliebigen Paketen haben möchtest,
> sondern einen Mix von großen und kleinen TCP- und UDP-Paketen zuzüglich
> einiger Broadcasts (arp, smb), dann wird es deutlich komplizierter.
Oi, SMB-Broadcasts.
Sag, wie kommt jemand mit deiner Unwissenheit dazu, hier so abgrundtief
schlecht den Experten zu simulieren?
Felix
--
>> Du onanierst am falschen Ort.
> Huh?
Q.E.D.
--Peter Lemken demontiert einen DAU
Rainer Nagel
On Fri, 10 May 2002 01:34:59 GMT,
Felix von Leitner <usenet-...@fefe.de> wrote:
> Thus spake Rainer Nagel (rai...@dragon.angor.de):
>> Für GE mußt du bei TCP mehrere Streams parallel fahren,
>
> Soso.
Durch das Bandbreiten-Latenz-Produkt ist die nutzbare Bandbreite eines
Links ebenso begrenzt, wie durch die maximale Bandbreite des Links
selber.
Das Window an Daten, die gleichzeitig unterwegs sind (TCP-Window) ist
Window = Bandbreite * Latenz
oder
Bandbreite = Window / Latenz
oder
Latenz = Window / Bandbreite.
Ergo ist bei einem TCP-Window von 64kByte (= 65536 Bytes) und einer
gewünschten Bandbreite von 1GE (1000.000.000 Bit/s) die maximale
erlaubte Latenz gleich:
Latenz = 65536 Bytes * 8 Bit/Byte / 1000.000.000 Bit/s
= .00052 s
= 0.52 ms
Das gilt von Prozess zu Prozess und nicht Netzwerkkarte zu
Netzwerkkarte.
Ein Paket selber hat bei 1500 Byte MTU 12.144 us Dauer, das ist
definitiv OK. Auch wenn ein Switch dazwischen sitzt, der mit store and
forward arbeitet, werden halt nochmal die selben 12.144 us (+
Verarbeitungszeit im Switch, vernachlässigbar) dazukommen.
Der ACK ist mit 64 Byte dagegen ebenfalls vernachlässigbar.
Dazu kommen in beiden beteiligten Rechnern aber die Verarbeitungszeiten
pro Paket, die deutlich höher sein können.
Z.B. habe ich zwischen zwei Rechnern über die Glas-GE-Karten round-trips
für 1500-Byte-Pakete von 0.3ms, für 700-Byte-Pakete von 0.2ms und für
64-Byte-Pakete von 0.1ms.
Beide Rechner haben weder die CPU noch das GE sinnvoll belastet.
Dazwischen hängen 2 Cisco Catalyst 6509 mit 4 getrunkten GE-Links, die
aktuell jeweils mit ca. 150-180MBit/s belastet sind, also nicht queuen
sollten. Dafür spricht auch, das die einzelnen rtt's nur wenig Abweichung
vom Mittelwert haben.
Und ICMP-Echo-Requests werden im Kernel relativ schnell abgehandelt und
müssen insbesondere nicht nochmal zu einem Userlevel-Prozess gegeben
werden, was die Latenz weiter erhöht.
Dazu kommt, das TCP-Pakete mehr Aufwand im Kernel im TCP-Stack erzeugen
und bei einem Lastgenerator auf beiden Rechnern jeweils einen Übergang
Kernel/Userlevel haben.
In Tests (Serverworks-LE-Chipset, 2x833MHz Pentium-III, 512MByte,
GE-Karten Syskonnekt bzw. Alteon, kein Switch dazwischen) haben wir halt
250MBit/s mit einer TCP-Session mit netperf erhalten. Bei zwei
TCP-Sessions kamen wir auf 430MBit/s, bei drei TCP-Sessions auf
450MBit/s.
Bei Test per UDP-Stream kamen wir mit einem Stream auf 450MBit/s.
Dabei war auf beiden Rechnern die CPU bei 99%.
Das mag mit deutlich schnelleren Rechnern sicherlich anders aussehen.
Dabei ist auch die Belastung der CPU durch die hohe Zahl an Interrupts
zu beachten. Diese kann zwar reduziert werden, indem Interrupts
zusammengefaßt werden, dabei steigt aber die Latenz und die Bandpreite
pro TCP-Session sinkt, obwohl mit mehreren TCP-Sessions so mehr
Bandbreite erreicht werden kann.
>> mit UDP kommst du mit einem einzelnen Stream auf gute Datenraten.
>
> Aha. UDP-Stream.
Ja, ein Strom von UDP-Paketen. Wie würdest du das nennen?
Dazu auch ein sinngemäß gekürzter Auszug aus der manpage von netperf:
-t testname
Specify the test to perform. Valid testnames are
(but not always compiled-in):
TCP_STREAM
UDP_STREAM
>> Wenn du nicht nur Last in Form von beliebigen Paketen haben möchtest,
>> sondern einen Mix von großen und kleinen TCP- und UDP-Paketen zuzüglich
>> einiger Broadcasts (arp, smb), dann wird es deutlich komplizierter.
>
> Oi, SMB-Broadcasts.
ramoth:~# tcpdump -n -i eth0 port 137 or port 138 or port 139
tcpdump: listening on eth0
21:49:40.673832 194.97.106.227.137 > 194.97.106.231.137:
>>> NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST (DF)
21:49:40.674492 194.97.106.225.137 > 194.97.106.227.137:
>>> NBT UDP PACKET(137): QUERY; POSITIVE; RESPONSE; UNICAST
Wie würdest du diese Pakete bezeichnen, wenn nicht smb broadcasts?
AFAIK versenden Windows-Maschinen regelmäßig Broadcasts, um ihre eigenen
Informationen anderen Rechnern im selben Netz mitzuteilen, was ein
integraler Bestandteil des SMB-Protokolls ist.
Man kann das sicherlich durch passende Konfiguration der Rechner
minimieren, vielleicht sogar eliminieren, aber die Möglichkeit existiert
und kann bei Testszenarien zu betrachten sein.
Achim Hammer
"Nico Sachs" <Nico...@t-online.de> schrieb im Newsbeitrag
news:abbbsv$q6$01$1...@news.t-online.com...
>
> Nein, ernsthaft: ich habe ein Buch über Fehlersuche im LAN gelesen,
> und da stand öfters von einem Gerät, was eine Last im Netzwerk
> generiert.
Hallo Nico,
was das Thema angeht bin ich nur auf der Windows-Seite bewandert.
Die Software die du suchst wird allgemein als Packetgenerator bezeichnet.
Das simpelste Ding, dass mir in dem Zusammenhang begegnet ist, ist IPLoad.
http://www.bttsoftware.co.uk/ipload.html
Aber die Dinger sind IMHO alle mit Vorsicht zu geniesen. Wir hier konnten
nie die Packetzahlen nachmessen, die IPLoad angeblich verschickt haben will
(dito bei weiteren Produkten).
Wenn du in deinem LAN nun Performancemessungen machen willst, rate ich dir
persönlich zu IPerf. Neben der klaren Konzeption gefällt mir vorallem, dass
es in allen Welten zu hause ist. Version 1.1 läuft nämlich auch unter
Windows 98, 2000 (und nach eigenem Bekunden auch WinNT). Unter Windows 2000
lies sich darüber hinaus ein grafisches Java-Frontend aktivieren.
Weitere Packetgeneratoren findest du unter Win eigentlich nur in
Bezahl-Software (tlw. sehr teuer).
So denn....