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

Modifying the vSwitch security policy is not persistent when SRIOV is enabled (74909)

Last Updated: 12/10/2019Categories: TroubleshootingTotal Views: 10766Language:
Chinese (Simplified)JapaneseEnglish

5 like this article

Subscribe to get an email
newsletter with new updates

5 people found this helpful Please provide article feedback:

Symptoms

When the vSwitch is configured with the vSwitch Security feature “Allow MAC Address Change: true”, the SRIOV VMs (VF) refuses to accept the new MAC address.

vSwitch Security policy (MAC change/Promiscuous Mode) for VF traffic on SRIOV enabled VMs are currently not fully supported

Cause

In-box i40en driver do not support Mac Change or Promiscuous Mode change.

Impact / Risks

You will have to reset the interface in the guest operating system to get the latest MAC address from the virtual device and acquire an IP address.

Resolution

VMware is working as designed.The following is the latest Intel Driver Version: 1.9.5. Currently, with this Driver patch, the Trusted Virtual Function (VF) set on the VM can stay Trusted persistently between VM reboots.

Download Link the here

NOTE: VLAN Tag Stripping Control feature is currently not available on Windows VF drivers. Some know issues, VF adapter cannot receive any packet after VM reboot. The probability of issue occurrence increases with the overall number of VFs and number of VMs reboots.

Workaround: power off and on VMs with VFs instead of rebooting them. More info: Release_Notes_i40en-1.9.5

Workaround

At the moment, Intel team has provided the TrustMode configurations, which allows to override the policy on a per VF basis.

Type ”esxcli intnet sriovnic vf set -v $VFID -n %VMNICID -s off” at VM startup, to disable spoof checking for that VF at the PF.

Type ”esxcli intnet sriovnic vf set -v $VFID -n %VMNICID –t on” at VM startup, to set that VF as trusted mode at the PF.

Example:

Set VF 1 as trusted

esxcli intnet sriovnic vf -n vmnic0 -v 1 -t on

Set VF 1 as untrusted

esxcli intnet sriovnic vf -n vmnic0 -v 1 -t off

Enable VF spoof-check for VF 1

esxcli intnet sriovnic vf -v 1 -n vmnic0 -s on

Disable VF spoof-check for VF 1

esxcli intnet sriovnic vf -v 1 -n vmnic0 -s off

For more information refer to release notes in  More info: Release_Notes_i40en-1.9.5 [ see attachment ]

Related Information

SR-IOV uses physical functions (PFs) and virtual functions (VFs) to manage global functions for the SR-IOV devices.

Physical function:
PFs are full PCIe functions that are capable of configuring and managing the SR-IOV functionality. It is possible to configure or control PCIe devices using PFs, and the PF has full ability to move data in and out of the device.

Virtual function:
VFs are lightweight PCIe functions that support data flowing but have a restricted set of configuration resources.

Note: Theoretically a trusted VF can have the same set of privileged functionality as that of its parent PF.

With SRIOV being enabled, the virtual machine and the physical adapter exchange data directly without using the VMkernel as an intermediary. Bypassing the VMkernel for networking reduces latency and improves CPU efficiency.

It basically relies on the interaction between the virtual functions (VF) and the physical function (PF) of the NIC port for better performance, and interaction between the driver of the PF and the host switch for traffic control.

“MAC address changes” and “Forged transmits” are the port group settings that need to be made persistent, in order to allow MAC spoofed frames to be passed between the VF and the NIC.

The VF will be using trust mode configuration via the driver syntax as stated above in the workaround section and it is independent of vmkernel operations.

Detectable by VMware SkylineTM

Actions

Copy

link to clipboard
copied!

Print

Language:
Chinese (Simplified)JapaneseEnglish

Attachments

Release_Notes_i40en-1.9.5

Additional Resources

KB
•
[VMC on AWS] VMware HCX の導入後にパブリック IP アドレスが自動的に割り当てられる (75035)

KB
•
在 VMware NSX-T Controller 节点上，/var/log 分区呈指数增长，而不进行轮换 (74758)

Results 1-2 of 2

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