1711 mit ISDN-Geschwindigkeit (LCP polling timeout)
Moderator: Lancom-Systems Moderatoren
1711 mit ISDN-Geschwindigkeit (LCP polling timeout)
unser 1711 VPN lädt seit ca. 2 Tagen mit ca. 20kb/s. Ein Telekomiker hat heute das Modem ausgetauscht, da dies seit heute plötzlich keinerlei leuchtende LESDs mehr zeige (komischerweise war auch der NTBA solange tot, bis das neue Modem dran war). DSL läuft nun zwar wieder, aber immer noch mit o.g. Geschwindigkeit, obgleich wir TDSL business 2Mbit haben u dies seit mehreren Jahren ohne Probleme mit dem 1711 lief.
Ein trace zeigt alle 45 Sekunden folgende Meldung: "LCP polling timeout for peer T-DSLBIZ"
Kann jemand damit was anfangen bzw. erkennen, ob es sich um ein Telekom oder Problem des 1711 handelt (Kabel wurden durch uns überprüft).
Danke !
Ein trace zeigt alle 45 Sekunden folgende Meldung: "LCP polling timeout for peer T-DSLBIZ"
Kann jemand damit was anfangen bzw. erkennen, ob es sich um ein Telekom oder Problem des 1711 handelt (Kabel wurden durch uns überprüft).
Danke !
Hi peterpan
Du weisst aber, daß 20kb/s (ich verbute du meinst 20 kilobyte) ca. 160 kBit entsprechen - das dürfte der Upstream der Gegenseite sein. Oder hat die andere Seite tatsächlich 2MBit Upstream - so daß du deinen Downstream überhaupt nutzen könntest.
Gruß
Backslash
das sagt nur, daß das Poll-Intervall abgelaufen ist. danach kommt normalerweise "- echo-response received during last interval". Das ist völlig nocmal und kein Fehler...Ein trace zeigt alle 45 Sekunden folgende Meldung: "LCP polling timeout for peer T-DSLBIZ"
Du weisst aber, daß 20kb/s (ich verbute du meinst 20 kilobyte) ca. 160 kBit entsprechen - das dürfte der Upstream der Gegenseite sein. Oder hat die andere Seite tatsächlich 2MBit Upstream - so daß du deinen Downstream überhaupt nutzen könntest.
Gruß
Backslash
sorry, hatte mich etwas blöd ausgedrückt: ich meinte, dass der downstream bei 20 kilobyte/s liegt, obgleich (bei 2MBit Bandbreite) vorher Downstreams von 240 kilobyte/s normal waren.backslash hat geschrieben:Hi peterpan
das sagt nur, daß das Poll-Intervall abgelaufen ist. danach kommt normalerweise "- echo-response received during last interval". Das ist völlig nocmal und kein Fehler...Ein trace zeigt alle 45 Sekunden folgende Meldung: "LCP polling timeout for peer T-DSLBIZ"
Du weisst aber, daß 20kb/s (ich verbute du meinst 20 kilobyte) ca. 160 kBit entsprechen - das dürfte der Upstream der Gegenseite sein. Oder hat die andere Seite tatsächlich 2MBit Upstream - so daß du deinen Downstream überhaupt nutzen könntest.
Gruß
Backslash
tatsächlich erscheint im trace anschließend "- echo-response received during last interval". das ist also normal, ok.
heute abend ist mir noch folgendes eingefallen: ich hatte am wochenende zu hause (zum x-ten Mal) meinen Rechner (mit dem Advanced VPN) client neu installiert. Nach Eingabe der Seriennummer erschien ein Hinweis, dass ich zu oft die Seriennummer aktiviert hätte und ich irgeneine Hotlinenummer anrufen sollte (bin ich bislang nocht nicht zu gekommen).
Kann es sein, dass der nicht aktivierte VPN client beim Zugriff eine Art "Downstreamsperre" im Router setzt?
- tunichtgut
- Moderator
- Beiträge: 214
- Registriert: 19 Okt 2005, 10:21
Gibt es sonst irgend eine Lösung für die langsame Verbindung? Braucht Ihr hiefür irgendwelche Logauszüge? Falls ja: welche (und wie bekomme ich die jeweils)? Danke nochmals.tunichtgut hat geschrieben:Nein, das kann nicht sein.peterpan hat geschrieben: Kann es sein, dass der nicht aktivierte VPN client beim Zugriff eine Art "Downstreamsperre" im Router setzt?
Hi,
Backslash hat bereits versucht Dir zu erklaeren, das dieser langsame Durchsatz ja u.U. normal sein kann, wenn beide Seiten einen "normalen" asynchronen ADSL Anschluss benutzen. Beide Seiten haben dann einen langsameren Upstream als den Downstream. Also ist der Upstream auf beiden Seiten der begrenzende Faktor im VPN. Das es bei Downloads normal aus dem Internet dann schneller geht ist ja klar, da die Gegenstelle dort ggf. selbst schneller ist.
Also poste doch mal ueber welche ADSL Anschluesse die beiden GENAU verfuegen? Up- und Downstream?
Ciao
LoUiS
redest Du jetzt vom Traffic allgemein ueber WAN, oder nur ueber Traffic im VPN Tunnel?sorry, hatte mich etwas blöd ausgedrückt: ich meinte, dass der downstream bei 20 kilobyte/s liegt, obgleich (bei 2MBit Bandbreite) vorher Downstreams von 240 kilobyte/s normal waren.
Backslash hat bereits versucht Dir zu erklaeren, das dieser langsame Durchsatz ja u.U. normal sein kann, wenn beide Seiten einen "normalen" asynchronen ADSL Anschluss benutzen. Beide Seiten haben dann einen langsameren Upstream als den Downstream. Also ist der Upstream auf beiden Seiten der begrenzende Faktor im VPN. Das es bei Downloads normal aus dem Internet dann schneller geht ist ja klar, da die Gegenstelle dort ggf. selbst schneller ist.
Also poste doch mal ueber welche ADSL Anschluesse die beiden GENAU verfuegen? Up- und Downstream?
Ciao
LoUiS
Dr.House hat geschrieben:Dr. House: Du bist geheilt. Steh auf und wandle.
Patient: Sind Sie geisteskrank?
Dr. House: In der Bibel sagen die Leute schlicht "Ja, Herr" und verfallen dann ins Lobpreisen.
ich meinte schlicht die geschwindigkeit des downstreams über den wan. diese ist seit einigen tagen nur noch bei ca 10 %. über die geschwindigkeit im vpn-tunnel kann ich nichts sagen, da hier von extern jeweils nur über isdn verbunden wird.LoUiS hat geschrieben:Hi,
redest Du jetzt vom Traffic allgemein ueber WAN, oder nur ueber Traffic im VPN Tunnel?sorry, hatte mich etwas blöd ausgedrückt: ich meinte, dass der downstream bei 20 kilobyte/s liegt, obgleich (bei 2MBit Bandbreite) vorher Downstreams von 240 kilobyte/s normal waren.
Backslash hat bereits versucht Dir zu erklaeren, das dieser langsame Durchsatz ja u.U. normal sein kann, wenn beide Seiten einen "normalen" asynchronen ADSL Anschluss benutzen. Beide Seiten haben dann einen langsameren Upstream als den Downstream. Also ist der Upstream auf beiden Seiten der begrenzende Faktor im VPN. Das es bei Downloads normal aus dem Internet dann schneller geht ist ja klar, da die Gegenstelle dort ggf. selbst schneller ist.
Also poste doch mal ueber welche ADSL Anschluesse die beiden GENAU verfuegen? Up- und Downstream?
Ciao
LoUiS
also: welche infos braucht ihr zur fehleranalyse?
- tunichtgut
- Moderator
- Beiträge: 214
- Registriert: 19 Okt 2005, 10:21
Hallo Backslash, welche Probleme gibt es denn bei vorherigen Firmwareversionen mit QoS-Mindestbandbreiten?backslash hat geschrieben:Hi peterpan
du hast nicht zufällig Firewallregeln definiert, die globale Mindestbandbreiten reservieren? Falls ja, wende dich an den LANCOM-Support und laß dir eine aktuelle 6.26 schicken
Gruß
Backslash
Mir ist bei der 6.24 aufgefallen, dass in RX Richtung die "Erzwingung" der Bandbreite nicht greift. Die Reservierung wird hier nach der Agingdauer wieder freigegeben und bleibt nicht kontinuierlich aktiv. Im TX Bereich tritt das Problem nicht nicht.
12x 1621 Anx. B-21x 1711 VPN-3x 1722 Anx. B-7x 1723 VoIP-1x 1811 DSL, 1x 7011 VPN-1 x 7111 VPN-1x 8011 VPN-10er Pack Adv. VPN Client (2x V1.3-3x 2.0)-Hotspot Option-Adv. VoIP Client/P250 Handset-Adv.VoIP Option-4x VPN-Option-2x L-54 dual-2x L54ag-2x O-18a
i love telekom
diese spezialisten haben zunächst mehrfach (auch vor ort) geprüft und gesagt, der fehler läge nicht an ihnen, bis zu uns sei alles bestens. nun habe ich gestern abend die mitteilung bekommen, es sei doch ein fehler auf dem weg zu uns und dass wir nun auf einen anderen port in der vermittlungsstelle geschaltet würden. kurz und gut: sei heute läuft alles wieder. danke an die telekomiker für 4 tage fehlersuche bei uns
, obwohl der fehler bei denen lag.
danke trotzdem an alle hier für ihre hilfeversuche


