After several days struggling to take advantage of the awesome potential of the switch chip in the RouterBOARD 750GL I am forced to say that it does not work. The documentation (http://wiki.mikrotik.com/wiki/Manual:Switch_Chip_Features) is vague, inadequate and inaccurate. The hardware capability may be there but RouterOS does not implement it (correctly).
On the surface, the rule table should permit filtering similar to bridge rules or firewall rules, but at wire speed. This is not the case. Typically, one would set up the access control list (Atheros 8327 terminology) to allow desired packets and then add a rule to drop anything else. However, packets continue to be processed after matching a rule and then get dropped when the final rule is encountered. This effectively prevents any switching, even to the CPU and a factory reset is the only means of recovery. Webfig lists the rules is reverse order relative to the CLI and does not allow the reordering of the rules as can be done for bridge rules and firewall rules.
A simple example - permit only two hosts to communicate across the switch: master port ether1 / slave port ether5
The first two rules should match IP packets in each direction. The destination port does not need to be modified so all actions are off (drop=no).
The third rule will allow ARP across the switch so the hosts can resolve MAC addresses.
The fourth rule blocks everything else (drop=yes).
Seems straight forward, but it does not work. No packets are forwarded.
The experience is the same with several versions of RouterOS including the latest (6.1).
If you disagree with this post please provide a working example.
In the mean time the switch chip features gets two thumbs down.
Using new-dst-ports would work in this extremely simple case, but does not generalize well.
If more ports are part of the switch and there is no foreknowledge of the ingress or egress ports the rules would need to add all ports (including the ingress port) to the new-dst-ports list. The switch no longer selects the correct port using the MAC address (host) table. The result is hub style operation instead of switching. The reduction of effective bandwidth could more than offset the gain from hardware filtering.
In the AR8327, ACL_DP_ACT (bits 72:70 of ACL Action Definition) permits four choices (111: drop, 011: redirect, 001: copy to cpu, 000: forward) the last two allow the packet to be forwarded normally (according to the MAC address table). [Perhaps DES_PORT_EN (bit 68 of the Action Definition) should be 0.]
The chip seems so cool and this looks easy to code. If a problem prevents implementation there should be a notice somewhere in the Wiki.
I am surprised that this has not come up before. Hasn’t anyone tested or used this yet?
Otherwise, this is a great product that easily competes with very expensive solutions from the big networking firms. (I don’t name them so they won’t find out.)
WARNING: This post may contain information considered confidential by Qualcomm Atheros. Persons under contract with Qualcomm Atheros or another entity operating in the same market may be required to avoid this information.
NOTICE to anyone who may object to the disclosure of this information: Everything disclosed herein was obtained legally without an non-disclosure agreement (NDA). Whether or not the source of this information had the right to disclose this information is an issue to between yourself and the source. I am an unrelated third party without any obligation to you or the source. DO NOT ATTEMPT TO INTIMIDATE ME. This information is now stored redundantly in the cloud. Should any of my ordinary communications activity cease the information will be automatically distributed to all known competitors of Qualcomm Atheros, all known patent trolls in the networking market, to members of the hacker group Anonymous and to wikileaks.org without any further intervention on my part.
MikroTIK is not the source of this information. The terms of most NDAs would permit MikroTIK to disclose confidential information that it obtains from legitimate sources. I have no knowledge of any NDAs to which MikroTIK may be a party or the terms of those agreements should they exist.
I believe that I have found the reason for the unexpected behavior of the switch chip features in the RouterBOARD 750GL.
The AR8327 (this may be the case for other chips in the same product line) will apply the actions of two matching rules to a matched packet. The rule actions will be combined in one of two ways:
For most action classes the action of the first rule will take precedence when specified. Where the first rule does not specify an action for a class of actions the action of the second rule will be applied. An example usage: Your can create a set of rules for VLAN management and another set of rules for QoS. Then both rule actions will be applied to packets that match one rule in both sets of conditions. This makes it possible to greatly simplify a set of rules.
Three classes of actions are “ORed”, effectively applying the most restrictive action. The three classes of action are generate system interrupt, drop/redirect/copy-to-cpu/forward, and mirror.
In this case I attempted to implement the following:
0 match-rule action="forward (no action in RouterOS)"
1 match-everything action="redirect to empty port list (drop not available in RouterOS)"
Anything that matches the first rule also matches the second rule. The action class falls into the second group above so no packets are forwarded.
Solution:
0 match-rule action="forward (empty action in RouterOS)"
1 match-everything action="forward (empty action in RouterOS)"
2 match-everything action="redirect to empty port list (drop not available in RouterOS)"
Now packets which match rule 0 also match rule 1 and rule 2. The first two matching rules (rule 0 and rule 1) will be applied. Both rules have the same action (forward), hence the packet is forwarded as desired.
Anything else (packets that don’t match rule 0) will match rule 1 and rule 2. These rules have different actions. The actions are in the second group above. This means the action from rule 2 will supersede the action of rule 1, hence the packet will not be forwarded.
The principle for similar filtering is to create a “guard” rule between the ACCEPT and DROP rules so that packets in the ACCEPT group will have two matching rules and not be caught up by a DROP rule. It requires a sophisticated understanding of logic to create a good set of rules to get the job done (mad mathematics skills), but the RouterBOARD 750GL is a great piece of hardware at an amazing price point.
This investigation revealed some bugs (or poor design choices) in Webfig and the CLI (I don’t use Winbox or The Dude so these remarks may or may not apply to them).
Drop is not exposed in the switch rule interface.
Forward is not exposed in the switch rule interface.
Drop, redirect to new ports, copy to cpu and forward are mutually exclusive and should be implemented with a radio button in Webfig.
Webfig does not present the switch rules in the correct order.
Webfig does not present the switch rule numbers.
Webfig does not allow reordering the switch rules.
When you use the CLI you need to print the switch rules after every change to reliably manage the rules.
There are a number of other useful features of the AR8327 that are unavailable to the user.
I don’t know what karma is worth but I deserve quite a bit for this report.
Polymath,
Your posts have been reviewed and your observations will be considered for further switch-chip development.
Thanks for pointing out Webfig imperfections.