ExtremeControl Deployment Guide (Legacy)

The ExtremeControl Deployment Guide provides technical and administrative information for deploying, managing, and troubleshooting your ExtremeControl deployment. The following topics are discussed:

• Phased Rollout Strategy
  • Authentication Only
  • Assessment without Quarantine
  • Location-Based Assessment and/or Registration
• Important Links in ExtremeControl and ExtremeCloud IQ Site Engine
  • ExtremeControl Pages on the ExtremeCloud IQ Site Engine Server
  • Assessment/Remediation and Registration Pages on ExtremeControl Engines
  • ExtremeControl Engine Administration Web Pages
• MAC and IP Resolution
  • MAC to IP Resolution
  • IP to MAC Resolution
• Agent-Based Assessment
  • Configure OS-Based Test Cases
  • Exclude End-Systems from Assessment Using MAC OUIs
• Third-Party Device Considerations
• ExtremeCloud IQ Site Engine Server Data Retention Tools
  • ExtremeControl Capacity Option
  • Data Persistence Options
• Troubleshooting
  • ExtremeControl Engine
  • ExtremeCloud IQ Site Engine Server
  • ExtremeCloud IQ Site Engine Server and ExtremeControl Engine Connectivity

Phased Rollout Strategy

The Extreme Networks ExtremeControl solution supports the five key network access control functions of detection, authentication, assessment, authorization, and remediation. These five ExtremeControl functions do not need to be implemented concurrently in an ExtremeControl deployment. ExtremeControl can be rolled out in a phased deployment approach with each phase building on the knowledge gained along the way. A phased approach helps you to avoid wide-scale problems that can be associated with deploying all ExtremeControl functionality simultaneously throughout the network. It allows you to fix any underlying network, end-system, or user perception issues as they appear in each phase, making for a smooth deployment process.

A phased deployment:

• Allows full control over infrastructure changes during deployment.
• Minimizes impact to business processes.
• Initially deploys each function without enforcement and verifies results before enabling enforcement.

Following is a suggested rollout strategy that includes three phased ExtremeControl deployments: Authentication Only, Assessment without Quarantine, and Location-Based Assessment and/or Registration.

Authentication Only

The first phase of the rollout strategy is called Authentication Only. In this phase, ExtremeControl operates in a passive mode, providing you with information about who and what is connecting to the network, and when and where those connections are taking place. At this stage of the deployment, any end-system connecting to the network is authenticated and gets the basic access policy. ExtremeControl is only detecting and tracking what is authenticating to your network; no access control decisions (apart from assigning the basic policy) are made. Then, as you come to understand what end-systems are connecting to the network, you can create ExtremeControl Configuration rules that allow you to provide different access to specific end-systems.

This phase also allows you to work out the basic RADIUS configuration (if RADIUS authentication is being used), and gives you time to spread the end-system load across the ExtremeControl engines by moving switches from one engine to another, as needed.

Assessment without Quarantine

The second phase of the rollout strategy is called Assessment without Quarantine. In this phase, ExtremeControl is again operating in a passive mode, allowing you to understand the health of devices on the network without impacting end user connectivity. This is done by enabling assessment with all policies (including the Quarantine policy) set to full access -- no end users will be denied access based on assessment results. Then in NAC Manager, you can use the End-Systems tab to view each end-system's state to determine how many end-systems would lose network access with the configured assessment security level. In this way, you can roll out ExtremeControl assessment, while avoiding problems that can  result from a large number of end users suddenly being quarantined and  unable to access the network because their patches or antivirus software aren't up-to-date. After these issues are fixed, then assessment with quarantine can be enabled.

Location-Based Assessment and/or Registration

When deploying agent-based or agent-less assessment, a location-based rollout allows you to fix any problems as they appear for each location, making for a smoother deployment. It is also important to verify that end-systems can communicate with all ExtremeControl engines on the network, so that the assessment state can be maintained. In addition, ExtremeControl engines must also be able to communicate with each other. This is because when an end-system moves from one engine to another (for example, the end user logs off in the dorm, then logs on in a classroom), ExtremeControl has to be able to reconcile the connection and move the end-system from one engine to another. You can test this by moving an end-system across the network and verifying that the agent stays connected.

For authenticated registration, a location-based rollout allows you to work out the LDAP configuration details prior to pushing out the configuration to the entire network. If an advanced LDAP configuration is used, it is important to test registration for users from different groups to verify that the LDAP rules are mapping the users to the correct group. Have an LDAP browser installed to aid in initial LDAP setup and rule creation.

Important Links in ExtremeControl and ExtremeCloud IQ Site Engine

The following tables provide lists of URLs for accessing commonly used ExtremeControl and ExtremeCloud IQ Site Engine web pages.

ExtremeControl Pages on the ExtremeCloud IQ Site Engine Server

Assessment/Remediation and Registration Pages on ExtremeControl Engines

ExtremeControl Engine Administration Web Pages

MAC and IP Resolution

MAC to IP resolution is the process used by the ExtremeControl L2 Controller and ExtremeControl Gateway engine to determine the IP address of an end-system from its MAC address. IP to MAC resolution is the process used by the ExtremeControl L3 Controller to determine the MAC address of an end-system from its IP address. The following sections describe the MAC and IP resolution processes used by ExtremeControl, and provide information for enabling diagnostic tools.

