Lots of RX errors on AP530

[J Vesterdahl]

Hello.

After upgrading my AP530s to software 2.15 and PCM+ to version 2.3, the Errors/sec frequently maxes out caused by one of the AP530s with external antenna (I mostly use the internal antennas). When I check the Traffic panel for the AP in question, I get the message "Sampling OK" or "Sample hijack" every time the max happens. What does this mean? I don't know if this is an error or some bad setting. The word "hijack" certainly does not sound healthy in a wireless world.

[J Vesterdahl]

This happens even when both radios in the AP are disabled ...
Weird, that!

[Steve Britt · Accepted solution]

Hi J,

The traffic collector in PCM 2.3 is only capable of distinguishing devices as sFlow-capable on a per-device basis, which means it sees either all interfaces on a device as being able to support sFlow or no interfaces on a device as being able to support sFlow. On recent AP530s the reality is that the radios support sFlow but the Ethernet ports do not (on older AP530 firmware no sFlow at all was supported). So what's happening is that the sFlow logic is trying to set up sampling on the Ethernet port but can't do it. However, the error statuses returned back from the AP530 indicate that the setup of the sFlow MIB worked OK for the Ethernet port (leading to the "Sampling OK" status, which is a transient status). Later, after about 10 minutes or so have passed in this "OK" state and the collector has received no samples it assumes that someone has "hijacked" its sFlow ports out from under it because as far as it knows it successfully set up the Ethernet ports for sampling and that is the most likely reason that it wouldn't have gotten samples for such an unreasonably long period of time after a successful configuration of sFlow.

To eliminate this error, manually configure traffic monitoring on the Ethernet ports so that is doesn't attempt to gather sFlow from these ports. Right-mouse on an Ethernet port, select the "Manual" submenu, and then select "Manually enable statistics" on the port. This will restrict the further collection of data from this port to polling the ifMIB counters, and if sFlow is later invoked on the radios everything should work fine because sFlow will no longer be attempted on the Ethernet ports.

Note that a utilization metric will not be shown for the radios of the AP530 irrespective of what collection method is used. This is because of the variable bandwidth available depending upon the distance between client and radio, which prevents utilization from being computed in the same manner as wired ports that have a fixed bandwidth. Our thought is that a truer measure of utilization would be the percentage of time that a radio is transmitting no matter what speed was being used; an enhancement request to provide this metric for radios is on our wish list for future releases.

Regards,

SVB

[J Vesterdahl]

Turns out it was "wlan0" that needed manual stats config on both APs so far.
Looks like that did it - and the explanation made sense. Thanks.