Verhalten von UniFi und VLANs (IEEE 802.1Q)

[emulbetsup]

Guten Abend,

bei der Umsetzung einer größeren WLAN-Lösung auf Basis von Ubiquiti beobachte jetzt schon wiederholt ein sehr merkwürdiges Verhalten.

Folgendes Szenario habe ich hier aufgebaut:

Relevante Geräte
Dreammaschine Pro
US-24-500W
UAP-AC-PRO

VLANs

VLAN ID	Name	Subnetz	SSID
natives LAN	MGMT	192.168.128.0/22	MGMT
VLAN 10	Hotspot	VLAN only	Hotspot
VLAN 20	Company_Guest	VLAN only	Company_Guest
VLAN 30	Company	VLAN only	Company

Port Profiles

Portprofile	MGMT	Hotspot	Company_Guest	Company
All	Untagged	Tagged	Tagged	Tagged
Disabled	Forbidden	Forbidden	Forbidden	Forbidden
MGMT	Untagged	Forbidden	Forbidden	Forbidden
Hotspot	Forbidden	Untagged	Forbidden	Forbidden
Hotspot_UL	Forbidden	Tagged	Forbidden	Forbidden
Company_Guest	Forbidden	Forbidden	Untagged	Forbidden
Company	Forbidden	Forbidden	Forbidden	Untagged

Portprofile Dreammaschine Pro

Die Dreammaschine ist lediglich DHCP und Gateway für das native Netzwerk. Die drei anderen Netze haben Ihre Uplinks und Ihren DHCP auf den Ports 2,4 und 6. Da der Uplink des Netzes Hotspot auf der Leitung Tagged VLAN 10 spricht, ist das Port Profile entsprechend konfiguriert.

Portprofile US-24-500W

Der AP an Port 2 ist neu und soll der Installation hinzugefügt werden. Dazu habe ich neben dem Port Profile "All" auch das Port Profile "MGMT" versucht, jedoch kommt es in beiden Fällen zu genau dem gleichen Phänomen:

Die bereits konfigurierten APs waren bereits mit dem System verheiratet, bevor der Uplink "Hotspot_UL" verbunden war. Wie man in WireShark schön beobachten kann, antworten auf das DHCP-Discover des APs beide Gateways, obwohl auf dem Port nur das MGMT Netz gelten darf. Hier wäre ja die Dreammaschine der alleinige DHCP. Adopten lässt sich der AP übrigens so auch nicht, weil er ja mit der Dreammaschine nicht im gleichen Netz ist und er aus dem Gästenetz ohnehin nicht ohne Voucher ins Internet kommt.

Was genau läuft hier bitte schief?

 

[Twostone]

Du hast keine passenden Filterregeln für den Port definiert. Verwerfe alle DHCP-Anfragen und/oder Antworten für bzw. von Ports, die auch keine senden sollen. In Deinem Falle Anfragen an Adressen und Antworten, die nicht von Deinem gewünschten DHCP-Server kommen bzw. an selbigen gehen.

 

[emulbetsup]

Es sollen ja grundsätzlich DHCP-Anfragen über den Port laufen, aber eben nur für VLAN 10. Das native Network und die anderen VLANs sollen aus anderen Quellen bedient werden. Mein Problem ist eher, dass Ubiquiti hier die gesetzten Portprofile und VLANs ignoriert.

 

[xammu]

ich glaube, dein Problem müsste das Untagged bei Hotspot sein. Allerding müsste dann ein DHCP aus Company auch antworten, sofern da einer läuft.

Wenn ich das richtig verstehe, sollten nur im MGMT ungetaggte Pakete rumschwirren.

 

[t-6]

Mal mal bitte ein Verkabelungsschema auf, inklusive der "Uplinks" zu den Netzen. Welches Kabel geht in welches Gerät.
Hier fehlen ein Haufen Infos, denn bspw. zähle ich 9 APs aber nur 2 PoE-Verbraucher am Unifi Switch. Was ist mit Port 16 & SFP1 im Unifi-Switch? Uplink zur DMP sind das ja anscheinend nicht (das wäre P23).
Hängen an den Ports noch weitere Switches?