MAC to IP Resolution

ExtremeControl L2 Controllers and ExtremeControl Gateway engines use MAC to IP resolution to determine an end-system's IP address from the MAC address that is learned from the RADIUS request used to authenticate the end-system. There are several reasons why MAC to IP resolution is critical to the ExtremeControl process:

• The IP address is required for the end-system to be scanned with agent-less or agent-based assessment.
• The IP address is required for the ExtremeControl Registration and Assessment/Remediation features. When the end user navigates to the Registration or Assessment/Remediation portal web page they are identified by the IP address found via the resolution process.
• The IP address also provides a way to identify an end-system in addition to its MAC address.

By default, ExtremeControl is configured to always resolve the IP address for every end-system ExtremeControl sees. If you have not deployed assessment, registration, and/or remediation on your network, you can disable MAC to IP Resolution by using the Advanced Configuration window (available from the Tools menu > Manage Advanced Configurations) and selecting Engine Settings > IP Resolution Tab > Resolve IP Address Only for Assessment.

The MAC to IP Resolution Process

The MAC to IP Resolution process begins when an end-system authenticates to the network via a RADIUS request. From the RADIUS request, ExtremeControl determines the end-system's MAC address by reading the Calling-Station-ID attribute. After determining what policy to assign to the end-system (Accept, Reject, or Scan), the MAC address to IP address resolution begins.

First, ExtremeControl checks to see if there is a static MAC to IP address mapping defined in NAC Manager for the end-system's MAC address. If there is, then that IP address is used. If there is not, then the IP resolution process starts trying to resolve the IP address using IP discovery on the network access switch (NAS).

IP Discovery on Network Access Switch

ExtremeControl makes SNMP requests for the IP information to the network access switch (NAS) that sent the RADIUS authentication request for the end-system. There are five supported MIBs that ExtremeControl can read for the IP address information, depending on what MIBs the switch supports:

• ctAliasMacAddressTable - This MIB table contains IP address information for end-systems, indexed by MAC address.
• ctAliasTable -This MIB table is used only if the ctAliasMacAddressTable is not supported by the switch.
• CiscoDHCPSnooping -This MIB table is used for Cisco devices that are running the appropriate firmware.
• ipNetToMedia -This MIB table is used for third-party switches and for ExtremeWireless Controllers.
• ipNetToPhysical -This MIB table supports IPv6 addresses and is the IPv6 replacement for the ipNetToMedia table.

Following the SNMP requests, ExtremeControl evaluates the IP addresses that it discovered. First, ExtremeControl filters out any IP addresses that are invalid, such as 0.0.0.0. If there is only one IP address remaining, then this address is used and the process stops here. If there are no IP addresses remaining, ExtremeControl proceeds to the router IP discovery process. If there are multiple IP addresses, then ExtremeControl goes to the next step in the filtering process, VLAN IP Subnet Filtering.

If VLANs are being used for access control, ExtremeControl looks up the IP subnet for the VLAN that the end-system is in. IP subnets can be defined for each VLAN to provide an IP range filter, which can be used to filter the list of IPs discovered on the switch. IP subnets are defined in NAC Manager under the Engine Settings > IP Resolution Tab. If no IP subnet is found, ExtremeControl proceeds to the router IP discovery process. If a subnet is found and filters down to one IP address, then that address is used and the process stops here. If the filter results contain no IP addresses, then ExtremeControl proceeds to the router IP discovery process. If there are multiple IP addresses, then ExtremeControl goes to the next step in the filtering process, NetBIOS IP Filtering.

ExtremeControl makes NetBIOS requests to the list of IP addresses to determine the correct IP address. If the NetBIOS requests filter the list down to one IP address, then that IP address is used and the process stops here. If there are no IP addresses remaining, then ExtremeControl proceeds to the router IP discovery process. If there are multiple IP addresses, then ExtremeControl goes to the next step in the filtering process, Clear Duplicate IPs.

ExtremeControl clears the duplicate IPs from the network access switch to which the end-system authenticated, and then tries to re-read the IP address from the switch to find the most recent entry. The only filtering done at this point is removing invalid IP addresses and VLAN IP Subnet Filtering. If only one IP address is read this time, then that IP address is used and the process stops here. If no IP addresses are read, then ExtremeControl proceeds to the router IP discovery process. If there are multiple IP addresses, then ExtremeControl looks to see if one IP address is the last one heard with DHCP, and if the DHCP information can be used. If so, then that IP address is used and the process stops here.

IP Discovery on Router

If the ExtremeControl engine was unable to resolve the end-system's IP address by querying the network access switch, ExtremeControl makes SNMP requests to an end-system's gateway router ARP table to try to resolve the IP address. ExtremeControl determines the router IP address by one of two mechanisms. If VLANs are being used for access control, ExtremeControl looks up the IP subnet for the VLAN that the end-system is in. IP subnets are defined in NAC Manager in the Engine Settings > IP Resolution Tab. If no IP subnet is found, ExtremeControl will look for the last relay router heard for that end-system from any DHCP data. The router IP discovery process can be disabled via the Engine Settings > IP Resolution Tab > Router IP Discovery option.

