Dashboard Alerts - Configuration Issues

Triggers

If the current number of routed clients exceeds the maximum routable client limit for the specific switch model. 

Troubleshooting Steps

Refer to MS Switch FAQ for details on the maximum routable clients limit per switch model.

---

Triggers

This is a Configuration Source: Device error.

The device must have 4 unused consecutive VTY slots. These VTY lines will be provisioned and secured for only the dashboard to access the device on these lines.

Troubleshooting Steps

Refer to Troubleshooting Dashboard Connectivity to Catalyst 9800 Wireless Controllers to learn how to remediate this error.

---

Triggers

SISF-based device tracking is disabled by default. 

Troubleshooting Steps

You can enable it by defining a device tracking policy and attaching the policy to a specific target. Refer to Configure SISF-Based Device Tracking.

---

Triggers

When the “Enable Safe Mode” option is enabled on the local status page.

Troubleshooting Steps

This feature is used to help enable troubleshooting the device and should be turned off when finished.

---

Triggers

The system is currently blocking serving the bad config to this device. Missing required fields for a proper config.

Troubleshooting Steps

Check and validate all required port config fields. 

---

Triggers

Device is running a firmware version that is no longer supported.

Troubleshooting Steps

Update firmware to a supported level.

---

Triggers

When a device’s gateway does not match the majority of other devices on the network.

Troubleshooting Steps

Check and validate gateways settings.

---

Triggers

This is a DFS event and it has detected RADAR in the environment.

Troubleshooting Steps

DFS should hop off the channel and select a non radar sharing channel. You can also manually exclude those channels identified so as not to have an issue in the future.

---

Triggers

These errors will appear as an alert on the device (just like invalid config).

Troubleshooting Steps

The details of the error will indicate which fields were not in the config inventory.

---

Triggers

When Prefix Starvation occurs, which is when the MX detects it does not have enough prefixes from a given WAN or manual configuration to assign a /64 prefix to each IPv6 enabled VLAN.

Troubleshooting Steps

Check and validate IPv6 settings.

---

Triggers

More tunnels have been defined than is recommended for the model.

Troubleshooting Steps

See MX Sizing Guide & Principles to check recommendations.

---

Triggers

Apple MDM certificate needs attention.

Troubleshooting Steps

1. Download Meraki CSR file from Organization > MDM page.
2. Log in to Apple's Push Notification Portal with the same Apple ID used to create the current push certificate.
   Note: If the Apple ID is not known, review "I Forgot Which Apple ID was Originally Used." Not using the original Apple ID (and therefore the original Apple Push certificate) would result in losing management of the previously enrolled devices. 
3. Find the expiring certificate, and select Renew (do not revoke expiring certificate, nor create a new certificate).
4. Upload CSR downloaded as per Step 1.
5. Download renewed certificate from Apple, and upload into Dashboard.
6. Enter/Confirm Apple ID used to log-in to Apple's push notification portal (highly recommended).

---

Triggers

Apple MDM certificate needs attention.

Troubleshooting Steps

1. Download Meraki CSR file from Organization > MDM page.
2. Log in to Apple's Push Notification Portal with the same Apple ID used to create the current push certificate.
   Note: If the Apple ID is not known, review "I Forgot Which Apple ID was Originally Used." Not using the original Apple ID (and therefore the original Apple Push certificate) would result in losing management of the previously enrolled devices. 
3. Find the expiring certificate, and select Renew (do not revoke expiring certificate, nor create a new certificate).
4. Upload CSR downloaded as per Step 1.
5. Download renewed certificate from Apple, and upload into Dashboard.
6. Enter/Confirm Apple ID used to log-in to Apple's push notification portal (highly recommended).

---

Triggers

Apple MDM certificate needs attention.

Troubleshooting Steps

1. Download Meraki CSR file from Organization > MDM page.
2. Log in to Apple's Push Notification Portal with the same Apple ID used to create the current push certificate.
   Note: If the Apple ID is not known, review "I Forgot Which Apple ID was Originally Used." Not using the original Apple ID (and therefore the original Apple Push certificate) would result in losing management of the previously enrolled devices. 
3. Find the expiring certificate, and select Renew (do not revoke expiring certificate, nor create a new certificate).
4. Upload CSR downloaded as per Step 1.
5. Download renewed certificate from Apple, and upload into Dashboard.
6. Enter/Confirm Apple ID used to log-in to Apple's push notification portal (highly recommended).

---

Triggers

During enrollments or re-enrollments, Systems Manager uses a variety of uniquely identifying values from clients to attempt to determine a device's hardware identity for pairing against it's Systems Manager identity. On mobile devices, this is usually the IMEI (International Mobile station Equipment Identity). This alert triggers when a device’s IMEI cannot be detected.

