Editer un article - Informaticien.be

Editer un article

Titre
Mots Clés
Texte	[size=18] [b]Nom[/b] [/size] arp - Module ARP du noyau Linux. [size=18] [b]Description[/b] [/size] Ce module du noyau implémente le protocole de résolution d'adresse ARP tel qu'il est décrit dans le document RFC 826. Il sert à la conversion entre les adresses matérielles de niveau 2 et les adresses du protocole IPv4 sur les réseaux connectés en direct. L'utilisateur n'a normalement pas d'interactions avec ce module sauf pour le configurer. En fait ce module fournit des services aux autres protocoles du noyau. Un processus utilisateur peut recevoir les paquets ARP en utilisant les sockets de type [b]packet (7).[/b] Il y a aussi un mécanisme pour gérer le cache ARP dans l'espace utilisateur avec des sockets [b]netlink (7).[/b] La table ARP peut être contrôlée par le biais d'un [b]ioctl (2) [/b] sur n'importe quelle socket [b]PF_INET .[/b] Le module ARP maintient un cache des correspondances entre les adresses matérielles et les adresses logiques. Le cache a une taille limitée, ainsi les entrées anciennes et utilisées moins fréquemment sont récupérées. Les entrées qui sont marquées comme permanentes ne sont jamais effacées. Le cache peut être manipulé directement par l'intermédiaire des [b]ioctl[/b]s et son comportement peut être ajusté à l'aide des [b]sysctl[/b]s décrits plus bas. Lorsqu'il n'y a pas de retour positif pour une correspondance existante après un certain temps (voir les [b]sysctl[/b]s ci dessous), l'entrée est considérée comme gelée. Un retour positif peut être obtenu d'un niveau supérieur, par exemple un ACK TCP réussi. D'autres protocoles peuvent signaler des avancées en utilisant l'attribut [b]MSG_CONFIRM[/b] de [b]sendmsg (2).[/b] Pour envoyer à nouveau des données à cette cible, l'ARP essaye d'abord d'interroger un démon arp local au maximum [b]app_solicit [/b] fois, afin d'obtenir une adresse MAC à jour. Si ceci échoue, et si une ancienne adresse MAC est connue, une tentative unicast est envoyée [b]ucast_solicit[/b] fois. Si on échoue encore, il enverra une requête ARP en broadcast sur le réseau. Les requêtes ne sont envoyées que s'il y a des données en attente d'émission. Linux ajoutera automatiquement une entrée arp proxy non-permanente lorsqu'il reçoit une requête pour une adresse à laquelle il envoie des données, et si l'arp proxy est validé sur l'interface réceptrice. Aucune entrée n'est ajoutée s'il y a une route de rejet. [size=18] [b]Ioctls[/b] [/size] Trois ioctls sont disponibles pour les sockets [b]PF_INET .[/b] Elles prennent un pointeur sur une [b]struct arpreq[/b] comme paramètre. .nf .ta 4 20 33 struct arpreq { struct sockaddr arp_pa; /* adresse protocole / struct sockaddr arp_ha; / adresse matérielle / int arp_flags; / attributs / struct sockaddr arp_netmask; / masque réseau du protocole / char arp_dev[16]; }; .fi [b]SIOCSARP , SIOCDARP et SIOCGARP[/b] ajoute, supprime, et consulte respectivement une correspondance ARP. L'ajout et la suppression de correspondance ARP sont des opérations privilégiées ne pouvant être réalisés que par un processus avec la capacité [b]CAP_NET_ADMIN[/b] ou un UID effectif nul. [i]arp_pa[/i] doit être une socket [b]AF_INET[/b] et [i]arp_ha[/i] doit être du même type que le périphérique indiqué dans [b]arp_dev .[/b] [i]arp_dev[/i] est une chaîne terminée par un caractère nul, contenant le nom d'un périphérique. .TS tab(:) allbox; c s l l. [i]arp_flags[/i] attribut:signification ATF_COM:Recherche complète ATF_PERM:Entrée permanente ATF_PUBL:Entrée publique ATF_USETRAILERS:Demande trailer ATF_NETMASK:Utiliser le masque réseau ATF_DONTPUB:Ne pas répondre .TE Si l'attribut [b]ATF_NETMASK[/b] est activé, alors le membre [i]arp_netmask[/i] doit être valide. Linux 2.2 ne supporte pas les entrées ARP proxy réseau, ainsi il doit être configuré avec 0xFFFFFFFF ou 0 pour supprimer une entrée arp proxy existante. [b]ATF_USETRAILERS[/b] est obsolète et ne doit pas être utilisé [size=18] [b]Sysctls[/b] [/size] ARP supporte une interface [b]sysctl[/b] pour configurer les paramètres sur une base globale ou interface par interface. Les sysctls peuvent être accessibles en lisant ou en écrivant dans le fichier [b]/proc/sys/net/ipv4/neigh//[/b] ou en utilisant l'interface [b]sysctl (2).[/b] Chaque interface dans le système a son propre répertoire dans /proc/sys/net/ipv4/neigh/. La configuration dans le répertoire [b]default[/b] sert pour tous les nouveaux périphériques. Sauf mention contraire, les durées sont en secondes. [b]anycast_delay[/b] [table][row][col]    [/col][col]Le nombre maximum de jiffies à attendre avant de répondre à un message de sollicitation IPv6 du voisinage. Le support Anycast n'est pas encore implémenté. Par défaut, le délai est 1 seconde.[/col][/row][/table] [b]app_solicit[/b] [table][row][col]    [/col][col]Le nombre maximum d'essai d'envoi au démon ARP de l'espace utilisateur par netlink avant de basculer en tentatives multicast (voir [b]mcast_solicit ).[/b] La valeur par défaut est 0.[/col][/row][/table] [b]base_reachable_time[/b] [table][row][col]    [/col][col]Une fois qu'un voisin a été trouvé, l'entrée est considérée comme valide pendant, au moins, une durée aléatoire entre [b]base_reachable_time /2 et 3 base_reachable_time /2.[/b] La validité d'une entrée sera étendue si on reçoit un retour positif des protocoles de plus haut niveau. La valeur par défaut est 30 secondes.[/col][/row][/table] [b]delay_first_probe_time[/b] [table][row][col]    [/col][col]Délai avant la première tentative multicast après avoir décidé qu'un voisin est gelé. Par défaut 5 secondes.[/col][/row][/table] [b]gc_interval[/b] [table][row][col]    [/col][col]Fréquence avec laquelle on vérifie les entrées valides. Par défaut 30 secondes.[/col][/row][/table] [b]gc_stale_time[/b] [table][row][col]    [/col][col]Fréquence avec laquelle on vérifie une entrée de voisinage gelée. Lorsqu'une correspondance est considérée comme gelée, elle sera à nouveau redéterminée avant d'y envoyer des données. Par défaut la durée est de 60 secondes.[/col][/row][/table] [b]gc_thresh1[/b] [table][row][col]    [/col][col]Le nombre minimal d'entrées à conserver dans le cache ARP. Le récupérateur ne sera pas déclenché si il y a moins d'entrées que cette valeur (par défaut 128).[/col][/row][/table] [b]gc_thresh2[/b] [table][row][col]    [/col][col]La limite maximale souple d'entrées à conserver dans le cache ARP. Le récupérateur autorisera un dépassement de cette valeur pendant 5 secondes avant de lancer une véritable récupération. Par défaut 512 entrées.[/col][/row][/table] [b]gc_thresh3[/b] [table][row][col]    [/col][col]La limite maximale d'entrées à conserver dans le cache ARP. Le récupérateur sera immédiatement déclenché si cette valeur est dépassée (par défaut 1024).[/col][/row][/table] [b]locktime[/b] [table][row][col]    [/col][col]Le nombre minimum de jiffies pendant lesquels on conserve une entrée ARP dans le cache. Ceci évite la dégradation du cache si il y a plusieurs correspondances possibles (généralement à cause d'une mauvaise configuration du réseau). Par défaut 1 seconde.[/col][/row][/table] [b]mcast_solicit[/b] [table][row][col]    [/col][col]Le nombre maximal de tentatives de résolution d'une adresse par le multicast et le broadcast avant de marquer l'entrée comme inaccessible. Par défaut 3.[/col][/row][/table] [b]proxy_delay[/b] [table][row][col]    [/col][col]Lorsqu'une requête arrive pour une adresse proxy-ARP, on attend [i]proxy_delay[/i] jiffies avant de répondre. Ceci permet d'éviter des saturations du réseau dans certains cas. La valeur par défaut correspond à 0.8 secondes.[/col][/row][/table] [b]proxy_qlen[/b] [table][row][col]    [/col][col]Le nombre maximal de paquets qui peuvent être conservés pour des adresses proxy-ARP. Par défaut 64.[/col][/row][/table] [b]retrans_time[/b] [table][row][col]    [/col][col]Le nombre de jiffies à attendre avant de retransmettre une requête. Par défaut 1 seconde.[/col][/row][/table] [b]ucast_solicit[/b] [table][row][col]    [/col][col]Le nombre maximal de tentatives d'envoi unicast avant d'interroger le démon ARP (voir [b]app_solicit ).[/b] Par défaut 3.[/col][/row][/table] [b]unres_qlen[/b] [table][row][col]    [/col][col]Le nombre maximal de paquets conservés pour chaque adresse non résolue par les autres couches réseau. Par défaut 3. [/col][/row][/table] [size=18] [b]Bugs[/b] [/size] Certaines temporisations sont exprimées en jiffies qui dépendent de l'architecture. Sur Alpha, un jiffy correspond à 1/1024 seconde, sur la plupart des autres il correspond à 1/100 seconde. Il n'y a pas de moyen d'envoyer une réponse positive de l'espace utilisateur. Ceci signifie que les protocoles orientés connexion implémentés dans l'espace utilisateur engendreront un trafic ARP excessif, car ndisc revérifiera régulièrement les adresses MAC. Le même problème se pose pour certains protocoles du noyau (par exemple NFS sur UDP). Cette page de manuel mélange les spécificités IPv4 et les fonctionnalités communes à IPv4 et IPv6. [size=18] [b]Versions[/b] [/size] La structure [b]arpreq[/b] a changé dans Linux 2.0 pour inclure le membre [i]arp_dev[/i] et les numéros d'ioctl ont changé en même temps. Le support pour les anciens ioctl a été abandonné dans Linux 2.2. Le support pour les entrées proxy ARP concernant des réseaux (netmask différent de 0xFFFFFFF) a été supprimé de Linux 2.2. Il est remplacé par une configuration proxy ARP automatique dans le noyau pour tous les hôtes accessibles sur les autres interfaces (lorsque l'on fait du forwarding et que le proxy ARP est activé sur l'interface). Les requêtes sysctl neigh/* n'existaient pas avant Linux 2.2. [size=18] [b]Voir aussi[/b] [/size] [b]ip (7)[/b] RFC826 pour une description de l'ARP. [b][/b] RFC2461 pour une description de l'exploration du voisinage IPv6 et des algorithmes de base employés.     L'ARP IPv4 de Linux 2.2 et ultérieurs emploie l'algorithme IPv6 si possible. [size=18] [b]Traduction[/b] [/size] Christophe Blaess, 2000-2003.
Fichier