slcium
Goto Top

Verbindungsprobleme von Clients und Access Points mit dem WLAN-Controller

Guten Tag,

ich stehe aktuell vor einem Problem, bei welchem ich seit ein paar Wochen keine großen Fortschritte mache.

Situation:

In ein bestehendes Netzwerk soll eine WLAN-Infrastruktur eingebunden werden.

Das Netzwerk basiert auf 25 Cisco Catalyst 2960 und einem 3750. Etwa zwei Dutzend VLANs sind vorhanden, es funktionieren alle VLANs ohne Probleme.

Eingebunden werden soll:
1x Ubiquiti Dream Machine Special Edition als Gateway, Firewall und DHCP-Server für WLAN-Geräte und Access Points
9x Ubiquiti U6-LR Access Points

Folgendes wurde auf der Dream Machine:
Dream Machine sitzt mit dem WAN-Port im Management-VLAN des "Hauptnetzes".
Die Dream Machine gibt den VLANs
600 Management VLANS für APs 192.168.130.0/24
601 Admin-WLAN 192.168.135.0/28
602 WLAN 192.168.136.0/25
603 Admin-WLAN 192.168.136.128/25
DHCP und dient als Firewall und Gateway.

Von der Dream Machine geht ein LWL Kabel in den 3750. Auf den Ports der beiden Geräte liegt VLAN 600 als native VLAN, 601-603 als tagged VLANs.
Zusätzlich sind direkt an der Dream Machine zwei Access Points angeschlossen (auch mit 600 als native, 601-603 tagged).
Alle nicht direkt verbundenen Access Points liegen an Ports auf den Switches an, welche 600 als native VLANs und 601-603 als tagged VLANs besitzen.


Problem / Aktuelle Situation:
Die direkt an die Dream Machine Special Edition angeschlossenen Access Points laufen ohne jedes Problem.
Die anderen Access Points, welche nicht direkt angeschlossen sind und darum über die Switches versorgt werden müssen, haben starke Probleme eine Verbindung zu der Dream Machine aufzubauen.
Das heißt konkret: Solange die Access Points untereinander über Mesh Kontakt zueinander haben, funktionieren sie. Sobald man diese Funktion deaktiviert, sind die Access Points sichtbar, aber sie können nicht vom Controller = Dream Machine verwaltet werden.
Alle Access Points ohne Mesh-Kontakt können gar nicht verwaltet werden (sind aber vom Controller aus sichtbar).
Zusätzlich erhalten alle Geräte, welche sich über Access Points, welche sich nicht im Mesh befinden, mit dem WLAN verbinden wollen, keine Antwort vom DHCP. Es sind im Netzwerk BCs der Geräte mit DHCP-Discover sichtbar. Die Geräte erhalten außerdem APIPA-Adressen. Außerdem konnten an diesen Access Points auf den Interfaces der tagged VLANs große Mengen an gedroppten Paketen nachgewiesen werden.

Wenn ich an den Ports, an denen eigentlich die Access Points hängen, mein Notebook anschließe, erhalte ich ohne Probleme eine IP aus dem Management VLAN 600 und habe keine Verbindungsprobleme.

Ich komme leider absolut nicht dahinter, warum die Clients keine Connection zum DHCP-Server bekommen und warum die Access Points vom Controller gesehen, aber nicht verwaltet werden können.

Ich hoffe, dass hier Jemand eine gute Idee hat und mir einen Wink in die richtige Richtung geben kann.

Content-Key: 44108854824

Url: https://administrator.de/contentid/44108854824

Printed on: February 23, 2024 at 07:02 o'clock

Member: Visucius
Visucius Oct 10, 2023 at 15:25:37 (UTC)
Goto Top
Verstehe ich das richtig, die DreamMachine hängt mit ihrem WAN-Port "hinter" einer anderen Firewall (Router-Kaskade) an nem Switch oder soll die Dreammachine für das Gesamtnetz (LAN/Wifi) die Firewall machen?!
Member: Slcium
Slcium Oct 10, 2023 at 15:36:27 (UTC)
Goto Top
Hallo Visucius,

