ExtremeControl Performance Tuning (Legacy)
The following sections provide detailed information on how to use specific ExtremeControl tools and features to monitor and improve ExtremeControl performance.
- Monitoring Active End-Systems
- Tuning Data Persistence
- Tuning ExtremeControl Capacity
- Using ExtremeControl Distributed Cache
Monitoring Active End-Systems
Monitoring the total number of active end-systems on the network, as well as the number per engine, is useful in determining whether authentication load is distributed evenly between available ExtremeControl engines. Some engines can be at or near capacity, while others can be underutilized and available to handle additional end-systems. Use this information to review your primary and secondary ExtremeControl engines and the switches that authenticate against each engine, to determine whether you need to make adjustments to more evenly distribute the load. The goal is to evenly distribute the authentication and captive portal load across all available ExtremeControl engines as much as possible.
Engine capacity information also provides data points you can use for capacity planning and determining future hardware needs based on current load and expected growth, as well as targeting areas for design improvements such as implementing additional redundancy and disaster recovery.
As you study the capacity information, keep in mind that an engine failure for any reason means that end-systems authenticating against that engine now authenticates against the designated backup engine. In an environment where there are two ExtremeControl engines each responsible for authenticating 2,500 end-systems, a single engine outage can mean that all 5,000 end-systems might possibly authenticate against the one remaining engine. Depending on a variety of factors, oversubscribing an engine could lead to scenarios such as failed or intermittent authentication responses, poor end-user experience, or restricted access to the network.
NOTE: | Any authentications previously performed by the unavailable primary engine remain authenticated until the session is removed or times out. At that point, subsequent authentication requests are sent to the backup engine. Whether authentication requests automatically revert to the primary engine when it is deemed available is a function of individual switch RADIUS operation. |
Locating the End-System and Capacity Information
The Configuration tab in NAC Manager displays authenticated end-system and capacity information for each ExtremeControl engine. To view this information, select an ExtremeControl engine in the NAC Manager tree and then select the Configuration tab. The Current Capacity field indicates the number of end-systems that have authenticated to the ExtremeControl engine within the last 24 hours out of the total supported authentication capacity for the ExtremeControl engine. For example, a current capacity value of 1365/3000 indicates that 1,365 end-systems have authenticated against this ExtremeControl engine within the last 24 hours, and this specific engine is rated to handle 3,000 authentications. The total number of supported authentications can vary depending on enginetype.
Configuration Tab - Current Capacity
To view capacity information for all ExtremeControl engines in one place, select the All NAC Appliances folder in the tree and select the NAC Appliances tab. The authenticated user counts and engine capacity are displayed under the Capacity column.
NAC Appliances Tab - Capacity
Engine load reporting is also available within ExtremeCloud IQ Site Engine. The NAC Appliance Load report provides a summary of end-system usage for each ExtremeControl engine on the network, including the number of active end-systems on the engine, and the number of authentication and captive portal requests per minute.
Tuning Data Persistence
ExtremeControl Data Persistence options provide granular control for defining how long end-system and end-system related information is retained and stored. These options let you customize the aging of stale end-systems, as well as the length of time to retain end-system events and end-system assessment health results.
Access Administration > Options > Access Control > Data Persistance to open the Data Persistance options tab. The options included in the three sections of the window are described below.
Age End-Systems
Retaining large amounts of stale end-system data can lead to ExtremeCloud IQ Site Engine client performance issues as well as server performance degradation in larger networks or on ExtremeCloud IQ Site Engine servers that do not have optimal hardware. Reducing unnecessary stale data in the database leads to improved performance, smaller (and faster) backup files, as well as reduced disk utilization on the server. (Performance differences vary between individual ExtremeControl deployments.)
By default, stale end-systems are aged out after 90 days of inactivity. In high volume networks with frequent short-term users (for example, an environment with a lot of visitors or contractors), you can change the number of days to a lower amount. Aging stale end-systems removes inactive and potentially one-time end-systems from the database and NAC Manager tables, making it easier to monitor and locate active end-systems on the network.
The option to remove associated MAC locks and occurrences in groups is disabled by default. For networks with a large volume of short-term authentications, as well as users who connect to the network infrequently but on a recurring basis, this ensures these end users retain any assigned end-system group membership and are authorized against the proper ExtremeControl rule the next time they authenticate to the network, should their end-system age out. If this is not a concern, consider selecting this option to remove group membership. Excessively large end-system groups can have an impact on both the server and engine. This varies by deployment, but generally, networks containing end-system groups with 30,000 to 35,000 end-systems should have this option selected to ensure stale data is properly handled.
By default, end-system registration data associated with stale end-systems is also removed when an end-system ages out. Even though registrations have an independent expiration timer and removal option, this removes registrations associated with stale end-systems prior to the defined registration expiration, maintaining active end-system registrations in the database and keeping end-system and registration information in sync.
End-System Event Persistence
End-system events track authentication and ExtremeControl related activity such as IP and OS resolution, state changes, and assessment information. These events are maintained in memory and are archived in log files on the ExtremeCloud IQ Site Engine server. Due to the high volume of event activity, the option to persist non-critical events is disabled by default, and certain non-critical end-system events are not retained. (Examples of non-critical events include duplicate or unchanging events, such as events tied to reauthentication where an end-system's state hasn't changed.) Removing events that are redundant or show no change leaves more space to retain those events that do indicate active changes, maintaining end-system event efficiency.
However, networks with fewer end-systems, or those not utilizing ExtremeControl features that create additional events such as registration and assessment, could choose to enable the option to persist non-critical events, since they can display events maintained in memory for a longer period than those in a more dynamic environment.
End-system events are stored in log files on the ExtremeCloud IQ Site Engine server. These logs are available in the <install directory>/Extreme_Networks/NetSight/appdata/logs directory and are identified by the filename convention: nacESE.date_version.log (for example, nacESE.2012_12_31_01.log, nacESE.2012_12_31_02.log). Events are continuously saved in the nacESE files with each individual file growing to about 5 MB before it is archived and a new log file is started for that day. Each day, when the Data Persistence check runs, it removes all log files that are older than the number of days specified (90 days by default). The length of time to retain the log files depends on your security policy (how long records need to be kept), system hardware limitations (disk availability), and the overall amount and type of activity logged.
The number of end-systems and activity on the network directly impacts the number of nacESE event log files generated on a daily basis. Monitoring the number of files generated for a period of time provides a baseline of the amount of space being consumed by these events and helps determine whether additional action is required to manage them.
Health Result Persistence
By default, a health result summary is saved for the last 30 assessments per end-system. A full, detailed health result report is retained for the last five assessments for each individual end-system. The number of summaries and detailed reports to save depends on your company's security policy, and how long summary and detailed assessment data is required.
For example, in an environment where end-systems are managed and generally compliant, retaining extended detailed assessment results is not necessary. Whereas, in some environments, end-system monitoring is much more stringent and specific guidelines specify the length of time this type of data must be retained. Other factors to consider when reviewing these settings are the frequency, level (heavy versus light), and type of scans (agent-less or agent-based) being performed.
If you select the option to only save health result details for quarantined end-systems, all health result details resulting in an Accept State are discarded. This applies only to agent-less assessment, as agent-based health result details are always saved for all end-systems, regardless of whether the result indicates an Accept or Quarantine state. (The number of health result details saved is determined by the option described above.)
You can select an option to save duplicate health result summaries and details, if desired. By default, duplicate health results are not saved. For example, if an end-system is scanned five times during the week with identical assessment results each time, the duplicate health results are not saved (with the exception of administrative scan requests such as Force Reauth and Scan, which are always saved). This reduces the number of health results saved to the database.
Tuning ExtremeControl Capacity
The NAC Capacity option in NAC Manager controls the configuration of internal ExtremeCloud IQ Site Engine resources (server processing queues, timing, etc.) allocated to ExtremeControl services. These resources are specifically targeted towards the processing of incoming end-systems, end-system events, and health result data sent from ExtremeControl engines to the server. The greater the number of end-systems and engines in your ExtremeControl deployment, the more resources ExtremeControl services require for processing the incoming information updates sent by each ExtremeControl engine.
Indications that capacity settings are insufficient can surface in the form of slower processing of end-system information or possibly missing updates. Modifying the capacity level upwards, incrementally allocates additional server resources dedicated to the processing of this data. Each level provides increased queue sizes to handle the greater volume of incoming data. In addition, changes are made in the frequency in which data is saved, as well as the amount of data saved in each operation. The changes enable ExtremeCloud IQ Site Engine to more efficiently process the larger amount of data.
If insufficient resources is not the actual problem, the allocation of additional resources can ultimately have little or no effect on performance. Because of this, it is important to first verify that the ExtremeCloud IQ Site Engine server is installed on a system with appropriate resources in terms of both hardware and role (a dedicated management server versus one performing multiple roles) and that the resources are commensurate with the size of the ExtremeControl deployment.
Insufficient server hardware could appear as an ExtremeCloud IQ Site Engine performance issue, where in reality, the server hardware resources are not adequate for the deployment.
To adjust ExtremeControl Capacity, access the NAC Manager options. From the NAC Manager menu bar, select Tools > Options to open the Options window. Expand the NAC Manager Options folder and select Advanced Settings.
Advanced Settings Options - NAC Capacity
Using ExtremeControl Distributed Cache
The ExtremeControl distributed end-system cache is an optimization recommended for large enterprise environments as engine a way to improve response times when handling end-system mobility. Enabling this option improves ExtremeControl performance when discovering new end-systems as they connect, or when end-systems move (and authenticate) from one location to another in the network.
Use of the distributed end-system cache feature requires that it is activated on both the ExtremeCloud IQ Site Engine server and on all ExtremeControl engines in order to take advantage of the optimized communications. (See the instructions below.)
NOTE: | The Distributed end-system cache functionality must be enabled in environments using the ExtremeControl DNS Proxy to redirect clients to the captive portal. |
When this feature is enabled, end-system information similar to that in the end-systems table is stored in memory on the ExtremeCloud IQ Site Engine server and ExtremeControl engine. Each cache contains the same up-to-date information, enabling the engine to perform lookups for end-system information in its local memory cache instead of having to query the server for updated information. Any changes to end-system information are propagated from each to the ExtremeCloud IQ Site Engine server, which then replicates updates to each ExtremeControl engine so all have a synchronized copy of real time end-system information.
Implementation of this feature is not recommended unless there is sufficient network bandwidth available to handle the additional overhead in communicating updates, as well as a fast connection between the ExtremeCloud IQ Site Engine server and the ExtremeControl engine. Take additional consideration prior to implementing this functionality on engines that reside in a location where the data path traverses a WAN link.
To enable on the ExtremeCloud IQ Site Engine server:
Select the Enable Distributed End-System Cache option on the Administration > Options > Access Control > Advanced tab. Enabling this option requires an enforce of the engine.
To enable on the ExtremeControl engine:
From the NAC Manager menu bar, select Tools > Options to open the Options window. Expand the NAC Manager Options folder and select Advanced Settings. The option is in the End-System Mobility section. When you enable or disable this option, you must select the Reload button to reload the cache configuration on the ExtremeCloud IQ Site Engine server.
04/2025
25.02.12 Revision -00
Contents Subject to Change Without Notice