9
CISCO SG500-28 DHCP-Raly für zweites Subnetz
Hallo zusammen,
ich stehe gerade etwas auf dem Schlauch. Ich wollte per DHCP-Relay Funktion auf dem Cisco-Switch aus dem 2. Subnetz eine IP per DHCP beziehen lassen.
VLAN1 (Default): 192.168.8.0/24
GW: 192.168.8.254/24 (eine Hardware Firewall mit Statischer Route ins 192.168.10.0/24)
DHCP: 192.168.8.1/24
VLAN10 : 192.168.10.0/24
GW/IP-VLAN10: 192.168.10.254/24
Ich kann sowohl aus dem 192.168.10.0/24 ins 192.168.8.0/24 pingen als auch umgekehrt.
Soweit so gut, wenn ich jetzt Wireshark anstarte, sehe ich dass:
1. Ein DHCPDISCOVER gesendet und auch am DHCP-Server ankommt. Die Anfrage kommt von der 192.168.10.254/24.
2. Der DHCP macht auch einen OFFER aus dem Pool den ich angelegt habe. Destination 192.168.10.254/24
3. Der OFFER kommt aber nie beim Client an.
Sowohl den DHCP-Relay als auch Option 82 sind aktiviert. Den UDP Relay/IP-Helper kann ich nicht auf die DHCP-Ports einstellen, da auch in der Anleitung steht, dass die DHCP-Relay Funktion dafür benutzt werden soll.
Wo kann ich noch ansetzen um den Fehler zu finden?
Vielen Dank und schöne Grüße
BruisE
EDIT:
ich stehe gerade etwas auf dem Schlauch. Ich wollte per DHCP-Relay Funktion auf dem Cisco-Switch aus dem 2. Subnetz eine IP per DHCP beziehen lassen.
VLAN1 (Default): 192.168.8.0/24
GW: 192.168.8.254/24 (eine Hardware Firewall mit Statischer Route ins 192.168.10.0/24)
DHCP: 192.168.8.1/24
VLAN10 : 192.168.10.0/24
GW/IP-VLAN10: 192.168.10.254/24
Ich kann sowohl aus dem 192.168.10.0/24 ins 192.168.8.0/24 pingen als auch umgekehrt.
Soweit so gut, wenn ich jetzt Wireshark anstarte, sehe ich dass:
1. Ein DHCPDISCOVER gesendet und auch am DHCP-Server ankommt. Die Anfrage kommt von der 192.168.10.254/24.
2. Der DHCP macht auch einen OFFER aus dem Pool den ich angelegt habe. Destination 192.168.10.254/24
3. Der OFFER kommt aber nie beim Client an.
Sowohl den DHCP-Relay als auch Option 82 sind aktiviert. Den UDP Relay/IP-Helper kann ich nicht auf die DHCP-Ports einstellen, da auch in der Anleitung steht, dass die DHCP-Relay Funktion dafür benutzt werden soll.
Wo kann ich noch ansetzen um den Fehler zu finden?
Vielen Dank und schöne Grüße
BruisE
EDIT:
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 257665
Url: https://administrator.de/forum/cisco-sg500-28-dhcp-raly-fuer-zweites-subnetz-257665.html
Ausgedruckt am: 23.12.2024 um 13:12 Uhr
9 Kommentare
Neuester Kommentar
Du routest also ausdrücklich NICHT über den L3 Switch was eigentlich möglich wäre sondern fest rein über die Firewall, richtig ?
Wenn dem so ist kann die DHCP Relay Funktion über den Switch ja niemals funktionieren, denn das würde zwingend ein Routing über den Switch erfordern was der SG-500 ja kann du aber wohl explizit nicht willst da du ja dort eine Firewall einsetzt.
Folglich darfst du niemals in dem VLAN 1 und 10 eine IP auf dem Switch vergeben !! Das ist vermutlich dein erster Fehler !
IP Adressen dürfen also rein nur die Firewall Interfaces haben in diesen beiden VLANs, die dann auch die Gateway IPs der Endgeräte in diesen VLANs darstellen...logisch !
Daraus ergibt sich dann zwangsläufig das du die DHCP Releay Funktion auch auf der Firewall aktivieren musst, denn die routet den Traffic ja auch zw. VLAN 1 und 10.
Eine Relay Funktion ist immer auch an das Routing gebunden. Das ist dein fataler Denkfehler den du hier gemacht hast im Design.
Wenn dem so ist kann die DHCP Relay Funktion über den Switch ja niemals funktionieren, denn das würde zwingend ein Routing über den Switch erfordern was der SG-500 ja kann du aber wohl explizit nicht willst da du ja dort eine Firewall einsetzt.
Folglich darfst du niemals in dem VLAN 1 und 10 eine IP auf dem Switch vergeben !! Das ist vermutlich dein erster Fehler !
IP Adressen dürfen also rein nur die Firewall Interfaces haben in diesen beiden VLANs, die dann auch die Gateway IPs der Endgeräte in diesen VLANs darstellen...logisch !
Daraus ergibt sich dann zwangsläufig das du die DHCP Releay Funktion auch auf der Firewall aktivieren musst, denn die routet den Traffic ja auch zw. VLAN 1 und 10.
Eine Relay Funktion ist immer auch an das Routing gebunden. Das ist dein fataler Denkfehler den du hier gemacht hast im Design.
Ich wollte unser 24er Netz etwas auseinander pflücken, da unsere IP-Adressen langsam ausgehen. Mein Gedanke war erst einmal die DHCP-Geräte auf ein eigenes Subnetz zu nehmen (VLAN10).
Wir haben im 192.168.8.0/24 unser jetztiges Netz den Standardgateway: 192.168.8.254, was auch unsere Firewall nach aussen ist.
Der SG-500 ist nicht direkt an der Firewall angeschlossen und hat die 192.168.8.25/24. Nun habe ich dem VLAN10 die 192.168.10.254/24 zugeordnet.
Auf der Firewall musste ich aber eine Route hinterlegen, alles was ins 192.168.10.0/24 geht muss vom 192.168.8.25 (Cisco Switch auf dem VLAN10 konfiguriert ist) geroutet werden. Somit müsste doch nun der Switch das InterVLAN-Routing übernehmen?
Wir haben im 192.168.8.0/24 unser jetztiges Netz den Standardgateway: 192.168.8.254, was auch unsere Firewall nach aussen ist.
Der SG-500 ist nicht direkt an der Firewall angeschlossen und hat die 192.168.8.25/24. Nun habe ich dem VLAN10 die 192.168.10.254/24 zugeordnet.
Auf der Firewall musste ich aber eine Route hinterlegen, alles was ins 192.168.10.0/24 geht muss vom 192.168.8.25 (Cisco Switch auf dem VLAN10 konfiguriert ist) geroutet werden. Somit müsste doch nun der Switch das InterVLAN-Routing übernehmen?
Hallo,
Vielleicht mal ein Blatt Papier nehmen, aufmalen, einscannen und hier hochladen.
Gruß,
Peter
Zitat von @BruisE:
Der SG-500 ist nicht direkt an der Firewall angeschlossen und hat die 192.168.8.25/24.
Wo ist er denn dann dran und warum hat der eine IP aus dem Netz deiner Firewall?Der SG-500 ist nicht direkt an der Firewall angeschlossen und hat die 192.168.8.25/24.
Vielleicht mal ein Blatt Papier nehmen, aufmalen, einscannen und hier hochladen.
Gruß,
Peter
Der Switch hängt über andere Switches indirekt an der Firewall. Eben halt nicht direkt FW -> CiscoSW sondern FW -> SW -> CiscoSW.
Werde aber gerne noch ein Blatt und Stift in die Hand nehmen und aufzeichnen :D
Werde aber gerne noch ein Blatt und Stift in die Hand nehmen und aufzeichnen :D
Hallo,
Haben diese anderen Switche irgendein Einfluss darauf außer das die Hops steigen? Dann ist es für dein Routing unwichtig (und für uns), außer deine VLANs werden dort....
Gruß,
Peter
Haben diese anderen Switche irgendein Einfluss darauf außer das die Hops steigen? Dann ist es für dein Routing unwichtig (und für uns), außer deine VLANs werden dort....
Werde aber gerne noch ein Blatt und Stift in die Hand nehmen und aufzeichnen :D
Ja, tu das Gruß,
Peter
Die Segmentierung ist erstmal eine gute Sache und der richtige Weg für ein Redesign, keine Frage !
Der SG-500 sollte der Core Switch sein an dem alle anderen Switches dranhängen.
Um das aber generell erstmal zum Fliegen zu bekommen musst du das lokale Routing umstellen und komplett auf den L3 Switch, sprich den SG 500 verlegen.
Dazu gehst du folgendermaßen vor:
Und nun funktioniert auch den DHCP Relay mit dem DHCP Server im .8.0er IP Segment !!
Der SG-500 sollte der Core Switch sein an dem alle anderen Switches dranhängen.
Um das aber generell erstmal zum Fliegen zu bekommen musst du das lokale Routing umstellen und komplett auf den L3 Switch, sprich den SG 500 verlegen.
Dazu gehst du folgendermaßen vor:
- VLAN 1 mit der IP 192.168.8.0 /24 gibt es ja schon
- VLAN 10 anlegen und Ports für die Endgeräte zuweisen
- Alle Uplinks die zu anderen Switches gehen tagged für das VLAN 10 einstellen, damit das VLAN 10 auch über die anderen Switches gelegt werden kann und dort verfügbar ist. OK, das klappt natürlich nur wenn diese auch managebar sind ?! Sollten sie das nicht sein kannst du immer nur einen gesamten solchen Switch entweder in VLAN 1 oder 10 betreiben, klar.
- Auf dem SG-500 muss nun eine IP im VLAN 1 und eine im VLAN 10 konfiguriert werden. Z.B. 192.168.8.25 /24 was du ja schon gemacht hast für VLAN 1 und dann z.B. 192.168.10.25 /24 für VLAN 10. Generell solltest du Router immer an die oberste oder unterste IP setzen damit sie nicht mittendrin liegen. .1 in beiden Netzen wäre kosmetisch sinnvoller. Das ist aber kein Muss sondern dient der Sicherheit und Übersichtlichkeit.
- Alle Endgeräte im VLAN 1 bekommen jetzt NICHT die .254 als Gateway sondern immer die .8.25 (Switch)
- Alle Endgeräte im VLAN 10 bekommen die .10.25 als Gateway ! (Switch)
- Der Switch bekommt eine Default Route auf die 192.168.8.254
- Der Internet Router eine statische Route: Zielnetz: 192.168.10.0, Maske 255.255.255.0, Gateway: 192.168.8.25
- Fertig !
Und nun funktioniert auch den DHCP Relay mit dem DHCP Server im .8.0er IP Segment !!
Schönen guten Morgen zusammen,
ich habe mal eine kleine Zeichnung angehängt zur Visualisierung.
Danke aqui für die Liste, leider kann ich da nur einen Punkt nicht mit "Check" beantworten und zwar ist es kein Core-Switch und kann als solcher vorerst auch nicht fungieren (und die Uplinkports sind nicht getagt, brauche ich soweit noch nicht).
Ich wollte eine kleine Testumgebung aufbauen und die ganze DHCP aus anderem Subnetz testen. In Theorie immer einfach, hier und da durch "Misskonfiguration" oder nicht kompatibler Gerätschaften halt lieber einmal ausgetestet.
- VLAN10 hat die 192.168.10.254/24 und umfasst die Porst gi1/1/7-10.
- VLAN1 (default) hat das Management interface 192.168.8.25/24 und einen Standardgateway 192.168.8.254/24
- Die Firewall/Gateway mit der 192.168.8.254 hat eine Route für das Netz 192.168.10.0/24 nach 192.168.8.25/24
- Der DHCP hat einen zusätzlichen Pool 192.168.10.10 bis 192.168.10.100 mit GW-Adresse 192.168.10.254/24
- Aus dem VLAN10 kann ins 192.168.8.0/24 Netz gepingt werden und vice versa.
- Nun macht der Client einen DHCP-DISCOVER der kommt auf 192.168.8.1 an von der Quelle 192.168.10.254.
- Der DHCP macht ein OFFER aus dem neuen Pool an die 192.168.10.254.
- Am VLAN10 Client kommt das OFFER Paket aber nie an (bleibt scheinbar irgendwo am Switch kleben).
Edit:
Ein Tracert auf 192.168.10.5 (feste IP Client) von 192.168.8.104 geht über
1. 192.168.8.254
2. 192.168.10.254
3. 192.168.10.5
ich habe mal eine kleine Zeichnung angehängt zur Visualisierung.
Danke aqui für die Liste, leider kann ich da nur einen Punkt nicht mit "Check" beantworten und zwar ist es kein Core-Switch und kann als solcher vorerst auch nicht fungieren (und die Uplinkports sind nicht getagt, brauche ich soweit noch nicht).
Ich wollte eine kleine Testumgebung aufbauen und die ganze DHCP aus anderem Subnetz testen. In Theorie immer einfach, hier und da durch "Misskonfiguration" oder nicht kompatibler Gerätschaften halt lieber einmal ausgetestet.
- VLAN10 hat die 192.168.10.254/24 und umfasst die Porst gi1/1/7-10.
- VLAN1 (default) hat das Management interface 192.168.8.25/24 und einen Standardgateway 192.168.8.254/24
- Die Firewall/Gateway mit der 192.168.8.254 hat eine Route für das Netz 192.168.10.0/24 nach 192.168.8.25/24
- Der DHCP hat einen zusätzlichen Pool 192.168.10.10 bis 192.168.10.100 mit GW-Adresse 192.168.10.254/24
- Aus dem VLAN10 kann ins 192.168.8.0/24 Netz gepingt werden und vice versa.
- Nun macht der Client einen DHCP-DISCOVER der kommt auf 192.168.8.1 an von der Quelle 192.168.10.254.
- Der DHCP macht ein OFFER aus dem neuen Pool an die 192.168.10.254.
- Am VLAN10 Client kommt das OFFER Paket aber nie an (bleibt scheinbar irgendwo am Switch kleben).
Edit:
Ein Tracert auf 192.168.10.5 (feste IP Client) von 192.168.8.104 geht über
1. 192.168.8.254
2. 192.168.10.254
3. 192.168.10.5
leider kann ich da nur einen Punkt nicht mit "Check" beantworten und zwar ist es kein Core-Switch und kann als solcher vorerst auch nicht fungieren
Das ist erstmal kein Hinderniss und fürs Design mehr oder weniger egal. Dir muss aber klar sein das die DHCP Relay Funktion einzig und allein nur da ausgeführt werden kann wo auch das Routing passiert !Was de facto nicht geht ist das Routing von Komponente X machen zu lassen und das DHCP Relay von Komponente Y. Das supportet kein Hersteller und ist auch protokolltechnisch so nicht vorgesehen und wird von vorn herein scheitern.
Noch ein Paar Fragen zu deinem Testsetup von oben:
- VLAN10 hat die 192.168.10.254/24 und umfasst die Porst gi1/1/7-10.
Was meinst du mit der IP ist das die Switch IP in diesem VLAN ? Also die Gateway IP für Clients in diesem VLAN 10 wenn der Switch VLAN Router also L3 Switch ist ?
- VLAN1 (default) hat das Management interface 192.168.8.25/24 und einen Standardgateway 192.168.8.254/24
Was meinst du mit Standardgateway hier ?? Normal ist das das Default Gateway für den Switch gilt das Gateway für alle IP Netze und logischerweise nicht nur für das VLAN 1
- Die Firewall/Gateway mit der 192.168.8.254 hat eine Route für das Netz 192.168.10.0/24 nach 192.168.8.25/24
Das ist korrekt !
- Der DHCP hat einen zusätzlichen Pool 192.168.10.10 bis 192.168.10.100 mit GW-Adresse 192.168.10.254/24
Korrekt wenn du mit Gateway IP die meinst die die Cliwents nachher vom DHCP Server bekommen.
- Aus dem VLAN10 kann ins 192.168.8.0/24 Netz gepingt werden und vice versa.
War zu erwarten
Ein Tracert auf 192.168.10.5 (feste IP Client) von 192.168.8.104 geht über 1. 192.168.8.254
Und das ist nicht ganz korrekt oder wäre besser wenn ALLEn Clients den Switch also die 192.168.8.25 als default Gateway hätten. Das würde auch das Relay Problem egalisieren.
Generell zentralisiert man das Default Gateway immer auf eine feste Maschine und NICHT auf unterschiedliche wie bei dir.
Da du DHCP machst kannst du die Gateway Änderung mit einem Mausklick an die Clients verändern. Das kannst du sogar während des Betriebs machen.
Clients nutzen dann zentral den Switch, bekommen von dem aber wenn das Routing direkt geht ein ICMP Redirect gesendet das sie die Firewall direkt erreichen können und sprechen sie danach dann direkt an ohne den Hop über den Switch.
Das wäre ein sauberes L3 Design und solltest du besser auch so ändern !
Erst einmal wünsche ich allen ein schönes neues Jahr (habe mich ja wieder lange nicht gemeldet).
Ich habe mein Problem lösen können und zwar habe ich für unsere Firewall (Sophos UTM) etwas im Manual gesucht und bin über das DHCP-Relay gestolpert.
Ebenso unterstützt die Firewall VLANs. Somit konnte ich nun schön alles über die Firewall umsetzten und kann so auch gleich den Zugriff auf die verschiedenen Netzte über die FW-Regeln einschränken und muss keine ACLs definieren.
Nun habe ich auch das Routing da wo ich es haben wollte und natürlich das DHCP-Relay auch.
Vielen Dank noch einmal an die Beteiligten für die super Unterstützung!!!
Ich habe mein Problem lösen können und zwar habe ich für unsere Firewall (Sophos UTM) etwas im Manual gesucht und bin über das DHCP-Relay gestolpert.
Ebenso unterstützt die Firewall VLANs. Somit konnte ich nun schön alles über die Firewall umsetzten und kann so auch gleich den Zugriff auf die verschiedenen Netzte über die FW-Regeln einschränken und muss keine ACLs definieren.
Nun habe ich auch das Routing da wo ich es haben wollte und natürlich das DHCP-Relay auch.
Vielen Dank noch einmal an die Beteiligten für die super Unterstützung!!!
