Bandbreitenverlust durch Lancom Router

[Jirka]

Hallo,

@ Koppelfeld:
Es handelt sich um eine 500 MBit-SDSL-Glasfaserleitung der Deutschen Glasfaser und nicht um eine 1.000 MBit-Leitung der Telekom.

danach hatte der Kollege Koppelfeld aber nicht wirklich gefragt. Er fragte, und das aus gutem Grund, welche Bandbreite denn in der DSL-Schnittstelle (DSL-3?) im LANCOM eingetragen ist.

Therapie: Neuer Router, z.B. 1906 VA.

bzw. 1900EF.

@ GrandDixence:
Unabhängig vom vorher Geschriebenen, steht ja immer noch die Frage im Raum, ob der 1781EF+ ggf. den Durchsatz drosselt.

Das Dokument sagt doch eigentlich recht viel: https://www.lancom-systems.de/pdf/techp ... .12-DE.pdf
Wenn man jetzt natürlich anfängt, die 500 Mbit/s symmetrisch gleichzeitig nutzen zu wollen und ggf. noch mit entsprechend vielen oder gar zu vielen oder nicht optimal eingestellten Firewall-Regeln, oder mit sehr viel kleinen Paketen, dann landet man bei der Empfehlung von Koppelfeld mit der 1900-er Reihe.

Viele Grüße,
Jirka

[Dr.Einstein]

Hey MaRoediger,

Unabhängig vom vorher Geschriebenen, steht ja immer noch die Frage im Raum, ob der 1781EF+ ggf. den Durchsatz drosselt.
Der Cisco-Router der Deutschen Glasfaser hängt im Moment am WAN-Port (DSL-3).

die Frage lässt sich aufgrund vom Aufbau (VPN, Firewallregeln, Routing Tabelle etc) nur sehr grob vorhersagen. Aber ihr könnt das direkt selbst testen. Einfach einen normalen Download starten, der den Anschluss ans Maximum bringt (bzw den Router) und dann auf die CPU Auslastung schauen. Geht diese immer wieder >90%, habt ihr einen Engpass. Der Test funktioniert nur bei regulären Downloads. Würdest du kleinstmögliche Pakete schicken, wird nicht die CPU dicht machen, sondern die maximal möglichen Pakete/s des Routers.

500 Mbit/s sollten aber mMn drin sein, so du keinerlei VPN parallel verwendest. Heißt im Umkehrschluss aber, dass wenn beide Verbindungsrichtungen ansatzweise ausgereizt werden, du das maximal mögliche überschreiten wirst. Der Zustand wird vermutlich aber selten erreicht werden und sollte beobachtet werden (CPU Mitschnitt / SNMP / LanMonitor).

Gruß Dr.Einstein

[MaRoediger]

Hallo nochmal...

@ Koppelfeld (& Jirka):
Die Leitungsgröße wollte ich nur richtigstellen, damit nicht von falschen Voraussetzungen ausgegangen wird.
Außerdem dachte ich, daß es doch schon einen Unterschied macht, ob da maximal 500 oder 1.000 MBit/s bzw. 60 oder 120 MB/s durch die Leitung bzw. den Router gepeitscht werden.

Sorry, da hatte ich wohl doch noch eine Frage übersehen; ich dachte aber, die war schon beantwortet:
Beim DSL-3-Interface stehen für Down- und Upstream jeweils 500.000 kbit/s.
Müßte das nicht eigentlich 488.281 kbit/s heißen oder spielt das keine Rolle?

@ GrandDixence (und alle) nochmal speziell die Frage:
Sollte nun im hier vorliegenden Fall definitiv Hardware-NAT abgeschaltet werden, was ja auch Performance-Einbußen bedeutet?
Den verlinkten Artikel dazu habe ich gelesen, allerdings schrieb ja da alf29 auch, daß er von generellen Problemen bei gleichzeitigem Hardware-NAT und Portforwarding nichts wüßte?! Der Artikel ist nun auch schon ca. 3 Jahre alt und das OS wurde seitdem mehrfach aktualisiert. Deshalb hier nochmal konkret die Frage an die Experten.
Hardware-NAT war vorher immer eingeschaltet und das Portforwarding gab es ebenfalls, allerdings lief der Traffic bis zum Ende letzten Jahres noch über eine 40 MBit/s-Leitung von EWE-Tel.

