Verständnisfrage zu vLAN

Hi,

Gute Frage... Teste es doch mal

Wenn ich das gerade recht im Kopf habe:
administrative VLAN = Management VLAN. von hier kommst du auch an die SSH/ Web-GUI
operative VLAN = die VLANs, in denen alle produktiven Daten "herumschwirren". Folglich alles != administrative VLAN


Folglich:

• Forbidden bedeutet absolut kein Mitglied des VLANs
• Excluded ist erstmal kein Member, kann aber via GRVP zu einem Member werden

das bedeutet ja erstmal nur, dass man neben einem untagged VLAN auch mehrere tagged-VLANs auf den Port setzen kannst. Belässt du es nur bei dem untagged Port, verhält er sich ja "nur" wie ein normaler Access-Port


Gruß
em-pie

Hallo,

Schon mal dein Handbuch zu dein SG 200-26P gelesen und versucht zu verstehen was dort steht?
https://learningnetwork.cisco.com/thread/21665
http://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst4500/12-2/25e ...
http://techhead.co/introduction-to-cisco-vlans/
https://de.wikipedia.org/wiki/VLAN_Trunking_Protocol
http://www.cisco.com/c/en/us/support/docs/lan-switching/vtp/10558-21.ht ...

http://www.itslot.de/2013/11/cisco-vlans-fur-anfanger.html
http://www.itslot.de/2013/11/cisco-vlan-konfigurieren-anleitung.html

Gruß,
Peter

Öhm, du taggst einen Switchport mit VLAN1 und erzeugst damit einen TAG an jedem Ethernet-Frame, was der Switchport wegschickt. Die Frames können dann mit Wireshark abgefangen und analysiert werden -> quod erat demonstrandum


Wer? WAS ist die richtige Frage. http://www.cisco.com/en/US/tech/tk389/tk689/tk301/tsd_technology_suppor ... erklärt dir, was em-pie meint.

Moin,

Der Switch sollte es meiner Meinung nach trotzdem richtig einordnen. Jedoch würde er Pakete ins VLAN 1 ohne Tag zurück schicken, dadurch muss das Native VLAN (PVID) auf der anderen Seite VLAN 1 sein.

Gute Frage, bei den Catalysts hätte ich es auf DTP geschoben aber bei den SGs hab ich hier noch keine Möglichkeit gefunden unterschiedliche Werte zu erzeugen.

In welchen Zusammenhang? Mach den Screenshot am besten mal etwas größer, hab aktuell keinen Zugriff mehr auf SG Switches.
Edit: Ok an GVRP hab ich jetzt natürlich nicht gedacht, das sollte es schon sein.
http://www.itwissen.info/GVRP-GARP-VLAN-registration-protocol.html

Ist ja bei den SG Cisco standardmäßig so. Dann werden eben alle untagged Pakete über über die PVID einsortiert. Schade nicht, ist aber auch nicht schön...

VG
Val

Wir hier natürlich täglich auch !!
OK, das heisst an dem Port wird VLAN 1 ungetagged und VLAN 124 getagged übertragen. VLAN 1 Standard ungetagged da vermutlich Default VLAN
Das ist ganz einfach...
Da der Switch mit einem Paket das einen VLAN Tag mit 1 trägt nichts anfangen kann schmeisst der Switch das Paket gleich am Eingangsport weg (Paktet Drop)
Diese Frage ist neulich hier schon einmal genau beantwortet worden.
Das Beispiel vom Kollegen Pjordorf (Schadet das etwa ?) sagt alles zu der Frage
Ja, im Hinblick auf die Sicherheit schadet das und es ist besser den Port Modus sauber zu konfigurieren wenn man vor Überraschungen sicher sein will ! Das alles im Trunk Mode gesetzt ist ist ein Zugeständnis an Konfig Dummies die nicht wirklich wissen was sie tun und die nicht gleich bei der Hersteller Hotline anrufen sollen. Guckst du hier:
SG300: Modus "Access" vs. "Trunk"
Dem Manne kann geholfen werden !
http://ostinato.org
Kennt nun aber auch jeder Netzwerker !!
Oha...auch das kennst du nicht. Dann kannst du aber kein richtiger Netzwerker sein. Eins der Standardprotokolle in mittleren bis größeren Netzen.
Das ist sowas wie der weltweite Standard von Ciscos proprietärem VTP. GVRP sorgt dafür das VLAN Informationen automatisch von Switch zu Switch übertragen werden.
Also stellt dir vor du hast 10 Switches und 10 VLANs. Normal müsstest du die 10 VLANs 10mal konfigurieren. Mit GVRP steckst du alle Switches zusammen wie dein Netz aussehen soll. Definierst auf EINEM Switch die VLANs...et voila...mit GVRP kennen nun auch alle anderen netze diese VLANs automatisch. Ebenso wenn du eins oder alle wieder löschst.
Guckst du auch hier:
http://www.it-administrator.de/lexikon/gvrp.html
http://www.cisco.com/en/US/tech/tk389/tk689/tk301/tsd_technology_suppor ...
Jein, denn Cisco arbeitet wie das Gros der Hersteller mit Auto PVID.
Guckst du auch hier:
Warum gibt es PVID bei VLANs?

So gaaaanz langsam wird das ja was mit deinem Aufstieg zu einem Netzwerker...