There are four supported MIBs that ExtremeControl can read for the IP address information, depending on what MIBs the router supports:

• ipAddrTable - This MIB table is used to find the ifIndex for the IP address of the router in order to reduce the number of reads that need to be made against the ipNetToMedia or ipNetToPhysical MIB tables.
• ipAddressTable -This MIB table supports IPv6 addresses and is the IPv6 replacement for the ipAddrTable table.
• ipNetToMedia -This MIB table is used to locate the IP to MAC bindings.
• ipNetToPhysical -This MIB table supports IPv6 addresses and is the IPv6 replacement for the ipNetToMedia table.

Following the SNMP request, ExtremeControl evaluates the IP addresses it discovered. First, ExtremeControl filters out any invalid IP addresses, such as 0.0.0.0.  If there is only one IP address remaining, then this address is used and the process stops here. If there are no IP addresses remaining, ExtremeControl proceeds to the DHCP IP address process. If there are multiple IP addresses, then ExtremeControl goes to the next step in the filter process, router IP subnet filtering.

If an IP subnet is defined with the relay router's IP as one of the gateways, then that subnet can be used to provide a filter. IP subnets are defined in NAC Manager in the Engine Settings > IP Resolution Tab. If no IP subnet is found, ExtremeControl proceeds to the DHCP IP address process. If a subnet is found and filters down to one IP address, then that address is used and the process stops here. If results after the filter contain no IP addresses, then ExtremeControl proceeds to the DHCP IP address process. If there are multiple IP addresses, then ExtremeControl goes to the next step in the filtering process, the NetBIOS filter.

ExtremeControl makes NetBIOS requests to the list of IP addresses to determine the correct IP address. If the NetBIOS filters down to one IP address, then that IP address is used and the process stops here. If the filter results contain no IP addresses, then ExtremeControl proceeds to the DHCP IP address process. If there are multiple IP addresses, then ExtremeControl goes to the next step in the filtering process, Clear Duplicate IPs.

ExtremeControl clears the duplicate IPs in the ARP tables of an end-system's gateway router and then try to re-read the IP address from the router to find the most recent entry. The only filtering done at this point is removing invalid IP addresses and VLAN IP Subnet Filtering. If only one IP address is read this time, then that IP address is used and the process stops here. If no IP addresses are read, then ExtremeControl proceeds to the DHCP IP address process. If the results contain multiple IP addresses, then ExtremeControl looks to see if one IP address is the last one heard with DHCP, and if the DHCP information can be used. If so, then that IP address is used and the process stops here.

Agent IP Discovery

If the ExtremeControl engine was unable to resolve the end-system's IP address by querying the end-system's gateway router ARP table, then ExtremeControl can use an IP address reported by a connected agent. This process looks for the end-system's MAC address in the list of MAC addresses from known connected agents. If an agent is connected and heartbeats during the IP Resolution process, then ExtremeControl uses the IP address of that agent.

DHCP IP Address

If the IP address resolution process has still not obtained an IP address, then ExtremeControl uses a DHCP address, if one was heard and was deemed usable. ExtremeControl uses it even though it could not be verified. You can disable the use of DHCP Request IPs in Engine Settings > IP Resolution Tab > Use DHCP Request IPs. By default, this option only allows IPs learned from DHCP requests to be used in non-VLAN environments. This is because the IP addresses from request packets in a VLAN environment is always incorrect, because as an end-system transitions through VLANs, it always requests the IP from the previous VLAN.

If IP Resolution Fails

If ExtremeControl is unable to resolve an IP address and assessment is enabled, the end-system is assigned the Error connection state, and its extended state is set to "MAC To IP Resolution Failed." If the IP resolution process takes more time than allowed by the IP Address Resolution Timeout setting, the end-system's extended state is set to "MAC to IP Resolution Timed Out." (The default timeout setting is 60 seconds and can be changed in Engine Settings > IP Resolution Tab > IP Address Resolution Timeout.) When IP address resolution fails:

• ExtremeControl is unable to apply rules that use IP-based end-system groups to this end-system.
• ExtremeControl is unable to resolve the hostname, and is therefore be unable to apply rules using hostname-based end-system groups to this end-system.
• The Failsafe policy is applied to the end-system, if assessment is enabled.
• Assessment of the end-system (agent-less or agent-based) does not take place.
• The end-system is not be able to see the Registration web page.
• The end-system is not be able to see the Assessment/Remediation web page.

Deployment Considerations

The following Node/Alias configuration changes may increase the accuracy of IP resolution:

• Turn off learning on uplink ports.
• Increase the maximum number of entries per port for all downstream ports to the maximum, so that entries are timed out on a oldest per-switch basis instead of oldest per-port.

Diagnostics for IP Resolution

You can enable diagnostics for IP Resolution by going to the ExtremeControl engine administration web page and enabling diagnostic groups that provides troubleshooting information. Launch the ExtremeControl engine administration web page by right-clicking on the ExtremeControl engine in the NAC Manager left-panel tree and selecting WebView or by using the following URL: https://<ExtremeControlEngineIP>:8444/Admin. The default user name and password for access to this web page is "admin/Extreme@pp." Expand the Diagnostics folder in the left-panel tree and select the Engine/Server Diagnostics page.