danke trotzdem an alle hier für ihre hilfeversuche

Hi ittk
siehe auch: http://www.lancom-forum.de/ptopic,23404 ... html#23404
Ist hingegen das Häkchen gesetzt, dann findet eine echte Reservierung (wie in der Empfangsrichtung) statt, d.h. die Bandbreite ist für andere Anwendungen auch dann nicht vorhanden, wenn kein zu priorisiernder Traffic vorhanden ist. Auch hier wird eine Session abgelehnt, wenn nicht genügend Bandbreite vorhanden ist.
Eine Reservierung wird in jedem Fall nach Ablauf der Aging-Zeit zurückgenommen, wenn kein passender Traffic vothanden war.
Gruß
Backslash
wenn du globale Mindestbandbreiten reservierst, dann konnte es dazu kommen, daß irgendwann mal die Reservierung nicht zurückgenommen wurde, wodurch die Bandbreiten mehrfach reserviert wurden - bis alles verbraucht war...Hallo Backslash, welche Probleme gibt es denn bei vorherigen Firmwareversionen mit QoS-Mindestbandbreiten?
siehe auch: http://www.lancom-forum.de/ptopic,23404 ... html#23404
Das ist so korrekt. Die Bandbreite wird natürlich nur so lange reserviert, wie sie auch benötigt wird. "Erzwungen" heißt in Rx-Richtung "nur", daß eine Verbindung abgelehnt wird, wenn nicht genügend Bandbreite zur Verfügung steht - wird das Häkchen nicht gesetzt und mehr Bandbreite angefordert als verfügbar ist, dann müssen sich alle Beteilugten halt um die verfügbare Bandbreite "prügeln"...Mir ist bei der 6.24 aufgefallen, dass in RX Richtung die "Erzwingung" der Bandbreite nicht greift. Die Reservierung wird hier nach der Agingdauer wieder freigegeben und bleibt nicht kontinuierlich aktiv.
im TX-Bereich wird auch keine Bandbreite "reserviert" - zumindest solange das Häkchen bei "Erzwungen" nicht gesetzt ist. Betroffene Pakete werden nur bevorzugt übertragen. Das hat den Vorteil, daß die Bandbreite nur dann vergeben wird, wenn auch zu priorisierender Traffic vorhanden ist.Im TX Bereich tritt das Problem nicht nicht.
Ist hingegen das Häkchen gesetzt, dann findet eine echte Reservierung (wie in der Empfangsrichtung) statt, d.h. die Bandbreite ist für andere Anwendungen auch dann nicht vorhanden, wenn kein zu priorisiernder Traffic vorhanden ist. Auch hier wird eine Session abgelehnt, wenn nicht genügend Bandbreite vorhanden ist.
Eine Reservierung wird in jedem Fall nach Ablauf der Aging-Zeit zurückgenommen, wenn kein passender Traffic vothanden war.
Gruß
Backslash