Reoccurring NSX alarm " Global Router MTU Too Big" , with no found MTU mismatch
search cancel

Reoccurring NSX alarm " Global Router MTU Too Big" , with no found MTU mismatch

book

Article ID: 429246

calendar_today

Updated On:

Products

VMware NSX

Issue/Introduction

The alarm " Global Router MTU Too Big" is seen in the NSX UI even after manually resolving the alarm, running the MTU check reports an overall consistent MTU Status, and verifying configuration requirements for both the NSX environment and physical networking (refer to Guidance to Set Maximum Transmission Unit for more details on configurations for MTU with NSX).

The alarm itself will look similar to the below example:

The global router MTU configuration is bigger than MTU of switches in overlay Transport Zone which connects to Tier0 or Tier1. Global router MTU value should be less than all switches MTU value by at least a 100 as we require 100 quota for Geneve encapsulation.

In the NSX Manager phonehome-coordinator logs the following data can be found:

 INFO pool-89-thread-1 MonitoringEventInstanceProcessor 88749 MONITORING [nsx@6876 comp="nsx-manager" level="INFO" subcomp="monitoring"] Alarm for event mtu_check.global_router_mtu_too_big, 
 node ########-####-####-####-############, entity id  ########-####-####-####-############ source id proton_mtucheck_monitor does not exist , creating new alarm

Environment

VMware NSX

Cause

This alarm was initially was alerting to an MTU issue, which may have been fixed since the first time the alarm was produced. In this case, there can be instances where one or more of the NSX Managers still having a reference to the alarm within its internal cache. In this state, even an attempt to manually resolve the alarm will fail, as the monitoring framework will automatically create the alarm without actually clearing the stale state. 

Resolution

To resolve this issue, restart the proton service on each NSX Manager:

  1. Log into the NSX Manager via SSH using the root credentials
  2. Run the command /etc/init.d/proton restart
  3. Once the service has been restarted on all NSX Managers, log into the NSX UI and manually resolve the alarm
    • Home > Alarms > Ellipses (three small dots to the left of the alarm) > Resolve

If the alarm returns after the process above, please open a support case with VMware by Broadcom support and provide the following details:

  1. NSX Manager logs
  2. Time and date of the most recent alarm
  3. Screenshot of the exact alarm

For more details on opening support cases, please refer to Creating and managing Broadcom cases.