Troubleshooting Steps

It's recommended to contact the manufacturer or reseller of the device, as a missing IMEI will impact the device's ability to connect to the cellular grid. 

---

Triggers

If Dashboard detects a collision of these values for enrolled or enrolling devices, an alert may be displayed with a link to filter the clients list down to those devices which are suspected. These values are important for both SM and other software; on mobile devices, these values can affect the device's ability to connect to the cellular grid. 

Troubleshooting Steps

Refer to Duplicate UUID or IMEI Detected Warnings on Dashboard.

---

Triggers

During enrollments or re-enrollments, Systems Manager uses a variety of uniquely identifying values from clients to attempt to determine a device's hardware identity for pairing against it's Systems Manager identity. On desktop machines, this is usually the BIOS UUID (Universally Unique Identifier). On mobile devices, this is usually the IMEI (International Mobile station Equipment Identity). This alert triggers when a device’s UUID or IMEI cannot be detected.

Troubleshooting Steps

It's recommended to contact the manufacturer or reseller of the device, as a missing IMEI or UUID will impact the device's ability to connect to the cellular grid.  

---

Triggers

If Dashboard detects a collision of these values for enrolled or enrolling devices, an alert may be displayed with a link to filter the clients list down to those devices which are suspected. These values are important for both SM and other software; on mobile devices, these values can affect the device's ability to connect to the cellular grid. 

Troubleshooting Steps

Refer to Duplicate UUID or IMEI Detected Warnings on Dashboard.

---

Triggers

Enrollment authentication is disabled.

Troubleshooting Steps

Refer to SM Enrollment Authentication.

---

Triggers

This is a Configuration Source: Device error.

If dashboard is unable to access the device's cloud console during the initial onboarding process, this may be due to the username, password or enable password provided during onboarding cannot authenticate to the device.

Troubleshooting Steps

Refer to Troubleshooting Dashboard Connectivity to Catalyst 9800 Wireless Controllers to learn how to remediate this error.

---

Triggers

This is a Configuration Source: Device error.

The device must have 4 unused consecutive VTY slots. These VTY lines will be provisioned and secured for only the dashboard to access the device on these lines.

Troubleshooting Steps

Refer to Troubleshooting Dashboard Connectivity to Catalyst 9800 Wireless Controllers to learn how to remediate this error.

---

Triggers

This is a Configuration Source: Device error.

The configuration for the device is out of date. 

Troubleshooting Steps

Contact Meraki support for further troubleshooting.

---

Triggers

This is a Configuration Source: Device error.

If dashboard is unable to access the device's cloud console during the initial onboarding process, this may be due to the username, password or enable password provided during onboarding cannot authenticate to the device.

Troubleshooting Steps

Refer to Troubleshooting Dashboard Connectivity to Catalyst 9800 Wireless Controllers to learn how to remediate this error.

---

Triggers

This is a Configuration Source: Device error.

If dashboard is unable to access the device's cloud console during the initial onboarding process, this may be due to the username, password or enable password provided during onboarding cannot authenticate to the device.

Troubleshooting Steps

Refer to Troubleshooting Dashboard Connectivity to Catalyst 9800 Wireless Controllers to learn how to remediate this error.

---

Triggers

This is a Configuration Source: Device error.

Dashboard is unable authenticate SSH with the device using the dashboard provisioned device local meraki-user account.

Troubleshooting Steps

Refer to Troubleshooting Dashboard Connectivity to Catalyst 9800 Wireless Controllers to learn how to remediate this error.

---

Triggers

This is a Configuration Source: Device error.

Dashboard is unable to connect to the device's cloud console through the Meraki tunnel, and the Meraki tunnel interfaces are UP.

Troubleshooting Steps

Contact Meraki support for further troubleshooting.

---

Triggers

This is a Configuration Source: Device error.

Dashboard is unable to access the device via SSH through the Meraki tunnel, and the Meraki tunnel interfaces are UP.

Troubleshooting Steps

Contact Meraki support for further troubleshooting.

---

Triggers

This is a Configuration Source: Device error.

Dashboard is unable to perform NETCONF operations on the device through the Meraki tunnel, and the Meraki tunnel interfaces are UP.

Troubleshooting Steps

Contact Meraki support for further troubleshooting.

---

Triggers

This is a Configuration Source: Device error.

To complete the onboarding configuration with the cloud console, the username provided during onboarding must have authorization for all the required onboarding configuration commands.

Troubleshooting Steps

Refer to Troubleshooting Dashboard Connectivity to Catalyst 9800 Wireless Controllers to learn how to remediate this error.

---

Triggers

This is a Configuration Source: Device error.

Dashboard is unable authorize commands via SSH with the device using the dashboard provisioned device local meraki-user account. AAA settings on the device must permit the meraki-user account to authorize the commands used for onboarding.

