Encore trop souvent je vois des déploiements dans lesquels les interfaces de loopbacks ne sont pas utilisées… et dans des cas encore trop nombreux la notion de loopback reste incomprise, et pour cause, la première fois qu’on en entend parler ça se passe à peu près comme cela : “Regarde : tu ping 127.0.0.1 et ça répond ! C’est une loopback : c’est génial !” Généralement on met tout ça de côté et on oublie le concept : dommage. A l’heure à laquelle on parle de mobilité de VM, de la nécessité de distinguer l’identifiant d’une machine de son du “locator” avec LISP, de réseaux intelligents offrant de plus en plus de services, quoi de plus simple que de commencer par faire reposer les services réseau de base sur des loopbacks, sans dépendre de la disponibilité de tel ou tel lien physique. Il devient ainsi possible de déplacer un “service” dans le réseau sans dépendre d’une quelconque topologie : il suffira simplement de migrer l’adresse de loopback sur un autre équipement et de l’annoncer dans le réseau via votre protocole de routage préféré.
Et pensez bien à choisir une adresse différente par “service”, vous n’en ferez jamais trop, par exemple : iBGP, administration, point de rendez-vous multicast, peer MSDP, tunnel end point (IPsec, IPv6/IPv4…), serveur NTP, les exemples ne manquent pas. J’ai vu trop de fois des clients se demander comment migrer un service car cela nécessitait d’en migrer un autre (ou alors de reconfigurer tous les autres équipements du réseau). Cela est bien sûr valable pour IPv4 et IPv6 ! Si vous démarrez le déploiement d’une infrastructure IPv6, pensez-y!
Authors