The log output is saved in /var/log/tag.log on the ExtremeControl engine.

IP to MAC Resolution

ExtremeControl L3 Controllers use IP to MAC resolution to determine an end-system's MAC address after traffic from a new source IP address is detected on the controller. NAC Manager must know the end-system's MAC address in order to track the end-system through the ExtremeControl process.

The IP to MAC Resolution Process

The IP to MAC Resolution process begins when an end-system authenticates to the network via a packet containing the end-system's IP address that crosses the ExtremeControl L3 Controller.

First, ExtremeControl checks to see if there is a static MAC to IP address mapping defined in NAC Manager for the end-system's IP address. If there is, then that MAC address is used. If there is not, then the MAC resolution process will make NetBIOS requests to the end-system's IP address.

The NetBIOS request is made asynchronously, and until a MAC address is determined, all traffic from this end-system is dropped by the controller. If a valid response comes back, the MAC address is used if it is not one of the unusable MAC addresses defined under the Engine Settings > MAC Resolution Tab > Unusable MAC Addresses section. If the MAC address is not valid, then ExtremeControl proceeds to the DHCP MAC Resolution process.

If ExtremeControl is able to snoop a DHCP packet for the end-system's IP address, it uses the data from that packet to obtain the MAC address. If no DHCP information is available for that IP address, then ExtremeControl proceeds to NetBIOS Hostname Pseudo MAC Generation.

If a NetBIOS response was heard, but the MAC address was deemed to be unusable, ExtremeControl looks for the hostname within the NetBIOS response. If there is one, a pseudo MAC address is generated starting with the prefix of AB:CD. The last four octets are generated by the hostname and are guaranteed to be unique on each ExtremeControl Controller. However, there is the possibility that two end-systems with different names on different controllers could end up with the same pseudo MAC address. Because of this possibility, this option is disabled by default, but can be enabled in NAC Manager via Engine Settings > MAC Resolution Tab > NetBIOS MAC Resolution > Allow Use of NetBIOS Hostname for Pseudo MAC Generation option.

If ExtremeControl is unable to determine the MAC address through any of the processes described above, ExtremeControl generates a pseudo MAC address from the IP address of the end-system. This method always generates the same MAC address, and it is more likely to generate an address that uniquely identifies the end-system if IP addresses are statically mapped to end-systems. Because a MAC address is required by ExtremeControl to identify and track an end-system, there is no way to disable this final method.

Diagnostics for MAC Resolution

You can enable diagnostics for MAC Resolution by going to the ExtremeControl engine administration web page and enabling diagnostic groups that help with troubleshooting. Launch the ExtremeControl Engine administration web page by right-clicking on the ExtremeControl engine in the NAC Manager left-panel tree and selecting WebView or by using the following URL: https://<ExtremeControlEngineIP>:8444/Admin. The default user name and password for access to this web page is "admin/Extreme@pp." Expand the Diagnostics folder in the left-panel tree and select the Engine/Server Diagnostics page.

Agent-Based Assessment

This section provides strategies on how to set up your ExtremeControl assessment to take advantage of certain ExtremeControl features. It includes information on how to configure assessment test cases based on the end-system's operating system, and how to use MAC OUIs to exclude end-systems such as printers and phones from assessment.

Configure OS-Based Test Cases

Agent-based test sets can be configured to include individual test cases that apply only to end-systems running certain operating systems. Here are three examples of how this functionality could be used:

• Create different versions of the same test case based on the different operating systems. For example, create a Mandatory test that requires antivirus software to be installed and running on Windows XP end-systems. The end-system must pass the test, or it will be scored against them.
  
  Then, create a Warning or Informational test for Mac end-systems that checks for antivirus software and reports the results without any score being applied towards risk assessment.
  
  The Agent-Based Test Set lists the two test cases: Antivirus - Windows XP and Antivirus - Mac OS.
  
• Create tests that take into account operating system versions. This allows you to create a test case where end-systems running an older version of the operating system must be tested while end-systems with newer versions are not tested. For example, if Microsoft released a new service pack that was incompatible with a certain agent-based test, the test could be disabled for that new service pack. To do this, you can define a new operating system definition for the new service pack using the Manage Operating Systems window accessed from the Operating System(s) configuration menu button in the test Editor window.
  
• Create a test case that checks for a specific process on a specific operating system. For example, you could create a test that checks for Telnet installed on any Windows end-system, while Mac end-systems would not be checked.
  

If you have assessment enabled on your network, you can use ExtremeControl Configuration rules and MAC OUI end-system groups to exclude specific end-systems such as printers and phones from being assessed. Here are the steps you would use to create a printer end-system group and rule for your ExtremeControl Configuration:

1. Create an end-system group for your printers selecting a MAC OUI as your end-system type.
2. Create a printer profile that specifies a Printer Accept Policy and does not enable assessment. (Use the Manage Policies button at the bottom of the Edit ExtremeControl (NAC) Profile window to open the Edit Policy Mapping window if you need to define a Printer Accept Policy.)
3. Add a new rule to your ExtremeControl (NAC) Configuration that uses the Printers end-system group and Printer Profile.
   