@ Dr. Einstein:
Ich werde den von Dir vorgeschlagenen Download-Test mal durchführen und die CPU beobachten, wenn ich wieder zurück aus dem Urlaub bin.
Noch ein paar Ergänzungen zum Aufbau:
Es gibt 4 permanente VPN-Tunnel zu Filialen, über die allerdings nur überschaubar Traffic fließt.
Ferner gibt es noch ca. 25 VPN-Zugänge, die aber auch nur selten und kurzzeitig benutzt werden. Mehr als zwei VPN-Verbidnungen gleichzeitig sind im Grunde so gut wie nie vorhanden, auch hier ist der Traffic gering.
Ich gehe auch davon aus, daß für die normale Internetnutzung der Anschluß kaum voll ausgelastet wird; bisher ist man mit einem 40 MBit/s-SDSL-Anschluß ausgekommen, ohne daß mir nennenswerte Kritik zu Ohren gekommen wäre.
Ich werde trotzdem mal den über die Leitung fließenden Traffic und die CPU-Last über den Lan-Monitor (Graph) beobachten.

Beste Grüße

Mario

[Koppelfeld]

Moin !

Außerdem dachte ich, daß es doch schon einen Unterschied macht, ob da maximal 500 oder 1.000 MBit/s bzw. 60 oder 120 MB/s durch die Leitung bzw. den Router gepeitscht werden.

Da liegt ein Urproblem der Meß- und Regeltechnik vergraben. Damit eine Drosselung eingreifen kann, muß ein Sollwert überschritten worden sein. Das "Drosseln" führt aber zu einer abrupten Übertragungsstörung. Würde der Provider ab 500 MBit/s anfangen zu shapen, würdest Du in der Praxis maximal 350 MBit/s erreichen.
Das macht einen Exkurs notwendig:
Schon eine Dampflok zu "drosseln" ist eine Katastrophe, obwohl diese über einen Dampfregler verfügt.
"Shapen" tut man aber wohlweislich mit der Steuerung. Das "Abwürgen" mit einer Drossel sorgt für ein rapides Absinken des Wirkungsgrades. Genau so ist es beim Benzinmotor. Die Drosselklappe ist ein Relikt aus dem vorvorigen Jahrhundert. Schlau wäre es, komplett darauf zu verzichten und stattdessen die Einlaßventile hydraulisch zu steuern. Aber das wäre am Ende eine sinnvolle Investition.
Wie drosselt man elektrischen Strom ? Mit einem Vorwiderstand ? Ganz, ganz schlechte Idee. Da hatten schon unsere Großväter die Idee vom "Transduktor", im Prinzip ein Transformator mit einem hochpermeablen Kern, dessen Primärseite in Reihe mit der Last lag und dessen Sekundärseite mit geglättetem Gleichstrom in die magnetische Sättigung gefahren wurde. Dadurch wurde lediglich die rein ohmsche Last der (niederohmigen) Primärwicklung über dem Transduktor wirksam, entsprach einer Stellgröße von 100 %. Wenn man jetzt den Gleichstrom sukzessive wegnahm, wurde nach und nach der induktive Teil wirksam und die Leistungsabgabe wurde beinahe leistungslos begrenzt.
Als Schüler hätte ich so einen unglaublichen Scheiß wie "Peter und der Wolf" im Hagener "Stadttheater" ansehen müssen, die absolut idiotische Veranstaltung nutze ich für die Untersuchung der Bühnenbeleuchtungssteuerung - da waren Transduktoren verbaut. Für eine Scheinwerfergruppe mit vielleicht 2.000 W brauchte man ein "kompaktes" Stellgerät von vielleicht 20 Kg.
Was ich damit zum Ausdruck bringen will: "traffic shaping" ist eigentlich "traffic vandalism". Denn was macht ein Router, wenn er mehr Pakete hereinbekommt als er abgeben kann ? Klar, er kann in gewissem Rahmen, über eine sogenannte Warteschlange (in der Praxis sind es wg. QoS mehrere). Nur bekommt der Router dann irgendwann dicke Backen und explodiert. Irgendwann wird der Router Pakete auf den Boden fallen lassen müssen. Und dann muß die Sicherungsschicht korrigierend eingreifen. Das "iPerf" - Beispiel des wie immer kompetenten Beitrages von GrandDixense zeigt das sehr schön. Wenn aber erstmal eine Retransmission erforderlich ist, dann ist natürlich Schluß mit der Freude an unterbrechngsfreien, effizienten Downloads.
Bestes Beispiel: Läuft das Downloadkontingent eines LTE-Accounts ab, wird meistens auf 64KBit/s geshaped. Allerdings ist das Angucken einer Webeite sehr mühsam damit, während mit "echtem" ISDN ein flüssiger Seitenaufbau möglich ist.
Um seine Kunden nicht zu vergrätzen, muß ein Provider also eine ganze Ecke später mit dem Shaping beginnen als bei 500 MBit/s. Er läßt also erst einmal alles durch und stellt, typischerweise alle 15s,
sufenweise herab.
Daraus folgt: Der Lancom muß, wenn er an einer 500 MBit/s - Leitung nicht "steckenbleiben" will, zwischenzeitlich mindestens 800 MBit/s schaffen.


