Instalación de BGP Peering/subred en la tabla de enrutamiento

Descripción

Hechos:

– BGP puede utilizarse como protocolo de enrutamiento entre sistemas autónomos o dentro de ellos.

– eBGP para Inter, e iBGP para Intra.

– eBGP AD es 200, iBGP AD es 20.

– BGP es un protocolo de vector distancia.

– BGP no utiliza la multidifusión o la difusión en el descubrimiento de pares.

– BGP requiere definir manualmente lo que se quiere – esto incluye el peering de vecinos.

– BGP es un protocolo de capa de aplicación, utiliza TCP 179 (cualquiera de los pares puede actuar como servidor).

– BGP utiliza «atributos de ruta» para seleccionar la mejor ruta al destino.

– El peer de BGP no tiene que estar directamente conectado (pero ambos peers deben tener accesibilidad el uno al otro, ya sea a través del enrutamiento estático o de los protocolos de enrutamiento IGP.

– La función principal de BGP es intercambiar NLRI (Network Layer Reachability Information) con otro router BGP con el que está haciendo peering, utilizando actualizaciones.

– El NLRI se compone de «prefijo» y «longitud». El prefijo es la dirección de red, la longitud es la máscara de red, ejemplo de NLRI: /24, 10.0.0, /16, 10.0, /8, 10.

– Tipos de mensajes BGP: Open, Keep-alive, Notification & Update.

– Estados BGP: tiene 6 estados – IDLE, CONNECT, ACTIVE, OPEN SENT, OPEN CONFIRM, ESTABLISHED. Estos estados pueden ser útiles en la resolución de problemas por los que el peering de BGP ha fallado.

Alcance

FortiGate v6.2.

FortiGate v6.4.

FortiGate v7.0.

FortiGate v7.2.

Solución

Escenario 1: Problema de peering BGP.

La razón para desplegar BGP es intercambiar NLRI con los otros peers BGP.

Pero esto no ocurrirá hasta que el estado de BGP esté en ESTABLISHED.

Aunque hay veces que el BGP está en estado ESTABLISHED y aún así NO enviará las rutas esperadas a los peers, esto es porque no se cumplen otras condiciones.

Cosas a comprobar:

1) ¿Se puede acceder al par?

Es posible hacer un ping a la IP de peering remota, que se abastece con la IP de peering local, para asegurar la alcanzabilidad L3.

2) Asegúrese de que el TCP 179 no está bloqueado por el Firewall en algún lugar del medio.

3) Asegúrese de que el peer NO está configurado con una dirección IP incorrecta.

4) Asegúrese de NO configurar una IP incorrecta en la configuración del peering.

5) Asegúrese de que el AS está bien configurado. Si un FortiGate está configurado para esperar un peer del AS ‘YY’, pero mantiene recibiendo peticiones de peering del AS ‘ZZ’, no hará peering.

6) Asegúrese de que la contraseña coincide en ambos extremos si se utiliza una.

Escenario 2: La red/subred no llegó a la tabla de enrutamiento.

Cosas a comprobar:

1) AS_PATH contiene el AS local:

– BGP no instalará subredes que contengan su propio AS, esto significa que la ruta se originó en este AS, o ha atravesado este AS antes (tipo de bucles).

2) La política de entrada denegó la subred/ruta.

– Compruebe el mapa de ruta de entrada y asegúrese de que no es el que bloquea la(s) subred(es).

3) NEXT_HOP no es alcanzable por el router BGP.

– Si el siguiente salto para alcanzar dicho NLRI está caído o no es accesible por el router BGP, no sirve de nada instalar la subred en la tabla de enrutamiento, ya que no será útil por el camino.

Asegúrese de que la IP del siguiente salto es accesible desde el enrutador BGP que se está solucionando, ya que esta podría ser la razón por la que la ruta no llega a la tabla de enrutamiento.

4) La sincronización está activada.

– Si la sincronización está habilitada en el FortiGate y la subred no es conocida por un IGP, la ruta no se instalará en la tabla de enrutamiento.

Es posible desactivar la sincronización para resolver esto.

También hay que tener en cuenta que en FortiGate, la sincronización estaba deshabilitada por defecto.