Verbindungsprobleme von Clients und Access Points mit dem WLAN-Controller

WER routet bei dir die VLANs??
Hast du ein Layer 2 VLAN Konzept umgesetzt mit einem "one armed" Router oder Firewall oder hast du ein Layer 3 VLAN Konzept umgesetzt wo der Catalyst 3700er als L3 Switch die VLANs zentral routet?
Wieso 2 Admin WLAN SSIDs?
Nur um da ohne Kenntnisse deines genauen Designs jetzt nicht wild kristallkugeln zu müssen... Eine kurze Skizze hätte allen hier zum Verständniss geholfen.

Das Kardinalsproblem ist sehr wahrscheinlich die völlig falsche Integration des Routers/Firewall über den WAN Port in die VLAN Infrastruktur. Das kann so nicht gehen weil dort das NAT Gateway und die Firewall aktiv sind und du damit keinerlei Layer 2 Connectivity hast. Damit scheitert dann die L2 VLAN Connectivity. Die APIPA Adressen sind ein sicheres Indiz für diesen gravierenden Designfehler.
Um das aber sicher sagen zu können müsste man aber deine VLAN Infrastruktur besser verstehen.

Moin...

wozu? ich sehe dazu keinen grund- und da wird dein Problem ligen!
auch verstehe ich nicht, warum du eine "Dream Machine" als Router Kaskade, und zu allem überfluss auch noch mit doppelten NAT in dein Netzwerk setzt. der Kostenlose Controller, sei es auf einer VM, Raspi, Toaster etc.. hätte nicht nur gereicht, sondern wäre die bessere Option gewesen!
ergo, die DreamMaschine soll am besten raus aus deinem Netz, stell das ding in die Bucht, es hat keinen nutzen! dein Catalyst 3700e ist ein Prima L3 switch, schalte das IP Routing ein- und du wirst zufrieden sein!

Frank

Hm, das kann doch nicht gehen?! Dann müssen die Daten der „Cisco-Wifis“ doch von außen durch die Firewall der Unifi/Dreammachine um den Controller dort zu erreichen!? Entweder Firewall aus oder die 2 Ports freigeben.

Ich würde auch mal behaupten, dass damit das vLAN-Setting Grütze ist, weil das doch gar nicht durch die Firewall der Dreammachine kommt?! Die verwaltet doch in Deinem Setup „eigene“ vLANs mit zufällig den selben IPs wie im Cisco Netz. Und das fällt Dir auf die Füße und erfüllt doch auch keinen Zweck?!

@Vision2015:
Auf dem Ding läuft der Controller … das geht aber auch anders (z.B. VM, Raspi, NAS, PC, …) und ist deutlich günstiger, bzw. eigentlich kostenlos

PS:

Moin,

oha... und warum sagst du nicht, das gewünschte Setup blödsinn ist, und so nicht klappt?
aha... dir ist bewusst, das dein Setup so nicht Funkionieren kann, und machst es Trotzdem?
da kannst du gleich Feuer mit Benzin Löschen!

nö... tut es eben nicht.
das haben wir dir schon geschrieben, warum liest du nicht, was wir dir schreiben?
alleine dein doppeltes NAT ist Blödsinn und sinnfrei!
aber da gehst du leider nicht drauf ein!
du würdest besser zu dem Thema Lesen was wir dir schreiben!
deine festgestellte Anomalie ist ein Fehlerhaftes Setup, welches du erstellt hast!
mein Ratschlag an dich, erstelle ein ordentliches Setup, ohne Doppel NAT und Schnickschnack!
dein Cisco Switch ist nicht zu alt, und erfüllt alle anforderungen!

Frank

OK, dein Switchnetz ist laut der Zeichnung dann ein reines Layer 2 Netz. So wie es gezeichnet ist sollte es eigentlich fehlerlos klappen, denn es ist aus Designsicht (VLANs etc.) alles richtig.
Einen teuren 3750 als simplen L2 Switch zu verwursten ist natürlich Perlen vor die Säue aber hier jetzt auch nicht das Thema...