die Dream Machine hängt mit dem WAN-Port hinter einer anderen Firewall an einem Switch.
Gibt also doppeltes NAT.
Member: aqui
aqui Oct 10, 2023 updated at 20:23:02 (UTC)
Goto Top
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.
Member: Vision2015
Vision2015 Oct 10, 2023 at 17:03:28 (UTC)
Goto Top
Moin...
Zitat von @Slcium:

Hallo Visucius,

die Dream Machine hängt mit dem WAN-Port hinter einer anderen Firewall an einem Switch.
Gibt also doppeltes NAT.

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
Member: Visucius
Visucius Oct 10, 2023 updated at 18:59:20 (UTC)
Goto Top
die Dream Machine hängt mit dem WAN-Port hinter einer anderen Firewall an einem Switch. Gibt also doppeltes NAT.

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:
bildschirmfoto 2023-10-10 um 20.49.24
Member: Slcium
Slcium Oct 11, 2023 updated at 14:35:30 (UTC)
Goto Top
Guten Tag,

Zitat von @aqui:

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.

2 Admin SSIDs: Bitte entschuldige; 601 ist das Admin-WLAN. 603 für die Gäste.
Ich habe mal versucht eine Skizze des Netzwerkaufbaus zu erstellen und beantworte darin hoffentlich auch den Großteil deiner Fragen:

unbenanntes diagramm-1696952453353 (1)

Die direkt an die Dream Machine angeschlossenen Access Points funktionieren ohne Probleme.

Zitat von @Visucius:

die Dream Machine hängt mit dem WAN-Port hinter einer anderen Firewall an einem Switch. Gibt also doppeltes NAT.

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?!
Ich verstehe diese Aussage leider nicht - Warum meinst du "eigene VLANs mit zu zufällig den selben IPs wie im Cisco Netz"? Würdest du mir das bitte erklären?
Welche Daten meinst du, die nicht durch die Firewall kommen? Über den WAN-Port kommen soweit alle Daten in das WLAN, welche wir aus dem WLAN haben wollen und umgekehrt.


Zitat von @Vision2015:

Moin...
Zitat von @Slcium:

Hallo Visucius,

die Dream Machine hängt mit dem WAN-Port hinter einer anderen Firewall an einem Switch.
Gibt also doppeltes NAT.

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

In gewisser Weise wurde mir die Entscheidung für diesen Aufbau oktroyiert ... Darum kann ich die Hardware nicht einfach aus dem Setup schmeißen. Mir ist bewusst, dass es einfachere und bessere Methoden gegeben hätte.
Dennoch - Das generelle Setup scheint zu funktionieren. Das schlussfolgere ich aus den funktionsfähigen Access Points, welche direkt an die Dream Machine angeschlossen sind - Hier läuft alles exakt wie es soll. Die Frage ist nur warum es über die Switches zu den Verbindungsproblemen kommt.
Zu diesem Thema habe ich heute weitere Beobachtungen gemacht:

Ich habe folgendes Testszenario gebaut:
Ich habe auf einem aktuell ungenutzten 2960 auf einem Interface die folgende Konfiguration vorgenommen. Die Connection zum LWL-Switch ist für alle VLAN-IDs eingerichtet:

3t4t
ajuraujarjujr

An das Interface Fa0/2 habe ich einen Access Point gehangen. Diesem habe ich keine statische IP gegeben, um so DHCP im Management-VLAN 600 zu testen. Dieser Aufbau ist auch oben in der Skizze zum Netzwerk angegeben (AP 192.168.130.5/24).

Ich habe aus diesem Aufbau die folgenden Erkenntnisse gewonnen:
- Der Access Point erhält automatisch eine IP vom DHCP Server. Die IP stammt aus dem richtigen Netz.
- Der Access Point lässt sich von der Dream Machine aus Pingen. Es ist außerdem möglich ihn aus dem WLAN heraus mit SSH zu erreichen -> Dazu muss ich mich im Bereich eines anderen Access Points befinden, welcher direkt an der Dream Machine angeschlossen ist.
- Der Versuch sich über den Access Point mit dem WLAN zu verbinden schlägt fehl. Ich erhalte mit meinem Notebook eine APIPA-Adresse. Meine DHCP-Anfragen werden vom DHCP-Server nicht beantwortet.
- Mein Notebook ist von der Dream Machine aus sichtbar. Der Controller erkennt, dass es ein Problem bei der Verbindung zum DHCP-Server gibt.
- Auf dem Access Point selbst sehe ich mit ifconfig, dass es auf br0.600 keine gedroppten Pakete gibt. Bei br0.601-603 sind in Summe an die 70.000 Pakete gedroppt.
- Beobachtungen mit Wireshark:
-> Die DHCP Discover Pakete, welches mein Notebook versendet, sehen in Ordnung aus.
-> Wenn ich an einem funktionsfähigen Access Points ein Gerät per DHCP eine IP geben lasse, erhalte ich den initialen BC nicht mit meinem Notebook.
-> Auf dem Interface des Switches sehe ich folgende Anomalie:
39tuj93zjp4zj

