VLAN-/DHCP-Probleme

[zaphod88]

Hallo zusammen,

ich habe ein Problem mit einer VLAN-Konfiguration und weiß im Moment nicht weiter.

Hier mal die Ausgangslage:
- Watchguard-Firewall für das Routing:

• VLAN 110: LAN
• VLAN 111: WLAN mit Zugriff auf LAN-Hardware
• VLAN 120: Gäste-WLAN

- HPE Aruba Switch (24 Ports, VLAN-fähig, managed) hängt hinter der Watchguard. Port-/VLAN-Konfiguration:

• VLAN 1 (Default): Ports 1,25-28 untagged
• VLAN 110: Port 1 tagged (Firewall), Ports 2-11, 13-24 untagged
• VLAN 111: Ports 1-11 tagged
• VLAN 120: Ports 1-11 tagged

An den Ports 1-11 hängen Unifi APs. Dort konfiguriert:

• LAN/Netzwerk für die Verwaltung
• VLAN-only 111
• VLAN-only 120
• sowie zwei SSIDs, jeweils eine entsprechend den VLANs.

Es sei erwähnt, dass ich auf die Watchguard keinen Zugriff habe, weil sie von extern betreut wird. Das zuständige Systemhaus hatte dazu geraten, das VLAN 111 aufzumachen, weil im 110er-Netz die IPs ausgegangen sind.
Nun tritt das Problem auf, dass unabhängig vom AP, mit dem das Gerät verbunden ist, Endgeräte sich keine IP im VLAN 111 ziehen können. Im VLAN 120 tritt das Problem ab und an auch auf, aber weniger häufig. Freie IPs gibt es in beiden Netzen - daran liegt es also nicht. Das Problem tritt auch auf, unmittelbar nachdem die Firewall neu gestartet wurde. Ich hatte dem zuständigen Mitarbeiter damals dort gesagt, dass er doch auch die DHCP-Range des 110er-Netzes erweitern könnte, aber mich dann doch zu einem VLAN 111 breitschlagen lassen. Bereue ich langsam...

Was habe ich probiert?

• verschiedene Endgeräte mit VLAN 110 verbunden - klappt mal, klappt mal nicht.
• APs zurückgesetzt, neu gestartet, neu eingebunden
• Kabel zwischen APs und Switch getauscht
• Firewall und Router neu gestartet

Hat jemand eine zündende Idee oder sieht hier irgendwo einen offensichtlichen Konfigurationsfehler?
Danke schonmal.

 

[KillerCow]

Mit Wireshark schauen, was genau passiert, wenn es nicht klappt.
Sind davon nur bestimmte Arten von Geräten betroffen?
Woher weiß du, dass der DHCP-Server in dem Moment noch Leases frei hat?
Gibt es Infos im Log des DHCP-Servers?
Wird DHCP in jedem Netz einzeln verteilt oder hängt der DHCP Server in einem Netz und es wird per DHCP-Relay in die anderen Netze verteilt?

 

[t-6]

Kein offensichtlicher Konfigurationsfehler, aber zeig doch mal bitte von Port 1-11 die VLAN-Konfiguration. Von der CLI oder aus der WebGUI.

Desweiteren:

An den Ports 1-11 hängen Unifi APs. Dort konfiguriert:

• LAN/Netzwerk für die Verwaltung
• VLAN-only 111
• VLAN-only 120
• sowie zwei SSIDs, jeweils eine entsprechend den VLANs.

Was ist damit gemeint? Es ist eine Sache Netzwerke/VLANs im Unifi Controller anzulegen. Es ist eine andere Sache entsprechende WLAN-Gruppen mit diesen Netzwerken auszustatten und die APs in die Gruppen aufzunehmen (bzw. neuerdings andersherum, WLANs in AP-Gruppen aufzunehmen). Hier wären entsprechende Screenshots interessant.

Ansonsten klingt es ein wenig danach als ob entweder nicht an allen Switchports (und damit APs) die VLANs korrekt getaggt sind und/oder vielleicht im Unifi Controller die Netzwerke/VLANs nicht korrekt zugewiesen sind.

