Launching soon: The world's first vendor agnostic bug scrubLearn more & join waitlist
OPERATIONAL DEFECT DATABASE
...
...
From NSX-T 3.2.0 version and onwards there is behavior change for Edge MP intent. If user directly updates some edge node settings on Edge CLI or Edge node vSphere configuration on VCenter, then these changes are not directly updated on Edge Node's MP intent. In such a case user will be alerted with edge node mismatch alarm. This alarm basically tells user that, some edge node configuration is directly changed on edge CLI OR on VCenter. Edge node "Configuration State" in NSX-T UI will also be updated with this Mismatch. There are 4 types of edge node mismatch alarms as mentioned below. Alarm 1: Edge Node Settings Mismatch Alarm will be raised when edge node settings parameters in Edge Node CLI and Edge Node MP intent are found to be different. If Any one of below Edge Node Settings field is changed directly through edge CLI, then this alarm will be raised. Edge node settings -> "Enable SSH""DNS Servers""Search domains""NTP servers""Host name""Syslog Servers""UPT_MODE" <<<< Added from Keeper Release 4.1.0 Onwards for realization failure. Alarm 2: Edge VM vSphere Settings Mismatch Alarm will be raised when edge node vSphere settings parameters on VCenter and Edge Node MP intent are found to be different. If user changes any one of below edge VM vSphere deployment configuration field through VCenter then this alarm will be raised. Edge VM vSphere settings -> "Display Name""Compute Id""Storage Id""Management Network Id""Data Networks Ids""Form Factor""CPU Reservation in shares""CPU Reservation in MHz""Memory Reservation percentage" Alarm 3: Edge Node Settings and vSphere Settings are changed Alarm will be raised when edge node vSphere settings parameters on VCenter and edge node CLI parameters are found to be different than Edge Node MP intent. If user changes edge fields from both "Edge node settings" and "Edge VM vSphere settings" directly on edge CLI and VCenter respectively, then this alarm will be raised. Alarm 4: Edge vSphere Location Mismatch Alarm will be raised when user uses the vMotion to move Edge VMs. The datastore ("Storage Id"), compute cluster id ("Compute Id") parameters of Edge Node in vSphere will be changed when Edge VM is moved. Thus, when these edge node vSphere settings parameters on VCenter and Edge Node MP intent are found to be different, then alarm will be raised. Thus, if only any (or all) of below fields is changed then this alarm is raised. "Compute Id""Storage Id" If other than "Compute Id" and "Storage Id" some more "Edge VM vSphere settings" OR "Edge node settings" fields are changed, then "Edge VM vSphere Settings Mismatch" Alarm or "Edge Node Settings and vSphere Settings are changed" Alarm will be raised based on fields that are changed. How Mismatch Alarm Looks Like in NSX-T UI Edge Mismatch Alarm is displayed in System → Nodes → Edge Transport Nodes page as below → Edge Mismatch Alarm is also displayed in NSX-T UI Home page.
Steps To Resolve Edge Mismatch Alarms There are 2 ways to resolve edge mismatch alarms. Approach 1 to resolve alarm → Select Mismatch in edge node Configuration State as shown below. This will open a pop-up window as shown below. Select "vSphere/Edge Appliance" as a Source and click Resolve. This will resolve mismatch alarm. This operation basically fires edge node refresh API internally. Edge node refresh API updates edge node MP intent with latest data from edge node and resolves mismatch alarm.In this way of resolving alarm, actual edge node configuration (on CLI OR on VCenter) gets copied to Edge Node MP intent. Approach 2 to resolve alarm → Select Mismatch in edge node Configuration State as shown below → This will open a pop-up window as shown below → Select "NSX" as a Source and click Resolve. This will resolve mismatch alarm. This operation basically fires edge node update API internally. This API realizes edge node configuration on MP to edge node. This way mismatch alarm gets resolved.In this way of resolving alarm, Edge Node MP intent data gets realized to edge node. Scenario when there is mismatch in Compute Id/Storage Id → In case there is mismatch in Compute Id/Storage Id field, then on selecting "NSX" as source(i.e. Approach 2) edge node will be redeployed and this will cause traffic disruption. A warning message about traffic disruption will also be displayed as shown in below image → So, in this case, it is preferable to select "vSphere/Edge Appliance" as source(i.e. Approach 1) to resolve alarm, when there is mismatch in Compute Id/Storage Id field. Certain Corner cases → In certain corner cases alarm might not get resolved with above mentioned Approach 1 or Approach 2. In such cases follow below mentioned steps to resolve alarm manually.Case 1: Alarm is not resolved from Edge-MP vertical side. Check output of edge transport node state API → GET https://<manager-ip>/api/v1/transport-nodes/<edge-uuid>/stateIf "node_deployment_state" in edge transport node state API is mismatch, similar to as shown below. Then mismatch is still present → { "node_deployment_state": { "state": "EDGE_VM_VSPHERE_SETTINGS_MISMATCH_RESOLVE", "details": [ { "sub_system_id": "EDGE_TRANSPORT_NODE_MISMATCH_ALARMS", "state": "EDGE_VM_VSPHERE_SETTINGS_MISMATCH_RESOLVE", "failure_message": " configuration on vSphere : {\"CPU Reservation in shares\":\"NORMAL_PRIORITY\",\"Storage Id\":\"datastore-14\"}, intent vSphere configuration :{\"CPU Reservation in shares\":\"LOW_PRIORITY\",\"Storage Id\":\"datastore-50\"}", "failure_code": 16087 } ], "failure_message": "", "failure_code": 0 } } To resolve this mismatch fire refresh api(Refresh api does not need any request body) → POST https://<manager-ip>/api/v1/transport-nodes/<edge-uuid?action=refresh_node_configuration&resource_type=EdgeNodeNow, check again the output of edge transport node state api →GET https://<manager-ip>/api/v1/transport-nodes/<edge-uuid>/state If in this edge transport node state api, "node_deployment_state" for edge transport node is NODE_READY then then we can say mismatch is resolved from Edge-MP vertical side → { "node_deployment_state": { "state": "NODE_READY", "details": [] } } If "node_deployment_state" is still a mismatch, then there is really a mismatch between edge node MP intent and realized edge node configuration on CLI or VCenter. Case 2: Alarm is resolved from Edge-MP vertical side, but not resolved from Alarm Framework side. Check output of edge transport node state api → GET https://<manager-ip>/api/v1/transport-nodes/<edge-uuid>/stateIn this API output, "node_deployment_state" for edge transport node is NODE_READY. This means Edge-MP vertical resolved mismatch. → { "node_deployment_state": { "state": "NODE_READY", "details": [] } } Now check if mismatch alarm is still OPEN using alarm API → GET https://<manager-ip>/api/v1/alarms?status=OPENif this alarm API shows our mismatch alarm as OPEN. Then we will need to resolve this mismatch alarm manually. Because Edge-MP vertical side resolved mismatch, but Alarm Framework failed to resolve alarm.To resolve alarm manually, Select Mismatch Alarm from "Open Alarms" → then select "Actions" → and finally "Acknowledge" the alarm . This can be done from System → Fabric → Nodes page OR from Home → Alarms page , as shown in below images →
Note: "Edge Node MP intent" term refers to Edge Transport Node configuration data which is present in NSX-T Manager Database. We get same data as payload when we do a GET call for this edge transport node e.g. GET https://<manager-ip>/api/v1/transport-nodes/<edge-tn-id> From NSX 4.1.1, UPT mode may be edited even when Edge maintenance mode is enabled. As part of UPT mode realization, maintenance mode is toggled on the Edge VM. If user edits UPT mode on edge with maintenance mode enabled, then user must disable maintenance mode, before UPT realization completes. Mismatch alarm is raised after partial UPT realization when edge has maintenance mode enabled. The alarm will resolve using NSX Value, when User disables maintenance mode on edge.