Est-il judicieux de déployer OSPF sur Metro Ethernet?

Lorsque j'ai besoin de connecter un certain nombre de succursales entre elles pour un client, je recommande généralement un VPN MPLS via un opérateur de confiance. Le CE de chaque site parle BGP avec son PE amont et chaque site est numéroté avec son propre ASN privé. C'est très pratique pour nous car BGP fournit une myriade d'outils d'ingénierie du trafic et nos contiguïtés sont limitées à n + 1 pour n sites (le +1 étant notre environnement colo).

Dernièrement, cependant, j'ai remarqué un intérêt croissant des clients pour les solutions Metro Ethernet. Beaucoup de nos clients ont des succursales dans une zone métropolitaine commune et les devis MetroE arrivent à plusieurs centaines de dollars (USD) de moins que le service MPLS pour des circuits de mêmes vitesses. Bien que cela soit attrayant, je ne sais pas comment établir au mieux le routage à travers une dorsale de couche deux tout en évitant de transformer une topologie maillée en hub-and-speak.

BGP nécessiterait un maillage complet d'adjacences entre les sites de succursales afin de maintenir la connectivité du maillage, ce qui n'est évidemment pas souhaitable du point de vue de l'évolutivité. L'autre option consiste à déployer un IGP, à savoir OSPF, et à ce que tous les sites forment des contiguïtés sur le WAN. Je voudrais traiter chaque site comme sa propre zone, ce qui semble exagéré, mais je veux conserver la possibilité de résumer les itinéraires annoncés à partir de chaque site et cela ne peut être fait qu'aux frontières de la zone.

Est-ce que ça a du sens? Y a-t-il des mises en garde à surveiller lors du déploiement d'OSPF de cette manière (par exemple, dois-je envisager de désactiver l'inondation LSA)? Ou y a-t-il une autre solution que j'ai ignorée?

C'est une sorte de question complexe, car les deux produits différents sont très différents. Un circuit MPLS L3VPN est intrinsèquement un maillage complet entre tous les emplacements qui participent, tandis qu'une connexion MetroE est généralement un lien point à point entre deux sites spécifiques.

D'après mon expérience, un circuit MetroE est un chemin d'accès directement approvisionné, sans services de protection, sauf s'il est contracté avec un chemin de protection. Cela signifie que la défaillance d'une interface ou d'un routeur le long du chemin spécifique entraînerait une interruption du trafic entre les deux sites directement liés par le service MetroE. Le MPLS L3VPN corrigera les échecs d'interface / routage pour vous garder avec un maillage complet entre vos sites. Cela explique généralement la différence de prix entre les deux.

Il n'y a rien de mal à créer vos propres services sur une plate-forme MetroE - il vous suffit de travailler avec les exigences des clients pour déterminer le type de routage approprié. Si vous travaillez avec un petit réseau de bureau, OSPF / IS-IS / EIGRP pourrait être un excellent moyen d'échanger des informations de routage entre les sites directement connectés que vous avez établis. Si vous êtes davantage un NSP / ISP / * SP, la séparation de l'infrastructure et des itinéraires client entre IGP et EGP devient beaucoup plus importante à mesure que vous évoluez.

En tant qu'ingénieur ISP, nous utilisons largement les liens MetroE et EWAN pour construire notre backbone, et utilisons notre connaissance des liens physiques pour concevoir notre environnement iBGP / eBGP. Dans de nombreux cas, nous utilisons des réflecteurs de route et des réflecteurs à double route (route-réflecteur-client des deux côtés du peering) pour réduire notre nombre de pairs iBGP. Cependant, à moins que vous n'ayez affaire à plus de 6 routeurs dans un POP, iBGP évolue plutôt bien.

En bref - si c'est pour un seul client, qui n'offre pas de services réseau à ses propres clients - s'en tenir à un IGP. Si la connectivité externe doit être partagée entre les sites, avec basculement / redondance / etc., examinez attentivement les chemins physiques dont vous disposez et concevez votre eBGP / iBGP pour refléter cela. Inutile d'avoir un routeur dans un emplacement distant avec seulement 1 lien en dehors du site vers un homologue iBGP avec tous les autres routeurs de l'AS - utilisez un réflecteur à double route.