Und was ist überhaupt der Hintergrund für dieses Konstrukt, also warum gibt es hier eine Dream Machine Pro parallel zu einem angedeuteten größeren Netzwerk mit separaten Gateways?

Du hast keine passenden Filterregeln für den Port definiert. Verwerfe alle DHCP-Anfragen und/oder Antworten für bzw. von Ports, die auch keine senden sollen. In Deinem Falle Anfragen an Adressen und Antworten, die nicht von Deinem gewünschten DHCP-Server kommen bzw. an selbigen gehen.

Dass zwei DHCP-Server antworten ist ein Symptom für eine unerwünschte VLAN-"Brücke"; die Broadcastdomänen zwischen dem MGMT-Netz & dem Hotspot-Netz sind nicht korrekt getrennt, was auch mit DHCP-Snooping ein Sicherheitsrisiko ist.

Hier ist möglicherweise irgendwo ein Kabel zwischen einem Port mit Profil MGMT/All (kommt aus Sicht der APs auf dasselbe hinaus) & einem untagged Hotspot-Port verbunden.*
Wozu gibt es überhaupt ein Profil für untagged Hotspot-Ports? Für den Uplink ja nicht; der läuft ja tagged.


*oder, ganz bescheuert, aber auch schon gesehen, deswegen erwähn ich es lieber: Ein Notebook ist per LAN mit einem untagged MGMT-Port verbunden, per WLAN mit dem Hotspot und die beiden Netzwerkkarten wurden gebrückt.
Nachher ists noch das Notebook vom Netzwerk-Techniker der per LAN im MGMT-Netz hängt um auf den Unifi Controller zu kommen aber gleichzeitig im Hotspot-WLAN um das zu testen, hat aber vergessen die NIC-Brücke rauszunehmen die er kurz vorher gebraucht hat um kurzzeitig einem nicht-WLAN-fähigen Gerät über seinen Handy-Hotspot Interrnetzugang zu gewähren.

 

[emulbetsup]

Werde heute Abend nochmal ausführlich antworten. Das Problem tritt nicht auf wenn ich einen Cisco Switch mit der folgenden Config auf den Ports zwischen die Dreammaschine und dem Uplink vom Hotspot klemme.


switchport trunk allowed vlan 10
switchport mode trunk
no switchport trunk native vlan

 

[emulbetsup]

Besten Dank für euren Input!

Mal mal bitte ein Verkabelungsschema auf, inklusive der "Uplinks" zu den Netzen. Welches Kabel geht in welches Gerät.
Hier fehlen ein Haufen Infos, denn bspw. zähle ich 9 APs aber nur 2 PoE-Verbraucher am Unifi Switch. Was ist mit Port 16 & SFP1 im Unifi-Switch? Uplink zur DMP sind das ja anscheinend nicht (das wäre P23).
Hängen an den Ports noch weitere Switches?

Das Netz ist deutlich größer, was aber für das Verhalten hier keine Rolle spielt. Werden die Uplinks zu den anderen Netzgeräten getrennt, besteht das Netz tatsächlich nur noch aus Dreammaschine und dem US-24-500W. Das Verhalten tritt aber trotzdem auf.

Und was ist überhaupt der Hintergrund für dieses Konstrukt, also warum gibt es hier eine Dream Machine Pro parallel zu einem angedeuteten größeren Netzwerk mit separaten Gateways?

Es gibt insgesamt vier Netze, die auf der gleichen Hardware laufen sollen. Jedes Netz soll dabei sein eigenes Gateway haben, weswegen das Konstrukt mit den VLANs so aussieht. Die Dreammaschine ist also nicht Gateway für alle vier Netze, sondern lediglich das Gateway für das MGMT Netz. Das sind weitestgehend Vorgaben von außen.