Ich vermute, dass in irgendeiner Form die Übergabe der Pakete vom Access Point auf das VLAN der Switches Probleme bereitet. Was haltet Ihr davon?

Außerdem eine Frage:
Gibt es ein Szenario, wo die Cisco Switches für die Arbeit mit den Access Points / der Dream Machine von der VLAN-Technologie her "zu alt" sind und es dadurch zu Problemen kommt?
rgerhrhru
Member: Vision2015
Vision2015 Oct 11, 2023 at 15:27:39 (UTC)
Goto Top
Moin,

In gewisser Weise wurde mir die Entscheidung für diesen Aufbau oktroyiert ...
oha... und warum sagst du nicht, das gewünschte Setup blödsinn ist, und so nicht klappt?
Darum kann ich die Hardware nicht einfach aus dem Setup schmeißen. Mir ist bewusst, dass es einfachere und bessere Methoden gegeben hätte.
aha... dir ist bewusst, das dein Setup so nicht Funkionieren kann, und machst es Trotzdem?
da kannst du gleich Feuer mit Benzin Löschen!

Dennoch - Das generelle Setup scheint zu funktionieren.
nö... tut es eben nicht.
Das schlussfolgere ich aus den funktionsfähigen Access Points, welche direkt an die Dream Machine angeschlossen sind - Hier läuft alles exakt wie es soll. Die Frage ist nur warum es über die Switches zu den Verbindungsproblemen kommt.
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!
Zu diesem Thema habe ich heute weitere Beobachtungen gemacht:
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
Member: aqui
Solution aqui Oct 11, 2023, updated at Oct 12, 2023 at 09:34:07 (UTC)
Goto Top
Die Frage ist nur warum es über die Switches zu den Verbindungsproblemen kommt.
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. face-sad
Ich vermute, dass in irgendeiner Form die Übergabe der Pakete vom Access Point auf das VLAN der Switches Probleme bereitet.
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):
vlansniff14
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.
Member: Visucius
Visucius Oct 11, 2023 updated at 16:31:39 (UTC)
Goto Top
Warum meinst du "eigene VLANs mit zu zufällig den selben IPs wie im Cisco Netz"? Würdest du mir das bitte erklären?
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.
Member: Slcium
Slcium Oct 11, 2023 at 16:55:34 (UTC)
Goto Top
Hallo,

ich möchte euch erstmal für die Antworten danken.

@Vision2015
Ich sehe absolut ein, dass diese Lösung auf L3 ausbaufähig ist. Außerdem wollte ich definitiv keine Informationen ignorieren oder überlesen - Ich habe alle Beiträge sehr sorgfältig "studiert" und vollständig zu verstehen versucht face-smile Das kannst du mir also nicht vorwerfen. Was ich aber leider nicht verstehe ist, warum ein (so verstehe ich es) reines L2 Problem etwas mit dem doppelten NAT bzw. allgemein L3 zu tun haben soll. Hier fehlt mir die Erfahrung, um ehrlich zu sein. Müsste nicht der Traffic an sich zwischen den Komponenten des "WLAN-Netzes" auf L2 funktionieren und erst bei dem Übergang über den WAN-Port Probleme machen? Die L2 Switches kennen ja diese Probleme mit dem Routing an sich gar nicht und sehen nur "Ziel-MAC-Adresse ist auf Port 10. Also dahin."

