Netonix Forums

Hey peeps, just testing some configurations out in the lab and for the life of me I cannot get a pair of Metrolinq 60GHz radios to form a part of a LAG/LACP-A group.

I set the Metrolinqs up and can pass traffic when in a LAG group with the neighbouring ethernet port, but the status shows 'not active' on the ports with the ML and active on the ports with cable.

Any suggestions? Are the ML's blocking LACP packets?

Get the LACP LAG working with 2 cables first.

Then replace one Ethernet Cable with the ML link and if the LACP LAG does not come up then you know it is the ML link not passing BPDU packets.

To use a wireless link in an LACP LAG it must be a true bridge.

Keep in mind LACP is not aware of link capacity or link congestion and is only aware of physical link state.

Need to be careful when using LAGs with wireless links because wireless link capacity does not match physical link capacity nor can LAGs detect link congestion.

Thanks Chris, I will try that although I'm sure I've tried it already.

I'm aware of the need for full layer 2 transparency and the limitations of LAG and wireless links, especially after reading all the threads in the forum first :)

This gets more frustrating as the weekend continues!

I put the ML's to one side and decided to try some WAP 60G's thinking they would just work...they didn't.

However when I disabled STP on the WAPs they started working, LAG status went to Active! Bingo!!

So then I updated the ROS on each of the WAP's and then they went back to not-active even though STP is still disabled.

Anyone seen this behaviour before or am I just missing something completely obvious?

Always disable STP/RSTP on all radios (PTP & PTMP) if they support STP/RSTP

Most people disable STP/RSTP on switch ports facing AP (PTMP) radios.

What is the reason for disabling STP/RSTP? An explanation would be good to understand the logic behind it.

So even with STP/RSTP disabled the link is still not active, is there anything else you can suggest?

My next test will be a pair of Ubnt radios.

signa wrote:What is the reason for disabling STP/RSTP? An explanation would be good to understand the logic behind it.

This question would indicate you do not understand how the STP/RSTP protocol works?

We did not write the STP/RSTP protocol/feature in the switch, it is an industry STANDARD called 802.1D and 802.1W respectively.

STP/RSTP feature is built into the switch core, we do not write this code we simply write the UI which allows you to configure the protocols / feature via STANDARD parameters such as priority, path cost, Forward delay, Hello time, Max age, and so on.

All STP/RSTP enabled devices talk to their direct Layer 2 neighbor devices with BPDU packets which are NOT passed through devices such as switches.

You should only turn SPT/RSTP on in a device if there is an event that can occur where that device could become the root.

You can search Google for STP and RSTP and read how the protocol works to better understand it.

This is not a situation where we as the manufacturer need more documentation but rather where the user needs to better understand a protocol they want to use. If for instance you were confused where to set the Priority we would need better documentation as to where you set that value.

Also another problem here for me in trying to help you is that I have no idea how the wireless link is handling STP/RSTP in regards to passing or not passing BPDU packets or how they envision it being used.

As I said I would set up the LAP with 2 switches with an LACP Lag setup using just cables then replace 1 cable with the link in your LAB and seeing how it behaves and playing with the settings in the radios.

Why you turn STP/RSTP OFF on switch ports facing APs (PTMP) is that there should be no reason for that device to become the root or for that path/port to ever be set to "blocking" and should always be forwarding. There are always situations where this would not be true such as an AD-HOC network topology where PTMP links can become root.

I see very few situations where STP/RSTP should ever be turned ON in radios but of course I could come up with one which is why many manufactures put that into the radios for those that would want it.

Apologies, I should have been clearer in my statement so you didn't have to write as much in reply.

I understand how STP works. I was merely trying to understand why disabling STP in this scenario made LACP work and then not.

I appreciate this is highly likely not a Netonix issue, however we only use Netonix switches and don't have the opportunity to test another manufacturers switch at present or in the near future. I was hoping another member of the forums had used LAG/LACP in the same scenario and/or with the same devices.

Have you ever tried using either UBNT or Mikrotik wireless devices to create a LAG/LACP group before? and before you reiterate it yes using LAG/LACP is not a good idea. If you have what devices did you use?

I really just want to get to the bottom of how and why this setup isn't working as it should and any ideas/experience anyone can throw in would be appreciated.

signa wrote:Have you ever tried using either UBNT or Mikrotik wireless devices to create a LAG/LACP group before? and before you reiterate it yes using LAG/LACP is not a good idea. If you have what devices did you use?

Did not mean to sound like I was being negative, I just answer so many posts, emails, PMs and such I tend to be direct.

Other users on this forum "say" they have used UBNT radio bridges with LACP LAGs with success but personally I do not use LACP with wireless bridges so my experience is not there, sorry.

You can use the search feature and look for some of those posts.

However my suggested LAB above would be the way I would proceed in testing LACP with wireless bridges.