maximalz

CAP ax bekommt keine Verbindung zum Capsman

Hallo zusammen,
ich versuche gerade, meinen neuen cAP ax am RB5009 mit Capsman ans Laufen zu bekommen. Beider Geräte laufen auf ROS 7.18.2, der RB5009 als Capsman hat die Pakete routeros und wireless drauf, der Cap routeros und wifi-qcomm.

Ich habe mich an die Anleitung von https://help.mikrotik.com/docs/spaces/ROS/pages/224559120/WiFi#WiFi-CAPs ... gehalten und sehe den Cap als DHCP-Lease und kann auch über die IP per Browser verbinden.

Ich sehe ihn aber weder auf dem Capsman unter wifi/RemoteCAP, noch sehe ich eine Capsman-Verbindung auf dem Cap unter wifi/wifi, sondern nur "no connection to Capsman".

Ich kann vom Cap aus dem Terminal sowohl den Capsman, interne Systeme, als auch externe Hosts (Google) anpingen.

Die Konfiguration des Cap ist

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
# 2025-03-19 18:50:37 by RouterOS 7.18.2
# software id = ML4D-R49A
#
# model = cAPGi-5HaxD2HaxD
# serial number = ...
/interface bridge
add admin-mac=F4:1E:57:30:64:37 auto-mac=no comment=defconf name=bridgeLocal
/interface wifi datapath
add bridge=bridgeLocal comment=defconf disabled=no name=capdp
/interface wifi
# no connection to CAPsMAN
set [ find default-name=wifi1 ] configuration.manager=capsman datapath=capdp
# no connection to CAPsMAN
set [ find default-name=wifi2 ] configuration.manager=capsman datapath=capdp
/interface bridge port
add bridge=bridgeLocal comment=defconf interface=ether1
add bridge=bridgeLocal comment=defconf interface=ether2
/interface wifi cap
set discovery-interfaces=bridgeLocal enabled=yes slaves-datapath=capdp
/ip dhcp-client
add comment=defconf interface=bridgeLocal
/system clock
set time-zone-name=Europe/Berlin
/system note
set show-at-login=no

und die vom Capsman (um Leases und Firewallregeln befreit, da ich im Log nichts auffälliges dahin gehend sehe)

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
# 2025-03-19 18:50:00 by RouterOS 7.18.2
# software id = VRR3-52VH
#
# model = RB5009UPr+S+
# serial number = ...
/interface bridge
add ingress-filtering=no name=vlan-bridge port-cost-mode=short \
    vlan-filtering=yes
/interface ethernet
set [ find default-name=ether2 ] poe-out=off
set [ find default-name=ether4 ] auto-negotiation=no poe-out=off speed=\
    100M-baseT-full
set [ find default-name=ether7 ] poe-out=off
set [ find default-name=ether8 ] poe-out=off
/interface vlan
add interface=vlan-bridge name=vlan1 vlan-id=1
add interface=vlan-bridge name=vlan10 vlan-id=10
add interface=vlan-bridge name=vlan11 vlan-id=11
add interface=vlan-bridge name=vlan12 vlan-id=12
add interface=vlan-bridge name=vlan20 vlan-id=20
add interface=vlan-bridge name=vlan30 vlan-id=30
/interface bonding
add mode=802.3ad name=bonding1 slaves=ether7,ether8 transmit-hash-policy=\
    layer-3-and-4
/interface list
add comment="WAN interfaces" name=WAN  
/interface wifi datapath
add bridge=vlan-bridge disabled=no name=datapath-privat vlan-id=20
add bridge=vlan-bridge disabled=no name=datapath-gast vlan-id=10
/interface wifi security
add authentication-types=wpa2-psk,wpa3-psk disable-pmkid=yes disabled=no ft=\
    yes ft-over-ds=yes name=auth-privat
add authentication-types=wpa2-psk,wpa3-psk disable-pmkid=yes disabled=no ft=\
    yes ft-over-ds=yes name=auth-gast
/interface wifi configuration
add datapath=datapath-gast name=xGHz-gast security=auth-gast ssid=\
    netzwerk.gast
add datapath=datapath-privat name=xGHz-privat security=auth-privat ssid=\
    netzwerk.privat
