DHCP-Relay mit Cisco SG300-28 Switch
Hallo geschätzte Mit-Admins,
ich habe momentan das erste Mal mit einer Umgebung mit VLANs zu tun.
Dabei stellt sich folgende Anforderung:
Ein einzelner Windows 2012R2 DHCP Server soll Clients in verschiedenen Subnetzen (die sich in eigenen VLANs befinden) bedienen. Die VLANs sollen so weit wie möglich abgeschottet sein und idealerweise gar nicht untereinander geroutet sein.
Daher habe ich am DHCP-Server mehrere Scopes (192.168.2.0/24, 192.168.3.0/24, 192.168.4.0/24) erstellt und mit der gewünschten Konfiguration versehen. Zunächst soll im Testaufbau einfach nur eine IP 192.168.x.100-149, Subnetmask 255.255.255.0, Gateway 192.168.x.1 vergeben werden.
Am Switch habe ich für diesen Test Port 2 zum VLAN 2 hinzugefügt und den Typ auf Access/untagged eingestellt. Port 3 zu VLAN 3, etc.
Dann noch für jedes VLAN dem Switch eine Interface IP 192.168.x.254/24 zugeordnet. Für VLAN1 hat der Switch 10.0.0.254/24 als Interface-IP.
Das mit dem VLAN scheint auch zu funktionieren, da ich am jeweiligen Switch-Port die entsprechende Switch-Interface-IP (und nur diese) anpingen kann, sofern ich hierzu dem Test-Client manuell eine passende IP-Adresse aus dem gleichen Subnet zuweise.
Der DHCP-Server ist an einem "normalen", nicht speziell konfigurierten Port angeschlossen - also Trunk+VLAN1 (die Grundeinstellung aller Ports). Die Netzwerkkonfiguration lautet IP 10.0.0.110, SN 255.255.255.0, GW 10.0.0.1 (eine Sonicwall über die das Internet läuft), DNS 10.0.0.109 (DC+DNS-Server).
Der nächste Schritt ist die Einrichtung des DHCP-Replays. Dazu habe ich die Firmware + Bootloader aktualisiert und den Switch auf Layer3-Modus umgeschaltet.
Dann DHCP-Relay generell und für VLAN 2+3+4 aktiviert. Für VLAN1 nicht. da es dort ja ohne Relay funktionieren sollte.
Laut Wireshark kommen dann am DHCP-Server auch die Anfragen an, allerdings scheint die Antwort des DHCP-Servers nicht mehr vom DHCP-Relay empfangen zu werden. Die Pakete werden dabei lt. Wireshark vom DHCP-Server an 192.168.x.254 geschickt - also die Switch-Interface-IP für das gewünschte VLAN-Subnet.
Offenbar ist der Switch nicht in der Lage diese Antwort auszuwerten, wenn diese nun an das Gateway 10.0.0.1 rausgeht (da 192.168.x.254 nicht zum Subnet des DHCP-Servers gehört).
Stelle ich am DHCP-Server das Gateway von 10.0.0.1 auf 10.0.0.254 (und somit die Interface-IP des Switches) um, funktioniert es. Alternativ kann ich am DHCP-Server auch manuelle Routen in der Form 192.168.x.254, 255.255.255.255 -> 10.0.0.254 anlegen.
Ist das normal und der vorgesehene Weg? In allen Guides die ich zu dem Thema gelesen habe, war das manuelle Anlegen von Routen und der Rückweg der DHCP-Pakete zum DHCP-Relay nie ein Thema. Auch würde ich davon ausgehen, dass der Switch das Antwortpaket, das ihn durchläuft auch abfangen kann, wenn es an Gateway 10.0.0.1 geschickt wird. Anhand der Transaktions-ID müsste das DHCP-Relay bzw. der Switch doch auch erkennen, dass es sich dabei um die Antwort zu seiner verarbeiteten Anfrage handelt? Und die Ziel-IP ist ja ebenfalls die dem Switch bekannte Interface-IP, die er für die Anfrage selbst benutzt hat.
Habe ich irgendwo einen Denkfehler und die Funktionsweise des DHCP-Relays falsch verstanden oder fehlt noch eine bestimmte Einstellung bzgl. DHCP-Relay und oder VLANs? Muss man tatsächlich selbst für das Routing der Antwort-Pakete sorgen und reicht es nicht, wenn diese einfach nur den Switch durchlaufen?
Über Antworten würde ich mich freuen - gerne auch mit Verbesserungsvorschlägen zum generellen Aufbau der Lösung.
ich habe momentan das erste Mal mit einer Umgebung mit VLANs zu tun.
Dabei stellt sich folgende Anforderung:
Ein einzelner Windows 2012R2 DHCP Server soll Clients in verschiedenen Subnetzen (die sich in eigenen VLANs befinden) bedienen. Die VLANs sollen so weit wie möglich abgeschottet sein und idealerweise gar nicht untereinander geroutet sein.
Daher habe ich am DHCP-Server mehrere Scopes (192.168.2.0/24, 192.168.3.0/24, 192.168.4.0/24) erstellt und mit der gewünschten Konfiguration versehen. Zunächst soll im Testaufbau einfach nur eine IP 192.168.x.100-149, Subnetmask 255.255.255.0, Gateway 192.168.x.1 vergeben werden.
Am Switch habe ich für diesen Test Port 2 zum VLAN 2 hinzugefügt und den Typ auf Access/untagged eingestellt. Port 3 zu VLAN 3, etc.
Dann noch für jedes VLAN dem Switch eine Interface IP 192.168.x.254/24 zugeordnet. Für VLAN1 hat der Switch 10.0.0.254/24 als Interface-IP.
Das mit dem VLAN scheint auch zu funktionieren, da ich am jeweiligen Switch-Port die entsprechende Switch-Interface-IP (und nur diese) anpingen kann, sofern ich hierzu dem Test-Client manuell eine passende IP-Adresse aus dem gleichen Subnet zuweise.
Der DHCP-Server ist an einem "normalen", nicht speziell konfigurierten Port angeschlossen - also Trunk+VLAN1 (die Grundeinstellung aller Ports). Die Netzwerkkonfiguration lautet IP 10.0.0.110, SN 255.255.255.0, GW 10.0.0.1 (eine Sonicwall über die das Internet läuft), DNS 10.0.0.109 (DC+DNS-Server).
Der nächste Schritt ist die Einrichtung des DHCP-Replays. Dazu habe ich die Firmware + Bootloader aktualisiert und den Switch auf Layer3-Modus umgeschaltet.
Dann DHCP-Relay generell und für VLAN 2+3+4 aktiviert. Für VLAN1 nicht. da es dort ja ohne Relay funktionieren sollte.
Laut Wireshark kommen dann am DHCP-Server auch die Anfragen an, allerdings scheint die Antwort des DHCP-Servers nicht mehr vom DHCP-Relay empfangen zu werden. Die Pakete werden dabei lt. Wireshark vom DHCP-Server an 192.168.x.254 geschickt - also die Switch-Interface-IP für das gewünschte VLAN-Subnet.
Offenbar ist der Switch nicht in der Lage diese Antwort auszuwerten, wenn diese nun an das Gateway 10.0.0.1 rausgeht (da 192.168.x.254 nicht zum Subnet des DHCP-Servers gehört).
Stelle ich am DHCP-Server das Gateway von 10.0.0.1 auf 10.0.0.254 (und somit die Interface-IP des Switches) um, funktioniert es. Alternativ kann ich am DHCP-Server auch manuelle Routen in der Form 192.168.x.254, 255.255.255.255 -> 10.0.0.254 anlegen.
Ist das normal und der vorgesehene Weg? In allen Guides die ich zu dem Thema gelesen habe, war das manuelle Anlegen von Routen und der Rückweg der DHCP-Pakete zum DHCP-Relay nie ein Thema. Auch würde ich davon ausgehen, dass der Switch das Antwortpaket, das ihn durchläuft auch abfangen kann, wenn es an Gateway 10.0.0.1 geschickt wird. Anhand der Transaktions-ID müsste das DHCP-Relay bzw. der Switch doch auch erkennen, dass es sich dabei um die Antwort zu seiner verarbeiteten Anfrage handelt? Und die Ziel-IP ist ja ebenfalls die dem Switch bekannte Interface-IP, die er für die Anfrage selbst benutzt hat.
Habe ich irgendwo einen Denkfehler und die Funktionsweise des DHCP-Relays falsch verstanden oder fehlt noch eine bestimmte Einstellung bzgl. DHCP-Relay und oder VLANs? Muss man tatsächlich selbst für das Routing der Antwort-Pakete sorgen und reicht es nicht, wenn diese einfach nur den Switch durchlaufen?
Über Antworten würde ich mich freuen - gerne auch mit Verbesserungsvorschlägen zum generellen Aufbau der Lösung.
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 290606
Url: https://administrator.de/contentid/290606
Ausgedruckt am: 26.11.2024 um 15:11 Uhr
3 Kommentare
Neuester Kommentar
Hi,
in folgender Anleitung https://www.linuxmuster.net/wiki/dokumentation:addons:subnetting:l3switc ...
solltest du alles nötige finden ...
Beste Grüße aus Karlsruhe,
Chris
in folgender Anleitung https://www.linuxmuster.net/wiki/dokumentation:addons:subnetting:l3switc ...
solltest du alles nötige finden ...
Beste Grüße aus Karlsruhe,
Chris
Hi,
da ich mit den SG-Series leider keine Erfahrungen auf diesem Gebiet gemacht habe, kann ich dir nur empfehlen dich an die Anleitung zu hängen, welche ich dir gesendet habe.
Es ist so ...
DHCP hat noch nicht aber wirklich nichts mit IPs zu tun, ergo auch nicht mit routing und co, da dass ja - wie du sicherlich weisst - auf L2 passiert.
Was du mit dem Standard-GW aber machst, ist dem Server sagen, dass er auch alle BCs und somit L2 Anfragen/antworten an die MAC des GW senden soll. Daher wird das dann AFAIK funktionieren....
In deinem einleitenden Text schreibst du, dass du in VLAN1, also jenem, in welchem der DHCP Server sitzt, das DHCP-relaying nicht aktiviert hast.
In der Anleitung steht allerdings ganz klar, dass man das auch da aktivieren soll. https://www.linuxmuster.net/wiki/_detail/dokumentation:addons:subnetting ...
Nun ist es so, dass man bei FullManaged-Switchen (cisco wie Hp) immer eine sg. dhcp-helper option auf dem "Coreswitch" also, jenem welche alle VLANs kennt und erreichen kann, aktivieren muss. Ich denke, dass die Option "DHCP-Relaying" auf dem SG-Switch diese Option beinhaltet. Probiere doch einfach mal aus, diese Option auch für VLAN1 zu aktivieren.
Probiers doch einfach mal so, wie es da drin steht. habe leider nicht die Möglichkeit das mit einem SG-Switch nachzubauen.
Grüße aus Karlsruhe,
Chris
da ich mit den SG-Series leider keine Erfahrungen auf diesem Gebiet gemacht habe, kann ich dir nur empfehlen dich an die Anleitung zu hängen, welche ich dir gesendet habe.
Es ist so ...
DHCP hat noch nicht aber wirklich nichts mit IPs zu tun, ergo auch nicht mit routing und co, da dass ja - wie du sicherlich weisst - auf L2 passiert.
Was du mit dem Standard-GW aber machst, ist dem Server sagen, dass er auch alle BCs und somit L2 Anfragen/antworten an die MAC des GW senden soll. Daher wird das dann AFAIK funktionieren....
In deinem einleitenden Text schreibst du, dass du in VLAN1, also jenem, in welchem der DHCP Server sitzt, das DHCP-relaying nicht aktiviert hast.
In der Anleitung steht allerdings ganz klar, dass man das auch da aktivieren soll. https://www.linuxmuster.net/wiki/_detail/dokumentation:addons:subnetting ...
Nun ist es so, dass man bei FullManaged-Switchen (cisco wie Hp) immer eine sg. dhcp-helper option auf dem "Coreswitch" also, jenem welche alle VLANs kennt und erreichen kann, aktivieren muss. Ich denke, dass die Option "DHCP-Relaying" auf dem SG-Switch diese Option beinhaltet. Probiere doch einfach mal aus, diese Option auch für VLAN1 zu aktivieren.
Probiers doch einfach mal so, wie es da drin steht. habe leider nicht die Möglichkeit das mit einem SG-Switch nachzubauen.
Grüße aus Karlsruhe,
Chris