Troubleshooting Steps

Refer to Troubleshooting Dashboard Connectivity to Catalyst 9800 Wireless Controllers to learn how to remediate this error.

---

Triggers

This is a Configuration Source: Device error.

The device must use AAA new-model for device access control. This mode allows the dashboard to securely access the device.

Troubleshooting Steps

Refer to Troubleshooting Dashboard Connectivity to Catalyst 9800 Wireless Controllers to learn how to remediate this error.

---

Triggers

This is a Configuration Source: Device error.

The following SSH encryption algorithms are supported by the dashboard:

• aes128-gcm@openssh.com
• aes256-gcm@openssh.com
• aes128-ctr
• aes192-ctr
• aes256-ctr 

Troubleshooting Steps

Refer to Troubleshooting Dashboard Connectivity to Catalyst 9800 Wireless Controllers to learn how to remediate this error.

---

Triggers

This is a Configuration Source: Device error.

Dashboard utilizes the HTTP secure server interface to read telemetry data from device. If your HTTP services are restricted by an IPv6 access control list, you must update the ACL to permit access from the Meraki tunnel interface subnet FD0A:9B09:1F7:1::/64.

Troubleshooting Steps

Refer to Troubleshooting Dashboard Connectivity to Catalyst 9800 Wireless Controllers to learn how to remediate this error.

---

Triggers

This is a Configuration Source: Device error.

Dashboard must provision the following command on the device in order to set the 4 configured VTY lines to be access able on port 2222.

Troubleshooting Steps

Refer to Troubleshooting Dashboard Connectivity to Catalyst 9800 Wireless Controllers to learn how to remediate this error.

---

Triggers

This is a Configuration Source: Device error.

During onboarding, dashboard will check the device AAA default authorization method list begins with 'local.'

Troubleshooting Steps

Refer to Troubleshooting Dashboard Connectivity to Catalyst 9800 Wireless Controllers to learn how to remediate this error.

---

Triggers

This is a Configuration Source: Device error.

If you have previously added and then removed your device from dashboard and the dashboard provisioned usernames were not removed from the configuration, dashboard will fail to configure these usernames if they already exist in the configuration.

Troubleshooting Steps

Refer to Troubleshooting Dashboard Connectivity to Catalyst 9800 Wireless Controllers to learn how to remediate this error.

---

Triggers

This is a Configuration Source: Device error.

If you have previously added and then removed your device from dashboard and the dashboard provisioned usernames were not removed from the configuration, dashboard will fail to configure these usernames if they already exist in the configuration.

Troubleshooting Steps

Refer to Troubleshooting Dashboard Connectivity to Catalyst 9800 Wireless Controllers to learn how to remediate this error.

---

Triggers

This is a Configuration Source: Device error.

Dashboard is unable to authorize NETCONF with the device using the dashboard provisioned device local meraki-user account. AAA settings on the device must permit the meraki-user account to authorize. Additional information may be available in the device log (show log). Verify there are no NETCONF aaa authorization conflicts.

Troubleshooting Steps

Contact Meraki support for further troubleshooting.

---

Triggers

The certificate is no longer valid.

Troubleshooting Steps

To renew your Self Signed SCEP CA Certificate, you will simply need to download the CSR file available on the dashboard under Organization > MDM > SCEP CA Certificate Configuration. Once downloaded, you can sign the certificate with your Certificate Authority and re-upload it to the Dashboard. You will see an alert on Dashboard to renew your custom Third Party Signed SCEP cert if it is set to expire soon. 

Refer to MDM Settings.

---

Triggers

The certificate will expire soon.

Troubleshooting Steps

To renew your Self Signed SCEP CA Certificate, you will simply need to download the CSR file available on the dashboard under Organization > MDM > SCEP CA Certificate Configuration. Once downloaded, you can sign the certificate with your Certificate Authority and re-upload it to the Dashboard. 

Refer to MDM Settings.

Triggers

One or more dashboard required IOS XE configurations are missing. Dashboard will provision these configurations when IOS XE hybrid mode switch is added to a network. These configurations are required to allow the dashboard to enable Cloud-Managed Catalyst hybrid mode switches and will need to be re-applied for dashboard management.

Troubleshooting Steps

Update IOS XE with the following configurations based on the missing configuration alert.

• Access Control Lists (ACLs) for Meraki Cloud Access

ip access-list standard MERAKI_MGMT_IP_IN
    20 deny any
ip access-list extended MERAKI_MGMT_IP_OUT
    20 deny tcp any any
ipv6 access-list MERAKI_MGMT_IPV6_IN
    sequence 10 permit tcp FD0A:9B09:1F7:1::/64 FD0A:9B09:1F7:1::/64 eq 2222
    sequence 20 deny tcp any any
