
39668
07.12.2006, aktualisiert am 22.12.2006
Routing von Bridge auf 3verschiedene Router zu Switch und zurück....
Hallo Forum
Ich habe heute unsere neue 4024-Switch erhalten. Diese sollte nun in unserem Netzwerk zum einen, den einzelnen IBM-Blades eine IP-Adresse geben (da nur copper-pass-trough-module drin sind) und zum zweiten sollte sie jegliche clients-anfragen auf drei verschiedene router weiterleiten (je nachdem was genutzt werden will), die wiederum eine öffentliche ip-adresse von der sdsl-bridge erhalten.
Ich brauche dazu hilfe, da ich keine ahnung hab wie ich überhaupt beginnen soll. solch komplizierte (für mich jedenfalls) routings hab ich noch nie konfigurieren müssen. ist für unser internes netzwerk.
Unten seht ihr einen Plan:
wäre froh um jede noch so kleine hilfe oder tipp (vielleicht sogar ein tutorial).
grüsse
rob
Ich habe heute unsere neue 4024-Switch erhalten. Diese sollte nun in unserem Netzwerk zum einen, den einzelnen IBM-Blades eine IP-Adresse geben (da nur copper-pass-trough-module drin sind) und zum zweiten sollte sie jegliche clients-anfragen auf drei verschiedene router weiterleiten (je nachdem was genutzt werden will), die wiederum eine öffentliche ip-adresse von der sdsl-bridge erhalten.
Ich brauche dazu hilfe, da ich keine ahnung hab wie ich überhaupt beginnen soll. solch komplizierte (für mich jedenfalls) routings hab ich noch nie konfigurieren müssen. ist für unser internes netzwerk.
Unten seht ihr einen Plan:
wäre froh um jede noch so kleine hilfe oder tipp (vielleicht sogar ein tutorial).
grüsse
rob
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 46264
Url: https://administrator.de/forum/routing-von-bridge-auf-3verschiedene-router-zu-switch-und-zurueck-46264.html
Ausgedruckt am: 22.04.2025 um 12:04 Uhr
8 Kommentare
Neuester Kommentar
Im Grunde genommen ist das gar nicht so kompliziert. Der GS 4024 ist nach Zyxel Seite ein Layer 3 Switch, kann also auch routen.
Leider ist deine Zeichnung sehr diffus und du sagst überhaupt nichts aus WIE in eurem Unternehmensnetz geroutet wird, denn es sind ja viele Teilnetze vorhanden.
Als ersten Schnellschuss erstmal die wichtigsten ToDos:
1.) Die unterschiedlichen Subnetze deines Netzes musst du auf dem Switch als sog. VLANs abbilden. Du musst dich also erstmal hinsetzen und eine Liste der benötigten VLANs, die Anzahl der Endgeräte Ports die für das VLAN benötigt werden und eine VLAN ID und ggf. einen Namen überlegen bevor du ans Konfigurieren gehst.
2.) Um mit dem Switch Layer 3 switchen (routen) zu können benötigst du eine IP Adresse aus jedem auf dem Switch aufliegenden Subnetz als Layer 3 Interface. Hierfür musst du eine freie IP Adresse verwenden. Laut Zeichnung kann der Switch mehrere einzelne Router ersetzen.Es ist die Frage ob das geschehen soll oder nicht. Wenn ja kann der Switch diese Adressen ggf. übernehmen ?
3.) Eine sehr wichtige Frage die zu klären ist: Wo zeigen die Gateways der Endsysteme hin. Sollen die zukünftig zentral über den Switch geroutet werden, was sich aus Performancegründen natürlich anbietet.
Sind diese Adressen statisch konfiguriert oder werden sie per DHCP übergeben. ? Hier ist ggf. eine Anpassung vonnöten ! Wären es 2 mal GS 4024 im Core könnte man über ein Hochverfügbarkeitsszenario nachdenken mit VRRP, denn auch das unterstützen die Switches.
4.) Als zweitwichtigste Frage stellt sich, ob ihr aufgrund der vielen Subnetze vielleicht dynamisch routet ?? Bei der Anzahl der Netze bietet sich das an um nicht in einem Meer von statischen Routen auf einzelnen Systemen unterzugehen. RIP2 oder OSPF wären hier die Protokolle der Wahl, die auch der Switch unterstützt. Das würde dir die Administration und Konfiguration erheblich erleichtern.
Du siehst...4 komplexe Punkte mit zig Unterpunkten die es zu klären gilt bevor man dir eine Step by Step Anweisung geben könnte. Das Konfig Manual des Zyxel musst du aber selber lesen
Leider ist deine Zeichnung sehr diffus und du sagst überhaupt nichts aus WIE in eurem Unternehmensnetz geroutet wird, denn es sind ja viele Teilnetze vorhanden.
Als ersten Schnellschuss erstmal die wichtigsten ToDos:
1.) Die unterschiedlichen Subnetze deines Netzes musst du auf dem Switch als sog. VLANs abbilden. Du musst dich also erstmal hinsetzen und eine Liste der benötigten VLANs, die Anzahl der Endgeräte Ports die für das VLAN benötigt werden und eine VLAN ID und ggf. einen Namen überlegen bevor du ans Konfigurieren gehst.
2.) Um mit dem Switch Layer 3 switchen (routen) zu können benötigst du eine IP Adresse aus jedem auf dem Switch aufliegenden Subnetz als Layer 3 Interface. Hierfür musst du eine freie IP Adresse verwenden. Laut Zeichnung kann der Switch mehrere einzelne Router ersetzen.Es ist die Frage ob das geschehen soll oder nicht. Wenn ja kann der Switch diese Adressen ggf. übernehmen ?
3.) Eine sehr wichtige Frage die zu klären ist: Wo zeigen die Gateways der Endsysteme hin. Sollen die zukünftig zentral über den Switch geroutet werden, was sich aus Performancegründen natürlich anbietet.
Sind diese Adressen statisch konfiguriert oder werden sie per DHCP übergeben. ? Hier ist ggf. eine Anpassung vonnöten ! Wären es 2 mal GS 4024 im Core könnte man über ein Hochverfügbarkeitsszenario nachdenken mit VRRP, denn auch das unterstützen die Switches.
4.) Als zweitwichtigste Frage stellt sich, ob ihr aufgrund der vielen Subnetze vielleicht dynamisch routet ?? Bei der Anzahl der Netze bietet sich das an um nicht in einem Meer von statischen Routen auf einzelnen Systemen unterzugehen. RIP2 oder OSPF wären hier die Protokolle der Wahl, die auch der Switch unterstützt. Das würde dir die Administration und Konfiguration erheblich erleichtern.
Du siehst...4 komplexe Punkte mit zig Unterpunkten die es zu klären gilt bevor man dir eine Step by Step Anweisung geben könnte. Das Konfig Manual des Zyxel musst du aber selber lesen
OK, das macht die Sache etwas transparenter. Um eine saubere Umgebung zu schaffen und erstmal schnell den Switch zu integrieren brauchst du mindestens 2 VLANs. Ich würde mir gleich 3 einrichten, denn die VoIP Umgebung setzt man tunlichst in ein separates VLAN um Sprachdaten von Anwendungsdaten zu trennen. Das hat auch sicherheitstechnische Gründe, da VoIP heute noch meist ungeschlüsselt übers Netz geht. Mischt man das mit Anwendungsdaten ist es ein Leichtes mit einem entspr. Tool den Voice Traffic abzuhören.
Ein VLAN ist euer neues Office Netz mit einem ganz neuen IP Adressbereich, da ihr ja von der alten Struktur unabhängig sein wollt.
Deshalb musst du ja erstmal den LanCom VPN Router in dem Umfeld belassen wie er ist. Der Router kommt in ein separates VLAN mit den alten IP Adressen.
Allerdings birgt dieses Setup die Gefahr das dir der Routeradmin des VPN Routers eine Route auf dein neues Office LAN eintragen muss.
Willst du das umgehen, kannst du erstmal nur die Endgeräte im gleichen VLAN betreiben wie der VPN Router solange eurer neues Netz IP technisch noch "unbekannt" auf diesen Routern ist.
Hast du das erreicht trägst du auf dem zentralen Zyxel Switch der ja nun deine Routing Instanz ist eine statische Route nach dem Muster ein:
IP Netz Navision, Maske, next Hop Gateway=IP des VPN Routers.
Nach diesem Muster gehst du vor für alle weiteren externen Netze die geroutet werden wenn sie NICHT direkt am Zyxel angeschlossen sind. Dafür braucht der Switch natürlich keine Routen, denn sie sind ja direkt an ihm dran, er kennt sie also selber !
So verfährt der Switch mit den von dir angesprochenen "Anfragen" seine Ziel IP des Navision Netzes steht ja in der IP Adresse und darauf zielt die statische Route ab die ihn dann an Router 2 schickt eben dem next Hop Gateway ! Bei allen anderen Packeten kann er das lokal machen wenn es Netze an ihm direkt sind.
Der Vorteil ist das du alle Endgeräte nach und nach je nach Konfiguration so in euer neues abgetrenntes Office Netz migrieren kannst.
Die Thematik mit den Blade Servern ist mir allerdings schleierhaft.... Ein Switch kann niemals IP Adressen zuweisen, das kann, wenn dann, nur ein DHCP Server im Netz.
Also entweder sind die "Copper pass through" Teile irgendsowas wie Hubs oder Switches. IBM war schon immer bekannt dafür das sie für Allerweltsbezeichnungen immer etwas "Spezielles" hatten. Das solltest du mit IBM nochmal genau klären was die genau machen...
Ein VLAN ist euer neues Office Netz mit einem ganz neuen IP Adressbereich, da ihr ja von der alten Struktur unabhängig sein wollt.
Deshalb musst du ja erstmal den LanCom VPN Router in dem Umfeld belassen wie er ist. Der Router kommt in ein separates VLAN mit den alten IP Adressen.
Allerdings birgt dieses Setup die Gefahr das dir der Routeradmin des VPN Routers eine Route auf dein neues Office LAN eintragen muss.
Willst du das umgehen, kannst du erstmal nur die Endgeräte im gleichen VLAN betreiben wie der VPN Router solange eurer neues Netz IP technisch noch "unbekannt" auf diesen Routern ist.
Hast du das erreicht trägst du auf dem zentralen Zyxel Switch der ja nun deine Routing Instanz ist eine statische Route nach dem Muster ein:
IP Netz Navision, Maske, next Hop Gateway=IP des VPN Routers.
Nach diesem Muster gehst du vor für alle weiteren externen Netze die geroutet werden wenn sie NICHT direkt am Zyxel angeschlossen sind. Dafür braucht der Switch natürlich keine Routen, denn sie sind ja direkt an ihm dran, er kennt sie also selber !
So verfährt der Switch mit den von dir angesprochenen "Anfragen" seine Ziel IP des Navision Netzes steht ja in der IP Adresse und darauf zielt die statische Route ab die ihn dann an Router 2 schickt eben dem next Hop Gateway ! Bei allen anderen Packeten kann er das lokal machen wenn es Netze an ihm direkt sind.
Der Vorteil ist das du alle Endgeräte nach und nach je nach Konfiguration so in euer neues abgetrenntes Office Netz migrieren kannst.
Die Thematik mit den Blade Servern ist mir allerdings schleierhaft.... Ein Switch kann niemals IP Adressen zuweisen, das kann, wenn dann, nur ein DHCP Server im Netz.
Also entweder sind die "Copper pass through" Teile irgendsowas wie Hubs oder Switches. IBM war schon immer bekannt dafür das sie für Allerweltsbezeichnungen immer etwas "Spezielles" hatten. Das solltest du mit IBM nochmal genau klären was die genau machen...
Uuhh böses Faul aber meist normal da die DHCP Server Implementation meist recht primitiv ist auf Switches. Dort sollte man auch tunlichst kein DHCP machen.
Das Problem kannst du aber ganz einfach lösen mit einem externen DHCP Server auf einer Windows Maschine oder umsonst mit Linux auf irgendeinem ollen PC den du noch überhast. Beide Lösungen leisten das Problemlos.
Den DHCP Server auf dem Swiitch musst du aber dann natürlich tunlichst abschalten !!
Das Problem kannst du aber ganz einfach lösen mit einem externen DHCP Server auf einer Windows Maschine oder umsonst mit Linux auf irgendeinem ollen PC den du noch überhast. Beide Lösungen leisten das Problemlos.
Den DHCP Server auf dem Swiitch musst du aber dann natürlich tunlichst abschalten !!