Switchport en half duplex - La velocidad de descarga sufrió pero la carga estuvo bien


13

Un usuario tuvo problemas con la velocidad de descarga de Internet. La conexión a Internet es de 100 Mbit / s. El usuario obtuvo alrededor de 7 Mbit / s en sentido descendente y alrededor de 80 Mbit / s en sentido ascendente.

Probé desde mi computadora y obtuvo alrededor de 70 Mbit / s en sentido descendente y 80 Mbit / s en sentido ascendente. Obviamente, la PC de los usuarios tenía la culpa.

Revisé el conmutador que es un Catalyst 3560 y allí estaba como esperaba, el puerto estaba en half duplex. El usuario había codificado su PC a 100 / completo y el puerto estaba usando auto. Los pulsos de enlace rápido (FLP) detectan la velocidad, pero se debe suponer que el dúplex es la mitad, por lo que el puerto estaba usando 100 / mitad. Con show controller pude ver colisiones y colisiones tardías como se esperaba.

El ancho de banda se probó a través del sitio sueco www.bredbandskollen.se. Utiliza TCP para probar la latencia al principio. Luego abre un socket a través de Flash y realiza varios HTTP GET (TCP) y mide el ancho de banda descendente durante unos 10 segundos. Después de eso, realiza cuatro publicaciones HTTP en el servidor y envía tráfico durante 10 segundos y calcula el ancho de banda ascendente.

Sé que este tipo de sitios no son 100% precisos, pero por lo general pueden dar algún tipo de indicación si está cerca de recibir el tipo de ancho de banda que debería y fue una prueba fácil de ejecutar para asegurarse de que fuera usuario y no la red culpable aquí.

  1. ¿Por qué solo se vio afectado río abajo y no río arriba?

  2. ¿Son estas colisiones reales? Dado que el cable tiene pares de transmisión y recepción separados.


¿Se basan 70/80 en una sola prueba o el promedio de múltiples pruebas? Teniendo en cuenta el tamaño variable de la ventana, una sola prueba sería demasiado vaga.
user2964971

Respuestas:


14

Este es un comportamiento completamente normal con una falta de coincidencia dúplex.

¿Por qué solo se vio afectado río abajo y no río arriba?

Como la computadora funciona en modo dúplex completo, no está utilizando CSMA-CD. Esto significa que no verifica si el medio está inactivo antes de transmitir, ni percibirá ningún dato que reciba durante la transmisión como una colisión. Como tal, la carga desde la computadora no se vería afectada en gran medida.

Por el contrario, el conmutador está utilizando CSMA-CD y esperará a que el medio esté inactivo antes de transmitir. Además, cuando el interruptor detecta una colisión, inmediatamente deja de transmitir la trama y sigue el procedimiento de detección de colisión CSMA-CD. Esto tiene un impacto significativo en el rendimiento del tráfico enviado a la computadora.

Cuando el tráfico es TCP, el efecto negativo se multiplicará ya que cualquier TCP ACK perdido que vaya a la computadora causará una retransmisión TCP.

¿Son estas colisiones reales? Dado que el cable tiene pares de transmisión y recepción separados.

Sí, son colisiones reales; incluso en un entorno semidúplex completo (es decir, concentradores) hay pares de transmisión y recepción separados. La razón es que en un entorno semidúplex, los concentradores repetirán la señal recibida en un puerto en todos los demás puertos. Si dos estaciones intentaran transmitir al mismo tiempo, la señal que se repite no será utilizable.

Dado que el conmutador funciona en modo semidúplex, funciona como en un entorno de este tipo y solo puede transmitir o recibir en un momento dado. Cada vez que el conmutador envía una trama y detecta otro tráfico en el medio (es decir, la computadora, que no está buscando un medio inactivo), esto se trata como una colisión y el conmutador seguirá el procedimiento de detección de colisión (que incluye un esperar o retroceder un período de tiempo).

Como la computadora no está funcionando de esta manera (es decir, comienza a transmitir automáticamente cuando hay datos para enviar), terminas con muchas más colisiones de las que obtendrías en un entorno que estaba compuesto completamente por dispositivos semidúplex.

Editar: Me encontré con una referencia a estos este fin de semana mientras buscaba un asunto no relacionado donde se los denominaba colisiones falsas . No estaría de acuerdo con este punto de vista ya que el interruptor los ve claramente como una colisión y los maneja como tal. Más bien, pensaría en ellos como colisiones innecesarias en el sentido de que no deberían existir en una red conmutada.


Por otro lado, este es el tipo de desajuste dúplex más frecuente (donde el interruptor está configurado en automático y la computadora en dúplex completo). La mayoría de las personas descargan mucho más de lo que cargan, tienden a notar esta condición más fácilmente para informarla.


2
me tomó un tiempo ver su punto en la pregunta de diferencia de velocidad, pero esta es una buena respuesta ... es posible que desee mejorarlo para señalar explícitamente que el Tx del interruptor tiene una velocidad limitada más que la PC, porque debe espere más tiempo debido a la detección de colisión CSMA / CD que la PC esperará los marcos de ejecución de las colisiones. Por el contrario, si incluso algunos de los ACK TCP de la PC chocan en la descarga de la PC, la descarga se penaliza doblemente tanto por TCP como por CSMA / CD de ethernet. Los ACK de TCP eliminados ralentizan ambas transferencias, pero el backoff de CSMA / CD mata la descarga.
Mike Pennington

También depende de qué extremo está Completo y qué extremo es Medio. El Completo envía / recibe sin problemas, mientras que el otro verá una colisión por cada paquete. Esto significa que la transferencia de datos desde el extremo Completo causará menos colisión en el Medio extremo ( como el medio extremo intentará exprimir el ACK entre un paquete grande) mientras que al revés, el extremo completo causará mucha colisión porque tiene más posibilidades de "golpear" un paquete grande con un reconocimiento más pequeño. Puede que no sea la explicación correcta , pero se ajusta a lo que he visto.
Remi Letourneau

@RemiLetourneau, claramente si se invirtiera la dirección del desajuste, el efecto también se revertiría. En tal caso, podría intercambiar la computadora / cambiar los términos en mi respuesta (que era el marco para responder la pregunta del OP). Sin embargo, no estoy seguro de seguir todo el resto de tu comentario.
YLearn

@YLearn Lo que quise decir es que los síntomas de desajuste dúplex incluyen el tráfico que va a una velocidad relativamente normal en una dirección y que se ralentiza al revés. Algo para hacer en qué extremo está enviando grandes marcos y el final de bruja está enviando confirmación. Como usted dice, si revierte la configuración de desajuste, revierte la lentitud del tráfico.
Remi Letourneau

3

Si se probó el TCP, hay muchas cosas que no puede controlar ni siquiera imaginar. La diferencia en el sentido descendente / ascendente podría deberse fácilmente a la configuración de prioridad interna de la NIC, a los almacenamientos intermedios para RX / TX y esencialmente a las configuraciones de bajo nivel que determinan cómo manejar el tráfico RX y TX.

Los 'controladores sh' deben informar cualquier condición simultánea de RX y TX como colisión si se trabaja en modo semidúplex.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.