I have 5 point-to-point links, 1 using the old 340 series and 4 with the new BR-350. The problem is that when I inject traffic I lost the link and it appear to flap (goes up and goes down) for 1 to 10 seconds. This problem just pop up last week after 4 months without any problem.
One is around 13 km and the others less than 3 Km (1 of less than 1km), each link with a different SSID, using different channels (1 to 6). Working without EAP, TLS, etc... just the SSID. In my central point I have a cisco catalyst without power-inline feature without any special config (no vlans, no qos, just a simple switch) and the remote points are using a 12 port 3COM switch.
I check alienation, carrier test and everything seems to be ok, I also check the connectors (for water) and UTP cables.
After check this I upgraded to the newest firmware 12.01T1 but it continues failing.
After many tests, I turn off all radios and test only one link (less than 2 km), then I started to ping the local radio and without logic reason it lost around 5 to 10 packets!... (pinging from a win98). If I turn on all the radios, and start pinging it, I lost all of then, then it go back. If I add traffic, I lost every 5 to 10 minutes!. I check the logs and no error!, no nothing!.
The curious is that the 340 is working really nice!!
Any idea? I also check the Catalyst no errors, just some collisions.
1. Try changing the Data Rates from Basic to YES, except for 1.0 Mbps.
2. Try reducing the Transmit Power of the Bridge.
3. Reverse the Role of the Bridges in the network.
4. Change the settings in the Setup -> Associations -> Advanced to 0
i.e 0 here means Infinite.
5. Try changing the Radio Frequency Channel .
6. Try Loading the Bonsai Image on the bridges.
7. Perform the carrier busy test and observe it carefully, try a different
channel ( this will help to reduce CRC due to interference).
8.Reduced the fragment size on the bridges to half of the value.
9. If all the above possibility won't work re-config it to the factory
default setting and upload the new firmware .
Go to Radio -> Hardware change beacon timeout from 100 to 4000 .
If performance is slow, most of the time it means that the link is not
healthy, check antenna alignment , sometimes they have strong winds in the
area and they push the antenna out of alignment , ask if there was any
storms in the area lately it may have water inside the cable and it is
working on short, ask him how well shielded are the connectors on the
antenna. Check for CRC errors and duplicated packets it usually confirms
issues described above.
1. you should have 5 miters between each antenna, becasue you have interferance.
1. but each link in differanet channel frequancy, for example:
link 1: channel 1
link 2: channel 6
link 3: channel 11
go to setup - radio hardware.
3. check your aligment
There is a possible simpler solution, too.
If you haven't already checked it, the speed and duplex settings of the older model's ethernet port may be unmatched to those in the newer models. My organization employs 185 access points over 15 different locations, and a myriad of switches at each location. I am the "lucky" guy who gets to babysit and optimize all of them..oh joy! Anyway, in autosensing mode on the AP's ethernet port, there is very likely to be some flapping. You might try checking the setting on the 3Com switch ends, too. Make sure you set them identically, or you'll likely have some problems. The switchport and the ethernet interface in the AP have to be the same, for optimal performance. Letting autosense handle speed and duplex seems like a good way to go,on the surface, but it isn't. During the time that autosense occurs, your 802.11b card is hitting the ethernet port at somewhere between 10 and 11 mbps
If you think this might be your problem, and it is an available setting on your Ap and your switch, try forcing it to use 10 mbps/half-duplex at each end, and see if your flapping continues. IF that works, then try 10mb/full duplex. If still good, try 100mb/half, then 100 full, but don't use autosensing on WLAN, if you can help it. It took a while for me to find this out, but a lot of our problems came down to this simple solution. But us techs always like to look for the more exotic ones, don't we?
Hi, We have a similar problem with bridge Aironet 350. We`ve tested all as ndoshi do, but nothing.
The only thing that resolved my problem was to changing the non-root from "non-root bridge w/o clients" -> "non-root bridge w/clients". This seems to stop the constant drops.
Changing the radio roles.
After many tests, changes, etc... I was unable to find what's wrong.
The flapping continues (I set up Nagios on Linux to check it). Someting that helps its changing the radio role, in my central I set up all non-root without clients and the remotes to root.
I think that somebody try to get into my network, I found one SSID out of policies but the signal is too weak to track without and onmi antenna. Then I activated all the security things.
Now I lost the ethernet ports (on all AIRBR350) once a day.
When I found the solution I'll post it.
I had the same problem, an access point had been added for outside coverage near the bridge, and they were on the same channel. I changed the channel on the bridges and the problem was alleviated.