Loading

×Sorry to interrupt
Uncaught ReferenceError: addCTracking is not defined
throws at https://kb.vmware.com/resource/KM_TealiumTrackingJS?v=0.5:100:1

Refresh

Cookie Preference Center

General Information on cookies

When you visit our website, we use cookies to ensure that we give you the best experience. This information does not usually directly identify you, but it can give you a more personalized web experience. Because we respect your right to privacy, you can choose not to allow some types of cookies by clicking on the different category headings to find out more and change your settings. However, blocking some types of cookies may impact your experience on the site and the services we are able to offer. Further information can be found in our

Cookie Policy.

Strictly Necessary

Strictly Necessary

Always Active

Strictly Necessary

Strictly necessary cookies are always enabled since they are essential for our website to function. They enable core functionality such as security, network management, and website accessibility. You can set your browser to block or alert you about these cookies, but this may affect how the website functions. For more information please visit www.aboutcookies.org or www.allaboutcookies.org.

Cookie Details‎

Performance

Performance

Performance

Performance cookies are used to analyze the user experience to improve our website by collecting and reporting information on how you use it. They allow us to know which pages are the most and least popular, see how visitors move around the site, optimize our website and make it easier to navigate.

Cookie Details‎

Please confirm your settings by refreshing the page.

Functional

Functional

Functional

Functional cookies help us keep track of your past browsing choices so we can improve usability and customize your experience. These cookies enable the website to remember your preferred settings, language preferences, location and other customizable elements such as font or text size. If you do not allow these cookies, then some or all of these services may not function properly.

Cookie Details‎

Advertising

Advertising

Advertising

Advertising cookies are used to send you relevant advertising and promotional information. They may be set through our site by third parties to build a profile of your interests and show you relevant advertisements on other sites. These cookies do not directly store personal information, but their function is based on uniquely identifying your browser and internet device.

Cookie Details‎

Advertising Cookies

Consent Leg.Interest

Select All Vendors

Select All Vendors

Select All Hosts

Select All

Clear Filters

Information storage and access

Apply

Confirm My Choices Reject All Allow All

My Subscriptions

Loading

Knowledge Base

VMs do not process firewall rules even though they are apart of the specified NSX Security Group. (56617)

Last Updated: 7/12/2018Categories: InformationalTotal Views: 2718Language:
English

Subscribe to get an email
newsletter with new updates

Please provide article feedback:

Details

Traffic is being blocked by the DFW when there are rules to allow traffic through the Firewall.

You see log messages in vsm.log simlar to:

WARN SimpleAsyncTaskExecutor-1AbstractMessageListenerContainer:431 - Execution of Rabbit message listenerfailed, and no ErrorHandler has been set.org.springframework.amqp.rabbit.listener.ListenerExecutionFailedException:
Listener threw exception

You find that there is no IP listed for the VM in the address set.

Get filter name:

# summarize-dvfilter | grep "<VMNAME>" -A 4
world 4311603 vmm0:<VMNAME> vcUuid:'50 04 a8 76 ee 27 f4 6a-52 16 d7 a9 45 ef 1a f0'
port 67109049 <VMNAME>.eth0
vNic slot 2
name: nic-4311603-eth0-vmware-sfw.2

Get Rule ID:

# vsipioctl getrules -f nic-1173309-eth0-vmware-sfw.2 | grep <Rule ID>
rule <Rule ID> at 1468 inout protocol any from addrset ip-securitygroup-15 to addrset ip-securitygroup-15 accept;

Get Ip in Address set:

# vsipioctl getaddrsets -f nic-4311603-eth0-vmware-sfw.2 -a ip-securitygroup-15 | grep <IPaddress>
#

If no output is seen then there is no ip for that vm in this specific address set.

​You see log messages on NSX Manager for firewall updates, but you never see the final message that the update completed successfully.

Start of task:

2018-05-22 11:37:27.626 CDT INFO TaskFrameworkExecutor-18 NotificationProcessor:240 - Setting rule update for domain-c7003 , update number 6 , generation number 1527007047480, object generation number 1527007047480.
2018-05-22 11:37:27.638 CDT INFO TaskFrameworkExecutor-18 NotificationProcessor:240 - Setting rule update for domain-c93544 , update number 4 , generation number 1527007047480, object generation number 1527007047480.

End of task:

2018-05-22 08:36:25.056 CDT INFO TaskFrameworkExecutor-8 NotificationProcessor:417 - Processing Context domain-c7003 : 1 rule updates, 3/4 container updates, 0 spoofguard updates.
2018-05-22 08:36:25.092 CDT INFO TaskFrameworkExecutor-23 NotificationProcessor:417 - Processing Context domain-c93544 : 1 rule updates, 3/4 container updates, 0 spoofguard updates.​

Solution

Firewall Publish Section API is invoked (by either Service Composer, DFW UI or REST API)
This API internally calls into SimpleTaskManager, which creates a new Job in the database for each cluster-id which needs rule update. Then the cache is updated for cluster-id to job-id mappings.

Note that at this point, the job object is just created in the database and it will not start execution until this transaction is committed to the database. After transaction commits, a thread will be allocated for this job to execute. Once the job starts executing, this entry is removed from the cache.

Next time publish is triggered, the cache in the SimpleTaskManager is referred for any existing entry for given cluster-id. If an entry is found, no new job is created, instead, just a counter is updated and the flow returns. The entry in the cache means that there already a job created to publish rules on this cluster, which is yet to start and it will take care of publishing rules for this cluster-id.

The exception that is seen in the vsm.logs, resulted in rolling back of the transaction and the job objects created in the database were also rolled back, but the job-ids still remained in the cache, resulting in cache corruption. From this point onwards, whenever there will be a publish request for any of these clusters (have corrupt entry in the cache), only the counter will be incremented and no new task will be scheduled. The end result is that the IP for the VM is never pushed down to the address set local to ESXi.

The only option to recover from this situation is to restart the NSX Manager, which resets the cache.

Related Information

This issue is scheduled to be resolved with NSX 6.3.7 and 6.4.3.

Detectable by VMware SkylineTM

Actions

Copy

link to clipboard
copied!

Print

Language:
English

Attachments

Additional Resources

KB
•
End Of General Availability of the Free vSphere Hypervisor (ESXi 7.x and 8.x) (2107518)

Result 1 of 1

Ask The Community

Get answers quickly from VMware experts in the community

Post Subject

CONTINUE IN COMMUNITIES

Related Products:

Related Versions:

Take Our Survey

Support Assistant