@Visucius
Der Router im LAN (Ist eigentlich eine VM auf OpenSense Basis ... Mir fehlte dazu nur das Symbol) hat keine Interfaces in den VLANs 600-603. Er routet also wirklich auch nur die nicht WLAN-Netze.
Alle Netze, welche mit dem WLAN zu tun haben, also 600-603, haben nur einen Weg, über welchen sie in das Internet/Nicht WLAN-Netz kommen: (Access Point) -> DreamMachine Routet über WAN-Port zum Hauptrouter-> Hauptrouter zu Firewall oder in nicht WLAN-VLANs
Der 3750 agiert hier wirklich nur als reiner L2 Switch und übernimmt keine L3 Funktionalitäten. Ich glaube, dass ich diesen Punkt sehr schlecht kommuniziert habe face-sad ..
Es sollte also kein VLAN von mehr als einem Router versorgt werden und damit keine Probleme mit doppelter IP-Vergabe geben.
Habe ich dich richtig verstanden?

@aqui
Vielen Dank für die sehr ausführliche Antwort und die Handlungsempfehlungen! Ich werde das morgen alles wie von dir beschrieben durchtesten und auch die Konfig-Auszüge hier reinstellen. Ich gehe dann morgen mit den Testergebnissen auf deinen Beitrag im Detail ein.
Member: Visucius
Visucius Oct 12, 2023 at 08:38:33 (UTC)
Goto Top
Na, Du wirst schon wissen, was Du tust. Auf jeden Fall viel Erfolg! face-wink
Member: Slcium
Slcium Oct 12, 2023 at 13:44:25 (UTC)
Goto Top
Hallo Aqui,

ich habe versucht deinen Beitrag Schritt für Schritt durchzugehen:


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.
Um Probleme mit LWL auszuschließen, habe ich den Uplink der Dream Machine auf Kupfer geändert. Vor deinen Tests wollte ich damit überprüfen, ob es sich hier vielleicht um ein defektes SFP+ Modul, Kabel, ... handelt.
Die Konfiguration für diesen Port habe ich 1:1 vom SFP+ Port übernommen (Dazu gibt es "Profile". Mit diesen lassen sich Ports auf der Dream Machine vereinheitlichen). An diesen Uplink habe ich dann einen Access Point gehangen. Der Access Point lief ohne Probleme: Auf allen WLAN Netzen wurden IP-Adressen vergeben.
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.
Auch diesen Punkt habe ich getestet ...
Ich habe mir einen Port am Switch genommen und jedes VLAN einzeln an einem Access-Port getestet:
Über VLAN 600 bekomme ich eine IP. 601-603 funktionieren nicht.
Ich vermute darum, dass es auf jeden Fall an dieser Stelle einen schwerwiegenden Konfigurationsfehler geben muss.


Ich habe einige Screenshots der Konfiguration gemacht - Bitte sag mir welche Informationen du zusätzlich benötigst:

Der Port auf der Dream Machine ist so konfiguriert:
unifi1
unifi2

Gegenstück auf der Cisco-Seite:
show_interface
running_config
switchport
trunk


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.
Mit "no cdp run" tue ich mich ein wenig schwer. Welche Auswirkungen hat das auf das Netzwerk? Ich habe einen kleinen 8-Port Switch von Cisco. Mit diesem würde ich das durchtesten und CDP deaktivieren. Könnte dieses Protokoll für das Problem verantwortlich sein? Den Switch würde ich dann als Testumgebung direkt an die Dream Machine hängen und an den Cisco Switch teste ich dann nochmal die VLANs.
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.
Ich muss leider sagen, dass ich absolut keine Ahnung habe nach was ich mit "show span" suchen muss face-smile Ich habe hier einen Screenshot der Ausgabe von "show span" für das VLAN 603 - Sieht das korrekt aus?
span
Member: aqui
Solution aqui Oct 12, 2023 updated at 15:42:19 (UTC)
Goto Top
Der Access Point lief ohne Probleme: Auf allen WLAN Netzen wurden IP-Adressen vergeben.
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?

an dieser Stelle einen schwerwiegenden Konfigurationsfehler geben muss.
Ja, das ist offensichtlich und man sieht anhand der Port Konfiguration an 1/0/22 auch sehr wahrscheinlich den möglichen Grund. face-sad
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:
!
interface GigabitEthernet1/0/1
 description Uplink Router Controller
 switchport mode trunk
 switchport trunk native vlan 600
 switch trunk allowed vlan 600-603
 switchport nonegotiate
 spanning-tree portfast
