Good day, ladies and gentlemen!
We have updated Layer 3 Hardware Offloading User Manual to reflect the latest features, changes, and configuration samples.
Feel free to use and do not hesitate to provide feedback!
Oops, we accidentally posted implemented but yet unreleased features. Well, I guess that now you have an official sneak peek of the upcoming changes.How is there a 7.1beta7 listed if it hasn't been released yet, or are you just keeping it as up-to-date as possible?
Doesn't first line of this example set ether2 as access port for VID 20 and should thus be set as untagged member of VLAN 20 in the second configuration line?/interface/bridge/port add bridge=bridge interface=ether2 pvid=20
/interface/bridge/vlan add bridge=bridge tagged=bridge,ether2 vlan-ids=20
That's a good question. Thank you! Let me explain.IMO there's an error in the "VLAN configuration example":
Doesn't first line of this example set ether2 as access port for VID 20 and should thus be set as untagged member of VLAN 20 in the second configuration line?/interface/bridge/port add bridge=bridge interface=ether2 pvid=20
/interface/bridge/vlan add bridge=bridge tagged=bridge,ether2 vlan-ids=20
Or (according to the idea behind the example) ether2 should rather be set as tagged port with "pvid" setting omitted?
- pvid property of /in/br/port is mandatory. If you omit it, the default pvid=1 is used, meaning the port gets bridged with other ports with VLAN ID 1. We do not want this, so we explicitly set pvid=20.
- Setting port's pvid leads to a dynamic vlan creation where the port is untagged by default. But we need port to be tagged, therefore we explicitly define /in/br/vlan entry for VLAN ID 20.
- Port's pvid is not used for inter-VLAN routing. We offload vlan-id of /interface/vlan entry into the hardware routing table instead. So you are right that pvid could be theoretically omitted, but in reality, pvid is mandatory. So the rule of thumb is to set pvid to the same value as vlan-id. Or one of vlan-ids because multiple VLANs may be routed through a single trunk port.
Not directly related to L3 routing (hence off topic in this thread), but anyway: I always thought that setting port tagged member of VLAN (/in/br/vlan entry for VLAN ID) and setting PVID on bridge port (/in/br/port) makes possible mismatch: if frame-types is not set, then untagged frames are allowed and get tagged on ingress while on egress they are always transmitted tagged? Or did this behaviour change in ROS v7?
I still don't fully understand why PVID setting is mandatory in practice. @raimondsp writes that omitting to set it keeps the default setting of pvid=1 (which we already know very well), but the argument about bridging the port with other ports with pvid=1 seems moot to me if frame-types property is properly set (to admit-only-vlan-tagged) (in which case port won't pass untagged frames on ingress and in practice pvid membership doesn't matter much).
Oops, we accidentally posted implemented but yet unreleased features. Well, I guess that now you have an official sneak peek of the upcoming changes.
RouterOS v7.1beta7: variable MTU / Jumbo frame support.
i agree.
- pvid property of /in/br/port is mandatory. If you omit it, the default pvid=1 is used, meaning the port gets bridged with other ports with VLAN ID 1. We do not want this, so we explicitly set pvid=20.
- Setting port's pvid leads to a dynamic vlan creation where the port is untagged by default. But we need port to be tagged, therefore we explicitly define /in/br/vlan entry for VLAN ID 20.
- Port's pvid is not used for inter-VLAN routing. We offload vlan-id of /interface/vlan entry into the hardware routing table instead. So you are right that pvid could be theoretically omitted, but in reality, pvid is mandatory. So the rule of thumb is to set pvid to the same value as vlan-id. Or one of vlan-ids because multiple VLANs may be routed through a single trunk port.
Not directly related to L3 routing (hence off topic in this thread), but anyway: I always thought that setting port tagged member of VLAN (/in/br/vlan entry for VLAN ID) and setting PVID on bridge port (/in/br/port) makes possible mismatch: if frame-types is not set, then untagged frames are allowed and get tagged on ingress while on egress they are always transmitted tagged? Or did this behaviour change in ROS v7?
/interface/bridge/port add bridge=bridge interface=ether2 pvid=20
/interface/bridge/vlan add bridge=bridge tagged=bridge,ether2 vlan-ids=21
/interface/bridge/vlan add bridge=bridge tagged=bridge untagged=ether2 vlan-ids=20
actually as i understand it, while disallowing untagged frames might make that port unable to talk to others it can still eavesdrop all other ports in that PVID (broadcast packets from other members would still be sent out untagged to it).I still don't fully understand why PVID setting is mandatory in practice. @raimondsp writes that omitting to set it keeps the default setting of pvid=1 (which we already know very well), but the argument about bridging the port with other ports with pvid=1 seems moot to me if frame-types property is properly set (to admit-only-vlan-tagged) (in which case port won't pass untagged frames on ingress and in practice pvid membership doesn't matter much).
You're right. But in that case recommended practice would be to set PVID of each trunk (tagged only) port to a different value, but not one of VLAN IDs allowed as tagged.actually as i understand it, while disallowing untagged frames might make that port unable to talk to others it can still eavesdrop all other ports in that PVID (broadcast packets from other members would still be sent out untagged to it).I still don't fully understand why PVID setting is mandatory in practice. @raimondsp writes that omitting to set it keeps the default setting of pvid=1 (which we already know very well), but the argument about bridging the port with other ports with pvid=1 seems moot to me if frame-types property is properly set (to admit-only-vlan-tagged) (in which case port won't pass untagged frames on ingress and in practice pvid membership doesn't matter much).