Daher: 1906 EF.

[Dr.Einstein]

Da liegt ein Urproblem der Meß- und Regeltechnik vergraben. Damit eine Drosselung eingreifen kann, muß ein Sollwert überschritten worden sein. Das "Drosseln" führt aber zu einer abrupten Übertragungsstörung. Würde der Provider ab 500 MBit/s anfangen zu shapen, würdest Du in der Praxis maximal 350 MBit/s erreichen.

Sorry Koppelfeld, sonst sind deine Beiträge ja sehr lesenswert, aber diesmal enthält dein Beitrag fast nur Blödsinn. Wenn ein Providercisco / Juniper auf 100 Mbit/s shapt, shapt er auf 100 Mbit/s, egal ob dahinter 250/500 oder 1000 Mbit/s liegen. Das Verfahren ist nahezu perfekt. TCP des Clients regelt dann selbstständig aufgrund des Paketverlustes, d.h. am Anfang wird sich langsam durch Verdoppelung an die 100 Mbit/s rangetastet, danach versucht der Client mehr als 100 zu ziehen, Paketverlust = Download bricht durch Paketverlust minimal unter 100 Mbit/s. Danach sorgt TCP dafür, dass der Download sich bei 100 Mbit/s einpendelt. Wenn man dann im Hintergrund den Shaper auf z.B. 200 Mbit/s erhöht, sieht man schön, wie lange der Download braucht, um auf die 200 Mbit/s hochzuwandern. UDP ist da halt anders. Das Protokoll zieht einfach das Maximum, was geht bzw eingestellt ist. Hier regelt wenn überhaupt die Anwendung. Das alles hat aber nichts mit dem Shaper zutun.

Bestes Beispiel: Läuft das Downloadkontingent eines LTE-Accounts ab, wird meistens auf 64KBit/s geshaped. Allerdings ist das Angucken einer Webeite sehr mühsam damit, während mit "echtem" ISDN ein flüssiger Seitenaufbau möglich ist.

Äpfel und Birnen zu vergleichen sieht dir nicht ähnlich. ISDN hat(te) 64kbit/s zu 64 kbit/s, gedrosselte Mobilfunkverbindungen (außer dieser O2 Tarif) haben 64 kbit/s zu 16 kbit/s.

Der EF+ sollte theoretisch für 500Mbit/s (beide Richtung addiert, Durchsatz) reichen. Wie gesagt, CPU Auslastung beobachten und nicht weiter rum spekulieren. Sollte nahe die Auslastung nahe 100% sein, im Lancom Router vor dem Schwellwert shapen und/oder neuen Router besorgen.

