Banda Ancha EU

Comunidad de usuarios
de fibra, móvil y ADSL

Problemas de enrutado de MásMóvil por BGP leak de Ensinca

  • Fibra

    [Editado]

    Problemas de enrutado de MásMóvil por BGP leak de Ensinca

    Parece que ahora mismo estamos sufriendo problemas con las rutas en MásMóvil (en mi caso Yoigo). Estan cambiando cada pocos minutos para enviarlo por un operador que nunca he visto que usen.

    La cosa es que es gracioso ya que el AS por el cual están enrutando parece tan cutre que quiero pensar que este operador está publicando rutas BGP que están secuestrando el trafico de MásMóvil al este aceptarlas.

    El operador es ensinca.net (stat.ripe.net/AS202831) y me niego a creer que MásMóvil esté enrutando por ellos a cosa hecha... La cosa es que en el Stat RIPE los datos de BGP tardan un poquito en aparecer.

    Pero vamos que sea como sea de nuevo con problemas de Internet con esta gente y en el teléfono de asistencia no saben nada, te reinícian el router y se pueden conectar a el sin problemas por lo que su respuesta es "está todo bien revise sus equipos".

    screenshot-2019-05-02-at-15-29-52.pngscreenshot-2019-05-02-at-15-45-38.png

    Actualización: Ahora que he tenido un rato he revisado BGPstream y efectivamente ENSINCA ha hecho un BGP Leak hacia AS15704 (XTRA Telecom, Yoigo, MásMóvil, como queráis llamarlo) que se han comido con mucho gusto. Ojalá poder hablar con el operador de nuevo y que me vuelva a decir que son mis equipos.

    (link roto)

    (link roto)

    (link roto)

    (link roto)

    (link roto)

    (link roto)

    (link roto)

    (link roto)

    (link roto)

    (link roto)

    (link roto)

    Este tema lleva más de 6 meses inactivo. Es recomendable que abras un nuevo tema para retomar la conversación.
    • No solo "se lo comieron con papas", sino que lo publicaron a…

      No solo "se lo comieron con papas", sino que lo publicaron a su vez a todos sus peers en Espanix y DE-CIX.

      Aunque se podría hacer un filtro para sólo aceptar las rutas legítimas según lo declarado en el IRR (en el caso de España, RIPE), lo habitual es configurar un límite de prefijos para cada sesión. Es decir, si se sabe que Masmóvil anuncia habitualmente un total de 200 rutas, se configura un límite de 250 rutas y en caso de recibirse más de la cuenta, se desconecta la sesión BGP (pudiéndose reiniciar automáticamente tras el tiempo configurado, o directamente dejarla deshabilitada hasta averiguar el motivo de la "avalancha")

      Que Ensinca por un error de configuración haya publicado la tabla de rutas completas... es un error humano al configurar un router

      Que Masmovil las acepte todas, las propague en toda su red y también a sus peers... es un error "de novato", que puede llegar ser admisible en un pequeño ISP local que acaba de empezar a hacer peering y en el mundo del BGP. Pero en alguien que se supone que es "el cuarto operador"...

      • Pero en alguien que se supone que es "el cuarto operador" Le…

        Pero en alguien que se supone que es "el cuarto operador"

        Le ha pasado a TODOS, sin excepción y cuanto más grande es un operador y más puntos de peering tiene, más probabilidades de que les pase, por dos motivos principalmente, porque se suele subcontratar la instalación de esos equipos de IX y porque llega un punto en el que tener controlado todo eso y tener claras todas las interacciones de los diferentes routers es muy,muy complicado.

        Ahora ... que ya les vale ..., de las primeras cosas del manual es la configuración de los filtros en las sesiones BGP.

        • Sí, en cuanto vi que era un BGP Leak pues es algo "mas…

          Sí, en cuanto vi que era un BGP Leak pues es algo "mas común", sin embargo me parece que la reacción de la gente de redes de MM fue 0, es algo que deberían tener monitorizado ya que los anuncios BGP del operador se salía de toda norma. El problema en MM duró todo lo que duró la mala configuración de Ensinca cuando, en mi opinión, debían haber tirado la sesión BGP y las rutas que venían de ella hasta que Ensinca hubiese solucionado el problema.

          image.png

          Según tengo entendido MM opera como Open Policy lo cual hace que se traguen mas fácilmente estos leaks. De hecho hay un Working Group que lleva unos años con un draft para estos casos (tools.ietf.org/html/draft-ietf-idr-bgp-o…en-policy-05).

          Sin embargo he de decir que mi experiencia con BGP se queda en lo teórico y practicas de Cisco ya que nunca lo he llegado a usar profesionalmente, por lo que no hablo desde la barra del bar pero casi que desde la puerta sí.

          • Por desgracia ... como en muchos otros operadores, no se…

            Por desgracia ... como en muchos otros operadores, no se gastan la pasta donde deben ... se obcecan con la captación de "gallinas que entran" ... pero pasan un kilo de dedicar recursos al perro guardián que vigila el gallinero o muchas veces ni siquiera al mantenimiento del propio gallinero.

          • Buenas. En las relaciones de Peering cada peer suele tener un…

            Buenas. En las relaciones de Peering cada peer suele tener un tipo de política:

            - Open: Cualquier solicitud de peering es bienvenida, y generalmente sin coste: "A mi me interesa que todos mis contenidos lleguen lo mejor posible a los usuarios, y que mis usuarios tengan la mejor conexión posible". Es la que tiene MasMovil, Adamo, Netflix, Google
            - Selective: Se evaluará la solicitud de peering, y si se cumplen ciertos requisitos (tráfico por encima de X gbps, tener puertos redundados, etc) se establece la sesión. Se evalúa que realmente establecer la sesión va a mejorar la experiencia del usuario y la estabilidad del servicio. Es la que utiliza por ejemplo Facebook, RIOT Games, O
            - Restrictive: Generalmente no se establecen relaciones de Peering. "El que quiera cursar tráfico por mi red que pase por caja". Es lo habitual en los operadores Tier1, que solamente establecen conexiones entre ellos: Telefónica, Opentransit (Orange), Verizon, etc

            Existe una base de datos donde habitualmente cualquier operador que quiere realizar peering con otros publica sus datos: peeringdb.com

            En dicha web se puede ver que Ensinca dice que ellos publican sólamente un prefijo. Sería razonable configurar la sesión con un límite de 10 (para que si crece no haya que modificar dicho valor).

            La política de peering no influye para nada en la configuración.

            @skgsergio En la captura que adjuntas se ven 2000 prefijos... Esas son estadísticas que se actualizan cada X minutos / horas y no llegaron a captar el valor real. Publicaron Full Routing (actualmente existen unas 750.000 rutas de IPv4 a nivel mundial)

            @rbetancor Claro que todos cometemos errores, somos humanos, y aunque las máquinas no suelan cometer errores, están configuradas por humanos. Yo mismo recibí más de 600.000 prefijos desde el AS de Masmovil en la red que administro. En menos de 3 minutos lo detectamos, solucionados, y notificamos a los clientes afectados. Lo que no es de recibo es que 1h después del incidente aún siguiera sin solucionar, y el SAC pidiera a los clientes "que reinicien el router"

            • En menos de 3 minutos lo detectamos, solucionados, y…

              En menos de 3 minutos lo detectamos, solucionados, y notificamos a los clientes afectados. Lo que no es de recibo es que 1h después del incidente aún siguiera sin solucionar, y el SAC pidiera a los clientes "que reinicien el router"

              A eso se le llama tener las herramientas adecuadas y la gente adecuada al cargo y vigilando ... eso no pasa en muchos de los grandes, creeme, existe el acojone de "¿y si lo toco y la jodo mas?" ... es muyyyyyyyyyyy patético lo que ocurre en el core de algunos operadores. ¡Ojo! que también está la versión de "no me dejan tocarlo, aunque sepa arreglarlo"

              El tema SAC, es SAC ... ya sabemos todos como va, su objetivo en muchos casos, no es ayudar al cliente ... sino minimizar el tiempo que consume la llamada del cliente. Lo que en mi opinión es un craso error.