Turris MOX questions

Hello,

Have anyone already owned a Turris MOX router? I got several question regarding this hardware:

  1. I see MOX A (with 1GB of RAM) is available on Amazon. However I cannot find information there if it already contains a power supply? Where can I buy it, if it is not included?
  2. Does the Turris MOX provide any wall mounting holes on the bottom of the case?
  3. Does the MOX E together with TurrisOS support VLANs? I need to tag some VLAN on specified switch ports.
  4. Does MOX D allow the usage of fiber modules only, or are the copper (RJ45) supported as well? I could not find any 2.5G copper modules - if I buy 10/100/1000/2.5G/5G/10G module, then will it work with MOX D as 2.5G RJ45 connector? Could you recommend any module?
  5. What is the MOX performance? I have read about problems with traffic through-put. Some people reported they cannot get over 300mbps WAN<->LAN.
  6. Have anyone tried OpenVPN and/or WireGuard on Turris MOX? How are they performing?
  7. Is it possible to use RJ45 from MOX A together with ports from MOX E as a single LAN network? I plan to buy MOX A+D+E, that would give me 9xLAN and 1x WAN if copper-based SFP modules would be supported…

Thanks for all your answers!

I cannot provide answers to all question but somebody will definitely fill me in. I don’t use my MOX as a switch.

ad 1) You should start with one of the base models anyway (e.g. MOX Start, MOX Classic). They all contain power supply. Nevertheless it’s a fairly standard barrel type plug with 2.1mm internal diameter and 12V output. (More info here)
ad 2) There are no mounting holes from factory. Top and bottom plastic pieces are the same.
ad 4) MOX uses a basic 1.0GHz dual-core A53 ARM SoC, so performance greatly depends on use case. There are definitely higher end products on the market. Can’t say a whole lot about throughput as I haven’t tested it myself.
ad 6) I’ve been running Nebula from the authors of Slack and due to crypto overhead I was nearly capping the CPU. WireGuard is supposed to be much more mature and throughput will generally be better, but I seriously doubt that MOX scales well beyond 100Mbps speeds.
ad 7) Yes, you can bridge the Module A WAN port with LAN.

As I see it, MOX is a tool to tinker with during long evenings and not a device with heavy load in mind. You might want to check Turris Omnia as it does have more raw performance than MOX anyway and maybe get a separate managed switch if you need more Ethernet ports.

Thanks for your response.
Unfortunately Omnia provides too few ethernet ports and there is no way to plug additional switch. I have a multimedia switchboard that has a place just for one device and I need to mount it somehow there. Actually I own Linksys WRT1900AC and it is just great, but does not allow me to connect all devices I need, especially I lose one port for UniFi.

It is also a big shame, MOX does not contain any wall mounting kit/holes, but I believe I can drill some…

I got one moire question? What is internal switching performance of MOX E? It has 8 GigE ports, so to satisfy all of them it needs 16Gbps (Full Duplex). But what is the real capability?

you can find some info in updates on indiegogo campaign

There is no answer to my questions… And I think I will not buy it, because I found MOX E tests that showed how SGMII limits throughput. If MOX D is used as WAN and MOX E as LAN switch, then all you can get is approximately 1.2Gbps of traffic. This is because data from SFP WAN needs to go to the CPU via SGMII and then go to the MOX E via SGMII as well. Thus data needs to go via SGMII bus twice. What means you can get only 1.25Gbps max out of 2.5Gbps bus. That sucks… and thus there is no point of such configuration.

On the other side, there is even no information about switch chipset used and its internal bandwidth. To accomplish all needs, it should be 16Gbps at least (8 ports 1Gbps Full Duplex each).

I have opened a support request ticket and asked them the same question… still no answer. This just shows how bad-designed is Turris MOX. If I want to spend such a lot of money for Turris MOX, I think I could buy some JetWay minipc that contains 10x Gigabit Intel NICs and I will be able to fire OpenWrt there as well, or pfsense if I wish to.

This [1] might provide a hint, probably the 88e6390x in the E-Module


