Symptom: A client fails to get access to the network after successful authentication.

Scenario: This issue can impact a client trying to onboard with a downloadable role after temporary network issues.

Workaround: Log off all the clients that are with the Downloadable User Role (DUR) in the failed state using command port-access log-off client role <role-name>. This will initiate a retry of download of the role. 

Symptom: The switch contacts the Google Public DNS server: 8.8.8.8

Scenario: This issue can occur if there is no user configuration for DNS server nor DNS hosts and HPE Aruba Networking Central is configured. The switch uses the Google DNS server 8.8.8.8 by default. HPE Aruba Networking Central is enabled by default across all switch platforms.

Workaround: Disable HPE Aruba Networking Central functionality

Symptom: A kernel panic occurs during bootup, rebooting the switch.

Scenario: This issue occurs when a USB-A serial cable is disconnected (either explicitly or due to a malfunctioning USB cable) during a boot from ServiceOS to ProductOS.

Symptom: When importing a CA certificate to a Trust Anchor (TA) profile, if the certificate is bigger than 3072kb in size, it could be treated as a malformed certificate and be rejected.

Scenario: This issue can occur when using a CLI terminal to import an over-sized CA certificate to a ta-profile context, either via TFTP, SFTP, SCP, or via a copy-paste to the terminal.

Symptom: The portaccessd process may crash.

Scenario When end user devices are fingerprinted for the HTTP User Agent, if a device's HTTP User Agent string contains any characters which can be also interpreted as format specifiers, then this issue may occur. 

Workaround: This problem does not occur if HTTP User agents are simple strings without any format specifiers (%20f , %20s etc),

Symptom: A critical log message is generated for a ipsavd process daemon restart with signal 11.

Scenario: This daemon restart will be observed when a DHCP client sends a DHCP renew packet without the end option when dhcpv4-snooping option 82 is disabled.

Workaround: Enable dhcpv4-snooping option 82, or configure a maximum lease-time for the client (365 days) to avoid this issue.

Symptom: The EVPN route selection process may cause an suboptimal path selected.

Scenario: During the EVPN best path selection, the IGP metric to reach the nexthop of the EVPN route may not be taken into the consideration.

Workaround: Other BGP attributes (like Local preference or weight, etc.) need to be altered for the routes to select the desired path. However this is may not be feasible in all the routing policy/scenarios for the enterprise.

Symptom: The EVPN route selection process may cause an suboptimal path selected.

Scenario: During the EVPN best path selection, the MED value of the EVPN route is not taken into the consideration.

Workaround: Other BGP attributes (like Local preference or weight, etc.) needs to be altered for the routes to select the desired path. However this is may not be feasible in all the routing policy/scenarios forthe enterprise

Symptom: An interface tunnel for a GRE tunnel is shown as being UP, even though the source IP is not reachable.

Scenario: This issue can occur happens there is a GRE tunnel between two endpoints, and the source IP is not reachable.

(For 6300 Switch Series only)

Symptom: Access points (APs) and IP Phones connected to a 6300 switch were repeatedly disconnecting and reconnecting again. 

Scenario: This issue is observed if the device profile has been configured on the switch to assign VLANs to IP phones and APs. However, once the device profile is applied, it gets removed immediately. LLDP entries on the port where the device profile is enabled are being deleted and then relearned.

Workaround: Enable LLDP Rx on all switch ports.

Symptom: A vtysh daemon restart with signal 11 is observed.

Scenario: This daemon restart can be observed when the console-lockout-time value of 300 is pushed via the REST API.

Workaround: Configure a value other than 300 as the value of the console-lockout-time.

Symptom: Denied mac entries are displayed in the output of the show mac-address-table interface command.

Scenario: A network administrator cannot identify which MAC entries are denied using show mac-address-table interface command, as this command doesn't have a detail option.

Workaround: issue the show mac-address detail and grep the specific interface.

(For 6400 Switch Series only)

Symptom: An IPTV display appears to be pixelizated,

Scenario: This issue can occur when a very large number of transactions are sent from mgmd to OVSDB. If the CPU usage reaches more than 91% of usage on the ovsdb-server, the hpe-mgmdd packet processing queue is slowed, contributing to a the spike in CPU usage.

Workaround: Issue the mgmd delayed-refresh command to fine tune the number of transactions and avoid frequent database updates which will in turn reduce CPU usage.

(For 6300 Switch Series only)

