MTU 3Com812 / Vodafone
Angel
transferir ficheros (scp) y de enviar correo (Exim) hacia el exterior de
mi router 3Com812.
En el servicio de atención al cliente me dijeron que debía modificar la
MTU del router a 1400 (tenía 1500). Desde entonces todo va bien, pero
tengo que poner la MTU de la tarjeta de red de todos los ordenadores de
la subred a 1500 también.
Ayer leí en otro grupo de Usenet que alguien tenía valores de MTU
diferentes para la subred local y para la ADSL en el router. ¿Es eso
correcto? ¿Podría dejar 1400 como MTU para la ADSL y 1500 para la
subred, de modo que no tenga que andar cambiándosela a todas las
máquinas?
Gracias.
--
Saludos,
Angel
O< ascii ribbon campaign - stop html mail and posts - www.asciiribbon.org
XPG
> En el servicio de atención al cliente me dijeron que debía modificar la
> MTU del router a 1400 (tenía 1500). Desde entonces todo va bien, pero
> tengo que poner la MTU de la tarjeta de red de todos los ordenadores de
> la subred a 1500 también.
será a 1400, ¿no?
En todo caso, si ahora va todo bien no hay necesidad de que toques nada en
los PCs...
En todo caso, en
http://www.speedguide.net/ -> Broadband -> Broadband Tools -> SG TCP/IP
Analyzer puedes ver la MTU actual de tus equipos...
Si no recuerdo mal de mis clases de redes, un host puede "ver" la MTU de los
equipos directamente conectados, y variar la suya de acuerdo a eso...
Verás que un Windows de fábrica (MTU=1500) escoge 1492 bytes al ser
conectado a un Comtrend o Xavi de Telefonica, por decir dos que he visto yo
con mis ojos (luego resulta que sigue fallando, pero bueno, ese es otro
tema).
> Ayer leí en otro grupo de Usenet que alguien tenía valores de MTU
> diferentes para la subred local y para la ADSL en el router. ¿Es eso
> correcto? ¿Podría dejar 1400 como MTU para la ADSL y 1500 para la
> subred, de modo que no tenga que andar cambiándosela a todas las
> máquinas?
¿en qué interfaz del 3Com has cambiado la MTU?
es posible que al cambiarla en la WAN se haya modificado también en la LAN,
pues no tiene mucho sentido tenerlas distintas...
Es que como dices que ahora va todo bien, posiblemente no tengas que tocar
nada más...
En todo caso, Windows viene con "MTU Discovery" activado, así que si la MTU
no se ajustó en los equipos, tienes todo funcionando porque Windows
reintenta enviar paquetes más pequeños si es informado de que es demasiado
grande...
Angel
>
>> En el servicio de atención al cliente me dijeron que debía modificar la
>> MTU del router a 1400 (tenía 1500). Desde entonces todo va bien, pero
>> tengo que poner la MTU de la tarjeta de red de todos los ordenadores de
>> la subred a 1500 también.
>
> será a 1400, ¿no?
A 1400, por supuesto.
> En todo caso, si ahora va todo bien no hay necesidad de que toques nada en
> los PCs...
Es un coñazo tener que cambiar la MTU cada vez que uso un nuevo
ordenador (portátil o no) a la red.
> Verás que un Windows de fábrica (MTU=1500) escoge 1492 bytes al ser
No utilizo ese sistema operativo en ninguno de mis servidores, portátiles,
ni estaciones de trabajo.
> conectado a un Comtrend o Xavi de Telefonica, por decir dos que he visto yo
> con mis ojos (luego resulta que sigue fallando, pero bueno, ese es otro
> tema).
Bueno, no me sorprende que falle, por eso no lo uso, entre otras cosas. :-)
> ¿en qué interfaz del 3Com has cambiado la MTU?
En "Internet", que es como se llama la interfaz externa en el 3Com812.
> es posible que al cambiarla en la WAN se haya modificado también en la LAN,
> pues no tiene mucho sentido tenerlas distintas...
¿No lo tiene? Al ver en otro post que decían que era perfectamente
normal que fuesen distintas es cuando me interesé por el tema, ya que ya
me había resignado a tener que cambiar la MTU en cada máquina cada vez.
> Es que como dices que ahora va todo bien, posiblemente no tengas que tocar
> nada más...
Decía que funcionan las cosas que dejaron de funcionar al cambiar de red
(recibo el correo electrónico que dejé de poder recibir con fetchmail,
puedo envíar y recibir ficheros por scp y rsync).
> En todo caso, Windows viene con "MTU Discovery" activado, así que si la MTU
> no se ajustó en los equipos, tienes todo funcionando porque Windows
> reintenta enviar paquetes más pequeños si es informado de que es demasiado
> grande...
No, tengo todo funcionando por lo que dije en mi post original:
1. Me ayudaron a cambiar la MTU en el router; y
2. Me dijeron que tenía que cambiarla en el PC (con un programa para
WinSlow, claro) y yo la cambio en la tarjeta de red de cada máquina que
conecto a la subred.
--
Saludos,
Angel
XPG
>> Verás que un Windows de fábrica (MTU=1500) escoge 1492 bytes al ser
>
> No utilizo ese sistema operativo en ninguno de mis servidores, portátiles,
> ni estaciones de trabajo.
Linux, por ejemplo, hace lo mismo que Windows más o menos, y me imagino que
cualquier otro S.O., es decir MTU a 1500 y MTU Discovery habilitado...
> ¿No lo tiene? Al ver en otro post que decían que era perfectamente
> normal que fuesen distintas es cuando me interesé por el tema, ya que ya
> me había resignado a tener que cambiar la MTU en cada máquina cada vez.
Es normal, sí, pero no tiene demasiado sentido estar reajustando el tamaño
ahí...
> No, tengo todo funcionando por lo que dije en mi post original:
> 1. Me ayudaron a cambiar la MTU en el router; y
> 2. Me dijeron que tenía que cambiarla en el PC (con un programa para
> WinSlow, claro) y yo la cambio en la tarjeta de red de cada máquina que
> conecto a la subred.
???
1º. El cambio de MTU se hace para cada sistema operativo: los cambios hechos
en Windows no deberían afectar a Linux, Mac, o lo que sea... Para comprobar
la MTU en cada S.O. puedes ir a la web que nombré antes.
2º. Me extraña que necesites hacer esos dos puntos obligatoriamente. Si
cambias la MTU del equipo a 1400, a partir de ahí todos los paquetes saldrán
de él con ese tamaño máximo, así que no sería necesario el cambio en el
router. Yo creo que desactivas eso en el router y todo seguirá igual.
Si el tenerlo en el router influye entonces es que el cambio en la interfaz
"Internet" se ha propagado a la ethernet y supongo que luego al resto de la
red.
Las soluciones obvias para no tener que tocar la MTU en cada equipo son dos:
1. Modificar la MTU de la interfaz Ethernet del 3Com. Este cambio deberían
"verlo" los equipos directamente conectados a él y actuar en consecuencia.
2. Ajustar el MSS (a 1360 !!) de los paquetes TCP en cualquiera de la
interfaces del 3Com. Esto sólo afectaría al tráfico TCP, pero apuesto a que
no necesitas más que eso...
El problema es que buscando por MTU y MSS en el manual del CLI del 3Com no
encuentro tales opciones en ese router.
La otra opción que se me ocurre es que lo dejes en manos del PathMTU
Discovery, pero con la configuración actual ya debería ser suficiente y no
parece que esté funcionando. Para Linux (Debian sobre todo creo), tienes el
programilla tracepath, que es como un traceroute, pero que te muestra la MTU
de los nodos por los que pasa el paquete. Si en algún punto "salta" el P-MTU
Discovery, verás que el tracepath muestra 2 líneas seguidas para el mismo
nodo. La idea es: tu equipo saca paquetes de 1500 bytes con el bit DF (Don't
Fragment) activado (esto es así por tener el PMTU Discovery activado), y en
cuanto se tope con un nodo con una MTU inferior (el 3Com en teoría), el
paquete es descartado por ser demasiado grande y tener el bit DF activo, y
el nodo envía un mensaje ICMP a tu equipo indicándole que debe reducir el
tamaño del paquete. Si ese mensaje llega a tu equipo (espero que no haya
nada entre el 3Com y tu PC, y que el firewall del 3Com no se cargue ese
mensaje), entonces es cuando verás que el tracepath (u otro proceso) lo
reintenta en otra línea con un tamaño de paquete inferior...
Por curiosidad, ¿un 3Com ADSL y Vodafone? Vodafone acaba de comprar
Tele2/Comunitel, pero que yo sepa no ofrecen ADSL en España todavía...
???
¿No tienes opción de probar con otro router?
Angel
> Linux, por ejemplo, hace lo mismo que Windows más o menos, y me imagino que
> cualquier otro S.O., es decir MTU a 1500 y MTU Discovery habilitado...
Pues no lo sé. En mi caso cuando arranco cualquiera de las máquinas
(FreeBSD, OpenBSD, NetBSD, Debian GNU/Linux) la MTU está a 1500. Tengo
que cambiarla a 1400 para que la red funcione correctamente.
> 1º. El cambio de MTU se hace para cada sistema operativo: los cambios hechos
> en Windows no deberían afectar a Linux, Mac, o lo que sea... Para comprobar
> la MTU en cada S.O. puedes ir a la web que nombré antes.
Sólo tengo instalado un sistema operativo por máquina (FreeBSD, OpenBSD,
NetBSD, Debian GNU/Linux).
En la única ocasión en que un portátil con el sistema imperativo
(WinSlow eXPensive) fue conectado en mi red (por una visita), sólo
consiguió conectar a la red cuando cambié la MTU del router a 1500 de
nuevo (no necesitaba enviar correo por un MTA ni mover ficheros por
SCP). En cuanto dejó de utilizarlo, tuve que volver a poner la MTU del
router en 1400 para que funcionase todo correctamente de nuevo en mis
máquinas.
> 2º. Me extraña que necesites hacer esos dos puntos obligatoriamente. Si
> cambias la MTU del equipo a 1400, a partir de ahí todos los paquetes saldrán
> de él con ese tamaño máximo, así que no sería necesario el cambio en el
> router. Yo creo que desactivas eso en el router y todo seguirá igual.
Pues es lo que me dijeron por teléfono en ya.com. Cambié la MTU del
router con sus instrucciones y las de las tarjetas de red de las
distintas máquinas con ifconfig. Sólo cambiando ambos funciona todo
correctamente.
> Si el tenerlo en el router influye entonces es que el cambio en la interfaz
> "Internet" se ha propagado a la ethernet y supongo que luego al resto de la
> red.
> Las soluciones obvias para no tener que tocar la MTU en cada equipo son dos:
> 1. Modificar la MTU de la interfaz Ethernet del 3Com. Este cambio deberían
> "verlo" los equipos directamente conectados a él y actuar en consecuencia.
Pues eso es lo que me gustaría saber y, sobre todo, si es cierto (y
cómo) que se puede poner una MTU en la interfaz ethernet del router
diferente a la de la ADSL (que, por fuerza, tiene que ser de 1400, según
los de ya.com).
> 2. Ajustar el MSS (a 1360 !!) de los paquetes TCP en cualquiera de la
> interfaces del 3Com. Esto sólo afectaría al tráfico TCP, pero apuesto a que
> no necesitas más que eso...
No sé qué es el MSS, voy a intentar buscarlo a ver.
> El problema es que buscando por MTU y MSS en el manual del CLI del 3Com no
> encuentro tales opciones en ese router.
Eso me pasa a mí. Por eso pregunté aquí, por que no veo cómo (ni
siquiera si es posible) cambiar la MTU de la interface de red del 3Com
independientemente de la de la ADSL.
> La otra opción que se me ocurre es que lo dejes en manos del PathMTU
> Discovery, pero con la configuración actual ya debería ser suficiente y no
> parece que esté funcionando. Para Linux (Debian sobre todo creo), tienes el
No lo parece, no.
> programilla tracepath, que es como un traceroute, pero que te muestra la MTU
> de los nodos por los que pasa el paquete. Si en algún punto "salta" el P-MTU
Sólo parece mostrarlo para la interface local. Igual hay algún parámetro
que lo modifica... miraré a ver:
- Con MTU = 1400:
$ tracepath www.ya.com
1: 192.168.0.26 (192.168.0.26) 0.119ms pmtu 1400
1: 192.168.0.254 (192.168.0.254) 2.642ms
- Con MTU = 1500:
$ tracepath www.ya.com
1: 192.168.0.26 (192.168.0.26) 0.121ms pmtu 1500
1: 192.168.0.254 (192.168.0.254) 1.717ms
2: 192.168.0.254 (192.168.0.254) asymm 1 1.688ms pmtu 576
> Discovery, verás que el tracepath muestra 2 líneas seguidas para el mismo
> nodo. La idea es: tu equipo saca paquetes de 1500 bytes con el bit DF (Don't
Eso parece ocurrir (ver arriba).
> Fragment) activado (esto es así por tener el PMTU Discovery activado), y en
> cuanto se tope con un nodo con una MTU inferior (el 3Com en teoría), el
> paquete es descartado por ser demasiado grande y tener el bit DF activo, y
> el nodo envía un mensaje ICMP a tu equipo indicándole que debe reducir el
> tamaño del paquete. Si ese mensaje llega a tu equipo (espero que no haya
> nada entre el 3Com y tu PC, y que el firewall del 3Com no se cargue ese
> mensaje), entonces es cuando verás que el tracepath (u otro proceso) lo
> reintenta en otra línea con un tamaño de paquete inferior...
>
> Por curiosidad, ¿un 3Com ADSL y Vodafone? Vodafone acaba de comprar
> Tele2/Comunitel, pero que yo sepa no ofrecen ADSL en España todavía...
> ???
Es ya.com. No sé en qué estaría pensando cuando escribí el subject del
OP.
> ¿No tienes opción de probar con otro router?
Pues no tengo ningún otro, de momento, aunque no me vendría mal uno
inalámbrico ya, la verdad. ¿Me lo regalarán en ya.com si se lo pido
después de 5 ó 6 años de cliente? No creo, ¿verdad?
XPG
> En la única ocasión en que un portátil con el sistema imperativo
> (WinSlow eXPensive) fue conectado en mi red (por una visita), sólo
> consiguió conectar a la red cuando cambié la MTU del router a 1500 de
> nuevo
juer, es raro... a menos que tuviese un firewall/antivirus bloqueando
mensajes ICMP como el del router avisando a Windows de que no le valen
paquetes de 1500...
> (no necesitaba enviar correo por un MTA ni mover ficheros por
> SCP). En cuanto dejó de utilizarlo, tuve que volver a poner la MTU del
> router en 1400 para que funcionase todo correctamente de nuevo en mis
> máquinas.
eso es lo que no me cuadra...
> Pues es lo que me dijeron por teléfono en ya.com. Cambié la MTU del
> router con sus instrucciones y las de las tarjetas de red de las
> distintas máquinas con ifconfig. Sólo cambiando ambos funciona todo
> correctamente.
>
>> Si el tenerlo en el router influye entonces es que el cambio en la
>> interfaz
>> "Internet" se ha propagado a la ethernet y supongo que luego al resto de
>> la
>> red.
>
>> Las soluciones obvias para no tener que tocar la MTU en cada equipo son
>> dos:
>> 1. Modificar la MTU de la interfaz Ethernet del 3Com. Este cambio
>> deberían
>> "verlo" los equipos directamente conectados a él y actuar en
>> consecuencia.
>
> Pues eso es lo que me gustaría saber y, sobre todo, si es cierto (y
> cómo) que se puede poner una MTU en la interfaz ethernet del router
> diferente a la de la ADSL (que, por fuerza, tiene que ser de 1400, según
> los de ya.com).
>
>> 2. Ajustar el MSS (a 1360 !!) de los paquetes TCP en cualquiera de la
>> interfaces del 3Com. Esto sólo afectaría al tráfico TCP, pero apuesto a
>> que
>> no necesitas más que eso...
>
> No sé qué es el MSS, voy a intentar buscarlo a ver.
Maximum Segment Size.
Esto sí que se negocia (a diferencia de la MTU) entre ambos extremos de la
conexión al iniciar la sesión TCP. El host de origen le indica el tamaño
máximo de segmento TCP que acepta en el 1er paquete, y el host destino le
devuelve también su información (normalmente MSS=MTU-40, pues en este caso
no se incluyen las cabeceras).
Pues el caso es que hay muchos routers que permiten manipular esos paquetes
de inicio de sesión TCP para colocar en el campo MSS el valor que tú
configures en el router. Bastaría con que le configurases un valor de 1300
para que ningún paquete IP (con protocolo TCP) sobrepasase los 1340 bytes y
que pasase "holgado" por cualquier nodo con MTUs pequeñas...
>> programilla tracepath, que es como un traceroute, pero que te muestra la
>> MTU
>> de los nodos por los que pasa el paquete. Si en algún punto "salta" el
>> P-MTU
>
> Sólo parece mostrarlo para la interface local. Igual hay algún parámetro
> que lo modifica... miraré a ver:
aquí no te entiendo... si te refieres a que tracepath no muestra nada al
salir del router será por qué en algún sitio se capan los mensajes ICMP que
permiten hacer funcionar un traceroute (normalmente el proveedor, pero
asegúrate de que no sea un firewall del 3Com).
> - Con MTU = 1400:
>
> $ tracepath www.ya.com
> 1: 192.168.0.26 (192.168.0.26) 0.119ms pmtu 1400
> 1: 192.168.0.254 (192.168.0.254) 2.642ms
>
> - Con MTU = 1500:
>
> $ tracepath www.ya.com
> 1: 192.168.0.26 (192.168.0.26) 0.121ms pmtu 1500
> 1: 192.168.0.254 (192.168.0.254) 1.717ms
> 2: 192.168.0.254 (192.168.0.254) asymm 1 1.688ms pmtu 576
576!? La MTU típica de un modem RTB (lo normal es que fuese 1400). Al verlo
no me cuadraba nada con lo de que el 3Com tuviese MTU=1400, que debería ser
el valor del 2º reintento, pero es que no estoy seguro de:
1. si el mensaje ICMP "packet too big and bit DF on" incluye información del
tamaño del siguiente salto (la interfaz WAN del 3Com).
2. En caso de que si haya ese campo en el mensaje ICMP, lo más probable es
que tu S.O. esté ignorando ese campo y ponga el tamaño por defecto, o bien
el 3Com no rellene ese campo del mensaje ICMP, pero tampoco lo sé...
En todo caso, parece que el PMTU Discovery estuviera funcionando
correctamente y que la gente de Ya.com te dió una solución válida
generalmente, pues en el momento en que el S.O. recibe ese mensaje y decide
rebajar el tamaño de paquete máximo, todas las comunicaciones con ese host
destino se van a realizar con la MTU rebajada durante un determinado tiempo
(en Ubuntu creo recordar que 5 ó 15 minutos).
Paquetes de 576 bytes deberían caber sobradamente por casi cualquier nodo de
internet/Ya.com. Por eso no entiendo que no te funcione esta solución.
> Es ya.com. No sé en qué estaría pensando cuando escribí el subject del
> OP.
Eso ya me cuadra. Ya.com está migrando todo a DSLAMs Ethernet y PPPoEthernet
tiene una MTU de 1492, y de ahí vienen los problemas seguramente. A mí me
pasó también con Telefonica: no era capaz de entrar en Gmail o en la web del
banco hasta que no rebajé la MTU del Windows lo suficiente. Es curioso
porque el router (dos Xavis en dos líneas distintas) sí propagaba
correctamente el valor de MTU de 1492 a Windows, pero por alguna razón aún
no ese valor fallaba y tuve que rebajarlo un poco más...
Una posibilidad que se me ocurre (que no veo muy clara) para que no te
funcione con tus equipos tal como vienen (MTU=1500) es que Ya.com haya
implementado un ajuste de MSS en sus Ciscos grandotes para paliar el
problema (por lo visto, puede que no sea raro que un ISP haga ajustes de MSS
a 1452 cuando utilizan PPPoE), y no sé qué pasaría cuando ambos hosts
negocian hablar TCP a 1000 y pico bytes máximo y se encuentran con que hay
una MTU por el medio de 576 bytes...
Tampoco entiendo por qué el portátil con Windows necesitó cambiar la MTU del
router a 1500...
> Pues no tengo ningún otro, de momento, aunque no me vendría mal uno
> inalámbrico ya, la verdad. ¿Me lo regalarán en ya.com si se lo pido
> después de 5 ó 6 años de cliente? No creo, ¿verdad?
Ni idea. El clásico 3Com inalámbrico de Ya.com no funcionaba muy allá por lo
visto (al menos con P2P) y no tengo idea de si soporta esas configuraciones
más avanzadas...
Pero el cambio de router posiblemente sea lo más sencillo... Igual que te
dieron la "solución" para el 3Com, en Ya.com seguramente tengan otros
recursos para otros routers...?
Angel
>
>> En la única ocasión en que un portátil con el sistema imperativo
>> (WinSlow eXPensive) fue conectado en mi red (por una visita), sólo
>> consiguió conectar a la red cuando cambié la MTU del router a 1500 de
>> nuevo
>
> juer, es raro... a menos que tuviese un firewall/antivirus bloqueando
> mensajes ICMP como el del router avisando a Windows de que no le valen
> paquetes de 1500...
Pues ni idea. Mi experiencia con eXPensive es prácticamente nula. Dejé
de usar los sistemas operativos de MS allá por el 99 o 2000.
>> (no necesitaba enviar correo por un MTA ni mover ficheros por
>> SCP). En cuanto dejó de utilizarlo, tuve que volver a poner la MTU del
>> router en 1400 para que funcionase todo correctamente de nuevo en mis
>> máquinas.
>
> eso es lo que no me cuadra...
¿El qué? Puse el router a 1500 por que es muy simple de hacer, mientras
que para cambiar la MTU de XP, según me dijeron en ya.com, es necesario
descargar y utilizar un programa que lo permite. Además, prefería no
modificar para nada el portátil, ya que sólo era un uso puntual en mi
red.
>> No sé qué es el MSS, voy a intentar buscarlo a ver.
>
> Maximum Segment Size.
> [...]
Ajá, entendido. Aunque guardo tu post para releerlo de nuevo más
despacio y para futuras referencias. :-)
>> Sólo parece mostrarlo para la interface local. Igual hay algún parámetro
>> que lo modifica... miraré a ver:
>
> aquí no te entiendo... si te refieres a que tracepath no muestra nada al
> salir del router será por qué en algún sitio se capan los mensajes ICMP que
No, no, me refiero a que no aparecen más valores de MTU y, por lo tanto,
no puse más líneas de la salida del tracepath. El tracepath continua
hasta el host de destino.
>> $ tracepath www.ya.com
>> 1: 192.168.0.26 (192.168.0.26) 0.121ms pmtu 1500
>> 1: 192.168.0.254 (192.168.0.254) 1.717ms
>> 2: 192.168.0.254 (192.168.0.254) asymm 1 1.688ms pmtu 576
>
> 576!? La MTU típica de un modem RTB (lo normal es que fuese 1400). Al verlo
> no me cuadraba nada con lo de que el 3Com tuviese MTU=1400, que debería ser
> el valor del 2º reintento, pero es que no estoy seguro de:
Pues está a 1400, te lo aseguro. Luego lo miro y pongo en otro post la
salida correspondiente.
> 1. si el mensaje ICMP "packet too big and bit DF on" incluye información del
> tamaño del siguiente salto (la interfaz WAN del 3Com).
> 2. En caso de que si haya ese campo en el mensaje ICMP, lo más probable es
> que tu S.O. esté ignorando ese campo y ponga el tamaño por defecto, o bien
> el 3Com no rellene ese campo del mensaje ICMP, pero tampoco lo sé...
Pues no lo sé. Luego intento mirarlo releyendo esto a ver...
> Paquetes de 576 bytes deberían caber sobradamente por casi cualquier nodo de
> internet/Ya.com. Por eso no entiendo que no te funcione esta solución.
Esto no lo entiendo yo. ¿A qué solución te refieres?
> pasó también con Telefonica: no era capaz de entrar en Gmail o en la web del
> banco hasta que no rebajé la MTU del Windows lo suficiente. Es curioso
Lo cierto es que la cambio a mano cada vez, ya que 1) los portátiles los
uso poco en esa red y mucho en otras, donde la MTU=1500 va bien; 2) los
servidores y escritorios los enciendo muy de tarde en tarde (más de 400
días de uptime en 3 máquinas ahora mismo). Así que no he puesto la MTU
en los scripts de inicio en ninguna máquina, aún.
La verdad es que no me cuesta nada cambiarlos al arrancar, pero si
pudieran quedarse en 1500 sería más cómodo. Por eso mi interés al leer
que el router podría tener dos MTUs diferentes.
> Tampoco entiendo por qué el portátil con Windows necesitó cambiar la MTU del
> router a 1500...
Ni idea, el caso es que la persona que estaba usando el portátil me
decía «no hay internet», hasta que puse la MTU del 3Com a 1500 y me dijo
«ya hay internet». :-)
>> Pues no tengo ningún otro, de momento, aunque no me vendría mal uno
>> inalámbrico ya, la verdad. ¿Me lo regalarán en ya.com si se lo pido
>> después de 5 ó 6 años de cliente? No creo, ¿verdad?
>
> Ni idea. El clásico 3Com inalámbrico de Ya.com no funcionaba muy allá por lo
> visto (al menos con P2P) y no tengo idea de si soporta esas configuraciones
> más avanzadas.
El mío es más clásico aún, no es inalámbrico. A ver si lo cambio. :-)
> Pero el cambio de router posiblemente sea lo más sencillo... Igual que te
> dieron la "solución" para el 3Com, en Ya.com seguramente tengan otros
> recursos para otros routers...?
Pues eso.
Gracias de nuevo.
XPG
> No, no, me refiero a que no aparecen más valores de MTU y, por lo tanto,
> no puse más líneas de la salida del tracepath. El tracepath continua
> hasta el host de destino.
Ah, correcto... ese comportamiento es normal: si la línea no indica pmtu,
quiere decir que no se ha modificado con respecto a la última línea que lo
muestra (1400 para todo el trazado en el primer caso y 567 para el 2º).
Ahora, si reconfiguras la MTU del 3Com a 1500 podrías ver seguramente la
"MTU real" de Ya.com... si ves que se mantiene en 1500, por si acaso prueba
el tracepath a sitios que te fallaban, como el correo... Si te vuelve a
salir 576 bytes entonces casi seguro que es cosa del S.O. el no hacer caso
al campo "Next Hop MTU" (se supone que en este caso no es el router el punto
donde se intentaría fragmentar sino los nodos de Ya.com que no soportan
paquetes de 1500 bytes)... desde luego, Ubuntu recogía los valores correctos
de la MTU cuando yo lo probé...
Ah, una cosa: yo interpreté que los tracepaths que pusiste antes, eran con
MTU=1400 y MTU=1500 EN EL S.O., y con 1400 siempre en el 3Com... Creo que
interpreté bien porque la 1ª línea del 1er tracepath ya va a 1400.
> Pues está a 1400, te lo aseguro. Luego lo miro y pongo en otro post la
> salida correspondiente.
>
>> 1. si el mensaje ICMP "packet too big and bit DF on" incluye información
>> del
>> tamaño del siguiente salto (la interfaz WAN del 3Com).
>> 2. En caso de que si haya ese campo en el mensaje ICMP, lo más probable
>> es
>> que tu S.O. esté ignorando ese campo y ponga el tamaño por defecto, o
>> bien
>> el 3Com no rellene ese campo del mensaje ICMP, pero tampoco lo sé...
>
> Pues no lo sé. Luego intento mirarlo releyendo esto a ver...
He revisado el antiguo libro de redes de la facultad (TCP/IP Illustrated) y
viene a decir que el campo del mensaje ICMP donde debe indicarse la MTU del
siguiente salto existe, pero que en implementaciones antiguas no se
utilizaba muchas veces...
El mensaje ICMP es el Type 3 Code 4: "Fragmentation needed but DF set".
>> Paquetes de 576 bytes deberían caber sobradamente por casi cualquier nodo
>> de
>> internet/Ya.com. Por eso no entiendo que no te funcione esta solución.
>
> Esto no lo entiendo yo. ¿A qué solución te refieres?
La del P-MTU Discovery implementada por la gran mayoría de S.O.s.
Recalco: el S.O. envía el paquete IP con el bit DF activado y si hay algún
nodo por el que no "cabe", entonces se descarta y se devuelve el mensaje
ICMP (teóricamente con la información del tamaño adecuado) al nodo que envió
el paquete para que lo retransmita con un tamaño más pequeño para que no
haya que fragmentarlo.
Tu S.O. recibe claramente el mensaje ICMP (en este caso el mensaje viene del
router, pero lo habitual es que provenga de "internet" si no hubieses
modificado la MTU del 3Com) porque reacciona correctamente rebajando a 576
el tamaño del siguiente intento (debería hacerlo a 1400 pero bueno, cuanto
más pequeño mejor). Por eso no le encuentro sentido a que no funcione
simplemente con el cambio en el 3Com.
Pero ya te digo que yo por si acaso probaría a deshabilitar el firewall del
3Com, por si está haciendo algo con esos mensajes ICMP que provienen de
fuera, aunque a priori no tiene sentido porque 576 es de sobra pequeño...
Creo que habría que empezar a analizar con Ethereal o similar qué está
pasando...
Por ejemplo, filtrar los paquetes SYN del inicio de conexión TCP y comprobar
qué MSS están ¿negociando?... en el post anterior dije negociar para denotar
que no es lo mismo qué sucede con la MTU (que no sé cómo llamarlo), pero
tampoco es una negociación pues no se elige el MSS más bajo de los dos, sino
que en un sentido se utiliza el MSS máximo indicado por un nodo, y en el
otro sentido puede haber otro MSS distinto (optimizando un poco más la
conexión).
El campo MSS sólo existe en el primer paquete de la conexión TCP (paquete
SYN) y en el 2º paquete, que es la respuesta del otro host (paquete
SYN-ACK). Ya digo que lo ideal sería un router que pueda manipular ese campo
de los paquetes SYN.
> Lo cierto es que la cambio a mano cada vez, ya que 1) los portátiles los
> uso poco en esa red y mucho en otras, donde la MTU=1500 va bien;
No deberías preocuparte por utilizar una MTU demasiado baja!
Con MTU=1400 vas a funcionar igualmente en otras redes. La única diferencia
será de rendimiento: cuando haya transferencias con muchos paquetes seguidos
a 1400 perderás un minimísimo porcentaje de velocidad (dudo que lo notes).
Y con matices, porque con MTUs de 1500 te arriesgas innecesariamente a
fragmentación en nodos típicos con MTUs de 1492: dividir un paquete de 1500
en dos paquetes (uno grande y otro pequeño) es claramente mucho peor que
enviar 1 paquete de 1400.
De arriesgarte para conseguir una mayor velocidad, casi aconsejaría 1492
antes que 1500...
> El mío es más clásico aún, no es inalámbrico. A ver si lo cambio. :-)
Pues yo lo intentaría con Ya.com, a ver si amenazando baja a los comerciales
se portan...
Si buscas en google por el 3Com inalámbrico de Ya.com, parece que algunos de
los firmwares compatibles traen cosas para modificar MTU por ejemplo...
XPG
> Tu S.O. recibe claramente el mensaje ICMP ...
> Por eso no le encuentro sentido a que no funcione simplemente con el
> cambio en el 3Com.
He estado haciendo pruebas con mi router (un cutre SpeedTouch 530v6) y hay
varios errores en todo lo que te he dicho, por ejemplo, lo que acabo de
quotear. El Path MTU Discovery queda comprobado que funciona EN UN SENTIDO!
Cuando es tu ordenador el que envía paquetes demasiado grandes, queda claro
que el mensaje adecuado llega desde el router al PC, pero no sabemos nada
sobre si un servidor web, FTP, etc es informado correctamente de que está
enviando paquetes demasiado grandes a tu equipo, que es el escenario
habitual (el cliente solicita información y el servidor le da un montón de
paquetes grandes).
Por eso puede ser normal que necesites cambiar la MTU de tus equipos, aunque
la hayas cambiado en el router.
> Pero ya te digo que yo por si acaso probaría a deshabilitar el firewall
> del 3Com, por si está haciendo algo con esos mensajes ICMP que provienen
> de fuera, aunque a priori no tiene sentido porque 576 es de sobra
> pequeño...
Otra confusión mía es que estaba pensando en que una conexión TCP se
reintentaría con un MSS válido ya desde el "principio" tal como el
tracepath, pero obviamente los paquetes SYN son pequeños y la conexión TCP
se establece "negociando" MSS grandes en ambos sentidos... Sólo "saltaría"
el P-MTU cuando durante la sesión TCP hubiese un paquete demasiado grande.
> Por ejemplo, filtrar los paquetes SYN del inicio de conexión TCP y
> comprobar qué MSS están ¿negociando?... en el post anterior dije negociar
> para denotar que no es lo mismo qué sucede con la MTU (que no sé cómo
> llamarlo), pero tampoco es una negociación pues no se elige el MSS más
> bajo de los dos, sino que en un sentido se utiliza el MSS máximo indicado
> por un nodo, y en el otro sentido puede haber otro MSS distinto
> (optimizando un poco más la conexión).
Como estaba aburrido, también probé esto con Ethereal (a ver si aprendo a
manejarlo un poco) y en la práctica es como si negociasen el tamaño más
pequeño de los dos MSSs.
Aunque el MSS sólo indica el tamaño máximo de segmento que puede recibir un
host, a la hora de enviar lo hace con el tamaño correspondiente a la MTU
(MSS+40) o con el MSS que le envía el otro extremo, dependiendo de cuál de
los dos sea más pequeño (para evitar la fragmentación). Vamos, que en la
práctica, en la mayoría de ocasiones, una sesión TCP va a ser con un tamaño
máximo de paquete igual en ambos sentidos y equivalente al más pequeño de
los dos MSS intercambiados.
> El campo MSS sólo existe en el primer paquete de la conexión TCP (paquete
> SYN) y en el 2º paquete, que es la respuesta del otro host (paquete
> SYN-ACK). Ya digo que lo ideal sería un router que pueda manipular ese
> campo de los paquetes SYN.
Mi SpeedTouch hace esto y lo llama MSSclamping: comprueba el campo MSS del
paquete SYN y si es demasiado grande, lo sobreescribe con el valor MTU (de
interfaz Internet) - 40.
El MSS clamping también se llama así en muchos routers, e incluso en
iptables creo, por si tienes un firewall de ese estilo por el medio.
Otra cosa obvia que te indiqué mal, es que esa página de speedguide.net te
da la MTU del S.O. Claramente, tal como pone la página, te devuelve el valor
estimado del Path MTU para esa conexión, y creo que lo hace precisamente
comprobando el campo MSS de la conexión TCP. No puedo confirmarlo, ya que si
deshabilito el mssclamping en el router (esperando ver 1500 en vez de los
1492 de mi conexión PPPoE), la página no carga... :-P
Mi router:
=>ip iflist
Interface Group MTU RX TX Admin Oper HW-address
0 loop local 65535 631510 55039 UP [UP]
00:14:7f:50:bb:04
1 Internet wan 1492 31229521 26344224 UP UP
2 LocalNetwork lan 1500 26669447 31565465 UP [UP]
00:14:7f:50:bb:04
=>
Lo que sigo sin entender es la razón por la que necesitas rebajar la MTU en
el router a 1400. Debería dar igual una vez que lo has hecho en el equipo y
así lo he comprobado con mi conexión.
Lo que tampoco ví que funcionase es cambiar la MTU de la interfaz LAN del
router.... Si la pongo a 1400, los equipos siguen intentando sacar paquetes
a 1500, tal como está configurado en el S.O.