MLPPP & Interfaceinstellung

marc b · Beitrag von **marc b** » 19 Aug 2006, 14:06

Hallo,

ich beschäftige mich gerade bei der Bündelung von drei oder vier ADSL Anschlüssen. Dies sollte ja mit dem 1711er kein Problem sein. Einen Provider der dies unterstützt habe ich auch. Ich mache mir gerade gedanken zur Einstellung der Interface-Ports.
Macht es Sinn dort den Speed der einzelnen Ports einzutragen? Denn der 1711 weis ja sondst garicht wieviel jede Leitung wirklich kann. So könnte es doch dazu kommen, das es Probleme mit der Bündelung gibt? Und auch der MTU-Wert ist hierbei doch von Bedeutung?
Hat jemand damit schon Erfahrung gesammelt?

Marc

Celltel · Beitrag von **Celltel** » 19 Aug 2006, 17:29

Hallo Marc
Ich habe es beim 1811 mit 4 dsl Gebündelt.
ohne große einstellungen. von MTU oder speed der Leitung.
Der Speed ist nur wichtig für QoS.

Mfg
Marcus

marc b · Beitrag von **marc b** » 19 Aug 2006, 18:05

Celltel hat geschrieben:Hallo Marc
Ich habe es beim 1811 mit 4 dsl Gebündelt.
ohne große einstellungen. von MTU oder speed der Leitung.
Der Speed ist nur wichtig für QoS.

Mfg
Marcus

Hallo Marcus,

also ich hatte das vor kurzem mal mit der 5.22 und dem 1711er voersucht. Nur hatte ich hin und wieder wohl Störungen auf einer der Leitungen. Das hatte dann zur Folge, das die Leistung sehr instabil war.

Welche Anbieter nutzt Du für die Bündelung?

Marc

Celltel · Beitrag von **Celltel** » 19 Aug 2006, 18:20

Habe RH-TEC
wichtig ist das die DSL-Leitungen stabil laufen.
und das alle zu gleichen zeit unter volllast.

Mfg
Marcus

marc b · Beitrag von **marc b** » 19 Aug 2006, 18:32

Celltel hat geschrieben:Habe RH-TEC
wichtig ist das die DSL-Leitungen stabil laufen.
und das alle zu gleichen zeit unter volllast.

Mfg
Marcus

Genau die hatte ich auch im Auge. Denn der Backbone scheind sher gut zu sein. Gerade für Onlinegaming muss dort eine gute Anbindung sein. Du hast dort also dem MTU-Wert und die Lan-Ports im 1711er auf default stehen.

Hattest Du mal die FW 5.22 und eine 6.1x Version im Vergleich ?

Marc

Celltel · Beitrag von **Celltel** » 19 Aug 2006, 18:48

Habe ich nicht
Habe gerade den 1721 mit Firmware 6.14 auf Bündeln gestellt das geht auch sehr gut aber habe ich da ein Problem mit dem Internen Modem das scheint Probleme zu machen. Beim Bündeln zeigt er zwar an, aber ich kann nicht mehr surfen.
über die Lan Ports geht alles wunderbar.

Mfg
Marcus

epple · Beitrag von **epple** » 30 Aug 2006, 21:09

Hallo!

Könnte mir jemand sagen, wo ich für den 1711er noch eine LCOS-Version 5.x herbekomme? Bei LANCOM hab ich die nicht mehr gefunden.
Warum ich in diesem Thread frage ist, weil es mit den Versionen 6.06 und 6.14 scheinbar nicht mehr möglich ist, MLPPP zum Laufen zu bekommen, ohne den Zugang zu maskierten. Gerade bei rh-tec hab ich aber ja mehrere öffentliche IP-Adressen zur Verfügung, die auch genutzt werden wollen.
Schaltet man nun die Maskierung aus, generiert der 1711er beim Verbindungsaufbau im Zusammenspiel mit Kanalbündelung irgendwie nicht akzeptierte IPCP-Pakete:

Code: Alles auswählen

[PPP] 1900/01/01 00:11:06,460
Positive Restart-Timeout event for IPCP
Generating IPCP configure-request for peer INTERNET
Inserting IP address 192.168.97.113
Inserting primary DNS address 0.0.0.0
Inserting secondary DNS address 0.0.0.0
Inserting primary NBNS address 0.0.0.0
Inserting secondary NBNS address 0.0.0.0
Sending IPCP configure-request with ID 03 and length 34 to peer INTERNET (channel 1)
Starting IPCP restart timer with 3000 milliseconds


[PPP] 1900/01/01 00:11:07,490

Received IPCP frame from peer INTERNET (channel 1)
Evaluate configure-request with ID 03 and size 10
Peer requests IP address 62.216.164.1, accepted
Positive Configure-Request-Received event for IPCP
Sending IPCP configure-ack with ID 03 and length 12 to peer INTERNET (channel 1)


[PPP] 1900/01/01 00:11:08,870

