Routage avancé et contrôle du trafic sous Linux

[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 : traduction 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.

[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 l'interface eth0 de plus près. Il est dit qu'elle est reliée à 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 ce HOWTO si vous avez des doutes.

Vous pouvez aussi noter qdisc, qui désigne la gestion de la mise en file d'attente (Queueing Discipline). Cela deviendra vital plus tard.

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 quatre 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

La première est de savoir comment router les réponses aux paquets entrants par un fournisseur particulier, disons le Fournisseur 1, vers ce même fournisseur.

Commençons par définir quelques symboles. $IF1 sera le nom de la première interface (if1 sur la figure au-dessus) et $IF2 le nom de la deuxième interface. $IP1 sera alors l'adresse IP associée à $IF1 et $IP2 sera l'adresse IP associée à $IF2. $P1 sera l'adresse IP de la passerelle du fournisseur d'accès 1 et $P2 sera l'adresse IP de la passerelle du fournisseur d'accès 2. Enfin, $P1_NET sera l'adresse réseau à l'intérieur duquel se situe $P1 et $P2_NET sera l'adresse réseau à l'intérieur duquel se situe $P2.

Deux tables de routage supplémentaires sont créées, par exemple T1 et T2. Celles-ci sont ajoutées dans /etc/iproute2/rt_tables. La configuration du routage dans ces tables s'effectue de la façon suivante :

ip route add $P1_NET dev $IF1 src $IP1 table T1
ip route add default via $P1 table T1
ip route add $P2_NET dev $IF2 src $IP2 table T2
ip route add default via $P2 table T2

Rien de vraiment spectaculaire. Une route est simplement positionnée vers la passerelle et une route par défaut via cette passerelle est mise en place, comme nous le ferions dans le cas d'un seul fournisseur d'accès. Ici, les routes sont placées dans des tables séparées, une par fournisseur d'accès. Il est à noter que la route vers le réseau suffit, dans la mesure où elle indique comment trouver n'importe quel hôte dans ce réseau, ce qui inclut la passerelle.

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

Indiquez maintenant votre préférence pour votre route par défaut :

ip route add default via $P1

Vous configurez ensuite les règles de routage. Celles-ci définissent la table qui sera vraiment choisie pour le routage. Il faut s'assurer que le routage s'effectue à travers une interface donnée si vous avez l'adresse source correspondante :

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

Cet ensemble de commandes vous assure que toutes les réponses au trafic entrant sur une interface particulière seront envoyées par cette interface.

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

Nous avons maintenant une configuration très basique. Elle marchera pour tous les processus exécutés sur le routeur lui-même, ainsi que pour le réseau local si celui-ci est masqué. Si ce n'est pas le cas, soit vous avez une plage d'adresses IP pour chaque fournisseur d'accès, soit vous masquez vers l'un des deux fournisseurs d'accès. Dans les deux cas, vous ajouterez des règles indiquant, en fonction de l'adresse IP de la machine du réseau local, vers quel fournisseur vous allez router.

La seconde question concerne la balance de charge du trafic sortant vers les deux fournisseurs d'accès. Ceci n'est pas vraiment très dur si vous avez déjà configuré l'accès séparé comme décrit ci-dessus.

Au lieu de choisir l'un des deux fournisseurs d'accès comme route par défaut, celle-ci peut être une route multichemin. Par défaut, le noyau répartira les routes vers les deux fournisseurs d'accès. Ceci est réalisé de la façon suivante (construit également sur l'exemple de la section de l'accès séparé) :

ip route add default scope global nexthop via $P1 dev $IF1 weight 1 \
nexthop via $P2 dev $IF2 weight 1

Ceci réalisera la balance des routes vers les deux fournisseurs. Les paramètres weight peuvent permettre de favoriser un fournisseur par rapport à un autre.

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.

De plus, si vous voulez vraiment mettre en œuvre ceci, vous devriez également aller consulter les mises à jour de Julien Anastasov à http://www.ssi.bg/~ja/#routes. Elles rendront le travail plus facile.

Dans un premier temps, intéressons-nous au tunnel IPv4 :

Disons que vous avez trois réseaux : deux réseaux internes A et B, et un réseau intermédiaire C (ou disons Internet).

Les caractéristiques du réseau A sont :

réseau 10.0.1.0
masque de sous-réseau 255.255.255.0
routeur  10.0.1.1

Le routeur a l'adresse 172.16.17.18 sur le réseau C. Appelons ce réseau neta.

Et pour le réseau B :

réseau 10.0.2.0
masque de sous-réseau 255.255.255.0
routeur  10.0.2.1

Le routeur a l'adresse 172.19.20.21 sur le réseau C. Appelons ce réseau netb.

En ce qui concerne le réseau C, nous supposerons qu'il transmettra n'importe quels paquets de A vers B et vice-versa. Comment et pourquoi, on s'en moque.

Sur le routeur du réseau A, nous faisons la chose suivante :

ip tunnel add netb mode gre remote 172.19.20.21 local 172.16.17.18 ttl 255
ip link set netb up
ip addr add 10.0.1.1 dev netb
ip route add 10.0.2.0/24 dev netb

Discutons un peu de cela. Sur la ligne 1, nous avons ajouté un périphérique tunnel, que nous avons appelé netb (ce qui est évident, dans la mesure où c'est là que nous voulons aller). De plus, nous lui avons dit d'utiliser le protocole GRE (mode gre), que l'adresse distante est 172.19.20.21 (le routeur de l'autre côté), que nos paquets « tunnelés » devront être générés à partir de 172.16.17.18 (ce qui autorise votre serveur à avoir plusieurs adresses IP sur le réseau C et ainsi vous permet de choisir laquelle sera utilisée pour votre tunnel) et que le champ TTL de vos paquets sera fixé à 255 (ttl 255).

La deuxième ligne active le périphérique.

Sur la troisième ligne, nous avons donné à cette nouvelle interface l'adresse 10.0.1.1. C'est bon pour de petits réseaux, mais quand vous commencez une exploitation minière (BEAUCOUP de tunnels !), vous pouvez utiliser une autre gamme d'adresses IP pour vos interfaces « tunnel » (dans cet exemple, vous pourriez utiliser 10.0.3.0).

Sur la quatrième ligne, nous positionnons une route pour le réseau B. Notez la notation différente pour le masque de sous-réseau. Si vous n'êtes pas familiarisé avec cette notation, voici comment ça marche : vous écrivez le masque de sous-réseau sous sa forme binaire, et vous comptez tous les 1. Si vous ne savez pas comment faire cela, rappelez-vous juste que 255.0.0.0 est /8, 255.255.0.0 est /16 et 255.255.255.0 est /24. Et 255.255.254.0 est /23, au cas où ça vous intéresserait.

Mais arrêtons ici, et continuons avec le routeur du réseau B.

ip tunnel add neta mode gre remote 172.16.17.18 local 172.19.20.21 ttl 255
ip link set neta up
ip addr add 10.0.2.1 dev neta
ip route add 10.0.1.0/24 dev neta

Et quand vous voudrez retirer le tunnel sur le routeur A :

ip link set netb down
ip tunnel del netb

Bien sûr, vous pouvez remplacer netb par neta pour le routeur B.

Voir la section 6 pour une courte description des adresses IPv6.

À propos des tunnels.

Supposons que vous ayez le réseau IPv6 suivant, et que vous vouliez le connecter à une dorsale IPv6 (6bone) ou à un ami.

Réseau 3ffe:406:5:1:5:a:2:1/96

Votre adresse IPv4 est 172.16.17.18, et le routeur 6bone a une adresse IPv4 172.22.23.24.

ip tunnel add sixbone mode sit remote 172.22.23.24 local 172.16.17.18 ttl 255
ip link set sixbone up
ip addr add 3ffe:406:5:1:5:a:2:1/96 dev sixbone
ip route add 3ffe::/15 dev sixbone

Voyons cela de plus près. Sur la première ligne, nous avons créé un périphérique tunnel appelé sixbone. Nous lui avons affecté le mode sit (qui est le tunnel IPv6 sur IPv4) et lui avons dit où l'on va (remote) et d'où l'on vient (local). TTL est configuré à son maximum : 255. Ensuite, nous avons rendu le périphérique actif (up). Puis, nous avons ajouté notre propre adresse réseau et configuré une route pour 3ffe::/15 à travers le tunnel.

Les tunnels GRE constituent actuellement le type de tunnel préféré. C'est un standard qui est largement adopté, même à l'extérieur de la communauté Linux, ce qui constitue une bonne raison de l'utiliser.

Comme expliqué avant, la gestion automatique des clés réalise beaucoup d'opérations pour nous. Spécifiquement, elle crée à la volée les Associations de Sécurité. Elle ne configure cependant pas la politique pour nous, ce qui est le fonctionnement attendu.

Donc, pour bénéficier de IKE, configurez une politique, mais ne fournissez aucune Association de Sécurité. Si le noyau découvre qu'il y a une politique IPSEC, mais pas d'Association de Sécurité, il va le notifier au démon IKE qui va chercher à en négocier une.

De nouveau, rappelons que la Politique de Sécurité spécifie CE QUE nous voulons tandis que l'Association de Sécurité décrit COMMENT nous le voulons. L'utilisation de la gestion automatique des clés nous permet de ne spécifier que ce que nous voulons.

Kame racoon possède un grand nombre d'options dont la plupart des valeurs par défaut sont correctes ; nous n'avons donc pas besoin de les modifier. Comme nous l'avons dit auparavant, l'opérateur doit définir une Politique de Sécurité, mais pas d'Associations de Sécurité. Nous laissons cette négociation au démon IKE.

Dans cet exemple, 10.0.0.1 et 10.0.0.216 sont encore une fois sur le point d'établir des communications sécurisées mais, cette fois, avec l'aide du démon racoon. Par souci de simplification, cette configuration utilisera des clés prépartagées, les redoutés 'secrets partagés'. Nous discuterons des certificats X.509 dans une section à part. Voir Section 7.2.3, « Gestion automatique des clés en utilisant les certificats X.509 ».

Nous allons à peu près rester fidèle à la configuration par défaut, qui est identique sur les deux hôtes :

path pre_shared_key "/usr/local/etc/racoon/psk.txt";

remote anonymous
{
        exchange_mode aggressive,main;
        doi ipsec_doi;
        situation identity_only;

        my_identifier address;

        lifetime time 2 min;   # sec,min,hour
        initial_contact on;
        proposal_check obey;    # obey, strict or claim

        proposal {
                encryption_algorithm 3des;
                hash_algorithm sha1;
                authentication_method pre_shared_key;
                dh_group 2 ;
        }
}
 
sainfo anonymous
{
        pfs_group 1;
        lifetime time 2 min;
        encryption_algorithm 3des ;
        authentication_algorithm hmac_sha1;
                compression_algorithm deflate ;
}

Beaucoup de paramètres. Je pense que l'on peut encore en supprimer pour se rapprocher de la configuration par défaut. Remarquons ici quelques éléments notables. Nous avons configuré deux sections « anonymous », ce qui convient pour tous les hôtes distants. Ceci va ainsi faciliter les configurations supplémentaires. Il n'est pas nécessaire d'avoir de sections spécifiques à une machine particulière, à moins que vous ne le vouliez vraiment.

De plus, la configuration précise que nous nous identifions grâce à notre adresse IP ('my_identifier address') et que nous pouvons faire du 3des, sha1 et que nous utiliserons une clé « prépartagée » se trouvant dans psk.txt.

Dans le fichier psk.txt, nous avons configuré deux entrées qui sont différentes suivant les hôtes. Sur 10.0.0.11 :

10.0.0.216       password2

Sur 10.0.0.216 :

10.0.0.11        password2

Soyez sûr que ces fichiers sont la propriété de root, et qu'ils ont le mode 0600. Dans le cas contraire, racoon ne pourra faire confiance à leur contenu. Notez que ces fichiers sont symétriques l'un de l'autre.

Nous sommes maintenant prêt à configurer notre politique qui est assez simple. Sur l'hôte 10.0.0.216 :

#!/sbin/setkey -f
flush;
spdflush;

spdadd 10.0.0.216 10.0.0.11 any -P out ipsec
        esp/transport//require;

spdadd 10.0.0.11 10.0.0.216 any -P in ipsec
        esp/transport//require;

Et sur 10.0.0.11 :

#!/sbin/setkey -f
flush;
spdflush;

spdadd 10.0.0.11 10.0.0.216 any -P out ipsec
        esp/transport//require;

spdadd 10.0.0.216 10.0.0.11 any -P in ipsec
        esp/transport//require;

Noter que ces politiques sont encore une fois symétriques.

Nous sommes maintenant prêt à lancer racoon ! Une fois lancé, au moment où nous essayons une connexion un telnet depuis 10.0.0.11 vers 10.0.0.216, ou l'inverse, racoon aura démarré la négociation :

12:18:44: INFO: isakmp.c:1689:isakmp_post_acquire(): IPsec-SA
  request for 10.0.0.11 queued due to no phase1 found.
12:18:44: INFO: isakmp.c:794:isakmp_ph1begin_i(): initiate new
  phase 1 negotiation: 10.0.0.216[500]<=>10.0.0.11[500]
12:18:44: INFO: isakmp.c:799:isakmp_ph1begin_i(): begin Aggressive mode.
12:18:44: INFO: vendorid.c:128:check_vendorid(): received Vendor ID: 
  KAME/racoon
12:18:44: NOTIFY: oakley.c:2037:oakley_skeyid(): couldn't find
  the proper pskey, try to get one by the peer's address.
12:18:44: INFO: isakmp.c:2417:log_ph1established(): ISAKMP-SA
  established 10.0.0.216[500]-10.0.0.11[500] spi:044d25dede78a4d1:ff01e5b4804f0680
12:18:45: INFO: isakmp.c:938:isakmp_ph2begin_i(): initiate new phase 2 
  negotiation: 10.0.0.216[0]<=>10.0.0.11[0]
12:18:45: INFO: pfkey.c:1106:pk_recvupdate(): IPsec-SA established: 
  ESP/Transport 10.0.0.11->10.0.0.216 spi=44556347(0x2a7e03b)
12:18:45: INFO: pfkey.c:1318:pk_recvadd(): IPsec-SA established:
  ESP/Transport 10.0.0.216->10.0.0.11 spi=15863890(0xf21052)

L'exécution de la commande setkey -D, qui nous montre les Associations de Sécurité, nous indique qu'elles sont en effet présentes :

10.0.0.216 10.0.0.11 
        esp mode=transport spi=224162611(0x0d5c7333) reqxml:id=0(0x00000000)
        E: 3des-cbc  5d421c1b d33b2a9f 4e9055e3 857db9fc 211d9c95 ebaead04
        A: hmac-sha1  c5537d66 f3c5d869 bd736ae2 08d22133 27f7aa99
        seq=0x00000000 replay=4 flags=0x00000000 state=mature 
        created: Nov 11 12:28:45 2002   current: Nov 11 12:29:16 2002
        diff: 31(s)     hard: 600(s)    soft: 480(s)
        last: Nov 11 12:29:12 2002      hard: 0(s)      soft: 0(s)
        current: 304(bytes)     hard: 0(bytes)  soft: 0(bytes)
        allocated: 3    hard: 0 soft: 0
        sadb_seq=1 pxml:id=17112 refcnt=0
10.0.0.11 10.0.0.216 
        esp mode=transport spi=165123736(0x09d79698) reqxml:id=0(0x00000000)
        E: 3des-cbc  d7af8466 acd4f14c 872c5443 ec45a719 d4b3fde1 8d239d6a
        A: hmac-sha1  41ccc388 4568ac49 19e4e024 628e240c 141ffe2f
        seq=0x00000000 replay=4 flags=0x00000000 state=mature 
        created: Nov 11 12:28:45 2002   current: Nov 11 12:29:16 2002
        diff: 31(s)     hard: 600(s)    soft: 480(s)
        last:                           hard: 0(s)      soft: 0(s)
        current: 231(bytes)     hard: 0(bytes)  soft: 0(bytes)
        allocated: 2    hard: 0 soft: 0
        sadb_seq=0 pxml:id=17112 refcnt=0

Nous avons les Politiques de Sécurité que nous avons nous-même configurées :

10.0.0.11[any] 10.0.0.216[any] tcp
        in ipsec
        esp/transport//require
        created:Nov 11 12:28:28 2002 lastused:Nov 11 12:29:12 2002
        lifetime:0(s) validtime:0(s)
        spxml:id=3616 seq=5 pxml:id=17134
        refcnt=3
10.0.0.216[any] 10.0.0.11[any] tcp
        out ipsec
        esp/transport//require
        created:Nov 11 12:28:28 2002 lastused:Nov 11 12:28:44 2002
        lifetime:0(s) validtime:0(s)
        spxml:id=3609 seq=4 pxml:id=17134
        refcnt=3

7-2-2-1. Problèmes et défauts connus▲

Comme nous l'avons dit avant, l'utilisation de secrets partagés est compliquée, car ils ne peuvent pas être facilement partagés et, une fois qu'ils le sont, ils ne sont plus secrets. Heureusement, nous avons la technologie d'encryptage asymétrique pour nous aider à résoudre ce problème.

Si chaque participant d'une liaison IPSEC crée une clé publique et privée, des communications sécurisées peuvent être mises en place par les deux parties en publiant leur clé publique et en configurant leur politique.

Créer une clé est relativement facile, bien que cela exige un peu de travail. Ce qui suit est basé sur l'outil 'openssl'.

7-2-3-1. Construire un certificat X.509 pour votre hôte▲

$ openssl req -new -nodes -newkey rsa:1024 -sha1 -keyform PEM -keyout \
  laptop.private -outform PEM -out request.pem

Country Name (2 letter code) [AU]:NL
State or Province Name (full name) [Some-State]:.
Locality Name (eg, city) []:Delft
Organization Name (eg, company) [Internet Widgits Pty Ltd]:Linux Advanced
Routing & Traffic Control
Organizational Unit Name (eg, section) []:laptop
Common Name (eg, YOUR name) []:bert hubert
Email Address []:ahu@ds9a.nl

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:

$ openssl x509 -req -in request.pem -signkey laptop.private -out \
  laptop.public
Signature ok
subject=/C=NL/L=Delft/O=Linux Advanced Routing & Traffic \
  Control/OU=laptop/CN=bert hubert/Email=ahu@ds9a.nl
Getting Private key

7-2-3-2. Configuration et lancement▲

path certificate "/usr/local/etc/racoon/certs";

remote 10.0.0.216
{
        exchange_mode aggressive,main;
        my_identifier asn1dn;
        peers_identifier asn1dn;

        certificate_type x509 "upstairs.public" "upstairs.private";

        peers_certfile "laptop.public";
        proposal {
                encryption_algorithm 3des;
                hash_algorithm sha1;
                authentication_method rsasig;
                dh_group 2 ;
        }
}

path certificate "/usr/local/etc/racoon/certs";

remote 10.0.0.11
{
        exchange_mode aggressive,main;
        my_identifier asn1dn;
        peers_identifier asn1dn;

        certificate_type x509 "laptop.public" "laptop.private";
 
        peers_certfile "upstairs.public";

        proposal {
                encryption_algorithm 3des;
                hash_algorithm sha1;
                authentication_method rsasig;
                dh_group 2 ;
        }
}

7-2-3-3. Comment configurer des tunnels sécurisés▲

$ openssl dgst upstairs.public 
MD5(upstairs.public)= 78a3bddafb4d681c1ca8ed4d23da4ff1

Andreas Jellinghaus <aj@dungeon.inka.de> rapporte : "win2k: cela marche. prépartage de clé et l'adresse ip pour l'authentification (je ne pense pas que Windows supporte fdqn ou userfdqn). Les certificats devraient également marcher, mais cela n'a pas été essayé.

Peter Bieringer rapporte :

Voici des résultats (seul le mode tunnel a été testé,
         auth=SHA1) :
 DES:     ok 
 3DES:    ok 
 AES-128: ok 
 AES-192: non supporté par CP VPN-1
 AES-256: ok 
 CAST* :  non supporté par le noyau Linux utilisé
 
 Version Testée : FP4 aka R54 aka w/AI

Plus d'informations ici.

Cette file d'attente, comme son nom l'indique : premier entré, premier sorti (First In First Out), signifie que les paquets ne subissent pas de traitements spéciaux. En fait, ce n'est pas tout à fait vrai. Cette file d'attente a trois « bandes ». À l'intérieur de chacune de ces bandes, des règles FIFO s'appliquent. Cependant, tant qu'il y a un paquet en attente dans la bande 0, la bande 1 ne sera pas traitée. Il en va de même pour la bande 1 et la bande 2.

Le noyau prend en compte la valeur du champ Type de Service des paquets et prend soin d'insérer dans la bande 0 les paquets ayant le bit « délai minimum » activé.

Ne pas confondre ce gestionnaire de mise en file d'attente sans classe avec celui basé sur des classes PRIO ! Bien qu'ils aient des comportements similaires, pfifo_fast ne possède pas de classe et vous ne pourrez pas y ajouter de nouveaux gestionnaires avec la commande tc.

9-2-1-1. Paramètres et usage▲

   0     1     2     3     4     5     6     7
+-----+-----+-----+-----+-----+-----+-----+-----+
|                 |                       |     |
|   PRECEDENCE    |          TOS          | MBZ |
|                 |                       |     |
+-----+-----+-----+-----+-----+-----+-----+-----+

Binaire Décimal   Signification
-----------------------------------------
1000    8         Minimise le Délai (Minimize delay) (md)
0100    4         Maximalise le Débit (Maximize throughput) (mt)
0010    2         Maximalise la Fiabilité (Maximize reliability) (mr)
0001    1         Minimalise le Coût Monétaire (Minimize monetary cost) (mmc)
0000    0         Service Normal

TOS     Bits  Signification                     Priorité Linux    Bande
------------------------------------------------------------------------
0x0     0     Service Normal                    0 Best Effort     1
0x2     1     Minimise le Coût Monétaire (mmc)  1 Filler          2
0x4     2     Maximalise la Fiabilité (mr)      0 Best Effort     1
0x6     3     mmc+mr                            0 Best Effort     1
0x8     4     Maximalise le Débit (mt)          2 Masse           2
0xa     5     mmc+mt                            2 Masse           2
0xc     6     mr+mt                             2 Masse           2
0xe     7     mmc+mr+mt                         2 Masse           2
0x10    8     Minimise le Délai (md)            6 Interactive     0
0x12    9     mmc+md                            6 Interactive     0
0x14    10    mr+md                             6 Interactive     0
0x16    11    mmc+mr+md                         6 Interactive     0
0x18    12    mt+md                             4 Int. Masse      1
0x1a    13    mmc+mt+md                         4 Int. Masse      1
0x1c    14    mr+mt+md                          4 Int. Masse      1
0x1e    15    mmc+mr+mt+md                      4 Int. Masse      1

1, 2, 2, 2, 1, 2, 0, 0 , 1, 1, 1, 1, 1, 1, 1, 1

TELNET                    1000           (minimise le délai)
FTP
        Contrôle          1000           (minimise le délai)
        Données           0100           (maximalise le débit)

TFTP                      1000           (minimise le délai)

SMTP 
        phase de commande 1000           (minimise le délai)
        phase DATA        0100           (maximalise le débit)

Domain Name Service
        requête UDP       1000           (minimise le délai)
        requête TCP       0000
        Transfert de Zone 0100           (maximalise le débit)

NNTP                      0001           (minimise le coût monétaire)

ICMP
        Erreurs           0000
        Requêtes          0000 (presque)
        Réponses         <même chose que requête> (presque)

Le Token Bucket Filter (TBF) est un gestionnaire de mise en file d'attente simple. Il ne fait que laisser passer les paquets entrants avec un débit n'excédant pas une limite fixée administrativement. L'envoi de courtes rafales de données avec un débit dépassant cette limite est cependant possible.

TBF est très précis, et peu gourmand du point de vue réseau et processeur. Considérez-le en premier si vous voulez simplement ralentir une interface !

L'implémentation TBF consiste en un tampon (seau), constamment rempli par des éléments virtuels d'information appelés jetons, avec un débit spécifique (débit de jeton). Le paramètre le plus important du tampon est sa taille, qui correspond au nombre de jetons qu'il peut stocker.

Chaque jeton entrant laisse sortir un paquet de données de la file d'attente de données et ce jeton est alors supprimé du seau. L'association de cet algorithme avec les deux flux de jetons et de données nous conduit à trois scénarios possibles :

• les données arrivent dans TBF avec un débit ÉGAL au débit des jetons entrants. Dans ce cas, chaque paquet entrant a son jeton correspondant et passe la file d'attente sans délai ;
• les données arrivent dans TBF avec un débit PLUS PETIT que le débit des jetons. Seule une partie des jetons est supprimée au moment où les paquets de données sortent de la file d'attente, de sorte que les jetons s'accumulent jusqu'à atteindre la taille du tampon. Les jetons libres peuvent être utilisés pour envoyer des données avec un débit supérieur au débit des jetons standard, si de courtes rafales de données arrivent ;
• les données arrivent dans TBF avec un débit PLUS GRAND que le débit des jetons. Ceci signifie que le seau sera bientôt dépourvu de jetons, ce qui provoque l'arrêt de TBF pendant un moment. Ceci s'appelle « une situation de dépassement de limite » (overlimit situation). Si les paquets continuent à arriver, ils commenceront à être éliminés.

Le dernier scénario est très important, car il autorise la mise en forme administrative de la bande passante disponible pour les données traversant le filtre.

L'accumulation de jetons autorise l'émission de courtes rafales de données sans perte en situation de dépassement de limite, mais toute surcharge prolongée causera systématiquement le retard des paquets, puis leur rejet.

Notez que, dans l'implémentation réelle, les jetons correspondent à des octets, et non des paquets.

9-2-2-1. Paramètres et usage▲

9-2-2-2. Configuration simple▲

# tc qdisc add dev ppp0 root tbf rate 220kbit latency 50ms burst 1540

Stochastic Fairness Queueing (SFQ) est une implémentation simple de la famille des algorithmes de mise en file d'attente équitable. Cette implémentation est moins précise que les autres, mais elle nécessite aussi moins de calculs tout en étant presque parfaitement équitable.

Le mot-clé dans SFQ est conversation (ou flux), qui correspond principalement à une session TCP ou un flux UDP. Le trafic est alors divisé en un grand nombre de jolies files d'attente FIFO : une par conversation. Le trafic est alors envoyé dans un tourniquet, donnant une chance à chaque session d'envoyer leurs données tour à tour.

Ceci conduit à un comportement très équitable et empêche qu'une seule conversation étouffe les autres. SFQ est appelé « Stochastic », car il n'alloue pas vraiment une file d'attente par session, mais a un algorithme qui divise le trafic à travers un nombre limité de files d'attente en utilisant un algorithme de hachage.

À cause de ce hachage, plusieurs sessions peuvent finir dans le même seau, ce qui peut réduire de moitié les chances d'une session d'envoyer un paquet et donc réduire de moitié la vitesse effective disponible. Pour empêcher que cette situation ne devienne importante, SFQ change très souvent son algorithme de hachage pour que deux sessions entrantes en collision ne le fassent que pendant un nombre réduit de secondes.

Il est important de noter que SFQ n'est seulement utile que dans le cas où votre interface de sortie est vraiment saturée ! Si ce n'est pas le cas, il n'y aura pas de file d'attente sur votre machine Linux et donc, pas d'effets. Plus tard, nous décrirons comment combiner SFQ avec d'autres gestionnaires de mise en file d'attente pour obtenir le meilleur des deux mondes.

Configurer spécialement SFQ sur l'interface ethernet qui est en relation avec votre modem câble ou votre routeur DSL est vain sans d'autres mises en forme du trafic !

9-2-3-1. Paramètres et usage▲

9-2-3-2. Configuration simple▲

# tc qdisc add dev ppp0 root sfq perturb 10
# tc -s -d qdisc ls
qdisc sfq 800c: dev ppp0 quantum 1514b limit 128p flows 128/1024 perturb 10sec 
 Sent 4812 bytes 62 pkts (dropped 0, overlimits 0)

Quand le trafic entre dans un gestionnaire de mise en file d'attente basé sur des classes, il doit être envoyé vers l'une de ses classes ; il doit être « classifié ». Pour déterminer que faire d'un paquet, les éléments appelés « filtres » sont consultés. Il est important de savoir que les filtres sont appelés de l'intérieur d'un gestionnaire, et pas autrement !

Les filtres attachés à ce gestionnaire renvoient alors une décision que le gestionnaire utilise pour mettre en file d'attente le paquet vers l'une des classes. Chaque sous-classe peut essayer d'autres filtres pour voir si de nouvelles instructions s'appliquent. Si ce n'est pas le cas, la classe met le paquet en file d'attente dans le gestionnaire de mise en file d'attente qu'elle contient.

En plus de contenir d'autres gestionnaires, la plupart des gestionnaires de mise en file d'attente basés sur des classes réalisent également de la mise en forme. Ceci est utile pour réaliser à la fois l'ordonnancement (avec SFQ, par exemple) et le contrôle de débit. Vous avez besoin de ceci dans les cas où vous avez une interface à haut débit (ethernet, par exemple) connectée à un périphérique plus lent (un modem câble).

Si vous n'utilisez que SFQ, rien ne devait se passer, dans la mesure où les paquets entrent et sortent du routeur sans délai : l'interface de sortie est de loin beaucoup plus rapide que la vitesse réelle de votre liaison ; il n'y a alors pas de file d'attente à réordonnancer.

Chaque interface à « un gestionnaire de mise en file d'attente racine » de sortie (egress root qdisc). Par défaut, le gestionnaire de mise en file d'attente sans classe mentionné plus tôt pfifo_fast. Chaque gestionnaire et classe est repéré par un descripteur (handle), qui pourra être utilisé par les prochaines déclarations de configuration pour se référer à ce gestionnaire. En plus du gestionnaire de sortie, une interface peut également avoir un gestionnaire d'entrée (ingress), qui réglemente le trafic entrant.

Ces descripteurs sont constitués de deux parties : un nombre majeur et un nombre mineur : <major>:<minor>. Il est habituel de nommer le gestionnaire racine 1:, ce qui est équivalent à 1:0. Le nombre mineur d'un gestionnaire de mise en file d'attente est toujours 0.

Les classes doivent avoir le même nombre majeur que leur parent. Le nombre majeur doit être unique à l'intérieur d'une configuration egress ou ingress. Le nombre mineur doit être unique à l'intérieur d'un gestionnaire de mise en file d'attente et de ses classes.

9-5-2-1. Comment les filtres sont utilisés pour classifier le trafic▲

                     1:   Gestionnaire de mise en file d'attente racine
                      |
                     1:1    classe enfant
                   /  |  \
                  /   |   \
                 /    |    \
                 /    |    \
              1:10  1:11  1:12   classes enfants
               |      |     | 
               |     11:    |    classe terminale
               |            | 
               10:         12:   Gestionnaire de mise en file d'attente
              /   \       /   \
           10:1  10:2   12:1  12:2   classes terminales

1: -> 1:1 -> 12: -> 12:2

1: -> 12:2

9-5-2-2. Comment les paquets sont retirés de la file d'attente et envoyés vers le matériel▲

Le gestionnaire de mise en file d'attente ne met pas vraiment en forme le trafic ; il ne fait que le subdiviser en se basant sur la manière dont vous avez configuré vos filtres. Vous pouvez considérer les gestionnaires PRIO comme une sorte de super pfifo_fast dopé, où chaque bande est une classe séparée au lieu d'une simple FIFO.

Quand un paquet est mis en file d'attente dans le gestionnaire PRIO, une classe est choisie en fonction des filtres que vous avez donnés. Par défaut, trois classes sont créées. Ces classes contiennent par défaut de purs gestionnaires de mise en file d'attente FIFO sans structure interne, mais vous pouvez les remplacer par n'importe quels gestionnaires disponibles.

Chaque fois qu'un paquet doit être retiré d'une file d'attente, la classe :1 est d'abord testée. Les classes plus élevées ne sont utilisées que si aucune des bandes plus faibles n'a pas fourni de paquets.

Cette file d'attente est très utile dans le cas où vous voulez donner la priorité à certains trafics en utilisant toute la puissance des filtres tc et en ne se limitant pas seulement aux options du champ TOS. Vous pouvez également ajouter un autre gestionnaire de mise en file d'attente aux trois classes prédéfinies, tandis que pfifo_fast est limité aux simples gestionnaires FIFO.

Puisqu'il ne met pas vraiment en forme, on applique le même avertissement que pour SFQ. Utilisez PRIO seulement si votre lien physique est vraiment saturé ou intégrez-le à l'intérieur d'un gestionnaire de mise en file d'attente basé sur des classes qui réalisent la mise en forme. Ce dernier cas est valable pour pratiquement tous les modems câbles et les périphériques DSL.

En termes formels, le gestionnaire de mise en file d'attente PRIO est un ordonnanceur Work-Conserving.

9-5-3-1. Paramètres PRIO et usage▲

9-5-3-2. Configuration simple▲

     racine 1: prio
          1:   Gestionnaire racine
         / | \ 
       /   |   \
       /   |   \
     1:1  1:2  1:3    classes
      |    |    |
     10:  20:  30:    gestionnaire gestionnaire
     sfq  tbf  sfq
bande 0    1    2

# tc qdisc add dev eth0 root handle 1: prio 
## Ceci crée *instantanément* les classes 1:1, 1:2, 1:3
  
# tc qdisc add dev eth0 parent 1:1 handle 10: sfq
# tc qdisc add dev eth0 parent 1:2 handle 20: tbf rate 20kbit buffer 1600 limit 3000
# tc qdisc add dev eth0 parent 1:3 handle 30: sfq

# tc -s qdisc ls dev eth0 
qdisc sfq 30: quantum 1514b 
 Sent 0 bytes 0 pkts (dropped 0, overlimits 0) 

 qdisc tbf 20: rate 20Kbit burst 1599b lat 667.6ms 
 Sent 0 bytes 0 pkts (dropped 0, overlimits 0) 

 qdisc sfq 10: quantum 1514b 
 Sent 132 bytes 2 pkts (dropped 0, overlimits 0) 

 qdisc prio 1: bands 3 priomap  1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1
 Sent 174 bytes 3 pkts (dropped 0, overlimits 0)

# scp tc ahu@10.0.0.11:./
ahu@10.0.0.11's password: 
tc                   100% |*****************************|   353 KB    00:00    
# tc -s qdisc ls dev eth0
qdisc sfq 30: quantum 1514b 
 Sent 384228 bytes 274 pkts (dropped 0, overlimits 0) 

 qdisc tbf 20: rate 20Kbit burst 1599b lat 667.6ms 
 Sent 2640 bytes 20 pkts (dropped 0, overlimits 0) 

 qdisc sfq 10: quantum 1514b 
 Sent 2230 bytes 31 pkts (dropped 0, overlimits 0) 

 qdisc prio 1: bands 3 priomap  1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1
 Sent 389140 bytes 326 pkts (dropped 0, overlimits 0)

# tc -s qdisc ls dev eth0
qdisc sfq 30: quantum 1514b 
 Sent 384228 bytes 274 pkts (dropped 0, overlimits 0) 

 qdisc tbf 20: rate 20Kbit burst 1599b lat 667.6ms 
 Sent 2640 bytes 20 pkts (dropped 0, overlimits 0) 

 qdisc sfq 10: quantum 1514b 
 Sent 14926 bytes 193 pkts (dropped 0, overlimits 0) 

 qdisc prio 1: bands 3 priomap  1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1
 Sent 401836 bytes 488 pkts (dropped 0, overlimits 0)

Comme dit avant, CBQ est le gestionnaire de mise en file d'attente disponible le plus complexe, celui qui a eu le plus de publicité, qui est le moins compris et qui est probablement le plus farceur lors de sa mise au point. Ce n'est pas parce que les auteurs sont mauvais ou incompétents, loin de là, mais l'algorithme CBQ n'est pas remarquablement précis et il ne correspond pas vraiment à la façon dont Linux fonctionne.

En plus d'être basé sur des classes, CBQ sert également à la mise en forme de trafic et c'est sur cet aspect qu'il ne fonctionne pas très bien. Il travaille comme ceci : si vous essayez de mettre en forme une connexion de 10mbit/s à 1mbits/s, le lien doit être inactif 90 % du temps. Si ce n'est pas le cas, nous devons limiter le taux de sorte qu'il soit inactif 90 % du temps.

Ceci est assez dur à mesurer et c'est pour cette raison que CBQ déduit le temps d'inactivité du nombre de microsecondes qui s'écoule entre les requêtes de la couche matérielle pour avoir plus de données. Cette combinaison peut être utilisée pour évaluer si le lien est chargé ou non.

Ceci est plutôt léger et l'on n'arrive pas toujours à des résultats convenables. Par exemple, qu'en est-il de la vitesse de liaison réelle d'une interface qui n'est pas capable de transmettre pleinement les données à 100mbit/s, peut-être à cause d'un mauvais pilote de périphérique ? Une carte réseau PCMCIA ne pourra jamais atteindre 100mbit/s à cause de la conception du bus. De nouveau, comment calculons-nous le temps d'inactivité ?

Cela devient même pire quand on considère un périphérique réseau « pas-vraiment-réel » comme PPP Over Ethernet ou PPTP over TCP/IP. La largeur de bande effective est dans ce cas probablement déterminée par l'efficacité des tubes vers l'espace utilisateur, qui est énorme.

Les personnes qui ont effectué des mesures ont découvert que CBQ n'est pas toujours très exact, et parfois même, très éloigné de la configuration.

Cependant, il marche bien dans de nombreuses circonstances. Avec la documentation fournie ici, vous devriez être capable de le configurer pour qu'il fonctionne bien dans la plupart des cas.

9-5-4-1. Mise en forme CBQ en détail▲

9-5-4-2. Le comportement CBQ classful▲

9-5-4-3. Paramètres CBQ qui déterminent le partage et le prêt du lien▲

9-5-4-4. Configuration simple▲

               1:           gestionnaire de mise en file d'attente racine
               |
              1:1           classe enfant
             /   \
            /     \
          1:3     1:4       classes terminales
           |       |
          30:     40:       gestionnaires de mise en file d'attente
         (sfq)   (sfq)

# tc qdisc add dev eth0 root handle 1:0 cbq bandwidth 100Mbit         \ 
  avpkt 1000 cell 8
# tc class add dev eth0 parent 1:0 classid 1:1 cbq bandwidth 100Mbit  \
  rate 6Mbit weight 0.6Mbit prio 8 allot 1514 cell 8 maxburst 20      \
  avpkt 1000 bounded

# tc class add dev eth0 parent 1:1 classid 1:3 cbq bandwidth 100Mbit  \
  rate 5Mbit weight 0.5Mbit prio 5 allot 1514 cell 8 maxburst 20      \
  avpkt 1000
# tc class add dev eth0 parent 1:1 classid 1:4 cbq bandwidth 100Mbit  \
  rate 3Mbit weight 0.3Mbit prio 5 allot 1514 cell 8 maxburst 20      \
  avpkt 1000

# tc qdisc add dev eth0 parent 1:3 handle 30: sfq
# tc qdisc add dev eth0 parent 1:4 handle 40: sfq

# tc filter add dev eth0 parent 1:0 protocol ip prio 1 u32 match ip \
  sport 80 0xffff flowid 1:3
# tc filter add dev eth0 parent 1:0 protocol ip prio 1 u32 match ip \
  sport 25 0xffff flowid 1:4

9-5-4-5. D'autres paramètres CBQ : split et defmap▲

# tc qdisc add dev eth1 root handle 1: cbq bandwidth 10Mbit allot 1514 \
  cell 8 avpkt 1000 mpu 64
 
# tc class add dev eth1 parent 1:0 classid 1:1 cbq bandwidth 10Mbit    \
  rate 10Mbit allot 1514 cell 8 weight 1Mbit prio 8 maxburst 20        \
  avpkt 1000

TC_PRIO..          Num  Correspond à TOS
-------------------------------------------------
BESTEFFORT         0    Maximalise la Fiabilité 
FILLER             1    Minimalise le Coût 
BULK               2    Maximalise le Débit (0x8)  
INTERACTIVE_BULK   4                               
INTERACTIVE        6    Minimise le Délai (0x10)      
CONTROL            7

# tc class add dev eth1 parent 1:1 classid 1:2 cbq bandwidth 10Mbit     \
  rate 1Mbit allot 1514 cell 8 weight 100Kbit prio 3 maxburst 20        \
  avpkt 1000 split 1:0 defmap c0

# tc class add dev eth1 parent 1:1 classid 1:3 cbq bandwidth 10Mbit     \
  rate 8Mbit allot 1514 cell 8 weight 800Kbit prio 7 maxburst 20        \
  avpkt 1000 split 1:0 defmap 3f

priorité       envoyer à
0               1:3
1               1:3
2               1:3
3               1:3
4               1:3
5               1:3
6               1:2
7               1:2

# tc class change dev eth1 classid 1:2 cbq defmap 01/01

priorité       envoyer à
0               1:2
1               1:3
2               1:3
3               1:3
4               1:3
5               1:3
6               1:2
7               1:2

Martin Devera(<devik>) réalisa à juste titre que CBQ est complexe et qu'il ne semble pas optimisé pour de nombreuses situations classiques. Son approche hiérarchique est bien adaptée dans le cas de configurations où il y a une largeur de bande passante fixée à diviser entre différents éléments. Chacun de ces éléments aura une bande passante garantie, avec la possibilité de spécifier la quantité de bande passante qui pourra être empruntée.

HTB travaille juste comme CBQ, mais il n'a pas recours à des calculs de temps d'inoccupation pour la mise en forme. À la place, c'est un Token Bucket Filter basé sur des classes, d'où son nom. Il n'a que quelques paramètres, qui sont bien documentés sur ce site.

Au fur et à mesure que votre configuration HTB se complexifie, votre configuration s'adapte bien. Avec CBQ, elle est déjà complexe même dans les cas simples ! HTB3 (voir sa page principale pour les détails des versions HTB) fait maintenant partie des sources officielles du noyau (à partir des versions 2.4.20-pre1 et 2.5.31 et supérieures). Il est encore cependant possible que vous soyez obligé de récupérer la version mise à jour de 'tc' pour HTB3. Les programmes de l'espace utilisateur et la partie HTB du noyau doivent avoir le même numéro majeur. Sans cela, 'tc' ne marchera pas avec HTB.

Si vous avez déjà un noyau récent ou si vous êtes sur le point de mettre à jour votre noyau, considérez HTB coûte que coûte.

9-5-5-1. Configuration simple▲

# tc qdisc add dev eth0 root handle 1: htb default 30

# tc class add dev eth0 parent 1: classid 1:1 htb rate 6mbit burst 15k

# tc class add dev eth0 parent 1:1 classid 1:10 htb rate 5mbit burst 15k
# tc class add dev eth0 parent 1:1 classid 1:20 htb rate 3mbit ceil 6mbit burst 15k
# tc class add dev eth0 parent 1:1 classid 1:30 htb rate 1kbit ceil 6mbit burst 15k

# tc qdisc add dev eth0 parent 1:10 handle 10: sfq perturb 10
# tc qdisc add dev eth0 parent 1:20 handle 20: sfq perturb 10
# tc qdisc add dev eth0 parent 1:30 handle 30: sfq perturb 10

# U32="tc filter add dev eth0 protocol ip parent 1:0 prio 1 u32"
# $U32 match ip dport 80 0xffff flowid 1:10
# $U32 match ip sport 25 0xffff flowid 1:20

Comme expliqué dans le chapitre Filtres avancés pour la classification des paquets, vous pouvez vraiment analyser n'importe quoi en utilisant une syntaxe très compliquée. Pour commencer, nous allons montrer comment réaliser les choses évidentes, ce qui heureusement est plutôt facile.

Disons que nous avons un gestionnaire de mise en file d'attente PRIO appelé 10: qui contient trois classes, et que nous voulons assigner à la bande de plus haute priorité tout le trafic allant et venant du port 22. Les filtres seraient les suivants :

# tc filter add dev eth0 protocol ip parent 10: prio 1 u32 match \ 
  ip dport 22 0xffff flowid 10:1
# tc filter add dev eth0 protocol ip parent 10: prio 1 u32 match \
  ip sport 80 0xffff flowid 10:1
# tc filter add dev eth0 protocol ip parent 10: prio 2 flowid 10:2

Qu'est-ce que cela signifie ? Cela dit : attacher à eth0, au nœud 10: un filtre u32 de priorité 1 qui analyse le port de destination ip 22 et qui l'envoie vers la bande 10:1. La même chose est répétée avec le port source 80. La dernière commande indique que si aucune correspondance n'est trouvée, alors le trafic devra aller vers la bande 10:2, la plus grande priorité suivante.

Vous devez ajouter eth0 ou n'importe laquelle de vos interfaces, car chaque interface possède un espace de nommage de ses descripteurs qui lui est propre.

Pour sélectionner une adresse IP, utilisez ceci :

# tc filter add dev eth0 parent 10:0 protocol ip prio 1 u32 \ 
  match ip dst 4.3.2.1/32 flowid 10:1
# tc filter add dev eth0 parent 10:0 protocol ip prio 1 u32 \
  match ip src 1.2.3.4/32 flowid 10:1
# tc filter add dev eth0 protocol ip parent 10: prio 2      \
  flowid 10:2

Ceci dirige le trafic allant vers 4.3.2.1 et venant de 1.2.3.4 vers la file d'attente de plus haute priorité, tandis que le reste ira vers la prochaine plus haute priorité.

Vous pouvez rassembler ces deux vérifications pour récupérer le trafic venant de 1.2.3.4 avec le port source 80 :

# tc filter add dev eth0 parent 10:0 protocol ip prio 1 u32 match ip src 4.3.2.1/32
  match ip sport 80 0xffff flowid 10:1

La plupart des commandes présentées ici commencent avec le préambule suivant :

# tc filter add dev eth0 parent 1:0 protocol ip prio 1 u32 ..

Ils sont appelés filtres u32 et analysent N'IMPORTE QUELLE partie d'un paquet.

Sur l'adresse source/destination

Masque pour la source match ip src 1.2.3.0/24 et masque pour la destination match ip dst 4.3.2.0/24. Pour analyser un hôte simple, employez /32 ou omettez le masque.

Sur le port source/destination, tous les protocoles IP

Source: match ip sport 80 0xffff et destination : match ip dport ?? 0xffff

Sur le protocole ip (tcp, udp, icmp, gre, ipsec)

Utilisez les nombres définis dans /etc/protocols, par exemple 1 pour icmp : match ip protocol 1 0xff.

Sur fwmark

Vous pouvez marquer les paquets avec ipchains ou iptables et voir cette marque préservée lors du routage à travers les interfaces. Ceci est vraiment utile pour mettre uniquement en forme le trafic sur eth1 et venant de eth0, par exemple. La syntaxe est la suivante :

# tc filter add dev eth1 protocol ip parent 1:0 prio 1 handle 6 fw flowid 1:1

Notez que ce n'est pas une correspondance u32 !

Vous pouvez positionner une marque comme ceci :

# iptables -A PREROUTING -t mangle -i eth0 -j MARK --set-mark 6

Le nombre 6 est arbitraire.

Si vous ne voulez pas assimiler la syntaxe complète de tc filter, utilisez juste iptables et apprenez seulement la sélection basée sur fwmark.

Sur le champ TOS

Pour sélectionner le trafic interactif, délai minimum :

# tc filter add dev ppp0 parent 1:0 protocol ip prio 10 u32 \
      match ip tos 0x10 0xff \
     flowid 1:4

Utilisez 0x08 0xff pour le trafic de masse.

Pour plus de commandes de filtrage, voir le chapitre Filtres avancés pour la classification des paquets.

La première chose qui devrait vous venir à l'esprit est d'utiliser la mise en forme du trafic entrant pour vous garantir une grande passante. ;) La configuration se fait comme avec n'importe quelle autre interface :

tc qdisc add dev imq0 root handle 1: htb default 20

tc class add dev imq0 parent 1: classid 1:1 htb rate 2mbit burst 15k

tc class add dev imq0 parent 1:1 classid 1:10 htb rate 1mbit
tc class add dev imq0 parent 1:1 classid 1:20 htb rate 1mbit

tc qdisc add dev imq0 parent 1:10 handle 10: pfifo
tc qdisc add dev imq0 parent 1:20 handle 20: sfq

tc filter add dev imq0 parent 10:0 protocol ip prio 1 u32 match \
                ip dst 10.0.0.230/32 flowid 1:10

Dans cet exemple, u32 est utilisé pour la classification. Les autres classificateurs devraient marcher tout aussi bien. Le trafic doit ensuite être sélectionné et marqué pour être mis en file d'attente vers imq0.

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

Il existe aussi une cible ip6tables.

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 chaîne 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.

Les mises à jour et de plus amples informations peuvent être trouvées sur le site imq.

Le sélecteur U32 contient la définition d'un modèle, qui sera comparé au paquet traité. Plus précisément, il définit quels bits doivent correspondre dans l'en-tête du paquet, et rien de plus, mais cette méthode simple est très puissante. Jetons un œil sur l'exemple suivant, directement tiré d'un filtre assez complexe réellement existant :

# tc filter parent 1: protocol ip pref 10 u32 fh 800::800 order 2048 key ht 800 bkt 0 flowid 1:3 \
  match 00100000/00ff0000 at 0

Pour l'instant, laissons de côté la première ligne ; tous ces paramètres décrivent les tables de hachage du filtre. Focalisons-nous sur la ligne de sélection contenant le mot-clé match. Ce sélecteur fera correspondre les en-têtes IP dont le second octet sera 0x10 (0010). Comme nous pouvons le deviner, le nombre 00ff est le masque de correspondance, disant au filtre quels bits il doit regarder. Ici, c'est 0xff, donc l'octet correspondra si c'est exactement 0x10. Le mot-clé at signifie que la correspondance doit démarrer au décalage spécifié (en octets) - dans notre cas, c'est au début du paquet. Traduisons tout cela en langage humain : le paquet correspondra si son champ Type de Service (TOS) a le bit « faible délai » positionné. Analysons une autre règle :

# tc filter parent 1: protocol ip pref 10 u32 fh 800::803 order 2051 key ht 800 bkt 0 flowid 1:3 \
  match 00000016/0000ffff at nexthdr+0

L'option nexthdr désigne l'en-tête suivant encapsulé dans le paquet IP, c'est-à-dire celui du protocole de la couche supérieure. La correspondance commencera également au début du prochain en-tête. Elle devrait avoir lieu dans le deuxième mot de 32 bits de l'en-tête. Dans les protocoles TCP et UDP, ce champ contient le port de destination du paquet. Le nombre est donné dans le format big-endian, c'est-à-dire les bits les plus significatifs en premier. Il faut donc lire 0x0016 comme 22 en décimal, qui correspond au service SSH dans le cas de TCP. Comme vous le devinez, cette correspondance est ambiguë sans un contexte, et nous en discuterons plus loin.

Ayant compris tout cela, nous trouverons le sélecteur suivant très facile à lire : match c0a80100/ffffff00 at 16. Ce que nous avons ici, c'est une correspondance de trois octets au 17e octet, en comptant à partir du début de l'en-tête IP. Cela correspond aux paquets qui ont une adresse de destination quelconque dans le réseau 192.168.1/24. Après avoir analysé les exemples, nous pouvons résumer ce que nous avons appris.

Les sélecteurs généraux définissent le modèle, le masque et le décalage qui seront comparés au contenu du paquet. En utilisant les sélecteurs généraux, vous pouvez rechercher des correspondances sur n'importe quel bit de l'en-tête IP (ou des couches supérieures). Ils sont quand même plus difficiles à écrire et à lire que les sélecteurs spécifiques décrits ci-dessus. La syntaxe générale des sélecteurs est :

match [ u32 | u16 | u8 ] PATTERN MASK [ at OFFSET | nexthdr+OFFSET]

Un des mots-clés u32, u16 ou u8 doit spécifier la longueur du modèle en bits. PATTERN et MASK se rapporteront à la longueur définie par ce mot-clé. Le paramètre OFFSET est le décalage, en octets, pour le démarrage de la recherche de correspondance. Si le mot-clé nexthdr+ est présent, le décalage sera relatif à l'en-tête de la couche réseau supérieure.

Quelques exemples :

# tc filter add dev ppp14 parent 1:0 prio 10 u32 \
     match u8 64 0xff at 8 \
     flowid 1:4

Un paquet correspondra à cette règle si sa « durée de vie » (TTL) est de 64. TTL est le champ démarrant juste après le 8e octet de l'en-tête IP.

Correspond à tous les paquets TCP ayant le bit ACK activé :

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

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'œil sur un schéma de l'en-tête TCP, nous pouvons voir que le bit ACK est le second bit (0x10) du 14^e 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^e 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

La table suivante contient la liste de tous les sélecteurs spécifiques que les auteurs de cette section ont trouvés dans le code source du programme tc. Ils rendent simplement la vie plus facile en accroissant la lisibilité de la configuration du filtre.

FIXME: emplacement de la table - la table est dans un fichier séparé « selector.html »

FIXME: c'est encore en Polonais :-(

FIXME: doit être « sgmlisé »

Quelques exemples :

# tc filter add dev ppp0 parent 1:0 prio 10 u32 \
     match ip tos 0x10 0xff \
     flowid 1:4

FIXME: tcp dport match ne fonctionne pas comme décrit ci-dessous :

La règle ci-dessus correspondra à des paquets qui ont le champ TOS égal à 0x10. Le champ TOS commence au deuxième octet du paquet et occupe 1 octet, ce qui nous permet d'écrire un sélecteur général équivalent : match u8 0x10 0xff at 1. Cela nous donne une indication sur l'implémentation du filtre u32. Les règles spécifiques sont toujours traduites en règles générales, et c'est sous cette forme qu'elles sont stockées en mémoire par le noyau. Cela amène à une autre conclusion : les sélecteurs tcp et udp sont exactement les mêmes et c'est la raison pour laquelle vous ne pouvez pas utiliser un simple sélecteur match tcp dport 53 0xffff pour désigner un paquet TCP envoyé sur un port donné. Ce sélecteur désigne aussi les paquets UDP envoyés sur ce port. Vous devez également spécifier le protocole avec la règle suivante :

# tc filter add dev ppp0 parent 1:0 prio 10 u32 \
        match tcp dport 53 0xffff \
        match ip protocol 0x6 0xff \
        flowid 1:2

Il y a essentiellement deux façons de réglementer. Si vous avez compilé le noyau avec Estimators, celui-ci peut mesurer plus ou moins pour chaque filtre le trafic qui est passé. Ces estimations ne sont pas coûteuses en temps CPU, étant donné qu'il ne compte que 25 fois par seconde le nombre de données qui sont passées, et qu'il calcule le débit à partir de là.

L'autre manière utilise encore le Token Bucket Filter qui réside à l'intérieur du filtre cette fois. Le TBF analyse seulement le trafic À HAUTEUR de la bande passante que vous avez configurée. Si cette bande passante est dépassée, seul l'excès est traité par l'action de dépassement de limite configurée.

12-3-1-1. Avec l'estimateur du noyau▲

12-3-1-2. Avec le Token Bucket Filter▲

Si votre filtre décide qu'un dépassement de limite est atteint, il peut mettre en œuvre des « actions ». Actuellement, trois actions sont disponibles :

continue

Provoque l'arrêt de l'analyse du filtre, bien que d'autres filtres aient la possibilité de le faire ;

drop

Ceci est une option très féroce qui supprime simplement le trafic excédant un certain débit. Elle est souvent employée dans le Ingress policer et a des utilisations limitées. Par exemple, si vous avez un serveur de noms qui s'écroule s'il traite plus de 5 mbit/s de paquets, alors, vous pourrez dans ce cas utiliser un filtre d'entrée pour être sûr qu'il ne traitera jamais plus de 5 mbit/s ;

Pass/OK

Transmettre le trafic. Peut être utilisé pour mettre hors service un filtre compliqué, tout en le laissant en place ;

reclassify

Permet le plus souvent une reclassification vers Best Effort. Ceci est l'action par défaut.

Le seul vrai exemple connu est mentionné dans la section Protéger votre machine des inondations SYN.

FIXME: si vous avez déjà utilisé ceci, partagez s'il vous plaît votre expérience avec nous.

La base de données des politiques de routage (RPDB) a remplacé le routage IPv4 et la structure d'adressage à l'intérieur du noyau Linux, ce qui a permis les merveilleuses fonctionnalités décrites dans ce HOWTO. Malheureusement, la pile IPv6 à l'intérieur de Linux a été implémentée en dehors de cette structure principale. Bien qu'ils partagent des fonctionnalités, la structure RPDB de base ne participe pas dans ou avec les structures d'adressage et de routage de IPv6.

Ceci va sûrement changer, nous devons juste attendre un peu plus longtemps.

FIXME : des idées sur des personnes travaillant sur ce sujet ? Planifications ?

ip6tables est capable de marquer un paquet et de lui assigner un numéro :

# ip6tables -A PREROUTING -i eth0 -t mangle -p tcp -j MARK --mark 1

Ceci ne va cependant pas nous aider dans la mesure où le paquet ne passera pas par la structure RPDB.

IPv6 est normalement encapsulé dans un tunnel SIT et transporté à travers les réseaux IPv4. Voir la section sur le tunnel IPv6 pour de plus amples informations quant à la configuration d'un tel tunnel. Ceci nous permet de filtrer les paquets IPv4 en considérant les paquets IPv6 comme la charge utile.

Le filtre suivant repère tous les paquets IPv6 encapsulés dans des paquets IPv4 :

# tc filter add dev $DEV parent 10:0 protocol ip prio 10 u32 \
             match ip protocol 41 0xff flowid 42:42

Continuons. Supposons que les paquets IPv6 soient envoyés grâce à des paquets IPv4 et que ces paquets n'ont pas d'options. On pourrait utiliser le filtre suivant pour repérer ICMPv6 dans IPv6 dans IPv4 n'ayant aucune option. 0x3a (58) est le type du champ en-tête suivant pour ICMPv6.

# tc filter add dev $DEV parent 10:0 protocol ip prio 10 u32 \
            match ip protocol 41 0xff \
            match u8 0x05 0x0f at 0 \
            match u8 0x3a 0xff at 26 \
            flowid 42:42

Repérer l'adresse de destination IPv6 nécessite un peu plus de travail. Le filtre suivant repère l'adresse de destination 3ffe:202c:ffff:32:230:4fff:fe08:358d:

# tc filter add dev $DEV parent 10:0 protocol ip prio 10 u32 \
             match ip protocol 41 0xff \
             match u8 0x05 0x0f at 0 \
             match u8 0x3f 0xff at 44 \
             match u8 0xfe 0xff at 45 \
             match u8 0x20 0xff at 46 \
             match u8 0x2c 0xff at 47 \
             match u8 0xff 0xff at 48 \
             match u8 0xff 0xff at 49 \
             match u8 0x00 0xff at 50 \
             match u8 0x32 0xff at 51 \
             match u8 0x02 0xff at 52 \
             match u8 0x30 0xff at 53 \
             match u8 0x4f 0xff at 54 \
             match u8 0xff 0xff at 55 \
             match u8 0xfe 0xff at 56 \
             match u8 0x08 0xff at 57 \
             match u8 0x35 0xff at 58 \
             match u8 0x8d 0xff at 59 \
             flowid 10:13

La même technique peut être utilisée pour repérer les réseaux. Par exemple 2001::

# tc filter add dev $DEV parent 10:0 protocol ip prio 10 u32 \
             match ip protocol 41 0xff \
             match u8 0x05 0x0f at 0 \
             match u8 0x20 0xff at 28 \
             match u8 0x01 0xff at 29 \
             flowid 10:13

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 « tic-tac » (jiffies) et elles utilisent obligatoirement 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'une horloge. Dans le noyau lui-même, une variable globale nommée jiffies est incrémentée à 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 égale à 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 6 paquets au plus, 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 et Andi Kleen.

/proc/sys/net/ipv4/icmp_destunreach_rate

Si le noyau décide qu'il ne peut pas délivrer un paquet, il le rejettera 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.

/proc/sys/net/ipv4/icmp_echo_ignore_broadcasts [Utile]

Si vous pinguez l'adresse de diffusion d'un réseau, tous les hôtes sont sensé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.

/proc/sys/net/ipv4/icmp_ignore_bogus_error_responses

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 en-têtes IP ou TCP erronés. 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 écoute 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 (c'est-à-dire quand le nombre d'entrées 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'hôte 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. À 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 il y a d'entrées, plus le temps de vie est faible et plus l'intervalle du ramasse-miettes est 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, il 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-la 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, tous les sockets TCP locaux qui n'ont pas eu de paquets de réponse seront retraités pour avoir la bonne adresse. Cela résout le problème posé par une connexion défectueuse ayant configuré 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 Recettes 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 rejettera 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 un socket dans le cas où il a été fermé de notre côté. Le partenaire peut être défectueux et ne jamais avoir fermé son côté 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 morts. Les sockets FIN-WAIT2 sont moins dangereux que les sockets FIN-WAIT1 parce qu'ils consomment au maximum 1,5 K de mémoire, mais ils 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

À quelle fréquence les sondes sont retransmises lorsqu'il n'y a pas eu acquittement de sonde. 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 pendant lequel 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és à 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 existe seulement 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 ce type d'état. Laissez-moi vous rappeler encore que chaque orphelin consomme jusqu'à environ 64 K 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 côté. La valeur par défaut de 7 correspond à un temps d'environ 50 s à 16 min suivant le RTO. Si votre machine supporte un serveur Web, vous pouvez envisager de baisser cette valeur, dans la mesure où de tels sockets peuvent consommer des ressources significatives. Cf tcp_max_orphans.

/proc/sys/net/ipv4/tcp_max_syn_backlog

Nombre maximum de requêtes d'une connexion mémorisée, qui n'avait pas encore reçu 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 maximum de sockets timewait gérées par le système simultanément. Si ce nombre est dépassé, le socket timewait est immédiatement détruit 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é bogue à bogue avec certaines imprimantes défectueuses. Tentative d'envoi de plus gros paquets lors de la retransmission pour contourner le bogue 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 minimale du RFC est de 3. C'est la valeur par défaut ; elle correspond à un temps d'environ 3 s à 8 min suivant le RTO.

/proc/sys/net/ipv4/tcp_retries2

Combien d'essais avant de détruire une connexion TCP active. Le 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 d'environ 13 à 30 minutes suivant le RTO.

/proc/sys/net/ipv4/tcp_rfc1337

Ce booléen active un rectificatif pour « l'assassinat hasardeux des time-wait dans tcp », décrit dans le RFC 1337. S'il est 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 manquants. Facilite ainsi une récupération rapide.

/proc/sys/net/ipv4/tcp_stdurg

Utilise l'interprétation du 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 côté de la connexion, le noyau envoie un SYN avec un ACK superposé (piggyback), pour accuser réception du SYN précédemment envoyé. C'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 estampillages horaires sont utilisés, entre autres, 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 parce qu'il était d'une génération précédente. L'estampillage 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 65 535 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.

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 relais BOOTP interceptera et transmettra de tels paquets.

La valeur par défaut est 0, puisque 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 Filtrage de Chemin Inverse.

/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, cette interface répondra aux requêtes ARP pour les adresses que le noyau doit router. Peut être très utile si vous mettez en place des « pseudoponts ip ». Prenez bien garde d'avoir des masques de sous-réseau corrects avant d'activer cette option. Faites également attention que le rp_filter agisse aussi sur les requêtes ARP !

/proc/sys/net/ipv4/conf/DEV/rp_filter

Voir la section sur le Filtrage de Chemin Inverse.

/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 les 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 Yes.

/proc/sys/net/ipv4/conf/DEV/tag

FIXME: à remplir.

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).

/proc/sys/net/ipv4/neigh/DEV/app_solicit

Détermine le nombre de requêtes à envoyer au démon ARP de l'espace utilisateur. Utilisez 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 le RFC2461.

/proc/sys/net/ipv4/neigh/DEV/delay_first_probe_time

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'écritures dans le cache.

/proc/sys/net/ipv4/neigh/DEV/mcast_solicit

Nombre maximum d'essais consécutifs pour une sollicitation multicast.

/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émunir 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.

/proc/sys/net/ipv4/route/error_burst

Ces paramètres sont utilisés pour limiter le nombre de messages d'avertissement écrits dans le journal du noyau par le code de 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 se 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 dans le journal du noyau par le code de 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 se limitent à un message d'avertissement toutes les cinq secondes.

/proc/sys/net/ipv4/route/flush

L'écriture dans ce fichier provoque la vidange 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 du cache de routage. Ceci peut être important en cas de défaut. 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.

Voir aussi ce message par Ard van Breemen.

/proc/sys/net/ipv4/route/gc_interval

Voir /proc/sys/net/ipv4/route/gc_elasticity.

/proc/sys/net/ipv4/route/gc_min_interval

Voir /proc/sys/net/ipv4/route/gc_elasticity.

/proc/sys/net/ipv4/route/gc_thresh

Voir /proc/sys/net/ipv4/route/gc_elasticity.

/proc/sys/net/ipv4/route/gc_timeout

Voir /proc/sys/net/ipv4/route/gc_elasticity.

/proc/sys/net/ipv4/route/max_delay

Délai d'attente pour la vidange du cache du routage.

/proc/sys/net/ipv4/route/max_size

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 d'attente pour vider le 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 aura é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-delà de cette période, les redirections seront de nouveau envoyées, même si elles ont été stoppées parce que la charge ou le nombre limite a été atteint.

limit

Spécifie la taille de la file d'attente. Mesurée en octets pour bfifo et en paquets pour pfifo. Par défaut, correspond à des paquets de taille égale au paramètre txqueuelen de l'interface (voir le chapitre pfifo_fast) ou txqueuelen*mtu octets pour bfifo.

Avant tout, il serait préférable de lire les RFC écrits sur ce sujet (RFC2474, RFC2475, RFC2597 et RFC2598) sur le site web du groupe de travail DiffServ IETF et sur le site web de Werner Almesberger (il a écrit le code permettant le support des Services Différenciés sous Linux).

DSMARK est un gestionnaire de mise en file d'attente qui offre les fonctionnalités dont ont besoin les services différenciés (Differentiated Services) (également appelés DiffServ ou tout simplement DS). DiffServ est l'une des deux architectures actuelles de la Qualité de Services (QoS : Quality of Services) (l'autre est appelée services intégrés (Integrated Services). Elle se base sur la valeur du champ DS contenu dans l'en-tête IP du paquet.

Une des premières solutions dans IP pour offrir des niveaux de qualité de services était le champ Type de Service (octet TOS) de l'en-tête IP. En modifiant la valeur de ce champ, nous pouvions choisir un niveau élevé/faible du débit, du délai ou de la fiabilité. Cependant, cela ne fournissait pas une flexibilité suffisante pour les besoins de nouveaux services (comme les applications temps réel, les applications interactives et autres). Par la suite, de nouvelles architectures sont apparues. L'une d'elles a été DiffServ qui a gardé les bits TOS et les a renommés champ DS.

Les services différenciés sont orientés groupes. Cela signifie que nous ne savons rien des flux (ce sera le but des services intégrés (integrated Services)). Nous connaissons en revanche les agrégations de flux et nous adopterons des comportements différents suivant l'agrégation à laquelle appartient le paquet.

Quand un paquet arrive à un nœud frontalier (nœud d'entrée du domaine DiffServ) et entre dans un domaine DiffServ, nous devrons avoir une politique, une mise en forme et/ou un marquage de ces paquets (le marquage fait référence à la mise en place d'une valeur dans le champ DS. Comme on le ferait pour des vaches :-)). Ce sera cette marque/valeur que les nœuds internes de votre domaine DiffServ regarderont pour déterminer quels comportement ou niveau de qualité de service appliquer.

Comme vous pouvez le déduire, les Services Différenciés impliquent un domaine sur lequel toutes les règles DS devront être appliquées. Vous pouvez raisonner de la façon suivante : « Je classifierai tous les paquets entrant dans mon domaine. Une fois qu'ils seront entrés dans mon domaine, ils seront soumis aux règles que ma classification impose et chaque nœud traversé appliquera son niveau de qualité de service ».

En fait, vous pouvez appliquer vos propres politiques dans vos domaines locaux, mais des autorisations au niveau service devront être considérées lors de la connexion à d'autres domaines DS.

En ce moment, vous vous posez peut-être beaucoup de questions. DiffServ est plus vaste que ce que j'ai expliqué. En fait, vous pouvez comprendre que je ne peux pas résumer plus de trois RFC en 50 lignes :-).

Comme le spécifie la bibliographie concernant DiffServ, nous différencions les nœuds frontaliers et les nœuds intérieurs. Ce sont deux éléments importants dans le chemin qu'emprunte le trafic. Les deux réalisent une classification quand un paquet arrive. Le résultat peut être utilisé à différents endroits lors du processus DS avant que le paquet ne soit libéré vers le réseau. Cela est possible, car le nouveau code DiffServ fournit une structure appelée sk_buff, incluant un nouveau champ appelé skb->tcindex. Ce champ mémorisera le résultat de la classification initiale et pourra être utilisé à plusieurs reprises dans le traitement DS.

La valeur skb->tc_index sera initialement configurée par le gestionnaire de mise en file d'attente DSMARK. Cette valeur sera extraite du champ DS de l'en-tête IP de tous les paquets reçus. En outre, le classificateur cls_tcindex lira tout ou une partie de la valeur skb->tcindex et l'utilisera pour sélectionner les classes.

Mais, avant tout, regardons la commande qdisc DSMARK et ses paramètres :

... dsmark indices INDICES [ default_index DEFAULT_INDEX ] [ set_tc_index ]

Que signifient ces paramètres ?

• indices : taille de la table des couples (masque,valeur). La valeur maximum est 2^n, où n>=0.
• default_index : index d'entrée par défaut de la table si aucune correspondance n'est trouvée.
• set_tc_index : indique au gestionnaire DSMARK de récupérer le champ DS et de l'enregistrer dans skb->tc_index.

Regardons DSMARK procéder.

Ce gestionnaire de mise en file d'attente réalisera les étapes suivantes :

• si vous avez déclaré l'option set_tc_index dans la commande qdisc, le champ DS est récupéré et mémorisé dans la variable skb->tc_index ;
• le classificateur est invoqué. Celui-ci sera exécuté et retournera un identificateur de classe (class ID) qui sera enregistré dans la variable skb->tc_index. Si aucun filtre correspondant n'est trouvé, nous considérons l'option default_index comme étant l'identificateur de classe à enregistrer. Si, ni set_tc_index, ni default_index n'ont été déclarés, alors les résultats peuvent être non prédictifs ;
• après avoir été envoyé dans le gestionnaire de files d'attente interne, où le résultat du filtre peut être réutilisé, l'identificateur de classe retourné par le gestionnaire est stocké dans la variable skb->tc_index. Cette valeur sera utilisée plus tard pour indexer la table masque-valeur. Le résultat de l'opération suivante sera assigné au paquet :
   

  Sélectionnez

    Nouveau_champ_DS = ( Ancien_champ_DS & masque ) | valeur

• la nouvelle valeur résultera donc d'un ET logique entre les valeurs du champ_DS et du masque, suivi d'un OU logique avec le paramètre valeur. Regardez la figure suivante pour comprendre tout ce processus :

                         skb->ihp->tos
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - >
     |                                                       |     ^
     | -- Si vous déclarez set_tc_index, nous configurons    |     |  <-----Peut changer
     |    la valeur DS dans la variable skb->tc_index        |     |O       le champ DS
     |                                                      A|     |R
   +-|-+      +------+    +---+-+  File d'attente-+     +---N|-----|----+
   | | |      |filtre|--->|   | |-->  . . .  -->| |     |   D|     |    |
   | | |----->|  tc  |--->|   | |   interne     | |---->|    v     |    |
   | | |      |index |--->| | | +---------------+ |   ---->(masque,valeur)|
-->| O |      +------+    +-|-+--------------^----+  /  |  (.  ,  .)    |
   | | |          ^         |                |       |  |  (.  ,  .)    |
   | | +----------|---------|----------------|-------|--+  (.  ,  .)    |
   | | sch_dsmark |         |                |       |                  |
   +-|------------|---------|----------------|-------|------------------+
     |            |         | <- tc_index -> |       |
     |            |(lecture)|   peut changer |       |  <--------------Index de la table
     |            |         |                |       |                    des couples 
     v            |         v                v       |                    (masque,valeur)
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - ->
                         skb->tc_index

Comment faire le marquage ? Il suffit de modifier le masque et la valeur associés à la classe que vous voulez marquer. Regardez la ligne de code suivante :

tc class change dev eth0 classid 1:1 dsmark mask 0x3 value 0xb8

Cela modifie le couple (masque,valeur) dans la table de hachage, et remarque les paquets appartenant à la classe 1:1. Vous devez « changer » ces valeurs en raison des valeurs par défaut que le couple (masque, valeur) obtient initialement (voir le tableau ci-dessous).

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.

Voici la commande de base pour déclarer un filtre TC_INDEX :

... tcindex [ hash SIZE ] [ mask MASK ] [ shift SHIFT ]
            [ pass_on | fall_through ]
            [ classid CLASSID ] [ police POLICE_SPEC ]

Ensuite, nous montrons l'exemple utilisé pour expliquer le mode opératoire de TC_INDEX. Soyez attentif aux mots en gras : tc qdisc add dev eth0 handle 1:0 root dsmark indices 64 set_tc_index tc filter add dev eth0 parent 1:0 protocol ip prio 1 tcindex mask 0xfc shift 2 tc qdisc add dev eth0 parent 1:0 handle 2:0 cbq bandwidth 10Mbit cell 8 avpkt 1000 mpu 64 # Classe du trafic EF tc class add dev eth0 parent 2:0 classid 2:1 cbq bandwidth 10Mbit rate 1500Kbit avpkt 1000 prio 1 bounded isolated allot 1514 weight 1 maxburst 10 # Gestionnaire de file d'attente fifo pour le trafic EF tc qdisc add dev eth0 parent 2:1 pfifo limit 5 tc filter add dev eth0 parent 2:0 protocol ip prio 1 handle 0x2e tcindex classid 2:1 pass_on (ce code n'est pas complet. Ce n'est qu'un extrait de l'exemple EFCBQ inclus dans la distribution iproute2).

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 restants. 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.

Le gestionnaire de mise en file d'attente d'entrée ne nécessite pas de paramètres. Il diffère des autres gestionnaires dans le fait qu'il n'occupe pas la racine du périphérique. Attachez-le comme ceci :

# tc qdisc add dev eth0 ingress

Ceci vous autorise à avoir d'autres gestionnaires de sortie sur votre périphérique en plus du gestionnaire d'entrée.

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

|---------------------------------------|
|Schéma du trafic après l'implémentation|
|---------------------------------------|

INTERNET
/\
||
\/
-----------------routeur donmuang---------------------
/\                                      /\         ||
||                                      ||         ||
||                                      \/         ||
naret                                  silom       ||
*trafic à destination du port 80=====>(cache)      ||
/\                                      ||         ||
||                                      \/         \/
\\===================================kaosarn, RAS, etc.

Notez que le réseau est asymétrique, car il y a un saut supplémentaire sur le chemin sortant.

Voici le cheminement d'un paquet traversant le réseau de kaosarn allant et
venant d'Internet.

Pour le trafic Web/http :
requête http kaosarn->naret->silom->donmuang->Internet
réponse http de Internet->donmuang->silom->kaosarn

Pour les requêtes non-Web/http (par ex. telnet) :
données sortantes kaosarn->naret->donmuang->Internet
données entrantes d'Internet->donmuang->kaosarn

Quand vous rencontrez des sites qui présentent ce problème, vous pouvez désactiver la découverte du MTU de chemin en le configurant manuellement. Koos van den Hout a à peu près écrit :

Le problème suivant : j'ai configuré le mtu et mru de ma ligne dédiée fonctionnant avec ppp à 296 dans la mesure où le débit est de seulement 33 k6 et que je ne peux pas influencer la file d'attente de l'autre côté. À 296, la réponse à l'appui d'une touche intervient dans un délai raisonnable.

Et, de mon côté, j'ai un routeur avec traduction d'adresse (masquage) fonctionnant (bien sûr) sous Linux.

Récemment, j'ai séparé le serveur du routeur de sorte que la plupart des applications fonctionnent sur une machine différente de celle qui réalise le routage.

J'ai alors eu des problèmes en me connectant sur l'irc. Grosse panique ! Je vous assure que certains essais trouvaient que j'étais connecté à l'irc, me montrant même comme connecté sur l'irc mais je ne recevais pas le « motd » (message of the day, message du jour) de l'irc. J'ai vérifié ce qui pouvait être erroné et ai noté que j'avais déjà eu des soucis liés au MTU en contactant certains sites Web. Je n'avais aucun souci pour les atteindre quand le MTU était à 1500, le problème n'apparaissant que lorsque le MTU était configuré à 296. Puisque les serveurs irc bloquent tout le trafic dont ils n'ont pas besoin pour leurs opérations immédiates, ils bloquent aussi l'icmp.

J'ai manœuvré pour convaincre les responsables d'un serveur Web que ceci était la cause d'un problème, mais les responsables du serveur irc n'avaient pas l'intention de réparer ceci.

Donc, je devais être sûr que le trafic masqué sortant partait avec le mtu faible du lien externe. Mais, je voulais que le trafic ethernet local ait le MTU normal (pour des choses comme le trafic nfs).

Solution :

ip route add default via 10.0.0.1 mtu 296

(10.0.0.1 étant ma passerelle par défaut, l'adresse interne de mon routeur masquant)

En général, il est possible d'outrepasser la découverte du MTU de chemin en configurant des routes spécifiques. Par exemple, si seuls certains réseaux posent problème, ceci devrait aider :

ip route add 195.96.96.0/24 via 10.0.0.1 mtu 1000

Les FAI savent que leurs performances ne sont seulement jugées que sur la vitesse à laquelle les personnes peuvent télécharger vers l'aval. En plus de la bande passante disponible, la vitesse de téléchargement est lourdement influencée par la perte des paquets, qui gêne sérieusement les performances de TCP/IP. Les grandes files d'attente peuvent aider à prévenir la perte des paquets, et augmenter les téléchargements. Les FAI configurent donc de grandes files d'attente.

Ces grandes files d'attente endommagent cependant l'interactivité. Une frappe doit d'abord parcourir la file d'attente du flux montant, ce qui peut prendre plusieurs secondes, et aller jusqu'à l'hôte distant. Elle est alors traitée, conduisant à un paquet de retour qui doit traverser la file d'attente du flux descendant, localisée chez votre FAI, avant qu'elle n'apparaisse sur l'écran.

Cet HOWTO nous enseigne plusieurs manières de modifier et traiter la file d'attente mais, malheureusement, toutes les files d'attente ne nous sont pas accessibles. Les files d'attente du FAI sont sans limites et la file d'attente du flux montant réside probablement dans votre modem câble ou votre périphérique DSL. Il se peut que vous soyez capable ou non de le configurer. La plupart du temps, ce ne sera pas le cas.

Et après ? Étant donné que nous ne pouvons pas contrôler ces files d'attente, elles doivent disparaître et être transférées sur notre routeur Linux. Heureusement, ceci est possible.

Limiter la vitesse de téléchargement vers l'amont (upload)

En limitant notre vitesse de téléchargement vers l'amont à une vitesse légèrement plus faible que la vitesse réelle disponible, il n'y a pas de files d'attente mises en place dans notre modem. La file d'attente est maintenant transférée vers Linux.

Limiter la vitesse de téléchargement vers l'aval (download)

Ceci est légèrement plus rusé dans la mesure où nous ne pouvons pas vraiment influencer la vitesse à laquelle Internet nous envoie les données. Nous pouvons cependant rejeter les paquets qui arrivent trop vite, ce qui provoque le ralentissement de TCP/IP jusqu'au débit désiré. Comme nous ne voulons pas supprimer inutilement du trafic, nous configurons une vitesse de rafale ('burst') plus grande.

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.

Marche avec tous les noyaux. À l'intérieur du gestionnaire de mise en file d'attente CBQ, nous plaçons deux SFQ pour être sûr que de multiples flux de masse ne vont pas mutuellement se pénaliser.

Le trafic descendant est réglementé en utilisant un filtre tc contenant un Token Bucket Filter.

Vous pourriez améliorer ce script en ajoutant 'bounded' aux lignes qui démarrent avec 'tc class add .. classid 1:20'. Si vous avez diminué votre MTU, diminuez aussi les nombres allot & avpkt !

#!/bin/bash 

# La configuration ultime pour votre connexion Internet domestique
# 
# Configurez les valeurs suivantes avec des valeurs légèrement inférieures que 
# vos vitesses de flux montant et descendant. Exprimé en kilobits.
DOWNLINK=800
UPLINK=220
DEV=ppp0

# Nettoie les gestionnaires de sortie et d'entrés, cache les erreurs
tc qdisc del dev $DEV root    2> /dev/null > /dev/null
tc qdisc del dev $DEV ingress 2> /dev/null > /dev/null

###### Flux montant (uplink)

# installe CBQ à la racine

tc qdisc add dev $DEV root handle 1: cbq avpkt 1000 bandwidth 10mbit 

# Le trafic est mis en forme à une vitesse de $UPLINK. Ceci évite
# d'énormes files d'attente dans votre modem DSL qui pénalisent le temps de
# latence.
# Classe principale

tc class add dev $DEV parent 1: classid 1:1 cbq rate ${UPLINK}kbit \
allot 1500 prio 5 bounded isolated 

# classe de priorité supérieure 1:10:

tc class add dev $DEV parent 1:1 classid 1:10 cbq rate ${UPLINK}kbit \
   allot 1600 prio 1 avpkt 1000

# la classe par défaut et pour le trafic de masse 1:20. Reçoit légèrement
# moins que le trafic et a une priorité plus faible :
# bulk and default class 1:20 - gets slightly less traffic, 
#  and a lower priority:

tc class add dev $DEV parent 1:1 classid 1:20 cbq rate $[9*$UPLINK/10]kbit \
   allot 1600 prio 2 avpkt 1000

# Les deux sont gérées par SFQ :
tc qdisc add dev $DEV parent 1:10 handle 10: sfq perturb 10
tc qdisc add dev $DEV parent 1:20 handle 20: sfq perturb 10

# Démarrage des filtres
# le bit Délai Minimum du champ TOS (ssh, PAS scp) est dirigé vers
# 1:10 :
tc filter add dev $DEV parent 1:0 protocol ip prio 10 u32 \
      match ip tos 0x10 0xff  flowid 1:10
# ICMP (ip protocol 1) est dirigé vers la classe interactive 1:10 de telle
# sorte que nous pouvons réaliser des mesures et impressionner nos
# amis :
tc filter add dev $DEV parent 1:0 protocol ip prio 11 u32 \
        match ip protocol 1 0xff flowid 1:10

# Pour accélérer les téléchargements vers l'aval lors de la présence d'un
# flux montant, les paquets ACK sont placés dans la classe
# interactive :

tc filter add dev $DEV parent 1: protocol ip prio 12 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:10

# Le reste est considéré 'non interactif' c.-à-d. 'de masse' et fini dans 1:20

tc filter add dev $DEV parent 1: protocol ip prio 13 u32 \
   match ip dst 0.0.0.0/0 flowid 1:20

########## Flux descendant (downlink) #############
# Ralentir le flux descendant à une valeur légèrement plus faible que votre
# vitesse réelle de manière à éviter la mise en file d'attente chez notre
# FAI. Faites des tests pour voir la vitesse maximum à laquelle vous pouvez
# le configurer. Les FAI ont tendance à avoir *d'énormes* files d'attente
# pour s'assurer de la rapidité des gros téléchargements.
#
# attache la réglementation d'entrée (ingress policer) :

tc qdisc add dev $DEV handle ffff: ingress

# Filtre *tout* (0.0.0.0/0), rejette tout ce qui arrive trop
# rapidement :

tc filter add dev $DEV parent ffff: protocol ip prio 50 u32 match ip src \
   0.0.0.0/0 police rate ${DOWNLINK}kbit burst 10k drop flowid :1

Si vous voulez que ce script soit exécuté par ppp à la connexion, copiez-le dans /etc/ppp/ip-up.d.

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

Le script suivant nous permet d'atteindre tous nos buts en utilisant la merveilleuse file d'attente HTB. Voir le chapitre correspondant. Cela vaut la peine de mettre à jour votre noyau !

#!/bin/bash

# La configuration ultime pour votre connexion Internet domestique
# 
# Configurez les valeurs suivantes avec des valeurs légèrement inférieures que 
# vos vitesses de flux montant et descendant. Exprimé en kilobits.
DOWNLINK=800
UPLINK=220
DEV=ppp0

#Nettoie les gestionnaires de sortie et d'entrés, cache les erreurs
tc qdisc del dev $DEV root    2> /dev/null > /dev/null
tc qdisc del dev $DEV ingress 2> /dev/null > /dev/null

###### Flux montant (uplink)

# installe HTB à la racine, le trafic ira par défaut vers 1:20 :

tc qdisc add dev $DEV root handle 1: htb default 20

# Le trafic est mis en forme à une vitesse de $UPLINK. Ceci évite
# d'énormes files d'attente dans votre modem DSL qui pénalisent le temps de
# latence.

tc class add dev $DEV parent 1: classid 1:1 htb rate ${UPLINK}kbit burst 6k

# la classe de haute priorité 1:10 :

tc class add dev $DEV parent 1:1 classid 1:10 htb rate ${UPLINK}kbit \
   burst 6k prio 1

# bulk & default class 1:20 - gets slightly less traffic, 
# and a lower priority:

tc class add dev $DEV parent 1:1 classid 1:20 htb rate $[9*$UPLINK/10]kbit \
   burst 6k prio 2

# Les deux sont gérées par SFQ :
tc qdisc add dev $DEV parent 1:10 handle 10: sfq perturb 10
tc qdisc add dev $DEV parent 1:20 handle 20: sfq perturb 10

# le bit Délai Minimum du champ TOS (ssh, PAS scp) est dirigé vers
# 1:10 :
tc filter add dev $DEV parent 1:0 protocol ip prio 10 u32 \
      match ip tos 0x10 0xff  flowid 1:10

# ICMP (ip protocol 1) est dirigé vers la classe interactive 1:10 de telle
# sorte que nous pouvons réaliser des mesures et impressionner nos
# amis :
tc filter add dev $DEV parent 1:0 protocol ip prio 10 u32 \
        match ip protocol 1 0xff flowid 1:10

# Pour accélérer les téléchargements vers l'aval lors de la présence d'un
# flux montant, les paquets ACK sont placés dans la classe
# interactive :

tc filter add dev $DEV parent 1: 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:10

# Le reste est considéré 'non interactif' c.-à-d. 'de masse' et fini dans 1:20


########## Flux descendant (downlink) #############
# Ralentir le flux descendant à une valeur légèrement plus faible que votre
# vitesse réelle de manière à éviter la mise en file d'attente chez notre
# FAI. Faites des tests pour voir la vitesse maximum à laquelle vous pouvez
# le configurer. Les FAI ont tendance à avoir *d'énormes* files d'attente
# pour s'assurer de la rapidité des gros téléchargements.
#
# attache la réglementation d'entrée (ingress policer) :

tc qdisc add dev $DEV handle ffff: ingress

# Filtre *tout* (0.0.0.0/0), rejette tout ce qui arrive trop
# rapidement :

tc filter add dev $DEV parent ffff: protocol ip prio 50 u32 match ip src \
   0.0.0.0/0 police rate ${DOWNLINK}kbit burst 10k drop flowid :1

Si vous voulez que ce script soit exécuté par ppp à la connexion, copiez-le dans /etc/ppp/ip-up.d.

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

Tout d'abord, nous allons configurer des gestionnaires de mise en file d'attente dans lesquels nous allons classifier le trafic. Nous créons un gestionnaire htb composé de six classes avec des priorités croissantes. Nous avons alors des classes qui obtiendront le débit alloué et qui pourront, de plus, utiliser la bande passante dont les autres classes n'ont pas besoin. Rappelons que les classes de plus hautes priorités (correspondant aux nombres prio les plus faibles) obtiendront en premier l'excès de bande passante. Notre liaison ADSL a un flux descendant de 2 Mbits/s et un flux montant de 300 kbits/s. J'utilise un débit de seuil (ceil rate) de 240 kbits/s car, au-delà de cette limite, les problèmes de latence commence à prendre de l'ampleur. Ceci est dû au remplissage d'un tampon placé quelque part entre nous et les hôtes distants.

Ajuster la variable CEIL à 75 % de votre bande passante montante maximum et ajuster le nom de l'interface (eth0 dans la suite) à celle qui a l'adresse publique Internet. Exécutez ce qui suit dans un shell root :

CEIL=240
tc qdisc add dev eth0 root handle 1: htb default 15
tc class add dev eth0 parent 1: classid 1:1 htb rate ${CEIL}kbit ceil ${CEIL}kbit
tc class add dev eth0 parent 1:1 classid 1:10 htb rate 80kbit ceil 80kbit prio 0
tc class add dev eth0 parent 1:1 classid 1:11 htb rate 80kbit ceil ${CEIL}kbit prio 1
tc class add dev eth0 parent 1:1 classid 1:12 htb rate 20kbit ceil ${CEIL}kbit prio 2
tc class add dev eth0 parent 1:1 classid 1:13 htb rate 20kbit ceil ${CEIL}kbit prio 2
tc class add dev eth0 parent 1:1 classid 1:14 htb rate 10kbit ceil ${CEIL}kbit prio 3
tc class add dev eth0 parent 1:1 classid 1:15 htb rate 30kbit ceil ${CEIL}kbit prio 3
tc qdisc add dev eth0 parent 1:12 handle 120: sfq perturb 10
tc qdisc add dev eth0 parent 1:13 handle 130: sfq perturb 10
tc qdisc add dev eth0 parent 1:14 handle 140: sfq perturb 10
tc qdisc add dev eth0 parent 1:15 handle 150: sfq perturb 10

Nous avons juste créé une arborescence htb avec un seul niveau de profondeur. Quelque chose comme ceci :

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

classid 1:10 htb rate 80kbit ceil 80kbit prio 0

Ceci est la classe de priorité la plus élevée. Les paquets de cette classe auront le plus faible délai et obtiendront en premier l'excès de bande passante. C'est donc une bonne idée de limiter le débit de seuil de cette classe. Nous enverrons dans cette classe les paquets qui ont un avantage à avoir un faible délai, tel que le trafic interactif : ssh, telnet, dns, quake3, irc, et les paquets avec le bit SYN activé.

classid 1:11 htb rate 80kbit ceil ${CEIL}kbit prio 1

Nous avons ici la première classe dans laquelle nous commençons à mettre du trafic de masse. Dans mon exemple, j'ai le trafic provenant de mon serveur Web local et les requêtes pour les pages Web : respectivement le port source 80 et le port destination 80.

classid 1:12 htb rate 20kbit ceil ${CEIL}kbit prio 2

Dans cette classe, je mettrai le trafic configuré avec le champ TOS « Débit Maximum » activé, ainsi que le reste du trafic provenant des processus locaux de mon routeur vers Internet. Les classes suivantes ne recevront donc que du trafic routé par cette machine.

classid 1:13 htb rate 20kbit ceil ${CEIL}kbit prio 2

Cette classe est pour le trafic des autres machines «NATées» (NdT : bénéficiant du service de traduction d'adresse) qui ont besoin d'une priorité plus grande dans leur trafic de masse.

classid 1:14 htb rate 10kbit ceil ${CEIL}kbit prio 3

Le trafic mail (SMTP, pop3,...) et les paquets configurés avec le champ TOS « Coût Minimum » seront envoyés dans cette classe.

classid 1:15 htb rate 30kbit ceil ${CEIL}kbit prio 3

Finalement, nous avons ici le trafic de masse des machines « NATées » se trouvant derrière le routeur. Les paquets liés à kazaa, edonkey et autres iront ici pour ne pas interférer avec les autres services.

Nous avons configuré le gestionnaire de mise en file d'attente, mais aucune classification de paquets n'a encore été faite. Pour l'instant, tous les paquets sortants passent par la classe 1:15 (car, nous avons utilisé : tc qdisc add dev eth0 root handle 1: htb default 15). Nous devons donc maintenant indiquer où doivent aller les paquets. Ceci est la partie la plus importante.

Nous allons maintenant configurer les filtres de telle sorte que nous puissions classifier les paquets avec iptables. Je préfère vraiment le faire avec iptables, car celui-ci est très souple et que nous avons un compteur de paquets pour chaque règle. De plus, avec la cible RETURN, les paquets n'ont pas besoin de traverser toutes les règles. Nous exécutons les commandes suivantes :

tc filter add dev eth0 parent 1:0 protocol ip prio 1 handle 1 fw classid 1:10
tc filter add dev eth0 parent 1:0 protocol ip prio 2 handle 2 fw classid 1:11
tc filter add dev eth0 parent 1:0 protocol ip prio 3 handle 3 fw classid 1:12
tc filter add dev eth0 parent 1:0 protocol ip prio 4 handle 4 fw classid 1:13
tc filter add dev eth0 parent 1:0 protocol ip prio 5 handle 5 fw classid 1:14
tc filter add dev eth0 parent 1:0 protocol ip prio 6 handle 6 fw classid 1:15

Nous indiquons simplement au noyau que les paquets qui ont une valeur FWMARK spécifique (handle x fw) vont dans la classe spécifiée (classid x:x). Voyons maintenant comment marquer les paquets avec iptables.

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 |
                        +-------+                    +--------+

Je suppose que toutes vos tables ont leur politique par défaut configurée à ACCEPT (-P ACCEPT), ce qui devrait être le cas si vous n'avez pas encore touché à iptables. Notre réseau privé est une classe B avec l'adresse 172.17.0.0/16 et notre adresse publique est 212.170.21.172.

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

Vérifions maintenant que les paquets transitent bien à travers 1:15 :

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

Vous devriez maintenant être capable de voir l'évolution du compteur de paquets quand vous pinguez des sites sur Internet depuis les machines du réseau privé. Vérifiez que le compteur de paquets augmente dans 1:10 :

tc -s class show dev eth0

Nous avons mis -j RETURN de manière à ce que les paquets ne traversent pas toutes les règles. Les paquets icmp ne scruteront pas les autres règles définies sous RETURN. Gardez ceci à l'esprit. Nous commençons maintenant à ajouter d'autres règles pour gérer les champs TOS :

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

Donnons la priorité aux paquets SSH :

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

Une bonne idée est de donner la priorité aux paquets initiant une connexion tcp, à savoir ceux qui ont le bit SYN activé :

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

Et ainsi de suite. Après la mise en place des règles dans la chaîne PREROUTING de la table « mangle », nous terminons par :

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

Ainsi, le trafic non marqué est dirigé vers 1:15. En fait, cette dernière étape n'est pas nécessaire puisque la classe par défaut est 1:15. Un marquage est quand même réalisé de manière à avoir une cohérence pour l'ensemble de la configuration. De plus, il est utile d'avoir une comptabilité pour cette règle.

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 telle sorte que le trafic local ait une priorité plus grande.

Toute notre configuration est maintenant opérationnelle. Prenez du temps pour regarder les graphes et observer où votre bande passante est la plus utilisée et cela correspond à vos souhaits. J'ai fait ceci pendant de nombreuses heures, ce qui m'a permis d'avoir une connexion Internet fonctionnant très bien. Autrement, vous serez confronté en permanence à des « timeout » et des allocations de bande passante presque nulles pour les nouvelles connexions tcp.

Si vous repérez des classes qui sont pleines la plupart du temps, ce peut être une bonne idée de leur attacher un autre gestionnaire de mise en file d'attente de manière à ce que le partage de la bande passante soit plus équitable :

tc qdisc add dev eth0 parent 1:13 handle 130: sfq perturb 10
tc qdisc add dev eth0 parent 1:14 handle 140: sfq perturb 10
tc qdisc add dev eth0 parent 1:15 handle 150: sfq perturb 10

Il est certain que ceci peut être fait de différentes façons. Dans mon cas, j'ai un shell script /etc/init.d/packetfilter qui accepte les arguments [start | stop | stop-tables | start-tables | reload-tables]. Celui-ci configure les gestionnaires de mise en file d'attente et charge les modules du noyau nécessaires et se comporte donc comme un démon. Le même script charge les règles iptables à partir de /etc/network/iptables-rules. Je vais l'embellir un peu et le rendrai disponible sur ma page Web ici

Quand un hôte veut dialoguer avec un autre hôte sur le même segment physique, il envoie un paquet du Protocole de Résolution d'Adresse (ARP) qui, en simplifiant quelque peu, est lu comme ceci : « Qui a 10.0.0.1, le dire à 10.0.0.7 ». En réponse à ceci, 10.0.0.1 renvoie un petit paquet « ici ».

10.0.0.7 envoie alors des paquets à l'adresse matérielle mentionnée dans le paquet « ici ». Il met dans un cache cette adresse matérielle pour un temps relativement long et, après l'expiration du cache, repose sa question.

Quand on construit un pseudopont, on configure le pont pour qu'il réponde à ces paquets ARP, les hôtes du réseau envoyant alors leurs paquets au pont. Le pont traite alors ces paquets et les envoie à l'interface adaptée.

Donc, en résumé, quand un hôte d'un côté du pont demande l'adresse matérielle d'un hôte se situant de l'autre côté, le pont répond avec un paquet qui dit « transmets-le-moi ».

De cette façon, tout le trafic de données est transmis à la bonne place et il traverse toujours le pont.

Les versions anciennes du noyau Linux permettaient de faire du proxy ARP uniquement à une granularité sous-réseau. Ainsi, pour configurer un pseudopont, il fallait spécifier les bonnes routes vers les deux côtés du pont, et également créer les règles proxy-ARP correspondantes. C'était pénible, déjà par la quantité de texte qu'il fallait taper, puis parce qu'il était facile de se tromper et créer des configurations erronées, où le pont répondait à des requêtes pour des réseaux qu'il ne savait pas router.

Avec Linux 2.4 (et peut-être bien le 2.2), cette possibilité a été retirée et a été remplacée par une option dans le répertoire /proc, appelée « proxy-arp ». La procédure pour construire un pseudopont est maintenant :

• assigner une adresse à chaque interface, la « gauche » et la « droite » ;
• créer des routes pour que votre machine connaisse quels hôtes résident à gauche et quels hôtes résident à droite ;
• activer le proxy-ARP sur chaque interface echo 1 > /proc/sys/net/ipv4/conf/ethL/proxy_arp echo 1 > /proc/sys/net/ipv4/conf/ethR/proxy_arp où L et R désignent les numéros de l'interface du côté gauche (Left) et de celle du côté droit (Right).

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érifiiez vos masques de sous-réseau.

Noyau Linux :

Compilé avec CONFIG_NETLINK_DEV and CONFIG_IP_MULTICAST (je ne sais pas si d'autres éléments sont également nécessaires).

Iproute

Zebra

Récupérez-le avec votre gestionnaire de paquet favori ou à partir de http://www.quagga.net.

Prenons le réseau suivant comme exemple :

----------------------------------------------------
| 192.168.0.0/24                                   |
|                                                  |
|      Zone 0    100BaseTX Commuté                 |
|     Épine dorsale     Ethernet                   |
----------------------------------------------------
|           |                |              |
|           |                |              |
|eth1       |eth1            |eth0          |
|100BaseTX  |100BaseTX       |100BaseTX     |100BaseTX
|.1         |.2              |.253          |
---------   ------------   -----------      ----------------
|R Omega|   |R Atlantis|   |R Legolas|      |R Frodo       |
---------   ------------   -----------      ----------------
|eth0         |eth0             |             |          |
|             |                 |             |          |
|2MbDSL/ATM   |100BaseTX        |10BaseT      |10BaseT   |10BaseT
------------   ------------------------------------       -------------------------------
| Internet |   | 172.17.0.0/16        Zone 1      |       | 192.168.1.0/24 wlan  Zone 2 |
------------   |     Réseau étudiant (dortoir)    |       |   Sans fil de Barcelone     |
               ------------------------------------       -------------------------------

Ne soyez pas effrayé par ce diagramme, Zebra réalise la plus grande partie du travail automatiquement ; ce qui ne demandera aucun travail de saisie des routes avec Zebra. Il serait pénible de maintenir toutes ces routes à la main au quotidien. La chose la plus importante à maîtriser clairement, c'est la topologie du réseau. Faites particulièrement attention à la zone 0, puisque c'est la plus importante. Dans un premier temps, configurez Zebra en éditant zebra.conf et en l'adaptant à vos besoins :

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

Debian nécessite également l'édition de /etc/zebra/daemons pour qu'ils soient lancés au démarrage :

zebra=yes
ospfd=yes

Nous devons maintenant éditer ospfd.conf si vous utilisez encore IPV4 ou ospf6d.conf si vous travaillez avec IPV6. Mon fichier ospfd.conf ressemble à ceci :

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

Ceci indique à ospf la topologie de notre réseau.

Nous devons maintenant démarrer Zebra soit à la main en tapant « zebra -d », soit avec un script comme « /etc/init.d/zebra start ». En regardant attentivement les logs de ospdfd, on peut voir les éléments suivants :

2002/12/13 22:46:24 OSPF: interface 192.168.0.1 join AllSPFRouters Multicast group.
2002/12/13 22:46:34 OSPF: SMUX_CLOSE with reason: 5   
2002/12/13 22:46:44 OSPF: SMUX_CLOSE with reason: 5
2002/12/13 22:46:54 OSPF: SMUX_CLOSE with reason: 5   
2002/12/13 22:47:04 OSPF: SMUX_CLOSE with reason: 5   
2002/12/13 22:47:04 OSPF: DR-Election[1st]: Backup 192.168.0.1
2002/12/13 22:47:04 OSPF: DR-Election[1st]: DR     192.168.0.1
2002/12/13 22:47:04 OSPF: DR-Election[2nd]: Backup 0.0.0.0
2002/12/13 22:47:04 OSPF: DR-Election[2nd]: DR     192.168.0.1
2002/12/13 22:47:04 OSPF: interface 192.168.0.1 join AllDRouters Multicast group.
2002/12/13 22:47:06 OSPF: DR-Election[1st]: Backup 192.168.0.2
2002/12/13 22:47:06 OSPF: DR-Election[1st]: DR     192.168.0.1
2002/12/13 22:47:06 OSPF: Packet[DD]: Negotiation done (Slave).
2002/12/13 22:47:06 OSPF: nsm_change_status(): scheduling new router-LSA origination
2002/12/13 22:47:11 OSPF: ospf_intra_add_router: Start

Ignorez le message SMUX_CLOSE pour l'instant dans la mesure où il concerne SNMP. Nous pouvons voir que 192.168.0.1 est routeur désigné (Designated Router) et que 192.168.0.2 est le routeur désigné de sauvegarde (Backup Designated Router).

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

$ telnet localhost zebra
$ telnet localhost ospfd

Voyons comment les routes se sont propagées en se connectant à zebra :

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

ou directement avec iproute :

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:~#

Nous pouvons voir les routes Zebra, qui n'étaient pas présentes auparavant. Il est vraiment agréable de voir apparaître les routes quelques secondes après le lancement de zebra et ospfd. Vous pouvez vérifier la connectivité avec les autres hôtes en utilisant ping. Les routes zebra sont automatiques. Vous pouvez ajouter un autre routeur au réseau, configurez Zebra et voilà !

Astuce ; vous pouvez utiliser :

tcpdump -i eth1 ip[9] == 89

pour analyser les paquets OSPF. Le numéro du protocole OSPF est 89 et le champ du protocole est le 9^e octet de l'en-tête ip.

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.

Le schéma réseau suivant est utilisé pour les exemples à suivre. AS 1 et 50 ont plusieurs voisins, mais nous avons seulement besoin de configurer 1 et 50 comme nos voisins. Les nœuds communiquent entre eux par des tunnels dans cet exemple, mais ce n'est pas une obligation.

Note : les numéros AS utilisés dans cet exemple sont réservés. Veuillez obtenir vos propres numéros AS du RIPE si vous installez des liens officiels.

                   --------------------
                   | 192.168.23.12/24 |
                   |    AS: 23        |
                   --------------------
                     /             \
                    /               \
                   /                 \
         ------------------       ------------------
         | 192.168.1.1/24 |-------| 10.10.1.1/16   |
         |    AS: 1       |       |    AS: 50      |
         ------------------       ------------------

La configuration suivante est écrite pour le nœud 192.168.23.12/24 et elle sera facile à adapter pour les autres nœuds.

Elle commence par des éléments généraux comme le nom de l'hôte, les mots de passe et les options de débogage :

! hostname
hostname anakin
 
! login password
password xxx
 
! enable password (super user mode)
enable password xxx
 
! path to logfile
log file /var/log/zebra/bgpd.log
 
! debugging: be verbose (can be removed afterwards)
debug bgp events
debug bgp filters
debug bgp fsm
debug bgp keepalives
debug bgp updates

La liste de contrôle d'accès (Access list) est utilisée pour limiter la redistribution aux réseaux privés (RFC 1918).

! RFC 1918 networks
 access-list local_nets permit 192.168.0.0/16
 access-list local_nets permit 172.16.0.0/12
 access-list local_nets permit 10.0.0.0/8
 access-list local_nets deny any

L'étape suivante consiste à configurer chaque AS :

! Own AS number
 router bgp 23
 
     ! IP address of the router
     bgp router-id 192.168.23.12
 
     ! announce our own network to other neighbors
     network 192.168.23.0/24
 
     ! advertise all connected routes (= directly attached interfaces)
     redistribute connected
 
     ! advertise kernel routes (= manually inserted routes)
     redistribute kernel

Chaque section 'router bgp' contient une liste de voisins auxquels le routeur est connecté :

     neighbor 192.168.1.1 remote-as 1
     neighbor 192.168.1.1 distribute-list local_nets in
     neighbor 10.10.1.1   remote-as 50
     neighbor 10.10.1.1   distribute-list local_nets in

Note : vtysh est un multiplexeur qui connecte toutes les interfaces utilisateur de zebra ensemble.

anakin# sh ip bgp summary 
BGP router identifier 192.168.23.12, local AS number 23
2 BGP AS-PATH entries
0 BGP community entries

Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  tate/PfxRcd
10.10.0.1       4    50      35      40        0    0    0 00:28:40        1
192.168.1.1     4     1   27574   27644        0    0    0 03:26:04       14

Total number of neighbors 2
anakin#
anakin# sh ip bgp neighbors 10.10.0.1
BGP neighbor is 10.10.0.1, remote AS 50, local AS 23, external link
  BGP version 4, remote router ID 10.10.0.1
  BGP state = Established, up for 00:29:01
  ....
anakin#

Voyons quelles routes nous avons obtenues de nos voisins :

anakin# sh ip ro bgp 
Codes: K - kernel route, C - connected, S - static, R - RIP, O - OSPF,
       B - BGP, > - selected route, * - FIB route
 
B>* 172.16.0.0/14 [20/0] via 192.168.1.1, tun0, 2d10h19m
B>* 172.30.0.0/16 [20/0] via 192.168.1.1, tun0, 10:09:24
B>* 192.168.5.10/32 [20/0] via 192.168.1.1, tun0, 2d10h27m
B>* 192.168.5.26/32 [20/0] via 192.168.1.1, tun0, 10:09:24
B>* 192.168.5.36/32 [20/0] via 192.168.1.1, tun0, 2d10h19m
B>* 192.168.17.0/24 [20/0] via 192.168.1.1, tun0, 3d05h07m
B>* 192.168.17.1/32 [20/0] via 192.168.1.1, tun0, 3d05h07m
B>* 192.168.32.0/24 [20/0] via 192.168.1.1, tun0, 2d10h27m
anakin#