Le passage d'un L3VPN géré (ce que je suppose que vous entendiez par «MPLS VPN») à un L2VPN est une belle étape en ce sens que vous pouvez exécuter des protocoles non IP et obtenir un contrôle total des protocoles de routage et des plates-formes de routage qui définissent votre routage topologie.

En supposant que vous placez une seule adresse MAC Ethernet sur le côté CPE de chacun de vos sites, il est beaucoup plus simple pour l'équipement du fournisseur d'apprendre et de transmettre 1 adresses MAC par site, que d'apprendre et d'acheminer potentiellement de nombreux sous-réseaux par site.

Au niveau du protocole, c'est une question délicate à laquelle répondre sans beaucoup plus d'informations, car le meilleur choix dépend de votre trafic et de vos plans de croissance.

S'agit-il d'un seul gros client qui a besoin d'une connectivité interne et Internet, ou vend-il également de la connectivité? En supposant que tout est interne, vous déploierez simplement un IGP et exécuterez peut-être un eBGP pour annoncer les chemins.

Si vous n'avez pas beaucoup de sites ou de préfixes internes, un protocole d'état de lien comme OSPF ou IS-IS a le plus de sens, car il convergera rapidement et pourra construire la FIB à partir de la RIB rapidement s'il n'y a que quelques préfixes .

Si vous avez de nombreux sites ou de nombreux préfixes, cela va commencer à taxer vos plates-formes de routage, car elles doivent chacune traiter chacune. C'est quelque chose qui commence à prendre n ² fois. Si vous avez des sites qui montent et descendent souvent, cette perte de l'état des liens peut également commencer à taxer votre pool de routeurs.

