web-dev-qa-db-fra.com

ip vs ifconfig commande le pour et le contre

À un moment donné, dans du matériel pédagogique (de Linux Foundation) sur Linux que j'ai rencontré, ce qui suit est mentionné:

La commande ip est plus polyvalente et plus efficace que ifconfig car elle utilise les sockets netlink plutôt que ioctl appels système.

Quelqu'un peut-il élaborer un peu à ce sujet parce que je ne comprends pas ce qui se passe sous le capot?

P.S. Je connais ce sujet sur ces outils mais cela ne résout pas cette différence spécifique sur la façon dont ils fonctionnent

33
pkaramol

La commande ifconfig sur les systèmes d'exploitation tels que FreeBSD et OpenBSD a été mise à jour en ligne avec le reste du système d'exploitation. De nos jours, il peut configurer toutes sortes de paramètres d'interface réseau sur ces systèmes d'exploitation et gérer une gamme de protocoles réseau. Les BSD fournissent une prise en charge de ioctl() pour ces choses.

Cela ne s'est pas produit dans le monde Linux. Il existe aujourd'hui trois commandes ifconfig:

  • ifconfig de GNU inetutils
    jdebp% inetutils-ifconfig -l 
     enp14s0 enp15s0 lo 
     jdebp% inetutils-ifconfig lo 
     lo Encapsulation de lien: boucle locale 
     inet addr: 127.0.0.1 Bcast: 0.0.0.0 Masque: 255.0.0.0 
     UP LOOPBACK RUNNING MTU: 65536 Métrique: 1 
     Paquets RX: 9087 erreurs: 0 abandonné: 0 dépassement: 0 trame: 0 
     Paquets TX : 9087 erreurs: 0 supprimées: 0 dépassements: 0 porteuse: 0 
     Collisions: 0 txqueuelen: 1000 
     Octets RX: 51214341 octets TX: 51214341 
     Jdebp%
  • ifconfig de NET-3 net-tools
    jdebp% ifconfig -l 
     ifconfig: option -l' not recognised.
    ifconfig: - help 'donne des informations d'utilisation. 
     jdebp% ifconfig lo 
     lo: flags = 73 <UP, LOOPBACK , RUNNING> mtu 65536 
     Inet 127.0.0.1 netmask 255.0.0.0 
     Inet6 :: 1 prefixlen 128 scopeid 0x10 <Host> 
     Inet6 :: 2 prefixlen 128 scopeid 0x80 <compat, global> 
     inet6 fe80 :: prefixlen 10 scopeid 0x20 <link> 
     loop txqueuelen 1000 (Local Loopback) 
     Paquets RX 9087 octets 51214341 (48,8 Mio) 
     RX erreurs 0 abandonné 0 dépassements 0 trame 0 
     paquets TX 9087 octets 51214341 (48,8 Mio) 
     erreurs TX 0 abandonné 0 dépassements 0 porteuse 0 collisions 0 
     jdebp%
  • ifconfig de (version 1.40 de) la trousse à outils nosh
    jdebp% ifconfig -l 
     enp14s0 enp15s0 lo 
     jdebp% ifconfig lo 
     lo 
     bouclage de liaison en cours d'exécution 
     adresse de liaison 00:00:00: 00:00:00 bdaddr 00: 00: 00: 00: 00: 00 
     Adresse inet4 127.0.0.1 prefixlen 8 bdaddr 127.0.0.1 
     Adresse inet4 127.53.0.1 prefixlen 8 bdaddr 127.255.255.255 
     adresse inet6 :: 2 portée 0 prefixlen 128 
     adresse inet6 fe80 :: portée 1 prefixlen 10 
     adresse inet6 :: 1 portée 0 prefixlen 128 
     jdebp% Sudo ifconfig lo inet4 127.1.0.2 alias 
     jdebp% Sudo ifconfig lo inet6 :: 3/128 alias 
     jdebp% ifconfig lo 
     lo 
     relier le bouclage en cours d'exécution 
     adresse du lien 00: 00: 00: 00: 00: 00 bdaddr 00: 00: 00: 00: 00: 00 
     adresse inet4 127.0.0.1 prefixlen 8 bdaddr 127.0.0.1 
     adresse inet4 127.1.0.2 prefixlen 32 bdaddr 127.1.0.2 
     Adresse inet4 127.53.0.1 prefixlen 8 bdaddr 127.255.255.255 
     Adresse inet6 :: 3 portée 0 prefixlen 128 
     Inet6 adresse :: 2 portée 0 préfixe 128 
     inet6 adresse fe80 :: portée 1 préfixe 10 
     inet6 adresse :: 1 portée 0 préfixe 128 
     jdebp% 

