• Link distance: 330m

• Device: RBSXTsqG-5acD

• Protocol used: 802.11

• Frequency: 5805

• RX signal: -59/-59

• TX power: 16 dBm both

• TX and RX rate: 400Mbps-40MHz/2S/SGI both

• rOS version: 6.48.1 on both

• SNR: 48dB

• CPU usage: around 10%

• Use only 20Mhz channels

• Use different channels

• Disable station-roaming (fixed other problems but not this)*

• Transmit at more power

• Transmit at less power

• Upgrade to 6.48.3 (no improvements on this direction)

• Remove wireless security

• Try different protocols

• Change antennas and radios

• Disable SGI

• Is it an expected behaviour and we're exagerating?

• Do you believe like us that it's a hardware/software problem more than a link configuration issue?

• Has anybody here experienced the same problem ever before?

• If so, does anybody has some clue about how to fix it? (apart from trying different devices)

What's in the LOG about those hiccups? (/system logging topics=wireless) . EG: Disconnect, reassociation, sending station leaving reason (1,3,8), excessive data loss, received deauth, group key exchange ..... etc etc etc

topics=!ssh,!snmp,debug action=disk 

19:51:58 route,debug,event Interface change 
19:51:58 route,debug,event     interface=wlan1 
19:51:58 route,debug,event     status=UP,RUNNING 
19:51:58 route,debug,event     mtu=1500 
19:51:59 route,debug,calc Begin calculation 
19:51:59 route,debug,calc End calculation 
19:52:02 route,debug,event Interface change 
19:52:02 route,debug,event     interface=wlan1 
19:52:02 route,debug,event     status=UP,RUNNING 
19:52:02 route,debug,event     mtu=1500 
19:52:02 route,debug,calc Begin calculation 
19:52:02 route,debug,calc End calculation 

If it not the wireless, next thing to check is the spanning tree. (STP,RSTP ...). Timing could correspond with a spanning tree transition, even triggered by some other device in the same broadcast domain.

"Interface change" as cause ?
Maybe other forum entries might help with ideas ... like: viewtopic.php?t=105456

Hello all,

We set up a link with a pair of SXT Sq AC (RBSXTsqG-5acD) covering a distance of 330m for serving some clients. After adjusting both units, selecting proper channels and frequencies we put this link on production with an overall CCQ above 90% (attaching a graph of gathered CCQs of the last 7 days). TX power in both units is below the maximum recommended for AC at MCS9 and RX signal is -58/-59 dBm. We monitored the spectrum and it seems we're the only ones on this channel, so link should not have any problems and work perfectly. Bandwith test shows a througput of about 200mbps. Not very worried about that.

Shot of CCQ graph:
mktik1.jpg

However, after some days in production we realised that the link losses some packets when it has moderate traffic (around 30mbits/second down and 4-5 up). This losses happen approximately every 2 minutes and only last for about 2-3 seconds. When there's no traffic, this doesn't happen. What surprises me more is the fact that not only icmp packets are lost, but all packets (even the ones causing the moderate traffic) and with a suspiciously stable periodicity and duration. Replicating this problem is not easy but yesterday I managed to catch a screenshot of this behaviour:

mktik2.jpg

The characteristics of this incident (like its periodicity and the complete loss of the links throughput) and the fact that all wireless metrics seem OK makes me think that it could be more a hardware/ software problem.

Sure it's not going to ruin the bussines, but for real time applications like videocalls or online gaming the truth is that bothers a bit.

I'm also attaching a /export of the whole configuration of both antennas and a "print advanced" output of both sides.

Some facts:

• Link distance: 330m

• Device: RBSXTsqG-5acD

• Protocol used: 802.11

• Frequency: 5805

• RX signal: -59/-59

• TX power: 16 dBm both

• TX and RX rate: 400Mbps-40MHz/2S/SGI both

• rOS version: 6.48.1 on both

• SNR: 48dB

• CPU usage: around 10%

Things we tried and fixed nothing:

• Use only 20Mhz channels

• Use different channels

• Disable station-roaming (fixed other problems but not this)*

• Transmit at more power

• Transmit at less power

* Station-roaming was causing a similar problem but even more constant and foreseeable. We disabled it and we got more stability but apparently was not enough.

Things we didn't try because we don't think are going to fix anything or have no sense (but we may be wrong)

• Upgrade to 6.48.3 (no improvements on this direction)

• Remove wireless security

• Try different protocols

• Change antennas and radios

• Disable SGI

So, some questions I would like to ask you:

• Is it an expected behaviour and we're exagerating?

• Do you believe like us that it's a hardware/software problem more than a link configuration issue?

• Has anybody here experienced the same problem ever before?

• If so, does anybody has some clue about how to fix it? (apart from trying different devices)

Thanks all,
Joan

EDIT: Also checked CPU usage and seems normal.

with redundant links using spanning tree for fast fail over (mostly 60ghz links with 5ghz backup).

If it was spanning tree or L2/L3 related, wouldn't it happen even without traffic on the wireless link?

Thanks for your answer.

Yesterday I managed to replicate the event. Made a bandwith test up, down and both. Things get interesting because it seems to only happen when the traffic is on both TX and RX.
Replying in lines:

What's in the LOG about those hiccups? (/system logging topics=wireless) . EG: Disconnect, reassociation, sending station leaving reason (1,3,8), excessive data loss, received deauth, group key exchange ..... etc etc etc

Nothing. Activated debug logs with:

Code: Select all

topics=!ssh,!snmp,debug action=disk 

I managed to replicate the event and only one message was shown. In addition this message did not apear all times:

Code: Select all

19:51:58 route,debug,event Interface change 
19:51:58 route,debug,event     interface=wlan1 
19:51:58 route,debug,event     status=UP,RUNNING 
19:51:58 route,debug,event     mtu=1500 
19:51:59 route,debug,calc Begin calculation 
19:51:59 route,debug,calc End calculation 
19:52:02 route,debug,event Interface change 
19:52:02 route,debug,event     interface=wlan1 
19:52:02 route,debug,event     status=UP,RUNNING 
19:52:02 route,debug,event     mtu=1500 
19:52:02 route,debug,calc Begin calculation 
19:52:02 route,debug,calc End calculation 

I doubt this is a "cause message" but a consequence of the error.

If it not the wireless, next thing to check is the spanning tree. (STP,RSTP ...). Timing could correspond with a spanning tree transition, even triggered by some other device in the same broadcast domain.

If it was spanning tree or L2/L3 related, wouldn't it happen even without traffic on the wireless link?