Configuration notifications that are grouped will have this OID prefix.

This notification is sent when the sending out of Snmp traps is disabled.
This would most likely be the last Snmp trap the snmp manager receives.
You may some times not receive it in case of high volume of traps. In those
cases you can rely on the heartbeat traps not being sent out.
Action required: None. If the sending of Snmp traps is enabled a warmStart
trap is received.
Frequency of traps: Once, whenever the sending snmp traps is disabled.

This notification is sent when the snmp manager configuration has been
updated. The event message will carry the semicolon separated new snmp
managers' details.
Action required: None
Frequency of traps: Once, whenever the Snmp manager configuration is updated.

Service Composer encountered an error while attempting to
enforce rules on this Policy.
Action required: Administrator needs to check the rules on the given Policy
for any errors, as reported in the message. After fixing the rules in the
Policy, user would need to resolve the alarm to bring this Policy back in
sync. Policy's alarm can either be resolved from NSX Manager Service Composer
UI or by using alarms API.
Frequency of traps: This trap is generated only once, if an error is
encountered while enforcing the Policy.

Service Composer encountered an error reordering sections to reflect
Policy's precedence change. This generally happens if there are Alarms on any
other Policy.
Action required: Administrator needs to check Policies and/or Firewall
sections for any errors, as reported in the message. After fixing the errors,
user would need to resolve the alarm. Alarm can either be resolved from
NSX Manager Service Composer UI or by using alarms API.
Frequency of traps: This trap is generated only once if a failure is
encountered while reordering section to reflect precedence change.

Service Composer encountered an error while initializing auto save drafts
setting.
Action required: Administrator needs to check Policies and/or Firewall
sections for any errors, as reported in the message. After fixing the errors,
user would need to resolve the alarm. Alarm can either be resolved from
NSX Manager Service Composer UI or by using alarms API.
Frequency of traps: This trap is generated only once if a failure is
encountered while initializing auto save drafts setting.

A Policy got deleted as a result of the internal
SecurityGroup, over which the Policy was created, got deleted.
Frequency of traps: This event is generated once every time
any internal SecurityGroup, that is being consumed by a policy,
gets deleted.

Service Composer encountered an error while attempting to
enforce Firewall rules on this Policy. Firewall related changes on this
Policy will not take effect, until this alarm is resolved.
Action required: Administrator needs to check the rules on the given Policy
for any errors, as reported in the message. After fixing the rules in the
Policy, user would need to resolve the alarm to bring this Policy back in
sync. Policy's alarm can either be resolved from NSX Manager Service Composer
UI or by using alarms API.
Frequency of traps: This trap is generated only once, if an error is
encountered while enforcing the Policy.

Service Composer encountered an error while attempting to
enforce Network Introspection rules on this Policy. Network Introspection
related changes on this Policy will not take effect, until this alarm is
resolved.
Action required: Administrator needs to check the rules on the given Policy
for any errors, as reported in the message. After fixing the rules in the
Policy, user would need to resolve the alarm to bring this Policy back in
sync. Policy's alarm can either be resolved from NSX Manager Service Composer
UI or by using alarms API.
Frequency of traps: This trap is generated only once, if an error is
encountered while enforcing the Policy.

Service Composer encountered an error while attempting to
enforce Guest Introspection rules on this Policy. Guest Introspection
related changes on this Policy will not take effect, until this alarm
is resolved.
Action required: Administrator needs to check the rules on the given Policy
for any errors, as reported in the message. After fixing the rules in the
Policy, user would need to resolve the alarm to bring this Policy back in
sync. Policy's alarm can either be resolved from NSX Manager Service Composer
UI or by using alarms API.
Frequency of traps: This trap is generated only once, if an error is
encountered while enforcing the Policy.

Service Composer encountered an error synchronizing Policies. Any changes on
Service Composer will not be pushed to Firewall/Network Introspection
Services, until this alarm is resolved.
Action required: Administrator needs to check Policies and/or Firewall
sections for any errors, as reported in the message. After fixing the errors,
user would need to resolve the alarm to bring Service Composer back in sync.
Alarm can either be resolved from NSX Manager Service Composer UI or by using
alarms API.
Frequency of traps: This trap is generated only once, whenever an error is
encountered.

Service Composer encountered an error while synchronizing Policies on
reboot.
Action required: Administrator needs to check Policies and/or Firewall config
for any errors, as reported in the message. After fixing the errors, user
would need to resolve the alarm to bring Service Composer back in sync. Alarm
can either be resolved from NSX Manager Service Composer UI or by using
alarms API.
Frequency of traps: This trap is generated only once on NSX Manager reboot,
if an error is encountered.

Service Composer went out of sync due to rollback of drafts from Firewall.
Any changes on Service Composer will not be pushed to Firewall/Network
Introspection Services, until this alarm is resolved.
Action required: Administrator needs to resolve the alarm to bring Service
Composer back in sync. Alarm can either be resolved from NSX Manager Service
Composer UI or by using alarms API.
Frequency of traps: This trap is generated only once, whenever Firewall
config is reverted to an older version of drafts.

Service Composer encountered an error while deleting the section
corresponding to the Policy. This generally happens if third party(NetX)
service's Manager is not reachable.
Action required: Administrator needs to check connectivity with third
party(NetX) service's Manager. Once the connectivity is restored, user would
need to resolve the alarm. Alarm can either be resolved from Service Composer
UI or by using alarms API.
Frequency of traps: This trap is generated only once if a failure is
encountered while deleting a Policy's section on Policy deletion.

Service VMs are deployed per ESX host, to provide functionality like
guest introspection and McAfee/Trend virus checking in VMs on the host.
An issue is detected with the state of the deployed Service VM. Follow
instructions in http://kb.vmware.com/kb/2125482 to analyze the logs
further. Warning: Resolving this alarm will delete the VM. After
deletion you will see a different alarm saying VM is deleted. If you
resolve same, it will reinstall the VM. If redeployment of the VM does
not fix the original issue, the original alarm will be added back
immediately.
Action required: Use resolve API to resolve the Alarm.
Frequency of traps: Once per host.

