HOWTO du routage avancé et du contrôle de trafic sous Linux

La table de routage principale est maintenant configurée. C'est une bonne idée de router les éléments à destination d'un voisin direct à travers l'interface connectée à ce voisin. Notez les arguments "src" qui assurent que la bonne adresse IP source sera choisie.

ip route add $P1_NET dev $IF1 src $IP1
ip route add $P2_NET dev $IF2 src $IP2

ip route add default via $P1

ip rule add from $IP1 table T1
ip rule add from $IP2 table T2

	Avertissement
	Notes d'un lecteur : si $P0_NET est le réseau local et $IF0 est son interface, alors les entrées suivantes sont désirables : ip route add $P0_NET dev $IF0 table T1 ip route add $P2_NET dev $IF2 table T1 ip route add 127.0.0.0/8 dev lo table T1 ip route add $P0_NET dev $IF0 table T2 ip route add $P1_NET dev $IF1 table T2 ip route add 127.0.0.0/8 dev lo table T2

Il est à noter que la balance de charge ne sera pas parfaite dans la mesure où elle est basée sur les routes et que celles-ci sont mises dans des caches. Ceci signifie que les routes vers les sites les plus souvent utilisés passeront toujours par le même fournisseur d'accès.

iptables -t mangle -A PREROUTING -i eth0 -j IMQ --todev 0

ip link set imq0 up

Les cibles iptables IMQ sont valides dans les chaînes PREROUTING et POSTROUTING de la table mangle. La syntaxe est la suivante :

IMQ [ --todev n ]	n : numéro du périphérique imq

Notez que le trafic n'est pas mis en file d'attente quand la cible est activée, mais après. La localisation exacte de l'entrée du trafic dans le périphérique imq dépend de la direction de ce trafic (entrant/sortant). Ces entrées sont les points d'accroche prédéfinis de netfilter et utilisés par iptables :

enum nf_ip_hook_priorities {
        NF_IP_PRI_FIRST = INT_MIN,
        NF_IP_PRI_CONNTRACK = -200,
        NF_IP_PRI_MANGLE = -150,
        NF_IP_PRI_NAT_DST = -100,
        NF_IP_PRI_FILTER = 0,
        NF_IP_PRI_NAT_SRC = 100,
        NF_IP_PRI_LAST = INT_MAX,
};

Pour le trafic entrant, imq se déclare avec la priorité NF_IP_PRI_MANGLE + 1, ce qui signifie que les paquets entrent dans le périphérique imq juste après la chaine PREROUTING de la table mangle.

Pour le trafic sortant, imq utilise NF_IP_PRI_LAST qui honore le fait que les paquets rejetés par la table filter n'occuperont pas de bande passante.

Utilisez ceci pour déterminer la présence du bit ACK sur les paquets d'une longueur inférieure à 64 octets :

## Vérifie la présence d'un ACK,
## protocol IP 6,
## longueur de l'en-tête IP 0x5(mots de 32 bits),
## longueur total IP 0x34 (ACK + 12 octets d'options TCP)
## TCP ack actif (bit 5, offset 33)
# tc filter add dev ppp14 parent 1:0 protocol ip prio 10 u32 \
            match ip protocol 6 0xff \
            match u8 0x05 0x0f at 0 \
            match u16 0x0000 0xffc0 at 2 \
            match u8 0x10 0xff at 33 \
            flowid 1:3

Seuls les paquets TCP sans charge utile et avec le bit ACK positionné vérifieront cette règle. Ici, nous pouvons voir un exemple d'utilisation de deux sélecteurs, le résultat final étant un ET logique de leur résultat. Si nous jetons un coup d'oeil sur un schéma de l'en-tête TCP, nous pouvons voir que le bit ACK est le second bit (0x10) du 14ème octet de l'en-tête TCP (at nexthdr+13). Comme second sélecteur, si nous voulons nous compliquer la vie, nous pouvons écrire match u8 0x06 0xff at 9 à la place du sélecteur spécifique protocol tcp, puisque 6 est le numéro du protocole TCP, spécifié au 10ème octet de l'en-tête IP. D'un autre côté, dans cet exemple, nous ne pourrons pas utiliser de sélecteur spécifique pour la première correspondance, simplement parce qu'il n'y a pas de sélecteur spécifique pour désigner les bits TCP ACK.

Le filtre ci dessous est une version modifiée du filtre présenté au-dessus. La différence est qu'il ne vérifie pas la longueur de l'en-tête ip. Pourquoi ? Car le filtre au-dessus ne marche que sur les systèmes 32 bits.

tc filter add dev ppp14 parent 1:0 protocol ip prio 10 u32 \
      match ip protocol 6 0xff \
      match u8 0x10 0xff at nexthdr+13 \
      match u16 0x0000 0xffc0 at 2 \
      flowid 1:3

