Qué es el flapping (y por qué es tan difícil)
Flapping es una sesión que se establece, dura poco, se cae, y se vuelve a levantar sola — en un ciclo que se repite. El cliente muchas veces ni se da cuenta de que "se cayó": solo siente micro-cortes. Y es difícil de cazar porque cuando vas a mirar, la sesión ya reconectó y todo parece normal. Sin histórico de logs, es imposible.
Por eso el primer paso no es tocar nada: es tener el histórico. Si tus routers no mandan syslog a un servidor central, empezá por ahí (te lo contamos en cómo centralizar el syslog de tus Mikrotik), porque el diagnóstico entero se apoya en leer cómo se cae la sesión.
La primera bifurcación: ¿físico o lógico?
Esta es la pregunta que ordena todo el diagnóstico. En el log de PPPoE, cómo termina la sesión te dice de qué lado buscar:
| Cómo se cae | Qué sugiere |
|---|---|
Corte "limpio": LCP terminated, timeout de keepalive, sin login previo | Físico — se cortó el medio |
| Reconexión con re-autenticación completa cada vez | Físico o corte de sesión aguas arriba |
authentication failed, rechazo de RADIUS, IP duplicada | Lógico — configuración o AAA |
Si las caídas son limpias y periódicas (la sesión muere sola por timeout, sin errores de auth), casi siempre es físico: fibra, ONU o energía. Perseguir el PPPoE en ese caso es perder días. Descartá lo físico primero.
Si apunta a físico: la fibra y la ONU
La causa número uno de flapping "limpio" en redes GPON es la potencia óptica al límite. Una ONU que recibe -27 dBm cuando debería recibir -22 dBm anda… hasta que una nube de humedad, un empalme flojo o un conector sucio la tiran por un segundo. Qué revisar:
- Potencia óptica Rx de la ONU: si está cerca del umbral de sensibilidad, ese es tu problema. Cómo monitorear la óptica de una OLT ZTE C600.
- Correlación por lote / modelo de ONU: si todas las que flapean son el mismo modelo o firmware, sospechá del equipo, no de la red. Un lote con firmware malo puede flapear aunque la óptica esté perfecta.
- Energía del cliente: micro-cortes de luz en la casa reinician la ONU. Se ve como flapping pero es eléctrico.
- Empalmes y conectores: un patch cord mal insertado degrada de a poco.
En algunas OLT (ZTE C600, por ejemplo), pedirle la potencia a la ONU por OMCI en pleno corte puede empeorar las cosas. Consultá la óptica del lado de la OLT, que es la fuente pasiva y segura.
Si apunta a lógico: MTU, keepalive y AAA
Cuando el log muestra errores de autenticación o negociación, el problema está en la config:
- MTU/MRU mal negociado: con PPPoE el overhead deja el MTU en 1492. Un MTU mal seteado rompe conexiones grandes y puede tirar la sesión. Verificá
mtuymruen el perfil PPPoE. - Keepalive agresivo: un
keepalive-timeoutmuy corto declara muerta una sesión que solo tuvo un hipo. Subilo si la red tiene jitter. - Timeout de RADIUS: si el server de AAA responde lento en hora pica, rechaza o demora logins y parece flapping masivo. Mirá la latencia al RADIUS.
- IP o sesión duplicada: dos sesiones peleando por el mismo usuario/IP se tiran mutuamente.
- CPU del BRAS al tope: un router que concentra PPPoE al 100% de CPU empieza a descartar keepalives y a tirar sesiones. Acá el flapping es un síntoma de saturación.
Cómo aislar cuando no está claro
Si el log no alcanza, aislá variables una por una:
- ¿Es un cliente o muchos? Uno solo → físico de ese cliente. Muchos de la misma zona/OLT → red o nodo. Todos → BRAS o AAA.
- ¿A qué hora? Siempre en hora pico → saturación. A cualquier hora → físico o firmware.
- Probá pasar la ONU a bridge y hacer el PPPoE desde un router del cliente: si deja de flapear, el problema estaba en la ONU.
- Cambiá la ONU por una de otro lote: si se soluciona, era el equipo.
Con nuestro servicio de NOC correlacionamos syslog, potencia óptica y capacidad, y detectamos el flapping antes de que el cliente reclame — con alerta y diagnóstico ya hecho.
Ver el servicio de NOC →