C'est bien comme ça que ça marche. Les routes iBGP best font que la route eBGP correspondante (si elle existe) ne sera pas annoncée vers le peer iBGP (et ne sera pas celle poussée en FIB).
L'objectif serait de s'assurer que les deux routeurs ont toutes les routes des deux transits... Dans ce cas, pour annoncer à coup sûr la best external aux peers (même si ce n'est pas la best "overall" du routeur) - et ainsi faire comme ce que la RFC prévoyait au départ (mais que personne ne fait par défaut parce que ça multiplie le nombre de routes échangées), il faut utiliser une commande pour modifier ces annonces coté iBGP: - bgp advertise-best-external chez Cisco en IOS, advertise best-external en IOS-XR - advertise-external + advertise-inactive chez Juniper - advertise-external chez ALU De cette façon les deux routeurs ont tous les deux toutes les routes des deux transits en RIB, en permanence (en RIB ou dans la table BGP qui va bien, d'ailleurs). Quoi qu'il en soit, s'ils ont un CPU de tortue rhumatisante, best external ou bonne vieille default annoncée par chaque transit, ça sera quand même lent :) En effet, on a beau advertiser la best external ou avoir une default external, si la best est en iBGP alors il faut bien attendre que le routeur d'à coté qui aurait perdu son transit envoie un withdraw pour invalider sa route, et qu'on puisse utiliser l'external coté FIB. Par contre le routeur qui a perdu son transit aura déjà toutes les routes de son pote (ou une default) sans attendre que l'autre se décide à lui annoncer les routes manquantes, à la suite de son propre withdraw. Mais comme au final, plus un routeur (moisi ou pas d'ailleurs) connait de routes et plus il est lent à converger, la default aurait tendance à être plus pertinente dans des conditions de CPU perrave... Conclusion: si pas besoin d'avoir toutes les routes, fais-toi annoncer fullview + default, et filtre à /22 voire /20 et plus large (ou bien filtre sur les communities placées par tes transits selon ce que tu veux, pourquoi pas); voire default seulement si pas de contre-indication pour ton usage. Vu que les solutions miraculeuses, y en a pas trop. > Le 19 janv. 2016 à 13:58, David Ponzone <[email protected]> a écrit : > > Raphael, > > Pour moi, si A reçoit une route de Transit1 (eBGP) et de B (iBGP), et que la > route venant de B est la meilleure, il ne redistribue pas la route qu’il a eu > de Transit1 à B. > C’est peut-être variable en fonction des implémentations et/ou de la conf. > >> Le 19 janv. 2016 à 12:42, Raphael Mazelier <[email protected]> a écrit : >> >> >> Théoriquement chaqun de tes routeurs tu devrais avoir pour chaque pfx deux >> paths, le préféré vers TransitX et l'autre vers TransitY (possiblement via >> ton routeur voisin). >> Si tu coupe une session de transit, chaque routeur devrait déjà avoir les >> chemins dans la RIB vers l'autre, pas la peine que ton autre routeur les ré >> annonce en IBGP. >> En revanche ce qui peut se passer lors de gros changement de route de ce >> style, c'est des lenteur de changement RIB->FIB. >> >> -- >> Raphael Mazelier >> >> >> Le 19/01/16 10:11, Aurélien a écrit : >>> Bonjour, >>> >>> J’ai une question sur une situation toute bête que j’ai sur un AS: >>> >>> Mettons que j’aie (pour simplifier) 2 routeurs, un IGP (ospf en >>> l’occurence, mais ça importe peu) qui récupère les routes connectées >>> sur chaque routeur (R1 et R2), de l’iBGP entre les loopbacks, et un >>> transit avec une full view sur chaque routeur. Chaque routeur a aussi >>> des sessions avec des clients (genre annonce de la route par défaut, >>> sur AS privé). >>> >>> Ce qui me fait donc sur R1, une fois que tout est up, dans les ~200k >>> routes préférées via mon transit local, et donc de par le fait, R2 qui >>> m’annonce ~360k routes IPv4 (la full view moins les routes qu’il >>> préfère passer par R1). >>> >>> Mon problème survient quand je coupe l’un de ces transits, mettons sur >>> R1. La session BGP est coupée, et je withdraw mes annonces de routes à >>> R2. R2 qui du coup va progressivement m’annoncer le reste de la full >>> view reçue via son transit. >>> >>> Le problème, c’est que pendant cette période de convergence, je peux >>> facilement me retrouver avec des paquets qui m’arrivent de mes >>> downstreams sur R1, et pour lesquels du coup je n’ai plus de route de >>> sortie (plus de route par mon transitaire, et R2 ne m’a pas encore >>> annoncé la route obtenue via son transit). >>> >>> Comme j’ai des routeurs qui carburent au PowerPC, ils ne jouent pas >>> très vite avec les routes, ce qui n’arrange pas le souci. >>> >>> Est-ce que quelqu’un a déjà eu ce genre de souci ? Est-ce qu’il existe >>> des solutions de configuration pour contourner ou minimiser ce type de >>> problème ? (Evidemment, on peut le minimiser en mettant un Xeon dans >>> le routeur, on est d’accord). >>> >>> Merci de vos lumières, >>> >>> Cordialement, >>> >> >> >> --------------------------- >> Liste de diffusion du FRnOG >> http://www.frnog.org/ > > > --------------------------- > Liste de diffusion du FRnOG > http://www.frnog.org/ --------------------------- Liste de diffusion du FRnOG http://www.frnog.org/
