Latenz bei Last von Client hoch, aber von 1781EF+ niedrig

[pal]

Ich habe seit einiger Zeit das Problem, dass die Latenz über unseren Company-Connect-Anschluss sehr hoch (ca. 1 Sekunde) ist, sobald Last auf der Leitung ist. Last bedeutet in diesem Fall, ab 4 MBit. Die Leitung gibt 8,6 Mbit her. Das Eigenartige ist, dass beim Trace die hohe Latenz zwischen dem LANCOM-Router und dem Cisco-Router der Telekom, der direkt daneben steht, auftritt. Wenn ich den Trace allerdings direkt per Console am LANCOM-Router absetze sehe ich davon nichts.

Einmal der Trace von meinem Rechner aus:

Code: Alles auswählen

tracepath 88.99.24.99 -n
 1:  192.168.40.6                                          1.336ms 
 2:  192.168.40.10                                         1.290ms asymm  6 
 3:  62.225.60.113                                       749.305ms 
 4:  80.152.6.21                                         674.189ms
 5:  62.154.27.89                                        563.306ms
 6:  62.156.131.250                                      645.239ms 
 7:  87.190.233.2                                        465.066ms 
 8:  80.255.14.6                                         491.203ms asymm  7 
 9:  80.255.15.122                                       508.734ms 
10:  213.239.245.2                                       570.554ms asymm  8 
11:  213.239.245.17                                      654.473ms asymm  9 
12:  213.239.245.234                                     303.250ms asymm 10 
13:  88.99.24.99                                         307.804ms reached
     Resume: pmtu 1500 hops 13 back 11 

Und vom 1781EF+:

Code: Alles auswählen

ping 88.99.24.99 -r 

0 Traceroute 62.225.60.113     seq.no=0 time=0.986 ms      
1 Traceroute 80.152.6.21       seq.no=1 time=11.647 ms     
2 Traceroute 62.154.27.89      seq.no=2 time=6.572 ms      
3 Traceroute 62.156.131.250    seq.no=3 time=12.463 ms     
4 Traceroute 87.190.233.2      seq.no=4 time=11.776 ms     
5 Traceroute 80.255.14.6       seq.no=5 time=11.760 ms     
6 Traceroute 80.255.15.122     seq.no=6 time=12.331 ms     
7 Traceroute 213.239.245.2     seq.no=7 time=12.243 ms     
8 Traceroute 213.239.245.17    seq.no=8 time=16.103 ms     
9 Traceroute 213.239.245.234   seq.no=9 time=17.847 ms
  Traceroute 88.99.24.99       seq.no=10 time=16.375 ms

CPU-Last steht in etwa bei 25% wobei 6% IPV4 entfallen und 15% EH (keine Ahnung was das ist).


Warum verhält sich das so unterschiedlich? Es wirkt so, als würde der LANCOM-Router hier irgendwie bremsen. Allerdings sollte die Menge traffic ja kein Problem darstellen, zumal gleichzeitig die DSL-Leitung Problem benutzt werden kann, ohne irgend welche nennenswerten Latenzen, also so mit ca. 40 ms.
Was kann ich noch überprüfen, um dem Problem auf die Schliche zu kommen?

[Dr.Einstein]

Hi pal,

kann es sein, dass du zwischen Cisco und Lancom ein Dublex Mismatch oder ähnliches hast? Schau dir mal den Status der Schnittstelle an. Ansonsten sind 25% CPU unrealistisch bei 4 Mbit/s. Könnte sein, dass z.B. eine Netzwerkschleife im LAN die CPU Last hochdrückt, was auch die Pings erklären könnte :s

Gruß Dr.Einstein

[pal]

Auf den Cisco-Router habe ich leider keinen Zugriff. Der wird komplett von der Telekom gemanaged. Das Interface ist im LANCOM auf 'AUTO' eingestellt und er zeigt folgendes an:

Code: Alles auswählen

Port              INFO:    WAN
Assignment        INFO:    DSL-1
Private-Mode      INFO:    Yes
Link-Active       INFO:    Yes
Connector         INFO:    FD100B-TX
Auto-Negotiation  INFO:    Completed
Flow-Control      INFO:    No
MDI-Mode          INFO:    MDI
Remote-Fault      INFO:    No
Downshift         INFO:    No
Clock-Role        INFO:    None
Power-Saving      INFO:    No

