Le 17/01/12 06:37, Michel Py a écrit :
Je crois que j'ai saisi maintenant; tu sépares control-plane et
forwarding-plane, tu fais ta control-plane et ta moulinette dans un PC avec de
la RAM et c'est le switch qui fait la forwarding plane et qui pousse les
paquets. Donc le switch n'a même pas de session BGP avec les transits, c'est le
PC qui lui donne directement la RIB réduite.
C'est ça, et c'est pourquoi j'étais en train de me grater la tête en
comprenant pourquoi tu parlais de prefix-list.
Faut avoir vraiment confiance dans le PC et dans le système entier; j'avais
dans l'idée de recevoir le feed sur le switch, en le filtrant.
J'ai plus confiance en un speaker BGP opensource que dans les
implémentations de cisco et juniper, en tout cas pour des choses simples
comme ça. Pour du MPLS ou du LISP, ils sont surement plus avancés. Quand
au PC, qu'il soit dans le route-processour ou dans le rack d'à coté,
c'est bien la même chose, non ?
>> 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.
Plus tu as de next-hop *en transit*, car les routes des peers sont peu
ou pas modifiées finalement.
>> 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.
Au début j'avais dans l'idée d'inventer les routes agrégées à la lecture
de l'arbre. C'est ce qui économise le plus de routes.
Dans le cas assez fréquent on un réseau a un transitaire "principal" et
un de secours, c'est assez logique d'avoir une default et des
exceptions, non ?
> 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.
Pas grave, puisqu'elle est crée par le RR ;) Après qu'on aie 0.0.0.0/0
ou tous les /8 à la place, ça se discute. En limitant la remontée de
l'arbre à /8 on minimise l'impact d'une bascule mal synchronisée, on
peut encore plus facilement "loadbalancer" sur plusieurs transitaires de
même poids, et finalement on va au moins dirigier "grosse maille" le
trafic par continent (zone ARIN par L3, zone APNIC par TATA, ... par
exemple.)
>> 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.
Je crois que c'est plus clair maintenant, non ?
Le seul inconvénient de ce montage, c'est qu'il n'est pas simple d'être
transparent pour les peers. Il n'y a pas de "proxy BGP" sur les
GroSwitchs, au mieux une capacité limitée de faire du NAPT. C'est
suffisant, mais c'est moche :(
C'est ptet pour ça que des /64 d'interconnexion sont pratiques,
finalement ;)
--
Jérôme Nicolle
06 19 31 27 14
---------------------------
Liste de diffusion du FRnOG
http://www.frnog.org/