Diese Aussage kann man in dieser Absolutheit leider nicht stehen lassen. Möglicherweise verhalten sich die ehemaligen Linksys-Modelle tatsächlich so, wenn sich der Port im Trunk-Mode befindet - das kann ich nicht widerlegen, da ich aktuell kein Gerät dieser Baureihe zum Testen da habe. Aber ich halte es eher für unwahrscheinlich. M.E. ist es sehr wahrscheinlich, dass der Switch eingehehend(!) auch Traffic mit VLAN1-Tag akzeptieren und richtig zuordnen wird, da an einem Trunkport nunmal tagged Frames eingehend zulässig sind und ihm das VLAN1 bekannt ist. Lediglich an einem Accessport sollte er dies eingehend droppen (aber selbst da wäre ich mir gar nicht so sicher). Dass der Antwort-Traffic natürlich ausgehend(!) trotzdem untagged übertragen würde, steht auf einem anderen Blatt und widerspricht dem Vorgenannten nicht.

Generell finde ich die Verwendung der Port-Modi "Access" und "Trunk" zwar praktisch, aber auch gefährlich, da man schon sehr genau wissen muss, welches Verhalten der jeweilige Hersteller hieran knüpft. Ich bezweifle, dass das bei allen Herstellern bis ins letzte Detail einheitlich ist - zumal man das Verhalten oftmals auch durch weitere Konfigurationsoptionen im Detail noch verändern kann.
Da ist mir ein standardkonformer Hybrid-Port lieber. Er gibt mir wesentlich mehr Kontrolle und Transparenz.

Gruß
sk

Also Catalysten z.B. droppen alle eingehenden Tagged Frames die nicht am Port mit switchport allow vlan xyz definiert sind auch wenn diese VLANs auf dem Switch vorhanden ist.
Brocade, Nortel, HP, Extreme machen es identisch so.
Ebenso macht es ein SG200 oder 300. Wenn das VLAN nicht tagged geflaggt ist im Setup wird es inbound nicht geforwardet.
Mikrotik forwardet z.B. generll kein VLAN 1 mit einem Tag sofern VLAN 1 das default VLAN ist.
Es gibt also Unterschiede.

Ja, logisch, der Switch hat dann auch nichts mehr zu einsortieren, was die PVID überflüssig macht.

Welche ungetaggten Pakete? Du hast beide VLANs, 1 und 124, auf dem Port getaggt, somit existiert kein untagged VLAN mehr auf dem Port.

Wenn jetzt von der Gegenstelle noch ungetaggte Pakete kommen sollten, werden diese bei der Annahme verworfen, da gibt es dann für die PVID nichts mehr zum einsortieren, ergo wird diese Funktion nicht mehr benötigt.

Das ist ja grundsätzlich so am Switch. Das Paket wird immer in das VLAN weitergeleitet mit dessen Tag es reinkommt am Switchport.
Hat der Switch dieses VLAN nicht konfiguriert ist ja die VLAN ID unbekannt und er kann es damit logischerweise nicht weiterleiten und dann dropped er es.
Klassisches Verhalten eines VLAN Switches....

Die PVID an einem Port sagt dem Switch in welches VLAN er ungetaggte Pakete forwarden soll ! Ungetaggten Pakete fehlt wie der Name schon sagt der VLAN Tag und damit hat der Switch keinerlei Möglichkeiten zu entscheiden WO dieser ungetaggte Traffic hin soll.
Über die PVID sagt man ihm das dann !
Eigentlich alles ganz simpel und logisch....

Das das Default VLAN in der Regel das VLAN 1 ist und dessen Frames IMMER untagged an tagged Uplinks übertragen wird muss man auch NIE das VLAN 1 irgendwie taggen.
Fragt sich warum du dir das leben so scher machst, denn die Logik dahinter ist sehr einfach.
Das du die PVID an einem Port auf 1 setzt und das auch noch gleichzeitig Tagged handeln willst ist technisch unmöglich.
Muss man ja auch gar nicht, denn es gibt kein Anwendungsdesign wo das so sein muss. VLAN 1 belasst man immer auf untagged.

Leute, Ihr müsst gedanklich einige Dinge stärker auseinander halten, sonst fällt es schwer, Zusammenhänge zu erkennen und ggf. auch mal kompliziertere Anforderungen umzusetzen.

Zugegeben, in 95,783periode Prozent der Fälle sind die Anforderungen zumindest in einem LAN recht simpel: Es gibt zum einen Endgeräte (z.B. Server, Clients), die ihrerseits gar nichts von der Existenz von VLANs wissen (müssen) und zum anderen eine aus verschiedenen Komponenten bestehende Infrastruktur, welche die Zugehörigkeit des behandelten Traffics zu VLANs berücksichtigen muss, um die daran geknüpften Bedingungen durchzusetzen. Bei der Datenübertragung zwischen den Infrastrukturkomponenten muß unter gewissen Bedingungen die VLAN-Zugehörigkeit mit übertragen werden, damit diese Information nicht verloren geht. Dies geschieht, indem in den Ethernet-Header eine entsprechende Information eingefügt wird (das sog. VLAN-Tag). Bei den Switchports zu den Endgeräten hin ist diese zusätzliche Kennzeichnung im Frame-Header weder ein- noch ausgehend erforderlich, wenn die VLAN-Zuordnung statisch anhand des Switchports erfolgt. In aller Regel ist es auch so, dass der Traffic an einem Endgeräteport sowohl ein- als auch ausgehend zum gleichen VLAN gehört.