4. Your ExtremeControl Configuration now includes a Printer rule based on a MAC OUI. Any end-system connecting to the network that matches the MAC OUI will be assigned to the Printers end-system group and receive the Printer Profile. That end-system is not assessed.

Third-Party Device Considerations

This section provides information on deploying ExtremeControl with third-party devices.

RADIUS Configuration
RADIUS configuration on third-party devices must be performed manually, outside of NAC Manager.

RADIUS Attributes
For third-party devices that support RFC 3580, NAC Manager access policies are by default associated to VLAN ID assignment based on RFC 3580 tunnel attributes. NAC Manager also allows you to define custom RADIUS attributes (such as vendor-specific ACL-based attributes) which are included as part of the RADIUS response.

Reauthentication
For third-party wireless devices (such as Cisco Wireless devices), reauthentication is accomplished using RFC 3576. For third-party wired switches, reauthentication is accomplished via dot1x MIB (standards), HP User Auth MIB, or by linking down the port.

IP Resolution
Third-party devices must have the ipNetToMedia MIB for ExtremeControl to be able to perform IP resolution. ExtremeControl also uses the Cisco DHCP Snooping MIB for Cisco devices.

ExtremeCloud IQ Site Engine Server Data Retention Tools

There are several NAC Manager options that allow you to configure the amount of data retained in the ExtremeCloud IQ Site Engine Server database. To access these options, select Tools > Options from the NAC Manager menu bar. In the NAC Manager Options window, expand the NAC Manager folder in the left-panel tree to see the options.

ExtremeControl Capacity Option

In the Advanced Settings Options panel, the ExtremeControl (NAC) Capacity option lets you configure the amount of ExtremeCloud IQ Site Engine resources allocated to ExtremeControl services. The greater the number of end-systems and engines in your ExtremeControl deployment, the more resources ExtremeControl services require. Use the slide bar to select the appropriate setting for your server.

• Low - For low performance shared systems.
• Medium - For medium performance shared systems, or low performance dedicated systems.
• High - For high performance shared systems, or medium performance dedicated systems.
• Maximum - For high performance dedicated systems.

Data Persistence Options

The Data Persistence options let you customize how NAC Manager ages-out or deletes end-systems, end-system events, and end-system health results (assessment results) from the tables and charts in the End-Systems tab and the Statistics tab. By default, a data persistence check is performed each day at 2:00 a.m. (You can change the time that the check is performed, if desired.) Use the following options to configure what the data persistence check ages-out or deletes.

Age End-Systems

Each day, when the Data Persistence check runs, it searches the database for end-systems that NAC Manager has not received an event for in the number of days specified (90 days by default). It removes those end-systems from the End-System table in the End-Systems tab.

If the Remove Associated MAC Locks and Occurrences in Groups checkbox is selected, the aging check also removes any MAC locks or group memberships associated with the end-systems being removed.

End-System Event Persistence

If this checkbox is selected, NAC Manager stores non-critical end-system events, which are events caused by an end-system reauthenticating. End-system events are stored daily in the database. Each day, when the Data Persistence check runs, it removes all events which are older than the number of days specified (90 days by default).

Health Result Persistence

This section lets you specify how many health result (assessment results) summaries and details are saved and displayed in the End-Systems tab for each end-system. By default, the Data Persistence check saves the last 30 health result summaries for each end-system along with detailed information for the last five health result details per end-system.

In addition, you can specify to only save the health result details for quarantined end-systems (with the exception of agent-based health result details, which are always saved for all end-systems).

You can also specify to save duplicate health result summaries and detail. By default, duplicate health results obtained during a single scan interval are not saved. For example, if the assessment interval is one week, and 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. If you select this option, all duplicate results are saved.

Troubleshooting

This section provides information on tools supplied by Extreme Networks ExtremeControl that provide diagnostic and troubleshooting information for the ExtremeControl engine and ExtremeCloud IQ Site Engine Server.

ExtremeControl Engine

The following tools can be used to collect and view diagnostic and troubleshooting information for the ExtremeControl engine.

Engine Command Line Diagnostics

Use the following two commands to display ExtremeControl (NAC) engine data:

nacstatus

From the engine command line, enter the command nacstatus to display engine status information including communications diagnostics, recent errors, DNS configuration, and Navis configuration.

nachelp

From the engine command line, enter the command nachelp to display engine status information including the location of specific log files and a list of administrative commands for the ExtremeControl engine.

ExtremeControl Engine Administration Web Page

