Description

Under some circumstances VMware routes broadcast packets coming from Solaris running in Charon-SSP back to the interface from which the packets came. In this case Solaris will log the following error:

Jul 29 05:08:20 my-hostname: IP: Hardware address '08:00:2b:b3:11:d8' trying to be our address 1.2.3.4!

The VMware "Net.ReversePathFwdCheckPromisc" parameter can be used to avoid this behavior.

Step-by-step guide

Open the ESXi VM configuration
Go to "configuration"
Select "advanced"
Set the "Net.ReversePathFwdCheckPromisc" parameter to 1.

Additional Information

VMware explanation of setting: VMware KB article with patch description

Here the relevant section for convenience:

Consider a vSwitch that has more than one uplink and has the promiscuous mode enabled. Some of the packets that come in from the uplinks that are not currently used by the promiscuous port, are not discarded. This behavior might mislead some applications, such as the CARP protocol instance.
This issue is resolved in this release. Starting with this release the Net.ReversePathFwdCheckPromisc configuration option is provided to explicitly discard all the packets coming in from the currently unused uplinks, for the promiscuous port.
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.

Related articles

Page:

Duplicate Network Packets with SSP and VMware

Browser not supported