Cisco Aironet Access Points, just like most Cisco devices, provide a web interface from which we are able to configure the device. It is often we are presented with a number of options and settings, which we really are not sure why they exist, what they do, and how they can affect the performance of our wireless access point.  This is all about to change!

This article aims to help cover this gap by explaining the various configuration options and settings found in Cisco's Aironet series Web-Based configuration page.  While the web-based interface allows the configuration of many functions within the Aironet device, we will be focusing on the 'Network Interfaces: Radio0-802.11a/b/g' Settings, which is perhaps the most important section for the device's proper wireless operation.

Understanding and configuring correctly your Cisco Aironet Access Points can really make a difference in your clients wireless performance and connectivity range.  You'd be suprised on the performance difference of your wireless network, when tweaking your Cisco Aironet Access Points to adapt to the working environment.

This article explains all the network options found under the Cisco Aironet web-interface setup, in a step-by-step manner.  To help make it easier to track, we have broken the page into three sections, each containing a screenshot of the covered options.

Please note that some features and settings will not appear on your Cisco Aironet Access Point as they are supported only on specific models:

Cisco Aironet Network Interfaces: Radio0-802.11a/b/g Settings

Enable Radio

Current Status (Software/Hardware)

• Software - Indicates whether the interface has been enabled or disabled by the user.

• Hardware - Indicates whether the line protocol for the interface is up or down.

Role in Radio Network

Select the role of the access point on your network. Choose one of the three access point (root) settings if the access point is connected to the wired LAN.

Access Point Root (Fallback to Radio Island)
This default setting enables wireless clients to continue to associate even when there is no connection to the wired LAN.

When you are running your own web hosting, it is important to monitor how much space is being used by each user. This is not a simple task to be done manually since one of the users or group could fill up the whole hard disk, preventing others from availing any space. Therefore, it is important to allow each user or group their own hard disk space called quota and locking them out from using more than what is allotted.

The system administrator sets a limit or a disk quota to restrict certain aspects of the file system usage on a Linux operating system. In multi-user environments, disk quotas are very useful since a large number of users have access to the file system. They may be logging into the system directly or using their disk space remotely. They may also be accessing their files through NFS or through Samba. If several users host their websites on your web space, you need to implement the quota system.

How to Install Quota

For installing a quota system, for example, in your Debian or RedHAT Linux system, you will need two tools called ‘quota’ and ‘quotatool’. At the time of installation of these tools, you will be asked if you wish to send daily reminders to users who are going over their quotas.

Now, the administrator also needs to know the users that are going over their quota. The system will send an email to this effect, therefore the email address of the administrator has to be inputted next.

In case the user does not know what to do if the system gives him a warning message, the next entry is the contact number of the administrator. This will be displayed to the user along with the warning message. With this, the quota system installation is completed.

At this time, a user and a group have to be created and proper permissions given. For creating, you have to assume root status, and type the following commands:

Next, these have to be mounted in the proper place on the root file system. For this, an entry has to be made in the ‘fstab’ file in the directory /etc. In the ‘fstab’ file, the root entry has to be modified with:

 The system is now able to work with disk quotas. However, you have to allow the system to build/rebuild its table of current disk usage. For this, you must first run quotacheck.

This will examine all the quota-enabled file systems, and build a table of the current disk usage for each one. The operating system’s copy of the disk usage is then updated. In addition, this creates the disk quota files for the entire file system. If the quota already existed, they are updated. The command looks like:

 Some explanation is necessary here. The (-a) tells the command that all locally mounted quota-enabled file systems are to be checked. The (-v) is to display the status information as the check proceeds. The (-u) is to enable checking the user disk quota information. The (-g) is to enable checking the group disk quota information. Finally, the (-m) tells the command not to try to remount file system read-only.

After checking and building the disk-quota files is over, the disk-quotas have to be turned on. This is done by the command ‘quotaon’ to inform the system that disk-quota should be enabled, such as:

Here, (-a) forces all file systems in /etc/fstab to enable their quotas. The (-v) displays status information for each file system. The (-u) is for enabling the user quota. The (-g) enables the group quota.

Define Quota for Each User/Group

Now that the system is ready with quotas, you can start defining what each user or group gets as his limit. Two types of limits can be defined. One is the soft limit and the other is the hard limit. To set the two limits try editing the size and inode size with:

