¿La duplicación de puertos causa latencia adicional?

9

Si estoy enviando tráfico del host A a B mediante un conmutador, ¿habilitar un puerto espejo / SPAN aumentará el tiempo que tardan mis tramas en llegar de A a B?

Nb: no me preocupa el tiempo que tarda el marco reflejado en llegar a mi host de monitoreo. Solo me pregunto si afectará el rendimiento de la red en un entorno de tiempo crítico.

¿Alguien ha probado esto? (También agradecería cualquier enlace a una publicación / documento sobre esto)

switch mirror

— Jugoso
fuente

1

En resumen, no. Este tipo de cosas sucede todo el tiempo con cuadros que tienen destinos desconocidos o son transmisiones. Por lo general, la duplicación y el reenvío se realizan en hardware a velocidad de cable.

— Ron Maupin

1

Como Ron Maupin ya ha señalado, en general no. Sin embargo, nadie podría hacer esta declaración general con ninguna garantía en todos los proveedores y plataformas. ¿Podrías reducir esto?

— YLearn

¿Alguna respuesta te ayudó? Si es así, debe aceptar la respuesta para que la pregunta no siga apareciendo para siempre, buscando una respuesta. Alternativamente, puede proporcionar y aceptar su propia respuesta.

— Ron Maupin

7

Por lo general, según Cisco, "el impacto en la estructura de conmutación de alta velocidad es insignificante".

Esto, por supuesto, depende de su interruptor, su estructura y la carga en el mismo interruptor. Sin embargo, el puerto al que se envían los datos copiados podría descartar paquetes si se suscribe demasiado. Personalmente, nunca he experimentado ningún tipo de detrimento al usar duplicación o SPAN.

Aquí hay un documento de Cisco directamente sobre el tema en algunas de sus líneas cat: http://www.cisco.com/c/en/us/support/docs/switches/catalyst-6500-series-switches/10570-41. html # anc48

— stevieb
fuente

1

Quizás uno pensó agregar a esto: Sea más cauteloso con "RSPAN" o la duplicación remota. Reenviar una gran cantidad de tráfico reflejado a través de su red podría sobrecargar fácilmente sus enlaces. Como dijo stevieb, si hace SPAN / puerto-espejo en el mismo dispositivo a un puerto espejo dedicado, debería estar bien.

— Sebastian Wiesinger

3

Es posible afectar las fuentes (es decir, los puertos monitoreados) si el tráfico agregado excede la capacidad del destino (es decir, el puerto de monitoreo). No tengo la referencia en la que estaba pensando inicialmente, pero aquí hay otra: Contrapresión de un puerto SPAN .

Así que imagine que tiene un servidor en un puerto de diez conciertos que desea SPAN a un dispositivo de captura de paquetes (o IDS / IPS, etc.). El dispositivo de monitoreo también está en una interfaz de diez conciertos.

Recuerde que cuando configura un SPAN, tiene la opción de SPANning transmitir (fuera de la interfaz del conmutador hacia el servidor), o recibir (del servidor al conmutador), o ambos. Normalmente nos gustaría ver ambos lados de una conversación, por lo que elegiríamos SPAN tanto la transmisión como la recepción.

Ahora imagine que el servidor está muy ocupado, y tanto sus transmisiones como las transmisiones de recepción están bastante llenas, consistentemente por encima de 5 gigas en cada dirección.

Ahora desea enviar DOS transmisiones de más de 5 conciertos al dispositivo de monitoreo a través del puerto de destino SPAN. El tráfico total que se envía hacia el destino SPAN es superior a 10 gig. Pero, esa interfaz es SOLAMENTE 10 Gig hacia el dispositivo de monitoreo. ¿Así que lo que sucede? Recuerdo que los documentos de Cisco decían que inicialmente, los paquetes serían descartados del búfer de transmisión de la interfaz hacia el dispositivo de monitoreo (es decir, el búfer de transmisión de destino SPAN). Sin embargo, en el caso de flujos de tráfico sostenidos de larga duración, con el tiempo, la capacidad del conmutador para soltar el exceso de tráfico del búfer de transmisión se agotará (lo que no tiene sentido, y en ese momento no tenía sentido para mí), y entonces el interruptor comenzará a usar otros mecanismos para disminuir el flujo, incluida la 'contrapresión' usando 802.

Y ahora ha afectado su tráfico de origen. Suceden cosas malas.

Este problema es / fue especialmente significativo para una red grande, de alta velocidad y muy baja latencia, que tenía muchas fuentes para SPAN. Lo cual fue una consideración importante y resultó en el reemplazo del uso de sesiones SPAN que tienen muchas fuentes para TAPS ópticos, alimentando conmutadores de agregación con ACL entrantes (filtrado para tráfico interesante), y luego conectando ese tráfico entrante a múltiples consumidores de paquetes especializados de 10 Gig (para datos necesidades de archivo y análisis).

Moraleja de la historia: si tiene la intención de utilizar muchas fuentes de SPAN, asegúrese de que el ancho de banda agregado de AMBOS tx y rx sea menor que el ancho de banda de su dispositivo de captura.

Aquí hay un tratado decente sobre el uso de puertos SPAN

— Jason
fuente