Banyan Virtual Integrated Network Service (VINES) is a network operating system based on proprietary protocol family. The protocol is basically derived from Xerox Network Systems (XNS) protocols, where it uses a client-server architecture that enables clients to request specified services like file and printer access from servers.
LANtastic supports a wide variety of PC operating systems like Windows NT 4.0/2000/2003 (Workstation and/or Server), and Windows XP. It comes with an enhanced multi-platform support. The installation and operation of the system is fast and user friendly, along with an improved interface that allows all networked PCs to be able to communicate by just using the Chat feature. Users are not required to employ a dedicated server or a full-time network manager because the system is simple and easy to maintain.
Once stationary usage of the applications is working satisfactorily, run tests to verify that users moving throughout the coverage areas are able to continue operating the applications successfully. When testing, be certain to move about the coverage area at typical and maximum speeds that users will operate the applications. This is necessary because roaming tends to break down at higher speeds. Also, run a wireless packet sniffer to record packet transmissions between the client device and the network. This will help you better understand the underlying issues if you run into problems. For example, you might see significant delays when the system is re-establishing the flow of packets when the client device radio hands off from one access point to another. By looking at the packet trace, you may also see that a client device is experiencing significant retransmissions with a particular access point before handing off to another access point with better signal quality, which would point to issues with the client radio’s ability to roam. For wireless IP applications, place a call and walk through the facility while talking to someone on a wired phone. As you walk, monitor the voice quality. If everything is working okay, you should hear consistent quality as you traverse the facility and the phone roams from one access point to another. If you detect poor sound quality at any point, check the signal strength indicator on the phone. A reduction of sound quality may occur when the signal strength is low. To make roaming phone call tests easier to perform, wear an earpiece for listening to the voice quality and monitoring the signal strength indicator on the phone at the same time. When performing the roaming tests, ensure that the phone can “see” at least two access points (each on nonoverlapping channels) from anywhere within the covered area. This can often be done by observing the phone’s wireless connection utility. If two or more access points cannot be seen on nonoverlapping channels, a phone roaming from one access point to another may not be smooth enough to maintain good voice quality. To make voice quality consistent, you might need to reengineer the wireless network by moving access points or adding additional access point. If the phone is connected to a particular access point and does not roam even if located directly under another access point, there may be more than one access point having relatively high signal strengths on overlapping RF channels. In this case, you may be able to fix the problem by adjusting the transmit power of one of the access points. Or, you might need to reengineer the WLAN. Another reason that the phone may not be roaming in this scenario is that the nearby access point is not operating. So, check the status of the access point. Another problem with roaming is that the phone may roam from one access point to the other too slowly. In this case, check the phone wireless utility to ensure that there is indeed another acceptable access point to roam to. The problem could be that there are no other access points having strong enough signal strength for the phone to roam. If the phone appears to roaming promptly to the next access point, there might still be excessive delay problems on the wired network infrastructure.
Sometimes the phone may roam okay with regard to the network, but the phone loses connection with the call manager. In this case, check to be certain that the phone is not traversing different IP subnets, which can cause a Layer 3 connection loss and disconnection from the call manager. In addition, if using Cisco LEAP, make certain that some of the access points are not blocking TCP ports associated with the LEAP protocol.
As final step when testing the performance of the WLAN, ensure that multiple users can use applications on the network. The goal here is to verify that the WLAN can continue to satisfy all requirements while a typical (and maximum) number of users are using the system. The best way to test load on the network is with actual users and client devices. In some cases, however, you may need to resort to simulation as explained later in this chapter. For example, with a wireless IP phone system, make use of multiple wireless IP phones throughout the facility. Ideally, distribute and use the phones in a similar manner as they will actually be used when operational. Find volunteers or actual users to help you with these tests. You can give them each a phone, instruct them on how to use it, and have them initiate calls with others. To simplify testing, you can start by having the group of callers place calls from the same location, and then have them separate uniformly throughout the facility while continuing voice conversations and monitoring voice quality. If requirements in parts of the facility specify a need for higher capacity, have an appropriate number of test users make use of the phones from that area. Again, strive to test the system as users will use it. While performing the load tests, monitor the system using network analyzers or system management tools, if available. Also, be sure to receive feedback from the users actually using the devices, and identify any related issues. If problems arise, note the applicable time and location in the facility where the problem occurred. Doing so makes it easier when looking through the results of the monitoring tools to identify the underlying problems.
Many WLAN systems implement 802.1X security mechanisms. If this is the case, ensure that the client device is successfully authenticating with the network. You can do so by observing the access point authentication status table or RADIUS server administration. If you are testing a wireless IP phone application, for example, be sure that each phone properly authenticates with the system. If only Wired Equivalent Privacy (WEP) security is in use, the phone will not authenticate with the access point if the WEP on the phone does not match the WEP key configured in the access point. In this case, the phone will not even associate with the access point. When using Lightweight Extensible Authentication Protocol (LEAP), the phone may associate with the access point but not authenticate with the LEAP authentication server. Therefore, verify that the phone is actually authenticating with the authentication server. To do this, you will probably need to access the authentication logs on the server. If the phone is not authenticating, check that the LEAP username and password entered in the phone are the same as those configured in the authentication server.