You may be a user at home, a user in a LAN (local area network), or a system administrator of a large network of computers. Alternatively, you may be maintaining a large number of servers with multiple hard drives. Whatever may be your function, monitoring your Linux system is of paramount importance to keep it running in top condition.

While monitoring a complex computer system, some of the basic things to be kept in mind are the utilization of the hard disk, memory or RAM, CPU, the running processes, and the network traffic. Analysis of the information made available during monitoring is necessary, since all the resources are limited. Reaching the limits or exceeding them on any of the resources could lead to severe consequences, which may even be catastrophic.

Monitoring the Hard Disk Space

Use a simple command like:

This shows there are two partitions (1 & 2) of the hard disk sda, which are currently at 24% and 72% utilization. The total size is shown in gigabytes (G). How much is used and balance available is shown as well. However, checking each hard disk to see the percentage used can be a big drag. It is better that the system checks the disks and informs you by email if there is a potential danger. Bash scripts may be written for this and run at specific times as a cron job.

For the GUI, there is a graphical tool called ‘Baobab’ for checking the disk usage. It shows how a disk is being used and displays the information in the form of either multicolored concentric rings or boxes.

Monitoring Memory Usage

Basic Features of VIM (Vi IMproved) - The Linux Editor

When you are using Vim, you want to know three things - getting in, moving about and getting out. Of course, while doing these three basic operations, you would like to do something meaningful as well. So, we start with getting into Vim.

Assuming that you are in a shell, or in the command line, you can simply type 'vim' and the application starts:

Exiting the VIM application is easily accomplished: type ':' followed by a 'q', hit the 'Enter' key and you are out:

That's how you start and stop the Vim car. Now, let's try to learn how to steer the car.

You can move around in Vim, using the four arrow keys. However, a faster way is to use the 'h', 'j', 'k' and 'l' keys. This is because the keys are always under your right hand and you do not need to move your hand to access them as with the arrow keys. The 'j' moves the cursor down, 'k' moves it up. The 'h' key moves the cursor left, while 'l' moves it to the right. That's how you steer the Vim car.

You can edit a file using Vim. You either have an existing file, or you make a new one. If you start with 'vim filename', you edit the file represented by the 'filename'. If the file does not exist, Vim will create a new file. Now, if you want to edit a file from within Vim, open the file using ':e filename'. If this file is a new file, Vim will inform you. You can save the file using the ':w' command.

If you need to search the file you are editing for a specific word or string, simply type forward-slash '/' followed by the word you would like to search for. After hitting 'enter', VIM will automatically take you to the first match.  By typing forward-slash '/' again followed by 'enter' it will take you to the next match.

To write or edit something inside the file, you can start by typing ':i' and Vim will enter the 'Insert' mode. Once you have finished, you can exit the Insert mode by pressing the 'Esc' key, and undo the changes you made with ':e!'. You also have a choice to either save the file using the ':w' command, or save & quit by using ':wq'. Optionally, you can abort the changes and quit by ':q!'.

If you have made a change and want to quit without explicitly informing Vim whether you want to save the file or not, Vim will rightly complain, but will also guide you to use the '!'.

Command Summary

Advanced Features of VIM

In the previous articles, we spoke about the Internet Domain Hierarchy and explained how the ROOT servers are the DNS servers, which contain all the information about authoritative DNS servers the domains immediately below e.g firewall.cx, microsoft.com. In fact, when a request is passed to any of the ROOT DNS servers, they will redirect the client to the appropriate authoritative DNS server, that is, the DNS server in charge of the domain.

For example, if you're trying to resolve firewall.cx and your machine contacts a ROOT DNS server, the server will point your computer to the DNS server in charge of the .CX domain, which in turn will point your computer to the DNS server in charge of firewall.cx, currently server with IP 74.200.90.5.

The Big Picture

As you can see, a simple DNS request can become quite a task in order to successfully resolve the domain. This also means that there's a fair bit of traffic generated in order to complete the procedure. Whether you're paying a flat rate to your ISP or your company has a permanent connection to the Internet, the truth is that someone ends up paying for all these DNS requests ! The above example was only for one computer trying to resolve one domain. Try to imagine a company that has 500 computers connected to the Internet or an ISP with 150,000 subscribers - Now you're starting to get the big picture!