Dieses sehr einfache aber sehr verbreitete Szenario erfordert also nur zwei Konfigurationsmodi:
a) sog. Accessports, die nur ein VLAN übertragen können und an denen der Traffic dieses VLANs sowohl eingehend als auch ausgehend ausschließlich ohne Kennzeichnung durch ein zusätzliches VLAN-Tag übertragen wird
b) sog. Trunkports, die mehr als ein VLAN übertragen können und die hierzu bei mehr als einem VLAN den Traffic ein- und ausgehend mit einer zusätzlichen Kennzeichnung versehen (VLAN-Tag)

Die meisten Switche bieten (zumindest auch) diese beiden Betriebsmodi und ermöglichen so auch dem weniger versierten Admin eine schnelle und sichere Konfiguration. Allerdings ist das Leben viel bunter und die Bandbreite der Anforderungen wesentlich breiter!
Bereits im LAN-Bereich ist es z.B. nicht immer so, dass die VLAN-Zuordnung statisch anhand von Switchports erfolgt. Sie kann z.B. auch anhand einer 802.1x-Authentifizierung, anhand der MAC-Adresse, anhand eines Priority-Tags, protokollbasiert (Layer3/4) oder z.B. per GVRP erfolgen. Auch gibt es Szenarien, in dem der Traffic in eine Richtung in einem anderen VLAN geführt wird, als der Antworttraffic in die Rück-Richtung, um z.B. switchübergreifend gewisse Funktionalitäten wie private VLANs zu erreichen. Nicht zuletzt kann es auch gewünscht sein, Traffic mit VLAN-Tags einfach nur durchzureichen, die der Switch selbst gar nicht kennt.
Spätestens wenn wir das LAN verlassen und uns dem Bereich der Serviceprovider zuwenden, bestimmt auch nicht mehr die ursprüngliche VLAN-Zuordnung oder gar die ursprüngliche VLAN-Kennzeichnung die spätere Weiterverarbeitung und Weiterleitung: Dort wird nach Herzenslust umgeschrieben, priorisiert, umverpackt, verworfen, umgeleitet usw. Hier müssen die Switche also wesentlich mehr können, als das oben dargestellte einfache Szenario. Gute Switche bieten hierfür dementsprechende erweiterte Optionen.

Man kann also nicht sagen, jeder Switch verhält sich generell so oder so. Dafür lässt der Standard auch bewusst zu viel Implementierungsspielraum. Vielmehr kommt es entscheidend darauf an, welches Defaultverhalten der Hersteller bei diesem konkreten Modell und bei dieser Firmwareversion implementiert hat, über welche (ggf. erweiterten) Konfigurationsmöglichkeiten der Switch verfügt und wie der zuständige Admin das Gerät im Einzelfall konfiguriert hat! Bei genauer Betrachtung zeigt sich häufig, dass manch Defaultverhalten lediglich eine Funktionslimitierung zugunsten einfacher Bedienbarkeit ist, die sich durchaus abwandeln lässt.

Man muss die eingesetzten Komponenten also genau kennen und verstehen. Bedeutet: Dokus lesen, Lehrgänge besuchen und vorallem: Testen!
Voraussetzung dafür ist dann freilich auch ein gewisses Abstraktions- und Vorstellungsvermögen.

Um die Vorgänge im Einzelnen verstehen zu können, muss man meines Erachtens zumindest 3 Sachverhalte unterscheiden und einzelnen betrachten:
1) Was passiert, wenn auf einem Switchport Traffic eingeht (Eingangs-Behandlung)
2) Wie wird dieser empfangene Traffic intern weiterverarbeitet (Klassifizierung, Veränderung und Weiterleitung)
3) Was passiert, wenn der Traffic auf einem Switchport ausgegeben werden soll (Ausgangsbehandlung)

Zu 1)
Je nach Konfigurationsmöglichkeiten des Switches entscheidet der Admin hier z.B. über den "Acceptable Frame Type". Also (eingehend!!!) entweder nur untagged Taffic, nur tagged Traffic oder beides.
Sofern untagged Traffic zugelassen wird, erfolgt (idR über die PVID) die Mitteilung an den Switch, welches VLAN er für ungekennzeichnet eingehenden(!) Traffic in dieser Phase assoziieren soll.
Sofern tagged Traffic eingehend zulässig ist, kann im Rahmen des sog. Ingress-Checks entschieden werden, ob der Switch auf diesem Port nur solchen Traffic annehmen soll, den er umgekehrt auch wieder hinauslassen würde (Prüfung auf VLAN-Membership). Ist kein Ingress-Check auf dem Port aktiv, akzeptiert der Port (eingehend) auch Traffic für VLANs, in denen er selbst gar nicht Mitglied ist! In aller Regel würde er jedoch dennoch solchen Traffic ausfiltern, der mit VLAN-IDs gekennzeichnet ist, die der Switch nicht kennt. Aber auch dieses Verhalten lässt sich meist abwandeln.

