Routage du trafic vers différentes liaisons à partir du même BGP AS


19

J'ai deux sites, A et B, dans BGP AS 65000, et un troisième site, C, dans AS 65001. Les trois sites ont une connectivité via l'opérateur MPLS et il y a une connectivité interne entre les sites A et B. J'essaie d'influencer BGP de sorte que le trafic du site A vers le site C sera acheminé via le lien MPLS du site A, et le trafic du site B vers le site C sera acheminé via le lien MPLS du site B. La topologie est similaire à celle décrite dans cet exemple .

AS 65000 et 65001

Les routeurs périphériques aux sites A et B verront tous les deux leur propre liaison MPLS comme le meilleur chemin, car les routes EBGP sont préférées aux routes IBGP. Cependant, les routeurs plus à l'intérieur de l'AS 65000 préféreront tous l'un ou l'autre lien. Mon objectif est de forcer tous les routeurs des deux sites à préférer le lien le plus proche. (Malheureusement, je ne suis pas en mesure de diviser les deux sites en AS séparés pour le moment.)

Existe-t-il un moyen sensé d'accomplir cela tout en permettant la connectivité de basculement au site C entre les liens du site A et B?

Edit: j'aurais dû noter qu'il n'y a pas d'IGP utilisé ici. En fait, les réseaux de chaque site existent au sein d'un VRF dans le cadre d'un réseau beaucoup plus vaste. En tant que tel, toute solution doit reposer entièrement sur BGP.


Hé Jeremy - il y a deux bonnes solutions à cela ci-dessous, mais je ne peux pas faire d'hypothèse sûre que vous avez un contrôle administratif sur l'IGP. Pouvez-vous clarifier cela?
John Jensen

Il n'y a pas d'IGP dans ce scénario. Ceci est en fait représentatif d'un seul VRF au sein d'un réseau beaucoup plus vaste; les détails dont j'ai omis pour des raisons de clarté.
Jeremy Stretch

Voilà ce que j'avais peur. :-) Merci de clarifier.
John Jensen

Quelque chose manque ici, je pense; Nous sommes donc deux supposons qu'il existe un lien (peut-être beaucoup, en raison de plusieurs routeurs internes?) Entre A et B à l'intérieur de l'AS 65000? Aussi, que voyez-vous qui est sous-optimal? Un / ou plusieurs routeurs plus proches de A (topologiquement parlant) envoient-ils du trafic via B pour se rendre à C?
jwbensley

@javano le problème est que A et B (les routeurs périphériques) sont des homologues iBGP dans le même ASN, donc tout préfixe appris de C sur l'un ou l'autre aura 2 chemins dans le RIB sur les deux boîtes, et le chemin eBGP sera toujours gagner, donc le trafic sortant de AS6500 vers AS65001 est bloqué sur un lien.
John Jensen

Réponses:


12

Existe-t-il une définition claire entre le site A et le site B?

Si c'est le cas, je chercherais à définir une politique sur les routeurs de périphérie pour injecter une communauté lors de la réception de routes du transporteur MPLS.

Une fois que cette communauté a été mise sur les préfixes (disons 100: 1 pour le site A et 100: 2 pour le site B), vous pouvez ensuite ajouter une stratégie à chacun des routeurs du site A pour augmenter le LP pour tous les itinéraires avec la communauté 100: 1 et de même pour le site B avec la communauté 100: 2.

Cette solution répondrait à l'exigence d'utiliser uniquement BGP et serait également suffisamment flexible pour permettre à B d'utiliser la liaison montante de A s'il perdait sa propre liaison montante au transporteur.


1
C'est probablement la meilleure façon de procéder, mais si Jeremy annonce un seul résumé de C, il devra le diviser en morceaux pour que cela fonctionne efficacement.
John Jensen

Je pense que c'est le chemin que je vais emprunter. J'aurai besoin de le tester demain et de voir si je suis coincé quelque part.
Jeremy Stretch

@JohnJensen cela ne devrait pas être nécessaire car les sites A et B vont recevoir les mêmes préfixes du transporteur et peuvent donc apporter des modifications à leurs propres préfixes de `` sites '' avec le bris d'égalité descendant vers le LP.
David Rothera

1
En outre, en y réfléchissant davantage, il serait préférable d'utiliser un attribut localement significatif comme le poids plutôt qu'un attribut transitif comme LP.
David Rothera