Dass zwei DHCP-Server antworten ist ein Symptom für eine unerwünschte VLAN-"Brücke"; die Broadcastdomänen zwischen dem MGMT-Netz & dem Hotspot-Netz sind nicht korrekt getrennt, was auch mit DHCP-Snooping ein Sicherheitsrisiko ist.

Das sehe ich genauso. Das darf so nicht sein.

Hier ist möglicherweise irgendwo ein Kabel zwischen einem Port mit Profil MGMT/All (kommt aus Sicht der APs auf dasselbe hinaus) & einem untagged Hotspot-Port verbunden.*

Eine Brücke im eigentlichen Sinn kann ich als Ursache ausschließen. Zum einen waren die WLAN-Netze noch gar nicht aktiv und zum anderen löst wie oben erwähnt ein Cisco-Switch mit der Port-Konfiguration, nach der sich auch die Dreammaschine verhalten sollte, das Problem. Die Portkonfiguration auf dem Cisco-Switch entspricht der Sache nach der Portkonfiguration des Ubiquiti.

Wozu gibt es überhaupt ein Profil für untagged Hotspot-Ports? Für den Uplink ja nicht; der läuft ja tagged.

Das ist das Default-Profil, das automatisch mit dem Netz angelegt wird und weder gelöscht noch editiert werden kann. Grundsätzlich wird es von Testzwecken mal abgesehen nicht benötigt.



Auf dem Uplink "Hotspot_UL" werden auch noch andere VLANs gesprochen. Hier sieht der Ubiquiti Switch Traffic aus den folgenden anderen VLANs:

Untagged
VLAN 10
VLAN 20
VLAN 30
VLAN 40

Die Netze werden aber von uns nicht administriert. Offiziell wissen wir nur von VLAN 10, auf das unser Traffic aus dem Netz übergeben werden soll.

Grundsätzlich darf das für die Konfiguration keine Rolle spielen und Ubiquiti verletzt hier trotz korrekt gesetztem Portprofil (mehrfach überprüft) die VLAN-Grenzen.

Weiß jemand (vielleicht @Raijin oder @conf_t ) aus dem Kopf, wie das definierte Verhalten nach dem zugehörigen RFC ist? AFAIR verhält sich Cisco hier in einem Detail anders als andere Hersteller. IMHO ist das Verhalten von Ubiquiti hier aber in jedem Fall falsch.

 

[conf_t]

Was ist deine Frage genau? Welches Verhalten bei was? War jetzt 2x den Thread durch, verstehe zwar dein Problem, aber nicht was du Rajin oder mich genau fragen willst. Ehrlich bin ich eher der Praktiker, d.h. ich weiß wie einzelne Hersteller was umsetzen, aber RfCs lesen ist nicht mein Hobby.
Mit Mgmt meinst du das Management Netz?

Eine CLI haben die Teile nicht. Aus Erfahrung traue ich GUIs 0 cm über den weg. Wenn manuell konfigurieren Nachmöglichkeit CLI. Da schon so manche Konfig bei GUIs nicht immer sauber bei allen Herstellern übernommen wurde. Oder gibt es eine Ansicht, in der die GUI mal mehr Details zu der .1Q Konfig ausspuckt? Ist ja rudimentärer als mein Linksys GS108 unterm Schreibtisch zu Haus.

Ich selbst arbeite nicht mit Ubquiti, aber es gab / gibt(?) Hersteller bei denen es immer ein untagged Port über einen .1Q Link übergtragen werden muss.

Hast du ausgeschlossen, dass die VLAN-Kopplung nicht an einem anderen Netzwerkgerät stattfindet?
In welchem VLAN schickt der AP das DHCP-Discover raus?

VLANs

VLAN ID	Name	Subnetz	SSID
natives LAN	MGMT	192.168.128.0/22	MGMT