Service VMs are deployed per ESX host, to provide functionality like
guest introspection and McAfee/Trend virus checking in VMs on the host.
An issue is detected with the state of the deployed Service VM. Follow
instructions in http://kb.vmware.com/kb/2125482 to analyze the logs
further. Warning: Resolving this alarm will restart the VM. If the
root cause here is not solved, the same alarm will be added back
immediately.
Action required: Use resolve API to resolve the Alarm.
Frequency of traps: Once per host.

An issue is detected while marking agent as available. Kindly
check the logs. Resolving this alarm will attempt to mark the agent as
available.
Action required: Use resolve API to resolve the Alarm.
Frequency of traps: Once per host.

A VM has got added to the SecurityGroup.
Frequency of traps: Once for every VM getting added to any SecurityGroup.

A VM has got removed from the SecurityGroup.
Frequency of traps: Once for every VM getting removed from any
SecurityGroup.

A failure is encountered when doing full sync of universal
objects on a secondary NSX manager. IP address of the secondary NSX
manager is present in event's message variable.
Action required: Kindly check NSX manager logs on the secondary NSX
manager on which the full sync has failed.
Frequency of traps: This trap is generated once per NSX manager on which
full sync failure is seen.

Secondary NSX manager is unreachable.
Action required: Kindly check if NSX manager is running and is reachable
from primary NSX manager. IP address of the secondary NSX
manager is present in event's message variable.
Frequency of traps: This trap is generated once per NSX manager for which
connection issue is seen.

A failure is encountered when doing sync of universal object
on a secondary NSX manager. IP address of the secondary NSX
manager is present in event's message variable.
Action required: Kindly check NSX manager logs on the secondary NSX manager
on which the sync has failed.
Frequency of traps: This trap is generated once per universal object on
a NSX manager on which sync failure is seen.

Secondary NSX manager is no longer receiving periodic universal sync updates.
IP address of the NSX manager is present in event's message variable.
Action required: Kindly check NSX manager logs and universal configuration on
the primary NSX manager to check if the secondary NSX manager has got removed.
Frequency of traps: This trap is generated one every 4 hours if secondary NSX
manager has not received universal sync updates for more than 4 hours.

Secondary NSX manager has resumed receiving periodic universal sync updates.
Frequency of traps: This trap is generated whenever communication between
primary and secondary managers resumes.

Denotes that NSX manager server is up and in running state,
Informs clients of NSX Manager of the current state.
Action required: None
Frequency of traps: Once for every query

Registers NSX manager as a vCenter extenstion. This is
applicable when no other NSX Manager is registered with vCenter and the
current NSX manager is the one registering with vCenter.
Action required: None
Frequency of traps: Only once when the extension is registered for the
very first time.

Updates the vCenter extension registration with the new NSX
Manager. This is applicable when there already exists another NSX manager
that is registered as a vCenter extension and the current one overwrites
it.
Action required: None
Frequency of traps: Every time a NSX Manager registers as a vCenter
extension when there already exists another NSX manager registered with
vCenter

A notification generated when NSX Data Security scan started
on VirtualMachine.

A notification generated when NSX Data Security scan ended
on VirtualMachine.

Service Activity Monitoring will start collecting data.
Action required: None
Frequency of traps: Event is triggered when SAM data collection state is
toggled.

Service Activity Monitoring will stop collecting data.
Action required: SAM data collection can be enabled to start collectiing
data.
Frequency of traps: Event is triggered when SAM data collection state is
toggled

Service Activity Monitoring data stopped flowing from USVM
Action required: Check the following
   - USVM log to see if heartbeats are recieved and sent
   - is the USVM running
   - is the Mux - USVM connection healthy
   - is the USVM - RMQ connection healthy
   - does the VM have endpoint driver installed
Frequency of traps: Event is triggered when NSX Manager does not receives
SAM data from USVM

Service Activity Monitoring data resumes flowing from USVM
Action required: None
Frequency of traps: Event is triggered when SAM data is received from USVM.

USVM stopped sending heartbeats to management plane.
Action required: Connection to NSX Manager was lost. Check why the
Manager didn't send a heartbeat.
Frequency of traps: Event is triggered when NSX Manager does not receives
heartbeats from USVM

USVM will start sending heartbeats to management plane.
Action required: None
Frequency of traps: Event is triggered when NSX Manager receives
heartbeats from USVM

USVM sent a HELLO message to Mux
Action: None
Frequency of traps: Event is triggered when Epsec Mux receives HELLO
message from USVM during initial connection establishement.

A notification generated when NSX Manager upgraded
successfully.

Certificate with mentioned id has expired.
Action: Replace expired certificate. Please refer to NSX Administration and API guide for details on certificate related operations.
Frequency: This is triggered every day until expired certificate is replaced.

Certificate with mentioned id will expire on mentioned date.
Action: Replace expiring certificate. Please refer to NSX Administration and API guide for details on certificate related operations.
 Frequency: This is triggered every day until expiring certificate is replaced.

NSX Manager CPU usage is currently high.CPU usage is based on load across all cores.
Action: If NSX Manager is facing performance issue, please collect the technical
support logs for NSX Manager and the host, and contact VMware technical support.
Frequency: This is triggered whenever NSX Manager CPU is above high threshold for consecutive 5 intervals.
Default value of high threshold and interval are 80% and 1 minute respectively.

NSX Manager CPU usage is back to normal.CPU usage is based on load across all cores.
Action: None
Frequency: This is triggered whenever NSX Manager CPU is below high threshold after 1 interval from CPU being above high threshold.
Default value of high threshold and interval are 80% and 1 minute respectively.

A notification generated when NSX Manager restored
successfully.

The NSX Manager IP has been assigned to another machine
Action: None
Frequency: This is triggered whenever NSX Manager detects that its IP
address is being used by another machine in the same network

Virtual machine is marked as system resource
Action: None
Frequency: This is triggered whenever any virtual machine is marked as system
resource

The scale value(s) of the mentioned parameter(s) has crossed the supported scale limits
Action: Reduce the scale of the parameter(s) mentioned
Frequency: This is triggered every hour if any new parameters cross the supported scale limits

