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!
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?
Thank you, excited about the changes, wireguard too.
Oops, we accidentally posted implemented but yet unreleased features. Well, I guess that now you have an official sneak peek of the upcoming changes.
Release by release the L3HW feature set is growing 
Hopefully IPv6 support is added in the next few releases.
IMO there’s an error in the “VLAN configuration example”:
/interface/bridge/port add bridge=bridge interface=ether2 pvid=20
/interface/bridge/vlan add bridge=bridge tagged=bridge,ether2 vlan-ids=20
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?
Or (according to the idea behind the example) ether2 should rather be set as tagged port with “pvid” setting omitted?
That’s a good question. Thank you! Let me explain.
The example you are referring to shows how to properly set up hardware routing for a tagged single (i.e., not bridged) port. It is a rare case but has a high chance of misconfiguration.
- In the case of software routing, you don’t need a bridge in-between because the port is not meant to be bridged with other ports. You simple create /interface/vlan on top of the physical port.
- However, this does not work for hardware routing. L3HW is built on top of L2HW, and L2HW, or in particular - the hardware bridge, is the one that assigns VLAN tags to the packets. Therefore, you need a bridge in between, otherwise, the hardware cannot set VLAN tags. This is a hardware requirement.
- That’s why we have to put the port under the hardware bridge but, no matter how weird it sounds, make sure it is not bridged (by setting VLAN filtering).
- 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?
If you want to prohibit untagged traffic, set frame-types=admit-only-vlan-tagged for the given /in/br/port. The same behavior in both ROS v6 and v7.
Just to be clear this aberration, anomaly is only for a very specific or rare scenario because its seem counter intuitive to what we have been exposed to up to this point in time.
In other words, can you better describe the use case/requirement that would lead to such a bizarre setup and is this limited to specific MT devices or all?
If I understood @raimondsp’s explanation correctly, then it’s the same for all devices and kind of makes sense:
when bridge port has PVID set (and it always has one, if nothing else the implicit pvid=1), then it gets automatically added as untagged member of corresponding VLAN. Unless it’s explicitly added as tagged member of the same VLAN (manual setting overrides automatic one), in that case port becomes tagged member of said VLAN.
And setting of frame-types to correct value should be at least good practice because of higher security, the default setting of frame-types=admit-all might be a good starting point (because it doesn’t block anything) but often (if not mostly) it’s just too permissive.
I’m sure @raimondsp will correct me if I’m wrong.
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).
Actually, when the frame-types property is set to admit-only-vlan-tagged, it does not necessary check the ingress. If ingress-filtering is set then it will. Ultimately, all this applies to us when configuring Hybrid ports:
ingress-filtering
By default, VLANs that don’t exist in the bridge VLAN table are dropped before they are sent out (egress), but this property allows you to drop the packets when they are received (ingress).
So, if you want port security in a Hybrid configuration, you need four confusing settings: pvid=X, frame-types=admit-all, ingress-filtering=yes, and then finally a tagged behavior on the port. Even though you have admit-all set, ingress-filtering will check to see if PVID is not 1 and if a tagged VLAN ID has been set on the egress behavior. This toxic mix of settings allows untagged and tagged frames, but only tagged frames from the list of allowed tags. Good tags pass entrance, bad tags are dropped at the door.
Not complaining 
What range of values will be possible for MTU on the CRS3xx series?
RouterOS v7.1beta7: variable MTU / Jumbo frame support.
Will it be possible to use switch as PE device?
As a P router?
i agree.
i understand setting the port PVID is meant to segregate the physical ports (equivalent to no bridge whatsoever, or port isolation), but setting the port PVID to the same as what you’re sending tagged is just bad practice.
ignoring untagged frames on the interface works, but you might actually want to do something with those frames so i think instead the best practice would be using a different PVID to what you’re tagging out the port, so using their example
/interface/bridge/port add bridge=bridge interface=ether2 pvid=20
/interface/bridge/vlan add bridge=bridge tagged=bridge,ether2 vlan-ids=21
this accomplishes the same while IMO being good practice.
if you wanted to route with untagged frames on that port, you would just need to add another VLAN entry for that ID.
/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).
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.