LANCOM als VDSL-Modem

[ecox]

Servus,

ohne hier auf weitere Details einzugehen. Hält man sich strickt an die Anleitung von LANCOM

https://www2.lancom.de/kb.nsf/bf0ed2a4d ... enDocument

Bei wem funktioniert das Sauber?

Bei mir gegeben ein 1783VA als Modem und ein 9100+ als Gateway...

Die Connection baut schnell auf und alles sieht gut aus. Pings vom Gateway Richtung WAN, kein Thema.
Rufe ich aus dem LAN einen Internetseite auf, bricht die Internetverbindung sofort zusammen.
Im Log sind unter anderem auch noch zu sehen "LCP error"...als ob das Linepolling nicht korrekt läuft oder keine Antworten zurücl gehen...
Ich könnte hier jetzt zich Sachen posten die ich dokumentiert habe....

Möchte aber nur mal wissen, bei wem das Sauber läuft, ohne Probleme und so wie mit der Anleitung von LANCOM.

Warum die Connection zusammen bricht sowie eine DNS Anfrage aus dem Browser kommt, erschließt sich mir nicht...

Grüße
ecox

P.S.: leider nicht so ausführlich heute, habe kaum Zeit

[ecox]

Sehr geehrte Damen und Herren,

ich habe jetzt mal anstatt des LANCOM Modems, ein Zyxell-Modem hingehängt und siehe da, hat Link und lacht!
Einwähl klappt.
Also entweder es stimmt generell noch was nicht oder ich habs einfach 1000x falsch eingerichtet. Ich habe auch abseits der Anleitung viel probiert, keine Chance.
Einwahl klappt noch, ein paar pings gehen durch und wenn ich dann den Browser öffne und die ersten Anfragen ins Netz raus gehen (DNS, HTTPS usw usw) bricht die Leitung zusammen.

Fehler die man sieht sind:
PPP Trace: Es kommt eine Meldung vom AC zurück das Frames verworfen werden, kurz darauf kommt der LCP Timeout...
Werden hier MAC-Adressen doppelt progagiert oder ähnliches?

Bitte mal Meldung, denn so kann man das dem Kunden nicht verkaufen, beta hin oder her...

Grüße
ecox

[LoUiS]

Hi,

Dir ist schon klar, dass Dir hier niemand antwortet, sofern dieses Feature von noch keinem anderen User ausprobiert wurde.
Aber ich denke LANCOM freut sich bestimmt ueber Dein Feedback zum LCOS 10.20 RC1, ueber den normalen Weg des RC Feedback.


Ciao
LoUiS

[ecox]

Servus,

Dir ist schon klar, dass Dir hier niemand antwortet, sofern dieses Feature von noch keinem anderen User ausprobiert wurde.

Thanks god, das du hier mal die Mentalität beschreibst die man von einigen internals erwarten kann, danke dafür...
Ich hoffe bei solchen Posts auf Antworten aus den 1. Reihen, die ja auch kam, leider absolut nicht zufriedenstellend

Aber ich denke LANCOM freut sich bestimmt ueber Dein Feedback zum LCOS 10.20 RC1, ueber den normalen Weg des RC Feedback.

Erledigt, hoffe auf baldige Antwort...

Grüße
ecox

[MoinMoin]

Moin ecox!

Hast du noch irgendwelche Dienste auf dem "Modem" laufen (DHCP etc.)? Noch irgendwelche Default-Internetzügänge z.B. für die LMC?

Ciao, Georg

[ecox]

Hallo MoinMoin,

DHCP habe ich gemäß der Anleitung ausgestellt, mehr nicht...wäre es denn theoretisch denkbar das Default-Sachen die ganze Geschicht beeinflussen, falls ja, sollte all das mit dem Haken "Bridge-Mode" tot gemacht werden. Die Kunden erwarten hier ein Modem das im Idealfall keine Konfiguration benötigt bis auf den Schalter auf "Bridge" zu stellen.

Ich kann morgen gerne noch ein Mal prüfen was passiert wenn ich Dienste wie DNS, DHCP, LMC gänzlich abschalte...

Grüße
ecox

[MoinMoin]

Moin ecox!

Der Haken "bridge mode" schaltet nur das Modem vom WAN-Interface auf das Bridge-Interface. Wenn du irgendwelche Dienste an die Bridge bindest, geht das auch über das Modem. Wenn du dem LAN eine IP-Adresse gibst, kannst du das LANCOM darüber erreichen - vermutlich auch über VDSL. Von daher würde ich es vorziehen, überhaupt kein IP-Netz, sei es Intranet oder DMZ, mit auf der Bridge zu haben.