Ein wichtiger Test wäre einmal einen der APs testweise an den LAN Port anzuschliessen der zum 3750 Switch geht. Das würde dann verifizieren das auch dieser Port korrekt konfiguriert ist und identisch wie die 2 direkten AP Ports funktioniert. Von dem hängt maßgeblich die korrekte Weitergabe der VLANs auf die Catalyst Infrastruktur ab!
Die Konfig aller dieser 3 Ports auf der Traumtänzer Gurke müssen ja identisch sein.
Ist das der Fall kann es nur noch ein einer fehlerhaften Port Konfig irgendwo an den Ciscos liegen. Entweder an den Uplink Ports oder den Accessports.

Idealerweise gehst du dafür strategisch vor um das zu prüfen und generierst dir auf den Ciscos je einen Access Port in den VLANs 600 bis 603 und schliesst dort einen Testrechner (Laptop etc.) an.
Dieser muss ja dann in allen diesen VLANs eine gültige IP Adresse per DHCP bekommen, zumindestens in den 600er Segmenten wo das Dreamteil DHCP macht. In statischen Segmenten setzt du dann eine statische IP und Gateway auf dem Testrechner.
Damit testest du in allen dieser 4 VLANs die IP Connectivity, Vergabe der IP Adressen und Ping auf die Dream Router IP im jeweiligen VLAN dort.

Hier muss in allen VLAN Segmenten IP Connectivity vorhanden sein, sowohl auf dem 3750er als auch auf dem 2960er Switch.
Das musst du sicherstellen. Wenn das nicht der Fall ist, ist irgendwo etwas falsch konfiguriert an der Layer 2 Infrastruktur. Leider fehlen hier die Konfig Auszüge.
Genau deswegen teste das explizit mit Kupfer und Accessports in diesen VLANs. Hier muss die Dreamkiste von beiden Switches bzw. Testswitch in den SSID VLANs pingbar sein und entsprechende IPs vergeben.
Ist das der Fall weisst du wenigstens das die Uplink Trunks zw. den Switches korrekt konfiguriert sind und alle vier 600er VLAN korrekt an den Switches anliegen.

Du solltest am Cisco Switch dann zusätzlich einen der AP Ports einmal spiegeln (Mirror Port)
https://www.miarec.com/legacy/how-to-configure-port-mirroring-for-cisco- ...
Hier zeichnest du dann mit dem Wireshark einmal den AP Traffic auf und checkst ob der MSSID Traffic dort die korrekten VLAN Tags hat (hier 14):
Was denkbar wäre das der AP am Switch keine VLAN 600 Connectivity hat und deshalb seine MSSID Konfig nicht vom Controller bekommt über das WLAN Management Netz 600 und somit kein oder ein falsches VLAN Tagging für die MSSID WLANs macht, was der Switch in dem Falle dann nicht korrekt weiterleiten kann.

Zusätzliche Empfehlung:
Deaktiviere mit no cdp run das proprietäre CDP Protokoll auf beiden Switches und aktiviere das Standard konforme LLDP mit lldp run.
Mit show lldp neighbors zeigt dir der Switch eine Portliste mit allen angeschlossenen Endgeräten die LLDP reden was vermutlich auch die Dreamteile machen.
Der Sinn davon ist zu checken ob du ggf. irgendwas physisch falsch gesteckt hast und/oder auf falschen Ports falsche VLAN Settings.
Im Grunde genau das was du schon mit dem Spare Cat 2960 richtigerweise gemacht hast und der richtige Weg ist zum Troubleshooten.
Genau diesen Switch könntest du idealerweise auch einmal testweise mit einem Uplink Port an einen der funktionierenden lokalen AP Ports anschliessen mit entsprechendem Tagging und dann so wie oben mit einem Testrechner die VLAN Connectivity testen. Da du ja sicher weisst das die AP dort an den Ports sauber funktionieren kannst du bei entsprechender Switch Konfiguration sicher davon ausgehen das es dann an dem testswitch auch funktionierne muss. Das wäre ein idealer erster Test!
Klappt das, dann muss ein dort am Switch angeschlossener AP ebenso fehlerlos funktionieren!
Wenn du so strukturiert vorgehst solltest du den Fehler im Handumdrehen finden.