To access status and diagnostic information for an ExtremeControl engine, launch the ExtremeControl engine administration web page by right-clicking on an ExtremeControl engine in the left-panel tree and selecting WebView. (You can also access the administration web page using the following URL: https://<ExtremeControlEngineIP>:8444/Admin.)

The default user name and password for access to this web page is "admin/Extreme@pp." The username and password can be changed in NAC Manager using the Advanced Configuration window (available from the Tools menu > Management and Configuration > Advanced Configurations) and selecting the Engine Settings > Miscellaneous Tab > Web Service Credentials field.

The left-panel tree in the administration web page displays a Home folder plus several other folders: Status, Diagnostics, Log Files, Downloads, and Utilities. Following is an overview of each folder and the web pages it contains.

Home

The Home web page provides engine performance information including debugging information (such as CPU usage) that helps you determine if the engine is being overloaded with requests.

Status

The Status folder provides the following diagnostic information:

• Agent-Based - Displays information about the agent-based clients connected to ExtremeControl. Select the Show All button to display all connected agents.
• Assessment - Provides performance information related to ExtremeControl assessment.
• Captive Portal - Provides debug information for the captive portal including statistics on the number of requests served and the interaction with ExtremeCloud IQ Site Engine.
• Details - Provides additional ExtremeControl performance information showing where performance bottlenecks may be occurring. The Throttled Tasks column can be used to help diagnose whether there is a problem in a specific part of the ExtremeControl process.
• End-System Authentication - Provides information on currently managed end-systems and all end-systems managed in the last 24 hours.
• Messaging - Provides information on sent and received JMS Statistics.
• NamedLists - Provides information about named lists (rule groups).
• Network Configuration - Provides a history of network configuration commands.
• Threads - Provides debug information by showing the tasks that ExtremeControl is currently performing.
• Switches & Routers - Displays basic configuration information about the switches that are configured to use this ExtremeControl engine

Diagnostics

The Diagnostics folder provides the following diagnostic information:

• Engine/Server Diagnostics - Lets you enable diagnostic groups and diagnostic level that helps with troubleshooting.
• Certificate Diagnostics - Provides information on your ExtremeControl engine security certificates including the Internal Communications server certificate chain, the captive portal server certificate chain, the RADIUS server certificate chain, the ExtremeControl Engine Trusted Certificate Store, the AAA Trusted Certificate Store, and AAA Certificate Revocation Lists.
• Communication Diagnostics - Displays diagnostic information and provides active tests to help troubleshoot communication issues between the ExtremeControl engine and the ExtremeCloud IQ Site Engine Server. Note that when using the RADIUS request test, RADIUS servers must be enforced to an ExtremeControl engine before they are available for selection from the drop-down list.
• Distributed Cache Diagnostics - Provides information and tools used to diagnose issues with data shared between the ExtremeCloud IQ Site Engine Server and ExtremeControl engines.
• End-System Cache Diagnostics - Provides information and tools to diagnose issues with ExtremeControl's end-system cache.
• End-System Diagnostics - If the debug information provided in the Server Diagnostics tab is too extensive, this tab allows you to enable debug information for a single end-system, making it easier to search through the database for specific information.
• Server Diagnostics - Allows you to enable different levels of logging on specific ExtremeControlengine functionality and view the debug information in /var/log/tag.log on the ExtremeControlengine and in the Server Log web page. By default, error and informational data is logged to the tag.log file, with a new file created each day. You can set the diagnostic level to "Verbose" to collect additional data that is presented in an easy-to-read format.

Log Files

The Log Files folder provides the following logs:

• Agent Logs - Displays the agent log files that have been retrieved from remote end-systems via the Client Diagnostics section on the Status > Agent-Based web page.
• RADIUS Log - Displays the last 1000 lines printed in the ExtremeControl engine RADIUS log (/var/log/radius/radius.log on the ExtremeControl engine).
• Server Log - Displays the last 1000 lines printed in the ExtremeControl engine server log (/var/log/tag.log on the ExtremeControl engine).
• OS Detect Failure Log - Displays the last 1000 OS detection failures (/var/log/osdetectfailure.log on the ExtremeControl engine).

You can change the number of displayed rows using the input box at the top of the page.

Downloads

The Downloads web page screen provides links to the assessment agent adapter install file and the installers for agent-based assessment. The assessment agent adapter is required for communication between the ExtremeControl engine and the Nessus assessment server.

Utilities

The TCP Dump web page provides the ability to run the TCP Dump packet analyzer and stores the packet capture files, which you can then download to view. Packet capture files (.pcap files) are stored on the ExtremeControlengine in /opt/nac/pcap.

You create a TCP Dump process by using the Add Process form or by typing in a CLI command in the Custom Command form. Two pcap files are created for each capture. When the first file reaches the maximum file size, the second file is started. When you download them, the server automatically zips these files together. If the server shuts down while a TCP Dump process (initialized through this interface) is running, the process automatically stops.

The options for the Add Process form are:

• File Name: Enter a name for the .pcap files. The .pcap extension is automatically added to the filename.
• Max File Size: Enter a maximum size for a single capture file. The default is 100 MB. A check is done to make sure there is enough disk room before running the process.
• Interface: Select a network interface on the server or use All (the default). Loopback is automatically ignored.
• IP Address: If you enter an IP address, only traffic going to or from this host is captured.
• Port Number: If you enter a port number, only traffic on this port is captured.
• Filters: Select the protocols on which to capture traffic or use Allow All Traffic (the default). If you have entered a port number, these checkboxes are ignored. Following are the ports associated with each protocol:
  • DHCP - port 67 and 68
  • RADIUS - port 1645, 1646, 1812, 1813
  • LDAP - port 389 and 636
  • Kerberos - port 88
  • HTTP - port 80, 443, 8080, 8443, and 8444

  CAUTION:

  If you enable an HTTP capture, you should not download any pcap files while the download is running because the capture will grow by the size of the pcap file. You should refrain from downloading pcap files while an HTTP capture is running.

For information on the proper syntax for using the Custom Command form, see: http://www.tcpdump.org/tcpdump_man.html. Additionally, for a TCP Dump cheat sheet, see: https://comparite.ch/tcpdumpcs.

ExtremeCloud IQ Site Engine Server

The following ExtremeControl diagnostic features can be used to collect and view diagnostic and troubleshooting information for the ExtremeCloud IQ Site Engine Server.

Generate Show Support

You can use ExtremeCloud IQ Site Engine to collect and save ExtremeControl status information for your ExtremeControl engines and the ExtremeCloud IQ Site Engine Server to a file, allowing you to easily view the data and also send it to Extreme Networks Support for troubleshooting purposes. ExtremeControl Status information includes communications diagnostics, recent errors, DNS configuration, and Navis configuration.

In ExtremeCloud IQ Site Engine, select the Administration tab. Under Support (in the left-panel tree), select the Generate Show Support report and select the Start button.

The ExtremeControl status information is collected and saved in a dated subdirectory under the <install directory>\appdata\ShowSupport directory on the ExtremeCloud IQ Site Engine Server. After you unzip the file, you see separate directories for the different ExtremeControl engine and ExtremeCloud IQ Site Engine server information saved.

Monitoring

Use the following NAC Manager menu options to monitor ExtremeControl engine and switch performance information.

Launch CPU Utilization View

From NAC Manager, right-click on one or more engines in the right-panel ExtremeControl Engines tab and select Launch CPU Utilization View to open the Host Processor Load FlexView.

Launch Memory and Diskspace Utilization View

From NAC Manager, right-click on one or more engines in the right-panel ExtremeControl (NAC) Engines tab and select Launch Memory and Diskspace Utilization View to open the Host Storage FlexView.

Launch RADIUS Client Information View

From NAC Manager, right-click on one or more switches in the right-panel Switches tab and select Launch RADIUS Client Information View to open the RADIUS Client Information FlexView.

Launch Node Alias and Multi Auth View

From NAC Manager, right-click on one or more switches in the right-panel Switches tab and select Launch Node Alias and Multi Auth View to open the Node Alias and Multi Auth FlexView.

View End-System Counts

From NAC Manager, select Tools > View End-System Counts to open a window where you can view the total number of current end-systems seen on each switch. Counts can be limited by specifying a time range, if desired.

ExtremeCloud IQ Site Engine Server and ExtremeControl Engine Connectivity

There are four communications channels between the ExtremeCloud IQ Site Engine Server and the ExtremeControl engine: SNMP, Web Services from the ExtremeControl engine to the ExtremeCloud IQ Site Engine Server, Web Services from the ExtremeCloud IQ Site Engine Server to the ExtremeControl engine, and JMS (Java Message Service). ExtremeCloud IQ Site Engine Console, Policy Manager, and Inventory Manager use SNMP to communicate with the ExtremeControl engine and determine its state. NAC Manager uses Web Services and JMS communication instead of SNMP to determine engine status, providing more robust connectivity information. NAC Manager status should always be used as the primary determination of engine connectivity. For example, ExtremeControl engine status could be "up" in Console while "down" in NAC Manager.

The following sections explain how to determine the status of each communication channel, and provide troubleshooting information for connectivity problems.

SNMP

SNMP is the most basic communication method used to talk to the ExtremeControl engine. ExtremeCloud IQ Site Engine Console use SNMP to poll the ExtremeControl engine (both ExtremeControl Gateways and ExtremeControl Controllers) and determine its status. Policy Manager and Inventory Manager can be used to verify SNMP status for ExtremeControl Controllers only. SNMP status is determined by looking at the device status icons in the left-panel tree. If the arrow on the ExtremeControl engine icon is green, SNMP connectivity is established. If the arrow is orange or red, there is an issue with SNMP connectivity. An orange arrow indicates that an SNMP error was returned (check the event log for an error description). A red arrow indicates an SNMP timeout. Check ping access between the server and the engine, and verify SNMP credentials. Alternatively, MIB Tools can be used to verify SNMP connectivity between the server and the ExtremeControlengine.

Web Services

Java Web Services is an XML-based communications protocol that provides symmetric communication channels from the ExtremeControl engine to the ExtremeCloud IQ Site Engine Server and from the ExtremeCloud IQ Site Engine Server to the ExtremeControl engine.

When troubleshooting Web Services, start by verifying the following basic configuration requirements:

• Web Services occur over SSL with a destination of port 8444. Verify that port 8444 is not blocked between the server and engine, in both directions.
• Verify that the ExtremeControl engine has DNS servers configured, and that the ExtremeCloud IQ Site Engine Server can resolve all engine hostnames and the ExtremeControl engines can resolve the ExtremeCloud IQ Site Engine Server hostname.
• Verify that the ExtremeCloud IQ Site Engine server is bound to the proper interface (if there are multiple interfaces). For information see Systems with Multiple NICs in the ExtremeCloud IQ Site Engine Installation Guide.
• Ensure that the ExtremeControl engine has the correct IP address configured as the Management Server IP address by running the command cat /opt/nac/mgmtServerIP. Run the command /opt/nac/configMgmtIP at the engine CLI to configure the IP address if necessary, and use the ExtremeCloud IQ Site Engine Server's IP address (the bound IP in the ExtremeCloud IQ Site Engine Server's server.log) as the Management Server IP address. To start using the new ExtremeCloud IQ Site Engine Server, you must restart the engine by entering the command nacctl restart.
• Verify Web Service credentials in NAC Manager (Tools > Manager Advanced Configurations > Global and Engine Settings > Engine Settings > Default > Credentials Tab).
• Reset the web service credentials on the ExtremeControl engines to ensure a match. From the /opt/nac/ directory, enter the command ./configWebCredentials.