ipv6 access-list MERAKI_MGMT_IPV6_OUT
    sequence 20 deny tcp any any

• Configuration change notification and logging for Cloud CLI

archive
 log config
  logging enable
  notify syslog contenttype xml

• Device tracking policy on ports for client tracking

device-tracking policy MERAKI_ACCESS_TRACK
 limit address-count 1000
 security-level glean
 tracking enable
device-tracking policy MERAKI_NO_TRACK
 trusted-port
 security-level glean
 no protocol ndp
 no protocol dhcp6
 no protocol arp
 no protocol dhcp4
device-tracking policy MERAKI_TRUNK_TRACK
 limit address-count 32000
 security-level glean

• EEM policy for Cloud CLI

event manager applet MERAKI_SHOW_RUN_EXEC
 event cli pattern "show running-config" sync yes
 action 1.0 if $_cli_username eq meraki-cli-ro
 action 1.1 cli command enable
 action 1.2 cli command $_cli_msg
 action 1.3 puts $_cli_result
 action 1.4 set _exit_status 0
 action 2.0 else
 action 2.1 set _exit_status 1
 action 3.0 end

• ip flow exporter for client tracking

flow file-export default
 file max-create-interval 5
 file max-count 2
 
flow exporter MERAKI_TA1
 destination local file-export default
 export-protocol ipfix
 option interface-table timeout 300

• ip flow exporter for traffic analysis

flow file-export default
 file max-create-interval 5
 file max-count 2

flow exporter MERAKI_TA2
 destination local file-export default
 export-protocol ipfix
 option interface-table timeout 300

• ip flow monitor for client tracking

flow monitor MERAKI_TA1_V4_IN
 exporter MERAKI_TA1
 cache timeout inactive 300
 cache timeout active 300
 record MERAKI_TA1_V4_IN
                
flow monitor MERAKI_TA1_V4_OUT
 exporter MERAKI_TA1
 cache timeout inactive 300
 cache timeout active 300
 record MERAKI_TA1_V4_OUT

• ip flow monitor for traffic analysis

flow monitor MERAKI_TA2_IPV4
 exporter MERAKI_TA2
 cache timeout inactive 300
 cache timeout active 300
 cache entries 65536
 record MERAKI_TA2_HTTP_SSL_IPV4

• ip flow record for client tracking

flow record MERAKI_TA1_V4_IN
 description meraki_ta1_ingress
 match application name
 match interface input
 match ipv4 source address
 collect counter bytes long
 collect counter packets long
 collect datalink dot1q vlan input
 collect datalink mac source address input
 collect flow direction
        
flow record MERAKI_TA1_V4_OUT
 description meraki_ta1_egress
 match application name
 match interface output
 match ipv4 destination address
 collect counter bytes long
 collect counter packets long
 collect datalink dot1q vlan output
 collect datalink mac destination address output
 collect flow direction

• ip flow record for traffic analysis

flow record MERAKI_TA2_HTTP_SSL_IPV4
 match application name
 match connection client ipv4 address
 match connection server ipv4 address
 match connection server transport port
 match flow observation point
 match ipv4 protocol
 match ipv4 version
 collect connection client counter bytes network long
 collect connection client counter packets long
 collect connection initiator
 collect connection new-connections
 collect connection server counter bytes network long
 collect connection server counter packets long
 collect flow direction
 collect interface input
 collect interface output
 collect timestamp absolute first
 collect timestamp absolute last

• HTTP server configuration

ip http secure-server
 
! Only apply the config when there is not any authentication config for http server
ip http authentication local
 
! Only apply the config when there is HTTP ACL rule for IPV4(The IPV4 rule blocks IPV6 traffic. It is a device bug.)
ip http access-class ipv6 MERAKI_MGMT_IPV6_IN

• device tracking policy on interfaces [xxx, xxx]

interface xxx
 device-tracking attach-policy MERAKI_ACCESS_TRACK

• ip flow monitor on interfaces [xxx, xxx]

interface xxx
 ip flow monitor MERAKI_TA1_V4_IN input
 ip flow monitor MERAKI_TA1_V4_OUT input

• default IPv6 route with distance 2 for Meraki tunnel

ipv6 unicast-routing

• Global LLDP configuration for neighbor information

lldp run

• Telemetry subscription and receiver configurations for event logs

telemetry ietf subscription 10000
 encoding encode-tdl
 filter tdl-uri /services;serviceName=stkm_oper/stack_info
 receiver-type pullmode
 source-vrf Mgmt-vrf
 stream native
 update-policy periodic 6000
 receiver name meraki_stack_info
