1. Etude de la stack réseau sous GNU Linux Thierry GAYET (ALTEN) – 11/2007 – v1.0 – OSP 005 – Creative Common [email_address]

3. Historique Le développement de la couche réseau dans le noyau Linux a été orchestré par plusieurs programmeurs indépendants. Le but est d'implémenter un système qui soit au moins aussi performant que les autres tout en restant dans le domaine du logiciel libre. C'est avant tout le protocole TCP/IP qui a été développé avec des primitives de base par Ross Biro . Orest Zborowski produisit la première interface socket BSD pour le noyau GNU Linux. Le code fut ensuite repris par Alan Cox de Red Hat.

5. Protocoles gérés Disponibilité des fonctionnalités dans la pile réseau en fonction des versions du noyau Linux 2.2, 2.4 et 2.6 

6. Support du réseau dans le Kernel Modèle Internet de la pile réseau. Architecture de la pile réseau .  La pile réseau couvre le protocole TCP/IP de la couche liaison (drivers) jusqu'à la couche transport (sockets BSD).  D'un point de vue de Linux, la pile est localisée dans le noyau avec une API (les sockets BSD) pouvant être appelée depuis l'espace utilisateur. Couche matérielle Couche de liaison Couche réseau Couche transport Couche applicative Application utilisateur Driver réseau Protocoles réseaux Interface de diagnostique des devices Interface de diagnostique des protocoles Appels système Carte réseau Application User space Kernel space

8. Les drivers réseaux : introduction Un driver réseau est la troisième catégorie de drivers Linux après les drivers de blocs et de caractères. Le fonctionnement d'une interface réseau au sein du système est assez similaire à un driver de blocs. Un driver de blocs est utilisé par le noyau pour transmettre ou recevoir des blocs de données. D'un point de vue similaire, un driver réseau s'enregistre auprès du noyau de Façon à pouvoir échanger des paquets de données avec l'extérieur. Il y a cependant une différence avec un driver de blocs qui consiste à ne pas avoir de point d'entrée dans le répertoire dédié aux devices /dev. Il n'est donc pas possible de mettre en application la règle qui veut que sous Unix / GNU Linux tout soit considéré comme un fichier. La différence la plus importante entre ces deux types de drivers est que le driver de blocs n'est utilisé que lorsque le driver y fait appel tandis qu'un drivers réseau reçoit les paquets réseau de façon asynchrone depuis l'extérieur. Ainsi, alors qu'un driver de blocs demande avant d'envoyer quelque chose au noyau, le driver réseau demande à pusher des données. 

9. Les drivers réseaux : découpage modulaire  http://docs.huihoo.com/linux/kernel/a1/index.html L'architecture réseau permet au noyau Linux de se connecter à d'autres système via le réseau. Il existe un certain nombre important de matériel ainsi qu'un nombre important de protocole supportés . Chaque objet réseau est représenté via une socket. Les sockets sont associées aux process dans le même sens que les i-nodes d'un système de fichiers peuvent être associées. Une socket peut être partagée par plusieurs processus. L'architecture réseau utilise le scheduler de process du noyau Linux schedule() pour suspendre ou reprendre un process en état d'attente de données (géré par un système de gestion du contrôle et du flow de données). De plus, la couche VFS apporte un système de fichiers logique (comme pour le cas de NFS ; il existe des possibilités en mode user via libfuse)

11. Chargement d'un driver réseau dynamiquement dans le kernel  Kmod est le chargeur de module dans le noyau GNU Linux. Le chargement initialise le nom du module (argv[0]) à charger. Si au lieu d'utiliser insmod, modprobe est utilisé, kmod ira regarder la configuration /etc/modprobe.conf

12. Les drivers réseaux : enregistrement Machine à états pour l'enregistrement d'un device réseau.