Unifi Controller, APs, Switch & Firewall haben aktuelle Firmwares?

 

[Poati]

Von dem was du an Informationen hast oder zumindest du hier zur Verfügung stellst, scheint es zu passen.

Wahrscheinlich meintest du, dass auf 2-11 APs angeschlossen sind. 1 wäre doch die Firewall.

Wozu wir aber noch nichts wissen ist der DHCP Server. Mehrere für die Netze oder per Relay? Übernimmt das die Firewall?

 

[TheCadillacMan]

Noch eine Idee: Ist DHCP Snooping auf dem Switch deaktiviert bzw. richtig eingestellt?
Ich hatte mich mal gewundert warum das Gast-WLAN nicht funktioniert bis ich gemerkt habe, dass ich die falsche IP eingetragen hatte.

 

[Pilatesjünger]

Hört sich stark nach watchguard an. Die macht dann wohl auch dhcp/routing für jedes vlan?

 

[zaphod88]

Woher weiß du, dass der DHCP-Server in dem Moment noch Leases frei hat?
Gibt es Infos im Log des DHCP-Servers?
Wird DHCP in jedem Netz einzeln verteilt oder hängt der DHCP Server in einem Netz und es wird per DHCP-Relay in die anderen Netze verteilt?

Besagtes Systemhaus hat nachgeschaut - da sind noch Adressen frei. In dem Fall, dass keine IP bezogen werden kann, zeigt wohl auch das DHCP-Log nichts an bzw. gibt es keinen Traffic Richtung Watchguard. Die Watchguard übernimmt das DHCP in alle Netze.

An Geräten sind scheinbar vorrangig Windows 10-Laptops betroffen, aber seltener auch andere (Smartphones/Tablets).

Unifi Controller, APs, Switch & Firewall haben aktuelle Firmwares?

Firmwares sind überall aktuell.

Screenshots:

Äquivalent auch VLAN 120 bzw. entsprechendes WLAN.

Nicht wundern wegen des LAN-Subnetzes - das sind die Defaults, die aber m.W. nur in Zusammenspiel mit Unifi-Router und Switches eine Auswirkung haben.

Wahrscheinlich meintest du, dass auf 2-11 APs angeschlossen sind. 1 wäre doch die Firewall.

Ja, natürlich.

Ergänzung (3. Juni 2021)

Die macht dann wohl auch dhcp/routing für jedes vlan?

Ja.

 

[KillerCow]

bzw. gibt es keinen Traffic Richtung Watchguard.

Na dann auf einem der betroffenen Geräte nen Wireshark anwerfen, einmal (oder mehrmals) nen DHCP Renew durchführen und schauen, was passiert. Am besten schaut gleichzeitig auch wer auf die Firewall.

Und wir reden hier aktuell nur von IPv4 oder auch von IPv6?

 

[zaphod88]

Und wir reden hier aktuell nur von IPv4 oder auch von IPv6?

Ja, es wird nur IPv4 genutzt.

 

[Raijin]

Das zuständige Systemhaus

Dann sollen die doch auch das Problem lösen?!? Es klingt massiv nach einer Firma und dies hier ist ein Forum für Heimnetzwerke. Wenn bereits ein Systemhaus mit der Betreuung des Netzwerks betraut wurde, ist es auch Aufgabe des Systemhauses, der Ursache nachzugehen.

weil im 110er-Netz die IPs ausgegangen sind.

VLANs sind ja nicht dazu da, zusätzliche DHCP-Bereiche zu erstellen. Wenn in einem Subnetz die IP-Adressen im DHCP ausgehen, erweitert man dessen DHCP-Pool. Reicht das ganze Subnetz nicht mehr aus, erweitert man das Subnetz (zB /23er Subnetzmaske statt /24er). Ein neues VLAN bedeutet ein komplett anderes Netzwerk mit eigenem Subnetz und in der Regel eben auch komplett anderen Zugriffsrechten innerhalb der Firewall. Vor allem aber ist ein anderes VLAN eine eigene Broadcast-Domäne und somit funktionieren einige Dienste, die auf Broadcasts aufbauen, nicht mehr, weil Client und Server schlicht und ergreifend in verschiedenen Netzwerken liegen. Das ist einfach sowas von am eigentlichen Problem vorbei, da ist es klar, dass Nebeneffekte auftreten.