telemetry ietf subscription 10002
 encoding encode-tdl
 filter tdl-uri /services;serviceName=iosevent/syslog_msg
 receiver-type pullmode
 stream native
 update-policy on-change
 receiver name meraki_syslog_msg
 
telemetry receiver pullmode meraki_stack_info
 size 1000000
telemetry receiver pullmode meraki_syslog_msg
 size 50000000

• Local users (meraki-cli-ro or merakicli-rw) for Cloud CLI

username meraki-cli-ro view MERAKI-MONITOR secret 9 xxx
username meraki-cli-rw privilege 15 view MERAKI-CONFIG secret 9 xxx

ip ssh pubkey-chain
  username meraki-cli-ro
    key-hash {KEY_HASH}
  username meraki-cli-rw
    key-hash {KEY_HASH}

Contact Meraki support if the IP SSH key configuration needs to be configured on your IOS XE device.

parser view MERAKI-CONFIG inclusive
 secret 9 xxx
 commands configure exclude all parser
 commands configure exclude all archive
 commands configure exclude all ntp
 commands configure exclude all timezone
 commands configure exclude all clock
 commands exec exclude all clock
 commands exec exclude all show memory
 commands exec exclude all show tech-support
parser view MERAKI-MONITOR
 secret 9 xxx
 commands exec include traceroute
 commands exec include ping
 commands exec include terminal width
 commands exec include terminal length
 commands exec include terminal
 commands exec exclude all show memory
 commands exec exclude all show tech-support
 commands exec include all show

• Syslog SNMP traps for event logs

logging snmp-trap 0 4
logging history informational
snmp-server enable traps syslog

• SNMP traps for config change notification

Contact Meraki support for this configuration to be re-applied.

• Log level configuration for syslog-events

logging syslog-events informational

---

Triggers

Device's configuration has not yet synchronized with the changes made in the Meraki dashboard. This can occur due to delays in applying updates, network connectivity issues, or high load on the Meraki shard.

Troubleshooting Steps

• Check Network Connectivity Ensure that the device has stable internet access. Poor connectivity can delay configuration updates.

• Monitor Bandwidth Utilization High bandwidth usage during configuration changes can slow down synchronization. Check your network's utilization and reduce load if necessary.

• Wait for Synchronization In most cases, changes should apply within 1-5 minutes. However, occasional delays of up to 10-20 minutes may occur due to shard load or other factors.

• Reboot the Device If a device remains out of sync for an extended period, rebooting it may force it to fetch the latest configuration from the dashboard.

• Contact Support If delays persist beyond normal expectations and a reboot does not resolve it, reach out to support. They can check for shard-related issues or maintenance tasks that might be causing delays.

---

Triggers

One or more of the required IOS XE internal usernames already exists in the IOS XE configuration.

Troubleshooting Steps

Username meraki-cli-ro or meraki-cli-rw already exists on the device. Please remove it manually from the IOS XE running configuration.

---

Triggers

Dashboard utilizes the NETCONF to provision wireless controllers. If your NETCONF-YANG services are restricted by an IPv6 access control list, you must update the ACL to permit access from the Meraki Tunnel interface subnet FD0A:9B09:1F7:1::/64

Troubleshooting Steps

Refer to Troubleshooting Dashboard Connectivity to Catalyst 9800 Wireless Controllers to learn how to remediate this error.

---

Triggers

Typically occurs when a Cisco device or feature requires a valid Cisco DNA license to operate, but the license is either missing, expired, or not properly applied. This error can arise due to several causes:

• The device does not have the appropriate Cisco DNA subscription license installed or activated. Cisco DNA licenses are mandatory for certain platforms and features, such as Catalyst 8300/8200 series edge platforms, which require Cisco DNA subscription licenses to enable traditional and advanced IOS-XE features.

• License compliance issues can occur if the device is not properly synchronized with Cisco Smart Software Management (CSSM). Devices in highly secured networks with limited internet access may fail to sync, causing license errors. Specific License Reservation (SLR) or Permanent License Reservation (PLR) can be used in such cases to reserve licenses without continuous CSSM connectivity.

• Communication failures between the device and Cisco Smart Licensing servers (CSSM or CSLU) can cause authorization failures. This may be due to network reachability issues, DNS resolution problems, or incorrect license server URLs.

• System clock inaccuracies or lack of synchronization with NTP servers can cause signature or timestamp mismatches, leading to license authorization failures.

Troubleshooting Steps

• Verify License Type and Validity

  • Confirm you have the correct Cisco DNA license type (e.g., DNA Advantage, DNA Essentials, or DNA Premier) for your device and use case.
  • Check if the license is active and not expired, especially for subscription-based DNA-stack add-on licenses which have term limits (3, 5, or 7 years).
  • Ensure that the license tier supports your device throughput and features; for example, Tier 3 or higher tiers are not supported with Network Essentials and DNA Essentials licenses

