Partie I Introduction à l'administration système : services IP
1. Suite de protocoles réseau TCP/IP Oracle Solaris (présentation)
Partie II Administration TCP/IP
2. Planification de votre réseau TCP/IP (tâches)
4. Planification d'un réseau IPv6 (tâches)
5. Configuration des services réseau TCP/IP et de l'adressage IPv4 (tâches)
6. Administration d'interfaces réseau (tâches)
7. Configuration d'un réseau IPv6 (tâches)
8. Gestion d'un réseau TCP/IP (tâches)
9. Dépannage des problèmes de réseau (tâches)
10. Présentation détaillée de TCP/IP et IPv4 (référence)
11. Présentation détaillée de IPv6 (référence)
12. À propos de DHCP (présentation)
13. Planification pour le service DHCP (liste des tâches)
14. Configuration du service DHCP (tâches)
15. Administration de DHCP (tâches)
16. Configuration et administration du client DHCP
17. Résolution des problèmes DHCP (référence)
18. Commandes et fichiers DHCP (référence)
19. Architecture IPsec (présentation)
20. Configuration d'IPsec (tâches)
21. Architecture IPsec (référence)
22. Protocole IKE (présentation)
23. Configuration du protocole IKE (tâches)
25. IP Filter dans Oracle Solaris (présentation)
28. Administration de Mobile IP (tâches)
29. Fichiers et commandes de Mobile IP (références)
Composants IPMP Oracle Solaris
Démon de multiacheminement in.mpathd
Détection de défaillance et basculement
Détection de réparation et rétablissement
Répartition de charge sortante
Configurations d'interfaces IPMP
Interfaces de réserve d'un groupe IPMP
Configurations courantes d'interfaces d'IPMP
Vérification du statut d'une interface
Détection de défaillance d'IPMP et fonctionnalités de reprise
Détection de défaillance basée sur les liaisons
Détection de défaillance basée sur sonde
Détection de réparation d'interface physique
Description du basculement d'interface
IPMP et reconfiguration dynamique
Connexion de cartes d'interface réseau
Déconnexion de cartes d'interface réseau
Reconnexion d'une carte d'interface réseau
Cartes d'interface réseau manquantes à l'initialisation du système
31. Administration d'IPMP (tâches)
Partie VII Qualité de service IP (IPQoS)
32. Présentation d'IPQoS (généralités)
33. Planification d'un réseau IPQoS (tâches)
34. Création du fichier de configuration IPQoS (tâches)
35. Démarrage et maintenance d'IPQoS (tâches)
36. Utilisation de la comptabilisation des flux et de la collecte statistique (tâches)
Vous pouvez configurer la détection de défaillance d'IPMP sur des réseaux IPv4 ainsi que sur des réseaux IPv4 et IPv6 double pile. Les interfaces configurées avec IPMP prennent deux types d'adresses en charge : les adresses de données et les adresses test.
Les adresses de données correspondent aux adresses IPv4 et IPv6 conventionnelles assignées à l'interface d'une carte d'interface réseau au démarrage ou manuellement, à l'aide de la commande ifconfig. Le trafic de paquets standard IPv4 et, le cas échéant, IPv6, passant par une interface est considéré comme du trafic de données.
Les adresses test sont des adresses spécifiques à IPMP utilisées par le démon in.mpathd. Pour pouvoir utiliser la détection de défaillance et de réparation basée sur sonde, une interface doit être configurée avec au moins une adresse test.
Remarque - La configuration des adresses test n'est requise que si vous souhaitez utiliser la détection de défaillance basée sur sonde.
Le démon in.mpathd utilise les adresses test afin d'échanger les sondes ICMP avec d'autres cibles sur la liaison IP. C'est ce qu'on appelle le trafic de sondes. Le trafic de sondes permet de déterminer le statut de l'interface et de sa carte d'interface réseau, y compris l'emplacement de la défaillance de l'interface. Les sondes vérifient que le chemin d'envoi et de réception vers l'interface fonctionne correctement.
Il est possible de configurer chaque interface avec une adresse IP test. Dans le cas d'une interface sur un réseau double pile, vous pouvez configurer une adresse test IPv4, une adresse test IPv6 ou les deux.
En cas de défaillance d'une interface, les adresses test restent sur celle-ci de sorte que in.mpathd puisse continuer à envoyer des sondes afin de vérifier les réparations ultérieures. Veillez à configurer les adresses test de façon spécifique, de sorte que les applications ne les utilisent pas accidentellement. Pour de plus amples informations, reportez-vous à la section Empêcher les applications d'utiliser les adresses test.
Pour de plus amples informations sur la détection de défaillance basée sur sonde, reportez-vous à la section Détection de défaillance basée sur sonde.
En règle générale, vous pouvez utiliser l'adresse IPv4 de votre choix sur votre sous-réseau en tant qu'adresse test. Il n'est pas nécessaire que les adresses test IPv4 soient acheminables. Dans la mesure où les adresses IPv4 sont une ressource limitée pour de nombreux sites, il est préférable dans certains cas d'utiliser des adresses privées RFC 1918 non acheminables en tant qu'adresses test. Notez que le démon in.mpathd n'échange que des sondes ICMP avec d'autres hôtes situés sur le même sous-réseau que l'adresse test. Si vous utilisez des adresses test de type RFC 1918, veillez à configurer d'autres systèmes, des routeurs de préférence, sur la liaison IP avec des adresses situées sur le sous-réseau RFC 1918. Le démon in.mpathd peut ensuite échanger les sondes avec des systèmes cible.
Les exemples d'IPMP utilisent les adresses RFC 1918 à partir du réseau 192.168.0/24 en tant qu'adresses test IPv4. Pour plus d'informations sur les adresses privées RFC 1918, reportez-vous au document RFC 1918, Address Allocation for Private Internets (en anglais).
Pour configurer les adresses test IPv4, reportez-vous à la tâche Procédure de configuration d'un groupe IPMP avec plusieurs interfaces.
La seule adresse test IPv6 valide correspond à l'adresse lien-local d'une interface physique. Vous n'avez pas besoin d'utiliser une adresse IPv6 en tant qu'adresse test IPMP. L'adresse IPv6 lien-local est basée sur l'adresse MAC (Media Access Control) de l'interface. Les adresses lien-local sont configurées automatiquement lorsque l'interface devient compatible IPv6 lors du démarrage ou lorsque l'interface est configurée manuellement via ifconfig.
Exécutez la commande ifconfig interface sur un nœud compatible IPv6 afin d'identifier l'adresse lien-local d'une interface. Vérifiez la sortie de l'adresse qui commence par fe80, le préfixe lien-local. L'indicateur NOFAILOVER dans la sortie de commande ifconfig ci-dessous indique que l'adresse lien-local fe80::a00:20ff:feb9:17fa/10 de l'interface hme0 est utilisée en tant qu'adresse test.
hme0: flags=a000841<UP,RUNNING,MULTICAST,IPv6,NOFAILOVER> mtu 1500 index 2 inet6 fe80::a00:20ff:feb9:17fa/10
Pour de plus amples informations sur les adresses lien-local, reportez-vous à la section Adresse unicast lien-local.
Lorsque IPv4 et IPv6 sont montés sur la totalité des interfaces d'un groupe IPMP , il est inutile de configurer des adresses test IPv4 distinctes. Le démon in.mpathd peut utiliser des adresses IPv6 lien-local en tant qu'adresses test.
Pour créer des adresses test IPv6, reportez-vous à la tâche Procédure de configuration d'un groupe IPMP avec plusieurs interfaces.
Après avoir configuré une adresse test, vous devez vous assurer que cette adresse n'est pas utilisée par les applications. Sinon, en cas de défaillance de l'interface, il devient impossible d'atteindre l'application car les adresses test ne basculent pas lors de l'opération de basculement. Pour vous assurer qu'IP ne sélectionne pas l'adresse test pour des applications normales, marquez l'adresse test comme étant deprecated.
IPv4 n'utilise pas d'adresse désapprouvée en tant qu'adresse source pour toute communication, à moins qu'une application ne crée une liaison explicite vers l'adresse. Le démon in.mpathd lie de façon explicite à une telle adresse afin d'envoyer et de recevoir du trafic de sondes. Cependant, si une application ne lie pas explicitement à une adresse et que la seule adresse marquée comme UP à l'interface est également marquée comme désapprouvée, alors cette adresse est utilisée comme adresse source en dernier recours.
Remarque - En cas de basculement et de rétablissement, tant que la détection d'adresses dupliquées est en cours d'exécution, les applications peuvent recevoir des paquets utilisant des adresses désapprouvées comme adresses source. Ce comportement est attendu. En général, après l'achèvement de la détection d'adresses dupliquées, les adresses désapprouvées ne sont plus traitées par les applications. Toutefois, une exception peut être observée avec les paquets TCP. Une fois qu'une connexion TCP a choisi une adresse source spécifique, l'utilisation de cette adresse ne peut pas être modifiée pendant toute la durée de la connexion. La durée de la connexion peut s'étendre sur une longue période. Dans de tels cas, les applications peuvent néanmoins continuer à utiliser des adresses désapprouvées, même après l'achèvement de la détection d'adresses dupliquées.
Dans la mesure où les adresses IPv6 lien-local sont généralement absentes dans un service de nom, les applications DNS et NIS n'utilisent pas d'adresses lien-local pour la communication. Par conséquent, vous ne devez pas marquer les adresses lien-local IPv6 comme étant deprecated.
Les adresses test IPv4 ne doivent pas être placées dans les tables de services de noms DNS et NIS. Dans IPv6, les adresses lien-local ne sont normalement pas placées dans les tables de services de noms.