Si vous allez avoir de nombreux sites, de nombreux sites tronqués (un chemin "en amont", pas d'autres routeurs en aval), ou beaucoup de désabonnement de route, vous devrez examiner d'autres protocoles ou topologies.

Dans un cas comme celui-ci, je recommanderais d'utiliser BGP avec certains réflecteurs de route. De cette façon, vous pouvez fournir 2+ réflecteurs de route robustes dans lesquels les rayons annoncent et pour lesquels les autres rayons peuvent récupérer une table de routage. De cette façon, vous pouvez déployer des CPE légers sur vos nombreux sites à rayons qui se connectent, annoncent leur espace et obtiennent une table interne ou une route par défaut vers un routeur qui le fait.

Environ, je suggérerais quelques échelles et équipements (et en supposant des débits sous-Gigabit):

• 1 - 20 rayons - OSPFv3 entre tous les sites. Juniper SRX240 ou similaire pour tous les sites.
• 20 - 100 rayons - iBGP avec réflecteurs de route. Juniper SRX240 dans les rayons, Juniper MX5 / 10/40/80 pour la réflexion d'itinéraire (ou Debian Linux / BIRD).
• 100-500 rayons - Commencez à les diviser en différents réseaux L2, AS ou zones

Juste pour ajouter deux bits souvent ignorés à la discussion BGP:

• Si vous exécutez iBGP, vous avez généralement besoin d'un autre protocole de routage pour établir la connectivité entre les prochains tronçons BGP. Du point de vue de la conception, iBGP est plus un outil d'évolutivité qu'un protocole de routage;
• Si vous exécutez eBGP, vous n'avez pas besoin d'un maillage complet de sessions BGP pour des flux de trafic de bout en bout optimaux; Le traitement du prochain saut BGP résout bien ces problèmes.

Voir http://blog.ioshints.info/2011/08/bgp-next-hop-processing.html pour plus de détails

Vous pouvez très bien exécuter OSPF (ou autre IGP) sur un service Metro-Ethernet multipoint, et cela devrait très bien fonctionner.

Cependant, il pourrait y avoir des raisons de continuer à exécuter BGP ... bien qu'il s'agisse à peu près des mêmes arguments expliquant pourquoi vous pouvez également exécuter BGP au sein de votre propre réseau.

Vous n'avez pas nécessairement à mettre toutes vos enceintes BGP dans le même AS sur un réseau "broadcast" comme celui-là. Considérez-le comme une sorte d'IXP interne géré par les télécommunications où vos AS privés peuvent s'interconnecter via un maillage de couche 2. Vous n'auriez même pas à maintenir nécessairement un maillage complet d'homologations BGP, car les mises à jour BGP peuvent transporter un saut suivant dans son message de mise à jour qui n'est pas le même que celui d'où provient la session d'homologue.

Ainsi, par exemple, si vous avez un maillage de couche 2 avec les routeurs A, B et C dessus et que vous avez des homologues BGP entre A et B, et entre B et C, lorsque C obtient des mises à jour pour les routes originaires de A, il avoir A comme prochain saut, même si elles ont été apprises au cours de la session d'appairage avec B. Évidemment, vous voudriez plus d'homologation de route qu'un simple concentrateur à rayons, vous n'êtes donc pas dépendant du concentrateur unique, mais vous ne nécessite en aucun cas un maillage complet.

Vous obtenez toujours tous les avantages de la politique de routage de l'exécution de BGP si vous le faites de cette façon ... et, comme un autre répondant l'a mentionné, il peut également utiliser le même espace de numéro AS privé et pourrait même s'interconnecter avec le L3VPN existant afin que votre modèle et les mécanismes de soutien n'ont pas besoin de changer.

Cela étant dit, j'ai quelques liaisons métro-E (point à point dans mon cas) que j'utilise OSPF et iBGP et cela fonctionne très bien.

Qu'en est-il d'une configuration de serveur de route avec des «rayons» étant des clients rs des concentrateurs / routeurs principaux?

Même si les homologues bgp seraient comme une topologie hub & speak, tous les rayons devraient pouvoir envoyer du trafic directement à tous les autres.

Vous pouvez même réutiliser les mêmes numéros AS privés que ceux utilisés avec le fournisseur MPLS pour faciliter la migration d'un service à un autre.

Je recommanderais fortement de lire et de prendre une décision concernant les topologies OSPF alternatives telles que le démarrage en tant que NBMA au lieu de la norme. Vous vous rendrez vite compte qu'il n'y a aucun moyen pour OSPF de sélectionner correctement entre deux chemins allant vers le même routeur / site dans le même Ethernet métropolitain, en raison de la façon dont le coût est calculé via l'interface sortante, les liens WAN principal et de secours apparaîtront les mêmes coût en OSPF standard. Cependant, si vous choisissez d'utiliser NBMA par exemple, vous pouvez définir manuellement les coûts voisins - mais vous devez maintenant définir manuellement le maillage / contiguïtés.

Quoi que vous fassiez, ROUTE OVER IT DO NE I REPEAT DO NOT JOIN AT LAYER 2, vous demandez simplement des problèmes plus tard, si vous avez besoin d'interconnectivité de couche 2, utilisez OTV ou une autre fonctionnalité de couche 2 sur couche 3.

Vous découvrirez rapidement que vous en apprendrez beaucoup plus sur OSPF (et que vous devez en savoir beaucoup plus) que par rapport à un simple fournisseur MPLS-VPN où le cœur WAN vous est caché.

OSPF over metroE fonctionne bien mais vous devrez vous assurer qu'il correspond à vos besoins et vous architecte en conséquence. Une mise en garde que je n'ai pas vue mentionnée est de vous assurer que vous savez quel MTU votre fournisseur prend en charge. J'ai vu une MTU tomber sur une liaison metroE pendant une maintenance de fournisseur, ce qui a empêché le voisin OSPF de se présenter. Probablement seulement un problème car ils ne supportent pas vraiment les trames jumbo mais ils l'ont fait juste pour nous :) Être gentil parfois ne rapporte pas.