• Set Up and Register Licenses in Cisco DNA Center

  • Access Cisco DNA Center with appropriate admin permissions.
  • Configure Cisco Smart Account credentials and link your Smart Account(s) in DNA Center under System > Settings.
  • Register devices and assign licenses via the License Manager tool in Cisco DNA Center.
  • For devices running IOS XE 17.3.2 or later, use the Smart License Compliance Reporting workflow for license registration

• Check Device Connectivity and Communication

  • Ensure devices can reach Cisco Smart Software Manager (CSSM) portals (tools.cisco.com) for license validation.
  • Verify network connectivity and firewall rules allow required ports and URLs for license communication.
  • Confirm devices are present and reachable in Cisco DNA Center inventory with assigned sites.
  • Check that the system clock is accurate and synchronized with an NTP server

• Troubleshoot License Errors and Status

  • Use Cisco DNA Center License Manager to view license status and compliance reports.
  • For migrated devices (e.g., from Meraki to DNA management mode), ensure proper license availability and controller connectivity; devices may enter a "looking for controller" state if licenses or controllers are missing

---

Triggers

Occurs when your SSH client and the SSH server you're trying to connect to cannot agree on a common compression algorithm to use for the session. SSH connections involve a negotiation process where both sides propose a list of supported algorithms (including key exchange, encryption, message authentication code, and compression). If no mutually supported compression algorithm is found, the connection fails.

Troubleshooting Steps

• Enable Compression on the Client Side

• Check and Configure Compression on the Server Side

• Update SSH Client and Server Software.  Outdated SSH software is a common cause of algorithm negotiation failures, as newer, more secure algorithms are introduced and older, less secure ones are deprecated. Updating your SSH client and server to the latest stable versions is often the most robust and recommended long-term solution.

• Use Verbose Mode for Debugging. To get more detailed information about the algorithm negotiation process and pinpoint the exact mismatch, use the verbose option (-v) with your ssh command: ssh -v username@your_server_ip.  You can add more v's (e.g., -vvv) for even more detailed output.

---

Triggers

Indicates that your SSH client and the SSH server you are trying to connect to cannot agree on a mutually supported cryptographic algorithm for authenticating the server's identity. This often occurs when one side (usually the client) has been updated to deprecate older, less secure algorithms, while the other side (often an older server or device) still relies on them.

Troubleshooting Steps

• Identify Supported Algorithms

• Modify SSH Client Configuration. If the server supports an algorithm that your client has deprecated (e.g., ssh-rsa), you can temporarily enable it for a specific connection or permanently configure your client.  You can specify the desired host key algorithm directly in the ssh command using the -o option. For example, to enable ssh-rsa: ssh -oHostKeyAlgorithms=+ssh-rsa user@your_server_ip

• For a more permanent solution, you can add an entry to your SSH client configuration file, usually ~/.ssh/config. This allows you to apply the settings only to specific hosts.

• Security Considerations

  • Prioritize Updates: The best long-term solution is to update both your SSH client and server software to their latest versions. This ensures support for the most secure and efficient algorithms.

  • Avoid Weak Algorithms: Enabling older algorithms like ssh-rsa (which uses SHA-1 for signing) should be a last resort and only for connecting to legacy systems that cannot be updated. SHA-1 is cryptographically weak and vulnerable to collision attacks.

  • Scoped Configuration: If you enable weaker algorithms, always restrict them to specific Host entries in your client's ~/.ssh/config or Match blocks in the server's sshd_config to minimize security exposure

---

Triggers

Occurs when your SSH client and the SSH server cannot agree on a common key exchange (KEX) algorithm to establish a secure connection. This often happens due to outdated SSH client or server software, or strict security configurations that disable older, less secure algorithms.

Troubleshooting Steps

• Identify Supported KEX Algorithms. The first step is to determine which KEX algorithms are supported by both your SSH client and the SSH server you are trying to connect to.

• The most recommended solution is to update both your SSH client and the SSH server to their latest versions. This ensures you have access to the most secure and widely supported algorithms.

• If updating is not immediately possible, or if specific security configurations are in place, you might need to manually enable or prioritize compatible algorithms.

• You can specify a KEX algorithm (client side) to use for a single SSH connection using the -o KexAlgorithms=<algorithm> option. Example: ssh -o KexAlgorithms=<algorithm name> user@your_server_ip

---

Triggers

Indicates that your SSH client and the SSH server you are trying to connect to do not have any common Message Authentication Code (MAC) algorithms enabled. MAC algorithms are crucial for ensuring the integrity and authenticity of data exchanged during an SSH session, preventing tampering and ensuring the data has not been altered.

Troubleshooting Steps

