9
Verluste beim Dauerping im WAN ... was ist noch ok?
Kann mir jemand fundiert darüber Auskunft geben, welche Verlustraten in WAN´s noch tolerierbar sind?
Hallo zusammen,
mein Arbeitsgebiet sind unter anderem die Weitverkehrsleitungen in einer größeren Behörde (1000 Mitarbeiter) mit mehreren Liegenschaften, die im Stadtgebiet bzw. im Bundesland verteilt sind. Die Außenstellen sind mit verschiedensten Verbindungen verknüpft (Mikrowelle, LaserLink, Funk und Kabel). Soweit zum Umfeld.
Nachdem ich meine *geliebten* Linux-Proxies weisungsbedingt durch Microsoft-ISA-Server tauschen musste, kamen immer wieder Beschwerden über die Performance der Internetzugänge hoch. Mit recht hohem Aufrüstungsaufwand der Hardware, konnte das Problem gemildert, jedoch nicht beseitigt werden.
Admin-Kollegen aus einer anderen Liegenschaft, die sich mit einem neuen Mammutprojet des Landes beschäftigen, beklagen zudem die Performance ihrer Anwendung über das WAN.
Ständig suchen sie die Ursache natürlich nicht im eigenen Bereich, sondern in den WAN-Verbindungen zu finden.
Neuester Versuch: Ein Dauerping an mehrere Server über einen Tag ergibt eine Verlustrate von gemittelt 0,5%. Dieses Ergebnis wird mit so fundierten Kommentaren wie ... empfinde ich als nicht normal ... und ... nach meinem Kenntnisstand gab es die früher nicht in diesem Ausmaß ... an die Chefetage gepostet.
Nun komme ich zu meiner eingangs gestellten Frage zurück:
Kann mir jemand fundiert darüber Auskunft geben, welche Verlustraten in WAN´s noch tolerierbar sind?
Leider konnte ich trotz längerer Suche im Netz keine Aussagen hierzu finden.
Einen Screenshot des Ping-Ergebnisses könnt ihr hier sehen:
http://www.hl-online.de/test/hc_220.jpg
Vielen Dank!
mein Arbeitsgebiet sind unter anderem die Weitverkehrsleitungen in einer größeren Behörde (1000 Mitarbeiter) mit mehreren Liegenschaften, die im Stadtgebiet bzw. im Bundesland verteilt sind. Die Außenstellen sind mit verschiedensten Verbindungen verknüpft (Mikrowelle, LaserLink, Funk und Kabel). Soweit zum Umfeld.
Nachdem ich meine *geliebten* Linux-Proxies weisungsbedingt durch Microsoft-ISA-Server tauschen musste, kamen immer wieder Beschwerden über die Performance der Internetzugänge hoch. Mit recht hohem Aufrüstungsaufwand der Hardware, konnte das Problem gemildert, jedoch nicht beseitigt werden.
Admin-Kollegen aus einer anderen Liegenschaft, die sich mit einem neuen Mammutprojet des Landes beschäftigen, beklagen zudem die Performance ihrer Anwendung über das WAN.
Ständig suchen sie die Ursache natürlich nicht im eigenen Bereich, sondern in den WAN-Verbindungen zu finden.
Neuester Versuch: Ein Dauerping an mehrere Server über einen Tag ergibt eine Verlustrate von gemittelt 0,5%. Dieses Ergebnis wird mit so fundierten Kommentaren wie ... empfinde ich als nicht normal ... und ... nach meinem Kenntnisstand gab es die früher nicht in diesem Ausmaß ... an die Chefetage gepostet.
Nun komme ich zu meiner eingangs gestellten Frage zurück:
Kann mir jemand fundiert darüber Auskunft geben, welche Verlustraten in WAN´s noch tolerierbar sind?
Leider konnte ich trotz längerer Suche im Netz keine Aussagen hierzu finden.
Einen Screenshot des Ping-Ergebnisses könnt ihr hier sehen:
http://www.hl-online.de/test/hc_220.jpg
Vielen Dank!
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 43511
Url: https://administrator.de/contentid/43511
Printed on: April 24, 2024 at 09:04 o'clock
9 Comments
Latest comment
Hi,
welche Verlustrate tolerierbar ist, hängt von der Anwendung ab. Wenn ein Echo-Paket nicht zurückkommt, dann kann das durchaus mehrere Ursachen haben:
- Überschreitung der Wartezeit
- dynamisches Routing geht über Gateways, die kein ICMP gestatten (unwahrscheinlich)
- die Gegenstelle reagiert nicht (sollte sich bei euch ja auch nicht ergeben)
- die Leitungsqualität ist schlecht
- die Leitung ist überlastet
- Die maximale Anzahl an Hops wird überschritten (TTL)
Die Aussgae alleine, dass ein paar ECHO Pakete nicht ankommen, ist keine Aussage für eine schlechte Leitungsqualität - es kommt immer auch auf den Einsatzbereich an.
Protokolle, die keine eigene Fehlererkennung und Korrektur haben, fliegen volle Kanne auf die Nase, wogegen andere viel toleranter sind und das Paket einfach nochmal anfordern ...
Interessant wäre auch noch, wie die Ping Antwortzeit normalerweise aussieht und ob sie stark schwankt und was passiert ist, wenn doch mal Pakete verloren gehen. Passiert das eventuell immer um die gleiche Zeit - vielleicht werden da irgendwelche Komponenten im Netz automatisch resettet oder Wartungen beim Provider vorgenommen oder sonstwas in der Art.
cu,
Alex
welche Verlustrate tolerierbar ist, hängt von der Anwendung ab. Wenn ein Echo-Paket nicht zurückkommt, dann kann das durchaus mehrere Ursachen haben:
- Überschreitung der Wartezeit
- dynamisches Routing geht über Gateways, die kein ICMP gestatten (unwahrscheinlich)
- die Gegenstelle reagiert nicht (sollte sich bei euch ja auch nicht ergeben)
- die Leitungsqualität ist schlecht
- die Leitung ist überlastet
- Die maximale Anzahl an Hops wird überschritten (TTL)
Die Aussgae alleine, dass ein paar ECHO Pakete nicht ankommen, ist keine Aussage für eine schlechte Leitungsqualität - es kommt immer auch auf den Einsatzbereich an.
Protokolle, die keine eigene Fehlererkennung und Korrektur haben, fliegen volle Kanne auf die Nase, wogegen andere viel toleranter sind und das Paket einfach nochmal anfordern ...
Interessant wäre auch noch, wie die Ping Antwortzeit normalerweise aussieht und ob sie stark schwankt und was passiert ist, wenn doch mal Pakete verloren gehen. Passiert das eventuell immer um die gleiche Zeit - vielleicht werden da irgendwelche Komponenten im Netz automatisch resettet oder Wartungen beim Provider vorgenommen oder sonstwas in der Art.
cu,
Alex
Hi
Und dieses Problem ist exaxt dann aufgetreten , nachdem dein "heisgeliebter " Linux durch den ISA getauscht wurde?
Wurde sonst noch etwas verändert....z.B router
Welche Version des ISAs Servers setzt du ein? Bei ISA das SP2 drauf?
Wie fungiert der ISA Server denn?
Also generell sind diese Werte nicht normal.....Auch ein gut konfiguriertes System läuft mit ISA sehr gut....
Kann es sein das eventuel ..."Filter" aktiv sind die unötig filtern?
mfg rooks
Und dieses Problem ist exaxt dann aufgetreten , nachdem dein "heisgeliebter " Linux durch den ISA getauscht wurde?
Wurde sonst noch etwas verändert....z.B router
Welche Version des ISAs Servers setzt du ein? Bei ISA das SP2 drauf?
Wie fungiert der ISA Server denn?
Also generell sind diese Werte nicht normal.....Auch ein gut konfiguriertes System läuft mit ISA sehr gut....
Kann es sein das eventuel ..."Filter" aktiv sind die unötig filtern?
mfg rooks
Wichtig ist erstmal zu wissen WIE die Aussenstellen angebunden sind ? Über die verschiedenen Infrastrukturen haben wir ja schon erfahren, allerdings ist es wichtig zu wissen ob diese WAN Links geroutet sind oder ob sie z.B. "flach" (Layer 2) sind wenn sie ggf. nur über Laser oder Mikrowelle gebridged werden und..... welche Bandbreite diese haben !!!
Auch hat die Gesamtstruktur der LANs in den Aussenstellen und vornehmlich am Hauptstandort einen nicht unerheblichen Einfluss.
Wird segmentiert mit VLANs (= kleine Broadcastdomains = wenig Belastung der Links durch Broadcast Grundrauschen)...wird nicht segmentiert und ist alles "flach" (=sehr hohe Broadcastbelastung und damit wahrscheinlich höhere Broadcast Belastung bei Links mit niedrigen Bandbreiten).
Das Broadcastverhalten ist nicht ganz so relevant wenn konsequent geroutet wird auf den WAN Links.
Letztlich ist es aber sehr schwer eine qualifizierte Aussage zu treffen, denn man müsste die Gesamtbelastung und Bandbreite dieser Links kennen.
Was in jedem Falle hilft ist einmal eine langfristige Betrachtung mit SNMP Tools wie SNMPTG oder MRTG auf den Routerports oder Bridgeports zu machen die diese Links bedienen, wie die prozentuale Last ist.
Danach könnte man einmal vorsichtig eine Prognose wagen.
Fakt ist aber das mit dem Einsatz von MS Produkten über WANs bei nicht so hohen Bandbreiten meist eine Verschlechterung der Bandbreitennutzung einher geht da diese nun mal sehr "geschwätzige" Protokolle benutzen und man einen erheblichen Aufwand in Filterung und Customizing des Netzes betreiben muss um das in den Griff zu bekommen.
Leider wird das im Behördenbereich die häufig MS "hörig" sind vollkommen übersehen und oft nicht beachtet oder aus Mangel an Kenntnis der "Weisungsbefugten" nicht umgesetzt. (nichts gegen dich..)
Nach einer sehr langen Leidenszeit wird dann meist einfach die Bandbreite erhöht (was immer Mehrkosten im Haushalt erfordert..) und das Problem dann einfach und simpel mit Bandbreite erschlagen.....bis zur nächsten Einführung von MS Tools...
Normalerweise sollte aber bei einem Ping über eine Bandbreiten seitig nicht zu niedrige WAN Anbindung keine Ping Ausfälle zu sehen sein sofern dies eine Point zu Point Verbindung ist und nicht noch über mehrere Routerhops geht. Meist sind solche Behördennnetze ja eh sternförmig historisch gewachsen.
Aber auch dann sollten keine Ausfälle zu sehen sein. Pinge mal den Heise Server (ct etc.) abends und vergleich mal wieviele Ausfälle du bekommst. Meist keine und das gilt auch mit einem analogen Dialin mit 40 kB/s !
Ausfälle zeugen eher von einer totalen Überlastung dieser Links oder altersschwachen Servern....pauschal lässt sich das aber nicht sagen, da sind (noch) zu viele Unbekannte drin.
Auch hat die Gesamtstruktur der LANs in den Aussenstellen und vornehmlich am Hauptstandort einen nicht unerheblichen Einfluss.
Wird segmentiert mit VLANs (= kleine Broadcastdomains = wenig Belastung der Links durch Broadcast Grundrauschen)...wird nicht segmentiert und ist alles "flach" (=sehr hohe Broadcastbelastung und damit wahrscheinlich höhere Broadcast Belastung bei Links mit niedrigen Bandbreiten).
Das Broadcastverhalten ist nicht ganz so relevant wenn konsequent geroutet wird auf den WAN Links.
Letztlich ist es aber sehr schwer eine qualifizierte Aussage zu treffen, denn man müsste die Gesamtbelastung und Bandbreite dieser Links kennen.
Was in jedem Falle hilft ist einmal eine langfristige Betrachtung mit SNMP Tools wie SNMPTG oder MRTG auf den Routerports oder Bridgeports zu machen die diese Links bedienen, wie die prozentuale Last ist.
Danach könnte man einmal vorsichtig eine Prognose wagen.
Fakt ist aber das mit dem Einsatz von MS Produkten über WANs bei nicht so hohen Bandbreiten meist eine Verschlechterung der Bandbreitennutzung einher geht da diese nun mal sehr "geschwätzige" Protokolle benutzen und man einen erheblichen Aufwand in Filterung und Customizing des Netzes betreiben muss um das in den Griff zu bekommen.
Leider wird das im Behördenbereich die häufig MS "hörig" sind vollkommen übersehen und oft nicht beachtet oder aus Mangel an Kenntnis der "Weisungsbefugten" nicht umgesetzt. (nichts gegen dich..)
Nach einer sehr langen Leidenszeit wird dann meist einfach die Bandbreite erhöht (was immer Mehrkosten im Haushalt erfordert..) und das Problem dann einfach und simpel mit Bandbreite erschlagen.....bis zur nächsten Einführung von MS Tools...
Normalerweise sollte aber bei einem Ping über eine Bandbreiten seitig nicht zu niedrige WAN Anbindung keine Ping Ausfälle zu sehen sein sofern dies eine Point zu Point Verbindung ist und nicht noch über mehrere Routerhops geht. Meist sind solche Behördennnetze ja eh sternförmig historisch gewachsen.
Aber auch dann sollten keine Ausfälle zu sehen sein. Pinge mal den Heise Server (ct etc.) abends und vergleich mal wieviele Ausfälle du bekommst. Meist keine und das gilt auch mit einem analogen Dialin mit 40 kB/s !
Ausfälle zeugen eher von einer totalen Überlastung dieser Links oder altersschwachen Servern....pauschal lässt sich das aber nicht sagen, da sind (noch) zu viele Unbekannte drin.
Hallo und Danke erstmal...
die beiden oberen Server-Tests kamen über einen 100 Mbit-LaserLink zustande. Standard-Response-Time <1ms
Alle paar Minuten kommt mal ein Paket dazwischen, welches 100-200 ms braucht, oder eben vollkommen verloren geht.
Die andere Server liegen über 100 km entfernt. Der Weg läuft über eine 34MBit-Mikrowelle, mehrere Router und Media-Konverter und eine 10MBit-ATM-Strecke in eine Rechenzentrum. Standard-Response-Time 3ms. Alle 10 bis 20 Pakete kommt mal ein Response im zweistelligen Bereich.
Seltsamerweise sind die Drops auf der Kurzstrecke (2 km) über LaserLink etwa doppelt so hoch, wie auf der Weitverkehrsstrecke.
die beiden oberen Server-Tests kamen über einen 100 Mbit-LaserLink zustande. Standard-Response-Time <1ms
Alle paar Minuten kommt mal ein Paket dazwischen, welches 100-200 ms braucht, oder eben vollkommen verloren geht.
Die andere Server liegen über 100 km entfernt. Der Weg läuft über eine 34MBit-Mikrowelle, mehrere Router und Media-Konverter und eine 10MBit-ATM-Strecke in eine Rechenzentrum. Standard-Response-Time 3ms. Alle 10 bis 20 Pakete kommt mal ein Response im zweistelligen Bereich.
Seltsamerweise sind die Drops auf der Kurzstrecke (2 km) über LaserLink etwa doppelt so hoch, wie auf der Weitverkehrsstrecke.
Ich möchte hier keinen Betriebssystemstreit lostreten 
))
Selbst innerhalb unserer IT-Teams favorisieren die einen MS, die anderen Linux.
Aber es kam halt zu heftigen Performancebeschwerden, nachdem wir den ISA einsetzten. Die Linux-Büchse war eine kleine Workstation (1700 MHz) und dem Squid als Proxy. Sie brachte rund 300 Arbeitsplätze recht performant ins Internet.
Im Zuge der AD-Migration wurde auf ISA umgestellt, der lediglich als Proxy fungiert und keinerlei Firewallaufgaben zu erledigen hat.
Nachdem die alte Maschine zunächst mit 2 Gig Speicher hochgerüstet wurde und sich keine Verbesserung einstellte, wurde ein neuer echter Server eingesetzt. Trotzdem wird permanent genörgelt und man sucht nun Fehler im Netzwerk.
...und so kam es zu meinem Post
))Selbst innerhalb unserer IT-Teams favorisieren die einen MS, die anderen Linux.
Aber es kam halt zu heftigen Performancebeschwerden, nachdem wir den ISA einsetzten. Die Linux-Büchse war eine kleine Workstation (1700 MHz) und dem Squid als Proxy. Sie brachte rund 300 Arbeitsplätze recht performant ins Internet.
Im Zuge der AD-Migration wurde auf ISA umgestellt, der lediglich als Proxy fungiert und keinerlei Firewallaufgaben zu erledigen hat.
Nachdem die alte Maschine zunächst mit 2 Gig Speicher hochgerüstet wurde und sich keine Verbesserung einstellte, wurde ein neuer echter Server eingesetzt. Trotzdem wird permanent genörgelt und man sucht nun Fehler im Netzwerk.
...und so kam es zu meinem Post
Generell wird bei uns alles geroutet. Jede Außenstelle hat ihr eigenes VLAN. Der LaserLink und die Mikrowelle arbeiten mit Transfernetzbereichen. Das größte VLAN hat die Hauptstelle. Ca. je 40-80 Hosts gehen über 100MBit-Kupfer zu Etagenswitchen (bzw. Stacks, etwa 20 Stück) und von dort mit Licht zum Zentralswitch.
Die Transfernetze mit den WAN-Links sind direkt auf den Zentralswitch gelegt.
Die Transfernetze mit den WAN-Links sind direkt auf den Zentralswitch gelegt.
tach
Hmm...
wäre auch gut so.."keinen Betriebsystemstreit"
also...du sagtest : es wurde ein neuer echter Server eingesetzt.
Vielleicht liegt ja die Fehlerursache an ihm?
sprich falsche Treiber...etc...
kannste mal probehalber den ISA abschalten und einfach mal n dauerping an einen anderen Server im INternern netz zu senden...? sprich ping ip -t
mfg rooks
Hmm...
wäre auch gut so.."keinen Betriebsystemstreit"
also...du sagtest : es wurde ein neuer echter Server eingesetzt.
Vielleicht liegt ja die Fehlerursache an ihm?
sprich falsche Treiber...etc...
kannste mal probehalber den ISA abschalten und einfach mal n dauerping an einen anderen Server im INternern netz zu senden...? sprich ping ip -t
mfg rooks
Trotzdem aus Netzwerksicht darf es in einem rein gerouteten WAN das aus Point to Point Transfernetzen besteht NIE zu solchen Ping Ausfällen kommen !!!
Wie gesagt die Voraussetzung ist das es wirklich geroutet ist und nicht ein komplettes VLAN irgendwo über einen gebridgten Link (also Schicht 2) über eine WAN Strecke übertragen wird !
Das erfordert dann natürlich auch Layer 3 sprich Routing fähige Switches in den Aussenstellen aber wenn es so ist wie du beschreibst kann man ja davon ausgehen.
Dadurch sind ja dann alle Broadcast Domains von den WAN Links abgetrennt und dort wird dann nur Wirktraffic übertragen und kein Broad- oder Unicast mehr.
Auch wenn jemand dort einen großen Filetransfer lostritt darf es nicht zu solchen Pingverlusten kommen, die liegen in jedem Fall erheblich zu hoch.
Um das genau zu analysieren sollte man an den Routern mal sniffern oder wenigstens mit SNMPTG auf die WAN Ports sehen wer diesen Traffic verursacht, denn ohne eine genaue Kenntnis des Netzdesigns ist die Spekulationsrate hoch... Ping rennt ja nicht über einen Proxy so das man davon ausgehen kann das es schon überlastete Leitungen sind und nicht ein mehr oder weniger geschwätziger MS Host. Vielleicht ist er einer der Verursacher aber wie gesagt ohne Messung ist das Wahrsagerei....
Wie gesagt die Voraussetzung ist das es wirklich geroutet ist und nicht ein komplettes VLAN irgendwo über einen gebridgten Link (also Schicht 2) über eine WAN Strecke übertragen wird !
Das erfordert dann natürlich auch Layer 3 sprich Routing fähige Switches in den Aussenstellen aber wenn es so ist wie du beschreibst kann man ja davon ausgehen.
Dadurch sind ja dann alle Broadcast Domains von den WAN Links abgetrennt und dort wird dann nur Wirktraffic übertragen und kein Broad- oder Unicast mehr.
Auch wenn jemand dort einen großen Filetransfer lostritt darf es nicht zu solchen Pingverlusten kommen, die liegen in jedem Fall erheblich zu hoch.
Um das genau zu analysieren sollte man an den Routern mal sniffern oder wenigstens mit SNMPTG auf die WAN Ports sehen wer diesen Traffic verursacht, denn ohne eine genaue Kenntnis des Netzdesigns ist die Spekulationsrate hoch... Ping rennt ja nicht über einen Proxy so das man davon ausgehen kann das es schon überlastete Leitungen sind und nicht ein mehr oder weniger geschwätziger MS Host. Vielleicht ist er einer der Verursacher aber wie gesagt ohne Messung ist das Wahrsagerei....
Hallo unbekannterweise.
Ich habe auch mal ein paar Fragen zu dem Thema.
Wir hatten vorher ein Pix als Firewall. Diese wurde nun durch einen ISA 2006 ersetzt.
Seitdem habe ich beim Dauerping desöfteren Timeouts. Was zur Folge hat, das einige Druckerwarteschlangen am VPN Remotetunnelendpunkt dann nicht mehr erreichbar sind.
1) Kennt einer ein Proogg, mit dem ich nen Dauerping auf mehrere Hosts laufen lassen kann und das Ergebnis grafisch darstellen kann? Wie heißt das Progg, was chopper1958 genutzt hat?
Habe da schon diverse Tools gefunden, aber immer hat was gefehlt. Will heißen bei dem einen konnte man schön Protokollieren aber den Repeatwert nicht unter 1 sek setzen. Dann wieder andersrum. Nutze grad mal JetPing und Colasoft Ping Tool
2) Kennt einer ein Progg, mit dem ich den VPN Tunnelaufbau protokollieren kann? Und dannach überwachen kann? Vielleicht haben die ja Probleme mit dem Rekeying.
Zur Info
Der ISA Server ist eine eigenständige Maschine auf welcher noch ein WSUS läuft. Den hab ich grad mal deaktiviert.
Vielleicht liegt es ja auch an der LANkarte. Weiß aber nicht mehr, wo ich noch ansetzen könnte.
Ich habe auch mal ein paar Fragen zu dem Thema.
Wir hatten vorher ein Pix als Firewall. Diese wurde nun durch einen ISA 2006 ersetzt.
Seitdem habe ich beim Dauerping desöfteren Timeouts. Was zur Folge hat, das einige Druckerwarteschlangen am VPN Remotetunnelendpunkt dann nicht mehr erreichbar sind.
1) Kennt einer ein Proogg, mit dem ich nen Dauerping auf mehrere Hosts laufen lassen kann und das Ergebnis grafisch darstellen kann? Wie heißt das Progg, was chopper1958 genutzt hat?
Habe da schon diverse Tools gefunden, aber immer hat was gefehlt. Will heißen bei dem einen konnte man schön Protokollieren aber den Repeatwert nicht unter 1 sek setzen. Dann wieder andersrum. Nutze grad mal JetPing und Colasoft Ping Tool
2) Kennt einer ein Progg, mit dem ich den VPN Tunnelaufbau protokollieren kann? Und dannach überwachen kann? Vielleicht haben die ja Probleme mit dem Rekeying.
Zur Info
Der ISA Server ist eine eigenständige Maschine auf welcher noch ein WSUS läuft. Den hab ich grad mal deaktiviert.
Vielleicht liegt es ja auch an der LANkarte. Weiß aber nicht mehr, wo ich noch ansetzen könnte.