The scale value(s) of the mentioned parameter(s) has crossed set threshold scale value
Action: Reduce the scale of the parameter(s) mentioned
Frequency: This is triggered every hour if any new parameters cross the set threshold value

The scale value(s) of the mentioned parameter(s) is back to normal after being above the set threshold or the supported value
Action: No action required.
Frequency: This is triggered every hour if any new parameters return to normal after being above the set threshold or the supported value

The scale value(s) of the mentioned parameter(s) is not matching the recommended value
Action: Increase/Decrease number of objects  for the parameter(s) mentioned, to match with recommended value. Please refer NSX Administration guide.
Frequency: This is triggered every hour if any new parameters does not match the recommended value

Whenever user authentication fails for number of times that
user is blacklisted and further login attempts are disabled for that user
from given IP address for some time.
Action required: None
Frequency of traps: Whenever user authentication fails consecutively within
some time.

Whenever there is disconnectivity for default VCenter
Connection maintained by NSX.
Action required: Administrator needs to check the connectivity with vCenter
for network problems or any other reasons.

Whenever there is disconnectivity for default VCenter
Connection maintained by NSX.
Action required: Administrator needs to check the connectivity with
vCenter for network problems or any other reasons.

Whenever there is disconnection with SSO lookup service.
Action required: Please check the configuration for possible disconnection
reasons like Invalid Credentials, Time sync issues, Network connectivity
problems etc. Navigate to Appliance management Web UI in browser
(https:///) traverse to Manage vCenter Registration tab
and verify the configuration for SSO Lookupservice.
Frequency of traps: Once per disconnect event, default frequency to check
SSO connection state is 1 hour.

When we try to configure VC on a system where SSO is already configured,
we fetch the token to login to the VC using SSO. If it times out during
that, this trap is raised.
Action required: Try reconnecting to the SSO server and if the service remains
unresponsive, try restarting the NSX management service from the NSX appliance
management UI. Contact the SSO administrator if the issue persists.
Frequency of traps: Whenever we try to configure VC on a system where
SSO is already configured.

After user is blacklisted, after blacklist duration expires,
user is removed from blacklist.
Action required: None
Frequency of traps: Whenever blacklist duration expires for any user.

Whenever configuration of lookup service / SSO fails due to
various reasons like invalid credentials, invalid configuration, time sync
problem etc.
Action required: Check the event message and reconfigure lookup service
with correct details.
Frequency of traps: Once per failed configuration of lookup service.

Whenever user unconfigures lookup service.
Action required: None
Frequency of traps: Once per unconfiguration event of lookup service.

When role is assigned on NSX manager for vCenter user.
Action required: None
Frequency of traps: Once for each user who is assigned role.

When role is unassigned on NSX manager for vCenter user.
Action: None
Frequency of traps: Once for each user where role is removed.

When role is assigned on NSX manager for vCenter group.
Action required: None
Frequency of traps: Once for each group who is assigned role.

When role is unassigned on NSX manager for vCenter group.
Action required: None
Frequency of traps: Once for each group where role is removed.

Whenever Connection with vCenter starts failing due to
invalid credentials.
Action required: Reconfigure NSX Manager vCenter configuration with
correct credentials.

This event is triggered if one or more distributed virtual
port groups backing a certain Logical Switch were modified and/or removed.
Or if migration of Control plane mode for a Logical Switch/Transport
Zone failed.
Action required: (1) If the event was triggered due to
deletion/modification of backing distributed virtual port groups, then the
error will be visible on Logical Switch UI page. Resolve from there will
try and create missing distributed virtual port groups for the Logical
Switch. (2) If event was triggered due to failure of Control plan mode
migration, redo the migration for that Logical Switch or Transport Zone.
Frequency of traps: Event is triggered due to user actions as explained
in description.
Affects: Logical Switch network traffic.

A notification generated when VXLAN Controller has been removed due to
the connection cant be built, please check controller IP configuration
and deploy again.

NSX manager detected the connection between two controller
nodes is broken.
Action required: It is a warning event, users need to check the controller
cluster for the further steps. Check following KB 2127655 https://kb.vmware.com/selfservice/microsites/search.do?cmd=displayKC&docType=kc&externalId=2127655&sliceId=1&docTypeID=DT_KB_1_1&dialogID=40732913&stateId=0%200%2040754965 to see if issue matches.
Frequency of traps: Whenever the controller reports the issue.
Affects: Networking might get affected.

Host Certification information couldn't be sent to NSX
Controllers.
Action required: Ensure that NSX Controller cluster is in healthy state
before preparing a new Host. Invoke Controller Sync API to try and rectify
this error.
Frequency of traps: When a new host is prepared for NSX networking.
Affects: Newly prepared Host. Communication channel between Host and NSX
Controllers might have issues.

A notification generated when Controller cluster state is
now active. Controller Synchronization job is in progress.
Frequency of traps: Controller cluster becomes active again from a
previous inactive state.
Action required: User doesnt have to take any corrective action.
NSX will auto-sync the controllers.

VXLAN vmknic is missing or deleted from host.
Action required: Issue can be resolved from Logical Network
Preparation - VXLAN Transport UI section. Clicking on resolve will try to
rectify the issue.
Frequency of traps: First time NSX Manager finds that VXLAN vmknic is
missing or deleted from Host.
Affects: VXLAN Traffic to/from the mentioned Host will be affected.

NSX Manager will raise this event when connection between
either of the following component is established/re-established
(i) connection between NSX Manager and Host Firewall agent.
(ii) connection between NSX Manager and Control Plane Agent.
(iii) connection between Control Plane Agent to Controllers.
Action required: None
Frequency of traps: NSX Manager will raise this event when connection
between either of the following component is established/re-established
(i) connection between NSX Manager and Host Firewall agent.
(ii) connection between NSX Manager and Control Plane Agent
(iii) connection between Control Plane Agent to Controllers.

NSX manager detected one vxlan vmknic is missing on VC.
Action required: Check the host, if that vmknic is deleted, click on the
resolve button on UI, or call the remediate API (POST /api/2.0/vdn/config/host/{hostId}/vxlan/vteps?action=remediate)
to recreate the vxlan vmknic.
Frequency of traps: First time when vxlan vmknic is detected missing
(manually deleted by user or inventory report the incorrect information)
Affects:  The VXLAN traffic on that host may be interrupted.

NSX manager detected one vxlan vmknic that was marked as
missing has now reappeared on VC.
Action required: None
Frequency of traps: When that missing vmknic re-appears again.
Affects: The VXLAN traffic on that host may be resumed.

This event is triggered when either of the following
connections are detected down by NSX Manager:
(i) connection between NSX Manager and Host Firewall agent.
(ii) connection between NSX Manager and Control Plane Agent.
(iii) connection between Control Plane Agent to Controllers.
Action required:
(i) If NSX Manager to Host Firewall Agent connection is
down, check NSX Manager and Firewall Agent logs to get error details. You
can try Fabric Synchronize API to try and retificy this issue.
(ii) If NSX Manager to Control Plane Agent connection is down, please
check NSX Manager and Control Plane Agent logs to get the error detail,
check whether the Control Plane Agent process is down.
(iii) If Control Plane Agent to Controllers connection is down, please go
to UI Installation page to check the connection status for crossponding
Host.
Frequency of traps: When
(i) NSX Manager looses connection with Firewall agent on host or
(ii) NSX Manager losses connection with Control plane agent on host or
(iii) Control plane agent on Host looses connection with NSX Controllers.
Affects: VMs on that Host might get affected.

NSX manager detected one backing portgroup of a logical
switch is missing on VCenter.
Action required: Click on the resolve button on UI or call the API
(POST https:///api/2.0/vdn/virtualwires//backing?action=remediate)
to recreate that backing portgroup.
Frequency of traps: Whenever logical switch backing portgroup is missing
on VC.
Affects: VMs cannot be connected to this Logical Switch.

Logical Switch status has been marked good, most probably as
result of resolving any errors on it.
Action required: None
Frequency of traps: Event is triggered when user resolves the Logical
Switch error and as a result missing backing distributed virtual port
groups are recreated.

NSX manager detected one backing portgroup of a logical
switch that was missing reappears on VC.
Action required: None
Frequency of traps: Whenever user triggered remediate API on Logical
Switch which has missing backing portgroup.

NSX manager detected the Managed Objectid of one backing
portgroup of a logical switch changed.
Action required: None
Frequnecy of traps: This typically happens when user restores a backup
of Logical Switch backing portgroup.

NSX manager detected some disk on a NSX Controller has high
latency.
Action required: Rectify the issue on specified device and controller.
Frequency of traps: First time NSX detected this issue as reported by
Controller. When this issue gets resolved another Informational event will
be raised by NSX Manager indicating the same.
Affects: NSX Controller.

NSX manager detected the disk high latency alert on a some
disk on a NSX Controller has been resolved.
Frequency of traps: First time NSX detected, previously raised disk
latency issue has been resolved.

NSX manager detected a Controller Virtual Machine is powered
off from vCenter.
Action required: Click on the 'Resolve' button on Controller page on UI or
call the API (POST https:///api/2.0/vdn/controller/{controllerId}?action=remediate)
to power on the Controller Virtual Machine.
Frequency of traps: This event wil be raised when controller Virtual
Machine is powered off from vCenter.
Affects: Controller cluster status might go to disconnected if a controller
Virtual Machine is powered off. Any operation that requires an active
Controller Cluster may be affected.

NSX manager detected a Controller Virtual Machine is deleted
from vCenter.
Action required: Click on the Resolve button on Controller page on UI or
call the API (POST https:///api/2.0/vdn/controller/{controllerId}?action=remediate)
to clean up NSX manager's database state.
Frequency of traps: This event will be raised when Controller Virtual
Machine is deleted from vCenter.
Affects: Controller cluster status might go to disconnected if a controller
Virtual Machine is powered off. Any operation that requires an active
Controller Cluster may be affected.

NSX manager detected the VXLAN configuration is not set on
the host (would-block issue). And this event indicates NSX Manager tried
to rectify this issue by resending the VXLAN configuration on Host.
Action required: See KB 2107951 https://kb.vmware.com/selfservice/microsites/search.do?cmd=displayKC&docType=kc&externalId=2107951&sliceId=1&docTypeID=DT_KB_1_1&dialogID=40732862&stateId=0%200%2040754197
for more information.
Frequency of traps: This event will generate when host preparation task is
triggered for a host and Host encounters would-block issue.
Affects: It is a notification, no specific guide for the next step.

NSX Manager will raise this event when a VXLAN portgroup is deleted from
a switch.
ACTION: User does not have to take any action. This is just a notification
for the user.
FREQUENCY: This event is generated a single time when the VXLAN portgroup
is deleted from the switch.
AFFECTS: The VXLAN traffic on the switch is interrupted.

DESCRIPTION: NSX Manager will raise this event when the teaming policies of
a VDS and it's associated VXLAN portgroup are not the same.
ACTION: Set the VXLAN portgroup teaming policy back to the original value. 
Below is the workaround to correctly update the teaming policy in a deployed
cluster: The supported method to correct teaming policy inconsistencies is
to create and prepare a new NSX cluster with the required teaming policy,
and to migrate ESXi hosts to that cluster. Changing the teaming policy in
the manager DB by some other means only applies to newly created virtual
wires after the DB change is made.
FREQUENCY: This event will generate whenever the VXLAN portgroup teaming
policy is changed to something different than the VDS teaming policy.
AFFECTS: The VXLAN traffic on the switch may be interrupted.

DESCRIPTION: NSX Manager raises this event when the Controller VM is
Disconnected ie the controller can not reached from the NSX Manager.
ACTION: Make sure the IP is assigned to the controller VM and it is
reachable form the NSX Manager.
FREQUENCY: The event occurs when the Controller VM is powered off or not responding.
Minimum 40 secs between two disconnecet events.
AFFECTS: Controller cluster status might go to disconnected if a controller
Virtual Machine is disconnected. Any operation that requires an active
Controller Cluster may be affected.

Failed to configure vmknic as a VTEP, VXLAN traffic through
this interface will be dropped until this is resolved.
Action required: Check the host's vmkernel.log for more details.
Frequency of traps: Every time a VTEP vmknic tries to connect to it's
Distributed Virtual Port.
Affects: VXLAN traffic on the affected Host.

DESCRIPTION: NSX Manager will raise this informational event when the
controller VM is connected to controller cluster.
ACTION: No action to be taken.
FREQUENCY: Event occurs as controller is connected to controller-cluster.
Minimum 40 secs between two connecet events.
AFFECTS: None.

DESCRIPTION: NSX manager detected a Controller Virtual Machine is powered on from vCenter.
ACTION: None.
FREQUENCY: This event occurs when Controller Virtual Machine is powered On.
AFFECTS: Controller cluster status might go to disconnected if a controller Virtual Machine
is powered off. Any operation that requires an active Controller Cluster may be affected.

DESCRIPTION: NSX manager receives a notification from the host informing MAC mismatch occurred.
ACTION: Contact the administrator to take following action:
         (1) Look for VMs that caused this issue at hosts.
         (2) If VMs are rouge, shut dowm these VMs.
FREQUENCY: Event is triggerred as MAC mismatch occurs at switchport on the hosts.
AFFECTS: Identify the VMs causing this issue.

Failed to configure VXLAN on the Distributed Virtual Port,
the port will be disconnected.
Action required: Check the host's vmkernel.log for more details.
Frequency of traps: Every time a VXLAN vNic tries to connect to it's
Distributed Virtual Port on the host.
Affects: VXLAN traffic on the affected Host.

VXLAN configuration was received for a Distributed Virtual
Port, but the host has not yet enabled VXLAN on the vSphere Distributed
Switch. VXLAN ports on affected Host will fail to connect until resolved.
Action required: See KB 2107951 (https://kb.vmware.com/selfservice/microsites/search.do?cmd=displayKC&docType=kc&externalId=2107951&sliceId=1&docTypeID=DT_KB_1_1&dialogID=40732862&stateId=0%200%2040754197)
Frequency of traps: Every time any VXLAN related port (vNic or vmknic)
tries to connect to it's Distributed Virtual Port on the host.
Affects: VXLAN Traffic on that Host.

VTEP interface was unable to join the specified multicast
address, the VTEP will be unable to receive some traffic from other hosts
until this is resolved. The host will periodically retry joining the group
until it is successful.
Action required: Check the host's vmkernel.log for more details.
Frequency of traps: NSX retries joining failed mcast groups every
5 seconds.
Affects: Logical Switch associated with problem VTEP interface won't work
properly.

The IP address of a VTEP vmknic has changed.
Action required: None.
Frequency of traps: Every time a VTEP IP changes

VTEP vmknic does not have a valid IP address assigned, all
VXLAN traffic through this vmknic will be dropped.
Action required: Verify the IP configuration for the interface, and the
DHCP server if DHCP is used.
Frequency of traps: Once per VTEP loosing it's IP address.

NSX packages where not installed prior to DVS configuration
for VXLAN. All VXLAN ports will fail to connect until resolved.
Action required: See KB 2107951 https://kb.vmware.com/selfservice/microsites/search.do?cmd=displayKC&docType=kc&externalId=2107951&sliceId=1&docTypeID=DT_KB_1_1&dialogID=40732862&stateId=0%200%2040754197
Frequency of traps: Once per setting of the com.vmware.netoverlay.layer0=vxlan
opaque property or whenver the host is configured for vxlan or Host
reconnects to VCEnter and host has some problem.
Affects: VXLAN Traffic for that Host will be affected.

DESCRIPTION: This event is triggered if the security log on domain controller event log server is full.
ACTION: See article regarding the issue : https://support.microsoft.com/en-us/kb/867860
        Contact Domain Administrator to take one of the following actions:
        (1). Inclease the size of security log.
        (2). Clear the security log.
        (3). Archive the security log.
FREQUENCY: Event is triggered due to event log size reaches its limit.
AFFECTS: Identity firewall stops functioning.

Started flow analysis on Application Rule Manager session.
Action required: None
Frequency of traps:This trap is sent once for each session on which analysis has started

Flow analysis failed on Application Rule Manager session.
Contextual data provided with this event may indicate the cause of this failure.
Action required: Start a new monitoring session for the applcation and try analyzing flows again.
On repeated failure, collect ESX & NSX Manager tech support bundle and open SR with Vmware tech support.
Frequency of traps:This trap is sent once for each session on which analysis has failed

Completed flow analysis on Application Rule Manager session.
Action required: None
Frequency of traps:This trap is sent once for each session on which analysis has completed

NSX Manager failed to enforce DFW. VMs on this host may not be protected by the DFW.  Contextual data provided with this event may indicate the cause of this failure.
This could happen if the VIB version mismatches on the NSX Manager and ESX host. This may happen during an upgrade. Please collect ESX and NSX Manager tech support bundle and open a SR with Vmware techsupport. See http://kb.vmware.com/kb/2074678 and http://kb.vmware.com/kb/1010705

Flow missed.
Contextual data provided with this event may indicate the cause of this failure.
Collect error logs (vmkernel.log) when firewall configuration was applied to the vnic. Verify that vsip kernel heaps have enough free memory and vsfwd memory consumption is within resource limits. Check VSFWD logs. See kb.vmware.com/kb/2125437.
If the issue persists, please collect ESX and NSX Manager tech support bundle and open a SR with Vmware techsupport. See http://kb.vmware.com/kb/2074678 and
http://kb.vmware.com/kb/1010705

Failed to receive, parse or Update the spoofguard configuration.
Contextual data provided with this event may indicate the cause of this failure.
Verify that the host in question was properly prepared by NSX Manager.
Collect error logs (vmkernel.log) when the spoofguard configuration was applied to the host. For Sync the firewall configuration . See kb.vmware.com/kb/2125437.

Failed to apply spoofguard to the vnic.
Contextual data provided with this event may indicate the cause of this failure.
Verify that vsip kernel heaps have enough free memory.
Please collect ESX and NSX Manager tech support bundle and open a SR with Vmware techsupport. See http://kb.vmware.com/kb/2074678 and
http://kb.vmware.com/kb/1010705

Enabled spoofguard for vnic.
Action required: None

Failed to disable spoofguard on the vnic.
Please collect ESX and NSX Manager tech support bundle and open a SR with Vmware techsupport. See http://kb.vmware.com/kb/2074678 and
http://kb.vmware.com/kb/1010705

Disabled spoofguard for vnic.
Action required: None

A notification generated when legacy application service VM
deletion failed.

vsfwd CPU usage threshold was exceeded.
Reduce the amount of traffic of VMs on the host in question.

vsfwd heap memory threshold exceeded for the specified heap.
Reduce the number of  of VMs on the host in question, reduce the number of rules or containers in firewall config. Use appliedTo feature to limit the number of rules for the current cluster.

vsfwd Connectons Per Second (CPS) threshold exceeded for the specified vnic.
Reduce the amount of new connections of VMs on the host in question.

NSX Manager failed to enforce DFW configuration on a vnic. This particular VM may not be protected by the DFW. Contextual data provided with this event may indicate the cause of this failure.This could happen if the VIB version mismatches on the NSX Manager and ESX host. This may happen during an upgrade. Please collect ESX and NSX Manager tech support bundle and open a SR with Vmware techsupport. See http://kb.vmware.com/kb/2074678 and
http://kb.vmware.com/kb/1010705

NSX Manager waits for 2 minutes after publishing the Firewall configuration to each host in the cluster. If a host takes more than 2 minutes to process the data, it times out.
Please check the Host in question. See if VSFWD is functioning or not. Also use CLI commands to verify if the rule realization is working properly or not. See kb.vmware.com/kb/2125437.
Please collect ESX and NSX Manager tech support bundle and open a SR with Vmware techsupport. See http://kb.vmware.com/kb/2074678 and
http://kb.vmware.com/kb/1010705

NSX Manager waits for 2 minutes after publishing the Spoofguard configuration to each host in the cluster. If a host takes more than 2 minutes to process the data, it times out.
Please check the Host in question. See if VSFWD is functioning or not. Also use CLI commands to verify if the rule realization is working properly or not. See kb.vmware.com/kb/2125437.
Please collect ESX and NSX Manager tech support bundle and open a SR with Vmware techsupport. See http://kb.vmware.com/kb/2074678 and
http://kb.vmware.com/kb/1010705

Firewall Configuration Publishing has failed for a given cluster/host.
Please collect ESX and NSX Manager tech support bundle and open a SR with Vmware techsupport. See http://kb.vmware.com/kb/2074678 and
http://kb.vmware.com/kb/1010705

Publishing of container (IP/MAC/vNIC) update pdate failed for a given host/cluster object.
Please collect ESX and NSX Manager tech support bundle and open a SR with Vmware techsupport. See http://kb.vmware.com/kb/2074678 and
http://kb.vmware.com/kb/1010705

The publishing of the spoofguard updates on this host has failed. Please collect ESX and NSX Manager tech support bundle and open a SR with Vmware techsupport. See http://kb.vmware.com/kb/2074678 and
http://kb.vmware.com/kb/1010705

The publishing of the exclude list or updates to the exclude list on this host has failed. Please collect ESX and NSX Manager tech support bundle and open a SR with Vmware techsupport. See http://kb.vmware.com/kb/2074678 and
http://kb.vmware.com/kb/1010705

Deletion of the object referenced in firewall rules.
Action required: Go to the NSX manager DFW UI. All the invalid reference
are marked invalid on the UI as well. Please remove the orphaned referenced
and update the firewall rules.

Host-level force synchronization has failed. Please collect ESX and NSX Manager tech support bundle and open a SR with Vmware techsupport. See http://kb.vmware.com/kb/2074678 and
http://kb.vmware.com/kb/1010705

Force Sync operation for host succeeded.
Action required: None

The Distributed Firewall was successfully Installed on the host.

Successfully updated filter config.
Action required: None

The Distributed Firewall Installation has failed. Please collect ESX and NSX Manager tech support bundle and open a SR with Vmware techsupport. See http://kb.vmware.com/kb/2074678 and
http://kb.vmware.com/kb/1010705

The Distributed Firewall has been installed at the request of a user.

The Distributed Firewall has been uninstalled at the request of a user.

The Distributed Firewall has been disabeld on the cluster at the request of a user.

Force Sync operation for the cluster has failed.
Use CLI commands to look at the logs and verify if any error messages appeared during the operation. See kb.vmware.com/kb/2125437.
Please collect ESX and NSX Manager tech support bundle and open a SR with Vmware techsupport. See http://kb.vmware.com/kb/2074678 and
http://kb.vmware.com/kb/1010705

Force Sync operation for cluster succeeded.
Action required: None

vsfwd process started on host.
Action required: None

Failure to apply all the rule section configuration. Contextual data provided with this event may indicate the cause of this failure.
Collect error logs (vmkernel.log) when firewall configuration was applied to the vnic. Verify that vsip kernel heaps have enough free memory. Check VSFWD logs. See kb.vmware.com/kb/2125437 .
If the issue persists, please collect ESX and NSX Manager tech support bundle and open a SR with Vmware techsupport. See http://kb.vmware.com/kb/2074678 and http://kb.vmware.com/kb/653.

Successfully applied all rule section config.
Action required: None.

Failure to apply the container configuration. Contextual data provided with this event may indicate the cause of this failure.
Collect error logs (vmkernel.log) when firewall configuration was applied to the vnic. Verify that vsip kernel heaps have enough free memory. Check VSFWD logs. See kb.vmware.com/kb/2125437 .
If the issue persists, please collect ESX and NSX Manager tech support bundle and open a SR with Vmware techsupport. See http://kb.vmware.com/kb/2074678 and http://kb.vmware.com/kb/653.

Filter created. DFW is enforced in the datapath for the
vnic.
Action required: None

Failure to apply all container configuration. Contextual data provided with this event may indicate the cause of this failure.
Collect error logs (vmkernel.log) when firewall configuration was applied to the vnic. Verify that vsip kernel heaps have enough free memory. Check VSFWD logs. See kb.vmware.com/kb/2125437 .
If the issue persists, please collect ESX and NSX Manager tech support bundle and open a SR with Vmware techsupport. See http://kb.vmware.com/kb/2074678 and http://kb.vmware.com/kb/653.

Successfully applied all container config to all vnics.
Action required: None.

Failed to apply all spoofguard to the vnics.
Contextual data provided with this event may indicate the cause of this failure.
Verify that vsip kernel heaps have enough free memory.
Please collect ESX and NSX Manager tech support bundle and open a SR with Vmware techsupport. See http://kb.vmware.com/kb/2074678 and
http://kb.vmware.com/kb/653.

Applied all spoofguard for vnics.
Action required: None.

Firewall session timer timeout configuration parse/update failed. Timeout values are unchanged. Contextual data provided with this event may indicate the cause of this failure. Collect error logs (vsfwd.log) when the host received firewall config. Force sync firewall config using ForceSync API/UI. See kb.vmware.com/kb/2125437 .
If the issue persists, please collect ESX and NSX Manager tech support bundle and open a SR with Vmware techsupport. See http://kb.vmware.com/kb/2074678 and http://kb.vmware.com/kb/653.

Firewall session timer timeout configuration apply failed. Certain timeout values are unchanged. Contextual data provided with this event may indicate the cause of this failure. Collect error logs (vsfwd.log) when the host received firewall config. Force sync firewall config using ForceSync API/UI. See kb.vmware.com/kb/2125437 .
If the issue persists, please collect ESX and NSX Manager tech support bundle and open a SR with Vmware techsupport. See http://kb.vmware.com/kb/2074678 and http://kb.vmware.com/kb/653.

Applied session timeout values for a vnic.
Action required: None.

Failed to apply all firewall session timer timeout configuration. Some timeout values are unchanged. Contextual data provided with this event may indicate the cause of this failure. Collect error logs (vsfwd.log) when the host received firewall config. Force sync firewall config using ForceSync API/UI. See kb.vmware.com/kb/2125437 .
If the issue persists, please collect ESX and NSX Manager tech support bundle and open a SR with Vmware techsupport. See http://kb.vmware.com/kb/2074678 and http://kb.vmware.com/kb/653.

Applied session timeout values for all vnics.
Action required: None.

Successfully applied container config to all vnics.
Action required: None.

Filter deleted. DFW is removed from the vnic.
Action required: None

vsfwd maximum concurrent connections threshold was exceeded for the specified vnic.
Reduce the amount of traffic on the vnic in question.

vsfwd memory utilization threshold was exceeded for the specified process.
Reduce the number of rules or containers in firewall config. If persists, there may be memory leaks in the process so restarting it may be necessary.

vsfwd CPU usage is back to below threshold level.
Action required: None.

vsfwd heap memory usage is back to below threshold level for the specified heap.
Action required: None.

vsfwd Connectons Per Second (CPS) is back to below threshold level for the specified vnic.
Action required: None.

vsfwd maximum concurrent connections is back to below threshold level for the specified vnic.
Action required: None.

vsfwd memory utilization is back to below threshold level for the specified process.
Action required: None.

Successfully applied all threshold config.
Action required: None.

Firewall threshold configuration apply failed. Certain threshold values are unchanged. Contextual data provided with this event may indicate the cause of this failure. Collect error logs (vsfwd.log) when the host received firewall config. Force sync firewall config using ForceSync API/UI. See kb.vmware.com/kb/2125437 .
If the issue persists, please collect ESX and NSX Manager tech support bundle and open a SR with Vmware techsupport. See http://kb.vmware.com/kb/2074678 and http://kb.vmware.com/kb/653.

Whenever an IP address 0.0.0.0 or 0.0.0.0/32 is configured as IPSet.
KB article: https://ikb.vmware.com/kb/53157
Action: Information-only event. No action required. Workaround to this issue documented in KB article.

Firewall rule Configuration between the NSX Manager and the host is not in sync. Contextual data provided with this event may indicate the cause of this failure. Verify that the host in question was properly prepared by NSX Manager. Collect error logs (vsfwd.log) when the host received firewall config. Force sync firewall config using ForceSync API/UI. See kb.vmware.com/kb/2125437 .
          
If the issue persists, please collect ESX and NSX Manager tech support bundle and open a SR with Vmware techsupport. See http://kb.vmware.com/kb/2074678 and
http://kb.vmware.com/kb/1010705

Failed to apply Distributed Firewall configuration.
Contextual data provided with this event may indicate the cause of this failure.
Collect error logs (vmkernel.log) when the firewall configuration was applied to the vnic. vsip kernel heaps may not have enough free memory. Check VSFWD logs . See kb.vmware.com/kb/2125437.
          
If the issue persists, please collect the ESX and NSX Manager tech support bundle and open a SR with Vmware techsupport.  See http://kb.vmware.com/kb/2074678 and
http://kb.vmware.com/kb/1010705

Applied firewall config. Key value will have context info
like generation number and also other debugging info.
Action required: None

Failed receive, parse or update the container configuration. Contextual data provided with this event may indicate the cause of this failure.
Collect error logs (vmkernel.log) when firewall configuration was applied to the vnic. Verify that vsip kernel heaps have enough free memory. Check VSFWD logs. See kb.vmware.com/kb/2125437 .
If the issue persists, please collect ESX and NSX Manager tech support bundle and open a SR with Vmware techsupport. See http://kb.vmware.com/kb/2074678 and
http://kb.vmware.com/kb/1010705

None of the Edge VMs found in serving state. There is a
possibility of network disruption.
Action required: System auto recovers from this state today. Event should
be followed by traps with event code 30202 or 30203

A notification generated when Edge Gateway is upgraded
to 5.1.x.
Action required: None

A notification generated when Edge licensing changed on
vCenter Server.
Action required: None

A notification generated when Edge appliance is moved in the vCenter
inventory.

A notification generated when Edge appliance not found in
the vCenter inventory.
Action required: If VM is accidentally deleted, redeploy edge.

A notification generated when Edge VM is not responding to
health check.
Action required: Communicaiton issues between manager and edge. Log
analysis required to root cause issue.

A notification generated when none of the Edge VMs are found
in serving state. There is a possibility of network disruption.
Action required: Commnunicaiton issues between manager and edge. Log
analysis required to root cause issue.

A notification generated when Edge Communication Agent is not
connected to vCenter Server.
Action required: Check VSM and VC connectivity. Try registering VSM to VC

A notification generated when Edge VM is discovered with
a different vmId.
Action required: None

A notification generated when Edge firewall rule is modified.
Action required: Revisit firewall rule and perform required updates

A notification generated when powering on NSX Edge appliance
violates a virtual machine anti-affinity rule.
Action required: Anti affinity rules removed from cluster. Both HA VM may
run on same host. Go to VC and please revisit anti affinity rules
on Cluster

Edge Gateway created.
Action required: None

A notification generated when NSX Edge HighAvailability is
enabled.
Action required: None

A notification generated when NSX Edge HighAvailability
is disabled.
Action required: None

A notification generated when NSX Edge Gateway has recovered
and now responding to health check.
Action required: None

A notification generated when NSX Edge VM has recovered
and now responding to health check.
Actione required: None

A notification generated when Edge Gateway is upgraded.
Action required: None

A notification generated when Edge VM health check is
disabled on consecutive critical vix errors. Please redeploy or force
sync vm to resume health check.
Action required: This points to environmental issues that lead to
repeated failure over vix. Log analysis needs to be done to identify
root cause. Post resoving issues force sync edge vm to resume health
check. Force sync and redeploy are disruptive operation.

A notification generated when Pre Publish has failed on Edge
VM.
Action required: Firewall rules might be out of sync. System auto recovers
but if problem persists then trigger force sync.

A notification generated when Edge VM was force synced.
Action required: None

A notification generated when Edge VM was booted.
Action required: None

A notification generated when Edge VM is in Bad State. Needs
a force sync.
Action required: Force sync required.

Edge VM in bad state. Needs a force sync.
Action required: System auto triggres force sync but if problem is
sustained then manual force sync should be triggered. For ESG force
sync is disruptive and will reboot edge VMs.

A notification generated when Edge VM CPU usage has
increased.
Action required: Spikes are normal but collect tech support logs for
further analysis if high CPU sustained for longer duration.

A notification generated when Edge VM Memory usage has
increased.
Action required: System recovers but collect tech support logs for further
analysis.

A notification generated when Edge VM process monitor detects
a process failure.
Action required: System recovers but collect tech support logs for further
analysis.

A notification generated when Edge VM system time is bad.
Action required: System recovers. Check NTP setting on hosts.

A notification generated when Edge VM system time sync up happens.
Action required: None

A notification generated when AESNI crypto engine is up.
Action required: None

A notification generated when AESNI crypto engine is down.
Action required: None

A notification generated when Edge VM is out of memory. The
Edge is rebooting in 3 seconds.
Action required: Collect tech support for further analysis.

A notification generated when Edge file system is read only.
Action required: Check datastore issues, once resolved force sync is
required.

A notification generated when Edge HighAvailability
communication channel is disconnected from peer node.
Action required: User will need to check network infrastructure
(virtual and physical) to look for any failures, specially on
the interfaces and the path configured for HA.

Failed to communicate with the Edge VM.
Action required: Need investigation depending upon comunication channel.
Log needs to be checked for VIX error code for futher action.

A notification generated when High Availability is disabled for NSX Edge.
The primary NSX Edge VM has its state transitioned from ACTIVE to SELF.
High Availability (HA) ensures that NSX Edge services are always available,
by deploying an additional Edge VM for failover. The primary NSX Edge VM is
the ACTIVE node and the secondary VM is the STANDBY node. Whenever the
ACTIVE VM is unreachable on account of VM powered off or network
connectivity issues, the STANDBY VM takes over the ACTIVE vm's role.
In the event NSX Edge High Availability is disabled, the STANDBY VM is
deleted and the ACTIVE VM continues to function with its ACTIVE state
transitioned to SELF.
Action required: None

A notification generated when High Availability switch over has happened
for NSX Edge. The secondary NSX Edge VM has its state transitioned from
STANDBY to ACTIVE. High Availability (HA) ensures that NSX Edge services
are always available, by deploying an additional Edge VM for failover.
The primary NSX Edge VM is the ACTIVE node and the secondary VM is the
STANDBY node. Whenever the ACTIVE VM is unreachable on account of VM
powered off or network connectivity issues, the STANDBY VM takes over the
ACTIVE vm's role.
Action required: None

A notification generated when High Availability switch over has happened
for NSX Edge. The primary NSX Edge VM has its state transitioned from
ACTIVE to STANDBY. High Availability (HA) ensures that NSX Edge services
are always available, by deploying an additional Edge VM for failover.
The primary NSX Edge VM is the ACTIVE node and the secondary VM is the
STANDBY node. Whenever the ACTIVE VM is unreachable on account of VM
powered off or network connectivity issues, the STANDBY VM takes over the
ACTIVE vm's role. When connectivity is re-established between the NSX Edge
VM's, one of the VM's state is transitioned from ACTIVE to STANDBY.
Action required: None

A notification generated when Edge process monitor detected
a process failure.
Action required: Collect tech support logs for further analysis.

A notification generated when LoadBalancer virtualServer/pool
is up.
Action required: None

A notification generated when LoadBalancer virtualServer/pool
is down.

A notification generated when LoadBalancer virtualServer/pool state is
wrong.

A notification generated when LoadBalancer pool changed to a warning
state.

A notification generated when IPsec Channel is up.
Action required: None

A notification generated when IPsec Channel is down.
Action required: Collect tech support logs for further analysis.

A notification generated when NSX Edge VM configuration is
changed.
Action required: None

A notification generated when IPsec Tunnel is up.
Action required: None

A notification generated when IPsec Tunnel is down.
Action required: Collect tech support logs for further analysis.

A notification generated when IPsec Channel status is
unknown.
Action required: Collect tech support logs for further analysis.

A notification generated when IPsec Tunnel status is unknown.
Action required: Collect tech support logs for further analysis.

A notification generated when Global Loadbalancer member
status is up.
Action required: None