1
@DavidRothera S'il y a plusieurs préfixes annoncés de C, vous auriez raison - il est possible qu'il ne puisse y avoir qu'un seul préfixe venant de C, auquel cas je ne suis pas tout à fait sûr que la définition de localpref avec une communauté ferait une différence pour résoudre le problème de Jeremy, car il y a un seul préfixe avec une option de deux communautés et deux valeurs de LP différentes, le LP le plus élevé sera préféré et le trafic restera épinglé sur un lien. Convenant également cependant que l'utilisation d'un attribut localement significatif peut être préférable ici.
John Jensen

6

entrez la description de l'image iciQuand j'ai fait quelque chose de similaire, je n'ai pas utilisé eBGP entre les routeurs. J'ai demandé au routeur parlant BGP d'envoyer uniquement la route par défaut aux routeurs Site A et Site B via OSPF, puis de redistribuer les routes OSPF dans BGP. Sur le lien entre les deux sites, j'ai appliqué un coût OSPF.

Cela permet au site A d'avoir des routes vers ses réseaux, les réseaux du site B et une route par défaut pour sortir du site A (le coût OSPF conserve la route par défaut du site B comme option secondaire si vous perdez le lien du site A). Le site A communiquera directement avec le site B, sans utiliser MPLS, sauf en cas de défaillance de la liaison entre les sites.

De plus, les coûts OSPF se traduisent par le BGP MED lors de la redistribution, ce qui amène le réseau MPLS de l'opérateur à préférer envoyer le trafic du site A directement au site A, mais également utiliser le site B pour se rendre au site A si nécessaire.


3

Je sens que certaines informations manquent. Pourquoi les routeurs périphériques ne préfèrent-ils pas déjà le meilleur chemin?

Avez-vous un iBGP à maillage complet dans 65000? Ou utilisez-vous la réflexion d'itinéraire?

Si vous avez un iBGP à maillage complet, chaque routeur périphérique apprend la route à partir des deux [AB] et recourra à la comparaison du coût IGP au saut suivant, qui devrait se traduire par la zone périphérique la plus proche.

S'il y a une réflexion de route en place, elle ne reflétera que la meilleure route de son propre POV, ce qui peut supprimer la meilleure transmission de chemin. Cela peut également être résolu en ajoutant un autre RR qui choisira l'autre itinéraire comme meilleur, puis les cases de bord peuvent à nouveau choisir le meilleur itinéraire. Si la fixation de RR n'est pas possible comme ça. Vous pouvez ajouter la même adresse IPV4 dans les deux bouclages de routes frontalières, et lorsque les routeurs frontaliers annoncent le préfixe à RR, ils définissent le saut suivant sur cette adresse anycast. Ensuite, même après réflexion, vous suivrez IGP jusqu'à la frontière la plus proche.


2

Si vous contrôlez l'IGP:

Ce que nous avons fait, c'est d'avoir uniquement des routeurs eBGP dans le maillage iBGP. Le reste de nos routeurs internes sont des routeurs OSPF. Nous redistribuons de BGP à OSPF dans chaque AS. Notre configuration est un peu différente de la vôtre, mais cela devrait permettre à la métrique de coût OSPF d'influencer le chemin emprunté par le trafic vers le routeur eBGP le plus proche.

Si vous n'avez aucun contrôle sur l'IGP:

Vous pouvez peut-être appliquer une politique d'importation aux routeurs internes pour leur faire préférer statiquement les annonces d'itinéraire du routeur eBGP de sortie souhaité. Ainsi, par exemple, si iBGP contient deux annonces pour un préfixe donné (une du routeur du site A et une du routeur du site B, mais une seule est installée dans le RIB), vous pouvez préférez localement l'annonce souhaitée à mesure qu'elle arrive. à l'intérieur. Je devrais le lab up, mais je ne vois pas pourquoi cela ne fonctionnerait pas.


Ouais, ce serait la meilleure façon que j'imagine, en supposant que vous avez la possibilité d'utiliser un IGP. Ce n'est malheureusement pas mon cas. :( J'ai mis à jour la question pour inclure ce détail négligé.
Jeremy Stretch

J'aime la réponse de David Rothera, car elle est la même que la mienne, mais il ajoute le détail de l'utilisation des communautés :)
netdad
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.