Zu 2)
In diese Phase fallen alle switchinternen Entscheidungs-, Veränderungs- und Weiterleitungsprozesse. Viele können vom Admin nicht näher gesteuert werden. Je nach Einsatzzweck (und Preisklasse) des Switches hat der Admin aber u.U. durchaus umfangreiche Eingriffsoptionen. Hierunter fallen u.a. die Themen ACL, Priorisierung, Spiegelung usw. Bei guten Switches kann man den Traffic nach bestimmten Merkmalen klassifizieren und darauf basierend mittels Policies in vielen Details umfangreich nachbehandeln. Es könnte beispielsweise die bisherige VLAN-ID entfernt und der Traffic regelbasiert einem anderen VLAN zugeordnet werden.

Zu 3)
In der Regel endet die interne Weiterbehandlung mit der Entscheidung, den Traffic an die Switchports weiterzuleiten, die Mitglied des (nunmehr zugeordneten) VLANs sind. Ob und in welcher Form dann der Traffic am jeweiligen Port ausgegeben wird, obliegt der Ausgangsbehandlung. So entscheidet jeder Switch anhand der Ziel-MAC-Adresse und seiner Cam-Table, ob er den Traffic an einem bestimmten Port ausgibt oder ob alle Memberports des VLANs (außer dem Eingangsport) zu fluten sind. Wenn der Traffic auszugeben ist, muss zusätzlich pro Port entschieden werden, ob der Traffic mit einer VLAN-ID zu versehen ist oder nicht (tagged oder untagged).

Quintessenz:
Die Festlegung der VLAN-Mitgliedschaft und des Taggings ja oder nein bezieht sich bei genauer Betrachtung also eigentlich nur auf das Egress-Processing. Es besteht weder ein technischer noch sachlicher Zwang, dass ein Switchport Mitglied eines VLANs sein muss, um Traffic für dieses VLAN anzunehmen. Zudem kann ein Port durchaus für das gleiche VLAN tagged und untagged Traffic (eingehend) annehmen (das geht logischer Weise aber nur bei einem VLAN). Auch kann Traffic des gleichen VLANs auf dem gleichen Port durchaus eingehend untagged und ausgehend tagged oder umgekehrt eingehend tagged und ausgehend untagged übertragen werden, wenn der Admin dies für erforderlich hält.
Erst mittels Optionen wie Ingress-Check, Port- und VLAN-Typisierung usw. wird herstellerspezifisch das Ingress-Verhalten an das Egress-Verhalten angeglichen. Da dieses in der Praxis aber für 95,783periode Prozent der Fälle wünschenswert und auch bedienungsfreundlicher ist, ist dies bei vielen Herstellern das Defaultverhalten. Zu einem leichteren Verständnis der Materie führt dies meines Erachtens jedoch nicht.

Gruß
sk

Leider nein. Aber die Hersteller liefern online genug Dokus. In Deutsch allerdings eher weniger



Ein MSSID- und VLAN-fähiger AP kommt selbstverständlich an einen Trunk-Port.



Dein Switch kann das auch. Siehe https://sbkb.cisco.com/CiscoSB/GetArticle.aspx?docid=07e54124d9be46b48d6 ...

Gruß
sk

Doch das geht sehrwohl. Jedoch ist die ausgehende Richtung gemeint! Bitte lies nochmal, was ich oben geschrieben habe.



Nirgends! Ich kenne zwar die SG-Reihe bislang noch nicht in der Tiefe (erst einmal Kontakt gehabt), aber ich vermute, dass die Spalte "operational VLAN" lediglich eine Anzeige des aktuellen Status ist. Diese kann sich durchaus von den Einstellungen des Admins unterscheiden, da ja Ports z.B. auch dynamisch über VTP oder GVRP Member werden können. Auch kenne ich es von anderen Switchen so, dass man einzelne VLANs auch deaktivieren kann. Dann existiert zwar administrativ eine diesbezügliche Konfig, diese ist jedoch nicht operational.

Gruß
sk

P.S.
Damit das Rumgerate hier endet, habe ich mir einen SG250 und einen SG350 für meine Testumgebung bestellt. Weiss aber nicht, wann ich Zeit finden werde, damit zu spielen, weil ich momentan beruflich sehr eingespannt bin.

Privat täte ich das auch nicht

Von jedem Hersteller gibt es die Modelle aber auch als kleine, preiswerte 8 Port Versionen mit denen es sich dann ohne Belastung von Portemonaie und Platz vortrefflich testen lässt und wenn sie über sind verbaut man sie irgendwo.
Für einen test ist es egal ob 48, 24 oder 8 Ports

Normal weist du das zuallererst in der Rubrik "Ports to VLAN" zu:

Das das VLAN nicht angezeigt wird kann daran liegen das du es nicht gesichert hast im Flash oder vergessen hast "Apply" zu klicken was wir jetzt aber mal nicht unterstellen wollen.
Was sagt denn die Übersicht ?? Dort müsste ja sowas zu sehen sein?

Einen Firmwarebug bei solch einer Basisfunktion kann man wohl ausschliessen aber trotzdem die Frage ob du mit der Firmware (hoffentlich) auf dem aktuellsten Release bist ??

Hallo Botschafter Sarek

Haben die beiden VLANs bei Dir das gleiche Subnetz? Wenn das verschiedene IP-Bereiche sind, könnte das noch Schwierigkeiten mit dem Routing geben - ich habe ein ähnliches Problem.

