Hallo,
Vieleicht ist es ja schon bekannt. Trotzdem nochmal die Info, damit sich nicht alle so tot suchen wie ich es tun musste, nach einem nicht auffindbaren Fehler
Wir setzen bei einigen Kunden zwei DSL Leitungen ein (ohne Loadbalancing). Also zwei Produktive DSL leitungen, keine brach liegende backup leitung. Bisher lief das soweit auch. In letzter zeit gab es aber massive Verbindungsprobleme der DSL Verbindungen. Eine der beiden DSL Verbindungen brach immer wieder ab. Meistens immer die gleiche aber auch unterschiedlich, also mal die eine und mal die andere.
Die verbindung wurde aufgebaut, dann ein paar Minuten gehalten und wieder abgebrochen. meistens durch ein LCP polling time out. Nach einiger erfolgloser fehlersuche hatte ich nun einen Supporter bei Lancom drann der wohl schon bescheit wusste und gleich sagte, dass es ein bekannter Bug in der 8.50 Firmware sei an dem sie schon fieberhaft arbeiten.
Ich würde sagen, der Bug hats in sich. Gerade die Möglichkeit 2 DSLs laufen zu lassen brauchen doch fast alle Kunden
Fakt ist, bei Firmware 8.50 soll man bei Problemen nur eine DSL laufen lassen. So jedenfalls der Lancom Support
Hatte jemand das gleiche problem oder kann auch über diesen "bekannten" Bug was sagen?
Lg Henry
Firmware DSL Bug 8.50...
Moderator: Lancom-Systems Moderatoren
-
Dr.Einstein
- Beiträge: 3253
- Registriert: 12 Jan 2010, 14:10
Also ich habe bei drei 1781A genau das selbe Problem mit LCP Errors, bei einem ist es sicher die Leitung. Die anderen Beiden bereiten mir aktuell Sorgen. Jeweils 4 DSL Anschlüsse drauf, und alle wechselseitig Probleme, oder zwei Paarweise. Deaktiviert man einen von vier, funktioniert alles super, Argus Prüfmodem keine physikalischen Fehler feststellbar. Zusätzlich aus Spaß mal Linepolling mit 5 Sekunden eingestellt, und zack, fliegen die Leitungen nach 2-10 Minuten wegen ICMP Fehler raus.
Als Gegenargument muss ich aber dazu sagen, dass wir diverse 1821n im Einsatz haben mit 4 Leitungen, keinerlei Probleme. Wenn das ein Softwarefehler wäre, bekomm ich die Krise. Mehrfach Lancom Support angefragt, mehrfach auf Leitung geschoben ...
Als Gegenargument muss ich aber dazu sagen, dass wir diverse 1821n im Einsatz haben mit 4 Leitungen, keinerlei Probleme. Wenn das ein Softwarefehler wäre, bekomm ich die Krise. Mehrfach Lancom Support angefragt, mehrfach auf Leitung geschoben ...
Hi,
ja ich hatte auch mehrfach den lancom Support dran und das mit dem Software Bug hat mir erst der letzte gesagt. Der wusste aber auch wirklich sofort bescheit als er die dauernden LCP Abbrüche gesehen hat.
Er meinte das Lancom der Bug bekannt ist und sie aktuelle daran arbeiten den in den Griff zu bekommen. Er hat mich in die verteilerliste genommen und schickt dann eine Rundmail wenn es behoben ist.
Wäre aber vieleicht gut, wenn diejenigen die ein änliches Problem haben das dort auch vortragen, denn je mehr umso schneller wird es behoben sein denke ich.
Das deine diversen 1821n keine Probleme machen hat nicht so viel zu sagen, denn ich habe auch einige 1721 ohne Probleme im Einsatz. Lancom Support meinte nach nachfrage das es jedes gerät mit der 8.50 betreffen könnte!! aber wohl nicht muss. Die meisten Probleme hatte ich mit dem 1781, aber auch dort kommt es zu merkwürdigen beobachtungen wie zb das ein VDSL und ein ADSL zusammen bei einem Kunden funktioniert, aber wenn ich zwei ADSL laufen lasse bricht wieder alles zusammen. Kein Plan woran das genau liegt aber es ist ein Software Problem seitens Lancoms und kein Leitungsproblem
Die Leitung würde ich in den meisten Fällen ausschliessen. Hatte ich auch erst in Verdacht natürlich, abedr sobald ich einen billig Router dran hänge oder nur eine DSL auf dem Lancom laufen lasse Läuft alles Fehlerfrei.
Ich finde diesen Bug ziemlich heftig und hoffe der ist schnell behoben, denn dadurch können und sind massive Probleme bei Kunden entstanden, welche mich und den Kunden reichlich Zeit und Nerven gekostet hat
Lg Henry
ja ich hatte auch mehrfach den lancom Support dran und das mit dem Software Bug hat mir erst der letzte gesagt. Der wusste aber auch wirklich sofort bescheit als er die dauernden LCP Abbrüche gesehen hat.
Er meinte das Lancom der Bug bekannt ist und sie aktuelle daran arbeiten den in den Griff zu bekommen. Er hat mich in die verteilerliste genommen und schickt dann eine Rundmail wenn es behoben ist.
Wäre aber vieleicht gut, wenn diejenigen die ein änliches Problem haben das dort auch vortragen, denn je mehr umso schneller wird es behoben sein denke ich.
Das deine diversen 1821n keine Probleme machen hat nicht so viel zu sagen, denn ich habe auch einige 1721 ohne Probleme im Einsatz. Lancom Support meinte nach nachfrage das es jedes gerät mit der 8.50 betreffen könnte!! aber wohl nicht muss. Die meisten Probleme hatte ich mit dem 1781, aber auch dort kommt es zu merkwürdigen beobachtungen wie zb das ein VDSL und ein ADSL zusammen bei einem Kunden funktioniert, aber wenn ich zwei ADSL laufen lasse bricht wieder alles zusammen. Kein Plan woran das genau liegt aber es ist ein Software Problem seitens Lancoms und kein Leitungsproblem
Die Leitung würde ich in den meisten Fällen ausschliessen. Hatte ich auch erst in Verdacht natürlich, abedr sobald ich einen billig Router dran hänge oder nur eine DSL auf dem Lancom laufen lasse Läuft alles Fehlerfrei.
Ich finde diesen Bug ziemlich heftig und hoffe der ist schnell behoben, denn dadurch können und sind massive Probleme bei Kunden entstanden, welche mich und den Kunden reichlich Zeit und Nerven gekostet hat
Lg Henry
-
Dr.Einstein
- Beiträge: 3253
- Registriert: 12 Jan 2010, 14:10
Aktueller Status bei mir:
Vier weitere Kunden mit dem Loadbalancing Problem, mal bei 2 Leitungen, mal erst bei 4 Leitungen.
Neu hinzugekommen ist ein Kunde, wo selbst nur ein einziger DSL Anschluss Probleme gebracht hat mit einem externen Modem. Heißt für mich, SDSL Anschlüsse mit Einwahlkennung sind mit der neuen Lancom-Produktserie erst einmal tabu ...
Entwicklung beschäftigt sich wohl aktuell mit dem Problem.
Gruß Dr.Einstein
Vier weitere Kunden mit dem Loadbalancing Problem, mal bei 2 Leitungen, mal erst bei 4 Leitungen.
Neu hinzugekommen ist ein Kunde, wo selbst nur ein einziger DSL Anschluss Probleme gebracht hat mit einem externen Modem. Heißt für mich, SDSL Anschlüsse mit Einwahlkennung sind mit der neuen Lancom-Produktserie erst einmal tabu ...
Entwicklung beschäftigt sich wohl aktuell mit dem Problem.
Gruß Dr.Einstein
Hallo zusammen,
wir waren auch von diesem Problem betroffen. Seit Dienstag Abend 23:00 Uhr läuft die Entwicklerversion Testweise bei einem der Kunden Router.
Zur Info: 1781a.
2x DSL.
1x CompanyConnect.
Sobald die beiden DSL zum Loadbalance zusammengeschaltet wurden wurden die Anschlüsse nur wechselseitig benutzt.
Mit der neuen Version ALPHA läuft soweit alles stabil. Ebenso die VPN Verbindungen innerhalb eines Verbundes.
Gruß.
wir waren auch von diesem Problem betroffen. Seit Dienstag Abend 23:00 Uhr läuft die Entwicklerversion Testweise bei einem der Kunden Router.
Zur Info: 1781a.
2x DSL.
1x CompanyConnect.
Sobald die beiden DSL zum Loadbalance zusammengeschaltet wurden wurden die Anschlüsse nur wechselseitig benutzt.
Mit der neuen Version ALPHA läuft soweit alles stabil. Ebenso die VPN Verbindungen innerhalb eines Verbundes.
Gruß.
Zuletzt geändert von smove99 am 25 Nov 2011, 09:44, insgesamt 1-mal geändert.
Hallo zusammen,
auch ich sitze gerade beim Kunden und habe Probleme, sobald ich Loadbalancing benutzen möchte. (1781A)
Mit einem 16000er Anschluß direkt am Lancom läuft das Gerät spitze, sobald ich nur das Modem (Leitung2) an ETH1/WAN anschließe, bricht alles auf 2 % Leistung zusammen. Webseiten öffnen nur noch nach Minuten.
Auch das entfernen der https Bindung auf eine Leitung etc half nicht.
Ich habe dies bereits weitergegeben und hoffe auf eine Lösung unserer IT, die in enger Zusammenarbeit mit Lancom arbeitet.
Selbst probiert habe ich schon:
- Wan Port auf 100 Auto herunterzustellen.
- internes ADSL zu ziehen, selbes Phänomen, alles wird total langsam, selbst
die Einwahl auf Leitung 2 bekommt der Lancom nur noch nach Minuten
gebacken.
Wenn ich neues weiß, meld ich mich
Gruß
Genom
auch ich sitze gerade beim Kunden und habe Probleme, sobald ich Loadbalancing benutzen möchte. (1781A)
Mit einem 16000er Anschluß direkt am Lancom läuft das Gerät spitze, sobald ich nur das Modem (Leitung2) an ETH1/WAN anschließe, bricht alles auf 2 % Leistung zusammen. Webseiten öffnen nur noch nach Minuten.
Auch das entfernen der https Bindung auf eine Leitung etc half nicht.
Ich habe dies bereits weitergegeben und hoffe auf eine Lösung unserer IT, die in enger Zusammenarbeit mit Lancom arbeitet.
Selbst probiert habe ich schon:
- Wan Port auf 100 Auto herunterzustellen.
- internes ADSL zu ziehen, selbes Phänomen, alles wird total langsam, selbst
die Einwahl auf Leitung 2 bekommt der Lancom nur noch nach Minuten
gebacken.
Wenn ich neues weiß, meld ich mich
Gruß
Genom
Soo, nach einem langen Tag gibt es folgendes zu berichten:
Lancom und mein IT Haus haben mir die Info gegeben, dass es erst in einigen Wochen ein Update geben wird, mit dem dieses Problem behoben wird.
Solange ist in dieser Konstellation kein Loadbalancing möglich:
Lancom 1781A
DSL1: internes Modem
DSL2: ETH1 als WAN mit externen Modem
Fehlerbild: Nach stecken von DSL2 wird Internet langsam (super langsam)
Seltsamerweise passiert das sofort nach anstecken, selbst wenn noch keine Verbindung aufgebaut ist über DSL2 (PPPoE Fehler dank Radius)
Auch die Einwahl dauert an sich sehr lange.
Mir kam es so vor, als wäre es ein Problem mit den Schnittstellen, vielleicht Layer1, dass das Modem den 1000 Mbit Port durcheinanderbringt, wenn er als WAN konfiguriert ist ?
Sofort! nach ziehen von DSL2 ist die volle Geschwindigkeit wieder da
Sehr strange auf jeden Fall
Gruß
Genom
Lancom und mein IT Haus haben mir die Info gegeben, dass es erst in einigen Wochen ein Update geben wird, mit dem dieses Problem behoben wird.
Solange ist in dieser Konstellation kein Loadbalancing möglich:
Lancom 1781A
DSL1: internes Modem
DSL2: ETH1 als WAN mit externen Modem
Fehlerbild: Nach stecken von DSL2 wird Internet langsam (super langsam)
Seltsamerweise passiert das sofort nach anstecken, selbst wenn noch keine Verbindung aufgebaut ist über DSL2 (PPPoE Fehler dank Radius)
Auch die Einwahl dauert an sich sehr lange.
Mir kam es so vor, als wäre es ein Problem mit den Schnittstellen, vielleicht Layer1, dass das Modem den 1000 Mbit Port durcheinanderbringt, wenn er als WAN konfiguriert ist ?
Sofort! nach ziehen von DSL2 ist die volle Geschwindigkeit wieder da
Sehr strange auf jeden Fall
Gruß
Genom
Moin,
für Leute, die es genau wissen wollen: im 1781 steckt wie auch früher in der 1711/1721 ein
Ethernet-Switch-Baustein, und alles was PPPoE ist, geht über den Switch - auch der Traffic, der
übers interne Modem geht, das Modem hängt an einem der Ports dieses Switch-Bausteins.
Bei Multilink-PPP(oE) zu einem Provider baut man zwei Verbindungen zum gleichen AC und damit
zur gleichen MAC-Adresse auf - und da liegt der Knackpunkt: ein Ethernet-Switch 'lernt'
normalerweise, Pakete für eine bestimmte MAC-Adresse nur zu *einem* Port zu lenken, bei
so einer Multilink-PPP(oE)-Verbindung muß das LCOS diese Adreßtabelle im Switch übersteuern
und dem Switch explizit sagen, welches Paket auf welchem Port rausmuß - und das hat bei
dem neuen Gigabit-Switch in den 1781-Geräten (noch) nicht funktioniert. Alle Pakete für beide
Verbindungen sid immer auf der einen oder anderen Strecke zum AC gelandet, je nachdem von
wo das letzte Paket vom AC hereingekommen ist, und damit funktioniert natürlich keine der
beiden Verbindungen mehr richtig...
Ich hoffe, das ist jetzt eine zufriedenstellende Erklärung. Wann genau das nächste RU kommt,
kann ich nicht beantworten.
Gruß Alfred
für Leute, die es genau wissen wollen: im 1781 steckt wie auch früher in der 1711/1721 ein
Ethernet-Switch-Baustein, und alles was PPPoE ist, geht über den Switch - auch der Traffic, der
übers interne Modem geht, das Modem hängt an einem der Ports dieses Switch-Bausteins.
Bei Multilink-PPP(oE) zu einem Provider baut man zwei Verbindungen zum gleichen AC und damit
zur gleichen MAC-Adresse auf - und da liegt der Knackpunkt: ein Ethernet-Switch 'lernt'
normalerweise, Pakete für eine bestimmte MAC-Adresse nur zu *einem* Port zu lenken, bei
so einer Multilink-PPP(oE)-Verbindung muß das LCOS diese Adreßtabelle im Switch übersteuern
und dem Switch explizit sagen, welches Paket auf welchem Port rausmuß - und das hat bei
dem neuen Gigabit-Switch in den 1781-Geräten (noch) nicht funktioniert. Alle Pakete für beide
Verbindungen sid immer auf der einen oder anderen Strecke zum AC gelandet, je nachdem von
wo das letzte Paket vom AC hereingekommen ist, und damit funktioniert natürlich keine der
beiden Verbindungen mehr richtig...
Ich hoffe, das ist jetzt eine zufriedenstellende Erklärung. Wann genau das nächste RU kommt,
kann ich nicht beantworten.
Gruß Alfred
@alf29
Die Lösung klingt erst mal logisch.
Ich verstehe aber nicht, wieso alles langsam wird, nachdem das DSL Modem gesteckt wurde und noch keine Einwahl vorgenommen wurde. Somit wurde ja noch kein 2ter Kontakt zum AC aufgenommen.
Oder stimmt die Zuordnung der "DSL Ports" nicht und sobald ein 2ter WAN Link oben ist, werden Pakete zwischen den Modems (intern + extern) verteilt, obwohl der Stream über ein Modem laufen müsste ?
Gruß
Die Lösung klingt erst mal logisch.
Ich verstehe aber nicht, wieso alles langsam wird, nachdem das DSL Modem gesteckt wurde und noch keine Einwahl vorgenommen wurde. Somit wurde ja noch kein 2ter Kontakt zum AC aufgenommen.
Oder stimmt die Zuordnung der "DSL Ports" nicht und sobald ein 2ter WAN Link oben ist, werden Pakete zwischen den Modems (intern + extern) verteilt, obwohl der Stream über ein Modem laufen müsste ?
Gruß
Ich muss sagen dieser Bug hat einige unserer Kunden und mich richtig in Not gebracht. ich weiss auch noch nicht ob und wie diese ausgibiege Fehlersuche und testerei einem Kunden in Rechnung stellen soll bzw kann.
Da sind locker ein paar Tage für drauf gegangen bis endlich der Hinweis auf diesen Bug kam.
@alf29
Danke für die Erklärung. Finde es wichtig auch zu wissen woran es liegt.
Lg Henry
Da sind locker ein paar Tage für drauf gegangen bis endlich der Hinweis auf diesen Bug kam.
@alf29
Danke für die Erklärung. Finde es wichtig auch zu wissen woran es liegt.
Lg Henry
Moin,
netzwerktechnisch eine Bridge, d.h. alle Pakete werden einfach anhand von MAC-Adressen
weitergereicht. Das bedeutet üblicherweise auch, daß Broad- und Multicasts auf alle Ports
weitergeflutet werden, z.B. auch vom AC *ausgehende* Broad- und Multicasts - die sieht der
Switch im LANCOM dann auf allen Ports einer Multilinklink-Verbindung hereinkommen und kommt
mit seinen Adreßtabellen durcheinander. Eine PPPoE-Verbindung muß dafür noch gar nicht
aufgebaut sein.
Dinge zusammenkommen mußten: Multilink-PPPoE, was nur ein kleiner Prozentsatz der Kunden
verwendet, ein relativ neues Gerät der 1781-Serie, was noch nicht so verbreitet ist gegenüber
den älteren 1711/1721/1811/1821-Geräten, und ein providerseitiger Setup, wo die beiden Links
auf einem AC aufschlagen, der für alle PPPoE-Verbindungen die gleiche MAC-Adresse
verwendet. Ich bin relativ sicher, daß Multilink-PPPoE bei uns vorher in der QS auf diesen
Geräten getestet worden ist, aber wenn wir dummerweise einen Provider hatten, der das nicht
so macht, dann ist das Problem bei uns nicht aufgefallen...
Gruß Alfred
So eine xDSL-Strecke mit DSLAM auf der einen und Modem auf der anderen Seite ist üblicherweiseIch verstehe aber nicht, wieso alles langsam wird, nachdem das DSL Modem gesteckt wurde und noch keine Einwahl vorgenommen wurde. Somit wurde ja noch kein 2ter Kontakt zum AC aufgenommen.
netzwerktechnisch eine Bridge, d.h. alle Pakete werden einfach anhand von MAC-Adressen
weitergereicht. Das bedeutet üblicherweise auch, daß Broad- und Multicasts auf alle Ports
weitergeflutet werden, z.B. auch vom AC *ausgehende* Broad- und Multicasts - die sieht der
Switch im LANCOM dann auf allen Ports einer Multilinklink-Verbindung hereinkommen und kommt
mit seinen Adreßtabellen durcheinander. Eine PPPoE-Verbindung muß dafür noch gar nicht
aufgebaut sein.
Das tut mir leid, aber so etwas läßt sich nicht immer verhindern, zumal für diesen Fehler einigeIch muss sagen dieser Bug hat einige unserer Kunden und mich richtig in Not gebracht. ich weiss auch noch nicht ob und wie diese ausgibiege Fehlersuche und testerei einem Kunden in Rechnung stellen soll bzw kann.
Da sind locker ein paar Tage für drauf gegangen bis endlich der Hinweis auf diesen Bug kam.
Dinge zusammenkommen mußten: Multilink-PPPoE, was nur ein kleiner Prozentsatz der Kunden
verwendet, ein relativ neues Gerät der 1781-Serie, was noch nicht so verbreitet ist gegenüber
den älteren 1711/1721/1811/1821-Geräten, und ein providerseitiger Setup, wo die beiden Links
auf einem AC aufschlagen, der für alle PPPoE-Verbindungen die gleiche MAC-Adresse
verwendet. Ich bin relativ sicher, daß Multilink-PPPoE bei uns vorher in der QS auf diesen
Geräten getestet worden ist, aber wenn wir dummerweise einen Provider hatten, der das nicht
so macht, dann ist das Problem bei uns nicht aufgefallen...
Gruß Alfred
“There is no death, there is just a change of our cosmic address."
-- Edgar Froese, 1944 - 2015
-- Edgar Froese, 1944 - 2015
Hallo Alfred,
ich verstehe das sowas passieren kann.
Ich kann aber nicht von einem kleinen Prozentsatz sprechen, denn bei uns nutzen mindestens 50 % der Kunden im KMU Bereich zwei DSL leitungen und davon geht sicher ein grosser Teil per Multilink PPOE zum Provider wie Telekom der anscheinend nur eine MAC Adresse verwendet für beide DSL Leitungen.
Die LCOS 8.6 Release Candidate 1 ist ja jetzt gerade draussen. Wurde da schon etwas bezüglich des problems geändert oder noch nicht?
Lg Henryy
ich verstehe das sowas passieren kann.
Ich kann aber nicht von einem kleinen Prozentsatz sprechen, denn bei uns nutzen mindestens 50 % der Kunden im KMU Bereich zwei DSL leitungen und davon geht sicher ein grosser Teil per Multilink PPOE zum Provider wie Telekom der anscheinend nur eine MAC Adresse verwendet für beide DSL Leitungen.
Die LCOS 8.6 Release Candidate 1 ist ja jetzt gerade draussen. Wurde da schon etwas bezüglich des problems geändert oder noch nicht?
Lg Henryy