La plupart des distributions Linux et des UNIX utilisent couramment les vénérables commandes "arp", "ifconfig" et "route". Bien que ces outils fonctionnent, ils montrent quelques comportements inattendus avec les noyaux Linux des séries 2.2 et plus. Par exemple, les tunnels GRE font partie intégrante du routage de nos jours, mais ils nécessitent des outils complètement différents.
Avec iproute2, les tunnels font partie intégrante des outils.
Les noyaux Linux des séries 2.2 et plus ont un sous-système réseau complètement réécrit. Ce nouveau codage de la partie réseau apporte à Linux des performances et des fonctionnalités qui n'ont pratiquement pas d'équivalent dans les autres systèmes d'exploitation. En fait, le nouveau logiciel de filtrage, routage et de classification possède plus de fonctionnalités que les logiciels fournis sur beaucoup de routeurs dédiés, de pare-feux et de produits de mise en forme (shaping) du trafic.
Dans les systèmes d'exploitation existants, au fur et à mesure que de nouveaux concepts réseau apparaissaient, les développeurs sont parvenus à les greffer sur les structures existantes. Ce travail constant d'empilage de couches a conduit à des codes réseau aux comportements étranges, un peu comme les langues humaines. Dans le passé, Linux émulait le mode de fonctionnement de SunOS, ce qui n'était pas l'idéal.
La nouvelle structure d'iproute2 a permis de formuler clairement des fonctionnalités impossibles à implanter dans le sous-système réseau précédent.
Linux possède un système sophistiqué d'allocation de bande passante appelé Contrôle de trafic (Traffic Control). Ce système supporte différentes méthodes pour classer, ranger par ordre de priorité, partager et limiter le trafic entrant et sortant.
Nous commencerons par un petit tour d'horizon des possibilités d'iproute2.
Vous devez être sûr que vous avez installé les outils utilisateur
(NdT : userland tools, par opposition à la partie "noyau" d'iproute2).
Le paquet concerné s'appelle "iproute" sur RedHat et Debian.
Autrement, il peut être trouvé à
ftp://ftp.inr.ac.ru/ip-routing/iproute2-2.2.4-now-ss??????.tar.gz.
Certains éléments d'iproute vous imposent l'activation de certaines
options du noyau.
FIXME: Nous devrions mentionner iproute2-current.tar.gz qui est toujours la dernière version.
Cela peut vous paraître surprenant, mais iproute2 est déjà configuré !
Les commandes courantes ifconfig et route utilisent
déjà les appels système avancés d'iproute2, mais essentiellement avec
les options par défaut (c'est-à-dire ennuyeuses).
L'outil ip est central, et nous allons lui demander de nous montrer
les interfaces.
ip nous montre nos liens
[ahu@home ahu]$ ip link list
1: lo: <LOOPBACK,UP> mtu 3924 qdisc noqueue
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: dummy: <BROADCAST,NOARP> mtu 1500 qdisc noop
link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
3: eth0: <BROADCAST,MULTICAST,PROMISC,UP> mtu 1400 qdisc pfifo_fast qlen 100
link/ether 48:54:e8:2a:47:16 brd ff:ff:ff:ff:ff:ff
4: eth1: <BROADCAST,MULTICAST,PROMISC,UP> mtu 1500 qdisc pfifo_fast qlen 100
link/ether 00:e0:4c:39:24:78 brd ff:ff:ff:ff:ff:ff
3764: ppp0: <POINTOPOINT,MULTICAST,NOARP,UP> mtu 1492 qdisc pfifo_fast qlen 10
link/ppp
La sortie peut varier, mais voici ce qui est affiché pour mon routeur NAT (NdT : translation d'adresse) chez moi. J'expliquerai seulement une partie de la sortie, dans la mesure où tout n'est pas directement pertinent.
La première interface que nous voyons est l'interface loopback. Bien que votre ordinateur puisse fonctionner sans, je vous le déconseille. La taille de MTU (unité maximum de transmission) est de 3924 octets, et loopback n'est pas supposé être mis en file d'attente, ce qui prend tout son sens dans la mesure où cette interface est le fruit de l'imagination de votre noyau.
Je vais passer sur l'interface dummy pour l'instant, et il se peut qu'elle ne soit pas présente sur votre ordinateur. Il y a ensuite mes deux interfaces réseau, l'une du côté de mon modem câble, l'autre servant mon segment ethernet à la maison. De plus, nous voyons une interface ppp0.
Notons l'absence d'adresses IP. Iproute déconnecte les concepts de "liens" et "d'adresses IP". Avec l'IP aliasing, le concept de l'adresse IP canonique est devenu, de toute façon, sans signification.
ip nous montre bien, cependant, l'adresse MAC, l'identifiant
matériel de nos interfaces ethernet.
ip nous montre nos adresses IP
[ahu@home ahu]$ ip address show
1: lo: <LOOPBACK,UP> mtu 3924 qdisc noqueue
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 brd 127.255.255.255 scope host lo
2: dummy: <BROADCAST,NOARP> mtu 1500 qdisc noop
link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
3: eth0: <BROADCAST,MULTICAST,PROMISC,UP> mtu 1400 qdisc pfifo_fast qlen 100
link/ether 48:54:e8:2a:47:16 brd ff:ff:ff:ff:ff:ff
inet 10.0.0.1/8 brd 10.255.255.255 scope global eth0
4: eth1: <BROADCAST,MULTICAST,PROMISC,UP> mtu 1500 qdisc pfifo_fast qlen 100
link/ether 00:e0:4c:39:24:78 brd ff:ff:ff:ff:ff:ff
3764: ppp0: <POINTOPOINT,MULTICAST,NOARP,UP> mtu 1492 qdisc pfifo_fast qlen 10
link/ppp
inet 212.64.94.251 peer 212.64.94.1/32 scope global ppp0
Cela contient plus d'informations : ip montre toutes nos adresses, et à quelles cartes elles appartiennent. "inet" désigne Internet. Il y a beaucoup d'autres familles d'adresses, mais elles ne nous concernent pas pour le moment.
Examinons eth0 de plus près. Il est dit qu'il est relié à l'adresse internet "10.0.0.1/8". Qu'est-ce que cela signifie ? Le /8 désigne le nombre de bits réservés à l'adresse réseau. Il y a 32 bits, donc il reste 24 bits pour désigner une partie de notre réseau. Les 8 premiers bits de 10.0.0.1 correspondent à 10.0.0.0, notre adresse réseau, et notre masque de sous-réseau est 255.0.0.0.
Les autres bits repèrent des machines directement connectées à cette interface, donc 10.250.3.13 est directement disponible sur eth0, comme l'est 10.0.0.1 dans notre exemple.
Avec ppp0, le même concept existe, bien que les nombres soient différents. Son adresse est 212.64.94.251, sans masque de sous-réseau. Cela signifie que vous avez une liaison point à point et que toutes les adresses, à l'exception de 212.64.94.251, sont distantes. Il y a cependant plus d'informations. En effet, on nous dit que de l'autre côté du lien, il n'y a encore qu'une seule adresse, 212.64.94.1. Le /32 nous précise qu'il n'y a pas de "bits réseau".
Il est absolument vital que vous compreniez ces concepts. Référez-vous à la documentation mentionnée au début de cet HOWTO si vous avez des doutes.
Vous pouvez aussi noter "qdisc", qui désigne la "Queueing Discipline" (gestion de la mise en file d'attente). Cela deviendra vital plus tard.
ip nous montre nos routesNous savons maintenant comment trouver les adresses 10.x.y.z, et nous sommes capables d'atteindre 212.64.94.1. Cela n'est cependant pas suffisant, et nous avons besoin d'instructions pour atteindre le monde. L'Internet est disponible via notre connexion ppp, et il se trouve que 212.64.94.1 est prêt à propager nos paquets à travers le monde, et à nous renvoyer le résultat.
[ahu@home ahu]$ ip route show
212.64.94.1 dev ppp0 proto kernel scope link src 212.64.94.251
10.0.0.0/8 dev eth0 proto kernel scope link src 10.0.0.1
127.0.0.0/8 dev lo scope link
default via 212.64.94.1 dev ppp0
Cela se comprend de soi-même. Les 4 premières lignes
donnent explicitement ce qui était sous-entendu par ip address show, la dernière ligne nous indiquant que le reste du monde peut être
trouvé via 212.64.94.1, notre passerelle par défaut. Nous pouvous voir que
c'est une passerelle à cause du mot "via", qui nous indique que nous avons
besoin d'envoyer les paquets vers 212.64.94.1, et que c'est elle qui
se chargera de tout.
En référence, voici ce que l'ancien utilitaire "route" nous propose :
[ahu@home ahu]$ route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use
Iface
212.64.94.1 0.0.0.0 255.255.255.255 UH 0 0 0 ppp0
10.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 eth0
127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo
0.0.0.0 212.64.94.1 0.0.0.0 UG 0 0 0 ppp0
ARP est le Protocole de Résolution d'Adresse (Address Resolution Protocol). Il est décrit dans le RFC 826. ARP est utilisé par une machine d'un réseau local pour retrouver l'adresse matérielle (la localisation) d'une autre machine sur le même réseau. Les machines sur Internet sont généralement connues par leur nom auquel correspond une adresse IP. C'est ainsi qu'une machine sur le réseau foo.com est capable de communiquer avec une autre machine qui est sur le réseau bar.net. Une adresse IP, cependant, ne peut pas vous indiquer la localisation physique de la machine. C'est ici que le protocole ARP entre en jeu.
Prenons un exemple très simple. Supposons que j'aie un réseau composé de plusieurs machines, dont la machine "foo" d'adresse IP 10.0.0.1 et la machine "bar" qui a l'adresse IP 10.0.0.2. Maintenant, foo veut envoyer un "ping" vers bar pour voir s'il est actif, mais foo n'a aucune indication sur la localisation de bar. Donc, si foo décide d'envoyer un "ping" vers bar, il a besoin d'envoyer une requête ARP. Cette requête ARP est une façon pour foo de crier sur le réseau "Bar (10.0.0.2) ! Où es-tu ?". Par conséquent, toutes les machines sur le réseau entendront foo crier, mais seul bar (10.0.0.2) répondra. Bar enverra une réponse ARP directement à foo ; ce qui revient à dire : "Foo (10.0.0.1) ! je suis ici, à l'adresse 00:60:94:E:08:12". Après cette simple transaction utilisée pour localiser son ami sur le réseau, foo est capable de communiquer avec bar jusqu'à ce qu'il (le cache ARP de foo) oublie où bar est situé.
Maintenant, voyons comment cela fonctionne. Vous pouvez consulter votre cache (table) arp (neighbor) comme ceci :
[root@espa041 /home/src/iputils]# ip neigh show
9.3.76.42 dev eth0 lladdr 00:60:08:3f:e9:f9 nud reachable
9.3.76.1 dev eth0 lladdr 00:06:29:21:73:c8 nud reachable
Comme vous pouvez le voir, ma machine espa041 (9.3.76.41) sait où trouver espa042 (9.3.76.42) et espagate (9.3.76.1). Maintenant, ajoutons une autre machine dans le cache arp.
[root@espa041 /home/paulsch/.gnome-desktop]# ping -c 1 espa043
PING espa043.austin.ibm.com (9.3.76.43) from 9.3.76.41 : 56(84) bytes of data.
64 bytes from 9.3.76.43: icmp_seq=0 ttl=255 time=0.9 ms
--- espa043.austin.ibm.com ping statistics ---
1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max = 0.9/0.9/0.9 ms
[root@espa041 /home/src/iputils]# ip neigh show
9.3.76.43 dev eth0 lladdr 00:06:29:21:80:20 nud reachable
9.3.76.42 dev eth0 lladdr 00:60:08:3f:e9:f9 nud reachable
9.3.76.1 dev eth0 lladdr 00:06:29:21:73:c8 nud reachable
Par conséquent, lorsque espa041 a essayé de contacter espa043, l'adresse matérielle de espa043 (sa localisation) a alors été ajoutée dans le cache ARP. Donc, tant que la durée de vie de l'entrée correspondant à espa043 dans le cache ARP n'est pas dépassée, espa041 sait localiser espa043 et n'a plus besoin d'envoyer de requête ARP.
Maintenant, effaçons espa043 de notre cache ARP.
[root@espa041 /home/src/iputils]# ip neigh delete 9.3.76.43 dev eth0
[root@espa041 /home/src/iputils]# ip neigh show
9.3.76.43 dev eth0 nud failed
9.3.76.42 dev eth0 lladdr 00:60:08:3f:e9:f9 nud reachable
9.3.76.1 dev eth0 lladdr 00:06:29:21:73:c8 nud stale
Maintenant, espa041 a à nouveau oublié la localisation d'espa043 et aura besoin d'envoyer une autre requête ARP la prochaine fois qu'il voudra communiquer avec lui. Vous pouvez aussi voir ci-dessus que l'état d'espagate (9.3.76.1) est passé en "stale". Cela signifie que la localisation connue est encore valide, mais qu'elle devra être confirmée à la première transaction avec cette machine.