Received LCP frame from peer INTERNET (channel 1)
Evaluate protocol-reject with ID 02 and size 40
Peer rejected IPCP 8021
Catastrophic Code/Protocol-Reject-Received event for IPCP
Stopping IPCP restart timer
This-Layer-Finish action for IPCP
Administrativ-Close event for LCP
This-Layer-Down action for LCP
Lower-Layer-Down event for BACP
Stopping BACP restart timer
Lower-Layer-Down event for CCP
Stopping CCP restart timer
Lower-Layer-Down event for IPCP
This-Layer-Start action for IPCP
Stopping IPCP restart timer
Lower-Layer-Down event for IPXCP
Stopping IPXCP restart timer
Initializing LCP restart timer to 3000 milliseconds
Change phase to TERMINATE
Sending LCP terminate-request with ID 09 and length 4 to peer INTERNET (channel 1)

Aus dem Log wird ersichtlich, dass die interne LAN-Adresse übertragen wird (die öffentlichen sind in der DMZ). Nur wenn wirklich ALLES maskiert wird, wird 0.0.0.0 übertragen, und nur dann klappt MLPPP.

Laut rh-tec soll es mit einer früheren LCOS-Version problemlos unmaskiert funktionieren. Ebenso dankbar wäre ich natürlich für jegliche Tipps, beides (Maskierung aus UND Bündelung) irgendwie auch wieder mit der neuen Firmware hinzubekommen.

Vielen Dank im Voraus![/code]

Celltel · Beitrag von **Celltel** » 30 Aug 2006, 22:03

Habe noch eine Firmware 5,04 die soll aber Probleme machen.

Mfg
Marcus

backslash · Beitrag von **backslash** » 31 Aug 2006, 12:15

hi epple

Schaltet man nun die Maskierung aus, generiert der 1711er beim Verbindungsaufbau im Zusammenspiel mit Kanalbündelung irgendwie nicht akzeptierte IPCP-Pakete:

ist ja auch klar, da du vom Provider eine private Adresse forderst (192.168.97.113). Das muß er ablehnen. Du mußt schon als DMZ-Adresse/Netzmaske das eintragen, was der Provider dir zugewiesen hat. Dann fordert das LANCOM das auch bei der Einwahl.

Und abgesehen davon: von einem privaten Netz kommst du ohne Maskierung gar nicht ins Internet, also bringt es dir auch nichts, eine andere Firmware auszuprobieren...

Zudem verhalten sich alle Firmwaren in Punkt Adressanforderung gleich: ohne Maskierung wird die DMZ-Adresse vom Provider angefordert.

Wenn du das nicht willst, oder der Provider dir ein Transfernetz zuweisen will, dann kannst du auch im unmaskierten Falll eine Adreßzuweisung vom Provider anfordern, in dem du für die Gegenstelle einen Eintrag in der IP-Parameterliste aufnimmst und dort als IP-Adresse 255.255.255.255 einträgst.

Gruß
Backslash

epple · Beitrag von **epple** » 31 Aug 2006, 17:09

Hatte ich schon erwähnt, dass es trotzdem sofort funktioniert, sobald die Kanalbündelung abgeschaltet wird?
Im Übrigen habe ich das LAN durchaus maskiert gehabt und die die öffentlichen Adressen in der DMZ unmaskiert gelassen.

Wie auch immer. Ein Downgrade auf Version 5.22 hat nichts gebracht, wohl aber dein Tipp, wie man die Adresszuweisung vom Provider anfordert. Da war aber auch mein rh-tec-Ansprechpartner erstaunt drüber. Hätte ich allein nie gefunden.

Vielen vielen Dank!!

jhokamp · Beitrag von **jhokamp** » 31 Aug 2006, 17:11

Hallo,

backslash hat geschrieben: ist ja auch klar, da du vom Provider eine private Adresse forderst (192.168.97.113). Das muß er ablehnen. Du mußt schon als DMZ-Adresse/Netzmaske das eintragen, was der Provider dir zugewiesen hat. Dann fordert das LANCOM das auch bei der Einwahl.

Naja, das macht imho aber keinen Sinn, da in der IPCP-Phase ja die WAN IP ausgehandelt werden soll. DMZ/LAN-IP(-Netze) werden ja lediglich numbered über die WAN IP gerouted.

backslash hat geschrieben: Zudem verhalten sich alle Firmwaren in Punkt Adressanforderung gleich: ohne Maskierung wird die DMZ-Adresse vom Provider angefordert.

Warum das? Das PPP-Protokoll (speziell IPCP) dient doch in erster Linie zum aushandeln der IP Parameter für das *WAN* Interface. Wenn da IP gesprochen wird, ist der Rest eine Routingfrage.

backslash hat geschrieben: Wenn du das nicht willst, oder der Provider dir ein Transfernetz zuweisen will, dann kannst du auch im unmaskierten Falll eine Adreßzuweisung vom Provider anfordern, in dem du für die Gegenstelle einen Eintrag in der IP-Parameterliste aufnimmst und dort als IP-Adresse 255.255.255.255 einträgst.

Ja, das funktioniert, danke!

Viele Grüße

Jörg Hokamp

backslash · Beitrag von **backslash** » 31 Aug 2006, 20:28

Hi jhokamp

