FritzBox, pfSense und VLAN am Cisco SG200-08
Hallo Forum,
vor etwa 4 Wochen habe ich erfolgreich pfSense (latest Version - 2.7.2) auf einer Sophos Appliance installiert. Dies ist eine SG135 in Rev. 2
Die Portbezeichnungen auf der Rückseite findet man in der pfSense wie nachfolgend aufgeführt wieder:
- WAN -> igb4
- LAN -> igb5
- DMZ -> igb6
- HA -> igb7
- ETH4 - > igb0
- ETH5 -> igb1
- ETH6 -> igb2
- ETH7 -> igb3
Diese 8 Ports, möchte ich gerne wie folgt verwenden:
VLANS
für jedes VLAN habe ich auf der pfSense entsprechend einen DHCP Server gestartet und lasse die Range 10.10.10.100 - 10.10.10.199 verteilen. Die Range ist für alle VLANS gleich.
In jedem VLAN existiert eine "Allow Any" Rule.. der Traffic wird protokolliert.
Jetzt versuche ich mich daran, die VLANS auf dem Switch bereitzustellen, das funktioniert aber nicht, so wie ich es mit dachte. Der Switch erhält aus dem VLAN 99, welches untagged auf Port 8 am Switch ankommt, keine IP Adresse via DHCP der pfSense. Ein Client am Switch welcher in das VLAN 10 - 50 kommen soll, erhält ebenfalls keine IP Adresse.
Wie in den Bildern zu sehen, habe ich korrekt die VLANS auf dem Switch konfiguriert.
Der Switch hat leider nur WebGUI und keine CLI ...
Kann mir jemand sagen, wo mein Fehler liegt?
Besten Dank schon jetzt
VG Alexander
vor etwa 4 Wochen habe ich erfolgreich pfSense (latest Version - 2.7.2) auf einer Sophos Appliance installiert. Dies ist eine SG135 in Rev. 2
Die Portbezeichnungen auf der Rückseite findet man in der pfSense wie nachfolgend aufgeführt wieder:
- WAN -> igb4
- LAN -> igb5
- DMZ -> igb6
- HA -> igb7
- ETH4 - > igb0
- ETH5 -> igb1
- ETH6 -> igb2
- ETH7 -> igb3
Diese 8 Ports, möchte ich gerne wie folgt verwenden:
- WAN Port -> an eine FritzBox angeschlossen (IP Bereich 192.168.123.0/24
- LAN Port verteilt erfolgreich IP Adressen über DHCP der pfSense aus dem Bereich 192.168.100.0/24 - dieser Port soll nur zur Konfiguration der pfSense genutzt werden
- ETH4 -> hier stelle ich über die pfSense ein paar VLANS bereit -> es ist hier ein Cisco SG200-08 angeschlossen.
VLANS
- VLAN 10 - 10.10.10.0/24 (geplant - Telefonie DECT der FritzBox)
- VLAN 20 - 10.10.20.0/24(gemeinsam genutze Geräte Drucker, Scanner)
- VLAN 30 - 10.10.30.0/24 (Clients)
- VLAN 40 - 10.10.40.0/24 (geplant Proxmox VMs, CTs)
- VLAN 50 - 10.10.50.0/24 (IoT)
- VLAN 99 - 10.10.99.0/24 (das Management VLAN)
für jedes VLAN habe ich auf der pfSense entsprechend einen DHCP Server gestartet und lasse die Range 10.10.10.100 - 10.10.10.199 verteilen. Die Range ist für alle VLANS gleich.
In jedem VLAN existiert eine "Allow Any" Rule.. der Traffic wird protokolliert.
Jetzt versuche ich mich daran, die VLANS auf dem Switch bereitzustellen, das funktioniert aber nicht, so wie ich es mit dachte. Der Switch erhält aus dem VLAN 99, welches untagged auf Port 8 am Switch ankommt, keine IP Adresse via DHCP der pfSense. Ein Client am Switch welcher in das VLAN 10 - 50 kommen soll, erhält ebenfalls keine IP Adresse.
Wie in den Bildern zu sehen, habe ich korrekt die VLANS auf dem Switch konfiguriert.
Der Switch hat leider nur WebGUI und keine CLI ...
Kann mir jemand sagen, wo mein Fehler liegt?
Besten Dank schon jetzt
VG Alexander
Kommentieren
Teilen
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 672639
Url: https://administrator.de/forum/fritzbox-pfsense-und-vlan-am-cisco-sg200-08-672639.html
Ausgedruckt am: 19.05.2025 um 09:05 Uhr
21 Kommentare
Neuester Kommentar
Das Foren Tutorial zu der Thematik hast du gewissenhaft gelesen und auch genau so umgesetzt??
VLAN Installation und Routing mit pfSense, Mikrotik, DD-WRT oder Cisco RV Routern
Die pfSense am anderen Ende sendet UNtagged Traffic nur vom physischen Parent Interface für den Trunk.
Bei dir ist das igb0 Interface was du aber gar nicht als aktiven Port im Interface Assignment der pfsense Firwall aktiviert hast. 🤔 Wie du ja selber siehst steht es noch unter "verfügbare" Interfaces und ist damit inaktiv.
Mit anderen Worten:
Der igb0 Port ist also in deinem Setup gar nicht als aktives Interface auf der Firewall definiert und damit physisch gar nicht verfügbar!
Wenn dieses Parent Interface damit generell deaktiviert ist, können logischerweise auch niemals die darauf aufsetzenden VLAN Interfaces aktiv werden die ja diesem physischen Parent Interface zugeordnet sind.
Es war also zu erwarten das dein Setup durch diesen Administrator Fauxpas dann von vorn herein scheitert.
Deine ToDos:
Mit dem Rüstzeug solltest du das Setup im Handumdrehen zum Fliegen bringen!
Tip:
Je nach Traffic Volumen zwischen den VLANs wäre es aus Performance und Redundanz Sicht etwas vorteilhafter du würdest die pfSense mit einem LACP LAG anbinden.
Dann würde sich der VLAN interne Traffic auf 2 (oder mehr) Links verteilen bei gleichzeitiger Leitungsredundanz.
Ist der VLAN interne Traffic lediglich sehr gering wäre dies nicht zwingend nötig.
Alle Details, auch zu diesem Setup, beschreibt ein separates Tutorial:
Link Aggregation (LAG) im Netzwerk
VLAN Installation und Routing mit pfSense, Mikrotik, DD-WRT oder Cisco RV Routern
Der Switch erhält aus dem VLAN 99, welches untagged auf Port 8 am Switch ankommt, keine IP Adresse via DHCP der pfSense.
Das ist vermutlich auch normal, denn du hast sicher nicht bedacht das das Management Interface des Switches UNtagged in VLAN 1 liegt wenn du es nicht umstellst.Die pfSense am anderen Ende sendet UNtagged Traffic nur vom physischen Parent Interface für den Trunk.
Bei dir ist das igb0 Interface was du aber gar nicht als aktiven Port im Interface Assignment der pfsense Firwall aktiviert hast. 🤔 Wie du ja selber siehst steht es noch unter "verfügbare" Interfaces und ist damit inaktiv.
Mit anderen Worten:
Der igb0 Port ist also in deinem Setup gar nicht als aktives Interface auf der Firewall definiert und damit physisch gar nicht verfügbar!
Wenn dieses Parent Interface damit generell deaktiviert ist, können logischerweise auch niemals die darauf aufsetzenden VLAN Interfaces aktiv werden die ja diesem physischen Parent Interface zugeordnet sind.
Es war also zu erwarten das dein Setup durch diesen Administrator Fauxpas dann von vorn herein scheitert.
Deine ToDos:
- Aktiviere in den "Assignments" das physische Firewall Interface igb0 für den Trunk Link auf den Switch
- Konfiguriere deine VLAN 99 Management IP und DHCP Server auf dem igb0 Trunk Interface auf der FW.
- Setze das Switch Management Interface von VLAN 1 ins VLAN 99. Diesen Schritt kannst du dir auch sparen wenn du damit leben kannst das das Management IP Netz im VLAN 1 aktiv ist.
Mit dem Rüstzeug solltest du das Setup im Handumdrehen zum Fliegen bringen!
Tip:
Je nach Traffic Volumen zwischen den VLANs wäre es aus Performance und Redundanz Sicht etwas vorteilhafter du würdest die pfSense mit einem LACP LAG anbinden.
Dann würde sich der VLAN interne Traffic auf 2 (oder mehr) Links verteilen bei gleichzeitiger Leitungsredundanz.
Ist der VLAN interne Traffic lediglich sehr gering wäre dies nicht zwingend nötig.
Alle Details, auch zu diesem Setup, beschreibt ein separates Tutorial:
Link Aggregation (LAG) im Netzwerk
Switch und Management IP ist eine Geschichte für sich. VLAN 1 ist Default. Das kann man meist an einer Stelle umstellen.
Kenne das Modell nicht. Management IP und VLAN sind hier die Optionen die du prüfen musst.
Generell kannst du 99 ohne switch testen. Nimm einen Laptop und prüfe trivial in der eine bekommt. Tags werden ignoriert.
Du hast VLAN 1 ausgeklammert. Damit 99 die Aufgabe übernehmen kann muss es untagged aus der Sophos kommen. Wäre dann also ein opt Netz am Port. Untagged...
Normal ist es ja in vielen Dokus vlan 1. Nur das ist LAN.
99 muss hier wie LAN raus gehen. Untagged
Kenne das Modell nicht. Management IP und VLAN sind hier die Optionen die du prüfen musst.
Generell kannst du 99 ohne switch testen. Nimm einen Laptop und prüfe trivial in der eine bekommt. Tags werden ignoriert.
Du hast VLAN 1 ausgeklammert. Damit 99 die Aufgabe übernehmen kann muss es untagged aus der Sophos kommen. Wäre dann also ein opt Netz am Port. Untagged...
Normal ist es ja in vielen Dokus vlan 1. Nur das ist LAN.
99 muss hier wie LAN raus gehen. Untagged
Untagged port ist immer normal.
Wenn der am switch vlan 1 Untagged ist, würde das 99 auf 1 übersetzt.
99U
4711U
42U
Schall und Rauch. Das du vlan 1 nicht nimmst ist gut. So kann man später nicht aus Versehen was zusammen stecken....
Nur 99U wäre an der pfsense sowas wie
LAN99
Das direkt nur als Schnittstellen Namen sehen! Untagged. Der Rest müsste dann passen.
Man kann durch so eine Verkabelung VLAN id's komplett ändern. Macht nur Chaos.
Bei deiner jetzigen Trennung muss 99 Untagged raus geführt werden. Also kein vlan.
Igb0 ist noch frei
VLAN99 löschen
LAN99 als Name für igb9
Nun sollte es klar sein.
Wenn der am switch vlan 1 Untagged ist, würde das 99 auf 1 übersetzt.
99U
4711U
42U
Schall und Rauch. Das du vlan 1 nicht nimmst ist gut. So kann man später nicht aus Versehen was zusammen stecken....
Nur 99U wäre an der pfsense sowas wie
LAN99
Das direkt nur als Schnittstellen Namen sehen! Untagged. Der Rest müsste dann passen.
Man kann durch so eine Verkabelung VLAN id's komplett ändern. Macht nur Chaos.
Bei deiner jetzigen Trennung muss 99 Untagged raus geführt werden. Also kein vlan.
Igb0 ist noch frei
VLAN99 löschen
LAN99 als Name für igb9
Nun sollte es klar sein.
Igb0 ist noch frei
Nein, nicht wirklich!Darauf mappen ja alle seine VLANs!
Das dazu korrespondierende phyische Interface (Parent) ist aber deaktiviert und damit auch der UNtagged Traffic von diesem Interface und auch alle VLANs.
Das ist der Kardinalsfehler den der TO vermutlich im Eifer des Gefechts gemacht hat...?!
Richtig. Ich sehe es so. Statt VLAN 1 hat er 99 als Nummer genommen.
Jain. Ich sagte ja im letzten Satz vlan 99 muss weg.
Das als LAN99 auf igb0. Die anderen können bleiben.
Dann wäre 99 der Name der Schnittstelle! Und ein Hinweis auf ein Netz was Untagged raus geht.
Er hat in Cisco 99U schon stehen.
Wenn er 99 als Schnittstelle und nicht als VLAN betrachtet passt es doch.
Unten ist doch bei add igb0 to sehen. Wenn vlan 99 gedanklich und auf dem Router gelöscht ist passt es doch wieder.
Hallo ihr helfenden Hände!
@aqui
Ja, ich habe nicht bedacht, das ich VLAN ID 99 als untagged gesetzt habe und habe es noch verschlimmbessert, als ich das Native VLAN auf 99 gesetzt habe. Das PVID scheint auf Cisco immer untagged zu terminieren.. natürlich muss es auch tagged am Port ausgewiesen werden, wieder was gelernt.
LAG erstellt:
Kontrolle Port VLAN Membership:
Frage: Warum steht hier nun wieder PVID 1 ??
Default VLAN Settings:
Nein "igb0" muss ja auch nicht aktiv sein, zumindest habe ich es so verstanden. Siehe das Bild Schnittstelle "VLAN10-99" an Netzwerkport "VLAN XX Ein igb0"
Daher ergibt sich nun (nach hinzufügen des LAGG folgendes Bild):
Das LAGG sieht so aus:
@alle
Ich habe nun alle hier genannten Tips umgesetzt und möchte das natürlich einem "Suchenden" wie ich es war, nicht vorenthalten:
1. VLANS auf der pfSense einrichten und DHCP Server dazu
2. auf dem Switch alle VLANS tagged terminieren lassen
3. das hatte ich falsch, VLAN 99 muss auch getagged ankommen
4. Die PVID hatte ich danach auf 99 gestellt und das Feld "Renew IP Adress" angeklickt
5. zack, war die Management IP Adresse aus dem DHCP Bereich da und ich konnte sie in der pfSense reservieren.
Der Beweis:
Dazu habe ich die Tips von @aqui umgesetzt
- aus Performance Gründen ein Lagg auf der pfSense erstellt (igb0 und igb1) sprich ETH4 und ETH5
- LAGG Protokoll - LACP
Vielen Dank für die hervorragende Hilfe!
VG Alexander
@aqui
Ja, ich habe nicht bedacht, das ich VLAN ID 99 als untagged gesetzt habe und habe es noch verschlimmbessert, als ich das Native VLAN auf 99 gesetzt habe. Das PVID scheint auf Cisco immer untagged zu terminieren.. natürlich muss es auch tagged am Port ausgewiesen werden, wieder was gelernt.
LAG erstellt:
Kontrolle Port VLAN Membership:
Frage: Warum steht hier nun wieder PVID 1 ??
Default VLAN Settings:
Nein "igb0" muss ja auch nicht aktiv sein, zumindest habe ich es so verstanden. Siehe das Bild Schnittstelle "VLAN10-99" an Netzwerkport "VLAN XX Ein igb0"
Daher ergibt sich nun (nach hinzufügen des LAGG folgendes Bild):
Das LAGG sieht so aus:
@alle
Ich habe nun alle hier genannten Tips umgesetzt und möchte das natürlich einem "Suchenden" wie ich es war, nicht vorenthalten:
1. VLANS auf der pfSense einrichten und DHCP Server dazu
2. auf dem Switch alle VLANS tagged terminieren lassen
3. das hatte ich falsch, VLAN 99 muss auch getagged ankommen
4. Die PVID hatte ich danach auf 99 gestellt und das Feld "Renew IP Adress" angeklickt
5. zack, war die Management IP Adresse aus dem DHCP Bereich da und ich konnte sie in der pfSense reservieren.
Der Beweis:
Dazu habe ich die Tips von @aqui umgesetzt
- aus Performance Gründen ein Lagg auf der pfSense erstellt (igb0 und igb1) sprich ETH4 und ETH5
- LAGG Protokoll - LACP
Vielen Dank für die hervorragende Hilfe!
VG Alexander
Das PVID scheint auf Cisco immer untagged zu terminieren..
Das "scheint" nicht nur so sondern ist allgemeiner Standard bei VLANs! Es ist also nicht nur bei Cisco so sondern bei allen anderen Switches auch! Das PVID VLAN am Switchport bestimmt immer wohin der Switch UNgetaggte Pakete forwardet. Also solche Pakete die keine VLAN Information im Paketheader tragen. Ohne diese Information muss man dem Switch das natürlich in der Konfiguration mitgeben. Im Default ist das PVID VLAN immer 1, sprich der Switch forwardet UNgetaggte Pakete ins VLAN 1. Will man diesen Traffic nicht im VLAN 1 haben muss man die Port PVID entsprechend setzen. Die PVID ist immer portbezogen am Switch.
Siehe auch HIER und die VLAN Schnellschulung.
Auf der Firewall am anderen Ende senden immer die Parent Interfaces, also die physischen Interfaces ihren Traffic UNtagged. Die darauf gemappten VLANs dann entsprechend dann mit einem VLAN Tag im Paketheader. Einfaches Prinzip....
⚠️ Leider hast du oben mit dem LAG Port schon wieder den gleichen Kardinalsfehler wie oben begangen und den LAG Port lagg0 wiederum NICHT über das "Interface Assignment" in die aktiven Ports der FW übernommen!! ☹️
Nach Erstellung des LAG Ports taucht dieser als virtueller Port in der Liste der "verfügbaren Netzwerkports" auf und muss dann wie jeder andere physische Port durch Klick auf das + dann auch in die Liste der aktiven Interfaces übernommen werden!!! Leider ist das schon wieder unterblieben wenn man deinem aktualisierten Screenshot oben trauen kann.
Das solltest du dringenst noch korrigieren!!!
Was den UNtagged Traffic deines igb0/igb1 LAG Trunk Ports anbetrifft, kannst du den also entweder ins VLAN 1 forwarden wenn du damit leben kannst. (Am Switch dann "99U" einstellen). Dann musst du nichts weiter am Switch einstellen.
Soll er aber dediziert ins VLAN 99, dann musst du im Switch das Management Interface von 1 aufs VLAN 99 mappen. Siehe IP Management Screenshot von oben.
Der Rest ist soweit OK.
Sinnvoll wäre es noch dem Switch und auch ggf. dem Debian Server im DHCP Setup ("DHCP Static Mappings") immer eine feste IP Adresse zuzuweisen. Alternativ klickt man in der Leases Übersicht das gerahmte "+" ("add static mapping") um das Gerät in den statischen Leases hinzuzufügen. Dort kann man dann die IP entsprechend seiner Wünsche anpassen. Infrastruktur und Server sollten in der Regel immer statische oder fest gemappte IPs haben.
Vielen Dank für die hervorragende Hilfe!
Immer gerne! 😊
Generell ist es klug was anderes als VLAN 1 zu nehmen.
So ist es immer ein bwußter Vorgang. 1 ist immer Auslieferungszustand. Wenn prod, Test und VoIP > 1 sind kann man später es besser auseinander halten. Sonst steckt man was ein und im eifer bekommt es halt eine IP, ist aber im nicht gewünschten Netz.
Der Aufwand lohnt sich.
Ansonsten ist es immer nur eine Kopfsache. VLANs existieren auf den Switchen max. bis zum Access Port.
Praktisch kann man VLANs auch einfach auf eine andere Nummer "mappen"
Zyxel AP Mangement Aplliance:
Port 1 - VID10U
Port 2 - VID20U
Port 3 - VID30U
Wenn die Firewall genug ports hat:
Port 1VID10U <-> Port 1 VID4711U
Dann hätte das Netz am andere Gerät VID 4711
Untagged ist immer so, als hätten wir kein VLAN. Man kann so auch großen Mist bauen und Netze "vereinigen".
Darum schreib ich oben ja, dass Namen Schall und Rauch sind. @aqui wies ja auf Interface Assignment hin.
Nummern und Namen sind immer nur eine Kopfsache. Am saubersten ist es, wenn man die einmal definierten VLANs komplett beibehält und nicht aus Äpfel Birnen macht.
Oben mit den Zyxel ist so ein unschönes Bsp. Wir verbinden mal mit Kabeln 2 Geräte, die dess Access Points ein anderes VLAN, von der ID her, haben. Aber die richtigen Dienste ansprechen - auf der richtigen (virt.) Schnittstelle final landen.
Zyxel oben hat ich selber mal so erlebt. Bei PVID 1 ist aber genau die Gefahr immer dabei. Wenn man also ID > 1 nimmt ist es immer ein bewusster Vorgang, da sonst die Anfragen ins leere gehen.
Hatte so 2019 noch 3 com Switch von 2006?!? Da kam man nicht mehr drauf, wenn LAG aktiv war. Obgleich alles richtig eingestellt war.
"1" ist halt default. Gute Geräte lassen das ändern. Auch Managent Netzwerk. Uralte vlt. nicht. ...
VLANs machen immer im ersten Moment etwas arbeit. Es lohnt sich aber durchaus das "1" zu versuchen los zuwerden, in dem prod Netze > 1 anfangen.
Normal plant man es und zieht es durch. 2x versch. VLAN Definitionen sind aber vlt. nicht immer vekehrt. Wenn man gerade bei einer Migartion ist und alles nacheinander neu aufbauen muss.
Durch das "wilde" verkabeln der Untagged Ports kann ich dann bewusst VID 10 auf die "neue" VID "100" umsetzen und erreich so nach und nach einen komplett neuen Aufbau.
Risiko ist natürlich dass man sich verzettelt. Auch ohne Trennung kann ein Ethernert Port ja mehrere Netze tragen - Subnetzmasken, etc. Wirkliche Abgrenzung erreicht man nur wenn man VLAN Regeln einhält.
So ist es immer ein bwußter Vorgang. 1 ist immer Auslieferungszustand. Wenn prod, Test und VoIP > 1 sind kann man später es besser auseinander halten. Sonst steckt man was ein und im eifer bekommt es halt eine IP, ist aber im nicht gewünschten Netz.
Der Aufwand lohnt sich.
Ansonsten ist es immer nur eine Kopfsache. VLANs existieren auf den Switchen max. bis zum Access Port.
Praktisch kann man VLANs auch einfach auf eine andere Nummer "mappen"
Zyxel AP Mangement Aplliance:
Port 1 - VID10U
Port 2 - VID20U
Port 3 - VID30U
Wenn die Firewall genug ports hat:
Port 1VID10U <-> Port 1 VID4711U
Dann hätte das Netz am andere Gerät VID 4711
Untagged ist immer so, als hätten wir kein VLAN. Man kann so auch großen Mist bauen und Netze "vereinigen".
Darum schreib ich oben ja, dass Namen Schall und Rauch sind. @aqui wies ja auf Interface Assignment hin.
Nummern und Namen sind immer nur eine Kopfsache. Am saubersten ist es, wenn man die einmal definierten VLANs komplett beibehält und nicht aus Äpfel Birnen macht.
Oben mit den Zyxel ist so ein unschönes Bsp. Wir verbinden mal mit Kabeln 2 Geräte, die dess Access Points ein anderes VLAN, von der ID her, haben. Aber die richtigen Dienste ansprechen - auf der richtigen (virt.) Schnittstelle final landen.
Zyxel oben hat ich selber mal so erlebt. Bei PVID 1 ist aber genau die Gefahr immer dabei. Wenn man also ID > 1 nimmt ist es immer ein bewusster Vorgang, da sonst die Anfragen ins leere gehen.
Hatte so 2019 noch 3 com Switch von 2006?!? Da kam man nicht mehr drauf, wenn LAG aktiv war. Obgleich alles richtig eingestellt war.
"1" ist halt default. Gute Geräte lassen das ändern. Auch Managent Netzwerk. Uralte vlt. nicht. ...
VLANs machen immer im ersten Moment etwas arbeit. Es lohnt sich aber durchaus das "1" zu versuchen los zuwerden, in dem prod Netze > 1 anfangen.
Normal plant man es und zieht es durch. 2x versch. VLAN Definitionen sind aber vlt. nicht immer vekehrt. Wenn man gerade bei einer Migartion ist und alles nacheinander neu aufbauen muss.
Durch das "wilde" verkabeln der Untagged Ports kann ich dann bewusst VID 10 auf die "neue" VID "100" umsetzen und erreich so nach und nach einen komplett neuen Aufbau.
Risiko ist natürlich dass man sich verzettelt. Auch ohne Trennung kann ein Ethernert Port ja mehrere Netze tragen - Subnetzmasken, etc. Wirkliche Abgrenzung erreicht man nur wenn man VLAN Regeln einhält.
1
Hallo zusammen,
ich habe alles nochmal überarbeitet - aber irgendwo stolpere ich immer noch.
Auf der Pfsense habe ich:
- ein Lag erstellt
- alle VLANS erstellt und eine statische IP zugewiesen
- DHCP Server in die den VLANS aktiviert
- die Interfaces zugewiesen (auch das LAG)
Das Lag scheint auch durch einen stumpfen Ping-Test auf die IP des LAG - vom Client aus, und dann Kabel raus und wieder rein auch zu funktionieren.. Also man sieht eine Verzögerung.
Was nun nicht funktioniert ist:
- Der Switch bekommt keine DHCP Adresse zugewiesen von der pfSense aus VLAN 99
Was funktioniert noch:
- Clients am Switch angeschlossen, erhalten eine IP aus dem jeweiligen VLAN DHCP Bereich der pfSense
Was ich festgestellt habe:
- wenn ich auf dem LAG Interface einen DHCP Server laufen lasse, bekommt der Switch eine IP Adresse
Wo liegt nun der Fehler oder besser mein Konfigurationsfehler?
In der Theorie würde ich doch sagen, das dieser Aufbau grundsätzlich funktioniert, dennoch ist irgendwas krumm.
Kurze Anmerkung zu statischen Adressen:
Ja ich möchte die IP Adressen auch statisch vergeben, dies möchte ich aber in der pfSense und nicht manuell auf den Geräten tun.
Das Debian System ist mein Schlepptop, welchen ich zum testen der einzelnen VLANs genutzt habe, die WKS ist mein Desktop und das andere war der Cisco SG200.
VG Alexander
(der weniger Haare auf dem Kopf hat, seit 2 Tagen - vom Haare raufen
ich habe alles nochmal überarbeitet - aber irgendwo stolpere ich immer noch.
Auf der Pfsense habe ich:
- ein Lag erstellt
- alle VLANS erstellt und eine statische IP zugewiesen
- DHCP Server in die den VLANS aktiviert
- die Interfaces zugewiesen (auch das LAG)
Das Lag scheint auch durch einen stumpfen Ping-Test auf die IP des LAG - vom Client aus, und dann Kabel raus und wieder rein auch zu funktionieren.. Also man sieht eine Verzögerung.
Was nun nicht funktioniert ist:
- Der Switch bekommt keine DHCP Adresse zugewiesen von der pfSense aus VLAN 99
Was funktioniert noch:
- Clients am Switch angeschlossen, erhalten eine IP aus dem jeweiligen VLAN DHCP Bereich der pfSense
Was ich festgestellt habe:
- wenn ich auf dem LAG Interface einen DHCP Server laufen lasse, bekommt der Switch eine IP Adresse
Wo liegt nun der Fehler oder besser mein Konfigurationsfehler?
In der Theorie würde ich doch sagen, das dieser Aufbau grundsätzlich funktioniert, dennoch ist irgendwas krumm.
Kurze Anmerkung zu statischen Adressen:
Ja ich möchte die IP Adressen auch statisch vergeben, dies möchte ich aber in der pfSense und nicht manuell auf den Geräten tun.
Das Debian System ist mein Schlepptop, welchen ich zum testen der einzelnen VLANs genutzt habe, die WKS ist mein Desktop und das andere war der Cisco SG200.
VG Alexander
(der weniger Haare auf dem Kopf hat, seit 2 Tagen - vom Haare raufen
Der Switch bekommt keine DHCP Adresse zugewiesen von der pfSense aus VLAN 99
Leider fehlt dazu deine korrespondierende Switch Konfig! Hier hast du jetzt 2 Möglichkeiten:
1.) VLAN 1 am Switch belassen, Mgmt über LAGG0 Interface:
Wie schon oben mehrfach beschrieben sendet das physische Parent Interface seinen Traffic immer UNtagged. Bei deinem LAG wäre das das Interface LAGG0.
Leider hast du vergessen dazu das Setup zu posten aber wenn du dort das IP Netz auf deine VLAN 99 IP setzt dann arbeitet das LAGG0 Interface UNtagged im IP Netz was fürs VLAN 99 vorgesehen ist und vergibt dort auch IPs sofern ein DHCP Server dort aktiv ist.
Auf dem Switch ist dann keine weitere Konfig nötig!
Seine Management IP liegt UNtagged im VLAN 1, folglich bekommt dann dieses Mgmt Interface UNtagged Traffic aus dem LAGG0 Interface das im IP Bereich des VLAN 99 liegt.
Der LAG Trunk Port ist dann entsprechend 1U,10T,20T.30T,40T,50T eingestellt.
Das dedizierte VLAN 99 entfällt dann und solltest du auch vollständig und beidseitig aus dem Setup löschen!!
Das Management IP Netz entspricht dann dem IP Netz was auf dem VLAN Parent Interface LAGG0 konfiguriert wurde.
Diese Option hast du oben ja auch schon selber zum Laufen bekommen. ("wenn ich auf dem LAG Interface einen DHCP Server laufen lasse, bekommt der Switch eine IP Adresse")
Daraus kann man nur schliessen das du lediglich die nun im Anschluss beschriebene Option 2 falsch oder fehlerhaft konfiguriert hast!
2.) Management dediziert über VLAN 99:
Hier behälst du das VLAN 99 bei und setzt es auf das dafür vorgesehene IP Netz.
Das LAGG0 Interface bleibt im Assignment aber IP-technisch leer und wird nicht mit einer IP konfiguriert. So wird dann keinerlei UNtagged IP Traffic vom LAGG0 Interface gesendet sondern rein nur tagged Traffic über die VLANs.
Das wiederum erzwingt dann das du im Switch im "IP Management Menü" die Bindung der Management IP Adresse auf das VLAN 99 setzt! (Anstatt VLAN 1, siehe Screenshot oben!). So arbeitet die Switch Management IP Adresse tagged im VLAN 99.
⚠️ Jetzt bekommst du allerdings ein Henne Ei Problem bei DHCP.
Setzt du das Management VLAN auf 99 verlierst du augenblicklich die Management Verbindung und kannst diese Einstellung nicht mehr sichern auf dem Switch. Der Switch erwartet jetzt die Management Verbindung mit einem VLAN 99 Tag.
Ein Reboot geht nicht, denn der würde die vorab aktive Konfig wiederherstellen mit der Management IP untagged im VLAN 1.
Hier bleibt dir also nichts anderes als den Ablauf der Lease Time abzuwarten so das dem Switch eine neue Management IP zugeteilt wird. Dann kannst du das Setup sichern.
Oder mit etwas Trickserei...
- Switch erst über einen untagged Access Port ins VLAN 99 stecken das er dort eine IP zieht.
- Über diese IP aufs Management verbinden und danach das management auf VLAN 99 umstellen
- Jetzt den Port wieder auf den Trunkport zurückstecken und über die Trunk die bestehende VLAN 99 IP verbinden und dann die Konfig sichern.
Diese beiden Optionen hast du für den Switch Management Zugang und dort ist sehr wahrscheinlich auch dein Fehler in der Konfiguration. Für eine dieser Optionen musst du dich entscheiden.
Da leider die wichtigsten Screenshots dazu fehlen kann man hier erstmal nur Kristallkugeln und leider nur raten wo du den Fehler gemacht haben könntest.
Für so ein einfaches Setup muss man sich allerhöchstens 3 Minuten am Hinterkopf kratzen aber keine 2 Tage Haare raufen.
Hallo zusammen,
ich versuche mich gerade an Option 2
jetzt wirklich im Detail:
- Switch zurücksetzen
- Switch hat Standard VLAN 1 IP Adresse 192.168.1.254
- Notebook an den Switch anschließen
- IP Adresse manuell am Notebook auf 192.168.1.250
- Subnetz 255.255.255.0
- per Browser auf den Switch -> klappt!
- Create VLAN 99
- Interface 5 auf Access setzen
- Port to VLAN 99 Untagged
- Konfig speichern, reboot
- Interface 5 mit pfSense Port verbinden (VLAN 99 mit DHCP)
Resultat -> keine IP Adresse
Hast Du einen SG200? Evtl. wäre eine Möglichkeit die config.txt einzulesen am Switch. Ich habe auch schon dran gedacht dies zu tun, aber ich weiß nicht, wie ich ihm darin DHCP auf 10.10.99.254 beibringen soll..
VG Alexander
ich versuche mich gerade an Option 2
jetzt wirklich im Detail:
- Switch zurücksetzen
- Switch hat Standard VLAN 1 IP Adresse 192.168.1.254
- Notebook an den Switch anschließen
- IP Adresse manuell am Notebook auf 192.168.1.250
- Subnetz 255.255.255.0
- per Browser auf den Switch -> klappt!
- Create VLAN 99
- Interface 5 auf Access setzen
- Port to VLAN 99 Untagged
- Konfig speichern, reboot
- Interface 5 mit pfSense Port verbinden (VLAN 99 mit DHCP)
Resultat -> keine IP Adresse
Hast Du einen SG200? Evtl. wäre eine Möglichkeit die config.txt einzulesen am Switch. Ich habe auch schon dran gedacht dies zu tun, aber ich weiß nicht, wie ich ihm darin DHCP auf 10.10.99.254 beibringen soll..
VG Alexander
Hast Du einen SG200?
Mehrere natürlich! Resultat -> keine IP Adresse
Das ist doch auch verständlich und erwartbar! Überlege einmal selberDu hast oben testweise die Default Management Adresse im VLAN 1 von .1.254 auf .1.250 geändert. OK, das bei beiden der Zugang von einem VLAN 1 Accessport klappt ist klart und erwartbar.
Du musst dir das so vorstehhen das die Management IP Adresse quasi über eine virtuelle Netzwerkkarte im VLAN 1 eingehängt ist.
OK, dann hast du ein VLAN 99 erstellt und einen Switchport als Accessport diesem VLAN 99 zugewiesen. Soweit so gut...kann man machen
Deine Switch Management Adresse hängt aber weiter mit der statischen IP 192.168.1.250 im VLAN 1, da ändert auch ein Reboot nichts.
Nun rebootest du den Switch und steckst den VLAN 99 Port in ein VLAN 99 Interface der pfSense das sehr wahrscheinlich auf ein anderes IP Netz benutzt.
Das das die weiter gültige Management IP des Switches im VLAN 1 NICHT ändert ist doch dann klar und erwartbar. VLAN 99 ist gar nicht mit dem Management verbunden.
Ein paar Dinge sind bei deinen Schritten oben unklar:
WO kommt der VLAN 99 Port auf der pfSense her der UNtagged Traffic sendet?? 🤔
UNtagged kommt der Traffi causschliesslich nur wenn die Option 1 genutzt wird und das Management Netz auf das Parent Interface gelegt wird.
In deiner ursprünglichen Konfig ist dein VLAN 99 aber ein VLAN mit der ID 99 auf dem Parent Interface, wird also immer mit einem VLAN Tag Richtung Switch versendet.
Solch getaggter Traffic wird niemals einen Accessport am Switch passieren können, denn der will natürlich immer nur UNtagged Traffic sehen und schmeisst eingehende Pakete mit einem VLAN Tag sofort in den Datenmülleimer ! Port 5 im Access Mode kann also nur Traffic "sehen" der UNtagged kommt was im Option 2 Setup aber, wo VLAN 99 ein dediziertes VLAN, ist nie der Fall ist. Das kommt so immer mit einem VLAN Tag den der Port dann verwirft.
In deinen "jetzt wirklich im Detail:" Schritte schreibst du mit keinem Wort WIE der korrespondierende pfSense Port aussieht?!
Wenn du von Option 2 redest was du umsetzen willst dann kommt der VLAN 99 Traffic über den Trunk Port der pfSense also immer Tagged. Folglich muss dann auch der Switchport ein Trunkport sein der dieses VLAN mit "xyT" erwartet, bei dir "99T".
Das erzwingt dann, wie oben schon beschrieben, das der Management Port des Switches auch tagged in das VLAN 99 gelegt wird denn nur so akzeptiert der Switch tagged Traffic am Management IP Port. Sprich er muss von VLAN 1 ins VLAN 99 wandern.
Nun bekommst du aber ein Konfig Problem wie oben schon beschrieben...
Du musst ja irgendwie auf den Switch kommen um das Konfigtechnisch umzustellen. Also dann via VLAN 1 Accessport über deine statische .1.250er IP.
Sowie du aber jetzt die IP statisch änderst oder das Management VLAN rennst du in ein Problem:
- Änderst du die IP auf eine VLAN 99 IP und klickst "Save" verlierst du sofort die Verbindung. Du hast dann zwar eine VLAN 99 IP aber der Mgmt Port ist weiterhin im VLAN 1 untagged. Jetzt hilft es nur dem Konfig PC statisch eine VLAN 99 IP zu geben um wieder über den VLAN 1 Accessport zuzugreifen um das VLAN umstellen zu können. Erst wenn das geschehen ist und du das VLAN dann von 1 auf 99 setzt und auf "Save" klickst wirst du dann wiederum sofort die Verbindung vom Konfig PC verlieren. Logisch, denn das Management Interface des Switches will die Frames jetzt nur Tagged sehen. Final klappt es dann nur wieder wenn du den PC dann in einen VLAN 99 Accessport steckst, dann solltest du eine DHCP IP im VLAN 99 bekommen und kannst dann auf die statische VLAN 99 IP des Switches zugreifen.
- Anders herum passiert ähnliches. Würdest du über die VLAN 1 IP zuerst das VLAN verändern im Switch IP Setting setzt du es auf 99 und verlierst sofort die Verbindung. Jetzt würde der Switch Zugang aus dem 99er Netz nur tagged akzeptieren aber die IP stimmt jetzt nicht. Du müsstest das 99er Netz temporär in .1.0/24 ändern dann auf die alte .1.250 zugreifen die dann in eine VLAN 99 IP ändern, du verlierst wieder den Zugang. Jetzt das VLAN 99 in der pfSense wieder zurückändern und erst dann klappt der Zugang wieder.
Diese ganzen Klimmzüge für die Option 2 sind deshalb erforderlich weil der SG200 keinen unabhängigen seriellen Terminal Zugang zur Konfiguration hat wie SG250 oder SG300 Modelle. Auch kein Out of Bound (OOB) Interface. Leider ein genereller Nachteil dieser sehr billigen Kleinmodelle die ausschliesslich nur LAN Zugänge zur Konfig haben.
Damit wären diese gesamten Option 2 Klimmzüge obsolet weil man dem Switch das alles über ein von der Netzwerk Infrastruktur völlig unabhängigen Interface konfigurieren kann.
So bleibt dir also nur die Schrittweise Umsetzung mit der o.a. "Trickserei" wenn du die Option 2 umsetzen willst.
Dadurch das zum fehlenden seriellen Terminal auch kein Telnet oder SSH Zugang beim SG200-8 möglich ist entfällt die Option eine config.txt auszulesen und entsprechend angepasst wieder zurückzuschreiben was in der Tat das Sinnvollste wäre.
Hallo aqui,
..hole ich heute Abend nach. Sorry dafür.
Ich kann doch aber eine running-config oder startup-config unter der statischen IP 192.168.1.254 im Menü unter Filemanagement einfügen?
Zum Beispiel diese hier:
Wenn man nun hier irgendwie ändern könnte das aus VLAN 99 eine IP Adresse zugewiesen/geholt werden soll.
So billig sind diese Switches gar nicht, also man möchte dafür auch Geld sehen.. leider auch schon EOL und damit vielleicht auch ein Grund die Sache mit diesem Switch zu überdenken und gleich in etwas "vernünftigeres" zu investieren.
Ich benötige eigentlich "24" Ports, VLan (Layer 2 reicht) und wie ich nun feststelle evtl. einen Switch der auch eingehende Management IP aus VLAN 99 kann?
Du schreibst das neuere SG250, eine Konfigurationsmöglichkeit über serielles Terminal hat .. evtl. ist das schon eine Lösung für mich. So einen kann ich mir besorgen und es testen... Leider auch wieder nur 8 Ports.
Verstehe ich das richtig? Diese "klimmzüge" muss man doch nur veranstalten, weil der Switch untagged Traffic erwartet um ihn über eine IP Managen zu können?
Hast Du evtl. einen Tip, welcher Switch meinen Anforderungen genügen würde?
VG Alexander
Zitat von @aqui:
Ein paar Dinge sind bei deinen Schritten oben unklar:
WO kommt der VLAN 99 Port auf der pfSense her der UNtagged Traffic sendet?? 🤔
UNtagged kommt der Traffi causschliesslich nur wenn die Option 1 genutzt wird und das Management Netz auf das Parent Interface gelegt wird.
WO kommt der VLAN 99 Port auf der pfSense her der UNtagged Traffic sendet?? 🤔
UNtagged kommt der Traffi causschliesslich nur wenn die Option 1 genutzt wird und das Management Netz auf das Parent Interface gelegt wird.
In deinen "jetzt wirklich im Detail:" Schritte schreibst du mit keinem Wort WIE der korrespondierende pfSense Port aussieht?!
..hole ich heute Abend nach. Sorry dafür.
Dadurch das zum fehlenden seriellen Terminal auch kein Telnet oder SSH Zugang beim SG200-8 möglich ist entfällt die Option eine config.txt auszulesen und entsprechend angepasst wieder zurückzuschreiben was in der Tat das Sinnvollste wäre.
Ich kann doch aber eine running-config oder startup-config unter der statischen IP 192.168.1.254 im Menü unter Filemanagement einfügen?
Zum Beispiel diese hier:
!Current Configuration:
!
!System Description "8-Port Gigabit Smart Switch"
!System Software Version "1.0.8.3"
!System Up Time "0 days 0 hrs 22 mins 57 secs"
!Additional Packages FASTPATH QOS
!Current SNTP Synchronized Time: Not Synchronized
!
vlan database
vlan 10,20,30,40,50,99
vlan name 10 "VLAN_10"
vlan name 20 "VLAN_20"
vlan name 30 "VLAN_30"
vlan name 40 "VLAN_40"
vlan name 50 "VLAN_50"
vlan name 99 "VLAN_99"
exit
configure
clock timezone 2 minutes 0
clock timezone config dhcp
username "XXXX" password xxxx encrypted override-complexity-check
authentication dot1x none
spanning-tree configuration name "00-CC-FC-D7-48-0C"
port-channel name ch1 LAG1
port-channel load-balance 1 ch1
interface g7
addport ch1
exit
interface g8
addport ch1
exit
!
interface g1
switchport mode access
switchport access vlan 10
exit
interface g2
switchport mode access
switchport access vlan 20
exit
interface g3
switchport mode access
switchport access vlan 30
exit
interface g4
switchport mode access
switchport access vlan 40
exit
interface g5
switchport mode access
switchport access vlan 50
exit
interface g6
switchport mode access
switchport access vlan 99
exit
interface ch1
switchport trunk allowed vlan add 10,20,30,40,50,99
exit
interface ch2
no adminmode
exit
interface ch3
no adminmode
exit
interface ch4
no adminmode
exit
exitWenn man nun hier irgendwie ändern könnte das aus VLAN 99 eine IP Adresse zugewiesen/geholt werden soll.
Diese ganzen Klimmzüge für die Option 2 sind deshalb erforderlich weil der SG200 keinen unabhängigen seriellen Terminal Zugang zur Konfiguration hat wie SG250 oder SG300 Modelle. Auch kein Out of Bound (OOB) Interface. Leider ein genereller Nachteil dieser sehr billigen Kleinmodelle die ausschliesslich nur LAN Zugänge zur Konfig haben.
So billig sind diese Switches gar nicht, also man möchte dafür auch Geld sehen.. leider auch schon EOL und damit vielleicht auch ein Grund die Sache mit diesem Switch zu überdenken und gleich in etwas "vernünftigeres" zu investieren.
Ich benötige eigentlich "24" Ports, VLan (Layer 2 reicht) und wie ich nun feststelle evtl. einen Switch der auch eingehende Management IP aus VLAN 99 kann?
Du schreibst das neuere SG250, eine Konfigurationsmöglichkeit über serielles Terminal hat .. evtl. ist das schon eine Lösung für mich. So einen kann ich mir besorgen und es testen... Leider auch wieder nur 8 Ports.
Verstehe ich das richtig? Diese "klimmzüge" muss man doch nur veranstalten, weil der Switch untagged Traffic erwartet um ihn über eine IP Managen zu können?
Hast Du evtl. einen Tip, welcher Switch meinen Anforderungen genügen würde?
VG Alexander
eine running-config oder startup-config unter der statischen IP 192.168.1.254 im Menü unter Filemanagement einfügen?
Das ist in der Tat richtig. Vermutlich reicht wie üblich nur die Zeile zur Konfiguration des Management Interfaces. Wäre auch ein Muss, denn wenn das VLAN nicht vorhanden ist scheitert ein Setzen des Managements in diesem VLAN.Der Default ist DHCP Client im VLAN 1, deshalb wird eine explizites Kommando in der running-config.txt zum Management auch nicht angezeigt.
Definiert man eine statische IP sieht es anders aus: (ip maske gateway)
network parms 192.168.1.1 255.255.255.0 192.168.1.254 Das Dilemma mit dem selber Absägen bei der Option 2 beschreibt auch ein entsprechender Thread
https://serverfault.com/questions/741101/cisco-sg200-26-cant-change-mana ...
So, Problem gelöst....
Ich habe den SG200-8 einmal an einen Catalyst 3560 mit seinem LAG Trunkport gehängt und auf dem SG200 parallel auch einen 99er Accessport eingerichtet und mir das Elend einmal über einen Mirrorport mit dem Wireshark angesehen.
Catalyst LAG:
SG200-8 LAG:
Was passiert ist Folgendes:
Auf den ersten Blick sieht es nach einem Firmware Bug in der latest 1.0.8.3 Firmware Version aus das die DHCP Client Funktion einzig nur im VLAN 1 funktioniert nicht aber in anderen VLANs.
Geht man dann aber via statischer Management IP auf den Switch und setzt jetzt die statische Konfig wieder zurück auf DHCP flimmert die Power LED kurz, wie sie es üblicherweise macht wenn der Switch keine IP hat, leuchtet aber nach 2 Sekunden wieder stabil was eine gültige IP signalisiert.
Sieht man im DHCP Server nach, existiert dort auch ein entsprechender Lease. Der Mirrorport zeigt dann auch ein entsprechenden DHCP Request mit einem VLAN Tag.
Ein Test mit mehrfachen Reboots und auch Löschen der Lease Datenbank lies den Switch dann mit DHCP VLAN Konfig auf dem Management immer wieder korrekt starten.
Auch ein vollständiger Hardware Reset auf die Werkseinstellungen mit anschliessender Rücksicherung der Konfig konnte die vorangegangene Problematik nicht mehr reproduzieren.
Warum hie und da mal DHCP Hänger passieren bleibt unklar. Über den "Umweg" über eine statische IP und dann zurück auf DHCP lässt sich das aber immer fixen.
Übrigens der VLAN Tag für das Management Interface ist in der running-config.txt ein separates Kommando.
Das zum o.a. Management IPv4 Interface korrespondierende GUI Setup mit statischer IP sieht dann so aus:
Die später ebenso funktionierende DHCP Variante dann entsprechend so:
Ich habe den SG200-8 einmal an einen Catalyst 3560 mit seinem LAG Trunkport gehängt und auf dem SG200 parallel auch einen 99er Accessport eingerichtet und mir das Elend einmal über einen Mirrorport mit dem Wireshark angesehen.
Catalyst LAG:
interface Port-channel1
description LACP LAG Uplink
switchport trunk encapsulation dot1q
switchport trunk native vlan 1
switchport trunk allowed vlan 1,10,20,99
switchport mode trunk
switchport nonegotiateWas passiert ist Folgendes:
- Verbleibt der IPv4 Management Port im DHCP Client Mode sendet er sobald man das VLAN von 1 auf ein anderes umstellt keinen DHCP Request mehr. Auch wenn man unten explizit den Haken bei Renew DHCP setzt!
- Und jetzt kommt es: Belässt man das IPv4 Management Interface auf dem VLAN 99 aber konfiguriert ihm mit Klick auf "Static" eine freie statische IP mit Gateway im VLAN 99 funktioniert es fehlerlos! (Crosscheck mit einem CBS250 und identischer Konfig sendet diesen Request mit den entsprechenden 802.1q VLAN Tags im Frame)
Auf den ersten Blick sieht es nach einem Firmware Bug in der latest 1.0.8.3 Firmware Version aus das die DHCP Client Funktion einzig nur im VLAN 1 funktioniert nicht aber in anderen VLANs.
Geht man dann aber via statischer Management IP auf den Switch und setzt jetzt die statische Konfig wieder zurück auf DHCP flimmert die Power LED kurz, wie sie es üblicherweise macht wenn der Switch keine IP hat, leuchtet aber nach 2 Sekunden wieder stabil was eine gültige IP signalisiert.
Sieht man im DHCP Server nach, existiert dort auch ein entsprechender Lease. Der Mirrorport zeigt dann auch ein entsprechenden DHCP Request mit einem VLAN Tag.
Ein Test mit mehrfachen Reboots und auch Löschen der Lease Datenbank lies den Switch dann mit DHCP VLAN Konfig auf dem Management immer wieder korrekt starten.
Auch ein vollständiger Hardware Reset auf die Werkseinstellungen mit anschliessender Rücksicherung der Konfig konnte die vorangegangene Problematik nicht mehr reproduzieren.
Warum hie und da mal DHCP Hänger passieren bleibt unklar.
Über den "Umweg" über eine statische IP und dann zurück auf DHCP lässt sich das aber immer fixen.Übrigens der VLAN Tag für das Management Interface ist in der running-config.txt ein separates Kommando.
network parms 10.99.1.99 255.255.255.0 10.99.1.254
network mgmt_vlan 99
Hallo zusammen,
ich bekomme das Konstrukt einfach nicht zum fliegen.
Egal was ich tue, es scheint vermutlich falsch zu sein.
Habe ich verstanden, fällt auf weil er kein Default Gateway in Form von 10.10.99.254 die in der pfSense existiert, für VLAN_99, da stehen hat.
Dazu müsste der Switch doch erstmal auf DHCP stehen, das scheint er ja nur auf VLAN 1 (IP 192.168.1.0 /24) zu machen?
Okay ich erstelle auf der pfsense nun ein neues Interface "MGMT"
- ich nehme igb2 dafür her auf der pfSense, also Zuweisungen und igb2 add geklickt
- IP Adresse des MGMT Lan -> 10.20.30.254 /24 - unter reservierte Netzwerke wird nichts blockiert
- ich gehe unter Dienste und erstelle einen DHCP Server dazu
- Range 10.20.30.100 bis 10.20.30.199
- Regel "Allow Any" - da eh nur zu Testzweck dazu im MGMT
Jetzt sollte die pfSense auf dem virtuellen MGMT Port (also dem physischen igb3 Port) erwartungsgemäß eine IP aus dem DHCP Bereich an ein angeschlossenes Gerät vergeben. Das teste ich doch gleich mal aus...
- Notebook mit Debian an die pfSense angeschlossen
- am Notebook DHCP auf Automatisch
- IP wird erwartungsgemäß auf 10.20.30.100 mit dem GW: 10.20.30.254 gesetzt.
Jetzt komme ich zurück auf deine Option 2
Das MGMT ist ja mein eigentliches VLAN_99.
Wie bekomme ich dieses VLAN nun auf 2 Ports an der pfSense "lauschen" lassen. Oder muss das VLAN_99 erstmal weg und später wieder hinzugefügt werden?
Sorry das ich mir etwas dämlich vorkomme ... aber ich möchte es lernen.
VG Alexander
ich bekomme das Konstrukt einfach nicht zum fliegen.
Egal was ich tue, es scheint vermutlich falsch zu sein.
Zitat von @aqui:
⚠️ Jetzt bekommst du allerdings ein Henne Ei Problem bei DHCP.
Setzt du das Management VLAN auf 99 verlierst du augenblicklich die Management Verbindung und kannst diese Einstellung nicht mehr sichern auf dem Switch. Der Switch erwartet jetzt die Management Verbindung mit einem VLAN 99 Tag.
Ein Reboot geht nicht, denn der würde die vorab aktive Konfig wiederherstellen mit der Management IP untagged im VLAN 1.
⚠️ Jetzt bekommst du allerdings ein Henne Ei Problem bei DHCP.
Setzt du das Management VLAN auf 99 verlierst du augenblicklich die Management Verbindung und kannst diese Einstellung nicht mehr sichern auf dem Switch. Der Switch erwartet jetzt die Management Verbindung mit einem VLAN 99 Tag.
Ein Reboot geht nicht, denn der würde die vorab aktive Konfig wiederherstellen mit der Management IP untagged im VLAN 1.
Habe ich verstanden, fällt auf weil er kein Default Gateway in Form von 10.10.99.254 die in der pfSense existiert, für VLAN_99, da stehen hat.
Oder mit etwas Trickserei...
- Switch erst über einen untagged Access Port ins VLAN 99 stecken das er dort eine IP zieht.
Dazu müsste der Switch doch erstmal auf DHCP stehen, das scheint er ja nur auf VLAN 1 (IP 192.168.1.0 /24) zu machen?
* Über diese IP aufs Management verbinden und danach das management auf VLAN 99 umstellen
- Jetzt den Port wieder auf den Trunkport zurückstecken und über die Trunk die bestehende VLAN 99 IP verbinden und dann die Konfig sichern.
Okay ich erstelle auf der pfsense nun ein neues Interface "MGMT"
- ich nehme igb2 dafür her auf der pfSense, also Zuweisungen und igb2 add geklickt
- IP Adresse des MGMT Lan -> 10.20.30.254 /24 - unter reservierte Netzwerke wird nichts blockiert
- ich gehe unter Dienste und erstelle einen DHCP Server dazu
- Range 10.20.30.100 bis 10.20.30.199
- Regel "Allow Any" - da eh nur zu Testzweck dazu im MGMT
Jetzt sollte die pfSense auf dem virtuellen MGMT Port (also dem physischen igb3 Port) erwartungsgemäß eine IP aus dem DHCP Bereich an ein angeschlossenes Gerät vergeben. Das teste ich doch gleich mal aus...
- Notebook mit Debian an die pfSense angeschlossen
- am Notebook DHCP auf Automatisch
- IP wird erwartungsgemäß auf 10.20.30.100 mit dem GW: 10.20.30.254 gesetzt.
Jetzt komme ich zurück auf deine Option 2
Das MGMT ist ja mein eigentliches VLAN_99.
Wie bekomme ich dieses VLAN nun auf 2 Ports an der pfSense "lauschen" lassen. Oder muss das VLAN_99 erstmal weg und später wieder hinzugefügt werden?
Sorry das ich mir etwas dämlich vorkomme ... aber ich möchte es lernen.
VG Alexander
es scheint vermutlich falsch zu sein.
Vielleicht auch nicht?!Fakt ist das die Option 2 nicht sauber rennt. Ich konnte das Verhalten mehrfach nachstellen und reproduzieren speziell wenn man im DHCP Modus das Tagging (anderes VLAN als 1) am Management Interface aktivierte. So gut wie immer kam es da zu einem Hänger.
Ein sicherer Workaround war dann immer die IP zusätzlich zum Tagging statisch zu konfigurieren. Über den Umweg einer statischen IP in Verbindung mit dem Tag bekam man sofort wieder Zugriff auf das Management MIT Tagging und konnte die Konfig dann sichern.
Danach klappte auch ein Zurückschalten auf die DHCP Option komischerweise problemlos. Auch ein Reboot überlebte diese Konfig.
Führte man allerdings einen Factory Reset aus und setzte das Management im DHCP Mode wieder auf Tagging (99) kam es wieder zu einem DHCP Hänger.
Wieder half ein Setzen einer statischen IP plus Tagging und danach ein Zurücksetzen mit Tag auf DHCP um das Problem dann zu fixen.
Die Switch Firmware ist hier also de facto nicht ganz astrein....
Dazu müsste der Switch doch erstmal auf DHCP stehen
Das ist richtig!!Du musst für den ersten Schritt also das Parent Interface mit einem DHCP Server versehen damit der Switch zuallererst über das Parent IP Netz (UNtagged) eine IP an VLAN 1 bekommt. So bekommst du ja überhaupt erstmal Management Zugang.
Um jetzt den IP Zugang tagged ins VLAN 99 zu legen musst du jetzt im IPv4 Management Adapter...
- die VLAN ID auf 99 setzen
- Die Adressierung auf "Static" setzen
- eine freie IP Adresse aus dem VLAN 99 IP Netz einsetzen und das Gateway statisch auf die VLAN 99 IP der pfSense setzen.
- Dann "Save / Submit" klicken
Du steckst den Management PC also um ins VLAN 99, checkst ob du dort eine korrekte IP und Gateway bekommen hast und pingst dann testweise die oben statisch konfigurierte IP des Switches.
Der sollte dann mit einem Reply seiner IP Antworten.
Ist dem so verbindest du dich aufs GUI via VLAN 99 was problem los klappen sollte und sicherst zuallererst einmal diese Konfig.
Damit hat dann der Switch erstmal eine sichere VLAN 99 Management IP Adresse, die auch einen Reboot überstehen sollte.
Ist dem so kannst du in einem nächsten Schritt das IPv4 Management von "Static" wieder zurückstellen auf DHCP Modus.
⚠️ ACHTUNG: Hier dann unbedingt unten den Haken bei Renew DHCP setzen damit ein neuer DHCP Request getriggert wird.
Beim Test hier bekam der Switch dann auch sofort eine IP Adresse im VLAN 99 per DHCP. Diese passte sich auch auf eine über die Mac Adresse konfigurierte neue IP an und überlebte mehrere Reboots.
Erst wenn man den Switch auf Werkseinstellung zurücksetzte kam es wieder zum "DHCP Hänger" wenn man ohne "Umweg" über eine statische IP das Tagging aktivierte.
Okay ich erstelle auf der pfsense nun ein neues Interface "MGMT"
Das kann man machen ist aber mehr oder minder sinnfrei und überflüssig!Logisch, denn über das LAGG0 Parent Interface bekommt der Switch ja immer gesichert eine VLAN 1 IP Adresse da dieses IP Netz UNtagged am Switch ankommt.
Egal was passiert und nach einem Werksreset bekommt der Switch immer eine IP um das Management zu erreichen und den o.a. "Umweg" über die statische IP im VLAN 99 einen Zugriff über das VLAN 99 zu erreichen.
Das dedizierte MGMT Interface an igb2 ist also nicht wirklich zwingend, schadet aber auch nicht.
Jetzt sollte die pfSense auf dem virtuellen MGMT Port (also dem physischen igb3 Port) erwartungsgemäß
Du meinst sicher igb2 oder?? Der igb3 Port ist bei dir physisch gar nicht der Firewall zugewiesen also ohne Funktion! Wie bekomme ich dieses VLAN nun auf 2 Ports an der pfSense "lauschen" lassen.
Das machst du wie oben schon genau beschrieben über den "static Umweg"....- Im Management Interface oben das VLAN 99 einstellen
- Adresskonfig auf "Static"
- Statische IP und Gateway vom VLAN 99 eingeben
- Aktivieren
- Management über VLAN 99 nach Ping Check connecten und Konfig sichern.
⚠️ Bei Letzterem an den "Renew DHCP" Haken denken!
Oder muss das VLAN_99 erstmal weg und später wieder hinzugefügt werden?
Nein, auf keinen Fall entfernen!Das VLAN 99 muss ja zwingend tagged auf dem LAGG0 Parent Interface bleiben. Logisch, denn das IPv4 Switch Management sendet und empfängt alle Management Daten ja dann mit einem VLAN 99 Tag im Ethernet Paket wenn das so eingestellt ist, was sein Gegenüber, die pfSense, dann ja über den Tag wieder dem korrekten VLAN (99) zuordnen kann. (Siehe dazu auch die VLAN Schnellschulung!!)
Moin,
also jetzt habe ich komplett den Faden verloren, daher hole ich Deine Option 2 abermals hervor. Ich habe Fragen diesbezüglich.
Das LAG muss aber zwingend eine IP Adresse auf der pfSense haben - sonst kein DHCP.
VLAN1? Management IP soll im Bereich 10.10.99.0 /24 liegen.
Ich kann jetzt meinen Laptop eine feste IP Adresse (z.B. die 192.168.1.250 und die SubnetzMaske 255.255.255.0 vergeben. Dann komme ich per WebGUI auf den Switch.. Kann die feste IP des Switches auf Beispiel: 10.10.99.10 setzen. Mit dem passenden Gateway auf der pfSense 10.10.99.254
Habe ich verstanden, sollte auch so sein, die pfSense kann aber den Switch nicht pingen/erreichen.
Wo stecke ich den Switch an der pfSense an? Ich gehe vom LAG aus?
Ich wüsste jetzt nicht, wo ich meinen Management PC einstecken soll im VLAN 99. Es ist ja nicht vorhanden, weil der Switch nicht tut.
Das wäre fein! Das ist das Ziel.
VG Alexander
also jetzt habe ich komplett den Faden verloren, daher hole ich Deine Option 2 abermals hervor. Ich habe Fragen diesbezüglich.
Zitat von @aqui:
2.) Management dediziert über VLAN 99:
Hier behälst du das VLAN 99 bei und setzt es auf das dafür vorgesehene IP Netz.
Das LAGG0 Interface bleibt im Assignment aber IP-technisch leer und wird nicht mit einer IP konfiguriert. So wird dann keinerlei UNtagged IP Traffic vom LAGG0 Interface gesendet sondern rein nur tagged Traffic über die VLANs.
Das wiederum erzwingt dann das du im Switch im "IP Management Menü" die Bindung der Management IP Adresse auf das VLAN 99 setzt! (Anstatt VLAN 1, siehe Screenshot oben!). So arbeitet die Switch Management IP Adresse tagged im VLAN 99.
⚠️ Jetzt bekommst du allerdings ein Henne Ei Problem bei DHCP.
Setzt du das Management VLAN auf 99 verlierst du augenblicklich die Management Verbindung und kannst diese Einstellung nicht mehr sichern auf dem Switch. Der Switch erwartet jetzt die Management Verbindung mit einem VLAN 99 Tag.
Ein Reboot geht nicht, denn der würde die vorab aktive Konfig wiederherstellen mit der Management IP untagged im VLAN 1.
Hier bleibt dir also nichts anderes als den Ablauf der Lease Time abzuwarten so das dem Switch eine neue Management IP zugeteilt wird. Dann kannst du das Setup sichern.
Hier behälst du das VLAN 99 bei und setzt es auf das dafür vorgesehene IP Netz.
Das LAGG0 Interface bleibt im Assignment aber IP-technisch leer und wird nicht mit einer IP konfiguriert. So wird dann keinerlei UNtagged IP Traffic vom LAGG0 Interface gesendet sondern rein nur tagged Traffic über die VLANs.
Das wiederum erzwingt dann das du im Switch im "IP Management Menü" die Bindung der Management IP Adresse auf das VLAN 99 setzt! (Anstatt VLAN 1, siehe Screenshot oben!). So arbeitet die Switch Management IP Adresse tagged im VLAN 99.
⚠️ Jetzt bekommst du allerdings ein Henne Ei Problem bei DHCP.
Setzt du das Management VLAN auf 99 verlierst du augenblicklich die Management Verbindung und kannst diese Einstellung nicht mehr sichern auf dem Switch. Der Switch erwartet jetzt die Management Verbindung mit einem VLAN 99 Tag.
Ein Reboot geht nicht, denn der würde die vorab aktive Konfig wiederherstellen mit der Management IP untagged im VLAN 1.
Hier bleibt dir also nichts anderes als den Ablauf der Lease Time abzuwarten so das dem Switch eine neue Management IP zugeteilt wird. Dann kannst du das Setup sichern.
Das LAG muss aber zwingend eine IP Adresse auf der pfSense haben - sonst kein DHCP.
Zitat von @aqui:
Du musst für den ersten Schritt also das Parent Interface mit einem DHCP Server versehen damit der Switch zuallererst über das Parent IP Netz (UNtagged) eine IP an VLAN 1 bekommt. So bekommst du ja überhaupt erstmal Management Zugang.
VLAN1? Management IP soll im Bereich 10.10.99.0 /24 liegen.
Um jetzt den IP Zugang tagged ins VLAN 99 zu legen musst du jetzt im IPv4 Management Adapter...
- die VLAN ID auf 99 setzen
- Die Adressierung auf "Static" setzen
- eine freie IP Adresse aus dem VLAN 99 IP Netz einsetzen und das Gateway statisch auf die VLAN 99 IP der pfSense setzen.
- Dann "Save / Submit" klicken
Ich kann jetzt meinen Laptop eine feste IP Adresse (z.B. die 192.168.1.250 und die SubnetzMaske 255.255.255.0 vergeben. Dann komme ich per WebGUI auf den Switch.. Kann die feste IP des Switches auf Beispiel: 10.10.99.10 setzen. Mit dem passenden Gateway auf der pfSense 10.10.99.254
Dann verlierst du erstmal sofort den Management Zugang. Logisch, denn der hängt jetzt im VLAN 99
Habe ich verstanden, sollte auch so sein, die pfSense kann aber den Switch nicht pingen/erreichen.
Wo stecke ich den Switch an der pfSense an? Ich gehe vom LAG aus?
Du steckst den Management PC also um ins VLAN 99, checkst ob du dort eine korrekte IP und Gateway bekommen hast und pingst dann testweise die oben statisch konfigurierte IP des Switches.
Der sollte dann mit einem Reply seiner IP Antworten.
Ist dem so verbindest du dich aufs GUI via VLAN 99 was problem los klappen sollte und sicherst zuallererst einmal diese Konfig.
Damit hat dann der Switch erstmal eine sichere VLAN 99 Management IP Adresse, die auch einen Reboot überstehen sollte.
Der sollte dann mit einem Reply seiner IP Antworten.
Ist dem so verbindest du dich aufs GUI via VLAN 99 was problem los klappen sollte und sicherst zuallererst einmal diese Konfig.
Damit hat dann der Switch erstmal eine sichere VLAN 99 Management IP Adresse, die auch einen Reboot überstehen sollte.
Ich wüsste jetzt nicht, wo ich meinen Management PC einstecken soll im VLAN 99. Es ist ja nicht vorhanden, weil der Switch nicht tut.
Ist dem so kannst du in einem nächsten Schritt das IPv4 Management von "Static" wieder zurückstellen auf DHCP Modus.
⚠️ ACHTUNG: Hier dann unbedingt unten den Haken bei Renew DHCP setzen damit ein neuer DHCP Request getriggert wird.
Beim Test hier bekam der Switch dann auch sofort eine IP Adresse im VLAN 99 per DHCP. Diese passte sich auch auf eine über die Mac Adresse konfigurierte neue IP an und überlebte mehrere Reboots.
Erst wenn man den Switch auf Werkseinstellung zurücksetzte kam es wieder zum "DHCP Hänger" wenn man ohne "Umweg" über eine statische IP das Tagging aktivierte.
⚠️ ACHTUNG: Hier dann unbedingt unten den Haken bei Renew DHCP setzen damit ein neuer DHCP Request getriggert wird.
Beim Test hier bekam der Switch dann auch sofort eine IP Adresse im VLAN 99 per DHCP. Diese passte sich auch auf eine über die Mac Adresse konfigurierte neue IP an und überlebte mehrere Reboots.
Erst wenn man den Switch auf Werkseinstellung zurücksetzte kam es wieder zum "DHCP Hänger" wenn man ohne "Umweg" über eine statische IP das Tagging aktivierte.
Das wäre fein! Das ist das Ziel.
VG Alexander
daher hole ich Deine Option 2 abermals hervor.
Wieso "abermals"? Ich ging davon aus das es dir ausschliesslich um die Option 2 geht?!Das LAG muss aber zwingend eine IP Adresse auf der pfSense haben - sonst kein DHCP.
Mit "LAG" meinst du das LAGG0 Parent Interface auf das deine VLANs gemappt sind, richtig?Wenn ja, dann ist das richtig!
Das IP Netz vom Parent Interface wird ja immer untagged gesendet und so bekommt der Switch die initiale VLAN 1 IP um aufs Management zugreifen zu können.
VLAN1? Management IP soll im Bereich 10.10.99.0 /24 liegen.
Ja, aber erst später wenn du das Management auf das VLAN 99 umgestellt hast. Dann bekommt das Management eine VLAN 99 IP.Um das aber überhaupt erstmal einstellen zu können brauchst du ja einen initialen Management Zugang und den bekommst du ja erstmal nur über das untagged VLAN 1 Interface Setup, sprich Parent Interface.
Danach erfolgt dann die Umstellung des IPv4 Management Setups im Switch über den "Umweg" VLAN 99 und erstmal statische IP weil der DHCP diesen Hänger in der Firmware hat.
Dann komme ich per WebGUI auf den Switch..
Richtig! Das ist der erste Schritt!Kann die feste IP des Switches auf Beispiel: 10.10.99.10 setzen. Mit dem passenden Gateway auf der pfSense 10.10.99.254
Auch das ist richtig. Leider hast du nicht geschrieben das oben dann gleichzeitig mit der Umstellung auf die .99.10er IP das VLAN auf 99 umgestellt werden muss!!! Logisch, damit der Switch Management Traffic mit einem 99er VLAN Tag gesendet wird um auch im 99er VLAN auf der pfSense zu landen was ja tagged am LAGG0 hängt.Unbedingt also das VLAN im Switch Management Setup auch auf 99 zusammen mit der statischen 99er IP setzen!!
die pfSense kann aber den Switch nicht pingen/erreichen.
WIE testest du das aus???- Idealerweise gehst du über dein separates "MGMT" Interface oder jedes andere VLAN Interface auf die pfSense.
- Dann ins Diagnostics Menü
- Dort wählst du Ping um ins Ping Menü zu kommen und gibst die konfigurierte Switch IP .99.10 an
- ⚠️ Als Absender IP (Source) erstmal das VLAN 99 Interface wählen um innerhalb des Netzes zu bleiben.
Es macht hier sehr viel Sinn vorher einen untagged Accessport im Switch einzurichten um von dort mit einem Test PC die VLAN 99 Connectivity direkt auf die pfSense und dann auch auf den Switch zu checken.
Ich wüsste jetzt nicht, wo ich meinen Management PC einstecken soll im VLAN 99
Eben in diesen testweise eingerichteten VLAN 99 Accessport am Switch. Das kannst du auch schon vorher, also vor der Management Umstellung machen um die VLAN 99 Connectivity auf die pfSense wasserdicht zu testen!Mit dem Rüstzeug solltest du es jetzt aber zum Fliegen bringen!
Hallo aqui,
ich bin schon ein wenig stolz das es nun läuft!
Leider bekommen die Synapsen noch nicht ganz die Kurve, warum ich nicht VLAN_99 als "Default VLAN" setzen kann.
Die Konfig am Switch ist nun folgend:
LAG
Port VLAN Membership
Besten Dank @aqui!
VG Alexander
ich bin schon ein wenig stolz das es nun läuft!
Leider bekommen die Synapsen noch nicht ganz die Kurve, warum ich nicht VLAN_99 als "Default VLAN" setzen kann.
Die Konfig am Switch ist nun folgend:
LAG
Port VLAN Membership
Besten Dank @aqui!
VG Alexander
ich bin schon ein wenig stolz das es nun läuft!
👏 👍 Glückwunsch!warum ich nicht VLAN_99 als "Default VLAN" setzen kann.
Vermutlich denkst du da zu kompliziert bzw. zu "kurvig" oder du hast dich oben nicht richtig ausgedrückt.Die Option das VLAN 99 als Default VLAN zu nutzen ist ja die beschriebene "Option 1".
Versteht man dich richtig wolltest du das oben ja explizit nicht sondern immer die Option 2 und es mit dem getaggten Management VLAN 99 umsetzen.
VLAN 99 als Default VLAN wäre natürlich das Einfachste. Dazu müsstest du dein dediziertes VLAN 99 auf der Firewall dann vollständig löschen und die 99er IP Adressierung auf das Parent Interface LAGG0 legen was dann UNtagged am Trunk anliegt (1U). Genau DAS war ja die "Option 1" die du ja eigentlich nicht wolltest...
Beide Optionen sind aber machbar und es letztlich egal wie man es löst. Die eine eben etwas "steiniger". 😉
Der einzige Unterschied ist das man eine dedizierte VLAN ID fürs Management hat. Bei der Option 1 Lösung (Default VLAN) muss man eben immer im Hinterkopf haben das das Parent Interface IP Netz dann das Management VLAN ist. Letztlich alles nur eine kosmetische Sichtweise aber der eine so der andere so. Die HW bietet ja immer die Möglichkeiten (fast) alles umzusetzen an persönlichen Vorlieben...
Besten Dank
Immer gerne... 😊
