7.15 beta what? IS-IS is already in v7.14
WAN under the Bridge (or not)
The debate about putting a WAN interface under the VLAN-filtered bridge or leaving it standalone is getting hot, so let’s clarify the subject.
- 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 nanoseconds), 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.
- None of RB* devices support L3HW. Hence, you can keep the WAN interface outside the bridge even if it requires VLAN tagging. You may put an /interface/vlan straightly on top of the WAN port.
- UPDATE: If a WAN port requires some bridge features (e.g., bridge firewall, VLAN traffic filtering, etc.), then, of course, you need a bridge.
VLAN MTU Issue
We have reproduced multiple issues regarding VLAN MTU not applying correctly or resetting to default after reboot. Unfortunately, it is too late to incorporate the fixes into 7.14, so those will be available in the upcoming 7.15beta.
Thanks for the feedback!
@raimondsp, there is also I think the case where you need bridge filter rules, for instance my provider Orange in France require to set the COS to 6 for DHCP request, therefore I need to use a bridge port to set it on my rb5009 as the new-vlan-priority is not supported on this device as a switch rule.
Good point! If you need a bridge firewall, then, of course, you need a bridge in the first place.
What’s new in 7.14rc3 (2024-Feb-27 10:06):
*) lte - improved FG621-EA modem firmware upgrade;
*) ovpn - limit the maximum length for “push-routes” up to 1400 characters;
*) sstp - added support for “aes256-gcm-sha384” encryption;
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?
yes, has been said by raimondsp.
Another use case is when you need to route some WAN vlans, and bridge other ones. Typically to replace a triple play provider box by a custom router setup. The RB5009 is perfect for that and do allow to keep the full provider speeed, around 900 mbps, regardless the IPIPv6 tunnel that is almost saturating a processor core for IPv4. I did it successfully for the Free french provider. With previous RB routers, it was not possible to get this speed. In this regard Orange is probably faster, because they deliver a dual stack traffic if i’m right, no need for a costly IPIPv6 tunnel for IPv4. The advantage of Free is that you can have two IPIPv6 tunnels, and get two IPv4 WAN addresses (a full stack and a 1/4 shared one), quite interesting for some experimentation.
Sorry if my post sounded misleading regarding the latency. I edited it for clarification. Once the NAT rule is offloaded to the switch chip, it has no additional latency, regardless of whether the WAN port is under the bridge. The delay may happen only on the CPU while traversing the interface stack: the packet goes from the VLAN interface handler straight to the port handler vs. entering the bridge in between (which, in turn, performs port lookup by VLAN ID). As I mentioned, it is not a big deal as those are just nanoseconds (depending on the CPU) or even less for FastPath.
The question of “A trunk port of 10 VLAN networks” vs. “10 standalone ports” is purely theoretical because connecting two devices with ten cables is impractical. Two devices get connected with multiple lines to ensure redundancy and/or load balancing rather than saving a few CPU cycles on bridge VLAN table lookup.
*) ovpn - improved system stability when using HW encryption on ARM64 devices (introduced in v7.13);
Any chance you will implement HW encryption for SSTP too? Pleeease 
I appreciate the clarification, this was my understanding as well but wanted to confirm!
Here is a bridge filter NAT problem with Ros7.14RC2, RB5009.
The following setup is a simple layer 2 NAT, to masquerade the MAC address of a client device.
There are two rules for layer 2 src and dest NAT, and two rules to make an ARP fixer. One more rule to filter anything except IPv4 traffic from client.
This is needed because my provider is checking the client MAC address and on some devices it is not possible to change the MAC address.
Layer 3 NAT is not possible because the upper layer 5 protocol is not NAT friendly and there is no NAT helper for this protocol inside RouterOS.
Here is a working setup on a RB450G with Ros 6.38.5. Only two Ethernet interfaces inside a bridge.
ether4 is client port
ether5 is provider port
# by RouterOS 6.38.5
# RB450G
#
/interface bridge nat
add action=arp-reply arp-dst-address=15.20.25.254/32 arp-opcode=request \
chain=dstnat comment="ARP Reply - MAC Provider" in-interface=\
ether4 mac-protocol=arp to-arp-reply-mac-address=00:05:AA:20:05:32
add action=arp-reply arp-dst-address=15.20.25.55/32 arp-gratuitous=no chain=\
dstnat comment="ARP Reply - MAC Client" in-interface=ether5 \
mac-protocol=arp to-arp-reply-mac-address=65:AB:55:99:1F:42
add action=src-nat chain=srcnat comment=\
"Source NAT Layer 2 - IP traffic from Client" mac-protocol=ip \
out-interface=ether5 to-src-mac-address=65:AB:55:99:1F:42
add action=dst-nat chain=dstnat comment=\
"Dest NAT Layer 2 - IP traffic to Client" in-interface=ether5 \
mac-protocol=ip to-dst-mac-address=15:DC:21:14:B5:81
/interface bridge filter
add action=drop chain=forward comment="Drop not IP from client" in-interface=\
ether4 mac-protocol=!ip
The same setup on RB5009 with Ros7.14RC2 does not work.
On the RB5009 there are a couple problems : ARP matcher does not work, VLAN matcher does not work (on the RB5009 i use a VLAN aware bridge). Perhaps a couple more problems that will ask for more investigations.
The same setup on a RB3011 with Ros 6.49.13 does not work.
Seems like the new VLAN aware bridge code did introduce a couple problems for matching ARP and VLANs inside the bridge filter NAT chains.
In the meantime, i'm using an external RB450G just to masquerade a client device MAC address.
I use the mikrotik CHR router under xcp-ng 8.2.1 (xenserver) and up to and including version 7.4rc1 it works fine. With the update to 7.14rc2 or 7.14rc3 the ethernet interfaces in the system are no longer recognized. xcp-ng also no longer recognizes a management agent with both releases, previously the management agent 6.6.80-71 was recognized. A rollback via snapshot to 7.14rc1 leads to a functioning system again. The problem is deterministic and reproducible.
802.3ad bonding interfaces created with a pair of MLAG switches according to help pages work fine with two CRS518-16XS-2XQ in MSTP bridge mode, but they don’t on CRS326-24S+2Q+ with the same configuration.
On the CRS518-16XS-2XQ MLAG bond, when you look at the remote peer, you see something like
/interface/bonding/monitor-slaves bond-bgp-rr1
Flags: A - active; P - partner
AP port=sfp28-1 key=21 flags="A-GSCD--" partner-sys-id=XX:XX:XX:XX:62:F0 partner-sys-priority=65535
partner-key=21 partner-flags="A-GSCD--"
AP port=sfp28-2 key=21 flags="A-GSCD--" partner-sys-id=XX:XX:XX:XX:62:F0 partner-sys-priority=65535
partner-key=21 partner-flags="A-GSCD--"
where the partner-sys-id advertised from both CRS518 in the MLAG group match up.
If you do the same thing on CRS326-24S+2Q+, sometimes the first unit creates what seems like a completely random system-id (MAC) but when you create both bonding interfaces, add both to bridge, etc on both CRS326-24S+2Q+ units, you then look at the remote peer’s monitor-slaves and only one port is active because there are two different partner-sys-ids coming in from each of the CRS326 — sometimes what’s been created on the secondary as listed in /interface/bonding/print, but the primary can be an out-of-left-field MAC (not even close to the one listed in its /interface/bonding/print) or sometimes it is. But they don’t synchronize/settle on reporting the same ID to the remote peer and so only one port comes up and the actual MLAG LACP bonding therefore isn’t working properly.
Anyway, in short, works on the one device (CRS518-16XS-2XQ) and doesn’t on the other (CRS326-24S+2Q+) fairly default configuration settings, equal in every way, both with MSTP bridges.
@MKTK_staff
Is there any chance for adding permanently present section in announcements:
“Functions removed or postponed to future betas”
*) none (if it is the case)
or e.g. as was in a past
*) BTH …
It would be timesaver for some decisions about upgrading when testing new versions…
What’s new in 7.14rc4 (2024-Feb-28 13:38):
*) route - use correct routing table for addresses on VRF interface (introduced in v7.14beta3);
*) smb - fixed export with default configuration (introduced in v7.14beta7);
Seems that 7.14 stable is near…
It would be nice to know what’s new in 7.14rc4 from 7.13.5, any chance to know it before the stable release?
Thanks
Yes, read the initial posting announcing the beta and they tell you everything that is new since 7.13 as well as improvements made with each revision.
since 7.13 not 7.13.5
Go back up to the very top and read the section clearly labeled “Other changes since v7.13”
Edit. Then aggregate all the 7.14 RC changes and there is your list.