/interface wireless security-profiles
set [ find default=yes ] supplicant-identity=MikroTik
/ip pool
add name=dhcp_vlan1 ranges=192.168.1.10-192.168.1.200
add name=dhcp_vlan10 ranges=192.168.10.10-192.168.10.200
add name=dhcp_vlan20 ranges=192.168.20.10-192.168.20.200
add name=dhcp_vlan30 ranges=192.168.30.10-192.168.30.200
add name=dhcp_vlan11 ranges=192.168.11.10-192.168.11.200
add name=dhcp_vlan12 ranges=192.168.12.10-192.168.12.200
/ip dhcp-server
add address-pool=dhcp_vlan1 interface=vlan1 lease-time=1m name=dhcp1
add address-pool=dhcp_vlan10 dhcp-option-set=guest interface=vlan10 \
    lease-time=10m name=dhcp10
add address-pool=dhcp_vlan20 dhcp-option-set=internal interface=vlan20 \
    lease-time=10m name=dhcp20
add address-pool=dhcp_vlan30 interface=vlan30 lease-time=10m name=dhcp30
add address-pool=dhcp_vlan11 dhcp-option-set=guest interface=vlan11 \
    lease-time=10m name=dhcp11
add address-pool=dhcp_vlan12 dhcp-option-set=guest interface=vlan12 \
    lease-time=10m name=dhcp12
/dude
set enabled=yes
/interface bridge port
add bridge=vlan-bridge comment="AccessPoint (OG)" \  
    ingress-filtering=no interface=ether6 internal-path-cost=10 path-cost=10
add bridge=vlan-bridge comment="AccessPoint (EG)" \  
    ingress-filtering=no interface=ether5 internal-path-cost=10 path-cost=10
add bridge=vlan-bridge comment="Switch Wohnzimmer" ingress-filtering=\  
    no interface=ether4 internal-path-cost=10 path-cost=10
add bridge=vlan-bridge comment="cAP ax" ingress-filtering=no interface=ether3 \  
    internal-path-cost=10 path-cost=10
add bridge=vlan-bridge comment="VLAN 11" frame-types=\  
    admit-only-untagged-and-priority-tagged ingress-filtering=no interface=\
    ether2 internal-path-cost=10 path-cost=10 pvid=11
add bridge=vlan-bridge comment="Uplink" ingress-filtering=no \  
    interface=bonding1 internal-path-cost=10 path-cost=10
/interface bridge settings
set use-ip-firewall-for-vlan=yes
/ip firewall connection tracking
set udp-timeout=10s
/interface bridge vlan
add bridge=vlan-bridge tagged=vlan-bridge vlan-ids=1
add bridge=vlan-bridge tagged=vlan-bridge,bonding1,ether6,ether5,ether3 \
    vlan-ids=10
add bridge=vlan-bridge tagged=vlan-bridge,bonding1,ether6,ether5,ether3 \
    vlan-ids=20
add bridge=vlan-bridge tagged=vlan-bridge,bonding1,ether6,ether5 vlan-ids=30
add bridge=vlan-bridge tagged=vlan-bridge vlan-ids=99
add bridge=vlan-bridge tagged=vlan-bridge,bonding1 vlan-ids=11
add bridge=vlan-bridge tagged=vlan-bridge,ether4,bonding1 vlan-ids=12
/interface list member
add interface=ether1 list=WAN
/interface ovpn-server server
add mac-address=FE:E9:55:2E:1C:BB name=ovpn-server1
/interface wifi capsman
set enabled=yes interfaces=vlan-bridge package-path="" \  
    require-peer-certificate=no upgrade-policy=none
/interface wifi provisioning
add action=create-dynamic-enabled master-configuration=xGHz-privat \
    slave-configurations=xGHz-gast supported-bands=5ghz-ax
add action=create-dynamic-enabled master-configuration=xGHz-privat \
    slave-configurations=xGHz-gast supported-bands=2ghz-ax