Ich hatte dem zuständigen Mitarbeiter damals dort gesagt, dass er doch auch die DHCP-Range des 110er-Netzes erweitern könnte, aber mich dann doch zu einem VLAN 111 breitschlagen lassen. Bereue ich langsam...

Genau das wäre aber der richtige Weg gewesen. Hättet ihr den DHCP-Bereich vergrößert und/oder die Lease Time runtergesetzt, wäre ansonsten alles beim alten geblieben.

In dem Fall, dass keine IP bezogen werden kann, zeigt wohl auch das DHCP-Log nichts an bzw. gibt es keinen Traffic Richtung Watchguard.

Dir - oder besser dem Systemhaus - bleibt jetzt eigentlich kaum etwas anderes übrig als mit WireShark den DHCP-Traffic zu analysieren, einmal an einem Client und einmal am DHCP-Server. Ggfs sogar "unterwegs" mittels Port Mirror bzw. LAN-TAP, um zu checken ob der Traffic durch die Uplinks geht, sollte er nicht beim DHCP-Server ankommen. Für solche Zwecke habe ich beispielsweise einen Throwing Star (allerdings China-Nachbau von aliexpress für 8€). Damit kann man sich wunderbar überall in eine LAN-Verbindung einklinken und mitlesen.

 

[Poati]

Um zu sehen, was auf Seiten des Clients passiert an diesen Artikel halten:

https://docs.microsoft.com/de-de/windows-server/troubleshoot/troubleshoot-problems-on-dhcp-client

Du sagst aber, dass es zeitweise kurz funktioniert? Wie verhält es sich, wenn die Geräte eine (passende) statische IP aus dem Netz bekommen?

 

[zaphod88]

Dann sollen die doch auch das Problem lösen?!? Es klingt massiv nach einer Firma und dies hier ist ein Forum für Heimnetzwerke. Wenn bereits ein Systemhaus mit der Betreuung des Netzwerks betraut wurde, ist es auch Aufgabe des Systemhauses, der Ursache nachzugehen.

Habe zu denen ehrlich gesagt nur mäßig Vertrauen, z.B. weil der zuständige Techniker ursprünglich nicht alle AP-Ports mit VLAN 120 auch mit dem neuen VLAN 111 versehen hat, sondern nur ein paar. Da hab ich mich auch schon gewundert, warum das neue WLAN nicht läuft... War also schon mal Fehlersuche angesagt... aber ja, grundsätzlich ist es deren Verantwortung. Mir ging es hauptsächlich darum, ob ich hier irgendwo den Wald vor lauter Bäumen nicht sehe und da vielleicht ein einfach zu behebender Fehler z.B. in der Port-Konfig steckt, aber das scheint ja nicht der Fall zu sein.

Du sagst aber, dass es zeitweise kurz funktioniert? Wie verhält es sich, wenn die Geräte eine (passende) statische IP aus dem Netz bekommen?

Wenn ein Gerät per DHCP keine IP zugewiesen bekommt, funktioniert es auch mit statischer IP nicht. "Kurzzeitig" ist also der falsche Ausdruck - es funktioniert auf manchen Geräten und auf manchen nicht.

 

[Raijin]

Habe zu denen ehrlich gesagt nur mäßig Vertrauen

Das ist natürlich denkbar schlecht...

es funktioniert auf manchen Geräten und auf manchen nicht

Hast du denn mal geprüft ob das geräte- oder portabhängig ist? Also einfach mal funktionierendes und nicht-funktionierendes Gerät am Switch vertauscht?

