Journal Simuler la perte du lien ethernet (débranchement de câble)

Posté par  .
Étiquettes :
3
29
mai
2012

Bonjour,

Afin de pouvoir tester automatiquement des cas de panne réseau (perte link), je souhaiterais éviter l'intervention humaine visant à aller débrancher un câble pour de vrai, mais dire à la carte / noyau de faire comme si le câble n'était plus là.

Or je ne trouve pas de solution satisfaisante, voici ce que j'ai déjà essayé:

  • "ip link set ethx down" renvoie une erreur à l'application
  • "ifdown ethX" est évidemment vu de l'application
  • iptables n'affecte pas les sockets RAW

  • il est impossible avec ethtool de modifier l'autonego pour envoyer une valeur invalide, le driver s'y refuse.

       advertise N
          Sets the speed and duplex advertised by autonegotiation.  The argument is a hexidecimal value using one or a combination of the following values:

    [..]
    0x8000 2500 Full(not supported by IEEE standards)

  • éteindre le link niveau switch n'est pas toujours envisageable, j'ai des câbles directs entre machines.

Le mieux que j'ai trouvé, c'est une boucle qui demande à la carte de redémarrer l'autonégociation toutes les secondes. Ainsi je n'ai plus de link.
while true ; do ethtool -r eth1 ; sleep 1 ; done

Existerait-il un moyen de forcer la déconnexion du lien ?

