Bonjour Fabien, REP est conçu principalement pour le ferroviaire, il permet de faire une boucle pour connecter la signalisation, la téléphonie d'urgence, les panneaux d'attente etc. On retrouve cette technologie et ses concurrentes de loop L2 sur la plupart des lignes de métro avec une double boucle optique. On le voit aussi sur des boucles de pylônes radio. Pour ces 2 cas d'usage on trouve aussi souvent la présence de PTP, qui n'a rien à voir avec REP mais est souvent demandé par la signalisation en ferroviaire comme en radio.
Le stretch L2 pose beaucoup de problèmes, effectivement en PCA/PRA on veut pouvoir tout migrer sans réadresser et sans basculer les subnets de façon binaire. Parfois on veut même cette flexibilité en prod tout court pour faire du VMotion inter-site par exemple. Les technos de fabric type TRILL / SPB comme FabricPath ont permis de faire du stretch doit disant scalable, en vérité les incidents sont fréquents et fortement impactant. On en vient à VxLAN + EVPN où l'usage de MAC-VRF permet d'étendre des réseaux proprement, sans avoir les risques de la génération précédente de fabric. Bien sûr quelqu'un de plus orienté WAN peut aussi faire du L2 en MPLS EVPN ou PBB s'il a besoin de peu de ports. Pendant longtemps on a cru que la résilience était l'affaire du réseau, si on regarde ce qu'on fait maintenant sur les architectures applicatives modernes à base de conteneur notamment, on se fou de l'IP et on cherche à remonter la résilience dans l'application. Et pas sur un load balancer couplé à des VLAN étendus avec FW qui synchronisent les sessions etc... Reste qu'il faut bien pouvoir gérer les applications existantes qui ont besoin de ce modèle vieillissant, qu'on nomme le "METRO DATACENTER" et qui a fortement percé au début de la dernière décennie en faisant tout synchroniser entre 2 sites (SAN, SGBD, ...) Si tu peux fais du VxLAN, si ton réseau est important utilise des équipements dédiés hors fabric pour porter les HA des FW. Enfin, incite les équipes système à gérer la redondance dans l'app, et à utiliser un 3e site comme quorum de vote pour les SGBD et autres clusters (ça évite le split brain et sauve des grains de café) Jean-Charles BISECCO -----Message d'origine----- De : frnog-requ...@frnog.org <frnog-requ...@frnog.org> De la part de Michel Py Envoyé : samedi 21 novembre 2020 20:25 À : 'Fabien H' <frnog.fab...@gmail.com> Cc : Liste FRnoG <frnog@frnog.org> Objet : RE: [FRnOG] [TECH] CISCO REP vs LACP > Fabien H > Certes. (Bon sur un ASA, quand le L2 remonte, c'est pas trop grave, ça se > passe assez bien). Sauf quand ton réseau est coupé et devient actif/actif car les deux cotés pensent que l'autre coté est mort. Quand çà remonte, tes deux ASA vont re-synchroniser, çà va être laid non pas pour les ASA mais pour tout le reste de l'infrastructure non seulement va se retrouver avec des sessions TCP qui perdent les pédales mais en plus qui a continué a faire des transactions en ignorant que l'autre coté faisait pareil. > Mais du coup ça veut dire qu'on abandonne les archis redondantes de FW ou > autres ? Bien sur que non. La redondance à l'intérieur du même datacenter, même si çà coute cher il faut être con pour ne pas le faire. Alim redondantes hot swap, disques en RAID, firewalls actif/standby avec heartbeat et synchronisation, tout çà c'est nécéssaire. Mais çà reste de la redondance LOCALE; a moins d'avoir de la fibre noire en chemin séparé entre les deux cotés, c'est fondamentalement pas bon d'étendre le L2 au-delà du campus. > Ou alors il faut le faire en L3 ? Non seulement en L3 mais probablement dans les couches plus hautes aussi, suivant l'application. Michel. --------------------------- Liste de diffusion du FRnOG http://www.frnog.org/ --------------------------- Liste de diffusion du FRnOG http://www.frnog.org/