Comme vous pouvez le voir, les GNU inetutils et NET-3 net-tools ifconfig s ont des lacunes marquées, par rapport à IPv6, par rapport aux interfaces qui ont plusieurs adresses, et en ce qui concerne des fonctionnalités comme -l.

Le problème IPv6 est en partie du code manquant dans les outils eux-mêmes. Mais dans l'ensemble, cela est dû au fait que Linux ne fournit pas (comme les autres systèmes d'exploitation) la fonctionnalité IPv6 via l'interface ioctl(). Il permet uniquement aux programmes de voir et de manipuler les adresses IPv4 via les réseaux ioctl() s.

Linux fournit à la place cette fonctionnalité via une interface différente, send() et recv() sur une famille d'adresses spéciale et quelque peu étrange, AF_NETLINK.

Les GNU et NET-3 ifconfig s auraient pu avoir été ajustés pour utiliser cette nouvelle API. L'argument contre cela était qu'il n'était pas portable sur d'autres systèmes d'exploitation, mais ces programmes étaient en pratique déjà pas portables de toute façon donc ce n'était pas vraiment un argument.

Mais ils n'ont pas été ajustés, et restent comme indiqué à ce jour. (Certaines personnes y ont travaillé à divers moments au fil des ans, mais les améliorations, malheureusement pour ne pas être entrées dans les programmes. Par exemple: Bernd Eckenfels n'a jamais accepté de correctif qui a ajouté une capacité d'API netlink à NET-3 net-tools ifconfig, 4 ans après l'écriture du correctif.)

Au lieu de cela, certaines personnes ont complètement réinventé le jeu d'outils en tant que commande ip, qui utilisait la nouvelle API Linux, avait une syntaxe différente et combinait plusieurs autres fonctions derrière une interface à la mode commandsubcommand.

