User's Manual

Troubleshooting MP.11 4954-R Installation and Management
Link Problems
155
Link Problems
While wireless networking emerges more and more, the number of wireless connections to networks grows every day.
The Tsunami MP.11 unit is one of the successful product families used by customers today who enjoy the day after day
high-speed, cost-effective connections. To successfully use the connections, technicians must be able to troubleshoot
the system effectively. This section gives hints on how a unit network could be analyzed in the case of “no link,” a
situation in which the customer thinks that the link is down because there is no traffic being passed.
The four general reasons that a wireless link may not work are related to:
• Hardware
• Configuration
• Path issues (such as distance, cable loss, obstacles)
• Environment (anything that is outside the equipment and not part of the path itself)
You have tested the equipment in the office and have verified that the hardware and configurations are sound. The path
calculation has been reviewed, and the path has been double-checked for obstacles and canceling reflections. Still, the
user reports that the link does not work.
Most likely, the problem reported is caused by the environment or by improper tests to verify the connection. This article
assumes that the test method, cabling, antennas, and antenna alignment have been checked. Always do this before
checking the environment.
General Check
Two general checks are recommended before taking any action:
• Check whether the software version at both sides is the most current
• Check for any reported alarm messages in the Event Log
Statistics Check
Interference and other negative environment factors always have an impact on the number of correctly received frames.
The Tsunami MP.11 models give detailed information about transmission errors in the Web interface, under Monitor.
The windows that are important for validating the health of the link are:
• Monitor / Wireless / General (Lowest level of the wireless network): Check FCS errors: Rising FCS errors
indicate interference or low fade margin. So does Failed count. If only one of those is high, this indicates that a
source of interference is significant near one end of the link.
• Monitor / Interfaces / Wireless (One level higher than Wireless / General): The information is given after the
wireless Ethernet frame is converted into a normal Ethernet frame. The parameters shown are part of the MIB-II.
– Both operational and admin status should be up. An admin status of down indicates that the interface is
configured to be down.
– In Discards and Out Discards indicate overload of the buffers, likely caused by network traffic, which is too
heavy.
– In Errors and Out Errors should never happen; however, it might happen if a frame’s FCS was correct while the
content was still invalid.
• Monitor / Wireless / WORP (Statistics on WORP): WORP runs on top of normal Ethernet, which means that the
WORP frame is in fact the data field of the Ethernet frame. Send Failure or Send Retries must be low in comparison
to Send Success. Low is about 1%. The same applies for Receive Success versus Receive Retries and Receive
Failures. Note that the Receive Failures and Retries can be inaccurate. A frame from the remote site might have
been transmitted without even being received; therefore, the count of that frame might not have been added to the
statistics and the receiver simply could not know that there was a frame.