On 18 Jan 2012, at 05:59, Michel Py wrote: >>>>> 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. > > C'est suffisamment tordu comme idée pour être intéressant :P
C'est le principe d'OpenFlow, ce n'est pas tordu. http://en.wikipedia.org/wiki/OpenFlow http://www.openflow.org/ > En théorie, ça peut marcher. Ceci dit, Le RR et le switch n'ont pas la même > IP, donc va falloir changer le next-hop des routes que tu annonces et > remplacer l'IP du RR par l'IP du switch, mais bon c'est pour ça que route-map > a été inventé. > Au niveau codage, je ne vois pas quelle autre solution tu as que de modifier > un des bgpd opensource. Sinon BIRD est le daemon BGP utilisé par les IX pour leurs route servers, donc le code est bien testé. Mais c'est le genre de magouille pour lesquelles ExaBGP a reçu tant de petits soins récemment : regarde la dernière version pour prendre conscience de toutes clownerie possibles : ton code, tes magouilles. Tu peux lire les routes (forme textuelle) reçues des peers en STDIN, faire ce que tu veux et diffuser le résultat au même (au d'autres peers) via STDOUT. http://code.google.com/p/exabgp/source/browse/#hg%2Fetc%2Fexabgp%2Fprocesses > Au niveau pratique, ça fait quand même un peu usine à gaz sur les bords. 2 > boites, 2 fois le risque de panne, 3 fois la complexité... Plutot, usine nucléaire en zone sismique :D > Va falloir avoir un budget Stroh important Il va vraiment falloir que je découvre le Stroh, il semble que j'ai toutes le prédispositions pour aimer :p >> 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. > > Pas moi, surtout quand c'est un clown de mon genre qui pisse du code de porc > qui modifie un opensource. C'est clairement le cas, mais on trouve les même codeurs chez Juniper/Cisco/... :D >> Plus tu as de next-hop *en transit*, car les routes des >> peers sont peu ou pas modifiées finalement. > > Oui, les routes des peers on essaie de ne pas toucher, merci pour la > précision. Centraliser BGP avec des serveurs qui ne font que route reflector est un design assez déployé. C'est pour cela que les operateurs poussent http://tools.ietf.org/html/draft-ietf-idr-bgp-multisession-06 Afin qu'un bug sur une session BGP IPv6 (par exemple) ne fassent pas tomber leur réseau MPLS avec SLA. Thomas --------------------------- Liste de diffusion du FRnOG http://www.frnog.org/