Übrigens: Wenn ein nicht-vlan-fähiges Gerät an einem Port mit einem untagged und mehreren tagged VLANs hängt, wird dieses Gerät immer dem untagged VLAN zugeordnet. Deswegen sollte man eigentlich auch nur so konfigurieren:

Uplinks zwischen VLAN-Switches und/oder VLAN-APs: Trunk-Port, alle nötigen VLANs als tagged
Ports für Endgeräte: Das jeweils gewünschte VLAN als untagged

Wenn ich das richtig sehe, sind bei dir Ports 1-11 Trunks mit VLAN tagged 110+111+120, während 12-24 untagged 110 sind. Heißt das, dass für 111+120 keine Access Ports für Endgeräte vorgesehen sind? Gibt es diese VLANs also effektiv nur im WLAN?

 

[zaphod88]

Hast du denn mal geprüft ob das geräte- oder portabhängig ist? Also einfach mal funktionierendes und nicht-funktionierendes Gerät am Switch vertauscht?

Ja, ich habe probiert, die Ports der APs zu tauschen. So wirklich einen Einfluss hat das auch nicht gehabt - mitunter kam es auch vor, dass am selben AP ein Gerät eine IP beziehen konnte und ein zweites nicht.

Wenn ich das richtig sehe, sind bei dir Ports 1-11 Trunks mit VLAN tagged 110+111+120, während 12-24 untagged 110 sind. Heißt das, dass für 111+120 keine Access Ports für Endgeräte vorgesehen sind? Gibt es diese VLANs also effektiv nur im WLAN?

So ist es: Die beiden VLANs 111 und 120 sind nur für die entsprechenden WLANs vorgesehen. Port 12 war nur mal zum Testen 120 untagged. Port 24 geht auf einen zweiten dummen Switch, an dem alle kabelgebundenen Geräte (vorrangig Drucker u.ä.) im 110er-Netz hängen.

 

[zaphod88]

Kleines Update: Nach einiger Rumprobiererei und Recherche hat sich herausgestellt, dass das Problem bei den APs zu liegen scheint. In den Unifi-Foren gibt es einige Threads dazu. Die APs leiten zwar den DHCP-Request der Clients weiter, aber nicht die Antwort des DHCP-Servers - oder teilweise erst nach 10 Minuten oder so. Das Problem tritt wohl hauptsächlich dann auf, wenn Switch und DHCP nicht von Unifi sind - wie bei mir.
Ich habe einen der APs probeweise mal auf eine Firmware downgegradet, bei der das Problem angeblich nicht so extrem ist. Da ein Reboot der APs das Problem temporär auch löst, mache ich mich nächste Woche parallel mal daran, ein Powershell-Skript zu schreiben, das sich zeitgesteuert per SSH auf den APs einloggt und sie morgens außerhalb der Arbeitszeiten neu startet.

 

[Raijin]

Hast du eine Quelle dazu? Ich nutze seit Jahren und bei vielen Bekannten Unifi APs mit Netgear oder Zyxel Switches und solche Probleme sind mir neu.

 

[t-6]

Die APs leiten zwar den DHCP-Request der Clients weiter, aber nicht die Antwort des DHCP-Servers - oder teilweise erst nach 10 Minuten oder so. Das Problem tritt wohl hauptsächlich dann auf, wenn Switch und DHCP nicht von Unifi sind - wie bei mir.

Das widerspricht doch aber der Feststellung, dass selbst Geräte mit statischen IPs sporadisch Probleme haben.

Vielleicht noch ein paar Ansätze:
Lass mal Pingplotter o.Ä. auf die APs laufen um zu checken, ob sie nicht einfach aus dem Netz fallen.
Sind im Unifi Controller Einträge zu sehen dass die APs sich trennen & irgendwann neu verbinden?
Spaßeshalber gerne auch mal die Funktion im Unifi Controller aktivieren, die das Ausstrahlen der SSIDs unterbindet wenn der AP feststellt, dass sein Gateway nicht erreichbar ist.
Hintergrund: Selbst wenn die Netzwerkverbindung wegfällt weil die Verkabelung wackelig ist, kann PoE meistens noch durchkommen & den AP weiterbetreiben (was natürlich sinnfrei ist wenn der AP keinen Uplink [auch keinen Wireless] hat; daher die Funktion)

