au secours, mon réseau fuit … que faire ?

Dans un post précédent, je montrais combien il était facile de faire un réseau avec des fuites. Il suffit pour cela d'avoir plus d'un point de routage.

Un réseau avec des fuites présente quelques inconvénients. Il n'y pas de confidentialité des données. C'est un réseau avec un "Man In The Middle" intégré !  En plus, ces fuites consomment de la bande passante. Sur un campus un peu développé, il peut y avoir plusieurs dizaines de switches, avec une toile d'araignée pour bien mailler le tout. Eh bien, cette toile d'araignée diffuse pour rien toutes ces fuites. Le réseau gaspille de la précieuse bande passante. Mais alors, que faire ?!

faire du routage symétrique …

La première idée qui vient à l'esprit, c'est d'instaurer un point de routage unique. Il faut y réfléchir à deux fois. En effet, il faudra que l'ensemble du trafic routé passe par ce point unique. Du coup, le réseau sera mal optimisé (pire qu'avec Spanning Tree, c'est dire …). Le point de routage unique est envisageable sur un réseau de taille modeste. C'est irréaliste sur un réseau complexe.

ARPer plus souvent ?

Et si on envoyait les ARP toutes les 290 secondes ? Le bail des mac@ sera ainsi constamment renouvelé avant son expiration (300 secondes). Comme cela, on aura des tables de mac@ bien à jour, et il n'y aura plus de fuites liées au routage asymétrique … Oui, mais il va y avoir beaucoup de ARP à diffuser un peu partout. En fait, 50 fois plus. Je connais plus d'un responsable réseau qui va hésiter à faire cela.

faire durer les mac@ ?

Bon, alors, il n'y a qu'à mettre 4 heures à la place de 5 minutes pour les tables de mac@... Cela fait peur aussi. En effet, à vue de nez, la taille des tables de mac@ va être au moins 48 fois plus grande ! Et si jamais les tables débordent, les conséquences sont encore pires.

choisir la voie du milieu …

Le plus raisonnable, c'est d'éviter les solutions extrêmes et de rechercher un compromis. En prenant des temporisations de l'ordre de 30 minutes, on arrive à des chiffres moins préoccupants : 8 fois plus de ARPs, et des tables de mac@ 6 fois plus grosses. En complément, on peut aussi réduire le nombre de ARPs en limitant le nombre de points de routage.

Le plus simple est de les associer 2 par 2 à l'aide de VRRP ou d'un protocole propriétaire équivalent.

Crédit photo : © ots-photo - Fotolia.com

Pascal Bonnard

Depuis 2004, je m’occupe d'ingénierie de commutateurs Ethernet (switches en anglais). Comme je suis curieux de nature, j'ai voulu savoir ce qu'il y avait sous le capot ... et c'est là que j'ai vu tous ces protocoles qui ne nous veulent que du bien, mais qui posent d'inévitables questions de sécurité. Sont-ils fiables ? Peuvent-ils être trompés ? Il me semble que ce domaine est peu documenté, et que les informations disponibles sont souvent incomplètes, parfois erronées. Je désire vous faire partager mes connaissances qui s'appuient sur des tests en laboratoire ainsi que sur plusieurs centaines de machines opérationnelles.