Review: Agere ORiNOCO AS-2000, part 2

by Lisa Phifer

Some setups are a breeze, while others reinforce the accuracy of Murphy's Law. Learn how the Agere ORiNOCO AS-2000 fared for configuration as we put it to the test on addressing and monitoring.

from ISP-Planet

In Part 1, we established the basic building blocks of our Agere WLANinstalling ORiNOCO cards, drivers, Client Manager, and AS Client software. Today, we continue our saga, describing AS-2000 installation, configuration, and monitoring, explaining how to integrate this wireless access server with an existing wired network.

AS-2000 and AS Manager
Surprisingly, the easiest component to install was the AS-2000. At 2 x 7 x 10", this petite device is easily mounted on a ceilingpower is optionally passed over Cat5 to the single 10/100 Ethernet port. Radio transmission occurs over ORiNOCO NICs, inserted into one or both CardBus slots. Status LEDs are visible with the removable plastic cover in place. The unit accepts an outside antenna, but is designed for indoor deployment.

In a pinch, the AS-2000 CLI (accessed by serial port or telnet) can be used to load image or configuration updates from a TFTP server or reconfigure addresses. Traffic counters are visible from the CLIa ping client would be a great addition. Admins can also monitor traps or administer the device using its enterprise MIB and a third-party SNMP manager.

Click for full sized image But most will use the AS Manager, a Java application for AS-2000 configuration and monitoring. We installed the AS Manager 2.03 and JRE 1.3 on NT Server and Windows 2000 PCs. At startup, the AS Manager scans attached subnet(s) to locate AS-2000s. Alternatively, AS-2000s can be added manually, identified by IP address. The first step is to select an AS-2000 and over-ride factory default addresses using Initial Device Setup. (Click on image to enlarge.) After renumbering, you may need to delete the old device and re-add or re-scan the subnet.

Device Configuration is password-protected by an SNMP community string with read-write permission. Use this menu to set system, network, physical interface, PPP, IAPP, SNMP, and RADIUS parameters.

System parameters include the ability to administratively take the AS-2000 offline now or later. SNMP parameters include an access table that limits administrative access to specified source IPs. (If you lock yourself out or forget the IPs entered here, you can get back in by resetting the device to factory defaults.)

Click for full sized image Physical interface parameters configure ORiNOCO radio cards in the AS-2000. (Click on image at left to enlarge.) Here you can specify a message size requiring RTS/CTS handshake for networks experiencing excessive frame collisions. Transmit rate, frequency, and density defaults are typically fine, but can be modified if desired.

IAPP parameters control communication between ORiNOCO base stations, such as announcement interval and response time, handover timeout and retransmission count. With only one AS-2000, we were unable to exercise handoffbut its intent is to enable roaming by eliminating the need to reconnect when moving from one AS to another.

Dynamic Address Assignment
The AS-2000 can be used in IP and IPX networks. Tech support runs into IPX infrequently, mostly at universities. We limited our testing to IP, and configured PPP parameters to exercise four methods of IP address assignment:

Click for full sized image 1)   In the simplest case, IP addresses are assigned from a local pool. (Click on image at right to enlarge.) The AS-2000 uses PPP IPCP to return the AS Client an unused address from this pool, along with DNS and WINS addresses (both required). The AS-2000 is a bridge, so addresses come from the same subnet as the AS-2000's Ethernet.

Click for full sized image 2)   Alternatively, IP addresses can be statically bound to specific MAC addresses. (Click on image at leftt to enlarge.) If the source NIC's MAC address appears in this table, the mapped IP is returned to the AS Client. Otherwise, an address can still be returned from the local poolthis table is not a MAC ACL.

Click for full sized image 3)   We also tested DHCP address assignment using a new 2.02.1 beta image. (Click on image at right to enlarge.) We let a DHCP server on the same LAN assign IP addresses. This beta also supports BOOTP/DHCP relay, acting as a DHCP proxy. When using DHCP assignment, beware that these values over-ride any assignments returned by RADIUS. Currently, there are no counters for DHCP, making problems hard to spot.

4)   Finally, a RADIUS server can be configured to supply IP addresses when accepting an Access Request. On the AS-2000, select RADIUS as the IP address assignment type and configure RADIUS parameters (discussed in the next section). Actual address assignments are configured on the RADIUS serverif RADIUS does not return an IP address, PPP session establishment fails.

PPP parameters also determine session idle timeout (disable if you want session timeout controlled by RADIUS) and the authentication protocol used between the AS-2000 and your RADIUS server (PAP or CHAP).

RADIUS Authentication
Click for full sized image Because the AS-2000 relies on RADIUS for authentication, RADIUS parameters must be configured, no matter which address assignment type is used (left). Two sets of parameters are required: a primary authentication server and a primary accounting server. Backup servers can also be configured.

Each RADIUS server is identified by IP address, destination port, and shared secret. These values must match those defined on your RADIUS serverin our case, the Interlink AAA Engine. The RADIUS Statistics button displays counters that are useful in diagnosing connectivity problems.

For example, if an AS Client cannot connect, check the Access Request counter. If this counter is not incrementing, the problem lies between the client and the AS-2000. Otherwise, check the Access Retransmissions counterthis signals connectivity or access issues between the AS-2000 and the RADIUS server. Otherwise, check the Access Rejects counterthis signals authentication failure, such as when the user supplied bad credentials.

We had no real issues integrating the AS-2000 with the Interlink AAA Engine. A bad route caused early retransmissionsthis is where traceroute would have been handy in the AS-2000. We also configured the AAA Engine to ignore an unencapsulated vendor-specific attribute (MAC address) supplied by the AS-2000. After this, it was smooth sailing.

In Part 3, we will cover monitoring.

This article was originally published on Thursday Sep 6th 2001