Troubleshooting with Central
Several tools are available within HPE Aruba Networking Central for troubleshooting, enabling the network operator to quickly and efficiently resolve issues. Real-time alerts, event correlation, targeted diagnostic tools, and Agentic AI capabilities form the basis for Central’s feature rich user interface, offering best in class insights into the operation and health of the network.
Issues that require troubleshooting are presented to a network operator in a variety of ways. Alerts on Central’s network dashboard, results from a query to Central’s Agentic AI, and end user reports are all common starting points for the troubleshooting process.
Table of contents
Troubleshooting Alerts
Central’s Alert capabilities are quite vast, and provide indications for an array of anomalies relating to device and client functionality, performance, processes, and topology.
Introduction to Alerts
Alerts in Central provide a unified platform for notifications related to the health and operation of the HPE Aruba Networking environment. In legacy monitoring environments, alerts may have come from multiple platforms - an SNMP polling and trap collector, a syslog collector, Airwave alerts via AMON, and perhaps other management systems. Using a sophisticated API-based telemetry infrastructure, Central is able to present the alerts in a single management platform, providing correlation logic to understand the scope of an anomaly across multiple sites and/or users. Central is also able to take advantage of its Agentic AI capabilities to provide insights and recommendations for quick resolution.
The full list of Alerts within Central’s library can be viewed from the Alert Management section. HPE Aruba Networking is actively creating new alerts for continuous improvement to the operator experience. The network operator can also create alerts, setting custom thresholds and alert content as required for the specific needs of that network.
Step 1 To view the alert list, click on the two-line hamburger Menu icon in the upper left hand corner of the Central Network Overview page.
Step 2 Click on the Manage button in the Alert Management card.
Step 3 This is a view of the list of active Alerts within Central. From this page, Alerts can be modified (i.e. changing a threshold value, or a trigger timeframe), enabled/disabled, created, or labeled. HPE Aruba Networking Central Online Help - Alert Management is an excellent resource that provides more information about the construct of alerts, how to modify existing alerts, how to create new ones, and how to change scope assignment.
Below is a sample output of an alert, in this case a DHCP Discover Timeout alert triggered by a client.
An Alert is comprised of relevant telemetry data collated by the AI capabilities of Central. It contains general information about the Alert in the Summary section, including when specificially it has occurrend and how often. Central has customized it’s Action response based on the behavior and configuration of this particular network. Central has started the Troubleshooting for this alert, and expansion of this card offers additional detail about the troubleshooting results. Finally, if there are Events that occur on the network related to this Alert, they are summarized in their own card. Once again, expansion can provide greater detail about the related events.
Note: Cards presented will vary for each alert.
Device Alerts
Central not only alerts on the typical up/down status or high CPU utilization of a device, it also alerts on anything that may impede operational performance, such as high channel utilization on an AP, or high broadcast traffic utlization on a switch. Device alerts are easily incorporated into a daily NOC check or runbook, or presented in Central’s reporting function, covered in the Campus Operate Reporting section.
Many views within the Central Dashboard offer a pathway to device status. The following example uses the Device Health card to provide a quick overview of the number of devices for each red/yellow/green status indicator.
Step 1 Start at the Central NOC Dashboard view and note the Device Health card.
Step 2 Expand the Device Health card to view a distribution of device status per site.
Step 3 Click on the number of a site/device/status combination that is of interest. In this case, The Miami (MIA)-Branch site, a yellow alert for a switch.
Step 4 For the MIA site it shows the devices that currently have associated alerts. Click anywhere on the gray part of the alert message (not the bold print) to engage a side card that offers a summary of information about the device and alert.
Step 5 Alternatively, select the bolded device name for a full snapshot of that device.
Step 6 From this full device view, select the Alerts planet on the left hand side solar system view to bring up the alerts.
Step 7 Select the bolded keyword Stack Topology Changed.
Step 8 This view of the Stack Topology Change alert is a key example of Central’s powerful AI Ops capability - itemizing related events with timestamps, summarizing the timeframe of occurrences, what specifically is impacted by the alert, and finally what actions the user can take to mitigate any issues. Expand the Events Card.
Step 9 Viewing the Events log provides detail leading up to the alert, offering correlated activity which can greatly reduce the invesigation and troubleshooting effort.
Catagorized Alerts
The ability to view different cross sections of data to fit the network operator’s viewpoint or scope of responsibility is a major advantage over legacy management platforms. The Alerts Card within the NOC Dashboard Global View of Central breaks out the alerts by categories. This view offers the advantage of isolating a problem on the network by alert type, even though it may span multiple devices, or multiple sites. The main focus of the category view reflects network functionality as a whole, and less about an alert per device, although it is possible to drill down to that level from this view.
Step 1 For this example, start at the Alerts card from the NOC Dashboard and click on the Clients keyword to view the alerts for that category.
Step 2 This expanded view shows the distribution by alert type, and number of sites affected by each alert. Click on a specific alert in bold - for this example DHCP Discover Timeout:
Step 3 The DHCP Discover Timeout alert will display information of the alert frequency by site. This example will focus on the alerts at the Miami (MIA) - Branch site. Because the intention is to focus on the DHCP Discover Timeout alert, it is important to click on the number in the second column. If the site name is actually clicked, it will go to the site view.
Step 4 Clicking on the number 7 in the previous screen reveals the seven alerts recorded for the Miami (MIA) - Branch site. Checking the far left box or the grey area of any alert will produce a side card, without navigating away from the seven alerts. This side card may be all the information that is needed by the network operator to understand the problem.
Step 5 For a deeper dive into the alert, including specific events related to this instance, click the Go To Alert button in the side card.
Step 6 This more detailed alert view shows a Summary of the alert, the Impact (in this case, one client over 3 access points), suggested Action to take the resolve the issue, Troubleshooting results that have already been performed by Central, and Events related to the occurrences of the alert.
In this particular example, the DHCP Discover Timeout presents itself as fairly localized, affecting only this client at this particular site. However, the power of the alerts and the intelligence behind their generation can efficiently present to the operator any correlation of the alert with other sites that perhaps use the same DHCP server, or other users at a single site that also are experiencing the same problem. In short, Central’s ability to leverage the data from the entire network and present it in a logical and correlated format will bring an advanced level of triaging to the network operator that was not as obvious in previous network operations.
Alerts by Site
Another option for alert investigation is presented through the Site view of the Central NOC Dashboard. This view shows all alerts per site.
In this example, a high number of alerts have been noted at the Miami (MIA) - Branch site, and a NOC engineer has been asked to investigate. This example will also introduce some additional functionality about setting priority, clearing alerts, and adding notes.
Step 1 The investigation starts by clicking on the Miami (MIA) - Branch site from the Sites card on the NOC Dashboard.
Step 2 Next, click on the Alerts planet to gain insight regarding the source of alerts.
Step 3 A quick scroll through the alerts indicate that the Loop Detected Alert has been triggering for several days. Using the search bar, input the keyword loop to pull up all alerts related to the Loop Detected Alert.
Step 4 As the NOC engineer is investigating, it is learned that the alert is caused by a staged environment of a senior engineer that has not been put into production yet. The NOC engineer is asked to clear the alerts. For this example, the NOC engineer performs a multi-select of the alerts by selecting the squares to the left of the alerts.
Step 5 Click Actions at the top right hand corner of the table to expand, and select Clear.
Step 6 In the same fashion as Clear, the NOC Engineer could have alternatively Set Priority depending on the processes used by this organization. Both tools are useful for NOC role shift handoffs, indicating to the next shift what is priority and needs further attention, or clearing items that can safely be ignored. To that end, the Note feature is also helpful to provide information about an acknowledged alert. In this case for the DHCP Discover Timeout alert, the NOC engineer provides information about the status of the alert that will be of use to the next shift. Note is available on the main Sun within the solar system view of a particular alert. Click on the Note icon to open a free form text box.
Step 7 Fill in the Note text and click Save.
Step 8 It may be necessary to review those alerts that have been cleared or deferred. This can be done using the filters from the Alerts view. From the Alerts menu, same as visiting in Step 7, select the appropriate filter for viewing. Unselect Active if desired.
Step 9 Using the Table Menu icon in the upper right hand corner of the table, select Customize Columns.
Step 10 Select the column Notes and click Apply to display any notes for the alerts selected.
Troubleshoot User Experience
A key capability of modern network management platforms is to empower the operator to efficiently and accurately identify the cause of any reduction in the quality of user experience on the network.
This section will present a troubleshooting example that uses multiple tools and capabilities within Central to troubleshoot a user with degraded performance. This troubleshooting effort will introduce the following:
- Search clients by MAC address and review key performance indicators.
- Use Central’s Agentic AI Networking CoPilot search functions to quickly gain information about an access point.
- Modify the device group and site for a device within central.
- Use Troubleshooting Tools to further understand and validate device capabilities.
Introduction to the User Scenario
An end user calls the NOC to report a degradation in WiFi performance. The enduser complains of slow speeds, and indicates he is sitting rather close to an installed access point.
The NOC engineer gathers some information. It can be summarizes as follows:
- The enduser device MAC address is bc:83:85:07:34:c8, with an obtained IP address of 192.168.20.124, on the CorpWiFi SSID.
- The enduser states they can see the access point labeled as AP-23, and can see the sticker indicates a MAC address ending in c3:16:84. The end user indicates the access point is powered on with green lights.
- The enduser’s location is on the main level, sitting inside a common area within the office.
- The enduser indicates the office had been notified of WiFi system maintenance the week prior, which is when the slow speeds started.
Client Search by MAC address
To start the troubleshooting process, the NOC Engineer looks up the enduser by their MAC address with the following process:
The NOC Engineer starts at the Network Overview page of the NOC Dashboard view and clicks on 365BranchOffice.
From this view, he selects Clients planet.
At this list of clients, the NOC Engineer enters into the Search bar the client MAC address - note that a partial entry of the MAC address was enough to bring up the client with a matching IP address.
The NOC Engineer then selects the bolded client device name.
At first glance, it seems the client is successfully connected to the network. However, the NOC engineer notices some suspicious performance numbers within the Connectivity Performance card, with a signal quality (SNR) of only 20dB. The transmit and receive rates are not as high as they should be if the user is right next to a healthy access point. The NOC engineer also notes a very relevant data point that the end user is connected to access point labeled AP-31 on the 2.4Ghz band, which is not the access point referenced by the end user.
AP Investigation with Agentic AI CoPilot
The NOC engineer contemplates why the user would not be able to attach to AP-23, so decides to pull up information about that access point.
Starting at the Network Overview page of the NOC Dashboard, the NOC engineer goes to the production 365BranchOffice site.
From this view, clicking on Network brings up the access points associated with this site.
The NOC engineer does not see AP-23 in the list for 365BranchOffice, which is raising a red flag.
Using the most expedient way to find status of that access point, the NOC engineer asks Central’s Agentic AI Networking Copilot. For this tool, context matters. In other words, asking at the Site Level vs. asking at the Global Level may produce different results. Because the access point does not appear in the 365BranchOffice device list, Networking Copilot will be launched at the Global Network Overview level to cast a wider net. Click on the Infinity icon at the top of the Network Overview.
The NOC engineer simply asks the Networking Copilot for status of the AP-23 device and clicks on the arrow.
Networking Copilot produces the following output. The NOC engineer quickly takes note: the access point is located in the Staging Site, when it should actually be in 365BranchOffice.
Clicking on the X in the upper right hand corner will return to the dashboard.
The NOC Engineer goes to Staging Site from the Sites card.
He clicks on Network planet to bring up the access points in Staging Site.
The NOC Engineer validates that the access point in question is indeed located in the Staging Site. He clicks on the bold device name.
Then he clicks on the Network Planet for the device.
Note the WLANs - the CorpWiFi that the enduser is connected to does not exist on this access-point, only the Staging-WLAN is present.
Modifying the Device Group and Site of a Device
The NOC Engineer knows that the reason the enduser cannot connect to AP-23 is because of the wrong device group, and the fact that the Staging Site does not advertise the appropriate WLANs, including CorpWiFi. The next actions for the NOC Engineer will be to move the device to the correct group and site. The NOC engineer confirms the following:
- Current Incorrect Site: Staging Site
- Move to Correct Site: 365BranchOffice
- Current Incorrect Device Group: StagingArea
- Move to Correct Device Group: 365DeviceGroup
Using guidance provided in the following links, the NOC engineer corrects the Device Group and Site for AP-23:
Move a device from one group to another as described in HPE Aruba Networking Product Documentation - Moving Devices between Groups
Remove a device from a site as described in HPE Aruba Networking Product Documentation - Removing devices from a site, and then assign a device to another site described in HPE Aruba Networking Product Documentation - Assigning a Device to a Site.
Validating the Device Move
To validate the correction, the NOC Engineer returns to the 365BranchOffice from the Network Overview Dashboard. The Staging Site should be grey, indicating no devices as part of that site.
The NOC Engineer clicks on the Network planet to validate the access points (notice that this number has incremented from 7 to now 8).
The NOC Engineer verifies that AP-23 is now in the list and click on the bolded name.
He selects Network for this device.
From this view, the CorpWiFi now exists in the WLANs list.
Validating the User
The NOC Engineer has instructed the user to disconnect from the CorpWiFi WLAN and reconnect. It is now necessary to review the client connectivity to ensure that the changes had the desired effect on the user.
From the NOC Dashboard’s Network Overview page, the NOC engineer goes back to the 365BranchOffice from the Sites card.
He clicks Network planet next.
Then he clicks on AP-23.
Clicking on AP-23 and then on the Clients planet will show the client of interest connected to this access point. Click on the client.
The client is connected to AP-23 as they should be. SNR, Rates, and retries also look more healthy. The user is no longer complaining of poor speeds.
The NOC Engineer is curious as to why the transmit and receive rates are not higher. They aren’t as bad as they were, but with a WiFi6 capable network, and 6Ghz enabled on this Access Point, the NOC Engineer knows that rates can be better. The NOC Engineer recalls some valuable show commands learned in the past, and decides to further investigate this end user. Click on the Tools icon in the solar system.
The two commands the NOC Engineer is interested in running are show ap debug client-table and show ap associations. From the Commands tab, enter ap debug client-table in the search box. Check the box for that command, and then select Add.
The ap debug client-table command is now present in the right hand column of selected commands. In the same fashion, enter ap associations within the seach box, check the box for that command and then select Add.
The two selected commands will appear in the right hand box, select Run.
The following output is displayed. The NOC engineer notes that the client capabilities within the second command indicate that this is an 802.11ac (VHT) client. The first command confirms similar data regarding the SNR data and transmit/receive rates. The recommendation to the client will be to upgrade to a Wi-Fi6 capable device for even better performance.
Insight-Driven Optimization/Maintenance
AI Insights provide recommendations to improve overall network performance, security, or reliability with changes to configuration that optimize for observed usage patterns, implement recommended firmware upgrades, or enable performance enhancing protocols.
Step 1 On the Network Overview page, use the Sites card to select a site for investigation. Expand the card if needed to see the full list of managed sites.
Step 2 On the Site dashboard, click the Insights card.
Step 3 Select an insight to display relevant details. In this example, the Roaming Recommender is displayed.
Step 4 On the Roaming Recommender, click the View button in the Actions frame to further investigate the impact of the recommended change.
Step 5 Explore additional Insight based functions such as View Floorplan, View Topology, or View Impacted Clients, depending on the specific Insight being investigated.
Using the Audit Trail
The Audit Trail in Central provides a searchable record of administrative activity across the network. This tool is essential when investigating issues that may stem from recent configuration changes—such as updates to VLANs, DHCP scopes, or switch uplinks.
Step 1 From anywhere in the Central interface click the menu icon.
Step 2 Click View on the Audit Trail Card.
Step 3 Use the filters to narrow the results:
- Set the Category to Configuration.
- Adjust the Time Range to align with when the problem was first reported.
- Optionally, filter by Device Type or User to isolate relevant changes.
Step 4 Review the list of changes for recent modifications that may have affected DHCP behavior or client onboarding.
Step 5 Click any entry, click the ellipse at the end of the row, then click show show difference.
Step 6 If a change appears related to the issue, use this information to validate with the change management process or initiate a rollback as appropriate.
Refer to the Troubleshooting section in the online help for more details.