Community discussions

 
FIPTech
Member
Member
Topic Author
Posts: 469
Joined: Tue Dec 22, 2009 1:53 am

RouterBoard Hardware Switch questions.

Wed Jun 14, 2017 6:48 pm

I've always had some difficulties to setup hardware switches on Routerboards, even after reading in details the wiki about this, as soon as the setup is more complicated than enabling master port on some ports, to switch all ports of the group and get an interface and mac address for the switch group on Router OS.

I'm not alone. Discussing with network managers guys i got the same feeling, switch features are difficult to understand and use, and most of the time the switch is wrongly considered buggy, because documentation is incomplete. This tendency mean that advanced switch features are most of the time not used, because they are too difficult to setup as soon as something a bit complex is necessary.

This is specially difficult when there is a mix of untagged and tagged traffic, with more than one port (mac address) on Router OS CPU side. More, there are some differences at the hardware level according to the switch chip used. This add to the complexity. For example, i was surprised to see that the switch chip on the high end RB3011 ARM dual core "home" router is not able to rewrite the VLAN ID and priority. This is not indicated in the wiki. This function is useful to split traffic to different VLANs without using different destination ports.

Some things are really not clear to me. Those questions are the ones who came to me during the setup of a quite complex half bridge (routing IPv4 and bridging IPv6) between a WAN and two LANs, on a RB3011 :

- When using VLAN mode (secure, check or fallback) how untagged packets are managed exactly ? Is there a difference for untagged packets between "disable" VLAN mode and other VLAN modes ?
- It is not clear to me what the disable VLAN mode mean, specially when it does allow VLAN tagged traffic to be passed to VLAN Router OS interfaces.
- How is managed traffic when there is a mix of ports with "disable" VLAN mode, and other ports with "fallback", "check" or "secure" mode ?

In the manual we can read :
Packets without vlan tag are treated just like if they had a vlan tag with port default-vlan-id. This means that if "vlan-mode=check or secure" to be able to forward packets without vlan tags you have to add a special entry to vlan table with the same vlan id set according to default-vlan-id.
But how are treated untagged packets if default-vlan-id is not defined ? Do they get an internal vlan-id ? If yes witch one ? Can this conflict with a user vlan ID ? I've read somewhere that VLAN ID = 1 is used internally to mark this traffic. Is that true or still the case in actual products ?

It seems that rules override vlan rules. But are they effective for ports where VLAN mode is "disable" ? VLAN rules on the other side are effective only for ports with VLAN mode different from "disable", if i'm right.

Other points :

- I've seen that it is possible to send traffic to Router OS ether interfaces, even if the Master-port function is not used. Traffic coming from a physical ether port, will go the the Router OS CPU port with the same number (ether1 physical will go to Router OS ether1 port) even if some part of the traffic is switched at the hardware level between physical ports, using VLAN switch rules and switch rules.
But why is it impossible to send traffic to router OS ether ports where there is no connected cable on the corresponding physical port ? It would be interesting to be able to use Router OS CPU interfaces when cables are not connected in their corresponding physical port (when the interface in Router OS does not have the Running flag). This would give the possibility to switch between physical ports, and give at the same time access to virtual CPU ports. This would be useful to send filtered switched traffic to different Router OS interfaces, independently from physical ports, for later inclusion inside software bridges for example. Actually it is only possible to do this with Router OS ether interfaces where a cable is connected.

Ideally, we should have the possibility to use more than one CPU port for each switch, and get those ports through virtual ether interfaces inside Router OS.

- On the manual it is stated that we need to use the master port function to be able to switch between two or more ports. This is not true. I've been able to switch between two or more ports of the switch physical ports using rules, without using the Master port function. And still getting traffic on the router OS side. Effectively, when not using master port function, each physical port is connected to its corresponding Router OS CPU interface with its own mac address. But this does not forbid to use rules to switch traffic between hardware ports.