Gruß Dr.Einstein

[Koppelfeld]

Moin!

Wenn ein Providercisco / Juniper auf 100 Mbit/s shapt, shapt er auf 100 Mbit/s, egal ob dahinter 250/500 oder 1000 Mbit/s liegen. Das Verfahren ist nahezu perfekt.

Ich erlebe regelmäßig ein "Einschwingen". Man kann das schön bei 'scp' und 'wget' sehen.

TCP des Clients regelt dann selbstständig aufgrund des Paketverlustes,

Ja, vorausgesetzt, das Shaping hat sich stabilisiert.

Anstatt eines "Herantastens" sehe ich
- zunächst Downloadraten mit 1,5-facher Rate
- dann deutlichen Einbruch unter den zu shapenden Wert
- dann, etwa während der folgenden 30 Sekunden, eine konvergierende Stabilisierung auf die geshapte Rate.

Wenn Du eine große Datei mit 'split' in handliche Happen stückelst, dann transferierst Du die mit einem 'ftp:mget' deutlich schneller als wenn Du die Datei 'am Stück' überträgst.

Die von mir vorrangig genutzten Betriebssysteme sind allerdings AIX, OS/400 und Linux. Ob "Windows" mit einer anderen TCP-Window size anfängt oder wo auch sonst vielleicht ein Unterschied vorliegen mag.

Als typischen Internetanschluß nutzen unsere Kunden entweder die "klassischen" 155 MBit/s, typischerweise auf 100 MBit/s geshaped oder die "neueren" Telekom-Glasfaseranschlüsse, welche theoretisch 1 GBit/s könnten, aber meist auf 300, 500 oder 600 geshaped sind. Allerdings ist die CPE jetzt neuerdings von Huawei.

Das Protokoll zieht einfach das Maximum, was geht bzw eingestellt ist. Hier regelt wenn überhaupt die Anwendung. Das alles hat aber nichts mit dem Shaper zutun.

Wenn der Shaper "überrannt" wird, muß er entweder queuen oder wegwerfen. Wegwerfen ist teuer.

Bestes Beispiel: Läuft das Downloadkontingent eines LTE-Accounts ab, wird meistens auf 64KBit/s geshaped. Allerdings ist das Angucken einer Webeite sehr mühsam damit, während mit "echtem" ISDN ein flüssiger Seitenaufbau möglich ist.

Äpfel und Birnen zu vergleichen sieht dir nicht ähnlich. ISDN hat(te) 64kbit/s zu 64 kbit/s, gedrosselte Mobilfunkverbindungen (außer dieser O2 Tarif) haben 64 kbit/s zu 16 kbit/s.

Oh. Danke. Ich ging allerdings von symmetrischen 64 KBit/s aus.

Der EF+ sollte theoretisch für 500Mbit/s (beide Richtung addiert, Durchsatz) reichen. Wie gesagt, CPU Auslastung beobachten und nicht weiter rum spekulieren. Sollte nahe die Auslastung nahe 100% sein, im Lancom Router vor dem Schwellwert shapen und/oder neuen Router besorgen.

Das ist ohne Frage ein Spitzen-Router. Aber die gelisteten "Ethernet-Fehler" deuten auf Überlastspitzen hin.

Ein Kunde hatte bis vor kurzem einen 1781VA-4G im Einsatz, an einer 600er Telekom-Leitung. Etwa 1.200 gleichzeitige Verbindungen (Hotel), 1 VPN, sehr viel Telephonie über VCM. Versuche zu verschiedenen Tag- und Nachtzeiten ergaben 450 MBit/s.
Dann habe ich dort einen 7100+ hingestellt, mit gleicher Konfiguration.
Erreicht wurden 550 MBit/s.

Ja, ich weiß, die 7100+ haben nicht diesen unnötigen Switch und jedes Interface hat seinen eigenen Link.

Was ich aber sicher sagen kann: Der 1781VA-4G (mit der gleichen CPU wie der 1781EF) ist mit 600 MBit/s und vielen Verbindungen am Limit.

