> L'idée est de construire une RIB complète puis de la factoriser > sous forme d'arbre binaire dont on colorie les branches en > fonction du next-hop. A la lecture, on reconstruit une RIB > factorisée sur les couleurs (ou next-hops) et ça correspond au > strict minimum d'informations dont le control-place a besoin > pour que les décisions de forwarding correspondent aux policies > du control-plane.
Si je comprends ce que tu veux dire, ce n'est pas suffisant. Ce que je comprends: à partir de la RIB complète tu construis la RIB réduite en enlevant les préfixes longs qui ont le même next-hop qu'un préfixe plus court (ou en copiant dans la RIB réduite uniquement les préfixes courts qui ont le même next-hop qu'un préfixe plus long). Ce qu'il faut construire, c'est non pas la RIB de taille réduite mais la préfix-list d'une taille raisonnable qui permet de filtrer le full-feed. Si pour réduire ta RIB de 100k routes il te faut une prefix-list de 50k lignes, tu as perdu la bataille. Ceci se complique encore plus quand tu as plusieurs prefix-list en utilisation (une par peer-group); donc dans ta FIB il faut incorporer la notion de catégorie de next-hop et autoriser que le même préfixe long soit filtré sur une catégorie de next-hop et pas sur l'autre. Donc oui la RIB de taille réduite est l'objectif final mais, à moins que le processus soit incorporé dans le code BGP (qu'en disent Cisco et Juniper?), ce que ta moulinette doit produire c'est la configuration de filtrage du full-feed, avec plusieurs peer-groups, et en tenant compte de contraintes du genre taille de la NVRAM et autres. > Stephane Bortzmeyer a écrit: > L'idée me parait excellente et je ne sais pas pourquoi elle > n'a jamais été faite. Ce n'est pas la première fois qu'on a parle. Il y a 10 ans, quand on a commencé à réaliser que les tentatives de garder la table IPv6 agrégée allaient toutes foirer, il y a quelques personnes qui ont discuté cette idée. > Quelqu'un a-t-il fait des simulations avec une vraie table de > routage d'un vrai routeur pour voir combien exactement on gagnait ? C'est vachement variable en fonction de la topologie, mais on peut espérer une division par 3 comme idée de base; mes chiffres sont démodés, ceci dit. Mais là encore on parle de gain théorique. > Jérôme Nicolle a écrit: > Sur AS197422, en simulation, je tombe à 70k routes sur le routeur > parisien. Mais mon algo est loin d'être optimisé et je n'ai pas > testé sur un replay pour l'instant. Avec une préfix-list de combien de long, ou est-ce que c'est le minimum théorique de la RIB requise sans considération de comment tu la construis? > Bertrand Yvain a écrit: > J'imagine que le gain dépend largement du nombre > de peers eBGP (de next-hops en fait). En partie seulement; c'est clair que plus tu as de next-hops moins de gain, ceci dit. > Dans le cas trivial d'un AS stub avec > un seul upstream, tu devrais tomber à 1 route. Seulement si tu inclus 0.0.0.0/0 dans les calculs, ce qui ne me semble pas être une bonne idée. > Jérôme Nicolle a écrit: > Le problème, c'est le cas ou on perde le next-hop > correspondant à la route par defaut. Ca ne me semble pas être une bonne idée de n'avoir qu'une seule route par défaut. Si tu ne fais pas comme Clement (avoir chaque transit qui te l'annonce) il faut au moins avoir une ou plusieurs floating-static, AMHA. > La fullbogons sur un PE, bof, plutot sur un RR qui distribue > entre tes upstream et tes PE. Je ne vois pas ce que ça change? Ou alors j'ai pas bien compris ce que tu suggères. Michel. --------------------------- Liste de diffusion du FRnOG http://www.frnog.org/