Wenn möglich würde ich darauf verzichten, weil ja jedes Gerät dann gleich im Mgmt-VLAN ist, wenn keine spezielle Portkonfig aktiv ist. Daraus besser auch ein VLAN nutzen.

 

[emulbetsup]

Danke für deine schnelle und ausführliche Antwort!

Was ist deine Frage genau? Welches Verhalten bei was? War jetzt 2x den Thread durch, verstehe zwar dein Problem, aber nicht was du Rajin oder mich genau fragen willst. Ehrlich bin ich eher der Praktiker, d.h. ich weiß wie einzelne Hersteller was umsetzen, aber RfCs lesen ist nicht mein Hobby.
Mit Mgmt meinst du das Management Netz?

Hab vor einiger Zeit einen Thread in einem anderen Forum gelesen, in dem unterschiedliches Verhalten von Switchen beim Handling von native VLANs auf Trunks beschrieben wurde:

Der VLAN Standard wird im IEEE Dokument 802.1q beschrieben: http://de.wikipedia.org/wiki/IEEE_802.1q
An diesen weltweiten Standard müssen sich also alle Hersteller halten. Der .1q Standard schreibt vor das ungetaggte Pakete ohne ein führende VLAN ID im Ethernet Header an einem Trunk Port ins default VLAN geforwardet werden. Dort hättest du also die ganz genaue Erklärung für das Verhalten.
Es halten sich aber (wie so oft) nicht alle Hersteller an diese Norm, da, wenn man das IEEE .1q Papier etwas liberaler auslegt, das auch nur eine Empfehlung ist und keinen strikte Vorschrift.
Andere Hersteller wie Brocade, Juniper usw. forwarden generell nichts ungetaggtes auf Trunk Ports ohne eine entsprechende Konfiguration auf den Geräten.
Es gibt also sehr wohl erhebliche Unterschiede in der Handhabung der 802.1q Norm, was du allerdings als bekennender Cisco Knecht, der nur diese Welt derzeit kennt, nicht sehen kannst ohne Geräte anderer Hersteller.
"Native VLAN" bezeichnet also immer Traffic ohne eine identifizierende VLAN ID, also gewissermassen nackten Ethernet Traffic, den man in einem VLAN Umfeld nicht genau einem VLAN zuordnen kann.

Quelle

Hier hatte ich die Hoffnung, dass ihr hierzu was sagen könnt. Im Grunde ist es für das Problem aber auch egal, da das DHCP-Discover des Clients den Port ja abseits des konfigurierten VLAN 10 verlassen haben muss. Die Antwort des DHCPs im falschen VLAN ist ja eigentlich nur die Fortsetzung.

Eine CLI haben die Teile nicht. Aus Erfahrung traue ich GUIs 0 cm über den weg. Wenn manuell konfigurieren Nachmöglichkeit CLI. Da schon so manche Konfig bei GUIs nicht immer sauber bei allen Herstellern übernommen wurde. Oder gibt es eine Ansicht, in der die GUI mal mehr Details zu der .1Q Konfig ausspuckt? Ist ja rudimentärer als mein Linksys GS108 unterm Schreibtisch zu Haus.

Ich selbst arbeite nicht mit Ubquiti, aber es gab / gibt(?) Hersteller bei denen es immer ein untagged Port über einen .1Q Link übergtragen werden muss.

Hast du ausgeschlossen, dass die VLAN-Kopplung nicht an einem anderen Netzwerkgerät stattfindet?
In welchem VLAN schickt der AP das DHCP-Discover raus?

Das werde ich mir nochmal genau ansehen. Das System ist heute mit der oben beschrieben Krücke (Cisco Switch als "Gatekeeper" für den VLAN 10 Traffic) produktiv gegangen, was Fehlersuche jetzt etwas erschwert. Das die Kopplung aber an anderer Stelle stattfindet kann ich nach bestem Wissen ausschließen. Selbst mit Minimalkonfiguration und jedem Setting "double checked" tritt das Verhalten so auf. Da der o.g. Cisco-Switch das Problem behebt erlaubt imho auch nur noch diese Möglichkeit.

