BGP es un protocolo de puerta de enlace exterior estandarizado diseñado para intercambiar información de enrutamiento y alcanzabilidad entre sistemas autónomos (AS) en Internet.
Basado en tus configuraciones y aprovechando la información de enrutamiento BGP, la Nube de Cato puede tomar decisiones de enrutamiento en tiempo real informadas sin que se te requiera configurar manualmente múltiples rutas estáticas y/o tomar acciones. Esto permite un soporte mejorado para escenarios como conexión directa y/o configuración activa-activa en AWS, recuperación ante desastres (DR) con IPs virtuales, integración con sistemas autónomos (AS) dentro de los sitios, y mayor flexibilidad en despliegues graduales.
Esta sección describe los componentes BGP de Cato (incluyendo objetos globales), y cómo está diseñado y funciona el soporte de Cato para BGP.
El soporte BGP de Cato se compone de tres componentes principales: vecinos BGP, rangos dinámicos y rangos flotantes.
Nota
Nota: Todos los rangos definidos en el Rango Nativo de un sitio se denominan "rangos estáticos" a lo largo de esta sección.
Se requiere conectividad para establecer sesiones BGP con vecinos. Estas son las opciones para donde un vecino BGP puede residir, y su interacción resultante con tu cuenta en la Nube de Cato.
-
BGP entre PoP de Cato Networks y un enrutador BGP dentro de un túnel - Cato anuncia rangos de cuentas, incluyendo la ruta predeterminada (0/0), y recibe rangos dinámicos, Rangos Dinámicos y Rangos Flotantes para un sitio. Por ejemplo, BGP es el modo preferido para intercambiar rutas en una conexión IPSec de Amazon AWS.
-
BGP entre la Nube de Cato y un router BGP que reside en el enlace LAN / Alt. Enlace WAN - Cato puede comunicarse con un vecino BGP sobre rangos establecidos en el socket: rangos directos, rangos nativos, o rangos VLAN.
Las sesiones BGP solo se pueden establecer sobre rangos enrutados siempre y cuando todos los rangos tengan el mismo siguiente salto que el par BGP.
Nota
Notas:
-
Esta opción no depende del establecimiento de un túnel.
-
Cato asume que todas las conexiones BGP son "next-hop-self": el vecino siempre es el siguiente salto seleccionado por Cato, y Cato anuncia la IP de su vecino como el siguiente salto para todas las rutas anunciadas.
-
Cuando BGP está en el Alt. WAN, usualmente recibe rangos de otros sitios (todos los otros sitios que son alcanzables vía el Alt. Enlace WAN). Cato filtra estos rangos antes de considerar los rangos dinámicos y flotantes.
-
Cuando un Socket se desconecta de la Nube de Cato, todos los rangos de otros sitios se retiran. Esto permite mantener la alcanzabilidad en caso de que el par BGP tenga un camino secundario que pueda ser utilizado alternativamente como siguiente salto si se desconecta temporalmente de la Nube de Cato. (Soportado desde la Versión 17.0 de Socket y superior)
Para más información sobre cómo configurar un vecino BGP, consulta Definición de Vecinos BGP.
Hay varias etapas para establecer la conexión BGP. Dependiendo de tu tipo de conexión, las conexiones BGP se establecen de la siguiente manera:
-
Se inicia una sesión TCP inicial. Si la sesión TCP no puede establecerse, se programa un intento cada 30 segundos hasta que la sesión se establece exitosamente
-
Se inicia una sesión BGP inmediatamente después de que se establece la sesión TCP
-
Si la sesión BGP no puede establecerse, se programa un intento cada 15 segundos.
-
Si una sesión BGP se termina después de haberse establecido, el siguiente intento se programa cada 1 segundo
Los rangos dinámicos son rangos IP que se aprenden dinámicamente por Cato de un vecino BGP. Una vez aceptados por Cato, se propagan a lo largo de una cuenta y se vuelven accesibles a través de ese vecino desde cualquier parte de la red.
Nota
Nota: Dado que los rangos dinámicos se aprende dinámicamente del vecino BGP y no se pueden configurar como objetos globales en la Aplicación de Gestión de Cato, no se pueden usar explícitamente en las reglas de red y/o seguridad, y por lo tanto se comportan según la política del sitio en el que residen.
Los rangos flotantes son rangos IP globales que no están conectados a un sitio específico, pero pueden aprenderse desde cualquier sitio con un vecino BGP. Por ejemplo, en un escenario de Recuperación ante Desastres (DR), muchas aplicaciones (como VMware NSX) pueden mover servidores de una ubicación a otra manteniendo sus direcciones IP. En estos casos, BGP ayuda a actualizar los objetos de red restantes y anuncia dónde residen ahora estos servidores.
Los rangos flotantes se definen como objetos globales. Los Rangos Flotantes no están asociados con un Sitio en particular y deben definirse en reglas de Seguridad o Red (la asociación de Sitio puede cambiar dinámicamente). Puedes aprovechar la definición del objeto global para crear explícitamente reglas de red y/o seguridad según los requisitos de política de tu organización.
Para que un rango dinámico BGP herede la política de seguridad o red para un rango flotante, debe coincidir exactamente con el rango flotante. Por ejemplo, si el rango dinámico BGP es 192.168.1.0/24 y el rango flotante se define como 192.168.1.1/32, entonces no hay conexión entre ellos y el rango dinámico BGP no hereda las políticas del rango flotante.
Nota
Nota: Los Rangos Flotantes no pueden superponerse con rangos estáticos.
El vecino BGP en la Nube de Cato está conectado con un PoP de Cato o con la conexión de sitio. La conexión de sitio puede ser un Socket o un túnel IPsec. Cuando la Nube de Cato recibe una ruta BGP nueva o actualizada, siempre se sincroniza con la red WAN global (conexiones de sitio y PoPs).
Cuando se recibe una ruta BGP, Cato la asocia con el objeto relevante de la siguiente manera:
-
Los rangos IP definidos como rangos flotantes se asocian con sus objetos definidos y se adhieren a todas las políticas de red y seguridad asignadas a los objetos.
-
Todos los demás rangos IP se consideran como rangos dinámicos y se adhieren a todas las políticas de red y seguridad asignadas al sitio.
Las rutas pueden retirarse a través de un mensaje BGP o mediante la desconexión de un vecino (CEASE o físicamente), y la Nube de Cato propaga inmediatamente el retiro.
Los sitios en Cato, como sitios IPSec o Socket, pueden tener múltiples túneles conectados para enviar tráfico sobre la LAN o el Internet. Si se conectan múltiples túneles, su prioridad se basa en la calidad del enlace y otros factores. La pantalla de Tabla de Enrutamiento (Monitoreo > Tabla de Enrutamiento) muestra la Métrica del Túnel para las rutas. Este es el valor que Cato asigna para asegurar que el tráfico se envíe por el mejor túnel. Cuanto más bajo sea el valor de Métrica de Túnel, mayor será la prioridad de este túnel. Por ejemplo, en un despliegue de Alta Disponibilidad del Socket el túnel activo puede tener una métrica de 5 y el túnel del socket pasivo tiene una métrica de 10.
A diferencia de los rangos estáticos regulares, BGP permite múltiples rutas que pueden superponerse o incluso duplicarse en partes de tu red. Entonces, ¿cómo decide la Nube de Cato por qué camino enrutar los paquetes?
Cuando se pueden aplicar múltiples rutas a una dirección IP de destino, las decisiones de enrutamiento se realizarán según las siguientes prioridades:
-
Se seleccionan rutas más específicas sobre rutas menos específicas (/24 sobre /22 y así sucesivamente).
-
El orden de preferencia para los siguientes rangos IP:
-
Rangos estáticos
-
Rangos flotantes
-
Rangos dinámicos
-
-
Se prefiere la Métrica de Vecino más baja.
-
Se prefiere la ruta AS-PATH más corta.
-
Se prefiere la Métrica de Túnel más baja.
-
Se prefiere el BGP MED (Multi-Exit-Discriminator) menor del ID de la ruta.
Dado que Cato Cloud realiza enrutamiento basado en políticas de capa 7, la necesidad de evitar rutas asimétricas es decisiva Por esa razón, la prioridad de la ruta es universal dentro de la misma cuenta: en otras palabras, se seleccionará un único origen desde cualquier ubicación dentro de la red de la Nube de Cato.
Cuando las rutas son aceptadas por un vecino BGP, la información asociada con ellas (ruta AS, comunidades BGP) se conserva. Cuando los rangos dinámicos se anuncian a los vecinos BGP, la Ruta AS se anexará con el número AS de la Nube de Cato (como es usual con BGP).
Cato propaga transparentemente todos los Atributos de Ruta marcados con la bandera Transitiva (RFC 4271), incluyendo las comunidades.
Los rangos de cuentas (estáticos) son anunciados con el ASN del vecino del Socket de Cato como ASN de origen (Número de Sistema Autónomo - ver abajo Asignación de un ASN a un Vecino).
Para más sobre resúmenes de rutas BGP, consulta Trabajando con Resúmenes de Rutas BGP.
Nota
Nota: Algunas comunidades bien conocidas no son propagadas por Cato a vecinos BGP en salida, como no-export.
El ASN es un número entre 64.512 – 65.534 (ASN privado), que representa la entidad de enrutamiento que establece la comunicación El ASN predeterminado de Cato Networks es 64.515
La Nube de Cato soporta eBGP, por lo que un Vecino BGP debe tener un ASN diferente al lado de la Nube de Cato.
Nota
Nota: Es una buena práctica usar globalmente un único ASN para representar el lado de la comunicación de la Nube de Cato a través de todas las sesiones BGP. Si estás considerando usar diferentes ASN en diferentes vecinos, por favor contacta a Soporte.
Cómo se Previenen los Bucles
Cuando Cato recibe una ruta, el camino AS se escanea para encontrar el ASN del vecino de la Nube de Cato. Cualquier ruta que contenga este ASN será descartada. Ten en cuenta que el vecino solo escanea el ASN del vecino actual.
Nota
Nota: Cato no soporta Reinicio Gradual.
Los rangos dinámicos se asocian automáticamente con el sitio desde el cual se recibió la ruta y heredan todos los grupos de política, políticas de red y seguridad del sitio. Los rangos flotantes se definen globalmente y las reglas de seguridad se aplican a ellos directamente o asociándolos con grupos de política.
¿Qué tipos de conexión de sitio puedo usar?
-
Cato soporta BGP para sitios que usan Sockets, vSockets y sitios IPsec (IPsec IKEv1 iniciado por Cato, IPsec IKEv2). Además, se requiere conectividad con sus routers BGP existentes.
¿Cómo establecerá el vecino BGP la sesión BGP con Cato?
-
Las sesiones BGP requieren conectividad establecida entre un vecino BGP y un sitio a través de rutas locales en sockets o a través de un túnel IPsec.
-
Para el despliegue de Cato Socket, solo se pueden usar rangos directos, VLAN y rangos nativos para establecer sesiones
Las sesiones BGP solo pueden establecerse sobre rangos enrutados siempre que todos los rangos tengan el mismo siguiente salto que el peer BGP.
Configuración de sesiones BGP sobre enlaces WAN alternativos
En Cato, los destinos WAN alternativos incluyen dos redes (potencialmente etiquetadas con VLAN): pública y privada. Un vecino BGP debe estar dentro de una de esas dos redes, y el vecino BGP en el lado de Cato Cloud será la IP de Cato correspondiente para ese rango.
Al definir una sesión BGP sobre una interfaz pública, también puede realizar NAT de Fuente en el tráfico que pasa a través de ese enlace. Esto significa que para todo el tráfico saliente a través de ese vecino, la dirección de origen será la IP del lado de Cato.
-
Cato Cloud solo soporta IPv4.
-
Si se configuran múltiples ASN para múltiples vecinos, los ASN no serán detectados por el vecino y puede resultar en bucles.
-
Cato Cloud permite la propagación de rutas que contienen el ASN del vecino, confiando en que el vecino escanee en busca de bucles.
-
Los rangos flotantes no pueden superponerse con un rango estático.
-
Cato no soporta el reinicio gradual para la retirada de rutas.
-
Los cambios de ruta BGP (incluyendo la retirada de rutas) que son iniciados por Cato, no generan eventos.
-
Cato no realiza la resumisión de rutas.
-
Por defecto, Cato limita el número de prefijos recibidos de cada vecino BGP a 1024. Para aumentar este límite, contacte a Support.
-
BGP no es soportado para cuentas que usan traducción de rango estático. Si requiere BGP para un rango nativo traducido para un sitio Socket, por favor contacte a Support.
0 comentarios
Inicie sesión para dejar un comentario.