Guest

My Cisco
Click to open
Click to close
Easily access your personalized content anywhere on Cisco using My Cisco.
Click to open
Click to open
Click to close
Easily access your personalized content anywhere on Cisco using My Cisco.
Click to open

Cisco Aironet Antennas and Accessories

Intermittent Connectivity Issues in Wireless Bridges

Document ID: 66090



Introduction

This document explains some of the main reasons for intermittent connectivity issues with wireless bridges, and how to resolve these issues.

Prerequisites

Requirements

Cisco recommends that you have some basic knowledge of wireless bridges.

Refer to Wireless - Technical Support & Documentation for more references on wireless bridges.

Components Used

The information in this document is based on Cisco Aironet Wireless bridges.

Conventions

Refer to Cisco Technical Tips Conventions for more information on document conventions.

Reasons for Intermittent Connectivity Issues in Wireless Bridges

Here are the common reasons for intermittent connectivity issues in wireless bridges:

  1. Radio Frequency Interference

  2. Sub-optimal/Incorrect Data Rate Settings on the Wireless Bridges

  3. Fresnel Zone and Line of Sight Issues

  4. Problems with Antenna Alignment

  5. Clear Channel Assessment Parameter (CCA)

  6. Other Issues that Degrade the Performance of Wireless Bridges

Radio Frequency Interference

Radio Frequency Interference (RFI) involves the presence of unwanted interfering RF signals that disrupt the original data signals from wireless devices. RFI in a wireless network can lead to adverse effects, for example, intermittent connectivity loss, poor throughput, and low data rates. There are different types of RFI that can occur in a wireless network environment, and you must tale these RFI types into consideration before you implement wireless networks. RFI types include narrowband RFI, all-band RFI, and RFI due to adverse weather conditions.

  • Narrowband RFI—Narrowband signals, depending on the frequency and signal strength, can intermittently interrupt or even disrupt RF signals from a spreadspectrum device, such as a wireless bridge. The best way to overcome narrowband RFI is to identify the source of the RF signal. You can use Spectrum analyzers to identify the source of the RF signal.

    Spectrum analyzers are devices that you can use to identify and measure the strength of interfering RF signals. When you identify the source, you can either remove the source to eliminate RFI, or shield the source properly. Narrowband signals do not disrupt original data RF signals (from a wireless bridge) across the entire RF band. Therefore, you can also choose an alternate channel for the bridge where no narrowband RF interference occurs. For example, if unwanted RF signals disrupt one channel, say channel 11, you can configure the wireless bridge to use another channel, say channel 3, where there is no narrowband RFI.

  • All-band RFI—As the name suggests, all-band interference involves any unwanted RF signal that interferes with the data RF signal across the entire RF band. All-band RFI can be defined as the interference that covers the whole spectrum that the radio uses. The entire RF band does not point to the ISM band alone. The RF band covers any band of frequencies that the wireless bridges use.

    A possible source of all-band interference that you can find commonly is a microwave oven. When all-band interference is present, the best possible solution is to use a different technology, for example, move from 802.11b to 802.11a (which uses the 5Ghz band). Also, the whole spectrum that the radio uses is 83.5 MHz in FHSS (the whole ISM band), while for DSSS it is only 20 MHz (one of the sub-bands). The chances of an interference that covers a range of 20 MHz are greater than the chances of an interference that covers 83.5 MHz. If you cannot change technologies, try to find and eliminate the source of the all-band interference. However, this solution can be difficult, because you have to analyze the entire spectrum to track the source of the interference.

  • RFI Due to Adverse Weather Conditions—Severely adverse weather conditions, for example, extreme wind, fog, or smog can affect the performance of wireless bridges, and lead to intermittent connectivity issues. In these situations, you can use a radome to protect an antenna from the environmental effects. Antennas that do not have radome protection are vulnerable to environmental effects, and can cause degradation to the performance of the bridges. A common problem that can occur if you do not use the radome is the one due to rain. Raindrops can accumulate on the antenna and affect performance. Radomes also protect an antenna from falling objects, such as ice that falls from an overhead tree. With the Cisco Outdoor Bridge Range Calculation Utility, you can choose your climate and terrain, and the program compensates for any degradation in weather.