• Identify Supported MAC Algorithms. You can list the MAC algorithms supported by your SSH client using the ssh -Q mac command.

• Understand MAC Algorithm Security

  • Recommended/Secure MAC Algorithms:

    • hmac-sha2-256
    • hmac-sha2-512
    • hmac-sha2-256-etm@openssh.com (Encrypt-then-MAC)
    • hmac-sha2-512-etm@openssh.com (Encrypt-then-MAC)
    • umac-128-etm@openssh.com

  • Weak/Deprecated MAC Algorithms (avoid if possible):

    • hmac-md5
    • hmac-md5-96
    • hmac-sha1 (while still widely supported, SHA-2 variants are preferred)
    • hmac-sha1-96
• Once you've identified a common, secure MAC algorithm, you can configure either your client to use it. 
• Temporary (for a single connection): You can specify the MAC algorithm directly in the ssh command using the -m or -oMACs option. Example: ssh -oMACs=hmac-sha2-512,hmac-sha2-256 user@your_server_ip
• Permanent (for your user): Edit your SSH client configuration file, typically ~/.ssh/config. Add or modify the MACs directive for the specific host or globally.

---

Triggers

Ttypically indicates a mismatch or incompatibility between the SSH client and the SSH server regarding the cryptographic algorithms they are configured to use for key exchange, host key authentication, ciphers, or message authentication codes (MACs).

Troubleshooting Steps

• Verify SSH Public Key Algorithms Configuration.  Ensure that the SSH server is configured to support the required public key algorithms. On Cisco devices, you can check and configure the SSH server settings using the sshconfig command. 

• Verify if SSH client keys are present using the command show ssh client key. If keys are missing, generate them and push the public key to the remote server using the appropriate CLI commands such as push ssh-key <hostname> user <username>. Also, confirm that the remote server supports public key authentication

• Update RSA Key Size if Using Cisco IOS XE. If you are using Cisco IOS XE Release 17.11.1 or later, RSA keys smaller than 2048 bits are not supported by default. Check the RSA key modulus size with show ip ssh | include Modulus.  If the key size is less than 2048 bits, generate a new RSA key pair with at least 2048 bits using:

  • crypto key generate rsa modulus 2048 label strong-ssh-key
    ip ssh rsa keypair-name strong-ssh-key

• ​​​​​​​Configure SSH Algorithms Explicitly. On Cisco IOS devices, you can explicitly configure the SSH server and client algorithms for encryption, MAC, host key, and key exchange to ensure compatibility

• Consider SSH Client Compatibility. Some newer SSH clients may consider certain algorithms like ssh-rsa unsafe and block connections. Ensure that the client and server support mutually compatible algorithms.

---

Triggers

Wireless controller standby was not added to the network. There was an error adding the standby chassis to the network

Troubleshooting Steps

The device already exists in the Meraki dashboard. To fix this issue, remove the standby from the network it is currently in. Once deleted, the standby will automatically be added to the intended network. The Meraki dashboard will continue to retry adding these devices in the background. If the standby WLC continues to fail to add to the network contact Meraki support.

 

---

Triggers

One or more access points associated to the WLC the failed to onboard.

Troubleshooting Steps

The Meraki dashboard will continue to retry adding these devices in the background. If the AP's continue to fail please contact Meraki support.

---

Triggers

An error occurring when the system is unable to successfully generate or apply the configuration for Dashboard. This can happen due to various reasons such as network connectivity issues, delays in applying updates, or internal system errors during the configuration process.

Troubleshooting Steps

• Check Network Connectivity. Ensure the Meraki device has stable internet access. Poor connectivity can delay or prevent configuration updates from being applied, causing this error.

• Monitor Bandwidth Utilization. High bandwidth usage during configuration changes can slow down synchronization. Check your network's utilization and reduce load if necessary.

• Wait for Synchronization. Configuration changes typically apply within 1-5 minutes. However, delays of up to 10-20 minutes may occur due to high load on the Meraki shard or other factors. Allow some time for the changes to propagate.

• Reboot the Device. If the device remains out of sync for an extended period, rebooting it may force it to fetch the latest configuration from the dashboard.

• Verify for Configuration Conflicts. Check for any internal username conflicts on IOS XE devices (e.g., usernames like meraki-cli-ro or meraki-cli-rw), which should be removed manually from the device configuration. For wireless controllers, ensure AAA settings permit the Meraki user account to authenticate and authorize commands properly.

• Check for IPv6 ACL Conflicts. If using NETCONF provisioning, ensure IPv6 ACLs permit access from the Meraki Tunnel interface subnet FD0A:9B09:1F7:1::/64.

• Review Firmware Compatibility. Ensure devices are running firmware versions compatible with the features in use, such as Open Roaming or vMX firmware requirements.

