Spécifier un itinéraire préféré lorsqu'il existe plusieurs liens vers le même réseau

J'ai un server avec plusieurs interfaces et adresses IP sur le même réseau. Je souhaite que le trafic non-iSCSI utilise exclusivement l'une des interfaces et que le trafic iSCSI utilise exclusivement le rest des interfaces. Limiter le trafic iSCSI à un sous-set de mes interfaces est facile; Je ne crée pas simplement d'inputs dans / var / lib / iscsi / ifaces / pour les interfaces que je ne veux pas utiliser. Cependant, je ne suis pas sûr de ce qu'est une bonne approche pour limiter le trafic non ISCSI à une seule interface. En ce qui concerne linux, les interfaces iSCSI et non-iSCSI sont également des bons paths vers le réseau.

Voici un exemple de configuration

Le stockage iSCSI possède les adresses IP 172.16.50.70-78.

Le server possède les interfaces, les adresses et les routes suivants.

$ ip route list 149.76.12.0/24 dev eth0 proto kernel scope link src 149.76.12.4 172.16.0.0/16 dev eth1 proto kernel scope link src 172.16.50.80 172.16.0.0/16 dev eth2 proto kernel scope link src 172.16.50.81 172.16.0.0/16 dev eth3 proto kernel scope link src 172.16.50.82 default via 149.76.12.1 dev eth0 

La configuration souhaitée est que eth3 soit utilisé pour le trafic non-ISCSI et que eth1 et eth2 soient utilisés pour le trafic iSCSI. Cependant, le trafic non-iSCSI sort actuellement de l'éth1.

 $ ip route get to 172.16.50.90 172.16.50.90 dev eth1 src 172.16.50.80 

(certaines modifications depuis la publication originale ci-dessous)

Avec ma configuration actuelle, si eth1 et eth2 sont complètement saturés en envoyant le trafic iSCSI, mon trafic non-iSCSI sera en concurrency avec le trafic iSCSI sur eth1 alors que eth3 est inactif.

Comment puis-je configurer linux pour préférer envoyer du trafic vers le réseau local en utilisant eth3 plutôt que eth1 ou eth2?

J'ai déjà configuré net.ipv4.conf.all.arp_ignore à 1 et net.ipv4.conf.all.arp_announce à 2. Cela devrait empêcher mes adresses IP de flotter entre les interfaces, par exemple, stream d'arp. Je pense que j'ai juste besoin d'aide pour le routing.

(plus de modifications)

Grâce à pfo, j'ai commencé à examiner les parameters. Si je supprimer les routes et les recréer avec les interfaces iSCSI ayant une mésortingque plus élevée que l'interface non-iSCSI, les choses semblent fonctionner comme je le souhaite. Le trafic iSCSI utilise toujours les interfaces dédiées sans que je configure des routes statiques vers les adresses IP iSCSI. Tout l'autre trafic local sort de l'éth3. Maintenant, je dois find la manière appropriée de définir les parameters automatiquement lorsque les interfaces sont générées. Il s'agit de RHEL 5.5.

 ip route delete to 172.16.0.0/16 dev eth1 ip route delete to 172.16.0.0/16 dev eth2 ip route delete to 172.16.0.0/16 dev eth3 ip route add to 172.16.0.0/16 dev eth1 src 172.16.50.80 mesortingc 1 ip route add to 172.16.0.0/16 dev eth2 src 172.16.50.81 mesortingc 1 ip route add to 172.16.0.0/16 dev eth3 src 172.16.50.82 mesortingc 0 

(mise à jour finale)

L'assignation d'une mésortingque différente à l'aide des scripts de réseau RHEL existants semble impossible, https://bugzilla.redhat.com/show_bug.cgi?id=498472

Il y a des choses à prendre en count lorsque vous êtes des hôtes multi-homing. La première chose, c'est que vous devez être conscient de la façon dont la stack Linux TCP / IP va gérer plusieurs interfaces dans le même sous-réseau concernant les requêtes et les réponses ARP. Ce paramètre est la valeur arp_filter l'interface que vous pouvez interroger via sysctl(1) ou le système de files /proc .

0 – (par défaut) La stack TCP / IP répondra aux requests ARP avec des adresses d'autres interfaces. Cela peut sembler faux, mais il est généralement logique, car cela augmente les chances de communication réussie. Les adresses IP sont la propriété de l'hôte complet sous Linux, et non par des interfaces particulières.

1 – Permet d'avoir plusieurs interfaces réseau sur le même sous-réseau, et les ARP pour chaque interface peuvent-ils être répondues en fonction de la question de savoir si le kernel pourrait ou non apather un package de l'IP ARP à cette interface. En d'autres termes, il permet de contrôler quelles NIC répondent à une request ARP et vont finalement laisser passer vos stream TCP / IP.

Vous devez d'abord activer arp_filter sur toutes les interfaces qui se trouvent dans le même sous-réseau et vous pouvez facilement append une input à votre table de routing pour votre portail iSCSI pour utiliser une iface spécifique et ajuster l'autre mésortingque d'interface pour que l'on soit préférable autre.

Une autre option consiste à configurer le routing basé sur la source, car le routing basé sur la destination par défaut fonctionnera exactement comme vous l'avez décrit lorsque toutes les occurrences se trouvent dans le même sous-réseau.

La raison pour laquelle eth1 est supprimé est que c'est IP qui a la valeur numérique la plus basse et est tellement choisi pour la communication avec ce réseau.

Pour résoudre mon problème, j'ai écrit nethook , un démon qui exécute des scripts lorsque les interfaces réseau changent d'état sur les dissortingbutions basées sur RHEL. Je l'ai fait exécuter ce script pour les interfaces dont la mesure de l'itinéraire que je veux augmenter.

EDIT: J'ai écrit nethook avant d'être informé de ifup-local et ifdown-local . Vous pouvez probablement les utiliser à la place.