Normalerweise würde ich erwarten, daß nach einem Konfigurationsreset alle Dienste bis auf DHCP aus sind. Bei der LMC bin ich mir da aber nicht so sicher. Da läuft meines Wissens irgend eine Suche nach dem Cloud-Server, die aber nicht über die Bridge gehen sollte. Aber man weiß ja nie.

Wie du richtig bemerkt hast, es ist noch eine Beta. Das gilt auch für die Anleitung. Fehler oder Unklarheiten sind durchaus möglich, aber keineswegs beabsichtigt.

Ciao, Georg

[ecox]

Hey,

die Logik mit den Diensten die an die Bridge gebunden sind, kann ich folgen, aber im Default ist wenn, alles auf BRG-1 gebridged ...ich habe hier ja extra LAN-1 und xDSL-1 auf BRG-2 gemacht, somit dürften doch die Dienste da nicht ankommen da der Rest ja auf BRG-1 steht, oder sollte man vllt. noch einstellen das der Port nicht mit den anderen kommunzieren darf, ich weiß es nicht, das mit dem IP-Netz könnte ja in der tat vllt auch in die Hose gehen, ich habe dort mit default ip und eingerichteter IP ja trotzdem das Netz auf LAN-1 was ich ja zu BRG-2 mit dem Modem interface gemacht habe, vllt. ist das schon das Problem, einfach mal das Intranet auf LAN-3 stellen, alles Vermutungen.

ich teste es heute auf Arbeit und gebe Rückmeldung.

Grüße
ecox

[ecox]

Servus,

so...alles noch ein Mal auf Anfang (beide Geräte sind vor Beginn nackig gemacht worden)
1x 1783VA-4G
1x 9100+

1783
-LAN-4 & xDSL-1 auf BRG-2
-xDSL Modus auf Bridge (LLC-Mux mit 1/32)
-DHCP gänzlich abgeschaltet (auch in der DHCP Port Tabelle)
-DNS gänzlich deaktiviert
-Sämtliche Default-Dinge gelöscht die was mit WAN zu tun haben
-Und alles abgeschaltet was auch nur irgendwie was auf LAN-4 raus hauen könnte

9100+
-Per Wizard PPPoE Verbindung eingerichtet
-Router geht sofort online, ein paar Pings von CLI und LAN erreich das WWW
-Nach kurzer Zeit, zusammenbruch der Verbindung mit ziemlich zeitnahen folgen der Meldung "LCP Timeout during intervall" <- auch mit LCP etc habe ich schon alles möglich ausprobiert

Trace:
Im 1783 sehe ich im VDSL und Bridge-Trace das alles korrekt laufen müsste, alles kennt seinen Weg und weiß zu wem was gehört. Im Bridge Trace sehe ich direkt das ein Frame von LAN-4 auf xDSL-1 gemapped wird (HTTP, Telnet, Proxy, LCP, solche Protokolle sehe ich im Trace)

Im 9100 sehe ich im PPP Trace halt das die Verbindung zusammenbricht, keine LCP echos mehr etc...

Also ich weiß jetzt echt nicht mehr weiter, ich habe glaube alle Kombinationen ausprobiert die man probieren kann...

Konntet ihr es schon nachstellen im Labor?

Grüße
ecox

[Koppelfeld]

Wie du richtig bemerkt hast, es ist noch eine Beta. Das gilt auch für die Anleitung. Fehler oder Unklarheiten sind durchaus möglich, aber keineswegs beabsichtigt.

MTU falsch ?

[ecox]

Wie du richtig bemerkt hast, es ist noch eine Beta. Das gilt auch für die Anleitung. Fehler oder Unklarheiten sind durchaus möglich, aber keineswegs beabsichtigt.

MTU falsch ?

Hallo Koppelfeld,
auch mit der MTU habe ich gespielt, auch mit externen Overhead und so weiter. In der PPP Aushandlung sehe ich das sich auf MTU 1492 geeinigt wird. Ich habe mal mit 1452 probiert, aber gleiches Verhalten. Gibt es einen Wert den du empfehlen oder ableiten könntest @Koppelfeld?

