Le 5 septembre 2014 21:14, Stephane Bortzmeyer <bortzme...@nic.fr> a écrit :
> > Ah au fait, j'ai modifié mon article pour mentionner cette > possibilité (qui n'était apparemment pas dans le RFC). Merci. > > > "Variante sur cette architecture (non mentionnée dans le RFC mais que j'emprunte à Vincent Bernat), annoncer dans le protocole de routage interne une route par machine (un préfixe /32 en IPv4 et /128 en IPv6). Cela résoud ce problème et permet de tout faire en L3, mais, si on a des centaines de milliers de machines, le protocole de routage va souffrir. " Sinon pour soulager le protocole de routage, une solution : des top of racks faisant du routage, un subnet par rack : disons un /26 par rack pour 100 racks. Tu configures tes TOP of rack pour n'annoncer que son /26 vers l'agrégation bien que lui connaitra les 64x/32 En temps normal tes switches/routeurs d'agrégation vont avoir 100 routes dans leur table. Si tu veux bouger un host vers un autre rack, le TOR du rack destination annoncera du coup son /26 et le /32 supplémentaire. Et rien ne t'empêche de changer l'IP de la machine pour qu'elle rentre dans le /26 du nouveau rack. En gros en situation optimale tu as 6400 hosts mais 100 routes dans l'aggreg. Pour couvrir le cas des 100aines de milliers de machines on va dire que tu tu es sur plusieurs DC. Disons un /14 par DC soit 256K hosts, ça fait 1000 racks de /24. Chaque coeur de DC connaitra le /14 du DC d'a cote et les 1000x/24 locaux et éventuellement quelques centaines de /32 more specific locaux, voire venant de l'autre DC si tu bouges des hosts du DC 1 au DC 2. Bref sans doute moins de 10k routes pour joindre 512k hosts. Dans tous les cas, un mec qui a plusieurs centaines de milliers de hosts peut se permettre d'avoir des routeurs prenant plusieurs millions d'entrées en RIB/FIB et BGP gère ça très bien. --------------------------- Liste de diffusion du FRnOG http://www.frnog.org/
