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

NetX failure policy - how to change the third party failure policy (60366)

Last Updated: 12/5/2018Categories: How toTotal Views: 3207Language:
English

Subscribe to get an email
newsletter with new updates

Please provide article feedback:

Symptoms

A Failure policy defines what actions will be taken if the third party NetX service is unavailable.

There are 2 states:

failOpen: The traffic for the VMs on the associated host will continue to pass if the third party service is not available, i.e. powered off.

failClose: The traffic for the VMs on the associated host will no longer pass if the third party service is not available, i.e. powered off.

Failure policy configuration is a day-1 installation configuration and ideally should not be changed regularly.

Purpose

This articles intends to explain how the failure policy works and the process to change it after installation.

Impact / Risks

If incorrectly configured, VMs may become unprotected when the third party service is not available, i.e. powered off.

Resolution

If after deployment, you decide to change it, the failure policy is located in Service Definitions / select the third party Service Insertion / Security Profile.

Please be aware that carrying out this procedure will remove protection from already protected VMs for the duration of the procedure.

Therefore it is recommended to isolate the protected VMs before the operation and carry out the operation in a maintenance window.
There is one location for the failure policy change and two locations were you can remove the Security Groups from the Security Policy which uses the failure policy.

The first option is in Service Definitions:

Go to Service Definitions, select the third party Service Insertion, click the Service Instance, click the profile associated with the filters, go to the applied objects tab and click Edit.

Unbind "Security Group/Dvpg/Logical Switch" from service profile and click OK.

On the ESXi hosts with protected VM, check the slot 4 filters are removed, use the following command: summarize-dvfilter

Change failure policy on Service Profile to be true or false as required.

Go to Service Definitions, select the third party Service Insertion, click the Service Instance, click the profile associated with the filters, go to the applied objects tab and click Edit.

Rebind "Security group/Dvpg/Logical Switch" to the service profile and click ok.

Verify failure policy by using summarize-dvfilter command on ESXi host. Slot 4 should now be either failOpen or failClose, depending on the selection made.

The second option is in Service Composer:

Unbind "Security Group/Dvpg/Logical Switch" from Service Profile if you are using "Firewall" tab for configuring rules or unbind Security Policy from Security Group if you are using "Service Composer" tab.

Change failure policy on Service Profile to be true or false as required.

Rebind "Security Group/Dvpg/Logical Switch" from Service Profile if you are using "Firewall" tab for configuring rules or bind Security Policy from Security Group if you are using "Service Composer" tab.

Verify failure policy by using summarize-dvfilter command on ESXi host.

The failure policy can only be failClose or failOpen per slot, there should not be a mix of these policies, however each slot can have a different policy i.e. slot 2 can be failOpen and slot 4 can be failClose. But all VMs slot 2 should be the same failure policy and likewise slot 4 VMs should also have the same failure policy.

Detectable by VMware SkylineTM

Actions

Copy

link to clipboard
copied!

Print

Language:
English

Attachments

Additional Resources

No results for undefined

Ask The Community

Get answers quickly from VMware experts in the community

Post Subject

CONTINUE IN COMMUNITIES

Related Products:

VMware NSX for vSphere

Related Versions:

Take Our Survey

Support Assistant