I have a fresh installation of a Point to Point (1km distance) link using autonomous Aps 1532 and directional antennas 14dbi.
The regulatory domain is Europe and the only usable channels are 100 104 108 112 116 132 136 140 (DFS channels).
The link is near military area and DFS is triggered very often which causes frequent disconnections near every minute.
From the logs i see that there is no available channel:
%DOT11-6-DFS_TRIGGERED: DFS: triggered on frequency 5540 MHz
%DOT11-2-NO_CHAN_AVAIL_NON_OCCP: Interface Dot11Radio1, no channel available.
So if all channels are occupied by the radars why carrier busy test does show anything?
ROOT#dot11 dot11Radio 1 carr bu
Frequency Carrier Busy %
The second issue is regarding vlans.
3 Vlans: Data vlan 1 ,Voice vlan 2 , Management vlan 100 (native vlan for bridging).
After rebooting the non-root bridge data vlan 1 doesn't works even though management and voice are ok.
The workaround i found is to manually change the bridge group to different number.
After the change connectivity is comes back... (maybe bug???)
encapsulation dot1Q 2
bridge-group 2 spanning-disabled
encapsulation dot1Q 1
bridge-group 4 spanning-disabled
encapsulation dot1Q 100 native
bridge-group 1 spanning-disabled
I will try to help you with the different problems you are facing here.
1) DFS / ETSI Regulation
I'm really surprised that the only channels available in the 5-GHz band in Europe are in the DFS band.
If you refer to the document below, you should be able to use UNII-1 band, which is not overlapping DFS:
Maybe this is a specific country requirement?
If DFS disruptions become an issue, I would suggest to move and try the 2.4-GHz band if possible.
2) Carrier Busy Test
From what I know about the Carrier Busy Test, it monitors all the channels in the band during a few seconds, and displays the radio occupation for each channel. I'm not sure if it displays only 802.11 occupation, or even non-802.11 results.
In the first case, this would explain why the AP can't detect a channel occupation, because radar transmissions are not 802.11.
Or maybe at the time you performed the test, there were no transmissions at all, leaving the medium free.
3) VLAN 1
I suppose you know it already, but your vlans should be consistent with the bridge-groups. Is your configuration displayed here the one in default.
Or whatever the configuration used, it works for a while, and stops working only when the AP reboots?
Could you detail your issue a little more please? And also post the complete configuration for your AP, and the following outputs:
show bridge verbose
Thanks for your reply.
Unfortunately the only channels i can use are dfs channels:
<100-5700> One of: 100 104 108 112 116 132 136 140 5500 5520 5540 5560 5580 5660 5680 5700
dfs Use Dynamic Frequency Selection
width Bandwidth used
ROOT#sh controllers dot11Radio 1
Radio AIR-AP1532A, Base Address 189c.5d7c.2e60, BBlock version 0.00, Software version 448.04.0
Number of supported simultaneous BSSID on Dot11Radio1: 16
Carrier Set: ETSI (OFDM) (EU) (-E)
Uniform Spreading Required: Yes
Configured Frequency: 5520 MHz Channel 104 (DFS enabled)
5500(100) 5520(104) 5540(108) 5560(112) 5580(116) 5660(132) 5680(136) 5700(140)
5180( 36) 5200( 40) 5220( 44) 5240( 48) 5260( 52) 5280( 56) 5300( 60) 5320( 64) 5500(100) 5520(104)
5540(108) 5560(112) 5580(116) 5600(120) 5620(124) 5640(128) 5660(132) 5680(136) 5700(140)
Usually i use the same vlan id - bridge group id but in my case management vlan100 needs to be linked to bridge-group 1 so i have to use different bridge-group for vlan 1.
Communication works fine for all vlans but when i reboot the non route bridge vlan1 users cannot pass traffic even though voice and management vlan works fine.
As a workaround i need to delete the subinterfaces for data vlan (int d1.4/gi0.4) and reconfigure them.
Very strange behavior.
Attached you can find the configs.
PS bridge-group 5 is not used (test purpose)
Below is the output from one of my APs in the -E regulatory domain:
It seems to be a limitation of the 1530 series:
Frequency Band and 20-MHz Operating Channels
● 2.401 to 2.4835 GHz; 13 channels
● 5.470 to 5.725 GHz; 8 channels
Regarding your issue with vlan 1, I can't see anything wrong in your configuration. This could indeed be a bug. I made a little research in the bug tool, but couldn't find anything related.
However, you should check the following before opening a case with the TAC:
Is the bridge setting a loop in your network? I have worked on architectures with redundant wireless bridge uplinks using STP. A STP blocked port for vlan 1 could be a lead in that case.
Moreover, in your configuration, I can't see the usual bridge-group configuration under your subinterfaces. Not sure if this is of any use here as you have a 1532 AP, but I would try to add it for each subinterface:
I upgraded today to version ap1g3-k9w7-tar.152-4.JB4 since the current version (JB3b) is deferred.
Unfortunately problem with vlan1 hasn't solved.
After power loss of root or non root bridge i have to manually reenter the bridge-group number under sub-interface (bridge-group4 in my case).
I have noticed additional problems:
- After power loss there are times that non-root bridge doesn't associate automatically to Root bridge.I have to manually reset the radio controller few times on root bridge or to reboot it.
- Low throughput.Association rate is M15 and i get maximum 5Mbps.
- Signal strength on root is between -59 to -64dbm and on non-root -70 to -75 dbm which is huge difference.Antennas are aligned as better as best as possible.
I can't open a TAC case at the moment so the only solution is to call ghostbusters to solve the issue. :)
Bridge group 1 is always your native vlan and can't be changed. This is default for all autonomous access points. If your only allowed DFS channels, then your solution will not work unless you set your backhaul using the 2.4ghz. Regulations will drop the radio when radar is detected.
Scott I'm sure Xristos already knows about the bridge-group 1 mapped to the native vlan, as I believe he is studying for CCIE Wireless :)
Regarding using the 2.4-GHz Band for the backhaul, this would be my advice too.
The other solution being to replace the APs for some allowing the UNII-1 Band.
Regarding your low data rate, I had to troubleshoot bridge APs separated from many kilometers. 1 km is not that far, and I think you should have a better RSSI... -75 dBm is too weak in my opinion to guarantee a stable connection.
Antenna alignment when using directional antennas is really important. What method did you use to check the alignment? You should read this link and verify this point: http://www.cisco.com/c/en/us/td/docs/wireless/bridge/1400/installation/guide/1400hig4/higch3.html
For your vlan 1, can you share the logs from all devices when you have the issue (AP and switches on each side)?
I wouldn't know who is studying for their CCIE or not. I just thought I saw the Vlan being defined wrong:)
There are other who have poor performance from the 1530's in production. Might just be an issue with the AP's itself.
Regarding the difference in the RSSI on each side (-60 dBm and -70/-75 dBm), I would rather suspect a problem with antenna alignment.
In a point-to-point configuration, using the same AP and antenna type (and the same Tx Power), you should approximately see the same RSSI on each side I believe.
Christos, can you confirm the configuration (hardware and software) is the same on each side?
Scott bridge group 1 is mapped to vlan 100 and is the native vlan.
The problem is that after rebooting one of two devices, bridge-group 4 which is mapped to vlan1 looses it's connection and comes back only if i manually re enter the bridge group number.
For antenna aliment i used the led indicator and signal strength-snr values from cli.
Definitely -75 is too low,the best value i got was -59 on root side and -69 on non root with the same Tx power on both bridges
Is any way to see if radios or antennas are faulty?
Regarding dfs issue i lowered the Tx power from 14 to 11dbm on the root and it seems that dfs is not triggered for now.
I'll try to change the antennas from root to non-root and vice versa.
If problem moves to non root might be antenna problem.
I just realized something about your configuration. I never worked with 1530 APs, so I'm not sure if this kind of parameter should be configured.
Usually, when you work with bridge APs and directional antennas, you only have one antenna connected to one connector of the AP. So you have to manually tell the AP on which connector the antenna is connected, with configuration:
Omitting this configuration would result in poor RSSI and low throughput.
I can't see these lines in your configuration. As I said before, I may be wrong, because I don't know 1530 series.
1530 Ap and the antenna i used (air-ant5114p2m-n) have 2 connectors so i've configured the radio to support diversity.
Also after the upgrade to new code i could added one command regarding the antennas that was missing in the previous code.
dot11 ant-band-mode single
I installed temporally a new pair of bridges (from different vendor) and i achieved about 45Mbps throughput.
I'll do extensive throughput tests in my office and maybe a test installation in the roof to see what's going on..
I'll inform you as soon as i have any conclusions.
Thanks for your help!
If you can achieve 45 Mbps with tierce APs, we can suppose antennas are working normally.
Then it could be a configuration problem, a bug, or a defective AP.
I would suggest to go through the AP GUI for the antenna parameters you can set, just to be sure you don't have forgotten something.
Does the logs show something (AP left BSS, or MAXRETRIES?). Maybe the show dot11 association <MAC> can show excessive retries?
I also changed the antennas so the new link has new Aps and antennas.
From dot11 association i see a lot of data retries on root side.
Not root side has no errors.
I'll try setup a test link with the 1532. First action is to move the antenna from root to non root and vice versa.
If the problem moves to the non root then we assume that it's an antenna related problem.
If there is no change then i'll change the hardware.
Regarding the vlan problem i'm pretty sure it's a bug so i'll wait for the next upgrade.
I'll try to reproduce the problem in the lab and see if i still have the same issue.
I've been working with TAC the last months.After a lot of tests,it seems we have found two new bugs.
1) Autonomous AP vlan 1 can not be forwarded CSCuq42930
2) AP1532E/I bridge throughput is very low on 802.11n CSCuo69578
Thank you all for your help!