hEX-S and hardware VLAN switching

Hardware MikroTik hardware general
1

Hi,

Is there some way to configure a hEX-S to do VLAN switching in hardware? There is a a bunch of options under /interface ethernet switch, but none seems to make any difference. Simple tagged and untagged/pvid settings will do fine.

The situation is that we are planning to run multicast audio and video (>25Mbps) passing over a hEX-S, and it will simply consume to much CPU to do that in a software bridge, and it may introduce jitter/stuttering and so on. We are doing it today with a RB260GS and it works fine, but we are trying to avoid those because of lack of manageability.

2

hEX S switch chip does not support Vlan tables

3

With lack of complete view, I am failing to understand why you think the >25Mb/s multicast will kill the hEX S?

If you need to change this, this is where the trusty old RB2011 will shine

4

Yes, it does actually. But RouterOS uses the VLAN to separate each switch-port to a logical interface within RouterOS. So my question is if this setup is changeable, so there will only be one logical interface to the cpu-side (as it’s actually connected) and you can run a couple of hardware VLANs instead. The menu options is there strangly.

It won’t kill it, of course, but since the packet forwarding will be done in software, there is risks of latency/jitter/stuttering depending on cpu load.

5

Not sure if above refers to my post saying hEX S switch chip does not support Vlan tables…
hEX S Switch Chip.JPG

6

Again, yes, it does.
http://www.trolink.cn/UploadFiles/Product/20160419152925_77763.pdf - Page 6

RouterOS uses this VLAN support to create logical interfaces, that is hidden from the user and configuration. Or maybe there are many variants of MT7621.

Anyways, would be nice if there was a way to “disable logical ports layout” and get back the VLAN capability.

7

It looks like RouterOS 7.1rc5 added functionality for HW offload of VLAN filtering:

“*) bridge - added HW offload support for vlan-filtering on MT7621 switch chip (hEX, hEX S, RBM33G, RBM11G, LtAP);”

http://forum.mikrotik.com/t/v7-1rc5-development-is-released/152877/1

8

yes is expected to be enabled

https://help.mikrotik.com/docs/display/ROS/Bridge#Bridge-BridgeHardwareOffloading

9

Okay but that does not mean setting up the router any differently with regard to the ‘new’ method of bridges and vlan filtering does it.
I thought its simply checking off a box somewhere.

10

I can confirm that is supported from ROS v7 but I noticed that VLANs have to have access to the bridge port (at least to forward the DHCP request to the uplink router).

host cannot obtain IP address, configuration as https://help.mikrotik.com/docs/display/ROS/Basic+VLAN+switching#BasicVLANswitching-CRS3xx,CRS5xxseriesswitches,CCR2116,CCR2216andRTL8367,88E6393X,88E6191XandMT7621switchchips:

/interface bridge
add name=bridge1 frame-types=admit-only-vlan-tagged

/interface bridge port
add bridge=bridge1 interface=sfp1 frame-types=admit-only-vlan-tagged
add bridge=bridge1 interface=ether2 pvid=20 frame-types=admit-only-untagged-and-priority-tagged

/interface bridge vlan
add bridge=bridge1 tagged=sfp1, ether2 vlan-ids=20
add bridge=bridge1 tagged=sfp1,bridge1 vlan-ids=99

/interface bridge
set bridge1 vlan-filtering=yes

host obtains IP address:

/interface bridge
add name=bridge1 frame-types=admit-only-vlan-tagged

/interface bridge port
add bridge=bridge1 interface=sfp1 frame-types=admit-only-vlan-tagged
add bridge=bridge1 interface=ether2 pvid=20 frame-types=admit-only-untagged-and-priority-tagged

/interface bridge vlan
add bridge=bridge1 tagged=sfp1, ether2, bridge1  vlan-ids=20
add bridge=bridge1 tagged=sfp1,bridge1 vlan-ids=99

/interface bridge
set bridge1 vlan-filtering=yes

The first configuration does work on my CRS328s.
I enable the conntrack temporarily on the hEX S but it showed only VLAN 99 traffic, so VLAN 20 traffic is only on the Switch Chip, which means L2HW does actually work.
I dare to say it is a bug, isn’t it?

11

So your DHCP server is on a machine beyond sfp1 port? In this case it seems like a bug indeed.
If DHCP server is running on hEX S device itself, then it’s not a bug.

12

this is the case

13

In this case you should open a support ticket with Mikrotik. A supout.rif file will be probably handy for them to analyze the problem.

14

will do
can I provide any logs as well?
a log for each configuration?

15

supout.rif files, taken while problem is hapoening, are supposed to contain 100% of device state, including any (internal) debug files etc.

16

What is your ROS version ? Did you update to latest 7.2.1 ?
Also a network diagram would help understand your network topology better.

17

I have been upgrading all devices to 7.2.1. hEX S was replaced by an updated one, one by one.
I will reset my new spare one and repeat the configuration but I’m sure it will happen again.

network topology: hEX S → CRS328 SFP → CCR1009 (router on stick design)

18

You could try to use Wireshark on the host to make a more detailed packet analysis…

19

Hi,
the solution is quite simple the SFP-Port is not connected to the Switch-Chip tough block diagram leaving room for interpretation. In particular, if you combine it with official documentation like https://help.mikrotik.com/docs/display/ROS/Wireless+VLAN+Trunk (replace wlan1 by sfp1)
This is more as built:
image-1.png
There is one benefit of all the efforts, the following note was added to https://help.mikrotik.com/docs/display/ROS/Wireless+VLAN+Trunk:

For devices with hardware offloaded VLAN filtering and wireless interface support (e.g. RB4011 with RTL8367 switch chip, or LtAP with MT7621 switch chip), more attention needs to be paid. Packets going from HW offloaded ports to wireless can be filtered, if the VLAN access to the CPU is not allowed. It is possible to allow CPU access for a certain VLAN by adding the bridge interface as a VLAN member (similar to the VLAN99 example) or disabling HW offloading on bridge ports.

If anyone has some concerns regarding limiting access to managing function of the device:

  1. The web-config access is handled via the core router and its firewall.
  2. Winbox by simply allowing the MAC WinBox Server only on the MGTM interface
  3. (if you still want to be able to access the device via WinBox locally you use ACL-Rules)