Directrices de administración de paquetes para la ruta de acceso de datos de conmutador extensible

En este tema se describen las directrices que deben seguir las extensiones de conmutador extensible de Hyper-V para administrar los paquetes obtenidos en la ruta de acceso de datos extensible del conmutador.

Nota En la interfaz de conmutador extensible, los controladores de filtro NDIS se conocen como extensiones de conmutador extensible y la pila de controladores se conoce como pila de controladores de conmutador extensible. Para obtener más información sobre las extensiones, vea Extensiones de conmutador extensible de Hyper-V.

Nota En esta página se supone que está familiarizado con la información y los diagramas de Información general del conmutador extensible de Hyper-V y elreenvío híbrido.

Las extensiones deben seguir estas directrices para la administración de paquetes en la ruta de acceso de datos de conmutador extensible:

  • Las extensiones que originan paquetes deben llamar a NdisFSendNetBufferLists para iniciar una solicitud de envío en la ruta de acceso de datos de entrada. Esto debe hacerse de esta manera para permitir el reenvío adecuado del paquete a través del conmutador extensible.

  • Una extensión de captura puede supervisar paquetes en la ruta de acceso de entrada y salida del conmutador extensible. Sin embargo, este tipo de extensión siempre debe reenviar paquetes y no debe quitar los paquetes. Además, la extensión de captura no debe modificar los datos del paquete antes de reenviar el paquete.

  • En la ruta de acceso de datos de entrada extensible del conmutador, las extensiones de filtrado y reenvío pueden hacer lo siguiente:

    • Las extensiones de filtrado pueden filtrar el tráfico de paquetes y aplicar solo directivas personalizadas de puerto o conmutador para la entrega de paquetes a través del conmutador extensible. Cuando la extensión filtra los paquetes en la ruta de acceso de datos de entrada, solo puede aplicar reglas de filtrado basadas solo en el puerto de origen y la conexión del adaptador de red desde el que se originó el paquete. Esta información se almacena en los datos OOB de la estructura NET_BUFFER_LIST de un paquete y se puede obtener mediante la macro NET_BUFFER_LIST_SWITCH_FORWARDING_DETAIL .

      Nota Los paquetes obtenidos en la ruta de acceso de datos de entrada no contienen puertos de destino. El filtrado de paquetes en función de los puertos de destino solo se puede realizar en los paquetes obtenidos en la ruta de acceso de datos de salida.

    • Las extensiones de reenvío pueden filtrar el tráfico de paquetes y aplicar directivas personalizadas y estándar de puerto o conmutador para la entrega de paquetes a través del conmutador extensible. Cuando la extensión de reenvío filtra los paquetes en la ruta de acceso de datos de entrada, aplica reglas de filtrado basadas en el puerto de origen, así como los puertos de destino que la extensión de reenvío asigna al paquete.

  • En la ruta de acceso de datos de salida extensible del conmutador, las extensiones de filtrado y reenvío pueden hacer lo siguiente:

    • Las extensiones de filtrado pueden filtrar el tráfico de paquetes y aplicar solo directivas personalizadas de puerto o conmutador para la entrega de paquetes a través del conmutador extensible. Cuando la extensión de filtrado filtra los paquetes en la ruta de acceso de datos de salida, puede aplicar reglas de filtrado basadas solo en los puertos de destino de un paquete.

      Los datos del puerto de destino se almacenan en los datos OOB de la estructura de NET_BUFFER_LIST de un paquete. Las extensiones obtienen esta información llamando a la función GetNetBufferListDestinations .

    • Las extensiones de reenvío pueden filtrar el tráfico de paquetes y aplicar directivas personalizadas y estándar de puerto o conmutador para la entrega de paquetes a través del conmutador extensible. Cuando la extensión de reenvío filtra los paquetes en la ruta de acceso de datos de salida, puede aplicar reglas de filtrado basadas en los puertos de origen o destino de un paquete.

    • En función de las directivas aplicadas en un paquete, la extensión de filtrado o reenvío puede excluir la entrega del paquete a uno o varios destinos. Para obtener más información sobre este procedimiento, vea Excluir la entrega de paquetes a puertos de destino de conmutador extensible.

      En función de las directivas aplicadas en un paquete, la extensión de reenvío puede excluir la entrega del paquete a uno o varios destinos. Para más información, consulte Reenvío híbrido.

  • En la ruta de acceso de datos de salida extensible del conmutador, las extensiones de filtrado y reenvío no deben hacer lo siguiente:

    • Modifique los datos del paquete antes de reenviar el paquete en la ruta de acceso de datos de salida.

      Si una extensión de filtrado necesita modificar los datos de un paquete, primero debe clonar el paquete sin conservar los destinos de puerto. A continuación, la extensión debe insertar el paquete modificado en la ruta de acceso de datos de entrada. Esto permite que las extensiones subyacentes apliquen directivas en el paquete modificado y la extensión de reenvío puede agregar destinos de puerto.

      Si la extensión de reenvío necesita modificar los datos de un paquete, primero debe clonar el paquete antes de asignar destinos de puerto. Una vez que se ha modificado el paquete y se han asignado destinos de puerto, la extensión debe insertar el paquete modificado en la ruta de acceso de datos de entrada.

      Para obtener más información, consulte Clonación del tráfico de paquetes.

      Nota Si la extensión clona un paquete que se obtuvo en la ruta de acceso de datos de salida, puede insertar el nuevo paquete en la ruta de acceso de datos de salida solo si no ha cambiado los datos del paquete y ha conservado los datos de puerto de destino originales.

    • Agregue puertos de destino al paquete antes de reenviar el paquete.

      Nota Las extensiones de reenvío pueden agregar puertos de destino a los paquetes obtenidos en la ruta de acceso de datos de entrada.

    • Inserte paquetes de datos nuevos o clonados en la ruta de acceso de datos de salida.

  • En la ruta de acceso de datos NDIS estándar, los datos de OOB de conmutador no extensible suelen tener formatos diferentes en función de si el paquete se indica como un envío o una recepción. Por ejemplo, el NDIS_IPSEC_OFFLOAD_V2_HEADER_NET_BUFFER_LIST_INFO datos OOB es una unión de estructuras específicas de envío y recepción.

    En la ruta de acceso de datos de conmutador extensible, todos los paquetes se mueven a través de la pila del controlador de extensión como los envía y recibe. Por este motivo, los datos de OOB de conmutador no extensible dentro de la estructura NET_BUFFER_LIST del paquete estarán en un formato de envío o recepción a través de la duración del flujo a través de la pila del controlador.

    El formato de estos datos OOB depende del puerto de conmutador extensible de origen desde el que el paquete llegó al conmutador extensible. Si el puerto de origen está conectado al adaptador de red externo, los datos de OOB de conmutador no extensible estarán en un formato de recepción. En el caso de otros puertos, estos datos de OOB estarán en un formato de envío.

    Nota Si la extensión clona la estructura NET_BUFFER_LIST de un paquete, debe tener en cuenta los datos de OOB de conmutador no extensible si agrega o modifica los datos de OOB. La extensión debe llamar a CopyNetBufferListInfo para copiar los datos de OOB asociados a la ruta de acceso de datos de conmutador extensible de un paquete de origen a un paquete clonado. Esta función mantendrá el formato de envío o recepción de OOB cuando los datos se copien en el paquete clonado.

  • Si una extensión quita un paquete de la ruta de acceso de datos de salida, debe llamar a ReportFilteredNetBufferLists. Cuando se llama a esta función, la interfaz de conmutador extensible incrementa los contadores y registra los eventos de los paquetes descartados o excluidos.