Nous allons maintenant expliquer comment le filtre TC_INDEX travaille, et comment il s'intègre dans tout cela. En outre, le filtre TC_INDEX peut être utilisé dans des configurations autres que celles incluant les services DS.

Avant tout, supposons que nous recevons un paquet marqué comme EF. Si vous lisez le RFC2598, vous verrez que DSCP recommande une valeur de 101110 pour le trafic EF. Cela signifie que le champ DS sera égal à 10111000 (rappelez- vous que les bits les moins significatifs de l'octet TOS ne sont pas utilisés dans DS) ou 0xb8 en notation hexadécimale.

              FILTRE
              TC INDEX
   +---+      +-------+    +---+-+    +------+                +-+    +-------+
   |   |      |       |    |   | |    |FILTRE|  +-+    +-+    | |    |       |
   |   |----->| MASK  | -> |   | | -> |HANDLE|->| |    | | -> | | -> |       |
   |   |  .   | =0xfc |    |   | |    |0x2E  |  | +----+ |    | |    |       |
   |   |  .   |       |    |   | |    +------+  +--------+    | |    |       |
   |   |  .   |       |    |   | |                            | |    |       |
-->|   |  .   | SHIFT |    |   | |                            | |    |       |-->
   |   |  .   | =2    |    |   | +----------------------------+ |    |       |
   |   |      |       |    |   |       CBQ 2:0                  |    |       |
   |   |      +-------+    +---+--------------------------------+    |       |
   |   |                                                             |       |
   |   +-------------------------------------------------------------+       |
   |                          DSMARK 1:0                                     |
   +-------------------------------------------------------------------------+

Le paquet arrive alors avec la valeur du champ DS configurée à 0xb8. Comme je l'ai expliqué auparavant, le gestionnaire de mise en file d'attente dsmark, identifié par 1:0 dans cet exemple, récupère le champ DS et l'enregistre dans la variable skb->tc_index. L'étape suivante consistera à associer un filtre à ce gestionnaire de mise en file d'attente (la seconde ligne dans cet exemple). Les opérations suivantes seront réalisées :

Valeur1 = skb->tc_index & MASK
Clé = Valeur1 >> SHIFT

Dans cet exemple, MASK=0xFC et SHIFT=2.

Valeur1 = 10111000 & 11111100 = 10111000
Clé = 10111000 >> 2 = 00101110 -> 0x2E en hexadécimal

La valeur retournée correspondra à un identificateur de filtre du gestionnaire de file d'attente interne (dans l'exemple, identifier par 2:0). Si un filtre avec cet identificateur (id) existe, les conditions de contrôle et de performance seront vérifiées (au cas où le filtre inclurait ceci) et l'identificateur de classe sera retourné (dans notre exemple, classid 2:1) et stocké dans la variable skb->tc_index.

Si aucun filtre avec cet identificateur n'est trouvé, le résultat dépendra de la déclaration de l'option fall_through. Si tel est le cas, la valeur Clé est retournée comme identificateur de classe. Si cela n'est pas le cas, une erreur est retournée et le traitement continue avec les filtres restant. Faites attention si vous utilisez l'option fall_through ; ceci ne peut être fait que si une relation existe entre les valeurs de la variable skb->tc_index et les identificateurs de classe.

Les derniers paramètres à commenter sont hash et pass_on. Le premier est relié à la taille de la table de hachage. Pass_on sera utilisé pour indiquer d'essayer le filtre suivant dans le cas où aucun identificateur de classe égal au résultat du filtre ne serait trouvé. L'action par défaut est fall_through (regarder la table suivante).

Finalement, regardons quelles sont les valeurs possibles pour la configuration de tous ces paramètres TCINDEX :

Nom TC                  Valeur          Défaut
-----------------------------------------------------------------
Hash                    1...0x10000     Dépendant de l'implémentation
Mask                    0...0xffff      0xffff
Shift                   0...15          0
Fall through / Pass_on  Flag            Fall_through
Classid                 Major:minor     Rien
Police                  .....           Rien

Ce type de filtre est très puissant. Il est nécessaire d'explorer toutes les possibilités. En outre, ce filtre n'est pas seulement utilisé dans les configurations DiffServ. Vous pouvez l'utiliser comme n'importe quel autre filtre.

Je vous recommande de regarder les exemples DiffServ inclus dans la distribution iproute2. Je vous promets que j'essaierai de compléter ce texte dès que possible. Tout ce que j'ai expliqué est le résultat de nombreux tests. Merci de me dire si je me suis trompé quelque part.

Pour un exemple inventé sur la façon dont le gestionnaire d'entrée peut être utilisé, voir le chapitre Recettes de cuisine.

Maintenant que nous avons fait ceci, nous avons éliminé totalement la file d'attente du flux descendant (sauf pour de courtes rafales de données), et obtenu la possibilité de gérer la file d'attente du flux montant avec toute la puissance Linux.