13. Les drivers réseaux : exemple d'implémentation (old) #if defined(MODULE) && LINUX_VERSION_CODE > 0x20115 MODULE_AUTHOR(&quot;Donald Becker <becker@cesdis.gsfc.nasa.gov>&quot;); MODULE_DESCRIPTION(&quot;3Com 3c590/3c900 series Vortex/Boomerang driver&quot;); MODULE_PARM(debug, &quot;i&quot;); ... #endif ... #ifdef MODULE int init_module(void) { ... } #else int tc59x_probe(struct device *dev) { ... } #endif /* not MODULE */ ... static int vortex_scan(struct device *dev, struct pci_id_info pci_tbl[]) { ... #if defined(CONFIG_PCI) || (defined(MODULE) && !defined(NO_PCI)) ... #ifdef MODULE if (compaq_ioaddr) { vortex_probe1(0, 0, dev, compaq_ioaddr, compaq_irq, compaq_device_id, cards_found++); dev = 0; } #endif return cards_found ? 0 : -ENODEV; } ... #ifdef MODULE void cleanup_module(void) { ... ... ... } #endif Example de code issue du code source du drivers réseau ( drivers/net/3c59x.c) destiné au Noyau 2.2.14. Il y a un nombre important de #ifdef MODULE et de #if defined (MODULE). Cela est assez représentatif de l'ancienne façon de programmer qui définissait le fonctionnement d'un module dynamique en fonction de la façon dont il était compilé tel un module statique au sein De l'image d'un noyau.

14. Les drivers réseaux : exemple d'implémentation (new) static char version[] _ _devinitdata = DRV_NAME &quot; ... &quot;; static struct vortex_chip_info { ... } vortex_info_tbl[] _ _devinitdata = { {&quot;3c590 Vortex 10Mbps&quot;, ... ... ... } static int _ _init vortex_init (void) { ... } static void _ _exit vortex_cleanup (void) { ... } module_init(vortex_init); module_exit(vortex_cleanup); Dans cette nouvelle version, les directives de pré-processing ne sont plus nécessaires ce qui enlève tous les #ifdef et #endif. Cela le rend plus facile à lire pour les développeurs de drivers via l'utilisation d'un ensemble de macros ( _ _init , _ _exit , et _ _devinitdata ).

15. Les drivers réseaux : exemple d'implémentation (macros 1/2) Liste des sections de mémoire pouvant être initialisées par des macros dans les drivers réseau. La plupart de ces macros sont définies dans le header include/linux/init.h

16. Les drivers réseaux : exemple d'implémentation (macros 2/2) A utiliser par les structures de données marquées par le tag __exitcall. _exitdata Initialise une structure à la séquence de BOOT. _initdata Anciennement appelée par la routine de sortie du drivers lors de son déchargement. _ _exitcall Macro obsolète. _ _initcall Ensemble de routine pour modifier l'ordre de priorité dans les routines de virtualisation exécutées lors de la séquence de BOOT. core_initcall, postcore_initcall, arch_initcall, subsys_initcall, fs_initcall, device_initcall, late_initcall Appelée lorsque le composant kernel est déchargé du noyau. _ _exit Routine d'initialisation lors de la séquence de boot. _ _init Description Macro

19. Les buffers sk 3/4 La structure du buffer_sk est géré via une liste doublement chaînée.

22. L'équipe de Netfilter et son leader actuel Patrick McHardy : Team Leader du projet Netfilter . The core Team du projet Netfilter.

23. Architecture La pile TCP/IP est directement implémentée dans le noyau. Les trames émises et reçues peuvent être amenées à traverser l’ensemble des couches (matérielles et logicielles) : Emission Réception Représentation des trames dans le Kernel Space les paquets sont manipulés par le noyau dans des structures de type sk_buffer. Le parcours d’une trame reçue ou à émettre, le traitement dans la pile IP peut être découpé en phases.

24. Circulation des paquets 1/2 Le traitement IP comporte 4 grandes phases :  La réception de trame : point d’entrée dans la couche IP pour les trames reçues sur les interfaces réseau.  Le routage : choix de la route à suivre par le paquet (réémission sur une autre interface/ réseau ou destination locale)  Le forwarding : contrôle du TTL et du MTU avant de passer à la phase de réémission.  L’émission : les paquets à émettre ou à réémettre passent par cette étape. Juste avant de quitter la couche IP l’en-tête Ethernet est complété.

