BGP est un protocole de passerelle extérieur standardisé conçu pour échanger des informations de routage et d'atteignabilité entre les systèmes autonomes (AS) sur Internet.
Basé sur vos configurations et en s'appuyant sur les informations de routage BGP, le Cloud Cato peut prendre des décisions de routage en temps réel éclairées sans que vous ayez besoin de configurer manuellement plusieurs chemins statiques et/ou de prendre des actions. 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 IPs virtuelles, l'intégration avec des systèmes autonomes (AS) au sein des sites, et une plus grande flexibilité dans les déploiements progressifs.
Cette section décrit les composants BGP de Cato (y compris les objets globaux), et comment le support de BGP de Cato est conçu et fonctionne.
Le support BGP de Cato se compose de trois composants principaux : voisins BGP, plages dynamiques et plages flottantes.
Remarque
Remarque : Toutes les plages définies dans la Plage Native d'un site sont désignées comme « plages statiques » dans cette section.
La connectivité est requise pour établir des sessions BGP avec des voisins. Voici les options pour savoir où un voisin BGP peut résider, et leur interaction résultante avec votre compte dans le Cloud Cato.
-
BGP entre le PoP de Cato Networks et un routeur BGP dans un tunnel - Cato annonce des 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 les plages établies dans la prise : plages directes, plages natives ou plages VLAN.
Les sessions BGP peuvent être établies sur les plages routées uniquement tant que toutes les plages ont le même saut suivant que le pair BGP.
Remarque
Remarques :
-
Cette option ne repose pas sur l'établissement d'un tunnel.
-
Cato suppose que toutes les connexions BGP sont « next-hop-self » : 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 accessibles via l'Alt. Lien WAN). Cato filtre ces plages avant de considérer les plages dynamiques et flottantes.
-
Lorsqu'un Socket est déconnecté du Cloud Cato, toutes les autres plages de site sont retirées. Cela permet de maintenir l'atteignabilité dans un cas où le pair BGP a un chemin secondaire qui peut être utilisé alternativement comme prochain saut s'il se déconnecte temporairement du Cloud Cato. (Pris en charge à partir de la version 17.0 de Socket et supérieure)
Pour plus d'informations sur la configuration d'un voisin BGP, voir Définition des Voisins BGP.
Il existe plusieurs étapes pour établir la connexion BGP. Selon 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 pas être établie, une tentative est programmée toutes les 30 secondes jusqu'à ce que la session soit établie avec succès
-
Une session BGP est démarrée immédiatement après l'établissement de la session TCP
-
Si la session BGP ne peut pas être établie, une tentative est planifiée toutes les 15 secondes
-
Si une session BGP est résiliée après avoir été établie, la tentative suivante est programmée toutes les 1 seconde
Les plages dynamiques sont des plages IP qui sont apprises dynamiquement par Cato 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
Remarque : Étant donné que les plages dynamiques sont apprises dynamiquement du voisin BGP et ne peuvent pas être configurées comme 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 dans lequel elles résident.
Les plages flottantes sont des plages IP globales qui ne sont pas connectées à un site spécifique, mais peuvent être apprises depuis n'importe quel site avec un voisin BGP. Par exemple, dans un scénario de récupération après sinistre (DR), de nombreuses applications (comme VMware NSX) peuvent déplacer des serveurs d'un endroit à l'autre tout en maintenant leurs adresses IP. Dans ces cas, BGP aide à mettre à jour les objets de 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
Remarque : Les Plages Flottantes ne peuvent pas se chevaucher avec les plages statiques.
Le voisin BGP dans le Cloud Cato est connecté à un PoP de Cato ou à la connexion de site. La connexion du site peut être une Prise ou un tunnel IPsec. Lorsque le Cloud Cato reçoit une nouvelle route BGP ou une mise à jour, il se synchronise toujours avec le réseau WAN global (connexions de site et PoPs).
Lorsqu'une route BGP est reçue, Cato l'associe avec l'objet pertinent de la manière suivante :
-
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.
-
Tous les autres plages IP sont considérées comme plages 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 (CESSER ou physique), et le Cloud Cato propage immédiatement le retrait.
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 l'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) affiche la Métrique de Tunnel pour les routes. C'est la valeur que Cato assigne pour s'assurer que le trafic est envoyé via le meilleur tunnel. Plus la valeur de Métrique de 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 à partir du socket passif a une métrique de 10.
Contrairement aux plages statiques régulières, BGP permet plusieurs routes qui peuvent se chevaucher ou même être dupliquées dans des parties de votre réseau. Alors, comment le Cloud Cato décide-t-il par quel chemin acheminer les 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 :
-
Des routes plus spécifiques sont sélectionnées par rapport aux routes moins spécifiques (/24 plutôt que /22, etc.).
-
L'ordre de préférence pour les plages IP suivantes :
-
Plages statiques
-
Plages flottantes
-
Plages dynamiques
-
-
La métrique de voisinage la plus basse est préférée.
-
Le chemin AS-PATH le plus court est préféré.
-
La métrique de tunnel la plus basse est préférée.
-
Le BGP MED (Discriminateur Multi-Sorties) le plus bas de l'identifiant de la route est préféré.
Comme Cato Cloud exécute le routage basé sur des politiques de couche 7, le besoin d'éviter les routes asymétriques est décisif. Pour cette raison, la priorité des routes est universelle au sein du même compte : en d'autres termes, une seule origine sera sélectionnée depuis n'importe quel emplacement au sein du réseau Cato Cloud.
Lorsque les routes sont acceptées par un voisin BGP, les informations associées (chemin AS, communautés BGP) sont préservées. Lorsque les plages dynamiques sont annoncées aux voisins BGP, le chemin AS sera ajouté avec le numéro AS de Cato Cloud (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 comptes (statiques) sont annoncées avec le ASN du voisin de Cato Socket 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 des routes BGP, consultez Travailler avec des résumés de routes BGP.
Remarque
Remarque : Certaines communautés bien connues ne sont pas propagées par Cato vers les voisins BGP à la sortie, comme no-export.
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.
Cato Cloud prend en charge eBGP, donc un voisin BGP doit avoir un ASN différent du côté de Cato Cloud.
Remarque
Remarque : Il est recommandé d'utiliser un seul ASN pour représenter le côté Cato Cloud 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 scanné pour le numéro ASN du voisin de Cato Cloud. Toute route contenant cet ASN sera abandonnée. Notez que le voisin ne scanne que l'ASN du voisin actuel.
Remarque
Remarque : Cato ne prend pas en charge Redémarrage en douceur.
Les plages dynamiques sont automatiquement associées au site à partir duquel la route a été reçue et héritent de tous les groupes de politiques, politiques de réseau et de sécurité du site. Les plages flottantes sont définies globalement et les règles de sécurité leur sont appliquées directement ou en les associant à des groupes de politiques.
Quels types de connexion de site puis-je utiliser ?
-
Cato prend en charge BGP pour les sites qui utilisent des Sockets, des vSockets et des sites IPsec (IPsec IKEv1 initié par Cato, IPsec IKEv2). De plus, une connectivité est requise avec vos routeurs BGP existants.
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 via des routes locales dans des sockets ou via un tunnel IPSec.
-
Pour le déploiement de Cato Socket, seules des plages directes, VLAN et plages natives peuvent être utilisées pour établir des sessions
Les sessions BGP ne peuvent être établies sur des plages routées que tant que toutes les plages ont le même prochain saut que le pair BGP.
Configuration des sessions BGP sur des liaisons WAN alternatives
Dans Cato, les destinations WAN alternatives incluent deux réseaux (potentiellement balisés par VLAN) : public et privé. Un voisin BGP doit être au sein de l'un de ces deux réseaux, et le voisin BGP du côté de Cato Cloud sera l'IP Cato correspondante pour cette plage.
Lors de la définition d'une session BGP sur une interface publique, vous pouvez également effectuer un NAT de source sur le trafic traversant ce lien. Cela signifie que pour tout le trafic sortant via ce voisin, l'adresse source sera l'IP du côté Cato.
-
Cato Cloud ne prend en charge que 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 en résulter.
-
Cato Cloud permet la propagation de routes contenant l'ASN du voisin, en s'appuyant sur le voisin pour scanner les boucles.
-
Les plages flottantes ne peuvent pas chevaucher une plage statique.
-
Cato ne prend pas en charge le redémarrage en douceur pour le retrait de route.
-
Les modifications de routes BGP (y compris le retrait de routes) initiées par Cato ne génèrent pas d'événements.
-
Cato ne réalise pas la somme des routes.
-
Par défaut, Cato limite le nombre de préfixes reçus de chaque voisin BGP à 1024. 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.
0 commentaire
Vous devez vous connecter pour laisser un commentaire.