Schöne Grüße an Spock ;)

Access = ALLE Endgeräte Ports also Ports die als Endgerät feste einem VLAN zugeordnet sind ! Dieser Port Mode kann nur untagged Pakete verarbeiten
Trunk = Das ist der Mode den du benutzt um Tagging zu machen. Also dein Uplink Port zwischen den beiden SG200 Switches und den UniFi APs.
Hier hast du ja untagged Traffic immer im Default VLAN 1 und den Tagged Traffic ist dein VLAN 124.
Der General Mode macht mehr oder minder das gleiche wie der Trunk Mode er hat nur ein paar Modi aus der IEEE 802.1Q-Spezifikation mehr.
Du solltest aber immer nur den Access und den Trunk Mode verwenden !!

Also ist dein Setup ganz einfach:
Trunk Mode = die Uplink Ports der SG200 Switches untereinander und der UniFi APs (Untagged VLAN 1, Tagged VLAN 124)
Access = Jeweils die Endgeräte in den VLANs 1 und 124

Was du aber vermutlich generell übersiehst ist die Tatsache das diese beiden VLAN 1 und 124 bei dir ja vollkommen unter sich getrennte Netze sind. OK, was ja auch der tiefere Sinn von VLANs sind und man sie deshalb ja verwendet.
Die SG-200 Switches sind reine Layer 2 VLAN Switches. Daher gibt es in deinem Design also absolut KEINE Kommunikation zwischen den beiden VLANs. VLANs sind wie jeder Netzwerker weiss völlig getrennte Layer 2 Collision Domains.
Ist auch klar, denn für eine VLAN übergreidende Kommunikation wäre irgendwo eine Layer 3 Funktion (Routing) erforderlich, die aber so oben im obigen Design Layout nirgends zu sehen ist.
Damit ist einen Kommunikation aus reiner Layer 2 Sicht also vollkommen ausgeschlossen solange du keine Layer 3 Instanz in deinem Netzwerk hast.
Endgeräte im VLAN 124 haben also keinerlei Kontakt zu solchen in VLAN 1 und andersrum.
Wenn dann nur der Internet Router in VLAN 1 ist können auch nur Endgeräte aus dem VLAN 1 ins Internet...auch das ist vollkommen logisch weil du ja nirgendwo ein IP Routing hast zwischen den beiden VLAN IP Netzen.
Hier ist also vermutlich dein genereller Denkfehler...?!
Mal abgesehen davon das Enduser im Gäste- oder öffentlichen VLAN 124 natürlich niemals Zugriff auf den WLAN Controller haben sollten...auch hier irrst du gewaltig.
Was du brauchst ist also eine Layer 3 (Routing) Instanz die zwischen beiden Netzen vermittelt und die entsprechend Filterlisten vorhält. Entweder also ein Router mit IP Accesslisten oder ein kleine Firewall.
Ideal wäre ein Layer 3 Switch wie der Cisco SG-300 gewesen aber dazu ist es jetzt zu spät weil du das falsche Modell gekauft hast.

Was du brauchst ist also eine Layer 3 Instanz die dir die beiden Netze im L3 zusammenfasst und sie von dort auf den Internet Router routet.
Das hiesige VLAN Tutorial beschreibt das alles im Detail und hat sogar mit dem Praxisbeispiel exakt genau dein Design.
VLAN Installation und Routing mit pfSense, Mikrotik, DD-WRT oder Cisco RV Routern
Denkbar wäre auch den Server bzw. dessen NIC als Trunk zu konfigurieren und den Server als L3 Router zu verwenden:
VLANs über 802.1q Trunk auf Windows und Linux Rechnern realisieren
Das hätte aber den gravierenden Nachteil das Traffic vom Besuchernetz über den Server geleitet werden muss. Mal ganz davon abgesehen das ein Server immer "serven" soll und NICHT "routen".

Hallo,

Und du meinst das dann deine VLANs noch was tun können oder warum sollen deine VLANs alle das gleiche IP Netz nutzen?

Mal wieder eine eminent wichtige Komponenten und Information von dir (absichtlich) unterdrückt worden.

Ein Server ist ein Server, ein Router ist ein Router. Du hast einen Vigor 2860 Router, nimm den. Man kann auch eine Gartenharke (Rechen) nehmen um sich sein allerwertesten abzuwischen

Gruß,
Peter

aber es macht einen Unterschied, ob es ein Speedport ist, oder ein Lancom/ Cisco/ ... (bzw. in deinem Fall ein Vigor).

Zu deinem vorhaben, beiden VLANs das selbe IP-Netz zu geben:
STell dir vor, du bist Router und erhälst anfragen für das Netz 192.168.130.0/24. Nach welchem Merkmal willst du denn jetzt die Pakete für das richtige VLAN-Interface zuordnen? Ich würde raten und vermutlich immer alle Pakete für das sichere Netz in das des WLANs schicken und umgekehrt. Ich weiss ja nicht, was richtig ist.
Es ist daher ziemlich wichtig, dass du für jedes VLAN ein eigenes Netz kreirst. Du kannst ja auch 1x 192.168.130.0/25 und einmal 192.168.130.128/25 machen. Zwei getrennte Netze, die auf den ersten Blick aber wie ein 24er Netz aussehen (wenn man nicht sofort due Subnetzmaske betrachtet).