25. Circulation des paquets 2/2 Couche transport OSI #4 Couche réseau OSI #3 Couche liaison OSI #2 Couche physique OSI #1 Cheminement des paquets dans les différentes couches de la stack réseau du kernel GNU Linux  Une carte réseau utilise 2 listes permettant de gérer les paquets entrants ( rx_ring ) et les paquets sortants ( tx_ring ) de la ou des interfaces réseaux. On peut ainsi distinguer la procédure d’émission de la procédure de réception. Pour les noyaux 2.2 et inférieurs, le traitement des trames est différent (ex : on ne retrouve pas les files tx et rx ).

26. Estimation du coût (temps et consommation mémoire) des recopie de paquets dans la pile réseau 1/5 1: Physical Layer 4: Transport 3: Network 7: Application 6: Presentation 5: Session TCP / IP vs. OSI model Le but étant de faire une estimation des recopies mémoire d'un paquet réseau de la carte réseau à la socket BSD  2: Data Link Interface Layer (Ethernet, etc.) Protocol Layer (TCP / IP) Socket layer Process

27. Estimation du coût (temps et consommation mémoire) des recopies de paquets dans la pile réseau 2/5 Application 1: sosend (……………... ) Couche des sockets BSD 2: tcp_output ( ……. ) Couche transport (TCP / UDP) 3: ip_output ( ……. ) Couche liaison (Ethernet Device Driver) 5: recvfrom(……….) 3: ip_input ( ……... ) 4: tcp_input ( ……... ) Couche protocole (IP) 4: ethernet_output ( ……. ) 2: ethernet_input ( …….. ) Carte réseau Résumé des couches  Queue de sortie Queue d'entrée

28. Estimation du coût (temps et consommation mémoire) des recopies de paquets dans la pile réseau 3/5 send (int socket, const char *buf, int length, int flags) Userspace Kernelspace sendto (int socket, const char *data_buffer, int length, int flags, struct sockaddr *destination, int destination _length) sendit (struct proc *p, int socket, struct msghdr *mp, int flags, int *return_size) sosend (struct socket *s, struct mbuf *addr, struct uio *uio, struct mbuf *top, struct mbuf *control, int flags )  uipc_syscalls.c  uipc_socket.c tcp_userreq (struct socket *s, int request, struct mbuf *m, struct mbuf * nam, struct mbuf * control )  tcp_userreq.c tcp_output (struct tcpcb *tp)  tcp_output.c TCP Layer

29. Estimation du coût (temps et consommation mémoire) des recopies de paquets dans la pile réseau 4/5 Réception d'un paquet

30. Estimation du coût (temps et consommation mémoire) des recopies de paquets dans la pile réseau 5/5 Algorigramme de la fonction tcp recvmsg 

31. Latence 1/2 L'étude de la latence des couches de la pile réseau TCP/IP sur l'envoi d'un paquet de 1024 octets en UDP et en TCP toutes les secondes montre les résultats suivant : Globalement le temps de recopie pour 1024 octets est de 1 µs, l'appel à la primitive système de la socket BSD est D'environ 2 µs et le temps de checksum en UDP est aussi de 2 µs. L'utilisation du DMA pour le transfert des données entre le device et la mémoire est un réel atout d'un point de vue des Performances. Le temps d'émission par le driver réseau d'un paquet réseau est en dessous des 2 µs mais il monte à environ 4 µs en réception du fait de la complexité inhérente du driver dans son mode réception. De plus, ce dernier mode possède une recopie mémoire non négligeable. UDP: Le temps d'émission pour 1024 octets en UDP quand le checksum est requis est de 18.9 µs alors qu'en réception cela Demande 35 µs. La capacité maximum d'envoie en UDP est donc de 433 Mbits/s alors qu'en réception le taux est de 234 Mbits/s. TCP: Avec le protocole TCP, l'envoie d'un paquet de 1024 octets met 22.5 µs et 36 µs en réception. La vitesse maximum en Émission est de 364Mbits/s alors qu'en réception elle est de 228Mbits/s. Lorsque le destinataire/expéditaire est local (localhost) la capacité maximale est d'environ 150 Mbit/s. Le temps global nécessaire dans le noyau GNU Linux pour les recopies mémoires, les checksums et les appels systèmes sont de 22% pour la partie émission en TCP et 16.7% pour la partie réception avec le même protocole. Idem pour UDP.

32. Latence 2/2 Résumé du benchmark précédent : Emission  Réception 