/ip address
add address=192.168.41.254/24 interface=ether1 network=192.168.41.0
add address=192.168.1.1/24 interface=vlan1 network=192.168.1.0
add address=192.168.10.1/24 interface=vlan10 network=192.168.10.0
add address=192.168.20.1/24 interface=vlan20 network=192.168.20.0
add address=192.168.30.1/24 interface=vlan30 network=192.168.30.0
add address=192.168.11.1/24 interface=vlan11 network=192.168.11.0
add address=192.168.12.1/24 interface=vlan12 network=192.168.12.0
/ip ipsec profile
set [ find default=yes ] dpd-interval=2m dpd-maximum-failures=5
/ip route
add disabled=no distance=1 dst-address=0.0.0.0/0 gateway=192.168.41.1 \
    routing-table=main scope=30 suppress-hw-offload=no
/ip service
set telnet disabled=yes
set ftp disabled=yes
set api disabled=yes
/system clock
set time-zone-name=Europe/Berlin
/system identity
set name=cAP_Controller
/system logging
add disabled=yes topics=dhcp
/system note
set show-at-login=no
/system ntp client
set enabled=yes
/system ntp client servers
add address=de.pool.ntp.org
/tool sniffer
set filter-interface=ether3 filter-ip-protocol=udp,icmp streaming-enabled=yes \
    streaming-server=192.168.1.200

Hat jemand einen Tipp, was mir hier fehlt?

Vielen Dank
Max
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilen

Content-ID: 672053

Url: https://administrator.de/forum/cap-ax-bekommt-keine-verbindung-zum-capsman-672053.html

Ausgedruckt am: 26.04.2025 um 05:04 Uhr

BiberMan
Lösung BiberMan 19.03.2025 aktualisiert um 20:30:09 Uhr
Goto Top
Grober Fehler hier
/interface wifi capsman
set enabled=yes interfaces=vlan-bridge
Hier gehört das vlan1 Interface rein was bei dir das MGMT zu sein scheint, die Bridge selbst nimmt nicht am IP-Traffic teil, somit sieht der CAP auch den CAPsMAN nicht weil er auf dem falschen Interface lauscht!

Der Port zum CAP sollte in der Bridge des CAPsMAN auch die PVID 1 haben.

Firewallregeln befreit,
Traffic vom CAP musst du aber schon zulassen!
da ich im Log nichts auffälliges dahin gehend sehe
Das LOG zeigt per Default keine Blocks der Firewall an, nur wenn du das das selbst auch aktivierst!
maximalz
maximalz 19.03.2025 um 20:40:21 Uhr
Goto Top
Erst mal vielen Dank, das war wohl der Fehler.

Das LOG zeigt per Default keine Blocks der Firewall an, nur wenn du das das selbst auch aktivierst!
Ja, das stimmt, die Regeln sind allerdings drin (nur leider nicht exportiert)
1
2
add action=drop chain=input comment="general drop input" log=yes log-prefix=IN-DROP  
add action=drop chain=forward comment="general drop forward" log=yes log-prefix=FW-DROP  

Traffic vom CAP musst du aber schon zulassen!
Aber nicht explizit oder? Das passiert doch über die Regeln, die ich für die jeweiligen VLANs festgelegt habe. Der Traffic vom CAP kommt doch schon im jeweils passenden VLAN.

Hier gehört das vlan1 rein
Da habe ich wohl das Beispiel von der MikroTik-Seite nicht richtig verstanden. Dort wird ja auch die Bridge als Capsman Interface definiert. Das würde ich gerne verstehen oder ist die Anleitung von MT falsch?
commodity
commodity 19.03.2025 um 23:18:35 Uhr
Goto Top
Entscheidend ist, dass Du eine Verbindung zwischen CAP und CAPsMAN hast. Dazu braucht es in der CAPsMAN-Einstellung ein Interface, auf dem eine Adresse anliegt.

Mikrotik hat im Beispiel der Bridge br eine Adresse gegeben:

1
2
3
4
/ip address
add address=192.168.1.1/24 interface=br network=192.168.1.0
add address=192.168.10.1/24 interface=MAIN network=192.168.10.0
add address=192.168.20.1/24 interface=GUEST network=192.168.20.0

und folglich dann auch die Bridge br als Interface im CAPsMAN eintragen können.

