I'm a little confused (still). I'm trying to keep it simple and practicle (so please try to accomodate this need).
A)
"/interface bridge port" defines vlan frame ingress behavior. Specifically in the example below, any frames arriving on port "wifi1" will have vlan-id=32 tags added to them.
EXAMPLE:
/interface bridge port
add bridge=bridge frame-types=admit-only-untagged-and-priority-tagged interface=wifi1 pvid=32
B)
"/interface bridge vlan" defines vlan frame egress behavior. Specifically in the example below, frames with vlan-id=32 tags will leave on ports "bridge" and "ether1" with their vlan-id tags in place AND frames will leave port "wifi1" and will have their vlan-id=32 tags stripped.
EXAMPLE:
/interface bridge vlan
add bridge=bridge tagged=bridge,ether1 untagged=wifi1 vlan-ids=32
Is my understanding correct?
Thanks.
Basic VLAN config question (again)
Last edited by Josephny on Sat Apr 05, 2025 3:14 pm, edited 1 time in total.
Re: Basic VLAN config question (again)
Is my understanding correct?
Yes.
Of course you need corresponding config for ether1 under bridge/port and appropriate config of bridge port (but that's not subject of this topic, right?)
Re: Basic VLAN config question (again)
Thank you.Is my understanding correct?
Yes.
Of course you need corresponding config for ether1 under bridge/port and appropriate config of bridge port (but that's not subject of this topic, right?)
Corresponding config for ether1?
Something specifically related to vlans?
That is, something more than just creating the bridge ("/interface bridge add name=bridge") and adding ether1 to that bridge ("/interface bridge port add bridge=bridge interface=ether1")?
Re: Basic VLAN config question (again)
Basically that's it for ether1, it would work.
But using VLANs is also about segregation of traffic belonging to different VLANs and enforcing that connected devices stick to their designated VLANs. The big problem is ingress, egress is configured on bridge and connected devices can't do much about it. There are a few settings on bridge/port dealing with that:
If you don't properly set the first property, then rogue user, connected to such port, could inject improper frames (e.g. untagged through trunk port).
If you don't enable the second property, then rogue user, connected to such port, could inject frames targeting "alien VLAN" and mess with devices in that VLAN even though the port is not member of that VLAN.
If these two properties are not set to the most restrictive values, then rogue device wouldn't be able to make bi-directional communication with devices in "alien" VLANs ... but it could inject potentially disruptive packets (similarly to IP firewall which would drop only packets in one direction).
But using VLANs is also about segregation of traffic belonging to different VLANs and enforcing that connected devices stick to their designated VLANs. The big problem is ingress, egress is configured on bridge and connected devices can't do much about it. There are a few settings on bridge/port dealing with that:
- frame-types ... either admit-all (default), admit-only-vlan-tagged or admit-only-untagged-and-priority-tagged
On access port you want to set the later setting. Which will block all tagged frames on ingress.
On trunk ports you want to set admit-only-vlan-tagged. It will block all untagged frames on ingress ... which also makes pvid setting irrelevant.
On hybrid ports (multiple tagged VLANs and single untagged VLAN) you have to leave it set to admit-all. - ingress-filtering ... either no (default) or yes
When enabled, port will actually look at VLAN ID of ingressing frame and will dtop frames where VID is not one of port's VLANs (as configured under bridge/vlan).
If you don't properly set the first property, then rogue user, connected to such port, could inject improper frames (e.g. untagged through trunk port).
If you don't enable the second property, then rogue user, connected to such port, could inject frames targeting "alien VLAN" and mess with devices in that VLAN even though the port is not member of that VLAN.
If these two properties are not set to the most restrictive values, then rogue device wouldn't be able to make bi-directional communication with devices in "alien" VLANs ... but it could inject potentially disruptive packets (similarly to IP firewall which would drop only packets in one direction).
Re: Basic VLAN config question (again)
That is a clear and useful explanation, spanning both the theoretical and practical aspects of vlan config. Thank you.
This is an access port (i.e., physical connections to non-vlan-aware devices):
This is a trunk port (i.e., physical connection to another device's trunk port, such as when ether5 on this device is connected to a port on a switch configured similarly; implied is that it is carrying all vlan-ids):
Correct?
This is an access port (i.e., physical connections to non-vlan-aware devices):
Code: Select all
/interface bridge port add bridge=bridge frame-types=admit-only-untagged-and-priority-tagged interface=wifi1 pvid=32This is a trunk port (i.e., physical connection to another device's trunk port, such as when ether5 on this device is connected to a port on a switch configured similarly; implied is that it is carrying all vlan-ids):
Code: Select all
/interface bridge port add bridge=bridge frame-types=admit-only-vlan-tagged interface=ether5Re: Basic VLAN config question (again)
Yes. Just add the ingress-filtering=yes and you're golden.
Re: Basic VLAN config question (again)
That's really great -- and very much appreciated.Yes. Just add the ingress-filtering=yes and you're golden.
You wrote above that ingress-filtering is NO by default.
I just added a port to a bridge, both by CLI and by Winbox, and in both cases ingress-filtering=yes was the default.
What am I missing?
Re: Basic VLAN config question (again)
Also, you wrote above:
"When ingresss-filtering=YES, port will actually look at VLAN ID of ingressing frame and will drop frames where VID is not one of port's VLANs (as configured under bridge/vlan)."
What parameter exactly in the bridge/vlan config is checked to see if a frame can ingress?
For example:
[code}add bridge=bridge tagged=bridge,sfp-sfpplus1,ether4,ether5 untagged=ether6,ether7 vlan-ids=32[/code]
Is it the bridge in bridge=bridge, any of the tagged ports, an untagged port?
"When ingresss-filtering=YES, port will actually look at VLAN ID of ingressing frame and will drop frames where VID is not one of port's VLANs (as configured under bridge/vlan)."
What parameter exactly in the bridge/vlan config is checked to see if a frame can ingress?
For example:
[code}add bridge=bridge tagged=bridge,sfp-sfpplus1,ether4,ether5 untagged=ether6,ether7 vlan-ids=32[/code]
Is it the bridge in bridge=bridge, any of the tagged ports, an untagged port?
Re: Basic VLAN config question (again)
Somewhere along the line MT must have changed the default to YES, hard on us ole-timers LOL
Re: Basic VLAN config question (again)
It will check if ingress port is member of VLAN that ingressing frame belongs to."When ingresss-filtering=YES, port will actually look at VLAN ID of ingressing frame and will drop frames where VID is not one of port's VLANs (as configured under bridge/vlan)."
What parameter exactly in the bridge/vlan config is checked to see if a frame can ingress?
As per your example: on ether1 if ingressing frame is tagged with VID=32, then it'll be accepted. If, OTOH, ingressing frame is tagged with e.g. VID=666, then it will be dropped (because ether1 is not set as member of vlan 666).
In reality, a trunk port will be mentioned in several bridge/vlan configuration lines, hence multiple VIDs will be allowed on ingress of such port.
Re: Basic VLAN config question (again)
Why would a frame tagged with VID=32 ingressing to ether1 be accepted?It will check if ingress port is member of VLAN that ingressing frame belongs to."When ingresss-filtering=YES, port will actually look at VLAN ID of ingressing frame and will drop frames where VID is not one of port's VLANs (as configured under bridge/vlan)."
What parameter exactly in the bridge/vlan config is checked to see if a frame can ingress?
As per your example: on ether1 if ingressing frame is tagged with VID=32, then it'll be accepted. If, OTOH, ingressing frame is tagged with e.g. VID=666, then it will be dropped (because ether1 is not set as member of vlan 666).
In reality, a trunk port will be mentioned in several bridge/vlan configuration lines, hence multiple VIDs will be allowed on ingress of such port.
Do you mean any of these ports: bridge,sfp-sfpplus1,ether4,ether5?
Does this mean that a frame tagged with the VID identified as one of the tagged ports on the vlan table means it will be accepted?
Re: Basic VLAN config question (again)
What??Why would a frame tagged with VID=32 ingressing to ether1 be accepted?
Well the physical port ether1 is a trunk port carrying multiple vlans to the local device.
Why would you not think that vlan32 should be allowed to ingress in ether1??
A. its on the trunk port leaving the upstream device.
B. its noted as a tagged vlan id on ether1 in /interface bridge vlan settings.
If there was also a port on the device untagged for vlan32, lets say connected to a PC, how do you think the PC gets an IP address and traffic out to the ethernet by willpower ???
Re: Basic VLAN config question (again)
Why would a frame tagged with VID=32 ingressing to ether1 be accepted?
It will check if ingress port is member of VLAN that ingressing frame belongs to.
As per your example: on ether1 if ingressing frame is tagged with VID=32, then it'll be accepted. If, OTOH, ingressing frame is tagged with e.g. VID=666, then it will be dropped (because ether1 is not set as member of vlan 666).
In reality, a trunk port will be mentioned in several bridge/vlan configuration lines, hence multiple VIDs will be allowed on ingress of such port.
Do you mean any of these ports: bridge,sfp-sfpplus1,ether4,ether5?
Right, you're awake
Yes, I should have used ether4 in my naration, not ether1. As an excuse: you did talk about ether1 in your initial post ... I didn't see you move in another forrest.
Re: Basic VLAN config question (again)
Not your concern mkx, its hard to keep straight incomplete questions without context................
Re: Basic VLAN config question (again)
The example we were using was:What??Why would a frame tagged with VID=32 ingressing to ether1 be accepted?
Well the physical port ether1 is a trunk port carrying multiple vlans to the local device.
Why would you not think that vlan32 should be allowed to ingress in ether1??
A. its on the trunk port leaving the upstream device.
B. its noted as a tagged vlan id on ether1 in /interface bridge vlan settings.
If there was also a port on the device untagged for vlan32, lets say connected to a PC, how do you think the PC gets an IP address and traffic out to the ethernet by willpower ???
[code}add bridge=bridge tagged=bridge,sfp-sfpplus1,ether4,ether5 untagged=ether6,ether7 vlan-ids=32[/code]
I think you were referring back to the first post in this thread.
Re: Basic VLAN config question (again)
The example we were using was:
What??
Well the physical port ether1 is a trunk port carrying multiple vlans to the local device.
Why would you not think that vlan32 should be allowed to ingress in ether1??
A. its on the trunk port leaving the upstream device.
B. its noted as a tagged vlan id on ether1 in /interface bridge vlan settings.
If there was also a port on the device untagged for vlan32, lets say connected to a PC, how do you think the PC gets an IP address and traffic out to the ethernet by willpower ???
[code}add bridge=bridge tagged=bridge,sfp-sfpplus1,ether4,ether5 untagged=ether6,ether7 vlan-ids=32[/code]
I think you were referring back to the first post in this thread.
In this case vlan32 travels within the router or switch as tagged between all ports associated with the vlan id, sfp-sfpplus1, ether4,ether5,ether6 and ether7.
Upon traffic exiting the ports, the vlan tags stay on the traffic for sfp-sfpplus1,ether4,ether5 being trunk ports ( or vice versa traffic entering these ports).
Upon traffic physically the device on etherports 6,7 the vlan-ids are stripped off, and when traffic arrives at the port from an external device, the vlan tags are added.
Re: Basic VLAN config question (again)
Great!
The example we were using was:
[code}add bridge=bridge tagged=bridge,sfp-sfpplus1,ether4,ether5 untagged=ether6,ether7 vlan-ids=32[/code]
I think you were referring back to the first post in this thread.
In this case vlan32 travels within the router or switch as tagged between all ports associated with the vlan id, sfp-sfpplus1, ether4,ether5,ether6 and ether7.
Upon traffic exiting the ports, the vlan tags stay on the traffic for sfp-sfpplus1,ether4,ether5 being trunk ports ( or vice versa traffic entering these ports).
Upon traffic physically the device on etherports 6,7 the vlan-ids are stripped off, and when traffic arrives at the port from an external device, the vlan tags are added.
So we can dumb that down even more and say that vlan32 traffic is allowed on all ports references on this config line, whether they are tagged= or untagged= ports.
Re: Basic VLAN config question (again)
So I spent an hour or so last night exercising my vlan configurating skills (which is the equivalent of 1kg (2.2 lbs for people like me) dumbells).
I thought I had it all working and was very excited. The vlan traffic between an RB5009 ether4 and an ax3 (ether1) was flowing beautfully, but I couldn't ping the 5009 (or anything past it on the Internet).
Took me a while but I figured out what I did wrong.
Here's a game: How many seconds will it take you experts to spot my error:
You can respond with either the solution, or the number of seconds -- and then I can provide the solution to prove I really did figure it out myself (after a while).
I thought I had it all working and was very excited. The vlan traffic between an RB5009 ether4 and an ax3 (ether1) was flowing beautfully, but I couldn't ping the 5009 (or anything past it on the Internet).
Took me a while but I figured out what I did wrong.
Here's a game: How many seconds will it take you experts to spot my error:
Code: Select all
/interface bridge
add admin-mac=F4:1E:57:2C:BE:98 auto-mac=no comment=defconf frame-types=\
admit-only-vlan-tagged name=bridge vlan-filtering=yes
/interface vlan
add comment=vlan32 interface=ether1 name=vlan32 vlan-id=32
/interface bridge port
add bridge=bridge comment="vlan32 MGMT" frame-types=\
admit-only-untagged-and-priority-tagged interface=ether2 pvid=32
add bridge=bridge comment="vlan42 TV " frame-types=\
admit-only-untagged-and-priority-tagged interface=ether3 pvid=42
add bridge=bridge comment="vlan62 Server" frame-types=admit-only-vlan-tagged \
interface=ether4 pvid=62
add bridge=bridge comment=defconf interface=wifi1
add bridge=bridge comment=defconf interface=wifi2
add bridge=bridge interface=ether1
add bridge=bridge frame-types=admit-only-untagged-and-priority-tagged \
interface=ax3-vlan-iot pvid=12
add bridge=bridge comment=VLAN2 frame-types=\
admit-only-untagged-and-priority-tagged interface=ax3-2g-vlan pvid=2
add bridge=bridge comment=VLAN2 frame-types=\
admit-only-untagged-and-priority-tagged interface=ax3-5g-vlan pvid=2
/interface bridge vlan
add bridge=bridge tagged=bridge,ether1 vlan-ids=32
You can respond with either the solution, or the number of seconds -- and then I can provide the solution to prove I really did figure it out myself (after a while).
Re: Basic VLAN config question (again)
This one:
It should be interface=bridge ... it took me 0 seconds (recognized it while reading config)./interface vlan
add comment=vlan32 interface=ether1 name=vlan32 vlan-id=32
Re: Basic VLAN config question (again)
We have a winner!This one:
It should be interface=bridge ... it took me 0 seconds (recognized it while reading config)./interface vlan
add comment=vlan32 interface=ether1 name=vlan32 vlan-id=32
Re: Basic VLAN config question (again)
Speed is not all its cracked up to be, taking ones time mostly results in greater satisfaction,..........
Besides there is an error before that..... and many many after LOL
1. /interface bridge
add admin-mac=F4:1E:57:2C:BE:98 auto-mac=no comment=defconf frame-types=\
admit-only-vlan-tagged name=bridge vlan-filtering=yes EDIT: It may actually be reasonable practice to limit CPU to vlan tagged......
2. /ip bridge port
add bridge=bridge comment="vlan62 Server" frame-types=admit-only-vlan-tagged \
interface=ether4 pvid=62
3. /ip bridge port
add bridge=bridge comment=defconf interface=wifi1 -----> frame types PVID??????
add bridge=bridge comment=defconf interface=wifi2 -----> frame types PVID??????
add bridge=bridge interface=ether1 ---> frame types????
4. Horrible nomenclature or plain wrong?, it seems to state to the reader we are untagging frames exiting a vlan vice exiting a port???
Did you actually name a port ax3-vlan-iot or did you think that a vlan is a port???
/ip bridge port
add bridge=bridge frame-types=admit-only-untagged-and-priority-tagged \
interface=ax3-vlan-iot pvid=12
5. Looks like you made the same mistake two more time........
add bridge=bridge comment=VLAN2 frame-types=\
admit-only-untagged-and-priority-tagged interface=ax3-2g-vlan pvid=2
add bridge=bridge comment=VLAN2 frame-types=\
admit-only-untagged-and-priority-tagged interface=ax3-5g-vlan pvid=2
Luckily there is no more config supplied to eviscerate.
Besides there is an error before that..... and many many after LOL
1. /interface bridge
add admin-mac=F4:1E:57:2C:BE:98 auto-mac=no comment=defconf frame-types=\
admit-only-vlan-tagged name=bridge vlan-filtering=yes EDIT: It may actually be reasonable practice to limit CPU to vlan tagged......
2. /ip bridge port
add bridge=bridge comment="vlan62 Server" frame-types=admit-only-vlan-tagged \
interface=ether4 pvid=62
3. /ip bridge port
add bridge=bridge comment=defconf interface=wifi1 -----> frame types PVID??????
add bridge=bridge comment=defconf interface=wifi2 -----> frame types PVID??????
add bridge=bridge interface=ether1 ---> frame types????
4. Horrible nomenclature or plain wrong?, it seems to state to the reader we are untagging frames exiting a vlan vice exiting a port???
Did you actually name a port ax3-vlan-iot or did you think that a vlan is a port???
/ip bridge port
add bridge=bridge frame-types=admit-only-untagged-and-priority-tagged \
interface=ax3-vlan-iot pvid=12
5. Looks like you made the same mistake two more time........
add bridge=bridge comment=VLAN2 frame-types=\
admit-only-untagged-and-priority-tagged interface=ax3-2g-vlan pvid=2
add bridge=bridge comment=VLAN2 frame-types=\
admit-only-untagged-and-priority-tagged interface=ax3-5g-vlan pvid=2
Luckily there is no more config supplied to eviscerate.
Last edited by anav on Wed Apr 09, 2025 1:33 am, edited 3 times in total.
Re: Basic VLAN config question (again)
I don't understand where you are quoting from?Speed is not all its cracked up to be, taking ones time mostly results in greater satisfaction,..........
Besides there is an error before that..... and many many after LOL
1. /interface bridge
add admin-mac=F4:1E:57:2C:BE:98 auto-mac=no comment=defconf frame-types=\
admit-only-vlan-tagged name=bridge vlan-filtering=yes
2. /ip bridge port
add bridge=bridge comment="vlan62 Server" frame-types=admit-only-vlan-tagged \
interface=ether4 pvid=62
3. /ip bridge port
add bridge=bridge comment=defconf interface=wifi1 -----> frame types PVID??????
add bridge=bridge comment=defconf interface=wifi2 -----> frame types PVID??????
add bridge=bridge interface=ether1 ---> frame types????
4. Horrible nomenclature or plain wrong?, it seems to state to the reader we are untagging frames exiting a vlan vice exiting a port???
Did you actually name a port ax3-vlan-iot or did you think that a vlan is a port???
/ip bridge port
add bridge=bridge frame-types=admit-only-untagged-and-priority-tagged \
interface=ax3-vlan-iot pvid=12
5. Looks like you made the same mistake two more time........
add bridge=bridge comment=VLAN2 frame-types=\
admit-only-untagged-and-priority-tagged interface=ax3-2g-vlan pvid=2
add bridge=bridge comment=VLAN2 frame-types=\
admit-only-untagged-and-priority-tagged interface=ax3-5g-vlan pvid=2
Luckily there is no more config supplied to eviscerate.
I had exactly what you wrote in items 1 and 2.
As for 3, I should have identified the PVID as 32 (mgmnt).
But, ether1 I think does not get a pvid because it is the trunk port (and pvid=1 is implied or the unstated).
And, yes, ax3-vlan-iot is an interface name.
Re: Basic VLAN config question (again)
The first error.
1. is quoting from your config in post #18 EDIT: and is USER OPTIONAL ( without frame limitations vlan-id1 is shown as a dynamic entry but not a concern, as well limit frame types on all bridge ports/wlans - I guess either way is acceptable!
2. is quoting from your confing in post #18 and is WRONG. Your contradicting yourself, as plain as day, how can you say its a vlan tagged frames, when you have a PVID????
3. Missing frame types and pvids
4. Then its horrible nomenclature and does nothing but confuse the reader, STATE THE PORT NUMBER and dont mention vlan !!
aka
/ip bridge port
add bridge=bridge frame-types=admit-only-untagged-and-priority-tagged \
interface=ether4-iot pvid=12
When I read that line, I immediately read that as an access port on ether4 associated with vlan12 and a dumb IOT device attached to the port.
Same for the wireless ports!!
add bridge=bridge comment=VLAN2 frame-types=\
admit-only-untagged-and-priority-tagged interface=wifi1-2g-home pvid=2
add bridge=bridge comment=VLAN2 frame-types=\
admit-only-untagged-and-priority-tagged interface=wifi2-5g-home pvid=2
1. is quoting from your config in post #18 EDIT: and is USER OPTIONAL ( without frame limitations vlan-id1 is shown as a dynamic entry but not a concern, as well limit frame types on all bridge ports/wlans - I guess either way is acceptable!
2. is quoting from your confing in post #18 and is WRONG. Your contradicting yourself, as plain as day, how can you say its a vlan tagged frames, when you have a PVID????
3. Missing frame types and pvids
4. Then its horrible nomenclature and does nothing but confuse the reader, STATE THE PORT NUMBER and dont mention vlan !!
aka
/ip bridge port
add bridge=bridge frame-types=admit-only-untagged-and-priority-tagged \
interface=ether4-iot pvid=12
When I read that line, I immediately read that as an access port on ether4 associated with vlan12 and a dumb IOT device attached to the port.
Same for the wireless ports!!
add bridge=bridge comment=VLAN2 frame-types=\
admit-only-untagged-and-priority-tagged interface=wifi1-2g-home pvid=2
add bridge=bridge comment=VLAN2 frame-types=\
admit-only-untagged-and-priority-tagged interface=wifi2-5g-home pvid=2
Last edited by anav on Wed Apr 09, 2025 1:30 am, edited 1 time in total.
Re: Basic VLAN config question (again)
My thinking on the interface name is to have it match the SSID. The reason why I chose ax3-vlan-iot, ax3-2g-vlan, and ax3-5g-vlan is to match the SSIDs of those wifi interfaces so that when I connect to them I can be certain I am connecting to the vlan-enabled wifi networks.The first error.
1. is quoting from your config in post #18 and is WRONG ( do not use the bridge itself to set frames )
2. is quoting from your confing in post #18 and is WRONG. Your contradicting yourself, as plain as day, how can you say its a vlan tagged frames, when you have a PVID????
3. Missing frame types and pvids
4. Then its horrible nomenclature and does nothing but confuse the reader, STATE THE PORT NUMBER and dont mention vlan !!
aka
/ip bridge port
add bridge=bridge frame-types=admit-only-untagged-and-priority-tagged \
interface=ether4-iot pvid=12
When I read that line, I immediately read that as an access port on ether4 associated with vlan12 and a dumb IOT device attached to the port.
Same for the wireless ports!!
add bridge=bridge comment=VLAN2 frame-types=\
admit-only-untagged-and-priority-tagged interface=wifi1-2g-home pvid=2
add bridge=bridge comment=VLAN2 frame-types=\
admit-only-untagged-and-priority-tagged interface=wifi2-5g-home pvid=2
As far as the others, I now see my mistakes -- thank you.
Re: Basic VLAN config question (again)
The first error.
1. is quoting from your config in post #18 and is WRONG ( do not use the bridge itself to set frames )
IMHO if OP has a VLAN-only configuration, with no IP address configured on the interface "bridge", then setting frame-types=admit-only-vlan-tagged is the correct way, and it's also what I usually do on my routers:
Here we configure the frame types parameter for the CPU bridge port. If we keep the default "admit-all" setting and enable VLAN Filtering, current RouterOS versions automatically add a dynamic entry for VLAN 1 in the /interface bridge vlan table, with the CPU port listed under Current Untagged. We have no use for VLAN 1, that dynamic entry is useless.
If we think more about it, on the router, in a VLAN-only configuration, the CPU port only appears in the "tagged ports" list of the VLANs (and only for VLANs that the main CPU needs access to). The CPU port is effectively a trunk port. That's why frame-types=admit-only-vlan-tagged is the perfect and correct setting for it. Doing it so also gets rid of the dynamic entry for VLAN 1 in the /interface bridge vlan table.
You do not have the required permissions to view the files attached to this post.
Re: Basic VLAN config question (again)
Interesting, as long as there is no downside, narrowing down the frame type at the bridge, is then viable would be my conclusion.
Assuming you mean this is valid for both routers and switches CR3 types when using vlan filtering???
Just to be clear this does not interfere with any situations where
a. router - one of the vlans terminates a WAN connection on the router
OR
b. switch - one of the vlans is the management vlan which gives a switch its IP address.
c. we have hybrid ports where we cannot state frame type on a bridge port...........
Assuming you mean this is valid for both routers and switches CR3 types when using vlan filtering???
Just to be clear this does not interfere with any situations where
a. router - one of the vlans terminates a WAN connection on the router
OR
b. switch - one of the vlans is the management vlan which gives a switch its IP address.
c. we have hybrid ports where we cannot state frame type on a bridge port...........
Re: Basic VLAN config question (again)
Yes, it works with all the cases you listed. This frame-types setting on the bridge interface is actually the setting for the "port" persona of bridge, where the bridge is the CPU port, in the same category as ether1, ether2, sfp1, etc... Even the tab in in WinBox has the same options as the tab you have for the entries under /interface bridge port. This CPU port persona is also the one represented when you list "bridge" in the untagged and tagged list of the VLAN entries in the /interface bridge vlan table.
When we look at the /interface bridge vlan table, with the Tagged and Untagged columns visible (not only the Current XXX columns) we can see that for a VLAN-only configuration, this CPU port "bridge" has no reason to be listed in the "Untagged" column at all. It only appears as untagged if we keep the default frame-types admit-all in the dynamic entry that RouterOS added because of that setting. Otherwise for all the other VLANs it's either only part of the tagged list or does not appear at all. The CPU port is a trunk port like I wrote above.
Normally if you configure ether8 as trunk port for a few VLANs, you add ether8 to the tagged list of those VLANs then go back to /interface bridge ports, and change frame-types of ether8 to admit-only-vlan-tagged, right?
Which means logically, the same is to be done for the CPU port, if it's only used as trunk port: You add it to the tagged list of the VLANs entry if required, then change the frame-types of the port to admit-only-vlan-tagged. The only difference is that setting the frame-types of the CPU port is not done in the /interface bridge ports table, but on the property of the bridge interface.
In the "default" configuration, when for example 192.168.88.1/24 is configured on the interface "bridge", for that part "bridge" is like an implicit "vlan1" interface added to /interface vlan, and "bridge" as CPU port is an access port of that VLAN1. That's compatible with the default setting of PVID=1 and frame-types=admit-all of the "bridge" port. And that's also why it's logical that when you turn on VLAN Filtering, RouterOS adds the dynamic entry for VLAN 1 with the "bridge" port untagged (because "bridge" is access port of the invisible "vlan1").
Because we don't want to have addresses or services on the interface bridge, we effectively want to remove that "bridge" as "vlan1" interface, we don't want "bridge" (the CPU port) to be access port of this VLAN anymore. Setting frame-types=admit-only-vlan-tagged make "bridge" the CPU port no longer access port of "vlan1" (or whatever invisible vlan interface that matches the PVID setting). This makes the "bridge" interface (the implicit "vlan1" under /interface vlan) useless and having no member port at all, as intended.
When we look at the /interface bridge vlan table, with the Tagged and Untagged columns visible (not only the Current XXX columns) we can see that for a VLAN-only configuration, this CPU port "bridge" has no reason to be listed in the "Untagged" column at all. It only appears as untagged if we keep the default frame-types admit-all in the dynamic entry that RouterOS added because of that setting. Otherwise for all the other VLANs it's either only part of the tagged list or does not appear at all. The CPU port is a trunk port like I wrote above.
Normally if you configure ether8 as trunk port for a few VLANs, you add ether8 to the tagged list of those VLANs then go back to /interface bridge ports, and change frame-types of ether8 to admit-only-vlan-tagged, right?
Which means logically, the same is to be done for the CPU port, if it's only used as trunk port: You add it to the tagged list of the VLANs entry if required, then change the frame-types of the port to admit-only-vlan-tagged. The only difference is that setting the frame-types of the CPU port is not done in the /interface bridge ports table, but on the property of the bridge interface.
In the "default" configuration, when for example 192.168.88.1/24 is configured on the interface "bridge", for that part "bridge" is like an implicit "vlan1" interface added to /interface vlan, and "bridge" as CPU port is an access port of that VLAN1. That's compatible with the default setting of PVID=1 and frame-types=admit-all of the "bridge" port. And that's also why it's logical that when you turn on VLAN Filtering, RouterOS adds the dynamic entry for VLAN 1 with the "bridge" port untagged (because "bridge" is access port of the invisible "vlan1").
Because we don't want to have addresses or services on the interface bridge, we effectively want to remove that "bridge" as "vlan1" interface, we don't want "bridge" (the CPU port) to be access port of this VLAN anymore. Setting frame-types=admit-only-vlan-tagged make "bridge" the CPU port no longer access port of "vlan1" (or whatever invisible vlan interface that matches the PVID setting). This makes the "bridge" interface (the implicit "vlan1" under /interface vlan) useless and having no member port at all, as intended.
Re: Basic VLAN config question (again)
This is a great approach and a great explanation.The first error.
1. is quoting from your config in post #18 and is WRONG ( do not use the bridge itself to set frames )
IMHO if OP has a VLAN-only configuration, with no IP address configured on the interface "bridge", then setting frame-types=admit-only-vlan-tagged is the correct way, and it's also what I usually do on my routers:
bridge-vlan-frame-types.png
Here we configure the frame types parameter for the CPU bridge port. If we keep the default "admit-all" setting and enable VLAN Filtering, current RouterOS versions automatically add a dynamic entry for VLAN 1 in the /interface bridge vlan table, with the CPU port listed under Current Untagged. We have no use for VLAN 1, that dynamic entry is useless.
If we think more about it, on the router, in a VLAN-only configuration, the CPU port only appears in the "tagged ports" list of the VLANs (and only for VLANs that the main CPU needs access to). The CPU port is effectively a trunk port. That's why frame-types=admit-only-vlan-tagged is the perfect and correct setting for it. Doing it so also gets rid of the dynamic entry for VLAN 1 in the /interface bridge vlan table.
I have made sure that both the 5009 and the ax3 (that now comprise this test lab) have bridge's with vlan's with frame-types=admit-only-vlan-tagged set.
And here is the (hopefully) corrrect ax3 relevant config parts (I don't think my ego can withstand the results of sharing the entire config (;-)):
Code: Select all
/interface bridge
add admin-mac=F4:1E:57:2C:BE:98 auto-mac=no comment=defconf frame-types=admit-only-vlan-tagged name=bridge vlan-filtering=yes
/interface wifi
set [ find default-name=wifi1 ] channel.band=5ghz-ax .skip-dfs-channels=all .width=20/40/80mhz configuration.mode=ap .ssid=ax3-5g-test disabled=no \
security.authentication-types=wpa2-psk .ft=yes .ft-over-ds=yes
set [ find default-name=wifi2 ] channel.band=2ghz-ax .skip-dfs-channels=all .width=20/40mhz configuration.mode=ap .ssid=ax3-2g-test disabled=no \
security.authentication-types=wpa2-psk .ft=yes .ft-over-ds=yes
/interface vlan
add comment=vlan32 interface=bridge name=vlan32 vlan-id=32
/interface wifi
add configuration.mode=ap .ssid=ax3-2g-vlan disabled=no mac-address=F6:1E:57:2C:BE:9D master-interface=wifi2 mtu=1500 name=ax3-2g-vlan security.authentication-types=\
wpa2-psk
add configuration.mode=ap .ssid=ax3-5g-vlan disabled=no mac-address=F6:1E:57:2C:BE:9C master-interface=wifi1 name=ax3-5g-vlan security.authentication-types=wpa2-psk
add configuration.mode=ap .ssid=ax3-vlan-iot disabled=no mac-address=F6:1E:57:2C:BE:9E master-interface=wifi2 name=ax3-vlan-iot security.authentication-types=wpa2-psk
/interface bridge port
add bridge=bridge comment="vlan32 MGMT" frame-types=admit-only-untagged-and-priority-tagged interface=ether2 pvid=32
add bridge=bridge comment="vlan42 TV " frame-types=admit-only-untagged-and-priority-tagged interface=ether3 pvid=42
add bridge=bridge comment="vlan62 Server" frame-types=admit-only-untagged-and-priority-tagged interface=ether4 pvid=62
add bridge=bridge comment=defconf frame-types=admit-only-untagged-and-priority-tagged interface=wifi1 pvid=32
add bridge=bridge comment=defconf frame-types=admit-only-untagged-and-priority-tagged interface=wifi2 pvid=32
add bridge=bridge frame-types=admit-only-vlan-tagged interface=ether1
add bridge=bridge frame-types=admit-only-untagged-and-priority-tagged interface=ax3-vlan-iot pvid=12
add bridge=bridge comment=VLAN2 frame-types=admit-only-untagged-and-priority-tagged interface=ax3-2g-vlan pvid=2
add bridge=bridge comment=VLAN2 frame-types=admit-only-untagged-and-priority-tagged interface=ax3-5g-vlan pvid=2
/interface bridge vlan
add bridge=bridge tagged=bridge,ether1 vlan-ids=32Note 2: The SSID and interface names "ax3-2g-vlan," "ax3-5g-vlan," and "ax3-vlan-io" are only for my experimenting and learning, so that when I connect via wifi I am certain of which network I should be on.
Re: Basic VLAN config question (again)
There is no effing CPU port of a software bridge. There indeed is a CPU port of a hardware switch, but it is not the same thing.
There is the router-facing port of the bridge, which is a virtual object within a software running on the CPU. The router software is not the same thing as the CPU.
There is the router-facing port of the bridge, which is a virtual object within a software running on the CPU. The router software is not the same thing as the CPU.
Re: Basic VLAN config question (again)
I am sorry that I did not use the term that you defined in your article @sindy. My "CPU port" is not the specific term that you only used for the hardware switch. For me the bridge (hardware offload by a switch chip or only software based is not important) has ports, including real physical ports, bonding interfaces, VETH, EoIP, etc... and the port that is normally referenced by the name of the bridge itself, the one that is always handled by "a software running on the CPU" like you wrote, that always goes to the main CPU. That port is what I call the bridge CPU port. It's not a term that you monopolize to only refer to the port on a hardware switch chip. And it's also much shorter than "router-facing port of the bridge".
It's 2025, we here on this forum might despise AI search engines, but we can agree that they should be able to provide an acceptable definition for basic networking terms. Now let's put "in networking, what is a bridge CPU port?" into ChatGPT, Grok, Gemini, Copilot whatever and we can see that they provide the descriptions that match the "bridge" port, and in none of them is "CPU port" a term reserved for "hardware switch chip".
It's 2025, we here on this forum might despise AI search engines, but we can agree that they should be able to provide an acceptable definition for basic networking terms. Now let's put "in networking, what is a bridge CPU port?" into ChatGPT, Grok, Gemini, Copilot whatever and we can see that they provide the descriptions that match the "bridge" port, and in none of them is "CPU port" a term reserved for "hardware switch chip".
Re: Basic VLAN config question (again)
Sorry, the trigger of my reaction was that use of such term leads to misunderstanding of the actual topology. I would be more than happy if someone created a better set of terms to describe the virtual objects in the software than those somehow bulky ones I came up with, but putting an equation between "CPU" and "router" introduces a misconception. The OP was struggling already with just slightly ambiguous terms describing the roles of ports with regard to VLANs, and this "CPU port of a bridge" thing is not just ambiguous, it is straight misleading.
Re: Basic VLAN config question (again)
The last thing I would, should, or could do is get involved the substance of this disagreement.
Nonetheless, as the struggling OP, I can add (due to my unique perspective and standing as a struggler), that we (strugglers) do indeed need a better set of terms, a manner of abstraction, a method of conceptualization -- essentially, a way to understand and communicate about -- these concepts and topics and solutions.
Nonetheless, as the struggling OP, I can add (due to my unique perspective and standing as a struggler), that we (strugglers) do indeed need a better set of terms, a manner of abstraction, a method of conceptualization -- essentially, a way to understand and communicate about -- these concepts and topics and solutions.