http://lxr.linux.no/#linux+v3.4/net/core/ethtool.c

  • # l'arrachage

    Posté par  (site web personnel) . Évalué à 1.

    Personnellement, je ne ferai jamais confiance à ce genre de test… Tu veux simuler un arrachage ou une coupure => Mieux vaut le faire pour de vrai! Ainsi, tu auras toujours la certitude que tu as fait en condition réelle.
    Imagine que ton test passe bien en simulant l'arrêt mais le jour d'un vrai débranchage, ca se passe mal.. Ton chef te dira : Tu n'as pas testé en condition réelle.

    • [^] # Re: l'arrachage

      Posté par  . Évalué à 3.

      Ouais bon… Si tu dois développer un truc et à chaque fois dé/rebrancher le cable, ça devient vite chiant. Y a peut-être un autre truc à la vas-vite, c'est la "virtualisation".

      • [^] # Re: l'arrachage

        Posté par  . Évalué à 10.

        Non non, il a raison, toujours tester en situation réelle !!
        CNR

    • [^] # Re: l'arrachage

      Posté par  . Évalué à 5.

      Tu passe chaque nuit vers 2 ou 3h du mat' débrancher le cable lors du lancement du test pour l'intégration continue histoire de vérifier qu'il n'y a pas de régression ?

      Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

    • [^] # Re: l'arrachage

      Posté par  . Évalué à 10.

      /me se demande comment on certifie des centrales nucléaires contre les crash d'avions de ligne…

      ------------>[ ]

      • [^] # Re: l'arrachage

        Posté par  . Évalué à 10.

        Bah on essaie et si ça foire, on fait passer ça pour un tsunami.

        Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

      • [^] # Re: l'arrachage

        Posté par  . Évalué à 0. Dernière modification le 29 mai 2012 à 17:03.

        C'est donc à ça que ça sert les terrosistes ? A tester la sécurité des installations ! Si ça résite, c'est que c'est ok.

        D'ailleur, on fait appelle a des consultants en sécurité informatique pour tester tout ça.

        " Michel, est-ce que tu peux te faire peter avec des explosifs au pied de la tourre pour voir si ça tient ? Merci"

      • [^] # Re: l'arrachage

        Posté par  . Évalué à 9.

        Sachant que le poids et donc l'inertie de l'appareil est sensiblement différent avec et sans les passagers :)

        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

        • [^] # Re: l'arrachage

          Posté par  . Évalué à 3.

          Et puis vu la complexité des avions, il me semble raisonnable de faire des campagnes de test pour chacun d'entre eux et donner une homologation par modèle.

      • [^] # Re: l'arrachage

        Posté par  (site web personnel) . Évalué à 4.

        Simple : on peint une grand croix rouge pour leur signaler «pas là, non, pas là!»

      • [^] # Re: l'arrachage

        Posté par  (site web personnel) . Évalué à 10.

        on laisse les militants anti nucléaire faire les tests de résistance…

  • # au niveau module ?

    Posté par  (site web personnel) . Évalué à 6.

    Peut-etre que tu peux forcer l’arrêt du module drivers de la carte réseau ?

    "La première sécurité est la liberté"

    • [^] # Re: au niveau module ?

      Posté par  . Évalué à 7.

      C'est pas évident, il me semble que tu ne peux pas décharger un module si la carte est active (le module étant occupé).

      En plus, ça n'est pas strictement équivalent vu qu'avec le module enlevé, la carte n'existe plus en mémoire. Je ne sais pas si ça correspond à son type de panne.

      Non, je pense que l'idéal c'est de la virtualisation, avec un bon mode opératoire

      • tu testes en environnement restreint sur des VM ;
      • une fois le comportement validé, tu appliques ta configuration sur l'environnement physique ;
      • tu testes en réel en débranchant le câble ;
      • si le comportement n'est pas celui attendu, tu récupères les logs, tu les analyses et tu retournes en environnement restreint pour refaire des tests.

      Les tests de développement directement sur l'environnement final, ce n'est jamais bon.

      Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

      • [^] # Re: au niveau module ?

        Posté par  . Évalué à 5.

        Après ça peut être contraignant d'utiliser une VM pour ça (lourdeur, mise à jour de la VM, etc), mais j'avoue que là j'ai du mal à voir d'autres solutions que celles déjà présentées.

        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

        • [^] # Re: au niveau module ?

          Posté par  (site web personnel) . Évalué à 3.

          Peut être qu'il est possible de monter un bridge ethernet à l’intérieur de l'os et de le couper au besoin ?

          "La première sécurité est la liberté"

          • [^] # Re: au niveau module ?

            Posté par  . Évalué à 2.

            L'idée du bridge est pas mal, on peut imaginer ça avec des conteneurs et une interface virtuelle qu'on coupe.

            Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

  • # Je ne suis pas sur

    Posté par  . Évalué à 6.

    un bridge ? avec une interface tun/tap ?

  • # Avec ton switch

    Posté par  . Évalué à 4.

    Désactiver le port au niveau du switch ? (si celui-ci est administrable)

  • # man ip

    Posté par  (site web personnel) . Évalué à -7. Dernière modification le 29 mai 2012 à 16:34. 

    ip link show

    par exemple paour une carte wifi qui mer…:
    #!/bin/bash
    while true ; do ping -c 2 192.168.0.254 2>&1 > /dev/null ; RET=$?; [ $RET != 0 ] && /etc/init.d/networking stop && rmmod rt2500usb && sleep 1 &&
    modprobe rt2500usb && /etc/init.d/networking start; sleep 10 ; done

    Système - Réseau - Sécurité Open Source

    • [^] # Re: man ip

      Posté par  . Évalué à 1.

      Je vois pas trop le rapport entre le sujet du commentaire et le contenu.

      De plus, tu remarqueras que décharger le driver implique de supprimer le device, ce qui sera visible de l'application, cf cas ifdown.

      • [^] # Re: man ip

        Posté par  (site web personnel) . Évalué à 0. Dernière modification le 29 mai 2012 à 18:10.

        La commande ip link show indique si le cable est connecté ou pas.

        Ce n'est qu'un exemple, je n'ai pas dit que c'est une solution adaptée à ton soucis.

        Faire un ifdown n'est pas equivalent à un cable debranché.
        La solution qui s'en approche le plus c'est de couper le port coté commutateur, mais tu as a un cable en direct…

        Le bridge idem.( cela ne simule pas une coupure du lien, cela peut interrompre les paquets )

        Parfois il n'y a pas de solution satisfaisante.

        Système - Réseau - Sécurité Open Source

  • # Précisions

    Posté par  . Évalué à 2. Dernière modification le 29 mai 2012 à 16:47.

    Trois questions qui peuvent orienter les réponses.
    1. Tu mets quoi dans tes RAW sockets ? C'est du TCP/IP ou UDP/IP ? Autrem chose qu'IP ?
    2. Tu fais quoi comme genre de tests ?
    3. Tu veux simuler quoi exactement comme panne ?

    • [^] # Re: Précisions

      Posté par  . Évalué à 1.

      1. Des fois le système récupère des trames ethernet, des fois c'est de l'udp, il y a de nombreux cas et applicatifs différents, d'où une méthode générique proche du 3.
      2. Vérifier que les mécanismes de redondance et de monitoring font leur boulot, de manière fiable et reproductible.
      3. débranchage de câble réseau / panne d'un switch / panne d'un port du switch.

      • [^] # Re: Précisions

        Posté par  . Évalué à 3.

        En fait ma question était est ce que tout ce que tu veux c'est voir ce qui se passe quand y'a des paquets qui partent vers /dev/null ou lorsque tu perds le, ou un des, lien de ta machine.

        Si tu veux voir ce qui se passe quand des paquets disparaissent tu peux soit jouer avec le routage, soit modifier la libc/ton programme pour dropper certains paquets, soit mettre une boite quelque part sur le réseau qui fait ce job.

        Et c'est plus sain comme design par ce que c'est plus facilement portable et tu fais pas trop mumuse avec un comportement spécifique comme la désactivation d'une carte réseau, et tu peux faire des choses beaucoup plus violentes ou précises. Pour le routage même avec du broadcast tu dois pouvoir jouer avec la table locale, ip route show dev eth0 table local pour tout dégager et faire oublier à une interface réseau qu'elle doit participer à un broadcast.

  • # Gateway

    Posté par  . Évalué à 2.

    Changer sa gateway pour une adresse IP qui n’existe pas sur ton réseau, ça marche pas trop mal pour simuler une panne réseau.

    • [^] # Re: Gateway

      Posté par  . Évalué à 1.

      J'ai des sockets RAW ainsi que du broadcast, et n'utilise pas la route par défaut.

    • [^] # Re: Gateway

      Posté par  . Évalué à 4.

      C'est une très bonne technique si tu veux simuler un problème quelque part sur le chemin de ta couche 3. Ce qui est souvent ce qu'on cherche à faire. Tu balances tout temporairement vers un blackhole. On peut jouer a un niveau plus applicatif / libc selon la nature des tests.

      Après dans son journal il parle explicitement de perte de link, donc ca suppose une panne en couche 1 sur la machine de test. Dans ce cas ca ne serait pas forcément la bonne technique.

      Je m'étonne du nombre de réponses sans être certain de ce qu'il test et pourquoi. Mais dans le doute celle là elle la plus censée.

  • # simulateur de réseaux ?

    Posté par  . Évalué à 2. Dernière modification le 29 mai 2012 à 17:01.

    Il me semble avoir vu il y a longtemps ici un journal sur un logiciel de simulation de réseaux, peut etre ca : http://www.gns3.net/ ou ça http://clownix.net/

  • # Mettre un utilisateur à coté et partir prendre un bain

    Posté par  (site web personnel) . Évalué à 7.

    Ça, c'est ma méthode pour m'assurer d'avoir une panne /o\

  • # C'est trop facile

    Posté par  . Évalué à 5.

    Un petit robot en mécano : deux chenilles, un bras télescopique, une "main", une connexion wifi, une caméra. Tu peux le déplacer à distance dans ton datacenter et simuler un débranchage de câble depuis ta station de travail !

    J'ai résolu au moins en partie ton problème ? Ah merde non j'ai pas encore le robot prêt pour te l'envoyer par la poste :/

    ---> []

  • # coupure physique par robot micro-contrôleur

    Posté par  . Évalué à 5. Dernière modification le 29 mai 2012 à 18:48.

    poser un interrupteur sur le câble piloté par un contrôleur arduino relié par usb/série sur la machine, encapsulé une commande appelé dans le script de test.

    après tout, le hello world arduino est d'allumer/éteindre une led, on est pas très loin, à par la soudure sur le câble rj45.

  • # Un peu de sérieux :-)

    Posté par  . Évalué à 8. Dernière modification le 29 mai 2012 à 21:33.

    Moi j'essayerais avec # tc qdisc add dev eth0 root bfifo limit 0
    qui installe une queue fifo de taille nulle à la sortie de l'interface.
    cf. man tc et man tc-bfifo

    Il est possible de faire de même pour les paquets entrants… plus d'infos dans quelque minutes.

    Mon seul doute concerne les connexions udp…
    Fais moi savoir ci ça marche comme espéré.

    Ah oui, on la retire avec # tc qdisc del dev eth0 root

    • [^] # Mécanisme complet

      Posté par  . Évalué à 10.

      Voici une information plus complète.

      On peut facilement jetter tous les paquets sortants avec
      # tc qdisc add dev eth0 root bfifo limit 0

      Pour les paquets entrants, il faut chipoter avec une interface spéciale…

      modprobe ifb
