Esxi Net.ReversePathFwdCheckPromisc Advanced setting
During deployment of Cisco proxy appliance, we discovered a problem. According to cisco to resolve this problem “Net.ReversePathFwdCheckPromisc” should be set to “1” on ESX’s.
The question is – do you know any negative effects which such change could cause. We believe that there must be a reason why by default this option is set to 0 ? That’s why I decided to figure our what it is used for.
After some research I was able to find answer:
Setting – > Net.ReversePathFwdCheckPromisc = 1 — > this is when you are expecting the reverse filters to filter the mirrored packets, to prevent multicast packets getting duplicated.
Note: If the value of the Net.ReversePathFwdCheckPromisc configuration option is changed when the ESXi instance is running, you need to enable or re-enable the promiscuous mode for the change in the configuration to take effect.
The reason you would use promiscuous mode depends on the requirement and configuration. Please check the below KB Article:
- This option is not enabled by default because we are not aware of the vSwitch configuration and can’t predict what it could be as it has configurable options.
VMware does not advise to enable this option if we do not have a use case scenario with teamed uplinks and have monitoring software running on the VMs ideally. As When promiscuous mode is enabled at the port group level, objects defined within that port group have the option of receiving all incoming traffic on the vSwitch. Interfaces and virtual machines within the port group will be able to see all traffic passing on the vSwitch causing VM performance impact.
Should the ESX server be rebooted for this change to take effect: answer is – > Yes, and Yes you can enable this option with the VMs running on the existing portgroup.
Do you have any interesting virtualization related question?
One thought on “Esxi Net.ReversePathFwdCheckPromisc Advanced setting”
Hi I enabled Net.ReversePathFwdCheckPromisc and it worked instantly on ESXi 6.5.