<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"><head><title>Configurations obscures</title><link href="style.css" rel="stylesheet" type="text/css" /><meta content="DocBook XSL Stylesheets V1.73.2" name="generator" /><link rel="start" href="index.html" title="HOWTO du routage avancé et du contrôle de trafic sous Linux" /><link rel="up" href="ch13.html" title="Chapitre 13. Paramètres réseau du noyau" /><link rel="prev" href="ch13.html" title="Chapitre 13. Paramètres réseau du noyau" /><link rel="next" href="ch14.html" title="Chapitre 14. Gestionnaires de mise en file d'attente avancés & moins communs" /></head><body><div class="navheader"><table summary="Navigation header" width="100%"><tr><th align="center" colspan="3">Configurations obscures</th></tr><tr><td align="left" width="20%"><a accesskey="p" href="ch13.html">Précédent</a> </td><th align="center" width="60%">Chapitre 13. Paramètres réseau du noyau</th><td align="right" width="20%"> <a accesskey="n" href="ch14.html">Suivant</a></td></tr></table><hr /></div><div class="sect1" lang="fr"><div class="titlepage"><div><div><h2 class="title"><a id="lartc.kernel.obscure" />Configurations obscures</h2></div></div></div><p>Bon, il y a beaucoup de paramètres qui peuvent être modifiés.
Nous essayons de tous les lister.
Voir aussi une documentation partielle dans
<code class="filename">Documentation/ip-sysctl.txt</code>.
</p><p>Certaines de ces configurations ont des valeurs par défaut différentes
suivant que vous répondez <code class="option">Yes</code> ou <code class="option">No</code> à la
question <code class="option">Configure as router and not host</code> lors de la
compilation du noyau.
</p><p>
Oskar Andreasson a une page sur ces options et il apparaît qu'elle soit
meilleure que la notre. De ce fait, allez également voir
<a class="ulink" href="http://ipsysctl-tutorial.frozentux.net/" target="_top">
http://ipsysctl-tutorial.frozentux.net/</a>.
</p><div class="sect2" lang="fr"><div class="titlepage"><div><div><h3 class="title"><a id="N1180F" />ipv4 générique</h3></div></div></div><p>En remarque générale, les fonctionnalités de limitation
de débit ne fonctionnent pas sur l'interface <code class="literal">loopback</code>.
N'essayez donc pas de les tester localement.
Les limites sont exprimées en « <span class="quote">tic-tac</span> »
(<em class="wordasword">jiffies</em>) et elles utilisent obligatoirement le
<em class="wordasword">Token Bucket Filter</em> mentionné plus tôt.
</p><p>[NdT : le terme <em class="wordasword">jiffies</em> désigne un
mouvement régulier, faisant référence au « <span class="quote">tic-tac</span> » d'une horloge.
Dans le noyau lui-même, une variable globale nommée <code class="varname">jiffies</code>
est incrémentée à chaque interruption d'horloge]
</p><p>Le noyau a une horloge interne qui tourne à <code class="literal">HZ</code>
impulsions (ou <em class="wordasword">jiffies</em>) par seconde.
Sur Intel, <code class="literal">HZ</code> est la plupart du temps égale à
<code class="literal">100</code>.
Donc, configurer un fichier <code class="filename">*_rate</code> à, disons 50,
autorise 2 paquets par seconde.
Le <em class="wordasword">Token Bucket Filter</em> est également configuré pour
autoriser une rafale de données de 6 paquets au plus, si suffisamment de
jetons ont été gagnés.
</p><p>Plusieurs éléments de la liste suivante proviennent du fichier
<code class="filename">/usr/src/linux/Documentation/networking/ip-sysctl.txt</code>,
écrit par
<span class="author"><span class="firstname">Alexey</span> <span class="surname">Kuznetsov</span></span>
<code class="email"><<a class="email" href="mailto:kuznet@ms2.inr.ac.ru">kuznet@ms2.inr.ac.ru</a>></code> et <span class="author"><span class="firstname">Andi</span> <span class="surname">Kleen</span></span> <code class="email"><<a class="email" href="mailto:ak@muc.de">ak@muc.de</a>></code>.
</p><div class="variablelist"><dl><dt><span class="term">
<code class="filename">/proc/sys/net/ipv4/icmp_destunreach_rate</code>
</span></dt><dd><p>Si le noyau décide qu'il ne peut pas délivrer un paquet, il le
rejettera et enverra à la source du paquet un ICMP notifiant ce rejet.
</p></dd><dt><span class="term">
<code class="filename">/proc/sys/net/ipv4/icmp_echo_ignore_all</code>
</span></dt><dd><p>N'agit en aucun cas comme écho pour les paquets.
Ne configurez pas ceci par défaut.
Cependant, si vous êtes utilisé comme relais dans une attaque de Déni de
Services, cela peut être utile.
</p></dd><dt><span class="term">
<code class="filename">/proc/sys/net/ipv4/icmp_echo_ignore_broadcasts</code>
[Utile]</span></dt><dd><p>Si vous pinguez l'adresse de diffusion d'un réseau, tous les hôtes
sont sensés répondre.
Cela permet de coquettes attaques de déni de service.
Mettez cette valeur à 1 pour ignorer ces messages de diffusion.
</p></dd><dt><span class="term">
<code class="filename">/proc/sys/net/ipv4/icmp_echoreply_rate</code>
</span></dt><dd><p>Le débit auquel les réponses echo sont envoyées aux destinataires.
</p></dd><dt><span class="term">
<code class="filename">/proc/sys/net/ipv4/icmp_ignore_bogus_error_responses</code>
</span></dt><dd><p>Configurer ceci pour ignorer les erreurs ICMP d'hôtes du réseau
réagissant mal aux trames envoyées vers ce qu'ils perçoivent comme
l'adresse de diffusion.
</p></dd><dt><span class="term">
<code class="filename">/proc/sys/net/ipv4/icmp_paramprob_rate</code>
</span></dt><dd><p>Un message ICMP relativement peu connu, qui est envoyé en réponse à
des paquets qui ont des en-têtes IP ou TCP erronés.
Avec ce fichier, vous pouvez contrôler le débit auquel il est envoyé.
</p></dd><dt><span class="term">
<code class="filename">/proc/sys/net/ipv4/icmp_timeexceed_rate</code>
</span></dt><dd><p>Voici la célèbre cause des « <span class="quote">étoiles Solaris</span> » dans
traceroute.
Limite le nombre de messages ICMP Time Exceeded envoyés.
</p></dd><dt><span class="term">
<code class="filename">/proc/sys/net/ipv4/igmp_max_memberships</code>
</span></dt><dd><p>Nombre maximal de sockets igmp (multidistribution) en écoute sur
l'hôte.
FIXME: Est-ce vrai ?
</p></dd><dt><span class="term">
<code class="filename">/proc/sys/net/ipv4/inet_peer_gc_maxtime</code>
</span></dt><dd><p>FIXME : Ajouter une petite explication sur le stockage des
partenaires internet (inet peer) ?
Intervalle de temps minimum entre deux passages du ramasse-miettes.
Cet intervalle est pris en compte lors d'une faible (voire inexistante)
utilisation du <em class="wordasword">pool</em>.
Mesuré en <em class="wordasword">jiffies</em>.
[NdT : Le <em class="wordasword">pool</em> désigne ici la liste des
adresses IP des partenaires internet.]
</p></dd><dt><span class="term">
<code class="filename">/proc/sys/net/ipv4/inet_peer_gc_mintime</code>
</span></dt><dd><p>Intervalle de temps minimum entre deux passages du ramasse-miettes.
Cet intervalle est pris en compte lors d'une utilisation intensive du
<em class="wordasword">pool</em>.
Mesuré en <em class="wordasword">jiffies</em>.
</p></dd><dt><span class="term">
<code class="filename">/proc/sys/net/ipv4/inet_peer_maxttl</code>
</span></dt><dd><p>Durée de conservation maximale des enregistrements.
Les entrées non utilisées expireront au bout de cet intervalle de temps
(c'est-à-dire quand le nombre d'entrées dans le
<em class="wordasword">pool</em> est très petit).
Mesuré en <em class="wordasword">jiffies</em>.
</p></dd><dt><span class="term">
<code class="filename">/proc/sys/net/ipv4/inet_peer_minttl</code>
</span></dt><dd><p>Durée de conservation minimale des enregistrements.
Devrait être suffisante pour prendre en compte le temps de vie des
fragments sur l'hôte qui doit réassembler les paquets.
Cette durée minimale est garantie si le nombre d'éléments dans le
<em class="wordasword">pool</em> est inférieur au seuil fixé par
<code class="option">inet_peer_threshold</code>.
</p></dd><dt><span class="term">
<code class="filename">/proc/sys/net/ipv4/inet_peer_threshold</code>
</span></dt><dd><p>Taille approximative de l'espace de stockage des partenaires
internet.
A partir de ce seuil, les entrées sont effacées.
Ce seuil détermine la durée de vie des entrées, ainsi que les intervalles
de temps entre deux déclenchements du ramasse-miettes.
Plus il y a d'entrées, plus le temps de vie est faible et plus
l'intervalle du ramasse-miettes est faible.
</p></dd><dt><span class="term">
<code class="filename">/proc/sys/net/ipv4/ip_autoconfig</code>
</span></dt><dd><p>Ce fichier contient la valeur 1 si l'hôte a reçu sa configuration IP
par <acronym class="acronym">RARP</acronym>, <acronym class="acronym">BOOTP</acronym>,
<acronym class="acronym">DHCP</acronym> ou un mécanisme similaire.
Autrement, il contient la valeur zéro.
</p></dd><dt><span class="term">
<code class="filename">/proc/sys/net/ipv4/ip_default_ttl</code>
</span></dt><dd><p>Durée de vie (<acronym class="acronym">TTL</acronym>) des paquets.
Fixer à la valeur sûre de 64.
Augmentez-la si vous avez un réseau immense, mais pas
« <span class="quote">pour s'amuser</span> » :
les boucles sans fin d'un mauvais routage sont plus dangereuses si le
<acronym class="acronym">TTL</acronym> est élevé.
Vous pouvez même envisager de diminuer la valeur dans certaines
circonstances.
</p></dd><dt><span class="term">
<code class="filename">/proc/sys/net/ipv4/ip_dynaddr</code>
</span></dt><dd><p>Vous aurez besoin de positionner cela si vous utilisez la connexion
à la demande avec une adresse d'interface dynamique.
Une fois que votre interface a été configurée, toutes les sockets TCP
locaux qui n'ont pas eu de paquets de réponse seront retraitées pour avoir
la bonne adresse.
Cela résout le problème posé par une connexion défectueuse ayant configuré
une interface, suivie par une deuxième tentative réussie (avec une adresse
IP différente).
</p></dd><dt><span class="term">
<code class="filename">/proc/sys/net/ipv4/ip_forward</code>
</span></dt><dd><p>Le noyau doit-il essayer de transmettre les paquets ?
Désactivé par défaut.
</p></dd><dt><span class="term">
<code class="filename">/proc/sys/net/ipv4/ip_local_port_range</code>
</span></dt><dd><p>Intervalle des ports locaux pour les connexions sortantes.
En fait, assez petit par défaut, 1024 à 4999.
</p></dd><dt><span class="term">
<code class="filename">/proc/sys/net/ipv4/ip_no_pmtu_disc</code>
</span></dt><dd><p>Configurez ceci si vous voulez désactiver la découverte du MTU de
chemin, une technique pour déterminer le plus grand MTU possible sur votre
chemin.
Voir aussi la section sur la découverte du MTU de chemin dans le chapitre
<em class="citetitle"><a class="xref" href="ch15.html" title="Chapitre 15. Recettes de cuisine">Recettes de cuisine</a></em>.
</p></dd><dt><span class="term">
<code class="filename">/proc/sys/net/ipv4/ipfrag_high_thresh</code>
</span></dt><dd><p>Mémoire maximum utilisée pour réassembler les fragments IP.
Quand <code class="literal">ipfrag_high_thresh</code> octets de
mémoire sont alloués pour cela, le gestionnaire de fragments rejettera les
paquets jusqu'à ce que <code class="literal">ipfrag_low_thresh</code>
soit atteint.
</p></dd><dt><span class="term">
<code class="filename">/proc/sys/net/ipv4/ip_nonlocal_bind</code>
</span></dt><dd><p>Configurez ceci si vous voulez que vos applications soient capables
de se lier à une adresse qui n'appartient pas à une interface de votre
système.
Ceci peut être utile quand votre machine est sur un lien non-permanent
(ou même permanent).
Vos services sont donc capables de démarrer et de se lier à une adresse
spécifique quand votre lien est inactif.
</p></dd><dt><span class="term">
<code class="filename">/proc/sys/net/ipv4/ipfrag_low_thresh</code>
</span></dt><dd><p>Mémoire minimale utilisée pour réassembler les fragments IP.
</p></dd><dt><span class="term">
<code class="filename">/proc/sys/net/ipv4/ipfrag_time</code>
</span></dt><dd><p>Temps en secondes du maintien d'un fragment IP en mémoire.
</p></dd><dt><span class="term">
<code class="filename">/proc/sys/net/ipv4/tcp_abort_on_overflow</code>
</span></dt><dd><p>Une option booléenne contrôlant le comportement dans le cas de
nombreuses connexions entrantes.
Quand celle-ci est activée, le noyau envoie rapidement des paquets RST
quand un service est surchargé.
</p></dd><dt><span class="term">
<code class="filename">/proc/sys/net/ipv4/tcp_fin_timeout</code>
</span></dt><dd><p>Temps de maintien de l'état <code class="literal">FIN-WAIT-2</code> pour un
socket dans le cas où il a été fermé de notre côté.
Le partenaire peut être défectueux et ne jamais avoir fermé son côté ou
même mourir de manière inattendue.
La valeur par défaut est de 60 secondes.
La valeur usuelle utilisée dans le noyau 2.2 était de 180 secondes.
Vous pouvez la remettre, mais rappelez vous que si votre machine a un
serveur WEB surchargé, vous risquez de dépasser la mémoire avec des
kilotonnes de sockets morts.
Les sockets <code class="literal">FIN-WAIT2</code> sont moins dangereux que les
sockets <code class="literal">FIN-WAIT1</code> parce qu'ils consomment au maximum
1,5K de mémoire, mais ils ont tendance à vivre plus longtemps.
Cf <code class="literal">tcp_max_orphans</code>.
</p></dd><dt><span class="term">
<code class="filename">/proc/sys/net/ipv4/tcp_keepalive_time</code>
</span></dt><dd><p>Durée entre l'envoi de deux messages
<em class="wordasword">keepalive</em> quand l'option
<em class="wordasword">keepalive</em> est activée.
Par défaut : 2 heures.
</p></dd><dt><span class="term">
<code class="filename">/proc/sys/net/ipv4/tcp_keepalive_intvl</code>
</span></dt><dd><p>A quelle fréquence les sondes sont retransmises lorsqu'il n'y a pas
eu acquittement de sonde.
Par défaut : 75 secondes.
</p></dd><dt><span class="term">
<code class="filename">/proc/sys/net/ipv4/tcp_keepalive_probes</code>
</span></dt><dd><p>Combien de sondes TCP <em class="wordasword">keepalive</em> seront
envoyées avant de décider que la connexion est brisée.
Par défaut : 9.
En multipliant par <code class="literal">tcp_keepalive_intvl</code>,
cela donne le temps pendant lequel un lien peut être actif sans donner de
réponses après l'envoi d'un <em class="wordasword">keepalive</em>.
</p></dd><dt><span class="term">
<code class="filename">/proc/sys/net/ipv4/tcp_max_orphans</code>
</span></dt><dd><p>Nombre maximum de sockets TCP qui ne sont pas reliés à un
descripteur de fichier utilisateur, géré par le système.
Si ce nombre est dépassé, les connexions orphelines sont immédiatement
réinitialisées et un avertissement est envoyé.
Cette limite existe seulement pour prévenir des attaques de déni de
services simples.
Vous ne devez pas compter sur ceci ou diminuer cette limite
artificiellement, mais plutôt l'augmenter (probablement après avoir
augmenté la mémoire) si les conditions du réseau réclament plus que cette
valeur par défaut et régler vos services réseau pour qu'ils détruisent
sans tarder ce type d'état.
Laissez-moi vous rappeler encore que chaque orphelin consomme jusqu'à
environ 64K de mémoire non <em class="wordasword">swappable</em>.
</p></dd><dt><span class="term">
<code class="filename">/proc/sys/net/ipv4/tcp_orphan_retries</code>
</span></dt><dd><p>Combien d'essais avant de détruire une connexion TCP, fermée par
notre côté.
La valeur par défaut de 7 correspond à un temps d'environ 50s à 16 min
suivant le <acronym class="acronym">RTO</acronym>.
Si votre machine supporte un serveur Web, vous pouvez envisager de baisser
cette valeur, dans la mesure où de tels sockets peuvent consommer des
ressources significatives.
Cf <code class="literal">tcp_max_orphans</code>.
</p></dd><dt><span class="term">
<code class="filename">/proc/sys/net/ipv4/tcp_max_syn_backlog</code>
</span></dt><dd><p>Nombre maximum de requêtes d'une connexion mémorisée, qui n'avait
pas encore reçu d'accusé de réception du client connecté.
La valeur par défaut est de 1024 pour des systèmes avec plus de 128 Mo
de mémoire et 128 pour des machines avec moins de mémoire.
Si un serveur souffre de surcharge, essayez d'augmenter ce nombre.
Attention ! Si vous positionnez une valeur supérieure à 1024, il serait
préférable de changer <code class="literal">TCP_SYNQ_HSIZE</code> dans
le fichier <code class="filename">include/net/tcp.h</code> pour garder
<code class="literal">TCP_SYNQ_HSIZE*16 <=
tcp_max_syn_backlog</code> et de recompiler de
noyau.
</p></dd><dt><span class="term">
<code class="filename">/proc/sys/net/ipv4/tcp_max_tw_buckets</code>
</span></dt><dd><p>Nombre maximum de sockets <code class="literal">timewait</code> gérées par le
système simultanément.
Si ce nombre est dépassé, le socket <code class="literal">timewait</code> est
immédiatement détruit et un message d'avertissement est envoyé.
Cette limite n'existe que pour prévenir des attaques de déni de services
simples.
Vous ne devez pas diminuer cette limite artificiellement, mais plutôt
l'augmenter (probablement après avoir augmenté la mémoire) si les
conditions du réseau réclament plus que cette valeur par défaut.
</p></dd><dt><span class="term">
<code class="filename">/proc/sys/net/ipv4/tcp_retrans_collapse</code>
</span></dt><dd><p>Compatibilité bug à bug avec certaines imprimantes défectueuses.
Tentative d'envoi de plus gros paquets lors de la retransmission pour
contourner le bug de certaines piles TCP.
</p></dd><dt><span class="term">
<code class="filename">/proc/sys/net/ipv4/tcp_retries1</code>
</span></dt><dd><p>Combien d'essais avant de décider que quelque chose est erroné et
qu'il est nécessaire d'informer de cette suspicion la couche réseau.
La valeur minimale du <acronym class="acronym">RFC</acronym> est de 3.
C'est la valeur par défaut ; elle correspond à un temps d'environ 3 sec à
8 min suivant le <acronym class="acronym">RTO</acronym>.
</p></dd><dt><span class="term">
<code class="filename">/proc/sys/net/ipv4/tcp_retries2</code>
</span></dt><dd><p>Combien d'essais avant de détruire une connexion TCP active.
Le <a class="ulink" href="http://www.ietf.org/rfc/rfc1122.txt" target="_top">RFC 1122</a>
précise que la limite ne devrait pas dépasser 100 secondes.
C'est un nombre trop petit.
La valeur par défaut de 15 correspond à un temps de environ 13 à 30
minutes suivant le <acronym class="acronym">RTO</acronym>.
</p></dd><dt><span class="term">
<code class="filename">/proc/sys/net/ipv4/tcp_rfc1337</code>
</span></dt><dd><p>Ce booléen active un rectificatif pour « <span class="quote">l'assassinat hasardeux
des time-wait dans tcp</span> », décrit dans le RFC 1337.
S'il est activé, le noyau rejette les paquets RST pour les sockets à
l'état de <code class="literal">time-wait</code>.
Par défaut : 0
</p></dd><dt><span class="term">
<code class="filename">/proc/sys/net/ipv4/tcp_sack</code>
</span></dt><dd><p>Utilise un ACK sélectif qui peut être utilisé pour signifier que des
paquets spécifiques sont manquant.
Facilite ainsi une récupération rapide.
</p></dd><dt><span class="term">
<code class="filename">/proc/sys/net/ipv4/tcp_stdurg</code>
</span></dt><dd><p>Utilise l'interprétation du RFC
<em class="citetitle">Host Requirements</em> du champ TCP pointeur urgent.
La plupart des hôtes utilisent la vieille interprétation BSD.
Donc, si vous activez cette option, il se peut que Linux ne communique
plus correctement avec eux.
Par défaut : FALSE (FAUX)
</p></dd><dt><span class="term">
<code class="filename">/proc/sys/net/ipv4/tcp_syn_retries</code>
</span></dt><dd><p>Nombre de paquets SYN que le noyau enverra avant de tenter
l'établissement d'une nouvelle connexion.
</p></dd><dt><span class="term">
<code class="filename">/proc/sys/net/ipv4/tcp_synack_retries</code>
</span></dt><dd><p>Pour ouvrir l'autre côté de la connexion, le noyau envoie un SYN
avec un ACK superposé (<em class="wordasword">piggyback</em>), pour accuser
réception du SYN précédemment envoyé.
C'est la deuxième partie de la poignée de main à trois voies
(<em class="wordasword">threeway handshake</em>).
Cette configuration détermine le nombre de paquets SYN+ACK à envoyer avant
que le noyau n'abandonne la connexion.
</p></dd><dt><span class="term">
<code class="filename">/proc/sys/net/ipv4/tcp_timestamps</code>
</span></dt><dd><p>Les estampillages horaires sont utilisés, entre autres, pour se
protéger du rebouclage des numéros de séquence.
On peut concevoir qu'un lien à 1 gigabit puisse de nouveau rencontrer un
numéro de séquence précédent avec une valeur hors-ligne parcequ'il était
d'une génération précédente.
L'estampillage horaire permet de reconnaître cet
« <span class="quote">ancien paquet</span> ».
</p></dd><dt><span class="term">
<code class="filename">/proc/sys/net/ipv4/tcp_tw_recycle</code>
</span></dt><dd><p>Mise en place du recyclage rapide des sockets
<code class="literal">TIME-WAIT</code>.
La valeur par défaut est 1.
Celle-ci ne devrait pas être changée sans le conseil/demande d'experts
techniques.
</p></dd><dt><span class="term">
<code class="filename">/proc/sys/net/ipv4/tcp_window_scaling</code>
</span></dt><dd><p>TCP/IP autorise normalement des fenêtres jusqu'à une taille de 65535
octets.
Pour des réseaux vraiment rapides, cela peut ne pas être assez.
Les options <code class="option">windows scaling</code> autorisent des fenêtres
jusqu'au gigaoctet, ce qui est adapté pour les produits à grande bande
passante.
</p></dd></dl></div></div><div class="sect2" lang="fr"><div class="titlepage"><div><div><h3 class="title"><a id="N11AAC" />Configuration des périphériques</h3></div></div></div><p><code class="literal">DEV</code> peut désigner soit une interface réelle,
soit <code class="option">all</code>, soit <code class="option">default</code>.
<code class="option">Default</code> change également les paramètres des interfaces qui
seront créées par la suite.
</p><div class="variablelist"><dl><dt><span class="term">
<code class="filename">/proc/sys/net/ipv4/conf/DEV/accept_redirects</code>
</span></dt><dd><p>Si un routeur décide que vous l'utilisez à tort (c'est-à-dire qu'il
a besoin de ré-envoyer votre paquet sur la même interface), il vous
enverra un message <code class="literal">ICMP Redirect</code>.
Cela présente cependant un petit risque pour la sécurité, et vous pouvez
le désactiver ou utiliser les redirections sécurisées.
</p></dd><dt><span class="term">
<code class="filename">/proc/sys/net/ipv4/conf/DEV/accept_source_route</code>
</span></dt><dd><p>Plus vraiment utilisé.
On l'utilisait pour être capable de donner à un paquet une liste
d'adresses IP à visiter.
Linux peut être configuré pour satisfaire cette option IP.
</p></dd><dt><span class="term">
<code class="filename">/proc/sys/net/ipv4/conf/DEV/bootp_relay</code>
</span></dt><dd><p>Accepte les paquets avec une adresse source 0.b.c.d et des adresses
destinations qui ne correspondent ni à cet hôte, ni au réseau local.
On suppose qu'un démon de relais <acronym class="acronym">BOOTP</acronym> interceptera et
transmettra de tels paquets.
</p><p>La valeur par défaut est 0, puisque cette fonctionnalité n'est pas
encore implémentée (noyau 2.2.12).
</p></dd><dt><span class="term">
<code class="filename">/proc/sys/net/ipv4/conf/DEV/forwarding</code>
</span></dt><dd><p>Active ou désactive la transmission IP sur cette interface.
</p></dd><dt><span class="term">
<code class="filename">/proc/sys/net/ipv4/conf/DEV/log_martians</code>
</span></dt><dd><p>Voir la section sur le
<em class="citetitle"><a class="xref" href="ch13.html#lartc.kernel.rpf" title="Filtrage de Chemin Inverse (Reverse Path Filtering)">Filtrage de Chemin Inverse</a></em>.
</p></dd><dt><span class="term">
<code class="filename">/proc/sys/net/ipv4/conf/DEV/mc_forwarding</code>
</span></dt><dd><p>Si vous faites de la transmission multidistribution
(<em class="wordasword">multicast</em>) sur cette interface.
</p></dd><dt><span class="term">
<code class="filename">/proc/sys/net/ipv4/conf/DEV/proxy_arp</code>
</span></dt><dd><p>Si vous configurez ceci à 1, cet interface répondra aux requêtes
ARP pour les adresses que le noyau doit router.
Peut être très utile si vous mettez en place des
« <span class="quote">pseudo ponts ip</span> ».
Prenez bien garde d'avoir des masques de sous-réseau corrects avant
d'activer cette option. Faites également attention que le rp_filter
agisse aussi sur le requêtes ARP !
</p></dd><dt><span class="term">
<code class="filename">/proc/sys/net/ipv4/conf/DEV/rp_filter</code>
</span></dt><dd><p>Voir la section sur le
<em class="citetitle"><a class="xref" href="ch13.html#lartc.kernel.rpf" title="Filtrage de Chemin Inverse (Reverse Path Filtering)">Filtrage de Chemin Inverse</a></em>.
</p></dd><dt><span class="term">
<code class="filename">/proc/sys/net/ipv4/conf/DEV/secure_redirects</code>
</span></dt><dd><p>Accepte les messages de redirection ICMP seulement pour les
passerelles indiquées dans la liste des passerelles par défaut.
Activé par défaut.
</p></dd><dt><span class="term">
<code class="filename">/proc/sys/net/ipv4/conf/DEV/send_redirects</code>
</span></dt><dd><p>Active la possibilité d'envoyer les messages de redirections
mentionnées ci-dessus.
</p></dd><dt><span class="term">
<code class="filename">/proc/sys/net/ipv4/conf/DEV/shared_media</code>
</span></dt><dd><p>Si cela n'est pas activé, le noyau ne considère pas que différents
sous-réseaux peuvent communiquer directement sur cette interface.
La configuration par défaut est <code class="option">Yes</code>.
</p></dd><dt><span class="term">
<code class="filename">/proc/sys/net/ipv4/conf/DEV/tag</code>
</span></dt><dd><p>FIXME: à remplir
</p></dd></dl></div></div><div class="sect2" lang="fr"><div class="titlepage"><div><div><h3 class="title"><a id="N11B50" />Politique de voisinage</h3></div></div></div><p><code class="literal">DEV</code> peut désigner soit une interface réelle,
soit <code class="literal">all</code>, soit <code class="literal">default</code>.
<code class="literal">Default</code> change également les paramètres des interfaces
qui seront créées par la suite.
</p><div class="variablelist"><dl><dt><span class="term">
<code class="filename">/proc/sys/net/ipv4/neigh/DEV/anycast_delay</code>
</span></dt><dd><p>Valeur maximum du délai aléatoire de réponse exprimé en
<em class="wordasword">jiffies</em> (1/100 sec) aux messages de sollicitation
des voisins.
N'est pas encore implémenté (Linux ne possède pas encore le support
<em class="wordasword">anycast</em>).
</p></dd><dt><span class="term">
<code class="filename">/proc/sys/net/ipv4/neigh/DEV/app_solicit</code>
</span></dt><dd><p>Détermine le nombre de requêtes à envoyer au démon ARP de l'espace
utilisateur.
Utilisez 0 pour désactiver.
</p></dd><dt><span class="term">
<code class="filename">/proc/sys/net/ipv4/neigh/DEV/base_reachable_time</code>
</span></dt><dd><p>Une valeur de base utilisée pour le calcul du temps aléatoire
d'accès comme spécifié dans le RFC2461.
</p></dd><dt><span class="term">
<code class="filename">/proc/sys/net/ipv4/neigh/DEV/delay_first_probe_time</code>
</span></dt><dd><p>Délai avant de tester pour la première fois si le voisin peut être
atteint.
(voir <code class="literal">gc_stale_time</code>)
</p></dd><dt><span class="term">
<code class="filename">/proc/sys/net/ipv4/neigh/DEV/gc_stale_time</code>
</span></dt><dd><p>Détermine la fréquence à laquelle on doit vérifier les vieilles
entrées ARP.
Si une entrée est obsolète, elle devra de nouveau être résolue
(ce qui est utile quand une adresse IP a été attribuée à une autre
machine).
Si <code class="literal">ucast_solicit</code> est supérieur à 0, alors on
essaie d'abord d'envoyer un paquet ARP directement à l'hôte connu.
Si cela échoue, et que <code class="literal">mcast_solicit</code> est
supérieur à 0, alors une requête ARP est multidiffusée.
</p></dd><dt><span class="term">
<code class="filename">/proc/sys/net/ipv4/neigh/DEV/locktime</code>
</span></dt><dd><p>Une entrée ARP n'est remplacée par une nouvelle que si l'ancienne
est au moins présente depuis <code class="literal">locktime</code>.
Cela évite trop d'écriture dans le cache.
</p></dd><dt><span class="term">
<code class="filename">/proc/sys/net/ipv4/neigh/DEV/mcast_solicit</code>
</span></dt><dd><p>Nombre maximum d'essais consécutifs pour une sollicitation
<em class="wordasword">multicast</em>.
</p></dd><dt><span class="term">
<code class="filename">/proc/sys/net/ipv4/neigh/DEV/proxy_delay</code>
</span></dt><dd><p>Temps maximum (le temps réel est aléatoire et compris entre 0
et <code class="literal">proxytime</code>) avant de répondre à une requête ARP pour
laquelle nous avons une entrée de proxy ARP.
Peut être utilisé dans certains cas pour se prémunir des inondations
réseaux.
</p></dd><dt><span class="term">
<code class="filename">/proc/sys/net/ipv4/neigh/DEV/proxy_qlen</code>
</span></dt><dd><p>Longueur maximale de la file d'attente du temporisateur de cache arp
en attente (Voir <code class="literal">proxy_delay</code>).
</p></dd><dt><span class="term">
<code class="filename">/proc/sys/net/ipv4/neigh/DEV/retrans_time</code>
</span></dt><dd><p>Le temps, exprimé en <em class="wordasword">jiffies</em> (1/100 sec),
entre deux requêtes ARP.
Utilisé pour la résolution d'adresses et pour déterminer si un voisin est
inaccessible.
</p></dd><dt><span class="term">
<code class="filename">/proc/sys/net/ipv4/neigh/DEV/ucast_solicit</code>
</span></dt><dd><p>Nombre maximum de requêtes ARP unicast.
</p></dd><dt><span class="term">
<code class="filename">/proc/sys/net/ipv4/neigh/DEV/unres_qlen</code>
</span></dt><dd><p>Longueur maximum de la file d'attente pour la requête ARP en
cours : le nombre de paquets qui sont acceptés des autres couches
pendant la résolution ARP d'une adresse.
</p></dd><dt><span class="term">Internet QoS: Architectures and Mechanisms for Quality of Service,
Zheng Wang, ISBN 1-55860-608-4</span></dt><dd><p>Livre traitant des sujets liés à la qualité de service.
Bien pour comprendre les concepts de base.
</p></dd></dl></div></div><div class="sect2" lang="fr"><div class="titlepage"><div><div><h3 class="title"><a id="N11C07" />Configuration du routage</h3></div></div></div><div class="variablelist"><dl><dt><span class="term">
<code class="filename">/proc/sys/net/ipv4/route/error_burst</code>
</span></dt><dd><p>Ces paramètres sont utilisés pour limiter le nombre de messages
d'avertissement écrits dans le journal du noyau par le code de routage.
Plus le paramètre <code class="literal">error_burst</code> est grand, moins
il y aura de messages.
<code class="literal">Error_burst</code> contrôle le moment où les messages
seront supprimés.
Les configurations par défaut se limitent à un message d'avertissement
toutes les cinq secondes.
</p></dd><dt><span class="term">
<code class="filename">/proc/sys/net/ipv4/route/error_cost</code>
</span></dt><dd><p>Ces paramètres sont utilisés pour limiter le nombre de messages
d'avertissement écrits dans le journal du noyau par le code de routage.
Plus le paramètre <code class="literal">error_cost</code> est grand, moins il
y aura de messages.
<code class="literal">error_burst</code> contrôle le moment où les messages
seront jetés.
Les configurations par défaut se limitent à un message d'avertissement
toutes les cinq secondes.
</p></dd><dt><span class="term">
<code class="filename">/proc/sys/net/ipv4/route/flush</code>
</span></dt><dd><p>L'écriture dans ce fichier provoque la vidange du cache du routage.
</p></dd><dt><span class="term">
<code class="filename">/proc/sys/net/ipv4/route/gc_elasticity</code>
</span></dt><dd><p>Valeurs qui contrôlent la fréquence et le comportement de
l'algorithme <em class="wordasword">garbage collection</em> du cache de
routage.
Ceci peut être important en cas de défaut.
Au moins <code class="literal">gc_timeout</code> secondes s'écouleront avant
que le noyau ne passe à une autre route si la précédente n'est plus
opérationnelle.
Configuré par défaut à 300.
Diminuez cette valeur si vous voulez passer plus rapidement ce type de
problème.
</p><p>Voir aussi
<a class="ulink" href="http://mailman.ds9a.nl/pipermail/lartc/2002q1/002667.html" target="_top">
ce message</a> par Ard van Breemen.
</p></dd><dt><span class="term">
<code class="filename">/proc/sys/net/ipv4/route/gc_interval</code>
</span></dt><dd><p>Voir
<code class="filename">/proc/sys/net/ipv4/route/gc_elasticity</code>.
</p></dd><dt><span class="term">
<code class="filename">/proc/sys/net/ipv4/route/gc_min_interval</code>
</span></dt><dd><p>Voir
<code class="filename">/proc/sys/net/ipv4/route/gc_elasticity</code>.
</p></dd><dt><span class="term">
<code class="filename">/proc/sys/net/ipv4/route/gc_thresh</code>
</span></dt><dd><p>Voir
<code class="filename">/proc/sys/net/ipv4/route/gc_elasticity</code>.
</p></dd><dt><span class="term">
<code class="filename">/proc/sys/net/ipv4/route/gc_timeout</code>
</span></dt><dd><p>Voir
<code class="filename">/proc/sys/net/ipv4/route/gc_elasticity</code>.
</p></dd><dt><span class="term">
<code class="filename">/proc/sys/net/ipv4/route/max_delay</code>
</span></dt><dd><p>Délai d'attente pour la vidange du cache du routage.
</p></dd><dt><span class="term">
<code class="filename">/proc/sys/net/ipv4/route/max_size</code>
</span></dt><dd><p>Taille maximum du cache de routage.
Les vieilles entrées seront purgées quand le cache aura atteint cette
taille.
</p></dd><dt><span class="term">
<code class="filename">/proc/sys/net/ipv4/route/min_adv_mss</code>
</span></dt><dd><p>FIXME: à remplir
</p></dd><dt><span class="term">
<code class="filename">/proc/sys/net/ipv4/route/min_delay</code>
</span></dt><dd><p>Délai d'attente pour vider le cache de routage.
</p></dd><dt><span class="term">
<code class="filename">/proc/sys/net/ipv4/route/min_pmtu</code>
</span></dt><dd><p>FIXME: à remplir
</p></dd><dt><span class="term">
<code class="filename">/proc/sys/net/ipv4/route/mtu_expires</code>
</span></dt><dd><p>FIXME: à remplir
</p></dd><dt><span class="term">
<code class="filename">/proc/sys/net/ipv4/route/redirect_load</code>
</span></dt><dd><p>Facteurs qui déterminent si plus de redirections ICMP doivent être
envoyées à un hôte spécifique.
Aucune redirection ne sera envoyée une fois que la limite de charge
(<em class="wordasword">load limit</em>) ou que le nombre maximum de redirections
aura été atteint.
</p></dd><dt><span class="term">
<code class="filename">/proc/sys/net/ipv4/route/redirect_number</code>
</span></dt><dd><p>Voir
<code class="filename">/proc/sys/net/ipv4/route/redirect_load</code>.
</p></dd><dt><span class="term">
<code class="filename">/proc/sys/net/ipv4/route/redirect_silence</code>
</span></dt><dd><p>Temporisation pour les redirections.
Au dela de cette période, les redirections seront de nouveau envoyées,
même si elles ont été stoppées parce que la charge ou le nombre limite
a été atteint.
</p></dd></dl></div></div></div><div class="navfooter"><hr /><table summary="Navigation footer" width="100%"><tr><td align="left" width="40%"><a accesskey="p" href="ch13.html">Précédent</a> </td><td align="center" width="20%"><a accesskey="u" href="ch13.html">Niveau supérieur</a></td><td align="right" width="40%"> <a accesskey="n" href="ch14.html">Suivant</a></td></tr><tr><td valign="top" align="left" width="40%">Chapitre 13. Paramètres réseau du noyau </td><td align="center" width="20%"><a accesskey="h" href="index.html">Sommaire</a></td><td valign="top" align="right" width="40%"> Chapitre 14. Gestionnaires de mise en file d'attente avancés
& moins communs</td></tr></table></div></body></html>