CRC, PLCP errors

CRC errors and PLCP errors can occur due to Radio Frequency interference. The more radios a cell has (APs, Bridges or Clients), the more are the chances of the occurrence of these errors. A cell means a single channel (for example, channel 1) or a channel that overlaps the channel. Radio interfaces are half duplex. Therefore, radio interfaces are just like collision messages on Ethernet. Here are some reasons for the occurrence of CRC errors:

  • Packet collisions that occur due to a dense population of client adapters

  • Overlapping access point coverage on a channel

  • High multipath conditions due to bounced signals

  • Presence of other 2.4-GHz signals from devices like microwave ovens and wireless handset phones

Wireless is a more open medium than wired networks, and is subject to environmental effects. The radio waves bounce off surrounding objects, which can create a weaker or broken signal. This happens with cell phones, FM radios, and other wireless devices. The more 802.11 radios and clients are in a cell area, higher is the contention level and the potential for retries and CRC errors. The same applies to wired segments.

CRC and PLCP (Physical Layer Control Protocol) errors are normal when traffic flows through the AP. You do not need to consider these errors to be an issue unless the number of errors is very large. Here are some parameters you must check if there is a large number of CRC errors:

  1. Line of Sight (LOS)—Check the LOS between the transmitter and the receiver, and ensure that the LOS is clear.

  2. Radio Interference—Use a channel that has lower radio interference.

  3. Antennas and Cables—Ensure that the antennas and cables are appropriate for the distance of the radio link.

Cisco recommends a site survey in order to minimize these errors. Refer to Performing a Site Survey for more information on Site Survey.

Use the Carrier Test Option in Bridges to Check for RFI

Cisco wireless bridges can also analyze different channels to detect RFI. The carrier busy test helps to view the activity in the RF spectrum. The carrier busy test is available on bridges, and enables you to view the radio spectrum. Figure 1 shows the carrier busy test on the BR500. The numbers 12, 17, 22, and so on represent the 11 frequencies that the bridge uses. For example, 12 represents the frequency 2412 MHz. The asterisk (*) indicate the activity on each frequency. Whenever possible, choose the frequency with the least activity to reduce chances of interference. Refer to Performing a Carrier Busy Test for more information on how to perform Carrier Test.

Figure 1 – Carrier Busy Test on the BR500

CarrierTest.gif

Sub-Optimal/Incorrect Data Rate Settings on the Wireless Bridges

Wireless bridges can run into connectivity issues if you configure the bridges with sub-optimal or incorrect data rate settings. If you configure the data rates incorrectly on wireless bridges, the bridges fail to communicate. A typical example is a scenario where one of the bridges is configured for a fixed data rate, for example, 11 Mbps, and the other bridge is configured with a data rate of 5 Mbps.

Normally, the bridge always attempts to transmit at the highest data rate set to basic, also called "require", on the browser-based interface. In case of obstacles or interference, the bridge steps down to the highest rate that allows data transmission. If one of the two bridges has a data rate of 11 Mbps set, and the other is set to "use any rate", the two units communicate at 11 Mbps. However, in case of some impairment in the communication that requires the units to fall back to a lower data rate, the unit set for 11 Mbps cannot fall back, and communications fail. This is one of the most common problems that relate to data rates. The workaround is to use optimized data rate settings on the two wireless bridges.

You can use the data rate settings to set up the bridge to operate at specific data rates. For example, in order to configure the bridge to operate at 54 Mbps service only, set the 54 Mbps rate to basic, and set the other data rates to enabled. In order to set up the bridge to operate at 24, 48, and 54 Mbps, set 24, 48, and 54 to basic, and set the rest of the data rates to enabled. You can also configure the bridge to set the data rates automatically to optimize either range or throughput. When you enter a range for the data rate setting, the bridge sets the 6 Mbps rate to basic and the other rates to enabled. When you enter throughput for the data rate setting, the bridge sets all data rates to basic. Refer to Configuring Radio Data Rates for more information on how to optimize the data rate settings.

