État

Echec!!

Date

Dimanche 08 Mars 2018

Admins impliqués:

Thomas DELABY (à distance), Baptiste GUILLARD, Vincent MESSIÉ

But:

Dans le cadre du projet fibre, remplacer Pessac par Polaris, afin de mettre le backbone en 10Gbps

État des lieux antérieur

Pessac en prod. Le réseau était assez "instable": en effet, la mise en prod des nouveaux switchs d'accès dans les bâtiments nous a forcé, pour utiliser les anciennes fibres, à utiliser les switchs Unifi (Rox & Roucky) pour chainer les switchs d'accès (lien Pessac => Unifi => Quanta). Un problème sur ces derniers, et tout les âtiments tombaient !. Fonctions assurés par Pessac:

  • Switch de coeur principal, connecté notamment à Delicate-cockroach (Hyperviseur), Peach (Firewall), F.O Quantic-Telecom et au réseau DISI.

  • Routage inter-vlans dans 2 zones définis : vlans d'administrations (997,998,988 + tunnel GRE) et vlans "utilisateurs" (999,994,995). Le vlan 980 (Quantic) ne possède pas d'@IP, et le vlan 990 (Disi) est dans une zone séparée (DMZ)

Le nouveau switch était également complètement configuré. Certaines concessions ont du néanmoins êtres faites par rapport à Pessac. Notamment, cet équipement ne peut avoir son interface d'administration dans une VRF. il a donc été nécessaire de:

  • Mettre la vrf admin actuelle dans la zone par défaut

  • Et mettre l'ancienne zone par défaut dans une VRF "users". Globalement, la façon de penser Mikrotik étant très différente de celle de cisco, la configuration a été très laborieuse.

État des lieux postérieur

L'opération ayant été infructueuse, Pessac a été remis en service. Le nouveau switch a néanmoins été installé uniquement pour l'accès (pas de fonctions L3 fonctionnelles, donc), afin d'utiliser les nouvelles fibres. Il est connecté avec Pessac via un LACP en Trunk sur les vlans 995,998 et 999. Les anciennes fibres sont donc libérées.

Machines / Services touchés:

À peut près tout le réseau Rennais ( ͡° ͜ʖ ͡°)

Détail des modifications

(tentative de) mise en prod du nouveau switch : transfers de toutes les IPs et du tunnel Gre sur le nouveau switch. L'équipement avait été configuré au préalable, il était néanmoins assez difficile d'en tester certaines fonctionnalités, telles que le tunnel Gre, etc. Migration de la connexion de delicate-cockroach (Hyperviseur) du LACP vers un lien 10Gbps (via un câble DAC): la nouvelle carte réseau était déjà reconnue, il fallait juste reconfigurer l'interface. Ce lien était fonctionnel. Cependant, openvswitch supporte difficilement ces changements d'interface, et il a fallu complètement rebooter l'hyperviseur pour avoir une connexion pleinement fonctionnelle sur les VMs. Après quelque heures à débugger les problèmes ci-desous, Pessac a été remis en prod en catastrophe.

Problèmes rencontrés

Lors de la mise en prod du switch, plusieurs lien ne fonctionnaient pas, listés ci-dessous (plus de détails dans la section Tests).

  • Lien Disi: l'interface recevait les paquets encapsulés GRE contenant les pings d'Icinga. Cependant, il était impossible, depuis le switch, de joindre l'interface distante du tunnel.

  • Lien avec Peach : Sur Pessac, outre l'IdRAC, Peach était connecté grâce à un lien trunk, et un lien hybride sur le VLAN 994. Peach ne supportant pas les cartes 10G, cette configuration a été gardée pour Polaris. Une fois connecté au nouveau switch, nous avons constaté un fonctionnement très aléatoire.

Ce qui nous laissait un switch pas du tout fonctionnel : impossible de communiquer avec le Firewall, ou avec Brest via le tunnel Gre...

Tests

Tous ces tests ont été effectué en faisant un mirroring des ports incriminés, pour analyser le traffic circulant. Cette fonction du switch a cependant ses limites, car:

  • Les requêtes L2 (ARP notamment) ne sont pas présentes sur le port en mirroring
  • Lors du mirroring, les trames encapsulées dans du 802.1Q (lien trunk) sont désencapsulées.