EDIT: Habe nochmal mit den MTU Sizes gespielt, keine Änderung. Leitung kommt zwar hoch und frisst jede menge Pings aus dem LAN und von CLI aber sowie ich www.google.de in den Browser eingebe und Entere, ist es vorbei, Leitung bricht zusammen...

Grüße
ecox

[MoinMoin]

Moin ecox!

Hast du beim 9100 die DSL-Datenraten passend konfiguriert?

Ciao, Georg

[ecox]

Moin ecox!
Hast du beim 9100 die DSL-Datenraten passend konfiguriert?

Ich habe es probiert mit Down/Upstream/Overhead, nur mit Down/Upstream, nur mit Overhead, alle Varianten die man machen könnte. Es ist ein 16000er ADSL-Anschluss (BNG der aber schon VLAN7 benötigt). Das dot1q geht auch über das Interface, das sieht man im Tracae..

Und warum sollten die nicht konfigurierten Raten dafür sorgen das die Verbindung zusammen bricht :/? Kannst du mir das technisch erklären..

EDIT:
Auch mit Datenraten, kein Erfolg, sowie ein Browser aus dem LAN eine Anfrage macht, Verbindung weg. 9100 zwischenzeitlich auch mal durch einen 1783, R883 ausgetauscht, genau das gleiche Verhalten...

Alle Geräte haben die aktuelle 10.20 Beta drauf...aber auch vorher ging es mit 10.12, 9.24 nicht...

Grüße
ecox

[MoinMoin]

Moin ecox!

Wenn die Datenraten (insbesondere die Upstream-Datenrate) nicht konfiguriert sind, kann es vorkommen, daß der Router hinter dem Modem mehr sendet, als das Modem zum Provider los wird. Dann muß das Modem irgendwann Pakete verwerfen. Das führte früher z.B. bei IP-Polling gelegentlich zu Verbindungsabbrüchen.

War bei dir eher unwahrscheinlich. Ein HTTP-Seitenabruf produziert dafür nicht genügend Daten im Upstream. Ich wollte es aber dennoch ausschließen.

Bei uns hier funktioniert ein vergleichbarer Aufbau problemlos. Kannst du mal die Modem-Konfiguration (also die des 1783) rüberwachsen lassen? Und am besten auch die WAN-Konfiguration des 9100.

Ciao, Georg

[ecox]

Hallo, dieses mal mit anderen Geräten getestet an einem ganz anderem Anschluss...

Code: Alles auswählen

### Baut sauber auf, bei 2:17 immer Cut (denke ist dem LCP geschuldet, 
also den Intervallen aber kann mich auch täuschen weil auch wenn ich mit den Werten gespielt habe in der PPP, gab es die selben Ergebnisse)

Conn.-start           Remote-ID         Mode    Ifc        Conn.-time            Charge   
------------------------------------------------------------------------------------------
00/00/0000 00:12:48   T-CLSURF          Active  DSL-CH-1   0:00:09               0        
00/00/0000 00:10:30   T-CLSURF          Active  DSL-CH-1   0:02:17               0        
00/00/0000 00:08:12   T-CLSURF          Active  DSL-CH-1   0:02:17               0        
00/00/0000 00:05:53   T-CLSURF          Active  DSL-CH-1   0:02:18               0        
00/00/0000 00:03:36   T-CLSURF          Active  DSL-CH-1   0:02:17               0        

### So 5-6 Sekunden vor dem Disconnect kommt ein paar mal

[PPP] 1900/01/01 00:12:26,350

LCP polling timeout for peer T-CLSURF - no echo-response received during last interval
Sending LCP echo-request with ID 05 and length 8 to peer T-CLSURF (channel 11)

### Das LCP Timeout kommt allerdings schon wenige Sekunden nach dem die Verbindung wieder erfolgreich aufgebaut wurde

[PPP] 1900/01/01 00:13:39,230

LCP polling timeout for peer T-CLSURF - echo-response received during last interval

### Dann natürlich der LCP Versuch - läuft natürlich auf Timeout

[PPP] 1900/01/01 00:14:29,230

LCP polling timeout for peer T-CLSURF - 
Sending LCP echo-request with ID 02 and length 8 to peer T-CLSURF (channel 11)

Ich werd verrückt. Wenn es bei euch läuft, wie habt ihr denn euer Modem eingerichtet, so wie in der Anleitung aus der KB?
Die Konfigurationen kann ich frühstens morgen zukommen lassen, schreib mir mal ne PM auf welchen Weg...

Grüße

ecox