From https://wiki.mikrotik.com/wiki/Manual:Switch_Chip_Features I can see that newer RB1100AHx4 device which is quite cost-efficient while capable of hardware IPSec acceleration equipped with RTL8367 switch chips while older models (RB1100AH and RB1100AHx2) were Atheros8327 based.
I wouldn’t pay attention on specific chip model (since I used to trust MT engineers for choosing good hardware for the task) but on the same page I can see the following:
RTL8367:
Port Switching - yes
Port Mirroring - yes
TX limit - no
RX limit - no
Host table - 2048 entries
Vlan table - no
Rule table - no
while Atheros8327 is much more hardware capable:
Port Switching - yes
Port Mirroring - yes
TX limit - yes
RX limit - yes
Host table - 2048 entries
Vlan table - 4096 entries
Rule table - 92 rules
Thus, when you get newer router you have to process all vlans and traffic limiting on its CPU, right? This way, older device appears to be better one to buy, and MT appears to push users to get CCRs.
Ok, CCRs are good (really), but then why MT still produce 1100 series?
If you use router primarily as router (and RB1100AHx4 is a router), then majority of traffic will have to pass CPU anyway (because that’s where routing is done). I’d get very annoyed if MT decided to put low-end switches in their CRS/CSS line of products though.
Yes, I totally agree, and play low by putting 3 switch chips for 5 ports each instead of one for all ports make us to pass traffic with CPUs even between ports on the same device (say from port on group 1-5 to port on group of 6-10), but anyway, at least 10 of these 13 ports can be used as client ports in some small office (or remote branch) - so 1100 series is quite good as branch router with h/w accelerated crypto. But these low-end switch chips… Looks like MT decided Atheros is too good for us poor users!
Anyway, we all have several VLANs to deal with and use CPU for this is something weird, isn’t it?
I agree that switch chips in RB line of devices should be better. At the same time I think that MT should take a step further in their current bridge vlan-filtering implementation so that it’d enable HW acceleration (offload) on all devices capable of dealing with VLANs in switch chips.