33. Spécificité du protocole ARP Par définition, les hooks netfilter servent à capturer des trames IP. Il n’est ainsi pas possible de voir les requêtes ARP. On peut cependant les capturer à la sortie du driver de la carte réseau au moment du choix du traitement à appliquer sur la trame en fonction du protocole identifié par le champs skb->protocol de la structure sk_buffer. Pour cela, à chacun de ces protocoles (IPv4, IPv6, ARP, BOOTP, ...) est associé une structurede type packet_type enregistré dans une file ( ptype_all ou la table de hash ptype_base ). La file ptype_all est utilisée pour capturer tous les paquets provenant (ou à destination) de toutes les interfaces réseaux. ptype_base est « hashée » par identifiant de protocole et permet de décider à quelle fonction est destiné le paquet (sk_buffer). Un sk_buffer peut « matcher » une ou plusieurs entrées dans la table. A l ‘émission, seuls les paquets de type ETH_P_ALL peuvent être capturés. Il est important de noter que, comme pour le chemin suivi par les trames dans le noyau, les fonctions utilisées dans le packet handling peuvent changer selon la version du noyau utilisé. Pour récupérer les trames ARP, il suffit d’enregistrer une structure packet_type dans une des listes ptype (ptype_base ou ptype_all) avec la fonction de callback dev_add_pack() (définie dans linux/netdevice.h ). Comme pour les netfilter hooks, il faut supprimer ce hook (packet handling) lorsque le module est retiré du noyau. Ceci se fait grâce à la fonction dev_remove_pack() ( linux/netdevice.h ). En enregistrant une fonction pour ETH_P_ALL notre packet type se retrouvera dans la liste ptype_all. On va ainsi récupérer toutes les trames arrivant (ou à destination) du driver de la carte réseau. Lorsque l’on récupère un sk_buffer avec ce type de hook, c’est en fait une copie du sk_buffer capturé sur laquelle on va travailler. La copie doit être détruite en fin de fonction avec la fonction kfree_skb() . Ce type de hook n’est donc pas destiné à modifier le paquet capturé. Position des hooks de type « packet handling » dans la chaîne de traitement des trames reçues ou à émettre.

35. Netfilter 2/2 Un hook peut se définir comme un point d’accès dans une chaîne de traitement (par exemple : saisie au clavier, parcours de la pile TCP/IP…). Netfilter est un ensemble de hooks à l’intérieur du noyau Linux permettant aux modules noyau d’enregistrer des fonctions de callback dans la pile IP. Les trames ainsi capturées peuvent être analysées, jetées ou modifiées. Le firewall « natif » de linux iptables n’est qu’un module « sur-couche » de netfilter permettant de définir un système de règles de filtrage et masquerading (translation d’adresse) de trames IP à partir des hooks.

36. Netfilter : étude de cas 1/2 Ecriture d'un driver gérant un hook netfilter : // Fonction standard de chargement d'un driver sous GNU linux : int init_module () { nfho_tunnel_in.hook = hook_func_tunnel_in; nfho_tunnel_in.hooknum = NF_IP_PRE_ROUTING; nfho_tunnel_in.pf = PF_INET; nfho_tunnel_in.priority = NF_IP_PRI_FIRST; nf_register_hook(&nfho_tunnel_in); printk(&quot;NF_HOOK: Module instale&quot;); return 0; } // Fonction standard de déchargement d'un driver // sous GNU Linux : void cleanup_module () { printk(&quot; NF_HOOK: I'll be back ....&quot;); nf_unregister_hook(&nfho_tunnel_in); }

