Introduction au BGP
BGP est un protocole de passerelle externe standardisé conçu pour échanger des informations de routage et de connectivité parmi les systèmes autonomes (AS) sur Internet.
Basé sur vos configurations et en exploitant les informations de routage BGP, le Cloud Cato peut prendre des décisions de routage en temps réel sans que vous ayez besoin de configurer manuellement plusieurs chemins statiques et/ou de prendre des mesures. Cela permet un support amélioré pour des scénarios tels que la connexion directe et/ou la configuration active-active dans AWS, la récupération après sinistre (DR) avec des adresses IP virtuelles, l'intégration avec des systèmes autonomes (AS) au sein des sites, et une plus grande flexibilité dans les déploiements progressifs.
Comment Cato prend-il en charge le BGP ?
Cette section décrit les composants BGP de Cato (y compris les objets globaux), et comment le support de Cato pour BGP est conçu et performant.
Composantes BGP de Cato
Le support BGP de Cato est composé de trois composantes principales : les voisins BGP, les plages dynamiques et les plages flottantes.
Remarque :
Toutes les plages définies dans la plage native d'un site sont appelées "plages statiques" dans cette section.
Voisins BGP
La connectivité est requise pour établir des sessions BGP avec des voisins. Voici les options pour où un voisin BGP peut résider, et leur interaction avec votre compte dans le Cloud Cato.
BGP entre le PoP des réseaux Cato et un routeur BGP au sein d'un tunnel - Cato annonce les plages de comptes, y compris la route par défaut (0/0), et reçoit des plages dynamiques, Plages Dynamiques et Plages Flottantes pour un site. Par exemple, BGP est le mode préféré pour l'échange de routes dans une connexion Amazon AWS IPSec.
BGP entre le Cloud Cato et un routeur BGP résidant sur le LAN / Alt. Lien WAN - Cato peut communiquer avec un voisin BGP sur des plages établies dans le socket : plages directes, plages natives ou plages VLAN.
Les sessions BGP peuvent être établies sur les plages routées tant que toutes les plages ont le même prochain saut que le pair BGP.
Remarques :
Cette option ne repose pas sur l'établissement d'un tunnel.
Cato suppose que toutes les connexions BGP sont « prochain-saut-soi-même » : le voisin est toujours le prochain saut sélectionné par Cato, et Cato annonce l'IP de son voisin comme le prochain saut pour toutes les routes annoncées.
Quand BGP est sur l'Alt. WAN, il reçoit généralement les plages des autres sites (tous les autres sites qui sont accessibles via l'Alt. Lien WAN). Cato filtre ces plages avant de considérer les plages dynamiques et flottantes.
Lorsque qu'un Socket est déconnecté du Cloud Cato, toutes les autres plages de sites sont retirées. Cela permet de maintenir la connectivité dans le cas où le pair BGP dispose d'un chemin secondaire qui peut être utilisé comme prochain saut s'il est temporairement déconnecté du Cloud Cato. (Pris en charge à partir de la version Socket 17.0 et supérieure)
Pour en savoir plus sur la configuration d'un voisin BGP, voir Définir les Voisins BGP.
Comment les connexions BGP sont-elles établies
Il existe plusieurs étapes pour établir la connexion BGP. En fonction de votre type de connexion, les connexions BGP sont établies comme suit :
Une session TCP initiale est démarrée. Si la session TCP ne peut être établie, une tentative est programmée toutes les 30 secondes jusqu'à ce que la session soit réussie
Une session BGP est démarrée immédiatement après l'établissement de la session TCP
Si la session BGP ne peut être établie, une tentative est programmée toutes les 15 secondes
Si une session BGP est interrompue après son établissement, la prochaine tentative est programmée toutes les 1 seconde
Plages Dynamiques
Les plages dynamiques sont des plages IP qui sont apprises dynamiquement par Cato à partir d'un voisin BGP. Une fois acceptées par Cato, elles sont propagées dans tout un compte et deviennent accessibles via ce voisin depuis n'importe où dans le réseau.
Remarque :
Étant donné que les plages dynamiques sont apprises dynamiquement du voisin BGP et ne peuvent pas être configurées en tant qu'objets globaux dans l'application de gestion Cato, elles ne peuvent pas être utilisées explicitement dans les règles de réseau et/ou de sécurité, et se comportent donc selon la politique du site où elles résident.
Plages Flottantes
Les plages flottantes sont des plages IP globales qui ne sont pas connectées à un site spécifique, mais peuvent être apprises de n'importe quel site avec un voisin BGP. Par exemple, dans un scénario de reprise après sinistre (DR), de nombreuses applications (telles que VMware NSX) peuvent déplacer les serveurs d'un emplacement à l'autre tout en conservant leurs adresses IP. Dans ces cas, BGP aide à mettre à jour les objets réseau restants et annonce où se trouvent maintenant ces serveurs.
Les plages flottantes sont définies comme des objets globaux. Les plages flottantes ne sont pas associées à un site particulier et doivent être définies dans des règles de sécurité ou de réseau (l'association de site peut changer dynamiquement). Vous pouvez exploiter la définition de l'objet global pour créer explicitement des règles de réseau et/ou de sécurité selon les exigences de la politique de votre organisation.
Pour qu'une plage dynamique BGP hérite de la politique de sécurité ou de réseau pour une plage flottante, elle doit correspondre exactement à la plage flottante. Par exemple, si la plage dynamique BGP est 192.168.1.0/24 et que la plage flottante est définie comme 192.168.1.1/32, alors il n'y a pas de connexion entre elles et la plage dynamique BGP n'hérite pas des politiques de la plage flottante.
Remarque :
Les plages flottantes ne peuvent pas chevaucher les plages statiques.
Comment BGP dans Cato est conçu et performant
Gestion des Routes
Le voisin BGP dans le Cloud Cato est connecté soit avec un PoP de Cato, soit avec la connexion du site. La connexion du site peut être un Socket ou un tunnel IPsec. Lorsque le Cloud Cato reçoit une nouvelle route BGP ou une route BGP mise à jour, il se synchronise toujours avec le réseau WAN global (connexions des sites et PoP).
Lorsqu'une route BGP est reçue, Cato l'associe à l'objet pertinent comme suit :
Les plages IP définies comme plages flottantes sont associées à leurs objets définis et adhèrent à toutes les politiques de réseau et de sécurité assignées aux objets.
Toutes les autres plages IP sont considérées comme dynamiques et adhèrent à toutes les politiques de réseau et de sécurité assignées au site.
Les routes peuvent être retirées via un message BGP ou via une déconnexion de voisin (CEASE ou physique), et le Cloud Cato propage immédiatement le retrait.
Métriques du Tunnel sur Cato (Table de Routage)
Les sites dans Cato, tels que les sites IPSec ou Socket, peuvent avoir plusieurs tunnels connectés pour envoyer du trafic sur le LAN ou Internet. Si plusieurs tunnels sont connectés, leur priorité est basée sur la qualité du lien et d'autres facteurs. L'écran Table de Routage (Surveillance > Table de Routage) montre la Métrique du Tunnel pour les routes. C'est la valeur que Cato assigne pour s'assurer que le trafic est envoyé sur le meilleur tunnel. Plus la valeur pour Métrique du Tunnel est basse, plus ce tunnel a une priorité élevée. Par exemple, dans un déploiement de haute disponibilité de socket, le tunnel actif peut avoir une métrique de 5 et le tunnel du socket passif a une métrique de 10.
Comment les routes sont-elles priorisées
Contrairement aux plages statiques régulières, BGP permet plusieurs routes qui peuvent se chevaucher ou même être dupliquées sur des parties de votre réseau. Alors, comment le Cloud Cato décide-t-il par quel chemin router des paquets ?
Lorsque plusieurs routes peuvent être appliquées à une adresse IP de destination, les décisions de routage seront effectuées selon les priorités suivantes :
Les routes plus spécifiques sont préférées aux routes moins spécifiques (/24 par rapport à /22, etc.).
L'ordre de préférence pour les plages IP suivantes :
Plages statiques
Plages flottantes
Plages dynamiques
Une métrique voisine plus basse est préférée.
Un chemin AS le plus court est préféré.
Une métrique de tunnel plus basse est préférée.
Un MED BGP plus bas (Discriminateur de Sortie Multiple) de l'ID de la route est préféré.
Puisque le Cloud Cato effectue un routage basé sur des politiques de couche 7, la nécessité d'éviter des routes asymétriques est décisive. Pour cette raison, la priorité des routes est universelle dans le même compte : autrement dit, une origine unique sera sélectionnée à partir de n'importe quel emplacement au sein du réseau Cato Cloud.
Comment les routes sont propagées
Lorsqu'elles sont acceptées par un voisin BGP, les informations associées (AS-path, BGP-communautés) sont conservées. Lorsque des plages dynamiques sont annoncées aux voisins BGP, le chemin AS sera complété avec le numéro AS du Cloud Cato (comme d'habitude avec BGP).
Cato propage de manière transparente tous les attributs de chemin marqués avec le drapeau transitoire (RFC 4271), y compris les communautés.
Les plages de compte (statiques) sont annoncées avec l'ASN de voisin de Socket Cato comme ASN d'origine (Numéro de Système Autonome - voir ci-dessous Attribution d'un ASN à un Voisin).
Pour en savoir plus sur les résumés de routes BGP, consultez Travailler avec des résumés de routes BGP.
Remarque :
Certaines communautés bien connues ne sont pas propagées par Cato vers les voisins BGP en sortie, telles que no-export.
Attribution d'un ASN à un voisin
L'ASN est un nombre compris entre 64,512 et 65,534 (ASN privé), qui représente l'entité de routage établissant la communication. L'ASN par défaut de Cato Networks est 64,515.
Le Cloud Cato prend en charge l'eBGP, de sorte qu'un voisin BGP doit avoir un ASN différent de celui du côté Cloud Cato.
Remarque :
Il est recommandé d'utiliser globalement un seul ASN pour représenter le côté du Cloud Cato de la communication dans toutes les sessions BGP. Si vous envisagez d'utiliser différents ASN pour différents voisins, veuillez contacter Support.
Comment les boucles sont évitées
Lorsqu'une route est reçue par Cato, le chemin AS est analysé pour l'ASN du voisin du Cloud Cato. Toute route contenant cet ASN sera rejetée. Notez que le voisin analyse seulement l'ASN du voisin actuel.
Remarque :
Cato ne prend pas en charge le redémarrage gracieux.
Sécurité et Réseau
Les plages dynamiques sont automatiquement associées au site d'où la route a été reçue, et héritent de tous les groupes de politiques, réseaux et politiques de sécurité du site. Les plages flottantes sont définies globalement et des règles de sécurité leur sont appliquées directement, ou en les associant à des groupes de politiques.
Avant de commencer à utiliser BGP
Quels types de connexion de site puis-je utiliser ?
Cato prend en charge BGP pour les sites qui utilisent des Sockets, vSockets et des sites IPsec (IPsec IKEv1 lancé par Cato, IPSec IKEv2). En outre, une connectivité avec vos routeurs BGP existants est requise.
Comment le voisin BGP établira-t-il la session BGP avec Cato ?
Les sessions BGP nécessitent une connectivité établie entre un voisin BGP et un site sur des routes locales dans les sockets ou sur un tunnel IPSec.
Pour le déploiement de Socket Cato, seules les plages directes, VLAN et natives peuvent être utilisées pour établir des sessions
Les sessions BGP peuvent être établies sur les plages routées tant que toutes les plages ont le même prochain saut que le pair BGP.
Configuration des sessions BGP sur des liens WAN alternatifs
Dans Cato, les destinations WAN alternatives incluent deux réseaux (éventuellement balisés VLAN) : public et privé. Un voisin BGP doit être dans un de ces deux réseaux, et le voisin BGP du côté Cloud Cato sera l'IP Cato correspondant pour cette plage.
Lors de la définition d'une session BGP sur une interface publique, vous pouvez également effectuer la translation de la source NAT sur le trafic traversant ce lien. Cela signifie que pour tout trafic sortant via ce voisin, l'adresse source sera l'IP côté Cato.
Limitations Connues
Le Cloud Cato ne prend en charge que l'IPv4.
Si plusieurs ASN sont configurés pour plusieurs voisins, les ASN ne seront pas détectés par le voisin et des boucles peuvent résulter.
Le Cloud Cato permet la propagation de routes contenant l'ASN du voisin, en s'appuyant sur le voisin pour analyser les boucles.
Les plages flottantes ne peuvent pas chevaucher une plage statique.
Cato ne prend pas en charge le redémarrage gracieux pour le retrait de route.
Les changements de route BGP (y compris le retrait de route) initiés par Cato ne génèrent pas d'événements.
Cato ne réalise pas de résumé de route.
Par défaut, Cato limite à 1024 le nombre de préfixes reçus de chaque voisin BGP. Pour augmenter cette limite, contactez Support.
BGP n'est pas pris en charge pour les comptes qui utilisent la traduction de plage statique. Si vous avez besoin de BGP pour une plage Native traduite pour un site Socket, veuillez contacter Support.