[Script Mikrotik] Aviso max-prefix-limit en sesiones peering bgp

Es importante tener controlado las sesiones de peering. Tenemos que tener cuidado para que no puedan inundar rutas por una sesión peering de rutas privadas. Veremos que es max-prefix-limit en Mikrotik y como usarlo.

¿Qué es el max-prefix-limit?

En una sesión de peering BGP recibimos un número de rutas. El total de las rutas debe ser conocido o por lo menos aproximado, y tenemos que impedir que nos puedan inundar una sesión de peering con rutas que no corresponderían que llegasen por ahí. Para impedirlo establecemos un max-prefix-limit que es el máximo número de rutas que permitimos recibir por ese peering. En caso de sobrepasar ese número de rutas, automáticamente la sesión de peering caería para protegernos. Como vemos es un parámetro importante y tenemos que tenerlo controlado.

¿Cómo obtener el número de rutas?

Lógicamente lo más fiable es pedirle al otro lado del peering el número de rutas que nos van a enviar. También tenemos la opción de establecer la sesión, ver las rutas que recibimos y dar un margen. Si por ejemplo recibimos 40 rutas, podemos poner un límite de 120 ya que sería muy extraño recibir más sin previo aviso. Lógicamente si recibmos 40 no vamos a limitarlos a 41 porque no tendríamos opción a crecimiento sin aviso.

Otra opción es consultarlo en la web de peeringDB. Introduciendo el AS o el nombre, podemos ver la información que ese AS ha proporcionado.

¿Qué es max-prefix-restart-time?

Como he comentado anteriormente, en caso de sobrepasar el número de rutas, la sesión se desconecta.

El problema es que tendríamos que volver a levantar manualmente la ruta. Para evitar estas molestias, ya que podríamos estar horas con las sesiones caídas, existe le parámetro max-prefix-restart-time. Lo que hace es en caso de que la sesión fuera desactivada por este motivo, pasado el tiempo especificado vuelva a intentar levantarlo. Con esto nos aseguramos que cuando el problema sea resuelto la sesión volverá a levantar.

Configuración

add in-filter=Filtro_IN max-prefix-limit=100 max-prefix-restart-time=5m name=Peering_Alferez out-filter=Filtro_OUT remote-address=172.17.0.50 remote-as=65535

¿Cómo controlarlo?

En otros operadores como Cisco, nos da la opción de avisarnos en caso de que la ruta supere un % sobre el total. Lamentáblemente Mikrotik no da esta opción y me tocó diseñar un script que solventara esta funcionalidad.

El Script

# Script para controlar el max-prefix-limit
# en las sesiones peering.
# www.alferez.es

:local correo "TUMAIL@DOMINIO.COM";
/routing bgp peer
:foreach i in=[find state=established ] do={  
     :local nombre "$[get $i name]"
     :local maximo "$[get $i max-prefix-limit]"
     :local limite ($maximo * 80 / 100)
     :local recibidas "$[get $i prefix-count]"
     :if ($recibidas > $limite) do={
         /tool e-mail send to=$correo subject=([/system identity get name]." PRECAUCION: Peering BGP con $nombre al limite") body="El peering con $nombre tiene un limite de $maximo rutas y esta recibiendo $recibidas, por lo que supera ya el 80% de las rutas permitidas y tarde o temprano fallara."
         :log info "WARNING: BGP Peer $nombre has exceeded 80% of max-prefix-limit. Mail sent.";
     }
}

La explicación

  • Lo primero es definir la cuenta de correo donde nos va a notificar.
  • Recorremos todas las sesiones BGP que estén están established.
  • En cada sesión se saca el nombre, el máximo y el límite.
  • Se calcula el valor del 80% del max-prefix-limit.
  • Si las recibidas superan ese 80% se envía un correo electrónico y se anota en el log.

La Programación

Lógicamente un script aislado no sirve para nada si no ponemos un scheduler en nuestro mikrotik que pase repetidas veces comprobando las rutas. A mi entender no es necesario que ese check se realice más de 1 vez al día, pero eso queda a elección de cada uno.

Buenas prácticas

  • Configurar a todos excepto a los Operadores de Tránsito un max-prefix-limit.
  • Establecer un max-prefix-restart-time no inferior a 5m porque podríamos ocasionar un bloqueo.
  • Activarlo a los peering, incluidos los Route Server de los puntos neutros como ESpanix.