Il nous reste à nous assurer que le trafic interactif se retrouve au début de la file d'attente du flux montant. Pour être sûr que le flux montant ne va pas pénaliser le flux descendant, nous déplaçons également les paquets ACK au début de la file d'attente. C'est ce qui provoque normalement un énorme ralentissement quand du trafic de masse est généré dans les deux sens. Les paquets ACK du trafic descendant rentrent en concurrence avec le trafic montant et sont donc ralentis.

Si nous avons fait tout ceci, nous obtenons les mesures suivantes en utilisant l'excellente connexion ADSL de xs4all, en Hollande :

Temps de latence de base :
round-trip min/avg/max = 14.4/17.1/21.7 ms

Sans le conditionneur de trafic, lors d'un téléchargement vers l'aval :
round-trip min/avg/max = 560.9/573.6/586.4 ms

Sans le conditionneur de trafic, lors d'un téléchargement vers l'amont :
round-trip min/avg/max = 2041.4/2332.1/2427.6 ms

Avec le conditionneur, lors d'un téléchargement vers l'amont à 220kbit/s :
round-trip min/avg/max = 15.7/51.8/79.9 ms

Avec le conditionneur, lors d'un téléchargement vers l'aval à 850kbit/s :
round-trip min/avg/max = 20.4/46.9/74.0 ms

Lors d'un téléchargement vers l'amont, les téléchargements vers l'aval s'effectuent à environ
80 % de la vitesse maximale disponible et 90% pour les téléchargements vers
l'amont. Le temps de latence augmente alors jusqu'à 850 ms ; je n'ai pas encore
déterminé la raison de ce phénomène.

Ce que vous pouvez attendre de ce script dépend largement de votre vitesse de lien réelle. Quand vous téléchargez vers l'amont à pleine vitesse, il y aura toujours un paquet devant votre frappe de clavier. Ceci est la limite basse de votre temps de latence. Pour la calculer, divisez votre MTU par la vitesse du flux montant. Les valeurs classiques seront un peu plus élevées que ça. Diminuez votre MTU pour un meilleur effet !

Voici deux versions de ce script, une avec l'excellent HTB de Devik, et l'autre avec CBQ qui est présent dans chaque noyau Linux, contrairement à HTB. Les deux ont été testés et marchent correctement.

Si les deux dernières lignes conduisent à une erreur, mettez à jour l'outil tc avec la dernière version !

Si les deux dernières lignes conduisent à une erreur, mettez à jour l'outil tc avec la dernière version !

+-----------+
			| racine 1: |
			+-----------+
			     |
			+---------------------------------------+
			| classe 1:1                            |
			+---------------------------------------+
			  |      |      |      |      |      |      
			+----+ +----+ +----+ +----+ +----+ +----+
			|1:10| |1:11| |1:12| |1:13| |1:14| |1:15| 
			+----+ +----+ +----+ +----+ +----+ +----+ 
			

Tout d'abord, nous devons comprendre comment les paquets traversent les filtres avec iptables :

        +------------+                +---------+               +-------------+
Paquets-| PREROUTING |--- Décision----| FORWARD |-------+-------| POSTROUTING |- Paquets
entrant +------------+   de routage   +-­-------+       |       +-------------+  sortants  
                             |                          |
                        +-------+                    +--------+   
                        | INPUT |-- Processus locaux-| OUTPUT |
                        +-------+                    +--------+

Nous indiquons au noyau de faire de la traduction d'adresse NAT; les clients du réseau privé peuvent alors commencer à dialoguer avec l'extérieur.

			echo 1 > /proc/sys/net/ipv4/ip_forward
			iptables -t nat -A POSTROUTING -s 172.17.0.0/255.255.0.0 -o eth0 -j SNAT --to-source 212.170.21.172
			

			tc -s class show dev eth0
			

Vous pouvez commencer à marquer les paquets en ajoutant les règles dans la chaîne PREROUTING de la table mangle.

iptables -t mangle -A PREROUTING -p icmp -j MARK --set-mark 0x1
iptables -t mangle -A PREROUTING -p icmp -j RETURN

tc -s class show dev eth0

iptables -t mangle -A PREROUTING -m tos --tos Minimize-Delay -j MARK --set-mark 0x1
iptables -t mangle -A PREROUTING -m tos --tos Minimize-Delay -j RETURN
iptables -t mangle -A PREROUTING -m tos --tos Minimize-Cost -j MARK --set-mark 0x5
iptables -t mangle -A PREROUTING -m tos --tos Minimize-Cost -j RETURN
iptables -t mangle -A PREROUTING -m tos --tos Maximize-Throughput -j MARK --set-mark 0x6
iptables -t mangle -A PREROUTING -m tos --tos Maximize-Throughput -j RETURN