The next step is to determine the current Web Service status for the engine. The current status of the Web Service for an ExtremeControl engine is found on the Communications Diagnostics page of the ExtremeControl Engine Administration web page.

Launch the ExtremeControl Engine administration web page by right-clicking on the ExtremeControl engine in the NAC Manager left-panel tree and selecting WebView or by using the following URL: https://<ExtremeControlEngineIP>:8444/Admin. The default user name and password for access to this web page is "admin/Extreme@pp." Select the Diagnostics page and then the Communication Diagnostics page.

On the Communications Diagnostics page, you will find the Web Service Authorization and Last Web Service Request status. These two fields provide information on whether or not the ExtremeControl engine can contact the ExtremeCloud IQ Site Engine Server with Web Service calls. If Web Service Authorization says "ExtremeControl (NAC) Engine is not Authorized," there is a communication issue between the ExtremeControl engine and the ExtremeCloud IQ Site Engine Server. In this case, check the following points:

• If the JMS Topic status does not say "Topic Connection is Up," refer to the section on troubleshooting JMS Connections to resolve this issue.
• Verify that DNS is configured with hostnames of the ExtremeControl engine and ExtremeCloud IQ Site Engine Server. Test DNS resolution with the Test Name Lookup button.
• Verify that SSL Certificates have been configured for Web Service connections. To do this, open the ExtremeControl Engine Administration Web Page and view the certificate via the browser window. Then, use your browser to view the certificate used:
  • Internet Explorer 7.0 or later: Select the lock icon to the right of the URL address > View Certificates
  • Microsoft Edge: Select the lock icon to the left of the URL address > Connection is secure > certificate icon
  • Mozilla Firefox 3.5 or later: Select the lock icon to the left of the URL address > Connection Secure > More information > View Certificate
