Edit

Share via

Using Virtual Switch Filtering

  • Article

Overview of Virtual Switch Filtering

Virtual Switch Filtering is supported in Windows 8 and later versions of Windows.

This WFP feature allows filtering on fields of the MAC header, IP header, and upper protocol ports as well as virtual switch specific fields such as virtual port (VPort) and virtual machine identifier (VM ID). These layers are invoked on a per-packet basis for all packets traversing the virtual switch. These layers are accessed from a virtual switch extension filter—a type of NDIS lightweight filter (LWF) driver.

A callout driver calls the FwpsvSwitchEventsSubscribe0 function to register callback entry points for virtual switch layer events.

The entry points for the callback notification functions are specified in an FWPS_VSWITCH_EVENT_DISPATCH_TABLE0 structure. The callback functions that are available include:

The FWPS_VSWITCH_EVENT_TYPE enumeration defines the values for the eventType parameter of the virtual switch notification functions.

The callout driver must eventually call FwpsvSwitchEventsUnsubscribe0 to free the system resources.

If a callout driver returns STATUS_PENDING from a WFP notification function, WFP will return STATUS_PENDING to the OID request handler. The callout driver must call the FwpsvSwitchNotifyComplete0 function to complete the pending operation. After the FwpsvSwitchNotifyComplete0 call, WFP calls the NdisFOidRequestComplete function to complete the OID for the virtual switch.

Callbacks should not add or delete WFP filters synchronously in the context of the notification functions. In addition, if the notification function allows the callback to return STATUS_PENDING, and the callout returns STATUS_PENDING, the callout should not add or delete WFP filters before completing the notification.

WFP Virtual Switch Filter Layer and Fields

Run-time Filtering Layer Identifiers for virtual switch filtering include:

  • FWPS_LAYER_INGRESS_VSWITCH_ETHERNET
  • FWPS_LAYER_EGRESS_VSWITCH_ETHERNET
  • FWPS_LAYER_INGRESS_VSWITCH_TRANSPORT_V4
  • FWPS_LAYER_INGRESS_VSWITCH_TRANSPORT_V6
  • FWPS_LAYER_EGRESS_VSWITCH_TRANSPORT_V4
  • FWPS_LAYER_EGRESS_VSWITCH_TRANSPORT_V6

Data Field Identifiers for virtual switch filtering include:

Guidance For WFP Virtual Switch Callout Writers

Port 0 Traffic

For WFP virtual switch callouts, traffic from port 0 (the default port ID) is trusted and should not be filtered. This is because, generally, traffic over port 0 originates from other extensions in the driver stack and is thus treated by the data path as privileged and trusted. Virtual switch extensions will sparingly use port 0 for situations such as originating a control packet, which should not be filtered and rejected by any underlying extensions. For more information about Hyper-V extensible switch source port modification, see Modifying a Packet's Extensible Switch Source Port Data.

Callout Matching Rules

When defining a matching rule for filtering, virtual switch callouts should not use the MAC address as a basis for comparison. MAC addresses can change at runtime, and some ports may generate traffic from multiple MAC addresses. Instead, callouts should use a more durable matching rule such as NIC ID, which will not change.

I/O Virtualization (IOV) and WFP Coexistence

WFP cannot be enabled on an IOV switch and is blocked by the OS if an attempt is made to enable it.

Enabling or Disabling WFP

Installers for WFP virtual switch callouts should not modify the WFP extension enabled state; that is, they should not enable or disable WFP itself.