v7.14rc [testing] is released!

[blacksnow]

• Technically, RouterOS v7 allows putting a WAN interface under the VLAN-filtered bridge in any case (into a separate VLAN, of course).
• However, it complicates the user config and CPU processing. In other words, it will be harder for humans to understand such a configuration, and it will take slightly longer for the device CPU to walk through the device tree to find an egress port for a packet. While it is not a big deal (we’re talking about a few extra microseconds per packet), you can still avoid it unless hardware requirements force you.
• Speaking about hardware requirements, the famous one is L3HW. Hardware routing requires hardware bridge for VLAN tagging, so the only way apply L3HW on a VLAN-tagged WAN interface is putting it under the bridge. Still, it applies to L3HW-capable devices only (CRS3xx, CRS5xx, and CCR2x16) and only if the WAN interface requires VLAN-tagging (or bridging multiple WAN interfaces). For instance, if CCR2216 has a standalone untagged WAN interface, you can keep it outside the bridge (and win a few nanoseconds of hardware-processing time per packet).

So with a WAN that requires VLAN that is in the bridge, once the NAT rule is in the switch chip how much additional latency are we talking about? Is the latency cost just for the first couple of packets for a new connection or is it on all packets? Are you essentially saying that L3HW regardless of implementation adds an additional X of latency? If so is X microseconds or nanoseconds? Also when you mention it complicates the user config doesn’t that apply to any network that is connected with a VLAN into the bridge? I mean there is nothing special about a WAN network it’s just another network. If I have 10 VLAN networks plugged into a trunk port (sfp1) and attached to the bridge does that mean all of those are suffering additional latency rather than if they were all individual physical ports like (sfp1-sfp10) each with an individual vlan directly on the interface?