☰

LAN con un enrutador lento y un conmutador rápido de capa 2: ¿por qué el enrutador afecta las velocidades de Ethernet?

tag-icon • tag-icon networking router ethernet lan gigabit-ethernet
LAN con un enrutador lento y un conmutador rápido de capa 2: ¿por qué el enrutador afecta las velocidades de Ethernet?

Aquí está mi diseño de LAN:

[Laptop (Windows 10)]  [Raspberry Pi (Ubuntu)]
                   \    /
               (Layer 2 Switch) 
                      |
     (Wireless router w/ gigabit LAN) 
                      |
     (Wireless router w/ 100 Mbps LAN)
                      |
                   Internet

Estoy usando Raspberry Pi como NAS, por lo que quiero velocidades de gigabit entre Pi y la computadora portátil con Windows.

La puesta en marchaeraLAN a WAN entre los dos enrutadores, y yoteníavelocidades gigabit entre Windows y Pi.

Acabo de cambiarlo para que el enrutador gigabit esté en modo LAN a LAN (ethernet conectado al puerto LAN, DHCP deshabilitado). ¡Pero ahora Pi y Windows solo hablan a 338 Mbps! ¿Que pasa con eso?

Tengo entendido que el conmutador dirigirá el tráfico directamente de uno a otro, sin involucrar a los enrutadores. (Además, pathping/tracert no muestra ninguna otra dirección IP entre los dos). Sin embargo:

  1. Cuando ejecuto el iperf3, las tres luces del interruptor parpadean frenéticamente, incluida la del enrutador.
  2. La velocidad es gigabit cuando permito que el enrutador gigabit sea su propio jefe (DHCP habilitado, conectado de WAN a LAN).
  3. La velocidad es ~338 Mbps tanto cuando configuro el enrutador gigabit como el enrutador secundario (DHCP desactivado, LAN a LAN),ycuando quito el enrutador gigabit, conecto el conmutador directamente al enrutador de 100 Mbps. La misma velocidad en ambos casos, por lo que el enrutador lento está claramente involucrado.

(Detalles: estoy midiendo con iperf3. La máquina con Windows usa iperf3 en WSL, con un adaptador de Ethernet a USB 3.0. El conmutador es un D-Link DGS-105, el enrutador gigabit es un TP-Link Archer C2 , el enrutador de 100 Mbps es un Fritz!Box 7430. Solo he medido con Windows como cliente y Pi como servidor; no puedo hacer que funcione al revés, incluso con los firewalls desactivados).

Respuesta1

¡Problema resuelto! Necesitaba realizar una liberación/renovación de DHCP. (Respondiendo mi propia pregunta para poder marcarla como resuelta).

Para futuros lectores: en Windows, entonces ipconfig /release, ipconfig /renewy en Linux, sudo dhclient -r eth0entonces sudo dhclient eth0. ( eth0es la interfaz; consulte con ip apara identificar el nombre correcto para su interfaz).

Si alguien tiene unos minutos para responder algunas de las preguntas que me quedan, ¡se lo agradecería! Intentando aprender algo de esto.

Aquí hay una línea de tiempo:

  1. iperf3 funciona a 338 Mbps y requiere el enrutador FritzBox de 100 Mbps.
  2. Pasan 12 horas. Desafortunadamente, no volví a verificar iperf antes de hacer lo siguiente.
  3. En Windows, verifiqué arp -ay el Pi simplemente no estaba en la lista.
  4. Hurgué un poco, incluido el acceso ssh al Pi desde Windows (usando el nombre de host). Cuando volví a comprobar arp -a, ¡el Pi había aparecido mágicamente! (No había realizado una liberación/renovación de DHCP en este momento).
  5. iperf3 ahora produjo una velocidad de gigabit, pero cuando desconecté el interruptor del enrutador, Pi y Windows no pudieron hacer ping entre sí. Además, el puerto del conmutador al enrutador parpadeó frenéticamente mientras se ejecutaba iperf.
  6. Hice una versión/renovación de DHCP tanto en Windows como en Pi. Ahora obtengo la misma velocidad gigabit, pero funciona incluso cuando desconecto el interruptor del enrutador. Cuando se conecta durante iperf, el puerto del enrutador aún parpadea, peromenosfrenéticamente que antes.

Lo que entiendo de esto es lo siguiente:

  • Cuando obtenía 338 Mbps, el conmutador necesitaba el enrutador habilitado para DHCP paraalgo, pero probablemente no para transportar el tráfico (porque 338 Mbps > 100 Mbps). ¿Quizás fue consultar al enrutador para determinar el destino de todos y cada uno de los paquetes?
  • Al realizar SSH desde Windows a Pi, de alguna manera mejoré la situación, pero no le di al conmutador total independencia de los enrutadores. ¿Quizás esto provocó que el enrutador gigabit aprendiera a responder las consultas del conmutador, sin involucrar al enrutador más lento?
  • Con una liberación/renovación completa de DHCP, el conmutador pudo dirigir el tráfico sin un enrutador. ¿Fue esto porque Windows y/o Pi aprendieron la dirección de cada uno, o la versión/renovación de DHCP también actualizó las tablas de enrutamiento del conmutador (o lo que sea el equivalente de un conmutador)?
  • Ahora que el interruptorpoderlleva el tráfico sin el enrutador, ¿por qué todavía conecta el enrutador (como lo indica la luz parpadeante) si está disponible?

¡Gracias por tu tiempo en responder cualquiera de estas preguntas! Y gracias a @user1686 por encaminarme por el camino correcto.

información relacionada