Le noyau utilise de nombreux paramètres qui peuvent être ajustés
en différentes circonstances. Bien que, comme d'habitude, les
paramètres par défaut conviennent à 99% des installations, nous ne
pourrions pas appeler ce document "HOWTO avancé" sans en dire un
mot.
Les éléments intéressants sont dans /proc/sys/net, jetez-y un
oeil. Tout ne sera pas documenté ici au départ, mais nous y
travaillons.
En attendant, vous pouvez jetter un oeil dans les sources du
noyau Linux et lire le fichier Documentation/filesystems/proc.txt.
La plupart des fonctionnalités y sont expliquées.
Par défaut, les routeurs routent tout, même les paquets qui
visiblement n'appartiennent pas à votre réseau. Un exemple courant
est l'espace des adresses IP privées s'échappant sur Internet. Si
vous avez une interface avec une route pour 195.96.96.0/24 dessus,
vous ne vous attendrez pas à voir arriver des paquets venant de
212.64.94.1.
Beaucoup d'utilisateurs veulent désactiver cette fonctionnalité.
Les développeurs du noyau ont permis de le faire facilement. Il y a
des fichiers dans /proc où vous pouvez ordonner au noyau de le
faire pour vous. La méthode est appelée "Reverse Path Filtering"
(Filtrage par chemin inverse). Pour faire simple, si la réponse à
ce paquet ne sort pas par l'interface par laquelle il est entré,
alors c'est un paquet "bogué" et il sera ignoré.
Les instructions suivantes vont activer cela pour toutes les
interfaces courantes et futures.
# for i in /proc/sys/net/ipv4/conf/*/rp_filter ; do
> echo 2 > $i
> done
En reprenant l'exemple du début, si un paquet arrivant sur le
routeur Linux par eth1 prétend venir du réseau Bureau+FAI, il sera
éliminé. De même, si un paquet arrivant du réseau Bureau prétend
être de quelque part à l'extérieur du pare-feu, il sera également
éliminé.
Ce qui est présenté ci-dessus est le filtrage de chemin inverse
complet. Le paramétrage par défaut filtre seulement sur les
adresses IP des réseaux directement connectés. Ce paramétrage par
défaut est utilisé parce que le filtrage complet échoue dans le cas
d'un routage asymétrique (où il y a des paquets arrivant par un
chemin et ressortant par un autre, comme dans le cas du trafic
satellite ou si vous avez des routes dynamiques (bgp, ospf, rip)
dans votre réseau. Les données descendent vers la parabole
satellite et les réponses repartent par des lignes terrestres
normales).
Si cette exception s'applique dans votre cas (vous devriez être
au courant), vous pouvez simplement désactiver le rp_filter sur
l'interface d'arrivée des données satellite. Si vous voulez voir si
des paquets sont éliminés, le fichier log_martians du même
répertoire indiquera au noyau de les enregistrer dans votre
syslog.
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 Documentation/ip-sysctl.txt.
Certaines de ces configurations ont des valeurs par défaut
différentes suivant que vous répondez "Yes" ou "No" à la question
"Configure as router and not host" lors de la compilation du
noyau.
ipv4 générique
En remarque générale, les fonctionnalités de limitation de débit
ne fonctionnent pas sur l'interface loopback. N'essayez donc pas de
les tester localement. Les limites sont exprimées en "jiffies"
("tic-tac") et sont contraintes d'utiliser le "token bucket filter"
mentionné plus tôt.
[NdT : le terme "jiffies" désigne un mouvement régulier,
faisant référence au "tic-tac" d'un horloge. Dans le noyau
lui-même, une variable globale nommée jiffies est incrémenté à
chaque interruption d'horloge]
Le noyau a une horloge interne qui tourne à "HZ" impulsions (ou
"jiffies") par seconde. Sur intel, "HZ" est la plupart du temps de
100. Donc, configurer un fichier *_rate à, disons 50, autorise 2
paquets par seconde. Le "token bucket filter" est également
configuré pour autoriser une rafale de données de au plus 6
paquets, si suffisamment de jetons ont été gagnés.
Plusieurs éléments de la liste suivante proviennent du fichier
/usr/src/linux/Documentation/networking/ip-sysctl.txt, écrit par
Alexey Kuznetsov <kuznet@ms2.inr.ac.ru> et Andi Kleen
<ak@muc.de>
/proc/sys/net/ipv4/icmp_destunreach_rate
Si le noyau décide qu'il ne peut pas délivrer un paquet, il le
rejetera et enverra à la source du paquet un ICMP notifiant ce
rejet.
/proc/sys/net/ipv4/icmp_echo_ignore_all
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.
Si vous pinguez l'adresse de diffusion d'un réseau, tous les
hôtes sont censés répondre. Cela permet de coquettes attaques de
déni de service. Mettez cette valeur à 1 pour ignorer ces messages
de diffusion.
/proc/sys/net/ipv4/icmp_echoreply_rate
Le débit auquel les réponses echo sont envoyées aux
destinataires.
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.
/proc/sys/net/ipv4/icmp_paramprob_rate
Un message ICMP relativement peu connu, qui est envoyé en
réponse à des paquets qui ont des entêtes IP ou TCP erronées. Avec
ce fichier, vous pouvez contrôler le débit auquel il est
envoyé.
/proc/sys/net/ipv4/icmp_timeexceed_rate
Voici la célèbre cause des "étoiles Solaris" dans traceroute.
Limite le nombre de messages ICMP Time Exceeded envoyés.
/proc/sys/net/ipv4/igmp_max_memberships
Nombre maximal de sockets igmp (multidistribution) en écoûte sur
l'hôte. FIXME: Est-ce vrai ?
/proc/sys/net/ipv4/inet_peer_gc_maxtime
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 pool. Mesuré en "jiffies". [NdT :
Le pool désigne ici la liste des adresses IP des partenaires
internet.]
/proc/sys/net/ipv4/inet_peer_gc_mintime
Intervalle de temps minimum entre deux passages du
ramasse-miettes. Cet intervalle est pris en compte lors d'une
utilisation intensive du pool. Mesuré en "jiffies".
/proc/sys/net/ipv4/inet_peer_maxttl
Durée de conservation maximale des enregistrements. Les entrées
non utilisées expireront au bout de cet intervalle de temps (cad
quand le nombre d'entrée dans le pool est très petit). Mesuré en
"jiffies".
/proc/sys/net/ipv4/inet_peer_minttl
Durée de conservation minimale des enregistrements. Devrait être
suffisante pour prendre en compte le temps de vie des fragments sur
l'hote qui doit réassembler les paquets. Cette durée minimale est
garantie si le nombre d'éléments dans le pool est inférieur au
seuil fixé par inet_peer_threshold
/proc/sys/net/ipv4/inet_peer_threshold
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 d'entrées,
temps de vie plus faible, intervalle du ramasse-miettes plus
faible.
/proc/sys/net/ipv4/ip_autoconfig
Ce fichier contient la valeur 1 si l'hôte a reçu sa
configuration IP par RARP, BOOTP, DHCP ou un mécanisme similaire.
Autrement, contient la valeur zéro.
/proc/sys/net/ipv4/ip_default_ttl
Durée de vie (TTL) des paquets. Fixer à la valeur sûre de 64.
Augmentez-là si vous avez un réseau immense, mais pas "pour
s'amuser" : les boucles sans fin d'un mauvais routage sont
plus dangereuses si le TTL est élevé. Vous pouvez même envisager de
diminuer la valeur dans certaines circonstances.
/proc/sys/net/ipv4/ip_dynaddr
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
locales 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ée une interface, suivie par
une deuxième tentative réussie (avec une adresse IP
différente).
/proc/sys/net/ipv4/ip_forward
Le noyau doit-il essayer de transmettre les paquets ?
Désactivé par défaut.
/proc/sys/net/ipv4/ip_local_port_range
Intervalle des ports locaux pour les connexions sortantes. En
fait, assez petit par défaut, 1024 à 4999.
/proc/sys/net/ipv4/ip_no_pmtu_disc
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 recette de cuisine.
/proc/sys/net/ipv4/ipfrag_high_thresh
Mémoire maximum utilisée pour réassembler les fragments IP.
Quand ipfrag_high_thresh octets de mémoire sont alloués pour cela,
le gestionnaire de fragments rejetera les paquets jusqu'à ce que
ipfrag_low_thresh soit atteint.
/proc/sys/net/ipv4/ip_nonlocal_bind
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.
/proc/sys/net/ipv4/ipfrag_low_thresh
Mémoire minimale utilisée pour réassembler les fragments IP.
/proc/sys/net/ipv4/ipfrag_time
Temps en secondes du maintien d'un fragment IP en mémoire.
/proc/sys/net/ipv4/tcp_abort_on_overflow
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é.
/proc/sys/net/ipv4/tcp_fin_timeout
Temps de maintien de l'état FIN-WAIT-2 pour une socket dans le
cas où elle a été fermée de notre coté. Le partenaire peut être
défectueux et ne jamais avoir fermé son coté 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 mortes. Les sockets FIN-WAIT2 sont moins
dangereuses que les sockets FIN-WAIT1 par qu'elles consomment au
maximum 1,5K de mémoire mais, elles ont tendance à vivre plus
longtemps. Cf tcp_max_orphans.
/proc/sys/net/ipv4/tcp_keepalive_time
Durée entre l'envoi de deux messages "keepalive" quand l'option
"keepalive" est activée.
Par défaut : 2 heures.
/proc/sys/net/ipv4/tcp_keepalive_intvl
A quelle fréquence les sondes sont retransmises quand une sonde
n'a pas été acquittée.
Par défaut : 75 secondes
/proc/sys/net/ipv4/tcp_keepalive_probes
Combien de sondes TCP "keepalive" seront envoyées avant de
décider que la connexion est brisée.
Par défaut : 9.
En multipliant par tcp_keepalive_intvl, cela donne le temps qu'un
lien peut être actif sans donner de réponses après l'envoi d'un
"keepalive".
/proc/sys/net/ipv4/tcp_max_orphans
Nombre maximum de sockets TCP qui ne sont pas reliées à 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
n'existe seulement que 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 de tel état.
Laissez-moi vous rappeler encore que chaque orphelin consomme
jusqu'à environ 64K de mémoire non swappable.
/proc/sys/net/ipv4/tcp_orphan_retries
Combien d'essais avant de détruire une connexion TCP, fermée par
notre coté. La valeur par défaut de 7 correspond à un temps de
environ 50s à 16 min suivant le RTO. Si votre machine supporte un
serveur Web, vous pouvez envisager de baisser cette valeur, dans la
mesure où de telles sockets peuvent consommer des ressources
significatives. Cf tcp_max_orphans.
/proc/sys/net/ipv4/tcp_max_syn_backlog
Nombre maximal de requêtes d'une connexion mémorisée, qui
n'avait pas encore reçue 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 TCP_SYNQ_HSIZE dans le fichier
include/net/tcp.h pour garder TCP_SYNQ_HSIZE*16 <=
tcp_max_syn_backlog et de recompiler de noyau.
/proc/sys/net/ipv4/tcp_max_tw_buckets
Nombre maximal de sockets timewait gérées par le système
simultanément. Si ce nombre est dépassé, la socket timewait est
immédiatement détruite 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.
/proc/sys/net/ipv4/tcp_retrans_collapse
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.
/proc/sys/net/ipv4/tcp_retries1
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 minimal du RFC est de 3, qui est celle par défaut
et qui correspond à un temps de environ 3 sec à 8 min suivant le
RTO.
/proc/sys/net/ipv4/tcp_retries2
Combien d'essais avant de détruire une connexion TCP active. La
RFC 1122 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 RTO.
/proc/sys/net/ipv4/tcp_rfc1337
Ce booléen active un rectificatif pour "l'assassinat hazardeux
des time-wait dans tcp", décrit dans le RFC 1337. Si activé, le
noyau rejette les paquets RST pour les sockets à l'état de
time-wait.
Par défaut : 0
/proc/sys/net/ipv4/tcp_sack
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.
/proc/sys/net/ipv4/tcp_stdurg
Utilise l'interprétation de la RFC Host Requirements 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)
/proc/sys/net/ipv4/tcp_syn_retries
Nombre de paquets SYN que le noyau enverra avant de tenter
l'établissement d'une nouvelle connexion.
/proc/sys/net/ipv4/tcp_synack_retries
Pour ouvrir l'autre coté de la connexion, le noyau envoie un SYN
avec un ACK superposé (piggyback), pour accuser réception du SYN
précédemment envoyé. Ceci est la deuxième partie de la poignée de
main à trois voies (threeway handshake). Cette configuration
détermine le nombre de paquets SYN+ACK à envoyer avant que le noyau
n'abandonne la connexion.
/proc/sys/net/ipv4/tcp_timestamps
Les estampilles horaires sont utilisées, entre autre, 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'estampille horaire permet de
reconnaître cet "ancien paquet".
/proc/sys/net/ipv4/tcp_tw_recycle
Mise en place du recyclage rapide des sockets TIME-WAIT. La
valeur par défaut est 1. Celle-ci ne devrait pas être changée sans
le conseil/demande d'experts techniques.
/proc/sys/net/ipv4/tcp_window_scaling
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 "windows scaling" autorisent des fenêtres
jusqu'au gigaoctet, ce qui est adapté pour les produits à grande
bande passante.
Configuration des périphériques
DEV peut désigner soit une interface réelle, soit "all", soit
"default". Default change également les paramètres des interfaces
qui seront créées par la suite.
/proc/sys/net/ipv4/conf/DEV/accept_redirects
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 ICMP Redirect. Cela présente cependant
un petit risque pour la sécurité, et vous pouvez le désactiver ou
utiliser les redirections sécurisées.
/proc/sys/net/ipv4/conf/DEV/accept_source_route
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.
/proc/sys/net/ipv4/conf/DEV/bootp_relay
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 relai BOOTP interceptera et
transmettra de tels paquets.
La valeur par défaut est 0, puique cette fonctionnalité n'est
pas encore implémentée (noyau 2.2.12).
/proc/sys/net/ipv4/conf/DEV/forwarding
Active ou désactive la transmission IP sur cette interface.
/proc/sys/net/ipv4/conf/DEV/log_martians
Voir la section sur le "reverse path filters"
/proc/sys/net/ipv4/conf/DEV/mc_forwarding
Si vous faites de la transmission multidistribution (multicast)
sur cette interface.
/proc/sys/net/ipv4/conf/DEV/proxy_arp
Si vous configurez ceci à 1, toutes les autres interfaces
répondront aux requêtes arp destinées à l'adresse de cette
interface. Peut être très utile si vous mettez en place des
"pseudo-ponts ip". Prenez bien garde d'avoir des masques de
sous-réseau correctes avant d'activer cette option.
/proc/sys/net/ipv4/conf/DEV/rp_filter
Voir la section sur le "reverse path filters"
/proc/sys/net/ipv4/conf/DEV/secure_redirects
Accepte les messages de redirection ICMP seulement pour les
passerelles indiquées dans la liste des passerelles par défaut.
Activé par défaut.
/proc/sys/net/ipv4/conf/DEV/send_redirects
Active la possibilité d'envoyer des messages de redirections
mentionnées ci-dessus.
/proc/sys/net/ipv4/conf/DEV/shared_media
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 'oui'.
/proc/sys/net/ipv4/conf/DEV/tag
FIXME: à remplir
Politique de voisinage
DEV peut désigner soit une interface réelle, soit "all", soit
"default". Default change également les paramètres des interfaces
qui seront créées par la suite.
/proc/sys/net/ipv4/neigh/DEV/anycast_delay
Valeur maximum du délai aléatoire de réponse exprimé en
"jiffies" (1/100 sec) aux messages de sollicitation des voisins.
N'est pas encore implémenté (Linux ne possède pas encore le support
anycast). Maximum for random delay of answers to neighbor
solicitation messages in jiffies (1/100 sec). Not yet implemented
(Linux does not have anycast support yet).
/proc/sys/net/ipv4/neigh/DEV/app_solicit
Détermine le nombre de requêtes à envoyer au démon ARP de
l'espace utilisateur. Utiliser 0 pour désactiver.
/proc/sys/net/ipv4/neigh/DEV/base_reachable_time
Une valeur de base utilisée pour le calcul du temps aléatoire
d'accès comme spécifié dans la RFC2461.
Délai avant de tester pour la première fois si le voisin peut
être atteint. (voir gc_stale_time)
/proc/sys/net/ipv4/neigh/DEV/gc_stale_time
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 ucast_solicit est supérieur à 0, alors on
essaie d'abord d'envoyer un paquet ARP directement à l'hôte connu.
Si cela échoue, et que mcast_solicit est supérieur à 0, alors une
requête ARP est multidiffusée.
/proc/sys/net/ipv4/neigh/DEV/locktime
Une entrée ARP n'est remplacée par une nouvelle que si
l'ancienne est au moins présente depuis "locktime". Cela évite trop
d'écriture dans le cache.
/proc/sys/net/ipv4/neigh/DEV/mcast_solicit
Nombre maximum d'essais consécutifs pour une solicitation
multicast. Maximum number of retries for multicast
solicitation.
/proc/sys/net/ipv4/neigh/DEV/proxy_delay
Temps maximum (le temps réel est aléatoire et compris entre 0 et
proxytime) 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évenir des inondations réseaux.
/proc/sys/net/ipv4/neigh/DEV/proxy_qlen
Longueur maximale de la file d'attente du temporisateur de cache
arp en attente (Voir proxy_delay).
/proc/sys/net/ipv4/neigh/DEV/retrans_time
Le temps, exprimé en "jiffies" (1/100 sec), entre deux requêtes
ARP. Utilisé pour la résolution d'adresses et pour déterminer si un
voisin est inaccessible.
/proc/sys/net/ipv4/neigh/DEV/ucast_solicit
Nombre maximum de requêtes ARP unicast.
/proc/sys/net/ipv4/neigh/DEV/unres_qlen
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.
Internet QoS: Architectures and Mechanisms for Quality of
Service, Zheng Wang, ISBN 1-55860-608-4
Livre traitant des sujets liés à la qualité de service. Bien
pour comprendre les concepts de base.
Configuration du routage
/proc/sys/net/ipv4/route/error_burst
Ces paramètres sont utilisés pour limiter le nombre de messages
d'avertissement écrits les messages du noyau provenant du code du
routage. Plus le paramètre error_burst est grand, moins il y aura
de messages. Error_burst contrôle le moment où les messages seront
supprimés. Les configurations par défaut limitent à un message
d'avertissement toutes les cinq secondes.
/proc/sys/net/ipv4/route/error_cost
Ces paramètres sont utilisés pour limiter le nombre de messages
d'avertissement écrits les messages du noyau provenant du code du
routage. Plus le paramètre error_cost est grand, moins il y aura de
messages. Error_burst contrôle le moment où les messages seront
jetés. Les configurations par défaut limitent les messages
d'avertissement à un toutes les cinq secondes.
/proc/sys/net/ipv4/route/flush
L'écriture dans ce fichier provoque le vidage du cache du
routage.
/proc/sys/net/ipv4/route/gc_elasticity
Valeurs qui contrôlent la fréquence et le comportement de
l'algorithme "garbage collection" pour le cache du routage. Ceci
peut être important en cas d'échec. Au moins gc_timeout 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.
Taille maximum du cache de routage. Les vieilles entrées seront
purgées quand le cache aura atteint cette taille.
/proc/sys/net/ipv4/route/min_adv_mss
FIXME: à remplir
/proc/sys/net/ipv4/route/min_delay
Délai pour vider la cache de routage.
/proc/sys/net/ipv4/route/min_pmtu
FIXME: à remplir
/proc/sys/net/ipv4/route/mtu_expires
FIXME: à remplir
/proc/sys/net/ipv4/route/redirect_load
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 (load limit) ou que le
nombre maximum de redirections a été atteint.
/proc/sys/net/ipv4/route/redirect_number
Voir /proc/sys/net/ipv4/route/redirect_load.
/proc/sys/net/ipv4/route/redirect_silence
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 par le fait que la charge ou le nombre limite aît été
atteint.
