There are several factors that have an impact on performance.
- Log level. Logging can impact performance by as much as 50%. All logging should only be enabled when diagnosing problems.
- Key generation. FIPS 140-2 certification requirements impose heavy processor requirements during key generation. If the target architecture involves high log in rates, average more than 5 per second, it may be beneficial to reduce the rounds of SHA used in key generation or to disable the FIPS 140-2 certified function calls.
- Dynamic updates. Updates to the running LMC session involve obtaining a system write lock before performing the operation. This can interrupt VPN traffic for period of time it takes to do the update. NOTE: log level changes and resets do acquire the system lock.
- External look-up operations. Network delays in communicating with external software such as the configuration store can adversely effect performance. When possible, IP addresses and local host files should be used to avoid DNS look ups. On AIX, DNS queries can be forced to use the local hosts file prior to going to the DNS buy editing the /etc/netsvc.conf file.
- Transport profiles. It is imperative that a client session negotiate the correct transport profile for the type of network that is being used. Profiles are assigned based on keywords and/or network speed provided by the Mobility Client at log in and roam time. System administrators should verify that the correct profiles are being assigned. This can be done by checking the wg.log file for messages relating to the transport profile. The device information relating to the network transport (proposed by the client) can be viewed in the active session table either from the command line or by using Gatekeeper.
If the wrong transport profile is assigned, it may enable (or disable) optimization functions that are not appropriate for the given network causing overall performance issues for the session in question.
Additionally, the default transport profiles provided with LMC may not be optimal for your installation and underlying network infrastructure. We occasionally run into network service providers and local WiFi hardware that can require up to 100 bytes of the transmission unit. This means that MTU sizes in the applicable transport profile may need to be optimized to account for this. The network service provider should be able to provide you with MTU size requirements.
- Filters. Filters provide a means of keeping unwanted traffic out of the LMC tunnel reducing processing overhead on the server. Filters are associated with transport profiles to allow negotiation based on transport. You can have one set of filters applied to low bandwidth networks and another for high bandwidth. They are also an effective means of removing well-known virus traffic.
- TCP/IP configuration. TCP/IP buffers should be tuned to match throughput requirements of the installation. By default, the LMC initialization script /etc/rc.wgated contains statements for updating TCPIP network options before starting the Connection Manager. However, this script is only executed at system start up (after a reboot). Modifications to this script will require you to stop the wgated process and then run the script from the command line.
- FIPS 140-2. In addition to key generation, FIPS 140-2 certification requirements include serializing access to the crypto APIs. This can cause unnecessary delays in heavily loaded (high throughput) systems. If FIPS 140-2 compliance is not required, it is possible to disable it and remove this restriction. To disable:
# stopsrc -s wgated
# cd /opt/IBM/ConnectionManager/lib
# mv libewgcrypto.so libewgcrypto.sav
# startsrc -s wgated