Routage dans SSG
Le routage dans SSG est réalisé par l’échange de routes entre SSG et Soft-Router à l’aide de la table de route du noyau Linux. Vous pouvez en apprendre davantage à ce sujet dans notre base de connaissances.
Les principales caractéristiques de SSG en tant que routeur sont les suivantes :
- Support des protocoles de routage BGP et OSPF.
- Mise en œuvre de VRF Lite où le SSG partage les tables de routage mais ne crée pas de tunnels uniques pour le trafic de chaque VRF (par exemple, MPLS, VXLAN). VRF Lite permet d’isoler les services fournis et d’optimiser le routage lors de l’utilisation de liens différents.
Avec la version 13.1, le SSG peut être utilisé comme routeur frontalier. Optimisation du routage dans le SSG avec le gestionnaire ARP
Considérons un schéma typique de la construction du réseau d’un opérateur de télécommunications, où le SSG agit en tant que DPI/NAT/BRAS/Routeur frontalier. Le SSG termine le segment L2 de l’abonné pour les connexions IPoE/PPPPoE du côté des interfaces d’entrée. Les interfaces de sortie sont incluses dans le commutateur auquel la liaison montante et les routeurs internes sont connectés.
Comme le SSG ne commute pas en interne entre les paires d’interfaces physiques, les connexions à plusieurs routeurs doivent être effectuées via le commutateur.
Dans ce schéma, le SSG reçoit la vue complète BGP de l’opérateur en amont (routeur BGP) et est connecté via OSPF au routeur (routeur OSPF), derrière lequel les services locaux de l’opérateur télécom sont situés.
Il convient de noter que le SSG stocke la table de routage dans la mémoire vive, qui peut être facilement étendue. Si nécessaire, il peut recevoir et traiter plusieurs vues complètes BGP. Cette capacité est activement utilisée par les fournisseurs car ils n’ont pas pu l’implémenter sur d’autres routeurs.Une caractéristique de ce schéma est que le routeur BGP n’annonce pas lui-même comme nexthop, mais d’autres routeurs tels que le routeur 1 ou le routeur 2. De cette manière, le fournisseur en amont met en œuvre la redondance des canaux de liaison montante et centralise en outre la gestion de l’annonce des routes pour le fournisseur en aval.
Avant la version 13.1, le SSG ne pouvait pas envoyer de manière indépendante une requête ARP pour obtenir les adresses MAC du Routeur 1 et du Routeur 2, ce qui l’empêchait de former un paquet vers le nexthop. Auparavant, le SSG remplissait sa table ARP en analysant les requêtes ARP provenant de l’espace de noms du réseau et les réponses à ces requêtes. Cependant, dans ce scénario, la pile réseau Linux ne génère pas de requêtes ARP vers le routeur 1 et le routeur 2, car ce n’est pas nécessaire. Pour résoudre ce problème, un gestionnaire ARP a été ajouté à SSG. Désormais, le SSG peut générer des requêtes ARP vers les adresses IP nécessaires. Lors de la génération d’une requête ARP, SSG utilise l’adresse spécifiée dans le paramètre bras_arp_ip comme le src IP .
Vous pouvez en savoir plus sur le gestionnaire ARP dans notre base de connaissances.
Conclusion
Nous continuerons à travailler sur l’amélioration du gestionnaire ARP. Dans un avenir proche, nous prévoyons d’ajouter la possibilité de générer des requêtes ARP avec différentes adresses IP sources, en plus de l’adresse spécifiée dans le bras_arp_ip paramètre. Cela permet d’établir plusieurs sessions BGP avec différents fournisseurs.