Wegen den 25% CPU muss man auch beachten, dass zu dem Zeitpunkt auch noch 10 MBit auf der DSL-Leitung aktiv war.

Sollte die Netzschleife den Ping vom LANCOM-Router aus nicht auch betreffen? Der WAN-Port ist direkt mit dem CISCO verbunden.

[pal]

Ich habe nun mal genauer angeschaut, ob bei den Schnittstellen Probleme existieren. Dabei sind mir in folgender Tabelle Fehler aufgefallen:

Code: Alles auswählen

ls /Status/TCP-IP/TCP/

LAN-Checksum-Errors  INFO:    0
LAN-Connections      INFO:    1
LAN-Rx               INFO:    24610
LAN-Service-Errors   INFO:    7069
LAN-Tx               INFO:    16026
LAN-Tx-Repeats       INFO:    0
WAN-Checksum-Errors  INFO:    51
WAN-Connections      INFO:    0
WAN-Rx               INFO:    149379
WAN-Service-Errors   INFO:    149328
WAN-Tx               INFO:    0
WAN-Tx-Repeats       INFO:    0
Delete-Values        ACTION:  

Das sieht doch etwas eigenartig aus. Weiß jemand, was diese Service-Errors sind?

[pal]

Ich konnte nun mittlerweile feststellen, dass die Latenz bei Auslastung der Leitung immer nur dann richtig hoch wird, wenn QoS gerade aktiv ist. Das bedeutet, wenn gerade VoIP-Gespräche stattfinden, wird auf der Leitung Bandbreite reserviert und dann schnellt die Latenz in die Höhe.
Die QoS-Einstellung betrifft nur RTP und 'for DiffServer-CP=EF' und garantiert dann eine minimale Bandbreite von 80 kbit per Session.

[backslash]

Hi pal,

Die QoS-Einstellung betrifft nur RTP und 'for DiffServer-CP=EF' und garantiert dann eine minimale Bandbreite von 80 kbit per Session.

wnn du Pech hast, dann markiert das Telefon auch die RTCP-Pakete mit EF (was die meisten Telefone leider machen) und schon hast du pro Telefonat 160 kBit reserviert. Jenachdem wie "dick" dein Upload ist, kann das schnell zu einem Problem werden, weil das Gerät ja alles andere ausbremst...

Solange du pro Telefon nur ein Telefonat gleichzeitig führen willst/kannst, könntest du das QoS auch auf 80 kBit pro Station umstellen. Oder aber du nutzt entweder das SIP-ALG oder besser noch den VCM und überläßt diesen die QoS-Steuerung...

Gruß
Backslash

[pal]

Hallo Backslash. Danke für den Tipp.

Die Telefone stellen die Verbindung nicht direkt nach extern her. Wir haben noch einen Asterisk-Server dazwischen, der die Telefonate dann an Easybell weiter gibt. Im LAN-Monitor wird mir 80 kbit pro Telefonat angezeigt, wenn ich QoS manuell einstelle.

SIP-ALG musste ich aktivieren, da ich massiv Packet-Loss bekam, wenn mehrere Telefonate gleichzeitig (ab 3) nach extern geführt wurden. Hier gingen die gesendeten Pakete verloren.

Für mich bleibt dennoch die Frage, warum, sobald im LAN-Monitor QoS-Reservierungen angezeigt werden, die Latenz bei Last so stark nach oben geht.

[backslash]

Hi pal,

SIP-ALG musste ich aktivieren, da ich massiv Packet-Loss bekam, wenn mehrere Telefonate gleichzeitig (ab 3) nach extern geführt wurden. Hier gingen die gesendeten Pakete verloren.

das klingt aber danach, daß dein Uplaod nicht allzu "dick" ist...

Für mich bleibt dennoch die Frage, warum, sobald im LAN-Monitor QoS-Reservierungen angezeigt werden, die Latenz bei Last so stark nach oben geht.

weil das LANCOM dann alles andere entsprechend ausbremst... wenn du im schlimmsten Fall einen 128 kBit Upstream hast und davon 80 kBit für VoIP reservierst, dann bleiben für den Rest nur noch 48 kBit übrig - und auf genau diese Rate bremst das LANCOM die Pakete aus. Wenn nun mehr Pakete gesendet werden sollen, als in die 48 KBit reinpassen, dann stauen diese sich im LANCOM auf und die Latenz steigt...

Gruß
Backslash

[pal]

Hallo backslash,

