2015-11-02 18:15 GMT+01:00 Nicolas V <[email protected]>: > Bonjour, > > Je cherche à interconnecter plusieurs sites (3 au minima) via une boucle > (de 1 à x*10G entre chaque site avec possibilité éventuelle d'ajout de > liens 1G). Le but étant de pouvoir faire transiter du L2 de manière > transparente. > > J'ai suivi le mail de Jérémy Martin "Design réseau L2", mais j'ai quelques > contraintes / une architecture un peu différente : > - Des routeurs ASR9k sur chaque POP => evpn / mpls possible > - Des nexus sur chaque POP => fabricpath possible (mais licence nécessaire) > > Ça dépend du type de service tu vas prêter.
- Si c'est bridged multipoint L2 VPN pour les clients B2B, un solution en base de « vrai MPLS » est vraiment désirable. En ce cas tu as besoin d'un vrai routeur MPLS comme Cisco ASR ou Juniper MX dans chaque PoP. Normalement ayant un vrais réseau MPLS tu peux prêter différent types des services pour différents types des clients : L2 p2p ou full-mesh des p2p avec Martini/Kompella l2circuit/v2vpn aka pseudowire aka VPWS aka PWE3, multipoint bridged ethernet avec VPLS ou EVPN, L3VPN, NG-MVPN, si t'en as besoin, hub-and-spoke L3VPN etc etc, par-dessus la même infrastructure du coeur. Les vrais routeurs comme ASR/MX sont désirables ici parce que en dehors de forwarding et protection ce type d’application aussi demande les choses comme policers pour limiter le débit, filtres ACL, conteurs pour billing, peut-être NetFlow pour la statistique etc etc. Le scaling (comment on dit scaling en français ? graduation ?) est une grande considération aussi dans ce cas : normalement tu veux être capable de servir des milliers des clients, avoir les tableaux full BGP etc etc. - Pour interconnexion des DCs (les vrai DCs avec des serveurs, à la différence de SP POPs) je préférerais EVPN/VPLS et plus ou moins le même type de design comme dans le cas précédent, mais les autres options comme Cisco fabricpath sont possibles aussi. Moi personnellement je déteste toutes les variations de MAC-in-MAC et toutes les technologies qui essayent de cacher la complexité en façon « Ethernet over MPLS over GRE over IP over Ethernet over n’importe quoi » (Cisco OTV) avec le control-plane propriétaire, mais pour les gars du monde des serveurs c'est souvent un avantage puisque la modèle des applications MPLS demande un certain niveau de connaissance et expertise. Normalement ce type de solution prétende d'être plug-and-play, assez facile à configurer, et réalisée par utilisation des commutateurs « optimisés pour DC », comme Cisco Nexus. - Si ça va être un réseau d'infrastructure, c'est à dire tu as besoin de certain nombre des service fixes et tu es sûre que tu n'as besoin ni des milliers des instances des services (VPNs, VRF, vlans, policers, interfaces) ni des millions des adresses MAC, IP-routes etc, tu peux choisir une solution MPLS au base des commutateurs qui supportent MPLS, comme, par exemple, Extreme X460/670 ou anagogiques. Ce type de solution va bien pour MPLS in the access, quand tu as besoin d'agréger des DSLAMs/MSANs, ou faire une extension d'une lien de peering en utilisant des pseudo-wires, etc. Et c'est, sans doute, beaucoup moi cher que les solutions au base des « vrais routeurs ». Une mis en garde importante ici c'est les fonctions MPLS supportées par les commutateurs. Normalement ce type d'équipement a plein des limitations, trucs insupportés et mal documentés et doit être bien testé avant être mis en production. (Pardon pour mon mauvais français :) -- Pavel --------------------------- Liste de diffusion du FRnOG http://www.frnog.org/
