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-feu 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. Il devra également être noté que toutes
les versions de RedHat jusqu'à la version 6.2 incluse n'ont pas les
fonctionnalités du contrôle de trafic dans le noyau par défaut.
RedHat 7.2 contient tous les éléments par défaut.
Soyez également sûr que vous avez le support netlink, en
utilisant son propre noyau (NdT : compilé par vous). Iproute2 en a
besoin.
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 physiques, 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" signifie
Internet (IPv4). 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 routes
Nous 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
pouvons 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é (typiquement au bout
de 15 minutes sur Unix).
[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
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.