The manual says here :
Switching feature allows wire speed traffic passing among a group of ports, like the ports were a regular Ethernet switch. You configure this feature by setting a "master-port" property to one ore more ports in /interface ethernet menu.
- Master port function seems to silently write some switch rules, something like automatic configuration of rules. The manual says that switch rules have priority, but it is not clear to me how things are managed if master port function is used at the same time as switch rules. It is impossible to know the result except perhaps with trial and error method, because master port rules are not available in the rule list. A better manual here, or a better GUI would be useful here.

All this add to the difficulty of using the Mikrotik switch features, mainly i think because the manual is not precise enough.
 
FIPTech
Member
Member
Topic Author
Posts: 469
Joined: Tue Dec 22, 2009 1:53 am

Re: RouterBoard Hardware Switch questions.

Wed Jun 14, 2017 9:10 pm

Something else i've just discovered :

Switch Rules are not fully directional (to be confirmed).

Example :

Here is a set of two rules to restrict traffic between two switch ports :
0   switch=switch1 ports=ether1-sw1-Wan-TV vlan-id=100 copy-to-cpu=no 
     redirect-to-cpu=no mirror=no new-dst-ports=ether5-sw1-trunk 

 1   switch=switch1 ports=ether5-sw1-trunk vlan-id=100 copy-to-cpu=no 
     redirect-to-cpu=no mirror=no new-dst-ports=ether1-sw1-Wan-TV
     
It seems that as soon as the traffic has been established in one direction through one of the two rules (host tables updated), the other rule as no more effect. You can remove it, the traffic will pass in the two directions.

If this is confirmed, this seems to be a security issue if we want to restrict traffic in a single direction ?

Tried on a RB3011.

There is no indication of this in the manual.
 
msatter
Forum Guru
Forum Guru
Posts: 1294
Joined: Tue Feb 18, 2014 12:56 am
Location: Netherlands / Nīderlande

Re: RouterBoard Hardware Switch questions.

Wed Jun 14, 2017 10:13 pm

Why should it be directorial, if you send traffic then you want to know if it has arrived and if not, retransmit.
Two RB760iGS (hEX S) in series. One does PPPoE and both do IKEv2.
Running:
RouterOS 6.46Beta59 / Winbox 3.20 / MikroTik APP 1.3.7
Having an Android device, use https://github.com/M66B/NetGuard/releases (no root required)
 
FIPTech
Member
Member
Topic Author
Posts: 469
Joined: Tue Dec 22, 2009 1:53 am

Re: RouterBoard Hardware Switch questions.

Thu Jun 15, 2017 12:07 am

Why should it be directorial, if you send traffic then you want to know if it has arrived and if not, retransmit.

Inside router OS, a software bridge rule (a forward filter) is directional. It is effective only in the direction you did write it for. If you need traffic in the other direction, you need another reversed rule.

In the case of hardware switch rules (switch chip), a rule directing traffic from one port to another port seems to be effective in the opposite direction as well.

In my tests (RB3011UiAS), when sending traffic from a physical switch port to the CPU port through a rule, the opposite rule (CPU to physical switch port) is not necessary to get the traffic back. This seems strange to me.

Imagine that traffic from CPU to to physical port is not filtered, this could end in sending sensitive CPU originated traffic you don't want to see on physical ports.

This is specially true when using the hardware switch for bridging WAN to LAN traffic. I'm using that setup to bridge IPv6 traffic, when routing and NAT at the same time IPv4. This is for a provider that deliver an unrouted IPv6 /64 prefix that absolutely need bridging. Only solution to that problem is to route IPv4 and bridge IPv6 at the same time.

My setup is working, but without more precise information i'm still confused and concerned about the switch chip safety and how it does work exactly.

The Qualcomm QCA8337 datasheet is a good start, but it is a very technical document that does not explain things like priority and interaction between rules, vlan rules, vlan modes.

Who is online

Users browsing this forum: MSN [Bot] and 122 guests