Alles andere hat aqui ja bereits gesagt:

• den Port, an dem der Vigor hängt auf Trunk belassen und Vlan 1 untagged, VLAN 124 tagged
• den Vigor an dem Port entsprechend einrichten (siehe hier) und jedem VLAN eine IP geben, z.B.
• VLAN 1 192.168.130.1 /25
• VLAN 124: 192.168.130.129 /25
• zwischen den beiden SGs die Ports auf Trunk setzen und das VLAN 1 auf untagged, das VLAN 124 auf tagged
• den Port des Controllers und der APs auf Trunk setzen
• den Controller und die APs auf VLAN1 untagged, auf VLAN 124 auf tagged
• alle übrigen Ports auf ACCESS setzen
• alle Endgeräte für das VLAN 1 auf untagged setzen
• alle Endgeräte für das VLAN 124 auf untagged setzen

Auch dann: zwei IP-Netze. oder baust du Firewall-Regeln anhand von MAC-Adressen zusammen?

Ich kenne das nur von Cisco's WLC: der WLC hat in jedem VLAN eine eigene IP und routet selbst nichts (dafür habe ich ja meinen Core-Switch).

Jo, macht der quasi auch. Habe es nur mit erwähnt, falls doch mal ein Kabelgebundenes Gerät an einen der Switche gesteckert werden soll...

Das ist natürlich Quatsch und ein Denkfehler, denn wie jeder weiß arbeitet ein Accesspoint ja nur als simple Bridge.
Folglich sind deine WLAN Clients aus der SSID die aufs VLAN 124 gemappt sind alle vollkommen isoliert im VLAN 124 und kommen da nicht raus.
Fataler Denkfehler !
OK, das bedeutet das der Vigor dann die beiden IP Netze terminiert sei es steinzeitlich mit 2 separaten Kabeln oder einem getaggten Uplink. Ist das so richtig ?
Dann hättest du natürlich wieder deinen L3 Router und alles ist gut
Was die Anbindung des WLAN Controllers dann noch etwas anspruchsvoller macht im Hinblick auf die Sicherheit.
Klar, nur wäre es hilfreich gewesen von dir mitzuteilen ob das ein 30Euro Baumarkt Router wie üblich ist oder ein Cisco..oder eben ein Vigor der etwas mehr auf dem Kasten hat. Solche Oberflächlichkeiten in der Schilderung triggern immer nur Missverständnisse und damit überflüssige Diskussionen die nicht zielführend sind.
Kollege em-pie hat ja schon die IP Adressierung und die korrekte Lösung präsentiert.
Fehlt nur noch anzumerken das der WLAN Controller dann in eine DMZ gehört, also ein 3tes VLAN sofern er wirklich zentral die Landing Page des Captive Portals beherbergt.
Und natürlich kann der mehrere Ports haben. Ubiquity supportet den Betrieb auf einem sparsamen RaspberryPi und den kann man mittels VLAN Interfaces:
Netzwerk Management Server mit Raspberry Pi
oder physischer Interfaces (USB-Ethernet Adapter) problemlos erweitern.
Fazit: Du solltest dein ganzes Konzept nochmal gründlichst überdenken. Aus Layer 3 Sicht ist das sehr suboptimal um das mal vorsichtig zu sagen.

Ja, aber 2 VLANs (mit entsprechenden IP Netzen dadrin) haben ja nix mit der physischen Verkabelung zu tun !!
Du kannst natürlich steinzeitlich pro VLAN ein separates Kabel ziehen, du kannst es aber auch Netzwerker üblich mit einem Tagged Uplink auf den Router übertragen.
Siehe VLAN Tutorial:
VLAN Installation und Routing mit pfSense, Mikrotik, DD-WRT oder Cisco RV Routern
Das dortige Beispiel des DD-WRT Routers entspricht exakt deinem Szenario !!
Vielleicht einfach mal lesen und verstehen

Wäre ein gruseliger Designfehler wenn das nicht ginge. Aller WLAN Hersteller mit einem Controller haben eine Box mit den üblichen 2-4 Interfaces.
Dort kann man die VLANs bzw. den Controller dann sehr granular zuordnen. Eigentlich ungewöhnlich das Ubiquity sowas nicht macht, denn man will ja wohl kaum ein öffentliches Captive Portal in seinem internen oder noch schlimmer Management Segment haben
Die Hardware usw. ist auch soweit OK und auch die Verkabelung. Da ist dein Konzept schon OK und muss nicht verbessert werden.
Es ist einzig die Terminierung auf dem Router (entweder einzelne Strippen oder Trunk) und die Plazierung des Captive Portals.
Aber mit einem guten VLAN Switch wie du ihn hast und dem Router ist das ein Kinderspiel.
Also nur noch das Finetuning

Wenn du mit einem IP Netz arbeitest brauchst du auch keine VLANs !!
Denn dann sind ja so oder so alle wieder in einem Netz. Vergiss den Unsinn....das ist üble Frickelei.
Nein !
Wie oben berits mehrfach gesagt ist an einem tagged Uplink das Default (oder native) VLAN immer untagged mit dran. Dieses VLAN muss man also de facto NICHT taggen ! Sollte es auch nicht !
Ein Tagged Uplink ist immer das gleiche wie ein Trunk !!!