!
interface GigabitEthernet1/0/10
 description Testport VLAN-600
 switchport access vlan 600
 switchport mode access
 spanning-tree portfast
!
interface GigabitEthernet1/0/11
 description Testport VLAN-601
 switchport access vlan 601
 switchport mode access
 spanning-tree portfast
!
interface GigabitEthernet1/0/12
 description Testport VLAN-602
 switchport access vlan 602
 switchport mode access
 spanning-tree portfast
!
interface GigabitEthernet1/0/13
 description Testport VLAN-603
 switchport access vlan 603
 switchport mode access
 spanning-tree portfast
! 

Mit "no cdp run" tue ich mich ein wenig schwer. Welche Auswirkungen hat das auf das Netzwerk?
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!
Könnte dieses Protokoll für das Problem verantwortlich sein?
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 ...

dass ich absolut keine Ahnung habe nach was ich mit "show span" suchen muss
Ob dort irgendwo was Wort "Blocking" auftaucht! 😉
"show span" für das VLAN 603 - Sieht das korrekt aus?
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!
Member: Slcium
Slcium Oct 12, 2023 updated at 17:19:13 (UTC)
Goto Top
Hallo,

erneut ein großes Danke für deinen Beitrag!
Ich werde morgen wieder alles durchtesten.
Bei einem Punkt konnte ich mich aber doch nicht zusammenreißen und musste mir das sofort anschauen face-smile

Das Macro "cisco-desktop" - also erstmal ... Das soll da auf keinen Fall sein! Völliger Schwachsinn. Aufgefallen ist es mir jedoch nicht; Egal. Ich habe zu den Macros im Allgemeinen eine Frage:

Wie werden diese Macros behandelt, denn Macro und Config widersprechen sich in in diesem Setup deutlich. Was davon gilt für den Switch?
Der Beschreibung des Macros nach würde ich schätzen, dass der Switch rabiat das Macro über die Config bügelt und alles überschreibt was vom Macro geregelt wird.
Könntest Du mir diese Wechselwirkung bitte erklären?

Ich habe den Inhalt des Macros einmal kopiert:

Macro name : cisco-desktop
Macro type : default interface
  1. macro keywords $access_vlan
  2. Basic interface - Enable data VLAN only
  3. Recommended value for access vlan should not be 1
switchport access vlan $access_vlan
switchport mode access

  1. Enable port security limiting port to a single
  2. MAC address -- that of desktop
switchport port-security
switchport port-security maximum 1

  1. Ensure port-security age is greater than one minute
  2. and use inactivity timer
switchport port-security violation restrict
switchport port-security aging time 2
switchport port-security aging type inactivity

  1. Configure port as an edge network port
spanning-tree portfast
spanning-tree bpduguard enable

PS die Zahlen im Macro sind eigentlichen Rauten ...
Member: aqui
Solution aqui Oct 12, 2023, updated at Oct 14, 2023 at 14:54:58 (UTC)
Goto Top
die Zahlen im Macro sind eigentlichen Rauten ...
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. face-wink

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 ...
# Enable port security limiting port to a single
# MAC address -- that of desktop
switchport port-security 
switchport port-security maximum 1 
Ä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?!
Aufgefallen ist es mir jedoch nicht
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.
Member: Slcium
Slcium Oct 14, 2023 at 14:28:39 (UTC)
Goto Top
Hallo,

ich habe das zuerst mit einem sauberen, leeren Switch als Uplink getestet -> hat funktioniert.
Dann habe ich, wie von Dir empfohlen, den Port auf dem "richtigen" Switch nochmal sauber konfiguriert. Keine sinnlosen Macros und Policies ...

Nach der Neukonfiguration gab es auch in der Produktivumgebung keine Probleme mehr. Das Problem ist also gelöst face-smile
Der Ablösung von CDP werde ich mich dann als nächstes annehmen.

Viel Dank Aqui für die Hilfe und ein schönes Wochenende!
Member: aqui
aqui Oct 14, 2023 at 14:51:58 (UTC)
Goto Top
👏 👍