Beachte zudem das die Ciscos PVSTP+ machen, also ein proprietäres Spanning Tree Verfahren mit proprietären BPDU Mac Adressen, was die Dreamteile sicher nicht supporten, da sie sehr wahrscheinlich nur ein einfaches single Span Verfahren supporten was nicht kompatibel ist.
Wenn hier Ports zu Bridges zusammengefasst sind und auch STP im Spiel ist, musst du aufpassen das die mit dem Spanning Tree machen.
Wenn die diese VLAN spezifische BPDUs der Ciscos in andere VLANs fluten oder forwarden kann es sein das der Cisco fälschlicherweise ein Blocking detektiert und diese Ports in den STP Blocking Mode oder Error Disable Mode gehen.
Hier also immer mit show span nachsehen das zumindestens die Cisco Ports immer im Forwarding Mode sind.

So wie ich das verstehe, baut ja der Router im Cisco-Netzwerk die vLANs auf. Dann hängst Du dahinter eine Dreammachine, die ne Firewall hat/macht und nochmal nattet. Und in dieser stellst Du ... teilw. die gleichen vLANs ... nochmal her. Wenn die vLANs aber von zwei Routern im gleichen Netzwerk verwendet werden, muss es doch zwangsläufig zur Doppelvergabe von Client-IPs kommen.