J'avais besoin d'un ifconfig qui avait la syntaxe de ligne de commande et le style de sortie de FreeBSD ifconfig (que ni le GNU ni le NET-3 ifconfig a, et que ip n'a certainement pas). J'ai donc écrit un. Comme preuve que l'on pourrait écrire un ifconfig qui utilise l'API netlink sur Linux, il le fait.

Ainsi, la sagesse reçue sur ifconfig, comme ce que vous citez, n'est plus vraiment vraie. Il est désormais faux de dire que "ifconfig n'utilise pas netlink.". La couverture qui en couvrait deux ne couvre pas trois.

Il a toujours été faux de dire que "netlink est plus efficace". Pour les tâches que l'on fait avec ifconfig, il n'y a pas vraiment grand-chose en termes d'efficacité entre l'API netlink et l'API ioctl(). On fait à peu près le même nombre d'appels d'API pour une tâche donnée.

En effet, chaque appel d'API est deux appels système dans le cas netlink, par opposition à un dans le système ioctl(). Et sans doute l'API netlink a l'inconvénient que sur un système très utilisé, elle intègre explicitement la possibilité que l'outil ne reçoive jamais de message d'accusé de réception l'informant du résultat de l'appel API.

De plus, il est faux de dire que ip est "plus polyvalent" que les GNU et NET-3 ifconfig s car il utilise netlink . Il est plus polyvalent car il fait plus de tâches, faisant des choses dans un grand programme que l'on ferait avec des programmes séparés autres que ifconfig. Il n'est pas plus polyvalent simplement grâce à l'API qu'il utilise en interne pour effectuer ces tâches supplémentaires. Il n'y a rien d'inhérent à l'API à ce sujet. On pourrait écrire un un outil tout-en-un qui a utilisé l'API FreeBSD ioctl(), par exemple, et déclare également qu'il est "plus polyvalent" que l'individu ifconfig, route, Commandes arp et ndp.

On pourrait écrire des commandes route, arp et ndp pour Linux qui utilisaient également l'API netlink.

Lectures complémentaires

49
JdeBP

Le ifconfig standard que nous avons dans de nombreuses distributions est déconseillé pour plusieurs raisons. Parle de manière obsolète et limitée avec le noyau, et en fait, ne comprend plus toutes les configurations réseau. Vous ne pourrez pas manipuler certaines configurations réseau telles que les versions ifconfig que vous pouvez faire avec ip. De plus, la prise en charge ifconfig des espaces de noms réseau est limitée.

Comme anecdotique, j'ai trouvé des alias IP d'interface qui ne sont visibles que dans ip et non dans SuSE ifconfig.

Quant aux différences sous le capot: De ifconfig vs ip: Quelle est la différence et comparaison de la configuration résea

Bien que ip puisse sembler un peu complexe au premier site, mais il est beaucoup plus large en fonctionnalités que ifconfig. Il est organisé fonctionnellement sur deux couches de la pile de mise en réseau, c'est-à-dire la couche 2 (couche de liaison), la couche 3 (couche IP) et effectue le travail de toutes les commandes mentionnées ci-dessus à partir du package net-tools.

Alors que ifconfig affiche ou modifie principalement les interfaces d'un système, cette commande est capable d'effectuer les tâches suivantes:

  • Affichage ou modification des propriétés de l'interface.

  • Ajout, suppression d'entrées de cache ARP lors de la création d'une nouvelle entrée ARP statique pour un hôte.

  • Affichage des adresses MAC associées à toutes les interfaces.

  • Affichage et modification des tables de routage du noyau.

L'un des principaux points forts qui le sépare de son ancien homologue ifconfig est que ce dernier utilise ioctl pour la configuration du réseau, ce qui est un moyen d'interaction moins apprécié avec le noyau tandis que l'ancien profite du mécanisme de socket netlink pour le même qui est un successeur beaucoup plus flexible. d'ioctl pour l'intercommunication entre le noyau et l'espace utilisateur à l'aide de rtnetlink (qui ajoute une capacité de manipulation de l'environnement réseau).

À propos de l'utilisation/des avantages de netlink: De LJ - Kernel Korner - Pourquoi et comment utiliser Netlink Socket

Le socket Netlink est un IPC utilisé pour le transfert d'informations entre le noyau et les processus de l'espace utilisateur. Il fournit un lien de communication en duplex intégral entre les deux au moyen d'API de socket standard pour les processus de l'espace utilisateur et une API de noyau spéciale pour les modules de noyau. Le socket Netlink utilise la famille d'adresses AF_NETLINK.

.....

Pourquoi les fonctionnalités ci-dessus utilisent-elles netlink au lieu d'appels système, d'ioctls ou de systèmes de fichiers proc pour la communication entre les mondes utilisateur et noyau? C'est une tâche non triviale d'ajouter des appels système, des ioctls ou des fichiers proc pour de nouvelles fonctionnalités; nous risquons de polluer le noyau et de nuire à la stabilité du système. Le socket Netlink est simple, cependant: seule une constante, le type de protocole, doit être ajoutée à netlink.h. Ensuite, le module du noyau et l'application peuvent parler immédiatement en utilisant des API de style socket.

....

La socket Netlink est une interface flexible pour la communication entre les applications de l'espace utilisateur et les modules du noyau. Il fournit une API de socket facile à utiliser pour les applications et le noyau. Il fournit des fonctionnalités de communication avancées, telles que le duplex intégral, les E/S tamponnées, la multidiffusion et la communication asynchrone, qui sont absentes dans d'autres IPC noyau/espace utilisateur.

9
Rui F Ribeiro