Équilibrage de charge BGP entrant à partir du même routeur ISP

J'ai deux routeurs BGP pour DIA avec un problème avec un fournisseur en ce que les deux liens vers ce fournisseur atterrissent sur le même routeur SP. Mes transferts Ethernet via deux liaisons MetroE distinctes d'un autre fournisseur au nom de mon fournisseur principal, car le seul fournisseur avait déjà la fibre optique vers le bâtiment. Si quelqu'un pouvait également clarifier la terminologie du FAI lorsqu'un fournisseur transporte des services pour un autre, je l'apprécierais. Les deux circuits se terminent en L3 avec le même routeur SP, donc mes deux routeurs sont chacun homologues avec le même routeur fournisseur. Je reçois un espace PA de ce SP.

Je n'ai aucun problème avec l'équilibrage de charge sortant (ou le partage de charge car je suppose que ce serait plus précis techniquement). Sortant, je fais l'ECLB au niveau du pare-feu qui sélectionne l'un des deux routeurs périphériques basé sur un hachage srcip / dstip .

Ce transporteur particulier - oubliez le transporteur qui fournit simplement le transport - n'équilibre pas la charge du trafic entrant de son seul routeur sur les deux liaisons vers mes deux routeurs, et c'est dans cette direction que nous pourrions utiliser le BW combiné 5x50Mb que nous avons contracté. Le SP voit des chemins égaux pour nous pour le même réseau annoncé et essentiellement le premier chemin qu'ils apprennent est ce qui devient le meilleur chemin.

J'ai énuméré ci-dessous ce que je considère comme mes options pour obtenir du trafic sur les deux circuits, et j'aimerais savoir ce que les experts ici pensent de mieux, en particulier si vous êtes familier avec les SOP SP typiques . Étant donné que j'ai un contrat, le modifier à ce stade n'est pas une option pour le reconstruire d'une autre manière.

Autoriser maximum-paths 2le réseau SP corrige cela, mais cela s'applique à tous leurs clients BGP sur le même routeur que je ne pense pas qu'ils autoriseront. Au moins une option qui fonctionnera implique des routes statiques, mais ce n'est pas ce que je préférerais.

Voici les options que j'ai envisagées dans mon ordre de préférence.

1. Autoriser BGPmaximum-paths 2 sur le routeur SP (affecte tous les clients BGP hébergés là-bas) donc / 24 est utilisé lorsqu'il est annoncé sur les deux circuits

2. Divisez mon / 24 en deux et annoncez des / 25 séparés sur chaque lien avec le / 24. Le SP a récemment déclaré qu'une communauté non documentée pourrait être utilisée pour accepter les préfixes> / 24. Cela nécessite de manipuler le NAT sur mon pare-feu pour utiliser des adresses globales dans les deux / 25, car la plupart du trafic nous est désormais destiné sur quelques adresses dans le / 25 inférieur.

3. Les routes statiques SP vers / 24 pour forcer l'équilibrage de charge avec BGP / 24 (route flottante).

4. Les routes statiques du SP vers / 25s pour forcer ECLB avec le préfixe BGP / 24 (en RIB, mais non utilisé sauf en cas de panne de / 25s).

Je pense que la publicité des / 25 dans BGP est la meilleure option que je n'ai découverte que récemment est possible avec la communauté non documentée SP, mais y a-t-il d'autres options que je n'ai pas envisagées ou des préoccupations concernant les paquets en panne avec certains de ces choix ?

C'est en quelque sorte le problème d'équilibrage de charge inverse que la plupart des gens demandent avec BGP.

Je demanderais des «chemins maximaux» (on l'appelle généralement ECMP dans les normes et les documents, pas ECLB). Et si ECMP ne démarre pas, revenez à votre plan / 25.

D'autres acronymes que je n'ai pas pu comprendre immédiatement étaient DIA (accès Internet dédié?) Et SOP (procédure standard d'exploitation?). Je ne suis pas sûr que ce soient vraiment des acronymes tellement universels qu'ils devraient être utilisés dans stackexchange sans au moins un survol pour les résoudre.

En parlant de terminologie, vous avez déjà dit que le transport est ce que je pense que ce type de service est le plus communément appelé. Parfois, les gens l'appelleront également un "lien".

Vous avez une autre possibilité de déplacer l'interface de votre côté vers le même routeur, puis de configurer eBGP multihop *** entre vous et votre fournisseur. Oui, vous perdez la redondance de votre côté, mais de l'autre côté, cela va quand même au même routeur, c'est donc une sorte de point discutable. Cela élimine également la nécessité pour le fournisseur d'effectuer des trajets multiples eBGP, au cas où il ne serait pas disposé à le faire avec vous (mais j'ai constaté qu'en général la plupart des fournisseurs acceptent d'activer cette option, si ce n'est déjà fait) .

Si cela ne semble pas plausible, alors annoncer deux / 25 est probablement votre meilleur pari, à moins bien sûr que votre fournisseur ne soit prêt à s'allumer maximum-paths(encore une fois, en supposant qu'ils ne l'ont pas déjà fait).

*** L'équilibrage de charge avec le multihop eBGP dans votre scénario impliquera les éléments suivants:

1. Déplacez la deuxième connexion ISP vers un routeur de votre côté.
2. Le fournisseur et vous-même configurez update-source Loopback0chacune de vos sessions - vous n'avez pas besoin d'utiliser Lo0 si vous ne le souhaitez pas, tant que vous êtes d'accord sur l'adresse à laquelle vous souhaitez effectuer un routage statique.
3. Configurez des routes statiques 2x / 32 vers les bouclages des autres via les interfaces connectées (ou les adresses IP du prochain bond) - c'est ainsi que l'équilibrage de charge fonctionne, car c'est vraiment juste ECMP.
4. Configurez ebgp-multihop 2les sessions des autres (vous voulez garder ce nombre aussi petit que possible pour éviter le détournement de session TCP).

Voila, équilibrage de charge. Cela évolue également par interface, car l'ajout d'un nouveau port impliquera l'ajout d'une autre interface et d'une route statique.

La solution optimale ici est BGP ECMP via maximum-paths 2- cependant, je dirai que "accepter des itinéraires> / 24" nécessitant un tag communautaire sonne comme une stupidité épique - en supposant que vous êtes un de leurs clients, ils devraient accepter tout ce que vous leur donnez jusqu'à un nombre maximum de préfixes et simplement filtrer les sortants selon les accords qu'ils ont avec leurs autres pairs. l'un des amonts que j'ai me met dans un bateau similaire en ce qui concerne ne pas faire ECMP, je m'attends toujours à être autorisé à annoncer toute taille de préfixe que je souhaite à un fournisseur de transit et à le faire l'utiliser.

Donc, étant donné qu'ils ne semblent pas terriblement compétents, pour équilibrer le trafic, ne retirez pas votre préfixe / 24 - au lieu de cela, laissez-le et assurez-vous que vos itinéraires / 25 sont marqués avec NO_EXPORT en plus de tout ce que votre fournisseur aurait nécessite pour que vos / 25 ne fuient pas accidentellement de leur AS (pas qu'il soit susceptible d'aller très loin s'il le fait).

Une dernière remarque - assurez-vous que cette "communauté sans papiers" n'est pas en fait une communauté de trou noir, car ce serait ... vous savez, mauvais .