07-25-2005 10:19 AM - edited 07-04-2021 10:59 AM
We have a bridge up and running that occasionally drops, the timing of the drops is not consistent, so doesn't appear to be a timer per se.
Here are the Dot11Radio config's
Root Bridge
interface Dot11Radio0
no ip address
no ip route-cache
!
ssid tsunami
authentication open
infrastructure-ssid
!
short-slot-time
concatenation
speed basic-1.0 basic-2.0 basic-5.5 6.0 9.0 basic-11.0 12.0 18.0 24.0 36.0 48.0 54.0
rts threshold 4000
power local cck 1
power local ofdm 1
power client 1
channel 2412
station-role root
payload-encapsulation dot1h
antenna receive right
antenna transmit right
infrastructure-client
bridge-group 1
Non-Root Bridge
interface Dot11Radio0
no ip address
no ip route-cache
!
ssid tsunami
authentication open
infrastructure-ssid
!
short-slot-time
concatenation
speed basic-1.0 basic-2.0 basic-5.5 6.0 9.0 basic-11.0 12.0 18.0 24.0 36.0 48.0 54.0
rts threshold 4000
power local cck 1
power local ofdm 1
power client 1
station-role non-root
payload-encapsulation dot1h
antenna receive right
antenna transmit right
infrastructure-client
bridge-group 1
SSID's have been change for obvious reasons, but as I say connectivity is OK (for short periods).
Logs show the following:
Root logs
Jul 25 18:02:03.516: %DOT11-6-DISASSOC: Interface Dot11Radio0, Deauthenticating Station 0012.43d7.1a30 Reason: Previous
authentication no longer valid
Jul 25 18:02:03.573: %DOT11-6-ASSOC: Interface Dot11Radio0, Station Unit_C_Bridge 0012.43d7.1a30 Reassociated KEY_MGMT[N
ONE]
Non-Root Logs
Jul 25 19:01:53.706: %DOT11-4-UPLINK_DOWN: Interface Dot11Radio0, parent lost: Received deauthenticate (2) not valid
Jul 25 19:01:53.709: %LINK-3-UPDOWN: Interface Dot11Radio0, changed state to down
Jul 25 19:01:53.763: %DOT11-4-UPLINK_ESTABLISHED: Interface Dot11Radio0, Associated To AP Unit_F_Bridge xxxx.xxxx.xxxx [
None]
Jul 25 19:01:53.764: %LINK-3-UPDOWN: Interface Dot11Radio0, changed state to up
Jul 25 19:02:09.116: %LINK-3-UPDOWN: Interface Dot11Radio0, changed state to down
Jul 25 19:02:10.116: %LINEPROTO-5-UPDOWN: Line protocol on Interface Dot11Radio0, changed state to down
Issue 1
What I have been reading, I can see the Power settings are low, not sure how to identify the Antennae, as we work remotely, I think this can only be done locally.
Issue 2
I can see the Root Bridge has been fixed to Channel 1 but not the Non-root bridge, is this OK/Normal.
Issue 3
In the documentation I can see the Infrastructure-ssid command should force any non-root bridges to the ssid, however this appears to be set at both ends.
Basically is any of this relevant, if not where do I need to go from there.
Thanks
Vince
07-25-2005 03:17 PM
Well, there are quite a few things you can do remotely in order to narrow down the problem. If you login to 1310s (both root and non-root side ) via telnet session and then if you type the following commands in 'enable' mode
term mon - hit 'Enter' key
dot dot 0 linktest - hit 'Enter' key
you need to see at the very beginning as
GOOD (0 % retries) - this means that there are no retries at all. So, the quality of the signal is pretty good
at the very end of the output you need to see
Rates (Src/Tgt) 54Mb 100/100 - this means that all 100 packets had been sent at 54meg rate. So, the quality of the signal is pretty good.
If you have poor signal quality then you would see X amout of tries and instead of 54meg you might see some packets sent at 5 meg, 11meg etc. If so, I would check
1. Whether I have clear line of sight between these two antennas.
2. Find out whether they are aligned properly. I may seek help from certified wireless professional to do site survey.
3. Whether any other antennas are installed in a close proximity to these two antennas
By the way, what type of antenna are you using? and how far these antennas are located from each other? The type of antenna and alignment plays a major role in terms of signal quality.
As far as the channel goes, I would configure to use ' Least Congested Channel Search'. Thus, the bridges will figure out by itself to use the appropriate channel. This can be done by accessing the bridge via http and the click ' Network Interfaces-->802.11G-->Settings' - in 'settings' page you can choose ' all the channels ' and from the pull down menu make sure it is using ' Least Congested Frequency'.
07-26-2005 08:36 AM
nchidamb,
Many thanks for that, I will try and update you with the results.
I have also been informed that the arials that are being used are 13.5dBi Yagi's at both ends.
So far Cisco have supplied a Excel sheet for caculating distance based on kit and settings and as the two arials appear to be 500yds apart, this exceeds the Cisco recommended limit of 440yds.
Vince
07-26-2005 11:33 AM
nchidamb,
I have been able to perform the link tests and the results are below:
Root_Bridge#
GOOD (1 % retries) Time Strength Quality % Retries
msec % In dBm % Out dBm In Out In Out
Sent : 100, Avg 2 58 - 65 66 - 57 100 100 Tot: 0 2
Lost to Tgt: 0, Max 16 65 - 63 70 - 52 100 100 Max: 0 1
Lost to Src: 0, Min 1 51 - 70 64 - 63 100 100
Rates (Src/Tgt) 36Mb 100/100
Linktest Done
NonRoot_Bridge#
GOOD (0 % retries) Time Strength Quality % Retries
msec % In dBm % Out dBm In Out In Out
Sent : 100, Avg 1 57 - 66 65 - 58 100 100 Tot: 0 1
Lost to Tgt: 0, Max 4 63 - 64 69 - 52 100 100 Max: 0 1
Lost to Src: 0, Min 1 52 - 70 63 - 65 100 100
Rates (Src/Tgt) 36Mb 100/100
Linktest Done
I intend to retry at 54Mb, as I now think the speed is not really relevant in this problem, as since the speed was reduced to give a greater range, we are still seeing exactly the same problems.
regards
Vince
07-26-2005 11:47 AM
One final update, I have increased the bandwidth back to 54Mb and the results are pretty much the same a few more retries but still not many.
Any further advice, please.
regards
Vince
08-05-2005 01:53 AM
We had something similar with a pair of these bridges, for some reason the bridges were making spanning tree decisions and spanning out the link. We disabled spanning tree on the bridges, problem solved. Can't remember how we did it though I'm afraid. :(
08-19-2005 06:10 AM
You should try to reduce the speed even further. If you reduce to 18Mbs according to Ciscos excel you'll get about a mile. Give it a try.
Rho
09-23-2005 08:16 AM
I have an identical intermittent problem - same error - "Previous authetication no longer valid" - This is apparently due to interference according to :www.cisco.com/en/US/tech/tk722/tk809/technologies_tech_note09186a00800948cb.shtml however a carrier busy test shows nothing abnormal.
Also the range seems very poor with 12dbi externals -dis-associates at around 500 metres. My version is 12.3(2)JA2.
If you have any updates then please post them.
Thanks.
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: