6.2 Configuration Details

 < Day Day Up > 



Bridging has been around for a long time and so the 802.11 wireless bridges for the enterprise environment are configured in a similar way, regardless of manufacturer. The screens in the configuration utilities are different, but they ask for the same basic information. If there are any differences, it is usually in the granularity of the configuration information. In other words, instead of accepting default configurations, the network manager is given the opportunity to enter very precise information in order to have maximum control of all aspects of network operation. Consumer products, on the other hand, stress ease of use and generally do not offer as much choice in setting the configuration.

To configure the bridge for the first time, the console connection is used for setting up initial configuration information. This is accomplished by attaching the console port cable to the console port on the bridge. The other end of the console cable is attached to the serial port on a terminal or PC running a terminal emulation program. The terminal is usually set to 9,600 baud, 8 data bits, no parity, 1 stop bit, and Xon/Xoff flow control. Future changes to the bridge can be made over the wireless link, including firmware upgrades.

  • Service set identifier. The console port is used to set the service set identifier (SSID), which allows the wireless bridge to communicate with other nodes. The SSID is a case-sensitive identifier of up to 32 alphanumeric characters that is attached to selected packets sent out over the radio network. It can be a plain text description for easy identification such as “Cisco_Aironet.” All devices on the same wireless network must have the same SSID or their association requests will be ignored. This same SSID is assigned to all bridges, as well as access points and clients.

  • IP address. To enable remote access to the bridge using Telnet, Hypertext Transfer Protocol (HTTP), or SNMP, the bridge must be assigned an IP address. If there are multiple bridges on the wireless network, each of them must be assigned a unique IP address. The network administrator can also assign other detailed Internet addressing options, such as gateway address, subnet mask, or SNMP configuration.

  • DHCP or BOTP. By default, the bridge is configured to attempt to get a DHCP or Boot Protocol (BOTP) server to assign it an IP address. With BOTP, IP addresses are assigned based on MAC addresses. With DHCP, IP addresses are “leased” for predetermined periods of time.

On power up, the bridge will issue boot protocol requests to see if there are any BOTP or DHCP servers on the network. If a response is received, an IP address is assigned by the server. If multiple responses are received, the bridge will pick a DHCP server over a BOTP server. If there is no response, the request is repeated up to 30 times. If there is still no response, the unit gives up. It is recommended, however, that a static IP address be assigned to the bridge to simplify network management and prevent delays in receiving an address through DHCP or BOTP.

  • Subnet mask. If the network uses subnets, a default gateway and an IP subnet mask will be needed for the bridge. The subnetwork mask determines the portion of the IP address that represents the subnet ID, which is used to group devices based on the network topology.

  • Domain name servers. A domain name server allows the network administrator to specify the plain language name of a known host rather than its raw IP address when accessing another node in the network. The IP addresses of the primary and backup domain name servers are entered into the appropriate fields using the bridge’s configuration utility.

  • IP routing table. The IP routing table controls how IP packets originating from the bridge will be forwarded. If the destination IP address exactly matches a host entry in the table, the packet will be forwarded to the MAC address corresponding to the next-hop IP address from the table entry. If the destination is in the local subnet, the Address Resolution Protocol (ARP) is used to determine the node’s MAC address.

If the destination address is on another subnet and matches the infrastructure portion of a net entry in the table, using the associated subnet mask, the packet will be forwarded to the MAC address corresponding to the next-hop IP address from the table entry. If the destination address is on another subnet and does not match any entry in the table, the packet will be forwarded to the MAC address corresponding to the default gateway’s IP address.

  • Root configuration. The default setting for a bridge is a root bridge. A root bridge is located at the top, or starting point, of a wireless infrastructure. The root bridge is usually connected to the main wired backbone LAN. Since the radio traffic from the other bridges’ LANs will pass through this unit, the root unit is usually connected to the LAN that originates or receives the most traffic.

Before performing a detailed configuration of a bridge, the network administrator-should determine whether it will be a root bridge or a nonroot bridge. A nonroot bridge, sometimes referred to as a remote or repeater bridge, establishes a connection to the root bridge or another repeater bridge to make the wired LAN to which it is connected part of the bridged LAN. Changing the default root bridge simply involves accessing the bridge’s configuration utility using a terminal emulator or browser and selecting “on” or “off” for the Enable root mode setting.

Once the bridge is configured as a root or nonroot unit, the network administrator can quit the terminal emulator or browser, disconnect the console port cable, and install the bridge in its desired location. After installation, an antenna alignment test should be run before proceeding with remote configuration. This test can be run from a utility installed on a client or from a wireless LAN management system. The antenna test displays signal strength and signal quality, in a text or graphical format (see Table 6.1). The test can be used to verify the link to each radio partner or to monitor signal strength while aligning directional antennas between two nodes. As the antennas are moved, the signal strength can be monitored to achieve the highest level.

Table 6.1: Sample Antenna Alignment Test Results

ID

Name

Address

Signal Strength

Signal Quality

15

North Bridge

00409631158c0

100% –10 dBm

100%

14

North Bridge

00409631158c0

100% –10 dBm

100%

13

North Bridge

00409631158c0

100% –10 dBm

95%

12

North Bridge

00409631158c0

100% –10 dBm

97%

11

North Bridge

00409631158c0

100% –10 dBm

100%

10

North Bridge

00409631158c0

100% –10 dBm

99%

9

North Bridge

00409631158c0

100% –10 dBm

100%

8

North Bridge

00409631158c0

100% –10 dBm

100%

7

North Bridge

00409631158c0

100% –10 dBm

97%

6

North Bridge

00409631158c0

100% –10 dBm

100%

5

North Bridge

00409631158c0

100% –10 dBm

100%

4

North Bridge

00409631158c0