Fresnel Zones and Line of Sight Issues

Line of Sight (LoS) is an apparent (invisible) straight line between the transmitter and receiver. In the case of wireless bridges, the LoS is between the two antennas that connect the bridges, for example a root bridge and a non-root bridge. The RF LoS is an apparent straight line because RF waves are subject to changes in direction due to various factors that include refraction, reflection, and diffraction. The problem is that Fresnel Zones can affect RF LoS. In such a scenario, the connectivity between the bridges can be intermittent, and in some cases, can lead to complete loss of connectivity between the bridges.

The Fresnel Zone is an elliptical area immediately surrounding the visual path. The Fresnel Zone varies depending on the length of the signal path and the frequency of the signal. A clear line of sight, with Fresnel Zone margin, indicates that the path has no obstructions that can affect the signal. Fresnel Zones are important, and you need to consider these zones before the implementation of any wireless bridged network. Any objects in the Fresnel Zone can interfere with the RF signal, which affects the signal, and causes a change in the LoS. These objects include trees, hills, and buildings.

Fresnel zones are frequency dependent. A frequency of 5.8GHz is used in the bridge utility calculations. Refer to the Fresnel Zone section of the Cisco Aironet 1400 Series Wireless Bridge Deployment Guide for technical details on fresnel zone clearance.

Figure 2 – Fresnel Zone

fresnel-zone.gif

In order to resolve these issues, make sure that there is visual and radio LoS between the root and non-root bridges. Check to ensure that nothing obstructs the Fresnel Zone. Sometimes, you need to raise the antenna height in order to clear the Fresnel Zone. If the bridges are more than six miles apart, the curvature of the earth encroaches on the Fresnel Zone. Refer to the Outdoor Bridge Range Calculation Utility for additional assistance.

Problems with Antenna Alignment

Antenna alignment directly relates to the proper LoS between the two bridges. In case of proper alignment of the antennas, the RF LoS between the devices is clear and connectivity problems do not occur. When you use directional antennas to communicate between two bridges, you must manually align the antennas for proper bridge operation. Directional antennas have greatly reduced radiation angles. The radiation angle for yagi antennas is approximately 25 to 30 degrees, and for parabolic dish antennas, the radiation angle is approximately 12.5 degrees. You can use the bridge link test to help measure the alignment of two antennas after the bridges are associated. The association indicates the antennas point in the general vicinity of each other, but does not indicate proper alignment of antennas. The link test provides information you can use to gauge the alignment.

Typically, when two antennas are aligned to the edges of their radiation patterns, communication can be marginal, as packets are lost, retry counts are high, and signal strength is low. However, when two antennas are properly aligned, communication improves, and all packets are received, retry counts are lower, and signal strength is high. Refer to the Basic Antenna Alignment section of Antenna Basics for information on basic antenna alignment, and for instructions on how to perform link tests.

Clear Channel Assessment Parameter (CCA)

CCA is essentially the establishment of a noise floor below which it ignores RF inputs, in search of a good, solid signal. With the programmable CCA feature, wireless bridges can be configured to a particular background interference level found in a specific environment, for reduced overhead contention with other wireless systems.

A CCA threshold can decrease the receiver sensitivity by changing the absolute receive power level above which the channel is normally considered busy. The default value of the CCA parameter is 75. However, you can increase the CCA threshold to reduce noise in environments. CCA values can be set independently for root and non-root bridges.

There might be intermittent connectivity loses with wireless bridges if the CCA value is not configured correctly. Ensure that the CCA value is not set to zero and is set to the value close to the default value of 75 if not the default value. Wireless bridges that run Cisco IOS® Software Releases earlier than 12.3(2)JA hit a bug which changes the default CCA value to zero upon reboot of the device. Refer to Cisco bug ID CSCed46039 (registered customers only) for more information on this bug and the workaround.

