cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1225
Views
0
Helpful
7
Replies
Highlighted
Beginner

AIR-BR1310G-E-K9-R Bridge Dropping

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

7 REPLIES 7
Highlighted
Beginner

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'.

Highlighted

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

Highlighted

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

Highlighted

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

Highlighted

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. :(

Highlighted

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

Highlighted

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.

Content for Community-Ad