Poor connectivity to remote resource through bridge due to slow throughput

[TCC_2]

Introduction

Connection to a resource on the far side of a bridge has slow throughput.

Resolution

If you are experiencing slow throughput,i.e. you can connect to remote resources, but the connection is slow, check the following to help isolate your problem;
Version of software on bridge

Use bridge software statistical tools to check throughput and error statistics.

Poor Throughput

Problems with bridge performance are the most difficult to troubleshoot because there are so many variables involved. In the case of wireless products, the majority of variables are literally invisible. Bridges have tools built into their software that can help to accurately determine the cause of symptoms of poor throughput, but they might not be able to solve the underlying problem. As a basic approach to troubleshoot this problem, you can increase the transmit power on the non-root bridge. Also, if the distance between the root and non-root bridge is less than 1km, you can set the distance on the root bridge to 1. Therefore, an increased throughput can be obtained.

Remember that the IEEE 802.11b protocol specifies 11 megabits per second, half-duplex, wireless communications. Set your throughput expectations accordingly.

Software

The first step to troubleshoot any problem is to check the version of the software on the bridge.

Use a Telnet session to log into the bridge and issue the show version EXEC command in order to find the version of Cisco IOS® software that runs on your bridge. This example shows command output from a bridge that runs Cisco IOS Release 12.2(13)JA2:

bridge> show version

Cisco Internetwork Operating System Software IOS (tm) C1410 Software (C1410-K9W7-M), Version 12.2(13)JA2 Copyright (c) 1986-2003 by Cisco Systems, Inc.

You can also find the software version on the System Software Version page in the web-browser interface of the bridge.

Start at the Wireless Software Center and choose the model of bridge with which you work. Compare your current version with the highest numbered version of bridge software listed. If you do not run that latest version, upgrade to the latest version in order to start to resolve your throughput issue. Refer to Managing Firmware and Configurations for more information on how to upgrade bridge firmware.

Use Statistical Tools

Bridge software provides tools to show you the types of problems and where the bridge encounters the problems. Two of the most helpful tools are the Throughput Statistics and the Error Statistics windows. In the entire wireless network, there are at least two bridges involved, and it is important to look at statistics from both sides (wired and wireless) of all bridges when you try to isolate a problem. Statistics are only relevant over time, and only when you have some benchmark for comparison. Comparing statistics from two associated bridges clearly shows if the problem is on one side or both.

Throughput Statistics

You need to look at both sets of Throughput Statistics in order to begin. Complete these steps

• Navigate to the Statistics page.

This varies and depends on the bridge model.

This document explains the procedure to get to the Statistics page on a 340 Series Bridge that runs VxWorks operating system.

• Choose Statistics from the Main menu once the connection is established to the bridge.

The Statistics menu provides a broad array of information about the performance of the bridge.

• Complete the procedure from Viewing Statistics in order to get to the Throughput Statistics page.
• Clear the statistics on both bridges at the same time so the time factor of the statistics is similar.

Note: Press C (as provided at the bottom of the Throughput Statistics page) in order to clear the Throughput Statistics.

• Clear and review the statistics several times over the course of a day, or several days, in order to recognize and understand the individual traffic patterns in a given network.

The traffic pattern flows in this sequence

1. In the Ethernet side of bridge A
2. Out the radio side of bridge A
3. In the radio side of bridge B
4. Out the Ethernet side of bridge B

• Verify that the radio of one bridge successfully transmits all the packets it receives from its Ethernet.

For example, if the Bridge Receive packet count is 1000, verify that the Radio Transmit packet count is somewhat close to 1000.

Note: If the bridge is connected to a hub, the two values might not be close because the hub is a broadcast device and sends the bridge all of the traffic that it receives. However, if the bridge is connected to a switch, the two values should be approximately equal.

• Compare the Radio Transmit packet count on bridge A to the Radio Receive packet count on bridge B.

If the transmit count of bridge A is higher than the receive count of bridge B, then packets are lost over the radio link. This loss is likely caused by one of these problems:

• The signal is not strong enough for the packets to make it to the far side.
• The packets are destroyed by some outside interference.

If the receive count of bridge B is higher than the transmit count of bridge A, then additional signals are received. The bridge interprets these as packets. This interference is likely caused by one of these problems:

• A nearby 2.4 GHz device, such as 2.4 GHz cordless phone, transmits on the same frequency.
• A nearby microwave oven that leaks sends signals on the same frequency.

Note: The Statistics page on a 1400 Series Bridge that runs Cisco IOS looks similar to this diagram:

Error Statistics

Refer to Error and Event Messages for more information on the definitions and implications of each type of error on the Error Statistics report. This document is based on the 1400 Series Bridge.

Error Statistics on the Cisco Aironet 340 Series Bridge

While the wired Ethernet side can be full-duplex, the radio side is not. Therefore, when the radio has a packet to transmit, it does not do so while another radio transmits on the same channel or frequency. When this situation occurs, the Holdoffs Statistic counter-increments. When the bridge continues to receive packets in the Ethernet interface, but is unable to transmit them over the radio interface due to holdoffs, the buffers designed to hold those outbound packets fill very quickly. This depends on traffic flow and volume. When those buffers overflow, the excess packets are discarded, and the Queue Full Discards Statistic counter-increments. You might see messages displayed on the console of the bridge or in the error log.

When the radio of a bridge transmits a packet, the receiving bridge must send an ACK back to the transmitting bridge so that the transmitting bridge can move on to the next packet in its transmit queue. If the transmitting bridge does not receive that ACK, it transmits that same packet again until it receives an ACK from the receiving bridge. When a bridge transmits the same packet more than once, the Retries Statistic counter-increments. You can assume one of these situations is true:

The receiving bridge did not send the ACK.

The ACK is sent, but is not received by the transmitting bridge. Therefore, the transmitter had to resend the packet.

All of these statistics indicate a problem with successful transmission over the radio link and do not indicate a failure of the physical hardware.

Problem Type

Associated but cannot pass traffic to some devices

Poor connectivity / Performance

Products

Bridge

Reference

Poor Throughput

Intermittent Connectivity Issues in Wireless Bridges