Accesspoint bekommt keine IP Adresse hinter Cisco CBS 350
Guten Abend,
Ich habe Accesspoints (cisco 2702) welche nach Tutorial konfiguriert sind erhalten hinter dem zweiten Cisco switch keine IP-Adresse mehr vom DHCP Server.
Ich habe eine Opnsense auf welcher mehrere vlans konfiguriert sind. Auf der Sense läuft ein dhcp server welcher die Ip-adressen der vlans verwaltet.
An die Opnsense ist ein cisco CBS 350 switch (Switch 01) angeschlossen an welchem wiederum ein weiterer CBS 350 (Switch 02) hängt.
alle Ports der switche sind als vlan-Trunks eingerichtet.
vlan30 soll das Verwaltungsnetzwerk sein in welchem später die Switche und Accesspoints ihre IP-Adressen erhalten.
Wenn die Access Points an Switch 01 angeschlossen werden erhalten diese eine IP-Adresse und alles funktioniert wie es soll. Wenn die Access Points allerdings an Switch 02 angeschlossen werden beziehen diese keine IP-Adresse. Die SSID wird jedoch ausgestrahlt und die Clients im zugehörigen WLAN erhalten eine IP.
Ein Notebook per Kabel läuft problemfrei an beiden Switchen 01 & 02 und erhält auch eine IP.
Hat jemand eine Idee weshalb der Adressenbezug hinter switch 02 für die AP's nicht funktioniert?
liebe Grüße
Ben
Ich habe Accesspoints (cisco 2702) welche nach Tutorial konfiguriert sind erhalten hinter dem zweiten Cisco switch keine IP-Adresse mehr vom DHCP Server.
Ich habe eine Opnsense auf welcher mehrere vlans konfiguriert sind. Auf der Sense läuft ein dhcp server welcher die Ip-adressen der vlans verwaltet.
An die Opnsense ist ein cisco CBS 350 switch (Switch 01) angeschlossen an welchem wiederum ein weiterer CBS 350 (Switch 02) hängt.
alle Ports der switche sind als vlan-Trunks eingerichtet.
vlan30 soll das Verwaltungsnetzwerk sein in welchem später die Switche und Accesspoints ihre IP-Adressen erhalten.
Wenn die Access Points an Switch 01 angeschlossen werden erhalten diese eine IP-Adresse und alles funktioniert wie es soll. Wenn die Access Points allerdings an Switch 02 angeschlossen werden beziehen diese keine IP-Adresse. Die SSID wird jedoch ausgestrahlt und die Clients im zugehörigen WLAN erhalten eine IP.
Ein Notebook per Kabel läuft problemfrei an beiden Switchen 01 & 02 und erhält auch eine IP.
Hat jemand eine Idee weshalb der Adressenbezug hinter switch 02 für die AP's nicht funktioniert?
liebe Grüße
Ben
Please also mark the comments that contributed to the solution of the article
Content-ID: 93152101949
Url: https://administrator.de/contentid/93152101949
Printed on: October 6, 2024 at 19:10 o'clock
25 Comments
Latest comment
Häufiger Fehler ist das nicht bedacht wird das die DHCP Requests des APs immer im Native bzw. PVID VLAN (also UNtagged) gesendet werden was am Switchport anliegt an das der AP angeschlossen ist!
Kollege @Visucius hat es oben schon richtig bemerkt.
Daher gilt es sicherzustellen das im Native bzw. PVID VLAN was ja in der Regel das Management VLAN des oder der APs sind ein DHCP Server sich befindet oder ein DHCP Relay konfiguriert ist. Vermutlich ist das beim TO nicht der Fall oder das PVID VLAN ist nicht gesetzt.
Leider ist die Beschreibung des TOs hier sehr oberflächlich, denn er macht keinerlei hilfreiche Angaben weder zur AP Switchport Konfiguration des 350ers noch dazu in welchem Mode der Accesspoint betrieben wird. (Singuläre SSID oder MSSID Setup oder dynmaische VLANs etc.)
Damit ist eine zielführende Antwort schwierig wenn man nicht ins Kristallkugeln abdriften will. Etwas mehr Detailinfos würden, wie immer, für ein Troubleshooting hier sehr helfen...
Mit Spanning Tree oder BPDU Modes hat das Fehlerbild nichts zu tun.
Kollege @Visucius hat es oben schon richtig bemerkt.
Daher gilt es sicherzustellen das im Native bzw. PVID VLAN was ja in der Regel das Management VLAN des oder der APs sind ein DHCP Server sich befindet oder ein DHCP Relay konfiguriert ist. Vermutlich ist das beim TO nicht der Fall oder das PVID VLAN ist nicht gesetzt.
Leider ist die Beschreibung des TOs hier sehr oberflächlich, denn er macht keinerlei hilfreiche Angaben weder zur AP Switchport Konfiguration des 350ers noch dazu in welchem Mode der Accesspoint betrieben wird. (Singuläre SSID oder MSSID Setup oder dynmaische VLANs etc.)
Damit ist eine zielführende Antwort schwierig wenn man nicht ins Kristallkugeln abdriften will. Etwas mehr Detailinfos würden, wie immer, für ein Troubleshooting hier sehr helfen...
Mit Spanning Tree oder BPDU Modes hat das Fehlerbild nichts zu tun.
Bei den Cisco switchen wird's offenbar geblockt.
Nein, da wird normal natürlich nie etwas "geblockt" wenn man nicht explizit ACLs dort definiert.Sehr wahrscheinlich hast du vergessen auf dem CBS350 eine Default Route: 0.0.0.0/0 => Default Gateway zu konfigurieren?!
Ohne diese Default Route kennt der L3 Switch kein Default Gateway und scheitert damit dann an der Rückroute des Tunneltraffics.
Klassischer Anfängerfehler und ein Traceroute hätte dir das auch gezeigt. 😉 Guckst du dazu auch HIER.
(172.20.30.1 ist hier "geraten" die IP Adresse der OPNsense im Management VLAN 30)
Nebenbei würde dir ein IKEv2 VPN auf der OPNsense die überflüssige Frickelei mit externer VPN Clientsoftware ersparen:
IPsec IKEv2 VPN für mobile Benutzer auf der pfSense oder OPNsense Firewall einrichten
Moin,
Ich selber nutze nur ein CBS350 als Core Switch und CBS250 als Uplink Switch. Wichtig ist, wenn ich ich nicht irre, der Uplink vom CBS350 1 zum CBS350 2
Und am CBS350 2 sollte der Port wo der AP angesteckt werden so aussehen
Gruß
Ich selber nutze nur ein CBS350 als Core Switch und CBS250 als Uplink Switch. Wichtig ist, wenn ich ich nicht irre, der Uplink vom CBS350 1 zum CBS350 2
interface GigabitEthernet XX
description "Uplink "
switchport mode trunk
switchport general allowed vlan add 1,10,20,30,40,50,60 tagged
Und am CBS350 2 sollte der Port wo der AP angesteckt werden so aussehen
interface GigabitEthernet XX
negotiation 100f
description "WLAN Flur OG"
switchport mode trunk
switchport general allowed vlan add 10,20,40,50 tagged
switchport general allowed vlan add 1 untagged
Gruß
@headcrash warum ist der AP-Port als Trunk konfiguriert? In der Regel ist die Kommunikation über ein untagged VLAN zum WLC/Firewall/Router verschlüsselt (DTLS), von daher ist Trunk nicht notwendig. Die VLAN Taggs werden dann direkt der SSID zugewiesen.
Und aus diesem Grund muss der Port an dem der AP angeschlossen ist, ein Trunk Port sein mit Management als nativ Vlan. Wie sonst sollen die VLan's über der Port gehen?
warum ist der AP-Port als Trunk konfiguriert?
Weil der Kollege mit einem MSSID (Multiple SSID) Setup arbeitet. Sprich der AP spannt mehrere WLAN Netze bzw. SSIDs auf die dann auf dedizierte VLANs gemappt sind.Klassisches Allerwelts MSSID Setup.... (Siehe zu der Thematik auch HIER)
Abgesehen davon verwendet der TO (vermutlich) keinen Controller sondern betreibt die Cisco Accesspoints sehr wahrscheinlich nicht im Lightweight sondern im Standalone Mode?!
Das was du da Controller bezogen beschreibst ist zudem tiefstes WLAN Neandertal mit einem zentralen CAPWAP Tunneling der APs auf den Controller der dann die MSSIDs auskoppelt.
Sowas hat man in Urzeiten einmal gemacht aber bei heutigen WLAN Raten ist sowas nicht skalierbar und damit sinnvoll nutzbar.
Man bräuchte mehrere 40G oder 100G Interfaces am Controller um heutige WLAN Bandbreiten so garantieren zu können. Solche Designs sind deshalb lange tot und man macht sowas heute mit Local Termination oder auch Local Breakout oder Flexconnect genannt und terminiert die APs dann direkt an der Switch Backbone Infrastruktur mit dem entsprechenden MSSID zu VLAN Tagging am Port.
@headcrash in deinem Screenshot ist der Port Access, weiter oben aber auf Trunk. Das widerspricht sich etwas.
@aqui mir ist das Thema WLAN "local termination" nicht bekannt und auch die anderen Begriffe ergeben keine passenden Suchergebnisse bis auf den letzten. "FlexConnect" scheint hier auch ein Produkt von Cisco zu sein. Btw habe ich dazu das hier gefunden...
When configuring a wireless access point to function in FlexConnect mode, it can be connected to a switch using either an access port or a trunk port.
Wenn das alles nur in der Cisco-Welt funktioniert, dann ist das irrelevant und das "Neandertal" weiterhin passend. Es sei denn, die anderen Hersteller haben das unter einem anderen Namen implementiert.
Abgesehen davon deine Aussage mit 40/100G am WLC ist ziemlich vage/übertrieben. Selbst wenn die APs mit 10GbE am Netz hängen, verteilt sich die Bandbreite auf 2.4, 5 und 6 GHz und Anzahl der Clients. Also mehr als 10Gbps werden nicht möglich sein.
@aqui mir ist das Thema WLAN "local termination" nicht bekannt und auch die anderen Begriffe ergeben keine passenden Suchergebnisse bis auf den letzten. "FlexConnect" scheint hier auch ein Produkt von Cisco zu sein. Btw habe ich dazu das hier gefunden...
When configuring a wireless access point to function in FlexConnect mode, it can be connected to a switch using either an access port or a trunk port.
Wenn das alles nur in der Cisco-Welt funktioniert, dann ist das irrelevant und das "Neandertal" weiterhin passend. Es sei denn, die anderen Hersteller haben das unter einem anderen Namen implementiert.
Abgesehen davon deine Aussage mit 40/100G am WLC ist ziemlich vage/übertrieben. Selbst wenn die APs mit 10GbE am Netz hängen, verteilt sich die Bandbreite auf 2.4, 5 und 6 GHz und Anzahl der Clients. Also mehr als 10Gbps werden nicht möglich sein.
@DerMaddin
Das liegt vielleicht daran das der TO kein Firmware Update gemacht hat.
Aber beim TO sind Access VLAN ID und General PVID dem VLAN 20 zugewiesen und Native VLAN ID ist dem VLAN 30 zugewiesen.
Da bin ich mir nicht sicher ob das so in Ordnung ist.
Gruß
Das liegt vielleicht daran das der TO kein Firmware Update gemacht hat.
Aber beim TO sind Access VLAN ID und General PVID dem VLAN 20 zugewiesen und Native VLAN ID ist dem VLAN 30 zugewiesen.
Da bin ich mir nicht sicher ob das so in Ordnung ist.
Gruß
In einem MSSID WLAN Setup muss der AP Anschlussport am Switch zwangsweise als Trunk gesetzt sein. Wie sollte man sonst die auf die VLANs getaggten SSIDs übertragen können.
Generell sollte man die APs so betreiben damit das Management Interface bzw. VLAN ohne ein zugewiesenes WLAN arbeitet. Wer will in seinem gesicherten Management VLAN ein VLAN betreiben? Aus Sicherheitsgründen ist das ein NoGo.
IKEv2 VPN Server für Windows und Apple Clients mit Raspberry Pi
https://www.cisco.com/c/de_de/support/docs/wireless-mobility/wireless-la ...
Fakt ist das auch deine Clients .11r supporten müssen ansonsten scheitert eine Assoziation mit einem .11r aktiviertem WLAN.
@DerMaddin
"Local Breakout" gilt für alle WLAN Hersteller und ist nicht herstellerspezifisch. Sucht man nach den Begriffen im Englischen Kontext gibt es zig Treffer. Es ist also definitiv NICHT herstellerbezogen! Weiss man aber auch wenn man sich die Konzepte aller führenden WLAN Hersteller ansieht die ja diesbezüglich alle gleich sind.
Würde man dieses in einem Unternehmensnetz mit 20-50 und mehr APs alle zentral auf einen Controller tunneln muss man nicht im Detail erklären was passiert. Skalierbarkeit sieht anders aus. Da reichen auch nur 2-3 Clients pro AP um dann so ein Netz in die Knie zu zwingen.
Die Bandbreite verteilt sich keineswegs, wie auch, sondern kumuliert zentral am Controller da dort die Tunnel terminieren und der dann der zentrale Flaschenhals ist.
Bei zugünftig weiter steigenden WLAN Datenraten wäre es also ziemlicher Unsinn solche veralteten Tunnel Konzepte weiter zu verfolgen deshalb sind solche Tunneling Designs heutzutage praktisch tot und das bei allen Herstellern.
Weitere Nachteile wie den Single Point of Failure so eines Tunnel Konzeptes jetzt mal gar nicht beachtet.
Es bleibt dabei: Ein Konzept aus dem WLAN Neandertal...
Generell sollte man die APs so betreiben damit das Management Interface bzw. VLAN ohne ein zugewiesenes WLAN arbeitet. Wer will in seinem gesicherten Management VLAN ein VLAN betreiben? Aus Sicherheitsgründen ist das ein NoGo.
den Eindruck, dass Wireguard deutlich performanter ist.
Nein, das ist ein Trugschluss, denn die IPsec Durchsatzraten sind quasi identisch zu WG. IPsec IKEv2 und auch L2TP haben den großen Vorteil das man auf jeglichen Endgeräten die onboard VPN Clients benutzen kann die deutlich besser ins OS integriert sind als externe Software.Der Tunnel läuft über einen gemieteten vlan server
Auch das rennt mit IKEv2 und den onboard Clients problemlos und ist im Handumdrehen aufgesetzt:IKEv2 VPN Server für Windows und Apple Clients mit Raspberry Pi
noch eine Frage zur Konfiguration des IEEE 802.11r Standards
Cisco erklärt das Verfahren hier im Detail. Die Reass. Time solltest du deutlich höher wählen.https://www.cisco.com/c/de_de/support/docs/wireless-mobility/wireless-la ...
Fakt ist das auch deine Clients .11r supporten müssen ansonsten scheitert eine Assoziation mit einem .11r aktiviertem WLAN.
@DerMaddin
mir ist das Thema WLAN "local termination" nicht bekannt
Das mag sein und kann bei einem Server Administrator auch mal vorkommen. Server Profis müssen ja auch nicht unbedingt alle Netzwerk Feinheiten kennen. Dennoch sind dies schon seit Jahren bekannte Begriffe im WiFi Umfeld bzw. beim Design performanter WLAN Netze."Local Breakout" gilt für alle WLAN Hersteller und ist nicht herstellerspezifisch. Sucht man nach den Begriffen im Englischen Kontext gibt es zig Treffer. Es ist also definitiv NICHT herstellerbezogen! Weiss man aber auch wenn man sich die Konzepte aller führenden WLAN Hersteller ansieht die ja diesbezüglich alle gleich sind.
Also mehr als 10Gbps werden nicht möglich sein.
Das ist so pauschal gesagt natürlich nicht richtig. WiFi7 APs haben in der Regel durchgehend N-Base T Anschlüsse mit min. 2,5G und höher, da aktuelle WiFi Datenraten deutlich über 1G liegen und man anderweitig Bandbreite verschenken würde. Mit 2 oder 3 Radios landet man also auch deutlich über 2Gig pro AP.Würde man dieses in einem Unternehmensnetz mit 20-50 und mehr APs alle zentral auf einen Controller tunneln muss man nicht im Detail erklären was passiert. Skalierbarkeit sieht anders aus. Da reichen auch nur 2-3 Clients pro AP um dann so ein Netz in die Knie zu zwingen.
Die Bandbreite verteilt sich keineswegs, wie auch, sondern kumuliert zentral am Controller da dort die Tunnel terminieren und der dann der zentrale Flaschenhals ist.
Bei zugünftig weiter steigenden WLAN Datenraten wäre es also ziemlicher Unsinn solche veralteten Tunnel Konzepte weiter zu verfolgen deshalb sind solche Tunneling Designs heutzutage praktisch tot und das bei allen Herstellern.
Weitere Nachteile wie den Single Point of Failure so eines Tunnel Konzeptes jetzt mal gar nicht beachtet.
Es bleibt dabei: Ein Konzept aus dem WLAN Neandertal...
@aqui bitte Links zu dem "Local Breakout" Thema hier posten, ich bekomme nur "Local Breakout Internet" wenn ich danach suche
Das grundlegende Prinzip ist hier erklärt:
https://www.cisco.com/c/de_de/support/docs/wireless/catalyst-9800-series ...
Wie bereits mehrfach gesagt: Es ist nicht herstellerspezifisch sondern heisst bei anderen Herstellern nur schlicht unbd einfach anders wie z.B. local Termination bei Ruckus usw.
https://www.cisco.com/c/de_de/support/docs/wireless/catalyst-9800-series ...
Wie bereits mehrfach gesagt: Es ist nicht herstellerspezifisch sondern heisst bei anderen Herstellern nur schlicht unbd einfach anders wie z.B. local Termination bei Ruckus usw.
erreichen die Opnsense auf der 172.20.30.1 bzw. 172.20.45.1 nicht und umgekehrt auch nicht.
Bedeutet dann das du zu 99,9% ein Layer 2 Connectivity Problem hast, also das dann dein Tagging entweder auf OPNsense Seite oder Switch Seite nicht übereinstimmt bzw. falsch konfiguriert wurde. Weshalb die Acces Points ein funktionstüchtiges WLAN ausstrahlen, allerdings selbst per DHCP im vlan30 keine IP Adresse erhalten.
Hier begehst du vermutlich einen fatalen Denkfehler?!Die APs selber bekommen niemals in einem getaggten MSSID VLAN eine IP. Sie bekommen immer nur eine einzige Management IP und das immer im Native VLAN bzw. PVID VLAN.
Es ist also essentiell wichtig auf welches PVID VLAN dein physisches AP Interface gemappt ist. Nur da bekommt der AP eine IP was auch logisch ist, da DHCP Requests natürlich immer UNtagged gesendet werden. Wenn du kein oder das falsche PVID VLAN AP konfiguriert hast bekommt der AP logischerweise auch keinerlei Management IP.
Deshalb vermute ich, dass hier irgendetwas nicht passt.
So ist es!Du solltest also strategisch vorgehen und...
- dir am CBS Switch einen UNtagged Testport jeweils für das VLAN 30 und 45 erstellen, dort einen Testclient anschliessen und checken ob der korrekt in beiden VLANs eine passende IP, Gateway und DNS vom DHCP bekommt. Pingcheck auf jeweilige Firewall IP und Internet. Das verifiziert dann wasserdicht das dein VLAN Setup zw. OPNsense und CBS Switch sauber funktioniert!
- Gleiches machst du für die PVID VLAN ID die am AP Anschlussport anliegt! Damit stellst du sicher das auch die IP Adressvergabe im ungetaggten PVID VLAN am Accesspoint Port sauber funktioniert und korrekt ist.
- Dann checkst du ob der AP Port als "Trunk" Port (nicht General) definiert ist, das korrekte PVID, Native VLAN definiert ist und 30 und 45 dort tagged konfiguriert sind.
- Ist das der Fall bekommt auch der AP im PVID VLAN eine Management IP und mapped die beiden VLAN IDs 30 und 45 auf die entsprechenden MSSID WLANs. Logischerweise mapped man aus Sicherheitsgründen keine WLAN SSID auf das Management PVID Netz um das Management nicht in einem WLAN zu exponieren und nur via Kupfer erreichbar zu haben.
Irgendwo hast du also in dem ganzen Konstrukt einen Fehler zu mindestens für das PVID VLAN und die VLAN IDs 30 und 45 begangen. Man kann hier aber nur frei kristallkugeln weil die entsprechenden Setup Screenshots fehlen um das für dich einmal auf Korrektheit zu kontrollieren.
Hilfreiche Dokus dazu findest du, wie immer, HIER (OPNsense VLAN Tagging) und HIER (Cisco MSSID Setup).
Alles Wissenswerte zu einem korrekten OPNsense Wireguard Setup findest du HIER (Wireguard Responder (Server) Setup).
HIER ist das Setup einer OPNsense im Wireguard Initiator Mode (Client) zu sehen.
Wenn du dich an all diese Setup Vorgaben genau hältst kommt das alles auch sofort zum Fliegen!
dass ich erst nächstes Wochenende wieder physischen Zugang zum System habe...
Was bekanntlich allein DEIN Problem ist! Bei der Problematik kann dir, wie du sicher selber weisst, auch das allerbeste Forum nicht helfen.Pfiffige Netzwerker würden allerdings auf der OPNsense immer ein Client VPN einrichten damit man von überall Zugriff hat. 😉
Jetzt scheint es zu funktionieren
👍habe ich es auch geschafft den Aufbau zu Dokumentieren.
Alles richtig gemacht!👍
Die Accesspoints bekommen über den Trunkport beim Switch eine IP aus vlan30.
Ist korrekt, wenn das dein Management VLAN ist. Auf dem Mamnagement sollte tunlichst kein aktives WLAN (MSSID) liegen! (Security!)Aber in der gui wird angezeigt, das Current Native VLAN = Management VLAN1 ist.
Ja, das ist ja mehr oder minder normal. Das native VLAN was in der Regel im Default VLAN 1 liegt sendet ja (da es ja native bzw. PVID VLAN ist) keinerlei VLAN Informationen. Die VLAN ID dort gibt ja lediglich an in welches VLAN UNgetaggter Traffic ohne jegliche VLAN Information geforwarted wird.Wenn du nun also am AP Switchport PVID 30 gesetzt hast landet das auf der anderen Seite im VLAN 1 weil dort das Management Interface hingemappt ist. Die Endgeräte merken von diesem kleinen und kosmetischen Widerspruch nichts da diese Traffic ja keinerlei VLAN Information im Paket trägt wie es z.B. mit dem 802.1q Header bei tagged Frames der Fall ist. (Siehe auch hier in der VLAN Schnellschulung)
Wenn du also mit diesem kleinen kosmetischen "Fehler" leben kannst lass es so. Man könnte es auch auf AP Seite umbauen so das es wieder "passt" was aber deine Konfig unnötig aufblähen würde und außer der Kosmetik keinerlei Vorteile hätte.
Also klare Antwort auf deine Frage:
Nein. Es stellt natürlich kein Problem dar, wenn du bei den Accespoints VLAN1 als native belässt!
Ich habe im Netz leider keine sinnvollen Anhaltswerte gefunden.
Doch die gibt es aber in einem sehr weit gefassten Bereich. Ideal sind mittlere Wert in der vorgegebenen Spanne. Die 300 ist schon ok, kann aber auch 600 sein. Die harten minimal oder maximal Werte sollte man besser meiden.
Wenn es das denn nun war bitte deinen Thread dann hier auch als erledigt schliessen!
How can I mark a post as solved?
How can I mark a post as solved?