I thought every hardware that had DSA support would be able to "see" all the switch ports, but my new Archer C7 has only the "eth0" Network Device. Is this a matter of hardware or is there any way that I can get my CPU to manage ports individually? If it is a matter of hardware, is there a way of finding out which switches have port management support and would work just like my old Archer C6?
My use case requires STP, and it is impossible to get STP to work if my CPU can't access the switches ports. The Archer C7 sends BPDUs with the same port ID out of every port (I guess its because the CPU is not connected to the ports, but to the unmanaged switch eth0 which contains the ports). The Archer C6 sends BPDUs with a different port ID for each port, which is the correct way of making it work.
The ARcher C6 is an ath79 device and is not DSA. It uses swconfig instead. You can access most of the switch settings via the switch menu (network > switch). Take a look at ethtool for more settings via the CLI.
EDIT: I stand corrected... I didn't realize the newer versions were MT7621. Please ignore my earlier bit.
This looks like a C6v3 which is MT7621 which is DSA. All versions of the C7 are QCA chips and are swconfig.
If you want to circumvent hardware switching on swconfig, you can set up the switch to send each port to the CPU through a separate VLAN and access them as eth0.N in software, building software bridges (with STP) as needed.
On the other hand, in DSA the eth0 port should never be accessed directly. Basically forget that it exists.
It works perfectly. I just built a network consisting of three Archer C7 switches connected in a ring, and the STP protocol prevented loops, so long as I separated each port to a different VLAN and bridged them through software as suggested. Thank you!
A little off topic, but do you know how can I see what is the current STP solution that the switch has adopted? I would like to know who was elected the network bridge, which ports are forwarding or blocking, etc.
Sorry for maybe overextending this post, but, while we are talking STP, is it possible to activate it only in some ports of a bridge, but not all of them? If I have two ports participating in a ring, but I know that the others are connected to end devices, it would be useful to allow these end device ports to skip the whole process of listening, learning, etc.
I don't have experience with STP on OpenWrt so the following are just suggestions.
Some implementations of STP have a port-fast feature, or something similar depending on vendor, to allow endpoints to connect quickly. I didn't see that in this doc: Options for bridges but it does list settings to control which bridge is root and which would take over if a root goes away. I also see a package ustp Description: 'OpenWrt STP/RSTP daemon' but I don't know if that is what is already installed or if it would ill advised to try to use it in your situation.
I noticed that the STP algorithm does not know that a port is down and, thus, allows a port to come up directly in forwarding state, which creates temporary loops before a BPDU gets to that port and it gets processed. Is there some way of preventing this? Could this be a bug that needs to be corrected in the code?
Notice how, for SW3, there is an event which indicates that port 2 is down, but only 20 seconds latter the STP algorithm notices that the neighbor switch was lost (this is the configured Maximum Age of the STP protocol). What the STP calls port 1 (eth0.1), the general switch event calls "Port 2":
TS
Switch
Event
08:56:03
SW3
kern.info kernel: [79636.566276] Atheros AR8216/AR8236/AR8316 mdio.0:00: Port 2 is down
08:56:23
SW3
kern.info kernel: [79655.925484] br-lan: port 1(eth0.1) neighbor 7fff.cc:32:e5:ed:98:7f lost
Then, the STP algorithm goes through listening and learning stages and puts this port in forwarding state. At this moment, nothing is connected to this port.
Then, when the cable is reconnected:
TS
Switch
Event
09:40:27
SW2
kern.info kernel: [82006.338768] Atheros AR8216/AR8236/AR8316 mdio.0:00: Port 3 is up
09:40:27
SW3
kern.info kernel: [82299.989919] Atheros AR8216/AR8236/AR8316 mdio.0:00: Port 2 is up
From 27 seconds to 30 seconds, the port was in forwarding state, closing a loop. The switch knew that the port had transitioned from down to up, but the STP algorithm somehow did not. Only after receiving a BPDU in this port the STP algorithm placed it in blocking state. How does the STP algorithm receive the information about which ports are down or up?