Wenn möglich würde ich darauf verzichten, weil ja jedes Gerät dann gleich im Mgmt-VLAN ist, wenn keine spezielle Portkonfig aktiv ist. Daraus besser auch ein VLAN nutzen.

Mgmt ist hier der Name für das native VLAN, dass Ubiquiti per default hat (analog bei Cisco das VLAN1) und mindestens für die Verwaltung der Netzwerkhardware benötigt wird. Best Practice wäre es ja das Management-Netz aus dem native VLAN rauszuziehen, so dass es auf keinen Ports untagged gesprochen wird. Das ist bei Ubiquiti leider nicht möglich und führte bei mir in der Vergangenheit dazu, dass ein Teststellung gar nicht mehr lauffähig war. Da wollte ich schon damals einen Thread zu aufmachen, aber das ging dann hier unter.

 

[Raijin]

Habe gerade nicht viel Zeit und bin den Thread nur grob durchgegangen. Wenn ich das richtig verstanden habe, geht es um ein Problem, dass die DHCP-Server in der UDM nicht nur in ihrem Subnetz/VLAN antworten, sondern auf allen?

Ich kenne dieses Verhalten von den EdgeRoutern Das passiert ab und zu, wenn man erst den DHCP-Server konfiguriert und im Nachhinein an den IP-Adressen der Interfaces rumspielt. Da man zumindest bei EdgeOS keine Möglichkeit hat, einen DHCP-Server an ein Interface zu binden, wird das im Hintergrund automatisch die DHCP-Range auf die IPs der Interfaces zugeordnet. Das kann dazu führen, dass der DHCP-Server auf dem falschen Interface reagiert, wenn man nachträglich die IP-Adressen geändert hat. Der Workaround bei EdgeOS ist simpel, den/die DHCP-Server löschen und neu konfigurieren. Ggfs hilft auch deaktivieren und aktivieren, ich mache aber immer tabula rasa.

 

[emulbetsup]

Habe gerade nicht viel Zeit und bin den Thread nur grob durchgegangen. Wenn ich das richtig verstanden habe, geht es um ein Problem, dass die DHCP-Server in der UDM nicht nur in ihrem Subnetz/VLAN antworten, sondern auf allen?

Jein, es antworten zwei DHCP-Server, weil Ubiquiti Traffic im native VLAN über Ports weitergibt, auf denen er so konfiguriert ist, dass er dort lediglich VLAN10 sprechen darf.

Habe heute nochmal die Zeit und einen Hub gefunden und WireShark mit einem NIC im MonitorMode betrieben.

Hier das Gerät mit dem Lease aus dem anderen Subnetz...

und hier der Vorgang...

DHCP Discover wird untagged über den Port auf der UDM-Pro mit Profil "Hotspot_UL" weitergegeben.

DHCP Offer untagged zurück. Da das Angebot angenommen wird, erreicht es logischerweise auch wieder das Endgerät. Die UDM-Pro nimmt also untagged Traffic auf einem Tagged Interface entgegen und gibt ihn weiter.

DHCP Request vom Client wieder zurück...

...und die Bestätigung vom Server....

Werde mal ein Case bei Ubiquiti aufmachen - in keinem Fall entspricht das dem IEEE 802.1Q

 

[Skysnake]

Ja mach ein Ticket auf.

 

[Kiso]

Gibt's hier weitere Erkenntnisse?

 

[emulbetsup]

Moin, habe das Thema bei Ubiquiti im Forum eingekippt. Leider verhallt es wohl ungehört.

Untagged Traffic on tagged Portprofiles

Hat jemand Erfahrungen mit dem Support von Ubnt? Ein Fall für RMA ist es ja nun nicht.