Aber solche Probleme in der Kombination wären mir auch neu. Wir haben bspw. einen Kunden mit ausschließlich Aruba-Switches, ge-VLANten WLANs (1 WLAN für Management-Ebene(nativ/untagged), 1x internes WLAN/VLAN, 1x GastWLAN/VLAN & 4 WLANs die alle auf dasselbe VLAN gehen); 1 & Unifi NanoHDs mit immer aktuellster Firmware. Keinerlei Meldungen oder Kuriositäten so wie du sie beschreibst.

 

[zaphod88]

Das widerspricht doch aber der Feststellung, dass selbst Geräte mit statischen IPs sporadisch Probleme haben.

An sich schon, das stimmt... Nur wenn über den AP überhaupt keine IP-Kommunikation (egal ob dynamisch oder statisch) läuft, kann ja eigentlich auch bei statischer IP kein Netzzugang da sein, oder? Keine Ahnung, ehrlich gesagt...

Vielleicht noch ein paar Ansätze:
Lass mal Pingplotter o.Ä. auf die APs laufen um zu checken, ob sie nicht einfach aus dem Netz fallen.
Sind im Unifi Controller Einträge zu sehen dass die APs sich trennen & irgendwann neu verbinden?

Nein, die APs sind permanent da. Bin mir allerdings nicht sicher, wie schnell der Controller reagiert - ist in einem anderen Standort und Subnetz per VPN angebunden.

Spaßeshalber gerne auch mal die Funktion im Unifi Controller aktivieren, die das Ausstrahlen der SSIDs unterbindet wenn der AP feststellt, dass sein Gateway nicht erreichbar ist.

Das ist ne gute Idee - das probier ich mal.

Aber solche Probleme in der Kombination wären mir auch neu. Wir haben bspw. einen Kunden mit ausschließlich Aruba-Switches, ge-VLANten WLANs (1 WLAN für Management-Ebene(nativ/untagged), 1x internes WLAN/VLAN, 1x GastWLAN/VLAN & 4 WLANs die alle auf dasselbe VLAN gehen); 1 & Unifi NanoHDs mit immer aktuellster Firmware. Keinerlei Meldungen oder Kuriositäten so wie du sie beschreibst.

Mir im Grunde auch. Bis zur VLAN-Einrichtung lief alles tadellos, aber ich habe mich dann erinnert, dass ich 1-2 Tage vorher die APs auf die neueste Firmware gehoben hatte. Vielleicht lag das Problem also auch dort.

Ich habe es mit einem der "Problemgeräte" (Windows 10-Laptop) an allen gestörten APs versucht. Nach einem Reboot des APs lief alles jeweils wieder einwandfrei, auch bei Erneuerung des DHCP-Lease.

Hast du eine Quelle dazu?

Sicher, z.B. hier:
https://community.ui.com/questions/...rebooted/59c3dee6-9e31-4756-92e0-361b78d3b48d
https://community.ui.com/questions/UniFi-AP-DHCP-problem/0e4b0b7a-7649-4d8d-b6cf-a08f9a37d0c0

Zweiteres kommt ja sehr nah an mein Problem dran bzw. ist eigentlich dasselbe. Switch-Firmware ist aber aktuell, daran kanns also nicht liegen.

 

[t-6]

An sich schon, das stimmt... Nur wenn über den AP überhaupt keine IP-Kommunikation (egal ob dynamisch oder statisch) läuft, kann ja eigentlich auch bei statischer IP kein Netzzugang da sein, oder?

Naja. DHCP ist ein Verfahren über Broadcast.
Sobald ein Client aber eine IP hat (egal ob dynamisch oder statisch), dann läuft der Traffic des Clients über Unicast. DHCP spielt dann keine Rolle bzw. erst mal keine Rolle mehr.