Symptom: A management interface is not showing the configured static IPv6 address.

Scenario: This issue can be seen when issuing the show interface mgmt command after a reboot or switchover. The output of the show interface mgmt command is not showing the static IPv6 address as configured.

Workaround: Disabling and then reenabling the management interface after an upgrade or reboot, will resolve this issue.

Symptom: Low performance speed is observed on 1G NIC cards. 

Scenario: This issue is observed with some NIC cards that are not tolerant to a smaller interpacket gap, as these cards will silently drop packets at certain inter packet gaps. The silent packet drops impact application performance. 

Workaround: Configure the affected port at speeds up to 100M.

Symptom: A kernel panic occurred while collecting support files on the switch.

Scenario: When multicast traffic pass through the switch, the logs accumulate over a period of time. which could result in an increased system memory consumption at switch.

Workaround: Issue the commands router pim disable then router-pim enable, or restart the pim daemon.

Symptom: APs connected to the 6300 switch are powered up with a 46W power level, but APs may later start drawing 25W of power instead of 46W.

Scenario:When more than 10 APs are directly connected to a 6300M and are powered-up at once, some of them may settle at lower power of ~25W instead of ~46W. The APs do not fail to power-up and random APs may experience this issue each time all the APs are powered off and then back on.

Workaround:Disable and then reenable power on ports where issue is seen.

(For 6400 Switch Series only)

Symptom: A wireless client roaming from a VSX primary to a VSX secondary does not get access to the network until one iteration of the MAC ageout configuration (which by default is 300 seconds). 

Scenario: This issue occurs when moving a wireless client from one AP in a VSX primary to another AP in a VSX secondary. Both the AP-connected ports in the switch will be operating in device mode. After the client moves, traffic gets dropped as the switch doesn't update the MAC entries until the MAC ageout time. 

Workaround: Disable port-access secure client-move using the command no port-access client-move enable secure.

Symptom: The port-access log-off command is not removing port-security sticky clients when the port is down or in an error-disabled state.

Scenario: This issue can impact dynamically learned port-security sticky clients when using the port-access log-off client mac command. Additionally, this command cannot be issued when the interface is unavailable; it must be operational or it leads to the client not being deleted from the interface.

Workaround: Physically bring interface down by pulling out the cable.

Symptom: On 6200Fv1 and 6300F switches ( JL724A-JL728A, JL665A-JL668A), the show environment power-consumption command can't be called, and the show environment power-consumption member 1 command output will return nothing.

Scenario: This issue can occur when attempting to check the power consumption usage on a 6200Fv1 or 6300F Switch.

(For 6300 Switch Series only)

Symptom: The PTP clock is stuck at holdover state when PTP is enabled on 32+ port and after performing a ptp interface disable/enable and shut/no shut operation on multiple ports.

Scenario: APR will combine 32 ports and form a aprslot and one port among 32 ports will be marked as the current ref port. In the case of 32+ ports, an additional new aprslot will be created for the next 32 ports, and one port in the newer slot will be selected as current ref for the aprslot. Each aprslot will have one port marked as the current ref. The GM-connected aprslot will become the clock reference stream (Active ref aprslot) and another apr slot will be Non-Active ref aprslot. Shutting down the port marked as the current ref in the non-Active ref aprslot causes this issue. While deleting the port entry, the next current ref for aprslot will be selected among the ports in the Non-Active ref aprslot and same port is marked as clock reference stream (Active ref slot). This makes the clock to go into a holdover state and offset to drift slowly to higher value. The clock reference stream(Active ref slot) should be marked only if it is connected to the best GM.

Workaround: Disable and reenable the clock-sink port to recover the offset.

(For 6300 Switch Series only)

Symptom: The switch will lose synchronization with the Grand-source clock. The offset and path-delay in the output of the show ptp clock command will remain frozen and occasionally a diagnostic dump for the PTP daemon created using the diag-dump command will also timeout.

Scenario: The issue is seen when the system is running for more than a day with several PTP clients (20+ devices) connected to the switch directly. With more clients, the activity of the PTP daemon is increased and so the internal logging activity. At some point, there is a hourly automatic log-rotation triggered by log-mgmtd and if the PTP log ( /var/log/ptp.log) filesize has reached to a larger value (more than 500mb) then there is high chance this issue may occur. Immediately after the rotation, the PTP daemon might hang and network administrators may observe the described symptoms