Mit dem Terminus Trunk mus sman nur vorsichtig sein. Für Cisco Menschen ist das ein tagged Uplink für den Rest der gesamten Netzwerk Welt aber eine Link Aggregation, also das Bündeln von mehreren Links zu einem virtuellen. LAG, Teaming oder Bonding nennt man das auch.
In so fern schafft der Terminus Trunk immer nur Verwirrung...
Hier ist aber ein Trunk ein Tagged Uplink bzw. ein- und dasselbe.
Nein, das ist wieder falsch oder du missverstehst es !
Es geht ja lediglich einzig um die Trunks oder tagged Links. Im Beispiel hast du den Switch der ganz viele Ports hat die untagged diversen Endgeräten in diversen VLANs zugeordnet sind. Genau wie bei dir also...
Dann der Tagged Uplink = Trunk auf den Internet Router.
Solche Router haben für jedes VLAN dann ein internes virtuelles IP Interfaces. Quasi virtuelle Ports wenn du so willst.

Vom Grundstz her korrekt, aber wie soll dein Router (Vigor) denn wiederum die Pakete sauber zuordnen können. Beim Routing wird auf Layer3 (also mit IPs) gearbeitet. Woher soll der Vigor denn wissen, ob die IP 192.168.130.123 nun im VLAN 124 oder VLAN1 hängt und morgen dann nicht wieder im anderen VLAN? Zudem werden deine DHCP-Server vermutlich auch nicht richtig rund laufen! Trenne das einfach und gut. Erspart dir eine Menge Ärger und Zeit bei irgendwelchen Fehlersuchen. Denn wenn dein Device eine IP aus einem anderen Segment erhält, ist das eindeutiger zu sehen, als wenn du mit Wireshark (mühsam) analysierst, welchen Weg das Paket gelaufen ist...
sehr gut