Du hingegen hast der Bridge selbst keine Adresse gegeben,
1
2
3
4
5
6
7
8
/ip address
add address=192.168.41.254/24 interface=ether1 network=192.168.41.0
add address=192.168.1.1/24 interface=vlan1 network=192.168.1.0
add address=192.168.10.1/24 interface=vlan10 network=192.168.10.0
add address=192.168.20.1/24 interface=vlan20 network=192.168.20.0
add address=192.168.30.1/24 interface=vlan30 network=192.168.30.0
add address=192.168.11.1/24 interface=vlan11 network=192.168.11.0
add address=192.168.12.1/24 interface=vlan12 network=192.168.12.0

die Bridge, die Du im CAPsMAN eingetragen hattest, konnte damit gar nicht kommunizieren.
Es hätte also auch geklappt, wenn Du, statt des VLAN1 im CAPsMAN die Bridge gelassen hättest und dieser eine Adresse gegeben.

Ob das so hübsch und logisch ist, mag dahinstehen. Die Leute bei Mikrotik wissen im allgemeinen, was sie tun. Ich gehe aber auch den Weg von @BiberMan, ein selbständiges VLAN für das Verwaltungsnetz anzulegen, weil ich das übersichtlicher finde.

Viele Grüße, commodity
BiberMan
BiberMan 19.03.2025 aktualisiert um 23:28:46 Uhr
Goto Top
Zitat von @maximalz:
Aber nicht explizit oder? Das passiert doch über die Regeln, die ich für die jeweiligen VLANs festgelegt habe. Der Traffic vom CAP kommt doch schon im jeweils passenden VLAN.
Die Regeln kennen wir ja eben nicht deswegen der Hinweis 🤪.
Hier gehört das vlan1 rein
Da habe ich wohl das Beispiel von der MikroTik-Seite nicht richtig verstanden. Dort wird ja auch die Bridge als Capsman Interface definiert. Das würde ich gerne verstehen oder ist die Anleitung von MT falsch?
Die nutzen da halt die Bridge selbst als MGMT-Interface und kein separates VLAN Interface, du aber schon, das ist der Unterschied.

Im Mikrotik Beispiel ist die IP nämlich auf der Bridge selbst gesetzt
/ip address
add address=192.168.1.1/24 interface=br
network=192.168.1.0
Deswegen läuft dort auch der CapsMan auf der Bridge.

Kann man so auch machen, ist aber eher bad practice ,wenn mal was in der Bridge schief läuft und der MGMT Traffic in andere VLANs leaked.

Die Bridge selbst sollte best Practice besser nie über eine eigene IP verfügen.
BiberMan
BiberMan 19.03.2025 aktualisiert um 23:36:07 Uhr
Goto Top
Zitat von @commodity:

Entscheidend ist, dass Du eine Verbindung zwischen CAP und CAPsMAN hast. Dazu braucht es in der CAPsMAN-Einstellung ein Interface, auf dem eine Adresse anliegt.
Nicht zwingend, der CAPsMAN läuft sogar präferiert über Layer-2 (MAC) wenn CAP und CAPsMAN direkt via Layer-2 gekoppelt sind und man auf dem CAP per Default nur das Interface und keine IP für den CAPsMAN hinterlegt hat.

Bei ihm kam der untagged Traffic nicht an weil er das Default vlan1 auf der Bridge getagged hat und somit die Bridge selbst nichts vom untagged Traffic mitbekommen hat.
aqui
aqui 19.03.2025 um 23:43:03 Uhr
Goto Top
Das würde ich gerne verstehen oder ist die Anleitung von MT falsch?
Vielleicht nochmal ein Blick ins MT VLAN Tutorial werfen, dort ist das umfassend erklärt. face-wink
Mikrotik VLAN Konfiguration ab RouterOS Version 6.41
commodity
commodity 20.03.2025 aktualisiert um 00:25:59 Uhr
Goto Top
Nicht zwingend
ah, ok. Da habe ich dunkel was im Hinterkopf face-smile
Grad mal nachgestellt: Wenn ich dem CAPsMAN-Interface die IP-Adresse wegnehme, kommt dennoch eine Verbindung zum CAP zustande. Muss also Layer2 sein.

