Directrices de administración de paquetes para la ruta de datos del switch extensible

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

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 Hyper-V Extensiones de conmutador extensible.

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

Las extensiones deben seguir estas guías para la administración de paquetes en la ruta de acceso de datos del 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 los paquetes de datos en la ruta de entrada y salida del conmutador extensible. Sin embargo, este tipo de extensión debe siempre reenviar paquetes y no debe descartarlos. 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 del conmutador extensible, 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 trayectoria de salida de datos.

  • 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 del conmutador extensible, 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 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 salida de datos, puede aplicar reglas de filtrado basadas en los puertos de origen o destino.

  • 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, consulte Exclusión de 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 obtener más información, consulte de reenvío híbrido.

• En la trayectoria 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 salida de datos.

    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 modificado el paquete y los destinos de puerto asignados, 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 trayectoria de salida de datos.

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

  En la ruta de datos del conmutador extensible, todos los paquetes se mueven a través de la pila de controladores de extensión tanto al enviar como al recibir. Debido a esto, los datos de OOB del switch no extensible dentro de la estructura NET_BUFFER_LIST del paquete estarán en formato de envío o de recepción durante la duración del flujo a través de la pila de controladores.

  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 OOB del 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 OOB del conmutador no extensible al agregar o modificar dichos datos 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 desde 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 descarta un paquete de la ruta de acceso de datos de entrada o 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.