Routing Frage welches Protokoll für Mobile Geräte
Hallo zusammen,
Ich habe folgende Frage bei der ihr mir sicher weiterhelfen könnt.
Ich habe einen Knotenpunkt bei einem Kunden. Als Router wird ein Mikrotik verwendet.
Der Kunde hat für seine Geräte über GSM/LTE (ebenfalls Mikrotik Router) eine VPN Verbindung zu diesem Router. Das ganze ca. 10-15 mal.
Jetzt wollte ich auf den Knotenpunkt als Routing Protokoll RIP V2 einsetzen. Leider geht das über die GSM/LTE nicht.
Warscheinlich weil RIP als Multicast gesendet wird.
Ich will die ganzen Router nicht manuell eintragen. Was würdet ihr einsetzen? bzw. das lösen.
Dachte an OSPF nur weis ich nicht ob das über GSM/LTE geht.
sG
Chris
Ich habe folgende Frage bei der ihr mir sicher weiterhelfen könnt.
Ich habe einen Knotenpunkt bei einem Kunden. Als Router wird ein Mikrotik verwendet.
Der Kunde hat für seine Geräte über GSM/LTE (ebenfalls Mikrotik Router) eine VPN Verbindung zu diesem Router. Das ganze ca. 10-15 mal.
Jetzt wollte ich auf den Knotenpunkt als Routing Protokoll RIP V2 einsetzen. Leider geht das über die GSM/LTE nicht.
Warscheinlich weil RIP als Multicast gesendet wird.
Ich will die ganzen Router nicht manuell eintragen. Was würdet ihr einsetzen? bzw. das lösen.
Dachte an OSPF nur weis ich nicht ob das über GSM/LTE geht.
sG
Chris
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 396127
Url: https://administrator.de/forum/routing-frage-welches-protokoll-fuer-mobile-geraete-396127.html
Ausgedruckt am: 21.12.2024 um 15:12 Uhr
8 Kommentare
Neuester Kommentar
Das kannst du machen RIPv2 oder OSPF wäre auch die richtige Wahl das sauber zu lösen. Bei soviel Außenstellen macht das auch in jedem Falle Sinn das dynamisch zu machen.
OSPF ist ein klein wenig effizienter, denn es schiebt nicht immer die gesamte Routig Tabelle raus per Broadcast sondern nur einen Keepalive. Außerdem kannst du OSPF noch verschlüsseln innerhalb des VPNs sofern du das möchtest.
Letztendlich ist es aber egal was man nimmt von beiden.
Du schreibst ja das du eine VPN Verbindung zw. den Standorten konfiguriert hast. Diese VPN Verbindungen laufen ja vermutlich aktuell über GSM/LTE ?! Also geht es ja.
Was du innerhalb deines VPN Tunnels machst kann der GSM/LTE Provider bzw. alle Provider ja niemals sehen.
Folglich geht also auch RIPv2 oder OSPF da drin im Tunnel.
Oder meintest du jetzt das du generell keinen Site to Site VPN Tunnel über eine LTE Verbindung hinbekommst ??
Das kann dann daran liegen das der Mobilfunkprovider im Funknetz private RFC 1918 IPs nutzt und ein CGN dort macht.
Das fixt man aber mit einem anderen APN sprich Business Tarif.
Dein Problem ist vermutlich eine falsche VPN Konfig. Wenn du dynamsiche Routing Protokolle überträgst reicht eine reine Traffic Encapsulation via IPsec nicht.
Wir gehen jetzt hier mal von einem IPsec VPN aus, ist das richtig ? Leider ist deine Beschreibung da etwas öberflächlich
Du musst innerhalb des VPN noch einen IPIP oder GRE Tunnel in jede Location legen. Die GRE Tunnelinterfaces inkludierst du dann ins dynmaische Routing Protokoll et voila.... dann rennt auch dynamisches Routing im gesamten Netz ! Egal ob xDSL, GSM/LTE, Ethernet oder ein feuchter Bindfaden zwischen den Mikrotiks ist
Guckst du auch hier:
http://gregsowell.com/?download=5687
OSPF ist ein klein wenig effizienter, denn es schiebt nicht immer die gesamte Routig Tabelle raus per Broadcast sondern nur einen Keepalive. Außerdem kannst du OSPF noch verschlüsseln innerhalb des VPNs sofern du das möchtest.
Letztendlich ist es aber egal was man nimmt von beiden.
Leider geht das über die GSM/LTE nicht.
Das ist natürlich Unsinn. Weisst du aber sicher auch selber.Du schreibst ja das du eine VPN Verbindung zw. den Standorten konfiguriert hast. Diese VPN Verbindungen laufen ja vermutlich aktuell über GSM/LTE ?! Also geht es ja.
Was du innerhalb deines VPN Tunnels machst kann der GSM/LTE Provider bzw. alle Provider ja niemals sehen.
Folglich geht also auch RIPv2 oder OSPF da drin im Tunnel.
Oder meintest du jetzt das du generell keinen Site to Site VPN Tunnel über eine LTE Verbindung hinbekommst ??
Das kann dann daran liegen das der Mobilfunkprovider im Funknetz private RFC 1918 IPs nutzt und ein CGN dort macht.
Das fixt man aber mit einem anderen APN sprich Business Tarif.
Dein Problem ist vermutlich eine falsche VPN Konfig. Wenn du dynamsiche Routing Protokolle überträgst reicht eine reine Traffic Encapsulation via IPsec nicht.
Wir gehen jetzt hier mal von einem IPsec VPN aus, ist das richtig ? Leider ist deine Beschreibung da etwas öberflächlich
Du musst innerhalb des VPN noch einen IPIP oder GRE Tunnel in jede Location legen. Die GRE Tunnelinterfaces inkludierst du dann ins dynmaische Routing Protokoll et voila.... dann rennt auch dynamisches Routing im gesamten Netz ! Egal ob xDSL, GSM/LTE, Ethernet oder ein feuchter Bindfaden zwischen den Mikrotiks ist
Guckst du auch hier:
http://gregsowell.com/?download=5687
Ich habe das RIP V2 nicht über das VPN zum laufen bekommen. Keine Ahnung wieso.
Da das mit Broadcasts funktioniert brauchst du dafür über das VPN immer eine Tunnelverbindung sprich also einen GRE oder IPIP Tunnel. Damit funktioniert sowas auf Anhieb.Routing Protokolle wie PIM, RIPv2, OSPF usw. kannst du ohne einen GRE oder IPIP Tunnel nicht realisieren, denn dafür brachst du zusätzlich routebare Interfaces.
Mit diesem Tunnel funktioniert es dann aber problemlos !
Ich habe mal einen Testaufbau gemacht hier mit 2 MTs und tunnele OSPF über einen GRE Tunnel.
Das funktioniert bestens ohne Masquerading auf dem WAN Port (eth1 hier im Test).
Mit Masquerading stirbt aber der GRE Tunnel.Mich würde da mal deine Firewall Konfig interessieren sofern du auch GRE nutzt und NAT machst auf dem WAN Port. Der Tunnel Traffic muss vom NAT ausgenommen werden.
Der IPsec Tunnel ist hier im Testaufbau stabil. Das ist auch klar, denn der greift ja nur extern.
Irgendwie wird der GRE Tunnel durch das Masquerading noch kaputt gemacht. Da muss ich nochmal forschen.
Leider beschreiben alle Anleitungen im Netz dieses Design immer nur ohne NAT am WAN Port
https://www.youtube.com/watch?v=wov-Jb3FgK8
Das funktioniert bestens ohne Masquerading auf dem WAN Port (eth1 hier im Test).
Mit Masquerading stirbt aber der GRE Tunnel.
Der IPsec Tunnel ist hier im Testaufbau stabil. Das ist auch klar, denn der greift ja nur extern.
Leider beschreiben alle Anleitungen im Netz dieses Design immer nur ohne NAT am WAN Port
https://www.youtube.com/watch?v=wov-Jb3FgK8
So...Denkfehler gefunden !!
Ich habe für den Testaufbau die stinknormale Default Konfig des Mikrotik genutzt. Internet NAT an eth1 und lokales LAN via eth2-5 zur Bridge zusammengefügt.
In der Interface Liste LAN (Default Konfig) muss logischerweise das GRE Tunnel Interface noch hinzugefügt werden, sonst blockt die Firewall den OSPF Traffic (oder das verwendete dynamische Routing Protokoll über den GRE Tunnel
Das hatte ich im Eifer des Gefechts übersehen...
So sieht der funktionierende Testaufbau aus:
Relativ simpel:
Die Schritte im einzelnen (Beispielkonfig hier Mikrotik 1):
1.) GRE Tunnelinterface anlegen:
Wichtig hier !:
Gleich einen Haken setzen bei IPsec secret dann legt Mikrotik gleich automatisch ein IPsec VPN an für den Tunnel !
2.) Dem GRE Tunnelinterface eine IP geben:
3.) Beide IP Netze (lok. LAN und GRE Tunnel) im OSPF Routing anlegen:
Interfaces werden automatisch im OSPF Route Prozess zugefügt:
4.) Interface Liste "LAN" in der Firewall anpassen (Default Konfig):
Das wirkt auf diese Firewall Regel:
Hat man alles richtig gemacht sieht man im OSPF Prozess unter "Neighbor" (Nachbar) den jeweils anderen OSPF Router via GRE Tunnel.
Die Routing Tabelle zeigt dann auch erwartungsgemäß alle per OSPF gelernten IP Netze an:
Die Distance 110 ist die Default Distance bei OSPF und zeigt dann das diese Route via GRE gelernt wurde.
Clients in beiden lokalen LAN Segmenten können sich pingen.
Works as designed...
Ich habe für den Testaufbau die stinknormale Default Konfig des Mikrotik genutzt. Internet NAT an eth1 und lokales LAN via eth2-5 zur Bridge zusammengefügt.
In der Interface Liste LAN (Default Konfig) muss logischerweise das GRE Tunnel Interface noch hinzugefügt werden, sonst blockt die Firewall den OSPF Traffic (oder das verwendete dynamische Routing Protokoll über den GRE Tunnel
Das hatte ich im Eifer des Gefechts übersehen...
So sieht der funktionierende Testaufbau aus:
Relativ simpel:
- Mikrotik Default Konfig: Internet mit NAT= Port eth1, Lokales LAN= Bridge Ports eth2-5.
- Das 172.32.32.0 /24 er Netz simuliert das Internet
- GRE Tunnelinterfaces 192.168.1.1 /30 auf MT-1 und 192.168.1.2 /30 auf MT-2
- Simple OSPF Standardkonfig: Keine Areas alles in Area 0 (Backbone)
- Es sind keinerlei statische Routen erforderlich !!! OSPF (bei dir RIPv2) macht alles dynamisch !
Die Schritte im einzelnen (Beispielkonfig hier Mikrotik 1):
1.) GRE Tunnelinterface anlegen:
Wichtig hier !:
Gleich einen Haken setzen bei IPsec secret dann legt Mikrotik gleich automatisch ein IPsec VPN an für den Tunnel !
2.) Dem GRE Tunnelinterface eine IP geben:
3.) Beide IP Netze (lok. LAN und GRE Tunnel) im OSPF Routing anlegen:
Interfaces werden automatisch im OSPF Route Prozess zugefügt:
4.) Interface Liste "LAN" in der Firewall anpassen (Default Konfig):
Das wirkt auf diese Firewall Regel:
Hat man alles richtig gemacht sieht man im OSPF Prozess unter "Neighbor" (Nachbar) den jeweils anderen OSPF Router via GRE Tunnel.
Die Routing Tabelle zeigt dann auch erwartungsgemäß alle per OSPF gelernten IP Netze an:
Die Distance 110 ist die Default Distance bei OSPF und zeigt dann das diese Route via GRE gelernt wurde.
Clients in beiden lokalen LAN Segmenten können sich pingen.
Works as designed...
Es gibt kein festes Limit aus Protokoll Sicht. Limit ist mehr oder minder CPU Power und RAM im Router.
So als goldene Netzwerker Daumenregel sagt man nicht mehr als 100 Neighbors (Router) pro Ärea.
Bei den Netzen ist das ebenfalls rein eine Frage des RAMs bei den Systemen. Auch kleine Router haben bis ca. 1000 Netzen keinerlei Probleme.
Von den Zahlen liegst du da weit drunter und bis safe.
Man könnte die Außenstellen als Stub Äreas definieren, das wird aber dann zum Problem wenn eine Außenstelle mal direkt zu einer anderen geht z.B. im Backup Fall. Dann fehlt dir die Backbone Ärea dazwischen ohne die nix geht.
Bei deiner geringen Anzahl an Neighbors kannst du alles in der Backbone Ärea belassen. Alles andere würde das Setup nur aufblähen und hätte nicht wirklich Vorteile.
Lesenswert zu dem Thema auch:
Zwischen Miktrotik und PFSense GRE Tunnel mit IPSec Verschlüsslung
So als goldene Netzwerker Daumenregel sagt man nicht mehr als 100 Neighbors (Router) pro Ärea.
Bei den Netzen ist das ebenfalls rein eine Frage des RAMs bei den Systemen. Auch kleine Router haben bis ca. 1000 Netzen keinerlei Probleme.
Von den Zahlen liegst du da weit drunter und bis safe.
Man könnte die Außenstellen als Stub Äreas definieren, das wird aber dann zum Problem wenn eine Außenstelle mal direkt zu einer anderen geht z.B. im Backup Fall. Dann fehlt dir die Backbone Ärea dazwischen ohne die nix geht.
Bei deiner geringen Anzahl an Neighbors kannst du alles in der Backbone Ärea belassen. Alles andere würde das Setup nur aufblähen und hätte nicht wirklich Vorteile.
Lesenswert zu dem Thema auch:
Zwischen Miktrotik und PFSense GRE Tunnel mit IPSec Verschlüsslung