ip link set dev ifb0 up
tc qdisc add dev eth0 ingress
tc filter add dev eth0 parent ffff: \
  protocol ip u32 match u32 0 0 flowid 1:1 action mirred egress redirect dev ifb0

      Ceci met en place une interface ifb0 sur laquelle on peut filtrer les paquets.
      Si on veut "perdre" tous les paquets entrants, on fera alors
      # tc qdisc add dev ifb0 root bfifo limit 0

      De cette manière, tous les paquets sont perdus de manière transparente pour une application.

      références :
      http://www.linuxfoundation.org/collaborate/workgroups/networking/netem
      http://lartc.org/howto/lartc.qdisc.filters.html

  • # ethtool

    Posté par  . Évalué à -3.

    ethtool me parait être le bon outil pour bricoler au niveau 2. J'ai pas de Linux sous la main pour tester, mais la page de man a l'air d'être de bonne augure pour ce qui tu veux faire.

  • # Hacke ton noyau.

    Posté par  . Évalué à 5. Dernière modification le 29 mai 2012 à 22:59.

    Hacke ton noyau, de préférence dans le driver que tu utilise, et demande lui de dropper les frames selon un paramétrage dans debugfs. Peut être qu'il y a déjà des paramètres dans debugfs capable de faire bugger ta carte.

    Bon sinon, en méthodes un peu plus soft, je ne sais pas si tes applis verront ça, mais au démarrage, tu peux renommer eth0 en real_eth0, créer un bridge "eth0" qui bridge real_eth0 et une interface dummy0 et continuer ton démarrage. Lorsque tu veux péter ton câble réseau, vire real_eth0 du bridge.

    Mais si dans ta conf ton eth0 doit déjà faire partir d'un bridge, ça marchera moins bien … Dans ce cas la, regarde peut-être du coté de ebtables.

    • [^] # Re: Hacke ton noyau.

      Posté par  . Évalué à -2.

      il y a plus simple:
      function debranche {
      iptables -I INPUT -j DROP
      iptables -I OUTPUT -j DROP
      }
      function rebranche {
      iptables -D INPUT -j DROP
      iptables -D OUTPUT -j DROP
      }

      • [^] # Re: Hacke ton noyau.

        Posté par  . Évalué à 4.

        Déjà proposé, déjà répondu: il travaille au niveau 2 = ethernet, pas 3 = IP.

      • [^] # Re: Hacke ton noyau.

        Posté par  . Évalué à 2.

        • IPv6 continuera de marcher.
        • ARP aussi.
        • Si c'était configuré, tu routera encore de l'IPv4.
        • Selon ton noyau, tu pourra toujours recevoir du multicast IPv4.
        • Tout ce qui joue avec des socket af_packet marchera encore. Par exemple, certains serveurs (et clients?) DHCP.
        • Et surtout: ça coupe toutes les interfaces, même lo ou celle qui est censé servir de backup.

        Ça ne suffit pas à couper la couche IP, si c'est ça que tu voulait.

        • [^] # Re: Hacke ton noyau.

          Posté par  . Évalué à 1. Dernière modification le 31 mai 2012 à 00:21.

          Comme dit plus haut (ou plus bas) : ebtables.

          Dans le cas présent un s/iptables/ebtables/ devrait être à peu près bon.
          Et ça marche même avec les bridges. ebtables, ça tabasse.

          edit: juste au dessus en fait /o\

  • # Un cummutateur rj45 ?

    Posté par  (site web personnel) . Évalué à 3.

    http://www.abix.fr/commutateur-manuel-rj45-2-voies,article,014520.html?par=shopziH001

    C'est le même principe que les commutateurs qui étaient parfois utilisés autrefois pour switcher entre deux imprimantes pour une même station (si si, ça se faisait).

  • # juste une nouvelle, nouvelle...

    Posté par  . Évalué à 0.

    Bonjour,

    Voila se que j'ai trouvé dans mes flux:
    http://blog.nicolargo.com/2012/06/simuler-un-reseau-wan-entre-deux-reseaux-lan.html

    Si ça peu toujours aidée.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.