All that traffic is going to end up on the Internet if something isn't done about it, not to mention who will be paying for it !

This is where DNS Caching comes in. If we're able to cache all these requests, then we don't need to ask the ROOT DNS or any other external DNS server as long as we are trying to resolve previously visited sites or domains, because our caching system would "remember" all the previous domains we visited (and therefore resolved) and would be able to give us the IP Address we're looking for !

Note: You should keep in mind that when you install BIND, by default it's setup to be a DNS Caching server, so all you need to do it startup the service, which is called 'named'.

Almost all Internet name servers use name caching to optimise search costs. Each of these servers maintains a cache which contains all recently used names as well as a record of where the mapping information for that name was obtained. When a client (e.g your computer) asks the server to resolve a domain, the server will first check to see whether it has authority (meaning if it is in charge) for that domain. If not, the server checks its cache to see if the domain is in there and it will find it if it's been recently resolved.

So far we have covered in great detail the main files required for the firewall.cx domain. These files, which we named db.firewall.cx and db.192.168.0, define all the resouce records and hosts available in the firewall.cx domain.

We will be analysing these files in this article, to help you understand why they exist and how they fit into the big picture :)

Our Common Files

There are 3 common files that we're going to look at, of which the first two files contents change slightly depending on the domain. This happens because they must be aware of the various hosts and the domain name for which they are created. The third file in the list below, is always the same amongst all DNS servers and we will explain more about it later on.

So here are our files:

• named.local or db.127.0.0
• named.conf
• named.ca or db.cache

The named.local File

The named.local file, or db.127.0.0 as some might call it, is used to cover the loopback network. Since no one was given the responsibility for the 127.0.0.0 network, we need this file to make sure there are no errors when the DNS server needs to direct traffic to itself (127.0.0.1 IP Address - Loopback).

When installing BIND, you will find this file in your caching example directory: /var/named/caching-example, so you can either create a new one or modify the existing one to meet your requirements.

The file is no different than our example db.addr file we saw previously:

That's all there is for named.local file !

The named.ca File

The named.ca file (also known as the "root hints file") is created when you install BIND and dosen't need to be modified unless you have an old version of BIND or it's been a while since you installed BIND.

The purpose of this file is to let your DNS server know about the Internet ROOT Servers. There is no point displaying all of the file's content because it's quite big, so we will show an entry of a ROOT server to get the idea what it looks like:

If you are wondering how is it that the Slave DNS server is easy to setup, well you need to remember that all the Slave DNS server does is update its database from the Master DNS server (zone transfer) so almost all the files we configure on the Master DNS server are copied to the Slave DNS server, which acts as a backup in case the Master DNS server fails.

Setting up the Slave DNS Server

Let's have a closer look at the requirements for getting our Slave DNS server up and running.

Keeping in mind that the Slave DNS server is on another machine, we are assuming that you have downloaded and successfully installed the same BIND version on it. We need to copy 3 files from the Master DNS server, make some minor modifications to one file and launch our Slave DNS server.... the rest will happen automatically :)

So which files do we copy ?

The files required are the following:

• named.conf (our configuration file)
• named.ca or db.cache (the root hints file, contains all root servers)
• named.local (local loopback for the specific DNS server so it can direct traffic to itself)

The rest of the files, which are our db.DOMAIN (db.firewall.cx for our example) and db.in-addr.arpa (db.192.168.0 for our example), will be transferred automatically (zone transfer) as soon as the newly brought up Slave DNS server contacts the Master DNS server to check for any zone files.

How do I copy the files ?

There are plenty of ways to copy the files between servers. The method you will use depends on where the servers are located. If, for example, they are right next to you, you can simply use a floppy disk to copy them or use ftp to transfer them.

If you're going to try to transfer them over a network, and especially over the Internet, then you might consider something more secure than ftp. We would recommend you use SCP, which stands for Secure Copy and uses SSH (Secure SHell).

SCP can be used independently of SSH as long as there is an SSH server on the other side. SCP will allow you to transfer files over an encrypted connection and therefore is preferred for sensitive files, plus you get to learn a new command :)

The command used is as follows: scp localfile-to-copy username@remotehost:desitnation-folder. Here is the command line we used from our Gateway server (Master DNS): scp /etc/named.conf root@voyager:/etc/