LANCOM 730 als Backup-LTE Lösung für LANCOM 1781VAW

[adrian2808]

Hi Lancom Forum,

bitte habt Nachsehen, da ich absoluter Einsteiger bin was Lancom angeht.
Habe einen bereits bestehenden Lancom 1781VAW und würde an diesen gerne einen Lancom 730 anschließen der im Falle eines Ausfalls der DSL Leitung eine stabile LTE Verbindung herstellt. Den Lancom 730 separat als Router zu nutzen ist mir gelungen, jedoch stellt sich für mich die Frage wie ich die beiden zur Kommunikation bekomme.
Das LCOS 1.50 Referenzhandbuch ist mir wohl zu komplex und im Forum habe ich leider diesen Fall nicht gefunden. Habt ihr noch Tipps wo man sich in das Thema einlesen könnte?

MFG
Vielen Dank im Voraus

[PappaBaer]

Moin,

ich gehe jetzt mal davon aus, dass Du nur ein IP-Netz im 1781 nutzt (Intranet). Geht natürlich auch mit mehreren, bedarf dann je nach Lösungsansatz aber ggf. zusätzliche Konfigurationen.

da gibt es im Prinzip drei Möglichkeiten.

Möglichkeit 1: Du gibst dem 730 eine IP-Adresse aus Deinem Intranet und erstellst auf dem 1781 im IP-Router eine weitere Default-Route mit Ziel "IP des 730" und Administrativer Distanz 20. Maskierung hier muss auf AUS stehen!. Das ist das "einfachste", bedeutet aber, dass Du bei Nutzung der LTE-Leitung ein asymmetrisches Routing hast. Das ist aber mit den Lancom-Geräten so erstmal kein Problem.

Möglichkeit 2: Du hast im 730 ein IP-Netz, welches sich vom Intranet unterscheidet. Dann erstellst Du am 1781 mit dem Assistenten eine weitere Internetverbindung und wählst hier IPoE aus. In den nächsten Schritten entweder IP automatisch beziehen lassen (wenn DHCP auf dem 730 aktiv) oder händisch eine aus dem 730-Intranet vergeben, Gateway ist IP des 730 und DNS entweder auch oder direkt ein öffentlicher DNS-Server. Als Schnittstelle wählst Du eine freie ETH vom 1781. Wichtig: Am Ende des Assistenten sagen, dass er die bisherige Default-Route belassen soll. Danach gehst Du im 1781 in die Konfiguration und erstellst ebenso eine weitere Default-Route mit Ziel "neue Internet Gegenstelle", Maskierung an und Administrativer Distanz 20. Nachteil wäre hier ggf. das doppelte NAT Richtung Internet bei Nutzung der LTE-Verbindung. 1781 dann mit der im Assistenten gewählten ETH-Schnittstelle mit dem 730 verbinden.

Möglichkeit 3: Du nutzt zwischen 1781 und 730 ein Transfer-Netz. Intranet vom 1781 und 730 unterschiedlich. Dann richtest Du sowohl auf dem 1781 als auch auf dem 730 ein weiteres IPv4-Netz an und nennst es z.B. Transfer. Hier nimmst Du auf beiden Geräten dasselbe Netz (ungleich dem Intranet von 1781 und ungleich dem Intranet von 730) mit unterschiedlichen Adressen. Das legst Du jeweils auf ein freies logisches LAN-Interface, z.B LAN3.
Dann noch unter Schnittstellen LAN auf beiden Geräten jeweils ein ETH-Inteface auf das dem Transfer-Netz zugewiesenen LAN-Inteface legen.
Auf dem 1781 dann wieder eine weitere Default-Route, Ziel "IP des 730 im Transfer-Netz", Maskierung AUS und Administrative Distanz 20. Auf dem 730 eine weitere Route für das "IP-Netz des Intranet auf dem 1781" mit Ziel "IP des 1781 im Transfer-Netz". Beide Geräte dann mit den ETH-Schnittstellen verbinden, denen Du das LAN des Transfer-Netzes zugewiesen hast.

Viele Grüße,
Torsten

[backslash]

Hi PappaBaer,

Möglichkeit 1: Du gibst dem 730 eine IP-Adresse aus Deinem Intranet und erstellst auf dem 1781 im IP-Router eine weitere Default-Route mit Ziel "IP des 730" und Administrativer Distanz 20. Maskierung hier muss auf AUS stehen!. Das ist das "einfachste", bedeutet aber, dass Du bei Nutzung der LTE-Leitung ein asymmetrisches Routing hast. Das ist aber mit den Lancom-Geräten so erstmal kein Problem.

das assymmetrische Routing kann bei "einkommenden" Sessions u.U. Probleme mit der Firewall nach sich ziehen, wenn Session-Recovery (im LANconfig "Sitzungs-Wiederherstellung") nicht erlaubt ist. Ein Beispiel wäre die Datensession eines aktiven FTP (denn die wird vom Server aus aufgebaut und ist somit eine "einkommende" Session):
Das TCP-SYN kommt beim LTE-Router an und wird direkt von diesem dierkt ins LAN gesendet. Die Antwort darauf (das SYN/ACK) geht zuerst aber an den 1781 und wird dort als Paket einer unbekannten Session abgelehnt. Es sei denn man erlaubt die Session-Recovery auch für die Default-Route

Gruß
Backslash