Other Issues That Degrade the Performance of Wireless Bridges

The materials that the RF signal can penetrate can determine the performance of the wireless bridge. The density of the materials used in the construction of a building determine the number of walls the RF signal can pass through and still maintain adequate coverage. Material impact on signal penetration are:

  1. Paper and vinyl walls have little effect on RF signal penetration.

  2. Solid and pre-cast concrete walls limit signal penetration to one or two walls without degrading coverage.

  3. Concrete and concrete block walls limit signal penetration to three or four walls.

  4. Wood or drywall allows for adequate signal penetration for five or six walls.

  5. A thick metal wall causes signals to reflect off, resulting in poor signal penetration.

  6. Chain link fence and wire mesh with 1 to 1½" spacing act as ½" waves that block a 2.4 GHz signal.

  7. When you deploy a wireless bridge link through a window, the window glass can introduce significant signal loss. Typical losses range from 5 to 15 dB per window, depending upon the type of glass. Your deployment plan must take this extra loss into account conservatively when you plan antenna gains and power settings.

  8. Disable Concatenation on the bridge. Concatenation is the process where multiple packets are aggregated into a single packet to increase the throughput. When the bridge connects to a low speed link on the wired side this poses a problem. Issue this command in order to disable concatenation.

    bridge(config)#interface dot11radio0
            bridge(config-if)#no concatenation.
  9. Wireless bridges can experience intermittent connectivity problems or total loss of connectivity if there is loose connectivity between the cables that connect the wireless bridges to the power injector and the antenna. As a first step, check if the cables are connected properly. This especially helps in cases where the wireless bridges were working previously but suddenly lost connectivity.

  10. CCA is essentially the establishment of a noise floor below which it ignores RF inputs, in search of a good, solid signal. With the programmable CCA feature, wireless bridges can be configured to a particular background interference level found in a specific environment, for reduced overhead contention with other wireless systems. A CCA threshold can decrease the receiver sensitivity by changing the absolute receive power level above which the channel is normally considered busy. The default value of the CCA parameter is 75. However, you can increase the CCA threshold to reduce noise in environments. CCA values can be set independently for root and non-root bridges. There might be intermittent connectivity loses with wireless bridges if the CCA value is not configured correctly. Ensure that the CCA value is not set to zero.

Before you implement a wireless network, make sure that you understand the behavior of RF waves through the different materials.

Cisco Support Community - Featured Conversations

Cisco Support Community is a forum for you to ask and answer questions, share suggestions, and collaborate with your peers. Below are just some of the most recent and relevant conversations happening right now.