weil er das Default vlan1 auf der Bridge getagged hat
Das kann ich noch nicht ganz nachvollziehen: Wenn Du das VLAN1 auf der Bridge taggst (wie alle VLANs, die geroutet werden sollen), bekommt die Bridge doch auch den untagged-Traffic, der über PVID1-Ports reinkommt zu sehen.
Oder liegt das daran, dass gerade die Verbindung auf Layer2 durch die Konfiguration des TO nicht mehr bestand?

Viele Grüße, commodity
BiberMan
BiberMan 20.03.2025 aktualisiert um 08:13:12 Uhr
Goto Top
Zitat von @commodity:
weil er das Default vlan1 auf der Bridge getagged hat
Das kann ich noch nicht ganz nachvollziehen: Wenn Du das VLAN1 auf der Bridge taggst (wie alle VLANs, die geroutet werden sollen), bekommt die Bridge doch auch den untagged-Traffic, der über PVID1-Ports reinkommt zu sehen.
Oder liegt das daran, dass gerade die Verbindung auf Layer2 durch die Konfiguration des TO nicht mehr bestand?

Viele Grüße, commodity
Der Traffic kommt untagged auf dem eth Interface rein und wird mit der PVID dem vlan1 zugeordnet, korrekt. Da aber auf der Bridge das VLAN-Filtering aktiv ist und das vlan1 unter bridge->vlan getagged wurde sieht das Bridge-Interface selbst diesen Traffic nicht mehr sondern nur noch das Vlan Interface, that's the reason.
Durch das tagging unter bridge->vlan auf das Bridge-Interface, geht das Paket auch tagged zur CPU und somit nur zum Interface mit diesem Tag). Hätte er vlan1 so wie es normalerweise ist, untagged auf der Bridge gelassen, hätte seine Config mit dem CapsMan auf dem Bridge Interface auch funktioniert, nur das er dann eben keine IP auf den CAPs gehabt hätte, da diese ja auf dem vlan Interface statt auf die Bridge gebunden sind.

Man kann das auch zusätzlich noch steuern/einschränken indem man auf dem Bridge-Interface selbst nur tagged oder auch untagged Traffic zulässt. Stellt man in
der Bridge den Frame-Type bspw. auf "admit-only-vlan-tagged" dann nimmt sie auch nur noch tagged Traffic entgegen. Würde man dann bei dieser Einstellung das vlan1 auf dem Bridge Interface nicht mehr taggen, sähe auch die Bridge nichts mehr vom untagged Traffic.
aqui
aqui 20.03.2025 aktualisiert um 09:20:15 Uhr
Goto Top
Muss also Layer2 sein.
Nicht muss sondern "kann auch..." face-wink
Das ist ein ähnlicher Mechanismus wie die Autodetection (Neighbor Discovery) z.B. der MTs untereinander und auch Winbox. Basiert auf Broadcasts...
Hätte er vlan1 so wie es normalerweise ist, untagged auf der Bridge gelassen, hätte seine Config mit dem CapsMan auf dem Bridge Interface auch funktioniert
Richtig! 👍
Ein Punkt der leider sehr oft nicht bedacht wird weil das PVID VLAN falsch behandelt wird wie leider auch oben. face-sad
commodity
commodity 20.03.2025 um 12:56:52 Uhr
Goto Top
Zitat von @aqui:
Hätte er vlan1 so wie es normalerweise ist, untagged auf der Bridge gelassen, hätte seine Config mit dem CapsMan auf dem Bridge Interface auch funktioniert
Richtig! 👍
Ein Punkt der leider sehr oft nicht bedacht wird weil das PVID VLAN falsch behandelt wird wie leider auch oben. face-sad

Jetzt bin ich verwirrt:
Im VLAN-Tutorial steht doch ausdrücklich:
Die Bridge selber unter Tagged auch immer als tagged Interface definieren !
und dort wird sie in den Beispielen auch für VLAN1 getaggt. Die Bridge muss doch immer tagged member der VLANs sein, wenn Routing zwischen den VLANs erfolgen soll und das ist doch der Regelfall bei einem Router face-smile

