RSTP Redundancy Problem

[ytunc41]

I am using 2 KSZ9477 chips and the 4th ports of these two chips are connected to 2 different network switchers. I want to use the 5th ports of KSZ9477 connected together for redundancy. Therefore, I want to make a backup connection using RSTP. But I cannot set the RSTP configuration properly. Since I do not use a Linux processor, I make these configurations myself and communicate using the I2C communication interface. Can you please inform me how I can apply which registers to which ports, respectively, in the scenario I described above?

[mtekllc]

I am using 2 KSZ9477 chips and the 4th ports of these two chips are connected to 2 different network switchers. I want to use the 5th ports of KSZ9477 connected together for redundancy. Therefore, I want to make a backup connection using RSTP. But I cannot set the RSTP configuration properly. Since I do not use a Linux processor, I make these configurations myself and communicate using the I2C communication interface. Can you please inform me how I can apply which registers to which ports, respectively, in the scenario I described above?

Much of the foot work of RSTP for KSZ9477 is handled in the KSZ driver for the linux kernel, ~5k lines of code.

I feel if I were in your situation, I'd poll the link state/speed for the ports of interest on a regular interval and set/unset the ports' learning, forward state registers by hand as required to accomplish what you desire.

The linux kernel driver source is a trove of information. You could cherry pick parts you need into your micro controller code.

The ksz9477 datasheet has detailed port specific control registers.

[ytunc41]

It must be a miracle that I was able to understand 5k lines of RSTP code and take the code blocks "I need" from it and put it on my own microcontroller. Instead, there should be a document explaining the algorithms here on a datasheet or in an application note. Why do I have to read the code and get the parts I need? RSTP redundancy logic should be explained and how to use it should be explained in detail in the application note document. In this way, users can develop their own software, simple or complex, according to this explanation. No one can understand anything with the 2 registers for RSTP in the datasheet. Am I wrong?

[mtekllc]

It must be a miracle that I was able to understand 5k lines of RSTP code and take the code blocks "I need" from it and put it on my own microcontroller. Instead, there should be a document explaining the algorithms here on a datasheet or in an application note. Why do I have to read the code and get the parts I need? RSTP redundancy logic should be explained and how to use it should be explained in detail in the application note document. In this way, users can develop their own software, simple or complex, according to this explanation. No one can understand anything with the 2 registers for RSTP in the datasheet. Am I wrong?

Spanning tree protocol and variants RSTP are not implemented on die. The host processor (linux kernel driver) handles everything. What is handled on die (in those port state registers) are the ability to control a ports state regarding handling of learning MAC addresses and forwarding packets. This is all you really claim you want to do with your uC. To try and use RSTP for that is heavy handed.

And yes… there is that data sheet thingy section 4.4.6 might be of interest. https://ww1.microchip.com/downloads/aemDocuments/documents/OTH/ProductDocuments/DataSheets/KSZ9477S-Data-Sheet-DS00002392C.pdf But notice the discussion of the host processors role.

My suggestion above was to simply poll via i2c the ports link state and status, then set them to learn, transmit, and forward based on that criteria. This would solve your original question of redundancy switch to switch (we assume using capacitively coupled links) and save you from having to implement a full RSTP implementation. You might also enjoy a faster failover not dealing with the wait states involved in RSTP while foreign BPDUs are accounted.

[ytunc41]

I better understand that STP and its variants are managed through the host processor. So, as far as I understand, KSZ only manages the HSR protocol. I wanted to use the HSR protocol in the architecture I mentioned above, but I was not successful. Isn't it suitable for the above architecture?

[mtekllc]

I better understand that STP and its variants are managed through the host processor. So, as far as I understand, KSZ only manages the HSR protocol. I wanted to use the HSR protocol in the architecture I mentioned above, but I was not successful. Isn't it suitable for the above architecture?

Nope, KSZ hardware handles all of the very low level port functionality required for implementing these protocols... particularly the blocking learning and forwarding all frames and in some cases passing of special frames of interest of these protocols. Most of the heavy lifting is done in the supplied linux drivers. This the case for RSTP, HSR and DLR.

HSR or DLR could provide a robust methodology to solve your initial requirement, however, you would still need to cherry pick that code over to your co-op / rtos uC code and slap it around a bit to get it working.

[ytunc41]

Actually, the question I wanted to ask was to understand the suitability of the HSR protocol for my architecture. In the examples used for HSR, two ports of two KSZs were directly connected to each other. However, for me, one connection between two KSZs is connected directly, and the other connection is connected through two different brands of switches. I found it to be more suitable for STP. Can it be used for HSR as well?

[mtekllc]

Actually, the question I wanted to ask was to understand the suitability of the HSR protocol for my architecture. In the examples used for HSR, two ports of two KSZs were directly connected to each other. However, for me, one connection between two KSZs is connected directly, and the other connection is connected through two different brands of switches. I found it to be more suitable for STP. Can it be used for HSR as well?

IMHO STP has a much wider vendor adoption probably due to the age of the technology, I think in your case, being that you can not run full switch stack, your best might be to just setup the switches to just forward/flood BPDU frames across the switchs like a dumb hub would do, let the other two switches hear those frames, detect a loop and break the link on the outside... if your internal link would fail, BPDUs would not pass internally; thus unheard from the adjacent switches and they would refactor the external link into a forwarding state again. The fail-over and recovery time would be that of STP version (hopefully RSTP for your sake) so keep that in mind as you experiment.

I can't speak to vendor interoperability of mchp DLR or HSR implementations.

good luck.

[ytunc41]

Is the reason you can't talk about HSR implementation because other smart switches don't support it? There are 2 smart cisco switches. Is HSR implementation useless?

[mtekllc]

Is the reason you can't talk about HSR implementation because other smart switches don't support it? There are 2 smart cisco switches. Is HSR implementation useless?

The reason I can't speak to vendor interoperability of mchp DLR or HSR implementations is simply because I have never used DLR or HSR protocols, nor have first hand knowledge regarding vendor interoperability. It's quite possible mchp DLR and or HSR would integrate just fine.

[ytunc41]

Thank you for everything. Then I want to focus and work on HSR.

[triha2work]

RSTP is mainly used to prevent looping. It is not used for redundancy as the hello time interval is fixed at 2 seconds. HSR and DLR are used in a ring network, so I do not know how they apply in your situation. There is a cost of using HSR as its header needs to be added and removed. The switch uses its source address filtering feature to prevent looping. There is only one programmed MAC address in the switch. The number of nodes in the network needs to be odd; otherwise the duplicate drop feature of the switch may not kick in, so software needs to handle it. DLR relies on a Supervisor to broadcast beacons every 400 microseconds and monitor the closed port for receiving. One issue is DLR may need licensing from the inventor.