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.
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?)
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”)?
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).
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):
/interface bridge port add bridge=bridge frame-types=admit-only-untagged-and-priority-tagged interface=wifi1 pvid=32
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):
/interface bridge port add bridge=bridge frame-types=admit-only-vlan-tagged interface=ether5
“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?
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.
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 ???
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.
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.
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).
