Autre petite info : les cluster-id. Deux approches : 1) historique : tu mets le même cluster-id sur tes RR. Cela signifie que chaque PE reçoit 2 fois le même annonces de routes, donc il n'en garde qu'un seul dans son calcul BGP. Utile quand tu renvoies la full routing, tu n'as pas 2 fois toutes les annonces BGP à compiler dans chaque routeur. Inconvénient, en cas de perte d'un RR, tu dois attendre de recevoir toutes tes annonces de routes du second RR, alors que le résultat n'a pas changé.
2) plus récente ; tu mets 1 cluster-id différent sur chaque RR : tu reçois donc maintenant N annonces (autant que de cluster-id différents, généralement N = 2), que tu gardes en mémoire. Inconvénient, donc tu utilises plus de mémoire. Avantage, en cas de crash du premier RR, chaque PE a déjà toutes les annonces de routes du second RR, et il n'y a pas à attendre le ré-envoi de toutes les annonces de routes. La seconde approche est pas mal pour éviter des temps de reconvergence long quand tu dois upgrader un RR, mais avec la full routing, c'est assez impactant. L'approche "default route" depuis les PE de peer/transit permet donc de prendre la seconde approche sans trop d'impacts sur tes PE "users". A+ Le 22 janvier 2012 19:34, Guillaume Barrot <guillaume.bar...@gmail.com> a écrit : > Si tu n'as que quelques PE de peering/transit, je te déconseille d'envoyer > la full-routing à tes RR. > Au moindre problème sur le net, non seulement tu risques d'avoir des > effets de bords sur tes PE, mais du coup aussi sur tes RR, et là tu perds > tout le control-plane de ton réseau. (Au hasard, un bug sur Juniper qui > fait flapper L3 ?) > > 2 solutions : > - avoir des RR dédiés à ton réseau interne, et des RR dédiés à tes PE de > peering/transit (valable si ceux-ci sont en très grand nombre) > - ne pas envoyer la full-routing à tes RR, mais uniquement une default > route. Si tu es déjà en MPLS, tu peux aussi d'envisager d'avoir un VPN > "internet", ce qui limite le nombre de label aux nombres de PE de > peering/transit (vu qu'avec le control en BGP, un next-hop = un label). > > Quand on a pas un réseau super complexe en terme de point de peering, ça > peut être une approche valable de ne pas injecter la full-routing sur tous > les routeurs, et de n'avoir qu'une default. Attention pour que ce soit > valable, il faut que tous tes PE de transit/peering se voient en iBGP et en > direct, sinon tu auras un routage sous-optimal. > > Cas concret : > - tu as 2 routeurs de transit/peering en région Parisienne (FranceIX ?), > que tu interconnectes en direct, et tu les peer en iBGP entre eux, et en > iBGP à tes RR. Tu génères une default à tes RR. > - tous tes routeurs voient une default vers les routeurs de transit. Dans > le cas ou tu arriverais sur le routeur de transit 1 avec une destination > connue avec un meilleur AS-PATH sur le routeur transit 2, tu passeras via > ton interco entre tes deux routeurs de transit pour prendre le bon chemin > (routage pas parfaitement optimal, car avec la full routing, ton PE > d'origine aurait su qu'il fallait passer direct par transit 2, mais > acceptable car le surcout est un passage dans un lien direct, que tu peux > avoir pour pas cher). > > Comme matos, tu peux utiliser le bon vieux 7200, en NPE-G2 si possible > (plus tu as de RAM, mieux c'est) ou de l'ASR 1001 du même constructeur > (voire gamme équivalente chez Junip, Brocade, etc.) > Si tu es joueur, tu peux tenter le BIRD sur un serveur, MAIS attention, > aux dernières nouvelles, ISIS n'était pas dispo, et je n'ai rien vu sur les > routes VPNv4/v6. Par contre c'est sans équivalent niveau perf (un serveur > de base c'est 2 Xeon multicore et 48 ou 96G de RAM, ça écrase n'importe > quel routeurs pour du control plane). > > Bouquin de référence sur le sujet : "Definitive MPLS Network Design" > Guichard, Le Faucheur et Vasseur, chez CiscoPress. Chapitre 4, "National > Telco Design". > Ca date un peu, et c'est très orienté Cisco, mais ça reste de la bonne > littérature sur le sujet, même si il faut garder un oeil critique sur des > trucs écrits en 2007 (4em edition). > D'ailleurs si vous avez d'autres références, pas orienté Cisco, merci de > partager ! > > A+ > > Le 22 janvier 2012 09:09, Olivier CALVANO <o.calv...@gmail.com> a écrit : > > Bonjour, >> >> >> Le 21 janvier 2012 20:06, Michel Py >> <mic...@arneill-py.sacramento.ca.us> a écrit : >> > [disclaimer: je ne connais pas ISIS, donc a prendre avec des pincettes >> tout ce que je peux écrire car ça va être inspiré par OSPF] >> > >> >> Olivier CALVANO a écrit: >> >> J'ai un reseau composé actuellement d'une trentaine de routeur >> >> en ISIS et BGP/MPBGP, certain ont la full-table d'autre n'ont que >> >> les routes internes... Chaque routeur a une session BGP avec les >> >> autres, full mesh. >> > >> > C'est pas beaucoup à se mettre sous la dent, comme détails. >> > Si certains routeurs n'ont que les routes internes, pourquoi avoir BGP >> configuré? >> > A quel point(s) tu redistribues ISIS dans BGP et vice-versa? >> >> Alors quand je parle de route interne, c'est pas routes du routeur, >> mais routes de mon >> reseau. Ils ont des session principalement MP-BGP pour le MPLS IP VPN. >> >> 90% des routeurs sont des PE ou P MPLS, les 10% restant sont mes routeurs >> d'accès Internet qui ont eux la full-table >> >> >> >> > >> >> J'ai un petit réseau aux USA, est ce qu'il faut prévoir de mettre >> >> un RR sur chaque continent ? >> > >> > Tu reçois un full-feed aux USA aussi? Ou seulement du peering? >> >> Alors ni l'un ni l'autre, actuellement aux USA, ce n'est que de la >> collecte >> T1/DSL/FIBRE toujours pour le MPLS IP VPN. Je ne remonte pas l'internet >> de notre reseau la bas. >> >> >> >> En lisant la doc sur le sujet, j'ai l'impression que le route server >> ce configure comme >> un routeur normal sauf que l'on rajoute un "route-reflector-client" >> sur le neighbor. >> Je suppose donc que je dois jouer avec le no-export pour ne pas envoyer la >> full table aux routeurs qui ne doivent pas la recevoir. >> >> >> > >> > Michel. >> > >> >> Olivier >> >> >> --------------------------- >> Liste de diffusion du FRnOG >> http://www.frnog.org/ >> > > > > -- > Cordialement, > > Guillaume BARROT > -- Cordialement, Guillaume BARROT --------------------------- Liste de diffusion du FRnOG http://www.frnog.org/
