I constantly find myself configuring wireless bridges between sites. It’s a cheaper alternative to using a fiber or copper connection, even if it is a bit problematic at times. However, I never seem to have the right configuration, either because it was barely working in the first place or I delete it from my email before saving it. Now, thanks to the magic of my blog, I’m putting this here as much for my edification as everyone else’s. Feel free to use it if you’d like.
dot11 ssid BRIDGE-NATIVE
vlan1
authentication open
authentication key-management wpa
wpa-psk ascii 0 security
!
dot11 ssid BRIDGE44
vlan 44
authentication open
authentication key-management wpa
wpa-psk ascii 0 security
!
interface Dot11Radio0
encryption vlan 1 mode ciphers tkip
encryption vlan 44 mode ciphers tkip
ssid BRIDGE-NATIVE
!
interface Dot11Radio0.1
encapsulation dot1Q 1 native
no ip route-cache
bridge-group 1
bridge-group 1 spanning-disabled
!
interface Dot11Radio0.44
encapsulation dot1Q 44
no ip route-cache
bridge-group 44
bridge-group 44 spanning-disabled
!
interface FastEthernet0.1
encapsulation dot1Q 1 native
no ip route-cache
bridge-group 1
bridge-group 1 spanning-disabled
!
interface FastEthernet0.44
encapsulation dot1Q 44
no ip route-cache
bridge-group 44
bridge-group 44 spanning-disabled
This allows you to pass traffic on multiple VLANs in case you want to put a phone or other device on the other side of the link. Just make sure to turn the switch port connected to the bridge into a trunk so all the information will pass correctly. As always, if you see an issue with my configuration or you have a cleaner, better way of doing things, don’t hesitate to leave a comment. I’m always open to a better way of getting things done.
I’ve often wondered why Cisco’s wireless bridging has to be so complicated. At a previous company we had a licensed band wireless link using Western Multiplex (Proxim) Tsunami radios. It truly functioned as a giant patch cable with no configuration other than adding in the security key and the management IPs for the management ports. The switches saw each other and established a trunk and didn’t care that it was a wireless bridge instead of a cable.
Hi Tom,
A few considerations you may want revise in your config:
1) Don’t use TKIP, since that will prevent use of 802.11n data rates. You’ll be limited to 54Mbps. Bad!
2) You actually only need a single SSID, and you can bridge through multiple other VLANs (sub-interfaces).
3) You may want to use 802.1X auth for higher security (dynamic encryption keys) since the likelihood of this being in operation for a long period of time is very high. And it’s probably outdoors for anyone to capture frames and try to hack the PSK.
Here is an example root bridge configuration that I use, which also includes 802.1X auth between the root bridge and non-root bridges, with the RADIUS server hosted locally on the root bridge so it remains up and is not reliant on an external RADIUS server.
aaa new-model
aaa group server radius rad_local
server 10.10.10.51 auth-port 1812 acct-port 1813
aaa authentication login eap_local group rad_local
dot11 ssid bridge
vlan 4
authentication open eap eap_local
authentication network-eap eap_local
authentication key-management wpa
guest-mode
infrastructure-ssid
bridge irb
interface Dot11Radio1
no ip address
no ip route-cache
!
encryption vlan 4 mode ciphers aes-ccm
!
ssid bridge
!
dfs band 3 block
speed basic-6.0 9.0 basic-12.0 18.0 basic-24.0 36.0 48.0 54.0
channel 5745
station-role root bridge
!
interface Dot11Radio1.2
encapsulation dot1Q 2
no ip route-cache
bridge-group 2
!
interface Dot11Radio1.3
encapsulation dot1Q 3
no ip route-cache
bridge-group 3
!
interface Dot11Radio1.4
encapsulation dot1Q 4 native
no ip route-cache
bridge-group 1
!
interface FastEthernet0
no ip address
no ip route-cache
duplex auto
speed auto
hold-queue 160 in
!
interface FastEthernet0.2
encapsulation dot1Q 2
no ip route-cache
bridge-group 2
!
interface FastEthernet0.3
encapsulation dot1Q 3
no ip route-cache
bridge-group 3
!
interface FastEthernet0.4
encapsulation dot1Q 4 native
no ip route-cache
bridge-group 1
radius-server local
nas 10.10.10.51 key
!
user bridge password mypassword
radius-server host 10.10.10.51 auth-port 1812 acct-port 1813 key mykey
!
bridge 1 route ip
Tom, the last few years I have been steering my customers away from using traditional (and often costly) APs to Ubiquiti products for quick, cheap wireless bridging. The Ubiquiti Nanobridges cost ~$100 a side including mounts and are easier than heck to set up. They could care less about tagged packets, though the management interface can be tagged if you don’t want it on the native VLAN.
Disclaimer- I do not work for Ubiquiti and do not own stock in them. I do work for a company that resells Ubiquiti hardware, but not at a material level (<$10k/yr). My employer also resells hardware and services from 3 other major WLAN manufacturers.
I have definitely seen an uptick in Ubiquiti around my area. The school districts love both their bridges and APs. Unfortunately though some districts are finding out that the low end APs without 5GHz just don’t cut it when there is a lot of contention in the 2.4GHz space.