Foro
Buenas Halfway
Te aseguro que no tienes un HGU defectuoso, y que el problema es de configuración por tu lado.
En tu caso... era el Switch gestionable y tenía configurado correctamente IGMP Snoopong? El AC56u tres cuartos de lo mismo, tiene soporte para IGMP Snooping (el cual habría que habilitarlo manualmente), pero no lo tiene en modo AP, y es imperativo su uso.
Al fin una respuesta.
El IGMP snooping no es necesario si no se tiene TV, no?
En cualquier caso para descartar esto compré un switch no gestionable con IGMP Snooping y sigue sucediendo.
Ayer mismo se bloqueó todo lo que cuelga del switch y reinicié el HGU, una hora después se reinició el HGU solo...
- Theliel29-05-2020Yo probé el VDSL
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] & 1Si 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.
- Halfway29-05-2020Yo probé el VDSL
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.
- Theliel29-05-2020Yo probé el VDSL
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.