Workaround: Use the following workarounds to reduce the intensity of the logging or stopping the logging all together for PTP daemon.

Workaround one: Use this workaround to reduce logging to critical errors only. Use the following procedures after a system reboot, a PTP daemon restart or any PTP global event like enabling or disabling PTP, or a change to PTP clock-step, transport or ptp modes.

1. Issue the systemctl stop ptpd command to stop the ptpd daemon.
2. Issue the rm /var/log/ptp.log command to remove /var/log/ptp.log.
3. Issue the systemctl start ptpd command to start the ptpd daemon.
4. Log in to the command-line interface and issue the show ptp clock command to verify that ptp is running and that the clock offset has a non-zero value and is updating continuously
5. From the bash prompt, execute the following commands:

   ovs-appctl -t ptpd ptp/ms_set_trace_level 28 0 ovs-appctl -t ptpd ptp/ms_set_trace_level 23 0 ovs-appctl -t ptpd ptp/ms_set_trace_level 19 0 ovs-appctl -t ptpd ptp/ms_set_trace_level 15 0 ovs-appctl -t ptpd ptp/ms_set_trace_level 14 0 ovs-appctl -t ptpd ptp/ms_set_trace_level 9 0 ovs-appctl -t ptpd ptp/ms_set_trace_level 8 0 ovs-appctl -t ptpd ptp/ms_set_trace_level 18 0 ovs-appctl -t ptpd ptp/ms_set_trace_level 10 0 ovs-appctl -t ptpd ptp/ms_set_trace_level 33 0 ovs-appctl -t ptpd ptp/ms_set_trace_level 29 0 ovs-appctl -t ptpd ptp/ms_set_trace_level 30 0 ovs-appctl -t ptpd ptp/ms_apr_log_ts stop ovs-appctl -t ptpd ptp/ms_apr_log_level_set 0

6.  Continue to monitor /var/log/ptp.log to verify that size is increasing more slowly.

Workaround two: This workaround prevents all logging. Use the following procedures after a sytem reboot,

1. Issue the systemctl stop ptpd command to stop the ptpd daemon.
2. Issue the rm /var/log/ptp.log command to remove /var/log/ptp.log.
3. Issue the command -s /dev/null /var/log/ptp.log to create a symlink.
4. Issue the systemctl start ptpd command to start the ptpd daemon.
5. log in to the command-line interface and issue the show ptp clock command to verify that ptp is running and that the clock offset has a non-zero value and is updating continuousl. Log files .will be suppressed and redirected to /dev/null

(For 6300 Switch Series only)

Symptom: Whenever PTP is enabled (or configured globally) on a PTP boundary clock (BC) switch, the device may select sub-optimal path if there are multiple announce messages received from the same Grand-Source-Clock (GSC) via different paths. The show ptp clock output may not always show the steps removed as the optimal path to GSC. 

Scenario: The scenario is likely to occur when there are announce messages received from the GSC on multiple paths and based on the order received the switch may select the last received announce as the best clock-source. If there is a change in order of announce messages (due to internal queuing or packet delays), then BC switch may toggle between the two different announces and start exhibit the above symptoms.

Workaround: The workaround for the problem is to stop the announce messages from the sub-optimal path reaching the BC switch either by disabling the source of the announce or install ACLs for the sub-optimal path's source IP (the originator of the PTP announces) and destination IP (PTP dest IP typically 224.0.1.129) so that all PTP messages would avoid reaching the BC switch from the sub-optimal path.

(For 6300 Switch Series only)

Symptom: A QoS schedule profile was not applied on some ports.

Scenario: This could happen either when a reboot was performed with the schedule profile configuration, when upgrading, or when schedule profile is applied when the port is down.

Workaround: Delete and re-apply the schedule profile configuration.

Symptom: A QoS rate-limit configuration applied via a dry-run or ShadowDB is not getting applied to the switch. An exclamation mark is shown in the CLI which is causing the dry-run to ignore the configuration.

Scenario: This issue happens only when applying the configuration via HPE Aruba Networking Central dry-run/shadowDB mode.

(For 6400 Switch Series only)

Symptom: Interface Tx drops increment on a V1 line card.

Scenario: This issue occurs when global block buffers are exhausted on the source line card.

(For 6300 Switch Series only)

Symptom: A TLS connection will intermittently fail when a RADIUS server FQDN address resolves to multiple IP addresses.

