Retour des RMLL !

Les RMLL se sont terminées il y a près d’un mois, ce qui nous a permis de faire beaucoup de rencontres et d’échanges au fil de cette semaine. Iloth était en charge du réseau. La gestion d’un tel évènement était pour nous une première et nous avons eu de multiples soucis. Afin que notre experience serve aux éditions futures nous allons décrire nos différents soucis et conseils dans cet article.

Ne pas sous-estimer la charge de travail avant l’événement

En effet, se dire que tout est bon et que l’on verra une fois sur place n’est pas suffisant, nous avons eu des configs erronées chez notre transitaire et des VLANs mal propagés sur l’université. Si nous avions testé cela sur les semaines precedentes nous nous serions évité quelques soucis (pas de net dans les amphis 6.xx, réseau sur les journées grand public le samedi quasi inexistant…).
Un des gros problèmes que nous avons eu a été que notre transitaire ne propagait pas nos annonces BGP à tous les siens. Nous avons été obligés de monter des tunnels au travers de Hivane (bigup bisous toussa toussa) et de BNT afin de s’annoncer. Ce bricolage a induit d’autres soucis tels que la gestion du MTU.

MTU !

Comme dit precedemment, notre traffic passait via deux tunnels GRE. La MTU sur ces tunnels était de 1476, nous avons donc du activer le TCP MSS CLAMPING sur notre routeur de cœur afin de bien fragmenter les paquets. Malgré cela de nombreuses machines ont dû régler leur MTU manuellement afin de parvenir à fonctionner convenablement. Un des diagnostics simples à effectuer est d’ouvrir différentes pages web, lorsque certaines bloquent, tenter de pinguer le serveur web. Si le ping passe, il y a des chances que ce soit effectivement un soucis de MTU. Un autre moyen est tout simplement de verifier avec tracepath ou traceroute –mtu.

DHCP

L’utilisation d’un serveur DHCP sur un aussi gros réseau est assez compliqué : notre serveur DHCP (que l’on nommera autoritaire) a bien fait son boulot. Néanmoins on s’est très vite retrouvé avec plusieurs autres serveurs DHCP squatteurs. Le réseau était découpé en plusieurs VLAN histoire de limiter la propagation cependant ce n’est pas suffisant. La solution pour contrer ce genre d’attaque est de filtrer les réponses DHCP, cependant nous n’étions pas en mesure de le faire sur l’ensemble du réseau (voir point suivant). La solution adoptée est le RFC 2322 connu sous le nom de peg-dhcp. Autrement dit, c’est un serveur DHCP à base de pinces à linge sur lequel on écrit une adresse ip unique et que l’on donne aux visiteurs. Le reste de la conf IP est inscrite sur une feuille. Cela permet de faire venir les gens sur le stand pour discuter en plus ! D’une peer, deux coups.

Se greffer à un réseau existant

Tout le réseau ne nous appartenait pas. On a rajouté du matériel à nous sur le réseau de la fac. On ne controllait donc pas tout le matériel. Typiquement on n’avait pas la main sur les switchs des bâtiments 5, 6 et 31 ni dans les différentes résidences du CROUS. Il a donc fallu collaborer avec la DSI de l’université ce qui est difficile surtout lorsqu’on se rend compte de certains soucis lors du week-end…
On se retrouve avec des soucis non résolvables pour le reste de l’évènement.

Statistiques du réseau

1,25km de fibre déployée sur l’esplanade et l’um2
647 mac différentes sur le réseau wifi du village
1300 mac differentes sur le serveur DHCP
Quelques To échangés mais au final vraiment pas beaucoup pour un évènement geek de cette taille, c’est étonnant.

Et voilà pour cette édition 2014.

Et enfin la dreamteam Iloth

Photo par @blatula

 Sans oublier notre teneur d’echelle professionnel :