Routest du über den Vigor, kombiniert mit dessen Firewall.
Alles was aus dem Netz des VLANs 124 kommt, darf ins WWW und auf die IP des Controllers, ergänzt um den relevanten Port (vermutlich Port 80/ 443. Wenn möglich (kenne den Controller nichT) solltest du dann noch mindestens die Management-Oberfläche des Controllers auf einen anderen Port legen (z.B. 11443/ 11080). Vllt. kann man dem Ding ja sogar beibringen, dass nur von bestimmten IPs aus auf die Management-Oberfläche zugegriffen werden darf...

Deine erste Zeichnung ist etwas wirr....
Einmal hat das 10er Netz einen 22er Prefix, dann wieder einen /24er...ja was denn nun ? Solche Unklarheiten bergen die Gefahr eines Subnet Mismatches was dann gravierende Folgefehler haben kann.
Ein 16er Prefix auf das gesamte 192.168er Netz zu legen ist ja auch Unsinn. Hier solltest du mal mit sinnvollen Subnetzmasken arbeiten. OK ist vermutlich nur der Test und damit dann irrelevant.

Das Produktivsystem Design ist dafür dann absolut korrekt und richtig. Wie im Bilderbuch und könnte man glatt ins VLAN Tutorial übernehmen hier.
Genau so sollte es aussehen !

Man kann auch das Testnetz vom Restnetz mit einem 40 Euro Router trennen
Wir warten dann mal gespannt auf den Dienstag...

Ooopsss.... How come ?? Bei solch einem Banalszenario kann man ja nun wahrlich nicht viel falsch machen. Zumal du ja alles auch bilderbuchmäßig geplant und getestet hast.
Was genau meinst du mit "Ich bekomme keine IP-Adresse" ???

• Der AP bekommt keinen Management IP Adresse im VLAN 1 ?
• Ein Client der sich auf der SSID einbucht die aufs VLAN 124 gemappt ist bekommt keine IP ???

Das ist unklar:
Troubleshooting:
Nimm einen Laptop stecke den in einen untagged Port im VLAN 1 und in einen untagged Port im VLAN 124 und checke dort ob die IP Adressen via DHCP bekommst !!!
Das testest du auf Ports an allen Switches die diese VLANs transportieren.
So schliesst du doch erstmal ganz sicher aus das es Problem mit dem DHCP Server oder dem Anschluss des DHCP Servers in den beiden VLAN Segmenten gibt !
Jetzt eierst du ja rum und weisst nicht genau ob es am DHCP Server, dessen VLAN Anbindung oder den APs liegt und suchst dir einen Wolf.
Warum gehst du hier nicht strategisch vor wie man es eigentlich sollte ??
Logo das du da dann eine IP bekommst aus dem VLAN 1. Vermutlich hast du dich dann in der SSID eingebucht die dem VLAN zugeordnet ist, richtig ? Auch hier bist du leider wieder sehr oberflächlich in der Beschreibung

ALLE angeschlossenen APs sollten eine Management IP aus dem VLAN 1 erhalten. Idealerweise eine statische oder eine feste über eine Mac Reservierung im DHCP.
Damit sind dann erstmal die APs komplett managebar im VLAN 1.
Wenn du an einem untagged Port eine IP aus dem VLAN 124 bekommst funktioniert ja auch der DHCP Server dort, dann kann es nur ein Fehler in der Konfiguration des APs seins im Mapping SSID Name zu VLAN ID.
Bekommst du keine IP im VLAN 124 wäre es mal sinnig gewesen dem WLAN Client im VLAN 124 / bzw. 124 gemappter SSID eine statische IP zu geben und zu checken ob man einen anderen Laptop oder Endgerät im VLAN 124 anpingen kann.
Das würde dann wenigstens verifizieren das die VLAN Zuordnung richtig ist und auch das Mapping SSID zu VLAN ID richtig ist.
Dann wäre der böse Buhmann der DHCP Server oder die Anbindung des DHCP ans netzwerk das Problem.

Das sind simple Binsenweisheiten und Test die man vornimmt um das Problem strategisch einzukreisen. Bei deinem Popelnetz ne Sache von 10 Minuten. Fragt sich eigentlich nur warum es schon daran scheitert...
OK, ein Lichtblick und der richtige Test.....
Ist dann wie schon vermutet der DHCP Server bzw. dessen Anbindung oder Konfig Fehler im AP beim SSID zu VLAN ID Mapping !
Von WO bekommen denn die Clients im VLAN 124 ihre IP Adressen ?? Router ? Controller ?? Bzw. klappt denn die DHCP Vergabe im VLAN 124 auf einem Kupferport ??
Wenn ja, dann kannst du den Fehler rein auf die Fehlkonfig des APs eingrenzen.

Na ja wenn man in der IT arbeitet sollte man schon ein klein wenig des Englischen mächtig sein !! Weiss man aber schon seit Jahren und ist auch Berufsgrundlage wenn man nicht einfacher PC Schrauber bleiben will....
Jeder in der IT der mal deutsche Handbücher gesehen hat kennt das wie gruselig die sind. Die machen die Sache meist schlimmer als besser.
Aber du isst ja vermutlich auch deutsche Bananen, oder ?
Aber gut wenn nun alles rennt wie es soll, dann kann der Dienstag ja nun wirklich kommen...

Na ja ...du weisst mittlerweile als ITler ja selber wie weltfremd solche Einstellungen sind.
Jedenfalls in der Netzwerkbranche passieren 99% der Entwicklungen in den USA und NICHT in Europa.
Deutsche Handbücher haben nichtmal Premium Hersteller.
Das sind alle börsennotierte Unternehmen für die primär der Umsatz und Rendite zählt. Deine von dir zitierte "Kundenfreundlichkeit" kommt da allerhöchstens erst an 10ter Stelle...wenn überhaupt.
Und du bewegst dich mit deinen von dir eingesetzten Produkten zudem noch im Billigsektor. Da zählt eh nur Volumen und Umsatz und jedes Bautel auf der Platine was gespart werden kann. Denn keiner will für Entwicklung, Service und Support oder gar sowas exotische wie Kundenzufriedenheit bezahlen.
Da geht es rein nur um Massenprduktion und Geld. Also nicht jammern und diese evidenten ökonomischen Fakten mal akzeptieren (und ein engliches Dictionary kaufen )
Aber auch das sind langjährige Binsenweisheiten die jeder kennt...
Wenn man dann in einem der seltenen deutschen Handbücher mal lesen muss das "Browser" dort als "Stöberer" im Deutschen übersetzt wurde oder andere gruselige Dinge kann man es besser gleich lassen.
Da ist dann sinnvoller mit englischem Halbwissen das "richtige" Manual zu lesen.
Wie gesagt....deutsche Bananen...das ist auch so weltfremd. An diesem Fakt wird sich in der schnellebigen IT Branche auch so schnell nichts ändern und Englisch ist dort nunmal die lingua franca das wird auf absehbare Zeit auch so bleiben.
Spielt ja aber für den kommenden spannenden Dienstag wenn du Life gehst ja gar keine Rolle...

Da bist du ganz sicher nicht alleine, aber die knallharte Wahrheit ist ja leider so....mit all den Nachteilen.
Viele vergessen das leider und haben einen verklärten Blick wie solche Unternehmen wirklich ticken. Aber auch der Verbraucher auf der anderen Seite zwingt denen das auch zum Teil auf.
Na ja ist alles gesagt dazu...
Konzentrieren wir uns mal aufs Wesentliche und den Dienstag

Ein Wireshark Trace an dem Port hätte dir das in Sekundenschnelle gezeigt
Möglich aber auch das die Draytek Gurken das gar nicht supporten.
Letztendlich geht es ja auch so. Hast sogar pro VLAN noch ein dediziertes Kabel mit entsprechend dedizierter Bandbreite und musst keinen Draht sharen was ja auch nicht so schlecht ist.
Gut die Kabelfrickelei ist natürlich nicht schön aber wenns erstmal geht...alles gut.
Ich check mal das Vigor Handbuch eben....

Doch ! Ist wie zu erwarten war supportet !
Siehe hier:
https://www.draytek.co.uk/archive/kb/kb_vigor_8021qvlan.html
Kapitel: VLAN with a mix of tagged and untagged
Untagged dann in dem Beispiel auf Port P1 ist dein VLAN 1 (entspricht VLAN0 im Vigor) und der Rest 124 usw. tagged !
Der Tagged Port VID 124 wird dann entsprechend der Zuweisung dem LAN Interface für das 124er Segment zugeordnet.
Eigentlich auch von der Konfig recht logisch wie das aussieht. Fragt sich warum du daran gescheitert bist.
Wireshark wäre hier immer dein Freund...