Forum

As some may be aware, Cisco bridges such as the BR350 series can be configured to "search for a less congested channel". I don't seem to be able to find out the rules that apply to this mechanism.

Specifically:

What defines the threshold for a "congested" channel? ... that is, what prompts a channel change?

What determines which channel the unit will switch to? ... that is, what constitutes a "less congested" channel?

The reason I ask is that there is a Cisco 802.11b bridge in the path of one of our P-P links which appears to be configured in the "auto" mode. Depending on the traffic on our (also Cisco 350 802.11b) link, the other guys bridge at the midpoint will change channel. There seems to be no rhyme or reason as to what channel it decides to change to. Also, any wireless LAN's that fire up in range of the midpoint bridge will often prompt a channel change.

This isn't a huge problem most of the time but quite often the other guys bridge will land on the same channel as ours or on an adjacent channel. It seems a bit crazy that the firmware in the Cisco will allow it (for example) to change from a "congested" channel 1 to a supposedly "less congested" channel 2, or 3 or 4 etc.

Incidentally, our link normally operates on a fixed channel. Out of curiosity I configured our root bridge to use "auto" frequency selection ... and the two systems merrily chased each other around the band all day.

AndyK Escribi?3:

What defines the threshold for a "congested" channel? ... that is, what prompts a channel change?

This isn't an answer, for which I apologize, but hopefully this information will help you eventually find an answer.

The functionality that you describe is not defined in the 802.11 standards. Even in the case of things like the clear-channel assessment threshold or the thresholds to change data rates, which 802.11 does define, the specific values of those thresholds are left up to the vendors. Ultimately, I think that your answer must come from Cisco.

Joshua Bardwell Escribi?3:

... I think that your answer must come from Cisco.

Thanks for your reply Joshua ... I'm sure you're correct, but based on experience I'm not confident that any answer would be forthcoming. I was just hoping that maybe someone could shed some light on it. It's only really of academic interest anyway as I will be upgrading the link to something a bit more resilient soon.

Do Cisco people ever read these forums I wonder?.

I used to monitor all the CWNP forums on a consistent basis. If you do a search on my username (joelb), you'll find a lot of my responses to posted questions.

Since the beginning of this year (2005) though, I've taken on a new position inside Cisco. My new job is as a Consulting Systems Engineer for the WorldWide Technical Sales Strategies group. I just haven't been able to keep up with all the posts, much less respond to them. Occasionly I'll get a request to answer specific ones (like this one) from Kevin or Devin. I don't know if there are other Cisco people monitoring this forum.

My recommendation, if you have a pending Cisco technical issue that isn't addressed here, is to visit the technical forum that Cisco maintains for all products and solutions. It's called the Networking Professionals Connection and is available here:

http://www.cisco.com/go/netpro

With that said, to answer your question, Cisco wireless devices roam depending on several parameters such as:

- Max Data Retry count exceeded
- Missed too many Beacons
- Datarate shift
- and many more

All wireless equipment vendors implement their own roaming algorithms for their IAPP (inter-access point protocol). The IEEE does not specify an exact algorithm, thus the "Recommended Practice" that is IAPP or 802.11F. There are working groups attempting to develop a standardized protocol. Some are even available through the IETF, such as LWAPP (a L2 and L3 protocol used in Airespace APs and controllers) and CAPWAP (an architecture that has several competing protocols defined).

So, how do you "fix" the channel surfing issue you've described? I would recommend a few things. First, the least expensive, would be to coordinate channels with your neighbor. They'd probably be happy to work with you since this is affecting their network as well. They might not even know it's happening. You might not know who this neighbor is though, only that there are specific devices that are causing the problems. This is where your investigative and analysis expertise can come in. Who knows, you might end up meeting a new friend or even finding out about an open position you didn't know existed.

Second, you could move the bridge to somewhere where it's not affected by the other bridges. Increase or decrease the height, change the antenna type (a narrower beamwight, higher gain should do the trick), or just increase the power (if possible) to blast through your neighbor's interference.

To prevent the bridge from moving to channels other than 1, 6, or 11, you can force it only to choose one of those channels rather than any .11b/g channel. You can do this either via CLI or the web interface. You could also lock down your channel if you've implemented the "blast through" scenario above.

Third, you could move to a BR1300 platform that would allow you to setup a .11g connection. OFDM is much more forgiving with RF interference than HR-DSSS modulation.

Last, and the most expensive option, is to consider using .11a which has 12 non-overlapping channels (soon to be 23 or even possibly 24 channels) rather than the 3 you're limited to with .11b/g.

Hope that helps,
Joel Barrett

Many thanks for your detailed reply Joel ... and my apologies for not posting a response sooner.

The scenario is that the interfering station is running a high gain omni directional antenna that is around 2 kilometers from one end of our 11 kilometer path. It is in a direct line between our two ends. This removes any possibility of narrower beamwidths ... and we were using high gain grid parabolics anyway.

I do know who owns the interfering station but negotiating with them has proved fruitless as they are a large beauracracy and getting through to the people who could or would do anything is virtually impossible. They seem to neither know or care about causing or being the victim of the interference. I had even considered simply hacking into their bridge and reconfiguring it myself ... but thought better of it in the end. :)

Locking our own stations to a particular frequency is something I already had in place but as the offending station is in the central business district of a town, it changes frequency as a result of interference from other nearby "in building" 802.11b networks ... often landing on the channel that I had set in our equipment. I did note that feeding constant low bandwidth data over our link prevented the offending station from grabbing it much of the time ... the "normal" traffic on our link being fairly bursty in nature.

Increasing power was also not an available option as both ends of our link were already at their maximum permitted EIRP (36dBm here in Australia).

As I indicated in my earlier post, the situation would become somewhat academic as I intended to change our equipment. This has now been done and the affected link has been replaced with equipment operating on 5.8GHz OFDM (Redline AN-50). I will redeploy the Cisco bridges in another location.

Thanks once again for taking time to respond Joel, and for providing an insight to the behaviour of the Cisco equipment in this situation. It is much appreciated.

Thanks for the update... sorry to see you implemented a non-Cisco replacement.

On another subject. Did you get to attend Networkers 2005 Gold Coast, south of Brisbane? I was there in September and spoke a few times on our wireless technologies. Just curious, wondered if we had met.

Joel

Joel, the Redline gear was used because I already had it on hand. We still use Cisco gear extensively.

I didn't make it to the Gold Coast ... I tend to go to events in Sydney as it's a fair bit closer for us. There's a good chance we will probably meet up some day though. :)