iptables -t mangle -A PREROUTING -p tcp -m tcp --sport 22 -j MARK --set-mark 0x1
iptables -t mangle -A PREROUTING -p tcp -m tcp --sport 22 -j RETURN

iptables -t mangle -I PREROUTING -p tcp -m tcp --tcp-flags SYN,RST,ACK SYN -j MARK --set-mark 0x1
iptables -t mangle -I PREROUTING -p tcp -m tcp --tcp-flags SYN,RST,ACK SYN -j RETURN

iptables -t mangle -A PREROUTING -j MARK --set-mark 0x6

C'est une bonne idée de faire de même avec la chaîne OUTPUT. Répétez ces commandes avec -A OUTPUT à la place de PREROUTING (s/PREROUTING/OUTPUT/). Le trafic généré localement (sur le routeur Linux) sera alors également classifié. Je termine la chaîne OUTPUT par -j MARK --set-mark 0x3 de tel sorte que le trafic local ait une priorité plus grande.

N'oubliez pas également d'activer l'option ip_forwarding ! Quand on convertit un vrai pont, il se peut que vous trouviez cette option désactivée dans la mesure où il n'y en a pas besoin pour un pont.

Une autre chose que vous devriez considérer lors de la conversion est que vous aurez besoin d'effacer le cache arp des ordinateurs du réseau. Le cache arp peut contenir d'anciennes adresses matérielles du pont qui ne sont plus correctes.

Sur un Cisco, ceci est réalisé en utilisant la commande 'clear arp-cache' et, sous linux, en utilisant 'arp -d ip.adresse'. Vous pouvez aussi attendre l'expiration manuelle du cache, ce qui peut être plutôt long.

Il se peut que vous découvriez également que votre réseau était mal configuré si vous avez/aviez l'habitude de spécifier les routes sans les masques de sous-réseau. Dans le passé, certaines versions de route pouvaient correctement deviner le masque ou, au contraire, se tromper sans pour autant vous le notifier. Quand vous faites du routage chirurgical comme décrit plus haut, il est *vital* que vous vérifiez vos masques de sous-réseau.

hostname omega
password xxx 
enable password xxx
!
! Interface's description.
!
!interface lo
! description test of desc.
!
interface eth1
multicast
!
! Static default route
!
ip route 0.0.0.0/0 212.170.21.129
!
log file /var/log/zebra/zebra.log

 			zebra=yes
 			ospfd=yes
 			

 			hostname omega
 			password xxx
 			enable password xxx
 			!
 			router ospf
 			  network 192.168.0.0/24 area 0
 			  network 172.17.0.0/16 area 1
 			!
 			! log stdout
 			log file /var/log/zebra/ospfd.log
 			

Nous pouvons également interagir avec zebra et ospfd en exécutant :

$ telnet localhost zebra
$ telnet localhost ospfd

 			root@atlantis:~# telnet localhost zebra
 			Trying 127.0.0.1...
 			Connected to atlantis.
 			Escape character is '^]'.
 
 			Hello, this is zebra (version 0.92a).
 			Copyright 1996-2001 Kunihiro Ishiguro.
 
 			User Access Verification
 
 			Password: 
 			atlantis> show ip route
 			Codes: K - kernel route, C - connected, S - static, R - RIP, O - OSPF,
 			       B - BGP, > - selected route, * - FIB route
 
 			K>* 0.0.0.0/0 via 192.168.0.1, eth1
 			C>* 127.0.0.0/8 is directly connected, lo
 			O   172.17.0.0/16 [110/10] is directly connected, eth0, 06:21:53
 			C>* 172.17.0.0/16 is directly connected, eth0
 			O   192.168.0.0/24 [110/10] is directly connected, eth1, 06:21:53
 			C>* 192.168.0.0/24 is directly connected, eth1
 			atlantis> show ip ospf border-routers
 			============ OSPF router routing table =============
			R    192.168.0.253         [10] area: (0.0.0.0), ABR
 						   via 192.168.0.253, eth1
 							 [10] area: (0.0.0.1), ABR
 						   via 172.17.0.2, eth0
 			

 			root@omega:~# ip route
 			212.170.21.128/26 dev eth0  proto kernel  scope link  src 212.170.21.172 
 			192.168.0.0/24 dev eth1  proto kernel  scope link  src 192.168.0.1 
 			172.17.0.0/16 via 192.168.0.2 dev eth1  proto zebra  metric 20 
 			default via 212.170.21.129 dev eth0  proto zebra 
 			root@omega:~# 
 			

Astuce : vous pouvez utiliser :

 			tcpdump -i eth1 ip[9] == 89
 			

OSPF possède de nombreux paramètres, spécialement pour les grands réseaux. Dans de prochains développements du HOWTO, nous montrerons des méthodes de réglages fins d'OSPF.