Originating Packet Traffic

This topic describes how Hyper-V extensions originate new packets and inject them into the extensible switch data path.

Note  This page assumes that you are familiar with the information and diagrams in Overview of the Hyper-V Extensible Switch and Hybrid Forwarding.

Note  In the extensible switch interface, NDIS filter drivers are known as extensible switch extensions and the driver stack is known as the extensible switch driver stack. For more information about the extensions, see Hyper-V Extensible Switch Extensions.

Extensible switch extensions can only inject new packets into the extensible switch ingress data path. This ensures that the extensible switch interface can filter and forward these packets correctly. Extensions must follow these guidelines for injecting new packets into the ingress data path:

• The extension must first allocate a NET_BUFFER_LIST structure for a new packet.

• After the extension allocates a NET_BUFFER_LIST structure for a new packet, it must call the AllocateNetBufferListForwardingContext handler function to allocate the extensible switch forwarding context for the packet.

  The forwarding context resides in the out-of-band (OOB) data of the packet. It contains forwarding information for the packet, such as its source port and an array of one or more destination ports.

  For more information about the forwarding context, see Hyper-V Extensible Switch Forwarding Context.

• After the extension calls AllocateNetBufferListForwardingContext, the source port for the packet will be set to NDIS_SWITCH_DEFAULT_PORT_ID. A packet with a source port identifier of NDIS_SWITCH_DEFAULT_PORT_ID is trusted and bypasses the extensible switch port policies, such as access control lists (ACLs) and quality of service (QoS).

  The extension may want the packet to be treated as if it originated from a particular port. This allows the policies for that port to be applied to the packet. The extension calls SetNetBufferListSource to change the source port for the packet.

  However, there may be situations where the extension may want to assign the packet's source port identifier to NDIS_SWITCH_DEFAULT_PORT_ID. For example, the extension may want to set the source port identifier to NDIS_SWITCH_DEFAULT_PORT_ID for proprietary control packets that are sent to a device on the external network.

• If the forwarding extension is sending a new packet on the ingress data path, it must determine the destination ports for the packet. For more information on this procedure, see Adding Extensible Switch Destination Port Data to a Packet.

  Note  A capturing or filtering extension cannot add new destination ports to the new packet.

• When the extension creates a new packet, the packet data is located in local, or trusted, memory in the parent operating system of the Hyper-V parent partition. This memory is not accessible by the child partition. Therefore, it is considered "safe" from unsynchronized updates by the guest operating system that runs in that partition.

  The extension must obtain the NDIS_SWITCH_FORWARDING_DETAIL_NET_BUFFER_LIST_INFO union for the new packet by using the NET_BUFFER_LIST_SWITCH_FORWARDING_DETAIL macro. The extension must set the IsPacketDataSafe member to TRUE. This specifies that all of the packet data is located in trusted memory.

• When the extension calls NdisFSendNetBufferLists to inject the packet into the ingress data path, it must set the Flags parameter with the appropriate extensible switch flag settings. For more information about these flag settings, see Hyper-V Extensible Switch Send and Receive Flags.

• When NDIS calls the extension's FilterSendNetBufferListsComplete function to complete the send request of the new packet, the extension must call FreeNetBufferListForwardingContext to free the allocated forwarding context. The extension must do this before it frees or reuses the NET_BUFFER_LIST structure for the packet.

For more information about the extensible switch ingress and egress data paths, see Hyper-V Extensible Switch Data Path.