Viele Grüße, commodity
BiberMan
BiberMan 20.03.2025 aktualisiert um 13:52:35 Uhr
Goto Top
Zitat von @commodity:
Jetzt bin ich verwirrt:
Im VLAN-Tutorial steht doch ausdrücklich:
Die Bridge selber unter Tagged auch immer als tagged Interface definieren !
und dort wird sie in den Beispielen auch für VLAN1 getaggt. Die Bridge muss doch immer tagged member der VLANs sein, wenn Routing zwischen den VLANs erfolgen soll und das ist doch der Regelfall bei einem Router face-smile

Viele Grüße, commodity

Es gehen beide Varianten keine ist falsch beide funktionieren einwandfrei. Best practice ist es aber auf dem Bridge Interface selbst keine IP zu binden für den Fall das es in der Bridge mal zu einem Fehler kommt wird nicht gleich das MGMT geleaked.

Also entweder vlan1 in der Bridge taggen und ein vlan1 Interface anlegen und die IP auf das vlan Interface binden , oder den untagged Traffic auf die Bridge laufen lassen und die IP auf das Bridge-Interface setzen (geht auch problemlos sollte man aber best Practice vermeiden)

Soll der Router also selbst ein IP Binding bekommen muss die Bridge selbst immer getagt werden, denn nur über sie erhält man Zugang zur CPU des Routers. Leitet der Router nur die VLANs in der Bridge durch (kein Routing), braucht man die Bridge auch nicht taggen.
Übrigens legt der Mikrotik inzwischen das Tagging für die Bridge dynamisch von selbst an sofern man ein VLAN-Interface in der Bridge anlegt.

Wenn man mal unter Linux mit einer modernen VLAN-Filtering Bridge gearbeitet hat, versteht man das Prinzip auch besser, kann ich nur empfehlen, denn das Mikrotik Schema basiert 1:1 darauf.
commodity
commodity 20.03.2025 um 14:24:48 Uhr
Goto Top
genau so habe ich das auch bisher verstanden. Mich hatte nur dieser Satz verwirrt:
Hätte er vlan1 so wie es normalerweise ist, untagged auf der Bridge gelassen

"so wie es normalerweise ist" gilt also nur für die nicht-Routing-Fälle. Habe ich es jetzt?
Routet man denn VLAN1 gar nicht?

Viele Grüße, commodity
BiberMan
BiberMan 20.03.2025 aktualisiert um 14:49:24 Uhr
Goto Top
Zitat von @commodity:

genau so habe ich das auch bisher verstanden. Mich hatte nur dieser Satz verwirrt:
Hätte er vlan1 so wie es normalerweise ist, untagged auf der Bridge gelassen

"so wie es normalerweise ist" gilt also nur für die nicht-Routing-Fälle. Habe ich es jetzt?
Routet man denn VLAN1 gar nicht?

Viele Grüße, commodity
Das hat mit dem Routing erst mal m nichts zu tun. Per Default liegt das vlan mit der ID 1 auf dem Bridge-Interface selbst durch die PVID des Bridge-Interfaces untagged an, also alles was an den Interfaces untagged ankommt würde dann auch auf dem Bridge-Interface ankommen, sofern die PVID an dem Port auf 1 steht. Tagged man dagegen das vlan1 auf der Bridge, geht dieser Traffic nur noch an Interfaces mit der vlan ID 1.

Man kann natürlich das VLAN 1 auf einem Link nach extern auch tagged übertragen, keine Frage, üblich ist es aber nicht. Das bleibt einem aber persönlich überlassen wie man dies bei sich zu Hause handhabt. Man muss in solchen Fällen halt dran denken das man an anderen Geräten die an diesem Port hängen auch das VLAN1 als tagged konfigurieren kann.
commodity
commodity 20.03.2025 um 15:37:50 Uhr
Goto Top
Also ich sehe immer noch nicht, was der TO da abnormes gemacht haben soll.
Wir sprechen über

1
2
/interface bridge vlan
add bridge=vlan-bridge tagged=vlan-bridge vlan-ids=1
richtig?