• Try Different Internet Connection. If possible, connect the device through a different internet connection to rule out upstream network issues.

---

Triggers

Indicates that the Meraki Dashboard was unable to successfully apply or generate the intended configuration on the device.

Troubleshooting Steps

• Verify Device Connectivity:

  • Check if the device is powered on and connected properly.

  • Confirm the device is reachable from the Meraki Dashboard.

  • Review device LED status and run cable tests if needed.

• Check Credentials:

  • Ensure the username, password, and enable password used during onboarding are correct.

  • Incorrect credentials can cause the dashboard to fail accessing the device for configuration.

• Review Configuration Parameters:

  • Validate access policies, Radius server IPs, ports, and secret keys if 802.1X is used.

  • Remove or disable unused or dummy Radius server entries.

• Check Dashboard Alerts and Logs:

  • Look for specific error messages related to configuration failures.

  • Review event logs under Network-wide > Event Log in the Meraki Dashboard.

• Device Registration and Licensing:

  • For virtual devices like C9800-CL wireless controllers, ensure the device is properly registered and claimed in the Meraki Dashboard.

  • Verify licenses are valid and applied correctly.

• Restart or Reboot Device:

  • Power cycle the device to clear transient issues.

---

Triggers

Open Roaming is enabled on firmware that does not support this feature

Troubleshooting Steps

Upgrade the network devices to a firmware version that supports Open Roaming.  Wireless networks in Dashboard needs to be configured for firmware version 28.5 or above. This is the minimum firmware requirement for the feature to work. 

---

Triggers

This device has disabled the 6 GHz frequency band because there are no active SSIDs using WPA3 encryption.

Troubleshooting Steps

Ensure that all SSIDs enabled for 6 GHz are configured for WPA3

---

Triggers

Occurs when there is a conflict or issue with the virtual terminal lines (VTYs) on a Cisco device. VTY lines are used for remote access sessions such as Telnet or SSH.

Troubleshooting Steps

• Check current VTY line usage:

  • Use the command show users or show line to see active sessions and which VTY lines are occupied.

• Clear stale or hung VTY sessions:

  • Use clear line <line_number> to free up VTY lines that are stuck or idle.

• Configure idle timeout:

  • Set an exec-timeout on VTY lines to automatically disconnect idle sessions

• Verify transport protocols:

  • Ensure VTY lines allow the desired protocols (SSH, Telnet) using the transport input command

• Review and adjust access control:

  • Check for any access-class or access-list applied to VTY lines that might restrict access improperly.

• Increase the number of VTY lines if needed:

  • Some devices allow increasing the number of VTY lines, e.g., line vty 0 15 to allow more simultaneous sessions.

• Reboot device if necessary:

  • If conflicts persist and cannot be cleared, a device reboot may clear stuck sessions.

---

Triggers

Occurs when a trunk port on a switch does not have the correct VLANs allowed on it, which can cause connectivity problems for devices relying on those VLANs.

Troubleshooting Steps

By ensuring the trunk port is correctly configured with the appropriate allowed VLANs, and that the VLANs themselves are active and consistent across the network, the "Switchport Allowed VLANs Missing" issue can be resolved.

• Verify trunk mode on the port

• Check allowed VLANs on the trunk

• Ensure VLANs exist and are active

• Check native VLAN settings

• Review VTP status and VLAN propagation

• Clear and reset trunk port if needed

• Check for errDisable state or port shutdown

---

Triggers

Indicates that certain VLANs expected or required on a switch are not configured or active, which can cause connectivity or segmentation problems.

Troubleshooting Steps

• Verify VLAN existence and status:

  • Use commands like show vlan brief to confirm required VLANs are present and active.

  • Create missing VLANs if necessary.

• Check VLAN interface state:

  • Ensure VLAN interfaces are not administratively down.

• Verify trunk port VLAN allowed list:

  • Confirm trunk ports allow the required VLANs.

  • Configure allowed VLANs explicitly if missing.

• Avoid overlapping VLAN pools without proper domain and EPG association (for ACI environments):

  • Associate overlapping VLANs to different Attachment Access Entity Profiles (AAEPs) and Endpoint Groups (EPGs).

  • Enable EPG VLAN validation to prevent conflicts.

• Use VLAN filtering carefully:

  • Ensure VLAN filters include all required VLANs.

• Reapply or reset VLAN configurations if needed.

---

Triggers

A vMX that is running 'on-prem' on a Cisco Enterprise Network Function Virtualization Infrastructure Software (NFVIS) appliance and has it's network firmware set to a version of MX firmware below MX 19.2.

Troubleshooting Steps

Upgrade the configured network firmware version to be above MX 19.2 on the Organization > Firmware Upgrades page.

---