[1] https://gitlab.labs.nic.cz/turris/mox-kernel/blob/master/drivers/net/dsa/mv88e6xxx/serdes.c

there is update “Last call + MOX E Throughput Test” and there is answers :slight_smile:
for example:
“When all of the 8 devices connected to the switch are downloading data from the CPU module, each device downloads 249 - 298 Mbps (depending on the MTU setting) - the 2.5G SGMII bus is fully utilized.”

This is exactly what I have already written… But this happens between modules only. Traffic between computers connected to the same module (i.e. MOX E) should not be limited by SGMII bus. What does not mean all of them will be able to reach 1Gbps UP&DOWN (Full Duplex) simultaneously.

Why not, if the packets remain within the switch border?

The Marvell® Link Street®-88E6390X device is a single-chip, 11-Port Ethernet Switch with eight integrated 10/100/1000Mbps Ethernet transceivers and two high speed SerDes interfaces supporting 10Gbps XAUI and RXAUI, 2500-BaseX, 1000Base-X, and SGMII. The device also includes an integrated 200MHz microprocessor to enable smart or lightly managed switches without the need of an external CPU.

Because there is no information about internal bus speed. For example, cheap 8-port switching units provide 8Gbps bus speed. People think it is enough as they forget that switch needs at least a double of that to allow max speed on all ports simultaneously. And Marvel does not provide such data. In this case, even the bus speed should be even at least 18Gbps - to allow additional symmetrical gigabit transfer via SGMII to another RJ45 port in MOX A.

The feature set in the product sheet [2] stipulates

non-blocking

which to my understanding, least what seems commonly perceived in the network industry lingo [a], implies the backplane being capable of 16Gbps for the 8 downstream ports (1 - 8)

upstream ports (9 - 10) mode are apparently configurable as:

PORT_STS_CMODE_SGMII
PORT_STS_CMODE_1000BASE_X 
PORT_STS_CMODE_2500BASEX
PORT_STS_CMODE_XAUI
PORT_STS_CMODE_RXAUI

product sheet [2] stipulates for these two ports

The 10Gbps interfaces provide non-blocking uplink to cascade to higher port count 16 and 24 port switches

However, the MOX documentation citing

On both MOX Es you have 8x 1GBit ports, but the switches are connected to each other via 2,5 GBit links

The purpose of the eleventh port (0) is not clear to me

LinkStreet_88E6390X_FINAL2


With all that said I would concur that the specification for any of the NIC.CZ product lines should mention the chip sets utilised aside from the SoC, it would certainly be helpful, and perhaps even a link to the chip sets’ manufacturer data sheet (if publicly available).
It should not be required having to dig into the distro’s source code to infer such information and thus saving from having to start a thread in the forum and/or send emails to support.


[a] internal bandwidth can handle all the port bandwidths, at the same time, at full capacity

[2] https://www.marvell.com/switching/assets/LinkStreet_88E6390X_FINAL2.pdf

Yes, though outlined for the TO platform the underlying principle is the same as mentioned here [3]


Suppose this meant in the context of multi-homing? In which case modules C or E should suffice but would require some VLAN and Firewall configuration and perhaps bonding (not sure whether that works on the MOX) or packages like mwan3 or vpn-policy-routing
It would take its share on the bandwidth throughput on the links crossing the border between the modules and add to the CPU load.

if you connect MOX D and use it as a WAN, then your traffic has to go through the switch(es) to the CPU, get natted/filtered/routed there and go through the switch(es) back to the final destination.


Contrary to the crypto chip in the TO that just provides secure seeds for cryptographic operations this SoC features:

  • High-performance security offload engine including IPSec, SSL, DTLS, and IKE

That should work by building a VLAN trunk between the two modules. The potential drawback could be that if the ethernet port on the A module is not driven by DSA then the trunk could only only be achieved with driver-level (802.1Q VLAN Support) tagging on the A module and thus costing CPU cycles.


Well, documentation states only

The MOX D module contains an SFP connector for an optical connection

Which would be an odd limitation if that is really the case. On the TO I got a VDSL modem working in the SFP cage.


[3] DSA and 802.1Q tagging