Utilice siempre una conexión lenta en lugar de una "más rápida"

8

En Windows, existe esta métrica automática donde la métrica se selecciona de acuerdo con la velocidad declarada del enlace. Ahora tengo una LAN gigabit enrutada a un servicio DSL de 2Mbps y una conexión de banda ancha móvil HSDPA. El primero siempre se elige para paquetes de Internet, aunque el segundo es realmente más rápido.

Intenté establecer la métrica de la interfaz de banda ancha móvil en 1 y aumentar su prioridad en la configuración avanzada de la configuración del adaptador, pero esto no parece afectar la métrica de la ruta predeterminada. La ruta predeterminada a la interfaz Ethernet siempre tiene una métrica "efectiva" más baja que la interfaz de banda ancha móvil (es decir, se usa incluso si tiene una métrica más alta).

¿Me estoy perdiendo de algo?

Editar:

Interfaces:

Idx     Met         MTU          State                Name
---  ----------  ----------  ------------  ---------------------------
 13           9        1500  connected     Mobile broadband
 12          25        1500  disconnected  WiFi 2
  1          50  4294967295  connected     Loopback Pseudo-Interface 1
 20           5        1500  disconnected  Local Area Connection* 12
 24          10        1500  connected     Ethernet

Edición 2:

El extraño comportamiento de enrutamiento regresó hoy:

Tabla de ruteo:

Publish  Type      Met  Prefix                    Idx  Gateway/Interface Name
-------  --------  ---  ------------------------  ---  ------------------------
No       Manual    512  0.0.0.0/0                  24  192.168.1.254
No       Manual    0    0.0.0.0/0                  12  192.168.135.1
No       Manual    256  0.0.0.0/0                  13  188.*.*.*

Idx 12 es el enlace más rápido. Idx 24 es el más lento. La métrica de ruta de la ruta idx 24 se ajustó manualmente. Sin embargo, la ruta de seguimiento mostró esto:

C:\Users\bc>tracert -4 -d google.com

Tracing route to google.com [173.194.41.168]
over a maximum of 30 hops:

  1     2 ms     2 ms     3 ms  192.168.1.254
  2    25 ms    24 ms    26 ms  217.*.*.*
  3    27 ms    26 ms    36 ms  217.*.*.*

Esto parece sugerir que para rutas con el mismo destino, las métricas no se utilizan.

Además, parece que las métricas solo se respetan en la primera ruta de seguimiento después de que se ha establecido una conexión. La siguiente ruta de seguimiento mostrará constantemente la conexión Ethernet (idx 24) como el primer salto.

billc.cn
fuente
1
¿Por qué no imprime su tabla de enrutamiento para que la gente pueda visualizar de qué está hablando? asegúrese de marcar las rutas que 'no funcionan'
Boppity Bop
Podrías probar Connectify Dispatch, supongo
pratnala

Respuestas:

1

La respuesta corta es NO, no puede enrutar paquetes basados ​​en métricas cuando se utiliza una conexión "dial up" y su conexión HSDPA se clasifica como conexión dial-up.


Microsoft enruta todos los paquetes IP a través de DuN si está establecido y cerrará la red local para evitar que intrusos de marcado externo invadan su LAN DSL / Gb.

Este diseño heredado se implementó a mediados de la década de 1990 y es inútil, pero está profundamente incrustado en su pila de red que se necesitará un enrutador de terceros o ajustes de Conexión compartida a Internet para evitar y lograr lo que está tratando de hacer.

Un administrador de perfiles de conexión también es una buena opción, como el Access Connections Manager de IBM / Lenovo, que detecta todas las conexiones existentes y usa las más rápidas, pero nunca he intentado instalarlo en otra cosa que no sea ThinkPad y no sé si funcionará en cualquier computadora portátil o sería compatible con su adaptador y controladores 3G. Microsoft puede ofrecer un administrador de perfil de connectiopn, pero no lo conozco ni afirmo presuntuosamente que conozco todo el software de Microsoft.

Por lo general, los usuarios equipados con Windows DialUpNetworking han aceptado este diseño y desconectado conscientemente su conexión DuN cuando usan una LAN, lo más probable es que también lo hayas descubierto.

Su pregunta requiere un seguimiento de por qué es necesario que monte dos o más conexiones IP simultáneas a través de su LAN y 3G. Espero que no creas tontamente que realmente puedes canalizar las conexiones para aumentar tu ancho de banda.

Otra razón por la que estoy especulando sobre su intención es posiblemente descargar simultáneamente desde un sitio limitante como Rapidshare que solo permitiría una transferencia de archivos a la vez, si ese es el caso, entonces debería usar dos navegadores diferentes y configurar IE para usar solo su Conexión de acceso telefónico 3G mientras que otro navegador como Firefox usa solo la LAN y esto le permitiría descargar sus grandes archivos de películas porno / pirateadas de dos en dos.

Lanza de águila
fuente
1
Soy muy consciente de lo que puedo y no puedo hacer al tener múltiples conexiones. En este caso, quiero acceder a recursos en la LAN y obtener Internet más rápido a través de banda ancha móvil. Sin embargo, lo que estoy observando parece ser exactamente opuesto a lo que describió aquí: los paquetes se enrutan constantemente a través de la conexión Ethernet en lugar de la banda ancha móvil.
billc.cn
Sí, es cierto, estás "tan consciente" de lo que es posible en una LAN que aún no puedes eludir el diseño de larga data de Windows.
Eagle Spear el
0

Antes de jugar con la métrica, siempre debe verificar si ambas formas funcionan (por ejemplo, desconectar cada una y comprobar si todas funcionan). En su caso, supongo que todo está bien con esto.

Si todo funciona y ambas conexiones pueden manejar sus paquetes, la métrica se usa para determinar qué interfaz usar. Si me meto con las métricas, prefiero deshabilitar la métrica automática para cada interfaz y manejarla por mí mismo, pero también puede buscar los valores utilizados por la métrica automática en KB299540 . No recomiendo esto, porque nunca se sabe con certeza si algo cambia en el futuro o si Windows decide que una conexión es de mejor o peor calidad.

La conexión con la métrica más baja debería usarse para enviar los paquetes. Si no es así, intente reiniciar. Si aún no funciona, entonces

a) has configurado mal algo;

b) una conexión que (en su opinión) debería enrutar sus paquetes no puede enrutarlos.

Mose
fuente