Das entspricht IMO exakt der Darstellung im VLAN-Tutorial und auch den Erläuterungen bei MT. Nach meinem Verständnis muss das VLAN auf der Bridge getaggt werden, wenn man es routen möchte. Das hat IMO nichts mit dem Link zu tun, auf dem das VLAN1 übertragen wird, denn der hierfür eingesetzte Port bekommt ja die PVID1 und überträgt es damit untagged.

Hier ein Beispiel eines Gerätes von mir:
Auch hier ist das VLAN1 auf der Bridge getaggt. Dennoch wird es über sfpplus untagged übertragen.

1
2
3
4
5
6
7
8
9
10
#   BRIDGE  VLAN-IDS  CURRENT-TAGGED  CURRENT-UNTAGGED
0   bridge        20  bridge                          
                      sfp-sfpplus1                    
1   bridge         1  bridge                          
2   bridge        30  bridge                          
                      sfp-sfpplus1                    
... 
;;; added by pvid
9 D bridge         1                  ether1          
                                      sfp-sfpplus1    

Wenn aber normalerweise das VLAN1 untagged auf der Bridge liegen soll, wie muss das dann (korrekt) aussehen?

Viele Grüße, commodity
BiberMan
BiberMan 20.03.2025 aktualisiert um 18:13:45 Uhr
Goto Top
Zitat von @commodity:

Also ich sehe immer noch nicht, was der TO da abnormes gemacht haben soll.
Habe ich nie behauptet und hat er ja auch nicht ... Er hat ausschließlich das falsche Interface in den den CAPsMAN-Settings ausgewählt, nicht mehr nicht weniger face-smile.

Wir sprechen über

1
2
/interface bridge vlan
add bridge=vlan-bridge tagged=vlan-bridge vlan-ids=1
richtig?
Korrekt
Das entspricht IMO exakt der Darstellung im VLAN-Tutorial und auch den Erläuterungen bei MT.
Die Mikrotik Anleitung die er oben genommen hat macht es anders als hier ausschließlcih über die Bridge nicht über ein separates MGMT VLAN-Interface.

Nach meinem Verständnis muss das VLAN auf der Bridge getaggt werden, wenn man es routen möchte.
Es muss auf dem Bridge-Interface getagged werden wenn der Router selbst mit einem seiner vorher angelegten VLAN-Interfaces mitspielen will, z.B. als DHCP-Server etc. pp. Dazu muss er aber nicht zwingend auch "routen".

Wenn aber normalerweise das VLAN1 untagged auf der Bridge liegen soll, wie muss das dann (korrekt) aussehen?
So wie in der oben verlinkten Seite von Mikrotik
https://help.mikrotik.com/docs/spaces/ROS/pages/224559120/WiFi#WiFi-CAPs ...
Alles bleibt Default, die PVID der Bridge bleibt auf 1, frametypes auf "admit all", IP Adresse auf das Bridge-Interface legen, fertig.
Ich würde aber wie gesagt die Variante des TO vorziehen, also epxlizites VLAN-Interface anlegen und auf die Bridge taggen, Gründe habe ich oben nun schon mehrfach genannt.
aqui
aqui 20.03.2025 um 19:16:39 Uhr
Goto Top
Best practice ist es aber auf dem Bridge Interface selbst keine IP zu binden
Das steht auch genau so im Tutorial. Extra in rot! face-wink
Also entweder vlan1 in der Bridge taggen und ein vlan1 Interface anlegen und die IP auf das vlan Interface binden
Sollte man m.E. so auch immer bevorzugen weil das 1er bei anderen angeschlossenen Komponenten immer Default ist. CAP Aps ziehen sich damit untagged ja auch eine (Management) IP.
IP auf dem Bridge Interface sollte immer Tabu sein.
Das Problem ist hier oft das Admins vergessen das VLAN 1 explizit anzulegen und zwar BEVOR man das VLAN Filtering aktiviert. Ist das aktiv kann man es nicht mehr einrichten.
Viele denken es ist schon da weil Default aber es ist dann alles ausgegraut von den Settings und nicht mehr konfigurierbar. Deshalb muss es, wie schon richtig oben gesagt, immer explizit angelegt werden um es managen zu können.
Der Fehler des TOs ist aber in der Tat das falsche CapsMan PVID Interface und sehr wahrscheinlich nicht das Setup der Bridge.
Es muss auf dem Bridge-Interface getagged werden wenn der Router selbst mit einem seiner vorher angelegten VLAN-Interfaces mitspielen will, z.B. als DHCP-Server etc. pp.
Absolut richtig! 👍
commodity
commodity 20.03.2025 um 21:50:20 Uhr
Goto Top
Danke @BiberMan für die geduldige Erläuterung.