Und warum funktioniert das scheinbar bisher? Weil die vLANs der Dreammachine doch am WAN-Port gar nicht ausgegeben werden. Oder täusche ich mich da?! D.h. die Anfrage vom Wifi-Client kommt zum Wifi-AP, dort wird das vLAN-Bit eingebaut, geht zur Dreammachine, die macht das wieder raus, schickt die Anfrage weiter zum "Cisco"-Router. Der antwortet, die Dreammachine gibt die Anfrage wieder in das vLAN zurück, aus der die Anfrage kam. Das ist aber doch nicht Sinn der Sache, bzw. doppelt gemoppelt (und Performance, Stromverbrauch und Latenz sind schlechter als nötig.
Eigentlcih muss doch das vLAN vom Cisco-router einfach nur durch die Dreammachine durchgereicht werden oder eben besser durch nen vLAN-fähigen Switch.

Na, Du wirst schon wissen, was Du tust. Auf jeden Fall viel Erfolg!

Perfekt! 👍
Konntest du an dem Port durch Messung (Mirroring, Wireshark) verifizieren das UNtagged Traffic aus 600 kommt und Traffic von 601 bis 603 mit der jeweiligen VLAN ID getagged kommt?
Das würde dann verlässlich verifizieren das das Tagging des Dreamteils OK ist und diese VLANs dann auch richtig in die Cat 2960er VLANs des Testswitches am Uplink Port geforwardet werden.
Gut, mehr oder minder verifiziert das ja auch das korrekte AP Verhalten an dem Port.
Ist das Interface GigabitEthernet 1/0/22 der Dream Uplink Port auf deinen Cat 2960er Testswitch?

Ja, das ist offensichtlich und man sieht anhand der Port Konfiguration an 1/0/22 auch sehr wahrscheinlich den möglichen Grund.
Es wäre sehr intelligent gewesen deinen Cat 2960er Testswitch VORHER mit erase startup oder auch write erase mit einem nachfolgenden Reboot in einen jungfräulichen Zustand (Factory Reset) zu versetzen um möglichen fehlerhaften Konfigresten oder Konfigversuchen aus Altlasten gleich aus dem Weg zu gehen und so mit einem "sauberen" Switch erstmal rein nur eine einfache Layer 2 Konfig zu testen.
Leider ist das scheinbar nicht passiert und der Port hat eine unnötige Port Security Konfig die dir vermutlich genau dieses Fehlerbild erzeugt.

Um dir hier also keine weiteren Fallen selbst zu stellen solltest du dringenst für die Testphase diese Security Einstellungen entfernen!! Noch besser, wie bereits gesagt, mit einem nackten Testswitch und einfacher Standard Layer 2 VLAN Konfig die Funktion nochmal zu testen.
An den Ports sollte nichts anderes sein und diese so aussehen:

Gar keine!!
CDP ist ein proprietäres Infrastruktur Protokoll von Cisco was man in heterogenen Umgebungen wie deinem immer deaktivieren sollte und immer mit dem übergreifenen Standard LLDP arbeiten sollte um vollkommen kompatibel zu anderen Herstellern zu sein.
Um Chaos zu vermeiden sollte man zudem ausschliesslich nur ein einziges Infrastruktur Protokoll aktiv haben!
Nein. Wenn überhaupt könnte es nur CDP, denn das könnte eine automatische Rekonfiguration des Ports veranlassen. Genau deshalb auch die Empfehlung in gemischten Umgebungen immer einzig LLDP zu verwenden.
Extrem wichtig hier ist zu verhindern das Cisco's DTP Autonegotiation eine automatische Port Rekonfiguration vornimmt!
Deshalb sollte bei Cisco Trunkports zu Fremdherstellern immer ein switchport nonegotiate konfiguriert werden um da absolut sicher zu gehen.
https://learningnetwork.cisco.com/s/question/0D53i00000Kt1GLCAZ/switchpo ...

Ob dort irgendwo was Wort "Blocking" auftaucht! 😉
Ja, ist korrekt.
1/0/22 ist ein Designated Port und im Forwarding Mode.

Dein Kardinalsproblem dürfte sehr wahrscheinlich die falsche und überflüssige Port Security Konfig am Uplink Port 22 sein.
Wie bereits gesagt: Setze den Testswitch unbedingt auf die Factory Defaults und teste nur die o.a. einfache Layer 2 Konfig OHNE überflüssigen Ballast und andere Fussfallen!

Bitte nutze genau deshalb der Übersicht halber und um solche Formatierungsfehler zu vermeiden immer die Code Tags bei Angabe von (Macro) Code!
Kann man über den "Bearbeiten" Knopf auch immer noch nachträglich erledigen.

Makros fassen mehrere Kommandos zusammen an konfigurierten Ports um den Konfig Aufwand zu reduzieren. Der Port der so ein Makro enthält führt also immer alle Kommandos aus die in der korrespondierenden Makro Definition enthalten sind.
https://www.cisco.com/en/US/docs/general/Test/dwerblo/broken_guide/smrtp ...
Äußerst fatal ist dort das Kommando switchport port-security maximum 1 was bewirkt das der Port nur eine einzige Mac Adresse im Forwarding lernt und alles andere blockiert.
Sowas hat natürlich böse Folgen für einen Trunk Port der so nur eine einzige Mac Adresse lernt und alles andere blockiert. Sehr wahrscheinlich der Auslöser all deiner Probleme weil vermutlich laienhaft die o.a. Beispielkonfig übernommen wurde?!
Warum nicht? 🤔 Springt einem mit der Menge der anderen unsinnig am Trunk Port konfigurierten Kommandos als Cisco Admin doch förmlich sofort ins Auge.
Wie der Name des Makros schon sagt ist das ein Desktop Port Makro was auf einem Trunk Port nichts zu suchen hat.
Abgesehen davon wird Port Security heutzutage sinnvollerweise statt statisch im Switch immer mit zentraler Radius Authentisierung gelöst!

Deshalb nochmals der dringende Appell das komplett zu entfernen oder besser noch den Switch mit einer sauberen Default Konfig ohne diese Fussfallen zu konfigurieren um solcherlei Fehler sicher ausschliessen zu können! Ganz besonders wenn man konfigtechnisch etwas unsicher ist.