[alf29]

Was ich aber sicher sagen kann: Der 1781VA-4G (mit der gleichen CPU wie der 1781EF) ist mit 600 MBit/s und vielen Verbindungen am Limit.

Du meinst: "wie der 781EF+"? Im 1781EF ohne Plus steckt eine deutlich langsamere CPU.

Viele Grüße

Alfred

[Koppelfeld]

Hallo,

Was ich aber sicher sagen kann: Der 1781VA-4G (mit der gleichen CPU wie der 1781EF) ist mit 600 MBit/s und vielen Verbindungen am Limit.

Du meinst: "wie der 781EF+"? Im 1781EF ohne Plus steckt eine deutlich langsamere CPU.

Ja. Ein Super-Router seinerzeit, der EF+, der reichte sogar für die "große" Studi-WG mit 10 gleichzeitigen Torrents.

Aber die Zeiten ändern sich. Leider, denn die Produktivität wächst nicht mit dem Ressourcenangebot.

[GrandDixence]

Die von mir vorrangig genutzten Betriebssysteme sind allerdings AIX, OS/400 und Linux. Ob "Windows" mit einer anderen TCP-Window size anfängt oder wo auch sonst vielleicht ein Unterschied vorliegen mag.

Der Mechanismus zur Wahl des TCP Receive Window wird gemäss Wikipedia "TCP congestion control" genannt. Moderne Betriebssysteme erlauben die Wahl des "TCP congestion control"-Algorithmus:
https://en.wikipedia.org/wiki/TCP_congestion_control

Gerade bei LFN (long fat network) ist die händische Wahl eines für LFN optimierten "TCP congestion control"-Algorithmus häufig empfehlenswert. Klassisches Beispiel von LFN sind Internetanschlüsse über einen geostationären Satelliten (hohe RTT > 500 ms, kombiniert mit hoher Datenübertragungsrate).
https://de.wikipedia.org/wiki/Verz%C3%B ... en-Produkt

https://de.wikipedia.org/wiki/Geostatio ... r_Satellit

https://technet.microsoft.com/en-us/mag ... leguy.aspx

Wie die 4 Faktoren RTT/Latency, Paketverluste, TCP Receive Window und "Verlust der TCP-Paketreihenfolge" die Datenübertragungsrate einer TCP-Verbindung beeinflussen, ist unter:
https://fasterdata.es.net/network-tunin ... explained/

https://fasterdata.es.net/network-tunin ... cket-loss/

https://fasterdata.es.net/network-tunin ... -ordering/

beschrieben.

Praxistaugliche Tuning-Tips für TCP findet man unter:
https://fasterdata.es.net/host-tuning/

Ich persönlich verwende unter Linux folgendes TCP-Tunning in /etc/sysctl.conf:

Code: Alles auswählen

# TCP Window vergrössern auf
# 16 MegaByte TCP-Window Size (analog zu Windows Vista/7) 
net.ipv4.tcp_rmem = 4096 87380 33554432
net.ipv4.tcp_wmem = 4096 16384 33554432

# Unterstützung von TCP ECN deaktivieren
# Damit Hardwarebeschleunigung der Netzwerkkarte greift
net.ipv4.tcp_ecn = 0

Hinweis: Die von mir unter Linux verwendeten Netzwerkkarten unterstützen gemäss:

Code: Alles auswählen

# ethtool --show-offload eth0

Hardwarebeschleunigung (TCP Segmentation Offload => kurz TSO) für "tx-tcp-segmentation" aber keine Hardwarebeschleunigung (TSO) für "tx-tcp-ecn-segmentation".
https://de.wikipedia.org/wiki/TCP_segmentation_offload
https://de.wikipedia.org/wiki/TCP_Offload_Engine

[Stradtmann]

Guten Morgen zusammen,

ich habe mir für das Wochenende mal einen neuen Lancom Router 1906VA zugelegt, um mal zu gucken, ob es wirklich am 1781EF+ liegen sollte. Dies war jedoch nicht der Fall. Meine Up- und Downloadraten waren genau so "schlecht" wie mit dem alten Router. Somit kann ich ausschließen, dass es am alten Router liegt.