100% –10 dBm

100%

3

North Bridge

00409631158c0

100% –10 dBm

100%

2

North Bridge

00409631158c0

100% –10 dBm

100%

1

North Bridge

00409631158c0

100% –10 dBm

100%

The test works by sending a packet once per second to the parent access point. This packet is echoed back to the bridge, which records and displays the RF signal strength associated with that particular node. The network administrator can choose the duration of the test, from 15 to 60 seconds. The columns provide the following information:

  • ID: This is the sequence number of the data sample. The most recent sample appears at the top of the column. In this test, there are 15 data samples.

  • Name: This is the system name of each device in the antenna alignment test.

  • Address: This is the MAC address of the device involved in the alignment test.

  • Signal strength: The left side of this column displays the percentage of signal strength between the bridge and the other device; the right side of the column displays signal strength in dBm.

  • Signal quality: This column shows the quality of the signal link between the bridge and the other device.

Data rate The network administrator can define the rate at which the bridge is allowed to receive and transmit data. When a repeater associates to a root bridge, data is usually transmitted between the units at the highest rate that they both support. The units can also downshift to use lower common rates if conditions warrant it. The basic rates option is set on the root bridge. It is the set of rates that all nodes in the radio cell must support or they will not be allowed to associate.

The lowest basic rate is used to transmit all broadcast and multicast traffic, as well as any association control packets. Using the lowest rate helps ensure they will be received by all nodes, even at the farthest distances. The highest basic rate determines the maximum rate at which an acknowledge packet may be transmitted.

Frequency The actual frequency allowed depends on the regulatory body that controls the radio spectrum in the location in which the unit is used. If the setting is left as “auto,” the unit will sample all the allowed frequencies when it is first started and try to pick one that is not in use. This setting is only allowed on the root unit, since it is in charge of setting up the radio cell.

Range Since the radio link between bridges can be quite long and vary between individual devices, the time it takes for the radio signal to travel between the radios can become significant. The range parameter is used to adjust the various timers used in the radio protocol to account for the extra delay. The parameter is only entered on the root bridge, which will inform all the other units. The range is entered as the distance in kilometers of the longest radio link in the set of bridges.

Beacon interval The beacon interval is expressed as K µ s, which is 1,024 microseconds, or a kilo-microsecond. The beacon packets are primarily used for radio network synchronization. A small beacon period means faster response for roaming nodes.

Broadcast SSID When the bridge is configured as an access point, this option controls whether client nodes will be allowed to associate with the unit if they specify the empty or broadcast SSID. Clients that do not know the SSID of the bridge can transmit packets with the broadcast SSID. Any bridges present will respond with a packet showing their SSID. The client will then adopt the SSID and associate with that device. However, if the network administrator wants to ensure that clients know the SSID beforehand, this function can be disabled.

RTS/CTS The IEEE 802.11b standard specifies an optional request to send/ clear to send (RTS/CTS) protocol. This four-way handshake protocol reduces the probability of data collisions at the bridge or access point (see Figure 6.3). When a sending node wants to transmit data, it first sends an RTS message and waits for the bridge to reply with a CTS message. Since all nodes in the network are listening, the CTS causes them to delay any intended transmissions, allowing the sending node to transmit data and receive a packet acknowledgment (ACK).

click to expand
Figure 6.3: This four-way handshake occurs between the sending node and the access point or bridge. Its purpose is to minimize the chance of data collisions at the access point or bridge when multiple nodes have data to send.

This setting in the configuration tool specifies the size of the data packet that the low-level RF protocol issues to an RTS packet. The range of this parameter is 0 to 2,048 bytes. A small value causes RTS packets to be sent more often and, when this occurs, more of the available bandwidth is consumed and the throughput of other network packets is reduced. On the upside, however, the system is able to recover faster from interference or collisions, which may be caused from a high multipath environment characterized by obstructions or metallic surfaces.

The RTS and CTS packets are small and, if lost in a collision, they can be retried more quickly and with less overhead than if a larger packet containing real data must be retried. The downside of using RTS/CTS is that for each data packet transmitted, another packet must be transmitted and received, which affects throughput.

Packet encryption This parameter controls the use of encryption on the data packet transmitted over the wireless link, which is usually 40/64-bit or 128-bit WEP, but depending on vendor may also include 256-bit enhanced WEP. The packets are encrypted using any one of up to four known keys. Each node in the radio cell must know all the keys in use. Not only must all nodes in the wireless network know the keys in use, but they must be entered into the fields of the configuration utility in the same order.

Only one of these keys is used for transmitting data. This key is selected by the network administrator. Each wireless device is capable of decrypting received packets sent with any of the four keys. Any unencrypted data received by these devices will be discarded. Of course, the network administrator can also choose not to encrypt data, but this would leave transmissions exposed to hackers.

A root bridge can be set to accept association from clients that have encryption enabled or disabled. A situation where this might be used is in the mixed vendor environment, to ensure compatibility between devices. But this mixed mode of operation is not recommended for security reasons. If a client with encryption enabled sends a multicast packet to its parent, the packet will be encrypted. The parent will then decrypt the packet and retransmit it to the cell for all other nodes to see. If a hacker sees a packet in both encrypted and unencrypted form, this can make it much easier to break a key.

Time The bridge can be configured to query a network time server so that any logs can reference the current date and time. Since the time returned by the network time server is based on Greenwich mean time (GMT), the network administrator must adjust this parameter to display the time in an appropriate local format. Another option is used to select whether a particular time zone uses daylight savings time so that the change is implemented automatically.



 < Day Day Up > 



LANs to WANs(c) The Complete Management Guide
LANs to WANs: The Complete Management Guide
ISBN: 1580535720
EAN: 2147483647
Year: 2003
Pages: 184

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net