42. Routage 5/5 Le rôle de la couche IP est de décider comment orienter les paquets vers leur destination finale. Pour rendre cela possible, chaque interface sur le réseau est associée à un contexte réseau obtenu soit statiquement, soit dynamiquement. Une adresse IP est constituée de quatre nombres séparés par des points, comme `167.216.245.249'. Chaque nombre étant compris entre zéro et 255. Consultation de la table de routage : $ ip route ls 192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.3 192.168.1.0/24 dev eth2 proto kernel scope link src 192.168.1.4 10.194.61.0/24 dev eth1 proto kernel scope link src 10.194.61.86 default via 10.194.61.1 dev eth1 default via 192.168.1.1 dev eth2 default via 192.168.1.1 dev eth0  http://mirabellug.org/wikini/upload/Documentations_routage.pdf $ /sbin/route –n Table de routage IP du noyau Destination Passerelle Genmask Indic Metric Ref Use Iface 192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth2 10.194.61.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1 0.0.0.0 10.194.61.1 0.0.0.0 UG 0 0 0 eth1 0.0.0.0 192.168.1.1 0.0.0.0 UG 0 0 0 eth2 0.0.0.0 192.168.1.1 0.0.0.0 UG 0 0 0 eth0

45. Filtrage 3/9 : iptables / ip6tables La branche gauche représente le trajet des paquets qui entrent et qui sortent vers et depuis un processus local (SMB, FTP, HTTP etc.) La branche de droite représente le trajet des paquets qui traversent notre passerelle dans sa fonction de routeur. Diagramme simplifié de l'emplacement des hooks de netfilter avec lesquels iptables peut interragir   Attention toutefois, ces diagrammes sont faux, dans la mesure où ils sont largement simplifiés. Leur but est uniquement de montrer où Netfilter vient interagir avec la pile IP, en aucun cas il ne représente l'architecture complète de la pile IP !!

51. Filtrage 9/9 : iptables / ip6tables Diagramme général permettant la gestion des paquets via le module iptables 

52. LES PRIMITIVES KERNEL POUR LE RESEAU

53. Primitives réseau du kernel 1/6 Check if a queue is empty : int skb_queue_empty (struct sk_buff_head * list); Reference buffer : struct sk_buff * skb_get (struct sk_buff * skb); Free an sk_buff : void kfree_skb (struct sk_buff * skb); Is the buffer a clone : int skb_cloned (struct sk_buff * skb); Is the buffer shared : int skb_shared (struct sk_buff * skb); Make a copy of a shared buffer : struct sk_buff * skb_unshare (struct sk_buff * skb, int pri); struct sk_buff * skb_peek (struct sk_buff_head * list_); Get queue length : __u32 skb_queue_len (struct sk_buff_head * list_); Queue a buffer at the list head : void __skb_queue_head (struct sk_buff_head * list, struct sk_buff * newsk); void skb_queue_head (struct sk_buff_head * list, struct sk_buff * newsk); Queue a buffer at the list tail : void __skb_queue_tail (struct sk_buff_head * list, struct sk_buff * newsk); void skb_queue_tail (struct sk_buff_head * list, struct sk_buff * newsk); Remove from the head of the queue : struct sk_buff * __skb_dequeue (struct sk_buff_head * list); struct sk_buff * skb_dequeue (struct sk_buff_head * list);

54. Primitives réseau du kernel 2/6 Insert a buffer : void skb_insert (struct sk_buff * old, struct sk_buff * newsk); Append a buffer : void skb_append (struct sk_buff * old, struct sk_buff * newsk); Remove a buffer from a list : void skb_unlink (struct sk_buff * skb); Remove from the tail of the queue : struct sk_buff * __skb_dequeue_tail (struct sk_buff_head * list); Remove from the head of the queue : struct sk_buff * skb_dequeue_tail (struct sk_buff_head * list); Add data to a buffer : unsigned char * skb_put (struct sk_buff * skb, unsigned int len); Add data to the start of a buffer : unsigned char * skb_push (struct sk_buff * skb, unsigned int len); Remove data from the start of a buffer : unsigned char * skb_pull (struct sk_buff * skb, unsigned int len); Bytes at buffer head : int skb_headroom (const struct sk_buff * skb); Bytes at buffer end : int skb_tailroom (const struct sk_buff * skb); Adjust headroom : void skb_reserve (struct sk_buff * skb, unsigned int len); Remove end from a buffer : void skb_trim (struct sk_buff * skb, unsigned int len);

55. Orphan a buffer : void skb_orphan (struct sk_buff * skb); Empty a list : void skb_queue_purge (struct sk_buff_head * list); void __skb_queue_purge (struct sk_buff_head * list); Allocate an skbuff for sending : struct sk_buff * dev_alloc_skb (unsigned int length); Copy a buffer if need be : struct sk_buff * skb_cow (struct sk_buff * skb, unsigned int headroom); Private function : void skb_over_panic (struct sk_buff * skb, int sz, void * here); void skb_under_panic (struct sk_buff * skb, int sz, void * here); void __kfree_skb (struct sk_buff * skb); Allocate a network buffer : struct sk_buff * alloc_skb (unsigned int size, int gfp_mask); Duplicate an sk_buff : struct sk_buff * skb_clone (struct sk_buff * skb, int gfp_mask); Copy an sk_buff : struct sk_buff * skb_copy (const struct sk_buff * skb, int gfp_mask); Copy and expand sk_buff : struct sk_buff * skb_copy_expand (const struct sk_buff * skb, int newheadroom, int newtailroom, int gfp_mask); Test if a device exists : int dev_get (const char * name); Primitives réseau du kernel 3/6

56. Primitives réseau du kernel 4/6 Run a filter on a socket : int sk_run_filter (struct sk_buff * skb, struct sock_filter * filter, int flen); Register ethernet device : struct net_device * init_etherdev (struct net_device * dev, int sizeof_priv ); Add packet handler : void dev_add_pack (struct packet_type * pt); Remove packet handler : void dev_remove_pack (struct packet_type * pt); Find a device by its name : struct net_device * __dev_get_by_name (const char * name); struct net_device * dev_get_by_name (const char * name); Find a device by its ifindex : struct net_device * __dev_get_by_index (int ifindex); struct net_device * dev_get_by_index (int ifindex); Allocate a name for a device : int dev_alloc_name (struct net_device * dev, const char * name); Allocate a network device and name : struct net_device * dev_alloc (const char * name, int * err); Device changes state : void netdev_state_change (struct net_device * dev); Load a network module : void dev_load (const char * name); Prepare an interface for use : int dev_open (struct net_device * dev);

57. Primitives réseau du kernel 5/6 Shutdown an interface : int dev_close (struct net_device * dev); Register a network notifier block : int register_netdevice_notifier (struct notifier_block * nb); Unregister a network notifier block : int unregister_netdevice_notifier (struct notifier_block * nb); Transmit a buffer : int dev_queue_xmit (struct sk_buff * skb); Post buffer to the network code : void netif_rx (struct sk_buff * skb); void net_call_rx_atomic (void (*fn) (void)); Register a SIOCGIF handler : int register_gifconf (unsigned int family, gifconf_func_t * gifconf); Set up master/slave pair : int netdev_set_master (struct net_device * slave, struct net_device *master); Update promiscuity count on a device : void dev_set_promiscuity (struct net_device * dev, int inc); Update allmulti count on a device : void dev_set_allmulti (struct net_device * dev, int inc); Network device ioctl : int dev_ioctl (unsigned int cmd, void * arg); Allocate an ifindex : int dev_new_index ( void);

58. Primitives réseau du kernel 6/6 Register a network device : int register_netdevice (struct net_device * dev); Complete unregistration : int netdev_finish_unregister (struct net_device * dev); Remove device from the kernel : int unregister_netdevice (struct net_device * dev);

59. LES SOCKETS BSD

60. Les sockets BSD 1/4 : introduction L'utilisation des primitives réseau ne se fait pas directement mais via une API disponible en userspace   http://www-adele.imag.fr/users/Didier.Donsez/cours/socketunix.pdf

63. Les sockets BSD 4/4 Vue synthétique des couches montrant la localisation de l'API des sockets BSD   http://docs.huihoo.com/linux/kernel/a2/index.html

65. Administration réseau ifconfig : permet de configurer les interfaces réseau résidentes dans le noyau Ex: sudo ifconfig eth0:1 192.168.5.96 netmask 255.255.255.0 /sbin/ifconfig eth0 down ifconfig eth0 inet6 add 2001:6ff:10:1::1000/64 route : permet la gestion de la table de routage Ex : route add default gw 192.168.0.1 netmask 0.0.0.0 route -A inet6 add default gw 2001:6ff:10:1::ffff ip (ou iproute2) : permet un gestion précise du réseau Ex : ip addr add 192.168.0.2/24 dev eth0 brodcast 192.168.0.255 ip addr ls ip link set dev eth0 up ip -6 addr add 2001:6ff:10:1::1000/64 dev eth0 ip -6 route add default via 2001:6ff:10:1::ffff iwconfig : permet la gestion des interfaces sans fil. ipsysctl : permet la gestion du procfs /proc/sys/net TCP tuning guide : http://www-didc.lbl.gov/TCP-tuning/TCP-tuning.html

66. /PROC $ ls /proc/sys/net/ipv4 conf/ ip_autoconfig tcp_abc tcp_low_latency Etc … $ ls /proc/sys/net/ipv4/route error_burst gc_elasticity gc_min_interval_ms x_delay min_delay redirect_load Etc …  http://linuxgazette.net/issue77/lechnyr.html $ echo &quot;0&quot; > /proc/sys/net/ipv4/conf/all/accept_redirects Listing des paramètres disponible dans le RAMFS du KERNEL : Affichage et modifications des paramètres : $ cat /proc/sys/net/ipv4/ip_forward 1 PROCFS est un RAMFS géré par le noyau. C'est un lien entre le monde user et le monde kernel.  http://mirrors.deepspace6.net/Linux+IPv6-HOWTO-fr/proc-net.html

67. SUPPORT D'IPV6

70. IPv6 : 3/3 Test du support d'IPv6 : test -f /proc/net/if_inet6 && echo &quot;Support IPv6 available.&quot; Test si IPv6 est activé : lsmod |grep -w 'ipv6' && echo &quot;IPv6 enabled&quot; Résumé : http://www.bieringer.de/linux/IPv6/status/IPv6+Linux-status-distributions.html Guide : http://deepspace6.net/sections/docs.html IPv6 théorie et pratique : http://livre.point6.net/index.php/Accueil La souche IPv6 a été intégrée officiellement au noyau depuis les versions 2.2, mais ces noyaux étaient incomplets et non conformes aux RFC. Les noyaux 2.4 sont plus corrects, mais eux aussi présentent quelques lacunes. Les noyaux 2.6 sont donc préférables ; ils intègrent un partie des développements du projet japonais USAGI, en particulier la sécurité (IPsec). Il faut aussi un noyau compilé avec l'option IPv6 (dans le noyau ou en module). Ce type de noyau est en général disponible dans toutes les distributions (au moins comme paquetage optionnel). Les applications, quand à elles, doivent utiliser une librairie C supportant IPv6. La GNU Libc 2 intègre correctement le support IPv6 à partir de la version 2.2 de la Glibc. Aussi, il est important d'utiliser une distribution Linux qui réponde à ces critères. Aujourd'hui la pile réseau est complètement opérationnelle avec IPv6.

71. Lectures de référence

72. Livres de référence sur TCP-IP  http://www.kohala.com/start/  http://www.uic.rsu.ru/doc/inet/tcp_stevens/ TCP/IP illustré – Volume 1 Editeur : Vuibert Édition : Nouv. éd (28 septembre 1998) Langue : Français ISBN-10: 2711786390 ISBN-13: 978-2711786398 TCP/IP Illustrated, Volume 3: TCP for Transactions, HTTP, NNTP, and the UNIX Domain Protocols (Hardcover) Hardcover: 328 pages Publisher: Addison-Wesley Professional (January 29, 1996) Language: English ISBN-10: 0201634953 ISBN-13: 978-0201634952 Product Dimensions: 9.4 x 7.4 x 1 inches TCP/IP Illustrated, Volume 2: The Implementation (Addison-Wesley Professional Computing Series) (Hardcover) Hardcover: 1200 pages Publisher: Addison-Wesley Professional (February 10, 1995) Language: English ISBN-10: 020163354X ISBN-13: 978-0201633542 Product Dimensions: 9.3 x 7.7 x 1.9 inches

73. Liens 1/2 GNU Linux DDK : http://www.kroah.com/log/2006/05/24/#ddk Linux Device Drivers, Third Edition - Network Drivers : http://lwn.net/images/pdf/LDD3/ch17.pdf Ipsysctl tutorial : http://ipsysctl-tutorial.frozentux.net/ipsysctl-tutorial.html Linux IP Networking : http://www.cs.unh.edu/cnrg/gherrin/linux-net.html UNIX IP Stack Tuning Guide : http://www.cymru.com/Documents/ip-stack-tuning.html Performance Analysis of the TCP/IP Stack of Linux Kernel : http://user.informatik.uni-goettingen.de/~kperf/gaug-ifi-tb-2005-03.pdf Linux IP Masquerade mini HOWTO : http://www.ibiblio.org/pub/Linux/docs/HOWTO/translations/fr/pdf/IP-Masquerade-HOWTO.pdf Pont + pare-feu + DSL Mini-HOWTO : http://www.ibiblio.org/pub/Linux/docs/HOWTO/translations/fr/pdf/Bridge+Firewall+DSL.pdf Mini How-To sur la configuration de l’aliasing IP sous Linux : http://www.ibiblio.org/pub/Linux/docs/HOWTO/translations/fr/pdf/IP-Alias.pdf Linux Network Administrators Guide : http://tldp.org/LDP/nag2/nag2.pdf The Linux Networking Overview HOWTO : http://www.ibiblio.org/pub/Linux/docs/HOWTO/other-formats/pdf/Networking-Overview-HOWTO.pdf TCP/IP Stack Hardening : http://www.cromwell-intl.com/security/security-stack-hardening.html Voyage au centre de la pile TCP/IP de Linux : http://asyd.net/docs/kernel/tcpip-stack.html A Measurement Study of the Linux TCP/IP Stack Performance and Scalability on SMP systems : http://www.cse.iitb.ac.in/~varsha/allpapers/mypapers/comswarepaper.pdf Berkeley sockets : http://en.wikipedia.org/wiki/Berkeley_sockets Linux TCP/IP Stack : http://www.cs.odu.edu/~csi/tcpipstack.ppt IP & Ethernet Interfaces : http://www.beyondlogic.org/etherip/ip.htm Implementation of TCP/IP in Linux : http://netweb.usc.edu/~rsinha/docs/tcp-ip.ppt Conception du sous-système réseau de linux : http://lacl.univ-paris12.fr/cegielski/reseau.html

74. Liens 2/2 Serial Line IP Implementation for Linux Kernel TCP/IP Stack : http://www.cse.iitb.ac.in/~bestin/pdfs/slip.pdf HOWTO du routage avancé et du contrôle de trafic sous Linux : http://www.ibiblio.org/pub/Linux/docs/HOWTO/translations/fr/pdf/lartc.pdf Linux NAT HOWTO : http://www.linux-france.org/prj/inetdoc/guides/NAT-HOWTO/ Linux Packet Filtering HOWTO : http://www.linux-france.org/prj/inetdoc/guides/packet-filtering-HOWTO/ Linux inetdoc : http://www.linux-france.org/prj/ Linux IPv6 HOWTO : http://cvs.tldp.org/go.to/LDP/LDP/users/Peter-Bieringer/Linux+IPv6-HOWTO.fr.pdf Nisnet (network emulator) : http://www-x.antd.nist.gov/nistnet/ TCPStackPerformance : http://www.gelato.unsw.edu.au/IA64wiki/TCPStackPerformance Anatomy of the Linux networking stack : http://www.ibm.com/developerworks/linux/library/l-linux-networking-stack/ Guide pratique du multicast sur les réseaux TCP/IP : http://www.ibiblio.org/pub/Linux/docs/HOWTO/translations/fr/pdf/Multicast-HOWTO.pdf Historique de la stack IP : http://www.linuxfranch-county.org/docs/guideLLLinux/implementation_reseau_5-2.pdf Fonctions réseau du noyau Linux : http://www.linux-france.org/prj/inetdoc/telechargement/interco.noyau.pdf Understanding Linux Network Internals : http://book.chinaunix.net/special/ebook/oreilly/Understanding_Linux_Network_Internals/ Algorithmic Complexity Attacks and the Linux Networking Code : http://www.enyo.de/fw/security/notes/linux-dst-cache-dos.html Linux Network Stack Walkthrough : http://gicl.cs.drexel.edu/people/sevy/network/Linux_network_stack_walkthrough.html Data Link Layer : http://lion.cs.uiuc.edu/courses/cs498hou_spring05/lectures/lecture8.pdf skb - Linux network buffers : http://ftp.gnumonks.org/pub/doc/skb-doc.html

75. MERCI DE VOTRE ATTENTION DES QUESTIONS ?