Ich habe mit dem neuen Router die Standardeinstellungen, die im Auslieferungszustand eingestellt sind, verwendet und dann ebenfalls noch mal mit der Konfig des alten Routers. Meine Werte lagen bei ca. 230-350MBps im Down- und ca. 260-400 im Upload.

Ohne Lancom Router, also direkt am Internetanschluss, lag ich im Downloadbereich bei 380-450MBps und im Upload bei 410-480MBps.

Was könnte die Verbindung also noch "drosseln"?

[Koppelfeld]

Was könnte die Verbindung also noch "drosseln"?

moin,

verdammt, verdammt, verdammt.

Ich war mir schon beinahe absolut sicher, der 1906 würde das Problem lösen.

Allerdings habe ich einen Beitrag von 'alf29' misinterpretiert.
Jeder schrieb, sinngemäß, daß alle Switchports an einem SerDes hängen und die WAN-Ports an einem anderen. Das bezog sich aber eindeutig NUR auf die ADSL - Ports.
Heißt konkret: Eine gewisse Designschwäche bei IPoE - Verbindungen teilen sich die 17xx- und die 19xx - Serie.

Also: MTU stimmt, DSL - "Bandbreite" ist richtig unter Schnittstellen / DSL eingetragen... Hmmm.

Bitte einmal folgendes probieren:

Gerät als einfachen LAN - Switch zwischen Provider-Router und Meßstelle setzen. Wird, im reinen Switchbetrieb, auch eine Verringerung der Transferrate feststellbar?
Unter Umständen auch einmal mit dem Flow-Control spielen, das auf Seiten des LANCOM verändert werden kann.
Alternativ: Einen guten Switch zwischen Provider-Endgerät und Lancom setzen.


Ansonsten bilde ich mir ja einiges auf meine Lateinkenntnisse ein, aber jetzt sind sie am Ende. Und es fängt an, interessant zu werden.

[Dr.Einstein]

Hey,

die DSL Rate ist überall auf 0 hinterlegt?

Code: Alles auswählen

root@:/Setup/Interfaces/DSL
> l

Ifc       Operating        Upstream-Rate  Ext.-Overhead  Downstream-Rate
==========--------------------------------------------------------------
DSL-1     Yes              0              0              0
DSL-2     No               0              0              0
DSL-3     No               0              0              0
DSL-4     No               0              0              0

Das Ethernet Interface für DSL-x ist sauber auf auto/auto konfiguriert?

Code: Alles auswählen

root@:/Setup/Interfaces/Ethernet-Ports
> l

Port       Assignment   Connector   MDI-Mode    Private-Mode        Downshift    Clock-Role         Power-Saving      Flow-Control
===========---------------------------------------------------------------------------------------------------------------------------
ETH-1      LAN-1        Auto        Auto        No                  Yes          Master-Preferred   No                Auto
ETH-2      LAN-1        Auto        Auto        No                  Yes          Master-Preferred   No                Auto
ETH-3      LAN-1        Auto        Auto        No                  Yes          Master-Preferred   No                Auto
ETH-4      DSL-1        Auto        Auto        No                  Yes          Master-Preferred   No                Auto

Zusätzlich mal testweise die Flow-Control für das Interface deaktivieren.

Gruß Dr.Einstein

[Stradtmann]

Hallo Dr.Einstein,

ja, die DSL Rate ist überall auf 0 eingestellt. Das Ethernet Interface für den DSL Anschluss ist auf AUTO/AUTO konfiguriert. Ich habe sogar testweise den Downshift auf 'Off' gestellt und das Flow-Control auch deaktiviert. Durch die Einstellungen konnte keine Verbesserung festgestellt werden. Heute hat der Anbieter Deutsche Glasfaser noch einen Leitungstest durchgeführt. Das Ergebnis wird mir am Montag mitgeteilt. Mal gucken, vielleicht liegt das Problem ja auch an der Leitung.

Danke erstmal und ein schönes Wochenende allen.