Also alles im Lot:
Ich hatte das hier
Hätte er vlan1 so wie es normalerweise ist, untagged auf der Bridge gelassen,
halt so verstanden, als ob das jetzt die angesagte Practice wäre. Ist es aber nicht, mit normalerweise meintest Du wahrscheinlich die Beschreibung im Beispiel bei MT.
Best Practice ist es hingegen (wie offenbar wir alle hier es machen face-big-smile), ein explizites VLAN-Interface anzulegen.

Das steht auch genau so im Tutorial. Extra in rot! face-wink
Genau. Ich habe ja auf Dein Tutorial Bezug genommen, das ebenfalls den Weg über das Tagging des VLAN1 geht.
Hier bestand aber ein Widerspruch zu den obigen Äußerungen von @BiberMan
... vlan1 so wie es normalerweise ist, untagged auf der Bridge gelassen
und einer im oberen Post erfolgten Aussage zum Link auf dem das VLAN1 übertragen wird, die aber inzwischen verschwunden ist face-smile

Also alles klar, was best practice ist und warum (auch sehr gut erklärt)

Viele Grüße, commodity
aqui
aqui 21.03.2025 um 07:44:09 Uhr
Goto Top
Best Practice ist es hingegen (wie offenbar wir alle hier es machen face-big-smile), ein explizites VLAN-Interface anzulegen.
Jein.
Das kommt bei Router OS immer drauf an ob man das VLAN routen will oder nicht oder in dem VLAN einen IP Zugang benötigt.
Wenn du kein IP Zugang bzw. Routing in dem VLAN benötigst brauch man auch das Interface nicht.
Beispiel ist z.B. einen Switch mit Router OS den man nur als reinen Layer 2 Switch einrichtet. Dort ist lediglich ein VLAN Interface im Management VLAN nötig. Alle anderen VLANs fackelt man rein in der Bridge ab ohne Interface.
commodity
commodity 23.03.2025 um 22:49:07 Uhr
Goto Top
Ja, das ist klar. Hier
Best Practice ist es hingegen (wie offenbar wir alle hier es machen face-big-smile), ein explizites VLAN-Interface anzulegen.
ging es aber um VLAN1. Gehe ich fehl in der Annahme, dass man dafür IP-Zugang braucht und dieses Netz im Regelfall auch geroutet wird?

Viele Grüße, commodity
BiberMan
BiberMan 24.03.2025 aktualisiert um 08:58:29 Uhr
Goto Top
Zitat von @commodity:

Ja, das ist klar. Hier
Best Practice ist es hingegen (wie offenbar wir alle hier es machen face-big-smile), ein explizites VLAN-Interface anzulegen.
ging es aber um VLAN1. Gehe ich fehl in der Annahme, dass man dafür IP-Zugang braucht und dieses Netz im Regelfall auch geroutet wird?
Für das MGMT von Mikrotik Devices braucht es ja erst mal nicht zwingend eine IP, die lassen sich ja bekanntlich auch über Layer-2 managen.
Ob die Firewall dann eine Weiterleitung aus VLAN1 heraus in andere Netze zulässt ist dann eine Frage der eigenen Organisation, für Firmware-Updates der Geräte aus dem Internet bspw. nützlich aber nicht zwingend. Anders herum ist es ja die Regel das man das vlan1, sofern es das MGMT Netz ist, vor Zugriff aus anderen Netzen abriegelt.
Gezwungen das vlan mit ID 1 überhaupt zu nutzen wird niemand, das kann man auch so ungenutzt liegen lassen ohne es überhaupt zu nutzen.
commodity
commodity 27.03.2025 um 11:22:49 Uhr
Goto Top
Danke @BiberMan, wieder vorzüglich erklärt.
Viele Grüße, commodity