Buenas Halfway
Como he dicho otras veces, jamás me fiaría de un Switch que diga que soporta X pero no permite configurarlo. Históricamente los Switch no han soportado dicha funcionalidad cuando no eran gestionables, principalmente porque hay ajustes que son buenos/malos dependiendo de que escenarios. Con la explosión de los servicios actuales se ha convertido en algo esencial, y muchos lo han incluido en su catálogo de funcionalidades.
Pero se podría decir mucho sobre ello. Por ejemplo, muchos de ellos empiezan a implementarlo, pero solo revisiones de hardware concretas. Tampoco indicas que marca/modelo de Switch tienes.
En cualquier caso es algo relativamente sencillo de diagnosticar, solo es necesario un PC con wireshark funcionando (un analizador de paquetes), conectarlo al Switch/AP y capturar el tráfico con este filtro (filtro de captura), no de visualición:
eth.dst[0] & 1
Si todo es normal, a penas debería de capturar tráfico, si hay algo mal, no será precisamente poco lo que capturará.
Existen muchos dispositivos/software que puede generar gran cantidad de tráfico Multicast. La inmensa mayoría de congelaciones como la que esgrimes se debe casi siempre precisamente por tener un Swich/AP/Router adicional en la red, y una mala configuración con ellos. Aplica una máxima sencilla... te pasa si desconectas el Switch/AP? Posiblemente no, ergo el problema no es el HGU.
Buenas.
Al fin vamos llegando a algo...
A ver, no sé si lo que dices es razón o no para fiarse, el switch es un TP Link TL-SG105 y en sus especificaciones pone claramente que soporta IGMP SNOOPING, si no lo hace supongo que es publicidad engañosa y habría que denunciarles.
Qué otro tipo de tráficos generan multicast?
Del switch cuelga un ordenador con windows (curro) un ordenador con ubuntu (NAS) y una SmartTV.
Lo de comparar con la situación actual, sin Switch/Asus no pasaba, evidentemente la cosa se tuerce cuando conectas algo al HGU, no quita que el HGU esté mal, que se reinicie solo no lo veo muy normal aún por tema de IGMP Snooping.
Buenas Halfway
En absoluto es normal. Solo te digo donde suelen estar la mayoría de los problemas, una vez acotados se puede sacar una conclusión más clara.
Existen problemas y PROBLEMAS. Me explico. Como he dicho muchas veces lo que es fibra el funcionamiento es muy simple, diagnosticar un problema de línea es casi inmediato, las opciones son A, B o C, y además cantan muy rápido. El resto de problemas suelen ser de puertas para dentro, la gran mayoría. De ellos, de puertas para dentro, la mayoría de nuevo se deben a hardware propio. por qué?? Simple, existe un numero casi infinito de posibilidades en la red de cualquiera, montones de fabricantes con montones de dispositivos... es totalmente imposible crear un dispositivo que sea compatible de forma universal.
Por ejemplo, los equipos de Apple son famosos por causar todo tipo de incompatibilidades. Los Switch mal configurados también. Las SmarTV suelen ser un dolor. No con el Router de Movistar, en general. Llamamos problemas de compatibilidad al final a cuando un dispositivo,el que sea, no se lleva bien con otro, el que sea, con independencia de que esos dos dispositivos se lleven bien con cualquier otro dispositivo. Estos problemas son complicados de diagnosticar porque solo se dan repito cuando A+B aparecen juntos, aunque la culpa sea de A o sea de B.
La experiencia aquí es la que manda, al menos para sbaer donde mirar. Como te digo, por ejemplo, los Switch/APs/PLC son siempre los primeros en el punto de mira, porque potencialmente son los que más rápidamente te tiran la red entera, cualquiera de ellos por una mala interacción, un bug, un fallo de configuración o cualquier cosa, y te causan un loop de red o una tormenta broadcast... y adiós muy buenas.
-------------------
Dicho eso es totalmente imposible a priori decir: El problema es tal o cual. Sería arriesgado sin hacer más pruebas. Partimos de la base de que hay dos dispositivos potencialmente problemáticos. Por qué descartamos el Router a priori?? Porque el Router está instalado en millones de hogares sin problemas de dicha índole, muchas de ellas con APs y Switchs. De nuevo, no significa que el problema al final de compatibilidad sea propiciado por el Router por no hacer las cosas bien del todo y se les haya escapado alguna cosa. Poder puede ser, pero me decanto antes por otras opciones.
-------------
Dicho todo esto, de nuevo, es muy sencillo ver por lo general que afecta o que está pasando. No vas a poder capturar tráfico directamente sobre el Router de Movistar, pero si es un dispositivo el que causa el problema, sea el Switco/AP o incluso un equipo conectado a ellos, eso si es simple de ver... o al menos mucho más simple.
Congelar/bloquear un Router no es fácil, o es un bug raro de narices o es una saturación. Lo más normal es que sean saturaciones, o en caso de reinicios incluso un consumo de RAM exagerado. Si es una saturación es fácil verlo, porque rara vez es por tráfico unicast, y el tráfico multicast podemos verlo sin problema
------------
Formas de diagnosticar:
1º. Prueba error:
Se conecta el Switch sin ningún dipsositivo conectado a él, y a ver que pasa. Si funciona bien sin problemas? Se añade uno de ellos. Si con el que se ha añadido observamos que todo va bien?? Se vuelve a añadir otro.... llegará un momento en que falle. Cuando falle, se deja solo el que ha hecho que falle y el resto se quitan, y se verifica que de nuevo falla con sólo el. Ya tenemos el responsable, ahora podemos realizar otras pruebas para ver que tipo de tráfico, servicio o llo que sea está haciendo para disparar el problema, un analizador de paquetes en dicho equipo nos lo dirá todo.
2º- Prueba/error es tedioso? Analizar tráfico direcatmente
Nos conectamos directamente al Switch y a capturar tráfico. Si hay alguna anomalía en tráfico Multicast/broadcast se va a ver inmediatamente. Podría pasar que realmente la culpa fuese del tráfico Multicast pero que IGMP Snooping filtrara el tráfico a nuestro equipo analizando el tráfico, en ese caso sería más efectivo hacer prueba error, ya que tu Switch no puede hacer Port Mirror.
3º- Port Mirror.
Si el hardware que tenemos lo permite, con port mirror y capturando tráfico tenemos todo lo que pasa, cualquier problema lo vamos a ver
--------------------------
Independientemente a todo ello, respecto al Switch específicamente.
Un Switch no gestionable es un Switch que llamamos "tonto". Puede soportar las funcionalidades que quieran funcionar, pero eso no significa ni que estén habilitadas, ni que sea bueno tenerlas habilitadas.
Te pongo un ejemplo sencillo y totalmente real, para que te des cuenta el grave problema que es esto, o lo simple que puede ser.
Mi Switch es gestionable, lo configuro todo perfectamente bla bla bla. Si uso como protocolo IGMP en el Askey y en mi propio Router, si habilito IGMP Snooping en el Switch tengo obligatoriamente que deshabilitar la validación de la cabecera IP de los paquetes IGMP (opción presente en la inmensa mayoría de los Switch gestionables). Si no lo hago, si algún dispositivo conectado al Switch envía un paquete IGMP pero con algún error en la cabecera, del tipo que sea, el Switch lo bloquea, y al poco tiempo el efecto es desastroso, el propio Switch termina bloqueándose porque el dispositivo sigue enviando una y otra vez el mensaje IGMP, el cual se sigue bloqueando y ... switch saturado y se necesita reiniciar. Realmente no se queda bloqueado y todo lo que ya esté conectado a él funciona bien, pero cualquier otro equipo nuevo o ajuste... KO total. Simplemente diagnosticado el problema (aun tengo dudas del dispositivo que los envía), solo tengo que deshabilitar la validación de cabecera IP de IGMP que pasa por el Switch, y asunto arreglado, pasa de congelación total cada 12-24 horas (el Switch) a funcionar 24/7 a las mil maravillas.
Bueno, mi caso es un fallo concreto de compatibilidad entre el Switch y algún dispositivo que me hace la puñeta con paquetes IGMPv3 que no son 100% conformables según estándar. Los fabricantes no son tontos, y te aseguro que ciertas opciones las ponen por algo, porque todos conocemos que cada dispositivo es de su padre y de su madre, y siempre hay que curarse en salud y permitir ajustes finos para adecuarse al entorno de cada uno
Es solo un ejemplo para que entiendas que no es todo blanco o negro. En mi caso en concreto sé que es un equipo mío (incluso puede ser el deco de Movistar) el que envía algún paquete IGMP de vez en cuando llamémoslo "malo" que causa problemas al Switch.
---
En este foro intento ser siempre lo más claro posible y tajante. Y en muchas cosas si te puedo afirmar o negar algo al 100%. Pero en otras, y creo que entiendo un poco sobre todo esto, es muy complicado poder acertar de primeras. Y aunque suene aburrido o costoso en tiempo, es imposible replicar ciertos problemas cuando existe tal cantidad de dispositivos diferentes, y que es suficiente un solo bug o interacción "rara" para arruinarte la experiencia. Me he llegado a encontrar escenarios donde el simple echo de que un PC de sobremesa se apagaba (aunque la bios mantenía un estado energético bajo para reactivación) provocaba bloqueos en toda la red. Si se encendía el equipo o se apagaba desenchufando, la red iba perfecta. Increible, pero cierto.
Buenas Theliel.
Estaba claro que hasta que no intervinieras tú no empezaríamos a solucionar esto.
Sobre las pruebas a hacer:
1º prueba y error: el problema que veo es que no existe ningún patrón de tiempo, a veces se queda sin conexión en 1 hora después de reiniciar y a veces está 3-4 días. Y el Switch no lo tengo puesto por capricho, dicho de otra manera, el NAS necesita estar conectado por cable y el portátil del curro también, tiene un wifi insufrible.
2º ver el tráfico: hay algo en Ubuntu para esto? Tengo acceso al NAS en remoto y podría ponerle a ver el tráfico todo el tiempo que quiera. El ordenador que tengo con Windows es el del curro y no puedo instalar nada.
3º port mirror: entiendo que descartada por no soportarlo el switch.
Gracias!
Buenas Halfway
WIFI es otra cuestión siempre independiente, en los problemas WIFI prefiero no entrar por motivos obvios, para mi WIFI nunca es un problema por mal que funcione, prefiero enfocar esfuerzos sinceramente en cosas que tienen en principio solución (la que sea), WIFI...
Respecto a capturar tráfico en Linux?? por descontado, posiblemente la herramienta más extendida en el mundo para ello, famosa y eficaz es tcpdump. Es cierto que un portatil tiene la ventaja que puedes ir conectándolo a los diferentes dispositivos de forma rápida mientras que un NAS por lo general no lo mueves, pero es un buen comienzo claro.
No sé que NAS tienes... si es un equipo propio con ubuntu con software para NAS, es muy posible que tcpdump lo tenga de serie instalado, y si no en cualquier repo está. Si es un NAS de algún fabricante ya dependerá de marca/modelo. Por ejemplo con QNAP es trivial instalar Entware-ng y desde ahí instalar sin problema tcpdump. En Synology no sé bien como tienen los gestores de paquetes externos...
Usar tcpdump es simple, pero eso sí... si dices que puede pasar en 1 hora o en 10 horas, el volcado puede ser grande. Se puede analizar en tiempo real pero sería una locura, con lo que sería mejor guardar el volcado y analizarlo luego:
La sintaxis es simple, sería algo así, aunque dependerá de la interfaz de red y de la versión de tcpdump:
tcpdump -s 0 -n -i eth0 multicast or broadcast -w test.cap
En este caso eth0 sería la interfaz (aunque pude ser diferente en cada caso, se puede consultar antes con ifconfig). -s 0 especifica el tamaño del frame, lo maximiza. -n es para que no resuelva nombres. Después es el filtro, que capture el tráfico multicast y broadcast, y el último parámetro es para que escriba en un archivo.
Podría ser otro tipo de tráfico el dañino, pero por peligrosidad, el tráfico multicast/broadcast siempre es el más propenso a dar problemas, así que es un buen punto de partida. Además el tráfico multicast/broadcast llega en principio a todos los dispositivos
Buenas tardes Halfway
Disculpa por las molestias ocasionadas y damos las gracias a Theliel por la colaboración.
Indicarte que solamente damos soporte a los equipos conectados por Movistar. De todas formas, para comprobar la conexión, envíanos por privado(pincha aquí) los siguientes datos:
- Número de teléfono fijo
- Nombre, apellidos y Nif de la persona titular de la línea
- Dirección de instalación (provincia, localidad, nombre de la calle)
- Teléfono y persona de contacto, por si fuera necesario
Dejamos el hilo abierto, para que otros usuarios puedan colaborar en la configuración de tus dispositivos.
Un saludo.
Nacho.