Lien Disi:

  • une capture sur l'interface du switch nous a montré que le lien aurait du fonctionner (nous voyions passer les pings d'Incinga encapsulé dans le tunnel Gre). Les paquets avaient néanmoins une mauvaise adresse Mac de destination (adresse appartenant au nouveau switch, mais pas de la bonne interface...).
  • routeur 10.35.5.1 joignable, mais seulement après un changement d'adresse mac (voir point plus haut).
  • Impossible de pinger l'interface distante du Tunnel (adresse Renater). Un traceroute nous a montré que le paquet n'allait pas plus loin que le premier routeur (ou la réponse était mal forwardée en retour).
  • il était possible de pinger depuis le switch une adresse sur le réseau wifi eduroam, et vice-versa, mais de façon très erratique (beaucoup de paquets perdus).

Nous avons donc diagnostiqué deux problèmes possibles:

  • Cache ARP du coté de la DISI, renvoyant sur l'adresse de Pessac
  • Whitelistage de Pessac sur le lien DISI, entravant la communication après le changement d'équipement.

Liens avec Peach:

  • Les pings du switch vers Peach ne fonctionnaient simplement pas, quelle que soit l'interface testée.
  • Les pings de Peach vers les IPs du switch étaient très aléatoires (ça marchait une fois sur 5!), et ne fonctionnaient encore que pour les subnets directement connectés (possible de ping le vlan 994, mais pas le vlan 999, par exemple)
  • Les pings vers le pont hertzien étaient possibles (addresse 192.168.254.1), mais cela n'allait pas plus loin... Impossible donc de joindre Internet.
  • La capture vers les interfaces incriminés (2 interfaces de Peach, et connexion Quantic) ne montrait aucun paquets circulant (pas de requêtes, ni de réponses) lors des phases de non fonctionnement. Cependant, comme indiqué plus haut, les requêtes de trop bas niveau (ARP) ne sont pas présentes sur le port en mirroring... Nous en avons déduit qu'il y avait un point bloquant de ce coté-là.

Le fonctionnement de Peach restant assez obscur, il en a été déduis que Peach devait filtrer sur les adresses Mac de Pessac. Et que le changement d'équipement a rendu tous les liens quasi-inopérants.

Liens avec delicate-cockroach:

Pas de problèmes à ce niveau-là, si ce n'est qu'openvswitch a l'air de mal supporter les changements d'interface à chaud. En effet,

  • Lors d'un reload / restart du service networking, des erreurs étaient toujours affichés (anciennes interfaces encore présentes même en les désactivant manuellement, etc.)
  • Après un reload / restart, le lien entre l'interface adm de l'hyperviseur et le switch ne fonctionne pas à tout les coups
  • Impossible de joindre les VMs, que ce soit du switch, ou de l'hyperviseur directement. Cependant, ces problèmes sont également présents sur Pessac, et il semblerait qu'un reboot complet de l'hyperviseur solutionne tout. Ce problème a donc été identifié comme étant inhérant à openvswitch, et non au nouveau switch.

Évolutions futures

Actuellement nous sommes dans une situation ou Pessac et Polaris cohabitent:

  • Le coeur de réseau principal reste Pessac (accès Adista, Disi, Tunnel GRE, et lien vers les serveurs).
  • Cependant, les liens d'accès (vers les chambres et les studios) Passent par Polaris. Ce dernier n'assure pour l'instant que des fonctions de switch, et est connecté à Pessac via un LACP de 2Gbps en trunk sur les vlans 995,998 et 999. Tout est fonctionnel. Les nouvelles fibres sont donc actuellement celles en production. Cela permet non seulement la fin de l'exploitation de l'ancienne fibre, mais également une plus grande robustesse aux pannes à l'accès. En effet, actuellement les équipements de chaque bâtiment sont tous connectés directement au switch, et non plus chainés comme précédemment. Ce qui fait que la panne d'un équipement d'accès n'affectera désormais plus tout le bâtiment.

Pour retirer définitivement Pessac du service certains points sont cependant à considérer:

  • Le nouveau switch ne gère actuellement pas de fonctions L3. Ces dernières sont donc configurées, mais non testées. Et la migration de ces fonctions aurait à nouveau pour conséquence une coupure totale du service rennais.
  • Le changement du firewall semble indispensable, ou du moins de la machine physique assurant cette fonction. En effet, il apparait que Peach ne peut supporter de cartes réseau 10G, n'ayant pas les ports PCI requis. Une machine possible pour assurer cette fonction serait NSA, actuellement retirée du parc. De plus, les problèmes listés précédemment montrent qu'une refonte du firewall Rennais serait la bienvenue...