Cisco France Blog

Happy admins ?

2 min read



Dans son dernier article Jean-Marc Barozet a expliqué “Happy Eyeball”, ou comment le choix se faisait entre IPv4 et IPv6. Si pour l’usager c’est parfait car cela garantit a priori que le choix se fera en fonction de la performance, cela introduit un côté non déterministe qui peut ne pas plaire à tous les admins… Voici un aperçu de ce que pourrait être un dialogue entre un usager qui se plaint d’un problème de performance à son admin:

USAGER  – Bonjour, je vous appelle pour un problème de performance vers www.monservicecloud.com.
ADMIN  – Très bien je regarde, il s’avère que ce service est disponible à la fois pour IPv4 et IPv6. Pourriez-vous me dire quelle version de l’Internet vous avez utilisé?
USAGER  – Euuhhhh
ADMIN  – En ce cas je ne peux rien faire, n’hésitez pas à regarder ce point avant de m’appeler la prochaine fois. Bonne journée!

Ajoutons à cela les mécanismes de tunneling automatiques qui permettent à un host de faire de l’IPv6 sans même qu’IPv6 ne soit déployé sur le réseau (ISATAP, 6to4, TEREDO…) on peut se retrouver dans des solutions plus cocasses où l’admin troubleshoot pendant des heures le réseau IPv4 alors que la requête est IPv6… Soyons positifs l’implémentation d’IPv6 sur Windows s’améliore et les tunnels sont de moins en moins automatiques. Par exemple, Teredo, qui a mon avis est à IPv6 ce que le doryphore est à la pomme de terre, n’est plus utilisé sur Windows 7 que si  le service n’est accessible qu’en IPv6 et qu’il n’y a pas d’autre mode de connexion IPv6… On progresse!

Pour toutes ces problématiques, et que l’on soit intéressé ou non par avoir IPv6 sur son intranet, il y a une chose à retenir: il faut avoir de la VISIBILITE des flux IPv4 et IPv6 sur le LAN, et ce si possible dès la couche d’accès. Côté Cisco voici quelques exemples de solutions disponibles:

  • Flexible Netflow: visibilité des flux IPv4/IPv6
  • IP SLA: permet de faire des mesures actives IPv4/IPv6 et de collecter des mesures de performance
  • Performance Monitor: permet d’avoir des détails sur un flux IPv4 ou IPv6 donné (RTP ou TCP) sur les switchs ou routeurs (déséquencement de paquet, gigue…)
  • NBAR2: deep packet inspection v4/v6 (sur l’accès WAN aujourd’hui)

Si on reprend notre échange précédent entre notre usager et notre admin cela va donner:

ADMIN  – Bonjour je suis votre administrateur réseau sur site. Je viens d’observer une anomalie sur le trafic qui est réalisé depuis votre poste de travail. Une quantité importante du trafic est de type “tunnel” et je constate également une dégradation des performances pour les flux véhiculés dans ce tunnel. Si vous avez 5 minutes, je vous propose de prendre un café, et pendant ce temps je vais prendre la main sur votre ordinateur et régler ce qui me semble être un petit problème de configuration sur votre système d’exploitation.

Alors, ça fait rêver?

Authors

Jerome Durand

Technical Solutions Architect

Laisser un commentaire


1 commentaires

  1. A quand un service Cisco par défaut qui averti l’admin : “des machines de votre réseau veulent utiliser IPv6 or vous n’avez pas configuré IPv6 sur votre réseau interne. Ceci représente un risque de sécurité car un intrus pourrait se faire passer pour le routeur légitime de votre réseau interne. Merci d’activer à minimum une configuration IPv6 de base dans votre réseau interne pour éviter ce risque.”.

    Car la majorité des OS et des périphériques d’entreprises sont activés en IPv6. Il y a qqe temps un net admin m’a dit : “ipv6 on n’a pas de besoin”, je lui ai répondu “mais êtes vous sûr qu’il n’y a pas déjà un impact pour votre SI ?”….

    Tiens une autre anecdote, chez un grand compte français après des heures d’analyse par un expert du réseau qui ne comprenait pas pourquoi il n’arrivait à rien trouver comme flux à problème … en jetant un œil à la machine, je remarque que les serveurs d’applis utilisait IPv6 pour communiquer avec une autre en DMZ. Le problème venait d’un firewall “pseudo-matériel” (je vais taire la marque) qui avait un support bogué d’IPv6 et droppait une partie des paquets aléatoirement. Impossible de mettre le firewall à jour, il nous a donc fallu désactivé IPv6 sur les machines qui ne devait pas être utilisés car le client savait même pas que “ça existait” …. Sauf que non seulement c’était activé sur les machines mes également sur les FW et sans règles de filtrages …. SIC !

    Dans un autre registre, à quand un opérateur de téléphonie mobile qui aura le courrage de déployer de l’IPv6 pour le grand public en France ?

    Free va-t-il encore être le premier ? Alors que SFR et Orange on commencer les tests depuis longtemps et qu’il propose ce service pour les entreprise (ADSL par exemple) ?

    Va-t-on avoir du LTE en IPv6 ?

    Pleins de bonnes questions …