ja, stimmt, der Upload ist nicht so toll, weil es hier auf dem Land nur einen Company-Connect 10M gibt. Netto habe ich hier 8,6 MBit übrig. Den Paketstau verstehe ich aber nicht so richtig. Ich kann die Leitung 'zuballern' wie ich will und die Latenz bleibt im Rahmen. Nur sobald QoS aktiv ist, steigt sie in einen inakzeptablen Bereich.
Meine, vermutlich falsche Vorstellung, ist, dass von den 8,6 MBit, die für QoS eingestellt sind, dann beispielsweise 7 MBit für andere Verbindungen übrig bleiben. Ich habe also dann sozusagen nur noch eine 7 MBit-Leitung. Alle Verbindungen die diese übrigen 7 MBit dann ohne QoS nutzen, haben die gleiche Priorität und die Pakete werden dann abwechselnd empfangen, im Prinzip genau so, wie ohne QoS nur eben mit eingeschränkter Bandbreite.

Ich hätte auch kein Problem, die doppelte Datenmenge für QoS zu reservieren, so lange die Leitung nutzbar bleibt, wenn beispielsweise ein Download läuft. Damit habe ich aber auch keine Besserung erzielen können.

[backslash]

Hi pal,

was hast du denn als Up- und Downstreamrate für dein DSL-Interface (unter Schnittstellen -> WAN -> Interface-Einsrtellungen -> DSL-x) eingestellt?

Gruß
Backslash

[pal]

Jeweils 8600. Ich hatte das testweise auch schon reduziert. Unter 4000 stellt sich eine Besserung ein, allerdings beschneide ich die Bandbreite damit schon sehr stark.

[Jirka]

Hi,

wenn Du einen Company Connect nach alter Bauart hast, dann muss da 8.704 kbit/s für Up- und Downstream und 12 Byte für externen Overhead eingetragen werden. Dann hast Du 7.737 kbit/s bei 64 Byte Paketen und 8.659 kbit/s bei 1.518 Byte großen Paketen. Somit wird der unterschiedlichen Übertragungsraten dieses Anschlusses bei verschiedenen Packetgrößen Rechnung getragen. Das funktioniert natürlich auch bei der Kombination von kleinen und großen (oder mittelgroßen) Paketen, was ja der Normalfall ist. (Steht auch in der LANconfig-Hilfe zu diesen Parametern.)

Viele Grüße,
Jirka

[pal]

Hallo Jirka,

vielen Dank für deine Hinweise. Mir war noch gar nicht richtig klar, dass bei kleineren Paketen der Overhead natürlich stärker durchschlägt und deswegen dieser Parameter durchaus relevant ist. Die konkreten Werte für den Company Connect zu wissen finde ich auch sehr gut.

Leider war bei mir der Overhead bis jetzt mit 32 byte eingestellt. Keine Ahnung woher ich den Wert hatte. Ich habe nun mal deine Werte übernommen, allerdings kann ich keinen Unterschied bei der Latenz feststellen.

Gruß,
PaL

[COMCARGRU]

Die konkreten Werte für den Company Connect zu wissen finde ich auch sehr gut.

Stellt sich die Frage wie wichtig diese sind? Anfangs bei einer 8011 an einem 100 MBit/s-Anschluss konnte man diese 100 MBit nicht mal korrekt eingeben wenn ich mich recht erinnere?

Wesentlich ist dieser Wert doch nur für QoS - und umso schnell die Anbindung ist, umso weniger wichtig dürfte hier der richtige Wert sein? Wenn ihr über eure 10 MBit-Leitung nicht gerade 100 Telefonate gleichzeitig führt, wird für die Telefonie doch wohl das eine oder andere KByte übrig sein?

Will sagen: Kann dieser Wert überhaupt etwas mit den Latenzen zu tun haben, wenn er dafür benutzt wird die Kapazitäten für QoS korrekt ausrechnen und verteilen zu können?

[pal]

Wenn ihr über eure 10 MBit-Leitung nicht gerade 100 Telefonate gleichzeitig führt, wird für die Telefonie doch wohl das eine oder andere KByte übrig sein?

Die hohe Latenz tritt auf, sobald mindestens ein Telefonat über die Leitung geführt wird, somit die QoS-Parameter aktiv sind und gleichzeitig z.B. ein Download durchgeführt wird. Der Download läuft dann ja auch mit fast voller Geschwindigkeit, also mit ca. 1 MByte/s.