Many devices supported by OpenWrt contain an Ethernet network switch. Most switches are configurable and driver options are available. Typical features include ethernet frame tagging and VLAN support. We require two software components:

1. a kind of a driver
2. a utility

The preferred contemporary driver architecture for ethernet switches in the Linux kernel is DSA (distributed switch architecture).

For a user the main difference to past OpenWrt switch drivers is that all the switch ports that on a consumer router have names such as LAN1, LAN2, … or WAN also appear as independent network interfaces in userspace and those can be handled like any other network interfaces using the ip tool or ethtool.

The Linux kernel also has userspace configuration examples on how to use the DSA switches in Linux.

DSA support will be introduced along with kernel 5.4 support, but there is no full feature parity with swconfig yet as of writing (2020-05-12). Changing VLAN tags is not supported yet at the moment, e.g..

Tagging support is more complex than with swconfig; see the kernel documentation for configuration instructions. It looks like at this point there is no automation for this yet and it needs to be configured through /etc/rc.local.

Only master targets actually having DSA enabled are listed.

The previous switch driver model invented by OpenWrt was switchdev and the corresponding configuration utility was swconfig. This is used in legacy patches and userspace, but is not recommended when implementing switch drivers for new devices. Please write new code using DSA and help out to convert old drivers to DSA if you can.

• RTL8366/RTL8369 datasheet, notice that this is quite different from RTL8366RB or RTL8369S
• RealTek RTL8366RB, a 5-port Gigabit switch e.g. in the WR1043ND v1 or DIR-685
  • Upstream RTL8366RB DSA kernel driver this should become the default after incorporating kernel v4.19 or later
  • see all tickets concerning the Realtek RTL8366RB
    • e.g. Ticket 7977:Enhance rtl8366rb driver
    • e.g. Ticket 10202: Add support for port mirroring in rtl8366rb
  • see all changesets concerning the Realtek RTL8366RB
    • e.g. r36847: add port mirroring/monitoring capability to the RTL8366RB switch
• RealTek RTL8366S, e.g. in the DIR-825
• Realtek RTL8306SD/SDM FastEthernet, 6 Ports, 5x 100BASE-TX-PHYs e.g. in the ARV4518PW
• RTL8309G FastEthernet, 9 Ports, 8x 100BASE-TX-PHYs e.g. in the D-Link DIR-632

• AR8216 FastEthernet, 6 ports; found in Arcadyan ARV752DPW22, Netgear WNR2000v1, others
• AR8316 GigabitEthernet, e.g. in the RouterStation Pro, WBMR-HP-G300H, …
• AR8228 + AR8229 FastEthernet: 7-Ports, 5x 100BASE-TX-PHYs
• AR8236 FastEthernet: 6-Ports, 5 x 100BASE-TX-PHYs
• AR8327 + AR8327N GigabitEthernet: 7Ports, 5x 1000Base-T-PHYs e.g. in the WR1043ND v2 (Atheros AR8327N-BL1A)
• AR8328 + AR8328N GigabitEthernet: 7Ports, 5x 1000Base-T-PHYs
• Atheros AR7240 built-in switch
• Atheros AR934X built-in switch

Note: Atheros Switch-Chips with the 'N' designation include the Hardware NAT function.

• r37650: brcm47xx: switch to kernel 3.10.4; This uses a new switch driver. The old ADMTEK Adm6996 switch is not supported any more.
• Broadcom BCM5325

• Vitesse have produced 4-port PHYs VSC8584 and VSC8574
  • Upstream PHY driver for VSC8584 and VSC8574
• Vitesse have produced switch chips for 5+1 and 8+1 switches VSC7385, VSC7388, VSC7395 and VSC7398.
  • Upstream DSA kernel driver for VSC7385, VSC7388, VSC7395 and VSC7398
• The Vitesse switch chips family were acquired by Micosemi who were then acquired by Microchip.
• Micochip will provide complete datasheets if you sign an NDA on their website

VSC7384 datasheet

• TC2206

• IC+ IP17xx

• some Switches contain a functionality called “Hardware NAT”; support for this features has not yet been included into OpenWrt. Since the cpus used in CPE Routers are relatively slow, expect 2 to 4 times performance gain if you were to use Hardware NAT, e.g. without hardware NAT some router could achieve 400Mbit/s at full CPU load, with hardware NAT it could achieve 900Mbit/s at full CPU load. OpenWrt developer is supposed to have said, that implementing HW-NAT support would be unacceptably hacky to accomplish.