Scenario: This problem will occur when a FQDN address is resolved to different IP address after a VSF switchover, and then to the previous resolved address prior to switchover.

Workaround: Reconfigure the Radsec server.

Symptom: An interface remains down after a CoA port bounce, with interface details showing showing an authorization change as the reason.

Scenario: If a network administrator issues the shut command to shut down the port during the Port-Bounce duration, the interface continues to remain in the down state even after the port-bounce duration.

Workaround: Issue the command default interface <IFNAME> to return the interface configuration to its default value and bring the interface back up.

(For 6300 Switch Series only)

Symptom: Configuring an IPv6 address on a 6300L switch will display the below warning:

Configuring an IPv6 address on this device may result in undefined behavior.

Scenario: This issue occurs when configuring RADIUS or RADsec IPv6 settings using the command-line interface.

Symptom: A switch logs the following messages for every REST-based login to the switch; user 'UNKNOWN' from address 'UNKNOWN' through REST session.

Scenario: This issue can impact switches managed through the Advanced Fabric Composer or REST and having Syslog auditable-events with INFO severity level set as the default.

Symptom: SNMP output shows the ifOperStatus of the LAG interface as down when the forwarding state is blocked by MSTP.

Scenario: This issue is seen if the LAG interface is used as redundant links which are blocked by the MSTP.

(for 6300 Switch series only)

Symptom: An snmpd core-dump observed with signal:6.

Scenario: This issue occurred when the system-oid was polled from a SolarWinds NMS.

Symptom: When configuring a VLAN outside of the VLAN range through REST, the hpe-entityd process daemon restarts.

Scenario: When a VLAN configured through REST is outside the range of allowable VLAN values, hpe-entityd daemon restarts when attempting to match ports to currently configured VLANs.

Workaround: Do not configure VLANs outside the allowable range.

(for 6300 Switch series only)

Symptom: It is not possible to set dot1qVlanStaticEgressPorts and dot1qVlanStaticUntaggedPorts MIB objects using a HEX value, only a string was supported.

Scenario: Only a string could be used to successfully set and read the object values. With this change, when trying to snmpset or read values from snmpwalk, these two objects will now appear in Hex-String form.

Symptom: An RPVST daemon daemon restart occurred.

Scenario: This issue can occur when connecting an STP-aware switch to a port where spanning-tree guard is configured. Ensure that the peer switch has an RPVST VLAN that is not configured on the switch.

Workaround: Refrain from connecting STP-aware switches to these ports. Alternatively, temporarily remove the BPDU-guard configuration to prevent further daemon restarts.

(for 6300 Switch series only)

Symptom: Configuring an IPv6 address on a 6300L switch will display the below warning:

Configuring an IPv6 address on this device may result in undefined behavior.

Scenario: This issue occurs when configuring TACACS+ IPv6 settings using the command-line interface.

(for 6300 Switch series only)

Symptom: A camera will go offline, and will not be able to send video traffic to the controller or a recording to a storage server.

Scenario: This issue might be seen when the network goes down between the User-Based Tunneling (UBT) switch and the controller, either after OSPF fails for more than eight seconds, or when network congestion between the switch and the controller prevents the UBT heartbeat from reaching the controller for more than 8 seconds.

Workaround: Issue the shut/no shut commands on the camera-connected access port on the UBT switch to bring the camera back online.

Symptom: A port member is an ingress-only member for a VLAN, causing traffic drops.

Scenario: This issue occurs in a deployment when MAC authentication is enabled on multiple physical ports and each port has different VLAN. When a client onboarded on VLAN 10 in one of the port and a LAG port was later added to VLAN 10, moving the MAC-authentication enabled port into the LAG causes the switch to drop packets over the LAG interface. This is due to LAG ports set as an ingress-only member for vlan 10.

Symptom: A VSX software upgrade can take more than 20 minutes to complete.

Scenario: This issue can occur during a VSX software upgrade on a VXLAN deployment without IGMP/MLD running on a few VLANs associated with a VNI, when multicast control packets are coming in continuously through the VLAN.

Workaround: Enable IGMP/MLD snooping on all the VLANs where multicast clients are sending IGMP/MLD control packets.

Symptom: A VXLAN tunnel between switches doesn't come up.

Scenario: This issue is observed in a Switch stack after performing software upgrade.

Workaround: Disable and then reenable the VXLAN Interface.