• Verify that the Web Service Credentials are configured correctly. Web credentials are used to negotiate Web Services between the ExtremeCloud IQ Site Engine Server and ExtremeControl engine. They can be configured on the ExtremeCloud IQ Site Engine Server through NAC Manager, by going to Tools > Management and Configuration > Advanced Configuration > Global and Engine Settings > Engine Settings. Select the Engine Settings to edit, select the Credentials tab, and configure the credentials in the Web Service Credentials section. Changes to the credentials is propagated to the ExtremeControl engines on Enforce. (If for some reason the credentials are out of sync on the ExtremeControl engine, use the /opt/nac/configWebCredentials command to configure the Web Service Credentials on the engine. Restart the engine by entering the command nacctl restart.)

Use the engine's Server Diagnostics page to obtain additional information on Web Service connectivity. Access this web page from the ExtremeControl Engine administration web page by selecting the Diagnostics page and then the Engine/Server Diagnostics page. Enable the "Messaging - Web Services" debug group to log detailed debug information on Web Service connectivity. Set the Diagnostic Level to "Verbose" and access the debug information in /var/log/tag.log on the ExtremeControl engine or in the Server Log web page.

On the ExtremeCloud IQ Site Engine Server, use the Server Diagnostics page to obtain detailed debug information on Web Service connectivity. Access this page from the ExtremeCloud IQ Site Engine Launch page by selecting the Administration tab. To access the server diagnostics, you need to log in with your username and password.

Use the Administration tab to view ExtremeControl web service counters. Launch ExtremeCloud IQ Site Engine and select the Administration tab. Select the Diagnostics sub-tab, expand the ExtremeControl folder, and select ExtremeControl Web Service Counters.

JMS Connections

The ExtremeCloud IQ Site Engine Server and ExtremeControl engine also use JMS (Java Message Service) as a communications channel for sending messages back and forth. JMS is proprietary socket-based and the ExtremeCloud IQ Site Engine Server and ExtremeControl engine listen on message "topics" for new messages to and from each other.

The state of JMS connections can be determined by looking at the JMS Topic field on the Communication Diagnostics page on the ExtremeControl Engine. Access this web page from the ExtremeControl Engine Administration web page by selecting the Diagnostics page and then the Communications Diagnostics page. You can also determine the state of JMS connections from the /var/log/tag.log file on the ExtremeControl engine, which contains error messages from TopicConnectionManager that helps troubleshoot JMS connectivity issues.

Additional debug information can be retrieved on the ExtremeControl engine by enabling the "Messaging - JMS" and "Messaging - JMS Connection" debug groups on the Server Diagnostics page. Access this web page from the ExtremeControl Engine Administration web page by selecting the Diagnostics page and then the Server Diagnostics page. Set the Diagnostic Level for these two groups to "Verbose" and access the debug information in /var/log/tag.log on the ExtremeControl engine or in the Server Log web page.

Related Information

For information on related help topics: