Nv2 Troubleshooting

What it is

Troubleshooting Nv2 means finding why a link will not form, or why it is slower or less stable than expected.

Because Nv2 is a schedule controlled by the access point, many faults come from settings that do not match, or from timing that does not fit the distance. The ordinary radio checks still apply, so signal and noise matter as much as before.

A calm method that works from the simplest cause to the hardest saves time.

How it works

You check that the ends match, then the radio path, then the timing, and change one thing at a time.

Step 1: the link does not form

If a station never appears in the registration table, check the basics first:

A mismatch in any of these can keep the link down. Compare the two configurations line by line.

/interface wireless print detail where name=wlan1

Step 2: the cell radius

If near clients work and far clients do not, suspect the cell radius. When it is smaller than the distance to the farthest client, signals from that client arrive late. Raise the nv2-cell-radius on the access point to cover it.

If all clients connect but the throughput is lower than expected, the cell radius may be far larger than needed. That wastes guard time. Set it to the real distance, with a small margin.

Step 3: signal and noise

An Nv2 link still depends on the radio path. Check the registration table:

/interface wireless registration-table print detail

Look at the signal strength, the TX signal strength, the signal to noise and the rates. For 802.11n hardware, also check the signal on each chain, as in the 802.11n chapter. A weak chain limits the stream count and the rate.

If the signal is poor, look at the antennas, the cables, the alignment and the distance. If the signal is fine but the rates are poor, look for interference with the scan and the frequency monitor.

Step 4: throughput

When the link is up and the signal is good but the speed is low, test it:

/tool bandwidth-test address=192.168.88.2 direction=both

Compare the result with the data rate. Then look at these causes:

• The channel width is narrower than planned.
• Many clients share the same schedule, so each gets a smaller share.
• The CPU of one of the devices is overloaded.
• The priority settings give a flow less than you expect.

Step 5: traffic classes

If voice or other important traffic has high delay while bulk traffic is fine, check the QoS settings. With nv2-qos=frame-priority, the packet priority decides the queue. If no rule sets the priority, all traffic lands in the default class.

Check the firewall rule that sets the priority, and check the queue count on both ends.

Step 6: stability

If the link drops and recovers, check these:

• Interference that comes and goes, as shown by the spectral history where the card supports it.
• A marginal signal that falls at times, for example because of weather, trees or moving objects.
• A power supply problem that reboots the device.
• A change of frequency caused by a feature such as radar detection on the channel.

A compact method

• Confirm that both ends are on the same protocol, SSID, band and security.
• Confirm that the cell radius covers the farthest client.
• Check the signal, the noise and the chains.
• Test throughput in both directions.
• Check the traffic classes if only some traffic suffers.
• Change one setting at a time, and record the result.

What to avoid

Do not copy settings from a different site without checking the distance and the clients. Do not raise the cell radius to a very large value as a general cure. It hides the real cause, and it lowers throughput.