Naja, das macht imho aber keinen Sinn, da in der IPCP-Phase ja die WAN IP ausgehandelt werden soll. DMZ/LAN-IP(-Netze) werden ja lediglich numbered über die WAN IP gerouted.
(...)
Warum das? Das PPP-Protokoll (speziell IPCP) dient doch in erster Linie zum aushandeln der IP Parameter für das *WAN* Interface. Wenn da IP gesprochen wird, ist der Rest eine Routingfrage

weil das LANCOM sich bei unmaskierten Verbindungen primär als "Halbrouter" verhält, d.h. LAN- und WAN-seitig im gleichen Netz steht, es sei denn, man konfiguriert etwas anderes.

Der Grund dafür ist, daß es es genügend Provider gibt - imho sind das sogar die meisten - die dir gar kein Transfernetz anbieten. Daher *MUSS* das LANCOM bei diesen Providern eine Adresse aus seiner DMZ anfordern.

Gruß
Backslash

jhokamp · Beitrag von **jhokamp** » 31 Aug 2006, 20:36

Hi backslash,

backslash hat geschrieben: weil das LANCOM sich bei unmaskierten Verbindungen primär als "Halbrouter" verhält, d.h. LAN- und WAN-seitig im gleichen Netz steht, es sei denn, man konfiguriert etwas anderes.

Der Grund dafür ist, daß es es genügend Provider gibt - imho sind das sogar die meisten - die dir gar kein Transfernetz anbieten. Daher *MUSS* das LANCOM bei diesen Providern eine Adresse aus seiner DMZ anfordern.

die Geschichte mit dem Halbrouter kann ich nachvollziehen - und macht bei vielen Verbindungsarten, wie zB ATM, sicher Sinn. Ich muss an dieser Stelle zugeben das ich bislang nichtmal wusste das diese unnumbered Übertragung für IPv4-PPP möglich ist - ist sie das wirklich, oder laufen wir hier lediglich in eine "ungünstige Konstellation" vom LCOS?

Was mich jedoch *richtig* wundert, ist, das das ganze lediglich mit MLPPP auftritt. Eine Erklärung *wäre* dafür das auf der LCOS Seite nur eine gewisse Anzahl an LCP-Negotationen zugelassen wird. Durch MLPPP muss ja die MRRU mit ausgehandelt werden, somit würde eine LCP-Verhandlung mehr stattfinden. (Denn es ist ja definitv so: Ohne den 255.255.255.255 Eintrag muss lediglich die Kanalbündelung deaktiviert werden, schon läufts wie es soll)

Any hints, anyone?

Gruss

Jörg Hokamp

backslash · Beitrag von **backslash** » 31 Aug 2006, 20:46

Hi jhokamp

Ich muss an dieser Stelle zugeben das ich bislang nichtmal wusste das diese unnumbered Übertragung für IPv4-PPP möglich ist - ist sie das wirklich,

eine PPP-Strecke ist erstmal nur "so eine Art Kabel" auf dem der Provider einfach alles, was für die dahinter liegende DMZ bestimmt rüberschickt. Da im PPP keine Ethernet-Header übertragen werden ist auch kein Transfernetz nötig, in dem der zuständige Router per ARP aufgelöst würde - das andere Ende nimmt einfach alles ab.

oder laufen wir hier lediglich in eine "ungünstige Konstellation" vom LCOS?

nein, das ist eine ganz normale Betriebsart, die - wie schon gesagt - vom LANCOM defaultmäßig benutzt wird.

Was mich jedoch *richtig* wundert, ist, das das ganze lediglich mit MLPPP auftritt

das wundert mich auch, denn Bündelung ist ja nur eine Option der Leitung. Ehrlich gesagt, kann ich das eigentlich auch nicht glauben, habe aber jetzt auch keine Zeit, das mal nachzustellen...

Eine Erklärung *wäre* dafür das auf der LCOS Seite nur eine gewisse Anzahl an LCP-Negotationen zugelassen wird

nein, da gibt es keine Beschränkungen

Gruß
Backslash

jhokamp · Beitrag von **jhokamp** » 31 Aug 2006, 20:59

Hi,

backslash hat geschrieben: eine PPP-Strecke ist erstmal nur "so eine Art Kabel" auf dem der Provider einfach alles, was für die dahinter liegende DMZ bestimmt rüberschickt. Da im PPP keine Ethernet-Header übertragen werden ist auch kein Transfernetz nötig, in dem der zuständige Router per ARP aufgelöst würde - das andere Ende nimmt einfach alles ab.

ja, das ist klar.

PPP Interfaces, welche auf Providerseite aus einem L2TP Tunnel "entspringen" sind aber idR dynamische, virtuelle Interfaces. Ich sehe hier absolut keinen Vorteil oder Grund das (IPv4-)Routing über diese dynamischen Interfaces zu legen.

Aber gut, wir haben eine Lösung, vielen Dank dafür.

Jörg

(der immernoch meint, das das Verhalten in frühen 5.x er Versionen anders war, und dieses Verhalten in Zusammenhang mit PPPoE auch nicht normal ist)