Cisco Patch Antenna and Cabling Configurations

When you make the decision to use a Cisco patch antenna for use on an AP model that requires external antennas, choosing the correct antenna and cabling accessories to do the job can be a bit of a daunting task.

You will still need to perform a site survey to determine which AP will meet your density, performance and coverage requirements, but you need to make sure the antenna is compatible with your AP! 

Typically your Cisco Sales Rep will know what parts connect to what, but it is always handy to know what your options are.

I don't deploy outdoor APs or indoor APs with external antenna connectors too often, so when I do I often forget what I can and can't do in this space. 

I created the images below to remind me quite some time ago, however have recently updated them with the latest Cisco AP models.

Please let me know if anything is incorrect!

Cisco WLC Discovery & Join Methods

In the Cisco Unified Wireless Network (CUWN) architecture, a Wireless LAN Controller provides central configuration and management of Cisco Lightweight Access Points. A Lightweight AP simply cannot cannot operate independently and must join a controller before it can can start to serve wireless clients.  An AP will use a number of methods to discover a list of controllers and their configured management IP addresses before it decides which one to join.

DISCOVERY PROCESS

Upon connecting an AP to the network, the following WLC discovery methods will be attempted:

1. Broadcast on local subnet
2. Use a previously configured/discovered list stored on the APs NVRAM
3. Use DHCP Option 43 provided from DHCP server
4. Use DNS to resolve "CISCO-CAPWAP-CONTROLLER.localdomain"

Broadcast

The AP will send a CAPWAP Discovery Request message on the local subnet. Any controller that has a management IP address within the same subnet will respond and can be used by the AP.

If there are no controllers located in the same subnet, the router can forward broadcasts (in the form of unicast packets) to the controller. The CAPWAP Discovery Request message is sent on UDP 5246.

Via IOS CLI:

ip forward-protocol udp 5246
interface <interface_name>
     ip helper-address <wlc_ip_address>

NVRAM

This list is built from a number of sources:

• Previously configured Primary, Secondary & Tertiary controllers

Via WLC GUI:

Via WLC CLI:

config ap primary-base <wlc_name> <ap_name> <wlc_ip_address>
config ap secondary-base <wlc_name> <ap_name> <wlc_ip_address>
config ap tertiary-base <wlc_name> <ap_name> <wlc_ip_address>

Via AP CLI:

config ap controller ip address <wlc_ip_address>

• Controllers part of a previously joined Mobility Group

DHCP Option 43

DHCP Option 43 is a vendor specific option which the Lightweight APs can also use to locate a controller. The controllers management IP address is entered in hexadecimal in the form of: Type + Length + Value, where;

Type = Always sub code option - 0xf1 (expressed as f1)
Length = Number of controller management IP addresses specified, multiplied by 4.
Value = IP addresses of controllers, listed sequentially

Via IOS CLI:

ip dhcp excluded-address <start_ip <end_ip>
ip dhcp pool <pool_name>
     network <ip_address> <netmask>
     default-router <gateway_ip>
     dns-server <ip_address1> <ip_address2>
     domain-name <domain>
     lease <days> <hours>
     option 43 hex <hex_value>   // e.g. option 43 hex f104.0a5e.dec8

Via Windows Server:

DNS

The AP will attempt to resolve "CISCO-CAPWAP-CONTROLLER.localdomain" to an IP address. This can be done by configuring a Host A Record on the DNS server specified in DHCP.

JOIN PROCESS

Once the AP has built a list of possible controllers, it will attempt to join one of them using the following order:

1. AP's NVRAM configured Primary controller
2. AP's NVRAM configured Secondary controller
3. AP's NVRAM configured Tertiary controller
4. Least loaded controller learnt through dynamic methods (broadcast, DHCP option 43, DNS)

Once an AP has joined a controller it will forgot about the controllers learnt through the dynamic methods listed in number 4 above.

If an AP is joined to a controller, and that control fails, the AP it will attempt to join another controller using the order below:

1. AP's NVRAM configured Primary controller
2. AP's NVRAM configured Secondary controller
3. AP's NVRAM configured Tertiary controller
4. WLC's Backup Primary controller
5. WLC's Backup Secondary controller
6. Controllers part of the WLC's mobility group membership

If an AP cannot join one of the controllers above, it will reboot and start the re-initialise the discovery process.

VERIFICATION

To confirm what controllers the AP is currently aware of, there are several AP CLI commands available:

show capwap client config



 // LIST OF NVRAM CONFIGURED WLCS (PRIMARY, SECONDARY, TERTIARY)

mwarName                WLC1
mwarIPAddress           10.100.5.1
mwarName                WLC2
mwarIPAddress           10.100.5.2
mwarName                WLC3
mwarIPAddress           10.100.5.3


// LIST OF WLCS IN PREVIOUSLY LEARNT MOBILITY GROUPS

Configured Switch 1 Addr 10.100.5.1
Configured Switch 2 Addr 10.100.5.2
Configured Switch 3 Addr 10.100.5.3
Configured Switch 4 Addr 10.159.44.17
Configured Switch 5 Addr 10.159.44.18

show capwap client ha

// LIST BACKUP PRIMARY & BACKUP SECONDARY WLCS (LOCAL TO CURRENT WLC

primaryBackupWlcIp      10.100.5.2 
primaryBackupWlcName    WLC2
secondaryBackupWlcIp    10.100.5.3 
secondaryBackupWlcName WLC3

802.11 EIRP limitations in Australia

I have recently had the opportunity to design and implement an outdoor wireless mesh network at one of Australia's major airports. Although relatively straight forward to implement, we had challenges in deciding what channels to use on each Root Access Point (RAP). A spectrum analysis of the required locations (highly secure) wasn't in scope so we relied on Cisco's Clean-Air reports to tell us the least used channels in each location once the APs were installed.

Without going in to details it turns out that the 5GHz band at airports (or at least this one) is quite utilised and we couldn't just randomly assign the UNII-3 channels available to us. In order to provide a fast, yet stable network we had to choose a channel which had the highest consistent Signal-to-Noise Ratio (SNR) for each RAP. Some channels had a higher 'peak' SNR but would occasionally drop to an unusable level.

This was the first time I had to REALLY think about neighbouring WiFi networks and the potential performance impact I could impose on those networks (as well as my clients) by not planning carefully. It was also the first time I had to care what the transmit power laws for the 2.4GHz / 5GHz bands in Australia were. After all, I would hate to be responsible for a plane to drop out of the sky!

Technically a Wireless LAN Controller will limit an AP's Effective Isotropic Radiated Power (EIRP) to the limits of the regulatory domain that the AP is based in. However a WLC trusts that you have provided it with antenna gain values that match the ACTUAL gain of the antennas you are using. Entering a gain value that is lower than the real value could cause the WLC to use a higher transmit power on the AP's radio, potentially violating the laws of the domain.

Getting to the point of this post...

This got me thinking about what the EIRP laws for Wireless LANs are in Australia. Although the ACMA (Australia's version of the FCC or ETSI) and the ComLaw websites do provide the information, the sites aren't exactly intuitive or display the information in an easy to view manner, so I have created a chart that does exactly that (see below). There is still talk of the ACMA following the FCC and adding various other laws around the use of the 5GHz spectrum, but as far as I can tell these are not actually in place as of yet, so I have left these out of the chart.

Feel free to use to graphic as you please. All I ask is that the (c) be retained. I will update the chart as changes are made to the bands or the the laws are modified. I would love some feedback if you feel something needs to be corrected :)

-Brett