Want to see more? Join us by clicking here
  • WAP4410N - Losing connectivity...cspgfphilly3 Replies2 years, 5 months ago
    I just bought two WAP4410N's and I was going to use them as a wireless bridge.  I put them about 100 feet apart, configured them as a wireless bridge and I was able to ping across the wireless to the device on the other I needed to access. I thought this was going to be a great solution.  Then about 15 minutes later, I lost connectivity to the far side.  I reset both devices and it came back up for a short time, and then it went down again.  Both devices are still powered up but the wireless point to point link goes down.  Is this a bug or some sort?  Anyone have any idea?
    • Re: WAP4410N - Losing connectivity...rjayasee2 years, 7 months ago
      Check for the antenna alignment between the bridges. Use the alignment utility for best signal reception. For further troubleshtooing refer the document Intermittent Connectivity Issues in Wireless Bridges on cisco.com.
    • Re: WAP4410N - Losing connectivity...accuitdept2 years, 5 months ago
      I am getting the exact same issue.  Figured you found out what the fix was since there have not been any more postings.  Please help.  This thing is a thorn in my side right now. Have been through the support and got both replaced with brand new units and still same thing. Just went down this morning and it will not come back up.  Guess it is time for another drive out there. Tom in NJ
      • Re: WAP4410N - Losing connectivity...cspgfphilly2 years, 5 months ago
        No I never did figure it out.  I returned them... I called support and they basically had no answers.  They offered me the replacement as well but since they were a few days old I went the RMA route.  I went with Netgear WG102's and have been very happy with them.
  • Overlappingjorge.s8 Replies5 years, 2 months ago
    Hi, how do I dettect, only accessing the Access Points, if a certain access point is having interferences due to the use of another channel by another access point, but which is overlapping the used one? Jorge
    • Re: Overlappingrobert.wright@bmwfs.com5 years, 2 months ago
      Jorge! Long time no talk ;) Come to ohio my friend so we can chat about wireless over a few beers ;) Maybe get rob to come down as well =p Anyways i am not fully understanding your question(s). I am going to treat it as if you asked a two part question. Q. How do you tell if your having interference? A. Issue the following command, "show interfaces dot11Radio 0 statistics". Take note of "CRC errors". Likly you have never cleared...
      • Re: Overlappingjorge.s5 years, 2 months ago
        Hi Robert, in fact I would not mind to join you in Ohio, I'm leaving in Portugal, but working accross Europe, and the problem I'm having is in this case, in Belgium. Sometimes de Wireless Devices just get de-associated from the WLAN, and we cannot connect to them anymore (in fact, Linksys Wireless Bridges). I've done like you described, and yesterday I cleared the counters, today when I look at it I find that there are some CRC errors. Do...
        • Re: Overlappingscottmac5 years, 2 months ago
          I think I'd start looking at the clients. Obviously, some clients are getting through with good traffic, others, I believe, are sending incompatible or self-mutilating traffic. Self-mutilating would be a client carrying something like Bluetooth or two wireless NICs concurrently. There are also some bad drivers. Earlier versions of te Intel BG2200 drivers would send (what was interpreted as) MIC errors and cause the AP to shut down (per...
    • Re: Overlappingjohnruffing@suntel.com5 years, 2 months ago
      Ekahau Site Survey tool can measure the RF from the access points in question and plot the areas on the floorplan where the interference is ocurring. http://www.ekahau.com This allows you to adjust your power / channel settings and/or add another AP on a different channel in the area where the interference is being shown on the floorlan.
      • Re: Overlappingrobert.wright@bmwfs.com5 years, 2 months ago
        Your CRC errors look fine, but your header crc's appear to be through the roof. Now CRC errors i know theres the direct relationship with radio interference. The header CRCs are related to some sort of layer 1 problem. But sadly thats all i know... I am going to have to ask Rob or one of the other fellas... This is purely my personal troubleshooting of what i would attempt to do. This is by no means a 'how you fix the issue'... I...
        • Re: Overlappingrob.huffman5 years, 2 months ago
          Hey Guys, I would love to join you for a beer (Bengals or Browns?). I appreciate the nice vote on this, but I am an idiot when it comes to trying to break down these type of errors (THINK EYES GLAZED OVER LOOK). I think that they really just indicate some sort of RF interferance,antenna alignment,or channel overlap issues. Have a look at his guide that relates to problems with Cisco Bridges; Reasons for Intermittent Connectivity Issues in...
  • Is 200m too long..experience some...DMobley102210 Replies3 years, 7 months ago
    In one of my setups, I have about 200m length of Cat5e from the phone directly to a cisco 3560. The phone is having intermittent issues. Sometimes the quality of the call is bad, and the call usually gets dropped a few times. I'm being told that even though 100m is the max length of Cat5e, that 200m is fine? Would you do this? What can I do to improve call quality?
    • Re: Is 200m too long..experience some...rob.huffman3 years, 7 months ago
      Hi Dustin, The standard 100m ethernet rules (90m drop + 10m patch/cross connect) still apply here and this 200m length is almost surely causing these issues. If you try to test a 200m cable run with a "Fluke" type test meter you will see many problems. This length can only run an Analog/FXS circuit :( Check out Page 29; The maximum lengths of horizontal distribution cables are shown in the following table. Table 4.1: Cable lengths...
      • Re: Is 200m too long..experience some...DMobley10223 years, 7 months ago
        Is there any type of equipment cisco has that will amplify this signal, would putting another switch in between help? Thanks that is a lot of help. I'm sure that is what the issue is, and then when you also add that we are running the internet over the same, and the internet we have is usually about 1.5 down and 512 up, it probably just adds to the problem. Its an office with 8 other phones as well, but this one phone just happens to be about...
        • Re: Is 200m too long..experience some...rob.huffman3 years, 7 months ago
          Hi Dustin, I like your thinking here! Your only real alternative is to setup a "mid-point" switch of some sort. The 90m rule is always the guideline we have to work within. Take care, Rob
          • Re: Is 200m too long..experience some...DMobley10223 years, 7 months ago
            We just tested the phones with a Fluke Meter and the wiring is A OK! The phones will power up, but just display Ethernet disconected. The distance is about 210m. So I'm thinking my problem is with distance. I will call our cisco rep and see about getting a mid-point switch. My question though in that regards is this. The only place to install that switch is at about 200m point. Do you think that would still cause the phones to work...
            • Re: Is 200m too long..experience some...rob.huffman3 years, 7 months ago
              Hi Dustin, As long as the new switch (mid-point) is within 90m of the IP Phone you should be good to go :) Hope this helps! Rob
            • Re: Is 200m too long..experience some...sushil.katre@wipro.com3 years, 7 months ago
              Hi Dustin, Are you saying this - Existing Switch --- 200mts --- new switch -- IP Phone? If the connectivity between the switches is Copper then again the 90 mts rule applies. The option that you have is to have a fiber connectivity between the swiches and then a copper connectivity between new switch & IP Phone. Or else instead of inventing on a new switch why don't you look for some media converter which can convert fiber...
    • Re: Is 200m too long..experience some...DMobley10223 years, 7 months ago
      We were able to get a temp solution to work. We configured the ports that these phones were plugged into to : Half Duplex 10mpbs and now the phones are working.
    • More Replies
  • 1310 WBR-Intermittent connectivity CRC...K-Herod1 Reply4 years, 10 months ago
    A wireless bridged site is intermittantly losing voice and data connectivity between the Aironet 1310 bridge and the switch at that location. The wireless connection between buildings is always on. When doing the show CDP neighbor command on the remote bridge, it may or may not show the connected switch. The Aironet IOS was upgraded on both wireless bridges today and the problem continues!
    • Re: 1310 WBR-Intermittent connectivity...thomas.chen4 years, 10 months ago
      Check for any physical connectivity flops in your network. Bcoz, intermittent conncectivity mainly occurs due to loose cabling (between your bridge and switch). Also, send me the show output of radio and ethernet interface. From that, I need to check for any interface reset errors occured. Interface reset occurs if the devices or the attached interfaces reboot. Also send the output of show cdp neighbor.
  • Connectivity Issues with 1400 Wireless...venom432127 Replies2 years, 9 months ago
    Just seeing if anyone has run into a similar problem....I have two 1400 outdoor wireless bridges. They have been in place for a couple of years without issue. This past week, the non-root bridge began dropping it's association, at first randomly, then consistently. Both bridges have been replaced, antennas (AIR-ANT58G10SSA-N) on both have been replaced, and a spectrum analyzer has been used to verify there is not a problem over the air...the ditance between the two is >=1000 feet. Debugs show no reason for the drop, and when the two are asscoaited, the RSSI is averaging around -78. It had been down since Thursday, then last night, as another step in the process of elimination, we replaced the power injector on the root side, and the two bridges associated. They were up for two hours, then went down again, and then started going up and down randomly. As an additional step in the process of elimnation, we are now going to move the power source that the PI is connected to. Anyone ever run into something similar before or have any additional ideas? Thanks in advance. Below is the most information I can glean from the logs *Mar 1 06:31:39 pst: %DOT11-4-UPLINK_ESTABLISHED: Interface Dot11Radio0, Associated To AP KAirBridge_Para 0019.566e.be47 [None WPA PSK] *Mar 1 06:31:39 pst: %LINK-3-UPDOWN: Interface Dot11Radio0, changed state to up *Mar 1 06:31:41 pst: %DOT11-4-UPLINK_DOWN: Interface Dot11Radio0, parent lost: Received deauthenticate (2) not valid *Mar 1 06:31:41 pst: %LINK-3-UPDOWN: Interface Dot11Radio0, changed state to down *Mar 1 06:31:42 pst: %DOT11-4-UPLINK_ESTABLISHED: Interface Dot11Radio0, Associated To AP KAirBridge_Para 0019.566e.be47 [None WPA PSK] *Mar 1 06:31:42 pst: %LINK-3-UPDOWN: Interface Dot11Radio0, changed state to up *Mar 1 06:32:05 pst: %DOT11-4-UPLINK_DOWN: Interface Dot11Radio0, parent lost: Received deauthenticate (2) not valid *Mar 1 06:32:05 pst: %LINK-3-UPDOWN: Interface Dot11Radio0, changed state to down
    • Re: Connectivity Issues with 1400...scottmac2 years, 10 months ago
      Have you tried shutting down / not using authentication? The log you posted appears to be an auth failure. If it initially authenticates then fails re-auth, check the key rotation periods at both ends. Good Luck Scott
      • Re: Connectivity Issues with 1400...venom432122 years, 10 months ago
        Thanks Scott...I have tried changing the auth paramters (we use WPA and I changed the PSK on both sides), but have not disabled it, that's a good idea and I will try it. I believe the key roation is disabled by default and I haven't configured it....it may be a parameter I will try configuring in further trouble shooting. Thanks again.
        • Re: Connectivity Issues with 1400...jeff.kish2 years, 10 months ago
          Hi Venom, Something isn't right with your RSSI. -78dBm is a terribly weak signal that can easily cause drops. Anything below -70 is weak. Seeing as these antennas are only 1000 feet apart, I'm not sure how it's possible that this signal is so bad. How long are the cables between the bridges and antennas? Are the bridges set to full power?
          • Re: Connectivity Issues with 1400...venom432122 years, 10 months ago
            Yeah, power save is off, the cable run is only about 20 feet. The radio interface was shut down last night so that alerts weren't generated through the night due to flapping, I opened the interface earlier and right now both are up and have been for about an hour. I agree, -78 is not a great signal...currently, looking at the association, the root is at -64 and the non-root is at -62...will update if there is a status change. Thanks.
  • WGB connectivity issuesTonyBell11 Reply3 years, 10 months ago
    Hi, I'm having trouble with a 1200 Wireless AP loosing connectivity to wirless group bridges, there are 21. A reboot fixes the problem for a time. Is there a limit on the number of WGB's that can be used?
    • Re: WGB connectivity issuesbcolvin3 years, 10 months ago
      Tony Found the pollowing in a FAQ for the WGB Q. How many WGB can associate to a single AP? A. When the AP treats WGB as a client device, which occurs by default, the minimum 20 WGB can associate to an AP. I am sure they mean maximum. here is the link http://www.cisco.com/en/US/products/hw/wireless/ps441/products_qanda_item09186a0080094644.shtml#q41 Bill
  • wireless 1310 intermittent issuescmelbourne1 Reply4 years, 3 months ago
    we have a link between two 1310 bridges and for a few months everything was fine. now, every so often we get high response times when running a ping. The average response normally is around 2ms peaking to 7ms but every so often it spikes to say 300ms and then 700ms. Also, Every so often we see that the link goes down and the logs say deauthenticated and then no response. we have to reboot the wireless bridges (BOTH OF THEM) then this works after a reset. any ideas?
    • Re: wireless 1310 intermittent issuesgmarogi4 years, 3 months ago
      There are several reasons for an intermittent connectivity issue to occur with a building to building Wireless bridge setup. Reasons like RF Interference, Fresnel Zone, Clear Channel Assessment etc are there. The following document should give you a clear picture on this http://www.cisco.com/en/US/products/hw/wireless/ps469/products_tech_note09186a0080508551.shtml
  • Wireless LAN Controller 4402 -...pwenstrand2 Replies5 years, 1 month ago
    We have a 4402 wireless LAN controller (ver 4.0.179.8) running with lwapp 1240 AP's that experiences intermittent connectivity problems with some servers while we can get to other servers on the same subnet. This morning I was unable to ping a server from the wireless while I could get to it from the LAN. After about 30 minutes it started working. I didn't change anything. REAP mode connectivity is also very flaky. We had the aironet 1231G's for a year and never had any problems like this. Has anyone else experienced problems like this with the centralized wireless platform?
    • Re: Wireless LAN Controller 4402 -...sandjose5 years, 1 month ago
      Could you please check the ARP cache on the wireless clients and see if it has the arp of the server on the wireless client.When yo say you have connectivity issues you need to check whether the wireless client is able to send the packet to the wired client.
    • Re: Wireless LAN Controller 4402 -...netmasque5 years, 1 month ago
      Just an FYI.. I have an open TAC case regarding the same exact issue. We're trying to debug it still. We don't use REAP/HREAP. We have a cluster of 4404-100's with 1131, 1231 and 1242 ap's running off of them. I'm suspecting there is a bug somewhere either in the disabling peer to peer code, or possibly in the tunneling. The devices we see most often getting blocked at devices on the same subnet as the controllers them selves....
  • Intermittent connectivity for wireless...k_sinjish3 Replies1 year, 4 months ago
    Hi All, We are facing some issues in our Wireless setup .The user who are connected  through  the access point facing intermittent connectivity problem .Also please  find our observations . 1)The access where we are facing the problem showing as  oper status UP , the alarm status  showing as MINOR ( yellow color )  for à802.11 b/g 2) But for the same  access   point oper status  DOWN and alarm status as GREEN  for  -->802.11 a. 3) Also we observed the alarm status is keep changing from  GREEN to YELLOW and back  . Can  anyone please help me by telling a)what is the reason for the MINOR alarm b) While the  AP  is in MINOR will it affect any connected users . c)If it affects  what I have to do to  make it enable and to avoid the intermittent co nnectivity . Regards , Sinjish.K
  • Two Aironet 340 Bridges logged Decrypt...kejun.zhang1 Reply10 years, 4 months ago
    There are over 7000 logs for last two days: Aug 27 15:57:50 wq-core-1 BR500E_35e28f E: Radio Error : 1 Decrypt errors Aug 27 15:58:16 wq-core-2 BR500E_35eb90 E: Radio Error : 1 Decrypt errors Aug 27 15:59:40 wq-core-1 BR500E_35e28f E: Radio Error : 1 Decrypt errors Aug 27 16:19:26 wq-core-1 BR500E_35e28f E: Radio Error : 1 Decrypt errors Aug 27 17:42:30 wq-core-1 BR500E_35e28f E: Radio Error : 1 Decrypt errors Aug 27 18:17:36 wq-core-1 BR500E_35e28f E: Radio Error : 12 Queue full discards Please give me some clues for it?
    • Re: Two Aironet 340 Bridges logged...thomas.chen10 years, 4 months ago
      I was told that intermittent/random decrypt errors can be caused by random radio noise or RF interference. When it tries to decrypt this “noise” or “interference” using the WEP key, and not be able to, it logs the error. Another reason is that is actually trying to communicate with the AP who does not have the correct WEP key. If it’s random and intermittent, and you have no connectivity issues, it’s likely nothing to worry about.

Related Information


Updated: Jan 21, 2008Document ID: 66090